1 / 49

BOGOR – A Flexible Framework For Creating Model Checkers

BOGOR – A Flexible Framework For Creating Model Checkers. Presented by : Roli Shrivastava 20 March 2007. Model Checking. What is Model Checking?. Model checking is a process of checking whether a given model satisfies a given logical formula. MODEL CHECKING.

phyland
Télécharger la présentation

BOGOR – A Flexible Framework For Creating Model Checkers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 MODEL CHECKING • 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

  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: http://courses.projects.cis.ksu.edu/index.php

  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: -2147483648 to 2147483647) 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 <i < 1> do i := i + 1; when <i < 2> do i := i + 2; else do i := i + 3; end end } } BIR Cited: http://bogor.projects.cis.ksu.edu/manual/ch02s14.html

  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: http://bogor.projects.cis.ksu.edu/manual/ch02s14.html BIR

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

  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: http://courses.projects.cis.ksu.edu/index.php

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

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

  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: http://courses.projects.cis.ksu.edu/index.php

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

  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: http://courses.projects.cis.ksu.edu/index.php

  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: http://courses.projects.cis.ksu.edu/index.php Tier-3 I-searcher - BOGOR

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

  37. I-SCHEDULER MODULE Cited: http://courses.projects.cis.ksu.edu/index.php Tier-3 I-scheduler - BOGOR

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

  39. Continues…. Cited: http://courses.projects.cis.ksu.edu/index.php 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: • IValueFactory: • Concrete value representations symbolic value representations. • IStateFactory: • State representations of the data structure symbolic data values and to include data constraints. • IStateManager: • Kiasan’s symbolic execution engine performs stateless Search. • The traditional state matching is changed to never store states stage. • 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??

More Related