Extension for Visibility Constraints

[kristofmeixner]

Currently, UVL supports constraints that define valid feature configurations using known constructs, such as or or alternative groups, or cross-tree constraints. Currently, it lacks constructs to specify the order in which features become available for selection during configuration.

For some use cases, it may be useful to guide users through a configuration sequence by making features available only after specific prerequisites or configurations have been selected, similar to decision models (cf. also https://doi.org/10.1145/2110147.2110167).

We propose extending UVL with visibility constraints to support such configuration sequences. The underlying idea for such a constraint was proposed in https://doi.org/10.1145/3634713.3634730.

Proposed extension

A visibility constraint defines a precondition for making a feature available for selection. We propose to introduce a binary operator, e.g., vif (visible if), expressed as F vif Φ, where F is a feature (list) and Φ is a propositional formula over features.

For example:

FeatureA vif FeatureB & FeatureC

This constraint specifies that FeatureA becomes available only after both FeatureB and FeatureC have been selected.

Unlike traditional cross-tree constraints, visibility constraints do not restrict the validity of the final configuration. Instead, they define dependencies between configuration steps, establishing a partial order over feature selections.

Aspects to consider

1. Language integration: Visibility constraints could be specified inline as feature attributes or in a dedicated visibility constraints section supporting backward compatibility.
2. Constraint semantics: Visibility constraints affect feature availability during configuration rather than the validity of the final configuration.
3. Tool support: Configuration tools shall dynamically evaluate feature availability as configuration progresses.

Questions for discussion

• Which use cases would benefit from explicitly modeling configuration sequences in UVL?
• Should visibility constraints be specified inline, in a dedicated section, or both?
• How should visibility constraints interact with existing cross-tree constraints and automated configuration?
• Would a dedicated UVL language level for visibility constraints make sense?

We have implemented a proof of concept that extends UVL and FeatureIDE with visibility constraints, demonstrating their technical feasibility across different configuration scenarios in https://doi.org/10.1007/978-3-032-40421-3_8.

We welcome feedback on the proposed syntax, semantics, and integration into UVL.