8/28/2021
12

UML Sequence Diagrams are designed so that they can depict a timeline. On the top, you can see the beginning and then the diagram flow descends downwards to mark the sequence of all interactions in the system. These interactions and objects have some symbols and notations that are used to standardize UML Structure Diagrams. Sequence diagrams are a popular dynamic modeling solution in UML because they specifically focus on lifelines, or the processes and objects that live simultaneously, and the messages exchanged between them to perform a function before the lifeline ends.

Uml Sequence Diagram Visio

NotationDescription
Lifeline

Lifeline with name 'data' of class Stock.

A Lifeline is shown using a symbol that consists of a rectangle forming its “head” followed by a vertical line (which may be dashed) that represents the lifetime of the participant.

Anonymous lifeline of class User.

Anonymous lifeline has no name - arbitrary representative of class.

Lifeline 'x' of class X is selected with selector [k].

Selector could be used to specify some lifeline from collection.

Execution

Execution specification shown as grey rectangle on the Service lifeline.

Execution (full name - execution specification, informally called activation) is interaction fragment which represents a period in the participant's lifetime when it is

  • executing a unit of behavior or action within the lifeline,
  • sending a signal to another participant,
  • waiting for a reply message from another participant.

The duration of an execution is represented by two execution occurrences - the start occurrence and the finish occurrence.

Execution is represented as a thin grey or white rectangle on the lifeline.

Execution represented as wider rectangle labeled as action.

Execution can be represented by a wider labeled rectangle, where the label usually identifies the action that was executed.

Overlapping execution specifications on the same lifeline - message to self.

Overlapping executions on the same lifeline are represented by overlapping rectangles.

Overlapping execution specifications on the same lifeline - callback message.


Message

Message is a named element that defines one specific kind of communication between lifelines of an interaction. The message specifies not only the kind of communication, but also the sender and the receiver. Sender and receiver are normally two occurrence specifications (points at the ends of messages).

A message is shown as a line from the sender message end to the receiver message end. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. The send and receive events may both be on the same lifeline. The form of the line or arrowhead reflects properties of the message.

Messages by Action Type

Depending on the type of action that was used to generate the message, message could be one of:

Synchronous Call

Web Client searches Online Bookshop and waits for results.

Synchronous call typically represents operation call - send message and suspend execution while waiting for response. Synchronous Messages are shown with filled arrow head.

Asynchronous Call

Service starts Task and proceeds in parallel without waiting.

Asynchronous call - send message and proceed immediately without waiting for return value. Asynchronous Messages have an open arrow head.

Asynchronous Signal

Asynchronous signal message corresponds to asynchronous send signal action.

Create Message

Online Bookshop creates Account.

Create message is sent to lifeline to create itself. Note, that it is weird but common practice in OOAD to send create message to a nonexisting object to create itself. In real life, create message is sent to some runtime environment.

Create message is shown as a dashed line with open arrowhead (same as reply), and pointing to created lifeline's head.

Delete Message

Online Bookshop terminates Account.

Delete message (called stop in previous versions of UML) is sent to terminate another lifeline. The lifeline usually ends with a cross in the form of an X at the bottom denoting destruction occurrence.

UML 2.3 specification provides neither specific notation for delete message nor a stereotype. Until they provide some notation, we can use custom «destroy» stereotype.

Reply Message

Web Client searches Online Bookshop and waits for results to be returned.

Reply message to an operation call is shown as a dashed line with open arrow head.

Messages by Presence of Events

Depending on whether message send event and receive events are present, message could be one of:

  • complete message
  • unknown message (default)
Lost Message

Web Client sent search message which was lost.

Lost Message is a message where the sending event is known, but there is no receiving event. It is interpreted as if the message never reached its destination. Lost messages are denoted with as a small black circle at the arrow end of the message.

Found Message

Online Bookshop gets search message of unknown origin.

Found Message is a message where the receiving event is known, but there is no (known) sending event. It is interpreted as if the origin of the message is outside the scope of the description. This may for example be noise or other activity that we do not want to describe in detail.

Found messages are denoted with a small black circle at the starting end of the message.

