Wolfram Fenske

Variant-preserving refactorings for migrating cloned products to a product line

A common and simple way to create custom product variants is to copy and adapt existing software (a. k. a. the clone-and-own approach). Clone-and-own promises low initial costs for creating a new variant as existing code is easily reused. However, clone-and-own also comes with major drawbacks for maintenance and evolution since changes, such as bug fixes, need to be synchronized among several product variants. Software product lines (SPLs) provide solutions to these problems because commonalities are implemented only once. Thus, in an SPL, changes also need to be applied only once. Therefore, the migration of cloned product variants to an SPL would be beneficial. The main tasks of migration are the identification and extraction of commonalities from existing products. However, these tasks are challenging and currently not well-supported. In this paper, we propose a step-wise and semi-automated process to migrate cloned product variants to a feature-oriented SPL. Our process relies on clone detection to identify code that is common to multiple variants and novel, variant-preserving refactorings to extract such common code. We evaluated our approach on five cloned product variants, reducing code clones by 25 %. Moreover, we provide qualitative insights into possible limitations and potentials for removing even more redundant code. We argue that our approach can effectively decrease synchronization effort compared to clone-and-own development and thus reduce the long-term costs for maintenance and evolution.

Use-Case-Specific Source-Code Documentation for Feature-Oriented Programming

Source-code documentation is essential to efficiently develop and maintain large software products. Documentation is equally important for software product lines (SPLs), which represent a set of different products with a common code base. Unfortunately, proper support for documenting the source code of an SPL is currently lacking, because source code variability is not considered by current documentation tools. We introduce a method to provide source-code documentation for feature-oriented programming and aim to support developers who implement, maintain, and use SPLs. We identify multiple use cases for developers working with SPLs and propose four different documentation types (meta, product, feature, and context) that fulfill the information requirements of these use cases. Furthermore, we design an algorithm that enables developers to create tailor-made documentation for each use case. Our method is based on the documentation tool Javadoc and allows developers to easily write documentation comments that contain little overhead or redundancy. To demonstrate the efficiency of our method, we present a prototypical implementation and evaluate our method with regard to documentation effort for the SPL developers by documenting two small SPLs.

Extracting software product lines: a cost estimation perspective

Companies are often forced to customize their software products. Thus, a common practice is to clone and adapt existing systems to new customer requirements. With the extractive approach, those derived variants can be migrated into a software product line. However, changing to a new development process is risky and may result in unnecessary costs. Therefore, companies apply cost estimations to predict whether another development approach is beneficial. Existing cost models for software-product-line engineering focus on development from scratch. Contrarily, the extractive approach is more common in practice but specialized models are missing. Thus, in this work we focus on product-line extraction from a set of legacy systems. We i) describe according cost factors, ii) put them in context with the development process and cost curves, and iii) identify open challenges in product-line economics. This way, our work supports cost estimations for the extractive approach and provides a basis for further research.

Code Smells Revisited: A Variability Perspective

Highly-configurable software systems (also called software product lines) gain momentum in both, academia and industry. For instance, the Linux kernel comes with over 12 000 configuration options and thus, can be customized to run on nearly every kind of system. To a large degree, this configurability is achieved through variable code structures, for instance, using conditional compilation. Such source code variability adds a new dimension of complexity, thus giving rise to new possibilities for design flaws. Code smells are an established concept to describe design flaws or decay in source code. However, existing smells have no notion of variability and thus do not support flaws regarding variable code structures. In this paper, we propose an initial catalog of four variability-aware code smells. We discuss the appearance and negative effects of these smells and present code examples from real-world systems. To evaluate our catalog, we have conducted a survey amongst 15 researchers from the field of software product lines. The results confirm that our proposed smells (a) have been observed in existing product lines and (b) are considered to be problematic for common software development activities, such as program comprehension, maintenance, and evolution.

Synchronizing software variants with variantsync

