Beim Modellieren von Use Cases ist es gute Praxis, die essentiellen Schritte textuell zu notieren, die die Durchführung des Use Cases detaillieren (siehe auch hier, Abschnitt 2.4.2). Nach der Identifizierung der essentiellen Schritte erzeugt man dann eine Aktivität zu dem Use Case, die diesen in einem Aktivitätsdiagramm beschreibt. Die Aktionen des Aktivitätsdiagramms leiten sich aus den zuvor identifizierten Schritten ab.

Zur Beschreibung der Essenzschritte nutzt man in Modellierungstools meist eine Notiz, die am Use Case hängt. Bei der Verfeinerung des Use Cases durch ein Aktivitätsdiagramm gerät man dann in die Problematik, dass man die Benennung und Reihenfolge der Aktionen mit der textuellen Beschreibung der Essenzschritte konsequent halten muss. In der Regel löscht man die Essenzschritte, sobald das zum Anwendungsfall modellierte Aktivitätsdiagramm den Informationsgehalt vollständig abdeckt.

Seit MagicDraw 17.0.3 gibt es nun einen Szenario-Editor, der es erlaubt, die Schritte (inkl. Entscheidungen) zu einem Use Case zu beschreiben. MagicDraw erstellt daraus dann automatisch das zugehörige Aktivitätsdiagramm. Wenn man nicht zu wild modelliert, führt MagicDraw sogar Änderungen im Aktivitätsdiagramm zurück in die Beschreibung der Schritte im Szenario-Editor.

use-case-scenario-editor

Nett wäre, wenn dieser Editor auch für Aktivitätsdiagramme direkt und auch für die Beschreibung von SysML-Testcases zur Verfügung stände. Ein entsprechender Feature Request bei Nomagic ist bereits erstellt ;-)

, , , ,

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

Stereotypen für Variantenmanagement in SysML

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.

Das Kernelement besteht aus drei Teilen

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.

Internes Blockdiagramm System Core

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.

Paketstruktur der Elemente

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.

Zusätzliche Parts der Variante X

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.

Detailmodellierung der Variante

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.

, , ,

No Magic, Hersteller des Modellierungstools MagicDraw, hat Service Pack 3 veröffentlicht mit folgenden Änderungen:

  • Das API für das Merge-Plugin ist nun frei verfügbar.
  • Generic Tables können nun als HTML-Tabellen exportiert werden.
  • Funktionalitäten bzgl. Darstellung und Refactoring sind nun per API für Plugins zugänglich.
  • Performance-Verbesserungen beim Aktualisieren von TeamWork-Server-Projekten.