Study guide
12.2 Associations, Include, Extend & Generalization
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
12.2 Associations, Include, Extend & Generalization
Key Takeaways Explain This Topic AI
Communication associations are solid lines without arrowheads connecting an actor to a use case, establishing bidirectional interaction without implying functional decomposition.
The «include» dependency points from the base use case to the included use case, enforcing mandatory, unconditional execution of shared modular behavior.
The «extend» dependency points from the extension use case to the base use case (the opposite direction of include), representing optional or conditional behavior triggered at explicit extension points.
Extension Points are declared within the base use case, providing precise insertion anchors referenced by optional extension behaviors under specific guard conditions.
Generalization (hollow triangular arrowhead) models inheritance between use cases (specializing behavioral goals) or between actors (inheriting communication associations).
Last updated: September 2026
12.2 Associations, Include, Extend & Generalization
Quick Reference: Use cases and actors interact through four primary relationships. Communication Associations (solid lines without arrowheads) link actors to use cases. «include» (dashed arrow) points FROM base TO included use case, enforcing mandatory execution. «extend» (dashed arrow) points FROM extension TO base use case (the opposite arrow direction!), representing optional execution at declared Extension Points . Generalization (solid line with hollow triangular arrowhead) models inheritance hierarchies between actors or between use cases.
Communication Associations: Connecting Actors to Use Cases
A Communication Association is the fundamental link between an actor and a use case. It signifies that the actor participates in the use case by exchanging signals, data, energy, or physical items with the system.
Syntax and Notational Rules
Visual Representation: A solid, continuous line connecting an actor symbol to a use case ellipse.
Arrowhead Rule: In standard SysML use case modeling, communication associations are drawn without arrowheads . This denotes bidirectional interaction: the actor initiates or sends input to the use case, and the use case returns status, results, or value to the actor.
Multiplicity Adornments: Multiplicities may optionally be specified at either end of the association (e.g., 1 at the actor end and * or 1..* at the use case end), indicating how many concurrent instances of the actor or use case can participate simultaneously.
Crucial Rule & Exam Trap: A communication association line CANNOT connect two use cases together directly , nor can it connect two actors together directly. Connecting two use cases with a plain solid line is a severe syntax error frequently used as a distractor on certification exams. Relationships between use cases must exclusively utilize «include» , «extend» , or Generalization .
The «include» Relationship: Mandatory Shared Capability
The «include» relationship is a directed dependency between two use cases that factors out common, reusable behavior shared across multiple capabilities.
Syntax and Arrowhead Direction
Visual Representation: A dashed line with an open stick arrowhead ( ---> ).
Stereotype Keyword: Labeled with the stereotype «include» .
Arrowhead Direction: The arrow points FROM the base use case TO the included use case : BaseUseCase - - - «include» - - - > IncludedUseCase
Mandatory Execution Semantics
Unconditional Invocation: Whenever the base use case executes, the included use case ALWAYS executes . Execution of the included behavior is mandatory for the base use case to complete successfully.
Factoring Commonality: Used when multiple use cases share an identical behavioral sequence. Rather than duplicating the behavior across multiple use cases, the shared sequence is encapsulated into a separate use case and included by each base use case.
Base Awareness: The base use case is explicitly designed with knowledge of the included use case and relies on its successful completion.
Real-World Example
Consider an aircraft avionics system where both ExecuteFlightPlan and PerformManualReroute require radio navigation verification. Both base use cases declare an «include» dependency pointing to the modular use case ValidateNavigationalWaypoints .
The «extend» Relationship: Optional and Exceptional Behavior
The «extend» relationship is a directed dependency that inserts optional, conditional, or exceptional behavior into a base use case.
Syntax and The "Opposite Arrow" Exam Trap
Visual Representation: A dashed line with an open stick arrowhead ( ---> ).
Stereotype Keyword: Labeled with the stereotype «extend» .
Arrowhead Direction: The arrow points FROM the extension use case TO the base use case : ExtensionUseCase - - - «extend» - - - > BaseUseCase
Critical Exam Trap: Modeler intuition frequently assumes the arrow should point from the base to the extension (since the base is being "extended"). SysML defines the exact opposite! The arrow originates at the extension use case and points toward the base use case . This semantic orientation signifies that the extension use case possesses the dependency knowledge of where and how it hooks into the base, whereas the base use case remains independent and decoupled from the extension.
Optionality and Conditional Execution
Not Mandatory: Unlike an included use case, an extension use case does not execute automatically. It executes only when specific operational conditions occur, such as system faults, emergency overrides, or optional feature toggles.
Base Decoupling: The base use case can execute to completion entirely on its own without the extension use case ever being triggered.
Extension Points: Anchoring Conditional Behavior
For an extension use case to know where within the base use case sequence its behavior should be inserted, the base use case must define one or more Extension Points .
Graphical Declaration of Extension Points
Inside or directly below the base use case ellipse, a dedicated compartment is rendered with the heading extension points: .
Each extension point is listed by an identifier name (e.g., extension points: ObstacleDetected, BatteryCritical ). +----------------------------------+
- ( DeliverPayload )
- ( -------------------------------- )
- ( extension points: )
- ( ObstacleDetected )
- +----------------------------------+
- ^
- | «extend»
- | condition: {obstacle_range < 2m}
- +----------------------------------+
- ( ExecuteObstacleEvasion )
- +----------------------------------+
- Condition Constraints and Notes
A constraint note or expression is typically attached to the «extend» dependency line, stating the guard condition (e.g., condition: {battery_charge < 15%} ). When the base use case reaches the named extension point during runtime, the condition is evaluated. If true, the extension use case executes; if false, the base use case continues its normal sequence.
Generalization: Classifier Inheritance for Use Cases and Actors
SysML supports Generalization to model taxonomic inheritance hierarchies among use cases and among actors. In accordance with UML/SysML classifier semantics, generalization is drawn as a solid line with a hollow, closed triangular arrowhead pointing toward the general element (super-classifier).
- 1. Generalization Between Use Cases
- Notation: SpecializedUseCase ----▷ GeneralUseCase
Semantics: The specialized use case inherits the operational intent, external actor associations, and extension/include dependencies of the general use case. The specialized use case provides a specific or alternative implementation of the general capability.
Abstract vs. Concrete: The general use case is often abstract (rendered with its name in italics ), meaning it establishes a common goal that is only instantiated through its concrete specializations.
Example: AuthenticateOperator (general use case) specialized by AuthenticateViaBiometrics and AuthenticateViaSmartCard .
- 2. Generalization Between Actors
- Notation: SpecializedActor ----▷ GeneralActor
Semantics: The specialized actor (sub-actor) inherits all communication associations connected to the general actor (super-actor). Any use case accessible to the general actor is automatically accessible to the specialized actor.
Added Capabilities: In addition to inherited capabilities, the specialized actor can participate in additional exclusive use cases unavailable to the general actor.
Example: In a mission control center, FlightDirector specializes MissionController . The FlightDirector inherits all routine monitoring capabilities of MissionController , but possesses exclusive communication associations to AuthorizeAbortSequence and OverrideSafetyProtocols .
Comparison Matrix: Use Case Relationships
Relationship Graphical Notation Arrowhead Type Direction Execution Guarantee Base Awareness Primary Engineering Purpose
Communication Association Solid line None (bidirectional) N/A (links Actor to Use Case) Participates whenever use case runs Yes Connects external actors to the capabilities they initiate or support.
«include» Dashed line Open stick arrowhead ( ---> ) Base → Included Mandatory (always executes with base) Yes (base references included) Reuses shared functional routines across multiple use cases.
«extend» Dashed line Open stick arrowhead ( ---> ) Extension → Base Optional / Conditional (executes at extension point) No (base defines point, unaware of extension) Models exception handling, optional features, and hazard mitigation.
Generalization (Use Case) Solid line Hollow closed triangle ( ----▷ ) Specialized → General Polymorphic specialization Inherits general behavior Refines a general capability into specific variant implementations.
Generalization (Actor) Solid line Hollow closed triangle ( ----▷ ) Specialized → General Full association inheritance Inherits all associations Models hierarchical operational roles and permission escalation.
Worked Systems Engineering Scenario: Autonomous Delivery Rover
Consider an Autonomous Delivery Rover operating in an urban pedestrian environment:
Base Capability with Mandatory Modular Inclusion:
The rover executes DeliverPayload . To complete this service, the rover must compute paths and navigate. DeliverPayload has an «include» dependency pointing to NavigateWaypoints .
Conditional Exception via Extension:
While navigating, a pedestrian may abruptly cross the rover's trajectory. DeliverPayload defines an extension point: extension points: ObstacleDetected .
The use case ExecuteObstacleEvasion has an «extend» dependency pointing to DeliverPayload , annotated with condition: {sensor_proximity < 1.5m} .
If no obstacle appears, ExecuteObstacleEvasion never executes; if an obstacle is detected, the evasion maneuver is inserted at the extension point.
Use Case Specialization:
The rover supports TransmitMissionLog . This capability is specialized into TransmitLocalWiFiLog and TransmitCellularLog via Generalization .
Actor Hierarchy:
FieldTechnician participates in PerformMaintenanceDiagnostic .
LeadFleetEngineer specializes FieldTechnician . The LeadFleetEngineer inherits the diagnostic capability and exclusively participates in FlashFirmwareImage .
Exam Pitfalls & Misconceptions
Concept Correct Rule Common Exam Trap / Distractor
Extend Arrowhead Direction Points from the extension use case to the base use case. Reversing the arrow to point from base to extension (matching include).
Include Arrowhead Direction Points from the base use case to the included use case. Drawing the include arrow pointing from included to base.
Association Between Use Cases Two use cases can NEVER be connected by a solid association line. Using a solid association line to indicate that one use case calls another.
Execution Conditionality «include» is mandatory; «extend» is conditional/optional. Believing that «include» can be optional or that «extend» always executes.
Extension Point Location Extension points are declared in the base use case, not the extension use case. Placing the extension points: compartment inside the extension use case ellipse.
Arrowhead Style for Generalization Generalization uses a hollow closed triangle , never an open stick arrow. Drawing generalization with a dashed line or an open arrow ( ---> ).
Actor Association Inheritance A specialized actor inherits ALL associations of the general actor. Believing that actor generalization creates a structural composition between actors.