1. TDT 4242 Inah Omoronyia and Tor Stålhane Advanced Use cases TDT 4242 Institutt for datateknikk og informasjonsvitenskap

2. TDT 4242 Advanced use cases Use cases: Based on work of Ivar Jacobson Based on experience at Ericsson building telephony systems Recommended refs: Writing Effective Use Cases, by Alistair Cockburn, Addison-Wesley, 2001 http://www.usecases.org

3. TDT 4242 Advanced use cases vocabulary – 1 Actor – External parties that interact with the system Roles are not job titles (roles cuts across job titles) Actors are not individual persons (e.g. John) but stimulates the system to react (primary actor) You normally don’t have control over primary actors Roles responds to the system’s requests (secondary actor) normally used by the system to get the job done An actor don’t have to be a person – it can also be e.g. another system or sub-system.

4. TDT 4242 Advanced use cases vocabulary – 2 Use Case – A sequence of actions that the system performs that yields an observable result of value to an actor. Use Case Model contains: Actors list, packages, diagrams, use cases, views A Use Case Model includes structured use case descriptions that are grounded in well-defined concepts constrained by requirements and scope Use case descriptions Concepts Constraints and requirements

5. TDT 4242 Finding Actors – 1 Important questions Who uses the system? Who gets information from the system? Who provides information to the system? What other systems use the system? Who installs, starts up, or maintains the system?

6. TDT 4242 Finding Actors – 2 Focus initially on human and other primary actors Group individuals according to their common tasks and system use Name and define their common role Identify systems that initiate interactions with the system Identify other systems used to accomplish the system’s tasks

7. TDT 4242 Finding use cases Describe the functions that the user wants from the system Describe the operations that create, read, update, and delete information Describe how actors are notified of changes to the internal state of the system Describe how actors communicate information about events that the system must know about

8. TDT 4242 Key points for use cases - 1 Building use cases is an iterative process You usually don’t get it right at the first time. Developing use cases should be looked at as an iterative process where you work and refine. Involve the stakeholders in each iteration

9. TDT 4242 Key points for use cases – 2 Define use case actors. UML visual notations are commonly used. Start by defining key actors: An actor can be a system because the system plays another role in the context of your new system and also interact with other actors Key users

10. TDT 4242 Key points for use cases – 3 Define your use case Actor Goals Note: Association relationships only show which actors interact with the system to perform a given use case. Association relationship DO NOT model the flow of data between the actor and the system. A directed association relationship only shows if the system or the actor initiates the connection. Note: Association relationships only show which actors interact with the system to perform a given use case. Association relationship DO NOT model the flow of data between the actor and the system. A directed association relationship only shows if the system or the actor initiates the connection.

11. An alternative path to use cases An approach from Siemens: 1.Start by filming the operations that shall be included in the use case. 2.Identify actors (system components) involved 3.Identify functions (actions), their sequence and the parts involved 4.By observing the driver we can also identify how the user moves between system states

15. TDT 4242 Reuse opportunity for use cases – 1 There is duplicate behavior in both the buyer and seller which includes "create an account" and "search listings". Extract a more general user that has the duplicate behavior and then the actors will "inherit" this behavior from the new user.

16. TDT 4242 Reuse opportunity for use cases – 2 Relationships between use cases: Dependency – The behavior of one use case is affected by another. Being logged into the system is a pre-condition to performing online transactions. Make a Payment depends on Log In Include – One use case incorporates the behavior of another at a specific point. Make a Payment includes Validate Funds Availability

17. TDT 4242 Reuse opportunity for use cases – 3 Relationships between use cases: Extends – One use case extends the behavior of another at a specified point, e.g. Make a Recurring Payment and Make a Fixed Payment both extend the Make a Payment use case Generalize – One use case inherits the behavior of another; it can be used interchangeably with its “parent” use case, e.g. Check Password and Retinal Scan generalize Validate User

18. Extend Respond to emergency Control center operator communication down > Request arrives through radio or phone

19. Generalize Request (re)scheduling of maintenance Already scheduled - reschedule Proposed time not acceptable Maintenance worker Ask for new suggestion Changes in time consumption or personnel

