UNI.LU Seminar Jan2015 - Montali - Online Monitoring of Business Constraints and Metaconstraints

Online Monitoring
of Business Constraints and Metaconstraints
Using LTL and LDL over Finite Traces
Based on our BPM2014 Paper
Marco Montali
KRDB Research Centre for Knowledge and Data
Free University of Bozen-Bolzano
Joint work with: G. De Giacomo, R. De Masellis, M. Grasso, F.M. Maggi
Marco Montali (unibz) Monitoring Business Constraints UNI.LU 1 / 42

Data-Awareness in Dynamic Systems
Traditional approach to model dynamic systems: divide et impera of
• static, data-related aspects
• dynamic, process/interaction-related aspects.
Notable examples:
• In BPM: data and business processes are conceptually isolated from each
other, and only integrated at the implementation level.
• In MAS: a plethora of logics for reasoning about the behavior of agents and
their interaction, but completely neglecting the exchanged information.
; No coherent understanding of what the system is doing.
Our ultimate goals
1. Provide formal models that simultaneously account for the system
dynamics and the manipulation of data (databases/ontologies).
2. Devise logic-based techniques for the veriﬁcation and monitoring of
such integrated systems.
This combination poses major challenges to veriﬁcation.

Compliance Checking
Behaviors Compliance Checker
Regulatory Model
Feedback
Our setting:
• Behaviors are BP execution traces: linear sequences of atomic tasks.
• Regulatory model: set of business constraints about the accepted
dynamics.

Key Dimensions
How to model traces?
When is compliance checked?
How to capture the regulatory model?

How to Model Traces?
Two choices: finite vs infinite.
• A business process instance is expected to end.
• Hence, traces are finite sequences of tasks.

Design-time.
A-posteriori.
Runtime.

Design-time.
• Traces generated from a process model (cf. temporal model checking).
• Too coarse-grained when the process model is only partially
compliant.
A-posteriori.
Runtime.

Design-time.
A-posteriori.
• Traces extracted from an event log.
• Can only detect issues: no live support to people.
Runtime.

Design-time.
A-posteriori.
Runtime.
• Partial, evolving traces.
• Constant feedback to people.
• Fine-grained notion of compliance (things may change).
• A whole space of possibilities on the power of monitors.

How to Capture the Regulatory Model?
We want precision and understanding: logics!
We want to predicate about the (un)desired BP dynamics.

How to Capture the Regulatory Model?
We want precision and understanding: logics!
We want to predicate about the (un)desired BP dynamics.
Hence:
• Linear
• Temporal/Dynamic
Logics
• over ﬁnite traces.

Declarative Approach to Business Process Modeling -
Declare
Basic idea: Drop explicit representation of processes, and ltlf formulas
specify the allowed (finite) traces. [VanDerAalstPesic06,ACM-TWEB10]
178 M. Pesic
forbidden
optional
allowed
possible
(a) forbidden, optional and allowed
in business processes
(b) procedural workflow
control-flow
(c) declarative workflow
constraints
constraints constraints
constraints
Fig. 6.3 Declarative vs. procedural workflows
the constraint-based approach can provide for all types of flexibility listed in the
previous paragraph. A concrete implementation that enables creating decomposi-Marco Montali (unibz) Monitoring Business Constraints UNI.LU 8 / 42

Declare at a Glance
64 3 The ConDec Language
choose
item
pay
refuse
shipment
accept
shipment
deliver
receipt
0..1
accept
order
close
order
cancel
order
refuse
order
C
C C C
S
S
S
W
W
0..1
Fig. 3.2. Complete ConDec model capturing the order management choreography
Table 3.7. Some cognitive dimensions
closeness of mapping Closeness of representation to domain
abstraction Types and availability of abstraction mechanisms
From [LNBIP-56].

