Information Technology and Management 5, 293318, 2004

2004 Kluwer Academic Publishers. Manufactured in The Netherlands.

Applying Propositional Logic to Workflow Verification

HENRY H. BI and J. LEON ZHAO

{hbi, lzhao}@bpa.arizona.edu

Department of MIS, University of Arizona, Tucson, AZ 85721, USA

Abstract. The increasing complexity of business processes in the era of e-business has heightened the need
for workflow verification tools. However, workflow verification remains an open and challenging research
area. As an indication, most of commercial workflow management systems do not yet provide workflow designers with formal workflow verification tools. We propose a logic-based verification method that is based
on a well-known formalism, i.e., propositional logic. Our logic-based workflow verification approach has
distinct advantages such as its rigorous yet simplistic logical formalism and its ability to handle generic
activity-based process models. In this paper, we present the theoretical framework for applying propositional logic to workflow verification and demonstrate that logic-based workflow verification is capable of
detecting process anomalies in workflow models.
Keywords: business process management, constrained truth table, logic-based workflow verification,
propositional logic, workflow verification

The current trend in e-business has led to more complex business processes in
recent years and has increased the need for workflow verification tools that help workflow designers develop correct workflow models efficiently. The purpose of workflow
verification is to examine whether there are any conflicts or anomalies in workflow models so as to avoid much higher costs of breakdown, debugging, and fixing during runtime [4,13]. For this reason, workflow verification should be a fundamental part of
workflow design. However, the lack of formal methodologies for workflow verification
remains a major concern [8,15].
While theoretical research in workflow verification has been around for quite a few
years, there are few workflow verification tools available, particularly in commercial
workflow systems. So far, most workflow management systems (WfMSs) provide only
simulation tools for validating workflow models using the trial-and-error method [9].
Simulation tools cannot replace the formal verification approaches because they are inefficient and inaccurate [17]. The lack of verification tools is an important issue in workflow applications because erroneously designed workflow models can result in failed
workflow processes, execution errors, and disgruntled customers and employees.
In this paper, we propose an activity-based workflow modeling formalism that
captures the essence of commercial workflow models and develop a logic-based workflow verification method for activity-based workflow models. Our workflow verification
method is based on process inference, which reduces the logical representation of a
Corresponding author.

294

BI AND ZHAO

workflow model to its simplest form possible. We demonstrate and prove that process
inference can be used to verify workflow models. In this paper, we focus on verifying
the correctness of workflow process structures during design time and do not consider
implementation issues and runtime problems.
Next, we present the foundation for logic-based workflow verification, including
an activity-based workflow modeling paradigm. In section 2, we explain how to detect
process anomalies including deadlock, lack of synchronization, activities without termination or without activation, and infinite cycles. In section 3, we present the logic-based
verification algorithm, prove its correctness, and demonstrate its validity. In section 4,
we review three other workflow verification approaches, namely Petri nets, graph reduction, and matrix-based and compare them with the logic-based approach. Finally,
section 5 concludes the paper by summarizing the main research findings and indicating
future research directions.
1.

Foundation of logic-based workflow verification

We introduce the activity-based workflow modeling formalism and the concept of logicbased workflow verification. While we use the activity-based modeling paradigm, the
logic-based workflow verification approach should also be applicable to other types of
workflow models.
1.1. Activity-based workflow modeling
Figure 1 contains a set of symbols for the activity-based modeling formalism. There
are two types of vertices, activity vertices and routing vertices. There are two special
activity vertices. Start activity vertex represents the start point of the workflow and end
activity vertex stands for the end point. There are three kinds of routing vertices, AND
vertex, OR vertex, and XOR vertex. Finally, directed arcs are used to link vertices.
An activity-based workflow is composed of a set of activities A = {a1 , a2 , . . . , al },
optional vertices, and directed links. We use eight basic workflow constructs as shown
in figure 2, where ai , aj , as , and at are activities, i.e., ai , aj , as , at A.
(a) Sequence: a construct in which an activity leads to another activity.
(b) AND-Split: a construct in which multiple threads are generated. These threads can
be executed in parallel or in any order.
(c) AND-Join: a construct in which multiple parallel threads converge with synchronization.
(d) XOR-Split: a construct in which exactly one of multiple threads is to be executed.

Figure 1. Symbols for activity-based workflow model.

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

295

(e) XOR-Join: a construct in which any one of multiple activities causes the following
activity to be executed.
(f) OR-Split: a construct in which one or more of multiple activities are executed. The
number of activities that are actually triggered depends on runtime conditions.
(g) OR-Join: a construct in which one or more of multiple threads converge.
(h) Cycle: a construct in which one or more activities are executed iteratively until a
certain condition is met.
We believe that these eight basic constructs are sufficient to model most workflow process structures. Six of these constructs, (a)(e) and (h), have been defined as

Figure 2. Basic workflow constructs.

296

BI AND ZHAO

Figure 3. An example adding dummy activity between two routing vertices.

the essential workflow primitives by the Workflow Management Coalition (WfMC) [16]
and are also defined in the form of Petri nets by Aalst [2,3]. Aalst also introduces the
concepts of explicit XOR-Split and implicit XOR-Split. They are distinguished by the
moment of choice. In an explicit XOR-Split, the choice is made when the activity
before the XOR-Split vertex is executed, whereas in an implicit XOR-Split, the choice
is made the moment when one of activities after the XOR-Spit vertex is executed. However, OR-Split and OR-Join vertices have not been defined by WfMC. It is worth noting
that OR-Split and OR-Join in conventional Petri nets are actually XOR-Split and XORJoin under our framework, respectively. There are two potential reasons for which OR
vertices have not been included in the workflow modeling standards. First, the implementation of OR vertices is difficult because of the execution uncertainties in the outcome of OR vertices. Second, an OR vertex can be simulated by a combination of AND
and XOR vertices although it is cumbersome to do so. However, because in many commercial workflow systems, OR-Split and OR-Join have been implemented, we include
these two constructs in the activity-based workflow modeling formalism to make our
models more expressive.
Note that the WfMC philosophy is to keep the set of basic constructs as simple
as possible. However, we believe this is not a limitation because we can use the basic
set of workflow constructs to simulate more complex constructs. Any two consecutive
routing vertices, such as the example in figure 3(a), can be modified by adding a dummy
activity d1 (figure 3(b)).
1.2. Logic-based process inference
The logic-based workflow verification rests on the analogy between workflow models
and logical deductive arguments. If there is no structural anomaly in an activity-based
workflow model, every workflow instance can walk its way from the start vertex of the
model through some activities to the end vertex, and there is no activity left inactivated.
This is similar to a deductive argument: if all premises of a deductive argument are true,
the conclusion of the argument will be true [12].
In mathematical logic, an argument can be written in the form
Premise 1, Premise 2, . . . , Premise N  Conclusion,

