FEVER: An approach to analyze feature-oriented changes and artefact co-evolution in highly configurable systems

Abstract

The evolution of highly configurable systems is known to be a challenging task. Thorough understanding of configuration options their relationships, and their implementation in various types of artefacts (variability model, mapping, and implementation) is required to avoid compilation errors, invalid products, or dead code. Recent studies focusing on co-evolution of artefacts detailed feature-oriented change scenarios, describing how related artefacts might change over time. However, relying on manual analysis of commits, such work do not provide the means to obtain quantitative information on the frequency of described scenarios nor information on the exhaustiveness of the presented scenarios for the evolution of a large scale system. In this work, we propose FEVER and its instantiation for the Linux kernel. FEVER extracts detailed information on changes in variability models (KConfig files), assets (preprocessor based C code), and mappings (Makefiles). We apply this methodology to the Linux kernel and build a dataset comprised of 15 releases of the kernel history. We performed an evaluation of the FEVER approach by manually inspecting the data and compared it with commits in the system's history. The evaluation shows that FEVER accurately captures feature related changes for more than 85% of the 810 manually inspected commits. We use the collected data to reflect on occurrences of co-evolution (2018) 23:905-952 in practice. Our analysis shows that complex co-evolution scenarios occur in every studied release but are not among the most frequent change scenarios, as they only occur for 8 to 13% of the evolving features. Moreover, only a minority of developers working on a given release will make changes to all artefacts related to a feature (between 10% and 13% of authors). While our conclusions are derived from observations on the evolution of the Linux kernel, we believe that they may have implications for tool developers as well as guide further research in the field of co-evolution of artefacts.Empir Software Eng

Mining Feature Revisions in Highly-Configurable Software Systems

“…Israeli and Feitelson [15] studied the Linux evolution in relation to the complexity of functions. The FEVER approach [8] is also applied to extract information of the Linux kernel evolution, extracting information about which features changed in the variability models (KConfig files), assets (preprocessor based C code), and mappings (Makefiles). They considered as features the ones defined in the KConfig file, and the source files are the ones mapped to the features in the Makefiles.…”

“…Annotation-based SPLs are often implemented as Highly-Configurable Software Systems (HCSSs) [16]. HCSSs use techniques such as feature flags, feature toggles, or feature switches, to turn on configuration options/features needed to be included in a product [8,18,27]. However, features also need to evolve over time.…”

GuyDance

“…To increase the level of automation, templates that match the changes performed by domain engineers could be automatically detected by analyzing the actually performed changes and comparing to the changes defined in the templates. For instance, the tool FEVER [8] is able to extract and detect changes that match a certain pattern, such as evolution scenarios described in the templates.…”

“…Recent research analyzed and categorized evolution of product lines and, in particular, the mapping between variability model and artifacts [6,8,17,35]. However, the guided configuration evolution is more generic and helps to update configurations.…”

“…However, the guided configuration evolution is more generic and helps to update configurations. With FEVER, Dintzner et al introduced a tool to extract changes to variability models, code artifacts, and the corresponding mapping [8]. FEVER could be used in combination with our methodology to identify commits of a product line that match a certain pattern, such as the evolution scenarios described with guidance templates.…”