Figure 1: The Three Classes of Software
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.
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.
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:
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.
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.
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:
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.
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.
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.