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.

Customers no longer consider configuration special: They expect it. This expectation applies both to simple goods like t-shirts or yoghurt and to sophisticated products composed of heterogeneous hardware and software like cars or ships. The software product line community has contributed to making the software configuration of such products more robust and efficient. Yet, despite those efforts, some challenges remain open. This keynote will bring to light some of those challenges by answering the question: What is research in software product line engineering not solving in configuration?

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.

In software product lines, engineers derive products using feature-based configurators. Such tools do not scale well to complex (non linear, multi-user) configuration processes. We address this issue by extending a feature-based configurator with multi-view support and by integrating it with a workflow management tool.

We recently introduced feature configuration workflows, a formalism for modelling the complex configuration processes in software product line engineering. In earlier work we identified obstacles to efficient tool support for which we now outline the main concepts of a solution. These take the form of a set of analysis tasks that can be performed on feature configuration workflows.

Variability models, feature diagrams ahead, have become commonplace in the software product lines engineering literature. Whereas ongoing research keeps improving their expressiveness, formalisation and automation, more experience reports on their usage in real projects are needed. This paper describes some challenges encountered during the re-engineering of PloneMeeting, an Open Source software family, into a software product line. The main challenging issues we could observe were (i) the ambiguity originating from implicit information (missing definitions of feature labels and unclear modelling viewpoint), (ii) the necessity of representing spurious features, (iii) the difficulty of making diagrams and constraints resistant to change, and (iv) the risks of using feature attributes to represent large sets of subfeatures. Our study reveals the limitations of current constructs, and calls for both language and methodological improvements. It also suggests further comparative evaluations of modelling alternatives.