1. Conquering Complex and Changing Systems Object-Oriented Software Engineering Art for Chapter 5, Analysis

2. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Figure 5-1. Ambiguity: what do you see?

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Figure 5-2. Products of requirements elicitation and analysis (UML activity diagram). System Design system model :Model system specification :Model analysis model :Model Requirements Elicitation Analysis

4. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Figure 5-3. The analysis model is composed of the functional model, the object model, and the dynamic model. In UML, the functional model is represented with use case diagrams, the object model with class diagrams, and the dynamic model with statechart and sequence diagrams. analysis model:Model dynamic model:Model object model:Model functional model:Model use case diagram:View class diagram:View statechart diagram:View sequence diagram:View

5. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Figure 5-4. Analysis classes for the 2Bwatch example. > Year > Month > Day > ChangeDateControl > LCDDisplayBoundary > ButtonBoundary

6. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Figure 5-5. An example of multiplicity of associations (UML class diagram). A 2Bwatch has two Buttons and one LCDDisplay. 2Bwatch ButtonLCDDisplay 1 2 1 1

7. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Figure 5-6. Examples of multiplicity (UML class diagram). The association between Person and SocialSecurityNumber is one-to-one. The association between Person and Car is one-to-many. The association between Person and Company is many-to-many. FieldOfficerIncidentReport * * FireUnitFireTruck * 1 PoliceOfficer 1 1 owner property author report BadgeNumber

8. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Figure 5-7. Example of a hierarchical file system. A Directory can contain any number of FileSystemElements (a FileSystemElement is either a File or a Directory ). A given FileSystemElement, however, is part of exactly one Directory. Directory FileSystemElement File 1 *

9. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Figure 5-8. Example of a nonhierarchical file system. A Directory can contain any number of FileSystemElements (a FileSystemElement is either a File or a Directory ). A given FileSystemElement can be part of many Directory (ies). Directory FileSystemElement File * *

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Figure 5-9. Example of how a qualified association reduces multiplicity (UML class diagram). Adding a qualifier clarifies the class diagram and increases the conveyed information. In this case, the model including the qualification denotes that the name of a file is unique within a directory. DirectoryFile filename Directory File filename 1 Without qualification With qualification * 0..1 1

11. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Figure 5-10. An example of a generalization hierarchy (UML class diagram). The root of the hierarchy represents the most general concept, whereas the leaves nodes represent the most specialized concepts. Incident LowPriorityEmergencyDisaster EarthQuakeChemicalLeakCatInTree TrafficAccidentBuildingFire

12. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Figure 5-12. Sequence diagram for the ReportEmergency use case (initiation from the FieldOfficerStation side).

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Figure 5-13. Sequence diagram for the ReportEmergency use case ( DispatcherStation ).

14. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Figure 5-14. Sequence diagram for the ReportEmergency use case (acknowledgment on the FieldOfficerStation ).

15. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Figure 5-16. An example of association between the EmergencyReport and the FieldOfficer classes. * 1 writes authordocument FieldOfficerEmergencyReport

16. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 Figure 5-17. Eliminating redundant association. The receipt of an EmergencyReport triggers the creation of an Incident by a Dispatcher. Given that the EmergencyReport has an association with the FieldOfficer that wrote it, it is not necessary to keep an association between FieldOfficer and Incident. * 1writes author document 1 1 1 1 triggers reports FieldOfficerEmergencyReport Incident

17. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Figure 5-18. Attributes of the EmergencyReport class. EmergencyReport emergencyType:{fire,traffic,other} location:String description:String

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Figure 5-19. UML statechart for Incident. numAllocatedResource == 0 all reports when incident.date > 1yr. are submitted ActiveInactiveClosedArchived

19. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Figure 5-20. An example of inheritance relationship (UML class diagram). FieldOfficerDispatcher PoliceOfficer badgeNumber:Integer

20. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Figure 5-21. Analysis activities (UML activities diagram).

21. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Figure 5-23. An example of a revision process (UML activity diagram).

22. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Figure 5-24. A naive model of the Gregorian calendar (UML class diagram). 1 * 1 * 1 * Year Month Week Day