I have two flows going to the same action. The action is Make Payment. One flow is for rent, and other is for purchase. In both cases customer has to pay. I want to use one payment action for both flows. Or should I use merge node and then connect the output to make payment action. I am not sure whether I can use merge node or not, because both flows are independent of each other. I have uploaded a picture.
This one caught me on the wrong foot. When there are multiple unguarded transitions going out of a state/action an implicit fork is issued so multiple tokens leave and travel independently. P. 401:
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.
I seemed to remember that analogously two incoming transitions mean that both have to deliver a token. And reading on (above) on p. 401:
An ExecutableNode shall not execute until all incoming ControlFlows (if any) are offering tokens. That is, there is an implicit join on the incoming Control Flows. Specific kinds of ExecutableNodes may have additional prerequisites that must be satisfied before the node can execute.
Now when you look at p. 425 you find
A merge node is a control node that brings together multiple alternate flows. It is not used to synchronize concurrent flows but to accept one among several alternate flows.
So here you are. You need to merge beforehand to make it correct.
N.B.: If you are modeling informally (so in a certain domain where this is documented) you could live with your notation since it's often used. Theory and practice... It's not recommended, though.
Just to add to Thomas Kilian answer
Can you model like that at all? Yes. But it will mean implicit Join so both flows has to complete in order to start the Make Payment action. This is allowed but not what you want to achieve.
Can you model like this in your case? No. This will have a different behaviour than what you want to achieve (join rather than merge).
Can you use Merge node before the activity to obtain expected results? Yes, that's absolutely correct and preferred way of merging flows when we want to continue when just one incoming flow completes. The fact that the flows are separately triggered does not pose a problem.
Can you achieve the same without Merge node? Yes, you can use parameters and parameter sets. You can use one parameter and the flows coming to that parameter create an implicit merge. Also if you have parameter sets defined action starts when all parameters of just one parameters set is offered a token but that means different sets of parameters are passed with different flows. Yet the approach with parameters is possible only if you have some parameters to pass. Besides it'll more difficult to understand so I would discourage such approach until you really know what you're doing.
Related
I tried to reduce my problem to the following simple example. If the profit is low and the customer is not a regular one then the order should become canceled. In all other cases (low/regular, high/*) the order is to be executed. How should I model the disconnected part in the middle?
Wheter or not the client corresponding to order is a regular client follows from the data model:
I assume you are looking for the formally correct way to model this. Here it is:
If less formality is sufficient, you could skip the decision input flows and simply assume that the guards have access to any objects in the scope of the activity. Then one decision node is sufficient with a guard [profit=low AND not order.customer.regular Customer].
I do a university course on business process management. The lecturer said that you can model conditions on sequence flows, which I agree with. However in the context of gateways he said that you can even model conditions on outgoing sequence flows if you use parallel gateways. My understanding is that this is not correct as the bpmn specification/page 97 also states:
A Sequence Flow can optionally define a condition Expression, indicating that the token will be passed down the Sequence Flow only if the Expression evaluates to true. This Expression is typically used when the source of the Sequence Flow is a Gateway or an Activity.
A conditional outgoing Sequence Flow from an Activity MUST be drawn with a mini-diamond marker at the beginning of the connector (as seen in Figure 8.33).
If a conditional Sequence Flow is used from a source Activity, then there MUST be at least one other outgoing Sequence Flow from that Activity.
Conditional outgoing Sequence Flows from a Gateway MUST NOT be drawn with a mini-diamond marker at the beginning of the connector.
A source Gateway MUST NOT be of type Parallel or Event.
From my interpretation the last 2 list items explicitly forbid to model conditions on outgoing sequence flows of a parallel gateway. Am I right or wrong? Or is this more a question of definition and modelling philosophy?
Thank you in advance
I think you are correct with your interpretation of the specification. Here is another source that also states that parallel gateways cannot have conditions.
That being said, in practice you will sometimes find diagrams that violate the standard in a detail. If the diagram is still very clear and understandable, I am personally okay with that - after all, diagrams are meant to be a tool for communication. But you will find other people who would not share this opinion. So yes, asking for the modelling philosophy is also a valid question.
On this concrete example, I do not really see a purpose of having parallel paths with conditions.
I have found in internet the following activity diagram:
I can't understand why from Recieve order action there are two control flows (to Ship order and Bill customer). Are they parallel? Then why there is NOT fork. How to understand this diagram? Please, explain.
This is simply a bad example.
Judging from the context there should be a fork to indicate that both Ship order and Bill customer should happen in parallel.
Then there should be a Join before Send confirmation to indicate that both flows should have finished before the Send confirmation is executed.
It's perfectly valid UML 2. The first action requires no tokens, so it can start immediately. When the first action finishes, it offers tokens to two other actions and they can start. The last action cannot start until all required tokens are offered. When the last action is done, the containing activity is also done.
Forks just copy tokens. Joins just merge tokens. Thus, forks and joins are often unnecessary.
Please see Conrad Bock's excellent series of articles on activity diagrams in the Journal of Object Technology.
I did not check if this is a recent amendment to the UML specification but the current version 2.5 (chapter 15.2.3.2) states (emphasis set on my own):
As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes in sub clause 15.3 and ExecutableNodes in sub clause 15.5). If a token is offered to multiple ActivityNodes at the same time, it shall be accepted by at most one of them, but exactly which one is not completely determined by the Activity flow semantics. This means that an Activity model in which non-determinacy occurs may be subject to timing issues and race conditions. It is the responsibility of the modeler to avoid such conditions in the construction of the Activity model, if they are not desired.
From that point of view, I would argue that #Jim L.'s answer might be deprecated. I assume that, at least in the current version of UML, the diagram in question does not reflect the modeler's intention. A fork seems to be not only the clean way but the only right way to go, now.
I am in the process of writing use cases for a website
I would like to know whether conditional flow can be incorporated in websites
Eg: Payment Success- Failure
Or should it be documented as Activity or state diagranm?
Use Case descriptions, as mentioned in another answer, should most importantly cover the successful use cases of the system. However, it is also important to mention some of the special cases, in which system and actor should interact differently. Be warned, it is important to identify special conditions related to the use of the system, not technical details and rather than describing the decision logic, you should describe the special conditions. Alistair Cockburn in Writing effective Use Cases uses extensions of use cases to describe those scenarios as branches (with pre- and post-conditions) from the main scenario, with possible merge. Other experts use alternative flows for the same use case description. If you are truly after capturing the algorithmic logic, your idea of considering activity or state diagrams is a better choice.
As mentioned, payment success would be your main path. Payment failure, as in the user's credit card was declined, is an acceptable outcome and should have an alternate path.
If the payment fails because of something like network connection issues, that would be a exception and handled accordingly. (I've always treated exception paths as a type of alternate path.)
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 #").