1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

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

28. 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

29. 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

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

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

32. 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

33. 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

34. 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

35. 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