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

Was bisher geschah:

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. Den Überblick darüber zu behalten, welche Artefakte in den verschiedenen Phasen zu einer bestimmten Variante gehören, kann schwierig werden. Im ersten Teil haben wir betrachtet, wie ein VariationPoint mit IBM Rhapsody für modellbasiertes Variantenmanagement genutzt werden kann. Falls Sie noch einmal nachlesen möchten, hier finden Sie Teil 1 unserer Serie.

In Part 2 stellen wir Ihnen heute vor, wie mit Hilfe von spezialisierten Profilen das Variantenmanagement auf UML Modellebene realisiert werden kann. Grundsätzlich bietet ein spezielles Profil umfassende Möglichkeiten für die maßgeschneiderte Anpassung auf eine konkrete Domäne. Für jede Domäne kann es unterschiedliche Notwendigkeiten geben, wie Varianten definiert und konfiguriert werden sollen. Es gibt möglicherweise Interdependenzen zwischen verschiedenen Varianten oder es gilt, spezifische Varianten in Abhängigkeit von einem Zielkundensegment auszuwählen.

Mit einem individuellen Profil können diese Notwendigkeiten abgebildet werden, und zwar exakt so wie erforderlich und ohne unnötigen „Ballast“, der für diese Domäne nicht erforderlich ist. Damit erhalten wir ein perfekt angepasstes Metamodell, das präzise auf die Erfordernisse der Domäne zugeschnitten ist. Idealerweise reflektiert dieses Metamodell auch den anzuwendenden Prozess für Definition, Implementierung und Konfiguration der Varianten, sodass Overhead und Reibungsverluste in der Entwicklung minimiert werden.

Ein weiterer Vorteil dieses Ansatzes besteht in der UML Konformität des Metamodells. Da ausschließlich Mechanismen und Sprachelemente des UML Standards genutzt werden, kann dieses Profil mit jedem Standardkonformen UML Tool genutzt werden.

Es gibt bereits öffentlich verfügbare Profile für Variantenmanagement, die zum Download bereitstehen. Ein Beispiel ist das VAMOS Profil von Tim Weilkiens, das spezifisch für Variantenmanagement im Systems Engineering ausgelegt ist. Konkret stellt VAMOS eine Untermenge des SYSMOD Profils von Tim Weilkiens dar, und er stellt es auf seiner Webseite als Cameo Datei zur Verfügung: mbse4u.com/download/ (SYSMOD-Profile XML 4.2 (Cameo export))

Das Profil kann dann über die eingebaute Importfunktion in IBM Rhapsody importiert werden:

Das zugrundeliegende Konzept für das VAMOS-Profil beinhaltet die Elemente „Core“, „Variants“ und „Configurations“. Dabei stellt „Core“ das Basismodell dar, das mit Hilfe von VariationPoints in Varianten differenziert wird, welche dann durch entsprechende „Configurations“ ausgewählt werden für ein konkretes Endprodukt (Deliverable). Diese Abbildung verdeutlicht den Zusammenhang der Elemente sowie ihre Beziehungen untereinander und wird detailliert erläutert in dem Dokument “Variant Modeling with SysML” von Tim Weilkiens:

Quelle:  Variant Modeling with SysML, Tim Weilkiens, S. 4 

Dabei verwenden wir den Begriff „Configurations“ hier ausschließlich innerhalb des Rahmens einer vollständig modellbasierten Abbildung und Konfiguration von Varianten. Den größeren Kontext der Einbettung von modellbasiertem Variantenmanagement in Global Configurations Szenarien werden wir in einer der nächsten Ausgaben dieser Serie betrachten.

Am Beispiel einer Anwendung aus dem Smarthome-Bereich lässt sich verdeutlichen, wie sich zwei verschiedene Varianten mit Hilfe des VAMOS Metamodells darstellen lassen, und wie sich die Architektur verändern kann in Abhängigkeit von der gewählten Variante. Es geht um einen Regensensor und das auswertende Modul, das aus den Daten des Regensensors herleitet, ob ein offenstehendes Fenster geschlossen werden soll.

In der Variante 1 liefert der Sensor selbsttätig in regelmäßigen Abständen seine Messdaten an das auswertende Modul RainDetection, das in Abhängigkeit von den gelieferten Daten ggfs. die Schließung des Fensters veranlasst:

In der Variante 2 wird ein Regensensor eingesetzt, der nicht automatisch seine Messdaten weitergibt, sondern nur auf Anfrage. Die Variante bezeichnet diesen Sensor als „PolledStation“ und variiert per Generalisierung den VariationPoint „Sensor“. Diese Variante erfordert auch eine andere auswertende Einheit „PollingRainDetection“ sowie eine Variante für die Schnittstelle zwischen PolledStation und PollingRainDetection: „IPolledRain“.

Im Statechart von „PollingRainDetection“ unterscheiden sich die beiden Varianten nur geringfügig. Es muss lediglich die Abfrage des Regensensors ergänzt werden, alle anderen Abläufe bleiben identisch mit dem ursprünglichen Core Modell. Besonders hervorzuheben ist hier der komfortable Umgang mit Rhapsody Statecharts bei der Nutzung von Generalisierung. Das Statechart von „PollingRainDetection“ übernimmt vollständig die Inhalte von „RainDetection“ und kann lediglich partiell modifiziert werden.

In Teil 1 haben wir drei Kategorien von Varianten identifiziert, die oft in Entwicklungsprojekten berücksichtigt werden müssen:

Implementierungsvarianten sind Alternativen für die Realisierung 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. Die hier beschriebene Option, das Variantenmanagement mit Hilfe des speziellen UML Profils VAMOS zu realisieren, eignet sich insbesondere für anspruchsvolles Variantenmanagement, bei dem die Varianten Prozess- und Methodengerecht vollständig im Modell abgebildet werden sollen. Diese Lösung ist hochgradig anpassbar und nutzt dabei die nativen Mittel der UML/SysML. Sie ist somit unabhängig von Toolherstellern, kostet jedoch den initialen Aufwand der Erstellung eines geeigneten Profils. Dafür erhält man ein präzise zugeschnittenes Metamodell, das ohne unnötigen "Ballast" individuell für die Domäne optimiert ist.

Falls Sie sofort loslegen möchten und selbst erfahren möchten, wie sich dieser Ansatz für Variantentenmanagement konkret in IBM Rhapsody handhaben lässt – hier finden Sie ein fertiges Modell zum Herunterladen und Ausprobieren:  https://download.willert.de/downloads/sample-uml-model-with-variant-management-for-use-with-ibm-rhapsody/ 

In den nächsten Ausgaben betrachten wir die weiteren Optionen für Variantenmanagement mit IBM Rhapsody – stay tuned! 

Hier gehts zu Teil 3