Object Oriented Analysis and Design

Presenter : Aseem JainOct 10, 2014

What is analysis?

2

• A method of studying the nature of something or of determining its essential features and their relations• A method of exhibiting complex concepts or

propositions as compounds or functions of more basic ones• The evaluation of an activity to identify its desired

objectives and determine procedures for efficiently attaining them

So what’s this got to do with developing software?

Getting to the essentials

3

Gather requirement

s

Analyze in real world

context

Develop the architecture

Scenarios unify the views

4

ProcessorsData stores

Code structurePackagesLibraries

Logical View

Progress View

Development View

Physical View

System engineersTopology

Communications

IntegratorsPerformanceScalability

End-user Functionality

ProgrammersSoftware

management

Scenarios

ClassesObjectsBehaviors

ThreadsProcessesCommunications

User stories

Describe a single feature or unit of work for a developer

Provides enough information to define the basic need“A promise for a conversation” – Allistair Cockburn

Should be able to be tested with unit tests

5

A typical user story (revised)

6

Open the dog door

The DogDoor will receive a signal to open the door from some peripheral device, such as the remote button or the bark recognizer. When the signal to open the door is received, the door will open and remain open for 5 seconds. At the end of 5 seconds, the door will close. If the door is already open, then the door will not close until 5 seconds from the current signal reception has elapsed.

User stories for our main use case

7

I like this. Any additional words of wisdom?

User story guidelinesIf the user story gets too long, break it up

into two or moreIf it won’t fit on an index card, it’s too big

If the user story is trivial, it can probably be combined with another

Make sure there’s enough information for the developer to implement the user story or at least ask intelligent questions about it

If a user story will take too much time (which is relative) to implement, break it up into smaller user stories

8

Comparing the three techniques

9

Use cases CRC Cards User stories

Address complete goal-oriented sequences of actions the system must perform

Can be used to describe complete sequences and scenarios

Feature oriented rather than a user’s goal oriented.

Unifies several features or parts of features to provide value. Does not address the class level view.

Shows relationships between classes by proximity.

Can be at a technical level but does not relate features to higher level goals.

Mainly requirements and analysis

More design level than the other two techniques

Can include technical details needed to satisfy requirements

Explicitly describes multiple paths

Implicitly represents multiple paths and scenarios

Does not address paths

Can be used for estimation (large granularity estimation)

Not very useful for estimation Good for individual programmer task estimation

Textual analysis Nouns in requirements

and documents

Entities and concepts From the application

domain

Experience Previous systems

10

Where do classes come from?

If nouns are classes, verbs are …

11

Behavior (methods)

Questions ?