1 BOGOR – A Flexible Framework For Creating Model Checkers Presented by : Roli Shrivastava 20 March 2007

2 Model Checking What is Model Checking?

3 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 MODEL CHECKING Model checking

4 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. Model checking

5 Continued… Synergistic blending of automated quality assurance technique. Sheer variety of application domains and computation models. Model checking

6 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. BOGOR

7 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 BOGOR -Features

8 WHY BOGOR continues… Features:  Direct Support of OOL  Extensible Modeling Language  Open Modular Architecture  Design for Encapsulation  Pedagogical Materials BOGOR -Features

9 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.). BOGOR -Features

10 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 BOGOR -Features

11 Cited:

12 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: to ) have a default value (e.g., int, long: 0) BIR

13 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 BIR

14 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 BIR

15 Example: CounterExample High-level system CounterExample { int i := 0; active[3] thread MAIN() { atomic choose when do i := i + 1; when do i := i + 2; else do i := i + 3; end } Cited: BIR

16 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 (); } throwable record ANY_THROWABLE {} } Cited: BIR

17 Cited:

18 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 Modular Architecture - BOGOR

19 Tier1 : Front End Module The following slides discuss about the Front End Module

20 Cited:

21 Cited:

22 Cited:

23 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) Tier-1 Summary - BOGOR

24 TIER 2 : Interpretative Component Module The slides following would discuss this component

25 Cited:

26 Cited:

27 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. Tier-2 I-value - BOGOR

28 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) Tier-2 I-state - BOGOR

29 IExpEVALUATOR MODULE evaluates an expression in a given context ISchedulingStrategyContext  contains methods to access the state and the executing thread id Tier-2 I-expEval - BOGOR

30 I-ACTION EVALUATOR MODULE execute an action in a given context ignore the array of IBacktrackingInfo for now action executions usually change the state Tier-2 I-action - BOGOR

31 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 Tier-2 summary - BOGOR

32 Tier 3 : Model Checking Module The coming slides discusses Model checking Module in detail.

33 Cited:

34 I-SEARCHER MODULE Navigating the State Space I-Searcher controls how we traverse the state space graph. Tier-3 I-searcher - BOGOR

35 Cited: Tier-3 I-searcher - BOGOR

36 Cited:

37 I-SCHEDULER MODULE Cited: Tier-3 I-scheduler - BOGOR

38 STEPS FOR SCHEDULING Cited: Tier-3 I-scheduler - BOGOR

39 Continues…. Cited: Tier-3 I-scheduler - BOGOR

40 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 Tier-3 I-scheduler - BOGOR

41 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. Tier-3 I-backtracking - BOGOR

42 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. Tier-3 I-state-manager - BOGOR

43 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 Tier-3 Summary- BOGOR

44 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. Kiasan

45 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 Kiasan

46 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

47 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. Summary of Exp

48 ANY QUESTIONS??

49