Introduction

All the previous chapters are about techniques for unambiguously specifying hardware/software systems and transforming abstract specifications into efficient programs. One important motivation for presenting these techniques is the fact that it is often useful to have a distinction between the external view and the internal view of a system. The external view can take the form of a formal specification and it can be optimised with respect to abstractness, compactness and clarity. The internal view is a program which is devised with efficiency in mind. To have two descriptions corresponding to these two views can be considered as a separation of concerns: it helps to manage the complexity of large systems.

This approach introduces additional formal texts when compared with the older approaches dealing mostly with programs. As a consequence, care is needed to maintain the overview of all formal texts that arise when designing large systems.

This chapter presents two techniques developed in the context of COLD-K which serve for keeping this overview. These are certainly not the only useful techniques; they should be complemented with additional graphical techniques and classical software engineering techniques for configuration management, project management, etc. The first technique is to use simple pictures showing the modular structure of a formal specification. This is the topic of Section 11.2. The second technique is to add structure, putting specifications and implementations together in simple language constructs called components and designs. This is the topic of Section 11.3. Finally, Sections 11.4 and 11.5 present a number of applications as well as some concluding remarks.

This monograph promotes specification and programming on the basis of Horn logic with equality. As was pointed out in [Pad88a], this theoretical background equips us with a number of deductive methods for reasoning about specifications and designing correct programs. The term declarative programming stands for the combination of functional (or applicative) and relational (or logic) programming. This does not rule out the design of imperative programs with conditionals, loops and sequences of variable assignments, since all these features have functional or relational equivalents. In particular, variables become “output parameters” of functions. Hence the static view of declarative programming is not really a restriction. Only if correctness conditions concerned with liveness or synchronization are demanded, transition relations must be specified for fixing the dynamics of program execution (cf. Sect. 6.6).

Design specifications

With regard to the overall software design process, the methods considered here are tailored to design specifications, each consisting of a many-sorted signature SIG denoting data, functions and predicates to be specified and a set of Horn clauses over SIG, allowing more or less abstract presentations of declarative programs and the data structures they use and manipulate (cf. Sects. 1.1 and 1.2). Associated with a design specification DS is a requirement specification, the conjecture section of DS, which consists of correctness conditions on DS. In contrast to design axioms, Horn clauses are not always sufficient for specifying requirements. Hence we admit positive Gentzen clauses, which may involve disjunctions and existential quantifiers, in a requirement specification (cf. Sect. 1.4).

Kinds of axioms

In Chapter 2 a number of techniques for setting up algebraic specifications were given. Now we want to do the same for state-based specifications. Recall that a state-based specification serves to describe a system whose model is a ‘class’. A class is a kind of state-machine where each state has an algebra associated with it. Because each such algebra can be viewed as a static world model, classes with their state transitions can be viewed to model dynamic systems. Special language constructs to specify these systems were introduced, such as procedures and the operators of dynamic logic. It is typical for these language constructs that they leave the sort of states implicit.

Therefore the techniques of Chapter 2 are mostly useful for describing the static aspects of states, whereas we need complementary guidelines for dealing with the dynamic aspects of a system. This is the main topic of this chapter. Key notions are that of precondition, postcondition and invariant.

In practice it turns out that there are certain patterns that occur quite often in state-based specifications, providing methodological guidelines for systematically setting up state-based specifications. In this chapter we shall do this, focusing on the axioms, and we adopt a classification distinguishing four distinct roles an axiom can play. These roles correspond to typical syntactic patterns. We shall refer to these by saying that there are four kinds of axioms:

1. properties of all states;

2. invariance properties;

3. properties of the initial state;

4. properties of state transitions including pre- and postcondition axioms and termination axioms.

In this section we will introduce the typed formal language PBC for the Propositional logic of Boolean Categories which may be regarded as loop-free propositional dynamic logic with data types. The main result is that the set of formulas valid in all Boolean categories coincides precisely with the set of formulas true in Mfn. We give two proofs. The first works only for atomic Boolean categories, but the construction is very straightforward. The second, general proof uses ultrafilters and follows that of [Kozen 1980] for dynamic algebras.

