2 OO Design Process Student

7/24/2019 2 OO Design Process Student

http://slidepdf.com/reader/full/2-oo-design-process-student 1/106

The Object-Oriented

Design Process

Ch2



Chapter Topics

Part I• From Problem to Code• The Object and Class Concepts• Identifying Classes• Identifying Responsibilities

• Relationships Between Classes

Part II• Use Cases• CRC Cards• U! Class "iagrams

• #e$%ence "iagrams• #tate "iagrams• Using ja&adoc for "esign "oc%mentation

Part III

• Case #t%dy' ( )oice ail #ystem



From Problem to Code

• Three Phases' – *+, (nalysis

– *2, "esign

– *-, Implementation

• Case #t%dy' )oice ail #ystem

Problem.nd

prod%ct

Programming tas/s originatefrom the desire to sol&e apartic%lar problem

The end prod%ctis a wor/ingprogram0



(1) Analysis Phase

• ( &ag%e %nderstanding of the problem is transformedinto a precise description of the tas/s that the softwaresystem needs to carry o%t0

• 1oal of this phase' – ( complete description of what the software prod%ct sho%ld

be0• Res%lts of this phase

– ( detailed tet%al description3 called functional specication

• F%nctional speci4cation characteristics' – Completely de4nes tas/s to be sol&ed

– Free from internal contradictions – Readable both by domain eperts and software de&elopers – Re&iewable by di&erse interested parties – Testable against reality



.ample

• ( word5processing program• "e4ne terms

– .0g03 fonts3 footnotes3 m%ltiple col%mns3

• "e4ne interaction of those feat%res

– .0g03 how footnotes in m%ltiple5col%mn tet o%ght toloo/ on the screen0

• "oc%ment the %ser interface – .0g03 how the %ser is to enter and mo&e a footnote

• "escribe the beha&ior of a system

– I0e03 a se$%ence of actions that yields a bene4t for%ser

– Use 6Use Cases7



8ote

• The analysis phase concerns itself with thedescription of 9:(T needs to be done3 not :O9it sho%ld be done0 – The selection of speci4c algorithms3 s%ch as those that

insert page brea/s or sort the inde3 will be handled inthe 6implementation phase7

• It is possible to %se OO techni$%es in the analysisphase as well as the design phase

– (d&' the object model of the analysis phase can becarried forward to the design phase0

– Pitfall' c%stomers of a software prod%ct are generallynot familiar with the terminology of object orientation



(2) Design Phase

• The program designer m%st str%ct%re theprogramming tas/s into a set of interrelatedclasses

• 1oals

– Identify the classes – Identify the responsibilities of these classes – Identify the relationships among these classes

• In practice – The abo&e are goals3 not steps0

– Us%ally not possible to 4nd (!! classes 4rst3 thengi&e a COP!.T. description of their responsibility3then elaborate CORR.CT!; on their relationship

– The disco&ery process is iterati&e• The identi4cation of one aspect of a class may force

changes in or lead to the disco&ery of others



(2) Design Phase

• (rtifacts – Tet%al description of classes and /ey

methods

– "iagrams of class relationships – "iagrams of important %sage scenarios

– #tate diagrams for objects with rich state

• Typically3 this phase is more time5

cons%ming than the act%al programming – ( good design greatly red%ces the time

re$%ired for implementation and testing



8ote

• The designer m%st stri&e for a res%lt inwhich

– the classes are crisply de4ned and class

relationships are of manageable compleity0• The eact choice of data str%ct%re is not

concern

– .0g03 hash tables or binary search trees for acollection

– It is deferred %ntil implementation



() !mplementationPhase

• 1oal – Classes and methods are coded3 tested3 and deployed

• (&oid <big bang< integration – Few program are born according to plan o%t of a

s%ccessf%l 6big bang7 integration – OO de&elopment enco%rages the grad%al growth of aprogram

• by s%ccessi&ely attaching more wor/ing classes and classcl%sters and repeated testing0

• Prototypes can be &ery %sef%l

– ( prototype is &ery helpf%l in in=%encing the design ore&en the problem analysis

– OO design is partic%larly s%ited for prototyping0• The objects s%pporting the prototype are li/ely to be the

same that need to be present in the 4nal prod%ct



Object and ClassConcepts

• Object' Three characteristic concepts

– *+, #tate

– *2, Beha&ior

– *-, Identity

• Class'

– ( class describes a collection of similar

objects – They s%pport a common set of operations

– They ha&e a common set of possible states0



*+, #tate

• #tate – (n object can store information that is the res%lt of its

prior operations

– The collection of all information held by an object>theobject’s state

– The state may determine how the object beha&es in thef%t%re0

• .ample' a mailbo in a &oice mail system

– ( mailbo object may be in an empty state or f%ll0

– This state a?ects the beha&ior of the mailbo object0 .0g03• a f%ll mailbo may reject new mail message3 or

• a empty mailbo may gi&e a special response *6no messagewaiting7,



*2, Beha&ior

• Behavior of an object

– "e4ned by the operations that an objects%pports

– I0e03 objects only permit certainoperations *not others,

– .0g03 a mailbo object can add a

message to its collection b%t not encryptit0



*-, Identity

• Possible for two or more objects to

– s%pport the same operations and

– ha&e the same state3

– ;et to be di?erent from each other0

• #o3 each object has its own identity

• .ample

– Two di?erent mailboes may3 by chance3ha&e the same contents3 yet the programcan tell them apart0



Reminder

• 1oals of "esign Phases

– Identify the classes

– Identify the responsibilities of theseclasses

– Identify the relationships among theseclasses



!denti"ying Classes

#tep +

• R%le of th%mb' !oo/ for nouns in problemdescription *or the f%nctional speci4cation, – 9hich phase prod%ces the f%nctional speci4cation@

• .ample' )oice mail system' – ailbo

– essage

– User

– Passcode

– .tension

– en%

– any3 b%t not necessarily all of them3 are good choices

for classes



!denti"ying Classes

• Class name

– #ing%lar no%n'

• e0g03 essage3 ailbo

– (djecti&e pre4ed'• e0g03 Rectang%lar#hape3 B%?eredReader

– #tay away from too generic names'

• e0g03 Tas/3 Item3 User

– On the wrong trac/ if naming classes after&erbs'

• e0g03 PrintingReport3 "oTas/



!denti"ying Classes

#tep 2

• T%rn yo%r attention to other classes that arere$%ired to carry o%t necessary wor/3

– after har&esting the classes that are ob&io%s from thespeci4cation0

• .ample' )oice mail system'

– #toring messages in a mailbo in a FIFO fashion

– essageA%e%e *with FIFO beha&ior, is s%ggested

• Foc%s on concepts

– The eact implementation of the $%e%e is of nointerest in design phase0



!denti"ying Classes

#tep -

• !oo/ at di?erent categories of classes formore identi4cation'

– *i, Tangible Things – *ii, (gents

– *iii, .&ents and Transactions

– *i&, Users and Roles

– *&, #ystems

– *&i, #ystem interfaces and de&ices

– *&ii, Fo%ndational Classes



!denti"ying Classes

• *i, Tangible Things

– They are the easiest classes to disco&er asthey are &isible in the problem domain0

• *ii, (gent classes – #ometimes it is helpf%l to change an operation

into an agent class

– (gent classes of then end in 6er7 or 6or70

– .0g03 the 6comp%te page brea/s7 operationco%ld be t%rned into a Paginator class0

– .0g03 Scanner and Iterator



!denti"ying Classes

• *iii, .&ent and Transaction classes

– They are %sef%l to model records of acti&ities

• that describle what happened in the past or what needs to bedone later

– .0g03 the MouseEvent class remembers when and wherethe mo%se was mo&ed or clic/ed

• *&i, User and Role classes

– They are stand5ins for act%al %sers of the program

– .0g03 (n Administrator class is a representation of theh%man administrator of the system0

– ( Reviewer class models a %ser whose role is to addcritical annotations and recommendations for changes



!denti"ying Classes

• *&, #ystem classes

– Their roles are typically• to perform initialiation and sh%tdown

• to start the =ow of inp%t into the system

• *&i, #ystem interface classes – They model interfaces to the host operating system3 a

database3 and so on0

– .0g03 the File class

• *&ii, Fo%ndation classes – .0g03 #tring3 "ate3 or Rectangle

– (t the design stage3 simply ass%me that these classesare readily a&ailable0



!denti"ying#esponsibilities

• R%le of th%mb' !oo/ for verbs in problemdescription

• .ample' &oice mail system

– essages are recorded3 played3 and deleted

– Users log in

– Passcodes are checked0

• (fter disco&ering a responsibility3 yo%m%st 4nd one *and only one, class thatowns that responsibility



!denti"ying#esponsibilities

• 9hen disco&ering responsibility3 commonly ma/ewrong g%esses

– .ample' (dd message to mailbo

– Is the responsibility of the Message or Mailbox class@

– Message is not a good idea0• Thin/ how a message perform the responsibility0

• In order to add itself to a mailbo3 the message needs to /nowthe internal str%ct%re of the Mailbox3 e0g03 array or lin/ list0 B%twe always ass%me that those details sho%ld be pri&ate toMailbox class3 and that Message class has no insight into them0

• :elpf%l to ha&e more than one person in&ol&ed

– If one assigns a responsibility to a class3 another canas/ hard $%estions



Class #elationships

• *+, "ependency *<%ses<,

• *2, (ggregation *<has<,

• *-, Inheritance *<is<,



(1) Dependency ($%ses&)

• C depends on D' If C *its method,manip%lates objects of D

– .ample' Mailbox depends on Message

• If C doesn't use D3 then C can bede&eloped witho%t /nowing abo%t D

– .ample' Message does not %se Mailbox

• (s shown3 dependency is an

asymmetric relationship



Co%pling

• To minimie dependency' red%cecoupling

– It is one important design goal

• 9hy @@@



Co%pling• .ample'

– public class Message

{

void print! {S"stem#out#printlntext!$%

# # #

%

– The method prints the message to S"stme#out#

• #o3 Message is co%pled with both S"stme and PrintStream

– If the class is deployed in an embedded de&ice or others inthat there is no S"stme#out3 changes need to be made0

• Better to ha&e a method' – public String get&ext!

– It is %p to some other part of the system to send theret%rned string to S"stme#out3 to a dialog bo3 to a log 4le3or to other contet0



(2) Aggregation ($has&)

• C aggregates "' if its objects contain objectsof "

• .ample' essageA%e%e

– essageA%e%e has essages objects – #o3 we say that the essageA%e%e class

aggreates the essage class

• (ggregation is a special case of dependency

– beca%se if a class contains objects of anotherclass3 then it is ac%tely aware of the eistence ofthat class



'%ltiplicities

• Informally described as the 6has5a7 relationship0• There may be a +'+ or +'E000n relationship'

• .0g03' ( mailbo has one greeting *+'+,

• p%blic class ailbo

0 0 0pri&ate 1reeting my1reetingG

• .0g03' ( message $%e%e may has many

messages *+'n,• p%blic class essageA%e%e

0 0 0pri&ate (rray!istHessage elements

G



() !nheritance ($is&)

• ore general class > superclass• ore specialied class > subclass• #%bclass inherits from s%perclass

• #%bclass s%pports all method interfaces ofs%perclass *b%t implementations may di?er,• #%bclass may ha&e added methods3 added

state

• .ample'

• ( forwarded message is a message0• ForwardedMessage inherits from Message • 'reeting does not inherit from Message *CanJt

store greetings in mailbo,



Three goals?

Three phases?

#%mmary

From problem to code

Theirresponsibil

ities

Indentifyclasses

Theirrelationshi

ps

K+0 "ependency *<%ses<,K20 (ggregation *<has<,K-0 Inheritance *<is<,

K)erbs in thespeci4cation3 etc

K8o%ns in thespeci4cation3 etc

(nalysis "esignImplementat

ion



Part II



se Cases

• (n (nalysis techni$%e• To describe how a system sho%ld wor/

*formally,

• .ach use case foc%ses on a speci4c scenario• > a se$%ence of actions necessary to bring it to

s%ccessf%l completion

• .ach action> an interaction between theactors and the system• (ctors > people or entities o%tside the system

• .ach action yields a result •

.ach res%lt has a &al%e to one of the actors

• ost scenarios that potentially deli&er a&al%able o%tcome can fail for some reasons• Use variations for eceptional sit%ations



se Cases

( #ystem

#cenario +

#cenario 2

#cenario N

.

.

.

A System

Use Case +

Use Case 2

Use Case 8

.

.

.

Action1 Action2 . . . ActionN



interactionbetween the actors

and the system



se Cases

• )oicemail system

• any scenarios' – 6!ea&e a message73 6Retrie&e message73 etc

• The %se case 6!ea&e a message7

– "escribe the steps that a caller m%st ta/e to dial an etensionand lea&e a message

– (ctor > @@@

– )al%e to the caller > the message is deposited in theappropriate mailbo

• The %se case 6Retrie&e message7 – "escribe the steps needed to listen to the messages in the

mailbo0

– actor >@@@

the caller leaving a message

the mailbox owner



ample se Case

*ea+e a 'essage+0 Caller dials main n%mber of &oice mail system20 #ystem spea/s prompt

.nter mailbo n%mber followed by L

-0 User types etension n%mberM0 #ystem spea/s

;o% ha&e reached mailbo 0 Please lea&e amessage now

N0 Caller spea/s message0 Caller hangs %p0 #ystem places message in mailbo

Variation Here

Variation Here



ample se Case --,ariations

• ,ariation 1• +0+0 In step -3 %ser enters in&alid etension

n%mber

• +020 )oice mail system spea/s 6;o% ha&e typed

an in&alid mailbo n%mber07• +0-0 Contin%e with step 20

• ,ariation 2• 20+0 (fter step M3 caller hangs %p instead of

spea/ing message• 20-0 )oice mail system discards empty message



C#C Cards

• CRC > Classes3 Responsibilities3Collaborators

• (n e?ecti&e design techni$%e for – disco&ering classes3 responsibilities3 andrelationships

– Proposed by Qent Bec/ and 9ard C%nningham3

6( !aboratory for Teaching Object5Oriented Thin/ing73OOP#!( S Conference3 Oct +53 +S0



C#C Cards

• ( CRC card > an inde card for a class' – Class name *top,

– Responsibilities *left,

– Collaborators *right,'• Other classes that need to collaborate with so that it can f%l4ll its

responsibilities



C#C Cards• 9hy inde cards@

– #mall• "isco%rage yo% from piling too m%ch responsibility into a single class

– !ow5tech• #o they can be %sed by gro%ps of designers gathered aro%nd a table

– R%gged than sheets of paper• Can be handed aro%nd and rearranged d%ring brainstorming sessions0



C#C Cards

• Responsibilities sho%ld be high level

– "O8T write indi&id%al methods

• + 5 - responsibilities per card

– 9hat yo% sho%ld do if a class has moreresponsibilities than yo% can 4t on the card@

• Collaborators are for the class3 not for eachresponsibility0

– #imply list collaborators as yo% disco&er them3witho%t regard for the ordering

!a"e two new cards# distrib$te the responsibilities

among them# and tear $p the old card.



.al/thro%ghs

• CRC cards are int%iti&e for 6wal/ingthro%gh7 %se cases'

• Use case' <!ea&e a message<

– Caller connects to &oice mail system – Caller dials etension n%mber

• <#omeone< m%st locate mailbo

• 8either Mailbox nor Message can do this• 8ew class' MailS"stem

• Responsibility' manage mailboes



.al/thro%ghs

• CRC cards are int%iti&e for 6wal/ing thro%gh7 %se cases'

• .ample'

*ea+e a 'essage+0 Caller dials main n%mber of &oice

mail system20 #ystem spea/s prompt

.nter mailbo n%mber followedby L


6;o% ha&e reached mailbo 0

Please lea&e a message now7

N0 Caller spea/s message0 Caller hangs %p

0 #ystem places message inmailbo

• <#omeone< m%st locatemailbo

• The responsibility ofMessage@

• The responsibility ofMailbox@

• 8either they can do this• 8ew class' MailS"stem• Responsibility' manage

mailboes



.al/thro%ghs

• CRC cards are int%iti&e for 6wal/ing thro%gh7 %se cases'

• .ample'

*ea+e a 'essage+0 Caller dials main n%mber of &oice

mail system20 #ystem spea/s prompt

.nter mailbo n%mber followedby L


6;o% ha&e reached mailbo 0

Please lea&e a message now7

N0 Caller spea/s message0 Caller hangs %p

0 #ystem places message inmailbo

• It needs to deli&er the message tothat mailbo0

• !oo/ again at the eisting Mailbox

CRC card0• It has a responsibility of 6manage

new and saved messages7• It is %p to the job of storing the

message0• #o3 add Mailbox as a collaborator0



Tips

• (&oid 6mission creep7 – If a class ac$%ires too many responsibilities3 then

consider splitting it in two0

• 9atch o%t for %nrelated responsibilities – ( class sho%ld represent a coherent concept0 9ith

related responsibilities• Resist the temptation to add responsibilities j%st

beca%se they can be done0 – .0g03 someone may ha&e s%ggested a ailbo

responsibility 6sort messages70 B%t the tas/ at hand

re$%ires no sorting0• ( class with no responsibilities s%rely is not %sef%l0

– .liminate classes that dont seem to contrib%te tosol&ing the problem at hand0



'* Diagrams

• 1raphical notations are &erygood for con&eying designinformation – .asier to etract relationship

information by loo/ing at a diagramthan by reading doc%mentation0• Which phrase produces documentation?

• ;o% /now =owcharts@

• For $%ite some time3 there was

no similar standard for OO designdiagrams – ( n%mber of diagramming

con&entions had been proposedo&er time0



'* Diagrams

• Three well5/nown researchers *Booch3R%mba%gh3 Vacobson, got together to%nify their disparate notations andde&elop U!

• U! > Uni4ed odeling !ang%age

• any diagram types

• 9eJll %se three types' – Class "iagrams

– #e$%ence "iagrams

– #tate "iagrams



'* Diagrams

• Best5/nown commercial programs' – Rational Rose

• http'WWwww0ibm0comWsoftwareWrationalW

– Together

• http'WWwwww0borland0comWtogether• Freely a&ailable programs

– )iolet tool• http'WWhorstmann0comW&iolet

– U!et• http'WWwww0%mlet0comW

– (rgoU!• http'WWwww0gentleware0com



Class Diagrams

• Rectangle with class name

• Optional compartments

– (ttrib%tes

– ethods

%&ten# an attrib$te ' an instance &ield

%ccasionally# an attrib$te is concept$al

(s$ally# not list all attrib$tes and methods )only the "ey ones*



Class Diagrams

• ;o% can also specify the type of an attrib%te'

– tet ' #tring

• ;o% can specify the parameter and ret%rn types of a method

– getC%rrentessage*inde ' int, ' essage

%&ten# they are omitted to conserve space.

So# i& yo$ see methodName)*# yo$ cannot a$tomatically ass$me that

the method has no parameters and no ret$rn val$es.



Class #elationships

(se

+as

,s



'%ltiplicities

• any n%mber *E or more,' X

• one or more' +00X

• ero or one' E00+

• eactly one' +

Message(ueue aggregates Message

Message(ueue has Message

1

Message(ueue

hasone or more

Message



Composition

• #pecial form of aggregation

• Contained objects donJt eist o%tside container

• .ample' essageA%e%e permanently containedin ailbo

• In contrast3 essage mo&e thro%gho%t the systemand dont always reside in a essageA%e%e



Association

• #ome designers donJt li/eaggregation

– Beca%se they feel it is too

implementation5speci4c

• ore general association relationship

• (ssociation can ha&e roles



Association

• #ome associations are bidirectionalCan na&igate from either class to the other – .ample' Co%rse has set of st%dents3 st%dent has set of

co%rses

• #ome associations are directed

8a&igation is %nidirectional – .ample' ( essageA%e%e needs to be able to locate themessages inside3 b%t a message doesnJt /now abo%tmessage $%e%e containing it



!nter"ace Types

• Interface type describes a set ofmethods

• 8o implementation3 no state

• Class implements interface if itimplements its methods

• In U!3 %se stereotype YinterfaceZ



Tips

• Use U! to inform3 not to impress

• "onJt draw a single monster diagram

• .ach diagram m%st ha&e a speci4cp%rpose

• Omit inessential details



e0%ence Diagrams

• Class diagram are static [ they display therelationships0

• ( se$%ence diagram shows dynamics of apartic%lar scenario0

• #e$%ence diagram describe interactions betweenobjects0



e0%ence Diagrams

• The tet inside an object rectangle has one of theformats' – ob)ect*ame+Class*ame *f%ll description,

– ob)ect*ame *class not speci4ed,

– +Class*ame *object not speci4ed,

#tart an barat the end

of the callarrow

Call amethod

-Activation bar

/xec$ting a method The bar

ends whenthe method

ret%rns



el" call



Object Constr%ction



Tips

• Principal p%rpose of a se$%ence diagram

– To show the objects that are in&ol&ed incarrying o%t a partic%lar scenario and the orderof the method calls that are eec%ted

• If yo% played thro%gh a %se case when%sing CRC cards3

– Probably a good idea to %se a se$%ence

diagram to doc%ment that scenario0• 8o re$%irement to %se se$%ence diagrams

to doc%ment e&ery method call0



tate Diagram

• #ome objects ha&e a discrete set of states*that a?ect their beha&ior,0

• .ample' a &oice mail system'

– 9aiting state' the system is idle and waitingnew call

– Connected state' when a caller 4rst connectsto it0

– Recording state' after the caller chooses antargeted mailbo

• (lso called #tate Transition diagram



tate Diagram

9aiting

Connected

Recording

A caller connected to the system

0estination chosen

oice recorded



Design Doc%mentation

• Recommendation' Use Va&adoc comments• !ea&e methods blan/

,--Adds a message to t.e end o/ t.e new messages#

0param aMessage a message-,public void addMessageMessage aMessage!{%

• "onJt compile 4le3 j%st r%n Va&adoc• a/es a good starting point for code later



Part III

Case t%dy ,oice 'ail



Case t%dy ,oice 'ailystem

• Consider the tas/ of writing a program thatsim%lates a telephone &oice mail system – ( caller dials an etension n%mber and lea&es a

message0

– The mailbo owner can later retrie&e the messages3/eep them3 or delete them0

• #impli4ed &ersion – Use tet for &oice3 phone /eys3 hang%p

– + 2 000 E L on a single line means /ey

– : on a single line means <hang %p<

– (ll other inp%ts mean &oice



Analysis Phase

Its role is to crisply de4ne the beha&ior of the system0

9e will de4ne the beha&ior thro%gh a set of %se cases0

8ote that the %se cases by themsel&es are not a f%ll speci4cation of a system0

The f%nctional speci4cation also needs to de4ne system limitations3

performance3 and so on0

se Case #each an



se Case #each an3tension

+0 User dials main n%mber of system20 #ystem spea/s prompt

.nter mailbo n%mber followed by L

-0 @@@M0 #ystem spea/s

;o% ha&e reached mailbo 0 Please lea&ea message now

se Case *ea+e a



se Case *ea+e a'essage

+0 Caller carries o%t #each an3tension

20 Caller spea/s message

-0 @@@

M0 #ystem places message in mailbo



se Case *og in

+0 ailbo owner carries o%t #each an3tension

20 ailbo owner types password and L*"efa%lt password > mailbo n%mber0 To

change3 see Change the Passcode,-0 #ystem plays mailbo men%'

.nter + to retrie&e yo%r messages0.nter 2 to change yo%r passcode0.nter - to change yo%r greeting0

se Case #etrie+e



se Case #etrie+e'essages

+0 ailbo owner carries o%t *og in 20 ailbo owner selects <retrie&e messages< men% option-0 #ystem plays message men%'

Press + to listen to the c%rrent messagePress 2 to delete the c%rrent messagePress - to sa&e the c%rrent messagePress M to ret%rn to the mailbo men%

M0 ailbo owner selects <listen to c%rrent message7N0 #ystem plays c%rrent new message3 or3 if no more new

messages3 c%rrent old message0

8ote' essage is played3 not remo&ed from $%e%e0 #ystem plays message men%0 User selects <delete c%rrent message<0 essage is remo&ed0

S0 Contin%e with step -0

se Case #etrie+e



se Case #etrie+e'essages

• ,ariation 1

• +0+0 #tart at #tep +020 User selects <sa&e c%rrent

message70+0-0 @@@

+0M0 Contin%e with step -0

se Case Change the



se Case Change the4reeting

+0 ailbo owner carries o%t *og in

20 ailbo owner selects <changegreeting< men% option

-0 @@@

M0 ailbo owner presses L

N0 #ystem sets new greeting

se Case Change the



se Case Change the4reeting

,ariation 1 5ang %p be"orecon6rmation

+0+0 #tart at step -0

+020 ailbo owner hangs %p0+0-0 #ystem /eeps old greeting0

se Case Change the



se Case Change thePasscode

+0 ailbo owner carries o%t *og in

20 ailbo owner selects <changepasscode< men% option

-0 ailbo owner dials new passcode

M0 ailbo owner presses L

N0 #ystem sets new passcode

se Case Change the



se Case Change thePasscode

,ariation 1 5ang %p be"orecon6rmation

+0+0 #tart at step -0

+020 ailbo owner hangs %p0+0-0 #ystem /eeps old passcode0



Design Phase

CRC Cards

9al/thro%gh

U!

! i i l C#C C d



!nitial C#C Cards

• #ome ob&io%s classes3 whose no%nsappear in the f%nctional speci4cationare'

– @@@ – @@@

– @@@

!nitial C#C Cards



!nitial C#C Cards'ailbo3

• The mailbo sho%ld /eep trac/ of which messagesare new and which are sa&ed0

• The messages need to be /ept somewhere0

!nitial C#C Cards



!nitial C#C Cards'essage7%e%e

• The messages need to be /ept somewhere sothat they can be retrie&ed3 sa&ed3 and deleted

• 9e retrie&e messages in a 4rst5in3 4rst5o%tfashion0

!nitial C#C Cards



!nitial C#C Cards'ailystem

• 9here are the mailboes /ept@

• There needs to be a class that containsthem all

T l h



Telephone

• 9ho interacts with %ser@

• Telephone ta/es b%tton presses3&oice inp%t

• Telephone spea/s o%tp%t to %ser

T l h



Telephone

• Two responsibilities' – Inp%t from %ser

– O%tp%t to %ser

C ti



Connection

• 9ith whom does Telephone comm%nicate

• 9ith ail#ystem@

– #%per4cially3 that so%nds li/e a good idea0

• 9hat if there are m%ltiple telephonesconnected to the system@

• ach connection can be in di?erent state*dialing3 recording3 retrie&ing messages3000,

• #ho%ld mail system /eep trac/ of allconnection states@

• Better to gi&e this responsibility to a new class

C ti



Connection

9 l/th h



9al/thro%gh

• 8ow we ha&e some idea of thecomponents of the system0

• It is time for a simple scenario

wal/thro%gh0

Analy8e se Case *ea+e a



a y e se Case ea e amessage

+0 User dials etension0 Telephone sends n%mber to Connection*(dd Connection as a collaborator of Telephone)

20 Connection as/s MailSystem to 4nd matching ailbo

-0 Connection as/s Mailbox for greeting*(dd responsibility <manage greeting< to Mailbox3add Mailbox as a collaborator to Connection,

M0 Connection as/s Telephone to play greetingN0 User spea/s greeting0 Telephone as/s Connection to record it0

*(dd responsibility <record &oice inp%t< to Connection,0 User hangs %p0 Telephone noti4es Connection0

0 Connection constr%cts a Message object that contains therecorded message

*(dd Message as a collaborator of Connection.a/e a Message card with a responsibility 6manage messagecontents70,

S0 Connection adds the Message object to Mailbox

#es%lt o" se Case



Analysis

#es%lt o" se Case



Analysis

Analyse se Case #etrie+e



ymessages

• +0 User types in passcode0 Telephone noti4es Connection• 20 Connection as/s ailbo to chec/ passcode0

*(dd responsibility <manage passcode< to ailbo,• -0 Connection sets c%rrent mailbo and as/s Telephone to spea/ men%• M0 User selects <retrie&e messages<0 Telephone passes /ey to

Connection• N0 Connection as/s Telephone to spea/ men%• 0 User selects <listen to c%rrent message<0 Telephone passes /ey to

Connection• 0 Connection gets 4rst message from c%rrent mailbo0

*(dd <retrie&e messages< to responsibility of ailbo,0Connection as/s Telephone to spea/ message

• S0 Connection as/s Telephone to spea/ men%

• 0 User selects <sa&e c%rrent message<0 Telephone passes /ey toConnection• +E0 Connection tells ailbo to sa&e message

*odify responsibility of ailbo to <retrie&e3sa&e3delete messages<,• ++0 Connection as/s Telephone to spea/ men%

#es%lt o" se Case



Analysis

C#C %mmary



C#C %mmary

• One card per class

• Responsibilities at high le&el

• Use scenario wal/thro%ghs to 4ll incards

• Us%ally3 the 4rst design isnJt perfect0*;o% j%st saw the a%thorJs third

design of the mail system,

U!



U!

• 8ow we %se U! to help design0

'* Class Diagram "or 'ail



gystem

• CRC collaborators yield dependencies – Mailbox depends on Message(ueue

– MailS"stem depends on Mailbox

– Message doesnJt depends on Mailbox

– Connection depends on &elep.one3MailS"stem3 Message3 Mailbox

– &elep.one depends on Connection

Dependency



p y#elationships

Aggregation



gg g#elationships

• ( mail system has mailboes

• ( mailbo has two message $%e%es

• ( message $%e%e has some n%mberof messages

• ( connection has a c%rrent mailbo0

'* Class Diagram "or



g,oice 'ail ystem

e0%ence agram or se ase ea+ea message



!nterpreting a e0%ence



Diagram• .ach /ey press res%lts in separate call to dial3 b%t

only one is shown

• Connection wants to get greeting to play

• .ach mailbo /nows its greeting

• Connection m%st 4nd mailbo object'Call 4ndailbo on ail#ystem object

• Parameters are not displayed *e0g0 mailbon%mber,

• Ret%rn &al%es are not displayed *e0g0 fo%ndmailbo,

• 8ote that connection holds on to that mailboo&er m%ltiple calls

e0%ence agram or se ase#etrie+e messages



Connection tate



Diagram



!mplementation Phrase

essage0ja&a

essageA%e%e0ja&a

ailbo0ja&aConnection0ja&a

ail#ystem0ja&a

Telephone0ja&a

ail#ystemTester0ja&a

2 OO Design Process Student

Documents

Transcript of 2 OO Design Process Student