Softwareproduktlinien

Transkript

1 PRAKTISCHE INFORMATIK, UNIVERSITÄT SIEGEN Softwareproduktlinien (Pro)Seminar Informatik WS 2014/2015 Finale Ausarbeitungen Stand:

2 Preface Dieser Band enthält die finalen Ausarbeitungen eines Informatik (Pro)Seminars: Thema: Softwareproduktlinien Ausarbeitungen: 7 Semester: Wintersemester 2014/2015 Institut: Praktische Informatik Betreuer: Dennis Reuling. February 7, 2015 Siegen Praktische Informatik v

3 Table of Contents Variabilitätsmodellierung in Softwareproduktlinien Sebastian Clemens Einführen einer Softwareproduktlinie Zhonghua He Testen von Produkten und Softwareproduktlinien Jan-David Hof Modellierung und Implementierung von Features in Softwareproduktlinien 4 Konstantin Kromberg Anwendungsbeispiele im SPL-Umfeld Andreas Rosowski Softwareproduklinien - Unterschiede zur klassischen Softwareentwicklung. 6 Tim Serowski Requirements Engineering im SPL-Umfeld Manuel Wörmann vi

4 Variabilitätsmodellierung in Softwareproduktlinien Sebastian Clemens Universität Siegen ABSTRACT Der Ansatz der Softwareentwicklung mittels Softwareproduktlinien beinhaltet im Kern die Modellierung von Variabilität um eine hohe Flexibilität innerhalb von technischen Domänen zu bieten. Zunächst soll geklärt werden in welcher Vielfalt Variabilität innerhalb einer Softwareproduktlinie auftreten kann und worin sie sich gegenüber Featuremodellen unterscheidet. Dazu bedarf es einer Übersicht über die verschiedenen Definitionen, welche zur Beschreibung der Modellierung notwendig sind. Die eigentliche Modellierung der Variabilität wird schrittweise anhand eines Beispiels von Fahrerassistenzsystemen[1] im PKW erfolgen. Innerhalb dieser Beispielmodellierung sollen die vier Schritte des Domain Engineering, die Anforderung, die Architektur, das Design und das Testen, im Bezug auf die Variabilität beschrieben werden. Innerhalb dieses Prozesses soll außerdem speziell auf die Unterschiede zwischen interner und externer Variabilität eingegangen werden. 1. EINLEITUNG Softwareproduktlinien gelten als Antwort auf die steigenden Anforderungen auf dem Markt nach individueller Software in elektronischen Systemen. Ein klassisches Beispiel für solche softwareintensiven Systeme bietet die Automobilindustrie, mit ihrer Vielzahl optionaler Assistenzsysteme, welche zusätzlich auf technischer Ebene eine hohe Komplexität aufweisen. Softwareprodukte, welche in derartigen Systemen eingesetzt werden, müssen daher Flexibilität im Bereich der Nutzeranforderungen gewährleisten, gleichzeitig entsteht durch diese individuellen Anforderungen ein hoher Umfang technischer Komponenten. Diese hohe Anzahl an Kombinationen aus Anforderungen und technischen Schnittstellen, bereitgestellt durch die unterschiedlichsten elektronischen Bauteile, muss auf der Ebene des Softwaredesigns bewältigt werden. Ein Weg diese Komplexität zu beherrschen und zu modellieren soll hier dargestellt werden. Dazu werden zunächst in Kapitel 2 alle notwendigen Definitionen zur Beschreibung von Variabilität in Softwareproduktlinien aufgeführt. Nach dieser Klärung der Definition von Variabilität soll diese in Kapitel 3 auf den Kontext bezogen werden, innerhalb dessen sie auftritt. Um in Kapitel 5 Variabilität anhand einer Beispieldomäne zu veranschaulichen, soll vorausgehend in Kapitel 4 die Notation festgelegt werden, wie auch das orthogonale Variabilitätsmodell, mithilfe dessen die Variabilität letztendlich modelliert werden soll. 2. DEFINITION VON VARIABILITÄT 2.1 Variationssubjekt und -objekt Pohl et al [5] definieren Variabilität anhand eines Variabilitätssubjekts und eines -objekts. Im Kern lassen diese sich wie folgt definieren: Subjekt Das Subjekt lässt sich mittels der Frage Was variiert? [5] definieren. Betrachten wir den einfachen Fall einer Autolackierung, so lässt sich dadurch das Subjekt Autofarbe ermitteln. Objekt Als Variationsobjekt lässt sich die Antwort der Frage Wie variiert es? [5] herleiten. Zurück im Beispiel der Autofarbe ist hier also die genaue Ausprägung, beispielsweise Blau als Variationsobjekt gefragt. 2.2 Variationspunkt Variabilität in Softwareproduktlinien besteht im Wesentlichen aus zwei Teilkomponenten, einem Variationspunkt und einer Variante. Der Variabilität liegen sogenannte Artefakte zugrunde, also Komponenten aus Anforderungen, Analyse, Design und Tests, welche innerhalb verschiedenster, aus einer Softwareproduktlinie entstehenden Softwareprodukten wiederverwendet werden. Pohl et al [5] definieren den Variationspunkt wie folgt: Definition 1. A variation point is a representation of a variability subject within domain artefacts enriched by contextual information. [5] Variationspunkte beschreiben demnach die im Domain Engineering auftretenden Kategorien innerhalb derer die genaue Art der Differenzierung zweier Softwareprodukte festgelegt wird. Beispiele für Variationspunkte sind die Farbe eines

5 PKW oder auch das Interface eines Navigationssystems, wobei die Ausprägungen keine Rolle spielen. 2.3 Variante Die konkreten Ausprägungen eines Variationspunktes werden als Varianten bezeichnet. Im genannten Beispiel stellen die Farben Blau und Rot oder auch die Interfaces Touchpanel oder Sprachsteuerung die jeweiligen Varianten der zugehörigen Variationspunkte dar. Definition 2. A variant is a representation of a variability object within domain artefacts. [5] 2.4 Abhängigkeiten Betrachten wir das obige Beispiel der Variationspunkte und Varianten, so fällt auf, dass bei der Auswahlmöglichkeit von Varianten, in bestimmten Fällen, gewisse Einschränkungen notwendig sind. Im Falle der Interfaces besteht kein Problem, sollten im betroffenen System beide Komponenten gefordert sein. Hingegen bei der Farbauswahl, angenommen es ist technisch nur möglich genau eine Farbe zu nutzen, muss in der Modellierung des Variationspunktes die Einschränkung gelten, nur genau eine Variante zu wählen. Böckle et al. [2] unterteilen die Abhängigkeiten in die folgenden vier Kategorien: Optional Eine Optionale Variante stellt keinerlei Einschränkungen für weitere Varianten innerhalb eines Variationspunktes dar. Bezogen auf das Beispiel stellt die Sprachsteuerung eine optionale Variante dar. Alternativ Alternative Varianten modellieren den Fall, dass aus einer Gruppe mindestens eine Variante gewählt werden muss. Zusätzlich kann hier sowohl eine minimal, als auch maximal Anzahl an Varianten gefordert werden. Im Falle der Farbe eines Fahrzeuges wäre es also denkbar genau eine Variante der Farbe zu fordern. Erforderlich Neben den wählbaren Varianten kann ein Variationspunkt eine spezielle Variante zwingend erfordern, welche dann um zusätzliche Varianten erweitert werden kann. Im vorliegenden Beispiel könnte für das Interface eine Touchsteuerung gefordert sein, welche sich optional um weitere Möglichkeiten erweitern lässt. Ausgeschlossen Genau wie die Möglichkeit erforderlicher Varianten, kann für einen Variationspunkt eine bestimmte Variante ausgeschlossen werden. Beispielsweise ist es möglich dass bestimmte Farben technisch nicht realisierbar sind, wodurch diese als Variante der Farbe ausgeschlossen werden. Neben den direkten Abhängigkeiten zwischen Variationspunkt und Variante, können weitere Einschränkungen in Variationspunkten und Varianten bestehen. Im Wesentlichen handelt es sich hierbei um erforderliche und ausgeschlossene Komponenten. Erforderlich Manche Variationspunkte oder Varianten benötigen oftmals andere Komponenten um funktionieren zu können. Eine Touchsteuerung benötigt beispielsweise einen Touchscreen, unabhängig von dessen genauer Funktionsweise. Ist nun aber eine Touchsteuerung gefordert, welche mit Handschuhen bedient werden kann, muss das geforderte Touchdisplay auf eine oder auch mehrere konkretere Varianten beschränkt werden. Somit kann eine spezielle Variante sowohl einen Variationspunkt als auch eine konkrete Variante als notwendig fordern. Ausgeschlossen Das obige Beispiel des mit Handschuhen bedienbaren Touchscreens zeigt neben der benötigten Variante auch die Beziehung des Ausschlusses. Es fallen bei der Wahl der Variante Touchsteuerung also sämtliche Varianten von Touchscreens heraus, welche diese Art der Bedienung nicht unterstützen. 2.5 Unterschiede zu Features Neben der Variabilität existiert in Softwareproduktlinien die Modellierung von Features. Wie bei den Beziehungen zwischen Variationspunkten und Varianten, existieren auch bei Features die oben genannten Abhängigkeiten, allerdings können aufgrund dieser Tatsache Featuremodelle nicht mit Variabilitätsmodellen gleichgesetzt werden. Es gibt zwei grundlegende Unterschiede zwischen Features und der Variabilität, beziehungsweise Featuremodellen und Variabilitätsmodellen [7]. Während Featuremodelle lediglich oberflächlich und kundennah die unterschiedlichen Funktionalitäten von Softwareprodukten anhand einer hierarchi-schen Struktur modellieren, wie sie aus einer Softwareproduktlinie erstellt werden können, berücksichtigen Variabi-litätsmodelle alle potentiellen Unterscheidungsmerkmale zwi-schen einzelnen Endprodukten. Softwareprodukte, welche zwar unterschiedliche Features bieten, können auf der Ebene der Variationspunkte und Varianten sehr ähnlich modelliert sein. Andererseits kann bei Produkten mit gleichen Features, die zugrunde liegende Infrastuktur die möglichen Varianten derart beeinflussen, dass es sich um zwei grundlegend verschiedene Anwendungen handelt. 3. ARTEN VON VARIABILITÄT Variabilität kann innerhalb einer Softwareproduktlinie aufgrund unterschiedlicher Ursachen in verschiedenen Ausprägungen auftreten. Bezogen auf den Einfluss eines Kundenwunsches oder einer Abhängigkeit der Infrastruktur innerhalb welcher das Softwareprodukt eingesetzt wird, unterscheidet man zwischen interner und externer Variabilität. Darüber hinaus kann auch durch die unterschiedlichen Anwendungsbereiche eines Produkts für den jeweiligen Fall eine spezielle Variante gefordert sein. Betrachtet man den gesamten Lebenszyklus eines Softwareprodukts, so muss für die Variabilität zusätzlich die zeitliche Entwicklung genauer definiert werden. 3.1 Externe Variabilität Eine mögliche Ursache für Variabilität sind die unterschiedlichsten Kundenwünsche an ein System. Allein durch diese individuellen Anforderungen entstehen konkrete Variationspunkte und Varianten, welche jeden einzelnen Kundenwunsch definieren. Zusätzlich zu den Kundenanforde-

6 rungen führen spezielle Einsatzbereiche, anhand von Industriestandards oder gesetzlichen Vorschriften, zu individuellen Varianten. Die hier entstehende Variabilität einer Produktlinie wird als externe Variabilität zusammengefasst. Ein klassisches Beispiel sind Sicherheitsmechanismen, welche im Regelfall für Privatanwender eine optionale Komponente darstellen. Verglichen dazu ist davon auszugehen, dass Banken wesentlich höhere Grundanforderungen an Sicherheitsmechanismen stellen. 3.2 Interne Variabilität Während externe Variabilität die Kundenwünsche beschreibt, dient interne Variabilität zur Bewältigung notwendiger technischer und auch qualitativer Unterschiede. Für den Kunden sind beispielsweise die genaue Art der Datenverarbeitung und deren Formate in erster Linie irrelevant, können sich bezogen auf die Architektur und das Design aber unterscheiden, um die notwendigen Anforderungen erzielen zu können. Bezogen auf das Beispiel der Sicherheitsmechanismen ist es für einen Kunden nicht relevant welcher Algorithmus angewandt wird, solange der Sicherheitsstandart eingehalten wird. 3.3 Räumliche Variabilität Neben interner und externer Variabilität existiert eine räumliche Variabilität. Lässt man im Beispiel der Sicherheitssysteme Kundenanforderungen und technische Unterscheidungsmerkmale zusammenfließen, so kann man auch hieraus einen Variationspunkt generieren, dessen Varianten die jeweiligen Sicherheitslevel darstellen. Hierbei bestimmt der jeweilige Anwendungsbereich die geforderten Varianten, in denen er sich von anderen Systemen unterscheidet. 3.4 Zeitliche Variabilität Im Rahmen von Softwareproduktlinien gibt es unterschiedliche Definitionen innerhalb derer zeitliche Variabilität betrachtet wird. [3] In diesem Abschnitt soll allerdings lediglich auf die Evolution eines Variationspunktes eingegangen werden, also die zeitliche Änderung einer Variante. [5] Da sich Kundenanforderungen oder auch Vorschriften innerhalb des Lebenszyklus einer Softwareproduktlinie ändern können, ist es auch auf der Ebene der Variabilität notwendig darauf zu reagieren. So kann es sein, dass ein spezieller Variationspunkt im Laufe der Zeit geändert werden muss, da er die Grundanforderungen, welche er zuvor abgedeckt hat, nicht mehr realisieren kann. Ein Beispiel hierfür kann sein, dass sich Vorschriften für Zugangskontrollen ändern, wodurch innerhalb der Produktlinie der Variations-punkt eines Pinpads durch einen Fingerabdruckscanner ersetzt werden muss. 4. NOTATIONEN IN DER MODELLIERUNG Zur der in Kapitel 3 beschriebenen Modellierung, soll in diesem Kapitel die grafische Notation von Variationspunkten, Varianten und deren Abhängigkeiten definiert werden. Dazu zeigt Abbildung 1 die Notation, wie sie auch Pohl et al [5] definieren. Im Gegensatz zu etwa der Notation wie sie von Metzger et al [4] benutzt wird, werden Variationspunkte nicht explizit nach optionaler und mandatorischer Abhängigkeit innerhalb des Modells unterschieden. Die Modellierung dient einer Darstellung der Abhängigkeiten zwischen Variationspunkten und Varianten. Die Notation der Alternativen wird im Folgenden so festgelegt, dass als Standard die Werte min = 1 und max = 1 gelten, sofern keine Angaben notiert sind. Notation zur Modellierung von Variabi- Figure 1: lität [5] 4.1 Orthogonales Variabilitätsmodell Die Schwierigkeit in der Modellierung von Variabilität im Domain Engineering ist die Verfolgbarkeit des Ursprungs einzelner Variationspunkte, Varianten und Beziehungen. Da das Domain Engineering vier separate Schritte durchläuft, muss ein einheitliches Modell die Möglichkeit bieten, jedes Element im Variabilitätsmodell dem zugehörigen Arbeitsschritt im Domain Engineering zuzuweisen. Um diese Problem zu beherrschen dient das orthogonale Variabilitätsmodell (kurz OVM), welches ein einheitliches Modell über die einzelnen Analyse- und Entwicklungsschritte hinweg bietet. Im Bezug auf die Dokumentation der Variabilität lassen sich mit dem OVM die folgenden Punkte festhalten[5]: Was variiert? Hier wird der Variationspunkt erfasst. Die Beschreibung von Variationspunkten unterscheidet sich jedoch zwischen den Entwicklungsphasen, indem innerhalb der Anforderungen aus textueller Beschreibung oder mittels Use-Case Diagrammen einzelne Variationspunkte extrahiert werden können. Die Architektur liefert Variationspunkte über die jeweiligen unterschiedlichen Hardwarekomponenten innerhalb eines Mess- oder Steuerbereichs. Das Design variiert in seinen unterschiedlichen Möglichkeiten der Implementierung von beispielsweise einer Schnittstellenkommunikation. Wie variiert es? Neben den Variationspunkten ist es notwendig zu klären, in welchen Ausprägungen die Variation auftritt. Auch hier ist wieder zu unterscheiden zwischen der textuellen Beschreibung von einzelnen Varianten der Anforderung, Variation von Hardwarekomponenten zur Realisierung einer Anforderung und der zugehörigen Implementierung. Warum variiert es? Auch zu klären sind die Gründe der Variation. Hier lässt sich zwischen interner und externer Variabilität unterscheiden, denn aus externer Sicht existieren unterschiedliche Kundenwünsche und Standards oder

7 auch gesetzliche Vorschriften. In der internen Variabilität existieren oftmals technische Gründe, welche zur Realisierung der Variabilität erforderlich sind. Für wen ist es dokumentiert? Durch die Verknüpfung des OVM mit den einzelnen Phasen, lässt sich zurückverfolgen, welchen Ursprung ein Variationspunkt samt Varianten hat, wodurch nachvollziehbar ist, ob es sich um interne oder externe Variabilität handelt und für wen diese dokumentiert werden muss. Ein Sicherheitssystem und dessen Abläufe können sowohl in technischer Ebene, als auch auf Ebene der Anwendung variieren. Allein durch die Variation ist nicht ersichtlich in welcher Ebene diese Variation relevant ist. 5. VARIABILITÄT IM DOMAIN ENGINEER- ING Nachdem in den vorangegangenen Kapiteln die Definitionen zur Variabilität geklärt wurden, soll in diesem Kapitel anhand einer Beispieldomäne gezeigt werden, wie unterschiedlich das Auftreten von Variabilität im Domain Engineering auftreten kann. Im Fokus steht speziell die Bedeutung von interner und externer Variabilität. Das Domain Engineering ist ein iterativer Prozess, innerhalb dem zunächst die Anforderungen an mögliche Softwareprodukte geklärt werden (Kapitel 5.1). Neben den äußeren Anforderungen muss im nächsten Schritt die Variabilität der benötigten Architektur (Kapitel 5.2) geklärt werden, da hier aus technischer Sicht unterschiedliche Komponenten notwendig sein können um eine vordefinierte Anforderung erfüllen zu können. Im dritten Schritt soll auf die Variabilität der Implementierung eingegangen werden (Kapitel 5.3). Hierbei muss geklärt werden wie einerseits die Anforderungen im Softwaredesign umgesetzt werden können und zusätzlich wie die Variabilität der Architektur mit ihren variablen Komponenten und Interfaces implementiert werden muss. Da in jedem der Schritte zur Erstellung des Variabilitätsmodells immer mehr Variationen hinzugefügt werden, entsteht ein hochkomplexes Modell mit einer Vielzahl an möglichen Einzelprodukten. Allein bei einem einzigen Variationspunkt mit 3 Varianten wäre es notwendig 7 Einzelprodukte testen zu müssen. Dies ergibt sich aus der leeren Konfiguration und den 3! möglichen Kombinationen der Varianten, also 3! + 1 = 7. Daher wird in Kapitel 5.4 darauf eingegangen, wie dieser hohe Umfang sinnvoll und effizient getestet werden kann, ohne jedes einzelne mögliche Softwareprodukt testen zu müssen. kann, stehen hier die Assistenzsysteme von VW im Vordergrund.[1] 5.1 Variabilität der Anforderung Im Schritt der Anforderungsanalyse soll aus einer textuellen Beschreibung des Systems oder auch aus Use-Case Diagrammen die zugrundeliegende Variabilität definiert werden. Eine weitere Möglichkeit der Beschreibung von Variabilität sind Featuremodelle. Obwohl diese für eine Modellierung der Variabilität einer Softwareproduktlinie in ihrer Gesamtheit ungeeignet ist, eignen sie sich dennoch zur Modellierung der Anforderungen. Im Gegensatz zu anderen Modellierungsschritten, handelt es sich bei der Modellierung von Anforderungen zu einem Großteil um externe Variabilität (vergleiche Abbildung 2), da hier die Sicht des Kunden im Vordergrund steht. Bei der Modellierung von Variabilität der Anforderung besteht die Schwierigkeit der exakten Definition der Domänengrenze und der Anpassung der Variabilität an die Ansprüche der Endnutzer. Das Domain Scoping dient dazu, die Grenzen der Domäne zu definieren und damit auch die Variabilität innerhalb der Domäne auf ihre notwendigen Bestandteile zu reduzieren und gleichzeitig die Bedürfnisse des Kunden vollständig zu erfüllen. Dieser Prozess beginnt in der Definition eines Grundsystems an verschiedenen Varianten, welches schrittweise um Variationspunkte und Varianten oder auch auf Basis von Featuremodellen um einzelne Features erweitert werden kann. Dieses Modell lässt sich solange innerhalb einer Domäne erweitern, bis die Funktionalität ein anderes System modelliert. Ein weiterer Aspekt der Variabilität innerhalb der Anforderung ist die zeitliche Variabilität. Bei bereits bestehenden Softwareproduktlinien können wie auch bei klassischen Softwareprodukten Anpassungen an geänderte Anforderungen erforderlich sein. Wie bereits in Kapitel 3.4 eingeschränkt, wird hier die zeitliche Änderung einzelner Varianten betrachtet. Figure 2: Das Verhältnis von interner und externer Variabilität bezogen auf die Entwicklungsphasen Beispieldomäne Fahrassistenzsysteme Bevor wir allerdings weiter auf das genaue Verfahren der Modellierung von Variabilität eingehen, soll hier eine Beispieldomäne eingeführt werden, innerhalb der die einzelnen Schritte veranschaulicht werden sollen. Als Beispieldomäne sollen Assistenzsysteme im PKW dienen, hier speziell solche Systeme zur Erleichterung von Einund Ausparkvorgängen, sowie zur Unterstützung in der Einhaltung von Sicherheitsabständen und Unterstützung in Gefahrensituationen. Da der genaue Umfang einzelner Systeme zwischen den Herstellern sich durchaus unterscheiden Beispiel Fahrassistenzsysteme In diesem Beispiel der Fahrassistenzsysteme soll die Analyse der Variabilität aus zwei unterschiedlichen Sichten gezeigt werden, der textuellen Beschreibung, der Beschreibung von Anwendungsfällen und der Beschreibung durch Features. Textuell - Einparkhilfen Bezogen auf eine Einparkhilfe sei folgendes gefordert. Kunde A benötigt eine Einparkhilfe welche anhand von Sensoren den Abstand zu Hindernissen anzeigt.

8 Kunde B hingegen wünscht eine Einparkhilfe, welche neben akustischen Signalen und einer einfachen optischen Anzeige eine kameragestützte Einparkhilfe bietet. Als Variationspunkt lässt sich aus dieser Beschreibung die Notwendigkeit der Unterscheidung von Einparkhilfen extrahieren. Als Varianten dazu stehen die sensorische und kameragestützte Hilfe zur Verfügung. (Siehe Figure 3) Anwendungsfälle - Einparkhilfe Betrachten wir den Vorgang des Einparkens, so existieren neben unterschiedlichen Kundenwünschen auch unterschiedliche Anwendungsfälle. Zwei wesentliche Unterschiede im Prozess des Einparkens bestehen zwischen Parklücken und herkömmlichen Parkplätzen senkrecht zur Fahrtrichtung, durch diese zwei Anwendungsfälle werden daher für den Variationspunkt Parksituation die Varianten Parklücke und Parkplatz benötigt. Um die nötigen Variationspunkte für weitere Schritte bereitzustellen bietet Abbildung 3 eine Übersicht aller Variationspunkte und Varianten, welche aus den Anforderungen innerhalb der Domäne Assistenzsysteme entstehen interne und externe Variabilität Betrachten wir die Anforderungen, verglichen mit Abbildung 2, so wird in diesem Schritt hauptsächlich externe Variabilität durch Kundenwünsche generiert. Ein Großteil dieser Variationen kann in einem Featuremodell stückweise wiedergefunden werden, da hier beispielsweise Features wie die Einparkhilfe oder ein Einparkassistent im OVM als Variationspunkt ebenfalls auftreten. In den Anforderungen kann bereits ein kleiner Teil interner Variabilität auftauchen, welche durch eine geforderte Qualität, bereits eine Unterscheidung in der Anbindung an ein Netzwerk erfordert OVM Im OVM in Abbildung 3 muss in diesem Schritt der Variationspunkt Einparkhilfe mitsamt den beiden Varianten der visuellen Anzeige mittels Kamera, sowie die sensorische Messung der Distanz modelliert werden. Zusätzlich zu den hier eingeführten Anforderungen ist eine mögliche Anforderung eines Parkassistenten modelliert. Dieser soll optional das Ein- beziehungsweise Ausparken unterstützen. 5.2 Variabilität der Architektur Nach der Variabilität der Anforderung muss deren Umsetzung betrachtet werden. Hier kann es erforderlich sein auf technische Besonderheiten (interne Variabilität) zu reagieren. Auf der Ebene der Architektur spielen speziell Schnittstellen zwischen technischen Bauteilen eine Rolle, wodurch allein über die Anforderungen der Bauteile Variabilität entsteht. Als Bauteile gelten in der Architektur sämtliche Komponenten der benötigten Hardware, wie beispielsweise Sensoren. Wie auch im Variabilitätsmodell existieren bei Bauteilen optionale und mandatorische Ports zur Kommunikation mit wiederum anderen Bauteilen. In diesem Abschnitt sind die genauen Signale eines Ports noch nicht relevant, werden jedoch später im Design der Produktlinie genauer betrachtet. Allgemein besteht die Entwicklung der Architektur aus den Schritten Analyse, Modellierung und Evaluierung Analyse Zunächst muss die für die Anforderungen notwendige Architenktur ermittelt werden. Hierzu müssen innerhalb der Anforderungen jene Architekturbestandteile identifiziert werden, welche die Architektur grundlegend bestimmen. Speziell Sicherheitssysteme erfordern oftmals eine spezielle Struktur, wodurch alle weiteren Bestandteile in dieses System integriert werden müssen. Dadurch wird die Variabilität der Architektur ebenfalls grundlegend beeinflusst. Modellierung Nachdem die Bestandteile identifiziert wurden, muss eine geeignete Architektur entwickelt werden. Dazu müssen die optionalen und mandatorischen Architekturkomponenten in einer geeigneten Architektur zusammengefasst werden, indem alle notwendigen Schnittstellen innerhalb derer die Variabilität der Komponenten bewältigt werden muss, in die Architektur integriert werden. Diese Schnittpunkte müssen zusammen mit den variablen Komponenten in das orthogonale Variabilitätsmodell überführt werden. Evaluierung Eine Herausforderung in der Variabilität der Architektur besteht in der Performance dieses Systems. So ist ein System, welches die volle Variabilität unterstützt nicht immer gleich das bestmögliche System. Daraus folgt dass aufgrund eben dieser Variabilität der Entwurf weiter angepasst werden muss, um bei der notwendigen Variabilität eine konstante Qualität bieten zu können Beispiel Fahrassistenzsysteme In unserem Beispiel der Fahrassistenzsysteme wollen wir uns, bezogen auf die Architektur, auf die Sensorik beschränken. Allein um die Anforerung der Distanzmessung zu bewältigen, muss hier der Anwendungsbereich konkretisiert werden. Distanzmessungen lassen sich über Ultraschalltechniken, Radartechniken oder auch durch visuelle Analysen erreichen. Auch kann die Positionierung der Messeinheit eine wichtige Rolle spielen, so kann es technisch bereits durch eine einzelne Komponente zur Variabilität kommen interne und externe Variabilität Da die Architektur eine Reaktion auf die Anforderungen erfordert, ist auch hier noch ein gewisses Maß an externer Variabilität vorhanden. Strukturen wie die Unterscheidung von Sensoren ist wie auch in den Anforderungen extern relevant, allerdings nimmt bereits der Anteil der internen Variabilität zu. Variationen, welche die Interfaces und weitere Komponenten zur Organisation und Verarbeitung der verschiedenen möglichen Bauteile betreffen, sind Teil der internen Variabilität, da es äußerlich nicht notwendig ist die genaue Struktur zu kennen.

