An Eclipse Plug-in for the Java PathFinder Runtime ... - CiteSeerX

1

An Eclipse Plug-in for the Java PathFinder Runtime Verification System Ivano Rigo Universita’ degli Studi di Milano Bicocca, Milano

Francesca Arcelli Fontana Universita’ degli Studi di Milano Bicocca, Milano

Claudia Raibulet Universita’ degli Studi di Milano Bicocca, Milano

Luigi Ubezio Universita’ degli Studi di Milano Bicocca, Milano

ABSTRACT

properties along all potential execution paths/states. JPF offers many powerful extension, integration and control mechanisms and moreover it is an open source project hence it is possible to easily integrate its verification engine in other applications by modifying the JPF core to adapt it to different requirements.

Java PathFinder (JPF) is an explicit state model checker developed by the Automated Software Engineering Group of NASA of the AMES Research Center (California). Eclipse is probably the most important and used Java Integrated Developing Environment (IDE) and not only; it is a framework/environment that can be easily extended by a developer by integrating new functions by exploiting its plug-in mechanism. Through a JPF plug-in for Eclipse it is possible to integrate powerful model checking and testing capabilities into the development environment.This paper presents the re-design of the standalone version of JPF towards an Eclipse plug-in exploiting and outlining in this way the advantages of an open source development.

Eclipse [2, 7], the most popular Java IDE supplies extension points that can be used to interact with the environment and the projects or to add new graphical elements at its interface. Using the JPF model checking engine in the Eclipse IDE it is possible to analyze a software during the development phase in an easy way, using a friendly graphic user interface (GUI), giving to the developers the possibility to create a reliable software through the engineering and encoding phases. Moreover, using the Java capability of being a modeling language, it is fast to create a model for a software written in any language and test its firmware, middleware and critical hardware management properties, usually written in C, C++ or assembler. Starting from the Java model is sufficient to translate it in the original language. The JPF plug-in can be used to drive the development of various types of applications to a reliability target. Hence, in this paper we describe our interesting and useful experience gained using open source tools as the Eclipse platform for NASA projects. The detailed description of the JPF Eclipse plug-in is presented in [18]. Through the JPF Eclipse plug-in, users are able to control the JPF execution, display what it is doing and query a state. This activity started in collaboration with the NASA Automated S.E. Group, in particular under the supervision and direction of Peter Mehlitz.

1. INTRODUCTION We often rely on digital controllers to supervise critical or not critical events and to control automatic machines. Traffic control, telecommunication and cellular phones, privacy protection, ATM systems are examples of systems involving critical software, where quality assurance becomes an irrenounceable prerogative. Model checking [16, 17] is a collection of techniques for the analysis of reactive systems to verify their stability and reliability because errors in the design of safety-critical aspects can elude conventional simulation and testing techniques. A model checker takes as input a description of the software system to be analyzed, or directly the source or the executable code with a number of properties that are expected to hold.

1.1. JPF PLUG-IN TARGETS JPF [9, 10, 14] is an explicit state software model checker for the Java bytecode, with a virtual machine that executes software components, checking for properties violations like deadlocks, unhandled exceptions or user defined

The most important motivations that have driven us to develop an Eclipse Plug-in for JPF are the following:

1

• JPF is a powerful model checker for the Java bytecode [5], but it works in a command line mode, so its usage is not ”user friendly”. Using the SWT (Standard Widget Tools) provided by the Eclipse platform, to create a graphical execution and configuration environment for the JPF has become less difficult than to create a stand alone software with a graphical interface.

(the .jar files). The entire model checking verification logic resides inside the JPFs core libraries.

• Eclipse permits the iteration on projects, so that the JPF plug-in can test directly a complete project created with Eclipse. In this way the model checking of a software can be made during the development phase. • Eclipse does not have already an integrated model checker. In this way a new interesting functionality for the development platform has been added and, furthermore, there has been created the basis to integrate new additional more complex functionalities.

Figure 1: The JPF Plug-in vs. a Standard Plug-in

• Java can be easily used as a modeling language. Eclipse has a powerful environment for the Java development called JDT (Java Development Toolkit). Using these characteristics it is possible to test a model (written in Java) for a critical software or firmware written in another programming language.

As it is possible to see in Figure 1 the JPF plug-in differs from a standard implementation of a plug-in under this aspect: usually a plug-in is an ”all in one” component; both the business logic and the Eclipse interfacing functionality reside inside the ”new tool” implementation. Using the interfacing mechanisms provided by the JPF, the plug-in interacts with the model checker to command the execution according with the action made by the user on the plug-in graphical interface and reports the model checking results on the Eclipse GUI. The JPF business logic resides in these packages:

