How to create Sequence Diagrams

The sequence diagram is a diagram from the Unified Modeling Language (UML). UML is an object-oriented modeling language. This kind of language consists of graphic elements. UML models systems and processes of object-oriented programming, as well as business processes. The aim is to present complex facts in such a way that they will be easily understood. UML has a standardized notation for this purpose. A certain form will always stand for a certain component or a certain behavior. The so-called metamodeling defines language units and their meaning within the UML. This also includes determining how certain elements interact with each other, and which hierarchies exist between language units.

Elements and relationships are represented in UML in the form of diagrams. UML2 distinguishes 14 different types of diagrams. These get assigned to one of three different categories: structure diagrams, behavior diagrams, and interaction diagrams.

Structure diagrams represent a system and its components in a static state. They illustrate the relationships between individual elements or between elements and superordinate concepts. An example of this is the class diagram.

Behavior diagrams represent processes and the behavior of a system. In contrast to structure diagrams, the sequence of processes and time also plays a role in the representation. An example of this is activity diagrams.

• Interaction diagrams are a subset of behavioral diagrams. They are listed separately because they model a specific behavior – namely the interactions between system elements. The basic building blocks of interactions are the so-called “lifelines.” These are objects (the smallest independent building blocks of object-oriented programming) that represent individual participants in an interaction. The most commonly used interaction diagram is the sequence diagram.

The UML sequence diagram displays events in chronological order. This is why it is sometimes referred to as an event diagram or event scenario. The exact order of the events is the most important element. However, you can add restrictions to your model. For example, a time limit for a particular process (such as entering a PIN at an ATM) can trigger the actions for an event (card issuance if no input is made after a certain time).

The sequence diagram basically describes how objects exchange messages in a certain order. Objects are the basic building block of UML diagrams. Depending on the diagram type, they represent certain characteristics of a system element. In interactions, the objects are lifelines.

Requests are made and responses are sent constantly within one system. The recipient makes a decision based on the specific request and the pre-defined rules of the recipient. This kind of network of possible decisions and interactions is usually represented by an activity diagram. If you imagine all possible decisions (yes/no) as a tree diagram, you’ll probably be imagining a highly branched network. The sequence diagram only shows a specific path within this network.

The sequence diagram differs from the UML application case diagram in particular by its detailed order. If a new business process is to be introduced, the application case provides a good overview of the requirements. If, on the other hand, you want to define specific cases and a schedule, you create a sequence diagram. Here, you can display individual subareas in more detail. With this so-called application scenario, you put the logical connections of your application case through their paces.

UML sequence diagrams are also useful when you want to graph complicated processes for better understanding. The clear modeling allows you to quickly identify which stations a single task must go through in order to be successfully completed. This allows you to plan and test your methods before they are implemented in everyday business or in a computer system.

To represent the control structures of a higher programming language, connect several sequence diagrams together in a combined fragment.

A UML diagram should help everyone understand complex systems better. The modeling language uses visual symbols for this purpose. UML can be adapted for exceptions and certain application groups. However, it makes sense to mainly use the language specified by the Object Management Group (also known as OMG). Otherwise, the whole point of using a diagram, i.e. to make complex systems understandable, will be lost, as the diagram will be incomprehensible. The following specifications correspond to the UML standard in version UML 2.5.

The lifeline represents the course of time for a process. The head of a lifeline consists of a rectangle. This usually contains the object name and the class name. If the object name is missing, the lifeline stands for an unnamed instance of the object. In this case, you can assume that all objects of the same class act equally in this sequence. The lifeline always stands for a single operand. If the operand has several characteristics, one of them must be selected. Alternatively, it can also be said that the multiplicity is never >1.

A dashed line goes down from the rectangular head. This line represents the course of time. Time is depicted linearly, moving downwards. Messages are sent and responses given along the timeline. A message to be sent after another message is at the bottom of the timeline. The notation is never about clear times, but always about the order, and messages are always arranged one below the other, unless they exist in parallel combined fragments.

Lifelines indicate how long an object is actively involved in a process. This is shown by how long one lifeline is compared to the others. Some objects are destroyed before the process is over. Objects that are no longer required are marked on their lifeline with an “X” at the point where they should be destroyed.

A sequence diagram is well suited to checking how failsafe your system is. Three class stereotypes of the lifeline can be used for this purpose:

• Entity
• Border
• Control

At the top of the picture you’ll see the three lifelines including notation: The entity has a round head that lies on a horizontal line. At the border, a line goes off the middle of the circle and connects with a vertical line – like an upturned T that goes off to the side of the head. The head of the control consists of an arrow that rotates in a circle. From all these class stereotypes, the dashed lifeline decreases vertically downwards.

If you have already worked out a concept using a use case diagram, the sequence diagram can help you work out the individual steps, taking into account the conceivable actors and objects.

