Wayne D. Heym

Reasoning about Software-Component Behavior

The correctness of a component-based software system depends on the component client’s ability to reason about the behavior of the components that comprise the system, both in isolation and as composed. The soundness of such reasoning is dubious given the current state of the practice. Soundness is especially troublesome for component technologies where source code for some components is inherently unavailable to the client. Fortunately, there is a simple, understandable, teachable, practical, and provably sound and relatively complete reasoning system for component-based software systems that addresses the reasoning problem.

Building a push-button RESOLVE verifier: Progress and challenges

A central objective of the verifying compiler grand challenge is to develop a push-button verifier that generates proofs of correctness in a syntax-driven fashion similar to the way an ordinary compiler generates machine code. The software developer’s role is then to provide suitable specifications and annotated code, but otherwise to have no direct involvement in the verification step. However, the general mathematical developments and results upon which software correctness is based may be established through a separate formal proof process in which proofs might be mechanically checked, but not necessarily automatically generated. While many ideas that could conceivably form the basis for software verification have been known “in principle” for decades, and several tools to support an aspect of verification have been devised, practical fully automated verification of full software behavior remains a grand challenge. This paper explains how RESOLVE takes a step towards addressing this challenge by integrating foundational and practical elements of software engineering, programming languages, and mathematical logic into a coherent framework. Current versions of the RESOLVE verifier generate verification conditions (VCs) for the correctness of component-based software in a modular fashion—one component at a time. The VCs are currently verified using automated capabilities of the Isabelle proof assistant, the SMT solver Z3, a minimalist rewrite prover, and some specialized decision procedures. Initial experiments with the tools and further analytic considerations show both the progress that has been made and the challenges that remain.

Part II: specifying components in RESOLVE

Conceptual modules may export two kinds of things for use in client programs: type families and operation families. We say “families” here because every RESOLVE module is generic, so a client must instantiate a module before using it. Instantiation has two parts: First you bind all of a conceptual module’s formal parameters to actuals which match the formals both in structure and in other specified properties; then you select an implementation for the concept and fix the realization’s (additional) parameters [Part III]. An instance created this way is called a facility. For a typical conceptual module that defines one type family and associated operation families, every instance defines a particular type and some particular operations whose specifications result, in effect, from replacing the formal parameters of the generic specification with the actuals for that instance.

A Language for Building Verified Software Components

Safe and secure reuse is only achievable by deploying formally verified software components. This paper presents essential design objectives for languages for building such components and highlights key features in RESOLVE—a prototype for such languages. It explains why the language must include specifications as an integral constituent and must have clean and rich semantics, which preclude unconstrained aliasing and other unwanted side-effects. In order that arbitrarily complex components can be given concise and verification amenable specifications, an adequate language must also include an open-ended mechanism for incorporating additional mathematical theories. Given these essential characteristics, safe and secure reuse cannot be attained within popular languages, such as C++ or Java, either by constraining them or by extending them. Better languages are necessary.

Traditional assignment considered harmful

Data movement in nearly all modern imperative languages is based on a single primitive: traditional assignment. (With traditional assignment, data are moved between variables by copying.) Unfortunately, traditional assignment poses many known software engineering drawbacks with respect to efficiency for value types, and with respect to modular reasoning for reference types. Moreover, its entrenched legacy has stifled serious regard of potentially superior data-movement primitives. Exploration of the complete design space for data-movement primitives supports the following conclusions: (1) traditional assignment is fundamentally flawed, and (2) any other data-movement primitive would be better.

Issues in performance certification for high-level automotive control software

High-level supervisory control software for automotive applications (e.g., drive-by-wire) presents many challenges to making performance guarantees, which are a necessary part of the softwares certification for deployment. The features of such systems demand that a compositional, or modular, approach to reasoning about performance be devised and applied. We discuss one such analytical approach as an alternative to simulation and testing.