Join Node or Merge Node?

1
votes

I am trying to make an activity diagram of a user for my system and I am unsure if the flow should come down to a Join Node or Merge Node before the user can log off. Here is the one I have made sa of now. Could anyone explain to me what's the difference?

Join Node

1
umldiagramactivity-diagram
According to your design I can only do one thing on your system and then I must log out. I'm guessing that is not how ou meant it? – Geert Bellekens
Ah, yes. So I reckon I should go for Merge Node instead? @GeertBellekens – walr0s
A merge node won't help if you don't allow the user to do something else after his first action. Currently the only thing they can do after doing one of the action is "Logout" – Geert Bellekens
@GeertBellekens Is it better if after the homepage, I added a Fork Node to split the flow into multiple concurrent flows like build itinerary etc. Then join all of them again with a Join Node that has one outgoing flow to a decision node named 'Go Back To Homepage'. If yes, the flow goes back to the homepage action state and if no, it goes to a new 'continue action' action node. – walr0s
Is that how you user a system? I personally can only do one task at a time, not all of them in parallel. Besides if you split them using a fork, and then join them, you are basically saying that the user has to do all of them. And it seems reasonable that I can logout from your system without doing anyhting as well. In that case Logout should be at the same level as the other actions a user can do. – Geert Bellekens

1 Answers

2
votes

It must be a join (though I first remembered wrongly and thanks to @AxelScheithauer pointing out my error). P. 401 of UML 2.5

15.5.3.1 Executable Nodes

...

When an ExecutableNode completes an execution, the control token representing that execution is removed from the ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode. That is, there is an implicit fork of the flow of control from the ExecutableNode to its outgoing ControlFlows.

That means that all 6 actions below will start in parallel which does not mean they must run concurrently. But all of them need completion in order to continue after the join below. (I doubt that this is desired.)

There's a (double) 2nd flaw in the top decision back-flows. They need to go back to the top merge. Otherwise neither Login nor Register would start since they expect 3 or 2 tokens where only one would arrive.