Declarative Specification of Processes: Discovery and Reasoning

Declarative
Specification of
Processes: Discovery
and Reasoning
Claudio Di Ciccio

Claudio Di Ciccio /klˈaːudio di ˈt͡ ʃiːtt͡ ʃo/
Assistant professor
Ph.D. in Computer Science and Engineering
Main research interests:
process mining,
declarative processes,
cryptoeconomics,
service-oriented architectures
27/05/2019©DiCiccio-DeclarativeSpecificationofProcesses
2

My experience so far
Latina, Italy (B.Sc) Rome, Italy (M.Sc, Ph.D) Vienna, Austria (Post-doc)
3

Declarative
Specification of
Business Processes
Preliminaries
4

Half empty or half full?
http://aeon.co/ideas/which-is-more-fundamental-processes-or-things
5

Processes are into dynamics
Thanks Dr. Mieke Jans for offering her hand
6

Processes and division of labour
To take an example, the trade of a pin-maker: But in the way in which this business is now carried on, it is
divided into a number of branches:
• One man draws out the wire;
• another straights it;
• a third cuts it;
• a fourth points it;
• a fifth grinds it at the top for receiving the head;
• to make the head requires three operations;
 to put it on is a peculiar business;
 to whiten the pins is another;
 to put them into the paper; …
[…] making a pin is, in this manner, divided into about 18 distinct operations.
[1] Smith 1776 [2] Dumas, La Rosa, Mendling, Reijers 2018
Draw out
wire
Straight wire Cut wire Grind wire
Put head on
pin
Put pin
in paper
Whiten pin
Point wire
Make head
7

Division of labour
Icons © freepik.com
Draw out
wire
Put head on
pin
Put pin
in paper
Whiten pin
Point wire
Make head
8

Pretty inhumane
Chaplin 1936
9

Division of labour
Draw out
wire
Put head on
pin
Put pin
in paper
Whiten pin
Point wire
Make head
Icons © freepik.com
10

Different perspectives
Factorial
Procedural / imperative
C
long factorial(int n) {
int c;
long result = 1;
for (c = 1; c <= n; c++) {
result = result * c;
}
return result;
}
Functional / declarative
LISP
(defun factorial (n)
(if (= n 0)
1
(* n (factorial (- n 1))) ) )
Local perspective Global perspective
! 𝑛 =
1 if 𝑛 = 0
𝑛 × 𝑛 − 1 if 𝑛 > 0
11

Declarative process specification
• “Open model”
• Specify constraints for permitted
behaviour
• Every execution that complies with
them is acceptable
12

Everyday examples of declarative specifications
13

The Declarative Approach
“When you have eliminated all that is impossible,
whatever remains must be the truth,
no matter how improbable.”
[Sherlock Holmes]
14

A fragment of declarative process
in DECLARE
Van der Aalst and Pesic 2006
Submit abstract Write new paper
Submit paper
Send confirmation
email
Submit paper Review paper
Review paper Accept paper
Reject paper Submit paper
Accept paper Reject paper
= activation task
Responded existence(Submit abstract, Write new paper)
Response(Submit paper, Send confirmation email)
Succession(Submit paper, Review paper)
Precedence(Review paper, Accept paper)
Not succession(Reject paper, Submit paper)
Not co-existence(Accept paper, Reject paper)
Template Tasks
• If an abstract is submitted, a new paper had been
written or will be written
• After the paper submission, a confirmation email is
sent
• After the paper submission, the paper will be
reviewed;
there can be no review without a preceding
submission
• A paper can be accepted only after it has been
reviewed
• After the rejection, no further submission follows
• Paper cannot be both accepted and rejected
15

A fragment of declarative process map
in DECLARE
Submit abstract
Write new paper Submit paper
Send confirmation
email
Reject paper
16

DECLARE templates:
Existence constraints
Init(a)
Every process instance starts with activity a
 bcaad  adcac  dabce  aeb  aabde
End(a)
Every process instance ends with activity a
 abcde  cedea  aacbaa  ababac  aabde
Participation(a)
Activity a occurs at least once
 bbcd  bedcca  bcaeda  dbdeb  aabde
AtMostOne(a)
Activity a occurs at most once
 baea  beed  acccd  edbcd  aabde
a
Init
a
End
a
1..*
a
0..1
17

DECLARE templates:
Relation constraints I
RespondedExistence(a, b)
If a occurs, b has to occur at some point, no matter when
 bcdd  bdca  addcd  adaab  bdaacb
