Method Verification CS/SWE 332 Paul Ammann

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!

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

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

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

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

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

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?

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

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

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

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?