Boundaries stand for interfaces that interact with external actors. These objects can be, for example, user interfaces – in which case the actor would be a person. Entities, on the other hand, stand for data containers or objects that contain system data. For borders and entities to communicate, you need a control element. The control does not necessarily have to be an object. A method attributed to one of the other two elements also works. The control element connects entity and boundary as a mediator. It monitors the signals of both elements and checks them for logic.

• The three stereotypes communicate according to four rules – border objects are the interface responsible for communication with actors. Actors communicate exclusively with borders.
• In contrast, control objects communicate with other control objects as well as with entities and boundaries. In return, they do not interact with actors.
• Borders communicate with control objects and with actors.
• Entities are rooted deepest in the system as data carriers. You only exchange data with control objects.

Response messages may only have one expression with a maximum of one operand per parameter. If the sender of a reply does not output any values, the message also has no specific values that it sends. Normally, the message models the output parameters of a sender (values that result from an operation) as operands. Without output parameters, the operand must remain empty. In this case, you simply model the wildcard placeholder, not the rewind value. If there is an operand, the system evaluates this again in the appearance specification. The result of the evaluation specifies the values for the parameters "out," "inout," and "return."

UML specifies three symbols that determine the recipient of the message as parameter expression. The recipient is the so-called assignment target of the message. The response message assigns it the response value from the sender's output parameter. These are the standardized symbols:

• Unknown
• Interaction parameter
• Attribute

Unknown is an empty parameter and stands for the wildcard. The interaction parameter is an owned parameter of the interaction to which it is inherent. This means that the interaction has the parameter. This has a name. Operation and interaction parameters have the same type. Attributes can be named without restrictions. They represent the name of a context behavior. This behavior determines either the lifeline to which the message returns or the surrounding interaction. If the interaction does not determine any behavior, it acts as context itself.

Gates are simply points at the end of a message. They belong to type MessageEnd. It marks the sender and recipient of a message. Gates illustrate the flow of information and show how messages move between two interaction fragments. More precisely, they represent connection points for messages between interaction benefits and interactions – and between interaction operands within and outside of a combined fragment.

The UML sequence diagram recognizes four types of gates. They differ in the fragments of interaction with which they are associated:

• The actual gateway: Interaction benefits point from one diagram to another. The actual gate opens the connection at the outer edge of the interaction benefit for messages from the interaction to which the interaction benefit refers. The gate has an association to the interaction benefit and accepts incoming and outgoing messages.
• The formal gate: For an interaction to exchange messages with an interaction benefit, it needs a formal gate. The gate is located on the inside of the frame.
• Inner CombinedFragment gate: Within a combined fragment, there is a gate on the frame. It exchanges messages with message ends from the combined fragment with messages with message ends outside the combined fragment.
• Outer CombinedFragment gate: This gate sits on the outer edge of a combined fragment. It forms the opposite pole to the inner gate.

Gates can have explicit or implicit names that must match in pairs. Actual and formal gates must match, as must inner and outer gates for combined fragments. In addition, the messages must go in the same direction and have the same property values and the same MessageSort.

Messages in communication diagrams play a special role. This diagram type is a simple form of the sequence diagram. Communication diagrams model how lifelines interact. Unlike sequence diagrams, they focus on the system architecture and how it determines the flow of messages. Although you can show a detailed architecture, interaction fragments such as combined fragments do not use them. As a result, a force element is missing. Instead, number the messages. Sometimes messages can overtake others. The sequence of outgoing messages then differs from the sequence of incoming messages. However, the UML standard advises against such non-sequential messages in the communication diagram.

The UML notation for communication diagrams prescribes a simple sequence diagram frame. A rectangle with a pentagonal label in the head. In the label, the designation “sd” marks this diagram type. Next to it, note the interaction name. Messages take a different form here – they connect the rectangular lifelines (UML: object nodes) as simple straight lines (UML: edges).

Above this, note the sequence expression, together with an arrow pointing in the direction of the receiver. The sequence name has the following form: [Integer name][Repetition]. The integer specifies the hierarchy for nested elements. If one of the integers (for example 1.2.2 and 1.2.3) differs in two messages, the system sends them one after the other. The name, on the other hand, stands for simultaneous broadcasts. The system sends two messages with the sequence names 1.2.3a and 1.2.3b simultaneously because of the identical integer. The repetition contains either a restriction that determines when the message is sent or a value that determines how often the message is repeated.

In UML, the guard guards the behavior of an element. The element must either:

• Meet a certain condition
• Not exceed or fall below a certain value
• Confirm an assertion

A guard is therefore a restriction. Only if the restriction is fulfilled can the affected element exert a certain behavior. There are many different elements that can have this kind of guard – actions, attributes, behavior, and others. UML does not prescribe a strict language, but offers OCL, the Object Constraint Language, as a native option. Boolean variables are also often used.

An interaction restriction consists of this kind of Boolean expression. The restriction serves as a guardian for the operand within a combined fragment. If the value of the constraint is true, then the surrounding interaction fragment can start its behavior. Note the restriction in square brackets on the lifeline above an execution specification. Standardization allows combined fragments without restriction of interaction. In this case, the system assumes that incoming messages are true.

