Software Engineering (phần 10) pptx

: 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 http://www.verypdf.com/ 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 http://www.verypdf.com/ 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 http://www.verypdf.com/ 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 http://www.verypdf.com/ 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 http://www.verypdf.com/ 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 http://www.verypdf.com/ 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 http://www.verypdf.com/ 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 http://www.verypdf.com/ 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 http://www.verypdf.com/ 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 http://www.verypdf.com/ to remove this message, thank you. . 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. . 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. 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,