Open Incremental Model Checking (OIMC) and the Role of Contracts

1. Open Incremental Model Checking (OIMC) and the Role of Contracts Model-Based Programming and Verification

2. Motivation • Component Based Software Development (CBSD) is considered to revolutionize software technology. • CBSD builds around two concepts: reuse and evolution. • In short, it is possible – in theory – to develop software systems faster and reduce the costs of maintenance (e.g. modifying or replacing specific parts of the software without affecting the rest of the system).

3. Verified components • Growing dependency of people on the proper functioning of computer systems demands new methods to increase the reliability and correctness of these systems. • Well-known methods of verification: testing, synthesis, correctness proof and model checking. • Only testing and model checking is currently used in practice considering commercial application development.

4. Drawbacks • Testing of component-based systems can be extremely complicated because it is usually not possible for system architects to pre-check the compatibility of the individual parts before the actual integration takes place. • The environment of the development and the deployment are rarely the same if prefabricated components also referred to as Components Off-The-Shelf (COTS) are used. • The use of these components may also differ considerably from the original purpose they were developed for.

5. Contract-based testing • A possible solution to this problem is based on the idea of building correct programs in which reliability is built-in. • This means the correctness properties of a program may be transferable or at least checkable in other environments as well. The concept behind that is the method of “design-by-contract”. • But after testing the components separately an integration testing of the assembled application is still needed.

6. Model checking • Testing methods generally do not guarantee that no hidden errors remain in a system, so the attention of researchers has turned towards formal methods. • Model checking is an automatic technique for verifying finite state concurrent systems. • Main challenge in model checking is dealing with the state space explosion problem occurring in systems with many components that can make transitions in parallel.

7. Sample component • In our example we designed an automatic betting machine to “TippMix”, the Hungarian version of “Bet and Win”. The only input needed for the betting machine is the number of events a person wants to bet on and produces a ticket that is bound to the rules of the game with a combination of bets. • The simplified functioning of the automatic betting machine can be seen in the next slide.

8. Automatic Betting Machine

9. Behavioral specification

10. Open Incremental Model Checking (OIMC) • OIMC addresses the changes to a system instead of re-checking the entire system model including the new extensions. • The model checking is executed in an incremental manner within the extension component only. • The conditions (inter-component constraints) resemble to pre- and post-conditions in“design-by-contract”.

11. Scalability of OIMC* • General case: the n-th version of the component (Cn) during software evolution as a structure of components B, E1, E2, …, En where Ei is the refining component to the (i-1)-th evolved version (C(i-1)), i=1,n. The initial version is C0=B and Ci=Ci-1+Ei. • Theorem: If all respective pairs of base (C(i-1)) and refining (Ei) components conform, the complexity of OIMC to verify the consistency between En and B is independent from the n-th version Cn, i.e. it only executes within En. *Source: Thang, N. T., Katayama, T.: “Specification and verification of inter-component constraints in CTL” in Proceedings of the 2005 conference on Specification and verification of component-based systems, Vol. 31, Issue 2, pp. 1-8, published by ACM Press.

12. Extending the sample component • The automatic betting machine – if necessary – may be extended with multiple terminal consoles. • In this case the betting component remains unchanged (properties must be preserved), though the mutual exclusion and liveliness properties of the system must be guaranteed additionally. • The betting component may also be transformed into a lottery component if – for instance – the number of events is 5 and the range of events is between 1 and 90 and the bet itself is ignorable.

13. Extending the system

14. Future work • Circular dependency between interface states of the base and the extension cannot be handled by OIMC. • There are existing software products able to extract contracts from the source code of an application. A tool should be developed that is able to transform these contracts to CTL temporal constraints for model checking (especially OIMC). • An educational framework with a library of verified components needs to be created for providing an environment for IT students to practice design decisions.

15. Conclusions • This research can result in the better use of formal methods in practical applications, the better understanding of specifications, and finally less debugging work for developers who could easily misinterpret specifications. • Ultimate goal: integration testing becomes unnecessary for large and complex systems in the case of replaced or modified components. • Third-party components formally verified by model checking techniques become more reliable and trustable.