Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien

Transkript

1 Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien Christoph Oberhokamp Franz-Hitze Str. 27, Paderborn co1@upb.de Abstract. Software-Produktlinien (SPL) umfassen mehrere individuelle Ausprägungen eines Softwareproduktes, die auf Basis einer gemeinsamen Plattform entwickelt werden. Um die Unterschiede zwischen den einzelnen Produkten ausdrücken zu können, werden Teile der gemeinsamen Plattform als variabel definiert. Das Verwalten und die Verfolgbarkeit (Traceability) dieser Variabilität stellt eine große Herausforderung dar. Da bei einer Software-Produktlinienentwicklung Variabilität in allen Entwicklungsartefakten und über den gesamten Entwicklungszyklus hinweg vorkommt, ist die Verfolgbarkeit dieser eine komplexe Aufgabe. Diese Seminararbeit gibt einen Überblick über das Problem der Verfolgbarkeit von Variabilität in Software-Produktlinien und stellt ausgewählte Ansätze zur Lösung des Problems vor. Keywords: Software-Produktlinien, Variabilitätsmanagement, Verfolgbarkeit, Traceability, Tracing 1 Einleitung Da der Markt heutzutage Software-Produkte fordert, die nach immer kürzeren Release-Zyklen und zu möglichst niedrigen Entwicklungskosten zur Verfügung stehen, wird in der Entwicklung ein hohes Maß an Effizienz und Flexibilität benötigt. Mit Hilfe des Entwicklungsparadigmas Software-Produktlinien sollen genau diese Anforderungen erfüllt werden. Die Software-Produktlinienentwicklung basiert auf der geplanten, strategischen, systematischen und somit pro-aktiven Wiederverwendung von Software-Artefakten. Im Vergleich zur Entwicklung von Einzel-Software- Systemen erlaubt dies eine Senkung der Entwicklungskosten und eine Verkürzung der Entwicklungszeit bei gleichzeitiger Steigerung der Qualität [21]. Eine Software-Produktlinie wird basierend auf den Gemeinsamkeiten und Unterschieden, die zwischen ähnlichen Produkten existieren, entwickelt. Die Gemeinsamkeiten definieren dabei die Eigenschaften, die zwischen den Produkten gleich sind, während die Unterschiede variable Eigenschaften der Produkte beschreiben. Diese Variabilität innerhalb einer SPL muss explizit definiert und verwaltet werden. Dabei muss Sie auf unterschiedlichen Abstraktionsebenen und über alle generischen Ent- 1

2 wicklungsartefakte, wie zum Beispiel Anwendungsfallbeschreibungen mit Variabilität, verwaltet werden. Hierbei spielt die Verfolgbarkeit der Variabilität eine wesentliche Rolle. Eine gute Verfolgbarkeit verbessert die Verständlichkeit eines Systems und trägt zu einer vereinfachten Wartbarkeit und Evolution einer Software- Produktlinie bei [2]. Die vorliegende Arbeit gliedert sich in fünf Kapitel. Kapitel 2 gibt zunächst eine Einführung in die grundlegenden Eigenschaften und den Entwicklungsprozess des Entwicklungsparadigmas Software-Produktlinie. Im darauf folgenden Kapitel 3 wird der Begriffe des Variabilitätsmanagements im Kontext einer Software-Produktlinienentwicklung näher betrachtet und eine Einordnung der Verfolgbarkeit von Variabilität in die Anforderungen an einen allgemeingültigen Variabilitätsmanagement-Ansatz vorgenommen. Anschließend wird im Kapitel 4 das Grundproblem der Verfolgbarkeit von Variabilität in Software-Produktlinien erläutert und zwei ausgewählte Ansätze zur Lösung des Problems vorgestellt und bewertet. Kapitel 5 fasst die Ergebnisse dieser Arbeit zusammen und gibt einen Ausblick auf zukünftige Arbeitsfelder in Bezug auf das behandelte Thema. 2 Software-Produktlinien Produktlinien werden in der Literatur, zum Beispiel in [7], als das dominante Software-Entwicklungsparadigma des 21. Jahrhunderts bezeichnet. Der grundlegende Gedanke besteht darin, mehrere Software-Produkte aus möglichst vielen gemeinsamen Teilen zu entwickeln, damit der Entwicklungsaufwand für diese Teile nur einmal geleistet werden muss. Gleichzeitig besitzt jedes Produkt spezifische Teile, die für das jeweilige Produkt charakteristisch sind. Die so entwickelten, ähnlichen Software-Produkte sind für eine bestimmte Domäne wie zum Beispiel Informationssysteme (CRM-Systeme, ERP-Systeme) oder eingebettete Systeme (Kfz-, Schiffsund Flugzeugelektronik, Telekommunikation) vorgesehen. Durch die konsequente Wiederverwendung von Entwicklungsartefakten wie Anforderungen, Spezifikationen, Architekturbeschreibungen, Quellcode und Testfälle können Entwicklungskosten gespart, die Software-Qualität erhöht und die Time-to-Market verkürzt werden [21]. Clements & Northrop vom Software Engineering Institute der Carnegie Mellon University definieren eine Software-Produktlinie wie folgt: Software-Produktlinie (software product line) A software product line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way [8]. Die Abbildung 1 zeigt den Entwicklungsprozess einer SPL von Pohl et al. [21]. Der wichtigste Unterschied zu anderen Entwicklungsprozessen ist die Aufteilung in einen Plattform- und einem dazu korrespondierenden Produkt-Entwicklungsprozess. 2

