Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction...

Marco Montali University of Bologna

Bolzano, 15/12/2010

¡  Interaction Models §  Declarativeness and Openness

¡  Requirements for a supporting framework ¡  Specification: ConDec ¡  Formalization

§  LTL §  ALP (CLIMB)

¡  Reasoning §  Static verification §  Run-‐time support §  Process mining

¡  In many emerging settings… § Distribution of activities and resources ▪ To attack the system’s complexity ▪  programming-‐in-‐the-‐large

▪ Due to the intrinsic presence of multiple stakeholders

§ Complex and unpredictable dynamics ▪ Multiple participants, autonomous and heterogeneous ▪ Exceptional situations and external stakeholders

¡  From the internal implementation of a single component…

¡ … to the interaction between components

¡  Interacting entities §  Autonomous §  Heterogeneous §  Can freely enter or leave the interaction

➔ Open systems

Participants Events Interaction Model

Main Challenge

Employees External stakeholders Customer Services

Activities lifecycle: start, complete, abort, reassign,…

Business Process

Balance between the boundaries of the BP and the expertise of the involved stakeholders

Healthcare professionals Patients Medical devices

Admin. actions Therapeutic actions …

Clinical Guideline

Balance between generally accepted best practices and the background medical knowledge applied to a specific patient

Services People

Messages Service Choreography

Balance between conformance and adaptability/replaceability

¡  Dynamics traced in terms of event occurrences §  Event-‐based systems

¡  Interaction modeling languages for open systems must be able to balance between §  Compliance The act of conforming as requested by the interaction model (e.g. internal and external rules and norms)

§  Flexibility The ability of accommodating and promptly adapting to change and to unforeseen situations

Universe of Traces

Compliant

Traces

Compliance

Flexibility

¡  Closed and procedural modeling abstractions

Closed approaches All that is not explicitly modeled is forbidden

Open approaches All that is not explicitly forbidden is allowed

Procedural approaches A-‐priori, rigid definition of all the acceptable courses of interaction

Declarative approaches Capture the interaction constraints without fixing a pre-‐determined way of satisfying them

Flexibility sacrificed

Flexibility guaranteed

¡  Non-‐ordered constraint ¡  Closed procedural approach: explicit encoding of all the compliant traces §  Do not contain the two involved activities §  Contain both activities, in any order and cardinality

if the warehouse refuses the order then the seller must also refuse (or have refused) it

¡  Empty workflow ¡  The following

¡ Many compliant traces not supported à over-‐constrained model

Selle

rW

areh

ouse

refuse shipment

refuse order

...

......

...

Selle

r

refuse order

refuse order

...

War

ehou

se

refuse shipment

refuse shipment

... ...

...decision drivenby the seller

?

¡  Ambiguous decision points

¡  Message exchanges not mentioned in the problem

à over-‐specified model! ¡  Still lack of support for

many compliant traces

¡  Problems §  Over-‐specification and over-‐constraining §  Even more difficult for negative constraints §  What about other business constraints?

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

diffe

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

¡  Focused on (business) constraints ¡  Define the “behavioral boundaries”

§  Supported traces implicitly determined by all behaviors compliant with the rules

Universe of traces

Problem's constraints Procedural closed approach

Universe of traces Universe of traces

Declarative open approach

knowledgelevel

business constraints

designlevel

legislation

proceduralmodel

declarativemodel

policies

regulations

businessrules

Is it possible to provide support at this level?

¡  Usability (by non-‐IT savvy)

¡  Support along the entire system’s lifecycle

High-‐level graphical specification languages

Automated reasoning capabilities

internallife cycle

third partylife cycle

diagnosis

desig

n

execution

execution

diagnosisdesig

n

runtime verification

static verificationa-posteriori verification

a-posteriori verification

runt

ime

verifi

catio

nst

atic

ver

ifica

tion

enactment

propertiesverification

a-prioricomplianceverification

modeldiscovery

trace analysis

a-prioricomplianceverification

monitoringon-the-fly

compliance verification

model discoverycomposition

trace analysis

a-posterioricompliance verification

open declarativeinteraction model

interactionmodel

Support!

Computational Logic for the Ification and Modeling of Business constraints

ver

REASONINGCAPABILITIES

GRAPHICALMODELING

system

formalspecification

bac

(extended)ConDec

CLIMB

Translation

SCIFF Framework

event log


GRAPHICALMODELING

system

formalspecification

bac

(extended)ConDec

CLIMB

Translation

SCIFF Framework

event log

¡  ConDec = Constraints, Declarative ¡  Graphical notation ¡ Model = activities + business constratins ¡  Constraints are first-‐class entities

§  More complex modeling abstractions than the strict precedences of workflows

▪  Negation constraints ▪  Non-‐oriented constraints ▪  Constraints with different degrees of “tightness”

¡  First step: activities elicitation §  Completely open model

choose

item

standard

payment

1-click

payment

accept

advert

close

order

register

¡  Second step: constraints elicitation §  Partial closure of the model: supported traces must comply with all the constraints

payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..1

Response Every time A is executed, B should be executed afterwards

Alternate response

Every time A is executed: -‐  B should be executed

afterwards -‐  A cannot be executed again

until B is executed

Chain response Every time A is executed, B should be executed next

A B

A B

A B

CUSTOMER SELLER WAREHOUSE

commit order

confirm order

refuse order

confirm shipment

refuse shipment


GRAPHICALMODELING

system

formalspecification

bac

(extended)ConDec

CLIMB

Translation

SCIFF Framework

event log

Translation

LTL

ConDec

[Pesic and van der Aalst, 2006]

¡  ConDec execution traces à LTL models ¡  ConDec model M à LTL “conjunction“ formula

§  Each ConDec constraint is formalized as an LTL formula ¡  LTL entailment becomes a compliance evaluator ¡  ConDec traces are finite

§  An interaction must eventually reach an end àEither a finite-‐trace semantics is adopted …or a termination property is introduced

72 3 The ConDec Language

|=L is defined by induction on the structure of the formulae3:

• (TL |=L φ) iff (TL, 0 |=L φ);• (TL, i |=L e) iff e ∈ TL(i) (i.e., i ∈ vocc(e));• (TL, i �|=L e) iff e �∈ TL(i);• (TL, i |=L φ ∧ ψ) iff (TL, i |=L φ) and (TL, i |=L ψ);• (TL, i |=L φ ∨ ψ) iff (TL, i |=L φ) or (TL, i |=L ψ);• (TL, i |=L φ ⇒ ψ) iff (TL, i �|=L φ) or (TL, i |=L ψ);• (TL, i |=L �φ) iff (TL, i + 1 |=L φ);• (TL, i |=L ψUφ) iff ∃k ≥ i s.t. (TL, k |=L φ) and ∀i ≤ j < k (TL, j |=L ψ);• (TL, i |=L ♦φ) iff ∃j ≥ i s.t. (TL, j |=L φ);• (TL, i |=L �φ) iff ∀j ≥ i (TL, j |=L φ);• (TL, i |=L ψWφ) iff either ∃k ≥ i s.t. (TL, k |=L φ) and ∀i ≤ j < k

(TL, j |=L ψ), or ∀j ≥ i (TL, j |=L φ).

3.7 Translating ConDec into Linear Temporal Logic

LTL can be successfully employed to formalize all the ConDec constraints,providing a temporal logic-based semantics to the graphical notation. TheConDec language itself has been developed starting from the work of Dwyeret al. [98], in which the authors present a pattern-based analysis of the mostdiffused LTL formulae in the specification of concurrent reactive systems. Inthis light, ConDec can be considered as a graphical front-end, supportingnon-IT savvy in the rigorous formal specification of interaction models, whileavoiding the direct manipulation of temporal logical formulae.

3.7.1 The Translation Function

We suppose that the translation of an arbitrary ConDec model into the un-derlying LTL formalization is embedded in a translation function called tLTL.

Definition 3.7.1 (ConDec to LTL translation). tLTL is a function whichtranslates a ConDec model CM = �A, Cm, Co� into an LTL conjunction for-mula as follows:

tLTL : CM �−→ tLTL (CM) =�

Ci | Ci∈Cm

tLTL (Ci)

where tLTL (Ci), i.e., the application of tLTL to a ConDec mandatory con-straint, follows the guidelines provided in [191, 173].

3 For the sake of readability, we explicitly denote the semantics of ♦, � and W,even if their meaning can be obtained from the semantics of U .

¡  The system itself is modeled as a formula!!!

3.7 Translating ConDec into Linear Temporal Logic 73

Example 3.7.1 (LTL representation of a ConDec model). Let us consider aportion of the ConDec model shown in Fig. 3.2, namely:

refuse order •−−−•� pay •−−�•0..1

deliver receipt

Its LTL representation is:

tLTL

