SysMLv1: MagicDraw/Cameo: Automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties of a Block. EXAMPLE: A UseCase scenario within a SystemContext as UseCase ‘subject’.

In the example shown, SC is a SystemContext that owns and is the 'subject' of a UseCase UC_SC. The SystemContext SC has part properties for the block-based «actor» and the SoI System (of Interest).

SysMLv1: MagicDraw/Cameo: Having a SystemContext as the 'subject' of each main UseCase plays nicely with the feature for automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties. But it's not the only way.

On creation of swimlanes the tool will prompt to create part properties for each allocation swimlane.

CAUTION: It’s up to you to check that the order is correct!

If you need to reorder them it's easy, just click on the header of a swimlane and little re-order arrows appears on each side.

One common convention is to have (here as part properties :User and :SoI) the actor on the left, and the System (or the relevant target) immediately right of that.

Make sure you have the Allocation Mode mode selected as :User mode under the Project Options for SysML, which you can check using the context menu under any swimlane.

Slight GOTCHA: If you instead have the the Allocation Mode set to Definition mode under the Project Options for SysML, the tool will assign part properties to the swimlanes, but the allocation mode for each swimlane will be Definition mode, which is a dis-connect.

That is easily fixed using the context menu on any swimlane (the change will apply to all swimlanes).

The automated part property allocation feature works for any Block, not just a SystemContext; it's up to you to manage the relationship to any UseCase and what its 'subject' is. The MagicGrid approach is to use a particular SystemContext as the 'subject' of each top- level UseCase, which is a good fit for this tool feature and works well with the part properties of the IBD for that SystemContext.

Please visit also:

Webel: SysML for MBSE: The frequent recommendation that each UseCase have at least one "primary" scenario is a very useful and highly recommended CONVENTION (only). But it is not actually enforced by the SysML1.7 or UML2.5.1 metamodels or specifications.

SysMLv1: UseCase scenario representations: On use of Activity Diagrams with swimlanes and/or Sequence Diagrams (Interactions): Actor or block-based custom «actor» on 1st (typically left) Lifeline/Swimlane, System/Subsystem on 2nd Lifeline/Swimlane

SysMLv1: MagicDraw/Cameo: INTRINSIC GOTCHA: Care must be taken with ownership of Activities used as UseCase scenarios vs the ‘subject’ of the UseCase. Make sure you don’t get an Activity ‘context’ mismatch! It's up to you to manage it as intended.

And a wider related discussion:

SysMLv1: "Should" the 'subject' of a top-level UseCase be a System or (a particular) SystemContext? Answer: Which one would you like to be correct!? [WITH EXTERNAL LINKS]

Relates to

SysML/MBSE: Cameo/MagicDraw: MagicGrid® and the MagicGrid® Book of Knowledge: A pragmatic review of some selected aspects by Dr Darren of Webel IT Australia

Webel SE: pragmatic tool-friendly functional analysis: 2-level drill-down from a single Use Case via a «scenario» Activity with allocation to «logical» subsystems first then crossing to the «design» Blocks zone.

Related notes