Tags and keywords
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:
myActivityIsAllocatedToBlock2- typed by an Activity
AllocateToBlock2- in a swimlane that represents a Block
AllocateActivityToMe2. The underlying Activity
AllocateToBlock2is allocated fine, but the action is left hanging without an allocation, consistent with the tool's definition allocation mode feature, but breaking this constraint:
If you run the tool's validation engine with the 'SysML ValSuite' it gives an info level message for the swimlane:
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:
The conclusion drawn here once again is:
But if you follow this reommendation you'll be just fine:
And it's also worth remembering this tip in case you do get your allocations in a twist: