And Split
An and split or parallel split is a point in a process model where a single
thread of control splits into multiple threads of control which are executed concurrently. Consider a process model with activity models A, B, and C and
a gateway G such that E {(A,G), (G,B), (G,C)} and type(G) = AndSplit.
Since thereby the process model P = (N,E, type) is well defined, we refrain
from providing the formal definition of P with the subsets of N. An and split determines that for each termination of an activity instance
a there are enable events of activity instances b and c, and these events occur
after the termination event of a. Therefore, for each ta 2 Ep there exist eb, ec 2
Ep such that ta < eb ^ ta < ec.
And Join
An and join is a point in a process model where multiple concurrent threads
converge into one single thread of control. It is an assumption of this pattern
that each incoming branch is executed exactly once.
Consider a process model with activity models B, C, and D, and a gateway
G such that E {(B,G), (C,G), (G,D)} and type(G) = AndJoin. For each enable event of an activity instance d, there are termination events of activity
instances b and c, such that the termination events occur before the enable
event. Therefore, for each ed 2 Ep 9tb, tc 2 Ep such that tb < ed ^ tc < ed.
Xor Split
An xor split or exclusive or split is a point in a process model where one of
several branches is chosen. A process model with activity models A, B, and
C and a gateway G such that E {(A,G), (G,B), (G,C)} and type(G) =
XorSplit The execution semantics of an exclusive or split determines that for each
termination of an activity instance a associated with activity model A there is
either an enable event of activity instance b or an enable event of an activity
instance c, but not both: for each ta 2 Ep: eb 2 Ep , ec /2 Ep, such that either
ta < eb or ta < ec.
Xor Join
An xor join or exclusive or join is a point in a process model where two
or more alternative threads come together without synchronization. It is an
assumption of this pattern that exactly one of the alternative branches is
executed.
Consider a process model with activity models B, C, and D, and a gateway
G such that E {(B,G), (C,G), (G,D)} and type(G) = XorJoin.
For each termination event of an activity instance b or c there is one and
only one enable event of an activity instance d. Therefore, for each ti 2 Ep,
such that i 2 {b, c} there is an event ed 2 Ep such that ti < ed.
While it is an assumption of this pattern that the branches are alternative
and none of them are ever executed in parallel, the branches can be part of
a loop. But even in this case, for each iteration of a loop, the branches are
alternative and have exclusive or semantics.
Or Split
An or split is a point in a process model where a number of branches are
chosen. Selection of any nonempty subset of branches is a proper behaviour of
an or split. Figure 4.8 shows a process model with activity models A, B, and
C and a gateway G such that E {(A,G), (G,B), (G,C)} and type(G) =
OrSplit.
An or split restricts the events of related activity instances as follows: for
each termination event of a there is a subset of enable events of b and c. In
general, for each termination event of a there can be enable events for any
subset of activity instances on the outgoing branches of the split.
In the example, the respective enable events are eb, ec 2 Ep, and any subset
of this event set reflects an acceptable behaviour of the or split, as long as
ta < eb and ta < ec are satisfied (if both branches are selected). In the general case where the or split has n
outgoing edges, 2n −1 options are possible: all nonempty subsets that can be
created out of n activities.
Or Join
An or join is a point in a process model where multiple threads of control
converge into one single thread. It is an assumption of this pattern that a
branch that has already been activated cannot be activated again while the
merge is still waiting for other branches to complete.
A process model with activity models B, C, and D, and a gateway G such
that E {(B,G), (C,G), (G,D)} and type(G) = OrJoin . Once all active branching paths are completed and the respective end events of the final activities in these paths have occurred, the synchronization takes place.
Either only
the upper thread is taken and only activity instance b is enabled, or only the
lower thread is taken and c is enabled, or both threads are performed and b
and c both are enabled. In general, any nonempty subset of the threads are
valid options, so that 2n − 1 options are allowed for n incoming edges of the
or join.
The or join is a problematic control flow pattern. The problem is that
the join cannot locally decide how long to wait for its activation. Even from
the simple process model fragment shown in Figure 4.9, this problem can be
explained: once one incoming branch is triggered, for instance, by termination
of b, how should the or join react? There are two options:
• Wait: The or join waits before the activity instance d is triggered, because
the other incoming path—which completes in activity instance c—can still
be executed.
• Trigger : The or join triggers d immediately after the termination of b.
The problem is that we cannot decide which of these alternatives the correct
one is. After the first incoming branch has terminated, how long should the
or join wait for the other branch to complete?
If no additional knowledge is available, there is no way of deciding whether
c will eventually terminate for the particular process instance. Since there is no upper bound on the waiting time, realizing the waiting alternative leads
to a deadlock situation if the second thread is never activated.
If the or join triggers d after one incoming branch is activated, a situation
might occur in which c terminates after d has already started! This behaviour
contradicts the semantics of the or join, since in this case it has to wait until
both branches complete.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment