Temporal logics over finite traces for declarative BPM

Marco Montali

Free University of Bozen-Bolzano [email protected]

A Success Story

TEMPORAL

DECLARATIVE

OVER

FOR

BPM

FINITETRACES

LOGICS

A SUCCESS STORY

marco montali free university of bozen-bolzano

FMAI17

Assets of an Organization• Data: the main information source about the history

of the domain of interest and the relevant aspects of the current state of affairs

• Resources: humans and devices responsible for the execution of work

• Business processes: how work is carried out in the domain of interest, towards the achievement of organizational objectives

2

Business Process Management

A collection ofconcepts, methodologies, techniques,to support humans in modeling, governance, deployment, enactment, and analysis ofbusiness processes

3

Business Process Lifecyclediagnosis/

requirements

configuration/implementation

(re)designenactment/monitoring

4

models

data

Environment

7

Flexibility vs ControlFlexibility: degree to which users can make local decisions about how to execute processes. Control: degree to which a system makes centralized decisions about how to execute processes.

Universe of Traces

Compliant

Traces

Compliance

Flexibility8

Trends in BPM

modeling

• Highly-variable BPs

• Metaphor: rules/constraints

Dec t ilara ev

Imperative modeling • Traditional repetitive BPs

• Metaphor: flow-chart

9

The Issue of Flexibility

10

Imperative Modeling11

Organizational Boundaries12

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

13

BPMN

Receiveorder

Check availability

Article available?

Ship articleFinancial

settlementyes

Procurement

no Paymentreceived

Inform customer

Late deliveryUndeliverable

Customerinformed

Inform customer

Articleremoved

Remove article from catalogue

14

BPMN

Receiveorder

Check availability

Article available?


settlementyes

Procurement

no Paymentreceived

Inform customer


Customerinformed

Inform customer

Articleremoved


Input Output

15

BPMN

Receiveorder

Check availability

Article available?


settlementyes

Procurement

no Paymentreceived

Inform customer


Customerinformed

Inform customer

Articleremoved


Input Output

16

Choreography Example• An order can be finalized at most once • Once an order is finalized, it must be confirmed or rejected • A confirmed order may be rejected later on (due to “late”

problems), but not vice-versa: a rejection cannot be reverted. • An order can be confirmed only if it shipped before. • An order may be rejected autonomously by the seller.

However, if the warehouse notifies the seller of a shipment issue, then the seller has to reject the order.

• The warehouse decision is firm: “Ship” and “Notify shipment issue” are mutually exclusive.

18

What is your Favourite Italian Food?

Order-to-delivery

19


Order-to-delivery

20


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

Healthcare21


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

Healthcare22

Our Goal

represents

Reality

Model

23

Constraint-Based Modeling24

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

25

Declare27

Declare28

Declare• A constraint-based extensible 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 _

29

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

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship

Notify shipment issue

30

0..1

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship


An order can be finalized at most once

31

0..1

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship


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

32

0..1

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship


precedence…

33

0..1

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship


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

34

0..1

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship


if the warehouse notifies the seller of a shipment issue, then the seller has to reject the order

An order can be confirmed only if it shipped before

35

0..1

Modeling in Declare

Finalize order

Confirmorder

Rejectorder

Ship


Mutually exclusive

36

Existence Constraints50 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



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





37

Choice Constraints3.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

38


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

39

Neg

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

40

Semantics of Declarediagnosis/

requirements


enactment/monitoring

41

data

(re)design

models

The Origin of Declare…

42


43

LTL

A Slide of FairnessThe disruptive novelty of this idea has to be

put in the BPM context!

• In AI, these ideas have been around for a long time

• E.g., work on declarative interaction protocols and temporal declarative specification of agents

44


45

LTL ⇤(m ! �⌃e)


46

LTLEach process instance eventually terminates!


47

LTLfEach process instance eventually terminates!

Models: finite traces

Declare 2 Finite State AutomataLTLf NFA

nondeterministicDFA

deterministic

LTLf2aut determin.

'

48

For a single constraint: local automaton

For the whole model: global automaton

Our Vision… Realized!

'

LTLf NFAnondeterministic

DFAdeterministic

LTLf2aut determin.

49

Formalization Example

MooredUnder way using engine

Under way sailing

constrained by her draught

50

Formalization Example

MooredUnder way using engine

Under way sailing


¬(⌃e ^ ⌃s)

Model formula: conjunction of all constraint formulae

⇤(m ! �⌃e)

51

¬cWs

Correctness Verificationdiagnosis/

requirements



52

data

(re)design

models

0..1

Example

a c

b

53

0..1

Example

a c

b

dead activity

54

0..1

Example

a c

b

dead activity

55

Correctness• In BPM: typically assessed via model checking

• In the case of Declare: satisfiability • Correct Declare model: there exists at least a finite

trace satisfying all its constraints • i.e., if its LTLf model formula is satisfiable

• A correct model may still contain dead activities: activities that can never be executed

• How to check? Language emptiness of the corresponding NFA

56

(re)design

models

diagnosis/requirements


57

data


Enactment and Monitoring

Enactment of a Process• History recognition: given the history of a running

instance, compute the current state (or reject)

• Todo list: given the current state, tell which tasks can(not) be executed next (including possibility of termination)

• Update: given a state and a task, determine the new state

S

AB

C

S

SnewS

58

Execution

0..1

Finalize order

Confirmorder

Rejectorder

Ship


59

Initial Situation

0..1

Finalize order

Confirmorder

Rejectorder

Ship


May complete now…60

“Finalize Order”

0..1

Finalize order

Confirmorder

Rejectorder

Ship


61

“Notify Shipment Issue”

0..1

Finalize order

Confirmorder

Rejectorder

Ship


62

“Reject Order”

0..1

Finalize order

Confirmorder

Rejectorder

Ship



Hidden Dependencies

Ship


Pick package Insert material Close package

64

Initial State

Ship




Initial State

Ship



May complete now…

What if I execute this?

66

“Notify Shipment Issue”

Ship



May complete now…

!!!

67

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

68

Linear Dynamic Logic over Finite Traces

69

The Logic ldl

f

[De Giacomo&Vardi,IJCAI13]Merges ltl

f

with regular expressions, through the syntax of PropositionalDynamic Logic (PDL):

Ï ::= „ | tt | � | ¬Ï | Ï1 · Ï2 | ÈflÍÏ | [fl]Ïfl ::= „ | Ï? | fl1 + fl2 | fl1; fl2 | flú

Ï: ltl

f

part; fl: regular expression part.They mutually refer to each other:

• ÈflÍÏ states that, from the current step in the trace, there is anexecution satisfying fl such that its last step satisfies Ï.

• [fl]Ï states that, from the current step in the trace, all executionsatisfying fl are such that their last step satisfies Ï.

• Ï? checks whether Ï is true in the current step and, if so, continuesto evaluate the remaining execution.

Of special interest is end = [true?]� , to check whether the trace has beencompleted (the remaining trace is the empty one).

Marco Montali (unibz) Monitoring Business Metaconstraints BPM 2014 13 / 26

Automata for LDLf

70

From ldl

f

to nfa

Direct calculation of nfa corresponding to ldl

f

formula Ï

Algorithm1: algorithm ldlf 2nfa()2: input ltlf formula Ï3: output nfa AÏ = (2P , S, {s0}, Í, {sf })4: s0 Ω {"Ï"} Û single initial state5: sf Ω ÿ Û single final state6: S Ω {s0, sf }, Í Ω ÿ7: while (S or Í change) do

8: if (q œ S and q

Õ |=w

("Â"œq) ”("Â", �))9: S Ω S fi {q

Õ} Û update set of states10: Í Ω Í fi {(q, �, q

Õ)} Û update transition relation

Note• Standard nfa.• No detour to Büchi automata.• Easy to code.• Implemented!

Auxiliary rules

”("tt", �) = true

”("� ", �) = false

”("„", �) =I

true if � |= „false if � ”|= „

(„ propositional)

”("Ï1 · Ï2", �) = ”("Ï1", �) · ”("Ï2", �)”("Ï1 ‚ Ï2", �) = ”("Ï1", �) ‚ ”("Ï2", �)

”("È„ÍÏ", �) =

Y_]

_[

"Ï" if last ”œ � and � |= „ („ propositional)”("Ï", ‘) if last œ � and � |= „false if � ”|= „

”("ÈÂ?ÍÏ", �) = ”("Â", �) · ”("Ï", �)”("Èfl1 + fl2ÍÏ", �) = ”("Èfl1ÍÏ", �) ‚ ”("Èfl2ÍÏ", �)

”("Èfl1; fl2ÍÏ", �) = ”("Èfl1ÍÈfl2ÍÏ", �)

”("ÈflúÍÏ", �) =I

”("Ï", �) if fl is test-only”("Ï", �) ‚ ”("ÈflÍÈflúÍÏ", �) o/w

”("[„]Ï", �) =

Y_]

