Page 83 -

70 N. Russell and A. ter Hofstede
Table 2.6 Data pattern support
Pattern Group Supported Patterns
Data visibility patterns Task Data, Block Data,and Multiple Instance
Data
Data interaction patterns – internal All except Data Interaction – Case to Case
Data interaction patterns – external None are directly supported
Data transfer patterns Data Transfer by Value, Data Transformation –
Input, Data Transformation – Output
Data routing patterns Data-based Routing

2.5.4 Data Patterns Coverage

The various facilities that underpin the data perspective in YAWL are influenced
by the data patterns presented in Sect. 2.2.2. The extent of data pattern support is
summarized in Table 2.6.
In total, YAWL directly supports 10 of the data patterns. There are partial solu-
tions for a further five patterns: Data Interaction – Process to Environment –
Push-Oriented is indirectly supported through the use of codelets via the Resource
Service (cf. Chap. 10) and the various Task Pre- and Post-condition patterns can be
facilitated via task configurations supported by the Exception Service.

2.5.5 Object Role Model

This section provides a conceptual model for the data perspective of a YAWL model
using the object-role modeling notation as shown in Fig. 2.32. The data perspec-
tive centers around the concepts of nets, tasks, variables, and parameters. Variables
are used to represent a data element and have a specific name together with a data
type specified using XMLSchema. Variables either correspond to a net or a task.
Parameters are used to map data elements from one variable to another at the com-
mencement or conclusion of a task. Parameters may be simple (which can be used
by any task) or multiple instance (which only apply to multiple instance tasks). In
either case, however, they are specified in terms of an XQuery expression. Parame-
ters always have an input and output data element. Simple parameters may be either
input or output parameters, indicating the direction in which they operate. In the case
of multiple instance parameters, the situation is more complicated and the parame-
ter is made up of four distinct queries: the accessor, splitter, instance, and aggregate
query. Tasks have a precedence relationship between them (termed a flow), which
indicates the direction in which the thread of control flows between them in a given
process. In the case where a task has an OR-split or XOR-split associated with it,
its outgoing flows are conditional and there is a Boolean condition, specified in
terms of an XPath expression, for each flow. This condition is evaluated at runtime
to determine whether the thread of control is passed down the flow when the task
completes execution.