Response(a, b)
If a occurs, b has to occur after a
 bdaac  adbbc  cddce  aadccba  bdaacb
AlternateResponse(a, b)
If a occurs, b has to occur after a, with no a in-between
 aabbd  aedbab  beedcd  abababa  bdaacb
ChainResponse(a, b)
b has to occur immediately after a
 cbaab  dabbab  aba  bdbababb  bdaacb
Activation Target
ba
ba
ba
ba
strictness
18

DECLARE templates:
Relation constraints II
RespondedExistence(b, a)
If b occurs, a has to occur at some point, no matter when
 acdd  bdca  bddcd  adabb  acbeead
Precedence(a, b)
If b occurs, then a has to occur before b
 cbdac  adbbc  cddcea  aadccba  acbeead
AlternatePrecedence(a, b)
Each time b occurs, it is preceded by a, with no b in-between
 aabd  adbbab  beead  abababa  acbeead
ChainPrecedence(a, b)
If b occurs, then a has to occur immediately beforehand
 ccbab  abbab  aba  abaab  acbeead
ba
ba
ba
ba
ActivationTarget
strictness
19

DECLARE templates:
Mutual relation constraints
CoExistence(a, b)
RespondedExistence(a, b) and RespondedExistence(b, a) hold
 bcdd  cddc  addcd  adaab  dbdaacb
Succession(a, b)
Response(a, b) and Precedence(b, a) hold
 bdaac  adbbc  cddce  aadccba  dbdaacb
AlternateSuccession(a, b)
AlternateResponse(a, b) and AlternatePrecedence(b, a) hold
 aabbd  addbab  beedcd  ababab  dbdaacb
ChainSuccession(a, b)
ChainResponse(a, b) and ChainPrecedence(b, a) hold
 ccbab  dabbab  dabab  babab  dbdaacb
ba
ba
ba
ba
ActivationTarget
Activation Target
strictness
20

DECLARE templates:
Negative relation constraints
NotCoExistence(a, b)
a and b cannot co-occur
 bdaac  adeec  cddce  cbdcb  aadccba
NotSuccession(a, b)
b cannot occur after a and a cannot occur before b
 aabad  adccda  bcdaed  dbabc  aadccba
NotChainSuccession(a, b)
b cannot occur immediately after a
 cbbab  adadbb  aba  aaadbbb  aadccba
ba
ba
ba
strictness
ActivationTarget
Activation Target
21

Constraints subsumption (strictness) hierarchy
22

Warning
The following slides contain sentences with symbols from Greek, math,
and other alphabets out of the sick fantasy of the inventors, which could
hurt, disturb, or offend the sensitivity of the audience.
We apologise in advance for the inconvenience.
F


23

Semantics of DECLARE: LTL and LTLf
• Linear Temporal Logic (LTL) initially was a specification language for the
execution of (endless) concurrent programs (Pnueli, 1977)
 Syntax (let A be a propositional symbol):
 Interpretation over infinite traces,
i.e., an infinite sequence of consecutive instants of time
• LTLf formulae are meant to be interpreted over finite traces
“Until”
“Eventually”“Always”
“Next”
24

About the expressive power
[1] Fitch, Friederici 2012 [2] Dwyer et al. 1999
25

Linear Temporal Logics over Finite Traces
LTL𝑓
RespondedExistence(a,b) Response(a,c)
Eventually Globally
Templates
Constraints
26

Linear Temporal Logics over Finite Traces
LTL𝑓 and Regular Expressions
[1] Diekert, Gastin 2008 [2] De Giacomo et al. 2014
Eventually Globally
Templates
Constraints
[â]*((a.*b.*)|(b.*a.*))*[â]* [â]*(a.*c)*[â]*
𝐿𝑇𝐿 𝑓 ≡ 3𝐹𝑂𝐿 𝑓 ⊂ 𝑅𝐸 ≡ 𝑀𝑆𝑂𝐿 𝑓 ⊆ 𝑆𝑂𝐿 𝑓
27

Every DECLARE constraint
can be abstracted as a Finite State Automaton
Accepting state
Any task but ‘a’
or ‘b’
Any task but ‘a’
Alphabet
State
FSA: (Deterministic) Finite State Automaton
Task ‘a’
Init
28

A DECLARE constraint
can be abstracted as an FSA
RespondedExistence(a,b) Response(a,c)&
×
29

