Semantics, Verification, and Implementation of Workflows ... - YAWL

Chapter 3. OR-join semantics
wards firing rule. Section 3.4 presents two restriction techniques to improve the
efficiency of OR-join analysis. Section 3.5 describes the implementation in the
context of the open source system YAWL and provides a detailed analysis of its
performance. Section 3.6 discusses related work on OR-join semantics.
This chapter presents and expands upon work published previously [WEAH05].
3.1 Original OR-join semantics
In this section, the informal semantics of an OR-join is first explained using a
number of examples. Two problems associated with multiple OR-joins in a YAWL
net are then discussed using the OR-join semantics as defined by van der Aalst
and ter Hofstede [AH05]. Some alternative treatments for OR-joins on the path
to other OR-joins are then proposed.
The OR-join is a control flow construct that sometimes behaves like an AND
join and sometimes like an XOR join based on the current context. Consider
the car servicing scenario shown in Figure 3.1. When a customer requests car
servicing, the mechanic needs to perform a number of tasks. After scheduling
the car for service, the mechanic performs two tasks: one to make a checklist of
servicing requirements and one to check for other faults that need to be repaired.
These two tasks can be done in any order. If the mechanic finds a problem
that requires repair actions, he/she will wait until other service requirements are
identified before performing necessary repairs. If the service requirements have
been identified first, the mechanic will wait for the outcome of the other task:
check for faults. There are two possible outcomes from check for faults: a fault is
either detected or there is no fault. When the outcome is known, servicing can be
started. As a result, the perform servicing task has been modelled as an OR-join.
Before generating the bill, we should make sure that all the necessary checks and
maintenance tasks have been performed. If there is no fault, the generate bill
task will wait for synchronisation until the perform servicing task is completed.
Otherwise, it can be started when the servicing has been completed for both
regular maintenance and necessary repairs. Hence, the generate bill task is also
modelled as an OR-join. The car servicing scenario in Figure 3.1 highlights the
need for a construct like OR-join in process modelling. The decision to start the
generate bill task requires knowledge of the status of all other tasks in the process
model and, hence, is non-local.
Check for faults
Schedule service
Identify yearly
servicing requirements
Perform car
servicing
Generate bill
Figure 3.1: Car servicing scenario
PhD Thesis – c○ 2006 M.T.K Wynn – Page 33