3 Beide Prozesse umfassen die Phasen Analyse, Design, Realisierung und Testen. Entwicklungsartefakte, die im Plattform-Entwicklungsprozess entwickelt werden, beinhalten variable Teile (schwarz und grau). Abbildung 1 Software-Produktlinen Entwicklungsprozess (abgewandelt aus [21]) Bei der Entwicklung (Ableitung) eines Produktes aus der Plattform wird die Variabilität in den Entwicklungsartefakten der Plattform gebunden. Das heißt, es wird eine konkrete Auswahl aus den variablen Elementen getroffen. In der Beispielabbildung ist das schwarze Artefakt in der Plattform Analyse Teil eines abgeleiteten Produktes, während das graue es nicht ist. Die Auswahl wirkt sich sukzessive auf alle Entwicklungsphasen und die darin enthaltenen Artefakte wie Klassen, Komponenten und Testfälle aus. Die Entwicklung von Produkten im Rahmen einer Software-Produktlinie stellt jedoch hohe Ansprüche an den Entwicklungsprozess, das technische und organisatorische Management sowie an die Personen, die an der Entwicklung beteiligt sind [8]. Die Abhängigkeiten der variablen Teile in verschiedenen Entwicklungsphasen müssen erkannt und verwaltet werden. Das zentrale Konzept für die Definition und Dokumentation der Variabilität einer Software-Produktlinie sind Variationspunkte und Varianten. Ein Variationspunkt spezifiziert, was variieren kann. Eine Variante definiert eine konkrete Variation. In der Produktentwicklung werden die Variationspunkte gebunden, indem die Varianten, die den anwendungsspezifischen Anforderungen entsprechen, ausgewählt werden [15]. Weitere Details über den Software-Produktlinien-Ansatz und seinem Entwicklungsprozess sind in [8], [21] und [6] zu finden. 3

4 3 Variabilitätsmanagement in Software-Produktlinien Um den vollen Nutzen einer Software-Produktlinie zu erhalten, müssen die Variabilität und insbesondere die Variationspunkte und deren Beziehungen zueinander in einer angemessenen und konsistenten Art über den gesamten Softwareentwicklungsprozess hinweg verwaltet werden [4]. Dies bedeutet, dass unabhängig von der Abstraktionsebene und unabhängig von der Entwicklungsphase die Variabilität in einer einfachen Art und Weise, am besten mit einem allgemeingültigen Ansatz, gemanagt werden sollte. Nach Berg und Muthig [3] sollte ein allgemeingültiger Ansatz für das Variabilitätsmanagement in Software-Produktlinien vier wichtige Charakteristika erfüllen. Der Ansatz sollte konsistent und skalierbar sein, er sollte eine gute Verfolgbarkeit zwischen Variationspunkten auf verschiedenen Abstraktionsebenen und durch alle Entwicklungsphasen hindurch ermöglichen und er sollte eine Möglichkeit bieten, Variabilität zu visualisieren: Konsistenz: Durch eine Standardisierung können Konfusionen und einem fehlerhaften Gebrauch des Ansatzes vorgebeugt werden. Deshalb sollte die Variabilität auf den verschiedenen Abstraktionsebenen und in den verschiedenen Entwicklungsphasen gleich gehandhabt werden. Ein konsistenter Ansatz reduziert außerdem die Möglichkeit von Fehlern, die auftreten könnten, wenn verschiedene Methoden für das Managen der Variabilität auf unterschiedlichen Abstraktionsebenen benutzt würden. Skalierbarkeit: Die Variabilität muss leicht handhabbar sein, egal ob es sich um eine einzelne Komponente oder um ein komplexes System handelt. Es reicht dabei nicht aus, wenn eine Methode das Verwalten der Variabilität im kleinen Umfang ermöglicht, im größer werdenden Umfang aber zu komplex und nicht mehr handhabbar wird. Verfolgbarkeit: Variabilität auf verschiedenen Abstraktionsebenen und in verschiedenen Entwicklungsphasen steht im Zusammenhang zueinander. Diese Zusammenhänge müssen miteinander verknüpft werden. Durch eine angemessene Verwaltung dieser multi-dimensionalen Beziehungen können die Wartbarkeit und die Evolution einer Software-Produktlinie vereinfacht werden. Visualisierung: Eine Visualisierung der Variabilität und der Abhängigkeiten zwischen Produkten in einer Produktlinie ermöglicht einen Überblick über die Zusammenhänge und fördert somit die Verständlichkeit und Wartbarkeit der Software-Produktlinie. Der Fokus in dieser Seminararbeit liegt auf der Verfolgbarkeit im Kontext eines solchen universellen Variabilitätsmanagement-Ansatzes. 4

