Checking Well-Formedness of Pure-Method Specifications

Contract languages such as JML and Spec# specify invariants and pre- and postconditions using side-effect free expressions of the programming language, in particular, pure methods. For such contracts to be meaningful, they must be well-formed: First, they must respect the partiality of operations, for instance, the preconditions of pure methods used in the contract. Second, they must enable a consistent encoding of pure methods in a program logic, which requires that their specifications are satisfiable and that recursive specifications are well-founded. This paper presents a technique to check well-formedness of contracts. We give proof obligations that are sufficient to guarantee the existence of a model for the specification of pure methods. We improve over earlier work by providing a systematic solution including a soundness result and by supporting more forms of recursive specifications. Our technique has been implemented in the Spec# programming system.

[1]  Cliff B. Jones,et al.  Systematic software development using VDM , 1986, Prentice Hall International Series in Computer Science.

[2]  David R. Cok,et al.  ESC/Java2: Uniting ESC/Java and JML , 2004, CASSIS.

[3]  Pierre Castéran,et al.  Interactive Theorem Proving and Program Development , 2004, Texts in Theoretical Computer Science An EATCS Series.

[4]  David R. Cok,et al.  Reasoning with specifications containing method calls and model fields , 2005, J. Object Technol..

[5]  Jean-Louis Lanet,et al.  Java Applet Correctness: A Developer-Oriented Approach , 2003, FME.

[6]  Yves Bertot,et al.  Interactive Theorem Proving and Program Development: Coq'Art The Calculus of Inductive Constructions , 2010 .

[7]  Patrice Chalin,et al.  Are the Logical Foundations of Verifying Compiler Prototypes Matching user Expectations? , 2007, Formal Aspects of Computing.

[8]  K. Rustan M. Leino,et al.  The Spec# Programming System: An Overview , 2004, CASSIS.

[9]  Lilian Burdy,et al.  Well Defined B , 1998, B.

[10]  Cliff B. Jones,et al.  A logic covering undefinedness in program proofs , 1984, Acta Informatica.

[11]  J. Michael Spivey,et al.  Understanding Z : A specification language and its formal semantics , 1985, Cambridge tracts in theoretical computer science.

[12]  David Detlefs,et al.  Simplify: a theorem prover for program checking , 2005, JACM.

[13]  Peter Müller,et al.  Reasoning About Method Calls in Interface Specifications , 2006, J. Object Technol..

[14]  S. C. Kleene,et al.  Introduction to Metamathematics , 1952 .

[15]  Tobias Nipkow,et al.  A Proof Assistant for Higher-Order Logic , 2002 .

[16]  Albert L. Baker,et al.  Preliminary design of JML: a behavioral interface specification language for java , 2006, SOEN.

[17]  K. Rustan M. Leino,et al.  Practical Reasoning About Invocations and Implementations of Pure Methods , 2007, FASE.

[18]  Samuel H. Valentine.  Inconsistency and Undefinedness in Z - A Practical Guide , 1998, ZUM.

[19]  Jean-Raymond Abrial,et al.  The B-book - assigning programs to meanings , 1996 .

[20]  Mandayam K. Srivas,et al.  A Tutorial Introduction to PVS , 1998 .

[21]  Fred B. Schneider,et al.  Avoiding the Undefined by Underspecification , 1995, Computer Science Today.

[22]  Peter Müller,et al.  Checking well-formedness of pure-method specifications ( Full Paper ) , 2008 .

[23]  John A. McDermid,et al.  MODEL CONJECTURES FOR Z SPECIFICATIONS , 1995 .

[24]  Natarajan Shankar,et al.  Subtypes for Specifications: Predicate Subtyping in PVS , 1998, IEEE Trans. Software Eng..

[25]  Patrice Chalin,et al.  A Sound Assertion Semantics for the Dependable Systems Evolution Verifying Compiler , 2007, 29th International Conference on Software Engineering (ICSE'07).

[26]  Albert Hoogewijs,et al.  On a Formalization of the Non-Definedness Notion , 1979, Math. Log. Q..

[27]  Marsha Chechik,et al.  A Practical Approach to Partial Functions in CVC Lite , 2005, D/PDPAR@IJCAR.