10.2 Allocation Representations: Callouts, Compartments, Partitions & Tables

10.2 Allocation Representations: Callouts, Compartments, Partitions & Tables

Quick Reference: SysML allows systems engineers to represent the exact same underlying «allocate» dependency using four canonical visual notations: (1) Explicit Dependency Arrow (dashed line with «allocate»), (2) Compartment Notation (allocatedFrom and allocatedTo compartments inside block/part symbols), (3) Callout Notation (dog-eared note box displaying allocatedTo: or allocatedFrom:), and (4) Allocate Activity Partitions (swimlanes whose label carries the keyword «allocate»). In addition, Allocation Tables/Matrices present these mappings in tabular format. All notations are semantically identical in the model repository.

---

The Principle of Notational Equivalence in SysML

One of the most powerful design principles in SysML is the separation of abstract syntax (the underlying model repository graph) from concrete syntax (the visual diagrams rendered on the screen or page). An «allocate» relationship is a unique element in the model repository consisting of a client and a supplier; the elements at each end display it through the derived properties allocatedTo and allocatedFrom.

Because systems engineering models span dozens of subsystems, hundreds of components, and thousands of operations, drawing explicit dependency lines between every action and every block quickly produces illegible "spaghetti diagrams." To preserve visual clarity while maintaining rigorous model traceability, SysML provides four distinct graphical representations for the allocation dependency.

Core Rule: Switching between dependency arrows, compartments, callouts, and activity partitions changes only the visual presentation on the diagram canvas. It does not alter the underlying model semantics, nor does it create redundant dependencies in the model repository.

---

The Four Canonical Visual Notations

+---------------------------------------------------------------------------------------+
|                                 SysML ALLOCATION NOTATIONS                            |
+---------------------------------------------------------------------------------------+
| 1. Dependency Arrow:    [Action] - - - «allocate» - - - > [Block]                     |
+---------------------------------------------------------------------------------------+
| 2. Compartment:         +-------------------------+                                   |
|                         |     «block» Avionics    |                                   |
|                         +-------------------------+                                   |
|                         | allocatedFrom           |                                   |
|                         |   ComputeTrajectory     |                                   |
|                         +-------------------------+                                   |
+---------------------------------------------------------------------------------------+
| 3. Callout Note:        +-------------------------+      +--------------------------+ |
|                         |  «action» ComputeTraj   |- - - | allocatedTo:             | |
|                         +-------------------------+      |   AvionicsProcessor      | |
|                                                          +--------------------------+ |
+---------------------------------------------------------------------------------------+
| 4. Activity Partition:  +-----------------------------------------------------------+ |
|    (Swimlane)           |         «allocate» adcs : ADCS_Computer                   | |
|                         |  +-----------------------+     +-----------------------+  | |
|                         |  | ComputeAttitudeError  | --> | FireReactionThruster  |  | |
|                         |  +-----------------------+     +-----------------------+  | |
|                         +-----------------------------------------------------------+ |
+---------------------------------------------------------------------------------------+

1. Explicit Dependency Arrow Notation

• Visual Syntax: A dashed line with an open stick arrowhead bearing the stereotype keyword «allocate». The arrow points from the client (allocated element) to the supplier (target host element).
• Applicable Diagrams: Block Definition Diagrams (bdd), Internal Block Diagrams (ibd), Activity Diagrams (act), and Package Diagrams (pkg).
• Advantages: Unambiguous, highly intuitive visual path; immediately highlights cross-domain dependencies.
• Limitations: Causes visual clutter and line crossings when many elements participate in allocations on the same diagram.

2. Compartment Notation

• Visual Syntax: Dedicated rectangular compartments embedded directly inside the shape boundary of a block, part, or action:
  • allocatedFrom compartment: Displayed inside a supplier host (e.g., a Block). Contains a bulleted or comma-separated list of client elements that have been allocated to this host.
  • allocatedTo compartment: Displayed inside a client element (e.g., an Action or Logical Block). Contains a list of supplier elements to which this client has been allocated.
• Entry Format: Entries are written without braces as «elementType» ElementName (e.g., «activity» ComputeTrajectory); the element type may be elided for brevity.
• Applicable Diagrams: Block Definition Diagrams (bdd, on blocks), Internal Block Diagrams (ibd, on parts), and Activity Diagrams (act, on actions).
• Advantages: Eliminates all crossing lines; keeps structural and behavioral views neatly organized within the respective element symbols.
• Exam Detail: The compartment label must be precisely allocatedFrom or allocatedTo. Synonyms such as allocations, assignedFrom, or hosts are non-standard and invalid on the certification exam.

3. Callout Notation

• Visual Syntax: A standard note symbol (a rectangle with a dog-eared upper-right corner) connected to the target model element by a dashed line without arrowheads (an anchor line).
• Internal Content: The body of the note box displays an explicit text string:
  • allocatedTo followed by entries such as «block» HostElementName (when attached to a client element)
  • allocatedFrom followed by entries such as «activity» ClientElementName (when attached to a supplier host element)
