Formal Methods: State of the Art and Future Directions EDMUND M. CLARKE, JEANNETTE M. WING, ET AL.1 Computer Science Department, Carnegie Mellon University, Pittsburgh, PA ^[email protected]& and ^[email protected]& 1. INTRODUCTION The first part of this report assesses the state of the art in specification and Hardware and software systems will in- verification. For verification, we high- evitably grow in scale and functionality. light advances in model checking and Because of this increase in complexity, theorem proving. In the three sections the likelihood of subtle errors is much on specification, model checking, and greater. Moreover, some of these errors theorem proving, we explain what we may cause catastrophic loss of money, mean by the general technique and time, or even human life. A major goal of software engineering is to enable de- briefly describe some successful case velopers to construct systems that oper- studies and well-known tools. The sec- ate reliably despite this complexity. One ond part of this report outlines future way of achieving this goal is by using directions in fundamental concepts, new formal methods, which are mathemati- methods and tools, integration of meth- cally based languages, techniques, and ods, and education and technology tools for specifying and verifying such transfer. We close with summary re- systems. Use of formal methods does marks and pointers to resources for not a priori guarantee correctness. more information. However, they can greatly increase our understanding of a system by revealing inconsistencies, ambiguities, and incom- 2. STATE OF THE ART pleteness that might otherwise go unde- In the past, the use of formal methods tected. in practice seemed hopeless. The nota- tions were too obscure, the techniques did not scale, and the tool support was 1 Working Group members include Rajeev Alur, inadequate or too hard to use. There Edmund Clarke (Co-Chair), Rance Cleaveland, were only a few nontrivial case studies David Dill, Allen Emerson, Stephen Garland, Steven German, John Guttag, Anthony Hall, and together they still were not convinc- Thomas Henzinger, Gerard Holzmann, Cliff ing enough to the practicing software or Jones, Robert Kurshan, Nancy Leveson, Kenneth hardware engineer. Few people had the McMillan, J Moore, Doron Peled, Amir Pnueli, training to use them effectively on the John Rushby, Natarajan Shankar, Joseph Sifakis, Prasad Sistla, Bernhard Steffen, Pierre Wolper, job. Jeannette Wing (Co-Chair), Jim Woodcock, and Only recently have we begun to see a Pamela Zave. more promising picture of formal meth- This research is sponsored in part by the Wright Laboratory, Aeronautical Systems Center, Air Force Materiel Command, USAF, and the Advanced Research Projects Agency (ARPA) under grant number F33615-93-1-1330. Views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing official policies or endorsements, either expressed or implied, of Wright Laboratory or the United States Government. Permission to make digital/hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. © 1996 ACM 0360-0300/96/0400–0626 $03.50 ACM Computing Surveys, Vol. 28, No. 4, December 1996 Formal Methods • 627 ods. For software specification, industry [ISO 1987] wed two different methods, is open to trying out notations such as Z one for handling rich state spaces and to document a system’s properties more one for handling complexity due to con- rigorously. For hardware verification, currency. Common to all these methods industry is adopting techniques such as is the use of the mathematical concepts model checking and theorem proving to of abstraction and composition. complement the more traditional one of The process of specification is the act simulation. In both areas, researchers of writing things down precisely. The and practitioners are performing more main benefit in so doing is intangible— and more industrial-sized case studies, gaining a deeper understanding of the and thereby gaining the benefits of us- system being specified. It is through ing formal methods. this specification process that develop- ers uncover design flaws, inconsisten- 2.1 Specification cies, ambiguities, and incompletenesses. A tangible byproduct of this process, Specification is the process of describing however, is an artifact that can itself be a system and its desired properties. For- formally analyzed, for example, checked mal specification uses a language with a to be internally consistent or used to mathematically defined syntax and se- derive other properties of the specified mantics. The kinds of system properties system. The specification is a useful might include functional behavior, tim- communication device between cus- ing behavior, performance characteris- tomer and designer, between designer tics, or internal structure. So far, speci- and implementor, and between imple- fication has been most successful for mentor and tester. It serves as a com- behavioral properties. One current panion document to the system’s source trend is to integrate different specifica- code, but at a higher level of descrip- tion languages, each able to handle a tion. different aspect of a system. Another is to handle nonbehavioral aspects of a Notable Examples system such as its performance, real- CICS. Oxford University and IBM time constraints, security policies, and Hursley Laboratories collaborated in architectural design. the 1980s on using Z to formalize part Some formal methods such as Z of IBM’s Customer Information Con- [Spivey 1988], VDM [Jones 1986], and trol System, an online transaction Larch [Guttag and Horning 1993] focus processing system with thousands of on specifying the behavior of sequential installations worldwide [Houston and systems. States are described in terms King 1991]. Measurements taken by of rich mathematical structures such as IBM throughout the development pro- sets, relations, and functions; state cess indicated an overall improve- transitions are given in terms of pre- ment in the quality of the product, a and post-conditions. Other methods reduction in the number of errors dis- such as CSP [Hoare 1985], CCS [Milner covered, and earlier detection of er- 1980], Statecharts [Harel 1987], Tempo- rors found in the process. IBM also ral Logic [Pnueli 1981; Manna and estimated a 9% reduction in the total Pnueli 1991; Lamport 1984], and I/O development cost of the new release. automata [Lynch and Tuttle 1987] focus The success of this work is well on specifying the behavior of concurrent known and resulted in the Queen’s systems; states typically range over Award for Technological Achieve- simple domains like integers or are left ment. It inspired many others to fol- uninterpreted, and behavior is defined low suit. in terms of sequences, trees, or partial orders of events. Still others such as CDIS. In 1992 Praxis delivered to the RAISE [Nielsen et al. 1989] and LOTOS UK Civil Aviation Authority the CCF ACM Computing Surveys, Vol. 28, No. 4, December 1996 628 • E. M. Clarke et al. Display Information System, a part of ular specifications [Heninger 1980; the new air traffic management sys- Janicki et al. 1996]. Many would ex- tem for London’s airspace [Hall 1996]. pect that the use of SPARK would add CDIS is a distributed fault-tolerant to the cost of the software, while im- system implemented on nearly 100 proving its quality. The added qual- computers linked in a dual local-area ity, however, decreased the overall network. Praxis used formal methods cost of software development because as an integral part of the development of the huge savings in testing. The process and in conjunction with other use of SPARK annotations to specify software engineering, project manage- the behavior of the modules led to ment, and quality assurance tech- software that is close to being “correct niques. During requirements analy- by construction,” and hence passes its sis, formal description supplemented tests instead of requiring expensive informal and structured requirements rework. notations. At the system specification stage, an abstract VDM model was TCAS. In the early 1990s, the Safety- developed in conjunction with con- Critical Systems Research Group at crete user interface definitions, semi- the University of California, Irvine formal definitions of the concurrent (now at the University of Washington) produced a formal requirements spec- behavior, and definitions of external ification for the Traffic Collision interfaces. During design, the ab- Avoidance System (TCAS) II, required stract VDM was refined into more on all commercial aircraft flying in concrete module specifications. At a US airspace. They used the Require- lower level, the software for the dual ments State Machine Language LAN was specified and developed for- (RSML), which is based on State- mally using CCS. charts with changes made to over- Productivity on the project was the come difficulties found during the same as or better than on comparable specification process. Although an in- projects carried out using informal dustry group was attempting to pro- methods. There