William F. Ogden

Reusable software components

Methods and apparatus, including computer program products, implement techniques for structuring applications into reusable components. A reusable component having an external interface and an internal interface is implemented. The component encapsulates functionality, where multiple instances of the component are reusable at the same time. The component is configurable to embed one or more specified components. The external interface comprises an external programming interface, an external data-binding interface, and an external visual interface. The internal interface comprises an embedding interface, an internal programming interface, an internal data-binding interface, and an internal visual interface. The embedding interface specifies one or more component interfaces of components that can be embedded.

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.

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.

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

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.

Modular verification of Ada generics

Abstract This paper develops modular verification rules for Ada generics which are proven to be sound and complete. The generic mechanism in Ada allows modules to be parameterized by types, procedures and functions. The modularity property allows a generic to be verified once, and then exported to other modules which assume that it is correct. This requires the generic to have a specification which is used in verifying other modules, but its implementation cannot be used for this purpose. Thus, modular verification cannot be based on removing generics by macro expansion which requires the use of the generics implementation. The main difficulty with specifying and verifying a generic is that the specification language may need to be extended with a new theory for specifying and reasoning about properties of objects whose type is a parameter to the generic. Such theories must be part of the specification of the generic, and this raises the possibility that the extended specification language may not be expressive, even if it was before the extension. The use of strings in our specification language prevents this from happening, which is proven in the paper; this is a major step toward establishing the completeness of our rules. Modularity also had a large impact on our semantics for programming constructs which is quite different from the usual semantics in the literature, even though it is still based the denotational semantics of Scott and Strachey. The main reason for this is that we had to modify the standard definition of validity. Modularity requires that validity depend on certain internal assertions in a program, such as the precondition of a procedure invoked in the program.

Verification of programs with procedure-type parameters

SummaryA verification system is developed for proving the correctness of programs containing procedures with procedure-type parameters. The system, which reduces programs and their specifications to assertions to be proved in ordinary logic, is shown to be logically sound. The reduction process is controlled by the syntax of the program and is completely mechanical, requiring no human intervention. The resulting assertions involve higher-order predicates, but they engender no significant difficulties which are not already present in ordinary first-order theories.Our system views the intermediate objects in the reduction process as extended programs, thereby making verification a much less abstruse process. Treating logical assertions as commands appeals strongly to a programmers intuition.

Specification of Abstract Data Types in Modula

The programming language MODULA is extended to permit the formal specification of the structure and functional capabilities of modules. This makes true hierarchical programming possible in MODULA by allowing programmers of higher level parts of a system to ignore completely the internal structure of lower level modules and to rely entirely on the specifications of the capabilities of these modules. An example is included to illustrate this technique. We show that our specification mechanisms are sufficiently powerful to support formal verification rules for modules that have disjoint representations for abstract objects.

A Data Abstraction Alternative to Data Structure/Algorithm Modularization

Modularization along the boundaries of data structures and algorithms is a commonly-used software decomposition technique in computer science research and practice. When applied, however, it results in incomplete segregation of data structure handling and algorithm code into separate modules. The resulting tight coupling between modules makes it difficult to develop these modules independently, difficult to understand them independently, and difficult to change them independently. Object-oriented computing has maintained the traditional dichotomy between data structures and algorithms by encapsulating only data structures as objects, leaving algorithms to be encapsulated as single procedures whose parameters are such objects. For the full software engineering benefits of the information hiding principle to be realized, data abstractions that encapsulate data structures and algorithms together are essential.

The location linking concept: a basis for verification of code using pointers

While the use of pointers can be minimized by language mechanisms for data abstraction, alias avoidance and control, and disciplined software development techniques, ultimately, any verifying compiler effort must be able to verify code that makes use of them. Additionally, in order to scale, the verification machinery of such a compiler must use specifications to reason about components. This paper follows a natural question that arises from combining these ideas: can the general machinery of specification-based component verification also be used to verify code that uses instances of types that are more traditionally built-in, such as arrays and pointers? This paper answers the question in the affirmative by presenting a Location_Linking_Template, a concept that captures pointer behavior, and uses it to verify the code of a simple data abstraction realized using pointers. In this deployment, pointers have a specification like any other component. We also note that the concept can be extended and realized so that different systems can plug in alternative implementations to give programmers the flexibility to choose, e.g., manual memory management or automatic garbage collection depending on their performance concerns.