4

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.

enter image description here

A.A Noman
  • 5,244
  • 9
  • 24
  • 46
user9343460
  • 53
  • 5
  • This is indeed a tricky question which brought me to square one. Usually all incoming arcs need a token to continue the action. Currently reading the specs again... – qwerty_so Feb 10 '18 at 20:45

2 Answers2

2

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.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • I don't think you can compare State Machine and Activities like that. The main difference is that Activities are something **active** whereas states are something **passive**. AFAIK the rule that sas that each incoming control flow has to have a token before the action will be executed, does not apply to states and transitions. – Geert Bellekens Feb 11 '18 at 09:11
  • While state machine diagram and activity diagram share some similar graphical elements and approaches, they are not fully consistent. In State Machine diagram a state becomes active whenever any coming transition completes. Since there are usually multiple ways to trigger a change to a state that's the only logical approach. It's different with the activity so in this area those two diagrams are totally different. Stick just to the part related to activity diagram (p. 401) and your answer is absolutely true. – Ister Feb 11 '18 at 11:59
  • @Ister Thanks for that. I have to think over this and will eventually remove the lower part of my answer. I'm not completely settled with the merge being any different in this "implicit join". I never had issues reading the OP's diagram like the way I do for the state machine. Hope I have some time tomorrow. – qwerty_so Feb 11 '18 at 13:55
  • @Ister You were completely right. I updated my answer. – qwerty_so Feb 12 '18 at 10:42
  • @GeertBellekens Yes, you are right. Though both notations base on Petri nets, they are used with different elements in UML and differ that way. – qwerty_so Feb 12 '18 at 10:43
1

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.

Ister
  • 5,958
  • 17
  • 26