Lei Bu Message Sequence Chart

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.

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.

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

mobile_2 base_1mobile_1 networkbase_2 msc call_set_up up_call_req down_req up_call_resp call_ack down_resp

req acknack addr val CPUmem CPU Mem MSC 1 MSC 2

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

Message Attributes req ack Addr(a) v := lookup(a) val(v) CPUMem

Internal Computations req ack Addr(a) v := lookup(a) val(v) CPUMem Internal Action

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

MSC visual notation P1P3P2 M1 M2 M3 M4 M5 M6

MSC Textual form 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; P1P3P2 M1 M2 M3 M4 M5 M6 instance P3; in M2 from P2; in M3 from P2; out M4 to P2; out M6 to P1; endinstance; endmsc;

Visual order semantics P1P3P2 M1 M2 M3 M4 M5 M6 ss s s s r r r r r r s M1 M2 M3 M4 M5 M6

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.message sending 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.

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

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

Visual order (wysiwyg) P1P3P2 M1 M2 M3 M4 M5 M6 ss s s s r r r r r r s M1 M2 M3 M4 M5 M6

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. P1P3P2 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.

Races P1P3P2 M1 M2 M3 M4 M5 M6 P1P3P2 M1 M2 M3 M4 M5 M6

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

Causal Order P1P3P2 M1 M2 M3 M4 M5 M6 ss s s s r r r r r r s M1 M2 M3 M4 M5 M6

Calculating the transitive closure Structure (E, R). E – Events, R  E  E. R * The transitive closure. Defined as follows: a R * b if there is a sequence x 1 x 2 … x n where a=x 1, b=x n, and x i R x i+1 for 1  i<n.

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).

P1P3P2P1P3P2 P1P3P2P1P3P2 connect approve fail req_service report

connect approve fail report Req_service A CD B Execution: ACACD connect fail Req_service report

MSG - Visually req ack addr val nack M1 M2 M3

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

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).

Synchronous concatenation s1 r1 s2 r2 s1 < r1 < s2 < r2

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.

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

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.

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

MSG - Recap req ack addr val nack M1 M2 M3

High-Level MSCs msc call_blocking initiate_call call_refused call_set_up terminate_call call_proceeding 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

Extended/Related Models UML Sequence Diagram Live Sequence Chart Timed MSC

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

Time Constraints: absolute (tracing) relative (specification) single point, intervals constrain regions Time Constraints/Data basemanager network set_up(time_out + 3) terminate expired (“z1”, _, x) initiate ready msc call_expiration(time_out: time) [5, x := f(_, 5) Real-Time Constraints Message Contents Data Dependent Behaviour 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

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

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

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

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.)

elementmandatoryprovisional chart universal all system runs satisfy chart existential at least one run satisfies chart A E message hot if message is sent it must be received cold receipt of message is not guaranteed condition hot condition must be met otherwise abort cold if condition not met exit current (sub) chart

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

Subcharts Loops Cold conditions enable control structures Hot conditions enable anti-scenarios:

MSG - Recap req ack addr val nack M1 M2 M3

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

A Universal chart CPU Mem nack 1. Mem.busy is the activation condition (AC) 2. If the AC holds, then this chart must be executed. 3. But the AC need not be true in every execution. Mem.busy

Pre-charts The trigger of a universal chart need simply be an activation condition. Can be an activation message: when it is received the chart is required to be activated. Can even be another full blown chart (a pre-chart). This chart can contain msg send/recv, conditions. Once the pre-chart is executed, the universal chart is required to follow.

Example of Pre-chart Mem.busy = true req CP U Mem nack Pre-chart Univ. chart Concatenation CPUMem

Timed extension Scenario-based specifications (SBSs) offer an intuitive and visual way of describing design requirements.  Message sequence charts(MSCs)  UML interaction models For real-time systems, timing constraints are introduced into SBSs to describe timed behaviors.

SBSs SBSs consist of UML sequence diagrams (SDs) and UML2.0 interaction overview diagrams (IODs). We use the SD to describe exactly one scenario without alternatives and loops, and the IOD which combines references to SDs to describe sequential, iterating and non-deterministic executions of SDs.

Case Study ATM

Motivation Describing timing constraints related to the separation in time between two events.  timers, interval delays, timing marks To describe timing constraints which are about the relation among multiple separations in time between events. Checking SBSs for timing consistency To check more properties  properties about the accumulated delays on the traces of systems

Timing Constraints The timing constraints enforced on SDs describe the relations among multiple separations in time between events. a ≤ c 0 (e 0 -e 0 ’)+c 1 (e 1 -e 1 ’)+…+c n (e n -e n ’) ≤ b separation

Timing Constraints The timing constraints enforced on SDs describe the relations among multiple separations in time between events. a ≤ c 0 (e 0 -e 0 ’)+c 1 (e 1 -e 1 ’)+…+c n (e n -e n ’) ≤ b The timing constraints enforced on IODs describe the timed relations between two events from different sequence diagrams. a ≤ e-e’ ≤ b

Reachability analysis To check if a given scenario of an SBS is reachable along a behavior of the SBS with regard to all the timing constraints.

Constraint conformance analysis To check if the given several scenarios, which occur consecutively in the behavior of an SBS, satisfy a given timing constraint. a ≤ c 0 (e 0 -e 0 ’)+c 1 (e 1 - e 1 ’)+…+c n (e n -e n ’) ≤ b

Bounded delay analysis To check if the separation in time between two given events, which may occur in different sequence diagrams, is not smaller or greater than a given real number in any behavior of an SBS.

Consistency Checking

Existency Checking

MSCs in the Lifecycle SDL Design Specification and Description Language Box Testing System/Integration Testing Code Generation UKUSARMTR air_in taxi_in taxi_out air_out ITU, ETSI Standards UKUSARMTR air_in taxi_in taxi_out air_out UKUSARMTR air_in taxi_in taxi_out air_out UKUSARMTR air_in taxi_in taxi_out air_out UKUSARMTR air_in taxi_in taxi_out air_out Code TTCN Test Generation Code Generation Box Requirements System Requirements MSCs Used Formally Throughout Lifecycle Automation Requires Formal Languages Test Generation

Verification & Validation: feature interactions race conditions tracing Tracing: model validation application code validation test validation Design Verification: model checking SDL upholds MSCs Test Generation: conformance testing test purposes (one-2- many) test specification (one-2-one) MSC Uses UKUSARMTR air_in taxi_in taxi_out air_out UKUSARMTR air_in taxi_in taxi_out air_out SDL Tracing UKUSARMTR air_in taxi_in taxi_out air_out UKUSARMTR air_in taxi_in taxi_out air_out Requirements V&V TTCN Generation SDL Verification Formality Enables Useful Tool Support

Summary MSC is a rich language suitable for requirements specification many uses across lifecycle ‘engineer friendly’ language used in telecom standards Good tool support getting more sophisticated industrial use integrated with SDL, TTCN tools Standardisation Continues interesting problems to work on good forum for insight, new ideas learn latest methods/technology