Basic Notations of a Sequence Diagram

A sequence diagram represents the interaction between the objects or compo- nents in a system for a particular purpose. It can also be used to realise a use case scenario, where a scenario describes the interactions within a system. UML2 sequence diagrams have become a widely used modelling language with many supporting tools for making SD specifications.

Generally, a SD shows a set of partial ordered sequences of messages that communicate between the instances participating in the interaction, and how the interaction develops over time along with the corresponding occurrences on the lifelines. The possible flows of control throughout the interactions in a SD are described in two dimensions: the horizontal dimension represents the different instances participating in the interaction, and the vertical dimension represents time with time progressing from top to bottom. We describe its key notations in detail first.

Figure 3.1: A Graphical Representation of a Sequence Diagram.

diagram that represents the boundary of the specified system. The name of the diagram following the keyword sdis placed inside a pentagon shaped com- partment on the upper left corner of the frame. Additionally, the diagram name may followed by the input and output parameters associated with the diagram. In general, a SD shows the instances participating in an interaction. An instance can correspond to a particular object or a role played in an in- teraction. A role may be a part of a collaboration and/or an internal part of a structured class, sub-system or component. An instance has a vertical line called lifeline that represents the existence of the instance at a particular time. A lifeline shows the participation of an instance in an interaction. An occurrence is something that happens, which has some consequence within the system. The order of occurrences along a lifeline is significant for denoting the order in which these occurrences will occur. However, the absolute distance between the occurrences on the lifeline is irrelevant semantically. For instance, Figure 3.1 shows an example of a SD using basic UML 2 constructs. The SD named A initially contains two object instances a:A and c:C.

The most visible aspects of an interaction in a SD are the sequence of messages that are exchanged between the sending and receiving instances, along with their corresponding occurrence on the lifelines. A message is a named element that defines a communication between lifelines (instances) of an interaction or between a lifeline and the environment of the diagram. A message can cause, for example, an operation to be invoked, a signal to be raised, and instance to be created or destroyed. When a message represents an operation call, a message may contain the arguments of the operation, whereas in the case of a signal, the arguments of the message are the attributes of the signal. A message specifies the type of communication (synchronous or asynchronous), and the sender and receiver occurrences associated with it.

A message is represented using an arrow from the sender message end to the receiver message end. Moreover, a message with the same source and target lifeline is called as aself-message. In a self-message the sending message event is ordered before the receiving message event. Messages are mainly divided into two types: asynchronous and synchronous messages. In asynchronous messages, the sender sends the message and continues the execution without waiting for a return from the receiver, whereas in synchronous messages, the sender waits for the receiver to return from the execution of the message. Here, the form of the line or arrowhead reflects properties of the message [Arlow and Neustadt, 2005,OMG, 2011a]. For example, in Figure 3.1 the first message with an open arrowhead represents an asynchronous call, where the sender sends the message and continues executing without waiting for a return from the receiver. A message with a filled arrowhead represent a synchronous call, where the sender waits for the receiver to return from the executing the message. Moreover, an open arrow with a dashed line represents a return message, (m3 in the example) that the receiver of an earlier message returns focus of control

to the sender of that message. The message ordering, data convey via messages and associated lifelines are important in a sequence diagram, however, a SD does not focus on the manipulation of data.

Generally, when the source or target of a message is a lifeline, then it corresponds to an event, whereas when it is a frame, then it corresponds to a gate. The latter happens when the sender or receiver of the message is (locally or globally) unspecified. Gates are described in more detail later in this chapter.

During an interaction it is possible to create and destroy instances. Fig- ure 3.1 shows an object creation and destruction messages drawn as a dashed line with an open arrowhead and the stereotype<<create>>and<<destroy>>, respectively. The creation results in creating an instance of the classifier spec- ified by the receiver. When an object is destroyed its lifeline stops and no further occurrences are possible. Destruction is represented by a cross in the form of a X at the bottom of the lifeline. If it consists of a compound object it may lead to the subsequent destruction of other objects owned by composition. Consider the example of a sequence diagramSDAshown in Figure 3.1. The

interactions within the diagram start by instance areceiving an asynchronous messagem0from a gate (unknown sender). Asynchronous messages are shown using an open arrowhead and the sender continues executing without waiting for a return message. Then, instance a sends an object creation message to create instance b, where the classifier is specified by the receiver. Next instance b sends a synchronous message m1 to instance c. Next instance c

executes a self-message m2. After that instance csends a return message m3

to instance b, focusing the control to the sender of an earlier message m1

and it is denoted by a dashed line. This is followed by message m4sent from instance b to instance a. Finally, instance a sends an object destroy message

to destroy instance b and the lifeline of instance b terminates with an X. UML 2 SDs contain other types of messages such as lost and found messages [Arlow and Neustadt, 2005, OMG, 2011a]. A lost message is a message that will never reach its destination, and is represented using a small black circle at the arrow-end. This type of messages may be used to indicate error conditions in which messages are lost. On the other hand, for a found message, the sender is unknown or outside the scope of the interaction and is denoted by a small black circle at the starting end of the message. These messages can be used to show message from an unknown sender.

The notion of gate mentioned earlier can simulate the found messages or lost messages, but are more general. A gate is used to define an unspecified source or recipient of an interaction, where the corresponding lifeline of the instance is not a part of the diagram. It is considered as a syntactic interface of the SD with its environment. A gate has no symbol of its own, and simply is shown as a message pointing to/from the edge of the frame of the diagram. A SD may also include local variables that support data flow within the interactions. These variable definitions may appear near the top of the dia- gram frame. Further, a SD can be structured further using complex constructs named interaction fragments and interaction uses. The remaining of this sec- tion describes these notions in detail.