This chapter is the first of three tutorial chapters on the basic features and programming techniques of CML. This chapter focuses on the features that make up CML's semantic core. The next chapter continues with a discussion of the two most important styles of CML programming: process networks and client-server protocols. Chapter 5 completes the tutorial with further discussion of CML's synchronization and communication mechanisms.

Sequential programming

As is the case with most concurrent languages, CML consists of a sequential core language — Standard ML — extended with concurrency primitives. The individual processes in a CML program are programmed using the features of SML. While we conceptually view CML as a programming language, it is actually implemented as a collection of modules on top of SML/NJ. The aspects of CML described in this chapter all belong to the core structure of this library, which is named CML. To reduce notational clutter, most of the examples in this chapter are assumed to be given in an environment where the CML structure has been pre-opened (i.e., all of its bindings are at top-level). The CML structure's interface is described in Appendix A, which contains an abridged version of the CML Reference Manual.

CML is a message-passing language, which means that processes are viewed as executing in independent address spaces with their only communication being via messages. But, since SML provides updatable references, this is a fiction that must be maintained by programming style and convention.

In Chapter 2 it was already mentioned that correctness of an implementation essentially means that the corresponding diagrams commute weakly. Recall that there are four possible ways in which this can be defined, each implying a notion of simulation. This is depicted in Figures 4.1–4.4 for a single operation (note the direction of the inner arrows).

In this chapter the subtle differences between these notions of simulation are studied. Such differences must be taken into account, e.g., when concatenating simulation diagrams. Also we investigate how these notions behave under vertical stacking and how they are related to each other. The outcome has serious consequences for the value of U- and U−1-simulation.

With the necessary technical machinery at hand, we are finally able to show how data invariants can be used to convert partial abstraction relations into total ones.

Then we analyze soundness and completeness of simulation as a method for proving data refinement.

We undertake most of our investigations in a purely semantic set-up, suppressing the distinction between syntax and semantics as much as possible.

Figure 4.1 represents U-simulation, and Figure 4.2 represents L-simulation. The diagrams in Figures 4.3 and 4.4 represent U−1 -simulation and L−1-simulation, respectively. Because a concrete operation can be less nondeterministic than the corresponding abstract operation, we say that the diagrams commute weakly. This weak form of commutativity is expressed by “⊆” in the following definitions. (Strong commutativity would be expressed by “=”.)

Composing Simulation Diagrams

To obtain a compositional theory of simulation, it would be interesting to have a sufficiently strong condition under which these kinds of simulation hold for composed diagrams.

The goal of this monograph is the introduction of, and comparison between, various methods for proving implementations of programs correct. Although these methods are illustrated mainly by applying them to correctness proofs of implementations of abstract data structures, the techniques developed apply equally well to proving correctness of implementations in general. For we shall prove that all these methods are only variations on one central theme: that of proof by simulation, of which we analyze at least 13 different formulations.

As the central result we prove that these methods either imply or are equivalent to L-simulation (also called forward or downward simulation in the literature) or a combination of L- with L−1-simulation (the latter is also called backward or upward simulation). Since, as shown by Hoare, He, and Sanders, only the combination of these forms of simulation is complete, this immediately establishes when these methods are complete, namely, when they are equivalent to this combination.

Our motivation for writing this monograph is that we believe that in this area of computer science (as well as in various other areas) the duty of universities is not to train students in particular methods, but rather to give students insight in both similarities and differences between methods such as VDM, Z, the methods advocated by Reynolds and Hehner, and methods more directly based on Hoare Logic or predicate transformers. The reason for this conviction is that computer science develops far too quickly for us to believe that any of these methods will survive in its present form.

This part presents an overview of some existing formalisms for proving data refinement. We analyze for each of the selected formalisms how it relates to simulation in its various shapes (partial vs. total correctness, relational vs. predicate transformer semantics). This allows us to compare the power of these formalisms when it comes to data refinement. The reader should be warned, however, that this does not at all imply a ranking that should be used as a guideline for selecting a particular method for a development project.

