SysML: Modeling Scenarios with Sequence Diagram

A sequence diagram is a kind of behavior diagram that presents a dynamic view of the use case, a requirement, or a system, a view that expresses sequences of behaviors and event occurrences over time. You can use elements called lifelines to model the participants in system behavior and then use messages between lifelines to model interactions among those participants. Interaction uses to let you model behavioral decomposition among a set of interactions. You can also specify time constraints and duration constraints on interactions.

SysML includes the Sequence Diagram only and excludes the Interaction Overview Diagram and Communication Diagram, which were considered to offer significantly overlapping functionality without adding the significant capability for system modeling applications. The Timing Diagram is also excluded due to concerns about its maturity and suitability for systems engineering needs

Why Scenario Modeling with Sequence Diagram?

A use case is a collection of interactions between external actors and a system. A use case is “the specification of a sequence of actions, including variants, that a system (or entity) can perform, interacting with actors of the system.

A scenario is one path or flows through a use case that describes a sequence of events that occurs during one particular execution of a system which is often represented by a sequence diagram.

User requirements are captured as use cases that are refined into scenarios. A use case is a collection of interactions between external actors and a system. Typically each use case includes a primary scenario (or main course of events) and zero or more secondary scenarios that are alternative courses of events to the primary scenario. It is often useful to visualize use case scenarios for the following reasons:

  • Understanding the requirements in more detail by creating a model of the end-users problems (Modelling the Problem)
  • Typically, however, after defining an initial System Architecture and exploring the capabilities of the system (captured as Use Cases) you’ll want to see how the capabilities are delivered by the components within the System Architecture (Modelling the Solution).
  • high-level interactions between the user of the system and the system, between the system and other systems, or between subsystems (sometimes known as system sequence diagrams)

Sequence Diagrams at a Glance

Sequence Diagram is an interaction diagram that details how operations are carried out — what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence.

Sequence Diagrams show elements as they interact over time and they are organized according to object (horizontally) and time (vertically):

Object (lifeline) Dimension

An object lifeline represents the existence of an object over some time. Objects that exist throughout an interaction should appear at the top of the object dimension with their lifelines drawn parallel to the Time dimension. Objects that are created and destroyed dynamically (transient objects) have object lifelines that begin and end with a receipt of a message.

  • The horizontal axis shows the elements that are involved in the interaction
  • Conventionally, the objects involved in the operation are listed from left to right according to when they take part in the message sequence. However, the elements on the horizontal axis may appear in any order

Time Dimension

  • The vertical axis represents time proceedings (or progressing) down the page.

The Example below is a generic sequence diagram showing the sequence of messages interacted between the objects with frames and message constraints.

Sequence Diagram example

Flow of Control and Messages

A focus of control, also known as the Activation bar, illustrates the period an object is acting. Actions can either be performed directly by an object or through a subordinate object to which it has sent messages.

Sequence Diagram notation: Flow of control and messages

Messages specify communication from one object to another, with an expectation that an activity will be performed by the recipient object.

Messages depict the invocation of operations are shown horizontally. They are drawn from the sender to the receiver. Ordering is indicated by the vertical position, with the first message shown at the top of the diagram, and the last message shown at the bottom. As a result, sequence numbers are optional.

The line type and arrowhead type indicates the type of message is used:

  • An asynchronous message (typically an operation call) is shown as a solid line with a filled arrowhead. It is a regular message call used for normal communication between the sender and the receiver.
    Sequence Diagram notation: Synchronous message
  • return message uses a dashed line with an open arrowhead.
    Sequence Diagram notation: Return message
  • An asynchronous message has a solid line with an open arrowhead. A signal is an asynchronous message that has no reply.
    Sequence Diagram notation: Asynchronous message

Creation and Destruction Messages

Participants do not necessarily live for the entire duration of a sequence diagram’s interaction. Participants can be created and destroyed according to the messages that are being passed.

constructor message creates its receiver. The sender that already exists at the start of the interaction is placed at the top of the diagram. Targets that are created during the interaction by a constructor call are automatically placed further down the diagram.

Sequence Diagram notation: Constructor message

destructor message destroys its receiver. There are other ways to indicate that a target is destroyed during an interaction. Only when a target’s destruction is set to ‘after destructor’ do you have to use a destructor.

Sequence Diagram notation: Destructor message

Non-instantaneous message

Messages are often considered to be instantaneous, thus, the time it takes to arrive at the receiver is negligible. The messages are drawn as a horizontal arrow. To indicate that it takes a certain while before the receiver receives a message, a slanted arrow is used.

Sequence Diagram notation: Non-instantaneous message

Sequence Diagram Message Example

The sequence diagram example below illustrates how you can represent objects, object lifelines, the focus of control, links, and messages in the context of a Sequence diagram.

Sequence Diagram notation: Message example

Sequence Frames and Fragments

Diagram frames explicitly define the boundary of a diagram whereas combined fragment frames encompass portions of a diagram or provide references to other diagrams or method definitions.


A Sequence Frame Notation is a graphical notation used in a UML Sequence Diagram to provide a boundary to enclose all messages and lifelines of a communication sequence.

A Sequence Frame Notation is drawn as a large rectangle with a pentagon at the top left corner. “sd” followed by the sequence name are written in the pentagon.

For example, a communication message interchanges between a user, a Web browser and a Web server to perform a user login process can be described as a communication message sequence with sequence frame.

Sequence Diagram notation: Frame

Sequence Diagram Fragments

You can use sequence Fragments to add additional semantics to a sequence diagram.

  • UML 2.0 introduces sequence (or interaction) fragments. Sequence fragments make it easier to create and maintain accurate sequence diagrams
  • A sequence fragment is represented as a box, called a combined fragment, which encloses a portion of the interactions within a sequence diagram
  • The fragment operator (in the top left corner) indicates the type of fragment
  • Fragment types: ref, assert, loop, break, alt, opt, neg

Modeling Simple Logic and Algorithms

A common issue with sequence diagrams is how to show looping and conditional behavior. The first thing to point out is that this isn’t what sequence diagrams are good at. If you want to show control structures like this, you are better off with an activity diagram or indeed with code itself. Treat sequence diagrams as a visualization of how objects interact rather than as a way of modeling control logic.

If you still prefer to model this in a sequence diagram, here’s the notation to use. Both loop and conditional use interaction frames, which are ways of marking off a piece of a sequence diagram. The sequence diagram example below shows a simple algorithm based on the following pseudocode:

Sequence Diagram notation: Fragment

alt Alternative multiple fragments: only the one whose condition is true will execute.
opt Optional: the fragment executes only if the supplied condition is true. Equivalent to an alt only with one trace.
par Parallel: each fragment is run in parallel.
loop Loop: the fragment may execute multiple times, and the guard indicates the basis of iteration.
region Critical region: the fragment can have only one thread executing it at once.
neg Negative: the fragment shows an invalid interaction.
ref Reference: refers to an interaction defined in another diagram. The frame is drawn to cover the lifelines involved in the interaction. You can define parameters and return value.
sd Sequence diagram: used to surround an entire sequence diagram.

Sequence Diagram notation: Different fragment types

Sequence Fragment Example- Place Order Scenario

A member of a ship who would like to place an order online. The item ordered will be sent to the member either send by courier or by ordinary mail depending on the member status (VIP, Ordinary membership). Optionally, the shop will send the member a confirmation notice if the member opted for the notification option in the order.

Sequence Diagram Place Order example

Turn every software project into a successful one.

We use cookies to offer you a better experience. By visiting our website, you agree to the use of cookies as described in our Cookie Policy.