In this chapter our intention is to present three large examples of abstract machines. In each of them, we would like to put the emphasis on a particular aspect of specifying.

The goal of the first example, the Invoice System, is to show how to build the technical specification of a data processing system in an incremental fashion. Another important aspect is that of defining how the errors can be trapped in a systematic way. Here, clearly, the intention is to build abstract machines whose operations are viewed as a “repertoire of instructions” for building further machines on top of them, and so on.

The second example (inspired by) is a Telephone Exchange System. The goal here is to show how the concept of abstract machine can be used to model a system where “concurrent” activities take place. The machine we shall specify is intended to be an abstract model of the entire activity of a telephone exchange, where all the telephone conversations are handled simultaneously. Clearly, the mental image of the operations of such a machine does not correspond to “buttons” that can be pressed or to “instructions” that can be invoked. The idea is rather to consider that the operations are events that may occur for some reason. The pre-conditions of such operations are then viewed as the “firing conditions” of such events. In a first approximation, the “real” reason for the occurence of such events, once the firing conditions are met, are not our concerns. Sometimes, it can be the consequence of physical events like someone lifting a telephone hand-set. Sometimes, it is rather a “spontaneous” decision of the system.

This chapter contains the second part of our presentation of set notation. It is devoted to the study of the construction of mathematical objects: that is, finite sets, natural numbers, finite sequences, and finite trees. All such constructions are realized by using the same inductive method based on the fixpoint theorem of Knaster and Tarski. We shall also describe the way recursive functions on these objects can be formally defined.

At the beginning of the chapter generalized intersection and union are presented, then we introduce the framework that we shall use in order to construct our objects. Then the construction of each of the mentioned objects follows in separate sections. Finally, at the end of the chapter, we present the concept of well-foundedness, which unifies completely each of the previous constructs.

Hurried readers, who are not interested in the details of these formal constructions, can skip them. They can go to Appendix A, where the notations are all listed.

Generalized Intersection and Union

Before presenting the framework that will allow us to construct mathematical objects in a systematic manner (section 3.2), we need first to introduce two important set theoretic concepts called generalized intersection and generalized union.

As usual, we first introduce our concepts syntactically, then we give an informal explanation and some examples, and finally we state and prove their basic properties. We now present the syntax of the new constructs.

The main objective of this chapter, and of the next one, is to make precise part of the notation that we intend to use in order to specify and design software systems. As a matter of fact, this notation is nothing but the one used, more or less formally, by every scientist: that of set theory.

Clearly, in order to perform our subsequent formal developments, we could have stayed within some extensions of the logic introduced in the previous chapter. For the following three reasons it is my view that set theory is a better choice.

First, when using set theory, one remains within first order logic while it is clearly possible to manipulate objects of “high order” such as sets and relations of any depth (that is, sets and relations built themselves on sets and relations, and so on). In any case, such constructs are objects (not predicates) and are thus licit candidates for first order quantifications.

Second, and more importantly, the use of set theory allows one, very often, to eliminate quantifiers. In fact, most of the set-theoretic concepts are introduced precisely because they hide some quantifications. Typical examples are: set inclusion, relational composition, and generalized intersection or union of sets of sets.

Third, set theory has the (apparently innocent but, in fact, very important) property of handling negation in a very controlled way: it is simply because the complement of a set is still a set. That is, negation does not extend beyond certain limits.

This book is much more than a new programming manual. It introduces a method in which the program design is included in the global process that goes from understanding the problem to the validation of its solution.

The mathematical basis of the method provides the exactness while the proposed notation eliminates the ambiguities of the vernacular language. At the same time, the process is simple enough for an industrial use “Industrial” is in fact the key word.

The general aim of formal methods is to provide correctness of the problem specification. Here we can see how the solution can be found, step by step, by a continuously monitored process. The mathematical verification of each step is so closely bound to the refinement activity that it is no longer possible to separate the design choices from the checking process. Imagination is helped by exactness!

But how about the efficiency? Isn't the design too long? Are the design people able to do this work? Are the machines powerful enough to implement the method? The answers are easy to give. Let me tell you.

My company has been involved, since the sixties, in the realisation of train control systems, which must meet stringent safety requirements. As soon as we began to use programmed logic (end of the seventies) we had to solve the problem of software correctness. Together with other methods, we chose to use the program proving method proposed by C.A.R. Hoare. In 1986, J.-R. Abrial introduced us to the B method. We decided to learn it and to use it. The tools did not exist at the time.