In Chapters 11 and 12, Reynolds' method and VDM are described and related to the results of Part I, and in Chapter 13 this is done for Z, Hehner's method, and Back's refinement calculus. In Section 13.1 we not only introduce the Z-notation and state Z's method for proving data refinement, but also explain why the latter is equivalent, modulo notation, with the VDM method for proving data refinement as stated in Chapter 12. Consequently, Z does not introduce anything new from the point of view of data refinement, although it constitutes a considerable improvement w.r.t. the important topic of structuring specifications.

The main result of these chapters is that these methods can be considered as applications of the L-simulation principle. Back's refinement calculus is similar to the one presented in Chapter 10 in that it is based on weakest precondition predicate transformer semantics and in that its notion of simulation is a kind of powersimulation.

Hoare logic is a formal system for reasoning about Hoare-style correctness formulae. It originates from C. A. R. Hoare's 1969 paper “An axiomatic basis for computer programming” [Hoa69], which introduces an axiomatic method for proving programs correct. Hoare logic can be viewed as the structural analysis of R. W. Floyd's semantically based inductive assertion method.

Hoare's approach has received a great deal of attention ever since its introduction, and has had a significant impact on methods both for designing and verifying programs. It owes its success to three factors:

1. (i) The first factor, which it shares with the inductive assertion method, is its universality: it is state-based, characterizes programming constructs as transformers of states, and therefore applies in principle to every such construct.

2. (ii) The second factor in its success is its syntax directedness: every rule for a composed programming construct reduces proving properties of that construct to proving properties of its constituent constructs. In case the latter are also formulated as Hoare style correctness formulae — when characterizing parallelism this is not always the case — Hoare logic is even compositional: proving Hoare style correctness formulae for composed constructs is reduced to proving Hoare style correctness formulae for their constituent constructs without any additional knowledge about the latter's implementation. Hoare's 1969 logic is compositional.

Compositional Hoare logics can also be regarded as design calculi. In such a design calculus a proof rule is interpreted as a design rule, in which a specific design goal, that of developing a program satisfying certain properties, is reduced to certain subgoals (and, in general, the satisfaction of certain verification conditions), obtained by reading that rule upside-down.

Introduction

In the glossary of terms in his book [J90] Cliff Jones explains the origin of the name Vienna Development Method.

VDM is the name given to a collection of notation and concepts which grew out of the work of the IBM Laboratory, Vienna. The original application was the denotational description of programming languages. The same specification technique has been applied to many other systems. Design rules which show how to prove that a design satisfies its specification have been developed. [J90, p. 294]

Of the techniques mentioned above, Bicarregui et al [BFL+94] stress three as the main ones: the specification language VDM-SL, data refinement techniques, and operation decomposition techniques, where the latter term refers to refinement as opposed to data refinement, for instance, the implementation of a specification statement by a loop.

One keyword in the quote above is ‘rule’. Nowadays the first impression a student might get when learning and practising VDM is that of a huge collection of rules to guide writing specifications. Indeed, specifying with VDM mostly comprises two activities carried out together:

• writing specifications of, e.g., types, functions, and operations in the specification language and

• discarding proof obligations — preferably by formal proof — that ensure, for instance, that a type1 is nonempty, a function specification is well-formed, a specification of an operation is satisfiable, or a specification is implemented by an operation.

• Of course, we focus in this monograph on the proof obligations that arise in the process of data refinement.

Binary relations on states are not the only semantic domain for representing sequential, nondeterministic programs. Since Dijkstra published his first paper on weakest preconditions in 1975 ([Dij75]), a rich theory based on monotone functions mapping sets of states to sets of states has emerged. Such functions are called predicate transformers. For instance, one models programs as functions mapping each postcondition to the corresponding weakest precondition. One branch of this theory concentrates on our primary subject, namely, the stepwise refinement of programs, possibly using data refinement techniques [B80, MV94, Mor89a, vW90]. The major drawback of predicate transformer as models of programs is that they are more complicated than binary relations because the domain of predicate transformers is richer than what we intend to model, i.e., not every predicate transformer represents one of our programs. But the predicate transformer approach also has its advantages. Several main results achieved in previous chapters, especially the completeness theorems (Chapters 4 and 9) and the calculation of maximal simulators (Chapters 7 and 9), require rather complicated proofs. The aim of this chapter is to demonstrate that more elegant and succinct proofs for these and also some new results exist, such as, for instance, isomorphism theorems between the relational and predicate transformer world for various forms of correctness and the use of Galois connections.

