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. 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). We performed a systematic mapping study including automated search in digital libraries, expert knowledge, and snowballing. 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. 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).

In large code bases, locating the elements that implement concrete features of a system is challenging. This information is paramount for maintenance and evolution tasks, although not always explicitly available. In this work, motivated by the needs of locating features as a first step for feature-based Software Product Line adoption, we propose a solution for improving the performance of existing approaches. For this, relying on an automatic feature localization approach to locate features in single-systems, we propose approaches to deal with feature localization in the context of families of systems, e.g., variants created through opportunistic reuse such as clone-and-own. Our feature localization approaches are built on top of Spectrum-based feature localization (SBFL) techniques, supporting both dynamic feature localization (i.e., using execution traces as input) and static feature localization (i.e., relying on the structural decomposition of the variants’ implementation). Concretely, we provide (i) a characterization of different settings for dynamic SBFL in single systems, (ii) an approach to improve accuracy of dynamic SBFL for families of systems, and (iii) an approach to use SBFL as a static feature localization technique for families of systems. The proposed approaches are evaluated using the consolidated ArgoUML SPL feature localization benchmark. The results suggest that some settings of SBFL favor precision such as using the ranking metrics Wong2, Ochiai2, or Tarantula with high threshold values, while most of the ranking metrics with low thresholds favor recall. The approach to use information from variants increase the precision of dynamic SBFL while maintaining recall even with few number of variants, namely two or three. Finally, the static SBFL approach performs equally in terms of accuracy to other state-of-the-art approaches, such as Formal Concept Analysis and Interdependent Elements.

Abstract To assure certain critical quality properties (e.g., safety, security, or privacy), supervisory authorities and industrial associations provide reference frameworks such as standards or guidelines that in some cases are enforced (e.g., regulations). Given the pace at which both technical advancements and risks appear, there is an increase in the number of reference frameworks. As several frameworks might apply for same systems, certain overlaps appear (e.g., regulations for different countries where the system will operate, or generic standards in conjunction with more concrete standards for a given industrial sector or system type). We propose the use of modelling for alleviating the complexity of these reference frameworks ecosystems, and we provide a tool-supported method to create them for the benefit of different stakeholders. The case study is based on privacy data protection, and more concretely on privacy impact assessment processes. The European GDPR regulates the movement and processing of personal data, and, contrary to available software engineering privacy guidelines, articles in legal texts are usually difficult to translate to the underlying processes, artefacts and roles that they refer to. To facilitate the mutual comprehension of legal experts and engineers, in this work we investigate how mappings can be created between these two domains of expertise. Notably, we rely on modelling as a central point. We modelled the legal requirements of the GDPR on data protection impact assessments, and then, we selected the ISO/IEC 29134, a mainstream engineering guideline for privacy impact assessment, and, taking a concrete sector as example, the EU Smart Grid Data Protection Impact Assessment template. The OpenCert tool was used for providing technical support to both the modelling and the creation of the mapping models in a systematic way. We provide a qualitative evaluation from legal experts and privacy engineering practitioners to report on the benefits and limitations of this approach.

When configuring a software product line, finding a good trade-off between multiple orthogonal quality concerns is a challenging multi-objective optimisation problem. State-of-the-art solutions based on search-based techniques create invalid configurations in intermediate steps, requiring additional repair actions that reduce the efficiency of the search. In this work, we introduceconsistency-preserving configuration operators(CPCOs)—genetic operators that maintain valid configurations throughout the entire search. CPCOs bundle coherent sets of changes: the activation or deactivation of a particular feature together with other (de)activations that are needed to preserve validity. In our evaluation, our instantiation of the IBEA algorithm with CPCOs outperforms two state-of-the-art tools for optimal product line configuration in terms of both speed and solution quality. The improvements are especially pronounced in large product lines with thousands of features.

