montali: declarative, constraint-based business process management - seville 2016
TRANSCRIPT
Declarative, Constraint-Based BPM
Marco Montali Free University of Bozen-Bolzano
ack to Maja Pesic, Wil van der Aalst, Fabrizio Maggi, Giuseppe De Giacomo, Riccardo de Masellis
1
Disclaimer for this Talk
Process = Control-flow
(but the story is much more interesting than that…)
2
BPM!3
BPM?4
Types of ProcessesNot all business processes are the same
• Even within one organization, business processes can be very different in terms of their essential properties.
• Business processes can be characterized through three dimensions: • complexity • predictability • repetitiveness
5
Complexity
Degree of difficulty in collaboration, coordination, and decision making
• Low complexity: exchanging personal email messages and handling travel requests
• High complexity: handling medical treatments
6
Predictability
How easy it is to determine in advance the way the process will be executed.
• Low predictability: exchanging personal email messages.
• High predictability: handling travel requests.
7
RepetitivenessFrequency of process execution. • A business process that is executed once per year
has a lower degree of repetitiveness than a process executed twice a day.
• Low repetitiveness: disaster handling.
• High repetitiveness: exchanging personal email messages.
8
Classifying Processes
Prepare coffee
Produce shoes
Register birth
Design shoes
Disaster recovery
Celebrate opening of A.Y.Win slot machine
9
Classifying ProcessesPrepare coffee Produce shoesRegister birth
Design shoes
Disaster recovery
Win slot machine
10
Celebrate opening of A.Y.
BPM SystemsBPM systems support collaboration, coordination and decision making in business processes.
• Groupware systems support human collaboration and co-decision.
• Workflow management systems explicitly control ordering, coordination and execution of activities with little human intervention.
11
BPMS and Decision Making
12
• Ordering and coordination of activities not automated.
• Users control the ordering and coordination of activities “on the fly” while executing the business process.
• Humans merely influence the execution of business processes by entering necessary data.
BPMS and Types of Processes
13
Environment!
14
Influence of the EnvironmentThe degree of turbulence of the environment influences the predictability of business processes and the nature of decision making.
15
Influence of the EnvironmentThe degree of turbulence of the environment influences the predictability of business processes and the nature of decision making.
‘optimal’
16
Combining Social and Technical Aspects
• Organizations can significantly benefit from using the best that both humans and technology have to offer.
• Instead of being replaceable, humans and machines should complement each other.
17
Combining Social and Technical Aspects
18
Flexibility vs SupportFlexibility: degree to which users can make local decisions about how to execute processes. Support: degree to which a system makes centralized decisions about how to execute processes.
Universe of Traces
Compliant
Traces
Compliance
Flexibility19
Trade-off?
20
The Issue of Flexibility
21
Ultimate Goal: Balance Flexibility and Control
22
Trends in BPM
modeling
• Highly-variable BPs
• Metaphor: rules/constraints
Dec t ilara ev
Imperative modeling • Traditional repetitive BPs
• Metaphor: flow-chart
23
Imperative Modeling24
Organizational Boundaries25
Imperative Modeling
Focus: how things must be done
• Explicit description of the process control-flow
Closed modeling
• All that is not explicitly modeled is forbidden • Exceptions/uncommon behaviors have to be
explicitly enumerated at design time
26
BPMN
Receiveorder
Check availability
Article available?
Ship articleFinancial
settlementyes
Procurement
no Paymentreceived
Inform customer
Late deliveryUndeliverable
Customerinformed
Inform customer
Articleremoved
Remove article from catalogue
27
BPMN
Receiveorder
Check availability
Article available?
Ship articleFinancial
settlementyes
Procurement
no Paymentreceived
Inform customer
Late deliveryUndeliverable
Customerinformed
Inform customer
Articleremoved
Remove article from catalogue
Input Output
28
BPMN
Receiveorder
Check availability
Article available?
Ship articleFinancial
settlementyes
Procurement
no Paymentreceived
Inform customer
Late deliveryUndeliverable
Customerinformed
Inform customer
Articleremoved
Remove article from catalogue
Input Output
29
Organizational Boundaries30
Example: Rigid Shopping
• Tasks: 𝚺 = {pick item, close order, pay}
• A customer starts the process by picking one or more items. She then decides to quit or close the order. In the latter case, she has to pay for the order.
31
Questions• Tasks: 𝚺 = {pick item, close order, pay}
• A customer starts the process by picking one or more items. She then decides to quit or close the order. In the latter case, she has to pay for the order.
• Which traces are accepted?
• <> (empty trace) • <i,i,i>
• <i,i,i,c,p>
• <i,i,i,c,p,p>
• <i,i,i,p,c>
• <i,c,p,i,i,c,p>32
Questions• Tasks: 𝚺 = {pick item, close order, pay}
• A customer starts the process by picking one or more items. She then decides to quit or close the order. In the latter case, she has to pay for the order.
• Which traces are accepted?
• <> (empty trace) • <i,i,i>
• <i,i,i,c,p>
• <i,i,i,c,p,p>
• <i,i,i,p,c>
• <i,c,p,i,i,c,p>33
Questions• Can you model this process in BPMN? How difficult
is it?
A customer starts the process by picking one or more items. She then decides to quit or close the order. In the latter case, she has to pay for the order.
34
Questions• Can you model this process in BPMN? How difficult
is it?
pick item
close order pay
quit
order paid
35
Example: Flexible Shopping
• Tasks: 𝚺 = {pick item, close order, pay}
• A customer may pick items, close several orders, and pay one or more orders at once.
• She may even close an empty order and pay for it, or pay multiple times (but this will result in a no-op)
• Business constraint: whenever you close an order, eventually you have to pay.
36
Questions• Tasks: 𝚺 = {pick item, close order, pay}
• Business constraint: whenever you close an order, eventually you have to pay.
• Which traces are accepted? • <> (empty trace) • <i,i,i>
• <i,i,i,c,p>
• <i,i,i,c,p,p>
• <i,i,i,p,c>
• <i,c,p,i,i,c,p>37
Questions• Tasks: 𝚺 = {pick item, close order, pay}
• Business constraint: whenever you close an order, eventually you have to pay.
• Which traces are accepted? • <> (empty trace) • <i,i,i>
• <i,i,i,c,p>
• <i,i,i,c,p,p>
• <i,i,i,p,c>
• <i,c,p,i,i,c,p>38
Questions• Can you model this process in BPMN? How difficult
is it?
You may pick items, close and pay an order.Whenever you close an order, eventually you have to pay.
39
Questions• Can you model this process in BPMN? How difficult
is it?
40
pick item
close order pay
quit
order paid
Questions• Can you model this process in BPMN? How difficult
is it?
41
pick item
close order pay
quit
order paid
simple, correct, but not general enough!
Questions• Can you model this process in BPMN? How difficult
is it?
42
pick item
close order pay
pick item
pay
Questions• Can you model this process in BPMN? How difficult
is it?
43
pick item
close order pay
pick item
pay
correct, general, but unreadable!
Choreography Example• An order can be finalized at mosto 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 reject 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.
44
What is your Favourite Italian Food?
45
Order-to-delivery
What is your Favourite Italian Food?
46
Order-to-delivery
What is your Favourite Italian Food?
47
Under
stan
din
gSpag
het
tiM
odel
sw
ith
Seq
uen
ceC
lust
erin
gfo
rP
roM
9
thos
eex
cept
ions
.Fig
ure
4de
pict
sth
ere
sult
ofa
first
atte
mpt
toan
alyz
eth
eap
plic
atio
nse
rver
logs
usin
gth
ehe
uris
tics
min
er[4
].
Exc
eptio
n(c
om
ple
te)
187
Est
abele
cim
ento
NotF
oundE
xceptio
n(c
om
ple
te)
187
0,9
91 1
52
GR
EJB
Pers
iste
ncy
Exc
eptio
n(c
om
ple
te)
179
0,9
09 1
59
PG
WS
Exc
eptio
n(c
om
ple
te)
168
0,8
89 1
2
ITP
TE
xtern
alS
erv
iceE
xceptio
n(c
om
ple
te)
183 0
,944
162
SIP
SC
NoR
eco
rdsF
oundE
xceptio
n(c
om
ple
te)
160
0,8 5
Pess
oaS
ingula
rNotF
oundE
xceptio
n(c
om
ple
te)
138
0,6
67 3
Busi
ness
Logic
Exc
eptio
n(c
om
ple
te)
183
0,7
5 4
SIC
CLE
xceptio
n(c
om
ple
te)
175
0,8
57 1
9
NaoE
xist
em
Regis
tosE
xceptio
n(c
om
ple
te)
143
0,8
33 6
RP
CB
usi
ness
Exc
eptio
n(c
om
ple
te)
38 0
,75
3
SA
FB
usi
ness
Exc
eptio
n(c
om
ple
te)
115
0,8
68
GR
EJB
Busi
ness
Exc
eptio
n(c
om
ple
te)
45
0,7
5 2
3
DE
SW
SE
xce
ptio
n(c
om
ple
te)
14
0,6
67 1
4
NullP
oin
terE
xceptio
n(c
om
ple
te)
104
0,8
91
Valid
atio
nE
xceptio
n(c
om
ple
te)
31
0,8
12
GIL
Busi
ness
Exc
eptio
n(c
om
ple
te)
14
0,5 6
GR
Serv
icesE
xceptio
n(c
om
ple
te)
7 0,6
67 3
CS
IBusi
ness
Exc
eptio
n(c
om
ple
te)
14
0,5 6
Conco
rrenci
aE
xceptio
n(c
om
ple
te)
5
0,5 2
CS
IPers
iste
ncy
Exc
eptio
n(c
om
ple
te)
3
0,5 2
0,8
57 3
4
ITP
TS
erv
erE
xceptio
n(c
om
ple
te)
21
0,6
67 1
5
CO
OP
Exc
eptio
n(c
om
ple
te)
4 0,5 2
RS
IValid
atio
nE
xceptio
n(c
om
ple
te)
25
0,6
67 1
8
Basi
cSys
tem
Exc
eptio
n(c
om
ple
te)
16
0,6
67 1
1
Pesq
uis
aA
mbig
uaE
xceptio
n(c
om
ple
te)
6
0,5 6
CP
FB
usi
ness
Exc
eptio
n(c
om
ple
te)
3
0,5 2
0,8
95
AD
OP
Exc
eptio
n(c
om
ple
te)
6
0,5 5
AF
Busi
ness
Exc
eptio
n(c
om
ple
te)
64
SIP
SC
Rem
ote
Busi
ness
Exc
eptio
n(c
om
ple
te)
51
0,8
33 1
3
Concu
rrentM
odifi
catio
nE
xceptio
n(c
om
ple
te)
5
0,5 1
CD
FB
usi
ness
Exc
eptio
n(c
om
ple
te)
6
0,6
67 2
Ass
inatu
raN
aoIn
cluid
aE
xceptio
n(c
om
ple
te)
1
0,5 1
SIC
CS
Exc
eptio
n(c
om
ple
te)
32
0,8
11
Ca
rta
oC
ida
da
oE
xce
ptio
n(c
om
ple
te)
64
0,8
33 3
8
SO
AP
Exc
eptio
n(c
om
ple
te)
22
0,6
67 1
4
TooM
anyR
ow
sExc
eptio
n(c
om
ple
te)
112
0,6
67 1
8
SIP
SC
Fata
lExc
eptio
n(c
om
ple
te)
20
0,6
67 9
Lim
iteT
em
pora
lExc
eptio
n(c
om
ple
te)
4
0,5 2
0,8
28
SV
IBusi
ness
Use
rExc
eptio
n(c
om
ple
te)
18
0,7
5 1
2
GR
Concu
rrency
Exc
eptio
n(c
om
ple
te)
8 0,5 2
Contr
ibuin
teR
egio
nalN
otF
oundE
xceptio
n(c
om
ple
te)
63
0,7
5 3
0
JDO
Fata
lUse
rExc
eptio
n(c
om
ple
te)
124
0,9
47 4
9
0,6
67 5
SQ
LE
xceptio
n(c
om
ple
te)
9
0,6
67 7
IOE
xceptio
n(c
om
ple
te)
27
0,7
5 2
2
Pess
oaC
ole
ctiv
aN
otF
oundE
xceptio
n(c
om
ple
te)
23
0,7
5 2
0
Serv
iceD
ele
gate
Rem
ote
Exc
eptio
n(c
om
ple
te)
3
0,5 2
0,5 5
PA
SE
xce
ptio
n(c
om
ple
te)
2
0,5 1
File
NotF
oundE
xceptio
n(c
om
ple
te)
31
0,7
5 1
3
QgenM
IPara
metr
izedB
usi
ness
Exc
eptio
n(c
om
ple
te)
1
0,5 1
AD
OP
Mess
ageE
xceptio
n(c
om
ple
te)
3 0,5 2
Layo
ffE
xceptio
n(c
om
ple
te)
1
0,5 1
0,7
5 8
CM
PE
xceptio
n(c
om
ple
te)
1
0,5 1
GR
EJB
Rem
ote
Serv
iceE
xceptio
n(c
om
ple
te)
34
0,7
5 4
RS
IPers
iste
nce
Exc
eptio
n(c
om
ple
te)
24
0,7
5 4
CS
IRem
ote
Exc
eptio
n(c
om
ple
te)
3
0,5 1
SIP
SC
Fata
lRem
ote
CallE
xceptio
n(c
om
ple
te)
3
0,5 1
SIP
SC
Data
base
Exc
eptio
n(c
om
ple
te)
1
0,5 1
Busi
ness
Exc
eptio
n(c
om
ple
te)
159
0,6
67 9
SV
IBusi
ness
Exc
eptio
n(c
om
ple
te)
1
0,5 1
Para
metr
izedB
usi
ness
Exc
eptio
n(c
om
ple
te)
2
0,5 2
GD
Serv
icesE
xceptio
n(c
om
ple
te)
4
0,5 3
Serv
erE
xceptio
n(c
om
ple
te)
132
0,7
5 1
6
PG
Exc
eptio
n(c
om
ple
te)
6
0,6
67 5
0,7
5 4
DE
SE
xceptio
n(c
om
ple
te)
135
0,6
67 1
3
0,6
67 2
0,7
5 9 SIP
SC
Exc
eptio
n(c
om
ple
te)
27
0,7
5 9
Report
Exc
eptio
n(c
om
ple
te)
5
0,6
67 2
SS
NS
erv
iceE
xceptio
n(c
om
ple
te)
1
0,5 1
AF
Exc
eptio
n(c
om
ple
te)
1
0,5 1
Inva
lidN
ISS
Exc
eptio
n(c
om
ple
te)
14 0
,75
4
0,7
5 1
4
GIL
Concu
rrency
Exc
eptio
n(c
om
ple
te)
1
0,5 1
RS
ISys
tem
Exc
eptio
n(c
om
ple
te)
28
0,7
5 7
0,6
67 5
0,6
67 1
0,7
5 2
0,6
67 5
0,8
33 5
0,6
67 5
0,6
67 4
0,7
5 1
2
0,9
81 5
3
AD
OP
Use
rChoic
eE
xceptio
n(c
om
ple
te)
1
0,5 1
0,6
67 5
RP
CE
xceptio
n(c
om
ple
te)
1
0,5 1
GR
EJB
Concu
rrency
Exc
eptio
n(c
om
ple
te)
15 0
,875
8
0,5 1
0,5 1
0,6
67 1
Mora
daP
ort
uguesa
NotF
oundE
xceptio
n(c
om
ple
te)
1
0,5 1
0,7
5 4
0,5 1
0,6
67 6
0,5 1
0,5 2
0,8
89 8
0,7
5 3
0,8 3
RS
IExc
eptio
n(c
om
ple
te)
1
0,5 1
0,5 1
0,5 1
0,6
67 4
0,6
67 3
0,5 1
0,5 2
0,7
5 5
0,5 1
0,5 1
0,5 2 0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,8 1
0,5 1
0,5 1
0,5 1
Fig
.4.
Spag
het
tim
odel
obta
ined
from
the
applica
tion
serv
erlo
gsusi
ng
the
heu
rist
ics
min
er.
Usi
ngth
ese
quen
cecl
uste
ring
plug
-inan
dit
spr
epro
cess
ing
capa
bilit
ies,
asw
ella
sthe
poss
ibili
tyof
visu
ally
adju
stin
gth
ecl
uste
rmod
elsa
ccor
ding
toce
rtai
nth
resh
olds
,itw
aspo
ssib
leto
iden
tify
seve
ralp
atte
rnsin
volv
ing
di�e
rent
type
sof
exce
ptio
ns.T
hese
patt
erns
wer
efo
und
afte
rse
vera
latt
empt
sof
tuni
ngw
ith
the
prep
roce
ssin
gpa
ram
eter
s,se
lect
ing
the
num
ber
ofcl
uste
rs(t
ypic
ally
from
3to
Healthcare
What is your Favourite Italian Food?
48
Under
stan
din
gSpag
het
tiM
odel
sw
ith
Seq
uen
ceC
lust
erin
gfo
rP
roM
9
thos
eex
cept
ions
.Fig
ure
4de
pict
sth
ere
sult
ofa
first
atte
mpt
toan
alyz
eth
eap
plic
atio
nse
rver
logs
usin
gth
ehe
uris
tics
min
er[4
].
Exc
eptio
n(c
om
ple
te)
187
Est
abele
cim
ento
NotF
oundE
xceptio
n(c
om
ple
te)
187
0,9
91 1
52
GR
EJB
Pers
iste
ncy
Exc
eptio
n(c
om
ple
te)
179
0,9
09 1
59
PG
WS
Exc
eptio
n(c
om
ple
te)
168
0,8
89 1
2
ITP
TE
xtern
alS
erv
iceE
xceptio
n(c
om
ple
te)
183 0
,944
162
SIP
SC
NoR
eco
rdsF
oundE
xceptio
n(c
om
ple
te)
160
0,8 5
Pess
oaS
ingula
rNotF
oundE
xceptio
n(c
om
ple
te)
138
0,6
67 3
Busi
ness
Logic
Exc
eptio
n(c
om
ple
te)
183
0,7
5 4
SIC
CLE
xceptio
n(c
om
ple
te)
175
0,8
57 1
9
NaoE
xist
em
Regis
tosE
xceptio
n(c
om
ple
te)
143
0,8
33 6
RP
CB
usi
ness
Exc
eptio
n(c
om
ple
te)
38 0
,75
3
SA
FB
usi
ness
Exc
eptio
n(c
om
ple
te)
115
0,8
68
GR
EJB
Busi
ness
Exc
eptio
n(c
om
ple
te)
45
0,7
5 2
3
DE
SW
SE
xce
ptio
n(c
om
ple
te)
14
0,6
67 1
4
NullP
oin
terE
xceptio
n(c
om
ple
te)
104
0,8
91
Valid
atio
nE
xceptio
n(c
om
ple
te)
31
0,8
12
GIL
Busi
ness
Exc
eptio
n(c
om
ple
te)
14
0,5 6
GR
Serv
icesE
xceptio
n(c
om
ple
te)
7 0,6
67 3
CS
IBusi
ness
Exc
eptio
n(c
om
ple
te)
14
0,5 6
Conco
rrenci
aE
xceptio
n(c
om
ple
te)
5
0,5 2
CS
IPers
iste
ncy
Exc
eptio
n(c
om
ple
te)
3
0,5 2
0,8
57 3
4
ITP
TS
erv
erE
xceptio
n(c
om
ple
te)
21
0,6
67 1
5
CO
OP
Exc
eptio
n(c
om
ple
te)
4 0,5 2
RS
IValid
atio
nE
xceptio
n(c
om
ple
te)
25
0,6
67 1
8
Basi
cSys
tem
Exc
eptio
n(c
om
ple
te)
16
0,6
67 1
1
Pesq
uis
aA
mbig
uaE
xceptio
n(c
om
ple
te)
6
0,5 6
CP
FB
usi
ness
Exc
eptio
n(c
om
ple
te)
3
0,5 2
0,8
95
AD
OP
Exc
eptio
n(c
om
ple
te)
6
0,5 5
AF
Busi
ness
Exc
eptio
n(c
om
ple
te)
64
SIP
SC
Rem
ote
Busi
ness
Exc
eptio
n(c
om
ple
te)
51
0,8
33 1
3
Concu
rrentM
odifi
catio
nE
xceptio
n(c
om
ple
te)
5
0,5 1
CD
FB
usi
ness
Exc
eptio
n(c
om
ple
te)
6
0,6
67 2
Ass
inatu
raN
aoIn
cluid
aE
xceptio
n(c
om
ple
te)
1
0,5 1
SIC
CS
Exc
eptio
n(c
om
ple
te)
32
0,8
11
Ca
rta
oC
ida
da
oE
xce
ptio
n(c
om
ple
te)
64
0,8
33 3
8
SO
AP
Exc
eptio
n(c
om
ple
te)
22
0,6
67 1
4
TooM
anyR
ow
sExc
eptio
n(c
om
ple
te)
112
0,6
67 1
8
SIP
SC
Fata
lExc
eptio
n(c
om
ple
te)
20
0,6
67 9
Lim
iteT
em
pora
lExc
eptio
n(c
om
ple
te)
4
0,5 2
0,8
28
SV
IBusi
ness
Use
rExc
eptio
n(c
om
ple
te)
18
0,7
5 1
2
GR
Concu
rrency
Exc
eptio
n(c
om
ple
te)
8 0,5 2
Contr
ibuin
teR
egio
nalN
otF
oundE
xceptio
n(c
om
ple
te)
63
0,7
5 3
0
JDO
Fata
lUse
rExc
eptio
n(c
om
ple
te)
124
0,9
47 4
9
0,6
67 5
SQ
LE
xceptio
n(c
om
ple
te)
9
0,6
67 7
IOE
xceptio
n(c
om
ple
te)
27
0,7
5 2
2
Pess
oaC
ole
ctiv
aN
otF
oundE
xceptio
n(c
om
ple
te)
23
0,7
5 2
0
Serv
iceD
ele
gate
Rem
ote
Exc
eptio
n(c
om
ple
te)
3
0,5 2
0,5 5
PA
SE
xce
ptio
n(c
om
ple
te)
2
0,5 1
File
NotF
oundE
xceptio
n(c
om
ple
te)
31
0,7
5 1
3
QgenM
IPara
metr
izedB
usi
ness
Exc
eptio
n(c
om
ple
te)
1
0,5 1
AD
OP
Mess
ageE
xceptio
n(c
om
ple
te)
3 0,5 2
Layo
ffE
xceptio
n(c
om
ple
te)
1
0,5 1
0,7
5 8
CM
PE
xceptio
n(c
om
ple
te)
1
0,5 1
GR
EJB
Rem
ote
Serv
iceE
xceptio
n(c
om
ple
te)
34
0,7
5 4
RS
IPers
iste
nce
Exc
eptio
n(c
om
ple
te)
24
0,7
5 4
CS
IRem
ote
Exc
eptio
n(c
om
ple
te)
3
0,5 1
SIP
SC
Fata
lRem
ote
CallE
xceptio
n(c
om
ple
te)
3
0,5 1
SIP
SC
Data
base
Exc
eptio
n(c
om
ple
te)
1
0,5 1
Busi
ness
Exc
eptio
n(c
om
ple
te)
159
0,6
67 9
SV
IBusi
ness
Exc
eptio
n(c
om
ple
te)
1
0,5 1
Para
metr
izedB
usi
ness
Exc
eptio
n(c
om
ple
te)
2
0,5 2
GD
Serv
icesE
xceptio
n(c
om
ple
te)
4
0,5 3
Serv
erE
xceptio
n(c
om
ple
te)
132
0,7
5 1
6
PG
Exc
eptio
n(c
om
ple
te)
6
0,6
67 5
0,7
5 4
DE
SE
xceptio
n(c
om
ple
te)
135
0,6
67 1
3
0,6
67 2
0,7
5 9 SIP
SC
Exc
eptio
n(c
om
ple
te)
27
0,7
5 9
Report
Exc
eptio
n(c
om
ple
te)
5
0,6
67 2
SS
NS
erv
iceE
xceptio
n(c
om
ple
te)
1
0,5 1
AF
Exc
eptio
n(c
om
ple
te)
1
0,5 1
Inva
lidN
ISS
Exc
eptio
n(c
om
ple
te)
14 0
,75
4
0,7
5 1
4
GIL
Concu
rrency
Exc
eptio
n(c
om
ple
te)
1
0,5 1
RS
ISys
tem
Exc
eptio
n(c
om
ple
te)
28
0,7
5 7
0,6
67 5
0,6
67 1
0,7
5 2
0,6
67 5
0,8
33 5
0,6
67 5
0,6
67 4
0,7
5 1
2
0,9
81 5
3
AD
OP
Use
rChoic
eE
xceptio
n(c
om
ple
te)
1
0,5 1
0,6
67 5
RP
CE
xceptio
n(c
om
ple
te)
1
0,5 1
GR
EJB
Concu
rrency
Exc
eptio
n(c
om
ple
te)
15 0
,875
8
0,5 1
0,5 1
0,6
67 1
Mora
daP
ort
uguesa
NotF
oundE
xceptio
n(c
om
ple
te)
1
0,5 1
0,7
5 4
0,5 1
0,6
67 6
0,5 1
0,5 2
0,8
89 8
0,7
5 3
0,8 3
RS
IExc
eptio
n(c
om
ple
te)
1
0,5 1
0,5 1
0,5 1
0,6
67 4
0,6
67 3
0,5 1
0,5 2
0,7
5 5
0,5 1
0,5 1
0,5 2 0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,5 1
0,8 1
0,5 1
0,5 1
0,5 1
Fig
.4.
Spag
het
tim
odel
obta
ined
from
the
applica
tion
serv
erlo
gsusi
ng
the
heu
rist
ics
min
er.
Usi
ngth
ese
quen
cecl
uste
ring
plug
-inan
dit
spr
epro
cess
ing
capa
bilit
ies,
asw
ella
sthe
poss
ibili
tyof
visu
ally
adju
stin
gth
ecl
uste
rmod
elsa
ccor
ding
toce
rtai
nth
resh
olds
,itw
aspo
ssib
leto
iden
tify
seve
ralp
atte
rnsin
volv
ing
di�e
rent
type
sof
exce
ptio
ns.T
hese
patt
erns
wer
efo
und
afte
rse
vera
latt
empt
sof
tuni
ngw
ith
the
prep
roce
ssin
gpa
ram
eter
s,se
lect
ing
the
num
ber
ofcl
uste
rs(t
ypic
ally
from
3to
Healthcare
Our Goal
49
represents
Reality
Model
Towards Flexible BPM
• Flexibility by underspecification: Model left incomplete, then “completed” at run time.Example: YAWL.
• Flexibility by change: imperative, completely specified model that may be modified at runtime. Example: ADEPT.
50
Towards Flexible BPM• Flexibility by deviation:
imperative model that supports more possibilities at runtime, deviating from what prescribed in the model.Example: FLOWer.
• Flexibility by design: the process modeling language directly supports flexibility. Example: Constraint-based modeling (Declare, DCR Graphs).
51
Constraint-Based Modeling52
Constraint-Based Modeling
Focus: what has to be accomplished
• Explicit description of the relevant business constraints • behavioral constraints, best practices, norms, rules, …
Open modeling
• All behaviors are possible unless they are explicitly forbidden
• Control-flow left implicit
53
Organizational Boundaries54
Declare55
Declare56
Declare• A declarative, constraint-based language for flexible
process modeling
• An execution engine for constraint-based processeshttp://www.win.tue.nl/declare/
• Originally proposed by Pesic and van der Aalst
• Formalized by Pesic and van der Aaalst, and by _
• Two main abstractions: task, constraint
57
Constraints• Much richer than the simple “precedence sequence
flow connector” of imperative languages
• Allow for:
• Presence/absence of tasks (do/not do … N times)
• Negative relationships (it is forbidden to…)
• Atemporal relationships (no order imposed)
• Temporal relationships, with different strengths
58
Flexible Shopper
59
Pick item
Close order Pay
Flexible Shopper
60
Pick item
Close order Payresponse
Constraint Features
Three dimensions:
• Type
• Temporal direction
• Strength
61
Constraint TypesUnary constraints (apply on a single task)
• Existence: you should/cannot do A (for a certain number of times)
Binary constraints (apply to two - or more - tasks)
• Choice: do A or B
• Relation: if A occurs, then B should also occur (when?)
• Negation: if A then B cannot occur (when?)
Binary constraints may branch to represent potential alternatives
62
Constraint Direction• Applies to relation/negation constraints
• “If A occurs, then B should/cannot occur …” • No direction: “… either before or after” • Response: “… in the future” • Precedence: “… in the past”
• Example: If close order, then pay in the future
63
Constraint Strength• Applies to relation/negation constraints
• If A occurs, then B should/cannot occur • Normal • Alternate: A cannot occur again until B occurs • Chain: Immediate constraint (applies to tasks occurring next to each other)
• Example: • If close order, then pay in the future
vs • If close order, then do not close order again until pay in the future
vs • If close order, then the next task is to pay
64
Graphical Appearance
65
3.5 Usability of ConDec 65
Table 3.8. Basic visual constitutive elements of ConDec’s constraints
concept notation
existence constraints 0..N, M..*, K (a la UML)
choice ♦/ " (a la decision gateway in BP modeling notations)
binary constraints − (normal)= (alternate)≡ (chain)
source of binary constraints •
negation ∥
temporal ordering −−#succession representation response + precedence part
(e.g. •−−#• = •−−−# + −−−#•)
ones. As attested by the case study presented in Sect. 3.4, a variety of naturallanguage statements can be directly represented in ConDec, facilitating thedesign task and making it simpler to maintain a link between the model andthe requirements specification document, keeping track of which requirementshave been covered so far.
The declarative and open nature of ConDec has also a positive impacton the premature commitment dimension, a topic which has been already dis-cussed in Sect. 2.3.3 – p. 31. Indeed, by focusing on the “what” without statingthe “how”, a ConDec model is close to the business constraints introduced bythe domain under study, avoiding over-specification and over-constraining is-sues and delaying as much as possible the choice about the “order of doingthings”, postponing it until the execution takes place.
While the presence of several abstractions is desired to properly capturethe complexity of the outer world, it raises a potential usability issue, becausea long learning curve is needed to become familiar with the whole notation.ConDec mitigates this problem by paying great attention to the consistencyof the graphical notation. In particular, constraints are represented by coher-ently combining the small set of basic visual elements shown in Table 3.8.For example, the semantics of each succession relation, as well as its graphi-cal representation, is determined by combining the semantics/representationof its response and precedence part. Furthermore, existence and choice con-straints employ familiar symbols, taken from UML and from the mainstreamBP modeling languages.
Even though ConDec combines simple concepts, rendered in a consistentway, as the complexity of the designed models grows the models tend to loosetheir readability. Indeed, ConDec is not a flow-oriented language, but it isinstead a constraint-based language, and thus drives the modeler towards theadoption of an unstructured approach to design. A ConDec diagram is a “flat”
Existence Constraints
66
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
aActivity a can be executed at most n times, i.e., theexecution 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 mostthree payment attempts can be made by the customer:
0..3
pay
3.3.2 Choice Constraints
Choice constraints are shown in Table 3.2. They are n-ary constraints as-serting that the interacting entities must necessarily perform some activities,selecting them inside a set of possible choices. They can be therefore seenas an extension of the existence n and exactly n constraints, replacing asingle activity with a set of activities. Choice constraints are especially usefulwhen the model contains several activities having the same effect or accom-plishing the same business goal, because they leave interacting entities free tochoose the most suitable on their own. Indeed, a ConDec choice correspondsto a deferred choice [239]: the decision is not driven by an explicit choice, butis instead delegated to the interacting entities, which take it by executing oneof the interconnected tasks. A 1 of 2 -choice could be used to state that acontributing author must submit her paper either by uploading it through theweb site of the conference or by sending it via e-mail2:
upload paper −− ♦−− e-mail paper
2 We suppose that the “n of m” notation is optional when n = 1.
Examples:
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
aActivity a can be executed at most n times, i.e., theexecution 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 mostthree payment attempts can be made by the customer:
0..3
pay
3.3.2 Choice Constraints
Choice constraints are shown in Table 3.2. They are n-ary constraints as-serting that the interacting entities must necessarily perform some activities,selecting them inside a set of possible choices. They can be therefore seenas an extension of the existence n and exactly n constraints, replacing asingle activity with a set of activities. Choice constraints are especially usefulwhen the model contains several activities having the same effect or accom-plishing the same business goal, because they leave interacting entities free tochoose the most suitable on their own. Indeed, a ConDec choice correspondsto a deferred choice [239]: the decision is not driven by an explicit choice, butis instead delegated to the interacting entities, which take it by executing oneof the interconnected tasks. A 1 of 2 -choice could be used to state that acontributing author must submit her paper either by uploading it through theweb site of the conference or by sending it via e-mail2:
upload paper −− ♦−− e-mail paper
2 We suppose that the “n of m” notation is optional when n = 1.
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
aActivity a can be executed at most n times, i.e., theexecution 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 mostthree payment attempts can be made by the customer:
0..3
pay
3.3.2 Choice Constraints
Choice constraints are shown in Table 3.2. They are n-ary constraints as-serting that the interacting entities must necessarily perform some activities,selecting them inside a set of possible choices. They can be therefore seenas an extension of the existence n and exactly n constraints, replacing asingle activity with a set of activities. Choice constraints are especially usefulwhen the model contains several activities having the same effect or accom-plishing the same business goal, because they leave interacting entities free tochoose the most suitable on their own. Indeed, a ConDec choice correspondsto a deferred choice [239]: the decision is not driven by an explicit choice, butis instead delegated to the interacting entities, which take it by executing oneof the interconnected tasks. A 1 of 2 -choice could be used to state that acontributing author must submit her paper either by uploading it through theweb site of the conference or by sending it via e-mail2:
upload paper −− ♦−− e-mail paper
2 We suppose that the “n of m” notation is optional when n = 1.
Choice Constraints
67
3.3 Constraints 51
Table 3.2. ConDec choice constraints
name graphical meaning
choice(n of m,[a1,...,am])a1
am
a2n of m
...
At least n distinct activitiesamong a1,. . . ,am must be exe-cuted
ex choice(n of m,[a1,...,am])a1
am
a2n of m
...
Exactly n distinct activitiesamong 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 evaluatesa trace without submissions as noncompliant.
A 1 of 2 -exclusive choice can be instead adopted to model the existencebetween two alternatives that exclude each other. For example, it could beused to state that, within an instance of the system, the customer commitsherself to cancel or successfully close the order, but not both:
cancel order −− !−− close order
It is worth noting that choice constraints, together with the existenceNand exactlyN ones, constitute a family of goal-oriented constructs. Indeed,they impose the mandatory presence of (some of) the involved activities inany possible execution trace supported by the model, independently of theother constraints and of the specific courses of interaction.
3.3.3 Relation Constraints
Differently from goal-oriented constraints, relation constraints express posi-tive dependencies among activities; in their simplest form, they interconnecttwo activities (the generalized case will be discussed in Sect. 3.3.5). As shownin Table 3.3, the graphical representation of each relationship coherently com-municates the meaning of the relationship:
• the number of lines used to interconnect the two activities indicates howmuch tight is the dependency;
• the position of the “•” element determines which activity has the abilityof triggering the dependency;
• the presence of an arrow and its relative position with respect to the“•” element denote the qualitative temporal constraint associated to therelation.
In particular, when a relation constraint is connected to an activity througha “•” element, such an activity is called source of the constraint, and has
Examples:
3.3 Constraints 51
Table 3.2. ConDec choice constraints
name graphical meaning
choice(n of m,[a1,...,am])a1
am
a2n of m
...
At least n distinct activitiesamong a1,. . . ,am must be exe-cuted
ex choice(n of m,[a1,...,am])a1
am
a2n of m
...
Exactly n distinct activitiesamong 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 evaluatesa trace without submissions as noncompliant.
A 1 of 2 -exclusive choice can be instead adopted to model the existencebetween two alternatives that exclude each other. For example, it could beused to state that, within an instance of the system, the customer commitsherself to cancel or successfully close the order, but not both:
cancel order −− !−− close order
It is worth noting that choice constraints, together with the existenceNand exactlyN ones, constitute a family of goal-oriented constructs. Indeed,they impose the mandatory presence of (some of) the involved activities inany possible execution trace supported by the model, independently of theother constraints and of the specific courses of interaction.
3.3.3 Relation Constraints
Differently from goal-oriented constraints, relation constraints express posi-tive dependencies among activities; in their simplest form, they interconnecttwo activities (the generalized case will be discussed in Sect. 3.3.5). As shownin Table 3.3, the graphical representation of each relationship coherently com-municates the meaning of the relationship:
• the number of lines used to interconnect the two activities indicates howmuch tight is the dependency;
• the position of the “•” element determines which activity has the abilityof triggering the dependency;
• the presence of an arrow and its relative position with respect to the“•” element denote the qualitative temporal constraint associated to therelation.
In particular, when a relation constraint is connected to an activity througha “•” element, such an activity is called source of the constraint, and has
68
52 3 The ConDec Language
Table 3.3. ConDec relation constraints
name graphical meaning
resp existence([a], [b]) a •−−−− bIf a is executed, then b must be exe-cuted before or after a
coexistence([a],[b]) a •−−−• bNeither a nor b is executed, or theyare both executed
response([a],[b]) a •−−−! bIf a is executed, then b must be exe-cuted thereafter
precedence([a],[b]) a −−−!• bb can be executed only if a has beenpreviously executed
succession([a],[b]) a •−−!• ba and b must be executed in succes-sion, i.e. b must follow a and a mustprecede b
alt response([a],[b]) a •===! bb is response of a and between everytwo executions of a, b must be exe-cuted at least once
alt precedence([a],[b]) a ===!• ba is precedence of b and between ev-ery two executions of b, a must beexecuted at least once
alt succession([a],[b]) a •==!• bb is alternate response of a, and a isalternate precedence of b
chain response([a],[b]) a •=−=−=−! bIf a is executed, then b must be exe-cuted next (immediately after a)
chain precedence([a],[b]) a =−=−=−!• bIf b is executed, then a must havebeen executed immediately before b
chain succession([a],[b]) a •=−=−!• ba and b must be executed in sequence(next to each other)
the ability to trigger it. When the constraint triggers, then also the targetactivity, connected to the other side of the relation, must be executed. Relationconstraints are therefore reactive.
Starting from this basic schema, each relation constraint differs from theothers for what concerns when the occurrence of the target is expected to hap-pen as the constraint triggers. The responded existence and coexistencerelation constraints do not impose any temporal ordering, but rather leavethe interacting entities completely free to decide when the execution of thetarget is placed.
Example 3.3.1 (Unordered business constraint). Let us consider an interactionmodel regulating the messages exchange between a seller and a warehouse,which stores the goods of the seller. When the warehouse ships a good, then
Rela
tion
Con
stra
ints
69Neg
atio
n C
onst
rain
ts
3.3 Constraints 55
Table 3.4. ConDec negation constraints
name graphical meaning
resp absence([a],[b]) a •−−−−∥ bIf a is executed, then b can neverbe 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 •−−!•∥ ba and b cannot be executed insuccession
neg alt response([a],[b]) a •===!∥ bb cannot be executed betweenany two occurrences of a
neg alt precedence([a],[b]) a ===!•∥ ba cannot be executed betweenany two bs
neg alt succession([a],[b]) a •==!•∥ bb cannot be executed betweenany two as and viceversa
neg chain response([a],[b]) a •=−=−=−!∥ b b cannot be executed next to a
neg chain precedence([a],[b]) a =−=−=−!•∥ ba cannot be executed immedi-ately before b
neg chain succession([a],[b]) a •=−=−!•∥ ba and b cannot be executed insequence
Indeed, a •=−=−=−!∥ b states that when activity a is executed, b can beexecuted if at least one intermediate occurrence of another activity exists; onthe contrary, a •−−−−∥ b forbids the presence of b along the whole instance,if a is performed inside that instance.
Negation constraints are peculiar of open approaches, where by default allactivities can be executed in any order. In this respect, it would be unfea-sible to assume that “positive” constraints are sufficient for expressing sig-nificant interaction models. Furthermore it is sometime much more effectiveand compact to model the undesired behaviors rather than the allowed ones.For example, the not coexistence constraint could be directly employed in aConDec model to express that two activities are incompatible, e.g., that theseller cannot accept and reject an incoming order when interacting with acustomer:
accept order •−−−•∥ reject order
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 reject 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.
70
Modeling in Declare
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
71
0..1
Modeling in Declare
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
72
An order can be finalized at most once
0..1
Modeling in Declare
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
73
Once an order is finalized, it must be confirmed or rejected
0..1
Modeling in Declare
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
74
A confirmed order may be rejected later on, but not vice-versa
0..1
Modeling in Declare
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
75
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
0..1
Modeling in Declare
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
76
Mutually exclusive
Linear temporal logic over finite traces (LTLf): propositional logic enriched with temporal operators • Models: words over the alphabet of tasks -> exactly one
task at a time! • Constraints: formulae over tasks
N.B.: there is a huge difference between “standard” LTL and LTLf (not discussed here)
Constraint Semantics
77
3.6 Linear Temporal Logic 69
Table 3.9. LTL temporal operators
op. name meaning intuition
current state
⃝φ (Next time) φ will hold in the next state
♦φ (Eventually) φ will hold sometimes in the future
"φ (Globally) φ will always hold in the future
ψUφ (Until) φ will hold in a future moment, ψwill always hold until that moment
• atomic propositions, i.e., events, together with the two special constantstrue and false;
• classical propositional connectives, i.e., ¬, ∧, ∧ and ⇒;• temporal operators, i.e., ⃝ (next time), U (until), ♦ (eventually), " (glob-
ally) and W (weak until).
Starting from these constitutive elements, an LTL formula is recursively de-fined as follows:
• each event e ∈ E is a formula;• if φ is a formula, then ¬φ is a formula;• if φ and ψ are formulae, then φ ∧ ψ is a formula;• if ψ is a formula, then ⃝ψ is a formula;• if φ and ψ are formulae, then φUψ is a formula.
Other LTL formulae can be defined as abbreviations:
• φ ∨ ψ # ¬(¬φ ∧ ¬ψ) and φ ⇒ ψ # ¬φ ∨ ψ;• true # ¬φ ∨ φ and false # ¬true;• ♦φ # trueUφ, "φ # ¬♦¬φ and ψWφ # ψUφ ∨ "ψ.
When parentheses are omitted, the following priority of operators holds: firstall the temporal operators, then ¬, ∧, ∨ and finally ⇒.
3.6.3 Semantics of Linear Temporal Logic
The semantics of LTL is given w.r.t. an LTL model, in a specific state. In otherwords, the truth of formulae is evaluated inside a given state. We will use |=Lto denote the logical entailment in the LTL setting. M, i |=L φ means that φis true at time i in M. The intuitive semantics of each temporal operator issketched in Table 3.9. The W operator relaxes U by removing the requirementthat φ must eventually hold in a future moment, and by stating that in thiscase ψ must hold in all the future states.
Formalization Example
78
MooredUnder way using engine
Under way sailing
constrained by her draught
Formalization Example
79
MooredUnder way using engine
Under way sailing
constrained by her draught
¬⇤c _ ¬c Us
¬(⌃e ^ ⌃s)
Model formula: conjunction of all constraint formulae
⇤(m ! �⌃e)
Correctness of Models• A Declare model is correct if there exists at least a
finite trace satisfying all its constraints
• A Declare model is correct if its LTLf formula is satisfiable
• A correct model may still contain dead activities: activities that can never be executed • Can be reduced to model correctness: just add
1..* on top of the activity to be checked!
80
1..*
Example 1
81
a c
b
1..*
Example 1
82
a c
b
INCORRECT
0..1
Example 2
83
a c
b
0..1
Example 2
84
a c
b
dead activity
0..1
Example 2
85
a c
b
dead activity
1..* 0..1
a c
b
INCORRECT!
0..1
Example 2
86
a c
b
Example 3
87
1..*
a b
Example 3
88
1..*
a b
INCORRECT(finite traces)
Process Responsibilities• 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
AB
C
S
SnewS
89
RV-LTL Truth ValuesRefined 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
90
Process Execution in Declare
• Start with the empty trace
• Loop • Consider the history so far, assuming it is correctly recognized
• Block all activities that would lead to a permanent violation (of what? Constraint? Model?)
• Highlight constraints that are permanently satisfied • Highlight constraints that are temporarily violated
• If there is no temporarily violated constraint: allow for completing the process
• Wait until an allowed activity is executed• Update the history with the executed activity
91
At the beginning is so if the model is correct!
Execution
92
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
Initial Situation
93
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
May complete now…
“Finalize Order”
94
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
“Notify Shipment Issue”
95
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
“Reject Order”
96
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
May complete now…
Another Execution
97
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
Initial Situation
98
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
May complete now…
“Finalize Order”
99
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
“Ship”
100
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
“Confirm Order”
101
0..1
Finalize order
Confirmorder
Rejectorder
Ship
Notify shipment issue
May complete now…
Important Question
• To “block” activities, shall we just consider constraints separately?
102
Hidden Dependencies
103
Ship
Notify shipment issue
Pick package Insert material Close package
Initial State
104
Ship
Notify shipment issue
Pick package Insert material Close package
May complete now…
Initial State
105
Ship
Notify shipment issue
Pick package Insert material Close package
May complete now…
What if I executed this?
“Notify Shipment Issue”
106
Ship
Notify shipment issue
Pick package Insert material Close package
May complete now…
!!!
How to Implement This? Automata to the Rescue!
107
From Formulae to Automata
• Observation: Declare constraints are formalized using LTL over finite traces (LTLf)
• LTLf corresponds to the star-free fragment of regular expressions
• Intimate connection with finite-state automata
108
Declare 2 DFA
'
LTLf NFAnondeterministic
DFAdeterministic
LTLf2aut determin.
109
Declare 2 DFALTLf NFA
nondeterministicDFA
deterministic
LTLf2aut determin.
A process!• allowed tasks: alphabet, task: symbol, trace: word • history recognition —> word prefix recognition • todo list —> return next symbols • update —> transition
110
'
Local 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
111
Local Automata: Example
112
00 1
m
e
not m not e
mooredunder way using engine
under way sailing
constrained by her draught
Local Automata: Example
113
0s
c
not {c,s}true1
0 true
mooredunder way using engine
under way sailing
constrained by her draught
Local Automata: Example
114
mooredunder way using engine
under way sailing
constrained by her draught
s
e
not s
true00
not {s,e}1
2
3
e
s
not e
1
2
Coloring local automataWe color the states of each local automaton with their corresponding RV-LTL truth values
• 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 permanently violated: it is non-final and cannot reach a final state
• State temporarily violated: it is non-final but can reach a final state
115
Local Automata: Example
116
mooredunder way using engine
under way sailing
constrained by her draught
0s
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
Local Automata: Example
117
mooredunder way using engine
under way sailing
constrained by her draught
0s
c
not {c,s}true1
0 true
00 1
m
e
not m not e
Local Automata: Example
118
mooredunder way using engine
under way sailing
constrained by her draught
0s
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
Local Automata: Example
119
mooredunder way using engine
under way sailing
constrained by her draught
0s
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
Global AutomataWhat about hidden dependencies?
• We have to consider the interplay between constraints
• To do that: compute the “global automaton” for the entire model. Two possibilities: • Take the “conjunction formula” of all constraints and
get the DFA • Compute the intersection of the local DFAs
120
Can you Digest Spaghetti?121
Declare 2 DFA: Complexity
'
LTLf NFAnondeterministic
DFAdeterministic
LTLf2aut determin.
exponentialblow-up
exponentialblow-up
122
123
Example
124
Example
Automaton: Design TimeCorrectness of a Declare model reduced to nonemptiness of the corresponding automaton
1. Obtain the LTLf formula for the model
2. Compute the corresponding DFA
3. Check whether the DFA is (non)empty (if nonempty, there is at least one trace that is accepted)
125
Runtime: Global AutomatonBy computing the global DFA as the intersection of the local colored DFAs, we can get a global DFA that retains all “local colors”, and use it directly to manage the execution!
126
Conclusion• Turbulent, unpredictable, knowledge-intensive environments
demands flexibility • Constraint-based approaches provide a declarative way to
capture flexible processes • Declare does this by exploiting temporal logics over finite
traces: a compact way to represent spaghetti processes • Flexible processes demand reasoning support for their
understanding and correct execution • The automata-theoretic characterization of temporal logics gives
a “correct by design” computation mechanism for: model verification, execution, monitoring, discovery, conformance checking!
127
And the Story Continues…
128
Conformance Checking Using Object-Centric Behavioral Constraints 21
register
applicationperson position
1
employee
1
1
1
1..*
0..1
r1 r2
r3
11..*
1
1
r4
open pos.
close pos.
selecthire
apply
check reference
interview
1
1
1
0..2
1
1
1
1
1
1
1
0..5
11
c1
c2
c3
c4
c5
c6
c7 c8
Fig. 13. An OCBC model modeling a hiring process.
– Constraint c3 combines a unary-response and a unary-precedence constraint statingthat the opening a a position should be followed by the closing of the applicationprocess and the closing should be preceded by the opening of the position.
– Constraint c4 also combines a unary-response and a unary-precedence constraintstating that the two activities are executed in sequence.
– Constraint c5 specifies that applications for a position need to be preceded by theopening of that position.
– Constraint c6 specifies that after closing a position there should not be any newapplications for this position (non-response constraint).
– Constraint c7 specifies that every hire needs to be preceded by at least one interviewwith the candidate applying for the position (precedence constraint).
– Constraint c8 again combines a unary-response and a unary-precedence constraintstating that the two activities are executed in sequence.It is important to note that the constraints are based on the object model and that
there is not a single instance notion. To illustrate this consider the BPMN model in Fig-ure 14 which models the lifecycles of persons, positions, applications, and employeesin separate diagrams. The BPMN model looks very simple, but fails to capture depen-dencies between the different entities. Consider for example constraints c5, c6, c7, andc8 in the OCBC model of Figure 13. The BPMN model does not indicate that thereis a one to many relationship between positions and applications, and does not showthat one can only apply if the corresponding position is opened but not yet closed. TheBPMN model does not indicate that only one person is hired per position and that theperson to be hired should have registered, applied, and had at least one interview. TheBPMN model does not indicate that employees are hired after the completion of the
Object-Centric Declare (joint work with Wil van der Aalst and Guangming Li)
ReferencesDeclare and its formalizations• M. Pesic and W. van der Aalst, A Declarative Approach for Flexible
Business Processes Management, in Proceedings of the Business Process Management Workshops. Springer-Verlag, 2006, vol. 4103, pp. 169-180.
• 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 Lecture Notes in Business Information Processing. Springer-Verlag, 2010. ISBN: 978-3-642-14537-7.
• M. Westergaard, Better Algorithms for Analyzing and Enacting Declarative Workflow Languages Using LTL, in Proceedings of the 9th International Conference on Business Process Management, Springer-Verlag, 2011, pp. 83-98.
129
ReferencesDeclare Execution Environment• M. Pesic, H. Schonenberg, and W. M. P. van der Aalst, DECLARE: Full
Support for Loosely-Structured Processes, in Proceedings of the 11th IEEE International Enterprise Distributed Object Computing Conference, Washington, DC, USA: IEEE Computer Society, 2007, pp. 287–300.
• M. Pesic, M. Schonenberg, N. Sidorova, and W. van der Aalst, Constraint-Based Workflow Models: Change Made Easy, in On the Move to Meaningful Internet Systems 2007: CoopIS, DOA, ODBASE, GADA, and IS, R. Meersman and Z. Tari, Ed., Springer Berlin / Heidelberg, 2007, vol. 4803, pp. 77-94.
• M. Pesic, H. Schonenberg, and W. Aalst, The Declare Service, in Modern Business Process Automation, Springer-Verlag, 2010, pp. 327-343.
• M. Westergaard, F. M. Maggi, Declare: A Tool Suite for Declarative Workflow Modeling and Enactment, BPM (Demos) 2011.
130
ReferencesMonitoring 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 Proceedings of the 9th International Conference on Business Process Management, Springer-Verlag, 2011, pp. 132-147.
• F. M. Maggi, M. Westergaard, M. Montali, W. M. P. van der Aalst,Runtime Verification of LTL-Based Declarative Process Models.: Proceedings of the 2th International Conference on Runtime Verification, Springer-Verlag, 2011, pp. 131-146.
• 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, Proceedings of the 12th International Conference on Business Process Management, Springer-Verlag, 2014, pp. 1-17.
131
ReferencesDiscovering 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
Proceedings of the IEEE Symposium on Computational Intelligence and Data Mining, Springer-Verlag, 2011, pp. 192-199. • 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 Proceedings of the 24th International Conference on Advanced Information Systems Engineering, Springer-Verlag, 2012, pp. 270-285.
• F. M. Maggi, M. Dumas, L. García-Bañuelos, M. Montali, Discovering Data-Aware Declarative Process Models from Event Logs. In Proceedings of the 11th International Conference on Business Process Management, Springer-Verlag, 2013, pp. 81-96.
• F. M. Maggi, Declarative Process Mining with the Declare Component of ProM. BPM (Demos) 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
Proceedings of the 13th International Conference on Business Process Management, Springer-Verlag, 2015, pp. 144-159. • C. Di Ciccio, F. M. Maggi, M. Montali, J. Mendling, Semantical Vacuity Detection in Declarative Process Mining. n
Proceedings of the 15th International Conference on Business Process Management, Springer-Verlag, 2016, pp. 158-175.
132