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#

An applicative language called HOPE is described and discussed. The underlying goal of the design and implementation effort was to produce a very simple programming language which encourages the construction of clear and manipulable programs. HOPE does not include an assignment statement; this is felt to be an important simplification. The user may freely define his own data types, without the need to devise a complicated encoding in terms of low-level types. The language is very strongly typed, and as implemented it incorporates a typechecker which handles polymorphic types and overloaded operators. Functions are defined by a set of recursion equations; the left-hand side of each equation includes a pattern used to determine which equation to use for a given argument. The availability of arbitrary higher-order types allows functions to be defined which 'package' recursion. Lazily-evaluated lists are provided, allowing the use of infinite lists which could be used to provide interactive input/output and concurrency.

The first part of this paper provides rigorous definitions for several basic concepts underlying the design of dependable programs, such as specification, program semantics, exception, program correctness, robustness, failure, fault, and error. The second part investigates what it means to handle exceptions in modular programs structured as hierarchies of data abstractions. The problems to be solved at each abstraction level, such as exception detection and propagation, consistent state recovery and masking are examined in detail. Both programmed exception handling and default exception handling (such as embodied for example in recovery blocks or database transactions) are considered. An assessment of the adequacy of backward recovery in providing tolerance of software design faults is made. An earlier version of this paper was published in "Dependability of Resilient Computers", T. Anderson, Editor, BSP Professional Books, Blackwell Scientific Publications, UK, 1989, pp. 68-97 INTRO...

We present a compositional program logic for call-by-value imperative higherorder functions with general forms of aliasing, which can arise from the use of reference names as function parameters, return values, content of references and part of data structures. The program logic

George Santayana's statement, "Those who cannot remember the past are condemned to repeat it, " is only half true. The past also includes successful histories. If you haven't been made aware of them, you're often condemned not to repeat their successes. In a rapidly expanding field such as software engineering, this happens a lot. Extensive studies of many software projects such as the Standish Reports offer convincing evidence that many projects fail to repeat past successes. This paper tries to identify at least some of the major past software experiences that were well worth repeating, and some that were not. It also tries to identify underlying phenomena influencing the evolution of software engineering practices that have at least helped the author appreciate how our field has gotten to where it has been and where it is. A counterpart Santayana-like statement about the past and future might say, "In an era of rapid change, those who repeat the past are condemned to a bleak future. " (Think about the dinosaurs, and think carefully about software engineering maturity models that emphasize repeatability.) This paper also tries to identify some of the major sources of change that will affect software engineering practices in the next couple of decades, and identifies some strategies for assessing and adapting to these sources of change. It also makes some first steps towards distinguishing relatively timeless software engineering principles that are risky not to repeat, and conditions of change under which aging practices will become increasingly risky to repeat.

Data Types and Software Validation ," Communications of the ACM, Vol. 21, No. 12, 1978, pp. 1048-1064.

This paper introduces a mechanism for asserting invariants that are maintained by a program that uses atomic memory transactions. The idea is simple: a programmer writes check E where E is an expression that should be preserved by every atomic update for the remainder of the program’s execution. We have extended STM Haskell to dynamically evaluate check statements atomically with the user’s updates: the result is that we can identify precisely which update is the first one to break an invariant.

Software engineering refers to the process of creating software systems. It applies loosely to techniques which reduce high software cost and complexity while increasing reliability and mochfiability. This paper outlines the procedures used in the development of computer software, emphasizing large-scale software development, and pmpomtmg areas

Software engineering research and programming language design have enjoyed a symbiotic relationship, with traceable impacts since the 1970s, when these areas were first distinguished from one another. This report documents this relationship by focusing on several major features of current programming languages: data and procedural abstraction, types, concurrency, exceptions, and visual programming mechanisms. The influences are determined by tracing references in publications in both fields, obtaining oral histories from language designers delineating influences on them, and tracking cotemporal research trends and ideas as demonstrated by workshop topics, special issue publications, and invited talks in the two fields. In some cases there is conclusive This article has been developed under the auspices of the Impact Project. The aim of the project is to provide a scholarly study of the impact that software engineering research—both academic and industrial—has had upon practice. The principal output of the project is a series of individual papers covering the impact upon practice of research in several selected major areas of software

. In this report, we describe a pragmatic, rigorous integration of the mathematical specification language Z with well-known object modeling notations and an object-oriented variant of statecharts. The goal is to preserve the abstraction and flexibility of widely-used design notations while being able to embed the precision and rigor of mathematical specification at selected places. The integration between the notations is based on a mapping between entities of the three models. Table of Contents 1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1 1.1 The Modeling Notations . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 The Integration Approach . . . . . . . . . . . . . . . . . . . . . . 4 2 A Small Case Study : : : : : : : : : : : : : : : : : : : : : : : : : : 5 2.1 Architectural Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Reactive Model of TwoHandPress Class . . . . . . . . . . . . . . 8 2.3 Functional Model . . . . . . . . . . . . ...