UML Sequence Diagrams

UML Sequence Diagrams

Sequence diagrams are one of the most interesting and useful diagrams in the Unified Modeling Language (UML). They help you document and understand the dynamic aspects of your software system—specifically the sequence of messages that are sent and received between objects. They can help you comprehend and solve difficult issues in the process-intensive portions of your applications.

This third article in the series covers one of the most interesting diagrams in the UML—sequence diagrams. They are most often used in the construction phase of software projects and are especially useful when analyzing the processintensive portions of your application. Sequence diagrams are closely related to collaboration diagrams (discussed in the next article in this series). While the collaboration diagram’s main focus is to show how objects are associated with each other, sequence diagrams show the time ordering of messages between objects.

Why use Sequence Diagrams?

As mentioned in the previous article on class diagrams, unless you are using business objects in your applications, you won’t have much need for sequence diagrams. This is because if you’re not using business objects, most of your application logic resides inside methods of user interface objects or in functions and procedures—and there really isn’t much messaging that occurs between objects. However, once you decide to elevate your programming by using business objects in your applications, sequence diagrams help you answer two very important questions:

1. Which objects should be assigned a particular responsibility?

2. In what order should messages pass between objects?

These questions are very difficult to answer correctly when you simply try to envision object messaging in your head. In contrast, when you document your thought process in a sequence diagram, suddenly the answers to these questions become crystal clear. At a higher level, it also helps you comprehend the overall flow of a particular process. In addition, sequence diagrams help you easily identify unnecessary messages between objects and factor them out. You may also discover that objects you originally thought should be involved in a particular process shouldn’t be involved at all!

Modeling Use Cases

So, what kinds of things should you document in a sequence diagram? Usually, a sequence diagram is used to document the logic of a use case (for a discussion of use cases, see CoDe Magazine Issue 2 – 2001). In this article, we’ll go step-bystep through the process of building a sequence diagram for a particular use case, but first, you need to learn about the different elements of sequence diagrams.

Sequence Diagram Elements

There are four primary elements of a sequence diagram:

• Objects • Lifelines • Messages • Focus of control

Objects

Objects that are involved in the sequence of events you are documenting should be placed at the top of the sequence diagram across its horizontal axis. As shown in Figure 1, it’s a good idea to place the actor that initiates a particular sequence at the upper left side of the diagram. You can also place a “UI” (user interface) placeholder class on the diagram with which the actor interacts. This is an excellent tool for providing context for a use case. Next, you can place objects on the diagram that are instantiated by the UI (e.g., the User object) or by other objects. You should place the most important objects to the left and subordinate objects to the right. It’s best to place objects on the diagram in a way that minimizes lines that cross.

Lifelines

The lifeline is the dotted line that extends down the vertical axis from the base of each object. The lifeline indicates the life span of an object over a period of time.

Messages

Messages are the most important element of a sequence diagram. They indicate when one object calls an operation on another object (or itself). They are also used to indicate return values. Message flow begins at the top left object (which is usually an actor) and flows down the vertical axis from one object to another.

Messages are shown on UML diagrams as labeled arrows, with the arrowhead indicating the direction of the call. When a message is sent to an object, the text associated with the message specifies the name of the method that is being called on the receiving object. For example, in Figure 1, the ValidateUser() message is sent to the “User” object. This indicates that the User object has a method named “ValidateUser.” In addition, the ValidateUser() method accepts two arguments: ID and password. With most modeling tools you can optionally display the type of the arguments (e.g., boolean, currency, string).

When a message is sent from an actor to the user interface, it does not indicate the name of a method on the UI. Rather, since the UI class is simply a placeholder, the message text is used to indicate the action that the actor performs (e.g., “Enter ID and password”).

Note: When you add a message to a sequence diagram, most modeling tools automatically add a corresponding operation to the class that receives the message.

When an object calls an operation on itself, this is known as a reflexive message or message to self. For example, in Figure 1, the UI object (though not a real object) has a reflexive “Display error” message.

It is not necessary to document a return for every message on a sequence diagram because in the UML specification a return is implied. However, if the method is returning something of interest, it’s perfectly valid to show the return value on the diagram.