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 stand­ard­izised notation for this purpose. A certain form will always stand for a certain component or a certain behaviour. The so-called metamod­el­ing defines language units and their meaning within the UML. This also includes de­term­in­ing how certain elements interact with each other, and which hier­arch­ies exist between language units.

Elements and re­la­tion­ships are rep­res­en­ted in UML in the form of diagrams. UML2 dis­tin­guishes 14 different types of diagrams. These get assigned to one of three different cat­egor­ies: structure diagrams, behaviour diagrams, and in­ter­ac­tion diagrams.

Structure diagrams represent a system and its com­pon­ents in a static state. They il­lus­trate the re­la­tion­ships between in­di­vidu­al elements or between elements and su­per­or­din­ate concepts. An example of this is the class diagram.

Behaviour diagrams represent processes and the behaviour of a system. In contrast to structure diagrams, the sequence of processes and time also plays a role in the rep­res­ent­a­tion. An example of this is activity diagrams.

• In­ter­ac­tion diagrams are a subset of be­ha­vi­or­al diagrams. They are listed sep­ar­ately 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 'life­lines.' These are objects (the smallest in­de­pend­ent building blocks of object-oriented pro­gram­ming) that represent in­di­vidu­al par­ti­cipants 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 chro­no­lo­gic­al 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­ist­ics of a system element. In in­ter­ac­tions, the objects are lifelines.

Requests are made and responses are sent con­stantly 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­res­en­ted 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­plic­a­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­plic­a­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­vidu­al subareas in more detail. With this so-called ap­plic­a­tion scenario, you put the logical con­nec­tions of your ap­plic­a­tion case through their paces.

UML sequence diagrams are also useful when you want to graph com­plic­ated 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­fully completed. This allows you to plan and test your methods before they are im­ple­men­ted 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­plic­a­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­hens­ible. The following spe­cific­a­tions cor­res­pond to the UML standard in version UML 2.5.

The lifeline rep­res­ents 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­ist­ics, one of them must be selected. Al­tern­at­ively, it can also be said that the mul­ti­pli­city is never >1.

A dashed line goes down from the rect­an­gu­lar head. This line rep­res­ents 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 ste­reo­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 ho­ri­zont­al 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 ste­reo­types, the dashed lifeline decreases ver­tic­ally 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­vidu­al steps, taking into account the con­ceiv­able actors and objects.

Bound­ar­ies 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­nic­ate, you need a control element. The control does not ne­ces­sar­ily 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 ste­reo­types com­mu­nic­ate according to four rules – border objects are the interface re­spons­ible for com­mu­nic­a­tion with actors. Actors com­mu­nic­ate ex­clus­ively with borders.
• In contrast, control objects com­mu­nic­ate with other control objects as well as with entities and bound­ar­ies. In return, they do not interact with actors.
• Borders com­mu­nic­ate 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 para­met­ers of a sender (values that result from an operation) as operands. Without output para­met­ers, 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 spe­cific­a­tion. The result of the eval­u­ation specifies the values for the para­met­ers ‘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 stand­ard­ised 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 para­met­ers have the same type. At­trib­utes can be named without re­stric­tions. They represent the name of a context behaviour. This behaviour de­term­ines 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 behaviour, 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­form­a­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 re­cog­nises four types of gates. They differ in the fragments of in­ter­ac­tion with which they are as­so­ci­ated:

• 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­ation 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­nic­a­tion diagrams play a special role. This diagram type is a simple form of the sequence diagram. Com­mu­nic­a­tion diagrams model how lifelines interact. Unlike sequence diagrams, they focus on the system ar­chi­tec­ture and how it de­term­ines 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­nic­a­tion diagram.

The UML notation for com­mu­nic­a­tion diagrams pre­scribes a simple sequence diagram frame: a rectangle with a pentagon­al 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 rect­an­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][Re­pe­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 sim­ul­tan­eous broad­casts. The system sends two messages with the sequence names 1.2.3a and 1.2.3b sim­ul­tan­eously because of the identical integer. The re­pe­ti­tion contains either a re­stric­tion that de­term­ines when the message is sent or a value that de­term­ines how often the message is repeated.

In UML, the guard guards the behaviour 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 acertain behaviour. There are many different elements that can have this kind of guard – actions, at­trib­utes, behaviour, 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 behaviour. Note the re­stric­tion in square brackets on the lifeline above an execution spe­cific­a­tion. Stand­ard­isa­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 behaviour. While the linked in­ter­ac­tion has formal gates, the referring in­ter­ac­tion has the actual gate.

Part-de­com­pos­i­tion is the partial, se­quen­tial de­com­pos­i­tion of a lifeline within an in­ter­ac­tion through another in­ter­ac­tion. Using such a de­com­pos­i­tion, you can separate details from each other and look at in­di­vidu­al sub-functions more closely. When messages enter or leave the dis­as­sembled lifeline, they are con­sidered actual gates. These are connected to the formal gates of the de­com­pos­i­tion action. Gates and para­met­ers of both elements must match. As an in­ter­ac­tion benefit, the partial de­com­pos­i­tion also receives the label 'ref' and is defined by the as­so­ci­ated in­ter­ac­tion.

Start and end mark the event oc­cur­rence spe­cific­a­tions. Ac­tiv­a­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 spe­cific­a­tion rep­res­ents the start or end of an action. The message oc­cur­rence spe­cific­a­tion gives the signal to send and receive a message. Their value therefore always depends on the message or action.

Ac­tiv­a­tion has no separate notation. It exists im­pli­citly at the outer edges of the execution spe­cific­a­tion rectangle. If the execution spe­cific­a­tion performs an atomic action, start and end as­so­ci­ations refer to the same oc­cur­rence spe­cific­a­tion. You can emphasise this with a link line between action and incoming ap­pear­ance spe­cific­a­tion.

While other ap­pear­ance spe­cific­a­tions do not require any notation, mark the message ap­pear­ance spe­cific­a­tion de­struc­tion with a large X. It marks the res­ol­u­tion of an object instance at a specific point on the lifeline. The lifeline ends with it. Sub­or­din­ate instances or per­form­ance spe­cific­a­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 spe­cific­a­tions overlap. For example, if an object sends a message to itself, an execution spe­cific­a­tion sends a message to another instance of this class. Both spe­cific­a­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 rect­angles.

The state variant specifies a re­strict­ive value. If this value is equal to the object state, the track is con­sidered 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 spe­cific­a­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 behaviour 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 behaviour 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­term­ines 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­din­ate fragment.

UML defines 12 in­ter­ac­tion operators

Al­tern­at­ive:

Within the combined fragment with the in­ter­ac­tion operator ‘Al­tern­at­ive,’ a sub­or­din­ate 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­tern­at­ive.’ Use the ab­bre­vi­ation ‘alt’ for the label. You divide the rect­an­gu­lar frame by a ho­ri­zont­al 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­tern­at­ive 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­tern­at­ive. 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­tern­at­ive, 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­term­in­ist­ic. 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 re­pe­ti­tions is exceeded, the loop also loosens, but the process is ter­min­ated as invalid.

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