9.1 Sequence Diagram Fundamentals, Lifelines & Execution

9.1 Sequence Diagram Fundamentals, Lifelines & Execution

Quick Reference: SysML Sequence Diagrams (sd) belong to the Behavior Pillar and capture time-ordered message exchanges between structural roles or actors. The diagram header strictly adheres to sd [Interaction] InteractionName [diagramName]. Time flows strictly downward along the vertical axis, while participants occupy distinct horizontal lifelines. An execution specification (activation bar) denotes active computation, and a bold X marks instance destruction.

---

The Role of Sequence Diagrams in MBSE

In Model-Based Systems Engineering (MBSE), modeling system behavior requires multiple specialized perspectives. While Activity Diagrams (act) focus on control flow, data transformations, and procedural step-by-step algorithms, and State Machine Diagrams (stm) model the life cycles, discrete operating modes, and reactive state transitions of a single structural block, Sequence Diagrams (sd) focus on communication interactions among collaborating elements over time.

A Sequence Diagram illustrates an Interaction—a behavior defined by the sequential exchange of messages between individual parts, ports, subsystems, or external actors. It emphasizes the sequence and timing of messages sent and received rather than the internal algorithms executed inside any single component.

Primary Engineering Uses

1. Use Case Realization: Detailing how collaborating system components interact to achieve the operational goal of a high-level Use Case (e.g., executing a nominal startup sequence or handling an emergency shutoff).
2. Interface Protocol Verification: Specifying the strict handshaking, command-acknowledgment protocols, and message sequences required between physical or logical interfaces.
3. Scenario Analysis & Test Case Derivation: Serving as direct visual baselines for end-to-end integration test procedures, validating nominal, off-nominal, and failure-recovery execution paths.
4. Timing and Synchronization Allocation: Allocating communication responsibilities across distributed computing hardware, sensors, and actuators.

---

Diagram Frame Header Syntax and Context Element

Like all SysML diagrams, a Sequence Diagram is enclosed within a rectangular outer border featuring a standard heading in the upper-left corner:

kind [type] name [diagramName]

The Mandatory Heading Grammar

1. kind (Mandatory): The diagram mnemonic for sequence diagrams is strictly sd (lowercase). Modeler mnemonics such as seq, sqd, or interaction are invalid.
2. [type] (shown to remove ambiguity): A sequence diagram frame designates an interaction, so the type is [Interaction]. In the SysML/UML metamodel, an Interaction is a specialized Behavior that owns the lifelines, messages, gates, and interaction fragments depicted on the canvas.
3. name (Mandatory): The identifier of the specific Interaction element owning the diagram within the model repository (e.g., DeploySolarArrays or ExecuteEmergencyBraking).
4. [diagramName] (Optional): A human-readable title enclosed in brackets that provides descriptive context for the specific view (e.g., [Nominal Deployment Sequence]).

Canonical Header Examples

• sd [Interaction] PowerUpAvionics [Nominal Cold Start]

  • Kind: sd
  • Metaclass: [Interaction]
  • Context Element: PowerUpAvionics
  • Diagram Title: Nominal Cold Start

• sd [Interaction] TransmitTelemetry [Ground Station Pass]

  • Kind: sd
  • Metaclass: [Interaction]
  • Context Element: TransmitTelemetry
  • Diagram Title: Ground Station Pass

Exam Trap: On the certification exam, question distractors frequently substitute [Block], [Activity], or [Package] into the sequence diagram header (such as sd [Block] FlightComputer). In standard SysML, the context element metaclass for an sd frame is always [Interaction].

---

The Two-Dimensional Interaction Coordinate Space

A sequence diagram organizes interaction dynamics across a two-dimensional grid:

The Horizontal Dimension: Interacting Participants

• The horizontal axis displays the individual participants involved in the interaction, represented by Lifelines.
• The horizontal placement or ordering of lifelines carries no semantic meaning. Arranging a sensor on the left and an actuator on the right does not alter the execution semantics of the interaction. However, engineering convention typically places the primary triggering entity (such as a human operator or external actor) on the far left, with supporting subsystems arranged progressively to the right.

The Vertical Dimension: Linear Progression of Time

• The vertical axis represents the linear, monotonic progression of time, flowing strictly from top to bottom.
• Events positioned higher on a lifeline occur before events positioned lower down on that same lifeline.
• Partial Ordering Semantics: SysML sequence diagrams adhere to partial ordering rules. Along a single lifeline, all event occurrences (send events, receive events, execution starts, and execution finishes) are strictly totally ordered from top to bottom. However, between different lifelines, event ordering is established only by message transmission and reception—the sending event on one lifeline must precede the corresponding receive event on another lifeline. Without a message link, relative timing between two different lifelines cannot be assumed unless explicit timing constraints are declared.
• Ordinal vs. Metric Time: By default, sequence diagrams depict ordinal time (relative chronological sequence). The vertical distance between two message arrows does not imply a specific physical duration (such as 10 milliseconds or 5 seconds) unless explicit duration constraints (e.g., {t..t+20ms}) or timing marks are annotated on the diagram.

