PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES

DE.3.1.1. Component Implementation

Getting Started

Component Implementation is an activity of the Product Implementation Activity for creating an Adaptable Component. A component is any work product fragment (e.g., software, documentation, or verification/validation artifact) produced during the Application Engineering process. An application engineering work product consists of a set of components. An Adaptable Component is a representation of a family of components that satisfies a Component Design (i.e., is adaptable to specified variations). The variability of an Adaptable Component enables application engineers to extract components to be used in creating work products for members of a product family.

Objectives

The objective of the Component Implementation Activity is to implement an Adaptable Component that satisfies a Component Design, consistent with relevant aspects of the Product Requirements and Product Architecture.

Required Information

The Component Implementation Activity requires the following information:

• Product Requirements
• Product Architecture
• Component Design
• Legacy Products

Required Knowledge and Experience

The Component Implementation Activity requires domain and software knowledge and experience in:

• Applicable standards and techniques for design, implementation, and verification of software components
• How to design, implement, and verify components of a work product family given a specification for the family
• The design and implementation of existing systems in the domain

PRODUCT DESCRIPTION

Name:

Adaptable Component

Purpose:

An Adaptable Component is a component (e.g., of software, documentation, verification/validation support) that is adaptable with respect to variations specified in the Component Design.

Content:

An Adaptable Component is an implementation of a family of components. This family is defined by a Component Design, with support by portions of the Product Requirements and Product Architecture. The Component Design characterizes an Adaptable Component by specifying the permissible adaptations of the component, along with the desired characteristics of its implementation.

Form and Structure:

An Adaptable Component is uniquely named and consists of two parts: an adaptability interface and a body.

A component family is characterized by a set of common capabilities and variations in those capabilities. The adaptability interface is a specification of a set of adaptation parameters that provide for the characterization and extraction of a particular instance of a component family.

The body is the sum of the potential implementations of all of the components in the family. The term "potential" is used because the parameters are sufficient to select any component family instance uniquely, but the particular implementation either may not be available or may be extracted from a representation of the family or relevant subfamily. This varies with the mechanism used for implementing adaptability in the Adaptable Component. Three common mechanisms for implementing an Adaptable Component are:

• Physical Separation. Represent members of the component set as physically distinct entities (e.g., in separate files on a computer).
• Target-Language Mechanisms. Use the language-specific facilities to represent different component set members. Ada generics, C++ templates, Interleaf effectivity control, and WordPerfect macro features are examples of target-language mechanisms for representing an Adaptable Component.
• Metaprogramming. Superimpose a language for handling variations on top of the language in which all members of the component set are expressed.

These may be used separately or in combination to implement a particular set of components.

The Booch Ada stack packages ( Booch 1987) are an example of an Adaptable Component. There is a unifying concept of what a stack is and how it works. Different stack components are extracted based on decisions such as:

• Type. The type of data that can be put into the stack.
• Iteration. Whether an indexing mechanism should be available for moving forward and backward through the stack in addition to simply pushing elements onto and popping elements off of the top of the stack.
• Garbage Collection. Whether the stack should manage unused stack space dynamically for later use.
• Bounding. Whether the stack should be bounded in length.

The Booch packages use physical separation to implement 26 different types of stacks. This physical separation approach has the advantage of being simple. If a family has 10 instances, there are 10 implementations and each can be written and verified independently. Physical separation does not take advantage of similarities among the instances, however, nor does it make explicit how variabilities determine the content of each instance.

Ada provides generic packages as a standard facility that you can use to implement a code Adaptable Component whose instances differ only in the values of well-defined placeholders that can be substituted at compile time. The "type" variability of stack packages may be represented using a generic package. The placeholders are parameters defined in the adaptability interface of the Adaptable Component. This approach has the advantage of representing variabilities for the component family more compactly and uniformly; however, only a simple form of parameter substitution is supported.

A metaprogramming approach ( Campbell 1989) uses a preprocessing mechanism to extract a concrete component from an Adaptable Component. This approach embeds target text fragments of a work product (e.g., code, documentation, verification/validation support) with a superimposed metaprogramming notation. The metaprogramming notation specifies how the target fragments are to be combined and adapted, based on the parameters in the adaptability interface of the Adaptable Component. Typical metaprogramming adaptations include:

