Allocation relationships
Allocation tests how you record the mapping between model elements, most often from behavior to structure and from logical to physical design. Expect questions on the «allocate» dependency, on what allocation does and does not mean, and on allocation tables.
The allocate dependency
«allocate» is a dependency, and it can relate almost any pair of model elements. Conventionally the arrow runs from the allocated element to the element that realizes it: an action or activity to a block, a state machine to a block, a logical block to a physical block, software to hardware. It is a mapping, not ownership.
What allocation adds and does not add
Allocation adds a traceable mapping and enables gap checks, such as every action having an allocator. It never moves, copies or deletes elements, and it carries no execution semantics: a block does not run an activity because of an allocation.
Presentation
SysML allows allocation compartments (allocatedFrom, allocatedTo), allocation tables and matrices, and an allocated property on activity partitions. Tables are the practical way to review coverage across dozens of elements.
Levels and refinement
Keep allocations at one consistent level of abstraction, then refine with sub-allocations. Allocating a whole activity to one block while its actions belong to different components hides interface problems.
Verification of the allocation
Check both directions: every allocated element has exactly one owning allocator at its level, and every allocator knows what it carries. Unallocated actions are functional gaps; allocated elements with no defining behavior are unused capacity.
Worked example
Activity Navigate has actions ReadGPS, ComputeCourse and CommandActuators. ReadGPS and CommandActuators are allocated to NavigationUnit, ComputeCourse to FlightController. An allocation table exposes that ReadGPS also appears allocated to MissionComputer, a conflict to resolve before design review.
Traps
Using allocate where «satisfy» is meant, expecting allocation to move elements, allocating a whole activity when its actions belong to different blocks, assuming allocation has runtime meaning, and ignoring the direction of the dependency.