DOMAIN ENGINEERING The intent of domain engineering is to identify, construct, catalog, and disseminate

27.3 DOMAIN ENGINEERING The intent of domain engineering is to identify, construct, catalog, and disseminate

a set of software components that have applicability to existing and future software a set of software components that have applicability to existing and future software

Domain engineering includes three major activities—analysis, construction, and “Domain engineering

dissemination. An overview of domain analysis was presented in Chapter 21. How- is about finding

ever, the topic is revisited in the sections that follow. Domain construction and dis- commonalities

among systems to semination are considered in later sections in this chapter. identify components

It can be argued that “reuse will disappear, not by elimination, but by integration” that can be applied

into the fabric of software engineering practice [TRA95]. As greater emphasis is placed to many systems,

on reuse, some believe that domain engineering will become as important as soft- and to identify

ware engineering over the next decade. program families

that are positioned to take fullest

27.3.1 The Domain Analysis Process

advantage of those In Chapter 21, we discussed the overall approach to domain analysis within the con- components.”

text of object-oriented software engineering. The steps in the process were defined

Paul Clements

as:

1. Define the domain to be investigated.

2. Categorize the items extracted from the domain.

3. Collect a representative sample of applications in the domain.

4. Analyze each application in the sample.

5. Develop an analysis model for the objects. It is important to note that domain analysis is applicable to any software engineer-

ing paradigm and may be applied for conventional as well as object-oriented devel- opment.

Prieto-Diaz [PRI87] expands the second domain analysis step and suggests an eight-step approach to the identification and categorization of reusable components:

1. Select specific functions or objects.

? 2. Abstract functions or objects.

How can we

identify and categorize 3. Define a taxonomy.

reusable

4. Identify common features.

components?

5. Identify specific relationships.

6. Abstract the relationships.

7. Derive a functional model.

8. Define a domain language.

A domain language enables the specification and later construction of applications within the domain.

Although the steps just noted provide a useful model for domain analysis, they provide no guidance for deciding which software components are candidates for reuse. Hutchinson and Hindley [HUT88] suggest the following set of pragmatic ques- tions as a guide for identifying reusable software components:

• ? Is component functionality required on future implementations?

Which

components

• How common is the component's function within the domain?

identified during domain analysis

• Is there duplication of the component's function within the domain?

will be candidates

• Is the component hardware dependent?

for reuse?

• Does the hardware remain unchanged between implementations? • Can the hardware specifics be removed to another component? • Is the design optimized enough for the next implementation? • Can we parameterize a nonreusable component so that it becomes reusable? • Is the component reusable in many implementations with only minor

changes? • Is reuse through modification feasible? • Can a nonreusable component be decomposed to yield reusable components? • How valid is component decomposition for reuse?

An in-depth discussion of domain analysis methods is beyond the scope of this book. For additional information on domain analysis, see [PRI93].