2.3 Specialization, Generalization & Inheritance Hierarchies

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:

1. Individual Lines: Each subtype connects to the supertype with its own line and separate triangular arrowhead.
2. 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

1. Type Covariance: The type of the redefining property must specialize (or be identical to) the type of the property being redefined.
2. 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:
  1. The name of the block is printed in italics (e.g., *Vehicle*), OR
  2. 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:

1. 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.
2. 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:

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

1. 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.
2. 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).
3. 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.
4. 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.
5. 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.