Computers in Industry 47 (2002) 139±154

A document-process association model

for work¯ow management
Hyerim Bae, Yeongho Kim*
Department of Industrial Engineering, Seoul National University, Seoul 151-742, South Korea
Received 7 June 2001; accepted 27 October 2001

Abstract

A WorkFlow Management System (WFMS) is a software system to support an automatic, ef®cient execution of business
processes. A business process often involves document processing. Although, many traditional WFMSs can support the
document processing to some extent, they are concerned mainly with document delivery. We propose an XML-based approach
to WFMS for form document processing on the Web. Taking advantage of XML, we can partition a document into several
meaningful segments, each of which in this approach becomes a unit of work that can be performed by some activities in a
work¯ow process. Based on this document partition, we develop a formal model, called document-process association model,
which can associate the units of work with process activities. The model not only provides a tight control over document-related
processes, but it also enables various useful services, such as customization of document monitoring and contents-based
interaction between WFMS and other application programs. A prototype system has been implemented to demonstrate the
usefulness of the proposed model. # 2002 Elsevier Science B.V. All rights reserved.

Keywords: Business process; Work¯ow; XML; Form document

1. Introduction to control their dependency with the underlying work-

Today's business environment makes it indispensa-
ble for a company to deal with complex business
processes. A work¯ow management system is a soft-
ware system to support an automatic, ef®cient execu-
tion of the business processes [14,18]. Such a business
process often involves document processing. In this
paper, we consider a WorkFlow Management System
(WFMS) that can manage the document ¯ow over a
work¯ow process. An essential ability in such a
WFMS is to keep track of the documents' trace and
*
Corresponding author. Tel.: ‡82-2-880-8335;
fax: ‡82-2-889-8560.
E-mail address: yeongho@snu.ac.kr (Y. Kim).
¯ow process.
Many traditional WFMSs can support document
processing to some extent [27]. However, the WFMSs
are concerned mainly with document delivery. While
controlling a business process, a WFMS identi®es a
document that the process should deal with, and
simply conveys the document to a relevant user.
Consider typical documents, such as purchase order,
engineering change order, and cost estimation sheet,
and so on. Most such documents in a business process
have a certain format, that is, it is composed of a
number of ®elds with some kind of structures. We call
such a document a form document.
In a typical business process, an activity is often
associated with ®lling in a form document. It may
involve inserting new values into some ®elds of the

0166-3615/02/$ ± see front matter # 2002 Elsevier Science B.V. All rights reserved.
PII: S 0 1 6 6 - 3 6 1 5 ( 0 1 ) 0 0 1 5 0 - 6
140 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
document or modifying those values. This indicates
that document processing may not be considered
separately from the process ¯ow. Such a notion leads
us to consider the necessity of associating form docu-
ment elements with process activities, so that WFMS
can provide a more tight control over document-
related processes. Although, existing form-based
WFMS's support such activities, they are signi®cantly
limited as follows. First, the existing approaches
consider a whole document as a unit work. This means
that it is hard for an activity to deal with a part of one
document. Second, most commercial form-based
WFMS's use their own proprietary format. This
requires that to understand the document contents a
client application should know the format. Using
XML [34] as a form document format, we have been
able to develop an effective method that can resolve
the above problems.
We propose, an XML-based approach to WFMS for
form document processing on the Web. Taking advan-
tage of XML, we can partition a document into several
meaningful segments. A segment is a unit of work that
can be performed by some activities in a work¯ow
process. We develop a formal model that associates
those units of work with process activities. The pro-
posed model not only supports the execution of docu-
ment processing with respect to the document ¯ow, but
it also enables various useful services during the
document processing. A prototype system has been
implemented to demonstrate some important docu-
ment-related functions.
2. Backgrounds
2.1. Work¯ow management system
A WFMS in general is a software system that
de®nes, creates, and manages automated business pro-
cesses [2,11,21,23]. The WFMS helps users involved
in a business process to carry out their tasks following
certain business logic [19]. This means that the WFMS
should have a process model representing the business
logic. A process model consists of a number of
activities and their precedence relations [4,10]. Once
a process model is set up, the WFMS automatically
assigns activities to individual users based on the
model [24]. By logging in the system, a user can
identify a task list that the user has to carry out. The
system assists the user by delivering task related
information including due date, process name, priority
and status of task, input and output ®les, and so on.
These are presented on a user interface for WFMS
clients. On completing the task assigned, the user
noti®es the WFMS of the task results. Then, the WFMS
proceeds to the remained part of the process by assign-
ing the subsequent tasks to other relevant users.
Work¯ow Management Coalition (WfMC), an
international standard organization on WFMS, has
proposed a Work¯ow Reference Model (WRM)
[14,29±33]. Fig. 1 presents the general architecture
of WRM, which is adopted by most existing WFMSs.
WRM consists of ®ve components: work¯ow engine,
process de®nition tools, monitoring tools, work¯ow
clients, and invoked applications. The central part of
the system is the engine that interprets process de®ni-
tions, controls process execution, and manages work
items in user's work lists. It also interacts with work¯ow
participants, and invokes some required applications.
The process de®nition tools create process models and
store them in a proper format. There are two types of
work¯ow clients: work¯ow client applications and
invoked applications. While both perform work¯ow
activities, the former are controlled by human clients,
and the latter are software programs that perform the
activities automatically. The administration and mon-
itoring tools provide a user interface for administration
and supervision of work¯ow management.
Many recently released commercial WFMSs are
Web-based systems [13,27]. Such a system provides
location transparency by allowing a user to access the
system simply using a Web browser. Almost all the
Web-based WFMSs use HTML as client user inter-
faces. This, however, has several limitations particu-
larly in interfacing the work¯ow engine with the other
components in Fig. 1. As an alternative, we use
eXtensible Markup Language (XML), which is further
discussed in the next section.
2.2. XML
HTML has been popularized as the standard for
Web documents due to its simplicity and ease of use. It
therefore has been adopted in many Web-based
WFMSs. However, the use of HTML is limited in
that the tags are prede®ned and inextensible, deal with
 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
