.

Net Software Architects

UG Meeting
Methodology for Use case
development

Arnon Rotem-Gal-Oz
Product Line Architect
arnon@rgoarchitects.com
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 /
Vision
not practical) Diagram
PDO
M
 A practical
prioritie
reasonable UC s
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 Police HQ

C om m ands

and relations Watch C om m ands

Com m ands

District
H as an Emergency
C enter

 Iterative
Commander

Is m ade of

development Is a
Sector
Allocated to
Rapid Response
Car

Is m ade of
Policeman Is a
Beat
Police C ar
Work in
Are
Allocated to
Allocated to Is a
Watch
D rive
Beat Team Beat Car
Step 4: Find Actors
 Identify
– Ask the End-Users
– Documentation

 Issues
– Roles Vs. Job Titles
– The Clock
 Actor Hierarchy

User Cop

User Log in
Emergency Watch
Center Operator Commander (from Actors)

Emergency HQ Watch
Center Supervisor Commander
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?
arnonrgo@cool.as
CHAOS Chronicles III - Jan. 2003
Success Factors
 Executive-management support
 User involvement “CHAOS research is
 Clear business objectives dedicated to solving
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?
– Plan Special Op.
– Monitor Special Op.
– Analyze Crime Patterns.
 What business event might this actor initiate (based on her role)?
– Handle Emergency Call
– Call Car for Service
 What services does the actor need from the system?
– Find Navigation Route
– Get Unit Status
– Map Incidents
 What services does the actor provide?
– Dispatch Units
– Issue Tickets
 What information does the actor need from the system?
– 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

(from Actors) Tap Communications

<<include>>
<<include>>

Hacker
(from Mis-Actors)
<<include>>
<<mitigate>>
Obtain Password
Hacker
(from Mis-Actors)
Enforce Password Regime
<<include>>

User Log in <<detect>> Obtain Password

(from Actors)

<<detect>>
Sys Admin
Monitor System
(from Actors)
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 Service/Maintenance management)

Why ?
How ?
<<trace>>
<<trace>>
<<trace>>

Service Cars Fix Car After Accident

Track Police Cars Usage (from Servi ce/Maintenance management)
(from Servi ce/Maintenance management)
(from Servi ce/Maintenance management)
Example : Refactoring
Common Sub-behavior

<<include>>

Respond to Incident
(from Inci dents Response)

Find Navigation Route

Beat Cop (from Navigation)
(from Actors) <<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