The management of technical debt related to non-functional properties such as security, reliability or other trustworthiness dimensions is of paramount importance for critical systems (e.g., safety-critical, systems with strong privacy constraints etc.). Unfortunately, diverse factors such as time pressure, resource limitations, organizational aspects, lack of skills, or the fast pace at which new risks appears, can result in an inferior level of trustworthiness than the desired or required one. In addition, there is increased interest in considering trustworthiness characteristics, not in isolation, but in an aggregated fashion, as well as using this knowledge for risk quantification. In this work, we propose a trustworthiness debt measurement approach using 1) established categories and subcategories of trustworthiness characteristics from SQuaRE, 2) a weighting approach for the characteristics based on an AHP method, 3) a composed indicator based on a Fuzzy method, and 4) a risk management and analysis support based on Monte Carlo simulations. Given the preliminary nature of this work, while we propose the general approach for all trustworthiness dimensions, we elaborate more on security and reliability. This initial proposal aims providing a practical approach to manage trustworthiness debt suitable for any life cycle phase and bringing the attention to aggregation methods.

Abstract Software Product Lines (SPLs) are rarely developed from scratch. Commonly, they emerge from one product when there is a need to create tailored variants, or from existing variants created in an ad-hoc way once their separated maintenance and evolution become challenging. Despite the vast literature about re-engineering systems into SPLs and related technical approaches, there is a lack of detailed analysis of the process itself and the effort involved. In this paper, we provide and analyze empirical data of the extraction processes of two open-source case studies, namely ArgoUML and Phaser. Both cases emerged from the transition of a monolithic system into an SPL. The analysis relies on information mined from the version control history of their respective source-code repositories and the discussion with developers that took part in the process. Unlike previous works that focused mostly on the structural results of the final SPL, the contribution of this study is an in-depth characterization of the processes. With this work, we aimed at providing a deeper understanding of the strategies for SPL extraction and their implications. Our results indicate that the source code changes can range from almost a fourth to over half of the total lines of code. Developers may or may not use branching strategies for feature extraction. Additionally, the problems faced during the extraction process may be due to lack of tool support, complexity on managing feature dependencies and issues with feature constraints. We made publicly available the datasets and the analysis scripts of both case studies to be used as a baseline for extractive SPL adoption research and practice.

Industries from very diverse domains are realising that security should not be treated in a reactive way (e.g., once the cyberattack has happened). This way, security-related requirements and risks need to be continuously managed, and the need of integrating technical measures should be continuously assessed. In some cases, some decisions led, intentionally or unintentionally, to debt related to security aspects. This security debt is thus incurred when limited approaches or solutions are applied to reach the expected security levels of the system in operation. Identifying and making explicit security debt items is a challenge for companies. In this work, we analyse the literature on security debt to provide initial insights on the topic. Concretely, we discuss its definition, identify its most salient characteristics, present approaches for integrating its management in the product life-cycle, and to present categories and examples of security debt items.

Abstract Handling large-scale software variability is still a challenge for many organizations. After decades of research on variability management concepts, many industrial organizations have introduced techniques known from research, but still lament that pure textbook approaches are not applicable or efficient. For instance, software product line engineering—an approach to systematically develop portfolios of products—is difficult to adopt given the high upfront investments; and even when adopted, organizations are challenged by evolving their complex product lines. Consequently, the research community now mainly focuses on re-engineering and evolution techniques for product lines; yet, understanding the current state of adoption and the industrial challenges for organizations is necessary to conceive effective techniques. In this multiple-case study, we analyze the current adoption of variability management techniques in twelve medium- to large-scale industrial cases in domains such as automotive, aerospace or railway systems. We identify the current state of variability management, emphasizing the techniques and concepts they adopted. We elicit the needs and challenges expressed for these cases, triangulated with results from a literature review. We believe our results help to understand the current state of adoption and shed light on gaps to address in industrial practice.

