Information Technology Reference
In-Depth Information
Fig. 2.
Fault detection framework
We have built a proof-of-concept framework to support this work-flow. The
framework consist of the following three main components that are illustrated
in Figure 2. A model compiler is used to transform models into runtime libraries
containing description of the model. A compiler plug-in instruments the program
under test. At runtime, besides the model specific library, another library is
loaded into the program. This library contains generic functionality for dynamic
data flow tracking, storing state information, and reporting errors.
We claim that from the software engineering perspective for a tool to be widely
adopted it should be as automated as possible in order to reduce the amount
of costly human work. Because of this, we find reusability of models, minimum
user interaction, and accurate error reporting valuable.
Models can represent library or application specific protocols. Ideally, in order
to obtain as accurate models as possible, models should be specified by the
authors of an API and distributed with the programming library when possible.
However, this clearly won't often be the case. Therefore, models for common
APIs, e.g., the socket interface, could also be provided by the fault detection
framework developer community. Nevertheless, developers using the framework
may sometimes need to specify models themselves because there is no model
available for the API they are using, they need application specific models, or
wish to check some functionality that has not been modelled at all. Thus, the
modelling activity itself should be easy and straightforward. In addition, in order
to allow developers to easily specify program specific protocol requirements or
behavior, models should be extensible.
The models should be separated from the program's source code for two main
reasons. First, models should be reusable across programs, i.e., no changes to a
model should be required when testing two programs that use exactly the same
API. Second, to allow a tool to be easily taken into use in existing projects, the
tool should be non-intrusive from the source code point-of-view, i.e., no source
code level changes should be required in order to use the tool.
According to our experience, for a tools to be adopted into use, in addition to
the benefits for testing, easy and seamless integration into existing development
