Model checking is usually applied at the software design level rather than at the software source code level, which is at least partially due to the fact that source code does not have any representation suitable for model checking. There are very few approaches [58] to model checking the source code of conventional object oriented programs. We observe that a program may contain some statements that violate the intended design of its model. For example, a program may have statements that violate the object protocol. Such statements are bugs that may be caught by model checking tools. However, the inability to model check the source code results in the inability to catch these kinds of bugs. In order to catch these kinds of bugs in the source code through model checking, we require the source code to have an abstraction with a suitable representation for model checking. We argue that a state controlled object oriented language allows specifying the object behavior by abstracting the state of the object. Transitions among the states or typestates can also be specified.
8.1 Model Checking SCOOP
Imperative programming languages, including OOP, are more useful in terms of describing software systems with operations, flow of operations, and performing operations on data. Formal verification tools are purpose-built to specify simple state machine representations of a system [55]. SCOOP combines both the simplicity of specifying a state machine representation of a software object and the strength of OOP.
State controlled object oriented source code exhibits a representation of objects that can be directly captured by formal verification tools, such as NuSMV [57], for model checking. Conventional object oriented language lacks such a representation of objects. Case study 3.14
108
of the File stated object is described in the SCOOP source code in Figure 5.1 and can be read conveniently as a finite state model as shown in Figure 3.7.
Mbeddr [56] is a tool that allows specifying the state machine representation of software objects. However, mbeddr [56] source code lacks the strength of OOP. In mbeddr, a programmer writes the source code of an object in the form of a state machine using mbeddr [56]. Mbeddr [56] can directly translate the programmer defined source code to another source code that is understandable as a model by NuSMV [57].
In this chapter, we compare SCOOP code with that of mbeddr. The description of objects, i.e. in the form of a state machine, written in mbeddr is quite analogous to the SCOOP source code. Therefore, we assume that SCOOP source code can also be directly translated to the source code that is understandable by NuSMV as a model.
Figure 8.1 Model Checking SCOOP
Figure 8.1 demonstrates a model checking tool, e.g. NuSMV, that can input a SCOOP generated model and a property to check whether the SCOOP software object complies with the property.
8.2 Symbolic Model Checking
As discussed in [55], there are many properties that can be checked on the state machine description of a software object. The checking of a property over a state machine model verifies whether the property holds true for that model. The model checker checks the property in every possible system run. If a required property holds true for a given model
SCOOP generated model Property Output Model Checking Tool
109
then it assures that the model correctly holds that property. Otherwise, the model does not correctly represent the required property and therefore should be rectified. All these properties may be divided into two categories i.e. automatic checking and manual checking. In the following sections, we illustrate properties of each of these categories that can also be checked for the SCOOP-generated model.
8.3 Automatic Checking
Some properties can be checked by the model checking tool itself as default properties. We therefore refer to such property checking as “automatic checking”. Below we discuss one such property which checks whether all states of the model are reachable.
The Reachability Property
The “reachability property” checks whether all states of a model are reachable. We illustrate the computation tree logic formula, CTL [54], to represent the reachability property from [55] for the openfile state of the ‘File’ stated object model as below.
SPEC AG _current_state!= openfile
The above property written in CTL formulae can be defined in the following words.
“In all possible system runs, it is true in every state that none of these each states is the openfile state”.
If the NuSMV finds the above property to be False for the File stated object model, it implies that the openfile state is reachable, hence it is a success scenario.
If the NuSMV finds the above property to be True for the File stated object model, it implies that the openfile state is not reachable and hence it is not a success scenario.
110
8.4 Manual Checking
There may be many custom properties that a programmer intends to check for his or her model using temporal logic formulae [54]. One of these properties is discussed below.
The ‘P is false before R Property’
This property, from [55], checks whether a condition P can be true before R. We illustrate this property in connection with the model of the ‘File’ stated object discussed in Case Study 3.14. The same model is specified in Figure 5.1 and drawn in Figure 3.7.
P is false Before R. P: file is read
R: file is in openfile state
Therefore, this property is evaluated as below.
“file is read” is false Before “file is in openfile state”
The above property says that the stated File object should not be read unless it is in the
openfile state. As long as this property is true for the File stated object model, the model is correct for that property. Otherwise, the model attempts to read the File that is not in the
openfile state. Clearly these kinds of bugs introduced in the software are a violation of object protocol.
8.5 Conclusion
Software testing and analysis of programs performed by a programming language includes static analysis to detect any violation of object protocols. In this chapter, we demonstrated
111
that the capability of SCOOP to specify object protocols can be exploited to detect violations of these protocols statically through model checking.
112