Declare Patterns
Declare promotes the use of a controlled set of notable ltlf formulas
for process speciﬁcation. [VanDerAalstPesic06,ACM-TWEB10]
Example (Some Declare Patterns)
name notation ltlf description
Existence
1..∗
a 3a a must be executed at least once
Resp. existence a •−−−− b 3a → 3b If a is executed, then b must be executed as well
Response a •−−− b 2(a → 3b) Every time a is executed, b must be executed afterwards
Precedence a −−− • b ¬b W a b can be executed only if a has been executed before
Alt. Response a •=== b 2(a → ◦(¬a U b)) Every a must be followed by b, without any other a
inbetween
Chain Response a •=−=−=− b 2(a → ◦b) If a is executed then b must be executed next
Chain Precedence a =−=−=− • b 2(◦b → a) Task b can be executed only immediately after a
Not Coexistence a •−−−• b ¬(3a ∧ 3b) Only one among tasks a and b can be executed
Neg. Succession a •−− • b 2(a → ¬3b) Task a cannot be followed by b, and b cannot be pre-
ceded by a

Parenthesis: the Subtlety of Finite Traces
Linear Temporal Logic (ltl) ubiquitous in AI and CS
However:
• Sometimes we interpret temporal logic on inﬁnite traces as originally
proposed [Pnueli1977].

However:
• Sometimes we interpret temporal logic on ﬁnite traces
[DeGiacomoVardi13].

However:
[DeGiacomoVardi13].
• Often, we blur the distinction interpreting ltl on inﬁnite or on ﬁnite
traces.

However:
[DeGiacomoVardi13].
• Often, we blur the distinction interpreting ltl on infinite or on finite
traces.
• Temporally extended goals - infinite/finite
• Temporal constraints on trajectories - finite
• Declarative and Procedural control knowledge on trajectories - finite
• Temporal specification in planning domains - infinite
• Planning via model checking - infinite
• Declarative Business Processes Specification: Declare - finite

Blurring of ltl and ltlf
From [Edelkamp2006]
We can cast the Büchi automaton as an NFA, which accepts a word if it
terminates in a final state.
From [GereviniEtAl2009]
Since PDDL 3.0 constraints are normally evaluated over finite trajectories, the
Büchi acceptance condition “an accepting state is visited infinitely often”, reduces
to the standard acceptance condition that the automaton is in an accepting state
at the end of the trajectory.
From [VanDerAalstPesic06]
We use the original (ltl) algorithm, but we specify that each execution
eventually ends.
• We introduce an “invisible” activity end, the ending activity in the model.
• We use this activity to specify that the service will end:
3end ∧ 2(end → ◦end))

Are these appealing intuitions correct?

Are these appealing intuitions correct? NO!

But why do they seem reasonable and were adopted for several years?

But why do they seem reasonable and were adopted for several years?
See [AAAI14]
In summary:
• For many widely used ltlf patterns, the intuition in
[VanDerAalstPesic06] is indeed correct.
• But it cannot be generalized to the entire logic.

ltl over finite traces
Assuming finite or infinite traces has big impact.

Example
Consider the following formula:
2(A → 3B) ∧ 2(B → 3A)

Example
2(A → 3B) ∧ 2(B → 3A)
• On inﬁnite traces:

Example
2(A → 3B) ∧ 2(B → 3A)
...A B A B ...A B

Example
2(A → 3B) ∧ 2(B → 3A)
...A B A B ...A B
• On ﬁnite traces:

Example
2(A → 3B) ∧ 2(B → 3A)
...A B A B ...A B
• On ﬁnite traces:
A
A
B

Example
Consider again the formula: 2(A → 3B) ∧ 2(B → 3A)
• Büchi automaton accepting its inﬁnite traces:
• NFA accepting its ﬁnite traces:

Process Mining

Process Mining
Classicaly applied to post-mortem data.

