Study guide
2.3 Specialization, Generalization & Inheritance Hierarchies
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
2.3 Specialization, Generalization & Inheritance Hierarchies
Key Takeaways Explain This Topic AI
Generalization is a taxonomic relationship where a specialized classifier inherits all structural and behavioral features from a general classifier.
The generalization notation is a solid line with an unshaded (hollow), closed triangular arrowhead pointing toward the general classifier (supertype).
Abstract blocks cannot be directly instantiated and are designated by an italicized name or the {abstract} property modifier.
A specialized block can narrow or replace inherited properties using the {redefines <property>} constraint.
Generalization ('is-a') models taxonomic classification, whereas composition ('has-a') models whole-part structural ownership.
Last updated: September 2026
2.3 Specialization, Generalization & Inheritance Hierarchies
Quick Summary: In SysML, generalization models a taxonomic classification relationship between a general classifier (supertype) and a specialized classifier (subtype). Notationally, it is depicted as a solid line with an unshaded (hollow), closed triangular arrowhead pointing toward the general classifier . The specialized block inherits all structural features (parts, references, values, ports, constraints) and behavioral features (operations, receptions), and can refine inherited properties using {redefines} .
1. Concept and Notation of Generalization
Generalization is a taxonomic relationship between a more general classifier (referred to as the supertype, superclass, or general classifier) and a more specific classifier (referred to as the subtype, subclass, or specialized classifier).
The Direction of the Arrowhead
On the OCSMP Model User exam, one of the most critical visual rules to master is the arrowhead orientation and style :
Arrowhead Style: An unshaded (hollow), closed triangle . It is not an open stick arrow -> , not a filled arrowhead, and not a diamond.
Arrowhead Direction: The arrow points from the specialized classifier to the general classifier (from subtype to supertype). +-----------------------+
- | «block» |
- | Vehicle | <-- General Classifier (Supertype)
- +-----------------------+
- ^
- |
- | (Solid line with hollow, closed triangle)
- |
- +-----------------------+
- | «block» |
- | GroundVehicle | <-- Specialized Classifier (Subtype)
- +-----------------------+
- Shared Arrow Notation (Tree Notation)
When multiple specialized blocks inherit from the same general block, SysML allows two equivalent graphical representations:
Individual Lines: Each subtype connects to the supertype with its own line and separate triangular arrowhead.
Tree Notation (Shared Target Line): The lines from multiple subtypes converge into a single horizontal or vertical bus line that terminates in a single shared hollow triangular arrowhead pointing to the supertype.
Both notations have identical semantic meaning.
2. Semantics of Inheritance: What is Inherited?
When Block B specializes Block A ( Block B --|> Block A ), Block B inherits all features defined on Block A. In SysML, inheritance is comprehensive across both structural and behavioral domains:
Inherited Structural Features
Part Properties: All composite parts owned by the general block are automatically owned by the specialized block.
Reference Properties: All references, external associations, and shared aggregations are inherited.
Value Properties: All quantifiable attributes, units, default values, and modifiers are inherited.
Constraint Properties: All mathematical equations and constraint parameters defined on the general block apply to the specialized block.
Ports: All interaction points (standard ports and flow ports) are inherited.
Inherited Behavioral Features
Operations: All callable service signatures, parameter lists, and return types are inherited.
Receptions: All signal reception capabilities declared by the general block are inherited.
The Liskov Substitutability Principle (LSP)
Inheritance in SysML conforms to the Liskov Substitutability Principle : Anywhere an instance of the general block is expected in a system model (e.g., as the type of a part property, an association end, or an operation parameter), an instance of any specialized subtype may be provided without violating the structural or behavioral contract of the system.
Additive Nature of Specialization
A specialized block is additive : it inherits everything from its general block and may define additional parts, references, values, operations, receptions, and constraints that are unique to its specialized role.
3. Feature Redefinition and Overriding
In many engineering scenarios, a specialized block does not simply accept an inherited property as-is; it needs to refine, specialize, or restrict that property. In SysML, this is accomplished via feature redefinition using the {redefines <propertyName>} constraint.
Redefinition Rules
Type Covariance: The type of the redefining property must specialize (or be identical to) the type of the property being redefined.
Multiplicity Narrowing: The multiplicity of the redefining property can be equal to or more restrictive than the inherited multiplicity, but it can never be widened. For example, a multiplicity of [0..*] can be redefined to [2..4] , or [0..1] can be redefined to [1] , but [1] cannot be redefined to [0..*] .
- Example: Propulsion Redefinition +---------------------------------------------------+
- | «block» |
- | Vehicle |
- +---------------------------------------------------+
- | parts |
- | propulsion : Engine [1] |
- +---------------------------------------------------+
- ^
- |
- +---------------------------------------------------+
- | «block» |
- | ElectricTruck |
- +---------------------------------------------------+
- | parts |
- | electricDrive : ElectricMotor [1] |
- | {redefines propulsion} |
- +---------------------------------------------------+
In this example, ElectricTruck inherits from Vehicle . Rather than having both an engine and an electricDrive , ElectricTruck explicitly specifies that electricDrive replaces the inherited propulsion part.
4. Abstract Blocks vs. Concrete Blocks
On BDDs, blocks are categorized as either abstract or concrete:
Abstract Blocks
Definition: An abstract block cannot be directly instantiated in a system model. It exists solely to define common properties, shared structural patterns, and standardized interfaces for its subtypes.
Visual Notation:
The name of the block is printed in italics (e.g., *Vehicle* ), OR
The text modifier {abstract} is placed below or next to the block name (e.g., Vehicle {abstract} ).
Usage Rule: A part property may be typed by an abstract block (common in reference architectures), but any instance that fills that part at runtime must belong to a concrete specialization.
Concrete Blocks
Definition: A block that can be directly instantiated in system models, allocated to physical components, and executed.
Visual Notation: Standard upright (roman) bold font with no {abstract} modifier.
5. Specialization of Value Types
Generalization is not restricted to «block» elements; it applies to all classifiers, including «valueType» elements.
Examples of ValueType Inheritance
An abstract value type Temperature can be specialized into CelsiusTemperature and KelvinTemperature .
A specialized value type UnsignedInteger can specialize Integer , adding the constraint {value >= 0} .
A specialized value type CalibratedPressure can specialize Pressure , inheriting the quantity kind Pressure and unit Pascal while adding calibration offset attributes.
- 6. Multiple Inheritance & Generalization Sets
- Multiple Inheritance
SysML supports multiple generalization , meaning a specialized block may inherit from more than one general block. For example, an AmphibiousVehicle block can specialize both GroundVehicle and Watercraft , inheriting the wheels and steering of the ground vehicle along with the hull and propulsion of the watercraft.
Generalization Sets
A Generalization Set is a mechanism to partition and categorize generalizations of a common supertype using a discriminator name. Generalization sets are governed by two orthogonal semantic constraints:
Completeness:
{complete} : Indicates that all possible specialized subtypes of the supertype have been defined in the model. No other subtypes exist.
{incomplete} : Indicates that the defined subtypes do not cover all possibilities; additional subtypes exist or may be added later.
Disjointness:
{disjoint} : Indicates that an instance of the supertype can be an instance of at most one subtype in the set. An element cannot be both subtypes simultaneously.
{overlapping} : Indicates that an instance can simultaneously be an instance of more than one subtype in the set.
Scope note: Generalization sets are not listed on the MU100 coverage map, and the default assumed when no constraint is shown has differed between UML versions. On a diagram, read the constraint that is actually written (for example {complete, disjoint} ) rather than relying on a default.
7. Generalization ('is-a') vs. Composition ('has-a') vs. Association ('refers-to')
A central focus of the OCSMP Model User exam is ensuring candidates never confuse classification with structural composition:
Relationship Semantic Meaning Notation Multiplicity Allowed? Feature Inheritance? Lifecycle Dependency?
Generalization "is-a" (Classification) Solid line, hollow triangle pointing to supertype No (never has multiplicity) Yes (subtypes inherit all features) N/A (classification, not instances)
Composition "has-a" (Whole-Part) Solid line, solid black diamond at whole end Yes (at both ends) No (whole owns parts, does not inherit) Yes (parts die with whole)
Association "refers-to" (Peer Connection) Solid line with no diamond (the white shared-aggregation diamond is outside the MU100 map) Yes (at both ends) No (peers communicate, no inheritance) No (independent lifecycles)
The Engineering Test
When evaluating a relationship between two system concepts on an exam question, apply this diagnostic:
If you can state "A DieselLocomotive IS A Locomotive" , use Generalization .
If you must state "A Locomotive HAS A DieselEngine" , use Composition .
If you must state "A Locomotive COMMUNICATES WITH A DispatchTower" , use Association .
8. Common OCSMP Exam Traps & Pitfalls
Arrowhead Direction Error: The hollow triangle points to the GENERAL block (parent/supertype), NOT to the specialized child. In diagrams where Block A is at the top and Block B is at the bottom, the arrow points UP from B to A.
Arrowhead Geometry Error: Only an unshaded (hollow), closed triangle represents generalization. Watch out for exam distractors showing:
Open stick arrows -> (dependencies when the line is dashed; navigability at an association end).
Solid filled triangles (used for synchronous messages in sequence diagrams).
Hollow diamonds <> (represents shared aggregation).
Solid diamonds <#> (represents composite aggregation).
Multiplicity on Generalization Lines: Generalization lines NEVER carry multiplicities . If you see numbers like [1] or [0..*] on a generalization arrow, that diagram is malformed according to SysML rules.
Confusing Inheritance with Composition: A common error is asserting that a Car inherits an Engine . A car does not specialize an engine; a car owns an engine as a part property via composite aggregation.
Abstract Block Instantiation: An abstract block has no direct instances. A part on an IBD can still be typed by an abstract block; the instance that fills it must belong to a concrete specialization.