abstract

Context: Software metrics, as one form of static analyses, is a commonly used approach in software engineering in order to understand the state of a software system, in particular to identify potential areas prone to defects. Family-based techniques extract variability information from code artifacts in Software Product Lines (SPLs) to perform static analysis for all available variants. Many different types of metrics with numerous variants have been defined in literature. When counting all metrics including such variants, easily thousands of metrics can be defined. Computing all of them for large product lines can be an extremely expensive process in terms of performance and resource consumption.

Objective: We address these performance and resource challenges while supporting customizable metric suites, which allow running both, single system and variability-aware code metrics.

Method: In this paper, we introduce a partial parsing approach used for the efficient measurement of more than 42,000 code metric variations. The approach covers variability information and restricts parsing to the relevant parts of the Abstract Syntax Tree (AST).

Conclusions: This partial parsing approach is designed to cover all relevant information to compute a broad variety of variability-aware code metrics on code artifacts containing annotation-based variability, e.g., realized with C-preprocessor statements. It allows for the flexible combination of single system and variability-aware metrics, which is not supported by existing tools. This is achieved by a novel representation of partially parsed product line code artifacts, which is tailored to the computation of the metrics. Our approach consumes considerably less resources, especially when computing many metric variants in parallel.

abstract

This tutorial introduces the EASy-Producer product line environment. EASy-Producer is an open-source toolset for engineering product lines, variability-rich software ecosystems, and dynamic software product lines. In particular, it features a variability modeling and a variability implementation DSL. It has been applied in several industrial case studies and research projects showing its practical applicability both from a stability and a capability point of view. While the tool-set also includes an interactive approach to product line definition and configuration through DSLs, the focus of this tutorial will be on the DSL-based techniques. We cover both the modeling of software product lines using the Integrated Variability Modeling Language (IVML) and its underlying conceptual approach, which differs from traditional feature modeling, but we will also provide an overview of the approach to variability instantiation with EASy-Producer (using the Variability Instantiation Language (VIL)).

abstract

EASy-Producer is an open-source research toolset for engineering product lines, variability-rich software ecosystems, and dynamic software product lines. In this tutorial, we will introduce its (textual) variability modeling capabilities realized by the Integrated Variability Modeling Language (IVML) and its model-based development and implementation capabilities, which are realized by the Variability Instantiation Language (VIL) and the Variability Template Language (VTL).

abstract

This summary refers to the paper Metrics for analyzing variability and its implementation in software product lines: A systematic literature review. It was online first in 2018 and was finally published 2019 in the Information and Software Technology (IST) journal.

The use of metrics for assessing software products and their qualities is well established in traditional Software Engineering (SE). However, such traditional metrics are typically not applicable to Software Product Line (SPL) engineering as they do not address variability management, a key part of product line engineering. Over time, various specialized product line metrics for SPLs have been described in literature, but no systematic description of these metrics and their characteristics is currently available.

This paper presents a systematic literature review, where we identify metrics explicitly designed for variability models, code artifacts, and metrics taking both kinds of artifacts into account. This captures the core of variability management for product lines. We discovered 42 relevant papers reporting 147 metrics designed for SPLs.We provide a categorization of these metrics and discuss problematic issues regarding their definitions. We also systematically assess the evaluation status of the metrics showing a current lack of high-quality evaluation in the field. Researchers and practitioners can benefit from the published catalog of variability-aware metrics

abstract

This summary refers to the paper Metrics for analyzing variability and its implementation in software product lines: A systematic literature review [EYS19]. The paper was online first in 2018 and was finally published 2019 in the Information and Software Technology (IST) journal.

abstract

Variability-aware metrics are designed to measure qualitative aspects of software product lines. As we identified in a prior SLR [6], there exist already many metrics that address code or variability separately, while the combination of both has been less researched. MetricHaven fills this gap, as it extensively supports combining information from code files and variability models. Further,we also enable the combination of well established single system metrics with novel variability-aware metrics, going beyond existing variabilityaware metrics. Our tool supports most prominent single system and variability-aware code metrics. We provide configuration support for already implemented metrics, resulting in 23,342 metric variations. Further, we present an abstract syntax tree developed for MetricHaven, that allows the realization of additional code metrics.

abstract

