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) create(d, c, p, q) p q d:Debtor c:Creditor

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 104

Commitments

Operationalizing Commitments: Discharge First; Optional Detach

How about this?

create(d, c, p, q) q p d:Debtor c:Creditor

• pt

[true]

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 105

Commitments

Operationalizing Commitments: Detach First; Optional Discharge

How about this?

create(d, c, p, q) p q d:Debtor c:Creditor

• pt

[true]

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 106

Commitments

Operationalizing Commitments: Creation by Creditor

C(debtor, creditor, antecedent, consequent) create(d, c, p, q) p q d:Debtor c:Creditor

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2016 107

Commitments

Operationalizing Commitments: Strengthening by Creditor

C(debtor, creditor, antecedent, consequent) create(d, c, p, q) p q d:Debtor c:Creditor C(d, c, p, q) C(d, c, ⊤, 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, m1 and m2

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