A. Hall, "Seven myths of formal methods," IEEE Software, vol. 7, no. 5, pp. 11 -- 19, 1990.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....industry alone was 6 billion [RT02] In spite of the current best practice, significant and costly errors remain in production software. Techniques utilizing formal specification languages and based on sound mathematics have been successful at identifying subtle errors missed by other techniques [CW96, H90]. Common formal verification tools include theorem provers [RJ00] model checkers [H97] and runtime monitors [GR01, GM02, KV99, DG01] In theorem proving, a logic formula expressing a desired property is derived from axioms that describe system behavior. In model checking, a system is described ....

....enabling the use of the aforementioned tools as well as other formal methods such as automated analysis and code synthesis. While formal methods have been demonstrated to improve the dependability of programs, practitioners have not widely adopted them. The following reasons have been cited [I88, H90]: The use of formal methods requires a high level of mathematical sophistication and training. Tools supporting the use of formal methods are not mature enough for general use and have not been well integrated with widely used software development tools. Customers and clients have ....

A. Hall, Seven Myths of Formal Methods, IEEE Software, September 1990, pp. 11-19.

....in this case meant that it could no longer prove unambiguously and quantitatively exactly how much better a formal method can be. Some more details on the project follow in section 2.3. 1. 2 Opponents Formal methods are often opposed by practitioners on purely pragmatic grounds, cf. also [Ha90] and [BoHi94] The following is from an opponent of formal methods, who shall remain anonymous: A formal design method is often overkill. Only a small portion of the errors found by an expensive formal design process would ultimately show up in practice. And similarly, quoted verbatim from a ....

J. A. Hall, Seven myths of formal methods . IEEE Software, 7(5):11, 19, Sept. 1990.

....a formal concretisation process leading to provably correct code. This process is normally referred to as refinement within the specialist literature (see, for example, Morgan [12] More recently, formal specifications have come to be acknowledged for their contribution to problem understanding [9, 10, 2, 11], their precision offering potential for enhanced communication and evaluation of understanding. In this paper we use refinement in its more common sense of clarification or increasing relevance. Our preliminary research [13, 14, 15, 2] suggested that a socio organizational approach could be used ....

A. Hall. Seven myths of formal methods. IEEE Software 75(5) (1990) 11--19.

....adequately captured) 4] Aside from certain well understood domains, the cost of formally specifying requirements is not only exorbitant, but the cost of proving the correctness of an implementation may be unacceptably high. Furthermore, although there are some well documented counter examples [11], formal specifications and proofs typically do not scale well to large systems, and are rarely robust in the face of evolutionary changes. This suggests that formal methods most likely have their place in ensuring the robustness and correctness of individual, functional software components, but ....

Anthony Hall. Seven myths of formal methods. IEEE Software, 7(5):11--19, Sept. 1990.

....considered to be a conformance centred approach to software development. They were presented as a basis for a formal concretisation process leading to provably correct code. More recently, formal specifications have come to be acknowledged for their contribution to problem understanding [H90, S92a, SS92a, W90], their precision offering potential for enhanced communication and evaluation of understanding. Our preliminary research [FSS93, S93, SFG92, SS92a] suggested that a socio organisational approach could be used beneficially in concert with object oriented formal specification techniques within the ....

Hall, A. (1990). Seven myths of formal methods. IEEE Software, 7(5), 11--19.

....such methods are not routinely used in industry. Even when formal methods are often used, they are used only to a limited extent and resisted by engineers and programmers. This situation is hardly surprising, both because there are many widely held misconceptions about the use of formal techniques [2] and because many of the methods are not practical. Below we will argue that it is possible, to obtain benefits from methods based on a relational model of software requirements. The principles of documentation and the software design process most applicable for our objectives are based on the ....

Hall, A., "Seven myths of formal methods", IEEE Software, 7(5), pp. 11-20, 1990.

.... The capability and feasibility of the approach presented here is fully demonstrated by a prototype tool Venus[9] 2 Pragmatic Obstacles The have been laudable efforts by the formal methods community to demystifying formal methods and to convince practitioners that formal methods are practical [3]. However, as the formal methods community zealously appeals to the practitioners, it fails to fully understand and address the practical concerns of practitioners. Since a reasonably solid foundation has been established for formal methods, it s time to focus more on the pragmatics of formal ....

