Variantenmanagement mit SysML

Variantenmanagement ist ein großes Thema bei der Entwicklung von Produkten. Die Lösungen dazu sind vielfach noch bescheiden. Es gibt Ansätze, wie sich bspw. die Anforderungen verschiedener Produktvarianten in DOORS verwalten lassen, aber spätestens beim Design von Lösungen stößt man an Grenzen. Beim Pflegen verschiedener Lösungsskizzen fängt man sich Inkonsistenzen ein oder die Verwaltung ist schlicht unhandlich und lästig.

Während wir auf die Veröffentlichung der SysML 1.3 warten, sind sich die Experten einig, dass in Version 1.4 eine Lösung für Variantenmanagement einfließen soll. Sobald Toolhersteller nach Veröffentlichung des Standards dann Variantenmanagement in ihre Tools integrieren, wird das Handling extrem vereinfacht, so meine Vermutung. Einer der Lösungskandidaten für Variantenmanagement in SysML ist der Ansatz von Tim Weilkiens, den ich hier kurz vorstellen möchte.

Erweitern des Profils für Variantenmanagement

Wir definieren uns dafür ein paar Stereotypen wie folgt:

• «Variant» für ein Paket, das eine Variante zu einer bestimmten Variation enthält
• «Variation» für ein Paket, das eine oder mehrere Varianten eines bestimmten Aspekts enthält, bspw. Variation von Anforderungen, Variation von Struktur, Variation des Systemkontextes
• «Variation point» für das Element, das variiert wird. Es befindet sich in der Paket-Hierarchie des Kernsystems.
• «Variation element» für das variierte Element. Es befindet sich innerhalb eines «Variant»-Pakets

Wie man im Bild sieht, erweitern «Variation» und «Variant» die UML-Metaklasse Package. Somit sind die beiden Stereotypen auf Pakete anwendbar. Wie wir später sehen werden kennzeichnen wir mit «Variation» die Variation eines bestimmten Aspekts und mit «Variant» die darin enthaltenen Varianten dieses Aspekts.

Die Stereotypen «Variation point» und «Variation element» hingegen können angewandt werden auf jedes „PackageableElement“, also auf jedes benannte Element, das sich in einem Paket befindet. «Variation point» bezeichnet dabei das Element, das konkret variiert wird, «Variation element» kennzeichet die Variation eines solchen Elements.

Beispiel zur Variation der Struktur eines Systems

Haben wir unser Profil wie beschrieben erweitert, lassen sich nun beliebige Aspekte variieren. So könnte es verschiedene Varianten des Systemkontexts geben, da etwa – je nach Variante – unterschiedliche externe Systeme mit dem System kommunizieren. Pflegt man Anforderungen im SysML-Modell lassen sich auch Anforderungsvarianten modellieren. Oftmals wird man aber wohl Varianten der Struktur des Systems bilden, um zu zeigen, wie sich das System aus unterschiedlichen Komponenten oder Subsystemen zusammensetzt. Betrachten wir mal so einen Fall.

Definition des «Variation point»

In SysML modellieren wir strukturelle Eigenschaften von System mit Blöcken (Stereotyp «block»). Um zu zeigen, aus welchen Elementen ein Block besteht, modelliert man einen Produktbaum (oder Breakdown) des Blocks, indem man die innenliegenden Komponenten mit einer gerichteten Kompositionsbeziehung hinzufügt. Lassen Sie uns zunächst den Teil des Systems modellieren, der in jeder Variante vorkommt; wir nennen den Block System Core und modellieren das folgende Blockdefinitionsdiagramm.

Unser System Core besteht also aus den drei Blöcken Part A, Part B und Part C. Diese drei Teile sind in jeder Variante vorhanden, daher sind sie Teil des „Kernsystems“. Da wir gleich eine Variante mit weiteren Blöcken Part D und Part E hinzufügen wollen, geben wir dem Block System Core den Stereotyp «Variation point», denn dies ist der Punkt, den wir variieren wollen.

Wie die drei Parts des System Core miteinander kommunizieren kann man wie gewohnt in einem Internen Blockdiagramm des Blocks System Core darstellen. Das folgende Diagramm zeigt eine vereinfachte Darstellung ohne Ports.

Ein «Variation»-Paket mit diversen «Variant»-Paketen

Der Übersicht halber sollte man sämtliche Variationen auslagern in ein Paket „Variations“. So lassen sich Variationen verschiedener Aspekte geordnet verwalten. Wir behandeln hier eine Variation der Struktur des Systems, so dass wir ein Paket Structure Variation erstellen und diesem den Stereotypen «Variation» zuweisen, im Bild erkenntlich an der veränderten Darstellung des Paket-Symbols.

Wie man sieht, befinden sich in dem Paket Structure Variation verschiedene Varianten, die System Core mit zusätzlichen Blöcken erweitern sollen. Jede dieser Varianten-Pakete erhält zur Kennzeichnung den Stereotyp «Variant», wieder ersichtlich an einem eigenen Piktogramm für diesen Stereotyp.

Modellierung des «Variation element»

In so einem Varianten-Paket legt man nun ein weiteres Blockdefinitiondiagramm an, in dem wir den Produktbaum unserer Variante modellieren. Für System Variant X fügen wir zwei weitere Blöcke mit einer Kompositionsbeziehung zu: Part D und Part E. System Variant X und alle Parts dessen erhalten den Stereotyp «Variant element», um zu kennzeichnen, dass diese Blöcke nur Teil einer bestimmten Variante sind und nicht Teil des Kernsystems.

Und nun kommt der Trick: Wir lassen den Block System Variant X von dem zuvor modellierten Block System Core erben (siehe Bild). Somit erbt System Variant X auch alle Parts von System Core.

Erzeugt man nun ein Internes Blockdiagramm des Blocks System Variant X, erhält man nicht nur Part D und Part E, sondern durch die Vererbungsbeziehung auch die Parts des Variationspunktes System Core.

Auf diese Weise lassen sich nun Varianten mit unterschiedlichen Parts modellieren. Durch die Vererbungsbeziehung, erhält man für zumindest für Blöcke der SysML eine elegante Möglichkeit, Elemente eines für alle Varianten geltenden Kerns wieder zu verwenden.

Für alle Modellelemente, die nicht über eine Vererbungsbeziehung verfügen, bleibt derzeit nur die Möglichkeit, die Elemente des Kerns in die Diagramme der Varianten hineinzuziehen und mit dem «Variation element» explizit in Beziehung zu setzen.

Falls jemand weitergehende oder andere Erfahrungen gemacht hat mit der Modellierung von Varianten, freue ich mich über Ihren Kommentar.