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

This content has been marked as discussing an ADVANCED topic!
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:

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:

Note also that: 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:

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:

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:

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
Snippets (quotes/extracts)
Visit also
Visit also (backlinks)
Related slides (other tutorials)
Related slides (other tutorials, backlinks)