• Substitution of parameter values
• Conditional inclusion of text fragments
• Repetition of text fragments
• Definition and in-line instantiation of parameterized fragments

This approach provides greater flexibility in representing a component family compactly but results in more complex descriptions. Since many implementations may be derived from a single description, domain engineers must both manually inspect that description and extract and verify representative instances. Example DE.3.1.1-1 Fragment of TLC Component Implementation illustrates a small fragment of a Component Implementation for a work product family of the TLC domain. This example contains a portion of the implementation for the Adaptable Component specified in Example DE.2.2.4.2-1 Fragment of TLC Component Implementation.

Verification Criteria:

• The Adaptable Components implement their specifications as defined in the Product Architecture and Component Designs.
• The Adaptable Components produce the correct variations in concrete components.
• Behaviors or constraints imposed by Product Requirements or Product Architecture on the Adaptable Component are all supported.

PROCESS DESCRIPTION

The Component Implementation process consists of all activities necessary for implementing an Adaptable Component to its Component Design specifications, consistent with relevant parts of the Product Architecture and Product Requirements. This involves the design, implementation, and verification of the family of software, documentation, or test-support components. It may involve the reengineering of existing components of work products from previously built systems. The Component Implementation Activity consists of the three steps shown in Figure DE.3.1.1-1 Component Implementation Process.

Procedure

Follow these steps for the Component Implementation Activity.

Step: Design the Component's Internal Structure

Action:

Create an internal design of the structure and elements of the required Adaptable Component.

Input:

• Component Design
• Product Architecture
• Legacy Products

Result:

• Adaptable Component: Internal design
• Candidate Components

Heuristics:

• The Adaptable Components internal design must satisfy its Component Design specification. The structures of the Product Architecture may impose additional requirements on the internal structure (e.g., for concurrency or level of performance) or define constraints on how other components are used in the implementation.
• Envision how to implement required members of the component's work product family. Create structures, according to the design method used, that characterize the required implementation. Parameterize each structure, if appropriate, with adaptability parameters that vary the structure, as required, for different members of the component family. Consider the required operations of the members.
• Determine whether a suitable component that approximates one of these desired instances is available from Legacy Products. Identify and evaluate the quality of each such component and designate it as a Candidate Component for further use. Determine which Adaptable Component variations are implicitly addressed by this selected Candidate Component.
• Consider whether other Adaptable Components in the Product Architecture can be used to implement all or part of this component family. Components that have complex functionality may be implementable as a composition of instances of other, more primitive components.
• Consider starting with the internal designs of identified Candidate Components. Portions of several candidate components may be used collectively to implement the Adaptable Component. These components may implement different variations that will be required for the family. Characterize which instance of the family corresponds to each component (i.e., by its parameter values). Consider whether each design is sufficiently well-engineered and representative of the family, or at the least of a subfamily, to provide substantial leverage in being refined to represent other variations and the family as a whole. Consider that they may represent different subfamilies that should be structured differently. See if their designs can be unified using variations. Be sure you can still derive each of the components with an acceptable structure.
• Use adaptation mechanisms (e.g., target-language mechanisms, metaprogramming) already present in the existing work products.

Step: Implement the Component

Action:

Elaborate the internal design to implement the Adaptable Component.

Input:

• Adaptable Component: Internal design
• Component Design
• Product Architecture
• Candidate Components
• Legacy Products

Result:

Adaptable Component

Heuristics:

• Fill in the internal structure with the details of the implementation. Keep in mind how the adaptabilities affect the content of the parts of the structure.
• If suitable Candidate Components were used in creating the internal design, then the implementations of those components can be useful as the starting point in implementing the Adaptable Component.
• If another Adaptable Components is to be used in implementing this Component, determine how the adaptability parameters of this Component can be mapped into the parameters of that Component so that its correct instance is derived for a particular instance of this family.
• Parts of the Adaptable Component might have to be engineered from scratch if all elements of the Adaptable Component's implementation cannot be obtained from existing Candidate Components or other Adaptable Component. These areas should be given much greater thought to ensure that you produce the correct content.
• Consider reengineering existing application engineering work products (e.g., Legacy Products) to increase their reusability. For example, you might want to replace arbitrary limits on data structure size with generic parameters. You should consider this if it will relax or remove constraints in your Decision Model. You should take into account any documentation or coding standards for the targeted project when you reengineer existing work products.