Feature location is a traceability recovery activity to identify the implementation elements associated to a characteristic of a system. Besides its relevance for software maintenance of a single system, feature location in a collection of systems received a lot of attention as a first step to re-engineer system variants (created through clone-and-own) into a Software Product Line (SPL). In this context, the objective is to unambiguously identify the boundaries of a feature inside a family of systems to later create reusable assets from these implementation elements. Among all the case studies in the SPL literature, variants derived from ArgoUML SPL stands out as the most used one. However, the use of different settings, or the omission of relevant information (e.g., the exact configurations of the variants or the way the metrics are calculated), makes it difficult to reproduce or benchmark the different feature location techniques even if the same ArgoUML SPL is used. With the objective to foster the research area on feature location, we provide a set of common scenarios using ArgoUML SPL and a set of utils to obtain metrics based on the results of existing and novel feature location techniques.

The engineering of a Software Product Line (SPL), either by creating it from scratch or through the re-engineering of existing variants, it uses to be a project that spans several years with a high investment. It is often hard to analyse and quantify this investment, especially in the context of extractive SPL adoption when the related software variants are independently created by different developers following different system architectures and implementation conventions. This paper reports an experience on the creation of an SPL by re-engineering system variants implemented around an educational game called Robocode. The objective of this game is to program a bot (a battle tank) that battles against the bots of other developers. The world-wide Robocode community creates and maintains a large base of knowledge and implementations that are mainly organized in terms of features, although not presented as an SPL. Therefore, a group of master students analysed this variability-rich domain and extracted a Robocode SPL. We present the results of such extraction augmented with an analysis and a quantification regarding the spent time and effort. We believe that the results and the a-posteriori analysis can provide insights on global challenges on SPL adoption. We also provide all the elements to SPL educators to reproduce the teaching activity, and we make available this SPL to be used for any research purpose.

Software Product Line (SPL) migration remains a challenging endeavour. From organizational issues to purely technical challenges, there is a wide range of barriers that complicates SPL adoption. The workshop REverse Variability Engineering (REVE) aims to foster research about making the most of the two main inputs for SPL migration: 1) domain knowledge and 2) legacy assets. Domain knowledge, usually implicit and spread across an organization, is key to define the SPL scope and to validate the variability model and its semantics. At the technical level, domain expertise is also needed to create or extract the reusable software components. Legacy assets can be, for instance, similar product variants (e.g., requirements, models, source code) that were implemented using ad-hoc reuse techniques such as clone-and-own. More generally, the workshop attracts researchers and practitioners contributing to processes, techniques, tools, or empirical studies related to the automatic, semi-automatic or manual extraction or refinement of SPL assets.

This year at SPLC we present a teaching and research project where a group of master students analysed a variability-rich domain and extracted an SPL (The Robocode SPL). We present the results of such extraction augmented with an analysis and a quantification regarding the time and effort spent. The research objective was to get and share data about an end-to-end SPL extraction which is usually unavailable in industrial cases because of their large size, complexity, and duration. We provide all the material to replicate, reproduce or extend the case study so it can be easily reused for teaching by anyone in our community. However, we were asking ourselves how can we leverage such case study for teaching to pursue research objectives. In this position paper, we aim to outline our initial ideas that we want to enrich with the others' viewpoints during SPLTea. Towards planning the settings of future teaching projects around this Robocode SPL case study, which can be the timely research objectives that we can identify? Can we involve others in planning this project in their institutions to get further relevant results?

The myriads of smart phones around the globe gave rise to a vast proliferation of mobile applications. These applications target an increasing number of user profiles and tasks. In this context, Android is a leading technology for their development and on-line markets are the main means for their distribution. In this paper we motivate, from two perspectives, the mining of these markets with the objective to identify families of apps variants in the wild. The first perspective is related to research activities where building realistic case studies for evaluating extractive SPL adoption techniques are needed. The second is related to a large-scale, world-wide and time-aware study of reuse practice in an industry which is now flourishing among all others within the software engineering community. This study is relevant to assess potential for SPLE practices adoption. We present initial implementations of the mining process and we discuss analyses of variant families.

