verification of object oriented programs with invariants n.
Skip this Video
Download Presentation
Verification of object-oriented programs with invariants

Loading in 2 Seconds...

play fullscreen
1 / 31

Verification of object-oriented programs with invariants - PowerPoint PPT Presentation

  • Uploaded on

Verification of object-oriented programs with invariants. Mike Barnett, Robert DeLine, Manuel Fahndrich, K. Rustan M. Leino, Wolfram Schulte ECOOP 2003 workshop on Formal Techniques for Java-like Programs. Encapsulation Seminar TAU 2005 Presented by Yossi Peery. Agenda. Introduction

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Verification of object-oriented programs with invariants' - apollo

Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
verification of object oriented programs with invariants

Verification of object-oriented programswith invariants

Mike Barnett, Robert DeLine,

Manuel Fahndrich, K. Rustan M. Leino,

Wolfram Schulte

ECOOP 2003 workshop on Formal Techniques for Java-like Programs

Encapsulation Seminar TAU 2005

Presented by Yossi Peery

  • Introduction
    • Motivation and Background
    • Object Invariants and Information Hiding
  • Solution
    • Basic Methodology Concepts
    • Adding Components and Subclasses
    • Modifies Clause and Dynamic Dispatching
    • Examples
  • Conclusion
why use object invariants
Why Use Object Invariants
  • Definition:

“A relation on an object’s data that the programmer intends for to hold”

  • Detect and prevent
    • Data corruption errors
    • Misuse of the object data
  • Formal methods allow automatic static verification of program invariants
  • Hoare’s 1972

“Proof of correctness of data representations”

  • Eiffel
    • Pioneer Design by Contract technique
    • Dynamically checks invariants at run-time
  • Peter Muller 2001
    • An OO language providing useful guarantees about when object invariants hold
    • Uses “Universe Type System” as an ownership model
    • Object invariants modeled by a boolean function on the object’s data
reentrancy problem
Reentrancy Problem

public method P (…)


M ();


invariant misconception
Invariant Misconception
  • General View:

An invariant is an implicit post-condition on every constructor and an implicit pre- and post-condition on every public method

  • Misconception:
    • Callers of an object’s methods do not need to establish the implicit pre-condition of the invariant.
    • It is sufficient to restrict modifications of the invariant to methods of an object and establish it before the method ends
explicit invariant condition
Explicit Invariant Condition
  • It will not be possible to call M from a function P that doesn’t ensure its invariant. Or,
  • It will not be possible to call a function P that ensure the invariant from the middle of M
problem of information hiding
Problem of Information Hiding
  • Invariants are conditions on the internal representation of objects
  • Explicit pre- and post-conditions are a breach of good information hiding
  • Conflict between revealing implementation details and the need for clients to know whether the object invariant holds
  • Same problem exists for modifies clause
basic methodology concept
Basic Methodology Concept
  • Provide an explicit representation of when object invariants are known to hold
    • Add special public field st to every object. = Invalid  o is invalid = Valid  o is valid

    • An object’s invariant holds whenever the object is valid
  • Restrictions
    • st can appear only in routine specifications
    • st can be modified only by special new statements:

pack & unpack

    • Objects are allocated with = Invalid
basic methodology concept1
Basic Methodology Concept
  • InvT(o) :

predicate to indicate that the invariant of object o of class T holds.

Using class T from previous example:

restrictions and validity
Restrictions and Validity
  • Object field updates can break invariant:
    • Field update statements: o.f := E
    • Permitted only where = Invalid
    • InvT(o) can depend only on internal fields of o
  • If the above restrictions hold then the following is a program invariant:

