2.1 Block Definitions, Features & Compartments

2.1 Block Definitions, Features & Compartments

Quick Summary: In SysML, a Block Definition Diagram (BDD) defines the reusable types (classifiers) of a system and their structural relationships. The fundamental distinction tested on the OCSMP Model User exam is Definition vs. Usage: a Block Definition is a reusable type on a BDD, whereas a Block Usage is a property typed by that block inside an enclosing assembly. Blocks group their structural and behavioral features into standard compartments that can be shown, suppressed, or left empty.

---

1. Purpose and Role of the Block Definition Diagram (BDD)

The Block Definition Diagram (BDD) is the primary structural diagram in the Systems Modeling Language (SysML). Derived from the UML Class Diagram, the BDD defines the elements that compose a system, their classification hierarchies, and their internal feature definitions without binding them to a single physical assembly or runtime context.

Diagram Header Syntax

Every SysML diagram is framed by a boundary with a standardized diagram header in the upper-left corner. For a BDD, the header format is:

bdd [modelElementType] QualifiedNamespace [DiagramName]

• Diagram Kind (bdd): Identifies the diagram as a Block Definition Diagram.
• Model Element Type: Typically package, model, or block indicating the enclosing namespace.
• Qualified Namespace: The full package path, such as AutomotiveSystem::Architecture.
• Diagram Name: A descriptive title enclosed in brackets, such as [Powertrain Taxonomy].

Architectural Benefits of BDDs

BDDs allow systems engineers to:

1. Define Reusable Vocabularies: Establish domain concepts (sensors, actuators, controllers) once and reuse them across multiple subsystems.
2. Specify Structural Decomposition: Define what components can belong to a system before designing their specific internal routing.
3. Classify Generalization Hierarchies: Build taxonomies from abstract base components to specialized production hardware.
4. Encapsulate Interfaces and Quantities: Associate units, value properties, operations, and signals with standardized classifiers.

---

2. Block Definition vs. Block Usage: The Core SysML Duality

The most heavily tested structural concept on the OCSMP Model User exam is the strict separation between a Block Definition and a Block Usage.

Understanding the Distinction

Consider an aircraft with four identical engines. The engineering design needs only one block definition called TurbofanEngine on a BDD. That definition specifies the engine's thrust rating, dry mass, fuel consumption equations, and control operations.

However, when modeling the aircraft assembly, the enclosing block Airframe declares four distinct block usages:

• engine1 : TurbofanEngine [1] (mounted on the inboard port wing)
• engine2 : TurbofanEngine [1] (mounted on the outboard port wing)
• engine3 : TurbofanEngine [1] (mounted on the inboard starboard wing)
• engine4 : TurbofanEngine [1] (mounted on the outboard starboard wing)

Each engine usage shares the exact same definition, but each represents a unique role with distinct physical locations, wiring harnesses, and telemetry streams.

---

3. Block Rectangle Anatomy & Notation Rules

A block is visually represented as a solid-outline rectangle. The standard notation consists of:

1. Stereotype Keyword: The string «block» appears centered above or alongside the block name. In standard typography, French guillemets « » are preferred, though double angle brackets <<block>> are accepted by modeling tools.
2. Block Name: The name of the block appears in bold text, centered in the top compartment (the name compartment).
3. Namespace Adornment: If the block is displayed in a diagram outside its owning package, its namespace path can be indicated above the name (e.g., (from PropulsionPkg) or PropulsionPkg::TurbofanEngine).
4. Abstract Modifier: If the block cannot be directly instantiated, its name is rendered in italics, or the text modifier {abstract} is appended.

---

4. Standard Block Compartments

SysML blocks organize their internal features into horizontal compartments separated by thin horizontal divider lines. Each compartment displays a specific category of feature.

+---------------------------------------------------+
|                     «block»                       |
|                   Automobile                      |
+---------------------------------------------------+
| parts                                             |
|   engine : V6Engine [1]                           |
|   transmission : AutomaticTransmission [1]        |
+---------------------------------------------------+
| references                                        |
|   maintenanceFacility : ServiceStation [0..1]     |
+---------------------------------------------------+
| values                                            |
|   curbWeight : Mass = 1450 kg                     |
|   fuelCapacity : Volume = 60 L                    |
+---------------------------------------------------+
| operations                                        |
|   startIgnition(keySignal : KeyCode) : Boolean    |
|   applyBraking(pedalForce : Real) : Void          |
+---------------------------------------------------+
| receptions                                        |
|   «signal» CrashDetectionSignal()                 |
+---------------------------------------------------+
| constraints                                       |
|   fuelBurnRateEq : FuelConsumptionLaw             |
+---------------------------------------------------+

1. parts Compartment

Contains part properties (composite aggregation). Parts are owned by the block by value. If the parent block instance is destroyed, all its owned part instances are destroyed with it. Syntax: partName : BlockType [multiplicity].

