Spec# is the latest in a long line of work on programming languages and systems aimed at improving the development of correct software. This paper describes the goals and architecture of the Spec# programming system, consisting of the object-oriented Spec# programming language, the Spec# compiler, and the Boogie static program verifier. The language includes constructs for writing specifications that capture programmer intentions about how methods and data are to be used, the compiler emits run-time checks to enforce these specifications, and the verifier can check the consistency between a program and its specifications. The Spec#

Abstract not found

this paper is organized as follows. Section 2 presents some related work. Section 3 describes the organization of the system. Section 4 briefly describes the specification language, including some interesting issues that arise when multiple levels of abstraction are present in the system. Section 5 describes the theorem prover. Section 6 describes some of the uses to which ESC has been put. Finally, section 7 presents conclusions and future directions.

Abstract not found

Interface specifications should express program properties in a formal, declarative, and implementation-independent way. To achieve implementation-independency, interface specifications have to support data abstraction. Program verification should enable to prove implementations correct w.r.t. such interface specifications. The presented work bridges the gap between existing specification and verification techniques for object-oriented programs. The integration is done within a formal framework for interface specifications and programming language semantics. Interface specification techniques are enhanced to support the specification of data structure sharing and destructive updating of shared variables. These extensions are necessary for the specification of real life software libraries. Moreover this generalization is needed for intermediate steps in correctness proofs. For verification, Hoare logic is extended to capture recursive classes and subtyping. Based on this extended logic, techniques are presented for proving typing properties, class and method invariants. The new

An overview is presented of the behavioral interface specification language Larch/C++. The features of Larch/C++ used to specify the behavior of C++ functions and classes, including subclasses, are described, with examples. Comparisons are made with other object-oriented specification languages. An innovation in Larch/C++ is the use of examples in function specifications.

In this paper we demonstrate the use of formal methods tools to provide a semantics for the type hierarchy of the AXIOM computer algebra system, and a methodology for Aldor program analysis and verification. We give examples of abstract specifications of AXIOM primitives, and provide an interface between these abstractions and Aldor code. 1 Introduction We describe work in progress at St Andrews to apply formal methods and machine assisted theorem proving techniques to improve the robustness and reliability of computer algebra systems. This project considers the use of the Larch [7] approach to formal methods through specifications and uses AXIOM [8] for the computer algebra system. We do not exclude other formal methods systems such as VDM [9] or Z [13] nor do we exclude applications to other computer algebra systems (CAS) such as Mathematica [17] or Maple [14]. Indeed the weaker type systems used by the latter packages may benefit more from our approach than AXIOM can. In the remai...

We present a technique for automating the discovery of loop invariants based upon the analysis of failed proof attempts. Previously we have shown how failure analysis may be used productively in the search for inductive proofs. This work had direct application to the verification of functional programs. Here we show how these ideas can also play an important role in the formal verification of imperative programs. While presented as an automatic technique we believe that our approach may be easily integrated within an interactive proof environment.

this document, but WEAVE processes only complete documents. We extracted parts in two ways. When we wanted just a few small, closely related parts, we created a special WEB file that held just those parts, and printed it. For something more general, we used a shell script that removed parts of WEAVE's output before passing the rest to TEX. This script recognized the special symbols in the section names so that, for example, we could include or exclude whole chapters by name, without having to enumerate their contents, It would have been more expensive, and no less awkward, to use standard mechanisms for extracting pages from TEX'S output

We describe the problems encountered in the design of Larch/C++, especially its object-oriented features. We discuss a range of possible solutions to these problems, and give the rationale for our particular solutions. We also present examples of Larch/C++ specifications and discuss differences from Larch/C.