Destruction Occurrence

Account lifeline is terminated

Destruction occurrence is a message occurrence which represents the destruction of the instance described by the lifeline. It may result in the subsequent destruction of other objects that this object owns by composition. No other occurrence may appear below the destruction on a given lifeline.

Complete UML name of the occurrence is destruction occurrence specification. Until UML 2.4 it was called destruction event, and earlier - stop.

The destruction of instance is depicted by a cross in the form of an X at the bottom of a lifeline.

State Invariant

Attribute t of Task should be equal to complete.

A state invariant is an interaction fragment which represents a runtime constraint on the participants of the interaction. It may be used to specify different kinds of constraints, such as values of attributes or variables, internal or external states, etc.

State invariant is usually shown as a constraint in curly braces on the lifeline.

Task should be in Finished state.

It could also be shown as a state symbol representing the equivalent of a constraint that checks the state of the object represented by the lifeline. This could be either the internal state of the classifier behavior of the corresponding classifier or some external state based on a 'black-box' view of the lifeline.

Combined Fragment

Interaction operator could be one of:

  • alt - alternatives
  • opt - option
  • loop - iteration
  • break - break
  • par - parallel
  • strict - strict sequencing
  • seq - weak sequencing
  • critical - critical region
  • ignore - ignore
  • consider - consider
  • assert - assertion
  • neg - negative
Alternatives

Call accept() if balance > 0, call reject() otherwise.

The interaction operator alt means that the combined fragment represents a choice or alternatives of behavior. At most one of the operands will be chosen. The chosen operand must have an explicit or implicit guard expression that evaluates to true at this point in the interaction.

Option

Post comments if there were no errors.

The interaction operator opt means that the combined fragment represents a choice of behavior where either the (sole) operand happens or nothing happens. An option is semantically equivalent to an alternative combined fragment where there is one operand with non-empty content and the second operand is empty.

Loop

Potentially infinite loop.

If loop has no bounds specified, it means potentially infinite loop with zero as lower bound and infinite upper bound.

Loop to execute exactly 10 times.

If only min-int is specified, it means that upper bound is equal to the lower bound, and loop will be executed exactly the specified number of times.

We may guess that as per UML 2.3, the loop is expected to execute minimum 5 times and no more than 10 times. If guard condition [size<0] becomes false loop terminates regardless of the minimum number of iterations specified. (Then why do we need that min number specified?!)

If both bounds are specified, loop will iterate minimum the min-int number of times and at most the max-int number of times.

Besides iteration bounds loop could also have an interaction constraint - a Boolean expression in square brackets. To add to the other confusions, UML 2.3 also calls both of them guards.

UML tries to shuffle the simplest form of for loop and while loop which causes weird UML 2.3 loop semantics on p.488: 'after the minimum number of iterations have executed and the Boolean expression is false the loop will terminate'. This is clarified - with opposite meaning - on the next page as 'the loop will only continue if that specification evaluates to true during execution regardless of the minimum number of iterations specified in the loop.'

Break

Break enclosing loop if y>0.

The interaction operator break represents a breaking or exceptional scenario that is performed instead of the remainder of the enclosing interaction fragment.

Note, UML allows only one level - directly enclosing interaction fragment - to be abandoned. This could become really annoying if double loop or loop with other combined fragments should be broken.

Parallel

Search Google, Bing and Ask in any order, possibly parallel.

The interaction operator par defines potentially parallel execution of behaviors of the operands of the combined fragment. Different operands can be interleaved in any way as long as the ordering imposed by each operand is preserved.

Coregion - search Google, Bing and Ask in any order, possibly parallel.

Parallel combined fragment has a notational shorthand for the common situations where the order of events on one lifeline is insignificant. In a coregion area of a lifeline restricted by horizontal square brackets all directly contained fragments are considered as separate operands of a parallel combined fragment.

Strict Sequencing

Search Google, Bing and Yahoo in the strict sequential order.

The interaction operator strict requires a strict sequencing (order) of the operands on the first level within the combined fragment.

Weak Sequencing

Search Google possibly parallel with Bing and Yahoo, but search Bing before Yahoo.

