PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES

DE.2.2.4.2. Component Design

Getting Started

The Component Design Activity is an activity of the Product Design Activity for creating a Component Design. The Product Architecture identifies a set of Adaptable Components that are required to implement the work products of a product family. A Component Design is a design specification for one of these Adaptable Components. A set of Component Designs defines a library of Adaptable Components that may be adapted and composed to implement the work products of the product family. Each component must be designed to satisfy relevant aspects of the Product Requirements and all design structures of the Product Architecture.

Objectives

The objective of the Component Design Activity is to produce a design for an Adaptable Component that satisfies applicable Product Requirements in accordance with its role in the Product Architecture.

Required Information

The Component Design Activity requires the following information:

• Product Requirements
• Product Architecture
• Legacy Products

Required Knowledge and Experience

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

• How components of systems in the domain are designed
• The principles and use of an appropriate design method
• The concepts and practice of abstraction-based reuse ( Parnas 1976; Campbell 1989)

PRODUCT DESCRIPTION

Name:

Component Design

Purpose:

A Component Design is a specification for an Adaptable Component that can be used to construct an application or associated work product.

Content:

Each Component Design represents a family of components. A Component Design consists of two parts:

• Adaptation Specification. The Adaptation Specification for an Adaptable Component describes the ways that the component can be tailored via a set of parameters. Each parameter has a name and type to indicate its range of variations. Constraints identify invalid combinations of parameter variations.
• Interface Specification. The Interface Specification describes the desired characteristics of the implementation of the component. The exact content of the interface specification is particular to the component type and the design method used. To describe the entire family, the interface specification is parameterized with respect to the variations in the Adaptation Specification.

Form and Structure:

The Adaptation and Interface Specifications each include textual and tabular information. The form of an Adaptation Specification is the same for all types of components and includes the following information:

• Name. Name of the Adaptable Component.
• Instantiation Parameters. Adaptation parameters for the component, including the name, type, and description of each parameter.
• Instantiation Constraints. Constraints on the instantiation of the Adaptable Component (e.g., constraints on the legal combination of parameter values).

The interface part of Adaptable Components is different for software and documentation. The content of the software interface is specific to the design method(s) used to create the members of the family. The following types of information are examples: definitions of interface programs (names, parameters, parameter types, returned values), definitions of exported types, descriptions of the effects of interface programs, assumptions about the environment in which the software is to be used.

The interface for a documentation component does not require the same type of detailed information. It consists of a brief statement of the content of the component.

---

Component Design - Determine Schedule

This module determines the traffic light sequence schedule based on mode 
transition rules defined in the requirements document.  

    Adaptation Specification 

        Instantiation Parameters 
            schedule list of composite of: 
                                                start : (0:00 .. 23:59) 
                                                end: (0:00 .. 23:59) 
                                                name: identifier 
                                                .... 

        Instantiation Constraints 
         - There must be at least one schedule transition in the schedule 
list.  

    Interface Specification 
        Concrete Operations 
            determine_schedule_transition Determines the traffic light 
                                            sequence schedule that the TLC 
                                            system should follow next and 
                                            returns the appropriate indicator.  
            current_schedule Returns the current schedule the 
                                            TLC system following 
        .... 

---

Example DE.2.2.4.2-1. Fragment of TLC Component Design

Example DE.2.2.4.2-1 illustrates a fragment of a Component Design for the TLC domain. This design corresponds to one of the adaptable components identified in the Product Architecture shown in Example DE.2.2.4.1-1. The Adaptation Specification defines the adaptation parameters for this adaptable component. The Interface Specification is parameterized, where appropriate, in terms of these adaptation parameters.

Verification Criteria:

• The Component Design satisfies the verification criteria established by the specific design method(s) used for its creation.
• The Component Design satisfies all structures of the Product Architecture.
• The value for each parameter in an Adaptation Specification either is derivable from the Decision Model or has a fixed, default value for all instances of the component family.

PROCESS DESCRIPTION

The Component Design Activity consists of two steps shown in Figure DE.2.2.4.2-1 Component Design Process.

Procedure

Follow these steps for the Component Design Activity. Domain engineers perform these steps for each Adaptable Component defined in the internal organization of the Product Architecture.

Step: Define Component Adaptation Specification

Action:

Identify the variations that parameterize the Adaptable Component, and record constraints on legal combinations.

Input:

• Product Architecture
• Product Requirements
• Legacy Products

Result:

Component Design: Adaptation Specification

Heuristics:

• Identify components in the Product Architecture that have the same form in all instances of the domain. These components have no associated variations (i.e., they are not adaptable). You must still provide an interface specification, but you may omit the Adaptation Specification.
• The adaptation specification of a component may be determined by identifying which roles the component must serve in the design, determining which adaptations are required so that it can fulfill these roles, and devising a set of parameters that can be used to indicate desired adaptations.
• Examine Legacy Products to determine variations. Concentrate on semantic, rather than syntactic, distinctions. However, unless you are willing to reengineer work products, you may need to define variations based on syntactic distinctions as well.
• Determine necessary component adaptations by analyzing the Product Requirements to see how the component must vary to satisfy relevant requirements. In practice, you should try to use both approaches.
• Decisions that parameterize components must derive from, but need not be, the decisions identified in the Decision Model. In general, there is a many-to-many relationship between Decision Model decisions and Component Design parameters. You may use whatever decisions most naturally specify variations among members of the family defined by an Adaptable Component.

Step: Specify Component Interface

Action:

Specify the requisite properties for the implementation of each component.

Input:

• Product Architecture
• Component Design: Adaptation Specification

Result:

Component Design: Interface Specification

Heuristics:

The properties that you must specify depend on the type of component and the design method used. Parameterize each component interface with the decisions from the component's adaptation specification so that it describes all instances of the component.

Risk Management

None

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:

The Product Requirements are incomplete, ambiguous, or inconsistent.

Source:

Product Requirements Activity

Response:

Describe the inadequacies in the Product Requirements. Proceed with Component Design, and document any assumptions made regarding the inadequate portions of the Product Requirements.

Contingency:

The Domain Plan cannot be satisfied with available technical capabilities.

Source:

Domain Management Activity

Response:

Propose (alternative) revisions to the Domain Plan that better match available capabilities. Complete a Component Design that satisfies the Domain Plan as closely as possible.

Contingency:

The practices and procedures specified in the Domain Plan are either ineffective or inefficient.

Source:

Domain Management Activity

Response:

Describe the ways in which the practices and procedures are either ineffective or inefficient. Propose revisions to the practices and procedures to make them more effective.

Contingency:

The Product Architecture is incomplete, ambiguous, or inconsistent.

Source:

Product Architecture Activity

Response:

Describe the inadequacies in the Product Architecture. Proceed with Component Design, and document any assumptions made regarding the inadequate portions of the Product Architecture.

4.2 Feedback From Product Consumers

Contingency:

Suggestions are made for Component Design changes to exploit unforeseen opportunities. For example, a situation where substantial software is made available for use in the Domain Implementation that was not available when the Component Design was completed.

Source:

• Product Implementation Activity
• Process Support Development Activity

Response:

• Revise the Component Design.
• Refer to Domain Management for future planning.
• Reject the changes due to conflicts with the Domain Definition.

Contingency:

The Component Design does not satisfy the Product Requirements.

Source:

Domain Verification Activity

Response:

Modify the Component Design to be consistent with the Product Requirements.

Contingency:

The Component Design is incomplete, ambiguous, or inconsistent.

Source:

• Component Implementation Activity
• Generation Design Activity

Response:

Refine the Component Design to correct inadequacies.