Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Marco	
  Montali	
  
University	
  of	
  Bologna	
  
Bolzano,	
  15/12/2010	
  
¡  Interaction	
  Models	
  
§  Declarativeness	
  and	
  Openness	
  
¡  Requirements	
  for	
  a	
  supporting	
  fra...
¡  In	
  many	
  emerging	
  settings…	
  
§  Distribution	
  of	
  activities	
  and	
  resources	
  
▪ To	
  attack	
 ...
¡  From	
  the	
  internal	
  implementation	
  
of	
  a	
  single	
  component…	
  
¡  …	
  to	
  the	
  interaction	
 ...
Participants	
   Events	
   Interaction	
  
Model	
  
Main	
  Challenge	
  
Employees	
  	
  
External	
  stakeholders	
  ...
¡  Interaction	
  modeling	
  languages	
  for	
  open	
  systems	
  
must	
  be	
  	
  able	
  to	
  balance	
  between	...
¡  Closed	
  and	
  procedural	
  modeling	
  abstractions	
  
Closed	
  approaches	
  
All	
  that	
  is	
  not	
  explicitly	
  modeled	
  is	
  
forbidden	
  
	
  
Open	
  approaches...
¡  Non-­‐ordered	
  constraint	
  
¡  Closed	
  procedural	
  approach:	
  explicit	
  encoding	
  of	
  
all	
  the	
  ...
¡  Empty	
  workflow	
  
¡  The	
  following	
  
¡  Many	
  compliant	
  traces	
  not	
  supported	
  
à	
  over-­‐con...
Seller
refuse
order
refuse
order
...
Warehouse
refuse
shipment
refuse
shipment
... ...
...
decision driven
by the seller
?...
Exception
(complete)
187
EstabelecimentoNotFoundException
(complete)
187
0,991
152
GREJBPersistencyException
(complete)
17...
¡  Focused	
  on	
  (business)	
  constraints	
  
¡  Define	
  the	
  “behavioral	
  boundaries”	
  
§  Supported	
  tra...
knowledge
level
business constraints
design
level
legislation
procedural
model
declarative
model
policies
regulations
busi...
¡  Usability	
  (by	
  non-­‐IT	
  savvy)	
  
	
  
	
  
¡  Support	
  along	
  the	
  entire	
  system’s	
  lifecycle	
 ...
internal
life cycle
third party
life cycle
diagnosis
design
execution
execution
diagnosis
design
runtime verification
stati...
Computational	
  	
  	
  
Logic	
  for	
  the	
  
Ification	
  and	
  	
  
Modeling	
  of	
  	
  
Business	
  
	
  	
  	
  ...
REASONING
CAPABILITIES
GRAPHICAL
MODELING
system
formal
specification
ba
c
(extended)
ConDec
CLIMB
Translation
SCIFF
Framew...
¡  ConDec	
  =	
  Constraints,	
  Declarative	
  
¡  Graphical	
  notation	
  
¡  Model	
  =	
  activities	
  +	
  busi...
¡  First	
  step:	
  activities	
  elicitation	
  
§  Completely	
  open	
  model	
  
choose
item
standard
payment
1-cli...
¡  Second	
  step:	
  constraints	
  elicitation	
  
§  Partial	
  closure	
  of	
  the	
  model:	
  supported	
  traces...
Response	
  
Every	
  time	
  A	
  is	
  executed,	
  B	
  
should	
  be	
  executed	
  afterwards	
  
Alternate	
  respon...
CUSTOMER	
   SELLER	
   WAREHOUSE	
  
commit
order
confirm
order
refuse
order
confirm
shipment
refuse
shipment
REASONING
CAPABILITIES
GRAPHICAL
MODELING
system
formal
specification
ba
c
(extended)
ConDec
CLIMB
Translation
SCIFF
Framew...
LTL	
  
ConDec	
  
[Pesic	
  and	
  van	
  der	
  Aalst,	
  2006]	
  
¡  ConDec	
  execution	
  traces	
  à	
  LTL	
  models	
  
¡  ConDec	
  model	
  M	
  à	
  LTL	
  “conjunction“	
  for...
¡  The	
  system	
  itself	
  is	
  modeled	
  as	
  a	
  formula!!!	
  
portion of the ConDec model shown in Fig. 3.2, n...
CLIMB/SCIFF	
  	
  LTL	
  
ConDec	
  
[Pesic	
  and	
  van	
  der	
  Aalst,	
  2006]	
  
¡  Developed	
  by	
  the	
  	
  
§  AI	
  group	
  at	
  DEIS,	
  University	
  of	
  Bologna	
  
§  AI	
  group	
  at...
(partial)
execution trace
CLIMB
specification
Expectations
Fulfillment
Abductive
explanations
CLIMB	
  specification:	
  	
  ...
¡  Happened	
  event	
  	
  
§  H(e,t)	
  à	
  event	
  e	
  occurs	
  at	
  time	
  t	
  (real	
  or	
  integer)	
  
§...
¡  Events	
  are	
  terms,	
  and	
  may	
  contain	
  variables	
  
