Status

Advanced

Purpose and Origin

The term domain is used to denote or group a set of systems or functional areas, within systems, that exhibit similar functionality. Domain engineering is the foundation for emerging "product line" software development approaches [Foreman 96], and affects the maintainability, understandability, usability, and reusability characteristics of a system or family of similar systems.

The purpose of this technology description is to introduce the key concepts of domain engineering and provide overview information about domain analysis. Detailed discussions of individual domain analysis methods can be found in the referenced technology descriptions.

Technical Detail

Domain engineering and domain analysis are often used interchangeably and/or inconsistently. Although domain analysis as a term may pre-date domain engineering, domain engineering is the more inclusive term, and is the process of

• defining the scope (i.e., domain definition)
• analyzing the domain (i.e., domain analysis)
• specifying the structure (i.e., domain architecture development)
• building the components (e.g., requirements, designs, software code, documentation)

for a class of subsystems that will support reuse [Katz 94].

Figure 11 [Foreman 96] shows the process and products of the overall domain engineering activity, and shows the relationships and interfaces of domain engineering to the conventional (individual) system development (application engineering) process. This has come to be known as the two life cycle model.

Domain engineering is related to system engineering, which is an integrated set of engineering disciplines that supports the design, development, and operation of large-scale systems [Eisner 94]. Domain engineering is distinguished from system engineering in that it involves designing assets¹ for a set or class of multiple applications as opposed to designing the best solution for a single application. In addition, system engineering provides the "whole solution," whereas domain engineering defines (i.e., limits) the scope of functionality addressed across multiple systems [Simos 96].

Figure 11: Domain Engineering and Application Engineering (Two Life Cycles)

Domain engineering supports systems engineering for individual systems by enabling coherent solutions across a family of systems: simplifying their construction, and improving the ability to analyze and predict the behavior of "systems of systems" composed of aggregations of those systems [Randall 96].

Domain analysis. Domain analysis (first introduced in the 1980s) is an activity within domain engineering and is the process by which information used in developing systems in a domain is identified, captured, and organized with the purpose of making it reusable when creating new systems [Prieto-Diaz 90]. Domain analysis focuses on supporting systematic and large-scale reuse (as opposed to opportunistic reuse, which suffers from the difficulty of adapting assets to fit new contexts) by capturing both the commonalities and the variabilities² of systems within a domain to improve the efficiency of development and maintenance of those systems. The results of the analysis, collectively referred to as a domain model, are captured for reuse in future development of similar systems and in maintenance planning of legacy systems (i.e., migration strategy) as shown in Figure 12 [Foreman 96].

Figure 12: Domain Engineering and Legacy System Evolution

One of the major historical obstacles to reusing a software asset has been the uncertainty surrounding the asset. Questions to be answered included

• How does the software asset behave in its original context?
• How will it behave in a new context?
• How will adaptation affect its behavior [Simos 96]?

Design for reuse techniques (e.g., documentation standards, adaptation techniques) were developed to answer these questions; however, they did not provide the total solution, as a software asset's best scope needed to be determined (i.e., In which set of systems would the software asset be most likely reused?). Domain engineering and analysis methods were developed to answer more global questions, such as:

• Who are the targeted customers for the asset base (the designed collection of assets targeted to a specific domain)?
• Who are the other stakeholders in the domain?
• What is the domain boundary?
• What defines a feature of the domain?
• When is domain modeling complete?
• How do features vary across different usage contexts?
• How can the asset base be constructed to adapt to different usage contexts?

Goals of domain analysis include the following:

• Gather and correlate all the information related to a software asset. This will aid domain engineers in assessing the reusability of the asset. For example, if key aspects of the development documentation (e.g., chain of design decisions used in the development process) are available to a potential reuser, a more cost-effective reuse decision can be made.
• Model commonality and variability across a set of systems. This comparative analysis can reveal hidden contextual information in software assets and lead to insights about underlying rationale that would not have been discovered by studying a single system in isolation. It would answer questions like the following:
  • Why did developers make different design tradeoffs in one system than another?
  • What aspects of the development context influenced these decisions?
  • How can this design history be transformed into more prescriptive guidance to new developers creating systems within this domain?
• Derive common architectures and specialized languages that can leverage the software development process in a specific domain.

There is no standard definition of domain analysis; several domain analysis methods exist. Common themes among the methods include mechanisms to

• define the basic concepts (boundary, scope, and vocabulary) of the domain that can be used to generate a domain architecture
• describe the data (e.g., variables, constants) that support the functions and state of the system or family of systems
• identify relationships and constraints among the concepts, data, and functions within the domain
• identify, evaluate, and select assets for (re-)use
• develop adaptable architectures

Wartik provides criteria for comparing domain analysis methods [Wartik 92]. Major differences between the methods fall into three categories:

• Primary product of the analysis. In the methods, the results of the analysis and modeling activities may be represented differently. Examples include: different types of reuse library infrastructures (e.g., structured frameworks for cataloging the analysis results), application engineering processes, etc.
• Focus of the analysis. The methods differ in the extent they provide support for
  • context analysis: the process by which the scope of the domain is defined and analyzed to identify variability
  • stakeholder analysis: the process of modeling the set of stakeholders of the domain, which is the initial step in domain planning
  • rationale capture: the process for identifying and recording the reasoning behind the design of an artifact
  • scenario definition: mechanisms to capture the dynamic aspects of the system
  • derivation histories: mechanisms for replaying the history of design decisions
  • variability modeling: the process for identifying the ways in which two concepts or entities differ
  • legacy analysis: the process for studying and analyzing an existing set of systems
  • prescriptive modeling: the process by which binding decisions and commitments about the scope, architecture, and implementation of the asset base are made
