Sequence Diagram Uml Notation

  • UML Tutorial

UML Sequence Diagrams are interaction diagrams that detail how operations are carried out. They capture the interaction between objects in the context of a collaboration. Sequence Diagrams are time focus and they show the order of the interaction visually by using the vertical axis of the diagram to represent time what messages are sent and when. See full list on uml-diagrams.org. Sequence diagram notation - Quiz. Each question is worth one point. Select the best answer or answers for each question. The scope of problem analysis requires the definition of Please select the best answer. The operations and attributes for each resource: B.

  • UML 2.0 Overview

UML Notation Tutorial: Symbol With Examples

  • UML Useful Resources
  • Utilities
  • Selected Reading

UML is popular for its diagrammatic notations. We all know that UML is for visualizing, specifying, constructing and documenting the components of software and non-software systems. Hence, visualization is the most important part which needs to be understood and remembered.

UML notations are the most important elements in modeling. Efficient and appropriate use of notations is very important for making a complete and meaningful model. The model is useless, unless its purpose is depicted properly.

Hence, learning notations should be emphasized from the very beginning. Different notations are available for things and relationships. UML diagrams are made using the notations of things and relationships. Extensibility is another important feature whichmakes UML more powerful and flexible.

The chapter describes basic UML notations in detail. This is just an extension to the UML building block section discussed in Chapter Two.


Structural Things

Graphical notations used in structural things are most widely used in UML. These are considered as the nouns of UML models. Following are the list of structural things.

  • Classes
  • Object
  • Interface
  • Collaboration
  • Use case
  • Active classes
  • Components
  • Nodes

Class Notation

UML class is represented by the following figure. The diagram is divided into four parts.

  • The top section is used to name the class.
  • The second one is used to show the attributes of the class.
  • The third section is used to describe the operations performed by the class.
  • The fourth section is optional to show any additional components.

Classes are used to represent objects. Objects can be anything having properties and responsibility.

Object Notation

The object is represented in the same way as the class. The only difference is the name which is underlined as shown in the following figure.

As the object is an actual implementation of a class, which is known as the instance of a class. Hence, it has the same usage as the class.

Interface Notation

Interface is represented by a circle as shown in the following figure. It has a name which is generally written below the circle.

Interface is used to describe the functionality without implementation. Interface is just likea template where you define different functions, not the implementation. When a class implements the interface, it also implements the functionality as per requirement.

Collaboration Notation

Collaboration is represented by a dotted eclipse as shown in the following figure. It has a name written inside the eclipse.

Collaboration represents responsibilities. Generally, responsibilities are in a group.

Use Case Notation

Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities.

Use case is used to capture high level functionalities of a system.

Actor Notation

An actor can be defined as some internal or external entity that interacts with the system.

An actor is used in a use case diagram to describe the internal or external entities.

Initial State Notation

Initial state is defined to show the start of a process. This notation is used in almost all diagrams.

The usage of Initial State Notation is to show the starting point of a process.

Final State Notation

Final state is used to show the end of a process. This notation is also used in almost all diagrams to describe the end.

The usage of Final State Notation is to show the termination point of a process.

Active Class Notation


Active class looks similar to a class with a solid border. Active class is generally used to describe the concurrent behavior of a system.

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

Component Notation

A component in UML is shown in the following figure with a name inside. Additional elements can be added wherever required.

Component is used to represent any part of a system for which UML diagrams are made.

Node Notation

A node in UML is represented by a square box as shown in the following figure with a name. A node represents the physical component of the system.

Node is used to represent the physical part of a system such as the server, network, etc.

Behavioral Things

Dynamic parts are one of the most important elements in UML. UML has a set of powerfulfeatures to represent the dynamic part of software and non-software systems. These features include interactions and state machines.

Interactions can be of two types −

  • Sequential (Represented by sequence diagram)
  • Collaborative (Represented by collaboration diagram)

Interaction Notation

Interaction is basically a message exchange between two UML components. The following diagram represents different notations used in an interaction.

Interaction is used to represent the communication among the components of a system.

State Machine Notation

State machine describes the different states of a component in its life cycle. The notations are described in the following diagram.

State machine is used to describe different states of a system component. The state can be active, idle, or any other depending upon the situation.

Grouping Things

Organizing the UML models is one of the most important aspects of the design. In UML, there is only one element available for grouping and that is package.

Package Notation

Package notation is shown in the following figure and is used to wrap the components of a system.

Annotational Things

In any diagram, explanation of different elements and their functionalities are very important. Hence, UML has notes notation to support this requirement.

Note Notation

This notation is shown in the following figure. These notations are used to provide necessary information of a system.


A model is not complete unless the relationships between elements are described properly.The Relationship gives a proper meaning to a UML model. Following are the different typesof relationships available in UML.

  • Dependency
  • Association
  • Generalization
  • Extensibility

Dependency Notation

Dependency is an important aspect in UML elements. It describes the dependent elements and the direction of dependency.

Dependency is represented by a dotted arrow as shown in the following figure. The arrow head represents the independent element and the other end represents the dependent element.

Dependency is used to represent the dependency between two elements of a system

Association Notation

Association describes how the elements in a UML diagram are associated. In simple words, it describes how many elements are taking part in an interaction.

Association is represented by a dotted line with (without) arrows on both sides. The two ends represent two associated elements as shown in the following figure. The multiplicity is also mentioned at the ends (1, *, etc.) to show how many objects are associated.

Association is used to represent the relationship between two elements of a system.

Generalization Notation

Generalization describes the inheritance relationship of the object-oriented world. It is aparent and child relationship.

Sequence Diagram Uml Represent


Generalization is represented by an arrow with a hollow arrow head as shown in the following figure. One end represents the parent element and the other end represents the child element.

Generalization is used to describe parent-child relationship of two elements of a system.

What Is Sequence Diagram? - Visual Paradigm For UML

Extensibility Notation

All the languages (programming or modeling) have some mechanism to extend its capabilities such as syntax, semantics, etc. UML also has the following mechanisms to provide extensibility features.

  • Stereotypes (Represents new elements)
  • Tagged values (Represents new attributes)
  • Constraints (Represents the boundaries)

Extensibility notations are used to enhance the power of the language. It is basically additional elements used to represent some extra behavior of the system. These extra behaviors are not covered by the standard available notations.


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 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 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

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.


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.


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 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.


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 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 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}.'


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.


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