Introduction 2 of 2 Sequence Diagram
A sequence diagram has two dimensions: the vertical dimension and the horizontal dimension, respectively representing the passage of time and the objects involved in the interaction. Object icons are placed horizontally at the top of the sequence diagram, and messages are passed between them. Figure 1 shows a sequence diagram for the login procedure of an Automatic Teller Machine (ATM) system.
Figure 1 – A Sequence Diagram for the Login Procedure of the ATM System
Refine Messages to Function Prototypes
The sequence diagram is then iteratively refined until all the messages are ultimately transformed into function prototypes, such as placeOrder(date, company, contactPerson), which provide a lot more useful information for implementation. In Figure 2, we can tell that there is an object called customer who places an order (another object) on behalf of his company. The customer performs a placeOrder operation with the required information. The three pieces of information (date, company, contactPerson) show from high level message initiate from the Customer and ultimately refine useful information for system implementation (what services are requirement by the Order object).
Figure 2 – A Customer Placing an Order
Lifelines are dashed vertical lines that indicate the object’s existence over time. In other words, if the lifeline extends to the bottom of the diagram, the object will continue to exist during the entire session of interaction. If the object is positioned at the top of the diagram, it indicates that the object actually exists before the interaction.
Object Creation and Deletion
By sending a <<create>> message, an object can create a new object dynamically. In the sequence diagram, the object is created at the position where the <<create>> message is sent out. Likewise, an object can also be deleted on receiving a <<destroy>> message from another object. A large cross (X) is placed at the end of the object’s lifeline to indicate that the object life has been terminated at that point. Figure 3 shows a simple example, illustrating how the Receiver object has been created and subsequently destroyed by the Sender object. The Receiver object is in a lower position in the diagram where the <<create>> message points at, and the Sender object was in existence before the interaction with the Receiver.
Figure 3 – Object Creation and Destruction
An object’s lifeline gives you an idea about the duration over which it exists, but it is not obvious when the object is actively performing a task or when it is inactive. A tall thin rectangle is used to represent the time when an object is active (See Figure 5). The top of the rectangle signifies when the activation starts and the bottom of the rectangle its completion time. In Figure 5, the Receive object is active when it receives a message from the Sender object.
Sometimes an object has an operation that invokes itself. This is called recursion. Suppose one of the objects in your system is a calculator, and suppose one of its operations computes interest. In order to compute compound interest for a timeframe that encompasses several compounding periods, the object’s interest-computation operation has to invoke itself a number of times. Sequence diagram for this is following:
Figure 3a. – Recursive Message
Simple and Collective Iteration
Sometimes, a task may be performed repeatedly for a number of times. In the sequence diagram, such a task is represented by a name with a proceeding ‘*’. In Figure 6, the add an item and get product details tasks may be carried out a number of times. Optionally you may place the continuation condition of the iteration in a pair of square brackets [ ]. Sometimes, you may want to repeat the execution of a block of messages, and this is represented in the sequence diagram by enclosing the group of messages within a rectangle. In figure 5 the add an item and get product details tasks are grouped together and contained in a rectangle to indicate that they will be performed repeatedly. Notice that the ‘*’ symbols preceding these two tasks have been removed.
Figure 4 – Simple Iterations in a Sequence Diagram
Figure 5 – Block Iterations in a Sequence Diagram
A branch is used to represent conditional action or concurrent action, and it is rendered by multiple arrows leaving the same point of the object’s life line. Each message may be labeled with a condition. If the conditions of the messages are mutually exclusive, the branch is a conditional, otherwise it is concurrency.
Figure 6 – Conditional Case in Sequence Diagram
Figure 7 shows the same set of events as a sequence diagram associated with the process of making a telephone call. We shall use this example to illustrate the concept of branching. Figure 11 shows the sequence diagram for the scenario when a call is successfully made, and the switch connects the caller and the callee at the same time when the callee has lifted the receiver. This is shown by a branching at the bottom of the sequence diagram. The messages in the figure are sometimes labeled with their sequence numbers which explicit specify their order chronologically. However, this is not a common practice because the time order of the messages is evident from the diagram. It should be noted that sequence numbers are necessary in a collaboration diagram. We will further explain the use of sequence numbers in collaboration diagrams in the following sections.
caller lifts receiver
dial tone begins
caller dials digits one at a time
switch makes routing
ringing tone on callee’s receiver begins
phone rings on callee’s receiver begins
callee lifts receiver
switch makes connection between caller and callee
switch connects callee
switch connects caller
Figure 7 – Scenario for Making a Phone Call
Figure 8 – Branching in Connecting Caller and Callee
- Introduction 1 of 2 Sequence Diagram
- Introduction 2 of 2 Sequence Diagram