where o ranges over non-null objects of type T

  • Proof by induction over structure of program statements
  • Objects are usually built in a hierarchy of layered abstractions
    • A “Buffered Input Stream” can be implemented in terms of a cache and a file reader objects
  • Program correctness may depend on relations between fields of an objects and fields of its components
  • Need to expend previous restrictions
  • If t.f = u then update of u.g breaks T’s invariant
  • Need to make sure that: = Invalid => = Invalid = Valid => = Committed

  • Committed state indicates Ownership
    • If = Commited then t owns t.f
    • Creates hierarchy of owned objects
  • Use repmodifier to indicate that a field is a component:

private rep f : U;

  • Object invariants can now depend on this.f0.f1.f2. … .g where fi are declared with the repmodifier

st : { Invalid , Valid, Committed}

CompT(o) = { o.f : f is a rep field in T }

  • Program Invariant:
  • Unique Ownership:
  • Ownership Transfer:
  • Object divided into class frames
  • Each frame can be valid or invalid
    • possible subsets
  • Consider only nonempty prefixes
    • { object }
    • { object, A }
    • { object, A, B }
new encoding
New Encoding
  • Instead of st:
    • Special field inv holdstype of most derived valid class
    • Special field committed is boolean indicating if object is committed

committed = TRUE => inv = type(o)

  • New objects of type T should return from theconstructor as:

inv = T & !commited

  • Field updates of subclass allowed if object is “sufficiently unpacked”
  • Invariants may contain fields of subclasses
new encoding1
New Encoding

T extends S

ois any subclass ofT

soundness theorem
Soundness Theorem

The following are program invariants

(ranges over non-null objects; <: is the subclass relationship)

Proof shows the conditions are maintained for all actions that extend the quantification range or change values of object fields

modifies clause
Modifies Clause
  • Model access to an object field by changes to the program heap:
    • Heap is a global 2 dimensional array indexed by object references and field names
    • Location if o.f is modeled by Heap[o,f]
  • Modifies Clause contains a set of heap locations the routine is allowed to modify
  • Routines are allowed to allocate new objects and modify their state
    • Special field alloc denotes allocated objects
modifies clause1
Modifies Clause
  • Post-condition for modifies clause W:
  • Innovation: allow every routine to modify fields of commited objects:
  • Implementation Hiding
    • Use special expression E.{ T }
    • T = { class name, type(o) for object-valued expression o }
    • Denotes all regular fields of object E declared in class T and its super classes
dynamic dispatch
Dynamic Dispatch
  • pack and unpack statements need to specify which type they are unpacking
    • Need to state the exact value of inv as a precondition
    • Limits use of dynamic dispatching
  • Innovation:
    • Use special expression: inv = 1
    • For caller 1 means type(this)
    • For implementation in class T, 1 means T
  • How can this be sound?
dynamic dispatch1
Dynamic Dispatch
  • Soundness:
    • For declaration of dynamic dispatched method M, introduce a procedure named M with specification:

inv = type(this)

    • For implementation of M in class T introduce a procedure M@T with specification: inv = T
    • Body of procedure M looks at type of this and calls corresponding procedure M@type(this)
    • Body of M@T is like that of method M in T except that any call for super class, super.M(…) is replaced with M@S
    • Every class must supply an implementation for every dynamically dispatched methoddeclared in the class or its super class
  • Extend 1 for the modifies clause: E.{1}
  • Can be used as a super class or a component
  • Subclass implementation can modify all regular fields of super class.

Constructor must copy char array


Constructor can capture the reader

  • Lexer can relinquish the underlying reader
  • Reader must be relinquished in an uncommitted state
  • Implementation leaves Lexer in an inconsistent state so that GetToken can no longer be invoked
  • Programmer must be aware at which points an object invariant can be relied upon
  • Presented method that provides programmers with a flexible and precise way to specify their intensions about object invariants
  • Ownership method allows a single valid owner per object at a time but doesn’t confine object aliasing and allows multiple read access
  • Methodology allows for both static verification and dynamic checking
current work
Current Work
  • Spec #
    • Extension of C# with method contracts
    • Compiler and static verifier tools integrate with visual studio .NET
  • Boogie
    • Spec# static program verifier
  • WebSite