The language PDL of [Fischer and Ladner 1979] defines programs and formulas by mutual recursion as follows (where we have made notational changes to conform to previous sections of this paper):

Atomic programs are programs; ∅ is a program; if α, β are programs and P is a formula then αβ, α + β, α* and p (the guard corresponding to P) are programs.

Atomic formulas are formulas; true and false are formulas; if P, Q are formulas and α is a program then P∪Q, P′ and < α > P are formulas.

The Kripke model semantics which is standard for PDL is, essentially, Mfn so that α + β = α∪β and α* are available. In particular, if-then-else can be expressed as in 8.24. The identity program is expressible as 0*.

Formal semantics is a topic of major importance in the study of programming languages. Its applications include documenting language design, establishing standards for implementations, reasoning about programs, and generating compilers.

This book is about action semantics, a recently-developed framework for formal semantics. The primary aim of action semantics is to allow useful semantic descriptions of realistic programming languages.

Action semantics combines formality with many good pragmatic features. Regarding comprehensibility and accessibility, for instance, action semantic descriptions compete with informal language descriptions. Action semantic descriptions scale up smoothly from small example languages to full-blown practical languages. The addition of new constructs to a described language does not require reformulation of the already-given description. An action semantic description of one language can make widespread reuse of that of another, related language. All these pragmatic features are highly desirable. Action semantics is, however, the only semantic framework that enjoys them! (For syntax, context-free grammars have similar features, which perhaps accounts for their popularity in language reference manuals.)

Action semantics is compositional, like denotational semantics. The main difference between action semantics and denotational semantics concerns the universe of semantic entities: action semantics uses entities called actions, rather than the higher-order functions used with denotational semantics. Actions are inherently more operational than functions: when performed, actions process information gradually.

Primitive actions, and the various ways of combining actions, correspond to fundamental concepts of information processing. Action semantics provides a particular notation for expressing actions.

• Denotational semantics has poor pragmatic features, due to its use of the λnotation.

• Several so-called algebraic frameworks are essentially operational.

• Genuinely axiomatic frameworks are prone to incompleteness and inconsistency.

• Operational semantics is useful; action semantics makes it easier.

Action semantics is not the only available framework for giving formal semantic descriptions of programming languages. Other frameworks include denotational semantics, various kinds of algebraic semantics, axiomatic semantics, and operational semantics. What is wrong with them all? Why should one prefer action semantics—at least for describing full-scale, realistic programming languages?

Let us look briefly at most of the other frameworks in turn, pointing out their major defects in comparison to action semantics. To make the discussion accessible to those not familiar with the various frameworks, we indicate their main features, and cite primary references. However, a full appreciation of the comparisons requires in-depth familiarity with both action semantics and the other frameworks, as well as a more thorough discussion than can be provided here.

Almost all frameworks for formal semantics are based on context-free abstract syntax, although the notations that they use to specify abstract syntax are quite varied. The grammars that we use in action semantic descriptions perhaps have some significant advantages over other ways of specifying abstract syntax. But our main interest here is in the essential differences concerning the specification of semantics, once abstract syntax has been specified, so let us not pursue this point further.

Part II introduces the details of action notation systematically, explaining the underlying concepts and the intended interpretation of the symbols. It is intended to be read together with Part III, which illustrates the use of action notation in semantic descriptions.

Some of the Appendices provide further details of the foundations of action notation, and summarize the explanations given throughout Part II. Appendix B specifies some algebraic properties of the entire action notation; this also reduces action notation to a reasonably small kernel. Appendix C defines the abstract syntax of the kernel, and gives the formal definition of its meaning, using structural operational semantics. Appendix D summarizes the informal explanations of the full action notation, for convenience of reference. Appendix E gives the complete algebraic specification of the data notation included in action notation.

Navigation

• If this is your first reading, proceed in parallel through Parts II and III: Chapter 4) Chapter 11, Chapter 5, Chapter 12, and so on. This way, you see an illustration of the use of each part of action notation immediately after its introduction

• Alternatively, you could look at each chapter of Part III before the corresponding chapter of Part II. This way, the illustrations in Part III motivate the action notation introduced in Part II.

• If you are revising, and would like an uninterrupted presentation of action notation, proceed straight through Part II.