A PROPERTY SPECIFICATION LANGUAGE
FOR WORKFLOW DIAGNOSTICS
E.E.Roubtsova
Technical University Eindhoven
Den Dolech 2, PO 513, 5600MB, Eindhoven, the Netherlands
Keywords:
Workflow log, workflow mining, property specification language, property check.
Abstract:
The paper presents a declarative language for workflow property specification. The language has been devel-
oped to help analysts in formulating workflow-log properties in such a way that the properties can be checked
automatically. The language is based on the Propositional Linear Temporal Logics and the structure of logs.
The standard structure of logs is used when building algorithms for property checks. Our tool for property
driven workflow mining combines a tool-wizard for property construction, property parsers for syntax checks
and a verifier for property verification. The tool is implemented as an independent component that can extend
any process management system or any process mining tool.
1 INTRODUCTION
Development of different workflow mining method-
ologies is triggered by the increasing attention to se-
curity of business and to performance of companies.
Changes in the business situation demand from com-
panies to be more flexible and react faster on every
deviation of a business process from a correct process
or on every unexpected group of events. That is why
recording, monitoring and diagnosing logs of events
becomes a normal practice of any good organized
business.
A log is a textual file containing information about
events recorded in the order of happening. Workflow
logs are huge files, and their effective diagnostics is
not possible without formal specification of properties
and tool support for property checks. Modern enter-
prize processes are site-defined, i.e. an enterprize de-
fines its own processes. Process management makes
sure that different processes will be made according
to the site-defined rules or properties. To do this the
process managers fulfill diagnostics of workflow logs
with respect to such properties.
The monitoring and diagnosing logs can be orga-
nized in many different ways (Aalst W.M.P. van der,
B.F.van Dongen, J.Herbet, L.Maruster, G.Schimm,
A.J.M.M.Weijters, 2003). Some authors direct
their research on discovering specific workflow met-
rics like entropy, periodicity, causality or concur-
rency (Cook J.E., A.L.Wolf, 1998). Those metrics
provide measures to quantify discrepancies between
a reference model and a logged process (Cook J.E.,
A.L.Wolf, 1999). Other approachers derive a visual
workflow model from a log (Schimm G., 2002),(Aalst
W.M.P. van der, T. Weijters, L. Maruster, 2004). Such
a workflow model can be compared with a stan-
dard reference model. The correspondence between a
workflow constructed from a log and the standard ref-
erence model indicates correctness of a logged busi-
ness process.
However, the reference model is often too complex,
or even not available at all. To reason about correct-
ness of a logged business process an enterprise defines
some properties of a correct process. However, pre-
sentation of such properties is usually informal and
ambiguous. This ambiguity complicates diagnostics
of workflows and makes tool support for such diag-
nostics impossible.
In this paper we present a language for specifica-
tion of workflow properties and a tool for property
checks. The language is based on the Propositional
Linear Temporal Logic (Pnueli, 1981) and the struc-
ture of workflow logs (Dongen B.F. van, W.M.P.van
der Aalst, 2004). Using PLTL-based language as a
driving forse for data mining of workflow logs is a
new approach, although temporal logic has been used
for modelling, scheduling (Davulcu H., M.Kifer, C.R.
Ramakrishman, I.V. Ramakrishman, 1998) and analy-
297
E.Roubtsova E. (2005).
A PROPERTY SPECIFICATION LANGUAGE FOR WORKFLOW DIAGNOSTICS.
In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 297-302
DOI: 10.5220/0002516502970302
Copyright
c
 SciTePress

