Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

bogor-roli-1

VIEWS: 7 PAGES: 49

									         BOGOR – A Flexible
Framework For Creating Model
Checkers
           Presented by :

        Roli Shrivastava
           20 March 2007

                               1
Model Checking

  What is Model Checking?



                            2
MODEL CHECKING

Model checking is a process of checking whether a given
model satisfies a given logical formula

   Effective technology for verification and debugging in hardware and
    more recently in software domains.

   Detecting coding flaws that are hard to detect using existing quality
    assurance methods

   Verifying that system models and implementations satisfy crucial
    temporal properties




                                                                            3
                            Model checking
WHATS WRONG with EXISTING TOOLS??
   Motivation for domain-specific model checking…..

       Existing Model Checkers tools are Spin, FDR and NuSMV
          support fixed input languages
          state-space representations
          reduction and exploration algorithms.


       Model-driven development :
          Domain-specific model checkers are more effective than general
           purpose model checkers.

       Product-line architectures and reusable middleware infrastructure.




                                                                             4
                                Model checking
Continued…

   Synergistic blending of automated quality assurance technique.

   Sheer variety of application domains and computation models.




                                                                     5
                          Model checking
SOLUTION to the ABOVE PROBLEM

                            BOGOR
   Developed by the SAnToS Group at Kansas State University and
    the ESQuaReD Group at University of Nebraska (Lincoln).
    Bogor is an extensible and customizable software model checking
    framework
       state of the art software model checking algorithms
       Visualizations
       user interface designed to support both general purpose and
        domain-specific software model checking.



                                                                      6
                            BOGOR
WHY BOGOR?

In contrast to many model checkers,

   Bogor is a highly modular and extensible software model
    checking framework

   well-designed API using design patterns make it possible
    to add/replace/refine module implementations

   crucial features for domain-specific customizations


                                                           7
                       BOGOR -Features
WHY BOGOR continues…

   Features:

       Direct Support of OOL

       Extensible Modeling Language

       Open Modular Architecture

       Design for Encapsulation

       Pedagogical Materials



                                               8
                             BOGOR -Features
    FEATURES in DETAIL
   Direct support of features (object-oriented)
      dynamic creation of threads and objects
      object inheritance
      virtual methods
      exceptions, garbage collection, etc.


   Bogor's modeling language can be extended
      new primitive types
      expressions, and commands associated with a particular
       domain (e.g, multi-agent systems, avionics, security protocols,
       etc.)
      a particular level of abstraction (e.g., design models, source
       code, byte code, etc.).


                                                                         9
                          BOGOR -Features
    FEATURES contd…
   Bogor's open architecture well-organized module facility allows new
    algorithms
      for state-space exploration, state storage, etc
      new optimizations (e.g., heuristic search strategies, domain-
       specific scheduling, etc.)

   Bogor has a robust feature-rich graphical interface implemented as
    a plug-in for Eclipse

   Bogor is an excellent pedagogical vehicle for teaching foundations
    and applications of model checking
      it allows students to see clean implementations of basic model
       checking algorithms
      to easily enhance and extend these algorithms in course projects




                                                                          10
                             BOGOR -Features
Cited: http://courses.projects.cis.ksu.edu/index.php

                                                       11
BIR : BOGOR Intermediate
Representation
   Supported types

    - basic: boolean, int, long, float, double
    - range types: int (lower, upper), long (lower, upper)
    - enumeration types: enum cards {spades, hearts, clubs, diamonds}
    - Non-primitive types
      record, array, string, lock, extensions


    All types in BIR are bounded (finite) (e.g., int: -2147483648 to
       2147483647) have a default value (e.g., int, long: 0)




                                                                       12
                                    BIR
BIR Cont’d
   Scope: functions and threads have own namespace, but can’t hide
    with global declarations

   Locations: control pts in threads

   Jump and Catch statements

   Actions: assign, assert, assume, lock, throw, exit




                                                                      13
                                        BIR
    BIR: HIGH LEVEL / LOW LEVEL SYNTAX

   High level Syntax
      Used for manual understanding and model construction
      Includes high-level programming constructs:
          atomic, while, if, else-if, else, try, catch, skip, return, choose

      During model checking, converted to low level


   Low level Syntax
      Used for automatic model extraction
      Interleaving only happen between locations
      Basic syntax:
          loc[ation], live, do, when, visible, goto, catch, return




                                                                                14
                                     BIR
    Example: CounterExample

        High-level
    system CounterExample {
      int i := 0;

        active[3] thread MAIN() {
          atomic
             choose
               when <i < 1> do
                 i := i + 1;
               when <i < 2> do
                 i := i + 2;
               else do
                 i := i + 3;
             end
           end
        }
    }


                                                                     15
