1 / 17

Verification of object-oriented programs with invariants

Verification of object-oriented programs with invariants. Mike Barnett, Robert DeLine, Manuel Fahndrich , K. Rustan M. Leino, Wolfram Schulte. ¨. Formal techniques for Java-like programs Darmstadt, Germany 21 July 2003. Example problem.

fabienne
Download Presentation

Verification of object-oriented programs with invariants

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. Verification of object-oriented programs with invariants Mike Barnett, Robert DeLine, Manuel Fahndrich, K. Rustan M. Leino, Wolfram Schulte ¨ Formal techniques for Java-like programsDarmstadt, Germany21 July 2003

  2. Example problem class T {int x, y;invariant x < y; publicvoid m(U u) { x++; u.p(); y++; } invariant assumed to hold invariant may not hold problem if p calls back into T invariant re-established

  3. Wanted:Methodology for invariants • Ideal methodology: • easy to understand • statically and modularly checkable • identifies all errors in a program • permits all good programs

  4. Invariant declarations–one per subclass Y y = new Y(); class W extends V {int a;int[] b; invariant a ≤ b.length; … Y X W V class V extends U { P p;invariant p ≠ null; … U T Object

  5. Special field inv keeps track of which invariants hold o o o • Declarations and statements of programminglanguage determine when inv is changed • The associated invariants are checked when inv increases • To prevent established invariants from having to bere-checked, one can treat fields in and below o.inv asread-only W W W V V V U U U T T T Object Object Object o.inv == ⊥ o.inv == U o.inv == W== typeof(o) “o is consistent”

  6. inv can be used inmethod specifications class T {int x, y;invariant x < y; publicvoid m()requiresinv == T; {int[] a = newint[y-x]; … } meaning: (∀t:T ･ t.inv <: T ⇒ t.x < t.y) invariant holds here (checked at call sites)

  7. inv can be used inmethod specifications class T {int x, y;invariant x < y; publicvoid m()requiresinv == typeof(this); {int[] a = newint[y-x]; … } meaning: (∀t:T ･ t.inv <: T ⇒ t.x < t.y) invariant holds here (checked at call sites)

  8. Exposed vs. owned o o o o owned W W W W V V V V U U U U T T T T Object Object Object Object o.inv == W o.inv == ⊥ o.inv == U o.inv == W consistent consistent exposed owned • Only consistent objects can be owned • Special field exposed keeps track of exposed/owned • exposed can be used in method specifications

  9. Components Q Object R W q P x 26 Object V p U T Object

  10. Components Q Object • Component fields are declared as such • Component fields are not necessarily unique references R q P x 26 Object p U T Object

  11. Components Q Object • When inv is increased to U, then U’s components are checked to be consistent (p.inv == typeof(p)) and are subsequently un-exposed owned R q P x 26 Object p U T Object o.inv == T o.inv == U

  12. Components Q Object • Decreasing inv below U exposes U’s components owned R q P x 26 Object p U T Object o.inv == T o.inv == U

  13. Fields of componentscan be mentioned in invariants k Q Object g h R q P x 26 Object p class U {… invariant x ≤ p.g ∧ p.g == p.h; invariant x ≤ q.k; U T Object • Fields of owned (un-exposed) objects are not allowed to be mutated

  14. License to modify • A field o.f can be modified only when o.exposed holds • A method m is allowed a net effect on a field o.f (including o.inv and o.exposed) only if: • o.f appears in the modifies clause of m, or • o was not allocated on entry to m, or • o was not exposed on entry to m new

  15. Method calls may change fields of un-exposed objects o owned g h R P x 26 Object p class U {… invariant x ≤ p.g ∧ p.g == p.h; U T Object

  16. Related work • rep types in CLU • valid idiom in ESC/Modula-3 • (implicit) pack/unpack operations in Vault and Fugue • capability calculus • ownership types • invariant declarations in ESC/Java and JML • locking and monitor disciplines in concurrent programming

  17. Conclusions exposed inv Object • Simple! • inv, exposed, identification of components, protocol for changing inv/exposed • object references can always be copied • but objects can have just one owner • fields can always be read • but curbed expectations about the values read • frame problem solved without abstraction (e.g., data groups) • Want: • experience, understanding of limits • extensions to support more good programs • more detailed comparison with other work

More Related