Observational Purity and Encapsulation

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.

show abstract

“…This is reflected in PO 1 , which cannot be proven to hold for this example. Possible solutions to this problem are suggested in [4,20,21].…”

Section: Related Work and Experiencementioning

confidence: 99%

Proving Consistency of Pure Methods and Model Fields

Leino

Middelkoop

2009

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

show abstract

“…Naumann [40] generalizes purity to observational purity, which allows pure methods to make modifications as long as these modifications cannot be observed by client code. His work can be combined with our verification techniques by considering dependencies of client invariants as observations.…”

Section: Ownership Models and Readonly Referencesmentioning

confidence: 99%

Modular invariants for layered object structures

Müller

Poetzsch-Heffter

Leavens

2006

Science of Computer Programming

106

View full text Add to dashboard Cite

Classical specification and verification techniques support invariants for individual objects whose fields are primitive values, but are unsound for invariants involving more complex object structures. However, such non-trivial object structures are common, and occur in lists, hash tables, and when systems are built in layers.We generalize classical techniques to cover such layered object structures using a refined semantics for invariants based on an ownership model for alias control. This semantics enables sound and modular reasoning. We further extend this ownership technique to even more expressive invariants that gain their modularity by imposing certain visibility requirements.

show abstract

“…Section 6 concludes. This paper is revised and extended from the conference version (Naumann, 2005). It includes full proofs and more thorough discussion of related work, as well as expository changes including adoption of the term "weak purity" for what had been called strong purity.…”

Section: Introductionmentioning

confidence: 99%

Observational purity and encapsulation

Naumann

2007

Theoretical Computer Science

Self Cite

View full text Add to dashboard Cite

Practical specification languages for imperative and object-oriented programs, such as JML, Eiffel, and Spec#, allow the use of program expressions including method calls in specification formulas. For coherent semantics of specifications, and to avoid anomalies with runtime assertion checking, expressions in specifications and assertions are typically required to be weakly pure in the sense that their evaluation has no effect on the state of preexisting objects. For specification of large systems using standard libraries this restriction is impractical: it disallows many standard methods that mutate state for purposes such as caching or lazy initialization. Calls of such methods can sensibly be used for specifications and annotations in contexts where their effects cannot be observed. This paper formalizes a notion of observational purity, justifies the use of weakly and observationally pure methods in specifications, and shows that a method is observationally pure if it simulates a weakly pure method.

show abstract

Observational Purity and Encapsulation

Cited by 20 publications

References 24 publications

Proving Consistency of Pure Methods and Model Fields

Proving Consistency of Pure Methods and Model Fields

Modular invariants for layered object structures

Observational purity and encapsulation

Contact Info

Product

Resources

About