Book contents
- Frontmatter
- Contents
- Preface
- Part I Theory
- Part II Applications
- 11 Reynolds' Method
- 12 VDM
- 13 Z, Hehner's Method, and Back's Refinement Calculus
- 14 Refinement Methods due to Abadi and Lamport and to Lynch
- Appendix A An Introduction to Hoare Logic
- Appendix B A Primer on Ordinals and Transfinite Induction
- Appendix C Notational Convention
- Appendix D Precedences
- Bibliography
- Index
12 - VDM
Published online by Cambridge University Press: 03 May 2010
- Frontmatter
- Contents
- Preface
- Part I Theory
- Part II Applications
- 11 Reynolds' Method
- 12 VDM
- 13 Z, Hehner's Method, and Back's Refinement Calculus
- 14 Refinement Methods due to Abadi and Lamport and to Lynch
- Appendix A An Introduction to Hoare Logic
- Appendix B A Primer on Ordinals and Transfinite Induction
- Appendix C Notational Convention
- Appendix D Precedences
- Bibliography
- Index
Summary
Introduction
In the glossary of terms in his book [J90] Cliff Jones explains the origin of the name Vienna Development Method.
VDM is the name given to a collection of notation and concepts which grew out of the work of the IBM Laboratory, Vienna. The original application was the denotational description of programming languages. The same specification technique has been applied to many other systems. Design rules which show how to prove that a design satisfies its specification have been developed. [J90, p. 294]
Of the techniques mentioned above, Bicarregui et al [BFL+94] stress three as the main ones: the specification language VDM-SL, data refinement techniques, and operation decomposition techniques, where the latter term refers to refinement as opposed to data refinement, for instance, the implementation of a specification statement by a loop.
One keyword in the quote above is ‘rule’. Nowadays the first impression a student might get when learning and practising VDM is that of a huge collection of rules to guide writing specifications. Indeed, specifying with VDM mostly comprises two activities carried out together:
writing specifications of, e.g., types, functions, and operations in the specification language and
discarding proof obligations — preferably by formal proof — that ensure, for instance, that a type1 is nonempty, a function specification is well-formed, a specification of an operation is satisfiable, or a specification is implemented by an operation.
Of course, we focus in this monograph on the proof obligations that arise in the process of data refinement.
- Type
- Chapter
- Information
- Data RefinementModel-Oriented Proof Methods and their Comparison, pp. 289 - 316Publisher: Cambridge University PressPrint publication year: 1998