_[

"Ï" if last ”œ � and � |= „ („ propositional)”("Ï", ‘) if last œ � and � |= „ („ propositional)true if � ”|= „

”("[Â?]Ï", �) = ”("nnf (¬Â)", �) ‚ ”("Ï", �)”("[fl1 + fl2]Ï", �) = ”("[fl1]Ï", �) · ”("[fl2]Ï", �)

”("[fl1; fl2]Ï", �) = ”("[fl1][fl2]Ï", �)

”("[flú]Ï", �) =I

”("Ï", �) if fl is test-only”("Ï", �) · ”("[fl][flú]Ï", �) o/w


Black Magic with LDLf

71

Runtime ldl

f

MonitorsCheck partial trace fi = e1, . . . , e

n

against formula Ï.

From ad-hoc techniques . . .

e1 . . .e

n |=C

ÏD

RV =Y___]

___[

temp_truetemp_falsetruefalse

. . . To standard techniques

e1 . . .e

n |=Y______]

______[

Ïtemp_true

Ïtemp_false

Ïtrue

Ïfalse


Colored Automata

72

'

00 1

m

e

not m not e

'temp true

Colored Automata

73

''temp false 'perm false'perm true

00 1

m

e

not m not e

'temp true

Colored Automata

74

''temp false 'perm false'perm true

00 1

m

e

not m not e

00 1

m

e

not m not e

Coloring local automataColoring simply amounts to reachability checks!

• State permanently satisfied: it is final and cannot reach a non-final state

• State temporarily satisfied: it is final but can reach a non-final state

• State temporarily violated: it is non-final but can reach a final state

• State permanently violated: it is non-final and cannot reach a final state

75

Local Colored Automata

• For each constraint, we take its LTLf formula, and compute the corresponding DFA

• This DFA accepts all and only the execution traces that lead to satisfy (pemanently or temporarily) the constraint

76

Local Automata: Example

mooredunder way using engine

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

77

Global AutomatonWhat about hidden dependencies?

• We have to consider the interplay between constraints

• To do that: compute the “global automaton” for the entire model. Either: • Take the “conjunction formula” of all constraints and

get the DFA • Compute the intersection of the local DFAs

78

Global Colored AutomatonBy carefully intersecting local DFAs: we get a

global DFA that retains all “local colors”. This is… an execution engine!

79

Implemented in ProM!

Approach1. Input ltl

f

/ldl

f

constraints and metaconstraints.2. Produce the corresponding RV ldl

f

monitoring formulae.3. Apply the direct algorithm and get the corresponding nfas.4. (Incrementally) run nfas the monitored trace.


MonitoringThe same approach can be used for monitoring

• With LDLf, we can predicate about the truth value of constraints

• Direct support formeta-constraints • Compensation constraints • Contrary-to-duty constraints • Dynamic activation/

disablement of constraints80


Process Mining

81

(re)design

models


data

diagnosis/requirements

Declarative Process Discovery

82Event log

Declarative Process Discovery

83Event log

Declarative model that “best” capture the

process hidden in the log

Basic Idea of Existing Algorithms

• Apply heuristics to guess a constraint

• Check the support of the constraint

• Check the interestingness factor of the constraint

• Combine these two metrics to decide whether to keep the constraint or not

• Iterate and prune

84

Problems• Correctness of the overall declarative model (for

constraints with <100% support)

• Minimality of the overall declarative model (redundant constraints)

• How to determine whether a constraint is interesting or not

• All these questions: successfully tackled with logics and automata!

85

Interestingness and Vacuity

• ababababab • adfbcdadb • acb • acbaafb • aabbabbb

86

⇤(a ! ⌃b)Support: 100%

⇤(a ! ⌃b)Support: 100%

Why is a trace interesting for a constraint?

• Because it “activates” the constraint, “changing” something

• Semantically: • It flips the RV-LTL state of the constraint • It changes the set of allowed transitions

• Non-vacuous satisfaction =satisfaction + interestingness

87

Example

88

00 1

a

b

not a not b

⇤(a ! ⌃b) ⇤(a ! ⌃b)

a c b a a f b

Another Example

89

c a d a f

¬(⌃a ^ ⌃b)

a

b

not b

true00

not {a,b}1

2

3

b

a

not a

1

2

c d f f

Activation-Aware Automata

90

Conclusion• BPM struggles to balance flexibility and control • Constraint-based approaches and temporal logics over finite

traces offer a solution • The automata-theoretic approach leads to a “correct by

design” computation mechanism to assist humans during the entire process lifecycle

• A lot of open challenges! • Measuring interestingness (“graded within a trace”) • Mix declarative and imperative approaches • Data!

91

And the Story Continues…

Object-Centric Declare (joint work with Wil van der Aalst and Guangming Li)

92

OrderItem Package

Pick Item

Pay Order

Get Package

0..1 ** 0..1

Acknowledgments• Wil van der Aalst

• Maja Pesic

• Federico Chesani

• Paola Mello

• Fabrizio Maggi

93

• Michael Westergaard

• Giuseppe De Giacomo

• Riccardo De Masellis

• Claudio di Ciccio

• Jan Mendling

Some ReferencesDeclare and its formalizations• M. Pesic and W. van der Aalst, A Declarative Approach for Flexible Business

Processes Management, in BPM Workshops. Vol. 4103 of LNCS, pp. 169-180. Springer, 2007.

• M. Montali, M. Pesic, W. M. P. van der Aalst, F. Chesani, P. Mello, and S. Storari, Declarative specification and verification of service choreographies, ACM Trans. Web, vol. 4, pp. 3:1–3:62, 2010.

• M. Montali. Specification and Verification of Declarative Open Interaction Models: a Logic- Based Approach, vol. 56 of LNBIP. Springer, 2010.

• M. Westergaard, Better Algorithms for Analyzing and Enacting Declarative Workflow Languages Using LTL, in BPM, vol. 6896 of LNCS, pp. 83-98. Springer, 2010.

• Giuseppe De Giacomo, Riccardo De Masellis, Marco Montali,Reasoning on LTL on Finite Traces: Insensitivity to Infiniteness, in AAAI, pp. 1027-1033. AAAI Press, 2014.

94

Some ReferencesDeclare Execution Environment• M. Pesic, H. Schonenberg, and W. M. P. van der Aalst, DECLARE:

Full Support for Loosely-Structured Processes, in EDOC, pp. 287–300. IEEE Computer Society, 2007.

• M. Pesic, M. Schonenberg, N. Sidorova, and W. van der Aalst, Constraint-Based Workflow Models: Change Made Easy, in CoopIS, vol. 4803 of LNCS, pp. 77-94. Springer, 2007.

• M. Pesic, H. Schonenberg, and W. Aalst, The Declare Service, in Modern Business Process Automation, Springer, 2010, pp. 327-343.

• M. Westergaard, F. M. Maggi, Declare: A Tool Suite for Declarative Workflow Modeling and Enactment, BPM (Demos) 2011.

95

Some 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 BPM, volume 6896 of LNCS, pp. 132-147. Springer, 2011.

• F. M. Maggi, M. Westergaard, M. Montali, W. M. P. van der Aalst,Runtime Verification of LTL-Based Declarative Process Models.: Proceedings of RV, volume 7186 of LNCS, pp. 131-146. Springer, 2011.

• M. Montali, F. M. Maggi, F. Chesani, P. Mello, W. M. P. van der Aalst,Monitoring business constraints with the event calculus. ACM Trans. on Intelligent Systems and Technology 5(1): 17, 2013.

• G. De Giacomo, R. De Masellis, M. Grasso, F. M. Maggi, M. Montali, Monitoring Business Metaconstraints Based on LTL and LDL for Finite Traces, in BPM, volume 8659 of LNCS, pp. 1-17. Springer, 2014.

96

Some 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 CIDM, pp. 192-199. IEEE Press, 2011.

• F. M. Maggi, R. P. J. Chandra Bose, W. M. P. van der Aalst, Efficient Discovery of Understandable Declarative Process Models from Event Logs. In CAiSE, volume 7908 of LNCS, pp. 270-285. Springer, 2012.

• F. M. Maggi, M. Dumas, L. García-Bañuelos, M. Montali, Discovering Data-Aware Declarative Process Models from Event Logs. In BPM, volume 8094 of LNCS, pp. 81-96. Springer, 2013.

• C. Di Ciccio, M. Mecella, On the Discovery of Declarative Control Flows for Artful Processes. ACM Trans. Management Inf. Syst. 5(4): 24:1-24:37, 2015.

• C. Di Ciccio, F. M. Maggi, M. Montali, J. Mendling, Ensuring Model Consistency in Declarative Process Discovery. In BPM, volume 9253 of LNCS, pp. 144-159. Springer, 2015.

• C. Di Ciccio, F. M. Maggi, M. Montali, J. Mendling, Semantical Vacuity Detection in Declarative Process Mining. In BPM, volume 9850 of LNCS, pp. 158-175. Springer, 2016.

• Claudio Di Ciccio, Fabrizio Maria Maggi, Marco Montali, Jan Mendling:Resolving inconsistencies and redundancies in declarative process models. Inf. Syst. 64: 425-446, 2017. 97

Temporal logics over finite traces for declarative BPM

Presentations & Public Speaking

Transcript of Temporal logics over finite traces for declarative BPM