Fig. 1. WRM and interfaces [14].
only displaying aspects, and do not support represen-
tation of semantic structures [8]. Since one cannot
de®ne one's own tags and attributes and the tags in
themselves are meaningless, users and applications
are prohibited from manipulating individual contents
of a document. To overcome such limitations, Stan-
dard General Markup Language (SGML) [16] can be
used. However, SGML is much more complex than
HTML, and dif®cult to use [8].
We employ XML, a relatively new technology, which
takes advantages of both HTML and SGML [22]. It is
simpler than SGML, and more powerful than HTML.
The underlying basis of XML is at the separation of
document structure and presentation style [26]. In order
to use XML in Web applications, users need to have
XML Document Type De®nition (DTD) and stylesheet.
DTD de®nes a document structure using user-de®ned
tags and attributes to specify the semantic relationships
of document elements. The stylesheet speci®es how an
XML document is presented on a Web-browser. The
stylesheet speci®cation includes the presentation styles
of document contents, such as color, font, and size.
It has been recognized that XML has a great poten-
tial to many Web-based applications [9,22]. In the
WFMS area, a number of researchers have considered
taking advantage of the standard [6,20], and WfMC's
Wf-XML binding [30] is one of the early research
results. XML gives several advantages [22]. Among
those, the separation of presentation styles from con-
141
tents allows one to modularize form documents. Since
a stylesheet takes charge of the presentation, the data
content can be handled independently of the presenta-
tion [1]. In our approach, the content of a form docu-
ment is modularized into several parts using XML tags,
so that our system can handle each of the individual
parts. On the other hand, for the representation of the
form document, we use the eXtensible Styling Lan-
guage (XSL) stylesheet [35]. By altering the stylesheet,
an XML document can be viewed in many different
ways. This feature can be very effectively used to
provide different users with different presentations,
in particular for WFMS of which the participants
usually have different presentation requirements.
3. Workunit model
In a typical business process dealing with a form
document, an activity is associated with a set of
elements in the document. In this section, we describe
a formal model, called a workunit model, for the
association between process activities and form docu-
ments elements.
3.1. Process and workunit models
As mentioned earlier, a critical challenge in
our form-based work¯ow is to associate document
142 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
Fig. 2. (a) Document workunits, (b) process activities, and their associations.
contents with work¯ow activities. We propose the
concept of workunit. The term workunit is de®ned
as a logical partition of a form document, and is used
as a unit of work assignment. A workunit is composed
of several document components, such as labels, text
input ®elds, and check boxes. The hierarchical rela-
tions among document, workunit, and document com-
ponents are illustrated in Fig. 2a.
In the Fig. 2a, a folder is a logical space to store
all the documents processed in a work¯ow process.
We assume that a folder has one-to-one mapping
with a process instance, that is, a folder is created
whenever a new process instance is launched. This is
to make our problem simple, and the notion of
folder is not further considered in the rest of this
paper.
Fig. 2a indicates that a form document is composed
of a set of workunits. Fig. 2b shows a process dealing
with the form document. Fig. 2a and b shows that each
of the workunits is assigned to at least one activity of
the process. This is represented as directed arrows.
Such assignment of individual workunits to process
activities becomes possible because the form docu-
ment is modularized into workunits.
A formal de®nition of workunit model forms a
theoretical basis of our approach. We ®rst con-
sider the de®nitions of process and workunit as fol-
lows.
Definition 3-1 (Process). A process is defined as a
directed graph p ˆ …A; L†, where
 A ˆ fai ji ˆ 1; . . . ; Ng is the set of activities,
and
 L  f…ai ; aj †jai ; aj 2 Ag is the set of links, each
of which, for example, (ai, aj) represents that
the i-th activity immediately precedes the j-th
activity.
Definition 3-2 (Workunit). Consider a form document
dk, …k ˆ 1; . . . ; K†. The document is composed of a set
of workunits, and each workunit consists of a number
of fields as follows.
 dk ˆ fwm jm ˆ 1; . . . ; Mg;
 wm ˆ ffl jl ˆ 1; . . . ; Lg;
such that wm \ wn ˆ ;, and a ®eld fl is speci®ed
with a pair of name and value, that is, (®eld name,
value).
Based on the above two de®nitions, form document
elements and process activities are denoted using
common dot (
) notation. Let dk
wm be the m-th work-
unit of document dk, and p
ai, the i-th activity of
process p. This notation can be used with a wild card
(). For example, dk. represents all the workunits of
document dk.
 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154 143