Experimentation with software prototypes plays a fundamental role in software engineering research. In contrast to many other scientific disciplines, however, explicit support for this key activity in software engineering is relatively small. While some approaches to improve this situation have been proposed by the software engineering community, experiments are still very difficult and sometimes impossible to replicate.In this paper, we propose the concept of an experimentation workbench as a means of explicit support for experimentation in software engineering research.

In particular, we discuss core requirements that an experimentation workbench should satisfy in order to qualify as such and to offer a real benefit for researchers. Beyond their core benefits for experimentation, we stipulate that experimentation workbenches will also have benefits in regard to reproducibility and repeatability of software engineering research. Further, we illustrate this concept with a scenario and a case study, and describe relevant challenges as well as our experience with experimentation workbenches.

abstract

Context: Software Product Line (SPL) development requires at least concepts for variability implementation and variability modeling for deriving products from a product line. These variability implementation concepts are not required for the development of single systems and, thus, are not considered in traditional software engineering. Metrics are well established in traditional software engineering, but existing metrics are typically not applicable to SPLs as they do not address variability management. Over time, various specialized product line metrics have been described in literature, but no systematic description of these metrics and their characteristics is currently available.

Objective: This paper describes and analyzes variability-aware metrics, designed for the needs of software product lines. More precisely we restrict the scope of our study explicitly to metrics designed for variability models, code artifacts, and metrics taking both kinds of artifacts into account. Further, we categorize the purpose for which these metrics were developed. We also  analyze to what extent these metrics were evaluated to provide a basis for researchers for selecting adequate metrics. Method: We conducted a systematic literature review to identify variability-aware implementation metrics. We discovered 42 relevant papers reporting metrics intended to measure aspects of variability models or code artifacts. Results: We identified 57 variability model metrics, 34 annotation-based code metrics, 46 code metrics specific to composition-based implementation techniques, and 10 metrics integrating information from variability model and code artifacts. For only 31 metrics, an evaluation was performed assessing their suitability to draw any qualitative conclusions.

Conclusions: We observed several problematic issues regarding the definition and the use of the metrics. Researchers and practitioners benefit from the catalog of variability-aware metrics, which is the first of its kind. Also, the research community benefits from the identified observations in order to avoid those problems when defining new metrics.

abstract

Transforming a clone-and-own (i.e., new product variants are created by copying and modifying existing artifacts) code structure and development process to a Software Product Line Engineering (PLE) approach is a tedious and error-prone task. Holistic tool support for such a process is highly desirable, especially to lower efforts and to speed up the transformation. Unfortunately, such a holistic toolchain for reverse engineering of variability, supporting variant-centric and platform-centric extraction approaches is not available. In this paper, we present a toolchain covering the first steps for moving a clone-and-own product development to a PLE approach. We validate the first prototype of the toolchain on a case study consisting of industrial firmware for smart motor controllers and we show that even this early prototype reduces time and effort for moving to a configurable platform approach in the sense of PLE.

abstract
Systematic exploration of hypotheses is a major part of any empirical research. In software engineering, we often produce unique tools for experiments and evaluate them independently on different data sets. In this paper, we present KernelHaven as an experimentation workbench supporting a significant number of experiments in the domain of static product line analysis and verification. It addresses the need for extracting information from a variety of artifacts in this domain by means of an open plug-in infrastructure. Available plug-ins encapsulate existing tools, which can now be combined efficiently to yield new analyses. As an experimentation workbench, it provides configuration-based definitions of experiments, their documentation, and technical services, like parallelization and caching. Hence, researchers can abstract from technical details and focus on the algorithmic core of their research problem. KernelHaven supports different types of analyses, like correctness checks, metrics, etc., in its specific domain. The concepts presented in this paper can also be transferred to support researchers of other software engineering domains. The infrastructure is available under Apache 2.0: github.com/KernelHaven. The plug-ins are available under their individual licenses. Video: youtu.be/IbNc-H1NoZU

abstract
Development of Software Product Lines (SPLs) requires additional implementation concepts to manage variability and to facilitate the derivation of individual products based on a common platform. These variability implementation concepts are not required for the development of single systems and, thus, are not considered in traditional software engineering. Metrics are well established in traditional software engineering, but are typically not applicable to SPLs as they do not address variability management. Over time, a number of specialized product line metrics have been described in literature. However, no systematic description of the characteristics of these metrics is currently available. We conducted a systematic literature review to identify variability-aware implementation metrics, designed for the needs of SPLs. We list these metrics according to the measured artifact types: variability models, code artifacts, and combined metrics measuring both artifact types. Further, we analyze to what extent these metrics were evaluated as a basis for qualitative conclusions.

