SPLC 2018 Challenge

Apo-Games – A Case Study for Reverse Engineering Variability from Cloned Java Variants

Jacob Krüger, Harz University of Applied Science, Otto-von-Guericke-University, Germany
Wolfram Fenske, Otto-von-Guericke-University, Germany
Thomas Thüm, Technische Universität Braunschweig, Germany
Dirk Aporius, Eudemonia Solutions AG, Germany
Gunter Saake, Otto-von-Guericke-University, Germany
Thomas Leich, Harz University of Applied Sciences, METOP GmbH, Germany
Software-product-line engineering is an approach to systematically manage reusable software features and has been widely adopted in practice. Still, in most cases, organizations start with a single product that they clone and modify when new customer requirements arise (a.k.a. clone-and-own). With an increasing number of variants, maintenance can become challenging and organizations may consider migrating towards a software product line, which is referred to as extractive approach. While this is the most common approach in practice, techniques to extract variability from cloned variants still fall short in several regards. In particular, this accounts for the low accuracy of automated analyses and refactoring, our limited understanding of the costs involved, and the high manual effort. A main reason for these limitations is the lack of realistic case studies. To tackle this problem, we provide a set of cloned variants. In this paper, we characterize these variants and challenge the research community to apply techniques for reverse engineering feature models, feature location, code smell analysis, architecture recovery, and the migration towards a software product line. By evaluating solutions with the developer of these variants, we aim to contribute to a larger body of knowledge on this real-world case study.


Multi-Objective Optimization for Reverse Engineering of Apo-Games Feature Models

Willian D. F. Mendonça, Wesley K. G. Assunção and Lukas Linsbauer
SPLC 2018 Solution
Software Product Lines Engineering (SPLE) is a software development approach intended for the development and maintenance of variable systems, i.e. systems that exist in many different variants. In the long run SPLE has many advantages. However, it requires a large upfront investment of time and money, which is why in practice Software Product Lines (SPLs) are rarely developed from scratch. Instead, they are often built using an extractive approach by which a set of existing system variants is consolidated (i.e. reverse engineered) into an SPL. A crucial part of this process is the construction of a variability model like a Feature Model (FM) that describes the common and variable parts of the system variants. In this paper we apply an approach for reverse engineering feature models based on a multi-objective optimization algorithm to the given challenge of constructing a feature model for a set of game variants and we present the results.
Solution paper

Recovering the Product Line Architecture of the Apo-Games

Crescencio Lima, Ivan Machado, Eduardo Almeida and Christina Chavez
SPLC 2018 Solution
Software Product Line (SPL) engineering is a paradigm for the development of a family of products based on the systematic reuse of artifacts. Although its increasing adoption, organizations often start with a single system and use ad-hoc techniques such as cloneand-own to create new systems by performing small changes and adaptations to meet customers’ needs. However, as the number of clones raises over time, it becomes a hard task to maintain and support all the systems. This scenario happened in the Apo-Games projects and adopting SPL Engineering can address these issues. Product Line Architecture (PLA) is one of the key assets to allow the success of SPL development. In this paper, we apply our approach to recover the PLA of the Apo-Games projects by using the source code of a set of Android and Java clones.We provide a set of information to support the development of the Apo-Games SPL. We identified that the Android and Java projects have similar PLAs.
Solution paper

Migrating Java-Based Apo-Games into a Composition-Based Software Product Line

Jamel Debbiche, Oskar Lignell, Jacob Krüger and Thorsten Berger
SPLC 2019 Solution
A software product line enables an organization to systematically reuse software features that allow to derive customized variants from a common platform, promising reduced development and maintenance costs. In practice, however, most organizations start to clone existing systems and only extract a software product line from such clones when the maintenance and coordination costs increase. Despite the importance of extractive software-product-line adoption, we still have only limited knowledge on what practices work best and miss datasets for evaluating automated techniques. To improve this situation, we performed an extractive adoption of the Apo-Games, resulting in a systematic analysis of five Java games and the migration of three games into a composition-based software product line. In this paper, we report our analysis and migration process, discuss our lessons learned, and contribute a feature model as well as the implementation of the extracted software product line. Overall, the results help to gain a better understanding of problems that can appear during such migrations, indicating research opportunities and hints for practitioners. Moreover, our artifacts can serve as dataset to test automated techniques and developers may improve or extent them in the future.
Solution paper

