MagicDraw/Cameo: ERROR: Incorrectly uses 2 ObjectFlow edges and a CentralBufferNode in place of "elided Pin notation" instead of an abstract ObjectNode symbol and 2 arrow symbols (that are supposed to represent together 2 Pins and 1 ObjectFlow edge)

This page identifies a possible issue, inconsistency, concern, error, or bug!
One of the ways Webel IT Australia helps promote tools, technologies, and languages is by donating a lot of time identifying, tracking, and reporting potential issues, in order to help vendors and developers improve the tools and technologies. In some cases, we also offer workarounds and advice for users. All issues tracked on our public site are offered most constructively and with sincerest gratitude to the tool vendors and technology developers.
DISCLAIMER: Vendors do not officially endorse issue analysis by Webel IT Australia.
Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
ISSUE
TOOL
UML keywords
Activity
Action
Pin
ActivityEdge
ObjectFlow
ObjectNode
CentralBufferNode
elided Pin notation
Keywords
Click on the image to view it full size
Figure 15.9 and Figure 16.6 elided Pin notations
On OMG copyright in text extracts and figures reproduced for educational purposes
Webel recommends when using MagicDraw/Cameo: AVOID the "elided Pin" abstract ObjectNode notation on Activity Diagrams, use explicit Pins!
Dr Darren says:
There are lots of things I love about MagicDraw® UML, the MagicDraw SysML Plugin, and Magic Cyber-Systems Engineer® (Cameo Systems Modeler®), it is my main professional tool of trade. This long-standing flaw is definitely not one of them.
In MagicDraw® UML or Magic Cyber-Systems Engineer ® (Cameo Systems Modeler®), if you select an "Object Node" (which has an abstract metaclass) from the Activity Diagram menu items and place it on the diagram it will create a «centralBuffer» node symbol, which is just plain wrong.

If you use the smart manipulator from an Action symbol to create an ObjectFlow and don't connect it up to another Action or an existing Pin on another Action, it creates an OutputPin, an ObjectFlow, and a «centralBuffer» node symbol, which is also just plain wrong.

The result is that you can end up with an extra ObjectFlow edge in the model and an unwanted and irrelevant CentralBufferNode and sometimes the wrong number of Pins

At least in version 19SP3, if you have an "ObjectFlow symbol" (there is in fact no such thing for elided Pin notation, there are only object node arrow symbols, see below) to a «centralBuffer» node directly from an Action that has a Pin it warns you that 'All pins that are created for this action must be displayed in the diagrams'. But that warning is itself also just plain wrong.

MagicDraw has never got this one right and probably never will

The notation as described in the UML specification is probably difficult to implement in a tool, but it is in fact quite clear (if somewhat strange):

UML-2.5.1: 'An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.'
The referenced Figure 15.9 ObjectFlow notations is reproduced here for convenience.

Note how it says (Webel's emphasis in bold) 'two object flow arrows denote a single object flow edge'. An object flow arrow is a notation symbol, it DOES NOT ALWAYS CORRESPOND ONE-TO-ONE TO A SINGLE ELEMENT IN THE MODEL!

Not convinced yet? More of the same from the spec:

UML-2.5.1: 'The situation in which the OutputPin of one Action is connected to the InputPin of the same name in another Action via an ObjectFlow may be shown by the optional notations of Figure 16.6.'
UML-2.5.1: 'The standalone Pin in the notation maps to an OutputPin and an InputPin and one ObjectFlow edge between them in the underlying model. This form should be avoided if the Pins are not of the same type.'
The referenced Figure 16.6 Standalone Pin notations is reproduced here for convenience.

And what the tool is doing contradicts this:

UML-2.5.1: 'no_executable_nodes ObjectFlows may not have ExecutableNodes at either end.'

[If you go from an InputPin to a compatible OutputPin, an object flow arrow corresponds one-to-one to an ObjectFlow edge in the model; MagicDraw/Cameo does get that case right.]

Relates to
Figure D.36 - Behavior Model for “Accelerate” Function (Activity Diagram) {ELIDED PINS}
Figure D.36 - Behavior Model for “Accelerate” Function (Activity Diagram) {EXPLICIT PINS}
Figure D.38 - Detailed Behavior Model for “Provide Power” {ELIDED PINS}
Figure 11-10: Continuous system example 1 {ELIDED PINS}
Figure 11-10: Continuous system example 1 {EXPLICIT PINS}
Figure 11-11: Continuous system example 2 {ELIDED PINS}
Figure 11-11: Continuous system example 2 {EXPLICIT PINS}
Figure 15-7: Example of flow allocation from ObjectNode to FlowProperty
AdjunctProperty for CallBehaviorAction and ObjectNode
Allocation matrix in the MagicDraw/Cameo tool
Allocation table in the MagicDraw/Cameo tool
uml101 - Activity Diagram - notation - REFERENCE CARD
ActivityPartitions using “swimlane” notation
Related notes
[DISPLAY, ISSUE, TOOL, WARNING] Webel recommends when using MagicDraw/Cameo: AVOID the "elided Pin" abstract ObjectNode notation on Activity Diagrams, use explicit Pins!
Related notes (backlinks)
Related snippets (extracts)
  [UML-2.5.1] An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.
  [UML-2.5.1] The situation in which the OutputPin of one Action is connected to the InputPin of the same name in another Action via an ObjectFlow may be shown by the optional notations of Figure 16.6.
  [UML-2.5.1] The standalone Pin in the notation maps to an OutputPin and an InputPin and one ObjectFlow edge between them in the underlying model. This form should be avoided if the Pins are not of the same type.
Visit also
Visit also (backlinks)