Message Sequence Chart

1. Message Sequence Chart Lei Bu

2. MSCs • Message sequence chart (MSC) is a graphical and textual language for the description and specification of the interactions between system components. • The main area of application for MSCs is as overview specification of the communication behavior of real-time systems, in particular telecommunication switching systems.

3. MSCs represent typical execution scenarios, providing examples of either normal or exceptional executions of the proposed system. • The MSC standard as defined by ITU-T in Recommendation Z.120 (International Telecommunication Union - Telecommunication Standardization) • basic MSCs and High-Level MSCs.

4. Keyboard Send Key Click Click(digit) Click Sent Retrieve(digit) number Call(number) signal signal not busy

5. msc call_set_up network base_2 mobile_2 mobile_1 base_1 up_call_req up_call_req down_req down_req call_ack call_ack up_call_resp up_call_resp down_resp down_resp

7. Mem CPU mem CPU req req ack nack addr val MSC 2 MSC 1

8. Concurrency modeling • Depicts concurrently executing processes (the vertical lines). • Processes communicate via a explicit message passing (instead of shared variables). • Realistic MSCs will also contain data attributes as part of the exchanged msg

9. Message Attributes req ack Addr(a) v := lookup(a) val(v) CPU Mem

10. Internal Computations req Internal Action ack Addr(a) v := lookup(a) val(v) CPU Mem

11. Basic MSCs • A basic MSC describes exactly one scenario, which consists of a set of processes that run in parallel and exchange messages in a one to one, asynchronous fashion

12. MSC visual notation P1 P2 P3 M1 M2 M3 M4 M5 M6

13. MSC Textual form instance P3; in M2 from P2; in M3 from P2; out M4 to P2; out M6 to P1; endinstance; endmsc; msc MSC; inst P1: process Root, P2: process Root, P3: process Root; instance P1; out M1 to P2; in M5 from P2; in M6 from P3; endinstance; instance P2; in M1 from P1; out M2 to P3; out M3 to P3; in M4 from P3; out M5 to P1; endinstance; P1 P2 P3 M1 M2 M3 M4 M5 M6

14. Visual order semantics M1 s r M2 s r P1 P2 P3 M1 M2 M3 s M3 r M4 s M4 M5 r M6 s s M5 M6 r r

15. A bMSC is a tuple where • P is a finite set of processes; • E is a finite set of events corresponding to sending a message and receiving a message. • M is a finite set of messages. Each Message in M is of the form where e, e’corresponds to sending and receiving the message respectively, and g is the message name which is a character string. • is a labeling function which maps each event eto a process L(e) • V is a finite set whose elements are a pair (e,e’) where e, e’and e precedes e’, which is corresponding to a visual order;

16. The semantics of a bMSC essentially consists of sequences (of traces) of messages that are sent and received among the concurrent processes in the bMSC. • The order of communication events (i.e.messagesending or receiving) in a trace is deduced from the visual partial order determined by the flow of control within each process in the bMSC along with a causal dependency between the events of sending and receiving a message.

17. We use event sequences to represent the traces of bMSCs which are corresponding to the untimed behavior of bMSCs. Any event sequence is of the form …, which represents thattakes place after for any i().

18. Let be a bMSC. An event sequence …is a trace of D if and only if the following conditions hold: • All events in E occur in the sequence, and each event occurs only once, i.e. {…}=E and for any i,j(); and • …satisfy the visual order defined by V, i.e. for any , if ().

19. Visual semantics • Sends before corresponding receives. • Events on the same process line execute in order of appearance, from top to bottom.

20. Visual order (wysiwyg) • If some event (send, receive) is higher on the line than another, it comes first. • Sends precede matching receives. P1 P2 P3 M1 M2 M3 M4 M5 M6

21. Visual order (wysiwyg) M1 s r M2 s P1 P2 P3 r M1 M2 M3 M3 s M4 r M5 s M4 M6 r s s M5 M6 r r

22. Causal Order and Races • Causality: Sends before matching receive. • Controlability: Receive or sends before sends of same process. • FIFO order: Two receives on the same process sent from the same process. P1 P2 P3 M1 M2 M3 M4 M5 M6 Races: check if every pair of events ordered by the visual order appears in the transitive closure of the causal order.

23. Races P1 P2 P3 P1 P2 P3 M1 M1 M2 M2 M3 M3 M4 M4 M5 M6 M6 M5

24. P1 P2 P3 M1 M2 M3 M4 M5 M6 Finding races: P1 P2 P3 M1 M2 M3 M4 M5 Rules: order between - receive and a later send. - two sends from same process. - send and corresponding receive. -fifo order. M6

25. Causal Order M1 s r M2 s r P1 P2 P3 M1 M2 M3 s M3 M4 r M5 s M4 M6 r s s M5 M6 r r

