MSC - Creating Message Sequence Charts using AutoFOCUS3 (AF3)

MSC - Message Sequence Chart

Creating a Message Sequence Chart

To create a message sequence chart inside a use case, open the context menu of the use case and select MSC Specification.

In the same way, you can add more message sequence charts to your project. In the Properties section you can change the name of your message sequence chart.

In the Model Elements section you can find the different parts of a message sequence chart namely:

MSC Entity
Entry
Exit
Loop
Condition

Those can be added to the message sequence chart via drag-and-drop - as seen in the picture below - and can also be renamed in the Properties section.

Connecting MSC Entities

MSC Entities represent different instances which interact with each other. They can be connected by holding the Ctrl-Button on your keyboard while clicking on one MSC Entity and dragging with the mouse to another MSC Entity. The result of this action is a Message between the two entities that has an Exit and an Entry.

It is possible to modify the properties of a message by selecting it. The Properties section then contains the following:

In addition to the usual Name and Comment fields, which allow, as their names suggest, to change the name and comment associated with the message, one can find the Modality field. The modality of a message can be of two sorts: Possibility (which is the default, since it corresponds to the usual semantics of MSCs) or Necessity. When the Necessity modality is selected then the message appears bold:

As opposed to Possibility:

An MSC can only contain first a (possibly empty) sequence of Possibility messages followed by a (possibly empty) sequence of Necessity messages. Triggering the modality for a given message will always ensure that:

if a message is made necessary, then all the messages below will be made necessary as well;
if a message is made possible, then all the messages above will be made possible as well;
if a message is drawn below a necessary message then it will be made necessary as well;
if a message is drawn above a possible message then it will be made possible as well;

The difference between both modalities is as follows:

A message with the Necessity modality must happen. Consider for instance the following MSC:

This MSC means that m₂ must be sent from E₂ to E₁ if m₂ has been sent from E₁ to E₂. The system should not satisfy any other scenario.
This entails that not sending m₂ is a bug of the system, and thus should be avoided by the implementation.
On the other hand, a message with the Possibility modality can happen but does not have to. Such a message just describes a situation which is possible, but not necessary. Consider for instance the following MSC:

This MSC means that such a scenario is feasible, but it does not mean that it has to hold all the time (as opposite to the previous MSC with necessity modality). If m₂ is not sent then we simply have another scenario (which might as well be described by another MSC). For instance, another message m₃ might be sent or even no message at all.
This entails that not sending m₂ is not a bug of the system, and thus can happen in the implementation.

See below for a concrete example making use of modalities.

Modalities allow to describe more information in scenarios than usual MSCs. They are taken into account in AF3 when checking whether the MSC is feasible for a given implementation (see MSC Conformity).

Remark: The reason why an MSC can only contain first a sequence of possible messages followed by a sequence of necessary messages is that it is not clear what would mean a possible message p appearing after a necessity message n: should p always be possible once n has been received? Or should it be possible in only one of the paths? Thus, for clarity, it is simpler to just avoid this type of situations, hence our choice.

Adding Loops and Conditions

A Loop defines a certain repetition of Messages. Conditions for start and end of the loop can be set in the properties section.

A Condition is a predicate that the system must satisfy at a certain time moment. For Conditions a condition expression can be set in the properties section.

Both conditions and loops can be added to your message sequence chart by pulling them into the MSC Specification, resizing them and bringing them in the appropriate position. Loops and Conditions can be associated with more than one MSC Entity.

The following picture shows an example for a MSC Specification including every object mentioned in the above sections:

Adding Time Information

MSCs can contain time information, e.g., state that a message arrives within a certain amount of time, or that the time interval between two messages is smaller than a given value. In AF3, the time information is bound to the (outgoing or incoming) ports of messages since these are the places where time instants are defined. To add time information to an MSC, click on one of the ports of some message:

The property section then contains two fields that are relevant for time information: Instant name and Time constraint.

Let us give a name to that port, say t₁:

We can now see that the time instant appears in blue on the diagram (time information is generally denoted by blue, to make a difference with other types of information):

Let us now select the second port in order to add a constraint to it:

We first associate this port with an instant name, say t₂:

And we can now associate a constraint to the port, say: the time between t₁ and t₂ is lower than 50ms. This is expressed in AF3 simply using a mathematical inequality: t₂-t₁<50.

Once a constraint is added to a port, a little clock displays next to it in the diagram:

Note that t₁ denotes the instant when the message Message 1 is received, it is unrelated to the computations actually performed by the second entity (though it probably triggers some computation). Similarly t₂ denotes the instant when the message Message 2 is sent, and it is also unrelated to the computations perforemd by the first entity (though it probably results from the end of some computation).

FAQ:

What is the time unit?
Milli-seconds (giving the choice of unit will be proposed in the future).
Why is time information attached to ports and not to messages?
Attaching time instants and time constraints to ports instead of messages allows to express more time information. For instance, this allows to express the time between receiving a message and sending another message (i.e., the computation time), instead of just between the communication time of a message. This also allows to express non-local time information, e.g., between the sending of the very first message in an MSC and the receiving of the very last one.
Why do we have to use mathematical inequalities written as text? Wouldn't it be simpler to just draw a line between the two ports?
This is to prevent diagrams from containing too much information. However that might be considered in the future.
How is time information used by other features of AF3?
Time information allows to provide constraints when computing a scheduling for a given deployment, see Design Space Exploration (however the use of time information in scheduling is not documented yet).

External Entities

For entities, the Properties section contains the usual Name and Comment fields, and also a checkbox labelled "External":

When checked, the corresponding entity gets yellow:

When an entity is marked as external, it is considered as an actor which is external to the system to be designed with AF3. Consider for instance the following example:

In this example, we assume that the system to be designed in AF3 is the software of an ATM. The server deals with the data of all users and the terminal allows users to retrieve money from the ATM or manage their account. In the above scenario, a user tries to withdraw some money from the ATM: from this request, the terminal contacts the server which responds that the account of that user is empty. Therefore, the terminal must send the user an error message stating that he cannot retrieve any money.

Here, the system designer only has control over the behaviour of the terminal since it is the system to be developed; he has no control over the user or the server. Therefore, the user and the server are "external entities". This can be indicated by checking the corresponding property:

Not only this information provides some valuable information to the system designer about the understanding of the requirements (on this simple example it is obvious to see what is external or not, but this is not always the case), but it also allows making a better connection between the system requirements and its implementation: AF3 can then be used directly (thanks to the MSC Conformity analysis feature) to check that the system behaviour is correct according to the MSC since it knows what is part of the system and what is not part of it. Similarly marking the external actors, can allow an MSC involving time information to be used for scheduling.

Note that messages coming from an external entity do not have any modality. Indeed, it does not make sense to say whether an external entity may or must send a message: the external entity has its own behaviour, over which we have no control.

More generally, external entities allow to represent the input and output of a system. Therefore, they can also be used to denote scenarios over subsystems of the main system. In this case, the external entities might be external to a considered subsystem but still internal to the overall system. Concretely, this means for instance that the MSC Conformity analysis can check the behaviour of the subsystem independently of the whole system, which is very useful regarding modularity and reusability of models and MSCs.