Formal Specification and Documentation Using Z
Total Page：16
File Type：pdf, Size：1020Kb
Formal Specification and Documentation using Z: A Case Study Approach Jonathan Bowen Revised 2003 FORMAL SPECIFICATION AND DOCUMENTATION USING Z X A CASE STUDY APPROACH Jonathan Bowen transputer DCS UNIX documentation All material that serves primarily to describe a system and make it more understandable, rather than to contribute in some way to the actual operation of the system. formal specification 1. A specification written and approved in accordance with established standards. 2. A specification written in a formal notation, such as VDM or Z. Z A formal notation based on set algebra and predicate calculus for the specifica- tion of computing systems. It was developed at the Programming Research Group, Oxford University. Z specifications have a modular structure. Dictionary of Computing [221] CICS and IBM are trademarks of International Business Machines Corporation. DEC, VAX and MicroVAX are trademarks of Digital Equipment Corporation. Inmos and Occam are trademarks of SGS-Thomson Microelectronics. MC68000 is a trademark of Motorola Computer Systems. POSTSCRIPT is a trademark of Adobe, Inc. Sun is a trademark of Sun Microsystems, Inc. UNIX is a registered trademark in the USA and other countries licensed through X/Open Company Ltd. X Window System is a trademark of X Consortium, Inc. To Jane, Alice and Emma Contents Foreword ix Preface xi I Introduction 1 1 Formal Specification using Z 3 1.1 Introduction 3 1.2 Formal Specification 4 1.3 Case Studies 7 1.4 Conclusions 10 2 Industrial Use of Formal Methods 15 2.1 Introduction 15 2.2 Technology Transfer Problems 16 2.3 Industrial-scale Usage 18 2.4 Motivation for Use 20 2.5 Guidelines for Use 22 2.6 Future Developments 26 3 A Brief Introduction to Z 29 3.1 Introduction 29 3.2 Predicate Logic 29 3.3 Sets and Relations 31 3.4 Functions and Toolkit Operators 41 3.5 Numbers and Sequences 44 3.6 Schemas 54 3.7 Conclusion 63 II Network Services 65 4 Documentation using Z 67 4.1 Introduction 67 v vi Contents 4.2 Motivation 68 4.3 Service Specification 69 4.4 Service Documentation 71 4.5 Reservation Service – User Manual 72 4.6 Reservation Service – Implementor Manual 79 4.7 Experience 83 4.8 Conclusions 87 5 A File Storage Service 89 5.1 Service State 89 5.2 Error Reports 92 5.3 Service Operations 94 5.4 Costs and Accounting 102 5.5 Total Operations 103 5.6 Security 103 III UNIX Software 107 6 A Text Formatting Tool 109 6.1 Basic Concepts 109 6.2 Processing the Input 110 6.3 Implementation Details 112 6.4 Files 115 6.5 Conclusion 116 6.6 UNIX Manual Page 117 7 An Event-based Input System 119 7.1 Motivation 119 7.2 Type Definitions 120 7.3 Input Device Events 120 7.4 Abstract State 121 7.5 Changes of State 122 7.6 System Operations 124 7.7 Implementation Notes 131 7.8 Types Revisited 131 IV Instruction Sets 133 8 Machine Words 135 8.1 Word Organization 135 8.2 Operations on Words 137 8.3 Hexadecimal Notation 141 9 The Transputer Instruction Set 143 9.1 Instructions 143 9.2 Machine State 144 9.3 Instructions 149 Contents vii 9.4 Power-up and Bootstrapping 163 9.5 Combined Operations and Instructions 164 9.6 Conclusions 164 V Graphics 167 10 Basic Graphical Concepts 169 10.1 Background 169 10.2 Pixels 169 10.3 Windows 173 11 Raster-Op Functions 175 11.1 Pixel Operations 175 11.2 Display Operations 178 11.3 An Example – Swapping Pixel Maps 179 11.4 Conclusion 180 VI Window Systems 181 12 The ITC ‘WM’ Window Manager 183 12.1 System State 183 12.2 Window Operations 186 12.3 Errors 189 12.4 The ITC Network 190 12.5 Simplifications and Assumptions 192 12.6 Comments 192 13 Blit Windows 195 13.1 System State 195 13.2 System Operations 198 13.3 Errors 201 13.4 Simplifications, Assumptions and Comments 202 14 The X Window System 203 14.1 System State 203 14.2 Window Operations 206 14.3 Errors 212 14.4 Simplifications and Assumptions 213 14.5 Comments and Inconsistencies 214 15 Formal Specification of Existing Systems 215 15.1 Comparison of Window Systems 215 15.2 Case Study Experience 216 15.3 General Conclusions 217 Acknowledgements 219 viii Contents Appendices 221 A Information on Z 223 A.1 Electronic Newsgroup 223 A.2 Electronic Mailing List 223 A.3 Postal Mailing List 224 A.4 Subscribing to the Newsgroup and Mailing List 224 A.5 Electronic Z Archive 224 A.6 Z Tools 225 A.7 Courses on Z 226 A.8 Publications 227 A.9 Object-oriented Z 229 A.10 Executable Z 229 A.11 Meetings 229 A.12 Z User Group 230 A.13 Draft Z Standard 230 A.14 Related Organizations 230 A.15 Comparisons of VDM and Z 231 A.16 Corrections 231 B Z Glossary 233 C Literature Guide 239 C.1 Introduction 239 C.2 Management, Style, and Method 239 C.3 Application Areas 241 C.4 Textbooks on Z 244 C.5 Language Details 244 C.6 Collections of papers 248 C.7 Tools 249 C.8 Object-Oriented Approaches 249 C.9 On-line Information 250 Bibliography 253 Index 285 Foreword The formal methods community has, in writing about the use of discrete mathematics for system specification, committed a number of serious errors. The main one is to concentrate on problems which are too small, for example it has elevated the stack to a level of importance not dreamt of by its inventors. While there is a good reason for using small examples at the beginning of a book or a tutorial, the need becomes progressively less important as one progresses towards teaching students and industrial staff topics such as structuring and modelling. Too many books have given up the fight after presenting small examples and have, I believe, contributed greatly to the lack of take-up of this technology. Staff and students who have read introductory materials on formal methods such as Z and VDM have had their hopes raised by small examples which have given the impression that formal specification is merely the writing down of some simple mathematical statements which define the behaviour of a system. What small examples do is to hide one of the most difficult tasks of specification: the process of selecting an adequate model. Jonathan Bowen is a formal methods researcher who I have a great deal of respect for. Almost all his work has concentrated on the application of this technology to real-life problems – not just stacks and queues. His book teaches through the medium of case studies which are realistic but not too large that they overwhelm the reader. They range from the specification of the Transputer instruction set to that of a tool for formatting free text. All the case studies contain excellent examples of the power of Z: its ability to structure large specifications into chunks which can be read, validated and developed in relative isolation. The formal methods community still have a long way to go in convincing many industrialists of the power of discrete mathematics; I would regard this book as a major contribution to doing so. Darrel Ince The Open University ix Preface 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 en- sure 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, us- ing 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.