3.2 Multiplicities, Reference Properties & Association Ends

3.2 Multiplicities, Reference Properties & Association Ends

Quick Summary: In SysML Block Definition Diagrams, multiplicities define instance cardinalities (allowable instance counts) using the canonical lower..upper notation. A property declared without a multiplicity defaults to 1; SysML 1.2 adds diagram defaults for association ends (see below). Association ends define properties typed by the opposite block: composite aggregation produces part properties (listed in the parts compartment; solid-outline boxes on an ibd), while associations without composition produce reference properties (listed in the references compartment; dashed-outline boxes on an ibd).

In Model-Based Systems Engineering (MBSE), defining system topology requires precision regarding not only how blocks connect, but how many instances of each block can or must exist, who owns them, and what role they play in the system architecture. On a Block Definition Diagram (BDD), these details are captured through multiplicities, association ends, and their realization as part properties or reference properties.

---

Multiplicity Syntax and Specification Grammar

A multiplicity is a definition of cardinality that constrains the number of allowable instances of a property, parameter, or association end in a valid system. In SysML, multiplicity expressions conform to formal grammar rules derived from UML:

General Format: lower..upper

The canonical multiplicity format specifies an inclusive range from a lower bound to an upper bound:

• lower bound: A non-negative integer (0, 1, 2, …) specifying the minimum number of instances required.
• upper bound: A positive integer or the literal asterisk character (*), which signifies an unbounded or unlimited number of instances.

Multiplicity Variations and Semantic Meanings

UML 2, the base of SysML 1.2, defines a multiplicity as a single lower..upper interval. Comma-separated lists such as 1, 3, 5 or 2..4, 6..8 came from UML 1.x and are not valid SysML multiplicities.

Default Multiplicity Rules

Three defaults matter when a multiplicity is not shown:

The specification adds: "To avoid confusion, any multiplicity other than the default should always be shown on a diagram."

Exam Trap: Do not read a missing multiplicity as * (zero-to-many). First identify where it is missing: a bare part label such as sensorPod : SensorUnit means exactly one, while an unlabeled black-diamond end means at most one whole (0..1).

---

Association Ends and Property Duality

An association line between two blocks has two association ends. Each end represents a property owned either by the association itself or by the classifier at the opposite end of the relationship.

Anatomical Breakdown of an Association End

An association end on a BDD can display a full textual string adhering to standard property syntax:

[visibility] [name] : [Type] '[' [multiplicity] ']' [ {constraints} ]

• Visibility: Specifies accessibility. In SysML, the standard notations are:
  • + Public (default in SysML)
  • - Private
  • # Protected
  • ~ Package
• Role Name: The identifier of the property in the context of the owning block (e.g., frontBrake, payloadController).
• Type: The block typing the end (typically implicit from the block attached to that end).
• Multiplicity: Enclosed in square brackets (e.g., [4], [0..1], [1..*]).
• Modifiers: Optional tagged values or property modifiers in curly braces (e.g., {readOnly}, {ordered}, {unique}).

Graph-to-Compartment Duality

In SysML, there is a strict 1-to-1 equivalence between drawing an association on a BDD and listing a property within a block compartment:

• Graphical Representation: An association line drawn between Block A and Block B.
• Compartment Representation: A text entry inside the feature compartments of Block A and Block B.

A system modeler can choose either representation—or use both across different diagrams. They represent the exact same underlying repository element.

---

Part Properties vs. Reference Properties

Understanding the distinction between part properties and reference properties is fundamental to passing the OCSMP Model User exam. The type of property created depends entirely on the aggregation kind of the association end:

1. Part Properties (Composition)

• Creation: Generated when the association features a solid black diamond attached to the owning block.
• Semantics: Represents exclusive whole-part containment. The owning block is responsible for the creation, management, and destruction of the part.
• Compartment Location: Displayed inside the parts compartment of the block.
• Visual Styling: On an ibd, a part property is drawn as a solid-outline box.
• Syntax Example: Inside the parts compartment of Automobile:

  parts
  +engine : InternalCombustionEngine [1]
  +wheels : WheelAssembly [4]
  

2. Reference Properties (Reference Association)