sis of workflows (Chuang Lin , Yang Qu , 2004).
The reminder of the paper is organized as follows.
Section 2 formalizes a workflow log. Section 3
shows the grammar and semantics of our workflow
property language. Section 4 presents examples of
workflow properties and their expressions in our lan-
guage. Section 5 concerns the implementation issues
of constructing, parsing and checking of property-
expressions. Section 6 concludes the paper.
2 FORMAL REPRESENTATION
OF A LOG
To define a language for workflow properties specifi-
cation we formalize a log. An event is represented in
a log by an audit trail entry (ate). An ate is a tuple
with the following fields:
ate = (W E, ET, T S, O),
W E : String (workflow element),
ET : String (event type),
T S : double (time stamp) and
O : String (originator).
A sequence of ate
′
s in a log is called a process in-
stance (Figure 1). A process instance defines a to-
tal order relation on the set AT E of audit trail en-
tries T = {(ate
1
, ate
2
)| ate
1
, ate
2
∈ AT E ∧
ate
2
follows ate
1
}:
p = (pname, (W E, ET, T S, O), T ).
A set P of process instances defines a workflow
w = (wname, P ). A set W of workflows is grouped
into a log: l = (lname, W ).
According to the definition, a process instance has
a twofold nature: it is both a sequence of ate’s and
a relation. Making diagnostics of a process instance,
we formulate the properties of the process instance
considering the position of a current record in the se-
quence and the values of the fields of this record or of
the records that follow the current one.
3 A LANGUAGE TO SPECIFY
PROPERTIES OF
WORKFLOWS
3.1 Properties of an audit trail entry
Any appearance of a field identifier for a specific ate
derives for this ate the value of the field with the
corresponding name. To compare the values of the
string-fields W E, ET, O with some site-defined val-
ues we use operations equal ” = ” and not equal
”! = ”. To work with the time stamp field T S we
use the complete set of comparison operators. So, an
elementary property of an audit trail entry is repre-
sented by a property of a field in form of one of the
following expressions:
< element >::= tr ue | false |
W E = < string > | W E ! = < string > |
ET = < string > | ET ! = < string > |
O = < string > | O ! = < string > |
T S = < double > | T S ! = < double > |
T S < < double > | T S > < double > |
T S >= < double > | T S <= < double > .
The set of elementary property expressions also
contains some functions, for example, to derive the
time information from the time stamp:
< element >::= HO U RS(T S) =< double > .
For the sake of simplicity, we do not define here the
complete set of functions.
We also assume using variables to memorize field
values and the arithmetic and the comparison opera-
tions on variables. To assign values of fields to vari-
ables at the level of elementary properties we define
the function assign : ” := ”, which always returns
value true:
< element >::=
< V ariable >:= W E | < V ariable >:= ET |
< V ariable >:= T S | < V ariable >:= O).
Such extension of the language allows analysts
to specify some additional properties of business
processes.
Elementary properties are combined into logical
expressions by means of logical operations ( the oper-
ations are represented in order of decreasing priority):
< expr >::=< el ement > |¬ < expr > |
< expr > & < expr > |< expr > || < expr > .
3.2 Properties of a process instance
A property of an audit trail entry is an elementary
property of a process instance. To express the order-
ing properties of a process instance we adapt the set of
the linear temporal operators: NEXT , ALW AY S,
IN
F U T U RE (Bernard B., M.Bidoit, A.Finkel,
F.Laroussinie, A.Petit, L.Petrussi, Ph.Schnoebelen,
2001). We also introduce useful temporal operators
EXIST S
UNT IL and ALW AY S U NT IL with
intuitively clear names. So, a set of possible process
instance properties can be represented inductively:
< tempexpr >:=< expr > | ¬ < tempexpr > |
< tempexpr > & < tempexpr > |
< tempexpr > || < tempexpr > |
NEXT (< tempexpr >) |
IN FUTURE (< tempexpr >) |
ALWAYS (< tempexpr >) |
(< tempexpr >)
ICEIS 2005 - ARTIFICIAL INTELLIGENCE AND DECISION SUPPORT SYSTEMS
298