5 4 Verfolgbarkeit von Variabilität in Software-Produktlinien Bei der Entwicklung von Einzelsystemen wird die Entscheidung, ob eine bestimmte Eigenschaft in einem Produkt vorhanden sein soll oder nicht, während der Anforderungs- oder Analysephase getroffen und das Produkt basierend darauf entwickelt. Bei der Entwicklung von Software-Produktlinien wird diese Entscheidung so lange wie möglich hinausgezögert, mindestens bis zu dem Punkt, an dem es der Organisation den meisten Nutzen bringt [11]. Dies hat zur Folge, dass die Variabilität nicht nur in der Anforderungs- und Analysephase, sondern in allen Entwicklungsphasen von der Anforderungsanalyse bis hin zur Implementierung verwaltet werden muss [19]. Das Verwalten der Variabilität beinhaltet als einen zentralen Punkt die Verfolgbarkeit von Variabilität über den gesamten Entwicklungszyklus hinweg. Dabei kann gut eingeführte Verfolgbarkeit die Verständlichkeit einer Produktlinien und ihrer Produkt-Entwicklung verbessern und die Evolution und Wartbarkeit unterstützen [23]. 4.1 Verfolgbarkeit Als Verfolgbarkeit wird eine Verknüpfung verstanden, welche eine Relation oder Abhängigkeit zwischen Entwicklungsartefakten beschreibt, die während der verschiedenen Phasen des Software Engineerings entwickelt wurden [3]. Entwicklungsartefakte können dabei beispielsweise Anforderungsspezifikationen, Architekturbeschreibungen, Source Code und Testpläne sein. Beim Traditionellen Software Engineering (nicht SPL) werden zwei Arten von Verfolgbarkeit definiert: vertikale und horizontale Verfolgbarkeit [1]. Vertikale Verfolgbarkeit beschreibt Beziehungen zwischen Artefakten derselben Abstraktionsebene, wie zum Beispiel zwischen verwandten Anforderungen, zwischen Modellen oder zwischen Softwarekomponenten. Horizontale Verfolgbarkeit bezieht sich auf die Beziehungen zwischen verschiedenen Abstraktionsebenen, wie zum Beispiel zwischen den Anforderungen und der Implementierung. Zu diesen zwei Arten der Verfolgbarkeit kommt bei der Entwicklung von Softwareproduktlinien eine dritte Art hinzu, welche sich mit Variabilität und seinen Auswirkungen befasst [3]. Verfolgbarkeits-Verknüpfungen haben dabei ebenfalls eine vertikal und eine horizontale Ausprägung. Sie werden benötigt, um Variationspunkte zu ihren Varianten, Varianten untereinander, Variationspunkte untereinander, Entwicklungsartefakte zu Variationspunkten oder Varianten und Entscheidungen, die bei der Produktentwicklung getroffen wurden, zu den angebotenen Optionen der Plattformentwicklung in Verbindung zu setzen [1]. Die Abbildung 2 veranschaulicht die Verfolgbarkeit von Variabilität am Beispiel des klassischen V-Modells [5]. Der Vollständigkeit halber sei erwähnt, dass eine weitere Dimension an Verfolgbarkeit entsteht, wenn das Konfigurationsmanagement einer Software-Produktlinien betrachtet wird. Diese Ebene wird oftmals als Evolution bezeichnet, da Relationen zwischen verschiedenen Versionen und Revisionen eines Artefaktes der Produktlinie betrachtet werden [1]. 5

6 Abbildung 2 Verfolgbarkeit von Variabilität am Beispiel des klassischen V-Modells Die Ausführungen in dieser Seminararbeit beziehen sich aber ausschließlich auf die Verfolgbarkeit von Variabilität in Software-Produktlinien. 4.2 Grundproblem der Verfolgung von Variabilität in SPL Das Grundproblem der Verfolgbarkeit von Variabilität zwischen Entwicklungsartefakten aus verschiedenen Abstraktionsebenen ist direkt mit dem sogenannten Feature Interaktionsproblem verwand, welches in [10] wie folgt beschrieben wird: Feature Interaktionsproblem Das Problem ist, dass individuelle Features typischerweise nicht direkt zu einer individuellen Komponente oder einem Cluster von Komponenten verfolgt werden können das bedeutet, wenn ein Produkt durch die Auswahl einer Gruppe von Features definiert wird, dann ist eine sorgfältig abgestimmte und komplizierte Mixtur an Teilen von verschiedenen Komponenten involviert. [10] Der Begriff Feature ist in der Literatur leider nicht eindeutig definiert. Plath et al. definieren ein Feature zum Beispiel als eine funktionale Einheit, die einem System hinzugefügt oder aus einem System weggelassen werden kann [20]. Im Allgemeinen werden als Feature markante und wichtige Charakteristiken einer Domäne oder eines Software-Systems verstanden [14]. Die Beschreibung des Feature Interaktionsproblems impliziert eine n-zu-n Relation zwischen Features und Komponenten oder Designelementen. Diese n-zu-n Relation zwischen Elementen aus dem sogenannten Problemraum und Elementen aus dem sogenannten Lösungsraum stellt das grundlegende Problem der Verfolgung von Variabilität in Software-Produktlinien dar. Die Begriffe Problemraum und Lösungsraum sind in Vergangenheit durch Czarnecki und Eisenecker eingeführt worden [9]. Der Problem- und Lösungsraum 6

