1. Class-local object invariants
6/23/2018 6:05 PM
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
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2. Program verification
Reasoning about object-oriented software involves object invariants
An object invariant describes the steady state of an object
Because of call-backs, it is necessary to keep track of when object are in their steady state
public class MyClass {
int x, y;
// invariant x < y;
public int M() {
int d = 100 / (y - x);
// expose (this) {
y++;
x++;
// }
return d; }
public MyClass(int k)
// requires 0 < k;
{ x = 0; y = k; }
public class SomeOtherClass {
public static void P(MyClass c) {
c.M();
DEMO 0:
0. add precondition to M: x < y
1. remove it, and add invariant x < y
2. add precondition to ctor: 0 < k
3. reverse order of x++/y++ (inv is temporarily violated)
4. add call to SomeOtherClass.P(this)
5. undo (3) and (4)
Demo 0

3. Program verification
Reasoning about object-oriented software involves object invariants
An object invariant describes the steady state of 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,
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:
0. add expose statement
1. add call to P (results in precondition violation – explain default preconditions)
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
public class Superclass {
protected int x, y;
invariant x < y;
public Superclass() { x = 0; y = 10; }
public virtual int M() {
int d = 100 / (y - x);
y++; x++;
return d; }
public class Subclass : Superclass { /*
int z;
invariant z < 8;
public override int M() {
expose ((Superclass)this) { x++; y++; }
z = (z + 1) % 8;
return base.M(); */
DEMO 2:
0. add: int z; … return base.M(); (but without the expose statement)
1. add: expose (this) … (to show how expose selects class/inv field)
2. change to: expose ((Superclass)this) …
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!
using Microsoft.Contracts;
public class T {
public T() ensures x == 0; { x = 0; }
/*[Additive]*/ protected int x;
invariant 0 <= x;
/*[Additive]*/ public virtual void Inc() {
/*additive*/ expose (this) { x++; } }
public class U : T {
protected int y;
//invariant x <= y;
public U() { y = 0; }
/*[Additive]*/ public override void Inc() {
/*additive expose (this) {*/ base.Inc(); /*}*/
DEMO 3:
0. add invariant x <= y in U
1. Show inv x… is not admissible
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
DEMO 4:
0. add [Additive] to x
1. add additive in T
2. add [Additive] to T.Inc
3. add [Additive] to U.Inc
4. add additive expose to U.Inc 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; invariant p.x < 100; … }
class V : U { invariant p.x == 20; … }
not supported V U p 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