Seven Myths of Formal Methods - by Anthony Hall, Praxis Systems Presented by Shanmughapriya Senthil

Introduction  Usually, detractors think that formal methods are,  Difficult  Expensive and  Not widely useful  A lot what is said about formal methods is based on assertions and not facts  Some of the beliefs about formal methods have been exaggerated and have acquired almost the state of myths  This article takes a look at seven of the favorable and unfavorable myths of formal methods.

Activities of Formal Methods The main activities of Formal methods are,  Writing a formal specification  Proving properties about the specification  Constructing a program by mathematically manipulating the specification  Verifying a program by mathematical argument

Myth 1  Formal Methods can guarantee that software is perfect  But the fact is that formal methods are fallible  Their fallibility is the most important limitation which arises from the fact that, Some things can never be proved and Sometimes proofs can be wrong  The above limitation can be overcome by using mathematical models based on reasoning  But again the limits of mathematical modeling are, Only some aspects of program behavior will be covered Correspondence between the formal description and the real world is limited  Formal Methods eliminate only certain classes of errors and not all of them but they do make much easier to find all sorts of errors.

Myth 2  Formal Methods are all about Program Proving  Program Verification is one aspect of Formal Method  It is important since cost of removing errors increases as a project progresses  To verify a program we need formal specification. - a formal specification is a precise definition of what the software intended to do - It differs from the design specification in that it is concerned only with the function of the system and makes no commitments to its structures

Myth 2 (Contd.)  Writing such formal specification help us to,  Clarify requirements  Discover latent errors and ambiguities  Make decision about functionality at the right stages  Implementation from the formal specifications done in small steps rather than writing a whole program and verifying it.  So, a specification is a kind of contract between specifiers and implementers, and if the specification is formal, it is easy to interpret the contract and to decide if it has been satisfied.

Myth 3  Formal Methods are useful for safety-critical systems  The fact is that formal specifications help with any system  Formal methods should be used when cost of failure in systems which are Critical in some way Replicated many times Fixed into hardware Dependent on quality for commercial reasons  If the system is critical, it must be developed completely formally  Many benefits of formal methods come from the specification stage. Thus, on a non-critical system, even if none of the rest of the development is formal, just writing a formal specification is a big improvement over other informal methods.

Myth 4  Formal Methods require highly trained mathematicians  The fact is that mathematics for specification is easy  Once it is recognized that the practice of formal methods is concerned with writing specifications, the mathematicla difficulties become much less significant  Training in fields of discrete mathematics and formal notation would help to overcome difficulties  Competent people who can cope with the necessary mathematical manipulations are the ones who must carry out safety-critical projects

Myth 5  Formal Methods increase the cost of development  But the fact is that it decreases the cost of development  Also, it changes the shape of project since more time is spent on the specification phase  Due to this, it can be difficult to manage the specification process even if cost of development decreases.

Myth 6  Formal Methods are unacceptable to users  The fact is that formal specifications help users understand what they are getting  There are 3 ways to do this, Paraphrase the specification in natural language Demonstrate consequences of the specification Animate the specification

Myth 7  Formal Methods are not used on real, largescale software  The fact is that formal methods are used daily on industrial projects  Several organizations are using formal methods on industrial scale projects  Formal methods are not only used in security area. Their scope is far wider

Conclusion Instead of seven myths, the author is replacing them with seven facts,  Formal methods are helpful at finding errors early on and can nearly eliminate certain classes of error  They work largely by making us think about the system we are going to build  They are useful for almost any application  They are based on mathematical specification, which are much easier to understand than programs  They can decrease the cost of development  They can help clients understand what they are buying  They are being used successfully on practical projects in industry.