Study guide
9.1 Sequence Diagram Fundamentals, Lifelines & Execution
OMG Certified Systems Modeling Professional — Model User OCSMP OMG-OCSMP-MU100
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
About the OCSMP Model User (OMG-OCSMP-MU100) Exam
2 Chapter 1: SysML Overview, Diagram Framework & Model Organization
1.1 SysML Overview, MBSE Foundations & Diagram Frame Syntax 1.2 Model Organization, Packages & Viewpoints
3 Chapter 2: Block Definition Diagrams — Blocks & Structural Features
2.1 Block Definitions, Features & Compartments 2.2 ValueTypes, Units, Dimensions & Primitive Types 2.3 Specialization, Generalization & Inheritance Hierarchies
4 Chapter 3: Block Definition Diagrams — Associations, Composition & Multiplicities
3.1 Associations, Composite Aggregation & Reference Associations 3.2 Multiplicities, Reference Properties & Association Ends
5 Chapter 4: Internal Block Diagrams — Internal Structure & Interconnection
4.1 Enclosing Blocks & Part Usages 4.2 Standard Ports, Flow Ports & Interfaces 4.3 Connectors, Item Flows & Flow Specifications
6 Chapter 5: Parametric Diagrams & Constraint Modeling
5.1 Constraint Blocks, Properties & Mathematical Expressions 5.2 Parametric Diagrams & Binding Connectors
7 Chapter 6: Activity Diagrams — Control & Object Flows
6.1 Activity Diagram Anatomy & Control Nodes 6.2 Object Flow, Pins & Activity Parameter Nodes 6.3 Decision, Merge, Fork & Join Execution
8 Chapter 7: Activity Diagrams — Partitions & Action Types
7.1 Activity Partitions (Swimlanes) & Structural Allocation 7.2 Action Types: Call Behavior, Send Signal & Accept Event
9 Chapter 8: State Machine Diagrams — States, Transitions & Events
8.1 State Machine Basics: States, Regions & Orthogonality 8.2 Transitions, Trigger-Guard-Effect Syntax & State Behaviors 8.3 Event Types & Run-to-Completion Semantics
10 Chapter 9: Sequence Diagrams — Message Interactions & Lifelines
9.1 Sequence Diagram Fundamentals, Lifelines & Execution 9.2 Message Types & Interaction References (ref)
11 Chapter 10: Cross-Cutting Constructs — Allocations & Metadata
10.1 The «allocate» Dependency: Semantics & Types 10.2 Allocation Representations: Callouts, Compartments, Partitions & Tables 10.3 Comments, Rationales, Problems, Stereotypes, Frames & Diagram Descriptions
12 Chapter 11: Requirement Diagrams — Requirements Modeling & Traceability
11.1 Requirement Element Definition, ID, Text & Compartments 11.2 Key Relationships: Derive, Satisfy & Verify 11.3 Refine, Trace & Containment Hierarchies
13 Chapter 12: Use Case Diagrams — System Context & Capabilities
12.1 Actors, Use Cases & Subject Boundaries 12.2 Associations, Include, Extend & Generalization
9.1 Sequence Diagram Fundamentals, Lifelines & Execution
Key Takeaways Explain This Topic AI
The Sequence Diagram (sd) is a behavioral diagram under the Behavior pillar that models chronological interactions between participants through ordered message exchanges.
The diagram frame header strictly follows the syntax sd [Interaction] InteractionName [diagramName], where Interaction is the enclosing classifier context.
The two-dimensional coordinate system maps linear progression of time downward along the vertical axis and interacting participants horizontally across lifelines.
A Lifeline consists of a head rectangle representing a participant (lifelineName : ClassifierName or :ClassifierName) and a vertical dashed stem line denoting its temporal existence.
Execution specifications (activation bars) represent periods of active processing or blocked synchronous waiting; a lifeline terminates with a bold X upon destruction.
Last updated: September 2026
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
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).
Interface Protocol Verification: Specifying the strict handshaking, command-acknowledgment protocols, and message sequences required between physical or logical interfaces.
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.
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
kind (Mandatory): The diagram mnemonic for sequence diagrams is strictly sd (lowercase). Modeler mnemonics such as seq , sqd , or interaction are invalid.
[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.
name (Mandatory): The identifier of the specific Interaction element owning the diagram within the model repository (e.g., DeploySolarArrays or ExecuteEmergencyBraking ).
[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:
Lifeline Head: A rectangular box positioned at the top of the interaction space containing the identity and type of the participant.
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:
Named and Typed Role: cmdProcessor : FlightComputer
Identifies a specific named role ( cmdProcessor ) typed by a classifier ( FlightComputer ).
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 .
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:
Stick Figure Notation: A stick-figure icon drawn directly above the dashed lifeline stem, labeled beneath with the actor name.
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
Element Name Graphical Notation Metamodel Construct Semantic Meaning
Diagram Frame Large outer rectangle with heading box Diagram Frame Demarcates the boundary of the enclosing Interaction context.
Heading sd [Interaction] Name [Title] Header String Formal SysML identity showing diagram kind, context metaclass, name, and optional view title.
Lifeline Head Rectangle: role : Classifier Lifeline Represents an individual structural participant playing a role in the interaction.
Lifeline Stem Vertical dashed line Lifeline (Stem) Depicts the continuous temporal existence of the participant, progressing downward.
Actor Lifeline Stick figure icon atop dashed line Actor / Lifeline Represents an external entity (human or external system) interacting with the system.
Execution Specification Thin vertical rectangle on stem ExecutionSpecification Denotes the time window during which the participant is actively executing or blocked.
Nested Execution Offset overlapping vertical rectangles Nested Execution Denotes re-entrant execution, self-calls, or hierarchical operation stacks.
Destruction Occurrence Large bold X at lifeline stem terminus DestructionOccurrence Marks the explicit runtime destruction/deallocation of the participant instance.
Exam Pitfalls & Misconceptions
Concept Correct SysML Rule Common Exam Trap / Distractor
Context Element An sd must always have an [Interaction] context element. Believing an sd can be enclosed by a [Block] or [Activity] .
Lifeline Naming :Classifier indicates an anonymous participant of type Classifier . Claiming that :Classifier represents a private variable or an uninitialized role.
Horizontal Spacing Horizontal spacing of lifelines has no semantic or chronological meaning. Claiming that lifelines positioned farther to the right execute after lifelines on the left.
Vertical Length Vertical length of a lifeline indicates ordinal sequence, not absolute physical duration. Measuring pixel length to deduce precise execution runtimes without duration constraints.
Destruction Marker An X destroys the runtime instance; instances without an X survive beyond the diagram. Believing that every lifeline must terminate with an X or that an X denotes an error state.
Activation Semantics A lifeline can exist and receive messages without an active execution specification bar. Believing an instance is dead or deleted if it lacks an execution bar.