Allocation of a CallBehaviorActionAction to a PartProperty via an AllocateActivityPartition "swimlane"

AllocateActivityPartition "swimlanes" in Activity Diagrams are an easy way to manage "classic" functional (a.k.a. behavioral) allocation of a CallBehaviorAction to a part Property:

Click on the image to view it full size

A consistent usage level allocation has been made in the tool between the CallBehaviorAction action (of type Activity) to the part Property part:PartType, which is represented by the «allocate» swimlane.

Note that these are not any old UML ActivityPartition swimlanes, these SysML-specific ones that appear with the «allocate» keyword, and they have different semantics:

SysML-1.6: 'AllocateActivityPartition::2_not_uml_semantics ... Classifiers or Properties represented by an «AllocateActivityPartition» do not have any direct responsibility for invoking behavior depicted within the partition boundaries. ...'

Unless you override it in the tool (which you can do easily using a context menu item) it's the default swimlane type:

MagicDraw/Cameo: The default swimlanes in SysML Activity Diagrams are AllocateActivityPartition swimlanes with the «allocate» keyword applied.

Usually, the swimlane technique shown here for Actions in Activity Diagrams - and the direct «allocate» approach in BDDs - are sufficient for functional (behavioral) allocation in SysML:

Webel Best Practice: By all means use ActivityAllocatePartition swimlanes for CallBehaviorAction allocation in usage allocation mode, but use BDDs for your definition-level allocations with directly drawn «allocate» relationships between Activity and Block symbols.

Please do always heed this warning:

Webel Best Practice: AVOID "mixed" functional (behavioral) allocation levels! DO NOT Allocate from Usage level (Action) to Definition level (Block) or from Definition level (Activity) to usage level (part Property) - even if formally permitted in SysML.

If you are curious about some edge cases for allocations using swimlanes (and why they should be avoided) some are explored in some advanced slides later in this trail section.

While functional (behavioral) allocation is perhaps the best known use of allocation in "classic" systems engineering, it is not the only kind, and also not the only very useful kind; in the next slide we have a quick look at structural allocation in SysML, before learning how we can examine allocations across an entire model using interactive tables and matrices in the tool.

BTW: The Dependency 'typed by' from the part:PartType to the block PartType is for illustration only.

Up next

Structural Allocation: USB - Progressive refinement using Allocations

Notes

[POLICY, WARNING]{STRICT} AVOID "mixed" functional (behavioral) allocation levels! DO NOT Allocate from Usage level (Action) to Definition level (Block) or from Definition level (Activity) to usage level (part Property) - even if formally permitted in SysML.

[ISSUE, TOOL] MagicDraw/Cameo 19SP3: The property path in callout does always correspond to the SysML spec examples.

[TIP]{STRONG} By all means use ActivityAllocatePartition swimlanes for CallBehaviorAction allocation in usage allocation mode, but use BDDs for your definition-level allocations with directly drawn «allocate» relationships between Activity and Block symbols.

[DISPLAY, FEATURE, TOOL] MagicDraw/Cameo: The default swimlanes in SysML Activity Diagrams are AllocateActivityPartition swimlanes with the «allocate» keyword applied.

Snippets (quotes/extracts)

[SysML-1.6] AllocateActivityPartition is used to depict an «allocate» relationship on an Activity diagram. The AllocateActivityPartition is a standard UML::ActivityPartition, with modified constraints...

[SysML-1.6] Note that the AllocateActivityPartition, if used in this manner, is unambiguously associated with behavior allocation.

[SysML-1.6] Allocate is a dependency based on UML::Abstraction. It is a mechanism for associating elements of different types, or in different hierarchies, at an abstract level. Allocate is used for assessing user model consistency and directing future design ...