Weak sequencing seq is defined by the set of traces with these properties:

  • The ordering of occurrence specifications within each of the operands are maintained in the result.
  • Occurrence specifications on different lifelines from different operands may come in any order.
  • Occurrence specifications on the same lifeline from different operands are ordered such that an occurrence specification of the first operand comes before that of the second operand.

Thus weak sequencing seq reduces to a parallel merge when the operands are on disjunct sets of participants. Weak sequencing reduces to strict sequencing when the operands work on only one participant.

Critical Region

Add() or remove() could be called in parallel, but each one should run as a critical region.

The interaction operator critical defines that the combined fragment represents a critical region. A critical region is a region with traces that cannot be interleaved by other occurrence specifications (on the lifelines covered by the region). This means that the region is treated atomically by the enclosing fragment and can't be interleaved, e.g. by parallel operator.

Ignore

Ignore get and set messages, if any.

Interaction operator ignore means that there are some messages that are not shown within this combined fragment. These message types can be considered insignificant and are implicitly ignored if they appear in a corresponding execution.

The list of ignored messages follows the operand enclosed in a pair of curly braces '{' and '}'. Ignore operation is typically combined with other operations such as 'assert ignore {m, s}.'

Consider

Consider only add() or remove() messages, ignore any other.

The interaction operator consider defines which messages should be considered within this combined fragment, meaning that any other message will be ignored.

The list of considered messages follows the operand enclosed in a pair of curly braces '{' and '}'. Consider operation is typically combined with other operations such as 'assert consider {m, s}.'

Assert

Commit() message should occur at this point, following with evaluation of state invariant.

The interaction operator assert means that the combined fragment represents the assertion that the sequences of the assert operand are the only valid continuations (must be satisfied by a correct design of the system). All other continuations result in an invalid trace.

Negative

Should we receive back timeout message, it means the system has failed.

The interaction operator neg describes combined fragment of traces that are defined to be negative (invalid). Negative traces are the traces which occur when the system has failed. All interaction fragments that are different from the negative are considered positive, meaning that they describe traces that are valid and should be possible.

Interaction Use

Web customer and Bookshop use (reference) interaction Checkout.

Interaction use is interaction fragment which allows to use (or call) another interaction. Large and complex sequence diagrams could be simplified with interaction uses. It is also common reusing some interaction between several other interactions.

The interaction use is shown as a combined fragment with operator ref.

Use Login interaction to authenticate user and assign result back to the user attribute of Site Controller.

The syntax of the interaction use of the ref operator is:

interaction-use ::= [ attribute-name '=' ] [ collaboration-use '.' ] interaction-name [ io-arguments ] [ ':' return-value ]
io-arguments ::= '(' io-argument [ ',' io-argument ]* ')'
io-argument ::= in-argument 'out' out-argument

  • UML Tutorial
  • UML 2.0 Overview
  • UML Useful Resources
  • Utilities

EdrawMax is an easiest all-in-one diagramming tool, you can create UML sequence diagrams and any other type diagrams with ease! With substantial UML sequence diagram symbols and cliparts, making UML sequence diagrams could be as simple as possible. Also, it supports to export your work in multiple formats and share your work with others. In this step-by-step tutorial, we'll show you how to make a UML sequence diagram using Lucidchart. Sequence diagrams are a type of Unified Modeling Language.

  • Selected Reading

In the previous chapters, we have discussed about the building blocks and other necessary elements of UML. Now we need to understand where to use those elements. Nike snkrs r.

The elements are like components which can be associated in different ways to make a complete UML picture, which is known as diagram. Thus, it is very important to understand the different diagrams to implement the knowledge in real-life systems.

Any complex system is best understood by making some kind of diagrams or pictures. These diagrams have a better impact on our understanding. If we look around, we will realize that the diagrams are not a new concept but it is used widely in different forms in different industries.

We prepare UML diagrams to understand the system in a better and simple way. A single diagram is not enough to cover all the aspects of the system. UML defines various kinds of diagrams to cover most of the aspects of a system.

You can also create your own set of diagrams to meet your requirements. Diagrams are generally made in an incremental and iterative way.