3.2. Assignment of workunit to process p1:  " W

A  : ˆ fd1
w1 ; d1
w2 ; d1
w3 ; d1
w4 ; d1

w5 ; d2
w6 ; d2
w7 g (Ex5-3)
Using the de®nitions of process and workunit in
Section 3.1, the document-process association is p1:  " W
A d1 : ˆ fd1
w1 ; d1
w2 ; d1
w3 ; d1
represented as follows.
w 4 ; d1
w 5 g (Ex5-4)

Definition 3-3 (Document-process associations). The p1
a2 " W

A  : ˆ fd1
w2 ; d2
w6 g (Ex5-5)
association between document and process is repre- p1
a2 " W
A d2 : ˆ fd2
w6 g (Ex5-6)
sented using upward and downward arrows, that is, `"'
and `#'. There are four types of associations: activity d1 :  #W
A  : ˆ fp1
a1 ; p1
a2 ; p1
a4 ; p1
a5 ; p1
to workunit " W W
A , workunit to activity # A , process to

a6 ; p2
a7 ; p2
a8 ; . . . ; p2
a12 g (Ex5-7)
document " P , and document to process # D
D
P. d1 :  # W
A p1: ˆ fp1
a1 ; p1
a2 ; p1
a4 ; p1
a5 ; p1
a6 g
 "WA identifies all the workunits that are assigned to (Ex5-8)
an activity.
d1
w1 # W  : ˆ fp1
a1 ; p2
a7 g (Ex5-9)
 #WA identifies all the activities that a workunit is
A

assigned to. d1
w1 # W
A p1: ˆ fp1
a1 g (Ex5-10)
 "DP identifies all the documents that a process deals
…p1 " D
P †: ˆ fd1
w1 ; d1
w2 ; d1
w3 ; d1
w4 ; d1
with.
 #D
w 5 ; d2
w 6 ; d2
w 7 g (Ex5-11)
P identifies all the processes that deal with a
document. …d1 # D
P †: ˆ fp1
a1 ; p1
a2 ; p1
a3 ; p1
a4 ; p1
The use of our document-process association is
a5 ; p1
a6 ; p2
a7 ; p2
a8 ; . . . ; p2
a12 g
explained. Consider two process de®nitions p1 and (Ex5-12)
p2 shown in Fig. 3. Process p1 deals with two docu-
ments d1 and d2, and p2 does d1 and d3. Each document 3.3. Activity and workunit dependency
has several workunits, and the workunits are assigned
to activities as shown in Fig. 3. Typical uses of the A process activity is somehow interrelated with
associations are listed below. other activities. In De®nition 3-1, the interrelations
between two directly preceding activities are repre-
p1 " D
P  ˆ fd1 ; d2 g (Ex5-1)
sented using directed arcs. This can be more general-
d1 # D
P  ˆ fp1; p2g (Ex5-2) ized between two arbitrary activities as follows.

Fig. 3. Examples of document-process association.

144 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
Definition 3-4 (Activity dependency). Consider two
arbitrary activities ai and aj. These two activities have
either a precedence relation or a parallel relation as
follows.
 Activity precedence relation: there is a path in the
directed graph from ai to aj. If {(ai, ak), (ak, ak‡1),
f…ak ; ak‡1 †…ak‡1 ; ak‡2 †; . . . ; …ak‡n ; aj †g  L, then ai
and aj are in a precedence relation represented as
ai < A aj .
 Activity parallel relation: there is no path in the
process graph. If ai and aj do not have a precedence
relation, then they are in a parallel relation repre-
sented as ai jjA aj .
An activity precedence relation indicates that there
is a path from the ®rst activity to the second one. In
other words, the second activity is dependent on the
®rst. On the other hand, activities with a parallel
relation can be performed independently.
There exists similar dependency among workunits,
called workunit dependency. This speci®es the order
of processing the workunits. If one workunit should be
processed after another, the former workunit may not
be assigned to any activity that precedes the activity
for the latter. A de®nition of this workunit dependency
is presented below.
Definition 3-5 (Workunit dependency). Consider two
workunits wm and wn in a document d. These two
workunits have either a precedence relation or a
parallel relation as follows.
 Workunit precedence relation: if wn should be
processed after wm, then wn and wm are in a pre-
cedence relation represented as wm <W wn .
 Workunit parallel relation: If wm and wn do not have
a precedence relation, then they are in a parallel
relation represented as wm jjW wn .
3.4. Association rules
Considering the de®nitions in Section 3.3, we can
identify several rules that should be satis®ed when
assigning workunits to activities.
Definition 3-6 (Association rules). Consider a process
p that deals with a document d. The association of d's
workunits with p's activities should meet the follow-
ing four associations rules.
 Uniqueness: a workunit cannot be assigned twice or
more to the same activity.
For p:ai " W W
A d:wm and p:aj " A d:wn ;
…i ˆ j† ! …m 6ˆ n†
 Completeness: every workunit in d should be
assigned to at least one activity of p. That is,
For all i; d:wi # W
A p: 6ˆ f
 Consistency: a workunit cannot be associated to
parallel activities.
For p:ai and p:aj …i 6ˆ j†;
…p:ai jjA p:aj † ! …p:ai " W W
A  :† \ …p:aj " A  :† ˆ f
 Compatibility: if two workunits have a precedence
relation, this needs to be preserved in the relations
of the activities dealing with the workunits.
For all m and n…m 6ˆ n†;
…d
wm <W d
wn † ! ai <A aj or
ai ˆ aj …ai 2 d
wm # W
A p:; aj 2 d
wn # W
A p:†
When a document-process association violates any
of these rules, it does not guarantee a proper proces-
sing of the document with the process. First, the
uniqueness rule states that it is simply meaningless to
assign a workunit to an activity multiple times.
Second, it is obvious that a violation of the com-
pleteness rule leaves some workunits not handled
until the end of a process execution. Third, for the
consistency rule, consider a situation that a workunit
is assigned to two or more activities that are in a
parallel relation. Since such activities can be exe-
cuted concurrently, it may produce inconsistent docu-
ment. A simple way to prevent the inconsistency is
disallowing such assignment. Another is to employ a
version control or advanced transaction model, but is
out of the scope of this paper. The ®nal rule states
that there should be compatibility between workunit
dependency and activity dependency. If two work-
units have a precedence relation, either the relation
should be maintained in the activities to which the
workunits are assigned or both workunits be assigned
to the same activity. Notice that activity dependency
does not always mean workunit dependency, how-
ever.
 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
4. Form document monitoring
The workunit model addressed in Section 3 enables
several document-related functions in WFMS. This
includes automatic identi®cation of relevant docu-
ments for individual activities and handling of the
contents contained in a certain part of form document.
Another interesting and important function is form
document monitoring. In general, work¯ow monitor-
ing is the ability to trace processes being currently
carried out and to report summary statistics over past
processes [33]. Almost all work¯ow systems provide
tools for this service, but most deal with process-
related information. We focus on the form document
monitoring in this section, since it should involve the
above two document-related functions.
4.1. Monitoring template
We provide form document monitoring with a mon-
itoring template. A monitoring template is actually a
monitoring pattern of a certain user. A monitoring
template speci®es objects to monitor and conditions
to con®ne the boundary of the objects to be monitored.
The monitoring template is de®ned as follows.
Definition 4-1 (Monitoring template). Monitoring
Template T consists of object elements ou and mon-
itoring elements mv , that is, T ˆ ‰fo1 ; o2 ; . . . ; ou g;
fm1 ; m2 ; . . . ; mv gŠ. An object element ou is a set of
objects that are homogeneous in that they all meet
certain conditions. A monitoring element mv is a set of
monitoring attributes whose values are returned by
applying some functions to the object element.
 ou ˆ …hobject typei hobject aliasi: hcondition(s)i),
where object type can be a process, activity, docu-
ment, workunit, or field, and object alias is a name
given to the set of homogeneous objects that meet
condition(s). The condition(s) restricts the object
set.
 mv ˆ hfunction…s†i (h<object (alias)i), where func-
tion returns some attribute values of objects. The
functions that can be used in a template are
explained in the next section. The arguments of
the function can be a set of objects or an alias.
In specifying ou and m v, we use the document-
process association in Section 3 and monitoring func-
145
tions. The monitoring functions are detailed in the
subsequent section.
The use of monitoring template is explained with an
example. Suppose that a user wants to monitor all the
documents that have been created since 4 April 2000
in process p1. The user is interested in the documents'
names, employees in charge of, and the duration of
each activity that is associated with the documents'
workunits. The user is also concerned with the pro-
ductivity of p1's activities dealing with d1's workunits
that are performed by Mr. Hur. This is compared with
that of the activities dealing with the same document's
workunits but performed by Mr. Bae. For this pro-
ductivity comparison, the user wants to analyze the
actual durations of those two groups of activities using
the ANOVA analysis [25].
The monitoring template for the above example
situation is provided below.
T1 ˆ ‰fo1 ; o2 ; o3 ; o4 g; fm1 ; m2 ; m3 ; m4 ; m5 gŠ
o1 ˆ …document d1 : creation-t…p1 " D
P †
> ``4 April 2000'' †
o2 ˆ …activity a1 : worker…d1
 # W
A p1
† > ``Hur''†
o3 ˆ …activity a2 : worker…d1
 # W
A p1
† ˆ ``Bae''†
o4 ˆ …activity a3 : …d1 :† # W
A  :†
m1 ˆ …name; user†…d1 †
m2 ˆ duration…a3 †
m3 ˆ …name; start t; urgency; duration†…a1 †
m4 ˆ …name; start t; urgency; duration†…a2 †
m5 ˆ anova…duration…a1 †; duration…a2 ††
The object elements, o1, o2, o3, o4, specify the
objects required for the monitoring, and the monitor-
ing elements, m1, m2, m3, m4, m5, denote the attributes
to monitor and the analysis to be carried out. In the
template, variable d1 in o1, which is used to refer to a
document, appears again in m1. The variable, d1 in o1,
declares the objects, and d1 in m1 indicates that it
simply uses the object. This applies to the use of all the
other variables. The object aliases in the monitoring
elements are used to make it easy to transform directly
a template into database query that is described in a
later section.
146 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154

Table 1
Basic monitoring functions

Object type Function Meaning Return value type Example

Folder, document, and workunit creation-t Creation time Date creation-t(d)