In this chapter we briefly introduce and discuss three more methods. These are Z, Hehner's method, and Back's Refinement Calculus. We do not intend to describe them in as much detail as Reynolds' method and VDM in the previous two chapters. We concentrate just on the data refinement aspects of these methods and analyze quickly how they compare to the methods already discussed.

All three methods discussed in this chapter turn out to be quite different members of the L-simulation community.

Originally Z was invented as another notation for Zermelo-Fränkel set theory. However, it evolved to a development style (or method) for specifications. Although invented by academics, Z is nowadays relatively popular in industry, especially in Europe. As will turn out at the end of our discussion of Z in Section 13.1, there is not much difference between Z and VDM from the data refinement point of view. The subtle differences between these two methods apart from the notational ones are analyzed elsewhere; see e.g. [HJN93].

Hehner arrives at a strikingly simple syntax-based development method by using first order predicate logic as the specification language [Heh93]. Whereas VDM uses two predicates, namely pre- and postconditions, Hehner needs only a single predicate. Moreover he interprets his predicates in a classical twovalued model similar to ours from Section 5.2 for two sets of variables: input and output variables. As we shall see in Section 13.2, Hehner's notion of data transformer corresponds to a total L-simulation relation combined with the solution to the L-simulation problem given in Section 7.2.

Introduction

This chapter is based on the fifth chapter of John Reynolds’ book “The craft of programming” [Rey81]. The material in Section 11.2 is taken verbatim from his book.

In contrast to Part I, Reynolds is mainly concerned with top-down development of programs rather than proving refinement between data types. His method of deriving programs is called stepwise refinement and was introduced in [Wir71] and [DDH72]. One of his development techniques, however, is related to data refinement. In this chapter we shall present and analyze this technique and show that it amounts to L-simulation.

In a given program Reynolds inspects each particular variable of some abstract data type separately, and shows how the choice of a way to implement that variable is guided by the number and relative frequency of the operations performed on it. This allows differentiation between the implementation of different variables of the same data type.

Reynolds uses Hoare-style partial correctness specifications. However, none of his program transformation steps increases the domain of possible nontermination. Therefore his examples of refinement are also refinements in a total correctness interpretation.

In Section 11.3 we relate Reynolds' method to L-simulation. At the last stage of our analysis of Reynolds' method we shall see that we have to interpret some of his operations in a total correctness setting to bridge a gap between his requirements and those for partial correctness L-simulation. Formally, this is supported by the L-simulation theorem for total correctness, Theorem 9.9.

We close this chapter with some remarks on the history of this method.

In the previous chapter, our proof techniques for data refinement, namely the notions of simulation introduced in Def. 2.1, have been proven adequate in Theorem 4.17 and sound in Theorem 4.10. This establishes proving simulation as an appropriate technique for verifying data refinement.

In Chapters 9 and 10 we shall encounter other notions of data refinement and simulation defined for frameworks different from that of the binary relations considered until now, for which similar soundness and completeness results will be proven.

In Part II of this monograph a number of established methods for proving data refinement will be similarly analyzed. (These methods are: VDM, Z, and those of Reynolds, Hehner, Back, Abadi and Lamport, and Lynch.) This is done by showing to what extent they are special cases of, or are equivalent to, the previously investigated notions of simulation referred to above, which are the subject of Part I of this monograph.

This justifies considering simulation as a generic term for all these techniques, where the connection with data refinement is made through appropriate soundness and completeness theorems.

Now an immediate consequence of our goal of comparing these simulation methods for proving data refinement is that we must be able to compare semantically expressed methods such as L-simulation and the methods of Abadi and Lamport and of Lynch (see Chapter 14) with syntactically formulated ones such as VDM, Z, and Reynolds' method. This implies immediately that we have to distinguish between syntax and semantics. We bridge this gap by introducing interpretation functions for several classes of expressions, such as arithmetic expressions and predicates built on them (see Section 5.2), programs (see Section 5.3), and relations (see Section 5.4).