2. references Compartment

Contains reference properties (shared aggregation or standard association). References designate other blocks that this block interacts with or knows about, but does not own. The lifecycle of a referenced block is independent of the referencing block. Syntax: refName : BlockType [multiplicity].

3. values Compartment

Contains value properties typed by a «valueType» or primitive type (such as Real, Integer, Boolean, or String). Value properties quantify measurable attributes, configurations, or operational parameters. Syntax: propertyName : ValueType [multiplicity] = defaultValue {modifiers}.

4. operations Compartment

Contains behavioral operations. An operation represents a callable service that the block can execute synchronously or asynchronously. It defines a signature: operation name, typed input/output parameters, parameter directions (in, out, inout, return), and return type.

5. receptions Compartment

Contains receptions. A reception declares that the block is prepared to receive and asynchronously react to an incoming «signal». In UML notation a reception is listed with the keyword «signal» before the signal name and parameters, e.g., «signal» IgnitionSignal(); the reception is named after the signal it accepts.

6. constraints Compartment

Contains constraint properties typed by constraint blocks (blocks shown with the «constraint» keyword). These bind mathematical equations, physics formulas, or logical invariant assertions to the block's value properties.

7. User-Defined Compartments

SysML allows modelers and organizations to define custom compartments labeled with arbitrary text headers to organize domain-specific features, such as telemetry, environmental limits, or thermal specs. SysML 1.2 also defines namespace and structure compartments, the Ports and Flows chapter adds flow ports and standard ports compartments, and properties of any kind may appear in a generic properties compartment.

---

5. Suppressed Compartments vs. Empty Compartments

A critical distinction on the OCSMP Model User exam concerns whether a compartment is visible, hidden, or empty on a diagram view:

• Suppressed Compartment: The compartment is completely omitted from the block's visual rectangle. In SysML, suppressing a compartment is purely a visual presentation decision to reduce clutter. It does NOT mean the block lacks those features. The underlying model repository may contain dozens of parts or operations that the author simply chose not to show on that specific diagram.
• The UML Rule SysML Inherits: "If a compartment is suppressed, no inference can be drawn about the presence or absence of elements in it." The same caution applies to a compartment that lists only some entries: tools can filter or elide individual features, so one diagram shows a selection of the model.
• Empty Compartment: The compartment label is displayed (e.g., parts) with nothing beneath it. That tells you no parts are displayed on this view. Whether the block truly has none is a fact about the model; confirm it in the model browser or an unfiltered view rather than inferring it from one diagram.

+-----------------------+     +-----------------------+
|        «block»        |     |        «block»        |
|       SensorA         |     |       SensorB         |
+-----------------------+     +-----------------------+
| values                |     | parts                 |
|   rate : Hz = 100     |     +-----------------------+
+-----------------------+     | values                |
                              |   rate : Hz = 100     |
                              +-----------------------+
(parts compartment is         (parts compartment is EMPTY:
 SUPPRESSED: no inference      no parts are displayed
 about parts is possible)      on this view)

---

6. Structural Features vs. Behavioral Features

Features belonging to a block are classified into two broad categories:

Structural Features (Properties)

Structural features specify the composition, internal state, and connectivity of a block. In the SysML metamodel, these are all subclasses of Property:

• Part Properties: Owned components (composite aggregation).
• Reference Properties: External connections or shared elements (shared aggregation or association).
• Value Properties: Quantifiable parameters or states typed by «valueType».
• Constraint Properties: Mathematical relationships typed by constraint blocks.
• Port Properties: Interaction points on the block boundary (standard ports and flow ports).

Behavioral Features

Behavioral features specify the dynamic capabilities and reactive behaviors of the block:

• Operations: Callable functions with formal parameters and return values. When invoked, an operation executes an associated method (such as an Activity, State Machine, or Interaction).
• Receptions: Declarations of readiness to accept asynchronous signals. When a signal arrives, the reception triggers an event in the block's state machine or activity.

---

7. Compartment Reference Matrix

---

8. Common OCSMP Exam Traps & Pitfalls

1. Operation vs. Activity Trap: An operation listed in a block's operations compartment is a behavioral feature signature (name, parameters, return type). It is not an Activity or Action. An Activity can provide the method that implements the operation, but the operation itself is merely the interface contract.
2. Suppression Trap: Never conclude that a block has no value properties or parts simply because the compartment does not appear on a BDD. Compartments are routinely suppressed or filtered for visual clarity, so a missing compartment tells you nothing about the model.
3. Reference vs. Part Property Trap: Exam questions often show a block with entries in both the parts and references compartments. Remember that deleting an instance of the block will delete all elements listed under parts, but leaves elements under references completely intact.
4. Block Definition vs. Instance Trap: A block on a BDD represents a reusable classifier, not a single physical hardware instance. To represent a specific physical component in an assembly, you must declare a block usage (a property typed by that block).