modified-t Modified time Date modified-t(d
w)
lock-state Lock-state {Locked, unlocked} lock-state(d
w)
user User String user(d
w)
length Length Integer length(d)
name Name String name(d)
Field value Field value Integer, float, date, string value(d
w
f)
length Field length Integer length(d
w
f)
Process and activity (: activity only) state State {Not ready, ready, state(p)
doing, done, failed}
duration Duration Float duration(p)
start-t Start time Date start-t(p
a)
finish-t Finish time Date finish-t(p
a)
urgency Urgency Boolean urgency(p
a)
worker User String worker(p
a)
priority Priority Integer priority(p
a)

4.2. Monitoring functions
A monitoring template uses some functions. There
are two types of monitoring functions: basic monitor-
ing functions and analytic monitoring functions. A
basic monitoring function is one that simply returns
attribute values. An analytic monitoring function is
applied to the results of basic monitoring function and
derives a new value from them. Some basic and
analytic monitoring functions are listed in Table 1
and Table 2, respectively. Notice that the functions are
also based on the workunit model in Section 3.
For example, the basic monitoring function, mod-
i®ed-t(d
w), returns all the dates and times when the
workunit, d
w, is modi®ed. The derived monitoring
function, max(modi®ed-t(d.)), returns the latest one
among all the results of modi®ed-t(d.).
4.3. Monitoring query
Once a monitoring template is de®ned, it needs
to be transformed into a database query language
that retrieves relevant records from a work¯ow data-
base.

Table 2
Analytic monitoring functions

Function Example Description


count count(urgency(p. )) The number of urgent activities in process p
max max(value(.w
f)) The maximum value of field w
f in all the document instances
min min(value(d..f)) The minimum value of field f in all the workunits of document d
sum sum(value(.w
f)) The sum of values of field w
f of all the document instances
avg avg(duration(p.)) The average duration of all the activities in process p
var var(duration(p.)) The variance of duration of all the activities in process p
sd sd(duration(p.)) The standard deviation of duration of all the activities in process p
anova anova(duration(p1.), The result of ANOVA analysis on the duration of the activities in
duration(p2.), duration(p3.)) processes p1, p2, and p3
reg reg(dur(p),val(d
w
f)) The result of regression with the duration of process p and the
values of field d
w
f
cor cor(urgency(p
a1), urgency(p
a2)) The correlation between urgencies of p
a1 and p
a2
 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
A monitoring element using basic monitoring func-
tions is transformed into an SQL language. Object
elements in a monitoring template determine database
tables and conditions. That is, the elements contain the
information needed to specify FROM and WHERE
clauses of a query statement. A special care is exer-
cised in handling the document-process association
described in Section 3.2. The association is always
transformed into a join operation in a WHERE clause.
The elements also determine the ®elds to retrieve, and
thus are used in a SELECT clause. The algorithm
developed for this transformation is available in [7].
For example, the monitoring element, m1, in Sec-
tion 4.1 can be transformed into an SQL query state-
ment. The monitoring element is de®ned based on
the monitoring object o1. Notice that the object set
is de®ned on process p1, which is associated with
documents, and the document is con®ned to those
that are created after 4 April 2000. It is straightfor-
ward to identify these three conditions from the
monitoring element speci®cation, and thus the algo-
rithm transforms them to those three conditions in the
WHERE clause. The resulting query statement is
as follows.
SELECT d.name, d.user
FROM document d, process p
WHERE p.process_idˆ`p1'
AND d.process_id ˆ p.process_id
AND d.create_t<TO_DATE(`4 April 2000')
Consider a more complex example m2 that involves
sub-queries. The transformation of such a query is
basically the same with the above simple example,
but the algorithm generates the sub-query since the
object element, o4, uses another object element o1.
Our algorithm outputs the following query statement
for m2.
SELECT a.duration
FROM activity a, workunit w
WHERE a.activity_id ˆ w.activity_id
AND w.workunit_id ˆ (SELECT ww.workunit_id
FROM workunit ww)
WHERE ww.document_id ˆ (SELECT d.docu-
ment_id)
FROM document d, process p
WHERE d.process_id ˆ p.process_id
AND p.process_idˆ`p1'
AND d.create_t < TO_DATE(`4 April 2000'))
147
For some analytic functions, like count, max, min,
etc., we can simply apply corresponding database
operations to the query results of basic monitoring
functions. For the other analytic functions, like var-
iance, ANOVA analysis, and regression, we can call a
relevant function that a statistical package provides.
5. XML representation in prototype
implementation
The proposed workunit model in Section 3 is
indeed enabled by XML and its related technologies.
In this section, the use of XML is described with a
prototype implementation of our work¯ow manage-
ment system.
5.1. System architecture
First of all, consider the overall architecture of our
system illustrated in Fig. 4. The system is composed of
®ve main components: process designer, form
designer, work¯ow engine, work¯ow database, and
client applications. The ®rst two, called build-time
modules, are implemented in Microsoft Visual C‡‡.
The others, run-time modules, are in Java servlet and
JSP [5], so that our system becomes platform-inde-
pendent in the Web environment.
Our system architecture is basically the as with that
of WfMC's WRM. Components of WFMS are often
classi®ed into two types: build-time and run-time
functions. A build-time function is mainly concerned
with de®ning a process model, whereas a run-time
function with executing, controlling, and monitoring
of the process de®ned. Our architecture differs from
WRM in the functions related to form document
processing.
Our system has two build-time modules: a process
designer and a form designer. The process designer
module, shown at the right hand side of Fig. 5, is used
to generate a process model. In the ®gure, a typical
process model is presented. The use of the process
designer is almost the same as that of the existing
WFMS's. On the other hand, the form designer mod-
ule, which does not appear in the WRM, is used to
create XML form documents. The form designer is
shown at the left hand side of Fig. 5. It currently shows
a form document to be processed in the process
148 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154