abstract

A number of SAT-based analysis concepts and tools for software product lines exist, that extract code dependencies in propositional logic from the source code assets of the product line. On these extracted conditions, SAT-solvers are used to reason about the variability. However, in practice, a lot of software product lines use integer-based variability. The variability variables hold integer values, and integer operators are used in the conditions. Most existing analysis tools can not handle this kind of variability; they expect pure Boolean conditions.

This paper introduces an approach to convert integer-based variability conditions to propositional logic. Running this approach as a preparation on an integer-based product line allows the existing SAT-based analyses to work without any modiications. The pure Boolean formulas, that our approach builds as a replacement for the integer-based conditions, are mostly equivalent to the original conditions with respect to satisfiability. Our approach was motivated by and implemented in the context of a real-world industrial case-study, where such a preparation was necessary to analyze the variability.

Our contribution is an approach to convert conditions, that use integer variables, into propositional formulas, to enable easy usage of SAT-solvers on the result. It works well on restricted variables (i.e. variables with a small range of allowed values); unrestricted integer variables are handled less exact, but still retain useful variability information.

abstract

KernelHaven is an open infrastructure for Software Product Line (SPL) analysis. It is intended both as a production-quality analysis tool set as well as a research support tool. Its design follows the principle of an experimentation workbench [13] to support researchers in systematically exploring research hypothesis. For flexibility and ease of experimentation KernelHaven components are plug-ins for extracting certain information from SPL artifacts and processing this information, e.g., to check the correctness and consistency of variability information or to apply metrics. A configuration-based setup along with automatic documentation functionality allows different experiments and supports their easy reproduction.

Here, we describe KernelHaven as a product line analysis research tool and highlight its basic approach as well as its fundamental capabilities. In particular, we describe available information extraction and processing plug-ins and how to combine them. On this basis, researchers and interested professional users can rapidly conduct a first set of experiments. Further, we describe the concepts for extending KernelHaven by new plug-ins, which reduces development effort when realizing new experiments.

abstract

EASy-Producer is an open-source research toolset for engineering product lines, variability-rich software ecosystems, and dynamic software product lines. In this tutorial, we will focus on its (textual) variability modeling capabilities as well as its configuration and validation functionality. Further, we will provide an outlook on how EASy-Producer can be applied to variability instantiation.

abstract

EASy-Producer is an open-source research toolset for engineering product lines, variability-rich software ecosystems, and dynamic software product lines. In this tutorial, we will focus on its model-based development and implementation capabilities, which are realized by the Variability Instantiation Language (VIL) and the Variability Template Language (VTL). Further, we will provide a basic introduction into the Integrated Variability Modeling Language (IVML) in order to use the provided information of IVML variability models and configurations during instantiation defined with VIL and as part of the templates created with VTL.

abstract

Ideally, a variability model is a correct and complete representation of product line features and constraints among them. Together with a mapping between features and code, this ensures that only valid products can be configured and derived. However, in practice the modeled constraints might be neither complete nor correct, which causes problems in the configuration and product derivation phases. This paper presents an approach to reverse engineer variability constraints from the implementation, and thus improve the correctness and completeness of variability models.

We extended the concept of feature effect synthesis [18] to extract domain knowledge from code artifacts of the Bosch PS-EC product line. We present an application of the approach to a large-scale industrial product line and discuss its required modifications to obtain meaningful results in an industrial case.

abstract
Ideally the variability of a product line is represented completely and correctly by its variability model. However, in practice additional variability is often represented on the level of the build system or in the code. Such a situation may lead to inconsistencies, where the actually realized variability does not fully correspond to the one described by the variability model. In this paper we focus on configuration mismatches, i.e., cases where the effective variability differs from the variability as it is represented by the variability model. While previous research has already shown that these situations still exist even today in well-analyzed product lines like Linux, so far it was unclear under what circumstances such issues occur in reality. In particular, it is open what types of configuration mismatches occur and how severe they are. Here, our contribution is to close this gap by presenting a detailed manual analysis of 80 configuration mismatches in the Linux 4.4.1 kernel and assess their criticality. We identify various categories of configuration issues and show that about two-thirds of the configuration mismatches may actually lead to kernel misconfigurations.

