Seven Myths of Formal Methods

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

2. 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.

3. 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

4. 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.

5. 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

6. 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.

7. 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.

8. 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

9. 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.

10. 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

11. 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

12. 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.