IMPLEMENTACIÓN DE LA FUNCIÓN PSD EN EL SISTEMA

Contract-dependent conflicts may occur when specific contract-dependent correctness requirements are invalid or lead to contradictions between contract parties. Most of the conflicting scenarios shown in Section 2.3 fall in to this category. Let us return to the Buyer/Seller contract at Section 3.3.3. We stated two crucial requirements: a) the contractual interaction always terminates in one out of several acceptable final states; b) the contractual interaction always progresses through a valid sequence of states. In particular, it is desirable to verify that ‘a Seller is penalised a fixed amount of money if he fails to deliver the purchased items on time’. Likewise, verify that the operation ‘reject purchase order’ always takes place after the occurrence of an ‘offer’ operation and within the permitted period for rejection. Recall that the term conflict used to refers to an inconsistency within a single clause or two or more contract clauses that may lead to a contradiction between the contract parties.

3.5

Discussion

This Chapter discussed the main components of the contract compliance checker of EROP model and how it can be abstracted as a reactive system. As discussed in Section 2.4.2, an abstract model of the CCC has been modelled using Promela and verified using Spin model checker [36]. Thus, different properties of a business contract model have been verified using the general purpose model checking tool (Spin).

We believe that the facilities of the Spin model checker can be reused in a better way to assist in the verification and validation of business contracts. In particular, the standard Promela can be extended [48] with the concept of business operations and operators to manipulate it. For example, in extended Promela, the designer can include in his model operations such as assign obligation delivery to the seller, and express queries like ‘is the buyer currently obliged to pay?’ Like many other model- checkers, Spin can accept and verify correctness constraints, for example where the buyer is never obliged to and prohibited from paying, abstracted as safety and liveness properties and expressed in LTL formulae [49].

The next Chapter introduces a formal Contractual B2B model (CB2B) based on EROP concepts. We discuss how Spin and an extended version of Promela that adds specific constructs aimed at capturing concepts frequently found in contracts can work together as a pragmatic tool for contract model checking. Such a tool can be built using the concepts of contract compliance checking CCC described at the beginning of this Chapter (Section 3.1.1). With the appropriate level of abstraction of the contract and contractual B2B environment, contract models of manageable sizes can be built with extended Promela and verified by Spin. So that the ECA rules expressed in extended Promela can be automatically analysed using well known model checking techniques and readily available technology.

Chapter 4

CB2B formal model

The contractual business–to–business model (CB2B) considered in this chapter ab- stracts the behaviour of the contract compliant checker CCC of the EROP language. It is empowered with a set of operations which facilitate access to the contract el- ements such as role player obligations held in the system memory. In earlier work, Promela was used to model the CCC and the rules [36]. The lack of data types other than the built-in types bit, byte and array is seen as a serious restriction to the use of Promela as a specification language rather than a protocol modeling language. However, the language can be extended with user–defined data types [48]. Using its typedef construct, and the inline and/or cpp macros can be used to define opera- tions on such new data types. On this basis, we have implemented an abstract data type extension to the standard Promela called BIS OP. A set of operations on the BIS OP data type have also been implemented to maintain information about ROP sets. These additional concepts not only simplify the task of writing rules, but also help the designer to specify the correctness requirements in LTL with parameters that map directly to contract concepts. Here, different aspects of the the CB2B model, its implementation and the CB2B’s model checking framework are described.

4.1

CB2B model: principles of operation

In this thesis, we have used the reactive system paradigm to design and develop an abstract architecture for contractual business to business interactions. Our architec- ture (Figure 4.1) is general and abstract enough that it can be used for i) verifying the logical correctness of contracts regarded as ECA systems; ii) implementing them and iii) testing the correctness of their implementations. Another salient point of the architecture is its modularity which allows reuse of its components at design, implementation and testing stages.

do { :: c1 -> PO :: c2 -> ACC :: c3 -> REJ :: c4 -> PAY :: !c1&!c2&!c3;!c4 break od end-state: } BEG

exe rule PAY res CCC PAY state information contract compliant or non-contract compliant CRM ROP= {1000} s₀ s1 s2 s_f ROP= {0110} ROP= {0001} ROP= {0000} Rule base rule PO rule ACC rule REJ rule PAY PO ACC PAY REJ Application being monitored

Figure 4.1: CB2B as a reactive system

To explain the concepts of CB2B model, we will use the following hypothetical contractual clauses:

1. The buyer can place a Purchase Order (PO) with the seller to buy an item. 2. The seller is obliged to reply with either Accept (ACC) or Reject (REJ) after

4. The buyer shall place Payment (PAY) after receiving an acceptance of the purchase order.

The contract example is oversimplified, for instance, it does not account for excep- tional situation like unsuccessful completion of the execution of an operation. Neither does it include deadline to complete them. In the following discussions, we use the symbol → to denote the business events chronological sequence, thus a → b denotes that a happened before b. The main components of the CB2B model are discussed in detail next.