Sunday, August 16, 2009

Control flow patterns provide a yardstick for expressing process orchestrations.Control flow patterns are independent of concrete process languages, so thateach pattern can be expressed in different process languages. Control flowpatterns can also be used to compare the expressiveness of process languages.Basic control flow patterns include sequence, and split, and and join, aswell as exclusive or split and exclusive or join. These control flow patternsare supported by virtually any process metamodel. Control flow patterns aredefined at the process model level. Their execution semantics, however, appliesto process instances.In this section, the semantics of control flow patterns will be investigatedon 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 thegeneral approach.Consider a process model P = (N,E, type) according to Definition 3.3with activity models A and B and a sequence flow A ! B. This processmodel defines an ordering on the activity instances associated with A andB in the context of a single process instance: for each process instance, theactivity instance associated with B can only start after the activity instanceassociated with A has terminated.As a result, the process model restricts the ordering of events that occurduring process instances. In the example, the termination event of the activityinstance associated with activity model A must occur before the begin eventof 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., aninstance of a sequence flow ordering the execution of two activity instances.Each gateway instance has a begin event and a termination event. For a uniformtreatment of control flow structures, sequences are also considered asgateways, as discussed above.Activity models are denoted by capital letters, A,B,C, . . ., while the associatedactivity instances are denoted by a, b, c, . . .. In case multiple activityinstances are associated with an activity model in the context of a givenprocess model, subscripts are used, for instance, a1, a2, . . .. Gateways are typicallydenoted by G, and g is an instance of a gateway. Let P be a processmodel 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 pis 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 modelG 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 orderingbetween the termination event of a (and the activity instance of activitymodel A) and b, such that b can only be enabled after a has terminated. Thisapproach relates the control flow patterns directly to the state transitions ofactivity instances.In particular, the state transition from init to enabled of an activity instanceb can only be done after the state transition from running of a toterminated 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 peractivity model. However, if the activity models are part of a loop, then theremight be multiple activity instances based on activity models A and B.Therefore, the execution semantics of the sequence control flow patternneeds to be refined so that eventually for each termination event of someactivity instance a1, a2, . . . there is an enable event of an activity instanceb1, b2, . . .. A fragment of a process model where A and B are part of a loop is shownin Figure 4.3; to realize this loop, an exclusive split gateway, an exclusive orjoin gateway, and a set of sequence flows are added.A process instance based on this process model is shown in the lower partof that figure. The loop is iterated three times, resulting in activity instancesa1, 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 theevent diagram, in each iteration of the loop, the activity instance ai terminatesbefore bi can start, for i 2 {1, 2, 3}.However, the ordering “first a then b” can be violated if a and b belong todifferent iterations of the loop. For instance, the termination event of b1 occursbefore the start event of a2. In order to capture loops properly, it is necessaryto define that for each termination event of a there is an enable event of b suchthat 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 notdirecly to begin events. Since begin events can only occur after the respectiveenable events have occurred, it is guaranteed that the termination event of aioccurs before the begin event of bi.