Conformance Checking using Formal Methods
Antonella Santone
1
and Gigliola Vaglini
2
1
Department of Engineering, University of Sannio, Benevento, 82100, Italy
2
Department of Information Engineering, University of Pisa, Pisa, 56122, Italy
Keywords:
Model Discovery, Process Mining, Model Checking, Conformance Checking.
Abstract:
Conformance checking is an important process mining task; it aims to detect inconsistencies between the
model of a process and its corresponding execution log. This paper proposes an approach in which it is given
a declarative description, represented by a set of temporal logic properties, for the process model; the process
discovered from the log is described by means of a process algebra, and conformance checking is performed
through the model checking of the discovered process against the properties. To discover the process we
consider additional information contained in the log and associated with the single events. Moreover, since
discovered processes tend, in general, to be very large and complex, we look for a reduced process containing
only the parts relevant for the properties satisfaction. In this way we reduce both the space needed for the
discovered process and the time complexity for the properties verification.
1 INTRODUCTION
The process mining techniques allow knowledge ex-
traction from events stored by information systems. A
classical application of process mining is process dis-
covery. Process discovery techniques take an event
log and produce a process description. In the case
of distributed systems, the discovered process may be
typically described in one of the several possible spec-
ification languages, i.e., Petri nets (Reisig and Rozen-
berg, 1998), Business Process Model and Notation
(BPMN)
1
, or process algebra specifications (Milner,
1989). The general idea is to discover, besides mon-
itoring and improving, real processes by extracting
knowledge from event logs readily available in infor-
mation systems. In fact, all process mining techniques
assume that it is possible to record events. Event logs
may store also additional information about events,
i.e., the particular device executing the activity or the
characterization of synchronization events among de-
vices.
Despite its benefits, process mining has some dis-
advantages. One of them is that discovered models
tend to be large and complex, especially on flexible
scenarios where process execution involves multiple
alternatives. In fact, trying to model every possible
process behavior can result in an information overload
that reduces model comprehensibility. Consequently,
1
http://www.omg.org/spec/BPMN/2.0
conformance checking is an important part of the pro-
cess mining methodology; by this checking it is pos-
sible to evaluate the level of discrepancy between the
discovered process and the process model.
In this work, we consider that distinct sets of
traces, each one regarding the behavior of one device
in the system, are retrieved from the log exploiting the
additional information on the source of each activity,
and that sub-traces representing simple loops can be
individuated (using known methods, such as, for ex-
ample, the α
+
-algorithm (de Medeiros et al., 2004));
moreover, the description of the possible synchroniza-
tion points, again taken from the additional informa-
tion included in the log, are used to express the com-
munication among devices. Finally, to address the
problem of coping with the high complexity of mod-
els obtained by means of automatic process mining,
we accomplish a pre-processing on the traces guided
by the properties required for the system. Abstraction
is seen as an effective approach to represent readable
models, showing aggregated activities and hiding ir-
relevant details. In our case, abstraction is character-
ized by the set of temporal logic formulae specifying
the system properties. These formulae are, in some
sense, the declarative side of the system. From the re-
sulting traces, we discover a system described by CCS
(Milner, 1989), a process algebra specification lan-
guage. Conformance is established through the model
checking of the properties on the discovered process:
258
Santone, A. and Vaglini, G.
Conformance Checking using Formal Methods.
DOI: 10.5220/0005993402580263
In Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) - Volume 1: ICSOFT-EA, pages 258-263
ISBN: 978-989-758-194-6
Copyright
c
 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

