A Sequence Diagram is primarily concerned with the chronological progression of messages. The messaging sequence corresponds to its horizontal position in the diagram. When an object is created, and when and to what object information is sent, are all determined here.

The participating objects are represented by a rectangle and a dashed vertical line. Both together are called a Lifeline. Messages are shown using arrows between the Lifelines. Time progresses from top to bottom. The chronological progress of messages is thereby highlighted.

The sequence diagram in the following illustration shows an interaction among three objects. It is important that the entire diagram represents an interaction, and that an interaction is not only a
single message exchange.

In the heading of the Lifeline is the (optional) element name with the associated class in the usual declaration notation: name : type.
ExecutionOccurence
When messages are exchanged between Lifelines, a Behavior must also be implemented in the associated elements. This is shown by the elongated rectangle on the Lifeline. These rectangles represent the so-called ExecutionOccurence. Start and End of ExecutionOccurence are defined via the so-called Event Occurrence. Put more simply, the sending and receiving of messages determines the start and end of the ExecutionOccurence.
Message Types
The transfer of a message is noted using arrows. Labeling of messages is carried out using the names of the corresponding operations. UML recognizes various types of messages which are demonstrated using various kinds of arrow notation. In the following illustration, the various message types and corresponding notation forms are shown.

•    Synchronous Messages are represented by filled arrowheads. Synchronous means that the caller waits until the called behavior has ended. The Reply Message to a synchronous call is represented by a dashed line and open arrow point.
•    Asynchronous Messages have an open arrow point. Asynchronous means that the caller does not wait, but rather proceeds immediately after the call. There is accordingly no answer arrow to asynchronous calls.
•    Lost Messages have an open arrow point in the direction of a filled circle. The circle is not linked to a Lifeline. When a message is lost the sender is recognized, but not the receiver.
•    Found Messages have an open arrow point. The line emanates from a filled circle. The circle is not linked to a Lifeline. When a message is found the receiver is recognized, but not the sender.
•    A message which creates a new Element is represented by a line and open arrow point. The Lifeline which belongs to the Element starts first on this place in the diagram; e.g., the arrow points to the Lifeline header.

Repeated message sending is modeled by adding the * symbol, in which case the message has the * symbol placed in front.

The message is noted on the message arrow with the following syntax:
[attribute =] name [(arguments)] [: return value]
 
Whereby
•    “attribute” can be a local variable of the interaction, or an Element of a Lifeline. The attribute allocation is only used in synchronous messages with return value.
•    “name” is the name of the message to be called, or the name of the signal to be sent. The sending of a signal is always as asynchronous character.
•    “arguments” is a comma-separated list of parameter values transferred to the message.

If an object is created via the setting of a message (e.g. by calling the method “new”), then the Lifeline of this object begins at this position. The destruction of an object is represented by a cross on the Lifeline.
Symbols
The following table contains the sequence diagram symbols.

Symbol/Name    Use

System Border
     The System Border isolates the concerned part of the program from the rest of the program. It usually serves as the start point of the triggering method call. Program flow is not always triggered by an object outside of the concerned area, so that in this case no system limit must be set.
Object
     An object is shown by a rectangle containing the name. Underlining of the name may be omitted so that no confusion with the class name can occur. Classes are not displayed in this diagram. Objects are shown along the upper sheet edge.
Lifeline
     Every object is on a vertical line - the Lifeline. An object’s lifeline grows in the direction of the lower sheet edge. For objects which already exist at the start of the program section, the object symbols are drawn on the upper sheet edge. For objects which are re-created within the program section, the symbol is drawn at the level of the method call in the course of which the object was created.
Object Activity
     If an object is involved in a method call, it is active. The Lifeline thickens. If an object calls its own method, the Lifeline thickens again. These activities are not always drawn.
Method Calls
     When an object calls a method of another object, this is symbolized by a continuous arrow which points to the object from which the method was called. The method name is placed on this symbol. This name can be added to the parameters list in parentheses.
Return of a Method
     In principle, only the method calls are shown in the sequence diagram. Should you nevertheless wish to plot method returns, this can be done with an arrow and a dashed line.
Object Creation
     If a method creates an object, the method's arrow ends on the object's rectangular symbol. The Lifeline begins at this symbol.
