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 pro­gram­ming, as well as business processes. The aim is to present complex facts in such a way that they will be easily un­der­stood. UML has a stan­dard­ized notation for this purpose. A certain form will always stand for a certain component or a certain behavior. The so-called meta­mod­el­ing defines language units and their meaning within the UML. This also includes de­ter­min­ing how certain elements interact with each other, and which hi­er­ar­chies exist between language units.

Elements and re­la­tion­ships are rep­re­sent­ed in UML in the form of diagrams. UML2 dis­tin­guish­es 14 different types of diagrams. These get assigned to one of three different cat­e­gories: structure diagrams, behavior diagrams, and in­ter­ac­tion diagrams.

Structure diagrams represent a system and its com­po­nents in a static state. They il­lus­trate the re­la­tion­ships between in­di­vid­ual elements or between elements and su­per­or­di­nate 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 rep­re­sen­ta­tion. An example of this is activity diagrams.

• In­ter­ac­tion diagrams are a subset of be­hav­ioral diagrams. They are listed sep­a­rate­ly because they model a specific behavior – namely the in­ter­ac­tions between system elements. The basic building blocks of in­ter­ac­tions are the so-called “lifelines.” These are objects (the smallest in­de­pen­dent building blocks of object-oriented pro­gram­ming) that represent in­di­vid­ual par­tic­i­pants in an in­ter­ac­tion. The most commonly used in­ter­ac­tion diagram is the sequence diagram.

The UML sequence diagram displays events in chrono­log­i­cal 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 re­stric­tions to your model. For example, a time limit for a par­tic­u­lar 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 char­ac­ter­is­tics of a system element. In in­ter­ac­tions, the objects are lifelines.

Requests are made and responses are sent con­stant­ly 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 in­ter­ac­tions is usually rep­re­sent­ed 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 ap­pli­ca­tion case diagram in par­tic­u­lar by its detailed order. If a new business process is to be in­tro­duced, the ap­pli­ca­tion case provides a good overview of the re­quire­ments. If, on the other hand, you want to define specific cases and a schedule, you create a sequence diagram. Here, you can display in­di­vid­ual subareas in more detail. With this so-called ap­pli­ca­tion scenario, you put the logical con­nec­tions of your ap­pli­ca­tion case through their paces.

UML sequence diagrams are also useful when you want to graph com­pli­cat­ed processes for better un­der­stand­ing. The clear modeling allows you to quickly identify which stations a single task must go through in order to be suc­cess­ful­ly completed. This allows you to plan and test your methods before they are im­ple­ment­ed in everyday business or in a computer system.

To represent the control struc­tures of a higher pro­gram­ming language, connect several sequence diagrams together in a combined fragment.

A UML diagram should help everyone un­der­stand complex systems better. The modeling language uses visual symbols for this purpose. UML can be adapted for ex­cep­tions and certain ap­pli­ca­tion groups. However, it makes sense to mainly use the language specified by the Object Man­age­ment Group (also known as OMG). Otherwise, the whole point of using a diagram, i.e. to make complex systems un­der­stand­able, will be lost, as the diagram will be in­com­pre­hen­si­ble. The following spec­i­fi­ca­tions cor­re­spond to the UML standard in version UML 2.5.

The lifeline rep­re­sents 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 char­ac­ter­is­tics, one of them must be selected. Al­ter­na­tive­ly, it can also be said that the mul­ti­plic­i­ty is never >1.

A dashed line goes down from the rec­tan­gu­lar head. This line rep­re­sents 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 stereo­types 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 hor­i­zon­tal 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 stereo­types, the dashed lifeline decreases ver­ti­cal­ly downwards.

If you have already worked out a concept using a use case diagram, the sequence diagram can help you work out the in­di­vid­ual steps, taking into account the con­ceiv­able actors and objects.

Bound­aries stand for in­ter­faces that interact with external actors. These objects can be, for example, user in­ter­faces – in which case the actor would be a person. Entities, on the other hand, stand for data con­tain­ers or objects that contain system data. For borders and entities to com­mu­ni­cate, you need a control element. The control does not nec­es­sar­i­ly have to be an object. A method at­trib­uted 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 stereo­types com­mu­ni­cate according to four rules – border objects are the interface re­spon­si­ble for com­mu­ni­ca­tion with actors. Actors com­mu­ni­cate ex­clu­sive­ly with borders.
• In contrast, control objects com­mu­ni­cate with other control objects as well as with entities and bound­aries. In return, they do not interact with actors.
• Borders com­mu­ni­cate 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 ex­pres­sion 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 pa­ra­me­ters of a sender (values that result from an operation) as operands. Without output pa­ra­me­ters, the operand must remain empty. In this case, you simply model the wildcard place­hold­er, not the rewind value. If there is an operand, the system evaluates this again in the ap­pear­ance spec­i­fi­ca­tion. The result of the eval­u­a­tion specifies the values for the pa­ra­me­ters "out," "inout," and "return."

