Sunday, October 4, 2009

We now discuss how YAWL supports control flow patterns. It is obvious thatthe basic control flow patterns are directly supported. The sequence patternis shown in Figure 4.55, where two alternative representations are shown: inextended workflow nets, the control flow edge can directly connect A and B, sothat the condition place can be dropped. Notice that these two representationsare equivalent, i.e., any extended workflow net with conditions connecting twotasks can be transformed to an equivalent extended workflow net with directconnections, and vice versa. And split and and join patterns are shown in part (a) of Figure 4.56.On completion of the split task A (split(A) = and), tasks B, C, and D are enabled, and the three tasks can be executed concurrently. The join taskE (join(E) = and) is enabled only if B, C, and D have been completed.The exclusive or split shown in part (b) of that figure selects exactly onealternative, so that E can start if exactly one branch is completed. In thiscase, split(A)= join(E) = Xor. Workflow specifications require additional information that allows evaluatingconditions to decide, for instance, which path in an exclusive or splitto take. These conditions, however, are not part of the formal specification ofworkflow specifications in YAWL.Figure 4.57 shows the inclusive or split. From a notation point of view,the or split and the or join can be defined similarly to the other control flowstructures. However, the decision on when the or join is activated is complex.These aspects will be discussed in more detail when the execution semanticsof YAWL is investigated.

Execution Semantics

The execution semantics in YAWL is defined by state transition systems.Each workflow specification has a corresponding state transition system that describes the execution semantics of process instances based on that workflowspecification. The rules implemented in this state transition system are ofa generic nature, so that they can be applied to any workflow specificationexpressed in YAWL.The overall idea for expressing the execution semantics is that each taskis represented by an individual state transition diagram. A state transitiondiagram of a task specifies its current state. The state of the process instanceis then represented by the combined state of all tasks involved in the processinstance plus conditions that are currently met at the process level.

Task Instances

State transition diagrams consist of conditions represented by circles and transitionsrepresented by rectangles. Since multiple instances tasks can take morestates than single instance tasks, single instance tasks are investigated first.The state transition diagram for single instance tasks is shown in Figure 4.58.In this section, task instances are investigated before state transition diagramsat the process level are investigated. To stay in line with terminologyin YAWL, this section uses the term task instance, which describes the sameconcept as the term activity instance this book has used so far. The following conditions are available for a task instance:enabled: Task instance is enabled, but not yet executingexec: Task instance is currently executingcompleted: Task instance is completedactive: Task instance is currently activeThe execution semantics of a task instance is specified by the state transitiondiagram shown in Figure 4.58. Despite the fact that transitions do not use Petri net transition semantics, it is appropriate to discuss the basic operationof state transition diagrams with Petri net terminology.When the task instance is entered, a token is put on the active and enabledconditions. An enabled task instance can start. Once the start transition fires,the task instance enters the exec condition.When the task instance completes,it enters the completed condition; finally, the task instance is terminated byfiring the exit transition. Note that the active condition and the exit transitionare somewhat artificial for single instance tasks; their role will become clearwhen multiple instances tasks are addressed.To summarize, the state transitions for a task t have the following semantics.The state transition enable checks the join condition of t; t might bea join node of type And, Xor, or Or, as specified by join(t). When the enabletransition occurs, the input tokens as defined by the join condition areremoved from the input conditions of the task.In case of a single instance task, one token is put in the active condition andone token is put in the enabled condition. When the start transition occurs,one token is removed from the enabled condition and one token is added tothe exec condition. The task instance is now executing. The termination of atask instance is represented by the completed transition in the state transitiondiagram. In this case, one token is removed from the exec condition and onetoken is added to the completed condition.The exit transition is specifically relevant for multiple instances tasks,because it fires if the termination condition of a multiple instances task is met.In case there is a cancellation region defined for task t, the exit transition alsoremoves tokens from the cancellation region of the workflow specification, asdefined by rem(t). Finally, the exit state transition generates tokens dependingon its split behaviour, defined by split(t) The state transition diagram for multiple instances tasks is shown in Figure4.59. There is an additional state transition, add, that spawns new taskinstances. Arcs drawn in bold indicate that multiple tokens can flow alongthese arcs.To discuss the execution semantics of a multiple instances task, the staticcase is considered first. In this case, all task instances are created up front,and no task instances can be added while instances of the task run. Considera multiple instances task with [4, 6, 4, s]: four to six task instances are created,and the multiple instances task terminates when the threshold of fourinstances that have completed is reached.Consider a process instance in which the enable transition creates fivetask instances by putting five tokens in the active condition and five tokensin the enabled condition. For each token in the enabled condition, the starttransition can fire.The termination of the overall task (completion of the required task instances)is realized by the exit transition. Exit can fire if the threshold numberof tokens are in the completed condition, indicating the completion of asufficient number of task instances. Assuming four task instances have beencompleted, the threshold value is reached, and the exit transition removesfour tokens from the completed condition and four tokens from the activecondition.However, since five task instances have been started, there is one additionaltask instance present. This task instance is represented by one token in theactive condition and one token in either the enabled or the exec condition.This task instance might also have already entered the completed condition.In the example shown in Figure 4.60, the task instance is still executing To implement a proper completion of the task, the exit transition needsto delete all remaining tokens from the state transition system of the task. Inthis case, two tokens that collectively represent the fifth (and not required)task instance are removed, completing the task and all its task instances, ofwhich four have been performed completely.In the example discussed, the number of task instances was statically defined,so that the dynamic creation of new task instances was not possible. Inthe following example, additional task instances can be created at run time.Let [3, 10, 8, d] define the multiple instances property of the task. This meansthat there are at least three instances, at most ten instances, and the thresholdis eight completed task instances.Assume that three task instances are started up front. In this case, theenable transition puts three tokens in the active condition and three tokensin the enabled condition. The enabled task instances can start.The dynamic creation of new task instances is represented by the statetransition add. As soon as there is one task instance in the active condition,the add transition can fire. When it fires, an additional token is put in theenabled and active conditions, representing the creation of a new task instanceat run time. In this way add realizes the dynamic creation of task instances atrun time. Using this feature, YAWL directly supports the multiple instanceswithout a priori run time knowledge control flow pattern, introduced in Section4.1.The other parts of the state transition system remain unchanged, so thatthe originally created task instances and the dynamically created task instancesare handled equivalently: the exit transition can fire if there are asufficient number of completed task instances available, in this case, eight.The actual trigger for creating new task instances is not in the scope ofthe state transition system. It is assumed that the user or a software systemspawns new task instances as desired. The state transition system is capableof monitoring the state of a task, including the states of its task instances.