Use Case Maps Introduction to Use Case Maps Daniel Amyot, Gunter Mussbacher [email protected] http://www.UseCaseMaps.org Page 2 Table of Contents Requirements & Software Engineering Issues Introduction to Use Case Maps UCM Usage 2001 Requirements Capture Architectural Evaluation Transformations to Designs and Tests 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 2001 Requirements Capture Architectural Evaluation Validation and Feature Interaction Detection
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
secure home ready to leave home X Basic Path commute X Responsibility Point elevator take elevator X Component (from circle to bar) 2001 in cubicle Bridging the Gap Between Requirements and Design with Use Case Maps
(generic) 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 Requirements Analysis/
High-level Design Detailed design Implementation 2001 NFR Use cases Problem modeling Use Case Maps Sequence/collaboration diagrams, statechart diagrams, class/object diagrams, component/deployment diagrams (UML); message sequence charts, SDL (ITU-T) Code Bridging the Gap Between Requirements and Design with Use Case Maps Page 11 UCM Notation - Hierarchy UCM Example: Commuting home ready to leave home transport secure
secure home home commute commute X X elevator take take elevator elevator X stay home Dynamic Stub Static Stub (selection policy) 2001 Bridging the Gap Between Requirements and Design with Use Case Maps in cubicle
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 transport X take 95 take 182 X X
take 97 X AND Fork 2001 OR Fork OR Join Bridging the Gap Between Requirements and Design with Use Case Maps AND Join Page 14 UCM Notation Dynamic Structures Generic UCM Example slot A create + create start + slot B move into - Slot (component)
move out pool A + move into copy Pool pool B destroy (component) destroy end 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] door close decide on
direction [stationary] below above in elevator motor down [requested] add to list motor stop no requests [else] at requested floor [more requests] door closing-delay 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. door open remove
from list Arrival Sensor approaching floor Select Destination 2001 moving motor up 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 up Scheduler down at floor below above in elevator at requested floor [requested] [not requested] moving select
elevator already add to on list decide on list direction [on list] [else] Arrival Sensor approaching floor Elevator door close stationarymemory motor up motor door down closing-delay remove from list Service Personnel switch on Arch. Alternative (I) 2001 motor stop door open
Bridging the Gap Between Requirements and Design with Use Case Maps Page 19 User down up at floor below Status&Plan Scheduler [not requested] select elevator already on list Elev. Mgr above [requested] Arrival Sensor Elev. Control approaching floor moving [on list] in elevator
at requested floor [else] Status&Plan add to list remove from list decide on direction Elevator door close stationarymemory door closingdelay motor up motor down Service Personnel switch on Arch. Alternative (II) 2001
Bridging the Gap Between Requirements and Design with Use Case Maps motor stop door open 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! 2001 Many are located in stubs and selection policies Need more formal analysis 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 busy 2001 ARC out busy Bridging the Gap Between Requirements and Design with Use Case Maps out Page 24 Feature Interaction
Unexpected behavior among different selected plugins 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 in 2001 CF deny in Bridging the Gap Between Requirements and Design with Use Case Maps redirect 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 Synthetic approach build-and-test construction 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