Object Destruction
     If an object is destroyed when a method is called, the object's Lifeline ends with a cross below the method call symbol.
Example
A theatre’s ticket system allows tickets to be sold out of the seating plan on an Internet website. The seating plan manages the seats of a given event.

When a seat is selected by a user, the concerned object :seat calls the “buy” method of the “:order” object and transfers a reference to itself in the parameter. The order class object calls the method “isFree(seat)” of the Seating Plan class to check whether the seat transferred into the parameter is free. If the seat is still free, the Seating Plan object calls its own method, “reserve”. The seat is thereby reserved for the time being.

After this has taken place, the invoice for the seat is created. The seating plan object then calls the “book” method with the chosen seat as parameter. The “book” method belongs to the object :order. This represents a list of the invoice line items - which is not modeled here. After the invoice line items have been compiled by the object :sales, it calls the “createInvoice” method of the object :order. To notify the Internet ticket system user of the success of his purchase, the Order object calls the method “confirmed” of the class Seat. The visitor confirms the order, and the method “confirmed” returns with the value “true”. The order is completed.

 

The message is noted on the message arrow with the following syntax:

[attribute =] name [(arguments)] [: return value]

 

Whereby

  • “attribute” can be a local variable of the interaction, or an Element of a Lifeline. The attribute allocation is only used in synchronous messages with return value.
  • “name” is the name of the message to be called, or the name of the signal to be sent. The sending of a signal is always as asynchronous character.
  • “arguments” is a comma-separated list of parameter values transferred to the message.

 

If an object is created via the setting of a message (e.g. by calling the method “new”), then the Lifeline of this object begins at this position. The destruction of an object is represented by a cross on the Lifeline.

Symbols

The following table contains the sequence diagram symbols.

Symbol/Name

Use

System Border

The System Border isolates the concerned part of the program from the rest of the program. It usually serves as the start point of the triggering method call. Program flow is not always triggered by an object outside of the concerned area, so that in this case no system limit must be set.

Object

An object is shown by a rectangle containing the name. Underlining of the name may be omitted so that no confusion with the class name can occur. Classes are not displayed in this diagram. Objects are shown along the upper sheet edge.

Lifeline

Every object is on a vertical line - the Lifeline. An object’s lifeline grows in the direction of the lower sheet edge. For objects which already exist at the start of the program section, the object symbols are drawn on the upper sheet edge. For objects which are re-created within the program section, the symbol is drawn at the level of the method call in the course of which the object was created.

Object Activity

If an object is involved in a method call, it is active. The Lifeline thickens. If an object calls its own method, the Lifeline thickens again. These activities are not always drawn.

Method Calls

When an object calls a method of another object, this is symbolized by a continuous arrow which points to the object from which the method was called. The method name is placed on this symbol. This name can be added to the parameters list in parentheses.

Return of a Method

In principle, only the method calls are shown in the sequence diagram. Should you nevertheless wish to plot method returns, this can be done with an arrow and a dashed line.

Object Creation

If a method creates an object, the method's arrow ends on the object's rectangular symbol. The Lifeline begins at this symbol.

Object Destruction

If an object is destroyed when a method is called, the object's Lifeline ends with a cross below the method call symbol.

 

 

 

Example

A theatre’s ticket system allows tickets to be sold out of the seating plan on an Internet website. The seating plan manages the seats of a given event.

When a seat is selected by a user, the concerned object :seat calls the “buy” method of the “:order” object and transfers a reference to itself in the parameter. The order class object calls the method “isFree(seat)” of the Seating Plan class to check whether the seat transferred into the parameter is free. If the seat is still free, the Seating Plan object calls its own method, “reserve”. The seat is thereby reserved for the time being.

After this has taken place, the invoice for the seat is created. The seating plan object then calls the “book” method with the chosen seat as parameter. The “book” method belongs to the object :order. This represents a list of the invoice line items - which is not modeled here. After the invoice line items have been compiled by the object :sales, it calls the “createInvoice” method of the object :order. To notify the Internet ticket system user of the success of his purchase, the Order object calls the method “confirmed” of the class Seat. The visitor confirms the order, and the method “confirmed” returns with the value “true”. The order is completed.