Timed Use Case Maps

Jameleddine Hassine

Concordia University, Montreal, Canada

URN Meeting, Ottawa, January 16-18, 2008

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

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

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

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

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

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

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

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

Timed Use Case Maps

11

Signature of Timed UCM Constructs

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) or slow (y>=5)

13

CTS-Based Semantics of Timed UCM

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

e3e2e1

duration(a) = 2, delay(a) =0duration(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

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

e3e2e1

duration(a) = 2, delay(a) =0duration(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

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

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

TA-based Semantics of Timed UCM

Root start point

Plug-in’ start point

Start point triggered by the environment

||

19

Responsibility

Atomic Responsibility with Delay

Urgent Responsibility with Duration

Responsibility with

variable update

Untimed Responsibility

TA-based Semantics of Timed UCM

20

OR-Fork OR-Join

AND-Fork AND-Join

Synchronous Timer

Stub

Root map end point Plugin end point

TA-based Semantics of Timed UCM

21

Segment 1: [SP1;R1;R2]Segment 2: [SP2;R5]Segment 3: [R3;EP1]Segment 4: [R4]Segment 5: [R6; EP2]

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

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

Step Semantics for Interleaving Model:

Configuration Transitions

24

Step Semantics for Interleaving Model:

Time Transition

25

Step Semantics for True Concurrency Model:

Configuration Transitions

26

Step Semantics for True Concurrency Model:

Time Transition