Immaturity and Potential of Formal Methods Luigi Logrippo University of Ottawa School of Information Technology and Engineering Telecommunications 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, Vienna http://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 use Allow design refinement Impressive adoption by industry LOTOS Formal, algebraic Lean 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 techniques State-Oriented Techniques: SDL 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 TTCN By testers for testers Standard widely accepted Successful in practice Excellent tools, linking it to FDTs Relevant Techniques at Different Design Stages Stage 1 Requirements Services Stage 2 Message Sequence Information Stage 3 Protocol & Procedures 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 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 complexity software formal methods time 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 services Interworking will have to be provided (deregulation...) http://www.dilos.com/region/crete/minoan_pictures.html Building on legacy software... 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 B,B A,A C,C BC,B BC,C A,A A(BC),A,B A(BC),A ,C A(BC),A A(BC),A & B ) & (A & & A(BC),(A Chains of deduction in linear logic C ) & B C 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 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... ©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... [Muffy] Huuu... Try double fixpoint induction... Cleaning... © 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 convinced...). 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. 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 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 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?