There are two broad categories of diagrams and they are again divided into subcategories −

  • Structural Diagrams

  • Behavioral Diagrams

Structural Diagrams

The structural diagrams represent the static aspect of the system. These static aspects represent those parts of a diagram, which forms the main structure and are therefore stable.

These static parts are represented by classes, interfaces, objects, components, and nodes. The four structural diagrams are −

  • Class diagram
  • Object diagram
  • Component diagram
  • Deployment diagram

Class Diagram

Class diagrams are the most common diagrams used in UML. Class diagram consists of classes, interfaces, associations, and collaboration. Class diagrams basically represent the object-oriented view of a system, which is static in nature.

Active class is used in a class diagram to represent the concurrency of the system.

Diagram

Class diagram represents the object orientation of a system. Hence, it is generally used for development purpose. This is the most widely used diagram at the time of system construction.

Object Diagram

Object diagrams can be described as an instance of class diagram. Thus, these diagrams are more close to real-life scenarios where we implement a system.

Object diagrams are a set of objects and their relationship is just like class diagrams. Theyalso represent the static view of the system.

The usage of object diagrams is similar to class diagrams but they are used to build prototype of a system from a practical perspective.

Component Diagram

Web

Component diagrams represent a set of components and their relationships. These components consist of classes, interfaces, or collaborations. Component diagrams represent the implementation view of a system.

During the design phase, software artifacts (classes, interfaces, etc.) of a system are arranged in different groups depending upon their relationship. Now, these groups are known as components.

Finally, it can be said component diagrams are used to visualize the implementation.

Deployment Diagram

Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities where the components are deployed.

Deployment diagrams are used for visualizing the deployment view of a system. This is generally used by the deployment team.

Note − If the above descriptions and usages are observed carefully then it is very clear thatall the diagrams have some relationship with one another. Component diagrams are dependent upon the classes, interfaces, etc. which are part of class/object diagram. Again, the deployment diagram is dependent upon the components, which are used to makecomponent diagrams.

Behavioral Diagrams

Any system can have two aspects, static and dynamic. So, a model is considered ascomplete when both the aspects are fully covered.

Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be further described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams −

  • Use case diagram
  • Sequence diagram
  • Collaboration diagram
  • Statechart diagram
  • Activity diagram

Use Case Diagram

Use case diagrams are a set of use cases, actors, and their relationships. They represent the use case view of a system.

A use case represents a particular functionality of a system. Hence, use case diagram is used to describe the relationships among the functionalities and their internal/external controllers. These controllers are known as actors.

Sequence Diagram

A sequence diagram is an interaction diagram. From the name, it is clear that the diagram deals with some sequences, which are the sequence of messages flowing from one object to another.

Sequence

Interaction among the components of a system is very important from implementation and execution perspective. Sequence diagram is used to visualize the sequence of calls in a system to perform a specific functionality.

Collaboration Diagram

Collaboration diagram is another form of interaction diagram. It represents the structuralorganization of a system and the messages sent/received. Structural organization consists of objects and links.

The purpose of collaboration diagram is similar to sequence diagram. However, the specific purpose of collaboration diagram is to visualize the organization of objects and their interaction.

Statechart Diagram

Any real-time system is expected to be reacted by some kind of internal/external events. These events are responsible for state change of the system.

Statechart diagram is used to represent the event driven state change of a system. It basically describes the state change of a class, interface, etc.

Diagram sequence uml

State chart diagram is used to visualize the reaction of a system by internal/external factors.

Activity Diagram

Activity diagram describes the flow of control in a system. It consists of activities and links. The flow can be sequential, concurrent, or branched.

Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared to capture the entire flow in a system.

Uml Sequence Diagram Example

Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have an idea of how the system will work when executed.

Diagram Sequence Uml Generator

Diagram sequence uml example

Note − Dynamic nature of a system is very difficult to capture. UML has provided featuresto capture the dynamics of a system from different angles. Sequence diagrams and collaboration diagrams are isomorphic, hence they can be converted from one another without losing any information. This is also true for Statechart and activity diagram.