1 Introduction
-
A characterization of the processes where two software systems were transformed into SPL. This characterization was possible using practices from the mining software repositories field (Hassan 2008). The insights of this characterization can serve as an experience report, describing the steps, artifacts, time taken, tools used, and problems of two specific cases, for companies and practitioners willing to re-engineer an existing monolithic system into an SPL. That is, practitioners can then have examples of how other re-engineering processes were conducted.
-
A publicly available dataset and analysis scripts3 to be used as a baseline for extractive SPL adoption research. This dataset includes a large amount of data for the two illustrative and comprehensible examples of SPLs creations.
2 Background
2.1 Annotative SPLs
ifdef
preprocessor directives), and it can also be used in object-oriented languages, such as C++ (Hu et al. 2000) and Java. For example, the Java Preprocessor4 functionality is the one used in ArgoUML-SPL. In this approach, annotative directives indicate pieces of code that should be compiled/included or not based on the value of variables. The pieces of code can be marked at the granularity of a single line of code or to a whole file. Feature toggling is also a used annotative approach (Mahdavi-Hezaveh et al. 2021) where there is no need of specific variability management libraries as the annotations are based on the standard if
clauses of the target programming language.//#if defined(UseCaseDiagram)
directive in line 5, for instance, indicates the beginning of code belonging to the Use Case Diagram feature. On the other hand, the directive in line 8 specifies the code of the State Diagram feature. The #endif
directives (e.g., lines 7 and 10) determine the end of code associated with each feature. Each identifier, such as UseCaseDiagram
in line 5, is associated with a Boolean value defined in a configuration file for each product of ArgoUML-SPL. Its value indicates the presence of the feature in a product and, consequently, the inclusion of the bounded piece of code in the compiled product.
2.2 Feature Interactions
2.3 Compositional SPLs
2.4 The Re-engineering Process
2.5 ArgoUML in a Nutshell
2.6 Phaser in a Nutshell
3 Study design
3.1 Study Goal, Questions, and Metrics
-
RQ1: How has the source code of the systems changed during the re-engineering processes? We discuss the modifications for turning the monolithic structure of the systems into an architecture that allows dealing with variability and customization.
-
Metric: LoC of each feature, percentage of LoC changes in the architecture, features made optional, and interactions among features.
-
-
RQ2: How was the operationalization of the re-engineering processes? Since the SVN and GitHub repositories are our source of information, in this question we aim to investigate if the features were extracted all in the same trunk, if there were branches, and the number of revisions in the process. Also, we investigate aspects related to the time, effort, and team involved in the extraction of the case studies. The goal of this RQ is to provide insights for those willing to move from monolithic systems to SPL architectures.
-
Metric: number of branches vs number of features (branching strategy), number of revisions per feature, number of months for each feature extraction, number of people, and initial/final revisions.
-
-
RQ3: What were the problems faced when conducting re-engineering processes of the systems? Since the re-engineering process is a complex intellectual activity, it is an error-prone task. Here we investigate which and how bugs were found after the SPL extraction, and barriers found by the collaborators during the process.
-
Metric: bugs found, inconsistencies detected, and feedback from developers.
-
3.2 Repository Data Extraction
3.2.1 ArgoUML-SPL extraction
Core
, i.e., the common part.3.2.2 Phaser extraction
3.3 Developer
4 Results and Analysis
4.1 Overview of the ArgoUML and Phaser re-engineering processes
ifdef
preprocessor directives but using a Java library for annotations[4]. Six features were related to diagrams and two were representative cross-cutting features, namely Logging
and Cognitive
support. The latter is responsible for providing critics and warnings regarding UML model instances. This re-engineering process was made in 156 commits, with contributions from three other developers. The latest revisions in 2014 consist only of fixes on the Java comments related to the granularity types of the variability annotations (meta-data on the variability annotations). Those revisions were made by a researcher on a study for consolidating ArgoUML variants in an SPL (Klatt 2014).4.2 Making the Architecture Variable
Feature | Version | Feature | Version |
---|---|---|---|
arcade | 2.3.0 | text | 2.3.0 |
bitmapdata | 2.3.0 | tilemapcolision | 2.3.0 |
bitmaptext | 2.3.0 | tilemaps | 2.3.0 |
debug | 2.3.0 | tweens | 2.3.0 |
gamepad | 2.3.0 | creature | 2.4.0 |
graphics | 2.3.0 | rope | 2.4.0 |
intro | 2.3.0 | tilesprite | 2.4.0 |
keyboard | 2.3.0 | video | 2.4.0 |
net | 2.3.0 | color | 2.5.0 |
ninja | 2.3.0 | create | 2.5.0 |
outro | 2.3.0 | dom | 2.5.0 |
p2 | 2.3.0 | flexgrid | 2.5.0 |
particles | 2.3.0 | pixidefs | 2.5.0 |
rendertexture | 2.3.0 | scale | 2.5.0 |
retrofont | 2.3.0 | weapon | 2.5.0 |
sound | 2.3.0 |
Rope
, Tilesprite
, Creature
and Video
, while Pixi
became a mandatory feature. Only Creature
and Video
were new features, Rope
and Tilesprite
were already modularized but were part of the Pixi
feature. On the same commit that Pixi
became a mandatory feature, both Rope
and Tilesprite
were extracted from the manifest file of feature Pixi
, and became optional features on their own. However, both were composed of a game object component and a Pixi
component. This was only addressed in later stages - in version 2.7.3, where the Pixi
component was removed and its content merged with the game object component, in order to cut down the number of internal classes and inheritance. In version 2.5.0, seven features were added to the Gruntfile: Scale
, Dom
, Create
, Flexgrid
, Color
, Weapon
and Pixidefs
. Weapon
was the only new feature, while the others already existed and were modularized. Scale
, Dom
, Create
and Color
were modularized as stubs, which means that, although they are optional and in theory can be removed from the custom build, Phaser still requires certain functionalities from these features in order to work properly. Stub features contain just the bare minimum of functions that Phaser needs to work, greatly reducing the file size.Pixi
, which is a 2D WebGL renderer, became mandatory due to, according to Phaser’s lead developer, the amount of customization made to the library in order to fix bugs. After that, it was not possible to swap with another Pixi
version. However, on the next version it was removed from the explicit list of mandatory features in the Gruntfile, but remained a mandatory feature due to being automatically added to the build also via the Gruntfile.Pixi
library mentioned by the lead developer. On this specific commit24 some Pixi
files that were no longer used in the Phaser build at the time, totaling 8100 deleted lines across 45 files. The second commit25 refers to the restructuring of the core game objects and the use of the new components “mixins”. There were over 4400 deletions across nine files.4.3 Re-engineering Processes Operationalization
SequenceDiagram
, UseCaseDiagram
, CollaborationDiagram
, and DeploymentDiagram
), feature-specific branches were used before merging. Also, for those branches, features were extracted in parallel (SequenceDiagram
in parallel with UseCaseDiagram
, and CollaborationDiagram
with DeploymentDiagram
). The extraction of ActivityDiagram
started in R12, Logging
in R17, and Cognitive
and StateDiagram
both in R33. According to the feedback from the main developer, the decision of creating branches per feature was taken since the beginning. However, we did not find evidence in the repository about branches for the first four features. Hence, it was probably made without adding the branches in the SVN.
UseCaseDiagram
and SequenceDiagram
branches which were extracted by Camilo Ribeiro27. Eduardo Figueiredo28 (an author of this paper) and Marco Tulio Valente29 were two experts supervising the extraction, acting like project managers, but not interacting directly with the repository. Finally, Christian Kästner30 reported variability-related bug fixes that were solved in R143, and Benjamin Klatt31 improved the meta-data of the Java variability-related annotations.
Feature | Size F. core LoC Interact. LoC | Revisions (global)–branch– | Dates dd/mm/yyyy (global) | Months (global) |
---|---|---|---|---|
Activity | 5,950 208 | 12 → 132 | 03/04/2010 – 27/09/2010 | 5.9 |
Cognitive | 28,380 2,069 | 33 → 132 (33 → 143) | 03/04/2010 – 27/09/2010 (07/10/2011) | 5.9 (18.4) |
Collaboration | 2,676 199 | 95 → 132 (95 → 148)–95 → 115– | 12/08/2010 – 27/09/2010 (08/06/2014) | 1.53 (46.53) |
Deployment | 3,243 1,708 | 98 → 132 –98 → 132– | 12/08/2010 – 27/09/2010 | 1.53 |
Logging | 2,312 690 | 17 → 132 (17 → 152) | 03/04/2010 – 27/09/2010 (16/06/2014) | 5.9 (51.16) |
Sequence | 8,437 420 | 80 → 123 (80 → 148)–80 → 88– | 21/06/2010 – 25/09/2010 (08/06/2014) | 3.2 (48.26) |
State | 8,801 207 | 33 → 132 | 03/04/2010 – 27/09/2010 | 5.9 |
UseCase | 5,294 60 | 81 → 132 (81 → 156)–81 → 89– | 21/06/2010 – 27/09/2010 (28/06/2014) | 3.26 (48.93) |
Average: | 4.14 |
DeploymentDiagram
was the quickest extracted (only 1.53 months, 34 revisions). All the revisions were made in a dedicated branch and, after its merge into the trunk (see Figure 9), no more changes were made to this feature nor to any of its feature interactions. Contrary to this, Logging
was the feature that took more time to be globally stable. This cross-cutting feature had a sustained activity in the trunk. The features CollaborationDiagram
, SequenceDiagram
, and UseCaseDiagram
had significant activity after their branches merged, that means that their extraction was not completed between merging the branch and the start of the SPL maintenance period.Logging
interaction with some diagram type, three involve the cross-cutting feature Cognitive
and a diagram type, and five are interactions only between diagrams. On average, each feature interaction has 2.64 revisions, commonly spread along the re-engineering process. The size of these interactions varies, ranging from interactions implemented with only one or two LoC, to one interaction with 1,653 LoC. Furthermore, Figs. 10a, 10b and 10c display the box-plots of the number of core LoC, interaction LoC and months.
Feature | Versions | Dates (dd/mm/yyyy) | Months | Commits |
---|---|---|---|---|
arcade | 2.0.0 → 2.15.0 | 05-03-2014 – 15-05-2020 | 74.35 | 184 |
bitmapdata | 2.0.0 → 2.15.0 | 02-03-2014 – 15-05-2020 | 74.45 | 171 |
bitmaptext | 2.0.0 → 2.15.0 | 06-03-2014 – 15-05-2020 | 74.32 | 71 |
color | 2.0.0 → 2.15.0 | 25-03-2014 – 15-05-2020 | 73.69 | 63 |
create | 2.3.0 → 2.15.0 | 08-07-2015 – 15-05-2020 | 58.25 | 22 |
creature | 2.3.0 → 2.15.0 | 13-04-2015 – 05-15-2020 | 61.07 | 59 |
debug | 2.0.0 → 2.15.0 | 02-03-2014 – 01-06-2020 | 75.01 | 145 |
dom | 2.1.0 → 2.15.0 | 10-11-2014 – 15-05-2020 | 66.13 | 30 |
flexgrid | 2.0.0 → 2.15.0 | 05-09-2014 – 15-05-2020 | 68.30 | 31 |
gamepad | 2.0.0 → 2.15.0 | 14-03-2014 – 15-05-2020 | 74.05 | 40 |
graphics | 2.0.0 → 2.15.0 | 06-03-2014 – 09-06-2020 | 75.14 | 72 |
intro | 2.0.0 → 2.7.3 | 14-03-2014 – 03-07-2017 | 39.65 | 9 |
keyboard | 2.0.0 → 2.15.0 | 03-03-2014 – 15-05-2020 | 74.42 | 74 |
net | 2.0.0 → 2.15.0 | 25-03-2014 – 15-05-2020 | 73.69 | 14 |
ninja | 2.0.0 → 2.10.0 | 06-03-2014 – 22-05-2018 | 50.53 | 33 |
outro | 2.0.0 → 2.15.0 | 10-03-2014 – 15-05-2020 | 74.18 | 23 |
p2 | 2.0.0 → 2.11.0 | 06-03-2014 – 01-10-2018 | 54.86 | 124 |
particles | 2.0.0 → 2.15.0 | 11-03-2014 – 05-15-2020 | 74.15 | 119 |
pixidefs | 2.2.0 → 2.15.0 | 17-02-2015 – 15-05-2020 | 62.88 | 23 |
rendertexture | 2.0.0 → 2.15.0 | 14-03-2014 – 15-05-2020 | 74.05 | 28 |
retrofont | 2.0.0 → 2.15.0 | 11-03-2014 – 15-05-2020 | 74.15 | 33 |
rope | 2.0.0 → 2.15.0 | 14-03-2014 – 15-05-2020 | 74.05 | 59 |
scale | 2.0.0 → 2.15.0 | 10-03-2014 – 15-05-2020 | 74.19 | 155 |
sound | 2.0.0 → 2.15.0 | 02-03-2014 – 29-05-2020 | 74.91 | 156 |
text | 2.0.0 → 2.15.0 | 06-03-2014 – 15-05-2020 | 74.32 | 165 |
tilemapcolision | 2.2.0 → 2.15.0 | 17-02-2015 – 15-05-2020 | 62.88 | 41 |
tilemaps | 2.0.0 → 2.15.0 | 02-03-2014 – 29-05-2020 | 74.90 | 163 |
tilesprite | 2.0.0 → 2.15.0 | 07-03-2014 – 15-05-2020 | 74.28 | 85 |
tweens | 2.0.0 → 2.15.0 | 03-03-2014 – 15-05-2020 | 74.42 | 89 |
video | 2.2.0 → 2.15.0 | 05-03-2015 – 15-05-2020 | 60.42 | 64 |
weapon | 2.4.0 → 2.11.0 | 03-06-2016 – 25-10-2018 | 28.71 | 48 |
Average: | 67.76 | 77.19 |
4.4 Error-proneness of the Process
4.4.1 ArgoUML-SPL
SEQUENCEIAGRAM
(missing D
), introduced inconsistencies in the system in R88 and R89. In addition, we observe evidence of feature name refactorings, e.g., UMLSTATEDIAGRAM
to STATEDIAGRAM
in R119, and how it affects also its feature interactions. More advanced tool support for checking the consistency of variability information and for variability-aware refactoring will be desired. In this sense, tool capabilities could have helped in solving these issues. As mentioned in Section 2.1, the used tool in ArgoUML-SPL is Java Prepocessor (Javapp) which is not part of Java itself but an external tool that parses Java source code identifying and handling comments with specific keywords for variability management. This parsing and handling are only considered at derivation-time. Thus, being standard Java comments, no keywords highlighting, auto-completion, nor consistency checks for the feature names is performed so the feature naming error was unnoticed during a couple of revisions. Javapp is a very basic variability management tool and its major advantage is that no external dependencies need to be added to the Java source code itself for the derivation of variants. However, generally speaking, it is acknowledged that SPL engineering lack of mature tool support (Horcas et al. 2019). For instance, annotative approaches in Java are supported in FeatureIDE (Meinicke et al. 2017) (v3.8.0) through its integration with Antenna and Munge. Using FeatureIDE with Antenna could have identified the consistency check issue of the feature name through a warning in the source code, but FeatureIDE with Munge does not have current support for it. Regarding name refactoring, both Antenna and Munge allow renaming features with automatic synchronization in the variability annotations.4.4.2 Phaser
Scale
and Flexgrid
. Scale
is a manager that handles the scaling, resizing and alignment of the game size and Flexgrid
is a grid manager that works in conjunction with Scale
. Before being added as an optional feature, Scale
created a Flexgrid
object during ScaleManager
initialization routine. This relationship was changed in version 2.5.0 in order that ScaleManager
no longer creates a Flexgrid
object if the class is not available – excluded via custom build for example. In order to implement the custom builds with different components, the developers have used feature toggles in some situations. For example, the feature Scale
has a feature toggle checking regarding the existence of the feature Flexgrid
. Other examples are in the implementation of the mandatory features Input
and Core
. The former checks if features Keyboard
and Gamepad
are available and the latter checks if the feature Graphics
is available. This indicates that in order to make a feature truly optional, it is pivotal to deal with features that depend on it or interact with it, either by implementing cross-tree constraints or removing these dependencies by making use of feature toggles. Otherwise, the derived product would not function properly, since the removal of a certain feature might break another feature that depends on it.Arcade Physics
but did not exclude Particles
or Weapon
, the script automatically removes them and warns the user through the console. Other than the ones mentioned before, there is a third one that removes RetroFonts
if the user excluded RenderTexture
as, similarly, RetroFonts
depends on RenderTexture
.Arcade Physics
nor Tilemaps
, the feature Timelap Collision
is added to the build. This feature is not listed in the Gruntfile to be excluded and is a compositional feature since it was part of the arcade physics feature and was extracted from it into its own feature.ScaleManager
, which is the Scale feature.5 Discussion
6 Threats to Validity
7 Related Work
Ref. | Year | Case Study | Duration | People |
---|---|---|---|---|
Kolb et al. (2006) | 2006 | Image Memory Handler (IMH) | 4 months | 2 researchers, 2 students, 1 domain expert |
Yang et al. (2009) | 2009 | JForum, JGossip and MVNForum | 2 weeks for analysis of all the three systems | 2 graduate students |
Ali et al. (2011) | 2011 | SIP Communicator | 171 hours to recover 830 feature traces | n/a |
Ali et al. (2011) | 2011 | Pooka Email Client | 135 hours to recover 318 feature traces | n/a |
Dhungana et al. (2011) | 2011 | Siemens VAI Steel Plant Automation Software | 4 years of case study | n/a |
Dhungana et al. (2011) | 2011 | IEC 61499 Industrial Automation System | 2.5 years of case study | n/a |
Dhungana et al. (2011) | 2011 | BMD .NET-based Business Software | 1.5 years of case study | n/a |
Zhang et al. (2011) | 2011 | Alcatel-Lucent IXM-PF | 1.5 years for an initial success | n/a |
Otsuka et al. (2011) | 2011 | Fujitsu Kyushu Network Technologies | more than 1 year | 100 engineers on an average |
Olszak and Jørgensen (2012) | 2012 | BlueJ | 2 hours for feature identification | n/a |
Hariri et al. (2013) | 2013 | Collaborative Software Suite (CoSS) | 30 hours to identify approximately 120 coarse-grained features | n/a |
ifdefs
. Three open-source forum systems were used by Yang et al. to manually identify features (Yang et al. 2009). During two weeks two graduate students manually performed feature location on Java code and SQL statements. The goal was to synthesize a variability model.