ArticlePDF Available

Abstract and Figures

The workflow technology manages the execution of business activities and coordinates the flow of information throughout the enterprise. 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 dimensions: structure, data, execution, temporal, and transactional. The concepts introduced in this paper have been applied as a foundation to the development of a workflows modeling and verification tool, FlowMake.
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
email: {wasim, maria}
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.
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.
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
Choice Merge
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
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.
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-
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
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
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
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-
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
... For instance the documents flow in organizations is determined by the policy of workflow of organizations and existing dynamic policies. These policies may change sometimes for various reasons [1]. This kind of changes in organizational policies and the process of workflow in organizations have always been a headache for managers of organizations. ...
... This kind of changes in organizational policies and the process of workflow in organizations have always been a headache for managers of organizations. Because teaching a new policy to employees and then demanding obedience of them is a hard and time-taking job, and probably there will be some resistances for it [1]. Therefore one of the needs of the organizations managers is the ability of simply changing the policies and performing them instantly in organization, in which all of the employees have to operate these new policies. ...
... By mechanizing the systems and using organizations of computer systems of workflow management, the employees have to obey of the organizational policy in doing their commitments and interchanging with other relevant parts [1],But still there is a main problem, these kind of systems either are not that much flexible that we could change the process of workflow easily or totally is impossible to make changes in them, But there is a need to have a special skill here, for example the ability of writing codes in an special language or interpreting policies with special sentences(for suitable interpretation by the algorithm of interpreting human language) [2,1]. On the other word the major problem here is that the systems are not flexible and dynamic or we can say the dissimilarity between human language and machine language and also the lack of a compatible interpreter is an important problem now [2]. ...
Full-text available
The change capability of information flow in organizations is a major request that is required from IT masters by managers. In this paper we develop a novel method for achieving this goal. This method uses UML activity and sequence diagrams in front-end section, and tree structure of XML language in back-end section. Extended UML diagrams provide an easy designing mode for managers that they can easily design flows and do their favorite changes. In the back-end or business process, graphical diagrams convert to XML trees and thus the process of them can do flexible because the nature of XML language makes a hierarchical tree using nested tags. Using this method can solve the old problem of managers that want a fast, flexible system for supporting policy changes in organizations.
... lógicos conjuntos e disjuntos [Sadiq et al. 1999]. ...
... Em [Sadiq et al. 1996] é proposto um modelo para a representação de sistemas de workflow que se baseia na Teoria de Grafos. As suas componentes gráficas são as apresentadas na Através dos objectos apresentados nos pontos anteriores, [Sadiq et al. 1999] define construções (constructs) que permitem modelar a forma como as actividades vão sendo executadas ao longo de um processo. ...
... Following we identify possible additional aspects and discuss extensibility characteristics of workflow meta-models which come to mind given the fact that additional aspects can occur. However, alternative categorisations exist and alternative approaches give more importance to different aspects, c.f. [12,25,31,33]. Figure 2 shows the relations between aspects in workflows. ...
... In this work we concentrate on the five so called key aspects which are common for most allroundworkflow management systems and are not specific for single problem-domains. For alternate views on aspect emphasis in workflow technology see Bernauer et al. [12], Reijers [31], Sadiq and Orlowska [33]. ...
Full-text available
Digital Enterprise Research Institute, National University of Ireland, Galway.
... BPMN aims to serve as a standard notation that is understandable by all business stakeholders and allows to bridge the gap between business process design and implementation. The proposed modeling approaches also includes [Sadiq 1999] in which authors propose to divide the workflow modeling into structure, data, execution, temporal, and transactional partitions for workflow modeling. The authors have also proposed the FlowMake modeling tool which allows to partition a workflow into several graph layers, instead of modeling all the workflow constraints on a single graph. ...
Web services composition design, verification and monitoring are highly active and widely studied research directions. Little work however has been done in integrating these related dimensions using a unified formalism. In this thesis, we have proposed a declarative event-oriented framework, called DISC, that serves as a unified framework to bridge the gap between the process design, verification and monitoring. Proposed framework allows for a composition design that can accommodate various aspects such as data relationships and constraints, Web services dynamic binding, compliance regulations, security or temporal requirements and others. Then, the proposed framework allows for instantiating, verifying and executing the composition design and for monitoring the process while in execution. The effect of run-time violations on the process execution can also be calculated and a set of recovery actions can be taken, and thus allowing for self-healing Web services composition.
... Processes are meant to ensure that activities in an organization are performed consistently and reliably [10]. The four primary components are objectives, tasks, performers, and constraints [11]. However, it is not easy to plan the work in detail beforehand, as development in the turbulent world today is characterized by constant changes in goals, work, resources, environment, etc. Trivial cases and simple problems can be solved with the top-down approach, while non-trivial problems are characterized by deviations from the predefined top-down approach [12], [13]. ...
Conference Paper
Full-text available
Developing software systems is a challenging business with short development cycles, changing needs, and unstable processes. Processes must deliver products that meet the customer needs and provide value for the stakeholders. There is no one way of achieving the development goals; instead, alternative routes should be possible within the boundaries of acceptable performance. Software development is therefore a set of problem-solving and decision-making activities. The problem is how to support the decision-oriented process, and how to provide justification, rationale, and how to provide the information that decision makers need. Case studies in the automation and telecom industries revealed that understanding the development process as a decision-oriented process, and controlling and coordinating the work through decision points offer an approach that addresses several challenges. The findings of this study offer new insights for scholars and practitioners.
... Expressibility The expressive power of a process modelling language is governed by its ability to express specific process requirements reflecting the purpose of process modelling and execution. A process model is required to contain structure, data, execution, temporal, and transactional information of the business process [22] [43]. Reflectivity Reflectivity is the ability of the business process model to represent change in the system on the process instance level, i.e. the model should be able to reflect every fine-granular state the system can be in, e.g. ...
Full-text available
Today’s fast and competitive markets require businesses to react faster to changes in its environment, and sometimes even before the changes actually happen. Changes can occur on almost every level, e.g. change in demand of customers, change of law, or change of the corporate strategy. Not adapting to these changes can result in financial and legal consequences for any business organisation. IT-controlled business processes are essential parts of modern organisations which motivates why business processes are required to efficiently adapt to these changes in a quick and flexible way. This requirement suggests a more dynamic handling of business processes and their models, moving from design-time business process models to run-time business process models. One general approach to address this problem is provided by the community of models@run.time, in which models reflect the system’s current state at any point in time and allow immediate reasoning and adaptation mechanisms. This paper examines the potential role of business process models at run-time by: (1) discussing the state-of the art of both, business process modelling and models@run.time, (2) reflecting on the nature of business processes at run-time, and (3) most importantly, highlighting key research challenges that need addressing to make this step.
... The tool uses XSLT (Extensible Style Language Transformations) to translate XRL specifications to a specific class of Petri nets called workflow nets. Sadiq [17] have studied the different issues in capturing workflow requirements and proposed a systematic layered modeling approach. Additionally, Morschheuser [18] present tools and methods to address problems in integrated document and workflow management with a case study involving offer processing of a machine tool company. ...
Full-text available
There is an increasing order in digitized technology. This increasing order requires high qualitative document management system which can be used in secure fashion especially for organization with different branches and different location. In this paper we propose a qualitative document management framework which could be used for most organization with little adaptation based on organization nature. The proposed framework provides the necessary options for creating an effective document management system such as access, modify, search, retrieve and index of files. The proposed framework consists of several phases which are connected together in a sequential fashion and cannot be separate. Also it ensures reliability and quality if it is used in a proper way. If any organization used the proposed framework in creating its own document management system, the end product will be suitable for organization and guaranteed to satisfy users requirement since they are included in the development process .On the other hand, if the organization has its own document management system it will not be a difficult task to adapt the system in order to make it more sufficient and suitable for the organization needs. The stages involved in creating the proposed framework are very consistence; each stage has its own characteristics and merits. The requirements of each stage must be achieved precisely to reach success in your work.
Business process modeling is that make use of graphics, formulas, tables and text to describe the characteristics of business process, and answer why to do, what to do, how to do. Business process modeling is the foundation of business process management. Implementation of business process management can improve the process and enhance competitiveness. In this chapter, the authors attempt to find current business process modeling methods’ advantages and disadvantages by analyzing their feature and comparison of based on series important evaluation criteria. The goal is that it provides a reference to business process modeling methods in practice.
Accessing the required information in the supply chain of structural steel components is critical for minimizing costly reworks and delays. This paper identifies the information items generated in the different phases of the supply chain related to structural steel components and formalizes the process of producing and using this information. Precise details about different features of the components (e.g., their geometry and weight, connection details, cutting/bending/punching requirements, and the type and grade of the material) are set in the various tasks performed in the different phases of the supply chain. Regardless of whether one uses paper-based systems or advanced technologies such as smart tags and radio-frequency identification (RFID), a better understanding is achieved of the processes through which a structural steel component passes. The results of this research can be used to streamline the information flow in the supply chain of structural steel components, regardless of the type of tracking technology used, hence reducing delays and reworks.
Conference Paper
From the analysis of workflow instance relevant data (WIRD), and a modeling method of WIRD based on object Petri nets is proposed. The method dynamically constructs an access mechanism of WIRD, to guarantee the security of WIRD. Moreover, a version management mechanism of WIRD is adopted as well as a collaborative communication mechanism of concurrent tasks is established to solve the inconsistency of WIRD during execution of workflow. The research of applied example has shown that this modeling method is significant in the application of access right and integrality of WIRD
Full-text available
Today's business enterprises must deal with global competition, reduce the cost of doing business, and rapidly develop new services and products. To address these requirements enterprises must constantly reconsider and optimize the way they do business and change their information systems and applications to support evolving business processes. Workflow technology facilitates these by providing methodologies and software to support (i) business process modeling to capture business processes as workflow specifications, (ii) business process reengineering to optimize specified processes, and (iii) workflow automation to generate workflow implementations from workflow specifications. This paper provides a high-level overview of the current workflow management methodologies and software products. In addition, we discuss the infrastructure technologies that can address the limitations of current commercial workflow technology and extend the scope and mission of workflow management systems to support increased workflow automation in complex real-world environments involving heterogeneous, autonomous, and distributed information systems. In particular, we discuss how distributed object management and customized transaction management can support further advances in the commercial state of the art in this area.
Full-text available
Workflow management promises a new solution to an age-old problem: controlling, monitoring, optimizing and supporting business processes. What is new about workflow management is the explicit representation of the business process logic which allows for computerized support. This paper discusses the use of Petri nets in the context of workflow management. Petri nets are an established tool for modeling and analyzing processes. On the one hand, Petri nets can be used as a design language for the specification of complex workflows. On the other hand, Petri net theory provides for powerful analysis techniques which can be used to verify the correctness of workflow procedures. This paper introduces workflow management as an application domain for Petri nets, presents state-of-the-art results with respect to the verification of workflows, and highlights some Petri-net-based workflow tools.
Todays workflow management systems are only applicable in a secure and safe manner if the business process (BP) to be supported is well-structured and there is no need for ad hoc deviations at run-time. As only few BPs are static in this sense, this significantly limits the applicability of current workflow (WF) technology. On the other hand, to support dynamic deviations from premodeled task sequences must not mean that the responsibility for the avoidance of consistency problems and run-time errors is now completely shifted to the (naive) end user. In this paper we present a formal foundation for the support of dynamic structural changes of running WF instances. Based upon a formal WF model (ADEPT), we define a complete and minimal set of change operations (ADEPTflex) that support users in modifying the structure of a running WF, while maintaining its (structural) correctness and consistency. The correctness properties defined by ADEPT are used to determine whether a specific change can be applied to a given WF instance or not. If these properties are violated, the change is either rejected or the correctness must be restored by handling the exceptions resulting from the change. We discuss basic issues with respect to the management of changes and the undoing of temporary changes at the instance level. Recently we have started the design and implementation of ADEPTworkflow, the ADEPT workflow engine, which will make use of the change facilities presented in this paper.
Most of today's business requirements can only be accomplished through integration of various autonomous systems which were initially designed to serve the needs of particular applications. In the literature workflows are proposed to design these kinds of applications. The key tool for designing such applications is a powerful conceptual specification language. Such a language should be capable of capturing interactions and cooperation between component tasks of workflows among others. These include sequential execution, iteration, choice, parallelism and synchronisation. The central focus of this paper is the verification of such process control aspects in conceptual workflow specifications. As it is generally agreed upon that the later in the software development process an error is detected, the more it will cost to correct it, it is of vital importance to detect errors as early as possible in the systems development process. In this paper some typical verification problems in workflow specifications are identified and their complexity is addressed. It will be proven that some fundamental problems are not tractable and we will show what restriction is needed to allow termination problems to be recognized in polynomial time.
Most of today's business requirements can only be accomplished through integration of various autonomous systems which were initially designed to serve the needs of particular applications. In the literature workflows are proposed to design these kinds of applications. The key tool for designing such applications is a powerful conceptual specification language. Such a language should be capable of capturing interactions and cooperation between component tasks of workflows among others. These include sequential execution, iteration, choice, parallelism and synchronisation. The central focus of this paper is the verification of such process control aspects in conceptual workflow specifications. As is generally agreed upon, that the later in the software development process an error is detected, the more it will cost to correct it; it is thus of vital importance to detect errors as early as possible in the systems-development process. In this paper some typical verification problems in workflow specifications are identified and their complexity is addressed. It will be proven that some fundamental problems are not tractable and we will show what restriction is needed to allow termination problems to be recognized in polynomial time.