The motivation for the development of Yet Another Workflow Language (YAWL) was the lack of a process language that directly supported all control flow patterns. While it uses workflow nets as a major ingredient, the execution semantics of process instances is specified by state transition systems and not by Petri nets. In this section, YAWL and its support for control flow patterns, as well as its execution semantics, are investigated.
While Petri nets provide a sound formalism for expressing most control flow patterns, the following deficiencies have been identified that hamper the expression of the full set of control flow patterns.
• Multiple Instances: Multiple instances patterns describe business processes with multiple instances of specific activities. The number of activity in- stances of one particular activity model might not be known at design time.
Petri nets do not provide adequate means to describe multiple instances tasks.
• Advanced Synchronization Patterns: Petri nets can directly express and split/join and exclusive or split/join using places, transitions and firing rules of traditional Petri nets. Advanced synchronization patterns such as, for instance, or split and or join and discriminator patterns, however, cannot be conveniently expressed in Petri nets.
• Nonlocal Firing Behaviour: The enabling of activities in a business process is based onlocal knowledge only. In the context of Petri nets, the presence of tokens in the input places of a transition indicates activation of that transition. In business processes, there are situations in which nonlocal parts of the process are affected by a decision. For instance, the cancellation pattern somehow vacuum-cleans defined parts of the Petri net when being activated. If used to cancel a customer order, different activities in different parts of the Petri net need to be cancelled in order to cancel the overall customer order.
4.5.1 Definitions
Notationwise, YAWL is based on workflow nets. In particular, it uses ex- tended workflow nets as building blocks for workflow specifications. Extended
workflow nets enhance traditional workflow nets with notational convenience (direct arcs between transitions are allowed), explicit split and join behaviour that can be attached to transitions, nonlocal behaviour (on the firing of a transition, parts of the extended workflow net are cleansed of tokens), and the handling of multiple instances tasks.
Because workflow specifications consist of a set of extended workflow nets, extended workflow nets are defined.
Definition 4.9 Anextended workflow net is a tuple (C, i, o, T, F, split, join, rem, nof i), such that
• C is a set of conditions
• i∈C is the initial condition, ando∈C is the final condition
• T is a set of tasks, such thatC andT are disjoint
• F ⊆(C− {o} ×T)∪(T×C− {i})∪(T×T) is a flow relation, such that every node inC∪T is on a directed path fromito o
• split : T 6→ {And, Xor, Or} is a partial mapping that assigns the split behaviour of a task
• join : T 6→ {And, Xor, Or} is a partial mapping that specifies the join behaviour of a task
• rem:T 6→ P(T∪C− {i, o}) specifies the subnet of the extended workflow that is cleansed when the task is executed, whereP(S) denotes the power set of S
• nof i : T 6→ N×Ninf ×Ninf × {dynamic, static} is a partial function that specifies the number of instances of each task (min, max, threshold for continuation, and dynamic/static creation of instances), where Ninf indicates the set of natural numbers plus an infinite value symbol.
Extended workflow nets, also definition wise, are an extension of work- flow nets. If (C, i, o, T, F, split, join, rem, nof i) is an extended workflow net, (C, T, F) is a workflow net, except for the fact that the flow relation in ex- tended workflow nets allows direct arcs between tasks. As discussed below, this is a shorthand notation for a more Petri-net-like flavour, in which there is always a condition between the transitions, representing the tasks.
In workflow nets, labels of transitions mark the split and join behaviour.
These labels are not part of the formal definition of workflow nets. In contrast, the annotation of transitions with specific split and join behaviour is part of the definition of extended workflow nets.
For each task a cancellation region can be defined. When a task with a cancellation region is executed, all tokens are removed from the cancellation region. The removal functionrem defines parts of the extended workflow net that need to be cleansed from tokens when the task is executed. In this way, nonlocal behaviour can be expressed.
There are also differences with respect to handling tokens. In Petri nets, firing of a transition removes tokens from its input places and adds tokens to
its output places. In Petri nets, tokens are never on transitions. In extended workflow nets, however, tokens reside at transitions while the transition is being executed. This also means that the execution of a transition takes time, another fundamental difference to Petri nets (and also to workflow nets), in which the firing of transitions does not consume time.
The number-of-instances functionnofi can be used to assign information about multiple instances to tasks. In an entry (min, max, threshold, d/s) as- sociated with a taskt,
• min: Minimum number of instances of taskt for one case
• max: Maximum number of instances oft for one case
• threshold: If the threshold is reached, then all active instances of that task are cancelled and the task completes
• d/s: The letterdstands for dynamic andsstands for static creation of new instances. In the dynamic case, new task instances can be created while instances of this task are already running. Static means that all instances are created up front, and no additional instances can be created at run time of the task.
Workflow specifications use extended workflow nets as building blocks, and multiple extended workflow nets involved in a workflow specification can be connected to each other by composite tasks.
Definition 4.10 A YAWL workflow specification S is a tuple (Q, top, T, map), such that
• Qis a set of extended workflow nets
• top∈Qis the top level workflow net
• T=S
N∈QTN is the set of all tasks. Conditions and tasks of all extended workflow nets are disjoint, i.e.,
N16=N2 =⇒ (CN1∪TN1)∩(CN2∪TN2) =∅,∀N1, N2∈Q.
• map:T 6→Q− {top} is a function that maps each composite task onto an extended workflow net. Hence, each task t ∈ T for which map(t) is defined is a composite task.
For each extended workflow net, except the top-level extended workflow net, there exists a task that maps to it, and for each extended workflow net there exists at most one task that maps to it.
The notational elements of Yet Another Workflow Language are shown in Figure 4.54. The notation borrows most elements of workflow nets, so that conditions are represented by circles and tasks are represented by rectangles.
The initial condition and the final condition of an extended workflow net are labelled with specific symbols.
There are several notational extensions for tasks. Composite tasks have a double border to indicate that they map to an extended workflow net. Tasks with multiple instances are represented by double rectangles, as shown in
Condition Input condition
Output condition
Atomic task Composite
task
Multiple instances of an atomic task
Multiple instances of a composite task
AND-split task
AND-join task
XOR-split task
XOR-join task
OR-split task
OR-join task
Remove tokens
Arc
Fig. 4.54.Notational elements of YAWL, van der Aalst and ter Hofstede (2005)
Figure 4.54. Composite tasks can also have multiple instances; in this case, the notational symbols are combined.
The graphical representation of the split and join behaviour of a task is equivalent to that in workflow nets. Finally, the set of tokens that are removed when a task is executed is shown by a dotted line. This graphical representa- tion might become cumbersome if the tasks and conditions are spread across a large workflow specification and if multiple tasks remove tokens.
4.5.2 Simple Control Flow Patterns
We now discuss how YAWL supports control flow patterns. It is obvious that the basic control flow patterns are directly supported. The sequence pattern is shown in Figure 4.55, where two alternative representations are shown: in extended workflow nets, the control flow edge can directly connectAandB, so that the condition place can be dropped. Notice that these two representations are equivalent, i.e., any extended workflow net with conditions connecting two tasks can be transformed to an equivalent extended workflow net with direct connections, and vice versa.
A B A B
Fig. 4.55.Representations of sequence pattern in YAWL
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), tasksB, C, and D are
enabled, and the three tasks can be executed concurrently. The join task E (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 one alternative, so that E can start if exactly one branch is completed. In this case,split(A)= join(E) = Xor.
C B
A E
D
C B
A E
D
(a) And Split / Join (b) Xor Split / Join Fig. 4.56.And split/join andxor split/joinpatterns
Workflow specifications require additional information that allows evalu- ating conditions to decide, for instance, which path in an exclusive or split to take. These conditions, however, are not part of the formal specification of workflow specifications in YAWL.
Figure 4.57 shows the inclusive or split. From a notation point of view, theor split and theor join can be defined similarly to the other control flow structures. However, the decision on when theor joinis activated is complex.
These aspects will be discussed in more detail when the execution semantics of YAWL is investigated.
C B
A E
D
Fig. 4.57.Inclusive or split andinclusive or joinpatterns
4.5.3 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 workflow specification. The rules implemented in this state transition system are of a generic nature, so that they can be applied to any workflow specification expressed in YAWL.
The overall idea for expressing the execution semantics is that each task is represented by an individual state transition diagram. A state transition diagram of a task specifies its current state. The state of the process instance is then represented by the combined state of all tasks involved in the process instance plus conditions that are currently met at the process level.
Task Instances
State transition diagrams consist of conditions represented by circles and tran- sitions represented by rectangles. Since multiple instances tasks can take more states 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 dia- grams at the process level are investigated. To stay in line with terminology in YAWL, this section uses the term task instance, which describes the same concept as the term activity instance this book has used so far.
enable
active
exit
start
exec
complete completed enabled
Fig. 4.58.State transition diagrams for single instance tasks
The following conditions are available for a task instance:
• enabled: Task instance is enabled, but not yet executing
• exec: Task instance is currently executing
• completed: Task instance is completed
• active: Task instance is currently active
The execution semantics of a task instance is specified by the state transition diagram shown in Figure 4.58. Despite the fact that transitions do not use
Petri net transition semantics, it is appropriate to discuss the basic operation of state transition diagrams with Petri net terminology.
When the task instance is entered, a token is put on the active and enabled conditions. 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 by firing the exit transition. Note that the active condition and the exit transition are somewhat artificial for single instance tasks; their role will become clear when multiple instances tasks are addressed.
To summarize, the state transitions for a taskthave the following seman- tics. The state transition enable checks the join condition of t; t might be a join node of typeAnd, Xor, or Or, as specified by join(t). When the en- able transition occurs, the input tokens as defined by the join condition are removed from the input conditions of the task.
In case of a single instance task, one token is put in the active condition and one 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 to the exec condition. The task instance is now executing. The termination of a task instance is represented by the completed transition in the state transition diagram. In this case, one token is removed from the exec condition and one token 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 taskt, the exit transition also removes tokens from the cancellation region of the workflow specification, as defined byrem(t). Finally, the exit state transition generates tokens depending on its split behaviour, defined bysplit(t)
enable
active
exit
add enabled
start
exec
complete completed
Fig. 4.59. State transition diagram for multiple instances task
The state transition diagram for multiple instances tasks is shown in Fig- ure 4.59. There is an additional state transition, add, that spawns new task instances. Arcs drawn in bold indicate that multiple tokens can flow along these arcs.
To discuss the execution semantics of a multiple instances task, the static case 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. Consider a multiple instances task with [4,6,4, s]: four to six task instances are cre- ated, and the multiple instances task terminates when the threshold of four instances that have completed is reached.
Consider a process instance in which the enable transition creates five task instances by putting five tokens in the active condition and five tokens in the enabled condition. For each token in the enabled condition, the start transition can fire.
The termination of the overall task (completion of the required task in- stances) is realized by the exit transition. Exit can fire if the threshold num- ber of tokens are in the completed condition, indicating the completion of a sufficient number of task instances. Assuming four task instances have been completed, the threshold value is reached, and the exit transition removes four tokens from the completed condition and four tokens from the active condition.
However, since five task instances have been started, there is one additional task instance present. This task instance is represented by one token in the active 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.
enable
active
exit
add enabled
start
exec
complete completed
Fig. 4.60.State transition diagram for multiple instances task with five instances, four of which have completed
To implement a proper completion of the task, the exit transition needs to delete all remaining tokens from the state transition system of the task. In this case, two tokens that collectively represent the fifth (and not required) task instance are removed, completing the task and all its task instances, of which four have been performed completely.
In the example discussed, the number of task instances was statically de- fined, so that the dynamic creation of new task instances was not possible. In the 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 means that there are at least three instances, at most ten instances, and the threshold is eight completed task instances.
Assume that three task instances are started up front. In this case, the enable transition puts three tokens in the active condition and three tokens in the enabled condition. The enabled task instances can start.
The dynamic creation of new task instances is represented by the state transitionadd. 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 the enabled and active conditions, representing the creation of a new task instance at run time. In this wayaddrealizes the dynamic creation of task instances at run time. Using this feature, YAWL directly supports themultiple instances without a priori run time knowledge control flow pattern, introduced in Sec- tion 4.1.
The other parts of the state transition system remain unchanged, so that the originally created task instances and the dynamically created task in- stances are handled equivalently: the exit transition can fire if there are a sufficient number of completed task instances available, in this case, eight.
The actual trigger for creating new task instances is not in the scope of the state transition system. It is assumed that the user or a software system spawns new task instances as desired. The state transition system is capable of monitoring the state of a task, including the states of its task instances.
Process Instances
The discussion of state transition diagrams is extended from a localized view of individual tasks to a process view. In order to do this, a number of defi- nitions are required. The first definition extends the compact representation of extended workflow nets in a way that it syntactically complies with the workflow net definition: wherever there is an arc connecting two tasks in an extended workflow net, a new condition is added and the arcs are modified accordingly.
Definition 4.11 LetN= (C, i, o, T, F, split, join, rem, nof i) be an extended workflow net.
• CNext is anextended condition set, such that
CNext=C∪ {cij|(ti, tj)∈F∩T×T}
• FNext⊆CNext×T ∪T×CNextis anextended flow relation set, such that FNext=F−T×T∪ {(ti, cij),(cij, tj)|(ti, tj)∈F∩T×T}
This definition is illustrated by an example, shown in Figure 4.61, which exhibits an extended workflow net
W1= (C1, i1, o1, T1, F1, split, join, rem, nof i),
such that C1 = {i1, o1}, T1 = {A, B, C, D, E, F, G}, split(C) = Xor, and join(G) =Xor. The flow relationF1 is given by the arrows in Figure 4.61.
Observe that taskF is a composite task, referencing an extended workflow netW2, with C2 ={i2, o2}, T2 ={H, I}, and F2 ={(i2, H),(H, I),(I, o2)}.
For the time being, the multiple instances tasks are not defined in detail.
The respective workflow specification is a tuple (Q, top, T, map), such that Q={W1, W2},top=W1,T={A, . . . I}, andmap(F) =W2.
H
B C
D
E
F
G
I A
W1
W2 i1
i2 o2
o1
Fig. 4.61.YAWL workflow specification
The extended condition set and the extended flow relation are shown in Figure 4.62. Observe that for each direct connection between tasks in the original extended workflow net, one condition and the respective arcs are added:C1ext={i1, cAB, cBC, cCD, cCE, cCF, cDG, cEG, cF G, o1}.
The extended flow relationF1extis given by the arrows in Figure 4.62. Anal- ogously, the extended condition set and the extended flow relation forW2are given byC2ext={i2, cHI, o2}andFext={(i2, H),(H, cHI),(cHI, I),(I, o2)}.