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