(1)

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

297

Table 1
Logical operators and symbols for logic-based
workflow verification.
Logical operator
And
Or
Exclusive or (XOR)
If . . . then
If and only if

Logical symbol

where  is called an assertion sign and is read as therefore. According to the aforementioned analogy, a workflow model can be expressed in the argument form1
Formula 1, Formula 2, . . . , Formula N  s e,

(2)

where logical formulas are obtained by translating constructs in the workflow model into
logical statements, and s e stands for from the Start vertex s of the model to the
End vertex e and is referred to as the conclusion. The left-hand side of is called the
LHS and the right-hand side the RHS.
Formula (2) should be considered as a deductive argument whose conclusion
s e follows necessarily from its premises (logical formulas). In other words, it is
impossible for s e to be false while all logical formulas are true. If all logical formulas are true, the conclusion s e will certainly be reached. If the conclusion s e
cannot be reached, it can be concluded that one or more logical formulas (i.e., one or
more constructs in the model) are wrong.
It is noteworthy to mention two important points. First, we consider workflow
models initially that do not contain cycles and then extend the ideas to cyclic workflows
in a later section. Second, in order to detect all potential workflow anomalies, we require
all formulas to be included in the deduction. This is different from classical prepositional
logic where even if some logical formulas in expression (2) are false, expression (2) can
still be valid.
Table 1 lists the logical operators and symbols from [12] and [14] used for logicbased workflow verification. In addition, each activity is assigned a truth value. In workflow, if an activity is executed, its truth value is 1 (true); if an activity is not executed, its
truth value is 0 (false). Furthermore, for any pair of activities ai and aj , ai aj means
if activity ai is executed, then activity aj will certainly be executed.
The conversion rules for seven workflow constructs are summarized in table 2,
where ai , aj , as , and at are activities. Because a cycle construct in figure 2(h) can be
modeled using two XOR constructs, we do not include the cycle construct in table 2.
The objective of workflow verification is to detect potential structural anomalies.
Given a logical representation of a workflow model (or simply the logical model), we
1 The conclusion s e is for an acyclic workflow model. For a cyclic model, the conclusion (s
)

(e
) is used, where
is a formula with exclusive disjunction of activities as addressed in later sections
of the paper.

298

BI AND ZHAO

Table 2
Rules of converting basic workflow constructs into logical formula.
No.

Workflow construct

Graph representation

Logical formula

1
2
3
4
5
6
7

Sequence
AND-Split
AND-Join
XOR-Split
XOR-Join
OR-Split
OR-Split

Figure 2(a)
Figure 2(b)
Figure 2(c)
Figure 2(d)
Figure 2(e)
Figure 2(f)
Figure 2(g)

ai aj
ai ((aj as ) at )
((ai aj ) as ) at
ai ((aj as ) at )
((ai aj ) as ) at
ai ((aj as ) at )
((ai aj ) as ) at

Table 3
Truth table for a1 (a2 a3 ) in classical logic.
a1

a2

a3

a2 a3

a1 (a2 a3 )

0
0
0
0
1
1
1
1

0
0
1
1
0
0
1
1

0
1
0
1
0
1
0
1

0
1
1
0
0
1
1
0

1
1
1
1
0
1
1
0

can verify its correctness by reducing the logical model towards the conclusion. We refer
to the process of verifying the logical representation of a workflow model as process
inference.
1.3. Constrained truth table
In propositional logic, truth table is used to prove inference laws and other inference
patterns. However, a workflow construct does not require the complete enumeration of
all possible truth values because the nature of workflow says that if a LHS activity is
not activated, its RHS activities will not be activated. In other words, a LHS activity
precedes its RHS activities. That is, it is not meaningful in process inference to say that
the premise is 1, but the consequent is 0. As a result, we proposed a new concept called
constrained truth table to derive new inference rules that are applicable to workflow
verification.
A constrained truth table excludes the truth values of impossible situations in a
workflow model. For example, table 3 is the truth table in classical logic for formula
a1 (a1 a3 ). There are 8 entry rows in table 3. However, in workflow, activity a2 or
a3 will not be executed until activity a1 is executed. Thus, the second, third, and fourth
rows will not be considered. Additionally, because the relationship between a2 and a3 is
exclusive or (XOR), after the execution of a1 , exactly one of a2 and a3 will be executed.
Therefore, the fifth and eighth rows will not be considered either. Finally, we ignore the

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

299

Table 4
Constrained truth table for a1 (a2 a3 ).
a1

a2

a3

a2 a3

a1 (a2 a3 )

1
1

0
1

1
0

1
1

1
1

Table 5
Constrained truth table for (a b) (a b)
with rule 2 applied to the LHS.
a

ab

ab

0
1

1
0

1
1

0
0

Table 6
Invalid constrained truth table for (a b)
(a b) with rule 1 applied to the RHS.
a

ab

ab

