fiw00_invited - School of Electrical Engineering and Computer

Immaturity and Potential
of Formal Methods
Luigi Logrippo
University of Ottawa
School of Information Technology and
Telecommunications Software Engineering Research Group
Communication and Information Technology
Revised version of an invited presentation given at the Sixth International Workshop on
Feature Interactions in Distributed Systems (FIW’2000). Glasgow, May 2000.
The Tower of Babel of
Formal Methods
Kunsthistoriches Museum, Vienna
Different methods are good for different
At the initial requirements stage, logical proof
techniques may be important
 Call Number Delivery stipulates that the number of the calling
party be displayed at the called end
 Unlisted Number stipulates that certain numbers cannot be
 Contradiction: if both features coexist, should
unlisted numbers be displayed or not?
Theorem provers can expose this.
As the design becomes behavioral, but is
still tentative, techniques that describe
abstract behaviors become important
We have had a lot of success with Use Case
Maps and LOTOS at this level
UCMs translate easily into LOTOS for
execution, testing, and state exploration
“Synchronous” models such as Lustre also
hold promise at this stage (reduced state explosion)
Use Case Maps
Represent partial orderings of abstract
Without reference to components (unbound)
With reference to components (bound)
Intuitive, easy to learn and use
Allow design refinement
Impressive adoption by industry
Formal, algebraic
Supports different levels of abstraction
Efficient tools
Message Sequence Charts
Excellent to represent concrete scenarios
All behavioral techniques can produce and
accept MSCs
MSCs are a visual medium for scenario
exchange among different behavioral
State-Oriented Techniques:
Specify concrete behaviors at the
implementation level
Allow rapid derivation of partial
implementation code
Allow detection of errors at the detailed
design stage
However many design errors should be
detected and corrected at earlier stages!
Testing methods:
techniques of very general use
It is possible to test at all stages and levels of
design, and between all of them!
Abstract, incomplete behaviors can be tested, as
well as implemented behaviors
It is possible to test if specifications at various
stages of design are mutually consistent
It is possible to test if different refinements of a
design are mutually consistent
By testers for testers
Standard widely accepted
Successful in practice
Excellent tools, linking it to FDTs
Relevant Techniques at
Different Design Stages
Stage 1
Stage 2
Stage 3
Protocol &
Compatibility between
Unfortunately, the techniques mentioned are not
quite compatible
They were developed by teams who were not very
interested in other techniques
Little attempt to develop common semantic models
Can we expect industry to adopt such a disparate
Lack of a sufficient common
body of basic concepts
This is one of the reasons why in software research many
researchers prefer to ‘start from scratch’ rather than using
the results of other researchers
If a researcher believes to be using better and new
concepts, won’t bother looking at others’ work
Where are our volt, amp, ohm, where are our voltohmmeters, oscilloscopes?
Other areas of computing (such as complexity theory,
formal languages) have been much more successful in this
respect than software
Perceived inadequacy of
Formal Methods
formal methods
Since current formal methods are perceived as not matching
the complexity of software, they will have to evolve more
rapidly than the software they address!
Other reasons of limited
penetration of formal methods
Little need felt for high quality software!
Rigorous techniques are seen as impeding
software development
Patching is seen as more efficient than
preventing (see similarity with medical practice?)
Current high tolerance of public for
software faults
Low quality standards in software industry
But certain things
could happen...
Piling up weak software on top of weak software may
reach a breaking point - a disaster?
Consumers may eventually decide that they are no longer
willing to put up with imposed bugs
 no warranty provided (only CD-ROM is guaranteed...)
 use at your own risk
 pay to get an improved release