Cited: http://bogor.projects.cis.ksu.edu/manual/ch02s14.html   BIR
    BIR Low Level
system CounterExample {
 int i := 0;

    active [3] thread MAIN() {
     boolean temp$0;
     boolean temp$1;
     boolean temp$2;
     ANY_THROWABLE atomicCatch$Local;

        loc loc0: do { Atomic.beginAtomic(); } goto loc1;
        loc loc1: do invisible {
                temp$0 := i < 1;
                temp$1 := i < 2;
                temp$2 := !((temp$0 || temp$1));
               } goto loc2;
        loc loc2: when temp$0 do invisible { } goto loc3;
               when temp$1 do invisible { } goto loc5;
               when temp$2 do invisible { } goto loc7;
        loc loc3: do { i := i + 1; } goto loc4;
        loc loc4: do { } goto loc9;
        loc loc5: do { i := i + 2; } goto loc6;
        loc loc6: do { } goto loc9;
        loc loc7: do { i := i + 3; } goto loc8;
        loc loc8: do { } goto loc9;
        loc loc9: do { Atomic.endAtomic(); } goto loc10;
        loc loc10: do { } return;
        loc atomicCatch: do {
                     Atomic.endAtomic();
                     throw atomicCatch$Local;
                   } goto atomicCatch;
        catch ANY_THROWABLE atomicCatch$Local at loc1, loc2, loc3,
            loc4, loc5, loc6, loc7, loc8 goto atomicCatch;
    }

    extension Atomic for edu.ksu.cis.bogor.projects.bogor.ext.atomicity.AtomicModule {
      actiondef beginAtomic ();
      actiondef endAtomic ();
    }                                                   Cited: http://bogor.projects.cis.ksu.edu/manual/ch02s14.html
        throwable record ANY_THROWABLE {}                                                                     16
}                                                                               BIR
Cited: http://courses.projects.cis.ksu.edu/index.php   17
COMPONENTS and MODULES
   Front-End Components
provide access to in-memory representations of BIR models


   Interpretative Components
provide access methods and data structures to interpret BIR models


   Model Checking Components
provide implementations of model checking algorithms




                                                                     18
                       Modular Architecture - BOGOR
             Tier1 : Front End Module


The following slides discuss about the Front End
                     Module




                                                   19
Cited: http://courses.projects.cis.ksu.edu/index.php
                                                       20
Cited: http://courses.projects.cis.ksu.edu/index.php
                                                       21
Cited: http://courses.projects.cis.ksu.edu/index.php
                                                       22
SUMMARY OF TIER-1

   Bogor, like an Interpreter/compiler has front-end module
      to process a BIR model textual representation
      Build an in-memory representation suitable for analysis/model checking


   The basic front-end has
        Lexer
        Parser
        Well-formed-ness checke
        + some data structures ( AST, symbol table etc)




                                                                           23
                       Tier-1 Summary - BOGOR
     TIER 2 : Interpretative
     Component Module


The slides following would discuss this component




                                                    24
Cited: http://courses.projects.cis.ksu.edu/index.php

                                                       25
Cited: http://courses.projects.cis.ksu.edu/index.php


                                                       26
I-VALUE FACTORY

   Values are created using the I-Value Factory

   Provide access methods to :-
     i) get the type of the value.
    ii) create the default value of a certain type.
    iii) create new int values, with or without types.




                                                         27
                       Tier-2 I-value - BOGOR
I-STATE FACTORY
provide methods to:

   create the initial state

    i) needs to provide an interface to wrap state data:
     for example, global values, the local values of each
    thread, and the location of each thread, and the thread
    ids

    ii) can be extended to provide additional information

   create thread descriptors (guaranteed to be unique)


                                                              28
                        Tier-2 I-state - BOGOR
IExpEVALUATOR MODULE

   evaluates an expression in a given context

    ISchedulingStrategyContext
        contains methods to access the state and the executing thread
        id




                                                                     29
                        Tier-2 I-expEval - BOGOR
I-ACTION EVALUATOR MODULE

   execute an action in a given context ignore the array of
    IBacktrackingInfo for now

   action executions usually change the state




                                                               30
                   Tier-2 I-action - BOGOR
SUMMARY OF TIER-2

   BOGOR Interpretative components are similar to an imperative
    Language interpreter’s
      has a module to evaluate expressions
      Has a module to evaluate actions


   Factories are used to create Values and States , thus decoupling
    usage and creation

   Several Data-structures are generated/ used for model checking




                                                                       31
                         Tier-2 summary - BOGOR
                  Tier 3 : Model Checking Module


