1. CISC/CMPE320 - Prof. McLeod
Winter 2013 CISC/CMPE320
2/15/2019
CISC/CMPE320
RAD marking is complete. Feedback and the grade is in the format of a Comment to the RAD document in Confluence.
SDD “Due” this Friday evening – Nov. 2 in Confluence.
Assignment 3 is now due Nov. 6 (a week from today).
VMs have been created for those teams that requested them. from Doug Martin with instr.
Fall 2018
CISC/CMPE320 - Prof. McLeod
Prof. Alan McLeod

2. CISC/CMPE320 - Prof. McLeod
Today
Continue Software Analysis – techniques to help you flesh out your system architecture.
The Analysis feeds the System Design process.
Fall 2018
CISC/CMPE320 - Prof. McLeod

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17. CISC/CMPE320 - Prof. McLeod
Fall 2018
CISC/CMPE320 - Prof. McLeod

18. CISC/CMPE320 - Prof. McLeod
CRC Cards, Cont.
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).
Fall 2018
CISC/CMPE320 - Prof. McLeod

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

20. Defining Relationships
We are trying to exactly define the relationships between actors and participating objects.
A Statechart diagram is the only other diagram that provides a dynamic view. It focuses on just a single object.
For example, look at a nested statechart diagram for the Incident object:
Fall 2018
CISC/CMPE320 - Prof. McLeod

21. CISC/CMPE320 - Prof. McLeod
Active
field officer arrives on site
Reported
Assessment
dispatcher allocates resources
field officer requests additional resources
Response
Disengagement
field officer releases resources
all resources deallocated
when date is greater than one year
all resources submitted reports
Inactive
Closed
Archived
Fall 2018
CISC/CMPE320 - Prof. McLeod

22. CISC/CMPE320 - Prof. McLeod
Statechart Diagrams
By concentrating on just a single object it is easier to see if there are any missing use cases. Or if a use case needs more refinement.
Fall 2018
CISC/CMPE320 - Prof. McLeod

23. From Before: Analysis as a UML Class Diagram
Use Case Diagram
Class Diagram
StateChart Diagram
Sequence Diagram
Functional Model
Object Model
Dynamic Model
Analysis Model
Fall 2018
CISC/CMPE320 - Prof. McLeod

24. CISC/CMPE320 - Prof. McLeod
Object Model Design
You might be using class diagrams to contain information about your classes:
Incident
dateCreated: Date
emergencyLevel: String …
setDateCreated()
setEmergencyLevel()
setOriginatingFieldOfficer() …
Fall 2018
CISC/CMPE320 - Prof. McLeod

25. Interface Specifications
You can start by deciding:
What is public, private and protected
The parameters and return types
Incident
means private
+ means public
# means protected
-dateCreated: Date
-emergencyLevel: String …
+setDateCreated(Date): void
+setEmergencyLevel(String): void
+setOriginatingFieldOfficer(FieldOfficer): void …
Fall 2018
CISC/CMPE320 - Prof. McLeod

26. Interface Specifications, Cont.
Add Contracts:
A contract consists of invariants, pre-conditions and post-conditions.
An invariant is something that is true for an attribute or for the entire class or interface.
A pre-condition is true before a method is invoked.
A post-condition is true after a method is invoked.
Fall 2018
CISC/CMPE320 - Prof. McLeod

27. After Software Analysis
Analysis has provided:
A set of Nonfunctional Requirements and Constraints
A System Model, expressed in:
Use Cases
Object Models
Sequence Diagrams
Statechart Diagrams …
Fall 2018
CISC/CMPE320 - Prof. McLeod

28. CISC/CMPE320 - Prof. McLeod
After System Design
End up with:
Design Goals
System qualities that need to be optimized
Software Architecture
Subsystem decomposed, mapped to hardware, decisions such as control flow, access control and data storage made.
Boundary Use Cases
System configuration, startup, shutdown and exception handling.
Fall 2018
CISC/CMPE320 - Prof. McLeod

