2.6.3. Structuring SDs

1. 2.6.3. Structuring SDs Normally a use case scenario is too long and complex to fit on a single (A4?) SD. We need to hierarchically structure SDs and decompose them into sub-SDs called by SD references.

2. A reference is a pointer to another SD. References may not be circular or recursive.

3. Let us give a typical example. A simple data exchange between two systems can be divided into 3 phases: • set-up communication/initialize • exchange data • close-down communication We can specify the use case “successful data exchange” as follows.

4. SD Successful_ Data_Exchange A B ref Initialize ref Exchange ref Shutdown

5. ref <name> The symbol denotes a sub-SD called name. Thus every SD has a symbolic name also. The keyword ref stand for reference. Then for the above example, we might have:

6. SD Shutdown SD Initialize A B A B “ready_to_send” “finished” “shutdown” “ready_to_receive” Notice these are “handshakes” between A and B. We will specify the SD “Exchange” later.

7. Note that a sub-SD does not synchronize timelines. i.e. either of A or B is free to leave sub-SD Exchange without the other leaving simultaneously. Here’s another example to clarify the point.

8. SD Sub-1 SD Unsynchronised_Ref A B A B ref “hello” Sub-1 “goodbye” “what?”

9. Possible executions are either: • hello • what • goodbye (A leaves Sub-1 late) or • hello • goodbye (A leaves Sub-1 early) • what?

10. SD normal_log_in User System Precondition: Power is on, operating system is active, log-in menu is visible. “username” “password?” “my_password” Postcondition: Power is on, operating system is active, user is logged in under own profile, user’s desktop is visible, log-in menu is not visible.

11. We introduce SD interaction operators • alt : alternative choice of sections • par : parallel execution of several sections • loop : iterative execution of a section • opt : optional section that could be omitted • (exc : exception section to handle errors.)

12. Interaction Operator alt An operator (possibly with a Boolean guard) used to define two or more alternatives, at most one of which will be taken. Below, users u1 and u2 compete for Printer p. Either u2 wins (top) or u1 wins (bottom)

13. SD Alternatives u1 : User u2 : User p : Printer “print_1” “print_2” alt “accept_2” “accept_1”

14. The only possible executions or traces for SD Alternatives are either : • print_1 • print_2 • accept_2 or • print_1 • print_2 • accept_1

15. Interaction Operator par An operator used to define two or more sections, all of which will be executed simultaneously Compare par with alt! Below, u1 and u2 both request a print job in parallel and both are accepted.

16. SD Parallel u1:User u2:User p:Printer par “print_1” “accept_1” “print_2” “accept_2”

17. This time there are 6 possible executions . These represent all possible interleavings of the two subsections of par. 1. print_1 1. print_1 1. print_2 1.print_1 2. print_2 2. accept_1 2. accept_2 2.print_2 3. accept_1 3. print_2 3. print_1 3.accept_2 4. accept_2 4. accept_2 4. accept_1 4.accept_1 1. print_2 1. print_2 2. print_1 2. print_1 3. accept_1 3. accept_2 4. accept_2 4. accept_1

18. Interaction Operator loop An operator (possibly with a Boolean guard, no guard = [true]) used to define a section that may be iterated finitely or infinitely many times. Guard evaluated on each iteration. As well as Boolean guards we can bound the number of iterations.

19. Keywords : • loop <m, n>, loop at least m times and at most n times, for fixed integer constants m, n. • loop <m, inf>, loop finitely often, but at least m times. ( *not* infinitely often). • loop <inf, inf> loop at least infinitely many times. (4) loop <n> = loop <n, n> . (5) loop = loop <1, inf> . (6) [ while <Boolean expression> ]

20. Important note: The parameters m, n are fixed constants, they are not variables which can be changed. In the following example, the user polls a printer until the printer becomes ready. When it becomes ready the printer prints the file.

21. u:User p:Printer Loop <0, inf> alt “ready?” “busy” “ready?” “ready?” “yes” “print(file)” “printing”

22. Interaction Operator Opt An expression, possibly with a Boolean guard, [ <Boolean expression> ] (no guard is the same as [true]) used to define an optional section which may or may not be executed (non -deterministic). In the next example, A sends to B and may or may not get confirmation in time t< maxdelay before the next send.

23. a:A b:B “send” opt “received” “ok” [ t < maxdelay ] “send”

24. Other Interaction Operators • neg – traces which are defined to be impossible • region – a critical region, i.e. traces cannot be interleaved by other events. • assert – all traces that involve the assertion being false are impossible (??)

25. 3. Introduction to Live Sequence Charts LSC The Play-Engine is an MS Windows-based tool for Live Sequence Charts: • managing a requirements project of LSCs, • graphically editing correct LSCs, (play-in), • simulating a set of LSCs (play-out), • analysing LSCs (model checking).

26. Menu bar Tool bar Project Explorer Tree Work area An LSC Application GUI

27. Traditional system development Java, C++, etc Code Basic structure System model structure Use cases behaviour Requirements LSCs (or MSCs or sequence diagrams) object model diagrams + statecharts

28. Play-in/out in the Development Lifecycle Java, C++, etc Code Basic structure Use cases System model structure played behaviour behaviour play-in play-out Requirements LSCs (or MSCs or sequence diagrams) object model diagrams + statecharts