20. Adding details We can add details to a use case diagram by splitting uses cases into three types of objects. Entity objectControl objectBoundary objectEntity objectControl objectBoundary object

21. Adding details – example Input and output via boundary objects Validate input and output via control objects Save via entity objects

22. From UC to SD – 1

23. From UC to SD – 2

24. From UC to SD – 3

25. TDT 4242 Use case index Create a use case index Every use case has several attributes relating to the use case itself and to the project At the project level, these attributes include scope, complexity, status and priority.

26. Use case diagrams – pros and cons Simple use case diagrams are Easy to understand Easy to draw Complex use case diagrams – diagrams containing >> and > are difficult to understand for most stakeholders. Use case diagrams do not show the sequence of actions

27. TDT 4242 Textual use cases - 1 Identify the key components of your use case. The actual use case is a textual representation

28. TDT 4242 Textual use cases - 2 Examples of alternative flow are: While a customer places an order, their credit card failed While a customer places an order, their user session times out While a customer uses an ATM machine, the machine runs out of receipts and needs to warn the customer Alternative flow can also be handled by using > and >

29. Textual use cases – 3 Most textual use cases fit the following pattern:

30. Textual use case – example Use case name Review treatment plan Use case actor Doctor User actionSystem action 1.Request treatment plan for patient X 2.Check if patient X has this doctor 3.Check if there is a treatment plan for patient X 4.Return requested document 5.Doctor reviews treatment plan Exceptional paths 2.1 This is not this doctor ’ s patient 2.2 Give error message This ends the use case 3.1 No treatment plan exists for this patient This ends the use case

31. Textual use case > Use case nameRespond to System emergency call Use case actorOperator User actionSystem action System OK => Receive system signal System Down => Use radio Receive system message Act on message Send response End REC – 1 Use case nameRespond to radio emergency call Use case actorOperator User actionSystem action Receive radio message Act on message Send response End REC – 2

32. Textual use case > Use case nameController Use case actorNA Start timer Get data Action necessary? Yes => Set Actuator Timer expired ? No => BIT Check error status On => Error handling End Controller Use case nameBIT Use case actorNA Get test pattern A Write test pattern Read test pattern Compare patterns Difference => Set error status End BIT

33. Textual use cases – pros and cons Complex textual use cases Are easier to understand than most complex use case diagrams Are easy to transform into UML sequence diagrams Require more work to develop Show the sequence of actions

34. TDT 4242 Mis-Use cases Aims to Identify possible misuse scenarios of the system The concept was created in the 1990s by Guttorm Sindre, NTNU and Andreas L. Opdahl, UiB. The basic concept describes the steps of performing a malicious act against a system The process is the same as you would describe an act that the system is supposed to perform in a use case

35. Mis-Use cases example – 1

36. TDT 4242 Mis-Use cases example – 2 Mis-use cases are mostly used to capture security and safety requirements

37. Textual misuse case U C nameRespond to over-pressure User actionsSys ResponseThreatsMitigations Alarm operator o high pressure System fails to set alarm; Operator fails to notice alarm Have two independent alarms; Test alarms regularly; Use both audio and visual cues; Alarm also outside control room Operator gives command to empty tank Operator fails to react (e.g., ill, unconscious) Operator gives wrong command, e.g., filling tank Alarm backup operator Automatic sanity check, disallow filling at high pressure System opens Valve to sewer System fails to relay command to valve; Valve is stuck Operator reads pressure Operator misreads and stops emptying too soon Maintain alarm until situation is normal

38. Why misuse case – 1 A misuse case is used in three ways: Identify threats – e.g. “System fails to set alarm”. At this stage we do not care how this error can arise. Identify new requirements – e.g. “System shall have two independent alarms”. This is a high level requirement. How it is realized is not discussed now.

39. Why misuse case – 2 Identify new tests – e.g. Disable one of the alarms Create an alarm condition Check if the other alarm is set This is just the test strategy. How it is realized cannot be decided before we have decided how we shall implement the requirement.

40. Misuse case – pros and cons Misuse cases will help us to Focus on possible problems Helps us to identify defenses and mitigations Misuse cases can get large and complex – especially the misuse case diagrams.