UML specifies three symbols that determine the recipient of the message as parameter ex­pres­sion. The recipient is the so-called as­sign­ment target of the message. The response message assigns it the response value from the sender's output parameter. These are the stan­dard­ized symbols:

• Unknown
• In­ter­ac­tion parameter
• Attribute

Unknown is an empty parameter and stands for the wildcard. The in­ter­ac­tion parameter is an owned parameter of the in­ter­ac­tion to which it is inherent. This means that the in­ter­ac­tion has the parameter. This has a name. Operation and in­ter­ac­tion pa­ra­me­ters have the same type. At­trib­ut­es can be named without re­stric­tions. They represent the name of a context behavior. This behavior de­ter­mines either the lifeline to which the message returns or the sur­round­ing in­ter­ac­tion. If the in­ter­ac­tion does not determine any behavior, it acts as context itself.

Gates are simply points at the end of a message. They belong to type Mes­sageEnd. It marks the sender and recipient of a message. Gates il­lus­trate the flow of in­for­ma­tion and show how messages move between two in­ter­ac­tion fragments. More precisely, they represent con­nec­tion points for messages between in­ter­ac­tion benefits and in­ter­ac­tions – and between in­ter­ac­tion operands within and outside of a combined fragment.

The UML sequence diagram rec­og­nizes four types of gates. They differ in the fragments of in­ter­ac­tion with which they are as­so­ci­at­ed:

• The actual gateway: In­ter­ac­tion benefits point from one diagram to another. The actual gate opens the con­nec­tion at the outer edge of the in­ter­ac­tion benefit for messages from the in­ter­ac­tion to which the in­ter­ac­tion benefit refers. The gate has an as­so­ci­a­tion to the in­ter­ac­tion benefit and accepts incoming and outgoing messages.
• The formal gate: For an in­ter­ac­tion to exchange messages with an in­ter­ac­tion benefit, it needs a formal gate. The gate is located on the inside of the frame.
• Inner Com­bined­Frag­ment 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 Com­bined­Frag­ment 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 Mes­sage­Sort.

Messages in com­mu­ni­ca­tion diagrams play a special role. This diagram type is a simple form of the sequence diagram. Com­mu­ni­ca­tion diagrams model how lifelines interact. Unlike sequence diagrams, they focus on the system ar­chi­tec­ture and how it de­ter­mines the flow of messages. Although you can show a detailed ar­chi­tec­ture, in­ter­ac­tion 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-se­quen­tial messages in the com­mu­ni­ca­tion diagram.

The UML notation for com­mu­ni­ca­tion diagrams pre­scribes a simple sequence diagram frame. A rectangle with a pen­tag­o­nal label in the head. In the label, the des­ig­na­tion “sd” marks this diagram type. Next to it, note the in­ter­ac­tion name. Messages take a different form here – they connect the rec­tan­gu­lar lifelines (UML: object nodes) as simple straight lines (UML: edges).

Above this, note the sequence ex­pres­sion, together with an arrow pointing in the direction of the receiver. The sequence name has the following form: [Integer name][Rep­e­ti­tion]. 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 si­mul­ta­ne­ous broad­casts. The system sends two messages with the sequence names 1.2.3a and 1.2.3b si­mul­ta­ne­ous­ly because of the identical integer. The rep­e­ti­tion contains either a re­stric­tion that de­ter­mines when the message is sent or a value that de­ter­mines 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 re­stric­tion. Only if the re­stric­tion is fulfilled can the affected element exert a certain behavior. There are many different elements that can have this kind of guard – actions, at­trib­ut­es, behavior, and others. UML does not prescribe a strict language, but offers OCL, the Object Con­straint Language, as a native option. Boolean variables are also often used.

An in­ter­ac­tion re­stric­tion consists of this kind of Boolean ex­pres­sion. The re­stric­tion serves as a guardian for the operand within a combined fragment. If the value of the con­straint is true, then the sur­round­ing in­ter­ac­tion fragment can start its behavior. Note the re­stric­tion in square brackets on the lifeline above an execution spec­i­fi­ca­tion. Stan­dard­iza­tion allows combined fragments without re­stric­tion of in­ter­ac­tion. In this case, the system assumes that incoming messages are true.

Since in­ter­ac­tion benefits refer to other diagrams, these external factors determine their behavior. While the linked in­ter­ac­tion has formal gates, the referring in­ter­ac­tion has the actual gate.