in this way we can use existing model checking envi-
ronments without introducing additional concepts to
establish the conformance of the discovered process.
The remainder of this paper is organised as fol-
lows. Section 2 presents a short description of the the-
oretical background of the work; Section 3 describes
the specification and reduction methodology, while
Section 4 shows the technique for model discovery.
Section 5 discusses some related work and Section 6
presents the conclusions and the future works.
2 BACKGROUND
Some basic concepts of process algebra specifications
and model checking of temporal logic formulae are
recalled.
2.1 CCS
We assume that the reader is familiar with the basic
concepts of process algebras and CCS. We summa-
rize the most relevant definitions below, and refer to
(Milner, 1989) for more details. The CCS syntax we
consider is the following:
p ::= α.p | nil | p + p | p|p | x | p[ f ]
Each constant x has a definition of the type x := p
x
,
where p
x
is called the body of x. α ranges over a
set of names of actions A ∪ τ, where A = {a,b, ,...}
and τ is the invisible action; nil denotes the empty
process. The operators to build processes are prefix-
ing (α.p), summation (p + p), parallel composition
(p|q), relabeling (p[ f ]). In this paper we use slightly
differently the communication operator: in fact, we
suppose that the actions causing the synchronization
between p and q are equal. Moreover, we use the ac-
tion named δ only to synchronize processes on ter-
mination. All the processes we define have the well-
formedness property, that is, they synchronize on δ
if and only if they terminate. A typical use of δ can
be found in the definition (see (Milner, 1989)) of the
operators k and “;” that correspond to the sequential-
ization and parallel execution of two well-formed pro-
cesses. The process resulting from their applications
are well-formed too.
pkq = p[δ
1
/δ]|q[δ
2
/δ]|(δ
1
.δ
2
.DONE + δ
2
.δ
1
.DONE)
p;q = (p[δ
1
/δ]|δ
1
.q)
DONE := δ.nil
DONE is a constant whose body contains only the
termination.
2.2 Model Checking Selective
Mu-calculus Formulae
In the model checking framework (Clarke and Lerda,
2007), systems requirements are expressed as formu-
lae in a temporal logic. Model checkers accept two
inputs, a system model and a temporal formula, and
return “true” if the system satisfies the formula and
“false” otherwise. We consider formulae expressed
in the selective mu-calculus temporal logic (Barbuti
et al., 1999), which is different from mu-calculus
(Stirling, 1989) in the definition of the modal oper-
ators. The syntax of the selective mu-calculus is the
following:
φ ::= tt | ff | Z | φ
1
∨ φ
2
| φ
1
∧ φ
2
| [K]
R
φ | hKi
R
φ | νZ.φ | µZ.φ
where K,R are sets of actions in A, while Z ranges
over a set of variable names; µZ.φ is the least fix-
point of the recursive equation Z = φ, while νZ.φ
is the greatest one. The selective modal operators
hKi
R
φ and [K]
R
φ substitute the standard modal op-
erators hKi φ and [K] φ: [K]
R
φ is satisfied by a pro-
cess which, after the performance of a sequence of
actions not belonging to R ∪ K, followed by an action
in K, can transform into a process obeying φ. hKi
R
φ
is satisfied by a process which is able to transform
into a process obeying φ after the performance of a
sequence of actions not belonging to R ∪ K, followed
by an action in K.
The precise and formal definition of satisfaction of
selective mu-calculus formulae can be found in (Bar-
buti et al., 1999).
The basic characteristic of the selective mu-
calculus is that the actions relevant for checking a
formula φ are those ones explicitly mentioned in the
modal operators used in the formula itself. Thus we
define the set O(φ) of occurring actions of a formula
φ as the union of all sets K and R appearing in the
modal operators ([K]
R
ψ, hKi
R
ψ) occurring in φ. A ρ-
bisimulation can be defined, formally characterizing
the notion of “the same behavior with respect to a set
ρ of actions”: two transition systems are ρ-equivalent
if a ρ-bisimulation relating their initial states exists.
In (Barbuti et al., 1999) it has been proved that: “two
processes are ρ-equivalent if and only if they satisfy
the same set of formulae with occurring actions in
ρ”. The interesting consequence of the theorem is
that a formula of the selective mu-calculus with oc-
curring actions in ρ can be checked on any process
ρ-equivalent to the standard one.
Conformance Checking using Formal Methods
259

