Murali Sitaraman

Model Variables: Cleanly Supporting Abstraction in Design By Contract

In design by contract (DBC), assertions are typically written using program variables and query methods. The lack of separation between program code and assertions is confusing, because readers do not know what code is intended for use in the program and what code is only intended for specification purposes. This lack of separation also creates a potential runtime performance penalty, even when runtime assertion checks are disabled, due to both the increased memory footprint of the program and the execution of code maintaining that part of the programs state intended for use in specifications. To solve these problems, we present a new way of writing and checking DBC assertions without directly referring to concrete program states, using ‘model’, i.e. specification‐only, variables and methods. The use of model variables and methods does not incur the problems mentioned above, but it also allow one to write more easily assertions that are abstract, concise, and independent of representation details, and hence more readable and maintainable. We implemented these features in the runtime assertion checker for the Java Modeling Language (JML), but the approach could also be implemented in other DBC tools. Copyright

Performance specification of software components

Component-based software engineering is concerned with predictability in both functional and performance behavior, though most formal techniques have typically focused their attention on the former. Reasoning about the (functional or performance) behavior of a component-based system must be compositional in order to be scalable. Compositional performance reasoning demands that components include performance specifications, in addition to descriptions of functional behavior. Unfortunately, as explained in this paper, classical techniques and notations for performance analysis are either unsuitable or unnatural to capture performance behaviors of generic software components. They fail to work in the presence of parameterization and layering. The paper introduces elements of a compositional approach to performance analysis using a detailed example. It explains that performance specification problems are so basic that there are unresolved research issues to be tackled even for the simplest reusable components. These issues must be tackled by any practical proposal for sound performance reasoning. Only then will software developers be able to engineer new systems by choosing and assembling components that best fit their performance (time and space) requirements.

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.

Part I: the RESOLVE framework and discipline: a research synopsis

In a nutshell, RESOLVE software components are just parameterized modules. A typical specification module defines formally the structural interface and functional behavior of an encapsulated abstract data type (ADT) and associated operations whose parameters are of that type and other types. A typical implementation module describes how such a type is represented as a composition of other ADTs and how the associated operations are effected by invoking sequences of operations associated with the types used in the representation.

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.

Recasting algorithms to encourage reuse

Instead of viewing algorithms as single large operations, the authors use a machine-oriented view to show how they can be viewed as collections of smaller objects and operations. Their approach promises more flexibility especially in making performance trade-offs, and encourages black-box reuse. They recommend black-box reuse because the real value of reused code lies in its properties, such as correctness with respect to an abstract specification. If you make even small structural or environmental changes, the confidence in these properties tends to evaporate, and with it most of the components value. They show how to design an entire category of more flexible black-box reusable software components by applying a general design technique that recasts algorithms as objects. To illustrate the technique, they recast a sorting algorithm and a spanning-forest algorithm into objects.<<ETX>>

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.

On the practical need for abstraction relations to verify abstract data type representations

The typical correspondence between a concrete representation and an abstract conceptual value of an abstract data type (ADT) variable (object) is a many-to-one function. For example, many different pointer aggregates give rise to exactly the same binary tree. The theoretical possibility that this correspondence generally should be relational has long been recognized. By using a nontrivial ADT for handling an optimization problem, the authors show why the need for generalizing from functions to relations arises naturally in practice. Making this generalization is among the steps essential for enhancing the practical applicability of formal reasoning methods to industrial-strength software systems.

Specification engineering and modular verification using a web-integrated verifying compiler

This demonstration will present the RESOLVE web-integrated environment, which has been especially built to capture component relationships and allow construction and composition of verified generic components. The environment facilitates team-based software development and has been used in undergraduate CS education at multiple institutions. The environment makes it easy to simulate “what if” scenarios, including the impact of alternative specification styles on verification, and has spawned much research and experimentation. The demonstration will illustrate the issues in generic software verification and the role of higher-order assertions. It will show how logical errors are pinpointed when verification fails. Introductory video URL: http://www.youtube.com/watch?v=9vg3WuxeOkA.

Specification and reasoning in SE projects using a Web IDE

A key goal of our research is to introduce an approach that involves at the outset using analytical reasoning as a method for developing high quality software. This paper summarizes our experiences in introducing mathematical reasoning and formal specification-based development using a web-integrated environment in an undergraduate software engineering course at two institutions at different levels, with the goal that they will serve as models for other educators. At Alabama, the reasoning topics are introduced over a two-week period and are followed by a project. At Clemson, the topics are covered in more depth over a five-week period and are followed by specification-based software development and reasoning assignments. The courses and project assignments have been offered for multiple semesters. Evaluation of student performance indicates that the learning goals were met.