Chap 5 - Object Oriented Design

8/17/2019 Chap 5 - Object Oriented Design

1/134

Object Oriented Analysis and Design 1

Chapter 5 Object Oriented Design OO Design Overview

Architectural Design Use Case Design Subsystem Design

Class Design


2/134


3/134


5.1 OO Design Overview Understanding Design

Analysis Versus Design Object Oriented Design


4/134


Understanding Design A process that uses the products of

analysis to produce a specification forimplementing a system. A logical description of how a system willwor .

!mphasi"es a conceptual solution #insoftware and hardware$ that fulfills there%uirements& rather than itsimplementation.'do the right thing #analysis$& and do thething right #design$(.


5/134


Analysis Versus Design Analysis

Focus on understandingthe problemIdealized design

eha!ior

"ystem structureFunctional re#uirements

A small model

Design

Focus on understandingthe solutionOperations and

Attributes$er%ormance&lose to real codeObject li%ecycles'on(%unctionalre#uirements

A large model


6/134


7/134Object Oriented Analysis and Design 0

Architectural Design


8/134Object Oriented Analysis and Design

5.2 Architectural Design Architectural )atterns

*esolution of Architectural +actors ,dentify Design !lementsOrgani"ing the design model pac ages


9/134


10/134


"ypical #ayering Appr$ach

Generalfunctionality

Specific

functionality


11/134


%&a'ples $( Architectural atterns ) #ayers1) Pattern Name: Layers2) Context A large system that requires decomposition.3) Pro lem

A system !hich must handle issues at di""erent le#els o"a straction. $or example: hard!are control issues%common ser#ices issues and domain&speci"ic issues. 't!ould e extremely undesira le to !rite #ertical

components that handle issues at all le#els. (he same issue!ould ha#e to e handled possi ly inconsistently) multipletimes in di""erent components.


12/134


13/134


14/134


*$deling Architectural #ayers Architectural layers can be modeled using

stereotyped pac8ages::layer;; stereotype

$ac8age 'ame::layer;;


15/134


#ayer + ,euse driving

layerApplication

layerusiness&+peci"ic

layeriddle!are


16/134

Object Oriented Analysis and Design 1)

%&a'ple + Applicati$n #ayer


17/134


%&a'ple + -usiness peci(ic #ayer


18/134


%&a'ples $( Architectural atterns ) #ayers


19/134


artial l$gical view $( layers in the /e&t0en applicati$n


20/134


yste' Operati$ns and #ayers


21/134


Upward C$llab$rati$n with Observer=I +indo+s-


22/134


Upward C$llab$rati$n with Observer


23/134


24/134


25/134


"er'in$l$gy "iers #ayers and artiti$ns*he original notion o% a tier in architecture +asa logical layer, not a physical node, but the+ord has become +idely used to mean aphysical processing node .or cluster o% nodes/

such as the client tier .the client computer/--

*he layers o% an architecture are said torepresent the !ertical slices*he partitions represent a horizontal di!isiono% relati!ely parallel subsystems o% a layer-


26/134


#ayers and partiti$ns


27/134


#ayer ) /)"ier 3C4

+er#er

Client A Client N4...


28/134


#ayer ) /)"ier 36 tier

5elational 6ata ase+er#er s)

Client C 777 ro!ser

7e+er#er

8( LC9' A+P a#a

usiness ;


29/134


#ayer ) /)"ier 3n)tier

HTML, Script Languages, ...

JS , Servlets, !G", ...

#J$, !O%$A, !OM&

'ative languages

Client> ro!ser

7e +er#er

Application +er#er

Legen(Syste)

Data*aseServer


30/134


Architectural attern ) *VC? Nam e: @C odel&@ie!&Controller)? Context and force s: !e ha#e a data model and se#eral representations o" the

data 7e !ant to modulari,e the system 6ata representation must e /ept up to date? Proble m: ho! to modulari,e the system? Solutio n: the model holds the data and does data modi"ication)% the #ie! representsthe data% the controller handles user input


31/134


32/134


%&a'ples $( Architectural atterns ) -lac7b$ard1) Pattern Name

lac/ oard2) ContextA domain in !hich no closed algorithmic) approach tosol#ing a pro lem is /no!n or "easi le. =xamples are A'