Fig. 4. System architecture.

created by the process designer. Notice that the form
document is partitioned into several workunits, and
their relationships are presented in a tree structure.
Once a process model and a form document are both
prepared, the workunits in the document can be asso-
ciated with the activities in the process model. In the
®gure, an arrow indicates such an association.
Process, form document, and their association mod-
els are stored in a work¯ow database. Based on these
models, run-time functions of our WFMS can work

Fig. 5. Form designer and process designer.

 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
with an actual business process. At the core of the run-
time functions is the work¯ow engine. The engine
communicates with work¯ow client, work¯ow mon-
itoring, and invoked applications during executing the
process. This is implemented on the basis of the XML
representation and document-process association
model, as is expressed in the subsequent sections.
5.2. XML representation of form document
In our system, a form document is represented in the
XML format. A simple example XML document is
shown in Fig. 6. This ®gure also shows a class diagram
designed to implement our workunit model. The class
diagram describes the relationships of XML document
objects. Every class has its corresponding objects in an
XML document. (The folder class represents a set of
documents that are dealt with in a process model.) The
document class is mapped to the entire XML docu-
ment, and a workunit and ®eld is mapped to a certain
part of the document. The example document has three
workunits, and each workunit has three ®elds. A
workunit is speci®ed using an XML attribute, and a
®eld is enclosed in an XML tag. For example, the ®rst
Fig. 6. Class diagram for (a) workunit model and (b) XML representation of workunits.
149
`PRODUCTSTATE' workunit is identi®ed as
`WS_P001_01', which contains three ®elds,
`ORDERQTY', `PRODUCTIONQTY', and `INVEN-
TORYQTY'.
An XML document contains data only. In order to
present the contents, we should have styling formats.
There are several styling languages, such as XSL and
CSS. We use XSL, which speci®es how form data are
viewed and whether the data are modi®able or read-
only. The style formatting classes in Fig. 6 show
styling components, such as label, text input ®eld,
and so on. The modi®ability is speci®ed as an
attribute of the component class. Such speci®cations
on document styling appear in an XSL stylesheet.
Once an XML document and a corresponding XSL
stylesheet are prepared, the document can be viewed
directly and operated on a Web browser. Our system
requires no additional module to handle the form
document.
Example styles of XML form document are pre-
sented in Fig. 7. The two styles are generated from one
XML form document by applying different XSL
stylesheets. Consider the two workunits indicated
in the ®gure. Suppose that the document-process
150 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
Fig. 7. Different presentation of one form document: (a) form document A and (b) form document B.
association model contains a condition that `Workunit
1' and `Workunit 2' be processed by `activity 1' and
`activity 2', respectively. When our work¯ow engine
orders a client user to perform the document operation
for `activity 1', it checks out the form document A
shown in Fig. 7a. Notice that only the workunit
associated with the activity is enabled, but the other
disabled. The form document B in Fig. 7b is similarly
created for `activity 2'. However, in this form, the
workunit for `activity 1'is disabled. Our system can
control this modi®ability by applying different XSL
stylesheets to one XML document.
Regarding with a monitoring application, the mon-
itoring template explained in Section 4 can be used. A
template, once de®ned, is transformed into a database
query. Consider the monitoring template, T1, in Sec-
tion 4. The query results are presented in Fig. 8. Here,
XML is used once again, and thus the presentation can
be readily altered re¯ecting monitoring users' roles
and preferences.
5.3. Monitoring template with invoked application
Another use of monitoring template is found with
communication between work¯ow engine and
invoked applications. Our workunit model and
XML-based approach provide a promising way for
the interaction. We adopt simple object access proto-
col (SOAP) [36], which is an XML-based standard
protocol for exchanging messages among heteroge-
neous systems.
During run-time, the work¯ow system generates an
input SOAP message to an invoked application. The
input message includes two types of information:
input data and task instruction. First, a monitoring
template is de®ned for the data that should be input to
an invoked application. Then, a database query for the
template is built and executed to obtain the input data.
The task instruction is to let the application know the
task that the application should perform with the input
data. The task is identi®ed from the activity descrip-
 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154 151

Fig. 8. An example use of monitoring template.

