Share ZU:
10 September 2013 @ Karsten Krennrich

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 10: Variabilität und Use Case Beschreibungen

This entry is part 10 of 13 in the series Produktlinien

Im letzten Teil der Blog Reihe haben wir uns mit der Abbildung von Produktvariabilität mit Hilfe eines Feature Modells beschäftigt. Heute wollen wir uns ansehen wie man mittels Use Case Beschreibungen die Variabilität innerhalb einer Produktlinie beherrschen kann.Aufgrund der sehr stark differenzierenden Möglichkeiten zur Abbildung von Variabilität in Use Case Diagramme und Use Case Beschreibungen, werden wir hier zunächst nur Use Case Beschreibungen betrachten. Im folgenden Teil der Blog Reihe werden wir dann gesondert auf Use Case Diagramme eingehen.

In [1] werden zwei Möglichkeiten beschrieben wie Variabilität mittels Use Case Beschreibungen abgebildet werden kann. Diese beiden Möglichkeiten, „Zwei Ebenen Use Case Beschreibung“ und „Ein Ebenen Use Case Beschreibung“ möchten wir hier gerne aufgreifen und diskutieren:

 

1)      „Zwei Ebenen Use Case Beschreibung“

Diese  Art der Use Case Beschreibung setzt sich aus den folgenden zwei Beschreibungsebenen zusammen:

  1. Ebene: Die „Produktebene“: Sie beschreibt die Abläufe innerhalb eines Use Cases und enthält „Tags“, welche Platzhalter für die variablen Inhalte darstellen und bei der Entwicklung eines spezifischen Produkts instantiiert werden müssen.
  2. Ebene: Die Produktlinienebene“: Sie beschreibt die Variabilitäten, welche die „Tags“ aus der 1. Ebene bei einer Produktinstantiierung ersetzen.

Schauen wir uns dazu direkt ein Beispiel an (die Inhalte der Use Case Beschreibung haben wir dazu auf die wesentlichen Inhalte reduziert; die o.g. „Tags“ sind an den geschweiften Klammern zu erkennen):

  1. Ebene (Produktebene)
USE CASE Weckzeit einstellen
Ziel Die zu weckende Person stellt eine Weckzeit ein.
Aktor Zu weckende Person
Der {[V1]} Wecker (System)
Beschreibung 1. Die zu weckende Person drückt {[V2] Taste}.
2. Der {[V1]} Wecker zeigt die aktuell eingestellte Weckzeit im Display an.
3. Die zu weckende Person stellt die Weckzeit über die Tasten „+“ und „-“ ein und bestätig sie mit der {[V2] Taste}.
4. Der {[V1]} Wecker zeigt im Display die Weckrufmöglichkeit Signalton und {[V3]} an.
5. Die zu weckende Person wählt den Weckruf über die Tasten „+“ und „-“ aus und bestätigt ihn mit der {[V2] Taste}.
6. Der {[V1]} Wecker speichert die Weckzeit.
7. Der {[V1]} Wecker zeigt die Uhrzeit im Display an.

2 . Ebene (Produktlinienebene)

V1: Alternative
V1:      1  XT2
2  YT3

V2: Alternative
V2:      if V1=1 then A Taste
If V1=2 then B Taste

V3: Option
V3:      Radio (als Weckruf)

Der „Tag“ V1 wird bei der Produktinstantiierung entweder durch die Systembezeichnung „XT2“ oder „YT3“ ersetzt. Aus der Entscheidung der ersten Alternative V1 wird direkt die Alternative für „Tag“ V2 bestimmt, da die Alternativen aus V2 von V1 abhängig sind. Der dritte „Tag“ V3 kann optional noch mit der Funktion das Radio als Weckruf nutzen zu können belegt werden.

 

2)      „Ein Ebenen Use Case Beschreibung“

Diese Art der Use Case Beschreibung besteht nur aus einer beschreibenden Ebene. Sie vereinigt dabei die Produktlinienanforderungen und deren Variabilitäten mit den Produktanforderungen in der Use Case Beschreibung.

Auch hierzu ein Beispiel:

USE CASE Weckzeit einstellen
Ziel Die zu weckende Person stellt eine Weckzeit ein.
Aktor Zu weckende Person
Der XT2 – YT3 Wecker (System)
Beschreibung 1. XT2 Wecker: Die zu weckende Person drückt Taste A.
YT3 Wecker: Die zu weckende Person drückt Taste B.
2. Das System zeigt die aktuell eingestellte Weckzeit im Display an.
3. XT2 Wecker: Die zu weckende Person stellt die Weckzeit über die Tasten „+“ und „-“ ein und bestätig sie mit der Taste A.
YT3 Wecker: Die zu weckende Person stellt die Weckzeit über die Tasten „+“ und „-“ ein und bestätig sie mit der Taste B.
4. XT2 Wecker a): Das System zeigt im Display die Weckrufmöglichkeit Signalton an.
XT2 Wecker b): Das System zeigt im Display die Weckrufmöglichkeit Signalton und Radio an.
YT3 Wecker a): Das System zeigt im Display die Weckrufmöglichkeit Signalton an.
YT3 Wecker b): Das System zeigt im Display die Weckrufmöglichkeit Signalton und Radio an.
5. XT2 Wecker: Die zu weckende Person wählt den Weckruf über die Tasten „+“ und „-“ aus und bestätigt ihn mit der Taste A.
YT3 Wecker: Die zu weckende Person wählt den Weckruf über die Tasten „+“ und „-“ aus und bestätigt ihn mit der Taste B.
6. Das System speichert die Weckzeit.
7. Das System zeigt die Uhrzeit im Display an.

 

Ein Vergleicht der beiden unterschiedlichen Use Case Beschreibung zeigt folgendes:

Die „Ein Ebenen Use Case Beschreibung“ ist für Produktlinien geeignet, die bereits einen sehr „reifen“ Zustand haben und somit aller Wahrscheinlichkeit nach, nicht mehr sehr stark weiterentwickelt bzw. verändert wird.

Im Gegensatz dazu ist die „Zwei Ebenen Use Case Beschreibungen“ mit weniger Aufwand zu verändern oder weiterzuentwickeln und somit vorteilhaft für Produktlinien, die sich gerade im Aufbau befinden oder aufgrund von Rahmenbedingungen häufigen Veränderungen unterliegen. Insbesondere dann, wenn die Variationen, die in Produktlinienebene gepflegt werden, verändert oder ergänzt werden.

Es zeigt sich also, dass für Produktlinien und deren Produkte, je nach Situation, unterschiedliche Use Case Beschreibungsmöglichkeiten besser oder weniger gut geeignet sein können.

Im nächsten Teil werden wir uns wie zu Beginn angekündigt der Beschreibung von Variabilität mit Hilfe von Use Case Diagrammen annehmen.

Quellen:

[1]        Paper: A. Bertolino, A. Fantechi, S. Gnesi, G. Lami, A. Maccari: Use Case Description of Requirements for Product Lines

Series Navigation<< Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 9: Retrospektive: Komplexität der Variabilität beherrschenKosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 11: Variabilität und Use Case Diagramme >>

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.