1. Method Verification
CS/SWE 332
Paul Ammann

2. Verification vs Validation
A given implementation is correct with respect to another description
Validation
A given description is desirable
We will focus on Verification in this lecture
Good news! All Verification Obligations follow the same basic model!

3. Verification of Method Contracts in Data Abstractions
First basic problem
Contract is in JavaDoc
Code is in Java
How are the states related?
Solution:
Abstraction Function maps
Representation States to
Abstract States

4. Key to verifying methods in isolation
Common (flawed) informal approach to analyzing a given method:
See how other methods behave
Worry about method interactions
Interactions are reflected in representation state.
This doesn’t scale!
Instead, we want to analyze each method by itself
We need a general description of important properties relevant to all methods
Exactly what the Rep Invariant does

5. Method Verification: Part 1 The Representation Invariant
Does the method establish/maintain the rep-invariant?
Base case for constructors
Plus any other methods that create objects
Clone? Serialization?
Inductive case for mutators

6. Method Verification Part 2: The Contract
Given The Rep Invariant as an Assumption
Given Preconditions as Assumptions
Does the Postcondition Hold?
Need to Map States Through Abstraction Function

7. Verification In Diagram Form
Abstract State (Before)
Abstract State (After)
Method
Contract ?
AF()
AF()
Representation State (After)
Representation State (Before)
Method
Code

8. Verification Example Exactly what is incorrect? Verification tools:
Diagram shown for method verification
Will revisit same diagram for overridden methods
Example to develop in class:
public class Members {
// Members is a mutable record of organization membership
// AF: ??
// rep-inv: ??
List<Person> members; // the representation
// Post: person becomes a member
public void join (Person person) { members.add (person);}
// Post: person is no longer a member
public void leave(Person person) { members.remove(person);} }
Exactly what is incorrect?
Verification tools:
Contract, Abstraction function, Representation Invariant
Validation question: What about null values in members?

9. Verification Example - Analysis
rep-inv: members != null
&& no duplicates in members
rep-inv: members != null
join()
Maintain rep-inv?
Yes
Satisfy contract?
leave() No
join()
Maintain rep-inv? No
Satisfy contract?
Not a meaningful question
leave()
Yes

10. Verification Example – Repair 1
Analysis
rep-inv: members != null
join()
As is
leave()
while (members.contains(person)) {
members.remove(person); }
join()
Maintain rep-inv?
Yes – already analyzed
Satisfy contract?
leave()
Yes

11. Verification Example – Repair 2
Analysis
rep-inv: members != null
&& no duplicates in members
join()
if (!members.contains(person)) {
members.add(person); {
leave()
As is
join()
Maintain rep-inv?
Yes
Satisfy contract?
leave()
Yes – Already analyzed

12. Another Verification Example
public class Poly {
// Polys are immutable polynomials c0 + c1x + c2x^2 + …
// AF: ci = trms[i] for appropriate values of i
// rep-inv: deg = trms.length-1
// trms.length >= 1
// trms != null
// if deg > 0 then trms[deg] != 0
int[] trms; int deg; // the representation
// Post: Return degree of this, ie largest exponent with
// coefficient != 0. Returns 0 if this is zero Poly
public int degree() { return deg; }
// Other methods omitted }
How do we decide if degree() is correct?
How must code change if rep-inv changes?