9 5.2.3 OVM Die bereits modellierten Variationspunkte der Einparkhilfe, sowie des Assistenten müssen um entsprechende Anforderungen innerhalb der Architektur erweitert werden. Hierzu zählt die Unterscheidung von Messsensoren und die Unterscheidung in der Lenkungssteuerung, da für einen Parkassistenten die Möglichkeit des eigenständigen Lenkens gegeben sein muss, der Fahrer muss aber gleichzeitig die Möglichkeit des manuellen Lenkens besitzen. 5.3 Variabilität des Designs Die Variabilität des Designs ist abhängig von der Variabilität innerhalb der Architektur und zugleich auch abhängig von den Anforderungen. So existieren Anforderungen, welche nur im Design umgesetzt werden können, wie auch Bestandteile der Architektur, welche Variabilität innerhalb der Implementierung fordern. In erster Linie besteht die Variabilität im Design in der Vielzahl der Komponenten und deren möglichen Kombinationen. Eine Möglichkeit diese Variabilität der Komponenten zu beherrschen ist es, sie in möglichst kleine Teilkomponenten zu zerlegen. Dies hat den Vorteil, dass jede variable Komponente der Architektur durch ein eigenständiges Paket im Design abgedeckt werden kann. Allerdings ist es nicht immer möglich, das Design auf Einzelkomponenten herunter zu brechen, da Variabilität auch das Gesamtkonzept betreffen kann, beispielsweise in Form von allgemeinen Datenformaten Beispiel Fahrassistenzsysteme In diesem Abschnitt betrachten wir die erforderliche Implementierung zur Realisierung der Anforderungen innerhalb der Architektur. Durch die unterschiedlichen Sensoren und deren unterschiedlichen Anordnungen, existieren demnach auch Unterschiede in den Datenströmen, wobei entweder aus den gesamten Daten aller Sensoren oder aber zunächst je Sensor die Distanz errechnet werden muss, worauf diese Daten fusioniert werden können. Ein weiterer Punkt der Implementierung sind die Einsatzbereiche einer solchen Distanzkontrolle. Betrachten wir drei mögliche Szenarien: Stadtverkehr Soll das System die Anforderung erfüllen im Stadtverkehr die Sicherheitsabstände einzuhalten und auf mögliche unerwartete Situationen reagieren zu können, so ist die Empfindlichkeit und Reichweite des Systems maßgebend in der Implementierung eines Algorithmus. Im Stadt-verkehr sollte dieser einerseits auf mittlerer Distanz optimal arbeiten, wie auch mögliche Beteiligung von Passanten in Gefahrensituationen berücksichtigen und diesen einen größtmöglichen Schutz bieten. Parken Gegenüber dem Stadtverkehr ist die Geschwindigkeit in einer Parksituation einerseits geringer und die Objekte, welche zu erkennen sind, sind im Regelfall statischer Natur, in Form parkender PKW oder sonstiger Begrenzungen. Das System sollte demnach auch bei möglichst kleinen Distanzen ausreichend genau die Abstände messen und verarbeiten können. Autobahn Während das System im Stadtverkehr und in Parksituationen für Geschwindigkeiten bis etwa 50 km h ausgelegt sind, sind auf deutschen Autobahnen deutlich höhere Geschwindigkeiten, aufgrund der streckenweise nicht vorhandenen Geschwindigkeitsbegrenzungen, anzutreffen ( 3 und 18 StVO). Dadurch ist es auch erforderlich, mögliche Risiken des Systems anzupassen, da ein Überreagieren des Systems fatale Folgen haben könnte. Ein System, welches Passanten schützen soll, sollte daher möglichst früh eingreifen, um diese zu schützen, hingegen kann ein zu sensibles Eingreifen bei hohen Geschwindigkeiten ein zusätzliches Risiko bedeuten. Daraus resultiert eine Variabilität der Implementierung aus Qualitätsgründen interne und externe Variabilität Im Design nimmt die Bedeutung von externer Variabilität zunehmend ab, da hier die Verarbeitung und Verwaltung von Daten im Vordergrund steht. Aus Kundensicht ist es irrelevant wie die Daten verwaltet werden, solange die bestehenden Vorgaben eingehalten werden. Ein möglicher Punkt der externen Variabilität in diesem Schritt sind Human- Device-Interfaces, also Schnittstellen der Implementierung zum Kunden, welche aufgrund von Anforderungen variieren können OVM Das Design erweitert das bestehende Modell um die Datenverarbeitung der Sensorik, sowie die Routinen zum Eingriff in die aktuelle Fahrsituation. Hier muss die in der Architektur vorbereitete Möglichkeit der Unterscheidung zwischen Fahrsituationen letztendlich umgesetzt werden. Das bedeutet, es entstehen hier die Varianten der Algorithmen, welche für die jeweiligen Einsatzgebiete, wie dem Stadtverkehr optimiert sind. Dabei benötigt beispielsweise die Regelung allgemein eine Variante der Objekterkennung, welche die letztendlichen Regelgrößen beeinflussen. 5.4 Variabilität der Tests Die Herausforderung des Testens von Softwareproduktlinien liegt in ihrer Variabilität und der damit verbundenen Vielzahl an Einzelprodukten. Wie auch in der Erstellung der Domäne, kann hier die Wiederverwendbarkeit einzelner Elemente ausgenutzt werden. Dadurch muss nicht jedes Produkt separat getestet werden, sondern es besteht die Möglichkeit die Artefakte zu verwenden um anhand von Testfällen, einzelne Szenarien zu testen, wie sie als Paket innerhalb eines Softwareproduktes Verwendung finden. Die Scenario based TEst case Derivation Methode, kurz ScenTED-Methode [2] berücksichtigt bereits die Variabilität aus Anforderung, Architektur und Design, um daraus mögliche Testfälle ableiten zu können. Aus den Anforderungen und den darin enthaltenen Anwendungsfällen lassen sich Anwendungsszenarien ableiten. Daraus folgt, dass jedes Produkt, welches einen konkreten Anwendungsfall abdecken soll, anhand eines entsprechend abgestimmten Testfalls innerhalb dieses Szenarios validiert werden kann. Analog zu den Anforderungen ist es auch möglich, aus einer Architekturvariante und zugehöriger Implementierung einen Testfall für eben diese Variante der Kommunikation zwischen Bauteilen

10 Figure 3: OVM eines Ausschnitts der Beispieldomäne abzuleiten. Diese einzelnen Szenarien dienen hier als Basis der Ableitung von Testfällen. Das Testen stellt bezogen auf das Domain Engineering kein festes Ende dar. Aufgrund des Testens können Änderungen in den vorangegangenen Schritten bis hin zur Anforderung notwendig sein, um die exakt gewünschte Funktionalität zu erreichen Beispiel Fahrassistenzsysteme Im vorliegenden Beispiel der Assistenzsysteme soll anhand der Variabilität in der Distanzmessung ein Testszenario identifiziert werden. Über die Anforderungen, die Architektur und das Design sticht die Variabilität der Distanzmessung heraus. Jede mögliche Variante unterscheidet sich zwar im Detail in ihrer Ausführung der Messung, allerdings bleibt ein Szenario aus den Anwendungsfällen erhalten. An jedes System wird die Anforderung gestellt, die Distanz zu einem Objekt zu messen und auszuwerten, wobei es für das Szenario irrelevant ist wie die Systeme exakt arbeiten und welche Objekte und äußeren Umstände als Voraussetzung gelten. Aus diesem Testartefakt der Distanzmessung können beispielsweise unter Verwendung weiterer Variationen folgende Testfälle generiert werden: PKW Erkennung innerorts Ein möglicher Testfall könnte nun also für ein Softwareprodukt gefordert sein, welches PKW erkennen soll. Der Testfall kann sich hier also weiter an der Variabilität des OVM orientieren, indem die Variante der Objekterkennung innerhalb geschlossener Ortschaften bei festgelegter Geschwindigkeit mit einbezogen wird. Dabei sind weitere Komponenten des Systems irrelevant. Passanten Erkennung Verglichen mit der Erkennung eines PKWs ist das Testen der Erkennung von Passanten kein grundlegend neues Problem. Hier kann vielmehr auf das vorher definierte Testszenario der Objekterkennung zurückgegriffen werden, allerdings hier unter der Berücksichtigung spezieller Parameter zugehörig zur Variation Passanten bezogen auf den Variationspunkt Objekterkennung.

11 5.4.2 interne und externe Variabilität Das Testen der Produktlinie geschieht weitestgehend auf Basis interner Variabilität. Die Wiederverwendung von bestehenden Variationspunkten und Varianten spielen in externer Sicht kaum bis keine Rolle. Damit entsteht hier, betreffend die interne und externe Variabilität, das genaue Gegenteil zum Verhältnis aus interner und externer Variabilität in der Anforderung OVM Die Verknüpfung zwischen Testfällen und Variationspunkten in der Beispieldomäne und damit zusammenhängend im vorliegenden OVM bestehen darin, dass in der Entwicklung der Testszenarien das gesamte Modell zur Entwicklung herangezogen wird, um eine möglichst große Menge an Szenarien definieren zu können, auf denen spätere Tests aufgebaut werden können, wie beispielsweise die Erkennung von PKWs oder Passanten in Kapitel ZUSAMMENFASSUNG Variabilität in Softwareproduktlinien ist definiert in der optionalen Verwendung einzelner Komponenten innerhalb eines Softwareprodukts. Diese lassen sich mittels Variationspunkten und Varianten modellieren und dienen der Auswahl einzelner Komponenten für ein gewünschtes Produkt. Jeder Schritt in der Entwicklung eines solchen Modells erfolgt über das Fokussieren einzelner Teilbereiche eines Gesamtsystems und teilt es auf in die Anforderung, die Architektur, das Design und das Validieren mittels geeigneter Testfälle. Die zunehmende Komplexität mit ihren unterschiedlichen Quellen für die Variabilität kann mittels eines orthogonalen Variabilitätsmodells festgehalten werden. [3] C. Elsner, G. Botterweck, D. Lohmann, and W. Schröder-Preikschat. variability in time product line variability and evolution revisited. In Fourth International Workshop on Variability Modelling of Software-intensive Systems, pages , [4] A. Metzger, P. Heymans, K. Pohl, P.-Y. Schobbens, and G. Saval. disambiguating the documentation of variability in software product lines: A separation of concerns, formalization and automated analysis. In 15th IEEE International Requirements Engineering Conference, pages , [5] K. Pohl, G. Böckle, and F. van der Linden. Software Product Line Engineering - Foundations, Principles, and Techniques. Springer-Verlag, [6] F. Pérez, C. Cetina, P. Valderas, and J. Fons. towards end-user development of smart homes by means of variability engineering. In Third International Workshop on Variability Modelling of Software-intensive Systems, pages , [7] F. Roos-Frantz. a preliminary comparison of formal properties on orthogonal variability model and feature models. In Third International Workshop on Variability Modelling of Software-intensive Systems, pages , [8] F. J. van der Linden, K. Schmid, and E. Rommes. Software Product Lines in Action The Best Industrial Practice in Product Line Engineering. Springer-Verlag, FAZIT Variabilität in Softwareproduktlinien lässt sich in interne und externe Variabilität kategorisieren. In der Entwicklung eines Variabilitätsmodells ist es also erforderlich stets beide Aspekte zu berücksichtigen, um ein Modell zu erzeugen, welches einerseits die Anforderungen ideal modelliert, aber auch die zugrundeliegende Technik ausreichend berücksichtigt. Im hier gezeigten Beispiel lässt sich erkennen, dass jeder Schritt ein gewisses Verhältnis zwischen interner und externer Variabilität beinhaltet. Damit kann gewährleistet werden, dass das resultierende Modell stets interne und externe Gründen von Variabilität miteinander verknüpft und nicht abgewogen werden muss, welche Sichtweise im absoluten Fokus stehen muss. Dieses Zusammenspiel lässt sich über das orthogonale Variabilitätsmodell geeignet dokumentieren. Es ermöglicht ein einheitliches Modell und dient darüber hinaus der Indentifizierung der Herkunft von Variabilität und somit auch ob es sich um interne oder externe Ursachen handelt. 8. REFERENCES [1] Volkswagen assistenzsysteme. URL: technologies/de/de/mainpage.html?deep=e6040c94-3b2b-4ee0-87ec-c6ef09d7d5ee Abgerufen: [2] G. Böckle, P. Knauber, K. Pohl, and K. Schmid. Software-Produktlinien Methoden, Einführung und Praxis. dpunkt.verlag, 2004.

12 Einführen einer Software Produktlinien Zhonghua He Universität Siegen ABSTRACT Um einen flüchtigen Einblick in die Software Produktlinie (SPL) zu verschaffen, beschäftigt sich dieser Artikel hauptsächlich mit den grundlegenen Begriffen, Verwendung und Randbedingungen der Software Produktlinie und dem Software Produktlinie Engineering. Dazu werden zuerst die Motivation, Grundlagen und die Zustände der Anwendung kurz vorgestellt. Im Anschluss lässt sich die SPL aufgrund der Merkmalen und den drei wesentlichen Aktivitäten für Software Produktlinien, nämlich Core Asset Development, Product Development, und Management auffassen. Darüber hinaus bezieht es sich auf die Voraussetzungen der Anwendung. Und am Ende kommt der Artikel zu der Anwendungsebene der SPL. Dazu wird das Software-Produktlinie-Engineering kurz beschreibt. 1. EINFÜHRUNG 1.1 Entstehungshintergrund der Software-Produktlinie Die massive Software-Wiederverwendung ist seit langem ein wichtiges Thema der Softwaretechnik, doch viele dieser Versuche sind wegen verschiednen Problemen endlich ausgeblieben. Die traditionellen Wiederverwendungsstrategien können nur wenigen Nutzen einbringen, denn in der Regel sind sie in kleinen Maß und meistens die Ad-hoc Wiederverwendung 1. Heute breitet sich die Anwendung der Software in fast allen Bereichen des Lebens aus, um die vielfältigen gesellschaftlichen Bedürfnisse zu befriedigen. Im intensiven Wettbewerb von heute streben die Unternehmen immer höheren Geschäftszielen zu, wie schnellere Marktagilität, kürzere Markteinführungszeit und höhere Benutzerzufriedenheit. 1 nach den Wiederverwendungsstufen gibt es 5 Wiederverwendungsstufe, die Ad-hoc-Wiederverwendung ist die niedriegste Stufe, ist eine gelegentlich,unsystematisch Wiederverwendung Dazu wird eine effizientere Wiederverwendung-Strategie erfordert, die sich mit dem Konzept der Software Produktlinie beschäftigt. Die SPL wurde in den letzten Jahrhundertwende vom Software Engineering Institute der Carnegie Mellon University in Pittsburgh eingeführt. Seit langem ist der Begriff von Produktlinie 2 in der Automobilindustrie schon vorhanden. Und nach der Einführung der Produktlinie stieg der Umsatz deutlich.[5](s. 6) 1.2 Verwendung von SPL in der Industrie In den letzten Jahren begannen viele internationalen Unternehmen wie ABB, HP, Boeing, Philips u.s.w. den Software- Produktlinen Aufmerksamkeit zu schenken und versuchten die zum Einsatz zu bringen. Ein erfolgreiches Beispiel zur Implementierung der Software Produktlinie ist bei HP (Hewlett Packard), sie initiierte das Owen Firmware Cooperative. 3 Dazu wurde eine Gemeinschaft von mehreren Produktteams für die Durchführung der Produktlinie auf eine kooperative Art und Weise aufgebaut. Der Anfang ist schwer, aber der Einsatz von Software-Produktlinien führte zu einer Erhöhung der Wiederverwendungsproportion auf etwa 70% für neue Produkte. Über 20% der Application Assets 4 basierten auf die leicht modifizierte Core Assets und nur 10% davon erforderten neue Code.[5](S. 419) Wie HP haben bisher viele Unternehmen Versuch dazu ausgeführt und einen Anfangserfolg erzielt, was darauf hinweist, ist, dass die Software-Produktlinie in der Industrieproduktion über großes Potenzial und hohen Forschungswert verfügt. 2. GRUNDLAGEN DER SOFTWARE PRO- DUKTLINIE 2.1 Definition Um unter dem Begriff zu verstehen, muss man zuerst auf die Erklärung von Carnegie Mellon University eingehen: A software product line (SPL) 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. [3] 2 Produktlinie bedeutet eine zusammenhängende Gruppe von Produkten eines Unternehmens 3 Owen ist eine Firmware,die in HP-Drucker Anwendung findet. 4 Die Begriffe von Application Assets und Core Assets werden im Abschnitt 2.2 erklärt.

13 In Anlehnung an diese Definition kann man dazu entnehmen, dass die Software-Produktlinie sich auf eine Menge von Softwareprodukten bezieht, die sich in eine Reihe von Merkmalen teilen. Diese Produktionsweise hängt von der auf die sogenannten Core Assets basierenden systematischen und strategischen Wiederverwendung ab. Zum anderen lässt sich das Software-Produkt trotz der gemeinsamen Entwicklungsgrundlage mit verschiedenen Verwendungszwecken variable einzustellen. 2.2 Begriffsbestimmung Unten aufgelistet sind die wichtigsten Begriffe in der Domäne, die als die grundlegenden Bausteine zum Aufbau des SPL-Konzepts und zur weiteren Intensivierung gelten. Produktlinie(Product Family) Für Software Produktlinie bestehen verschiedene Bezeichnungen, die teilweise synonym verwendet werden. So gibt es für den in der amerikanischen Forschung geprägten Begriff Product line im europäischen Raum die Bezeichnung Product Family, genauso wie ihre Bestandteile entweder Core Assets oder Platform genannt werden. Das lässt sich darauf zurückführen, dass sich ursprünglich amerikanische und europäische Forschungsgemeinschaften getrennt mit der Software Produktlinienentwicklung beschäftigt haben. Außerdem gibt es in Europa weitere Bedeutung für Software-Produktlinien: so bezeichnen einige Unternehmen mit Product Line eine Menge ähnlicher Produkte, die aber auf unterschiedlichen Technologien basieren. Um keine Verwechselungen zu provozieren wurde deshalb in vielen europäischen Forschungsprojekten explizit Product Family (oder auch System Family) verwendet. Außerdem ist es hier zu beachten, dass Product Lines in Product Families enthalten sein können und umgekehrt. Bezüglich dieser Terminologie ist der Begriff Product Line markt- und kundenorientiert, wohingegen eine Product Family ein technologie- bzw. implementierungsabhängiges Konzept ist.[1] Feature Feature(deutsch: Merkmale) ist eine abstrakte Anforderung, die für die Spezifikation der Gemeinsamkeiten und Variabilitäten von Software-Systemen eingesetzt wird. Es ist einfacher die Software zu entwickeln, wenn ihre Features in Design und code explizit dargestellt werden. Wenn die Software durch Auswahl von Features erzeugt werden, wird diese Methode als Featureorientierte Softwareentwicklung genannt.[4] Core Assest(Platform) Core Asset, das in der Produktion von mehreren Produkten in einer Software-Produktlinie verwendet wird, ist ein wiederverwendbares Artefakt 5 oder ein Ressource. Ein Core Asset kann eine Architektur, eine Softwarekomponente, eine Domänenmodell, eine Spezifikation, ein Dokument, ein Plan, einen Testfall, eine Verfahrensbeschreibung usw. sein.[3] Core Asset wird manchmal auch als eine Plattform genannt, alle diese beziehen sich auf die Menge von wiederverwendbaren Artefakten. 5 ein Produkt, das als Zwischen- oder Endergebnis in der Softwareentwicklung entsteht Variabilität Software-Produktlinie hat darüber hinaus auch eine Aufgabe, nämlich die Mannigfaltigkeit einer Reihe von Produkten zu schaffen. Diese Produkte werden je nach den verschiedene Kundenbedarf erstellt, deshalb ist die Variabilität ein Schlüsselkonzept in einem solchen Ansatz. Die Variabilität einer Produktlinie wird durch sogenannte Variationspunkte charakterisiert. Ein Variationspunkt definiert eine Auswahlmöglichkeit unter den von der Produktlinie zur Verfügung gestellten verschiedenen Funktionalitäten. Die Variationspunkte können in allen Entwicklungsphasen definiert und verwaltet werden.[6](s. 8) Da eine Produktlinie typischerweise über sehr viele Variationspunkte verfügt, ist die Variabilität einer Produktlinie oft sehr umfangreich und komplex. Je umfangreicher die Variabilität einer Produktlinie ist, umso größer ist die Flexibilität bei der Entwicklung von kundenspezifischen Produkten; d.h. umso mehr unterschiedliche Produkte können durch die Ausnutzung der Variationspunkte entwickelt werden. 2.3 Merkmale Die Software-Produktlinie verfügt über solche folgenden Merkmale: Die Software-Produktlinie ist die höchste Stufe der Wiederverwendung. Im Vergleich zu der früheren kleinkörnigen Wiederverwendung werden alle Core Assets zur Wiederverwendung konzipiert und zur Anwendung in mehreren Systemen optimiert.[3] Die Core Assets sind hier die Anforderungen, Domänenmodelle, Software- Architektur, Performance-Modelle, Testfälle und Komponenten u.s.w. gemeint. Früher hängt die Generierung der neuen Systeme von der Änderung der alten vorhandenen Systeme ab. Diesen Ansatz nennt man clone and own 6. Im Gegensatz dazu zielt die Software-Produktlinie darauf ab, im selben Core Asset mehrere Systemen aufzubauen. Im Rahmen der Software-Produktlinie wird das Core Asset für Wiederverwendung speziell entworfen und die Produktlinie wird als eine ganze Einheit betrachtet. In den ausgereiften Produktlinien findet man das Konzept der mehreren Produkten nicht mehr. Jeder Produkt dient als einen Extrakt des Core Assets und nur das Core Asset wird sorgfältig mit der Zeit entwickelt und verbessert.[3] Der wesentliche Unterschied zwischen der traditionellen Single-System-Entwicklung und der Software Produktlinienentwicklung liegt in der Verschiebung des Schwerpunkts: Von einem individuellen Projekt zu der Produktlinie, von einem bestimmten Projekt zu einem bestimmten Geschäftsbereich.[3] 2.4 Drei Notwendigen Bestandteile der Software Produktlinie 6 Clone-and-Own bezeichnet die Vorgehensweise,dass die Implementierung von Produktvarianten, basierend auf einer Codekopie mitmanueller Anpassung ist.

14 Software Produktlinie besteht aus drei notwendigen Aktivitäten, nämlich Core Asset Entwicklung, Produktntwicklung und Management.[3] Die variablen Kombinationen der drei Aktivitäten führen zu den vielen Möglichkeiten der Anwendung der Software- Produktlinie. Ein proaktiver Ansatz ist so, dass eine Software- Produktlinie erstens durch den Aufbau von Core Asset eingeführt wird. Darüber hinaus kann man auch mit einigen vorhandenen Produkten anfangen, die als Grundlage des Core Assets dienen. Die weiteren Produkte werden darauf generiert. Diesen Ansatz heißt man reaktiv. In den beiden Fällen lassen sich die Core Asset Schritt für Schritt mit der graduellen Steigerung entwickeln, und zwar kann man vor allem die wichtigste Core Asset gründen, auf der die anfänglichen Produkte entwickelt werden. Sobald das Core Asset bereichert wird, steht es auch den weiteren Produkten zur Verfügung.[3] 2.5 Vorteile der Software-Produktlinie Von Erfahrungen ausgehend bietet der Einsatz von Software- Produktlinie die folgenden Vorteile: Figure 1: Drei Notwendigen Bestandteile Der Software Produktlinie[3] Entwicklung des Core Assets Die Entwicklung des Core Assets ist die wichtigste Aspekt in Software Produktlinien. Hier wird das Core Asset nicht nur das Programm-Code gemeint, sondern auch die Anforderungen, die Architekturbeschreibungen, die Spezifikationen und die Testfälle etc. Das Core Asset stellt die Grundlage für die Herstellung von Produkten, aber man sieht häufig, dass das Core Asset nur teilweise in mehreren Produkten Anwendung findet.[3] Produktentwicklung Im Vergleich mit der traditionellen Software-Entwicklung wird die Produktentwicklung in Software Produktlinien leichter, denn es geht nur um Zusammenbau von Core Assets. In diesem Prozess werden die Anforderungen modelliert, die nur für eine konkrete Produktvariante gelten. Danach fangen die Entwicklerteams an, die passenden Bestandteile des Core Assets für die Realisierung des Produktes auszuwählen. Falls das Core Asset manche bestimmten Funktionen nicht anbieten kann, ist es dann notwendig, die fehlenden Funktionen zu ergänzen.[3] Management Im Managementprozess wird die gesamte Entwicklung der Produktlinie gesteuert und überwacht, damit eine adäquate Ressourcenverteilung zwischen den beiden anderen Entwicklungsprozessen erfüllt wird.[3] Wie in der Abbildung 1 gezeigt wird, baut man die neuen Produkte auf der Basis des Core Assets auf. Dabei lässt sich das Core Asset auch von vorhandenen Produkten extrahieren. Das Core Asset ändert sich mit der Zeit. Alle drei Aktivitäten sind ineinander verflochten und bestehen in ständiger Bewegung. In jeder Software-Produktlinie sind sie notwendig, untrennbar, interaktiv und treten in beliebige Reihenfolge auf.[3] Produktivitätssteigerung Dies ist genau der größte Vorteil der Software-Produktlinie. Mit dem Einsatz der Software-Produktlinie wird die komplizierte und beschwerliche Programmierung durch die eher einfache Konfiguration des Core Assets substituiert.[5](s. 11) In dieser Hinsicht werden die Unternehmen dadurch befähigt, in kurzer Zeit eine Reihe Produkte mit Varianz aber auch Homogenität (wie wir heute die umfangreichen Komponenten von Microsofts Office-Suiten sehen) herzustellen, um eine größere Marktanteile zu gewinnen Verringerung der Markteinführungszeit Figure 2: Markteinführungszeit Mit Und Ohne SPL[5](S. 11) Wie allgemein bekannt im IT-Bereich, wer zuerst das Produkt auf dem Markt bringt, gewinnt den Vorsprung. Deswegen legt man den großen Wert auf die Markteinführungszeit, und bemüht sich mit äußerster Kraft sie zu verkürzen. Wie in der Abbildung 2 dargestellt wird, nehmen wir in der Entwicklung von einzelnen Systemen an, dass die Markteinführungszeit konstant ist. Aber im Vergleich zu der traditionellen einzelnen Programmierung nimmt die Entwicklung der Software-Produktlinie normalerweise in der Angangsphase mehr Zeit in Anspruch, damit die Core Assets komplett aufgebaut werden. Aber die deutliche Erhöhung der Leistungsfähigkeit findet man danach mit Ausdehnung der Software-

15 Produktlinie, weil viele Artefakte zur Entwicklung der neuen Produkte wiederverwendet werden können.[5](s. 11) Kostenreduzierung Figure 3: Kostenvergleich[5](S. 11) Die Software-Produktlinie verwendet die massive Wiederverwendung, um Kosten zu senken, aber die Vorteile sind nicht kostenfrei, man muss vor allem die Voraussetzung schaffen. Wie in der Abbildung 3 gezeigt wird, nur wenn die Zahl der Produkte 3 bis 4 beträgt, erreicht man erst den Gleichgewichtspunkt. Das heißt, dass die Produktionskosten mit Anstieg der Produktmenge stark reduziert werden. Deswegen ist es zu bedenken, dass die Entscheidung zum Einsatz der Software-Produktlinie von der Produktmenge fest abhängt.[5](s. 9f) Andere Diese oben genannten Vorteile sind die drei wichtigsten Aspekten, wie die Software-Produktlinie die Entwicklung und Produktion der Software im großen Maß positiv beeinflusst. Natürlich gibt es andere Vorteile, die man nicht übersehen kann, wie die Erhöhung der Produktqualität. Denn die Artefakte der Produktlinie werden in der Wiederverwendung mehrmals überprüft, so dass die Fehler sich schwer verschleiern lassen. Außerdem setzt die Wiederverwendung die User Experience herauf, indem die Homogenität der verschiedenen Produkte mit Anwendung der Software-Produktlinie gut bewahrt wird, was gleichzeitig zur erhöhten Nutzungszufriedenheit führen kann.[5](s. 11f) 3. VORAUSSETZUNGEN DER UMSETZUNG 3.1 Voraussetzungen Zurzeit besteht die Software-Produktlinie noch in der Anfangsphase. Um sie besser auszunutzen, muss man die Voraussetzungden der Anwendung in Betracht nehmen. Und tatsächlich geht der Erfolg des Produktlinienansatzes mit neuen Lösungen und Technologien einher Technische Durchführbarkeit Die erste Hinderung zur Durchführung der Software Produktlinie liegt an dem Mangel an geeigneten Technologien für die Anwendung der Prinzipien der Produktlinienentwicklung auf einfache Weise. Heutzutage werden viele Programme in prozeduralen Programmiersprache geschrieben. Aber in der prozeduralen Programmiersprache ist die Verkapselung und Information hiding 7 schwer zu erreichen. Die Verkapselung ist die Voraussetzung für Variabilitätsmanagement. In der Praxis besteht derzeit eine Fokussierung auf die Verwendung von Komponententechnologien in Verbindung mit objektorientierter Programmierung, die diese Barriere mit der Unterstützung von anerkannten Design-Prinzipien wie die objektorientierte Modellierung und Programmierung- Theorie entschärft.[5](s. 16) Die Prozessreife Die Unerfahrenheit in der Software-Entwicklung kann auch auf die Umsetzung der Software-Produktlinie negativ einwirken. Der Software-Entwicklungsprozess, der früher unstrukturiert, kaum gut definiert, und auch nicht gut verstanden ist, wird mit Einführung der Prozessmodelle wie CMMI 8 verbessert. Das Prozessmodell leistet zur Identifizierung der schwachen Teilen der Software-Entwicklungsprozesse einen wertvollen Beitrag. Außerdem ist es zu bedenken, dass die unzureichende Requirements Engineering eine der Hauptursache für Probleme in Software-Projekten. Die komplette Requirements Engineering beinhalten Identifikation von Gemeinsamkeiten und Variabilität, die genau als hauptsächliche Voraussetzung der Software-Produktlinie gelten.[5](s. 17) Domain-Eigenschaften und Expertise Des Weiteren ist die Erfahrung in den bestimmten Domain von großer Bedeutung. Nur wenn man die Märkten und Kunden auskennt, kann die Gemeinsamkeiten und Variabilität in angemessener Weise für Entwicklung der Plattformen und Produkten identifiziert werden. Die Unwissenheit in der betreffenden Domain führt zur falschen Abstraktionen und Verstehen, sodass die Entwickler nicht sofort bemerken könnnen und nur danach die Fehler reparieren müssen.[5](s. 17f) 3.2 SEI-Methode Nach der Meinung von der Universität Carnegie Mellon muss man vor allem die drei wesentlichen Aktivitäten, nämlich Entwicklung des Core Assets, Produktentwicklung und Management, erfüllen, um eine Software-Produktlinie zu realisieren(siehe Abbildung 1). Dazu sind die Voraussetzungen zur Durchführung der drei wesentlichen Aktivitäten von großer Bedeutung. Im Folgenden wird die SEI Entwicklungsmethode der Universität Carnegie Mellon charakterisiert. Um die Umsetzung der Software-Produktlinie in der Praxis zu ermöglichen, SEI stellt 29 relevanten praktischen Anwendungsbereichen(siehe Abbildung 4) (Architecture Definition, Architecture Evaluation, Component Development, Mining 7 Verkapselung und Information hiding ist eine Merkmale von Objektorientierter Programmiersprache, bedeutet in der Programmierung das Verbergen von Daten oder Informationen vor dem Zugriff von außen. 8 Das Capability Maturity Model Integration (kurz CMMI) ist eine Familie von Referenzmodellen für unterschiedliche Anwendungsgebiete derzeit für die Produktentwicklung, den Produkteinkauf und die Serviceerbringung. Ein CMMI- Modell ist eine systematische Aufbereitung bewährter Praktiken, um die Verbesserung einer Organisation zu unterstützen.

16 Figure 4: 29 Anwendungsbereichen[2] Existing Assets, Requirements Engineering, Software System Integration, Testing, Understanding Relevant Domains, Using Externally Avallable Software, Configuration Management, Make/Buy/Mine/Commission Analysis, Measurement und Tracking, Process Discipline, Scoping, Technical Planning, Technical Risk Management, Tool Support, Building a Business Case, Customer Interface Management, Developing an Acquisition Strategy, Funding, Launching and Institutionalizing, Market Analysis, Operations, Organizational Risk Management, Structuring the Organization, Technology Forecasting, Training). Der Anwendungsbereich ist die Ansammlung der Aktivitäten, die für die erfolgreiche Durchführung der drei wesentlichen Aktivitäten in der Software Produktlinie notwendig sind. Der Anwendungsbereich macht die wesentlichen Aktivitäten mehr erreichbar durch Festlegung von den Aktivitäten, die kleiner und besser lenkbar als eine unklare Aktivität wie z.b. Ëntwicklung des Core Assetsßind. Der Anwendungsbereich bietet auch die Ansatzpunkte, von denen die Entwickler bei der Annahme eines Produktlinienansatzes den Projetkszeitplan leicht kontrollieren können.[3] Eigentlich spielen diese 29 Anwendungsbereichen eine große Role nicht nur in der Software-Produktlinie, sondern auch in der traditionellen Entwicklung. Die 29 Anwendungsbereichen sind in drei Kategorien unterteilt, nämlich Software-Engineering, Technik-Management und Organisation-Management.[3] Software-Engineering Software-Engineering bezeichnen die Tätigkeiten, die notwendig für Anwendung der Technologie zur Schaffung und Entwicklung der Plattformen und Produkten. Dazu zählen z.b. Architekturentwicklung, Requirements Engineering, Komponenten-Entwicklung und Testen.[3] Der schwierigste Teil im Aufbau eines Software-Systems ist zu entscheiden, was für eine Software produziert werden soll. Die Anforderungen dient zur Beschreibung darüber, was das System tun muss, wie es sich verhalten muss, welche Eigenschaften es aufweisen muss, welche Qualität es besitzen muss, und welche Randbedingungen, die das System erfüllen muss. Das Requirements Engineering betont die Verwendung von den systematischen und wiederverwendbaren Techniken, die die Vollständigkeit und Konsistenz der Systemsanforderungen gewährleistet. Genauer gesagt umfasst das Requirements Engineering Anforderungserhebung, Analyse, Spezifikation, Verifikation und Management.[3] Die Architektur ist ein wichtiges Artefakt, wenn man über die Qualitätsziele des Systems(wie beispielsweise Sicherheit, Zuverlässigkeit, Benutzerfreundlichkeit, Änderbarkeit und Echtzeit-Performance)spricht. Mittlerweile ist die Architektur auch eine Kommunikationsbrücke für alle Teilnehmenden: Entwickler, Manager, Betreuer, Benutzer, Kunden, Tester, Vermarkter, und alle anderen, die ein Interesse über die Entwicklung und Nutzung des Systems haben.[3] Eine der Aufgaben des Software-Architekten ist es, die Liste der Komponenten entsprechend der Architektur zu produzieren. Die Komponenten werden als Einheiten in der Software intergriert, um ein ganzes System