first row, which is a trivial case for workflow. The resulting constrained truth table is
given in table 4.
The following constrained truth table rules (CTT rules) are applicable when building a constrained truth table, where are are logical formulas that are not identical:
Rule 1: For , and must both be true or must both be false.
Rule 2: For , and cannot both be true.
Rule 3: For , and must both be true or must both be false.
Rule 4: For , and must both be true or must both be false.
Note that the rules above should be applied consistently, and in case there is a
conflict between applying the rules to the LHS and the RHS, one should only apply the
rules to the LHS, which we refer to as the Consistency Principle when constructing a
constrained truth table. For instance, given a logical formula (a b) (a b), to
construct a constrained truth table. As shown in table 5, rule 2 is applied to the LHS of
the formula, indicating that this formula is invalid.
Note that in this example, rule 2 is applied to the LHS and rule 1 to the RHS of the
same formula. However, this will lead to a conflict and the values of a and b cannot be
determined since rule 1 says both a and b must be 1 and rule 2 says that a and b cannot
both be 1.
Another potential error when applying the rules is to apply rule 1 to the RHS only
as shown in table 6. Although it correctly shows that the formula is invalid since not

300

BI AND ZHAO

Figure 4. An invalid workflow due to lack of synchronization.

Table 7
Logical laws.
Commutative laws
(p q) (q p)
(p q) (q p)
(p q) (q p)a

Transitive laws
p
p
p
p

q, q r  p r
q, (q r) s  (p r) s a
q, (q r) s  (p r) s a
q, (q r) s  (p r) s a

Associative laws
((p q) r) (p (g r))
((p q) r) (p (g r))
((p q) r) (p (g r))a

a Nolt et al. [12] do not give these laws. We proved them next using constrained truth tables.

both the LHS and the RHS are true, this should not be allowed since the LHS cannot
be 0 in a non-trivial case.
In sum, the given formula indicates a structural anomaly, namely lack of synchronization under a cyclic structure as shown in figure 4. Although this situation rarely
arises in a real world workflow, it illustrates that we should not allow the application of
multiple rules that cause inconsistency.
1.4. Proofs of process inference laws via constrained truth table
The purpose of process inference is to reduce a logical model towards its conclusion by
logical substitution. Logical reduction requires the application of several logical laws
such as commutative laws, transitive laws, and associative laws [12]. The most common
among these three types of laws are the transitive laws, which reduce the logical model
by logical substitution. We show that if a workflow model is reduced to the conclusion,
then the workflow model is free from process anomalies.
We create constrained truth tables by applying the CTT rules given above to remove
non-applicable rows from the conventional truth tables used in propositional logic. Since
the logical laws found in the literature do not contain XOR vertices, we add a number of
new laws as proven next using constrained truth tables. The three types of logical laws
are given in table 7.
The five new laws are proven in the constrained truth tables 812.
Note that the distributive laws such as ((p q) r) (p r) (q r) and the
law of exportation i.e., ((p q) r) (p (q r)) are not allowed in process
inference because their usage results in the alteration of the original workflow graph.
Note also that the tautological laws such as (p p) p are not allowed because they
are, in fact, naming anomalies in a workflow graph.

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

301

Table 8
Proof of (p q) (q p).
p

pq

qp

0
1

1
0

1
1

1
1

Table 9
Proof of ((p q) r) (p (g r)).
p

(p q) r

p (q r)

0
0
1

0
1
0

1
0
0

1
1
1

1
1
1

Table 10
Proof of p q, (q r) s  (p r) s.
p

pq

(q r) s

(p r) s

0
1

0
1

1
0

1
1

1
1

1
1

1
1

Table 11
Proof of p q, (q r) s  (p r) s.
p

pq

qr s

pr s

Table 12
Proof of p q, (q r) s  (p r) s.

2.

pq

qr s

pr s

0
1
1

0
1
1

1
0
1

1
1
1

1
1
1

1
1
1

1
1
1

Logic-based detection of workflow anomalies

In this section, we show how to verify several well-known classes of workflow anomalies. Throughout this subsection, we assume a workflow model has a start vertex and
an end vertex, as defined in most workflow modeling paradigms.
2.1. Deadlocks
A deadlock refers to a situation in which a workflow instance gets into a stalemate such
that no activity can be executed [4]. Figure 5 shows two types of deadlocks. Figure 5(a)

302

BI AND ZHAO

Figure 5. Workflow deadlocks.

Figure 6. Lack of synchronization.

is a deterministic deadlock. Semantically, the deadlock occurs because only one of a1

and a2 is executed at the XOR-Split vertex, the AND-Join vertex will wait forever and
thus block the continuation of the process.
The logical presentation of the graph in figure 5(a) includes two logical formulas,
s (a1 a2 ) and (a1 a2 ) e. However, s e cannot be reached by process inference. Figure 5(b) is a non-deterministic deadlock. When both a1 and a2 are executed
at the OR split vertex, there is no problem. But if only one of a1 and a2 is executed,
a1 a2 will block any further execution. Logically, we cannot obtain s e by process
inference because a1 a2 and a1 a2 are not equivalent.
2.2. Lack of synchronization
Lack of synchronization refers to a situation in which the concurrent activities are joined
by an XOR vertex, resulting in unintentional multiple executions of the End activity e
that follows the XOR vertex [13]. Figure 6 shows two kinds of lack of synchronization:
(1) a deterministic one and (2) a non-deterministic one.
The logical formulas for workflow model in figure 6(a) are s (a1 a2 ) and
(a1 a2 ) e, and similarly, the logical model for figure 6(b) is s (a1 a2 ) and
(a1 a2 ) e. It is easy to see that the conclusion s e cannot be reached by process
inference in both cases. In terms of workflow execution, if only one of a1 and a2 is
executed after s, then e is executed once and there is no problem; but if both a1 and a2
are executed, then e can be triggered twice.
2.3. Activities without termination or without activation
Each well-defined activity in a workflow should be on a path from the start to the end
vertex. If a path from an activity cannot lead to the end, this activity is an activity without
termination. If an activity on a path that does not begin with the start, we say it is an
activity without activation.

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

303

Figure 7. An activity without termination or without activation.

Figure 8. Infinite cycles.

For example, in figure 7(a), activity a2 is an activity without termination. This

