Date post: | 09-Jan-2017 |
Category: |
Presentations & Public Speaking |
Upload: | marco-montali |
View: | 56 times |
Download: | 1 times |
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
REASONINGCAPABILITIES
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
REASONINGCAPABILITIES
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, 5),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)
{ E(ev, 8),EN(ev, 6),EN(ev, 7) } (E-consistent)
{ E(ev, 9),EN(ev, 6),EN(ev, 7) } (E-consistent)
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).
¡ 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
EvaluationBank Target
failed(Evaluation) add to.O = diligence.O/\ add to.Target = diligence.Bank
(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
Level < 70test glucose.Patient = eat.O
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
type(Code, 'no-food')
Food
(0,8]
eat.O = test.Patient
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
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.
¡ 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..*
¡ 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..*
H(1-‐click, Tc)
fulfiller
¡ 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..*
H(1-‐click, Tc)
fulfiller
E(register, Tr), Tr < Tc, E(close_order, To), To < Tc
“precedence” triggering
¡ 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..*
H(1-‐click, Tc)
fulfiller
E(register, Tr), Tr < Tc, E(close_order, To), To < Tc
“precedence” triggering
fulfiller
H(register, Tr), Tr < Tc
¡ 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..*
H(1-‐click, Tc)
fulfiller
E(register, Tr), Tr < Tc, E(close_order, To), To < Tc
“precedence” triggering
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 (CM) ∧ term (CM)�
=⇒ 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 (CM) ∧ term (CM)�
=⇒ 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
¡ Show § Pending constraints § Forbidden activities
¡ Hidden dependencies!
“a” executed
a b c d e0..11..*
¡ Show § Pending constraints § Forbidden activities
¡ Hidden dependencies!
“b” executed
a b c d e0..11..*
¡ Show § Pending constraints § Forbidden activities
¡ Hidden dependencies!
“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.