Sequence Diagrams

Frame

In UML 2, the frame is an element that is used as a basis for many other diagram elements in UML 2, but the first place most people will encounter a frame element is as the graphical boundary of a diagram. In addition to providing the visual border, the frame element also has an important functional use in diagrams that depict interaction, such as the sequence diagram. Incoming and outgoing messages can make use of the frame, seen in figure 8 above, which is done by connecting the messages to the border of the frame.

Figure 9: the Frame

Lifelines

A lifeline represents an individual participant in the interaction. Lifeline notation elements are placed across the top of the diagram. They represent either roles or object instances that participate in the sequence being modeled. Lifelines are drawn with a dashed line descending from the centre of the bottom edge. The name of the lifeline is placed inside the box.

Figure 3: the Lifeline

The lifeline in figure 10 represents an instance of the class Student, whose instance name is freshman. The lifeline name here is underlined, which means that the lifeline represents a specific instance of a class in a sequence diagram, and not a particular kind of instance (a role). Sequence diagrams can include roles, even if they don’t really specify who holds those roles by name. This allows diagram re-use in different contexts. Instance names are underlined, but role names are not.

Messages

Your first message of a sequence diagram always starts at the top, and is typically located in the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower than the previous message. If you want to show an object (e.g. lifeline) sending a message to another object, you draw a line to the recieving object with a solid arrowhead, or with a stick, dependant on the signal. This depends on the signal and type of message, which can be seen in figure 12 below.

Figure 11: the Message

The message / method name is placed above the arroved line. The message that is being sent to the recieving object represents an operation / method that the recieving object’s class implements. In figure 12, the analyst object makes a call to the system object which is an instance of the ReportingSystem class. The analyst object is calling the system object’s getAvailableReports method. The system object then calls the getSecurityClearance method with the argument of userId on the secSystem object, which is of the class type SecuritySystem. (Note: When reading this sequence diagram, assume that the analyst has already logged into the system.)

Figure 12: an example message, with return messages present

Guards

When modeling object interactions, there will be times when a condition must be met for a message to be sent to the object. Guards are used throughout UML diagrams to control flow. In figure 14, the guard is the text “[pastDueBalance = 0]“. By having the guard on this message, the addStudent message will only be sent if the accounts recievable system returns a past due balance of zero. The notation for this in UML is pretty simple.

[pastDueBalance = 0]

Figure 13: the Guard

Alternatives

We use alternatives to designate a mutually exclusive choice between two or more message sequences. While it is possible for two or more guard conditions attached to different alternative operands to be true at the same time, but at most only one operand will actually occur at run time. Alternatives allow the modelling of the classic “if then else” logic we have come to know (and maybe even love).

An alternative combination fragment eleemnt is drawn using a frame. The word “alt” is placed inside the frame’s namebox. The larger rectangle is then divided into what UML 2 calls operands. (Note: Although operands look a lot like lanes on a highway, I specifically did not call them lanes. Swim lanes are a UML notation used on activity diagrams.) Operands are separated by a dashed line. Each operand is given a guard to test against, and this guard is placed towards the top left section of the operand on top of a lifeline. (Note: Usually, the lifeline to which the guard is attached is the lifeline that owns the variable that is included in the guard expression.) If an operand’s guard equates to “true,” then that operand is the operand to follow.

Alternative combination fragments are not limited to simple “if then else” tests. There can be as many alternatives path as are needed (or as you want). If you need more alternatvies, then all you need to do is add an operand to the rectangle with that sequence’s guard and messages.

Figure 14: the Alternative

All information can be found in further detail at the References below.

Option

The option cobination fragment is used to model a sequence that, given a certain condition, will occur; otherwise the sequence does not occur. An option is used to model the “if then” logic statement. It is similar to the alternative fragment notation, except that it only has one operand and there can never be an “else” guard. To draw an option, you first draw a frame. The text “opt” is placed inside the frame’s namebox and in the frame’s content areas the option’s guard is placed towards the top left corner on top of a lifeline.

Figure 5: the Option

Loops

Sometimes you will need to model a repetitive sequence, which can be done by making use of a loop. The loop combination fragment is very similar in appearance to the option combination fragment. You draw a frame, and in the frame’s namebox the text “loop” is placed. Inside the frame’s content area the loop’s guard is placed towards the top left corner, on top of a lifeline.

The loop shown in Figure 6 executes until the reportsEnu object’s hasAnotherReport message returns false. The loop in this sequence diagram uses a Boolean test to verify if the loop sequence should be run. To read this diagram, you start at the top, as normal. When you get to the loop combination fragment a test is done to see if the value hasAnotherReport equals true. If the hasAnotherReport value equals true, then the sequence goes into the loop fragment. You can then follow the messages in the loop as you would normally in a sequence diagram.

Figure 6: the Loop

Gates

Gates can be an easy way to model the passing of information to another sequence diagram. A gate itself is merely a message that is illustrated with one end connected to the sequence diagram’s frame edge and other end connected to a lifeline. The example diagram in Figure 7 has an entry gate called getBalance that takes the parameter of accountNumber. The getBalance message is an entry gate, because it is the arrowed line that is connected to the diagram’s frame with the arrowhead connected to a lifeline. The sequence diagram also has an exit gate that returns the balance variable. The exit gate is known, because it’s a return message that is connected from a lifeline to the diagram’s frame with the arrowhead connected to the frame.

Figure 7: the Gate

Break

The break combined fragment is almost identical in every way to the option combination fragment, with two exceptions:

• 1 - A break’s frame has a namebox with the text “break” instead of “option”.
• 2 - When a break’s message is to be executed, the enclosing interaction’s remainder messages will not be executed because the sequence breaks out of the enclosing interaction.

In this way, the break is much like the break keyword in a language such as C++ or Java. Breaks are commonly used to model exception handling in a sequence diagram.

Figure 8: the Break

Parallel

The parallel combination fragment is drawn using a frame, and you place the text “par” in the frame’s namebox. You then break up the frame’s content section into horizontal operands separated by a dashed line. Each operand in the frame represents a thread of execution done in parallel. Figure 9 is not the best example of Parallel in use, but it offers an easy to understand example of a sequence with parallel activities.

Figure 9: the Parallel

These concepts can be seen in more detail in the references.