abstract
Development of Software Product Lines (SPLs) requires additional implementation concepts to manage variability and to facilitate the derivation of individual products based on a common platform. These variability implementation concepts are not required for the development of single systems and, thus, are not considered in traditional software engineering. Metrics are well established in traditional software engineering, but are typically not applicable to SPLs as they do not address variability management. Over time, a number of specialized product line metrics have been described in literature. However, no systematic description of the characteristics of these metrics is currently available. We conducted a systematic literature review to identify variability-aware implementation metrics, designed for the needs of SPLs. We list these metrics according to the measured artifact types: variability models, code artifacts, and combined metrics measuring both artifact types. Further, we analyze to what extent these metrics were evaluated as a basis for qualitative conclusions.

abstract
Context. Software product line engineering has been established to minimize costs and efforts, while maximizing the quality of products in a family of software products. Software product lines typically contain a variability model, which supports the derivation of permissible variants. These variability models may contain expert/domain knowledge in the form of constraints. These constraints are used during the configuration process to avoid the selection of unsupported product variants. Problem. Developers must encode their knowledge about supported product variants and restrictions, otherwise the variability model becomes ineffective or even incorrect. The initial development of the variability model as well as the evolution of the product line implementation bear the risk that model and implementation drift apart. In this report, we introduce the notion of mismatched configuration information to describe the situation if the variability model does not react the dependencies of the implementation. This may indicate an incomplete variability model or undesired dependencies between code artifacts. Solution. We discuss the impact of mismatched configuration information and show how to detect this conceptually. Subsequently, we focus on mismatched hierarchical configuration information and present an effective heuristic for their detection. These results serve as an input to complete variability models or a code review to remove undesired implementation dependencies. We discuss the application of our approach on a Linux case study. The analysis of the x86 architecture of the Linux kernel takes only around 30 minutes and revealed mismatched configuration information, which was not treated by prior work.

abstract
The Linux Kernel is often used as real world use case to demonstrate novel Software Product Line Engineering techniques. The large open source repository facilitates the analysis of the variability model, the instantiation process, the instantiable artefacts, and the evolution of all of them. This report focusses on the analysis of undocumented KConfig functionalities. These functions have to be considered while applying any variability management technique to the Linux Kernel. Hence, this report will contribute to a better understanding how variability is handled in KConfig files. Further, we analyse existing work, which also analysed KConfig. Based on the weak documentation of KConfig, these works contain errors. These errors threat the validity of many existing analysis of the Linux Kernel.

abstract
Software Product Line Engineering (SPLE) is a systematic approach for the development of related software products. These products share a common infrastructure but vary with respect to their individual capabilities, called variabilities. Variability management is a key part of SPLE and is responsible for developing, combining and configuring such variabilities. As these activities are inherently complex, SPLE significantly benefits from tool-support. We developed a customizable Eclipse extension for SPLE that consists of around 38 plug-ins. The resulting tool, called EASy-Producer, extends the Eclipse IDE by the capability to support the creation and management of software product line projects. To provide this capability, EASy-Producer utilizes the extension concepts of the Eclipse platform and integrates additional frameworks, like Xtext. In this paper, we share our experience while applying the Eclipse technologies and, in particular, realizing specific capabilities of our tool using the Eclipse framework. The focus of this paper is on our lessons learned regarding managing workspace information and conflicting build mechanism as well as using Eclipse extensions outside of Eclipse. These lessons serve as an input to the Eclipse community and may help other developers in realizing a complex Eclipse extension.

abstract
The Linux kernel is often used as a real world case study to demonstrate novel Software Product Line Engineering research methods. An important point in this is often the analysis of the Kconfig semantics. However, we detected that the semantics of Kconfig is rather unclear and has many special cases, which are not documented in its short specification. We performed a systematic analysis to uncover the correct behaviour of Kconfig and present the results, which are necessary for applying semantically correct analyses. Further, we analyse existing analysis tools of the research community whether they are aware of the correct semantics of Kconfig. These analyses can be used for improving existing analysis tools as well as decision support for selecting an appropriate tool for a specific analysis. In summary we contribute to a better understanding of Kconfig in the research community to improve the validity of evaluations based on Linux.