anomaly can be detected based on process inference as follows. Given the logical formulas s a1 , a1 (a2 a3 ), a3 e, by process inference, we obtain s (a2 e).
The resulting logical formula indicates that a2 is an activity without termination. Similarly, we can use process inference to determine that a2 is an activity without activation
in figure 7(b).
As mentioned previously, process inference is different from conventional logical
inference. We use the activity without termination problem in figure 7 to illustrate this
point more explicitly. It is interesting to note that a conventional propositional logical
validation will not be able to identify the problem. From figure 7, we have the formulas:
s a1 , a1 (a2 a3 ), a3 e, by adding a logical inference rule (a2 a3 ) a3 , it is
easy to show that the conclusion s e can be reached. That is to say, the conventional
inference process of propositional logic cannot detect that there is a structural problem
in the original graph. This is because the logical inference rule (a2 a3 ) a3 , though
valid in classic logic, adds a link to the workflow and amounts to a modification of the
original graph. Consequently, we should not allow any addition of logical formulas that
add a new link to the graph.
2.4. Infinite cycles
An infinite cycle is a structural anomaly that causes some activities in a workflow model
to be repeatedly executed forever. For instance, figure 8(a) illustrates a deterministic
infinite cycle in which after a1 is executed, both e and a2 are executed. The execution
of a2 triggers itself, thus causing an infinite cycle. This anomaly can be detected by
logical inference. Two logical formulas can be obtained from figure 8(a): (s a2 ) a1
and a1 (e a2 ). By the transitive law, we obtain (s a2 ) (e a2 ). This
formula indicates that the execution of a2 triggers itself and e, resulting in an infinite
cycle. Similarly, figure 8(b) shows a non-deterministic infinite cycle. That is, although
long cycles are possible, once only e is triggered, the cycle terminates.

304

BI AND ZHAO

It is worth noting that the logic-based verification can be used to test the reachability of a workflow model as well. Reachability between any two vertices is defined as the
connectivity between them [10]. In our context, we define the reachability of a workflow
model as the connectivity between any vertex and the end vertex. Note that three of
the aforementioned anomalies, deadlock, lack of synchronization, and activity without
activation or termination can cause incomplete reachability in a workflow model.
2.5. The correctness of logic-based verification
We present one lemma and one theorem to illustrate formally the correctness of the
logic-based workflow verification. Lemma 1 is based on the anomalies defined above,
and theorem 1 specifies the sufficient condition for an acyclic workflow to be correct.
Lemma 1. Given an acyclic workflow W = (f1 , f2 , . . . , fn ) that contains at least one
anomaly such as deadlock, lack of synchronization, and activity without termination,
the corresponding logical representation must contain at least one logical formula that
causes the inference by substitution to fail, or at least one original or intermediate formula that contains a pattern of anomaly, such as deadlock.
Discussion. As we have explained in the previous subsections, each type of workflow
anomalies (not including infinite cycles) can be detected based on their logical expressions. First, a deadlock (section 2.1) or lack of synchronization (section 2.2) anomaly
causes inference by substitution to fail because of asymmetry of logical operators. Second, an activity without termination can cause a logical formula to fail to link to other
formulas that lead to the end vertex e. Third, certain original or intermediate formulas can also contain anomalies such as deadlocks (section 2.1). Consequently, lemma 1
is correct. Note that since we are dealing with acyclic workflows here, we need not
consider the infinite cycle anomalies.


Theorem 1. A workflow model W = (f1 , f2 , . . . , fn ) is free from anomalies if all
formulas f1 , f2 , . . . , fn are combined by substitution into s e.
Proof by contradiction. Assume theorem 1 is false, that is, W contains at least one
anomaly. By lemma 1, there is at least one formula in {f1 , f2 , . . . , fn } that causes the
inference to fail or contains a pattern of anomaly. Consequently, it is impossible to
achieve the conclusion s e. This contradicts the given condition that s e has been
reached. Thus, theorem 1 must be true if the condition holds.


3.

Logic-based workflow verification algorithm

In this section, we first present the verification algorithm and then illustrate it using a
real world workflow example.

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

305

3.1. The verification algorithm

The following notations are used in the algorithm:

W : a workflow model;
s: start vertex;
e: end vertex;
ai : an activity;
: a set of logical formulas for a given workflow;
: a set of terminal logical formulas resulting from inference;
(x1 , x2 , x3 , . . . , xd ): a logical expression in the form of ((((x1 x2 ) x3 ) ) xd ),
{, , }, d  1. Note that x1 , x2 , x3 , . . . , xd can be either an activity or a
logical expression;
f : a logical formula in the form lhs(f ) rhs(f ), and can also be written f (lhs(f ),
rhs(f ));
lhs(f ): the left hand side (LHS) of formula f in the form of (p1 , p2 , p3 , . . . , pk ),
k  1;
rhs(f ): the right hand side (RHS) of formula f in the form of (q1 , q2 , q3 , . . . , qm ),
m  1;

: an exclusive disjunction of activities in form of (((a1 a2 ) ) ac ), c  1;
contains: a function indicating that an expression subsumes another expression, for
instance, lhs(f ) = ((a1 a2 ) a3 ) a4 contains rhs(f ) = (a1 a2 ) a3 .
We use an example to illustrate some of these notations. Given a formula
f1 = (((a1 a2 ) a3 ) a4 ) (a5 a6 ),

we can write
lhs(f1 ) = (p1 , p2 , p3 , p4 ) = (((a1 a2 ) a3 ) a4 ),
where p1 = a1 , p2 = a2 , p3 = a3 , p4 = a4 and
rhs(f1 ) = (q1 , q2 ) = (a5 a6 ),
where q1 = a5 , and q2 = a6 .
The way of expressing lhs(f1 ) and rhs(f1 ) as exemplified here enables us to specify
various matching conditions between formulas. For instance, given another formula
f2 = ((p1 ) (qi )) = (a5 (a7 a8 )),
where p1 = a5 and q1 = (a7 a8 ). We can say that the RHS of f1 , rhs(f1 ) contains the
LHS of f2 , lhs(f2 ). Note that rhs(f1 ) = (q1 , q2 ), lhs(f2 ) = (p1 ) where q1 = p1 =

