Menu
What is the difference between Join and Merge in Unified Modeling Language Activity Diagram. Give an example to understand more clearly.
538
TL;DR and more simple version: JOIN requires both activities that are coming in to be completed. MERGE just waits for one of the incoming activities to be completed.
A fork node is used to split a single incoming flow into multiple concurrent flows. It is represented as a straight, slightly thicker line in an activity diagram. A join node joins multiple concurrent flows back into a single outgoing flow. A fork and join mode used together are often referred to as synchronization.
A Decision Node in an Activity diagram is used much like a choice or junction point in the State diagrams. Decision nodes allow you to separate the Activity Edges. Merge nodes allow you to combine the Activity Edges together.
A merge node is a node in an activity at which several flows are merged into one single flow. There is an arbitrary number of incoming edges and exactly one outgoing edge. A flow within an activity is generally controlled by conditions.
Join Node (see reference 1):
Join node is a control node that has multiple incoming edges and one outgoing edge and is used to synchronize incoming concurrent flows. Join nodes are introduced to support parallelism in activities.
Merge Node (see reference 2):
Merge node is a control node that brings together multiple incoming alternate flows to accept single outgoing flow. There is no joining of tokens. Merge should not be used to synchronize concurrent flows.
For example in below diagram:
A decision is used after a fork, the two flows coming out of the decision need to be merged into one before going to a join.
Why?: Otherwise, the join will wait for both flows.
So, Activity 2 and Activity 3 are our alternate flows and only one of which will arrive. And they are not synchronize incoming.
However, the Concurrent_Activity and result of decision between Activity 1 and Activity 2 (that merged into one output) are synchronize incoming concurrent flows. The join waits for both to perform and continue.
194
To elaborate on @Gholamali-Irani's answer: Activity diagrams are derived from Petri nets. In short you have to imagine a single "token" that starts at the one initial start point (that fat dot). The token travels along a path until it vanishes in one of those (circled dot) final terminals (or as UML allows in actions which have no outgoing path). The fork nodes will multiply that single token into as many tokens as it has outgoing paths (UML also has an implicit fork for actions with multiple outgoing paths which are not guarded). So these multiple tokens travel independently until they either vanish like described above or they reach a join (or action) with multiple ingoing paths. Here the token waits until all paths are fed with a single token. These multiple tokens are then merged into a single one which travels on as usual.
With this ruleset you can model any complex concurrent network.
43
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