3 THE SPECIFICATION AND
REDUCTION METHODOLOGY
In this section, we assume that the log is rearranged
so that separate traces for each device in a dis-
tributed system can be obtained exploiting the source
of each activity. Further, we give each activity a dif-
ferent name; moreover simple loops are solved as
(de Medeiros et al., 2004); at the end, we consider that
it is now possible to describe the traces derived from
the log by means of the simple language defined in the
next subsection. Successively, names corresponding
to activities performing equal communication among
devices are given a new equal name. Property-driven
reductions can be performed on the resulting traces
to obtain an abstract CCS system. This system spec-
ification will be model checked against the required
properties to state its conformance.
3.1 Trace-based System Specification
As stated in (de Medeiros et al., 2004), “We assume
perfect information: (i) the log must be complete (i.e.,
if a task can follow another task directly, the log con-
tains an example of this behavior) and (ii) the log is
noise free (i.e., everything that is registered in the log
is correct). This is not a real limitation because we
are primarily interested in formal properties of our
algorithms”. The language we assume to define the
traces obtained through the log pre-processing is the
following.
Definition 1 (Trace). Let A = {e
1
,e
2
,...} be a set of
activity names, a trace of such names can be built up
by the following syntax: t ::= e | t.t | < t >
∗
| λ
where e ∈ A and λ is the empty sequence.
The operator “.” represents trace concatenation:
usually it is omitted. The operator “
∗
” represents the
iteration of a trace and it turns out that << t >
∗
>
∗
is
the same as < t >
∗
and < λ >
∗
is the same as λ. The
following definitions are of interest.
Definition 2 (Alphabet, Branching names). Let T be
a set of traces:
• αT is the alphabet of T , and
• Be(T ) is the set of pairs (e,e
0
) defined as follows:
Be(T ) = {(e,e
0
) | t
1
= s.e.t ∈ T, t
2
= s.e
0
.t
0
∈ T,
e 6= e
0
and s,t,t
0
∈ A
∗
}
The names in each pair in Be(T ) represent the
point in which two traces begin to differ.
After having obtained from the log the set T of
traces of activity names, our aim is to derive from T
the description of the distributed system through CCS
processes composed in parallel. The first step of the
method is:
1. Individuation of the Traces of Each Compo-
nent of the Distributed System in Isolation (The
Layout)
We give the following definition.
Definition 3 (Layout Specification). Given a set of
traces of activity names derived from a log, the Lay-
out Specification of a distributed system is LS =
{T
1
,... ,T
n
}, where each T
i
has a distinct alphabet
αT
i
, and each activity in T
i
has the same source,
different from that of each other T
j
. Thus αLS =
αT
1
∪ ... ∪ αT
n
.
The second step consists in the representation
in the traces of communications performed among
devices; the activity definitions in the log allows
the individuation of corresponding communication
activities. This step is called:
2. Specification of the Synchronization Be-
tween Components (The Flow)
Definition 4 (Flow Specification. Renaming function
). Consider the Layout Specification LS and the set
C = {c
1
,... ,c
m
}, where c
j
= (e
j
1
,... ,e
j
k
),1 ≤ j ≤ m
and the names in the same tuple individuate corre-
sponding communication activities in the log. The re-
naming function S is such that ∀ j, s ∈ [1..m], S(c
j
) =
e
j
and e
j
6∈ αLS, moreover, for j 6= s it is S(c
j
) 6=
S(c
s
). The Flow Specification is FS = LS S(C).
From now on we will use S(C) for {S(c
1
),.. .,S(c
m
)}.
S renames all elements of C using the same new
name for all elements of the same tuple of C; obvi-
ously the new name given to each tuple is different
from those chosen for the other tuples and from all
other names in the traces. It is possible to have a third
step too of the method, when some system require-
ments are included in the specification. This kind of
requirements should be expressible as constraints on
the order and the number of communication activities,
and thus by means of traces on αFS. From now on we
call System Specification, SS, any Flow specification.
3.2 Formula-based Reduction of the
System Specification
The approach we present is based on the reduction of
the system specification: the function below removes
activity names from a generic trace.
Definition 5 (del
I
(t)). Given a trace t on the alpha-
bet A and I ⊆ A, we define the function del
I
: A
∗
→
A
∗
as following:
ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications
260

del
I
(t) =