17 zusammenzubauen.[3] Die Testen haben zwei Hauptfunktionen. Zum Ersten wird der Fehler identifiziert, die zum Ausfällen geführ haben, so dass sie sich reparieren lassen. Zum Zweiten ist zu bestimmen, ob die zu testende Software nach der festgelegten Anforderungen durchführen können. Mittlerweile bleibt der Test aktiv im gesamten Lauf des Entwicklungsprozesses. Schließlich werden einige Artefakte produziert: Testfälle, Testdokumente, Testdatensätze.[3] Technik-Management Technik-Management sind die organisatorische Aktivitäten, die die Schaffung und Entwicklung der Plattformen und Produkten verwalten, wie beispielsweise Risikomanagement, Projektplannung, Scoping oder Konfigurationsmanagement.[3] Das wichtigste Ziel des Risikomanagements ist, Risiken zu vermeiden. Das Software-Projektrisiko besteht in der Budget- und Zeitkontrolle in der Software Entwicklung und andere Aspekte, die sich negativ auf das Projekt auswirkt. Wenn die Projektrisiken auftreten, können sie den Fortschritt des Projekts beeinflussen, die Kosten des Projekts erhöhen, und sogar zum Scheitern des Projekts führen.[3] Das Scoping ist eine Aktivität, die ein System oder eine Menge von Systemen begrenzt, durch Bestimmung aller Verhalten oder Aspekte, die zum System gehören oder nicht gehören. Kurz gesagt beantwortet das Scoping die Frage Welche Produkte sollten in meiner Software-Produktlinie inklusiv sein? [3] Organisation-Management Das Organisation Management zielt auf die Instrumentierung der gesamten Software Produktlinie ab. Sie bezeichnen betriebswirtschaftliche Aufgaben, zu denen beispielsweise Marktanalyse, Organisationsplanung, Geschäftsmodellentwicklung oder Training gehören. Sie werden u.a. zur Einführung und Evolution der Produktlinieentwicklung im Unternehmen benötigt.[3] Da die Märkte sich ständig verändert, sollte eine Marktanalyse ein lebendiges Dokument sein. Basierend auf dieser Analyse kann ein Business-Fall, eine Strategie oder ein Plan entwickelt werden. Das Ziel der Marktanalyse ist, die grundsätzliche Frage zu beantworten. Kann der Markt das ausreichende wirtschaftliche Potenzial für uns anbieten, um unsere Unternehmensziele mit diesem Produkt zu erreichen?[3] In der Organisationsplanung geht es um die Plannung auf der strategischen und organisatorischen Ebene. Das Training ist das Kerngeschäft von der Software Entwicklungsorganisation. Der Zweck ist, die Fähigkeiten und Kenntnisse zu liefern, die für das Software Management und die technischen Aufgaben erforderlich sind.[3] Die SEI-Methode beschreibt Tätigkeiten auf einem abstrakten Niveau und kann an unterschiedliche Prozesse angepasst werden. 3.3 Sonderfälle Außerdem muss man nicht übersehen, dass es auch die Sonderfälle gibt, wobei die Software Produktlinie nicht geeignet in Anwendung finden kann. Beispeisweise wird nur die einzige Version von den Kunden angefordert. Oder das läufige Projekt unterscheidet sich ganz und gar von dem ehemaligen, das heißt, dass die Geschäftsbereiche verändert werden. Darüber hinaus gibt es auch die Möglichkeit, dass das Projekt sich an der Spitze der Innovation befindet, und alle Projekte sollen von Grund auf völlig neu entwickelt werden. In diesen Fällen eignet die Software-Produktlinie sich nicht für die Entwicklung.[6](S. 305) 4. GRUNDLAGEN DES SOFTWARE PRO- DUKTLINIE ENGINEERINGS 4.1 Software Produktlinie Engineering Das Software Produktlinie Engineering bezieht sich auf die Engineering und Management Methode, um eine Software Produktlinie zu erstellen, zu entwickeln und zu erhalten. Im Rahmen der Software Produktlinienentwicklung werden die zwei Begriffe unterschieden, nämlich Entwickung für Wiederverwendung und Entwicklung mit Wiederverwendung. Wie in der Abbildung 5 gezeigt wird, dass Software Produktlinie Engineering aus zwei Prozessen besteht, nämlich Domain Engineering (Entwickung für Wiederverwendung) und Application Engineering (Entwicklung mit Wiederverwendung).[6](S. 6f) Domain Engineering Im Domain Engineering wird die Grundlage für die Gemeinsamkeit und Variabilität zur Entwicklung der Produkte hergestellt. Das Hauptziel von Domain Engineering ist, das Core Asset zu generieren.[5](s. 20f) Aber man muss beachten, dass die verschiedenen Assets mehrdeutige Variabilität enthalten. Zum Beispiel kann eine Darstellung der Anforderungen eine explizite Beschreibung der spezifischen Anforderungen enthalten, die nur für eine bestimmte Untergruppe der Produkte gelten. In der Regel enthält das Domain Engineering die meisten Funktionen, die für ein neues Produkt erforderlich sind. Zu dem Domain Engineering gehören fünf Subprozessen: Product Management, Domain Requirements Engineering, Domain Design, Domain Realisation und Domain Testing.[5](S. 21) Product Management: Das Produktmanagement befasst sich mit den wirtschaftlichen Aspekten der Software-Produktelinie und vor allem mit der Marktstrategie. Die Scoping Technologie wird dazu verwendet, um den Umfang der Produktlinie zu definieren. Der Einsatz des Produkt Managements stammt aus den oberen Schichten des Unternehmens, um das Geschäftsziel zu setzen.[5](s. 24) Domain Requirements Engineering: Der Domain-Requirements-Engineering Subprozess umfasst alle Aktivitäten zur Auslösung und Dokumentation der gemeinsamen und variablen Anforderungen an die Produktlinie. Domain Requirements Engineering unterscheidet sich von Requirements Engineering für

18 Figure 5: Rahmen Von Software Produktlinie Engineering[5](S. 22) Einzelsystem, denn das Domain Requirements Engineering sich gegen die allgemeine Anforderungen richtet.[5](s. 25) Domain Design: Der Domain-Design Subprozess umfasst alle Aktivitäten zur Definition der Referenzarchitektur der Produktlinie, die eine gemeinsame High-Level-Struktur für alle Produktlinie-Anwendungen anbietet.[5](s. 26) Domain Realisation: Der Domain-Realisierung Subprozess befasst sich mit der detaillierten Konzeption und Umsetzung der wiederverwendbaren Software-Komponenten.[5](S. 27) Domain Testing: Der Domain-Testing Subprozess sorgt für die Validierung und Verifizierung der wiederverwendbaren Komponenten. Der Domain-Testing überprüft die Spezifikationen der Komponenten, d.h. Anforderungen, Architektur und Design-Artefakte. Des Weiteren entwickelt der Domain-Testing die Test-Artefakte zur Reduzierung des Aufwands für Application-Testing.[5](S. 27) Applicaition Engineering Im Application Engineering wird die Produkte auf der Basis, die im Prozess von Domain Engineering gestellt wird, endlich erzeugt. Der Prozess Applicaition Engineering fokussiert auf die Variabilität der Produkte, um die speziellen Anforderungen an verschiedenen Produkten zu befriedigen. Zu dem Application Engineering Prozess zählen vier Subprozessen: Application Requirements Engineering, Application Design, Application Realisation, Application Testing.[5](S. 31) Application Requirements Engineering: Der Application-Requirements-Engineering Subprozess umfasst alle Aktivitäten zur Entwicklung der Anforderungsspezifikation der Anwendungen(Application). Die wiederverwendbare Anzahl der Domain Artefakte ist von den Anwendungsanforderungen abhängig.[5](s. 31f) Application Design: Der Application-Design Subprozess umfasst die Aktivitäten zur Herstellung der Anwendungsarchitektur. Application-Design verwendet die Referenzarchitektur, um die Anwendungsarchitektur zu instanziieren. Dabei werden die benötigte Teile der Referenzarchitektur ausgewählt und anwendungsspezifisch konfiguriert. Die mit Application-Design gebunden Variabilität bezieht sich auf die Gesamtstruktur des Systems.[5](S. 32) Application Realisation: Im Application-Realisation Subprozess wird die konkreten Produkten hergestellt. Der beschäftigt sich hauptsächlich mit der Auswahl und Konfiguration der wiederverwendbaren Software-Komponenten sowie die Verwirklichung von anwendungsspezifischen Assets. Die wiederverwendbaren und anwendungsspezifischen Assets werden hier zusammengebaut.[5](s. 33) Application Testing: Der Application-Testing Subprozess umfasst die erfor-

19 derlichen Aktivitäten, die zur Verifizierung und Überprüfung der Anwendung der Produkte dienen.[5](s. 34) Practice in Product Line Engineering. Springer, Berlin Heidelberg, Prinzipien Die folgenden vier Prinzipien sind die Grundlage für den Erfolg des Software-Produktlinien-Engineerings. Variabilität Management Die einzelnen Produkte werden als Varianten im Rahmen der Produktlinie betrachtet. Damit stellt die Anforderung, dass die Variabilität explizit gemacht und systematisch verwaltet werden muss.[6](s. 7) Business-Orientierung Software Produktlinie Engineering zielt darauf ab, sich mit der langfristigen Unternehmensstrategie zu verbinden.[6](s. 8) Architektur-Orientierung Die technische Aspekte der Software müssen auf die Vorteile der Gemeinsamkeit der einzelnen Produkten basieren.[6](s. 8) Zwei-Lebenszyklus-Ansatz Die einzelnen Systeme basieren auf einem Software- Plattform. Aber gleichzeitig müssen diese Systeme und die Plattform ihre eigenen individuellen Lebenszyklen aufrechterhalten.[6](s. 8) 5. FAZIT Angesichts der hohen Anforderungen sollen die heutigen Softwaresysteme immer leistungsfähiger, zuverlässiger, komplexer, gleichzeitig aber immer günstiger in Produktion und Wartung sowie schneller in Entwicklung und Auslieferung werden. Die Software-Produktlinie gehört zu einen der leistungsfähigeren Ansätze der Wiederverwendung. Das Konzept bedeutet nicht nur eine neue Technologie, sondern eine Art Entwicklung der Software-Business. Dazu gibt es wesentliche Aktivitäten der Produktlinie und praktische Anwendungsbereiche, um die Steuerung und Verwaltung der Software-Produktlinie zu ermöglichen. 6. REFERENCES [1] P. Clements. Reuse and product lines. ftp/wisr/wisr8/wisr8- summary/product.html, December [2] L. M. Northrop. Software product lines essentials. December [3] L. M. Northrop and P. C. Clements. A framework for software product line practice, version report/index.html., December [4] O.A. Feature-oriented software development. February [5] K. Pohl, G. Böckle, and F. van der Linden. Software Product Line Engineering: Foundations, Principles, and Techniques. Springer, Berlin Heidelberg, [6] F. van der Linden, K. Schmid, and E. Rommes. Software Product Lines in Action: The Best Industrial

20 Testen von Produkten und Softwareproduktlinien Jan-David Hof Universität Siegen ABSTRACT Viele Produkte können aus einer Produktlinie abgeleitet werden, deshalb ist es sinnvoll Testverfahren zu entwickeln, die diese Produktlinien komplett abdecken und zudem weitaus effizienter sind, als jedes Produkt einzeln zu testen. Dieser Artikel befasst sich mit der richtigen Ausf ührung der Tests von Softwareproduktlinien und geht genauer auf einige verschiedene Verfahren zum Testen von Softwareproduktlinien und Produkten ein. Weiterhin behandelt diese Ausarbeitung die verschiedenen Herangehensweisen, beleuchtet Kriterien zur Auswahl des Testverfahrens, zeigt anhand einem Beispiel eine Vorgehensweise beim Testen und stellt die Abgrenzung zu Einzeltests dar. 1. EINLEITUNG Eine Softwareproduktlinie bilden Softwarekomponenten/ Programme, die sich in einigen Eigenschaften stark ähneln, beziehungsweise diese teilen und so entsprechende Anforderungen erfüllen. Diese Eigenschaften können sowohl Teil des Designs, als auch Teil der Implementierung sein. In der Regel ist es wesentlich einfacher und profitabler eine Softwareproduktlinie zu entwerfen als jedes Produkt einzeln zu entwickeln. So können direkt alle Produkte dieser Produktlinie verwaltet und behandelt werden, was gerade größeren Unternehmen zum Vorteil gereicht. Softwareproduktlinien vereinfachen das Testen ungemein, da nicht mehr jede Software einzeln getestet werden muss. In diesem Artikel werden Verfahren behandelt, die für das Testen von Softwareproduktlinien entwickelt wurden oder verwendet werden können. Softwareproduktlinien werden beispielsweise oft in der Mikrochipentwicklung und Softwareentwicklung verwendet. Wenn jedes Produkt einzeln entwickelt werden würde, würde dies sehr viel Zeit und Geld kosten. Bei Softwareproduktlinien wird sozusagen nur ein Grundmodell entwickelt, was je nach Anforderungen angepasst, beziehungsweise um verschiedene Features ergänzt werden kann. Somit werden die Kosten, der Aufwand für die Entwicklung und Wartung erheblich gesenkt. Außerdem wird so die Qualität der Produkte gesteigert und das Produkt ist ausgereifter, als bei der Einzelentwicklung. Die Mikrochips werden zum Beispiel in Autos eingebaut um verschiedene Funktionen zu steuern, wobei jeder Chip mehrere Konfigurationsmöglichkeiten besitzt. Ein anderes bekanntes Beispiel neben den Mikrochips ist das Betriebssystem Linux/Unix. Auf dem Linux-Kernel bauen die verschiedensten Betriebssysteme auf, wie zum Beispiel Ubuntu, Debian, opensuse oder verschiedene Android- Versionen. Wobei das System Android selbst auch wieder eine Softwareproduktlinie bildet. Das Basismodell wird direkt von Google geliefert und die verschiedenen Handy-Hersteller passen dieses dann beispielsweise um weitere Funktionen an. Dies hat zur Folge, dass aus eine Softwareproduktlinie oftmals einige tausend verschiedene Variationen von Produkten gebildet werden können. In der Praxis werden Softwareproduktlinien meistens nur dadurch validiert, dass jede einzelne Produktinstanz wie ein einzelnes Produkt getestet wird. In dieser Methode verwendet man dann schon bekannte und bewährte Methoden und Verfahren zum Testen, somit kann ein Großteil der Variabilität der Produkte vernachlässigt werden. Da dieses Verfahren aber wegen zu hoher Anzahl an möglichen Produkten in einigen Fällen nicht anwendbar ist, werden neue Verfahren gesucht um den Testaufwand zu minimieren. 2. TESTEN VON SOFTWARE In der Regel wird Software durch Ausführung des Programms, also durch Ausführung der verschiedenen Features/Funktionen und die im nachfolgenden aufgeführten Testverfahren getestet. Jedoch kann es auch sinnvoll sein das Testen mit verschiedenen Inspektionsmethoden zu kombinieren. Dazu gibt es beispielsweise die Methode der statischen Analyse, womit allgemeine Qualitäts-Attribute des Quellcodes ermittelt werden, wodurch er zielgerichtet optimiert werden kann. So ist auch eine Überprüfung unvollständiger Software-Artefakte, insbesondere derjenigen die mit Variabilität versehen sind, möglich. Dabei ist der Schwerpunkt auf die Überprüfung von Quellcode-Richtlinien, -Konventionen und auf die Überprüfung von Fehlern in nebenläufigen Systemen gerichtet. 2.1 Testartefakte Testartefakte sind Produkte, die während des Testens entstehen, dies können zum Beispiel Testergebnisse, Pläne(Vorgehen, Struktur,...) und genauere Beschreibungen des Tests sein.

21 Testplan Ein Test wird nach einem Testplan durchgeführt, welcher die Fälle/Schritte festlegt, die durchgeführt werden sollen. Diesen Fällen werden Prioritäten abhängig von den während des Testens zur Verfügung stehenden Ressourcen zugewiesen. Weiterhin werden die zu verwendeten Tools, Programme und Werkzeuge bestimmt. Test-Case Im Test-Case sind die Bedingungen und die zu erwartenden Eingabe- und Ausgabedaten festgelegt. Jeder Testfall besitzt ein fest definiertes Ziel und enthält mehrere verschiedene Testszenarios, durch die das Ziel auf einem anderen Weg zu erreichen ist. Außerdem werden die Testumgebung, die Anforderungen/Bedingungen, die erfüllt werden müssen festgelegt. Weiterhin wird bestimmt, was im Falle eines Fehlers passieren und wie der Test ausgeführt werden soll. Test-Case Szenario Das Szenario beschreibt die Abfolge der Aktionen, was schlussendlich zum Erreichen des vorhin festgelegten Testziels führt. Jede Aktion hier ist ein sogenannter Szenario Step. Test-Case Szenario-Step Ein Szenario-Schritt enthält genauere Informationen darüber, wie genau der entsprechende Schritt ausgeführt werden soll und liefert gegebenenfalls das zu erwartende Ergebnis des Schrittes. Domain-Testing Die Domain-Tests gehören zu den am weitesten verbreiteten Softwaretestverfahren. Das Ziel des Domain- Tests ist es, die Ergebnisse aus der Domain-Engineering Phase zu validieren. Domain-Testing soll die Fehlerursachen in den Domainartefakten aufdecken und erzeugt wiederverwendbare Artefakte für das Application- Testing. Der Domain-Test beinhaltet die gleichen Aktivitäten wie der Einzelsystemtest, muss aber gleichzeitig Variabilität berücksichtigen und besitzt kein ausführbares System. (Einzelne Funktionen werden getestet). Application-Testing Application-Testing verwendet Domain-Test Artefakte um die Fehler in der Produktinstanz aufzudecken. Anders als beim Domain-Testing muss jede Programminstanz einzeln getestet werden (Zusammenwirken wird getestet). Bei dem Test wird eine Instanz der Produktlinie auf ihre anfangs festgelegten Spezifikationen überprüft. In [2] wird auf den Aufbau des Domain- und Application- Engineering und deren Beziehungen nochmals genauer eingegangen. Zur Veranschaulichung dient die folgenden Grafik: Test summary report Hier wird eine Übersicht über die Ergebnisse der Testausführung gegeben. 2.2 Domain und Application Testing Die in der Softwareproduktlinie vorhandene Variabilität spielt bei der Wiederverwendung von Entwicklungsartefakten eine große Rolle. Durch diese Variabilität ist es möglich verschiedene Produkte aus einer Produktlinie abzuleiten, um so beispielsweise unterschiedlichen Kundenwünschen gerecht zu werden. Die Erstellung der Produktlinien-Plattform/Domäne ist Teil des Domain-Engineering. Nach der Produktableitung können natürlich auch noch weitere individuelle Anforderungen oder Funktionalitäten zum Produkt hinzugefügt werden, was im Application-Engineering geschieht. Die Test-Aspekte müssen von Anbeginn des Entwicklungsprozesses an klar sein, um zu gewährleisten, dass die Anforderungen und Design das Testverfahren unterstützen. Das Ziel des Domain- Tests ist im Prinzip die Ausgaben der anderen Subprozesse des Domain-Engineering zu validieren. Die Auswahl der Test-Cases richtet sich nach den Ausgaben von requirements engineering, domain design und domain realisation. Domain-Testing befasst sich mit lose gekoppelten und wiederverwendbaren Komponenten des Programms, Application-Testing mit kompletten Programmen. Beide Testverfahren wirken zusammen und bilden Synergien. Figure 1: Problemdefinition für das Testen von Software-Produktlinien [5] 3. TESTVERFAHREN Es gibt einige Testverfahren, wobei sich manche besonders hervorgetan haben. Im folgenden werden die wichtigsten Testverfahren aufgelistet und näher beschrieben. Ursprünglich wurde nur getestet, um während der Entwicklung Fehler im Programm zu finden und um festzustellen, ob das Programm die vorgegebenen Anforderungen erfüllt. In der heutigen Zeit wird auch getestet um die Zuverlässigkeit der Software einzuschätzen, was besonders wichtig ist, wenn die Software immer wieder verwendet beziehungsweise eingesetzt wird. Eine Fehlfunktion wird im schlechtesten Fall bei jedem Produktableger auftreten. Für Softwareproduktlinien gibt es verschiedene Granularitäts-Ebenen auf denen getestet werden kann. Die folgenden Ebenen sind besonders wichtig: -Modultest(Unit-Test): hier werden die einzelnen Komponenten überprüft -Integrationstest: untersucht die Interaktion zwischen den Komponenten

22 -System-Test: validiert das Gesamtsystem gegen seine Spezifikationen/Anforderungen Da im Domain-Testing applikationsspezifische Varianten fehlen und einige Fehler nur durch Interaktionen auffallen können wird das Testen komplexer. Interaktionen sind im Domain-Test nicht möglich, da hier kein ausführbares Programm zu Grunde liegt. Erst im Application-Test können verschiedene Interaktionen am fertigen Programm getestet werden. Die Variabilität und das Fehlen vollständiger Applikationen erfordert deshalb spezielle Teststrategien, die sich von den Einzeltests unterscheiden. Bei Teststrategien von Softwareproduktlinien muss der Unterschied zwischen Domain-Engineering und Application-Engineering genauso wie die Variabilität berücksichtigt werden. Im Folgenden werden fundamentale Teststrategien behandelt. 3.1 Test-Level Ein Test-Level ist von der Granularität der zu testenden Produkte bestimmt und deren Anforderungen werden als Test-Referenzen definiert. Die verschiedenen Testtechniken und -Methoden sind in der Regel in diesen, beziehungsweise zwischen den verschiedenen Testlevels angesiedelt, welche da wären: Modultest Mit Hilfe des Modultests wird das Verhalten der einzelnen Komponenten, Methoden oder Klassen, welche in der korrespondierenden Signatur spezifiziert wurden, gegen deren Eingabe/Ausgabe Verhalten überprüft. Der Modultest ist ein Test-Level, welches oft von Software-Entwicklern angewandt wird. Dabei testet der Programmierer jede implementierte Methode, Prozedur und Funktionalität der Einheit. Dieser Test validiert das Verhalten des implementierten Codes gegen seine Spezifikation. Das Modultesten kann in Black-Box und White-Box-Tests aufgeteilt werden, worauf auch in [6] eingegangen wird. Beim Black Box testen erzeugt das Testprogramm eine Umgebung(setzt Variablen) und ruft die zu testenden Funktionen mit entsprechenden Parametern auf. Im Anschluss prüft das Testprogramm die Rückgabewerte der Funktionen und die Umgebung auf Änderungen. Generell sollten Black- Box-Tests anhand der Spezifikationen des zu testenden Programmes entwickelt werden um Abhängigkeiten von der eigentlichen Implementierung zu vermeiden. Weiterhin ist es empfehlenswert Negativ-Tests 1 zu schreiben. In der Regel werden für Black-Box-Tests unter anderem die Spezifikationen/Dokumentationen benötigt, um die Funktionsweise abzuleiten. Sie sind nicht dazu geeignet Fehler in bestimmten Komponenten aufzudecken. Wenn aber keine Dokumentation verfügbar ist (Extreme Programming) oder man Fehler in bestimmten Komponenten aufdecken will, muss dazu der White-Box-Test benutzt werden, weil der Black- Box-Test dazu nicht fähig ist. Dabei wird sich an die interne Struktur des Modells gehalten. Im Allgemeinen werden Black-Box-Tests also dazu verwendet Fehler 1 falsche Parameter, Randfälle, etc. also im Allgemeinen Dinge die fehlerhafte Programme schnell überfordern gegenüber der Spezifikation aufzudecken und White- Box-Tests benutzt man um Fehler in den Komponenten aufzudecken. Des Weiteren gibt es mittlerweile für die meisten Programmiersprachen spezielle Frameworks für Unit-Testing. Integrationstests Der Integrationstest validiert das Verhalten von zwei oder mehr Komponenten, die miteinander die Konfiguration bilden, welche in der Architektur spezifiziert wurde. Der Integration Test wird in der Regel an Komponenten angewendet, deren Verhalten den Spezifikationen entspricht, also den Modultest erfolgreich bestanden haben. Aber die Funktionalität der Konfiguration kann sich noch von der Spezifikation unterscheiden. Die Integrationstests sollen anschließend überprüfen, ob die Komponenten untereinander fehlerfrei ablaufen und die Kommunikation zwischen diesen funktioniert. Auch hier gibt es wieder zwei verschiedene Strategien für die Durchführung von Integrationstests, wobei beide Verfahren aber auch miteinander kombiniert werden können. Beim Top-Down Verfahren, wird in den höchsten Abstraktionsschichten begonnen die verschiedenen Komponenten zu testen, um dann die darunter liegenden durch Mock 2 - und Dummy 3 Objekte zu simulieren. Diese werden dann schrittweise durch reale Teilsysteme ersetzt. Bei der Bottom-Up Strategie hingegen werden streng nacheinander die einzelnen bereits fertigen Komponenten verknüpft und getestet, so dass am Ende das komplette System abgebildet wurde. Sowohl auf Dummy-Objekte, als auch auf eine frühzeitige Simulation des Gesamtsystems wird verzichtet. So kann die Korrektur der Fehler, beim Zusammensetzen der Teile, durchaus sehr aufwendig werden. Systemtests Nachdem der Integrationstest erfolgreich abgeschlossen wurde, kann der Systemtest durchgeführt werden. Dieser überprüft das Verhalten des ganzen Systems gegenüber seiner Systemanforderungsspezifikationen. Die Eigenschaften/Einzelheiten des Systems werden normalerweise nicht während des Tests erdacht. Weiterhin definieren die Systemanforderungen das gesamte Verhalten des Systems. Der Systemtest ist der letzte Abschnitt einer ganzen Folge von Integrationstests von zunehmend größeren Teilsystemen, in welchem das Gesamtsystem mit der Interaktion seiner Komponenten und den bestehenden Abhängigkeiten den Untersuchungsgegenstand bildet. Hierbei wird das Gesamtsystem mit Hilfe von funktionalen und nicht funktionalen Tests, mit den im Integrationstest verwendeten Methoden überprüft. Endo-Testing Dummies und Mocks implementieren Komponenten- Interfaces, die von den getesteten Interfaces benötigt werden. Endo-Testing ist eine spezielle Art von Testen, bei denen Mocks genutzt werden, so kann auch das Verhalten von Komponenten verifiziert werden. Diese Art 2 liefert bei bestimmten Funktionsaufrufen bestimmte Rückgabewerte 3 Ein Objekt, welches im Code weitergereicht, aber nicht verwendet wird. Sie werden eingesetzt, um Parameter mit Werten zu füllen

23 von Test ist eigentlich auch ein Modultest, jedoch werden hierbei Mock-Objekte verwendet. Normale Modultests prüfen nur den Zustand der Komponenten. Dummies verkörpern eine Implementierung von Interfaces, die im Dummy definiert wurden, die Methoden des Interfaces besitzen dabei bestimmte Rückgabewerte. Der Dummy kann zu einem Mock Erweitert werden, um das richtige Aufrufverhalten zu testen. Der Dummy erwartet bestimmte Methodenaufrufe in einer festgelegten Reihenfolge. Der Test schlägt fehl, wenn diese nicht eingehalten wird. 3.2 Kriterien für SPL-Teststrategien Durch die Beschreibung der drei Test-Level wird verdeutlicht, dass Variabilität hohe Auswirkungen auf das Testen hat. Bei den Modultests hält sich dies noch in Grenzen, aber bei höheren Testlevel(Integration- und Systemtest) bei denen statt einzelnen Modulen größere Teile des Systems getestet werden, treten immer mehr Probleme auf. Aufgrund der großen Auswirkungen besonders auf Integration- und Systemtest-Ebenen werden für Softwareproduktlinien bestimmte Teststrategien notwendig. Im folgenden wird auf fünf essenzielle Kriterien zur Entwicklung/Auswahl einer Teststrategie für Softwareproduktlinien eingegangen. Overhead/ Überlauf Im Overheadkriterium wird überprüft, ob die Anzahl der ausgeführten Aktivitäten und die Anzahl der Artefakte, welche erstellt wurden, auch mit weniger Aufwand hätten erzielt werden können. Überlauf resultiert meist daraus, dass ein Artefakt mehrere Male produziert wurde und Aktivitäten ausgeführt wurden, die nicht erforderlich/überflüssig waren. 3.3 Aufteilung nach Verantwortlichkeit/ V- Modell Zeit um Testartefakte zu erstellen Ein Großteil der Zeit des Testens wird damit verbracht, Artefakte zu erstellen. Die Zeit, die dies in Anspruch nimmt ist abhängig von der Anzahl der Artefakte und der Schwierigkeit diese zu erstellen. Die Variabilität der Softwareproduktlinien macht dies eher komplex, aber durch die gute Wiederverwendbarkeit wird die verlängerte Entwicklungszeit wieder ausgeglichen. Dieses Kriterium ist die Schätzung für die Zeit, die benötigt wird, um Testartefakte zu erstellen, dabei sollte berücksichtigt werden, in wie weit die Teststrategie die Wiederverwendung der Testartefakte unterstützt und wie gut es die Entwicklung von Testartefakten beschleunigt. Absent Variants/ Abwesende Varianten Absent Variants sind Varianten, die im Domain- Engineering noch nicht realisiert wurden, sondern erst im Application-Engineering. Dieses Kriterium wertet aus, wie gut eine Teststrategie mit absent variants zurecht kommt. Early Validation Es ist sehr wichtig die Entwicklungsartefakte früh, also so bald wie möglich zu überprüfen um eine gute Qualität der Produktlinie zu gewährleisten. Je später Fehler festgestellt werden, desto schwerer und aufwendiger ist es, diese wieder zu beseitigen. Weiterhin ist dieses Kriterium ein Indikator für die benötigte Zeit zwischen Fertigstellung und Überprüfung des Artefakts. Diese Zeit sollte möglichst gering ausfallen. Learning Effort Hier wird im Bezug auf die Zeit bewertet, die benötigt wird, um die Testaktivitäten zu bewerkstelligen. Vielleicht hat ein Entwickler bisher nur mit Einzelsystemen gearbeitet und muss den Prozess des Softwareproduktlinientestens und Variabilität erst noch erlernen. Figure 2: V-Modell [1] Die verschiedenen Testlevel(Unit, Integration, System, Endo) werden den Domain- und Application-Engineering Prozessen zugeordnet. Hier könnten dann zum Beispiel die Unit- Tests im Domain-Engineering und die anderen Testlevel im Application-Engineering ausgeführt werden. Die linke Seite des V-Models enthält die gemeinsamen Abstraktionsebenen der Software. Auf dieser Seite werden die Tests im Laufe der Entwurfs- und Implementierungsphase des Systems entworfen. Die rechte Seite dahingehend behandelt die Testlevel der Abstraktionslevel, hier werden dann die Tests auch durchgeführt. 3.4 Inkrementelles Testen Subsysteme werden in der Regel inkrementell getestet. Auch bei diesem Verfahren werden die Produkte einzeln getestet, der Aufwand wird aber jedoch durch Verwendung von Regressions-Testverfahren 4 deutlich verringert. In der Regel werden dabei zwei zueinander von der Funktionalität ähnliche Produkte nach speziellen Kriterien ausgew ählt, wobei aber nur ein Produkt ausführlich getestet werden muss, da nach der Grundidee dieses Verfahrens nur die veränderten Komponenten des zweiten Produkts nochmal getestet werden müssen. Die gemeinsamen Komponenten wurden somit schon mit dem ersten Produkt getestet, weshalb man dies 4 Regressionstest bezeichnet die Wiederholung bereits durchgeführter Tests

