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

2. © 2001 Page 2 Bridging the Gap Between Requirements and Design with Use Case Maps Table of Contents u Requirements & Software Engineering Issues u Introduction to Use Case Maps u UCM Usage – Requirements Capture – Architectural Evaluation – Transformations to Designs and Tests

3. © 2001 Page 3 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

4. © 2001 Page 4 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 seemless way u We propose Use Case Maps (UCMs)!

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

6. © 2001 Page 6 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 causal relationships between responsibilities of one or more use cases u UCMs show related use cases in a map-like diagram

7. © 2001 Page 7 Bridging the Gap Between Requirements and Design with Use Case Maps UCM Notation - Basic UCM Example: Commuting secure home X X commute X take elevator ready to leave home in cubicle hometransportelevator Responsibility PointBasic Path (from circle to bar) Component (generic)

8. © 2001 Page 8 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 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 u Convey a lot of information in a compact form u Use case maps integrate many scenarios - enables reasoning about potential undesirable interactions of scenarios

9. © 2001 Page 9 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 design u Effective learning tool for people unfamiliar with the domain u May be transformed (e.g. into MSC/sequence diagrams, performance models, test cases)

10. © 2001 Page 10 Bridging the Gap Between Requirements and Design with Use Case Maps The Development Pyramid

11. © 2001 Page 11 Bridging the Gap Between Requirements and Design with Use Case Maps UCM Notation - Hierarchy UCM Example: Commuting ready to leave home in cubicle hometransportelevator secure home X X commute X take elevator secure home commute take elevator Dynamic Stub (selection policy) Static Stub stay home

12. © 2001 Page 12 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

13. © 2001 Page 13 Bridging the Gap Between Requirements and Design with Use Case Maps UCM Notation - AND/OR UCM Example: Commute - Bus (Plug-in) person read Dilbert X X take 182 AND ForkOR JoinOR ForkAND Join transport X take 97 X take 95

14. © 2001 Page 14 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 slot B copy destroy - + move out move into Generic UCM Example start end slot A pool A pool B + + create move out slot B move into copy move into destroy - - + Slot (component) Pool (component)

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

16. © 2001 Page 16 Bridging the Gap Between Requirements and Design with Use Case Maps User Elevator Control System in elevator above below at requested floor Arrival Sensor approaching floor door closing-delay add to list [else] no requests [stationary] [moving] [not requested] door close motor up motor down moving decide on direction motor stop [requested] door open Select Destination remove from 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.

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

18. © 2001 Page 18 Bridging the Gap Between Requirements and Design with Use Case Maps User Arrival Sensor Service Personnel Scheduler Elevator in elevator above below decide on direction [else] door close motor up motor down moving at floor up down select elevator approaching floor [not requested] motor stop [requested] door open at requested floor stationary- memory switch on door closing-delay add to list [on list] already on list remove from list Arch. Alternative (I)

19. © 2001 Page 19 Bridging the Gap Between Requirements and Design with Use Case Maps User Service Personnel Elevator Scheduler Status&Plan Elev. Control Elev. Mgr in elevator above below decide on direction [else] door close motor up motor down moving at floor up down select elevator Arrival Sensor approaching floor [not requested] motor stop door open stationary- memory switch on door closing- delay add to list already on list [on list] [requested] remove from list at requested floor Arch. Alternative (II)

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

21. © 2001 Page 21 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)

22. © 2001 Page 22 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

23. © 2001 Page 23 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) busyout CW busyout ARC inout ORIGTERM

24. © 2001 Page 24 Bridging the Gap Between Requirements and Design with Use Case Maps Feature Interaction u 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 indeny OCS inredirect CF inout ORIGTERM

25. © 2001 Page 25 Bridging the Gap Between Requirements and Design with Use Case Maps Analysis Model Construction 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 approach u scenarios "compiled" into new target model u interactive or automated u Several approaches studied (UCM to LOTOS, UCM to SDL, …)