An analysis of the variability in forty preprocessor-based software product lines

Liebig, Jörg; Apel, Sven; Lengauer, Christian; Kästner, Christian; Schulze, Michael

doi:10.1145/1806799.1806819

Cited by 272 publications

(260 citation statements)

References 37 publications

Supporting

Mentioning

247

Contrasting

Order By: Relevance

“…Finally, some works discuss characteristics of feature implementations in code, such as feature cohesion and coupling [1] or granularity, frequency and structure of preprocessor annotations [12,16]. However, these works are not easily generalizable to address the issue of structural complexity of models.…”

Section: Discussion and Related Workmentioning

confidence: 99%

Quality of Merge-Refactorings for Product Lines

Rubin

Chećhik

2013

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

Abstract. In this paper, we consider the problem of refactoring related software products specified in UML into annotative product line representations. Our approach relies on identifying commonalities and variabilities in existing products and further merging those into product line representations which reduce duplications and facilitate reuse. Varying merge strategies can lead to producing several semantically correct, yet syntactically different refactoring results. Depending on the goal of the refactoring, one result can be preferred to another. We thus propose to capture the goal using a syntactic quality function and use that function to guide the merge strategy. We define and implement a quality-based mergerefactoring framework for UML models containing class and statechart diagrams and report on our experience applying it on three case-studies.

show abstract

Section: Discussion and Related Workmentioning

confidence: 99%

Quality of Merge-Refactorings for Product Lines

Rubin

Chećhik

2013

Fundamental Approaches to Software Engineering

View full text Add to dashboard Cite

show abstract

“…We consider only configurable implementation assets (source files). We focus specifically on pre-processor based variability implementation (using #ifdef statements), which, despite known limitations (Spencer and Collyer 1992), is still widely used today (Liebig et al 2010). An example of an addition of a pre-processor statement is presented in Listing 3 where feature SQUASHFS FILE DIRECT is used to condition the compilation of two code blocks, one…”

Section: Assetsmentioning

confidence: 99%

“…To rebuild the models, we rely on CPPSTATS (Liebig et al 2010) to obtain starting and ending lines of each #ifdef block as well as their guarding condition. It should be noted that Fig.…”

Section: Extracting Implementation Changesmentioning

confidence: 99%

“…In this study, we used the approach presented in Liebig et al (2010) to identify code blocks and their conditions, and we then relied on this representation to build a model of implementation assets.…”

Section: Related Workmentioning

confidence: 99%

“…The benefits of such development strategies are to reduce the time to market, as masscustomization facilitates the creation of tailored solutions, and improved software quality, as re-used components are tested in various contexts (Clements and Northorp 2002). Examples of such systems can be found in various domains, such as database management (Rosenmüller et al 2008;Batory et al 1988), SOA based systems (Kumara et al 2013), operating systems , and a number 1 of industrial and open source software projects (Liebig et al 2010) among which the Linux kernel may be the best known.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

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

2017

View full text Add to dashboard Cite

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

show abstract

The Linux kernel: a case study of build system variability

Nadi

Holt

2013

J Software Evolu Process

View full text Add to dashboard Cite

SUMMARYAlthough build systems control what code gets compiled into the final built product, they are often overlooked when studying software variability. The Linux kernel is one of the biggest open source software systems supporting variability and contains over 10,000 configurable features described in its KCONFIG files. To understand the role of the build system in variability implementation, we use Linux as a case study. We study its build system, KBUILD, and extract the variability constraints in its Makefiles. We first provide a quantitative analysis of the variability in KBUILD. We then study how the variability constraints in the build system affect variability anomalies detected in Linux. We concentrate on dead and undead artifacts, and by extending previous work, we show that considering build system variability constraints allows more anomalies to be detected. We provide examples of such anomalies on both the code block and source file level. Our work shows that KBUILD contains a large percentage of the variability information in Linux, so it should not be ignored during variability analysis. Nonetheless, the anomalies we find suggest that variability on the file level in KBUILD is consistent with KCONFIG, whereas the constraints on the code level are harder to keep consistent with both KBUILD and KCONFIG.

show abstract

An analysis of the variability in forty preprocessor-based software product lines

Cited by 272 publications

References 37 publications

Quality of Merge-Refactorings for Product Lines

Quality of Merge-Refactorings for Product Lines

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

The Linux kernel: a case study of build system variability

Contact Info

Product

Resources

About