systems% #oice recognition% and sur#eillance systems.3) Pro lem

ultiple pro lem&sol#ing agents /no!ledge agents) mustcooperate to sol#e a pro lem that cannot e sol#ed y any

o" the indi#idual agents. (he results o" the !or/ o" theindi#idual agents must e accessi le to all the otheragents so they can e#aluate !hether they can contri uteto "inding a solution and post results o" their !or/.

$ $


33/134


%&a'ples $( Architectural atterns ) -lac7b$ard*) $orces+equence in !hich /no!ledge agents can contri ute to sol#ing thepro lem is not deterministic and may depend on pro lem sol#ingstrategies. 'nput "rom di""erent agents results or partial solutions)may ha#e di""erent representations. Agents do not /no! o" eachotherBs existence directly ut can e#aluate each otherBs posted

contri utions-) +olutionA num er o" no!ledge Agents ha#e access to a shared data storecalled the lac/ oard. (he lac/ oard pro#ides an inter"ace to

inspect and update its content. (he Control module>o


34/134


%&a'ples $( Architectural atterns ) -lac7b$ard


35/134

$l i$ $( A hi l 8 $


36/134


,es$luti$n $( Architectural 8act$rsBecording Architectural Alternati!es, Decisions,and 6oti!ation ( technical memos C ample o% *echnical 6emo

D i *$d l O i


37/134


Design *$del Overview

Dse case reali,ation

Special Applicationlayer--

General Applicationlayer--

General Serviceslayer--

Syste) Serviceslayer--

Layered Architecture

Architecture echanism

6esign odel

Dse case

se case report

Glossary

Supple)entarySpecification

5equirement odel

" h i l * '$


38/134


"echnical *e'$ All architectural methods recommend 8eeping arecord o% alternati!e solutions, decisions, in%luential%actors, and moti!ations %or the note+orthy issues anddecisions-"uch records ha!e been called technical memos ,issue cards, and architectural approach documents,+ith !arying degrees o% %ormality and sophistication-

In some methods, these memos are the basis %or yetanother step o% re!ie+ and re%inement-

In the =$, the memos should be recorded in the "AD-

An important aspect o% the technical memo is themoti!ation or rationale-C plaining the rationale o% rejecting the alternati!es isimportant-

%& ' l $( " h i l * '$


39/134


%&a'ple $( "echnical *e'$

A hi l 9 ($ ' i$ i h U A i(


40/134


Architectural 9n($r'ati$n in the U Arti(acts *he architectural decisions are recorded in the

"AD #Software Architecture Document$ -*his includes the technical memos anddescriptions o% the architectural !ie+s-


41/134


42/134


"(entify Design #le)ents


43/134

9d ti( D ig %l ' t


44/134


9denti(y Design %le'ents

classes& to represent a set o% rather %ine(grainedresponsibilities@subsystems , to represent a set o% coarse(grainedresponsibilities, perhaps composed o% a %urther set o%subsystems, but ultimately a set o% classes@active classes , to represent threads o% control in thesystem@interfaces& to represent abstract declarations o%responsibilities pro!ided by a class or subsystem-

analysis classes represent conceptual things which can perfor)*ehavior."n (esign, analysis classes evolve into a nu)*er of (ifferent0in(s of (esign ele)ents1


45/134

ac7ages versus ubsyste's


46/134

Object Oriented Analysis and Design 4)Encapsulation is the key!

ac7ages versus ubsyste's"ubsystems

$ro!ide beha!ior &ompletelyencapsulate theircontents

Are easily replaced

Su*syste) Asu*syste)--

ac0age $!lass$2

!lass$3

!lient !lass

ac0agesDon4t provi(e*ehaviorDon4t co)pletely

encapsulate theircontentsMay not *e easilyreplace(

ubsyste' e&a'ple


47/134


ubsyste' e&a'ple

9denti(ying ubsyste's


48/134


5Super)an !lass6

9denti(ying ubsyste s&lassA

D./E./

789:89

"nterface--

Su*syste) ;su*syste)--

%&a'ple Design ubsyste's and 9nter(aces


49/134


Analysis Design

%&a ple Design ubsyste s and 9nter(aces

illing"ystem

FFsubmit bill./

::boundary;; $illing Syste)su*syste)--

"$illingSyste)

su*)it$ill8forTuition 1 Dou*le, forStu(ent 1 Stu(ent9

!ourse!atalogSyste)


50/134


Interfaces start with an “I”

package

class

*$deling C$nventi$n ubsyste s and 9nter(aces

!ourse!atalogSyste)

su*syste)--

"!ourse!atalogSyste)

!ourse!atalogSyste)

get!ourseOfferings89initiali/e89

su*syste) pro=y--


get!ourseOfferings8forSe)ester 1 Se)ester, forStu(ent 1 Stu(ent9 1 !ourseOfferingListinitiali/e89

8a:ade in subsyste'


51/134


8a:ade in subsysteFor subsystems, the most common pattern o% access isFacade, a >oF design pattern-

a public %acade object de%ines the ser!ices %or the subsystem,and clients collaborate +ith the %acade, not internalsubsystemcomponents

*he Facade pattern is commonly used %or do+n+ardcollaboration %rom a higher to a lo+er layer, or %oraccess to ser!ices in another subsystem o% the samelayer- *he %acade should not normally e pose many lo+(le!eloperations-

Bather, to e pose a small number o% high(le!el operationsGthe coarse(grained ser!ices-

A %acade does not normally do its o+n +or8-Bather, it is consolidator or mediator to the underlyingsubsystem objects, +hich do the +or8-


52/134


53/134


Organi/ing the Design Mo(el ac0ages

eview What 9s a ac7age!


54/134


A pac8age is a general purpose mechanism %ororganizing elements into groups-

It is a model element that can contain other modelelements-

A pac8age can be used*o organize the model under de!elopment-

As a unit o% con%iguration management-

,eview What 9s a ac7age!

niversityArtifacts

ac7age elati$nships Dependency


55/134


$ac8ages can be related to one another usinga dependency relationship

Dependency ImplicationsH &hanges to the "upplier pac8age may a%%ect the &lient pac8ageH *he &lient pac8age cannot be reused independently because it

depends on the "upplier pac8age

ac7age ,elati$nships Dependency

!lient ac0age Supplierac0age

Depen(ency relationship

Av$iding Circular Dependencies


56/134


!

A

$

Hierarchyshould beacyclic

A

$

!

A>

ircular dependencies make it impossible to reuse one

package without the other

Av$iding Circular Dependencies

A

$


57/134

ac7aging "ips 8uncti$nally elated Classes


58/134


ac7aging ips 8uncti$nally ,elated Classes&riteria %or determining i% classes are %unctionallyrelated

&hanges in one classJ beha!ior and or structure necessitate changes inanother classBemo!al o% one class impacts the other class*+o objects interact +ith a large number o% messages or ha!e acomple intercommunication

A boundary class can be %unctionally related to a particular entity class i%the %unction o% the boundary class is to present the entity class*+o classes interact +ith, or are a%%ected by changes in the same actor*+o classes ha!e relationships bet+een each other One class creates instances o% another class

&riteria %or determining +hen t+o classes should NOT be placed in the same pac8age*+o classes that are related to di%%erent actors should not be placed inthe same pac8age

An optional and a mandatory class should not be placed in the samepac8age

ac7age Dependencies ac7age %le'ent Visibility


59/134


ac0age$

ac0ageA

ublic "isibility

ri"ate "isibility

#nly public classescan be referencedoutside of the owning package

OO Principle: Encapsulation

ac7age Dependencies ac7age %le ent Visibility

A

$

!lass A2

!lass A3

!lass A?

&!lass $2

@!lass $3

ac7age C$upling "ips


60/134

Object Oriented Analysis and Design )9

A

$ $ $

ac7age C$upling ips

$ac8ages should

not be cross(coupled$ac8ages in lo+erlayers should not bedependent uponpac8ages in upperlayersIn general,dependenciesshould not s8iplayers

A $

$ $ pper

Layer

LowerLayer

!

$ $

$ $ !oupling violation

*$st esp$nsible Are *$st table


61/134


$st ,esp$nsible Are $st table

8act$r $ut 9ndependent "ypes


62/134


8act$r $ut 9ndependent ypes

Use 8act$ries t$ ,educe Dependency $n C$ncrete ac7ages


63/134


$ $ , p y $ $ g


64/134


65/134


66/134

Object Oriented Analysis and Design ))

Su*syste) Design

5.6 ubsyste' Design teps


67/134


5.6 ubsyste Design teps"ubsystem Design O!er!ie+

"ubsystem >uidelines"ubsystem Design "teps&hec8points


68/134

ubsyste' Design ) urp$se


69/134

Object Oriented Analysis and Design )

y g ) p$-o define the behaviors specified in thesubsystem6s interfaces in terms ofcollaborations of contained classes -o document the internal structure of thesubsystem -o define reali"ations between thesubsystem6s interfaces and containedclasses -o determine the dependencies uponother subsystems

,eview ubsyste's and 9nter(aces


70/134


A "ubsystemK

Is a Lcross bet+eenM a pac8age and a classBealizes one or more inter%aces +hich de%ineits beha!ior

su*syste)--Su*syste) 'a)e

