1. Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Project Wikis are private again. Assignment 3 is posted. Due Nov. 6. SDD framework must be in place by Nov. 9. Today: –Software Analysis.

2. Software Analysis Analysis provides the fodder for the SDD. The SDD provides a framework, so you know where to store the results as they evolve. Fall 2015CISC/CMPE320 - Prof. McLeod2

3. Software Analysis Some information comes straight from the RAD, but most comes from an Analysis of the RAD. To build your project you ultimately need to know what all of your classes are going to be: –Their attributes and methods. –Their public interfaces. –How they interact along a time line. –How they interact with other systems and users. The result of Analysis is expressed by a Model: Fall 2015CISC/CMPE320 - Prof. McLeod3

4. Fall 2015CISC/CMPE320 - Prof. McLeod4 Overview as a UML Class Diagram Use Case Diagram Class Diagram StateChart Diagram Sequence Diagram Functional Model Object Model Dynamic Model Analysis Model

5. Where to Start? Look over the RAD to identify the Objects that are part of your system. Focus on the Use Cases: (Continue with the FRIEND system example.) Fall 2015CISC/CMPE320 - Prof. McLeod5

6. Fall 2015CISC/CMPE320 - Prof. McLeod6 Identify Participating Objects Recurring nouns (like “Incident”) Real world entities that must be tracked by the system (like “FieldOfficer”, “Resource”) Processes that must be tracked (like “EmergencyOperationPlan”) Use case names Data sources or sinks Artifacts interacted with (like “Station”) Use Application Domain Terms! (Not “Solution Domain” terms)

7. Fall 2015CISC/CMPE320 - Prof. McLeod7 Identifying Object Hierarchies If you are using an OOP development language, breaking the system down into objects is really helpful! Where possible, create object hierarchies that will: –Help to indicate which objects are more abstract than others. –Allow you to simplify construction by referring to more abstract objects. –Identify relationships between objects. –Help to identify gaps. (We still need to talk about how to implement inheritance in C++).

8. Fall 2015CISC/CMPE320 - Prof. McLeod8 Example from FRIEND As a UML Class Diagram Incident LowPriorityEmergencyDisaster CatInTree EarthquakeNuclearMeltdown TrafficAccidentBuildingFire

9. Fall 2015CISC/CMPE320 - Prof. McLeod9 Classifying Objects Take your set of participating objects, located by an examination of the use cases, and separate them into three categories: –Entity Objects – Persistent information tracked by system. –Boundary Objects – Where the actor interacts with the system. –Control Objects – Realize the use cases (make it happen!). What kind of objects were shown on the previous slide?

10. Fall 2015CISC/CMPE320 - Prof. McLeod10 Aside - Mapping Natural Language to Model Components – Examples As Language Model Component Example Proper nounInstanceAlice Common nounClassField Officer Doing verbOperationCreates, submits Being verbInheritanceIs a kind of Having verbAggregationHas, consists of Modal verbConstraintsMust be AdjectiveAttributeIncident description

11. Fall 2015CISC/CMPE320 - Prof. McLeod11 Entity Objects Terms from the glossary. Recurring nouns from use cases (“Incident”). Real world entities that the system needs to track (“FieldOfficer”, “Dispatcher”, “Resources”). Real world activities that must be tracked (“EmergencyOperationsPlan”). Data sources or sinks (“Printer”).

12. Fall 2015CISC/CMPE320 - Prof. McLeod12 Boundary Objects UI controls that the user needs to initiate a use case (“ReportEmergencyButton”). Forms needed to obtain information from the user (“EmergencyReportForm”). Messages sent by the system to the user (“AcknowlegementNotice”). Separate actor terminals (“DispatcherTerminal”). Leave more detail of components to UI prototypes or “mock-ups”. Continue to use application domain terms.

13. Fall 2015CISC/CMPE320 - Prof. McLeod13 Control Objects Do not have concrete counterparts in the “real world”. They coordinate the interaction between boundary objects and entity objects. Identify one control object per actor, per use case. The life span of the control object should cover the entire interaction of the actor with the system in that use case.

14. Example Take apart the ReportEmergency use case from the FRIEND example: Fall 2015CISC/CMPE320 - Prof. McLeod14

15. Fall 2015CISC/CMPE320 - Prof. McLeod15 ReportEmergency Use Case Example Use case name: ReportEmergency Participating Actors: –Initiated by FieldOfficer –Communicates with Dispatcher Flow of Events: 1.FieldOfficer activates “Report Emergency” function on her laptop. 2.FRIEND responds by presenting a form to the FieldOfficer. The form includes an emergency type list to choose from, location details, incident description, resources requested and hazardous materials involved option. 3.FieldOfficer provides a description of the situation, the emergency level, location, and the type of emergency, along with possible responses. Once complete, the FieldOfficer submits the form along with a request for a specific response. The minimum required information is emergency type and description.