EXISTS UNTIL (< tempexpr >) |
(< tempexpr >)
ALWAYS
UNTIL (< tempexpr >).
The definition above allows analysts nesting of
properties, which means changing the position of the
ate in the process instance for which the property
must hold.
The semantics of the properties is defined by a sat-
isfaction relation. To define the semantics we con-
struct a Kripke structure (Alur R., C. Courcoubetis,
D.L. Dill, 1993): M
tempexpr
= (AT E, T, ν), where
AT E is a finite set of audit trail entries being states
of a process instance;
T is a binary ordering relation on audit trail entries
which defines the initial audit trail entry and a single
transition from each ate to the next one;
ν : AT E → 2
tempexpr
assigns true values of a tem-
poral property to each ate in the process instance:
1. (ATE,T,position ate
i
) |= expr iff expr ∈ ν(ate
i
).
2. (ATE,T,position ate
i
) |= ¬tempexpr
iff expr 6∈ ν(ate
i
).
3. (ATE,T,position ate
i
) |= tempexpr ∧ tempexpr
1
iff
ate
i
|= tempexpr and ate
i
|= tempexpr
1
.
4. (ATE,T,position ate
i
) |= tempexpr || tempexpr
1
iff
ate
i
|= tempexpr or ate
i
|= tempexpr
1
.
5. (ATE,T, position ate
i
) |= NEXT (tempexpr ) iff
for (AT E, T ) : ate
i
, ate
i+1
, ...
ate
i+1
|= tempexpr.
6. (ATE,T, position ate
i
) |= ALWAYS (tempexpr) if for
(AT E, T ) : ate
i
, ate
i+1
, ... for all j ≥ i
ate
j
|= tempexpr.
7. (ATE,T, position ate
i
) |= IN
FUTURE (tempexpr) iff
for (AT E, T ) : ate
i
, ate
i+1
, ... for some j ≥ i ate
j
|=
tempexpr.
8. ( ATE,T, position ate
i
) |= ((tempexpr )
EXISTS
UNTIL (temexpr
1
)) iff for (AT E, T ) :
ate
i
, ate
i+1
, ... for some j ≥ i ate
j
|= tempexpr
1
and for some k k < j ate
k
|= tempexpr .
9. ( ATE,T, position ate
i
) |= ((tempexpr) AL-
WAYS
UNTIL (temexpr
1
)) iff for (AT E, T ) :
ate
i
, ate
i+1
, ... for some j ≥ i ate
j
|= tempexpr
1
and for all k k < j ate
k
|= tempexpr.
3.3 Properties of a log
The language for specification of a log properties has
to be completed by the specification of the scope of a
property. A property of a log can cover one, several
or all process instances of a process and one, several
or all workflows etc.:
logproperty ::=< LOG >
< W ORKF LOW >
< INST AN CE >< tempexpr >;
< LOG >::=FOR-ALL-LOGS |
EXISTS-LOG |
FOR-LOG < lname >;
< W ORKF LOW >::= FOR-ALL-WORKFLOWS |
EXISTS-WORKFLOW |
FOR-WORKFLOW < wname >;
< INST AN CE >::= FOR-ALL-INSTANCES |
EXISTS-INSTANCE |
FOR-INSTANCE < pname > .
< lname >, < wname >, < pname >::=< string > .
4 EXAMPLES OF PROPERTIES
OF A PROCESS INSTANCE
Sometimes it is not trivial to specify a property. To
ensure correctness of analysis companies should have
specialists responsible for specification of properties
and documentation of their business semantics. Those
properties can be saved under recognizable names in
order to be used by personnel doing everyday moni-
toring of logs. We show here some examples of pos-
sible properties.
4.1 Security properties
Security of editing. When creating own files, we
can set up restrictions for other network users. For
example, only for two persons Rob and Ana we can
allow editing of information.
FOR-LOG ”access”
FOR-WORKFLOW ”access to document X”
FOR-INSTANCE ”the 22d of N ovember”
ALW AY S(¬(W E = ”edit document X”) ||
(W E = ”edit document X” &
(O = ”Rob” || O = ”Ana”))).
Security for electronic voting is another example
of security properties. The uniqueness property de-
clares that no voter should be able to vote more than
one time.
FOR-LOG ”voting”
FOR-WORKFLOW ”voting June 2003”
FOR-INSTANCE ”the 10th of J une”
( ALWAYS (¬(
(W E = ”voting” & v := O & v = v
1
)
EXISTS
UNTIL
(W E = ”voting” & v
1
:= O)))).
4.2 Four eyes principle
The four eyes principle (FourEyes, 2004) dictates that
at least two different persons must witness certain ac-
tivities. This helps to protect an organization from
dishonest individuals and unintended mistakes. Our
property indicates that the first workflow element is
”authentication” and the second workflow element is
A PROPERTY SPECIFICATION LANGUAGE FOR WORKFLOW DIAGNOSTICS
299