24 nicht wiederholen muss und so nur die veränderten Komponenten zu testen hat. Das entscheidende Problem bei diesem Testverfahren ist, dass entschieden werden muss, welches Produkt ausführlich getestet wird und bei welche Komponenten kein Test mehr notwendig ist. 3.5 Brute-Force-Strategie (BFS) Die Grundidee hierbei ist, die Qualität so früh und so komplett wie möglich zu prüfen, was auch dem Early validation Kriterium entspricht. Die Brute-Force-Strategie setzt sich zum Ziel die Qualität des Produkts durch einen umfangreichen Domain-Test für alle möglichen Programme durchzuführen. Also wird auf den Testebenen (Modultest, Integrationstest, Systemtest) für alle möglichen Konfigurationen getestet. Da die BFS-Methode alle Anwendungen berücksichtigt, wird hier nicht auf der Anwendungsebene getestet(application-testing). Dadurch, dass Komponenten fehlen dauert der domain realisation process länger, welcher die Implementation aller Komponenten beinhaltet. Diese Strategie erscheint ziemlich sinnvoll, da Early validation erfüllt ist, nichtsdestotrotz ist diese Strategie in der Praxis nicht umsetzbar. Das Problem ist, dass um die Korrektheit des Programms zu gewährleisten, jede Kombination der Eingabewerte/Konfigurationen getestet werden m üsste. Aber durch die Komplexität der meisten Programme ist dies nicht machbar, da die Kombinationsmöglichkeiten viel zu hoch sind und dadurch die Anwendung von BFS verhindert wird. Auch bei einer kleinen Software mit zum Beispiel 10 Eingabefeldern und 3 Möglichkeiten gäbe es schon 3 10 = verschiedene Testfälle. 3.6 Kombinatorisches Testen Kombinatorisches Testen ist ein Ansatz mit dem die Anzahl der Testfälle minimiert wird, die Testabdeckung aber möglichst groß bleibt, dabei müssen besonders die Abhängigkeiten zwischen Parametern und Parameterwerten beachtet werden. Eine Anwendung für das kombinatorische Testen wäre beispielsweise das paarweise Testen. Dabei wird die Erkenntnis genutzt, dass der Großteil der Softwarefehler aus einzelnen Datenwerten oder der Interaktion zweier Datenwerte entsteht. Aus diesem Grund werden nur die Eingabefelder paarweise mit jedem weiteren Eingabefeld getestet, dabei werden zwischen beiden Eingabefeldern trotzdem alle möglichen Konfigurationen gebildet. 3.7 Pure-Application-Strategie (PAS) Die Pure-Application-Strategie ist sozusagen das Gegenteil von der Brute-Force-Strategie, also wird nur auf Anwendungsebene und nicht auf Domainebene getestet. PAS betrachtet dabei nur die Artefakte, welche auch in der aktuellen Anwendung Verwendung finden. Auch diese Methode eignet sich wiederum weniger für die Praxis, unter anderem weil es in zwei der vorher festgelegten Kriterien eher schlechte Ergebnisse erzielt. Zum einen ist der Überlauf unverhältnismäßig hoch, jedes Testartefakt für die Anwendungen wird immer wieder neu für jede Anwendung entwickelt. So hat diese Softwareproduktlinienteststrategie keinen Mehrwert gegenüber normalen Einzelsystem-Tests. Weiterhin verursacht die PAS dabei einen sogenannten Flaschenhals im Softwareproduktlinien-Entwicklungsprozess. So m üssen die Tests immer für jede Anwendung wieder von vorne anfangen. Das zweite Problem ist die fehlende Early validation, das Testen beginnt hier erst, wenn die erste Anwendung komplett fertiggestellt ist. So können die Stakeholder 5 kein Vertrauen in die Qualität der Software setzen und es kostet einiges an Aufwand und Geld die Fehler zu beseitigen. 3.8 Product-by-product-testing/Sample- Appllication-Strategie (SAS) Bei Product-by-product-testing wird jede einzelne Produktinstanz individuell getestet wobei auf Standard-Tests des Software-Engineering zurückgegriffen wird. Aber aufgrund der Menge der Produkte ist es in vielen Fällen nicht möglich jedes Produkt einzeln zu testen. Deshalb werden bei der Sample-Application-Strategie nicht alle Anwendungen getestet, sondern nur eine einzige oder einige wenige Anwendungen. Mit den ausgewählten Anwendungen wird sozusagen ein repräsentatives System gebildet, welches auch getestet werden kann. Im Folgendem werden alle gemeinsamen Komponenten im Kontext der ausgewählten Anwendungen getestet, des Weiteren werden die ausgewählten Anwendungen auch selbst getestet. Bis nicht alle möglichen Anwendungen getestet wurden, muss Application-Testing auch ausgeführt werden, wobei dann natürlich die wiederverwendbaren Teile aus dem Domain-Testing verwendet werden. Eine Besonderheit von SAS ist, dass nicht nur eine Early validation der ausgewählten Anwendungen, sondern auch von allen weiteren Anwendungen, die Gemeinsamkeiten mit den ausgewählten Anwendungen haben, durchgef ührt wird. Außerdem ist durch die Definition der Beispielanwendungen gewährleistet, dass die Ableitung einer Anwendung möglich ist und dass die Bindungsmechanismen richtig funktionieren. Die Zeit, die benötigt wird, um ein Testartefakt zu erstellen, ist genauso hoch wie bei einem Einzelsystem, wird aber durch die Wiederverwendbarkeit ausgeglichen. Das Problem der Absent variants wird durch die Erzeugung von Beispielanwendungen terminiert und das Early validation -Kriterium wird auch erfüllt. Genauso ist das Learning effort -Kriterium für diese Strategie positiv, da Produkte und Aktivitäten hier ähnlich zu denen des Einzelsystem-Tests sind. Aber das Overhead -Kriterium fällt nicht gut aus, da für das Testen eine oder mehrere Anwendungen realisiert werden müssen, dafür wird aber bewiesen, dass Anwendungen von der Produktlinie abgeleitet werden können. Das Problem dabei ist aber, dass meist nicht die minimale Menge von Produkten bestimmt wird, stattdessen erzeugt man zu viele sich äquivalent zueinander verhaltende Produkte. Das Application-Testing ist dabei überflüssig, weil nur eine geringe Auswahl späterer Programme getestet werden. Es werden aber auf jeden Fall gemeinsame Artefakte der Produktlinie und Bindungsmechanismen an Variationspunkten verifiziert. 3.9 Commonality and Reuse Strategy (CRS)/ Wiederverwendung von Test Assets Bei dieser Testmethodik wird das Testen gleichermaßen auf Domain- und Application-Testing, durch Erzeugung von wiederverwendbaren Testartefakten aufgeteilt. Grundidee ist, im Domain-Engineering wiederverwendbare Testartefakte zu entwickeln, die dann für das Testen von Produkten verwendet werden können, welche im Application- Engineering an das jeweilige Produkt angepasst werden. Demnach werden beim Domain-Testing überwiegend Domain- 5 Personen, die ein Interesse an dem Produkt haben

25 Artefakte getestet, während gleichzeitig Tests vorbereitet werden, welche das Testen von variablen Artefakten im Application-Testing ermöglichen. Die CRS erfüllt das Time to create -Kriterium sehr gut, die Einbeziehung der Variabilität in die Testartefakte reduziert die Anzahl an Testfällen erheblich. Ein Domaintest-Artefakt definiert, wie die Varianten später getestet werden sollen. Im Application-Test können diese Artefakte dann wiederverwendet werden und die vorher definierten Varianten können in Gruppen(je nach Gemeinsamkeiten) zusammen getestet werden, wobei diese dann als Application-Artefakt bezeichnet werden. Die Entwicklung der wiederverwendbaren Testartefakte beinhaltet eine Teilvalidation der Testreferenzen, die benutzt wurden(domain requirements, reference architecture, interface descriptions). Deshalb unterscheidet sich das Early validation -Kriterium nicht von den Einzeltests. Der Learning effort ist aber höher, als bei den anderen Strategien, weil es relativ viel Zeit kostet, bis die Tester Testartefakte, die Variabilität beinhalten spezifizieren können. Dadurch, das die Variabilitäten in die Testartefakte gebunden/zusammengefasst werden, wird die Wiederverwendbarkeit erhöht, es werden keine unnötigen Artefakte oder Aktivitäten mehrmals ausgeführt. Dies hat zur Folge, dass es keinen Overhead gibt. CRS ermöglicht einen höheren Wiederverwendungswert durch die Einführung von Variabilität in den Testprozess als SRS, ist dafür aber auch komplexer. Um von beiden Vorteilen zu profitieren, lassen sich diese Verfahren auch kombinieren. SAS ermöglicht zum einen eine frühe Verifizierung und CRS zum anderen die Verwendung von Testartefakten Regressionstest(Application-Testing) Im Regressionstest werden bereits durchgeführte Tests wiederholt, um (unter anderem) zu gewährleisten, dass die Fehler behoben wurden und auszuschließen, dass die Veränderungen Auswirkungen auf andere Teile der Software haben. Es gibt zwei Arten von Regressionstests. Beim progressiven Regressionstest hat sich die Spezifikation geändert, also muss ein modifiziertes Programm gegen die modifizierte Spezifikation getestet werden. Der korrigierende Regressionstest behandelt Fälle, in denen die Spezifikationen unverändert geblieben sind, also müssen nur die geänderten Anweisungen mit bestehenden Testfällen getestet werden. Generell werden Regressionstests immer dann ausgeführt, wenn sich die Software geändert hat und können auch schon im Entwicklungszyklus durchgeführt werden. werden. Eine 0 wird gesetzt, wenn die Produktlinie beim Testen nicht besser abschneidet als ein Einzel-System. Ein + wird vergeben, wenn das Kriterium voll und ganz erfüllt wurde und ein - indiziert, dass nahezu alle Konfigurationen das Kriterium unzureichend erfüllt haben. 4. TEST ACTIVITIES Das Testen von Software ist in die fünf folgenden Schritte/Aktivitäten unterteilt: Domain Test Planning Damit der Test geplant werden kann, müssen die entsprechenden Referenzen, Spezifikationen und Anforderungen vollständig vorliegen. Weiterhin ist es für die Aufstellung des Zeitplans wichtig zu wissen, zu welchem Zeitpunkt die entsprechenden Komponenten zum Testen bereit stehen. Beim Domain-Testing baut die Testplanung vollkommen auf die Domain-Artefakte, domain requirements, reference architecture, design artefacts, Variabilität auf. Als erstes muss die Teststrategie ausgewählt werden, anhand derer werden dann die benötigten Ressourcen ermittelt und die zu verwendeten Testfälle ausgewählt und priorisiert. Außerdem sollten die zur Verfügung stehenden Werkzeuge/Tools bestimmt werden. Allgemein soll der Testplan den gesamten Testprozess definieren. Weiterhin sollte der Plan in jedem Testschritt neu definiert bzw. aktualisiert werden. Es sollte auch festgelegt werden, unter welchen Bedingungen der Test abgebrochen werden sollte, Termine, Rollen und auch das Risikomanagement sollte bedacht werden. Domain Test Specification Das Ziel dieses Abschnittes ist es, wiederverwendbare Testfälle zu erstellen, was in zwei Schritten erreicht wird. Als erstes werden die Logik-Testf älle, in welchen aber die konkreten Details und GUI-Elemente fehlen, erstellt. Im zweiten Schritt werden dann die Testf älle mit den beim ersten Schritt fehlenden Informationen verfeinert. Detaillierte Testfälle werden ausschließlich für gemeinsame Artefakte erzeugt. Es würde zu einem erhöhten Überlauf führen, wenn für jedes mögliche Element der Produktlinie ein detaillierter Testfall erstellt werden müsste. Nichtsdestotrotz können generische und logische Testfälle generiert werden, die den Anforderungen entsprechen und die Designvariabilität wiedergeben, welche im Variabilitäts-Modell spezifiziert wurde. Für 3.11 Zusammenfassung jedes Testartefakt wird eine Abhängigkeitsreferenz zu der zugehörigen Testreferenz gebildet. Diese Referenzen Table 1: Strategieübersicht [3] werden benötigt, um die Wiederverwendbarkeit von Time to Absent Early validation effort Wenn die Systemtestfälle von Use-Cases abgeleitet wer- Learning Overhead Testartefakten im Application-Testing zu unterstützen. create variants BFS den, ist beispielsweise jeder Systemtestfall dem zugehörigen Use-Case zugeordnet. So können die Tester mit PAS SAS wenig Aufwand die zugehörigen Testfälle identifizieren, CRS indem sie den Abhängigkeitsreferenzen zwischen Anforderungen und Testartefakten folgen. SAS/ CRS Domain Test Execution, Recording, and Completion Die vorangehende Tabelle liefert eine grobe Übersicht, ob die verschiedenen Testverfahren die jeweiligen Testkriterien erfüllen, beziehungsweise wie schlecht oder gut diese erf üllt Während des Tests werden die Testfälle angewandt und dabei wird ein Testprotokoll erzeugt, welches die Testfälle, die Versionsnummer des Testobjekts und das

26 Testergebnis enthält. Wenn dies so durchgeführt wird, ist die Verifizierung und Wiederverwendbarkeit des Tests gewährleistet. Während der Fertigstellung des Tests wird das Testprotokoll analysiert und die Fehler eliminiert. Zum Abschluss wird ein zusammenfassendes Testprotokoll aufgesetzt. eine Pflichtfunktion darstellt. In [4] sind noch weitere Informationen über Testartefakte, insbesondere über Test Plans zu finden. 5. UNTERSCHIED ZU EINZELSYSTE- MEN Bei Softwareproduktlinientests ist das Testen in die Prozesse: Domain-Testing und Application-Testing unterteilt. Außerdem ist die Variabilität entgegen zu Einzelsystemtests eine großer Aspekt der Entwicklung/des Testens und wird dementsprechend berücksichtigt. Die Schwierigkeit beim Domain-Testing ist, dass keine einzelne Konfiguration der Komponenten besteht, die getestet werden könnte. Daher sind verschiedenen Teststrategien notwendig, um eine frühe Validation der Softwareproduktlinie und die Wiederverwendung von Testartefakten durch Application- Engineering sicherzustellen. Test Activities finden zwischen Domain-Engineering und Application-Engineering Anwendung. Um zu verhindern, dass Testartefakte für jede Produktinstanz gebildet werden müssen, bietet Domain- Testing variable/wiederverwendbare Testartefakte. Die Variabilität der Testartefakte resultiert aus der Variabilität in domain-requirements, domain-design, domain-realisation, der Entwicklungsumgebung. Bei Testen von Einzelsystemen bildet man hingegen bei jedem Programm neue Artefakte und Variabilität wird auch nicht berücksichtigt. Das Ziel des Application-Testing und der Einzelsystemtests ist es, eine hinreichende Qualität des Programms durch eine Reihe von verschiedenen Tests zu gewährleisten, worin sich beide nicht unterscheiden. Im Kontrast dazu muss bei dem Testen von SPLs berücksichtigt werden, dass die Anforderungen/Spezifikationen bzw. die Programminstanz, die getestet werden soll schrittweise im Domain-Engineering und Application-Engineering erstellt werden. 6. ANWENDUNGSBEISPIEL Ein Anwendungsbeispiel für eine Softwareproduktlinie ist das Handy-Betriebssystem Android, welches selbst wiederum von Linux abstammt. Für jedes Gerät wird das Basismodell weiter angepasst beziehungsweise um weiter Features erweitert. So benutzt zum Beispiel Samsung andere Android-Varianten als HTC, aber auch innerhalb der Firmen gibt es für die unterschiedlichen Modelle unterschiedliche Produktinstanzen(angepasste Androidsysteme). Zum einen werden Kernel und Treiber angepasst, zum anderen aber auch grundlegendes Design, Funktionen werden verändert oder auch hinzugefügt, etc. Im folgenden wird eine Android-Produktlinie betrachtet, die über die standardmäßigen Grundfunktionen, Datenübertragungsmöglichkeiten und einige Extrafunktionen verf ügt. Grundfunktionen sind beispielsweise das Telefonieren und das Versenden von Nachrichten. WLAN, Bluetooth, UMTS gehören zu den Datenübertragungsmöglichkeiten. Mögliche Extrafunktionen könnten der MP3-Player und eine Kamera sein. Wobei die Grundfunktionen hierbei Pflichtfunktionen darstellen, außerdem soll das Handy ein UMTS-Handy sein, womit dies auch Figure 3: Feature-Modell des Anwendungsbeispiels [5] Die Extrafunktionen können immer beliebig kombiniert werden, wobei aber immer eine Funktion mindestens ausgewählt sein muss. Gegebenenfalls lassen die Extrafunktionen auch noch weitere Konfigurationen zu. Bei der Kamera könnte zum Beispiel eine mit 3MP oder 8MP verbaut werden. Weiterhin sollten bei der Herleitung/Planung von Produkten auch Restriktionen bedacht werden, so muss wenn MMS- Nachrichten verschickt werden sollen, auch die Kamera implementiert werden. (In unserem Beispiel schließen sich auch MP3-Player und Bluetooth aus) Dieser Produktinstanz können dann auch noch produktindividuelle Erweiterungen hinzugefügt werden, hierbei ist diese Erweiterung nicht Teil der Handy-SPL, sondern wird im Rahmen des Application-Engineering zum Produkt hinzugefügt. Dies kann zum Beispiel ein Spiel sein, welches auf bestimmten Produktinstanzen der Produktlinie spielbar sein soll. Natürlich kann auch hier nicht jedes Produkt der SPL einzeln getestet werden, da mit jedem Feature der Variationsgrad der zu testenden Instanzen erheblich wächst. Aus dieser eben definierten Produktlinie würden sich alleine schon 26 gültige Produktvarianten ableiten lassen. In Folge ist es unerlässlich die Anzahl der zu testenden Feature-Kombinationen zu reduzieren, dabei sollte aber darauf geachtet werden, dass der Test nicht verfälscht wird und die Aussagekraft erhalten bleibt. Wenn eine Produktinstanz aus der SPL-Plattform abgeleitet wurde, kann diese im Rahmen des Application-Engineering um individuelle Anforderungen erweitert werden, wie in unserem Beispiel ein Spiel. Anschließend sollten die implementierten Erweiterungen zusammen mit den bereits vorhandenen Funktionen der SPL getestet werden um die Integration zu gewährleisten. Dafür müssen die Testfälle des Domain-Engineerings wiederverwendbar sein und um bestimmte Eigenschaften, die auf den produktindividuellen Anforderungen basieren, ergänzt werden. Diese könnten dann beispielsweise durch wiederverwendbare Testartefakte, Inkrementelles Testen (Regressionstest), Sample-Appllication- Strategie, getestet werden. Das kombinatorische Testverfahren baut hier auf die Idee auf, dass die eben definierten Features als Parameter der Softwareproduktlinie betrachtet werden können. Deshalb bietet sich hier eine Methode zum reduzieren des Testaufwands auf Basis der Parameter an. Anwendung findet dies in Algorithmen, die das Feature-Modell auf paarweises Testen vorbereiten und dies dann realisieren. Diese Methode nutzt die Erken-

27 ntnis, dass der Großteil aller Softwarefehler aus einzelnen Datenwerten oder der Interaktion zweier Datenwerte resultiert. Daher werden lediglich die Eingabefelder paarweise mit jedem anderen Eingabefeld getestet, wobei zwischen diesen zwei Feldern weiterhin alle möglichen Kombinationen gebildet werden. [5] Anschließend werden die Constraints (Einschränkungen, Bedingungen) zwischen Features ausgewertet und die Erzeugung von ungültigen Featurekombinationen verhindert. Die daraus resultierenden Produktinstanzen können dann mit den gängigen Testverfahren getestet werden, da diese keine Variabilität mehr besitzen. 6.1 Tiefenreduktion des Feature-Modells Für die Ausführung des paarweisen Testens werden Parameter mit korrespondierenden Werten benötigt. So können dann die Parameter paarweise kombiniert und die Werte zusammen getestet werden. Damit das paarweise Testen möglich ist, wird für das Feature-Modell die sogenannte Tiefenreduktion ausgeführt. Hierbei werden zuerst alle Features zusammen mit ihrer Notation iterativ nach oben verschoben und direkt dem Wurzelknoten untergeordnet (Durch logische Ausdrücke lässt sich die semantische Äquivalenz zum Ursprungsmodell nachweisen). Im Folgendem werden allen Features Kind- Knoten zugeordnet, welche den möglichen Belegungen der Features entsprechen. Dabei enthält ein optionales Feature, wie zum Beispiel Kamera die Werte Kamera und Kamera, diese werden in dem Feature-Modell als Alternativ-Gruppe dargestellt. Diese Regeln werden auf alle Teilbäume angewandt, welche immer aus drei Ebenen bestehen. Die Kind- Knoten werden auf Ebene des Vaterknotens gehoben, stehen also unter der Wurzel. Schlussendlich sieht das Modell dann so aus: Figure 4: Tiefenreduziertes Feature-Modell [5] Das paarweise Testen kann nun unter der Verwendung der Parameter und zugehörigen Parameterwerte des tiefenreduzierten Feature-Modells ausgeführt werden. Um dies zu realisieren, können verschiedene Algorithmen zur Anwendung kommen. Grundidee der Algorithmen ist die Vermutung, dass Fehler in der Integration von Features in zweier- Kombinationen auftreten. Darstellung eines Beispielalgorithmus: Als erstes wird eine Liste aller möglichen paarweisen Kombinationen erstellt. Um gültige Produktinstanzen bestimmen zu können, wird eine Kombination aus dieser Liste als Anfangswert einer neuen Produktinstanz verwendet und mit Hilfe des Forward-Checking- Algorithmus 6 für jeden Parameter ein Wert bestimmt. 6 Forward-Checking ist eine Methode des Backtrackings. Ein gültiges Produkt liegt vor, wenn für jeden Parameter ein Wert gefunden wurde, der keinen anderen in der Produktinstanz enthalten Wert durch eine Exclude-Kante ausschließt, weiterhin müssen alle Require-Kanten erfüllt sein. Wenn ein derartiges Produkt generiert wurde, werden alle Kombinationspaare, die sich in diesem Produkt befinden aus der Liste der benötigten Kombinationen entfernt. Schließlich werden für die übrigen Kombinationen weitere Produktinstanzen generiert. Wenn der Forward-Checking- Algorithmus aus dem Anfangswert keine gültige Produktinstanz erzeugen kann, wird die Kombination verworfen. Als Ergebnis wird hierbei die Menge von Produktinstanzen, die beispielsweise genutzt werden k önnen, um die Softwareproduktlinie durch die Ausführung von Systemtests auf jeder Produktinstanz zu validieren, betrachtet. Wenn dieser Algorithmus auf unser Beispiel angewendet wurde, bleiben acht Produktinstanzen von den anfänglichen 26 übrig. Diesen Algorithmen gibt es auch als Java-Plugins (z.b. pure::variants). 6.2 Individueller Produkttest im Application- Engineering Damit der individuelle Produkttest ausgeführt werden kann, müssen die Testfälle des Domain-Tests auf die Features des Feature-Modells angepasst werden. Dabei werden Mapping- Objekte erzeugt, in denen die Features zusammen mit den Produktcharakteristika von den Testfällen miteinander in Beziehung gesetzt sind. Dort werden dann die Features in Form von Bedingungen mit abhängigen Produktcharakteristika notiert, dabei hat jedes Mapping-Objekt einen eindeutigen Bezeichner, der die Bindungskonfiguration darstellt. Dadurch wird bei einem Testfall die Auswahl des Produktcharakteristika in Abhängigkeit einer Feature-Auswahl ermöglicht. Die Mapping-Objekte bilden dann zusammen das Mapping-Modell der Softwareproduktlinie. Ein Beispiel wäre eine Bindungskonfiguration, in der in Abhängigkeit vom Feature Bluetooth im Testfall: Verbindung mit Handy herstellen ein Test mit der Verbindung via Bluetooth hinzugefügt wird. Noch ein weiteres Beispiel wäre, falls das Handy über die Features MMS und Kamera verfügt, wird über die Bindungskonfiguration im Testfall: Konfiguration der Verbindungen das Produktcharakteristika zur Kamera und MMS-Konfiguration hinzugefügt. Schließlich können die Testfälle für unsere Produktdefinition mit Hilfe des Mapping- Modells konfiguriert werden. In unserem Fall ist dies nur der Testfall: Konfiguration der Verbindungen. Dieser Testfall muss nun nur noch um die individuellen Eigenschaften des Programms, welches auf dem Gerät laufen soll, erweitert werden. 7. FAZIT In diesem Artikel wurde allgemeines Hintergrundwissen zu Softwareproduktlinien und dem damit verbundenen Testen aufgebaut. Es wurde verdeutlicht, wie umfangreich sich dies Zunächst wird eine Variable mit einem Wert ihrer Produktlinie/Domäne instanziiert. Im nächsten Schritt wird eine andere Variable einem Wert zugeordnet, der einheitlich mit den vorherigen Zuordnungen ist. Dies wird immer wieder wiederholt

28 gestaltet und mit wie vielen verschiedenen Verfahren das Testen von Softwareproduktlinien möglich ist. Es wurde auf die einzelnen Testartefakte eingegangen, welche während des Testens entstehen und auf die nachfolgende Tests aufbauen. Im Anschluss wurde sich mit Domain- und Application- Testing auseinander gesetzt, wobei die Unterschiede und das Zusammenwirken erläutert wurden. Weiterhin wurden die Testebenen(Modultest, Integrationstest, Systemtest) betrachtet, auf welchen sich die Tests abspielen. Dabei kristallisierte sich heraus, dass man das Testverfahren nur anhand bestimmter Kriterien auswählen sollte, da die Variabilität große Auswirkungen auf das Testen hat. Schließlich wurden die verschiedenen Teststrategien vorgestellt und anhand der Kriterien bewertet. Unter anderem wurde dabei genauer auf das V-Modell des Softwaretestens, Inkrementelles Testen, Brute-Force-Strategie, Pure-Application-Strategie, Sample- Application-Strategie und Commonality and Reuse Strategie eingegangen. Weiterhin werden die einzelnen Schritte des Softwaretestens näher erklärt, welche das Planen, die Spezifikationen, Ausführung und Dokumentation des Testes behandeln. Anschließend wurde anhand einem Anwendungsbeispiel das kombinatorische Testen mit Hilfe von Feature-Modellen durchgearbeitet und erläutert, wobei auch auf Tiefenreduktion des Feature-Modells eingegangen wird. Zum Schluss setzt sich die Arbeit mit dem individuellen Produkttest speziell im Application-Engineering auseinander. 8. REFERENCES [1] V model, [2] K.Pohl, G.Böckle, and F. der Linden. Domain engineering, application engineering. In Software Product Line Engineering, pages , Berlin, [3] K.Pohl, G.Böckle, and F. der Linden. Product line test strategies. In Software Product Line Engineering, Berlin, [4] J. D. McGregor. Testing a software product line [5] S.Oster and A.Wübbeke. Verknüpfung von kombinatorischem plattform- und individuellem produkt-test für software-produktlinien. TU Darmstadt, Universität Paderborn, [6] G. Wirtz. Integrationstests: Strategien und herausforderungen Systementwicklung/Software-Implementierung/Testenvon-Software/Modultest.

