eberard@ajpo.sei.cmu.edu (Edward Berard) (12/24/89)
PROLOGUE
If you were to ask a good number of people why they were using, or
were seriously thinking about using, an object-oriented approach to
software engineering, you would get responses such as:
- enhanced interoperability,
- software solutions which are easily modified and extended,
- simpler, more straightforward solutions, and
- better suitability for real-time systems.
However, probably the most common answer would be: enhanced reusability.
Like object-orientation, software reusability is very much
misunderstood. Many people think that the pinnacle of software reuse
is a "library of math functions." What most software professionals do
not realize is that software reusability, like object-orientation,
impacts everything, from management practices to software development
standards, and much more.
SOFTWARE REUSABILITY
"Software components (routines), to be widely acceptable to
different machines and users, should be available in families
arranged according to precision, robustness, generality and
time-space performance. Existing sources of components --
manufacturers, software houses, users' groups and algorithm
collections -- lack the breadth of interest or coherence of
purpose to assemble more than one or two members of such
families, yet software production in the large would be
enormously helped by the availability of spectra of high
quality routines, quite as mechanical design is abetted by the
existence of families of structural shapes, screws, or
resistors."
-- Doug McIlroy (in [Naur and Randell, 1969])
"Specialists in every part of software have a curious vision
of the world: All parts of software but his are simple and
easily parameterized; his is totally variable."
-- A. J. Perlis (in [Naur and Randell, 1969])
"In talking about the implementation of software components,
the whole concept of how one designs software is ignored. Yet
this is the key thing."
-- K. Kolence (in [Naur and Randell, 1969])
"A comparison with our hardware colleagues is relevant."
-- Peter Naur (in [Naur and Randell, 1969])
"Reusable code is taken seriously in Japan and should be here
too. ... To me this is the most important branching point. In
the long run, it will determine which companies will stay in
business and which ones won't."
-- Capers Jones (_ComputerWorld_, November 24, 1986, page 19)
"The results of a California study proved that software
systems are highly redundant, with 75% of the application
code, 50% of the systems programs and 70% of
telecommunications programs sharing identical code or
functions."
-- News item from _ComputerWorld_, November 24, 1986, page 19
One of my primary areas of interest is software reusability. I have
conducted research on, taught courses about, and developed products
using, software reusability technology. Here are some of the things I
found:
- Software practitioners often incorrectly limit their
definition of "software" to source code and object code. In
truth, software includes such things as:
- code fragments
- modules, i.e.:
- subprograms, e.g., procedures, functions,
subroutines, paragraphs
- larger collections, e.g., Smalltalk's
classes, Modula's modules, and Ada's
packages
- large object-oriented entities, e.g., subsystems
([Levy and Ripken, 1987] and [Rational, 1986])
- scaffolding code (and documentation)
- test data
- plans, policies, standards, and procedures
- products of analysis, design, and software quality
assurance efforts
- Management and technical staff alike often avoid thinking
about software reuse until too late, i.e., the "coding
phase." They fail to realize that reusability impacts
everything including management, contracting and legal
issues, in-house development standards, and relationships
with subcontractors. (See, e.g., [Berard, 1987].)
- Fortunately, delaying consideration of reusability issues
until the coding phase is far less disastrous than delaying
object-oriented considerations until the design and/or
coding phase.
- Although many people pitch software reusability on the
grounds that it will "save money," both management and
technical staffers are seldom swayed by this argument --
even when presented with hard data to back up the argument.
- Software reusability can have a very positive impact on
software reliability, software efficiency, and "time to
market."
- Training is essential. Simply purchasing libraries of
reusable components (e.g., [Dusink and van Katwijk, 1987],
[Russell, 1987] and [Margono and Berard, 1987]) and/or
software reusability systems (e.g., [Burton et al, 1987])
does not guarantee their (proper) use.
- The concepts of software reusability and object-oriented
technology are so intertwined that it is often difficult to
talk about one without mentioning the other, e.g., see
[Frankowski, 1986], [Johnson and Foote, 1988], [Meyer,
1987], [Schmucker, 1986], [St. Dennis et al, 1986], [Devanbu
and Bachman, 1989], and the panel ("Experiences With
Reusability") at the 1988 OOPSLA.
- The major obstacles to software reusability are _not_
technical, they are primarily cultural. (See, e.g.,
[Carstensen, 1987] and [Tracz, 1987].)
DOMAIN ANALYSIS: DEFINITIONS
If you study software reusability for a little while, you will
probably encounter some discussion of "domain analysis." Here are two
alternative definitions of domain analysis:
"An investigation of a specific application area that seeks to
identify the operations, objects, and structures that commonly
occur in software systems within this area."
-- Dan McNicholl (in [Booch, 1987])
"Systems analysis states what is done for a specific problem
in a domain while domain analysis states what can be done in a
range of problems in a domain. ... A domain analysis is only
useful if many similar systems are to be built so that the
cost of the domain analysis can be amortized over the cost of
all the systems.
"The key to reusable software is captured in domain analysis
in that it stresses the reusability of analysis and design,
not code."
-- Jim Neighbors (in [Neighbors, 1980])
[Note Neighbors's emphasis on the importance of non-code software.
(See, also [Arango, 1989].)]
In essence, "domain" in domain analysis refers to "application
domain," e.g., graphical user interfaces, embedded missile
applications, and decision support systems. The reason you are
conducting an "analysis" is that you hope to identify reusable items
within the domain, i.e., items which may be reused to build new
applications which also fall within the same domain.
Grady Booch ([Booch, 1987]) offers the following definitions of
horizontal and vertical domain analysis:
"A horizontal domain analysis studies a number of different
systems across a variety of applications."
"A vertical domain analysis studies a number of systems
intended for the same class of applications."
There are different types of domain analysis beyond simple vertical
and horizontal approaches. In general, each type of domain analysis is
distinguished by the types of reusable items which are being sought,
e.g.:
- "Functional domain analysis" seeks to identify reusable
items localized around functions, e.g., functions,
subroutines, procedures, and programs.
- "Object-oriented domain analysis" seeks to identify reusable
items localized around objects e.g., classes, instances,
systems of objects, and subsystems.
HISTORICAL BACKGROUND
Although the concept of domain analysis (like the concept of software
reusability) has been around for decades, probably the first work of
any significance in the area is documented in the doctoral thesis of
Jim Neighbors ([Neighbors, 1980]). It was not, however, until 1985
that the term "domain analysis" began showing up with any regularity
in the literature, e.g., [Adelson and Soloway, 1985].
By 1988-89, there were quite a few articles on domain analysis, e.g.,
[Iscoe, 1988], [Prieto-Diaz, 1988], and [Simos, 1988]. The way we
think about domain analysis has also changed. For example, by 1987
there was a recognized need for a formal approach to domain analysis
(e.g., [RMISE, 1987]), and by 1989, proposed "formal" approaches did
begin to appear (e.g., [Arango, 1989]).
In 1989, we began to see articles on object-oriented domain analysis.
The first of these articles is [Shlaer and Mellor, 1989].
In this article, I will present a very brief introduction to
object-oriented domain analysis. However, please note that, as with
object-oriented requirements analysis (OORA) and object-oriented
design (OOD), there is more than one school of thought on the process.
DOMAIN ANALYSIS IS NOT A LIFE-CYCLE ACTIVITY
One of the first items one encounters in the study of domain analysis,
is that it is _not_ a life-cycle activity. Specifically, an overall
domain analysis effort goes on _in_ _parallel_ with the software
life-cycles for the products which an organization produces and
maintains. As we will see shortly, there is a synergistic relationship
between the overall domain analysis effort and individual software
projects.
Christine Youngblut (in [Booch, 1987]) details some of the reasons for
keeping domain analysis separate from any specific project:
- "When a component is developed in the context of some
system, it is difficult to abstract from the concerns of
that system to produce a truly flexible, unbiased
component."
- "The additional requirements of a reusable component
(increased quality assurance, testing, flexibility, etc.)
mean that it is more expensive to produce than other
components, and this may not have been allowed for in the
project budgets and schedules."
- "It may be difficult to recognize that a particular part is
highly reusable, and so many potentially useful components
may be ignored."
The relationship between the domain analysis effort and a given
project is fairly simple:
- the project may use components identified, created,
documented, tested, and quality assured by the domain
analysis effort. (These components, along with any necessary
supporting documentation, are placed in the organization's
component library.)
- the domain analysis effort interacts with specific projects
to identify potentially reusable items which have been
produced as a result of development or modification efforts.
WHAT IS A DOMAIN ANALYST
One of the rarest species of software professional is the domain
analyst. The reason for their rarity is that they must
_simultaneously_ possess all of the following characteristics:
- They must be familiar with the specific application domain.
(This is a fairly easy requirement.)
- They must be familiar with the concepts, ideas, or objects
which are to be considered for reuse. (If the domain analyst
is familiar with the application domain but does not have a
fundamental understanding of object-oriented concepts, he or
she will not be able to easily recognize an object when he
or she sees one.)
- They must have excellent abstraction skills. (Any analyst
must be able to distinguish the general from the specific,
and between concepts and implementations.)
- They must be versed in software reusability technology.
(Software reusability technology is _not_ trivial. For
example, can the analyst examine an object in isolation and
systematically determine if the object possesses a complete
set of operations, constants, and exceptions?)
STEPS IN OODA
Oversimplifying, the steps in an OODA effort are:
- Define the domain
- Define the types of objects which are to be considered for
reuse within the defined domain
- Collect a representative sample of applications found in the
defined domain
- Analyze the representative applications to identify reusable
components
- Define reusability guidelines regarding the reusable components
- Demonstrate reuse using the reusable components and the guidelines
- Make recommendations
[Truth in advertising: True domain analysis is a never-ending process.
Specifically, as long as an organization continues to develop and/or
maintain software applications, the domain analysis effort will remain
active. We will describe the steps here as if they were indeed
sequential, however, in practice, each of these steps is more like an
on-going activity.]
In the following discussions, "object" can be taken to mean one, or
more, of the following: class, instance, metaclass, metaobject,
subsystem, and system of objects.
DEFINING THE DOMAIN
It is useful to define each domain as narrowly and as quantitatively
as possible, because:
- Identification of candidate applications which fall (or will
fall) within the domain will be easier.
- Separation of domain-specific reusable objects from
non-domain-specific reusable objects will be easier.
- In general, analysis of the domain, and the resulting
conclusions will be more meaningful.
DEFINING THE OBJECTS WHICH WILL BE REUSED
To perform an adequate analysis, you must know the characteristics of
the objects which you are trying to identify. The object-oriented
domain analyst will have to deal with the following:
- Original identification of the objects (For example, this
may require some object decoupling.)
- Nomenclature (Once you find it, what are you going to call
it?)
- Identification of hierarchies, sets, or other
organizations, (e.g., subclass-superclass relationships,
partial types, and subsystems.)
- Configuration management (How will the reusable objects,
and information relating to the reusable objects, be
tracked?)
COLLECTING A REPRESENTATIVE SAMPLE OF APPLICATIONS
This is a continually on-going effort and requires a careful analysis.
The following must be considered:
- Are the applications in the sample truly representative of
the applications in the domain, e.g., types, sizes, and
languages?
- What is the likelihood that the applications in the sample
contain a representative collection of reusable objects?
- Is there a high probability that future applications within
the domain will have the same characteristics?
[Note: When an organization first begins to use object-oriented
technology, it is quite likely that any previously-existing
applications were _not_ created in an object-oriented manner. Hence,
the analysis of existing applications will require that the
object-oriented domain analyst identify the _conceptual_ (as opposed
to _physical_) objects in each application.]
ANALYSIS OF THE SAMPLE
During the analysis of the representative sample of applications, the
domain analyst must:
- identify candidate reusable objects.
- state why the objects are considered potentially reusable
- identify variations on the objects which will also be
reusable
- determine the percentage of a typical application which
might be constructed from the reusable objects
- name, catalog, and otherwise apply configuration management
to the reusable objects
- predict the relative usefulness of each object in terms of
future applications.
[Note: The most desirable form of reuse is reuse with _no_ changes.
Until they are properly trained, project software engineers will
probably _not_ be designing objects with reuse in mind. (Even after
they are properly trained, project management may not allow them the
resources (e.g., time) to correctly implement reusable objects.)
Therefore, the domain analysts should not expect to find "complete"
objects.More specifically, object-oriented domain analysts will often
be expected to ensure that each object represents a complete
abstraction. Further, the object-oriented domain analysts must make
sure that each reusable object receives the proper amount of testing
and quality assurance.]
DEFINING REUSABILITY GUIDELINES
The domain analyst must provide software engineers with a set of
meaningful guidelines for the reuse of the objects within the domain.
For example the analyst should identify the criteria used to select an
object for use in an application, and the trade-offs to be considered.
DEMONSTRATIONS OF REUSE USING THE REUSABLE OBJECTS
At least one representative example of an application constructed
using the reusable objects must be developed. (In truth, an on-going
series of sample applications will have to be constructed.) In
addition to the application itself, a report describing the the
experiences of the developers, and the characteristics of reuse within
the application must also be produced.
MAKING RECOMMENDATIONS
Based on the guidelines, and on the results of the demonstration, the
domain analyst must provide recommendations for incorporating the
reusable objects into current and future projects. The recommendations
may also include recommendations for changes in life-cycle approaches,
policies, standards, and tools.
DOMAIN ANALYSIS AND LIFE-CYCLE ACTIVITIES
Software reusability is a key consideration during the object-oriented
life-cycle. The analyst must both reuse existing objects, _and_ create
new ones in such a way that they can be easily reused. Some of the
previously existing objects may very well have been created, not for
any specific project, but as a normal product of domain analysis.
Object-oriented requirements analysis (OORA) and object-oriented
design (OOD) are specific to a particular application within a domain.
These processes, however, benefit from domain analysis in a number of
ways:
- Since domain analysis has already identified a number of
reusable objects within the domain, the analysts and the
designers can use this information to help guide the
analysis and design.
- If done well, domain analysis will contribute significantly
to understanding how to design complete, robust objects.
- If done well, domain analysis will have identified those
variations on an object that appear to be most useful within
the domain, e.g., concurrent forms.
- Many of the same techniques used by the domain analyst can
be used by the analysts and designers to help identify the
objects within a specific application -- as well as helping
to understand the interactions of these objects.
As new applications are developed, new objects will be constantly
uncovered. New relationships among new, and existing, objects will
also be discovered. These new relationships will often suggest
different and useful variations on the existing library of objects. In
effect, the development and maintenance processes will be one of the
most effective "feedback" mechanisms for domain analysis.
As usual, my message runneth over. Please forgive the length. Thank
you for listening.
-- Ed Berard
Berard Software Engineering, Inc.
18620 Mateney Road
Germantown, Maryland 20874
Phone: (301) 353-9652
FAX: (301) 353-9272
E-Mail: eberard@ajpo.sei.cmu.edu
BIBLIOGRAPHY
[Adelson and Soloway, 1985]. B. Adelson and E. Soloway, "The Role of
Domain Experience in Software Design," IEEE Transactions on Software
Engineering, Vol. SE-11, No. 11, November 1985, pp. 1351 - 1360.
[Arango, 1989]. G. Arango, "Domain Analysis: From Art to Engineering
Discipline," Proceedings of the Fifth International Workshop On
Software Specification and Design, May 19-20, 1989, Pittsburgh,
Pennsylvania, IEEE Computer Society Press, Washington, D.C., May 1989,
pp. 152 - 159.
[Berard, 1987]. E.V. Berard, "Software Reusability Cannot Be
Considered in a Vacuum," Digest of Papers COMPCON, Spring 1987, IEEE
Catalog Number 87CH2409-1, Computer Society Order Number 764, Computer
Society Press of the IEEE, Washington, D.C., pp. 390 - 393.
[Booch, 1987]. G. Booch, Software Components With Ada,
Benjamin/Cummings, Menlo Park, California, 1987.
[Brown and Quanrud, 1988]. G.R. Brown and R.B. Quanrud, "The Generic
Architecture Approach to Reusable Software," Proceedings of the Sixth
National Conference on Ada Technology, March 14-18, 1988, U.S. Army
Communications-Electronics Command, Fort Monmouth, New Jersey, pp. 390
- 394.
[Burton et al, 1987]. B.A. Burton, R.W. Aragon, S.A. Bailey, K.D.
Koehler, and L. A. Mayes, "The Reusable Software Library," IEEE
Software, Vol. 4, No. 4, July 1987, pp. 25 - 33.
[Carstensen, 1987]. H.B. Carstensen, "A Real Example of Reusing Ada
Software," Proceedings of the Second National Conference on Software
Reusability and Maintainability, National Institute for Software
Quality and Productivity, Washington, D.C., March 1987, pp. B-1 to
B-19.
[Chan, 1987]. Y.K. Chan, "Lessons in Software Reusability in Large
Complex Software Systems," Proceedings of the Conference on Software
Reusability and Portability, National Institute for Software Quality
and Productivity, Washington, D.C., September 16-17 1987, pp. B-1 to
B-7.
[Devanbu and Bachman, 1989]. P. Devanbu and R. Bachman, "OOPSLA
Workshop on Domain Modeling in Software Engineering," New Orleans,
Louisiana, 1989.
[Dusink and van Katwijk, 1987]. E.M. Dusink and J. van Katwijk,
"Reflections on Reusable Software and Software Components," Ada
Components: Libraries and Tools -- Proceedings of the Ada-Europe
International Conference, Stockholm 26-28 May 1987, Edited by S.
Tafvelin, Cambridge University Press, Cambridge, U.K., pp. 113 - 126.
[Fischer, 1987]. G. Fischer, "Cognitive View of Reuse and Redesign,"
IEEE Software, Vol. 4, No. 4, July 1987, pp. 60 - 72.
[Frankowski, 1986]. E. N. Frankowski. "Why Programs Built from
Reusable Software Should be Single Paradigm," Proceedings of the STARS
Reusability Workshop, March 24-27, 1986.
[Iscoe, 1988]. N. Iscoe, "Domain-Specific Reuse: An Object-Oriented
and Knowledge-Based Approach," in IEEE Tutorial: Software Reuse --
Emerging Technology, Edited by W. Tracz, IEEE Computer Society Press,
Washington, D.C., 1988.
[Johnson and Foote, 1988]. R. E. Johnson and B. Foote, "Designing
Reusable Classes," Journal of Object-Oriented Programming, Vol. 1, No.
2, June/July 1988, pp. 22 - 35.
[Kaiser and Garlan, 1987]. G.E. Kaiser and D. Garlan, "Melding
Software Systems from Reusable Building Blocks," IEEE Software, Vol.
4, No. 4, July 1987, pp. 17 - 24.
[Levy and Ripken, 1987]. P. Levy and K. Ripken, "Experience in
Constructing Ada Programs from Non-Trivial Reusable Modules," Ada
Components: Libraries and Tools -- Proceedings of the Ada-Europe
International Conference, Stockholm 26-28 May 1987, Edited by S.
Tafvelin, Cambridge University Press, Cambridge, U.K., pp. 100 - 112.
[Margono and Berard, 1987]. J. Margono and E.V. Berard, "A Modified
Booch's Taxonomy for Ada Generic Data-Structure Components and Their
Implementation," Ada Components: Libraries and Tools - Proceedings of
the Ada-Europe International Conference, Stockholm 26-28 May 1987,
Edited by S. Tafvelin, Cambridge University Press, Cambridge, U.K.,
pp. 61 - 74.
[Matsumoto, 1984]. Y. Matsumoto. "Some Experiences in Promoting
Reusable Software: Presentation in Higher Abstract Levels," IEEE
Transaction on Software Engineering, Vol. SE-10, No. 5, September
1984, pp. 502 - 513.
[Meyer, 1987]. B. Meyer, "Reusability: The Case for Object-Oriented
Design," IEEE Software, Vol. 4, No. 2, March 1987, pp. 50 - 64.
[Naur and Randell, 1969]. P. Naur and B. Randell, Editors, Software
Engineering: Report on a Conference Sponsored by the NATO Science
Committee, Garmisch, Germany, October 7-11, 1968.
[Neighbors, 1980]. J.M. Neighbors, "Software Construction Using
Components," Technical Report 160, Department of Information and
Computer Sciences, University of California, Irvine, 1980.
[Neighbors, 1984]. J.M. Neighbors, "The DRACO Approach to Constructing
Software From Reusable Components," IEEE Transactions on Software
Engineering, Vol. SE-10, No. 5, September 1984, pp. 564 - 574.
[Prieto-Diaz, 1988]. P. Prieto-Diaz, "Domain Analysis for
Reusability," in IEEE Tutorial: Software Reuse -- Emerging Technology,
Edited by W. Tracz, IEEE Computer Society Press, Washington, D.C.,
1988.
[RMISE, 1987]. Rocky Mountain Institute of Software Engineering,
Workshop on Software Reuse -- Participant Proceedings, October 1987.
[Rational, 1986]. Rational, Inc., Large-System Development and
Rational Subsystems, Document Control Number 6004, Rational, Inc.,
Mountain View, California, November, 1986.
[Reilly, 1987]. A. Reilly, "Roots of Reuse," IEEE Software, Vol. 4,
No. 1, January 1987, page 4.
[Russell, 1987]. G.E. Russell, "Experiences Implementing a Reusable
Data Structure Component Taxonomy," Proceedings of the Joint Ada
Conference, Fifth National Conference on Ada Technology and Washington
Ada Symposium, U.S. Army Communications-Electronics Command, Fort
Monmouth, New Jersey, pp. 8 - 18.
[Schmucker, 1986]. K.J. Schmucker, "Object Orientation," MacWorld,
Vol. 3, No. 11, November 1986, pp. 119 - 123.
[Shlaer and Mellor, 1989]. S. Shlaer and S.J. Mellor, "An
Object-Oriented Approach to Domain Analysis," Software Engineering
Notes, Vol. 14, No. 5, July 1989, pp. 66 - 77.
[Simos, 1988]. M.A. Simos, "The Domain-Oriented Software Life-Cycle:
Towards and Extended Process Model for Reusability," in IEEE Tutorial:
Software Reuse -- Emerging Technology, Edited by W. Tracz, IEEE
Computer Society Press, Washington, D.C., 1988.
[St. Dennis et al, 1986]. R. St. Dennis, P. Stachour, E. Frankowski,
and E. Onuegbe, "Measurable Characteristics of Reusable Ada
Software,"Ada Letters, Vol. VI, No. 2, March-April 1986, pp. 41 - 50.
[Standish, 1984]. T. A. Standish. "An Essay on Software Reuse," IEEE
Transaction on Software Engineering, Vol. SE-10, No. 5, September
1984, pp. 494-497.
[Tracz, 1987]. W. Tracz, "Software Reuse: Motivators and Inhibitors,"
Digest of Papers COMPCON, Spring 1987, IEEE Catalog Number 87CH2409-1,
Computer Society Order Number 764, Computer Society Press of the IEEE,
Washington, D.C., 1987.
[Woodfield et al, 1987]. S.N. Woodfield, D.W. Embley, and D.T. Scott,
"Can Programmers Reuse Software?," IEEE Software, Vol. 4, No. 4, July
1987, pp. 52 - 59.