Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec A -- By Mathias Weske

Control Flow Patterns

Control flow patterns provide a yardstick for expressing process orchestrations.
Control flow patterns are independent of concrete process languages, so that
each pattern can be expressed in different process languages. Control flow
patterns can also be used to compare the expressiveness of process languages.
Basic control flow patterns include sequence, and split, and and join, as
well as exclusive or split and exclusive or join. These control flow patterns
are supported by virtually any process metamodel. Control flow patterns are
defined at the process model level. Their execution semantics, however, applies
to process instances.
In this section, the semantics of control flow patterns will be investigated
on the basis of the events and event orderings they imply on process instances.
Due to its simplicity, the sequence pattern is well suited to explaining the
general approach.
Consider a process model P = (N,E, type) according to Definition 3.3
with activity models A and B and a sequence flow A ! B. This process
model defines an ordering on the activity instances associated with A and
B in the context of a single process instance: for each process instance, the
activity instance associated with B can only start after the activity instance
associated with A has terminated.
As a result, the process model restricts the ordering of events that occur
during process instances. In the example, the termination event of the activity
instance associated with activity model A must occur before the begin event
of the activity instance associated with activity model B.
Each control flow construct is represented in the process model by a gateway.
As with activity instances, there are instances for gateways, e.g., an
instance of a sequence flow ordering the execution of two activity instances.
Each gateway instance has a begin event and a termination event. For a uniform
treatment of control flow structures, sequences are also considered as
gateways, as discussed above.
Activity models are denoted by capital letters, A,B,C, . . ., while the associated
activity instances are denoted by a, b, c, . . .. In case multiple activity
instances are associated with an activity model in the context of a given
process model, subscripts are used, for instance, a1, a2, . . .. Gateways are typically
denoted by G, and g is an instance of a gateway. Let P be a process
model and p a process instance based on this model with an event set Ep.

Sequence

The sequence pattern defines that an activity instance b in a process instance p
is enabled after the completion of activity instance a in p, with process model P = (N,E, type) containing activity models A, B, and a gateway model
G such that A,B 2 NA, G 2 NG, E  {(A,G), (G,B)}, and type(G) =
Sequence.
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. In process instance p, for a termination event ta 2 Ep of an activity instance a, there is an enable event bb 2 Ep of an activity instance b, such that ta < eb.
The discussion captures well the case of a single activity instance per
activity model. However, if the activity models are part of a loop, then there
might be multiple activity instances based on activity models A and B.
Therefore, the execution semantics of the sequence control flow pattern
needs to be refined so that eventually for each termination event of some
activity instance a1, a2, . . . there is an enable event of an activity instance
b1, b2, . . ..
A fragment of a process model where A and B are part of a loop is shown
in Figure 4.3; to realize this loop, an exclusive split gateway, an exclusive or
join gateway, and a set of sequence flows are added.
A process instance based on this process model is shown in the lower part
of that figure. The loop is iterated three times, resulting in activity instances
a1, b1, . . . , a3, b3. Rather than showing all events of these activity instances,
just the enable and termination events are displayed. As can be seen in the
event diagram, in each iteration of the loop, the activity instance ai terminates
before bi can start, for i 2 {1, 2, 3}.
However, the ordering “first a then b” can be violated if a and b belong to
different iterations of the loop. For instance, the termination event of b1 occurs
before the start event of a2. In order to capture loops properly, it is necessary
to define that for each termination event of a there is an enable event of b such
that ta < bb. This condition is satisfied by the process instance: for ta1 < eb1,
ta2 < eb2, and ta3 < eb3.
These event orderings relate termination events to enable events and not
direcly to begin events. Since begin events can only occur after the respective
enable events have occurred, it is guaranteed that the termination event of ai
occurs before the begin event of bi.