Winter 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 2 due today. Assignment 3 is a GUI...

Winter 2015 CISC/CMPE320 - Prof. McLeod 1

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.


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


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.



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


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.


SDD as a Deliverable

• Looking for the SDD framework in place (in your Wiki!!!) by the end of next week – Sunday, March 8th.

• 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 8th!



SDD Contents

• Create something like this table of contents in your Wiki as a framework to hold your design information:

1. Introduction1. Purpose of system

2. Design goals

3. Definition, acronyms and abbreviations

4. References

5. Overview

2. Current software architecture (not needed for us)


SDD Contents, Cont.

3. Proposed software architecture1. 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.


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:



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



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)


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


Example from FRIENDAs a UML Class Diagram

Incident

LowPriority Emergency Disaster

CatInTree Earthquake NuclearMeltdown

TrafficAccident BuildingFire


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?


Aside - Mapping Natural Language to Model Components – Examples

As Language Model Component Example

Proper noun Instance Alice

Common noun Class Field Officer

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 Incident description


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


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.


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:



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.


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.


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


Control Objects in FRIEND

• From the “ReportEmergency” use case:

• “ReportEmergencyControl”– Running on “FieldOfficerTerminal”

• “ManageEmergencyControl”– Running on “DispatcherTerminal”


ReportEmergency Objects

• Entity:

Dispatcher, EmergencyReport, FieldOfficer, Incident, Acknowledgement

• Boundary:

AcknowledgementNotice, DispatcherTerminal, ReportEmergencyButton, EmergencyReportForm,

FieldOfficerTerminal, IncidentForm• Control:

ReportEmergencyControl, ManageEmergencyControl


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…


FieldOfficer

Report EmergencyButton

ReportEmergencyControl

ReportEmergencyForm

EmergencyReport

ManageEmergencyControl

press()<<create>>

<<create>>

<<create>>

fillContents()

submit()submitReport()

submitReportToDispatcher()

<<destroy>>


Dispatcher

IncidentForm


<<create>>

<<create>>

<<create>>

createIncident()

submit()

submitReportToDispatcher()

Incident

Acknowledgment

<<destroy>>


FieldOfficer

AcknowledgementNotice


ReportEmergencyControl

<<create>>

dismiss()

acknowledgeReport()

endReportTransaction()

<<destroy>>

<<destroy>>

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.




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



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



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

Winter 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 2 due today. Assignment 3 is a GUI...

Documents

Transcript of Winter 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 2 due today. Assignment 3 is a GUI...