Commitments as Elements of a Contract A kind of normative - PowerPoint PPT Presentation

Commitments Commitments as Elements of a Contract A kind of normative relationship: Express meanings of interactions ◮ Are atoms of contractual relationships ◮ Enable correctness checking of contracts ◮ Yield precise meanings and verifiability Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 102

Commitments Example: Commitment Progression Via explicit operations or because of logical properties C (Buyer, Seller, goods, pay): Active and conditional ◮ If goods ∧ C (Buyer, Seller, goods, pay) Then ◮ Active and detached (or unconditional or base) ◮ C(Buyer, Seller, T, pay) ◮ If C (Buyer, Seller, T, pay) Then ◮ If pay Then Satisfied ◮ If never pay Then Violated ◮ If C (Buyer, Seller, goods, pay) Then ◮ If pay Then Satisfied ◮ If never pay and never goods Then Expired Can be nested: C (Seller, Buyer, pay, C (Shipper, Buyer, T, deliverGoods)) Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 103

Commitments Operationalizing Commitments: Detach then Discharge C (debtor, creditor, antecedent, consequent) d:Debtor c:Creditor create(d, c, p, q) p q Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 104

Commitments Operationalizing Commitments: Discharge First; Optional Detach How about this? d:Debtor c:Creditor create(d, c, p, q) q opt p [true] Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 105

Commitments Operationalizing Commitments: Detach First; Optional Discharge How about this? d:Debtor c:Creditor create(d, c, p, q) p opt q [true] Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 106

Commitments Operationalizing Commitments: Creation by Creditor C (debtor, creditor, antecedent, consequent) d:Debtor c:Creditor create(d, c, p, q) p q Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 107

Commitments Operationalizing Commitments: Strengthening by Creditor C (debtor, creditor, antecedent, consequent) d:Debtor c:Creditor create(d, c, p, q) C(d, c, p, q) p C(d, c, ⊤ , q) q no active commitment Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 108

Commitments Commitment Life Cycle (and Patterns) C (debtor, creditor, antecedent, consequent) Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 109

Commitments Commitment Operations ◮ create( C (d, c, p, q)) establishes the commitment ◮ detach( C (d, c, p, q)) turns it into a base commitment ◮ discharge( C (d, c, p, q)) satisfies the commitment ◮ cancel( C (d, c, p, q)) cancels the commitment ◮ release( C (d, c, p, q)) releases the debtor from the commitment ◮ delegate(z, C (d, c, p, q)) replaces d by z as the debtor ◮ d remains ultimately responsible (in our work) ◮ assign(w, C (d, c, p, q)) replaces c by w as the creditor Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 110

Commitments State Diagrams State Diagrams Formalized in UML 2.0 from Harel’s statecharts Generalize over finite state machines ◮ Condition or guard on a transition ◮ Superstate ( or -state): being in a substate entails being in the superstate ◮ Natural for summarizing states that bear similar meanings and support similar transitions ◮ Parallel states indicate being in the each of the states at the same time ( and -state) ◮ Cartesian product of the individual states ◮ Natural for expressing mutually independent components of the state Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 111

Commitments State Diagrams Exercise: Diagram the Purchase Protocol First as we specified and second with concurrent Pay and Ship subprotocols Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 112

Commitments State Diagrams Exercise: Diagram the Purchase Protocol with Return and Refund Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 113

Commitments State Diagrams Exercise: Diagram Precedence, Occurrence, Exclusion Across two messages, m 1 and m 2 Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 114

Commitments State Diagrams Applying State Diagrams in Our Setting Behavior descriptions, but of social behavior ◮ In general, sequence diagrams should describe interactions whereas state diagrams should describe internal behaviors ◮ Traditional sequence diagrams often step into internal details ◮ Traditional state diagrams are low-level, just as traditional sequence diagrams are, only more so ◮ Our state diagrams apply to a social state, which can be affected through messages described by sequence diagrams ◮ Consider state diagrams as describing the progression of the social state of a service engagement ◮ We can express this from an outside, i.e., a public or an institutional, as opposed to an implementation perspective ◮ A research challenge is to ensure the social state remains sufficiently aligned across the interacting parties ◮ For a properly designed service engagement, its social state ought to progress consistently Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 115