Christian Kästner

My last name Kästner is pronounced [ˈkɛstnɐ].
It is a quite common German last name, well known for the author and poet Erich Kästner.
The umlaut ä is signficiant for the pronunciation.
The valid ASCII spelling is Kaestner, not Kastner.
To correctly typeset the name in LaTeX use K{\"a}stner.
To create the ä in Windows enter 0228 while pressing the ALT key or simply copy it from this page. [close]

Many applications require not only representing variability in software and
data, but also computing with it. To do so efficiently requires variational
data structures that make the variability explicit in the underlying data and
the operations used to manipulate it. Variational data structures have been
developed ad hoc for many applications, but there is little general
understanding of how to design them or what tradeoffs exist among them.
In this paper, we take a first step towards a more systematic exploration and
analysis of a variational data structure. We want to know how different design
decisions affect the performance and scalability of a variational data
structure, and what properties of the underlying data and operation sequences
need to be considered.
Specifically, we study several alternative designs of a variational stack, a
data structure that supports efficiently representing and computing with
multiple variants of a plain stack, and that is a common building block in many
algorithms. The different variational stacks are presented as a small product
line organized by three design decisions. We analyze how these design decisions
affect the performance of a variational stack with different usage profiles.
Finally, we evaluate how these design decisions affect the performance of the
variational stack in a real-world scenario: in the interpreter VarexJ when
executing real software containing variability.

GNU Autotools is a widely used build tool in the open source
community. As open source projects grow more complex,
maintaining their build systems becomes more challenges,
due to the lack of tool support. Here we propose a platform
to mitigate this problem, and aid developers by providing
a platform to build support tools for GNU Autotools build
systems. The platform would provide an abstract approximation
for the build system to be used in different analysis
techniques.

Quality assurance for highly-configurable systems is challenging due to the exponentially growing configuration space.
Interactions among multiple options can lead to surprising behaviors, bugs, and security vulnerabilities.
Analyzing all configurations systematically might be possible though if most options do
not interact or interactions follow specific patterns that can be exploited by
analysis tools.
To better understand interactions in practice, we analyze program traces to identify where interactions occur on control flow and data.
To this end, we developed a dynamic analysis for Java based on variability-aware execution and monitor executions
of multiple mid-sized real-world programs.
We find that the essential configuration complexity of these programs is indeed much lower than
the combinatorial explosion of the configuration space indicates, but also that
the interaction characteristics that allow scalable and complete analyses are more nuanced than
what is exploited by existing state-of-the-art quality assurance strategies.

There has been a considerable growth in research
and development of service robots in recent years.
For deployment in diverse environment conditions
for a wide range of service tasks, novel features and
algorithms are developed and existing ones undergo
change. However, developing and evolving the robot
software requires making and revising many design
decisions that can affect the quality of performance
of the robots and that are non-trivial to reason about
intuitively because of interactions among them. We
propose to use sensitivity analysis to build models
of the quality of performance to the different design
decisions to ease design and evolution. Moreover,
we envision these models to be used for run-time
adaptation in response to changing goals or environment
conditions. Constructing these models is challenging
due to the exponential size of the decision
space. We build on previous work on performance
influence models of highly-configurable software
systems using a machine-learning-based approach
to construct influence models for robotic software.

Change introduces conflict into software ecosystems: breaking
changes may ripple through the ecosystem and trigger rework
for users of a package, but often developers can invest additional
effort or accept opportunity costs to alleviate or delay
downstream costs. We performed a multiple case study of
three software ecosystems with different tooling and philosophies
toward change, Eclipse, R/CRAN, and Node.js/npm,
to understand how developers make decisions about change
and change-related costs and what practices, tooling, and
policies are used. We found that all three ecosystems differ
substantially in their practices and expectations toward
change and that those differences can be explained largely by
different community values in each ecosystem. Our results
illustrate that there is a large design space in how to build
an ecosystem, its policies and its supporting infrastructure;
and there is value in making community values and accepted
tradeoffs explicit and transparent in order to resolve conflicts
and negotiate change-related costs.

Preprocessors support the diversification of software products
with #ifdefs, but also require additional effort from developers
to maintain and understand variable code. We conjecture
that #ifdefs cause developers to produce more vulnerable
code because they are required to reason about multiple
features simultaneously and maintain complex mental
models of dependencies of configurable code.
We extracted a variational call graph across all configurations
of the Linux kernel, and used configuration complexity
metrics to compare vulnerable and non-vulnerable functions
considering their vulnerability history. Our goal was to learn
about whether we can observe a measurable influence of configuration
complexity on the occurrence of vulnerabilities.
Our results suggest, among others, that vulnerable functions
have higher variability than non-vulnerable ones and
are also constrained by fewer configuration options. This
suggests that developers are inclined to notice functions appear
in frequently-compiled product variants. We aim to
raise developers’ awareness to address variability more systematically,
since configuration complexity is an important,
but often ignored aspect of software product lines.

The Android platform is designed to support mutually untrusted
third-party apps, which run as isolated processes but
may interact via platform-controlled mechanisms, called Intents.
Interactions among third-party apps are intended and
can contribute to a rich user experience, for example, the
ability to share pictures from one app with another. The
Android platform presents an interesting point in a design
space of module systems that is biased toward isolation,
extensibility, and untrusted contributions. The Intent mechanism
essentially provides message channels among modules,
in which the set of message types is extensible. However,
the module system has design limitations including the lack
of consistent mechanisms to document message types, very
limited checking that a message conforms to its specification,
the inability to explicitly declare dependencies on other
modules, and the lack of checks for backward compatibility
as message types evolve over time. In order to understand
the degree to which these design limitations result in real
issues, we studied a broad corpus of apps and cross-validated
our results against app documentation and Android support
forums. Our findings suggest that design limitations do
indeed cause development problems. Based on our results,
we outline further research questions and propose possible
mitigation strategies..

Almost every software system provides configuration options
to tailor the system to the target platform and application
scenario. Often, this configurability renders the analysis of
every individual system configuration infeasible. To address
this problem, researchers proposed a diverse set of sampling
algorithms. We present a comparative study of 10 state-of-the-art
sampling algorithms regarding their fault-detection
capability and size of sample sets. The former is important
to improve software quality and the latter to reduce the
time of analysis. In a nutshell, we found that the sampling
algorithms with larger sample sets detected higher numbers
of faults. Furthermore, we observed that the limiting assumptions
made in previous work influence the number of
detected faults, the size of sample sets, and the ranking of
algorithms. Finally, we identified a number of technical challenges
when trying to avoid the limiting assumptions, which
question the practicality of certain sampling algorithms.

Today’s social coding tools foreshadow a transformation of the software industry, as it increasingly relies on open libraries, frameworks, and code fragments. Our vision calls for new “intelligently transparent” services that support rapid development of innovative products while managing risk and receiving early warnings of looming failures. Intelligent transparency is enabled by an infrastructure that applies analytics to data from all phases of the lifecycle of open source projects, from development to deployment, bringing stakeholders the information they need when they need it.

C. Bogart, C. Kästner, and J. Herbsleb. When it Breaks, it Breaks: How Ecosystem Developers Reason About the Stability of Dependencies. In Proceedings of the ASE Workshop on Software Support for Collaborative and Global Software Engineering (SCGSE), November 2015.
[ .pdf, bib ]

Dependencies among software projects and libraries are an indicator of the
often implicit collaboration among many developers in software ecosystems.
Negotiating change can be tricky: changes to one module may cause ripple
effects to many other modules that depend on it, yet insisting on only backward-compatible
changes may incur significant opportunity cost and stifle
change. We argue that awareness mechanisms based on various notions of stability
can enable developers to make decisions that are independent yet wise and
provide stewardship rather than disruption to the ecosystem. In ongoing
interviews with developers in two software ecosystems (CRAN and Node.js),
we are finding that developers in fact struggle with change, that they
often use adhoc mechanisms to negotiate change, and that existing awareness
mechanisms like Github notification feeds are rarely used due to information
overload. We study the state of the
art and current information needs and outline a vision toward a change-based
awareness system.

W. Ahmad, J. Sunshine, C. Kästner, and A. Wynne. Enforcing Fine-Grained Security and Privacy Policies in an Ecosystem within an Ecosystem. In Proceedings of the 3rd International Workshop on Mobile Development Lifecycle (MobileDeLi), pages 28--34, October 2015.
[ .pdf, doi, bib ]

Smart home automation and IoT promise to bring many advantages
but they also expose their users to certain security
and privacy vulnerabilities. For example, leaking the information
about the absence of a person from home or the
medicine somebody is taking may have serious security and
privacy consequences for home users and potential legal implications
for providers of home automation and IoT platforms.
We envision that a new ecosystem within an existing
smartphone ecosystem will be a suitable platform for distribution
of apps for smart home and IoT devices. Android is
increasingly becoming a popular platform for smart home
and IoT devices and applications. Built-in security mechanisms
in ecosystems such as Android have limitations that
can be exploited by malicious apps to leak users’ sensitive
data to unintended recipients. For instance, Android enforces
that an app requires the Internet permission in order to access
a web server but it does not control which servers the
app talks to or what data it shares with other apps. Therefore,
sub-ecosystems that enforce additional fine-grained custom
policies on top of existing policies of the smartphone ecosystems
are necessary for smart home or IoT platforms. To this
end, we have built a tool that enforces additional policies
on inter-app interactions and permissions of Android apps.
We have done preliminary testing of our tool on three proprietary
apps developed by a future provider of a home automation
platform. Our initial evaluation demonstrates that
it is possible to develop mechanisms that allow definition
and enforcement of custom security policies appropriate for
ecosystems of the like smart home automation and IoT.

In collaborative software development, when two or more developers
incorporate their changes, a merge conflict may arise if the
changes are incompatible. Previous research has shown that such
conflicts are common and occur as textual conflicts or build/test
failure, i.e., semantic conflicts. When a merge conflict occurs for
a large number of parallel changes, it is desirable to identify the
actual (minimum) set of changes that directly results in the conflict.
Pinpointing the specific conflicting changes directly leading to test
failure facilitates quick accountability and correction from developers.
For semantic conflicts, to identify such subset of the changes is
challenging. A naive approach trying all possible subsets would not
scale due to the exponential number of possible combinations.
We propose Semex, a novel approach to detect semantic conflicts
using variability-aware execution. In the first step, we encode all parallel
changes into a single program with variability in which we use
symbolic variables to represent whether a given change is applied to
the original program. In the second step, we run the test cases via
variability-aware execution. Variability-aware execution explores
all possible executions of the combined program with regard to all
possible values of the symbolic variables representing all changes,
and returns a propositional formula over the set of variables repre-
senting the condition in which a test case fails. Due to our encoding
algorithm, such a set corresponds to the minimum set of changes
that are responsible for the conflict. In our preliminary experimental
study on seven PHP applications with a total of 50 test cases and 19
semantic conflicts, Semex correctly detected all 19 conflicts.

Almost every complex software system today is configurable.
While configurability has many benefits, it challenges
performance prediction, optimization, and debugging.
Often, the influences of the individual configurations options on performance
is unknown. Worse, configuration options may interact, giving rise to a
configuration space of possibly exponential size. Addressing this
challenge, we propose an approach that derives a performance-influence model
for a given configurable system, describing all relevant
influences of configuration options and their interactions. Such a model
shall be useful for automatic performance prediction and optimization,
on the one hand, and performance debugging for developers, on the other
hand. Our approach combines
machine-learning and sampling technique in a novel way. Our approach
improves over standard
techniques in that it (1) represents influences of options and their
interactions explicitly (which eases debugging), (2) smoothly integrates
binary and numeric configuration options for the first time, (3) incorporates
domain knowledge, if available (which eases learning and
increases accuracy), (4) considers complex constraints among options, and
(5) systematically reduces the solution space to a tractable size. A
series of experiments demonstrates the feasibility of our approach in
terms of the accuracy of the models learned as well as the accuracy of
the performances predictions one can make with them. Using our approach,
we were able to identify a number of real performance bugs and other
problems in real-world systems.

During software maintenance, program slicing is a useful technique
to assist developers in understanding the impact of their changes.
While different program-slicing techniques have been proposed for
traditional software systems, program slicing for dynamic web applications
is challenging since the client-side code is generated from
the server-side code and data entities are referenced across different languages
and are often embedded in string literals in the server-side
program. To address those challenges, we introduce WebSlice, an
approach to compute program slices across different languages for
web applications. We first identify data-flow dependencies among
data entities for PHP code based on symbolic execution. We also
compute SQL queries and a conditional DOM that represents client-code
variations and construct the data flows for embedded languages:
SQL, HTML, and JavaScript. Next, we connect the data flows across
different languages and those across PHP pages. Finally, we compute
a program slice for any given entity based on the established
data flows. Running WebSlice on five real-world PHP systems,
we found that out of 40,670 program slices, 10 % cross languages,
38 % cross files, and 13 % cross string fragments, demonstrating the
potential benefit of tool support for cross-language program slicing
in web applications.

Highly configurable systems allow users to tailor software to specific needs. Valid combinations of configuration options are
often restricted by intricate constraints. Describing options and constraints in a variability model allows reasoning about the supported
configurations. To automate creating and verifying such models, we need to identify the origin of such constraints. We propose a static
analysis approach, based on two rules, to extract configuration constraints from code. We apply it on four highly configurable systems to
evaluate the accuracy of our approach and to determine which constraints are recoverable from the code. We find that our approach is
highly accurate (93 % and 77 % respectively) and that we can recover 28 % of existing constraints. We complement our approach with a
qualitative study to identify constraint sources, triangulating results from our automatic extraction, manual inspections, and interviews
with 27 developers. We find that, apart from low-level implementation dependencies, configuration constraints enforce correct runtime
behavior, improve users’ configuration experience, and prevent corner cases. While the majority of constraints is extractable from code,
our results indicate that creating a complete model requires further substantial domain knowledge and testing. Our results aim at
supporting researchers and practitioners working on variability model engineering, evolution, and verification techniques.

The C preprocessor has received strong criticism in academia, among others regarding separation of concerns, error proneness, and code obfuscation, but is widely used in practice.
Many (mostly academic) alternatives to the preprocessor exist, but have not been adopted in practice.
Since developers continue to use the preprocessor despite all criticism and research, we ask how practitioners perceive the C preprocessor.
We performed interviews with 40 developers, used grounded theory to analyze the data, and cross-validated the results with data from a survey among 202 developers, repository mining, and results from previous studies.
In particular, we investigated four research questions related to why the preprocessor is still widely used in practice, common problems, alternatives, and the impact of undisciplined annotations.
Our study shows that developers are aware of the criticism the C preprocessor receives, but use it nonetheless, mainly for portability and variability.
They indicate that they regularly face preprocessor-related problems and preprocessor-related bugs.
The majority of our interviewees do not see any current C-native technologies that can entirely replace the C preprocessor.
However, developers tend to mitigate problems with guidelines, but those guidelines are not enforced consistently.
We report the key insights gained from our study and discuss implications for practitioners and researchers on how to better use the C preprocessor to minimize its negative impact.

Build systems contain a lot of configuration
knowledge about a software system, such as under which
conditions specific files are compiled. Extracting such
configuration knowledge is important for many tools analyzing
highly-configurable systems, but very challenging due to the
complex nature of build systems. We design an approach, based
on SYMake, that symbolically evaluates Makefiles and extracts
configuration knowledge in terms of file presence conditions and
conditional parameters. We implement an initial prototype and
demonstrate feasibility on small examples.

In software development, IDE services such as
syntax highlighting, code completion, and “jump to declara-
tion” are used to assist developers in programming tasks. In
dynamic web applications, however, since the client-side code is
dynamically generated from the server-side code and is embedded
in the server-side program as string literals, providing IDE
services for such embedded code is challenging. In this work,
we introduce Varis, a tool that provides editor services on
the client-side code of a PHP-based web application, while it
is still embedded within server-side code. Technically, we first
perform symbolic execution on a PHP program to approximate
all possible variations of the generated client-side code and
subsequently parse this client code into a VarDOM that compactly
represents all its variations. Finally, using the VarDOM, we
implement various types of IDE services for embedded client
code including syntax highlighting, code completion, and “jump
to declaration”.

Almost every sufficiently complex software system today is configurable.
Conditional compilation is a simple variability-implementation mechanism that is widely used in open-source projects and industry.
Especially, the C preprocessor (cpp) is very popular in practice, but it is
also gaining (again) interest in academia.
Although there have been several attempts to understand and improve cpp,
there is a lack of understanding of how it is used in open-source and
industrial systems and whether different usage patterns have emerged.
The background is that much research on configurable systems and product lines
concentrates on open-source systems, simply because they are available for
study in the first place.
This leads to the potentially problematic situation that it is unclear whether
the results obtained from these studies are transferable to industrial systems.
We aim at lowering this gap by comparing the use of cpp in open-source
projects and industry—especially from the embedded-systems domain—, based
on a substantial set of subject systems and well-known variability metrics,
including size, scattering, and tangling metrics.
A key result of our empirical study is that, regarding almost all aspects we
studied, the analyzed open-source systems and the considered embedded systems
from industry have comparable distributions regarding most metrics, including
systems that have been developed in industry and made open source at some point.
So, our study indicates that, regarding cpp as variability-implementation
mechanism, insights, methods, and tools developed based on studies of open-
source systems are transferable to industrial systems—at least, with respect
to the metrics we considered.

Highly-configurable software systems are pervasive, although
configuration options and their interactions raise complexity
of the program and increase maintenance effort. Especially
load-time configuration options, such as parameters from
command-line options or configuration files, are used with
standard programming constructs such as variables and if
statements intermixed with the program’s implementation;
manually tracking configuration options from the time they
are loaded to the point where they may influence control-flow
decisions is tedious and error prone. We design and
implement Lotrack, an extended static taint analysis to
automatically track configuration options. Lotrack derives
a configuration map that explains for each code fragment under
which configurations it may be executed. An evaluation
on Android applications shows that Lotrack yields high
accuracy with reasonable performance. We use Lotrack to
empirically characterize how much of the implementation of
Android apps depends on the platform’s configuration options
or interactions of these options.

When developing and maintaining a software system, programmers often rely on
IDEs to provide editor services such as syntax highlighting, auto-completion,
and “jump to declaration”. In dynamic web applications, such tool support is
currently limited to either the server-side code or to hand-written or
generated client-side code. Our goal is to build a call graph for providing
editor services on client-side code while it is still embedded as
string literals within server-side code. First, we symbolically execute the
server-side code to identify all possible client-side code variations.
Subsequently, we parse the generated client-side code with all its variations
into a VarDOM that compactly represents all DOM variations for further
analysis. Based on VarDOM, we build conditional call graphs for embedded
HTML, CSS, and JS. Our empirical evaluation on real-world web applications
show that our analysis achieves 100 % precision in identifying
call-graph edges. 62 % of the edges cross PHP strings, and 17 % of them cross files—in both situations, navigation
without tool support is tedious and error prone.

Variation is everywhere, but in the construction and analysis of customizable software it is paramount. In this context, there arises a need for variational data structures for efficiently representing and computing with related variants of an underlying data type. So far, variational data structures have been explored and developed ad hoc. This paper is a first attempt and a call to action for systematic and foundational research in this area. Research on variational data structures will benefit not only customizable software, but the many other application domains that must cope with variability. In this paper, we show how support for variation can be understood as a general and orthogonal property of data types, data structures, and algorithms. We begin a systematic exploration of basic variational data structures, exploring the tradeoffs between different implementations. Finally, we retrospectively analyze the design decisions in our own previous work where we have independently encountered problems requiring variational data structures.

We performed an empirical study to explore how closely
well-known, open source C programs follow the safe C standards
for integer behavior, with the goal of understanding
how difficult it is to migrate legacy code to these stricter
standards. We performed an automated analysis on fifty-two
releases of seven C programs (6 million lines of preprocessed
C code), as well as releases of Busybox and Linux (nearly
one billion lines of partially-preprocessed C code). We found
that integer issues, that are allowed by the C standard but
not by the safer C standards, are ubiquitous—one out of four
integers were inconsistently declared, and one out of eight
integers were inconsistently used. Integer issues did not improve
over time as the programs evolved. Also, detecting
the issues is complicated by a large number of integers whose
types vary under different preprocessor configurations. Most
of these issues are benign, but the chance of finding fatal
errors and exploitable vulnerabilities among these many issues
remains significant. A preprocessor-aware, tool-assisted approach
may be the most viable way to migrate legacy C code
to comply with the standards for secure programming.

Software-product-line engineering has gained considerable momentum in recent years, both in industry and
in academia. A software product line is a set of software products that share a common set of features.
Software product lines challenge traditional analysis techniques, such as type checking, model checking,
and theorem proving, in their quest of ensuring correctness and reliability of software. Simply creating and
analyzing all products of a product line is usually not feasible, due to the potentially exponential number
of valid feature combinations. Recently, researchers began to develop analysis techniques that take the
distinguishing properties of software product lines into account, for example, by checking feature-related
code in isolation or by exploiting variability information during analysis. The emerging field of product-line
analyses is both broad and diverse, such that it is difficult for researchers and practitioners to understand
their similarities and differences. We propose a classification of product-line analyses to enable systematic
research and application. Based on our insights with classifying and comparing a corpus of 76 articles, we
infer a research agenda to guide future research on product-line analyses.

Program comprehension is an important cognitive process that inherently eludes direct measurement. Thus, researchers are struggling with providing optimal programming languages, tools, or coding conventions to support developers in their everyday work.
With our approach, we explore whether functional magnetic resonance imaging (fMRI), which is well established in cognitive neuroscience, is feasible to directly measure program comprehension. To this end, we observed 17 participants inside an fMRI scanner while comprehending short source-code snippets, which we contrasted with locating syntax errors.
We found a clear, distinct activation pattern of five brain regions, which are related to working memory, attention, and language processing—all processes that fit well to our understanding of program comprehension. Based on the results, we propose a model of program comprehension.
Our results encourage us to use fMRI in future studies to measure program comprehension and, in the long run, answer questions, such as: Can we predict whether someone will be an excellent programmer? How effective are new languages and tools for program understanding? How do we train someone to become an excellent programmer?

In plugin-based systems, plugin conflicts may occur when two or more
plugins interfere with one another, changing their expected
behaviors.
It is highly challenging to detect plugin conflicts due to the
exponential explosion of the combinations of plugins (i.e.,
configurations). In this paper, we address the challenge of executing
a test case over many configurations. Leveraging the fact that many
executions of a test are similar, our variability-aware execution runs
common code once. Only when encountering values that are different
depending on specific configurations will the execution split to run
for each of them. To evaluate the scalability of variability-aware
execution on a large real-world setting, we built a prototype PHP
interpreter called Varex and ran it on the popular WordPress
blogging Web application. The results show that while plugin
interactions exist, there is a significant amount of sharing that
allows variability-aware execution to scale to 2^50 configurations
within seven minutes of running time. During our study, with Varex, we were
able to detect two plugin conflicts: one was recently reported on
WordPress forum, and another one is not yet discovered.

Highly-configurable systems allow users to tailor the software to
their specific needs. Not all combinations of configuration options
are valid though, and constraints arise for technical or non-technical
reasons. Explicitly describing these constraints in a variability model
allows reasoning about the supported configurations. To automate
creating variability models, we need to identify the origin of such
configuration constraints. We propose an approach which uses build-time
errors and a novel feature-effect heuristic to automatically
extract configuration constraints from C code. We conduct an empirical
study on four highly-configurable open-source systems with
existing variability models having three objectives in mind: evaluate
the accuracy of our approach, determine the recoverability of existing
variability-model constraints using our analysis, and classify the
sources of variability-model constraints. We find that both our extraction
heuristics are highly accurate (93 % and 77 % respectively),
and that we can recover 19 % of the existing variability-models
using our approach. However, we find that many of the remaining
constraints require expert knowledge or more expensive analyses.
We argue that our approach, tooling, and experimental results support
researchers and practitioners working on variability model
re-engineering, evolution, and consistency-checking techniques.

Hidden code dependencies are responsible for many complications in maintenance tasks.
With the introduction of variable features in product lines, dependencies may even cross
feature boundaries and related problems are prone to be detected late. Many current
implementation techniques for product lines lack proper interfaces, which could make
such dependencies explicit. As alternative to changing the implementation approach, we
provide a comprehensive tool-based solution to support developers in recognizing and
dealing with feature dependencies: emergent interfaces. Emergent interfaces are computed
on demand, based on feature-sensitive interprocedural data-flow analysis. They emerge
in the IDE and emulate benefits of modularity not available in the host language. To
evaluate the potential of emergent interfaces, we conducted and replicated a
controlled experiment, and found, in the studied context, that emergent interfaces
can improve performance of code change tasks by up to 3 times while also reducing
the number of errors.

Programming experience is an important confounding parameter in controlled
experiments regarding program comprehension. In literature, ways to measure or
control programming experience vary. Often, researchers neglect it or do not specify
how they controlled for it. We set out to find a well-defined understanding of
programming experience and a way to measure it. From published comprehension
experiments, we extracted questions that assess programming experience. In a
controlled experiment, we compare the answers of computer-science students to these
questions with their performance in solving program-comprehension tasks. We found
that self estimation seems to be a reliable way to measure programming experience.
Furthermore, we applied exploratory and confirmatory factor analyses to extract and
evaluate a model of programming experience. With our analysis, we initiate a path
toward validly and reliably measuring and describing programming experience to better
understand and control its influence in program-comprehension experiments.

The feature-interaction problem has been keeping researchers and practitioners in suspense for years. Although there has been substantial progress in developing approaches for modeling, detecting, managing, and resolving feature interactions, we lack sufficient knowledge on the kind of feature interactions that occur in real-world systems. In this position paper, we set out the goal to explore the nature of feature interactions systematically and comprehensively, classified in terms of order and visibility. Understanding this nature will have significant implications on research in this area, for example, on the efficiency of interaction-detection or performance-prediction techniques. A set of preliminary results as well as a discussion of possible experimental setups and corresponding challenges give us confidence that this endeavor is within reach but requires a collaborative effort of the community.

Software product line engineering is an efficient means to generate a set of tailored software products from a common implementation.
However, adopting a product-line approach poses a major challenge and significant risks, since typically legacy code must be migrated toward a product line. Our aim is to lower the adoption barrier by providing semiautomatic tool support—called variability mining—to support developers in locating, documenting, and extracting implementations of product-line features from legacy code. Variability mining combines prior work on concern location, reverse engineering, and variability-aware type systems, but is tailored specifically for the use in product lines. Our work pursues three technical goals: (1) we provide a consistency indicator based on a variability-aware type system, (2) we mine features at a fine level of granularity, and (3) we exploit domain knowledge about the relationship between features when available. With a quantitative study, we demonstrate that variability mining can efficiently support developers in locating features.

The advent of proper variability management and generator technology enables users to derive individual variants from a variable code base solely based on a selection of desired configuration options.
This approach gives rise to a huge configuration space,
but the high degree of variability comes at a cost: classic analysis methods do not scale any more; there are simply too many potential variants to analyze.
To address this issue, researchers and practitioners usually apply sampling techniques—only a subset of all possible variants is analyzed.
While sampling promises to reduce the analysis effort significantly, the information obtained is necessarily incomplete.
Furthermore, it is unknown whether sampling strategies scale to billions of variants, because even samples may be huge and expensive to compute.
Recently, researchers have begun to develop variability-aware analyses that analyze the variable code base directly with the goal to exploit the similarities among individual variants to reduce analysis effort.
However, while being promising, so far, variability-aware analyses have been applied mostly only to small academic systems.
To learn about the mutual strengths and weaknesses of variability-aware and sampling-based analyses of large-scale, real-world software systems, we compared the two by means of two concrete analysis implementations (type checking and liveness analysis) applied to three subject systems: the Busybox tool suite, the x86 Linux kernel, and the cryptographic library OpenSSL.
A key result is that in these settings already setting up sampling techniques is challenging while variability-aware analysis even outperforms most sampling approximations with respect to analysis time.

While standardization has empowered the software industry to substantially scale software development and to provide affordable software to a broad market, it often does not address smaller market segments, nor the needs and wishes of individual customers. Software product lines reconcile mass production and standardization with mass customization in software engineering. Ideally, based on a set of reusable parts, a software manufacturer can generate a software product based on the requirements of its customer. The concept of features is central to achieving this level of automation, because features bridge the gap between the requirements the customer has and the functionality a product provides. Thus features are a central concept in all phases of product-line development.
The authors take a developer’s viewpoint, focus on the development, maintenance, and implementation of product-line variability, and especially concentrate on automated product derivation based on a user’s feature selection. The book consists of three parts. Part I provides a general introduction to feature-oriented software product lines, describing the product-line approach and introducing the product-line development process with its two elements of domain and application engineering. The pivotal Part II covers a wide variety of implementation techniques including design patterns, frameworks, components, feature-oriented programming, and aspect-oriented programming, as well as tool-based approaches including preprocessors, build systems, version-control systems, and virtual separation of concerns. Finally, Part III is devoted to advanced topics related to feature-oriented product lines like refactoring, feature interaction, and analysis tools specific to product lines. In addition, an Appendix lists various helpful tools for software product-line development, along with a description of how they relate to the topics covered in this book.
To tie the book together, the authors use two running examples that are well documented in the product-line literature: data management for embedded systems, and variations of graph data structures. They start every chapter by explicitly stating the respective learning goals and finish it with a set of exercises; additional teaching material is also available online. All these features make the book ideally suited for teaching – both for academic classes and for professionals interested in self-study.

Formal specification and verification techniques have been used successfully to
detect feature interactions. We investigate whether feature-based specifications
can be used for this task. Feature-based specifications are a special class of
specifications that aim at modularity in open-world, feature-oriented systems. The
question we address is whether modularity of specifications impairs the ability
to detect feature interactions, which cut across feature boundaries. In an
exploratory study on 10 feature-oriented systems, we found that the majority of
feature interactions could be detected based on feature-based specifications, but
some specifications have not been modularized properly and require undesirable
workarounds to modularization. Based on the study, we discuss the merits and
limitations of feature-based specifications, as well as open issues and
perspectives. A goal that underlies our work is to raise awareness of the importance
and challenges of feature-based specification.

Program comprehension plays a crucial role during the software-development life cycle: Maintenance programmers spend most of their time with comprehending source code, and maintenance is the main cost factor in software development.
Thus, if we can improve program comprehension, we can save considerable amount of time and cost. To improve program comprehension, we have to measure it first. However, program comprehension is a complex, internal cognitive process that we cannot
observe directly. Typically, we need to conduct controlled experiments to soundly measure program comprehension. However, empirical research is applied only reluctantly in software engineering. To close this gap, we set out to support researchers in
planning and conducting experiments regarding program comprehension. We report our experience with experiments that we conducted and present the resulting framework to support researchers in planning and conducting experiments. Additionally, we
discuss the role of teaching for the empirical researchers of tomorrow.

The collections API of a programming language
forms an embedded domain-specific language to express queries
and operations on collections. Unfortunately, the ordinary style
of implementing such APIs does not allow automatic domain-specific
analyses and optimizations such as fusion of collection
traversals, usage of indexing, or reordering of filters.
Performance-critical code using collections must instead be
hand-optimized, leading to non-modular, brittle, and redundant code.
We propose SQuOpt, the Scala Query Optimizer—a deep embedding of
the Scala collections API that allows such analyses
and optimizations to be defined and executed within Scala, with-
out relying on external tools or compiler extensions. SQuOpt
provides the same “look and feel” (syntax and static typing guar-
antees) as the standard collections API. We evaluate SQuOpt
by re-implementing several code analyses of the Findbugs tool
using SQuOpt and demonstrate that SQuOpt can reconcile
modularity and efficiency in real-world applications.

Software product-line engineering aims at the development of families of
related products that share common assets. An important aspect is that
customers are often interested not only in particular functionalities (i.e.,
features), but also in non-functional quality attributes such as performance,
reliability, and footprint. A naive approach is to measure quality attributes
of every single product, and to deliver the products that fit the customers'
needs. However, as product lines may consist of millions of products, this
approach does not scale.
In this research-in-progress report, we propose a systematic approach for the
efficient and scalable prediction of quality attributes of products that
consists of two steps. First, we generate predictors for certain categories
of quality attributes (e.g., a predictor for low performance) based on
software and network measures, and receiver operating characteristic analysis.
Second, we use these predictors to guide a sampling process that takes the
asset base of a product line as input and efficiently determines the products
that fall into the category denoted by a given predictor (e.g., products with
low performance). In other words, we use predictors to make the process
of finding “acceptable” products more efficient. We discuss and compare
several strategies to incorporate predictors in the sampling process.

Software product-line engineering aims at the development of families of
related products that share common assets. An important aspect is that
customers are often interested not only in particular functionalities (i.e.,
features), but also in non-functional quality attributes such as performance,
reliability, and footprint. A naive approach is to measure quality attributes
of every single product, and to deliver the products that fit the customers'
needs. However, as product lines may consist of millions of products, this
approach does not scale.
In this research-in-progress report, we propose a systematic approach for the
efficient and scalable prediction of quality attributes of products that
consists of two steps. First, we generate predictors for certain categories
of quality attributes (e.g., a predictor for low performance) based on
software and network measures, and receiver operating characteristic analysis.
Second, we use these predictors to guide a sampling process that takes the
asset base of a product line as input and efficiently determines the products
that fall into the category denoted by a given predictor (e.g., products with
low performance). In other words, we use predictors to make the process
of finding “acceptable” products more efficient. We discuss and compare
several strategies to incorporate predictors in the sampling process.

Product-line analysis has received considerable attention in the past. As it is often infeasible to analyze each product of a product line individually, researchers have developed analyses, called variability-aware analyses, that consider and exploit variability manifested in a code base. Variability-aware analyses are often significantly more efficient than traditional analyses, but each of them has certain weaknesses regarding applicability or scalability, as we discuss in this paper. We present the Product-Line-Analysis Model, a formal model for the classification and comparison of existing analyses, including traditional and variability-aware analyses, and lay a foundation for formulating and exploring further, combined analyses. As a proof of concept, we discuss different examples of analyses in the light of our model, and demonstrate its benefits for systematic comparison and exploration of product-line analyses.

Program comprehension is an often evaluated, internal cognitive process.
In neuroscience, functional magnetic resonance (fMRI) imaging is used to
visualize such internal cognitive processes. We propose an experimental design
to measure program comprehension based on fMRI. In the long run, we hope to
answer questions like What distinguishes good programmers from bad programmers?
or What makes a good programmer?

We investigate how to execute a unit test in all configurations of a product line without generating each product in isolation in a brute-force fashion. Learning from variability-aware analyses, we (a) design and implement a variability-aware interpreter and (b) reencode variability of the product line to simulate the test cases with a model checker. The interpreter internally reasons about variability, executing paths not affected by variability only once for the whole product line. The model checker achieves similar results by reusing powerful off-the-shelf analyses. We experimented with a prototype implementation for each strategy. We compare both strategies and discuss trade-offs and future directions.

It is common believe that separating source code along concerns
or features improves program comprehension of source
code. However, empirical evidence is mostly missing. In this
paper, we design a controlled experiment to evaluate that
believe for feature-oriented programming based on maintenance
tasks with human participants. We validate our
experiment with a pilot study, which already preliminarily
confirms that students use different strategies to complete
maintenance tasks.

The theory of context-free languages is well-understood and context-free parsers can be used as off-the-shelf tools in practice. In particular, to use a context-free parser framework, a user does not need to understand its internals but can specify a language declaratively as a grammar. However, many languages in practice are not context-free. One particularly important class of such languages is layout-sensitive languages, in which the structure of code depends on indentation and whitespace. For example, Python, Haskell, F\#, and Markdown use indentation instead of curly braces to determine the block structure of code. Their parsers (and lexers) are not declaratively specified but hand-tuned to account for layout-sensitivity.
To support declarative specifications of layout-sensitive languages, we propose a parsing framework in which a user can annotate layout in a grammar as constraints on the relative positioning of tokens in the parsed subtrees. For example, a user can declare that a block consists of statements that all start on the same column. We have integrated layout constraints into SDF and implemented a layout-sensitive generalized parser as an extension of generalized LR parsing. We evaluate the correctness and performance of our parser by parsing 33290 open-source Haskell files. Layout-sensitive generalized parsing is easy to use, and its performance overhead compared to layout-insensitive parsing is small enough for most practical applications.

Context: A software product line is a family of related software products,
typically created from a set of common assets. Users select features to derive
a product that fulfills their needs. Users often expect a product to have
specific non-functional properties, such as a small footprint or a bounded
response time. Because a product line may have an exponential number of
products with respect to its features, it is usually not feasible to generate
and measure non-functional properties for each possible product.
Objective: Our overall goal is to derive optimal products with respect to
non-functional requirements by showing customers which features must be
selected.
Method: We propose an approach to predict a product’s non-functional
properties based on the product’s feature selection. We aggregate the influence
of each selected feature on a non-functional property to predict a
product’s properties. We generate and measure a small set of products and,
by comparing measurements, we approximate each feature’s influence on
the non-functional property in question. As a research method, we conducted
controlled experiments and evaluated prediction accuracy for the
non-functional properties footprint and main-memory consumption. But,
in principle, our approach is applicable for all quantifiable non-functional
properties.
Results: With nine software product lines, we demonstrate that our approach
predicts the footprint with an average accuracy of 94\,\%, and an accuracy
of over 99\,\% on average if feature interactions are known. In a further
series of experiments, we predicted main memory consumption of six customizable
programs and achieved an accuracy of 89\,\% on average.
Conclusion: Our experiments suggest that, with only few measurements,
it is possible to accurately predict non-functional properties of products of
a product line. Furthermore, we show how already little domain knowledge
can improve predictions and discuss trade-offs between accuracy and required
number of measurements. With this technique, we provide a basis for many
reasoning and product-derivation approaches.

Feature-oriented software development is a paradigm for the
construction, customization, and synthesis of large-scale and variable
software systems, focusing on structure, reuse and variation. In this
tutorial, we provide a gentle introduction to software product lines, feature
oriented programming, virtual separation of concerns, and variability-
aware analysis. We provide an overview, show connections between the
different lines of research, and highlight possible future research directions.

FeatureIDE is an open-source framework for feature-oriented software development (FOSD) based on Eclipse. FOSD is a paradigm for the construction, customization, and synthesis of software systems. Code artifacts are mapped to features, and a customized software system can be generated given a selection of features. The set of software systems that can be generated is called a software product line (SPL). FeatureIDE supports several FOSD implementation techniques such as feature-oriented programming, aspect-oriented programming, delta-oriented programming, and preprocessors. All phases of FOSD are supported in FeatureIDE, namely domain analysis, requirements analysis, domain implementation, and software generation.

Module systems enable a divide and conquer strategy to software development.
To implement compile-time variability in software product lines, modules
can be composed in different combinations. However, this way variability
dictates a dominant decomposition. Instead, we introduce a variability-aware
module system that supports compile-time variability inside a module and its
interface. This way, each module can be considered a product line that can
be type checked in isolation. Variability can crosscut multiple modules. The
module system breaks with the antimodular tradition of a global variability
model in product-line development and provides a path toward software
ecosystems and product lines of product lines developed in an open fashion.
We discuss the design and implementation of such a module system on a core
calculus and provide an implementation for C, which we use to type check
the open source product line Busybox with 811 compile-time options.

Module systems enable a divide and conquer strategy to software development.
To implement compile-time variability in software product lines, modules
can be composed in different combinations. However, this way variability
dictates a dominant decomposition. Instead, we introduce a variability-aware
module system that supports compile-time variability inside a module and its
interface. This way, each module can be considered a product line that can
be type checked in isolation. Variability can crosscut multiple modules. The
module system breaks with the antimodular tradition of a global variability
model in product-line development and provides a path toward software
ecosystems and product lines of product lines developed in an open fashion.
We discuss the design and implementation of such a module system on a core
calculus and provide an implementation for C, which we use to type check
the open source product line Busybox with 811 compile-time options.

Software-product-line engineering has gained considerable momentum in recent years, both in
industry and in academia. A software product line is a set of software products that share a
common set of features. Software product lines challenge traditional analysis techniques, such as
type checking, testing, and formal verification, in their quest of ensuring correctness and reliability
of software. Simply creating and analyzing all products of a product line is usually not feasible,
due to the potentially exponential number of valid feature combinations. Recently, researchers
began to develop analysis techniques that take the distinguishing properties of software product
lines into account, for example, by checking feature-related code in isolation or by exploiting
variability information during analysis. The emerging field of product-line analysis techniques is
both broad and diverse such that it is difficult for researchers and practitioners to understand
their similarities and differences (e.g., with regard to variability awareness or scalability), which
hinders systematic research and application. We classify the corpus of existing and ongoing work
in this field, we compare techniques based on our classification, and we infer a research agenda.
A short-term benefit of our endeavor is that our classification can guide research in product-line
analysis and, to this end, make it more systematic and efficient. A long-term goal is to empower
developers to choose the right analysis technique for their needs out of a pool of techniques with
different strengths and weaknesses.

Software-product-line engineering aims at the development of variable
and reusable software systems. In practice, software product lines are
often implemented with preprocessors. Preprocessor directives are easy to use,
and many mature tools are available for practitioners. However, preprocessor
directives have been heavily criticized in academia and even referred to
as “#ifdef hell”, because they introduce threats to program comprehension
and correctness. There are many voices that suggest to use other implementation
techniques instead, but these voices ignore the fact that a transition
from preprocessors to other languages and tools is tedious, erroneous, and expensive
in practice. Instead, we and others propose to increase the readability
of preprocessor directives by using background colors to highlight source code
annotated with ifdef directives. In three controlled experiments with over 70
subjects in total, we evaluate whether and how background colors improve
program comprehension in preprocessor-based implementations. Our results
demonstrate that background colors have the potential to improve program
comprehension, independently of size and programming language of the underlying
product. Additionally, we found that subjects generally favor background
colors. We integrate these and other findings in a tool called FeatureCommander,
which facilitates program comprehension in practice and which can serve
as a basis for further research.

Background: Software product line engineering provides an effective mechanism to implement variable software.
However, the usage of preprocessors to realize variability, which is typical in industry, is heavily criticized, because
it often leads to obfuscated code. Using background colours to highlight preprocessor statements to support
comprehensibility has shown effective, however, scalability to large software product lines (SPLs) is questionable.
Aim: Our goal is to implement and evaluate scalable usage of background colours for industrial-sized SPLs. Method:
We designed and implemented scalable concepts in a tool called FeatureCommander. To evaluate its effectiveness, we
conducted a controlled experiment with a large real-world SPL with over 99,000 lines of code and 340 features. We
used a within-subjects design with treatments colours and no colours. We compared correctness and response time of
tasks for both treatments. Results: For certain kinds of tasks, background colours improve program comprehension.
Furthermore, subjects generally favour background colours compared to no background colours. Additionally, subjects
who worked with background colours had to use the search functions less frequently. Conclusion: We show that
background colours can improve program comprehension in large SPLs. Based on these encouraging results, we will
continue our work on improving program comprehension in large SPLs.

Programming experience is an important confounding
parameter in controlled experiments regarding program
comprehension. In literature, ways to measure or control programming
experience vary. Often, researchers neglect it or do
not specify how they controlled it. We set out to find a well-defined
understanding of programming experience and a way to measure
it. From published comprehension experiments, we extracted
questions that assess programming experience. In a controlled experiment,
we compare the answers of 128 students to these questions
with their performance in solving program-comprehension
tasks. We found that self estimation seems to be a reliable way
to measure programming experience. Furthermore, we applied
exploratory factor analysis to extract a model of programming
experience. With our analysis, we initiate a path toward measuring
programming experience with a valid and reliable tool,
so that we can control its influence on program comprehension.

Customizable programs and program families
provide user-selectable features to tailor a program to an
application scenario. Knowing in advance which feature selection
yields the best performance is difficult because a
direct measurement of all possible feature combinations is
infeasible. Our work aims at predicting program performance
based on selected features. The challenge is predicting performance
accurately when features interact. An interaction
occurs when a feature combination has an unexpected influence
on performance. We present a method that automatically
detects performance feature interactions to improve prediction
accuracy. To this end, we propose three heuristics to reduce the
number of measurements required to detect interactions. Our
evaluation consists of six real-world case studies from varying
domains (e.g. databases, compression libraries, and web server)
using different configuration techniques (e.g., configuration files
and preprocessor flags). Results show, on average, a prediction
accuracy of 95 %.

Superimposition is a composition technique that has been applied successfully in many areas of software development. Although superimposition is a general-purpose concept, it has been (re)invented and implemented individually for various kinds of software artifacts. We unify languages and tools that rely on superimposition by using the language-independent model of feature structure trees (FSTs). On the basis of the FST model, we propose a general approach to the composition of software artifacts written in different languages. Furthermore, we offer a supporting framework and tool chain, called FeatureHouse. We use attribute grammars to automate the integration of additional languages. In particular, we have integrated Java, C#, C, Haskell, Alloy, and JavaCC. A substantial number of case studies demonstrate the practicality and scalability of our approach and reveal insights into the properties that a language must have in order to be ready for superimposition. We discuss perspectives of our approach and demonstrate how we extended FeatureHouse with support for XML languages (in particular, XHTML, XMI/UML, and Ant) and alternative composition approaches (in particular, aspect weaving). Rounding off our previous work, we provide here a holistic view of the FeatureHouse approach based on rich experience with numerous languages and case studies and reflections on several years of research.

Software is changed frequently during its life cycle. New requirements come and bugs must be fixed.
To update an application it usually must be stopped, patched, and restarted. This causes time periods of
unavailability which is always a problem for highly available applications. Even for the development of
complex applications restarts to test new program parts can be time consuming and annoying. Thus, we
aim at dynamic software updates to update programs at runtime. There is a large body of research on
dynamic software updates, but so far, existing approaches have shortcomings either in terms of flexibility or
performance. In addition, some of them depend on specific runtime environments and dictate the program’s
architecture. We present JavAdaptor, the first runtime update approach based on Java that (a) offers
flexible dynamic software updates, (b) is platform independent, (c) introduces only minimal performance
overhead, and (d) does not dictate the program architecture. JavAdaptor combines schema changing class
replacements by class renaming and caller updates with Java HotSwap using containers and proxies. It runs
on top of all major standard Java virtual machines. We evaluate our approach’s applicability and performance
in non-trivial case studies and compare it to existing dynamic software update approaches.

Software product line engineering is an efficient means to generate a set of tailored software products from a common implementation.
However, adopting a product-line approach poses a major challenge and significant risks, since typically legacy code must be migrated toward a product line. Our aim is to lower the adoption barrier by providing semiautomatic tool support—called variability mining—to support developers in locating, documenting, and extracting implementations of product-line features from legacy code. Variability mining combines prior work on concern location, reverse engineering, and variability-aware type systems, but is tailored specifically for the use in product lines. Our work extends prior work in three important aspects: (1) we provide a consistency indicator based on a variability-aware type system, (2) we mine features at a fine level of granularity, and (3) we exploit domain knowledge about the relationship between features when available. With a quantitative study, we demonstrate that variability mining can efficiently support developers in locating features.

Large software projects consist of code written in a multitude of different
(possibly domain-specific) languages, which are often deeply interspersed even
in single files. While many proposals exist on how to integrate languages
semantically and syntactically, the question of how to support this scenario in
integrated development environments (IDEs) remains open: How can standard IDE
services, such as syntax highlighting, outlining, or reference resolving, be
provided in an extensible and compositional way, such that an open mix of
languages is supported in a single file?
Based on our library-based syntactic extension language for Java, SugarJ, we
propose to make IDEs extensible by organizing editor services in editor
libraries. Editor libraries are libraries written in the object language,
SugarJ, and hence activated and composed through regular import statements on a
file-by-file basis. We have implemented an IDE for editor libraries on top of
SugarJ and the Eclipse-based Spoofax language workbench. We have validated
editor libraries by evolving this IDE into a fully-fledged and schema-aware XML
editor as well as an extensible Latex editor, which we used for writing this
paper.

Modularity of feature representations has been a long standing
goal of feature-oriented software development. While
some researchers regard feature modules and corresponding
composition mechanisms as a modular solution, other researchers
have challenged the notion of feature modularity
and pointed out that most feature-oriented implementation
mechanisms lack proper interfaces and support neither modular
type checking nor separate compilation. We step back
and reflect on the feature-modularity discussion. We distinguish
two notions of modularity, cohesion without interfaces
and information hiding with interfaces, and point out the
different expectations that, we believe, are the root of many
heated discussions. We discuss whether feature interfaces
should be desired and weigh their potential benefits and
costs, specifically regarding crosscutting, granularity, feature
interactions, and the distinction between closed-world and
open-world reasoning. Because existing evidence for and
against feature modularity and feature interfaces is shaky
and inconclusive, more research is needed, for which we
outline possible directions.

In many projects, lexical preprocessors are used to manage
different variants of the project (using conditional compilation)
and to define compile-time code transformations (using
macros). Unfortunately, while being a simply way to implement
variability, conditional compilation and lexical macros
hinder automatic analysis, even though such analysis would
be urgently needed to combat variability-induced complexity.
To analyze code with its variability, we need to parse
it without preprocessing it. However, current parsing solutions
use heuristics, support only a subset of the language, or
suffer from exponential explosion. As part of the TypeChef
project, we contribute a novel variability-aware parser that
can parse unpreprocessed code without heuristics in practicable
time. Beyond the obvious task of detecting syntax errors,
our parser paves the road for further analysis, such as
variability-aware type checking. We implement variabilityaware
parsers for Java and GNU C and demonstrate practicability
by parsing the product line MobileMedia and the
entire X86 architecture of the Linux kernel with 6065 variable
features.

Existing approaches to extend a programming language with
syntactic sugar often leave a bitter taste, because they cannot
be used with the same ease as the main extension mechanism
of the programming language—libraries. Sugar libraries are
a novel approach for syntactically extending a programming
language within the language. A sugar library is like an ordinary
library, but can, in addition, export syntactic sugar
for using the library. Sugar libraries maintain the composability
and scoping properties of ordinary libraries and are
hence particularly well-suited for embedding a multitude of
domain-specific languages into a host language. They also
inherit the self-applicability of libraries, which means that
the syntax extension mechanism can be applied in the definition
of sugar libraries themselves.
To demonstrate the expressiveness and applicability of
sugar libraries, we have developed SugarJ, a language on
top of Java, SDF and Stratego that supports syntactic extensibility.
SugarJ employs a novel incremental parsing mechanism
that allows changing the syntax within a source file. We
demonstrate SugarJ by five language extensions, including
embeddings of XML and closures in Java, all available as
sugar libraries. We illustrate the utility of self-applicability
by embedding XML Schema, a metalanguage to define
XML languages.

An ongoing problem in revision control systems is how to resolve
conflicts in a merge of independently developed revisions. Unstructured
revision control systems are purely text-based and solve
conflicts based on textual similarity. Structured revision control
systems are tailored to specific languages and use language-specific
knowledge for conflict resolution. We propose semistructured revision
control systems that inherit the strengths of both classes of
systems: generality and expressiveness. The idea is to provide structural
information of the underlying software artifacts—declaratively,
in the form of annotated grammars. This way, a wide variety of languages
can be supported and the information provided can assist the
automatic resolution of two classes of conflicts: ordering conflicts
and semantic conflicts. The former can be resolved independently
of the language and the latter can be resolved using specific conflict
handlers supplied by the user. We have been developing a tool that
supports semistructured merge and conducted an empirical study on
24 software projects developed in Java, C#, and Python comprising
180 merge scenarios. We found that semistructured merge reduces
the number of conflicts in 60 % of the sample merge scenarios by,
on average, 34 %. Our study reveals that renaming is challenging
in that it can significantly increase the number of conflicts during
semistructured merge, which we discuss.

A software product line (SPL) is a family of related programs of a domain.
The programs of an SPL are distinguished in terms of features, which are end-uservisible
characteristics of programs. Based on a selection of features, stakeholders can
derive tailor-made programs that satisfy functional requirements. Besides functional requirements,
different application scenarios raise the need for optimizing non-functional
properties of a variant. The diversity of application scenarios leads to heterogeneous
optimization goals with respect to non-functional properties (e.g., performance vs.
footprint vs. energy optimized variants). Hence, an SPL has to satisfy different and
sometimes contradicting requirements regarding non-functional properties. Usually, the
actually required non-functional properties are not known before product derivation
and can vary for each application scenario and customer. Allowing stakeholders to derive
optimized variants requires to measure non-functional properties after the SPL is
developed. Unfortunately, the high variability provided by SPLs complicates measurement
and optimization of non-functional properties due to a large variant space.
With SPL Conqueror, we provide a holistic approach to optimize non-functional
properties in SPL engineering. We show how non-functional properties can be qualitatively
specified and quantitatively measured in the context of SPLs. Furthermore, we
discuss the variant-derivation process in SPL Conqueror that reduces the effort of computing
an optimal variant. We demonstrate the applicability of our approach by means
of nine case studies of a broad range of application domains (e.g., database management
and operating systems). Moreover, we show that SPL Conqueror is implementation and
language independent by using SPLs that are implemented with different mechanisms,
such as conditional compilation and feature-oriented programming.

Software measures are often used to assess program comprehension, although their applicability is discussed controversially. Often, their application is based on plausibility arguments, which however is not sufficient to decide whether and how software measures are good predictors for program comprehension. Our goal is to evaluate whether and how software measures and program comprehension correlate. To this end, we carefully designed an experiment. We used four different measures that are often used to judge the quality of source code: complexity, lines of code, concern attributes, and concern operations. We measured how subjects understood two comparable software systems that differ in their implementation, such that one implementation promised considerable benefits in terms of better software measures. We did not observe a difference in program comprehension of our subjects as the software measures suggested it. To explore how software measures and program comprehension could correlate, we used several variants of computing the software measures. This brought them closer to our observed result, however, not as close as to confirm a relationship between software measures and program comprehension. Having failed to establish a relationship, we present our findings as an open issue to the community and initiate a discussion on the role of software measures as comprehensibility predictors.

A software product line is a set of program variants, typically generated from a common code base. Feature models describe variability in product lines by documenting features and their valid combinations. In product-line engineering, we need to reason about variability and program variants for many different tasks. For example, given a feature model, we might want to determine the number of all valid feature combinations or detect specific feature combinations for testing.
However, we found that contemporary reasoning approaches can only reason about feature combinations, not about program variants, because they do not take abstract features into account. Abstract features are features used to structure a feature model that, however, do not have any impact at implementation level. Using existing feature-model reasoning mechanisms for product variants leads to incorrect results.
We raise awareness of the problem of abstract features for different kinds of analyses on feature models. We argue that, in order to reason about program variants, abstract features should be made explicit in feature models. We present a technique based on propositional formulas to reason about program variants. In practice, our technique can save effort that is caused by considering the same program variant multiple times, for example, in product-line testing.

A software product line (SPL) is a family of related software products, from which users can derive a product that fulfills their needs.
Often, users expect a product to have specific non-functional properties, for example, to not exceed a footprint limit or to respond in a given time frame. Unfortunately, it is usually not feasible to generate and measure non-functional properties for each possible product of an SPL in isolation, because an SPL can contain millions of products. Hence, we propose an approach to estimate each product's non-functional properties in advance, based on the product's configuration. To this end, we approximate non-functional properties per features and per feature interaction. We generate and measure a small set of products and approximated non-functional properties by comparing the measurements. Our approach is implementation independent and language independent. We present three different approaches with different trade-offs regarding accuracy and required number of measurements. With nine case studies, we demonstrate that our approach can predict non-functional properties with an accuracy of 2\%.

What is modularity? Which kind of modularity should developers strive for?
Despite decades of research on modularity, these basic questions have
no definite answer. We submit that the common understanding of
modularity, and in particular its notion of information hiding, is
deeply rooted in classical logic.
We analyze how classical modularity, based on classical logic, fails to
address the needs of developers of large software systems, and
encourage researchers to explore alternative visions of
modularity, based on nonclassical logics, and henceforth called
nonclassical
modularity.

Background: Software product line engineering provides
an effective mechanism to implement variable software.
However, the usage of preprocessors, which is typical in industry,
is heavily criticized, because it often leads to obfuscated code.
Using background colors to support comprehensibility has shown
effective, however, scalability to large software product lines
(SPLs) is questionable.
Aim: Our goal is to implement and evaluate scalable usage of
background colors for industrial-sized SPLs.
Method: We designed and implemented scalable concepts
in a tool called FeatureCommander. To evaluate its effectiveness,
we conducted a controlled experiment with a large real-world
SPL with over 160,000 lines of code and 340 features. We
used a within-subjects design with treatments colors and no
colors. We compared correctness and response time of tasks for
both treatments.
Results: For certain kinds of tasks, background
colors improve program comprehension. Furthermore, subjects
generally favor background colors. Conclusion: We show that
background colors can improve program comprehension in large
SPLs. Based on these encouraging results, we will continue our
work improving program comprehension in large SPLs.

Software-product-line engineering is an efficient means to generate a family of program variants for a domain
from a single code base. However, because of the potentially high number of possible program variants, it is
difficult to test them all and ensure properties like type safety for the entire product line. We present a
product-line–aware type system that can type check an entire software product line without generating each variant in
isolation. Specifically, we extend the Featherweight Java calculus with feature annotations for product-line development
and prove formally that all program variants generated from a well-typed product line are well-typed.
Furthermore, we present a solution to the problem of typing mutually exclusive features. We discuss how results
from our formalization helped implementing our own product-line tool CIDE for full Java and report of
experience with detecting type errors in four existing software-product-line implementations.

The C preprocessor cpp is a widely used tool for implementing
variable software. It enables programmers to express
variable code of features that may crosscut the entire implementation
with conditional compilation. The C preprocessor
relies on simple text processing and is independent of the host
language (C, C++, Java, and so on). Language independent
text processing is powerful and expressive|programmers can
make all kinds of annotations in the form of #ifdefs but
can render unpreprocessed code difficult to process automatically
by tools, such as code aspect refactoring, concern
management, and also static analysis and variability-aware
type checking. We distinguish between disciplined annotations,
which align with the underlying source-code structure,
and undisciplined annotations, which do not align with the
structure and hence complicate tool development. This distinction
raises the question of how frequently programmers
use undisciplined annotations and whether it is feasible to
change them to disciplined annotations to simplify tool development
and to enable programmers to use a wide variety of
tools in the first place. By means of an analysis of 40 mediumsized
to large-sized C programs, we show empirically that
programmers use cpp mostly in a disciplined way: about 85 %
of all annotations respect the underlying source-code structure.
Furthermore, we analyze the remaining undisciplined
annotations, identify patterns, and discuss how to transform
them into a disciplined form.

The C preprocessor is commonly used to implement
variability. Given a feature selection, code fragments
can be excluded from compilation with #ifdef and similar
directives. However, the token-based nature of the C preprocessor
makes variability implementation difficult and errorprone.
Additionally, variability mechanisms are intertwined
with macro definitions, macro expansion, and file inclusion.
To determine whether a code fragment is compiled, the entire
file must be preprocessed. We present a partial preprocessor
that preprocesses file inclusion and macro expansion, but
retains variability information for further analysis. We describe
the mechanisms of the partial preprocessor, provide a full
implementation, and present some initial experimental results.
The partial preprocessor is part of a larger endeavor in
the TypeChef project to check variability implementations
(syntactic correctness, type correctness) in C projects such as
the Linux kernel.

Software product lines have gained momentum as an approach to
generate many variants of a program, each tailored to a specific
use case, from a common code base. However, the implementation
of product lines raises new challenges, as potentially millions of
program variants are developed in parallel. In prior work, we and
others have developed product-line–aware type systems to detect
type errors in a product line, without generating all variants. With
TypeChef, we build a similar type checker for product lines written
in C that implements variability with #ifdef directives of the
C preprocessor. However, a product-line–aware type system for C
is more difficult than expected due to several peculiarities of the
preprocessor, including lexical macros and unrestricted use of #ifdef
directives. In this paper, we describe the problems faced and our
progress to solve them with TypeChef. Although TypeChef is still
under development and cannot yet process arbitrary C code, we
demonstrate its capabilities so far with a case study: By type checking
the open-source web server Boa with potentially 2^110 variants,
we found type errors in several variants.

Feature-Oriented Software Development (FOSD) is a paradigm
for the development of software product lines. A challenge
in FOSD is to guarantee that all software systems of
a software product line are correct. Recent work on type
checking product lines can provide a guarantee of type correctness
without generating all possible systems. We generalize
previous results by abstracting from the specifics of
particular programming languages. In a first attempt, we
present a reference-checking algorithm that performs key
tasks of product-line type checking independently of the target
programming language. Experiments with two sample
product lines written in Java and C are encouraging and
give us confidence that this approach is promising.

In feature-oriented programming (FOP) a programmer decomposes a program in
terms of features. Ideally, features are implemented modularly so that they can be
developed in isolation. Access control is an important ingredient to attain feature
modularity as it provides mechanisms to hide and expose internal details of a module's
implementation. But developers of contemporary feature-oriented languages
have not considered access control mechanisms so far. The absence of a well-defined
access control model for FOP breaks encapsulation of feature code and leads to unexpected
program behaviors and inadvertent type errors. We raise awareness of this
problem, propose three feature-oriented access modifiers, and present a corresponding
access modifier model. We offer an implementation of the model on the basis of
a fully-fledged feature-oriented compiler. Finally, by analyzing ten feature-oriented
programs, we explore the potential of feature-oriented modifiers in FOP.

Feature-oriented software development (FOSD) aims
at the construction, customization, and synthesis of large-scale
software systems. We propose a novel software design paradigm,
called feature-oriented design, which takes the distinguishing
properties of FOSD into account, especially the clean and consistent
mapping between features and their implementations as well
as the tendency of features to interact inadvertently. We extend
the lightweight modeling language Alloy with support for feature-oriented
design and call the extension FeatureAlloy. By means of
an implementation and four case studies, we demonstrate how
feature-oriented design with FeatureAlloy facilitates separation
of concerns, variability, and reuse of models of individual features
and helps in defining and detecting semantic dependences and
interactions between features.

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-specific) 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
amount of clones in feature-oriented software product lines and
that a large fraction of these clones is FOP-specific (i.e., caused by
limitations of feature-oriented mechanisms). Based on our results,
we initiate a discussion on the reasons for FOP-specific clones and
on how to cope with them. We exemplary show how such clones
can be removed by the application of refactoring.

