WARNING: advanced topic: includes detailed analysis of a complex diagram with many issues
There are many difficulties representing the original SysML1.0 spec figure 11.10 in MD SysML 15, including:
- MD SysML15 can't draw object flows from the the fork to the action :Braking,
I have used control flows as a workaround for now. (One definitely should be able to have object flows into and out of a fork and/or join in UML2.1.1, as long as one does not mix object and control flows.) - One can't easily show the {stream} from :Driving to :BrakePressure indicating that the parameter has 'isStream=true' without a Pin (indeed the spec Figure is inconsistent in this matter, the examples in Table 11.1 - Graphical nodes included in activity diagrams under UML4SysML::Parameter.isStream shows actions with Pins and {stream}).
I recommend that you ALWAYS use typed Pins in these situations; see the examples in green in the images below using Pins typed by 'BrakePressure' and expressing the 'isStream=true' condition of the underlying Parameter using the {stream} notation.
Another problem is that the default concrete object node in MagicDraw is a CentralBufferNode, which should not be related directly to an Action. However, the UML2.1.1 spec is inconsistent on this matter:
12.3.38 ObjectNode (from BasicActivities, CompleteActivities)
An object node is an abstract activity node that is part of defining object flow in an activity.
12.3.16 CentralBufferNode (from IntermediateActivities)
A central buffer node is an object node for managing flows from multiple sources and destinations. A central buffer node accepts tokens from upstream object nodes and passes them along to downstream object nodes. They act as a buffer for multiple in flows and out flows from other object nodes. They do not connect directly to actions.
The UML2.1.1 does not provide a sensible concrete ObjectNode for participation in flows, which is a major problem for tool vendors. Once again, using typed Pins solves this problem in MD15, too, for when using Pins there is no need to incorrectly assume a CentralBufferNode. I also consider using Pins a cleaner notation than ObjectNodes managed by two object flows to and from the ObjectNode.
Why doesn't the spec figure show a typed Pin with control
tokens flowing out of the <<controlOperator>> ? The spec in fact asserts that such a <<controlOperator>> must have at least one Parameter of type ControlData (being part of the activities ModelLibrary):
11.3.2.2 ControlOperator
..
Constraints
[1] When the «controlOperator» stereotype is applied, the behavior or operation must have at least one parameter typed by ControlValue.
If the stereotype is not applied, the behavior or operation may not have any parameter typed by ControlValue.
Since <<controlOperator>> is applied to ':Enable on Brake Pressure > 0' its Behavior should have an output Parameter typed by ControlValue, so it makes good sense for it to also have an output Pin corresponding to that ControlValue output Parameter (as shown in green as an alternative). By contrast, since the controlled Action ':Monitor Traction' does not have the <<controlOperator>> applied its Behavior may not have an input Parameter of type ControlValue, and so it may not have a Pin of type ControlValue.
Please visit also my "improved" version of the Figure 11.10 using Pins whereever possible.
WARNING: the SysML1.0 spec figure notation for actions typed by activities is confusing, use instead anonymous CallBehaviorActions as I have done here.
