Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 12: Variabilität und Feature Graphen

In diesem Teil der Blog Reihe möchte ich gerne auf Feature Graphen und deren Möglichkeiten zur Abbildung von Variabilität aus Produktlinien eingehen.

Im 9. Teil der Blog Reihe haben wir uns mit der Notation eines Feature Model beschäftigt. Feature Graphen sind diesen sehr ähnlich. Da sie aber beide sehr häufig in der Literatur genannt werden und sich in ihrer Notation unterscheiden, möchte ich auch hier gesondert Feature Graphen betrachten und an einem Beispiel erläutern. Features werden bei der „Feature Orientierten Domänen Analyse“ (FODA) genutzt, um Variabilität der Produktlinie im Zuge der Domänenanalyse zu beschreiben (siehe [2]).

Die folgende Abbildung zeigt ein Feature Model mit der Notation, die auch in [1] verwendet wurde:

Abbildung 1: Beispiel für ein Feature Graph

Das Beispiel zeigt, dass die Systemanforderungen wie in einem Feature Model hierarchisch als Features, Sub-Features und deren Abhängigkeiten in einer Baumstruktur  beschrieben sind.

Das Beispiel spezifiziert den Wecker, den wir bereits im 9. Teil beschrieben haben:
Er besitzt eine Zeitanzeige und ein Batteriefach. Optional kann der Wecker auch mit einem Radio ausgestattet sein. Ein Radio erfordert allerdings ein Batteriefach für sechs Batterien. Die Zeitanzeige kann entweder rote oder blaue Schrift haben. Hat der Wecker ein Radio, so kann keine blaue Schrift für die Zeitanzeige gewählt werden.

Das Beispiel zeigt weiter, dass Abhängigkeiten mit der graphischen Notation nur zwischen Features mit dem gleichen direkten Elternfeature abgebildet werden können. Um Abhängigkeiten und Einschränkungen zwischen Features unterschiedlicher direkter Elternfeatures beschreiben zu können, müssen textuelle Regeln definiert und dem Feature Graph beigefügt werden.

Genauso wie ein Feature Model ist auch ein Feature Graph im Vergleich zu textuellen Beschreibungen einfach zu verstehen und eignet sich zur Abbildung der Domäne einer Produktlinie.

Im nächsten Teil möchte ich gerne noch weitere UML Notationen in Bezug auf ihre Möglichkeiten zur Modellierung von Variabiliät von Produktlinien diskutieren.

Quellen:

[1]        Paper: Thomas von der Maßen, Horst Lichter: Modeling Variability by UML Use Case Diagrams

[2]        Kyo Kang et al. Feature Oriented Domain Analysis (FODA) Feasibility Study. Technical report CMU/SEI-90-TR-021, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2000.

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.