Operational Decision Support
Extension of classical process mining to current, live data.
Refined process mining framework
PAGE
information system(s)
current
data
“world”people
machines
organizations
business
processes documents
historic
data
resources/
organization
data/rules
control-flow
de jure models
resources/
organization
data/rules
control-flow
de facto models
provenance
explore
predict
recommend
detect
check
compare
promote
discover
enhance
diagnose
cartographynavigation auditing
event logs
models
“pre
mortem”
“post
mortem”

Detecting Deviations
Auditing: ﬁnd deviations between observed and expected behaviors.
e
o
e
ee
.
current
data
historic
data
resources/
organization
data/rules
control-flow
de jure models
resources/
organization
data/rules
control-flow
de facto models
detect
check
compare
promote
auditing
event logs
models
“pre
mortem”
“post
mortem”

Detecting Deviations
Auditing: ﬁnd deviations between observed and expected behaviors.
e
o
e
ee
.
current
data
historic
data
resources/
organization
data/rules
control-flow
de jure models
resources/
organization
data/rules
control-flow
de facto models
detect
check
compare
promote
auditing
event logs
models
“pre
mortem”
“post
mortem”
Our setting:
Model
Declarative business constraints.
• E.g., Declare.
Monitoring
• Online, evolving observations.
• Prompt deviation detection.

On Promptness
Flight routes (thanks Claudio!)
• When the airplane takes oﬀ, it must eventually reach the destination airport.
• When the airplane is re-routed, it cannot reach the destination airport anymore.
• If a dangerous situation is detected at the destination, airplane must be re-routed.
take-off reach re-route danger
Question
Consider trace:
take-off danger
Is there any deviation?

Boring Answer: Apparently Not
Reactive Monitor
• Checks the partial trace
observed so far.
• Suspends the judgment if no
conclusive answer can be given.
take-off danger

Prophetic Answer: YES
Proactive Monitor
• Checks the partial trace observed so far.
• Looks into the future(s).
Ciao
Marco Montali (unibz) Monitoring
take-off danger

Prophetic Answer: YES
Proactive Monitor
• Checks the partial trace observed so far.
• Looks into the future(s).
Ciao
Marco Montali (unibz) Monitoring
2(take-off → 3reach) ∧ ¬(3(reach) ∧ 3(re-route)) ∧ 2(danger → 3re-route)
take-off danger

Logics on Finite Traces
Goal
Reasoning on finite partial traces and their finite suffixes.
Typical Solution: ltlf
Adopt LTL on finite traces and corresponding techniques based on
Finite-State Automata.a
a
Not Büchi automata!

Logics on Finite Traces
Goal
Reasoning on finite partial traces and their finite suffixes.
Typical Solution: ltlf
Adopt LTL on finite traces and corresponding techniques based on
Finite-State Automata.a
a
Not Büchi automata!
Remember the difference, often neglected, between LTL on finite and
infinite traces!
See [AAAI2014]

Problem #1: Monitoring
Proactive monitoring requires to reﬁne the standard ltlf semantics.
RV-LTL
Given an LTL formula ϕ:
• [ϕ]RV = true ; OK;
• [ϕ]RV = false ; BAD;
• [ϕ]RV = temp_true ; OK now, could become BAD in the future;
• [ϕ]RV = temp_false ; BAD now, could become OK in the future.

Problem #1: Monitoring
Proactive monitoring requires to refine the standard ltlf semantics.
RV-LTL
Given an LTL formula ϕ:
• [ϕ]RV = true ; OK;
• [ϕ]RV = false ; BAD;
• [ϕ]RV = temp_true ; OK now, could become BAD in the future;
• [ϕ]RV = temp_false ; BAD now, could become OK in the future.
However. . .
• Typically studied on infinite traces: detour to Büchi automata.
• Only ad-hoc techniques on finite traces [BPM2011].

Problem #2: Contextual Business Constraints
Need for monitoring constraints only when speciﬁc circumstances hold.
• Compensation constraints.
• Contrary-do-duty “expectations” (yes, I’m scared about obligations).
• . . .

