Adaptable Components

Generating customized software for flexible reuse

In DsE, the basic unit of construction is the component. Components are combined to form work products and work products are aggregated to form a product. An Adaptable Component is a unified representation of a set of similar components that can each be used for the same purpose. The purpose of the Adaptable Component is to provide easy rapid access to specifically tailored components, for reuse in a new product or to modify an existing product in response to changed needs. Associated with each Adaptable Component is a set of decisions that distinguish among the represented components, along with a mechanism for deriving any of the represented instance components by resolution of these decisions.

An Adaptable Component can be created to express the form and content of any type of software-related artifact, including specifications, plans, code, documentation, or test materials. A set of related Adaptable Components can be instantiated to create or modify a needed work product. A collection of architecturally integrated Adaptable Components is sufficient for systematic derivation of complete products.

The Adaptable Components Tutorial provides detailed guidance on the development and use of Adaptable Components.

Metaprogramming Text Processor is a notation and tool that supports defining text-based Adaptable Components and mechanically deriving customized instance components.

Sample Adaptable Components presents examples of how MTP-represented Adaptable Components are defined and used.

The motivation for Adaptable Components is to represent reusable software in a form that makes comprehensive need-specific tailoring implicit to retrieval of each needed component. In this way, storage of reusable components is highly efficient, with each Adaptable Component implicitly representing an arbitrarily large number of retrievable instance components. This expressive efficiency enables a simple tree-structured repository, based on a concept abstraction hierarchy that logically organizes a set of Adaptable Components. Accordingly, the repository search problem is reduced to a top-down traversal to locate a specific Adaptable Component. An Adaptable Component repository can be comprehensive yet relatively small (tens or hundreds of entries), enabling retrieval of components that had not existed in the particular form before being derived in the retrieval.

The differences that motivate a need for different components are formalized as a set of decisions. The set of decisions taken together are sufficient to distinguish any single component uniquely. An Adaptable Component representation provides for expressing the concrete differences in the retrievable components in terms of the decision set. An associated mechanism enables the derivation of a particular component when a reuser resolves the set of decisions to represent a specific need.

A complete notation for representing a set of similar components as an Adaptable Component provides five types of construct:

Together, these constructs provide the means to define decision-parameterized abstractions that effectively represent the derivable set of components. Derivation of specific instance components is mechanical and easily automated.

Adaptable Components provide benefits to both component developers and reusers. For developers, they provide:

For reusers, they provide:

The effort to develop and evolve an Adaptable Component over its lifetime is planned to be no more than 2-3 times the cost of developing a single component. This effort is justified when there is a need over time either for several such components or for several changes to one such component due to unclear or changing needs. Experience indicates that the lifetime cost of a well-considered Adaptable Component will not be greater than the lifetime cost of a corresponding single component due primarily to avoiding the usual costs of predictable but unplanned modifications.

To better understand the use of Adaptable Components, consider first a canonical procedure, consisting of 3 steps, appropriate for a conventional approach to reuse:
  1. Retrieve a candidate set of components that approximate some needed capability.
  2. Select the component from the candidate set that most closely matches the specific need.
  3. Tailor the selected component to all aspects of the specific need.

This procedure presumes a library of reusable components from which developers retrieve needed parts. It presents several problems:

This model is too weak, requiring an inefficient procedure of reuse and providing too little benefit to justify the associated cost to provide components or subsequent effort to use them.

In contrast, a procedure for reuse based on Adaptable Components consists of two steps:

  1. From a taxonomy of provided Adaptable Components, select the Adaptable Component, if any, of which the needed reusable component should be an instance.
  2. Consistent with the particular needs, if possible, resolve the decisions associated with the selected Component, mechanically retrieving the corresponding reusable component.
This procedure does not guarantee that a developer will find a needed reusable component but it guarantees that the effort to determine success or failure is very low. An Adaptable Component repository provides a capability that effectively addresses the problems associated with the conventional model of reuse. This capability derives from the essential nature of an Adaptable Component as a coherent representation of a set of similar reusable components. In contrast to the problems of a conventional model of reuse: