The use of hierarchy is an important component of object-oriented design. Hierarchy allows the use of type families, in which higher level supertypes capture the behavior that all of their subtypes have in common. For this methodology to be effective, it is necessary to have a clear understanding of how subtypes and supertypes are related. This paper takes the position that the relationship should ensure that any property proved about supertype objects also holds for its subtype objects. It presents two ways of defining the subtype relation, each of which meets this criterion, and each of which is easy for programmers to use. The subtype relation is based on the specifications of the sub- and supertypes; the paper presents a way of specifying types that makes it convenient to define the subtype relation. The paper also discusses the ramifications of this notion of subtyping on the design of type families.

Specifications are useful because they allow reasoning about objects without concern for their implementations. Type hierarchies are useful because they allow types that share common properties to be designed as a family. This paper is concerned with the interaction between specifications and type hierarchies. We present a way of specifying types, and show how some extra information, in addition to specifications of the objects' methods, is needed to support reasoning. We also provide a new way of showing that one type is a subtype of another. Our technique makes use of information in the types specifications and works even in a very general computational environment in which possibly concurrent users share mutable objects. 1.

Object-oriented systems are typically structured as complex networks of interacting mutable objects. To reason about such systems, simple and efficient techniques for coping with aliasing are needed. This paper identifies several key criteria for evaluating techniques for reasoning about aliasing, then proposes a technique which satisfies these criteria. The proposed technique is a simple extension of the traditional local store technique for modelling pointers. The increasing popularity of the object-oriented style of programming has resulted in a renewed interest in reasoning about aliasing. Aliasing is common in object-oriented systems, because they are typically structured as complex networks of interacting mutable objects. Simple and efficient techniques for coping with aliasing are a pre-requisite to reasoning effectively about the behaviour of such systems. Techniques for reasoning about aliasing within data structures and aliasing between program variables were thorough...

Subtype polymorphism, based on syntactic conformance of objects' methods and used for substituting subtype objects for supertype objects, is a characteristic feature of the object-oriented programming style. While certainly very useful, typechecking of syntactic conformance of subtype objects to supertype objects is insufficient to guarantee correctness of object substitutability. In addition, the behaviour of subtype objects must be constrained to achieve correctness. In class-based systems classes specify the behaviour of the objects they instantiate. In this paper we define the class refinement relation which captures the semantic constraints that must be imposed on classes to guarantee correctness of substitutability in all clients of the objects these classes instantiate. Clients of class instances are modelled as programs making an iterative choice over invocation of class methods, and we formally prove that when a class C # refines a class C, substituting instances of C # for instances of C is refinement for the clients.

The use of hierarchy is an important component of object-oriented design. Hierarchy allows the use of type families, in which higher level supertypes capture the behavior that all of their subtypes have in common. For this methodology to be effective, it is necessary to have a clear understanding of how subtypes and supertypes are related. This paper takes the position that the relationship should ensure that any property proved about supertype objects also holds for its subtype objects. It presents two ways of defining the subtype relation, each of which meets this criterion, and each of which is easy for programmers to use. The subtype relation is based on the specifications of the sub- and supertypes; the paper presents a way of specifying types that makes it convenient to define the subtype relation. The paper also discusses the ramifications of this notion of subtyping on the design of type families. 1 Introduction What does it mean for one type to be a subtype of another? We arg...

Abstract not found

. We present a theory of object-orientation on the basis of the refinement calculus. This theory allows for specifying the behaviour of objects and provides a calculus for the proof of relationships between classes such as refinement. Given two similar, but not identical classes, we present an algorithm to construct a common superclass which is refined by both classes, and an algorithm to construct a common subclass which refines both classes. As an example, we present an account manager to illustrate design and verification. The overall approach aims at giving a simple theoretical basis for incremental object-oriented software construction. We demonstrate how formal specification and verification can be integrated into the development process, and thus can be put into practical use. 1 Introduction Object-orientation supplies structuring constructs for software systems which are new, compared to traditional programming. These structuring constructs support a development process that ...

Refinement calculi are program logics which formalize the “top-down ” methodology of software development promoted by Dijkstra and Wirth in the early days of structured programming. I present here the shallow embedding of a refinement calculus into Coq constructive type theory. This embedding involves monad transformers and the computational reflexion of weakest-preconditions, using a continuation passing style. It should allow to reason about many ML programs combining non-functional features (state, exceptions, etc) with purely functional ones (higher-order functions, structural recursion, etc). The interest of combining higher-order functions and imperative state modifications is examplified here on the modelization of the game of Nim. 1

Abstract not found

Abstract not found