Figure 2 - uploaded by Andy Galloway
Content may be subject to copyright.
Source publication
This paper describes the intermediate results of a project to develop automated, high integrity, software verification and validation techniques for aerospace applications. Automated specification validation and test case generation are made possible by the targeted use of formal methods. Specifically, the restricted domain of use is exploited to r...
Similar publications
Abstract Many approaches to software verification require to check the satisfiability of first-order formulae. For such techniques, it is of crucial importance to have satisfiability solvers which are both scalable, predictable and flexible. We describe our approach to build solvers satisfying such requirements by combining equational theorem provi...
Software verification and validation (V&V) methodologies were investigated for high integrity systems. The effort was jointly sponsored by the Nuclear Regulatory Commission and the Electric Power Research Institute as a precursor to official nuclear regulatory guidance. The technology is dual-use; both the nuclear and defense communities will benef...
Citations
... We summarize: checking the determinism of a DEVS model is performed by checking whether all the preconditions are pairwise distinct. Formally this is traduced by [21]: If the behavior of a component is defined as a set of operations {Op 1 , Op 2 , ..., Op n } over the inputs and state, then a conjecture on the determinism of the specification of that component can be formulated as follows: ...
... The Z operations corresponding to "δ ext (src, e, ?x1) = trg1 if Cond1" and "δ ext (src, e, ?x2) = trg2 if Cond2" are given above. Formally, checking completeness is performed by checking the following theorem for each group of operations having the same source state [21]: If the behavior of a component is defined as a set of operations {Op 1 , Op 2 , ..., Op n } over the inputs and the same source state phase, then a conjecture on the completeness of the specification of that component can be formulated as follows: ...
... As emphasised in a position paper [11] that motivated the work described here, software engineering tools for building software that is both correct and robust do exist. They include formal verification and validation (V&V), design by contract, and quality assurance [9, 48, 52]. However, for self-adaptive software, the three properties listed above must continue to hold as the software evolves to adapt to change. ...
The demand for cost effectiveness and increased flexibility has driven the fast-paced adoption of software systems in areas where requirement violations may lead to financial loss or loss of life. Many of these software systems need to deliver not only high integrity but also self adaptation to the continual changes that characterise such application areas. A challenge long solved by control theory for continuous-behaviour systems was thus reopened in the realm of software systems. Software engineering needs to embark on a quest for self-adaptive high-integrity software. This paper explains the growing need for software capable of both self-adaptation and high integrity, and explores the starting point for the quest to make it a reality. We overview emerging techniques for the engineering of self-adaptive high-integrity software, propose a service-based architecture that aims to integrate these techniques, and discuss opportunities for future research.
... Many textbooks on Z are now available (e.g., [Jac97]) and Z is taught on many university computer science courses [Bow01]. Concerning software testing, the Z notation has been used to derive tests from model-based specifications [CaS94,StC96], for the testing of abstract data types (modules, classes, package, clusters) [Hay86], automatic test case generation [BCG00,BCM00], and the selection of test cases and evaluation of test results [Hor95]. So, when Z is used for software development and testing, it is expedient to use testing criteria that have also been formulated in Z. ...
This chapter describes an approach to the formalization of existing criteria used in computer systems software testing and proposes a Reinforced Condition/Decision Coverage (RC/DC) criterion. This criterion has been developed from the well-known Modified Condition/Decision Coverage (MC/DC) criterion and is more suitable for the testing of safety-critical software where MC/DC may not provide adequate assurance. As a formal language for describing the criteria, the Z notation has been selected. Formal definitions in the Z notation for RC/DC, as well as MC/DC and other criteria, are presented. Specific examples of using these criteria for specification-based testing are considered and some features are formally proved. This characterization is helpful in the understanding of different types of testing and also the correct application of a desired testing regime.
... One of the aims of this paper will be to illustrate the benefits of using the PFS method in modelling the discrete aspects of software used in control systems [7]. The PFS project [7][8][9][10] arose out of a desire to apply formal techniques to the development of software systems in a way that augmented the established development practices rather than replacing them. The tool support for PFS builds on the Matlab/Simulink/Stateflow toolset, which is used widely in control system development. ...
... Having identified the DSRs for this example, it is important to specify them formally. There are various documented techniques such as Douglass' real-time annotations [24], Object Constraint Language (OCL) [10], etc. suitable for specifying safety contracts on operations. The SSA tool extends the notation of Stateflow Conditions to allow reference to preceeding values of inputs and outputs (to capture differential information). ...
Where software systems are safety critical, for example in aircraft engine control, it is necessary to carry out safety analysis on designs in support of certification. We argue that there is also significant value in formally validating such a design. Few “classical” formal notations and methods are geared towards embedded systems. We illustrate one such method known as Practical Formal Specification (PFS), showing how it can be integrated in a UML context with various forms of safety analysis. The PFS method was developed to extend classical approaches in the development of embedded software systems in a way that adds engineering value, and fits into existing well-established frameworks. We exemplify the approach to model the reverse thrust selection function of the thrust reversal system of a turbo-jet engine.
... In the larger context of formal verification, it appears that techniques and tools for constraint solving, equivalence class analysis, and test generation specifications can be useful in addition to theorem provers and model checkers [29]. ...
The term "Model based design and development" has grown in popularity over the past decade. Within the embedded avionics community the term model based design implies the development and application of "control models and simulations" within tools such as MATLAB. At Honeywell, the authors have been engaged in model based development (MBD) and associated tools development for avionics applications. This position paper applies the lessons learned and discusses several issues, relating to sound model-based design, to meet design assurance and certification objectives. The paper examines the dominant approaches utilized by some of the popular model-based design, code generation and verification tool suites available commercially. It contrasts these approaches to traditional software design, implementation, and verification methods. This paper also recommends taking a broader perspective of MBD and suggests adopting lessons learned from the classical software engineering arena. We discuss this together with areas for future investigation, standardization, and automation tool development and integration.
... [14][15]. These techniques can use heuristics [2], which can optimize the generation of test data. @BULLET Dynamic techniques, used for white box tests [10]. ...
Many software applications produced today have a component, of lesser or greater importance to the structure, that is based on database management systems. What is more, this information is generally handled through SQL queries embedded in the application code. However, automatic software testing is normally associated with the testing of programs implemented in imperative and structured languages. The problem arises when it comes to unifying software tests in programs that manage databases using SQL. The aim of this paper is to get closer to a measurement of the coverage of SQL statements and to show how, using this measurement, we might change the testing databases by means of completing or deleting information which provides improvements to the measurement, in order to achieve the highest possible percentage of coverage of the statements which have access to the database.
... One often cited problem concerning such techniques based is a marked reluctance of engineers to write formal descriptions. Approaches that map automatically from a " safe subset " of engineering-friendly graphical notations (e.g., Statecharts) to provide a formal and processable intermediate description (e.g., using the Z notation) are a promising avenue to follow [13, 12] . The principal challenge , and one we cannot ignore, would appear to be scala- bility. ...
Formal methods have traditionally been used for specification and development of software. However there are potential benefits for the testing stage as well. The panel session associated with this paper explores the usefulness or otherwise of formal methods in various contexts for improving software testing. A number of different possibilities for the use of formal methods are explored and questions raised. The contributors are all members of the UK FORTEST Network on formal methods and testing. Although the authors generally believe that formal methods are useful in aiding the testing process, this paper is intended to provoke discussion. Dissenters are encouraged to put their views to the panel or individually to the authors.
... The techniques described in this paper were used as part of a large case study to develop part of an aircraft electronic engine controller software application (described in more detail in [6]). A Z specification was automatically generated from around 100 pages of semi-formal (state-based and tabular) requirements with supporting text. ...
Software verification and validation forms the single largest cost component in safety-critical software intensive systems. The minimal requirement when verifying or validating a safety critical system is a correct and testable specification that is unambiguous, consistent and complete. There are few frameworks currently available that provide all three properties. The SpecTRM Level 3 model is a black box Boolean specification of system behavior that is unambiguous, complete, consistent and testable. The syntax and semantics of SpecTRM-RL (Specification Toolkit for Requirements Modeling Requirements Language) are clearly specified, allowing us automate test case generation. In the paper, we present a three-stage architecture for test case generation. Test data generation is carried out using the inputs specification in the model to partition the input domain. Test data selection is based on impact of the test case on the outcome of the Boolean formulae that comprise the specification. The executability of the model is exploited by using it as an oracle to determine pass-fail criteria.
... One often cited problem concerning such techniques based is a marked reluctance of engineers to write formal descriptions. Approaches that map automatically from a " safe subset " of engineering-friendly graphical notations (e.g., Statecharts) to provide a formal and processable intermediate description (e.g., using the Z notation) are a promising avenue to follow [13, 12] . The principal challenge , and one we cannot ignore, would appear to be scala- bility. ...
Formal methods have traditionally been used for specification and development of software. However there are potential benefits for the testing stage as well. The panel session associated with this paper explores the usefulness or otherwise of formal methods in various contexts for improving software testing. A number of different possibilities for the use of formal methods are explored and questions raised. The contributors are all members of the UK FORTEST Network on formal methods and testing. Although the authors generally believe that formal methods are useful in aiding the testing process, this paper is intended to provoke discussion. Dissenters are encouraged to put their views to the panel or individually to the authors.
... La automatización de la prueba del software, para programas escritos en leguajes imperativos, se puede estudiar desde varios puntos de vista en función del tipo de pruebas que se van a realizar: caja blanca o caja negra [15]. Existen diversos estudios y técnicas aplicados a programas escritos en leguajes imperativos que permiten la creación automatizada de casos de prueba: técnicas aleatorias [16]; técnicas estáticas que utilizan ejecución simbólica [5], programación lógica de restricciones [14], y lenguajes de especificación Z y VDML-SL [12] y pueden utilizar heurísticos [1] que optimicen la generación de casos de prueba; técnicas dinámicas que ejecutan los programas instrumentados previamente [8] tratando de probar la cobertura del código y pueden utilizar técnicas metaheurísticas [3] como algoritmos genéticos aplicables a cobertura de ramas [7][11][18] y a cobertura de caminos [9] y como recocido simulado [21]; por último técnicas que resultan de una combinación de las estáticas y de las dinámicas [17][6]. ...
La tarea de las pruebas del software puede mejorarse con su automatización, utilizando diferentes técnicas en función del criterio de la prueba. Normalmente, esta automatización se aplica para probar programas implementados en leguajes imperativos y estructurados. Sin embargo, el software desarrollado puede tener acceso a bases de datos mediante código SQL embebido en la aplicación. En este artículo se establece una forma de medir la cobertura de sentencias SQL utilizando el concepto de cobertura de múltiple condición, que se aplica tradicionalmente a los programas imperativos, para su posterior uso en la automatización del proceso de pruebas en software escrito en lenguaje SQL.