A. Hall. Seven myths of formal methods. IEEE Software, 7(5):11--19, Sept. 1990.

....these accidents with the Therac 25 the reader is referred to [LT93] Formal methods, the term with which the variety of mathematical modelling techniques that are applicable to computer system design is meant, are often advocated as a way of increasing confidence in computer based systems. Many [BS92, BH95b, BS93b, BBL93, BH95a, BS93a, Bow93, But93, CGR93, CG92, GCR94, Hal90, Kem90, Nic91, RvH93, Rus94, WW93] believe that the use of formal methods currently offers the only intellectually defensible method for handling the software crisis which increasingly affects the world of embedded systems. In this report we shall mainly concentrate on safety critical software design. Formal methods can be applied ....

A. Hall. Seven myths of formal methods. IEEE Software, pages 11--19, September 1990.

....designs. Parts of the industry seem to have adopted this thought. Companies like AT T, Bell Laboratories, Cadence, IBM, Intel and Motorola started formal verification programs in the recent years, often kept internal and on a high level of confidence. For the interested reader we recommend [Hal90] and the followup [BH95] A tool engineer s point of view on formal verification is recorded in [Ste98] 0.3 Techniques for Formal Verification Formal verification is the process of establishing or refuting that a system conforms to a specification. We briefly outline some of the most prominent ....

Anthony Hall. Seven Myths of Formal Methods. IEEE Software, 7(5):11--19, September 1990. 9

.... from many experts in the area of formal methods and concentrating on the industrial application of these techniques [23] Anumber of sites are participating in this project and a summary of some of the issues involved has been produced [9] in response to a paper byAnthony Hall of Praxis [19]. In 1995, a special issue of the Information and SoftwareTechnology journal on the Z notation is also planned, again with contributions from several partners. Open meetings The major school and symposium on Formal Techniques in Real Time and Fault Tolerant Systems (FTRTFT) is jointly ....

J. A. Hall. Seven myths of formal methods. IEEE Software, pages 11--19, September 1990.

....and managers. This situation is hardly surprising since formal methods technology is largely perceived to consist of a collection of prototype notations and tools which are difficult to use and do not scale up easily# there are many widely held misconceptions about the use of formal techniques [56]. It maybefairtosay that formal methods research has to some extent been dominated by the fundamental scientific aspects rather than by problems in application. Even if we knew how to fit formal methods with currentdevelopmenttechniques there is still the problem that a lot of software is ....

....a whole, rather than the software alone. A combination of modern techniques, including formal methods, can help in the development of safety critical software, even though their scope may be limited at present. There are manymyths and few facts concerning software engineering methods (see also [56]) 63] lists some myths and facts concerning the use of formal methods in the development of software. Improvements in time scales, costs and quality are possible in practice using suchtechniques. In a (subjective) table giving the contribution of 11 (not necessarily incompatible) software ....

HALL, J.A.: `Seven myths of formal methods', IEEE Software, September 1990, pp. 11--19

....cation strategy tted to B is outlined in section 6. 2 Previous work on the limits of Formal Methods If formal methods are deemed necessary to achieve ultra high dependability, previous work has allowed to identify their limits. Most of the material included in this section has been found in [6, 7, 13, 15]. Non functional requirements (including dependability requirements) are not addressed by formal methods. In the sequel of this paper, the word requirement without any further comment will denote a functional requirement . Formal methods involve building formal models, and there are some ....

A. Hall. Seven myths of formal methods. IEEE Software, pages pp.11-19, September 1990.

....and managers. This situation is hardly surprising since formal methods technology is largely perceived to consist of a collection of prototype notations and tools which are difficult to use and do not scale up easily# there are many widely held misconceptions about the use of formal techniques [48]. Additionally, a proportion of the formal methods researchcommunity has been inward looking for much of its existence and has not therefore been able (or willing) to explore ways of working with and improving existing best practice. Even if we knew how to fit formal methods with ....

....as a whole, rather than the software alone. Acombination of modern techniques, including formal methods, can help in the developmentofsafety critical software, even though their scope may be limited at present. There are manymyths and few facts concerning software engineering methods (see also [48]) 55] lists some myths and facts concerning the use of formal methods in the development of software. Improvements in time scales, costs and quality are possible in practice using such techniques. In a (subjective) table giving the contribution of 11 (not necessarily incompatible) software ....

HALL, J.A.: `Seven myths of formal methods', IEEE Software,September 1990, pp. 11--19

