Part 1: Schluss mit "one size fits all" - So werden Sie allen gerecht mit modellbasiertem Variantenmanagement

Das neue Serien-Highlight bei SodiusWillert - Part 1

Das Hantieren mit Produktversionen und Varianten kann sehr mühsam sein. Entwicklung und Weiterentwicklung eines Systems erfordert in den meisten Fällen, parallel existierende Varianten sowie aufeinanderfolgende Versionen verwalten zu müssen. Sie haben es mit verschiedenen Versionen von Anforderungen, von Modellen, von Code, von Testfällen zu tun – jedes einzelne Artefakt entlang des Lebenszyklus kann in mehreren Varianten existieren.

Den Überblick darüber zu behalten, welche Artefakte in den verschiedenen Phasen zu einer bestimmten Variante gehören, kann schwierig werden. Falls Sie bereits einmal vor dem Problem standen, diese eine bestimmte Version eines Sourcecode-Moduls zweifelsfrei zu identifizieren, die dieser einen bestimmten Anforderung in Bezug auf diese spezifische Produktvariante entspricht, wissen Sie welche Tücken dabei auftauchen können. Dieses Problem potenziert sich rasant bei der Erstellung von Berichten und Zertifizierungsdokumentationen, wie sie gerade in regulierten Märkten erforderlich sind. Zulassungsbehörden erwarten den lückenlosen Nachweis, dass die vorgestellte Variante des Produktes den Vorgaben der zuständigen Behörde entspricht. Der Ansatz, die Effizienz der Produktentwicklung durch Verwendung möglichst vieler gemeinsamer Komponenten zu steigern, kann leicht zu dramatisch erhöhtem Aufwand bei der Erstellung der Zulassungsdokumentation führen.

Während es für das Management von Varianten und Konfiguration in den frühen Phasen des Lebenszyklus seit Jahrzehnten erprobte Tools und Prozesse gibt, war die modellbasierte Systementwicklung lange eine Art „blinder Fleck“, da UML und SysML keine eingebauten Konstrukte für Varianten und Konfigurationen vorsahen. Jedoch gibt es seit einigen Jahren entsprechende Sprachelemente und ergänzende Profile, mit denen Variantenmanagement auch in der Modellierung durchgängig eingesetzt werden kann.

Bevor man sich für eine konkrete Ausgestaltung der Modellierung von Varianten entscheidet, gilt es grundsätzlich zu klären, welcher Typ von Varianten in einem Projekt erforderlich ist:

• Implementierungsvarianten sind Alternativen für die Realsierung einer bestimmten vorgegebenen Funktion, beispielsweise um Second-Source-Supplier zulassen zu können.
• Geographische Varianten sind Alternativen für die Lieferung in bestimmte Märkte, in denen unterschiedliche Marktanforderungen erfüllt werden müssen, beispielsweise Links- oder Rechtslenkung im Fahrzeug.
• Funktionale Varianten sind Alternativen für die Befriedigung unterschiedlicher Kundenbedürfnisse, beispielsweise verschieden konfektionierte Funktionsprofile für ein Infotainment-System im Fahrzeug.

Je nach Art des Systems können auch alle drei Typen von Varianten in Kombination vorkommen. Im Hinblick auf die Erwartungen an das Variantenmanagement auf Modell-Ebene empfehlen sich unterschiedliche Alternativen. In dieser und den folgenden Ausgaben unserer Technologie- und Produktnews betrachten wir diese Optionen für das Variantenmanagement mit IBM Rhapsody:

1. Nutzung der eingebauten Funktionen
2. Nutzung eines speziellen Profils wie z.B. VAMOS von Tim Weilkiens
3. Nutzung eines Third-Party Werkzeugs am Beispiel pure::variants

Für die Option (I) bietet IBM Rhapsody seit einigen Jahren Unterstützung für die Modellierung von Varianten mittels VariationPoint. Damit erhält der Anwender eine einfache Möglichkeit, direkt in IBM Rhapsody Variationen auf Basis des Core Modells zu spezifizieren. Für einen VariationPoint werden in Rhapsody Varianten (Variant) auf der Ebene von Klassen und Blöcken definiert, und für diese Varianten kann auch entsprechender Source Code generiert werden. Die Konfiguration, also die Auswahl einer konkreten Variante wird immer über eine gesamte Komponente vorgenommen, indem dort für jeden VariationPoint genau eine Variante ausgewählt wird; eine komplexere Konfiguration wird nicht unterstützt. Wenn Projekte klein sind, bzw. die Variantenbildung nicht sehr komplex ist ist dies völlig ausreichend. Je nach konkreter Aufgabe, Komplexität und Größe des Projekts kann diese Einschränkung die Übersichtlichkeit beeinträchtigen. Insbesondere lassen sich mehrere Varianten mit unterschiedlichen Abhängigkeitsbeziehungen mit dieser Implementierung nicht modellieren und werden bei der Konfiguration nicht unterstützt.