abstract
Development of software product lines requires tool support, e.g., to define variability models, to check variability models for consistency and to derive the artifacts for a specific product. Further capabilities are required when product lines are combined to software ecosystems, i.e., management and development of distributed product lines across multiple different organizations. In this paper, we describe EASy-Producer, a prototypical tool set for the development of software product lines in general and variant-rich ecosystems in particular. To support the product line engineer, EASy-Producer differentiates between simplified views limiting the capabilities and expert views unleashing its full power. We will discuss how these two views support the definition of variability models, the derivation of product configurations and the instantiation of artifacts.

abstract
Most research in product line engineering focuses on the domain engineering phase. However, the ultimate reason of any Software Product Line Engineering (SPLE) activity is the derivation of products and thus application engineering. In this research we focus on how the configuration activity within application engineering can be supported to achieve sufficient efficiency. We aim to provide a broad overview of the potential research landscape where we also discuss the actual coverage of the field by research work. As a result, we do not only provide an overview of the field, but do also describe several potential research approaches that have so far received very little attention.

abstract
In Software Product Line Engineering, variability modeling plays a crucial rule. Over the years, a couple of different modeling paradigms with a plethora of different approaches have been proposed. However, only little attention was spend to compare these concepts. In this paper, we compare the capabilities and expressiveness of basic feature modeling with basic decision modeling. In this paper, we also present a formalization of basic decision modeling and show that in combination with a powerful constraint language both approaches are equivalent, while in their very basic forms they are not equivalent. These results can be used to transfer existing research results between the two paradigms.

abstract
[Context and motivation] While requirements engineering earlier focused on gathering requirements, it has been recognized today that creativity and innovation are required as a basis for novel products. [Question/problem] We described earlier an approach to support creativity in requirements engineering. Here, we focus on a thorough validation of the approach. [Principal ideas/results] Our approach uses semantic-based technologies to derive new idea triggers. Here, we show an evaluation of this approach. We find that the approach provides better results than other existing creativity techniques like random triggers. [Contribution] The paper provides evidence for creativity enhancement using our approach. It also shows how a controlled experiment to analyze creativity in requirements engineering can be performed.

abstract
Im modernen Requirements Engineering werden Anforderungen nicht nur erfasst, sondern gestaltet. Entsprechend ist Innovation in der Anforderungsgewinnung eine wichtige Aufgabe, die entscheidenden Einfluss auf den Produkterfolg hat. Doch können innovative Ideen systematisch entwickelt werden? Frühere Fallstudien zeigten bereits, dass dies möglich ist. In diesem Beitrag zeigen wir, dass der kreative Nutzen einzelner Techniken mit empirischen Methoden systematisch analysiert und belegt werden kann.

abstract
In this paper, we describe EASy-Producer, a prototypical tool for complex and large-scale Software Product Line (SPL) development. The tool enables SPL engineers to reduce complexity by combining derivation and composition techniques to manage one large SPL as a combination of individual, but interrelated SPLs.

abstract
Software Product Line Engineering is inherently complex. This complexity increases further if multiple product line infrastructures are composed to yield the final products, an approach sometimes referred to as Multi Software Product Lines (MSPL). In this paper, we present an approach that targets this development scenario. The approach we present here aims at a lightweight, scalable, and practical approach to variability management for multi software product lines. Our approach explicitly supports heterogeneous product lines, i.e. situations where the various product lines use different generation approaches. The approach has been implemented in the EASy-Producer tool set and applied on some case studies.

abstract
Traditionell wird die Anforderungserhebung vor allem als eine reine Erfassung existierender Wünsche gesehen. In letzter Zeit setzt sich jedoch die Ansicht durch, dass Anforderungen für neue Produkte meist erst entwickelt werden müssen; Anforderungserhebung also mit Innovation verbunden ist. Damit ist auch das Interesse an der Unterstützung von Kreativität in der Anforderungserhebung stark gewachsen. Kreativitätsunterstützung wird meist im Zusammenhang mit moderierten Workshops gesehen. Hier stellen wir jedoch einen Ansatz dar, bei dem ein Assistenzsystem basierend auf modelliertem Wissen versucht zusätzliche Anhaltspunkte für die kreative Entwicklung von Anforderungen zu geben.

abstract
In competitive markets product innovation becomes a major issue for companies. Many creativity techniques have been proposed over time to improve creativity.In this paper, we discuss a platform and a specific reasoning approach to support product innovation. This reasoning approach is based on a specific form of heuristic (or almost correct) reasoning, most instances rely on analogies.