58
Again, a build file would select the number appropriate for a particular product.
Selection of versions of elements that have the same interface but different behavioral or quality
attribute characteristics. Selection can occur at compile or build time or, in some cases, even
runtime. Two selection mechanisms are static libraries, which contain external functions linked to
after compilation time, and dynamic link libraries, which have the flexibility of static libraries but defer
the decision until runtime based on context and execution conditions. By changing the libraries, we
can change the implementation of functions whose names and signatures are known.
These mechanisms produce wholesale changes at the architectural level. Other mechanisms can be
introduced that change aspects of a particular element. Changing the source code falls into this category.
More sophisticated techniques include the following:
In object-oriented systems, specializing or generalizing particular classes can achieve variation.
Classes can be written to admit a variety of specializations that can be written for various products
as necessary.
Building extension points into the element's implementation. This is a place where additional
behavior or functionality can be safely added.
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. Reflective programs can adjust their behavior based on their context.
Overloading is a means of re-using a named functionality to operate on different types. Overloading
promotes code re-use, but at the cost of understandability and code complexity.
Of course, there must be documentation (see Chapter 9
) for the product line architecture as it resides in
the core asset base and for each product's architecture (to the extent that it varies from the product line
architecture). The documentation for the product line architecture should clearly show its variation points
and a rationale for each (probably using the scope definition as justification). It should also describe the
architecture's instantiation process—that is, how its variation points are exercised. Theoretically, each
variation point could be described separately, but in practice not all variations are allowed. Some
combinations may be unused or (worse) result in an error, and so the documentation needs to explain
valid and invalid variation bindings.
The documentation for an individual product's architecture can be written in terms of deltas from or
binding of variation points. For example, the architecture for product #16 might require
three
servers,
sixty-four
client workstations,
two
databases, the
high-speed low-resolution version
of the graphics
element, and
null
encryption in the message generator.
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 line architecture.
The good news is that the evaluation techniques described earlier in this book work well for product line
architectures. The architecture should be evaluated for its robustness and generality, to make sure it can
serve as the basis for products in the product line's envisioned scope. It should also be evaluated to make
sure it meets the specific behavioral and quality requirements of the product at hand. We begin by
focusing on the what and how of the evaluation and then turn to when it should take place.
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, that they allow products to be built quickly,
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
343 / 463
33
and that they do not impose unacceptable runtime performance costs. If your evaluation is scenario
based, expect to elicit scenarios that involve instantiating the architecture to support different products in
the family. Also, different products in the product line may have different quality attribute requirements,
and the architecture will have to be evaluated for its ability to provide all required combinations. Here
again, try to elicit scenarios that capture the quality attributes required of family members.
Often, some of the hardware and other performance-affecting factors for a product line architecture are
unknown to begin with. In this case, evaluation can establish bounds on the performance that the
architecture is able to achieve, assuming bounds on hardware and other variables. The evaluation can
identify potential contention so that you can put in place the policies and strategies to resolve it.
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. The extent to which this is a separate, dedicated
evaluation depends on the extent to which the product architecture differs in quality-attribute-affecting
ways from the product line architecture. If it does not differ, the product line architecture evaluation can be
abbreviated, since many of the issues normally be raised in a single product evaluation will have been
dealt with in the product line evaluation. In fact, just as the product architecture is a variation of the
product line architecture, the product architecture evaluation is a variation of the product line architecture
evaluation. Therefore, depending on the evaluation method used, the evaluation artifacts (scenarios,
checklists, etc.) will have re-use potential, and you should create them with that in mind. The results of
evaluation of product architectures often provide useful feedback to the product line architects and fuel
architectural improvements.
When a new product is proposed that falls outside the scope of the original product line (for which the
architecture was presumably evaluated), the product line architecture can be re-evaluated to see if it will
suffice for it. If it does, the product line's scope can be expanded to include the new product or to spawn a
new product line. If it does not, the evaluation can determine how the architecture will have to be modified
to accommodate the new product.
The product line and product architectures can be evaluated not only to determine architectural risks but
also, using the CBAM (see Chapter 12
), to determine which products will yield the most return.
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
344 / 463
55
[ Team LiB ]
14.5 What Makes Software Product Lines Difficult?
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 product line. 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 configuration management.
Architecture definition is an important activity for any project but, as we saw in the previous section, it
needs to emphasize variation points in a software product line. Configuration management is also an
important activity for any project but is more complex for a software product line because each product is
the result of binding a large number of variations. The configuration management problem for product
lines is to reproduce any version of any product delivered to any customer, where "product" means code
and supporting artifacts ranging from requirement specs and test cases to user manuals and installation
guides. This involves knowing what version of each core asset was used in a product's construction, how
every asset was tailored, and what special-purpose code or documentation was added.
Examining every facet of product line production is outside the scope of this book, but the next section
will examine a few of the key areas to give a flavor of the qualitative difference between product line and
single-system development. These are issues that an organization will have to face when considering
whether to adopt a product line approach for software development.
ADOPTION STRATEGIES
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 and context.
Top-down adoption comes when a manager decrees that the organization will use the approach. The
problem here is to get employees in the trenches to change the way they work. 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. The
problem here is finding a manager willing to sponsor the work and spread the technique to other parts of
the organization. Both approaches work; both are helped enormously by the presence of a strong
champion
—someone who has thoroughly internalized the product line vision and can share that
compelling vision with others.
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.
[1]
[1]
These models were identified by Charles Krueger at a recent Dagstuhl workshop on
software product lines (www.dagstuhl.de
).
In a
proactive
product line, an organization defines the family using a comprehensive definition of scope.
They do this not with a crystal ball but by taking advantage of their experience in the application area,
their knowledge about the market and technology trends, and their good business sense. The proactive
model is the most powerful of the two product line growth models, because it allows the organization to
make the most far-reaching strategic decisions. Explicitly scoping the product line allows you to look at
areas that are underrepresented by products already in the marketplace, make small extensions to the
product line, and move quickly to fill the gap. In short, proactive product line scope allows an organization
to take charge of its own fate.
Sometimes an organization does not have the ability to forecast the needs of the market with the certainty
suggested by the proactive model. Perhaps the domain is a new one. Perhaps the market is in flux. Or
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
345 / 463
60
perhaps the organization cannot afford to build a core asset base that will cover the entire scope all at
once. In this situation, a
reactive
model is more likely. Here an organization builds the next member or
members of the product family from earlier products. With each new product, the architecture and designs
are extended as needed and the core asset base is built up from what has
turned out
to be common
—instead of what was
preplanned
to be common. The reactive model puts much less emphasis on
upfront planning and strategic direction setting. Rather, the organization lets itself be taken where the
market dictates.
Knowing the various adoption models can help an organization choose the one that is right for it. The
proactive model requires an initial investment but less rework than the reactive model. The reactive model
relies exclusively on rework with little initial investment. Which model should act as a guide for a particular
organization depends very much on the business situation.
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 member of the product line that will have
features both in common with and different from those of other members.
One problem associated with a product line is managing its evolution. As time passes, the product line
—or, in particualr, the set of core assets from which products are built—must evolve. That evolution will
be driven by both external and internal sources:
1.
External sources
- New versions of elements in the line will be released by their vendors, and future products will
need to be constructed from them.
- Externally created elements may be added to the product line. Thus, for example, functions
that were previously performed by internally developed elements may now be performed by
elements acquired externally, or vice versa. Or future products will need to take advantage of
new technology, as embodied in externally developed elements.
- Features may be added to the product line to keep it responsive to user needs or competitive
pressures.
2.
Internal sources
- It must be determined if new functions added to a product are within the product line's scope.
If so, they can simply be built anew from the asset base. If not, a decision must be made: Either
the enhanced product spins off from the product line, following its own evolutionary path, or the
asset base must be expanded to include it. Updating the product line may be the wisest choice
if the new functionality is likely to be used in future products, but this capability comes at the
cost of the time necessary to update the core assets.
- If the product line assets are changed, even if the organization is in a position to issue a
"recall," replacing old products with ones built from the most up-to-date version of the asset
base does not mean that it should do so. Keeping products compatible with the product line
takes time and effort. But not doing so may make future upgrades more time consuming,
because either the product will need to be brought into compliance with the latest product line
elements or it will not be able to take advantage of new functions added to the line.
ORGANIZATIONAL STRUCTURE
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 product development. Jan Bosch [Bosch 00b
] has
studied product line organizational models and has identified four types.
1.
Development department.
All software development is concentrated in a single unit. Each unit
member is expected to be a jack-of-all-trades in the product line, doing domain engineering or
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
346 / 463
41
application engineering when and as appropriate. This model appears in small organizations and
those that provide consulting services. Although it is simple, with short communication paths, having
a single unit has a number of distinct drawbacks. Bosch wrote that it probably works only for units of
up to 30 people (and that sounds high to us) but in very small organizations whose product lines are
commensurately small, it can be a viable starting-out approach.
2.
Business units.
Each business unit is responsible for a subset of the systems in the product family,
which are clustered by similarity. Shared assets are developed by the units that need them and
made available to the community; collaboration across business units to develop new assets is
possible. This model has variations depending on how flexible a business unit can be in developing
(or modifying a shared asset). With no constraints, the products tend to diverge on their own
evolutionary paths, negating the product line approach. Responsibility for particular assets is
assigned to specific business units, which must maintain their assets for use by the entire product
line. Other business units are required to make use of these assets. Bosch estimates that this model
could apply to organizations with between 30 and 100 employees. It suffers from the obvious risk
that a business unit will focus on its own product(s) first and the good of the product line will take a
back seat.
3.
Domain engineering unit.
A special unit is given responsibility for the development and maintenance
of the core asset base, from which business units build the products. Bosch writes that when
organizations exceed 100 employees, communication channels among separate business units
become untenable and a focusing channel to a central shared asset unit becomes necessary. In this
model, a strong and disciplined process becomes much more important to manage the
communication and to ensure that the overall health of the product line is the goal of all parties.
4.
Hierarchical domain engineering units.
It may pay to regard hierarchically a product line that is very
large and/or very complex. That is, the product line may consist of subgroups that have more in
common with each other than with other members of the product line. In this case, a domain
engineering unit may turn out shared assets for the product line at large, and another domain
engineering unit may turn out shared assets for the specialized subgroup. This example is of two
levels, but the model could be extended indefinitely if the subgroups have specialized sub-
subgroups, and so forth. Hierarchical domain units work for very large product lines, built by very
large organizations. Their main disadvantage is the tendency to bloat, reducing the organization's
responsiveness to new needs.
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
347 / 463
13
[ Team LiB ]
14.6 Summary
This chapter presented an architecture-based development paradigm known as software product lines.
The product line approach is steadily climbing in popularity as more organizations see true order-of-
magnitude improvements in cost, schedule, and quality from using it.
Like all new technologies, however, this one holds some surprises for the unaware. Architecturally, the
key is identifying and managing commonalities and variations, but nontechnical issues must be addressed
as well, including how the organization adopts the model, structures itself, and maintains its external
interfaces.
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
348 / 463
22
[ Team LiB ]
14.7 For Further Reading
[Anastasopoulos 00
] presents a nice list of variability techniques. [Jacobson 97
] and [Svahnberg 00
] also
list these techniques.
[Clements 02a
] is a comprehensive treatment of software product lines. It includes a number of case
studies as well as a discussion of product line practice areas.
Organizational models are treated in [Bosch 00
b
].
The FAST process is from [Weiss 00
]. The Philips example comes from [America 00
]. Finally, the GM
Powertrain example is taken from [Bass 00
].
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
349 / 463
Documents you may be interested
- pdf viewer winforms c#: How to copy pictures from pdf file SDK Library service wpf asp.net html dnn PROSTEP-3DPDFPro_2.1_Help_Doc7-part191
- pdf viewer winforms c#: How to copy an image from a pdf to word SDK Library service wpf asp.net html dnn The%20World%20Best%20Boyfriend%20BY%20Durjoy%20Datta9-part1892
- pdf viewer winforms c#: Paste image into pdf acrobat software Library dll windows asp.net wpf web forms The%20World%20Best%20Boyfriend%20BY%20Durjoy%20Datta90-part1893
- pdf viewer winforms c#: How to copy picture from pdf software application cloud windows html .net class The%20World%20Best%20Boyfriend%20BY%20Durjoy%20Datta91-part1894
- pdf viewer winforms c#: How to paste a picture into pdf software control dll winforms azure .net web forms The%20World%20Best%20Boyfriend%20BY%20Durjoy%20Datta92-part1895
- pdf viewer winforms c#: Pasting image into pdf SDK Library project winforms .net wpf UWP The%20World%20Best%20Boyfriend%20BY%20Durjoy%20Datta93-part1896
- pdf viewer winforms c#: Paste picture pdf software SDK cloud windows wpf web page class The%20World%20Best%20Boyfriend%20BY%20Durjoy%20Datta94-part1897
- pdf viewer winforms c#: Copy image from pdf to ppt control software platform web page winforms .net web browser The%20World%20Best%20Boyfriend%20BY%20Durjoy%20Datta95-part1898
- pdf viewer winforms c#: How to copy images from pdf file software control dll windows web page azure web forms The%20World%20Best%20Boyfriend%20BY%20Durjoy%20Datta96-part1899
- pdf viewer winforms c#: Copy a picture from pdf control application platform web page html azure web browser The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis0-part1900
- pdf viewer winforms c#: How to copy pdf image into powerpoint software application dll winforms windows web page web forms The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis1-part1901
- pdf viewer winforms c#: Copy a picture from pdf SDK application service wpf windows .net dnn PoythressVernInTheBeginningWasTheWord21-part21
- pdf viewer winforms c#: How to copy and paste a picture from a pdf document software application cloud windows azure html class protecting-personal-data-in-online-services-learning-from-the-mistakes-of-others0-part192
- pdf viewer winforms c#: Extract images from pdf files without using copy and paste Library software class asp.net windows azure ajax The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis2-part1902
- pdf viewer winforms c#: Copy paste image pdf control application platform web page azure html web browser The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis3-part1903
- pdf viewer winforms c#: How to copy an image from a pdf in preview application control tool html web page wpf online The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis4-part1904
- pdf viewer winforms c#: How to copy and paste a pdf image into a word document software SDK project winforms wpf web page UWP The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis5-part1905
- pdf viewer winforms c#: How to copy a picture from a pdf file control software system azure windows web page console The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis6-part1906
- pdf viewer winforms c#: How to copy a picture from a pdf file Library software component asp.net wpf windows mvc The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis7-part1907
- pdf viewer winforms c#: How to cut an image out of a pdf SDK software API wpf winforms asp.net sharepoint The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis8-part1908
- pdf viewer winforms c#: Copy image from pdf to pdf SDK software API .net winforms wpf sharepoint The+Lion,+The+Witch+and+The+Wardrobe+by+C.S.+Lewis9-part1909
- pdf viewer winforms c#: How to copy an image from a pdf to word software application dll winforms windows html web forms The-5-Best-Heart-Centered-Online-Marketing-Strategies0-part1910
- pdf viewer winforms c#: How to copy picture from pdf to word control application system azure html web page console The-5-Best-Heart-Centered-Online-Marketing-Strategies1-part1911
- pdf viewer winforms c#: How to paste a picture in a pdf Library control class asp.net web page windows ajax protecting-personal-data-in-online-services-learning-from-the-mistakes-of-others1-part193
- pdf viewer winforms c#: How to copy pdf image into powerpoint control SDK platform web page wpf windows web browser the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz0-part1914
- pdf viewer winforms c#: How to copy and paste image from pdf to word control software utility azure html asp.net visual studio the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz1-part1915
- pdf viewer winforms c#: Copy images from pdf to powerpoint control software utility azure html asp.net visual studio the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz10-part1916
- pdf viewer winforms c#: Paste image into preview pdf Library software component .net windows wpf mvc the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz100-part1917
- pdf viewer winforms c#: How to cut pdf image software Library dll windows asp.net winforms web forms the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz101-part1918
- pdf viewer winforms c#: How to copy and paste a picture from a pdf document application Library tool html .net asp.net online the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz102-part1919
- pdf viewer winforms c#: How to copy pictures from a pdf Library control class asp.net web page wpf ajax the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz103-part1920
- pdf viewer winforms c#: How to cut and paste image from pdf control SDK platform web page wpf html web browser the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz104-part1921
- pdf viewer winforms c#: How to cut and paste image from pdf Library software component asp.net winforms windows mvc protecting-personal-data-in-online-services-learning-from-the-mistakes-of-others2-part194
- pdf viewer winforms c#: Cut and paste pdf image application control tool html azure asp.net online the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz105-part1922
- pdf viewer winforms c#: How to copy picture from pdf file control SDK platform web page winforms windows web browser the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz106-part1923
- pdf viewer winforms c#: How to copy an image from a pdf in control application system azure web page windows console the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz107-part1924
- How to copy and paste an image from a pdf the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz108-part1925
- Pasting image into pdf the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz109-part1926
- Copy picture to pdf the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz11-part1927
- How to paste a picture into pdf the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz110-part1928
- How to copy text from pdf image to word the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz111-part1929
- Copy images from pdf the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz112-part1930
- How to copy picture from pdf file the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz113-part1931
- Copy and paste image from pdf protecting-personal-data-in-online-services-learning-from-the-mistakes-of-others3-part195
- How to copy picture from pdf to word the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz114-part1932
- How to copy and paste an image from a pdf the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz115-part1933
- How to copy image from pdf to word the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz116-part1934
- How to copy an image from a pdf the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz117-part1935
- Paste image into pdf form the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz118-part1936
- Cut and paste pdf image the-girl-in-the-spider-s-web-millennium-s-david-lagercrantz119-part1937
Documents you may be interested
