We reverse-engineer a formal semantics of the Component Definition Language (CDL), which is part of the highly configurable, embedded operating system eCos. This work provides the basis for an analysis and comparison of the two variability-modeling languages Kconfig and CDL. The semantics given in this document are based on analyzing the CDL documentation, inspecting the source code of the toolchain, as well as testing the tools on particular examples.

The Kconfig language defines a set of symbols that are assigned a value in a configuration. We describe the semantics of the Kconfig language according to the behavior exhibited in the xconfig configurator. We assume an abstract syntax representation for concepts in the Kconfig language and delegate the details of the translation from concrete to abstract syntaxes to a later document.

To prevent ill-formed configurations, highly configurable software often allows defining constraints over the available options. As these constraints can be complex, fixing a configuration that violates one or more constraints can be challenging. Although several fix-generation approaches exist, their applicability is limited because (1) they typically generate only one fix or a very long fix list, difficult for the user to identify the desirable fix; and (2) they do not fully support non-Boolean constraints, which contain arithmetic, inequality, and string operators. This paper proposes a novel concept, range fix, for software configuration. A range fix specifies the options to change and the ranges of values for these options. We also design an algorithm that automatically generates range fixes for a violated constraint. We have evaluated our approach with three different strategies for handling constraint interactions, on data from nine open source projects over two configuration platforms. The evaluation shows that our notion of range fix leads to mostly simple yet complete sets of fixes, and our algorithm is able to generate fixes within one second for configuration systems with a few thousands options and constraints.

Feature models are menu-like hierarchies of features (i.e., configuration options) used in variability-rich software. Feature models have many applications such as domain analysis, describing design and implementation constraints in software, or for product configuration. The many applications of feature models have given rise to a wide range of scenarios involving feature model synthesis. Feature model synthesis is the process of building a feature model for a given set of features and their allowed combinations, expressed as feature dependencies or feature configurations. We describe and classify software re-engineering scenarios involving feature model synthesis found in literature and industry. We analyze these scenarios to derive requirements for feature model synthesis techniques.

Context: Software ecosystems are increasingly popular for their economic, strategic, and technical advantages. Application platforms such as Android or iOS allow users to highly customize a system by selecting desired functionality from a large variety of assets. This customization is achieved using variability mechanisms.Objective: Variability mechanisms are well-researched in the context of software product lines. Although software ecosystems are often seen as conceptual successors, the technology that sustains their success and growth is much less understood. Our objective is to improve empirical understanding of variability mechanisms used in successful software ecosystems.Method: We analyze five ecosystems, ranging from the Linux kernel through Eclipse to Android. A qualitative analysis identifies and characterizes variability mechanisms together with their organizational context. This analysis leads to a conceptual framework that unifies ecosystem-specific aspects using a common terminology. A quantitative analysis investigates scales, growth rates, and-most importantly-dependency structures of the ecosystems.Results: In all the studied ecosystems, we identify rich dependency languages and variability descriptions that declare many direct and indirect dependencies. Indirect dependencies to abstract capabilities, as opposed to concrete variability units, are used predominantly in fast-growing ecosystems. We also find that variability models-while providing system-wide abstractions over code work best in centralized variability management and are, thus, absent in ecosystems with large free markets. These latter ecosystems tend to emphasize maintaining capabilities and common vocabularies, dynamic discovery, and binding with strong encapsulation of contributions, together with uniform distribution channels.Conclusion: The use of specialized mechanisms in software ecosystems with large free markets, as opposed to software product lines, calls for recognition of a new discipline variability encouragement. (C) 2014 Elsevier B.V. All rights reserved.

