Winter 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 2 due today. Assignment 3 is a GUI – posted soon. Due the end of next week. Project work – the SDD is also “due” the end of next week. “CommonGround” Wiki created. Additional issue type: “task”. Back to Software Engineering for a while. –Including what the SDD is and what goes in it.

Project Grading You will be getting: –A document with feedback on your Wiki, RAD, Presentation, and work efforts. –Grades for your RAD and Presentation. –Interim grade for your peer reviews (as a %). Read the feedback document carefully. Winter 2015CISC/CMPE320 - Prof. McLeod2

Crunch Time! Focus on a do-able proof of concept first. Test this before you go on to adding features. Make sure your libraries do what you want them to do. Can all team members install and use the libraries? Start testing asap – so, you need something to test! If you are splitting into sub-teams, create a plan that allows integration testing of the results. Assign a team member to be responsible for system testing and assigning bugs/additional work (“feature request”). Winter 2015CISC/CMPE320 - Prof. McLeod3

The Crunch, Cont. Figure out an organization for your repository before it gets out of hand. Everyone has to use the repository. Leverage issues. Redmine will track document changes – tracks everything, in fact. If something does not go into Redmine, then it doesn’t exist!!! Keep your diaries current. Winter 2015CISC/CMPE320 - Prof. McLeod4

Winter 2015CISC/CMPE320 - Prof. McLeod5 Subsystem Decomposition System Design Object Model Analysis Object Model Non-functional requirements Requirements Elicitation Problem Statement Functional Model Analysis Dynamic Model System Design Design Goals Use Case Diagram Class Diagram Statechart Diagram Sequence Diagram RAD SDD

Winter 2015CISC/CMPE320 - Prof. McLeod6 Deliverable System Object Design Model Object Design Implementation Source Code Testing Class Diagram This is not a flowchart. The stages are not necessarily carried out in this order. No iteration or feedback is shown.

SDD The RAD is usually a one-shot deal, viewed and approved of by the client. “Software Design Document” The SDD is for the development team only – it is not shown to the client. It is technical – more diagrams than words. It should be a dynamic document or just a framework that evolves or fills in as the design of your project changes. Well suited to the Wiki environment because it is dynamic and everyone can view and contribute. Winter 2015CISC/CMPE320 - Prof. McLeod7

SDD as a Deliverable Looking for the SDD framework in place (in your Wiki!!!) by the end of next week – Sunday, March 8 th. You do not have to use all categories, but need to have put what analysis results you have in the right places. The SDD will keep changing – even after the 8 th ! Winter 2015CISC/CMPE320 - Prof. McLeod8

Winter 2015CISC/CMPE320 - Prof. McLeod9 SDD Contents Create something like this table of contents in your Wiki as a framework to hold your design information: 1.Introduction 1.Purpose of system 2.Design goals 3.Definition, acronyms and abbreviations 4.References 5.Overview 2.Current software architecture (not needed for us)

Winter 2015CISC/CMPE320 - Prof. McLeod10 SDD Contents, Cont. 3.Proposed software architecture 1.Overview 2.Subsystem decomposition 3.Hardware/software mapping 4.Persistent data management 5.Access control and security 6.Global flow control 7.Boundary conditions 4.Subsystem services 5.Glossary

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. Winter 2015CISC/CMPE320 - Prof. McLeod11

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: Winter 2015CISC/CMPE320 - Prof. McLeod12

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

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.) Winter 2015CISC/CMPE320 - Prof. McLeod14

Winter 2015CISC/CMPE320 - Prof. McLeod15 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)

Winter 2015CISC/CMPE320 - Prof. McLeod16 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++).

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

Winter 2015CISC/CMPE320 - Prof. McLeod18 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?

Winter 2015CISC/CMPE320 - Prof. McLeod19 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

Winter 2015CISC/CMPE320 - Prof. McLeod20 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”).

Winter 2015CISC/CMPE320 - Prof. McLeod21 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.

Winter 2015CISC/CMPE320 - Prof. McLeod22 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.

Example Take apart the ReportEmergency use case from the FRIEND example: Winter 2015CISC/CMPE320 - Prof. McLeod23

Winter 2015CISC/CMPE320 - Prof. McLeod24 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.

Winter 2015CISC/CMPE320 - Prof. McLeod25 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.

Winter 2015CISC/CMPE320 - Prof. McLeod26 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.

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

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

Winter 2015CISC/CMPE320 - Prof. McLeod29 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…

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

Winter 2015CISC/CMPE320 - Prof. McLeod31 Dispatcher IncidentForm ManageEmergency Control > createIncident() submit() submitReportToDispatcher() Incident Acknowledgment >

Winter 2015CISC/CMPE320 - Prof. McLeod32 FieldOfficer AcknowledgementNotice ManageEmergency Control ReportEmergency Control > dismiss() acknowledgeReport() endReportTransaction() >

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 (and who) creates the object. –Which objects interact with the object and in what order. –The nature of this interaction. –If and when the object is destroyed. Winter 2015CISC/CMPE320 - Prof. McLeod33

Winter 2015CISC/CMPE320 - Prof. McLeod34 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.

Winter 2015CISC/CMPE320 - Prof. McLeod35 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.)

Winter 2015CISC/CMPE320 - Prof. McLeod36 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.