refuse order •−−−•� pay •−−�•0..1

deliver receipt

= (Def. 3.7.1)

tLTL

�refuse order •−−−•� pay

�∧

tLTL

�pay •−−�• deliver receipt

�∧

tLTL

0..1

deliver receipt

= ([191, 173])

[♦refuse order ⇒ ¬♦pay ∧ ♦pay ⇒ ¬♦refuse order]∧[�(pay ⇒ ♦deliver receipt) ∧ (¬deliver receipt)Wpay]∧

[¬(♦(deliver receipt ∧�♦deliver receipt))]

Indeed, the translation of the whole model corresponds to the conjunc-tion of the formulae translating each one of the three constraints. The notcoexistence constraint is represented in LTL by stating that if refuse orderis eventually executed, then the execution of the pay activity is always for-bidden4, and vice versa. The succession constraint is translated as the con-junction of the translations of its response and precedence parts. Responseexpresses that every time a payment is done, then a receipt will be eventu-ally delivered. Conversely, the precedence part is formalized by means of theweak until operator: deliver receipt cannot be executed until the payment isdone, or it cannot be executed at all if the payment is never done. Finally,the absence 2 constraint is formalized by forbidding a double execution ofdeliver receipt. To model the double occurrence of deliver receipt, in turn, wecombine the ♦ and� operators: the receipt must be eventually delivered, andfrom the state immediately following such a delivery a second receipt must beeventually delivered again.

3.7.2 LTL Entailment as a Compliance Evaluator

Thanks to Defs. 3.6.1 and 3.7.1, we have established a link between executiontraces and LTL models, and between ConDec models and LTL formulae. Un-der this perspective, LTL entailment provides a formal account to the notion4 Remember that ¬♦pay � �¬pay.

CLIMB/SCIFF LTL

ConDec

[Pesic and van der Aalst, 2006]

¡  Developed by the §  AI group at DEIS, University of Bologna

§  AI group at ENDIF, University of Ferrara

during the SOCS EU Project (FP7 – Global Computing)

¡  Expressive language for specifying interaction protocols, with an

underlying ALP-‐based declarative semantics ¡  Proof-‐theoretic operational counterparts based on the IFF proof

procedure by Fung and Kowalski

A framework based on Computational Logic for the declarative specification and verification of global

interaction protocols in open agent societies

(partial) execution trace

CLIMBspecification

Expectations

FulfillmentAbductive

explanations

CLIMB specification: rule-‐based, mixing forward and backward rules Subset of the SCIFF syntax

¡  Happened event §  H(e,t) à event e occurs at time t (real or integer) §  Explicit and quantitative notion of time §  A set of ground happened events is an execution trace

¡  Positive Expectation §  E(e,t) à event e is expected to occur at time t §  Must have a corresponding event occurrence §  Variables are existentially quantified

¡  Negative Expectation §  EN(e,t) à event e is expected not to occur at time t §  Must have no corresponding event occurrence §  Variables are universally quantified

¡  Events are terms, and may contain variables ¡  Times are variables ¡  Variables can be

§  Used into predicates and §  Subject to CLP constraints

¡  Examples §  E-‐bay is expected to sell item foo for a price of at least 20 €, within time 60 at most (deadline)

§  Basic customers cannot never pay by credit card E(sell(e-‐bay,foo,Price),T) /\ Price > 20 /\ T < 60

EN(pay(Customer,Item,credit_card),T) /\ basic(Customer)

¡  Prolog KB to express the static domain knowledge ¡  Integrity constraints to constrain the dynamics of the system

H(E1,T1) /\ H(E2,T2) /\ … /\ predicates /\ constraints → E/EN(E3, T3) /\ … /\ predicates /\ constraints \/ E/EN(E4, T4) /\ … /\ predicates /\ constraints \/ …

Link with the KB Could contain variables: the integrity constraint will trigger for any possible configuration of ground happened events matching with the body

¡  Every time a premium customer sends a request_info, an employee is expected to send back an answer within at most 2 hours H(request_info(Customer,Info),T) /\ premium(Customer) → E(answer(Employee,Content), T2) /\ T2 > T /\ T2 < T + 120. (minute granularity)

¡  When the seller accepts an order from a customer, it cannot refuse it anymore H(accept(Seller,Customer,Order),T) → EN(refuse(Seller,Customer,Order), T2) /\ T2 > T.

¡  ICs exploited in a forward, reactive manner §  Occurring events match with the happened events contained in rules’ body

§ When the whole body matches, the constraint triggers

§ When the constraint triggers, the expectations contained in the head are generated

¡  Triggered expectations must be fulfilled by the actual trace

à compliance!

¡  Abductive reasoning §  Reasoning under incomplete knowledge §  Hypothesis of possible explanations that account for an observation

§  Integrity constraints to identify acceptable explanations ¡  In LP à Abductive Logic Program <P,A,IC>

§  P= Logic program where some predicates are left undefined ▪  abducibles

§  IC = formulae used to identify acceptable explanations §  Queries answered by formulating hypotheses on predicates in A (abductive explanations)

¡  CLIMB specification mapped onto an Abductive Logic Program <KB, {E/2, EN/2}, IC>

§  KB is the domain knowledge base §  IC constrains the interaction §  Expectations are abducibles ▪  The framework “observes” the occurring events… ▪  … formulating hypotheses about the expected courses of interaction

¡  Events dynamically occur over time à three-‐valued semantics §  Partial vs complete trace à open vs closed entailment ▪  Completion not applied to partial traces

4.3 CLIMB Declarative Semantics 105

Comp (KB ∪ T ∪∆) ∪ CET∪TX |= IC

where Comp is the three-valued completion of a theory [147], CET standsfor Clark Equational Theory [77] and TX is the constraint theory [135],parametrized by X .

Fixing a CLP theory corresponds to instantiating the parameter X . There-

fore, different structures (such as R or finite domains) can be chosen without

affecting the notion of CLIMB abductive explanation.

The symbol |= is interpreted in three valued logics, thus embedding the

CLIMB abductive semantics into a three-valued model-theoretic semantics,

as done, in a different context, by Fung and Kowalski [111] and by Denecker

and De Schreye [89]. Three-valued logics are multi-valued logic systems in

which there are three truth values: true, false and unknown. They are there-

fore particularly appropriate to deal with systems characterized by incomplete

knowledge. This is the case of open and heterogeneous EBSs, in which un-

predictable events dynamically occur over time, a large share of information

is unknown and knowledge evolves over time. For example, let us consider

a business constraint stating that “if a private medical examination is com-

pleted, the patient is obliged to pay for it within two days”. When such a

constraint is applied to an instance of the system, there are many situations

in which neither its truth nor its falsity can be determined. One of these sit-

uations comes about when the medical examination is completed: it is not

possible to know whether the patient will satisfy the payment obligation until

the payment is actually done or two days have passed.

It is worth noting that if a set of integrity constraints is entailed, then

each single constraint is entailed as well. The following remark starts from this

trivial observation and establishes a link between an abductive explanation

for a certain instance ST , and the T -instances obtained by considering only

a sub-set of integrity constraints in S.

Remark 4.3.3 (Abductive explanations and sub-specifications). If ∆ is an ab-

ductive explanation for �KB, IC�T , then ∆ is an abductive explanation also

for �KB, IC��T , where IC� ⊆ IC.

The following example introduces some abducible sets, discussing whether

they are suitable abductive explanations of a given CLIMB instance or not.

Example 4.3.5 (Abductive explanations). Let us consider the CLIMB specifi-

cation Q, described in Example 4.3.4, together with the execution trace

T = { H(tell(alice, hatter, query-ref(loc(rabbit))), 5),

H(tell(hatter, alice, refuse(loc(rabbit)), 10) }

The abducible sets

∆0 = ∅∆1 = { E(tell(alice, hatter, query − ref(loc(rabbit))), 5) }

¡  Semantics: the one of ALP but… 1)  Semantics of expectations à specialized notion of consistency

§  E-‐consistency:

2)  Hypotheses confirmation à formal notion of compliance §  Closed:

3)  Events dynamically occur over time à three-‐valued semantics §  For partial traces, fulfillment cannot be always assessed ▪  Fulfillment of negative expectation is unknwon ▪  Violation of positive expectations is unknown

4.3 CLIMB Declarative Semantics 107

4.3.6 On the Formal Definition of Compliance

In Sect. 4.3.5, we have provided a formal account to CLIMB abductive ex-

planations. However, in the context CLIMB expectations are not simply ab-

ducible predicates, but they carry a specific, prescriptive meaning: a positive

expectation states that some event is expected to happen, while a negative

expectation states that some event occurrence is prohibited. Hence, expecta-

tions are strongly connected to the happened events composing the execution

traces of the system: depending on the actual event occurrences contained in