Conditional compilation with preprocessors such as cpp is a simple but effective means to implement variability.
By annotating code fragments with #ifdef and #endif directives, different program variants with or without these annotated fragments can be created, which can be used (among others) to implement software product lines. Although, such annotation-based approaches are frequently used in practice, researchers often criticize them for their negative effect on code quality and maintainability. In contrast to modularized implementations such as components or aspects, annotation-based implementations typically neglect separation of concerns, can entirely obfuscate the source code, and are prone to introduce subtle errors.
Our goal is to rehabilitate annotation-based approaches by showing how tool support can address these problems. With views, we emulate modularity; with a visual representation of annotations, we reduce source code obfuscation and increase program comprehension; and with disciplined annotations and a product-line–aware type system, we prevent or detect syntax and type errors in the entire software product line. At the same time we emphasize unique benefits of annotations, including simplicity, expressiveness, and being language independent. All in all, we provide tool-based separation of concerns without necessarily dividing source code into physically separated modules; we name this approach virtual separation of concerns.
We argue that with these improvements over contemporary preprocessors, virtual separation of concerns can compete with modularized implementation mechanisms.
Despite our focus on annotation-based approaches, we do intend not give a definite answer on how to implement software product lines. Modular implementations and annotation-based implementations both have their advantages; we even present an integration and migration path between them.
Our goal is to rehabilitate preprocessors and show that they are not a lost cause as many researchers think. On the contrary, we argue that – with the presented improvements – annotation-based approaches are a serious alternative for product-line implementation.