7 zusammen repräsentieren die Entwicklungsphasen einer Software-Produktlinienentwicklung (siehe Abbildung 3). Der Problemraum umfasst dabei im Allgemeinen die Systemspezifikation, die während der Anforderungsanalyse- und Designanalysephase entwickelt wird, während der Lösungsraum das konkrete System umfasst, welches während der Architektur-, Design- und Implementierungsphase erstellt wird. Alle Entwicklungsartefakte zusammen bilden die Produktlinien Infrastruktur. Abbildung 3 Problem- und Lösungsraum (entnommen aus [3]) Eine ideale Verfolgbarkeit sollte eine Verknüpfung der Relationen und Abhängigkeiten zwischen allen Variationspunkten in den Entwicklungsartefakten vom Problemraum zum Lösungsraum bieten [25]. Dies würde eine 1-zu-1 Mapping zwischen Variationspunkten der verschiedenen Räume bedeuten. Wie oben schon erwähnt wurde, existiert jedoch typischerweise ein n-zu-n Mapping zwischen den Variationspunkten in den Entwicklungsartefakten des Problem- und denen des Lösungsraumes. Zum Beispiel könnte ein Variationspunkt in der Anforderungsspezifikation durch mehrere Variationspunkte, die über verschiedene Komponenten verteilt sind, realisiert werden. Zur gleichen Zeit könnte eine einzige Komponente mehrere variable Anforderungen realisieren (siehe Abbildung 4). Eine solche Beziehung wird auch als Streuung bezeichnet [26]. Abbildung 4 Beziehung zwischen Features und anderen Entwicklungsartefakten (entnommen aus [22]) Um eine Verfolgung der Variabilität zwischen den Artefakten aus verschiedenen Abstraktionsebenen zu ermöglichen, ist es erforderlich eine 1-zu-1 Beziehung zwischen allen Artefakten, die im Problem- sowie im Lösungsraum entwickelt werden, herzustellen. Die Abbildung 5 veranschaulicht, dass ein spezifisches Zwischenmodell benötigt wird, welches die individuellen Beziehungen erfasst und ein dazugehöriges Mapping bereitstellt, um eine solche 1-zu-1 Beziehung zwischen allen Artefakten des Problem- und des Lösungsraums zu erreichen. 7

8 Abbildung 5 Beziehung zwischen Artefakten im Problem- und Lösungsraum (entnommen aus [4]) Die im folgenden Abschnitt vorgestellten Ansätze zielen darauf ab, ein geeignetes Zwischenmodell zu finden, um eine Verfolgbarkeit der Variabilität in Software- Produktlinien zu ermöglichen. 4.3 Bestehende Lösungsansätze In der Literatur existieren einige Ansätzen zur systematischen Verfolgbarkeit von Variabilität in Software-Produktlinien. Sie unterscheiden sich im Grad der Abdeckung des Lebenszyklus (für eine Phase, mehrere Phasen oder den ganzen Lebenszyklus) und in ihrer Notation und Notationsabhängigkeit [24]. Verschiedene Ansätze betrachten die Variabilitätsmodellierung und das Variabilitätsmanagement lediglich für eine einzige Phase oder für zwei Lebenszyklus-Phasen. So betrachten zum Beispiel Moon und Chae in [16] die Verfolgbarkeit der Variabilität zwischen den Anforderungen und der Architektur einer Software-Produktlinie. Wie oben bereits erwähnt, ist jedoch ein Ansatz, der den gesamten Entwicklungs- Lebenszyklus abdeckt, wünschenswert. Es gibt einige Ansätze, die ein Variabilitätsmanagement für den gesamten Lebenszyklus vorschlagen [3, 12, 13, 17, 24]. Den meisten liegt ein sogenanntes Entscheidungsmodell (decision model) zugrunde, was den Kern des Variabilitätsmanagements und somit der Verfolgbarkeit bildet. Aus den vorhandenen Ansätzen werden die Ansätze von Schmid et al. [24] sowie von Berg et al. [3] im Folgenden etwas genauer erläutert. Die beiden Ansätze geben einen guten Einblick in die Herangehensweisen und Lösungsansätze für eine erfolgreiche Verfolgung von Variabilität in Software-Produktlinien. Schmid et al. präsentieren einen Ansatz, der ein homogenes Variabilitätsmanagement über die verschiedenen Entwicklungs-Lebenszyklus-Phasen unabhängig von einer spezifischen Notation verspricht [24]. Sie gehen bei Ihrem Vorgehen davon 8

