8/11/2019 05ooa.doc

1/7

Object-Oriented Analysis

Requirements analysis and domain analysis precede design

So far weve looked at requirements analysisunderstanding what the customer wants

Domainanalysis understands the customers problemby identifying the classes comprising a

problem domain. Design explores their contents from outside in

Whats the difference between traditional or structured analysis and OO analysis?

Result of !! analysis is a representation of the classesof a problem domain "not functions#

$dentifying classes is category%formation

!b&ects simulatesome slice of the world which a computer system models

!b&ects are a natural construct for simulation

'lasses of ob&ects are a natural way to organi(e classes

$nfants learn to recogni(e objectsand how to categori(ethem in their first few months

) key insight of the child psychologist *iaget+ cognitive scientists have done further work )dults rely on categori(ation to understand the world around them

,e create new categories all the time for example new makes of cars

) problem with categories however is that they can be fu((y and hard to define precisely

Natural kinds- how do you define an elephant a game

Prototypes- people see how close ob&ects match a prototypical member of a category

Why is the fuzziness of natural kinds a problem for OOSE?

$t/s hard to be precise about defining categories

0hat/s why we need a methodology for !!S1

Some categories are directly observable in requirements

!thers are more abstract implicit or arising from implementation needs 'andidate classes include-

0angible things referred to by common nounsin requirements specification

or application domain "i.e. cookie factory triangle#

Eventswith associated information "i.e.flightgame#.

)bstract data stores "i.e. buffer, tree, hash table#

1xternal interface ports "i.e.terminal, printer, window, menu#

'omplex processes or operations "i.e.sort, edit command#

2ote- verbscan also be classes3 1specially processes than store state information.!ne might think of a scanner as an operation on tokens of class S0R$24

5ut a scanner/s behavior probably deserves its own abstraction)s a subclass of S0R$24

'an anything be a class ,hat isn'ta class

$ndeed category%formation is a fundamental human activity

5ut there are practical limits- classes should have content storing state information

Simple operations "e.g. 67$0#

*roper nouns "these are instances of classes not classes#

'lasses with &ust one or two routines"probably not worth classifying#

8

8/11/2019 05ooa.doc

2/7

Redundantclasses "merge synonyms reuse classes in libraries#

)gain- develop a glossary of termsWhy would this be especially helpful to OO analysis?

5rief dictionary%like definitions denoting how the term is used in domain

Definingterms explicates the domain knowledge that you are modeling

0erms can help with the discovery of classes and their structure

9aintain glossary files throughout development finally as documentation

Responsibility-Driven Design!ee multimedia from The Universal Machineon "R" cards#

Developed by 5eck and 'unningham at 0ektronix see http-::c;.com:doc:oopslaowler introduces 'R' and end of chapter ? "@rdedition#

Aey idea- ob&ects have responsibilities as if they were simple agents "or actors in scenarios#

)nthropomorphism of class responsibilities gets away from thinking about classes as &ust data

holders+ Bob&ect thinkC focuses on their active behaviors 1ach ob&ect is responsible for specific actions %% client can expect predictable behaviors

Responsibility also implies independence- to trust an ob&ect to behave as expected is to rely upon its

autonomy and modularity

arder to trust ob&ects easily caught up in dependencies caused by global variables and side effects.

"R" "lass Responsibility "ollaborator# cards are Elow techE- ordinary index cards1ach card represents a classof ob&ects. 1ach card has three components-

"lass Namecreates the vocabulary of our analysis

7se nouns as class names so you begin to think of them as simple agents.

1ven classes that you might think of verbs or actions can be made into nouns+e.g. Breading a cardC becomes "ardReader a class of ob&ect "agent# that manages bank cards.

7se pronounceable names. $f you cannot read aloud it is not a good name.

7se capitali(ation "or underscores# to initiali(e class names and to demarcate multi%word

names such as 'ardReader rather than ')RDR1)D1R or cardFreader. ,e feel that thisconvention is easier to read and to type.

)void obscure ambiguous abbreviations- e.g. is 0erm*rocess something that terminates

or something that runs on a terminal

;

http://c2.com/doc/oopsla89/paper.htmlhttp://c2.com/doc/oopsla89/paper.html

8/11/2019 05ooa.doc

3/7

0ry not to use digits within a name%%better for instances than classes of ob&ects.

Responsibilitiessection describes a classs be%aviors%% describe whatis to be done not how3

7se short verb phrases e.g.- Breads cardC or Blook up wordsC

'onstraints of an index card are a good measure of appropriate complexity-