306

BI AND ZHAO

a5 , and the superscript indicates that the expression is from formula f2 . Consequently,
formula f1 and formula f2 can be merged into
f1 = ((p1 , p2 , p3 , p4 ) (q1 , q2 )) = ((p1 , p2 , p3 , p4 ) (q1 , q2 ))
= ((((a1 a2 ) a3 ) a4 ) ((a7 a8 ) a6 )),
where q1 = (a7 a8 ) from the RHS of f2 .
The logic-based workflow verification algorithm consists of the following procedures:
PROCEDURE Verify () {
=
// Initialize the set of resulting formulas
do {
// Start the overall process inference
do {
// Start process inference for the remaining logical formulas
for any f 
 =f
Lhs_match(f ) = MatchLHS(f, )
Rhs_match(f ) = MatchRHS(f, )
f = Merged(f, Lhs_match(f ), Rhs_match(f ))
 =  + f Lhs_match(f ) Rhs_match(f )
} while (f
= f AND 
= )
// Found a resulting formula
// Insert the resulting formula into a set
 =  + f
} while (
= )
Identify()
// Identify potential anomalies
}
PROCEDURE MatchLHS(f, ) {
// Search for formulas in  that matches the LHS of f
Lhs_match(f ) =
for each f  {
if (lhs(f ) contains rhs(f ) OR rhs(f ) contains lhs(f )) {
Lhs_match(f ) = Lhs_match(f ) + f
 =  f
}
} return Lhs_match(f )
}
PROCEDURE MatchRHS(f, ) {
// Search for formulas in  that matches the RHS of f
Rhs_match(f ) =
for each f  {
if (lhs(f ) contains rhs(f ) OR rhs(f ) contains lhs(f )) {
Rhs_match(f ) = Rhs_match(f ) + f
 =  f
}
} return Rhs_match(f )
}

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

307

PROCEDURE Merge(f, Lhs_match(f ), Rhs_match(f )) { // Merge formula f with its

matching formulas
for each f Lhs_match(f ) {
if (lhs(f ) contains rhs(f )) {
lhs(f ) = (p1 , p2 , . . . , lhs(f ), . . . , pk )
// replace part of the LHS of f by the LHS of f based on the transitive
law
} else {
rhs(f ) = (q1 , q2 , . . . , t (f ), . . . , qm )
f =

// replace part of the RHS of f by the RHS of f based on the transitive law

}
}
for f Rhs_match(f ) {
if (rhs(f ) contains lhs(f )) {
rhs(f ) = (q1 , q2 , . . . , rhs(f ), . . . , qm )
} else {
lhs(f ) = (p1 , p2 , . . . , lhs(f ), . . . , pk )
f = f
}
} return f
}
PROCEDURE Identify() {
// Identify potential anomalies in resulting formulas
if(|| = 1) {
for f 
if (f = (s, e) OR f = ((s
), (e
)) {
print W contains no anomaly
}
} else {
for each f  {
for each f , f
= f {
if (lhs(f ) contains (((a1 a2 ) ) ar ) AND rhs(f ) contains
(((a1 a2 ) ) ar )) {
print W contains lack of synchronization at a1 , a2 , . . . , ar
} else if (lhs(f ) = (p1 , p2 , . . . , (((a1 a2 ) ) ar ), . . . , pk ) AND
rhs(f ) = (q1 , q2 , . . . , (((a1 a2 ) ) ar ), . . . , qm )) {
print W contains deadlock at a1 , a2 , . . . , ar
}
}
if (f = ((s ), (e ))) {
// is a valid logical expression
print W contains a deadlock at
}
if (f = ((s ), (e )) { print W contains a deterministic infinite cycle at }
if (f = ((s ), (e ))) { print W contains a non-deterministic infinite cycle
at }

308

BI AND ZHAO

if (f = (s, (e )) OR f = (s, (e )) OR f = (s, (e ))) {

print W contains an activity without termination at

}
if f = ((s ), e) OR f = ((s ), e) OR f = ((s ), e))){
print W contains an activity without activation at

}
}
}
}

The complexity of the algorithm can be estimated as follows. Although the procedure Verify contains two levels of do-loops, they combine together into one loop since
the number of outer loop iteration is equal to the number of resulting formulas, and
the number of inner loop iteration depends on the number of formulas in each resulting
formula of process inference. At one extreme, when there is no anomaly found in the
workflow, there will be only one resulting formula. In this case, the inner loop will iterate at most (n1) times, and the outer loop will iterate only once, where n is the number
of constructs in the workflow model as defined in figure 2.
In sum, the two do-loops collectively contain n 1 steps of iteration since at the
first iteration the initial dimension of  is n 1. Further, Procedures MatchLHS( )
and MatchRHS( ) also contain loops, with a maximum 2(n 1) number of comparisons initially and decreasing thereafter. Consequently, the worst case complexity of the
algorithm is proportional to 2(n 1)2 , or approximately O(n2 ).
3.2. Handling cyclic workflow models
In the verification algorithm, formulas f1 , f2 , . . . , fn are transformed through process
inference to reach the conclusion s e if the given workflow W is acyclic. However,
if W is cyclic, we will not be able to reach s e. Instead, we need a new form of
conclusion as explained next.
As shown in figure 9, if a correct workflow contains a single cycle, process inference can reduce the workflow model to figure 9(a), and if a correct workflow contains
multiple cycles, process inference can reduce the workflow model similar to figure 9(b).

Figure 9. Basic cycles.

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

309

Figure 9(a) is a basic cycle that can be expressed as (s a1 ) (e a1 ), and figure 9(b) contains three basic cycles that can be represented by (s (a1 (a2 a3 )))
(s (a1 (a2 a3 ))), which can be generalized as (s
) (e
), where

