Variantenmanagement: mehr als Feature-Strings

Wird ein Feature umbenannt, veralten Variationsbedingungen in den Entwicklungsartefakten oft unbemerkt. Oder eine Variante enthält eine Architekturkomponente, deren referenzierte Anforderung beim Filtern entfernt wurde. Solche Fehler sind keine Einzelfälle, sondern entstehen systematisch aus der losen Kopplung zwischen Variantenmanagement-Werkzeugen und den übrigen Entwicklungsartefakten. Eine engere Integration behebt diese Probleme grundlegend und eröffnet darüber hinaus Analysemöglichkeiten, die in der Praxis bisher kaum genutzt werden.

Feature-Diagramme als formale Grundlage

Für die Entwicklung von Produktfamilien ist eine formale Beschreibung des gesamten möglichen Produktraums unverzichtbar. Dafür hat sich seit mehr als drei Jahrzehnten die Feature-Orientierte Domänenanalyse (FODA) bewährt: Feature-Diagramme beschreiben alle Entscheidungen zur Konfiguration eines konkreten Produkts sowie die geltenden Einschränkungen.

Ein Feature-Diagramm folgt einer hierarchischen Baumstruktur. Jeder Knoten repräsentiert ein Produktmerkmal. Optionale Features, Alternativen (XOR) und Oder-Gruppen (OR) werden durch standardisierte Notation ausgedrückt. Zusätzliche Cross-Tree-Constraints schränken die erlaubten Kombinationen weiter ein – etwa durch Implikationsregeln wie HighEndGraphics ⇒ CPU_3GHz. Features können außerdem Attribute besitzen, mit denen pro Variante konkrete Datenwerte festgelegt werden (z.B. eine Speichergröße in GB).

Beispiel eines Feature-Diagramms: Mandatory-Features, optionale Features, XOR-Alternativen, Attribute und ein Cross-Tree-Constraint (HighEndGraphics ⇒ CPU_3GHz).

Da die formale Sprache klar definiert ist, können Werkzeuge Konsistenz und Redundanz automatisch prüfen. Dadurch werden ungültige Feature-Diagramme erkannt und überflüssige Constraints identifiziert.

Konfiguration von Produktinstanzen

Werden alle Entscheidungen eines Feature-Diagramms konsistent getroffen, entsteht eine konkrete Produktinstanz – eine Variante. Geeignete Werkzeuge unterstützen diesen Prozess durch eine hierarchische Baumdarstellung mit Checkboxen und berücksichtigen dabei automatisch strukturelle Abhängigkeiten und Cross-Tree-Constraints. So wird verhindert, dass inkonsistente Konfigurationen entstehen.

Variabilität in Entwicklungsartefakten: das 150%-Prinzip

Ein Feature-Diagramm allein hat noch keine Auswirkungen auf Anforderungen, Architekturmodelle oder Code. Die Verbindung entsteht durch das Konzept der 150%-Artefakte:

• Alle Entwicklungsartefakte werden als Übermenge über alle möglichen Varianten ausgelegt.
• Jeder variable Teil eines Artefakts erhält eine Presence Condition – eine Bedingung, die angibt, bei welchen Feature-Kombinationen dieser Teil enthalten sein soll.
• Liegt eine konkrete Konfiguration vor, wird das 150%-Artefakt automatisch auf das 100%-Artefakt der Produktinstanz transformiert.

Dieses Prinzip ist auf beliebige Artefakttypen anwendbar: Requirements aus Codebeamer™ oder DOORS™, SysML-Modelle, Office-Dokumente oder C-Code.

Für die Verbindung eines Feature-Modells mit diesen Artefakten gibt es grundsätzlich zwei Ansätze: lose Kopplung und enge Kopplung. Sie unterscheiden sich vor allem darin, welche Fehler sich damit erkennen lassen.

Lose Kopplung – praktisch, aber mit Grenzen

In der Praxis dominiert heute die lose Kopplung: Ein separates Variantenmanagement-Werkzeug verwaltet Feature-Diagramme und Konfigurationen. Die Presence Conditions werden in den jeweiligen Entwicklungswerkzeugen als einfache Zeichenketten oder Key-Value-Paare hinterlegt. Das Variantenmanagement-Werkzeug wertet diese aus und transformiert die Artefakte.

Dieser Ansatz hat den Vorteil, dass die beteiligten Werkzeuge weitgehend unabhängig voneinander bleiben und die Schnittstelle schmal und mit überschaubarem Aufwand zu implementieren ist. Dem stehen jedoch einige typische Schwachstellen gegenüber:

