One of the main problems with model checking is how to restrain the state space explosion. It can be caused by the level of detail or the level of concurrency within the validation model [27]. Optimising parameters such as the number of states, state vector size, size of search stack and the verification time can considerably improve the process of model verification. The state vector in the Promela model is the set of information stored by Spin to uniquely identify the system state. It contains information on the global variables, contents of each channel, process counter and the local variables in each process. The size of the state vector represents the amount of storage space it occupies. This in turn determines the state space of the model for the set of all possible states which occur during the computation. State space size is the total space required to store the state vectors corresponding to all states. If the
size of a single state vector is m bytes and there are n states in the Promela model, the state space size is m ∗ n bytes.
The contract models discussed in this Chapter executed on a HP Compaq PC with Intel(R) Core(TM)2, CPU 6300 @ 1.86 GHz 1.86 GHz and 1.98 GB of RAM. The operating system is Microsoft Windows XP Professional, Version 2001, Service Pack 3. The models verified using Spin Version 6.1.0 and iSpin version 1.0.3. All contract models experimented with the default options of iSpin with few changes. For example, the assertion violation box check–box on, the storage mode exhaustive and the search algorithm depth–first search (DFS). The next table summarises some performance metrics returned by Spin during the verification of the models. As the table shows, we have been able to verify interesting properties of contracts with reasonable size. We discussed our technique to maintain the state space of CB2B models in detail in Section 4.7. Internet-provision contract Storage service contract Buyer/Seller contract Stored states Memory usage Elapsed time Stored states Memory usage Elapsed time Stored states Memory usage Elapsed time 29950 states 5.664 Mbyte 0.047 seconds 287 states 2.539 Mbyte 0.015 seconds 317228 states 317228 states 0.672 seconds State-vector size State-vector size State-vector size
96 byte 68 byte 152 byte
Chapter 6
Conclusions and future work
6.1
Conclusions
This thesis developed a toolkit for the model checking of electronic contracts. It has employed the facilities of the Spin model checker and its input language Promela with some extensions for the process of modelling contracts. The extensions aimed to use the language of a high-level of notation in order to facilitate the composition of a contract model as a set of ECA rules. With the high level notation of the language the user can intuitively write contract rules, thus benefiting from the well-known and widely used Spin model checker for the verification and validation of the correctness of contracts.
For contract verification, this thesis considers two major types of contract con- flicts: contract–independent conflicts, which are general conflicts that may affect any contract, and contract–dependent conflicts specific to each contract. In Chapter 3, a contract compliance checker (CCC) was modelled as a reactive system, and the contract correctness requirements to detect both contract–dependent and contract– independent conflicts are specified as safety and liveness properties.
In Chapter 4, the Spin model checker and its input language Promela were used to develop a contract verification model (CB2B) based on the concepts of EROP system, its contract compliance checker and its rule–based EROP language. The CB2B is abstracting the behaviour of the contract compliant checker CCC of EROP system and empowered with a set of operations facilitates manipulation of contract elements (e.g. rights, obligations, prohibitions , etc...) held in the system memory. Furthermore, we have implemented an abstract data type extension to the standard Promela called BIS OP. We also implemented a set of operations on the BIS OP data type to maintain information about ROP sets. This extension, facilitated writing the contract models in a way mimicking the EROP language, however, our contracts can be automatically verified with the Spin model checker. Chapter 4 also describe a tool for test–case generation using our CB2B model.
Chapter 5 demonstrated our tool for the representation and verification of a num- ber of contracts derived from natural language descriptions, modelled as ECA rules and input to the CB2B model for contract compliance checking. It was shown that: (i) our representation of a contract model captures the contracts essential elements of business operations, role players, rights, obligations and prohibitions and handles CTDs and CTPs; (ii) with the help of the CB2B model, Spin automatically detects contract independent conflicts (discussed in Chapter 3), (iii) contract-dependent con- flicts can be specified with relative ease in terms of contract elements as safety and liveness requirements which were verified by the Spin model checker.
We believe that the CB2B model can be used as an integral tool of a framework for building contractual applications. Within this context the CB2B model could play a key role operating as i) validator of logical inconsistencies of contracts and ii) generator of sequences of executions of contractual business operations. Execution sequences describe the behaviour encoded in the contract, thus they can be used for many purposes, including testing as discussed in Section 4.4. Also, they can be used
for verifying conformance of the contract, for example, against i) an upgraded version of the contract expected to be equivalent ii) a business process that is supposed to implement the contractual interaction. In both cases the problem can be solved by means of comparison of the sequences generated by the contract written in CB2B model against the sequences under question.