= a1 (a2 a3 ), an exclusive disjunction of two or more activities.
Note that we do not deal with nested cycles in this paper. However, any nested
cycles can be dealt with iteratively using the algorithm provided above. That is, we first
deal with the simple cycle (a cycle that does not contain a cycle in it), and then reduce
the verified portion to a vertex. The same algorithm can then be applied to deal with
higher order cycles.
We prove the correctness of verification in the case of cyclic workflows next:
Lemma 2. Given a cyclic workflow W = (f1 , f2 , . . . , fn ) that contains at least one
anomaly such as deadlock, lack of synchronization, activity without termination, and
infinite cycles, the corresponding logical representation must contain at least one logical formula that causes the inference by substitution to fail, or at least one original or
intermediate formula that contains a pattern of anomaly, such as deadlock or infinite
cycle.
Discussion. Similar to lemma 1, each type of workflow anomalies can be detected
based on their logical expressions. In addition to anomalies found in acyclic workflows,
infinite cycles (section 2.4) can also be detected based on the original or intermediate
logical patterns in a cyclic workflow. Consequently, lemma 2 is correct.


Theorem 2. A cyclic workflow model W = (f1 , f2 , . . . , fn ) is free from anomalies
if all formulas f1 , f2 , . . . , fn are combined by substitution into (s
) (e
),
where s is the Start vertex of W and e the End vertex, and
is a formula with exclusive
disjunction of activities.
Proof by contradiction. Assume theorem 2 is false, that is, W contains at least one
anomaly. By lemma 2, there is at least one formula in {f1 , f2 , . . . , fn } that causes the
inference to fail or contains a pattern of anomaly. Consequently, it is impossible to
achieve the conclusion (s
) (e
). This contradicts the given condition. Thus,
theorem 2 must be true.


Note that theorem 2 proves the correctness of logic-based process inference, but
not its completeness. In fact, the current verification algorithm does not handle workflow models that contain certain types of overlapping patterns. An overlapping pattern
is a structure in which two or more routing vertices share two or more immediately
preceding (or parent) routing vertices. For instance, figure 10 illustrates an overlapping pattern in which the routing vertices r4 and r5 share two parent routing vertices,
r2 and r3 .
Applying process inference to the logical formulas obtained from this workflow
model, we get two formulas, s ((a1 a2 )(a3 a4 )) and ((a1 a3 )(a2 a4 )) e,

310

BI AND ZHAO

Figure 10. An overlapping pattern.