if you cannot fit enough tasks on a card maybe you need to divide tasks between classes

0he "ollaboratorssection list important suppliersand possibly clients of a class

,hy are classes that supply services more important here

5ecause suppliers are necessary for the description of responsibilities

)s you write down responsibilities for a class add any suppliers needed for them

>or example Bread dictionaryC obviously implies that a BdictionaryC as a collaborator

Developing 'R' cards is first a process of discovering classes and their responsibilities*eople naturally cut up the world in terms of categories of ob&ects$n ob&ect%oriented analysis one discovers new categories relevant to a problem domain

Designing for responsibility involves simulation%% ob&ects model a world interacting behaviors

)n analyst can prototype a system by running a simulation of ob&ects and their behaviors!nce youve developed a set of 'R' cards you/re ready to run simulations or

orstructured walkthrough scenarios %%

*laying Bwhat ifC lets you simulate scenarios that illustrated expected use of a systemlet each person be responsible for simulating one or more classesnow you can BexecuteC a scenario by having each ob&ect run at the right time

Start a simulation with the construction of an ob&ect of a classthen run one of its behaviors "a responsibility of that class#

0his behavior may in turn pass control to some collaborator %% another classSimulation becomes visible as an exchange of behavior and control from one card to another

Gou may discover missing or incompletely described responsibilities

$9! it really should be called responsibility%driven analysis, rather than design.

Why? When is activity most useful?

See 'oad H 2icola handout "pp. ??%?I#- 2otice the use of first person scenarios'oad H 2icola call this the E!m aliveprincipleE- !b&ects can be better understood by thinkingabout them and talking about them in the first person%%E$ know my own FFFF and $ can FFFmyself.E

Similarly Aent 5eck talks about the need for anthropomorphism in responsibility%driven

design What goes in the blanks? "attributes and behaviors#

Why is putting these scenarios in the first person a good idea?

$ow is this similar to responsibility%driven design?

50, 'oad H 2icola "on reserve# spice up their text with a lot of these common sense principles

)ppendix ' starting on p. I?= lists all the principles found in this book

$ll read a few- you reflect them back to me in your words and comment

@

8/11/2019 05ooa.doc

4/7

"lass diagrams"handout from 'oad H Gourdon p. ??%?I see >owler- p. IJ in ;ndedition @J in @rdedition-

http-::www.cse.lehigh.edu:Kglennb:oose:figs:class?%8.&pg #9eyer- circles represent classes+ unlabeled lines connecting classes represent relations'oad- boxes represent classes+ connecting lines have gate%like markings on them79L- boxes represent classes+ lines are associations to which more information may be added

euristic- don!t put labels on the relations yet at first

Semantics of relations tends to be vague1.g. Eis aE can mean S750G*1 "Ea square is a polygonE#or $2S0)2'1%!> "E4eorge is a squareE#or $D120$')L%0! "E0he morning star is the evening starE#or *R!*1R0G%!> "E) circle is roundE#or R!L1%!> "E4eorge is *residentE#or 9)D1%!> "E9y house is brickE#or simply 1M$S0S "Eto be or not to beE#."$n many languages there is no EisE at all.#

Let the meaning of relations emerge from what they relate

Nagueness is natural- start off vague get more specific gradually

79L supports this heuristic by starting with simple undirected lines "associations#

>owler advocates starting with conceptual perspective ignoring implementation

Later add detail to your relationship structures

!!) typically distinguishes two relations- is-aand %as-a

9eyer calls these in%eritanceand client&supplier

'oad and Gourdon call these generaliation&specialiationand (%ole&part

