Study guide
10.2 Allocation Representations: Callouts, Compartments, Partitions & Tables
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
10.2 Allocation Representations: Callouts, Compartments, Partitions & Tables
Key Takeaways Explain This Topic AI
SysML shows one underlying «allocate» dependency in several ways: dependency arrows, allocatedFrom/allocatedTo compartments, callout notes, «allocate» activity partitions, and tables.
All of these notations display the same «allocate» dependency and its derived allocatedTo and allocatedFrom properties; switching notation changes only the picture.
Compartment notation renders allocatedFrom and allocatedTo compartments directly inside block or part boundary rectangles, displaying allocated elements textually without cluttering diagrams with crossing lines.
Callout notation is a note anchored to an element that lists allocatedFrom and/or allocatedTo entries written as «elementType» ElementName.
A partition labeled «allocate» makes each action inside it the client of an «allocate» to the partition's element; plain partitions do not create allocations.
Last updated: September 2026
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
Orphan Function Detection: Any row without a mark represents an unallocated action—a function that has no physical component assigned to execute it.
Underutilized Hardware Identification: Any column without marks indicates a physical component with no functional responsibilities assigned to it.
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:
Dependency Arrow ( bdd ): A dashed arrow labeled «allocate» originates at ComputeAttitudeError and terminates at AvionicsController .
Compartment ( bdd ): The AvionicsController block displays an allocatedFrom compartment containing ComputeAttitudeError .
Callout Note ( act ): Next to the action ComputeAttitudeError , a note box states allocatedTo: AvionicsController , anchored by a dashed line.
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
Representation Format Graphical Syntax Applicable Diagram Kinds Primary Readability Strength Main Limitation
Explicit Dependency Arrow Dashed line with open stick arrowhead and «allocate» bdd , ibd , act , pkg Explicit, intuitive visual connection across separate shapes. Severe clutter and crossing lines on dense diagrams.
Compartment Notation allocatedFrom / allocatedTo compartments inside a block, part, or action bdd , ibd , act Zero crossing lines; compact; maintains clean modular layout. Requires inspecting inside block shapes; does not show spatial topology.
Callout Notation Dog-eared note with allocatedTo: or allocatedFrom: via dashed anchor line All SysML diagrams ( act , ibd , bdd , stm ) Localized clarity; avoids routing long arrows across canvas. Can obscure adjacent diagram elements if many callouts are placed.
Allocate Activity Partition Swimlane whose label carries «allocate» act (Activity Diagrams) Directly integrates functional sequence flows with structural ownership. Restricted strictly to Activity Diagrams; cannot be used on BDDs or IBDs.
Allocation Matrix (Table) Cross-tabular matrix with client rows and supplier columns Tabular views / Model browser Comprehensive, 100% auditability; detects orphan elements easily. Lacks visual architectural context and flow sequence information.
Exam Pitfalls & Misconceptions
Concept Correct SysML Rule Common Exam Trap / Distractor
Swimlane Metamodel Effect Placing an action in a partition labeled «allocate» establishes an «allocate» dependency to the partition's element. Believing swimlanes create UML composition, ownership, or aggregation between block and action.
Callout vs Comment Callout allocation is formal syntax for «allocate» , not an informal user comment. Confusing an allocation callout note with an unstereotyped UML descriptive note.
Notational Semantic Parity All four notations have identical semantic meaning in the underlying model repository. Claiming that explicit dependency arrows are "stronger" or "more binding" than compartment notation.
Compartment Naming The compartment titles must be strictly allocatedFrom or allocatedTo . Using incorrect names such as allocations , assignedBehavior , or hostedFunctions .
«allocate» Keyword Only partitions labeled «allocate» create allocations; a colon label ( part : Block ) designates a part, a simple name designates a block. Assuming every swimlane allocates its actions, or that the supplier is the block even when the label names a part.
Multi-Representation Sync Changes made in one notation (e.g., moving an action between swimlanes) automatically update all other views. Claiming that each diagram maintains independent, conflicting allocation records.