---

Lifeline Anatomy and Classifier Typing

A Lifeline represents an individual participant in an interaction, corresponding to a structural feature—such as a part property, a reference property, a boundary port, or an external actor—acting in a specific role.

Graphical Components of a Lifeline

A lifeline consists of two distinct visual components:

1. Lifeline Head: A rectangular box positioned at the top of the interaction space containing the identity and type of the participant.
2. Lifeline Stem: A dashed vertical line extending downward from the center bottom of the head rectangle across the interaction canvas, representing the participant's existence over time.

Lifeline Naming Syntax

The text string inside the lifeline head adheres to the standard UML/SysML instance-specification syntax:

lifelineName [ [multiplicity] ] : ClassifierName

SysML supports three common permutations of this syntax:

1. Named and Typed Role: cmdProcessor : FlightComputer
   • Identifies a specific named role (cmdProcessor) typed by a classifier (FlightComputer).
2. Anonymous Typed Role: :TelemetryReceiver
   • The role name is omitted, but the colon (:) is preserved. This indicates an anonymous participant whose behavior is governed by the classifier TelemetryReceiver.
3. Named Untyped Role: powerBus
   • The role name is specified without a colon or classifier type, indicating that the participant's typing is left unspecified or inherited implicitly.

+-------------------------+       +-------------------------+       +-------------------------+
|  navComputer : NavCore  |       |   :TelemetryReceiver    |       |        powerBus         |
+-------------------------+       +-------------------------+       +-------------------------+
             |                                 |                                 |
             |                                 |                                 |
             :                                 :                                 :

Actors on Sequence Diagrams

When a participant is an external human user, external system, or operational role defined as an Actor, the lifeline head may be rendered in either of two standard notations:

1. Stick Figure Notation: A stick-figure icon drawn directly above the dashed lifeline stem, labeled beneath with the actor name.
2. Stereotyped Rectangle: A standard lifeline head rectangle containing the stereotype «actor» above the actor name (e.g., «actor» pilot : Pilot).

Both notations are semantically identical under SysML v1.2.

---

Execution Specifications (Activation Bars)

An Execution Specification (historically termed an activation bar or execution occurrence) represents the period of time during which a participant is actively executing an internal behavior, computing an action, or suspended while waiting for a synchronous operation to complete.

Graphical Syntax & Rules

• Notation: A thin, vertical rectangular bar overlaid directly on top of the dashed lifeline stem.
• Initiation: The top edge of an execution specification is typically anchored to the receipt of an incoming message (such as a synchronous operation call or an asynchronous signal).
• Termination: The bottom edge coincides with the completion of the behavior, the dispatch of a reply message, or a local termination event.
• Width: The horizontal width of the activation bar has no semantic significance; it is purely graphical.

Nested Activations (Re-entrancy and Self-Calls)

When an active component calls a local operation on itself (a self-call or internal message), or when it receives an incoming interrupt while already active, a second execution specification is drawn partially overlaid and offset slightly to the right of the primary execution bar. This visual nesting clearly denotes recursive execution, re-entrancy, or layered execution scopes.

+-------------------------+
|   ctrl : Controller     |
+-------------------------+
             |
             |  <-- Inactive / Idle
             |
          +--+--+
          |  |  |  <-- Primary Execution Specification
          |  |  |
          |  +--+--+  <-- Nested Activation (Self-Call)
          |  |  |  |
          |  +--+--+
          |  |  |
          +--+--+
             |
             |  <-- Inactive / Idle

---

Lifeline Destruction Occurrences

In dynamic system architectures, structural instances can be created and destroyed at runtime during an interaction.

The Destruction Marker (Bold X)

• Notation: A large, prominent bold X placed at the terminal bottom point of a lifeline's dashed stem.
• Semantics: Indicates the destruction of the instance. UML 2.3, the base of SysML 1.2, calls the X a stop marking a destruction event; later UML versions call it a destruction occurrence. At the instant marked by the X, the runtime instance represented by the lifeline is destroyed, its allocated resources or memory are freed, and its physical/logical lifecycle terminates.
• Strict Rule: Once a lifeline has terminated with a destruction X, no further event occurrences, messages, or execution specifications may exist on that lifeline below the X.

Destruction vs. Out-of-Scope Lifelines

• Terminating with X: The instance is explicitly destroyed at runtime by a destruction event or delete message.
• Ending Without X: The dashed stem line simply terminates at the bottom margin of the diagram. This signifies that the instance continues to exist in the system; it has merely ceased participating in the specific scenario captured by this view.

---

Summary of Sequence Diagram Graphical Elements

---

Exam Pitfalls & Misconceptions