Database Reference
In-Depth Information
both sides of the connected classes. The
Participant
,
Activity
, and
WorkTransition
classes
respectively stand for participants, activities, and work transitions of a process model. The
ProcessData
class stands for process data as a set of data that is referenced or modifi ed by
activities of a process model. Note that the
Participant
class has an one-to-many associa-
Participant
tion, “
belong to,
” with the
Activity
class; the
WorkTransition
class has two many-to-many
associations, “
is pre-activity
” and “
is post-activity,
” with the
Activity
class to respectively
indicate its preceding and following activities; the
Activity
class has a many-to-many as-
sociation, “
use,
” with the
ProcessData
class to indicate process data referenced or modifi ed
by the activity.
Using the object diagram of the UML, Figure 3(b) shows an object data example that
represents the order handling process, PM
1
, in the form of the presented object data model.
An object is represented by a rectangle that has an object name on the upper side and attri-
bute values on the lower side. An association is represented by a line. In particular, a solid
line and dashed line are used to distinguish “
is pre-activity
” and “
is post-activity
” associa-
tions between
WorkTransition
and
Activity
objects. For example,
WorkTransition
object
w3
represents the AND-SPLIT work transition from A
1,2
to both A
1,3
and A
1,4
in Figure 2.
As an “
is pre-activity
” association, the activity object,
a2
, is linked with a solid line, while
objects
a3
and
a4
are linked with two dashed lines as
“is post-activity”
associations. In
this way, the object data example in Figure 3(b) represents the whole structure of the order
handling process, PM
1
.
The process status is defi ned as a set of ongoing activities' states and a set of process
data used by the activities. In PM
1
, suppose that A
1,3
has notifi ed a customer that an ordered
product is being shipped, while A
1,4
is in the midst of delivering the product. Then, A
1,3
and
A
1,4
are ongoing activities in the process instance and they use three process data - product,
shipping address, and sales amount - according to the object data example in Figure 3(b).
Figure 3(c) shows an XML representation of this process status on the basis of the following
XML Document Type Declaration (XML DTD) that is a generic XML document structure
representing a process status:
Participant
class has an one-to-many associa-
<! ELEMENT
WfMessage
(
WfMessageBody
)>
<! ATTLIST
WfMessage
Version CDATA #REQUIRED>
<! ELEMENT
WfMessageBody
(
ActivitySet
,
ProcessDataSet
)>
(
ActivitySet
<! ELEMENT
ActivitySet
(
*) >
ActivitySet
(
ActivitySet Activity
(
Activity
<! ELEMENT
Activity
(
AID
(
AI
( ,
State
)>
<! ELEMENT
AID
(#PCDATA)>
<! ELEMENT
State
(#PCDATA)>
<! ELEMENT
ProcessDataSet
(
ProcessData
*) >
(
ProcessData
<! ELEMENT
ProcessData
(
Key
,
Value
)>
(
Key
<! ELEMENT
Key
(#PCDATA)>
<! ELEMENT
Value
(#PCDATA)>
In the beginning, the XML DTD borrows the Wf-XML specifi cation that the Workfl ow
Management Coalition (2000) proposed as a standard XML-based representation of a pro-
cess status, and thus it defi nes the root element,
WfMessage
, to identify a Wf-XML message
and its child element,
WfMessageBody
, to indicate a message body section. In representing
a process status, however, the Wf-XML covers only the state of a process instance itself,
such as “running,” “suspended,” “terminated,” etc., and does not support the activity-level
