Cradle from 3SL, the complete Model Based Systems Engineering Toolsuite, specialising in requirements management, requirements capture, model based systems engineering and for systems engineering software, support and consultancy, the logical choice: Cradle from 3SL.
login Register forgot password or username?

Welcome to 3SL Reference Section

Sequence Diagram Sequence Diagram (SQD)

Sequence Diagram (SQD)

Each Use Case Diagram (UCD) use case may be expanded into a Sequence Diagram (SQD) and/or a Collaboration Diagram (COD). A use case with multiple scenarios will be decomposed into a lower-level UCD with a set of use cases, one for each scenario, and therefore a set of SQDs. An SQD provides a time-sequenced view of the interaction between actors and class instances in a scenario graphically distributing the messages that are exchanged along timelines.

A use case is a class of interactions between actors in a UML model’s environment and the system. Each use case may be complex or compound and may require decomposition into more elemental, simpler, use cases. A use case is, effectively, a set of events sequenced in time, termed an event flow. There may be several event flows for a use case, describing, for example, the normal or most common sequence of events, alternate sequences of events, and exceptional sequences of events that will usually correspond to error conditions. Each path through these multiple event flows is called a scenario.

Scenarios are described by either an SQD or a COD, or both. Both of the diagram styles show the details of the interaction of the environment (the external actors shown in the UCD) with the appropriate part(s) of the system (classes and their object instances), in terms of a time sequenced exchange of messages. The time sequencing is made graphically explicit by the SQD, whereas the COD focuses on clearly showing the totality of message transfers between all of the actors and classes/object instances involved in the scenario.

Except for these graphical differences, the SQD and COD convey similar information.

An SQD identifies the actors and classes (or instances of classes: objects) involved in the interaction, with a timeline (called a lifeline) for each. Between the lifelines, the SQD shows the messages sent between the participants in the interaction. Initially, these messages are expressed in free format text. Ultimately (and potentially only in the design model instances of the SQDs), the messages are rigorously specified in terms of message numbers, optional precursor conditions (termed guards), a message name and optional parameters. In this form, the message names correspond to invocations of correspondingly named operations of the recipient class.

The classes and objects shown in an SQD are defined by class specifications whose name and number match the name of the class. No other symbol has a definition, the data content of a class must consist of basic data types, there will never be a set of data definitions defining data structure.

When naming classes and objects in the SQD the naming convention is as follows:

instance-name : class-name

When viewing the definition of an object instance named in this way, Cradle ignores the instance name and the : class name separator character, and uses only the class name to identify the class specification.

It is possible to navigate directly to a class’s definition from an SQD, and thereafter to the Class Diagram (CD) in which the class appears.

By being defined in class specifications, the classes in an SQD will be cross referenceable.

If the user omits the ( and ) characters from messages (which contain the arguments being passed in the message to the operation in the recipient class), then Cradle will interpret the message name as being the name of a data definition. This approach allows SQDs to be used as pure data protocol diagrams, which show time sequenced data exchanges.

When used in this way, the lifelines are not considered to relate to actors or object instances, but instead to relate to parts of the system architecture.

SQDs are not hierarchical. Their connectivity is:

Diagram showing the connectivity of a Sequence Diagram

SQDs are available in models in both the Essential and Implementation Domains.

Data Protocol Diagrams

The messages in Sequence Diagrams (SQDs) are normally calls to an operation in a destination class or object instance.

As a non-UML extension to the behaviour of SQDs, if the parameter list of a message is omitted, then the message symbol will have a data definition. This allows SQDs to be used as pure data protocol diagrams.

To omit the parameter list, do not use a () combination in the message name.

Numbering of SQDs

Each use case may be expanded into an SQD and/or COD to define its scenario. A use case with multiple scenarios will be decomposed into a lower-level UCD with a set of use cases, one for each scenario. An SQD has the same name and number as its parent use case. The specifications for object instances and actors are named and numbered from the class or actor name.


An example SQD is:

Screenshot of a Sequence Diagram

The symbols available in SQDs are:

Symbol Name Description Definition Expansion


Comment Makes a note anywhere in the diagram. Are always surrounded by * characters. None None

External Actor

External Actor A part of the environment that stimulates the system or is stimulated by it. Environment None

Object Instance

Object Instance An object that is created, performs actions, and/or is destroyed during the lifeline. Class

Lifeline Node

Lifeline Node A connection point in a lifeline. None None

Object Deletion

Object Deletion Indicates the deletion of an object. None None

Lifeline Script Text

Lifeline Script Text A label for the actions being performed over the time of the lifeline, which is attached to a particular segment of the lifeline. None None

Send Message

Send Message Connects into object lifelines and acts as the source of any type of message. Message

Object Lifeline

Object Lifeline A representation of the existence of an object over a particular period of time. None None


Activation The period during which an object is performing an action either directly or through a subordinate procedure. The Activation time may include time when it has control information on a stack, but during which control resides in something that is called. Also known as the Focus of Control. None None

Computing Activation

The period during which an object activation is actually computing (i.e. it is the top item on the stack). None None

Synchronous Message

An instantaneous communication between objects that conveys information, with the expectation that an action will be initiated as a result. None None

Flow of Control Message

Flow of Control
A message that passes the focus of control from one object to another. None None

Asynchronous Message

A communication between objects, taking a measurable time, that conveys information, with the expectation that an action will be initiated as a result. None None


Picture Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol. None None