Montali: Declarative, Constraint-Based Business Process Management - Seville 2016

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?


settlementyes

Procurement

no Paymentreceived

Inform customer


Customerinformed

Inform customer

Articleremoved


Input Output

28

BPMN

Receiveorder

Check availability

Article available?


settlementyes

Procurement

no Paymentreceived

Inform customer


Customerinformed

Inform customer

Articleremoved


Input Output

29


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}


• 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



• 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


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



• 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



• 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


is it?

You may pick items, close and pay an order.Whenever you close an order, eventually you have to pay.

39


is it?

40

pick item

close order pay

quit

order paid


is it?

41

pick item

close order pay

quit

order paid

simple, correct, but not general enough!


is it?

42

pick item

close order pay

pick item

pay


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


46

Order-to-delivery


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


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


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

http://www.win.tue.nl/declare/

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:




absence(a)

0


absence(n+1,a)

0..n


existence(n,a)

n..∗


exactly(n,a)

n


init(a)

init


1..∗

order item


0..3

pay








absence(a)

0


absence(n+1,a)

0..n


existence(n,a)

n..∗


exactly(n,a)

n


init(a)

init


1..∗

order item


0..3

pay





Choice Constraints

67

3.3 Constraints 51

Table 3.2. ConDec choice constraints


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


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


Table 3.3. ConDec relation constraints


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


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


72

An order can be finalized at most once

0..1

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship


73

Once an order is finalized, it must be confirmed or rejected

0..1

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship


74

A confirmed order may be rejected later on, but not vice-versa

0..1

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship


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


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


¬⇤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


Initial Situation

93

0..1

Finalize order

Confirmorder

Rejectorder

Ship


May complete now…

“Finalize Order”

94

0..1

Finalize order

Confirmorder

Rejectorder

Ship


“Notify Shipment Issue”

95

0..1

Finalize order

Confirmorder

Rejectorder

Ship


“Reject Order”

96

0..1

Finalize order

Confirmorder

Rejectorder

Ship


May complete now…

Another Execution

97

0..1

Finalize order

Confirmorder

Rejectorder

Ship


Initial Situation

98

0..1

Finalize order

Confirmorder

Rejectorder

Ship


May complete now…

“Finalize Order”

99

0..1

Finalize order

Confirmorder

Rejectorder

Ship


“Ship”

100

0..1

Finalize order

Confirmorder

Rejectorder

Ship


“Confirm Order”

101

0..1

Finalize order

Confirmorder

Rejectorder

Ship


May complete now…

Important Question

• To “block” activities, shall we just consider constraints separately?

102

Hidden Dependencies

103

Ship


Pick package Insert material Close package

Initial State

104

Ship



May complete now…

Initial State

105

Ship



May complete now…

What if I executed this?

“Notify Shipment Issue”

106

Ship



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



113

0s

c

not {c,s}true1

0 true


under way sailing



114


under way sailing


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


116


under way sailing


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


117


under way sailing


0s

c

not {c,s}true1

0 true

00 1

m

e

not m not e


118


under way sailing


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


119


under way sailing


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

Presentations & Public Speaking

Montali: Declarative, Constraint-Based Business Process Management - Seville 2016