![Page 1: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/1.jpg)
Reasoning about Multiple Related Abstractions with
MultiStarStephan van Staden, Cristiano Calcagno
Chair of Software Engineering
![Page 2: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/2.jpg)
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
![Page 3: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/3.jpg)
Abstract Predicate Families (APF)
Purpose: data abstractionE.g. d + 100 < 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
![Page 4: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/4.jpg)
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
Counterc: int
Balanceb: int
Counterc: int
Balanceb: int
Accountd: Counterb: Balance
Accountd: intb: int
![Page 5: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/5.jpg)
The opportunityCorrectness 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)
![Page 6: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/6.jpg)
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
![Page 7: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/7.jpg)
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
![Page 8: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/8.jpg)
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 informationE.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
![Page 9: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/9.jpg)
More examples
Impose representation constraints on subclasses• axiom C(cnt: c) CAccount(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: intMusician
pfm: int
StudentMusician
![Page 10: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/10.jpg)
More examples
Relationships between predicate arguments• axiom A(deps: d, bal: b) d + 100 < b
Properties of predicate argumentsE.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.AAccount(deps: d, bal: b) as 0 ≤ d ˄ …
10
![Page 11: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/11.jpg)
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.AAccount(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
Counterc: int
Accountf: Counter
…
![Page 12: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/12.jpg)
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 methodologyOnly use exports and axioms where you really want them
12
![Page 13: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/13.jpg)
MultiStar
Automated tool for verificationPart of EVE, the Eiffel Verification EnvironmentFront-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
![Page 14: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/14.jpg)
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)
![Page 15: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/15.jpg)
Other work
Other work in the paper:• MultiStar implementation details• Formalization, proof of soundness• Related work
15
![Page 16: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/16.jpg)
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
![Page 17: Reasoning about Multiple Related Abstractions with MultiStar](https://reader036.vdocuments.mx/reader036/viewer/2022062806/56814f1b550346895dbcac6b/html5/thumbnails/17.jpg)
Axioms are universal representation invariants
Class invariants are properties which methods must preserve
Further comparison:
What about class invariants?
17