¡  Times	
  are	
  variables	
  
¡  Variables	
  c...
¡  Prolog	
  KB	
  to	
  express	
  the	
  static	
  domain	
  knowledge	
  
¡  Integrity	
  constraints	
  to	
  constr...
¡  Every	
  time	
  a	
  premium	
  customer	
  sends	
  a	
  
request_info,	
  an	
  employee	
  is	
  expected	
  to	
 ...
¡  ICs	
  exploited	
  in	
  a	
  forward,	
  reactive	
  manner	
  
§  Occurring	
  events	
  match	
  with	
  the	
  h...
¡  Abductive	
  reasoning	
  
§  Reasoning	
  under	
  incomplete	
  knowledge	
  
§  Hypothesis	
  of	
  possible	
  e...
¡  CLIMB	
  specification	
  mapped	
  onto	
  an	
  Abductive	
  Logic	
  
Program	
  KB,	
  {E/2,	
  EN/2},	
  IC	
  
§...
¡  Semantics:	
  the	
  one	
  of	
  ALP	
  but…	
  
1)  Semantics	
  of	
  expectations	
  à	
  specialized	
  notion	
...
¡  A	
  (partial/complete)	
  trace	
  T	
  is	
  compliant	
  with	
  
a	
  CLIMB	
  specification	
  S	
  	
  
	
  	
  	...
¡  Empty	
  KB	
  
¡  IC	
  
§  H(exec(d),T)	
  à	
  EN(exec(Y),T)	
  /	
  Y!=d.	
  
