This paper is a survey of the current state of the art of research on methods for formal software development. The scope of this paper is necessarily restricted so as to avoid discussion of a great many approaches at a very superficial level. First, although some of the ideas discussed below could be (and have been) applied to hardware development as well as to software development, this topic will not be treated here. Second, the special problems involved in the development of concurrent systems will not be discussed here although again many of the approaches mentioned below could be applied in this context. Third, no attempt is made to treat programming methodologies such as Jackson's method and program development systems such as the MIT Programmer's Apprentice which are not formally based. Finally, this survey does not claim to be fully exhaustive although an attempt has been made to cover most of the main approaches. Many of the technical details of the different approaches discussed have been glossed over or simplified for the purposes of this presentation; full details may be found in the cited references.

ions are defined both for objects and layers. There are several compatibility requirements for the definition of these functions. The set of objects contains a specific ?-element which allows the source and target functions to be total on the set of objects. Up to now there exists no implementation of general colimits in the AGG-system. This problem is currently fixed by the integration of the colimit library. Again we can use the colimit computation for Alpha algebras. For this purpose we have to find an Alpha representation of AGG-graphs. Here we will outline the idea. r0 r1 r2 object layer label v0 r4 r0 Item Data The picture above presents a possible Alpha type algebra for AGG-graphs. r 0 ; r 1 and r 2 correspond to the abstraction, source and target functions, r 4 represents the assignment of layers to objects and v 0 is the labelling function. Note that although not shown in the picture, since all references are total, r 1 ; r 2 and r 3 are defined also for layer. This shows ...

This paper primarily reports on semantic aspects of how a formal specification of the PCTE interfaces has been achieved in a situation where only a combination of existing formalisms could meet the needs. The motivations for combining a VDM specification language with a language of temporal logic, for translating the resulting language, called VVSL, to an extended COLD-K and for translating it also (partially) to the language of the logic MPL! are briefly outlined. The main experiences from this work on combination and transformation of formalisms are presented. Some important experiences with the application of VVSL to the formal specification of the PCTE interfaces and otherwise are also mentioned. Keywords & Phrases: formal specification languages, model-oriented specification, pre- and post-conditions, inter-conditions, temporal logic, transformational semantics, logical semantics. 1987 CR Categories: D.2.1, D.2.2, D.3.1, F.3.1, F.3.2, F.4.1 1 Introduction A large software syst...

This document provides a comparative study of the different alternatives for the executable (sequential) specification language which must be selected for the IPTES mini-specifications. This investigation will be focussed on notations from existing model-oriented methods where appropriate subsets can be extracted. However, existing executable languages inspired from such model-oriented methods also form a basis for this investigation. An Investigation of Executable Specification Languages for the IPTES Mini-: : : Contents 1 Introduction 2 2 Background about the VDM history 2 3 An overview of the considered notations 3 3.1 BSI/VDM-SL : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3 3.2 VIP VDM SL : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 3.3 RAISE SL : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 3.4 Me too : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6 3.5 EPROL : : : : : : : : : : : : : : : : : : : : : : : : : : ...

Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.5.4 Special Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.6 Semantics of Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6.1 Semantics of Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6.2 Action Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.7 Specification Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.1 Early Algebraic Specification Languages . . . . . . . . . . . . . . . . . . . . . . . . 53 4.7.2 Recent Algebraic Specification Languages . . . . . . . . . . . . . . . . . . . . . . . 55 4.7.3 The Common Framework Initiative. . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5 Methodology 57 5.1 Development Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1.1 Applica...

he component has not to be done several times by numerous readers. Moreover, if we want to rigorously treat the question of software correctness, it is necessary to associate a rigorous semantics (mathematically defined) to each statement (i.e., to the syntax) of a specification. Formal specifications define unambiguously what the correctness of a program signifies and they are indeed the only way to have a rigorous definition of correctness. Consequently, formal specifications must be used if we want to consider "entirely proved programs, " "zero-default softwares," etc. From a logical point of view, the notion of correctness of a program, without a formal specification of it, is a non-sense. Slogan: To prove a theorem, it must be rigorously stated. To reach software correctness, it must be formally specified. Indeed, the fact that formal specifications are the only way to rigorously define software correctnes

A formalisation of this programming methodology depends on some precise notion of the implementation of a specification by a lower-level specification. Previous notions have been given for the implementation of non-parameterised ([GTW 78], [Nou 79], [Hup 80], [EKP 80], [Ehr 82]) and parameterised ([Gan 81], [Hup 81])*~ specifications, but none of these approaches deals fully with 'structured ' algebraic specifications (as in Clear [BG 77] or CIP-L [Bau 81]) which may be constructed in a hierarchical fashion and may be loose (with an assortment of non-isomorphic models). We present a definition of implementation which agrees with our intuitive notions built upon programming experience and which handles such loose hierarchical specifications, based on a new (and seemingly fundamental) concept of the simulation of a theory by an algebra. We show how this definition extends to give a definition of the implementation of parameterised specifications. An example of an implementation is given and several other examples are sketched. We work within the framework of the Clear specification language [BG 77] which allows large specifications to be built from small easy-to-understand bits. For most