1. Timed Use Case Maps Jameleddine Hassine Concordia University, Montreal, Canada URN Meeting, Ottawa, January 16-18, 2008

2. 2 Outline Early Stages of Development Process Time in Use Case Maps Modeling Time in Use Case Maps Syntax of Timed Use Case Maps Formal Semantics of Timed Use Case Maps  Clocked Transition System (CTS)  Timed Automata (TA) Conclusion

3. 3 Early Stages of Development Process Describe system functional requirements Scenario driven approaches Reason about the system at a high level of abstraction Facilitate moving towards design Timing and performance issues are often overlooked during the initial system design Typically regarded as separate issues and therefore described in separate models

4. 4 Use Case Maps Capture and integrate functional requirements Causal relationships between responsibilities but no information about the relative timing of different responsibilities Real-time Systems Requirements  Time, performance and functionalities are tightly related  Correctness depends on the satisfaction of timing constraints  Time expressed in milliseconds Business Process Requirements  Helps understand the scheduling/coordination between activities  Time expressed in terms of days/weeks Timing aspects must be integrated at early stages  Detecting errors through Simulation/Testing/Verification  Reduce the cost due to the late discovery of design flaws

5. 5 Time in Use Case Maps A timer construct (clock symbol), used to select between a normal path and a timeout path.  No quantity in timer. More like a Boolean variable. Some constraints on time distances between two locations on UCM paths  Timestamps and response time requirements attached to scenario paths Performance attributes can be attached to a start point (arrival distribution, percentiles...etc.)

6. 6 Standard time semantics Time-guarded behavior Global/Local time Urgency: Concept that gives priority to actions over time delay. Usually used as a property of transitions.  Eager transition: they are urgent as soon as they are enabled. Time cannot progress as long as they are enabled  Lazy transitions: They are never urgent. their execution can always wait  Delayable transitions: become urgent when they are enabled and progress of time would disable them Use Case Maps Do not have

7. 7 1. Instantaneous (atomic) vs. Durational actions  Instantaneous semantics make modeling more compact and easier to reason about  Durational semantics help: Describe various system requirements Describe truly concurrent systems  Only responsibilities take time to execute  Control constructs (AND-Fork, OR-Fork,..etc.) are instantaneous 2. Absolute vs. Relative Time  Responsibilities use relative time  Start points use absolute time Modeling Time in Use Case Maps

8. 8 3.Construct Enabling  Initiation and termination of enabling  R (T, T’). Responsibility R is enabled T time units after the completion of its predecessor. The enabling is offered for T’ time units  R(minDL,maxDL): Responsibility is enabled any time between minDL and maxDL after the completion of its predecessor. Upper bound maxDL is relative to the completion of the preceding construct. 4.Time Representation and Measurement  Interval-based: Measure the execution time of a responsibility  Point-based: Associated with time stamps Modeling Time in Use Case Maps

9. 9 5.Discrete vs. Dense Time Domain 6.Global vs. Local Clocks  One Master Clock: Used within constraints associated with start points Used to measure the time between responsibilities (e.g. end-to-end scenarios)  Local Clocks Measure time taken by responsibilities Measure delay associated with responsibilities 7.Urgency  Start points and Responsibilities may be delayed  Control constructs are urgent  Transitions (edges between UCM constructs) are urgent Modeling Time in Use Case Maps

10. 10 Timed Use Case Maps

11. 11 Signature of Timed UCM Constructs

12. 12 Timed UCM Formal Semantics Clocked Transition System (CTS)  Discrete Time Model Timed Automata (TA)  Dense Time Model The local clock y of the lamp is used to detect if the user was fast (y =5)

13. 13 CTS-Based Semantics of Timed UCM

14. 14 Configuration Transition Update system configuration defined by the three sets: H-taken, C-active and H-enabled. Triggered upon the timer expiration of either: One element of C-timers One element of T-trigger e3e2 e1 duration(a) = 2, delay(a) =0 duration(b) = 3, delay(b) =0 H-taken = {e1} C-active=[a] H-enabled = [e2] C-timers=[0] MClock = t H-taken = {e1,e2} C-active=[b] H-enabled = [e3] C-timers=[3] MClock = t+1 Configuration transition …

15. 15 Time Transition Only MClock (incremented by a clock tick) and C-timers (decremented by a clock tick) are subject to change. Triggered when one of the following conditions is met: One responsibility, part of C-active, is still executing One construct is delayed e3e2 e1 duration(a) = 2, delay(a) =0 duration(b) = 3, delay(b) =0 H-taken = {e1} C-active=[a] H-enabled = [e2] C-timers=[2] MClock = t H-taken = {e1} C-active=[a] H-enabled = [e2] C-timers=[1] MClock = t+1 Time transition …

16. 16 Concurrency Models and Time Evolution Interleaving Semantics At any given time t, only one construct may be executing. Sequences C-active and C-timers are reduced to one element True Concurrency Semantics At any given time t more than one responsibility may be executing. C-active, C-timers and T-trigger may have more than one element in presence of concurrent paths.

17. 17 TA-based Semantics of Timed UCM Timed UCM specification is modeled as a network of concurrent timed automata. Associate a TA process to each timed UCM Construct Each process interacts with other processes through synchronization channels and read-write operations to global variables. The Set H of edges is used as synchronization channels

18. 18 TA-based Semantics of Timed UCM Root start point Plug-in’ start point Start point triggered by the environment

19. 19 Responsibility Atomic Responsibility with Delay Urgent Responsibility with Duration Responsibility with variable update Untimed Responsibility TA-based Semantics of Timed UCM

20. 20 OR-Fork OR-Join AND-ForkAND-Join Synchronous Timer Stub Root map end pointPlugin end point TA-based Semantics of Timed UCM

21. 21 TA-based Specification Optimization The transfer of control between sequential constructs occurs in a deterministic way (i.e., in complete order), UCM specification may be decomposed into a collection of sequential paths. Synchronization is resolved between sequential responsibilities:

22. 22 Conclusion Extended Use Case Maps language with time Concise formal semantics for timed UCM models based on:  Clocked Transition Systems  Timed Automata CTS semantics are implemented using AsmL language  Simulation, step by step execution  Generation of timed traces TA semantics are implemented using UPPAAL model checker  Verification of Properties using Model checking Allows for formal Validation/Verification of timed UCM models

23. 23 Step Semantics for Interleaving Model: Configuration Transitions

24. 24 Step Semantics for Interleaving Model: Time Transition

25. 25 Step Semantics for True Concurrency Model: Configuration Transitions

26. 26 Step Semantics for True Concurrency Model: Time Transition