Market emphasis is shifting towards provision of complex
Interworking will have to be provided (deregulation...)
Building on legacy software...
Reasons for Long-run
Formal methods have already proven
themselves in the area of critical software
much software will soon be seen as critical
Logic is to programming what calculus is
to mechanics
Use of logic and algebraic methods allows
long chains of deduction, that provide
useful information on system behavior
And the main reason:
The immaturity of formal methods
means immaturity of the whole area
of software technology
‘To do’ list
(beside what has been mentioned already)
Create a trajectory of software development that includes
formal methods as an inevitable link (some formal methods
are already there: BNF)
Include graphic methods because they are seen as
Identify system architectures and software structures that
are conducive to the use of formal methods
Automate the trajectory as much as possible
Property-preserving transformations
‘To do’ list continued...
 Design “families” of formal methods that work well
 Break the boundaries between different representation
correctness properties established at some stage of
development or in some viewpoint should be inherited by other
stages and viewpoints
 Invent new logics, new algebras to support the process
current logic and algebraic models
do not sufficiently support refinement, transformation, property
do not sufficiently support dynamic systems
A(BC),A ,C
B ) & (A
Chains of deduction in linear logic
C )
The Power
of Specialized Methods
Special-purpose systems are more
powerful than general-purpose systems
Because they can use domain-specific
Future practical validators or verifiers will
not be general-purpose systems
They will be specific to an application area,
or even specific to systems.
How long will it take?
Some sobering thoughts...
 It took 1700 years between the time when the principle of steam
turbines became known and the time it was widely applied
 It took 53 years between the time when it was found that lemon juice
prevented scurvy and the time it became a part of the diet in the
British Navy
preventive medicine!
 The principles of Multics were invented in the mid-sixties. They are
largely ignored by popular OS
 Formal methods are so little recognized now that, if a crisis occurs,
they may not be identified among the solutions
An example of how long...
IP protocol is over 25 years old and only
now is being widely adopted
One of the reasons may be that it has
been widely tested in practice
only now a sufficiently large industrial base
‘believes’ in it
Time-to-market in this case is obviously
unacceptably long
Revisiting An Old Story...
(about proving the worth of formal methods)
Hercules was summoned by his boss
Eurystheus, who told him that, in order to
prove himself, he had to perform 10 feats
to become 12, we’ll see...
The State Explosion Problem...
Kill the nine-headed Hydra. Two new
heads would grow on the Hydra from
each fresh wound, and one was immortal.
Hercules burned eight and put the
immortal one under a rock.
J.Paul Getty Museum
The Legacy Software Problem...
Clean the Stables of King Augeas, which
had not been cleaned for 30 years.
Hercules succeeded by diverting two nearby
rivers to wash the muck away.
As a side effect, this proved the ‘scalability’
of the approach...
Try double fixpoint
© C.H. Smith
[Temple of Zeus at Olympia]
Tackling New Applications...
Take the golden applets from the garden
of the Hesperides
© C.H. Smith
Dealing with Various Managers...
Kill the lion of Nemea (a quick one).
Capture the Ceryneian Hind. After running after
it for many months, he finally trapped it.
Kill the wild boar of Erymanthus. A wild battle...
Capture the wild bull of Crete.
Bring Cerberus, the three-headed dog of Hades,
to the surface world (this one had to be
Manager hostile
(defending his practices)...
J. Paul Getty Museum
Later, Manager happy
J. Paul Getty Museum
Not everyone could be persuaded...
J. Paul Getty Museum
Dealing with armies of hackers and
super-programmers of various kinds...
Kill the carnivorous birds of Stymphalis.
Capture the oxen of Geryon.
Capture the man-eating mares of Diomedes.
Sundry Jobs...
In passing, he had to sustain the world...
Another proof of the scalability of the
Getting grants...
Obtain the girdle of Hippolyta, the queen
of the Amazons
I want that grant
Hyppolyta, chair of the
committee, gave it to
him but the other
Amazons in the
committee (unduly
influenced by Juno)
were unhappy...
But not for himself...
When it was discovered that he had
accepted payment for two labors,
Hercules was asked to do two additional
Happily for him, activity reports
were written by others...
Hesiod, Apollodorus...
Hercules did not have to
face the ultimate downer...
This project is
going very
unfortunately we
have to cancel it...
Hercules tired...
Hercules’ main method was ‘brute force’
Can we do better?