Formal specification and implementation

  • C. T. Sennett
Part of the Software Science and Engineering book series (SSEN)


The production of high-integrity software is a matter of engineering. Bridges, buildings, cars, television sets, and well engineered artefacts generally, are all produced to quantifiable standards of reliability. It is possible to step into a lift, for example, with no qualms about its safety simply because the engineering requirements for its production are both well understood and enforced by society. To achieve a similar state of affairs in software engineering requires a similar discipline but absolutely fundamental to any engineering discipline must be its scientific basis and the mathematical tools and techniques which support it. The safety of a bridge depends critically on an ability to calculate stresses and decide on the strength of materials and, indeed, the whole basis of engineering is dependent on the ability to calculate performance and build a product to quantifiable standards. By these criteria software is poorly engineered: all too often the performance and reliability is assessed by building the product and patching deficiencies as they occur, so for high-integrity software the science behind software engineering must be both understood and practised. Broadly speaking, formal methods may be equated with this scientific basis. Professional software engineers should have a thorough understanding of the subject, and production methods for high-integrity software should be marked by extensive use of mathematical tools based on this science.


Formal Method Theorem Prove Specification Language Expressive Power Proof Obligation 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. [Dijkstra 1976]
    Dijkstra E. W., A Discipline of Programming, Prentice Hall (1976).Google Scholar
  2. [Core 1987]
    Core P. W., User-extensible Graphics Using Abstract Structure, RSRE report 87011 (1987).Google Scholar
  3. [Gries 1981]
    Gries D., The Science of Programming, Springer (1981).Google Scholar
  4. [Hayes 1987]
    Hayes I., Specification Case Studies, Prentice Hall (1987).Google Scholar
  5. [Jones 1986]
    Jones, C. B., Systematic Software Development Using VDM, Prentice Hall (1986).Google Scholar
  6. [King 1987]
    King S, Sorensen I. H., Woodcock J., Z: Grammar and Concrete and Abstract Syntaxes, Programming Research Group, University of Oxford (1987).Google Scholar
  7. [Morgan/Robinson 1987]
    Morgan C. C., Robinson K. A., “Specification statements and refinement”, IBM Journal of Research and Development, 31, 5 (1987).MathSciNetCrossRefGoogle Scholar
  8. [Morgan 1988]
    Morgan C. C., The specification statement (private communication, to appear in TOPLAS).Google Scholar
  9. [Scott 1976]
    Scott, D. S. “Data types as lattice”, SIAM Journal of Computing, 5, pp. 522–587 (1976).MATHCrossRefGoogle Scholar
  10. [Sennett 1987]
    Sennett, C. T., Review of the Type Checking and Scope Rules of the Specification Language Z, RSRE report 87017 (1987).Google Scholar
  11. [Spivey 1988]
    Spivey, J. M., Understanding Z: a Specification Language and its Formal Semantics, Cambridge University Press (1988).Google Scholar
  12. [Stoy 1977]
    Stoy, J. E., Denotational Semantics: the Scott-Strachey Approach to Programming Language Theory, MIT Press (1977).Google Scholar
  13. [Sufrin 1983]
    Sufrin, B., “Formal system specification: notation and examples”, in Tools and Notations for Program Construction (Ed. Neel), Cambridge University Press (1983).Google Scholar

Copyright information

© Crown Copyright 1989

Authors and Affiliations

  • C. T. Sennett
    • 1
  1. 1.Royal Signals and Radar EstablishmentUK

Personalised recommendations