CASE STUDIES IN SYSTEMATIC SOFTWARE DEVELOPMENT CASE STUDIES IN SYSTEMATIC SOFTWARE DEVELOPMENT Edited by CLIFF B JONES Department of Computer Science, Manchester University and ROGER C F SHAW Praxis Systems plc. c Prentice/Hall International Contents v vi Contents Foreword VDM is currently the most widely spread method for the systematic, via rigorous, to formal development of software, from programs to programming systems. Background VDM, as first conceived, around 1973–1975, at the IBM Vienna Laboratory , derived its foundational and methodological constituents from many academic sources: notably from the works of, and inspired by such researchers as, Jaco de Bakker, Rod Burstall, Tony Hoare, Peter Landin, John McCarthy, Robin Milner, John Reynolds, Dana Scott, Christopher Strachey, and many others. The inspirational background offered here was cast into a whole to form ‘classical’ VDM by the Viennese industrial researchers (the late) Hans Beki´c, and Wolfgang Henhapl, Peter Lucas, Cliff Jones and myself. Three VDM R&D phases – and two schools Since VDM research and development left Vienna, around 1975–1976, a number of in- dependent, mostly compatible directions have been pursued. Roughly three phases of VDM R&D can be identified: (1) the ‘classical’ Vienna VDM (1973–1978) – as mani- fested for example in the book: The Vienna Development Method – the Meta-Language published in 1978 by Springer Verlag as its 61st Lecture Notes in Computer Science volume (LNCS61), and Formal Specification and Software Development mostly by Cliff Jones and myself (Prentice Hall International (PH), 1982); (2) the parallel, complement- ing VDM as witnessed by the books: Software Development – a Rigorous Approach (SDRA) by Cliff Jones (PH), 1980, Towards a Formal Description of Ada (Springer Verlag, LNCS98), and Systematic Software Development using VDM (SSD/VDM) by Cliff Jones (PH, 1986); and the more independent, not always fully compatible lines of VDM R&D as witnessed by the book MetaSoft Primer by Andrzej Blikle (Springer Ver- lag, LNCS288, 1987), and by the article ‘The RAISE Language, Method and Tools’, by Mogens Nielsen et al., and appearing in Springer Verlag’s new journal: Formal Aspects vii viii Foreword of Computing, Vol. 1, No. 1, 1989. Phase 2 can be characterized as composed of a Danish (LNCS98) and an English (SDRA and SSD/VDM) ‘school’. The difference in emphasis between the two schools is really superficial: styles of notation differ, modes of defining functions and opera- tions either mostly directly, and mostly applicatively (the Danish school), or (the English school) by means of pre-/post-conditions, and, for operations, on a slightly different im- perial state notion. – a unification The British Standards Institute’s current VDM standardization effort is successfully amalgamating these two schools. The present book follows this consolidation. Whereas phase 3 work may be called post-VDM, and whereas it is too early to speak of this work’s wide acceptance, the present book offers material that can be readily adapted in any mature industrial environment. The present book For widespread acceptance of formal methods in industry, realistic case studies, carefully documented, must be presented. The various case examples presented here ought to convince most dogmatic ‘anti-formalists’ that VDM is a sound, industry-ready method for developing large scale, primarily sequential, deterministic software – software that can be trusted. Although VDM was first conceived while developing a compiler for PL/I, it is re- freshing to see its wider use in such diverse areas as databases (Chapters 2–3), proof systems (Chapter 4), explaining and implementing the crucial, ‘originally’ logic pro- gramming notion of unification (Chapters 5–6), storage management, whether in an op- erating system, a database management system or a program’s run-time system (Chap- ters 7–8), non von Neumann computer architectures (Chapter 11), user interface systems (Chapter 12), or graphics (Chapter 13). Of course, a classical programming language definition must be given (Chapter 9) – and that chapter may be a good starting point for students, but a semantic analysis, in the form of a definition, of what constitutes ‘object-orientedness’ in programming languages is also presented (Chapter 10). A warning, and a promise It is my sincere belief, one which has been tempered by many years of sad industrial experience, that the present, large software houses may easily become extinct if they do not provide a means – for the hundreds of young candidates that graduate yearly – Foreword ix to pursue software development in the only exciting and professionally responsible way it should be developed – namely formally. Young, upstart, companies which offer this opportunity to the recent academically trained software engineers and programmers will attract the coming (large) generations. An old generation clings to such ‘dogmatisms’ as: (1) formal definitions are unreadable , (2) it is hard to prove programs correct , (3) the technology is not available. This book proves otherwise: (1) the definitions are easy to read – and one should only entrust serious software development to professionals anyway; (2) it is not that hard to reason about correctness – and who would want incorrect software if it could be correct?; and (3) the technology, VDM, has been here for quite a while – it is industry’s task to develop industry-scale tools. Industry no longer has any excuse not to put the results of academic research into daily practice. This volume certainly proves that academic research is industrially useful. To specify formally, and to formally develop software, is to create insight into, and theories about, otherwise complex systems. This book, with its balanced examples proves that point: it is refreshingly relaxing to develop beautiful software embodying elegant theories formally – and VDM is presently the strongest contender! Dines Bjørner Holte, 25 September 1989 x Foreword Preface Although young by the standards of most engineering disciplines, software development tackles tasks of enormous complexity. In seeking a systematic approach to control this complexity, the software industry is recognizing the need for a variety of new practices. High on their list is an acceptance that ‘formal methods’ are necessary if large systems are to be developed to higher standards than currently prevail. Formal methods is a term which is used to cover both the use of mathematical notation in the functional specifica- tions of systems and the use of justifications which relate designs to their specifications. One of the most widely known and used formal methods is called the ‘Vienna Develop- ment Method’ (more often referred to as ‘VDM’). VDM was developed in an industrial environment but has also evoked considerable academic research. VDM provides both a specification notation and proof obligations which enable a designer to establish the correctness of steps of design. It is a development method in the sense that it offers notation and framework for recording and justifying specifica- tions and design steps. VDM does not, however, claim to be a normative method in the sense that it results in the choice of a standard or best design: the designer provides the insight. Chapter 1 discusses how VDM concepts fit into the broader subject of ‘software engineering’. VDM grew out of earlier research but became a coherent whole in the mid 1970s. Since then it has been developed and discussed in a literally hundreds of publications. A clear sign of its maturity for industrial use is the availability of a variety of textbooks which set out to teach the use of both the specification and design justification parts of the method. Furthermore, courses are available from commercial organizations and two international conferences (organized by the European Community, ‘VDM-Europe’ group) have been dedicated to VDM. It is the experience of the authors and editors of the current volume (amongst many other people) that methods like VDM enable them to describe major computer sys- tems. Such experience is difficult to convey in a book and a textbook on a method such as [Jon90] is certainly an inadequate medium. Although the examples in this vol- ume are not large by industrial standards, they should provide a much clearer indication of how to tackle major systems than is possible in any book whose main task is teaching xi xii Preface the method from scratch. It has long been obvious that there is a significant need for such material: both of the editors have taught courses where the step from the textbook examples to an industry-sized specification has to be bridged by some sort of case study. Much case study material has – in fact – been available in the literature. Unfortu- nately, the papers are not always easily located and the notation (often because of such mundane issues as printing devices) varies from one publication to the next. Experi- ence of teaching VDM to industrial audiences constantly reminds one of the importance of a uniform style of presentation, at least during the early stages of the learning pro- cess. While researchers often show a cavalier disdain for issues of syntax, more practi- cally oriented people tend to get confused when presented with a variety of notation. In fact, some industrial organizations cite the absence of a stable language (along with the paucity of tools) as a major reason for their reluctance to embrace formal methods. The work of the British Standards Institution (BSI) group BSI IST/5/50 has pro- gressed to the point that an outline standard is now available for comment. This presents a timely opportunity to publish a collection of VDM material in a coherent notation which should achieve wide acceptance. There is also evidence that this stability is stimulating tool builders. A second edition of Systematic Software Development using VDM [Jon90] has been prepared using the draft BSI standard notation and the current volume adopts the same language. The case studies illustrate all facets of VDM. Some confine themselves to speci- fications often providing insight as to why the particular specification was developed. Other examples cover design by data reification 1 or operation decomposition. In many chapters proofs are only sketched but some very detailed proofs are also presented. Ten authors have contributed a total of twelve case studies (Chapters 2–13). The authors come from backgrounds as varied as their material and – beyond conformity to the specification notation itself – the editors have not tried to force the material into a particular mould. In fact the editors could echo George Bernard Shaw’s comment in the preface to Essays on Socialism that ‘there has been no sacrifice of individuality’. There are several positive reasons for this. Before tackling larger specifications the reader must become aware that there is often no ‘right’ specification. Furthermore, seeing a range of styles will help the readers focus on what they wish to develop as their own approach. The size of the chosen case studies is such that they illustrate many of the points made in [Jon90] better than was possible there. This is particularly the case with the exhortation to use more formal approaches in the early stages of design. Another major point which should become clear is the importance of providing a design record. Most readers will probably begin their study of the material with application areas with which 1 The term reification is preferred to the more widely-used word ‘refinement’. Michael Jackson pointed out to the author that the latter term is hardly appropriate for the step from a clean mathematical abstraction to a messy representation dictated by a particular machine architecture. The Concise Oxford Dictionary defines the verb ‘reify’ as ‘convert (person, abstract concept) into thing, materialize’. [...]... to perceive the use of formal models in experimenting with alternative architectures Apart from the case studies themselves, an appendix covers the notation used In part, this is just a summary of the language; but it also discusses those aspects which are needed in some case studies but are not covered in [Jon90] (e.g Lambda expressions) A reader who encounters anything unfamiliar should consult Appendix... REVIEWS PIR PSR PDR DDR Product initiation review Product specification review Product design review Detailed design review IR INR PSUDR PAR Implementation review Integration review Product support and documentation review Product acceptance review SSPR Sales/Support periodic review Figure 1.1 A software development life cycle model 4 1 Introduction – Formal Methods and Software Engineering 1.3 The contractual... paradigm and see how it relates to the conventional phase model view of software development A formal method has three essential characteristics 1 Formal systems The use of formal systems, that is, formal languages with well defined syntax, semantics and proof systems Thus, in the case of VDM, Jones describes, informally, a formal system for the specification of software systems [Jon90] This includes a logic... Requirementsn 5 Specificationn 1 Rework within phase or previous phases failed failed ok ok Verification Requirementsn Validation 1 Figure 1.2 Phase verification and validation (SP0 ) using a formal specification language In the case of VDM the abstract specification takes the form of a model of the intended problem that characterizes what is required; it eschews, as far as possible, issues to do with how the requirements... composes specifications SP31 and SP32 Here we would need to show that SP31 SP32 satisfies SP21 and that SP21 SP22 satisfies SP1 Various composition operators are possible and depend on the particular formal language being used Conceptually, reification and decomposition allow us to develop detailed implementation level specifications from our abstract specifications However, life is not quite so straightforward... Additionally, when specifications are decomposed into components, compositional proof obligations are required to show that specifications are satisfied when their components are brought together Finally, the language itself yields proof obligations relating to type compatibility and the well formed definition of expressions Some of these can be checked by tools (type checkers) while others appear in the form... formal methods? 1 Formal methods provide precise notations for capturing functional specification decisions be they abstract characterizations of the requirements or implementation specific A specification language is used for this purpose suggested by other authors [MRG88, HHS87, Nip86]: these should be investigated 1.5 What do we mean by method? 9 2 The notion of abstraction is essential to the application... methods and tools appropriate to these activities must be sought elsewhere In fact, as suggested below, formal methods can quite easily be added to development methods that lack a formal specification language and formal development framework The method side of formal methods may be viewed as the use of formal systems, the use of abstraction and reification and the generation and discharging of specific . systems (Chapter 12), or graphics (Chapter 13). Of course, a classical programming language definition must be given (Chapter 9) – and that chapter may be. the form of a definition, of what constitutes ‘object-orientedness’ in programming languages is also presented (Chapter 10). A warning, and a promise It