From organizational issues to purely technical challenges, there is a wide range of barriers that complicates Software Product Line (SPL) adoption. This workshop aims to foster research about making the most of two main inputs for SPL migration: 1) domain knowledge and 2) existing legacy assets. Domain knowledge, usually implicit and spread across an organization, is key to define the SPL scope and to validate the variability model and its semantics. At the technical level, domain expertise is also needed to create reusable software components. Regarding legacy assets, they use to be similar product variants (e.g. requirements, models, source code etc.) that were implemented using ad-hoc reuse techniques such as clone-and-own. These assets can be leveraged in extractive SPL adoption processes. The workshop REverse Variability Engineering (REVE) attracts researchers and practitioners contributing processes, techniques, tools, or empirical studies related to the automatic, semi-automatic or manual extraction or refinement of SPL assets.

Reengineering a Software Product Line from legacy variants remains a challenging endeavour. Among various challenges, it is a complex task to retrieve enough information for inferring the variability from experts' domain knowledge and from the semantics of software elements. We propose the VariClouds process that can be leveraged by domain experts to understand the semantics behind the different blocks identified during software variants analysis. VariClouds is based on interactive word cloud visualisations providing name suggestions for these blocks using tf-idf as weighting factor. We evaluate our approach by assessing its added-value to several previous works in the literature where no tool support was provided to domain experts to characterise features from software blocks.

We address the problem of automating 1) the analysis of existing similar model variants and 2) migrating them into a software product line. Our approach, named MoVaPL, considers the identification of variability and commonality in model variants, as well as the extraction of a CVL-compliant Model-based Software Product Line (MSPL) from the features identified on these variants. MoVaPL builds on a generic representation of models making it suitable to any MOF-based models. We apply our approach on variants of the open source ArgoUML UML modeling tool as well as on variants of an In-flight Entertainment System. Evaluation with these large and complex case studies contributed to show how our feature identification with structural constraints discovery and the MSPL generation process are implemented to make the approach valid (i.e., the extracted software product line can be used to regenerate all variants considered) and sound (i.e., derived variants which did not exist are at least structurally valid).

Variability management of a product family is the core aspect of Software Product Line Engineering. The adoption of this mature approach requires a high upfront investment before being able to automatically generate product instances based on customer requirements. However, this adoption costs and risks could be reduced with an incremental approach, which mines existing assets and then transitions to full product line engineering. Those existing assets can be for instance similar product variants that were implemented using ad-hoc reuse techniques such as clone-and-own. Hence, there is a great need of bottom-up approaches that extract variability from the artifacts (across all the life cycle) of the legacy product variants and manage the consolidated variability. The REVE workshop series aims to bring together the Reengineering and Software Product Line Engineering communities to address this gap.

Although Software Product Lines are recurrently praised as an efficient paradigm for systematic reuse, practical adoption remains challenging. For bottom-up Software Product Line adoption, where a set of artefact variants already exists, practitioners lack end-to-end support for chaining (1) feature identification, (2) feature location, (3) feature constraints discovery, as well as (4) reengineering approaches. This challenge can be overcome if there exists a set of principles for building a framework to integrate various algorithms and to support different artefact types. In this paper, we propose the principles of such a framework and we provide insights on how it can be extended with adapters, algorithms and visualisations enabling their use in different scenarios. We describe its realization in BUT4Reuse (Bottom--Up Technologies for Reuse) and we assess its generic and extensible properties by implementing a variety of extensions. We further empirically assess the complexity of integration by reproducing case studies from the literature. Finally, we present an experiment where users realize a bottom-up Software Product Line adoption building on the case study of Eclipse variants.

Variability management of a product family is the core aspect of Software Product Line Engineering. The adoption of this mature approach requires a high upfront investment before being able to automatically generate product instances based on customer requirements. However, this adoption costs and risks could be reduced with an incremental approach, which mines existing assets and then transitions to full product line engineering. Those existing assets can be for instance similar product variants that were implemented using ad-hoc reuse techniques such as clone-and-own. Bottom-up approaches to automatically extract variability management related artifacts could be proposed, applied, validated and improved in this domain therefore the REVE workshop aims to fill the gap between the Reengineering and Software Product Line Engineering communities.

Software Product Line Engineering is a mature approach enabling the derivation of product variants by assembling reusable assets. In this context, domain experts widely use Feature Models as the most accepted formalism for capturing commonality and variability in terms of features. Feature Models also describe the constraints in feature combinations. In industrial settings, domain experts often deal with Software Product Lines with high numbers of features and constraints. Furthermore, the set of features are often regrouped in different subsets that are overseen by different stakeholders in the process. Consequently, the management of the complexity of large Feature Models becomes challenging. In this paper we propose a dedicated interactive visualisation paradigm to help domain experts and stakeholders to manage the challenges in maintaining the constraints among features. We build Feature Relations Graphs (Frogs) by mining existing product configurations. For each feature, we are able to display a Frog which shows the impact, in terms of constraints, of the considered feature on all the other features. The objective is to help domain experts to 1) obtain a better understanding of feature constraints, 2) potentially refine the existing feature model by uncovering and formalizing missing constraints and 3) serve as a recommendation system, during the configuration of a new product, based on the tendencies found in existing configurations. The paper illustrates the visualisation paradigm with the industrial case study of Renault's Electric Parking System Software Product Line.

Software Product Line Engineering (PLE) exploits systematic reuse by identifying and methodically reusing software artifacts to develop different but related software systems. Developing Product Lines requires analysis skills to identify, model, and encode domain and product knowledge into artifacts that can be systematically reused across the development life-cycle. As such, Knowledge plays a paramount role in the success of the various activities of PLE. The objective of the KOPLE workshop series is to bring together SPL researchers and practitioners from academia and industry to investigate the role of Knowledge in PLE. Knowledge is usually encapsulated in PL architectures in a tacit or implicit way, and this may appear to be sufficient for industry to implement successful product lines. Nevertheless, KOPLE also aims to become a discussion forum about techniques and methods to convert from tacit to explicit Knowledge in PLE and to process and use this Knowledge for optimizing and innovating PLE processes.

Companies that develop similar software systems often transition from single-system development to software product line development. In this transition, reusable assets are identified and incrementally created over a period of time. Bottom-up Software Product Line Engineering approaches aid stakeholders to identify variability from the legacy artifacts. One of these artifacts is the legacy source code. In this paper, we contribute the Collaboration and Source Code Driven Bottom-up approach, with two main enhancements. We apply clone detection and architecture reengineering techniques for identifying variability from the legacy artifacts. These techniques which have been traditionally used for maintaining software are now used for identifying variability and analyze code coupling and cohesion from the legacy code. Our second enhancement is improving stakeholder collaboration by guiding the domain experts in order to decide on variability. In particular, we apply Questions, Options and Criteria technique for capturing rationale and supporting collaboration.

Software Product Line Engineering (PLE) exploits systematic reuse by identifying and methodically reusing software artifacts to develop different but related software systems. Developing Product Lines requires analysis skills to identify, model, and encode domain and product knowledge into artifacts that can be systematically reused across the development life-cycle. As such, Knowledge plays a paramount role in the success of the various activities of PLE. The objective of KOPLE is to bring together SPL researchers and practitioners from academia and industry to investigate the role of Knowledge in PLE. Knowledge is usually encapsulated in PL architectures in a tacit or implicit way, and this may appear to be sufficient for industry to implement successful product lines. Nevertheless, KOPLE also aims to become a discussion forum about techniques and methods to convert from tacit to explicit Knowledge in PLE and to process and use this Knowledge for optimizing and innovating PLE processes.