Use Cases - Presentation
Download
Report
Transcript Use Cases - Presentation
.Net Software Architects
UG Meeting
Methodology for Use case
development
Arnon Rotem-Gal-Oz
Product Line Architect
[email protected]
The king’s Ship Wasa - 1628
No Architecture description
Changes done on the fly,
often under market/customer
pressure
Testing ignored
Didn’t know how to tell the
clients No
The system last longer than
was ever imagined
Maintenance costs far exceed
ordinary development
No Specification !
Agenda
Vocabulary
Why Use Cases?
Why should we care?
The challenges of UC modeling in large
projects
The Methodology
Summary
Vocabulary
Actor – Role(s) external parties that interact with
the system
Use Case – A sequence of actions that the system
performs that yields an observable result of value
to an actor. [Booch 1999]
Use Case Model - Bag that contains
– Actors list, packages, diagrams, use cases, views
Use Cases benefits
Promote customer involvement
Help manage complexity
– Layers
– Focus on real user needs
Groundwork for user manual, test cases
Help us work in iterations
Use cases aren’t everything
Non-behavioral requirements
– Performance
– Design constrains
– Etc.
Sometimes – an overkill
Use cases & Architects ?!
Requirements drive the design !!!
Help force designers focus on concrete issues
Help identifying technical and business risks
Can be used to help validate the architecture
Use cases & Architects ?! (cont.)
Architects should be involved in (if not responsible for)
- UC prioritization !
Architectural design workflow (Kruchten 2003):
–
–
–
–
–
–
–
–
Select scenarios : criticality and risk
Identify main classes/components and their responsibility
Distribute behavior
Structure into subsystems, layers and define interfaces
Define distribution and concurrency
Implement architectural prototype
Derive tests from use cases
Evaluate architecture
Overview
Use case modeling for large projects is
problematic
Most literature is lacking
(too simplistic /
Diagram
Vision
not practical)
PDO
M
A practical
prioritie
UC
s
reasonable
Verify
process is needed! Refactor
Validate
Tea
m
Naïve approach
Find Actors
Find Use Cases
Describe Use Cases
Challenges
Model
– Duplicates
– Explosion
– Making sure the requirements are good
Team
– Efficiency
– Fragmentation
Process
– Details too early
– Quitting Time
– Waterfall
The Methodology
To resolve the challenges we need a
process that is:
–
–
–
–
–
Ordered
Controlled
Not too complicated
Not too demanding
Flexible
Methodology – Initialization Steps
Define System Boundary
Organize the Team
Build a Problem Domain Object Model
Methodology - Process
Find Actors
Find Use Cases
Organize the Model
Prioritize Use Cases
Describe Use Cases
Refactor the Model
Methodology – Supporting Steps
Verify and Validate
Add Future Requierments
Methodology – End Game
Knowing when to stop !
Step 1: Define System Boundary
Vision and Scope
–
–
–
–
–
–
What problems are solved
Who are the stakeholders
Client’s Organization main goals
System main goals
Boundaries of the solution
Future Directions
Step 2: Organize the Team
Small teams
Heterogeneous
Multi-tier reviews
Requirements manager
Step 3: Build a PDOM
Terms
and relations
Iterative
development
Police HQ
Commands
Commands
Commands
Watch
Commander
Has an
District
Emergency
Center
Is made of
Is a
Allocated to
Sector
Rapid Response
Car
Is made of
Is a
Policeman
Beat
Police Car
Work in
Are
Allocated to
Watch
Beat Team
Allocated to
Drive
Beat Car
Is a
Step 4: Find Actors
Identify
– Ask the End-Users
– Documentation
Issues
– Roles Vs. Job Titles
– The Clock
Actor Hierarchy
User
Emergency
Center Operator
Emergency
Center Supervisor
Cop
Watch
Commander
HQ Watch
Commander
User
(from Actors)
Log in
Step 5: Find Use Cases
Scenario Driven
–
–
–
–
–
Find measurable value
Business events
Services actor needs / supplies
Information needed
Recurring
Actor/Responsibility
Unstructured aggregation
Mission decomposition
Misuse cases
Step 5: Find Use Cases ../2
Initial Description
–
–
–
–
–
Unique ID
Scope
Pre conditions
Success Guarantee
Trigger
Example : Initial description
Use Case: Run Special Op.
ID: UC4
Scope: The Watch Commander chooses a Special operation to manage.
The task team chosen for the operation is briefed
The watch commander then monitors the operation as it unfolds (sending out orders as needed)
The task team is debriefed for the results and a final report is made.
Primary Actor: Watch Commander
Preconditions: A Special Op. Plan is saved in the system.
Success Guarantees:
The Special Op. recordings (Forces movement, Voice recordings etc.) are saved in the system.
The operation's statistics are saved in the system.
Operation Final Report is saved and printed.
Trigger: The Watch Commander chooses a Special Op.
Step 6: Organize the Model
Ever Unfolding story
Category sets
– Status, scope, stakeholders, sub-systems
Subject Category hierarchy
Views
– Architectural view (i.e. SAD - Use Case
View)
Step 7: Prioritize Use Cases
Risk Classes
– Business Risks
– Architectural Risks
– Logistical Risks
Iterative development
– Small vs. Large projects
Step 8: Describe Use Cases
Template
–
–
–
–
–
–
–
–
–
–
Main success Scenario
Variations
Exception
Assumptions
Status
Priority
Stakeholders and concerns
Issues
Non-behavioral reqs.
Extension points.
Step 8 : Describe Use Cases ../2
Focus
Technology neutral
Activity diagrams
Step 9: Refactor the Model
Relations
–
–
–
–
Trace (decomposition)
Include (common sub-behavior)
Extend (promoted alternatives)
Generalize
Merge droplets
Step 10: Verify & Validate
Verification – Making sure we build the product
right
Validation – Making sure we build the right
product
Traceability
Inspection
Reviews
Walkthroughs
Prototypes
Step 10 : V&V ../2
Actors
– Are all the actors abstractions of specific
roles?
– Are all the actors clearly described, and do
you agree with the descriptions?
– Is it clear which actors are involved in which
use cases, and can this be clearly seen from
the use case diagram and textual descriptions
Step 10: V&V ../3
Use Cases
– Does the use case make sense?
– For each iteration: Are all the use cases described at
the same level of detail?
– Are there any superfluous use cases, that is, use cases
that are outside the boundary of the system, do not
lead to the fulfillment of a goal for an actor or
duplicate functionality described in other use cases?
– Do all the use cases lead to the fulfillment of exactly
one goal for an actor, and is it clear from the use case
name what is the goal
Step 10: V&V ../4
The Scenarios
– Are there any variants to the normal flow of events
that have not been identified in the use cases, that is,
are there any missing variations? (“happy days
scenarios”, exceptions, variation, “soup-opera
scenarios”)
– Are the triggers, starting conditions, for each use case
described at the correct level of detail?
– Does the behavior of a use case conflict with the
behavior of other use cases?
– Is the number of steps in the complex scenarios
excessive (12 to 15 is getting borderline)?
Step 10: V&V ../5
Organization & Prioritization
– Are all the use cases organized in an
appropriate manner (e.g. by functional area,
by dependency, by actor etc)?
– Are all the use cases within a package
consistent with the theme of the package?
– Is the priority mechanism documented?
– Are the use cases prioritized correctly?
Step 11: Add Future Requirements
Capture Change cases
– Preparing for change
– Impact analysis
Example: Future Requierments
Step 12: Knowing When to Stop
Project Level
– Complete list of actors and goals
– Customer approval
– Design ready
Iteration Level
– Covered all currently prioritized use cases
– Level of detail
Summary
What we have seen…
Additional Issues
– Project Management
– Requirements Management
– Configuration Management
Further Reading…
Writing Effective Use Cases (Cockburn)
Patterns for Effective Use Cases (Adolph
& Bramble)
Advanced Use Case Modeling (Armour &
Miller)
The End…
Questions/Full Article?
[email protected]
CHAOS Chronicles III - Jan. 2003
Success Factors
Executive-management support
“CHAOS research is
User involvement
dedicated to solving
Clear business objectives
the mystery of project
Minimizing scope
success and failure”
– Time is the enemy of all projects
– Scope equals time
Firm basic requirements
– Balance between "Paralysis through Analysis"
and what happens if requirements are not
specified
http://standishgroup.com
Example: Finding Use Cases
What measurable value is needed by the actor?
–
–
–
What business event might this actor initiate (based on her role)?
–
–
Dispatch Units
Issue Tickets
What information does the actor need from the system?
–
–
Find Navigation Route
Get Unit Status
Map Incidents
What services does the actor provide?
–
–
Handle Emergency Call
Call Car for Service
What services does the actor need from the system?
–
–
–
Plan Special Op.
Monitor Special Op.
Analyze Crime Patterns.
Get Car Registration History
List Duties
What are the activities that are recurring and triggered by time?
–
–
–
Get Updated Situation Awareness Map
Generate Emergency Center Statistics Report
Generate Crime Trends Report.
Example : Mis-Use Cases
Tap Communications
User
Log in
<<include>>
Tap Communications
(from Actors)
<<include>>
Hacker
<<include>>
(from Mis-Actors)
<<mitigate>>
Obtain Password
Enforce Password Regime
User
Log in
Hacker
(from Mis-Actors)
<<include>>
<<detect>>
Obtain Password
(from Actors)
Sys Admin
(from Actors)
<<detect>>
Monitor System
Example : Use Case
Use Case: Handle Emergency Call
ID: UC24
Scope: The Operator accepts an incoming call, enters the incident information and dispatch a unit to the location of the
incident
Stakeholders and Concerns:
Victim - wants the police to arrive as soon as possible
Beat Team – don't want to be dispatched to handle false incidents.
Primary Actor: Emergency Center Operator
Preconditions: Operator logged in.
Success Guarantees:
The Call has been recorded
A unit has been dispatch to investigate the incident
The incident details are saved in the system
Trigger: A Citizen's incoming call has been directed by the Call Center system to an Operator.
Example : Use Case ../2
Main Success Scenario:
1.The system begins recording the call.
2.The system traces the caller address.
3.The Operator takes the incidents location
4.The system calculates available police units.
5.The Operator takes the incidents detail
6.The system presents a list of available teams and their distance from the incidents estimated location.
7.The Operator chooses a unit to handle the incident
8.The system dispatches the incident details to the chosen team.
9.The Operator takes the caller details
10.The system saves the incidents details including call statistics
11.The system ends recording.
Variations:
1.step 2 - when the caller uses a mobile phone
a. Locate the callers current location
2.step 2 - when the caller is on the black list (known to call for no reason)
a.The Operator is presented with additional questions to ask the caller
b.The system marks the incident as low-priority on count of possible false alarm.
3.step 7 - when the incident does not require police intervention.
a.The Operator closes the incident
b.The system saves the termination reasons and continues from step 10
4.step 7 - if the incident requires a fire truck/ambulance
a. The Operator chooses which authority to notify (fire / ambulance etc)
b.The system dispatches the incident details to the appropriate authority's system
Example: Use Case ../3
Main Success Scenario:
1.
The system begins recording the call.
2.
The system traces the caller address.
3.
The Operator takes the incidents location
4.
The system calculates available police units.
5.
The Operator takes the incidents detail
6.
The system presents a list of available teams and their distance from the incidents estimated location.
7.
The Operator chooses a unit to handle the incident
8.
The system dispatches the incident details to the chosen team.
9.
The Operator takes the caller details
10.
The system saves the incidents details including call statistics
11.
The system ends recording.
Exceptions:
1.step 2 - when the call cannot be traced
a.The system suggests lowering the priority of the call on the count of an unknown caller
b.The operator decides what priority to allocate for the incident.
2.step 6 – when there is no available free force
a.The system presents the operator with low-priority incidents (along with the reason for low-priority
3.step 8 – communication problem with the unit dispatched
a.The system performs step 6 and 7 again.
4.step 8 – communication problem with all the units.
a.The system presents the operator the incidents details to allow dispatching by radio/mobile phone.
Non Behavioral Requirements:
The system should present as few screen as possible to the operator
Locating a free unit should take less than 30seconds
Communications to and from the unit should be secure (encrypted) to prevent eavesdropping by offenders/media
Example: Use Case Levels
Maintain Police Cars
(from Servi ce/Mai ntenance management)
<<trace>>
<<trace>>
<<trace>>
Service Cars
(from Servi ce/Mai ntenance management)
Fix Car After Accident
Track Police Cars Usage
(from Servi ce/Mai ntenance management)
(from Servi ce/Mai ntenance management)
Example : Refactoring
Common Sub-behavior
<<include>>
Respond to Incident
(from Incidents Response)
Find Navigation Route
Beat Cop
(from Actors)
(from Navigation)
<<include>>
Perform Assignment
(from Special Ops support)
Use Case View
Concerns
– What’s the conceptual framework in which the system
operates
– What are the key processes and events that must be
presented in the system
– Why the architecture is the way it is
Stakeholders
– Users
– Designers & Developers
Integrate the other views