”authentication” but the originators of these events are
different:
FOR-LOG ”or ganization”
FOR-WORKFLOW ”logon”
FOR-INSTANCE ”network logon 18.09.2004”
IN
FUTURE ((W E = ”authentication” &
or
1
:= O) &
NEXT (W E = ”authentication” &
or
2
:= O) & (or
1
! = or
2
)).
The property uses operator NEXT nested under the
operator IN
FUTURE. Variables or
1
and or
2
save
the values of the event originators to compare them:
(or
1
! = or
2
).
4.3 Separation of functions
There are business activities which can’t be fulfilled
by the same person. For example, an application for a
business trip (ET = ”start”) can be initiated by any
member of a department. A permission for a business
trip (ET = ”complete”) is usually given by the chief
of the department. However, if the chief applies for a
trip, then the permission for his trip can’t be given by
himself. The property below specifies that the permis-
sion to a travel of the chief of the department should
not be given by himself.
FOR-LOG or ganization
FOR-PROCESS business trip
FOR-INSTANCE 18.10.2004
((W E = ”business trip ” &
ET = ”start” & O = ”H. de Jong”)
EXISTS
UNTIL
(W E = ”business trip” &
ET = ”complete” & O ! = ”H. de Jong”)).
4.4 Deadlines
Field timestamp T S allows us to represent deadlines
as properties. Let us imagine that the activity A of the
process-instance shown in Figure 1 should be com-
pleted till 18.00:
FOR-LOG ”pn − ex − 15.xml”
FOR-WORKFLOW ”main − process”
FOR-INSTANCE ”experiment”
IN
FUTURE (W E = ”A” &
ET = ”complete” & HOURS(T S) ≤ 18.00).
This deadline-property holds for the process instance
in Figure 1.
Relative deadlines. For example, we may demand
that an activity should be completed in ten hours from
the start:
FOR-LOG ”pn − ex − 15.xml”
FOR-WORKFLOW ”main − process”
FOR-INSTANCE ”experiment”
((W E = ”A” & ET = ”start” &
t
1
:= HOURS(T S))
EXISTS
UNTIL
(W E = ”A” & ET = ”complete” &
t
2
:= Hours(T S) ) & t
2
− t
1
≤ 10)).
The property does not hold for the process instance in
Figure 1.
5 IMPLEMENTATION OF THE
METHODOLOGY OF THE
PROPERTY DRIVEN
WORKFLOW MINING
To implement the property driven workflow mining
we have solved the following tasks: property con-
structing, property parsing and property checking.
Property constructing has been implemented as a
wizard-tool which helps analysts to choose the scope
of property-oriented mining and formulate a property.
The wizard shows the set of the temporal operators,
the lists of fields and logical connectors (Figure. 2)
which allow constructing properties.
Property parsing has been implemented using the
Java Compiler Compiler (JavaCC. A parser/scanner
generator for java, 2004) in the grammar presented
in Section 3. There have been developed parsers for
temporal expressions (with nesting), for expressions,
and for simple logical expressions to build property
checkers on their basis.
Property checking of expressions is performed as
interpretation of expressions during parsing. An ex-
pression expr is evaluated for one record at a speci-
fied position in a process instance.
The temporal property checking could not be done
during parsing because of the parser backtracking
problem. So, each kind of temporal operator is evalu-
ated by a corresponding function.
1. Function V erif yN ext(p, i, expr) checks the
value of expression expr for the next ate (i + 1) to
the current one.
2. Function V erif yInF uture(p, i, expr) searches
an ate of the process instance p where expr = true
and then returns value true. If such an ate has not
been found, the function returns false.
3. Function V erifyAlways(p, i, expr) calls the ex-
pression checker for every ate of process instance
p starting from i. Only if the expression is true for
all ate
′
s the function returns value true.
4. Function V erifyExistsU ntil(p, i, expr, expr
1
)
searches an ate j of the process instance p where
expr
1
= true and then from the ate i until the ate
j searches an ate where expr = true. Only if both
searches are successful, then the function returns
value true.
ICEIS 2005 - ARTIFICIAL INTELLIGENCE AND DECISION SUPPORT SYSTEMS
300