Part-de­com­po­si­tion is the partial, se­quen­tial de­com­po­si­tion of a lifeline within an in­ter­ac­tion through another in­ter­ac­tion. Using such a de­com­po­si­tion, you can separate details from each other and look at in­di­vid­ual sub-functions more closely. When messages enter or leave the dis­as­sem­bled lifeline, they are con­sid­ered actual gates. These are connected to the formal gates of the de­com­po­si­tion action. Gates and pa­ra­me­ters of both elements must match. As an in­ter­ac­tion benefit, the partial de­com­po­si­tion also receives the label "ref" and is defined by the as­so­ci­at­ed in­ter­ac­tion.

Start and end mark the event oc­cur­rence spec­i­fi­ca­tions. Ac­ti­va­tion 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 oc­cur­rence spec­i­fi­ca­tion rep­re­sents the start or end of an action. The message oc­cur­rence spec­i­fi­ca­tion gives the signal to send and receive a message. Their value therefore always depends on the message or action.

Ac­ti­va­tion has no separate notation. It exists im­plic­it­ly at the outer edges of the execution spec­i­fi­ca­tion rectangle. If the execution spec­i­fi­ca­tion performs an atomic action, start and end as­so­ci­a­tions refer to the same oc­cur­rence spec­i­fi­ca­tion. You can emphasize this with a link line between action and incoming ap­pear­ance spec­i­fi­ca­tion.

While other ap­pear­ance spec­i­fi­ca­tions do not require any notation, mark the message ap­pear­ance spec­i­fi­ca­tion de­struc­tion with a large X. It marks the res­o­lu­tion of an object instance at a specific point on the lifeline. The lifeline ends with it. Sub­or­di­nate instances or per­for­mance spec­i­fi­ca­tions at later points in the timeline are then invalid since they no longer exist either after the de­struc­tion of an object.

Sometimes, execution spec­i­fi­ca­tions overlap. For example, if an object sends a message to itself, an execution spec­i­fi­ca­tion sends a message to another instance of this class. Both spec­i­fi­ca­tions are partly on the same lifeline at the same time. In the UML sequence diagram, you represent this cir­cum­stance with over­lap­ping rec­tan­gles.

The state variant specifies a re­stric­tive value. If this value is equal to the object state, the track is con­sid­ered valid. If the object does not meet the re­stric­tion, its track is invalid.

According to the UML sequence diagram notation, the state variant is either in curly brackets on the execution spec­i­fi­ca­tion or you use the rounded rectangle of the state class.

Combined fragments belong to the in­ter­ac­tion fragments. These fragments are abstract elements of the system. They stand for in­ter­ac­tion units. This means that they are part of an in­ter­ac­tion. On the other hand, they are also small in­ter­ac­tions them­selves. Combined fragments in a sequence diagram determine the behavior of several in­ter­ac­tion fragments. However, they only form the framework. They are defined by in­ter­ac­tion operators and in­ter­ac­tion operands. Operands contain one or more messages. On the lifeline in front of a combined fragment, a re­stric­tion, 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 con­di­tions. The operator de­ter­mines which re­la­tion­ships operands within a fragment have to each other and which re­la­tion­ship they have to the su­per­or­di­nate fragment.

UML defines 12 in­ter­ac­tion operators

Al­ter­na­tive:

Within the combined fragment with the in­ter­ac­tion operator "Al­ter­na­tive," a sub­or­di­nate 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 "Al­ter­na­tive." Use the ab­bre­vi­a­tion "alt" for the label. You divide the rec­tan­gu­lar frame by a hor­i­zon­tal 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 al­ter­na­tive 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 al­ter­na­tive. 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 al­ter­na­tive, on the other hand, is empty. Mark a fragment with the in­ter­ac­tion operator "Option" with the label "opt."

Break:

A combined fragment with the in­ter­ac­tion operator "break" in­ter­rupts 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-de­ter­min­is­tic. 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 ap­pro­pri­ate 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 rep­e­ti­tions is exceeded, the loop also loosens, but the process is ter­mi­nat­ed as invalid.

Your task also changes depending on how you arrange the con­tin­u­a­tion in the sequence diagram. If the con­tin­u­a­tion is at the beginning of your in­ter­ac­tion diagram, you use it to model the behavior of the con­tin­u­a­tion. If the con­tin­u­a­tion is at the end of your in­ter­ac­tion fragment, it forwards the process. If you name your con­tin­u­a­tion (as in the example: notOK), the next fragment on the lifeline must have a con­tin­u­a­tion with the same name (notOK) or it may not model a con­tin­u­a­tion. If the con­tin­u­a­tion is in the fragment alone, this cor­re­sponds to a con­tin­u­a­tion at the end of the fragment.