PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES
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 form a draft application engineering work product.
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.
The Component Implementation Activity requires the following information:
The Component Implementation Activity requires domain and software knowledge and experience in:
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:
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:
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:
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 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.
Pedestrian Lanes with Push Buttons (TLC-PL-PB-1)Purpose: The purpose of this segment is to provide the functionality needed by the controller segment to manage the pedestrian lane indicators at the intersection considering the input provided by the trip mechanism.
Description: The segment is composed of those functions needed to turn on and off the walk and don't walk indicators present in the pedestrian lanes of the intersection.The functions needed to read and reset the pedestrian lanes' push buttons are also contained in this segment.The pedestrian lanes' push buttons assume a < COMP_interface > interface to the traffic light indicators.
System Capabilities: ....
....
< if COMP_blinking_rate = yes then >
The TLC system shall be capable of setting the blinking rate associated with the walk-don't walk indicators at the pedestrian lanes.
< endif >....
Example DE.3.1.1-1. Fragment of the TLC Component Implementation for the System/Segment Specification Work Product Family
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 work product 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.
Follow these steps for the Component Implementation Activity.
Step: Design the
Component's Internal Structure
Step: Implement the Component
Step: Verify the Component
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 Management
INTERACTIONS WITH OTHER ACTIVITIES
Feedback to Information Sources
Feedback From Product Consumers