The coming slides discusses Model checking Module in detail.




                                                        32
Cited: http://courses.projects.cis.ksu.edu/index.php
                                                       33
I-SEARCHER MODULE

   Navigating the State Space

   I-Searcher controls how we traverse the state space
    graph.




                                                          34
                    Tier-3 I-searcher - BOGOR
Cited: http://courses.projects.cis.ksu.edu/index.php
                                                       35
             Tier-3 I-searcher - BOGOR
                                                       36
Cited: http://courses.projects.cis.ksu.edu/index.php
I-SCHEDULER MODULE




     Cited: http://courses.projects.cis.ksu.edu/index.php
                                                            37
                Tier-3 I-scheduler - BOGOR
STEPS FOR SCHEDULING




    Cited: http://courses.projects.cis.ksu.edu/index.php
                                                           38
                    Tier-3 I-scheduler - BOGOR
Continues….




    Cited: http://courses.projects.cis.ksu.edu/index.php
                                                           39
                  Tier-3 I-scheduler - BOGOR
WHY Do We Need I-Scheduler
   ���� Used to:
      determine enabled transitions
      determine which transition to take
      create strategy information


   ���� DefaultSchedulingStrategist
      Full state-space exploration
         the scheduling policy ensure that each state is visited
      At each choice point, the info contains
         the number of enabled transitions, and
         the last chosen transition index
      advise() simply increase the last chosen transition index until
      all are chosen




                                                                         40
                      Tier-3 I-scheduler - BOGOR
I-BACKTRACKING
   Since the analyzer is not holding states in the stack, if it
    needs to back-track and return to a previously encountered state, it
    needs an “undo” operation to run the transitions in the reverse
    direction.

   Information needed to backtrack
      state, thread ID, etc.


   scheduling information like
      which nondeterministic choice was made, if any
      specific info for each kind of action, transformation, etc.




                                                                           41
                         Tier-3 I-backtracking - BOGOR
I-STATE MANAGER MODULE

   Used to keep track states that have been visited before storing the
    states

   Also, assigns a unique number for each stored state (state id)

   Hence uses the number instead of the actual state in the DFS stack.




                                                                          42
                        Tier-3 I-state-manager - BOGOR
SUMMARY FOR TIER-3

   Implementations of Model checking functional aspects are modular

   Can be customized to a specific-domain application:
      Search algorithms can be customized to used heuristics to find
       bugs faster
      Scheduler can be customized to enforce a specific scheduling
       policy
      State manager can be customized to allow different encodings




                                                                        43
                       Tier-3 Summary- BOGOR
IS BOGOR FLEXIBLE ?? ( KIASAN )
    Kiasan – A Verification and Test-Case Generation Framework for
     Java based on Symbolic Execution

    Built by customizing the following Bogor Modules:
1.   IValueFactory:
        Concrete value representations           symbolic value
         representations.
2.   IStateFactory:
        State representations of the data structure       symbolic data values
         and to include data constraints.
3.   IStateManager:
        Kiasan’s symbolic execution engine performs stateless Search.
        The traditional state matching is changed to never store states stage.
4.   JVM Extension Interpretation:
        The JVM code in Bogor            a code that interprets byte codes
         including exploration of conditional paths as well.

                                                                                  44
                                     Kiasan
Capabilities of KIASAN

   automatic checking of code against user-supplied
    contracts

   flexible control over the depth/coverage of checking by
    adjusting tool parameters

   automatic generation of both abstract and concrete
    execution path

   automatic generation of JUnit test cases



                                                              45
                            Kiasan
Bogor within the development Process
   Eclipse-Based Graphical user Interface
        Eclipse like Bogor is implemented in JAVA => tight integration of Bogor
         and its GUI contents and extensions.


   Encapsulation in other tools
      Developing Bandera, Cadena ( for CORBA ) by customizing BOGOR.
      Helped in space and time improvements (more than 3 times as
       compared to SPIN / dSPIN)


   Placement of model checking in a development process
        Model checking at design time
           Space state will be smaller




                                                                                   46
SUMMARY of EXPERIENCE using BOGOR

   In 1 year Bogor has been downloaded more than 1000 times by
    individuals in 32 countries.

   Till date, more than 35 substantive extensions of Bogor.

   Has around approx 23 APIs
        Extensions requires generally few 100 lines of code
        Mostly modeled from the already existing extensions


   It is a robust and well-reasoned foundation : used for modern
    Software systems.



                                                                    47
                                Summary of Exp
ANY QUESTIONS??




                  48
49

								
To top