• The model checking during the development phase permits to create a reliable software in an easy way. 2. THE IMPLEMENTATION APPROACH The Eclipse plug-in [1] development has followed an engineering process [3] residing at an half-way between the standard engineering process and the extreme programming implementation approach. After studying the plug-in tasks, the development guidelines were defined and furthermore, an architectural base structure was designed. During the plug-in implementation, the architecture has been modified due to the unexpected aspects emerged from the need to add new functions, to divide the logic of very large classes in more specialized sub-classes and to follow the changes of JPF, which is still under evolution and optimization. Moreover, being the first integration of the JPF into Eclipse, the architecture has endured other changes due to the problems raised by the runtime class loading of JPF. The aspect that needed more changes regards the variable value real time debugging. This aspect has been an add-on to our plug-in features, because the first target was to give a user friendly graphical interface to JPF. The variable value real time debugging is an added value at our plug-in that permits to know the variable state when an error is detected by the JPF.

• ”open-jpf.jar”: which implements the JPF model checking core. • ”env-jpf.jar”: which implements the execution environment of the JPF. • ”env-jvm.jar”: which implements the JPF simulation virtual machine. These packages can be built by a developer who has a ”source” release of JPF. It is possible to modify some components of the the JPF model checking core to adapt it to the application before the creation of the libraries.

2.1. THE JPF PLUG-IN SOFTWARE ARCHITECTURE The Eclipse plug-in for the JPF has been designed to become an ”‘interface”’ between the Eclipse Integrated Development Environment and the core of the JPF model checker which is integrated in the plug-in using libraries

Figure 2: The JPF Core Structure for JPF Plug-in 2

The JPF core uses several functionalities implemented by these libraries (see Figure 2):

mentations can assume the following notification model. VMListeners are used to follow the detailed VM processing. VMListeners usually reside in JPF implementation packages, and are mainly intended to be an internal, nonintrusive JPF extension mechanism.

• ”bcel.jar”: which implements the run-time class loading mechanism.

Implementing the ”SearchListener” and ”VMListener” interfaces offered by the JPF, it is possible to create classes able to be triggered on all the events occured during the model checking process. After the registration of these interfaces implementation in the JPF using the ”addSearchListener” and ”addVMListener” methods, all the events will be notified to the plug-in.

• ”md5-twmacinta.jar”: which implements the md5 algorithm. • ”XercesImpl.jar”: which is an XML parser. The major design force of JPF is related to the further development and extensibility capabilities. The two major extension mechanisms are Search/VMListeners [12] and Model Java Interface (MJI) [13]. Search/VMListeners provides a convenient way to extend the JPFs internal state model, adding more complex property checks, directing searches, or simply gathering execution statistics. This is achieved by an Observer pattern [8] (see Figure 3) that lets concrete observers (listeners) subscribe to certain events inside the JPF, like bytecode instructions execution or forward/backtrack steps. Listener instances register themselves either with the Search and/or the VM object (Subject), they get notified when their corresponding Subjects perform certain operations, and can then interact with the Subject to query additional information, or even control the successive Subject behavior.

Figure 4: The Plug-in Search Listener The search listener ”PluginSL” (see Figure 4) is the JPF plug-in controller for all the events occurring during the model checking process. Some of these events have an implementation and they report information on the user interface. Other methods have an empty body because they do not give relevant information for the plug-in scope. All the methods take a ”Search” class instance as parameter. Using this class it is possible to retrieve all the information concerning the model checking process. The internal state of this class is correlated with properties verification processes and keep trace of information as the average memory used by the model checker, open backtrack number, total number of states in process, number of states completely analyzed, instantaneous amount of memory used by the model checking process. All the public methods are called directly from the JPF core when a research process event occures and all the interesting information is passed to the listener through a ”‘Search”’ class instance. The model checking events controlled violation of standard properties or user defined properties, completion of a search constraint, beginning and end of the model checking process, analysis advancement, state backtracking, end of a state processing and restoration

Figure 3: The ”Observer/Listener” Design Pattern Changed facets of the Subjects are mapped into separate Observer methods, passing in the corresponding Subject instance as a parameter. As an implementation detail, Subjects keep track of the registered listeners via limits called MultiCasters (linked lists consisting of nodes implementing the listener interface), in order to avoid runtime costs for the container traversal, which is suitable for high frequent notifications with small numbers of listeners. SearchListener instances are used to monitor the state space search process, for example, to create graphical representations of the state-graph. They provide notification methods for all major Search actions. Listener imple3

