We present a Hoare-style specification and verification approach for invariants in sequential OO programs. It allows invariants over non-hierarchical object structures, in which update patterns that span several objects and methods occur frequently. This gives rise to invalidating and subsequent re-establishing of invariants in a way that compromises standard data induction, which assumes invariants hold when a method is called. We provide specification constructs (inc and coop) that identify objects and methods involved in such patterns, allowing a refined form of data induction. The approach now handles practical designs, as illustrated by a specification of the Observer Pattern.

An algebraic specification is viewed as a black box that rewrites input to a ``most basic'' canonical form. We argue that a canonical form should be given for each specific specification, to prevent ``cheating'' in the implementation. Furthermore, we argue that the definition of the canonical form may sometimes require semantic rather than syntactic information.To relate an OO implementation to a specification requires opening the black box to some extent; we assess the choices to be made here.

No abstract

Pure methods and model fields are useful and common specification constructs that can be interpreted by the introduction of axioms in a program verifier's underlying proof system. Care has to be taken that these axioms do not introduce an inconsistency into the proof system. This paper describes and proves sound an approach that ensures no inconsistencies are introduced. Unlike some previous syntax-based approaches, this approach is based on semantics, which lets it admit some natural but previously problematical specifications. The semantic conditions are discharged by the program verifier using an SMT solver, and the paper describes heuristics that help avoid common problems in finding witnesses with trigger-based SMT solvers. The paper reports on the positive experience with using this approach in Spec# for over a year. IntroductionPure methods and model fields [1,2] are useful and common specification constructs. By marking a method as pure, the specifier indicates that it can be treated as a function of the state. It can then be called in specifications. Model fields provide a way to abstract from an object's concrete data. A problem with either technique is that it can introduce an inconsistency into the underlying proof system. In this paper, we discuss how to prove (automatically) that no such inconsistency is introduced while allowing a rich set of specifications.Starting from a review of the setting, the problem, and previous solutions, this section leads up to an overview of our contributions.Pure Method Specifications. Figure 1 shows the template for a pure method specification (for simplicity, we show only a single formal parameter, named p). As usual, requires declares the method's precondition P , ensures declares the method's postcondition Q , and result denotes the method's return value. The only free variables allowed in P are this and p. In Q , result is allowed as well.A Deduction System. Marking method m as pure adds an uninterpreted total function #m : C ×T → T (a method function [3]) to the specification language. In predicates in the specification, the expression E 0 .m(E 1 ) is treated as syntactic M.

No abstract