Use Case Maps Bridging the Gap Between Requirements

Use Case Maps Bridging the Gap Between Requirements and Design with Use Case Maps Daniel Amyot, Ph. D. http: //www. Use. Case. Maps. org

Page 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 UCM Validation by Inspection u Several problems may be detectable by inspection (JP: hum. . . ) – – Non-determinism in selection policies and OR-forks Erroneous UCMs u Many feature interactions (FI) solved while integrating feature scenarios together (ditto) 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 11 Feature Interaction (1) u Conflict between candidate plug-ins for the same stub (eg preconditions of plug-ins are the same) – Call waiting (CW) vs. automatic re-call (ARC) JP: same pre-conditions entails you do not know which will be chosen… ORIG TERM in out CW busy © 2001 ARC out busy Bridging the Gap Between Requirements and Design with Use Case Maps out

Page 12 Feature Interaction (2) u Unexpected behaviour 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 13 Scenario Definitions u Enhances the behavioural modeling capability of UCM paths and path elements u Requires a path data model (for conditions at various points along the path) – Currently, global and modifiable Boolean variables u – Values may be assigned to variables along a path In future, … (JP: hum…) Variables may possibly have different types u Variables may be scoped to paths or components u Scenarios may be structured into sub-scenarios u © 2001 Bridging the Gap Between Requirements and Design with Use Case Maps

Example Page 14 User up Elevator Control System down at floor below above in elevator [not requested] already on list select motor up moving door close elevator [on list] decide on motor down direction [off] [else] exit stationary[requested] memory add to list motor stop door closing-delay at requested floor Service Personnel switch on switch off © 2001 door open remove from list Arrival Sensor approaching floor Bridging the Gap Between Requirements and Design with Use Case Maps switch on above app. floor switch off !On. List Up !Requested !Off