Jacob Krüger

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.

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.

FeatureCoPP: compositional annotations

Software product lines can be implemented with different techniques. Those techniques can be grouped into annotation-based and composition-based approaches, with complementary strengths and weaknesses. A combination seems useful to utilize benefits of both groups but using two techniques in parallel may cause new problems. To our knowledge, there is no approach that integrates composition into an annotation-based approach or vice versa. We propose the use of an extended preprocessor to introduce physical separation of concerns similar to feature-oriented programming. In this paper, we i) present a preliminary implementation that integrates composition into annotation, ii) analyse its benefits and shortcomings, and iii) discuss implementation and tooling. Overall, we enable developers to keep on using familiar preprocessors but also to benefit from composition. Finally, we show the potential of our approach.

Lost in source code: physically separating features in legacy systems

Feature-oriented programming allows developers to physically separate and reuse features via composition. This promises several benefits compared to other reuse approaches, for instance, easier traceability and maintenance. However, due to their simplicity cloning and annotation-based product lines are established in practice. We aim to reduce risks and costs of migrating towards composition, lowering the adoption barrier. This includes i) processes, ii) migration approaches, and iii) assessing advantages and disadvantages. Overall, we will facilitate integrating physical separation into legacy applications.

Towards a Better Understanding of Software Features and Their Characteristics: A Case Study of Marlin

The notion of features is commonly used to describe, structure, and communicate the functionalities of a system. Unfortunately, features and their locations in software artifacts are rarely made explicit and often need to be recovered by developers. To this end, researchers have conceived automated feature-location techniques. However, their accuracy is generally low, and they mostly rely on few information sources, disregarding the richness of modern projects. To improve such techniques, we need to improve the empirical understanding of features and their characteristics, including the information sources that support feature location. Even though, the product-line community has extensively studied features, the focus was primarily on variable features in preprocessor-based systems, largely side-stepping mandatory features, which are hard to identify. We present an exploratory case study on identifying and locating features. We study what information sources reveal features and to what extent, compare the characteristics of mandatory and optional features, and formulate hypotheses about our observations. Among others, we find that locating features in code requires substantial domain knowledge for half of the mandatory features (e.g., to connect keywords) and that mandatory and optional features in fact differ. For instance, mandatory features are less scattered. Other researchers can use our manually created data set of features locations for future research, guided by our formulated hypotheses.

FeatureIDE: Empowering Third-Party Developers

FeatureIDE is a popular open-source tool for modeling, implementing, configuring, and analyzing software product lines. However, FeatureIDEs initial design was lacking mechanisms that facilitate extension and reuse of core implementations. In current releases, we improve these traits by providing a modular concept for core data structures and functionalities. As a result, we are facilitating the usage of external implementations for feature models and file formats within FeatureIDE. Additionally, we provide a Java library containing FeatureIDEs core functionalities, including feature modeling and configuration. This allows developers to use these functionalities in their own tools without relying on external dependencies, such as the Eclipse framework.

Comprehending studies on program comprehension

Program comprehension is an important aspect of developing and maintaining software, as programmers spend most of their time comprehending source code. Thus, it is the focus of many studies and experiments to evaluate approaches and techniques that aim to improve program comprehension. As the amount of corresponding work increases, the question arises how researchers address program comprehension. To answer this question, we conducted a literature review of papers published at the International Conference on Program Comprehension, the major venue for research on program comprehension. In this article, we i) present preliminary results of the literature review and ii) derive further research directions. The results indicate the necessity for a more detailed analysis of program comprehension and empirical research.

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.

Composing annotations without regret? Practical experiences using FeatureC

Software product lines enable developers to derive similar products from a common code base. Existing implementation techniques can be categorized as composition‐based and annotation‐based approaches, with both approaches promising complementary benefits. However, annotation‐based approaches are commonly used in practice despite composition allowing physical separation of features and, thus, improving traceability and maintenance. A main hindrance to migrate annotated systems toward a composition‐based product line is the challenging and time‐consuming transformation task. For a company, it is difficult to predict the corresponding costs, and a successful outcome is uncertain. To overcome such problems, a solution proposed by the previous work is to use a hybrid approach, utilizing composition and annotation simultaneously. Based on this idea, we introduce a stepwise migration process from annotation‐based toward composition‐based approaches to lower the adoption barrier of composition. This process itself is independent of used implementation techniques and enables developers to incrementally migrate toward composition. We support our approach with detailed examples by partially migrating a real‐world system. In detail, we describe the following: (1) our migration process, (2) its application on a real‐world system, and (3) discuss practical challenges we face. We implemented the proposed approach and show that appropriate tool support helps to migrate toward composition‐based product lines. Based on the case study, we show that the hybrid product lines work correctly and can compete with the performance of the original annotated system. However, the results also illustrate open issues that have to be solved to apply such migrations in practice.

Daedalus or icarus?: experiences on follow-the-sun

Follow-the-sun is an approach to develop software by handing off the progress to different time zones as the day passes. Hence, this approach allows companies to work on a project 24 hours a day, potentially reducing its time-to-market. However, several challenges, such as time zone differences or handing off work, are often reported. In this paper, we describe a case study on a follow-the-sun approach that was applied in a German company. During the approach, we did rarely face the aforementioned challenges but experienced different ones. For this reason, the company put its approach on hold but benefited from the learned lessons. Overall, we report on a partly successful follow-the-sun approach and identify five important practices.