The C preprocessor is often used in practice to
implement variability in software product lines. Using #ifdef
statements provokes problems such as obfuscated source code,
yet they will still be used in practice at least in the medium-term
future. With CIDE, we demonstrate a tool to improve understanding
and maintaining code that contains #ifdef statements
by visualizing them with colors and providing different views on
the code.

Feature-Oriented Software Development (FOSD) provides a multitude of formalisms, methods,
languages, and tools for building variable, customizable, and extensible software. Along
different lines of research, different notions of a feature have been developed. Although these
notions have similar goals, no common basis for evaluation, comparison, and integration
exists. We present a feature algebra that captures the key ideas of feature orientation and
provides a common ground for current and future research in this field, in which also alternative
options can be explored. Furthermore, our algebraic framework is meant to serve as a
basis for the upcoming development paradigms automatic feature-based program synthesis
and architectural metaprogramming.

A feature-oriented product line is a family of programs that share a common set
of features. A feature implements a stakeholder's requirement and represents a design decision
or configuration option. When added to a program, a feature involves the introduction
of new structures, such as classes and methods, and the refinement of existing ones, such
as extending methods. A feature-oriented decomposition enables a generator to create an
executable program by composing feature code solely on the basis of the feature selection
of a user – no other information needed. A key challenge of product line engineering is to
guarantee that only well-typed programs are generated. As the number of valid feature combinations
grows combinatorially with the number of features, it is not feasible to type check
all programs individually. The only feasible approach is to have a type system check the
entire code base of the feature-oriented product line. We have developed such a type system
on the basis of a formal model of a feature-oriented Java-like language. The type system
guaranties type safety for feature-oriented product lines. That is, it ensures that every valid
program of a well-typed product line is well-typed. Our formal model including type system
is sound and complete.

