Allocation via swimlanes in usage allocation mode - DOs and DON'Ts

It is assumed here that you have already understood the basic Activity to Block (definition level) and CallBehaviorAction to part Property (usage level) allocations.

The following specification constraint suggests that the AllocateActivityPartition mechanism in Activity Diagrams should only be used for usage-level allocations:

SysML-1.6: 'AllocateActivityPartition::1_actions_on_client_ends An Action appearing in an "AllocateActivityPartition" shall be the /client (from) end of an "allocate" dependency. The element that represents the "AllocateActivityPartition" shall be the /supplier ...'

But an ActivityPartition (including an AllocateActivityPartition) swimlane may represent a Classifier (definition level, such as a Block), and the tool optionally supports definition level allocations via swimlanes, so one has to be very careful using the feature:

MagicDraw/Cameo: One can choose between 'usage' level or 'definition' level allocation modes on AllocateActivityPartition swimlanes. The setting always applies to all AllocateActivityPartition items in one Activity Diagram at once.

Note also that:

MagicDraw/Cameo: In SysML Activity Diagrams you can only set the allocation mode in to 'usage' or 'definition' for an entire AllocateActivityPartition group at once, not for individual AllocateActivityPartition columns or rows.

This likely corresponds to most users' expectations, but it does mean things can get out of sync (even with validation engine support).

Here we look at some DOs and DON'Ts when working with CallBehaviorAction in swimlanes in Activity Diagrams. First, we look at some cases when under usage allocation mode, including some "pathological" cases that have been provoked:

Click on the image to view it full size

The case on the left (the 1st swimlane column) is the only way Webel recommends using AllocateActivityPartition with swimlanes in Activity Diagrams (and in usage allocation mode). A CallBehaviorAction actionAllocatedToPart typed by an Activity AllocateUsageToPart has been allocated to a part Property part:AllocateToMyInstance, which happens to be within a Block AllocateToMyPart. Note that the underlying Activity AllocateToMyInstance is NOT allocated; happy campers.

If you've been following this trail you'll of course already have taken this advice to heart:

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.

Let's ignore it anyway just for a moment and see what a mess we can get into. The action actionAllocatedToBlock1 - typed by Activity AllocateUsageToBlock1 - in the 2nd swimlane column (in the middle) appears visually in an ActivityAllocatePartition, so according to the following constraint it "should" be allocated to something:

But the swimlane represents a block AllocateActionToMe1, which usage allocation mode can't handle. An allocation has nevertheless been HACKED in "manually" here using this otherwise nice tool feature:

MagicDraw/Cameo: You can allocate an Action to any NamedElement in the model via its specification box under the Allocations section by dragging and dropping an element (such as a part Property) from the model browser onto the Allocate To field.

But instead of using a nice part Property, an allocation to the block AllocateActionToMe1 was made. Yuck!

From the point of view of the BDD, the next case looks fine; there is a direct «allocate» from Activity AllocateToBlock1 to Block AllocateActivityToMe1. But look at the action myActivityIsAllocatedToBlock1 - typed by Activity AllocateToBlock1 in the 3rd swimlane column;it is not allocated to anything, once again breaking the above constraint.

If you run the tool's validation engine with the 'SysML ValSuite' it gives an info level message for both the 2nd and 3rd swimlanes:

'The represented element of the activity partition which are applied with «AllocateActivityPartition» stereotype, should be the Property'

The conclusion drawn here is:

SysML-1.6: The constraint that ''An Action appearing in an “AllocateActivityPartition” shall be the /client (from) end of an “allocate” dependency.' is not compatible with all Activity Diagram swimlane configurations.

But since breaking things is so much fun and a great way to learn stuff, we'll see next whether we can get into an even deeper mess using definition allocation mode.

Up next

Allocation via swimlanes in definition allocation mode - DOs and DON'Ts

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.

[CAVEAT, FEATURE, TOOL, WARNING] MagicDraw/Cameo: In SysML Activity Diagrams you can only set the allocation mode in to 'usage' or 'definition' for an entire AllocateActivityPartition group at once, not for individual AllocateActivityPartition columns or rows.

[CAPABILITY, FEATURE, TOOL] MagicDraw/Cameo: One can choose between 'usage' level or 'definition' level allocation modes on AllocateActivityPartition swimlanes. The setting always applies to all AllocateActivityPartition items in one Activity Diagram at once.

[ISSUE] SysML-1.6: The constraint that ''An Action appearing in an “AllocateActivityPartition” shall be the /client (from) end of an “allocate” dependency.' is not compatible with all Activity Diagram swimlane configurations.

[FEATURE, TIP, TOOL] MagicDraw/Cameo: You can allocate an Action to any NamedElement in the model via its specification box under the Allocations section by dragging and dropping an element (such as a part Property) from the model browser onto the Allocate To field.

[TIP] MagicDraw/Cameo: If you remove a CallBehaviorAction from an ActivityAllocatePartition swimlane any previously created allocations won't be removed, but you can delete them using the Allocations section of the Specification dialog of any relevant element.

Snippets (quotes/extracts)

[SysML-1.6] AllocateActivityPartition::1_actions_on_client_ends An Action appearing in an "AllocateActivityPartition" shall be the /client (from) end of an "allocate" dependency. The element that represents the "AllocateActivityPartition" shall be the /supplier ...