Use
Cas
e M
aps
Daniel Amyot, [email protected]
http://www.UseCaseMaps.org
Carleton UniversityNovember 15, 2001
Bridging the Gap Between Requirements and Design
with Use Case Maps
© 2001
Page 2
Bridging the Gap Between Requirements and Design with Use Case Maps
Requirements Engineering Issues
u Early focus on low-level abstractions
u Requirements and high-level decisions buried in the details
u Evolution of functionalities difficult to handle (feature interactions, V&V, adaptability to legacy architectures...)
u Delay introduction of new services
© 2001
Page 3
Bridging the Gap Between Requirements and Design with Use Case Maps
Software Engineering Issues
u Requirements/analysis models need to support new types of dynamic systems– Run-time modification of system structure– Run-time modification of behaviour
u Need to go from a requirements/analysis model to design models in a seamless way
u We propose Use Case Maps (UCMs)!
© 2001
Page 4
Bridging the Gap Between Requirements and Design with Use Case Maps
Use Case Maps (UCMs)
u The Use Case Maps notation allows illustrating a scenario path relative to optional components involved in the scenario (gray box view of system)
u UCMs are a scenario-based software engineering technique for describing causalrelationships between responsibilities of one or more use cases
u UCMs show related use cases in a map-like diagram
© 2001
Page 5
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 6
Bridging the Gap Between Requirements and Design with Use Case Maps
Why Use Case Maps?
u Bridge the modeling gap between requirements (use cases) and design
– Link behaviour and structure in an explicit and visual way– Provide a behavioural framework for making (evaluating)
architectural decisions at a high level of design– Characterize the behaviour at the architecture level once the
architecture is decided
u Convey a lot of information in a compact formu Use case maps integrate many scenarios - enables
reasoning about potential undesirable interactions of scenarios
© 2001
Page 7
Bridging the Gap Between Requirements and Design with Use Case Maps
Why Use Case Maps?
u Provide ability to model dynamic systems where scenarios and structures may change at run-time
– E-commerce applications– Telecommunication systems based on agents
u Simple, intuitive, low learning curve u Document while you designu Effective learning tool for people unfamiliar with the
domainu May be transformed (e.g. into MSC/sequence
diagrams, performance models, test cases)
© 2001
Page 8
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 9
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 10
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 11
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 12
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 13
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 14
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 15
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 16
Bridging the Gap Between Requirements and Design with Use Case Maps
Generic Problem with Scenarios
u Given a set of scenarios capturing informal (functional) requirements
u Specify (formally) the integration of scenarios– Undesirable emergent behaviour may result…
u Validate, i.e. look for logical errors and check against informal requirements
u Numerous tools and techniques can be applied (e.g. functional testing)
© 2001
Page 17
Bridging the Gap Between Requirements and Design with Use Case Maps
UCM Validation by Inspection
u Several problems detectable by inspection– Non-determinism in selection policies and OR-forks– Erroneous UCMs– Ambiguous UCMs, lack of comments
u Many feature interactions (FI) solved while integrating feature scenarios together
u Remaining undesirable FI need to be detected!– Many are located in stubs and selection
policies– Need more formal analysis
© 2001
Page 18
Bridging the Gap Between Requirements and Design with Use Case Maps
Feature Interaction
u 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 19
Bridging the Gap Between Requirements and Design with Use Case Maps
Feature Interaction
u Unexpected behaviour 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 20
Bridging the Gap Between Requirements and Design with Use Case Maps
Analysis Model Construction
u Source scenario model ⇒ Target analysis model
u Q1. What should the target language be?– Use Case Maps Specification ⇒ ?
u Q2. What should the construction strategy be?– Analytic approach
u build-and-test construction
– Synthetic approachu scenarios "compiled" into new target modelu interactive or automated
© 2001
Page 21
Bridging the Gap Between Requirements and Design with Use Case Maps
Specification-Validation Approach with LOTOS and UCMs
Results(Coverage)
Results(Coverage)
Test Suite(LOTOS)
Add tests ifnecessary
Add tests ifnecessary
Test CasesGeneration
Test CasesGeneration
Testing FrameworkAnd Patterns
Requirements
Bound UCM
Prototype(LOTOS)
Prototype(LOTOS)
Results(Functional)
Results(Functional)
ConstructionConstruction
Modify ifnecessary
Modify ifnecessary
TestingTesting
AllocationAllocation
Scenarios(UCM)
ArchitectureArchitecture
ConstructionGuidelines
© 2001
Page 22
Bridging the Gap Between Requirements and Design with Use Case Maps
Complementary Yet Compatible!
Use Case MapsScenario notation, readable, abstract, scalable, loose, relatively effortless to learn
Use Case MapsScenario notation, readable, abstract, scalable, loose, relatively effortless to learn
LOTOSMature formal language, good theories and tools for V&V and completeness &consistency checking.
LOTOSMature formal language, good theories and tools for V&V and completeness &consistency checking.
BothFocus on ordering of actionsHave similar constructs à simpler mappingHandle specifications with or without componentsHave been used to describe dynamic systems in the pastHave been used to detect feature interactions in the past
BothFocus on ordering of actionsHave similar constructs à simpler mappingHandle specifications with or without componentsHave been used to describe dynamic systems in the pastHave been used to detect feature interactions in the past
© 2001
Page 23
Bridging the Gap Between Requirements and Design with Use Case Maps
RequirementsRequirements
Scenarios(UCM)
StructureStructure
UCMs onStructure
Prototype(LOTOS)
Prototype(LOTOS)
Results(Functions)
Results(Functions)
Results(Coverage)
Results(Coverage)
Test Suite(LOTOS)
Add tests ifnecessary
Add tests ifnecessary
Test CasesGeneration
Test CasesGeneration
ConstructionConstruction
Modify ifnecessary
Modify ifnecessary
TestingTesting
AllocationAllocation
UCM-LOTOS Construction Guidelines
© 2001
Page 24
Bridging the Gap Between Requirements and Design with Use Case Maps
UCM-LOTOS Testing Framework
RequirementsRequirements
Scenarios(UCM)
StructureStructure
UCMs onStructure
Prototype(LOTOS)
Prototype(LOTOS)
Results(Functions)
Results(Functions)
Results(Coverage)
Results(Coverage)
Test Suite(LOTOS)
Add tests ifnecessary
Add tests ifnecessary
Test CasesGeneration
Test CasesGeneration
ConstructionConstruction
Modify ifnecessary
Modify ifnecessary
TestingTesting
AllocationAllocation
© 2001
Page 25
Bridging the Gap Between Requirements and Design with Use Case Maps
Structural Coverage
RequirementsRequirements
Scenarios(UCM)
StructureStructure
UCMs onStructure
Prototype(LOTOS)
Prototype(LOTOS)
Results(Functions)
Results(Functions)
Results(Coverage)
Results(Coverage)
Test Suite(LOTOS)
Add tests ifnecessary
Add tests ifnecessary
Test CasesGeneration
Test CasesGeneration
ConstructionConstruction
Modify ifnecessary
Modify ifnecessary
TestingTesting
AllocationAllocation
© 2001
Page 26
Bridging the Gap Between Requirements and Design with Use Case Maps
Scenario Definitions
u Enhances the behavioural modeling capability of UCM paths and path elements
u Requires a path data model (for conditions at various points along the path)– Currently, global and modifiable Boolean variables
u Values may be assigned to variables along a path
– In future, …u Variables may possibly have different typesu Variables may be scoped to paths or componentsu Scenarios may be structured into sub-scenarios
© 2001
Page 27
Bridging the Gap Between Requirements and Design with Use Case Maps
OnList
Up
Requested
ExampleUser
Arrival Sensor
Elevator Control System
abovebelow
decide ondirection
at floor
updown
selectelevator
approachingfloor
at requestedfloor
motorstop
doorclosing-delay
[requested]
dooropen
removefrom list
Service Personnelswitch on
stationary-memory
[not requested]
[else]
[on list]
already on list
inelevator
add to list
movingdoor close
motor up
motor down
BR: !OnList BL: OnListBR: !Up BL: UpBR: Requested BL: !Requested
© 2001
Page 28
Bridging the Gap Between Requirements and Design with Use Case Maps
Scenario Definitions
u Requires a more formal definition of some notational elements– Currently, logical expressions with global variables– Currently, OR forks, selection policies, start points,
waiting places, & timers covered (in future: loops)
u Scenario definitions consist of …– Name of scenario (scenarios may be grouped for
convenience)– Set of concurrent start points– Set of initial values assigned to global variables
© 2001
Page 29
Bridging the Gap Between Requirements and Design with Use Case Maps
UCM Path Traversal
u Starts at one or more parallel start points as defined by user
u Starts with initial values (true, false, or undetermined) for each path data variable as defined by the user
u Moves from path element A to path element B if continuation criteria are met for element A– Each UCM path element has specific criteria
u Issues a warning if path traversal is stuck
© 2001
Page 30
Bridging the Gap Between Requirements and Design with Use Case Maps
����
X7
A RX6
X5X
4
X2
X1
X3
UCM Path Traversal - Example I
X7
A RX6
X5X
4
X2
X1
X3
A,12
4,��5,��
����
35
A,12,P��3,��
A,1,P��,6,��
,7,R
© 2001
Page 31
Bridging the Gap Between Requirements and Design with Use Case Maps
7,��
UCM Path Traversal - Example II
3B
P��4,��3,R
��
A SX8
X5X
4
X2
X1
X3
��
RB X
6
X7
5
A,12
4,��5,��
3,RB,6,��
P��P��3,R
��
A SX8
X5X
4
X2
X1
X3
��
RB X
6
X7
,8,S
© 2001
Page 32
Bridging the Gap Between Requirements and Design with Use Case Maps
Applications of UCM Path Traversal
u Highlightingu Animation
– Requires sequence numbers
u MSC generation– Requires component information – Well-nestedness transformation and warning mechanism
u LQN generation– Requires arrival and device characteristics, device demands,
data access modes, response-time requirements
u Test case generation– Requires controllable and observable activities
© 2001
Page 33
Bridging the Gap Between Requirements and Design with Use Case Maps
down
ExampleUser
Arrival Sensor
Elevator Control System
abovebelow
decide ondirection
at floor
updown
selectelevator
approachingfloor
at requestedfloor
motorstop
doorclosing-delay
[requested]
dooropen
removefrom list
Service Personnel
stationary-memory
[not requested]
[else]
[on list]
already on list
inelevator
add to list
movingdoor close
motor up
motor down
at floor
down
selectelevator
[on list]
already on list
add to list
switch on
OnList
© 2001
Page 34
Bridging the Gap Between Requirements and Design with Use Case Maps
!OnList
!Requested
ExampleUser
at floor
d own
elevator
approachingfloor
s top
-delay
d oor
r emovefrom list
Service Personnel
memory
[ else]
already on list
i n
m ovingm otor up
[ else]
d eci de ondi r ec t ion
i n-
door closem ovingm oving
approachingfloor
d oorclosing-delay
s top
[requested]
o pen
stationary-
[off] e xit
switch onabove
a pp. floor
s witch off
! OffOff
switch on
s wit ch off
Selected Contributionsu Amyot, D., Andrade, R., Logrippo, L., Sincennes, J., and Yi, Z. (1999) Formal Methods for Mobility
’99, Richardson, USA, D. and Andrade, R. (1999) Description of Wireless Intelligent Network Services with Use Ca
M aps. SBRC’99, Rio de Janeiro, Brazil, D., Buhr Gray, T., and , L. (1999) Use Case Maps for the Capture and Validation of
. ISRE'99, Limerick, Ireland, D. and Logrippo Use Case Maps and LOTO Sfor the Prototyping and Validation of a
. Computer Communication, 23(12)., D., Charfi Gray, T., , L., Sincennes Stepien, B., and Ware, T. (2000)
Feature description and feature interaction analysis with Use Case Maps and LO TOS. FI W'0 0, Sc otland.u Amyot, D. (2000), Use Case Maps as a Feature Description Notation. In: L ang uag e C onstruct s f o r
Designing Features, Gl asg ow, Sc otl and .u Amyot, D., and Logrippo, L. (2000) Structural Coverage for Lotos—A Probe Insertion Technique.
T est Co m ’2 000, Ottawa, Canada., D. and Mussbacher On the Extension of UML with Use Case Maps Concepts.
Y ork, UKu Amyot, D. and Eberlein, A. (2001) An Evaluation of Scenario Notations for Telecommunication Systems
. ICTS'01, Dallas, USAu Am yot, D. (2001) Specification and Validation of Telecommunications Systems with Use Case Maps and
LOTOS. Ph.D. thesis, University of Ottawa, Canadau Cameron, D. et al. (2001) Draft Specification of the User Requirements Notation, C ana dia n con t rib uti on to
-Tu Miga, A ., Amy ot, D., B ord ele au, F . , C am e ron, D ., and Wo odside, M . ( 200 1) Der ivi ng Mes sage S equ enc e
C har ts fro m U se Cas e M aps Sc enario Sp ec i fic ati ons . 10th S DL Forum, Co pen hag en, De nmarku Mussbacher, G. and Amyot, D. (2001) A Collection of Patterns for Use Case Maps,
2001, Rio de Janeiro, Brazil