Over 30 years ago, the preprocessor cpp was developed to
extend the programming language C by lightweight metaprogramming
capabilities. Despite its error-proneness and low
abstraction level, the cpp is still widely being used in presentday
software projects to implement variable software. However,
not much is known about how the cpp is employed
to implement variability. To address this issue, we have
analyzed forty open-source software projects written in C.
Specifically, we answer the following questions: How does program
size influence variability? How complex are extensions
made via cpp's variability mechanisms? At which level of
granularity are extensions applied? What is the general type
of extensions? These questions revive earlier discussions on
understanding and refactoring of the preprocessor. To answer
them, we introduce several metrics measuring the variability,
complexity, granularity, and type of extensions. Based on
the data obtained, we suggest alternative implementation
techniques. The data we have collected can influence other
research areas, such as language design and tool support.

Revision control systems are a major means to
manage versions and variants of today's software systems. An
ongoing problem in these systems is how to resolve conflicts
when merging independently developed revisions. Unstructured
revision control systems are purely text-based and solve conflicts
based on textual similarity. Structured revision control systems
are tailored to specific languages and use language-specific
knowledge for conflict resolution. We propose semistructured
revision control systems to inherit the strengths of both classes
of systems: generality and expressiveness. The idea is to provide
structural information of the underlying software artifacts in the
form of annotated grammars, which is motivated by recent work
on software product lines. This way, a wide variety of languages
can be supported and the information provided can assist the
resolution of conflicts. We have implemented a preliminary
tool and report on our experience with merging Java artifacts.
We believe that drawing a connection between revision control
systems and product lines has benefits for both fields.

