Reasoning about Multiple Related Abstractions with MultiStar Stephan van Staden, Cristiano Calcagno Chair of Software Engineering

Introduction Broad topic: reasoning about the correctness of OO programs In particular: well-behaved invariants Data abstractions pervade OO programs: Language constructs: classes Concepts: account, counter, person, stack 2

Abstract Predicate Families (APF) Purpose: data abstraction E.g. d < b x.deposits = d ˄ x.balance = b APF predicate x.A(deps: d, bal: b) Logical abstractions of data APF predicate arguments are the only visible properties of the abstraction Think in terms of interface and implementation. This enforces high-level reasoning APF predicates can have different implementations in different classes Inheritance-aware 3

Related abstractions Abstractions are often related: x.A(deps: d, bal: b)  x.C(cnt: d) * x.R(bal: b) Possible implementations: One class Client Inheritance 4 Account Counter c: int Balance b: int Counter c: int Balance b: int Account d: Counter b: Balance Account d: int b: int

The opportunity Correctness of code often depends on such relationships, but the original proof system allows only to pass APF predicates around Assume library routine use_counter(x) {x.C(cnt: d)}_{x.C(cnt: d+20)} Client reasoning: {x.A(deps: d, bal: b)} {x.C(cnt: d) * x.R(bal: b)} use_counter(x) {x.C(cnt: d+20) * x.R(bal: b)} // Code that assumes x.A(deps: d+20, bal: b) Client infers an A -based specification for use_counter Access control & call protocols: x.A(deps: d, bal: b)  x.C(cnt: d) * x.R(bal: b) 5 x.A(deps: d, bal: b)  x.C(cnt: d) * x.R(bal: b)

The problem Original APF system lacks ways to Specify relationships among abstractions Verify them Reason about code that relies on them Solutions must be flexible, since a property may apply to Instances of particular classes A whole class hierarchy Further requirements: soundness, modularity, simplicity 6

Our approach We use two new specification mechanisms Export clauses for properties of individual classes Axiom clauses for properties of entire class hierarchies Export clauses Class C contains export P Verification checks whether P follows from the APF assumptions of C Clients can assume P The paper contains examples 7

Our approach Axiom clauses Class C contains axiom l: P C and all its subclasses must implement axiom l Subclasses can refine (i.e. strengthen) an axiom Clients can assume ∀ x <: C  P[x / Current] Dynamic type information is not necessary to use this axiom information E.g. axiom a1: A(deps: d, bal: b)  C(cnt: d) * R(bal: b) Method body verification can use export and axiom information of all classes 8

More examples Impose representation constraints on subclasses axiom C(cnt: c)  C Account (cnt: c) All subclasses are forced to implement the C abstraction in the same way as class Account Diamond inheritance & view shifting In class StudentMusician : axiom S(age: a, exm: e) * R1(pfm: p)  M(age: a, pfm: p) * R2(exm: e) Ownership transfer rule Separation logic can express disjointness and sharing 9 Person age: int Student exm: int Musician pfm: int StudentMusician

More examples Relationships between predicate arguments axiom A(deps: d, bal: b)  d < b Properties of predicate arguments E.g. The number of deposits is non-negative axiom A(deps: d, bal: b)  0 ≤ d Include 0 ≤ d in A predicate definitions: define x.A Account (deps: d, bal: b) as 0 ≤ d ˄ … 10

More examples Axioms for aggregate structures that rely on other axioms For the Counter hierarchy: axiom cnt_non_neg: C(cnt: c)  0 ≤ c In class Account : define x.A Account (deps: d, bal: b) as ∃ y  x.f ↦ y * y.C(cnt: d) * … axiom deps_nn: A(deps: d, bal: b)  0 ≤ d relies on Counter.cnt_non_neg 11 Counter c: int Account f: Counter …

Observations Export/axiom information can be seen as well-behaved, operation-independent invariants of OO programs They are universal invariants – always hold Logical, not operational: cannot be violated by adding new methods (cf. class invariants) Idea is not to impose a methodology Only use exports and axioms where you really want them 12

MultiStar Automated tool for verification Part of EVE, the Eiffel Verification Environment Front-end for Eiffel and back-end based on jStar Back-end reasoning enhancements Export and axiom clauses Shared multiple inheritance (including interface inheritance, handling abstract classes and methods) Demonstration 13

Case study with MultiStar Gobo data structure library’s iterator hierarchy Axiom of container hierarchy: 14 ElementAt(iter: i1, elem: e1, content: c1, iters: i) * ElementAt(iter: i2, elem: e2, content: c1, iters: i) * Replaced(iter: i1, value: e2, newcontent: c2, oldcontent: c1, iters: i) * Replaced(iter: i2, value: e1, newcontent: c3, oldcontent: c2, iters: i)  Swapped(iter1: i1, iter2: i2, newcontent: c3, oldcontent: c1, iters: i)

Other work Other work in the paper: MultiStar implementation details Formalization, proof of soundness Related work 15

In conclusion Two new specification mechanisms: export and axiom clauses Simple, well-behaved and powerful Sound proof system incorporating exports and axioms, based on separation logic and APFs Accommodates shared multiple inheritance and interfaces Implementation: MultiStar verification tool 16

Axioms are universal representation invariants Class invariants are properties which methods must preserve Further comparison: What about class invariants? 17