Contract analysis is a process aimed at detecting potential errors that can be intro- duced by inconsistent contract clauses. As discussed above, contracts could contain inconsistencies in the form of conflicting clauses. For instance, two or more clauses could conflict or be inconsistent if in certain conditions one of the rules is triggered by an event but the actions defined in the body of the rules contradict some other rules. Different tools have been used for the verification and analysis of contracts, most of which are model checkers. For example the Spin model checker is used for the verification of safety and liveness properties of e-contracts [36]. The use of Spin has been demonstrated for validating an ECA rule based contract compliance checker that monitors the interactions between business partners. The same Spin model checker has also been used for the verification of Web service specifications modeled as syn- chronous interactions [21]. Other model checkers such as MCMAS [3], NuSMV [7], VeriSoft [22] and CLAN [19] have also been successfully used for the verification of
contracts. For example, the specification of contract regulated service compositions written in WS-BPEL are translated into timed automata which are automatically verified by the MCMAS model-checker [4]. The NuSMV model checker is also used to verify the properties of contracts written in CL contract language [41]. The VeriSoft model checker has been suggested for the validation of business processes [53]. Petri nets [39] are also used to model the behaviour of the participants of a contractual protocol, where a process view of agreements between parties means that a contract is modelled as it evolves over time in terms of actions or more general events that effect changes in its state [9]. CLAN is another model checker that is implemented for performing the automatic analysis of conflicting clauses written in CL language. This is not a general model checker however, but was designed and implemented only for the verification of contracts written in CL language.
We have seen that different model checkers have been successfully used for the analysis of contract properties. Next we discuss the main principles of model checking using Spin model checker. Notice that, apart from the contract–dedicated model checker CLAN, the principles of model checking with Spin are quite similar to the other model–checker introduced in this section.
2.4.1
Principles of model–checking (using Spin)
Spin [27] is a freely available, mature and well documented model checker designed to validate the correctness properties of asynchronous process systems. It validates abstract models written in the Promela language against safety and liveness correct- ness claims that can be expressed as basic assertions and linear temporal logic (LTL) formulae [28]. Recall that safety is concerned with a program not reaching a bad state and that liveness is concerned with a program eventually reaching a good state [33]. In response to the detection of a violation of a given property, Spin produces coun- terexamples that show how the property was violated. A counterexample is actually
an execution trace from the initial state of the model through to the state where the violation of the property takes place. Figure 2.8 depicts the Spin structure: in a Promela model describing the behaviour of a system, and an LTL property expressing a correctness property that the Promela model is expected to observe are presented to Spin for analysis. Spin produces a counterexample if the LTL is violated, otherwise, it outputs nothing.
Promela model
LTL property
Spin
Counter-
example
Figure 2.8: Spin structure
Promela is a process modeling language, which can generally be seen as a fairly standard imperative programming language although it does have some novel fea- tures. Its intended use is for describing concurrent systems. It is a non-deterministic, multi-process language which incorporates guarded commands and communication channels. Processes are global objects that represent the concurrent entities of the distributed system. Message channels and variables can be declared either globally or locally within a process. Processes specify behavior, channels and global variables define the environment in which the processes run. Given a program in Promela, Spin verifies the model for correctness by performing random or iterative simulations of the modeled system’s execution, or it can perform an exhaustive verification of the generated system’s state space. During simulations and verifications, Spin looks for the absence of deadlocks, unspecified receptions, and unexecutable (dead) code.
find non-progress execution cycles. Finally, it supports the verification of linear time temporal constraints by formulating them in temporal logic formulae. Each model can be verified with Spin under different types of assumptions about the environment. Once the correctness of a model has been established, that fact can be used in the construction and verification of subsequent models.
2.4.2
Analyzing x-contracts with Spin
Analyzing x-contracts with the Spin model checker relies on model-checking algo- rithms to determine whether or not a contract model satisfies a list of correctness requirements. The validation process following a widely used model-based validation approach for validating such requirements, including correct commencement, prece- dence, and the absence of livelocks as defined in a previous study [49]. With the Spin model checker, the correctness requirements of an x-contract are specified as safety and liveness properties through linear temporal logic. Informally, a safety property is a statement which claims that something bad will not happen, and a liveness property is a statement which claims that something good will eventually happen. Further- more, it can be argued that most correctness requirements in traditional business contracts can readily be expressed either as safety or liveness properties [49].
For the verification of the safety and liveness properties of a contract, an x-contract has to be derived and represented as a set of FSMs, one for each of the contracting parties that interact with each other. Conceptually this assumes that an FSM is located within each contracting party and that these FSMs communicate with each other through communication channels.
In order to use the Spin model checker for the verification of x-contracts, the first step is to convert the FSMs into Promela language. After that, Spin can by default verify general safety properties that must hold true for any x-contract, for example deadlocks. The validation of the remaining specific safety properties is done
through simple assertions inserted within the Promela code. Through these steps, the validation of x-contracts with Spin follows the classical model checking technique of software systems.
2.4.3
Analyzing EROP contracts with Spin
Spin has been used for the validation of EROP contracts specified as a set of ECA rules. In a practical approach, an abstracted model of a contract compliance checker (CCC) [51] system has been modelled as a reactive system, converted into Promela and validated with Spin to observe the properties of interest which are regarded as safety and liveness properties. This checks the consistency of the ECA rules and the behaviour of the CCC in response to both valid, or contractually compliant or invalid events erroneously supplied by the parties. Other properties considered are contract specific properties, such as deadline extensions granted exactly as stated in the clauses and so forth.
In has been suggested that a large proportion of errors in ECA rules, such as rule redundancy, submed rules or conflicting rules can be detected by conventional model checkers [36]. With Spin, general types of potential errors that might be accidentally introduced into ECA contract rules can be detected as violations of safety and liveness properties, such as deadlocks, non-progress cycles, unexpected messages and incorrect final states. With default settings, Spin has been used to validate these requirements and for subtle errors linear temporal logic (LTL) expressions have been suggested to verify rule conflicts.
2.4.4
Analyzing CL contracts with CLAN
Section 2.3.3 has described the contract language CL and demonstrated through an example how it is used to specify the permissions, obligations and prohibitions
clauses in contracts written in the CL, and it enables the automatic analysis of the contract for normative conflicts as well as the automatic generation of a monitor for the contract [19].
CLAN has been implemented to verify the correctness of specific contracts written in CL language. In particular CLAN considers the contract conflicts omitted in the previous studies discussed in sections 2.4.1 and 2.4.2 using a different approach based on deontic logic. For conflict analysis, the tool performs exhaustive search on clauses written in CL language to detect conflicts that arise for four reasons [19]: (i) obligation and prohibition on the same action; (ii) permission and prohibition on the same action; (iii) obligation to perform mutually exclusive actions; and (iv) permission and obligation to perform mutually exclusive actions.