• the Plug-in loader : JPFPlugin defines the standard interface to load the plug-in components inside Eclipse.

of a pre-analyzed state. The private methods have the task to update the state of the Listener and they are called when a callback is delivered. They update information as the number of analyzed states per second, number of analyzed states per backtrack, the instantaneous memory usage and the average memory usage, the number of analyzed states and the number of open backtracks.

• the Property page: JPFSetupPropertyPage defines the interface and the business logic to create a Java PathFinder execution configuration from the Eclipse interface. Any configuration is associated with a specific project loaded in the ”Package Explorer” view. The configuration is loaded, using an Eclipse API, by the components dedicated to control the JPF execution. The page uses a mechanism to react at the selection of the user with an action listener, which keeps updated the graphical interface.

The virtual machine listener ”PluginVML” (see Figure 5) is instead triggered by all the events concerning the JPF simulation JVM. All the methods take a ”VM” or a ”JVM” class instance as parameter. Using this class it is possible to retrieve all the information concerning the simulation virtual machine. The internal state of this class is correlated with the simulation VM state and it keeps trace of information as the total number of instructions executed by the simulation JVM, the total number of exceptions generated during the simulation (it is useful both if the JPF is configured to continue the simulation and if there is an exception) and the total number of objects instanced in the simulation JVM. All the public methods are called directly from the JPF core when a Java Virtual Machine event occurs, all the information concerning the virtual machine status is passed to the callback management method using an instance of the ”VM” class following the ”listener” DP and reporting the following events: class loading, exception events, the beginning of the garbage collection phase, end of the garbage collection phase, execution of an instruction, object creation and destruction, beginning and ending of a thread.

• the Listeners: PlugInVML and PluginSL represent the direct interface with the JPF core and the analysis process. This class receives the callback from the JPF core and responses with the correct action on the plug-in state or on the graphical interface. Moreover these listeners interact with the Variable Value Management component, notifying it when to query the JPF core to retrieve a new value for a variable.

Figure 6: The JPF Plug-in Class Diagram • the Variable Value Management: This component defines classes which interact with the listeners to decide when to recharge a value of a variable from the JPF core. It has the task to monitor the variable changing value and to communicate with the view management class in order to show to the user the variable value status. In this way, it is quiet immediate to determinate the status of the software in the moment of the failure. These classes are a real time variables values monitor.

Figure 5: The JFP Plug-in Virtual Machine Listener The plug-in internal structure is not very complex; this is due to the JPF design that enables the interaction with the model checking engine in a very simple way. Considering the class diagram of the JPF plug-in (see Figure 6) the plug-in structure can be divided in the following subcomponents.

• the Controller : It consists of a single class which controls the execution of the JPF. Using this class it is 4

possible to start, stop, pause and resume the execution of JPF.

3.1. THE JFP INTERFACE INTO ECLIPSE The graphical extension points used by the application are Views of Properties Pages, which interact with other Eclipse predefined components, as the Eclipse console, to redirect the JPF output. The Standard Widget Toolkit (SWT) is a widget toolkit for Java developers that provides a portable API and a tight integration with the underlying native OS GUI platform. JFace viewers and actions provide implementations for the common interactions between applications and widgets. SWT includes many rich features, but a basic knowledge of the systems core (widgets, layouts, and events) is all that is needed to implement useful and robust Eclipse applications. The workbench defines extension points for plug-ins to contribute UI functions to the platform.

• the View: It represents the core of the plug-in. These classes react to the user choices on the GUI and use the appropriate plug-in component to interact with JPF and to redirect its ”DOS output” to the Eclipse console. Moreover, this component receives callbacks from the JPF interface classes and displays model checking process information. 3. THE ECLIPSE ENVIRONMENT The Eclipse platform provides extension points to enrich its core functionalities [4, 6]. Hence, additional functionalities or tools can be integrated in Eclipse as plug-ins through these extension points. Eclipse is composed of three high-level development layers, each layer providing a different abstraction level and functions:

