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:
- Abstraction: a means to define a family concretely as a parameterized constructor of instances, by composition of fragments relative to simple, aggregate, optional, and multivalued parameters (corresponding to decisions) and expressed using the other 4 types of construct recursively.
- Substitution: a means to express that part of the content of instances either is common and thus fixed or comes from parameters and differs accordingly.
- Selection: a means to express that part of the content of instances differs based on predicates over parameter values.
- Repetition: a means to express that part of the content of instances is repeated in accordance with the number and ordinality of a multivalued parameter's value.
- Instantiation: a means to express that part of the content of instances is an instance of a family defined by an abstraction and to express the parameters that indicate which instance is needed.
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:
- Leverage in providing many more need-specific parts without all the effort of individual handcrafting.
- Simpler and much lower resource needs for parts storage.
- Easy access through a repository to previously unavailable components.
- More diversity with less need to create solutions that conform to capabilities of available components created for other uses.
- Less need for detailed or deep expertise in all aspects of a type of problem and its solutions.
- Substantially lower cost and errors in tailoring to specific needs.
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:
- Retrieve a candidate set of components that approximate some needed capability.
- Select the component from the candidate set that most closely matches the specific need.
- 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.
- Deciding whether an appropriate component exists requires indeterminate effort, potentially linear to the number of components available or dependent on unreliable content matching or concept indexing techniques.
- Choosing among similar components requires detailed comparative analyses of the components.
- Tailoring a component to meet slightly different needs can violate unstated developer assumptions resulting in errors; failure to tailor or remove unneeded capabilities results in inefficient or bloated code.
- Every minor adaptation of a reusable component creates a new candidate for reuse resulting in uncontrolled growth in repository size and complexity.
In contrast, a procedure for reuse based on Adaptable Components consists of two steps:
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:
- From a taxonomy of provided Adaptable Components, select the Adaptable Component, if any, of which the needed reusable component should be an instance.
- Consistent with the particular needs, if possible, resolve the decisions associated with the selected Component, mechanically retrieving the corresponding reusable component.
- The thought that goes into abstracting similar reusable components into an Adaptable Component leads naturally into the identification of a hierarchy of well-defined categories that substantially reduces the effort of identifying the existence, or non-existence, of components appropriate to a particular need.
- An Adaptable Component establishes a certain level of standardization, retaining essential diversity but avoiding unnecessary redundancy that would exist in separately represented components and eliminating non-essential differences which arise when different people develop components that provide similar capabilities.
- Part of creating an Adaptable Component is envisioning future alternative uses that would be a natural extension of any existing set of similar components. This increases the likelihood that an Adaptable Component will support each developer's particular needs without additional tailoring of a derived component.
- The differences among the set of components represented by an Adaptable Component are formalized as a set of decisions that indicate the diversity represented. These decisions characterize alternative uses for a component and are a sufficient basis for identifying a particular component for retrieval.