26. Calculating the transitive closure • Structure (E, R). • E – Events, R  E  E. • R* The transitive closure. Defined asfollows:a R*b if there is a sequencex1 x2 … xn where a=x1, b=xn,and xi R xi+1 for 1i<n.

27. Combining MSCs • Models a single scenario and states its possible execution in the system implementation. • How could we use MSCs to model the behavior of a concurrent system ? • One attempt is to describe the system behavior as a graph of MSCs. • Each node of this graph is a MSC. • We call such graphs as Message Sequence Graphs (MSG).

28. P1 P2 P3 P1 P2 P3 approve connect P1 P2 P3 P1 P2 P3 fail req_service report

29. A B Execution: ACACD approve connect connect fail report connect fail fail Req_service report report Req_service C D

30. MSG - Visually req M1 M3 M2 ack nack addr val

31. Choice and Concatenation • Choice of scenarios at a certain point in system execution modeled by several outgoing branches • M1  M2 and M1  M3 • Concatenation of MSCs (by following the edges in the MSG) produces infinite execution traces. Client Server

32. More on concatenation • Synchronous concatenation • All processes synchronize at the end of each MSC (a node of the MSG) • For any edge M1  M2 • All events in M1 happen before all events in M2 • Costly to implement since the natural control flow in a process is disrupted by the termination of a MSC (requiring handshake with other processes).

33. Synchronous concatenation r1 s1 s1 < r1 < s2 < r2 r2 s2

34. An alternative concentation • Asynchronous concatenation • If M1  M2 is an edge in the MSG, then concatenate M1 and M2 process by process • If a process finishes its role in M1 ahead of others, it can start executing M2 • Amenable to efficient distributed implementation.

35. Asynchronous concatenation r1 s1 s1 < r1 s2 < r2 s1 < s2 Is r1 < s2 ?? r2 s2

36. Hierarchical MSC (HMSC) • Improves MSGs by incorporating hierarchy. • A graph, each node of which is: • a Message Sequence Chart, or • a HMSC • Clearly a MSG can appear as a node of HMSC. • Different nodes in the graph can be labeled by the same HMSC • The HMSC is like a subprogram which is invoked in various contexts.

37. HMSC example Th1 CPU Th2 CPU-Mem MSG CPU-Mem MSG can be invoked in another context involving thread Th2. Th1 CPU data

38. MSG - Recap req M1 M3 M2 ack nack addr val

39. msc call_blocking initiate_call call_refused call_set_up call_proceeding terminate_call High-Level MSCs • References can be to • basic MSCs or • high-level MSCs • start point • end point • reference • branching • looping • parallel (not shown) • guards (not shown) Single telecom. feature may have >100 basic MSCs structured through 3 levels of high-level MSCs

40. Extended/Related Models • UML Sequence Diagram • Live Sequence Chart • Timed MSC

41. msc MyLife infra mobile_1 mobile_2 call_req t(5) alt when idle call_ack t call_accept otherwise t req_refused In-Line Expressions Structuring event behaviour within an MSC • In-line expressions: • alternative • parallel • optional • loop • exceptional • Operands: • non-deterministic choice • may be guarded • events interleaved with those outside expression

42. msc call_expiration(time_out: time) network base manager initiate @10:00 ready x := f(_, 5) set_up(time_out + 3) [5, 10] expired (“z1”, _, x) terminate Time Constraints/Data • Real-Time Constraints • Message Contents • Data Dependent Behaviour • Time Constraints: • absolute (tracing) • relative (specification) • single point, intervals • constrain regions • Data: • static variables • - parameterises MSC • - global to MSC • - also instances, etc. • dynamic variables • - local to instance • - assigned in actions • - declared MSC Document • underspecification • - “don’t care” values

43. Instance Decomposition Splitting an Instance Into Constituent Processes msc call network decomposed as network_call base manager initiate ready set_up • Hierarchical view of processes • Instance structure defined in enclosing MSC Document • Internal messages hidden in upper view mscnetwork_call manager_handler base_handler ready initiate initiate_set_up set_up

44. LSC Scenario-based Stories about the system MSCs: (Message Sequence Charts) inter-object behavior (one story for all relevant objects)

45. But,… we need richer requirements may/must; can/always; fragmental and overlapping scenarios; anti-scenarios; etc.

46. Live sequence charts(LSC’s) “LSC’s: Breathing Life into Message Sequence Charts” (Damm & Harel, ‘98 ) A natural extension of classical MSCs, with modalities (universal/existential, hot/cold, etc.) and structure (subcharts, conditionals, loops, etc.)

47. Basic form of an LSC prechart (if) main chart (then)

48. Subcharts • Loops • Coldconditions enable control structures • Hotconditions enable anti-scenarios:

49. MSG - Recap req M1 M3 M2 ack nack addr val

50. M1 req Mem.busy Mem.busy Mem CPU M3 M2 ack nack addr val CPU Mem CPU Mem