Visualizations for the evolution of Variant-Rich Systems: A systematic mapping study

Abstract

Context
Variant-Rich Systems (VRSs), such as Software Product Lines or variants created through clone & own, are created to satisfy different needs while reusing existing assets. The long lifespan of families of variants, and the scale of both the technical side (implementation size) and the organizational side (roles diversity) make their maintenance and evolution a challenge. Visualization tools are a needed companion.

Objective
We aim at mapping the current state of visualization interventions in the area of VRS evolution. We tackle evolution in both the functionality and the variability management architecture. Three research questions are posed: What sort of analysis is being conducted? (Analysis perspective); What sort of visualizations are displayed? (Visualization perspective); What types of research have been reported and how have they been evaluated? (Maturity perspective).

Methods
We performed a systematic mapping study including automated search in digital libraries, expert knowledge, and snowballing.

Results
The study reports on 41 visualization approaches to cope with VRS evolution. Analysis wise, feature identification and location is the most popular scenario, followed by variant integration towards a Software Product Line. As for visualization, nodelink diagram visualization is predominant while researchers have come up with a wealth of ingenious visualization approaches. Finally, maturity wise, almost half of the studies are solution proposals. Most of the studies provide proof-of-concepts, some of them also include public available tools, yet very few face proof-of-value.

Conclusions
This systematic mapping study introduces a comparison framework where to frame future studies. It also points out distinct research gaps worth investigating as well as shortcomings in the evidence about relevance and contextual considerations (e.g., scalability).

Full text

Information and Software Technology 154 (2023) 107084
Available online 29 September 2022
0950-5849/© 2022 The Author(s). Published by Elsevier B.V. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).
Contents lists available at ScienceDirect
Information and Software Technology
journal homepage: www.elsevier.com/locate/infsof
Visualizations for the evolution of Variant-Rich Systems: A systematic
mapping study
Raul Medeiros a,∗
, Jabier Martinez b, Oscar Díaz a, Jean-Rémy Falleri c
aUniversity of the Basque Country (UPV/EHU), San Sebastián, Spain
bTecnalia, Basque Research and Technology Alliance (BRTA), Derio, Spain
cLaBRI, UMR 5800, F-33400, IUF, Talence, France
ARTICLE INFO
Keywords:
Variant-rich systems
Software product lines
Visualization
Evolution
Maintenance
Mapping study
ABSTRACT
Context: Variant-Rich Systems (VRSs), such as Software Product Lines or variants created through clone &
own, aim at reusing existing assets. The long lifespan of families of variants, and the scale of both the code
base and the workforce make VRS maintenance and evolution a challenge. Visualization tools are a needed
companion.
Objective: We aim at mapping the current state of visualization interventions in the area of VRS evolution.
We tackle evolution in both functionality and architecture. Three research questions are posed: What sort of
analysis is being conducted to assess VRS evolution? (Analysis perspective); What sort of visualizations are
displayed? (Visualization perspective); What is the research maturity of the reported interventions? (Maturity
perspective).
Methods: We performed a systematic mapping study including automated search in digital libraries, expert
knowledge, and snowballing.
Results: The study reports on 41 visualization approaches to cope with VRS evolution. Analysis wise, feature
identification and location is the most popular scenario, followed by variant integration towards a Software
Product Line. As for visualization, nodelink diagram visualization is predominant while researchers have come
up with a wealth of ingenious visualization approaches. Finally, maturity wise, almost half of the studies are
solution proposals. Most of the studies provide proof-of-concept, some of them also include publicly available
tools, yet very few face proof-of-value.
Conclusions: This study introduces a comparison framework where to frame future studies. It also points
out distinct research gaps worth investigating as well as shortcomings in the evidence about relevance and
contextual considerations (e.g., scalability).
1. Introduction
Software evolution is a major issue in software engineering [1]. Its
understanding involves facing large amounts of data from heteroge-
neous data sources including version control systems, bug tracking sys-
tems, mailing and project discussion lists, as well as the implementation
assets themselves. Software evolution research interests include to build
theories and models that allow grasping the past and present, while
predicting future properties, and hence, supporting software mainte-
nance and evolution [1]. In this realm, our endeavours can be framed
along two dimensions: the purpose of the evolution (i.e., evolution in
functionality, e.g., perfective maintenance, or evolution in architec-
ture, e.g., refactoring) and the subject of evolution (i.e., variant-rich
systems).
∗Corresponding author.
E-mail addresses: raul.medeiros@ehu.eus (R. Medeiros), jabier.martinez@tecnalia.com (J. Martinez), oscar.diaz@ehu.eus (O. Díaz), falleri@labri.fr
(J.-R. Falleri).
A Variant-Rich System (VRS) consists of a family of software prod-
ucts (aka portfolio) that serves a particular market segment or context
while sharing commonalities and variabilities among them in their
functions or behavior. Depending on the automation level (ad-hoc vs.
systematic), there are different strategies for managing VRSs, ranging
from clone & own to Software Product Lines (SPLs) [2]. VRS evolution
tends to be more frequent and complex than its one-off application
counterpart. Frequency wise, evolution episodes are more numerous
since the functionality scope is not that of a single product but of
a family of products (aka a domain). On top of that, evolution is
not limited to the functionality itself. The gradual enlargement of the
functionality might require to be accompanied by the evolution of the
system architecture (e.g., moving from clone & own to SPLs [3]). Both
https://doi.org/10.1016/j.infsof.2022.107084
Received 14 January 2022; Received in revised form 18 September 2022; Accepted 22 September 2022