9 aus, dass ein Unternehmen bereits eine Einzelsystementwicklung betrieben hat und daran interessiert ist, so viel wie möglich der existierenden Notationen, Ansätze und Prozesse zu behalten. Wenn zum Beispiel ein Unternehmen in der Vergangenheit eine textbasierte Anforderungsdefinition vorgenommen hat, soll diese bei der Umstellung auf eine Produktlinien-Entwicklung erhalten und mit Variabilitätskonzepten angereichert werden. Für eine umfassende Variabilitätsmanagement-Technik sehen sie fünf Kernpunkte, die von einem allgemeingültigen Ansatz erfüllen werden sollten: 1. Die Definition von Variationspunkten in den Basis-Artefakten 2. Die Definition von Elementen, die potenziell an diese Variationspunkte gebunden werden können 3. Die Definition von Relationen zwischen Variationspunkten und potenziell gebundenen Elementen 4. Die Definition von Bedingungen, die die potenziellen Instantiierungen zwischen potenziellen Variationspunkt-Bindungen einschränken 5. Ein Auswahlmechanismus, zur Definition der Elemente, die in ein spezifisches Produkt einfließen sollen. Dieser Auswahlmechanismus kann sowohl eine manuelle als auch eine Tool-unterstützte Elementauswahl unterstützen Neben diesen hauptsächlich technischen Anforderungen stellen Schmid et al. noch einige weitere Anforderungen an einen allgemeingültigen Variabilitätsmanagement- Ansatz, die sie aus Erfahrungen aus verschiedenen Industrieprojekten abgeleitet haben. Der Ansatz soll notationsunabhängig sein Der Ansatz soll auf alle Arten an Lebenszyklus-Artefakte anwendbar sein Der Ansatz soll die Verfolgbarkeit von Variabilität sowohl horizontal als auch vertikal unterstützen Es soll möglich sein, den Ansatz hierarchisch zu strukturieren Den Ansatz, den Schmid et al. basierend auf diesen selbst definierten Anforderungen entwickelt haben, besteht aus den folgenden fünf Komponenten: 1. Ein Entscheidungsmodell als Basis für die Charakterisierung der Auswirkungen von Variabilität 2. Einem Mechanismus, um Interaktionen zwischen verschiedenen Entscheidungen (decision) zu beschreiben 3. Einem Mechanismus, um Relationen zwischen Variationspunkten und den spezifischen Entscheidungen (oder einer Gruppe von Entscheidungen), von denen die Auflösung der Variabilität abhängt, zu beschreiben 4. Eine allgemeine (maximale) Menge an Auswahltypen 5. Ein begleitendes Mapping der Auswahltypen zu einer spezifischen Notation, um die Variationspunkte in den Artefakten auszudrücken Lediglich die letzte Komponente, das Mapping, muss auf eine spezifische Repräsentationstechnik, die ein Unternehmen bei der Umstellung auf eine Produktlinienentwicklung beibehalten hat, angepasst werden. Die anderen Komponenten des 9

10 Ansatzes sind unabhängig von einer spezifischen Repräsentationstechnik, also notationsunabhängig. Die Abbildung 6 veranschaulicht diese Situation und den Variabilitätsmanagement-Ansatz von Schmid et al.. Abbildung 6 Variabilitätsmanagement-Ansatz nach Schmid et al. (entnommen aus [24]) Die ersten vier Teile des Ansatzes sind für alle Anwendungen identisch. Ausschließlich das spezifische Mapping muss jeweils angepasst und modifiziert werden. Die übrigen Elemente des Ansatzes bleiben unverändert, sodass Entwickler und Ingenieure fast wie zuvor modellieren und vorhandene Modellierungsartefakte nutzen können. Lediglich die Variationspunkte müssen in den Entwicklungsartefakten spezifiziert und im Entscheidungsmodell eingetragen werden. Im Folgenden wird das Entscheidungsmodell des Ansatzes genauer erläutert, da es für die Verfolgbarkeit eine entscheidende Rolle einnimmt. Die weiteren Komponenten des Ansatzes sind für die Verfolgbarkeit nicht ausschlaggebend und werden daher nicht weiter betrachtet. Das Entscheidungsmodell des Ansatzes von Schmid et al. besteht aus einer Menge von Entscheidungsvariablen (decision variable), die in Tabellenform notiert werden. Jede Entscheidungsvariable repräsentiert dabei eine (variable) Entscheidung, die bei der Instanziierung eines Produktes aus der Produktlinie getroffen werden muss. Eine solche Entscheidungsvariable kann dabei für mehrere Variationspunkte in den Entwicklungsartefakten verwendet werden. Sie bestehen zumeist aus den folgenden Informationen: Name: Ein eindeutiger Name, der die Entscheidungsvariable treffend beschreibt Relevanz: Die Relevanz einer Entscheidungsvariable kann von der Ausprägung einer anderen Entscheidungsvariable abhängen. So ist eine Entscheidungsvariable gegebenenfalls nicht mehr relevant, sobald eine andere einen bestimmten Wert annimmt Beschreibung: Eine textuelle Beschreibung der Entscheidung, die durch die Entscheidungsvariable erfasst wird 10

11 Wertebereich: Der Wertebereich gibt die möglichen Werte an, die eine Entscheidungsvariable annehmen kann Kardinalität: Die Kardinalität drückt aus, wie viele der definierten Werte aus dem Wertebereich von der Entscheidungsvariable angenommen werden können Bedingungen: Bedingungen werden dazu verwendet, um Wechselbeziehungen zwischen verschiedenen Entscheidungsvariablen zu beschreiben Abhängig vom spezifischen Kontext kann es vorkommen, dass eine Auswahl aus diesen Entscheidungsvariablen-Informationen verwendet wird. Es handelt sich jedoch immer um eine Teilmenge der oben genannten Informationen. Angemerkt sei auch, dass es aus praktischen Gründen und Gründen der Konsistenz immer nur ein Entscheidungsmodell für alle Entwicklungsphasen gibt. Die Tabelle 1 veranschaulicht an einem Beispiel den möglichen Aufbau des Entscheidungsmodells nach Schmid et al. und die Ausprägung einiger Entscheidungsvariablen. Tabelle 1 Beispiel eines Entscheidungsmodells nach Schmid et al. (entnommen aus [24]) Die Abbildung 7 soll die beispielhafte Verwendung einer Entscheidungsvariable in einem Entwicklungsartefakt, das eine textuelle Notation verwendet, verdeutlichen. Anzumerken ist hierbei, dass die beiden spitzen Klammern << und >> Elemente sind, die noch nicht in der textuellen Notation verwendet wurden und dass opt für optional und alt für alternativ steht. Abbildung 7 Beispielhafte Verwendung einer Entscheidungsvariable in einem textbasierten Entwicklungsartefakt (entnommen aus [24]) 11

