Figure 5-2, Products of requirements elicitation and analysis.

1. Requirements elicitation Analysis Figure 5-2, Products of requirements elicitation and analysis. Requirements Specification nonfunctional requirements functional model Analysis Model dynamic model analysis object model System design Object design

2. use case class statechart sequence diagram:View diagram:View diagram:View diagram:View functional object dynamic model:Model model:Model model:Model analysis model:Model Figure 5-3, The analysis model is composed of the functional model, the object model, and the dynamic model.

3. TimeZoneDatabase UniversalTime TimeZone GPSLocator UserId Location Figure 5-4, Examples and counterexamples of classes in the analysis object model of SatWatch. Domain concepts that should be representedin the analysis object model. Software classes that should not be representedin the analysis object model. Refers to how time zones are stored (design decision). Denotes to how location is measured (design decision). Refers to an internal mechanism for identifying users (design decision)

4. <<entity>> <<control>> <<boundary>> Year ChangeDateControl ButtonBoundary <<entity>> <<boundary>> Month LCDDisplayBoundary <<entity>> Day Figure 5-5, Analysis classes for the 2Bwatch example.

5. Incident LowPriority Emergency Disaster CatInTree EarthQuake ChemicalLeak TrafficAccident BuildingFire Figure 5-6, An example of a generalization hierarchy.

6. Report Manage EmergencyButton EmergencyControl ReportEmergencyControl ReportEmergency Form Figure 5-8, Sequence diagram for the ReportEmergency use case. FieldOfficer press() «create» «create» fillContents() submit() submitReport() «create» Emergency Report submitReportToDispatcher() «destroy»

7. Manage EmergencyControl Dispatcher IncidentForm Incident Acknowledgment Figure 5-9, Sequence diagram for the ReportEmergency use case (continued from Figure 5-8). submitReportToDispatcher() «create» createIncident() «create» submit() «create» «destroy»

8. ReportEmergency Control Acknowledgment Notice Figure 5-10, Sequence diagram for the ReportEmergency use case (continued from Figure 5-9). Manage FieldOfficer EmergencyControl acknowledgeReport() «create» dismiss() endReportTransaction() «destroy» «destroy»

9. Figure 5-12, Examples of CRC cards for the ReportEmergencyControl and the Incident classes.

10. 1 * writes FieldOfficer EmergencyReport author document Figure 5-13, An example of association between the EmergencyReport and the FieldOfficer classes.

11. document author writes 1 * FieldOfficer EmergencyReport 1 1 reports triggers Incident 1 1 Figure 5-14, Eliminating redundant association.

12. State FireStation County FireFighter LeadCar FireEngine Ambulance Township Figure 5-15, Examples of aggregations and compositions.

13. EmergencyReport emergencyType:{fire,traffic,other} location:String description:String Figure 5-16, Attributes of the EmergencyReport class.

14. Active field officer arrives on site Reported Assessment dispatcher field officer requests allocates resources additional resources Response Disengagement field officer releases resources all resources deallocated when d ate > 1yr. Inactive Closed Archived all resources submitted reports Figure 5-17, UML statechart for Incident.

15. PoliceOfficer badgeNumber:Integer FieldOfficer Dispatcher Figure 5-18, An example of inheritance relationship.

16. Define use cases Define participating objects Define Define Define boundary entity control objects objects objects Define interactions Define Define Define nontrivial attributes associations behavior Consolidate model Review model Figure 5-19, Analysis activities.

17. Figure 5-22, An example of a revision process. Client Developer Report problem Design change or and change request estimate impact Review proposed change [change approved] Update Archive requirements request Design Update test design Update code (if applicable) Execute all relevant tests Review actual change

18. :Tournament :Arena :League Form :LeagueOwner :Announce Tournament Control :Tournament Figure 5-26, UML sequence diagram for AnnounceTournament, tournament creation workflow. newTournament(league) «new» checkMaxTournament() setName(name) setMaxPlayers(maxp) commit() createTournament(name,maxp) createTournament(name,maxp) «new»

19. :Request :Announce :Tournament Sponsorship :Arena Tournament Form Control :Advertiser :Sponsorship Request :Sponsorship Reply Figure 5-27, UML sequence diagram for AnnounceTournament use case, sponsorship workflow. :LeagueOwner requestExclusiveSponsor() requestExclusiveSponsor() findInterestedExclusiveSponsors() confirmSponsorInterest() notifySponsor() reply(yesNo) «new» notifyLeagueOwner() selectSponsor() setSponsorship(sponsor) setSponsorship(sponsor) setSponsorship(sponsor)

20. :Notify :Announce :Interest Interest Tournament Group GroupsForm Control :Player :Advertiser :Interest Group Notice Figure 5-28, UML sequence diagram for AnnounceTournament use case, interest group workflow :LeagueOwner notifySponsorsOfDecision() notifySponsorsOfDecision() «new» :Sponsor Notice notifyAdvertiser(yesNo) notifyInterestGroups(groups) notifyInterestGroups(groups) notifyInterestGroups(groups) «new» notifyPlayer()

21. Figure 5-29, Entity objects identified after analyzing the AnnounceTournament use case. Arena 1 1 max tournaments * sponsorship fee 1 Advertiser 1 1 1 1 1 * Advertisement 1 Account balance charges * payments LeagueOwner * 1 * 1 Game * * * * * * League Interest Group * * 1 1 TournamentStyle 1 * * Tournament User * 1 name * contact * * Match Player

22. Figure 5-30, Inheritance hierarchy among entity objects of the AnnounceTournament use case. User LeagueOwner Advertiser Player Game TournamentStyle TicTacToe Chess KnockOutStyle RoundRobinStyle

23. Figure 5-31, Associations among boundary, control, and selected entity objects participating in the AnnounceTournament use case. AnnounceTournamentControl Arena TournamentForm Tournament RequestSponsorshipForm SponsorshipRequest Advertiser SponsorshipReply LeagueOwner SelectExclusiveSponsorForm SponsorNotice NotifyInterestGroupsForm InterestGroup InterestGroupNotice

24. Year Month Week Day Figure 5-32, A naive model of the Gregorian calendar. 1 * 1 * 1 *