Since interaction benefits refer to other diagrams, these external factors determine their behavior. While the linked interaction has formal gates, the referring interaction has the actual gate.

Part-decomposition is the partial, sequential decomposition of a lifeline within an interaction through another interaction. Using such a decomposition, you can separate details from each other and look at individual sub-functions more closely. When messages enter or leave the disassembled lifeline, they are considered actual gates. These are connected to the formal gates of the decomposition action. Gates and parameters of both elements must match. As an interaction benefit, the partial decomposition also receives the label "ref" and is defined by the associated interaction.

Start and end mark the event occurrence specifications. Activation starts with the start event and ends with the closing event. These fragments represent a single moment and exist on a single lifeline. The event occurrence specification represents the start or end of an action. The message occurrence specification gives the signal to send and receive a message. Their value therefore always depends on the message or action.

Activation has no separate notation. It exists implicitly at the outer edges of the execution specification rectangle. If the execution specification performs an atomic action, start and end associations refer to the same occurrence specification. You can emphasize this with a link line between action and incoming appearance specification.

While other appearance specifications do not require any notation, mark the message appearance specification destruction with a large X. It marks the resolution of an object instance at a specific point on the lifeline. The lifeline ends with it. Subordinate instances or performance specifications at later points in the timeline are then invalid since they no longer exist either after the destruction of an object.

Sometimes, execution specifications overlap. For example, if an object sends a message to itself, an execution specification sends a message to another instance of this class. Both specifications are partly on the same lifeline at the same time. In the UML sequence diagram, you represent this circumstance with overlapping rectangles.

The state variant specifies a restrictive value. If this value is equal to the object state, the track is considered valid. If the object does not meet the restriction, its track is invalid.

According to the UML sequence diagram notation, the state variant is either in curly brackets on the execution specification or you use the rounded rectangle of the state class.

Combined fragments belong to the interaction fragments. These fragments are abstract elements of the system. They stand for interaction units. This means that they are part of an interaction. On the other hand, they are also small interactions themselves. Combined fragments in a sequence diagram determine the behavior of several interaction fragments. However, they only form the framework. They are defined by interaction operators and interaction operands. Operands contain one or more messages. On the lifeline in front of a combined fragment, a restriction, also called a guard, watches over the included operand.

As already described, operands are constant or variables that run through a process. Operators influence the behavior of operands. For example, the Boolean operator "OR" can specify that operand A or operand B is executed (or both). Within a combined fragment, an operand specifies that a specific message is sent under certain conditions. The operator determines which relationships operands within a fragment have to each other and which relationship they have to the superordinate fragment.

UML defines 12 interaction operators

Alternative:

Within the combined fragment with the interaction operator "Alternative," a subordinate fragment can only send a message if a certain condition is fulfilled. Otherwise, a competing fragment within the frame will send its message. The image above shows an example of a combined fragment with the operator "Alternative." Use the abbreviation "alt" for the label. You divide the rectangular frame by a horizontal dashed line. The upper area is a condition.

Guard:

The guard checks whether the condition of the operand is fulfilled. If so, the system sends a message in the condition area. If not, it sends a message in the alternative area. An operand within this combined fragment always needs a guard that is judged true to be executed. If the condition operand does not have an explicit guard, an implicit guard is assumed. So this fragment is always an either-or decision.

Option:

This combined fragment is modeled in the sequence diagram like the alternative. It also stands for a decision. However, there is only one operand. The decision is therefore decided on the basis of whether or not the operand should be executed. The operand with a condition must not be empty. Its alternative, on the other hand, is empty. Mark a fragment with the interaction operator "Option" with the label "opt."

Break:

A combined fragment with the interaction operator "break" interrupts the parent fragment. If a lifeline meets the condition of the operand, the system executes the combined fragment. But it ignores the rest of the parent fragment. In order for all lifelines to reach their full life span, you should include each lifeline in the combined fragment. Otherwise, a lifeline may stop in the middle of the process without being properly destroyed. If the break fragment lacks a guard, the decision is non-deterministic. We therefore recommend using a guard.

At an ATM, for example, you can enter the correct PIN number three times. If the PIN is incorrect, you will be asked to repeat the entry. In the UML sequence diagram, note the message "PIN entry" and its response "Wrong PIN. Try again with the appropriate arrows. The label has the form Loop (0,2). The Boolean variable is [wrong PIN]. As long as the PIN is wrong, the loop repeats itself twice. If the PIN is correct, the system resolves the loop. If the maximum number of repetitions is exceeded, the loop also loosens, but the process is terminated as invalid.

Your task also changes depending on how you arrange the continuation in the sequence diagram. If the continuation is at the beginning of your interaction diagram, you use it to model the behavior of the continuation. If the continuation is at the end of your interaction fragment, it forwards the process. If you name your continuation (as in the example: notOK), the next fragment on the lifeline must have a continuation with the same name (notOK) or it may not model a continuation. If the continuation is in the fragment alone, this corresponds to a continuation at the end of the fragment.