Are object flows to decision node and object flows from merges legal?

[mse]

Is the following activity diagram "legal" with respect to connectivity i.e. control and object flow?

• ReadStructuralValue action with result pin connected via OBJECT FLOW to decision node.
• One edge has guard (x != TIMEOUT) and leads to an atomic action with Effect (y = x)
• Another edge has guard (else) and leads to an atomic action with Effect (y = 0)
• Both actions merge into a merge node via CONTROL FLOW
• From merge node, there is an outgoing OBJECT FLOW to value pin of a AddStructuralFeature action

Are these object flows from pins to decision and merge nodes okay?

[qwerty]

Gives me headaches. How about a picture? You could ask that on StackOverflow....

q.

[Eve]

5.3.3.6 Decision Nodes
...
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.

In short, yes. Object flows are valid to and from Decision Nodes. My personal explanation is that an Object Flow is a¹ Control Flow with an additional piece of data.

¹ Technically it is an ActivityEdge that "may hold values". But as a ControlFlow doesn't add semantics of its own I believe describing one in terms of the other makes for an easier explanation and an easier decision while modeling.

[Paolo F Cantoni]

5.3.3.6 Decision Nodes
...
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.

In short, yes. Object flows are valid to and from Decision Nodes. My personal explanation is that an Object Flow is a¹ Control Flow with an additional piece of data.

¹ Technically it is an ActivityEdge that "may hold values". But as a ControlFlow doesn't add semantics of its own I believe describing one in terms of the other makes for an easier explanation and an easier decision while modelling.

Yes, I agree.  I've always thought of the Object flow as a Control Flow with data.  This reinforces the Decision Note wording; as the data has to "go" somewhere.

Paolo

[KP]

Yes, but...

• Both actions merge into a merge node via CONTROL FLOW
• From merge node, there is an outgoing OBJECT FLOW to value pin of a AddStructuralFeature action

I don't think you can have an object flow out of a merge node unless there's an object flow in. Where does the object come from?