I'm learning Activity diagram in UML and now I'm confused with the following diagram for representing procedures when calling a pizza.
I think a merge node should be added before the join node because if not, the join node will wait forever. Is that correct?
Thank you.
I think you are right.
There should be a merge node merging the two flows coming from the decision right after Ask for toppings and a merge node to merge the two flows that have been split by the decision right after Deliver Pizza
A join node will only continue if it gets a token from all incoming flows, which will never happen if those flows are mutually exclusive because of a decision earlier on.
Related
Is it valid to have the following combined join and fork nodes in a UML activity diagram or is it wrong?
I searched online and in some UML books but I cannot find a clear answer or a similar example.
The idea is to have two actions (1 and 2) that need to be completed and then synchronised before the start of actions 3 and 4.
Should I just introduce a sync action between a join and a fork node to be on the safe side?
Yes, that is valid.
In the UML specifications version 2.5.1 you'll find on page 391
The functionality of a JoinNode and a ForkNode can be combined by
using the same node symbol, as illustrated in Figure 15.31. This
notation maps to a model containing a JoinNode with all the incoming
ActivityEdges shown in the diagram and one outgoing ActivityEdge to a
ForkNode that has all the outgoing ActivityEdges shown in the diagram.
I wonder if this how you want it done?
Fork end merge
Let's say I have a decision node. I want the output of that decision node to be the input of another decision node, without having to create another action in the middle. Is it possible to do that in UML?
In short
Yes, this is possible.
What does it mean?
There are two kind of flows in an activity diagram:
control flows: the arrow is more or less answering the question "what's next?".
object flows: the "what's next" is related to objects passed along the arrow.
The rule for a decision node, is that if the primary incoming edge is a control flow, all the outgoing edges shall be control flows. Conversely, if the primary incoming edge is an object flow, all the outgoing edges shall be object flows.
In this regard, it is important to keep in mind that a decision node is not an activity that creates an output; It just routes the incoming control flow tokens or objects to the right branch.
So you can definitively take the output of a first decision node as input for the second decision node. The only constraint is that the incoming flow of the second node is of the same kind as for the first node.
My question is about the merge node in the UML activity diagram, when and why to use it?
Merge node example:
A merge node accepts a single token to continue processing. Other nodes need tokens at all incoming edges to start processing. So if a flow is split by a decision you have a single token passing at one side of it. In order to reach the Join at the lower end, you need to collect either flow left and right to collect the single token and pass it on.
N.B.: Activity diagrams have their root in Petri nets. You could consult Wikipedia to see how they work in detail. There also a couple of answers here on SO.
I have the below UML activity diagram for a shopping cart use case. It has several decision and fork nodes but there are no corresponding join/merge nodes. Could you please show me:
how to correct the diagram by introducing the merge/join nodes.
how to modify the diagram so that a customer can repeat the process (of adding more products to the shopping cart).
Thank you.
You should look into the token concept. It is introduced in petri nets and also used in the UML activity diagram.
Decision nodes produce one token only, i.e. they follow just one outgoing path. To merge such paths, of which only was is followed, you can use a merge node. Which just looks like a reversed decision node and is able to consume exactly one token. A diamond with multiple incoming edges.
If you use a parallelization node to start concurrent execution paths, you have multiple tokens leaving the parallelization node. To merge these kind of paths, you can use a synchronization node, it looks like a reversed parallelization node and has to consume one token per incoming edge.
(source: amg at www.lcc.uma.es)
Do you have an initial activity element anywhere? Makes it a bit easier to read. To your question, the merge should be used as opposed to having multiple connectors coming into the same activity. For instance, "Acknowledge Msg" should have a merge above it that the other branches can flow into.
As for how to make it repeatable, you may want an "Add to Cart" action, and prior to a "Checkout" action, have a Decision with guards for "Shopping Complete" (which goes to the Checkout action) and "Continue Shopping" (which goes back to "Enter Product #").
I'm working on an activity diagram that has a decision node. First action is "review application" then it goes into the decision node. This splits into accepted or rejected. On both cases, I need to add "Update audit trail" and "notify user" actions. And then the flow goes to the final node.
The "Update audit trail" and "notify user" actions will use the same method in the application, but obviously behave differently depending on the decision.
0-->Review_Application--> <> --> ??
The question is, after the decision node can I duplicate the last two actions twice for each decision flow and then join them to the final node. Or should I use a join node to after the decision node and not duplicate the last two actions? What is the recommended way to achieve this?
Many Thanks
My preference is to avoid fork/join unless there's real concurrency. So I would not use fork or join bars unless you had real parallel activities.
The left one makes more sense. Why?
In this case, the arguments inside the "Notify User" activity will be different.
They're two instances of the same type of activity. Someone may implement them as one method with different argument values.
You can clarify this by naming the activities with a name that clarifies what's different about them.
Your two "update audit trail" can both connect directly to the terminating node. Don't use a Join. Just connect to the next activity or state node.