Wednesday, August 26, 2009

The implicit termination pattern is defined as follows: a given process instanceshould be terminated when there is nothing else to be done. This means, thereis no activity instance in the process instance in the init, ready, or runningstate 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 activityinstances with each other, such as, for instance, the sequence pattern or thesplit and join patterns discussed. It represents a termination condition of anoverall process.In several process languages, termination is explicit, because there is exactlyone state in the process that marks its termination. If there are manystates in which the process can terminate, then termination is implicit.

Multiple Instances Without Synchronization

More important than implicit termination are the patterns involving multipleactivity instances. These activity instances are based on a single activity modelin the context of a business process.There are many situations that can be expressed properly by multipleinstances patterns. For instance, assume an order process in which an incomingorder contains a number of order lines. For each of these order lines, a checkactivity needs to be executed. This means that only at run time can thebusiness process management system decide how many activities actually needto 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 instancesof one activity model can be created. No synchronization of these activityinstances takes place. In the process model shown, activity model B usesthe pattern. After the termination of activity instance a, a number of activityinstances are initiated and enabled for activity model B. In the event diagram, activity instances b1, b2, and b3 are shown. These instances are enabled andcan be started.The term “without synchronization” in the context of this example meansthat the follow-up activity instance c can be enabled immediately after theinstances for B have been enabled. Since there are no assumptions on theexecution times of activity instances, c can terminate while activity instancesof 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 controlflow between activity models B and C does not—strictly speaking—havethe semantics of a sequence pattern, since an instance of C can be enabledwhile instances of B are still active. As a result, the sequence pattern is somehowviolated by the multiple instances without synchronization pattern.This pattern causes problems not only with the sequence flow, but alsowith the termination of the overall process. Since the activity instances arenot synchronized, it cannot be guaranteed that these activity instances haveterminated when the end of the process is reached. This means that certainexecution guarantees related to soundness properties (which will be discussedin Chapter 6) cannot be satisfied.Multiple instances patterns can be distinguished for the point in timewhen the actual number of instances is determined. The multiple instanceswithout synchronization pattern does not make any assumptions on whetherthe number of instances is defined at design time or at run time. This issubject of the control flow patterns discussed next.