FinalNode must not have outgoing ActivityEdges — model validation fails on activity final node

Question

I am modeling an activity in UML 2.5.1 and my validator flags the model as invalid when an activity final node has an outgoing control flow. My understanding is that the Activities clause defines a well-formedness rule: a FinalNode (both activity final node and flow final node) must not have outgoing ActivityEdges, and violating it makes the model non-conforming rather than merely stylistically wrong.

The design intent was to let one branch continue after another branch reaches a final node, which I now suspect conflates the activity final node (terminating all flows in the activity) with a state machine final state, where entering the final vertex completes the region and can trigger a completion transition on the enclosing composite state.

Constraints: the model must validate cleanly under a conforming validator (Eclipse Papyrus), and I want to stay within the UML 2.5.1 specification rather than rely on tool-specific leniency, since validators differ in strictness.

Does the FinalNode rule apply identically to activity final nodes and flow final nodes, or only to one of them?
If a branch must continue after another ends, is a FlowFinalNode on the ending branch plus a merge/join on the continuing flow the conforming pattern?
Is a validator that accepts the outgoing edge simply non-strict, or is the constraint scoped differently across 2.4.1, 2.5, and 2.5.1?

Tasadduq Burney · Answer

Answer
In UML 2.5.1 the well‑formedness rule for FinalNode (both ActivityFinalNode and FlowFinalNode) requires that the node have no outgoing ActivityEdge.
Confirmed facts

The rule is expressed in the OCL constraint FinalNode::outgoing->isEmpty() and appears unchanged from UML 2.4.1 through 2.5.1.
An ActivityFinalNode terminates all flows in the activity; a FlowFinalNode terminates only the specific flow that reaches it. In both cases emitting a token on an outgoing edge would contradict their semantics.

Likely explanation
If a validator accepts an outgoing edge on a FinalNode it is being non‑strict or lenient; the specification does not differ across versions, so any acceptance indicates the validator is not enforcing the UML well‑formedness rule.
Conforming pattern for a continuing branch

Place a FlowFinalNode on the branch that should end, with no outgoing edge.
Let the other branch continue directly; no merge or join is required unless you later need to synchronize the two flows.
If a later synchronization is needed, the ended branch must still provide a token (e.g., via a DecisionNode with a guard that forwards a token) because a FlowFinalNode consumes the token and does not emit one.

Verification steps (Eclipse Papyrus)
1. Open Preferences → Papyrus → Model Validation → Strict UML compliance and enable it.
2. Edit the activity diagram, add an outgoing edge from a FinalNode.
3. Save; the model should be marked invalid with a violation of the FinalNode outgoing‑edge constraint.

Alternatively run the Eclipse UML2 validator (org.eclipse.uml2.ecore.validation) on the model; the OCL check will fail for any FinalNode with an outgoing edge.

FinalNode must not have outgoing ActivityEdges — model validation fails on activity final node

1 answer

Answer

Confirmed facts

Likely explanation

Conforming pattern for a continuing branch

Verification steps (Eclipse Papyrus)

Your perspective belongs here.

0 question comments