tion in a process model. The task instruction and the
query results are transformed into an XML message,
like the one in Fig. 9.
For example, consider an object element and a
monitoring element as follows.
o5 ˆ …field f1 : …p1:  " W
A d1
w1 †:†
m6 ˆ …name; value; user†…f1 †
The work¯ow system can specify the input data to an
invoked application with the monitoring element. The
object element presents all the data ®elds of workunit
w1 in document d1 that are processed by activities of
process p1. The required input data, name, value, and
user, are retrieved and transformed to the SOAP
message in Fig. 9. The invoked application is sup-
posed to calculate an optimal order quantity based on
the values in the speci®ed ®elds. This task appears in
the task instruction tag, that is, CalculateOrderQuan-
tity. The name of the tag can be automatically retrieved
from an activity description in a process model de®ned
at build-time.
152 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
Fig. 9. An example SOAP message sent to an invoked application.
The output that the application program produces is
returned to the work¯ow engine. Since this return
message is also in an XML format, the engine can
interpret it and an appropriate workunit can be ®lled in
with the message contents, if necessary. This mechan-
ism can also be used for the analytic functions in
Section 4.2.
The XML-based approach can be applied to agent
communication in agent-based work¯ow systems
[15]. In addition, if other work¯ow systems support
the SOAP protocol, they can be treated as invoked
applications and thus it can be interfaced with our
system. This provides a method of interoperation
among heterogeneous work¯ow systems.
6. Conclusions and further research issues
The main purpose of our research is to develop an
effective method of handling form documents con-
sidering the semantics of work¯ow processes. Since
traditional WFMSs supporting a simple delivery of
form documents cannot handle a part of the document
elements, it is dif®cult to make any meaningful action
based on the contents. To solve this problem, an
XML-based document-process association model is
proposed. Our approach supports the semantic rela-
tionships between a form document and a work¯ow
process. The use of XML can partition a form docu-
ment into several meaningful parts. This document
modularization provides a basis for sophisticated con-
trol of document contents during a process execution.
We have developed a formalized model to associate
objects in form documents with a process model. This
model can support various document-related functions
in WFMS. A set of document objects or their proper-
ties can be easily obtained through database queries,
so that our approach facilitates document-related
activities. It also makes it easy to customize the
monitoring environment for individual users. Another
advantage is that a work¯ow engine can interact with
an invoked application based on document contents. A
prototype system has been implemented to demon-
strate these advantages.
An interesting further research issue is to augment
WFMS functions with synchronous collaboration.
WFMS is a typical example of asynchronous colla-
boration system, like groupware and electronic docu-
ment management systems. For the synchronous
collaboration, however, it requires a ®ne control
mechanism to avoid inconsistency among document
contents, maintain dynamic changes in the documents,
and handle exceptions [12,17]. Advanced transaction
models [3] and technologies in computer supported
cooperative work [28] may be able to provide a
potential solution to these issues.
 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
