RSP gb toc RSP Return Up Down GoTo Synthesis Leveraged Domain Engineering
PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES

DE.2.2.4.3. Generation Design

Getting Started

The Generation Design Activity is an activity of the Product Design Activity for creating a Generation Design. A Generation Design is a specification of production procedures that an application engineer uses to produce deliverable application engineering work products. A Generation Design defines a transformation (or mapping) from an Application Model that describes a product to the equivalent application engineering work products. For each application engineering work product, a Generation Design specifies how to select and adapt Adaptable Components according to decisions in an Application Model and to compose them according to the internal organization of that work product in the Product Architecture. The Generation Design Activity is performed for each work product that comprises the product family specified by the Product Requirements.

Objectives

The objective of the Generation Design Activity is to produce a specification for the production procedures that can be used to produce application engineering work products for a member of a product family through reuse of Adaptable Components. The specification establishes a correspondence between an Application Model and equivalent domain engineering work products that implement the intent of the model correctly.

Required Information

The Generation Design Activity requires the following information:

Required Knowledge and Experience

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

PRODUCT DESCRIPTION

Name:
Generation Design
Purpose:
A Generation Design is a specification for a production procedure for creating deliverable application engineering work products.
Content:
A Generation Design relates the decisions from the Decision Model to the elements of a work product's internal organization defined in the Product Architecture. A Generation Design consists of three mappings:
  • Architecture Mapping. The Architecture Mapping is a description of the relation between decisions in the product family's Decision Model and the decisions of the corresponding adaptable Product Architecture. This mapping describes how values for the Product Architecture's decisions are determined from values of decisions in the Decision Model. As a result, the Architecture Mapping defines the internal organization of a work product that describes a member of the product family based on decisions in the Decision Model (i.e., from an Application Model).
  • Component Mapping. A Component Mapping is a description of the relation of each element of the organizational structure to an Adaptable Component that implements that element. This mapping defines how each component of a work product is to be produced.
  • Decision Mapping. A Decision Mapping is a description of the relation between decisions in the product family's Decision Model and the instantiation parameters in the adaptation specification of a Component Design for each work product component. This relation describes how values for the instantiation parameters are determined from values of decisions in the product family's Decision Model.
Form and Structure:
There is a Generation Design for each supported work product. The Architecture Mapping is represented as a statement for each instantiation parameter of the work product's Product Architecture. The statement contains a pairing between an instantiation parameter and an expression. The expression to determine the value to assign an instantiation parameter is described in terms of decisions in the product family's Decision Model. The expression may involve iteration over a group of decisions or conditional testing of one or more decisions.

The Decision Mapping representation is similar to the Architecture Mapping, except that the instantiation parameters come from the adaptation specification of the Component Design for the work product.

The Component Mapping is represented as a "use" statement. If the expression bracketing the use statement is True, then the use statement describes which Adaptable Component contains the needed implementation. The expression is usually described in terms of decisions in the product family's Decision Model. However, if the Adaptable Component is always used, then an expression of True is sufficient to describe this situation.

Examples DE.2.2.4.3-1 and DE.2.2.4.3-2 illustrate fragments of a Generation Design for the TLC domain. These depict one way of representing the expressions discussed for Architecture, Component, and Decision Mapping. The decisions used the metaprogramming notation come directly from the Decision Model shown in Example DE.2.2.1-1. The parameters on the lefthand side of the "=" statements in the Architecture and Decision Mapping come from Examples DE.2.2.4.1-1, DE.2.2.4.1-3, and DE.2.2.4.2-1, respectively. 




Generation Design - Static Software Architecture for the TLC product family


    Architecture Mapping 
        crosswalk = < if there is a street S that has a Crosswalk_Button = CB 
then > 
                    yes 
                    < else > 
                    no 
                    < endif > 
        .... 


    Component Mapping 
        Determine Schedule 
            use adaptable component Determine_Schedule_Transition 
        .... 


    Decision Mapping 
        Determine_Schedule_Transition 
                schedule = ( < forall S in Fixed_Schedule.Schedule > 
                                    ( start = < S.Start_Time >, 
                                       end = < S.Stop_Time >, 
                                       name = < S.Name >, 
                                       .... ) 
                            < endfor > 
                            ) 
        ....

Example DE.2.2.4.3-1. Fragment of TLC Generation Design 




Generation Design - Interface Requirements Specification work product family


    Architecture Mapping 
        crosswalk = < if there is a street S that has a Crosswalk_Button = CB 