Interface%ubsystem

su*syste)--Su*syste) 'a)e"nterface

&eali'ation ( anonical form)

&eali'ation (Elided form )

interface--"nterface

, y (

ubsyste' 0uidelines


71/134


*ey is abstraction and encapsulation

Asu*syste)--

$su*syste)--

!su*syste)--

y>oals

oose coupling$ortability, plug(and(play compatibilityInsulation %rom changeIndependent e!olution

"trong "uggestionsDonNt e pose details, only inter%acesOnly depend on other inter%aces

,eview *$deling C$nventi$n ($r ubsyste's and 9nter(aces


72/134


!ourse!atalogSyste)

su*syste)--



!ourse!atalogSyste)su*syste) pro=y--

!ourse!atalogSyste)su*syste)--Interfaces start with an “I”

package

class

ubsyste' Design teps


73/134


y g pDistribute subsystem beha!ior tosubsystem elementsDocument subsystem elementsDescribe subsystem dependencies

ubsyste' ,esp$nsibilities


74/134


!ourse!atalogSyste)su*syste)--"!ourse!atalogSyste)

get!ourseOfferings89

interface--

subsystem responsibility

y , p"ubsystem responsibilities de%ined byinter%ace operations

6odel inter%ace realizations

Inter%ace operations may be realized byInternal class operationsInternal subsystem operations

