Embed Size (px)
Citation preview
Use
Cas
e M
aps
Daniel Amyot, Gunter [email protected]
http://www.UseCaseMaps.org
Introduction toUse Case Maps
© 2001
Page 2
Bridging the Gap Between Requirements and Design with Use Case Maps
Table of Contents
Requirements & Software Engineering Issues Introduction to Use Case Maps UCM Usage
– Requirements Capture– Architectural Evaluation– Transformations to Designs and Tests
© 2001
Page 3
Bridging the Gap Between Requirements and Design with Use Case Maps
Requirements Engineering Issues
Early focus on low-level abstractions Requirements and high-level decisions buried
in the details Evolution of functionalities difficult to handle
(feature interactions, V&V, adaptability to legacy architectures...)
Delay introduction of new services
© 2001
Page 4
Bridging the Gap Between Requirements and Design with Use Case Maps
Software Engineering Issues
Requirements/analysis models need to support new types of dynamic systems– Run-time modification of system structure– Run-time modification of behaviour
Need to go from a requirements/analysis model to design models in a seemless way
We propose Use Case Maps (UCMs)!
© 2001
Page 5
Bridging the Gap Between Requirements and Design with Use Case Maps
Table of Contents
Requirements & Software Engineering Issues Introduction to Use Case Maps UCM Usage
– Requirements Capture– Architectural Evaluation– Validation and Feature Interaction Detection
© 2001
Page 6
Bridging the Gap Between Requirements and Design with Use Case Maps
Use Case Maps (UCMs)
The Use Case Maps notation allows illustrating a scenario path relative to optional components involved in the scenario (gray box view of system)
UCMs are a scenario-based software engineering technique for describing causal relationships between responsibilities of one or more use cases
UCMs show related use cases in a map-like diagram
© 2001
Page 7
Bridging the Gap Between Requirements and Design with Use Case Maps
UCM Notation - Basic
UCM Example: Commuting
securehome
X X
commute
X
takeelevator
readyto
leavehome
incubicle
home transport elevator
Responsibility PointBasic Path(from circle to bar)
Component(generic)
© 2001
Page 8
Bridging the Gap Between Requirements and Design with Use Case Maps
Why Use Case Maps?
Bridge the modeling gap between requirements (use cases) and design
– Link behavior and structure in an explicit and visual way– Provide a behavioral framework for making (evaluating)
architectural decisions at a high level of design– Characterize the behavior at the architecture level once the
architecture is decided
Convey a lot of information in a compact form Use case maps integrate many scenarios - enables
reasoning about potential undesirable interactions of scenarios
© 2001
Page 9
Bridging the Gap Between Requirements and Design with Use Case Maps
Why Use Case Maps?
Provide ability to model dynamic systems where scenarios and structures may change at run-time
– E-commerce applications– Telecommunication systems based on agents
Simple, intuitive, low learning curve Document while you design Effective learning tool for people unfamiliar with the
domain May be transformed (e.g. into MSC/sequence
diagrams, performance models, test cases)
© 2001
Page 10
Bridging the Gap Between Requirements and Design with Use Case Maps
The Development Pyramid
Requirements
Analysis/ High-level Design
Detailed design
Implementation
NFRUse cases
Problem modeling
Use Case Maps
Sequence/collaboration diagrams, statechartdiagrams, class/object diagrams,
component/deployment diagrams (UML);message sequence charts, SDL (ITU-T)
Code
© 2001
Page 11
Bridging the Gap Between Requirements and Design with Use Case Maps
UCM Notation - Hierarchy
UCM Example: Commuting
readyto
leavehome
incubicle
home transport elevator
securehome
X X
commute
X
takeelevator
securehome
commutetake
elevator
Dynamic Stub(selection policy)
Static Stub
stayhome
© 2001
Page 12
Bridging the Gap Between Requirements and Design with Use Case Maps
UCM Notation - Simple Plug-in
UCM Example: Commute - Car (Plug-in)
transport
X
drive car
© 2001
Page 13
Bridging the Gap Between Requirements and Design with Use Case Maps
UCM Notation - AND/OR
UCM Example: Commute - Bus (Plug-in)
person
readDilbert
X
X
take 182
AND Fork OR JoinOR Fork AND Join
transport
Xtake 97
Xtake 95
© 2001
Page 14
Bridging the Gap Between Requirements and Design with Use Case Maps
-
UCM Notation - Dynamic Structures
Generic UCM Example
start
end
Dynamic Responsibilities and Dynamic Components
slot A
pool A
pool B
++
create create
slot B
copy
destroy
-
destroy
+
move out
move intomove into
Generic UCM Example
start
end
slot A
pool A
pool B
++
create create
move outslot B
move intocopy
move into
destroy
-
-
destroy
+
Slot(component)
Pool(component)
© 2001
Page 15
Bridging the Gap Between Requirements and Design with Use Case Maps
Table of Contents
Requirements & Software Engineering Issues Introduction to Use Case Maps UCM Usage
– Requirements Capture– Architectural Evaluation– Validation and Feature Interaction Detection– Transformations to Designs and Tests
Standardization Research Issues
© 2001
Page 16
Bridging the Gap Between Requirements and Design with Use Case Maps
User Elevator Control System
inelevator
abovebelow
at requestedfloor
Arrival Sensor
approachingfloor
doorclosing-delay
add to list
[else]
no requests
[stationary]
[moving][not requested]
door closemotor up
motor down
moving
decide ondirection
motorstop
[requested]
dooropen
Select Destination
removefrom list
[more requests]
The elevator control system case study is adapted from Hassan Gomaa's Designing Concurrent, Distributed, And Real-Time Applications with UML (p459-462), copyright Hassan Gomaa 2001, published by Addison Wesley. Used with permission.
© 2001
Page 17
Bridging the Gap Between Requirements and Design with Use Case Maps
Table of Contents
Requirements & Software Engineering Issues Introduction to Use Case Maps UCM Usage
– Requirements Capture– Architectural Evaluation– Validation and Feature Interaction Detection– Transformations to Designs and Tests
Standardization Research Issues
© 2001
Page 18
Bridging the Gap Between Requirements and Design with Use Case Maps
User
Arrival Sensor
Service Personnel
Scheduler
Elevator
inelevator
abovebelow
decide on direction
[else]
door close
motorup
motordown
moving
at floor
updown
selectelevator
approachingfloor
[not requested]
motorstop
[requested]
door open
at requestedfloor
stationary-memory
switch on
doorclosing-delay
add tolist
[on list]
alreadyon list
remove from list
Arch. Alternative (I)
© 2001
Page 19
Bridging the Gap Between Requirements and Design with Use Case Maps
User
Service Personnel
Elevator
Scheduler
Status&Plan
Status&Plan
Elev. Control
Elev. Mgr
inelevator
abovebelow
decide ondirection
[else] doorclose
motorup motor
down
moving
at floor
updown
selectelevator Arrival Sensor
approachingfloor
[not requested]
motorstop
door open
stationary-memory
switch on
doorclosing-delay
add tolist
alreadyon list
[on list]
[requested]
removefrom list
at requestedfloor
Arch. Alternative (II)
© 2001
Page 20
Bridging the Gap Between Requirements and Design with Use Case Maps
Table of Contents
Requirements & Software Engineering Issues Introduction to Use Case Maps UCM Usage
– Requirements Capture– Architectural Evaluation– Validation and Feature Interaction Detection– Transformations to Designs and Tests
Standardization Research Issues
© 2001
Page 21
Bridging the Gap Between Requirements and Design with Use Case Maps
Generic Problem with Scenarios
Given a set of scenarios capturing informal (functional) requirements
Specify (formally) the integration of scenarios– Undesirable emergent behaviour may result…
Validate, i.e. look for logical errors and check against informal requirements
Numerous tools and techniques can be applied (e.g. functional testing)
© 2001
Page 22
Bridging the Gap Between Requirements and Design with Use Case Maps
UCM Validation by Inspection
Several problems detectable by inspection– Non-determinism in selection policies and OR-forks– Erroneous UCMs– Ambiguous UCMs, lack of comments
Many feature interactions (FI) solved while integrating feature scenarios together
Remaining undesirable FI need to be detected!– Many are located in stubs and selection
policies– Need more formal analysis
© 2001
Page 23
Bridging the Gap Between Requirements and Design with Use Case Maps
Feature Interaction
Conflict between candidate plug-ins for the same stub (preconditions of plug-ins are the same)
– Call waiting (CW) vs. automatic re-call (ARC)
busy out
CW
busy out
ARC
in outORIG TERM
© 2001
Page 24
Bridging the Gap Between Requirements and Design with Use Case Maps
Feature Interaction
Unexpected behavior among different selected plug-ins for different stubs (postconditions of plug-ins are not the same)
– Originating call screening (OCS) denies call whereas call forward (CF) redirects call to screened number
in deny
OCS
in redirect
CF
in outORIG TERM
© 2001
Page 25
Bridging the Gap Between Requirements and Design with Use Case Maps
Analysis Model Construction
Source scenario model Target analysis model Q1. What should the target language be?
– Use Case Maps Specification ?
Q2. What should the construction strategy be?– Analytic approach
build-and-test construction
– Synthetic approach scenarios "compiled" into new target model interactive or automated
Several approaches studied (UCM to LOTOS, UCM to SDL, …)
