Transcript Seven Myths of Formal Methods

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.