12 Das Entscheidungsmodell bildet die Basis, um individuelle Produkte der Produktlinien zu beschreiben. Ein spezifisches Produkt kann beschrieben werden, indem Entscheidungen getroffen und damit den Entscheidungsvariablen im Entscheidungsmodell Werte zugewiesen werden. Die Bedingungen zwischen den Entscheidungsvariablen geben dabei die zulässigen Werte vor. Mit diesen zugewiesenen Entscheidungen können die Variationspunkte in den Entwicklungsartefakten, die mit den Entscheidungsvariablen in Bezug stehen, instanziiert werden. Die Abbildung 8 veranschaulicht den Zusammenhang des Entscheidungsmodells und der Entwicklungsartefakte. Abbildung 8 Zusammenhang zwischen Entscheidungsmodell und Entwicklungsartefakten Jedem Variationspunkt in den Entwicklungsartefakten ist eine Entscheidungsvariable im Entscheidungsmodell zugewiesen. Eine Verfolgbarkeit der Variabilität ist somit über das Entscheidungsmodell gegeben, da es eine 1-zu-1 Beziehung zwischen Variationspunkten und Entscheidungsvariablen herstellen. Berg et al. [3] haben einen Ansatz vorgestellt, in dem sie Variabilitätsmanagement in einer dritten Dimension, in einem sogenannten konzeptionellen Variabilitätsmodell (conceptual variability model) darstellen. Sie fassen das Software Engineering für Einzelsysteme in einem zweidimensionalen Raum auf, einen für den Entwicklungsprozess und einen für die Abstraktionsebene (siehe Abbildung 9). Alle Entwicklungsartefakte können in diesem zweidimensionalen Raum platziert werden. Für die Variabilität einer Software-Produktlinie fügen sie eine dritte Dimension hinzu, in der explizit alle Variabilitätsinformationen gekapselt werden. So werden zum Beispiel die Beziehungen und Abhängigkeiten von Variationspunkten zu Variationspunkten in anderen generischen Artefakten oder auf anderen Abstraktionsebenen in diesem konzeptionellen Variabilitätsmodell gekapselt [3]. Der Ansatz von Berg et al. basiert auf einigen der Ideen der multi-dimensionalen Separierung von Eigenschaften (separation of concerns), bei der Softwareartefakte durch Separierung von sich überlappenden Eigenschaften entlang mehrerer 12

13 Dimensionen durch Komposition und Dekomposition modelliert und implementiert werden [26]. Durch die explizite Beschreibung von Variabilitätsinformationen in der dritten Dimension erreichen sie ebenfalls eine Separierung der Variabilitätsinformationen aus den generischen Artefakten. Da für jedes generische Artefakt die individuellen Variationspunktinformationen und insbesondere die Beziehungen und Abhängigkeiten zu Variationspunkten in anderen Artefakten im konzeptionellen Variabilitätsmodell gekapselt werden, kann mithilfe dieses Modells eine Verfolgbarkeit der Variabilität gewährleistet werden. Somit ist ein 1-zu-1 Mapping zwischen Variationspunkten der verschiedenen Räume möglich (siehe Abbildung 9). Abbildung 9 Konzeptionelles Modell für die Verfolgbarkeit von Variabilität (entnommen aus [3]) Jeder Variationspunkt, der in einem Entwicklungsartefakt definiert wird, steht im Bezug zu einer Entscheidung (decision) [18]. Eine Entscheidung ist das Resultat der Beantwortung einer Frage, welche die Essens der Variabilität beschreibt, die in einem Variationspunkt ausgedrückt werden soll [3]. Entscheidungen können andere Variationspunkte einschränken und zu einer Begrifflichkeit aus einer konkreten Domäne in Bezug gesetzt werden. Eine einfache Entscheidung (simple decision) ist ein Variationspunkt, der lediglich an einer Stelle in einem generischen Artefakt auftritt. Es ist eine Entscheidung, die nur im Bezug zu einem generischen Artefakt und nicht im Bezug zu anderen Variationspunkten steht. Die Entscheidungen werden im Ansatz von Berg et al. im konzeptionellen Variabilitätsmodell gekapselt, während die einfachen Entscheidungen in den generischen Artefakten bleiben. Die Entscheidungen mit den dazugehörigen Informationen können in Tabellenform oder in einer baumartigen Struktur notiert werden. 13