29. Subsystem Decomposition
The aim is to identify and/or create classes (or packages of classes) that can be coded by a single coder.
Techniques used are Layering and Partitioning.
Concerned about Coupling between subsystems and Cohesion within a subsystem.
The Subsystems must address the design goals. Keep refining the Decomposition until the goals are satisfied.
Fall 2018
CISC/CMPE320 - Prof. McLeod

30. Identifying Subsystems
A subsystem is like a package in Java – a group of classes related by their functionality.
Like classes in a Java package, objects in a subsystem will have some coupling within the subsystem, but should have minimal coupling with other subsystems.
What is coupling anyways?
Fall 2018
CISC/CMPE320 - Prof. McLeod

31. Coupling and Cohesion Strong Cohesion, Weak Coupling
Strong Coupling, Weak Cohesion
Fall 2018
CISC/CMPE320 - Prof. McLeod

32. Coupling and Cohesion, Cont.
Coupling occurs between packages and cohesion occurs between methods.
Unlike the bad old days of languages that had (gasp!) goto statements (the horror!), modern OOP languages do their best to enforce strong cohesion and weak coupling.
Weak coupling allows you to make changes in one object and minimize the effects on other objects.
Strong cohesion means that methods are small and single-purpose.
Fall 2018
CISC/CMPE320 - Prof. McLeod

33. CISC/CMPE320 - Prof. McLeod
Layering
Two general kinds: Open Architecture and Closed Architecture (don’t confuse “Open” with “Non-Proprietary”, here!).
Fall 2018
CISC/CMPE320 - Prof. McLeod

34. Closed Architecture, in General
Most Abstract
Level 1
Subsystem A
Level 2
Subsystem B
Subsystem C
Subsystem D
Level 3
Subsystem E
Subsystem F
Subsystem G
Least Abstract
Fall 2018
CISC/CMPE320 - Prof. McLeod

35. Closed Architecture, Cont.
You cannot go from level 3 back to level 1 without going through level 2.
Subsystems A, B and E represent a complete Vertical Slice of the architecture, but subsystems D and G would not.
Fall 2018
CISC/CMPE320 - Prof. McLeod

36. Closed Architecture, Cont.
A layer can only access the layer immediately above or below it.
(In Java you can construct a closed object hierarchy.)
In an Open Architecture you can skip layers.
Fall 2018
CISC/CMPE320 - Prof. McLeod

37. Closed Architecture Example – OSI Model
Stands for “Open Systems Interconnection”
Most Abstract
Application
Key
Presentation
CORBA or Java RMI
Connection
Session
Message
Transport
Packet
Network
TCP/IP
Frame
DataLink
Bit
Physical
Ethernet
Fall 2018
CISC/CMPE320 - Prof. McLeod
Least Abstract

38. Open Architecture Example
Application
Swing
AWT
You can get improved performance by bypassing the Swing layer.
(Nowadays, JavaFX replaces the Swing and AWT layers). OS
Fall 2018
CISC/CMPE320 - Prof. McLeod

39. CISC/CMPE320 - Prof. McLeod
Layering and Coupling
The emergency response database system:
The Database subsystem is directly coupled to the other three subsystems, making these subsystems vulnerable to changes in Database design.
ResourceManagement
MapManagement
IncidentManagement
Database
Fall 2018
CISC/CMPE320 - Prof. McLeod

40. Layering and Coupling, Cont.
Add a layer:
Storage will have a more stable interface. If Database changes then only Storage will have to be modified. Less coupling to Database!
ResourceManagement
IncidentManagement
MapManagement
Storage
Database
Fall 2018
CISC/CMPE320 - Prof. McLeod

41. Coupling and Cohesion, Cont.
Usually have a tradeoff.
Limit to the number of layers formed by partitioning:
“Common Wisdom” says that developers can handle a maximum of 9 layers of abstraction.
Often as little as 3 layers is just fine!
7 ± 2
Fall 2018
CISC/CMPE320 - Prof. McLeod