79L calls these generali(ation and association or aggregation or composition

$mplemented in 'OO and Pava by inheritance and data members

)eneraliationsextract commonality among speciali(ations-

9eyer uses double%line+ 'oad:Gourdon use lines bisected by semi%circle+ 79L uses arrow

4enerali(ation drawn above speciali(ations in a hierarchy or lattice

1xamples on pp.

8/11/2019 05ooa.doc

5/7

1.g. 9anager %%%%%%%%%%% sales rep % 1mployee "1mployee/s role is sales rep#*ore notation for analysis or design+#

'oad Gourdon H 2icola describe five activities of OOA "see handout#8# 'lass%H%ob&ect %% describing problem domain in terms of classes of ob&ects;# Structure %% describing relationships between classes@# Sub&ect %% organi(ing classes into clusters "79L packages#?# )ttributes %% describing data held by ob&ectsI# Services %% describing behaviors that ob&ects can performWhich of these five activities are analysis and which are design? What do you think?

8# 'lasses represented by boxes with class name in the top section

1xtra gray box surrounding a class denotes that it is a concrete class otherwise it/s abstract

)n abstract class has one or more operations that must be implemented by subclasses

What does this notation tell you about class &ount?

79L represents an abstract class by italici(ing the class name or adding the label

VabstractW;# Structure represented by lines connecting classes

$n 'oad notation semicircle means gen:spec "e.g. 'ount generali(es $nteger'ount#

triangle represents whole%part "e.g. 5utton is part of 'ountNiew'ontainer#

thin black line represents ob&ect association "e.g. Display5ox holds 8 'ount#

0hick line represents message scenario

"e.g. 'ount sends a message E)8E to Display5ox- display my value#

$n 79L simple line is an association"with notation for multiplicity role names constraints#

See >owler ch I "p. J

8/11/2019 05ooa.doc

6/7

)gain 79L has a bit more notation for information about default values and visibility

1.g. O balance!n"date-Date#- 9oney

)gain $ recommend you hold off on these details until design

*odeling dynamic be%aviors (it% se,uence and collaboration diagrams"See >owler chapter I#

'lass diagrams describe static relationships between classes but what about modeling dynamic behavior

$nteraction diagrams model how groups of ob&ect collaborate in some behavior

0ypically an interaction diagram captures the behavior of a single use case

1xample use case "http-::www.cse.lehigh.edu:Kglennb:oose:figs:7se'ase!rder1ntry.htm #-

)n !rder 1ntry window sends a BprepareC message to an !rder

!rder sends BprepareC to each !rder Line on the !rder

1ach !rder Line checks the given Stock $tem- if true remove Stock $tem and deliver

$f Stock $tem falls below reorder level then Stock $tem requests reorder

!e,uence diagram"http-::www.cse.lehigh.edu:Kglennb:oose:figs:seqI%8.&pg #-

Nertical line is called an ob&ects lifeline representing an ob&ects life during interaction

!b&ect deletion denoted by M ending a lifeline

ori(ontal arrow is a message between two ob&ects

!rder of messages sequences top to bottom

9essages labeled with message name optionally arguments and control information

'ontrol information in brackets may express conditions such as YhasStockZ or iteration

Returns "dashed lines# are optional+ use them to add clarity

Sequence diagrams can also represent concurrent processes-

>igure I%@ "http-::www.cse.lehigh.edu:Kglennb:oose:figs:seqI%@.&pg # 79L 8 models async%ronousmessages as hori(ontal lines with %alfarrow heads

79L ; makes this distinction by not filling an arrowhead

>owler prefers older notation. Why? Which do you prefer?

)fter setting up 0ransaction 'oordinator invoke concurrent 0ransaction 'heckers

$f a check fails kill all the 0ransaction 'hecker processes

2ote use of comments in margin' When is this a good idea? for documentary purposes

"ollaboration diagramis a second way to model interactions of ob&ects

http-::www.cse.lehigh.edu:Kglennb:oose:figs:collabI%?.&pg

!b&ects are rectangular icons e.g. !rder 1ntry ,indow !rder etc.

9essages are arrows between icons e.g. prepare"#

2umbers on messages indicate sequence+ also spatial layout helps show flow

Which do you prefer( se)uence or collaboration diagrams?

>owler now admits he doesnt use collaboration diagrams demoting them to ch 8I

$nteraction diagrams show flow clearly but are awkward when modeling alternatives

79L notation for control logic has changed in 79L ; but >owler isnt impressed

J

http://www.cse.lehigh.edu/~glennb/oose/figs/UseCaseOrderEntry.htmhttp://www.cse.lehigh.edu/~glennb/oose/figs/seq5-1.jpghttp://www.cse.lehigh.edu/~glennb/oose/figs/seq5-3.jpghttp://www.cse.lehigh.edu/~glennb/oose/figs/collab5-4.jpghttp://www.cse.lehigh.edu/~glennb/oose/figs/UseCaseOrderEntry.htmhttp://www.cse.lehigh.edu/~glennb/oose/figs/seq5-1.jpghttp://www.cse.lehigh.edu/~glennb/oose/figs/seq5-3.jpghttp://www.cse.lehigh.edu/~glennb/oose/figs/collab5-4.jpg

8/11/2019 05ooa.doc

7/7

>owler recommends using 'R' cards to begin modeling scenarios

0hen document with 79L sequence "or interaction# diagrams

7se sequence diagrams to show collaborations among many ob&ects

7se state diagrams to show the behavior of a single ob&ect across many use cases

Q