14 4.4 Bewertung der vorgestellten Lösungsansätze Die beiden vorgestellten Ansätze von Schmid et al. und Berg et al. zur Verfolgbarkeit von Variabilität in Software-Produktlinien basieren grundsätzlich auf derselben Idee. In beiden Ansätzen werden die Variabilitätsinformationen außerhalb der Entwicklungsartefakte, die während der verschiedenen Phasen des Entwicklungsprozesses erstellt werden, gekapselt und verwaltet. Die Verfolgbarkeit der Variabilität erfolgt dann über diese gekapselten Variabilitätsinformationen. Nutzt man im Ansatz von Berg et al. zur Notation der in der dritten Dimension verwalteten Entscheidungen eine Tabelle, so wird eine starke Ähnlichkeit zum Entscheidungsmodell von Schmid et al. offensichtlich. Die beiden Ansätze unterscheiden sich jedoch in ihrem Ursprung und in der Herangehensweise an einen allgemeingültigen Variabilitätsmanagement Ansatz. Schmid et al. gehen davon aus, dass bereits eine Einzelsystementwicklung betrieben wurde. Sie versuchen mit ihrem Ansatz, bei der Umstellung auf eine Produktlinienentwicklung, möglichst viele der bestehenden Methoden und Vorgehensweisen zu erhalten und weiterhin zu nutzen. Lediglich das Entscheidungsmodell kommt als neues Modell zu den bereits vorhandenen hinzu. Sie fassen es als neuartiges, zusätzliches Entwicklungsartefakt auf, in dem ausschließlich die Variabilität verwaltet wird. Ein großer Vorteil der Methode liegt in der Notationsunabhängigkeit und der damit gegebenen universellen Anwendbarkeit. Als einen Nachteil kann man die Unübersichtlichkeit des Entscheidungsmodells bei größeren Produktlinien anführen. Die Auswahl von Eigenschaften, die ein Produkt der Produktlinie enthalten soll, ist nur möglich, indem das komplette Entscheidungsmodell durchlaufen und jede Entscheidung einzeln getroffen wird. Somit ist es nur sehr schwer möglich, diejenigen Eigenschaften, die insgesamt für ein Produkt zur Auswahl stehen, zu erfassen. Berg et al. hingegen gehen davon aus, dass es bereits eine Software-Produktlinienentwicklung gibt, in der auch bereits ein eigenes Variabilitätsmodell, wie zum Beispiel ein Feature-Diagramm [13], vorhanden sein kann. Zu dieser bestehenden Produktlinienentwicklung führen sie in einer dritten, orthogonalen Ebene eine Kapselung von Variabilitätsinformationen ein. Sie verwalten die Variabilität in einer separaten Ebene, die den gesamten Entwicklungszyklus überspannt. Schmid et al. dagegen verwalten diese in einem weiteren Entwicklungsartefakt. Ein Vorteil des Ansatzes ist, dass er auf jede bestehende Produktlinienentwicklung angewendet werden kann. Schwächen hat der Ansatz von Berg et al. ebenfalls im Bereich der Übersichtlichkeit und Wartbarkeit. Selbst bei einer Darstellung der Variabilitätsinformationen in einer hierarchischen, baumartigen Struktur, ist die Übersicht über alle möglichen Eigenschaften eines Produktes bei großen Produktlinien nur sehr eingeschränkt gegeben. Die Wartbarkeit der Entscheidungen ist ebenfalls sehr aufwendig, da nach einer Änderung alle zugeordneten einfachen Entscheidungen überprüft und gegebenenfalls ebenfalls geändert werden müssen. Obwohl die grundsätzliche Idee für die Verfolgbarkeit von Variabilität in beiden Ansätzen gleich ist, haben beide Ansätze aufgrund ihrer Unterschiede im Hinblick auf einen allumfassenden Variabilitätsmanagement-Ansatz ihre Daseinsberechtigung. 14

15 5 Zusammenfassung und Ausblick Das zentrale Ziel dieser Arbeit war es, einen Einblick in das Problem der Verfolgbarkeit von Variabilität in Software-Produktlinien zu geben und ausgewählte Lösungsansätze vorzustellen. Nachdem die Grundlagen des Entwicklungsparadigmas Software-Produktlinien beschrieben wurden und dargestellt wurde, was Variabilitätsmanagement in Software- Produktlinien bedeutet, ist in Kapitel 4 das Grundproblem der Verfolgbarkeit von Variabilität in Software-Produktlinien beschrieben worden. Anschließend sind zwei ausgewählte Ansätze von Schmid et al. und Berg et al. zur Lösung des Problems vorgestellt und bewertet worden. Das Problem der Verfolgbarkeit von Variabilität in Software-Produktlinien wird im Allgemeinen als einen Teil eines allgemeingültigen, universellen Variabilitätsmanagement Ansatze für Software-Produktlinien verstanden. Die beiden vorgestellten Ansätze geben dazu einen Einblick in die in der Literatur vorhandenen Lösungsansätze. Beide Ansätze sind von der grundsätzlichen Idee her ähnlich. Sie lösen das Problem der Verfolgbarkeit von Variabilität in Software-Produktlinien durch Kapselung von Variabilitätsinformationen. Dabei weisen beide Ansätze jedoch deutliche Schwächen in der Übersichtlichkeit und Wartbarkeit auf. Die Unterstützung der vorhandenen Ansätze durch Tools ist bis heute nur sehr eingeschränkt und nicht durchgängig durch alle Entwicklungsphasen möglich. Es ist zu erwarten, dass in Zukunft weitere Tools entwickelt werden, die die Ansätze zu Verfolgung von Variabilität in Software-Produktlinien unterstützen. Literatur 1. Anquetil, N., Grammel, B., Galvao Lourenco da Silva, I., Noppen, J., Shakil Khan, S., Arboleda, H., Rashid, A., Garcia, A.: Traceability for Model Driven, Software Product Line Engineering. In: ECMDA Traceability Workshop Proceedings 2008, pp (2008) 2. Bayer, J., Widen, T.: Introducing traceability to product lines, In: Proceedings of the 4th International Workshop on Product Family Engineering 2001, pp , Lecture Notes in Computer Science, vol. 2290, Springer, Heidelberg (2001) 3. Berg, K., Bishop, J., Muthig, D.: Tracing Software Product Line Variability: From Problem to Solution Space. In: Proceedings of SAICSIT 2005, ACM International Conference Proceeding Series, vol. 150, pp White River, South Africa (2005) 4. Berg, K., Muthig, D.: A Critical Analysis of Using Feature Models for Variability Management. Technical Report, University of Pretoria, South Africa (2005) 5. Boehm, B.W.: Guidelines for Verifying and Validating Software Requirements and Design Specification. In: EURO IFIP 1979, pp (1979) 6. Böckle, G., Knauber, P., Pohl, K., Schmid, K. : Software Produktlinien: Methoden, Einführung und Praxis. Dpunkt, Heidelberg (2004) 7. Clements, P.: Software Product Lines: A New Paradigm for the New Century, Cross Talk: The Journal of Defense Software Engineering, pp (1999) 15