41. TDT 4242 Use-Case Maps Definition: A visual representation of the requirements of a system, using a precisely defined set of symbols for responsibilities, system components, and sequences. Links behavior and structure in an explicit and visual way UCM paths: Architectural entities that describe causal relationships between responsibilities, which are bound to underlying organizational structures of abstract components. UCM paths are intended to bridge the gap between requirements (use cases) and detailed design

42. TDT 4242 Use-Case Maps – path Start Point End Point Path …… …… Responsibility Direction Arrow …… Timestamp Point Failure Point …… Shared Responsibility …… UCM Path Elements

43. TDT 4242 Use Case Maps example - path Mainly consist of path elements and components UCM Example: Commuting secure home X X commute X take elevator ready to leave home in cubicle home transport elevator Responsibility Point Basic Path (from circle to bar) Component (generic)

44. Use-Case Maps – AND / OR … … … … [C1] [C2] [C3] OR-Fork & Guarding Conditions … … … … OR-Join … … … … … … … … AND-JoinAND-Fork UCM Forks and Joins

45. UCM example – 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

46. Use-Case Maps – IN / OUT UCM Stubs and Plug-ins …… IN1OUT1 Static Stub & Segments ID Dynamic Stub IN1OUT1 …… S{IN1}E{OUT1} Plug-in Map

47. UCM example – IN / OUT UCM Example: Commuting ready to leave home in cubicle hometransportelevator commute take elevator secure home Dynamic Stub (selection policy) Static Stub stay home

48. Use-Case Maps – coordination Waiting Place Trigger Path (asynchronous) Waiting Path Continuation Path Timer Release (synchronous) Waiting Path Continuation Path Timeout Path UCM Waiting Places and Timers

49. Use Case Map 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 Slot (component) Pool (component)

50. TDT 4242 Use Case Maps – example 1 Example of Use Case map path traces through a system of objects to explain a causal sequence, leaving behind a visual signature. Contains pre-conditions or triggering causes causal chains of responsibilities (crosses, representing actions, tasks, or functions to be performed) Responsibilities are normally bound to component when the cross is inside the component causal chains of responsibilities (crosses, representing actions, tasks, or functions to be performed) Responsibilities are normally bound to component when the cross is inside the component bars representing post-conditions or resulting effects bars representing post-conditions or resulting effects A component is responsible to perform the action, task, or function represented by the responsibility. Start points may have preconditions attached, while responsibilities and end points can have post-conditions.

51. The influence of chosen elements The elements we choose to include in our model will decide the use case map but will not necessarily influence the actions needed. The following examples are meant to illustrate this. Two elements are always needed: User – requesting service Arrival sensor – indicates when the elevator arrives at the chosen floor.

52. User 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. Use Case Maps – example

53. Model 1 – scheduler User Scheduler Arrival Sensor Elevator in elevator above at requested floor below at floor up down approaching floor moving motor stop door open add to list remove from list select elevator [not requested][requested]

54. 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) Model 1 – Use Case Map

55. Model 2 – scheduler and status & plan User Scheduler Status & Plan Elev. Mgr Service Personnel Status & Plan Elev. Control Elevator Arrival Sensor at floor up down in elevator above below at requested floor motor stop door open switch on add to list remove from list select elevator [not requested][requested]

56. 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) Model 2 – Use Case Map

57. TDT 4242 Summary – 1 Use Cases benefits: Promote customer involvement Use cases describe a system from an external usage perspective They can be organized according to their relevance, frequency of use, and perceived value to the system’s users System features can be correlated with how they are used within specific use cases Impacts of adding and/or removing features on system usability can be analyzed

58. TDT 4242 Summary – 2 What Use Cases Cannot Do Use Cases are best used to describe system functionality from a task-oriented perspective They do not describe: o user interfaces o performance goals o application architecture o non-functional requirements

59. 59 Trondheim, Norway Acknowledgement Most of the slides on use case maps has been taken from a presentation written by D. Amyoty, University of Ottawa  Daniel Amyot, Gunter Mussbacher  damyot@site.uottawa.ca http://www.UseCaseMaps.org TDT 4242