....to be able to do both. The examples were chosen to be relevant to other aspects of the degree course; e.g. a (simplified version of) the World Wide Web was used as a running example. The process of producing a formal specification [Bow00b, BH97] is as important as the final specification itself [Hal90], so a major aspect of the unit was to show how a specification can be developed, in the framework of the Z notation. Four exercises, supported by tutorials, were used to help develop student s understanding of Z and their specification skills: 1. Logic and Quantifiers Sets and Set ....

J. A. Hall. Seven myths of formal methods. IEEE Software, 7(5):11--19, September 1990.

....may be veri ed. There are many examples that show the usefulness of FM in different areas (Z[Spi88] VDM [Jon86] Larch [GuHo93] CSP [Hoa85] CCS [Mil80] StateCharts [Har87] Temporal Logic [Pnu81] and LOTOS [ISO87] Despite these advantages, FM are not very popular among practitioners [Hal90, BoHi95a, BoHi95b, SwSw92b]. In their beginnings, it could be argued that FM notations were obscure, that techniques did not scale, that tool support was inadequate or too hard to use, that there were only a few non trivial case studies, or that very few practicing software and hardware engineers had been trained to use ....

....in the early stages of the software development cycle, as a aw detector and, capitalizing on the intrinsic abstraction of FM, as a means of reducing complexity and improving the understanding of requirements by the development team. Veri cation properties are sacri ced, but it has been contended [Hal90, SwSw92a] that formal speci cations may, in fact, be valuable independently of their use for program veri cation. Lightweight modeling has been applied to the modeling of EDI applications [GSS95] in Object Z [DuRo00, SwFo92] and in FOOM methodology [Fow96] which combines formal modeling with ....

Hall, A. 1990. Seven Myths of Formal Methods. IEEE Software, 7:11-19.

....of abstraction is something that only comes with experience. If formal specifications are included, these should always be accompanied by informal explanation to clarify the meaning and place it in context. Formal specifications can be made intelligible and acceptable to non technical personnel [19], but only provided that they are augmented with sufficient amounts of informal explanation, diagrams, etc. 7. Maiandros 1 (M ff ff ffiaeo ) meandering Taking too long in the development of software is a widespread phenomenon [18] Estimating the time for software projects is difficult ....

....be assessed. Understanding (oeAE ffloe sunesis) A formal specification significantly aids in the comprehension of a system. The process of producing the formalization is as important as, or perhaps even more important than, the resulting specification itself in helping with this understand [19]. The construction of proofs for theorems concerning the system can bring an even greater depth of knowledge about why the system works the way it does. Modelling, animation and rapid prototyping are also complementary aids to understanding [8] Judgement (fl j gnome) and consideration ....

J. A. Hall. Seven myths of formal methods. IEEE Software, 7(5):11--19, September 1990.

....University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands. 196 TRETMANS, WIJBRANS AND CHAUDRON Figure 1. The geographical situation of the Maeslant Kering near Hoek van Holland, between Rotterdam and the North Sea. and discussed in a famous article: Seven Myths of Formal Methods [8]. The experiences obtained from using formal methods for the development of BOS will be discussed on the basis of that article. We will discuss to what extent those myths are true for the BOS project. The data for this paper were collected by means of interviews with software engineers working on ....

....half were incorrect test specifications, incorrect configuration parameters or documentation problems. None of the faults affected multiple subsystems in the design; all had limited scope and could be solved locally. 3. Seven Myths of Formal Methods The Seven Myths of Formal Methods presented in [8] are seven (positive and negative) claims about the use of formal methods: 1. formal methods can guarantee that software is perfect; 2. formal methods are all about program proving; 3. formal methods are only useful for safety critical systems; 4. formal methods require highly trained ....

[Article contains additional citation context not shown here]

A. Hall, "Seven myths of formal methods," IEEE Software, Vol. 6, No. 9, pp. 11--19, 1990.

....not readily accepted by domain specialists. This applies particularly to formal speci cations that are at the very basis of any formal software development. The reasons are twofold formal speci cations are hard to understand and dicult to relate to the concepts of the application domain. Hall [9] expressed this quite succinctly when he wrote that formal speci cations need to be accompanied by a paraphrase in natural language that explains what the speci cation means in real world terms and why the speci cation says what it does . We are directly addressing both problems ....

A. Hall. Seven Myths of Formal Methods. IEEE Software, 7(5):11-19, 1990.

....VISUALIZATION In considering the material at hand for component comprehension, we discussed the case, when specifications are available as an almost ideal situation. However, whether it is a myth and or a fact, formal specifications [30, p 2303] are often criticized to be hard to understand [10] or not containing all important facets a software developer is interested in [14] Some of the properties, formal specifications are criticized for (e.g. the lacking connection to other representational forms, either upstream or downstream in the software development process) might not pertain ....

A. Hall. Seven Myths of Formal Methods. IEEE Software, 7(5):11--19, Sept. 1990.

....competences in logic and inductive proof. Their take up in industry has been limited, due to the specialist nature of the skills required, perceived cost factors and doubts about their effectiveness, even though some projects have demonstrated significant cost savings through using formal methods [Hall90]. Model based methods, such as VDM [Jone80] and Z [Spiv92] are mostly used to foster more abstract thinking about a design, while algebraic methods, such as OBJ [Futa85] Larch [Gutt85] come with full term rewriting engines for inductive theorem proving and Lotos [Bolo87] uses traceinclusion to ....

A Hall, "Seven myths of formal methods", IEEE Software, 7 (5), 1990, 11-20.

....not readily accepted by domain specialists. This applies particularly to formal speci cations that are at the very basis of any formal software development. The reasons are twofold formal speci cations are hard to understand and dicult to relate to the concepts of the application domain. Hall [10] expressed this quite succinctly when he wrote that formal speci cations need to be accompanied by a paraphrase in natural language that explains what the speci cation means in real world terms and why the speci cation says what it does . We are directly addressing both problems ....

A. Hall. Seven Myths of Formal Methods. IEEE Software, 7(5):11-19, 1990.

....if they or their employers had to guarantee their software and could be sued for damages caused by their malfunctioning software. 1 Introduction Formal methodologists continue to bemoan the failure of practicing software engineers to employ formal methods in their daily software development work [15, 30, 17, 8, 9, 12, 22, 23, 21, 11]. Early attempts by formal methodologists to convince software engineers to use formal methods focused on the benefits to software quality that would accrue if formal methods were to be used regularly in software development [20, 14, 11, 12] Surely, once a software practitioner understood the ....

Hall, A., "Seven Myths of Formal Methods," IEEE Software 7(5), p.11--19 (September 1990).

....development over formal development. And instead of dismissing it out of hand, accommodating it within the current formal framework advocated by many software engineers and academics may be more productive. In doing so we may also remove some of the myths around both testing and formal development [4, 5]. Formality should not be an end to itself but faced with such a mass of ad hoc techniques which constitute the testing phase one cannot believe that incorporating formality in the testing process would not at least clarify the situation and allow further progress. 1.2 A Gap to be Filled As ....

....oracle. 32 In addition to these benefits we can note that, from a more global point of view, the process of testing software from formal specifications brings more cohesion to the software development life cycle and helps dismantle some long established paradoxes about formal methods in general [4, 5]. In particular, using formal specifications to derive software test cases is not at odds with the techniques of formally proving software correctness. This is particularly true since such proofs are rarely provided for the entire specification but are more generally derived for those parts of the ....

[Article contains additional citation context not shown here]

A. Hall, "Seven myths of formal methods," IEEE Software, pp. 11--19, Sept. 1990.

.... items could be: ffl Has the panel chairman gone nuts ffl Is there a difference between the US and Europe ffl Is Australia like Europe or the US ffl Where in the Spectrum is Japan Located 5 Formal Method Myths Commandments A background also for the panel are the following publications [2, 3, 4]. See references at end of this panel statement. 5.1 Seven Myths of Formal Methods In [2] Anthony Hall lists and dispels the following seven Myths : 1. Formal Methods can Guarantee that Software is Perfect 2. Formal Methods are all about Program Proving 3. Formal Methods are only Useful for ....

....and Europe ffl Is Australia like Europe or the US ffl Where in the Spectrum is Japan Located 5 Formal Method Myths Commandments A background also for the panel are the following publications [2, 3, 4] See references at end of this panel statement. 5. 1 Seven Myths of Formal Methods In [2] Anthony Hall lists and dispels the following seven Myths : 1. Formal Methods can Guarantee that Software is Perfect 2. Formal Methods are all about Program Proving 3. Formal Methods are only Useful for Safety Critical Systems 4. Formal Methods Require highly trained Mathematicians 5. Formal ....

Anthony Hall. Seven Myths of Formal Methods. IEEE Software, 7(5):11--19, 1990.

....Methods 1. Formal methods guarantee perfection. 2. They work by proving correctness. 3. They are only good for critical systems. 4. They involve complex mathematics. 5. They increase costs. 6. They are incomprehensible to clients. 7. Nobody uses them for real projects. This classic paper [8] by Anthony Hall of Praxis Systems is based upon industrial usage of formal methods. Here is a summary of how he refutes each myth. 1. All human methods are fallible. In particular, the specification could be an inadequate model of the real world. Errors can also occur in machine checked proofs. ....

....involving critical software. In those last four, government agencies required the use of formal methods. Two of them (the Darlington nuclear power plant and the Paris Metro signalling system) are discussed in separate slides below. The SSADM design tool built by Praxis inspired Hall s paper [8]. It involved 450 staff weeks of effort, two devoted to writing the Z specification. IBM s Customer Information Control system is large, 800,000 lines of code. IBM is now using the Z specification language to re engineer this system; the 50,000 lines quoted above were developed in this way. ....

Anthony Hall. Seven myths of formal methods. IEEE Software, pages 11--19, September 1990.

....of this paper, I am trying to include in the realm of FMs anything anyone working in FM claims is an FM. If I have neglected to include one, my apologies. Please inform me by e mail and include a reference to literature about it. For fuller discussions, see the papers by Hall, Leveson, and Wing [16,19,22], and papers cited therein. 2 Berry 1 P C formal specification of requirements 2 P C verification of consistency and basic correctness of requirements specification 3 P C formal specification of design 4 P C verification of consistency of requirements and design specifications 5 P ....

.... eliminate enough errors from ever showing up later in the development of the SWICBS, when they are very expensive to fix, that the cost of the later development is reduced enough that the total cost of an FMassisted development is no more or even less than than that of an unassisted development [16,17]. See Section 5 for more information about the cost to fix 6 Berry errors as a function of the development stage in which they are found. 3 Errors and Requirements Specifications One thing that has been learned over the years is that most errors are introduced into SWICBSs during the ....

Hall, A., "Seven Myths of Formal Methods," IEEE Software, 7:5, 104--103, September 1990

....If the costs of complete application of formal methods preclude their use, then selective application of those same methods is the only practical alternative. Arguments are often heard that practitioners should be using formal methods and that the factors preventing their use in practice are myths [Hal90, BH94]. But the fact remains that the mainstream software engineering community has largely failed to embrace a complete switch to formal methods. Even formal methods proponents have begun to recognize that the selective application of those formal methods may be the only viable alternative [Rus95, ....

Hall, A., "Seven Myths of Formal Methods," IEEE Software, Vol. 7, No. 5, Sept. 1990.

....be described at its best as poor. Formal methods have been used with success in hardware development [Hei98] but in software development they have been used rarely, their use being restricted mainly to safety critical software. Many reasons have been suggested for this in the literature [Sai96, Hal90a, Hoa96, Str89, Rus93] some of the most common being: 1. Problems finding the right level of abstraction. 2. Lack of education (on the user s part) 3. Hard to write good specifications. 4. Difficult to understand (highly specialised) 5. Absence of structure and method. 1 CHAPTER 1. ....

A. Hall. Seven myths of formal methods. IEEE Software, 7(5):11--19, September 1990.

....delivered. Thus it appeared mandatory to change the way of developing the requirements document. 3. Another way to validate requirements How is it possible to produce better SRD and to derive tests from this SRD These questions were answered many years ago by people emphasizing formal methods [3]. Unfortunately their approach was based uniquely on formal specifications without any considerations for the (semi formal) techniques used at the industrial level. Moreover, formal techniques have not been scaled up. A few thousand lines seems to be the maximum length of such formal ....

J. Hall. Seven myths of formal methods. IEEE Software, September 1990.

....engineers to be able to do both. The examples were chosen to be relevant to other aspects of the degree course; e.g. a (simplified version of) the World Wide Web was used as a running example. The process of producing a formal specification [4, 5] is as important as the final specification itself [10], so a major aspect of the unit was to show how a specification can be developed, in the framework of the Z notation. Four exercises, supported by tutorials, were used to help develop student s understanding of Z and their specification skills: 1. Logic and Quantifiers Sets and Set ....

J. A. Hall. Seven myths of formal methods. IEEE Software, 7(5):11--19, September 1990.

....formal methods remain one of the more contentious techniques in industrial software engineering. Despite some improvement in the uptake of formal methods, it is still the case that the vast majority of potential users of formal methods fail to become actual users. A paper by Hall in 1990 [31] examined a number of myths concerning formal methods, assumed by some to be valid. This paper considers a few more beliefs held by many and presents some counter examples. 1 Introduction Formal Methods continue to grow in popularity; growing numbers of delegates at conferences such as FME ....

....what constitutes a formal method, and how formal methods have been successfully employed in the development of complex systems. Of great concern is the fact that we must place many professional system developers into that latter category. 2 Hall s Original Seven Myths In a seminal article [31], Hall highlights seven popular misconceptions, or myths as he calls them, of formal methods, and attempts to dispel these by means of an example. Regretfully, four years later, these and other misconceptions still abound. Formal methods are unfortunately the subject of extreme hyperbole or deep ....

[Article contains additional citation context not shown here]

Hall, J.A.: Seven Myths of Formal Methods. IEEE Software, 7(5):11--19, September 1990.

No context found.

Anthony Hall. Seven Myths of Formal Methods. IEEE Software, 7(5):11-19 (Sept. 1990).

No context found.

Anthony Hall. Seven Myths of Formal Methods. IEEE Software, 7(5):11-19 (Sept. 1990).

No context found.

A. Hall, "Seven myths of formal methods," IEEE Software, vol. 7, no. 5, pp. 11 -- 19, 1990.

No context found.

Hall, A. (1990). Seven myths of formal methods. IEEE Software, 7(5).

No context found.

J.A. Hall. Seven Myths of Formal Methods. IEEE Software, pages 11--19, September 1990.

No context found.

J.A. Hall. Seven myths of formal methods. IEEE Software, 7(5):11-19, 1990.

No context found.

J. Anthony Hall. Seven Myths of Formal Methods. IEEE Software, 7(5):11{ 19, September 1990. 14

No context found.

A. Hall. Seven Myths of Formal Methods. IEEE Software, September 1990.

No context found.

J. A. Hall. Seven myths of formal methods. IEEE Software, 7(5):11--19, September 1990.

No context found.

A. Hall. Seven myths of formal methods. IEEE Software, pages 11--19, September 1990.

No context found.

A. Hall, Seven Myths of Formal Methods, IEEE Software, 7, 5, pp. 11-19, 1990

No context found.

Anthony Hall. Seven myths of formal methods. IEEE Software, 7(5):11--19, September 1990.

No context found.

Anthony Hall. Seven myths of formal methods. IEEE Software, 7(5):11--19, September 1990.

No context found.

A. Hall. "Seven myths of formal methods," IEEE Software Vol. 7, No. 5, 1990, pp. 11-19.

No context found.

A. Hall. Seven myths of formal methods. IEEE Computer, pages 11--20, September 1990.

No context found.

A. Hall, "Seven Myths of Formal Methods," IEEE Software (Sept., 1990).

No context found.

Hall, A. (1990). Seven myths of formal methods. IEEE Software, 7(5).

No context found.

A. Hall, Seven myths of formal methods, IEEE Software 7: 5, Sep 1990, 11#19.

No context found.

Hall, A., "Seven Myths of Formal Methods," IEEE Software, Vol. 7, No. 5, Sept. 1990, pp. 11-19.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC