Domain Analysis and Engineering: How Domain-Specific Frameworks Increase Software Reuse

Jeffrey S. Poulin
Loral Federal Systems-Owego
July 1995

Proceedings of CASE JAPAN'95, Tokyo, Japan, 12-15 July 1995, pp. B-3/1-3.


This paper discusses the relationship between software reuse, domain analysis, and domain engineering. It gives a model for explaining the reuse potential on programs which only practice assembly of general-purpose components and those which develop domain-specific frameworks. The paper shows that domain-specific software not only leads to high levels of software reuse but it also helps developers build better software by providing a consistent approach to related applications.


We normally consider "software" reuse as the use of existing source code components to develop new applications [GAO93]. However, reusable software components can take many other forms, including: executable programs, code segments, documentation, requirements, design and architectures, test data, test plans, and experience. With this in mind, we define a reusable component as a group of functionally-related software modules. A reusable component may take the form of a software "building block" that offers primitive operations on top of which programmers can develop more complex and specific capabilities.

Planned versus unplanned reuse

Reuse takes two primary forms in an organization; either it happens by accident (opportunistic reuse) or the organization plans and designs reuse into their development process (systematic reuse).

Almost every organization practices opportunistic reuse by salvaging old information in some ad-hoc fashion. People routinely save a little time by modifying something similar to their current need. However, the benefits to this white-box reuse, or copying and modifying assets, has limitations. The new asset must undergo the same testing, configuration management, maintenance, documentation, and all the other requirements as a new asset. In other words, white-box reuse achieves a marginal savings and this savings does not extend beyond the development phase.

On the other hand, an organization that practices systematic reuse plans and formally integrates reuse into a well-defined software development process. In formal reuse, developers focus on the use of black-box assets, or unmodified software components. This means the developer does not alter the source files of the reusable asset; if necessary, the developer makes all behavior modifications through parameter passing, generic instantiations, or (in the case of object-oriented languages such as C++), inheritance and polymorphism.

The benefits to black-box reuse greatly exceed those of white-box reuse. This occurs because the developer knows the component functions without error and can avoid a lot of effort, especially in the unit test through maintenance phases. Furthermore, the developer does not need to know the component's implementation. This raises the level of abstraction required to program, accelerates the learning curve, lowers the perceived software complexity, and reduces the effort required to enhance and maintain the final product. A successful reuse program depends on having formal, systematic reuse as a key part of application development.

Domain analysis and engineering

Having a formal, systematic reuse process assumes the existence of software to reuse; domain analysis helps identify this software. A domain analysis primarily consists of a well-structured, intense study of a collection of problems or a collection of applications [Ara93]. A domain analysis helps answer the questions:

  1. What software can we reuse?
  2. How do we make it reusable?
A domain analysis helps identify the common parts of a problem; in other words, those features which will translate later into shared software. The domain analysis also helps develop an understanding of the problem which, when documented, leads to models of the domain, preliminary design documents, and interface specifications. The domain analysis process consists of characterizing and understanding the problem space. The analyst has the goal of factoring out commonality in the problems so as to identify common, shared threads. The analyst then attempts to characterize and understand the solution space for the domain. The process culminates in a mapping of the problem space to the solution space by modeling a framework, architecture, design, and/or software to generate applications within the domain [Tra93]. Domain engineering differs from domain analysis in that domain engineering includes the actual construction of the software system.

Domain-Specific Reuse

We can characterize reuse as vertical or horizontal, depending on attributes of the software and the domain.

Most programs make use of a standard set of domain-independent, general-purpose utility software. As shown in Figure 1, this utility software provides a good example of horizontal reuse, or reuse across domains. Most programmers have experience in horizontal reuse by way of mathematical subroutines or I/O libraries. Although horizontal reuse has stable and low risk benefits, these benefits have upper limits of around 20% of an application due to the generally small size and scope of domain-independent software.

(Image 3class)

Figure 1: The Three Classes of Software

A typical application will consist of up to 20% general-purpose domain-independent software and up to another 65% of domain-dependent reusable software built specifically for that application domain. The remainder of the application will consist of custom software written exclusively for the application and having relatively little utility elsewhere.

