Invited talk on "Temporal logics over finite traces for declarative BPM" at the Workshop on Formal Methods for Artificial Intelligence (FMAI 2017), 22-24/02/2017, Naples, Italy
Temporal logics over finite traces for declarative BPM
1. Marco Montali
Free University of Bozen-Bolzano
montali@inf.unibz.it
cess Story
TEMPORAL
DECLARATIVE
OVER
FOR
BPM
FINITE
TRACES
LOGICS
A SUCCESS STORY
marco montali
free university
of bozen-bolzano
FMAI17
2. Assets of an Organization
• Data: the main information source about the history
of the domain of interest and the relevant aspects
of the current state of affairs
• Resources: humans and devices responsible for
the execution of work
• Business processes: how work is carried out in
the domain of interest, towards the achievement of
organizational objectives
2
3. Business Process Management
A collection of
concepts, methodologies, techniques,
to support humans in
modeling, governance, deployment,
enactment, and analysis of
business processes
3
8. Flexibility vs Control
Flexibility: degree to which users can make local
decisions about how to execute processes.
Control: degree to which a system makes centralized
decisions about how to execute processes.
Universe of Traces
Compliant
Traces
Flexibility8
9. Trends in BPM
modeling
• Highly-variable BPs
• Metaphor: rules/constraints
Dec t i
lar
a
ev
Imperative modeling
• Traditional repetitive BPs
• Metaphor: flow-chart
9
13. Imperative Modeling
Focus: howthings must be done
• Explicit description of the process control-flow
Closedmodeling
• All that is not explicitly modeled is forbidden
• Exceptions/uncommon behaviors have to be
explicitly enumerated at design time
13
18. Choreography Example
• An order can be finalized at most once
• Once an order is finalized, it must be confirmed or rejected
• A confirmed order may be rejected later on (due to “late”
problems), but not vice-versa: a rejection cannot be reverted.
• An order can be confirmed only if it shipped before.
• An order may be rejected autonomously by the seller.
However, if the warehouse notifies the seller of a shipment
issue, then the seller has to reject the order.
• The warehouse decision is firm: “Ship” and “Notify shipment
issue” are mutually exclusive.
18
25. Constraint-Based Modeling
Focus: whathas to be accomplished
• Explicit description of the relevant business constraints
• behavioral constraints, best practices, norms, rules, …
Openmodeling
• All behaviors are possible unless they are explicitly
forbidden
• Control-flow left implicit
25
29. Declare
• A constraint-based extensible language
for flexible process modeling
• An execution engine for constraint-based
processes
http://www.win.tue.nl/declare/
• Originally proposed by Pesic and van der
Aalst
• Formalized by Pesic and van der Aaalst,
and by _
29
31. 0..1
Modeling in Declare
Finalize order
Confirm
order
Reject
order
Ship
Notify
shipment issue
An order can be
finalized at most once
31
32. 0..1
Modeling in Declare
Finalize order
Confirm
order
Reject
order
Ship
Notify
shipment issue
Once an order is finalized, it must
be confirmed or rejected
32
34. 0..1
Modeling in Declare
Finalize order
Confirm
order
Reject
order
Ship
Notify
shipment issue
A confirmed order may be rejected
later on, but not vice-versa
34
35. 0..1
Modeling in Declare
Finalize order
Confirm
order
Reject
order
Ship
Notify
shipment issue
if the warehouse notifies the seller of a shipment
issue, then the seller has to reject the order
An order can be confirmed only if
it shipped before
35
37. Existence Constraints
50 3 The ConDec Language
Table 3.1. ConDec existence constraints
name graphical meaning
absence(a)
0
a Activity a cannot be executed
absence(n+1,a)
0..n
a
Activity a can be executed at most n times, i.e., the
execution trace cannot contain n + 1 occurrences of a
existence(n,a)
n..∗
a Activity a must be executed at least n times
exactly(n,a)
n
a Activity a must be executed exactly n times
init(a)
init
a Activity a must be the first executed activity
1..∗
order item
On the contrary, an absenceN constraint could be used to state that at most
three payment attempts can be made by the customer:
Examples:
ec existence constraints
graphical meaning
0
a Activity a cannot be executed
0..n
a
Activity a can be executed at most n times, i.e., the
execution trace cannot contain n + 1 occurrences of a
n..∗
a Activity a must be executed at least n times
n
a Activity a must be executed exactly n times
init
a Activity a must be the first executed activity
1..∗
order item
, an absenceN constraint could be used to state that at most
absence(n+1,a)
0..n
a
Activity a can be executed at most n times, i
execution trace cannot contain n + 1 occurrenc
existence(n,a)
n..∗
a Activity a must be executed at least n times
exactly(n,a)
n
a Activity a must be executed exactly n times
init(a)
init
a Activity a must be the first executed activity
1..∗
order item
On the contrary, an absenceN constraint could be used to state that a
three payment attempts can be made by the customer:
0..3
pay
37
38. Choice Constraints
3.3 Constraints 51
Table 3.2. ConDec choice constraints
name graphical meaning
choice(n of m,[a1,...,am])
a1
am
a2
n of m
...
At least n distinct activities
among a1,. . . ,am must be exe-
cuted
ex choice(n of m,[a1,...,am])
a1
am
a2
n of m
...
Exactly n distinct activities
among a1,. . . ,am must be exe-
cuted
Note that the constraint supports an execution trace containing three submis-
sions of the paper (via e-mail and/or by using the web site), while it evaluates
a trace without submissions as noncompliant.
A 1 of 2-exclusive choice can be instead adopted to model the existence
between two alternatives that exclude each other. For example, it could be
used to state that, within an instance of the system, the customer commits
herself to cancel or successfully close the order, but not both:
Examples:
choice(n of m,[a1,...,am])
a1
am
a2
n of m
...
At least n distinct activitie
among a1,. . . ,am must be exe
cuted
x choice(n of m,[a1,...,am])
a1
am
a2
n of m
...
Exactly n distinct activitie
among a1,. . . ,am must be exe
cuted
ote that the constraint supports an execution trace containing three submis
ons of the paper (via e-mail and/or by using the web site), while it evaluate
trace without submissions as noncompliant.
A 1 of 2-exclusive choice can be instead adopted to model the existenc
etween two alternatives that exclude each other. For example, it could b
sed to state that, within an instance of the system, the customer commit
erself to cancel or successfully close the order, but not both:
cancel order −− −− close order
It is worth noting that choice constraints, together with the existence38
39. name graphical meaning
resp existence([a], [b]) a •−−−− b
If a is executed, then b must be exe-
cuted before or after a
coexistence([a],[b]) a •−−−• b
Neither a nor b is executed, or they
are both executed
response([a],[b]) a •−−− b
If a is executed, then b must be exe-
cuted thereafter
precedence([a],[b]) a −−− • b
b can be executed only if a has been
previously executed
succession([a],[b]) a •−− • b
a and b must be executed in succes-
sion, i.e. b must follow a and a must
precede b
alt response([a],[b]) a •=== b
b is response of a and between every
two executions of a, b must be exe-
cuted at least once
alt precedence([a],[b]) a === • b
a is precedence of b and between ev-
ery two executions of b, a must be
executed at least once
alt succession([a],[b]) a •== • b
b is alternate response of a, and a is
alternate precedence of b
chain response([a],[b]) a •=−=−=− b
If a is executed, then b must be exe-
cuted next (immediately after a)
chain precedence([a],[b]) a =−=−=− • b
If b is executed, then a must have
been executed immediately before b
chain succession([a],[b]) a •=−=− • b
a and b must be executed in sequence
(next to each other)
RelationConstraints
39
40. NegationConstraints
Table 3.4. ConDec negation constraints
name graphical meaning
resp absence([a],[b]) a •−−−−∥ b
If a is executed, then b can never
be executed
not coexistence([a],[b]) a •−−−•∥ b a and b exclude each other
neg response([a],[b]) a •−−−∥ b b cannot be executed after a
neg precedence([a],[b]) a −−− •∥ b a cannot be executed before b
neg succession([a],[b]) a •−− •∥ b
a and b cannot be executed in
succession
neg alt response([a],[b]) a •===∥ b
b cannot be executed between
any two occurrences of a
neg alt precedence([a],[b]) a === •∥ b
a cannot be executed between
any two bs
neg alt succession([a],[b]) a •== •∥ b
b cannot be executed between
any two as and viceversa
neg chain response([a],[b]) a •=−=−=−∥ b b cannot be executed next to a
neg chain precedence([a],[b]) a =−=−=− •∥ b
a cannot be executed immedi-
ately before b
neg chain succession([a],[b]) a •=−=− •∥ b
a and b cannot be executed in
sequence
40
44. A Slide of Fairness
The disruptive novelty of this idea has to be
put in the BPM context!
• In AI, these ideas have been around for a
long time
• E.g., work on declarative interaction protocols
and temporal declarative specification of
agents
44
46. The Origin of Declare…
46
LTL
Each process instance
eventually terminates!
47. The Origin of Declare…
47
LTLf
Each process instance
eventually terminates!
Models: finite traces
48. Declare 2 Finite State Automata
LTLf NFA
nondeterministic
DFA
deterministic
LTLf2aut determin.
'
48
For a single constraint:
local automaton
For the whole model:
global automaton
51. Formalization Example
Moored
Under way
using engine
Under way
sailing
constrained by
her draught
¬(⌃e ^ ⌃s)
Model formula: conjunction of all constraint formulae
⇤(m ! ⌃e)
51
¬cWs
56. Correctness
• In BPM: typically assessed via model checking
• In the case of Declare: satisfiability
• Correct Declare model: there exists at least a finite
trace satisfying all its constraints
• i.e., if its LTLf model formula is satisfiable
• A correct model may still contain dead activities: activities
that can never be executed
• How to check? Language emptiness of the
corresponding NFA
56
58. Enactment of a Process
• History recognition: given the history of a running
instance, compute the current state (or reject)
• Todo list: given the current state, tell
which tasks can(not) be executed next
(including possibility of termination)
• Update: given a state and a task,
determine the new state
S
A
B
C
S
SnewS
58
68. RV-LTL Truth Values
Refined analysis of the “truth value” of a constraint.
Consider a partial trace t, and a constraint C
• C is permanently satisfied if t satisfies C and no matter
how t is extended, C will stay satisfied
• C is temporarily satisfied if t satisfies C but there is a
continuation of t that violates C
• C is temporarily violated if t violates C but there is a
continuation that leads to satisfy C
• C is permanently violated if t violates C and no matter
how t is extended, C will stay violated
68
69. Linear Dynamic Logic
over Finite Traces
69
The Logic ldlf [De Giacomo&Vardi,IJCAI13]
Merges ltlf with regular expressions, through the syntax of Propositional
Dynamic Logic (PDL):
Ï ::= „ | tt | | ¬Ï | Ï1 · Ï2 | ÈflÍÏ | [fl]Ï
fl ::= „ | Ï? | fl1 + fl2 | fl1; fl2 | flú
Ï: ltlf part; fl: regular expression part.
They mutually refer to each other:
• ÈflÍÏ states that, from the current step in the trace, there is an
execution satisfying fl such that its last step satisfies Ï.
• [fl]Ï states that, from the current step in the trace, all execution
satisfying fl 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?] , to check whether the trace has been
70. Automata for LDLf
70
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 final state
6: S Ω {s0, sf }, Í Ω ÿ
7: while (S or Í change) do
8: if (q œ S and qÕ
|=
w
("Â"œq) ”("Â", ))
9: S Ω S fi {qÕ
} Û update set of states
10: Í Ω Í fi {(q, , qÕ
)} Û update transition relation
Note
• Standard nfa.
• No detour to Büchi automata.
• Easy to code.
• Implemented!
Auxiliary rules
”("tt", ) = true
”(" ", ) = false
”("„", ) =
I
true if |= „
false if ”|= „
(„ propositional)
”("Ï1 · Ï2", ) = ”("Ï1", ) · ”("Ï2", )
”("Ï1 ‚ Ï2", ) = ”("Ï1", ) ‚ ”("Ï2", )
”("È„ÍÏ", ) =
Y
_]
_[
"Ï" if last ”œ and |= „ („ propositional)
”("Ï", ‘) if last œ and |= „
false if ”|= „
”("ÈÂ?ÍÏ", ) = ”("Â", ) · ”("Ï", )
”("Èfl1 + fl2ÍÏ", ) = ”("Èfl1ÍÏ", ) ‚ ”("Èfl2ÍÏ", )
”("Èfl1; fl2ÍÏ", ) = ”("Èfl1ÍÈfl2ÍÏ", )
”("Èflú
ÍÏ", ) =
I
”("Ï", ) if fl is test-only
”("Ï", ) ‚ ”("ÈflÍÈflúÍÏ", ) o/w
”("[„]Ï", ) =
Y
_]
_[
"Ï" if last ”œ and |= „ („ propositional)
”("Ï", ‘) if last œ and |= „ („ propositional)
true if ”|= „
”("[Â?]Ï", ) = ”("nnf (¬Â)", ) ‚ ”("Ï", )
”("[fl1 + fl2]Ï", ) = ”("[fl1]Ï", ) · ”("[fl2]Ï", )
”("[fl1; fl2]Ï", ) = ”("[fl1][fl2]Ï", )
”("[flú
]Ï", ) =
I
”("Ï", ) if fl is test-only
”("Ï", ) · ”("[fl][flú]Ï", ) o/w
Marco Montali (unibz) Monitoring Business Metaconstraints BPM 2014 22 / 26
71. Black Magic with LDLf
71
Runtime ldlf Monitors
Check partial trace fi = e1, . . . , en against formula Ï.
From ad-hoc techniques . . .
e1 . . . en |=
C
Ï
D
RV =
Y
___]
___[
temp_true
temp_false
true
false
. . . To standard techniques
e1 . . . en |=
Y
______]
______[
Ïtemp_true
Ïtemp_false
Ïtrue
Ïfalse
Marco Montali (unibz) Monitoring Business Metaconstraints BPM 2014 14 / 26
75. Coloring local automata
Coloring simply amounts to reachability checks!
• State permanently satisfied: it is final and
cannot reach a non-final state
• State temporarily satisfied: it is final but can
reach a non-final state
• State temporarily violated: it is non-final but can
reach a final state
• State permanently violated: it is non-final and
cannot reach a final state
75
76. Local Colored Automata
• For each constraint, we take its LTLf formula, and
compute the corresponding DFA
• This DFA accepts all and only the execution traces
that lead to satisfy (pemanently or temporarily) the
constraint
76
77. Local Automata: Example
moored
under way
using engine
under way
sailing
constrained by
her draught
0
s
c
not {c,s}
true1
0 true
00 1
m
e
not m not e
s
e
not s
true00
not {s,e}
1
2
3
e
s
not e
1
2
77
78. Global Automaton
What about hidden dependencies?
• We have to consider the interplay between constraints
• To do that: compute the “global automaton” for the
entire model. Either:
• Take the “conjunction formula” of all constraints and
get the DFA
• Compute the intersection of the local DFAs
78
79. Global Colored Automaton
By carefully intersecting local DFAs: we get a
global DFA that retains all “local colors”.
This is… an execution engine!
79
80. Implemented in ProM!
Monitoring
The same approach can be used for monitoring
• With LDLf, we can predicate about the truth value of
constraints
• Direct support for
meta-constraints
• Compensation constraints
• Contrary-to-duty constraints
• Dynamic activation/
disablement of constraints
80
84. Basic Idea of Existing Algorithms
• Apply heuristics to guess a constraint
• Check the support of the constraint
• Check the interestingness factor of the constraint
• Combine these two metrics to decide whether to
keep the constraint or not
• Iterate and prune
84
85. Problems
• Correctness of the overall declarative model (for
constraints with <100% support)
• Minimality of the overall declarative model
(redundant constraints)
• How to determine whether a constraint is
interesting or not
• All these questions: successfully tackled with logics
and automata!
85
87. Why is a trace interesting for
a constraint?
• Because it “activates” the constraint, “changing”
something
• Semantically:
• It flips the RV-LTL state of the constraint
• It changes the set of allowed transitions
• Non-vacuous satisfaction =
satisfaction + interestingness
87
91. Conclusion
• BPM struggles to balance flexibility and control
• Constraint-based approaches and temporal logics over finite
traces offer a solution
• The automata-theoretic approach leads to a “correct by
design” computation mechanism to assist humans during
the entire process lifecycle
• A lot of open challenges!
• Measuring interestingness (“graded within a trace”)
• Mix declarative and imperative approaches
• Data!
91
92. And the Story Continues…
Object-Centric Declare
(joint work with Wil van der Aalst and Guangming Li)
92
OrderItem Package
Pick
Item
Pay
Order
Get
Package
0..1 ** 0..1
93. Acknowledgments
• Wil van der Aalst
• Maja Pesic
• Federico Chesani
• Paola Mello
• Fabrizio Maggi
93
• Michael Westergaard
• Giuseppe De Giacomo
• Riccardo De Masellis
• Claudio di Ciccio
• Jan Mendling
94. Some References
Declare and its formalizations
• M. Pesic and W. van der Aalst, A Declarative Approach for Flexible Business
Processes Management, in BPM Workshops. Vol. 4103 of LNCS, pp. 169-180.
Springer, 2007.
• M. Montali, M. Pesic, W. M. P. van der Aalst, F. Chesani, P. Mello, and S. Storari,
Declarative specification and verification of service choreographies, ACM
Trans. Web, vol. 4, pp. 3:1–3:62, 2010.
• M. Montali. Specification and Verification of Declarative Open Interaction
Models: a Logic- Based Approach, vol. 56 of LNBIP. Springer, 2010.
• M. Westergaard, Better Algorithms for Analyzing and Enacting Declarative
Workflow Languages Using LTL, in BPM, vol. 6896 of LNCS, pp. 83-98. Springer,
2010.
• Giuseppe De Giacomo, Riccardo De Masellis, Marco Montali,
Reasoning on LTL on Finite Traces: Insensitivity to Infiniteness, in AAAI, pp.
1027-1033. AAAI Press, 2014.
94
95. Some References
Declare Execution Environment
• M. Pesic, H. Schonenberg, and W. M. P. van der Aalst, DECLARE:
Full Support for Loosely-Structured Processes, in EDOC, pp.
287–300. IEEE Computer Society, 2007.
• M. Pesic, M. Schonenberg, N. Sidorova, and W. van der Aalst,
Constraint-Based Workflow Models: Change Made Easy, in
CoopIS, vol. 4803 of LNCS, pp. 77-94. Springer, 2007.
• M. Pesic, H. Schonenberg, and W. Aalst, The Declare Service, in
Modern Business Process Automation, Springer, 2010, pp.
327-343.
• M. Westergaard, F. M. Maggi, Declare: A Tool Suite for
Declarative Workflow Modeling and Enactment, BPM (Demos)
2011.
95
96. Some References
Monitoring Declare constraints
• F. M. Maggi, M. Montali, M. Westergaard, and W. M. P. van der Aalst,
Monitoring Business Constraints with Linear Temporal Logic: An
Approach Based on Colored Automata, in BPM, volume 6896 of LNCS,
pp. 132-147. Springer, 2011.
• F. M. Maggi, M. Westergaard, M. Montali, W. M. P. van der Aalst,
Runtime Verification of LTL-Based Declarative Process Models.:
Proceedings of RV, volume 7186 of LNCS, pp. 131-146. Springer, 2011.
• M. Montali, F. M. Maggi, F. Chesani, P. Mello, W. M. P. van der Aalst,
Monitoring business constraints with the event calculus. ACM Trans.
on Intelligent Systems and Technology 5(1): 17, 2013.
• G. De Giacomo, R. De Masellis, M. Grasso, F. M. Maggi, M. Montali,
Monitoring Business Metaconstraints Based on LTL and LDL for
Finite Traces, in BPM, volume 8659 of LNCS, pp. 1-17. Springer, 2014.
96
97. Some References
Discovering Declare constraints
• F. Chesani, E. Lamma, P. Mello, M. Montali, F. Riguzzi, S. Storari, Exploiting Inductive Logic Programming
Techniques for Declarative Process Mining. Trans. Petri Nets and Other Models of Concurrency 2:
278-295, 2009.
• F. Maria Maggi, A. J. Mooij, W. M. P. van der Aalst, User-guided discovery of declarative process models.
In CIDM, pp. 192-199. IEEE Press, 2011.
• F. M. Maggi, R. P. J. Chandra Bose, W. M. P. van der Aalst, Efficient Discovery of Understandable
Declarative Process Models from Event Logs. In CAiSE, volume 7908 of LNCS, pp. 270-285. Springer,
2012.
• F. M. Maggi, M. Dumas, L. García-Bañuelos, M. Montali, Discovering Data-Aware Declarative Process
Models from Event Logs. In BPM, volume 8094 of LNCS, pp. 81-96. Springer, 2013.
• C. Di Ciccio, M. Mecella, On the Discovery of Declarative Control Flows for Artful Processes. ACM
Trans. Management Inf. Syst. 5(4): 24:1-24:37, 2015.
• C. Di Ciccio, F. M. Maggi, M. Montali, J. Mendling, Ensuring Model Consistency in Declarative Process
Discovery. In BPM, volume 9253 of LNCS, pp. 144-159. Springer, 2015.
• C. Di Ciccio, F. M. Maggi, M. Montali, J. Mendling, Semantical Vacuity Detection in Declarative Process
Mining. In BPM, volume 9850 of LNCS, pp. 158-175. Springer, 2016.
• Claudio Di Ciccio, Fabrizio Maria Maggi, Marco Montali, Jan Mendling:
Resolving inconsistencies and redundancies in declarative process models. Inf. Syst. 64: 425-446,
2017.
97