Distributing ubsyste' ,esp$nsibilities


75/134


g y , pIdenti%y ne+, or reuse e isting, design elements .e-g-,classes and or subsystems/

Allocate subsystem responsibilities to design elementsIncorporate applicable mechanisms .e-g-, persistence,distribution, etc-/Document design element collaborations in Linter%acerealizationsM

One or more interaction diagrams per inter%aceoperation&lass diagram.s/ containing the re#uired designelement relationships

Be!isit L Identify Design lements M Adjust subsystem boundaries and or dependencies,as needed

ubsyste' Dependencies 0uidelines


76/134


"ubsystem dependency on a subsystem

"ubsystem dependency on a pac8age

y p

+lexible,referred

Server

!lient Supportsu*syste)--

Server Supportsu*syste)--

-se with care!lient Support

su*syste)-- SupportingTypes


77/134


se !ase Design

5.< Use Case Design


78/134


g =se &ase Design O!er!ie+

=se &ase Design "teps


79/134

Use Case Design ) urp$se


80/134


-o refine use3case reali"ations in terms ofinteractions -o refine re%uirements on the operationsof design classes

-o refine re%uirements on the operationsof subsystems and7or their interfaces.

Use)Case Design teps


81/134


Describe interaction bet+een design objects

"impli%y se#uence diagrams using subsystemsDescribe persistence related beha!ior Be%ine the %lo+ o% e!ents description

=ni%y classes and subsystems


82/134


!lass Design

5.5 Class Design


83/134


&reate Initial Design &lasses

De%ine OperationsDe%ine 6ethodsDe%ine "tates

De%ine AttributesDe%ine DependenciesDe%ine Associations

Class Design C$nsiderati$ns


84/134


&lass stereotypeoundary

Cntity&ontrol

Applicable design patterns Architectural mechanisms

$ersistenceDistributionetc-


85/134


86/134

