Allocation via swimlanes in definition 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 AND that you have read all of the previous slide page about usage allocation mode.

We now look at what happens if one tries to combine (misuse) CallBehaviorActions in swimlanes in Activity Diagrams with definition 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) has a CallBehaviorAction myActivityIsAllocatedToBlock2 - typed by an Activity AllocateToBlock2 - in a swimlane that represents a Block AllocateActivityToMe2. The underlying Activity AllocateToBlock2 is allocated fine, but the action is left hanging without an allocation, consistent with the tool's definition allocation mode feature, but breaking this constraint:

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 ...'

If you run the tool's validation engine with the 'SysML ValSuite' it gives an info level message for the swimlane:

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

And for the CallBehaviorAction it gives something like that above constraint as an 'info' level message.

Similarly for 2nd swimlane column with the CallBehaviorAction actionAllocatedToBlock typed by an Activity AllocateUsageToBlock2. No sneaky "manual" allocation to the Block AllocateActionToMe2 represented by the swimlane has inappropriately been attempted here, it's just showing what the tool (sensibly enough) does. Once again, that constraint above is broken (and the validation engine reports it at info level).

But from the point of view of the BDD, everything is all "happy campers" again. And if you use Display > Display All Paths on the «activity» symbols the tool will nicely draw the «allocate» relationships for you that were generated behind the scenes in the Activity Diagram using ActivityAllocatePartition swimlanes.

What the tool is doing is perfectly consistent for the 2 modes it offers - usage allocation mode and definition allocation mode - it just does not support "mixed" modes, which is probably a good idea:

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.

The conclusion drawn here once again 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 if you follow this reommendation you'll be just fine:

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.

And it's also worth remembering this tip in case you do get your allocations in a twist:

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.

Up next

16:01: Requirements engineering in SysML

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.

[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.