Ideas from SPLC
John D. McGregor, Clemson University and Luminary Software
LLC, U.S.A.
|
 |
COLUMN
PDF Version |
Abstract
Software product lines continue to provide adopters with gains in
many areas such as faster time to market and increased productivity.
The recent Software Product Line Conference (SPLC) provided a forum
in which a spectrum of results were reported. In this issue of Strategic
Software Engineering I will use the activities at SPLC to focus on
a couple of interesting areas that have strategic importance.
1 INTRODUCTION
Software product lines is a strategy for improving a company’s
product production capability. They do this by differentiating between
those features that are common across a set of products and those that
appear in only some products. This analysis is used to define a set
of core assets that are structured to support building the set of products.
The Software Product Line Conference (SPLC) is the gathering place
for the software product line community. Like most international technical
conferences, SPLC brings together industry and academic professionals
to discuss research and practice. Many organizations recognize the
strategic importance of participating in conferences, sharing their
results, and listening to the latest information in their field. Participants
can see trends in the industry reflected in the topics presented in
the formal sessions and the discussions in the coffee breaks.
For this issue I have focused on three themes that received attention
at SPLC 2005. I will give a taste of each and invite you to explore
further through the proceedings of the conference available from Springer
and the others works cited here. Whether you are a member of the product
line community or not, these are issues that most organizations need
to consider.
2 PRODUCT SPECIFICATION AND PRODUCTION
The coordinated development of a set of products provides the opportunity
to explore more powerful means of product production. One production
problem is the difficulty in crafting a complete, correct, and consistent
product specification. A couple of answers were presented at SPLC that
center around understanding the domains relevant to the product line.
Domain Modeling
Product line organizations must understand the domains relevant to
their products. There are essentially two different perspectives for
conducting a domain analysis and I find both perspectives useful for
different reasons. The first approach is to do what I will call a conceptual
domain analysis. In this approach the content of the model are concepts
from the domain, such as the concept of score in a gaming product line.
The model includes a class diagram that identifies concepts and the
relationships between them, sequence diagrams that capture standard
algorithms used in the domain, and state diagrams that capture the
life cycles of instances of the concepts. This model is useful as the
initial object model for an object-oriented design.
This conceptual domain analysis is useful for establishing the vocabulary
to be used in the statement of the product requirements. The conceptual
analysis provides a basis for examining the requirements for correctness
and consistency. The feature-oriented domain analysis identifies constraints
and other relationships among the individual features. This second
perspective, using product features instead of concepts, is discussed
in more detail in the following sections.
Feature Modeling
Feature modeling is emerging as a fundamental technique for product
line modeling and this is reflected by several papers on the topic
at SPLC 2005. A feature is a “prominent aspect of something” according
to web definitions. It is a useful unit of specification when the specification
is created by a client or a domain expert. A feature is at the correct
grain size to specify the functional variations among a set of products.
The basic notation for a feature model is a simple graphical representation,
see Figure 1 for examples of one such notation. The darkened circle
above the “event loop” feature indicates a required feature.
The light circle indicates the “scoreboard” feature is
optional. There are several different notations for feature graphs,
although most are closely related. The feature model for a product
line must be able to model a range of variability concepts including
inclusive and exclusive or and selection of potentially multiple members
from a set of choices.
Figure 1 - Feature model notation Formalizing
Feature Models
The graphical notation used in feature models makes for an easy to
understand, but impossible to automate, specification. In a session
at SPLC Don Batory showed an equivalence from this graphical notation
to an attribute grammar [Batory 05]. For the very small model in
Figure 1, the grammar would be stated as:
This grammar makes it easier to automate product derivation, but
only partially addresses the need to evaluate the consistency
and completeness
of the model. Batory then showed that the attribute grammar can
be translated into the propositional logic formula:
The advantage of getting to this form is the ability to automate
the consistency check for the model. As the model evolves,
each new version
can be checked for consistency relatively quickly.
Using the feature model
A product line feature model shows the complete range of features
that are within the scope of the product line. Each product
team then specifies
their product by making all the decisions necessary to
make all the choices called for at alternative and optional branches
in
the feature
model. Essentially the product-specific model contains
only
those features that are required for the final product.
Depending upon the production method for the product line
the specification technique may be the only portion of
the production
method that
requires human intervention. It is fairly easy to design
a decision tool that
guides the product specifier through the choices needed
to specify the product. The product is then automatically
generated
from
the specification.
3 ECONOMIC MODELING
Many of the strategic decisions made during the initial planning
for product line adoption and during product line operation are based
on economic issues. At this year’s SPLC there was a “competition” among
several modeling techniques [Clements 05]. A scenario was provided
and each team produced a model of the scenario using their specific
technique. Several issues appeared.
Basic assumptions and goals
Even simple models involve a number of factors, not all of which
can be varied in one analysis if the model is to be understandable.
In
the case of the product line economic modeling competition, there was
a range of assumptions made in the original problem statement and by
the individual models. Some of the important cost factors in a software
product line are:
- The rate at which the domain is changing - This rate is
not under the control of the product line organization but it affects
how often the
core assets must be updated. Even the product line approach does
not result in large amounts of reuse if the core assets must be modified
after each product is built. This is often expressed as a percentage
of the core asset base that must be modified each year (or other
appropriate
period).
-
The productivity of the asset builders producing the core assets – This
value can be affected by the product line organization through hiring
appropriate people, training, and adoption of appropriate tools.
The models account for this factor using a LOC/hour parameter.
-
The commonality among the products – This value can be controlled
by adjusting the scope of the product line. The commonality allows
the economic model to estimate the amount of total content needed
to produce all of the products. The higher the commonality, the smaller
the cost of the core asset base. One of the techniques modeled this
commonality as an integral part of the cost computation.
-
The timing for when the assets and products will be produced – The
sooner the assets are produced, the sooner the cost is incurred.
The sooner the products are produced, the sooner a cash flow is established.
The sooner the products are produced, the less risk that a product
will be cancelled. Several models take time into account when computing
return on investment as well as actual costs.
-
The certainty of the values being used in the model – A product
line usually represents an investment over time. Plans can change
based on market trends, economic conditions, and technology innovations.
One model in the competition used probabilities that each of its
chosen
scenarios would actually occur to account for uncertainty. Another
model used a range of possible conditions and recomputed each scenario
for several selected values within the range.
Scope and depth of the models
One model provided a high-level view of the costs and benefits of
the entire product line. Other models focused more on just the
software
to be developed and delivered. Product line organizations plan
and model before committing to code. In my opinion, the costs of these
assets have to be accounted for to have an accurate model. One
model
accounted for that by adjusting the LOC/hour productivity while
other models explicitly modeled costs such as the cost of the architecture.
Fixed versus custom modeling approaches
A major difference in the models is whether they use a fixed set
of equations to compute the economic value or whether they
describe a
modeling approach and create each model specifically for the
scenario at hand. Product line organizations vary dramatically
from one
to another. The fixed equation models must be at a very high-level
to
be broadly
applicable. This limits the specificity of the answers they
can provide. The modeling approach allows individual variations in
the product
line organizations and their assumptions to be taken into account
but obviously
require more effort and training to use effectively.
The slides for this competition, including the models, will
be available from www.splc.net shortly. This competition
gave a
clear survey of
the state of the art in developing the economic portion of
the strategic arguments for the product line business case.
4 AGILITY
Since much of product line practice is based on comprehensive planning,
how do you rapidly respond to innovative ideas? Böckle raised
this interesting question in a session at SPLC [Böckle 05]. Innovation
that is anticipated, and therefore may correspond to a variation point,
is probably not very innovative. So is it possible to anticipate that
the variation points will not anticipate the full range of variation – a
meta-level of variation?
The ability to respond quickly is strategically important. Software
product lines are typically structured to minimize the time to market
for a product that is within the scope of the product line. The question
is, does that have to equate to a slower than normal time to market
for products or features that were not included in the original planning
for the product line? The worst case should be the time it takes to
build the product as a one-off product but this may not be the case
if the “reusefulness” of an asset makes it more difficult
to modify than a simpler, single-use asset.
If a decision is made to expand the scope of the product line, the
time for producing the newly in-scope product may be longer than in
non-product line products depending upon the structure of the core
assets. The more abstract the level of the assets, the more flexibility
at the concrete level and the more effort required to modify at the
abstract level. Consider the Unified Modeling Language (UML). A number
of experts have found the UML lacking constructs that were necessary
for their purpose. Rather than invent their own language, they have
extended UML. This is facilitated by the meta-model provided by the
Meta-Object Facility (MOF). Structuring the core assets of a product
line to have this level of flexibility can support an important level
of agility.
Later in the conference, Jan Bosch, a Vice President at Nokia, alluded
to a similar situation but a different type of agility: the ability
to adapt products to unanticipated modifications beyond deployment
[Bosch 05]. In his view, variability binding is extending well beyond
deployment time. He compared systems which previously shipped as a
closed product – 100% bound - with systems shipped more recently
in which an intermediary might add 30 to 40% additional content through
late binding after the original development group has released the
product. Bosch further contrasted those situations to the currently
shipping open systems in which the intermediary may supply 60% or more
of the functionality using late binding mechanisms.
Both of these approaches to agility relate to how quickly new functionality
can be provided. The second type of agility relates to a third-party
providing product functionality as opposed to the first type of agility
which relates to the original development organization responding to
innovative ideas during product line operation. The ability for large
amounts of additional features to be added to a product after it leaves
the original producing company provides flexibility with respect to
market. The open system to which large additions may be made by others
allows agility with respect to the market but in many cases adds complexity.
The strategic advantage of a software product line may become a liability
if these forms of agility aren’t recognized, accommodated, and
appropriately managed.
5 SUMMARY
Software product lines continues to be a means of achieving the strategic
objectives of an organization whose mission is to produce software-intensive
products. Researchers continue to refine product line practice.
New techniques for creating and using feature models are being created.
Techniques for justifying and planning product line efforts are
maturing
as we devise more complete models. We are beginning to consider
how to optimize product line practice by asking questions about the
agility
of otherwise successful product line organizations. All of these
advances better position the product line organization to achieve
its strategic
goals.
SPLC is the forum in which software product lines researchers and
practitioners explore ideas and report results. The growing community
is a vibrant
group that is making substantial progress in a wide range of
areas. I have only reviewed a few of the ideas presented this year.
In
particular I have not discussed most of the industrial reports
and panels nor
have I described the various tutorials and research workshops.
SPLC provides a venue for many types of interaction with, and
presentation by, industrial and academic participants.
I invite you to sample these areas when our community meets again
in Baltimore in August 2006. See www.splc.net for details.
REFERENCES
[Batory 05] Don Batory, Feature Models, Grammars, and Propositional
Formulas, Software Product Line Conference, 9th International Conference,
LNCS 3714, 2005.
[Böckle 05] Günter Böckle, Innovation Management for
Product Line Engineering Organizations, Software Product Line Conference,
9th International Conference, LNCS 3714, 2005.
[Bosch 05] Jan Bosch, Software
Product Families in Nokia, Software Product Line Conference, 9th
International Conference, LNCS 3714,
2005. [Clements 05] Paul Clements, A Competition of Software Product Line
Economic Models, Software Product Line Conference, 9th International
Conference, LNCS 3714, 2005.
About the author
|
 |
Dr. John D. McGregor is an associate
professor of computer science at Clemson University and a partner
in Luminary Software, a software engineering consulting firm. His
research interests include software product lines and component-base
software engineering. His latest book is A Practical Guide
to Testing Object-Oriented Software (Addison-Wesley 2001). Contact him at
johnmc@lumsoft.com. |
Cite this article as follows: John McGregor: “Ideas from SPLC”,
in Journal of Object Technology, vol. 4, no. 9, November-December 2005,
pp. 23-29, http://www.jot.fm/issues/issue_2005_11/column3.
|
