: i
: :
.
' j
l2.s DYNAMIC M ODEKING aTy '
!
.
;
'
of transition rules of the form given in equation ( 1 I .2):
' (
' Curreni Xute Qnd eveni Clnd Predicole =:/ nexl Xote j
.
'
;
I
. .
' :
.
IForm ality is achieved by presenting the model in the torm of a set ot mathematical '
'
rules. ;
I
In contrast, the representation of a UM L state diagram is somew hat Iess formal. ' l
The three aspects of a state machine (state, event, and predicate) are distributed overthe !
UML diagram. For example, the state Go in'o W oii Sto'e in Figure 12.6 is entered j
if the present state is Elevotor Even, toop and the predicate ëelevator stopped, j 1
no requests pendingl is true. (UML predicates or ''guards'' appear in brackets. as j 1 1I l
shown in Figure 12.6). When the state Go ine Wci, Sioie has been entered. action .(
'
lClose elevaior doors cher timeout is to be canied out

. current versions of OOA i !
'
. x
, 1
are semiformal (graphical) techniques, and the intrinsic lack ot tormality of the state ! j
diagram accordingly is no problem. However, when the object-oriented paradigm
matures, it is likely that more formal versions will be developed and the corresponding
dynamic models will be somewhat closer to finite state machines. r
To see the equivalence of the state diagram of Figure 1 2.6 and the STDS of Figures j
1 l . 14 through 1 l . 16, consider various scenarios. For example. consider the hrst part ':
'
of the scenario of Figure 12.2. First, User A presses the Up floor button at floor 3. If .
; E
the floor button is not on, then, according to both Figure 1 l . 15 and the state Protess 2
, .
- - l '
Requesi of Figure l 2.6, the button is turned on as required. ln the case of the state ;,
'
h t state is Elevotor Event toop. ldiagram, t e nex
Next. the elevator nears floor 3. First, considerthe STD approach. In Figure l 1 . 16, E q
the elevator goes into state S(U, 3), that is, it stops at floor 3, about to go up. (Because l : i
the simplifying assumption has been made of only one elevator, the argument e in j
i l l I 6 is suppressed here)
. From Figure 1 l . l 5, when the elevator arrives, the ; i
.
Figure .
i
floor button is turned off. Now (Figure 1 1 . 1 6) the doors close, and the elevator starts :
: to move toward floor 4. ; i
Returning to the state diagram of Figure 12.6, consider what happens when the . .

elevator nears floor 3. Because the elevator is in motion, the next state entered is :
' Deiermine If S'op Reques/d. The requests are checked and, because User A has ' i
!'
requested the elevator to stop there, the next state is Stop oi Floor. The elevator stops j t
at floor 3 and the doors open. The elevator button for floor 3 has not been pressed. so 1 ' 1 )
state Elevoior Eveni toop is next. l
$ ' ' i
User A enters and presses the elevator button for floor 7. Therefore, the next !
State is again Profess Request followed again by Elevotor Event toop. The elevator !
has stopped and two requests are pending, so state Close Elevoior Doors is next and , ! 1
.
.
tthe doors close after a timeout
. The floor button at floor 3 w as pressed by User A , t
so Floor Bu/on Off is the following state, and the floor button is turned off. State i.
Protess Nexl Requesl is next. and the elevator starts to move toward floor 4. The j
relevant aspects of the corresponding diagrams clearly are equivalent w ith respect to '
this scenario', you may wish to consider other scenarios as well. y !
IF
rom the preceding discussion. it should com e as no surprise to learn that Figure :
I12
.6 was constructed from the scenarios. M ore precisely, the specific events of the !
scenarios were generalized. For example, consider the first event of the scenario of f '
Figure l 2.2, User A presses the Up floor button at floor 3. This specihc event is
generalized to an arbitrary button being pushed. Then there are two possibilities. : j (
l @
' j;
.
.
t

Please purchase Image To PDF Converter on to remove this message, thank you.
!
l
t 3V% < H A p T E R IQ * Obiee-orien#ed Anolysis Phose
i
1 .
! Either the button already is Iit (in which case nothing happens) or the button is unlit
g j , '(in which case action must be taken to process the user s request).
1
j To model this event, the Elevotor Event Loop state is drawn in Figure 12.6. The
i case of an already Iit button is modeled by the do-nothing loop with guard (button
@ pushed, bufton lif) in the top left-hand corner of Figure 12.6. The other case, an unlit
E button, is modeled by the arrow labeled with the guard Ibufton pushed, bufton unliti
' leading to state Protess Request From event 2 of the scenario it is clear that the action
E Turn on button is needed in this state
. Furthermore, the purpose of the user's action
'
of pressing an arbitrary button is to request an elevator, so aetion Updote requests
also must be carried out in the state Protess Request
Now consider event 3 of the scenario, An elevator arrives at floor 3. This!
) was generalized to the concept of an arbitrary elevator moving between Qoors. The
motion of the elevator is modeled by the guard Ielevator moving in direction d,
.
i fl
oor f is next) and the state Delermine if Slop Requesled. But there again are two
l possibilities
. Either there is a request to stop at floorf. or no such request. ln the former;
i case. con-esponding to guard (no request to stop at floor f), the elevator simply must! l C
onlinue Moving one more floor in direction d. In the latter case (corresponding to
t 7 uard (user Incs requested stop ct floor f!). from the scenario of Figure l 2.2 it is dear! g

j ! that it is necessary to Stop elevator (from event 3), and then Open doors and storf
timer (from events 5 and 6). Also, similar to the case of the Protess Requesi state,
it becomes apparent that it is necessary to Update requests in state Slop G Floor.!
. : Finally, generalizing event 4 of the scenario leads to the realization that the elevator '1
i i button has to be turned off if it is Iit
. This is modeled by state Elevolor Bu/on 0: ,:
r (the state on the bottom left of Figure l 2.6), together with the two guards above tlle .
l box representing that state
.
l Generalizing event 9 of the scenario of Figure 12.2 yields the state Close Elevolor
'
Doors', generalizing event 10 yields the state Process Next Requesi. However, the(
:
: need for the state Go inlo Woif Stote and guard (no requests pending, doors closedl
is deduced by generalizing an event of a different scenario, one in which the user exits
from the elevator and no buttons remain lit. 2.
The state diagrams for the other classes are relatively straightforward and there-
: fore left as an exercise (Problem l 2. l ).
l
1 1Q .* TKSTIN/ PURIN/ THE @ BJKW -@ RIKNTEP
i
1 A xAkysls puAsz
.
tl
l l At this point
,
the three models of the object-oriented analysis process seem to bej '
! complete. The next step is to review the OOA to date. One component of this review,i
g as suggested in Section l 2.4.2, is to use CRC cards.
Accordingly, CRC cards are hlled in for each of the classes, Bu/on, ElevdorI

Bu/on, Floor Bu/on. Elevoùor. and Elevotor Coniroller. The CRC card for Elevo-;
ior Controller, shown in Figure 12.7, is deduced from the class diagram of Figure
i
;
I
i
; '
t .
Please purchase Image To PDF Converter on to remove this message, thank you.
;
3
1 :k
'
@ j
:
: 42.* TESTING DURING THE OBJECT-ORIENTED ANAWSIS PHASE 3F@ : j 1
. I !
l i
'
t cLAss 7 2
I 1
Elevador Condroller I
e i ';
.
ën RESPONSIBILITY
gi
.t 1
.
Tu rn on elevator button ' y
t

.
1 2. Turn off elevator button E
n 3. Turn on floor button '
n 4. Turn off floor button '
:
i
's 5. Move elevator up one floor 2 ,
: 6. M ove elevator down one floor i 1
7. Open elevator doors and stort timer i
s ! !8
.
Close elevator doors aher timeout je
.
p. check requests j1
, 1 o update requests t
O .
rr COLLABORATION
it : 1
. class Elevokor Bu/on
o , 2. Class Floor Bu/on
2r 3. Closs Elevol'or E l .
-
t : I
'
I i
', Flgur. 1Q.y First iteration of CRC card ' j
'
.
for the class ElevoMr Conkoller. '
pr . i

:lF )
1 2 5 and the state diagram Of Figure 1 2.6. ln more detail, the RESPONSIBI LIW of the 1e .
Elevolor Eondroller was obtained by Iisting a1l the actions in the state diagram for l
lpr the Elevaior Controller (Figure 12
.6). The CO LLABORATION of the Elevolor Con- j
e lroller was determined by examining the class diagram of Figure 12.5 and noting that g
1) ,
classes Elevoior Bu/on, Floor Bu/on, and Elevoior interact with the class Elevoer i
Controller. lIS .
.
IThi
s CRC card highlights two majorproblems with the hrst iteration of the object- ; '
i ted analysis. First consider responsibility 1 . Turn on elevator bueon. This com- ! lir- Or en:
.
:d is totally out of place in the object-oriented paradigm. From the viewpoint of : iman
responsibility-driven design (Section l .6). objects of the class Elevcior Bu/on are ' ' )
'
responsible for turning themselves on or off. Also, from the viewpoint of informa- : l
tion hiding (Section 7.6), the Elevotor Conlroller should not have the knowledge of l
-
: the internals of Elevotor Bu/on needed to be able to turn on a button. The correct i
'
l B /on to turn itself on. Similar 1responsibility is this: send a message to E evctor u
changes are needed tbr responsibilities 2 through 6 in Figure 12.7. These six correc- tj
tions are reflected in Figure l 2.8. the second iteration of the CRC card for the Elevoe r
Coniroller. t 'ie
,
v A second problem is that a class has been overlooked. Consider the responsibility I
Z. Open elevator doors cnd start timer. The key concept here is the notion of a state. j
J ' ''' -

