Modular Verification of Higher-Order Methods in JML

1. Modular Verification of Higher-Order Methods in JML Gary T. Leavens,Steve Shaner, and David A. NaumannSupport from US NSF grant CCF-0429567

2. Summary Problem • How to reason about higher-order methods? Approach • Greybox [Büchi-Weck97,99] specifications, Copy rule / substitution [Morgan88], Structurally-restricted refinement Contribution • Structural matching for refinement • Integration with JML

3. Background:Higher-Order Methods • A higher-order method(HOM)makes mandatory callsto weakly-specified methods

4. Example (part 1)Class with a `method parameter’ public class Counter { protected/*@ spec_public @*/int count = 0; protected/*@ spec_public @*/ Listener lnr; //@ assignablethis.lnr; //@ ensuresthis.lnr == lnr; public Counter(Listener lnr) { // parameter this.lnr = lnr; }

5. Example (part 2): HOM public void bump() { this.count = this.count + 1; this.lnr.actionPerformed(this.count); } }

6. Mandatory Calls areWeakly Specified public interface Listener { //@ assignablethis.objectState; void actionPerformed(int x); }

7. Subtype of Listener public class LastVal implements Listener { private/*@ spec_public @*/int val = 0; //@ in objectState; //@ ensures\result == this.val; public/*@ pure @*/int getVal() { returnthis.val; } //@ also //@ assignable objectState; //@ ensuresthis.val == x; public void actionPerformed(int x) { this.val = x; } }

8. Subtype of Listener public class LastVal implements Listener { private/*@ spec_public @*/int val = 0; //@ in objectState; //@ ensures\result == this.val; public/*@ pure @*/int getVal() { returnthis.val; } //@ also //@ assignable objectState; //@ ensuresthis.val == x; public void actionPerformed(int x) { this.val = x; } }

9. Reasoning Problem:Want strong conclusions LastVal lv = new LastVal(); //@ assert lv.val == 0; Counter c = new Counter(lv); //@ assert c.lnr == lv && c.count == 0; c.bump(); //@ assertlv.val == 1;

10. Why is strong conclusion valid?Copy rule and substitutions LastVal lv = new LastVal(); //@ assert lv.val == 0; Counter c = new Counter(lv); //@ assert c.lnr == lv && c.count == 0; c.count = c.count+1; c.lnr.actionPerformed(c.count); //@ assertlv.val == 1;

11. Problem Summary • Specification of higher-order methods(challenge 8 in [Leavens-Leino-Müller06]) • Abstract • Specifies mandatory calls • Suppress other details • Allows strong conclusions (challenge 9) • Copy rule and substitution • Soundness • Must make mandatory calls

12. Use of Higher-Order Methods • Key in design patterns [Gamma-etal95]: • Observer • Template Method • Chain of Responsibility • Clients of design patterns: • Interpreter • Command • State • Strategy • Visitor

13. How to Specify HOMs?Standard Pre/Post … /*@ assignablethis.count, lnr.objectState; @ ensuresthis.count ==\old(this.count+1); @*/ public void bump() { this.count = this.count + 1; this.lnr.actionPerformed(this.count); }

14. … Is Not Enough LastVal lv = new LastVal(); //@ assert lv.val == 0; Counter c = new Counter(lv); //@ assert c.lnr == lv && c.count == 0; c.bump(); //@ assumec.count == 1; //@ hence_by(* ??? *); //@ assertlv.val == 1;

15. Higher-Order Specifications? E.g., [Ernst-Navlakhla-Ogden82]: /*@ forallint x; @ requires\req(this.lnr.actionPerformed)(x); @ assignablethis.count, @\asgn(this.lnr.actionPerformed); @ ensuresthis.count ==\old(this.count+1) @ &&\ens(this.lnr.actionPerformed)(this.count); @*/ public void bump() { /* … */ }

16. Problems with Higher-Order Specifications • Often longer and more complex than code • Harder to learn and teach • Harder for tools to work with? • Calls are not mandatory

17. Greybox (Ref. Calc.) Approach[Büchi–Weck97, 99] c.count++ lnr.actionPerformed() lnr.actionPerformed() vs. Better:

18. Greybox Approach in JML:Model Program Specification /*@ public model_program { @ normal_behavior @ assignablethis.count; @ ensuresthis.count ==\old(this.count+1); @ @this.lnr.actionPerformed(this.count); @ } @*/ public void bump() { /* … */ }

19. Reasoning About HOM Calls LastVal lv = new LastVal(); //@ assert lv.val == 0; Counter c = new Counter(lv); //@ assert c.lnr == lv && c.count == 0; c.bump(); //@ assertlv.val == 1;

20. Approach: Model Program Copy Rule and Substitution LastVal lv = new LastVal(); //@ assert lv.val == 0; Counter c = new Counter(lv); //@ assert c.lnr == lv && c.count == 0; /*@ normal_behavior @ assignable c.count; @ ensures c.count == \old(c.count+1); @*/ c.lnr.actionPerformed(c.count); //@ assertlv.val == 1;

21. Rule for HOM Calls(Copy Rule + Substitution) y: T, methType(T,m) = x:S -> void, specFor(T,m) = C, C’ = C [y,z/this,x], P { C’ } Q P { y.m(z); } Q

22. Strong Conclusions fromCopy + Contextual Knowledge //@ assertc.lnr == lv; c.bump(); Copy/Substitute model program /*@ normal_behavior @ assignable c.count; @ ensures c.count == \old(c.count+1); @*/ c.lnr.actionPerformed(c.count); + Context lv.actionPerformed(c.count);

23. Soundness fromRestricting Implementations • For soundness of HOM call rule: • (copy rule) body refines model program • (use of context) restrict refinement somandatory calls must happen in specified states

24. Notion of Refinement with Mandatory Calls in Given States • Need to define “structure-preserving refinement” • Approach: • Restrict implementations • Pattern matching • Model program vs. • Implementation

25. Kinds of Patterns • Refinable (holes, wildcards) • Specification statements (normal_behavior) • Mandatory • Calls • Everything else

26. Pattern Matching Method implementation Model program followingnormal_behavior …{ C } normal_behavior … m(); m();

27. Implementing Higher-Order Methods /*@ public model_program { @ normal_behavior @ assignablethis.count; @ ensuresthis.count == \old(this.count+1); @this.lnr.actionPerformed(this.count); @ } @*/ public void bump() { /*@ following normal_behavior @ assignable this.count; @ ensuresthis.count == \old(this.count+1);@*/ { this.count = this.count+1; } this.lnr.actionPerformed(this.count); }

28. Refinement P ⊑ C iff • C pattern matches against P • The resulting following statements are provable

29. Rule for following P ==> P’, Q’ ==> Q, P’ { C } Q’ P { following normal_behaviorrequires P’; ensures Q’; C } Q

30. Future Work • Soundness argument • Connection to Büchi and Weck’s work(refinement of traces) • Case studies • Implementation in JML tools • Exceptions • Concurrency

31. Related Work Büchi and Weck (1997, 99): • Idea of greybox approach • Trace semantics • Doesn’t focus on reasoning about calls • Needs definition of structure preservation Morgan (1988): • Uses adaptation and substitution for procedures

32. Related Work Ernst, Navlakhla, and Ogden (1982): • Higher-order logic specifications • Harder to write and use • Mandatory calls might not be made Soundarajan and Fridella (2004): • Higher-order trace-based specifications • Can ensure mandatory calls are made • Harder to write and use

33. Conclusions • Greybox (refinement-style) model programs • Clear specification of HOMs • Allow strong conclusions • Soundness: • Restrictions on refinement • Use of pattern matching