The title of this paper provides an answer to the question posed by Larry King in his panel paper titled "Do formal methods really belong in the toolbox of the practicing engineer?" Yes, formal methods do indeed belong to the toolbox of the practicing engineer. The capabilities of today's computers are truly impressive and as a result have opened door to the design and development of increasingly ambitious systems. An almost unavoidable by-product of these systems is the growing consequences associated with their failure. Another attribute shared by most of these systems is that their complexity is of an unprecedented nature. Thus, these systems live in the cross section (or shall I say cross-hairs) of high consequence and high complexity. For these reasons, attaining and developing the ability to construct highly reliable software is be coming a significant concern. Furthermore, software manufacturers as well as consumers are getting more and more fed-up with missed deadlines, bugs crashing and freezing hardware, and in the worst case, causing havoc to organizations, as bugs/incompleteness lead to allowing trojan horses for hackers through viruses and attacks. This is leading to attempts to replace ad hoc techniques in system design by more systematic methods. What is the role that formal methods, as a field of study, can play in addressing these issues? If by formal methods, one is exclusively referring to formal verification methods for software, such tools will probably not be part of a practicing engineer's tool in the near future. King's note reflects the prevailing confusion about formal methods, what can be achieved using them, and what cannot be achieved using them, and their overall role in system design and development.
展开▼
