Introduction to Use Case Maps
Page 2 Table of Contents
Introduction to
Requirements & Software Engineering Issues Use Case Maps
Introduction to Use Case Maps UCM Usage e Maps
By: I Gede Made Karma By: I Gede Made Karma s s
Requirements Capture – Architectural Evaluation
- – Taken from:
Transformations to Designs and Tests
- – Daniel Amyot, Gunter Mussbacher
damyot@site.uottawa.ca http://www.UseCaseMaps.org Use Ca
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps Page 3 Page 4
Requirements Engineering Software Engineering Issues Issues
Early focus on low-level abstractions Requirements/analysis models need to support new types of dynamic systems
Requirements and high-level decisions buried Run-time modification of system structure in the details
- – R n time modification of beha io r Run-time modification of behaviour –
Evolution of functionalities difficult to handle
Need to go from a requirements/analysis (feature interactions, adaptability to legacy model to design models in a seemless way architectures...)
Delay introduction of new services
We propose Use Case Maps (UCMs)!
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps © 2001 Bridging the Gap Between Requirements and Design with Use Case Maps Page 5 Page 6
Table of Contents Use Case Maps (UCMs) Requirements & Software Engineering Issues The Use Case Maps notation allows illustrating a scenario path relative to
Introduction to Use Case Maps optional components involved in the scenario
UCM Usage g (gray box view of system) (gray box view of system)
Requirements Capture
- –
UCMs are a scenario-based software Architectural Evaluation – engineering technique for describing causal
Validation and Feature Interaction Detection
- – relationships between responsibilities of one or more use cases
UCMs show related use cases in a map-like diagram
UCM Example: Commuting home transport elevator
- – Link behavior and structure in an explicit and visual way
- – Provide a behavioral framework for making (evaluating)
- – Characterize the behavior at the architecture level once the architecture is decided
X take elevator ready to leave home in cubicle Responsibility Point Basic Path (from circle to bar) Component (generic)
Problem modeling
X drive car
UCM Example: Commute - Car (Plug-in) transport
Page 12
X X commute
UCM Example: Commuting home transport elevator secure t take ready to leave home in cubicle secure home
Page 11 UCM Notation - Hierarchy
Code
Sequence/collaboration diagrams, statechart diagrams, class/object diagrams, component/deployment diagrams (UML); message sequence charts, SDL (ITU-T)
Use Case Maps
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps Analysis/ High-level Design Detailed design Implementation
NFR Use cases
Requirements
Bridge the modeling gap between requirements (use cases) and design
Page 7 UCM Notation - Basic
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps secure home
X X commute
Page 8 Why Use Case Maps?
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps architectural decisions at a high level of design
Convey a lot of information in a compact form Use case maps integrate many scenarios - enables reasoning about potential undesirable interactions of scenarios
Page 9 Why Use Case Maps?
Provide ability to model dynamic systems where scenarios and structures may change at run-time
- – E-commerce applications
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps 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)
Page 10 The Development Pyramid
- – Telecommunication systems based on agents
UCM Notation - Simple Plug-in
X take elevator home commute elevator Dynamic Stub (selection policy) Static Stub stay home
UCM Example: Commute - Bus (Plug-in) person read Dilbert
Generic UCM Example start slot A + + create create Generic UCM Example start slot A + + create create Slot (component)
Dilbert
X take 95
- - end Dynamic Responsibilities and Dynamic Components pool A pool B slot B copy destroy - destroy + move out move into move into end pool A pool B move out slot B move into copy move into destroy - - destroy + Pool (component)
- – Requirements Capture
- – Architectural Evaluation
- – Validation and Feature Interaction Detection –
Research Issues Page 18
Page 17 Table of Contents
Requirements & Software Engineering Issues Introduction to Use Case Maps
UCM Usage g
Validation and Feature Interaction Detection
Standardization
[else] door close moving at floor up down select elevator approaching floor
User Arrival Sensor
Scheduler Elevator in elevator above below decide on direction
remove from list [more requests]
[not requested] [requested] add to list
[on list] already on list
Service Personnel [else] motor up motor down motor stop door open at requested floor stationary- memory switch on door closing-delay remove from list
Arch. Alternative (I)
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.
[else] no requests stop door open
Introduction to Use Case Maps
UCM Usage © 2001 Bridging the Gap Between Requirements and Design with Use Case Maps g
X take 97
Page 14 UCM Notation - Dynamic Structures
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Page 15 Table of Contents
Requirements & Software Engineering Issues
at requested floor Arrival Sensor approaching floor door closing-delay
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 in elevator above below add to list no requests
[stationary] [moving]
[not requested] door close motor up motor down moving decide on direction motor stop
[requested]
Page 13 UCM Notation - AND/OR
X X take 182 AND Fork OR Join OR Fork AND Join transport
Select Destination
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
- – Requirements Capture
- – Architectural Evaluation –
- – Transformations to Designs and Tests
- – Requirements Capture
- – Architectural Evaluation
- – Validation and Feature Interaction Detection –
Many feature interactions (FI) solved while integrating feature scenarios together
Specify (formally) the integration of scenarios © 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Validate, i.e. look for logical errors and check against informal requirements
Numerous tools and techniques can be applied (e.g. functional testing)
Page 22 UCM Validation by Inspection
Several problems detectable by inspection
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
Remaining undesirable FI need to be detected!
Page 21 Generic Problem with Scenarios
policies
Page 23 Feature Interaction
Conflict between candidate plug-ins for the same stub (preconditions of plug-ins are the same)
busy out CW busy out ARC in out ORIG TERM Page 24
Feature Interaction Unexpected behavior among different selected plug- ins for different stubs (postconditions of plug-ins are not the same)
in deny OCS in redirect CF in out ORIG TERM
Given a set of scenarios capturing informal (functional) requirements
Transformations to Designs and Tests Standardization Research Issues
Arrival Sensor approaching floor
Scheduler Status&Plan
Introduction to Use Case Maps UCM Usage
Requirements & Software Engineering Issues
Page 20 Table of Contents
Service Personnel Status&Plan motor up motor down motor stop door open stationary- memory switch on door closing- delay add to list remove from list at requested floor
Page 19
[requested]
[not requested] already on list [on list]
User Elevator
[else] door close moving at floor up down select elevator
Elev. Mgr in elevator above below decide on direction
Status&Plan Elev. Control
Arch. Alternative (II)
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps g
© 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
- – Non-determinism in selection policies and OR-forks
- – Erroneous UCMs A bi UCM l k f t
- – Ambiguous UCMs, lack of comments
- – Undesirable emergent behaviour may result…
- – Many are located in stubs and selection
- – Need more formal analysis
- – Call waiting (CW) vs. automatic re-call (ARC)
- – Originating call screening (OCS) denies call whereas call forward (CF) redirects call to screened number
Source scenario model ⇒ Target analysis model Q1. What should the target language be?
- – Use Case Maps Specification ⇒ ?
Q2 What should the construction strategy be? © 2001 Bridging the Gap Between Requirements and Design with Use Case Maps
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, …)