which cannot be further transformed using existing logical rules. But, it can be shown
that this workflow is structurally correct. In other words, not all overlapping patterns
will present a problem. However, for example, if all AND routing vertices in figure 10
are replaced with XOR vertices, the process inference algorithm will be able to verify its
correctness. Detailed analyses of overlapping workflow patterns and their verification
are beyond the scope of this paper.
3.3. A workflow example
We use an online hotel reservation workflow (figure 11) to illustrate the verification
algorithm. The hotel reservation company allows a customer to name her or his price
first and then contacts its partner hotels to find whether any hotels accept the requested
reservation. For simplicity, we limit the number of hotels to three.
We will show that this model contains structural anomalies, assuming that the conversion rules given in table 2 are used to create the logical formulas as shown in table 13.
Applying the process inference laws defined in section 1, the logical formulas in
table 13 can be transformed using logical rules. In table 14, for example, the associative
law ((p q) r) (p (q r)) is first applied to formula 2, ((a1 a4 ) a16 ) a2 ,
to obtain (a1 (a4 a16 )) a2 . Then the transitive law p q, (q r) s 
(p r) s is applied to (a1 (a4 a16 )) a2 and formula 1, s a1 , to generate
(s (a4 a16 )) a2 . Finally, the associative law is applied again to (s (a4 a16 )
a2 to produce formula 14, ((s a4 ) a16 ) a2 . Other formulas in table 14 are obtained
in a similar way.
Now, we explain briefly how to verify the example using the verification algorithm.
Initially the formula set  contains 13 formulas as listed in table 13. Starting with formula 1, s a1 , for instance, the procedure MatchRHS finds that the LHS of formula 2,
((a1 a4 ) a16 ), contains the RHS of formula 1, a1 . Then, the procedure Merge
merges the LHS of formula 1, s, into the LHS of formula 2 and obtains formula 14,
((s a4 ) a16 ) a2 , in table 14.
Continuing the algorithm, we derive the resulting formula set  containing 3 formulas, that is, formulas 18, 21, and 22 in table 14. Two anomalies, deadlock and lack of
synchronization, are found among these three remaining formulas when the procedure

Figure 11. A wrongly designed workflow model for the hotel reservation process.

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

311

312

BI AND ZHAO

Table 13
The logical formulas from figure 11.
Formula No.
1
2
3
4
5
6
7

Formula
s a1
((a1 a4 ) a16 ) a2
a2 (a3 a6 )
a3 (a4 a5 )
a6 ((a7 a8 ) a9 )
a7 (a10 a13 )
a8 (a11 a13 )

Formula No.

Formula

8
9
10
11
12
13

a9 (a12 a13 )
(((a10 a11 ) a12 ) a13 ) a14
a14 (a15 a18 )
a15 (a16 a17 )
a18 (a19 a20 )
(((a5 a17 ) a19 ) a20 ) e

Table 14
Transformation of logical formulas in table 13.
Formula No.

Transformation

Sources

14
15
16
17
18
19
20
21
22

((s a4 ) a16 ) a2
((s a4 ) a16 ) (a3 a6 )
((s a4 ) a16 ) ((a4 a5 ) a6 )
((s a4 ) a16 ) ((a4 a5 ) ((a7 a8 ) a9 ))
((s a4 ) a16 ) ((a4 a5 ) (((a10 a13 ) (a11 a13 )) (a12 a13 )))
(((a10 a11 ) a12 ) a13 ) (a15 a18 )
(((a10 a11 ) a12 ) a13 ) ((a16 a17 ) a18 )
(((a10 a11 ) a12 ) a13 ) ((a16 a17 ) (a19 a20 ))
(((a5 a17 ) a19 ) a20 ) e

1, 2
3, 14
4, 15
5, 16
6, 7, 8, 17
9, 10
11, 19
12, 20
13

Identify is applied to them. Because  contains three terminal formulas, i.e., formulas
that cannot be further merged, it must contain at least one anomaly. The AND relationships among a10 , a11 , a12 , and a13 in the second part (formulas 9 through 12) do not
match the OR and XOR relationships among these four activities in the first part (formulas 1 through 8). This indicates that the model contains a deadlock around these four
activities. Also, the XOR relationship between a19 and a20 in the third part (formula 13)
does not match their AND relationship in the second part. This implies that a lack of
synchronization problem occurs around a19 and a20 .
These two anomalies are corrected as follows: (1) add activities a21 through a25 and
change the AND-Join among a10 , a11 , a12 , and a13 into XOR-Joins and OR-Join among
a10 through a13 and a21 through a25 , and (2) add activity a26 and change the XOR-Join
between a19 and a20 into an AND-Join. The new model is shown in figure 12, and its
logical formulas are given in table 15.
Applying the verification algorithm to the new set of formulas, we obtain a single
formula (s (a4 a16 )) (e (a4 a16 )). The resulting formula can be represented graphically as a workflow model consisting of two basic cycles without structural
anomaly (figure 13). According to theorem 2, we can declare that the revised model in
figure 12 contains no structural anomaly.

Figure 12. An activity-based workflow model for the hotel reservation process.

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

313

314

BI AND ZHAO

Table 15
Logical formulas obtained by the conversion of workflow model in figure 12.
Formula No.
1
2
3
4
5
6
7
8
9

Formula
s a1
((a1 a4 ) a16 ) a2
a2 (a3 a6 )
a3 (a4 a5 )
a6 ((a7 a8 ) a9 )
a7 (a10 a13 )
a8 (a11 a21 )
a9 (a12 a22 )
(a10 a13 ) a23

Formula No.

Formula

10
11
12
13
14
15
16
17

(a11 a21 a24

(a12 a22 ) a25
((a23 a24 ) a25 ) a14
a14 (a15 a18 )
a15 (a16 a17 )
a18 (a19 a20 )
(a19 a20 ) a26
((a5 a17 ) a26 ) e

Figure 13. A workflow model consisting of two basic cycles.

4.

Related work on workflow verification

We review three existing workflow verification approaches, Petri nets, graph reduction,
and matrix-based, and compare them with the logic-based verification method.
4.1. Petri nets
Petri nets have been used to represent and verify workflow models [13,5,11]. A Petri net
consists of three main components: transitions that represent activities or tasks, places
that hold tokens representing states, and directed arcs that link transitions and places.
The existing research on Petri-net-based workflow is related to a concept called workflow net (WF-net) [1]. A Petri net is a WF-net if and only if (1) it has a source place
and a sink place and (2) if a transition that connects the sink place and the source place,
the resulting Petri net is strongly connected. The verification of WF-nets focuses on
verifying the soundness of workflows and related issues such as liveness, boundedness,
safeness, deadlock, livelock, and dead activity [13].
The main advantages of the Petri net formalism include a formal theory base, a token-based representation of workflow states, and its rigorous analysis and verification
tools. Tokens play a key role in simulating control flows within a workflow model, representing states of the model at any given time, and providing an instrument to verify
the model. Currently, most existing WfMSs do not use Petri nets as the modeling formalism [2,13]. Since Petri nets translate workflows into transitions, places, and tokens,

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

315

Petri-net-based workflow representation is not as easy to understand as those based on

activities and explicit control constructs.
4.2. Graph reduction
Graph reduction was developed to identify two types of structural anomalies - deadlock
and lack of synchronization [13]. It does so by removing the definitely correct structures
that do not contain any structural anomaly, thus reducing the workflow model. This is
accomplished by iteratively applying five reduction rules to remaining vertices in the
model. The five reduction rules are terminal reduction, sequential reduction, adjacent
reduction, closed reduction, and overlapping reduction. The model cannot be completely
reduced to an empty graph, if it contains any of these two types of anomalies.
Graph reduction improves computational efficiency by reducing the graph iteratively. The worst case complexity of the main graph reduction algorithm is O(n2 ). The
main weakness of the graph reduction technique is that it is not applicable to workflow
models that contain cycles [13]. Furthermore, although graph reduction can verify a special overlapping structure, it may not be able to handle general overlapping structures.
4.3. Matrix-based approach
The matrix-based workflow verification integrates process abstraction and process verification [6,7]. This approach uses the adjacency matrix to represent the workflow model
and applies the concept of inline block to reduce computational complexity. An inline
block is a collection of vertices satisfying the blocked transition property and is free
from structural conflicts to verify workflow models. The blocked transition property requires that any inward transition to the inline block can only occur to the start vertex
and that any outward transition from the inline block can only occur at the end node.
A matrix-based algorithm is applied to identifying subsets of a process model that can
be represented as inline blocks.
So far, the matrix-based approach has been shown to be effective in identifying
deadlock and lack of synchronization problems in cyclic workflow models. Additionally, this approach can verify complex workflow structures (including any overlapping
workflow structures) by analyzing all instance flows within each inline block. However,
like most existing WfMSs, this approach has not addressed how to handle workflow
models that contain OR vertices. In addition, the computational efficiency of matrixbased verification has not been reported in the literature.
4.4. Comparison of workflow verification approaches
The three approaches are compared with the logic-based verification in table 16, where
OR vertices are OR-Split and OR-Join vertices, n/a means that the information is
not found in the referenced papers. A state-based approach can capture the states of
a workflow, whereas an activity-based approach does not model the states of a workflow.

316

BI AND ZHAO

Table 16
Comparisons of four workflow verification approaches.
Petri nets

Graph reduction

Matrix-based

Logic-based

Model

State-based

Activity-based

Activity-based

Activity-based

Anomalies
detected

Deadlock
Liveness
Boundedness
Safeness
Livelock
Dead activity

Deadlock
Lack of
synchronization

Deadlock
Lack of
synchronization

Deadlock
Lack of
synchronization
Activity without
termination
Infinite cycle

Cyclic models

Yes

No

Yes

Yes

OR vertices

n/a

n/a

n/a

Yes

Overlapping
structures

Yes

Yes (partially)

Yes

Some

Complexity

n/a

O(n2 )

n/a

O(n2 )

Tools created

Woflan

FlowMake

n/a

n/a

Compared with other activity-based verification approaches, logic-based verification can detect more types of workflow anomalies with acceptable computational complexity and is the only method that considers workflow models that contain OR vertices.
This is an important feature since commercial workflow systems such as SAP R/3 Workflow, Verve Workflow, and Forte Conductor have implemented the concept of OR-Split
and OR-Join [5]. However, as discussed earlier, the logic-based verification algorithm
presented in this paper cannot handle workflow models that contain certain overlapping
routing vertices; an extended logical verification method that is based on instance analysis will resolve this issue.
5.

Conclusion

Workflow verification has been known to be an important, but hard problem to resolve. As such, few commercial workflow management systems provide workflow verification tools. In this paper, we developed a logic-based method for detecting workflow anomalies by process inference in the presence of cyclic structures. We also
proposed an activity-based modeling paradigm that can capture the basic features of
commercial workflow models. In order to make the activity-based modeling paradigm
more powerful, we extended the WfMC standards with OR-Split and OR-Join constructs.
We applied propositional logic to the workflow verification with two extensions.
First, we discovered that conventional truth table is inconvenient when proving new
logical rules needed for process inference, and therefore, we proposed the concept of
constrained truth table as a deviation from classic propositional logic. Second, we found

APPLYING PROPOSITIONAL LOGIC TO WORKFLOW VERIFICATION

317

that conventional logical inference rules cannot be applied in workflow verification if a

rule causes a modification to the workflow graph. Consequently, process inference is not
the same as the classical logical inference as we exemplified in the paper.
We have proven theoretically that any workflow model that passes the verification
is guaranteed to be free from the types of anomalies that have been defined in the paper.
However, our verification algorithm cannot handle certain overlapping workflow patterns
as aforementioned. We are currently working on an extended algorithm that has shown
promising results towards eliminating this limitation.
We believe that we have made a strong case for applying propositional logic to
workflow verification, and we hope that the presented results can stimulate more research
in workflow verification. In our future research, we plan to:
Extend the logic-based workflow verification to handle overlapping structures. Our
initial investigation has shown that instance-based process inference can handle any
complex workflow structures.
Design and implement a logic engine that can verify workflow models automatically,
which will help transfer our research results to industrial strength applications.
Acknowledgements
We appreciate the comments by two anonymous reviewers and the guest editor, which
helped improve the quality of this paper significantly.
References
[1] W.M.P. van der Aalst, Verification of workflow nets, in: The 18th International Conference on Application and Theory of Petri Nets, Lecture Notes in Computer Science, Vol. 1248 (1997) pp. 407426.
[2] W.M.P. van der Aalst, The application of Petri nets to workflow management, Journal of Circuits,
Systems and Computers 8(1) (1998) 2166.
[3] W.M.P. van der Aalst, Three good reasons for using a Petri-net-based workflow management system, Information and Process Integration in Enterprises: Rethinking Documents (Kluwer Academic,
Dordrecht, 1999) pp. 161182.
[4] W.M.P. van der Aalst and Arthur H.M. ter Hofstede, Verification of workflow task structures: A Petrinet-based approach, Information Systems 25(1) (2000) 4369.
[5] N.R. Adam, V. Atluri and W.K. Huang, Modeling and analysis of workflows using Petri nets, Journal
of Intelligent Information Systems 10(2) (1998) 131158.
[6] Y. Choi and J.L. Zhao, Matrix-based abstraction and verification for e-business processes, in: Proceedings of the 1st Workshop on e-Business (2002).
[7] Y. Choi and J.L. Zhao, Handling cycles in workflow verification by feedback identification and partition, in: Proceedings of the 2003 International Conference on Information and Knowledge Engineering, Las Vegas, NV (June 2326, 2003).
[8] D. Georgakopoulos, M. Hornick and A. Sheth, An overview of workflow management: From process
modeling to workflow automation infrastructure, Distributed and Parallel Databases 3(2) (1995) 119
153.
[9] A.M. Law and D. Kelton, Simulation Modeling and Analysis, 3rd edn. (McGraw-Hill Higher Education, 2000).

318

BI AND ZHAO

[10] T. Maruta, S. Onoda, Y. Ikkai, T. Kobayashi and N. Komoda, A deadlock detection algorithm for
business processes workflow models, in: IEEE International Conference on Systems, Man, and Cybernetics, Vol. 1 (1114 October 1998) pp. 611616.
[11] T. Murata, Petri nets: Properties, analysis and applications, Proceedings of the IEEE 77(4) (1989)
541580.
[12] J. Nolt, D. Rohatyn and A. Varzi, Schaums Outline of Logic, 2nd edn. (McGraw-Hill, 1998).
[13] W. Sadiq and M.E. Orlowska, Analyzing process models using graph reduction techniques, Information Systems 25(2) (2000) 117134.
[14] M. Sipser, Introduction to the Theory of Computation (PWS, 1997).
[15] E.A. Stohr and J.L. Zhao, Workflow automation: Overview and research issues, Information Systems
Frontiers: Special Issue on Workflow Automation 3(3) (2001) 281296.
[16] WfMC, Workflow management coalition terminology & glossary (WFMC-TC-1011, Issue 3.0),
Workflow Management Coalition (1999).
[17] D. Wodtke, J. Weienfels, G. Weikum, A. Kotz Dittrich and P. Muth, The MENTOR workbench for
enterprise-wide workflow management, in: SIGMOD Conference (1997) pp. 576579.