• Creation: Generated when the association end has no black diamond: aggregation none, or the white diamond of shared aggregation (which the MU100 map excludes).
• Semantics: Represents a "knows-about" or "points-to" reference. The referencing block holds a pointer or handle to an external instance without owning it or controlling its lifecycle.
• Compartment Location: Displayed inside the references compartment of the block.
• Visual Styling: On an ibd, a reference property is drawn as a dashed-outline box.
• Syntax Example: Inside the references compartment of Automobile:

  references
  +currentDriver : Person [0..1]
  +assignedMechanic : Technician [1]
  

Comprehensive Comparison Table

---

Multiplicity Calculations in Structural Trees

On the OCSMP Model User exam, questions frequently present a hierarchical decomposition tree and ask candidates to calculate the minimum and maximum possible instances of a leaf component in a system instance.

Instance Multiplication Rule

When traversing a composition hierarchy from parent to child, total instance counts are calculated by multiplying the multiplicities along the path:

$$\text{Total Count} = \prod_{i=1}^{k} \text{Multiplicity}_i$$

When ranges are involved, calculate the lower and upper bounds independently:

$$\text{Min Count} = \prod \text{Lower}_i \quad \text{and} \quad \text{Max Count} = \prod \text{Upper}_i$$

Detailed Step-by-Step Scenario: Commercial Aircraft Structural Tree

Consider the following structural decomposition modeled on a BDD:

1. Fleet to Aircraft:
   • Relationship: Composition.
   • End at Aircraft: +planes : Aircraft [10..20]
2. Aircraft to TurbofanEngine:
   • Relationship: Composition.
   • End at TurbofanEngine: +engines : TurbofanEngine [2..4]
3. TurbofanEngine to TurbineBlade:
   • Relationship: Composition.
   • End at TurbineBlade: +blades : TurbineBlade [50..80]
4. TurbofanEngine to FullAuthorityDigitalEngineControl (FADEC):
   • Relationship: Composition.
   • End at FADEC: +fadec : FADEC [2] (dual-redundant channels per engine)

Calculating Component Cardinalities:

• How many TurbofanEngine instances exist in a single Aircraft?

  • Minimum: 2
  • Maximum: 4

• How many TurbineBlade instances exist in a single Aircraft?

  • Minimum: min engines × min blades = 2 × 50 = 100
  • Maximum: max engines × max blades = 4 × 80 = 320

• How many FADEC units exist across the entire Fleet?

  • Minimum: min planes × min engines × FADECs per engine = 10 × 2 × 2 = 40
  • Maximum: max planes × max engines × FADECs per engine = 20 × 4 × 2 = 160

• How many TurbineBlade instances exist across the entire Fleet?

  • Minimum: 10 × 2 × 50 = 1,000
  • Maximum: 20 × 4 × 80 = 6,400

Special Handling of Optional Parts (0..1)

If an intermediate block has a lower bound of 0, the lower bound of all downstream leaf components automatically drops to 0.

• For example, if an Aircraft has 0..1 AuxiliaryPowerUnit (APU), and each APU has 2 StarterGenerators, the number of StarterGenerators in an aircraft is between 0 × 2 = 0 and 1 × 2 = 2.

---

Common Exam Pitfalls with Multiplicities and Roles

1. Reading Roles at the Wrong Block:
   • A role name placed adjacent to Block B specifies a property owned by Block A, typed by Block B.
   • If an association between Satellite and Battery has +powerStorage [2] placed next to Battery, the powerStorage property belongs to Satellite! The Battery does not own a powerStorage property.
2. Confusing Multiplicity Brackets with Array Indices:
   • In programming languages, [4] might signify an array index or fixed size. In SysML, [4] means the instance cardinality is exactly 4 instances (4..4), not an index from 0 to 3.
3. Ignoring Which End Is Unlabeled:
   • A property label with no multiplicity means 1, but an unlabeled black-diamond end means 0..1. Neither default is *.
4. Treating Reference Properties as Parts:
   • If a question asks which components are destroyed when SystemA is deleted, eliminate any blocks linked via reference associations (no diamond). Only blocks linked via composite aggregation (solid black diamond) undergo cascading deletion.