16. Fall 2015CISC/CMPE320 - Prof. McLeod16 4.FRIEND receives the form and notifies the Dispatcher using a pop up dialog. 5.Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. All information in the report submitted by the FieldOfficer is included in the Incident. The Dispatcher selects a response by allocating resources to the Incident (using the AllocateResources use case) and acknowledges the report by sending a Acknowledgement to the FieldOfficer. The Acknowledgement indicates to the FieldOfficer that the EmergencyReport was received, and Incident created and resources were allocated to the Incident, along with the type of resources and the ETA. 6.FRIEND displays the acknowledgement and response to the FieldOfficer.

17. Fall 2015CISC/CMPE320 - Prof. McLeod17 Entry Condition: –The FieldOfficer is logged into FRIEND. Exit Conditions: –The FieldOfficer has received an acknowledgement and the selected response from the dispatcher, OR –The FieldOfficer has received an explanation of why the transaction could not be processed. Quality Requirements: –The FieldOfficer’s report is acknowledged within 30 seconds. –The selected response arrives no later than 30 seconds after it is sent by the Dispatcher.

18. Fall 2015CISC/CMPE320 - Prof. McLeod18 Control Objects in FRIEND From the “ReportEmergency” use case: “ReportEmergencyControl” –Running on “FieldOfficerTerminal” “ManageEmergencyControl” –Running on “DispatcherTerminal”

19. Fall 2015CISC/CMPE320 - Prof. McLeod19 ReportEmergency Objects Entity: Dispatcher, EmergencyReport, FieldOfficer, Incident, Acknowledgement Boundary: AcknowledgementNotice, DispatcherTerminal, ReportEmergencyButton, EmergencyReportForm, FieldOfficerTerminal, IncidentForm Control: ReportEmergencyControl, ManageEmergencyControl

20. Fall 2015CISC/CMPE320 - Prof. McLeod20 Sequence Diagrams A UML Sequence Diagram re-creates a use case using its objects. They consist of the actors, the boundary, control and entity objects, with interactions shown along a time line. Pretty complicated! Not very useful for single player game apps…

21. Fall 2015CISC/CMPE320 - Prof. McLeod21 FieldOfficer Report EmergencyButton ReportEmergencyControl ReportEmergency Form Emergency Report ManageEmergency Control press() > fillContents() submit() submitReport() submitReportToDispatcher() >

22. Fall 2015CISC/CMPE320 - Prof. McLeod22 Dispatcher IncidentForm ManageEmergency Control > createIncident() submit() submitReportToDispatcher() Incident Acknowledgment >

23. Fall 2015CISC/CMPE320 - Prof. McLeod23 FieldOfficer AcknowledgementNotice ManageEmergency Control ReportEmergency Control > dismiss() acknowledgeReport() endReportTransaction() >

24. Sequence Diagrams, Cont. Think of the time line as going from top, left to bottom, right. List the objects like column headers across the top. For these objects you are interested in: –When is the object created and who creates it. –Which objects interact with the object and in what order. –The nature of this interaction. –If and when the object is destroyed. Fall 2015CISC/CMPE320 - Prof. McLeod24

25. Fall 2015CISC/CMPE320 - Prof. McLeod25 Sequence Diagrams, Cont. From the left: –First column should be the actor who initiates the use case. –Second column should be the boundary object that the actor used to initiate the use case. –Third column should be the control object that manages the rest of the use case. The initiated boundary objects create the control object. Other boundary objects are created by control objects.

26. Fall 2015CISC/CMPE320 - Prof. McLeod26 Sequence Diagrams, Cont. Entity objects are accessed by both control and boundary objects. Entity objects never access boundary or control objects. (This way entity objects can be shared by many use cases.)

27. Fall 2015CISC/CMPE320 - Prof. McLeod27 Sequence Diagrams, Cont. Lets the designer know what responsibilities belong to which objects, and the order in which they take place. Time consuming to create – focus on problematic or underdeveloped functionality first.

28. Fall 2015CISC/CMPE320 - Prof. McLeod28 An Agile Analysis Technique – CRC Cards Class, Responsibilities, Collaborators Example (on recipe cards or “post-it” notes…): ReportEmergencyControl Responsibilities Collect input from FieldOfficer. Control sequence of forms during emergency reporting. Collaborators EmergencyReportForm EmergencyReport AcknowledgementNotice

29. Fall 2015CISC/CMPE320 - Prof. McLeod29 CRC Cards, Cont. The technique was documented in 1989 (Beck and Cunningham). Suited to a brain-storming session: –Lock all your coders and architects, etc into a banquet room at the local hotel. Have all their meals brought in. –(No booze until later…) –Lots of whiteboards, post-it notes, recipe cards, pencils and little magnets, etc.

30. Fall 2015CISC/CMPE320 - Prof. McLeod30

31. Fall 2015CISC/CMPE320 - Prof. McLeod31 CRC Cards, Cont. Discuss scenarios and agree upon objects as identified in scenarios. Can be done in teams or in one large group. Create one card per object. Add responsibilities and collaborators to each card. Lay cards out on the board or on a table to see how events flow and how objects interact (take pictures).

32. Fall 2015CISC/CMPE320 - Prof. McLeod32 CRC Cards, Cont. Good: –Simple –Works better with a large group –Can rough out a design in a fairly short time Bad: –How can you precisely document the results of the brainstorming session? –Do you have to rely on everyone’s memory of how the objects interact? Might be a good way to start a more formal design effort.