534 NOTICES OF THE AMS VOLUME 47, NUMBER 5 H ow can a computer program developer ensure that a program actually implements its intended purpose? This article describes a method for checking the correctness of certain types of computer programs. The method is used commercially in the development of programs implemented as integrated circuits and is applicable to the development of “control-intensive” software programs as well. “Divide-and-conquer” techniques central to this method apply to a broad range of program verification methodologies. Classical methods for testing and quality control no longer are sufficient to protect us from communication network collapses, fatalities from medical machinery malfunction, rocket guidance failure, or a half-billion dollar commercial loss due to incorrect arithmetic in a popular integrated circuit. These sensational examples are only the headline cases. Behind them are multitudes of mundane programs whose failures merely infuriate their users and cause increased costs to their producers. A source of such problems is the growth in program complexity. The more a program controls, the more types of interactions it supports. For example, the telephone “call-forwarding” service (forwarding incoming calls to a customer-designated number) interacts with the “billing” program that must determine whether the forwarding number or the calling number gets charged for the additional connection to the customer-designated number. At the same time, call-forwarding interacts with the “connection” program that deals with the issue of what to do in case the called number is busy, but the ultimate forward destination is free. One property to check is that a call is billed to the customer if and only if the connection is completed. If the call connection and billing programs interact incorrectly, a called number that was busy and then became free could appear busy to one program and free to the other, resulting in an unbilled service or an unwarranted charge, depending upon their order of execution. If a program includes n interrelated control functions with more than one state, the resulting program may need to support 2n distinct combinations of interactions, any of which may harbor a potential unexpected peculiarity. When n is very small, the developer can visualize all the combinations and deal with them individually. Since the size of a program tends to be proportional to the number of functions it includes (one program block per function), the number of program interactions as a function of program size may grow exponentially. As a result, the developer can use only a very small proportion of the possible program interactions to guide the development and testing of the program. When some unconsidered combination produces an eccentric behavior, the result may be a “bug”. While a computer could be programmed to check a program under development for eccentric behavior by searching exhaustively through all combinations of program interactions, the exponential growth could soon cause the computer to exceed available time or memory. On account of the potential for interactions, adding a few functions to a program can substantially alter its testability and thus viability. From the program developer’s perspective, this is unsatisfactory. If the program is developed carefully, however, the correct behavior of each of the n individual control functions of the program can be checked in a way Robert P. Kurshan is Distinguished Member of Technical Staff at Bell Laboratories, Murray Hill, NJ. His e-mail address is k@research.bell-labs.com.

Program verification

Metamathematics is a source of many interesting theorems and difficult proofs. This paper reports the results of an experiment to use the Boyer-Moore theorem prover to proof-check theorems in metamathematics. We describe a First Order Logic due to Shoenfield and outline some of the theorems that the prover was able to prove about this logic. These include the tautology theorem which states that every tautology has a proof. Such proofs can be used to add new proof procedures to a proof-checking program in a sound and efficient manner.

Towards mechanical metamathematics

Our goal is to develop formal methods for abstracting a given set of programs into a program schema and for instantiating a given schema to satisfy concrete specifications. Abstraction and instantiation are two important phases in software development which allow programmers to apply knowledge learned in the solutions of past problems when faced with new situations. For example, from two programs using a linear (or binary) search technique, an abstract schema can be derived that embodies the shared idea and that can be instantiated to solve similar new problems. Along similar lines, the development and application of program transformations are considered.We suggest the formulation of analogies as a basic tool in program abstraction. An analogy is first sought between the specifications of the given programs; this yields an abstract specification that may be instantiated to any of the given concrete specifications. The analogy is then used as a basis for transforming the existing programs into an abstract schema that represents the embedded technique, with the invariant assertions and correctness proofs of the given programs helping to verify and complete the analogy. A given concrete specification of a new problem may then be compared with the abstract specification of the schema to suggest an instantiation of the schema that yields a correct program.

Program abstraction and instantiation

Dominance relations are used to prune unnecessary nodes in search graphs, but they are problem-dependent and cannot be derived by a general procedure. The authors identify machine learning of dominance relations and the applicable learning mechanisms. A study of learning dominance relations using learning by experimentation is described. This system has been able to learn dominance relations for the 0/1-knapsack problem, an inventory problem the reliability-by-replication problem, the two-machine flow shop problem, a number of single-machine scheduling problems, and a two-machine scheduling problem. It is considered that the same methodology can be extended to learn dominance relations in general. >

Learning dominance relations in combined search problems

Significant modifications of the first-order rules have been developed so that they can be applied directly to algebraic expressions. The importance and implication of normalization of formulas in any theorem prover are discussed. It is shown how the properties of the domain of discourse have been taken care of either by the normalizer or by the inference rules proposed. Using a nontrivial example, the following capabilities of the verifier that would use these inference rules are highlighted: (1) closeness of the proof construction process to the human thought process; and (2) efficient handling of user provided axioms. Such capabilities make interfacing with humans easy. >

Frank Malloy Brown

Papers

An investigation into the goals of research in automatic theorem proving as related to mathematical reasoning

Inductive reasoning on recursive equations