Problem #2: Contextual Business Constraints
Need for monitoring constraints only when speciﬁc circumstances hold.
• Compensation constraints.
• Contrary-do-duty “expectations” (yes, I’m scared about obligations).
• . . .
However. . .
• Cannot be systematically captured at the level of constraint
speciﬁcation.

Suitability of the Constraint Speciﬁcation Language
ltlf
FOL over
ﬁnite traces
Star-free
regular
expressions

ltlf
MSOL over
ﬁnite traces
FOL over
ﬁnite traces
Regular
expressions
Star-free
regular
expressions

ltlf
MSOL over
finite traces
FOL over
finite traces
Regular
expressions
Star-free
regular
expressions
pspace
complexity
Nondet.
finite-state
automata
(nfa)
• ltlf : declarative, but lacking expressiveness.
• Regular expressions: rich formalism, but low-level.
(t)ake-off (r)each ((r|other)∗
(t(t|other)∗
r)(r|other)∗
)∗

ldlf
Linear Dynamic
Logic over
finite traces
ltlf
MSOL over
finite traces
FOL over
finite traces
Regular
expressions
Star-free
regular
expressions
pspace
complexity
Nondet.
finite-state
automata
(nfa)
• ltlf : declarative, but lacking expressiveness.
• Regular expressions: rich formalism, but low-level.
(t)ake-off (r)each ((r|other)∗
(t(t|other)∗
r)(r|other)∗
)∗
• ldlf : combines the best of the two!

The Logic ldlf [De Giacomo&Vardi,IJCAI13]
Merges ltlf with regular expressions, through the syntax of Propositional
Dynamic Logic (PDL):
ϕ ::= φ | tt | ff | ¬ϕ | ϕ1 ∧ ϕ2 | ρ ϕ | [ρ]ϕ
ρ ::= φ | ϕ? | ρ1 + ρ2 | ρ1; ρ2 | ρ∗
ϕ: ltlf part; ρ: regular expression part.
They mutually refer to each other:
• ρ ϕ states that, from the current step in the trace, there is an
execution satisfying ρ such that its last step satisfies ϕ.
• [ρ]ϕ states that, from the current step in the trace, all execution
satisfying ρ are such that their last step satisfies ϕ.
• ϕ? checks whether ϕ is true in the current step and, if so, continues
to evaluate the remaining execution.
Of special interest is end = [true?]ff , to check whether the trace has been
completed (the remaining trace is the empty one).

Runtime ldlf Monitors
Check partial trace π = e1, . . . , en against formula ϕ.
From ad-hoc techniques . . .
e1 . . . en |= ϕ RV =



temp_true
temp_false
true
false

Runtime ldlf Monitors
Check partial trace π = e1, . . . , en against formula ϕ.
From ad-hoc techniques . . .
e1 . . . en |= ϕ RV =



temp_true
temp_false
true
false
. . . To standard techniques
e1 . . . en |=



ϕtemp_true
ϕtemp_false
ϕtrue
ϕfalse

How is This Magic Possible?
Starting point: ltlf /ldlf formula ϕ and its RV semantics.

1. Good and bad preﬁxes
• Lposs_good(ϕ) = {π | ∃π .ππ ∈ L(ϕ)}
• Lnec_good(ϕ) = {π | ∀π .ππ ∈ L(ϕ)}
• Lnec_bad(ϕ) = Lnec_good(¬ϕ) = {π | ∀π .ππ ∈ L(ϕ)}

