Sascha El-Sharkawy

EASy-producer: product line development for variant-rich ecosystems

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.

Supporting heterogeneous compositional multi software product lines

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.

From feature models to decision models and back again an analysis based on formal transformations

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 spent 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.

A heuristic approach for supporting product innovation in requirements engineering: a controlled experiment

[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.

KernelHaven: an experimentation workbench for analyzing software product lines

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: https://github.com/KernelHaven. The plug-ins are available under their individual licenses.

Analysing the Kconfig semantics and its analysis tools

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.

An Empirical Study of Configuration Mismatches in Linux

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.

KernelHaven: an open infrastructure for product line analysis

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, e.g., 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.

Reverse engineering variability in an industrial product line: observations and lessons learned

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 analysis [22] to extract variability constraints from code artifacts of the Bosch PS-EC large-scale product line. We present an industrial application of the approach and discuss its required modifications to handle non-Boolean variability and heterogeneous artifact types.

Reverse engineering code dependencies: converting integer-based variability to propositional logic

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 modifications. 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.