SYSML17 — Inconsistent incoming ObjectFlow and outgoing ControlFlows on the DecisionNode in Figure 11.12 - Continuous system example 3 'Enable on Brake Pressure > 0'

The 'Figure 11.12 - Continuous system example 3' for the Activity 'Enable on Brake Pressure > 0' shows a single incoming ObjectFlow from the ActivityParameterNode pressure : Brake Pressure to a DecisionNode with two outgoing ControlFlows (shown dashed) with guards vs Brake Pressure.

It is not indicated whether the incoming ObjectFlow is a DecisionNode::decisionInputFlow. Assuming it is or is not both lead to contradictions vs the UML-2.5.1 spec.

First, assume that is it not a decisionInputFlow. Then according to UML-2.5.1 it is then the primary incoming edge:

A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge. If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge.

But this means the reported figure immediately contradicts:

If the primary incoming edge of a DecisionNode is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows.

Because in the reported figure clearly there is a mix of a single incoming ObjectFlow and 2 outgoing ControlFlows.

Let us then instead assume that the incoming ObjectFlow is a decisionInputFlow. The UML spec then seems to require that there be an additional ControlFlow (that is not present in the reported figure).

Some related UML-2.5.1 spec quotes and constraints:

edges
The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows.

incoming_outgoing_edges
A DecisionNode has one or two incoming ActivityEdges and at least one outgoing ActivityEdge.

decisionInputFlow : ObjectFlow [0..1] (opposite A_decisionInputFlow_decisionNode::decisionNode)
An additional ActivityEdge incoming to the DecisionNode that provides a decision input value for the guards ValueSpecifications on ActivityEdges outgoing from the DecisionNode.

If the primary incoming edge of a DecisionNode is an ObjectFlow, and the DecisionNode does not have a decisionInput or decisionInputFlow, then the value contained in an incoming object token may be used in the evaluation of the guards on outgoing ObjectFlows.

This is clearly not consistent with the reported figure, which has outgoing ControlFlows.

The following seems to imply that decisionInputFlow is always accompanied by another incoming edge, but this is not (as far as I can tell) made explicit elsewhere as a constraint:

If a DecisionNode has a decisionInputFlow, then a token must be offered on both the primary incoming edge and the decisionInputFlow before the token from the primary incoming edge is offered to the outgoing edges.

[ASIDE: The UML-2.5.1 might be inconsistent when referring to 'incoming' w.r.t. decisionInputFlow (but this does not explain away the inconsistency in the reported SysML spec figure). The DecisionNode::decisionInputFlow does not subset ActivityNode::incoming:ActivityEdge[0..*], but it is sometimes referred to as an incoming edge.]

An additional consideration is why outgoing ControlFlows are being used in the first place. The UML-2.5.1 does not seem to explicitly reject the use of incoming ObjectFlows on a ValueSpecification (although at least one tools declares InputPins on them to be invalid). It is not clear to this reporter that ObjectFlows with Probability could not be used to activate the ValueSpecifications for enable/disable (even though the reported spec figure for this version seems to have been changed to used dashed-line ControlFlows, compared with previous SysML spec versions).

[EDIT:DK: Axel explained: 'ValueSpecificationActions can in fact have no InputPins (the attribute input is a derived union and ValueSpecificationActions don't define a subset of it).']

It seems to this reporter that there are 2 solutions to the reported inconsistency:

1. Somehow use an additional ControlFlow to the DecisionNode, and declare the existing Brake Pressure incoming ObjectFlow to be a decisionInputFlow.

2. "Revert" the outgoing edges to be ObjectFlows [NOT permitted]