Immaturity and Potential of Formal Methods

Luigi LogrippoUniversity of OttawaSchool of Information Technology and EngineeringTelecommunications Software Engineering Research Group

Communication and Information Technology Ontario

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, Viennahttp://www.oir.ucf.edu/wm/paint/auth/bruegel/babel.jpg

Complementarity:Different methods are good for different purposes

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 displayed

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 behaviors Without reference to components

(unbound) With reference to components (bound)

Intuitive, easy to learn and useAllow design refinementImpressive adoption by industry

LOTOS

Formal, algebraicLeanSupports different levels of

abstractionEfficient 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 techniques

State-Oriented Techniques: SDLSpecify concrete behaviors at the

implementation levelAllow rapid derivation of partial

implementation codeAllow detection of errors at the detailed

design stageHowever 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

TTCN

By testers for testersStandard widely acceptedSuccessful in practiceExcellent tools, linking it to FDTs

Stage 1Requirements

Services

Stage 2MessageSequence

Information

Stage 3Protocol &Procedures

Relevant Techniques at Different Design Stages

UCM

MSC

LOTOS

SDL

TTCN

Compatibility between techniques

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

toolset?

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 volt-ohmmeters, 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

time

complexity

formal methods

software

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 developmentPatching 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 services

Interworking will have to be provided (deregulation...)

Building on legacy software...http://www.dilos.com/region/crete/minoan_pictures.html

Reasons for Long-run Optimism

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 ‘natural’

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

together Break the boundaries between different representation

techniques 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 inheritance

do not sufficiently support dynamic systems

A ( B C ) , A , B

B , B C , C

A , A B C , B A , A B C , C

A ( B C ) , A B

&

A ( B C ) , A C

&

A ( B C ) , ( A B ) & (A C )

& &

A ( B C ) , A , C

Chains of deduction in linear logic

The Power of Specialized Methods

Special-purpose systems are more powerful than general-purpose systems Because they can use domain-specific

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

©Dilbert

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

© C.H. Smith

[Temple of Zeus at Olympia]

Try double fixpoint induction...

[Muffy]Huuu...

Cleaning...

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

J. Paul Getty Museum

Manager hostile (defending his practices)...

J. Paul Getty Museum

Later, Manager happy

J. Paul Getty Museum

Not everyone could be persuaded...

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.

British Museum

Sundry Jobs...

In passing, he had to sustain the world... Another proof of the scalability of the

approach

Getting grants...

Obtain the girdle of Hippolyta, the queen of the Amazons

Hyppolyta, chair of the committee, gave it to him but the other Amazons in the committee (unduly influenced by Juno) were unhappy...

I want that grant

But not for himself...

When it was discovered that he had accepted payment for two labors, Hercules was asked to do two additional labors...

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

unfortunately we have to cancel it...

Hercules tired...

Hercules’ main method was ‘brute force’

Can we do better?