In 1990, Anthony Hall published a seminal article that listed and dispelled seven myths about the nature and application of formal methods. Today - five years and many successful applications later - formal methods remain one of the most contentious areas of software-engineering practice. Despite 25 years of use, few people understand exactly what formal methods are or how they are applied. Many nonformalists seem to believe that formal methods are merely an academic exercise -- a form of mental masturbation that has no relation to real-world problems. The media's portrayal of formal methods does little to help the situation. In many "popular press" science journals, formal methods are subjected to either deep criticism or, worse, extreme hyperbole. Fortunately, today these myths are held more by the public and the computer-science community at large than by system developers. It is our concern, however, that new myths are being propagated, and more alarmingly, are receiving a certain tacit acceptance from the system-development community. Following Hall's lead, we address and dispel seven new myths about formal methods: Formal methods delay the development process; formal methods lack tools; formal methods replace traditional engineering design methods; formal methods only apply to software; formal methods are unnecessary; formal methods are not supported; and formal-methods people always use formal methods.

Abstract not found

For whatever reason, 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.

We address the problem of increasing the impact of formal methods in the practice of industrial computer applications. We summarize the reasons why formal methods so far did not gain widespread use within the industrial environment despite several promising experiences. We suggest an evolutionary rather than revolutionary attitude in the introduction of formal methods in the practice of industrial applications and we report on our long-standing experience which involves an academic institution, Politecnico di Milano, two main industrial partners, ENEL and CISE, and occasionally a few other industries. Our approach aims at augmenting an existing and fairly deeply rooted informal industrial methodology with our original formalism, the logic specification language TRIO. On the basis of the experiences we gained we argue that our incremental attitude towards the introduction of formal methods within the industry could be effective largely independently from the chosen formalism. 1.

this paper, we report on the lessons learned during a study of one such change on the software development process at British Aerospace Systems and Equipment Ltd. (BASE) in the UK. At BASE, there was interest in developing a security-critical system to levels of assurance at which the use of formal specification for modelling the security policy was mandated. The purpose of our study was to provide evidence on the effect of introducing a modest amount of formal specification into an existing development process applied to this system. Note that the study was not an attempt to prove the costeffectiveness or technical value of formal meth1 ods generally. Also, our aim was to introduce a relatively minor "delta" to the development process, so there was no stress on formal proof, our use of a specification language being largely for system and software modelling. The study itself consisted of the parallel development of a system component known as a trusted gateway by two separate teams of engineers. One team employed the conventional BASE development methodology using structured analysis with CASE tool support (referred to as the conventional path below). The other team followed the same design process, but used formal specification wherever it was felt appropriate (referred to as the formal path

This paper introduces and motivates ADL, a new formal notation for the specification of the temporal and functional behaviour of concurrent processes. ADL is tailored to be directly compatible with the DORIS design method. It combines a graphical Activity State-Machine (ASM) notation and a model-based Activity Functional Behaviour (AFB) notation. The abstract syntax, and static and dynamic semantics for the ASM notation are given, the dynamic semantics being given proof-theoretically in many-sorted logic extended with the RTL `occurrence' relation, \Theta , and the ERTL `holding' relation, \Phi. ADL is used to specify a small network, and proofs are given of its timeliness and safety properties. 1 Introduction Safety-critical software (SCS) should be kept simple to ease the demanding task of validating and verifying its behaviour to a sufficent level of confidence. This means that, ideally, SCS should not contain the complexity of concurrency. Unfortunately, concurrency cann...

This paper describes the lessons learned from an application of formal specification techniques in the development of a security-critical system within a UK company. The authors advocate the gradual introduction of formal methods, beginning with an appreciation of existing development processes, and discuss the role played by non-software professionals, executable specifications, formal proof, training and tool support in this and future projects. Keywords: Applications of Formal Methods; Tool Support; Software Process; Training Introduction If formal methods are to be more than an academic toy, experts in the field must develop a fruitful dialogue with commercial systems developers. We believe the best way to begin this is to discuss formal methods with engineers on their own terms, and then build on their experience. Professionals are generally open to techniques which will help them do a better job, but such techniques cannot be introduced at the expense of existing good practice. ...

This report argues that formal methods need to be properly integrated into an architectural design method if they are to be successfully transferred into industrial practice. It outlines a number of issues which need to be considered when performing such integration, and illustrates these points by reference to the formal techniques for complex high-integrity real-time systems being developed in the BAE SYSTEMS Dependable Computing Systems Centre. 1 Introduction Formal specification languages promise the ability to express the behavioural requirements of software systems concisely (and when wisely used, abstractly) in unambiguous notations. Formal specifications form a suitable foundation for system validation by proof and animation, and they define the requirements against which the correctness of a design or implementation can be formally verified. Formal proofs, by removing the role of intuition in interpreting symbols, promise to provide strong evidence for the validation a...

Abstract. Formal methods can help to increase the correctness and trustworthiness of the software developed. However, they do not solve all the problems of software development. This paper analyses some limitations of formal methods. 1.

specification. Describe their functions and constraints ffl Interface design. Precisely define how they fit together ffl Component design. Recursively design each block Source: Sommerville, Software Engineering, 1992 Top-down design involves repeatedly breaking down the problem into smaller components, until their implementation becomes obvious. Interfaces must be precisely defined so that each component can be designed and coded separately. Modifying or replacing a component should not affect the rest of the system provided the component still meets its specification. Other components must not depend on a component's internal variables or data representation. Such information hiding requires programming language support: modules, packages, etc. Many design methods have been promoted. Computer-Assisted Software Engineering (CASE) tools support some of them. They are typically based on graphical notations. The data flow approach tracks data as it moves through the system. The entity-r...