Page 354 -

352 G. Decket et al.
objects). In BPMN, standard properties are defined more precisely than data objects
and they are proposed to be used for the purpose of defining transformations from
BPMN to executable languages. Indeed, in the mapping from BPMN to BPEL pre-
sented in the BPMN specification, they are mapped to the data variables in BPEL.
However, the drawback of properties is that they are not visible in the graphical
notation of BPMN. To counter these drawbacks, properties and data objects can be
used in combination: data objects to document the data aspect of the process and
properties to precisely define the data variables that are used in the process. This is
the approach we follow below.
BPMN leaves the modeler with much freedom to model data and data manipu-
lation. In particular, it leaves the modeler with the freedom to choose the (textual)
language in which property types and data manipulation are modeled. A benefit of
this is that BPMN does not favor a particular workflow language for implementing
BPMN models. Another benefit is that the modeler can now use BPMN to draw a
model, without having to worry about the complexities of a data modeling language
such as XQuery. However, a drawback of having freedom to choose a data modeling
language is that it precludes a general mapping from BPMN to a workflow language,
because such a general mapping would require the definition of a mapping from any
data modeling language (including natural language) to the data modeling language
used by the workflow system. Therefore, we will impose constraints in this chapter
on what BPMN models we consider to be well-formed for mapping to YAWL.
The YAWL-constrained version of BPMN that we consider uses XQuery to
model data and data manipulation (meaning that both the QueryLanguage and
ExpressionLanguage attributes of the BPMN diagram must be set to XQuery).
Properties of activities and processes must be used to represent data. Data types
of properties must be specified in XML Schema. Assignments must be attached
to activities in order to represent data manipulation, and conditions on sequence
flows must be used to represent conditional passing of control. Assignments and
conditions must also be expressed in XQuery. Conditions with “ConditionType =
None” are not accepted. Figure 13.4 shows an example, in which the details of
the data objects from Fig. 13.3 are added. Note that, while this figure uses XML
to specify those details, this is done here only for the example, because the con-
crete syntax for specifying properties, conditions, and assignments is not defined
in BPMN. Figure 13.4 defines that the process Freight in Transit has the property
trackpoints of type Trackpoints as well as some other properties. The trackpoints
property corresponds to the Trackpoints data object that is shown in Fig. 13.3. How-
ever, it is defined in more detail (assuming that the structure of the Trackpoints
type is defined in an XML Schema elsewhere). Similarly, the task Issue Trackpoint
Notice has some properties. This task also has some assignments. One assignment
assigns the value of the trackpoints property of the Freight in Transit process to
the trackpoints property of the task, when the task is started. Another assignment
adds the trackpointNotice that is generated by the task (if one is generated at all)
to the trackpointNotices of the process. Finally, Fig. 13.4 refines the condition more
Trackpoints on one of the sequence flows from Fig. 13.3.