Developing and managing software variants is a key challenge in todays software development. Due to conflicting requirements, software is developed in multiple variants to satisfy the needs of individual customers. While software product lines allow the efficient development of a high number of variants, many projects in industrial software development start with few variants, where each variant is developed separately. Unfortunately, for an increasing number of variants, this clone-and-own approach becomes error-prone and unprofitable regarding synchronization of changes between variants. With VariantSync, we demonstrate a tool to reduce the gap between clone-and-own and product lines by automating the synchronization of software variants and simplifying a potential later transition to a product line.

Finding Lost Features in Cloned Systems

Copying and adapting a system, also known as clone-and-own, is a common reuse approach that requires little initial effort. However, the drawbacks of clones are increasing maintenance costs as bug fixes and updates must be propagated. To reduce these costs, migrating cloned legacy systems towards a software product line promises to enable systematic reuse and customization. For both, managing and migrating cloned systems, it remains a challenge to identify and map features in the systems. In this paper, we i) propose a semi-automatic process to identify and map features between legacy systems, ii) suggest a corresponding visualization approach, and iii) assess our process on a case study. The results indicate that our process is suitable to identify features and present commonalities and variability in cloned systems. Our process can be used to enable traceability, prepare refactorings, and extract software product lines.

Apo-games: a case study for reverse engineering variability from cloned Java variants

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.

Comparing algorithms for efficient feature-model slicing

Feature models are a well-known concept to represent variability in software product lines by defining features and their dependencies. During feature-model evolution, for information hiding, and for feature-model analyses, it is often necessary to remove certain features from a model. As the crude deletion of features can have undesirable effects on their dependencies, dependency-preserving algorithms, known as feature-model slicing, have been proposed. However, current algorithms do not perform well when removing a high number of features from large feature models. Therefore, we propose an efficient algorithm for feature-model slicing based on logical resolution and the minimization of logical formulas. We empirically evaluate the scalability of our algorithm on a number of feature models and find that our algorithm generally outperforms existing algorithms.

When code smells twice as much: Metric-based detection of variability-aware code smells

Code smells are established, widely used characterizations of shortcomings in design and implementation of software systems. As such, they have been subject to intensive research regarding their detection and impact on understandability and changeability of source code. However, current methods do not support highly configurable software systems, that is, systems that can be customized to fit a wide range of requirements or platforms. Such systems commonly owe their configurability to conditional compilation based on C preprocessor annotations (a. k. a. #ifdefs). Since annotations directly interact with the host language (e. g., C), they may have adverse effects on understandability and changeability of source code, referred to as variability-aware code smells. In this paper, we propose a metric-based method that integrates source code and C preprocessor annotations to detect such smells. We evaluate our method for one specific smell on five open-source systems of medium size, thus, demonstrating its general applicability. Moreover, we manually reviewed 100 instances of the smell and provide a qualitative analysis of its potential impact as well as common causes for the occurrence.

Protein Identification as a Suitable Application for Fast Data Architecture

Metaproteomics is a field of biology research that relies on mass spectrometry to characterize the protein complement of microbiological communities. Since only identified data can be analyzed, identification algorithms such as X!Tandem, OMSSA and Mascot are essential in the domain, to get insights into the biological experimental data. However, protein identification software has been developed for proteomics. Metaproteomics, in contrast, involves large biological communities, gigabytes of experimental data per sample, and greater amounts of comparisons, given the mixed culture of species in the protein database. Furthermore, the file-based nature of current protein identification tools makes them ill-suited for future metaproteomics research. In addition, possible medical use cases of metaproteomics require near real-time identification. From the technology perspective, Fast Data seems promising to increase throughput and performance of protein identification in a metaproteomics workflow. In this paper we analyze the core functions of the established protein identification engine X!Tandem and show that streaming Fast Data architectures are suitable for protein identification. Furthermore, we point out the bottlenecks of the current algorithms and how to remove them with our approach.