Automated analysis of feature models: Quo vadis?

Feature models have been used since the 90's to describe software product lines as a way of reusing common parts in a family of software systems. In 2010, a systematic literature review was published summarizing the advances and settling the basis of the area of Automated Analysis of Feature Models (AAFM). From then on, different studies have applied the AAFM in different domains. In this paper, we provide an overview of the evolution of this field since 2010 by performing a systematic mapping study considering 423 primary sources. We found six different variability facets where the AAFM is being applied that define the tendencies: product configuration and derivation; testing and evolution; reverse engineering; multi-model variability-analysis; variability modelling and variability-intensive systems. We also confirmed that there is a lack of industrial evidence in most of the cases. Finally, we present where and when the papers have been published and who are the authors and institutions that are contributing to the field. We observed that the maturity is proven by the increment in the number of journals published along the years as well as the diversity of conferences and workshops where papers are published. We also suggest some synergies with other areas such as cloud or mobile computing among others that can motivate further research in the future.Ministerio de Economía y Competitividad TIN2015-70560-RJunta de Andalucía TIC-186

ModelVars2SPL : an automated approach to reengineer model variants into software product lines

Orientadora : Profª. Drª. Silvia R. VergilioCoorientador : Prof Dr. Roberto E. Lopez-HerrejonTese (doutorado) - Universidade Federal do Paraná, Setor de Ciências Exatas, Programa de Pós-Graduação em Informática. Defesa: Curitiba, 11/04/2017Inclui referências : f. 74-82Área de concentração : Ciência da computaçãoResumo: Linhas de Produto de Software (LPSs) são famílias de sistemas de software relacionados que são desenvolvidos para um segmento de mercado ou domínio. Comumente, LPSs surgem de um conjunto de variantes existentes, quando a manutenção e/ou evolução individuais tornam-se complexas. Contudo, as abordagens encontradas na literatura para extração de LPS a partir de variantes existentes não dão suporte a modelos de projeto, são parcialmente automatizadas, ou não refletem restrições de domínio em termos de combinação de características. Para lidar com estas limitações, o objetivo deste trabalho é apresentar uma abordagem automatizada para fazer a reengenharia de variantes de modelos em uma LPS, chamada ModelVars2SPL (Variantes de Modelos para Linha de Produto de Software, do Inglês Model Variants to Software Product Line). A entrada para a abordagem é um conjunto de diagramas de classe Linguagem de Modelagem Unificada (UML) e uma lista de características que estes implementam. Todo o processo de reengenharia é coberto, e a saída inclui (i) um Modelo de Características, que representa a combinação de características das variantes de entrada, e (ii) uma Arquitetura de Linha de Produto, que representa uma arquitetura global com características anotadas. O processo de reengenharia da ModelVars2SPL é composto por quatro passos, sendo dois deles apoiados em técnicas baseadas em busca, e os dois outros baseados em algoritmos determinísticos. Não existe a necessidade de especialistas humanos para obter soluções. Para avaliar a abordagem proposta, foi conduzido um experimento para aferir a qualidade das soluções obtidas. A qualidade dos Modelos de Características e das Arquiteturas de Linha de Produto foi medida considerando-se o quão bem as variantes de entrada foram representadas. Além disso, a qualidade das saídas em cada passo da abordagem foi avaliada levando-se em consideração os objetivos do processo de reengenharia. Para a experimentação utilizaram-se dez estudos de caso representando dois cenários diferentes. Os resultados da avaliação mostram que a abordagem consegue obter soluções com alto grau de corretude em termos de representação das variantes de entrada, e que as saídas dos passos estão de acordo com as fases do processo de reengenharia. Com base em um exemplo de uso de uma solução mostra-se como os artefatos de LPS obtidos facilitam a atividade de manutenção. Palavras-chave: Reúso, Reengenharia, Linha de Produto de Software, Extração de LPS, Engenharia de Software Baseada em Busca.Abstract: Software Product Lines (SPLs) are families of related software systems developed for specific market segments or domains. SPLs commonly emerge from sets of existing variants when their individual maintenance and/or evolution become complex. However, current approaches for SPL extraction from existing variants do not support design models, are partially automated, or do not reflect domain constraints in terms of feature combinations. To tackle these limitations, the goal of this work is to present an automated approach to reengineer model variants into an SPL, called ModelVars2SPL (Model Variants to Software Product Line). The input of the approach is a set of Unified Modeling Language (UML) class diagrams and the list of features they implement. All the reengineering process is covered, and the output includes (i) a Feature Model, which represents the combinations of features of the input variants, and (ii) a Product Line Architecture, which represents a global architecture with feature-related annotations. The reengineering process of ModelVars2SPL is composed of four steps, two of them rely on searchbased techniques and the others are based on deterministic algorithms. There is no need for human experts for obtaining solutions. We conducted an experiment to evaluate the quality of the solutions obtained with the proposed approach. The quality of the FMs and PLAs was measured by considering how well these artifacts represent the input variants. Furthermore, we evaluate the quality of the outputs in each step of the approach taking into account the goals of the reengineering process. For the experimentation we used ten case studies representing two di_erent scenarios. The results of the evaluation show that the approach can obtain solutions with high degree of correctness in terms of representing the input variants, and that the outputs of the steps are in accordance to the phases of the reengineering process. Based on an example of use we show how the obtained FM and PLA make easier the maintenance activity. Keywords: Reuse, Reengineering, Software Product Line, SPL extraction, Search-Based Software Engineering

Evolution, testing and configuration of variability intensive systems

