Study guide
10.3 Comments, Rationales, Problems, Stereotypes, Frames & Diagram Descriptions
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
10.3 Comments, Rationales, Problems, Stereotypes, Frames & Diagram Descriptions
Key Takeaways Explain This Topic AI
SysML annotations provide structured mechanisms for attaching explanatory narrative, engineering trade justifications, and defect tracking to model elements using dog-eared note boxes connected by dashed anchor lines without arrowheads.
SysML standardizes two specialized comment stereotypes: «rationale» (capturing the justification, trade study, or rationale behind an architectural decision) and «problem» (recording an unresolved issue, anomaly, or modeling deficiency).
Stereotypes extend UML and SysML metaclasses to introduce domain-specific vocabulary and metadata, rendered using guillemets («stereotypeName») and carrying custom properties called tagged values.
Every SysML diagram has a frame whose heading reads diagramKind [modelElementType] modelElementName [diagramName]; its border can hold ports, activity parameters, gates, or constraint parameters.
A diagram description is a comment attached to the frame that records version, description, completion status, references, and any user-defined fields.
Last updated: September 2026
10.3 Comments, Rationales, Problems, Stereotypes, Frames & Diagram Descriptions
Quick Reference: SysML enriches systems models through cross-cutting metadata and structural framing constructs. Comments use dog-eared note boxes connected by dashed lines without arrowheads (anchor lines). SysML standardizes two specialized comment stereotypes: «rationale» (capturing architectural justification) and «problem» (flagging unresolved defects or design issues). Stereotypes extend UML metaclasses with domain-specific semantics and tagged values . Every SysML diagram is bounded by a Diagram Frame with a standardized header ( kind [type] name [diagramName] ), whose perimeter can host boundary ports, parameter nodes, and interaction gates.
Informational Annotations: Comments and Note Anchors
In systems engineering, visual diagrams must convey both formal structural/behavioral logic and the contextual rationale that led to specific engineering decisions. In SysML, informal or human-readable textual descriptions are incorporated using Comments .
The Comment Element
Graphical Notation: A rectangle with its upper-right corner folded over (a dog-eared note box ).
Content: Unstructured text, rich prose, hyperlinks, or mathematical expressions describing an element or diagram.
Connection to Model Elements (The Anchor): A comment attaches to one or more annotated model elements using a dashed line without an arrowhead .
Exam Trap: On the certification exam, question distractors frequently refer to the comment connecting line as a "dependency line" or illustrate it with an open stick arrowhead. In standard SysML, the line connecting a comment to a model element is strictly an anchor line ( annotatedElement reference in the metamodel) and must never have an arrowhead . +-----------------------+
- | «block» |
- | HydraulicPumpUnit | - - - - - - - - - - - - - - +--------------------------+
- +-----------------------+ (Dashed line, | Standard SysML Comment: |
- | flowRate = 120 L/min | NO arrowhead) | Operating envelope must |
- +-----------------------+ | withstand 300 bar peak. |
- +--------------------------+
- Specialized Comment Stereotypes: «rationale» and «problem»
SysML formally extends the basic UML Comment metaclass by providing two standardized, specialized stereotypes essential for systems engineering governance: +-----------------------------+
- | UML Comment |
- +-----------------------------+
- ^
- |
- +--------------------+--------------------+
- | «stereotype» | «stereotype»
- +-------------------+ +-------------------+
- | «rationale» | | «problem» |
- +-------------------+ +-------------------+
- 1. The «rationale» Stereotype
Purpose: Documents the underlying engineering justification, trade study results, mathematical analysis, or regulatory compliance reasoning behind a modeling choice.
Visual Notation: A dog-eared note box displaying the stereotype keyword «rationale» at the top, followed by the explanatory justification text.
Common Engineering Applications:
Justifying why a redundant dual-bus architecture was selected over a single bus.
Referencing a trade study report ID that determined battery chemistry.
Recording safety factor margins required by aerospace regulatory baselines.
Attachment: SysML 1.2 says a rationale "can be attached to any model element including relationships," so it can sit on a «satisfy» dependency to cite the trade study behind a design decision.
2. The «problem» Stereotype
Purpose: Flags a known design defect, unresolved technical question, anomalous behavior, safety hazard, or open issue requiring engineering remediation.
Visual Notation: A dog-eared note box displaying the stereotype keyword «problem» at the top, followed by the issue description.
Common Engineering Applications:
Documenting that thermal dissipation exceeds enclosure limits during peak processing.
Flagging an unverified interface protocol between two vendor-supplied subsystems.
Recording an unresolved test failure pending root-cause investigation.
Semantic Non-Intrusiveness
Both «rationale» and «problem» elements are non-executable informational metadata. They do not alter the behavioral execution semantics, state transitions, or token flows of the annotated elements. However, they provide rigorous traceability for systems audits and design reviews.
Constraints vs. Comments
Modelers must distinguish between informal explanatory notes and formal mathematical Constraints :
- Feature SysML Comment / «rationale» / «problem» SysML Constraint ( {...} )
- Metamodel Base Extends Comment Instance of Constraint (evaluates a ValueSpecification )
Visual Notation Dog-eared note box; dashed anchor without arrowhead Text in braces {expression} , placed beside the constrained element or inside a note anchored to it
Execution Semantics Purely informational narrative; does not evaluate Formal rule or invariant; evaluates to a boolean ( true or false )
Violation Impact Highlights concerns or context for human review Constitutes a formal invalidation of the system state or parameter limit
Typical Example «rationale» Weight limit chosen based on launch vehicle payload manifest. {totalMass <= 450.0 kg}
Stereotypes, Tagged Values, and SysML Profiles
SysML is itself a specialized profile of UML, created by defining stereotypes that adapt UML to systems engineering. Furthermore, systems engineering organizations routinely define their own custom Profiles to tailor SysML to specialized domains such as avionics, automotive safety (ISO 26262), medical devices, or defense systems.
1. Stereotypes
Definition: A stereotype is a model construct that extends an existing UML or SysML metaclass (such as Block , Property , Operation , or Comment ), adding domain-specific semantics.
Visual Syntax: Rendered by placing the stereotype name enclosed within guillemets ( «stereotypeName» ) directly above or before the element's name.
Example: In SysML, «block» is a stereotype extending the UML Class metaclass; «itemFlow» extends UML InformationFlow .
2. Tagged Values (Stereotype Properties)
Definition: When a stereotype is defined, it can own attributes. When the stereotype is applied to a model element, these attributes are called Tagged Values .
Visual Syntax: Displayed in one of two standardized formats:
Inside curly braces beneath or beside the element name: {tag1 = value1, tag2 = value2} .
Inside a dedicated compartment within the element's rectangle. SysML 1.2 allows a compartment labeled with the stereotype name in guillemets (e.g., «spaceQualified» ) listing that stereotype's property values. +-------------------------------------------------------+
- | «block» |
- | «radiationHardened» |
- | FlightTelemetryCPU |
- | {radTolerance = 100kRad, safetyClass = A} |
- +-------------------------------------------------------+
- | properties |
- | clockFrequency : Frequency = 400 MHz |
- +-------------------------------------------------------+
- Diagram Frames and Boundary Syntax
Every SysML diagram is encapsulated within an outer rectangular border called the Diagram Frame . The frame defines the boundary of the diagram canvas and establishes the structural or behavioral scope of the view.
The Standard Diagram Header Syntax
In the upper-left corner of the frame, a distinct header box displays a strictly structured text string: kind [type] name [diagramName]
kind (Mandatory): A 2-to-3 letter lowercase mnemonic identifying the specific SysML diagram kind:
- bdd (Block Definition Diagram)
- ibd (Internal Block Diagram)
- act (Activity Diagram)
- stm (State Machine Diagram)
- sd (Sequence Diagram)
- req (Requirement Diagram)
- uc (Use Case Diagram)
- par (Parametric Diagram)
- pkg (Package Diagram)
[type] (included when needed to remove ambiguity): The metaclass of the model element that encloses and owns the diagram content, enclosed in square brackets (e.g., [Block] , [Activity] , [StateMachine] , [Interaction] , [Package] ).
name (always shown): The qualified or simple identifier of the specific model element owning the diagram (e.g., SpacecraftBus , ThermalControlActivity ).
[diagramName] (Optional): A descriptive user-assigned title for this specific graphical view, enclosed in square brackets (e.g., [Internal Power Routing] , [Nominal Telemetry Sequence] ).
Boundary Elements on Diagram Frames
Crucially, the border of a diagram frame is not merely a visual border—it serves as the interface boundary of the enclosing model element. Across different diagram kinds, the frame border hosts specific boundary elements:
Internal Block Diagram ( ibd ): Boundary Ports
Small square port symbols drawn directly on the outer diagram frame represent ports belonging to the enclosing Block that owns the IBD.
Connectors inside the IBD attach to these boundary ports, routing internal signals from internal parts to external systems.
Activity Diagram ( act ): Activity Parameter Nodes
Rectangles drawn directly on the diagram frame border represent input and output parameters of the enclosing Activity .
Object flow arrows inside the activity originate from or terminate at these boundary parameter nodes.
Sequence Diagram ( sd ): Boundary Gates
Connection points placed on the frame border representing message endpoints that enter or exit the interaction from external contexts.
Frame Anchors for Annotations
An entire diagram can be annotated by attaching a Comment, «rationale» , or «problem» dog-eared note directly to the diagram frame border via a dashed anchor line.
Other Border Elements
SysML 1.2 Annex A also lists entry and exit points on state machine frames and constraint parameters on constraint block frames.
Diagram Description and Diagram Usage
The MU100 coverage map names the diagram description alongside the header. SysML 1.2 Annex A defines it as a comment attached to the diagram frame (its Figure A.2 shows it at the top right of the frame) that can include:
- Field What it records
- Version The version of the diagram
- Description What the diagram shows
- Completion status How complete the modeler asserts the diagram is
- Reference References to related information
- User-defined fields Anything else the organization needs
The diagram description may also identify the view the diagram belongs to and the corresponding viewpoint (Section 1.2). Tools may present it in more detail.
SysML 1.2 also allows a diagram usage : a keyword such as «ContextDiagram» placed above the diagram kind in the heading to mark a specialized use of a diagram kind, for example a context diagram drawn as a uc , bdd , or ibd . Because a diagram is not a metaclass, this is a notation convention rather than a true stereotype.
Worked Real-World Example: Electric Vehicle Battery Management System (BMS)
Consider an Internal Block Diagram specifying the internal architecture of an EV Battery Pack:
Diagram Header: ibd [Block] BatteryPack [Internal Cell Balancing Architecture]
Boundary Ports on Frame:
pHighVoltage : HV_PowerPort positioned on the right vertical frame border.
pCAN : CAN_BusPort positioned on the bottom frame border.
Stereotyped Component: The internal controller part bmsCore : BMS_Controller is stereotyped with «automotiveSafety» displaying tagged values {ASIL = ASIL_D, maxFailureRate = 10FIT} .
Rationale Annotation: A dog-eared note labeled «rationale» is anchored via a dashed line to the cell balancing resistor circuit: "Passive cell balancing selected over active balancing based on trade study TS-BMS-04; satisfies volume, thermal envelope, and unit cost constraints."
Problem Annotation: A dog-eared note labeled «problem» is anchored via a dashed line to the temperature sensor array: "Thermistor ADC sampling experiences severe EMI noise when inverter draws >300A; filtering capacitor revision required in Rev C."
This single diagram combines structural framing, interface boundaries, domain metadata (stereotypes and tags), and formal engineering rationale and issue tracking.
Summary Comparison of SysML Annotations & Stereotype Constructs
Construct Visual Notation Metamodel Foundation Semantic Role Tagged Values Supported?
Comment Dog-eared note box; dashed anchor line without arrowheads Comment Plain text narrative, descriptions, or general notes. No
«rationale» Dog-eared note with «rationale» at top Stereotype extending Comment Captures engineering justification, trade study results, and design decisions. Yes (if defined by profile)
«problem» Dog-eared note with «problem» at top Stereotype extending Comment Identifies defects, open questions, hazards, or technical debt. Yes (if defined by profile)
Constraint Text in braces {...} , beside the element or in an anchored note Constraint Formal invariant condition that must evaluate to true/false. No
Stereotype Guillemets «stereotypeName» above element Extends a UML Class or Metaclass Extends metamodel vocabulary for specific engineering domains. Yes (defines tagged values)
Tagged Value {tag = value} or dedicated compartment Property of a Stereotype Holds domain-specific metadata values assigned to an element. N/A (is the value)
Diagram Frame Elements Across SysML Diagram Kinds
Diagram Kind Kind Mnemonic Typical Enclosing Context Metaclass Boundary Elements Hosted on Frame Border Primary System Scope
Block Definition Diagram bdd [Package] , [Block] , [ConstraintBlock] Package containment anchors, comment anchors Element definitions, generalizations, associations.
Internal Block Diagram ibd [Block] Boundary Ports of the enclosing block Internal part interconnection and flow routing.
Activity Diagram act [Activity] Activity Parameter Nodes (inputs/outputs) Procedural algorithmic workflows and token flow.
State Machine Diagram stm [StateMachine] Entry/Exit connection points, comment anchors Event-driven reactive modal behavior.
Sequence Diagram sd [Interaction] Gates (message end points on the frame) Chronological message passing across lifelines.
Parametric Diagram par [Block] , [ConstraintBlock] Constraint parameters, bound value properties Mathematical equations and performance trade-offs.
Package Diagram pkg [Package] , [Model] Comment anchors Model organization, namespaces, and views.
Requirement Diagram req [Package] , [Requirement] Comment anchors Requirements and their relationships.
Use Case Diagram uc [Package] Comment anchors Actors, use cases, and subjects.
Exam Pitfalls & Misconceptions
Concept Correct SysML Rule Common Exam Trap / Distractor
Comment Anchor Lines Connecting line must be a dashed line with NO arrowhead . Drawing an arrowhead (solid or open) on a comment connection line.
Rationale & Problem Metaclass «rationale» and «problem» are stereotypes extending UML Comment . Believing they are structural blocks, associations, or specialized requirements.
Constraint vs Annotation Constraints evaluate formal expressions to boolean values; comments are informational text. Treating a constraint as a comment, or assuming comments are evaluated by analysis engines.
Frame Context Metaclass The [type] field in the frame header must match the metaclass of the owning element. Mismatching the context element (e.g., writing act [Block] VehicleControl instead of act [Activity] VehicleControl ).
Boundary Port Ownership Ports drawn on an ibd frame border belong to the enclosing Block , not to internal parts. Assuming frame boundary ports are internal parts or external environment actors.
Stereotype Guillemets Stereotypes are displayed using guillemets ( «...» ), not square brackets or parentheses. Writing [stereotype] or {stereotype} instead of «stereotype» .