Sandro Schulze

DeltaJ 1.5: delta-oriented programming for Java 1.5

Delta-oriented programming (DOP) is a modular, yet flexible approach to implement software product lines. In DOP, a product line is implemented by a set of deltas, which are containers of modifications to a program. A delta-oriented product line is specified by its code base, i.e., the set of delta modules, and a product line declaration specifying the set of possible product variants. In this paper, we present DOP for Java 1.5 extending previous proof-of-concept realizations of DOP for simple core Java-like languages. The novel prototypical implementation DeltaJ 1.5 provides full integrated access to the object-oriented features of Java. The extensions include delta operations to fully integrate the Java package system, to declare and modify interfaces, to explicitly change the inheritance hierarchy, to access nested types and enum types, to alter field declarations, and to unambiguously remove overloaded methods. Furthermore, we improve the specification of the product line declaration by providing a separate language. We have evaluated DeltaJ 1.5 using a case study.

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.

Code clones in feature-oriented software product lines

Some limitations of object-oriented mechanisms are known to cause code clones (e.g., extension using inheritance). Novel programming paradigms such as feature-oriented programming (FOP) aim at alleviating these limitations. However, it is an open issue whether FOP is really able to avoid code clones or whether it even facilitates (FOP-related) clones. To address this issue, we conduct an empirical analysis on ten feature-oriented software product lines with respect to code cloning. We found that there is a considerable number of clones in feature-oriented software product lines and that a large fraction of these clones is FOP-related (i.e., caused by limitations of feature-oriented mechanisms). Based on our results, we initiate a discussion on the reasons for FOP-related clones and on how to cope with them. We show by means of examples how such clones can be removed by applying refactorings.

Interface variability in family model mining

Model-driven development of software gains more and more importance, especially in domains with high complexity. In order to develop differing but still similar model-based systems, these models are often copied and modified according to the changed requirements. As the variability between these different models is not documented, issues arise during maintenance. For example, applying patches becomes a tedious task because errors have to be fixed in all of the created models and no information about modified and unchanged parts exists. In this paper, we present an approach to analyze related models and determine the variability between them. This analysis provides crucial information about the variability (i.e., changed parts, additional parts, and parts without any modification) between the models in order to create family models. The particular focus is the analysis of models containing components with differing interfaces.

Refactoring delta-oriented software product lines

Delta-oriented programming (DOP) is an implementation approach to develop software product lines (SPL). Delta-oriented SPLs evolve over time due to new or changed requirements and need to be maintained to retain their value. Refactorings have been proposed as behavior-preserving program transformations that improve the design and structure of (object-oriented) software systems. However, there is a lack of refactoring support for software product lines since refactoring of SPLs is more complex than of single systems. For refactoring SPLs, we have to preserve the behavior of probably thousands of programs instead of only one. In this paper, we address the refactoring of software product lines by presenting a catalogue of refactorings for delta-oriented SPLs. Additionally, we propose code smells to guide developers to potential refactoring opportunities. We show how code smells can aid the identification of SPL refactorings and how these refactorings improve the evolvability and maintainability of delta-oriented SPLs.

Does the discipline of preprocessor annotations matter?: a controlled experiment

The C preprocessor (CPP) is a simple and language-independent tool, widely used to implement variable software systems using conditional compilation (i.e., by including or excluding annotated code). Although CPP provides powerful means to express variability, it has been criticized for allowing arbitrary annotations that break the underlying structure of the source code. We distinguish between disciplined annotations, which align with the structure of the source code, and undisciplined annotations, which do not. Several studies suggest that especially the latter type of annotations makes it hard to (automatically) analyze the code. However, little is known about whether the type of annotations has an effect on program comprehension. We address this issue by means of a controlled experiment with human subjects. We designed similar tasks for both, disciplined and undisciplined annotations, to measure program comprehension. Then, we measured the performance of the subjects regarding correctness and response time for solving the tasks. Our results suggest that there are no differences between disciplined and undisciplined annotations from a program-comprehension perspective. Nevertheless, we observed that finding and correcting errors is a time-consuming and tedious task in the presence of preprocessor annotations.

Forked and integrated variants in an open-source firmware project

Code cloning has been reported both on small (code fragments) and large (entire projects) scale. Cloning-in-the-large, or forking, is gaining ground as a reuse mechanism thanks to availability of better tools for maintaining forked project variants, hereunder distributed version control systems and interactive source management platforms such as Github. We study advantages and disadvantages of forking using the case of Marlin, an open source firmware for 3D printers. We find that many problems and advantages of cloning do translate to forking. Interestingly, the Marlin community uses both forking and integrated variability management (conditional compilation) to create variants and features. Thus, studying it increases our understanding of the choice between integrated and clone-based variant management. It also allows us to observe mechanisms governing source code maturation, in particular when, why and how feature implementations are migrated from forks to the main integrated platform. We believe that this understanding will ultimately help development of tools mixing clone-based and integrated variant management, combining the advantages of both.

Towards a refactoring guideline using code clone classification

Evolution of software often decreases desired properties like readability and maintainability of the evolved code. The process of refactoring aims at increasing the same desired properties by restructuring the code. New paradigms like AOP allow aspect-oriented refactorings as counterparts of object-oriented refactoring with the same aim. However, it is not obvious to the user, when to use which paradigm for achieving certain goals. In this paper we present an approach of code clone classification, which advises the developer when to use a respective refactoring technique or concept.

QuEval: beyond high-dimensional indexing à la carte

In the recent past, the amount of high-dimensional data, such as feature vectors extracted from multimedia data, increased dramatically. A large variety of indexes have been proposed to store and access such data efficiently. However, due to specific requirements of a certain use case, choosing an adequate index structure is a complex and time-consuming task. This may be due to engineering challenges or open research questions. To overcome this limitation, we present QuEval, an open-source framework that can be flexibly extended w.r.t. index structures, distance metrics, and data sets. QuEval provides a unified environment for a sound evaluation of different indexes, for instance, to support tuning of indexes. In an empirical evaluation, we show how to apply our framework, motivate benefits, and demonstrate analysis possibilities.

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.