Computer Systems & Architecture
10. Software Product Lines
10. Software Product Lines
• Describe why we need to reuse an existing architecture
• Explain that what makes software product lines work
• List the three things should be consider the
architecture for product lines
• A software architecture represents a significant
investment of time and effort, usually by senior
• So it is natural to want to maximize the return on
this investment by re-using an architecture across
• Architecturally mature organizations tend to treat
their architectures as valuable intellectual property
and look for ways in which that property can be
leveraged to produce additional revenue and
• When an organization is producing multiple
similar systems and re-using the same
architecture, it enjoys substantial benefits that
include reduced cost of construction and
reduced time to market.
• This is the lure of the software product line,
– A set of software-intensive systems sharing a
common, managed set of features that satisfy the
specific needs of a particular market segment or
mission and that are developed from a common
set of core assets in a prescribed way.
10.2 What makes software product lines work?
• The essence o a software product line is the
disciplined, strategic re-use of assets in producing a
family of products.
• What makes product lines succeed to spectacularly
from the vendor or developer’s point of view is that
the commonalities shared by the products can be
exploited through re-use to achieve production
• The potential for re-use is broad and far-ranging,
– Architectural design
– Modeling and analysis
– Project planning
– Process, methods and tools
– Exemplar systems
– Defect elimination
• The scope of the product line defines what
systems are in it, and what systems are out.
• Put less bluntly, a product line’s scope is a
statement about what systems an organization
is willing to build as part of its line and what
systems it is not willing to build.
10.4 Architectures for product lines
• Of all of the assets in a core asset repository, the
software architecture plays the most central role.
• The essence of building a successful software
product line is discriminating between what is
expected to remain constant across all family
members and what is expected to vary.
• Products in a software product line exist
simultaneously and may vary in terms of their
behavior, quality attributes, platform, network,
physical configuration, middleware, scale factors
and so on.
• A product line architect needs to consider
• Identifying variation points
• Supporting variation points
• Evaluating the architecture for product
Identifying variation points
• Identifying variation is an ongoing activity.
Because of the many ways a product can vary,
variants can be identified at virtually any time
during the development process.
• Some variations are identified during product
line requirements elicitation; others, during
architecture design; and still others, during
• Variations may also be identified during
implementation of the second products as well.
Supporting variation points
• In a conventional architecture, the mechanism for
achieving different instances almost always comes
down to modifying the code. But in a software
product line, architectural support for variation can
take many forms:
• Inclusion or omission of elements.
• Inclusion of a different number of replicated
• Selection of versions of elements that have the
same interface but different behavioral or quality
• These mechanisms produce wholesale changes at the
architectural level. Other mechanisms can be
introduced that change aspects of a particular element.
More sophisticated techniques include the following:
– In object-oriented systems, specializing or
generalizing particular classes can achieve variation.
– Building extension points into element’s
– Variation can be accomplished by introducing build-
time parameters to an element, a subsystem, or a
collection of subsystems, whereby a product is
configured by setting a collection of values.
- Reflection is the ability of a program to
manipulate data on itself or its execution
environment or state.
- overloading is a means of re-using a
named functionality to operate on different
Evaluating a product line architecture
• Like any other, the architecture for a
software product line should be evaluated
for fitness of purpose.
• In fact, given the number of systems that
will rely on it, evaluation takes on an
even more important role for a product
- What and how to evaluate. The evaluation will
have to focus on the variation points to make
sure they are appropriate, that they offer
sufficient flexibility to cover the product
line’s intended scope.
- When to evaluate. An evaluation should be
performed on an instance or variation of the
architecture that will be used to build one or
more products in the product line.
10.5 What makes software product lines
• It takes a certain maturity in the developing
organization to successfully field a product line.
• Technology is not the only barrier to this;
organization, process and business issues are
equally vital to master to fully reap the benefits of
the software product line approach.
• The Software Engineering Institute has identified
twenty-nine issues or ‘practice areas’ that affect an
organization’s success in fielding a software
• Most of these practice areas are applied during
single-system development as well, but take on a
new dimension in a product line context.
• Two examples are architecture definition and
• Architecture definition needs to emphasize
variation points in a software product line.
• Configuration management is each product is the
result of binding a large number of variations.
• Getting an organization to adopt the product line
approach is in many regards like any other
technology insertion problem.
• How to solve it depends on the organization’s culture
• Top-down adoption comes when a manager decrees
that the organization will use the approach.
• Bottom-up adoption happens when designers
and developers working at the product level
realize that they are needlessly duplicating
each other’s work and begin to share
resources and develop generic core assets.
• Orthogonal to the issue of in which direction
the technology will grow is the question of
how the product line itself grows. Here there
are two primary models.
• Proactive model
• Reactive model
Creating products and evolving a product line
• An organization that has a product line
will have an architecture and a collection
of elements associated with it.
• From time to time, the organization will
create a new number of the product line
that will have features both in common
with and different from those of other
• One problem associated with a product
line is managing its evolution.
• As time passes, the product line-or, in
particular, the set of core assets from
which products are built – must evolve.
• That evolution will be driven by both
sources which are:
– External sources
– Internal sources
• An asset base on which products depend, but which
has its own evolutionary path, requires an
organization to decide how to manage both it and
• Jan Bosch has studied product line organizational
models and has identified four types:
1. Development department
2. Business units
3. Domain engineering unit
4. Hierarchical domain engineering units.