e if t = e and e ∈ I
λ if t = e and e 6∈ I
del
I
(t
0
).del
I
(t
00
) if t = t
0
.t
00
< del
I
(t
0
) >
∗
if t =< t
0
>
∗
λ if t = λ
where λ is the empty trace.
The function del
I
can be extended to any set of
traces T as follows:
del
I
(T ) = {del
I
(t) | t ∈ T }
According to the syntax of a trace given in Definition
1, if the trace t is of the form “e” two cases may oc-
cur: 1) e is not the name of an interesting activity: we
delete e; 2) e is the name of an interesting activity:
we cannot delete e and the empty trace λ is returned.
If the trace t is of the form t
0
.t
00
, we apply the delete
function on t
0
and recursively on t
00
, while if the trace t
is of the form < t
0
>
∗
, we apply recursively the delete
function on t
0
, keeping the recursion. The function
terminates when the empty trace is encountered. Af-
ter having applied del
I
on the sets of traces belonging
to a system specification, we expect that the new set
of traces describes a behavior equivalent to the old
one with respect to the activity names in I . Conse-
quently, there are several problems to be taken into
account: when the name given to a synchronization
activity does not belong to I , its elimination can avoid
the possible deadlock of the system. Also the elimi-
nation of one branching name could avoid the feasi-
bility of alternative behaviors of the system. Thus, to
preserve the truth value of a formula, the names of
all communications and all branching names, must be
preserved by the reduction.
Definition 6 (I (SS,ϕ)). Consider a system specifica-
tion SS = LS S(C) = {T
1
,·· · , T
n
} and a selective
mu-calculus formula ϕ. The activity names of interest
in the system are
I (SS,ϕ) = O(ϕ) ∪ Be(T
1
∪ ··· ∪ T
n
) ∪ S(C)
4 MODEL DISCOVERY
Now we define a general syntactic transformation
function T which transforms a trace-based system
specification into a CCS process by means of the
auxiliary functions defined below. For the purpose
of mathematical reasoning it is often convenient and
simpler to represent a transition system algebraically
in the form of CCS processes, especially because all
formal verification environments can easily compute,
through the operational semantics, the corresponding
transition system.
Let T be a set of traces.
• F irst(T ) = {e | e.t ∈ T or < e.t >
∗
.t
0
∈ T }
• R est(T ) = {t | e.t ∈ T } ∪ {t
1
. < e.t
1
>
∗
.t
2
|
< e.t
1
>
∗
.t
2
∈ T }
• C ont(T ) = {t
2
| < t
1
>
∗
.t
2
∈ T }
F irst(T ) returns the set of all the first names of
the traces in T, while R est(T ) says as a trace may go
on after its first activity has been performed; C ont(T )
describes what happens when a loop is skipped. For
example, the trace < e.t >
∗
.t
0
describes a behavior
that becomes t. < e.t >
∗
.t
0
after the execution of e,
while it becomes t
0
when the loop terminates.
Definition 7 (Function S plit). Consider a set of
traces T , S plit(T ) = T
1
,... ,T
k
where each subset T
i
is such that
• T
i
= {t
i
1
,... ,t
i
n
| n ≥ 1,t
i
1
,... ,t
i
n
∈
T
i
,F irst({t
i
1
}) = . .. = F irst({t
i
n
})}, ∀i ∈ [1..k];
• T = T
1
∪ ··· ∪ T
k
;
• T
i
∩ T
j
=
/
0 and F irst(T
i
) 6= F irst(T
j
), ∀i, j ∈
[1..k] and i 6= j.
Now we are ready to define the syntactic transfor-
mation function T .
Definition 8 (T ). Consider the system specification
SS = ((LS S(C))) = {T
1
,·· · , T
n
} the CCS pro-
cesses x
1
:= T (T
1
),.. .,x
n
:= T (T
n
) can be obtained
by applying the transformation function T defined be-
low to each T
i
, 1 ≥ i ≤ n : T (T
i
) =



T
0
(t,DONE) if T
i
= t
(F
1
;R
1
+C
1
) + · ·· + (F
r
;R
r
+C
r
) otherwise
with







S plit(T
i
) = T
i
1
,... ,T
i
r
,r ≥ 1
F
j
:= F irst(T
i
j
);DONE j ∈ [1..r]
R
j
:= T (R est(T
i
j
)) j ∈ [1..r]
C
j
:= T (C ont(T
i
j
)) j ∈ [1..r]
and T
0
(t,C) =





C if t =<>
NC, where
NC := T
0
(t
1
,NC) + T
0
(t
2
,C) if t =< t
1
>
∗
.t
2
e. T
0
(t
0
,C) if t = e.t
0
where NC is a new constant.
Finally, the complete CCS program corresponding
to a System Specification is obtained as follows
Definition 9. Consider the system specification SS =
((LS S(C))) = {T
1
,·· · , T
n
}, the corresponding
CCS process is:
x := (x
1
kx
2
k··· kx
n
)
where, x
i
:= T (T
i
) ∀i ∈ [1..n]
Conformance Checking using Formal Methods
261

