Variant Management: More Than Feature Strings

When a feature is renamed, variation conditions in the development artifacts often become outdated without notice. Or a variant contains an architecture component whose referenced requirement was removed during filtering. Such errors are not isolated cases; they arise systematically from the loose coupling between variant management tools and the other development artifacts. A tighter integration resolves these problems fundamentally and, in addition, opens up analysis capabilities which are rarely used in practice today.

Feature Diagrams as a Formal Foundation

For the development of product families, a formal description of the entire possible product space is indispensable. For this purpose, Feature-Oriented Domain Analysis (FODA) has been an established approach for more than three decades: feature diagrams describe all decisions required to configure a concrete product, along with the applicable constraints.

A feature diagram follows a hierarchical tree structure. Each node represents a product characteristic (feature). Optional features, alternatives (XOR), and OR groups are expressed using standardised notation. Additional cross-tree constraints further restrict the permitted combinations – for example, through implication rules such as HighEndGraphics ⇒ CPU_3GHz. Features can also carry attributes that define concrete data values per variant (e.g. a storage size in GB).

Example of a feature diagram: mandatory features, optional features, XOR alternatives, attributes, and a cross-tree constraint (HighEndGraphics ⇒ CPU_3GHz).

Because the formal language is clearly defined, tools can automatically check consistency and redundancy. This allows invalid feature diagrams to be detected and superfluous constraints to be identified.

Configuring Product Instances

When all decisions in a feature diagram are made consistently, a concrete product instance – a variant – emerges. Suitable tools support this process through a hierarchical tree view with checkboxes, automatically accounting for structural dependencies and cross-tree constraints. This prevents the creation of inconsistent configurations.

Variability in Development Artifacts: The 150% Principle

A feature diagram alone has no direct effect on requirements, architecture models, or code. The connection is established through the concept of 150% artifacts:

• All development artifacts are designed as a superset across all possible variants.
• Each variable part of an artifact receives a presence condition – a predicate that specifies under which feature combinations this part should be included.
• When a concrete configuration is available, the 150% artifact is automatically transformed into the 100% artifact for that product instance.

This principle applies to any artifact type: requirements from Codebeamer™ or DOORS™, SysML models, Office documents, or C code.

For connecting a feature model to these artifacts, there are basically two approaches: loose coupling and tight coupling. They differ above all in which errors can be detected.

Loose Coupling – Practical, but Limited

In practice, loose coupling dominates today: a separate variant management tool manages feature diagrams and configurations. Presence conditions are stored in development tools as simple strings or key-value pairs. The variant management tool evaluates these and transforms the artifacts.

This approach has the advantage that the tools involved remain largely independent of each other, and the interface is narrow and can be implemented with moderate effort. However, there are some typical weaknesses:

• Syntactic inconsistency: Presence conditions as plain strings are not automatically updated when features are renamed or deleted. Errors often go unnoticed for a long time.
• No structural checks: The variant management tool has no knowledge of the internal structure of development artifacts. Nested or redundant conditions and dead code in models cannot be detected.
• Artifact inconsistency after transformation: References can become invalid after transformation – for example, when a referenced requirement is filtered out, but the referencing architecture component is not.
• No domain-specific checks: Domain invariants that must hold for all variants (e.g. “every data bus has at least two nodes”) cannot be validated against the feature model.

As a consequence, errors are only detected late in the development process. Fixing them then requires considerably more effort, and the probability of defects in the final product increases.

Tight Coupling of Feature Models and DSL Models

Tight coupling requires that development artifacts are created in an environment which knows their internal structure and can be connected directly to the feature model. A language workbench meets this requirement: it allows domain-specific languages (DSLs) to be defined and domain models to be edited with projectional editors. At itemis, we use MPS by JetBrains in customer projects, among other tools. On this basis, we have developed IETS3, a powerful variant management framework which enables exactly this tight coupling and is integrated as a building block into customer-specific development tools (custom tools).

Checking Reference Consistency Automatically

A concrete example of the added value of tight coupling is reference consistency checking in domain artifacts:

Suppose model element A references model element B via a reference Ref1. A has presence condition Cond1, B has presence condition Cond2. The reference is only consistent if the implication Cond1 ⇒ Cond2 holds – i.e., B is always present whenever A is present.

Reference consistency: if A points to B, then Cond1 ⇒ Cond2 must hold. With tight coupling, the tool checks this automatically for every reference in the model.

With tight coupling, the tool can perform this check automatically for all references in the model. If a violation is found, it computes concrete configurations as counterexamples. In practice, the model hierarchy and parent nodes are also taken into account.

Presence Conditions as Real References

With tight coupling, presence conditions are stored not as strings but as real references to features. This has several consequences:

• Syntactic consistency is always guaranteed: renaming a feature automatically propagates to all artifacts.
• Logical consistency: Variation conditions are algorithmically validated against the feature model and its constraints. Tautologies (conditions that are always true) and contradictions (conditions that are never true) are detected.
• Structural consistency: Nested conditions can be checked for mutual consistency – thanks to the tool’s knowledge of the abstract syntax tree.

In addition, variation conditions can be algorithmically computed (implicit conditions): if an architecture component is filtered out by its own condition, associated ports and connectors can be automatically filtered as well. This reduces the manual modeling effort, and the models remain more concise.

Further Capabilities

Tight coupling also opens up additional analysis capabilities:

• Domain-specific variant checks: Domain properties can be automatically checked against all possible configurations – yielding concrete counterexamples as output.
• Variant-aware instantiation: Architecture components can be instantiated with awareness of variant configurations.
• Variance analysis: The set of all concrete variants of a sub-model can be computed. Here, different feature configurations may yield identical sub-models.
• Automatic consolidation: Redundant sub-models can be detected through formal analysis and automatically consolidated into 150% models.

Conclusion

Tight integration of feature models and variability-annotated development artifacts unlocks capabilities that loose coupling cannot provide: earlier error detection, reduced model complexity through implicit variation points, and domain-specific consistency checks across all variants. For the development of complex product lines, tight coupling is therefore indispensable.

Variant management and custom tooling at itemis — DSLs and tools for managing variability-rich development: Custom Tool Development →