Symbolic Model Checking of Declarative Relational Models - PowerPoint PPT Presentation

1 / 10
About This Presentation
Title:

Symbolic Model Checking of Declarative Relational Models

Description:

Advantages of using declarative modeling: ... Background Information (Current Model Checkers) ... SLAM: Used on C programs generates its own boolean abstraction. ... – PowerPoint PPT presentation

Number of Views:78
Avg rating:3.0/5.0
Slides: 11
Provided by: Dan5278
Category:

less

Transcript and Presenter's Notes

Title: Symbolic Model Checking of Declarative Relational Models


1
Symbolic Model Checking of Declarative Relational
Models
  • byDaniel Jackson Felix Sheng-Ho Chang
  • Massachusetts Institute of Technology
  • 28th ICSE Conference 2006
  • pp. 312 - 320  

Poster by Daniel Utz
2
Summary
  • Using a model checking tool requires designing a
    model that can be accepted into a particular
    tool. Most tools and modeling methods use
    temporal logic and imperative modeling.
  • The authors (in previous work) have shown the
    structure of object-oriented programs can simply
    and clearly be modeled declaratively using sets,
    relations, and relational operators, but few
    tools incorporate this.
  • Advantages of using declarative modeling
  • The modeling is more instinctive for programmers
    which allows modeling of more complicated
    applications.
  • Allows the specification to be more concise which
    lessens the chance of bugs and system-specificatio
    n mismatch.
  • The authors (also, previous work) have worked on
    tools (Alloy) that utilize declarative modeling
    and relational logic .
  • This paper seeks to demonstrate the next step -
    that these techniques can be incorporated into,
    or combined with, more traditional model
    checkers.

3
Background Information(Current Model Checkers)
  • SMV (NuSMV) Based on Binary Decision Diagrams
    (BDD). Uses temporal logic and descriptions of
    Kripke structures. No support for relation
    operators.
  • SLAM Used on C programs generates its own
    boolean abstraction. No support for relation
    operators.
  • SPIN Also uses temporal logic. No support for
    relation operators.
  • Alloy Supports relation operators. Does not
    combine declarative and imperative modeling.
  • B Supports relation operators. Does not check
    finite states which allow the checking to be
    automated.

4
Background Information
  • BDD (Binary Decision Diagram)
  • Kripke Structure

x 1 If() x 2
CTL (Computational Tree Logic) 8 possible CTL
operators AG, AX,AF, AU, EG, EX, EF, and EU.
AG(x1 -gt x'2) True AG(x2 -gt x'1) False
5
Concepts
  • Core Language Syntax
  • Expr emptyset Variable Expr - . -gt
    Expr Expr
  • Formula true false Variable Formula
    gt Formula
  • ! Formula AG AX AF AU EG EX EF EU
  • all some one no lone Variable Formula
  • all some one no lone Expr Expr in Expr
  • Statement Var Expr Var Formula
    Formula
  • if Formula Statement
  • if Formula Statement else Statement
  • foreach VariableExpr Statement
  • FunctionName(Expression, Expression,
    )

6
Concepts
  • Imperative statements
  • Models an action
  • ABC
  • Declarative statement
  • Models an effect
  • A A A !in B

7
Concept
  • Java Code Snipet
  • Vector topoSort(String root, Hashtable targets)
  • Vector ret new Vector()
  • Hashtable state new Hashtable()
  • Stack visiting new Stack()
  • tsort(root, targets, state, visiting, ret)
  • for (Enumeration en targets.keys()
    en.hasMoreElements())
  • String curTarget (String) en.nextElement()
  • String st (String) state.get(curTarget)
  • if (st null) tsort(curTarget,targets,state,v
    isiting,ret)
  • else if (st VISITING) throw new
    RuntimeException(..)
  • return ret
  • Corresponding Model
  • toplevel void topoSort()
  • badfalse

8
Concepts
  • Challenges
  • Finding the right mix of imperative and
    declarative modeling for the language.
  • Finding efficient algorithms .
  • Optimization.

9
Critique
  • The paper does well describing the significance
    of their proposal and its benefits.
  • It also does well describing in general terms why
    current methods fall short.
  • The stated goal is to enable programmers to
    write very intuitive and compact specifications,
    in order to allow the automatic verification of
    more complicated software systems. The paper
    does not do well showing how their methods reach
    this goal more than current methods.
  • The paper spend too much time describing their
    syntax without comparing this to current checker
    syntax.

10
Questions
  • What type of logic and what type of modeling do
    tradition model checkers use?
  • What type of modeling do the authors add?
  • Alloy ( a current model checker ) uses similar
    concepts as the authors. What unique concept do
    the authors add that Alloy does not?
Write a Comment
User Comments (0)
About PowerShow.com