Results 1 - 10
of
19
Modular invariants for layered object structures
- Science of Computer Programming
"... Classical specification and verification techniques support invariants for individual objects whose fields are primitive values, but do not allow sound modular reasoning about invariants involving more complex object structures. Such non-trivial object structures are common, and occur in lists, hash ..."
Abstract
-
Cited by 66 (30 self)
- Add to MetaCart
Classical specification and verification techniques support invariants for individual objects whose fields are primitive values, but do not allow sound modular reasoning about invariants involving more complex object structures. Such non-trivial object structures are common, and occur in lists, hash tables, and whenever systems are built in layers. A sound and modular verification technique for layered object structures has to deal with the well-known problem of representation exposure and the problem that invariants of higher layers are potentially violated by methods in lower layers; such methods cannot be modularly shown to preserve these invariants. We generalize classical techniques to cover 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.
State based ownership, reentrance, and encapsulation
- In: European Conference on Object-Oriented Programming (ECOOP
"... Abstract. A properly encapsulated data representation can be revised for refactoring or other purposes without affecting the correctness of client programs and extensions of a class. But encapsulation is difficult to achieve in object-oriented programs owing to heap based structures and reentrant ca ..."
Abstract
-
Cited by 23 (11 self)
- Add to MetaCart
Abstract. A properly encapsulated data representation can be revised for refactoring or other purposes without affecting the correctness of client programs and extensions of a class. But encapsulation is difficult to achieve in object-oriented programs owing to heap based structures and reentrant callbacks. This paper shows that it is achieved by a discipline using assertions and auxiliary fields to manage invariants and transferrable ownership. The main result is representation independence: a rule for modular proof of equivalence of class implementations. 1
Reasoning about Method Calls in Interface Specifications
- JOURNAL OF OBJECT TECHNOLOGY
, 2006
"... ... In this paper, we illustrate the subtle problems any encoding of method calls in specifications has to address. We present a sound encoding that allows side-effect free methods to create and initialize objects by explicitly modeling such modifications of the heap. ..."
Abstract
-
Cited by 19 (11 self)
- Add to MetaCart
... In this paper, we illustrate the subtle problems any encoding of method calls in specifications has to address. We present a sound encoding that allows side-effect free methods to create and initialize objects by explicitly modeling such modifications of the heap.
The Spec# Programming System: Challenges and Directions
- IN PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON VERIFIED SOFTWARE: THEORIES, TOOLS, EXPERIMENTS
, 2005
"... ..."
Reasoning about method calls in JML specifications
- Proceedings of the Seventh Workshop on Formal Techniques for Java-like Programs (FTfJP
, 2005
"... Abstract. The Java Modeling Language, JML, is an interface specification language that uses side-effect free Java expressions to describe program behavior. In particular, JML specifications can contain calls to side-effect free methods. To verify programs w.r.t. JML specifications, JML expressions h ..."
Abstract
-
Cited by 15 (1 self)
- Add to MetaCart
Abstract. The Java Modeling Language, JML, is an interface specification language that uses side-effect free Java expressions to describe program behavior. In particular, JML specifications can contain calls to side-effect free methods. To verify programs w.r.t. JML specifications, JML expressions have to be encoded in a program logic. This encoding is non-trivial for method calls. In this paper, we illustrate several subtle problems any program verifier for JML has to address. We present an encoding of method calls that handles abrupt termination, allows methods to create and initialize objects, and is sound, even if the JML specification is not satisfiable. 1
Flexible Immutability with Frozen Objects
"... Object immutability is a familiar concept that allows safe sharing of objects. Existing language support for immutability is based on immutable classes. However, class-based approaches are restrictive because programmers can neither make instances of arbitrary classes immutable, nor can they contro ..."
Abstract
-
Cited by 8 (2 self)
- Add to MetaCart
Object immutability is a familiar concept that allows safe sharing of objects. Existing language support for immutability is based on immutable classes. However, class-based approaches are restrictive because programmers can neither make instances of arbitrary classes immutable, nor can they control when an instance becomes immutable. These restrictions prevent many interesting applications where objects of mutable classes go through a number of modifications before they become immutable. This paper presents a flexible technique to enforce the immutability of individual objects by transferring their ownership to a special freezer object, which prevents further modification. The paper demonstrates how immutability facilitates program verification by extending the Boogie methodology for object invariants to immutable objects. The technique is based on Spec#’s dynamic ownership, but the concepts also apply to other ownership systems that support transfer.
Assertion-based encapsulation, object invariants and simulations
- In FMCO post-proceedings
, 2005
"... Abstract. In object-oriented programming, reentrant method invocations and shared references make it difficult to achieve adequate encapsulation for sound modular reasoning. This tutorial paper surveys recent progress using auxiliary state (ghost fields) to describe and achieve encapsulation. Encaps ..."
Abstract
-
Cited by 5 (3 self)
- Add to MetaCart
Abstract. In object-oriented programming, reentrant method invocations and shared references make it difficult to achieve adequate encapsulation for sound modular reasoning. This tutorial paper surveys recent progress using auxiliary state (ghost fields) to describe and achieve encapsulation. Encapsulation is assessed in terms of modular reasoning about invariants and simulations. 1
On behavioral subtyping and completeness
- In ECOOP Workshop on Formal Techniques for Java-like Programs
, 2005
"... Abstract. Behavioral subtyping forces objects of subtypes to behave in the same way as objects of supertypes. It is often favored over standard subtyping because it provides a means to obtain a modular program logic. Relative completeness is a formal property of a Hoare logic that ensures that any f ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
Abstract. Behavioral subtyping forces objects of subtypes to behave in the same way as objects of supertypes. It is often favored over standard subtyping because it provides a means to obtain a modular program logic. Relative completeness is a formal property of a Hoare logic that ensures that any failed attempt to verify the correctness of a program is not caused by a weakness of its Hoare rules. In this paper, we argue that the standard relative completeness notion is too stringent for program logics that are based on behavioral subtyping. Subsequently, we propose two novel and complementary completeness notions that can be employed to assess the strength of program logics that rely on behavioral subtyping. 1
Allowing state changes in specifications
- In Günter Müller, editor, International Conference on Emerging Trends in Information and Communication Security (ETRICS), volume 3995 of Lecture Notes in Computer Science
, 2006
"... Abstract. We provide a static analysis (using both dataflow analysis and theorem proving) to allow state changes within specifications. This can be used for specification languages that share the same expression sub-language with an implementation language so that method calls can appear in precondi ..."
Abstract
-
Cited by 3 (3 self)
- Add to MetaCart
Abstract. We provide a static analysis (using both dataflow analysis and theorem proving) to allow state changes within specifications. This can be used for specification languages that share the same expression sub-language with an implementation language so that method calls can appear in preconditions, postconditions, and object invariants without violating the soundness of the system. 1
Proving Consistency of Pure Methods and Model Fields
"... 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 ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
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.

