There exists a general confusion regarding the relationship
between reuse, domains, product lines, and software architectures.
High levels of reuse can occur within domains, due to opportunities
for reuse across applications within the domain. Software architectures
describe the highest level organization of a software system,
and may include many domains. This paper shows that product lines
represent the exact same level of abstraction as domains. The
paper then explains that the term "product line" exists
primarily to help the software technical community effectively
communicate concepts about problems (domains) to managers, who
think in terms of solutions (products). This paper discusses
the relationship between these concepts and warns against unnecessarily
creating or raising abstraction levels when discussing software
design issues.
Keywords: Software Architectures, Domain Specific Software Architectures, DSSA, Product Lines, Software Reuse.
Workshop Goals: To explore, learn, and discuss current issues in software architectures and reuse. To have a spirited discussion on the topic of this position paper.
Working Groups: Software architectures for reuse, Domain analysis/engineering representations, or Reuse metrics and economics.
Every couple of years our discussions about reuse
seem to rise to higher levels of abstraction. Reuse using building
blocks gave way to discussions about horizontal reuse and vertical
reuse. Vertical reuse developed into the study of related problem
areas, or domains. Soon the importance of domains became well-known
and reuse research focused on "Domain Specific Software Architectures
(DSSAs)" in order to achieve high levels of reuse within
a domain. More recently, researchers have started to advocate
software development based on "Product Lines." At the
same time, related work in designing large software systems has
identified software architectures as important for consistent
and efficient software development [Gar91]. Each of these concepts
raises the level of abstraction at which we describe software.
In part, the increased levels of abstraction reflect our struggle
to cope with the rapidly increasing complexity of our field.
However, this series of research directions has also led to a
general confusion as to the relationship between reuse, domains,
product lines, and software architectures.
A common understanding of the relationship between
reuse, domains, product lines, and software architectures does
not exist. I believe that the confusion comes from the level
of abstraction that each supposedly represents. Furthermore,
I believe that the term "product line" refers to the
same level of abstraction as "domains" and that the
two terms exist simply to help communicate the same idea to different
audiences.
3 Approach
Extensive work in domain analysis and domain engineering
by a number of excellent sources has defined our knowledge of
domains and their relationship to (vertical) reuse [Ara93]. Likewise,
work in software architectures leaves little doubt that an architecture
provides the highest level representation of a software system
[Gar91]. I have pursued developing reuse-based software architectures
for very large scale software systems [Pou95, Pou96a, Pou96b].
However, a general disagreement exists as to the
definition of product lines. At a recent reuse symposium, a panel
on product lines attempted to field the question "please
explain the difference between product lines and domains."
Every member of the panel gave a different answer. For example,
"there is no difference between product lines and domains
except that product lines connote the idea of a market, whereas
domains do not." Actually, every known domain analysis method
seeks to identify the common elements of a group of related problems
and quantify the number of potential uses of each common element.
Domain analysis must address this in order to justify,
through a business case, the subsequent development of shared
components.
To help answer the question as to the difference
between domains and product lines we will start by exploring them
as a possible abstraction hierarchy. We will then show why domains
and product lines actually refer to the same concept and represent
the same level of abstraction.
3.1 Do the terms form a hierarchy of abstraction?
One possible way to differentiate domains, product
lines, and architectures involves creating a hierarchy of abstractions.
Tracz recently explained how this might work by defining a product
line to possibly span several domains [Tra96]. However, a hierarchy
does not address the issue of deciding the boundaries at each
level of abstraction. In other words, deciding how much of the
problem falls into domains, how much falls into product lines,
and how much falls under a software architecture. With regards
to domain analysis, we refer to this as the "domain scoping"
problem [Svo96]. This problem arises when we do not agree on
the boundary of a problem and therefore cannot agree upon what
constitutes a "domain."
Example: Consider the
domain of avionics applications. Within this domain, we
might have sub-domains consisting of navigation, guidance
and flight direction [Cog92]. On the other hand, we could
instead call the "domain" of avionics applications a
product line and define domains within the product
line as consisting of navigation, guidance and flight
direction [Bar96]. Deciding on the boundaries of a problem
(what to call a domains versus a sub-domain) constitutes the "domain
scoping" problem.
The domain scoping problem has repeatedly caused
disagreement even amongst members of the same design team. Arguments
over how to bound a problem and what to call a domain versus a
sub-domain often hinge on subtle or academic criteria. Unfortunately,
these arguments do not impress management and make it difficult
for the members of the design team to develop a cogent case for
continued support.
Note that we have not defined the role of software
architecture. Continuing with the abstraction hierarchy,
we could define a software architecture as possibly spanning several
product lines. For example, perhaps all product lines on board
an aircraft (e.g., avionics, weapons systems, entertainment, etc.)
would adhere to the same software architecture.
However, we do not really need a three-level hierarchy.
If a product line spans many domains, then at most we need a
software architecture for all products built within that product
line. This would mean that software architecture and
product line architecture mean the same thing.
Example: Consider a suite
of applications for managing a large business. The applications
might include several applications to manage personnel, several
applications to manage logistics, several to manage finances,
etc. We could say that all applications belong to a domain
called "management information systems." However, on
a recent project we decided that the area of MIS systems encompassed
far too many problem areas to call it a domain [Pou96a]. Instead,
we decided that groups of applications in the same problem area
bounded a domain; this made our definition consistent with most
work in domain analysis. Having made this decision, we developed
a software architecture that applied to all MIS applications,
and planned to develop a DSSA for each of our domains.
In retrospect, we could have called our suite of
business applications a product line. However,
we really had no need for this term; the software architecture
unequivocally specified the highest level organization of our
software system. This led us to question how product lines relate
to domains.
3.2 Tuning a concept to the audience
Most software developers (technical persons) understand
the concept of domain. Developers work with problems and
readily adopt unique terms and expressions to express their problem
space. However, most managers do not understand this special
language; they think in "business language." In the
language of their solution space they deal with products,
and they group related products into a "product line."
In other words, "domains" and "product lines"
refer to the same concept but appeal to different audiences.
Example: In a recent
product line "success story," our developers explained
the need to obtain customer buy-in in order to fund the analysis,
design, and development of a large software system [Ran96]. Despite
years of unsuccessful attempts to gain support for domain analysis
and domain engineering, the customer bought into the concept of
moving toward a product-line organization. They saw product line
reuse as the "reuse of architectural coherence, OO models,
processes, tools, and most important, the skills, knowledge, and
motivation of a technologically sophisticated, synergistic team
of people."
This experience report advertised significant opportunities
for reuse within the product line because all products share common
features. Note that the software technical community has forwarded
this exact same concept for years by pointing out the high
opportunities for reuse within a domain and limited opportunities
across domains. The DSSA approach includes the development of
a common reference architecture, domain models, processes, tools,
and depends on the knowledge developed by the team conducting
the domain study. In their very successful reuse program, Hewlett-Packard
structures their domains around portfolios of related products
[Col96]. Substituting the term "domain" for "product
line" rarely changes the content or intent of a paper or
discussion; it can, however, increase the probability that
a particular audience will listen.
Domains and product lines refer to the exact same
level of abstraction. The term "product line" grew
out of the software technical community's failure to relate the
idea of related problems to managers who needed to have
things explained in terms of related solutions [Bid96].
The exact boundaries of each will, of course, depend on the audience.
For example, a manager may scope a product line such that it
includes bits and pieces of what a domain analyst might have defined
as several domains. In this sense, Tracz's explaination that
product lines may span several domains holds. Otherwise, product
lines and domains refer to the exact same thing.
So why the hype? Part of it comes from opportunists
who capitalize on confusion by claiming to understand "the
bigger picture." However, unnecessarily creating or raising
levels of abstraction leads to a situation in which no one can
understand how anything really works. We have seen the confusion
caused by the "product line" trend. In our field, much
of this trend comes from persons who talk about reuse but
do not actually do reuse. Not surprisingly, technical
leaders from within Lockheed Martin ranked product lines as one
of the least important technology areas for future investment
(while at the same time ranking reuse as one of the most important).
I would enjoy seeing the results of a similar question posed
to management.
[Ara93] Arango, Guillermo, "Domain Analysis
Methods," in Software Reusability. Wilhem Shaefer,
Ruben Prieto-Diaz, and Masao Matsumoto, eds. Ellis Horwood, Chichester,
U.K.,1993.
[Bar96] Bardo, Tim, Dave Elliot, Tony Krysak, Mike
Morgan, Rebecca Shuey, and Will Tracz, "CORE: A Product Line
Success Story," Crosstalk: The Journal of Defense Software
Engineering, Vol. 9, No. 3, March 1996, pp. 24-28.
[Bid96] Biddle, Robert, and David Eichman, Private
Conversation, 26 September 1996.
[Cog92] Coglianese, L., R. Smith, and W. Tracz, "DSSA
Case Study: Navigation, Guidance, and Flight Director Design and
Development," 1992 IEEE Symposium on Computer Aided
Control System Design, Napa, CA, 17-19 March 1992, pp. 102-109.
[Col96] Collins Cornwell, Patricia, "HP Domain
Analysis: Producing Useful Models for Reusable Software,"
Hewlett-Packard Journal, Vol. 47, No. 4, August 1996, pp.
46-55.
[Gar91] Garlan, David, and Mary Shaw, "An Introduction
to Software Architecture," Advances in Software Engineering
and Knowledge Engineering, World Scientific, Singapore, 1993,
pp. 1-39.
[Pou95] Poulin, Jeffrey S., "The Software Architecture
of the Army SBIS Program," Crosstalk: The Journal of Defense
Software Engineering,, February 1996, pp. 16-21.
[Pou96a] Poulin, Jeffrey S., Norm Kemerer, Mike Freeman,
Tim Becker, Kathy Begbie, Cheryl D'Allesandro, and Chuck Makarsky,
"A Reuse-Based Software Architecture for Management Information
Systems," Fourth International Conference on Software
Reuse, Orlando, FL, 23-26
April 1996, pp. 94-103.
[Pou96b] Poulin, Jeffrey S., "Evolution of a
Software Architecture for Management Information Systems,"
Proceedings of the Second International Software Architecture
Workshop (ISAW-2), San Francisco, CA, 14-15 October 1996,
pp. 134-137.
[Ran96] Randall, Richard L., David J. Bristow, Jesse
G. Foster, and Maj. Dennis D. Kaip, "Product-Line Reuse Delivers
a System for One-Fifth the Cost in One-Half the Time,"
Crosstalk: The Journal of Defense Software Engineering, August
1996, pp. 25-26.
[Tra96b] Tracz, Will, Private Conversation,
August, 1996.
Jeffrey S. Poulin (Jeffrey.Poulin@lmco.com)
MD 0210, Lockheed Martin Federal Systems, Owego, New York, 13827.
http://www.owego.com/~poulinj.
Dr. Poulin works as a Senior Programmer and
software architect with Lockheed Martin Federal Systems (formally
Loral Federal Systems and IBM Federal Systems Company) in Owego,
NY. As a member of the Advanced Technology Group, he works software
reuse and architecture issues on a variety of software development
efforts across Lockheed Martin.
From 1991-1993 Dr. Poulin worked in the IBM Reuse Technology Support Center (RTSC) where he led the development and acceptance of the IBM software reuse metrics and return on investment (ROI) model. He also organized, edited, contributed to, and published a complete library of resources on the IBM Reuse Method. Active in numerous professional activities and conference committees, Dr. Poulin has over 40 publications, to include a book on reuse metrics and economics published by Addison-Wesley. 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.