1 / 15

Class-local object invariants

Class-local object invariants. K. Rustan M. Leino Microsoft Research Redmond, WA, USA Angela Wallenburg Chalmers University of Technology G öteborg, Sweden. 20 Feb 2008 ISEC 2008 Hyderabad, India. Program verification. Reasoning about object-oriented software involves object invariants

beau
Download Presentation

Class-local object 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. Class-local object invariants K. Rustan M. Leino Microsoft ResearchRedmond, WA, USA Angela Wallenburg Chalmers University of TechnologyGöteborg, Sweden 20 Feb 2008 ISEC 2008 Hyderabad, India

  2. Program verification • Reasoning about object-oriented software involves object invariants • An object invariant describes the steady stateof an object • Because of call-backs, it is necessary to keep track of when object are in their steady state Demo 0

  3. Program verification • Reasoning about object-oriented software involves object invariants • An object invariant describes the steady stateof an object • Because of call-backs, it is necessary to keep track of when object are in their steady state …but first, a word from our sponsor Spec# is a programming system that emphasizes program specifications. The Spec# language is a superset of the object-oriented .NET language C# 2.0. The system can be downloaded from Microsoft Research, http://research.microsoft.com/specsharp. Demo 0

  4. Boogie methodology • Idea: Explicitly keep track of whether an object is in its steady state • Done by adding a special field inv to each object, such that: (o  o.inv  Inv(o)) • The inv field is changed by a special program statement: the expose block Demo 1

  5. Subclassing • Each class can declare its own invariant • Each class gets its own inv field (o,T  o.invT  Inv(o, T)) • Expose block operates on one invT field Demo 2

  6. Exposing subclasses • class T : object { … } • class U : T { … } • class V : U { … } • void M(U u) { • expose (u) { … } • expose ((T)u) { … } • } V U T object

  7. Exposing subclasses • class T : object { … } • class U : T { … } • class V : U { … } • void M(U u) { • expose (u) { … } • expose ((T)u) { … } • } V U T object

  8. Exposing subclasses • class T : object { … } • class U : T { … } • class V : U { … } • void M(U u) { • expose (u) { … } • expose ((T)u) { … } • } V U T object

  9. Invariants that mention superclass fields • Modular verification: each “module” is verified independently, using only the specifications of other modules • To support modular verification, changes in a superclass must be consistent with all possible subclass invariants! admissible Demo 3

  10. Inter-class invariants • class T : object { … } • class U : T { int x; … } • class V : U { int y; invariant x ≤ y; … } V • void M(U u) { • expose (u) { x++; } • } U T object

  11. Additive behavior • By always exposing an entire suffix of class frames (one frame at a time), we can allow additive invariants • void M(U u) { • expose ((V)u) {expose (u) { x++; }} • } V U T Demo 4 object

  12. Implementation • Allow both additive and local invariants and expose blocks • Only one local expose (per object) at a time o typeof(o) • “o is in steady state” ≡ o.inv = o.localinv = typeof(o) • if f is a field declared in class T with superclass S, then o.f is allowed to be modified if:(o.inv <: T)  o.localinv = S o.inv o.localinv object

  13. Contributions • An integration of class-local and additive invariants • Experience results • >6000 lines of code • Class-local invariants are used exclusively • Our encoding of constructors use additive behavior, but perhaps this could be encoded differently

  14. Aggregate objects • class U : T { rep C p; invariantp.x < 100; … } • class V : U { invariantp.x == 20; … } not supported V p U x T object

  15. Summary and conclusions • Class-local invariants can be used together with additive invariants • Additive invariants are rarely used • Implemented in Spec# and its program verifier Boogie • Open issue: nice way to allow invariants to dereference fields declared in superclass Download Spec# and Boogie from here http://research.microsoft.com/specsharp

More Related