Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 13: Variabilität in UML

Wie im letzten Blog Nummer 12 angekündigt werden wir in diesem Teil die UML in Bezug auf Abbildung von Variabilität betrachten.

In den Teilen 10 und 11 sind wir bereits auf Use Cases eingegangen. Heute wollen wir die folgenden weiteren UML Diagramme untersuchen:

1. Klassendiagramme
2. Sequenzdiagramme

Klassendiagramme
In Klassendiagrammen können Stereotypen dazu verwendet werden um Variabilität abzubilden.

Hierzu direkt unser Beispielsystem „Wecker“ durch ein Klassendiagramm beschrieben:

Abbildung 1: Beispiel für ein Klassendiagramm

Über die Stereotypen, die in einem Klassendiagramm frei verwendet werden können lassen sich somit variable statische Eigenschaften von Systemen beschreiben. In unserem Beispiel ist das Radio als optionale Systemkomponente abgebildet.

Sequenzdiagramme
Stellen wir uns nun die Frage, wie variables Systemverhalten abgebildet werden kann. In [1] werden Sequenzdiagramme als Möglichkeit beschrieben dies zu tun. Im Urzustand besitzen Sequenzdiagramme allerdings keine Elemente um variable Verhaltensweisen zu beschreiben. Aus diesem Grund müssen Elemente zur Beschreibung von Variationspunkten und optionalem Verhalten eingeführt werden. Schauen wir uns ein Sequenzdiagramm mit variablem Systemverhalten beispielhaft an:

Abbildung 2: Beispiel für ein Sequenzdiagramm

Das Beispiel zeigt, dass der Benutzer des Weckers (User) über die A-Taste zunächst die Weckzeit einstellen kann. Je nachdem, ob der Wecker mit einem Radio (der optionalen Komponente) ausgestattet ist oder nicht, kann er zusätzlich noch den Typ des Alarms (Klingelton oder Radio) auswählen und speichern. Bei einem Wecker ohne Radio würde das Systemverhalten aus dem gestrichelt umrandeten Teil des Sequenzdiagramms komplett entfallen.

Die beiden in diesem Blogbeitrag angeführten Beispiele zeigen, dass man mit Hilfe von UML-Diagrammen sowohl statische als auch dynamische Variabilitäten einer Produktlinieninfrastruktur abbilden kann.

Quellen:

[1]        Paper: Tewfik Ziadi, Loic Hélouet, Jean-Marc Jézéquel: Modeling behaviors in Product Lines

Karsten Krennrich

Kontaktieren Sie Karsten Krennrich

Herr Karsten Krennrich ist als Consultant der HOOD Group tätig. Seine Schwerpunkte liegen in der Beratung von Requirements Engineering (RE) orientierten Entwicklungsprozessen. Er ist als Projektleiter bei der HOOD Software Division verantwortlich für die Realisierung von Softwarelösungen im Bereich der Entwicklungsprozess unterstützenden Werkzeuge. Für diese Anpassungen und Erweiterung von Standard Werkzeugen erarbeitet Herr Krennrich auch die zur Realisierung notwendigen Konzepte. Bei deren Implementierung arbeitet Herr Krennrich unter anderem auch mit den Konfigurationsmanagement Werkzeugen CMSynergy und Subversion. Neben dem RM-Werkzeug DOORS® von IBM hat Herr Krennrich auch Praxiserfahrungen mit den Werkzeugen CaliberRM® von Borland und RequisitePro® von IBM. Er verfügt außerdem über Erfahrungen im Bereich Datenbanken und Informationssysteme, im Software Engineering und im Themenbereich Produktlinien.