Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction Models
•
0 gostou•697 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (7)
Semelhante a Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction Models
Semelhante a Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction Models (20)
Mais de Faculty of Computer Science - Free University of Bozen-Bolzano
Mais de Faculty of Computer Science - Free University of Bozen-Bolzano (20)
Último
Último (20)
Invited Seminar@KRDB 2010 - Montali - Specification and Verification of Declarative Open Interaction Models
- 1. Marco Montali University of Bologna Bolzano, 15/12/2010
- 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. ¡ 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. ¡ 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. 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. ¡ 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. ¡ Closed and procedural modeling abstractions
- 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. ¡ 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. ¡ Empty workflow ¡ The following ¡ Many compliant traces not supported à over-‐constrained model SellerWarehouse refuse shipment refuse order ... ...... ...
- 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?
- 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. 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. ¡ Usability (by non-‐IT savvy) ¡ Support along the entire system’s lifecycle High-‐level graphical specification languages Automated reasoning capabilities
- 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. 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
- 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. ¡ First step: activities elicitation § Completely open model choose item standard payment 1-click payment accept advert close order register
- 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. 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. CUSTOMER SELLER WAREHOUSE commit order confirm order refuse order confirm shipment refuse shipment
- 25. LTL ConDec [Pesic and van der Aalst, 2006]
- 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. ¡ 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. CLIMB/SCIFF LTL ConDec [Pesic and van der Aalst, 2006]
- 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. (partial) execution trace CLIMB specification Expectations Fulfillment Abductive explanations CLIMB specification: rule-‐based, mixing forward and backward rules Subset of the SCIFF syntax
- 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. 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. 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. 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. 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. 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. 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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
- 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. 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. ¡ 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. ¡ 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. ¡ 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. 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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. ¡ 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..*
- 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. ¡ 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
- 81. ¡ 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”
- 82. ¡ 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
- 83. ¡ 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
- 84. ¡ 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
- 85. ¡ 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!
- 87. ¡ Show § Pending constraints § Forbidden activities ¡ Hidden dependencies! a b c d e 0..11..* Initial state
- 88. ¡ Show § Pending constraints § Forbidden activities ¡ Hidden dependencies! “a” executed a b c d e 0..11..*
- 89. ¡ Show § Pending constraints § Forbidden activities ¡ Hidden dependencies! “b” executed a b c d e 0..11..*
- 90. ¡ Show § Pending constraints § Forbidden activities ¡ Hidden dependencies! “c” executed a b c d e 0..11..*
- 91. ¡ 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
- 93. ¡ Extraction of relevant information from event logs (un)desired properties interaction modelrecords event log refers to models system Log-based verification Conformance checking Discovery
- 94. ¡ SCIFF can perform trace analysis ¡ For CLIMB specifications à reasoning can be performed in Prolog Trace Analyzer Business rule Log
- 96. ¡ 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
- 97. ¡ 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!
- 98. !
- 99. ¡ 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
- 100. ¡ 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)
- 101. ¡ 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.
- 102. ¡ 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.
- 103. ¡ 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.
- 104. ¡ 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.