Step: Verify the Component

Action:

Verify that the Adaptable Component satisfies all relevant specifications.

Input:

• Adaptable Component
• Component Design
• Product Architecture
• Product Requirements
• Candidate Components

Result:

Verified Adaptable Component

Heuristics:

• Perform rigorous inspection of the Adaptable Component by other experienced engineers. The Component Design, as well as relevant parts of the Product Requirements and Product Architecture, should be verified as being satisfied.
• Derive representative instances of the Adaptable Component and test those instances in a conventional fashion to see if they operate correctly. One part of this activity is the creation of test-case scenarios that can be used in regression testing of the Adaptable Component when it is modified in the future. These scenarios may be made adaptable to the same parameters as the Adaptable Component itself so that a scenario can be derived for a particular test instance.
• Rederive the Candidate Components that influenced the implementation of the Adaptable Component. The original and derived instances can then be compared to see if and how they differ and whether an equivalent result can be produced.
• Use of a Candidate Component may have been based on assurances that the component received with respect to certain desired properties such as correctness, reliability, certification, and trust (in the security sense). Note, however, that modification of the component can invalidate some of these assurances (i.e., certification and trust). It is important to verify that the desired properties are retained when the component is extracted from the resulting Adaptable Component.

Risk Management

Risk:

Certain combinations of adaptability are not fully supported in the Adaptable Component.

Implication:

Work products for some systems will not be derivable using the Component.

Mitigation:

In verifying the Adaptable Component, use bounds-coverage techniques to identify a variety of adaptability combinations in deriving test instances.

Risk:

The effort required to implement all specified adaptabilities for an Adaptable Component is not viable compared to that required to develop concrete components which support a single system development effort.

Implication:

Only a subfamily of the Adaptable Component will be available for production of systems in the domain.

Mitigation:

Implement the variations required for the current systems under development. The development of these variations may require less effort than developing all possible variations and can be refined as additional needs arise. The Adaptable Component can be evolved to a completed state over several development iterations of a system or systems.

Risk:

Determining the value of existing components as a basis for the Adaptable Component will require too much effort (e.g., too many components to search through, too labor intensive to look through complicated components, too difficult to determine whether a component is correctly implemented).

Implication:

Effort to evaluate and reengineer existing components exceeds the effort to create the Adaptable Component from scratch.

Mitigation:

If there are too many existing components to search through to find a good baseline component, limit the amount of effort dedicated to the search, and use the best approximation that results from the limited search.

If looking through complicated components is too labor-intensive, reduce the number of components that will be reviewed. If the component is overly complicated, relying on higher-level documentation (i.e., requirements, high-level design, or testing documentation) of the component as an indicator of its worth may be beneficial. Reviewing documentation on the existing component is likely to take less effort than reviewing code.

If determining the correctness of the component is difficult, then determining correctness from previous test documentation may be sufficient. Reliance on existing components may be greater if engineers are available who developed, or at least used, the existing components.

Risk:

Modifying the baseline component may invalidate assurances of quality that the component possessed (e.g., certification).

Implication:

Modifying a certified component will require that the resulting Adaptable Component must pass, once again, the tests required for assurance of given properties.

Mitigation:

• Concentrate effort on areas of particular concern. If the given properties are less important for the component family as a whole, treat that particular member as a special case (i.e., a component subfamily in its own right). That is, if a component family contains several members, only one of which is certified, define two Adaptable Components, one whose component family contains the certified member and another which contains all the uncertified members.
• Try to retain the essential nature of the baseline component in the Adaptable Component so that proving assurance of given properties is not an expensive process.

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:

The Component Design is incomplete, ambiguous, or inconsistent.

Source:

Component Design Activity

Response:

Describe how the Component Design is inadequate, and suggest how it may be modified. Proceed with Component Implementation as far as possible with the current Component Design.

Feedback From Product Consumers

Contingency:

The Component Implementation does not satisfy the Component Design.

Source:

Domain Verification Activity

Response:

Request clarification of the intent of the Component Design, if necessary. Modify the Component Implementation to satisfy the Component Design.