trategies ($r Designing %ntity Classes


87/134


Analysis

+at!lassLa/yDataHelper0rarely se(Att?0rarely se(AttC

Design

+at!lass0transient$oo0eeping

& get!o))only se(Att289& get!o))only se(Att389& get%arely se(Att?89& get%arely se(AttC89

+at!lassDataHelper0co))only se(Att20co))only se(Att3

2 2

+at!lass@ transient$oo0eeping0co))only se(Att20co))only se(Att30rarely se(Att?0rarely se(AttC

entity --

Cntity objects are o%ten passi!e and persistent$er%ormance re#uirements may %orce some re(%actoring"ee Identi%y $ersistent &lasses step

trategies ($r Designing C$ntr$l Classes


88/134

Object Oriented Analysis and Design


89/134

/a'e and Describe the Operati$ns


90/134


Appropriate operation namesIndicate the outcome=se client perspecti!e&onsistent across classes

De%ine operation signaturesoperation'ame.parameter K class,--/ Kreturn*ype

$ro!ide short description, including

meaning o% all parameters

0uidelines Designing Operati$n ignatures


91/134



92/134


u*licoperations

rotecte(operations

rivate operations

7isibility is used to en%orce encapsulation

6ay be public, protected, or pri!ate


93/134

c$pe


94/134


!lass@ classifierScopeAttri*ute

classifierScopeOperation89

@ instanceScopeAttri*ute

instanceScopeOperation89

Determines number o% instances o% theattribute operation

InstanceK one instance %or each class instance&lassi%ierK one instance %or all class instances

&lassi%ier scope is denoted by underlining theattribute operation name

%&a'ple c$pe


95/134


Stu(ent

@ na)e@ a((ress

@ ne=tAvail"D 1 int

& a((Sche(ule8theSche(ule 1 Sche(ule, forSe)ester 1 Se)ester9& getSche(ule8forSe)ester 1 Se)ester9 1 Sche(ule& has rereEuisites8for!ourseOffering 1 !ourseOffering9 1 *oolean

passe(8the!ourseOffering 1 !ourseOffering9 1 *oolean& get'e=tAvail"D89 1 int

entity--

@ stu(ent"D

%&a'ple De(ine Operati$ns


96/134

Object Oriented Analysis and Design )

!ourseOffering8fro) niversity Artifacts9

entity--

Stu(ent .

& getTuition89 1 (ou*le& a((Sche(ule8theSche(ule 1 Sche(ule9

& getSche(ule8forSe)ester 1 Se)ester9 1 Sche(ule& (eleteSche(ule8forSe)ester 1 Se)ester9& has rereEuisites8for!ourseOffering 1 !ourseOffering9 1 *oolean

passe(8the!ourseOffering 1 !ourseOffering9 1 *ooleanclass-- & get'e=tAvail"D89 1 int

& getStu(ent"D89 1 int& get'a)e89 1 string& getA((ress89 1 string

8fro) niversity Artifacts9

entity--

%egistration!ontroller

& su*)itSche(ule89& saveSche(ule89& get!ourseOfferings89 1 !ourseOfferingList& get!urrentSche(ule8forStu(ent 1 Stu(ent, forSe)ester 1 Se)ester9 1 Sche(ule& (elete!urrentSche(ule89

class-- & new8forStu(ent 1 string9& getStu(ent8with"D 1 string9 1 Stu(ent

8fro) %egistration9

control--

Sche(ule8fro) niversity Artifacts9

entity--

F..2

F..2&registrant

F..

2

F..2

F..2

&currentSche(ule

F..

F..

&pri)ary!ourses

F..C

&alternate!ourses

F..3


& get!ourseOfferings89

& initiali/e89

8fro) #=ternal Syste) "nterfaces9

"nterface--

2F..

De(ine *eth$ds


97/134



98/134


$urposeDesign ho+ an objectNs state a%%ects its beha!ior De!elop statecharts to model this beha!ior

*hings to consider K


99/134


State 'a)e

state ar 1 type value

entry< entry action(o< activitye=it< e=it action

event8args9Iguar( con(ition< operation8args9 Ktarget.sen(#vent8args9

%tate E"ent

1ransition

.ction

.cti"ity

A directed graph o% states .nodes/ connectedby transitions.directed arcs/Describes the li%e history o% a reacti!e object

pecial tates


100/134


Initial state*he state entered +hen an object is created6andatory&an only ha!e one initial state

Final stateIndicates the objectNs end o% li%eOptional6ay ha!e more than one +inal state

"nitial state


101/134


102/134

9denti(y the "ransiti$ns


103/134


nassigne(

Assigne(

re)ove rofessor

a(( rofessor

For each state, determine +hat e!ents cause transitionsto +hat states, including guard conditions, +hen needed

*ransitions describe +hat happens in response to thereceipt o% an e!ent

!ourseOffering2 add rofessor()2 remo"e rofessor()

entity--

F..

&instructorrofessorentity--F..2

Add Activities and Acti$ns


104/134


Acti!ities Associated +ith a state"tart +hen the state is entered*a8e time to completeInterruptible

Actions Associated +ith a transition*a8e an insigni%icant amount o% time to complete

'on(interruptible

State A

State $(o1 activity

eventI con(ition < action

State !acti"ity

action

entry1 action

%&a'ple tatechart


105/134


a(( stu(ent < nu)Stu(ents nu)Stu(ents & 2

nassigne(

Assigne(

+ull

!ancelle((o1 Sen( cancellation notices

!o))itte(

(o1 Generate class roster

close%egistration I has rofessor assigne(

close

< nu)Stu(ents F

a(( rofessor

close%egistration

re)ove stu(ent < nu)Stu(ents nu)Stu(ents @ 2

cancel

re)ove rofessor

I nu)Stu(ents 2F

closeI nu)Stu(ents ?

close%egistrationI nu)Stu(ents - ?

closeI nu)Stu(ents - ?

a(( stu(ent <

nu)Stu(ents nu)Stu(ents & 2

cancel

re)ove stu(ent < nu)Stu(ents nu)Stu(ents @ 2

close

I nu)St u(ents 2F cancel

%&a'ple tatechart With /ested tates and =ist$ry


106/134


superstate

substate

a(( stu(ent


107/134


Objects +hose role is clari%ied by statetransitions&omple use cases that are state(controlledIt is not necessary to model all objects

Objects +ith straight%or+ard mapping toimplementationObjects that are not state(controlledObjects +ith only one computational state

=$w D$ tatecharts *ap t$ the ,est $( the *$del!


108/134


Open +ull

a(( stu(ent <nu)Stu(ents nu)Stu(ents & 2

Inu)Stu(ents 2F

!ourseOffering

$u 8ind "he'!


109/134


C amine method descriptionsC amine states

Any in%ormation the class itsel% needs tomaintain

Attribute ,epresentati$ns" i% d i l d % l ! l


110/134


"peci%y name, type, and optional de%ault !alueattribute'ame K *ype R De%ault

Follo+ naming con!entions o% implementationlanguage and project*ype should be an elementary data type inimplementation language

uilt(in data type, user(de%ined data type, oruser(de%ined class"peci%y !isibility

$ublicK SPN

$ri!ateK S(N$rotectedK SQN

Derived Attributesh d d b


111/134



112/134

h I D d

De(ine Dependency


113/134



114/134


Associations are structural relationshipsDependencies are non(structuralrelationshipsIn order %or objects to L8no+ each otherMthey must be !isible

ocal !ariable re%erence$arameter re%erence>lobal re%erence

Field re%erence .ssociation!lientSupplier2

Supplier3

3ependency

Ass$ciati$ns vs. Dependencies in C$llab$rati$nsA i % i i i li 8


115/134


An instance o% an association is a lin8 All lin8s become associations unless they ha!eglobal, local or parameter !isibility&onte t dependent relationship

Dependencies are transient lin8sa!e a limited duration

&onte t independent relationship"ummary relationship


116/134

%&a'ple De(ine Dependencies 3be($re" f


117/134



& get!ourseOfferings8forSe)ester 1 Se)ester9 1 !ourseOfferingList


"nterface--

Stu(ent

@ na)e@ a((ress@ Stu(ent"D 1 int


passe(8the!ourseOffering 1 !ourseOffering9 1 *oolean


entity--


&


118/134


4lobal "isibility

arameter "isibility


& get!ourseOfferings8forSe)ester 1 Se)ester9 1 !ourseOfferingList


"nterface--

Stu(ent

@ na)e@ a((ress@ Stu(ent"D 1 int


passe(8the!ourseOffering 1 !ourseOffering9 1 *oolean


entity--


&


119/134


$urposeBe%ine remaining associations

*hings to loo8 %or K Association !s- Aggregation Aggregation !s- &omposition Attribute !s- Association'a!igability

Association class design

6ultiplicity design

What is C$'p$siti$n!A % % gg g ti +ith t g


120/134


Bhole art

7hole

Composition

Part

A %orm o% aggregation +ith strongo+nership and coincident li%etimes

*he parts cannot sur!i!e the +hole aggregate

Aggregati$n hared Vs. /$n)shared


121/134


"hared Aggregation

'on(shared Aggregation

5y definition, composition is non0shared aggregation

Bhole art2.. F..

6ultiplicity > 7

6ultiplicity 8 7 6ultiplicity 8 7

2Bhole art2 F.. Bhole artF..

omposition

Aggregati$n $r C$'p$siti$n!&onsideration


122/134


aggregation

composition

!lass2

!lass2

!lass3

!lass3

&onsiderationi%etimes o% &lass1 and &lass2

%&a'ple C$'p$siti$n


123/134


Stu(ent Sche(ule2 F..

2 2 %egister+or!ourses+or) %egistration!ontroller

Attributes Vs C$'p$siti$n=se composition +hen


124/134


=se composition +hen$roperties need independent identities6ultiple classes ha!e the same properties$roperties ha!e a comple structure andproperties o% their o+n

$roperties ha!e comple beha!ior o% their o+n$roperties ha!e relationships o% their o+n

Other+ise use attributes

%&a'ple Attributes Vs C$'p$siti$n


125/134


omposition ofseparate class

.ttributes

F..22

Stu(ent@ na)e@ a((ress

classifier scope-- @ ne=tAvail"D 1 int@ Stu(ent"D 1 int@ (ateof$irth 1 Date

& a((Sche(ule89& getSche(ule89& (elete sche(ule89& has rereEuisites89

passe(89

entity--

Sche(ule

& su*)it89&


126/134


127/134


128/134

6ultiplicity R 1 or 6ultiplicity R 9--1*ultiplicity Design


129/134


6ultiplicity R 1, or 6ultiplicity R 9--16ay be implemented directly as a simple!alue or pointer 'o %urther LdesignM is re#uired

6ultiplicity ; 1&annot use a simple !alue or pointer Further LdesignM may be re#uired

F..F..2

instructor !ourseOfferingrofessor

F..F..2

instructor9eeds acontainer

rofessor !ourseOffering

*ultiplicity Design Opti$nsC plicit modeling o% a container class


130/134


C plicit modeling o% a container class

'ote

instructorrofessor !ourseOffering

F..F..2

!ourseOfferingentity--

rofessorentity--

!ourseOfferingList

& new89& a((89

2

F..

F..2F..2

&instructor

!ourseOffering

F..F..2

instructor

List

rofessor

What is a ara'eteri;ed Class 3te'plate !A class de%inition +hich de%ines other


131/134


"te)

Listara)eteri/e(

!lass

+or)alargu)ents

A class de%inition +hich de%ines otherclassesO%ten used %or container classes

"ome common container classesKH"ets, lists, dictionaries, stac8s, #ueues, T

9nstantiating a ara'eteri;ed Class


132/134


"nstantiate( !lass actual argu)ents-

*in(-- actual argu)ents-

ara)eteri/e(!lass

+or)alargu)ents

"nstantiate( !lass

O%

Implicit bindingExplicit binding

%&a'ple 9nstantiating a ara'eteri;ed Class


133/134


!ourseOfferingentity--

!ourseOfferingList2 F..

5efore

.fter

*in(-- !ourseOffering-

List

"te)

!ourseOfferingList !ourseOffering

List !ourseOffering- !ourseOfferingO%

*ultiplicity Design Opti$nalityI% a lin8 is optional ma8e sure to include an


134/134

!ourseOfferingrofessor

isTeaching8 9 1 $oolean F..2 F.. has"nstructor8 9 1 $oolean

I% a lin8 is optional, ma8e sure to include anoperation to test %or the e istence o% the lin8

Chap 5 - Object Oriented Design

Documents

Transcript of Chap 5 - Object Oriented Design