Use Case Maps

Introduction to
Use Case Maps

Daniel Amyot, Gunter Mussbacher

damyot@site.uottawa.ca
http://www.UseCaseMaps.org
Page 2

Table of Contents
 Requirements & Software Engineering Issues
 Introduction to Use Case Maps
 UCM Usage
– Requirements Capture
– Architectural Evaluation
– Transformations to Designs and Tests

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 3

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 4

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 5

Table of Contents
 Requirements & Software Engineering Issues
 Introduction to Use Case Maps
 UCM Usage
– Requirements Capture
– Architectural Evaluation
– Validation and Feature Interaction Detection

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 6

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 7

UCM Notation - Basic

UCM Example: Commuting

home transport elevator

secure take
ready commute
home elevator
to in
leave X X X cubicle
home

Basic Path Responsibility Point Component

(from circle to bar) (generic)

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 8

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 9

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 10

The Development Pyramid

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 11

UCM Notation - Hierarchy

UCM Example: Commuting

home transport elevator

secure take
secure commute take
ready home commute elevator
home elevator
to in
leave X X X cubicle
home

stay
home
Dynamic Stub Static Stub
(selection policy)

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 12

UCM Notation - Simple Plug-in

UCM Example: Commute - Car (Plug-in)

transport

drive car
X

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 13

UCM Notation - AND/OR

UCM Example: Commute - Bus (Plug-in)
person
read
Dilbert
X
transport

take 95 take 182

X
take 97
X
X
AND Fork OR Fork OR Join AND Join

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 14

UCM Notation -
Dynamic Structures
Generic UCM Example
slot A Slot
create create (component)
start
+
+
pool A move out
slot B
+
move into move into
copy Pool
- (component)
destroy pool B
-
end
destroy
Dynamic Responsibilities and Dynamic Components

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 15

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 16

User Elevator Control System

[not requested]
[moving]
motor up moving
door close
decide on
below direction motor down
above [stationary]

in [requested]
add to list
elevator motor
no requests stop
door
[more requests] open
[else] door remove
at requested closing-delay from list
floor

The elevator control system case study is adapted from Arrival Sensor
Hassan Gomaa's Designing Concurrent, Distributed,
And Real-Time Applications with UML (p459-462),
copyright Hassan Gomaa 2001, published by Addison approaching
Wesley. Used with permission. floor
Select Destination
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 17

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 18

User Scheduler
down [requested] Arrival Sensor
up [not requested]
moving approaching
select floor
at floor elevator

below already Elevator

above add to on list
list decide on door
direction close
in [on list]
elevator
[else]
stationary-
at requested memory motor
floor up
motor
door down
closing-delay
remove from list
Service Personnel motor
switch on stop

Arch. Alternative (I) door open

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 19

User
Status&Plan
down
up Scheduler [not requested] [requested]

select
elevator Arrival Sensor
at floor Elev. Control
already approaching
on list moving floor
below Elev. Mgr
above [on list]
decide on Elevator
in direction
elevator [else] door
close
Status&Plan
stationary-
add to memory
list
at requested
floor door motor
closing- up
delay motor
remove down
from list
Service Personnel
switch on motor
stop

Arch. Alternative (II) door open

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 20

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 21

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 22

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 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 23

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)

ORIG TERM
in out

CW ARC
busy out busy out

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 24

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
ORIG TERM
in out

OCS CF
in deny in redirect

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 25

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, …)

© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps