Steve King

ZB 2002:Formal Specification and Development in Z and B

Alloy: A Logical Modelling Language.- An Outline Pattern Language for Z: Five Illustrations and Two Tables.- Patterns to Guide Practical Refactoring: Examples Targetting Promotion in Z.- Reuse of Specification Patterns with the B Method.- Composing Specifications Using Communication.- When Concurrent Control Meets Functional Requirements, or Z + Petri-Nets.- How to Diagnose a Modern Car with a Formal B Model?.- Parallel Hardware Design in B.- Operation Refinement and Monotonicity in the Schema Calculus.- Using Coupled Simulations in Non-atomic Refinement.- An Analysis of Forward Simulation Data Refinement.- B#: Toward a Synthesis between Z and B.- Introducing Backward Refinement into B.- Expression Transformers in B-GSL.- Probabilistic Termination in B.- Probabilistic Invariants for Probabilistic Machines.- Proving Temporal Properties of Z Specifications Using Abstraction.- Compositional Verification for Object-Z.- Timed CSP and Object-Z.- Object Orientation without Extending Z.- Comparison of Formalisation Approaches of UML Class Constructs in Z and Object-Z.- Towards Practical Proofs of Class Correctness.- Automatically Generating Information from a Z Specification to Support the Classification Tree Method.- Refinement Preserves PLTL Properties.- Proving Event Ordering Properties for Information Systems.- ZML: XML Support for Standard Z.- Formal Derivation of Spanning Trees Algorithms.- Using B Refinement to Analyse Compensating Business Processes.- A Formal Specification in B of a Medical Decision Support System.- Extending B with Control Flow Breaks.- Towards Dynamic Population Management of Abstract Machines in the B Method.

Ravenscar-Java: a high integrity profile for real-time Java

For many, Java is the antithesis of a high integrity programming language. Its combination of object-oriented programming features, its automatic garbage collection, and its poor support for real-time multi-threading are all seen as particular impediments. The Real-Time Specification for Java has introduced many new features that help in the real-time domain. However, the expressive power of these features means that very complex programming models can be created, necessitating complexity in the supporting real-time virtual machine. Consequently, Java, with the real-time extensions as they stand, seems too complex for confident use in high integrity systems. This paper presents a Java profile for the development of software-intensive high integrity real-time systems. This restricted programming model removes language features with high overheads and complex semantics, on which it is hard to perform timing and functional analyses. The profile fits within the J2ME framework and is consistent with well-known guidelines for high integrity software development, such as those defined by the U.S. Nuclear Regulatory Commission.

Is proof more cost-effective than testing?

This 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 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.

CICS Project Report: Experiences and Results from the use of Z in IBM

This paper describes some experiences and results arising from the use of Z in two major projects at the Hursley Park laboratory of IBM 1 United Kingdom Laboratories Ltd. The first project involved the use of Z in the development of a major new release of IBMs transaction processing system CICS 1 (Customer Information Control System), while the second project is a more recent one, concerning the formal specification of the CICS Application Programming Interface (API). The version of CICS which used Z in its development process was released to selected customers on an Early Support Programme in June 1989, and was made generally available in June 1990. Many process measurements were made during the development of the product, and early results show an encouraging improvement in quality, particularly in the parts of the release that were formally specified. The API specification project involved the description of an already existing interface, currently described informally in various manuals in the CICS library. Since this is purely a specification project, no figures are available for the success of the work in terms of reduction of errors, but the motivation for and experiences from the work are described below. Thus this report concentrates on describing results from the use of Z for the development of the CICS product, and experiences from the use of Z for the specification of the CICS API.

Z and the Refinement Calculus

Z has been developed as a formal specification notation, and, as such, has been used successfully for a number of years. Recently, other formal notations, the various flavours of refinement calculi, have emerged. They have been designed as wide spectrum languages to support the whole of the development cycle, from abstract specification through to executable code. We explore the differences between Z and the refinement calculus, and explain the reasons for some of those differences.

Ravenscar-Java: a high-integrity profile for real-time Java

For many, Java is the antithesis of a high‐integrity programming language. Its combination of object‐oriented programming features, its automatic garbage collection, and its poor support for real‐time multi‐threading are all seen as particular impediments. The Real‐Time Specification for Java has introduced many new features that help in the real‐time domain. However, the expressive power of these features means that very complex programming models can be created, necessitating complexity in the supporting real‐time virtual machine. Consequently, Java, with the real‐time extensions as they stand, seems too complex for confident use in high‐integrity systems. This paper presents a Java profile for the development of software‐intensive high‐integrity real‐time systems. This restricted programming model removes language features with high overheads and complex semantics, on which it is hard to perform timing and functional analyses. The profile fits within the J2ME framework and is consistent with well‐known guidelines for high‐integrity software development, such as those defined by the U.S. Nuclear Regulatory Commission. Copyright

Assessment of the Java programming language for use in high integrity systems

This paper sets a goal of investigating the use of Java in the development of high integrity systems. Based on previous studies, guidelines, and standards, we develop 23 criteria that are used for the following assessment of Java. A summary of the assessment is provided before we go on to review a few existing subsets of the language.

Towards an Integrated Model Checker for Railway Signalling Data

Geographic Data for Solid State Interlocking (SSI) systems detail site-specific behaviour of the railway interlocking. This report demonstrates how five vital safety properties of such data can be verified automatically using model checking. A prototype of a model checker for Geographic Data has been implemented by replacing the parser and compiler of NuSMV. The resulting tool, gdlSMV, directly reads Geographic Data and builds a corresponding representation on which model checking is performed using NuSMVs symbolic model checking algorithms.Because of the large number of elements in a typical track layout controlled by an SSI system, a number of optimisations had to be implemented in order to be able to verify the corresponding data sets.We outline how most of the model checking can be hidden from the user, providing a simple interface that directly refers to the data being verified.

The Value of Verification: Positive Experience of Industrial Proof

This 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 which 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 a comparison 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 was substantially more efficient at finding faults than the most efficient testing phase. Given the importance of early fault detection, this helps to demonstrate the significant benefit and practicality of large-scale proof on projects of this kind.

Exits in the refinement calculus

Although many programming languages contain exception handling mechanisms, their formal treatment — necessary for rigorous development — can be complex. Nevertheless, this paper presents a simple incorporation ofexit commands and exception blocks into a rigorous program development method. The refinement calculus, chosen for the exercise, is a method of developing imperative programs. It is based on weakest preconditions, although they are not used explicitly during program construction; they merely justify the general method. In the style of the refinement calculus, program development laws are given that introduce and allow the manipulation ofexits. The soundness of the new laws is shown using weakest preconditions (as for the existing refinement calculus laws). The extension of weakest preconditions needed to handleexits is a variation on earlier work of Cristian; the variation is necessary to handle nondeterminism.