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. Email from Doug Martin with instr. Fall 2018 CISC/CMPE320 - Prof. McLeod Prof. Alan McLeod

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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