Open Incremental Model Checking

(OIMC) and the Role of Contracts

Model-Based Programming and Verification

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).

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.

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.

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.

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.

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.

Automatic Betting Machine

Behavioral specificationInitial State and Precondition Transition Final State and Postcondition

Idle and Enter not Pressed Waiting Idle and Display(0)

Idle and Enter not Pressed Enter_Num(Num) Idle and Display(0)

Idle and Enter_Num(0) Press Enter Idle and Display(0)

Idle and Enter_Num(Num) Press Enter Checking Num and Display(Num)

Checking_Num and 1<=Num<3   Working and Display(Num) and Max=50

Checking_Num and 3<Num<=5   Working and Display(Num) and Max=150

Checking_Num and 5<Num<=14   Working and Display(Num) and Max=200

Checking_Num and Num>14 Error Idle and Display(0)

Working and Num=1 Generate Tips and Print TicketIdle and Event_Num <=50 and Tip in ("Home","Draw","Guest")

Working and Num>1 Generate Tips and Print Ticket

Idle and all Event_Numi in (1..Max) Where i=1..Num and Event_Numi <> Event_Numj Where i <> j and Tip in ("Home","Draw","Guest")

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”.

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.

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.

Extending the system

Automatic Betting Component

Check NumGenerate Event_Num Num timesGenerate Tip for each Event_Num

Terminal Component

Display NumWait for Enter to be Pressed

Print Ticket

Automatic Betting Machine

Terminal Component

Display NumWait for Enter to be Pressed

Print Ticket

Scheduler

Extended Betting Machine

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.

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.