Information and Software Technology 154 (2023) 107084
2
R. Medeiros et al.
higher frequency and more complex evolution scenarios substantiate
the need for visualization assistance even to a larger degree than
in one-off software development, and, specifically, the use of Visual
Analytics [4].
Visual Analytics is defined as the science of analytical reasoning
facilitated by interactive visual interfaces [4]. The basic idea is to
visually represent the data to allow humans to directly interact with the
information, to gain insights, and to ultimately make optimal decisions.
Broadly speaking, Visual Analytics helps create a path from data to
decision. In this process, visualization plays a twofold role [5]:
•as an abstraction medium, by highlighting certain constructs and
relationships while ignoring others,
•as an interaction medium, by supporting the workflows for deci-
sion making.
Hence, interventions based on this approach are characterized in terms
of both the analysis they allow, and the visualizations they support. On
these premises, this work introduces the following research questions:
•RQ1: What sort of analysis is being conducted to assess VRS evolu-
tion?
•RQ2: What sort of visualizations are displayed?
•RQ3: What is the research maturity of the reported interventions?
We answer these questions through a systematic mapping study.
A systematic mapping study is an evidence-based form of secondary
study. Systematic mapping studies intend to provide a broad overview
of a study domain, as well as to determine whether or not research
evidence exists on a certain issue and to estimate its amount [6].
To the best of our knowledge, no previous work has characterized
VRS literature along with the aforementioned research questions. We
extracted data for 234 potentially relevant articles using academic
article search engines. After a careful screening of these articles, we
identified 41 primary sources.1
The rest of the paper is structured as follows. Section 2presents
related reviews. Section 3describes the background. Section 4intro-
duces the research design, and Section 5describes the data extraction.
Sections 6,7and 8present the results while Section 9discusses them.
Then, Section 10 presents the threats to validity. Finally, Section 11
concludes the paper.
2. Related work
Several studies have surveyed the literature on software visualiza-
tion, namely:
•Kienle and Müller look into requirements to build and evaluate
tools in software visualization along with three main activities:
maintenance, re-engineering, and reverse engineering [7].
•Shahin et al. investigated software visualizations but for under-
standing software architectures [8].
•Chotisarn et al. conduct a systematic review along two main con-
cerns: software aspect to be visualized (i.e., structure, behavior
and evolution) and software process to be supported (i.e., soft-
ware requirements, software design and implementation, soft-
ware validation, software maintenance) [9].
•Novais et al. review the visualization of software evolution from
a global perspective [10].
•Lopez-Herrejon et al. focus on visualization approaches to support
a broad range of Software Product Line activities [11].
1A gallery of the visualizations of the 41 primary sources (taken from
the respective papers) is available for research purposes at https://doi.org/
10.5281/zenodo.7057654.
Table A.15 provides more details on the mentioned surveys. In
their tertiary study on research in Software Product Lines (SPLs) [12],
Raatikainen et al. notice that [11] and its previous version [13],
are the only ones which tackle visualization in SPLs, departing from
visualization in one-off development. Compared with Lopez-Herrejon
et al.’s work, our mapping is more specific as we focus on evolution.
Yet, our interest is broader since we encompass VRSs no matter their
stage in the evolution maturity journey (e.g., clone & own) and not
only SPLs. This introduces a main distinctive concern that is not limited
to the ‘evolution in functionality’ but also expands to ‘evolution in
architecture’. This results in [11] considering 37 primary sources while
ours had 41 with an overlap of 12 primary sources.
3. The mapping space
Visual Analytics is defined as the science of analytical reasoning
facilitated by interactive visual interfaces [4]. Accordingly, primary
sources are characterized along two major dimensions: the analysis
dimension and the visualization dimension. We add a third dimension:
the maturity of the visualization proposal. Along with good practices in
mapping studies, this section resorts to literature-backed classification
schemas that will be used to characterize the primary sources along
these three dimensions.
3.1. Dimension 1: Analysis scenarios
This analysis dimension considers the subject (aka ‘object’, ‘artifact’)
to be analyzed, and the purpose of the analysis.
The subject of evolution. VRSs face variability at different degrees
of automation (ad-hoc vs. systematic) through different implemen-
tation mechanisms: annotative approaches like pre-processor direc-
tives [14] or feature toggles [15]; compositional approaches such as
source code super-imposition and merge [16]; generative program-
ming [17], feature-oriented programming [18,19], aspect-oriented pro-
gramming [20] or delta-oriented programming [21]. The binding time
of the variability is also relevant ranging from design-time to run-
time, the latter enabling the creation of self-adaptive systems (aka
Dynamic SPLs [22]). We use the umbrella term ‘VRSs’ to denote this
broad diversity of cases, from almost independently created variants
(i.e., clone & own), to highly-configurable systems, SPLs and Dynamic
SPLs.
The purpose of evolution. VRSs can evolve not only in their
functionality but also in their architecture. At the onset, an organi-
zation might capture variations through ‘if-then’ statements, where
‘if’ conditions are evaluated at runtime against a configuration file.
Here, a single artifact handles all functionality, no matter whether it
is statically known that a configuration option will never be selected
in a certain scenario. Alternatively, variations can be supported as
distinct variants (products). While the number of variants is small,
clone & own might be an effective architecture. However, as the
variants increase, clone & own ends in replication and propagation
challenges [2]. Engineers can opt to move to Conditional Compilation.
Here, variants are enclosed within #ifdef and #endif marks, and asso-
ciated with pre-compilation directives, i.e., boolean expressions upon
‘configuration parameters’. This allows for configuration-dependency
checking to be outsourced from the application code to dedicated
configurators. Finally, as the number of features and variants increase,
a more systematic approach is needed. This might end up in an SPL.
This diversity in both the subject and the purpose gives rise to
distinct scenarios where engineers are confronted with VRS evolution.
Next, we revise Struber et al.’s evolution scenarios [23]. For each
scenario, we present: the setting where this scenario arises and an
example of a visualization intervention that (partially) tackles these
needs. We selected the examples arbitrarily based on visualization
variety, maturity, and clarity.

