Program Verification

Abstract

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.