verification of object-oriented programs with invariants
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/1.jpg)
1
Verification of object-oriented
programswith invariantsMike Barnett, Robert DeLine,
Manuel Fahndrich, K. Rustan M. Leino,
Wolfram Schulte
ECOOP 2003 workshop on Formal Techniques for Java-like Programs
Encapsulation Seminar TAU 2005Presented by Yossi Peery
![Page 2: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/2.jpg)
2
Agenda
Introduction Motivation and Background Object Invariants and Information Hiding
Solution Basic Methodology Concepts Adding Components and Subclasses Modifies Clause and Dynamic Dispatching Examples
Conclusion
![Page 3: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/3.jpg)
3
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
![Page 4: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/4.jpg)
4
Background 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
![Page 5: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/5.jpg)
5
Reentrancy Problem
public method P (…)
{
…
M ();
…
}
![Page 6: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/6.jpg)
6
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
![Page 7: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/7.jpg)
7
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
![Page 8: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/8.jpg)
8
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
![Page 9: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/9.jpg)
9
Basic Methodology Concept
Provide an explicit representation of when object invariants are known to hold Add special public field st to every object.
o.st = Invalid o is invalid
o.st = 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 o.st = Invalid
![Page 10: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/10.jpg)
10
Basic Methodology Concept InvT(o) :
predicate to indicate that the invariant of object o of class T holds.
Using class T from previous example:
![Page 11: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/11.jpg)
11
Basic Methodology Concept
![Page 12: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/12.jpg)
12
Restrictions and Validity
Object field updates can break invariant: Field update statements: o.f := E Permitted only where o.st = 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
![Page 13: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/13.jpg)
13
Components
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
![Page 14: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/14.jpg)
14
Components
If t.f = u then update of u.g breaks T’s invariant Need to make sure that:
u.st = Invalid => t.st = Invalid
t.st = Valid => u.st = Committed
![Page 15: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/15.jpg)
15
Ownership
Committed state indicates Ownership If t.f.st = Commited then t owns t.f Creates hierarchy of owned objects
Use rep modifier 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 rep modifier
![Page 16: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/16.jpg)
16
Components
st : { Invalid , Valid, Committed }
CompT(o) = { o.f : f is a rep field in T }
![Page 17: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/17.jpg)
17
Components
Program Invariant:
Unique Ownership:
Ownership Transfer:
![Page 18: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/18.jpg)
18
Subclasses
Object divided into class frames
Each frame can be valid or invalid possible subsets
Consider only nonempty prefixes { object } { object, A } { object, A, B }
n2
![Page 19: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/19.jpg)
19
New Encoding
Instead of st: Special field inv holds type 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 the constructor as:
inv = T & !commited
Field updates of subclass allowed if object is “sufficiently unpacked”
Invariants may contain fields of subclasses
![Page 20: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/20.jpg)
20
New Encoding
T extends S
o is any subclass of T
![Page 21: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/21.jpg)
21
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
![Page 22: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/22.jpg)
22
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
![Page 23: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/23.jpg)
23
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
![Page 24: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/24.jpg)
24
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?
![Page 25: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/25.jpg)
25
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 method declared in the class or its super class
Extend 1 for the modifies clause: E.{1}
![Page 26: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/26.jpg)
26
Examples
Can be used as a super class or a component Subclass implementation can modify all regular
fields of super class.
![Page 27: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/27.jpg)
27
Examples
Constructor must copy char array
![Page 28: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/28.jpg)
28
Examples
Constructor can capture the reader
![Page 29: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/29.jpg)
29
Examples
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
![Page 30: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/30.jpg)
30
Conclusions
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
![Page 31: Verification of object-oriented programs with invariants](https://reader035.vdocuments.site/reader035/viewer/2022070406/56814096550346895dac2e6e/html5/thumbnails/31.jpg)
31
Current Work
Spec # Extension of C# with method contracts Compiler and static verifier tools integrate with
visual studio .NET
Boogie Spec# static program verifier
WebSitehttp://research.microsoft.com/foundations