• Metamodel Distinction: Although callout notation visually resembles a standard UML comment, it is not an informal comment. In SysML, the callout displays the derived allocatedTo / allocatedFrom values of an existing «allocate» dependency. It is a view of a real model relationship, not a free-text remark.
• Applicable Diagrams: Any SysML diagram kind, especially useful on Activity Diagrams (act) and Internal Block Diagrams (ibd) where drawing dependency arrows across subsystem boundaries would degrade legibility.

4. Allocate Activity Partitions (Swimlanes)

• Visual Syntax: An activity partition (swimlane) whose label shows the keyword «allocate», SysML's short keyword for the AllocateActivityPartition stereotype.
• Element Binding: A label with a colon (partName : BlockName or :BlockName) designates a part property; a simple name (BlockName) designates the block itself.
• Allocation Semantics: Each action inside an «allocate» partition is the client of an «allocate» dependency whose supplier is the partition's element. A plain partition without the keyword shows UML responsibility, not allocation.
• Multi-Dimensional Partitions: SysML supports two-dimensional grids (e.g., horizontal rows representing physical location and vertical columns representing subsystem blocks). In a two-dimensional grid, an action at an intersection lies in both partitions; only partitions marked «allocate» imply allocation.
• Underlying Mechanism: When an action is dragged into an allocate partition in an MBSE authoring tool, the tool automatically instantiates an «allocate» dependency from that Action to the partition's classifier and populates allocatedTo / allocatedFrom.

---

Tabular Representation: Allocation Matrices & Tables

While graphical diagrams provide spatial intuition, systems engineering verification and audit gates require exhaustive, comprehensive mapping validation. For this reason, SysML 1.2 lets allocations be shown in tables: "A separate row is provided for each «allocate» dependency. 'from' is the client of the «allocate» dependency, and 'to' is the supplier," and both the element type and element name appear for each end. Tools also offer the same data as a matrix.

Structure of an Allocation Matrix

• Row Axis (Left): Lists all client elements (e.g., every Action in a functional decomposition, or every Logical Block).
• Column Axis (Top): Lists all supplier host elements (e.g., every physical subsystem, processor, or assembly).
• Intersection Cells: Marked with a checkmark (✓), X, or the keyword «allocate» to indicate an active allocation dependency between that row and column.

Systems Engineering Value

1. Orphan Function Detection: Any row without a mark represents an unallocated action—a function that has no physical component assigned to execute it.
2. Underutilized Hardware Identification: Any column without marks indicates a physical component with no functional responsibilities assigned to it.
3. Redundancy & Overload Auditing: Highlights whether safety-critical functions are concentrated in a single processor (single point of failure) or properly distributed across redundant hardware.

Allocation table (one row per «allocate» dependency):
+-----------+---------------------------+----------+---------------------------+
| from type | from name                 | to type  | to name                   |
+-----------+---------------------------+----------+---------------------------+
| «action»  | AcquireSensorData         | «part»   | sensorSuite : SensorSuite |
| «action»  | FilterIMUBias             | «part»   | fc : FlightComputer       |
| «action»  | ComputeAttitudeTrajectory | «part»   | fc : FlightComputer       |
| «action»  | ModulateThrusterDutyCycle | «part»   | fc : FlightComputer       |
| «action»  | FireReactionThruster      | «part»   | thrusters : ThrusterPack  |
+-----------+---------------------------+----------+---------------------------+

Allocation matrix (tool view of the same data):
+---------------------------+-------------+-----+-----------+
| client \ supplier         | sensorSuite | fc  | thrusters |
+---------------------------+-------------+-----+-----------+
| AcquireSensorData         |      X      |     |           |
| FilterIMUBias             |             |  X  |           |
| ComputeAttitudeTrajectory |             |  X  |           |
| ModulateThrusterDutyCycle |             |  X  |           |
| FireReactionThruster      |             |     |     X     |
+---------------------------+-------------+-----+-----------+

---

Worked Real-World Example: Satellite Attitude Control Subsystem

Consider the allocation of spacecraft attitude control behavior across different notations:

• Behavioral Action: ComputeAttitudeError
• Structural Block: AvionicsController

Here is how the exact same relationship is represented across the four notations:

1. Dependency Arrow (bdd): A dashed arrow labeled «allocate» originates at ComputeAttitudeError and terminates at AvionicsController.
2. Compartment (bdd): The AvionicsController block displays an allocatedFrom compartment containing ComputeAttitudeError.
3. Callout Note (act): Next to the action ComputeAttitudeError, a note box states allocatedTo: AvionicsController, anchored by a dashed line.
4. Swimlane (act): The action ComputeAttitudeError is placed inside an activity partition labeled «allocate» over the simple name AvionicsController (a simple name designates the block itself).

If an engineer alters the allocation by moving the action into a different «allocate» partition (thrusterController), the tool automatically updates the block's allocatedFrom compartment and the callout note text. All notations reflect the identical underlying repository model.

---

Comparison of SysML Allocation Representations

---

Exam Pitfalls & Misconceptions