Formal methods are becoming more accepted in both academia and industry as one possible way in which to help improve the quality of both software and hardware systems. It should be remembered however that they are not a panacea, but... more
Formal methods are becoming more accepted in both academia and industry as one possible way in which to help improve the quality of both software and hardware systems. It should be remembered however that they are not a panacea, but rather one
more weapon in the armoury against making design mistakes. To quote from Prof. Tony Hoare:
"Of course, there is no fool-proof methodology or magic formula that will ensure a good, efficient, or even feasible design. For that, the designer needs experience, insight, flair, judgement, invention. Formal methods can only stimulate, guide, and
discipline our human inspiration, clarify design alternatives, assist in exploring their consequences, formalize and communicate design decisions, and help to ensure that they are correctly carried out." - C.A.R. Hoare, 1988
Thus we should not expect too much from formal methods, but rather use them to advantage where appropriate.
Even within the formal methods community, there are many camps: for example, those that believe that a formally correct system must be proved correct mechanically, one small step at a time, and those who use the term formal to mean mathematical, using high-level pencil-and-paper style proofs to verify a design is ‘correct’ with respect to its specification. Sometimes the latter method is known as ‘rigorous’ to differentiate it from the former; and of course there are positions between these two extremes.
Even if a system is proved correct, there are still many assumptions which may be invalid. The specification must be ‘obviously right.’ There is no way that this can be formally verified to be what is wanted. It must be simple enough to be understandable and should be acceptable to both the designer and the customer.
This book presents an even more pragmatic view of the use of formal methods than that held by some academics: that is that formal specification alone can still be beneficial (and is much more cost effective in general) than attempting proofs in many cases. While the cost of proving a system correct may be justified in safety-critical systems where lives are at risk, many systems are less critical, but could still benefit from formalization earlier on in the design process than is normally the case in much industrial practice.
Ultimately the computer system will be communicating with the outside world. In a control system, we will probably be dealing with physical laws, continuous mathematics (e.g., differential equations), etc. This will have to be converted into digital values and approximations will have to be made. In many cases, a Human-Computer Interface will be involved. Great engineering skill will be needed to ensure that any assumptions made are correct and will not invalidate any formally verified design. It is very important to apportion responsibility between the engineers associated with each design task. Mutually agreed interfaces must be drawn up. Ideally these should be formalized to reduce the risk of ambiguity and misunderstanding on each side of the interfaces.
This book presents the use of one notation in the accumulation of available mathematical techniques to help ensure the correctness of computer-based systems, namely the Z notation (pronounced ‘zed’), intended for the specification of such systems. The formal notation Z is based on set theory and predicate calculus, and has been developed at the Oxford University Computing Laboratory since the late 1970’s.
The use of a formal notation early on in the design process helps to remove many errors that would not otherwise be discovered until a later stage. The book includes specification of a number of digital systems in a variety of areas to help demonstrate the scope of the notation. Most of the specifications are of real systems that have been built, either commercially or experimentally. It is hoped that the variety of examples in this book will encourage more developers to attempt to specify their systems in a more formal manner before they attempt the development or programming stage.
In Part I, the first two chapters give an introduction to formal specification, using Z in particular, and also to the issues concerning the practical take-up and use of formal methods in industry. Chapter 2 gives an overview of some industrial issues, for those contemplating the use of formal methods as part of the software development process. Some guidelines to help with successful use are given. Finally a brief tutorial is given in Chapter 3, which introduces Z for those who have not seen the notation before, but who wish to tackle the rest of the book. However, it should be noted that this is not a substitute for a fuller treatment, which if required should be sought from one of the numerous Z textbooks now available.
Z has been designed to be read by (suitably trained) humans, rather than by computers, and as such may be included in manuals documenting computer-based systems. Part II gives some examples, using network services designed and built at Oxford University. Two types of manual have been developed, one of the user of a service, giving an idealized external abstract view, and one for potential implementors, giving more details of the suggested internal structure of the service.
In Part III, Chapter 6 details the specification of a text formatting tool designed for using under the UNIX operating system. The structure of UNIX files is discussed in this context. A specification of a mouse-based input system for UNIX workstations is also presented in Chapter 7.
Although Z has mainly been applied to software systems, it is also applicable to hardware. In Part IV, a number of aspects important in the specification of machine instruction sets are discussed. Chapter 8 formally defines some concepts which are useful in the specification of any microprocessor. Building of this, a part of a specific instruction set, namely that of the Transputer, is then presented in Chapter 9.
Part V details some graphical concepts. Chapter 10 introduces general concepts useful for specifying pixel maps and window systems. Chapter 11 defines the rasterop function which is fundamental to many graphics operations.
Window systems are now one of the most popular interfaces for computers. Part VI builds on the ideas presented in Part V and gives details of three window systems, including the highly successful XWindow System. Chapter 15 remarks on experience
gained by formally specifying the three window systems and other case studies.
Appendix A gives some indications on how to obtain further up-to-date information on Z. A glossary of the Z notation may be found in Appendix B. A literature guide in Appendix C together with a substantial bibliography at the end of the book are included to allow readers to follow up on another aspect of Z and formal methods that are of special interest. Finally an index, particularly of names of definitions in the specifications presented in the book, will aid the reader in navigating the text, especially the formal parts.
It is hoped that the specifications presented here will help students and industrial practitioners alike to produce better specifications of their designs, be they large or small. Even if no proofs or refinement of a system are attempted, mere formalization early on in the design process will help to clarify a designer’s thoughts (especially when undertaken as part of a team) and remove many errors before they become implemented,
and therefore much more difficult and expensive to rectify.
For further on-line information related to this book, held as part of the distributed World Wide Web (WWW) Virtual Library, the reader is referred to the following URL
(Uniform Resource Locator):
http://http://formalmethods.wikia.com/zbook
J.P.B.
June 1995
more weapon in the armoury against making design mistakes. To quote from Prof. Tony Hoare:
"Of course, there is no fool-proof methodology or magic formula that will ensure a good, efficient, or even feasible design. For that, the designer needs experience, insight, flair, judgement, invention. Formal methods can only stimulate, guide, and
discipline our human inspiration, clarify design alternatives, assist in exploring their consequences, formalize and communicate design decisions, and help to ensure that they are correctly carried out." - C.A.R. Hoare, 1988
Thus we should not expect too much from formal methods, but rather use them to advantage where appropriate.
Even within the formal methods community, there are many camps: for example, those that believe that a formally correct system must be proved correct mechanically, one small step at a time, and those who use the term formal to mean mathematical, using high-level pencil-and-paper style proofs to verify a design is ‘correct’ with respect to its specification. Sometimes the latter method is known as ‘rigorous’ to differentiate it from the former; and of course there are positions between these two extremes.
Even if a system is proved correct, there are still many assumptions which may be invalid. The specification must be ‘obviously right.’ There is no way that this can be formally verified to be what is wanted. It must be simple enough to be understandable and should be acceptable to both the designer and the customer.
This book presents an even more pragmatic view of the use of formal methods than that held by some academics: that is that formal specification alone can still be beneficial (and is much more cost effective in general) than attempting proofs in many cases. While the cost of proving a system correct may be justified in safety-critical systems where lives are at risk, many systems are less critical, but could still benefit from formalization earlier on in the design process than is normally the case in much industrial practice.
Ultimately the computer system will be communicating with the outside world. In a control system, we will probably be dealing with physical laws, continuous mathematics (e.g., differential equations), etc. This will have to be converted into digital values and approximations will have to be made. In many cases, a Human-Computer Interface will be involved. Great engineering skill will be needed to ensure that any assumptions made are correct and will not invalidate any formally verified design. It is very important to apportion responsibility between the engineers associated with each design task. Mutually agreed interfaces must be drawn up. Ideally these should be formalized to reduce the risk of ambiguity and misunderstanding on each side of the interfaces.
This book presents the use of one notation in the accumulation of available mathematical techniques to help ensure the correctness of computer-based systems, namely the Z notation (pronounced ‘zed’), intended for the specification of such systems. The formal notation Z is based on set theory and predicate calculus, and has been developed at the Oxford University Computing Laboratory since the late 1970’s.
The use of a formal notation early on in the design process helps to remove many errors that would not otherwise be discovered until a later stage. The book includes specification of a number of digital systems in a variety of areas to help demonstrate the scope of the notation. Most of the specifications are of real systems that have been built, either commercially or experimentally. It is hoped that the variety of examples in this book will encourage more developers to attempt to specify their systems in a more formal manner before they attempt the development or programming stage.
In Part I, the first two chapters give an introduction to formal specification, using Z in particular, and also to the issues concerning the practical take-up and use of formal methods in industry. Chapter 2 gives an overview of some industrial issues, for those contemplating the use of formal methods as part of the software development process. Some guidelines to help with successful use are given. Finally a brief tutorial is given in Chapter 3, which introduces Z for those who have not seen the notation before, but who wish to tackle the rest of the book. However, it should be noted that this is not a substitute for a fuller treatment, which if required should be sought from one of the numerous Z textbooks now available.
Z has been designed to be read by (suitably trained) humans, rather than by computers, and as such may be included in manuals documenting computer-based systems. Part II gives some examples, using network services designed and built at Oxford University. Two types of manual have been developed, one of the user of a service, giving an idealized external abstract view, and one for potential implementors, giving more details of the suggested internal structure of the service.
In Part III, Chapter 6 details the specification of a text formatting tool designed for using under the UNIX operating system. The structure of UNIX files is discussed in this context. A specification of a mouse-based input system for UNIX workstations is also presented in Chapter 7.
Although Z has mainly been applied to software systems, it is also applicable to hardware. In Part IV, a number of aspects important in the specification of machine instruction sets are discussed. Chapter 8 formally defines some concepts which are useful in the specification of any microprocessor. Building of this, a part of a specific instruction set, namely that of the Transputer, is then presented in Chapter 9.
Part V details some graphical concepts. Chapter 10 introduces general concepts useful for specifying pixel maps and window systems. Chapter 11 defines the rasterop function which is fundamental to many graphics operations.
Window systems are now one of the most popular interfaces for computers. Part VI builds on the ideas presented in Part V and gives details of three window systems, including the highly successful XWindow System. Chapter 15 remarks on experience
gained by formally specifying the three window systems and other case studies.
Appendix A gives some indications on how to obtain further up-to-date information on Z. A glossary of the Z notation may be found in Appendix B. A literature guide in Appendix C together with a substantial bibliography at the end of the book are included to allow readers to follow up on another aspect of Z and formal methods that are of special interest. Finally an index, particularly of names of definitions in the specifications presented in the book, will aid the reader in navigating the text, especially the formal parts.
It is hoped that the specifications presented here will help students and industrial practitioners alike to produce better specifications of their designs, be they large or small. Even if no proofs or refinement of a system are attempted, mere formalization early on in the design process will help to clarify a designer’s thoughts (especially when undertaken as part of a team) and remove many errors before they become implemented,
and therefore much more difficult and expensive to rectify.
For further on-line information related to this book, held as part of the distributed World Wide Web (WWW) Virtual Library, the reader is referred to the following URL
(Uniform Resource Locator):
http://http://formalmethods.wikia.com/zbook
J.P.B.
June 1995