Information and Software Technology 154 (2023) 107084
3
R. Medeiros et al.
Fig. 1. Variant Synchronization. Using similarity analysis, this tool identifies common, shared and unique artifacts among variants. On the upper left side, the visualization shows
a similarity distribution of 6 variants. Colors represent the degree of commonality of the artifacts: green (common), cyan (shared) and yellow (unique). On the upper right side,
a treemap groups the shared lines of code regarding the number of products where they are present. On the bottom left side, the similarity distribution is displayed within each
implementation element (i.e., package or folder) allowing a more focused structural exploration. Finally, on the bottom right corner, a phylogenetic distance diagram provides
information about which variants are more similar. Figure credits [S1]. (For interpretation of the references to color in this figure legend, the reader is referred to the web version
of this article.)
3.1.1. Variant Synchronization (VS)
Setting. Clone & own and variant-based evolved SPLs. When bug
fixes or feature implementations are made in one variant, they need
to be propagated to other variants. During Variant Synchronization, it
is important to identify the variants affected by a bug fix or a feature
upgrade. To this end, criteria such as the cost of the propagation or the
importance of the variant can be used.
Example. Variant synchronization benefits from visualizing the
distribution of the lines of code of each variant in terms of ‘core’,
‘shared’, or ‘unique‘. In this way, if a bug is fixed in the ‘shared’ part
of a variant it becomes a candidate to be rippled across the other
variants sharing the same code. This approach is followed in [S1] using
set-based similarity analysis (see Fig. 1).
3.1.2. Variant Integration (VI)
Setting. Variant-based evolved SPLs. Here, application engineers
are allowed to tune the codebase to meet the specifics of a variant
without waiting for this specific to be introduced in the SPL platform.
Bug fixes or urgent customer requests might not wait for being con-
ducted at the SPL platform, and hence, they are branched off into
a separate codebase. Eventually, these branches need to be merged
back into the SPL Master. Being variants from the same SPL, they are
based on the very same core assets, and hence, bug fixes or functional
enhancements undertaken for a variant might well serve other variants.
Here, application engineers need to be aware of potential coordination
problems right during coding rather than deferring it until merging
time.
Example. PeeringHub [S2] (see Fig. 2) advocates for making appli-
cation engineers aware of potential coordination problems right during
coding rather than deferring it until merge time. To this end, PeeringHub
introduces the notion of ‘peering bar’ for GitHub. These visual bars
reflect whether the codebase of a variant’s feature is being upgraded
in other variant branches. PeeringHub helps by making developers
aware of potential coordination problems right during variant coding
rather than deferring it until variant specifics are merged back into the
platform master.
3.1.3. Feature Identification and Location (FIL)
Setting. Migration from clone & own to an SPL platform. Feature
identification aims to determine which features are present, while fea-
ture location tackles the relationship between features and assets. De-
velopers may wish to determine which features already exist in the sys-
tem and which features are implemented in which assets (e.g., source
code, models, requirements, or other types of artifacts) as a means of
better supporting clone & own development as well as preparing for
the migration to an SPL platform.
Example. During the migration from clone & own to an SPL plat-
form, SPL engineers might need to identify which parts of the variants
are common and which ones are specific. Fig. 3 shows a visualization
that uses clone detection for this purpose. The visualization shows the
parts of the source code that are common (red), variant specific (white),
and those that might be shared among some variants but not all (light
red). This way, the user can interact with the results (e.g., focusing on
specific source code files) and identify mandatory features and features
that only appear in a given variant or a set of variants [S3].
3.1.4. Constraints Extraction (CE)
Setting. Migration from clone & own to an SPL platform. On
the way towards an SPL, meaningful sets of functional requirements
are named as a ‘feature’. Features hold dependencies among them: a
feature might require/exclude other features. This information might
not be initially known. Developers might be assisted through an au-
tomated constraint extraction approach. Constraint extraction exhibits
two needs. First, it has to be easy to identify which constraints are
already formalized. Secondly, constraints extraction techniques are
not 100% accurate, and hence, means are needed for measuring the
confidence of the extracted constraints.
Example. Feature Relation Graphs (FRoGs) [S4]. Fig. 4 places the
feature under analysis at the center while the rest of the features
are disposed at a distance based on the frequency they appear to-
gether in the available configurations. It can be used to discover
non-formalized ‘requires’ and ‘excludes’ constraints between features as
well as soft-constraints such as one feature ‘encourages’ or ‘discourages’
another.