A view is a workbench part that can navigate a hierarchy of information or display properties of an object. Views are often provided to support a corresponding editor. Only one instance of any given view is open in a workbench page. The extension point org.eclipse.ui.views allows plug-ins to add views to the workbench. The interface for views is defined in IViewPart, but plug-ins can choose to extend the ViewPart class rather than implement an IViewPart from scratch. The JPFExecutionView class extends the ViewPart, to inherit the views methods. Private members are prevalently the view standard methods used Eclipse to load the class or method associated to standard graphical interface events: ”contributeToActionBars”, ”fillContextMenu”, ”fillLocalPullDown”, ”fillLocalToolBar”. Protected methods are almost all the action performers and interact strictly with the ”JPFController” class that has the task to drive the execution of the JPF model checking core. The public methods of the class have mainly the task to update the information reported on the plug-in graphical interface according with the events detected by the listeners connected to the JPF core. ”JPFExecutionView” interacts with the ”ViewConstants” class that defines all the strings necessary to populate the view graphical interface.

• Platform: which defines the common and neutral programming language infrastructure. • Java Development Tools (JDT): which adds a full featured Java IDE to Eclipse. • Plug-In Development Environment (PDE): which extends the JDT to support the plug-ins development.

The ”ConsoleMng” class manages (creation and setup) the console view addicted to show the JPF output, which is normally shown in a ”Command Prompt” window. This class can be configured to redirect on Eclipse the standard output or the error output, or both. Property is a parameter configuration method associated with a particular resource. It is possible to allocate a property page for a resource by using the org.eclipse.ui.propertyPages extension point. A resources property page is invoked using the Properties menu in the resource navigator view. When the workbench creates and launches a properties page, it sets the selected resource into the page. Property pages show information about their elements. This information can be obtained by accessing an element in order to query or compute the relevant information. The information can also be stored and retrieved from the resources proper-

Figure 7: Eclipse Contribution Architecture None of them is ”built into” Eclipse. There is no monolithic tool, but a tiny kernel to which further functionalities can be added (see Figure 7). The Java environment and the Eclipse base together are more than 60 large plug-ins. At start-up, the end user should not pay attention to those plug-ins that are installed but not used: this working rule is called LAZY LOADING RULE; contributions are only loaded when they are used. The compiled form of contributions is represented by the Java class files (collected in a Java Archive [JAR] file). 5

ties. When a property is computed, there is no need for the corresponding logic to save the value, since the user cannot update this value. Properties pages are commonly used to view and set the application-specific properties of a resource. Since the property page knows its resources, the resources API can be used in the page to initialize control values or to set new property values based on user selections in the properties page. ”JPFSetupPropertyPage” is a simple properties page with two checkboxes which determine what type of variable values analysis to perform and to decide if system and JPF errors are shown on the console view. When you ”rightclick” on a project and when you select ”properties” a window with a list of properties pages will be displayed. Selecting JPF from this list, the JPF plug-in properties page will appear. The class implementing this interface defines the graphical environment and save the choices made by the user. ”JPFSetupPropertyPage” defines a set of ”static final” variables containing the strings shown on the property page interface. Furthermore, ”JPFSetupPropertyPage” defines all the methods necessary to implement the ”PropertyPage” as private or protected. These methods are necessary to create the properties page instance inside the Eclipse environment. ”JPFSetupPropertyPage” interacts with a ”SelectionListener” implementation called ”Btn1Listener”. ”Btn1Listener” is associated to the check box that enables the variables values checking and adapts the properties page graphical interface to the check box value.

Java and Sun advice users to not use this last ”Thread” method, because, deadlock errors can be easily generated when developing concurrent applications. In the JPF plug-in we are not in the presence of a concurrent application. It is possible to call these methods without problems. The usefulness is simply to stop, definitively or temporarily, a computational intensive model checking process. The JPFCleanUp method destroys a temporarily stopped model checking to free memory and resources for a new analysis. Respect to this, the JPF core implementation has been modified because it implements the ”Runnable” interface. This interface does not permit to stop, pause or resume a thread execution. While, the extension of the ”Thread” class permits a high level interaction with the JPF directly from the plug-in by simply calling a method. 4. CONCLUSIONS AND FUTURE DEVELOPMENTS The JPF Eclipse Plug-in has been developed as a working prototype, ready to be extended in order to integrate new functionalities. To test the plug-in, some projects have been built in a new Eclipse IDE with JPF Eclipse Application installed. These projects have different complexity and have been created first to test the correctness of the plug-in (simple projects act to verify the absence of errors in the application), then to stress the plug-in and JPF and moreover, to verify the system resource requirements of the model checker integrated in the IDE. The series of tests have been performed using the examples distributed in the JPF web site or using the CVS system. These series of Java samples have been specifically created by the BASA developers to test the capacity of the model checker: these are voluntary created with logical errors, assertion violation, uncaught exceptions, and deadlocks [11, 15].