29 Modellierung und Implementierung von Features in Software-Produktlinien Kromberg, Konstantin Universität Siegen Siegen, Deutschland ABSTRACT Im Folgenden geht es um Features (Merkmale) und deren Implementierung in Softwareproduktlinien (kurz: SPLs). Am Anfang wird die Bedeutung von Features in SPLs beschrieben und es wird veranschaulicht wie man diese modelliert. Es werden verschiedene Möglichkeiten Features zu modellieren vorgestellt, darunter das Feature-Diagramm, das Komponenten-Diagramm und aussagenlogische Ausdrücke. Anschließend machen wir den Schritt vom Modell zur Implementierungseinheit. Dabei werden wir folgende Ansätze betrachten: Kompositionsansatz, Annotationsansatz und Transformationsansatz. Es werden Vor-und Nachteile der verschiedenen Techniken herauskristallisiert, sodass am Ende eine Bewertung erfolgen kann. 1. EINLEITUNG Eine Softwareproduktlinie ist eine Menge von Softwaresystemen, die wohl-definierte Gemeinsamkeiten und Unterschiede aufweist. In der Entwicklung von SPLs haben Features eine sehr wichtige Rolle. Da diese die wesentlichen Ziele einer SPL realisieren, nämlich Produktvielfalt und die Wiederverwendung von einzelnen Artefakten. Die Produktvielfalt wird durch die Anzahl der verschiedenen Features reguliert. Sind beispielsweise n Features optional und unabhängig von einander so lassen sich theoretisch 2 n Produktvarianten realisieren. So ist es beispielsweise mit bereits 33 unabhängigoptionalen Features schon möglich eine maßgeschneiderte Variante für jeden Menschen auf diesem Planeten zu erstellen. Die Wiederverwendung von den einzelnen Artefakten trägt zur schnelleren und einfacheren Entwicklung von Produkten bei. Ziel ist es auf die Kundenwünsche einzugehen und die erwarteten Features in möglichst kurzer Zeit umzusetzen. Bei der Entwicklung einer SPL stellt sich auch deshalb oft die Frage welche Features denn überhaupt relevant und wirklich notwendig sind. Denn mit steigender Vielfalt kann man zwar flexibel auf die Kundenwünsche eingehen, aber man erhöht dadurch auch den Arbeitsaufwand, die Komplexität und somit den Preis der einzelnen Produkte. Mit diesen wirtschaftlichen Aspekten beschäftigt sich das sogenannte Scoping, das hier nicht näher betrachtet wird. Bei einem Feature handelt es sich um ein für den Benutzer sichtbares Merkmal oder ein Charakteristika einer Domäne 1. Durch eine bestimmte Kombination dieser Merkmale lassen sich unterschiedliche Produktvarianten erstellen. Gemeinsamkeiten beziehungsweise Unterschiede der einzelnen Varianten werden somit durch Features ermöglicht. Hat man nun alle geplanten Features in der Domäne definiert und kann den Produktwünschen des Kunden nachgehen, möchte man auch noch sicherstellen, dass in Zukunft geforderte Features ebenfalls möglichst leicht in die bestehende SPL integriert werden können. Diese Möglichkeit wird durch übersichtliche und leicht wartbare Feature-Implementierungen, die hier vorgestellt werden, ermöglicht. 2. FEATURE-MODELLIERUNG An dieser Stelle werden verschiedene Möglichkeiten der Feature- Modellierung vorgestellt. Diese ist besonders bei großen Systemen wie einer SPL unabdingbar. Sie erleichtert das Verständnis und verschafft einen guten Überblick über Anforderungen und Ziele der Produktlinien. Bei manchen Darstellungsformen, wie beispielsweise dem Feature-Diagramm, erhält man sogar einen guten Überblick über die Menge der möglichen Produktvarianten. 2.1 Feature-Diagramm Das Feature-Diagramm beschreibt die Konzepte einer Domäne näher. Es hat eine grafische, baumartige Form und repräsentiert die Variabilität einer Produktlinie. Aufgrund dieser Darstellungsform lassen sich durch die Abhängigkeiten zwischen den Charakteristika lassen sich alle möglichen Produkt-Konfigurationen einer SPL ermitteln. Auch die Kommunikation zwischen Softwareentwicklern und Kunden wird dadurch vereinfacht, denn man bekommt eine visualisierte Übersicht der geforderten Features. Anhand von solchen Feature-Modellen lassen sich auch Abhängigkeiten unter Features beschreiben und man kann sie später zur Konfiguration benutzen. Es gibt verschiedene Darstellungsformen der Feature-Diagramme, die sich nur minimal voneinander unterscheiden, wie beispielsweise die Feature orientierte Domain- Analyse (kurz FODA). 1 Eine Domäne ist ein Anwendungsgebiet.

30 Figure 1: Feature-Diagramm Das Feature-Diagramm in Figur 1, erstellt mit FeatureIDE 2, beschreibt eine einfache Graphen-Produktlinie. Es werden die Beziehungen zwischen den Features deutlich. Wie man anhand der Legende erkennen kann, existieren viele verschiedene Modellierungsmittel. Features werden mittels der Farbe abstrakt oder konkret dargestellt, wobei die Abstrakten keine Implementierungseinheit benötigen. Darüber hinaus können sie obligatorisch (ausgefüllter Kreis) oder optional(leerer Kreis) sein. Man kann die Kinder Verunden, Verodern oder alternativ miteinander verknüpfen. Die Verundung wird mit einem ausgefüllten Kreis über dem Feature symbolisiert und bedeutet, dass das Feature für die Produktkonfiguration ausgewählt werden und die Produktvariante ohne diese Auswahl ungültig wäre. Die Veroderung wird mit einem ausgefüllten Dreieck zwischen den Kanten dargestellt und besagt, dass mindestens ein Kind ausgewählt werden muss, während die Alternativ-Verknüpfung durch ein leeres Dreieck repräsentiert wird und bedeutet, dass genau eins der Kinder ausgewählt werden muss. Des Weiteren lassen sich auch noch Einschränkungen in das Diagramm einfügen, die mittels aussagenlogischer Ausdrücke realisiert werden. Durch ShortestPath Directed Weighted ist zum Beispiel für das Feature ShortestPath die Auswahl von Directed und Weighted eine Voraussetzung. So lässt sich anhand des Beispiels aus Figure 1 bereits erkennen, dass ein Graph entweder gerichtet oder ungerichtet sein muss, weil die beiden Features Directed und Undirected alternativ-verknüpft sind. Auch kann ein Graph nur gewichtet oder ungewichtet sein. Ungewichtet ist der Graph, wenn man nur das abstrakt obligatorische Feature Weight, welche keine Implementierungseinheit beinhaltet, anwählt. Durch das optionale Feature Weighted kann ein gewichteter Graph implementiert werden. Um einen Algorithmus zu wählen, den der Graph unterstützen soll, hat man die Möglichkeit die Features StrongConnceted und/oder ShortestPath auszuwählen. 2.2 Komponenten-Diagramm Komponenten-Diagramme stellen die interne Struktur von einzelnen Features dar. Sie zeigen auf, wie einzelne Kompo- 2 research/featureide/ nenten miteinander verdrahtet sind und welche Schnittstelle(n) ein Feature bereitstellt beziehungsweise anfordert. Implementierungsdetails werden hinter den Schnittstellen gekapselt und bleiben verborgen weshalb die Komponenten auch als BlackBox bezeichnet werden. Die bereitgestellten Schnittstellen werden mit einem von der Komponente ausgehenden Strich und einem Kreis -die geforderten hingegen mit einem Halbkreis am Ende symbolisiert. Die Verbindungsstücke werden auch Konnektoren genannt. Figure 2: Komponenten-Diagramm

