UML/SysML Activity Diagrams - Can a Decision Node element be hanging? (i.e., no incoming edge)

Question

UML/SysML Activity Diagrams - Can a Decision Node element be hanging? (i.e., no (visible) incoming edge.)

I have quite a large activity diagram with three main parallel object flows (with merging data, just to make it even more complicated) until activity completion.

Towards the end of the activity, I have a Decision Node element that selects (based on some "global" variable) which of the parallel object flows provides the activity output. For the selection I used a Decision Node element.

As a temporary simplification, I did not add the usual incoming edge to the Decision node. I left it "hanging in the air". Although the meanning is intuitive, is this allowed in strict UML/SysML?

The reason why I did it (obviously...), is that to add the incoming edge I would have to add 3 more edges (from the 3 parallel flows) and also a few more joins -- which makes an already busy diagram, even busier.

And no - I can't split it into sub-diagrams. It is what it is.

Answer 1

(Update due to @Axel's comment) If a decision node has no ingoing edge it will immediately fire a token.

UML 2.5.1 states on p. 378

nodes that do not have incoming edges and require no input data to execute are immediately enabled.

It's questionable that the condition of a decision note can be understood by anyone if it's starting out of nowhere.

It's futile to refrain from splitting. If your diagram gets that large it can not be read by anyone and will be useless. So either you get to the point where you can cut it into manageable pieces or you are at the wrong place. There is no king's way (Euclide).

Answer 2

Per UML 2.5.1, section 15.3.3.6, Decision Nodes, pg 390:

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.

Additionally, it is the token on the primary incoming edge that traverses the outgoing edge in which the guard evaluates to true. If the decision node has only one incoming edge and the incoming is an object flow the value of that token is used to evaluate the guards. If the node has a decision input flow the value of that token is used in the evaluation of the guards only. Bottom line is a decision node SHALL have at least one incoming edge, and if it has only one incoming edge it is the primary incoming edge. If you don't include an incoming edge it is semantically incorrect.