Every DECLARE constraint
can be abstracted as an FSA
RespondedExistence(a,b) Response(a,c)&
30

A fragment of declarative process specification
in DECLARE
RespondedExistence(Submit abstract, Write new paper)
Response(Submit paper, Send confirmation email)
Succession(Submit paper, Review paper)
Precedence(Review paper, Accept paper)
NotSuccession(Reject paper, Submit paper)
NotCoExistence(Accept paper, Reject paper)
31

A fragment of declarative process specification
in DECLARE
Submit abstract
Write new paper Submit paper
Send confirmation
email
Reject paper
32

Under the carpet
33

Under the carpet
RespondedExistence
(Submit abstract, Write new paper)
Response
(Submit paper, Send confirmation email)
Succession
(Submit paper, Review paper)
Precedence
(Review paper, Accept paper)
NotSuccession
(Reject paper, Submit paper)
NotCoExistence
(Accept paper, Reject paper)
⊨
34

Under the carpet
RespondedExistence
Response
Succession
Precedence
NotSuccession
NotCoExistence
⊨
Process model Process specification
35

Under the carpet
RespondedExistence
Response
Succession
Precedence
NotSuccession
NotCoExistence
⊨
Process model Process specification
36

The message
Declarative specifications as a means to specify norms & rules
Imperative models as a means to organize operations
in compliance with them
37

Discovery of
Declarative Process
Specifications
Extracting temporal rules from data
38

Control-flow discovery
Objective:
Extracting the constraints that best
define the allowed behaviour of the
process behind the event log
Event log
39

Knowledge-intensive Processes
40

Mining flexible processes
41

Mining declarative process specifications:
ingredients
“Submit draft”,
“Write deliverable”,
“Organise agenda”,
…
a,
b,
c,
…
Activities Process alphabet
Event log Declarative constraint templates
42

Mining declarative process specifications
RespondedExistence(a,b) ?
• Support:
fraction of cases fulfilling the constraint
• Confidence:
support scaled by fraction of traces in which the
activation occurs
• Interest factor:
confidence scaled by fraction of traces in which the
target occurs
Support Conf. I.F.
RespondedExistence(a,c) ?
…
Response(a,b) ?
…
Response(a,c) ?
43

Support Conf. I.F.
…
Response(a,b) ?
Response(a,c) ?
…
44

Support Conf. I.F.
…
Response(a,b) ?
Response(a,c) ?
…
45

Support Conf. I.F.
…
Response(a,b) ?
Response(a,c) ?
…
46

Support Conf. I.F.
…
Response(a,b) 
Response(a,c) ?
…
47

Support Conf. I.F.
RespondedExistence(a,b) 
RespondedExistence(a,c) 
…
Response(a,b) 
Response(a,c) 
…
48

Is it really that easy?
This is a rhetoric question, you know.
49

Reasoning on
Declarative Process
Specifications
Dealing with temporal rules discovered from data
50

While mining a real-life event log…
Support threshold: 0.85
Confidence threshold: 0.25
Interest factor threshold: 0.25
51

Objective
52

While mining a real-life event log…
53

Challenging the cross product
×
54

Time to challenge the X
Loading…
55

The result
56

The problems
1) inconsistency
• When support threshold is lower than 100%,
constraints can be valid through most of the log, though being in conflict
• Example: an event log consists of two traces defined over three tasks (a, b, c):
1.<a, b, a, b, a, b, c>
2.<a, b, a, b, a, c>
• Support threshold: 0.7
• a is always the first
 Init(a)
• c is always the last
 End(c)
• In 6 cases over 8 (75%), a and c do not directly follow each other
 NotChainSuccession(a,c)
• In 5 cases over 7 (71.143%), b and c do not directly follow each other
 NotChainSuccession(b,c)
57

The problems
1) inconsistency
• When support threshold is lower than 100%,
constraints can be valid through most of the log, though being in conflict
• Example: an event log consists of two traces defined over three tasks (a, b, c):
1.<a, b, a, b, a, b, c>
2.<a, b, a, b, a, c>
• Support threshold: 0.7
 Init(a)
 End(c)
• In 6 cases over 8 (75%), a and c do not directly follow each other
 NotChainSuccession(a,c)
• In 5 cases over 7 (71.143%), a and b do not directly follow each other
 NotChainSuccession(b,c)
• Question: what can be done right before c?
 inconsistency!
58

