The intent of domain engineering is to identify, construct, catalog, and disseminate a set of software components that have applicability t...
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 in a particular application domain. The overall goal is to establish mechanisms that enable software engineers to share these components—to reuse them—during work on new and existing systems.
Domain engineering includes three major activities—analysis, construction, and dissemination. It can be argued that “reuse will disappear, not by elimination, but by integration” into the fabric of software engineering practice . As greater emphasis is placed on reuse, some believe that domain engineering will become as important as software engineering over the next decade.
The Domain Analysis Process
We discussed the overall approach to domain analysis within the context of object-oriented software engineering. The steps in the process were defined 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 engineering paradigm and may be applied for conventional as well as object-oriented development.
Prieto-Diaz 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.
3. Define a taxonomy.
4. Identify common features.
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 suggest the following set of pragmatic questions as a guide for identifying reusable software components:
• Is component functionality required on future implementations?
• How common is the component's function within the domain?
• Is there duplication of the component's function within the domain?
• Is the component hardware dependent?
• 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?
Characterization Functions
It is sometimes difficult to determine whether a potentially reusable component is in fact applicable in a particular situation. To make this determination, it is necessary to define a set of domain characteristics that are shared by all software within a domain. A domain characteristic defines some generic attribute of all products that exist within the domain. For example, generic characteristics might include the importance of safety/reliability, programming language, concurrency in processing, and many others.
A set of domain characteristics for a reusable component can be represented as {Dp}, where each item, Dpi, in the set represents a specific domain characteristic. The value assigned to Dpi represents an ordinal scale that is an indication of the relevance of the characteristic for component p. A typical scale might be
1: not relevant to whether reuse is appropriate
2: relevant only under unusual circumstances
3: relevant—the component can be modified so that it can be used, despite differences
4: clearly relevant, and if the new software does not have this characteristic, reuse will be inefficient but may still be possible
5: clearly relevant, and if the new software does not have this characteristic, reuse will be ineffective and reuse without the characteristic is not recommended
When new software, w, is to be built within the application domain, a set of domain characteristics is derived for it. A comparison is then made between Dpi and Dwi to determine whether the existing component p can be effectively reused in application w. Table lists typical domain characteristics that can have an impact of software reuse. These domain characteristics must be taken into account in order to reuse a component effectively.
Even when software to be engineered clearly exists within an application domain, the reusable components within that domain must be analyzed to determine their applicability. In some cases (ideally, a limited number), “reinventing the wheel” may still be the most cost-effective choice.
Structural Modeling and Structure Points
When domain analysis is applied, the analyst looks for repeating patterns in the applications that reside within a domain. Structural modeling is a pattern-based domain engineering approach that works under the assumption that every application domain has repeating patterns (of function, data, and behavior) that have reuse potential. Pollak and Rissman describe structural models in the following way:
Structural models consist of a small number of structural elements manifesting clear patterns of interaction. The architectures of systems using structural models are characterized by multiple ensembles that are composed from these model elements. Many architectural units emerge from simple patterns of interaction among this small number of elements.
Each application domain can be characterized by a structural model (e.g., aircraft avionics systems differ greatly in specifics, but all modern software in this domain has the same structural model). Therefore, the structural model is an architectural style that can and should be reused across applications within the domain.
McMahon describes a structure point as “a distinct construct within a structural model.” Structure points have three distinct characteristics:
1. A structure point is an abstraction that should have a limited number of instances. Restating this in object-oriented jargon , the size of the class hierarchy should be small. In addition, the abstraction should recur throughout applications in the domain. Otherwise, the cost to verify, document, and disseminate the structure point cannot be justified.
2. The rules that govern the use of the structure point should be easily understood. In addition, the interface to the structure point should be relatively simple.
3. The structure point should implement information hiding by isolating all complexity contained within the structure point itself. This reduces the perceived complexity of the overall system.
As an example of structure points as architectural patterns for a system, consider the domain of software for alarm systems. This domain might encompass systems as simple as SafeHome (discussed in earlier chapters) or as complex as the alarm system for an industrial process. In every case, however, a set of predictable structural patterns are encountered:
• An interface that enables the user to interact with the system.
• A bounds setting mechanism that allows the user to establish bounds on the parameters to be measured.
• A sensor management mechanism that communicates with all monitoring sensors.
• A response mechanism that reacts to the input provided by the sensor management system.
• A control mechanism that enables the user to control the manner in which monitoring is carried out.
Each of these structure points is integrated into a domain architecture.
It is possible to define generic structure points that transcend a number of different application domains :
• Application front end—the GUI including all menus, panels and input and command editing facilities.
• Database—the repository for all objects relevant to the application domain.
• Computational engine—the numerical and nonnumerical models that manipulate data.
• Reporting facility—the function that produces output of all kinds.
• Application editor—the mechanism for customizing the application to the needs of specific users.
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 engineering paradigm and may be applied for conventional as well as object-oriented development.
Prieto-Diaz 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.
3. Define a taxonomy.
4. Identify common features.
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 suggest the following set of pragmatic questions as a guide for identifying reusable software components:
• Is component functionality required on future implementations?
• How common is the component's function within the domain?
• Is there duplication of the component's function within the domain?
• Is the component hardware dependent?
• 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?
Characterization Functions
It is sometimes difficult to determine whether a potentially reusable component is in fact applicable in a particular situation. To make this determination, it is necessary to define a set of domain characteristics that are shared by all software within a domain. A domain characteristic defines some generic attribute of all products that exist within the domain. For example, generic characteristics might include the importance of safety/reliability, programming language, concurrency in processing, and many others.
A set of domain characteristics for a reusable component can be represented as {Dp}, where each item, Dpi, in the set represents a specific domain characteristic. The value assigned to Dpi represents an ordinal scale that is an indication of the relevance of the characteristic for component p. A typical scale might be
1: not relevant to whether reuse is appropriate
2: relevant only under unusual circumstances
3: relevant—the component can be modified so that it can be used, despite differences
4: clearly relevant, and if the new software does not have this characteristic, reuse will be inefficient but may still be possible
5: clearly relevant, and if the new software does not have this characteristic, reuse will be ineffective and reuse without the characteristic is not recommended
When new software, w, is to be built within the application domain, a set of domain characteristics is derived for it. A comparison is then made between Dpi and Dwi to determine whether the existing component p can be effectively reused in application w. Table lists typical domain characteristics that can have an impact of software reuse. These domain characteristics must be taken into account in order to reuse a component effectively.
Even when software to be engineered clearly exists within an application domain, the reusable components within that domain must be analyzed to determine their applicability. In some cases (ideally, a limited number), “reinventing the wheel” may still be the most cost-effective choice.
Structural Modeling and Structure Points
When domain analysis is applied, the analyst looks for repeating patterns in the applications that reside within a domain. Structural modeling is a pattern-based domain engineering approach that works under the assumption that every application domain has repeating patterns (of function, data, and behavior) that have reuse potential. Pollak and Rissman describe structural models in the following way:
Structural models consist of a small number of structural elements manifesting clear patterns of interaction. The architectures of systems using structural models are characterized by multiple ensembles that are composed from these model elements. Many architectural units emerge from simple patterns of interaction among this small number of elements.
Each application domain can be characterized by a structural model (e.g., aircraft avionics systems differ greatly in specifics, but all modern software in this domain has the same structural model). Therefore, the structural model is an architectural style that can and should be reused across applications within the domain.
McMahon describes a structure point as “a distinct construct within a structural model.” Structure points have three distinct characteristics:
1. A structure point is an abstraction that should have a limited number of instances. Restating this in object-oriented jargon , the size of the class hierarchy should be small. In addition, the abstraction should recur throughout applications in the domain. Otherwise, the cost to verify, document, and disseminate the structure point cannot be justified.
2. The rules that govern the use of the structure point should be easily understood. In addition, the interface to the structure point should be relatively simple.
3. The structure point should implement information hiding by isolating all complexity contained within the structure point itself. This reduces the perceived complexity of the overall system.
As an example of structure points as architectural patterns for a system, consider the domain of software for alarm systems. This domain might encompass systems as simple as SafeHome (discussed in earlier chapters) or as complex as the alarm system for an industrial process. In every case, however, a set of predictable structural patterns are encountered:
• An interface that enables the user to interact with the system.
• A bounds setting mechanism that allows the user to establish bounds on the parameters to be measured.
• A sensor management mechanism that communicates with all monitoring sensors.
• A response mechanism that reacts to the input provided by the sensor management system.
• A control mechanism that enables the user to control the manner in which monitoring is carried out.
Each of these structure points is integrated into a domain architecture.
It is possible to define generic structure points that transcend a number of different application domains :
• Application front end—the GUI including all menus, panels and input and command editing facilities.
• Database—the repository for all objects relevant to the application domain.
• Computational engine—the numerical and nonnumerical models that manipulate data.
• Reporting facility—the function that produces output of all kinds.
• Application editor—the mechanism for customizing the application to the needs of specific users.