Migrating the Android Apo-Games into an Annotation-Based Software Product Line

Jonas Åkesson, Sebastian Nilsson, Jacob Krüger and Thorsten Berger
SPLC 2019 Solution
Most organizations start to reuse software by cloning complete systems and adapting them to new customer requirements. However, with an increasing number of cloned systems, the problems of this approach become severe, due to synchronization efforts. In such cases, organizations often decide to extract a software product line, which promises to reduce development and maintenance costs. While this scenario is common in practice, the research community is still missing knowledge about best practices and needs datasets to evaluate supportive techniques. In this paper, we report our experiences with extracting a preprocessor-based software product line from five cloned Android games of the Apo-Games challenge. Besides the process we employed, we also discuss lessons learned and contribute corresponding artifacts, namely a feature model and source code. The insights into the processes help researchers and practitioners to improve their understanding of extractive softwareproduct-line adoption. Our artifacts can serve as a valuable dataset for evaluations and can be extended in the future to support researchers as a real-world baseline.
Solution paper

Code smell analysis in cloned Java variants: the apo-games case study

Luciano Marchezan, Wesley K. G. Assunção, Gabriela Michelon, Edvin Herac, Alexander Egyed
SPLC 2022 Solution
Families of software products are usually created using opportunistic reuse (clone-and-own) in which products are cloned and adapted to meet new requirements, user preferences, or non-functional properties. Opportunistic reuse brings short-term benefits, e.g., reduced time-to-market, whereas creating long-term drawbacks, e.g., the need of changing multiple variants for any maintenance and evolution activity. This situation is even worse when the individual products have poor design or implementation choices, the so-called code smells. Due to their harmfulness to software quality, code smells should be detected and removed as early as possible. In a family of software products, the same code smell must be identified and removed in all variants where it is are present. Identifying instances of similar code smells affecting different variants has not been investigated in the literature yet. This is the case of the Apo-Games family, which has the challenge of identifying the flaws in the design and implementation of cloned games. To address this challenge, we applied our inconsistency and repair approach to detect and suggest solutions for six types of code smells in 19 products of the Apo-games family. Our results show that a considerable number of smells were identified, most of them for the long parameter list and data class types. The number of the same smells identified in multiple variants ranged between 2.9 and 20.2 on average, showing that clone-and-own may lead to the replication of code smells in multiple products. Lastly, our approach was able to generate between 4.9 and 28.98 repair alternatives per smell on average.
Solution paper


References outside the SPLC Challenge track

Apo-Games case study has its own entry in the ESPLA Catalog (extractive SPL adoption catalog of case studies).

Previous to the Challenge paper, we can find two main references to the case study.
Variant-Preserving Refactorings for Migrating Cloned Products to a Product Line
Wolfram Fenske, Jens Meinicke, Sandro Schulze, Steffen Schulze, and Gunter Saake
SANER 2017, International Conference on Software Analysis, Evolution and Reengineering, 2017

Finding Lost Features in Cloned Systems
Jacob Krüger, Louis Nell, Wolfram Fenske, Gunter Saake, Thomas Leich
SPLC 2017 REVE workshop, International Systems and Software Product Line Conference, 2017

After the Challenge paper, we can also find this reference outside of the SPLC Challenge track
Towards an Automated Product Line Architecture Recovery: The Apo-Games Case Study
Crescencio Lima, Wesley K. G. Assunção, Jabier Martinez, Christina von Flach G. Chavez, Willian D. F. Mendonça
SBCARS '18 Proceedings of the VII Brazilian Symposium on Software Components, Architectures, and Reuse, Pages 33-42, Sao Carlos, Brazil — September 17 - 21, 2018
and its journal extension:
Crescencio Lima, Wesley K. G. Assunção, Jabier Martinez, Willian D. F. Mendonça, C. Machado, Christina von Flach G. Chavez,
Product Line Architecture Recovery with Outlier Filtering in Software Families: The Apo-Games Case Study
Journal of the Brazilian Computer Society 2019 25:7