The problems
1) inconsistency
• Support threshold ≤ 100%  constraints valid through most of the log
though (possibly) in conflict
• How to trust a discovery algorithm that can return inconsistent models?
59

The problems
2) redundancy
• Many constraints may be fulfilled 100% of times yet not add a bit of information to other
already discovered ones
• Example: an event log consists of two traces:
1.<a, b, a, b, a, b, c>
2.<a, b, a, b, a, c>
 Init(a)
 End(c)
• Before c, a precedes
 Precedence(a,c)
• Before b, a precedes
 Precedence(a,b)
• After a, c eventually follows
 Response(a,c)
• After b, c eventually follows
 Response(b,c)
60

The problems
2) redundancy
1.<a, b, a, b, a, b, c>
2.<a, b, a, b, a, c>
 Init(a)
 End(c)
 Precedence(a,c)
 Precedence(a,b)
 Response(a,c)
 Response(b,c)
Of course! a is always the first
61

The problems
2) redundancy
1.<a, b, a, b, a, b, c>
2.<a, b, a, b, a, c>
 Init(a)
 End(c)
 Precedence(a,c)
 Precedence(a,b)
 Response(a,c)
 Response(b,c)
Of course! a is always the first
Of course! c is always the last
• Question: can't we avoid stating the obvious?
 redundancy!
62

The problems
2) redundancy
• Many constraints may be fulfilled 100% of times
yet not add a bit of information to other already discovered ones
• How to reduce the number of unnecessary returned constraints?
63

The solution
Automata-product monoid
Algebraic structure with composition
operator (×) holding the properties of
• commutativity
• associativity
and bearing
• identity element
• and absorbing element
64

The solution
Automata-product monoid
65

Rules of the game
• Intersect the product automaton with
the newly visited constraints, one at a
time

Init(a) Participation(b)
=
Product automaton
Init(a)
Participation(b)
66

Rules of the game
• Intersect the product automaton with
the newly visited constraints, one at a
time
ChainPrecedence(a,b)
Product automaton
Init(a)
Participation(b)
67

Exploiting formal properties
• We take advantage of
1. associativity
 allows for "storage" of results
Product automaton

Old product automaton
=
68

1. associativity
2. commutativity
 allows for priority sorting of constraints
Product automaton
69

1. associativity
2. commutativity
 allows for priority sorting of constraints
Product automaton
70

Playing the game
• Newly visited constraints add
information to the knowledge on the
process model if they reduce the
number of possible traces (accepted
strings)
Product automaton
71

Playing the game
strings)
Product automaton
72

Playing the game
strings)
Product automaton
73

Inconsistency!
strings)
• Conflict:
Product automaton
74

Inconsistency!
strings)
• Conflict:
 The product automaton becomes
(accepts only the empty language)
Response(a,b)
Response(b,a)
75

Inconsistency!
strings)
• Conflict:
 The product automaton becomes
(accepts only the empty language)
76

Inconsistency!
strings)
• Conflict:
 Remove the constraint, in case
77

Redundancy!
strings)
• Redundancy:
78

Redundancy!
strings)
• Redundancy:
 The new product automaton accepts the
same strings as before
(language inclusion)
Response(a,c)
End(c)
79

Redundancy!
strings)
• Redundancy:
 The new product automaton accepts the
same strings as before
(language inclusion)
80

Redundancy!
strings)
• Redundancy:
 Remove the constraint, in case
81

Objectives
• Remove inconsistencies
 Through empty language detection
• Minimise redundancies
 Through language inclusion detection
• Analyse each constraint once
 Use sorting for priorities
82

Recap
83

84

Which were the conflicting constraints in the log?
1. NotSuccession(send meeting, organize agenda)
2. NotChainSuccession(send draft, send deliverable)
3. Succession(send draft, submit report)
85

86

Redundancy reduction and performance
87

MINERful
https://github.com/cdc08x/MINERful
Command-line tool (stand-alone) As a Java library (here, in ProM)
ProM screenshot courtesy of Mitchel Schouten
88

Current and Future
Work on Declarative
Business Processes
One-slide pitches on ongoing projects + research outlook
89

Reactive constraints
and the Janus approach
“Send notification email” triggers that ( )
sometime before “submit paper” must occur and
sometime after “review paper” must occur
Slide courtesy of Alessio Cecconi. Cecconi et al. 2018
Activation event
e
Automaton of
𝐿𝑇𝐿𝑝 𝑓 past formula
Automaton of
𝐿𝑇𝐿𝑝 𝑓 future formula
!s
s
!r
r
e s r
90