Acknowledgements
This research was supported by the program of
National Research Laboratory granted from Korea
Institute Science and Technology Evaluation and
Planning, and carried out at the Research Institute
of Engineering Science at Seoul National University.
The authors would like to thank the anonymous
referees for their constructive comments which have
greatly improved the quality of the paper.
References
[1] S. Abiteboul, On Views and XML, in: Proceedings of the 18th
ACM SIGMOD±SIGACT±SIGART Symposium on Principles
of Database Systems, Philadelphia, PA, USA, 1999, pp. 1±9.
[2] G. Alonso, H.J. Schek, Research Issues in Large Work¯ow
Management Systems, in: Proceedings of the NSF Workshop
on Work¯ow and Process Automation in Information
Systems, University of Georgia, GA, USA, 1996, pp. 126±
132.
[3] G. Alonso, D. Agrawal, A.E. Abbadi, M. Kamath, R.
GuÈnthoÈr, C. Mohan, Advanced Transaction Models in Work-
¯ow Contexts, in: Proceedings of the 12th International
Conference on Data Engineering, New Orleans, LA, USA,
1996, pp. 574±581.
[4] I.B. Arpinar, U. Halici, S. Arpinar, A. DogÏac, Formalization
of Work¯ows and Correctness Issues in the Presence of
Concurrency, Distributed and Parallel Database 7 (1999) 199±
248.
[5] D. Ayers, H. Bergsten, M. Bogovich, J. Diamond, M. Fettis,
M. Fleury, P. Houle, P. Mohseni, A. Patzer, R. Phillips, S. Li,
K. Vedati, M. Wilcox, S. Zeiger, Professional Java Server
Programming, Wrox, Birmingham, UK, 2000.
[6] H. Bae, H. Yoon, Y. Kim, S. Kang, XML-based Interfaces for
Work¯ow Management Systems, in: Proceedings of
ICPR2000 Conference, Bangkok, Thailand, 2000.
[7] H. Bae, Y. Kim, A Transformation algorithm of work¯ow
monitoring data into SQL Languages, SNU-Technical Paper-
IS-2001-05, Seoul National University, 2001.
[8] F. Boumphrey, O. Drenzo, J. Duckett, J. Graf, D. Hollande, P.
Houle, T. Jenkins, P. Jones, A. Kingsley-Hughes, K.
Kingsley-Hughes, C. McQueen, S. Mohr, Professional XML
Applications, Wrox, Birmingham, UK, 1999.
[9] F.P. Colye, Legacy Integration-Changing Perspectives, IEEE
Software 17 (2) (2000) 37±41.
[10] S. Das, K. Kochut, J. Miller, A. Sheth, D. Worah, ORBWork:
a Reliable Distributed CORBA-based Work¯ow Enactment
System for METEOR_2, Technical Report no. UGA-CS-TR-
97-001, Department of Computer Science, University of
Georgia, GA, USA, 1997.
[11] D. Georgakopoulos, M. Hornick, A. Sheth, An overview of
work¯ow management: from process modeling to work¯ow
153
automation infrastructure, Distributed and Parallel Databases
3 (2) (1995) 119±154.
[12] C. Hagen, G. Alonso, Exception handling in work¯ow
management systems, IEEE Transactions on Software
Engineering 26 (10) (2000) 943±958.
[13] Handysoft, Collaborative Content Management, White Paper,
http://www.handysoft.com, 2000.
[14] D. Hollingsworth, Work¯ow management coalition speci®ca-
tion: the work¯ow reference model, WfMC speci®cation,
1994.
[15] A. Inamoto, Agent oriented system approach for work¯ow
automation, International Journal Production Economics 60/
61 (1999) 327±335.
[16] ISO, Information Processing-text and Of®ce Systems,
Standard Generalized Markup Languages, ISO standard,
ISO 8879, 1986.
[17] D.K.W. Chiu, Q. Li, K. Karlapalem, A Meta Modeling
Approach to Work¯ow Management Systems Supporting
Exception Handling, Information Systems 24 (2) (1999) 159±
184.
[18] Y. Kim, S. Kang, D. Kim, J. Bae, K. Ju, WW-Flow: Web-
based work¯ow management with runtime encapsulation,
IEEE Internet Computing 4 (3) (2000) 55±64.
[19] N. Krishnakumar, A. Sheth, Managing heterogeneous multi-
system tasks to support enterprise-wide operations, Distrib-
uted and Parallel Databases 3 (2) (1995) 155±186.
[20] A. Kristensen, Formsheets and the XML Forms Language,
Computer Networks 31 (1999) 1189±1201.
[21] P. Lawrence, 1997, Work¯ow Handbook 1997, Wiley, USA,
New York.
[22] H. Maruyama, K. Tamura, N. Uramoto, XML and Java
Developing Web Application, Addison-Wesley, MA, 1999.
[23] S. McCready, There is more than one kind of Work¯ow
Software, Computerworld, 2 November 1992.
[24] J.A. Miller, A.P. Sheth, K.J. Kochut, X. Wang, CORBA-based
Run-Time Architectures for Work¯ow Management Systems,
Journal of Database Management 7 (1) (1996) 16±27.
[25] J. Neter, W. Wasserman, M.H. Kutner, Applied Linear
Statistical Models, 3rd Edition, IRWIN, IL, 1990.
[26] G. Salvato, I.J. Leontaritis, P. Winstone, M. Zelm, D. Rivers-
Moore, Presentation and Exchange of Business Models with
CIMOSA_XML, Computers in Industry 40 (1999) 125±139.
[27] Pic. Staffware, Staffware 2000 Functionality, White Paper,
http://www.staffware.com, 1999.
[28] R. Walter, S. Jean, V. Gerd, W. Michael, CSCW Tools:
concepts and architectures, Computer 27 (1994) 28±36.
[29] WfMC, Interoperability Internet e-mail MIME Binding,
WfMC Standards, WFMC-TC-1018, http://www.wfmc.org,
2000.
[30] WfMC, Interoperability Wf-XML Binding, WfMC Stan-
dards, WFMC-TC-1023, http://www.wfmc.org, 2000.
[31] WfMC, Interface1: Process De®nition Interchange Process
Model, WfMC Standards, WfMC-TC-1016-P, http://
www.wfmc.org, 1999.
[32] WfMC, Work¯ow Management Application Programming
Interface (Interfaces 2 & 3) Speci®cation, WfMC Standards,
WfMC-TC-1009, http://www.wfmc.org, 1998.
154 H. Bae, Y. Kim / Computers in Industry 47 (2002) 139±154
[33] WfMC, Work¯ow Management Coalition Audit Data Speci-
®cation, WfMC Standards, WfMC-TC-1015, http://
www.wfmc.org, 1998.
[34] World Wide Web Consortium (W3C), Extensible Markup
Language (XML) 1.0, W3C Recommendation, http://
www.w3c.org/TR/REC-xml.html, 1998.
[35] World Wide Web Consortium (W3C), Extensible Stylesheet
Language (XSL) 1.0, W3C Candidate Recommendation,
http://www.w3c.org/TR/xsl/, 2000.
[36] World Wide Web Consortium (W3C), Simple Object Access
Protocol (SOAP) 1.1, W3C Note, http://www.w3.org/TR/
2000/NOTE-SOAP-20000508, 2000.
Hyerim Bae is a PhD candidate in
department of industrial engineering at
Seoul National University. He received
his BS and MS degrees in industrial
engineering from The Seoul National
University in 1996 and 1998, respec-
tively. His research interests include
information system design, engineering
databases, Web-based application development, work¯ow manage-
ment system, and document version management.
Yeongho Kim is an associate professor in
the Department of Industrial Engineering
at The Seoul National University. He
received his PhD degree from The North
Carolina State University and BS and MS
degrees from The Seoul National Univer-
sity. He is interested in the areas of Inter-
net applications, concurrent engineering
and collaborative design, engineering
databases, and AI applications in manu-
facturing. His research topics cover a
wide variety of areas including work¯ow management systems,
product data management, and computer supported collaborative
work on the Internet. He is a member of the Editorial Board of
International Journal of Industrial EngineeringÐApplications and
Practice, International Journal of Management Systems, and Inter-
national Journal of CAD/CAM.