this paper, we show that there is a real di#erence between control predicates and dummy variables. Although dummy variables can represent the control state, the implicit nature of this representation limits their utility. The use of explicit control predicates allows a strengthening of the ordinary Owicki-Gries method that makes it easier to write annotations. Our strengthening of the Owicki-Gries method eliminates a well-known weakness in the original method. Assertional methods for proving safety properties involve proving the invariance of an assertion. In the Ashcroft method [1], one writes a single global assertion; in the Owicki-Gries method, the global assertion is decomposed into an annotation of the program. It often happens that when the global invariant used in an Ashcroft-method proof is decomposed in the obvious way, the original Owicki-Gries method cannot prove its invariance; a di#erent and often more complicated annotation must be used. This is not the case with the strengthened version. If the Ashcroft method can prove invariance of a global assertion, then the strengthened Owicki-Gries method can prove the invariance of the corresponding annotation. Strengthening the Owicki-Gries method makes it easier to construct proofs; it does not change what can be proved. The global invariant used in an Ashcroft-style proof can always be translated into a proof with the original Owicki-Gries method by simply attaching the global invariant to all control points, though of course this defeats the whole purpose of the method, which is to decompose the invariant. Moreover, even though the original Owicki-Gries method fails on one simple decomposition of the invariant, there may be another equally simple decomposition for which it does work. What we claim is that usin...

Dijkstra introduced an enticing development strategy in a paper addressing the readers/ writers problem. This strategy is as follows: one starts with some \stupid" (in the sense that it allows undesirable computations) rst try and then tries in subsequent steps to \rene" this stupid try into a better one by eliminating (some) undesirable computations. In a number of steps one strives to get a good (in the sense that it no longer contains undesirable computations) implementation for the problem. Unfortunately this strategy is not very formal. In this paper we try to make it more formal by using Stark's temporal logic based rely/guarantee formalism. We use this formalism in a special way in order to describe Dijkstra's development strategy: the part intended to describe the liveness condition is used for the more general purpose of disallowing the undesirable sequences. 1 Introduction Current formal methods are far from solving the problems in software development. The simplest view o...

In order to develop formal methods for the design, analysis and implementation of object-oriented systems it is essential to formalise the underlying object-oriented concepts. At present, most object-oriented concepts are treated informally, or are defined with reference to a particular language. The aim of this paper is to present a formal view of behavioural compatibility for classes which is independent of any language or methodology. Starting with an external view of classes, we define behavioural class compatibility from two points of view. The relationship between these definitions for compatibility and inheritance is then discussed. 1 Introduction Over the last decade object orientation has gained rapid popularity in the programming language community as a useful implementation methodology[14, 24, 30]. More recently, it has also been applied to specification languages[4, 8, 12]. Object-orientation simplifies the construction of complex systems using the notions of inheritance ...

this paper. See [9] for an introduction to aliasing and orthogonality in sequential programs.