Bandera Extracting Finite-state Models from Java Source Code

Document Sample
Bandera Extracting Finite-state Models from Java Source Code Powered By Docstoc
					Bandera: Extracting
Finite-state Models from
Java Source Code
James C. Corbett (Hawai’i)
Matthew B. Dwyer, John Hatcliff, Shawn Laubach,
Corina S. Păsăreanu, Robby, Hongjun Zheng (KSU)

Presented by Christian Almazan
18 November 2003 (CMSC 631)
         Model Checking in One Slide
             Finite-State Model   Model Checker   Verified
                                  • SPIN
                                  • dSPIN
                                  • SMV
Temporal Logic Formula            •…              Counter-Example
• Linear Temporal Logic (LTL)
• Computation Tree Logic (CTL)




            Automatic specification verification
            Covers all possible paths in the model
            Popular in hardware and protocol verification
Difficulty in Bringing
Model Checking to Software
   State-Explosion Problem
       States increase exponentially as program size grows
   Model Construction Problem
       Development in a general-purpose language
       Verification tools use an specification language
   Requirement Specification Problem
       Specification languages tend to be mathematical
       Hard to use, read, debug, very lengthy
   Output Interpretation Problem
       Counter-example long and complex
       Hard to map directly to source code
Problems in Previous Efforts

   Monolithic Approach
       Model checker for a specific language (Erlang)
       Difficult to place newer model checking techniques
   Source Code  Verifier Input Language
       Translates program directly from source code
       JCAT or Java PathFinder to PROMELA for SPIN
       Program Size Increases = Exponential State Growth
   Combined Problems
       Keeps developers tied to one technology
       Limited support for control and data abstraction
Overcoming Obstacles:
Bandera
   Use proven model checkers
       SPIN, dSPIN, Java PathFinder
   Automated transformations
       Compacting number of states
   Use individual models for each property
   Design for extensibility
       Build individual components
   Create a friendly environment
       Familiar, uniform, specifications easy to learn
       Leveraged for testing, debugging, and simulation
Bandera Components
Program Infrastructure

   Built on top of the Soot compiler framework
       Uses control-flow graph language Jimple
       Language used by all middleware components


   Java-to-Jimple-to-Java Compiler (JJJC)
       Easily use internal tools and return Java code
       Allows model checker counter-examples to be
        mapped back into original Java source code
Property Specification

   Bandera Specification Language (BSL)
       Collection of temporal specification patterns in English
       Parameterized macros  LTL or CTL


   Defined in source code directly using Javadoc

   Not mathematical like LTL or CTL
Bounded Buffer Specification

If a buffer becomes full, it will eventually become non-full.

/**
 * @observable
 *   EXP Full(this): (head == tail);
 *
 *   FullToNonFull: forall[b:BoundedBuffer];
 *       {!Full(b)} responds to {Full(b)} globally
 */
class BoundedBuffer {
    ...
}
Static Analysis

   Bandera Object Flow Analysis (BOFA)
       Optimizations: data/control analysis
       Statically collects information about objects that may
        flow into each program expression at runtime
   Associates a set of tokens { t1, …, tn } for a
    particular expression e.
       ti is a pair (C,s): C is a class name and s is where
        object is created
   Similar to “points to” analysis for imperative
    languages and “closure analysis” used for
    functional programming languages
Slicing
                                                  In Property

                                                  Relevant




   Given program P and slicing criterion  based
    on the observables in the specification…
   Does program dependence-based slicing to get
    a reduced version of P
       dependences: data, control, interference, ready, wait
       backwards slicing
   Effectiveness based on structure of program
Abstract Interpretation

   Further reductions through data abstraction
   Useful when specification does not need
    concrete values, but only properties of values
   Developers aid abstraction libraries: Bandera
    Abstraction Specification Library (BASL)
   Utilizes the PVS theorem prover
   Examples
       integers to signs: { positive, zero, negative }
       vector items: { ItemInVector, ItemNotInVector }
Back End Model Generation

   Bandera Intermediate Representation language
    (BIR)
       Jimple-BIR: BIR Constructor
       Used between Bandera components and model
        checker input languages
   Model checker writers only need to write a
    translator from BIR to their input language
   BIR contains higher-level constructs to model
    Java code more efficiently
       locks, threads, references, heap
Bandera Components
    Using Bandera




   Launch the Bandera User Interface (BUI) from
    the command line
   Future runs: save which components you want
    to use in session files
Counter-Example: Overview

   Counter-example with a thousand states?!?!

   Bandera provides debugger-like features:
       map states to source code
       program tracing
       create checkpoints
       keep track of variables and objects
       UML-like object displays
       lock graphs
Counter-Example:
Program Tracing
Counter-Example:
Lock Graph
Counter-Example:
Object Viewer
            Mandatory Performance Slide
Problem Extract Check     Check    States
        Time (s) Time (s) Result
b, r1, n   24    2674     true     7338120   Threaded Pipeline
b, r1, s   13    4        true     3478      b: basic
b, r1, a   15    4        true     895       d: defective variant

b, r2, s   13    56       true     528059    r: response property
                                             p: precedence property
b, r2, a   16    11       true     27519
b, p1, s   13    4        true     2507      n: no reductions
                                             s: slicing
b, p1, a   15    4        true     331       a: slicing + data abstraction
d, r1, s   13    3        false    88
d, r1, a   15    2        false    17
When to Use Model Checking

   Control-related properties
       assertions
       pre- and post-conditions
       simple data invariants
   Container objects
       stacks
       queues
   Verifying concurrent behavior
   Necessity for counter-examples
   Automatic property verification of source code
Analysis Not Appropriate for
Model Checking
   Data-related properties
       Verification of sorting algorithms
       Use other formal methods instead (theorem proving)


   Where static dataflow analysis is better
       array-bounds errors
       buffer overruns
       null-pointer de-referencing
The Future of Bandera

   Bandera 0.3b2        Summer 2003
   Bandera 1.0          Summer 2004
       No more command line startup
       Collection of plug-ins for the Eclipse IDE
       All features re-deigned, re-implemented, re-done
   Future of Model Checking?: Bogor (KSU)
       Forget supporting other model checkers in Bandera
       Bogor is a big step in model checking?
Links and Related Work

   Try Me!
       http://bandera.projects.cis.ksu.edu/
   Visit Citeseer for abstraction and slicing papers
   Model Checkers: SPIN, dSPIN, JPF
   Source Code Translators: JPF, JCAT
   Many More! Use Google!
Questions?

   Learn anything from this talk or the class?
   Would you use model checking? If so, when?
   Do you like the push for the original Bandera?
   Using only Eclipse a good idea?
   Why stop supporting other model checkers?
       Support their own tool Bogor?
       Too time consuming writing BIR translators?
       A dream writing BIR, universal language?