Automatic feature model analysis

[ekuiter]

Right now, we do not do much with the feature models other than allowing basic editing.

FeatureIDE provides many analyses such as dead or false-optional feature analysis. The editor should integrate these analyses.

The tricky question is, when to calculate analysis results. Most likely, users expect that analysis results are provided automatically (not only when explicitly requested) and included in the editor UI. So, we basically need to recalculate all enabled analyses after each feature model update.

Some ideas for making this more performant:

• cache analysis results (and determine when an update actually may affect the cached result, e.g., renaming a feature does not affect dead or false-optional features)
• do not calculate results after each feature model update, but after a batch of updates - this way, the user might have to wait a little for results, which should be okay if we show a matching loading indicator)

We also have to run analyses asynchronously. This is important so that the server can still operate and process incoming messages (analysis is only a "nice" feature that should never render the server unusable). This might prove tricky, as the analysis now runs on a feature model that may be changed while the analysis is still running. We have to account for this with some kind of synchronization, or by cloning the feature model before analysis. Another problem is that this way, we may get "outdated" analysis results (results that are now invalid because the feature model was changed during analysis, e.g., a feature is marked as dead although it has been removed during the analysis). So we need some sanity-check or invalidation mechanism to account for this.

Note that this way all analyses run on the server. We could also run them on a client, but this would require a SAT solver (big JavaScript footprint) and re-implementing all analyses in JavaScript. This would also have a negative effect on device battery life.

[ekuiter]

It would also be interesting to integrate feature model edit reasoning (Thüm 2009) to classify/restrict editing capabilities (e.g., certain user groups may only add variability (see #12)). (This may be tricky regarding performance, because for edits to take effect, the validation has to be performed first (and may take a second or so). We could maybe use an optimistic approach that reverts an edit if it turns out to be invalid after analysis.)

[ekuiter]

The kernel approach necessitates that we run analyses for each generated/received operation (on server AND client). Analysis is done synchronously and blocks the user interface, so not recommended for larger feature models. (Alternatively, analysis could be done asynchronously without guaranteeing consistency, just to improve understanding of the model.)
Regarding Thüm 2009: It can be proven that, suppose an edit is locally a refactoring/generalization/specialization, it will also be when combined with other refactoring/generalization/specialization edits (no check needed in the kernel). (Proof relies on the set equivalence/subset relation's transitivity.)