§  H(exec(a),T)	
  à	
  E(exec(...
¡  Empty	
  KB	
  
¡  IC	
  
§  H(exec(d),T)	
  à	
  EN(exec(Y),T)	
  /	
  Y!=d.	
  
§  H(exec(a),T)	
  à	
  E(exec(...
¡  Complete	
  trace:	
  
H(exec(a),1). 	
  H(exec(c),5). 	
  H(exec(d),5).	
  
¡  Two	
  minimal	
  E-­‐consistent	
  Δ...
¡  Complete	
  trace:	
  
H(exec(a),1). 	
  H(exec(c),5). 	
  H(exec(d),5).	
  
¡  Two	
  minimal	
  E-­‐consistent	
  Δ...
¡  Why?	
  
§  Language	
  motivation	
  
▪ High	
  expressiveness	
  
▪ Quantitative	
  and	
  explicit	
  notion	
  of...
¡  Very	
  intuitive	
  translation	
  
§  Activities	
  mapped	
  onto	
  CLIMB	
  events	
  
§  Constraints	
  formal...
payme
failure
choose
item
standard
payment
1-click
payment
payme
done
accept
advert
close
order
register
0..1
Simple	
  re...
payme
failure
choose
item
standard
payment
1-click
payment
payme
done
accept
advert
close
order
register
0..1
Timed	
  rel...
payme
failure
choose
item
standard
payment
1-click
payment
payme
done
accept
advert
close
order
register
0..1
Negation	
  ...
Response	
   H(a,	
  Ta)	
  	
  →	
  E(B,	
  Tb)∧Tb	
  	
  Ta.	
  
Alternate	
  
response	
  
H(a,	
  Ta)	
  	
  →	
  E(b,...
LTL
formula
CLIMB
specification
ba
c
tLTL tCLIMB
complies with
CLIMB trace
LTL
trace
ConDec Model
Real execution trace
tm
c...
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-N1
between(N...
¡  In	
  most	
  event	
  logs	
  (see	
  e.g.	
  BPMS)	
  
§  Activities	
  involve	
  data	
  and	
  roles	
  
§  Act...
¡  In	
  most	
  event	
  logs	
  (see	
  e.g.	
  BPMS)	
  
§  Activities	
  involve	
  data	
  and	
  roles	
  
§  Act...
¡  Atomic	
  activities	
  à	
  instantaneous	
  execution	
  
¡  Non-­‐atomic	
  activities	
  à	
  span	
  over	
  t...
¡  Non-­‐atomic	
  activities	
  require	
  event	
  correlation	
  
§  Each	
  tc	
  and	
  tx	
  must	
  be	
  associa...
REASONING
CAPABILITIES SCIFF
Framework
REASONING
CAPABILITIES SCIFF
Framework
GRAPHICAL
MODELING
system
formal
specificatio...
¡  Reactive	
  proof	
  procedure	
  
§  Triggered	
  by	
  the	
  acquisition	
  of	
  new	
  happened	
  events	
  
¡...
I(S, Ti)
T1 = Ti ∆P 1 = ∅
R1 = true ∆F 1 = ∅
CS1 = ∅ ∆V 1 = ∅
psIC1 = {IC} ∆A1 = ∅
propagation
T2 = Ti ∆P 2 = ∅
R2 = true ...
¡  Extends	
  the	
  IFF	
  proof	
  procedure	
  
§  Is	
  a	
  general	
  abductive	
  proof	
  procedure!	
  
▪  The	...
¡  Generative	
  variant	
  of	
  SCIFF	
  for	
  static	
  verification	
  
¡  Extends	
  SCIFF	
  with	
  a	
  fulfiller...
¡  SCIFF	
  and	
  g-­‐SCIFF	
  rely	
  on	
  
§  Prolog	
  
§  CHR	
  
§  CLP(fd)	
  or	
  CLP(R)	
  
¡  Fully	
  im...
execution
diagnosis
design
implement.
design
implement.
feedback
model
execution
traces
182 8 Static Verification of Declar...
¡  General	
  “properties”	
  verification:	
  model’s	
  
executability	
  
§  Conflicts	
  detection	
  
§  Discovery	
...
¡  Non-­‐conflicting	
  à	
  supports	
  the	
  empty	
  trace	
  
¡  All	
  activities	
  are	
  dead	
  
of further pr...
¡  ConDec	
  à	
  CLIMB	
  translation	
  
¡  g-­‐SCIFF	
  finds	
  a	
  supported	
  trace	
  à	
  no	
  conflict!	
  
...
¡  Does	
  the	
  model	
  support	
  a	
  scenario	
  in	
  which	
  the	
  user	
  
chooses	
  the	
  “1-­‐click”	
  pa...
¡  Does	
  the	
  model	
  support	
  a	
  scenario	
  in	
  which	
  the	
  user	
  
chooses	
  the	
  “1-­‐click”	
  pa...
¡  Goal:	
  E(1-­‐click,	
  Tc)	
  /	
  EN(accept_advert,Ta)	
  
choose
item
standard
payment
1-click
payment
accept
adve...
¡  Goal:	
  E(1-­‐click,	
  Tc)	
  /	
  EN(accept_advert,Ta)	
  
choose
item
standard
payment
1-click
payment
accept
adve...
¡  Goal:	
  E(1-­‐click,	
  Tc)	
  /	
  EN(accept_advert,Ta)	
  
choose
item
standard
payment
1-click
payment
accept
adve...
¡  Goal:	
  E(1-­‐click,	
  Tc)	
  /	
  EN(accept_advert,Ta)	
  
choose
item
standard
payment
1-click
payment
accept
adve...
¡  Goal:	
  E(1-­‐click,	
  Tc)	
  /	
  EN(accept_advert,Ta)	
  
choose
item
standard
payment
1-click
payment
accept
adve...
¡  ConDec	
  à	
  LTL	
  Translation	
  
¡  Verification	
  of	
  properties	
  reduced	
  to	
  LTL	
  
satisfiability	
...
¡  Comparison	
  
§  g-­‐SCIFF	
  
§  NuSMV	
  
▪  best	
  model	
  checker	
  for	
  sat	
  [Rozier	
  and	
  Vardi,	
...
¡  Model	
  checking:	
  state	
  explosion	
  problem	
  
§  Translation	
  onto	
  automaton	
  exponential	
  in	
  t...
¡  g-­‐SCIFF	
  is	
  sound	
  
¡  g-­‐SCIFF	
  terminates	
  and	
  is	
  	
  
complete	
  if	
  the	
  specification	
 ...
model
run-time
reasoning
partial
trace
info
execution
diagnosis
design
implement.
design
implement.
feedback
model
executi...
¡  ConDec	
  model	
  as	
  a	
  public	
  global	
  contract	
  
§  Autonomous	
  entities	
  cannot	
  be	
  controlle...
¡  SCIFF	
  Proof	
  Procedure	
  
§  ConDec	
  model	
  à	
  regulatory	
  global	
  contract	
  
§  Evolution	
  of	...
¡  Continuous	
  support	
  
§  Autonomous	
  system	
  à	
  could	
  continue	
  the	
  execution	
  
even	
  in	
  pr...
¡  A	
  logic-­‐based	
  framework	
  for	
  reasoning	
  about	
  
§  Time	
  (quantitative	
  and	
  explicit,	
  as	
...
¡  Events:	
  execution	
  of	
  activities	
  
¡  Formalization:	
  effect	
  of	
  events	
  in	
  terms	
  of	
  const...
¡  EC	
  can	
  be	
  axiomatized	
  in	
  LP	
  +	
  NAF	
  
§  Deductive	
  reasoning	
  
▪  Input:	
  a	
  trace	
  a...
¡  Lack	
  of	
  reactive	
  reasoners	
  
§  Ad-­‐hoc	
  algorithms	
  for	
  EC-­‐based	
  monitoring	
  
▪  No	
  sem...
¡  Show	
  
§  Pending	
  constraints	
  
§  Forbidden	
  activities	
  
¡  Hidden	
  dependencies!	
  
a b c d e
0..1...
¡  Show	
  
§  Pending	
  constraints	
  
§  Forbidden	
  activities	
  
¡  Hidden	
  dependencies!	
  
“a”	
  execute...
¡  Show	
  
§  Pending	
  constraints	
  
§  Forbidden	
  activities	
  
¡  Hidden	
  dependencies!	
  
“b”	
  execute...
¡  Show	
  
§  Pending	
  constraints	
  
§  Forbidden	
  activities	
  
¡  Hidden	
  dependencies!	
  
“c”	
  execute...
¡  Hidden	
  dependencies	
  à	
  dead	
  activities	
  
¡  Cannot	
  be	
  discovered	
  by	
  SCIFF	
  nor	
  EC	
  
...
log
process
mining
info
execution
diagnosis
design
implement.
design
implement.
feedback
model
execution
traces
¡  Extraction	
  of	
  relevant	
  information	
  from	
  event	
  logs	
  
(un)desired
properties
interaction
modelrecor...
¡  SCIFF	
  can	
  perform	
  trace	
  analysis	
  
¡  For	
  CLIMB	
  specifications	
  à	
  reasoning	
  can	
  be	
  ...
¡  FIRB	
  TOCAI.IT	
  à	
  Think3	
  
§  Compliance	
  verification	
  w.r.t.	
  regulations	
  and	
  best	
  
practic...
¡  Declarative	
  Process	
  Discovery	
  
¡  Given	
  two	
  sets	
  of	
  traces	
  
§  Good	
  traces	
  
§  Bad	
 ...
!
¡  CLIMB	
  is	
  a	
  suitable	
  tool	
  to	
  
§  Formalize	
  interaction	
  models	
  
▪  With	
  a	
  declarative	...
¡  Operational	
  Decision	
  Support	
  
¡  Integration	
  between	
  regulative	
  and	
  constitutive	
  
aspects	
  ...
¡  CLIMB	
  
§  Marco	
  Montali.	
  Specification	
  and	
  Verification	
  of	
  Declarative	
  Open	
  Interaction	
  M...
¡  Static	
  Verification	
  
§  Marco	
  Montali,	
  Paolo	
  Torroni,	
  Marco	
  Alberti,	
  Federico	
  Chesani,	
  M...
¡  Run-­‐time	
  Verification,	
  Monitoring	
  and	
  (Reactive)	
  Event	
  Calculus	
  
§  Marco	
  Alberti,	
  Federi...
¡  Log	
  Analysis	
  
§  Federico	
  Chesani,	
  Paola	
  Mello,	
  Marco	
  Montali,	
  Fabrizio	
  Riguzzi,	
  Mau-­‐...
Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction Models
Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction Models
Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction Models
Upcoming SlideShare
Loading in …5
×

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

170 views

Published on

Invited seminar on "Specification and Verification of Declarative Open Interaction Models" at the KRDB Research Centre for Knowledge and Data, Faculty of Computer Science, Free University of Bozen-Bolzano (Italy), 15/12/2010.

  • Be the first to comment

  • Be the first to like this

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

  1. 1. Marco  Montali   University  of  Bologna   Bolzano,  15/12/2010  
  2. 2. ¡  Interaction  Models   §  Declarativeness  and  Openness   ¡  Requirements  for  a  supporting  framework   ¡  Specification:  ConDec   ¡  Formalization   §  LTL   §  ALP  (CLIMB)   ¡  Reasoning   §  Static  verification   §  Run-­‐time  support   §  Process  mining  
  3. 3. ¡  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  
  4. 4. ¡  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  
  5. 5. 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  
  6. 6. ¡  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
  7. 7. ¡  Closed  and  procedural  modeling  abstractions  
  8. 8. 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  
  9. 9. ¡  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  
  10. 10. ¡  Empty  workflow   ¡  The  following   ¡  Many  compliant  traces  not  supported   à  over-­‐constrained  model   SellerWarehouse refuse shipment refuse order ... ...... ...
  11. 11. Seller refuse order refuse order ... Warehouse refuse shipment refuse shipment ... ... ... decision driven by 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?    
  12. 12. Exception (complete) 187 EstabelecimentoNotFoundException (complete) 187 0,991 152 GREJBPersistencyException (complete) 179 0,909 159 PGWSException (complete) 168 0,889 12 ITPTExternalServiceException (complete) 183 0,944 162 SIPSCNoRecordsFoundException (complete) 160 0,8 5 PessoaSingularNotFoundException (complete) 138 0,667 3 BusinessLogicException (complete) 183 0,75 4 SICCLException (complete) 175 0,857 19 NaoExistemRegistosException (complete) 143 0,833 6 RPCBusinessException (complete) 38 0,75 3 SAFBusinessException (complete) 115 0,8 68 GREJBBusinessException (complete) 45 0,75 23 DESWSException (complete) 14 0,667 14 NullPointerException (complete) 104 0,8 91 ValidationException (complete) 31 0,8 12 GILBusinessException (complete) 14 0,5 6 GRServicesException (complete) 7 0,667 3 CSIBusinessException (complete) 14 0,5 6 ConcorrenciaException (complete) 5 0,5 2 CSIPersistencyException (complete) 3 0,5 2 0,857 34 ITPTServerException (complete) 21 0,667 15 COOPException (complete) 4 0,5 2 RSIValidationException (complete) 25 0,667 18 BasicSystemException (complete) 16 0,667 11 PesquisaAmbiguaException (complete) 6 0,5 6 CPFBusinessException (complete) 3 0,5 2 0,8 95 ADOPException (complete) 6 0,5 5 AFBusinessException (complete) 64 SIPSCRemoteBusinessException (complete) 51 0,833 13 ConcurrentModificationException (complete) 5 0,5 1 CDFBusinessException (complete) 6 0,667 2 AssinaturaNaoIncluidaException (complete) 1 0,5 1 SICCSException (complete) 32 0,8 11 CartaoCidadaoException (complete) 64 0,833 38 SOAPException (complete) 22 0,667 14 TooManyRowsException (complete) 112 0,667 18 SIPSCFatalException (complete) 20 0,667 9 LimiteTemporalException (complete) 4 0,5 2 0,8 28 SVIBusinessUserException (complete) 18 0,75 12 GRConcurrencyException (complete) 8 0,5 2 ContribuinteRegionalNotFoundException (complete) 63 0,75 30 JDOFatalUserException (complete) 124 0,947 49 0,667 5 SQLException (complete) 9 0,667 7 IOException (complete) 27 0,75 22 PessoaColectivaNotFoundException (complete) 23 0,75 20 ServiceDelegateRemoteException (complete) 3 0,5 2 0,5 5 PASException (complete) 2 0,5 1 FileNotFoundException (complete) 31 0,75 13 QgenMIParametrizedBusinessException (complete) 1 0,5 1 ADOPMessageException (complete) 3 0,5 2 LayoffException (complete) 1 0,5 1 0,75 8 CMPException (complete) 1 0,5 1 GREJBRemoteServiceException (complete) 34 0,75 4 RSIPersistenceException (complete) 24 0,75 4 CSIRemoteException (complete) 3 0,5 1 SIPSCFatalRemoteCallException (complete) 3 0,5 1 SIPSCDatabaseException (complete) 1 0,5 1 BusinessException (complete) 159 0,667 9 SVIBusinessException (complete) 1 0,5 1 ParametrizedBusinessException (complete) 2 0,5 2 GDServicesException (complete) 4 0,5 3 ServerException (complete) 132 0,75 16 PGException (complete) 6 0,667 5 0,75 4 DESException (complete) 135 0,667 13 0,667 2 0,75 9 SIPSCException (complete) 27 0,75 9 ReportException (complete) 5 0,667 2 SSNServiceException (complete) 1 0,5 1 AFException (complete) 1 0,5 1 InvalidNISSException (complete) 14 0,75 4 0,75 14 GILConcurrencyException (complete) 1 0,5 1 RSISystemException (complete) 28 0,75 7 0,667 5 0,667 1 0,75 2 0,667 5 0,833 5 0,667 5 0,667 4 0,75 12 0,981 53 ADOPUserChoiceException (complete) 1 0,5 1 0,667 5 RPCException (complete) 1 0,5 1 GREJBConcurrencyException (complete) 15 0,875 8 0,5 1 0,5 1 0,667 1 MoradaPortuguesaNotFoundException (complete) 1 0,5 1 0,75 4 0,5 1 0,667 6 0,5 1 0,5 2 0,889 8 0,75 3 0,8 3 RSIException (complete) 1 0,5 1 0,5 1 0,5 1 0,667 4 0,667 3 0,5 1 0,5 2 0,75 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
  13. 13. ¡  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
  14. 14. knowledge level business constraints design level legislation procedural model declarative model policies regulations business rules Is  it  possible  to   provide  support   at  this  level?  
  15. 15. ¡  Usability  (by  non-­‐IT  savvy)       ¡  Support  along  the  entire  system’s  lifecycle     High-­‐level  graphical     specification  languages   Automated  reasoning  capabilities  
  16. 16. internal life cycle third party life cycle diagnosis design execution execution diagnosis design runtime verification staticverificationa-posterioriverification a-posteriori verification runtimeverificationstaticverification enactment properties verification a-priori compliance verification model discovery trace analysis a-priori compliance verification monitoring on-the-fly compliance verification model discovery composition trace analysis a-posteriori compliance verification open declarative interaction model interaction model Support!  
  17. 17. Computational       Logic  for  the   Ification  and     Modeling  of     Business                    constraints     ver   REASONING CAPABILITIES GRAPHICAL MODELING system formal specification ba c (extended) ConDec CLIMB Translation SCIFF Framework event log
  18. 18. REASONING CAPABILITIES GRAPHICAL MODELING system formal specification ba c (extended) ConDec CLIMB Translation SCIFF Framework event log
  19. 19. ¡  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”  
  20. 20. ¡  First  step:  activities  elicitation   §  Completely  open  model   choose item standard payment 1-click payment accept advert close order register
  21. 21. ¡  Second  step:  constraints  elicitation   §  Partial  closure  of  the  model:  supported  traces   must  comply  with  all  the  constraints   paym fail choose item standard payment 1-click payment paym do accept advert close order register 0..1
  22. 22. 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
  23. 23. CUSTOMER   SELLER   WAREHOUSE   commit order confirm order refuse order confirm shipment refuse shipment
  24. 24. REASONING CAPABILITIES GRAPHICAL MODELING system formal specification ba c (extended) ConDec CLIMB Translation SCIFF Framework event log Translation
  25. 25. LTL   ConDec   [Pesic  and  van  der  Aalst,  2006]  
  26. 26. ¡  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   avoiding 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 which translates 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.
  27. 27. ¡  The  system  itself  is  modeled  as  a  formula!!!   portion 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 not coexistence constraint is represented in LTL by stating that if refuse order is eventually executed, then the execution of the pay activity is always for- 4
  28. 28. CLIMB/SCIFF    LTL   ConDec   [Pesic  and  van  der  Aalst,  2006]  
  29. 29. ¡  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  
  30. 30. (partial) execution trace CLIMB specification Expectations Fulfillment Abductive explanations CLIMB  specification:     rule-­‐based,  mixing  forward  and   backward  rules     Subset  of  the  SCIFF  syntax  
  31. 31. ¡  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  
  32. 32. ¡  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)  
  33. 33. ¡  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  
  34. 34. ¡  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.  
  35. 35. ¡  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!    
  36. 36. ¡  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)  
  37. 37. ¡  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 S Comp (KB ∪ T ∪ ∆) ∪ CET ∪TX |= IC where Comp is the three-valued completion of a theory [14 for Clark Equational Theory [77] and TX is the constrain parametrized by X. Fixing a CLP theory corresponds to instantiating the param
  38. 38. ¡  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   traces of the system: depending on the actual event occurrences cont a trace, they become fulfilled or violated, leading to consequently c the trace as correct or not. The CLIMB declarative semantics must t of formally capturing such an intended meaning, making clear and the relationships between positive and negative expectations, and expectations and happened events. The connection between positive and negative expectations is ta E-consistency, which basically states that they are conflicting conce same event cannot be expected to happen and not to happen at t time. Definition 4.3.8 (E-consistency). An abducible set ∆ is E-consi ∀e ∈ U and ∀t ∈ T: {E(e, t), EN(e, t)} ∆ Example 4.3.6 ( E-consistency and intensional representations). Let sider the abductive explanations of Example 4.3.5. Sets ∆3 and ∆ consistent, while ∆5 is not E-consistent, because the same refusal expected to happen and not to happen at time 10. Indeed, remem EN(tell(hatter, alice, refuse(loc(rabbit)), T) is used to intensionall sent the (infinite) set of negative expectations on all the possible groun including also T = 10. The intensional representation of expectations may sometimes ca 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 con expectations overlap in time, it is sufficient that there exists at l { 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 is operationally handled, in SCIFF, by the CLP solver itself. The relationship between expectations and happened events is captured by the notion of fulfillment, which formalizes the conditions determining whether an 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 the execution trace of the instance; • negative expectations must have no corresponding matching event in the execution trace of the instance. Definition 4.3.9 (Fulfillment). Given a CLIMB trace T and an abducible set ∆, ∆ is T -fulfilled if and only if, ∀e ∈ U, ∀t ∈ T: E(e, t) ∈ ∆ =⇒ H(e, t) ∈ T EN(e, t) ∈ ∆ =⇒ H(e, t) /∈ T By taking into account the abductive nature of expectations, fulfillment can be interpreted as a particular form of hypotheses confirmation: • Expectations are hypothesized according to the running instance of the system and the CLIMB specification; this leads to the formulation of ex- pectations as abductive explanations, according to Def. 4.3.7.
  39. 39. ¡  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  
  40. 40. ¡  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).  
  41. 41. ¡  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).  
  42. 42. ¡  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  
  43. 43. ¡  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  
  44. 44. ¡  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  
  45. 45. ¡  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  
  46. 46. payme failure choose item standard payment 1-click payment payme done accept advert close order register 0..1 Simple  relation  constraint   H(register,  Tr)  →  E(accept_advert,  Ta).    
  47. 47. payme failure choose item standard payment 1-click payment payme done accept advert close order register 0..1 Timed  relation  constraint   H(1-­‐click_payment,  Tp)  →  E(register,  Tr)∧Tr    Tp.    
  48. 48. payme failure choose item standard payment 1-click payment payme done accept advert close order register 0..1 Negation  constraint   H(close_order,  To)  →  EN(choose_item,  Ti)  ∧  Ti    To.            
  49. 49. 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
  50. 50. LTL formula CLIMB specification ba c tLTL tCLIMB complies with CLIMB trace LTL trace ConDec Model Real execution trace tm complies with behavioral equivalence 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!!!  
  51. 51. 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-N1 between(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 the ones shown in the formalization. Fig. 6.1 shows how ConDec++ is able to combine the proposed notation with basic relation constraints (i.e., responded existence, response and precedence) to express a plethora of metric relationships between the in- volved activities. A typical use of the metric extension is the modeling of deadlines. For example, a customer could express that she wants to interact only with sellers able to deliver the ordered items by at most two days after the order’s payment. By assuming a time granularity of hours, ConDec++ can capture this business constraint as: pay (−,48) •−−− deliver Finally, the metric extension can be combined with negation relationships to model latencies, i.e., minimum time spans that must be respected before executing a certain activity. For example, a warehouse could state that it takes at 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 modeled by substituting the and CLP constraint with ≤ and ≥ respectively. Metric precedence expresses that activity b is executable only inside the time indows ranging from n to m time units after each occurrence of activity a. he membership of Tb to such a time window is expressed by means of the wo CLP constraints Tb Ta + n and Tb Ta + m, which are equivalent to he ones shown in the formalization. Fig. 6.1 shows how ConDec++ is able to combine the proposed notation ith basic relation constraints (i.e., responded existence, response and recedence) to express a plethora of metric relationships between the in- olved activities. A typical use of the metric extension is the modeling of eadlines. For example, a customer could express that she wants to interact nly with sellers able to deliver the ordered items by at most two days after he order’s payment. By assuming a time granularity of hours, ConDec++ can apture this business constraint as: pay (−,48) •−−− deliver inally, the metric extension can be combined with negation relationships o model latencies, i.e., minimum time spans that must be respected before xecuting a certain activity. For example, a warehouse could state that it takes t 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 We show the case in which bounds are excluded. Inclusion of bounds is modeled by substituting the and CLP constraint with ≤ and ≥ respectively.
  52. 52. ¡  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 1, we can model it by relying on an open account activity, associated to n age datum3 . Then, an absence constraint can be employed to state that counts cannot be opened. However, since the prohibition is only applied originators whose age is less than 18, a data condition age 18 must be sociated 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 cardinality constraint will be enforced (and violated) only if open account is ecuted by a person whose age is under 18. It will instead remain quiescent data aware ConDec++ constraints into CLIMB 8 true →EN(exec(open account, EID , O, [Age]), T) ∧ Age 18.
  53. 53. ¡  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   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 tha the constraint triggers only when the glucose level is lower than 70 mg/d Second, an equality constraint models that the eat activity is expected to b executed by the patient who has been subjected to the glucose test. Third, Prolog predicate sweet(Food) is used to impose that the eaten food must b sweet. The graphical ConDec++ representation of (DA4) is then: test glucose eat Level Level 70 test 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 a ion of some data aware ConDec++ constraints into CLIMB open account 0 Age 18 true →EN(exec(open account, EID , O, [Age]), T) ∧ Age 18. add to black list Target 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. eat Food sweet(Food) 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.
  54. 54. ¡  Atomic  activities  à  instantaneous  execution   ¡  Non-­‐atomic  activities  à  span  over  time   §  Associated  to  a  life  cycle   ▪  Multiple  events   ▪  Multiple  possible  instantiations  at  the  same  time  ing ConDec initial execution execution successful execution failed started (ts) completed (tc) canceled (tx) 152 6 Extending ConDec (role) a Datum1 Datum2 (role) a Output datum ts tc tx Input datum Fig. 6.4a. Atomic ConDec++ activity with data and role Fig. 6.4b. non atomic ConDec++ ac- tivity with data and role
  55. 55. ¡  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  
  56. 56. REASONING CAPABILITIES SCIFF Framework REASONING CAPABILITIES SCIFF Framework GRAPHICAL MODELING system formal specification ba c (extended) ConDec CLIMB Translation event log
  57. 57. ¡  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  
  58. 58. 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 = ∅) 1
  59. 59. ¡  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    
  60. 60. ¡  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!!!  
  61. 61. ¡  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  
  62. 62. execution diagnosis design implement. design implement. feedback model execution traces 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
  63. 63. ¡  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  
  64. 64. ¡  Non-­‐conflicting  à  supports  the  empty  trace   ¡  All  activities  are  dead   of further properties, starting from the discovery of dead activities to evaluation of domain-dependent requirements. The following example p out this issue. Example 8.5.1 (Trivial compatibility). A modeler wants to investigate whe the two models CM1 = a •== • b CM2 = b •−− • c •−−−− a can be composed. The two models are compatible, because they both sup the empty execution trace. Hence, it would seem that a composition ca actually 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 a are all dead activities. of further properties, starting from the discovery of dead activities to evaluation of domain-dependent requirements. The following example poi out this issue. Example 8.5.1 (Trivial compatibility). A modeler wants to investigate whet the two models CM1 = a •== • b CM2 = b •−− • c •−−−− a can be composed. The two models are compatible, because they both supp the empty execution trace. Hence, it would seem that a composition can actually 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 an are all dead activities. In general, if none of the local models contains goal-oriented ConDec c straints (see p. 51), compatibility always returns a positive answer, beca
  65. 65. ¡  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  
  66. 66. ¡  Does  the  model  support  a  scenario  in  which  the  user   chooses  the  “1-­‐click”  payment  modality  without   accepting  advertising?   pa f choose item standard payment 1-click payment paaccept advert close order register 0..1
  67. 67. ¡  Does  the  model  support  a  scenario  in  which  the  user   chooses  the  “1-­‐click”  payment  modality  without   accepting  advertising?   pa f choose item standard payment 1-click payment paaccept advert close order register 0..1 0   1..*  
  68. 68. ¡  Goal:  E(1-­‐click,  Tc)  /  EN(accept_advert,Ta)   choose item standard payment 1-click payment accept advert close order register 0..1 0   1..*  
  69. 69. ¡  Goal:  E(1-­‐click,  Tc)  /  EN(accept_advert,Ta)   choose item standard payment 1-click payment accept advert close order register 0..1 0   1..*   H(1-­‐click,  Tc)   fulfiller  
  70. 70. ¡  Goal:  E(1-­‐click,  Tc)  /  EN(accept_advert,Ta)   choose item standard payment 1-click payment accept advert close order register 0..1 0   1..*   H(1-­‐click,  Tc)   fulfiller   E(register,  Tr),  Tr    Tc,     E(close_order,  To),  To    Tc       “precedence”   triggering  
  71. 71. ¡  Goal:  E(1-­‐click,  Tc)  /  EN(accept_advert,Ta)   choose item standard payment 1-click payment accept advert close order register 0..1 0   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  
  72. 72. ¡  Goal:  E(1-­‐click,  Tc)  /  EN(accept_advert,Ta)   choose item standard payment 1-click payment accept advert close order register 0..1 0   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!  
  73. 73. ¡  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”   Satisfiability and validity can then directly accommod and ∀-entailment. Conflict detection is a specific case o Theorem 11.3.1 (ConDec conflict in terms of LT ConDec model CM is conflict-free if and only if sat tLTL (CM) ∧ term (CM) Proof. Straightforward from the definitions of satisfiab of LTL-based ∃-entailment (Def. 11.3.1), considering a Theorem 11.3.2 (∃-entailment in terms of LTL s A ConDec model CM ∃-entails a ConDec property sat tLTL (CM) ∧ term (CM) ∧ tLTL (Ψ) Proof. Straightforward from the definitions of satisfiab of LTL-based ∃-entailment (Def. 11.3.1). 11.3 Static Verification of ConDec Models a Theorem 11.3.3 (∀-entailment in terms of LTL model CM ∀-entails a ConDec property Ψ if and onl val tLTL (CM) ∧ term (CM) =⇒ tLTL (Ψ) Proof. Straightforward from the definitions of valid LTL-based ∀-entailment (Def. 11.3.2). Example 11.3.1 (LTL-based discovery of dead activit looping ConDec model Loop shown in Fig. 10.4, p. that the modeler wants to know whether activity d is d consists in verifying if the ConDec model ∀-entails th translated into LTL as ¬d. This problem in turns r the formula
  74. 74. ¡  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)  
  75. 75. ¡  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      
  76. 76. ¡  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   !!!   ba 1..*
  77. 77. model run-time reasoning partial trace info execution diagnosis design implement. design implement. feedback model execution traces
  78. 78. ¡  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  
  79. 79. ¡  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  
  80. 80. ¡  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”    
  81. 81. ¡  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  
  82. 82. ¡  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  
  83. 83. ¡  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  
  84. 84. ¡  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!  
  85. 85. ¡  Show   §  Pending  constraints   §  Forbidden  activities   ¡  Hidden  dependencies!   a b c d e 0..11..* Initial  state  
  86. 86. ¡  Show   §  Pending  constraints   §  Forbidden  activities   ¡  Hidden  dependencies!   “a”  executed   a b c d e 0..11..*
  87. 87. ¡  Show   §  Pending  constraints   §  Forbidden  activities   ¡  Hidden  dependencies!   “b”  executed   a b c d e 0..11..*
  88. 88. ¡  Show   §  Pending  constraints   §  Forbidden  activities   ¡  Hidden  dependencies!   “c”  executed   a b c d e 0..11..*
  89. 89. ¡  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   pastpresent   ➔ g-­‐SCIFF  for  reasoning  about  the  future  
  90. 90. log process mining info execution diagnosis design implement. design implement. feedback model execution traces
  91. 91. ¡  Extraction  of  relevant  information  from  event  logs   (un)desired properties interaction modelrecords event log refers to models system Log-based verification Conformance checking Discovery
  92. 92. ¡  SCIFF  can  perform  trace  analysis   ¡  For  CLIMB  specifications  à  reasoning  can  be   performed  in  Prolog   Trace  Analyzer   Business   rule   Log  
  93. 93. ¡  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  
  94. 94. ¡  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!  
  95. 95. !
  96. 96. ¡  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  
  97. 97. ¡  Operational  Decision  Support   ¡  Integration  between  regulative  and  constitutive   aspects  in  interaction  models   §  Business  Constraints   §  Social  Commitments   ¡  Generation  of  compliant-­‐by-­‐design  procedural   models   pay choose item 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)
  98. 98. ¡  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.  
  99. 99. ¡  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.  
  100. 100. ¡  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.  
  101. 101. ¡  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.  

×