31 In Figure 2 sieht man beispielsweise, dass das Feature ShortesPath zwei Schnittstellen, einmal von Weighted und einmal von Directed, anfordert und ein Interface bereitstellt. Die übrigen beiden Features stellen jeweils eine Schnittstelle zum Feature ShortestPath bereit. 2.3 Aussagenlogische Ausdrücke Durch aussagenlogische Ausdrücke lassen sich Feature- Konfigurationen auf Richtigkeit überprüfen, da das Feature- Modell durch einen logischen Ausdruck dargestellt werden kann. Dabei wird jedes Merkmal als eine boolesche Variable betrachtet, die bei Auswahl des Features wahr und bei Nichtauswahl falsch ist. Anschließend wird die Feature-Konfiguration, also die aktuelle Produktvariante, in den aussagenlogischen Ausdruck eingesetzt und auf ihre Gültigkeit überprüft. Wenn nun der unten angegebene Ausdruck für eine Feature- Konfiguration aus Figure 1 wahr ist, ist die Konfiguration und somit das Produkt gültig. Der Schritt vom Feature- Diagramm zur aussagenlogischen Formel ist automatisierbar. GPL (GraphType (Directed Undirected) (Directed Undirected) (Weight (Weighted Weight)) Algorithms (StrongConnected Transpose StronglyConnected) (ShortestPath Directed Weighted) class GPL{ void addvertex(vertex v) { //... #ifdef SP // Vertex ist gewichtet // Graph ist gerichtet #endif SP } void Algorithms(Graph g) { #ifdef SP //Methode #endif SP #ifdef SC //Methode #endif SC } Wie man anhand des Beispiels erkennen kann, werden die Codefragmente der Features ShortestPath(SP) und Strong- Connected(SC) nur in den Quellcode eingebunden, wenn die Features zuvor durch #define SP und/oder SC definiert wurden. Ansonsten werden die Codestücke einfach ignoriert beziehungsweise nicht eingebunden. Dieses Verfahren ermöglicht dem Programmierer einen hohen Grad an Verfeinerungen und Detailarbeiten, führt jedoch schnell zur Unübersichtlichkeit und ist zudem noch sehr fehleranfällig. 3. FEATURE IMPLEMENTIERUNG Es gibt verschiedene Ansätze und Techniken den Schritt von der Modellierung zur Implementierung zu machen. Hier werden die folgenden Featureimplementierungsansätze betrachtet: der Annotationsansatz, der Kompositionsansatz und der Transformationsansatz. 3.1 Annotationsansatz Beim Annotationsansatz teilen sich alle Features eine gemeinsame Codebasis. Mit Hilfe von Annotationen werden einzelne Code-Fragmente mit zugehörigen Features im Quelltext markiert. Um diese Codefragmente zu markieren, gibt es verschiedene Techniken. Zum einen kann man den entsprechenden Code, der zu einem Feature gehört, mit Präprozessor-Direktiven umschließen wie beispielsweise mit #ifdef FEATURE #endif- Anweisungen. Eine weitere Möglichkeit ist, dass man die entsprechenden Codefragmente farblich markiert. Man kann sogar einzelne Kommata annotieren, um die Granularität dieses Ansatzes zu verdeutlichen. Um anschließend aus der gemeinsamen Codebasis eine gültige Variante zu erstellen, werden alle nicht erwünschten Features vor der Übersetzung des Quellcodes aus der Basis entfernt. Ein Beispiel für die Präprozessor-Direktive #ifdef und #endif könnte in der Programmiersprache C folgendermaßen ausschauen: Ein Beispiel wie so etwas in CIDE aussehen könnte ist in Figure 3 zu sehen. In diesem GPL-Beispiel sind die Methoden, Figure 3: CIDE-Beispiel die zum ShortestPath-Feature gehören, farblich unterlegt. Falls man nun ein Produkt ohne dieses Feature haben möchte, so kann man den blau markierten Code vor der Übersetzung entfernen. 3.2 Kompositionsansatz Der Kompositionsansatz besagt, dass jedes Feature als separate, physisch getrennte Codeeinheit implementiert wird. Jedes Feature stellt im Grunde ein eigenes Modul dar. Um ein Produkt nun erstellen zu können, werden die dazugehörigen Module anhand der Auswahl von Features ermittelt und zusammengefügt. Üblicherweise passiert dieses zur

32 Übersetzung 3 - oder Startzeit. In Figure 4 wird das grundlegende Vorgehen illustriert. und dweight. Durch das Schlüsselwort super wird die Methode display um eine weitere Ausgabe (System.out.println) erweitert. Die zusammengesetzte Klasse würde folgendermaßen aussehen: public class Vertex{ public String name; public String predecessor; int dweight; private boolean isdirected = true; public void display(){ System.out.println( Pred + predecessor + DWeight + dweight + ); //... System.out.println(); } } Figure 4: Idee des Kompositionsansatz Das Basisprogramm wird in unserem Beispiel durch die Klasse Vertex implementiert und anschließend mit einem separaten Modul, welches das ShortestPath-Feature realisiert, erweitert. Dabei beschreibt das Schlüsselwort refines die Verfeinerung der Klasse Vertex. Es werden zwei neue Methoden, backup und restore eingebunden und die Methode push wird überschrieben. Das Schlüsselwort Super verweist auf die verfeinerte Klasse. Die Implementierung könnte mit dem featureorientierten Generator AHEAD folgendermaßen ausschauen: public class Vertex { public String name; public void display(){ //... System.out.println(); } } public refines class Vertex { private String predecessor; private int dweight; private boolean isdirected = true; public void display(){ System.out.println( Pred + predecessor + DWeight + dweight +); super.display(); } } Mit diesem Ansatz lässt sich der Quellcode, der zu einem Feature gehört, leicht auffinden und gegebenenfalls korrigieren. 3.3 Transformationsansatz Der delta-orientierte Transformationsansatz besteht im wesentlichen aus zwei Komponenten. Zum einen aus einem Kernmodul und zum anderen aus einer Menge von Delta- Modulen (=Deltas). Das Kernmodul umfasst die Menge an Features, die ein komplettes und gültiges Produkt darstellen. Das Kernmodul ist also, mehr oder weniger, eine beliebige Produktkonfiguration und wird auch als Startpunkt bezeichnet, weil von ihm aus alle übrigen Produkte generiert werden können. Es enthält also alle obligatorischen Features und gegebenenfalls eine Menge von optionalen Features, bei denen man von vornherein sagen kann, dass sie später in den meisten Produkten enthalten sein werden. Das Kernmodul kann wie sonst als gültiges Einzelprodukt entwickelt werden. Die Delta-Module spezifizieren Veränderungen, die an dem Kernmodul gemacht werden dürfen, um neue und gültige Produkte zu erhalten. Die Operationen, die durch die Delta- Module definiert werden, sind add,modify und remove. Im Konkreten bedeutet es also, dass Klassen, Methoden oder Schnittstellen hinzugefügt, gelöscht oder modifiziert werden können. Bei der Modifikation können die super Klasse, der Konstruktor oder einzelne Methoden verändert werden. Für Delta-Module kann es auch sogenannte Anwendungsbedingungen geben, die besagen, dass ein Delta nur im Falle einer bestimmten Feature-Konfiguration angewandt werden darf. Diese Anwendungsbedingungen können komplexe Einschränkungen enthalten, um Code-Duplikate zu vermeiden und dem optionalen Feature-Problem entgegen zu wirken. Das Basisprogramm und das Feature-Modul werden anschließend komponiert und es entsteht eine zusammengesetzte Klasse Vertex mit den zusätzlichen Attributen predecessor 3 Wird auch als Compile-Zeit bezeichnet und bildet das Gegenstück zur Laufzeit. Es behandelt die Analyse des zu übersetzenden Programms

33 Generell haben Delta-Module die folgende Form: delta <name> [after <delta names>] when<application condition>{ removes <class or interface name> adds class <name><standard Java class> adds interface <name><standard Java interface> modifies interface <name>{<remove,add, rename method header clauses>} modifies class <name>{<remove,add,rename field clauses> <remove, add, rename method clauses>} Durch folgenden Quellcode wird ein Kern-Modul mit den obligatorischen Features GraphType, Weight und Algorithms implementiert. Die Syntax für den Kern ist von der Form: core <Feature names> {<Java classes and interfaces>} core GraphType,Weight,Algorithms { interface Display{void print();} class Vertex implements Display{ public String name; //... } class Edge{ //... } } Ein Implementierungsbeispiel für die Delta-Module DDirected und DShortestPath könnte folgendermaßen ausschauen. delta DShortestPath after DDirected,DWeighted when ShortestPath { modifies class Vertex{ //... } modifies class Edge{ //... } } Im Delta-Modul DShortestPath hat man noch die Besonderheit, dass es erst nach den Delta-Modulen DDirected und DWeighted in Kraft treten darf, weil es durch die Einschränkung in dem Feature-Diagramm definiert wurde. Um nun gültige Produkte zu generieren, werden die Delta- Module schrittweise auf das Kernmodul angewendet. Die Reihenfolge der Deltas spielt eine wichtige Rolle und kann optional durch die after-klausel festgelegt werden. Diese Klausel besagt, dass ein Delta nur dann auf das Kernmodul angewendet werden darf, falls die Deltas, die in der after- Klausel stehen, bereits angewendet wurden. Somit erhält man eine Abhängigkeit der Deltas untereinander. Diese Abhängigkeit ist wichtig, um sich eine Garantie zu verschaffen, dass beispielsweise die Methode, die man mit einem Delta verändern möchte, vorher durch ein anderes Delta definiert wurde. Man kann die after-klausel auch nutzen, um Konflikte zwischen Delta-Modulen, falls diese auf eine gemeinsame Methode zugreifen, zu vermeiden. Hat man nun eine bestimmte Feature-Konfiguration vorgegeben, so sucht man zunächst alle Delta-Module, die eine gültige Anwendungsbedingung zu der Feature-Konfiguration aufweisen (d.h. die when-klausel ist erfüllt) und dann wendet man diese, unter der Berücksichtigung der after-klauseln, an. delta DDirected when Directed{ modifies interface Display{ System.out.println( Vertex +name+ connected to...); //... } modifies class Vertex { boolean isdirected = true; //... } } Bei Anwendung des Delta-Moduls DDirected wird das Interface Display um eine Textausgabe erweitert, die die Nachbarknoten anzeigt. Des Weiteren wird die Klasse Vertex modifiziert, indem dort eine neues Attribut namens isdirected hinzugefügt wird. Die Anwendungsbedingung für das Delta- Modul steht hinter der when-klausel und lautet Directed. Das heißt, dass das Delta-Modul immer nur dann angewendet werden darf, wenn das Feature Eval in der Feature- Konfiguration enthalten ist. 3.4 Das optionale Feature-Problem Das optionale Feature-Problem tritt auf, wenn zwei (oder mehr) optionale Features in der Domänen-Analyse als unabhängig voneinander definiert wurden, sich jedoch in der Implementierung herausstellt, dass die beiden abhängig voneinander sind. Dies hat zufolge, dass manche Produktvarianten, die in der Domäne gültig sind, nicht ohne weiteres implementiert werden können. So muss man beispielsweise entweder auf etwas Variabilität verzichten oder mehr Arbeitsaufwand in die Implementierung investieren. Zudem kann sich das ineffizient und zu Gunsten einer schlechteren Code-Qualität auswirken. Das Problem soll an dem Beispiel, entnommen aus [7], in Figure 6 erklärt werden. Das Feature Statistics sammelt alle möglichen Informationen zu einer Datenbank, wie beispielsweise Tabellengrößen, Kardinalitäten und Transaktionen pro Sekunde. Da nicht jedes System so ein Feature benötigt, weil es unter anderem zur Verlangsamung führt, ist dieses Feature optional.

34 Figure 5: Feature-Modell links und Komponenten-Diagramm rechts einer Datenbankmanagementsystem-SPL Das optionale Merkmal Transactions, welches die ACID 4 - Eigenschaften sicherstellt, wird beispielsweise bei read-onlyoder single-user-system auch nicht benötigt. Somit erscheinen beide Features erst einmal unabhängig voneinander zu sein, wie man auch dem Feature-Modell in Figure 6 entnehmen kann. Bei der Implementierung wird jedoch deutlich, dass, wenn man das Feature Statistics einbindet, man auch auf das Charakteristika Transactions angewiesen ist, weil Statistics Informationen zu Transaktionen pro Sekunden sammelt. Mithilfe des Komponenten-Diagramms lässt sich die Implementierungs-Abhängigkeit zwischen den beiden Merkmalen darstellen. Nun gibt es zwei Maßnahmen dieses Problem anzugehen. Zum einen kann man sagen, dass man, aufgrund der Implementierungsabhängigkeit, keine Produktvarianten, die das Feature Statistics enthalten, ohne Transactions zulässt zu Kosten der Variabilität. Zum anderen kann man die Feature-Implementierung auf verschiedene Arten abändern und die Variabilität beibehalten. Man kann beispielsweise die Abhängigkeit dadurch eliminieren, indem man das Verhalten mancher Produktvarianten verändert. So könnte man in unserem Beispiel DBMS 5 mit dem Feature Statistics implementieren, die keine Informationen zu Transaktionen pro Sekunden sammelt. Dieser Ansatz funktioniert in der Realität eher selten. Der Code, der die beiden Features abhängig von einander macht, kann auch verschoben werden. Das würde bedeuten, dass man die Funktion, die die Transaktionen pro Sekundeäufsammelt, anstatt in Statistics, in Transactions implementiert. Somit würde Transactions einen Teil der Funktionalität des Statistics-Features übernhemen. Eine Weitere Lösung wäre das Statistics zwei mal zu implementieren, sodass einmal die Transaktionen pro Sekunden gezählt werden und einmal nicht. Die Auswahl der Funktionalität macht sich abhängig von dem Feature Transactions. Hat man also das Feature Transactions eingebunden, wird Statistics mit der Funktion, die Transaktionen zu zählen, eingebunden - ansonsten nicht. 4 Automicity, Consistency, Isolation, Durability 5 Datenbankmanagementsysteme Der vierte Lösungsansatz, der oben bereits schon vorgestellt wurde, ist der mit Direktiven zu arbeiten. Will man beispielsweise das Feature Transactions in seiner Produktvariante haben, so werden die mit #ifdef und #endif umrahmten Codefragmente, die die Transaktionen zählen, aus der Codebasis nicht entfernt. Hat man das Feature nicht implementiert, werden die Codefragmente aus der Basis gelöscht. Die hier letzte Methode mit diesem Problem umzugehen, ist das Extrahieren des Codes, durch den die Features abhängig werden, in ein separates Modul. Dieses Vorgehen besteht aus zwei Schritten. Zunächst muss der Code aus den abhängigen Features entfernt und anschließend in ein neues Modul, das sogenannte derivative modul, implementiert werden. Das Modul wird bei der Generierung des Produkts zur Implementierung herangezogen, falls beide Features ausgewählt wurden. 3.5 Bewertung Um ein aussagekräftiges Fazit zu ziehen und die vorgestellten Ansätze bewerten zu können, führen wir im Folgende einige Kriterien, die es zu untersuchen gilt, ein. Auffindbarkeit von Featurecode. Da es nicht viele Features braucht, um ein unübersichtliches und unstrukturiertes Codegerüst zu produzieren, ist die Auffindung von Codestücken, die zu einem Feature gehören, umso wichtiger. Eine Strukturierung des Quellcodes ist daher wünschenswert. Eine gute Auffindbarkeit erleichtert das Verständnis und die Wartung des Quellcodes. Es lassen sich einfacher Fehler finden und beheben. Das Auffinden der Implementierungseinheit, die zu einem Feature gehört, lässt sich im Kompositionsansatz gut bewerkstelligen, da jedes Feature in einem Modul untergebracht wird. Beim Annotations-und Transformationsansatz ist es schlechter, weil die Codestücke im Basisprogramm beziehungsweise den Deltas verstreut sein können. Daher punktet der Kompositionsansatz hier. Modularität. Ziel der Modularität ist die Unterstützung von Kohäsion 6 und Kapselung 7. Zum einen soll der Featurecode in einzelnen Modulen oder Komponenten vorliegen, sodass man ihn einfach zusammenführen kann, und zum anderen sollen Schnittstellen angeboten werden über die die Features interagieren können. Diese Eigenschaft wird praktisch nur vom Kompositionsansatz unterstützt, weil man dort die einzelnen Feature- Module zusammenführen kann. Die beiden anderen Ansätze unterstützen diesen Aspekt nicht. Granularität. Granularität beschreibt das Maß an Verfeinerungen, die dem Programmierer geboten werden. Grobe 6 beschreibt die Abbildung von Programmeinheit auf Einheit/Aufgabe 7 bzw. Datenkapselung bezeichnet das Verbergen von Daten hinter Schnittstellen

35 Granularität bedeutet beispielsweise, dass nur das Entfernen und Hinzufügen von Dateien oder Verzeichnissen ist. Wohingegen feingranulare Konzepte das Löschen, Hinzufügen und Verändern von Verzeichnissen, Methoden und Parametern unterstützen. Hier profitiert man von den Annotations-und Transformationsansätzen, weil man durch Direktiven, Refines und Deltas den Featurecode bis ins kleinste Detail verändern kann. Beim Kompositionsansatz ist das Hinzufügen und Entfernen zwar möglich. Aber nicht das Manipulieren von Anweisungen in einzelnen Methoden. Sicherheit. Sicherheit bedeutet in diesem Zusammenhang, dass die Ansätze die Korrektheit der einzelnen Produktvarianten sicherstellen. Beim Kompositionsansatz wird dieses Kriterium erfüllt, weil dort die syntaktische Korrektheit durch Sprachmechanismen garantiert wird. Auch der Transformationsansatz stellt durch die Anwendungsbedingung sicher, dass man am Ende ein gültiges Produkt generiert. Der Annotationsansatz weist hier Schwächen auf, weil man, beispielsweise mit Direktiven, nur eine Klammer oder eine Bedingung falsch umrahmen muss und man bereits ein ungültiges Produkt erhält. Sprachunabhängigkeit. In Puncto Sprachunabhängigkeit liegen alle drei Ansätze gleich auf. Sowohl Präprozessoren als auch das Komponieren können die Grammatiken beliebiger Sprachen benutzen. Deltas können ebenfalls unabhängig von der Sprache definiert und benutzt werden. Table 1: Vor-und Nachteil der Ansätze Annota. Kompos. Trans. Auffindung Modularität Granularität Sprachunabhä sehr gut unterstützt; + gut unterstützt; - schlecht unterstützt; gar nicht unterstützt Wie man an der Tabelle erkennen kann, haben die Ansätze ihre Vor- und Nachteile, die teilweise komplementär zueinander sind. Eine Kombination wäre daher wünschenswert. In [2] wird ein integrierter Ansatz vorgestellt, der die annotative und komponierte Methode vereinigt und somit nur mit den Stärken beider Ansätze arbeitet. Der integrierte Ansatz für das Stack-Beispiel könnte folgendermaßen aussehen: Hier werden die grobgranularen Features in einzelne Module untergebracht und bei feingranularen Features wird annotiert. Für das Beispiel in Figure 7 bedeutet es, dass die beiden Funktionen backup und restore dem Kompositionsansatz nach als separate Codeeiheit vorliegen und der Aufruf der Methode backup in push wird dementsprechend annotiert. Bei der Generierung einer Programmvariante werden zuerst die benötigten Module komponiert und anschließend die annotierten Implementierungseinheiten herausgelöst oder beibehalten. Figure 6: Stack-Beispiel mit integriertem Ansatz 4. FAZIT Features haben eine bedeutende Rolle in SPLs. Es wurden einige Darstellungsformen aufgeführt, die sowohl die Zusammenhänge zwischen den Features aufzeigen als auch den Überblick einer SPL sichern. Anschließend wurde der Annotations-, der Kompositions-, und der Transformationsansatz vorgestellt und die verschiedenen Vor- und Nachteile der Ansätze herauskristallisiert. Durch die Kriterien wurde deutlich, dass entweder eine Kombination der Ansätze sinnvoll ist oder je nach Anwendungsfall entschieden werden soll, welchen Ansatz man bei der Feature-Implementierung wählt. 5. REFERENCES [1] Dr. Christian Kästner Vorlesung: Softwareproduktlinien - Konzepte und Implementierung https: // www. uni-marburg. de/ fb12/ ps/ teaching/ ss11/ spl? language_ sync= 1, 2015 [2] Sven Apel, Christian Kästner, Christian Lengauer, Vergleich und Integration von Komposition und Annotation zur Implementierung von Produktlinien, 2009 [3] Sebastian Krieter Anwendungsspezifische Generierung von Quelltext-Dokumentationen für die Feature-Orientierte Programmierung, 2014 [4] Daniel Lüddecke Extraktion von Feature-Modellen aus Implementierungsartefakten, 2012 [5] Ina Schaefer, Lorenzo Bettini, Viviana Bono, Ferruccio Damiani, Nico Tanzarella.Delta-oriented Programming of Software Product Lines, 2010 [6] Wikipedia. C-Programmierung: Präprozessor http: // en. wikibooks. org/ wiki/ C_ Programming/ Preprocessor, 2015 [7] Christian Kästner, Sven Apel, Syed Saif ur Rahman, Marko Rosenmüller, Don Batory Gunter Saake, On the Impact of the Optional Feature Problem: Analysis and Case Studies, 2009 [8] Dipl.-Inform. Martin Kuhlmann, Refactoring Feature Modules: Disciplined Generation of Reusable Modules, 2011

36 Anwendungsbeispiele im SPL-Umfeld Andreas Rosowski Universität Siegen ABSTRACT Im folgenden Text werden verschiedene Software Produktlinien betrachtet und daraufhin untersucht, welche Optionen beziehungsweise Variationspunkte definiert wurden und mit welchen Techniken die Softwareproduktlinien umgesetzt wurden. Zuerst wird die Softwareproduktlinie von Philips betrachtet. Hierbei handelt es sich um eine Softwareproduktlinie für Fernseher. Es werden die einzelnen Fernseherserien im Vergleich betrachtet. Als nächstes wird die Motorsteuerungssoftware der Firma Bosch untersucht. Hier werden einzelne Motortypen, wie zum Beispiel Benzinbetrieb oder Ethanolgemischbetrieb, ausgewählt und erläutert. Drittens wird eine Heimautomationssoftware untersucht. Hier werden verschiedene Funktionen der Heimautomation behandelt und Variationspunkte ausgearbeitet und vorgestellt. Als Letztes wird der Linux-Kernel betrachtet. Hier werden Kernfunktionen vorgestellt und anschließend auf Variationspunkte untersucht. Bei allen Beispielen wird jeweils am Ende Bezug darauf genommen, mit welchen Techniken diese Software Produktlinien umgesetzt wurden. 1. EINLEITUNG Softwareproduktlinien sind sehr nützlich. Mit Hilfe dieser erspart man sich bei der Softwareentwicklung das ständige Schreiben von neuem Code, indem man bereits vorhandene Teile wiederverwendet und gegebenenfalls ergänzt, um so neue Varianten zu erhalten. Bei der Softwareproduktlinienerstellung werden Variationspunkte definiert, durch die verschiedene Varianten des Produkts definiert werden können. Heutzutage ist dieser Programmieransatz nicht mehr wegzudenken. Wie man an manchen Beispielen sehen wird, werden Softwareproduktlinien in sehr vielen verschiedenen Bereichen entwickelt. Zum Beispiel entwickelt die Firma Philips Softwareproduktlinien, um die unterschiedlichen Softwareanforderungen für ihre Fernseher möglichst kostengünstig und schnell in der Entwicklung bereit stellen zu können. Die Firma Bosch entwickelt Softwareproduktlinien, um mit einem Motorsteuerungsgerät verschiedene Arten von Motoren steuern zu können. Aber auch im nicht-kommerziellen Bereich sind Softwareproduktlinien vertreten. Wie zum Beispiel bei dem Linux-Kernel, wo man vor der Kompilierung auswählen kann, welche Features man haben möchte, welche nicht und welche eventuell als Module kompiliert werden sollen. Aber auch im privaten Bereich sind Softwareproduktlinien vertreten, wie das Beispiel der Heimautomation zeigt. Um Softwareproduktlinien zu realisieren, gibt es unterschiedliche Ansätze. Bei den Techniken, die in diesem Text erwähnt werden, handelt es sich um den Annotationsansatz, bei dem mit Hilfe von Annotationen bestimmt wird, welche Teile des Codes kompiliert werden sollen und welche nicht. Diese Annotationen werden von einem Präprozessor interpretiert. Der zweite Ansatz wird mit Hilfe von einer gewissen Architektur innerhalb der Software realisiert. Bei dem Architekturansatz gibt es nicht eine Herangehensweise, um die Architektur zu realisieren, sondern jede Softwareproduktlinie, die mit Hilfe des Architekturansatzes programmiert wurde, besitzt seine individuelle Architektur, die an die Umstände und Anforderungen der Softwareproduktlinie angepasst wird. 2. ANWENDUNGSBEISPIELE 2.1 Philips Fernseher Philips ist einer der weltgrößten Elektronikkonzerne. Während anfangs Fernseher nur aus Hardware bestanden, beinhalten Fernseher heutzutage voll ausgestattete Mikroprozessoren, die die Hardware steuern. Um Kompexität und Vielfalt ermöglichen zu können, hat Philips diese Softwareproduktlinie entwickelt. Jeder mid-range und high-end 1 Fernseher benutzt Software dieser Softwareproduktlinie. Philips bietet Fernseher der 9000er Serie bis zur 3000er Serie an. Ältere Modelle werden nicht mehr angeboten. Im Folgenden werden nur Fernseher der 5000er Serie bis zur 9000er Serie betrachtet. Jeder Fernseher der 5000er Serie bietet die Möglichkeit, das Bildschirmformat anzupassen, zum Beispiel durch Verschieben, Vollbild oder mit Hilfe von Zoomen. Alle Fernseher bieten die Möglichkeit, die Firmware über USB zu upgraden. Es gibt einen Assistenten für die automatische Firm- 1 Bei high-end Fernsehern handelt es sich um Fernseher, die auf dem neusten Stand der Technik sind, bei mid-range Fernsehern um durchschnittlich gute Fernseher.

37 ware-aktualisierung. Alle Fernseher unterstützen die selben Wiedergabeformate. Es werden unterschiedliche Video-, Audio- und Bildformate unterstützt. Außerdem bieten die Fernseher der 5000er Serie die Möglichkeit Untertitel einzufügen. Jeder Fernseher besitzt eine Energiesparfunktion. Dazu gehören ein Ausschalt-Timer, der Ökomodus und Bildabschaltung im Radiobetrieb. Der Fernseher bietet folgende Audiofunktionen: Smart Stereo und ambi w00x. Es soll ein natürlicher Klang erzeugt werden. Die Soundqualität soll verbessert werden durch Incredible Surround, automatische Lautstärkeeinstellung und Bassverstärkung. Die Fernseher haben eine Vielzahl von Anschlüssen, unter anderem HDMI-Anschlüsse, USB-Anschlüsse, Satellitenanschluss und einen Kopfhörerausgang. Zusätzlich werden EasyLink 2 Funktionen angeboten. Zu den weiteren Funktionalitäten gehören eine Videotextfunktion und eine Signalstärkeanzeige. Folgende Variationspunkte wurden definiert: Es gibt Fernseher, die unterstützen die Ambilight-Technologie 3. Bei den Fernsehern der 5000er Serie handelt es sich um die 2-seitige Version von Ambilight. Ein weiterer Variationspunkt besteht darin, dass manche Fernseher Smart-TVs sind. Sie bieten also bestimmte Zusatzfunktionalitäten an. Insbesondere wird hierdurch möglich, auf das Internet zuzugreifen. Philips Fernseher mit SmartTV bieten eine Vielzahl von Apps an. Außerdem wird ein Browser zur Verfügung gestellt. Alle SmartTV Fernseher bieten HbbTV an. Ein Smart-TV hat außerdem den Vorteil, dass er Philips-Geräte automatisch erkennt. Verschiedene Assistenten unterstützen den Nutzer bei der Geräteverbindung, bei der Netzwerkinstallation und bei Einstellungen. Smart TV Geräte bieten Smart Sound 4 an. Neben der bereits erwähnten Möglichkeit, die Firmware über USB zu upgraden, besteht bei Smart-TV Geräten die Möglichkeit, die Firmware online zu aktualisieren. Einige Geräte haben zudem einen Lichtsensor verbaut, der im Rahmen der Energiesparfunktion die Helligkeit anpasst. Ein weiterer Variationspunkt liegt bei der Bildoptimierung. Hier gibt es drei verschiedene Möglichkeiten. Zum einen Pixel Precise HD in Verbindung mit Digital Natural Motion und Micro Dimming, zum anderen gibt es Pixel Plus HD in Verbindung mit Micro Dimming und es gibt Digital Crystal Clear[2]. Im Vergleich zur 5000er Serie wurde die 6000er Serie dahingehend erweitert beziehungsweise geändert, dass alle Fernseher der 6000er Serie nun SmartTVs sind. Außerdem bie-tet Ambilight nun mehr Funktionen. Zum Beispiel gibt es bei der 6000er Serie einen Lounge-Modus und Ambilight wurde mit dem Lichtsensor verknüpft, so dass Ambilight auch an die Helligkeit angepasst werden kann. Waren die Fernseher der 5000er alle Full-HD-Fernseher, sind manche der 6000er Serie bereits Ultra-HD-Fernseher. Ein weiterer Unterschied zur 5000er Serie ist, dass die Fernseher der 6000er Serie alle 3D unterstützen. Manche Fernseher benutzen Active3D und manche benutzen Passive3D. Manche Fernseher haben 2 EasyLink stellt Lösungen für elektronischen Datenaustausch und digitaler Unternehmenskommunikation, wie zum Beispiel Faxen, bereit. vgl. 3 Bei Ambilight handelt es sich um eine Technologie, welche das Gerätesichtfeld in der Wahrnehmung des Zuschauers vergrößern und damit die Augen schonen soll. 4 Smart Sound ermöglicht es, eigene, professionelle Soundtracks zu erstellen. vgl. zusätzlich flimmerfreies 3D und unterstützen Zwei-Spieler- Fullscreen fürs Gaming. Bei der Bildoptimierung wurde auf Digital Crystal Clear und Pixel-Plus-HD verzichtet. Zusätzlich gibt es aber Pixel-Plus-Ultra-HD und Micro Dimming Pro[3]. Bei der 7000er Serie wurde bei manchen Fernsehern 3-seitiges Ambilight verwendet. Bei manchen Fernsehern wurden statt SmartTV-Apps ein Android-Betriebssystem aufgespielt. Bei der Bildoptimierung verwenden zusätzlich einige Fernseher entweder Super Resolution oder Ultra Resolution. Eine weitere Erweiterung ist, dass die Fernbedienung bei einigen Fernsehern mit Tastatur, mit Mauszeiger oder mit Hilfe der Stimme möglich ist[4]. Die 8000er Serie benutzt unter anderem 3-seitiges und 4- seitiges Ambilight. Auf jedem Fernseher der 8000er Serie ist ein Android-Betriebssystem vorhanden. Es wurde eine Smart-Kamera eingebaut, die eine Gestensteuerung erlaubt und für Skype benutzt werden kann. Manche Fernseher haben zusätzlich die Distance-Adaptive-Sharpness-Funktion[5]. Die 9000er Serie benutzt 3-seitiges Ambilight XL und 4- seitiges Ambilight. Im Gegensatz zur 8000er Serie ist nicht auf jedem Fernseher der 9000er Serie ein Android-Betriebssystem. Für die 3D Funktionalität wird bei der 9000er Serie kein Passive 3D mehr benutzt, sondern nur noch Active 3D oder Easy 3D. Die Bildoptimierung hat wieder ein paar Funktionalitäten hinzubekommen. Unter anderem ein lokaler Kontrast, Bright Pro und Mircro Dimming Pro[6]. Philips hat diese Softwareproduktlinie anfangs mit Hilfe eines Software-Komponentenmodells mit Namen Koala realisiert. Man musste dazu wiederverwendbare Komponenten auswählen und erhielt so neue Kombinationen. Koala ist sowohl ein Komponentenmodell, als auch eine architektonische Sprache, mit der man Interfaces definieren kann, so wie die Verbindungen zwischen den einzelnen Komponenten. Mit der architektonischen Sprache wurde die Komplexität gehandhabt und wurde dazu benutzt, automatisch produktspezifischen Code zu generieren. Eine Koala Komponente enthielt eine Vielzahl von Bereitstellungsinterfaces und Anforderungsinterfaces. Bereitstellungsinterfaces definieren die Funktionalitäten einer Komponente, die von anderen Komponenten benutzt werden können. Anforderungsinterfaces definieren die Funktionalitäten, die eine Komponente von anderen Komponenten benötigt, um die eigenen Funktionalitäten zur Verfügung stellen zu können. Außerdem gibt es noch einen speziellen Typ von Anforderungsinterfaces, und zwar solche Interfaces, welche einige Parameter oder Funktionen beinhalten und zusammen mit einigen Konstrukten und Modulen Variationspunkte in den Komponenten definieren. Später hat man dann eine Produktlinien-Architektur entwickelt. Diese Architektur legt eine Reihe von Regeln und Grundsätze fest, die von individuellen Produkten eingehalten werden sollen, was jedem Produkt ermöglicht, seine eigene spezifische und optimierte Architektur zu besitzen. Die Architektur beinhaltet einen Anfangsbestand an Komponenten, welche einige gegebene Features implementieren. Die so entstandene Produktlinie hat eine bestimmte Anfangskomplexität und Codegröße. Ein neues Feature wird hinzugefügt, indem bereits existierende wiederverwendbare Komponenten modifiziert werden und neue Komponenten hinzuge-

38 fügt werden. Es gibt sogenannte kommerzielle Features, wie zum Beispiel Ambilight und es gibt technische Features. Technische Features sind für die technische Umsetzung da. Kommerzielle Features können sich mit einer Vielzahl von technischen Features überschneiden und ein technisches Feature kann von einer Vielzahl an Komponenten implementiert werden[1][20]. 2.2 Bosch Motorsteuerungssoftware Die Bosch Gruppe ist ein führender globaler Anbieter von Technologien und Dienstleistungen im Bereich der Automobiltechnologie und Industrietechnologie. Die Motorsteuerungen sind eingebettete, sehr komplexe Echtzeitsysteme, die die Verbrennungsmotoren in unzähligen Autos kontrollieren. Diese Softwaresysteme müssen einige Anforderungen erfüllen. Unter anderem: Extreme Variabilität, permanent wachsende Komplexität, verteilte Entwicklung in Kooperation mit Autoherstellern und Einhaltung von Standards. Die Herausforderung, steigende Komplexität bei niedrigen Kosten und dabei einen hohen Qualitätsstandard zu gewährleisten, führte dazu, dass man mit Software Produktlinien arbeitet. Wichtige Meilensteine sind die Definition des Umfangs der Produktlinien, der Softwarearchitekturentwurf und des Kernbestandteils[7]. Für die elektronische Motorsteuerung wurde ein Gerät mit dem Namen Motronic entworfen. Das elektronische Motormanagement ermöglicht eine präzise zentrale Steuerung aller Funktionen, die für den Motorbetrieb notwendig sind. Das funktioniert so, dass das Motorsteuergerät alle Anforderungen an den Motor sammelt, die Anforderungen priorisiert und dann umsetzt. Beispiel für Anforderungen sind Fahrpedalstellung und Anforderungen des Abgassystems an die Gemischzusammensetzung. Das Luft-Kraftstoff-Verhältnis ist für die Regelung sehr wichtig und wird so geregelt, dass das angeforderte Drehmoment möglichst sparsam und sauber bereitgestellt wird. Die Motorsteuerung ermöglicht auch den Eingriff aktiver Sicherheitssysteme wie ASR und ESP. Die Motronic kann Verbrennungsmotoren mit Benzin, Diesel, Erdgas, Ethanol und Hybridantriebe steuern. Durch standardisierte Kommunikationsschnittstellen und Datenformate wird die Vernetzung aller Fahrzeugsysteme erreicht, die den Antrieb beeinflussen. Bosch bietet Systeme für Benzin-Direkteinspritzung, Benzin-Saugrohreinspritzung, Diesel, Flex Fuel- und Flexstart, Hybrid-Fahrzeuge und Plug-in Hybrid- Fahrzeuge an. Flex Fuel- und Flexstart-Systeme benutzen Ethanol. Der Unterschied liegt darin, dass bei dem Flex Fuel-System ein kleiner Benzinzusatztank an Bord ist, um das Ethanol, falls erforderlich, besser zünden zu können. Flexstart-Systeme hingegen erwärmen den Kraftstoff über elektrisch gesteuerte Heizelemente. Im Gegensatz zu Hybrid-Fahrzeugen, ist es bei Plug-in Hybrid-Fahrzeugen so, dass die Batterie vor Fahrtbeginn mit einem Ladekabel aufgeladen werden kann[8][9]. Die Motorsteuerung, also die Motronic, in jedem dieser Systeme, muss eine Reihe von Funktionen steuern. Dazu zählen die Kraftstoffversorgung, die Luftsteuerung, die Kraftstoffeinspritzung, die Zündung und die Abgasnachbehandlung. Um diese Funktionen alle korrekt steuern zu können, werden eine Vielzahl von Sensoren eingesetzt. Hinzu kommen noch wahlweise Funktionen, wie zum Beispiel Turbosteuerung, Motortemperatursteuerung, Kraftstofferwärmung und Funktionen für Hybrid-Fahrzeuge. Bei der Benzin-Direkteinspritzung und bei der Benzin-Saugrohreinspritzung sorgt die Motronic für die zentrale Steuerung der verschiedenen Funktionen. In Abhängigkeit von Parametern wie Drehzahl, Lastzustand, Betriebs- und Lufttemperatur steuert die Motronic den gesamten Prozess der Leistungserzeugung, von der Gemischaufbereitung über die Verbrennung bis zur Abgasnachbehandlung. Der Unterschied zwischen Benzin-Direkteinspritzung und Benzin-Saugrohreinspritzung liegt im Ort der Kraftstoff-Luft-Gemisch Bildung. 5 Bei der Benzin-Direkteinspritzung geschieht dies direkt im Brennraum. Über das Einlassventil strömt reine Frischluft ein. In diesem Luftstrom wird dann mit hohem Druck der Kraftstoff eingespritzt. 6 Bei der Benzin-Saugrohreinspritzung entsteht das Luft-Kraftstoff-Gemisch außerhalb des Brennraums im Saugrohr. Das Einspritzventil spritzt den Kraftstoff vor das Einlassventil. Im Ansaugtakt strömt das Gemisch durch das geöffnete Einlassventil in den Verbrennungsraum. Die Motorsteuerung Motronic für Flex Fuel und Flexstart basiert auf der Motronic für Benzin-Saugrohreinspritzung. Das System besteht aus speziell an die Eigenschaften von Ethanol angepassten Systemkomponenten. Die Motorsteuerung passt Einspritzung, Ventilsteuerzeiten und Zündung automatisch an unterschiedliche Ethanolanteile im Benzin an. Zusätzlich kann das Steuergerät das Flexstart-System steuern. Je nach Ethanolgehalt und Außentemperatur steuert die Motronic die Heizelemente über das Heizsteuergerät. Motoren mit Bifueal CNG-Antrieb verbrennen Erdgas oder Benzin. Die beiden getrennten Kraftstoffsysteme werden über ein gemeinsames Motormanagement gesteuert. Durch dieses innovative System erfolgt das Umschalten zwischen CNG(Compressed Natural Gas)- und Benzin-Betrieb unmerklich. Das Bifuel-Steuergerät Motronic für Erdgas vereint das Motormanagement für Benzin- und Erdgasbetrieb, welches auf der Motronic für Benzineinspritzung basiert und steuert die Gemischbildung, Zündung und Abgasnachbehandlung. Die drehmomentgeführte Steuerung erlaubt die einfache Integration der für den CNG-Betrieb spezifischen Funktionen. Der Hybrid-Antrieb kombiniert den Verbrennungsmotor mit einer elektrischen Maschine. Für Diesel Fahrzeuge stellt Bosch eine elektronische Motorsteuerung bereit. Diese regelt die Funktionen des Einspritzsystems, so dass der Motor den angeforderten Motordrehmoment bereitstellt[10][13]. Die Software Produktlinie wird mit Architektur umgesetzt. Diese Architektur wird unterteilt in drei Haupt-Cluster. Zum Einen die gemeinsame Basissoftware, gemeinsame Anwendungssoftwarekomponenten, welche einen Zusammenhang der Fahrzeuge für das Motorsteuerungssystem bereitstellt. Und der dritte Teil besteht aus zwei separaten Sätzen von spezifischen Motorsteuerungskomponenten, die jeweils den Dieselbeziehungsweise Benzinmotor steuern. Figure 1 zeigt die Architektur, welche dem Motorsteuerungssystem zugrunde liegt. Dieser Grundaufbau wird erweitert durch ein Schich- 5 powertrain systems for passenger cars 1/direct gasoline injection/direct gasoline injection 23.html 6 powertrain systems for passenger cars 1/gasoline port fuel injection 22/gasoline port fuel injection 23.html

39 tenmodell, um Hardware und Gerätetreiberkapselung zu unterstützen[7][18]. Um die Variabilität zu handhaben, wird ein Feature-Modell erzeugt, um festzustellen, wo Variationspunkte vorhanden sind. Figure 1: Top level architecture[18] Während der Entwicklung des Kernbestands wird Variabilität eingeführt und verfeinert und spiegelt sich in den Artefakten wider. Innerhalb dieser Softwareproduktlinie muss die Architektur auch Designvariabilität erfassen. Architektonische Variabilität repräsentiert alternative Designoptionen, die nicht während der Architekturmodellierung gebunden werden konnten. Diese Variabilität wird durch einen Satz an architektonischen Variationspunkten verdeutlicht, welche einen Teil der architektonischen Lösung der variablen Features darstellen. Die fertige Architektur beinhaltet alle funktionalen und nicht-funktionalen Anforderungen. Auf architektonischer Ebene werden Variationspunkte eingeführt, um die Variabilität unter den Anforderungen zu erfüllen. Jeder Variationspunkt wird dadurch charakterisiert, wie und wann ein Variationspunkt angewendet wird. Variationspunkte können voneinander abhängen. Dadurch werden einheitliche Komponentenkonfigurationen definiert. Durch bestimmtes Komponentendesign oder durch bestimmte Code-Konstrukte ist es möglich, Variabilität aus der architektonischen Sicht auszukapseln. Wie zum Beispiel Codeverschlüsselung, um unauthorisierte Änderungen zu verhindern oder Laufzeitdatenkompression, um Speicher effizienter nutzen zu können. Schrittweiße Verfeinerungen beinhalten die Variabilität, die in dem Feature-Modell identifiziert wurde und werden schließlich in architektonischen Variationspunkten implementiert. Features werden explizit zu dem zugehörigen architektonischen Variationspunkt gemapped. Dieses Mapping zeigt im Prinzip, wie der architektonische Variabilitätsmechanismus zur Realisierung der Feature-Modell-Variabilität beiträgt[19]. Das Motorsteuerungsgerät Metronic ist weitgehend frei programmierbar. Im Prinzip hat also jeder Nutzer eines Fahrzeugs, in dem ein solches Motorsteuerungsgerät verbaut ist, die Möglichkeit, die Software individuell anzupassen. 2.3 Heimautomation Heutzutage werden die meisten technischen Alltagsgeräte durch Mikroprozessoren gesteuert. Heimautomation integriert solche Geräte in ein Netzwerk. Dieses Netzwerk ermöglicht den Geräten, sich zu koordinieren, um komplexe Aufgaben zu erledigen, ohne dass ein Mensch sich darum kümmern muss. Intuitive Userinterfaces ermöglichen die einfache Handhabung dieser Funktionalitäten des Smart Homes. Ein Hauptvorteil von Vernetzung und Softwaresteuerung ist die Möglichkeit, ein einziges Verwaltungssystem für das ganze System bereit zu stellen. Um mit einzelnen Geräten zu interagieren, ist es nicht nötig, jedes einzeln zu benutzen, sondern kann das über ein gemeinsames Userinterface tun. Das ist von Vorteil, weil die Hausbewohner dann nicht von Raum zu Raum gehen müssen, um zum Beispiel zu prüfen, ob die Fenster offen beziehungsweise geschlossen sind. Diese Information kann man sich dann über das Userinterface holen. Ein Heimautomationssystem stellt eine Vielzahl von Funktionalitäten zur Verfügung: Das Lichtsteuerungssystem verwendet Schalter, Licht und Sensoren. In einem Smart Home wird das Licht anhand von einigen Faktoren angepasst. Die Gesamthelligkeit in einem Raum und die Anwesenheit von Personen sind zwei Basisfaktoren, die bei der Lichtsteuerung eine Rolle spielen sollten. Ein weiterer Faktor ist das aktuelle Geschehen der Bewohner im Raum und individuelle Gewohnheiten. Zum Beispiel würde man beim Fernsehen das Licht anders einstellen, als wenn man ein Buch liest. Das Tür- und Fenstersteuerungssystem überwacht den Status der Türen und Fenster, zum Beispiel, ob diese geöffnet, geschlossen, abgeschlossen oder aufgeschlossen sind. Es ist auch möglich, dass das Steuerungssystem die Bewohner in bestimmten Situationen erinnert, die Fenster zu schließen. Außentüren können mit Hilfe eines bestimmten Erkennungsmechanismus elektronisch aufgeschlossen werden, zum Beispiel mit einem Fingerprint-Mechanismus. Das Fenstersteuerungssystem umfasst außerdem elektrische Rollladen, die bei Bedarf geschlossen werden können. Werden die Rollladen geschlossen oder geöffnet, hat das Auswirkungen auf das Licht. Deshalb müssen das Tür- und Fenstersteuerungssystem und das Lichtsteuerungssystem miteinander kommunizieren und sich koordinieren. Zum Beispiel ist es möglich, dass automatisch eine Lampe angeht, wenn der Rollladen geschlossen wird. Die Hauptaufgabe des Haushaltsteuerungssystems ist, Steckdosen zu überwachen. Das ermöglicht den Bewohnern, den Stromverbrauch zu überwachen und bestimmte Steckdosen abzuschalten. Außerdem ist es möglich, anspruchsvollere Geräte zu integrieren. Zum Beispiel ist es möglich, eine Waschmaschine an das Userinterface anzubinden. Das Hitze-, Feuer- und Raucherkennungssystem benutzt Sensoren und Thermometer, um Feuer und Rauchentwicklung erkennen zu können. Das System kann dann zum Beispiel automatisch die Feuerwehr benachrichtigen, wenn Feuer entstanden ist und ein akustisches Signal abgeben, um die Bewohner vor Rauch und Feuer zu warnen. Das Audio- und Videosteuerungssystem sorgt für das Abspielen von Audio- und Videostreams auf zum Beispiel einem Fernseher. Hier wird auch die Kommunikation mit dem Lichtsteuerungssystem notwendig. Denn zum Beispiel kann es sein, dass man einen Film im Dunkeln schauen möchte.

40 Oder falls man laut Musik hören möchte, ist es sinnvoll, die Fenster des Raums, in dem die Musik gespielt wird, zu schließen[11]. In einem Smart Home benötigt man Variabilität beziehungsweise Variationspunkte, um die Wohnung individuell anzupassen. Im folgenden Abschnitt werden einige Variationspunkte vorgestellt: Für das Userinterface gibt es mehrere Möglichkeiten. Manche können auch gleichzeitig existieren. Userinterfaces kann man grob unterteilen in lokale Userinterfaces und remote Userinterfaces. Zu den lokalen Userinterfaces gehört zum Beispiel ein graphisches TV Interface oder ein Touchscreen. Zu den remote Interfaces zählt zum Beispiel der Zugriff über das Internet oder der Zugriff mit einem Tablet. Die Verfügbarkeit von verschiedenen Sensoren ist noch ein wichtiger Punkt. Wenn zum Beispiel ein Helligkeitssensor und eine Uhr vorhanden ist, dann kann die Rollladensteuerung anhand der aktuellen Zeit und der Helligkeit gesteuert werden. Wenn ein Wettersensor vorhanden ist, können die Rollladen auch geöffnet werden, wenn der Wind sehr stark weht, um eventuelle Schäden zu verhindern. Die Variabilität liegt hier in den verschiedenen Steuerungsalgorithmen. Das System kann eventuell verschiedene Stufen von Fehlersicherheit unterstützen. Zum Beispiel kann es auf der untersten Stufe Selbsttests geben und Fehlerprotokolle. Höhere Stufen können redundante Komponenten für die wichtigsten Funktionen beinhalten. Die Software in einem redundanten System muss dann Defekte erkennen können und defekte Komponenten deaktivieren und Tasks an andere Komponenten zuweisen. Userinterfaces haben. Dann benötigt man gegebenenfalls ein barrierefreies Userinterface. Oder falls es in dem Haus Treppen gibt, benötigt man eventuell Software für eine automatische Treppenhilfe. Ein weiterer Punkt ist die Feueralarmabstellung. Denkbar ist, dass es entweder automatisch nach einer gewissen Zeitspanne abgestellt wird oder dass eine Person diesen manuell abstellt. Entweder ein Bewohner oder die Feuerwehr. Auch hier kann man festlegen, welche Personen das dürfen. Gegebenenfalls ist hier eine Authentizierung notwendig. Diese Softwareproduktlinie wird mit einer speziellen Architektur umgesetzt. Die Architektur wird in unterschiedliche Schichten für verschiedene Komponenten des Heimautomationssystems eingeteilt. Für jede dieser Schichten werden spezielle Frameworks erstellt, um feste Konfigurationen für die Variationspunkte bereitzustellen. Die Komponenten können durch Interfaces miteinander verbunden werden. Jede Komponente wird dann über Plug-Ins spezialisiert, um die verschiedenen Varianten zu erhalten. Das Framework legt fest, welche Interfaces benutzt werden. Das selbe Interface ist für eine Vielzahl von Komponenten gültig. Variabilität macht es auf der einen Seite notwendig, von den Unterschieden der bereitzustellenden Komponenten zu abstrahieren, aber auf der anderen Seite auch, Funktionen bereitzustellen, welche dafür sorgen, dass bestimmte Informationen bezüglich der Variabilität des Interfaces, welches zum Beispiel die benötigten Varianten zur Laufzeit ermittelt, aufgedeckt werden. Ein Interface spezifiziert Funktionalitäten, welche von verschiedenen Komponenten bereitgestellt werden und von anderen benötigt werden. Interfaces können dazu verwendet werden, um auf die Variabilität der einzelnen Komponenten zuzugreifen. So können zur Laufzeit die Varianten angepasst werden. Die bereitgestellten Interfaces bestimmen die Funktionalität der einzelnen Komponenten. Die Funktionen, Typen und Klassen werden alle so bereitgestellt, wie es in den Interfaces definiert wurde. Die Architektur ermittelt den Großteil der Variabilität. Variabilität entsteht hauptsächlich durch unterschiedliche Konfigurationen. Der Komponentenentwickler bestimmt eine Auswahl an Konfigurationsparametern, um die richtige Komponentenvariante auszuwählen. Die mögliche Unabhängigkeit der Konfiguration von einer Komponente beziehungsweiße von einem Interface ist abhängig davon, welche Rolle die Konfiguration in der Architektur spielt. Deshalb sollte die Konfiguration so entworfen werden, dass sie genau die Funktionalitäten spezifiziert, die das Interface bereitstellt. bool: Door lock electronic bool: Door authentication bool: Auto close string: Authentication algorithm Figure 2: Architekturausschnitt am Beispiel der Türverriegelung[12] Heimautomationssysteme müssen zusätzliche Anforderungen erfüllen, wenn sie von älteren Menschen oder von Menschen mit Behinderung benutzt werden. Es kann zum Beispiel sein, dass diese Menschen Probleme mit der Bedienung des int: Auto close delay In diese Tabelle wird eine Beispielauswahl an Punkten der Konfiguration vorgestellt. Man hat boolesche Werte, die festlegen, wie der Türschließmechanismus funktioniert. Dann hat man einen string, der den Authentizitätsalgorithmus festlegt und einen int-wert, der die Verzögerung bei der automatischen Türschließung festlegt.

41 In Figure 2 sieht man einen Ausschnitt aus der Architektur am Beispiel der Türverriegelung. Man hat die Türverriegelung, die Benutzersteuerung und einen Manager für die Authentizierung. Verschiedene Plug-Ins spezialisieren die Software. In diesem Beispiel hat das System Schließaktoren und Sensoren, die erkennen, ob die Tür offen oder geschlossen ist. Außerdem hat man ein elektronisches Schloss, welches man aber manuell schließen muss[12]. 2.4 Linux-Kernel Der Linux-Kernel ist der Kern jedes Linux-Betriebssystems. Der Finne Linus Torvald hat die Entwicklung des Linux- Kernels 1991 begonnen und wird heute unter seiner Leitung von einer weltweiten Entwicklergemeinde weitergeführt. Der Linux-Kernel ist ein modularer, monolithischer Betriebssystemkern. 7 Ein monolithitscher Kernel hat im Vergleich zu einem nicht-monolithischen Kernel einen größeren Funktionsumfang. In einem monolithischen Kernel sind Treiber bereits vorhanden. Dadurch lässt sich die Geschwindigkeit verbessern. Durch die Treiberintegration wird das System allerdings fehleranfälliger und weniger stabil. Stürzt ein Treiber bei einem monolithischen Kernel ab, dann ist davon das ganze System betroffen. Der Linux-Kernel selbst ist aber kein rein monolithischer Kernel, sondern, wie bereits erwähnt, vereint er monolithische und modulare Aspekte[14]. Der Linux-Kernel stellt eine Schnittstelle auf die Hardware für die darauf aufsetzende Software bereit. Eine weitere Aufgabe ist die Speicherverwaltung. Der Kernel legt fest, welche Bereiche des physischen Speichers benutzt werden und welche nicht. Außerdem verwaltet er den virtuellen Adressraum der einzelnen Prozesse beziehungsweise der Anwendungen. Die Verwaltung der laufenden Prozesse ist ein weiterer Punkt, um den sich der Linux-Kernel kümmert. Der Kernel muss den Überblick über die einzelnen Prozesse behalten und muss entscheiden, welcher Prozess wichtiger ist und gegebenenfalls Verklemmungen erkennen und verhindern. Nach diesen Erkenntnissen entscheidet der Kernel, welcher Prozess wie lang welcher CPU zugeteilt wird. Der Kernel muss eine Möglichkeit für eventuell aufkommende Kommunikation zwischen den einzelnen Prozessen bereitstellen. Ein weiterer Punkt ist die Multitasking-Fähigkeit. Es müssen Funktionen bereit gestellt werden, um mehrere Tasks nebenläufig ausführen zu können, falls nur ein CPU-Kern vorhanden ist oder um Tasks echt parallel abarbeiten zu können, falls mehrere CPU-Kerne vorhanden sind. Die Lastverteilung ist eine weitere Aufgabe, die der Linux- Kernel übernimmt. Hierzu zählt zum Beispiel die Lastverteilung auf Rechnern mit mehreren Prozessoren, wo jeder Prozess auf einem eigenen Prozessor ausgeführt werden kann. Der Linux-Kernel bietet neben den bereits erwähnten Funktionalitäten außerdem noch die Sicherheitserzwingung, in dem bestimmte Sicherheitsmaßnahmen festen Bestand haben, wie zum Beispiel eine Benutzerverwaltung oder Rechteverwaltung. Eine weitere Aufgabe des Linux-Kernels sind Eingabe/Ausgabe-Operationen, also die Bereitstellung von Schnittstellen zur Kommunikation und Interaktion mit der Außenwelt. Zum Beispiel die Interaktion mit dem Benutzer, aber auch 7 vgl. knowledge:monolith kernel Aktionen zum Lesen und Schreiben von Daten[15][14]. Im Gegensatz zu einem rein monolithischen Kernel ist der Linux-Kernel in der Lage, fast alle seine Features in dynamisch - also zur Laufzeit - hinzu ladbare Module auszulagern. Das macht den Linux-Kernel sehr flexibel. Die meisten Linux-Features sind optional. Im Folgenden werden einige Variationspunkte unterteilt und vorgestellt. Man kann die Features anhand der Beschreibungen kategorisieren. Zur ersten Kategorie zählen Gruppierungsfeatures, also zum Beispiel ein Feature, welches Lese-/Schreibscheduler für blockbasierte Geräte, zum Beispiel eine Festplatte, gruppiert. Eine weitere Kategorie sind unterstützende Features, die eine Unterstützung für verschiedene Geräte bereitstellen, wie zum Beispiel die Unterstützung für Geräte wie die Infrarot- Remotesteuerung von Samsung. Die nächste Kategorie enthält solche Features, die eine spezielle Kernel- oder Treiberfähigkeit ein- oder ausschalten können, wie zum Beispiel DASD 8, welches DASD blockbasierte Geräte einschaltet. Die letzte Kategorie enthält Features, die Debugfunktionen für Entwickler bereit stellen, wie zum Beispiel MEMSTICK DEBUG, was Debuging für Memorystick Geräte aktiviert. Zusätzlich kann man die Features in Typen unterteilen. Zum einen gibt es Features, die eine API zum Programmieren bereit stellen, wie zum Beispiel CRYPTO CTR, welches eine API für den Blockverschlüsselungsalgorithmus bereit stellt. Ein weiterer Typ fasst Features zusammen, die für Treiber benötigt werden, wie zum Beispiel SND ADLIB, das Unterstützung für AdLib Karten bietet. Das Feature FAILSLAB ermöglicht Fault Injection für kmalloc und zählt damit zu den Typen, die das Kernel Verhalten beeinflussen, beziehungsweise ändern. Zum nächsten Typ zählen Features, welche Protokolle implementieren. LLC2 zum Beispiel ermöglichen die Unterstützung von PF LLC Sockeln. Zu dem letzten hier vorgestellten Typ zählen die Features, die ein ganzes Teilsystem ermöglichen, wie zum Beispiel BT, mit dem Bluetooth ermöglicht wird, welches aus mehreren Softwareschichten besteht. Die meisten Features sind Treiber für verschiedene Geräte und Protokolle[17]. Man hat also die Möglichkeit bei der Kompilierung festzulegen, welche Features man als festen Bestandteil in den Kernel aufnehmen möchte und welche Teile nicht. Die Teile, die nicht als fester Bestandteil integriert werden, können als Module kompiliert werden, die dann zur Laufzeit problemlos eingebunden werden können und auch wieder entfernt werden, wenn sie nicht mehr gebraucht werden. Der Vorteil daran ist, dass nicht unnötiger Speicherplatz gebraucht wird. Es ist so also möglich, den Kernel sehr klein zu halten und Module dann bei Bedarf nachzuladen. Es gibt eine Vielzahl von Modulen, die man benutzen kann. Es ist auch möglich, sich eigene Module zu programmieren. Auf die Module soll hier nur am Rande eingegangen werden, da sich die Funktionalitäten der Module weitgehend mit den vorgestellten Features decken: Es gibt Module für spezielle Hardware, also Gerätetreiber, wie zum Beispiel Grafikkartentreiber oder Soundtreiber. Weitere Module sind zum Beispiel Module für spezielle Filesystems oder für Netzwerk- 8 Direct Access Storage Device

42 protokolle. Ein weiteres Beispiel sind Module für Kryptographie, um Daten zu verschlüsseln, oder sichere Protokolle bereitstellen zu können. Unter den einzelnen Modulen kann es auch zu Abhängigkeiten kommen. Das heißt also, dass manche Module auf andere Module angewiesen sind. Diese müssen dann zusammen geladen werden, damit die Module korrekt funktionieren[16]. Figure 3: Die Xconfig GUI[17] Diese Software Produktlinie benutzt den Annotationsansatz, der mit Hilfe von Präprozessoranweisungen umgesetzt wird. Wie bereits erwähnt ist es möglich, vor dem Kompilieren auszuwählen, welche Features fester Bestandteil sein sollen und welche als Module kompiliert werden sollen. Um den Kompilierungsprozess zu konfigurieren, verwendet man Kconfig. Damit ist es möglich, die verfügbaren Konfigurationsoptionen und Abhängigkeiten zu spezifizieren. Konfigurationsoptionen sind in Linux bekannt als configs. Configs sind benannte Namen mit einem speziellen Typ: Boolean, tristate, integer oder string. Boolean Configs repräsentieren Optionen, welche entweder eingeschaltet (y) sind, oder ausgeschaltet (n). Tristate Configs sind ähnlich, haben aber zwei mal den Status ein. y signalisiert hier, dass der Code, der diese Option implementiert statisch in den Kernel gelinkt werden sollte. m bedeutet, dass der Code als Modul kompiliert werden sollte. Folglich ist eine tristate Config eine einfache Form der Bindungsartspezifikation. Integer Configs werden dazu benutzt, numerische Optionen, wie zum Beispiel Puffergrößen festzulegen. String Configs werden benutzt, um Namen zu spezifizieren, wie zum Beispiel für Dateien oder Diskpartitionen. Config-Definitionen können andere Elemente neben Typen beinhalten. Der Xconfig Configurator benutzt diese mit Kconfig spezifizierten Configs und der User hat dann die Möglichkeit auszuwählen, welche Features er haben möchte, welche er nicht haben möchte und welche als Module kompiliert werden sollen. In Figure 3 sieht man ein Beispiel für eine mit Xconfig getätigte Konfiguration. Im Beispiel zu sehen ist die Konfiguration des Power Managements und der ACPI Optionen. Wenn hinter dem Typ ein Prompt steht, dann kann die Config vom Benutzer angepasst werden, ansonsten nicht. Eine Sichtbarkeitsbedingung kann direkt hinter dem Prompt stehen. Eine depends-on-klausel zeigt eine Abhängigkeit von anderen Configs an. Die Config, von der die Abhḧangigkeit besteht, muss auch ausgewählt werden. Eine default-klausel hat einen zweifachen Effekt. Zum Einen, wenn die Config vom Benutzer angepasst werden kann, wird default dazu genutzt, einen initialen Wert festzulegen. Wenn die Config nicht vom Benutzer angepasst werden kann, dann erzwingt default einen Wert für dieses Feature[17]. 3. FAZIT In diesem Text wurden unterschiedliche Softwareproduktlinien vorgestellt und daraufhin untersucht, wie die Softwareproduktlinie definiert wurde, also welche Optionen beziehungsweise Variationspunkte definiert wurden und mit welchen Techniken diese Softwareproduktlinie umgesetzt wurde. Die vorgestellten Softwareproduktlinien von Philips, Bosch und das Heimautomationssystem zeigen ganz gut, dass Softwareproduktlinien auch im Alltag sehr nützlich sind und unverzichtbar für die schnellere Produktion solcher Produkte. Die Softwareproduktlinie von Philips ermöglicht es, Software für unterschiedliche Fernseher bereit zu stellen, ohne für jeden einzelnen Fernseher extra Software schreiben zu müssen. Die Motorsteuerungssoftware von Bosch ist ein schönes Beispiel dafür, wie Softwareproduktlinien auch die Automobilindustrie erreicht haben. Die Motronic ist in der Lage unterschiedlichste Motortypen zu steuern. Das Heimautomationsbeispiel zeigt ganz gut, wie hilfreich Softwareproduktlinien auch im privaten Bereich sein können. Ohne Probleme lässt sich für fast jede Anforderung ein eigenes Produkt entwickeln, ohne dass man umständlich neue Software schreiben müsste. Aber auch der Linux-Kernel ist eine hervorragende Softwareproduktlinie, die es schafft, die Kernbestandteile vom Speicherplatzverbrauch sehr klein zu halten und doch auch Platz bietet für optionale Komponenten, die sich in Modulen auslagern lassen und bei Bedarf geladen werden können. Im Großen und Ganzen sind Softwareproduktlinien ein sehr interessantes und wichtiges Thema und Softwareproduktlinienentwicklung hilft auf lange Zeit betrachtet, Zeit und Resourcen für die Entwicklung von Produkten zu sparen. 4. REFERENCES [1] Internet Abgerufen: November 2014 [2] Internet SERIES FLAT TV SE&sliders=&price=&priceBoxes=&page=&layout= 12.subcategory.p-grid Abgerufen: November 2014 [3] Internet SERIES SU&sliders= &price=&priceboxes=&page=&layout=12. subcategory.p-grid Abgerufen: November 2014 [4] Internet

43 serie/neueste#filters=7000 SERIES FLAT TV SE&sliders=&support=&price=&priceBoxes=&page= &layout=12.subcategory.p-grid Abgerufen: November 2014 [5] Internet SERIES FLAT TV SE&sliders=&support=&price=&priceBoxes=&page= &layout=12.subcategory.p-grid Abgerufen: November 2014 [6] Internet SERIES FLAT TV SE&sliders=&support=&price=&priceBoxes=&page= &layout=12.subcategory.p-grid Abgerufen: November 2014 [7] Internet Abgerufen: November 2014 [8] Internet europe/db application/downloads/pdf/antrieb/de 5/gs datenbl motronic de.pdf Abgerufen: November 2014 [9] Internet powertrain systems for passenger cars 1/powertrain systems for passenger cars 1.html Abgerufen: November 2014 [10] Internet powertrain systems for passenger cars 1/gasoline port fuel injection 22/gasoline port fuel injection 23.html Abgerufen: November 2014 [11] Internet Abgerufen: November 2014 [12] Prof. Dr. Klaus Pohl et al. Software Product Line Engineering - Foundations, Principles, and Techniques. 2005, pp 46-52, , [13] Internet ubk europe/db application/downloads/pdf/antrieb/de 5/ elektronisches steuergeraet motronic.pdf Abgerufen: November 2014 [14] Internet Kernel Abgerufen: November 2014 [15] Internet Was ist der Kernel%3F Abgerufen: November 2014 [16] Internet Abgerufen: November 2014 [17] Dr. Steven She et al. The Variability Model of The Linux Kernel. 2010, pp 1-4 [18] Christian Tischer et al. Why does it take that long? Establishing Product Lines in the Automotive Domain. 2007, pp 2 [19] Steffen Thiel and Andreas Hein. Modeling and Using Product Line Variability in Automotive Systems. 2002, pp 1-6 [20] Aleksandra Tesanovic. Evolving Embedded Product Lines: Opportunities for Aspects. 2007, pp 2-5

44 Softwareproduktlinien - Unterschiede zur klassischen Softwareentwicklung Tim Serowski tim.serowski@student.uni-siegen.de ABSTRACT Das vorliegende Paper beschreibt die Unterschiede beim Einsatz von Softwareproduklinien gegenüber einer klassischen Softwareentwicklung beim Herstellen von Individualsoftware. Im Folgenden wird beleuchtet, wie es gelingen kann, Software zu entwickeln, die es einem Unternehmen möglich macht, mit Hilfe der Technik der Softwareproduktlinien beim Entwickeln von Softwaresystemen Entwicklungskosten und Entwicklungszeit zu senken und dabei gleichzeitig eine erhöhte Softwarequalität zu erreichen. Desweiteren wird anhand der Softwareproduklinien gezeigt, wie wiederverwendbare Softwarekomponenten erstellt werden, die in späteren, oder sogar zeitgleich entwickelten, Projekten wiederverwendet werden können. Diese gewonnene Flexibilität lässt sich, wie untersucht wird, auch rückwärtsorientiert nutzen und so auch bei bereits abgeschlossenen Systemen einsetzen. Hiermit lässt sich eine sehr hohe Kundenzufriedenheit herstellen, während kaum ansteigende Kosten entstehen. Diese Arbeit belegt, dass es möglich ist, diese Ziele zu erreichen und zeigt die Schwierigkeiten auf, die dabei entstehen und wie mit diesen umgegangen wird. 1. EINLEITUNG Softwareentwicklung unterscheidet sich bislang noch wesentlich von einer Industrieproduktion wie beispielsweise der Automobilproduktion oder der Herstellung von anderen komponentenbasierten Gegenständen, wie zum Beispiel Computer, Laptops und Smartphones. Bei der Softwareentwicklung wird häufig stark projektbezogen gearbeitet, ohne dass die dabei entstehenden Komponenten Einfluss in andere Softwarelösungen derselben Firma nehmen. Die auf diesem Wege entstehende Software wird gemeinhin als Individualsoftware bezeichnet. Individualsoftware birgt den Nachteil, dass einzelne Bestandteile des geschaffenen Systems nicht, oder nur mit sehr hohem Aufwand in spätere Projekte übernommen werden können und diese, falls eine Weiterentwicklung von Komponenten doch notwendig ist, nach dessen Abschluss nicht im Ursprungsprojekt ebenfalls aktualisiert werden können, ohne dass erneute, erhebliche Aufwände entstehen. Softwareproduktlinien versuchen, dieses Problem der klassischen Softwareentwicklung zu lösen indem ein Ansatz gewählt wird, bei dem zunächst eine gemeinsame Plattform geschaffen wird. Diese Plattform birgt das Rahmenmodell der Software und liefert die Schnittstellen für sogenannte Komponenten oder Artefakte, die an die gemeinsame Plattform andocken können. Zur vereinfachten Vorstellung soll hierbei etwa der Herstellungsprozess von Automobilen genannt werden, bei denen es eine seit der Einführung von Produktlinien Komponenten eines Modells auch in späteren Modellen weiterverwendet werden können. Diese Komponenten müssen dabei im Nachhinein nicht mehr aufwändig modifiziert werden. Hierbei wird die Plattform durch den Unterboden, das Getriebe und die Karosserie gebildet, wobei es bei letzterer zu Variationen entsprechend der Wünsche des Verbrauchers kommt. So entstehen etwa eine Version als T-Modell, mit Ladefläche, längerem Radstand oder mit einer besonderen Ausstattung. Die Wiederverwendbarkeit von Komponenten bedeutet auch bei der Softwareentwicklung erhebliche Vorteile. Diese ergeben sich sowohl durch eine hohe Flexibilität der entwickelten Systeme, als auch durch Reduktion der Produktkosten, gesteigerte Qualität, einen schnelleren Marktstart und weiteren wichtigen Vorteilen gegenüber klassischer Softwareentwicklung. Im Folgenden sollen diese Unterschiede und Vorteile in der Entwicklung von Software unter dem Gesichtspunkt der Softwareproduktlinien gegenüber einer klassischen Softwareentwicklung genau herausgearbeitet werden. Auch Nachteile werden erläutert und es wird geklärt, welche Rahmenbedingungen nötig sind, damit Softwareproduktlinien effizient eingesetzt werden können. 2. WIEDERVERWENDBARKEIT VON KOMPONENTEN Bei der klassischen Softwareentwicklung ist eine Wiederverwendung von Komponenten in anderen Softwareprojekten durch die Verwendung von Interfaces möglich, dies wird aber in der Regel nur dann verwendet, wenn wenige Methoden

45 definiert werden sollen, da sie bei der Implementation immer vollständig implementiert werden müssen. In der Praxis handelt es sich daher häufig um zusätzliche Eigenschaften, mit denen eine Klasse angereichert werden soll (wie bspw. die Fähigkeit, Objekte miteinander zu vergleichen) [zk] und nicht im Sinne einer Softwareproduktlinie eingesetzt. Wenn Komponenten einer bereits bestehenden Software übernommen werden sollen, müssen diese in der Regel aufwändig umprogrammiert werden. Bei Softwareproduktlinien hingegen, wird festgelegt, dass es eine Projektspezifische Plattform gibt, die sich von Projekt zu Projekt unterscheidet, ausschlaggebend hierfür ist eine Anpassung der Softwarelösung an Kundenwünsche oder die Reaktion auf eine neue Marktsituation. An diese Plattform können Module andocken, die in der Summe eine individuelle Softwarelösung ergeben. Gerätes. Einem Unternehmen ist es so möglich, ein großes Repertoire von Komponenten für verschiedenste Kundenwünsche oder Marktsituationen zu entwickeln, ohne dass die dafür notwendigen Entwickler die Plattform genau kennen müssen, sodass sich der Aufwand zum Entwickeln einer neuen Komponente erheblich reduziert. Die daraus entstehenden Vorteile liegen auf der Hand: Durch die Wiederverwendung von Softwarekomponenten können Kosten bei zukünftigen Projekten gespart werden. Das Software Engineering Institute rechnet bei einer Entwicklung von Software mit Produktlinien von einer Kostensenkung um 60%. Außerdem weitet sich der Zugewinn auch direkt auf die menschlichen Resourcen aus, so können einzelne Entwickler längerfristig an die Entwicklung einzelner Komponenten gebunden werden, anstatt dieses Know-How nach der Beendigung eines klassischen Softwareprodukts zu verlieren. Durch diesen Umstand können bei Softwareproduktlinien der Bedarf an Entwicklungszeit um bis zu 87% reduziert werden.[uni] Durch die Zusammenstellung von Softwarelösungen durch die Komponentenbasierte Vorgehensweise lassen sich schnell und effizient völlig neue Systeme entwickeln, ohne dass aufwändige Neuprogrammierungen notwendig wären. Auch das entfernen überholter Softwarekomponenten aus einem System und der Austausch durch eine neue Komponente ist jederzeit problemlos möglich und zeigt die Flexibilität einer Softwareproduktlinie. Beim Austausch von Komponenten zeigt sich das volle Potential von Produktlinien, da eine Verbesserung von bereits bestehenden Systemen in der klassischen Industrie bei Beispielen, die ebenfalls Produktlinien einsetzen, nicht in der Art und Weise möglich ist, wie bei Softwareprodukten. Der nachträgliche Einsatz von neuen Komponenten und eine damit verbundene Verbesserung ist beispielsweise in der Auto-Industrie nicht vorgesehen. 3. PRODUKTLINIE AM BEISPIEL PRO- JEKT ARA Als Beispiel für das Aufbrechen klassischer Entwicklungsstratgien hin zu einer Produktlinienbasierten Entwicklung könnte das Smartphone mit dem Codenamen Ara von Google genannt werden. Bei diesem Gerät ist es möglich, Komponenten durch anstecken und entfernen an der Geräteplattform auszutauschen. Figure 1 zeigt einen Komnzeptentwurf dieses Figure 1: Projekt Ara - Komponentenbasiertes Smartphone [Mot] Google Ara verdeutlicht auch einen weiteren Vorteil der Wiederverwendung von Komponenten. So ist es weiterhin möglich, dass Komponenten nicht ausschließlich vom eigenen Unternehmen entwickelt, sondern durch externe Firmen angefertigt und in die eigenen Softwareprodukte integriert werden. Der Aufwand hierfür ist gering, da durch die gute Dokumentation beim Entwickeln mit Softwareproduktlinien ein Leitfaden für die Integration von neuen Komponenten entsteht. 4. VORBEREITEN EINER SOFTWARE- PRODUKTLINIE Während bei klassischer Softwareentwicklung von Individualsoftware nach kurzer Zeit mit der Implementierung begonnen werden kann und dadurch die Kosten für die Entwicklung linear verlaufen, muss bei der Durchführung eines Softwareentwicklungsprozesses mit Softwareproduktlinien zuvor die gemeinsame Plattform der entstehenden Produkte geplant werden. Hierbei ist von Bedeutung, welche Features zur Plattform gehören und somit in allen Variationen der Software enthalten sind und welche komponentenbasiert hinzugef ügt werden. Bei Softwareproduklinien wird also zunächst geklärt, welche Gemeinsamkeiten alle entstehenden Produkte haben und hieraus wird die gemeinsame Plattform zusammengesetzt. Die hinzukommenden Komponenten werden entweder auf Kundenwunsch hin neu entwickelt oder aus alten Systemen wiederverwendet. Durch dieses Vorgehen entstehen bei der Anwendung

46 Plattform. Es muss zu jeder Zeit spezifiziert werden, welche Teile des Programms welche Aufgaben übernehmen und welche Bedingungen die Teile erfüllen müssen, wenn eine Anpassung im Sinne der Softwareproduktlinien erfolgen soll. Dies bedeutet auch, dass gewisse Komponenten entfallen müssen, wenn eine andere Komponente eingesetzt wird. Als Beispiel könnte man sich vorstellen, dass wenn festgelegt wird, dass eine Software keine Bezahlmöglichkeit implementiert, ist es nicht notwendig, dass die Komponente für die Kreditkartenabrechnung im Gesamtprojekt verbleibt. Figure 2: [IBM] Komponenten von externen Zulieferern von Softwareproduktlinien bereits Kosten, bevor an der eigentlichen Arbeit begonnen werden kann, was auf den ersten Blick nicht notwendigerweise zu einer positiven Betrachtung führt. Letztendlich zahlt sich der Einsatz von Softwareproduktlinien jedoch aus, da davon ausgegangen wird, dass die Einsparung von Kosten durch den konsequenten Einsatz als deutlich höher eingeschätzt wird, sobald eine gewisse Anzahl von Systemen mithilfe von Softwareproduktlinien erstellt wurde. Im Folgenden werden einige Punkte aufgezählt, in denen sich Softwareproduktlinien von klassischer Softwareenticklung unterscheidet. Vor allem werden dabei die entstehenden Vorteile von Softwareproduktlinien herausgestellt. Es bleibt festzustellen, dass der Einsatz von Produktlinien im Softwarebereich 1 damit verbunden ist, dass große Anstrenungen im Bereich der Dokumentation und der Durchführung von Tests unternommen werden müssen, damit sich der Einsatz lohnt. 5. GEWONNENE FLEXIBILITÄT Flexibilität ist der wichtigste Ansatz bei Softwareproduktlinien. Wie bereits geklärt ist die Wiederverwendbarkeit von Komponenten ein wesentliches Kriterium für den Einsatz dieser Technologie. Dies bedeutet aber auch, dass nicht nur die Komponenten flexibel sein müssen, sondern auch die 1 Wie auch in anderen Bereichen Figure 3: Wiederverwendung von Komponenten in mehreren Systemen [IBM] Bei diesem Beispiel wird deutlich, wie genau im Vorfeld geplant werden muss, um die Flexibilität zu erreichen, die Softwareproduktlinien von der klassischen Softwareentwicklung, insbesondere bei Individualsoftware, unterscheidet. Außerdem wird festgelegt, an welchen Stellen sich die unterschiedlichen Endprodukte unterscheiden, sodass die gemeinsame Plattform eine möglichst breite gemeinsame Basis haben kann. Die gewonnene Flexibilität birgt einen weiteren Vorteil gegenüber klassischer Softwareentwicklung. So können bereits geschaffene und abgeschlossene Plattformen in neuen Produkten möglicherweise wieder Verwendung finden und durch die Kombination von einer bestehenden Plattform im Zusammenspiel mit neu entwickelten Komponenten zu einem völlig neuen Gesamtsystem kombiniert werden. Als Beispiel lässt sich hier die Produktion von Mobiltelefonen nennen, wo eine bestehende gemeinsame Plattform, also das Motherboard, mit neuen Komponenten bestückt (LCD, Prozessor, RAM) ein völlig neues Produkt ergibt.

47 Die entstandene Flexibilität erfordert allerdings ein Umdenken im Unternehmen. Wie bereits zuvor angedeutet, sind beim Einsatz von Softwareproduktlinien deutlich mehr Entwickler involviert als beim Herstellen von Individualsoftware. Die Entwickler müssen untereinander kommunizieren bzw. ihre Programmteile so entwickeln, dass sich diese nahtlos in verschiedene Plattformen integrieren lassen. Diese Notwendigkeit erfordert den Einsatz von neuen Strukturen, die überwachen, dass Arbeitsabläufe standardisiert und sauber dokumentiert werden. 6. REDUZIERUNG DER PRODUK- TKOSTEN Wie bereits erwähnt ist einer der wichtigsten Gründe für die Einführung von Softwareproduktlinien die Reduzierung der Kosten in der Entwicklung neuer Software. Durch die Wiederverwendung von Komponenten oder Plattformen ergibt sich ein erhebliches Einsparpotential bei der zukünftigen Entwicklung neuer Systeme. Nachdem mehrere Produktlinien geschaffen worden, reduzieren sich die Maßnahmen, die für ein neues System durchgeführt werden müssen, um ein erhebliches Maß. Nichtsdestotrotz ergibt sich beim ersten Einsatz von Softwareproduktlinien zunächst ein anderes Bild, da zunächst eine Plattform entwickelt werden muss, die die Möglichkeiten bietet, die zum Andocken weiterer Artefakte ben ötigt wird. Außerdem muss jede Komponente so geplant werden, dass diese an beliebige Plattformen andocken kann. Da diese Notwendigkeiten ein Umdenken und Umstrukturieren des Unternehmens bedeuten, wirken die Investitionen, die vor der Umsetzung einer Softwareproduktlinie getätigt werden müssen, auf den ersten Blick sehr hoch. Die folgende Grafik zeigt einen Vergleich der entstehenden Kosten zwischen Einzelsystemen im Vergleich zu Softwareproduktlinien. Die durchgezogene Linie visualisiert die Kosten bei der Entwicklung von Einzelsystemen, die gestrichelte Linie zeigt die Kosten einer Softwareproduktlinie. Mit einer wachsenden Zahl der Systeme auf der X-Achse steigen die Kosten der Entwicklung auf der Y-Achse. Zunächst fällt auf, dass die Grundkosten für eine Softwareproduktlinie nicht im Ursprung, also bei null, starten, sondern sogenannte Up- Front-Investments, also Startkosten anfallen. Wird ein einzelnes System oder eine geringe Zahl an Systemen entwickelt, ist die Einführung einer Produktlinie nicht kosteneffizient. Ab einer Anzahl von drei Systemen wird hingegen ein Break-Even Point, also der Kostendeckungspunkt erreicht, von dem an die Kosten für eine Softwareproduktlinie erheblich günstiger ausfallen, als für Individualsoftware [KP05]. Der Kostendeckungspunkt kann je nach Marktsituation oder Kundenanforderungen variieren und es sollte im Vorfeld der Entwicklung geklärt werden, ob die Einführung von Produktlinien sinnvoll ist. 7. GESTEIGERTE QUALITÄT Alle Komponenten, die für eine Softwareproduktlinie erstellt werden, erreichen durch die häufige Wiederverwendbarkeit Figure 4: Break-Even: Individualsoftware vs. Produktlinien [KP05] eine höhere Qualität. Ein wichtiger Faktor dabei ist die Wiederverwendbarkeit selber, da Komponenten für jede Plattform getestet, überprüft und gegebenenfalls weiterentwickelt werden müssen. Außerdem wird, aus dem Ansatz der Softwareproduktlinien hervorgehenden Konzept, jede Komponenten im Vorfeld ausgiebig designed und dokumentiert um genau die Wiederverwendbarkeit herzustellen. Durch dieses Design und den Einsatz auf mehreren Plattformen erhöht sich die Chance, Fehler schon während der Entwicklung zu erkennen und diese zu korrigieren, was direkt in einer Qualitätserhöhung der gesamten Plattform resultiert. Figure 5: Fehlerate Softwareproduktlinien [Kru] 8. SCHNELLERER MARKTSTART Die Einführung eines Produktes hat häufig einen Entscheidenden Einfluss auf den Erfolg des Systems. Wird ein früher Marktstart verpasst, können Konkurrenzprodukte den Markt sättigen, bevor das eigene Produkt veröffentlicht wird. Bei einzelnen unter klassischer Softwareentwicklung hergestellten Produkten kann der Marktstart schneller geschehen, wie aus Abbildung 6 hervorgeht. Dies hängt, wie bereits geklärt, mit der individuellen Entwicklung von Komponenten für Softwareproduktlinien zusammen. Sind diese Komponenten bereits aus vorhergehenden Systemen unter den Gesichtspunkten der Produktlinien entwickelt worden und können in die neu geschaffene Plattform integriert werden, reduziert sich die Zeit bis zum Marktstart erheblich.

48 Da neu- oder weiterentwickelte Komponenten auch ohne besonderen Mehraufwand in bereits fertiggestellte Softwarelösungen, die unter dem Gesichtspunkte der Softwareproduktlinien erstellt wurden, integriert werden k önnen, lässt sich eine gute Zukunftssicherheit erreichen. Hierbei wird explizit darauf hingewiesen, dass, im Gegensatz zu klassischer Softwareentwicklung, der Mehraufwand für einen Austausch von Komponenten fast kostenfrei ist. So kann auch die Qualität alter Systeme gesteigert werden und eventuell verlorene Marktanteile zurückgewonnen werden. Figure 6: Zeit zum Marktstart [KP05] Es wird also davon ausgegangen, dass die Einführung von Softwareproduktlinien auch im Hinblick auf die Time to market einen positiven Effekt hat, wenn es um die Wiederverwendbarkeit von Artefakten geht. 11. GESUNKENE KOMPLEXITÄT Aus klassischer Softwareentwicklung entstandene Systeme haben den Nachteil, dass durch nachträgliche Kundenwünsche oder veränderte Martksituationen eine Komplexität der Software entsteht, die nur schwer behandelt werden kann. Der Grund hierfür ist unter anderem die Einbringung neuer Funktionalitäten, die nicht im Design der Software zu Beginn des Entwicklungsprozesses vorgesehen waren. 9. GERINGERER WARTUNGSAUFWAND Die durch Softwareproduktlinien erstellten Komponenten für eine Plattform können universell für andere Plattformen weiterverwendet werden, dies ist der Grundgedanke von Softwareproduktlinien. Da bei einem erneuten Verwenden dieser Komponenten überprüft wird, ob eine einwandfreie Funktion gegeben ist, erhöht sich die Qualität der Komponenten pro eingesetzter Plattform. Ist eine Komponente diesen Prozess mehrmals durchlaufen, reduziert sich der Aufwand, die Komponente zu warten erheblich im Vergleich zu einer Weiterverwendung von Komponenten in klassischer Softwareentwicklung. Desweiteren ergibt sich ein reduzierter Wartungsaufwand dadurch, dass verbesserte Komponenten zeitgleich alle Systeme einer Produktlinie verbessern, in denen diese Komponente eingesetzt wird. Ein weiterer Vorteil ist, dass die Mitarbeiter, die Wartungen durchführen beim Einsatz von Softwareproduktlinien bestenfalls einzelne Komponenten testen, während bei Einzelsystemen häufig das gesamte System überprüft werden muss. Hier können spezialisierte Mitarbeiter deutlich effizienter arbeiten. Da Komponenten-Tests ein wesentlicher Teil eines Entwicklungsprozesses mit Softwareproduktlinien sind, vermindert sich der Aufwand solcher Tests durch den regelmäßigen Einsatz dieser Techniken mit der Zeit. 10. ZUKUNFTSSICHERE SOFTWARE Die Austauschbarkeit von Komponenten liefert die Möglichkeit, eine Evolution aller an einer Softwareproduktlinie beteiligten Systeme gleichzeitig zu erreichen. Wenn im Laufe der Zeit eine Komponente aufgrund neuer technischer Möglichkeiten neu entwickelt oder deutlich verbessert wird, kann diese in allen beteiligten Systemen durch die neue Komponente ersetzt werden. Figure 7: Anzahl Codezeilen bei Windows- Versionen Eine erhöhte Komplexität der Software nimmt direkten Einfluss auf die Qualität der Software. Entwicklern fällt es schwer, den Gesamtüberblick über die Software zu wahren, was direkt zu einer hohen Fehleranf älligkeit des Quellcodes bzw. der Software führt. Daraus resultieren schlussendlich längere Entwicklungszyklen und eine verlangsamung des Marktstarts. Durch die Komponentenbasierte Entwicklung bei Softwareproduktlinien kann einer solchen entstehenden Komplexität aufgehoben werden, indem Änderungen direkt in neue Komponenten ausgelagert werden und somit kein Ansteigen der Komplexität der Plattform mit sich bringt. Die bereits erwähnte erforderliche Dokumentation der Schnittstellen von Komponenten bei Softwareproduktlinien, die an der Plattform andocken, erleichtert Entwicklern die Übersicht und sorgt so für eine gleichbleibende Komplexität, was in einer geringen Fehleranfälligkeit und Entwicklungszeit führt. 12. KOSTENABSCHÄTZUNG Bei der Entwicklung mit Softwareproduktlinien kann die Entwicklungszeit der Anwendung im Gegensatz zu individuell

49 erstellter Software sehr leicht abgeschätzt werden, da sich diese lediglich auf Produkte beschränkt, die aus der Entwicklung und Kombination der Komponenten zusammen mit der Plattform ergeben. Am Beispiel eines Kunden, der ein Produkt bestellt, dass vom Unternehmen aus der Plattform A mit den Komponenten A, B, D und E, sowie einer Komponente X hergestellt wird, wird angenommen, dass die Plattform A und die Komponenten A, B, D und E bereits vollständig entwickelt wurden. Hier muss also lediglich die Entwicklungszeit für Komponente X berechnet werden um die Kosten für das Gesamtsystem ermitteln zu können, da die Kosten für das Anfertigen der Plattform mit den Artefakten bekannt ist. Kostenabschätzung ist ein wesentlicher Faktor bei der Wirtschaftlichkeit von Softwareprojekten. Lässt sich dieser Faktor im Vorfeld gut abschätzen, können Fehlinvestitionen vermieden werden. 13. KUNDENVORTEILE Der Vorteil von Softwareproduktlinien für den Kunden ist das Erlangen einer Softwarelösung, die auf die Bedürfnisse des Kunden zugeschnitten ist. Hierbei spielt die Wiederverwendung von Teilen der Software, wie sie bei Softwareproduktlinien üblich ist, eine große Rolle. Besonders im Bereich der grafischen Benutzeroberfläche wird deutlich, wie groß der Vorteil gegenüber Individualsoftware oder Software von der Stange ist. Beim Einkauf von Individualsoftware muss der Kunde gegebenenfalls damit leben, dass sich Elemente der Oberfläche von Version zu Version stark unterscheiden, selbst wenn vom gleichen Unternehmen gekauft worden ist. Aus diesem Umstand ist im Laufe der Zeit der Wunsch der Kunden nach einer gesteigerten Benutzerfreundlichkeit der Software entstanden. Diese Benutzerfreundlichkeit besteht aber nun eben nicht ausschließlich im Erstellen von intuitiven Benutzeroberflächen 2, sondern vor allem in einem gleichbleibenden Bedienkonzept zwischen verschiedenen Versionen. Softwareproduktlinien ermöglichen durch die modulare Funktionsweise genau diesen Ansatz. Wenn Teile der grafischen Benutzeroberfläche direkt durch die einzelnen Komponenten implementiert oder erweitert werden, ändert sich die GUI nur in diesen Teilen, während das Gesamtkonzept identisch bleibt. Die dadurch entstehende Konsistenz führt direkt zu einer geringeren Lernbelastung f ür die Mitarbeiter eines Unternehmens. Ein weiterer Vorteil von Softwareproduktlinien, der bereits erwähnt wurde, spiegelt sich auch in der Kundenzufriedernheit wieder, die gesteigerte Produktqualität. Durch das ausgiebige und wiederholte Testen der Komponenten, hervorgerufen durch den mehrfachen Einsatz im Sinne der Softwareproduk- 2 Dies ist bei sehr komplexen Anwendungen m öglicherweise gar nicht möglich, da der große Funktionsumfang eine intuitive Bedienung nicht erlaubt. Anhand von Umfangreichen Softwarelösungen wie Microsoft Word lässt sich erkennen, dass die Einführung von einem neuen Bedienkonzept (Ribbons) gerade bei fortgeschrittenen Benutzern oder Profis eher dazu führt, dass wichtige Funktionen nicht oder nur sehr schwer erreichbar sind. tlinien, sinkt die Anzahl von Fehlern in den Komponenten erheblich. Als Resultat erhält der Benutzer eine Software, die deutlich weniger fehleranfällig ist, als Individualsoftware. Außerdem sinken bei Softwareproduktlinien 3 die Kosten für die Softwarelösung gegenüber Individualsoftware deutlich, sodass ein Wettbewerbsvorteil für Anwendungen aus Softwareproduktlinien entsteht. Müssen außerdem neue Komponenten für einen Kunden entwickelt werden, kann dies in einer zeitlich sehr schnellen Abfolge geschehen, da die Schnittstellen für neue Komponenten klar definiert und die Arbeitsabläufe zum Integrieren neuer Komponenten bekannt sind. Dadurch ist die Erweiterung der Plattform kostentechnisch sowohl für den Auftraggeber, als auch für den Auftragnehmer sehr transparent. Desweiteren können zusätzlich aus Kundenwünschen erstellte neue Komponenten auch für alle anderen Anwendungen einer Softwareproduktlinie übernommen werden, was es dem Auftragnehmer ermöglicht dem Kunden weitere Kosten zu ersparen, wenn die Komponente für weitere Anwendungen infrage kommt. Auch die Implementierung neuer oder verbesserter Komponenten aus neuen Anwendungen einer Softwareproduktlinie in bereits bestehende Anwendungen ist problemlos möglich und bedeutet für den Kunden eine regelmäßige Aktualisierung und Verbesserung seiner Software über einen langen Zeitraum, ohne dass hierfür ein besonderer Aufwand notwendig wäre. 14. BEWERTUNG Softwareproduktlinien beweisen, dass es möglich ist, individuelle Softwarelösungen zu erstellen, ohne das Rad jedes Mal neu zu erfinden. Durch den Einsatz von individuell angefertigten Komponenten können Entwickler neue Funktionalität zu einem Produkt hinzufügen, ohne Wissen über das Gesamtsystem besitzen zu müssen, was den Entwicklern die Möglichkeit gibt, sich stark zu spezialisieren. Vorteilhaft gegenüber Individualsoftware ist außerdem die gewonnene Flexibilität. Es ist in kurzer Zeitabfolge möglich, verschiedene Produkte zu veröffentlichen, die eine unterschiedliche Ausprägung von Features beinhalten, die auf verschiedene Kundenwünsche zugeschnitten sind. Hierbei kann auch der Kostenfaktor auf Kundenseite eine Rolle spielen, beispielsweise bei der Verbreitung von Professional- oder Enterprise-Versionen eines Produktes. Durch den Einsatz von Softwareproduktlinien entsteht die Chance, die Produktkosten für eine Softwarelösung erheblich zu reduzieren. Wie in Kapitel 6 angeführt, lässt sich bereits mit einigen wenigen verschiedenen Systemen aus einer Produktlinie ein Kostendeckungspunkt erreichen, ab dem die Gesamtkosten für eine neue Softwarelösung deutlich geringer ausfallen als bei einer klassischen Softwareentwicklung. Auch die Kostenabschätzung fällt bei Produktlinien deutlich einfacher aus, hier muss lediglich bestimmt werden, welcher Aufwand für eventuell neuzuprogrammierende Komponenten 3 Wenn der Kostendeckungspunkt erreicht ist

50 entstehen wird um die Gesamtkosten für eine Softwarelösung zu ermitteln. Beim Erstellen von Systemen unter den Vorgaben von Softwareproduktlinien müssen Richtlinien eingehalten werden, damit Komponenten sich in die gemeinsame Plattform integrieren können. Hierbei entsteht Investitionsaufwand, der vor dem eigentlichen Projektstart anfällt, was als Nachteil ausgelegt werden könnte. Im Nachhinein stellt sich jedoch die notwendige Dokumentation beim Einsatz von Produktlinien und die Vorbereitung als Qualitätsmerkmal heraus, da die erhöhte Dokumentation zu weniger Fehlerhafter Software führt. Auch die mehrfache Anpassung von Komponenten für zukünftige Softwareversionen führt dazu, dass sich die Codequalität auch in allen anderen Systemen verbessert, die dieselbe Komponente verwendet. Liegt eine ausreichende Anzahl von verschiedenen Komponenten und eine breite Basis von Plattformen bereits vor, kann neue individuelle Software sehr schnell entwickelt werden, indem eine Mischung aus bereits bestehenden Komponenten und Neuentwicklungen kombiniert wird. Dadurch kann sich der Marktstart für ein neues Projekt sehr schnell stattfinden. Ein Nachteil von Produktlinien sind sicherlich die Vorabkosten, die eine Produktlinie erfordert. Werden nicht ausreichend viele Systeme erstellt, können die Gesamtkosten von Individualsoftware geringer sein als von Softwareproduktlinien (vgl. [KP05]). Deshalb rentiert sich dessen Einsatz eher für mittelständische Unternehmen, die häufig neue und unterschiedliche Softwareprodukte entwickeln. Zuletzt werden die gewonnenen Erkenntnisse der Arbeit in Kapitel 14 aufgegriffen und einer Bewertung unterzogen. Hier wird deutlich, welche Vor- und Nachteile die Entwicklung von Software mit Produktlinien hat. 16. REFERENCES [IBM] IBM. Modsoc - product line modeling for system-on-a-chip. [Online; Stand 06. Februar 2015]. [KP05] Frank van der Linden Klaus Pohl, Günter Böckle. Software Product Line Engineering. Springer, Berlin, [Kru] Charles W. Krueger. Introduction to the emerging practice off software product line development. [Online; Stand 06. Februar 2015]. [Mot] Motorola. Grafik - projekt ara. [Online; Stand 06. Februar 2015]. [Uni] Carnegie Mellon University. Software product lines - overview. [Online; Stand 06. Februar 2015]. [zk] Universität zu Köln. Abstrakte klassen und interfaces. [Online; Stand 06. Februar 2015]. 15. FAZIT Die vorliegende Arbeit belegt, dass es erhebliche Unterschiede zwischen einer klassischen Softwareentwicklung einer Individualsoftware und einer Softwareproduktlinie gibt. Wie in Kapitel 2 dargestellt, beläuft sich der grundsätzliche Unterschied in der Herstellung einer gemeinsamen Plattform, die durch wiederverwendbare Komponenten mit Funktionalitäten erweitert wird. Bei einer klassischen Individualsoftware ist dieser Prozess nicht in diesem Umfang zu beobachten. Im weiteren Verlauf der Arbeit wird gezeigt, wie sich die Vorbereitung einer Softwareproduktlinie von der Vorbereitung einer klassischen Software-Entwicklung unterscheidet. Es wird deutlich, dass der initiale Aufwand von Softwareprodukten erheblich höher ist. In den Kapiteln 5 bis 12 werden die Unterschiede der beiden Entwicklungsmethoden anhand von Kriterien erläutert, die für den Auftraggeber von erheblicher Bedeutung bei der Planung von Software ist. Hierbei wird konkret auf Flexibilität, Produktkosten, Softwarequalität, Time to market, Komplexität, Wartungsaufwand, Zukunftssicherheit und Kostenabschätzung eingegangen. Im Kapitel 13 wird schließlich erläutert, welche Auswirkungen der Einsatz einer Softwareproduktlinie auf die Ansprüche des Kunden hat. Neben Änderungswünschen von Seiten der Kunden wird hier auch diskutiert, inwiefern sich eine Anpassung einer Softwarelösung eines Kunden auf ein Gesamtsystem auswirken kann.

51 Requirements Engineering im SPL-Umfeld Manuel Wörmann Universität Siegen ABSTRACT Requirements Engineering im Umfeld von Softwareproduktlinien umfasst zwei Teilprozesse, das Domain Requirements Engineering sowie das Application Requirements Engineering. Beim Domain Requirements Engineering werden die Haupt-Anforderungen, die das Grundsystem bieten soll, um später verschiedene Ausprägungen in Form von Applikationen abzuleiten, analysiert, modelliert und spezifiziert. Das Application Requirements Engineering behandelt dagegen spezielle Anforderungen einzelner abzuleitender Applikationen. Wichtige Ziele beim Einsatz von Requirements Engineering bei der Planung vom Softwareproduktlinien ist das Erreichen eines hohen Grades an Wiederverwendbarkeit sowie hohe Flexibilität bei der Ableitung von Applikationen. 1. EINLEITUNG Requirements Engineering bezeichnet in der Informatik einen Prozess in der Vorbereitungsphase eines Entwicklungsprojekts. Hierbei werden Anforderungen an das zu entwickelnde Produkt oder System auf Basis genereller Geschäftsziele und Vorgaben auf systematische Weise erhoben mit dem Ziel dokumentierte Anforderungen an Produkte oder Systeme zu erhalten, die mit den Ansprüchen aller Beteiligten möglichst gut im Einklang stehen.[3] gen einbringt. Des Weiteren ist es wichtig, dass eine Softwareproduktlinie sehr flexibel ist, um möglichst vielseitig neue Applikationen ableiten zu können, die auf den Kunden passend zugeschnitten sind. Die Ergebnisse des Requirements Engineering werden letztlich beim konkreten Entwurf der jeweiligen Softwareproduktlinie eingesetzt. 2. DOMAIN REQUIREMENTS ENGI- NEERING Der Prozess des Domain Requirements Engineering verfolgt das Ziel, die Anforderungen für alle absehbaren Anwendungen einer Softwareproduktlinie zu definieren. Hierzu werden so genannte common domain requirements und variable domain requirements entwickelt und dokumentiert. [2] (S. 194) Das Domain Requirements Engineering steht in Verbindung mit anderen Teilprozessen des Domain-Engineering- Prozesses, wie dem Product Management und Domain Design sowie mit dem Application Requirements Engineering, welcher dem Application Engineering zugehörig ist. [2] (S. 194f.) Die Hauptaufgaben des Requirements Engineering Im Umfeld von Softwareproduktlinien (SPL) besteht das Requirements Engineering aus den zwei Teilprozessen domain requirements engineering und application requirements engineering, welche wiederrum selbst aus unterschiedliche Phasen bestehen. Beide Teilprozesse stehen in ständiger Beziehung zueinander, so dass eine strikte zeitliche Trennung der Prozesse nicht möglich ist. Die Herausforderung besteht darin, möglichst früh in der Planungsphase einer Softwareproduktlinie bereits sehr präzise vorherzusehen, welche Anforderungen sinnvollerweise später an das Gesamtsystem sowie abgeleitete Applikationen gestellt werden könnten. Hierdurch soll eine hoher Wiederverwendbarkeitsgrad von zu entwickelnden oder bereits entwickelten Komponenten gewährleistet werden, was in der Praxis Kosteneinsparun- Figure 1: Domain Requirements Engineering im Zusammenspiel mit anderen Teilprozessen [2] (S. 194) lassen sich in fünf Punkte fassen: Erhebung (Elicitation): Die Bedürfnisse der Benutzer

52 an das System sowie notwendige Einschränkungen verstehen Dokumentation (Documentation): Die erhobenen Anforderungen gut strukturiert dokumentieren Verhandlung (Negotiation): Einen ausreichenden Konsens zwischen allen stakeholdern 1 unter Berücksichtigung der dokumentierten Anforderungen finden Validierung und Verifizierung (Validation and Verification): Sicherstellen der Deutlichkeit, Vollständigkeit, Korrektheit und Verständlichkeit der Systemanforderungen Verwaltung (Management): Kontinuierliche Pflege der Systemanforderungen während der Entwicklung sowie der Laufzeit des Systems, um die ständige Verfügbarkeit einer aktuellen und konsistenten Spezifikation zu gewährleisten. [2] (S. 197f.) Die Herausforderung des Domain Requirements Engineering einer Softwareproduktlinie besteht darin, die gesamte Variabilität der Produktlinie zu berücksichtigen. Dadurch entstehen drei weitere Aufgaben, die speziell beim Requirements Engineering von Softwareproduktlinien anfallen: Gemeinsamkeiten-Analyse (commonality analysis): Identifikation der Anforderungen die alle Applikationen betreffen Variabilitätsanalse (variability analysis): Identifikation und Präzisierung der Anforderungen, die sich für einzelne Applikationen unterscheiden Modellierung der Variabilität (variablity modeling): Modellierung von variation points, Varianten und deren Beziehungen [2] (S. 198f.) Neben der Identifikation und Modellierung der Variabilität ist es wichtig, dass eine Konsistenz zwischen den unterschiedlichen so genannten requirements artefacts sowie deren Dokumentationen herrscht. Requirements Artefacts können dabei Features, Szenarien, Datenmodelle, funktionale Modelle, textuelle Anforderungen, etc. sein. (Kapitel 5) Die während des Domain Requirements Engineering definierten Requirements Artefacts umfassen letztendlich gemeinsame und variable Anforderungen. Der erste Schritt dahin ist die Gemeinsamkeiten-Analyse, welche aus zwei Schritten besteht: 1. Identifikation eines Satzes von gemeinsamen Anforderungen 2. Detaillierte Dokumentierung dieser Anforderungen in einem geeigneten Repräsentationsformat Diese beiden Schritte werden iterativ wiederholt und die Anforderungen somit immer weiter überarbeitet. [2] (S. 199f.) 1 Personen, die in irgendeiner Verbindung zum Produkt stehen, z.b. Produktmanager, Requirement Engineers, Kunden, etc. Bei der Definition der gemeinsamen Anforderungen müssen zwei Merkmale besonders berücksichtig werden: Da sie die Basis für alle Applikationen der Produktlinie bilden, muss besonders viel Wert auf die Aktualität, Konsistenz und eine hohe Qualität der Requirements Artefacts gelegt werden. Zur Gewährleistung der Qualität können auch Reviews eingesetzt werden. Durch die Evolution der Produktlinie kann eine gemeinsame Anforderung durch Einführung einer neuen Variabilität zu einer variablen Anforderung werden. Durch ausführliche Dokumentation kann das Verständnis einzelner gemeinsamer Anforderungen verbessert und so eventuell unnötige Änderungen in variable Anforderungen verhindert werden. [2] (S. 200) Variable Anforderungen werden bei der Variabilitätsanalyse ermittelt. Diese beinhaltet auch die Modellierung der Variabilität. Sie umfasst vier Schritte: 1. Identifikation von variablen Anforderungen 2. Entwicklung eines OVM (Orthogonales Variabilitätsmodell) 3. Detaillierte Dokumentation dieser Anforderungen in einer geeigneten Notation 4. Herstellung der Beziehungen zwischen allen variablen Requirement Artefacts und den entsprechenden Varianten im OVM. Die Schritte 3 und 4 werden hierbei so lange wiederholt, bis alle Views berücksichtigt wurden. [2] (S. 200) Der Prozess des Domain Requirements Engineering bezieht verschiedene Anforderungs-Quellen mit ein. Hierzu gehören unter anderem Stakeholder, bereits existierende Produkt, Fehlerberichte oder auch Produkte von Mitwettbewerbern. Alle diese Quellen können zur Definition der benötigten Funktionen berücksichtigt werden. Bei der Identifikation der Domain-Anforderungen und deren Variabilität werden oftmals bereits existierende Applikationen verwendet. [2] (S. 201) Neben der Erhebung von Anforderungen an die Applikationen der Produktlinie, müssen auch deren Gemeinsamkeiten definiert werden. Dabei ist es wichtig die Variabilität auf das absolut benötigte Minimum zu reduzieren und gleichzeitig so viel Gleichheit wie möglich zu erreichen. Je Mehr Gleichheit besteht, desto weniger Aufwand muss in die Flexibilität investiert werden. Die gemeinsamen Anforderungen bilden somit die Basis einer jeden Applikation einer Softwareproduktlinie. Dennoch sollte die Variabilität natürlich einen Grad erreichen, der es ermöglicht Applikationen zu erstellen, die die Ziele und Wünsche der potenziellen Kunden erfüllen können. [2] (S. 201) 2.1 Gemeinsamkeiten-Analyse Zur Identifikation der gemeinsamen Anforderungen werden zunächst die Anforderungen aller für die Produktlinie vorgesehenen Applikationen untersucht. Anforderungen, die all

53 diese Applikationen stellen, sind naheliegende Kanditaten für gemeinsame Anforderungen. Für diese Analyse gibt es verschiedene Werkzeuge. Oft wird hierfür beispielsweise eine Application-Requirements-Matrix eingesetzt. [2] (S. 201f.) Dabei wird eine Tabelle erstellt, die als Spaltenüberschriften Der nächste wichtige Schritt besteht in der Definition der Variabilität. Hier wird wieder das Orthogonale Variabilitätsmodell eingesetzt. Dieser Schritt besteht aus folgenden drei Teilaspekten: Wohlbedachte Definition der passenden Variation Points sowie Varianten, Ermittlung ihrer Abhängigkeiten, Beschluss, welcher Teil der Variabilität der Produktlinie den Kunden als externe Variabilität angeboten werden soll. [2] (S. 206) Figure 2: Matrix Beispielhafte Application-Requirements- die vorgesehenen Applikationen erhält und als Zeilen alle Anforderungen. In Figure 2 ist zu sehen, dass Anforderung 2 für alle Anwendungen in diesem Beispiel gilt, also einen aussrichtsreicher Kandidaten für eine gemeinsame Anforderung darstellt. [2] (S. 202) 2.2 Variabilitätsanalyse Die Variabilitätsanalyse zielt darauf ab, die Variabilität der Anforderungen zu bestimmen. Außerdem werden bei diesem Schritt die Variation Points und deren Varianten in Bezug auf die Anforderungen definiert. Zuerst wird hierzu nach so genannten High-Level-Requirements gesucht. Dies sind Anforderungen, die einzig an einer einzige Teilmenge von Applikationen gestellt werden oder solche, die in verschiedenen Applikationen der Produktlinie, unterschiedliche Charakteristiken aufweisen. Resultat der Variabilitätsanalyse sind die bereits angesprochenen Variation Points und Varianten. [2] (S. 204) Bei der Variabilitätsanalyse können die gleichen Techniken wie bei der Gemeinsamkeiten-Analyse eingesetzt werden. Demnach kann auch hier eine Application-Requirements- Matrix aufgestellt werden, wobei in diesem Fall dann genau die Anforderungen, die nur eine einzige oder eine kleinen Teilmenge von Applikationen betreffen, Kandidaten für Variable Anforderungen darstellen. Aus dem Beispiel (Figure 2) folgt demnach, dass es naheliegt, dass Anforderung 4 variabel ist. [2] (S. 205) Ein anderer Ansatz ist die Priority-Based Variability Analysis. Hierbei werden den Anforderungen, die an die Applikationen gestellt werden, von den Stakeholdern Prioritäten zugeordnet. Jene Anforderungen, die für einige Stakeholder eine hohe Priorität und für andere wiederrum eine niedriger Priorität aufweisen, sind eindeutige Aspiranten für variable Anforderungen. Es können jedoch auch Konflikte auftreten, wenn Anforderungen, die von möglicherweise unterschiedlichen Benutzergruppen mit einer hohen Priorität versehen wurden, miteinander in Konflikt stehen. Dieser Konflikt kann aus technischen Inkompatibilitäten bestehen oder auch aus semantischen Widersprüchen. [2] (S. 203) 2.3 Definition der Anforderungsvariabilität Aus den dokumentierten Anforderungen geht oft nicht eindeutig hervor, welche Variante in Beziehung zu welchem Variation Point besteht. Ein Blick auf die unterschiedlichen Varianten reicht hier jedoch oft aus, um festzustellen, welche Varianten einem gemeinsamen Variation Point unterliegen. Wenn beispielsweise eine Applikation A1 die Anforderung Zugriff auf das System soll erst nach Prüfung des Fingerabdrucks erfolgen hat und eine Applikation A2 weist die Anforderung Zugriff nur mit Mitarbeiterausweis auf, ist deutlich erkennbar, dass der gemeinsame Variation Point hier der Mechanismus zur Identifikation für den Systemzugriff ist. [2] (S. 206) Nach der Definition eines Variation Points und seiner initialen Varianten, werden mögliche zusätzliche Varianten gesucht. Dies kann den Grund haben, einen Zusatznutzen für den Benutzer zu schaffen oder/und auch vor allem, um sich von der Produktlinie eines konkurrierenden Unternehmens abzuheben. Dieser Schritt könnte auch vor der Definition des Variation Points durchgeführt werden, in der Praxis hat sich jedoch gezeigt, dass der Variation Point sowie die bereits vorhanden Varianten das Finden von weiteren sinnvollen Varianten erleichtern. [2] (S. 207) Die möglichen Kombinationen von Varianten für eine Applikation einer Softwareproduktlinie ergibt sich aus den Variabilitätsabhängigkeiten zwischen einem Variation Point und seinen Varianten sowie den fest definierten Alternativen 2. Bei der Definition von Variabilitätsabhängigkeiten ist zu beachten, dass die Variabilität einer Softwareproduktlinie einen großen Einfluss auf dessen Referenzarchitektur haben kann, weshalb neben dem Requirement Engineer auch Softwaretechniker in den Vorgang der Variabilitätsdefinition involviert sein sollten. [2] (S. 207) Zudem müssen Einschränkungen so genannte constraint Figure 3: Constraint Dependency requires [2] 2 Alternativen (XOR) werden im OVM durch einen Bogen über den Verbindungen zwischen Variation Point und Varianten dargestellt (siehe Figure 3, rechts)

54 dependencies definiert werden. Sie geben an, welche Variation Points und/oder Varianten nur gemeinsam bzw. nicht gemeinsam auftreten dürfen. Constraint dependencies gehen aus der Tatsache hervor, dass es Einflüsse zwischen Variation Points, zwischen Varianten und/oder zwischen Variation Points und Varianten geben kann. Sie treten entweder in der Form requires oder excludes auf. Kann beispielsweise eine Variante V5 nur dann auftreten, wenn auch eine andere Variante V2 aktiv ist, wird zwischen ihnen die constraint dependency requires definiert. Wäre V5 auf der anderen Seite nur möglich, wenn V2 inaktiv ist, würde hier excludes verwendet. Bild 3 zeigt ein konkretes Beispiel für das Auftreten von requires. Wenn Video Surveillance (Videoüberwachung) als Feature einer Alarm- /Überwachungsanlage gewählt wird, muss auch die entsprechende Qualität der Videoüberwachung festgestelt werden, für welche es in diesem Fall die drei Möglichkeiten High Quality, Mid Quality oder Low Quality zur Auswahl gibt. [2] (S. 209) Die letzten Entscheidungen bezüglich der Aufnahme von Variabilität in die Domain Requirements Artefacts obliegen dem Produkt-Management. Es hat zu entscheiden: Artefacts für eine bestimmte Applikation benötigt werden. Hierbei sollen so viele der Domain Requirements Artefacts wie möglich wiederverwendet werden. [4] (S. 308) Üblicherweise sind auch Produktmanager und Kunden in den Prozess des Application Requirements Engineering involviert. Die Produktmanager legen die Hauptmerkmale der Applikationen fest, während Kunden Anwendungen fordern, die ihren individuellen Vorstellungen entsprechen und zu einem erschwinglichen Preis zu haben sind. Da Kunden in diesem Stadium der Entwicklung jedoch meist noch nicht persönlich bekannt sind, werden sie häufig von Produktmanagern und Marketingexperten repräsentiert. [4] (S. 309) Auch das Application Requirements Engineering steht in Verbindung zu anderen Teilprozessen. Natürlich besteht eine Beziehung zum Domain Requirements Engineering und wie bereits bei jenem Prozess auch zum Product Management. Daneben spielt das Application Design auch eine Rolle. [4] (S. 309ff.) Ob ein identifizierter und definierter Variation Point in die Produktlinie aufgenommen werden soll oder nicht oder ob überhaupt Variation Points hinzugefügt werden sollen. Ob identifizierte und definierte Varianten in die Produktlinie aufgenommen werden sollen oder ob überhaupt Varianten hinzugefügt werden sollen. Ob die Abhängigkeiten und Variability Constraints korrekt sind und ob und falls ja, wie sie adaptiert werden sollen. Ob ein Variation Point als externe Variabilität oder interne Variabilität eingeordnet wird. [2] (S. 209) 2.4 Relevanz von Domain Requirements Engineering für SPL Es lässt sich zusammenfassen, dass das Hauptziel beim Domain Requirements Engineering in der vorausschauenden Entwicklung von gemeinsamen und variablen Requirements Artefacts liegt. Diese sollen eine große Wiederverwendbarkeit beim späteren Entwicklungsprozess garantieren. Dazu wird zuerst untersucht, welche Anforderungen alle Applikationen der Produktlinie betreffen und welche sich unterscheiden. Zur Erkennung der unterschiedlichen Varianten einer Produktlinie wird die Variabilität bestimmt. Diese wird im so genannten orthogonalen Variabilitätsmodell dargestellt. Hierzu müssen die Variation Points und die zugehörigen Varianten definiert werden, was durch Abstraktion von den variablen Anforderungen geschieht. Ebenso werden die Variability Dependencies und Constraint Dependencies definiert. [2] (S. 215f.) 3. APPLICATION REQUIREMENTS EN- GINEERING Beim Application Requirements Engineering geht es darum, zu erkennen und zu dokumentieren, welche Requirements Figure 4: Application Requirements Engineering im Zusammenspiel mit anderen Teilprozessen [4] (S. 308) Es gibt zwei Kategorien von Applikationen einer Softwareproduktlinie: Applikationen, die nur aus Requirements Artefacts bestehen, die eine Teilmenge der Domain Requirements Artefacts sind. Applikationen, die Requirements Artefacts haben, die nicht Teilmenge der Domain Requirements Artefacts sind. Für Applikationen der ersten Kategorie werden den Stakeholdern einfach die vorhandenen Domain Requirements Artefacts unterbreitet, woraufhin die benötigten Artefacts ausgewählt und dokumentiert werden. Applikationen der zweiten Kategorie stellen da schon eine größere Herausforderung dar. Hier müssen die Deltas zwischen den vorhan-