Content uploaded by Maria Orlowska
Author content
All content in this area was uploaded by Maria Orlowska on Jul 12, 2014
Content may be subject to copyright.
On Capturing Process Requirements of
Workflow Based
Business Information Systems*
Wasim Sadiq and Maria E. Orlowska
Distributed Systems Technology Centre
Department of Computer Science & Electrical Engineering
The University of Queensland
Australia
email: {wasim, maria}@dstc.edu.au
Abstract
The workflow technology manages the execution of business activi-
ties and coordinates the flow of information throughout the enter-
prise. It is emerging as one of the fastest growing disciplines in
information technology. It is essential to correctly and effectively
capture the workflow specific requirements of business information
systems before their deployment through workflow management
systems. In this paper, we look at different issues in capturing such
requirements and propose a systematic layered modeling approach.
We split the workflow specification requirements into five basic di-
mensions: structure, data, execution, temporal, and transactional.
The concepts introduced in this paper have been applied as a foun-
dation to the development of a workflows modeling and verification
tool, FlowMake.
1. Introduction
The past few decades have witnessed a tremendous growth in business process
automation. It is essential to understand the operations of business processes before
any information systems are developed and implemented. For this purpose, busi-
ness data and process modeling methodologies are used. Data requirements are
modelled through conceptual data modeling methodologies like entity-relationship,
and process modeling methodologies like data flow diagrams, are used to identify
business processes and capture the flow of information between them.
Organizations are partitioned into several functional areas and information sys-
tems are deployed for each of the divided areas. Activities within a functional
—————
*The work reported in this paper has been funded in part by the Cooperative Research
Centres Program through the Department of the Prime Minister and Cabinet of the Com-
monwealth Government of Australia.
business area are either manual, automated, or a combination of both. For large
organizations, the systems supporting the functional areas run in heterogeneous
and distributed hardware and software environments. Generally, each system itself
is also developed following a modular approach. The related modules and systems
must communicate and coordinate with each other to effectively achieve their
functional objectives.
The coordination of these automated or manual activities has historically been
performed manually. In recent years, the possibility of automating such coordina-
tion is being explored through workflow technology. The Workflow Management
Coalition [14] defines workflows as “The automation of a business process, in
whole or part, during which documents, information or tasks are passed from one
participant to another for action, according to a set of procedural rules.” Workflows
represent the organizational flow of information from one processing entity, either
manual or automated, to another. The processing entities use this information to
accomplish assigned tasks. These tasks take some information from the preceding
tasks, perform some work based on the information received using the services of
the assigned processing entities, and proceed to the next task(s) in the workflow.
The on-line information management systems accomplish much more automa-
tion than their batch-oriented counterparts. Sophisticated computerization provides
further possibilities for automating the execution coordination. Workflow man-
agement systems provide capabilities to partially or fully take over the responsi-
bility for coordinated execution of workflow tasks from human coordinators. The
execution coordination involving tasks and processing entities is accomplished by
enforcing associated business process rules and constraints.
Before a workflow management system can be deployed to manage workflows,
process definition tools are required to model workflow processes. Information about
the process rules and constraints is stored in the workflow repository. The workflow
management systems make extensive use of this repository in their operation.
On the basis of the process definitions, workflow management systems create and
execute workflow instances and coordinate the interactions between its tasks.
The workflow management systems promote a component oriented information
systems development approach. The workflow based information systems separate
the process logic from application logic. The process logic is implemented through
a workflow management system and the application logic through underlying ap-
plication components. Whereas, in conventional information system both process
logic and application logic are embedded into the same system. This separation
requires that at the time of capturing the requirements of information systems
a clear distinction be made between these two types of requirements. This paper is
an attempt to provide a framework that helps in capturing the process logic re-
quirements of workflow based information systems.
There are several workflow management systems in the market. Most of these
products also provide graphical tools and a variety of modeling languages to define
workflows. We believe, however, that there is a need to identify and systematically
classify the issues that should be targeted during the workflow modeling process.
The major contribution of this paper is to provide a breakup of the modeling effort
into five intuitive phases. Furthermore, we identify a means of capturing different
requirements of workflow applications. A CASE tool, FlowMake, for workflow
modeling and verification has also been developed as an outcome of this work. The
FlowMake provides workflow analysts and designers a well-defined framework to
model and reason about various aspects of workflows.
2. Partitioning the Workflow Model
The primary objective of a workflow management system is to coordinate the exe-
cution of activities or tasks in an organization. Correspondingly, a workflow
modeling framework should cover the techniques and tools to capture, analyze,
and specify different aspects of tasks and their coordination.
Objects
Performers
Tasks
Constraints
Perform
Control
Manipulate
Control
Figure 1. Workflows building blocks
We divide a workflow application into four building blocks: objects, tasks, per-
formers, and constraints. The overall characteristics of these four components iden-
tify the nature of the application. We use the keyword work to define these four
building blocks:
– Work is performed on Objects. An object is any entity of interest.
– Tasks specify the work to be done. The work specified by tasks is generally
performed on objects or on the basis of information contained in objects.
– Performers carry out the work. Tasks cannot perform the work themselves.
They need the services of performers.
– Constraints control correct execution of the work. Tasks specify what to do
and performers carry out that work. The constraints ensure that the work is
performed correctly.
The motivation of the work presented in this paper is to specify a framework for
capturing the workflow specific requirements of a business information system.
In other words, capturing the essential information pertaining to the above men-
tioned four building blocks.
A workflow management system coordinates the execution of tasks. Looking
at Figure 1, we realize that this coordination is dependent on the constraints block.
The performers execute tasks conforming to the specified constraints. As such,
a primary objective of workflow modeling is to capture and ensure the correctness
of these constraints.
One way to enhance the understanding of workflow models and to reduce the
complexity is to divide the modeling activity into phases. By adopting a layered
modeling approach, we can capture and analyze the modeling information for each
of the phases. Eventually requirements captured in all phases could be combined
into an integrated workflow model.
Workflows
Structure
Data
Temporal
Transactional
Execution
Figure 2. Partitioning the workflow model
We propose to divide the modeling effort into five phases: structure, data, exe-
cution, temporal, and transactional. In the following sections, we briefly explain
the process information captured under each phase.
2.1. Structure
A workflow is a set of tasks that are performed to achieve some business objec-
tives. Generally, the tasks in a workflow are inter-related in such a way that the
initiation of one task is dependent on the successful completion of a set of other
tasks. Therefore, the order in which tasks are executed is very important.
The first phase of this modeling framework captures the flow of execution
from one task to another. The structural modeling of a workflow defines the way
a workflow management system would order and schedule workflow tasks. This is
the primary and perhaps the most important aspect of a workflow model and builds
a foundation to capture other aspects of workflow requirements.
Generally, information modeling techniques include graphical representation
that enhances the understanding of the model. A workflow specification could also
be represented using graphical objects. In this section, we briefly describe the
structural aspect of our workflow modeling language and its graphical representa-
tion. This language is based on generic workflow modeling concepts as described
in Workflow Management Coalition [15]. For a more detailed description, the reader
is referred to [13].
The workflow models in this graphical language are modeled using two types
of objects: node and control flow. Node is classified into two subclasses: task and
condition. A task, graphically represented by a rectangle, represents the work to be
done to achieve some objectives. It is also used to build sequential, concurrency,
and synchronization structures. It is the primary object in workflow specifications
and could represent both automated and manual activities. Tasks are executed
by assigned performers. A condition, graphically represented by a circle, is used to
construct or-split and or-join structures. A control flow links two nodes in the
graph and is graphically represented by a directed edge. By connecting nodes with
control flows through five modeling structures, as shown in Figure 3, we build di-
rected acyclic graphs (DAG) called workflow graphs where nodes represent vertices
and control flows represent directed edges. From now on, we will refer to vertices
as nodes and edges as flows.
Initial Concurrency
Sequence
Choice Merge
Nesting
Final
Synchronization
Figure 3. Workflow modeling structures
Sequence is the most basic modeling structure and defines the ordering of task
execution. It is constructed by connecting at the most one incoming and one out-
going flow to a task. A concurrency structure is used to represent concurrent paths
within a workflow graph and is modeled by connecting two or more outgoing
flows to a task. At certain points in workflows, it is essential to wait for the com-
pletion of more than one execution path to proceed further. A synchronization
structure, represented by more than one incoming flow to a task, is applied to syn-
chronize such concurrent paths. A synchronization task waits until all the incoming
flows have been triggered.
A choice structure is used to model mutually exclusive alternative paths and is
constructed by attaching two or more outgoing flows to a condition object. At run-
time, the workflow selects one of the alternative execution paths for a given in-
stance of the business process by activating one of the outgoing flows originating
from the choice condition object. The choice structure is exclusive and complete.
The exclusive characteristic ensures that only one of the alternative paths is selected.
The completeness characteristic guarantees that, if a condition object is activated,
one of its outgoing flows will always be triggered. A merge structure is “opposite”
to the choice structure. It is applied to join mutually exclusive alternative paths into
one path by attaching two or more incoming flows to a condition object.
Since a workflow model is represented by a directed acyclic graph (DAG),
it has at least one node that has no incoming flows (source) and at least one node
that has no outgoing flows (sink). We call these initial and final nodes respectively.
To uniquely identify a final node for a workflow graph, we join all split struc-
tures. Therefore, a workflow graph contains only one initial and one final node.
A workflow instance completes its execution after its final node has completed its
execution.
We need the iteration structure to model the repetition of a group of tasks within
a workflow. The iteration is modeled through block structures. As long as a certain
condition is met, a sub graph of the workflow is repeated.
The nesting structure simplifies the workflow specifications through abstraction.
Using this construct, we can encapsulate a workflow specification into a task and
then use that nested task in other workflow specifications. For each execution of
a nested task, the underlying workflow is executed.
The Workflow Management Coalition [15] identifies four primary workflow
control structures: or-split, or-join, and-split, and and-join. These are represented
in our model through choice, merge, concurrency, and synchronization structures
respectively. We have the condition object to model the choice and merge struc-
tures. However, the concurrency and synchronization structures are represented
simply by directly connecting flows to tasks. This approach reduces the number of
modeling objects but at the same time allows explicit notation for workflow struc-
tural models. Nevertheless, in certain cases, it requires the use of null tasks whose
only purpose is the coordination of flow and compliance to the syntactical correct-
ness criteria of workflow structures.
2.2. Data
The workflow tasks are generally defined and executed outside the workflow man-
agement system. The coordination relationship among these tasks is modeled
through control flow specifications. A data dependency may also exist between
tasks that is not identified in control flow specifications. A task T1 is called data
dependent on another task T2 if, for its successful execution, it requires the data
produced or provided by T2. Such a relationship is modeled by using a data flow
that specifies the mapping between data provided by the T1 and received by T2.
As shown in Figure 1, performers are responsible for task execution. During task
execution some objects are manipulated by tasks. While the performers execute
tasks they make use of or generate some data regarding the objects they work on.
Performer
Performer
Data
Workflow
Data
Common
Data
Task
Figure 4. Task and performer data relationship
We classify such data in three categories: performer data, workflow data, and
workflow specific performer data. The performer data is generally invisible to the
workflow application unless the performer makes it available to the workflow man-
agement system. The workflow data is local to the workflow management system
and is used for coordinating the task scheduling and execution. A subset of workflow
and performer data is common and called workflow specific performer data. The
workflow management system and the performers communicate with each other
using this set of common data parameters. This relationship is shown in Figure 4.
The structural and data aspects of a workflow model are significantly dependent
on each other. For example, the condition object needs the data parameters pro-
vided by a data flow to select the alternative path. Similarly, a control flow path
must also exist to satisfy a data flow constraint between two tasks.
We support the modeling of data flows through global workflow variables. Each
task has associated input and output containers. The underlying application com-
ponent of a task can read the variables in its input container and write into the vari-
ables in its output container. The variables in these containers of a task are mapped
to a subset of the global workflow variables, which are used to indirectly map the
variables of one task to another.
2.3. Execution
Using the structure and data aspects of a workflow model, the workflow engine
schedules appropriate tasks at different stages of workflow execution. This sched-
uling activity is accomplished through the task scheduler that is a fundamental part
of a workflow engine.
The task scheduler allocates the tasks to respective performers. For task alloca-
tion, the workflow management system needs certain modeling information for
individual tasks that is captured by the execution aspect of the framework.
As shown in Figure 1, tasks are allocated to performers who in turn are re-
sponsible for carrying out the tasks. We classify tasks into two categories: auto-
mated and human-oriented. An automated task is performed completely and in-
dependently by a computer. To execute such a task, the workflow management
system would need information about the protocol to communicate with the un-
derlying computer application. A human-oriented is performed by humans and
may also have an associated computing resource for accomplishing the task ob-
jectives. For such a task, the workflow management system would also need in-
formation about role and responsibilities of the person who would be executing
the task.
As described earlier, we use the nesting structure to encapsulate a workflow into
a task and then use that nested task in some other workflows. The atomicity char-
acteristic distinguishes between the tasks that could be decomposed into workflows
and the tasks that could not be decomposed. An atomic task is a single task from
the point of view of a workflow management system. A nested task encapsulates
a workflow and the tasks in the encapsulated workflow have to be executed for the
successful completion of the nested task. It is possible to have an atomic task that
is more complex than a nested task. It all depends on the workflow specifica-
tions. However, as long as it does not decompose into a workflow, we call it an
atomic task.
Under the scope classification, we have two types of tasks: external and internal.
Most of the tasks in a workflow specification belong to the first category. An ex-
ternal task is any automated or manual activity that is performed to accomplish
some business objective. An internal task is a workflow management system
activity that is performed to coordinate other external or internal tasks.
In some workflows, certain authorization may be required for task allocation.
The workflow application for such a process must have the ability to ensure that
only the authorized performers execute the task. Such authorization levels are also
captured during the modeling of execution aspects.
Another important feature of workflows is distributed allocation of tasks to
a group of performers. Tasks use services of performers for carrying out their op-
erations. In a workflow application that involves a large number of humans as per-
formers, effective task allocation policies are even more important. For example,
for a particular task there could be a group of performers who could perform the
task. There could be several considerations for allocating the task to a particular
performer. For example, we may want to maintain a balanced workload among
performers. These task allocation policies could be very complex and may involve
many constraints. It is important to capture and analyze the task allocation policies
during the modeling process.
2.4. Temporal
The temporal aspects add another dimension to the scheduling of workflow tasks.
Without temporal constraints, a workflow task is initiated when its preceding tasks
in structural specification have finished execution. However, if any temporal con-
straints are specified, they must also be satisfied, besides other constraints, to suc-
cessfully execute the task.
One may argue to include temporal constraints in execution partition. However,
in our opinion, these constraints are complex enough to be captured in an inde-
pendent phase of workflow modeling. In this section, we identify the types of tem-
poral constraints that could be applied to workflow specifications.
At certain points in workflows, we may require a task to finish by a specific
deadline. There is more than one way to specify such deadlines.
A task specific deadline does not depend on other tasks in the workflow. We
may specify that a task T1 must finish at a given time. At the time of execution, if
that deadline was reached and task T1 had not finished its execution, the workflow
engine would take appropriate actions. The task specific deadline could be speci-
fied as a task property. There could be two possibilities of specifying a task spe-
cific deadline. The first type is specified at the initiation of the workflow that con-
tains the task with deadline. Such a deadline specification model the maximum
time allowed for the workflow to finish all the preceding tasks and the task with
deadline specification. The second type is specified at the time of the task initiation
and models the maximum time allowed for the execution of the task. The task spe-
cific deadlines could be relative or absolute. We can specify an absolute deadline
irrespective of the current time. For such a workflow, each instance would have the
same task deadline as long as it is not changed at the workflow definition level.
Such deadlines are defined as workflow constants. The relative deadlines are speci-
fied in relation to the current time.
An inter-dependent deadline introduces temporal dependencies between tasks.
For example, we may specify that task T2 must finish within a specified time after
initiating or completing task T1. The workflow engine may have to finish several
other tasks between T1 and T2. The temporal dependency is represented with the
help of a temporal flow where the deadline constraint is attached to the flow.
Another type of temporal constraint is the wait constraint. At particular stages of
workflow execution, we may want to wait for a given time before proceeding. Just
like deadlines, this wait specification could either be task specific or inter-dependent.
A task specific wait specifies the time a task should wait for before starting its
execution. Just like deadline, this wait could be specified at the time of workflow
initiation or task initiation. The workflow initiation based wait models the mini-
mum time allowed for the workflow to finish all the preceding tasks before
starting or completing the execution of the task with wait specification. The task
initiation based wait models the minimum time allowed for execution of the task.
If the task finishes its execution before the wait time, it would wait before pro-
ceeding.
The inter-dependent wait introduces temporal dependency between tasks. For
example, we may specify that task T2 must not start or finish before a specified
time after starting or completing task T1. The temporal dependency is represented
with the help of temporal flow where the wait constraint is attached to the flow.
The workflows with obligatory constraints must be able to handle any number
of instances at a given time. For example, the workflow to process the admission
applications for a university has an obligatory constraint to process all the applica-
tions received. These constraints, along with other temporal constraints, add to the
complexity of workflow applications.
Other important temporal properties are the minimum, maximum, and average
execution times for each task. Such specification, along with deadlines, waits, and
obligatory constraints are required to reason the feasibility and effectiveness of
a workflow application.
In structural specification, we introduced the iteration concept that is based on
some conditional value. There is another possibility of iteration, called temporal
iteration, that is modeled to repeat a task for a given time period. Such a concept is
very useful for transactional workflows, where we may want to model a task with
time dependent redo properties in case of failures.
There are several other constraints like workload, availability and efficiency of
staff, holidays, etc. that may affect the timely completion of workflow tasks. The
identification of temporal constraints and associated bottlenecks during the mod-
eling process is very important for workflows involving a large number of per-
formers and expected instances.
2.5. Transactional
The concept of transactional workflows has been an active area of workflow research
[2, 9, 10]. The difference between workflows and transactional workflows is similar
to the difference between legacy applications based on flat sequential files and the ap-
plications developed using relational database management systems like Oracle. The
modern relational database management systems provide extensive transaction ma-
nagement features to ensure the consistent updating of databases and handling of sys-
tem failures. Similarly, transactional workflows extend the basic workflow model by
introducing well-tested transactional features of the transaction management systems.
The concept of transactions is used in transaction processing systems to maintain
the consistency of information systems in case of system and transaction failures and
concurrent updates to the underlying database. A Transaction conforms to the well-
known ACID (Atomicity, Consistency, Isolation, and Durability) properties. Corre-
spondingly, a transactional workflow management system should have facilities to
define these transactional properties. The concept of transactions fits beautifully within
the database-oriented transaction management paradigm. However, the transactional
workflows for large enterprises involving heterogeneous and distributed environments
may not meet the strict requirements of ACID properties [2]. A database manage-
ment system has to deal with computer programs and data only, whereas, a workflow
management system deals with humans and manual activities as well. Furthermore,
not all the workflow processing entities may be based on database management sys-
tems supporting transaction management. Therefore, a flexible transactional model is
generally required for defining and managing transactional workflows.
The motivation behind modeling the transactional features of a workflow is to
add the capability in the workflow to handle exceptional circumstances that would
otherwise leave the workflow in an unacceptable state. The transactional features
of a workflow are handled by a workflow management system. However, the
workflow management system needs some information about transactional proper-
ties of the workflow tasks to control these features.
Two important transactional workflow concepts are abort and recovery. A work-
flow starts its execution from a unique initial task and completes its execution after
executing a final task. During these two tasks, it may run several other tasks de-
pending on the control flow specification.
Abort introduces an exceptional termination of the process during its execution.
There could be several reasons for abort. For example, a system or application error
could result into abnormal workflow termination. It is also possible for the user to
abort the workflow during its execution.
Recovery is the process of taking an aborted workflow from an unacceptable
state to an acceptable state. The way a system handles recovery depends on the
underlying recovery mechanisms in the workflow management system.
In some cases of recovery, the system would need to undo the activities per-
formed by some tasks. For this purpose, during the modeling activity, we identify
compensating tasks that are executed during recovery process to accomplish the
task undo operations.
3. Putting it all Together
We have applied the framework for workflow modeling presented in previous sec-
tion as a foundation for developing a CASE tool for workflow modeling and veri-
fication, FlowMake. The layered approach of the proposed framework has been
effectively applied in FlowMake. Rather than modeling all the workflow con-
straints on a single graph, a workflow is partitioned into several graph layers,
where the same tasks are presented with different partition related properties and
constraints.
It is also important to note that although the workflow constraints could be par-
titioned into logical groups, inter-dependencies do exist between them. For example,
the transactional specifications depend on the structural specifications. An impor-
tant and challenging aspect of the workflow modeling methodology and associated
CASE tool is to ensure the consistency and reliability of the integrated workflow
conceptual model.
Figure 5. FlowMake: Workflow Modeling and Verification Tool
It is possible to easily get into error situations while building complex workflow
specifications. The identification of these errors is obvious and trivial for workflows
that consist of only a few objects. However, the verification of workflow concep-
tual specifications containing a large number of objects is known to be complex [8].
The extensive use of choice and concurrency structures in workflows and the
overlapping data, execution, temporal, and transactional aspects further increase
the complexity of some verification problems. This inherent difficulty of manually
verifying the correctness of workflows makes a strong case for the development of
an automated verification engine. Such an engine would become an essential com-
ponent of a process definition tool for workflows. The early detection of errors in
workflow specifications during the modeling stage is of vital importance and
facilitates the development of reliable and correct workflow applications. The
identification of a set of constraints for avoiding errors in workflow specifications
is the first step towards developing a verification engine. Some of these constraints
have been identified in [13].
The implemented tool based on the framework presented in this paper, called
FlowMake, provides workflow analysts and designers a well-defined framework to
model and reason about various aspects of workflows. It has been designed to
augment production workflow products with enhanced modeling capabilities and
to provide a basis for expanding the scope of the verification. It attempts to identify
inconsistencies in the model that could arise due to conflicting use of modeling
constructs. For example, it is possible that a particular instance of a syntactically
correct workflow model stops executing before reaching and completing an ac-
ceptable final task because of a modeling inconsistency and thus terminating the
workflow instance in an undesirable state. FlowMake provides means to identify
such problems in workflow models.
FlowMake is composed of four major components: the repository, the workflow
editor, the verification engine, and the interface. Repository maintains workflow
models and has been implemented using relational technology. Workflow Editor pro-
vides a user-friendly graphical environment to maintain large workflow graphs. It is
also used to visualize inconsistencies in design. Verification Engine implements the
algorithms to check the consistency of workflow models. Interface component pro-
vides linkage to workflow products through import and export of workflow models.
Presently, the tool allows importing of process models from IBM workflow product
MQ Workflow (previously known as FlowMark), analyzing them for structural con-
flicts, and exporting them back to the product. More information about FlowMake is
available at http://www.dstc.edu.au/DDU/projects/FlowMake/.
4. Conclusion
The contribution of the work presented in this paper is to identify a layered frame-
work for capturing the requirements for a workflow based business information
systems. We divide the workflow modeling effort into five partitions: structure,
data, execution, temporal, and transactional. We introduced a graphical language
for workflow modeling and discussed the issues in capturing and specifying the
workflow constraints. The presented framework is applied as a foundation to de-
velop a methodology and automated tool for the modeling and verification of
workflows.
There are several workflow products available in the market. The framework
presented in this paper is based on generic requirements of workflow applications
and is not influenced by any of the products. However, the framework could be
used to model and analyze workflow requirements before mapping to workflow
products. The framework may also be used to evaluate the functionality supported
in workflow products for each of the partition. We believe that the presented
framework represents a logical, intuitive, and effective breakup of workflow con-
straints.
References
1. Aalst. WMP van der (1998). The Application of Petri Nets to Workflow Management.
The Journal of Circuits, Systems and Computers 1998, 8(1):21–66
2. Alonso G., Agrawal D., El Abbadi A., Kamath M., Guenthoer R., Mohan C. Advanced
Transaction Models in Workflow Contexts. In Proceedings of the 12th International
Conference on Data Engineering, New Orleans, 1996
3. Butler Report. Workflow: Integrating the Enterprise. The Butler Group, 1996
4. Carlsen S. Conceptual Modeling and Composition of Flexible Workflow Models.
PhD Thesis. Department of Computer Science and Information Science, Norwegian
University of Science and Technology, Norway, 1997
5. Casati F., Ceri S., Pernici B., Pozzi G. Conceptual Modeling of Workflows. In: Pa-
pazoglou M.P. (ed) Proceedings of the 14th International Object-Oriented and Entity-
Relationship Modeling Conference, Springer-Verlag, pp 341–354 (Lecture Notes in
Computer Science no. 1021)
6. Ellis C.A., Nutt G.J. Modelling and Enactment of Workflow Systems. In: M. Ajmone
Marasan (ed) Application and Theory of Petri Nets, Springer-Verleg, Berlin, 1993,
pp 1–16 (Lecture Notes in Computer Science no. 691)
7. Georgakopoulos D., Hornick M., Sheth A. An Overview of Workflow Management:
From Process Modeling to Workflow Automation Infrastructure. Journal on Distributed
and Parallel Databases 1995; 3(2):119–153
8. Hofstede A.H.M. ter, Orlowska M.E., Rajapakse J. Verification Problems in Conceptual
Workflow Specifications. Data & Knowledge Engineering, January 1998; 24(3):239–256
9. Kuo D., Lawley M., Liu C., Orlowska M.E. A General Model for Nested Transactional
Workflow. In: Proceedings of the International Workshop on Advanced Transaction
Models and Architecture (ATMA'96), Bombay India, 1996, pp 18–35
10. Kamath M., Ramamritham M. Bridging the gap between Transaction Management and
Workflow Management. Proceedings of the NSF Workshop on Workflow and Process
Automation in Information Systems: State of the Art and Future Directions. Athens,
Georgia, May 1996
11. Rajapakse J. On Conceptual Workflow Specification and Verification. MSc Thesis. De-
partment of Computer Science, The University of Queensland, Australia, 1996
12. Reichert M., Dadam P. ADEPTflex – Supporting Dynamic Changes of Workflow with-
out loosing control. Journal of Intelligent Information Systems (JIIS), Special Issue on
Workflow and Process Management, 1997
13. Sadiq W., Orlowska M.E. On Correctness Issues in Conceptual Modeling of Workflows.
In: Proceedings of the 5th European Conference on Information Systems (ECIS ‘97),
Cork, Ireland, June 19–21, 1997
14. Workflow Management Coalition. The Workflow Management Coalition Specifications
– Terminology and Glossary. Issue 2.0, 1996, Document Number WFMC-TC-1011
15. Workflow Management Coalition. Interface 1: Process Definition Interchange, Process
Model, 1998, Document Number WfMC TC-1016-P
