Program Development by Refinement

1. Front Matter

   Pages i-xxiv

   PDF

2. Information Systems

   1. Front Matter

      Pages 1-1

      PDF

   2. Introduction to the B Method

      • Ken A. Robinson

      Pages 3-37

   3. Container Station

      • Elena Troubitsyna

      Pages 39-78

   4. Minimum Spanning Tree

      • Ranan Fraer

      Pages 79-114

   5. The B Bank

      • Martin Büchi

      Pages 115-180

3. Reactive Systems

   1. Front Matter

      Pages 181-181

      PDF

   2. Parallel Programming with the B Method

      • Michael Butler, Marina Waldén

      Pages 183-195

   3. Production Cell

      • Emil Sekerinski

      Pages 197-254

   4. Distributed Load Balancing

      • Marina Waldén

      Pages 255-300

   5. Distributed Electronic Mail System

      • Michael Butler

      Pages 301-322

4. Back Matter

   Pages 323-334

   PDF

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 oflayers, 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.

• Container
• algorithms
• data structures
• design
• development
• distributed systems
• formal specification
• language
• load balancing
• programming

• Department of Computing and Software, McMaster University, Hamilton, Canada

  Emil Sekerinski

• Department of Computer Science, Åbo Akademi University, Turku, Finland

  Kaisa Sere

Policies and ethics