We reverse-engineer a formal semantics of the Component Definition Language (CDL), which is part of the highly configurable, embedded operating system eCos. This work provides the basis for an analysis and comparison of the two variability-modeling languages Kconfig and CDL. The semantics given in this document are based on analyzing the CDL documentation, inspecting the source code of the toolchain as well as testing the tools on particular examples. 1 Semantics 1.1 Abstract Syntax Features, types and constraints. Let Id be a finite set of features, let Kinds be a set of domain-specific feature kinds and let Flavors be a set of types that further define a feature’s possible values. More precisely, Kinds = {package, component, option, interface} and Flavors = {none, bool, booldata, data}. Furthermore, we introduce two types of expressions allowed in CDL: Goal expressions and list expressions. Concerning the first one, we define Exp(Id) to be a set of goal expressions over Id, generated by the following grammar: e ::= id | const | e⊗ e |!e | ̃e | e⊕ e | e⊘ e | Func(e, e, ...) | e?e : e (1) Here, ⊗ ∈ {||,&&, implies, eqv, xor}, ⊕ ∈ {+,−, ∗, /,%, <<,>>, ˆ,&, |}, ⊘ ∈ {==, !=, <,>,<=, >=}, Func ∈{get data, is active, is enabled, is loaded, is substr, is xsubstr, version cmp}, id ∈ Id and const ∈ Data, whereas Data is a set of untyped data (say all character strings). The second type of expressions, so-called list expressions represent an enumeration of values or ranges, which can be computed by goal expressions. Thus, we define LExp(Id) to be a set of list expressions over goal expressions, generated by the following grammar (e ∈ Exp(Id)): l ::= (e | e to e) [ l ] (2) CDL models. Cdl is the set of all possible models in CDL. Each CDL model m ∈ Cdl is a set of nodes, so Cdl = P(Nodes), where Nodes = Id× ⌈Id⌉ × Flavors× P(Exp(Id))×P(Exp(Id))× ⌊Exp(Id)⌋ × ⌊LExp(Id)⌋ × Kinds× P(Id) (3) 1http://ecos.sourceware.org 2http://ecos.sourceware.org/docs-3.0/cdl-guide/cdl-guide.html

Variability models represent the common and variable features of products in a product line. Since the introduction of FODA in 1990, several variability modeling languages have been proposed in academia and industry, followed by hundreds of research papers on variability models and modeling. However, little is known about the practical use of such languages. We study the constructs, semantics, usage, and associated tools of two variability modeling languages, Kconfig and CDL, which are independently developed outside academia and used in large and significant software projects. We analyze 128 variability models found in 12 open--source projects using these languages. Our study 1) supports variability modeling research with empirical data on the real-world use of its flagship concepts. However, we 2) also provide requirements for concepts and mechanisms that are not commonly considered in academic techniques, and 3) challenge assumptions about size and complexity of variability models made in academic papers. These results are of interest to researchers working on variability modeling and analysis techniques and to designers of tools, such as feature dependency checkers and interactive product configurators.

Variability models represent the common and variable features of products in a product line. Since the introduction of FODA in 1990, several variability modeling languages have been proposed in academia and industry, followed by hundreds of research papers on variability models and modeling. However, little is known about the practical use of such languages. We study the constructs, semantics, usage, and associated tools of two variability modeling languages, Kconfig and CDL, which are independently developed outside academia and used in large and significant software projects. We analyze 128 variability models found in twelve open source projects using these languages. Our study (1) supports variability modeling research with empirical data of the real-world use of its flagship concepts. However, we (2) also provide requirements for concepts and mechanisms not commonly considered in academic techniques, and (3) challenge assumptions about size and complexity of variability models made in academic papers. These results are of interest to researchers working on variability modeling techniques, variability analysis techniques, and for tool designers, such as feature dependency checkers and interactive product configurators.

To prevent ill-formed configurations, highly configurable software often allows defining constraints over the available options. As these constraints can be complex, fixing a configuration that violates one or more constraints can be challenging. Although several fix-generation approaches exist, their applicability is limited because (1) they typically generate only one fix, failing to cover the solution that the user wants; and (2) they do not fully support non-Boolean constraints, which contain arithmetic, inequality, and string operators. This paper proposes a novel concept, range fix, for software configuration. A range fix specifies the options to change and the ranges of values for these options. We also design an algorithm that automatically generates range fixes for a violated constraint. We have evaluated our approach with three different strategies for handling constraint interactions, on data from five open source projects. Our evaluation shows that, even with the most complex strategy, our approach generates complete fix lists that are mostly short and concise, in a fraction of a second.

