Synthesis Leveraged Domain Engineering
PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES
The Product Architecture Activity is an activity of the Product Design Activity
for creating a Product Architecture.
An architecture, for a given work product, is one or more design structures
that define the internal organization of that work product from different
perspectives. Similarly, a Product Architecture is a description of the
internal organization of a
product family. A Product Architecture includes the architecture of each of
the work product families that make up the product family. A Product
Architecture varies according to the decisions supported by the
product family's Decision Model. A Product Architecture describes a
standardized architecture for all members of a
product family in a domain. By applying the decisions that characterize a
particular
product to the Product Architecture, a standardized architecture of that
product is produced.
For each required application
work product family (requirements, design, code, etc.), one design structure
must identify a set of Adaptable Components. Application engineers compose
instances of these components to create a
an instance of the
work product. Depending on which design method domain engineer's follow, they
may also create other structures which provide other views of the behavior or
interrelationships of components. In all cases, the structures are in an
adaptable form so that Application Engineering can use them to produce any
member of the indicated product family.
The objective of the Product Architecture Activity is to define an adaptable
architecture for products that can be produced in Application Engineering.
Product Architecture is the design of solutions to the problems that Product
Requirements describe.
The Product Architecture Activity requires the following information:
-
Product Requirements
-
Legacy Products
The Product Architecture Activity requires domain and software knowledge and
experience in:
-
The principles and use of
an appropriate software
design method used to create members of the work product family (e.g.,
ADARTS
[Software Productivity Consortium 1993])
-
How systems in the domain are designed and documented following chosen design
and documentation methods
-
Typical engineering tradeoffs that must be balanced when designing systems in
the domain
-
The concepts and practice of metaprogramming (
Campbell 1989)
-
- Name:
-
Product Architecture
- Purpose:
-
The Product Architecture describes the internal organization of members of the
application engineering work product family.
- Content:
-
The Product Architecture consists of design structures for the each
application work product.
One of the structures must identify the components that make up each of the
members of the work product family. Each structure consists of:
-
A set of design elements
-
A relation that associates elements
For example, a software requirements specification document is one type of
application engineering work product. The domain engineers might choose
sections of requirements documents as design elements, and "subsection" as the
relation among these elements. This describes the structure of a software
requirements specification document in enough detail to allow its composition
from its constituent elements. The structures developed for a particular
domain depend on the particular application work products and the design method
used to produce them.
Although the Product Architecture for a particular
product may contain multiple design structures, there must be one structure
that describes the decomposition of the
product into work assignments (e.g., modules, sections). The elements of this
structure correspond to components that are to be implemented by Adaptable
Components.
The only difference between the design structures specified in the Product
Architecture and those specified in a conventional design is that the Product
Architecture is parameterized and adaptable, so that it describes the family of
products in the domain.
- Form and Structure:
-
The form for each structure of a Product Architecture is a textual or graphic
network of elements and relations. This representation is then augmented with
a suitable technology such as metaprogramming notation to parameterize the
structure for adaptation to variations.
Examples
DE.2.2.4.1-1 Fragment of TLC Product Architecture,
DE.2.2.4.1-2 Fragment of TLC Product Architecture,
and
DE.2.2.4.1-3 Fragment of TLC Product Architecture
illustrate fragments of a Product Architecture for the TLC domain (i.e.,
fragments of the static software architecture for the product family, process
structure architecture for the product family, and an architecture for a
DOD-STD-2167A Interface Requirements Specification document work product
family, respectively). Multiple structures are needed to fully describe the
architecture of the software and documentation for the product family. Notice
that the Product Architecture of the document is expressed as an annotated
outline where each numbered heading (e.g., 1. Scope) corresponds to a section
of the work product. Preceding each architecture are the decisions that
parameterize the respective architecture. The content of these architectures
will vary depending on values chosen for the respective decisions. For
example, in Example DE.2.2.4.1-3, Section 3.3 will be included only when
parameter crosswalk is true. Otherwise, this section is omitted.
- Verification Criteria:
-
-
Each Product Architecture structure satisfies the verification criteria
established by the specific design method used in its creation.
-
The Product Architecture defines all structures for the software and other work
products required by the Application Engineering process.
The Product Architecture Activity consists of two steps shown in
Figure DE.2.2.4.1-1.Product Architecture Process.
These steps are performed for the Product Architecture Activity.
Step: Identify Work Product Components
-
- Action:
-
Develop a structure that describes, as a structured set of components, the
internal organization of the
products in the family.
- Input:
-
-
Product Requirements
-
Legacy Products
- Result:
-
Product Architecture: Internal Organization
- Heuristics:
-
-
The Process Requirements define the required standards for the development of
each work product. For software, Process Requirements define which design
method is to be followed, which in turn determines the design structures
required. Using ADARTS, there are three structures: Information Hiding,
Process, and Dependency. For documentation, an annotated outline, in which each
section and subsection is listed as a component, is normally sufficient as the
design for the work product. For test and delivery support, a hierarchical
structure is needed that characterizes each test case or delivery function as a
component.
-
Each work product is broken down, or decomposed, into a set of components so
that the work may be performed independently by multiple component
implementors. Using a chosen design method, a structure must be created that
determines this decomposition. Using ADARTS, the Information Hiding Structure
determines a suitable decomposition into components.
-
Each structure is parameterized by a set of decisions that characterize how it
is adapted to represent a particular system. A parameterized structure defines
a family of structures. The set of structure families must be parameterized
consistently, both with each other and with the Product Requirements. The
content of each structure must be consistent with the Product Requirements.
-
Analyze Legacy Products; look for recurring patterns in their design
structures. Recurring patterns suggest portions of a structure that do not
vary.
-
Use the Product Requirements to determine what characteristics are common to
all systems in the domain. These characteristics should correspond to common
structures identified in the analysis of Legacy Products.
-
Each structure must be adaptable to requirements and design variations among
systems. Parameterize the structure to characterize required variations. Use
a metaprogramming notation to record the effects of variations. For example, a
conditional statement referencing a variation indicates that a portion of a
structure is included only for some systems.
Step: Develop Other Structures
-
- Action:
-
Create any other structures required to define the work product fully.
- Input:
-
-
Product Requirements
-
Legacy Products
- Result:
-
Product Architecture: Alternate Structures
- Heuristics:
-
-
The chosen design method for software identifies other required design
structures. Using ADARTS, these design structures are the Process Structure
and the Dependency Structure. Hypertext-based documents would have an analogous
alternative structure.
-
Alternate structures impose constraints on the implementation of each component
of the internal organization. The design method characterizes these
constraints.
-
Each structure must support a subset of the same variations. The internal
organization determines how these variations affect each component. Component
variations must account properly for variations in relevant parts of the
alternate structures.
-
- Risk:
-
The Product Architecture will not support all features or variations in Product
Requirements.
- Implication:
-
The Product Architecture is not a correct solution to the Product Requirements.
- Mitigation:
-
Review the Product Architecture with developers of the Product Requirements and
experienced designers. Establish traceability of all required features to
elements of the architecture. Evaluate whether variations that characterize
different
products lead to proper architectural variations.
-
- Contingency:
-
The Product Requirements are incomplete, ambiguous, or inconsistent.
- Source:
-
Product Requirements Activity
- Response:
-
Describe the inadequacies in the Product Requirements. Proceed with Product
Architecture, 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 Product Architecture 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:
-
Suggestions are made for Product Architecture 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
Domain Specification was completed.
- Source:
-
-
Product Implementation Activity
-
Process Support Development Activity
- Response:
-
-
Revise the Product Architecture.
-
Refer to Domain Management for future planning.
-
Reject the changes due to conflicts with the Domain Definition.
- Contingency:
-
The Product Architecture does not satisfy the Product Requirements.
- Source:
-
Domain Verification Activity
- Response:
-
Modify the Product Architecture to be consistent with the Product Requirements.
- Contingency:
-
The Product Architecture is incomplete, ambiguous, or inconsistent.
- Source:
-
-
Product Implementation Activity
-
Generation Design Activity
-
Component Design Activity
- Response:
-
Refine the Product Architecture to correct inadequacies.