.
jr ' The attributes of a class sometimes are termed state variables. The reason for this ; !
1- ' terminology is that, in most object-oriented implementations, the state of the product
'
i d termined by the values of the attributes of the various component objects. The I.e s e
; '
: !i
r!
.
r:
l'
j
Please purchase Image To PDF Converter on to remove this message, thank you.
i
1
1
1
'
1 aao t u A p T : R lx . obieu-orien'ed Anolysis phose .
1
1
1
1 CLASS
d Elevajor confxller
.
i
1
1 ZESFONSIBILITY
i
! 1 . send message to Elevo'or Bu/on to turn on button

1 2 send message to Elevofor Bu/on to turn off button
3. Send message to Floor Bu/on to turn on button
4. Send message to Floor Bu/on to turn off bufton
5. Send message to Elevolor to move up one floor
4 6. send message to Elevador to move down one floor
! 7 send message to Elevotor Doors to open
j '
'
8. Start fimer
; 9. Send message to Elevaior Doors to close aher timeout '
l 1 0. Check requests
q ' .1 1
. Updote requests1
.
;
t COLLABORATIOX
'
) 1
. Subclass Elevoêor Bu/on
'
!
l 2. Subclass Floor Bu/on
)
3. Closs Elevo#or Doors
:
)
''
' z Class Elevo#or
1
'

1 ylgvee 1Q.@ second iteration of CRC card for the class
i Elevoer controller.
I
.
I
l
!
I
. state diagram has m any features in com mon with a finite state machine. A ccordingly,
it is not surprising that the concept of the state plays an important role in the object-
oriented paradigm. This concept can be used to help determine whether a component
should be m odeled as a class. lf the component in question possesses a state that
i will be changed during execution of the implementation
,
then it probably should be
i m odeled as a class
.
Clearly, the doors of the elevator possess a state (open or closed),!
:
'
and Elevcdor Doors therefore should be a class.i
I There is another reason why Elevoior Doors should be a class. The object-1
i oriented paradigm allows the state to be hidden within an object and hence protected
1 from unauthorized change
.
lf there is an Elevoior Doors object, the only way that thef j
' '
t doors of the elevator can be opened or shut is by sending a message to that Elevo*r
' I Doors object. Serious accidents can be caused by opening or closing the doors of an
I I elevator at the wrong time', see the Just in Case You Wanted to Know Box on page

