Synthesis Opportunistic 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. This activity is performed for each work
product family in the domain.
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 work
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 work
product family's Decision Model. A Product Architecture describes a
standardized architecture for all members of a work
product family in a domain. By applying the decisions that characterize a
particular work
product to the Product Architecture, a standardized architecture of that work
product is produced.
For each required
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 draft
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
a specific work product family.
Product Architecture is the design of solutions to the problems that Product
Requirements describe.
Application engineers create work products by selecting, adapting, and
composing instances of Adaptable Components that Domain Engineering produces.
During Product Architecture, domain engineers identify the structure of each
application engineering work product family in terms of components that
application engineers may produce manually or from Adaptable Components.
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 the
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
-
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
application work
product family.
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 work
product may contain multiple design structures, there must be one structure
that describes the decomposition of the work
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
work
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.
Example
DE.2.2.4.1-1
illustrates a fragment of a Product Architecture for a DOD-STD-2167A
System/Segment Specification document work product family of the TLC domain.
The Product Architecture of this document work product family is expressed as
an annotated outline where each numbered heading (e.g., 1. Scope) corresponds
to a section of the work product. Preceding the annotated outline are the
decisions (e.g., ARCH_pedestrian_lanes) that parameterize the annotated
outline. The content of the annotated outline will vary depending on values
chosen for these decisions. For example, the content of Section 3.2.1.1.j
varies for some family members. In other family members, 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 work
products in the family.
- Input:
-
-
Product Requirements
-
Legacy Products
- Result:
-
Product Architecture: Internal Organization
- Heuristics:
-
-
Examine Legacy Products for components and structural relationships. A work
product usually contains structures that intuitively identify components. A
calling hierarchy is an example for code. In documents, consider basing the
structure around the table of contents, especially if a standard format exists
in the domain (see the following heuristic).
-
Let the design methods used in the Legacy Products guide you. For example,
systems developed using ADARTS include an information hiding hierarchy.
Systems developed using structured design have a functional decomposition.
Documents developed using DOD-STD-2167A have a predefined section
organization.
-
The structures that result from Product Architecture establish a de facto
standard in your organization if none already exists. You should, therefore,
try to use standard organizational formats in the domain, such as those defined
by ADARTS or DOD-STD-2167A. Incorporate any formats that are relevant to the
targeted project.
-
The decisions that parameterize a structure are related to the Decision Model
for the work product family of which the Product Architecture forms a
solution. However, the Decision Model describes the problem space of the work
product family, whereas the Product Architecture is associated with the
solution space of that family. To reflect this difference, you may want to
create parameters that are not in the Decision Model. During the Generation
Design Activity, you will map these parameters to decisions in the Decision
Model.
-
One motivation for creating a Product Architecture is to break down a work
product into a set of components on which subsequent Domain Engineering
activities (Component Design, Component Implementation, Generation Design) can
be performed independently. If the packaging of Legacy Products does not
conform to the internal organization, create one that does.
Step: Develop Other Structures
-
- Action:
-
Create any other structures required to define the
Product Architecture 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 work
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.
-
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.