Vertical reuse, on the other hand, takes place within a domain or a family of related systems. Vertical reuse has a tremendous potential benefit when building many applications within a related area or domain because each application can make use of common objects and operations. As an example of the benefits of domain-specific reuse over horizontal reuse, the estimated reuse potential in the domain of business applications (management information systems) ranges from 75% to 90% [Jon84]. To achieve these levels of reuse an application must make use of domain-specific frameworks and software.

Definition of a domain-specific framework

A reusable component may offer rules, templates, or generic designs to aid in the assembly of the components. These additional items begin to define what we mean by a domain-specific framework. In general, a framework has three major features:

  1. an architecture, or rules defining the structure of applications within the problem domain,

  2. a relatively small set of components engineered and designed to fit the architecture and that have interfaces that comply with the composition rules defined by the architecture, and,

  3. tools that help the programmer build applications using the domain knowledge contained within the architecture and the components; these tools include component interconnection mechanisms ("glue code") and environments such as layout editors and browsers.

Domain-specific frameworks can reduce development costs through shorter life cycles, reduce maintenance costs through the use of pre-existing and proven components, and reduce training costs because the framework makes it easier to explain how a developer should design software so it works effectively within the entire system.

Attributes of a good domain

The most successful domain analysis and engineering projects come from organizations which have extensive experience working in that domain. However, certain domains lend themselves to domain analysis [Iso92]. In general, narrow domains containing a small number of abstractions or having limited scope provide the best candidates. Developers must have a thorough knowledge of the domain, either from extended experience or through domain analysis. Mature domains, i.e., those with a stable implementation technology, terminology, and methods, as well as widely-used domains which require a lot of custom development based on core functions, work best. These attributes help guarantee well-defined reuse opportunities that will enjoy a large market before they become obsolete.


Many organizational reuse programs only address horizontal reuse opportunities. However, these organizations will unlikely see very high levels of reuse because the amount and types of software available for horizontal reuse rarely comprise more than 20% of a typical application. To achieve levels of reuse of up to 85%, an organization must develop software frameworks or architectures based on domain analysis and engineering techniques.

Cited References

Arango, Guillermo, "Domain Analysis Methods," in Software Reusability. Wilhem Shaefer, Ruben Prieto-Diaz, and Masao Matsumoto, eds. Ellis Horwood, Chichester, U.K.,1993.
GAO, "Software Reuse - Major Issues Need to Be Resolved Before Benefits Can Be Achieved," United States General Accounting Office (GAO), GAO/IMTEC-93-16, January 1993.
Isoda, Sadahiro, "Experience Report on Software Reuse Project: Its Structure, Activities, and Statistical Results," Proceedings of the International Conference on Software Engineering, Melbourne, Australia, 11-15 May 1992, pp. 320-326.
Jones, T.C. "Reusability in Programming: A Survey of the State of the Art," IEEE Transactions on Software Engineering, Vol. SE-10, No.5, September, 1984.
Tracz, Will, Lou Coglianese, and Patrick Young, "A Domain-Specific Software Architecture Engineering Process Outline," ACM SIGSOFT Software Engineering Notes, Vol. 18, No. 2, April 1993, pp. 40-49.


Jeffrey S. Poulin ( MD 0210, Loral Federal Systems (LFS), Owego, New York, 13827. Dr. Poulin works with the Advanced Technology Group as the lead software architect on a major management information system for the U.S. Army. His past responsibilities in Owego include technical lead for the LFS reuse program and leading research into object-oriented frameworks, distributed computing, and information retrieval. A former member of IBM's Reuse Technology Support Center (RTSC), his responsibilities included developing and applying IBM's reuse standards to include a major software reuse metrics and economic model. He also organized, edited, contributed to, and published a complete library of resources on the IBM Reuse Method.

Active in various professional activities, Dr. Poulin has published over 30 papers on software measurement and reuse. In addition to serving on numerous conference committees and panels, he chaired the IEEE Computer Society 6th Annual Workshop on Software Reuse (WISR'93) in November, 1993. A Hertz Foundation Fellow, Dr. Poulin earned his Bachelors degree at the United States Military Academy at West Point and his Masters and Ph.D. degrees at Rensselaer Polytechnic Institute in Troy, New York.