There are many different implementation approaches to realize the
vision of feature oriented software development, ranging from simple
preprocessors, over feature-oriented programming, to sophisticated
aspect-oriented mechanisms. Their impact on readability and
maintainability (or program comprehension in general) has caused
a debate among researchers, but sound empirical results are missing.
We report experience from our endeavor to conduct experiments
to measure the influence of different implementation mechanisms
on program comprehension. We describe how to design such
experiments and report from possibilities and pitfalls we encountered.
Finally, we present some early results of our first experiment
on comparing CPP with CIDE.

In feature-oriented programming (FOP), a programmer decomposes
a program in terms of features. Ideally, features
are implemented modularly so that they can be developed in
isolation. Access control is an important ingredient to attain
feature modularity as it provides mechanisms to hide and
expose internal details of a module's implementation. But
developers of contemporary feature-oriented languages did
not consider access control mechanisms so far. The absence
of a well-defined access control model for FOP breaks the
encapsulation of feature code and leads to unexpected and
undefined program behaviors as well as inadvertent type errors,
as we will demonstrate. The reason for these problems
is that common object-oriented modifiers, typically provided
by the base language, are not expressive enough for FOP and
interact in subtle ways with feature-oriented language mechanisms.
We raise awareness of this problem, propose three
feature-oriented modifiers for access control, and present an
orthogonal access modifier model.