The correctness of our method is stated by the
following theorem.
Theorem 1. Let SS be a System Specification, ψ a
selective formula and ρ = I (SS,ψ):
T (del
ρ
(SS)) and T (SS) are ρ-equivalent
The corollary below expresses important conse-
quences on the system requirements of the reduction
method.
Corollary 1.
Let SS be a System Specification, ψ a selective for-
mula and ρ = I (SS,ψ):
T (SS) |= ψ iff T (del
ρ
(SS)) |= ψ
Example.
Let now consider the following Layout Specification
LS and the renaming function S:
LS = {T
1
,T
2
}, where
T
1
= {< a.b >
∗
,< a.c >
∗
.d}
T
2
= {< e. f >
∗
}
S(C) = S(c
1
) = k, where
c
1
= (a,e)
The Flow Specification FS = LS S(C) is:
FS = {T
0
1
,T
0
2
}
T
0
1
= {< k.b >
∗
,< k.c >
∗
.d}
T
0
2
= {< k. f >
∗
}
Let ϕ = hki
/
0
hdi
/
0
tt be the property that must be ver-
ified. Applying our methodology we obtain the fol-
lowing reduced Flow Specification RFS:
RFS = {RT
0
1
,RT
0
2
}
RT
1
= {< k. >
∗
,< k >
∗
.d}
RT
2
= {< k >
∗
}
The discovered CCS model obtaining using RFS is:
x := (x
1
kx
2
)
x
1
:= k.x
1
+ d.DONE
x
2
:= k.x
2
5 RELATED WORK
Conformance testing, i.e., checking whether a given
model and a given event log fit together, can be a
seen as a very specific form of log-based verifica-
tion: the discovered process model (i.e., a Petri net)
is used to verify whether the log satisfies some be-
havioral properties expressed by several possible for-
malisms. The first comprehensive approach to confor-
mance analysis was proposed in (Rozinat and van der
Aalst, 2008) by Rozinat and van der Aalst. Suc-
cessively, in (de Leoni et al., 2015) van der Aalst
and other authors present a novel log preprocessing
and conformance checking approach tailored towards
declarative models. They formulated conformance
checking problems as an optimization problem and
they suggest that traces containing undesirable be-
haviors could be corrected. Recently, declarative ap-
proaches have received increasing interest and sug-
gest a basically different way of describing business
processes too (van der Aalst et al., 2009). While im-
perative models specify exactly how things have to be
done, declarative approaches only focus on the logic
that governs the interplay of actions in the process
by describing the activities that can be performed,
as well as constraints prohibiting undesired behav-
ior. However, declarative process mining techniques
may produce models with a high quantity of con-
straints, which may be incomprehensible for humans,
as showed by Bose et al. (Bose et al., 2013). The com-
bination of constraints in a declarative process model
might generate new hidden dependencies, which are
complex and difficult to be identified (Haisjackl et al.,
2013); moreover, the increasing number of restric-
tions negatively impacts on the model quality (Rosa
et al., 2011). The work of van der Aalst et al. (van der
Aalst et al., 2005) follows another road and is closely
related to this paper: given an event log and a tempo-
ral property, they verify whether the observed behav-
ior matches the (un)expected/(un)desirable behavior
through a custom-made LTL Checker.
In this paper, we analyse conformance checking
using a formal verification methodology: first we de-
rive from the log a process described by a process al-
gebra, then we verify conformance between the dis-
covered process and any process model respecting the
given properties by the model checking of the dis-
covered process with respect to those properties. We
can exploit existing efficient model checking frame-
works to perform this task, for example, (Francesca
et al., 2011; De Francesco et al., 2016; De Francesco
et al., 2014; Barbuti et al., 2005). To cope with time
and space complexity (a typical problem of the model
checking context), we discover an abstract process by
a preprocessing of the traces derived from the log, so
directly building a reduced process, without generat-
ing before the LTS, for example, corresponding to the
complete log as in (Rubin et al., 2006); the reduction
is performed on the basis of the temporal logic for-
mulae to be verified and the method is completely au-
tomatable since it is based on the syntactic structure
of the formulae.
ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications
262