5. Function V erif yAlwaysU ntil(p, i, expr, expr
1
)
searches an ate j of the process instance p where
expr
1
= true and then from the ate i until the ate
j checks if for all the ate
′
s expr = true. Only if
both searches are successful, then the function re-
turns value true.
Recursive application of these functions is used to
evaluate temporal logical expressions for a process in-
stance.
6 CONCLUSION
Correctness control of workflows using log-mining
can not be fulfilled in general: it is always fulfilled
with respect to some side-defined criteria. If these
criteria come from the workflow design, for example,
in form of a standard workflow, then we can control
the deviations of the real process from the standard
workflow. But the standard workflow can also be de-
veloped with mistakes. So, it is always reasonable
to specify some correctness criteria that are not based
on the design decisions. With respect to these cri-
teria both the standard designed process and the real
logged process can be analyzed.
In this paper we have proposed formulating those
criteria as workflow properties in a declarative PLTL
based language. We have developed the language for
the standard log-format and implemented a version of
the language for a fixed log structure as a component-
prototype which can extend any process management
system or any process mining tool. Construction of
properties and property checks are supported by the
component. The properties formulated by specialists
are saved under recognizable names in order to be
used by personnel doing the everyday monitoring of
logs.
We are going to integrate our component into the
ProM tool (ProM framework. TU/e, 2004) being un-
der development by the Business Process Modelling
group of the Technology Management Faculty at the
Technical University Eindhoven. Such an integrating
our component into this framework will allow us to
find the methodology of property specification and
checking which is the most suitable for monitoring
of workflow logs. If the format of logs is changed in
the future covering the XML-log format, we can de-
velop automatic adaptation of the property language
to the structure of a log. For example, introducing
new fields into the description of an event (ate) will
change the set of elementary formulas in our work-
flow mining language. This predictable extension of
the language will cause the predictable modification
of the wizard-tool and the property checking tool.
ACKNOWLEDGEMENT
The author thanks all members of the Business
Process Modelling group of the Technology Manage-
ment Faculty at the Technical University Eindhoven
for sharing insights.
REFERENCES
Aalst W.M.P. van der, B.F.van Dongen, J.Herbet,
L.Maruster, G.Schimm, A.J.M.M.Weijters (2003).
Workflow mining: A survey of issues and approaches.
In Data and Knowlege Engineering, volume 47, Issue:
2 , pages 151– 162.
Aalst W.M.P. van der, T. Weijters, L. Maruster (2004).
Workflow mining: Discovering process models from
event logs. In IEEE Transactions on Knowledge and
Data Engineering, volume 16, Issue: 9 , pages 1128–
1142.
Alur R., C. Courcoubetis, D.L. Dill (1993). Model-
checking in dense real-time. Information and Com-
putation, 104(1):2–34.
Bernard B., M.Bidoit, A.Finkel, F.Laroussinie, A.Petit,
L.Petrussi, Ph.Schnoebelen (2001). Systems and Soft-
ware Verification. Model-Checking Techniques and
Tools. Springer-Verlag.
Chuang Lin , Yang Qu (2004). Temporal inference of work-
flow systems based on time petri nets: Quantitative
and qualitative analysis. In International Journal of
Intelligent Systems, volume 19, Issue 5, pages 417 –
442.
Cook J.E., A.L.Wolf (1998). Discovering models of soft-
ware processes from event based data. In ACM Trans-
actions on Software Engeneering and Methodology,
volume 7, Issue: 3 , pages 215– 249.
Cook J.E., A.L.Wolf (1999). Software process valida-
tion: Quantitatively measuring the correspondence of
a process to a model. In ACM Transactions on Soft-
ware Engeneering and Methodology, volume 8, Issue:
2 , pages 147– 176.
Davulcu H., M.Kifer, C.R. Ramakrishman, I.V. Ramakr-
ishman (1998). Logic based modeling and analysis
of workflows. In ACM Symposium on Principles of
Database Systems (PODS), Seattle.
Dongen B.F. van, W.M.P.van der Aalst (2004). Emit: A
process mining tool. In 25th International Conference
on Applications and Theory of Petri Nets.
FourEyes (2004). Retrieved January 15, 2005, from
http://www.tpis.com.au/products/fe/default.htm.
JavaCC. A parser/scanner generator for java
(2004). Retrieved January 15, 2005, from
https://javacc.dev.java.net.
Pnueli, A. (1981). The temporal semantics of concurrent
programs. In Theoretical Computer Science, volume
13, Issue: 1 , pages 46– 60.
A PROPERTY SPECIFICATION LANGUAGE FOR WORKFLOW DIAGNOSTICS
301

ProM framework. TU/e (2004). Retrieved January 15, 2005,
from http://is.tm.tue.nl/research/processmining/.
Schimm G. (2002). Process miner - a tool for mining
process schemes from event based data. In Lecture
Notes in Computer Science, volume 2424 , pages 525–
528.
Figure 1: Example of a process instance.
Figure 2: A screen shot of the wizard-tool for constructing
of properties.
ICEIS 2005 - ARTIFICIAL INTELLIGENCE AND DECISION SUPPORT SYSTEMS
302