The Gypsy verification environment is a large computer program that supports the development of software systems and formal, mathematical proofs about their behavior. The environment provides conventional development tools, such as a parser for the Gypsy language, an editor and a compiler. These are used to evolve a library of components that define both the software and precise specifications about its desired behavior. The environment also has a verification condition generator that automatically transforms a software component and its specification into logical formulas which are sufficient to prove that the component always runs according to specification. Facilities for constructing formal, mechanical proofs of these formulas also are provided. Many of these proofs are completed automatically without human intervention. The capabilities of the Gypsy system and the results of its applications are discussed.

Abstract not found

Many approaches to programming emphasize the use of interfaces. The basic idea is to decompose programs into modules and to specify how each module's interface behaves. This makes it easier to reason about programs because one can rely on a module's speci#cation rather than examining its implementation, which is more complicated.

Computer programs may be regarded as formal mathematical objects whose properties are subject to mathematical proof. Program verification is the use of formal, mathematical techniques to debug software and software specifications. 1. Code Verification How are the properties of computer programs proved? We discuss three approaches in this article: inductive invariants, functional semantics, and explicit semantics. Because the first approach has received by far the most attention, it has produced the most impressive results to date. However, the field is now moving away from the inductive invariant approach. 1.1. Inductive Assertions The so-called Floyd-Hoare inductive assertion method of program verification [25, 33] has its roots in the classic Goldstine and von Neumann reports [53] and handles the usual kind of programming language, of which FORTRAN is perhaps the best example. In this style of verification, the specifier "annotates " certain points in the program with mathematical assertions that are supposed to describe relations that hold between the program variables and the initial input values each time "control " reaches the annotated point. Among these assertions are some that characterize acceptable input and the desired output. By exploring all possible paths from one assertion to the next and analyzing the effects of intervening program statements it is possible to reduce the correctness of the program to the problem of proving certain derived formulas called verification conditions. Below we illustrate the idea with a simple program for computing the factorial of its integer input N flowchart assertion start with input(N) input N A: = 1 N = 0 yes stop with? answer A

Managing tradeoffs between program structure and program efficiency is one of the most difficult problems facing software engineers. Decomposing programs into abstractions simplifies the construction and maintenance of software and results in fewer errors. However, the introduction of these abstractions often introduces significant inefficiencies. This paper describes a strategy for eliminating many of these inefficiencies. It is based upon providing alternative implementations of the same abstraction, and using information contained in formal specifications to allow a compiler to choose the appropriate one. The strategy has been implemented in a prototype compiler that incorporates theorem proving technology. Keywords: Program Modularity, Software Interfaces, Formal Specifications, Compilers, Program Optimization. 1 INTRODUCTION Many approaches to programming emphasize the use of specifications of interfaces. The basic idea is to achieve a separation of concerns. The client of an ...

ix 1 Survivability and the System Life Cycle ........................................................1 2 Survivability Concepts ....................................................................................3 2.1 The New Network Paradigm: Organizational Integration ...........................3 2.2 The Definition of Survivability ....................................................................4 2.3 Characteristics of Survivable Systems.......................................................5 2.4 Survivability as an Integrated Engineering Framework ..............................9 3 System Development Life-Cycle Models ..................................................... 11 3.1 The Spiral Model ..................................................................................... 11 3.2 A Spiral Model for Survivable Systems Development...............................13 4 System Development Life-Cycle Activities and Survivability.....................17 4.1 Requirements and Specification ..............................................................17 4.1.1 Expressing Survivability Requirements ........................................18 4.1.2 Requirements Definition for Essential Services............................22 4.1.3 Requirements Definition for Survivability Services .......................23 4.2 Architecture and Design ..........................................................................26 4.3 Implementation and Verification...............................................................29 4.3.1 Defensive Coding Strategies........................................................29 4.3.2 Correctness Verification .................................