a trace, they become fulfilled or violated, leading to consequently certifying

the trace as correct or not. The CLIMB declarative semantics must take care

of formally capturing such an intended meaning, making clear and explicit

the relationships between positive and negative expectations, and between

expectations and happened events.

The connection between positive and negative expectations is tackled by

E-consistency, which basically states that they are conflicting concepts: the

same event cannot be expected to happen and not to happen at the same

time.

Definition 4.3.8 (E-consistency). An abducible set ∆ is E-consistent iff∀e ∈ U and ∀t ∈ T:

{E(e, t),EN(e, t)} � ∆

Example 4.3.6 (E-consistency and intensional representations). Let us con-

sider the abductive explanations of Example 4.3.5. Sets ∆3 and ∆4 are E-

consistent, while ∆5 is not E-consistent, because the same refusal event is

expected to happen and not to happen at time 10. Indeed, remember that

EN(tell(hatter, alice, refuse(loc(rabbit)), T ) is used to intensionally repre-

sent the (infinite) set of negative expectations on all the possible ground times,

including also T = 10.

The intensional representation of expectations may sometimes cause con-

fusion w.r.t. E-consistency. For example, the set

{ E(ev, T1) ∧ T1 ≥ 4 ∧ T1 ≤ 9,EN(ev, T2) ∧ T2 > 5 ∧ T2 < 8 }

is E-consistent: being T1 existentially quantified, event if the two contrasting

expectations overlap in time, it is sufficient that there exists at least one

possible assignment of T1, consistent with the CLP constraints, that is outside

the scope of T2. In particular, by adopting a discrete, integer time structure,

the set intensionally represents one of the sets

{ E(ev, 4),EN(ev, 6),EN(ev, 7) } (E-consistent)


{ E(ev, 6),EN(ev, 6),EN(ev, 7) } (E-inconsistent)

{ E(ev, 7),EN(ev, 6),EN(ev, 7) } (E-inconsistent)



108 4 The CLIMB Rule-Based Language

5 6 7 8 94

E ev

EN ev

[ ])(

5 6 7 8 94

[ ])(

] [E-inconsistency

Fig. 4.5. Interplay between CLP temporal constraints and E-consistency

Two of such sets are not E-consistent. The possible choices hence restrict to

{ E(ev, 4),EN(ev, 6),EN(ev, 7) }{ E(ev, 5),EN(ev, 6),EN(ev, 7) }{ E(ev, 8),EN(ev, 6),EN(ev, 7) }{ E(ev, 9),EN(ev, 6),EN(ev, 7) }

Therefore, by taking into account E-consistency, the original set is equivalentto:

{ E(ev, T1) ∧ [(T1 ≥ 4 ∧ T1 ≤ 5) ∨ (T1 ≥ 8 ∧ T1 ≤ 9)],EN(ev, T2) ∧ T2 > 5 ∧ T2 < 8 }

The graphical intuition is reported in Fig. 4.5. This kind of manipulation isoperationally handled, in SCIFF, by the CLP solver itself.

The relationship between expectations and happened events is captured bythe notion of fulfillment , which formalizes the conditions determining whetheran expectation is satisfied by a given CLIMB instance or not. In particular,it formalizes the following intended meaning:

• positive expectations must have a corresponding matching event in theexecution trace of the instance;

• negative expectations must have no corresponding matching event in theexecution trace of the instance.

Definition 4.3.9 (Fulfillment). Given a CLIMB trace T and an abducibleset ∆, ∆ is T -fulfilled if and only if, ∀e ∈ U,∀t ∈ T:

E(e, t) ∈ ∆ =⇒ H(e, t) ∈ TEN(e, t) ∈ ∆ =⇒ H(e, t) /∈ T

By taking into account the abductive nature of expectations, fulfillment canbe interpreted as a particular form of hypotheses confirmation:

• Expectations are hypothesized according to the running instance of thesystem and the CLIMB specification; this leads to the formulation of ex-pectations as abductive explanations, according to Def. 4.3.7.

¡  A (partial/complete) trace T is compliant with a CLIMB specification S

compliant(ST) if and only if

§  There exists an abductive explanation Δ for ST (according to the open/closed entailment) s.t. ▪  Δ is E-‐consistent ▪  Δ is T-‐fulfilled (according to the open/closed def.)

¡  Expectations as a bridge between interaction rules and the actual behaviors

¡  Empty KB ¡  IC

§  H(exec(d),T) à EN(exec(Y),T) /\ Y!=d. §  H(exec(a),T) à E(exec(b),T2) /\ T2 > T.

\/ E(exec(c),T2) /\ T2 > T. ¡  Complete trace:

§  H(exec(a),1). §  H(exec(c),5). §  H(exec(d),5).

¡  Complete trace: H(exec(a),1). H(exec(c),5). H(exec(d),5).

¡  Two minimal E-‐consistent Δs (intensional representation) §  Δ1 = {E(exec(b),T’), EN(exec(Y’),5)} with ▪  T’ > 1 existentially quantified ▪  Y’ ≠ d universally quantified

§  Δ2 = {E(exec(c),T’’), EN(exec(Y’’),5)} with ▪  T’’ > 1 existentially quantified ▪  Y’’ ≠ d universally quantified

¡  Complete trace: H(exec(a),1). H(exec(c),5). H(exec(d),5).

¡  Two minimal E-‐consistent Δs (intensional representation) §  Δ1 = {E(exec(b),T’), EN(exec(Y’),5)} with ▪  T’ > 1 existentially quantified à no “b” in the trace ▪  Y’ ≠ d universally quantified à Y’ / c

§  Δ2 = {E(exec(c),T’’), EN(exec(Y’’),5)} with ▪  T’’ > 1 existentially quantified à T’’ / 5 ▪  Y’’ ≠ d universally quantified à Y’’ / c

NONCOMPLIANT !

“pending” if the trace had been partial

¡ Why? § Language motivation ▪ High expressiveness ▪ Quantitative and explicit notion of time à metric constraints (deadlines!) ▪ Variables to model data and resources à data-‐related aspects

§ Reasoning motivation ▪ A family of proof procedures for reasoning

¡  Very intuitive translation §  Activities mapped onto CLIMB events §  Constraints formalized as integrity constraints ▪  “Positive” constraints à positive expectations ▪  “Negative” constraints à negative expectations

¡  Compositionality §  Compliance to an entire model reduced to compliance to each constraint (alone)

§  The formalization of each constraint can be changed as long as it is equivalent modulo compliance

payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..1

Simple relation constraint H(register, Tr) → E(accept_advert, Ta).

payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..1

Timed relation constraint H(1-‐click_payment, Tp) → E(register, Tr)∧Tr < Tp.

payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..1

Negation constraint H(close_order, To) → EN(choose_item, Ti) ∧ Ti > To.

Response H(a, Ta) → E(B, Tb)∧Tb > Ta.

Alternate response

H(a, Ta) → E(b, Tb)∧Tb > Ta ∧EN(a, Ta2)∧Ta2 > Ta ∧Ta2< Tb.

Chain response

H(a, Ta) → E(b, Tb)∧Tb > Tb ∧EN(X, TX)∧TX > Ta ∧TX< Tb.

A B

A B

A B

LTLformula

CLIMB specification

ba

c

tLTL tCLIMB

complies with

CLIMB traceLTLtrace

ConDec Model

Real execution trace

tmcomplies with

behavioralequivalence

tm-1

¡  Formal results §  Soundness of the CLIMB translation w.r.t. the LTL one

§  SCIFF is strictly more expressive than LTL ▪  Automatic translation LTLàSCIFF ▪  Cannot be used for reasoning ▪  semi-‐decidability!!!

after

after(N)Ta+N

activity a performed at time Ta

before(N)Ta-N

before

between(N1,N2)Ta+N1 Ta+N2

Ta-N2 Ta-N1between(N1,N2)

anytime

equals(N)

Ta+Nequals(N)

Ta-N

a b

a b

a b

a b

a b

(N,-)

a b

(N,-)a b(N1,N2)

a b(N1,N2)

[N,N]

[N,N]a b

validity of TB

6.1 Metric Constraints 145

activity. In particular, the time window is translated backward or forward withrespect to the source execution time, depending on whether the constraint isof a precedence or response type.

CLIMB is able to capture such desiderata in a straightforward way. Forexample, the formalization of the metric response is2:

tIC

�a

(n,m)•−−−� b

�� H(exec(a), Ta) →E(exec(b), Tb) ∧ Tb > Ta + n

∧ Tb < Ta + m.

The constraint expresses that if activity a is executed at time Ta, then afollowing activity b is expected to occur with a minimum delay of n timeunits, and a maximum delay of m time units, i.e., (strictly) between Ta + nand Ta + m. Symmetrically, precedence is extended as follows:

tIC

�a

(n,m)−−−�• b

�� H(exec(b), Tb) →E(exec(a), Ta) ∧ Ta > Tb −m

∧ Ta < Tb − n.

Metric precedence expresses that activity b is executable only inside the timewindows ranging from n to m time units after each occurrence of activity a.The membership of Tb to such a time window is expressed by means of thetwo CLP constraints Tb > Ta + n and Tb < Ta + m, which are equivalent tothe ones shown in the formalization.

Fig. 6.1 shows how ConDec++ is able to combine the proposed notationwith basic relation constraints (i.e., responded existence, response andprecedence) to express a plethora of metric relationships between the in-volved activities. A typical use of the metric extension is the modeling ofdeadlines. For example, a customer could express that she wants to interactonly with sellers able to deliver the ordered items by at most two days afterthe order’s payment. By assuming a time granularity of hours, ConDec++ cancapture this business constraint as:

pay(−,48)•−−−� deliver

Finally, the metric extension can be combined with negation relationshipsto model latencies, i.e., minimum time spans that must be respected beforeexecuting a certain activity. For example, a warehouse could state that it takesat least one day to ship a an order after having received a request; ConDec++

models such a latency constraint as:

receive order request(−,24)•−−−�� ship order

2 We show the case in which bounds are excluded. Inclusion of bounds is modeledby substituting the < and > CLP constraint with ≤ and ≥ respectively.

6.1 Metric Constraints 145

activity. In particular, the time window is translated backward or forward withrespect to the source execution time, depending on whether the constraint isof a precedence or response type.

CLIMB is able to capture such desiderata in a straightforward way. Forexample, the formalization of the metric response is2:

tIC

�a

(n,m)•−−−� b

�� H(exec(a), Ta) →E(exec(b), Tb) ∧ Tb > Ta + n

∧ Tb < Ta + m.

The constraint expresses that if activity a is executed at time Ta, then afollowing activity b is expected to occur with a minimum delay of n timeunits, and a maximum delay of m time units, i.e., (strictly) between Ta + nand Ta + m. Symmetrically, precedence is extended as follows:

tIC

�a

(n,m)−−−�• b

�� H(exec(b), Tb) →E(exec(a), Ta) ∧ Ta > Tb −m

∧ Ta < Tb − n.

Metric precedence expresses that activity b is executable only inside the timewindows ranging from n to m time units after each occurrence of activity a.The membership of Tb to such a time window is expressed by means of thetwo CLP constraints Tb > Ta + n and Tb < Ta + m, which are equivalent tothe ones shown in the formalization.

Fig. 6.1 shows how ConDec++ is able to combine the proposed notationwith basic relation constraints (i.e., responded existence, response andprecedence) to express a plethora of metric relationships between the in-volved activities. A typical use of the metric extension is the modeling ofdeadlines. For example, a customer could express that she wants to interactonly with sellers able to deliver the ordered items by at most two days afterthe order’s payment. By assuming a time granularity of hours, ConDec++ cancapture this business constraint as:

pay(−,48)•−−−� deliver

Finally, the metric extension can be combined with negation relationshipsto model latencies, i.e., minimum time spans that must be respected beforeexecuting a certain activity. For example, a warehouse could state that it takesat least one day to ship a an order after having received a request; ConDec++

models such a latency constraint as:

receive order request(−,24)•−−−�� ship order

2 We show the case in which bounds are excluded. Inclusion of bounds is modeledby substituting the < and > CLP constraint with ≤ and ≥ respectively.

¡  In most event logs (see e.g. BPMS) §  Activities involve data and roles §  Activities are executed by some actor (originator)

¡  These aspects could be exploited inside constraints §  Data-‐related conditions

6.3 Modeling Data in ConDec++ 153

6.1, we can model it by relying on an open account activity, associated to

an age datum3. Then, an absence constraint can be employed to state that

accounts cannot be opened. However, since the prohibition is only applied

to originators whose age is less than 18, a data condition age < 18 must be

associated to absence. The resulting model is then:

open account

0

Age

Age < 18

“Age < 18” acts as a restriction on the applicability of absence. Indeed, the

0 cardinality constraint will be enforced (and violated) only if open account is

executed by a person whose age is under 18. It will instead remain quiescent

every time an account is opened by persons whose age is ≥ 18.

When conditions are associated to binary relationships, it is necessary to sep-

arate them into different (optional) groups. First, groups of conditions may

be associated to each constraint’s endpoint. This is graphically rendered by

anchoring the group of conditions to the contact point between the constraint

and the activity or port. Such a group is interpreted as a set of absolute condi-

tions on the data of the activity, applied in the context of the constraint. If the

activity is a source of the constraint, then the group of conditions contributes

to determine when the constraint is triggered: it will trigger only if all the

group’s conditions are met. In this respect, the group plays the role of an ex-plicit choice, i.e., a choice driven by the actual data [239]. If instead the activity

is a target of the constraint, then the group of conditions is interpreted as a

mandatory requirement restricting the possible matching event occurrences.

Moreover, a further group of conditions may be anchored to the constraint, in

order to model relative conditions between the data of the involved activities.

Such an additional group is interpreted as a further restriction applied on the

target activity. Since relative conditions are expressed over data of different

activities, to resolve possible name clashes each datum is recalled by using an

ActivityName.datum notation.

Summarizing, a data aware response like

a bCs Ct

Cm

is interpreted as: “every time a is executed such that Cs is satisfied, then an

instance of b, satisfying both Ct and Cm, must be eventually executed”.

Example 6.3.2 (Data aware response constraints). Let us focus on the (DA3)

and (DA4) business constraints of Example 6.2.1. They can be both modeled

3 The second datum, namely the responsible of the activity, is implicitly associatedto each activity, and can be recalled, in this specific case, using notation “ open

account.O”.

6.4Form

alizing

Data

Aw

areA

spects

inC

LIM

B159

Table 6.2. Translation of some data aware ConDec++ constraints into CLIMB

open account

0

Age

Age < 18

true→EN(exec(open account ,EID ,O , [Age]), T ) ∧Age < 18.

diligence study

add to black list

EvaluationBank Target

failed(Evaluation) add to.O = diligence.O/\ add to.Target = diligence.Bank

H(exec(diligence study ,EIDs ,Os , [Bank ,Evaluation]), Ts) ∧ failed(Evaluation)

→E(exec(add to black list ,EIDb ,Ob , [Target ]), Tb)

∧Ob = Os ∧ Target = Bank ∧ Tb > Ts.

test glucose eat

Level

Level < 70test glucose.Patient = eat.O

Patient Food

sweet(Food)

(0,5)H(exec(test glucose,EIDt ,Ot , [Level ,Patient ]), Tt) ∧ Level < 70

→E(exec(eat ,EIDe ,Oe , [Food ]), Te)

∧Oe = Patient ∧ sweet(Food) ∧ Te > Tt ∧ Te < Tt + 5.

eat test

type(Code, 'no-food')

Food

(0,8]

eat.O = test.Patient

Code PatientH(exec(test ,EIDt ,Ot , [Code,Patient ]), Tt) ∧ type(Code,no-food)

→EN(exec(eat ,EIDe ,Oe , [Food ]), Te)

∧Oe = Patient ∧ Te < Tt ∧ Te ≥ Tt − 8.

¡  In most event logs (see e.g. BPMS) §  Activities involve data and roles §  Activities are executed by some actor (originator)

¡  These aspects could be exploited inside constraints §  Data-‐related conditions

154 6 Extending ConDec

by means of a response constraint, suitably extended with data and dataaware conditions. As shown in Table 6.1, (DA3) involves a source condition,stating that only failed evaluations will trigger the constraint, and two relativeconditions, expressing that the constrained activities must be executed by thesame originator, as well as that the target of the add to black list activity mustbe the bank whose evaluation failed. While the source condition is modeledas a predicate failed(evaluation), the two relative conditions are actuallyequality constraints. We thus obtain the ConDec++ response:

diligence study

add to black list



(DA4) involves instead three different types of data aware conditions. First,a CLP constraint level < 70 is employed as source condition, to state thatthe constraint triggers only when the glucose level is lower than 70 mg/dl.Second, an equality constraint models that the eat activity is expected to beexecuted by the patient who has been subjected to the glucose test. Third, aProlog predicate sweet(Food) is used to impose that the eaten food must besweet. The graphical ConDec++ representation of (DA4) is then:

test glucose eat

Level


Patient Food

sweet(Food)

(0,5)

Note that the constraint is also associated to a (0, 5) temporal constraint,because the sweet food must be eaten by the patient within 5 time units atmost.

Example 6.3.3 (A data aware negation response constraints). Rule (DA5) ofExample 6.2.1 is an example of data aware negation response constraint. Itis triggered by the occurrences of the test activity, when the test has type “no-food”. This condition can be expressed by attaching a type(code, ‘no-food’)Prolog predicate to the source of the constraint. Furthermore, the constraintmust be enforced on the patient subjected to the medical test, and thereforean equality condition between the patient datum of test and the originator ofeat must be anchored to the constraint. Finally, the constraint is delimited intime: eating food is forbidden only during the 8 hours preceding the test. Thegraphical ConDec++ representation of (DA5) hence becomes:

eat test


Food

(0,8]


Code Patient

6.4Form

alizing

Data

Aw

areA

spects

inC

LIM

B159

Table 6.2. Translation of some data aware ConDec++ constraints into CLIMB

open account

0

Age

Age < 18

true→EN(exec(open account ,EID ,O , [Age]), T ) ∧Age < 18.

diligence study

add to black list



H(exec(diligence study ,EIDs ,Os , [Bank ,Evaluation]), Ts) ∧ failed(Evaluation)

→E(exec(add to black list ,EIDb ,Ob , [Target ]), Tb)

∧Ob = Os ∧ Target = Bank ∧ Tb > Ts.

test glucose eat

Level


Patient Food

sweet(Food)

(0,5)H(exec(test glucose,EIDt ,Ot , [Level ,Patient ]), Tt) ∧ Level < 70

→E(exec(eat ,EIDe ,Oe , [Food ]), Te)

∧Oe = Patient ∧ sweet(Food) ∧ Te > Tt ∧ Te < Tt + 5.

eat test


Food

(0,8]


Code PatientH(exec(test ,EIDt ,Ot , [Code,Patient ]), Tt) ∧ type(Code,no-food)

→EN(exec(eat ,EIDe ,Oe , [Food ]), Te)

∧Oe = Patient ∧ Te < Tt ∧ Te ≥ Tt − 8.

¡  Atomic activities à instantaneous execution ¡  Non-‐atomic activities à span over time

§  Associated to a life cycle ▪  Multiple events ▪  Multiple possible instantiations at the same time 150 6 Extending ConDec

initial execution

executionsuccessful

executionfailed

started (ts) completed (tc)

canceled (tx)

Fig. 6.3. The life cycle of non atomic activities in (extended) ConDec (from [191])

The MXML meta model states that a log is associated to a set of inter-action models. Being the set of activities the only portion of the interactionmodel that leaves a trace during the execution, in the context of MXML in-teraction models are simply characterized as sets of (non atomic) activities.Interaction models can be executed multiple times: each execution is calledinstance, and is composed by a set of audit trail entries. Each entry representsan observed event occurrence, and is associated to:

• a corresponding activity of the interaction model;• an originator , i.e., the interacting entity responsible for the generation of

the event;• an event type, reflecting the specific type of event with respect to the

activity;• a date, representing the time value at which the event occurred;• a (possibly empty) set of further specific domain-dependent data values

related to the event occurrence.

The possible event types are taken from the MXML transactional model,which characterizes the life cycle of each non atomic activity in terms ofatomic, punctual events. Such a life cycle has been devised by carrying outan extensive analysis of the different types of logs in real-life systems, payingparticular attention to Workflow Management Systems.

Summarizing, MXML provides a standardized way to model executiontraces, and tackles the first two requirements pointed out in Sect. 6.2.1, namelysupport of data and of non atomic activities.

6.2.3 The Life Cycle of Non Atomic Activities in ConDec++

The MXML transactional model fixes a set of events (or operations) thatcan be executed on each activity. Since activities can be executed multipletimes, the life cycle models the evolution of each specific execution of theactivity, i.e., of each activity instance, describing how its state is affected bythe generation of events. For example, the execution of an activity could bestarted by someone, then assigned to a new originator, and finally completedby the new responsible.

152 6 Extending ConDec

(role)aDatum1 Datum2

(role)a

Outputdatum

ts tc

tx

Inputdatum

Fig. 6.4a. Atomic ConDec++ activitywith data and role

Fig. 6.4b. non atomic ConDec++ ac-tivity with data and role

a b

absolute conditionson a's data absolute conditions

on b's data

relative conditionsbetween a's and b's data

1..*

absolute conditions on a's data

Fig. 6.5. ConDec++ notation for expressing data aware conditions

ConDec++ inherits (and extends) all the ConDec constraints . Since Con-Dec constraints are applied to punctual events, in the case of a non atomicactivity they are not directly connected to the activity itself, but rather on itsports. In this way, it is possible to model complex situations, such as that asome activity must have at least one successful completion (by anchoring anexistence 1 constraint to its completion port), or that a certain activity canbe started only if another activity has been successfully completed before (byusing a precedence constraint that interconnects the start port of the firstactivity and the completion port of the second one).

6.3.2 Modeling Data Aware Conditions

Fig. 6.5 depicts how data aware conditions are represented in ConDec++.They are graphically represented as strings composed by a conjunction ofCLIMB atoms, i.e., Prolog predicates and CLP constraints. Typical examplesare equality (or disequality) constraints, stating that two data do (not) havethe same value. CLP-based conditions are especially useful when dealing withnumerical data. The text of a condition is anchored to the targeted ConDec++

constraint by means of a dashed arrow with a small filled diamond on its top.When conditions are associated to an existence constraint, they are in-

terpreted as an absolute restriction on the activity’s data, reducing the set ofground event occurrences to which the constraint applies. In other words, onlyoccurrences satisfying the imposed restriction will affect the constraint. Sucha restrictions is “absolute” because it does not relate the targeted variablesto other variables, but only to ground terms.

Example 6.3.1 (A data aware absence constraint). Let us consider the businessconstraint (DA1) of Example 6.2.1. Following the analysis reported in Table

¡  Non-‐atomic activities require event correlation §  Each tc and tx must be associated to a single previous ts

¡  LTL cannot express this kind of correlation §  [Pesic, 2008]

¡  CLIMB can easily express correlation by §  Introducing the notion of “activity instance identifier” §  Augmenting the ConDec formalization by ▪  Defining the semantics of instance identifier ▪  Constraining events as specified by the activity lifecycle

§  ConDec constraints can be then associated to the activity’s ports

REASONINGCAPABILITIES SCIFF

Framework

REASONINGCAPABILITIES SCIFF

Framework

GRAPHICALMODELING

system

formalspecification

bac

(extended)ConDec

CLIMB

Translation

event log

¡  Reactive proof procedure §  Triggered by the acquisition of new happened events

¡  Given a trace T and a SCIFF specification S, evaluates compliant(ST) §  Generates expectations §  Checks E-‐consistency and T-‐fulfillment §  Open/closed modality for partial/complete traces

¡  Rewriting system à generates a proof tree §  Computes until a quiescent node is reached, or all paths lead to a failure node ▪  At closure, a quiescent node is a success node

I(S, Ti)T1 = Ti ∆P 1 = ∅R1 = true ∆F 1 = ∅

CS1 = ∅ ∆V 1 = ∅psIC1 = {IC} ∆A1 = ∅

propagation

T2 = Ti ∆P 2 = ∅R2 = true ∆F 2 = ∅

CS2 = ∅ ∆V 2 = ∅psIC2 = {IC, T �

a = 5 → E(exec (b) , T �b) ∧ T �

b > T �a.} ∆A2 = ∅

case analysis T �a=5

��

��

�T �

a �=5

��

��

�

T3 = Ti ∆P 3 = ∅R3 = true ∆F 3 = ∅

CS3 = {T �a = 5} ∆V 3 = ∅

psIC3 = {IC, true → E(exec (b) , T �b) ∧ T �

b > 5.} ∆A3 = ∅logical equivalence and constraint solver

⊥

T4 = Ti ∆P 4 = ∅R4 = E(exec (b) , T �

b) ∆F 4 = ∅CS4 = {T �

a = 5, T �b > 5} ∆V 4 = ∅

psIC4 = {IC} ∆A4 = ∅

abduction

T5 = Ti ∆P 5 = {E(exec (b) , T �b)}

R5 = true ∆F 5 = ∅CS5 = {T �

a = 5, T �b > 5} ∆V 5 = ∅

psIC5 = {IC} ∆A5 = ∅E-fulfillment T �

b=10

��

��

�T �

b �=10

��

��

�

T6a = Ti ∆P 6a = ∅R6a = true ∆F 6a = {E(exec (b) , 10)}

CS6a =

T �a = 5,

T �b = 10,

10 > 5

∆V 6a = ∅

psIC6a = {IC} ∆A6a = ∅

closure

T6b = Ti ∆P 6b = {E(exec (b) , T �b)}

R6b = true ∆F 6b = ∅

CS6b =

T �a = 5,

T �b �= 10,

T �b > 5

∆V 6b = ∅

psIC6b = {IC} ∆A6b = ∅

closure and E-violation

SUCCESS ⊥(∆P 6b �= ∅)

Figure 1:

1

¡  Extends the IFF proof procedure §  Is a general abductive proof procedure! ▪  The computed abductive explanation usually contain fulfilled, pending and violated expectations

§  New transitions ▪  Dynamic acquisition of events à reactivity ▪  CLP constraints ▪  E-‐consistency and universally quantified variables ▪ Manages the interplay between E and EN

▪  Fulfillment/violation of expectations ▪  “Close trace” transition

¡  Generative variant of SCIFF for static verification ¡  Extends SCIFF with a fulfiller transition

§  Smart encoding of the declarative rule E(X,T) à H(X,T)

¡  Generate intensional classes of compliant traces transforming positive expectations into happened events §  If at least one trace is generated, then the model is executable

¡  Simulation by abduction!!!

¡  SCIFF and g-‐SCIFF rely on §  Prolog §  CHR §  CLP(fd) or CLP(R)

¡  Fully implemented in §  SWI Prolog §  SICStus Prolog

¡  Freely downloadable from http://www.lia.deis.unibo.it/sciff

execution

diagnosis

des

ign

&im

ple

men

t.

des

ign

&im

ple

men

t.

feedback

model

executiontraces

182 8 Static Verification of Declarative Open Interaction Models

model

Properties Verification

yes

no

property

(counter)example

Fig. 8.3. Verification of properties

8.3 Static Verification of Properties

Static verification tasks focusing on a single model are collected under the

umbrella of verification of properties, whose general schema is sketched in

Fig. 8.3. The broad problem of proving or disproving the correctness of a

model with respect to some property is usually called formal verification.

Properties formally capture requirements that must be covered by the system

under development. Requirements may differ from one another in nature and

purpose, and can be classified along different axes. For example, a requirement

may express that an external regulation must be fulfilled in every execution of

the system. Another requirement may capture a desired (hidden) dependency

among activities, which should be entailed by the model even if not explicitly

contained by it. In the following, we will focus on two fundamental dimensions:

existential vs universal and general vs particular properties.

It is worth noting that properties themselves are captured by means of

business constraints. Hence, when a property is expressible in ConDec, we

will use ConDec’s graphical notation to describe it. For example, a property

saying that “a receipt must be eventually sent” corresponds to the ConDec

constraint

1..∗

send receipt

8.3.1 Existential vs Universal Properties

When the modeler is interested in verifying whether the ConDec model un-

der development always meets a best practice of the company, the intended

meaning is that the property must be respected in any possible execution

of the system. Contrariwise, the reachability of a certain state of affairs is

guaranteed if there exists at least one execution which leads to that situation.

In general, properties quantify over execution traces in two complementary

ways: existential and universal.

Definition 8.3.1 (∃-entailment). A property Ψ is ∃-entailed by a ConDecmodel CM (CM |=∃ Ψ) if at least one execution trace supported by CM

¡  General “properties” verification: model’s executability §  Conflicts detection §  Discovery of dead activities

¡  Domain-‐dependent properties verification ¡  Composition of models

§  Composition of local models to realize a global interaction model

§  Conformance with a choreographic model à Specialized proofs

¡  Non-‐conflicting à supports the empty trace ¡  All activities are dead

8.5 Composing ConDec Models 189

comp (CM1, . . . , CMn) !! n"

i=1

Ai,n"

i=1

Cim,

n"

i=1

Cio

#

Definition 8.5.2 (Compatibility). Two ConDec models CM1 and CM2 arecompatible if their composition is conflict-free:

comp (CM1, CM2) |=! true

Obviously, the notion of compatibility can be generalized to the case of n localmodels. Incompatibility means that a subset of the n local models is conflict-ing. A precise identification of the conflicting local models would require tobuild and check all the 2n"1 possible compositions.

Compatibility verification is the first fundamental step in the evaluation ofthe feasibility of the composition, but it must be followed by the verificationof further properties, starting from the discovery of dead activities to theevaluation of domain-dependent requirements. The following example pointsout this issue.

Example 8.5.1 (Trivial compatibility). A modeler wants to investigate whetherthe two models

CM1 = a •=="• b CM2 = b •!!"• c •!!!!" a

can be composed. The two models are compatible, because they both supportthe empty execution trace. Hence, it would seem that a composition can beactually built. However, let us take a look at the composite model:

comp$CM1, CM2

%!

! "

#

It is apparent that no activity can be executed in the composition: a, b and care all dead activities.

In general, if none of the local models contains goal-oriented ConDec con-straints (see p. 51), compatibility always returns a positive answer, becausethe empty execution trace is supported by all local models.

Compatibility verification must be therefore followed by further tests,aimed at answering to questions like: “Are all activities of the local mod-els still executable in the composition?”, “Does the composition e!ectivelyachieve the business goals which motivated its realization?”, “Does the com-position respect the regulations and norms of each involved party?”. Thesequestions can be answered by means of properties verification on the global,composite model. For example, an answer to the first question could be pro-vided by checking if the composition contains dead activities.

8.5 Composing ConDec Models 189

comp (CM1, . . . , CMn) !! n"

i=1

Ai,n"

i=1

Cim,

n"

i=1

Cio

#

Definition 8.5.2 (Compatibility). Two ConDec models CM1 and CM2 arecompatible if their composition is conflict-free:

comp (CM1, CM2) |=! true

Obviously, the notion of compatibility can be generalized to the case of n localmodels. Incompatibility means that a subset of the n local models is conflict-ing. A precise identification of the conflicting local models would require tobuild and check all the 2n"1 possible compositions.

Compatibility verification is the first fundamental step in the evaluation ofthe feasibility of the composition, but it must be followed by the verificationof further properties, starting from the discovery of dead activities to theevaluation of domain-dependent requirements. The following example pointsout this issue.

Example 8.5.1 (Trivial compatibility). A modeler wants to investigate whetherthe two models

CM1 = a •=="• b CM2 = b •!!"• c •!!!!" a

can be composed. The two models are compatible, because they both supportthe empty execution trace. Hence, it would seem that a composition can beactually built. However, let us take a look at the composite model:

comp$CM1, CM2

%!

! "

#

It is apparent that no activity can be executed in the composition: a, b and care all dead activities.

In general, if none of the local models contains goal-oriented ConDec con-straints (see p. 51), compatibility always returns a positive answer, becausethe empty execution trace is supported by all local models.

Compatibility verification must be therefore followed by further tests,aimed at answering to questions like: “Are all activities of the local mod-els still executable in the composition?”, “Does the composition e!ectivelyachieve the business goals which motivated its realization?”, “Does the com-position respect the regulations and norms of each involved party?”. Thesequestions can be answered by means of properties verification on the global,composite model. For example, an answer to the first question could be pro-vided by checking if the composition contains dead activities.

¡  ConDec à CLIMB translation ¡  g-‐SCIFF finds a supported trace à no conflict! ¡  All types of verification are reduced to conflicts detection §  Existential entailment of a property ▪  Model augmented with the property

§  Universal entailment of a property ▪  Model augmented with the negated property

§  If the resulting model supports at least one trace, then the property is (not) entailed

¡  Does the model support a scenario in which the user chooses the “1-‐click” payment modality without accepting advertising?

payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..1

¡  Does the model support a scenario in which the user chooses the “1-‐click” payment modality without accepting advertising?

payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..10 1..*

¡  Goal: E(1-‐click, Tc) /\ EN(accept_advert,Ta)

payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..10 1..*


payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..10 1..*

H(1-‐click, Tc)

fulfiller


payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..10 1..*

H(1-‐click, Tc)

fulfiller

E(register, Tr), Tr < Tc, E(close_order, To), To < Tc

“precedence” triggering


payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..10 1..*

H(1-‐click, Tc)

fulfiller



fulfiller

H(register, Tr), Tr < Tc


payment failure

choose item

standard payment

1-click payment

payment done

sendreceipt

accept advert

closeorder

register

0..1

0..10 1..*

H(1-‐click, Tc)

fulfiller



fulfiller

H(register, Tr), Tr < Tc “responded existence”

triggering

E(accept_advert, Ta2)

E-‐inconsistency! (Ta universally quantified)

Answer: NO!

¡  ConDec à LTL Translation ¡  Verification of properties reduced to LTL satisfiability checking §  Existential entailment: §  Universal entailment:

¡  Satisfiability can be reduced to model checking [Rozier and Vardi, 2007] §  Formula checked against a “universal transition system”

264 11 Experimental Evaluation

Definition 11.3.2 (∀-entailment in LTL). A ConDec model CM ∀-entailsan LTL property ϕ (tLTL (CM) |=∀ ϕ) if and only if:

∀TL�TL |=L

��tLTL (CM) ∧ term(CM)

�=⇒ ϕ

��

Note that if also the property is specified in ConDec, then we can seamlesslycompose it with the model under study, before applying the translation func-tion. Indeed, from the definitions of ConDec composition and of tLTL, it holdsthat, given a ConDec model CM and a ConDec property Ψ :

tLTL (CM) ∧ tLTL (Ψ) ⇐⇒ tLTL (comp(CM, Ψ))

11.3.2 ConDec Properties Verification as Satisfiability andValidity Problems

We introduce the satisfiability and validity of an LTL formula.

Definition 11.3.3 (Satisfiability). An LTL formula ϕ is satisfiable if andonly if there exists at least one LTL trace which entails the formula:

sat(ϕ) � ∃TL�TL |=L φ

�

Definition 11.3.4 (Validity). An LTL formula ϕ is valid if and only if allpossible LTL traces satisfy the formula:

val(ϕ) � ∀TL�TL |=L φ

�

Satisfiability and validity can then directly accommodate the notions of ∃-and ∀-entailment. Conflict detection is a specific case of ∃-entailment.

Theorem 11.3.1 (ConDec conflict in terms of LTL satisfiability). AConDec model CM is conflict-free if and only if

sat�

tLTL (CM) ∧ term (CM)�

Proof. Straightforward from the definitions of satisfiability (Def. 11.3.3) andof LTL-based ∃-entailment (Def. 11.3.1), considering a true property. ��

Theorem 11.3.2 (∃-entailment in terms of LTL satisfiability).A ConDec model CM ∃-entails a ConDec property Ψ if and only if

sat�

tLTL (CM) ∧ term (CM) ∧ tLTL (Ψ)�

Proof. Straightforward from the definitions of satisfiability (Def. 11.3.3) andof LTL-based ∃-entailment (Def. 11.3.1). ��

11.3 Static Verification of ConDec Models as Model Checking 265

Theorem 11.3.3 (∀-entailment in terms of LTL validity). A ConDecmodel CM ∀-entails a ConDec property Ψ if and only if

val��


=⇒ tLTL (Ψ)�

Proof. Straightforward from the definitions of validity (Def. 11.3.4) and ofLTL-based ∀-entailment (Def. 11.3.2). ��Example 11.3.1 (LTL-based discovery of dead activities). Let us consider thelooping ConDec model Loop shown in Fig. 10.4, p. 245 – left side. Supposethat the modeler wants to know whether activity d is dead or not. The problemconsists in verifying if the ConDec model ∀-entails the absence of d, which istranslated into LTL as �¬d. This problem in turns reduces to check whetherthe formula

tLTL (Loop) ∧ term (CM) =⇒ �¬d

is valid. The answer is positive, and attests that there does not exist a finiteexecution trace supported by the model which contains d.

If we had erroneously forgot to take into account the term (CM) property,then a wrong answer would be produced: the formula

tLTL (CM) =⇒ �¬d

is not valid, because the infinite-length trace d → c → a → b → c → . . . con-tains an execution of activity d. Clearly, the trace respects all the constraintsof the model, but it is however not finitely supported by the model.

As in the case of g-sciff, in LTL it holds that ∀-entailment can be reducedto ∃-entailment. Differently from g-sciff, the reduction simply requires tonegate the property, without requiring to find an explicit complementation. Infact, satisfiability and validity are intimately connected: a formula ϕ is validif its negation is unsatisfiable, i.e. val(φ) ⇐⇒ ¬sat(¬φ).

Theorem 11.3.4 (Reduction of ∀-entailment to ∃-entailment in LTL).A ConDec model CM ∀-entails a ConDec property Ψ if and only if it does not∃-entail the negation of tLTL (Ψ), i.e., if and only if

¬sat�

tLTL (CM) ∧ ¬ tLTL (Ψ) ∧ term (CM)�

Proof.

tLTL (CM) |=∀ tLTL (Ψ) ⇐⇒ (Def. 11.3.2)

val��


=⇒ tLTL (Ψ)�⇐⇒

¬sat�¬

��tLTL (CM) ∧ term (CM)

�=⇒ tLTL (Ψ)

��⇐⇒

¬sat�

tLTL (CM) ∧ term (CM) ∧ ¬ tLTL (Ψ)��⇐⇒ (Def. 11.3.1)

tLTL (CM) �|=∃ ¬ tLTL (Ψ) ��

¡  Comparison §  g-‐SCIFF §  NuSMV ▪  best model checker for sat [Rozier and Vardi, 2007]

§  (also Zot, LTL metric sat checker) ¡  Benchmark stressing two aspects

§  Number of constraints (N) §  Number of times some activity must be executed (K)

¡  Model checking: state explosion problem §  Translation onto automaton exponential in the size of the formula

§  The system itself is modeled with a formula! §  OBDDs partially mitigate the problem

¡  NuSMV: predictable degradation ¡  g-‐SCIFF: performance highly dependent on the

instance (focuses on triggered constraints only) ¡  g-‐SCIFF experiences a more graceful degradation as N

increases ¡  NuSMV experiences a more graceful degradation as K

increases

¡  g-‐SCIFF is sound ¡  g-‐SCIFF terminates and is

complete if the specification is acyclic and bounded

➔ When the ConDec model loops, g-‐SCIFF may not terminate

Conflicting model! ¡  Ad-‐hoc algorithms for the identification and

treatment of loops

Semi-‐decidability

!!!

ba1..*

model

run-time

reasoning

partial

trace

info

execution

diagnosis

des

ign

&im

ple

men

t.

des

ign

&im

ple

men

t.

feedback

model

executiontraces

¡  ConDec model as a public global contract §  Autonomous entities cannot be controlled §  Hence they cannot be trusted §  Even in presence of static information about their behavior ▪  Unpredictable behaviors (e.g. when an exception is encountered) ▪  Implementation mismatches

§  Operational decision support ¡  Enactment of a ConDec model

§  Support to the interacting entities §  Generation of currently pending constraints and forbidden activities

¡  SCIFF Proof Procedure §  ConDec model à regulatory global contract §  Evolution of the interaction à partial trace

¡  Reasoning is driven by the occurring events §  Chaining of rules “mediated” by the trace

¡  Sound, complete, and always terminates §  For ConDec++, iff the static knowledge base is acyclic

¡  Continuous support §  Autonomous system à could continue the execution even in presence of a violation

¡  Feedback about the state of affairs §  Status of business constraints §  Alarms/exceptional situation

¡  Limits of SCIFF §  No continuous support ▪  Violations are bound to logical inconsistency ▪  Strong notion of violation: no optional “soft” constraints

§  No explicit representation of the constraints’ “status”

¡  A logic-‐based framework for reasoning about §  Time (quantitative and explicit, as in SCIFF)

§  Events and execution traces §  Effects of events

¡  Focus: properties that vary over time (fluents) ¡  Fluents’ validity is manipulated by the execution of events §  They initiate/terminate fluents

¡  Events: execution of activities ¡  Formalization: effect of events in terms of constraints’

instances ¡  Fluents: constraint instances’ states

§  Pending à the instance is waiting for an event occurrence §  Satisfied à the instance is currently satisfied §  Violated à the instance has been violated

¡  Example: response(A, B) with deadline §  Every execution of A generates a pending instance §  If B occurs within the deadline, the instance becomes permanently satisfied

§  If the deadline expires, the instance becomes violated

¡  EC can be axiomatized in LP + NAF §  Deductive reasoning ▪  Input: a trace and an EC specification ▪  Output: fluents’ validity intervals

¡  Is deductive reasoning suitable for monitoring? §  NO: reasoning must be restarted from scratch every time the trace is updated

¡  Reactive forms of reasoning are needed

¡  Lack of reactive reasoners §  Ad-‐hoc algorithms for EC-‐based monitoring ▪  No semantics ▪  Limited expressiveness

¡  Solutions §  Cached Event Calculus [Chittaro and Montanari, 1996] ▪  Prolog axiomatization which caches the outcome of reasoning for future use

▪  Caching by means of assert/retract à no declarative semantics

§  Reactive Event Calculus [Chesani et al., 2010] ▪  Inspired by CEC ▪  Caching by aduction à fully declarative!

¡  Show §  Pending constraints §  Forbidden activities

¡  Hidden dependencies!

a b c d e0..11..*

Initial state



“a” executed

a b c d e0..11..*



“b” executed

a b c d e0..11..*



“c” executed

a b c d e0..11..*

¡  Hidden dependencies à dead activities ¡  Cannot be discovered by SCIFF nor EC

§  Event-‐driven reasoning §  Combination of constraints not exploited

¡  g-‐SCIFF is able to discover them ¡  g-‐SCIFF can be applied with a partial trace as input ➔ SCIFF/EC for reasoning about the past&present ➔ g-‐SCIFF for reasoning about the future

log

process

mininginfo

execution

diagnosis

des

ign

&im

ple

men

t.

des

ign

&im

ple

men

t.

feedback

model

executiontraces

¡  Extraction of relevant information from event logs

(un)desiredproperties

interactionmodelrecords

event log

refers to modelssystem

Log-based verification

Conformance checking

Discovery

¡  SCIFF can perform trace analysis

¡  For CLIMB specifications à reasoning can be performed in Prolog

Trace Analyzer

Business rule

Log

¡  FIRB TOCAI.IT à Think3 §  Compliance verification w.r.t. regulations and best practices

¡  Screening Protocols in Emilia Romagna §  Conformance of the actual application of the protocol to the regional guidelines

¡  Wastewater decision support system §  Event logs containing physical signals events §  Identification of the purification phase

¡  Declarative Process Discovery ¡  Given two sets of traces

§  Good traces §  Bad traces

¡  Discovery of a constraint-‐based model which correctly discriminates the two sets

¡  Inductive Logic Programming techniques §  Induction of a SCIFF model §  Tuning the language bias à induction of CLIMB constraints à inverse translation à ConDec!

¡  CLIMB is a suitable tool to §  Formalize interaction models ▪  With a declarative and open flavor ▪  Mediating between expressiveness and applicability

§  Provide reasoning capabilities along the entire systems’ lifecycle

¡  Meets the fundamental requirements for dealing with open systems. It is… §  Declarative §  Meaningful §  Formal §  Verifiable

¡  Operational Decision Support ¡  Integration between regulative and constitutive aspects in interaction models §  Business Constraints §  Social Commitments

¡  Generation of compliant-‐by-‐design procedural models

paychooseitem

sms receipt

e-mail receipt

null

active

satisfied violated

discharge cancel (after 20 t.u.)

create

ConDec (flow) constraints Social CommitmentsEvents ↔ Effects

C(seller,customer,receiptDelivered)

¡  CLIMB §  Marco Montali. Specification and Verification of Declarative Open Interaction Models: a Logic-‐

Based Approach. Vol. 56 of Lecture Notes in Business Information Processing, Springer, 2010. ¡  Open Declarative Modeling

§  Marco Montali, Maja Pesic, W. M. P. van der Aalst, Federico Chesani, Paola Mello, and Sergio Storari. Declarative Specification and Verification of Service Choreographies. ACM Transactions on the Web, Vol. 4(1), 2010.

§  Federico Chesani, Paola Mello, Marco Montali, Sergio Storari, and Paolo Torroni. On the Integration of Declarative Choreographies and Commitment-‐ based Agent Societies into the SCIFF Logic Programming Framework. Multiagent and Grid Systems, Special Issue on Agents, Web Services and Ontologies: Integrated Methodologies, 6(2), 2010.

§  Alessio Bottrighi, Federico Chesani, Paola Mello, Gianpaolo Molino, Marco Montali, Stefania Montani, Sergio Storari, Paolo Terenziani, Mau-‐ ro Torchio. A Hybrid Approach to Clinical Guideline and to Basic Medical Knowledge Conformance. In C. Combi, Y. Shahar and A. Abu-‐ Hanna, editors, Proceedings of the 12th International Conference on Artificial Intelligence in Medicine (AIME 2009), Vol. 5651 of LNCS, pages 91–95. Springer, 2009. ISBN: 978-‐3-‐642-‐02975-‐2.

§  Federico Chesani, Paola Mello, Marco Montali, and Paolo Torroni. Declarative Technologies for Open Agent Systems and Beyond. In Proceedings of the 4th KES International Symposium on Agent and Multi-‐ Agent Systems: Technologies and Applications (KES-‐AMSTA 2010), Vol. 6070 of LNCS, Springer, 2010.

¡  Static Verification §  Marco Montali, Paolo Torroni, Marco Alberti, Federico Chesani, Marco

Gavanelli, Evelina Lamma, and Paola Mello. Verification from Declara-‐ tive Specifications Using Logic Programming. In M. Garcia De La Banda and E. Pontelli, editors, 24th International Conference on Logic Programming (ICLP2008), Vol. 5366 of LNCS, pages 440–454. Sprin-‐ ger, 2008.

§  Marco Montali, Paolo Torroni, Marco Alberti, Federico Chesani, Evelina Lamma, and Paola Mello. Abductive Logic Programming as an Effective Technology for the Static Verification of Declarative Business Processes. Special Issue of Fundamenta Informaticae, 102 (3-‐4) 325–361, IOS Press.

§  Federico Chesani, Paola Mello, Marco Montali and Paolo Torroni. Veri-‐ fying a-‐Priori the Composition of Declarative Specified Services. In Proceedings of the 2nd Multi-‐Agent Logics, Languages, and Organisations Federated Workshops (MALLOW), International Workshop on Agents, Web Services and Ontologies, Integrated Methodologies, 2009. Vol. 494 of CEUR Workshop Proceedings, 2009.

¡  Run-‐time Verification, Monitoring and (Reactive) Event Calculus §  Marco Alberti, Federico Chesani, Evelina Lamma, Marco Gavanelli, Pao-‐ la Mello, Marco

Montali, Sergio Storari, and Paolo Torroni. Computatio-‐ nal Logic for the Run-‐time Verification of Web Service Choreographies: Exploiting the SOCS-‐SI Tool. In M. Bravetti, M. Nu`n ez, and G. Zavattaro, editors, Proceedings of the 3rd International Workshop on Web Services and Formal Methods (WS-‐FM’06), volume 4184 of LNCS, pages 58–72. Springer, 2006.

§  Federico Chesani, Paola Mello, Marco Montali, and Paolo Torroni. A Logic-‐Based, Reactive Calculus of Events. Special Issue of Fundamenta Informaticae, 104 1–27, IOS Press. To appear (expected 2011).

§  Federico Chesani, Paola Mello, Marco Montali, and Paolo Torroni. Verification of Choreographies During Execution Using the Reactive Event Calculus. In R. Bruni, K. Wolf, editors, Proceedings of the 5th International Workshop on Web Service and Formal Methods (WS-‐ FM2008), volume 5387 of LNCS, pages 129–140. Springer, 2009.

§  Federico Chesani, Paola Mello, Marco Montali, and Paolo Torroni. Commitment Tracking via the Reactive Event Calculus. In C. Boutilier, editor, Proceedings of the 21th International Joint Conference on Ar-‐ tificial Intelligence (IJCAI-‐09), pages 91–96, 2009.

§  Federico Chesani, Paola Mello, Marco Montali, and Paolo Torroni. Monitoring Time-‐Aware Social Commitments with Reactive Event Calculus. In Proceedings of the 7th International Symposium “From Agent Theory to Agent Implementation”, Austrian Cybernetics Studies, 2010. Best Paper Award.

¡  Log Analysis §  Federico Chesani, Paola Mello, Marco Montali, Fabrizio Riguzzi, Mau-‐ rizio Sebastianis, and

Sergio Storari. Checking Compliance of Execution Traces to Business Rules. In D. Ardagna and M. Mecella and J. Yang, editors, International Workshop on Business Intelligence, Proceedings of BPM 2008 Workshops, Vol. 17 of LNBIP, pages 134–145, Springer, 2009.

§  Luca Luccarini, Gianni Luigi Bragadin, Gabriele Colombini, Maurizio Mancini, Paola Mello, Marco Montali, and Davide Sottara. Formal Verification of Wastewater Treatment Processes using Events detected from continuous signals by means of Artificial Neural Networks. Environmental Modelling and Software, 2009.

§  Federico Chesani, Evelina Lamma, Paola Mello, Marco Montali, Sergio Storari, Paola Baldazzi, and Marilena Manfredi. Compliance Checking of Cancer-‐Screening Careflows: an Approach Based on Computational Logic. In A. ten Teije, S. Miksch, and P. Lucas, editors, Computer-‐ Based Medical Guidelines and Protocols: a Primer and Current Trends. IOS Press, 2008.

¡  Declarative Process Discovery §  Evelina Lamma, Paola Mello, Marco Montali, Fabrizio Riguzzi, and Ser-‐ gio Storari. Inducing

Declarative Logic-‐Based Models from Labeled Traces. In M. Rosemann and M. Dumas, editors, Proceedings of the 5th International Conference on Business Process Management (BPM 2007), Vol. 4714 of LNCS, pages 344–359. Springer Verlag, 2007.

§  Federico Chesani, Evelina Lamma, Paola Mello, Marco Montali, Fabrizio Riguzzi, and Sergio Storari. Exploiting Inductive Logic Programming Techniques for Declarative Process Mining. LNCS Transactions on Petri Nets and Other Models of Concurrency (ToPNoC), Special Issue on Concurrency in Process-‐Aware Information Systems, 5460:278– 295, 2009.

Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction...

Presentations & Public Speaking

Transcript of Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction...