CISC/CMPE320 - Prof. McLeod Winter 2013 CISC/CMPE320 2/17/2019 CISC/CMPE320 RAD marking is underway, still. You will get feedback in an Issue. SDD “Due” next Friday evening – Nov. 2 in Confluence. Assignment 3 is now due Nov. 6. See next slide… Fall 2018 CISC/CMPE320 - Prof. McLeod Prof. Alan McLeod

CISC/CMPE320 - Prof. McLeod Assignment 3 It is “different”! Read it over carefully. In summary: Create a *.dll file out of your fraction code from assignment 2 or use the sample solution (posted tonight). This can be done by changing g++ command line parameters in Eclipse along with some minor changes to your source code. Or it can be done in Visual Studio (or many other IDEs). Create a GUI fraction calculator that must use the *.dll file. Use whatever language/IDE you like to create the GUI. You might need to do some research for this one… Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod Today Instead of talking more about the heap, which would be fun: Software Analysis – techniques to help you flesh out your system architecture. Fall 2018 CISC/CMPE320 - Prof. McLeod

Back to Software Engineering Start with a more traditional view of the software engineering process. Where do the RAD and the SDD documents fit into the process? Fall 2018 CISC/CMPE320 - Prof. McLeod

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

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

Where to Start the Analysis? Focus on the User Stories and the resulting Functional and Non-Functional Requirements. Look over the RAD to identify the Objects that are part of your system. Fall 2018 CISC/CMPE320 - Prof. McLeod

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”) Epic names? Data sources or sinks Artifacts interacted with (like “Station”) Use Application Domain Terms! (Not “Solution Domain” terms) Fall 2018 CISC/CMPE320 - Prof. McLeod

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++). Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod Classifying Objects Take your set of participating objects, located by an examination of the RAD and user stories, and separate them into three categories: Entity Objects – Persistent information tracked by system. Boundary Objects – Where the actor interacts with the system. Control Objects – Makes it work! Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod Aside – “Actors” This is a traditional term that really just means “Users”. But it sometimes can include another separate system that is accessed by your system. You might have different types of users, that are characterized by the different way they interact with your sytem: Landlords, Tenants, Administrators, Players, Students, Professors, etc. Each would be represented by an “Actor”. Any system must have at least one Actor, and might have more than one. Fall 2018 CISC/CMPE320 - Prof. McLeod

Aside - Mapping Natural Language to Model Components – Examples As Language Model Component Example Proper noun Instance Alice Common noun Class Player Doing verb Operation Creates, submits Being verb Inheritance Is a kind of Having verb Aggregation Has, consists of Modal verb Constraints Must be Adjective Attribute Game score Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod FRIEND System Example This system is to be used by dispatchers and emergency responders to create an emergency response and then to record that response in a database. Start by looking over one “Use Case” that describes a typical use of the system. A Use Case is kind of like the script for a TV commercial. Short and Simple, but longer than a User Story… Fall 2018 CISC/CMPE320 - Prof. McLeod

ReportEmergency Use Case Example Use case name: ReportEmergency Participating Actors: Initiated by FieldOfficer Communicates with Dispatcher Flow of Events: FieldOfficer activates “Report Emergency” function on her laptop. 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. 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. Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod FRIEND receives the form and notifies the Dispatcher using a pop up dialog. 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. FRIEND displays the acknowledgement and response to the FieldOfficer. Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod 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. Fall 2018 CISC/CMPE320 - Prof. McLeod

Use Cases vs. User Stories Agile user stories are much shorter! A use case contains information on what the system is doing along a time line, it does not just describe a requirement. A use case can also contain non-functional requirements. Fall 2018 CISC/CMPE320 - Prof. McLeod

Equivalent User Stories? As an emergency supervisor I want to be able to collect, analyze and review all data for emergency responses through the use of a database, so problems can be corrected and system improvements can be made. Fall 2018 CISC/CMPE320 - Prof. McLeod

Equivalent User Stories?, Cont. As a field officer I want to be able to provide emergency information to the dispatcher by filling out a form on my laptop, so that all information is supplied, recorded and is not ambiguous. As a field officer I want to receive a response from the dispatcher that contains specifics about the response and the ETA so I know what to expect and I can judge if I think the response is adequate. Fall 2018 CISC/CMPE320 - Prof. McLeod

Equivalent User Stories?, Cont. As a dispatcher I want to receive notifications of new emergencies on my computer. As a dispatcher I want to be able to have a real-time view of the location and availability of my emergency response assets. As a dispatcher I want to be able to allocate assets to the new emergency and record this allocation. As a dispatcher I want to send an update to the field officer containing the response information so that they are informed of the details. Fall 2018 CISC/CMPE320 - Prof. McLeod

Non-Functional Requirements The field officer has a laptop running the system. The field officer’s original notification is received and acknowledged by the dispatcher within 30 seconds. The response details created by the dispatcher is received by the field officer within 30 seconds. Fall 2018 CISC/CMPE320 - Prof. McLeod

Use Cases vs. User Stories, Cont. To make a time to completion estimate for a user story, the team must eliminate any ambiguity in the story and discover non-functional requirements. Maybe break it down into separate sub-tasks?... As they discuss the user story, they seem to actually be building a use case, but normally they would not document it. Or the set of issues linked to the user story would acquire more detail. And, they would get to work on it right away! Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod Object Names, Cont. Go over the Object types in more detail and then: Continue the example, listing the object names obtained from this FRIEND system Use Case: Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod 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”). Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod 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. Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod 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. Fall 2018 CISC/CMPE320 - Prof. McLeod

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

CISC/CMPE320 - Prof. McLeod 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… Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod Report EmergencyButton ManageEmergencyControl FieldOfficer <<create>> ReportEmergencyControl press() <<create>> ReportEmergencyForm fillContents() submit() submitReport() EmergencyReport <<create>> submitReportToDispatcher() <<destroy>> Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod ManageEmergencyControl Dispatcher submitReportToDispatcher() IncidentForm <<create>> createIncident() <<create>> Incident submit() <<create>> Acknowledgment <<destroy>> Fall 2018 CISC/CMPE320 - Prof. McLeod

CISC/CMPE320 - Prof. McLeod ManageEmergencyControl ReportEmergencyControl FieldOfficer acknowledgeReport() <<create>> AcknowledgementNotice dismiss() endReportTransaction() <<destroy>> <<destroy>> Fall 2018 CISC/CMPE320 - Prof. McLeod

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. Fall 2018 CISC/CMPE320 - Prof. McLeod

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. Fall 2018 CISC/CMPE320 - Prof. McLeod

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.) Fall 2018 CISC/CMPE320 - Prof. McLeod

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. Fall 2018 CISC/CMPE320 - Prof. McLeod