Upload
sheila-cooper
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 2
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”).
Winter 2015 CISC/CMPE320 - Prof. McLeod 3
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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 4
Winter 2015 CISC/CMPE320 - Prof. McLeod 5
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
Winter 2015 CISC/CMPE320 - Prof. McLeod 6
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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 7
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!
Winter 2015 CISC/CMPE320 - Prof. McLeod 8
Winter 2015 CISC/CMPE320 - Prof. McLeod 9
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)
Winter 2015 CISC/CMPE320 - Prof. McLeod 10
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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 11
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:
Winter 2015 CISC/CMPE320 - Prof. McLeod 12
Winter 2015 CISC/CMPE320 - Prof. McLeod 13
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.)
Winter 2015 CISC/CMPE320 - Prof. McLeod 14
Winter 2015 CISC/CMPE320 - Prof. McLeod 15
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)
Winter 2015 CISC/CMPE320 - Prof. McLeod 16
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++).
Winter 2015 CISC/CMPE320 - Prof. McLeod 17
Example from FRIENDAs a UML Class Diagram
Incident
LowPriority Emergency Disaster
CatInTree Earthquake NuclearMeltdown
TrafficAccident BuildingFire
Winter 2015 CISC/CMPE320 - Prof. McLeod 18
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?
Winter 2015 CISC/CMPE320 - Prof. McLeod 19
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
Winter 2015 CISC/CMPE320 - Prof. McLeod 20
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”).
Winter 2015 CISC/CMPE320 - Prof. McLeod 21
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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 22
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:
Winter 2015 CISC/CMPE320 - Prof. McLeod 23
Winter 2015 CISC/CMPE320 - Prof. McLeod 24
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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 25
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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 26
• 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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 27
Control Objects in FRIEND
• From the “ReportEmergency” use case:
• “ReportEmergencyControl”– Running on “FieldOfficerTerminal”
• “ManageEmergencyControl”– Running on “DispatcherTerminal”
Winter 2015 CISC/CMPE320 - Prof. McLeod 28
ReportEmergency Objects
• Entity:
Dispatcher, EmergencyReport, FieldOfficer, Incident, Acknowledgement
• Boundary:
AcknowledgementNotice, DispatcherTerminal, ReportEmergencyButton, EmergencyReportForm,
FieldOfficerTerminal, IncidentForm• Control:
ReportEmergencyControl, ManageEmergencyControl
Winter 2015 CISC/CMPE320 - Prof. McLeod 29
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…
Winter 2015 CISC/CMPE320 - Prof. McLeod 30
FieldOfficer
Report EmergencyButton
ReportEmergencyControl
ReportEmergencyForm
EmergencyReport
ManageEmergencyControl
press()<<create>>
<<create>>
<<create>>
fillContents()
submit()submitReport()
submitReportToDispatcher()
<<destroy>>
Winter 2015 CISC/CMPE320 - Prof. McLeod 31
Dispatcher
IncidentForm
ManageEmergencyControl
<<create>>
<<create>>
<<create>>
createIncident()
submit()
submitReportToDispatcher()
Incident
Acknowledgment
<<destroy>>
Winter 2015 CISC/CMPE320 - Prof. McLeod 32
FieldOfficer
AcknowledgementNotice
ManageEmergencyControl
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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 33
Winter 2015 CISC/CMPE320 - Prof. McLeod 34
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.
Winter 2015 CISC/CMPE320 - Prof. McLeod 35
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.)
Winter 2015 CISC/CMPE320 - Prof. McLeod 36
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.