Context Navigation

Reverse Engineering and Maintaining Feature Models

or how Breathing Knowledge into Feature Model Synthesis can be practically performed for this purpose.

Feature Models (FMs) are a popular formalism for modelling and reasoning about commonality and variability of a concept. The essence of feature models is to define a set of valid combinations of features, also called configurations.
We tackle the problem of constructing a feature model from a set of legal configurations, a process called feature model synthesis.
The main challenge is that numerous candidate feature models can be extracted from the same input configurations, yet only a
few of them are meaningful and maintainable (see examples below).
We develop a synthesis procedure capable of restituting the intended
meanings of feature models based on user or inferred knowledge.
The synthesis procedure is supported by the FAMILIAR language.
We show how the integration of knowledge into feature models synthesis can be realised in different application scenarios such as feature model refactoring, reverse engineering, merging or slicing.
For example, using the language and the synthesis procedure, multiple FMs can be merged while the resulting FM, if not suitable, can be refactored.

Indeed they represent the exact same set of configurations.
In the jargon of feature models (see the paper of Thuem, Batory and Kästner, ICSE'09, "Reasoning about Edits to Feature Models"), these feature models are refactoring in the sense they represent the same set of configurations.

Below are a FAMILIAR script and an interactive session illustrating this fact:

Note that the compare operation reasons over the set of configurations (Thuem, Batory and Kästner made a slight difference by considering only leaf features as part of the configurations... It has no impact here)

Second example

Let us now consider the set of configurations s1

s1 =
{
{MI,Nifti,CT},
{MRI,MI,DICOM}
}

typically representing the projected set of configurations of fm0 on features Medical Image, MRI, CT, Nifti, and DICOM

Concrete syntax

To overcome this issue, we propose a generic synthesis integrated in the FAMILIAR language.
It comes through an operator, called ksynthesis.
The operator performs over propositional formulae and computes a feature model.
Specific directives (see below) can be specified by users for synthesising a feature model with intended properties.

From a practical perspective, the operator takes as first parameter

either a formula (e.g., specified in the DIMACS format, a standard format for boolean formulas in conjunctive normal forms), typically for reverse engineering a feature model ;

or a feature model -- in this case, the corresponding formula of the feature model is considered by the synthesis operator -- typically for refactoring and maintaining an existing feature model

The directives are all optionals: users can specify either the hierarchy, the way features should be grouped and the constraints expected in the resulting feature model.
Below is an excerpt of the FAMILIAR Xtext grammar:

Applications

Reverse engineering

The goal is to produce a feature model whose set of configurations corresponds exactly to programs' feature sets.
Stated differently, each valid configuration of the feature model should correspond to one program documented in the tabular data.

The solutions proposed in Haslinger et al. and Acher et al. are not completely satisfactory.
Typically, the feature models produced can exhibit an unstructured hierarchy (see below two examples):

The approach proposed in Acher et al. (see also the dedicated page of the project) is as follows: each program/product is documented as a feature model and then the feature models are "merged" into an integrated feature model representing the union of set of configurations.
The major problem is that the procedure cannot determine a hierarchy due to the lack of structure in the tabular data.
Therefore a flattened hierarchy is chosen by the merging procedure.