Feature models describe the common and variable characteristics of a product line. Their advantages are well recognized in product line methods. Unfortunately, creating a feature model for an existing project is time-consuming and requires substantial effort from a modeler. We present procedures for reverse engineering feature models based on a crucial heuristic for identifying parents - the major challenge of this task. We also automatically recover constructs such as feature groups, mandatory features, and implies/excludes edges. We evaluate the technique on two large-scale software product lines with existing reference feature models--the Linux and eCos kernels--and FreeBSD, a project without a feature model. Our heuristic is effective across all three projects by ranking the correct parent among the top results for a vast majority of features. The procedures effectively reduce the information a modeler has to consider from thousands of choices to typically five or less.

Variability models represent the common and variable features of products in a product line. Several variability modeling languages have been proposed in academia and industry; however, little is known about the practical use of such languages. We study and compare the constructs, semantics, usage and tools of two variability modeling languages, Kconfig and CDL. We provide empirical evidence for the real-world use of the concepts known from variability modeling research. Since variability models provide basis for automated tools (feature dependency checkers and product configurators), we believe that our findings will be of interest to variability modeling language and tool designers.

Understanding the challenges faced by real projects in evolving variability models, is a prerequisite for providing adequate support for such undertakings. We study the evolution of a model describing features and configurations in a large product line--the Linux kernel variability model. We analyze this evolution quantitatively and qualitatively. Our primary finding is that the Linux kernel model appears to evolve surprisingly smoothly. In the analyzed period, the number of features had doubled, and still the structural complexity of the model remained roughly the same. Furthermore, we provide an in-depth look at the effect of the kernel's development methodologies on the evolution of its model. We also include evidence about edit operations applied in practice, evidence of challenges in maintaining large models, and a range of recommendations (and open problems) for builders of modeling tools.

Large software product lines have complex build systems that enable compiling the source code into different products that make up the product line. Unfortunately, the dependencies among the available build options, which we refer to as features and their mapping to the source code they control, are implicit in complex imperative build-related logic.

Framework-specific modeling languages (FSMLs) are specifications of framework concepts and their intended usages. Interpreting an FSML over a set of applications enables a user to detect framework concepts in source code through reverse-engineering. We describe our FSML interpreter written using Prolog. The interpreter itself consists of two main components: a parser that is responsible for reading an FSML specification and an engine, responsible for interpreting the constraints of the FSML and reverseengineering an FSML instance from a set of program facts. We discuss the purpose of each component and further highlight the advantages, as well as disadvantages of our implementation.

We present probabilistic feature models (PFMs) and illustrate their use by discussing modeling, mining and interactive configuration. PFMs are formalized as a set of formulas in a certain probabilistic logic. Such formulas can express both hard and soft constraints and have a well defined semantics by denoting a set of joint probability distributions over features. We show how PFMs can be mined from a given set of feature configurations using data mining techniques. Finally, we demonstrate how PFMs can be used in configuration in order to provide automated support for choice propagation based on both hard and soft constraints. We believe that these results constitute solid foundations for the construction of reverse engineering tools for software product lines and configurators using soft constraints.

Documentation maintainence is a difficult and costly proces s. Existing forms of software documentation exist independent from the code it describes. As a result, pr oblems arise when source code evolves since there is no traceability between the documentation and code d mains. CodeLink, a semantic wiki designed for code documentation a ttempts to address this problem. CodeLink provides a platform for establishing traceability links be tw en developer documentation and code concepts. Traceability links between documentation and code can be ex plicitly created by the user through annotations, or inferred through the use of natural language analysis. Co deLink employs an ontology as its knowledge model and a semantic wiki as its user interface. Annotations on traceability relations in the ontology serve to connect natural language phrases with formal ontology co ncepts. In this paper, the motivation, design and implementation of C deLink are described. Particular focus is placed on the natural language processing (NLP) component o f CodeLink. The process in which the NLP component infers traceability links from the natural langu a e text in the semantic wiki is described in depth. Several methods of querying and retrieving information fro m the knowledge model are discussed, followed by a summary of related and future work.

Abstract In this paper, we examine the architecture of the GNU Image Manipulation Program (GIMP) from two separate points of view. We begin by constructing a conceptual architecture using available developer documentation. We then describe the GIMP’s control flow based on our conceptual architecture and describe how the architecture allows for the extensibility of the GIMP. The conceptual architecture is then compared to the concrete architecture, the architecture