Conditional compilation with preprocessors like cpp is a simple but effective means to
implement variability. By annotating code fragments with #ifdef and #endif directives,
different program variants with or without these fragments can be created, which
can be used (among others) to implement software product lines. Although, preprocessors
are frequently used in practice, they are often criticized for their negative effect
on code quality and maintainability. In contrast to modularized implementations, for
example using components or aspects, preprocessors neglect separation of concerns,
are prone to introduce subtle errors, can entirely obfuscate the source code, and limit
reuse. Our aim is to rehabilitate the preprocessor by showing how simple tool support
can address these problems and emulate some benefits of modularized implementations.
At the same time we emphasize unique benefits of preprocessors, like simplicity
and language independence. Although we do not have a definitive answer on how to
implement variability, we want highlight opportunities to improve preprocessors and
encourage research toward novel preprocessor-based approaches.

Physical separation with class refinements and method refinements
à la AHEAD and virtual separation using annotations à la #ifdef
or CIDE are two competing groups of implementation approaches for
software product lines with complementary advantages. Although both
groups have been mainly discussed in isolation, we strive for an
integration to leverage the respective advantages. In this paper,
we provide the basis for such an integration by providing a model
that supports both, physical and virtual separation, and by describing
refactorings in both directions. We prove the refactorings complete,
such that every virtually separated product line can be automatically
transformed into a physically separated one (replacing annotations by refinements)
and vice versa. To demonstrate the feasibility of our approach, we have
implemented the refactorings in our tool CIDE and conducted four case studies.

