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

This thesis investigates a particular approach, called state-transition specification, to the problem of describing the behavior of modules in a distributed or concurrent computer ,stem. A state-transition specification consists off (1) a state machine, which incorporates the safety or invariance properties of the module, and (2) validity conditions on the computations of the machine, which'capture the desired liveness or eventu;lity properties. The theory and techniques of state. transition specification are developed'from first principles to a point at which it is possible to write example sPeCificatiOns,'to check-the Specifications for coraiatency, and to perform correctlse examples.

This report contains the transcript of a mechanical verification of the Stenning protocol [3]. A description of this protocol, as well as complete documentation on the methods used, can be found in a separate report [2]. Reference to this report is necessary, since the following material is not selfcontained. The transcripts themselves were produced by the Boyer-Moore theorem prover [1]. 2 VC Proof Log 27-Jun-82 09:54:20 ++++++++++++++++++++++++++++++++++++++++ Proof of VC 'TRANSPORT#1' (IMPLIES (AND (SENDER.EXT SOURCE ACK.IN PKT.OUT) (RECEIVER.EXT PKT.IN SINK ACK.OUT) (FOLLOWS PKT.IN PKT.OUT) (FOLLOWS ACK.IN ACK.OUT)) (INITIAL SINK SOURCE)) This formula can be simplified, using the abbreviations SENDER.EXT, AND, and IMPLIES, to: (IMPLIES (AND (CONSISTENT (QUOTE SEQNO) (QUOTE EQUAL) PKT.OUT) (EQUAL SOURCE (FAPPLY (QUOTE MSSG) (RANGE (LATEST (QUOTE SEQNO) PKT.OUT)))) (RECEIVER.EXT PKT.IN SINK ACK.OUT) (FOLLOWS PKT.IN PKT.OUT) (FOLLOWS ACK.IN ACK.OUT)) (INITIAL SINK SOURCE)), which we simplify, applying CONSISTENT.FOLLOWS, INITIAL.FAPPLY, INITIAL.CONSEC.FOLLOWS, NUMBERP.SEQNO, FOLLOWS.LATEST.CONSISTENT, PMAPP.LATEST, INITIAL.RANGE, and INITIAL.TRANS, and opening up RECEIVER.EXT and INITIAL, to: T. Q.E.D. 13069 conses 9.963 seconds 0.0 seconds, garbage collection time ---------------------------------------- VC Proof Log 27-Jun-82 09:55:11 ++++++++++++++++++++++++++++++++++++++++ Proof of VC 'SENDER#1' (SENDER.INT (NULL) (NULL) (NULL) (QUOTE IDLE) 3 0 0 (NULL) 0) This formula can be simplified, using the abbreviation SENDER.INT, to the following six new conjectures: Case 6. (PMAPP (QUOTE (1QUOTE NULL))), which simplifies, opening up PMAPP, to: T. Case 5. (NUMBERP 0). This simplifies, clearly, to: T. Case 4. (FOLLOWS (RANGE (QUOTE (1QUOTE NULL))) (QUOTE (1QUOTE NULL))),...

This report contains the transcripts of a mechanical verification of the "Nano TCP protocol, " which is an abstract model of the data transfer functions of the TCP protocol [Postel 80]. A description of the Nano TCP protocol, as well as complete documentation on the verification methods, can be found in a separate report [DiVito 82]. Reference to this report is necessary, since the following material is not self-contained.

One of the main reasons why constructing deductive proofs that programs satisfy their specifications can be very expensive in practice is the absence of reusable problem domain theories. These theories contain functions that define relevant concepts in the application area of the program, and they contain properties that are deduced from these definitions. Presently, the cost of proving programs is highly inflated by the fact that we usually have to build a new problem domain theory for each new application. If we can develop reusable problem domain theories, the cost of specifying and proving programs in actual practice can be greatly reduced. The development of these theories also would have significant benefits for other aspects of computing science. This paper discusses the composition of problem domain theories and their relation to program specification and proof. REUSABLE PROBLEM DOMAIN THEORIES 2 Acknowledgements During its eight year existence, well over 50 people have contr...

This paper presents an introduction to computer-aided theorem proving and a new approach using parallel processing to increase power and speed of computation. Automated theorem provers, along with human interpretation, have been shown to be powerful tools in verifying and validating computer software. Destiny, while still in developmental stages, has shown promise for deeper and more powerful analysis in the quest to marry a software program with its desired specification. Computer software development is a tedious process. Unlike hardware, software is easily, and therefore often, changed and updated. The ease to build and upgrade programs has yielded ideologies that include “build first, fix later, ” “if it runs, ship it, ” and “there will always be bugs, so only fix the worst ones. ” Additionally, the software development