1. Good and bad prefixes
• Lposs_good(ϕ) = {π | ∃π .ππ ∈ L(ϕ)}
• Lnec_good(ϕ) = {π | ∀π .ππ ∈ L(ϕ)}
• Lnec_bad(ϕ) = Lnec_good(¬ϕ) = {π | ∀π .ππ ∈ L(ϕ)}
2. RV-LTL values as prefixes
• π |= [ϕ]RV = true iff π ∈ Lnec_good(ϕ);
• π |= [ϕ]RV = false iff π ∈ Lnec_bad(ϕ);
• π |= [ϕ]RV = temp_true iff π ∈ L(ϕ) Lnec_good(ϕ);
• π |= [ϕ]RV = temp_false iff π ∈ L(¬ϕ) Lnec_bad(ϕ).

How is This Black Magic Possible?
3. Preﬁxes as regular expressions
Every nfa can be expressed as a regular expression.
; We can build regular expression prefϕ s.t. L(prefϕ) = Lposs_good(ϕ).

4. Regular expressions can be immersed into ldlf
Hence: π ∈ Lposs_good(ϕ) iﬀ π |= prefϕ end
π ∈ Lnec_good(ϕ) iﬀ π |= prefϕ end ∧ ¬ pref¬ϕ end

4. Regular expressions can be immersed into ldlf
Hence: π ∈ Lposs_good(ϕ) iff π |= prefϕ end
π ∈ Lnec_good(ϕ) iff π |= prefϕ end ∧ ¬ pref¬ϕ end
5. RV-LTL can be immersed into ldlf !
• π |= [ϕ]RV = true iff prefϕ end ∧ ¬ pref¬ϕ end;
• π |= [ϕ]RV = false iff pref¬ϕ end ∧ ¬ prefϕ end;
• π |= [ϕ]RV = temp_true iff π |= ϕ ∧ pref¬ϕ end;
• π |= [ϕ]RV = temp_false iff π |= ¬ϕ ∧ prefϕ end.
Ending point: 4 ldlf monitor formulae under standard semantics.

Monitoring declare with ldlf
Step 1. Good preﬁxes of declare patterns.
name notation pref possible RV states
existence
Existence
1..∗
a (a + o)∗ temp_false, true
Absence 2
0..1
a o∗ + (o∗; a; o∗) temp_true, false
choice
Choice a −−
♦
−− b (a + b + o)∗ temp_false, true
Exclusive Choice a −− −− b (a + o)∗ + (b + o)∗ temp_false, temp_true, false
relation
Resp. existence a •−−−− b (a + b + o)∗ temp_true, temp_false, true
Response a •−−− b (a + b + o)∗ temp_true, temp_false
Precedence a −−− • b o∗; (a; (a + b + o)∗)∗ temp_true, true, false
negation
Not Coexistence a •−−−• b (a + o)∗ + (b + o)∗ temp_true, false
Neg. Succession a •−− • b (b + o)∗; (a + o)∗ temp_true, false

Monitoring declare with ldlf
Step 1. Good preﬁxes of declare patterns.
name notation pref possible RV states
existence
Existence
1..∗
a (a + o)∗ temp_false, true
Absence 2
0..1
a o∗ + (o∗; a; o∗) temp_true, false
choice
Choice a −−
♦
−− b (a + b + o)∗ temp_false, true
Exclusive Choice a −− −− b (a + o)∗ + (b + o)∗ temp_false, temp_true, false
relation
Resp. existence a •−−−− b (a + b + o)∗ temp_true, temp_false, true
Response a •−−− b (a + b + o)∗ temp_true, temp_false
Precedence a −−− • b o∗; (a; (a + b + o)∗)∗ temp_true, true, false
negation
Not Coexistence a •−−−• b (a + o)∗ + (b + o)∗ temp_true, false
Neg. Succession a •−− • b (b + o)∗; (a + o)∗ temp_true, false
Step 2. Generate ldlf monitors.
• Local monitors: 1 formula for possible RV constraint state.
• Global monitors: 4 RV formulae for the conjunction of all constraints.

