Prorgram Development by Stepwise Refinement: Case Studies Using

E. Sekerinski and K. Sere (Eds) Program Development by Refinement Case Studies Using the B Method Springer-Verlag Berlin Heidelberg NewYork London Paris Tokyo Hong Kong Barcelona Budapest Preface The Idea of Program Refinement Programs are complex. They are typically so complex, that they go beyond the full comprehension even of the programmer or team who designed them, with all the consequences this has. How can we cope with such complexity in a satisfactory way? An approach, advocated for a long time, is to separate a concise specification of a program — the “what” — from a possibly involved implementation — the “how”. Once a specification is obtained from the set of requirements on the program, there can still be a large gap to an efficient implementation. The development from specification to implementation can then proceed by a succession of layers, such that each layer is a refinement of the previous one. Design decisions can be introduced in refinement steps one at a time. By this, the refinement steps can be kept small and manageable. Still, the set of all requirements can be far too large to be taken completely into account in the initial specification. Even if they could, they might obscure issues more than clarify them. For example: An information system for stored goods needs to produce an error message on il- legal input. Yet, the exact wording — and even the language — of those messages is irrelevant for an understanding of the essence of the system. A banking application interacts with customers with a graphical interface. Yet the specification of the graphical layout is secondary compared to the specification of the possible transactions. For a mailing system the possible physical distribution of the users is an essen- tial requirement. Yet it can be ignored for an initial specification of the logic of message delivery. Such requirements do not need to be reflected in the initial specification. Rather, they can better be taken into account in subsequent refinement steps. Hence, our picture of program development is that the initial specification is only a partial one, though, by slight abuse, we still refer to it as the specification. Subsequent refinement steps take further requirements into account or represent design decisions (Fig. 0.1). vi Preface R0 S0 R1 S1 . Rn Fig. 0.1. Program Development by Refinement: R , , Rn S 0 n are the requirements, S0 is the specification, Sn is the implementation, and the other Si are intermediate refinements; Solid arrows stand for the refinement relation The B Method The B Method is an approach for the industrial development of highly trusted software. It is the outcome of two decades of academic research on program specification and refinement: It offers a rich collection of set-theoretic data types for an abstract specification of the state of systems. It allows the use of standard first-order predicate logic for the specification of operations on the state. It uses a relational semantics for statements and supports consistency and correct- ness proofs of operations by weakest precondition calculation. It supports grouping of operations and encapsulation of state variables in mod- ules, called machines. It supports algorithmic refinement of operations and data refinement of state variables in machines. It allows the construction of new machines out of existing ones. Currently there are two commercial tools supporting the B Method, B-Toolkit from B Core, UK and Atelier B from Steria, France. Both tools address issues of documentation, project management, and prototyping which are necessary for large- scale use, beside issues of verification and code generation. The tools achieve a remarkable degree of automation in checking refinements by proof, as well as in project management. Even though the tools are still being further developed, the B Method with its current tool support can be considered the most advanced general purpose environment for producing highly trustworthy software. Preface vii Contents of the Book This book is a collection of case studies in program refinement with the B Method. Each chapter shows a typical program development from problem analysis to implementation with a non-trivial example, using one of the tools. The developments include a discussion and justification of the chosen approach as well as experiences with the tools used. The developments are intended to be representative of a whole class of related problems. The book is divided in two parts. Part I considers the development of information systems and data structures. These examples demonstrate the typical use of the B Method, in particular the development by a sequence of refinement steps, the con- sideration of further requirements in refinement steps, and the use of object-oriented models with the B Method. For the benefit of readers who are not familiar with the B Method, the first chapter gives an introduction to it. The other chapters of the first part can be read in any order. Chapter 1: Introduction to the B Method. This chapter introduces the basic con- cepts of the B Method, substitutions, statements, machines, invariants, nonde- terminism, algorithmic and data refinement, layered development, and refinement and implementation machines. The use of these is illustrated by a series of examples. Also, the impact of the finiteness of numbers and of the memory is discussed and the use of the B-Toolkit library is illustrated. Chapter 2: Container Station. The container station is an information system with a rather complex structure of the state and an elaborate set of requirements. This chapter exemplifies the use of various set-theoretic data types and operations for describing and manipulating a complex state. Moreover, it shows how the initial specification can be kept abstract and how requirements like fairness of a scheduling strategy and error reporting can be incorporated in refinement steps. This chapter also exemplifies the use of library machines provided with the B-Toolkit for the implementation. Chapter 3: Minimum Spanning Tree. This chapter is about an algorithm on graphs with a simple abstract specification but an intricate implementation. It shows how introducing further B machines during refinement leads to better modular- isation for reuse and helps to keep the proof obligations simpler. The last point is known as design for provability. The B machines introduced in the development for maintaining equivalence classes with union-find, priority queues, and heaps, are of interest on their own. Chapter 4: The B Bank. This chapter develops a simple but complete application for banking over the Internet. An object-oriented model is used as an aid during analysis, which is translated to a B machine which specifies the key function- ality. For the implementation, new base machines for persistent object storage and for string handling are introduced. These are of general usefulness. In this chapter, a robust interface with error reporting is built on top of the basic func- tionality. Thus, this illustrates a combined top-down and bottom-up development. Finally, for working over the Internet and for providing a graphical user viii Preface interface, general-purpose B machines for interfacing with HTML and CGI are developed. Part II illustrates refinement for the development of distributed systems and process control systems. These systems are examples of reactive systems. A reactive system is a system which maintains an on-going interaction with its environment. Although reactive systems are outside the original scope of the B Method, the con- nection can be established by the theory of action systems, as presented in the first chapter of Part II. The remaining chapters illustrate this and can be read in any order. Chapter 5: Parallel Programming with the B Method. By appealing to the theory of action systems, this chapter shows how reactive systems and the parallel composition of reactive systems can be expressed with the B Method. It also shows how the refinement of reactive systems leads to proof obligations which can be mapped to those of B machine refinement. Chapter 6: Production Cell. This chapter illustrates an approach for developing a control program for a discrete control system by the example of a production cell consisting of several interacting machines. For such a system, it is shown how safety conditions can be guaranteed. Refinement is used for decomposing a system specification into a controller and a plant. This chapter presents action systems with a large number of actions but simple data structures and basic action system refinement. Chapter 7: Distributed Load Balancing. Load balancing in a network of processes can be conveniently specified by disregarding the distribution, assuming that each process has direct access to the load of neighbouring processes. In an implementation however, nodes must either communicate their load explicitly or keep estimates of each other’s loads. This chapter illustrates the development of such an implementation by a series of refinement steps using superposition refinement, a special form of action system refinement. Chapter 8: Distributed Electronic Mail System. The previous chapters on action systems have taken the view that only the global state of action systems is observable. By contrast, this chapter takes the alternative view that only external events of action systems are observable. The refinement of event-based action systems is illustrated by the development of a mailing system with communi- cation over a network of nodes with links between them. By disregarding the distribution, the specification can be kept concise. In this development, exten- sions of the B notation are proposed for supporting such developments. Smaller B machines are presented with separate explanations, larger B machines are presented with explanations interleaved. For B machines which are longer than just a few pages this literate style relates directly pieces of formal text with the cor- responding explanation and thus improves readability.

Load more