6 CONCLUSION AND FUTURE
WORK
An approach to conformance checking through model
checking has been presented. The approach aims at
the discovering of a process described in the process
algebra framework, while the system model is de-
fined through temporal logic properties. The main
characteristics of the method are: (i) conformance be-
tween the discovered process and the system model
performed by model checking of the temporal logic
properties; (ii) pre-processed traces are reduced on
the basis of the system properties; so it is avoided
the state explosion arising when starting from big
sets of traces; (iii) transformation rules directly ap-
ply to traces, without building any process represen-
tation before. As future work we planning to im-
plement our approach and to use LOTOS (Bolognesi
and Brinksma, 1987) specification language, instead
of CCS, in order to use more mature tools.
REFERENCES
Barbuti, R., De Francesco, N., Santone, A., and Vaglini,
G. (1999). Selective mu-calculus and formula-based
equivalence of transition systems. J. Comput. Syst.
Sci., 59(3):537–556.
Barbuti, R., De Francesco, N., Santone, A., and Vaglini, G.
(2005). Reduced models for efficient CCS verifica-
tion. Formal Methods in System Design, 26(3):319–
350.
Bolognesi, T. and Brinksma, E. (1987). Introduction to the
iso specification language lotos. Computer Networks,
14:25–59.
Bose, R. P. J. C., Maggi, F. M., and van der Aalst, W. M. P.
(2013). Enhancing declare maps based on event corre-
lations. In BPM 2013, Beijing, China, August 26-30,
2013. Proceedings, pages 97–112.
Clarke, E. M. and Lerda, F. (2007). Model checking: Soft-
ware and beyond. J. UCS, 13(5):639–649.
De Francesco, N., Lettieri, G., Santone, A., and Vaglini,
G. (2014). Grease: A tool for efficient ”nonequiva-
lence” checking. ACM Trans. Softw. Eng. Methodol.,
23(3):24.
De Francesco, N., Lettieri, G., Santone, A., and Vaglini,
G. (2016). Heuristic search for equivalence checking.
Software and System Modeling, 15(2):513–530.
de Leoni, M., Maggi, F. M., and van der Aalst, W. M. P.
(2015). An alignment-based framework to check the
conformance of declarative process models and to pre-
process event-log data. Inf. Syst., 47:258–277.
de Medeiros, A. K. A., van Dongen, B. F., van der Aalst, W.
M. P., and Weijters, A. J. M. M. (2004). Process min-
ing: Extending the α-algorithm to mine short loops.
In Eindhoven University of Technology, Eindhoven.
Francesca, G., Santone, A., Vaglini, G., and Villani, M. L.
(2011). Ant colony optimization for deadlock detec-
tion in concurrent systems. In COMPSAC, pages 108–
117.
Haisjackl, C., Zugal, S., Soffer, P., Hadar, I., Reichert, M.,
Pinggera, J., and Weber, B. (2013). Making sense of
declarative process models: Common strategies and
typical pitfalls. In BMMDS/EMMSAD 2013, Valencia,
Spain, June 17-18, 2013. Proceedings, pages 2–17.
Milner, R. (1989). Communication and concurrency. PHI
Series in computer science. Prentice Hall.
Reisig, W. and Rozenberg, G., editors (1998). Lectures on
Petri Nets I: Basic Models, Advances in Petri Nets, the
volumes are based on the Advanced Course on Petri
Nets, held in Dagstuhl, September 1996, volume 1491
of Lecture Notes in Computer Science. Springer.
Rosa, M. L., Wohed, P., Mendling, J., ter Hofstede, A.
H. M., Reijers, H. A., and van der Aalst, W. M. P.
(2011). Managing process model complexity via ab-
stract syntax modifications. IEEE Trans. Industrial
Informatics, 7(4):614–629.
Rozinat, A. and van der Aalst, W. M. P. (2008). Confor-
mance checking of processes based on monitoring real
behavior. Inf. Syst., 33(1):64–95.
Rubin, V., Dongen, B. F. V., Kindler, E., and G
¨
unther, C. W.
(2006). Process mining: A two-step approach using
transition systems and regions. Technical report, BPM
Center Report BPM-06-30, BPM Center.
Stirling, C. (1989). An introduction to modal and temporal
logics for ccs. In Concurrency: Theory, Language,
And Architecture, pages 2–20.
van der Aalst, W. M. P., de Beer, H. T., and van Dongen,
B. F. (2005). Process mining and verification of prop-
erties: An approach based on temporal logic. In OTM
Conferences 2005, Agia Napa, Cyprus, October 31 -
November 4, 2005, Proceedings, Part I, pages 130–
147.
van der Aalst, W. M. P., Pesic, M., and Schonenberg, H.
(2009). Declarative workflows: Balancing between
flexibility and support. Computer Science - R&D,
23(2):99–113.
Conformance Checking using Formal Methods
263