1. 3/26/2013
CHAPTER OUTLINE
• Section 4.1 introduces control flow patterns, a
Business Process Methodology yardstick in process control flow structures. The
patterns will be described both textually and more
Chapter 4- Process Orchestrations
formally using the event-based approach introduced in
the previous chapter.
• Section 4.2 provides a compact introduction to Petri
nets. Different Petri net classes are introduced,
Prepared by: including condition event nets, predicate transition
Rao Majid Shamshad nets and, colored Petri nets.
University of Education, Lahore
• An informal perspective on business process modelling
email: majidrao111@yahoo.com
http://www.bpm-ue.blogspot.com is taken in Section 4.3, where event-driven process
chains are discussed. This approach is widely used in
the business domain to model business processes from
a pragmatic, application-oriented point of view.
4.1 CONTROL FLOW PATTERNS • Basic control flow patterns include:
• Control flow patterns provide a yardstick for – sequence,
expressing process orchestrations. Control – and split,
flow patterns are independent of concrete – and join,
process languages, so that each pattern can – exclusive or split
be expressed in different process languages. – exclusive or join.
Control flow patterns can also be used to • These control flow patterns are supported by
compare the expressiveness of process virtually any process meta-model. Control flow
languages. patterns are defined at the process model level.
Their execution semantics, however, applies to
process instances.
4
1
2. 3/26/2013
• Activity models are denoted by capital letters, SEQUENCE
A,B,C, . . ., • The sequence pattern defines that an activity
• while the associated activity instances are instance b in a process instance p is enabled
denoted by small letters, i.e. a, b, c, . . .. after the completion of activity instance a in p,
• Gateways are typically denoted by G, and g is with process model
an instance of a gateway • P = (N,E, type) containing activity models A, B,
• Let P be a process model and p a process and a gateway model G such that A,B Є NA,
instance based on this model with an event G Є NG, E Ͻ {(A,G), (G,B)}, and
set Ɛᵨ. type(G)=Sequence
5 6
• The application of the sequence pattern in
A→B induces an event ordering between the
termination event of a (and the activity
instance of activity model A) and b, such that
b can only be enabled after a has terminated.
This approach relates the control flow
patterns directly to the state transitions of
activity instances.
• In particular, the state transition from init to
enabled of an activity instance b can only be
done after the state transition from running of
a to terminated of a has occurred.
7 8
2
3. 3/26/2013
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.
• 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.
9 10
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.
• 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.
11 12
3
4. 3/26/2013
Xor Split
• An Xor split or exclusive or split is a point in a
process model where one of several branches
is chosen.
• 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:
13 14
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.
• For each termination event of an activity instance
b or c there is one and only one enable event of
an activity instance d.
• 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.
15 16
4
5. 3/26/2013
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
behavior of an or split.
• 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.
17 18
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.
• 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.
19 20
5
6. 3/26/2013
• 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
21 22
Multiple Merge
• A multiple merge or multi-merge is a point in a
process model where two or more concurrent
threads join without synchronization. The activity
following the merge is started for every activation
of every incoming branch.
• The multi-merge is functionally equivalent with
the exclusive or join; the only difference is that
the latter assumes that only one of its incoming
branches gets activated. This assumption is not in
place for the multi-merge pattern.
23 24
6
7. 3/26/2013
• The multiple merge pattern spawns off new threads of
control. These threads need to be identified so that
future joins can be realized properly. These aspects are
illustrated in an example shown in Figure 4.11, where a
process model with an and split followed by a multi-
merge is shown. As a result, any of the threads induced
by the and split will survive the multiple merge and
spawn a new instance for activity model D and of the
activity models following D in the process model.
• Each of the threads of control spawned off by the
multi-merge is subject to the and split/and join shown
in the process model. The and join requires
information on the identity of the threads that come
in; otherwise, situations could arise in which activity
instances that belong to different threads of control are
synchronized. These issues can be illustrated by the
event diagram
25 26
Discriminator
• The discriminator is a point in a process model
that waits for one of the incoming branches to
complete before activating the subsequent
activity. From that moment on it waits for all
remaining branches to complete and “ignores”
them. Once all incoming branches have been
triggered, it resets itself so that it can be
triggered again. This allows a discriminator to
be used in the context of a loop.
27 28
7
8. 3/26/2013
These activity instances are b2 and c2. What is remarkable
in this example is that there are two instances of activity
model C active concurrently, assuming c1 has not yet
terminated. Even if c2 terminates before c1, the semantics
of the discriminator makes sure that it can only fire and
enable d2 after the first iteration has completed, i.e., only
after the remaining activity instance c1 has terminated. If
• An example involving the discriminator pattern is this I the case, the discriminator can fire a second time, to
shown in Figure 4.14. The process starts with enable d2. The event diagram of this process instance is
activity instance a before an and split occurs that shown in Figur 4.15.
spawns activity instances b1 and c1. Assuming b1
terminates first, the discriminator fires and
enables d1. When d1 terminates, assuming a new
iteration of the loop is required, new activity
instances based on B and C are created.
29 30
Arbitrary Cycles A more complex example of a cycle involving the multi-
merge pattern I shown in Figure 4.18. The problem in
• An arbitrary cycle is a point in a process model
where one or more activities can be executed this example is that the cycle enter one of two
repeatedly. concurrent branches of an and split whose branches
• An arbitrary cycle is graphically depicted in Figure are joined b a multi-merge
4.17. In this example, a sequence consisting of
activity models A, B, and C is iterated. The
iteration is represented by an exclusive or split
that decides whether to iterate the cycle or
whether to leave it and continue with activity
instance d, associated with activity model D. In
case the loop is iterated, the exclusive or join
triggers another instance associated with activity
model A.
31 32
8
9. 3/26/2013
Deferred Choice
• Deferred choice is a state-based pattern.
State-based patterns capture the implicit
behaviour of processes that is based not on
the current case but rather on the
environment or other parts of the process.
Some of the following patterns require the
existence of an external process that
represents the environment. This process is
used as a source for external events.
33 34
• A deferred choice is a point in a process model
where one of several branches is chosen. In
contrast to the exclusive or split, the choice is
not made explicitly—for example, based on
data values or a user decision—but several
alternatives are offered to the environment.
• The environment activates one of the
alternatives, and the other branches are then
withdrawn. Because the choice is delayed
until one of the alternative branches has
actually been started, the moment of choice is
deferred to a point in time that is as late as
possible
35 36
9
