Use Case Maps Introduction to Use Case Maps

Use Case Maps Introduction to Use Case Maps Daniel Amyot, Gunter Mussbacher damyot@site. uottawa. ca http: //www. Use. Case. Maps. org

Page 2 Table of Contents u Requirements & Software Engineering Issues u Introduction to Use Case Maps u 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 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 Bridging the Gap Between Requirements and Design with Use Case Maps

Page 4 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 seemless way u We © 2001 propose Use Case Maps (UCMs)! Bridging the Gap Between Requirements and Design with Use Case Maps

Page 5 Table of Contents u Requirements u Introduction u UCM – – – © 2001 & Software Engineering Issues to Use Case Maps Usage 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) 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 causal relationships between responsibilities of one or more use cases u 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? u Bridge the modeling gap between requirements (use cases) and design – – – u u 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? u Provide ability to model dynamic systems where scenarios and structures may change at run-time – – u u 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 ready to leave home transport secure home commute X X elevator take 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 u Requirements & Software Engineering Issues u Introduction to Use Case Maps u UCM Usage – Requirements Capture – Architectural Evaluation – Validation and Feature Interaction Detection – Transformations to Designs and Tests u Standardization u Research © 2001 Issues 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 (p 459 -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 u Requirements & Software Engineering Issues u Introduction to Use Case Maps u UCM Usage – Requirements Capture – Architectural Evaluation – Validation and Feature Interaction Detection – Transformations to Designs and Tests u Standardization u Research © 2001 Issues 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 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 Elev. Mgr above [requested] Arrival Sensor Elev. Control already on list 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 u Requirements & Software Engineering Issues u Introduction to Use Case Maps u UCM Usage – Requirements Capture – Architectural Evaluation – Validation and Feature Interaction Detection – Transformations to Designs and Tests u Standardization u Research © 2001 Issues Bridging the Gap Between Requirements and Design with Use Case Maps

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

Page 22 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! – – © 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 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) 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 u 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 u u Source scenario model Þ Target analysis model Q 1. What should the target language be? – u Use Case Maps Specification Þ ? Q 2. What should the construction strategy be? – Analytic approach u – Synthetic approach u u u 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