Programs can be composed from features. We want to verify automatically
that all legal combinations of features can be composed
safely without errors. Prior work on this problem assumed that features
add code monotonically. We generalize prior work to enable
features to both add and remove code, describe our analyses and
implementation, and review case studies. We observe that more
expressive features can increase the complexity of developed programs
rapidly – up to the point where automated concepts as presented
in this paper are not a helpful tool but a necessity for verification.

Feature-oriented software development (FOSD) is a paradigm for the construction,
customization, and synthesis of large-scale software systems. In this survey, we give
an overview and a personal perspective on the roots of FOSD, connections to other
software development paradigms, and recent developments in this field. Our aim is to
point to connections between different lines of research and to identify open issues.

A software product-line is a family of related programs that are distinguished
in terms of features. A feature implements a stakeholders' requirement.
Different program variants specified by distinct feature selections are produced from
a common code base. The optional feature problem describes a common mismatch between
variability intended in the domain and dependencies in the implementation. When this
occurs, some variants that are valid in the domain cannot be produced due to implementation
issues. There are many different solutions to the optional feature problem, but
they all suffer from drawbacks such as reduced variability, increased development effort,
reduced efficiency, or reduced source code quality. In this paper, we examine the impact
of the optional feature problem in two case studies in the domain of embedded database
systems, and we survey different state-of-the-art solutions and their trade-offs.
Our intension is to raise awareness of the problem, to guide developers in selecting
an appropriate solution for their product-line project, and to identify opportunities
for future research.

Through implicit invocation, procedures are called without explicitly referencing them. Implicit announcement
adds to this implicitness by not only keeping implicit which procedures are called, but also where or when –
under implicit invocation with implicit announcement, the call site contains no signs of that, or what it calls.
Recently, aspect-oriented programming has popularized implicit invocation with implicit announcement as a
possibility to separate concerns that lead to interwoven code if conventional programming techniques are used.
However, as has been noted elsewhere, as currently implemented it establishes strong implicit dependencies
between components, hampering independent software development and evolution. To address this problem, we
present a type-based modularization of implicit invocation with implicit announcement that is inspired by how
interfaces and exceptions are realized in JAVA. By extending an existing compiler and by rewriting several
programs to make use of our proposed language constructs, we found that the imposed declaration clutter tends
to be moderate; in particular, we found that for general applications of implicit invocation with implicit announcement,
fears that programs utilizing our form of modularization become unreasonably verbose are unjustified.

In software product line engineering, feature composition generates
software tailored to specific requirements from a common set of artifacts. Superimposition
is a popular technique to merge code pieces belonging to different
features. The advent of model-driven development raises the question of how to
support the variability of software product lines in modeling techniques. We propose
to use superimposition as a model composition technique in order to support
variability. We analyze the feasibility of superimposition as a model composition
technique, offer a corresponding tool for model composition, and discuss our experiences
with three case studies (including one industrial study) using this tool.

The separation of concerns is a fundamental principle in software engineering.
Crosscutting concerns are concerns that do not align with hierarchical
and block decomposition supported by mainstream programming languages. In
the past, crosscutting concerns have been studied mainly in the context of object
orientation. Feature orientation is a novel programming paradigm that supports
the (de)composition of crosscutting concerns in a system with a hierarchical
block structure. By means of two case studies we explore the problem of crosscutting
concerns in functional programming and propose two solutions based on
feature orientation.

Based on a general model of feature composition, we present a composition
language that enables programmers by means of quantification and weaving
to formulate extensions to programs written in different languages. We explore
the design space of composition languages that rely on quantification and weaving
and discuss our choices. We outline a tool that extends an existing infrastructure
for feature composition and discuss results of three initial case studies.

A software product line (SPL) is a family of related program variants in
a well-defined domain, generated from a set of features. A fundamental difference
from classical application development is that engineers develop not a single
program but a whole family with hundreds to millions of variants. This makes
it infeasible to separately check every distinct variant for errors. Still engineers
want guarantees on the entire SPL. A further challenge is that an SPL may contain
artifacts in different languages (code, documentation, models, etc.) that should be
checked. In this paper, we present CIDE, an SPL development tool that guarantees
syntactic correctness for all variants of an SPL. We show how CIDE's underlying
mechanism abstracts from textual representation and we generalize it to arbitrary
languages. Furthermore, we automate the generation of safe plug-ins for additional
languages from annotated grammars. To demonstrate the language-independent
capabilities, we applied CIDE to a series of case studies with artifacts written in
Java, C++, C, Haskell, ANTLR, HTML, and XML.

Tools support is crucial for the acceptance of a new programming
language. However, providing such tool support
is a huge investment that can usually not be provided
for a research language. With FeatureIDE, we have built
an IDE for AHEAD that integrates all phases of featureoriented
software development. To reuse this investment for
other tools and languages, we refactored FeatureIDE into
an open source framework that encapsulates the common
ideas of feature-oriented software development and that can
be reused and extended beyond AHEAD. Among others, we
implemented extensions for FeatureC++ and FeatureHouse,
but in general, FeatureIDE is open for everybody to showcase
new research results and make them usable to a wide
audience of students, researchers, and practitioners.

The size of the structured query language (SQL) continuously increases.
Extensions of SQL for special domains like stream processing or sensor networks come
with own extensions, more or less unrelated to the standard. In general, underlying
DBMS support only a subset of SQL plus vendor specific extensions. In this paper,
we analyze application domains where special SQL dialects are needed or are already
in use. We show how SQL can be decomposed to create an extensible family of SQL
dialects. Concrete dialects, e.g., a dialect for web databases, can be generated from
such a family by choosing SQL features à la carte. A family of SQL dialects simplifies
analysis of the standard when deriving a concrete dialect, makes it easy to understand
parts of the standard, and eases extension for new application domains. It is also the
starting point for developing tailor-made data management solutions that support only
a subset of SQL. We outline how such customizable DBMS can be developed and what
benefits, e.g., improved maintainability and performance, we can expect from this.

Database schemas are used to describe the logical design of a database.
Diverse groups of users have different perspectives on the schema which leads to
different local schemas. Research has focused on view integration to generate a global,
consistent schema out of different local schemas or views. However, this approach
seems to be too constrained when the generated global view should be variable and
only a certain subset is needed. Variable schemas are needed in software product lines
in which products are tailored to the needs of stakeholders. We claim that traditional
modeling techniques are not sufficient for expressing a variable database schema. We
show that software product line methodologies, when applied to the database schemas,
overcome existing limitations and allow the generation of tailor-made database schemas.

Features express the variabilities and commonalities
among programs in a software product line (SPL). A feature
model defines the valid combinations of features, where each
combination corresponds to a program in an SPL. SPLs
and their feature models evolve over time. We classify the
evolution of a feature model via modifications as refactorings,
specializations, generalizations, or arbitrary edits. We
present an algorithm to reason about feature model edits
to help designers determine how the program membership
of an SPL has changed. Our algorithm takes two feature
models as input (before and after edit versions), where the
set of features in both models are not necessarily the same,
and it automatically computes the change classification. Our
algorithm is able to give examples of added or deleted products
and efficiently classifies edits to even large models that
have thousands of features.

Superimposition is a composition technique that has
been applied successfully in many areas of software development.
Although superimposition is a general-purpose
concept, it has been (re)invented and implemented individually
for various kinds of software artifacts. We unify
languages and tools that rely on superimposition by using
the language-independent model of feature structure trees
(FSTs). On the basis of the FST model, we propose a general
approach to the composition of software artifacts written
in different languages, Furthermore, we offer a supporting
framework and tool chain, called FEATUREHOUSE. We
use attribute grammars to automate the integration of additional
languages, in particular, we have integrated Java,
C#, C, Haskell, JavaCC, and XML. Several case studies
demonstrate the practicality and scalability of our approach
and reveal insights into the properties a language must have
in order to be ready for superimposition.

C. Kästner, and S. Apel. Integrating Compositional and Annotative Approaches for Product Line Engineering. In Proceedings of the GPCE Workshop on Modularization, Composition and Generative Techniques for Product Line Engineering (McGPLE), pages 35--40, Passau, Germany: Department of Informatics and Mathematics, University of Passau, October 2008.
[ .pdf, bib ]

Software product lines can be implemented with many different approaches. However, there are common underlying mechanisms which allow a classification into compositional and annotative approaches. While research focuses mainly on composition approaches like aspect- or feature-oriented programming because those support feature traceability and modularity, in practice annotative approaches like preprocessors are common as they are easier to adopt. In this paper, we compare both groups of approaches and find complementary strengths. We propose an integration of compositional and annotative approaches to combine advantages, increase flexibility for the developer, and ease adoption.

Software product line development is a mature technique to implement
similar programs tailored to serve the needs of multiple
users while providing a high degree of reuse. This approach also
scales for larger product lines that use smaller product lines to fulfill
special tasks. In such compositions of SPLs, the interacting product
lines depend on each other and programs generated from these
product lines have to be correctly configured to ensure correct communication
between them. Constraints between product lines can
be used to allow only valid combinations of generated programs.
This, however, is not sufficient if multiple instances of one product
line are involved. In this paper we present an approach that uses
UML and OO concepts to model compositions of SPLs. The model
extends the approach of constraints between SPLs to constraints between
instances of SPLs and integrates SPL specialization. Based
on this model we apply a feature-oriented approach to simplify the
configuration of complete SPL compositions.