One Step Beyond: Metaconstraints
ldlf monitors are simply ldlf formulae.
They can be combined into more complex ldlf formulae!
• E.g., expressing conditional/contextual monitoring.
Business metaconstraint
An ldlf formula of the form Φpre → Ψexp
• Φpre combines membership assertions of business constraints to their
RV truth values.
• Ψexp combines business constraints to be checked when Φpre holds.
ldlf metaconstraint monitors
• Φpre → Ψexp is a standard ldlf formula.
• Hence, just reapply our technique and get the 4 ldlf monitors.

Compensation Constraints
• An order cannot be canceled anymore if it is closed.
ϕcanc = close order •−− • cancel order
• If this happens, then the customer has to pay a supplement:
ϕdopay =
1..∗
pay supplement
• Formally: {[ϕcanc]RV = false} → ϕdopay
• In ldlf : ( pref¬ϕcanc
end ∧ ¬ prefϕcanc
end) → ϕdopay

Compensation Constraints
• If this happens, then the customer has to pay a supplement:
ϕdopay =
1..∗
pay supplement
• Formally: {[ϕcanc]RV = false} → ϕdopay
• In ldlf : ( pref¬ϕcanc
end ∧ ¬ prefϕcanc
end) → ϕdopay
Observation
When the violation occurs, the compensation is monitored from the
beginning of the trace: OK to “compensate in advance”.
• Trace close order → pay supplement → cancel order is OK.

Metaconstraints Revisited
Business metaconstraint with temporal consequence
1. Take Φpre and Ψexp as before.
2. Compute ρ: regular expression denoting those paths that satisfy Φpre
3. Make ρ part of the compensation:
Φpre→ [ρ] Ψexp

Metaconstraints Revisited
Business metaconstraint with temporal consequence
1. Take Φpre and Ψexp as before.
2. Compute ρ: regular expression denoting those paths that satisfy Φpre
3. Make ρ part of the compensation:
Φpre→ [ρ] Ψexp
Ψexp has now to be enforced after Φpre becomes true.

Compensation Revisited
• After this happens, then the customer has to pay a supplement:
ϕdopay =
1..∗
pay supplement
• Formally:
{[ϕcanc]RV = false}→ [re{[ϕcanc]RV =false}] ϕdopay

Compensation Revisited
• After this happens, then the customer has to pay a supplement:
ϕdopay =
1..∗
pay supplement
• Formally:
{[ϕcanc]RV = false}→ [re{[ϕcanc]RV =false}] ϕdopay
All traces violating ϕcanc

From ldlf to nfa
Direct calculation of nfa corresponding to ldlf formula ϕ
Algorithm
1: algorithm ldlf 2nfa()
2: input ltlf formula ϕ
3: output nfa Aϕ = (2P
, S, {s0}, , {sf })
4: s0 ← {"ϕ"} single initial state
5: sf ← ∅ single ﬁnal state
6: S ← {s0, sf }, ← ∅
7: while (S or change) do
8: if (q ∈ S and q |= ("ψ"∈q) δ("ψ", Θ))
9: S ← S ∪ {q } update set of states
10: ← ∪ {(q, Θ, q )} update transition relation
Note
• Standard nfa.
• No detour to Büchi automata.
• Easy to code.
• Implemented!
Auxiliary rules
δ("tt", Π) = true
δ("ﬀ ", Π) = false
δ("φ", Π) =
true if Π |= φ
false if Π |= φ
(φ propositional)
δ("ϕ1 ∧ ϕ2", Π) = δ("ϕ1", Π) ∧ δ("ϕ2", Π)
δ("ϕ1 ∨ ϕ2", Π) = δ("ϕ1", Π) ∨ δ("ϕ2", Π)
δ(" φ ϕ", Π) =



