SysML/UML: MagicDraw/Cameo: Activity Diagrams: All Pins of CallBehaviorActions and CallOperationActions MUST be displayed (synchronised). All ActivityParameterNodes MUST be shown on the frame of an Activity Diagram.

Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
Policy level
UML keywords
SysMLv1.x keywords
Keywords
Click on the image to view it full size

The active validation engine of MagicDraw® UML, MagicDraw SysML Plugin, and Magic Model Analyst® (Cameo Simulation Toolkit®) is powerful, and can guide you during your modelling. It is particularly useful when dealing with Parameters of Activities and ActivityParameterNodes.

In the model browser view at the top left the OuterActivity has Parameters 'i1', 'i2', 'o1', but only one ActivityParameterNode 'i' (which is bound to Parameter 'i1' but happens to have a different name). The InnerActivity has Parameters 'i1', 'i2', 'o1' and 'o2', but no ActivityParameterNodes at all.

In a Package Diagram showing the Activities (with their owned parameters showing in element properties compartments), the MagicDraw/Cameo validation engine fires, and gives a warning about the incorrect synchronisation of the Parameters and ActivityParameterNodes on each Activity and offers an actions to fix them, which are accepted (it was decided to synchronise the ActivityParameterNodes against the Parameters).

We can than see that the matching ActivityParameterNodes have been created, and as a side-effect (welcome in this case), the name of the ActivityParameterNode for Parameter 'i1' in OuterActivity has been changed to 'i1' to match its parameter.

On the initial Activity Diagram for OuterActivity, not all Pins are showing on the CallBehaviorAction :InnerActivity, the symbol for the OutputPin for 'o2' is missing. Once again the MagicDraw/Cameo validation engine fires, and offers a fix action, which is accepted. The symbol for the OutputPin for 'o2' then correctly appears.

In some cases some of the input Parameters for an Activity may be considered optional. However, the InputPins corresponding to those Pins must still be displaying on each usage as a CallBehaviorAction in client Activity Diagrams. In such cases, you can use symbol properties (such as using grey pen style or grey fill) to indicate that it is not intended that a displayed optional InputPin be connected in a particular usage context. Or you can use custom stereotypes to indicate that they are optional.

Note also that:

If you delete (or un-display) an ActivityParameterNode symbol on the frame of an ActivityDiagram is removes the ActivityParameterNode AND the corresponding Parameter from the underlying model of the Activity context
Relates to
Related notes
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)