“join node” and “fork node” for a single branch in UML

Question

Section 15.3.3.3 of UML specification says:

Fork Nodes

A ForkNode is a ControlNode that splits a flow into multiple concurrent flows.

Also 15.3.3.4 says:

Join Nodes

A JoinNode is a ControlNode that synchronizes multiple flows.

Also 15.3.4.2 says:

Fork and Join Nodes

[...] ForkNode must have a single incoming ActivityEdge and usually has two or more outgoing ActivityEdges, while a JoinNode usually has two or more incoming ActivityEdges and must have a single outgoing ActivityEdge.

So specification says: "It is possible to use a fork node to split a single flow to a single flow and a join node to synchronize a single flow." But with attention to the meaning of concurrency and synchronizing concepts, I think it is not rational and also does not mean. Am I misunderstanding somethings? If yes, is there an example which needs to use fork node and join node in that way?

Answer 1

In short

You have understood correctly.

In long

Analysis of the standard

15.3.3.3 says it very clearly:

A ForkNode is a ControlNode that splits a flow into multiple concurrent flows. A ForkNode shall have exactly one incoming ActivityEdge, though it may have multiple outgoing ActivityEdges.

The important thing here is that a ForkNode cannot have no outgoing activity edge, because this would cause an inconsistency. If such a nonsense would be possible, the flow of tokens would be interrupted, but the would never end. If a partial flow is to be ended, a FlowFinalNode must be used.

If a ForkNode has only one output, it is not very useful. However, it would create no inconsistency:

      |
----->|----->       is equivalent to    ---------->
      |

Similarly, 15.3.3.4 gives the full picture:

A JoinNode is a ControlNode that synchronizes multiple flows. A JoinNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges.

The reasoning is the same than before. It is important that there is at least one input. It is expected to have several, but if there'd be only one, it wouldn't cause any inconsistency.

The following sentence in the same section, also shows that the multiple input is the expectation, because an and needs two operands. But the reformulation in plain text makes it work with only one input:

If a JoinNode does not have a joinSpec, then this is equivalent to a joinSpec Expression with the Boolean operator “and.” That is, the implicit default joinSpec condition is that there is at least one token offered on each incoming ActivityEdge.

Note that a join with a single input may have some purpose, depending on how the joinSpec is formulated, and especially if the input is an ObjectFlow.

Expressivity

Having only one output to a fork has no practical effect on concurrency (the sole flow is concurrent with itself). If you don't beliee this, you'll have at least to agree that it has no more effect than having only a single start node, since 15.3.3.1 tells us that:

If an Activity has more than one InitialNode, then invoking the Activity starts multiple concurrent control flows, one for each InitialNode.

The fact that UML allows the modeller to consistently express something, doesn't mean that this thing will be useful. For example, UML allows to have an activity diagram made solely of a start node having a flow to an end node. Just another elaborate way to say that the activity consists of doing nothing.

The possibility to have only one input on a join or one output on a fork has some advantages in terms of expressivity, without affecting the semantic. By using this kind of construct:

• You can highlight that it's a partial diagram of the model, being understood that a part of the activity model is not represented or still needs to be designed;
• You can also suggest that some degree of concurrency could be expected between the fork and the join in future.
• You can isolate visually a sequence of actions