Variabilität als eine eigenständige Sicht auf Produktlinien
Kim Lauenroth, Klaus Pohl Software Systems Engineering
Universität Duisburg-Essen Schützenbahn 70
45117 Essen
kim.lauenroth@sse.uni-due.de klaus.pohl@sse.uni-due.de
1 Einleitung
Die explizite Analyse und Modellierung von Variabilität ist neben der Aufteilung in Domain und Application Engineering das wesentliche Unterscheidungsmerkmal zwischen Produktlinienentwicklung und Einzelsystementwicklung (vgl. [PBL05]). In diesem Beitrag vertreten wir den Standpunkt, dass die Variabilität einer Produktlinie eine eigenständige Sicht darstellt und daher in einem eigenständigen Modell dokumentiert werden muss. Die eigenständige Dokumentation bietet für die Produktlinienentwicklung zahlreiche Vorteile, die wir in diesem Beitrag skizzieren.
2 Argumente für eine eigenständige Sicht
In der Literatur werden zwei Arten der Dokumentation von Variabilität unterschieden:
• Dieintegrierte Dokumentation von Variabilitätdokumentiert Variabilität innerhalb von Entwicklungsartefakten. Zahlreiche Typen von Entwicklungsartefakten unterstützen die Dokumentation von Variabilität mit Hilfe von Modellierungskonstrukten. Zum Beispiel bieten Use Cases hierzu optionale und alternative Abläufe an oder Klassendiagramme bieten hierzu Vererbungsmechanismen an. Artefakttypen ohne Mechanismen für Variabilität müssen entsprechend erweitert werden.
• Die orthogonale Dokumentation von Variabilität dokumentiert die Variabilität in einem eigenständigen Modell und damit unabhängig von konkreten Entwicklungsartefakten. Die Auswirkungen der Variabilität werden mit Hilfe von Beziehungen zu den Artefaktmodellen dokumentiert.
Die integrierte Dokumentation von Variabilität ist aus verschiedenen Gründen von Nachteil. Unter anderem ist die Variabilitätsinformation über verschiedene Modelle verstreut und Abhängigkeiten zwischen verschiedenen Artefakten (z.B. zwischen der Variabilität in den Use Cases und den Klassenmodellen) können nur schwierig dokumentiert und geprüft werden. Ebenfalls kann die Variabilität nur mit Hilfe der
Modelle kommuniziert werden, d.h. den Stakeholdern müssen die (teilweise sehr komplexen) Modelle der Produktlinie präsentiert werden. Schließlich besteht die Gefahr, dass die Variabilität der Produktlinie mit der Variabilität der Software verwechselt wird.
Dies wird im Folgenden genauer erläutert.
Produktlinienvariabilität bzw. Softwarevariabilität sind wie folgt definiert (vgl.
[MHPSS07]):
• Softwarevariabilitätbeschreibt die Fähigkeit eines Softwaresystems oder –artefakts angepasst, erweitert oder variiert zu werden. Zum Beispiel sind Plug-Ins für einen Webbrowser Formen von Softwarevariabilität.
• Produktlinienvariabilität beschreibt die Variation zwischen möglichen Produkten einer Produktlinie in Form von Eigenschaften oder Funktionen.
Software- und Produktlinienvariabilität können sehr leicht miteinander verwechselt werden, da beides Konzepte zur Variation darstellten. Allerdings bezieht sich die Softwarevariabilität auf die technische Sicht bzw. die Realisierung von Variationen wie sie durch verschiedene Artefakttypen bereits unterstützt wird (siehe oben, z.B. durch abstrakte Klassen, Vererbung und Schnittstellen in objektorientierter Entwicklung). Der zentrale Unterschied zwischen Software- und Produktlinienvariabilität besteht darin, dass die Definition von Produktlinienvariabilität eine explizite Entscheidung in der Produktlinienentwicklung erfordert, d.h. es muss explizit definiert werden, in welcher Weise die Produkte einer Produktlinie variieren. Die Realisierung von Produktlinienvariabilität wird dann durch Konzepte der Softwarevariabilität vorgenommen.
Um die Verwechselungsgefahr zwischen Software- und Produktlinienvariabilität zu minimieren und aufgrund der oben genannten Nachteile der integrierten Dokumentation von Variabilität vertreten wir den Standpunkt, dass die Variabilität einer Produktlinie in einem eigenständigen Modell dokumentiert werden muss.
3 Dokumentation der Variabilität in einem eigenständigen Modell
Zur eigenständigen Dokumentation von Produktlinienvariabilität schlagen wir das orthogonale Variabilitätsmodell (OVM, vgl. [PBL05]) vor. Das OVM unterscheidet die folgenden Konzepte:
• Variationspunkte beschreiben, was in einer Produktlinie variiert. Es werden obli- gatorische und optionale Variationspunkte unterschieden. Obligatorische Variations- punkte müssen betrachtet werden, optionale Variationspunkte können betrachtet werden.
• Varianten beschreiben, wie etwas in einer Produktlinie variiert, d.h. Varianten be- schreiben mögliche Ausprägungen einen Variationspunktes.
• Variabilitätsabhängigkeiten zwischen Variationspunkt und Variante beschreiben, welcher Weise eine Variante an einem Variationspunkt gewählt werden darf. Es
werden obligatorische, optionale und alternative Variabilitätsabhängigkeiten unterschieden.
• Bedingungsabhängigkeiten beschreiben Bedingungen in der Auswahl von Varianten und Variationspunkten. Es werden Erfordert- und Ausschlussabgängigkeiten unterschieden.
• Artefaktabhängigkeiten dokumentieren die Auswirkungen der Variabilität auf die Entwicklungsartefakte durch eine Beziehung zwischen Varianten und (Teilen von) Entwicklungsartefakten. Wenn eine Variante z.B. mit einer Anforderung in Beziehung steht, ist diese Anforderung nur dann für ein Produkt relevant, wenn die entsprechende Variante gewählt ist. Wenn ein Artefakt(teil) mit keiner Variante in Beziehung steht, handelt es sich um ein gemeinsames Artefakt (oder einen gemeinsamen Artefaktteil), der Bestandteil aller Produkte der Produktlinie ist.
schließt aus
VP
Fahrzeug- aufbau
Limousine
V
Cabriolet
V Sonnen-
dach
V Nav.-
system
V
VP
Sonder- ausstattung [1..1]
Art des Daches
Softtop
V
Hardtop
V
[1..1]
erfordert schließt aus
Variationspunkt (optional) Variationspunkt
(obligatorisch)
Variante
Optionale Variabilitäts- abhängigkeit
Alternative Variabilitäts- abhängigkeit
Bedinungs- abhängigkeit
VP
Abbildung 1: Beispiel für ein OVM
Abbildung 1 zeigt ein einfaches orthogonales Variabilitätsmodell für PKWs als Beispiel.
Es spezifiziert, dass ein Kunde den Fahrzeugaufbau und die Sonderausstattung entscheiden muss (beides obligatorische Variationspunkte). Der Kunde kann entweder Limousine oder Cabriolet wählen (alternative Abhängigkeit1). Wenn der Kunde ein Cabriolet wählt, muss er die Art des Daches entscheiden (optionaler Variationspunkt, verbunden mit der Variante Cabriolet durch eine Erfordert- Bedingungsabhängigkeit).
1Die Kardinalität in Form von „[1..1]“ gibt an, dass bei dieser Alternative mindestens eine und höchstens eine Variante gewählt werden darf. Andere Kardinalitäten sind ebenfalls möglich, z.B.: beschreibt „[0..2]“, dass keine oder höchstens zwei Varianten gewählt werden dürfen.
Gleichzeitig darf er kein Sonnendach als Sonderausstattung wählen (Ausschluss- Bedingungsabhängigkeit). Wenn der Kunde die Variante Limousine wählt, darf er die Art des Daches nicht entscheiden (Ausschluss- Bedingungsabhängigkeit).
Abbildung 2 zeigt ein Beispiel für Artefaktabhängigkeiten. Zum Beispiel ist die Variante Sonnendach über eine Artefaktabhängigkeit mit der Anforderung R-2. Damit ist diese Anforderung nur dann für ein Produkt zu erfüllen, wenn die Variante Sonnendach gewählt ist. Die Anforderung R-3 steht mit keiner Variante in Beziehung, damit muss diese Anforderung für alle Produkte der Produktlinie erfüllt werden (und damit hat jedes Fahrzeug eine Klimaanlage als Sonderausstattung).
R-2: Das Fahrzeug verfügt über ein Sonnendach … Sonnen-
dach
V Nav.-
system
V
VP
Sonder- ausstattung Artefakt-
abhängigkeit
R-3: Das Fahrzeug verfügt über eine Klimaanlage … R-1: Das Fahrzeug verfügt über
ein Navigationssystem …
Abbildung 2: Beispiel für Artefaktabhängigkeiten
4 Vorteile eines eigenständigen Variabilitätsmodells
Ein eigenständiges Variabilitätsmodell bietet unter anderem die folgenden Vorteile für die Produktlinienentwicklung (vgl. [PBL05]):
• Produktlinienvariabilität wird explizit dokumentiert: Durch ein eigenständiges Modell wir die Variabilität der Produktlinie explizit dokumentiert und als eigenständiges Artefakt verfügbar gemacht. Eine Verwechslung mit Softwarevariabilität wird damit ausgeschlossen.
• Dokumentation an einer zentralen Stelle: Durch die Dokumentation der Produktlinienvariabilität in einem eigenständigen Modell und durch die Beziehungen des Variabilitätsmodells zu den Entwicklungsartefakten wird erreicht, dass die Variabilität der Produktlinie in einem einzigen Modell zentral dokumentiert wird. Hierdurch wird ein unmittelbarer Überblick über die Variabilität der Produktlinie ermöglicht.
• Produktlinienvariabilität kann unabhängig von anderen Artefakten kommuniziert werden: Durch das eigenständige Modell kann die Variabilität der Produktlinie z.B.
einem Kunden vorgestellt werden, ohne detailliert auf andere Artefakte, wie z.B.
Anforderungen eingehen zu müssen.
• Explizite Entscheidung für Kunden: Durch die Dokumentation von Variationspunkten und Varianten werden alle für den Kunden notwendigen Entscheidungen und Entscheidungsalternativen zur Ableitung eines Produktes explizit dargestellt.
• Verbesserung der Nachvollziehbarkeit: Durch die Beziehungen der Artefakte zu den Varianten des Variabilitätsmodells wird zum einen die Nachvollziehbarkeit zwischen den Artefakten innerhalb eines Entwicklungsschrittes als auch die Nachvollziehbarkeit von Artefakten über mehrere Entwicklungsschritte hinweg verbessert.
5 Zusammenfassung und Ausblick
In diesem Beitrag haben wir argumentiert, dass die Variabilität einer Produktlinie eine eigenständige Sicht benötigt. Zur Dokumentation dieser eigenständigen Sicht haben wir das orthogonale Variabilitätsmodell vorgestellt und die Vorteile der eigenständigen Sicht erläutert.
Abbildung 3: Prototypisches Werkzeug zur orthogonalen Variabilitätsmodellierung
Aktuell entwickeln wir eine prototypische Werkzeugumgebung, die sowohl das ortho- gonale Variabilitätsmodell unterstützt, als auch die Modellierung von Produktlinien- artefakten, insbesondere Anforderungen (z.B. Zielmodelle, Use Cases und Datenmodelle) oder Architekturbestandteile (z.B. Komponentenmodellen, Automaten- modellen oder Message Sequence Charts) und Testartefakte. Ein Screenshot des Prototyps ist in Abbildung 3 dargestellt.
Des Weiteren bearbeiten wir z.B. die frühe Qualitätssicherung der Produktlinienvaria- bilität in der Domänenentwicklung und untersuchen u.a. Ansätze zur Konsistenzprüfung von Domänenanforderungen (vgl. hierzu z.B. [LP08]).
Literaturverzeichnis
[LP08] Lauenroth, K.; Pohl, K.: Dynamic Consistency Checking of Domain Requirements in Product Line Engineering. In Proceedings of the 16th International Requirements Engineering Conference, 2008.
[MHPSS07] Metzger, A.; Heymans, P.; Pohl, K.; Schobbens, P.-Y.; Saval, G.:
Disambiguating the Documentation of Variability in Software Product Lines. In Proceedings of the 15th International Requirements Engineering Conference, 2007, S. 243-253.
[PBL05] Pohl, K.; Böckle, G.; van der Linden, F.: Software Product Line Engineering – Foundations, Principles, and Techniques. Springer, Heidelberg, 2005.
