MSC - Message Sequence Chart
Creating a Message Sequence Chart
MSC attached to a Component
You can now attach MSC specifications to components in the component architecture.
To do so, right-click in the Model Navigator on the component you want to attach an MSC to:
Then right-click the created Component Specifications, and create an MSC by using the context menu:
The MSC is created and automatically populated with entities corresponding to the subcomponents of the component,
as well as two external entities to denote the inputs and outputs of the component:
Properties and Model Elements
The Properties section allows you to change the name of the MSC.
The Model Elements section allows to add to the MSC some elements by drag-and-drop, namely:
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.
Note that messages cannot go back in time, i.e., that starting point of a message cannot be below its ending point.
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 and self-explanatory Name and Comment fields,
one can find two fields:
Future modality is available only if the message has a preceding message
(p in the previous scheenshot).
The future modality itself can be either Next or Future:
A Next means that the message (m in the previous screenshot) is the next message to be sent after p, i.e.,
once p arrived, no other message than m is sent or received on the receiving entity
(i.e., Controller in the screenshots).
Note: it does not mean that the message should arrive on the next tick, but only that no other message should arrive on the same entity.
Note also: meanwhile, other messages might arrive on another entity.
On the opposite, a Future message can arrive any time and independently of other message arrival.
Most of the time, the Next semantics is intended.
Modality is available only if the originating entity is not external.
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:
The difference between both modalities is as follows:
- 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;
See below for a concrete example making use of modalities.
- A message with the Necessity modality must happen.
Consider for instance the following MSC:
This MSC means that m2 must be sent from E2 to E1 if
m2 has been sent from E1 to E2.
The system should not satisfy any other scenario.
This entails that not sending m2 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 m2 is not sent then we simply have another scenario (which might as well be described by another MSC).
For instance, another message m3 might be sent or even no message at all.
This entails that not sending m2 is not a bug of the system, and thus can happen in the implementation.
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).
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 three fields that are relevant for time information:
Name, Time possibility-constraint and Time possibility-constraint.
The name of the port allows to denote a time instant, in order to refer to it later on in timing constraints.
For instance, given a port connected to another message:
We can associate a so-called Time necessity-constraint
(New in AF3 2.6):
Once a constraint is added to a port, a little clock displays next to it in the diagram:
Here the constraint is t2-t1<50, which means: the time between t1 and t2 must be lower than 50ms.
Note that t1 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 t2 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).
If one wants to express on the other hand that the time between t1 and t2 can be lower than 50ms,
then we can use a time possibility-constraint:
Using a possibility constraint allows to restrict the considered scenarios to those satisfying the constraint.
Contrarily to a necessity constraint (e.g., in the previous screenshots) a possibility constraint does not enforce the constraint to be satisfied:
it might happen that the constraint, in which case, the rest of the MSC is irrelevent;
if, however the constraint is satisfied, then the trace should satisfy the scenario denoted by the rest of the MSC.
- 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).
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
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.
Mapping MSC Objects to Components
Improved in AF3 2.7
For further analysis (e.g., MSC Conformity analysis or Design Space Exploration),
one can make a connection between MSCs and the objects they represent in the component architecture.
For instance, one can map an MSC entity to an existing component using the Component Reference field of its properties section:
When the component is referenced, a little symbol appears next to the MSC entity:
Similarly, one can map MSC time instants (i.e., message ports) to component ports of the component to which the entity is mapped: