Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee.
SOFTVIS 2008, Herrsching am Ammersee, Germany, September 16–17, 2008. © 2008 ACM 978-1-60558-112-5/08/0009 $5.00

Applying Visualisation Techniques in Software Product Lines
Daren Nestor, Steffen Thiel, Goetz Botterweck, Ciara´n Cawley, Patrick Healy
Lero, the Irish Software Engineering Research Centre
University of Limerick, Ireland
{daren.nestor, steffen.thiel, goetz.botterweck, ciaran.cawley, patrick.healy}@lero.ie
Abstract
Software product lines of industrial size can easily incorporate
thousands of variation points. This scale of variability can become
extremely complex to manage resulting in a product development
process that bears significant costs. One technique that can be ap-
plied beneficially in this context is visualisation. Visualisation is
widely used in software engineering and has proven useful to am-
plify human cognition in data intensive applications. Adopting this
technique in software product line engineering can help stakehold-
ers in supporting essential work tasks and in enhancing their under-
standing of large and complex product lines.
The research presented in this paper describes an integrated meta-
model and research tool that employs visualisation techniques to
address significant software product line tasks such as variability
management and product derivation. Examples of the tasks are de-
scribed and the ways in which these tasks can be further supported
by utilising visualisation techniques are explained.
CR Categories: D.2.1.3 [Software Engineering]: Reusable
Software—Reuse models; D.2.2 [Software Engineering]: De-
sign Tools and Techniques—Computer-aided software engineer-
ing (CASE); I.3.6 [Computer Graphics]: Methodology and
Techniques—Interaction Techniques;
Keywords: Software product lines, Visualisation, Interaction,
Feature configuration
1 Introduction
In software product line engineering similarities between products
are exploited to reduce the amount of work involved in producing
a new software product. As a result of dealing with products with
similarities software product line engineering has rapidly emerged
as an important software development paradigm during the last few
years.
SPL engineering promises benefits such as “order-of-magnitude
improvements in time to market, cost, productivity, quality, and
other business drivers” [SEI 2008]. Many of these expected ben-
efits rely on the assumption of additional upfront investment in do-
main engineering. This is necessary to create the product-line and
its core assets, and is expected to pay off in the long run because
product derivation based on a product line is (expected to be) more
efficient than development from scratch.
However, to benefit from these productivity gains we have to ensure
that application engineering processes are performed as efficiently
as possible. One way of facilitating this is to support the activities
by providing visual and interactive tools.
Visualisation is widely used in software engineering and has proven
useful to amplify human cognition in data-intensive applications.
Call graphs, for example, are used to represent the internal layout
of programs and to assist the decomposition of legacy systems into
reusable components [Gansner and North 2000]. Adopting visu-
alisation techniques in software product line engineering can help
stakeholders in supporting essential work tasks and in enhancing
their understanding of large and complex product lines.
This paper introduces software product lines and elaborates on vi-
sualisation techniques that support fundamental product line engi-
neering tasks. It advances a research tool that implements various
visualisation and interaction techniques that can support stakehold-
ers in the performance of important software product line engineer-
ing tasks.
The remainder of the paper is organised as follows. Section 2
briefly gives some background on Software Product Lines, explains
difficulties with two of the most error prone processes within soft-
ware product line engineering and provides an overview of the con-
figuration process. Section 3 introduces the integrated meta-model
as a foundation for visual representation of software product lines.
In Section 4 we introduce our visual research tool (VISIT-FC) and
explain the visualisation techniques used within the tool in more
detail. Section 5 explains how VISIT-FC can be used to support
specific product line engineering tasks. Section 6 discusses related
work, and section 7 outlines future directions for this work. Finally,
section 8 concludes the paper.
2 Software Product Lines
A software product line is a set of software intensive systems shar-
ing a common, managed set of features that satisfy the specific
needs of a particular market segment or mission and that are de-
veloped from a common set of core assets in a prescribed way.
This involves strategic, planned reuse that yields predictable re-
sults [Clements and Northrop 2002].
The organisation implementing a software product line plans the
scope of the product family and designs the products to take advan-
tage of the commonality between the various products. During the
design of the product line, the specific differences between products
is also planned, and “variation points” are built into the product line
artefacts. These are locations where variation between members of
the product line will occur. This phase is called Domain Engineer-
ing. Application Engineering refers to the processes involved in
creating products from the existing product line. In short, domain
engineering is development for reuse, application engineering is de-
velopment with reuse.
Two areas within the software product line process that can cause
particular difficulties for practitioners are the management of vari-
ability, and the process of product derivation.
175

Figure 1: Overview of the product configuration process
2.1 Variability Modelling and Representation
Variability refers to the ability of a software product line develop-
ment artefact to be configured, customized, extended, or changed
for use in a specific context [van Gurp et al. 2001]. It thus provides
the required flexibility for product differentiation and diversifica-
tion within the product line.
Numerous models and approaches have been proposed for repre-
senting variability information in various development phases of
a software product line approach, especially in requirements engi-
neering [Halmans and Pohl 2004] and architecture design [Thiel
and Hein 2002]. Possible relationships between features are usu-
ally categorised based on the constraints imposed by the model (for
instance, one feature may exclude or require another). A com-
mon method of representing product line variability is a feature
model [Kang et al. 2002]. A feature diagram is typically repre-
sented as a tree where primitive features are leaves and compound
features are interior nodes.
2.2 Product Derivation
Product derivation is the process of creating a specific product from
the product line. The process of product derivation can be divided
into two phases: the initial phase and the iterative phase [Deelstra
et al. 2005]. The initial phase involves using requirements to drive
the primary derivation of a product using either assembly from ex-
isting components or the selection of the closest existing config-
uration and adapting it to the requirements of the product being
derived. In some cases, an initial configuration sufficiently imple-
ments the desired product. In most cases, however, one or more
cycles through the iterative phase are required for various reasons,
such as requirements changing, the assets having been modified, or
to ensure that communication between the components is working
as expected.
The iterative phase involves adaptation of the selected assets. The
adaptations can be product specific or evolutionary, that is, they can
be specific to this instance of the asset, or they can be shared with
all the members of the product line.
The iterative phase is a particular source of error. Major factors
identified empirically by Deelstra et al. [Deelstra et al. 2005] in-
clude amongst others:
• the large number of errors in parameter settings due to large
amount of parameters with implicit dependencies,
• false-positives during the compatibility test during component
selection,
• the unmanageable number of variation points and variants,
• the lack of hierarchy in the organization of variation points,
• the unpredictable consequences of variant selection.
For instance, in the case study cited above, a business unit identified
parameter settings during the configuration of the assets being used
in a specific product as accounting for approximately 50 percent of
product derivation costs.
Expanding on this, Hotz et al. [Hotz et al. 2006] identified two is-
sues that were at the core of all the problems mentioned. These core
issues were:
• The complexity of the product line in terms of variation
points, variants and dependencies;
• The large number of implicit properties or dependencies as-
sociated with variation points and variants. These tend to be
undocumented or only known to experts.
The issues thus identified imply that the product line asset base can
suffer from combinatorial complexity - that is, the interactions be-
tween assets become extremely complex. This complexity in the
area of variability management is a cause of issues in the product
derivation process, and is one of the areas where the authors feel
that visualisation can be of particular use.
2.3 Process Overview
The benefits of software products lines, e.g., a reduction of costs per
product, can only be achieved if we can derive each product from
the product line as efficiently as possible. However, as indicated in
the preceding section, this process of product derivation is complex
and error prone.
176