Software product lines (SPLs) enable stakeholders to derive
different software products for a domain while providing
a high degree of reuse of their code units. Software
products are derived in a configuration process by combining
different code units. This configuration process becomes
complex if SPLs contain hundreds of features. In
many cases, a stakeholder is not only interested in functional
but also in resulting non-functional properties of a
desired product. Because SPLs can be used in different application
scenarios alternative implementations of already
existing functionality are developed to meet special nonfunctional
requirements, like restricted binary size and performance
guarantees. To enable these complex configurations
we discuss and present techniques to measure nonfunctional
properties of software modules and use these values
to compute SPL configurations optimized to the users
needs.

Modifying an application usually means to stop the application,
apply the changes, and start the application
again. That means, the application is not available for at
least a short time period. This is not acceptable for highly
available applications. One reasonable approach which
faces the problem of unavailability is to change highly
available applications at runtime. To allow extensive runtime
adaptation the application must be enabled for unanticipated
changes even of already executed program parts.
This is due to the fact that it is not predictable what changes
become necessary and when they have to be applied. Since
Java is commonly used for developing highly available applications,
we discuss its shortcomings and opportunities
regarding unanticipated runtime adaptation. We present
an approach based on Java HotSwap and object wrapping
which overcomes the identified shortcomings and evaluate
it in a case study.

Implementing software product lines is a challenging task.
Depending on the implementation technique the code that realizes
a feature is often scattered across multiple code units.
This way it becomes difficult to trace features in source code which
hinders maintenance and evolution. While previous effort on visualization
technologies in software product lines has focused mainly on the feature model,
we suggest tool support for feature traceability in the code base.
With our tool CIDE, we propose an approach based on filters and views on source code
in order to visualize and trace features in source code.

Feature-oriented programming (FOP) is a paradigm that incorporates programming
language technology, program generation techniques, and stepwise refinement.
In their GPCE'07 paper, Thaker et al. suggest the development of a type system
for FOP to guarantee safe feature composition, i.e, to guarantee the absence of
type errors during feature composition.
We present such a type system along with a calculus for a simple feature-oriented,
Java-like language, called Feature Featherweight Java (FFJ). Furthermore,
we explore four extensions of FFJ and how they affect type soundness.

A functional aspect is an aspect that has the semantics of a transformation;
it is a function that maps a program to an advised program.
Functional aspects are composed by function composition. In
this paper, we explore functional aspects in the context of aspect-oriented
refactoring. We show that refactoring legacy applications
using functional aspects is just as flexible as traditional aspects in
that (a) the order in which aspects are refactored does not matter,
and (b) the number of potential aspect interactions is decreased.
We analyze several aspect-oriented programs of different sizes to
support our claims.

Feature modules are the building blocks of programs in software
product lines (SPLs). A foundational assumption of feature-based
program synthesis is that features are composed in a predefined
order. Recent work on virtual separation of concerns reveals a new
model of feature interactions that shows that feature modules can be
quantized as compositions of smaller modules called derivatives.
We present this model and examine some of its unintuitive consequences,
namely, that (1) a given program can be reconstructed by
composing features in any order, and (2) the contents of a feature
module (as expressed as a composition of derivatives) is determined
automatically by a feature order. We show that different
orders allow one to “adjust” the contents of a feature module to isolate
and study the impact of interactions that a feature has with
other features. Using derivatives, we show the utility of generalizing
safe composition (SC), a basic analysis of SPLs that verifies
program type-safety, to prove that every legal composition of derivatives
(and thus any composition order of features) produces a typesafe
program, which is a much stronger SC property.

A software product line (SPL) is an efficient means
to generate a family of program variants for a domain from
a single code base. However, because of the potentially high
number of possible program variants, it is difficult to test all
variants and ensure properties like type-safety for the entire SPL.
While first steps to type-check an entire SPL have been taken,
they are informal and incomplete. In this paper, we extend the
Featherweight Java (FJ) calculus with feature annotations to be
used for SPLs. By extending FJ's type system, we guarantee that
– given a well-typed SPL – all possible program variants are welltyped
as well. We show how results from this formalization reflect
and help implementing our own language-independent SPL tool
CIDE.

Feature-Oriented Software Development (FOSD) provides a multitude
of formalisms, methods, languages, and tools for building variable, customizable,
and extensible software. Along different lines of research, different notions of
a feature have been developed. Although these notions have similar goals, no
common basis for evaluation, comparison, and integration exists. We present a
feature algebra that captures the key ideas of feature orientation and provides
a common ground for current and future research in this field, in which also
alternative options can be explored.

S. Apel, C. Kästner, and C. Lengauer. Research Challenges in the Tension Between Features and Services. In Proceedings of the ICSE Workshop on Systems Development in SOA Environments (SDSOA), pages 53--58, New York, NY: ACM Press, May 2008.
[ doi, .pdf, bib ]

We present a feature-based approach, known from software
product lines, to the development of service-oriented architectures.
We discuss five benefits of such an approach: improvements
in modularity, variability, uniformity, specifiability,
and typeability. Subsequently, we review preliminary
experiences and results, and propose an agenda for further
research in this direction.

Building software product lines (SPLs) with features is a challenging
task. Many SPL implementations support features with coarse
granularity - e.g., the ability to add and wrap entire methods. However,
fine-grained extensions, like adding a statement in the middle
of a method, either require intricate workarounds or obfuscate the
base code with annotations. Though many SPLs can and have been
implemented with the coarse granularity of existing approaches,
fine-grained extensions are essential when extracting features from
legacy applications. Furthermore, also some existing SPLs could
benefit from fine-grained extensions to reduce code replication or
improve readability. In this paper, we analyze the effects of feature
granularity in SPLs and present a tool, called Colored IDE (CIDE),
that allows features to implement coarse-grained and fine-grained
extensions in a concise way. In two case studies, we show how CIDE
simplifies SPL development compared to traditional approaches.

Software product lines (SPL) allow to generate tailormade
software by manually configuring reusable core assets.
However, SPLs with hundreds of features and millions
of possible products require an appropriate support
for semi-automated product derivation. This derivation has
to be based on non-functional properties that are related to
core assets and domain features. Both elements are part
of different models connected via complex mappings. We
propose a model that integrates features and core assets in
order to allow semi-automated product derivation.

Aspect-Oriented Programming (AOP) aims at modularizing crosscutting
concerns. AspectJ is a popular AOP language extension for
Java that includes numerous sophisticated mechanisms for implementing
crosscutting concerns modularly in one aspect. The language
allows to express complex extensions, but at the same time
the complexity of some of those mechanisms hamper the writing
of simple and recurring extensions, as they are often needed especially
in software product lines. In this paper we propose an AspectJ
extension that introduces a simplified syntax for simple and
recurring extensions. We show that our syntax proposal improves
evolvability and modularity in AspectJ programs by avoiding those
mechanisms that may harm evolution and modularity if misused.
We show that the syntax is applicable for up to 74\% of all pointcut
and advice mechanisms by analysing three AspectJ case studies.

Aspect-oriented programming (AOP) is a novel programming paradigm
that aims at modularizing complex software. It embraces
several mechanisms including (1) pointcuts and advice as well as
(2) refinements and collaborations. Though all these mechanisms
deal with crosscutting concerns, i.e., a special class of design and
implementation problems that challenge traditional programming
paradigms, they do so in different ways. In this article we explore
their relationship and their impact on software modularity. This
helps researchers and practitioners to understand their differences
and guides to use the right mechanism for the right problem.

Software product line is a paradigm to develop a family
of software products with the goal of reuse. In this paper, we
focus on a scenario in which different products from different
product lines are combined together in a third product
line to yield more elaborate products, i.e., a product line
consumes products from third product line suppliers. The
issue is not how different products can be produced separately,
but how they can be combined together. We propose
a service-oriented architecture where product lines are regarded
as services, yielding a service-oriented product line.
This paper illustrates the approach with an example for a
service-oriented architecture of a web portal product line
supplied by portlet product lines.

Creating a software product line from a legacy application
is a difficult task. We propose a tool that helps automating
tedious tasks of refactoring legacy applications
into features and frees the developer from the burden of
performing laborious routine implementations.

Taking an extractive approach to decompose a legacy application
into features is difficult and laborious with current
approaches and tools. We present a prototype of a tooldriven
approach that largely hides the complexity of the task.

Software product lines aim to create highly configurable
programs from a set of features. Common belief and recent
studies suggest that aspects are well-suited for implementing
features. We evaluate the suitability of AspectJ with respect
to this task by a case study that refactors the embedded
database system Berkeley DB into 38 features. Contrary to
our initial expectations, the results were not encouraging.
As the number of aspects in a feature grows, there is a noticeable
decrease in code readability and maintainability.
Most of the unique and powerful features of AspectJ were
not needed. We document where AspectJ is unsuitable for
implementing features of refactored legacy applications and
explain why.

Stepwise refinement (SWR) is fundamental to software engineering. As aspectoriented
programming (AOP) is gaining momentum in software development, aspects
should be considered in the light of SWR. In this paper, we elaborate the notion of
aspect refinement that unifies AOP and SWR at the architectural level. To reflect this
unification to the programming language level, we present an implementation technique
for refining aspects based on mixin composition along with a set of language
mechanisms for refining all kinds of structural elements of aspects in a uniform way
(methods, pointcuts, advice). To underpin our proposal, we contribute a fully functional
compiler on top of AspectJ, present a non-trivial, medium-sized case study, and
derive a set of programming guidelines.

Collaborations are a frequently occurring class of crosscutting
concerns. Prior work has argued that collaborations
are better implemented using Collaboration Languages
(CLs) rather than AspectJ-like Languages (ALs).
The main argument is that aspects flatten the objectoriented
structure of a collaboration, and introduce more
complexity rather than benefits – in other words, CLs and
ALs differ with regard to program comprehension. To explore
the effects of CL and AL modularization mechanisms
on program comprehension, we propose to conduct a series
of experiments. We present ideas on how to arrange such
experiments that should serve as a starting point and foster
a discussion with other researchers.

The integration of aspects into the methodology of stepwise software
development and evolution is still an open issue. This paper
focuses on the global quantification mechanism of nowadays
aspect-oriented languages that contradicts basic principles of this
methodology. One potential solution to this problem is to bound the
potentially global effects of aspects to a set of local development
steps. We discuss several alternatives to implement such bounded
aspect quantification in AspectJ. Afterwards, we describe a concrete
approach that relies on meta-data and pointcut restructuring
in order to control the quantification of aspects. Finally, we discuss
open issues and further work.

Copyright Notice: This material is presented to ensure timely
dissemination of scholarly and technical work. Copyright and all rights
therein are retained by authors or by other copyright holders. All
persons copying this information are expected to adhere to the terms
and constraints invoked by each author's copyright. In most cases,
these works may not be reposted without the explicit permission of the
copyright holder.

Thomas Thüm.
A Machine-Checked Proof for a Product-Line-Aware Type System.
Master's Thesis (Diplomarbeit), University of Magdeburg, Germany, January 2010.
Best-thesis award of the Denert Foundation for Software Engineering. Results published as part of a journal paper in ACM Transactions on Software Engineering and Methodology (TOSEM), 2011
[ bib| .pdf]

Janet Feigenspan.
Empirical Comparison of FOSD Approaches Regarding Program Comprehension – A Feasibility Study.
Master's Thesis (Diplomarbeit), University of Magdeburg, Germany, August 2009.
Best-thesis award by Metop Research Center and Research Award by IHK Magdeburg. The results were published as part of a journal paper in Empirical Software Engineering, 2012.
[ bib| .pdf]