Information and Software Technology 154 (2023) 107084
4
R. Medeiros et al.
Fig. 2. Variant Integration. PeeringHub mimics GitHub topic bar but now colors denote code churns per feature within a branch. Branches hold temporary developments of variants
(e.g., productDenmark) before being merged back into the Master. In the example, the PeeringBar hints at code efforts being conducted for the variant productDenmark, specifically,
for features WindSpeed,English,AirPressure, etc. In this way, if you are upgrading namesake features, you better engage with your productDenmark colleagues to prevent later
conflicts during merging. Figure credits [S2]. (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)
Fig. 3. Feature Identification and Location. The visualization consists of a heatmap inside a treemap. The treemap represents the structure of each variant’s artifacts, while the
heatmap represents the degree of commonality of each variant implementation artifact. Using the colors, a developer can identify the parts of the source code that are common
(red), the parts that are product specific (white), and the parts that might be shared among some product variants but not by all of them (light red). Figure credits [S3]. (For
interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

Information and Software Technology 154 (2023) 107084
5
R. Medeiros et al.
Fig. 4. Constraint Extraction. Feature Relation Graphs use nodelink diagrams on top of a radial network. Nodes represent feature names. The node in the center is the feature under
analysis while the arrangement of the others represents the relationship they have with the central feature. Concretely, the arrangement represents three types of relationships:
type of constraint (proximity to the center), stakeholder perspective (radial position), and level of formalization (edge type). Using the visualization, developers identify potential
feature constraints related to the feature under analysis. Figure credits [S4]. (For interpretation of the references to color in this figure legend, the reader is referred to the web
version of this article.)
Fig. 5. Architecture Recovery. When it comes to integrating a set of existing similar variants on the way towards an SPL, it is essential to abstract a common architecture. This
visualization abstracts from the variants’ component architecture to highlight the variance presence. The component diagram depicts which modules are present in several variants
(list of names) and to which extent the module is similarly implemented (bar chart). Figure credits [S5].
3.1.5. Architecture Recovery (AR)
Setting. Migration from clone & own to an SPL platform. While
feature models capture functionality dependencies, architectural mod-
els focus on the dependencies of implemented classes or components.
Automatic extraction of architectural dependencies can be assisted
through architecture recovery techniques. Architecture Recovery can
be performed from a configurable platform or from a set of variants.
Example. Building a platform architecture out of existing variants
is error-prone and tedious. Fig. 5 introduces a visualization that ab-
stracts and aggregates this information. Commonalities and variabilities

Information and Software Technology 154 (2023) 107084
6
R. Medeiros et al.
Fig. 6. Transformation. FeatureVisu uses a nodelink visualization built on top of a clustering method to depict the feature cohesion metric. For instance, on the left side, we can
observe how the implementation elements of the feature BaliBuild (green) are more cohesive than those of the features Bali (blue) and CodeGen (red). On the right side, we
can observe an excerpt of the previous layout but this time showing the dependency links between the implementation elements. Figure credits [S6]. (For interpretation of the
references to color in this figure legend, the reader is referred to the web version of this article.)
among variant architectures are captured from two perspectives: vari-
ance presence (i.e., if the existence of the module is variable or not)
and variance realization (i.e., if the implementation of the module is
different across variants) [S5].
3.1.6. Transformations (TR)
Setting. Evolution of an SPL platform. The developer can use trans-
formation techniques to decrease manual effort during evolution activ-
ities. Transformation techniques include refactoring and partial refac-
toring of an SPL platform. For instance, high cohesion of a feature is
a desired property and a relevant motivation for refactoring. For this,
developers look to what extent implementation elements of a feature
depend on each other, minimizing external dependencies.
Example. FeatureVisu (see Fig. 6) supports feature cohesion by
creating clustering among features with a high cohesion.
3.1.7. Functional Testing (FT)
Setting. Clone & own and SPL platforms. Regression testing aims
at ensuring that an application still functions as expected after any
code changes. In view of the impossibility of testing hundreds of
features and variants, deciding which features and configuration to
test becomes critical. To tame this scalability issue, testers resort to
distinct heuristics: hot spots (i.e., the larger the change, the more likely
the impact) or variant similarity comparison analysis to increase test
coverage.
Example. FeatureCloud (see Fig. 7) is a tree-cloud visualization to
identify hot-spot features, i.e., features undergoing substantial change
in their codebase, i.e., ifdef blocks. FeatureCloud depicts feature change
along three metrics: LOC (color opacity), scattering (font size), and
tangling (position in the word cloud). Using FeatureCloud, developers
identify which features had complex updates and thus, might require
more dedicated testing.
3.1.8. Analysis of Non-Functional Properties (ANF)
Setting. Clone & own and SPL platforms. VRSs are common among
cyber–physical systems where non-functional requirements are key
(e.g., performance in a safety–critical system, memory consumption
in an embedded system with resource constraints). In safety–critical
domains, engineers might need to explore which variants are optimal
for their goals. This might require the analysis of the impact of fea-
tures and feature interactions on quality properties, optimization of
configurations towards attaining a given quality criteria, and analysis
of trade-offs among non-functional properties.
Example. Fig. 8 presents a bubble chart to analyze optimal vari-
ants: variants are located based on four custom non-functional metrics
(battery-life, security, productivity and cost).
3.1.9. Co-evolution of Problem Space and Solution Space (CPS)
Setting. Compared to the evolution of one-off applications, VRS
evolution introduces additional challenges since the evolution should
be synchronized across a potentially high number of variants [2]. The
inter-dependency between these variants varies from highly-indepe-
ndent (e.g., the clone & own approach where ‘clones’ might evolve
totally independently from its ancestor) to totally-dependent variants
(e.g., configurable software-product lines where new variant require-
ments should be first considered at the core platform before impacting
the variants). An automated approach may suggest co-evolution activ-
ities to maintain the two spaces in sync. This scenario includes both
evolving the solution space based on the problem space, and vice-versa.
Example. New feature dependencies may be reflected uniquely in
the code without being mirrored in the feature model due to devel-
opment urgency during SPL evolution. Fig. 9 presents a visualization
that identifies dissonances between the problem and the solution space.
The visualization displays inconsistencies between the current feature
model and its implementation through different views: the dependency
matrix shows inconsistencies between feature dependencies in red (top-
right); the feature model shows suggested feature dependencies with
colored lines (middle-right); the code-view displays the feature imple-
mentation (middle-left); and finally, the nodelink diagram depicts the
code-level interactions (bottom).
3.2. Dimension 2: Visualization approach
Visualization can be regarded as the intervention to cope with
increasingly complex evolution scenarios. By introducing Visual Analyt-
ics, decision makers can focus their attention on visualization-enabled
analytical reasoning while benefiting from automatic data processing
techniques. This dimension can be characterized along with the sort of
interaction type [24] and the visualization strategy [10].

Information and Software Technology 154 (2023) 107084
7
R. Medeiros et al.
Fig. 7. Functional Testing. FeatureCloud helps identify hot-spot features, i.e., features undergoing substantial changes in their codebase from the last release of the SPL platform.
FeatureCloud takes the code churn, and extracts the pre-compilation directives from the associated ifdef blocks. On these grounds, the tool generates a word-cloud using feature
names as words, and pre-compilation directives as phrases. Nodes stand for features. Color opacity, font size, and distribution of nodes denote the size of the change, the scattering
degree and the tangling degree, respectively, for the feature at hand. Take the case of feature AUTO_BED_LEVELING_UBL (right-upper corner in the screenshot). From the last
release, this feature has been subject to few changes (light-blue color). Yet, testing is guessed to be complicated. First, this feature’s changes are scattered along distinct ifdef blocks
(as reflected by the medium font size). Second, these changes pertain to ifdef blocks whose pre-compilation directives involve feature AUTO_BED_LEVELING_UBL but also other five
features that are depicted in the same radial branch, e.g., EEPROM_SETTING. Figure credits [S7]. (For interpretation of the references to color in this figure legend, the reader is
referred to the web version of this article.)
Fig. 8. Analysis of Non-Functional Properties. Bubble Front Graphs display four custom quality (non-functional) metrics in a bubble chart. This way, users can select the optimal
variants based on those quality metrics. The chart uses four dimensions to represent those quality metrics: horizontal axis X (bottom), the vertical axis Y (left), bubble color Z (top)
and bubble size 𝑇(right) to visualize up to four quality dimensions simultaneously. In the figure, productivity is represented as a vertical coordinate (Y); batterylife is represented
as a horizontal coordinate (X); security is represented as a color (Z); and cost is represented as a size (T). Figure credits [S8]. (For interpretation of the references to color in
this figure legend, the reader is referred to the web version of this article.)

Information and Software Technology 154 (2023) 107084
8
R. Medeiros et al.
Fig. 9. Co-evolution of Problem Space and Solution Space. This visualization guides developers on the evolution of the feature model by showing them inconsistencies between the
current feature model and its implementation. The top-right matrix displays the inconsistencies (marked in red). The visualization also suggests feature-level dependencies which
are shown in the feature model on the middle-right (colored lines). Developers can also consult the implementation of the selected feature on the upper-left part and check its
code-level dependencies in the nodelink diagram on the lower part. Figure credits [S9]. (For interpretation of the references to color in this figure legend, the reader is referred
to the web version of this article.)
Visualization interaction. Yi et al. introduce the following interaction
schema [24]:
•Filter. When the visualization allows users to specify several con-
ditions that the data that is shown must satisfy.
•Select. When the visualization provides users with the ability to
focus on a specific data item(s).
•Abstract/Elaborate. When the visualization provides users with the
functionality of adjusting the abstraction/detail level of the data.
•Connect. When the visualization provides users with the option of
checking associations and relationships between data items.
•Explore. When the visualization enables users to explore a differ-
ent subset of data items.
•Reconfigure. When the visualization allows users to watch differ-
ent perspectives by rearranging the data.
Visualization strategy. Novais et al. introduce the following strategy
schema [10]:
•Temporal Snapshot (TS). It represents a snapshot of the software
at a specific point in time.
•Temporal Overview (TO). It displays all of the values of the de-
velopment of a particular metric for all of the software entities
being examined. This complicates the presentation since we must
represent several entities (e.g. software modules) in a single visual
picture, as well as the temporal evolution of one or more of their
properties (e.g. size).
•Temporal Accumulative Snapshot (TA). It considers the absolute
value of changes to study the evolution of the program. It is
commonly employed in the study of software churn [25].
•Differential Relative (DR). It expresses the increase or decrease in
a software module’s property. If a software feature f1 increased
its scattering by 2 points, but another feature f2 increased it by 4,
then the DR representation should graphically show that f2 grew
more than f1. In a similar way, decrements should be presented.
•Differential Absolute (DA). When the definition of growth or re-
duction does not apply, the absolute strategy comes in handy. It
is focused on recognizing and representing discrete events, such
as entity properties that have appeared or vanished from one
software version to the next.
3.3. Dimension 3: Research maturity
No matter the analysis nor the visualization, an important insight is
the extent of the evidence of the intervention utility. To this end, we
resort to two existing classifications for Research Type [26] and Evalu-
ation Method [27]. In addition, we consider the Publication Venue as
an additional proxy of the research maturity.
Research type. Wieringa et al. introduce the following research type
schema [26]:
•Evaluation research. Explains a method of evaluating research that
involves assessing how a solution works in practice or comparing
it to other solutions while highlighting positive and negative as-
pects. It is more comprehensive than validation and is frequently
performed in an industrial context.
•Validation research. Describes the validation of a research that
has not yet been implemented in practice, for example, by an
experiment, the performance of tests, lab experiments, and so on.
It usually comes after a proposal for a solution.
•Proposal of solutions. Without a thorough validation, these works
suggest a solution approach and argue for its utility. The approach
must be new, or at the very least a considerable improvement on
one that already exists. A proof-of-concept might be presented in
the form of a simple example, a compelling argument, or another
method.
•Philosophical papers. These publications propose a new way of
thinking, a new conceptual framework, etc.

Information and Software Technology 154 (2023) 107084
9
R. Medeiros et al.
Fig. 10. Primary sources selection process.
•Personal experience papers. Represent the authors’ experience, gen-
erally in practice, with a particular method, technology, or other
device. These papers are frequently authored by industry profes-
sionals.
Evaluation method. Stol and Fitzgerald introduce the following schema
[27]:
•Field Studies. Any research undertaken in a specific, real-world
situation to explore a specific software engineering issue.
•Field Experiments. Experimental studies conducted in a natural
setting with a high degree of realism (similar to a field study), but
this evaluation method reduces the level of realism compared to
a field study because the researcher manipulates some properties
or variables in the research setting in order to observe an effect
of some kind.
•Experimental Simulations. In this kind of evaluations, the behaviors
of actors (e.g., developers, users, or software systems) that a
researcher aims to observe and measure in experimental simula-
tions are natural, but the setting in which they occur has been
specifically created for the purposes of the study—that is, the
setting would not exist if the study did not exist.
•Laboratory Experiments. Laboratory experiments differ from field
experiments in that field experiments explore phenomena in their
natural setting, whereas laboratory experiments are conducted in
a controlled environment.
•Judgment Studies. These studies entail obtaining empirical data
from a group of people who are asked to assess or rate actions,
reply to a researcher’s request or ‘stimulus’, or debate a particular
topic of interest.
•Sample Studies. These are studies that try to attain generalizability
across a certain demographic or set of factors, such as software
professionals, software systems, or development process artifacts.
•Formal theory. This is a way of evaluation that aims for a high
level of universality so that the resultant theory or framework
may be used in a wide range of situations, even though most
theories have boundaries beyond which they do not apply.
•Computer Simulation. Studies that replicate a real-world phe-
nomenon or setting using a computer. These kinds of studies
are like virtual laboratory experiments where hypotheses can be
tested.
Publication venue. We distinguish between four different venue types:
journals, conferences, workshops and symposiums.

Information and Software Technology 154 (2023) 107084
10
R. Medeiros et al.
4. Research design
The goal of this study is to review the visualization interventions
that have been proposed to assist in the maintenance and evolution of
VRSs. To this end, we follow the recommendations presented in [6].
This section describes the plan for each step of the study, including
the research questions, academic databases and search strategy, and
inclusion/exclusion criteria.
4.1. Research questions
RQ1: What sort of analysis is being conducted to assess VRS evo-
lution?. RQ1 takes an analysis perspective. In accordance with the
Goal-Question-Metric (GQM) model, an analysis is conducted by an
agent with a purpose through a set of questions grounded on a collec-
tion of metrics [28]. Accordingly, we could characterize studies based
on the agent (‘target role’), the purpose (‘evolution scenario’), and the
support provided by the tool to conduct the analysis (‘added-value’).
We can then refine RQ1 as follows:
•RQ1.1: Which are the target roles involved?
•RQ1.2: What are the evolution goals being pursued?
•RQ1.3: What is the added-value provided by the tool?
RQ2: What sort of visualization are displayed?. RQ2 takes a tool
perspective. The question intends to find out what kind of visualization
tools are used on VRS evolution and what are the elements used to build
them. This question can be refined as follows
•RQ2.1: What are the elements being visualized?
•RQ2.2: Which visualization techniques are used?
•RQ2.3: Which sort of visual interactions are catered for?
•RQ2.4: What visualization strategies are used?
•RQ2.5: What data sources are used to build which visualizations?
•RQ2.6: To what extent is VRS scalability considered in each evolution
scenario?
RQ3: What is the research maturity of the reported interventions? No
matter the analysis nor the visualization, this question sheds light on
the degree of maturity of the primary sources.
4.2. Search strategy
Search string. Along the lines of Kitchenham et al. [6], we broke down
the question into individual facets, namely, VRS as ‘the population’,
evolution as ‘the aim’, and ‘Visual Analytics’ (i.e., visualization) as
‘the intervention’. We searched for synonyms. In addition, we noticed
that ‘maintenance’ and ‘evolution’ are terms that are arbitrarily in-
terchanged. We also noticed that visualization is often expressed in
other forms such as ‘visual’ or ‘visualizing’. Hence, we included visual
with a wildcard *. What was more elusive was the notion of VRS as it
encompasses areas such as product lines, variability management and
configurable systems. This resulted on the following search string:
(‘‘evol*’’ OR ‘‘maint*’’) AND (‘‘visual*’’) AND
(‘‘product line’’ OR ‘‘feature model’’ OR ‘‘variability
management’’ OR ‘‘configurable system’’)
Academic databases. Primary sources were obtained by querying the
following databases: Scopus,2ACM Digital Library,3IEEEXplore,4Sci-
enceDirect5and Wiley Online Library6(see the top of Fig. 10). We did
not query Google Scholar and SpringerLink as they lacked the advanced
query functionality we needed.
2https://www.scopus.com/.
3https://dl.acm.org/.
4https://ieeexplore.ieee.org/.
5https://www.sciencedirect.com/search.
6https://onlinelibrary.wiley.com/.
Fig. 11. Distribution of the primary sources per year.
Search scope. Search was conducted upon papers’ title, abstract, and
keywords. To check the validity of the search string, we manually
double checked a few articles.
4.3. Protocol
Fig. 10 outlines the process. We ran the query on the 17th of
September of 2021. We obtained an initial set of 234 papers from
which 24 belonged to the papers manually selected by the authors. At
the onset, we removed duplicated papers (40) and secondary studies.
This resulted in 189 candidate papers (‘Candidate papers’). We reserved
secondary studies for a snowballing phase.
Candidate papers (189) went next through a filtering process. The ti-
tle and the abstract were carefully read by two researchers (the first two
authors). In case of doubt, the introduction and conclusion, or even the
full content of the paper was also read. Each paper was filtered based on
the inclusion and exclusion criteria described in Table 1. Snowballing
was conducted for the remaining 35 papers that provided an addition of
6 papers. This gives a total of 41 primary sources. To minimize potential
biases on the selection process, two other researchers (the last two
authors) were involved when doubts or disagreements arouse between
the other two researchers. This happened for 15 papers. Finally, two re-
searchers (the two first authors) carried out the data extraction process.
Each paper classification was surveyed by at least another researcher.
Fig. 11 shows the distribution of the primary sources publication per
year. It suggests a sustained effort throughout with an average of 2.75
publications per year.
5. Data extraction & Paper classification
Data from primary sources was extracted along the template in
Table 2. The table indicates the Research Questions, the items ex-
tracted to answer them, the domain (‘type of data’) and cardinality
(‘multivalued’) of these items and the section where the information
item is described. Besides the literature-backed classification schemas
introduced in Section 3, new ones were derived from the data itself
(ad-hoc schemas). That is, if an existing scheme did not exist, thematic
analysis was conducted by grounding classification themes on quotes
extracted directly from the primary sources. Next, we review these
ad-hoc schemas.
RQ1.1: Target role. Regarding ‘target role’, a main distinction in SPLs
is between domain engineers and application engineers. As the review
scope is not limited to SPLs but includes VRSs in general, we conducted
a fine-grained categorization of ‘target roles’ through a coding step
(i.e., grouping equivalents, synonyms, and assigning ids). We identified
six categories, namely:
•Application Engineers: The people who develop variants out of
existing code. Primary sources refer to them as either ‘application
engineer’ or ‘product developer’.
•Domain Engineers: The people who develop code to be reused. Pri-
mary sources refer to them as ‘SPL architects’, ‘domain engineers’
or ‘product line maintainer’.

Information and Software Technology 154 (2023) 107084
11
R. Medeiros et al.
Table 1
Exclusion and inclusion criteria.
Type Criteria
Inclusion criteria - Focus on topic – The study focuses on evolution or maintenance.
–The study focuses on variant-rich systems.
–The study proposes/uses some kind of graphical visualization technique to support evolution activities
Inclusion criteria - Quality guarantee – The study is peer reviewed
Exclusion criteria - Type of paper – The study is in a language other than English
–The study is a previous version of another study in the review
–The work is a Secondary study such as a literature review
Exclusion criteria - Characteristics of the approach – The visualization is not tool supported. We only focus on visualizations that have an implementation
behind them, e.g., we exclude manually created graphs
Table 2
Data extraction template.
RQ Extracted item Type of data Multi-valued Described at
RQ1 Analysis scenarios Yes Yes Section 3.1
Target roles Ad-hoc schema Yes Section 5
Added-value Ad-hoc schema Yes Section 5
RQ2 Visualized elements Ad-hoc schema Yes Section 5
Visualization technique Ad-hoc schema Yes Section 5
Visualization interaction Existing schema Yes Section 3.2
Visualization strategies Existing schema Yes Section 3.2
Data sources Ad-hoc schema Yes Section 5
RQ3 Research type Existing schema No Section 3.3
Evaluation method Existing schema Yes Section 3.3
Tool availability Free text No Section 5
Metadata General meta-data Free text No Section 5
•Software Engineers: This code is used when authors do not make
a clear distinction between Application Engineers and Domain
Engineers. This code abstracts from quotes referring to either
‘engineers’ or ‘code developers’.
•Requirement Engineers: This code is used when the primary sources
explicitly mention that the tool targets people in charge of re-
quirement engineering activity. Primary sources refer to them as
‘requirement engineer’ or ‘scope analyst’.
•Testers: Here, authors mention that the tool targets testers or it is
used for testing purposes.
•Project Managers: The people in charge of the planning, schedul-
ing, budgeting, execution, and delivery of a software. This code
abstracts from quotes referring to either ‘managers’, ‘change con-
trol board’ or ‘product line managers’.
RQ1.3: Added-value. This facet accounts for the degree of support
provided by the visualization from merely displaying the raw data
to engineering analysis workflows as part of the tool offerings. Codes
follow:
•Raw. When raw elements are used in the visual analysis (e.g., code-
base), at best, tool interactions are limited to provide some sort
of data aggregation,
•Metric. When metrics are computed from the raw elements as
proxies for the analysis (e.g., number of methods, feature cohe-
sion),
•Analysis. When some sort of analysis is being conducted out of the
metric (e.g., data-flow analysis, feature-location analysis).
RQ2.1: Visualized elements. Visualized elements may coincide with
the data sources. Sometimes however, elements such as features are
abstracted out of the code without the existence of a feature model.
RQ2.3: Visualization technique. Examples of visualization techniques
include nodelink diagrams, heatmaps, bubble charts, etc.
RQ2.5: Data sources. This includes [10], namely: ‘source code’ (e.g., the
SPL platform codebase or the variant codebase, if available), ‘fea-
ture model’,‘variant configuration model’, other model-based artifacts
(e.g., UML notation such as architectural-component diagrams or state-
transition diagrams), ‘traceability links’ (feature-code traces, requirement-
variant traces), ‘project documentation’ (requirements or design docu-
ments), ‘VCS meta-data’ (commits, issues), and the ‘run-time context’
(logs).
RQ3.3. Tool availability/replicability. We checked the availability of the
visualization tool (source code or installer package). First, we searched
for an URL in the paper that would take us to the tool. If broken, we
contacted the authors asking for an active link. If the link was not
present, we googled it using the tool name as the search string.
General meta-data. We recovered the venues and publication years for
the primary sources.
6. Results for RQ1: What sort of analysis is being conducted to
assess VRS evolution?
An analysis is conducted by an agent (‘target role’) with a purpose
(‘evolution scenario’) assisted by a visualization tool (‘added-value’).
We delve into each of these characteristics.
6.1. Target roles
Table 3 outlines the extent each target role is being referred to in the
primary sources. ‘Domain engineers’ and ‘application engineers’ get the
lion’s share: 31 of the primary sources target these roles. For the rest of
the primary sources, either this distinction did not apply (e.g., clone &
own where a reusability platform is not available, and hence the ‘target
role’ of ‘domain engineer’ does not yet exist) or they tackle marginal
cases (e.g., testing, management).
6.2. Evolution scenarios
Table 4 summarizes the results. We can observe how visualization
support develops in tandem with the VRS field. At the onset, VRSs
depart from clone & own to an extractive approach on the search for
systematic reuse. Here, ‘Feature Identification and Location’ in existing
variants was (and still is) a main endeavour (10 papers). As the area
matures, and VRS develops towards configuration systems and SPLs,

Information and Software Technology 154 (2023) 107084
12
R. Medeiros et al.
Table 3
Target roles numbers.
Target role Number Primary sources
Application engineers 16 [S10,S9,S11,S7,S2,S12,S13,S14,S5,S15,S3,S16,S17,S6,S18,S19]
Domain engineers 15 [S9,S7,S20,S4,S21,S22,S8,S23,S19,S24,S25,S26,S15,S25,S27]
Software engineers 9 [S28,S29,S30,S31,S32,S33,S34,S35,S1]
Testers 3 [S36,S37,S16]
Requirements engineers 2 [S38,S39]
Project managers 2 [S40,S41]
Table 4
Evolution scenarios numbers.
Evolution scenario Number Primary sources
Feature Identification and Location (FIL) 10 [S28,S31,S32,S35,S3,S22,S38,S17,S39,S13]
Variant Integration (VI) 8 [S26,S30,S2,S33,S21,S14,S41,S23]
Variant Synchronization (VS) 6 [S10,S27,S12,S11,S37,S1]
Functional Testing (FT) 6 [S30,S7,S36,S29,S16,S19]
Transformations (TR) 5 [S25,S11,S24,S20,S6]
Co-Evolution of Problem and Solution Spaces (CPS) 4 [S9,S7,S40,S18]
Constraints Extraction (CE) 4 [S9,S4,S34,S15]
Architecture Recovery (AR) 2 [S5,S19]
Analysis of Non-Functional Properties (ANF) 1 [S8]
‘Variant Synchronization’ ‘Variant Integration’, and ‘Transformations’ are
moved to the spot (19 papers). Visualization wise, efforts are made to
understand and support evolution rather than on testing the preser-
vation of certain (non)functional properties. Interestingly, it is not
uncommon for primary sources to investigate multiple scenarios: [S30]
(VI and FT), [S11] (VS and TR) or [S19] (FT and AR).
6.3. Added-value
Table 5 displays the results: 8 papers contribute through elabo-
rated mining approaches to provide the raw data; 14 papers place
a visualization on top of the raw data to highlight different metrics;
finally, 18 papers contribute by providing some sort of analysis on
top of the visualization. This distribution 8-14-18 is akin to the role
played by each added-value: one sort of raw data might be aggregated
along different metrics which, in turn, might allow for different analysis
perspectives.
We complement this report by listing the metrics and analysis
types at play: code churn [S23,S2,S7], feature scattering [S26,S7,S31],
number of feature dependencies [S9,S18], code delta metric [S23],
feature cohesion metric [S6], feature size [S26], feature tangling [S7],
feature model metrics [S20], number of method overload [S35], run-
time non-functional metrics [S8], significance criteria [S10], t-wise
coverage [S36] and weighted hamming distance [S16]. On the other
hand, analysis strategies include, formal concept analysis [S21,S38], n-
way analysis [S5,S17,S3,S14], behavior analysis and comparison [S12],
bug prevalence analysis [S37], clone detection analysis [S39], data-
flow analysis [S34], feature location analysis [S32,S13], MOEA Anal-
ysis [S25], NLP analysis [S22], pair-wise feature relations [S4], PLC
project analysis [S28], scope analysis [S41], and variant similarity
analysis [S33,S1,S39].
With the exception of [S23,S39,S7,S26], papers focus on either a
single metric or a single analysis strategy. This pattern is common in
the early stages of an area subject to analysis (as it is the case of VRS
evolution). Rationales are many-fold: mining techniques are not yet
mature; lack of evidence about the appropriate metrics; and the scarcity
of real scenarios where to validate the analysis strategies. As the area
matures, we expect more hybrid approaches where different metrics
and strategies are combined to tackle more realistic settings.
7. Results for RQ2: What sort of visualization are displayed?
7.1. Visualized elements (RQ2.1)
Table 6 displays the results: ‘features’,‘variants’, and ‘implementation
assets’ (e.g., source code classes) are the most popular. These elements
seem to satisfy the analysis needs of the most investigated scenarios (see
Section 6.2), i.e., ‘Variant Synchronization’ and ‘Feature Identification and
Location’.
7.2. Visualization techniques (RQ2.2)
Table 7 summarizes the results: ‘nodelink diagram’ (e.g. Figs. 6
and 4), and ‘tabular/matrix’ (e.g., Fig. 8) are by far the most popular
visualization techniques. This coincides with visualizations for one-
off development [10]. In total, we found 11 different visualization
techniques. We note that 16 primary sources implemented more than
one: ‘heatmap’ and ‘enriched software diagram’ (see Fig. 9) [S9]; ‘tabu-
lar/matrix’ and ‘enriched software diagram’ [S26]; ‘tabular/matrix’ and
‘line chart’ [S11]; ‘alluvial diagram’ and ‘bar chart’ (see Fig. 2) [S2]; ‘tab-
ular/matrix’ and ‘bar chart’ [S31,S14]; ‘tabular/matrix’,‘bubble chart’,
‘treemap’ and ‘heatmap’ [S36]; ‘tabular/matrix’ and ‘bubble chart’ (see
Fig. 8) [S8]; ‘nodelink diagram’ and ‘tabular/matrix’ [S34,S40]; ‘bar
chart’,‘heatmap’ and ‘treemap’ (see Fig. 3) [S3]; ‘tabular/matrix’ and
‘heatmap’ [S16]; ‘bar chart’ and ‘nodelink diagram’ (see Fig. 1) [S1];
‘nodelink diagram’ and ‘word cloud’ (see Fig. 7) [S7]; ‘tabular/matrix’,
‘bar chart’ and ‘enriched software diagram’ (see Fig. 5) [S5]; or ‘alluvial
diagram’ and ‘treemap’ [S23].
7.3. Visualization interactions (RQ2.3 & RQ2.6)
Table 8 outlines the results. Nearly half of the primary sources
(44%) do not support any kind of interaction but just provide static
diagrams. For those supporting some interaction, ‘abstract/elaborate’ is
the most common. This may be due to the different levels of abstraction
present in VRSs (e.g. variants, features, source code). Some of the
primary sources start the analysis at the variant level and next, drill-
down to either the features or the source code [S30,S2,S1,S39,S23,S12,
S5,S3]. Both ‘filter’ and ‘select’ mechanisms are also widely used, akin
to the large codebase of VRSs. Finally, ‘connect’ and ‘explore’ are the
least popular which could be due to the yet poorly elaborated analysis
frameworks for managing VRS evolution.
7.4. Visualization strategies (RQ2.4)
Table 9 summarizes the results: the vast majority of primary sources
use a ‘temporal snapshot’ strategy. Tentatively, researchers are also
considering other scenarios, e.g., ‘temporal overview’ and ‘differential
relative’. Exceptionally, three primary sources support various strate-
gies: [S9,S11] both support ‘temporal snapshot’ and ‘differential relative’,
while [S1] supports ‘temporal snapshot’ and ‘temporal overview’. The
ability to change the strategy based on user-demand seems to be a
desirable property for future visualization tools.

Information and Software Technology 154 (2023) 107084
13
R. Medeiros et al.
Table 5
Added-value numbers.
Added-value Number Primary sources
Analysis strategy 19 [S21,S38,S5,S17,S12,S37,S39,S34,S32,S13,S25,S22,S3,S14,S4,S41,S33,S1,S28]
Metrics 14 [S23,S2,S7,S26,S31,S9,S18,S6,S20,S35,S8,S10,S36,S16]
Raw 8 [S27,S30,S11,S24,S29,S40,S15,S19]
Table 6
Visualized elements numbers.
Visualized element Number Primary sources
Features 21 [S9,S30,S11,S7,S2,S31,S32,S24,S20,S4]
[S36,S34,S15,S22,S17,S6,S39,S41,S19,S23,S13]
Variants 19 [S10,S27,S11,S2,S12,S33,S36,S8,S21,S37]
[S14,S3,S22,S38,S16,S17,S1,S39,S23]
Implementation assets 15 [S9,S28,S30,S11,S31,S32,S12,S35,S3,S1]
[S6,S39,S19,S23,S13]
Feature model 5 [S9,S26,S20,S40,S18]
Architecture 4 [S25,S24,S29,S5]
Variation points 4 [S27,S28,S15,S35]
Requirements 2 [S21,S38]
Table 7
Visualization techniques numbers.
Visualization technique Number Primary sources
Nodelink diagram 23 [S11,S32,S12,S13,S29,S34,S40,S15,S35,S6,S39]
[S18,S19,S33,S21,S38,S4,S30,S1,S20,S25,S7,S24]
Tabular/Matrix 11 [S11,S31,S36,S8,S26,S34,S14,S40,S16,S39,S41]
Bar chart 7 [S10,S31,S3,S17,S1,S14,S2]
Enriched software diagram 5 [S9,S26,S37,S5,S25]
Heatmap 4 [S9,S36,S3,S16]
Treemap 4 [S36,S3,S23,S13]
Indented tree 3 [S27,S28,S24]
Word cloud 2 [S7,S22]
Bubble chart 2 [S36,S8]
Alluvial diagram 2 [S2,S23]
Line chart 1 [S11]
Table 8
Visualization interactions numbers.
Visualization interaction Number Primary sources
None 17 [S10,S9,S25,S26,S31,S32,S13,S24,S33,S36,S21,S37]
[S34,S15,S22,S38,S41]
Abstract/Elaborate 14 [S28,S30,S11,S7,S2,S12,S20,S14,S5,S3,S16,S1,S6,S23]
Select 10 [S27,S28,S11,S4,S29,S16,S1,S6,S39,S19]
Filter 8 [S30,S7,S33,S4,S40,S35,S17,S18]
Explore 5 [S11,S7,S8,S15,S39]
Connect 2 [S28,S30]
Reconfigure 1 [S6]
Table 9
Visualization strategies numbers.
Visualization strategy Number Primary sources
Temporal snapshot 33 [S21,S38,S16,S17,S1,S6,S39,S18,S19,S14,S34,S40,S5,S15,S35,S3,S22]
[S10,S9,S25,S27,S28,S30,S11,S31,S32,S12,S13,S24,S20,S4,S36,S8]
Temporal overview 5 [S33,S29,S37,S1,S41]
Differential relative 5 [S9,S26,S7,S2,S23]
Differential absolute 1 [S11]
7.5. Data sources (RQ2.5)
Table 10 shows the results: ‘source code’ and ‘feature model’ are
the most common data sources with 29 and 17 primary sources, re-
spectively. ‘Traceability links’ and ‘models’ are also relevant, but with
half of the occurrences. In the case of ‘traceability links’, researchers
resort to different approaches: ‘feature-to-code’ [S26,S30,S11,S32,S6,
S19], ‘feature-to-component’ [S24,S19], ‘feature-to-variant’ [S19,S13], or
‘requirement-to-variant’ [S21,S19].
Researchers often resort to a combination of data sources. Fig. 12
depicts the most popular combinations using an Upset plot [29]. The
combinations (‘source code’, ‘feature model’, ‘traceability links’) is ex-
plored in 4 primary sources. We expect more research on how to
combine different data sources.
7.6. Visualization techniques & Data sources (RQ2.5)
This section breaks down visualization techniques by data sources
(see Fig. 13 (right-side)). Questions of interest include: What sources
are the most used with tabular/matrix? What techniques do usually
depend on traceability links?Fig. 13 (right side) depicts the outcome. We
excluded visualization techniques which involve less than three data
sources. It comes as no surprise that the ‘source code’ and ‘nodelink

Information and Software Technology 154 (2023) 107084
14
R. Medeiros et al.
Table 10
Data sources numbers.
Data source Number Primary sources
Source code 29 [S35,S3,S1,S6,S39,S19,S23,S13,S15,S28,S16,S10,S21,S37,S22,S27]
[S9,S26,S30,S11,S7,S2,S31,S32,S12,S33,S34,S14,S5]
Feature model 17 [S9,S27,S26,S30,S11,S20,S4,S36,S8,S15,S16,S6,S19,S32,S24,S13,S41]
Traceability links 9 [S26,S30,S11,S32,S6,S19,S24,S21,S13]
Models 8 [S25,S24,S29,S40,S15,S6,S19,S17]
VCS metadata 5 [S2,S37,S19,S23,S18]
Project documentation 4 [S21,S38,S25,S8]
Variant config. model 3 [S4,S29,S16]
Runtime contexts 2 [S30,S29]
Fig. 12. Upset plot of data sources combinations. The bar chart on the left represents the number of primary sources using a particular data source, while the bar chart on the
top represents the number of primary sources with a visualization resorting to a particular combination of one or more data sources.
Fig. 13. Visualization techniques distribution by evolution scenarios and data sources.
diagram’ have the biggest relation as they are the most popular ap-
proaches. ‘Feature model’ for ‘nodelink diagram’ follows the lead with
11 occurrences. In general, ‘feature