Finding the needle in the haystack
with semantic technologies
Di Ciccio et al. 2019
91

SQL for Data-Aware
Declarative Process Discovery
Return all constraints of the Response(x,y) kind such that x and y occur in the same location,
and indicate the location of x.
92

Extraction of declarative process specifications from
natural-language text
van der Aa et al. 2019
93

Testing our theory
Correspondence theorems
• Conjectures (theorems to be proven)
are expressed as co-implications
between relations stemming from
different languages
TPTP excerpt (example)
![A,B]: (
( Label(A) & Label(B) )
=>
(
( aaecausal(A,B) & ~canconflict(A,B) )
<=>
( response(A,B) )
)
)
4C rel. 4C rel.
Automated proof (example) Proof graph
DECLARE
𝐿𝑇𝐿 𝑓 ≡ 3𝐹𝑂𝐿 𝑓 ⊂ 𝑅𝐸 ≡ 𝑀𝑆𝑂𝐿 𝑓 ⊆ 𝑆𝑂𝐿 𝑓
𝐿𝑇𝐿 ≡ 3𝐹𝑂𝐿 ⊂ 𝑀𝑆𝑂𝐿 ⊆ 𝑆𝑂𝐿
94

Open questions
A short list
• General measures for mined declarative process specifications
• Declarative process constraints to control machine learning
• Vector space based on orthogonal declarative template
primitives
• …
95

Transaction
• Transfer of (crypto)assets (Ether, Bitcoin, Litecoin, EOS, …)
from account A to account B
Externally Owned
Account (EOA)
Externally Owned
Account (EOA)
Digital signature
96

Ledger
• Ordered collection of transactions
• The order matters!
97

Block
• Blocks group and collate transactions
98

Blockchain
• Blocks refer back to direct predecessors
99

The Blockchain remembers
100

About decentralisation
Centralisation Decentralisation
Distributing the ledger makes for permanence
BUT
entails no notion of unique distributed clock
101

Distributed nature
102

Distributed nature
103

Distributed nature
104

A programmable distributed environment
Gas price (execution costs)
Input (and output) encoded data. Yes, hashing strikes back.
Smart Contract
Account
105

Distributed nature
106

The polygraph machine
Where are Smart Contracts
executed?
First on the mining nodes.
Then, potentially, on every node!
Only absolutely needed
instructions should be put in code!
107

Executing inter-organisational processes on the
Blockchain
Weber, Xu, Riveret, Governatori, Ponomarev, Mendling 2016
108

From ledgers to event logs
109

From event logs to behavioural specifications
110

Upcoming venues
7th Int. Workshop on DEClarative, DECision and Hybrid approaches to
processes (DEC2H 2019, https://ai.wu.ac.at/dec2h2019/)
Sep. 2, 2019
1st Int. Blockchain Forum (https://tinyurl.com/blockchain-forum-bpm2019)
Sep 3-4, 2019
Submission deadline: 31 May 2019 (extended!)
co-located with the 17th Int. Conference on Business Process Management
(BPM 2019, bpm2019.ai.wu.ac.at)
Vienna, Sep. 1-6, 2019
111

Declarative
Specification of
Processes
Di Ciccio, C. & Mecella, M. On the Discovery of Declarative Control Flows for Artful Processes. ACM
Trans. Manage. Inf. Syst., 2015, 5, 24:1-24:37, doi: 10.1145/2629447
Di Ciccio, C.; Maggi, F. M.; Montali, M. & Mendling, J. Resolving inconsistencies and redundancies in
declarative process models. Information Systems, 2017, 64, 425-446, doi: 10.1016/j.is.2016.09.005
Di Ciccio, C.; Maggi, F. M.; Montali, M. & Mendling, J. On the Relevance of a Business Constraint to an
Event Log. Information Systems, 2018, 78, 144-161, doi: 10.1016/j.is.2018.01.011

Declarative Specification of Processes: Discovery and Reasoning

Recommended

Recommended

More Related Content

Similar to Declarative Specification of Processes: Discovery and Reasoning

Similar to Declarative Specification of Processes: Discovery and Reasoning (19)

More from Claudio Di Ciccio

More from Claudio Di Ciccio (10)

Recently uploaded

Recently uploaded (20)

Declarative Specification of Processes: Discovery and Reasoning

Editor's Notes