16 8. Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. SEI Series in Software Engineering. Addison-Wesley, Boston, USA (2001) 9. Czarnecki, K., Eisenecker, U.W.: Generative Programming: Methods, Tools, and Applications. Addison-Wesley. Boston, USA (2000) 10. Griss, D., Allen, R., d Allesandro, M.: Integrating Feature Modelling with the RSEB. In: Proceedings of the 5th International Conference of Software Reuse (ICSR) 1998, pp , IEEE Computer Society, Washington, DC, USA (1998) 11. Gurp, J.v., Bosch, J., Svahnberg, M.: Managing Variability in Software Product Lines. In Proceedings of IEEE/IFIP Conference on Software Architecture (WICSA) 2001, pp , IEEE Computer Society Press, Washington, DC, USA (2001) 12. John, I., Muthig, D.: Tailoring Use Cases for Product Line Modeling: In: Proceedings of the International Workshop on Requirements Engineering for Product Lines (REPL) 2002, pp Proceedings. S.l.: Avaya Labs (2002) 13. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, S.: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, USA (1990) 14. Maßen, T.v.: Feature-basierte Modellierung und Analyse von Variabilität in Produktlinienanforderungen. Dissertation, RWTH Aachen, Shaker, Aachen (2007) 15. McGregor, J.D.: Testing a Software Product Line. Technical Report CMU/SEI-2001-TR- 022, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, USA (2001) 16. Moon, M., Chae, H. S.: A Metamodel Approach to Architecture Variability in a Product Line, 9th International Conference on Software Reuse, pp , Lecture Notes in Computer Science, vol. 4039, Springer, Heidelberg (2006) 17. Muthig, D.: A Light-weight Approach Facilitating an Evolutionary Transition Towards Software Product Lines. PhD Theses in Experimental Software Engineering. Fraunhofer IESE, Kaiserslautern (2002) 18. Muthig, D., Atkinson, C.: Model-Driven Product Line Architectures. In: Proceedings of the 2nd International Software Product Line Conference, SPLC 2002, pp , Lecture Notes in Computer Science, vol Springer, Heidelberg (2002) 19. Myllymäki, T.: Variability Management in Software Product Lines. Technical Report, Institute of Software Systems, Tampere University of Technology (2002) 20. Plath, M.C., Ryan, M.D.: Feature Integration Using a Feature Construct. Science of Computer Programming, vol. 41, pp , Elsevier, Niederlande (2001) 21. Pohl, K., Böckle, G., Linden, F.v.: Software Product Line Engineering: Foundations, Principles, and Techniques, Springer, Heidelberg (2005) 22. Riebisch, M.: Towards a More Precise Definition of Feature Models. In: Workshop at ECOOP Pp , Books On Demand, Darmstadt (2003) 23. Sametinger, J., Riebisch, M.: Evolution Support by Homogenously Documenting Patterns, Aspects and Traces. In: Proceedings of the 6th European Conference on Software Maintenance and Reengineering 2002, pp , IEEE Computer Society Press (2002) 24. Schmid, K., John, I.: A customizable approach to full-life cycle variability management. Science of Computer Programming, vol. 53, No. 3, pp (2004) 25. Sochos, P., Philippow, I., Riebisch, M.: Feature-Oriented Development of Software Product Lines: Mapping Feature Models to the Architecture. In: Proceedings of the 5th Annual International Conference on Object-Oriented and Internet-Based Technologies, Concepts, and Applications for a Networked World, NODe 2004, pp , Lecture Notes in Computer Science, vol Springer, Heidelberg (2004) 26. Tarr, P., Ossher, H., Harrison, W., Sutton Jr., S. M.: N Degrees of Separation: Multi- Dimensional Separation of Concerns. In: Proceedings of the 21st International Conference on Software Engineering 1999, pp , IEEE Computer Society Press (1999) 16