Thomas A. Alspaugh
Message Sequence Charts and Sequence Diagrams


MSC event ordering

Figure 1. An MSC  [from ITU1999-msc p.21]

A (basic) message sequence chart or MSC is a diagram that shows communications between system components (also called instances). Each vertical line in an MSC represents a system components, and horizontal arrows represent messages from one component to another.

It is a design-level notation, intended for and best suited for system design involving two or more subsystems; it is not particularly appropriate for system requirements.

There is also the high-level message sequence chart or hMSC, which gives the order in which some MSCs can occur.

Interpreting an MSC

An MSC shows the sequence in which some messages are sent among some components (sometimes called instances). The vertical line for each component/instance is its axis. The messages and components have to be defined elsewhere. Each message m has two instants in time: when it is sent by one component (out(m)) and when it is received by another (in(m)). The sequence is as follows:

  1. Each message is sent before it is received (out(m) precedes in(m)).
  2. For each component, messages higher on the vertical line precede messages lower down.
MSC event ordering

Figure 2. Partial order of outs and ins in Figure 1

But there is no other guarantee about the sequence of messages on different vertical lines. For two messages that don't share a component, it doesn't matter which is higher or lower in the diagram. This can be confusing and misleading for a novice.

Also an MSC may describe an implementation that is inconsistent, in that the components may not have enough information to enforce the message ordering the MSC defines. This may be viewed as appropriate for the kinds of systems that MSCs are used to model, but it can be confusing and misleading as well.

For example, in Figure 1

Figure 2 gives the partial order of message ins and outs in Figure 1.

Figure 1 also shows:

Other MSC possibilities


Figure 3. ATM  [from Letier+Kramer+2005-mcsb p.387]

Some example MSCs

Figure 3 shows a user going through the beginning of an ATM withdrawal transaction. The diagram assumes that we have definitions of the components and messages, and simply gives the sequence of the messages. "User" is the user, "ATM" is the ATM, and "Bank" is the bank's database system with which the ATM communicates. The user inserts an ATM card, the ATM requests a PIN, the user enters a PIN; the ATM verifies the PIN with the bank's database. The "processing" message stands for the ATM showing a message saying it is processing the PIN. After the bank says the PIN is valid, the ATM presents the transaction choices ("option") and the user selects withdrawal. The ATM then asks for the amount to withdraw.

Although this MSC states that the ATM shows the "processing" message before the bank responds with "valid", in fact the implementation that the MSC describes cannot ensure this because the ATM doesn't control how quickly the bank responds. Granted, this is a fairly insignificant problem but is an example of how an MSC can state a property that the implementation it describes cannot guarantee.


Figure 4. hMSC relating four basic MSCs


A high-level message sequence chart or hMSC gives the sequence in which some basic MSCs can occur. An example is shown in Figure 4.

UML sequence diagrams under construction


Figure 5. Sequence diagram

A UML sequence diagram or SD is similar to an MSC but written with a different notation. Presumably the same semantic issues arise, but possibly not since UML semantics are not well-defined. An example is shown in Figure 5.

The timelines are dotted rather than solid, and the name of the component is inside a box at the head of each timeline. The narrow rectangles apparently show when a component is active (unsure precisely what "active" means). An X on a timeline indicates that the component ceases to exist in some sense (unsure precisely how this is meant also). In the example, the Bank timeline has an X simply as an example (presumably the Bank does continue to exist).


Message Sequence Chart (MSC). ITU-T Recommendation Z.120. International Telecommunications Union. Nov. 1999.
Message Sequence Chart (MSC). ITU-T Recommendation Z.120. International Telecommunications Union. Apr. 2004.
Emmanuel Letier, Jeff Kramer, Jeff Magee, and Sebastian Uchitel. Monitoring and control in scenario-based requirements analysis. In 27th International Conference on Software Engineering (ICSE ’05), pages 382–391, 15–21 May 2005.

flip bgunflip