• Representation techniques. An objective of every domain analysis method is to represent knowledge in a way that is easily understood and machine-processable. Methods differ in the type of representation techniques they use and in the ease with which new representation techniques can be incorporated within the method.

Examples of domain analysis methods include

• Feature-Oriented Domain Analysis (FODA), a domain analysis method based upon identifying the features of a class of systems, defines three basic activities: context analysis, domain modeling, and architecture modeling [Kang 90].
• Organization Domain Modeling (ODM), a domain engineering method that integrates organizational and strategic aspects of domain planning, domain modeling, architecture engineering and asset base engineering [Simos 96].

Randall, Arango, Prieto-Diaz, and the Software Productivity Consortium offer other domain engineering and analysis methods [Randall 96, Arango 94, Prieto-Diaz 91, SPC 93].

Usage Considerations

Domain analysis is best suited for domains that are mature and stable, and where context and rationale for legacy systems can be rediscovered through analysis of legacy artifacts and through consultation with domain experts. In general, when applying a domain analysis method, it is important to achieve independence from architectural and design decisions of legacy systems. Lessons learned from the design and implementation of the legacy system are essential; however, the over-reliance on precedented features and legacy implementations may bias new developments.

Maturity

See individual technologies.

Costs and Limitations

See individual technologies.

Complementary Technologies

Use of visual programming techniques can provide better understanding of key software assets like execution patterns, specification and design animations, testing plans, and systems simulation. Other complementary technologies include comparative/taxonomic modeling and techniques for the development of adaptable architectures/implementations (e.g., generation, decision-based composition).

Index Categories

This technology is classified under the following categories. Select a category for a list of related topics.

Name of technology	Domain Engineering and Domain Analysis
Application category	Domain Engineering (AP.1.2.4)
Quality measures category	Reusability (QM.4.4) Maintainability (QM.3.1) Understandability (QM.3.2)
Computing reviews category	Software Engineering Tools and Techniques (D.2.2)

References and Information Sources

[Arango 94]	Arango, G. "Domain Analysis Methods," 17-49. Software Reusability. Chichester, England: Ellis Horwood, 1994.
[Eisner 94]	Eisner, H. "Systems Engineering Sciences," 1312-1322. Encyclopedia of Software Engineering. New York, NY: John Wiley and Sons, 1994.
[Foreman 96]	Foreman, John. Product Line Based Software Development- Significant Results, Future Challenges. Software Technology Conference, Salt Lake City, UT, April 23, 1996.
[Hayes 94]	Hayes-Roth, F. Architecture-Based Acquisition and Development of Software: Guidelines and Recommendations from the ARPA Domain-Specific Software Architecture (DSSA) Program. Palo Alto, CA: Teknowledge Federal Systems, 1994.
[IESE 98]	Fraunhofer Institute for Experimental Software Engineering. Domain Engineering Bibliography [online]. Originally available WWW <URL:http://www.iese.fhg.de/ISE/DEbib/domain.html> (1998).
[Kang 90]	Kang, K., et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study (CMU/SEI-90-TR-21, ADA 235785). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1990.
[Katz 94]	Katz, S., et al. Glossary of Software Reuse Terms. Gaithersburg, MD: National Institute of Standards and Technology, 1994.
[Prieto-Diaz 90]	Prieto-Diaz, R. "Domain Analysis: An Introduction." Software Engineering Notes 15, 2 (April 1990): 47-54.
[Prieto-Diaz 91]	Prieto-Diaz, R. Domain Analysis and Software Systems Modeling. Los Alamitos, CA: IEEE Computer Society Press, 1991.
[Randall 96]	Randall, Rick. Space and Warning C2Product Line Domain Engineering Guidebook, Version 1.0 [online]. Originally available WWW <URL: http://source.asset.com/stars/loral/domain/guide/delaunch.htm>
[Simos 96]	Simos, M., et al. Software Technology for Adaptable Reliable Systems (STARS) Organization Domain Modeling (ODM) Guidebook Version 2.0 (STARS-VC-A025/001/00). Manassas, VA: Lockheed Martin Tactical Defense Systems, 1996.
[SPC 93]	Reuse-Driven Software Processes Guidebook Version 2.00.03 (SPC-92019-CMC). Herndon, VA: Software Productivity Consortium, 1993.
[Svoboda 96]	Svoboda, Frank. The Three "R's" of Mature System Development: Reuse, Reengineering, and Architecture [online]. Available WWW <URL: http://source.asset.com/stars/darpa/Papers/ArchPapers.html> (1996).
[Wartik 92]	Wartik, S. & Prieto-Diaz, R. "Criteria for Comparing Reuse-Oriented Domain Analysis Approaches." International Journal of Software Engineering and Knowledge Engineering 2, 3 (September 1992): 403-431.

Current Author/Maintainer

Liz Kean, Air Force Rome Laboratory

External Reviewers

Jim Baldo, MITRE, Washington, DC
Dick Creps, Lockheed Martin, Manassas, VA
Teri Payton, Lockheed Martin, Manassas, VA
Spencer Peterson, SEI
Rick Randall, Kaman Sciences, Colorado Springs, CO
Mark Simos, Organon Motives, Belmont, MA

Modifications

4 Feb 98: added reference for [IESE 98]
7 Oct 97: minor edits
10 Jan 97: (original)

Footnotes

¹ Examples include requirements, design, history of design decisions, source code, and test information.

² Commonality and variability refer to such items as functionality, data items, performance attributes, capacity, and interface protocols.