Synthesis Opportunistic Domain Engineering
PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES
The Domain Specification Activity is an activity of Domain Analysis for
creating a Domain Specification. A Domain Specification is a description of the
Application Engineering process for a domain and a definition of a collection
of work product families that support reuse within that process.
The Application Engineering process used by projects in the domain determines
the types of work products whose creation could be supported by reuse.
For targeted application engineering projects, those work products that offer
the greatest opportunities for reuse are designated for formulation as a
family.
A description of a work product family consists of a description of how members
of the family vary,
an abstract of the content of its members, and a specification of the design
(i.e., composition and structure) of its members.
The descriptions of content and design must allow for the diversity among
members indicated by the described variation in the family.
The objectives of the Domain Specification Activity are to:
-
Create a precise specification of the work product families that Domain
Engineering provides to application engineering projects
-
Identify a collection of work product families that will provide targeted
application engineering projects with optimal reuse opportunities within their
existing process
The Domain Specification Activity requires the Domain Definition.
The Domain Specification Activity requires domain and software knowledge and
experience in:
-
Past and current systems in the domain
-
The process that projects in the organization use to construct
application engineering work
projects
-
Creating work products upon which reuse in the domain is to be based; expertise
in what motivates differences in their form and content
-
The concepts and structures that are convenient forms by which to communicate
about the distinguishing features of work products
in the domain
-
- Name:
-
Domain Specification
- Purpose:
-
A Domain Specification is a description of the Application Engineering
process for a domain and a set of work product families that
support reuse in that domain. Domain Specification identifies
a collection of work product families which the targeted project
can reuse (through adaptation and tailoring) to produce individual
work products that meet the needs of its particular customer.
- Content:
-
A Domain Specification consists of one of each of the following components:
-
Decision Model.
A Decision Model
identifies, for each work product family,
the application engineering requirements and engineering decisions that
determine how members of the work
product family can vary (see
Section DE.2.2.1).
A Decision Model has one component for each supported work product family.
-
Product Requirements.
Product Requirements
describe, for each work product family, the abstracted content of the members
of the family (see
Section DE.2.2.2).
Product Requirements have one component for each supported work product
family.
-
Process Requirements.
Process Requirements
describe the established process of Application Engineering within a domain
(see
Section DE.2.2.3).
It identifies the types of work products produced, and the types of work
products for which families may be provided.
-
Product Design.
A Product Design
determines, for each work product family,
the structure and composition of solutions provided by members of the work
product family (see
Section DE.2.2.4).
A Product Design has one component for each supported work product family.
- Verification Criteria:
- Problems and solutions typical both of existing application engineering
work projects and of the needs of the targeted project are adequately addressed
within the perspective of the Domain Specification.
The Domain Specification Activity consists of the
five
steps shown in
Figure DE.2.2-1 Domain Specification Process.
Follow these steps for the Domain Specification Activity.
Activity:
Process Requirements
-
- Action:
- Describe the process and work products of Application Engineering.
- Input:
- Domain Definition
- Result:
- Process Requirements
- Heuristics:
-
-
Identify the types of work products, resulting from the Application Engineering
process, that are normally used by projects in the domain. Make allowance for
any deviations known to be required by the targeted project.
-
Determine how the process of work product development used by individual
application engineers is to be modified to exploit reuse opportunities.
Section AE
provides a description of a typical process modified for reuse.
Step: Identify Work Product
Families
-
- Action:
- Identify work product families targeted as the focus for increasing
opportunities for reuse.
- Input:
- Process Requirements
- Result:
- None
- Heuristics:
-
-
Identify those work product families that offer the best opportunities for
reuse by the targeted application engineering project.
-
A survey of existing work products is the primary basis for determining which
types of work products should be supported with families. Focus the survey on
what is available and what the targeted project will need.
Activity:
Decision Model
-
- Action:
- Define the set of requirements and engineering decisions that an
application engineer must resolve to select an instance from a designated work
product family.
- Input:
- Domain Definition
- Result:
- Decision Model
- Heuristics:
-
-
Perform this step for each designated work product family.
Define the decisions that lead to expected differences among the members of the
family.
-
A Decision Model for a work
product family should reflect the decisions that application engineers had to
make when creating such work
products in previous projects.
-
The Decision Model for a work
product family should reflect the variability assumptions from the Domain
Definition that are relevant to this particular work product family.
-
Ensure that supported decisions are sufficient to distinguish each existing
work
product from other members of the family.
-
Identify logical relationships among the decisions that characterize a work
product family and use them to structure the Decision Model. Such relationships
can reduce the number and complexity of separate decisions that application
engineers have to make.
Activity:
Product Requirements
-
- Action:
- Describe the content, in abstracted form, of the members of a designated
work product family.
- Input:
-
-
Domain Definition
-
Decision Model
- Result:
- Product Requirements
- Heuristics:
-
-
Perform this step for each supported work product family. Describe the content
of family members as briefly as possible without omitting key information.
-
To the degree that application engineering decisions change work product
content, describe how content varies with respect to those decisions. This
description will provide a partial basis for explaining the meaning of
decisions to application engineers.
Activity:
Product Design
-
- Action:
- Define the design (i.e., composition and structure) of the members of a
designated work
product family.
- Input:
-
-
Decision Model
-
Product Requirements
-
Domain Definition: Legacy Products
- Result:
- Product Design
- Heuristics:
-
-
Perform this step for each supported work product family.
Create a design for the work product family
An annotated outline is one model of a Product Design for a document work
product family.
An information hiding structure and process structure from the Ada-based Design
for Real-Time Systems (
ADARTS
) (Software Productivity Consortium 1993) design method are models of a Product
Design for a software work
product family.
-
A key element of domain knowledge is how existing instances of the designated
work
product family are designed. When feasible, derive the initial Product Design
for a family by extracting the design essentials of existing instances. Ensure
that the composition and structure of existing instances are appropriately
reflected in the design.
-
To the degree that Application Engineering decisions change work product
composition and structure, describe how composition and structure vary with
respect to those decisions. This description will provide a further, but still
partial, basis for explaining the meaning of decisions to application
engineers.
-
- Risk:
-
The Domain Specification does not accommodate work products
that meet
the needs of the targeted application engineering project.
- Implication:
- The domain will not provide sufficient opportunities for reuse by the
targeted project.
- Mitigation:
- Compare previously developed application engineering work projects
that should be within supported families
with expected needs of the targeted project.
Check that likely differences are accommodated.
-
- Contingency:
- The Domain Definition is incomplete, ambiguous, or inconsistent.
- Source:
- Domain Definition Activity
- Response:
- Describe the inadequacies in the Domain Definition. Proceed with Domain
Specification, and document any assumptions made regarding the inadequate
portions of the Domain Definition.
- 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 Domain Specification 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 Domain Specification 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:
- Domain Implementation Activity
- Response:
-
-
Revise the Domain Specification.
-
Refer opportunities to Domain Management for future planning.
-
Reject the changes due to conflicts with the Domain Definition.
- Contingency:
- The Domain Specification fails to provide the capabilities required by the
Domain Plan.
- Source:
- Domain Management Activity
- Response:
- Evolve the Domain Specification to be consistent with the Domain Plan.
- Contingency:
- The Domain Specification for a work product family
is incomplete, ambiguous, inconsistent, or incorrect.
- Source:
-
-
Domain Implementation Activity
-
Domain Verification Activity
- Response:
- Refine the Domain Specification to correct any inadequacies.
- Contingency:
- The standardized Application Engineering process for developing
application engineering work projects from a supported work product family
is inefficient or leads to less-than-ideal results for
the targeted project.
- Source:
- Project Support Activity
- Response:
-
Revise
the Application Engineering process to reflect the problems encountered.
conditions of concern."
- Contingency:
-
Supported work
product families are
not useful for the targeted project.
- Source:
- Project Support Activity
- Response:
-
-
Determine that the nature of the problem and the consequent costs of upgrading
the work
product families
outweigh expected benefits to the targeted
project.
-
Evolve the domain engineering work product family to reflect this project's
experience or to be more flexible under the particular conditions of concern.