• Syntaktische Inkonsistenz: Presence Conditions als reine Zeichenketten werden nicht automatisch aktualisiert, wenn Features umbenannt oder gelöscht werden. Fehler bleiben oft lange unbemerkt.
• Keine Strukturprüfung: Das Variantenmanagement-Werkzeug kennt die interne Struktur der Entwicklungsartefakte nicht. Verschachtelte oder redundante Conditions und dead code in Modellen können nicht erkannt werden.
• Artefakt-Inkonsistenz nach Transformation: Referenzen können nach der Transformation ungültig werden – etwa wenn eine referenzierte Anforderung weggefiltert wird, die referenzierende Architekturkomponente aber nicht.
• Keine domänenspezifischen Prüfungen: Fachliche Invarianten, die für alle Varianten gelten müssen (z.B. „jeder Datenbus hat mindestens zwei Teilnehmer"), lassen sich nicht gegen das Feature-Modell prüfen.

In Summe werden Fehler dadurch erst spät im Entwicklungsprozess entdeckt. Ihre Korrektur kostet dann deutlich mehr Aufwand, und die Wahrscheinlichkeit von Fehlern im Endprodukt wächst.

Enge Kopplung von Feature-Modellen und DSL-Modellen

Enge Kopplung setzt voraus, dass die Entwicklungsartefakte in einer Umgebung entstehen, die deren interne Struktur kennt und sich direkt mit dem Feature-Modell verbinden lässt. Eine Language Workbench erfüllt diese Voraussetzung: Sie erlaubt es, domänenspezifische Sprachen (DSLs) zu definieren und Fachmodelle mit projizierenden Editoren zu erstellen. Bei itemis setzen wir in Kundenprojekten unter anderem MPS von JetBrains ein. Darauf aufbauend haben wir mit IETS3 ein leistungsfähiges Framework für Variantenmanagement entwickelt, das genau diese enge Kopplung ermöglicht und als Baustein in kundenspezifische Entwicklungswerkzeuge (Custom Tools) integriert wird.

Referenzkonsistenz automatisch prüfen

Ein konkretes Beispiel für den Mehrwert der engen Kopplung ist die Konsistenzprüfung von Referenzen in fachlichen Artefakten:

Angenommen, Modellelement A referenziert Modellelement B. A hat die Presence Condition Cond1, B hat die Presence Condition Cond2. Die Referenz ist nur dann konsistent, wenn die Implikation Cond1 ⇒ Cond2 gilt – also B immer dann enthalten ist, wenn A enthalten ist.

Referenzkonsistenz: Zeigt A auf B, muss gelten: Cond1 ⇒ Cond2. Bei enger Kopplung prüft das Werkzeug diese Bedingung automatisch für alle Referenzen im Modell.

Bei enger Kopplung kann das Werkzeug diese Prüfung automatisch für alle Referenzen im Modell durchführen. Wird eine Verletzung erkannt, berechnet es konkrete Konfigurationen als Gegenbeispiele. In der Praxis werden dabei auch die Modellhierarchie und Elternknoten berücksichtigt.

Presence Conditions als echte Referenzen

Bei enger Kopplung werden Presence Conditions nicht als Zeichenketten, sondern als echte Referenzen auf Features gespeichert. Daraus ergeben sich mehrere Konsequenzen:

• Syntaktische Konsistenz ist stets gewährleistet: Umbenennungen von Features propagieren sich automatisch in alle Artefakte.
• Logische Konsistenz: Variationsbedingungen werden algorithmisch gegen das Feature-Modell validiert. Tautologien (Conditions, die immer wahr sind) und Widersprüche (Conditions, die nie wahr sind) werden erkannt.
• Strukturelle Konsistenz: Verschachtelte Conditions können auf gegenseitige Konsistenz geprüft werden – die Kenntnis des abstrakten Syntaxbaums macht dies möglich.

Darüber hinaus lassen sich Variationsbedingungen algorithmisch berechnen (implizite Conditions): Wenn eine Architekturkomponente durch eine eigene Condition gefiltert wird, können zugehörige Ports und Konnektoren automatisch mitgefiltert werden. Der manuelle Modellierungsaufwand sinkt, und die Modelle bleiben übersichtlicher.

Weitere Möglichkeiten

Die enge Kopplung erschließt noch weitere Analysemöglichkeiten:

• Domänenspezifische Prüfungen: Fachliche Eigenschaften können automatisch gegen alle möglichen Konfigurationen geprüft werden – mit konkreten Gegenbeispielen in Form einer Variantenkonfiguration als Ergebnis.
• Variantenbewusste Instanziierung: Architekturkomponenten lassen sich unter Berücksichtigung von Variantenkonfigurationen instanziieren.
• Variantenanalyse: Die Menge aller konkreten Varianten eines Teilmodells lässt sich berechnen. Dabei können unterschiedliche Feature-Konfigurationen zu identischen Teilmodellen führen.
• Automatisches Zusammenfassen: Redundante Teilmodelle können durch formale Analyse erkannt und automatisch zu 150%-Modellen konsolidiert werden.

Fazit

Die enge Integration von Feature-Modellen und fachlichen Entwicklungsartefakten eröffnet Möglichkeiten, die mit loser Kopplung nicht erreichbar sind: frühzeitigere Fehlererkennung, reduzierte Modellkomplexität durch implizite Variationspunkte und domänenspezifische Konsistenzprüfungen über alle Varianten hinweg. Für die Entwicklung komplexer Produktlinien ist die enge Kopplung damit unverzichtbar.

Variantenmanagement und Custom Tooling bei itemis — DSLs und Werkzeuge für die Beherrschung variantenbehafteter Entwicklung: Custom Tool Development →