j' 1 1 38 l
. Therefore, for certain types of products, safety considerations should be added '
' 1 , to the other advantages of objects Iisted in chapters 7 and 8.
l ' Elevoùor Doors into a class means that responsibilities 7 and 8 in Figures Making
I .
; 12.7 need to be changed analogously to responsibilities l through 6. That is, messages
( should be sent to the Elevoior Doors to open and close themselves. But there is an
! additional complication
. Responsibility 7 is Open elevator doors and start timer.i
!
1
1
l E
I
Please purchase Image To PDF Converter on to remove this message, thank you.
.
! 7
!
'
,
j
'
j4a.* TESTING DURING THE OBJECT-ORIENTED ANAWSIS PHASE 381
:
t
.
ll 'J
us' IN Gs: You WANTZP To Kwow q j
.
Some years ago. I was on the 10th floor of a building, Perhaps. if that elevator control system had been

: waiting impatiently for an elevator
.
The doors opened, developed using the object-oriented paradigm, the in-
.
lI
started to step forward- only no elevator was there. appropriate opening of the doors on the 10th floor might !
.
lWhat saved me was the total blackness I saw as l was have been avoided
. l
about to step into the elevator shaft. and l instinctively j j!
. realized that something was wrong. j !
'
i l
'
j I
-
. ( p
'
1 i
'
;
;
'
!
.
Button
illuminated: Boolean l
'
j
'

!
'
i
Elevator Button Floor Button 1 '
! '
'
j 'mn 2m - 2
q q i
controls controls ' !
l
.
j
j . j j. ' Elevator Controller
1 . r, Elevator Doors
.
' controls '' : 1 k
requests: request-rype doors open: Boolean ''
.
)
1
!
.'
controls !
.
I
R
.
EIPVRtOT F
I
Flgve* 1Q.* Third iteration of class diagram . . i

,
i 1
i ! 1 l
.
I l
'
.
.
j
1 -Thi
s must be split into two separate responsibilities. A message indeed must be sent i1 ëto the Elevuùor Doors to open
. However. the timer is part of the Elevcior Conlroller,
and starting the timer therefore is the responsibility of the Elevoior Conlroller itself. l
lThe second iteration of the CRC card for the Elevoior Controller class (Figure 12
.8) q; r ,
hows that this separation of responsibilities has been achieved satisfactorily. ( k 1s
In addition to the two major problems highlighted by the CRC card of Figure , I
12.7. responsibilities Check requesis and Update requests of Elevolor Coniroller
require the attribute reques@s be added to the class Elevolor Coniroller. At this stage, :
requests are dehned simply to be of type requestType; a data structure for requests
,
: .
: i
will be chosen during the detailed design step. i
The corrected class diagram is shown in Figure 12.9. Having modified the class r !
'
diagram . the use-case and state diagrams m ust be reexamined to see if they, too. need i ' '
! I
Ii
!

'
.
.
1 !
!!
1
-
'
Please purchase Image To PDF Converter on to remove this message, thank you.
5
2 aaa t u A p T : . la . obietf-orienfed Anolysis phoseI
1 '
1
1 1 User A presses the Up floor button at floor 3 to request an elevator
. User A wishes to goj .
. fo floor 7,l
1 2. The floor button informs the elevator controller that the floor button has been pushed.
1 3. Tie elevator controller sends a message to the Up floor button to turn itself on.
! h Ievator controller sends a series of messages to the elevator to move itself up
.: z. . T e e
! to floor 3. The elevator contains User B, who has entered the elevator ct floor 1 and
ressed the elevotor button for floor 9. 'P
5. The elevator controller sends a messoge to the Up floor button to turn itself off.
E 6. The elevator controller sends a message to the elevator doors to open themselves. '
i
( Z. The elevator control starts the timer.
User A enters the elevator.
:
.8. User A presses elevotor button for floor 7. .
9. The elevator button informs the elevator controller that the elevator button has been

oushed. .
; '
.
.
1 0. The elevator controller sends a messcge to the elevator button for floor 7 to turn itself on.
i 1 1 , The elevator controller sends c message to the elevator doors to close themselves oher o
i timeout
.
'
E
'
'
i 1 2, The elevator controller sends a series of messages to the elevator to move itself up fo
I floor 7.
:' ! l
! ) 3. The elevator controller sends a messoge to the elevator button for floor 7 to turn itself off.1
rI ' 1 4. The elevotor confroller sends a message to the elevator doors to open themselves to: j
. cllow User A to exit from the elevator.
1 5. The elevotor controller starts the timer. '(
'
User A exits from ihe elevator.
I 1 6
. The elevator controller sends a message to the elevctor doors to close themselves cher c
.
!
'
l
2 timeout.
i 1 7. The elevator controller sends a series of messages to the elevator to move itself up to :1
.

floor 9 with User B.
Flgvee 1Q.1@ Second iteration of u normal scenario.
furtherrelinement. The use-case diagram clearly still is adequate. However, the actions
.
in the state diagram of Figure l 2.6 must be m odified to reiect the responsibilities of
Figure 12.8 (the second iteration of the CRC card) and not Figure 1 2.7 (the first '
1 iteration). Also, the set of state diagrams must be extended to include the additional (
k 1 class. The scenarios need to be to updated to reiect these changes', Figure 12. 10 shows
.
l the second iteration of the scenario of Figure 12.2. Even after all these changes have
ê
. !
:
been made and checked (including the modified CRC cards), it still may be necessary
# ' during the object-oriented design phase to return to the object-oriented analysis and 25l
I ! f tjw diagram s
.revise one or more oI
' '
i A inted out in Section l l
.
1 the specification document is a contract betweenS po ,I
'
: client and developers. Accordingly, after the OOA is complete, a more conventional
:
specihcation docum ent has to be drawn up; one alternative is to use a format similar
to that of Appendix E. Once approved, the specilication document is handed to the
j design team, together with the various UML diagrams.
i
j '
.

j
.
1
'
: ;
Please purchase Image To PDF Converter on to remove this message, thank you.
' !
-
1
l
i l
:.
. I ! I
l2.e AIR GOURMET CASE STUDY: O BJKT-O RIENTID ANAWSIS a@a 1
,
!
! k
'
1Q.y QASK Toots FoR TH: @ BJE<T-@ RIKNTEP ': j l
.
IA NAW SIS PHASE 2 I
l
1B
earing in mind the role played by diagrams in object-oriented analysis, it is not I
surprising that a number of CASE tools have been developed to support object- I(
1
oriented analysis. ln its basic form , such a tool essentially is a drawing tool that : t
kes it easy to perform each of the modeling steps. More important. it is far simpler ' 1 jma
to modify a diagram constructed with a drawing tool than to attempt to change a 2
!hand

-
draw n figure. Thuss a CASE tool of this type supports the graphical aspects of ;
,
!
object-oriented analysis. In addition, some tools of this type not only draw all the I I ë
1 levant diagrams but CRC cards as well. A strength of these tools is that a change to 7
:
lre q
1 1
;
the underlying model is reoected automatically in aIl the affected diagram s', after all, )
the various diagram s are merely different views of the underlying m odel. '
E 1On the other hand
, some CASE tools support notjust object-oriented analysis but 1'
.
- - -
.
- -
'
, a considerable portion ot the rest of the object-oriented life cycle as well. Nowadays 1. 1
Is support UML (Rumbaugh, Jacobson. and Booch, 19991. : i 1virtually al1 of these too
'
.
. p
Examples ot such tools include Rose and Together. ; :g
: :
.
! E
.
è i

j I r
1 12.@ A IR G @URM KT ZASE STUPY: i
@ tT-@ RIENTKP A NAW SI: 1, 1 'BJE
?
'
:
Object-oriented analysis consists of three steps: use-case modeling, class model- .
ing, and dynamic modeling. These steps are canied out iteratively, starting with the :
first step, use-case modeling. The main menu of the Air Gourmet rapid prototype
(Appendix C or D) yields a list of use cases. These also could have been deduced. j
C with considerably more effort. directly from the requirements of Section 1 0. 14. j 1 'T
The use case for m aking a reservation is shown in Figure l 2. 1 l . Normal and E '
.
I)
exception scenarios are needed for this use-case diagram . One approach is to con- I ''
! I
struct separate normal and exception scenarios', this was done for the elevator problem (
l
(Figures l 2.2 and l 2.3). For the Air Gourmet problem, we use a slightly different for- 4 j
malism, an extended scenario that retlects possible alternatives. A n extended scenario '
di to Fi ure 12.1 l is shown in Figure l 2. 1 2 'correspon ng g .
Figure l 2. l 2 was constructed from the prototype (Appendix C or D). Choosing '
Enter a Reservation from the main menu (represented by event l of Figure 1 2. 1 2) 1 ti
causes solicitation of tlight information (events 4 and 5), seating preference (events 8 .
and 9), special meals information (events 6 and 7), and passenger information (events )
'
2 and 3). It was quickly realized that the rapid prototype solicits information in the ' '
wrong order, and that the payment for the reservation had been omitted. Rearranging k
,
1

I 'the requests and adding the payment portion yielded events 1 through l 1 of Figure j
: 12 l 2 The last three events of the scenario were added to complete the normal part '. l'
. .
of the seenario. : .
: l ! '
j I '
j :
'
'
'
t
'
'
il .
Please purchase Image To PDF Converter on to remove this message, thank you.
i
I :
1
I a** t u A p T : * 42 @ obiete-orienfed Anolysis Pbose!
I
1
1 Air oourmet
1 .:
.
j .
1
I make a reservation
l .
k
1 passenger phone operator

.
:
,
I .
1 Flsure 12
.11 Use-case diagram for making a reservation for the
' Air Gourmet product. . .:
:
'
j '
1 . The Fassenger contacts the Air Gourmet call center Phone Operator and expresses thei
.
desire to reserve (7 flight.
2. Tlae Phone Operaàor requesfs àlne name and address of àlne Passenger.
1 3. The Possenger provides fhe requested information.
1 zt The Phone Operator asks the Fassenger the date of the flight and the flight number
.
: '5
. The Passenger provides the requested information.!
.
'
I I 6. The Phone Operator asks the Fassenger if a special meal is desired.I
!j . 7. The Possenger stctes whot kind of special meal, if any, is desired.
!
''
8. The Phone Operofor asks the Fossenger for his or her seating preference
.
.
:
9. The Fassenger provides his or her seofing preference.

; ' 1 0. The Fhone Operctor requests payment information.
,
I
1 1 . The Possenger provides o volîd credif cord number.;
'
! 1 2. The Fhone Operator commits the reservation to the Air Gourmet database
.
1 1 3 The Air Gourmet datobase issues the reservation ID to the Phone Operator
.
t '1
z
1 The Fhone Operator gives the reservation ID to the Passenger and informs the1
.
Fcssenger that lhe ticket will be mailed soon.
posslble Alterno#ives
!
.
è A
. The flight number requested does not exist on the particulcr day that the Fassenger wantsi
., .
'
: to fly.
J B. The flighf fhof fhe Passenger requesfed olready is full.
'
C. The Fassenger has an unusuol meol request that Air Gourmet cannot fulfill. .
D. There are problems with the credit card number provided by the Fassenger,
(
! Flgvze 12.12 Extended scenario corresponding to Figure 1 2
. 1 1 .1
' 2l

1
6
'
'
:.
'
.
'
i The possible alternatives were deduced while working on the norm al events. It ,
j 1 is not a good idea to look for alternatives in the rapid prototype, which should haveI
I ! been constructed too rapidly to consider including code to handle alternatives like1
ë
,
events A through D in Figure l 2. l 2.
l
1 The use case for returning and scanninc a postcard is shown in Ficure 12.13: a
: ''''' ''''' A %'-'' ' .
j
corresponding extended scenario is shown in Figure l 2. 14. Event 3 of this scenalio
was obtained from the scon postcard portion of the rapid prototype. Events 1 and
2 then were added to complete the scenario. As with the previous scenarios the four
.
1
possible alternatives were deduced while working on the normal events.
7
/
!
1
Please purchase Image To PDF Converter on to remove this message, thank you.
l I .

. :E ;
.
1
'
.
i
!j '
12.* AIR GOURMET CASE STUDY: OBJKT-ORIENTED ANAWSIS a@5 j
'
. I
l
:
l
.
q 1 1Air Gourmet I
:
? i j''
; ;i '
: Iq
( ireturn/scan postcard
2 : l
; . 1
' j j
'
Passenger Air Gourmet
! 1S
taff Member lë
q l
Flgure Io.la Use-cose dicgram for returning and scanning a postcard. ' ; !
I .

l .
1
l .
ff Member mails an evaluation postcard 1 .1
.
Aher the flight has Ianded, the Air Gourmet Sta l
to the Passenger who received a special meal. .l
2. The Fassenger receives the postcard, rates the meal, and mails the postcard back to Air j )
G rmet ' 'ou
.
;
3. The Air Gourmet Staff Member receives the postcard and updates the appropriote flight 1
record in the Air Gourmet datcbase to record the Fassenger's response. ! 1
I
'
k
lP
ossible Aliernoiives y ,
i IA
. The Fassenger never receives the postcard. r ! i
IB
. The Passenger never returns the postccrd, : !
' C. The Fassenger marks the postcard erroneously; for exomple, by providing an answer ;! : I
outside the ronge of valid values. ' il !
D. A Fassenger who did not request a special meal receives the postcard and mails it bock. i 1
.
:: !
ï
Flgvre 1Q.1* Extended scenario corresponding to Figure 1 2. 1 3. ' i
l

:
The other use cases (create and shade a special meals list, transport special . j .'
meals, view é'low sodium'' report view E'percentage statistics'' report, view çtm eals I ' l )
! '
not loaded'' report, and view ûçpoor quality'' report) are similar. as are their respective I I i
1 '' I l
tended scenarios. So, for the sake of brevity, they are omitted here. I l
.
ex
The second step is class modeling. The aim of this step is to extract the classes. ( l
I :find their attributes
,
and determine their interrelationships and interactions. This was jl
performed using the three-stage noun extraction method of Section l 2.4, rather than p
,
k
scenarios or CRC cards. Stage 1 is to define the product as briefly and concisely as l
!
.
l
possible, preferably in a single sentence. ln the case ot Air Gourmet, one possible ; 2
I .
way of doing this is ) ( ë
k 'l
'
tion regarding the efficacy of a l ' kA computerized system is needed to provide intorma
I :
special meals program . '
ln stage 2. an inform al strategy is draw n up, preferably in a single paragraph. l
I I .àO

ne possible such paragraph is ! j
,
!R
eports are to be generated to document the efficacy of the special meals program. ' 1
.
The reports concern meals Ioaded on flights, llights boarded by passengers. names ' !
d ddresses of passengers, meal qualitys and Iow-sodium meal quality. ! lan a
; 2 1 c
.
j i
j ( .
!
1 j
i
Please purchase Image To PDF Converter on to remove this message, thank you.
!
'
:
'
!
i
t a@* f H A P T E R 12 @ Obietborienled Anolysis Phase
!
l
1 ln stage 3. the nouns in this paragraph are identified, yielding
Reports are to be generated to document the efficacy of the special meals progrom.i
i 'rhe reporfs concern percentoges of meals loaded on flights and boording of flights
i dd f assengers
,
meal qualits and Iow-sodium; by passengers, names and a resses o p

1 meal quality.
!
'
,
The nouns are report, efficacy, program, percentage. meal. flight. boarding,
passenger, name, oddress, and quality. Efficacy, progrom, percentoge, boording, C
'
and qualityare abstractnouns and therefore unlikely to beclasses. Nameandaddress ;
clearly are attributes of passenger. The presence or absence of a special meal on a
iven flight is a central issue. What is less clear is whether the meal itself or thel g
i flight itself will be classes. Because it usually is easier to add a class than delete one,
:
l it was felt that it was probably better to set these two nouns aside, at least for the
i
'
lirst iteration. This left two nouns and, thercfore, two candidate classes: Report and
j Possenger. The resulting first iteration ofthe class diagram is shown in Figure l2. 15.
i This hgure reflects the two candidate classes
,
plus four subclasses. one for each of the
i reports
.
The Repori class contains the tields common to all four reports, the startingi
.
j and ending date. Each subclass comprises the lields specific to that report.
! There are a number of problems with this class diagram '.
''
.
'
1k

'
-
'
t 1. l . .
1 . To compute the intormation needed to print the various reports, data are needed
: ' on a per-flight basis. For exam ple, to determ ine the percentage of passengers
; (
'
1
.
, I
;
1
l Passenger
*
1
Report
i .
.!
1
.
l
l
'
.
)
l i
I ;
' ; .Percentages Meals-Not-Loaded Poor-ouality Low-sodium
-

l
j Report Report Meals Report Meals Report
i
l
!
I
' Flguee IQ.IS First iteration of class diagram for the Air Gourmet product.!
; '
.
1
I
l
.
l
Please purchase Image To PDF Converter on to remove this message, thank you.
1
I
'
.
l .
,
4a.a AIR Gou- eT CASE 5TuDY: OBJKT-ORIENTED ANALYSIS aay '1
I
,
onboard the flight for which they ordered a special meal, the data have to be é
organized into llights. 2
j '2
.
Each report has to access multiple flight records, and each iight has multiple 4 j
passengers. ' !

Section 10. 14 specifies four numbered reports, as reflected in Figure 12.15. How- 13
.
!2
ever, the first numbered report actually consists of three separate reports. There- 1
,
. lfore
,
the class diagram should reqect six (and not four) subclasses of Report j
, . :
1
$ These events are rectiied in the class diagram of Figure l2. 16. There are in- ''
t ' deed now six subclasses of Report Furthermore. there is a one-to-many relationship .I E
) (Section 1 1.5) between Repod and Flighl Record, rellecting that each report con- t I
,
tains information from many qights. Finally. the open diamond next to Fligl/ Retord , l i
) denotes aggregation (Section 7.7), and the asterisk next to Possenger again denotes ;!
!l a one-to-m any relationship
. That is, each llight record comprises many passenger , ', .
ds. These records could have been modeled as components of the Flighl Reeord. : !. recor
.
:
) Instead, for simplicity and clarity, the Pcssenger class is treated as a separate en- E j
tity. The held (key) passenger ID is used to associate a given Possenger with the !, 1j
.
convsponding Fligh, Retord.
:
W hy w as the hrst iteration of the class diagram so wrong? Part of the problem was '
'
the decision not to include Flight as a candidate class. Everyone has 20-20 hindsight, 2 l .l
1 . 1 ,., ,

! ,b
ut at the time it seemed reasonable to select neither rlloht nor M eol as an initial ! i
5 . %' 1 t
candidate class. As previously pointed out, it is easy to add classes but much harder ( ;
to remove them, so there was little to Iose and much to be gained by selecting only l
$
two candidate classes for the initial iteration. ' j j
lt is less easy to justify the decision to incorporate only four repol.t subclasses. !
'
I IAfter all
. the rapid prototype (Appendix C or Appendix D) contains six reports. On ' l
the other hand, this is a m inor issue and easily resolved. ' 6
lnstead of bewailing the inadequacy of the first iteration (Figure 12. 15), it would '
.
(;
.
be better to note the ease with which the second iteration was produced, once it was ) t
observed that the data for the reports had to be organized on the basis of the Qights and . j
he passengers on those Pights. ln other words, iteration is intrinsic to the object- i ' 1 1not t h
'
)
'
oriented paradigm in general and object-oriented analysis in particular. lteration does l I :
discarding an artifact when a fault is detected, but rather modifying that : '
'
J :not mean
m ifact stepwise to correct the fault. I '
I
i
The third step in object-oriented analysis is dynamic modeling. A1l the scenarios ( !

flected in the state diagram of Figure l 2. l 7 for the complete product. Strictly lare re
i
.
speaking, a state diagram appertains to a class not the product as a whole, but because j i
lasses of the Air Gourmet product do not move from state to state, a diagram ' ' ( tjthe c
such as that of Figure 1 2. 17 is more appropriate here. q !
The object-oriented analysis appears complete. lt therefore should be reviewed. ! q
.Neither the client nor the development team should be willing to accept the set .
.
of UM L diagram s as an adequate specification document. After all, as pointed out in r
: Section 1 l . l , the specihcation document is a contract between client and developers. '1 '
Accordingly, after the OOA is hnished, a m ore conventional speciEcation document y
has to be drawn up. Because that document would be so similar to m uch of the material
) i
'
of Appendix E, it is om itted from this case study for brevity.
,
.
j '( t
.
-
!
'
!j
. /
( r ! G
' 1 .
'
I :
Please purchase Image To PDF Converter on to remove this message, thank you.

!
!
1 .
.) aea t u A p 4 . R 42 @ Obleu-orien'ed Anolysis Phose
!
. ?
l
1 Flight Record passenger
!
1 passenger ID : string passenger ID : string
1 .
reservotion ID : string first name : string .l
:
j flight number : strins middle initial : char
flight dote : string Iosl name : string .i
' seat number : s'rins suffix : string
.
meal type : m-type , . oddress 1 : sfring
meal Iooded : Boolean oddress 2 : string!
.
'
onboord : Boolean city : strins
E perc meal quolity : int state/province : string
postul code : strins
: country : string '
*
.
g 1
4
.

Report :
. l
I
, jrom date : string Li
'
t fo dafe : s'ring
j '
.
1 .
'
j .C
k
I ,
.
l
t
i
: Percentage Report Low-sodium Report Poor-ouality Report
f
l
'
Ioaded as specified,
'
!
assenger on board,p
not Iocded : intllzl '
t
Not-Loaded Report Onboard Report Caterer Report
i flight number : string flight number : string :
:

spec. meal tally : intl 1 3) '4
i
:
,
'
.
Flgure 1o.1* Second iteration of class diagrom for the Air Gourmet product.
1
, . ;
l ' -
1 i
; . j '
l .
:
i .
: g .
( $
'
: i
.
'
J
J :
Please purchase Image To PDF Converter on to remove this message, thank you.
l
'
k j
q 2 l
! ' I .
A2.* A1R GOURMET CM E STUDY: OBJECT-ORIENTED ANAWSIS 3@@ l

' j'
i (
'
iMake Reservation Order Special Meal
24 hr before flight ( I
1Store reservation in Air
: 1 !Create Iist for caterers
.
Gourmet database I
caterer receives Iist j
Obtain passenger ' j '
.
. Deliver list lo caterers : .
information l
l
ë
'
l(take-off time - 1 hr S check-in time < take-off time - 10 min)
;
passenger al check-in counter r i '
i i
E
'
1 -Passenger Check-in
) )
Update Air Gourmet database q . '
to reflect that passenger has ' ; '
hecked in 1 Jc
l
j ) , 'aircraft takes off i !

.
I ,
.
( j
In Fligut t !
Create Special meals Iist 1 (
2
Shade in squares :
Scan Iist
i I .
; I I .
aircraft Iands '' :
; '1
.
l
Postcard Evaluation I ù
' J
Mail postcard lo passenger ,1
,
j
'
1. ''
,,
Fill in postcard I
l .Scan postcard
:
data complete
- - j l :.
ê l 2Print Repofts !
1 ,(

.
1 . .
Get start, end dates j . .@ p
Get list of reports to be printed ,' i
! Print reports h 1 .
j '
! g
'
Flgure l.2ay State diagram for the Air Gourmet product. î
i
.
I (1i
.
t '
( 1
l .): .
' ' j .
! 1
( ! -'!
1
.
! '
l
Please purchase Image To PDF Converter on to remove this message, thank you.
j '
i .L
i
! a*o < u A p T K R la * obiet'-orienled Anolysis Phoset
'
.

t
.
1 .Just as when the structured paradigm was used for the specihcation of the Air
1 Gourmet product (Section 1 1. 1 5), at this point the software project management planl
i is drawn up. Appendix F contains a software project management plan for develop- E.
! ment of the Air Gourmet product by a small (three-person) software organization.i
.
j This plan adheres to the IEEE SPM P format. :
1
2
.
(
k 1Q.@ ZHALU N/ES @F TH: @ BJKW -@ RIENTKP
1 A NAW SIS PHAS:
)
i Object-oriented analysis is a specihc approach to the specification phase
,
so the gen-
1 l challenges of the specihcation phase described in Section 1 l
. 16 apply equally to, era
1 obiect-oriented analvsis. In particular, the second challence listed in that section is '
' j -' -'' '*
'
%-'''
'
that it is easy to cross the boundary line between specihcations (ûtwhat'') and design
.
j
'
t (édhow''). This danger is especially acute in the case of object-oriented analysis.' ;

g ; Recall that, as described in Section l .6, the transition from object-oriented anal-
'
' ysis to object-oriented design is far smoother than the transition in the classical
l paradigm from the specification phase to the design phase. In the classical paradigm,
i an initial task of the design phase is to decompose the product into modules. In con-
' trast, the classes, the itmodules'' of the object-oriented design phase. are extractedh
during the object-oriented analysis phase, ready for refinement during the object-t
r oriented design phase. The presence of classes from early in the OOA phase means
that the temptation to carry the OOA too far can be extremely strong.5
For example, eonsider the issue of allocation of methods to elasses. One task
of the classical specihcation phase is to determine the data and actions of the target
r product. However, allocation of the various actions to specihc modules should be
delayed until the design phase, because as pointed out in Section 1 l . 1 6, we first have
l t
o determ ine how the product as a whole is broken down into m odules.
'
In the object-oriented paradigm. however. this latter task is part of the analysisl
phase. That is, during the object-oriented analysis phase, we determine the modulesi
! (classes) and their interactions', the result is depicted in the elass diagram (Section
1.
: 1 2.4). Thus, there apparently is no reason why we should wait until the object-oriented :
)
'
'
design phase before allocating methods to classes.1
Neverthelesss it is important to remember that object-oriented analysis is an iter- .it
J ative process. ln the course of rehning the various models, frequently large portions of (C
' l deI have to be reorganized. Reorganizing the classes and their attributesthe c ass mo
.
-

l
,
I ' can be time-consuming. Reallocating the methods then results in unnecessary addi-
,r
'
'
; tional rework
.!
'
i At each step of the OOA process it is a good idea to minimize the information
' è that would have to be reorganized during iteration
. Therefore, allocation of methodsi
; to classes should wait until the design phase, no matter how tempting it may be to go
just a little further during the object-oriented analysis phase.
5
:
'
,
!
i
'
i g
l
Please purchase Image To PDF Converter on to remove this message, thank you.
l
. .
i j
. I
I
FoR FURTHER REaolxo am ' l

: I
'
!
IE
7
'
-
'
ë
'
11
tHAPTZR Rzvlzw I I'
(i i l
Object-oriented analysis is introduced (Section 12. 1). The three steps of the object- ' E'
oriented analysis phase are described: use-case modeling (Section 12.3), class mod- i l
g
ling (Section 12.4), and dynamic modeling (Section l 2.5). These steps are applied ' 1e l
to the elevator problem (restated in Section 12.2). Testing during the object-oriented . l I '
'
!analysis phase is the subject of Section l 2
.
6. CASE tools for object-oriented analysis l
are discussed in Section 12.7. The chapterconcludes with the object-oriented analysis . i J '
of the Air Gourmet case study (Section 12.8) and a discussion of the challenges of 1,
,
the object-oriented analysis phase (Section l 2.9). I 1 j
! j 'p
'
5: I
E

'
k
i t '- 5 t
'
j
l !F
@R FURTHER R EAPIN/ 1 !
:
.
1
.
1
ly books describing different versions of object-oriented analysis include îcoad
lEar
and Yourdon, l 99 la; Rumbaugh et a1., 199 l ; Shlaer and Mellor, l 992., and Booch, I I!
19941. As mentioned in the chapter, these techniques (and others not listed here) are i 1
I ib
asically similar. j
'
ln addition to object-oriented analysis techniques of this type, Fusion (Coleman l 1
'
et al., 19941 is a second-generation OOA technique, a combination (or fusion) of a 1 l
'
j j .
number of first-generation techniques. including OMT gRumbaugh et a1., 19911 and '
Objectory (Jacobson, Christerson. Jonsson. and Overgaard, l 9921. The Unified Soft- y ,
ware Development Process unilies the work of Jacobson, Booch. and Rumbaugh gJa- 'E i:
cobson, Booch, and Rumbaugh, 1 9991. Catalysis is another important object-oriented : ,
methodology (D'souza and Mills, 19991.
ROOM is an object-oriented methodology for real-time software gselic, ) )

I l 1 iGullekson
, and Ward. 19951. Further information on real-time object-oriented tech- I I j !
'
logies can be tbund in (Awad, Kuusela, and Ziegler, l 9961. j' ino
Introductions to UM L 1 .0 include Il-ee and Tepfenhart, l 997, and Fowler, l 997171. 1
.
' lFull details regarding UML can be found in gBooch
,
Rumbaugh, and Jacobson, 1999, ; ':
( '
and Rumbaugh, Jacobson, and Booch, 19991. The October 1999 issue of Communi- ! j
cations ofthe ACM contains a broad variety of papers on the use of UML. 1
'
The noun-extraction technique used in this chapter to extract candidate classes is l
,
: j . .formalized in tluristo
a Moreno, and Löpez, 20001. CRC cards were tirst put forward ' I
'
I p
'
in (Beck and Cunningham, l 9891. (W irfs-Brock, W ilkerson. and W iener, 19901 is a .l
r -
good source of information on CRC cards. i t
The September 1992 issue of the Conlmunications ofthe ACM contains a num- '!
ber of articles on object-oriented analysis. Several eomparisons of object-oriented ' !
analysis techniques have been published, including ëde Champeaux and Faure, 1992 !
' and Embley, Jackson, and Woodfield, 19951. Compar- : 1 'Monarchi and Puhr
,
1992,
: lisons of object

-
oriented and structured analysis techniques appears in gFichman and . r
Kemerer, l 9921. k ) j!
I I
.
I j
.
'
q!
j ''
.
j .
: 1
Please purchase Image To PDF Converter on to remove this message, thank you.
)
i
g a*2 t H A p T z * 42 * Obiete-orienled Anolysis Phoset
1 Management of iteration in object-oriented projects is described in (Williams
,
a.q
.
19961. Statecharts (Section 10.6. 1) have been extended to the object-oriented paradigm;1
his is described in (Coleman, Hayes, and Bear, 19921 and kldarel and Gery, 19971. The .i t1 ;
.
reuse of specitications in the object-oriented paradigm is described in gBellinzona,1
! Fugini, and Pernici, 19951. (Kazman, Abowd, Bass, and Clements, 19961 propose the
i f scenarios to assist with object-oriented analysis
.
I uSe o
i

I
1
l
1
PRo Bk:Ms2
i 1 2 1 Complete the elevator problem case study by developing state diagrams for the other!
@
classes shown in Figure 12.9.1
E 1 Q
.
2 Use object-oriented analysis to specify the automated library circulation system of!
1 Problem 8.7.
'
ë
'
1
:
1 Q.3 W hy cannot the finite state machine formalism of Section 1 1 .6 be used unchanged in
,
; object-oriented analysis?
f 1 2.4 Use object-oriented analysis to specify the software for controlling the ATM of Prob-
E lem 8.9. There is no need to consider the details of the constituent hardware compo-
nents such as the card reader, printer, and cash dispenser. lnstead, sim ply assume that
!
I
I when the ATM sends commands to those components, they are executed correctly.
l
,
1 Q.5 What is the latest point in the object-oriented analysis process at which classes can
9 1

.be introduced without adversely atfecting the project?
1 Q.6 What is the earliest point in the object-oriented paradigm at which classes can be
meaningfully introduced?
i
! 1Q.7' ls it possible to represent the dynamic m odel using a form alism other than the state
l
! diagram described in this chapter? Explain your answer.
1 Q.8 W hy do you think that the attributes of the classes but not the methods are determined
during object-oriented analysis?
i 1 2.@ (Term Project) Use object-oriented analysis to specify the Broadlands Area Children'si
Hospital product described in Appendix A.' t
.
1 1 2.1 0 (Case Study) Add class Mecl to the object-oriented analysis of the Air Gourmet case
'
1 study (Section 12.8). ls this an improvement or an unnecessary complication?
'
j
i 1 a.1 1 (case study) Determine what happens when object-oriented analysis starts with dy-
1 7 namic modeling
.
start with the state diagram of Figure l 2.6 and complete the object-$ ;' :
i oriented analysis process for the Air Gourmet case study.
.
j
1 zp
roblem 1 1 . 1 6 (Term Proiect) ond Problems 1 1 .20 ond 1 1 .2 1 (Case Study) can be done at the end of either:
Chopter 1 1 or Chapter 1 2.1
.
k
i

I)
'
!
j
.
! : l .
Please purchase Image To PDF Converter on to remove this message, thank you.
.
,
'
,
1
l '- I
h
'
'
'
1l ;
!
REFEuxcEs a.a 1 i ' '!'. t j
r
'
I j
'
I -h 1
11 1Q (Case Study) Compare and contrast the structured systems analysis of Section I l . 14 l i I*
.
j j
with the object-oriented analysis of Section l 2.8. ': 1: i
i1

.13 (Readings in Software Engineering) Your instructor will distribute copies of (Harel ; !
9 l .and Gery
, 1 9971. Could statecharts be adapted to replace state diagrams in OOA . ë j .
l 1
i !'
'
j .
! ! )
.
T I .
'
; !
I .1
-
1
REFERKNtES ! '!
:2
.
I
(Awad, Kuusela, and Ziegler, 19961 M . AwAD. J. KUIJSELA. AND J. ZIEGLER, Object-oriellted j 1 ;
i
.
Technologyjbr Real-lime Svstems, Prentice Hall, Upper Saddle River, NJs l 996. I I y
Beck and Cunningham, 19891 K. BECK AND W. CUNNINGHAM, GA Laboratory for Teaching k 11) :
'
,s ,
1 ;Object-oriented Thinking
,
Proceedings of OOPSLA 89, ACM SIGPLAN Notices 24 l
i(October l 989)

,
pp. 1-6.
,
( j ,
(Bellinzona, Fugini. and Pernici, 19951 R. BELLINZONA, M. G. FIJGINI, AND B. PERNICI, ! I 1. '
'
,,
1'*Reusing Specifications in 00 Applications
, IEEE Sojtware 12 (March 1995). ; . '
j 'pp
. 656-75.
' h .4 Iications, 2nd ed., l(Booch, 19941 G. Boocil, Object-orientedAnalysis and Design w?/ pp
Benjamin/cummings. Redwood City, CA, 1994. !
(Booch, Rumbaugh, and Jacobson, 19991 G. Boocu, J. RUMBAUGH, AND 1. JACOBSON, The !
UM L Users Guide, Addison W esley, Reading, MAs 1 999. 8
' d Yourdon, 1 99 1 al P. COAD ANt) E. YOURDON, Object-oriented Analyxiy 2nd ed., l t ''(Coad an
,
jY
ourdon Press, Englewood Cliffs, NJ, 199 1 . ( ! t '
(Coleman, Hayes, and Bear, 19921 D. COLEMAN, F. HAYES, AND S. BEAR, ttlntroducing i
.
j'
'
Statecharts in Object-oriented Design,'' IEEE Transactions i . 'Objectcharts or How to Use j
'
:Jn Software Engineering 18 (January 1 992), pp. 9- I 8. '
'
v r
(Coleman et al., 19941 D. COLEMAN, P. ARNOI-D, S. BODOFF, C. DOLLIN, l1. GILCHRIST, (
t *

F. HAYES, AND P. JEREMAES, Object-oriented Development The Fusion Method, ! '
Prentice Hall, Englewood Cliffs. NJ, 1994. : !
,
-
,
. . .
I I l 'ë '(D So
uza and Wills, l 9991 D. F. D SouzA AND A. C. WILL.s, Objettn, Colnponents' and r j g!l
.
j r
'
Frameworks with UML: The CataI)'.%i.% Appmacll, Addison-W esley, Reading, M A, 1999. .
$ j .
!de Champeaux and Faure, l 9921 D. DE CHAMPEAIJX ANo P. FAURE, ''A Comparative Study 'j L.
f Object-oriented Analysis Methods,'' Jr/lfrntz/ # Object-oriented Programming 5 1O I
(March/April l 992), pp. 2 l -33. r I
(Embley. Jackson, and Woodfield, 19951 D. W. EMBI.EY, R. B. JAclksoN. ANI) 1
S. N. WOODFIEI-D, 00 Systems Analysis: Is lt or Isn t It? IEEE s'q/rktlre 12 (July : j .
'
1995) pp. 1 8-33. l 1 '.9 1
j .
''Object-oriented and ' I '(Fichman and Kemerer, 1992) R. G. FICHMAN AND C. F. KEMERER. I
,
Conventional Analysis and Design Methodologies: Comparison and Critique,'' IEEE 1E !
Computer 25 (October l 992), pp. 22-39. k j .
Fowlers 1 997b1 M. FOWLER WITH K. SCOTT, UML Distilled, Addison-Wesley, Reading, MA, 1 .
1997. I '1gl
-
larel and Gery, 19971 D. HAREL AND E. GERY, ''Executable Object Modeling with ' 1 .
'' IEEE Computer 30 (July 1 997), pp. 3 1 42. i ' ''Statecharts

. I(J
acobson, Booch, and Rumbaugh, l 999) J. RUMBAIJGH, G. Boocll, AND 1. JACOBSON, The .
.eb.% Addison-Wesleys Reading, MA. 1999. IUnfied Software Development #mc . . ,
'
j
1 j
'
'
'
'
: 1l ij .
.
! .
:
' jl
Please purchase Image To PDF Converter on to remove this message, thank you.
'
!
l '
i
I
l !
l
1
' j
e n > * e < $ lI !
l(
!i
: j
)

j 'y .
i .
K I E ! l!
.
l '
;
.
1!
i;
.
l
.
I
; I
j j - 'i
'
1 1
I i
I ; .@
he ast 35 or so years, hundreds of design techniques have been put forward. Some are variations on l jver t p
existing techniques, others are radically different from anything previously proposed. A few design techniques '
:have been used by tens of thousands of software engineers
,
many have been used only by their authors. Som e I
:
I
design strategies. particularly those developed by academics. have a lirm theoretical basis. Others. including
manv drawn uo bv academics, are more praematic in nature', thev were put forward because their authors E ,:
'
*'' * *'' '*' * ' ''' ''' k .

; found that they worked well in practice. M ost design techniques are manual, but automation increasingly is '.
,
' becoming an im portant aspect of design, if only to assist in the management of documentation. ! 1
1l 1
'gNotwithstanding this plethora of design techniques, there is a certain underlying pattern. A major theme j j ,
j 'jof this book is that two essential aspects of a product are its actions and the data on which the actions operate. I
'
''
'
'''' '
œ k 1 ,
Therefore, the two basic ways of designing a product are action-oriented design and data-oriented design. In 1 ''
i
action-oriented design, the emphasis is on the actions. An example is data flow analysis (Section 13.3), where .
the objective is to design modules with high cohesion (Section 7.2). In data-oriented design, the data are j j
considered first. For example, in Jackson's technique (Section l 3.5), the structure of the data is determined : l'
I j !first
, then the procedures are designed to conform to the structure of the data. ! '
A weakness of action-oriented design techniques is that they concentrate on the actions', the data are of :' 1
I 1 ' .
only secondary importance. Data-oriented design techniques similarly emphasize the data, to the detriment of I
j 'the actions
.
The solution is to use object-oriented techniques, which give equal weight to actions and data. ln '!
r
this chapter, action- and data-oriented design are described first, then object-oriented design is described. Just 1 qI
as an object incorporates both action and data, so object-oriented design combines features of action-oriented I '
and data-oriented design. Therefore, a basic understanding of action- and data-oriented design is needed to I L1 '
(get a full understanding of object-oriented design. ( .1
. :?Before specilic design techniques are examined, some general remarks must be m ade regarding the !

.
,
1 i '' ''design phase
.
;I J
-
-
: :
1a.I DESI/N ANp A BSTRM TI/N 1 '!
4 t
I '
.
The software design phase consists of three activities: architectural design, detail- :7
ed design, and design testing. The input to the design process is the specihcation I '
; I '
h
j ' '
I t
I
:
Please purchase Image To PDF Converter on to remove this message, thank you.
'
j1
.
.
(
'
! '
l a@l t u A p T : R Aa . Design Phose
.

j
i description of what the product is to do
.
The output is the design docu-document, a1
ment, a description of how the product is to achieve this.
t During architectural design (also known as general design
,
Iogical design, or
. j high-level design). a modular decomposition of the product is developed. That is,
! the specifications are analyzed carefully, and a module structure that has the desired
' f'unctionality is produced. The output from this activity is a list of the modules and a
deseription of how they are to be interconnected. From the viewpoint of abstraction,
during architectural design, the existence of certain modules is assumed', the design
: l then is developed in terms of those modules. When the object-oriented paradigm is
! ' used
,
as explained in Section l .6, part of the architectural design activity is performed ,
, :
during the object-oriented analysis phase (Chapter 12). This is because the hrst step
in OOA is to determine the classes. Because a class is a type of module, some of the
modular decomposition has been performed during the analysis phase.
The next activity is detailed design, also known as modular design, physical
J
l design, or low-level design, during which each module is designed in detail. For
'
j
.
exam ple, specific algorithms are selected and data structures are chosen. Again from
.
i

t l the viewpoint of abstraction, during this activity the fact that the m odules are to be
h'
,
j .' interconnected to form a complete produet is ignored
.
.
l Thi
s two-stage process is typical of abstraction as described in Chapter 7. First,
$ t the top level (the overall product) is designed in terms of modules that do not yet
) exist. Then each m odule is designed in turn, w ithout regard to its being a component
' of the complete product. '
Ee j
.
'
j lt was stated previously that the design phase has three activities and that the third
.
activity is testing. The word activity was used, rather than stage or step, to emphasize
.
i
j that testing is an integral part of design, just as it is an integral part of the entire
software development and m aintenance process. Testing is not something performed
only after the architectural design and detailed design have been completed.
A variety of different design techniques now are described, hrst action-oriented
techniques, then data-oriented techniques, and finally object-oriented techniques.
:
'
j
(
'
i '

'
:
%a.Q A W I@N-@ RIENTKP D KSI/N
(
i Sections 7.2 and 7.3 made a theoretical case for decomposing a product into mod-
1 ules with high cohesion and low coupling
.
W e now describe two practical techniques' j
for achieving this design objective, data flow analysis (Section 13.3) and transac-
.
(
; tion analysis (Section 13.4). ln theory, data flow analysis can be applied whenever
i the specihcations can be represented by a data flow diagram, and because (at least;
'
: t in theory) every product can be represented by a DFD, data flow analysis is uni-7
, . ,'
! lly applicable. In practice, however, in a num ber of situations, there are moreversa;
'
!
' appropriate design techniques, speciically for designing products where the flow of
:
'
l
: data is secondary to other considerations. Exam ples where other design techniquesi
! are indicated include rule-
based systems (expert systems), databases, and transaction' i
) i processing products. (Transaction analysis, described in Section 13.4, is a good way
f of decomposing transaction processing products into modules
.
)i

j '
'
j
.
1
Please purchase Image To PDF Converter on to remove this message, thank you.
' j:
i
1
1 il !
'
I I1 Aa
oa DATA FLOW ANAWSIS 3*7 !
.
i
l
la.a PATA Fkow A NAW SI: i
! i
'
:
:
l 'g
Data flow analysis (DFA) is a design technique for achieving modules with high
h ion. It can be used in conjunction with most specihcation techniques. Here. 1co es I ,
i (Section l l .3). The ë IDFA is presented in conjunction with structured systems analys s
' :input tothe technique is adataqow diagram
.
A key pointis that, oncethe DFD has been
com pleted, the software designer has precise and complete infbrmation regarding the ;1
.

s :input to and output from the product
.
Consider the flow of data in the product represented by the DFD of Figure 1 3.1 . j
.
'
The product somehow transform s input into output. At some point in the DFD. the ë l
i I
input ceases to be input and becomes some sort of internal data. Then, at some further C
point. these internal data take on the quality of output. This is shown in more detail in
- b ing input and simply 1Fi
gure I 3.2. The point at which the input loses the quality ot e ji
.
:
becomes internal data operated on by the product is termed the point oj' highest i I ,
!
'
5
,
'
abstraaion of input. The point of highest abstraction of output is similarly the first . :
point in the flow of data at which the output can be identified as such. rather than as '
som e sol't of internal data. ' ,
'highest abstraction of input and output, the product is decom- 1 ,Using the points ot
posed into three modules: the input module. transform module, and output module. !
i: N
ow each m odule is taken in turn, its points of highest abstraction found, and the !
d le is decomposed again. This procedure is continued stepwise until each module 1mo u
ingle action', that is. the design eonsists of modules with high cohesion. l; performs a s
j
'

.
Thus, stepwise retinem ent, the foundation of so m any other software engineering i
'
j
.
techniques, also underlies data flow analysis. i r
1 - h ld be pointed out that minor moditications might have to be 1 lIn tairness it s ou
; ,
: . made to the decomposition to achieve the lowest possible coupling. Data flow analysis r
' is a way of achieving high cohesion. The aim of composite-structured design is high
cohesion butalso lowcoupling. To achieve the latter, it sometimes is necessaryto make !
'
'
j
.
I !i
I T .' Input Output I
:
1 .
'
- -
+. a b c d e f c h l
j -''' I ' :11
p
'
11l Fl
gure laa Dofa flow diagram showing flow of dato and actions of product. j , .
j , '
.
j

'
'
l
.
t
Input output l
. .
i a b c d e f g h r !
.
1
l :
'
i
; ' input transform output
.
l 11
'
; module 6 module i module ( I l! I
.
2 è E I
s I l
.
!
'
Point of Point of l
highest abstraction highest abstraction
of input of output ' ll
1
! ë
Flgure la.2 Points of highest abstractions of input ond output. i

q
Please purchase Image To PDF Converter on to remove this message, thank you.
.
'
l'
j:
.
1
'
I
' l a@a t u A p T : R Aa . Design pbose
i
'
i
minor modilications to the design. For example, because D FA does not take coupling '
. into account, control coupling may arise inadvertently in a design constructed using
1 I h a case
.
all that is needed is to modify the two modules involved so thati DFA. n suc
1 d
ata, and not control, are passed between them .
.
1
1
!
: Iaoa.I PATA Fkow A wAkysls ExxMpu
l
k ! Consider the problem of designing a product that takes as input a file name andreturns
5 ' b f words in that hle
,

sim ilarly to the UNIX wc utility.the num er o'
'
.
'
!.
ë Figure 13.3 depicts the data flow diagram. There are five modules. Module recd
! file name reads the name of the file
.
which then is validated by validate file name.
'
: The validated name is passed to count number of words, which does precisely that.
The word count is passed on to format word count. and the formatted word count
1 finally is passed to display word count for output.
l file name
.
When this becomes vol-' ) Examining the data qow, the initial input is
'
; C idated file name it still is a file name and therefore has not lost its quality of being
.
i .
'
' ! input data. But consider module count number of words. lts input is validcied file
. .
name and its output is word count. The output trom this module is totally different
' i lit from the input to the product as a whole
. lt is clear that the point of highestin qua y
abstraction of input is as indicated on Figure 13.3. Similarly, even though the output
i . from count number of words undergoes some sort of formatting, it is essentially
: output from the time it emerges from module count number of words. The point ofl
p highest abstraction ot output therefore is as shown in Figure 13.3.

1 The result of decomposing the product using these two points of highest abstrac-
tion is shown in the structure chart of Figure 13.4. Figure l 3.4 also reveals that the!
'
7 data flow diagram of Figure l 3.3 is som ewhat too simplistic. The DFD does not show '
the Iogical flow corresponding to what happens if the file specified by the user does
not exist. Module read and validate file name must return a status flag to perform '
word count. If the name is invalid, then it is ignored by perform word count and
an error message of some sort is printed. But, if the name is valid, it is passed on .
!
! -1
i file file validated word formatted desired
i ' name read name Validate file name Count count format d display t ut
r WOr ou p
j file file number of word word
name name words count count countl
'
'
1
.
. l
1 Input to here . . . . Output from here
! :t
;
r 1
#
l ! j
1 l
:
'
Point of Point of

'
l highest abstraction highest abstraction
of input of output
.
;
' i
'
'
'
FI*.e* la.a Data flow dioqram: first refinement.
j ''''''' ''''''' '
i
k j
:
'
i
Please purchase Image To PDF Converter on to remove this message, thank you.
1 I
I/
'
f
'
' t' : I
ta.a DATA Fmw ANALYSIS a@* i 1 2
1'
)
' j: !
iorm k ipe
.
lWord s

:
status count I i '
flag ' '
i
validated word i
file name count I i
validated word l
file name count
i
read and count format
validate number of and display
file name words word count 1 '
:
11
1
Data I
!Control
f
.
i
'
Flgure 1a.* Structure chart: first refinement. 1
) j .
$
'
.
'
j j .
l
I

perform p )/
: word . j
' S'YUS ' ! 'Count
.
'
flag :( :
lidated Word ;
.
va ,
file name Validated word Count !
file name count . I
! ' 1
:
.
! ! '
.
.
t i 'coun
.
jget produce
number of ' jinput
cj outputwor s 1
.
' j .
'
status formatted ! .fil
e word d i 'fl
ag formatted W0rname file
count counl !
name word l:

1 I .count
j! i
:
read validate format display 1 1 'fil
e file word word ! 1
1 .
name name count count 2
( 2 ' ,
Data 'i '
.
ç.
control ;
j '
j 17Flgure 1a
.5 Structure chart; second refinement. )
.:
'
1
.
j '
.
j ' ;
; j ' '.
to count number of words. In general, wherever there is a conditional data flow, a E ' .
.
'
k i
corresponding control flow is needed.
'
,

t 'In Figure 13.4, two modules have eommunicational cohesion (Section 7.2.5),
read cnd validate file name and format and disolav word count. These must be !
: ' '
I
I
'
decomposed fufther. The final result is shown in Figure l 3.5. Al1 eight modules have ï j
'
!functional cohesion
,
with either data coupling or no coupling between them . i!
!Now that the architectural design has been completed
,
the next step is the detailed j j
design. Here, data structures are chosen and algorithms selected. The detailed design I l
.
I !
.
1 i
'
j
r '!'
.
i '
Please purchase Image To PDF Converter on to remove this message, thank you.
.
' !
l !
'
1 j

'
: 1i
.
!
j 'r *@@ < H A p T E R la @ Design Phose
? J
i j .
, g of each module then is handed to a programmer for implementation. Just as with
h 1 irtually every other phase of software production
,
time constraints usually requiret v
?
'
l
r that the implementation be done by a team , rather than having a single programmer:
I
I responsible for coding all the modules. For this reason, the detailed design of each
t
:
1 module must be presented so it ean be understood without reference to any other
!
I module. The detailed design of four of the eight modules appears in Figure 13.6., the
i other four m odules are presented in a different form at
.!
'
i The design of Figure 13
.6 is independent of the programming language. However,
E !
k ,2 if m anagement decides on an im plementation language before the detailed design is
r started, the use of a program description language (PDL) for representing the detailed

jt '
ë design is an attractive alternative (pseudocode is an earlier name for PDL). PDL
: essentially consists of comments connected by the control statements of the chosen
' t
'
l
L
I
' Module name read file name .#
'
i
i i Module type Function .
!.
,
.
Return type stringi
: d I
n ut arguments xonet P
'
. :
.
l Output arguments None
'
Error messages None
' Files accessed None . '
, $
l
i ! Modules called None
f 1
1 l Narrative The product is invoked by the user by means of 1he command

1 string
; i
; word count wfile name>
' Using an operating system call, this module accesses the contents
'
.
of the command string input by the user, extracts ufile namex,
'
and returns it as the value of the naodule.
' '
Module name validate file name 5
.
( . ;
! Module type Function '
.
E
.
j
'
I
k Return type Boolean
1
.
Input arguments file name : string1
.
'
1 output argunaents xone
.
.
'

(
'
'
. 1 Error messages None
: ! yiles aceessed xone
i
$ Files changed None
! I M
odules called None
. .
1
1 Narrative This module makes an operating system call to determine whether
' )
j file file name exists. The module relurns true if the hle exists
'
I and folse otherwise.
1
1
! Flsvre 1a.l Detailed design of four modules of example. .
l
.
1 . 1
t I
Please purchase Image To PDF Converter on to remove this message, thank you.
: j : '
'
I
!
'
p

lI
I l -la
.a DATA Fkow ANAWSIS *@1 : !
' i
! g
ï'
.
i.
I g
Module name count number of words l l' I r
'
Module type Function : I ëf
'
I I
Return type integer '' .
Input arguments validated file name : string ' !
.
output arguments None ;
Error messages None j
.
Files accessed None j .
. ::
'
!
'
Files changed None ' $ I '
Modules called None j'' i
Narrative This mtldule determines whether vclidute file ncme is a text ! l .
'
file, that is, divided into lines of characters. If so, the module 1 I

: i
returns the number of words in the text hle', otherwise, the module i 'l
-
'
'
:
1 ) '.returns
-
1 . i '
.
i
: 1 .
1 .
5 j . .
: ' t1 .
Module name product oufptlt ' j
i
.
Module type Function
I '
Return type void ' 'i
.
' Input arguments word cotlnt : integer 'i
.
'
jOutput arguments None kl
;Error messages None
ë (
:
'

!Fil
es accessed None @
l iFil
es changed None ; ;
IM
odules called format word count i j!
'
afgtlfflellts: WOQ COURt : intogef
.
!
'
formottv WOFJ COURt : Stfi ng '
ldisplay word count ' l
arguments: formatted word count : strins : !
I !N
arrative This module takes the integer word count passed to it by the
.
!!
calling module and calls format word count to have that integer i j
I 1 .éformatted according to the specihcations
. Then it calls display 1j j
g
word count to have the Iine printed. 11 ,
Ij j '1
1 I :' lj
Flgure 1a.ê Detailed design of four modules of example (continued). Ii
!
j '
implementation language. Figure 13.7 shows a detailed design for the remaining four 2
imodules of the product written in a PDL with the iavor of C++ or Java

. A PD L r
.
'
has the advantage that it generally is clear and concise, and the implementation step l
; '
usually consists merely of translating the comments into the relevant programming t k 1$l
anguage. The disadvantage is that sometimes there is a tendency for the designers k
into too much detail and produce a complete code im plementation of a module . Ito go
rather than a PDL detailed design.
After it has been fully documented and successfully tested, the detailed design '
is handed over to the implementation team for coding. The product then proceeds !
!through the remaining phases of the software process
.
! (
i r
; !
I (
'
'
1 .
' j
Please purchase Image To PDF Converter on to remove this message, thank you.
j '
' j
1 ; .
i
.
.
.
j

1 *@Q t H A > T : R Aa @ Design Phqse
1 .
1 voia perform word count ()
1
.
(l
sping vclidated file nome;' j
in# word count;
J
'
I
j if (get input (validated file nome) ix folse)
i print ''error 1 : file does not exisr;
else
l
, y
'
set word count equal to count number of words (validcted file name);
' l if (word couni is equal to - 1 ) '
! print 'zerror 2: file is not o text filez'-
.
#'
ejs.
produce output (word count);:
'
)
l
i .
.
E Booleon get input (String volidoted file name)

'
l (i
.
j'
.
sfring file nome;
.
ë :
!
: 2 jile nome = read file name ();
'
i if (volidote file ncme (file name) is lrue)
1 .
l
' i set volidcfed file nome equal to file nome;
'
, return lrue, .
'
.
j .
? !
! else
relurn fclse; .
i l)
'
void display word count (String formaqed word count)
f
rint formatfed word count, lepjustqied;
li
sfring format word count (int word countl; .)

' t '
return ''File contains'' word couni ''words'' ' '
' : )
) .
k Flguee 1a.T' PDL (pseudocode) representction of detailed design of four .
l methods of example
.!
' j
l .
5
Ia.a.Q Exn xsloxsE)
.ï
'
t . @ 'The reader may well feel that this example is som ewhat artificial
,
in that the data flow :
.
i
i diagram (Figure 13.3) has only one input stream and one output stream. To see what ' :
'
!
, 4 happens in more complex situations. consider Figure 13.8. Now there are four input
.
( streams and Iive output streams, a situation that corresponds m ore closely to reality.
:
W hen there are multiple input and output streams, the way to proceed is to find
j the point of highest abstraetion of input tor each input stream and the point of highest
I
! '
;

.
J '
.
@ j
Please purchase Image To PDF Converter on to remove this message, thank you.