No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
Dear Sir, Yours faithfully: an Everyday Story of Formality
Abstract
The paper seeks a perspective on the reality of Formal Methods in industry today. What has worked; what has not; and what might the future bring? We show that where formality has been adopted it has largely been benefical. We show that formality takes many forms, not all of them obviously “Formal Methods”.
... Despite the long interest in formal validation methods, "It seems that practitioners judge formal methods to be insufficiently beneficial to outweigh pragmatic problems" [24]. According to Amey [25], "Customers are often 'aghast' at the idea of formal methods being used to develop their products and might say 'couldn't you use UML?'" Amey [25] suggests overcoming such prejudices through "formality by stealth" and cites semantically strengthened UML as an example [24]. ...
... Despite the long interest in formal validation methods, "It seems that practitioners judge formal methods to be insufficiently beneficial to outweigh pragmatic problems" [24]. According to Amey [25], "Customers are often 'aghast' at the idea of formal methods being used to develop their products and might say 'couldn't you use UML?'" Amey [25] suggests overcoming such prejudices through "formality by stealth" and cites semantically strengthened UML as an example [24]. ...
... The code is processed (17) to be compared with the set of codes (18, 19, 20, and 21). When the code is found, the percentage of discount is calculated (22) and, together with the price (23), is processed to calculate the payment (24) and invoice (25). ...
A conceptual model is used to support development and design within the area of systems and software modeling. The notion of validation refers to representing a domain in a model accurately and generating results using an executable model. In UML specifications, validation verifies the correctness of UML diagrams against any constraints and rules defined within the model. Currently, significant research has been conducted on generating test sets to validate that UML diagrams conform to requirements. UML activity diagrams are a specific focus of such efforts. An activity diagram is a flexible instrument for describing a system s behaviors and the internal logic of complex operations. This paper focuses on the notion of validation using activity diagrams and contrasts that process with a proposed method that involves an informal validation procedure. Accordingly, this informal validation involves comparing requirements to specifications expressed by a diagram of a modeling language called thinging machine (TM) modeling. The informal validation is a type of model checking that requires the model to be small enough for the verification to be done in a limited space or time period. In the proposed method, the model diagram is divided into subdiagrams to achieve this purpose. We claim the TM behavioral model comes with a particular dispositional structure that allows a designer to carve a model into smaller components for informal validation, which is shown through two case studies.
... Despite the long interest in formal validation methods, "It seems that practitioners judge formal methods to be insufficiently beneficial to outweigh pragmatic problems" [24]. According to Amey [25], "Customers are often 'aghast' at the idea of formal methods being used to develop their products and might say 'couldn't you use UML?'" Amey [25] suggests overcoming such prejudices through "formality by stealth" and cites semantically strengthened UML as an example [24]. ...
... Despite the long interest in formal validation methods, "It seems that practitioners judge formal methods to be insufficiently beneficial to outweigh pragmatic problems" [24]. According to Amey [25], "Customers are often 'aghast' at the idea of formal methods being used to develop their products and might say 'couldn't you use UML?'" Amey [25] suggests overcoming such prejudices through "formality by stealth" and cites semantically strengthened UML as an example [24]. ...
... The code is processed (17) to be compared with the set of codes (18, 19, 20, and 21). When the code is found, the percentage of discount is calculated (22) and, together with the price (23), is processed to calculate the payment (24) and invoice (25). ...
A conceptual model is used to support development and design within the area of systems and software modeling. The notion of validation refers to representing a domain in a model accurately and generating results using an executable model. In UML specifications, validation verifies the correctness of UML diagrams against any constraints and rules defined within the model. Currently, significant research has been conducted on generating test sets to validate that UML diagrams conform to requirements. UML activity diagrams are a specific focus of such efforts. An activity diagram is a flexible instrument for describing a system's behaviors and the internal logic of complex operations. This paper focuses on the notion of validation using activity diagrams and contrasts that process with a proposed method that involves an informal validation procedure. Accordingly, this informal validation involves comparing requirements to specifications expressed by a diagram of a modeling language called thinging machine (TM) modeling. The informal validation is a type of model checking that requires the model to be small enough for the verification to be done in a limited space or time period. In the proposed method, the model diagram is divided into subdiagrams to achieve this purpose. We claim the TM behavioral model comes with a particular dispositional structure that allows a designer to "carve" a model into smaller components for informal validation, which is shown through two case studies.
... Peter Amey [29] presented what he called the reality of formal methods and described a series of cases of successful software development. He inquired why, despite its utility, the approach still was not widely used in industry, and he concluded that it was because, typically, they were trying to use development at inopportune times. ...
In 1987, Michael Jackson presented his work "Power and Limitations of Formal methods for software fabrication" at the AIT Conference, which analyzed the advantages and limitations of formal methods up to that time. His conclusion was that formal methods had undoubted capabilities and advantages, but they also had serious limitations that prevented their widespread acceptance and adoption. The aim of this paper is to present the current context of formal methods compared with what Jackson described three decades ago. A tour of the strengths and limitations of formal methods is taken through a review of literature in the timeline of the past thirty years. The conclusion is that little progress has been made on this issue in relation to the situation presented by Jackson, and formal methods still need more work from academia, industry and the community. Povzetek: Prispevek analizira napredek formalnih metod s primerjavo z Jacksonovo metodo izpred trideset let.
... UML is a widely accepted design format and many customers of software systems may expect to see it being used, whereas formal methods is often seen as being unnecessary and costly. In the work carried out by Amey [2] it was reported that customers of software systems often did not like the idea of formal methods being used, with some customers asking "couldn't you use UML?". ...
The UML-B notation has been created as an attempt to combine the success and ease of use of UML, with the verification and rigorous development capabilities of formal methods. However, the notation currently only supports a basic diagram set. To address this we have, in this project, designed and implemented a set of extensions to the UML-B notation that provide a much fuller software engineering experience, critically making UML-B more appealing to industry partners. These extensions comprise five new diagram types, which are aimed at supplying a broader range of design capabilities, such as conceptual Use-Case design and future integration with the ProB animator tool.
... It is widely recognized that formal methods (FM) technology makes a strong contribution to the verification required for safety-critical systems; indeed, DefStan 00-55 [33] as well as the avionics standards above recommend the use of FM for critical systems. It is further recognized that FM will need to be integrated [5] in as " black-box " as possible a manner -with OOT in order to achieve serious industry penetration. The combination of UML and formal methods therefore offers the promise of improved safety and flexibility in the design of software for aviation certification. ...
We consider the failure detection and management function for engine control systems as an application domain where product line engineering is indicated. The need to develop a generic requirement set - for subsequent system instantiation - is complicated by the addition of the high levels of verification demanded by this safety-critical domain, subject to avionics industry standards. We present our case study experience in this area as a candidate method for the engineering, validation and verification of generic requirements using domain engineering and Formal Methods techniques and tools. For a defined class of systems, the case study produces a generic requirement set in UML and an example system instance. Domain analysis and engineering produce a validated model which is integrated with the formal specification/ verification method B by the use of our UML-B profile. The formal verification both of the generic requirement set, and of a simple system instance, is demonstrated using our U2B, ProB and prototype Requirements Manager tools.
This work is a demonstrator for a tool-supported method which will be an output of EU project RODIN\footnote{This work is conducted in the setting of the EU funded research project: IST 511599 RODIN (Rigorous Open Development Environment for Complex Systems) \texttt{http://rodin.cs.ncl.ac.uk/}.}. The use of existing and prototype formal verification and support tools is discussed. The method, developed in application to this novel combination of product line, failure management and safety-critical engineering, is evaluated and considered to be applicable to a wide range of domains.
... UML is a widely accepted design format and many customers of software systems may expect to see it being used, whereas formal methods is often seen as being unnecessary and costly. In the work carried out by Amey [2] it was reported that customers of software systems often did not like the idea of formal methods being used, with some customers asking "couldn't you use UML?". ...
The UML-B notation has been created as an attempt to combine the success and ease of use of UML, with the verification and rigorous development capabilities of formal methods. However, the notation currently only supports a basic diagram set. To address this we have, in this project, designed and implemented a set of extensions to the UML-B notation that provide a much fuller software engineering experience, critically making UML-B more appealing to industry partners. These extensions comprise five new diagram types, which are aimed at supplying a broader range of design capabilities, such as conceptual Use-Case design and future integration with the ProB animator tool.
... It is widely recognized that formal methods (FM) technology makes a strong contribution to the verification required for safety-critical systems; indeed, DefStan 00-55 [20] as well as the avionics standards above recommend the use of FM for critical systems . It is further recognized that FM will need to be integrated [4] -in as " black-box " as possible a manner -with OOT in order to achieve serious industry penetration. The combination of UML and formal methods therefore offers the promise of improved safety and flexibility in the design of software for aviation certification. ...
We consider the failure detection and management function for engine control systems as an application domain where product line engineering is indicated. The need to develop a generic requirement set - for subsequent system instantiation - is complicated by the addition of the high levels of verification demanded by this safety-critical domain, subject to avionics industry standards.
We present our case study experience in this area as a candidate methodology for the engineering, validation and verification of generic requirements using domain engineering and Formal Methods techniques and tools. For a defined class of systems, the case study produces a generic requirement set in UML and an example instantiation in tabular form. Domain analysis and engineering produce a model which is integrated with the formal specification/ verification method B by the use of our UML-B profile. The formal verification both of the generic requirement set, and of a simple system instance, is demonstrated using our U2B and ProB tools.
This work is a demonstrator for a tool-supported method which will be an output of EU project RODIN. The method, based in the dominant UML standard, will exploit formal verification technology largely as a "black box" for this novel combination of product line, failure management and safety-critical engineering.
... It is widely recognized that formal methods (FM) technology makes a strong contribution to the verification required for safety-critical systems [19] . It is further recognized that FM will need to be integrated [3] in as " black-box " as possible a manner in order to achieve serious industry penetration. The B method of J.-R. ...
We present work in progress on a method for the engineering, validation and verification of generic requirements using domain engineering and formal methods. The need to develop a generic requirement set for subsequent system instantiation is complicated by the addition of the high levels of verification demanded by safety-critical domains such as avionics. Our chosen application domain is the failure detection and management function for engine control systems: here generic requirements drive a software product line of target systems.
A pilot formal specification and design exercise is undertaken on a small (two-sensor) system element. This exercise has a number of aims: to support the domain analysis, to gain a view of appropriate design abstractions, for a B novice to gain experience in the B method and tools, and to evaluate the usability and utility of that method. We also present a prototype method for the production and verification of a generic requirement set in our UML-based formal notation, UML-B, and tooling developed in support. The formal verification both of the structural generic requirement set, and of a particular application, is achieved via translation to the formal specification language, B, using our U2B and ProB tools.
This section of the document describes the proposed HIT diffusion framework based on capabilities. In this section diffusion and adoption theories, software engineering techniques, dynamic capabilities, and multi-perspectives are discussed. In the later sections the model is future reasoned for in the context of modeling, documenting, and simulating it. Various perspectives are discussed and why certain particular design decisions were made.
This paper presents an approach to verify PLCs, a common platform to control systems in the industry. We automatically translate PLC programs written in the languages of the IEC 61131-3 standard to B models, amenable to formal analysis of safety constraints and general structural properties of the application. This approach thus integrates formal methods into existing industrial processes, increasing the confidence in PLC applications, nowadays validated mostly through testing and simulation. The transformation from the PLC programs to the B models is described in detail in the paper. We also evaluate the approach's potential with a case study in a real railway application.
Un des aspects de la securite en informatique concerne le controle des acces aux donnees d'un systeme pour lequel differentes poli- tiques de securite peuventetre mises en application. Toutefois, rien ne sert de mettre en place une politique de securite pour gerer un systeme si les programmes charges de garantir le bon fonctionnement de cette poli- tique ne sont pas fiables. Ne pas apporter de garanties fortes sur la cor- rection de tels programmes reviendraita construire un chateau fort avec une porte en papier. Cet article rend compte de maniere informelle de differentes experiences permettant d'obtenir des developpements formels de politiques de controle d'acces. Ces developpements nous conduisenta introduire un "cadre semantique" dans lequel il est possible de specifier, implanter et comparer des politiques de controle d'acces.
Un des aspects de la securite en informatique concerne le controle des acces aux donnees d'un systeme pour lequel differentes poli- tiques de securite peuventetre mises en application. Toutefois, rien ne sert de mettre en place une politique de securite pour gerer un systeme si les programmes charges de garantir le bon fonctionnement de cette poli- tique ne sont pas fiables. Cet article rend compte de maniere informelle de differentes experiences permettant d'obtenir des developpements formels de politiques de controle d'acces. Ces developpements nous conduisenta introduire un "cadre semantique" dans lequel il est possible de specifier et d'implanter des politiques de controle d'acces. Ce cadre permet de definir des mecanismes de comparaison de modeles et d'analyser ces modeles en termes de flots d'information qu'ils autorisent. Mots cles : Controle d'acces, Methodes formelles
The World Wide Web has rapidly evolved from a simple, page-driven, document-centric platform, in which each client is underpinned by a simple, synchronous request-response model, to a fully application-centric platform in which clients utilize highly interactive User Interfaces (UIs), complex internal interactions, and synchronous and/or asynchronous mechanisms to interact with server resources. At the forefront of the present stage of web evolution is a class of applications called Rich Internet Applications (RIAs). These applications combine the best features of traditional desktop applications, such as partial UI updates and fast UI response times, with the best features of traditional web applications, such as virtual ubiquity and operating system independence. Traditionally, web applications could simply be developed as sequential, event-driven applications in which each event on the user interface of the client is immediately processed on the server; and the result of processing returned as a completely new page to the client. RIAs however, have introduced fine-grained concurrency, non-sequential event-driven semantics, and client-side computation to the client; resulting in a number of challenges. These challenges include:
SESAR, the ‘Single European Sky Air traffic Research’ program, envisages radical changes for European Air Traffic Management (ATM). It integrates and implements new technologies and information processing. This paper examines the safety decision-making in the implementation of SESAR projects. SESAR poses new safety problems because it adopts new paradigms for ATM safety – what lessons are there from environmental, nuclear and defense modeling? These disciplines have also had to confront the limitations of modeling the rates of rare and damaging – even catastrophic – events. A major conceptual change in SESAR is that of automated separation assurance systems. Some existing responsibilities transfer from the controller – either to the pilot or to computer systems – in a progressively phased approach. The major problem for SESAR safety validation is that mixed equipage/operations within a common airspace potentially generate new and different safety issues regarding the validation of safety predictions. A potential way forward uses high-fidelity Human In The Loop Simulations (HITLS) to generate confidence in the resilience of the ATM system. The focus changes from proving safety, i.e. through traditional kinds of validation processes, to extensive resiliencetesting using these simulations. The aim would be to test how resilient the system is to seeded errors, penetration testing, and crash/stress testing. This would be a high cost process because of the large investments required and the need for long sequences of testing. However, these demanding processes can provide ‘justified belief’ to the decision-maker that the changed ATM system is acceptably safe.
This paper examines some aspects of the aims and goals of the RODIN project and asks whether a successful outcome of the project
will remove the need for us to worry about programming languages and the meaning of program source code. In common with some
other currently ascendent approaches to software engineering, such as model-based development, RODIN is leading towards the
construction of software models (in RODIN’s case precise software models) from which we may hope to generate source or even object code. So, does this remove the need for us to be
concerned with the form these automatically-generated, intermediate representations take? Perhaps rather surprisingly, I conclude
that the need to show an unbroken chain of confidence from requirements to object code means that programming languages and
their analysis, remain an extremely important topic. I hope to show that the ability to produce better specifications and
designs, as promised by approaches exemplified by RODIN, is a necessary precondition for effective high-integrity software development rather than a substitute for approaches currently in use.
Modern society depends on computers for a number of critical tasks in which failure can have very high costs. As a consequence, high levels of dependability (reliability, safety, etc.) are required from such computers, including their software. Whenever a quantitative approach to risk is adopted, these requirements must be stated in quantitative terms, and a rigorous demonstration of their being attained is necessary. For software used in the most critical roles, such demonstrations are not usually supplied. The fact is that the dependability requirements often lie near the limit of the current state of the art, or beyond, in terms not only of the ability to satisfy them, but also, and more often, of the ability to demonstrate that they are satisfied in the individual operational products (validation). We discuss reasons why such demonstrations cannot usually be provided with the means available: reliability growth models, testing with stable reliability, structural dependability modelling, as well as more informal arguments based on good engineering practice. We state some rigorous arguments about the limits of what can be validated with each of such means. Combining evidence from these different sources would seem to raise the levels that can be validated; yet this improvement is not such as to solve the problem. It appears that engineering practice must take into account the fact that no solution exists, at present, for the validation of ultra-high dependability in systems relying on complex software.
The paper describes the use of formal development methods on an
industrial safety-critical application. The Z notation was used for
documenting the system specification and part of the design, and the
SPARK subset of Ada was used for coding. However, perhaps the most
distinctive nature of the project lies in the amount of proof that was
carried out: proofs were carried out both at the Z level (approximately
150 proofs in 500 pages) and at the SPARK code level (approximately 9000
verification conditions generated and discharged). The project was
carried out under UK Interim Defence Standards 00-55 and 00-56, which
require the use of formal methods on safety-critical applications. It is
believed to be the first to be completed against the rigorous demands of
the 1991 version of these standards. The paper includes comparisons of
proof with the various types of testing employed, in terms of their
efficiency at finding faults. The most striking result is that the Z
proof appears to be substantially more efficient at finding faults than
the most efficient testing phase. Given the importance of early fault
detection, we believe this helps to show the significant benefit and
practicality of large-scale proof on projects of this kind
This paper describes methods for automatically analyzing formal,
state-based requirements specifications for some aspects of completeness
and consistency. The approach uses a low-level functional formalism,
simplifying the analysis process. State-space explosion problems are
eliminated by applying the analysis at a high level of abstraction;
i.e., instead of generating a reachability graph for analysis, the
analysis is performed directly on the model. The method scales up to
large systems by decomposing the specification into smaller, analyzable
parts and then using functional composition rules to ensure that
verified properties hold for the entire specification. The analysis
algorithms and tools have been validated on TCAS II, a complex,
airborne, collision-avoidance system required on all commercial aircraft
with more than 30 passengers that fly in U.S. Airspace
This work affirms that the quantification of life-critical
software reliability is infeasible using statistical methods, whether
these methods are applied to standard software or fault-tolerant
software. The classical methods of estimating reliability are shown to
lead to exorbitant amounts of testing when applied to life-critical
software. Reliability growth models are examined and also shown to be
incapable of overcoming the need for excessive amounts of testing. The
key assumption of software fault tolerance-separately programmed
versions fail independently-is shown to be problematic. This assumption
cannot be justified by experimentation in the ultrareliability region,
and subjective arguments in its favor are not sufficiently strong to
justify it as an axiom. Also, the implications of the recent
multiversion software experiments support this affirmation
This paper describes a successful project where we used formal methods as an integral part of the development process for
a system intended to meet ITSEC E6 requirements. The system runs on commercially available hardware and uses common COTS software.
We found that using formal methods in this way gave benefits in accuracy and testability of the software, reduced the number
of errors in the delivered product and was a cost-effective way of developing high integrity software. Our experience contradicts
the belief that formal methods are impractical, or that they should be treated as an overhead activity, outside the main stream
of development. The paper explains how formal methods were used and what their benefits were. It shows how formality was integrated
into the process. It discusses the use of different formal techniques appropriate for different aspects of the design and
the integration of formal with non-formal methods.
Formal property verification has been an effective complement to pre-silicon validation of several Intel® Pentium® 4 CPU designs at Intel Corporation. The principal objective of this program has been to prove design correctness rather than hunt for bugs. In the process, we have evolved our tools and methodology and are now applying FPV techniques to protocol level properties. Moving forward, new technologies such as GSTE and SAT offer the potential to significantly increase the scope of what can be formally verified. This paper discusses the application of FPV to validation of the Intel® Pentium® 4 microarchitecture and some approaches being considered to broaden the application of FV techniques, particularly at a higher level of design abstraction.
Praxis Critical Systems recently developed a secure certification authority for smart cards that had to satisfy performance and usability requirements while meeting stringent security constraints. The authors used a systematic process from requirements elicitation through formal specification, user interface prototyping, rigorous design, and coding to ensure these objectives' achievement. They show how a process that achieves normal commercial productivity can deliver a highly reliable system that meets all its throughput and usability goals
Can formal methods be a part of large system development? The
project teams at Praxis used a combination of formal methods to help
specify, design, and verify CDIS, a large information display system
within on ATC support system. Their project suggests that it can be
practicable and beneficial
Seven widely held conceptions about formal methods are challenged. These beliefs are variants of the following: formal methods can guarantee that software is perfect; they work by proving that the programs are correct; only highly critical systems benefit from their use; they involve complex mathematics; they increase the cost of development; they are incomprehensible to clients; and nobody uses them for real projects. The arguments are based on the author's experiences. They address the bounds of formal methods, identify the central role of specifications in the development process, and cover education and training
Anthony Hall Using formal methods to develop an ATC information system
[Hall 1996] Anthony Hall. Using formal methods to develop an ATC information system.
IEEE Software 13(2): pp 66-76, 1996.
High Integrity Software - the SPARK Approach to Safety and Security
- John Bames