Tesis descargada desde ResearchGateOne of the key characteristics of software is its ability to be adapted and configured to different scenarios. Recently, software variability has been studied as a first-class concept in different domains ranging from software product lines to pervasive systems. Variability is the ability of a software product to vary depending on different circumstances. Variability intensive systems are those software products where variability management is a core engineering activity. The varying parts of those systems are commonly modeled by us- ing different variability model flavors, being feature modeling one of the most common ones. Feature models were first introduced by Kang et al. back in 1990 and are a compact representation of a set of configurations in a variability intensive system. The large number of configurations that a feature model can encode makes the manual analysis of feature models an error prone and costly task. Then, computer-aided mechanisms appeared as a solution to extract useful information from feature models. This process of extracting information from feature models is known as ¿Automated Analysis of Feature models¿ that has been one of the main areas of research in the last years where more than thirty analysis operations have been proposed.Premio Extraordinario de Doctorado U

Spl needs an automatic holistic model for software reasoning with feature models

The number of features and their relations in a Software Product Line (SPL) may lead to have SPLs with a big number of potential products which may be difficult to manage. This number of potential products widely increases if, as well as functional features, extra–functional features are taken into account. There are several questions that a SPL engineer would like to ask to his SPL model such as: is it a valid model?, how many potential products a SPL has?, is there any product fulfilling the customer needs? and so forth. These types of questions are error prone to answer without an automatic support. The work reported in this position paper glipmses some misconceptions of previous related proposals: we uphold the need to have an holistic product line model were not distinction are made between functional and extra–functional features, we propose a model based on a formalism strong enough to support both type o features: contraint programming.Ministerio de Ciencia y Tecnología TIC2003-02737-C02-0

Fundamental Approaches to Software Engineering

computer software maintenance; computer software selection and evaluation; formal logic; formal methods; formal specification; programming languages; semantics; software engineering; specifications; verificatio

Monte Carlo Tree Search for Feature Model Analyses: a General Framework for Decision-Making

The colossal solution spaces of most configurable systems make intractable their exhaustive exploration. Accordingly, relevant anal-yses remain open research problems. There exist analyses alterna-tives such as SAT solving or constraint programming. However, none of them have explored simulation-based methods. Monte Carlo-based decision making is a simulation based method for deal-ing with colossal solution spaces using randomness. This paper proposes a conceptual framework that tackles various of those anal-yses using Monte Carlo methods, which have proven to succeed in vast search spaces (e.g., game theory). Our general framework is described formally, and its flexibility to cope with a diversity of analysis problemsis discussed (e.g., finding defective configurations, feature model reverse engineering or getting optimal performance configurations). Additionally, we present a Python implementation of the framework that shows the feasibility of our proposal. With this contribution, we envision that different problems can be ad dressed using Monte Carlo simulations and that our framework can be used to advance the state of the art a step forward.Ministerio de Economía y Competitividad RTI2018-101204-B-C22 (OPHELIA

Variability Anomalies in Software Product Lines

Software Product Lines (SPLs) allow variants of a software system to be generated based on the configuration selected by the user. In this thesis, we focus on C based software systems with build-time variability using a build system and C preprocessor. Such systems usually consist of a configuration space, a code space, and a build space. The configuration space describes the features that the user can select and any configuration constraints between them. The features and the constraints between them are commonly documented in a variability model. The code and build spaces contain the actual implementation of the system where the former contains the C code files with conditional compilation directives (e.g., #ifdefs), and the latter contains the build scripts with conditionally compiled files. We study the relationship between the three spaces as follows: (1) we detect variability anomalies which arise due to inconsistencies among the three spaces, and (2) we use anomaly detection techniques to automatically extract configuration constraints from the implementation. For (1), we complement previous research which mainly focused on the relationship between the configuration space and code space. We additionally analyze the build space to ensure that the constraints in all three spaces are consistent. We detect inconsistencies, which we call variability anomalies, in particular dead and undead artifacts. Dead artifacts are conditional artifacts which are not included in any valid configuration while undead artifacts are those which are always included. We look for such anomalies at both the code block and source file levels using the Linux kernel as a case study. Our work shows that almost half the configurable features are only used to control source file compilation in Linux’s build system, KBUILD . We analyze KBUILD to extract file presence conditions which determine under which feature combinations is each file compiled. We show that by considering the build system, we can detect an additional 20% variability anomalies on the code block level when compared to only using the configuration and code spaces. Our work also shows that file level anomalies occur less frequently than block level ones. We analyze the evolution of the detected anomalies and identify some of their causes and fixes. For (2), we develop novel analyses to automatically extract configuration constraints from implementation and compare them to those in existing variability models. We rely on two means of detecting variability anomalies: (a) conditional build-time errors and (b) detecting under which conditions a feature has an effect on the compiled code (to avoid duplicate variants). We apply this to four real-world systems: uClibc, BusyBox, eCos, and the Linux kernel. We show that our extraction is 93% and 77% accurate respectively for the two means we use and that we can recover 19 % of the existing variability-model constraints using our approach. We qualitatively investigate the non-recovered constraints and find that many of them stem from domain knowledge. For systems with existing variability models, understanding where each constraint comes from can aid in traceability between the code and the model which can help in debugging conflicts. More importantly, in systems which do not have a formal variability model, automatically extracting constraints from code provides the basis for reverse engineering a variability model. Overall, we provide tools and techniques to help maintain and create software product lines. Our work helps to ensure the consistency of variability constraints scattered across SPLs and provides tools to help reverse engineer variability models