then > yes 
                     < else > no 
                     < endif > 
        light_schedule = < if the Traffic_Light_Controller.Schedule is fixed 
then > fixed 
                         < else > dynamic 
                         < endif > 
        .... 


    Component Mapping 
        .... 


    Decision Mapping 
        ....

Example DE.2.2.4.3-2. Fragment of TLC Generation Design

Verification Criteria:
  • The Generation Design specifies mappings that will produce application work products which exhibit the internal organization specified in the Product Architecture.
  • The Generation Design specifies mappings that produce application work products which satisfy the Product Requirements (i.e., the mappings are consistent with Product Requirements variation).
  • All variabilities allowed by decisions are properly represented as product variations.
  • The effects of variabilities among work products are mutually consistent (i.e., all mappings are consistent).

PROCESS DESCRIPTION

The Generation Design Activity consists of two steps shown in Figure DE.2.2.4.3-1 Generation Design Process.

Procedure

Step: Define Work Product Structure

Action:
Define how decisions in the Decision Model affect the structure of the work product.
Input:
  • Decision Model
  • Product Architecture
Result:
Generation Design: Architecture and Component Mappings
Heuristics:
  • It is sufficient to define the work product structure as a mapping from the Decision Model to the internal organization of the Product Architecture for the work product. The internal organization defines the components that are required to implement the work product. This mapping determines which elements of the Product Architecture are implemented for a particular Application Model.
  • The Product Architecture determines (conditionally and iteratively) how components of each work product are to be derived from Adaptable Components (i.e., the component mapping is provided implicitly by the Product Architecture). The Generation Design should not modify that mapping.
  • Represent this mapping in metaprogramming notation associated with components in the Product Architecture. The mapping is defined in terms of decisions in the Decision Model and determines whether (one or more of) the associated component(s) should be included in the product created for a given Application Model. This mapping is formed by analyzing the Product Architecture and noting conditions that must be true if a particular component is to be included. If a component is always included in the product, metaprogramming notation is not required.
  • Several Adaptable Components might be used to implement a single Product Architecture component, depending on decisions in the Application Model. In this case, use a conditional in the Component Mapping to qualify the association between the Product Architecture and Adaptable Components, thus indicating when a particular Adaptable Component is used.

Step: Define Component Adaptation

Action:
Define a mapping from the decisions in the Decision Model to adaptations of the Adaptable Components referenced by the Component Mapping.
Input:
  • Decision Model
  • Component Design
  • Generation Design: Component Mapping
Result:
Generation Design: Decision Mapping
Heuristics:
When a particular Component Design is to be used to implement a particular component in the Product Architecture, the variability of the Adaptable Component (i.e., its parameterization) must be realized in terms of decisions from the Decision Model. Define the value of each parameter (by name) as a derivation from Decision Model decisions.

Risk Management

Risk:
The Generation Design will not produce correctly-structured work products.
Implication:
Application Production will not produce acceptable application engineering work products.
Mitigation:
Derive work product structures from the Generation Design for Application Models of familiar systems and review the result with experienced engineers to determine whether the result is acceptable.

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:
The Decision Model is incomplete, ambiguous, or inconsistent.
Source:
Decision Model Activity
Response:
Describe the inadequacies in the Decision Model. Proceed with Product Architecture and document any assumptions made regarding the inadequate portions of the Decision Model.

Contingency:
The Product Requirements are incomplete, ambiguous, or inconsistent.
Source:
Product Requirements Activity
Response:
Describe the inadequacies in the Product Requirements. Proceed with Generation 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 Generation 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 Generation Design, and document any assumptions made regarding the inadequate portions of the Product Architecture.

Contingency:
The Component Design for a work product family is incomplete, ambiguous, or inconsistent.
Source:
Component Design Activity
Response:
Describe the inadequacies in the Component Design. Proceed with Generation Design, and document any assumptions made regarding the inadequate portions of the Component Design.

Feedback From Product Consumers

Contingency:
Suggestions are made for Generation 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 Generation Design was completed.
Source:
Generation Implementation Activity
Response:
  • Revise the Generation Design.
  • Refer to Domain Management for future planning.
  • Reject the changes due to conflicts with the Domain Definition.

Contingency:
The Generation Design does not satisfy the Product Requirements.
Source:
Domain Verification Activity
Response:
Modify the Generation Design to be consistent with the Product Requirements.

Contingency:
The Generation Design is incomplete, ambiguous, or inconsistent.
Source:
Generation Implementation Activity
Response:
Refine the Generation Design to correct inadequacies.


PHS