具有依赖性的并行进程

Question

There are two parallel processes. Each process has two steps. The second step of the first process is always executed after the first step. The second step of the second process is performed only under a certain condition.

Activity diagram:

How to reflect an additional condition: to complete the second step of the second process, the first step of the first process must be completed.

I managed:

Flaws:

1. No match between fork and join
2. If the condition of the second process is not met, the token “hangs” before join

Answer 1

Having looked at your solution once more made me think that you saw issues, where there are none. You are worried about the hanging token, but that is no issue in this case. If P22 is bypassed, the token from P11 will go down directly to the join node. P11 and P12 will pass their token down also with no issue, thereby creating that ghost token which gets stuck in the middle right join. Since the lower join now has two tokens it will continue to the end where the activity is terminated. At that point any free running tokens (and even active actions) are terminated as well. All good.

I leave my former answer for further inspiration. But basically they will all be implemented in similar ways since they represent a gateway.

---

Original answer

I guess that using an event would be the best way:

This way D can only start (and finish) when the event has been received which is sent after A s completion.

Another way would be to use an object that stores the finalization of action A and which is read by D .

Note that the diagonal connectors through a ready are ObjectFlow s which UML does not per default distinguish optically (unlike SysML).

P. 374 of UML 2.5 states

Object tokens pass over ObjectFlows, carrying data through an Activity via their values, or carrying no data ( null tokens). A null token can still be passed along an ObjectFlow and used like any other token. For example, an Action can output a null token to explicitly indicate that it did not produce an optional value, and a downstream DecisionNode (see sub clause 15.3) can test for this and branch accordingly.

So you can see that as a buffer holding a token and no real data is needed to be stored. Basically that's the same as an event. Implementation wise you would use a semaphore or a stream to realize that, but of course at this level you would not care too much about such details.