The JPF core controller (see Figure 8) is a simple class: it supplies only the methods strictly necessary to create a JPF core instance and to command it. • ”JPFCreate()” creates a new JPF instance through the parameter in the string array ”args”. If the controller is unable to load a new instance a null pointer is returned.

The current version of the Eclipse application works correctly, following the prefixed specification by integrating advanced model checking functionalities and extra functions as the real time variable value debugging. The JPF Plug-in has been engineered to improve further developments and can be easily used in the Eclipse 3.0 and later versions by simply copying the ”.jar” distribution file inside the ”plugin” folder of the Eclipse IDE. The possible future developments regard the addition of new configurations for the model checking process, the extension of the graphical interface with Eclipse Rich Client, the graphical analysis of the model checking process using graphs, which are more detailed for the intermediate model checking results and for the real-time variable values debugging.

• ”JPFStart()” starts a model checking process parameterized with the settings passed to the ”JPFCreate” method. The start is performed calling the ”run” method defined by the ”Thread” interface. • ”JPFPause()”, ”JPFStart()” and ”JPFStop()” perform the action specified by the name on the model checking thread.

ACKNOWLEDGEMENTS We would like to deeply thank Peter C. Mehlitz from the Automated Software Engineering, NASA Group Ames Research Center for his always valuable advices and suggestions during this work. We greatly thank also John Figure 8: The JPF Controller Class Diagram 6

Penix and Masoud Mansouri-Samani of the same Research Center.

[15] C. S. Pasareanu, Willem Visser - NASA Ames Research Center. Verification of Java Programs using Symbolic Execution and Invariant Generation, Proceedings of SPIN 2004. Barcelona, Spian, April 2004 . LNCS 2989.

REFERENCES

[2] Steve Holzner - Eclipse CookBook, O’Reilly; June 2004

[16] D. Giannakopoulou, C. S. Pasareanu, J. M. Cobleigh. - NASA Ames Research Center. Assume-guarantee Verification of Source Code with Design-Level Assumptions, Proceedings of the the 26th International Conference on Software Engineering (ICSE). Edinburgh, Scotland. May 2004.

[3] Ian Sommerville - Software Engineering (6th Edition), Addison Wesley; 6 edition, August 11, 2000.

[17] Stephan Merz Overview, 2002.

[4] IBM Corp. - http://download.eclipse.org/ eclipse/downloads/documentation/2.0/html/ plugins/org.eclipse.platform.doc.isv/; 2000, 2001. Eclipse - Platform Plug-In Developer Guide

[18] Ivano Rigo - An Eclipse Plug-In for the Java PathFinder Runtime Verification System, Master Thesis, University of Milano-Bicocca, Italy, Decembre 2005.

[1] Erich Gamma, Kent Beck - Contributing to Eclipse: Principles, Patterns, and Plug-Ins, Addison Wesley; October 20, 2003.

[5] IBM Corp. - http://download.eclipse.org/ eclipse/downloads/documentation/2.0/html/ plugins/org.eclipse.platform.doc.isv/; June 20, 2002 Java Development Tooling overview [6] IBM Corp. - http://download.eclipse.org/ eclipse/downloads/documentation/2.0/html/ plugins/org.eclipse.platform.doc.isv/; June 20, 2002 Using the Plug-in Development Environment [7] IBM Corp. - http://download.eclipse.org/ eclipse/downloads/documentation/2.0/html/ plugins/org.eclipse.platform.doc.isv/; 2000, 2004. Welcome to Eclipse [8] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - Addison-Wesley Professional, 1st edition; January 15, 1995. Design Patterns: Elements of Reusable Object Oriented Software [9] Peter C. Mehlitz, Willem Visser, John Penix - NASA Ames Research Center, April, 2005. The JPF Runtime Verification System [10] http://ase.arc.nasa.gov/jpf/JPF-user-guide. html Java Path Finder Version 3.1.1 User Guide [11] Willem Visser, Corina S. Pasareanu, Sarfraz Khurshid - NASA Ames Research Center. Test Input Generation with Java PathFinde, Proceedings of ISSTA 2004. Boston, MA, July 2004. [12] JPF Listeners - http://ase.arc.nasa.gov/jpf/ Listeners.html Search and VMListeners - the JPF Extension Structure [13] MJI Interface - http://ase.arc.nasa.gov/jpf/ Mji.html MJI - the Model Java Interface [14] Willem Visser, Klaus Havelund, Guillaume Brat, SeungJoon Park and F. Lerda - NASA Ames Research Center Model Checking Programs, Automated Software Engineering Journal. Volume 10, Number 2, April 2003. 7

Model Checking:

A Tutorial