The implicit termination pattern is defined as follows: a given process instance
should be terminated when there is nothing else to be done. This means, there
is no activity instance in the process instance in the init, ready, or running
state and—as a result—no activity instance can be become enabled.
While implicit termination is defined as one of the control flow patterns,
its role differs with respect to the other patterns. It does not relate activity
instances with each other, such as, for instance, the sequence pattern or the
split and join patterns discussed. It represents a termination condition of an
In several process languages, termination is explicit, because there is exactly
one state in the process that marks its termination. If there are many
states in which the process can terminate, then termination is implicit.
Multiple Instances Without Synchronization
More important than implicit termination are the patterns involving multiple
activity instances. These activity instances are based on a single activity model
in the context of a business process.
There are many situations that can be expressed properly by multiple
instances patterns. For instance, assume an order process in which an incoming
order contains a number of order lines. For each of these order lines, a check
activity needs to be executed. This means that only at run time can the
business process management system decide how many activities actually need
to be instantiated in order to perform the required checking activities.
The multiple instances without synchronization pattern is defined as follows.
In the context of a single process instance, multiple activity instances
of one activity model can be created. No synchronization of these activity
instances takes place.
In the process model shown, activity model B uses
the pattern. After the termination of activity instance a, a number of activity
instances are initiated and enabled for activity model B. In the event diagram,
activity instances b1, b2, and b3 are shown. These instances are enabled and
can be started.
The term “without synchronization” in the context of this example means
that the follow-up activity instance c can be enabled immediately after the
instances for B have been enabled. Since there are no assumptions on the
execution times of activity instances, c can terminate while activity instances
of the multiple instances activity are still running. In the event diagram shown,
b1 and b2 are still running when c has already completed.
This behaviour of the pattern has some consequences. First of all the control
flow between activity models B and C does not—strictly speaking—have
the semantics of a sequence pattern, since an instance of C can be enabled
while instances of B are still active. As a result, the sequence pattern is somehow
violated by the multiple instances without synchronization pattern.
This pattern causes problems not only with the sequence flow, but also
with the termination of the overall process. Since the activity instances are
not synchronized, it cannot be guaranteed that these activity instances have
terminated when the end of the process is reached. This means that certain
execution guarantees related to soundness properties (which will be discussed
in Chapter 6) cannot be satisfied.
Multiple instances patterns can be distinguished for the point in time
when the actual number of instances is determined. The multiple instances
without synchronization pattern does not make any assumptions on whether
the number of instances is defined at design time or at run time. This is
subject of the control flow patterns discussed next.