"ϕ" if last ∈ Π and Π |= φ (φ propositional)
δ("ϕ", ) if last ∈ Π and Π |= φ
false if Π |= φ
δ(" ψ? ϕ", Π) = δ("ψ", Π) ∧ δ("ϕ", Π)
δ(" ρ1 + ρ2 ϕ", Π) = δ(" ρ1 ϕ", Π) ∨ δ(" ρ2 ϕ", Π)
δ(" ρ1; ρ2 ϕ", Π) = δ(" ρ1 ρ2 ϕ", Π)
δ(" ρ∗
ϕ", Π) =
δ("ϕ", Π) if ρ is test-only
δ("ϕ", Π) ∨ δ(" ρ ρ∗ ϕ", Π) o/w
δ("[φ]ϕ", Π) =



"ϕ" if last ∈ Π and Π |= φ (φ propositional)
δ("ϕ", ) if last ∈ Π and Π |= φ (φ propositional)
true if Π |= φ
δ("[ψ?]ϕ", Π) = δ("nnf (¬ψ)", Π) ∨ δ("ϕ", Π)
δ("[ρ1 + ρ2]ϕ", Π) = δ("[ρ1]ϕ", Π) ∧ δ("[ρ2]ϕ", Π)
δ("[ρ1; ρ2]ϕ", Π) = δ("[ρ1][ρ2]ϕ", Π)
δ("[ρ∗
]ϕ", Π) =
δ("ϕ", Π) if ρ is test-only
δ("ϕ", Π) ∧ δ("[ρ][ρ∗]ϕ", Π) o/w

Implemented in ProM!
Approach
1. Input ltlf /ldlf constraints and metaconstraints.
2. Produce the corresponding RV ldlf monitoring formulae.
3. Apply the direct algorithm and get the corresponding nfas.
4. (Incrementally) run nfas the monitored trace.

Colored Automata [BPM2011]
Ad-hoc technique for monitoring ltlf formulae according to RV-LTL.
1. Bulild a local automaton for each of the business constraints.
2. Color states of each local automaton according to the 4 RV-LTL truth
values.
3. Combine colored automata into a global colored automaton.

Colored Automata
resulting in a complex or over-restrictive model.
Low_Risk
High_YieldMoney Stocks
Bonds
=
alternate
response
response
precedence
not co-existence
Fig. 1. Reference Model
000
(N)(P)(R)
001
(N)(P)r
M
010
(N)(R)
C
202
(N)(P)R
E
320
(N)P(R)
S
011
(N)r
C
E
321
(N)Pr
S
M
212
(N)R
E
310
(N)(R)
S
E
311
(N)r
S
112
R
122
PR
S
C
S
E
M
E
E
M E

Correctness of Colored Automata
Why is coloring correct?
1. Take the ltlf formula ϕ of each business constraint constraint.
2. Produce the 4 corresponding ldlf monitoring formulae.
3. Generate the 4 corresponding nfas.
4. Determinize them ; they are identical but with = acceptance states!
5. Hence they can be combined into a unique colored local dfa.

Conclusion
• Focus on finite traces.
• Avoid unneeded detour to infinite traces.
• ldlf : essentially, the maximal expressive logic for finite traces with
good computational properties (≡ MSO).
• Monitoring is a key problem.
• ldlf goes far beyond declare.
• ldlf captures monitors directly as formulae.
Clean.
Meta-constraints.
• Implemented in ProM!
Future work: declarative, data-aware processes.

UNI.LU Seminar Jan2015 - Montali - Online Monitoring of Business Constraints and Metaconstraints

Recommended

Recommended

More Related Content

Similar to UNI.LU Seminar Jan2015 - Montali - Online Monitoring of Business Constraints and Metaconstraints

Similar to UNI.LU Seminar Jan2015 - Montali - Online Monitoring of Business Constraints and Metaconstraints (20)

More from Faculty of Computer Science - Free University of Bozen-Bolzano

More from Faculty of Computer Science - Free University of Bozen-Bolzano (20)

Recently uploaded

Recently uploaded (20)

UNI.LU Seminar Jan2015 - Montali - Online Monitoring of Business Constraints and Metaconstraints