Variabilitätsmanagement im Kontext von software-basierten Experimentalsystemen

Transkript

1 Variabilitätsmanagement im Kontext von software-basierten Experimentalsystemen Diplomarbeit zur Erlangung des akademischen Grades Diplominformatiker Humboldt-Universität zu Berlin Mathematisch-Naturwissenschaftliche Fakultät II Institut für Informatik

2 eingereicht von: Alexander Wagner geboren am: in: Berlin Gutachter(innen): Prof. Dr. Klaus Bothe Prof. Dr. Hartmut Wandke eingereicht am: verteidigt am: ii

3 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis Tabellenverzeichnis Abbildungsverzeichnis Abkürzungen vi vii ix 1. Einleitung Motivation Experimentalsysteme Projekt ArbeitsTeilung Entwickler-Operateur SAM SAM in ATEO SAMj Zielstellung und Ergebnisse der Arbeit Aufbau der Arbeit Software Product Lines Einführendes Besipiel Überblick Product Line Development Core Asset Development Product Line Scope Core Assets Production Plan Product Development Management Variabilitätsmodelle Anforderungen an ein Variabilitätsmodell Vorteile eines guten Modells Orthogonales Variabilitätsmodell Featuremodell Vergleich zwischen Featuremodell und OVM Ansatz Übersicht Vorarbeiten iii

4 Inhaltsverzeichnis Inhaltsverzeichnis 3.3. Methode zur Migration eines Einzelproduktsystems zur SPL Featureanalyse Feature identifizieren Anforderungsdokumentation Review Core Asset Development Architekturentwurf Refactoring und Neuimplementation Tests Review Erzeugung eines Features Requirement Engineering Anpassung des Featuremodells Implementation Tests Integration in Variabilitätsmanagement Review Variabilitätsmanagement Einführung Umsetzung Featuremodell von GenLabS Dokumentation Genese des Featuremodells von GenLabS Featuremodell von SAMs Featuremdodell von SAMj Vollständiges Featuremodell von GenLabS Featuremodell von GenLabS Konzept Protokollierung Grafik Engine Tracking Simulation Architektur von GenLabS Überblick Schicht Application Paket control Schicht Management Paket managementinterface Paket io Paket input Paket expconfig Paket logging Paket gui Paket productconfigurator iv

5 Inhaltsverzeichnis Inhaltsverzeichnis 5.4. Schicht Model Paket modelinterface Paket objectsystem Paket sim Paket config Paket simobjects Paket engine Implementation Variabilitätsmanagement Produktkonfigurator Featureparser Featurerepräsentation Versuchskonfiguration Controller und Parser Versuchsrepräsentation Zusammenfassung und Ausblick Zusammenfassung Ausblick A. Featuremodell 86 A.1. Featuredokumentation von GenLabS B. Variabilitätsmanagement 91 B.1. Konfigurationsdetails C. Implementationsdetails 92 C.1. Attribute für SimObjectSystem C.2. Die Simulationsstatus Literaturverzeichnis 97 v

6 Tabellenverzeichnis Tabellenverzeichnis Tabellenverzeichnis Möbelhausbeispiel: Schrankmodelle Möbelhausbeispiel: Türen Featuredokumentation Eingabegerät A.1.1. Featuredokumentation GenLabS B.1.1. Varibilitätsmanagement B.1.2. Standardkonfiguration GenLabS C.1.1. Attributbezeichner für Pacours C.1.2. Attributbezeichner für Trackingobjekt C.1.3. Attributbezeichner für Hindernisse C.1.4. Attributbezeichner für dynamische Hindernisse C.1.5. Attributbezeichner für statische Hindernisse C.2.6. Simulationsstatus vi

7 Abbildungsverzeichnis Abbildungsverzeichnis Abbildungsverzeichnis Arbeitsteilung Operateur und Entwickler Strecke in SAMs Kosten von SPLs Aktivitäten in der Product Line Entwicklung Core Asset Development Attached Processes Product Development Variationspunkt Variante Varibilitätsabhängigkeiten Alternative Wahl Grenzabhängigkeiten OVM Beispiel Featuresdarstellung Obligatorische Feature Optionale Feature Alternative Feature Oder-Feature Featuremodell Beispiel Migration SAMs zu GenLabS Übersicht der Arbeitsschritte Architektur von SAMj Architektur von SAMj Migrationsmethode im Überblick Erweiterungsmethode im Überblick Vererbung Übersicht Featuremodell Featurediagramm SAMs Featurediagramm SAMj Featurediagramm Anforderungsanalyse GenLabS Featurediagramm GenLabS Speed Indicator Architektur GenLabS Schicht Application vii

8 Abbildungsverzeichnis Abbildungsverzeichnis Paket control Schicht Management Paket Managementinterface Paket input Paket expconfig Paket logging Paket gui Paket productconfigurator Schicht Model Paket modelinterface Paket objectsystem Paket sim Unterpaket config Unterpaket simobjects Unterpaket engine viii

9 Abkürzungen Abkürzungen Abkürzungen AAF ALS AMD ATEO CSV ATEO Automation Framework ATEO Lab System ATEO Master Display Arbeitsteilung Operateur und Entwickler Comma-SeparatedValuesn GenLabS Generic Laboratory Software GUI SAM SAMj SAMs MWB OVM SPL XML Graphics User Interface Socially Augmented Mircowold (Konzept) Socially Augmented Mircowold in Java (Implementation in Java) Socially Augmented Mircowold in Smalltalk (Implementation in Smalltalk) Mikroweltbewohner Orthogonales Variabilitätsmodell Software Product Line Extensible Markup Language ix

10 1. Einleitung 1.1. Motivation 1. Einleitung 1.1. Motivation Experimentalsysteme In der experimentellen Ingenieurspsychologie wird unter anderem die Wirkung von Automatisierung und Assistenz in verschiedenen Anwendungen untersucht. Bisher gab es fünf Ansätze zur softwareunterstützten Durchführung von ingenieurspsychologischen Experimenten (Wandke und Bothe, 2009). Der erste Ansatz ist der Einsatz von realen Systemen, welche die Bedienung und Überwachung von Mensch-Maschine-Systemen übernehmen. Diese sind jedoch in wenigen Bereichen einsetzbar, da sie keine Möglichkeit bieten die Auswertung in automatisierter Form durchzuführen. Des Weiteren bieten sie nur in begrenztem Maße die Möglichkeit die Versuche zu variieren. Ein solch reales System ist die Analyse von Bedienhandlungen während des Autofahrens. Ein zweiter Ansatz sind maßgeschneiderte Lösungen, die jedoch nicht oder nur mit erheblichem Mehraufwand nachgenutzt werden können. Mit dieser Lösung werden komplexe dynamische Zusammenhänge dargestellt, z.b. Simulationen von Mikrowelten. Eine Erweiterung stellen die Semi-maßgeschneiderten Lösungen dar, die jedoch meistens für andere Zwecke entworfen wurden und bei intensiverer Nutzung mit den Mitteln der Informatik erweitert werden müssen beispielsweise LOGO und Squeak. Eine vierte Gruppe bilden experimental operating systems, welche hervorragende Möglichkeiten zur Erstellung von Experimenten der psychologischen Grundlagenforschung bieten, jedoch für den Einsatz innerhalb der ingenieurspsychologischen Forschung ungeeignet sind. Ein solches System stellt Presentation dar, welches die Durchführung einer Vielzahl von Experimenten ermöglicht. Der fünfte Ansatz sind abgeschlossene ingenieurspsychologische Komplettsysteme, die allerdings Hardware gebunden sind und in den meisten Fällen nur als geschlossene Komplettsysteme verbreitet werden. Vertreter dieses Kategorie sind NASA-MATB (Multi-Attribute Test Battery) und CAMS (Cabin Air Management System) (Wandke und Bothe, 2009). 1

11 1. Einleitung 1.1. Motivation Wandke und Bothe stellen fest, dass insbesondere die durch Informatik-Fremde erstellten ad hoc Softwaresysteme in diesem Kontext Probleme darstellen, da sie oft den Anforderungen der Nutzung innerhalb von ingenieurspsychologischen Experimenten hinsichtlich von Sicherheit, Effizienz, Wartbarkeit und Erweiterbarkeit nicht genügen (Wandke und Bothe, 2009) Projekt ArbeitsTeilung Entwickler-Operateur Am 1. Oktober 2004 wurde das interdisziplinäre Graduiertenkolleg prometei iniziiert, welches sich mit der Mensch-Technik-Interaktion beschäftigt. Im Zuge des Kollegs werden Methoden, Verfahren sowie Werkzeuge entwickelt und integriert, welche die Mensch-Technik-Interaktion bereits in einer frühen Phase der Entwicklung von Systemen berücksichtigt (Prometei, 2011). Das Projekt ArbeitsTeilung Entwickler-Operateur (ATEO) ging aus der Arbeit des Graduiertenkollegs hervor und befasst sich mit der asynchronen Arbeitsteilung zwischen Entwicklern auf der einen Seite und Operateuren auf der anderen Seite. Diese beiden Gruppen unterscheiden sich wie folgt: Während die Entwickler für die Systemplanung, Entwicklung und Implementation zuständig sind, sollen die Operateure das System im späteren Verlauf nutzen (Nachtwei et al., 2011). Die Abbildung zeigt diesen Zusammenhang. Abbildung Arbeitsteilung zwischen Operateur und Entwickler (Nachtwei et al., 2011) 2

12 1. Einleitung 1.1. Motivation SAM Das Kernstück von ATEO bildet die Socially Augmented Microworld (SAM). In dieser Mikrowelt steuern zwei Mikroweltbewohner (MWB) kooperativ ein Trackingobjekt über eine Strecke (siehe Abbildung ). Dabei haben die beiden Mikroweltbewohner widersprüchliche Aufgaben zu erfüllen. Einem Bewohner wird die Aufgabe gestellt, das Trackingobjekt möglichst schnell über die Strecke zu manövrieren, dem Anderen, es möglichst genau zu steuern. Das Tracking wird dabei von einem Operateur oder einer Automatik überwacht (Nachtwei et al., 2011). Hierbei liegt das Hauptaugenmerk auf der Erzeugung von Daten, die zu einem bestimmten Grad unvorhersagbar, jedoch im nachhinein erklärbar sind. Die unvorhersagbare Komponente entsteht durch die Beteiligung von Versuchspersonen. Abbildung Darstellung der Strecke in SAMs mit grünem Trackingobjekt (Nachtwei et al., 2011) SAM in ATEO Im Zuge des ATEO Projekts wurden 3 unterschiedliche Softwarepakete entwickelt. Hierbei handelt es sich um die Socially Augmented Microworld in Smalltalk (SAMs), das ATEO Master Display (AMD) und ATEO Automation Framework (AAF). Mit Hilfe von SAMs wird die Tracking Simulation durchgeführt sowie die entsprechenden Daten für das AMD und AAF bereitgestellt. Mit Hilfe des AMD kann der Operateur Eingriffe durchführen und das Tracking überwachen. Eingriffe von Seiten der Automatiken werden durch das AAF bedient. Letztere werden in zwei Kategorien eingeteilt.zum einen seien die weichen Eingriffe genannt, welche sich auf audiovisuelle Hinweise beschränken. Die andere Kategorie bilden die harten Eingriffe, die durch limitierende Eingriffe des Fahrverhaltens charakterisiert sind, d.h. Eingriffe, die direkt das Fahrverhalten der Mikroweltbewohner beeinflussen, indem z.b. die maximale Geschwindigkeit herabgesetzt wird. Grundsätzlich verfügen beide Softwarepakete über den selben Umfang an Eingriffsmöglichkeiten. Der AMD stellt somit eine Schnittstelle dar, bei der 3

13 1. Einleitung 1.2. Zielstellung und Ergebnisse der Arbeit eine Person direkt in die Trackingsimulation eingreifen kann. Bei den Automatiken handelt es sich um Systeme, die von Entwicklern erdacht wurden und mögliche Situtationen abstrahieren müssen. Das gesamte System wird unter dem Begriff ATEO Lab System (ALS) zusammengefasst (Nachtwei, 2010). Alle genannten Softwarepakete wurden ursprünglich in Smalltalk unter Zuhilfenahme von Squeak implementiert. Bei Smalltalk handelt es sich um eine objektorientierte Programmiersprache SAMj Durch Hildebrandt wurden erhebliche Mängel in den Qualitätsmerkmalen von SAMs festgestellt. Dazu gehören mehrere Abhängigkeitszyklen und die Benutzung von globalen Variablen. Zusammen mit der ungenügenden Problemdekomposition hat dies einen negativen Einfluss auf die Nachnutzbarkeit, Verständlichkeit, Modifizierbarkeit und Testbarkeit von SAMs. Durch ein Reengineering der Architektur konnten diese Mängel beseitigt werden. Hildebrandt führte hier eine Schichtenarchitektur ein. Am Ende der Arbeit stand eine prototypische Umsetzung von Socially Augmented Microworld in Java (SAMj) (Hildebrandt, 2009). Ausgehend von dieser Arbeit und einem Architekturentwurf von (Hildebrandt, 2010) wurde in einer Studienarbeit eine Restrukturierung der Architektur von SAMj durchgeführt (Wagner, 2012). Ziel der Restrukturierung war eine Erhöhung der Kohäsion der Schichten und somit eine losere Kopplung zwischen den Schichten. Dazu wurde ebenfalls ein Object System eingeführt, welches auf der Beschreibung von (Doherty, 2003) basiert Zielstellung und Ergebnisse der Arbeit Im Projekt ATEO wurde deutlich, das mit Hilfe von ALS auch weitergehende ingenieurspsychologische Fragestellungen bearbeitet werden könnten. Um einen weitergehenden Einsatz von ALS durchzuführen, muss dieses durch Psychologen auf die jeweilige Fragestellung konfigurierbar sein. Die Zielstellung dieser Diplomarbeit ist die Entwicklung einer Methodik zur Migration eines Einzelproduktsystems zur Software Product Line (SPL) und einer Methodik zur Erweiterung einer SPL um zusätzliche Features. Diese Methoden sollen auf SAMj angewendet werden und zu einem konfigurierbaren Experimentalsystem führen. Hierbei wird eine Minimierung des Pro- 4

14 1. Einleitung 1.3. Aufbau der Arbeit grammieraufwandes bei der Konfiguration einbezogen. Im Zuge der Migration soll ebenfalls ein Variabilitätsmanagement eingeführt werden. Es konnten die folgenden Ergebnisse erzielt werden: Entwicklung einer Methode zur Migration von Einzelproduktsystemen: Aufbauend auf den Erkenntnissen und Techniken aus dem Software Product Line Engineering wurde eine allgemeine Methodik zur Migration von Einzelproduktsystemen zu SPLs entwickelt. Hierbei stand die Portierbarkeit der Methode auf andere Systeme im Vordergrund. Entwicklung einer Technik zur Erweiterung von SPLs: Es wurde eine strukturierte Vorgehensweise zur Integration von neuen Features in eine bestehende SPL vorgeschlagen. Erstellung eines Variabilitätsmanagements: Für das in dieser Arbeit entwickelte Softwaresystem wurde eine Technik zur Konfiguration entwickelt, die in dieser Arbeit Variabilitätsmanagement genannt wird. Diese ermöglicht mit sehr geringem programmieraufwand eine Anpassung des Systems an die geforderten Bedürfnisse. Migration und Erweiterung von SAMj: Im Zuge der Diplomarbeit wurde SAMj in eine SPL umgewandelt. Dabei wurden die im Vorfeld entwickelten Methoden angewendet. Das entstandene System erhielt den Namen Generic Laboratory Software (GenLabS). Der Funktionsumfang von GenLabS wurde im Vergleich zu SAMj erweitert Aufbau der Arbeit Der Aufbau dieser Diplomarbeit gliedert sich in folgende Abschnitte. Anschließend an die Einleitung wird in Kapitel 2. eine Einführung in die Software Product Lines gegeben, die als Grundlage für die weitere Arbeit dient. In Kapitel 3. wird der Lösungsansatz für die Entwicklung von konfigurierbaren Softwaresystemen vorgestellt. Es werden die Methoden zur Migration und Erweiterung vorgestellt. In den folgenden drei Kapiteln werden die Ergebnisse der Migration und Erweiterung von SAMj zu GenLabS erläutert, welche mit Hilfe der entwickelten Methoden durchgeführt wurden. Das Featuremodell in Kapitel 4. vorgestellt, wobei auf die Dokumentation der Features und auf das Modell von GenLabS eingegangen wird. Kapitel 5. stellt die Architektur von GenLabS dar. Im vorletzten Kapitel 6. werden die Entwurfskonzepte des Variabilitätsmanagements und der Konfiguration vorgstellt. Die Ergebnisse der Arbeit werden in 5

15 1. Einleitung 1.3. Aufbau der Arbeit Kapitel 7. zusammengefasst und mit einem Ausblick abgerundet. 6

16 2. Software Product Lines 2.1. Einführendes Besipiel 2. Software Product Lines Die entscheidende Neuerung von GenLabS gegenüber SAMj ist die Anzahl an möglichen Variationen die zur Verfügung gestellt werden sollen. Diese sollen durch Informatik-Fremde konfigurierbar sein. Es soll z.b. die Möglichkeit geben, die Protokollierung sowohl im CSV als auch im XML Format abzuspeichern. Um diese Anforderung zu erfüllen, wurde SAMj in eine Software Product Line umgewandelt. Das folgende Kapitel soll einen Überblick über dieses Fachgebiet eröffnen und zum Verständnis der Vorgehensweise innerhalb der Diplomarbeit dienen. In Abschnitt 2.1. und Abschnitt 2.2. werden die Software Product Lines anhand eines Beispiels eingeführt und erklärt. Im Abschnitt 2.3. wird auf das Product Line Development, d.h. die Entwicklung von Software Product Lines, eingegangen. Das Product Line Development dient als Grundlage für die in Kapitel 3. entwickelten Methoden. In Abschnitt 2.4. werden die Variabilitätsmodelle, Featuremodell und Orthogonales Variabilitätsmodell, vorgestellt, die zur Beschreibung von Software Product Lines benutzt werden. Abschließend wird in Abschnitt 2.5. ein Vergleich der beiden Variabilitätsmodelle aufgestellt. Das Featuremodell wird in Kapitel 4. zur Darstellung von GenLabS benutzt Einführendes Besipiel Für den Einstieg soll ein Beispiel aus der Welt der Möbelhersteller einen Eindruck von der Funktionsweise von Software Product Lines liefern. Ein bekanntes schwedisches Möbelhaus offeriert die Möglichkeit, sich den eigenen Schrank individuell zusammenzustellen. Dabei sollen zur Einfachheit folgende Wahlmöglichkeiten zur Verfügung gestellt werden. Der Kunde kann sich zwischen einer Anzahl von Schrankmodellen entscheiden. Schrankmodelle können sich in Form und Größe unterscheiden. Zu den Modellen können Türen ausgewählt werden. Es kann auch auf die Montage von Türen verzichtet werden. Als letzte Wahl bleibt dem Kunden die Entscheidung, welche Farbe der Schrank haben soll. Bereits unter der Annahme von nur 3 Möglichkeiten je Auswahlkriterium, ergeben sich 3 hoch 3 also 27 mögliche 7

17 2. Software Product Lines 2.2. Überblick Kombinationen, d.h. man erhält 27 unterschiedliche Produkte Überblick Dieses Beispiel einer Product Line, aus der realen Welt, lässt bereits einige Vorteile erkennen, die sich aus der Nutzung von Software Product Lines ergeben. Zu diesen Vorteilen gehört, die Kostensenkung, die sich durch den Einsatz von Software Product Lines erreichen lässt (Pohl et al., 2005). Dabei ergibt sich die Kostensenkung - gemäß des Konzeptes der Software Product Line - erst nach der Entwicklung mehrerer Produkte. In Abbildung wird dieser Effekt graphisch dargestellt. Es zeigt sich, daß der anfängliche Aufwand für SPLs deutlich höher ist, als bei herkömmlichen Entwicklungsmethoden, was der größeren Sorgfalt bei der Planung geschuldet ist. Dieser Effekt gleicht sich im Durchschnitt bereits bei der Entwicklung des zweiten Produktes aus. Spätestens beim dritten Produkt ist ein deutlicher Kostenvorteil, bei Nutzung von SPLs gegenüber anderen Entwicklungstechniken, zu erwarten. Abbildung Kumulative Kosten je Produkt bei Nutzung von SPLs und bei der Nutzung von herkömmlichen Verfahren (Northrop, 2009) Des Weiteren ergeben sich Vorteile im Bereich der Qualitätssicherung. Die Artefakte werden in vielen Produkten getestet und bewertet. Sie müssen ihre Funktionsfähigkeit in verschiedenen Anwendungsszenarien unter Beweis stellen. Aufgrund dieser Tatsachen kann eine deutlich höhere Qualität gewährleistet werden, als dies bei vergleichbaren Einzelproduktentwicklungen möglich ist. 8

18 2. Software Product Lines 2.2. Überblick Ein weiterer Vorteil ergibt sich im Bereich des Zeitaufwandes, so ist der sogenannte time-tomarket Zeitraum, d.h. der Zeitraum von Beginn der Entwicklung bis zur Auslieferung des fertigen, einsatzfähigen Produkts, bei Software Product Lines deutlich niedriger als bei klassischen Entwicklungsmethoden. Dieser Effekt wird unter anderem durch die Wiederverwendung von Programmteilen erzielt. Dadurch entfällt ein erheblicher Teil der Entwicklungszeit, da z.b. Implementationsarbeiten auf ein Minimum reduziert oder ganz eliminiert werden können. Clements definiert Software Product Lines (SPL) wie folgt: A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets[ 1 ] in a prescribed way (Clements, 2007). Die Definition soll nun auf unser Beispiel des Möbelhauses übertragen werden. Die Menge der Software-intensiven Systeme wird in unserem Beispiel durch die Menge der möglichen Schränke repräsentiert, d.h. durch die Menge an Kombinationen aus Schrankmodellen, Türen und Farben. Die Features werden durch diese drei Kategorien gebildet. Es ist sofort sichtbar, dass alle Schränke diese Features miteinander teilen. Jeder Schrank besitzt einen Rahmen, welcher durch das Schrankmodell gebildet wird, und eine Farbe. Außerdem besitzt jeder Schrank eine Tür oder keine. Dies sind die geteilten Gemeinsamkeiten aller Produkte der Software Product Line. Sie alle bedienen eindeutig einen Markt bzw. haben eine Aufgabe. Alle Schränke, egal in welcher Ausprägung, sind zur Aufbewahrung von Gegenständen vorgesehen. Dabei spielt es keine Rolle, ob dies Kleidungsstücke oder Töpfe sind. Um die in der Definition genannten Core Assets besser zu verstehen, soll ein Feature unseres Beispiels näher betrachtet werden. Für die Schrankmodelle kann der Kunde zwischen mehreren vorgegebenen Modellen wählen. Es könnte ein Modell zur Auswahl stehen, welches in der Mitte unterteilt ist und in der Breite 2,50 Meter lang ist. Ein weiteres Modell könnte sich durch einen massiven Rahmen auszeichnen sowie ein drittes besonders hoch konstruiert sein. Jede dieser Ausprägungen stellt ein Core Assets dar. Der Kunde kann sich also aus bereits spezifizierten Modellen eines auswählen, hat jedoch nicht die Möglichkeit diese noch im Detail zu verändern. 1 Anm.: Bei Core Assets handelt es sich um die Bestandteile eines Produktes, z.b. Softwarekomponenten, die Software-Architektur etc.. Eine genaue Beschreibung findet sich in Abschnitt

19 2. Software Product Lines 2.3. Product Line Development Genauso ist die Anzahl an möglichen Assets endlich. Es kann nur eine bestimmte, begrenzte Anzahl an Ausprägungen eines Features geben. Als letztes soll der vorgeschriebene Weg beschrieben werden. Für die Erstellung des Schrankes ist es wichtig, dass ein vorgeschriebener Weg eingehalten wird. Zuerst wählt der Kunde ein Modell. Diese Entscheidung könnte bereits Einfluss auf die mögliche Auswahl an Türen haben, weil z.b. die ein oder andere Tür von den Maßen nicht zum Modell passt. Es macht also nur begrenzt Sinn, zuerst eine Tür zu wählen und dann ein Modell. Zum Schluss wird die Farbe gewählt. Es ist denkbar das der Möbelhersteller aus unserem Beispiel diesen Weg so und nur so dem Kunden vorgibt Product Line Development Das Product Development besteht nach Clements aus drei grundlegenden Aktivitäten, dem Core Asset Development, dem Product Developement und dem Management. Wie Abbildung zu sehen handelt es sich dabei um iterative Prozesse, die jeweils eng miteinander verknüpft sind. Alle drei Aktivitäten haben bestimmte Inputs und liefern nach einem Prozess Outputs, welche in den folgenden Abschnitten näher erläutert werden. Wie in der Abbildung zu sehen werden die Aktivitäten in die Bereiche Domain- und Application Engineering eingeordnet (Clements, 2007). Pohl definiert das Domain Engineering als den Entwicklungsprozess innerhalb von Software Product Lines bei dem Gemeinsamkeiten und Unterschiede definiert und realisiert werden. Das Application Engineering stellt nach Pohl den Entwicklungsprozess der einzelnen Produkte einer Software Product Line dar, bei dem die einzelnen Artefakte der Software Product Line zusammengebaut werden (Pohl et al., 2005) Core Asset Development Das Ziel des Core Asset Development ist die Festlegung des Funktionsumfangs der Software Product Line, d.h. an dieser Stelle wird die grundlegende Entscheidung über die späteren Produkte gefällt. Um dieses Ziel zu erreichen, dienen die bestimmte Inputs als Grundlage, welche im folgenden kurz beschrieben werden. 10

20 2. Software Product Lines 2.3. Product Line Development Abbildung Grundlegende Aktivitäten in der Product Line Entwicklung (Clements, 2007) 11

21 2. Software Product Lines 2.3. Product Line Development Production Contraints Die Product Contraints definieren die Gemeinsamkeiten und Variationen der einzelnen Produkte die innerhalb der Product Line entwickelt werden sollen. Hier sollen auch die Überlegungen zu den möglichen Features, die durch den Markt oder die Aufgaben gefordert werden könnten, einfliessen. Zu diesem Input gehört ebenso der durch die Zielgruppe, den Markt, vorgegebene Standards, die Qualitätsanforderungen der Produkte, Sicherheitsfragen und nicht zuletzt die mögliche Interaktion mit anderen externen Anwendungen. Styles, Pattern, Framework Unter den Inputs Styles, Pattern und Framework subsumieren sich alle Lösungen, die aus früheren Projekten übernommen werden können, aber auch die bekannten sogenannten Design Pattern und alle zur Verfügung stehenden Frameworks. Production Constraints Unter die Production Constraints fallen alle kommerziellen, firmenspezifischen und eventuell militärischen Standards, die bei der Produktion, d.h. bei der Entwicklung der Software Product Line und den einzelnen Produkten, eingehalten werden müssen. Hinzu kommen eventuelle Einschränkungen bezüglich des Zielsystems auf das implementiert werden soll. Es sind auch time-to-market Zeiträume einzuhalten. Die Zielgruppe könnte ebenso die Nutzung von components-off-the-shelf (COTS) erfordern. Production Strategy Die Production Strategy beschreibt die globale Strategie, die mit der Software Product Line erzielt werden soll. Dazu gehört die Festlegung, ob die Software Product Line mit einigen Core Assets startet und daraus eine Reihe von Produkten entwickelt wird oder ob aus einer Reihe von bestehenden Produkten Gemeinsamkeiten und Variationen abstrahiert und Assets gebildet werden sollen. Hier wird auch die Frage der Preisgestaltung entschieden. Werden die Kosten für die Software Product Line, die für die ersten Produkte noch sehr hoch sind, gleichmäßig auf die geplanten Produkte verteilt oder gibt es eine Preisgewichtung? Werden die einzelnen generischen Komponenten vermarktet oder nur intern in den Produkten verwertet? Wie werden die einzelnen Produkte erzeugt? Inventory Of Preexisting Assets Beim letzten Input handelt es sich um Komponenten, Bibliotheken, Frameworks usw. die bereits im Einsatz sind. Diese eignen sich besonders für die Core Asset Basis, da hier bereits ein großer Anteil an Domain Know-how eingeflossen ist. Es handelt sich beim Core Asset Development um eine iterative Tätigkeit, d.h. es wird schritt- 12

22 2. Software Product Lines 2.3. Product Line Development weise und mehrmals durchlaufen. Daraus ergibt sich, dass der Input durch den Output beeinflusst wird und vice versa. Dieser Zusammenhang wird in Abbildung deutlich. Nach einem Durchlauf sollten drei Dinge erstellt worden sein, ein Product Line Scope, Core Assets sowie ein Production Plan. Diese drei Outputs werden im Folgenden genauer betrachtet. Abbildung Core Asset Development (Clements, 2007) 13

23 2. Software Product Lines 2.3. Product Line Development Product Line Scope Hierbei handelt es sich um die Abgrenzung der Software Production Line. Das heißt, es wird die Menge der möglichen Produkte definiert, die sich aus der SPL ableiten lassen. Die simpelste Form ist eine Auflistung von möglichen Produktnamen. Im Allgemeinen wird man aber eine Beschreibung der Gemeinsamkeiten und Variabilitäten der Produkte erstellen. Für diesen Zweck wurden verschiedene Modelle entwickelt. Zu den meistgenutzten gehören das Featuremodell und das Orthogonale Variabilitätsmodell (OVM). Es ist essentiell für den weiteren Verlauf der Software Product Line, dass hierbei besondere Sorgfalt eingehalten wird. Sollte die Abgrenzung zu weit gewählt sein, unterscheiden die Produkte sich so stark, dass die Core Assets nicht mehr ausreichend alle Variabilitäten abdecken können. Ist die Abgrenzung hingegen zu schmal gewählt, kann die Software Product Line schnell an ihre Grenzen stoßen und zurückfallen auf eine Einzelproduktentwicklung. Core Assets Die Core Assets bilden die Basis für alle Produkte der Software Product Line. Inhalt ist die genutze Architektur, die Software Komponenten, aber auch Requirement Specifications und Domainmodelle. Besondere Aufmerksamkeit verdient hierbei die Architektur der SPL, denn sie muss nicht nur die Notwendigkeiten für die Variabilitäten, sondern auch der einzelnen Produkte berücksichtigen. Zur Entwicklung der Architektur ist es nötig, die Product Line Scope der SPL zu kennen. Nach (Clements, 2007) sollte jedem Core Asset ein Prozess angeheftet werden (attached process). Wie in Abbildung zu sehen spezifiziert dieser, wie der Core Asset in der späteren Produktentwicklung eingesetzt werden soll. Production Plan Der Production Plan stellt Informationen zur Verfügung, die gebraucht werden, um aus den Core Assets das fertige Produkt zu konstruieren. Hierbei dienen die Attached Processes als Grundlage. Im Wesentlichen besteht der Production Plan aus einer Zusammenstellung von Attached Processes. Letztere werden um Zusatzinformationen angereichert. Es wird im Production Plan also definiert, wie aus den verschiedenen Core Asstes ein ausführbares Produkt zusammengestellt werden kann, d.h. es wird definiert, wie einzelne Variationen erzeugt werden. Dafür stehen mehrere Möglichkeiten zur Verfügung, unter anderem der Aus- 14

24 2. Software Product Lines 2.3. Product Line Development Abbildung Attached Processes (Clements, 2007) 15

25 2. Software Product Lines 2.4. Variabilitätsmodelle tausch von Dateien oder Komponenten aber auch die Parametrizierung. Hierbei sind nicht nur automatisierte Methoden einsetzbar, auch das manuelle Zusammenstellen von Komponenten wäre eine denkbare Möglichkeit Product Development Im Gegensatz zum Core Asset Development, welcher sich mit der Entwicklung von Software Product Line beschäftigt, liegt das Hauptaugenmerk bei der Product Development im Erzeugen von konkreten, ausführbaren Produkten. Im Product Development werden aus den Requirements, dem Product Line Scope, den Core Assets und dem Production Plan die Produkte erzeugt. Dieser Prozess wird anschaulich in Abbildung gezeigt. Hierbei gibt es wie im Core Asset Development Rückkopplungen zwischen Input und Output. So können beim Erzeugen der fertigen Applikationen Fehler sichtbar werden, die in der Core Asset Development nicht abstrahiert werden konnten oder es zeigen sich mögliche Verbesserungen im Einsatz, die dann im Core Asset Development in die Software Product Line übernommen werden Management Um eine Software Product Line erfolgreich umzusetzen spielt das Management eine besondere Rolle. Es wird unterschieden zwischen organisatorischem und technischem Management. (Clements, 2007) definiert das technische Management als die Tätigkeit, die dafür zuständig ist, das Core Asset Development und das Procuct Development zu überwachen und die Koordination zwischen beiden zu organisieren. Das organisatorische Management ist hingegen mit der Bereitstellung von Ressourcen befasst und ist auf wirtschaftlicher Ebene angesiedelt Variabilitätsmodelle Anforderungen an ein Variabilitätsmodell Die nachfolgenden Modelle zur Darstellung von Variabilität, Featuremodell und Orthogonales Variabilitätsmodell dienen zur Modellierung. Um eine bessere Bewertung dieser Modelle 16

26 2. Software Product Lines 2.4. Variabilitätsmodelle Abbildung Product Development (Clements, 2007) 17

27 2. Software Product Lines 2.4. Variabilitätsmodelle vornehmen zu können, muss also zunächst geklärt werden, was eine gute Dokumentation von Variabilität beinhalten soll. Pohl stellt fest, dass ein gutes Modell von Variabilität folgende Anforderungen erfüllt (Pohl et al., 2005). Variationsdefinition Es muss wohl definiert sein, welche Variationen möglich sind. Dies soll durch das Modell geschehen. Dabei ist es wichtig dass keine implizierten Variationen auftreten, da dies zu Verwirrungen führen kann, d.h. im späteren Verlauf soll nur das Variabel sein, was in dem Modell als solches gekennzeichnet ist. Variationsart Diese Anforderung bezieht sich auf die Unterscheidung von internen und externen Variabilitäten. Pohl unterscheidet zwei Arten von Variabilität, die externe Variabilität, welche durch externe Faktoren wie Kunden, gesetzliche Vorgaben, Standards usw. verursacht werden, und internen Variabilitäten, welche ihren Ursprung in externen Variabilitäten finden, aber auch technischer Herkunft sein können. Variantendefinition Hier gilt es genau zu beschreiben, welche Varianten es gibt. Adressat des Modells Pohl macht hier eine explizite Unterscheidung zwischen Kunden, die nur die externen Variabilitäten zur Kenntnissnahme bekommen und den Auszuführenden, die sowohl externe wie auch interne Variabilitäten nachvollziehen müssen. Des Weiteren kann es auch nötig sein, Unterscheidungen innerhalb der Firmenhierachie zu machen Vorteile eines guten Modells Nachdem nun einige Qualitätsmerkmale für ein gutes Modell zur Diskussion gestellt wurden, soll nun noch kurz auf die Vorteile eines solchen Variabilitätsmodells eingegangen werden. Diese werden ebenfalls durch Pohl, wie folgt charakterisiert. Entscheidungsfindung Eine gute Dokumentation, welche die Entwickler dazu anhält alle Variabilitäten, d.h. alle Variationspunkte und alle Varianten zu dokumentieren, hilft dem Kunden bei der Entscheidungsfindung, indem ihm alle Möglichkeiten klar aufgezeigt werden. 18

28 2. Software Product Lines 2.4. Variabilitätsmodelle Außerdem hilft eine solche Dokumentation auch den Entwicklern bei der Entscheidung, wie Variabilitäten technisch umgesetzt werden sollen und können. Kommunikation Eine expliziete Modellierung von Variabiliäten ermöglicht eine verbesserte Kommunikation, indem dem Kunden der Zugang zu der Software Product Line auf einem hohen Abstraktionsniveau gegeben wird. Dies erleichtert es dem Kunden, alle Optionen bei seiner Entscheidungsfindung zu berücksichtigen und gegebenfalls Änderungen besser zu kommunizieren. Nachvollziehbarkeit Die Verbindung und Nachvollziehbarkeit von Variabilitäten zwischen den Abstraktionsebenen wird durch eine explizite Dokumentation verbessert und in weiten Teilen erst ermöglicht. Dies ist unter anderem wichtig, um die Konsistenz zwischen Modell und Implementation zu gewährleisten. In den folgenden beiden Abschnitten sollen nun die beiden Modelle Featuremodell und Orthogonales Variabilitätsmodell kurz vorgestellt werden Orthogonales Variabilitätsmodell Das Orthogonale Variabilitätsmodell (OVM) wurde von Pohl entwickelt. Die nachfolgende Beschreibung des OVM sind aus (Pohl et al., 2005) entnommen. Es soll eingesetzt werden um die Variabilität auf einem hohen Abstraktionslevel darzustellen. Außerdem steht die Nachverfolgbarkeit zwischen den Abstraktionsebenen im Vordergrund. Pohl definiert das OVM als Model, welches die Varibilität einer SPL definiert. Variationspunkt Der Variationspunkt ist der Punkt im Modell an dem Variabilitäten in der Software Product Line eingeführt werden. Nur entlang dieser Punkte können die Produkte der Product Line variieren. Somit stellt der Variationspunkt ein zentrales Konzept des OVM dar. Die graphische Repräsentation innerhalb des Orthogonalen Variabilitätsmodelles gibt Abbildung wieder. Variante Die Variante stellt eine mögliche Ausgestaltung eines Variationspunktes dar. Einem Variationspunkt können somit n Varianten zugeordnet werden. Die graphische Darstellung fin- 19

29 2. Software Product Lines 2.4. Variabilitätsmodelle Abbildung Graphische Darstellung des Variationspunktes det sich in Abbildung Abbildung Graphische Darstellung der Variante Optionale und obligatorische Variabilität Es gibt zwei Arten von Variabilitäten. Die erste zeichnet sich dadurch aus, dass diese Variante ein Teil eines Produktes der Software Product Line sein könnte, dies allerdings nicht verpflichtend ist. Diese Variabilitäten werden optionale Variabilitäten genannt. Die zweite Möglichkeit einer Variabiliät ist die obligatorische Variabilität. Diese ist, wie der Name schon sagt, in jedem Produkt der SPL vertreten, d.h. eine der Varianten die dieser Variabilität zugeordnet ist, ist in jedem Produkt der Software Product Line vertreten. Abbildung Graphische Darstellung der Variability Dependencies 20

30 2. Software Product Lines 2.4. Variabilitätsmodelle Alternative Wahl Eine Gruppe von Varianten kann ein und demselben Variationspunkt zugeordnet sein. Mit Hilfe der alternativen Wahl kann nun bestimmt werden, wieviele Varianten innerhalb eines Produktes verwendet werden können. Dabei ist es möglich die Spanne anzugeben, innerhalb welcher die Anzahl der Varianten liegen muss. Es ist eine Spanne von 2 bis n möglich. Abbildung Graphische Darstellung der alternativen Wahl Varibilitätsabhängigkeiten Die Variabilitäten innerhalb einer Software Procut Line können sich gegenseitig beeinflussen. So kann es möglich sein, dass die Benutzung einer Variante eine andere Variante ausschließt. Wenn man sich an das Beispiel vom Anfang erinnert, so ist es denkbar, dass die Wahl eines zwei Meter hohen Schrankes die Benutzung von Türen, welche nur 1.50 m sind ausschließt. Andererseits kann eine Variante auch die Benutzung einer anderen Variante nötig machen. Die Auswahl der Türen wäre sinnlos, wenn ein Schrankmodell gewählt würde, an den diese nicht montiert werden können. An dieser Stelle ist es wichtig zwischen Abhängigkeiten zwischen Varianten, zwischen Variationspunkten und zwischen Varianten und Variationspunkten zu unterscheiden. Um bei unserem Beispiel zu bleiben. Wenn der Variationspunkt Farbe ausgewählt wird, so setzt das voraus, dass zumindest der Variationspunkt Modell ausgewählt wurde. Wenn hingegen die Variante Große Tür ausgewählt wurde, so kann dies die Variante Sideboard ausschliessen. Es gibt folgende Abhängigkeiten, die in Abbildung dargestellt werden: Variante benötigt Variante (requires_v_v): Eine Variante benötigt eine andere Variante um realisiert zu werden. Variante schliesst Variante aus (excludes_v_v): Eine Variante schliesst die Benutzung einer anderen Variante aus. Variante benötigt Variationspunkt (requires_v_vp): Die Benutzung einer Variante setzt einen Variationspunkt voraus. 21

31 2. Software Product Lines 2.4. Variabilitätsmodelle Variante schliesst Variationspunkt aus(excludes_v_vp): Die Benutzung einer Variante schliesst die Benutzung eines Variationspunktes aus. Variationspunkt benötigt Variationspunkt (requires_vp_vp): Ein Variationspunkt setzt einen anderen Variationspunkt voraus. Variationspunkt schliesst Variationspunkt aus (excludes_vp_vp): Die Berücksichtigung eines Variationspunktes schliesst die Benutzung eines anderen Variationspunktes aus. Abbildung Graphische Darstellung der Variabilitätsabhängigkeiten Beispiel Im Folgenden soll das Beispiel des schwedischen Möbelhauses mit Hilfe der im vorhergeheneden Abschnitt vorgestellten Orthogonalen Variabilitätsmodell aufgestellt werden. Dabei soll das Szenario wie folgt konkretisiert werden. Es werden drei Varianten von Schrankmodellen angeboten. Die Details der Schrankmodelle sind der Tabelle zu entnehmen. Des Weiteren soll es 3 verschiedene Türen geben. Die Maße sind der Tabelle zu entnehmen. Abschließend soll noch erwähnt werden, dass es drei gültige Farben geben soll schwarz, weiss und rot. Die Abbildung stellt das Beispiel als OVM dar. 22

32 2. Software Product Lines 2.4. Variabilitätsmodelle Abbildung Modellierung des Möbelhausbeispiels mit OVM 23

33 2. Software Product Lines 2.4. Variabilitätsmodelle Bezeichner Rahmen 1 Rahmen 2 Rahmen 3 Beschreibung Abmessung 2 m hoch, 2 m breit, 80 cm tief Abmessung 1,5 m hoch, 2 m breit, 80 cm tief Abmessung 2 m hoch, 1,50 m breit, 80 cm tief Tabelle Schrankmodelle Bezeichner Tür 1 Tür 2 Tür 3 Beschreibung Abmessung 2 m hoch, 1 m breit Abmessung 2 m hoch, 75 cm breit Abmessung 1.5 m hoch, 2 m breit Tabelle Türen Featuremodell Bei dem Featuremodell handelt es sich um ein Modell zur Darstellung von Gemeinsamkeiten und Variationen innerhalb einer Software Product Line. Die Beschreibung des Featuremodells wurde aus (Czarnecki, 1998) entnommen. Das Modell besteht aus Konzepten, Features und den Beziehungen zwischen und unter diesen. Zum Modell gehört das Feature Diagramm und optional eine Kurzbeschreibung der Freatures mit Randbedingungen, Prioritäten etc. Feature Bei einem Feature handelt es sich um eine Eigenschaft des Systems, wie sie sich dem Anwender darstellt. Nach dieser Definition sind alle Auswahlmöglichkeiten aus unserem Beispiel des schwedischen Möbelhauses jeweils ein Features des Gesamtsystems Schrank. Hier zeigt sich also das Feature im Sinne der im Orthogonalen Variabilitätsmodell verwendeten Begrifflichkeit, sowohl Variationspunkte als auch Varianten darstellen können. Konzept Ein Konzept wird beschrieben durch Features. Es gibt keine einheitliche Handhabung auf welcher Granularitätsebene diese Bezeichnung benutzt wird. So könnte sowohl ein Gesamtsystem, als auch z.b. eine Komponente als Konzept bezeichnet werden. Übertragen auf das Beispiel könnte also ein Konzept sowohl den gesamten Schrank als auch die Einzelkomponenten Schrankmodell und Tür bezeichnen. Feature Diagramm Bei dem Feature Diagramm handelt es sich um einen gerichteten Baumgraphen. Die Knoten sind die Konzepte und Features. Mit Hilfe der Kanten werden die verschie- 24

34 2. Software Product Lines 2.4. Variabilitätsmodelle denen Beziehungen zwischen den Knoten dargestellt. Es gibt 4 grundlegende Beziehungen die durch die Kanten dargestellt werden können obligatorische, optionale, alternative Features und Oder-Features (Czarnecki, 1998). Abbildung zeigt beispielhaft Featurediagramm mit drei Features. Abbildung Feature Diagramm mit drei Feature Obligatorische Feature Ein obligatorisches Feature ist immer dann im Konzept enthalten, wenn der Elternknoten Teil des Konzeptes ist. Diese Beziehung wird durch eine Kante mit einem ausgefüllten Punkt dargestellt (siehe Abbildung ). In unserem Beispiel sind die Features Schrankmodell und Farbe obligatorisch, denn ein Schrank braucht mindestens einen Rahmen und dieser hat auch eine Farbe. Abbildung Feature Diagramm mit fünf obligatorischen Feature Optionale Feature Ein optionales Feature kann im Konzept enthalten sein, wenn der Elternknoten in diesem enthalten ist. Dies bedeutet wenn der Elternknoten enthalten ist, kann das Features ebenfalls enthalten sein oder auch nicht. Dargestellt wird diese Beziehung durch eine Kante mit einem unausgefüllten Kreis (siehe Abbildung ) In unserem Beispiel könnte so 25

35 2. Software Product Lines 2.4. Variabilitätsmodelle ein optionales Feature die Tür sein, d.h. eine Tür könnte an den Schrank montiert werden, es gibt jedoch auch die Möglichkeit diese wegzulassen. In beiden Fällen würde ein Schrank, mit anderen Worten ein funktionierendes Produkt herauskommen. Abbildung Feature Diagramm mit vier optionalen Feature Alternative Feature Bei den alternativen Features handelt es sich um eine Entweder-Oder- Beziehung, d.h. genau eines der Feature einer Gruppe von alternativen Features ist im Konzept enthalten, wenn der Elternknoten enthalten ist. Dargestellt wird diese Beziehung wie in Abbildung gezeigt. Übertragen auf unser Beispiel wären die Varianten an verschiedenen Schrankmodellen eine Gruppe von alternativen Features, da jeweils nur genau ein Rahmen im Schrank verbaut werden kann. Abbildung Feature Diagramm mit vier alternativen Feature Oder-Feature Bei dem Oder-Feature handelt es sich, wie bei dem alternativen Feature, um eine Gruppe von Features, bei denen jedoch eines oder mehrere im Konzept enthalten sein können, wenn der Elternknoten enthalten ist. Es handelt sich dabei also um ein logisches Oder. Im Diagramm wird es wie in Abbildung benutzt. In unserem ursprünglichen Beispiel gibt es hierfür keine direkte Entsprechung. Jedoch kann man sich leicht vorstellen, dass es auch möglich sein könnte, Farben in beliebiger Anzahl zu verwenden. In diesem Falle wären alle Farbvarianten in einer Oder Beziehung zusammengefasst. 26

36 2. Software Product Lines 2.5. Vergleich zwischen Featuremodell und OVM Abbildung Feature Diagramm mit drei Oder-Feature Beispiel Abschließend soll auch das Featuremodell benutzt werden, um das Beispiel vom Anfang dieses Kapitels zu modellieren. Die Erklärungen zu den in Abbildung verwendeten Bezeichnern finden sich in den Tabelle und Tabelle Abbildung Modellierung des Möbelhausbeispiels mit Featuremodell 2.5. Vergleich zwischen Featuremodell und OVM In diesem Abschnitt soll ein Vergleich zwischen dem Featuremodell und dem Orthogonalen Variabilitätsmodell stattfinden. Dazu sollen zuerst die Vorteile und Nachteile der einzelnen Modelle aufgezeigt werden und abschließend soll die Wahl des Featuremodells für die weitere Arbeit begründet werden. Für das Orthogonale Variabilitätsmodell spricht zu aller erst die Tatsache, dass es speziell für die Nutzung innerhalb von Software Product Lines entwickelt wurde. So werden die rudimentären Anforderungen an die Modellierung innerhalb von Software Product Lines vom OVM erfüllt, d..h. Variabilität kann mit Hilfe von Variabilitätspunkten und Varianten gut dargestellt werden. Hinzu kommen die Möglichkeiten verpflichtende und fakultative Variabilitäten darzustellen. Besonders hervorzuheben ist, die im Modell verankerte Möglichkeit zwischen den Artefakten 27

37 2. Software Product Lines 2.5. Vergleich zwischen Featuremodell und OVM zu verlinken. Dies steigert die Nachvollziehbarkeit über die Abstraktionsebenen hinweg. Außerdem stellt das Orthogonale Variabilitätsmodell die Abhängigkeit von Varianten und Variationspunkten dar. Negativ fällt die Tatsache auf, dass das Modell noch nicht weit verbreitet ist. Insbesondere im kommerziellen Betrieb hat sich die Nutzung dieser Technologie bisher nicht durchgesetzt. Dies spiegelt sich in der Verfügbarkeit und Qualität von Tools zur Modellierung von OVM wieder. Das Featuremodell erfüllt ebenfalls alle rudimentären Anforderungen an die Modellierung von Variabilitäten innerhalb der Software Product Line. Hier besteht ein besonderer Vorteil dieses Modells darin, dass nicht nur Variabilitäten sondern auch Gemeinsamkeiten im Modell dargestellt werden. Bei dem Featuremodell handelt es sich um ein im kommerziellen Umfeld benutzten und etablierten Konzept. Es gibt eine Vielzahl an Tools, welche sich teilweise erheblich in Qualität und Kosten unterscheiden. Hervorzuheben ist, dass es ebenfalls gute kostenlose Tools gibt, wie das FeatureIDE, welches sich in die Eclipse IDE via Plug-In einfügen lässt und innerhalb dieser Arbeit zur Erzeugung der Featuremodelle genutzt wurde. Gegen den Einsatz von Featuremodellen spricht der erhöhte Aufwand um die Nachvollziehbarkeit innerhalb der Abstraktionsebenen darzustellen. Auch ist die Darstellung von Abhängigkeiten zwar grundsätzlich möglich, jedoch nicht so übersichtlich durchführbar, wie bei den Orthogonalen Variabilitätsmodellen. Für diese Arbeit wurde trotz der genannten Nachteile das Featuremodell benutzt, da es zum einen eine ganzheitlichere Darstellung der Software Product Line zulässt und zum anderen ein kostenlos einsetzbares Tool zur Verfügung stand. Des Weiteren war auch die weite Verbreitung des Featuremodells ausschlaggebend für die Nutzung innerhalb dieser Arbeit. Das OVM bietet demgegenüber keinen signifikanten Vorteil zum Featuremodell. 28

38 3. Ansatz 3.1. Übersicht 3. Ansatz In diesem Kapitel werden die entwickelten Methoden zur Migration und Erweiterung vorgstellt. Des Weiteren wird das Variabilitätsmanagement aus der theoretischen Sicht vorgestellt. Dies bildet den Einstieg in die folgenden drei Kapitel, welche die praktischen Ergebnisse der Umsetzung der Methoden darstellen Übersicht Ziel dieser Arbeit ist die Migration eines Altsystems (SAMs) von einem Einzelprodukt, zur Durchführung von ingenieurspsychologischen Experimenten, zu einer konfigurierbaren Versuchsumgebungssoftware mit dem Namen Generic Labratory Software (GenLabS). Diese Migration besteht aus insgesamt drei Schritten, die in Abbildung dargestellt werden. Die ersten Beiden sind nicht Teil dieser Diplomarbeit, sondern wurden in vorhergehenden Arbeiten durchgeführt. Abbildung Übersicht über die einzelnen Schritte vom Einzelproduktsystem SAMj zur Software Product Line GenLabS Im ersten Schritt wurde ein Reengineering der Architektur, unter besonderer Berücksichtigung von Techniken aus der objekt-orientierten Analyse und Design, vorgenommen. Dieses wurde durch Hildebrandt umgesetzt und mündete in einer prototypischen Umsetzung von SAM in 29

39 3. Ansatz 3.1. Übersicht Java (SAMj 1.0) (Hildebrandt, 2009). Auf Basis dieser Ergebnisse erfolgte der zweite Schritt, eine Restrukturierung der Architektur, aufbauend auf den Erkenntnissen der Spieleentwicklung, welche bei Doherty nachzulesen sind (Doherty, 2003) und einem Architekturentwurf von Hildebrandt (Hildebrandt, 2010). Innerhalb dieser Arbeit wurden außerdem ein Object System und eine neue Grafik Engine entworfen und implementiert (Wagner, 2012). Im Abschnitt 3.2. werden diese Vorarbeiten genauer dargestellt. Der dritte Schritt wurde innerhalb dieser Arbeit realisiert und besteht aus drei Teilschritten die in Abbildung zu sehen sind. Im ersten Teilschritt wurden, ausgehend von den Techniken und Methoden des Software Product Line Engineerings (siehe Kapitel 2.), Methoden erdacht, die zur systematischen Migration von Einzelproduktsystemen in Software Product Lines (siehe Abschnitt 3.3.) und zur Erweiterung von bestehenden SPLs um weitere Features (siehe Abschnitt 3.4.) eingesetzt werden können. Im zweiten Teilschritt wurde ein Variabilitätsmanagement eingeführt, d.h. eine strukturierte Darstellung von Variabilität auf Modellebene und eine technische Umsetzung von Variabilität auf Implementationsebene. Die Ergebnisse der ersten beiden Teilschritte wurden im dritten Teilschritt auf das Einzelproduktsystem SAMj 2.0 angewendet. Ergebnis dieses letzten Teilschrittes ist die Software Product Line GenLabS, die in den nächsten drei Kapiteln vorgestellt wird. Abbildung Übersicht der Schritte dieser Arbeit 30

40 3. Ansatz 3.3. Methode zur Migration eines Einzelproduktsystems zur SPL 3.2. Vorarbeiten Dem in dieser Arbeit durchgeführten Schritt gingen zwei Schritte voraus. Der erste von Hildebrandt durchgeführte Schritt beinhaltete ein Reengineering von SAMs und eine prototypische Umsetzung in Java, SAMj 1.0. (Hildebrandt, 2009). Ziel dieser Arbeit war die Beseitigung von Mängeln in den Qualitätsmerkmalen von SAMs. Im Einzelnen umfassten diese zahlreiche Abhängigkeitszyklen, die Benutzung zahlreicher globaler Variablen und eine ungenügende Problemdekomposition [bezüglich der] Verständlichkeit, Modifizierbarkeit, Testbarkeit und Nachnutzbarkeit von SAMs (Hildebrandt, 2009, Seite 5). Im Ergebnis wurde eine Schichtenarchitektur eingeführt, die in Abbildung dargestellt ist. Der zweite Schritt bestand in einer Restrukturierung der Architektur von SAMj 1.0 auf Grundlage eines Architekturvorschlages von Hildebrandt (Hildebrandt, 2010) und unter Berücksichtigung der von Doherty vorgeschlagenen Spielearchitektur (Doherty, 2003). Hierbei wurde insbesondere ein Object System entwickelt und implementiert, das zur zentralen Haltung von Simulationsobjekten dient. Zudem wurde eine Grafik Engine auf Basis von OpenGL entworfen und implementiert (Wagner, 2012). Die Architektur von SAMj 2.0 ist in Abbildung veranschaulicht Methode zur Migration eines Einzelproduktsystems zur SPL Die in diesem Abschnitt vorgestellte Methode ist ein Vorschlag zur systematischen Migration von Einzelproduktssytemen zu Software Product Line. Es fußt auf den Erfahrungen, die bei der Migration der Simulationssoftware SAMs in die konfigurierbare Versuchsumgebungssoftware GenLabS gesammelt wurden. Ziel dieser Methode ist die Erstellung einer SPL, welche über die gleiche Funktionalität verfügt wie das Einzelprodukt, von dem es abgeleitet ist. Um dieses Ziel zu erreichen, müssen folgende Artefakte erzeugt werden: Ein Featuremodell, sowie eine Software-Architektur, Core Assets und entsprechende Tests. Wie in Abbildung zu sehen, unterteilt sich die Methode in zwei iterative Prozesse. Im ersten Prozess steht die Analyse des vorhandenen Einzelproduktsystems im Vordergrund. Ziel des Prozesses ist ein das gesamte System beschreibendes Featuremodell. Der zweite interative Prozess baut auf dem ersten auf und erzeugt die Core Assets, d.h. eine Architektur, die Core 31

41 3. Ansatz 3.3. Methode zur Migration eines Einzelproduktsystems zur SPL Abbildung Architektur von SAMj

42 3. Ansatz 3.3. Methode zur Migration eines Einzelproduktsystems zur SPL Abbildung Architektur von SAMj

43 3. Ansatz 3.3. Methode zur Migration eines Einzelproduktsystems zur SPL Assets und die dazugehörigen Tests. Abbildung Vom Einzelprodukt zur Software Product Line Featureanalyse Die Featureanalyse setzt sich aus drei Teilprozessen zusammen, erstens dem Identifizieren von Features, zweitens dem Dokumentieren von Anforderungen und drittens dem Review der vorangegangenen Ergebnisse. Als Input erhält dieser Prozess das Einzelproduktsystem in Form der Dokumentation und dem Quellcode. Am Ende steht ein Featuremodell des Einzelproduktsystems. Feature identifizieren Die Identifikation der Features kann in zwei Richtungen erfolgen. Zum einen kann von der höchsten Abstraktionsebene zur niedrigsten Abstraktionsebene vorgegangen werden (Top-down Methode) oder genau anders herum (Bottom-up Methode). Dies 34

44 3. Ansatz 3.3. Methode zur Migration eines Einzelproduktsystems zur SPL hängt von der Qualität der durch das Einzelproduktsystem gestellten Dokumentation ab. Bei der Top-down Methode spielt die Dokumentation der Einzelproduktsoftware eine entscheidende Rolle, da sie den Ausgangspunkt für die Analyse bildet. Dementsprechend eignet sich diese Methode nur bei gut dokumentierten Softwaresystemen. Bei weniger guter Qualität der Dokumentation empfiehlt sich der Einsatz der Bottom-up Methode. In beiden Fällen werden vom jeweiligen Ausgangspunkt die Abstraktionsebenen durchlaufen, um eine vollständige Analyse des Systems durchzuführen. Für die Top-down Methode bedeutet dies beispielsweise in einem ersten Schritt ein Featurediagram anhand des Pflichtenheftes zu erstellen, um dann in einem zweiten Schritt das Verhalten des Systems zu analysieren und anhand dessen, das Featurediagram zu verfeinern und in einem letzten Schritt den Quellcode zur Analyse heranzuziehen. Anforderungsdokumentation Bei der Erstellung des Featuremodells anhand eines Featurediagrammes kann es nützlich sein, zusätzlich zum Diagramm weitere Informationen zu den Features zu erfassen. Dies geschieht in diesem Teilprozess. Die Dokumentation kann anhand einer in dieser Arbeit entworfenen Featuredokumentation erfolgen. Hierbei werden Randbedingungen erfasst, woraufhin eine Verlinkung zwischen Featuremodell und Implementation erfolgt. Die genaue Umsetzung wird in Abschnitt 4.1. vorgestellt. Review In diesem Teilprozess geht es um die Bewertung des erstellten Featuremodells. Es ist zu analysieren, ob das entwickelte Featuremodell das Einzelproduktsystem umfänglich darstellt. Dieser Review dient als Entscheidungshilfe für oder gegen einen weiteren Durchlauf des gesamten Prozesses Featureanalyse Core Asset Development Dieser Prozess besteht aus den vier Teilprozessen. Dem Entwurf der Architektur schliesst sich das Refactoring bzw. die Neuimplementation an, worauf die Testerstellung und Durchführung folgt. Das Erstellen von Reviews der Ergebnisse bildet den letzten Teil. Der Prozess baut auf den Ergebnissen der Featureanalyse, d.h. dem Featuremodell, und der Implementation des Einzelproduktsystems auf. Am Ende dieses Prozesses steht eine Software Produkt Line, die über die Funktionalität des Ausgangssystems verfügt und nun die Möglichkeit bietet, weitere Features einzufügen. 35

45 3. Ansatz 3.4. Erzeugung eines Features Architekturentwurf Beim Entwurf der Architektur ist insbesondere auf die Einführung eines Variabilitätsmanagements zu achten (siehe Abschnitt 3.5.). Des Weiteren ist es von besonderer Bedeutung auf eine hohe Kohäsion und eine damit einhergehende geringe Kopplung der einzelnen Core Assets zu achten, um das Variabilitätsmanagement, d.h. insbesondere die Austauschbarkeit der einzelnen Core Assets zu erleichtern. Refactoring und Neuimplementation Bei der Erstellung der Core Assets ist es sinnvoll, vorzugsweise auf die Algorithmen und Klassen der Einzelproduktsoftware zurückzugreifen. Dies begründet sich darin das sich diese im Einsatz bewährt und somit ihre Qualität bewiesen haben und in der Tatsache das sie Know-how beinhalten, welches ansonsten erst neu geschaffen werden müsste. Tests Bei der Erstellung der Tests der einzelnen Core Assets ist, primär auf die Tests des Einzelproduktsystems zurückzugreifen. Dies ist insbesondere bei Unittests besonders praktikabel. Bei Integrationstests ist auf die Besonderheiten von Software Product Lines zu achten insbesondere betrifft dies die Abhängigkeiten der Features bzw. auftretende Seiteneffekte. Review Wie bereits im vorigen Prozess steht auch am Ende dieses Prozesses ein Review der in dem jeweiligen Durchlauf erzielten Ergebnisse. Dieser dient der Kontrolle und der Entscheidung für oder gegen einen weiteren Durchlauf, hat aber auch einen dokumentierenden Charakter und kann zur Rückverfolgung von Teilergebnissen herangezogen werden Erzeugung eines Features Nachdem im vorigen Abschnitt eine Software Product Line entwickelt wurde die keine Variabilität besitzt, soll in diesem Abschnitt nun eine Methode zur Erzeugung und Integration von neuen Features in die Software Product Line vorgstellt werden. Die Methode stellt eine konkrete Ausgestaltung des in Abschnitt vorgestellten Core Asset Developments dar. Es besteht aus sechs Prozessen, die solange durchlaufen werden können, bis keine neuen Features mehr dazu kommen. Die Reihenfolge der Prozesse ist Requirement Engineering, Anpassung des Featuremodelles und ggf. der zugehörigen Dokumentation, Implementation und Test des neuen Features, Integration in das Variabilitätsmanagement und schließlich 36

46 3. Ansatz 3.4. Erzeugung eines Features ein Review der Ergebnisse eines Durchlaufs. Eine grafische Darstellung zum besseren Verständnis findet sich in Abbildung Abbildung Vorgehensweise beim erzeugen und einfügen eines neuen Features Am Ende des Durchlaufes der einzelnen Prozesse stehen ein modifizierter Production Line Scope, die Core Assts und ein neuer Production Plan. Requirement Engineering Ziel dieses Prozesses ist die Entwicklung neuer Features. Dabei sind auch Randbedingungen, Abhängigkeiten und Art des Features zu klären, d.h. es ist zu erfassen, ob es sich um ein obligatorisches, optionales, alternatives oder Oder-Feature handelt. (siehe Abschnitt ). Die Dokumentation kann in verbaler Form durchgeführt und durch Use-Case-Diagrammen ergänzt werden. 37

47 3. Ansatz 3.5. Variabilitätsmanagement Anpassung des Featuremodells Die im vorhergehenden Prozess entwickelten Features sollen in diesem Schritt in das bestehende Featuremodell eingefügt werden. Dabei sind die beschriebenden Abhängigkeiten und Art der Features zu berücksichtigen. Implementation Die Features werden in diesem Prozess implementiert. Dabei sind Techniken der Objekt-orientierten Designs zu beachten und der Einsatz von Design Patterns zu empfehlen. Tests Es sind Unit- und Integrationstests zu entwickeln. Besondere Bedeutung bekommen dabei die Integrationstests, welche auch Koabhängigkeiten zwischen den Features beachten müssen. Integration in Variabilitätsmanagement Um das Feature in der SPL verfügbar zu machen, muss das Variabilitätsmanagement angepasst werden. Dabei wird die Art der Anpassung vom jeweiligen Variabilitätsmanagement bestimmt. Am Ende steht jedoch in jedem Falle ein neuer Production Plan. Einen Vorschlag wie ein Variabilitätsmanagement und eine Integration aussehen kann, wird in Abschnitt 3.5. erläutert. Review Den Abschluß des Prozesses bildet ein Review der Ergebnisse. Dabei ist zum einen zu prüfen, ob das Feature korrekt, d.h. den im ersten Schritt erfassten Anforderungen entsprechend, umgesetzt wurde und ob es eventuell noch Veränderungen geben muss Variabilitätsmanagement Einführung Im Folgenden wird eine mögliche Variante eines Variabilitätsmanagements vorgestellt werden. Unter einem Variabilitätsmanagement versteht man die Verwaltung von Features innerhalb einer Software Product Line. Diese kann sich über verschiedene Abstraktionsebenen erstrecken. So kann auch die Modellierung von Software Product Lines mit Hilfe von Featuremodellen als eine Art des Variabilitätsmanagements aufgefasst werden. In dieser Arbeit wird der Begriff im Sinne 38

48 3. Ansatz 3.5. Variabilitätsmanagement der Umsetzung auf Implementationsebene verwendet, unter Variabilitätsmangement wird also die Technik zur Konfiguration der Software Product Line verstanden. Dazu sollen zuerst die möglichen Variationsmechanismen nach van der Linden und Clements vorgestellt werden (Linden, 2007; Clements, 2007). An erster Stelle ist die Vererbung (inheritance) zu nennen. Dabei wird, wie der Name schon sagt, die Variation durch Subklassen, welche das Verhalten bzw. die Ausprägung der Elternklassen modifizieren, erzeugt. Ein zweiter Weg ist das Patching, bei dem die Variation durch verschiedene Patches erzeugt wird. Als nächste Möglichkeit besteht die Konfiguration zur Kompilierungszeit. Dabei manifestiert sich ein Produkt einer Software Product Line nach dem Kompilieren. Dies kann z.b. durch Preprocessoren oder Macros realisiert werden. Auch der Einsatz von Werkzeugen wie z.b. Ant ist hier möglich. Ein ähnliches Verfahren ist die Konfiguration während der Laufzeit. Dabei ist der Konfigurationsmechanismus in das Softwareprodukt integriert und eine Anpassung kann hier auch durch den Anwender stattfinden. Eine mögliche Umsetzung wäre die Nutzung von Konfigurationsdateien. Eine weitere Möglichkeit ist die Parametrisierung, die Code Generierung und der Austausch von Komponenten. Ein beliebter Weg innerhalb der Rich-Client-Entwicklung ist die Nutzung von Plug-ins die mit Hilfe von Extensionpoints zu Produkten kombiniert werden können Umsetzung Bei dem bei GenLabs verwendeten Variabilitätsmanagement stand die Anpassbarkeit durch den Nutzer im Vordergrund. Dabei sollte es ist insbesondere möglich sein GenLabS mit geringem Programmieraufwand zu konfigurieren. Um dieses Ziel zu erreichen wurden die Variationsmechanismen Vererbungen, Parametrisierung und Konfiguration zur Laufzeit verwendet, die im Folgenden vorgestellt werden. Mit Hilfe dieser Technik konnte die in GenLabS geforderte Variabilität voll umfänglich erzielt und alle Anforderungen, insbesondere an die Einfachheit der Konfiguration erfüllt werden. Die Vererbung wird zur Bereitstellung von Varianten bzw. Varianzen benutzt. Hierbei werden die Variationspunkte (siehe Abschnitt ) durch die abstrakten Klassen und den Einsatz von Interfaces realisiert. Die einzelnen Varianten eines Variationspunktes werden durch die konkrete Klasse bzw. die Implementierung des Interfaces dargestellt (siehe Abbildung ) An einigen Stellen, wie z.b. in der Grafik Engine, kommt das Konzept der Parametrisierung 39

49 3. Ansatz 3.5. Variabilitätsmanagement Abbildung Variabilitätsmechanismus: Vererbung von Methoden und Klassenkonstruktoren zum Einsatz. Hierbei wird die Variabilität dadurch hergestellt, dass über die Parameter die zu verwendenden Features definiert werden. Am Beipiel der Grafik Engine wird dies durch die Verwendung z.b. des allgemeinen Interfaces für Trackingobjekte deutlich. Um die Varianten innerhalb der Software Product Line nutzbar, d.h. auswählbar, zu machen, wurde hier auf die Möglichkeit der Konfiguration zur Laufzeit gesetzt. Die Konfiguration wird durch Konfigurationsdateien realisiert, in denen die zu verwendenden Varianten eingetragen werden. Diese Information wird dann während der Laufzeit vorgehalten und zur Konfiguration der Anwendung verwendet. Dieser Ansatz hat den Vorteil, dass eine Konfiguration mit nur geringem Programmieraufwand zu realisieren ist. Dabei ist eine übersichtliche Gestaltung der Konfigurationsdateien ein entscheidendes Qualitätsmerkmal. Die technische Umsetzung des Variabilitätsmanagements erfolgt in Kapitel 6.. Darüber hinaus wird damit die SPL flexibler gestaltet, als dies bei der Konfiguration bei Kompilierungszeit der Fall ist. 40

50 4. Featuremodell von GenLabS 4.1. Dokumentation 4. Featuremodell von GenLabS Im folgenden Kapitel soll das Featuremodell, welches in dieser Arbeit verwendet wurde, vorgestellt werden. Dazu wird im ersten Teil des Kapitels ein genauerer Blick auf die Art der Dokumentation geworfen. Es werden die verwendeten Werkzeuge und Dokumente beschrieben und deren Nutzung innerhalb der Arbeit erläutert. Im zweiten Teil soll die Entstehung des Featuremodells von GenLabS im Vordergrund stehen. Dabei werden die Schritte vom ersten Featuremodell, basierend auf der Dokumentation von SAMs, bis zum endgültigen Modell, welches aus der Anforderungsanalyse stammt, vorgstellt. Im letzten Teil wird das Modell von GenLabS näher angeschaut. Dazu werden die einzelnen Feature von GenLabS vorgestellt Dokumentation Das Featuremodell von GenLabS besteht aus zwei Teilen, wie in Abbildung zu sehen. Auf der einen Seite das Featurediagramm und auf der anderen Seite die Featuredokumentation. Das Featurediagramm wird, wie in Abschnitt dargestellt, verwendet, um die Variabilität innerhalb einer SPL zu modellieren. Dabei wird dies im Diagramm grafisch dargestellt. Zur Auswahl stehen die Typen obligatorisch, optional, alternativ und oder-varibilität. In GenLabS wurde zur Erstellung des Featurediagrammes das Software-Werkzeug FeatureIDE 1 verwendet. Dieses ist ein auf Eclipse 2 basierendes Plug-in. Durch den Einsatz innerhalb von Eclipse hat es den Vorteil, dass es auch mit weiteren Tools innerhalb von Eclipse verwendet werden kann, wie z.b. der Versionierung. FeatureIDE wurde als Open-Source-Werkzeug für den Einsatz im akademischen Umfeld an der Universität Marburg entwickelt und ist somit frei verfügbar. Es stellt das Featurediagramm grafisch und im XML Format dar. Die Konzepte des Featuremodelles (siehe Abschnitt ) werden komplett umgesetzt. Den zweiten Teil des Featuremodells bildet die Featuredokumentation. Sie dient zur Verknüp

51 4. Featuremodell von GenLabS 4.1. Dokumentation Abbildung Darstellung des Zusammenhangs zwischen Featurediagramm und Featuredokumention fung des Featuremodells, insbesondere des Featurediagramms, und den Core Assets, wie z.b. den einzelnen Klassen im Quellcode, und zur ausführlichen Dokumentation von Verhalten der Features, sowie Randbedingungen. Dabei werden folgende Informationen in einer Tabelle erfasst: Der Featurebezeichner dient zur Identifikation des Features innerhalb des Featurediagramms und wird hier erfasst, um eine Verlinkung zwischen Diagramm und Dokumentation herzustellen. Die Beschreibung dient zur kurzen Darstellung, um was es sich bei dem Feature handelt. Es sollte jedoch in jedem Fall auch auf einen beschreibenden Featurenamen geachtet werden. Die Abhängigkeiten zwischen einzelnen Features wird erfasst, da dies im Featurediagramm nicht ohne weiteres möglich ist. Hierbei können sowohl Voraussetzungen, d.h. benötigte Features, sowie Auschließungen, d.h. Features, welche nicht gleichzeitig eingesetzt werden können, erfasst werden. Die Klassen werden erfasst um eine Verlinkung zwischen Modell und Umsetzung herzustellen. Dabei können einem Feature eine oder mehrere Klassen zugeordnet sein. 42

52 4. Featuremodell von GenLabS 4.2. Genese des Featuremodells von GenLabS Unter Zusatzinformationen werden ggf. Randbedingungen oder Einschränkungen des Einsatzes erfasst. In Tabelle findet sich ein Beispiel der Featuredokumentation. Die ausführliche Featuredokumentation von GenLabS kann im Anhang A. in Tabelle A.1.1. nachgeschlagen werden. In Abschnitt 4.3. wird das Featuremodell von GenLabS genauer dargestellt. An dieser Stelle sei auf die in den Abschnitt 3.3. und Abschnitt 3.4. geforderte Aktualisierung bei Änderung hingewiesen. Diese umfasst das Featurediagramm und die Featuredokumentation. Feature Beschreibung Abhängigkeiten zugehörige Klassen Eingabegerät Konzept, welches keine ControlDevice die Eingabegeräte darstellt Keyboard Keyboard als benötigt KeyboardControl Eingabegerät Eingabegerät Joystick Joystick als benötigt JoystickControl Eingabegerät Eingabegerät Information Tabelle Featuredokumentation am Beispiel des Konzeptes Eingabegerät 4.2. Genese des Featuremodells von GenLabS Nachdem nun die Dokumentationsweise innerhalb dieser Arbeit vorgestellt wurde, soll in diesem Abschnitt die Genese des Featuremodells von GenLabS vorgestellt werden. Es wurden drei verschiedene Featuremodelle aufgestellt. Das erste Featuremodell basiert auf SAMs, das zweite wurde aus SAMj 2.0 abgeleitet und das dritte stellt den maximalen Umfang an Features dar, welche in Anforderungsanalysen entwickelt und gesammelt wurden. Für das erste Modell wurde der erste Prozess der in Abschnitt 3.3. vorgestellten Methodik zur Migration von Einzelproduktsystemen zu SPLs verwendet. Die vollständige Methodik der Migration kam beim zweiten Modell zum Einsatz und führte zur ersten SPL. Die in Abschnitt 3.4. vorgestellte Methodik zur Erweiterung einer SPL um zusätzliche Feature kam beim Modell drei zum Einsatz und mündete in einem umfangreichen Modell, dass jedoch nur in den Maßen umgesetzt, d.h. 43

53 4. Featuremodell von GenLabS 4.2. Genese des Featuremodells von GenLabS implementiert, wurde, wie dies in Abschnitt 4.3. beschrieben wird Featuremodell von SAMs Die Dokumentation von SAMs, namentlich der Software-Spezifikation (Bothe et al., 2010), war Ausgangspunkt für das erste Featuremodell. Die Featureanalyse wurde so lange durchlaufen bis die in der Dokumentation beschriebene Funktionalität subjektiv durch das Featuremodell abgebildet wurde. Das hierbei entwickelte Featurediagramm findet sich in Abbildung Die dabei identifizierten und modellierten Features orientierten sich dabei stark an den in der Spezifikation aufgestellten Anwendungsfällen. So sind die Features der obersten Ebene identisch mit den Anwendungsfällen wie sie im Use-Case Diagramm aufgestellt wurden. Trotz des Vorteils, dass der Anwender so die Features besser mit der Dokumentation vergleichen kann, stellte sich diese Granularität als zu grob heraus. Eine Verbindung zwischen dem Featuremodell und der Implementationsebene war zu unspezifisch, d.h. in der Dokumentation waren nicht nur einem Feature unterschiedliche Klassen zugeordnet, sondern auch einer Klasse konnten unter Umständen mehrere Features zugeordnet sein. Dies hätte unter anderem zu einem erhöhten Aufwand bei der Wartung und Erweiterung der Software bzw. des Modells geführt. Abbildung Featurediagramm von SAMs 44

54 4. Featuremodell von GenLabS 4.2. Genese des Featuremodells von GenLabS Featuremdodell von SAMj Aufgrund der Erkenntnisse aus der Entwicklung des Featuremodells von SAMs wurde im zweiten Schritt die dort getroffene Entscheidung über die Granularität revidiert. Bei dem Featuremodell von SAMj wurde das Pflichtenheft von SAMj (Wagner, 2011) und die prototypische Umsetzung als Grundlage verwendet. Die Featureanalyse endete auch in diesem Falle nachdem eine größtmögliche Übereinstimmung zwischen Funktionsumfang und Featuremodell bestand. Mit Hilfe der in Abschnitt 3.3. vorgestellten Top-Down Methode wurde ein Featuremodell erstellt, welches in Abbildung als Diagramm dargestellt ist. Dieses Modell besitzt eine feinere Granularität, indem es sich näher an der technischen Umsetzung orientiert. Dadurch wird eine verbesserte Verbindung zwischen Modell und System hergestellt und so das Modell aussagekräftiger, weil eindeutiger. Abbildung Featurediagramm von SAMj Vollständiges Featuremodell von GenLabS Das im vorigen Abschnitt entwickelte Featuremodell wurde als Grundlage zur weiteren Entwicklung genommen. Ziel war die Erweiterung von SAMj hin zu GenLabS. Dazu wurde die in Abschnitt 3.4. vorgestellte Methodik der Erweiterung von SPLs um Features benutzt. Ergebnis dieser Arbeit war das in Abbildung dargestellte Featurediagram. Es stellt die vollständige geforderte Funktionalität von GenLabS dar. Im Zuge dieser Arbeit wurde das Modell verkleinert und implementiert. Die Basis für die Implementation stellt das im folgenden Abschnitt vorgestellte Featuremodell dar. 45

55 4. Featuremodell von GenLabS 4.2. Genese des Featuremodells von GenLabS Abbildung Featurediagramm nach Anforderungsanalyse 46

56 4. Featuremodell von GenLabS 4.3. Featuremodell von GenLabS 4.3. Featuremodell von GenLabS Die in diesem Abschnitt vorgestellten Features wurden in der aktuellen Version von GenLabS umgesetzt. Einen Überblick über diese Features stellt das Featurediagramm in Abbildung dar. Die vollständige Featuredokumentation ist der Tabelle A.1.1. zu entnehmen. GenLabS setzt sich in der aktuellen Variante aus drei Konzepten zusammen, die im Folgenden näher betrachtet werden. Diese sind die Tracking Simulation und die Grafik Engine, welche beide obligatorisch sind, sowie dem Feature Protokollierung, welche optional ist. Abbildung Featurediagramm der aktuellen Version von GenLabS Konzept Protokollierung Mit diesem Konzept wird die Loggingfunktion von GenLabS umschrieben. Wie man dem Featuremodell entnehmen kann, handelt es sich bei diesem Feature um ein optionales Feature, d.h. GenLabS kann mit und ohne Logging betrieben werden. Sollte dieses Feature Bestandteil von GenLabS sein, so muss ein Format für die zu speichernden Daten gewählt werden. Es stehen alternativ die Formate CSV und XML zur Verfügung. Es ist also immer nur ein Format möglich Grafik Engine GenLabS hat in jedem Fall eine Grafik Engine, d.h. dieses Feature ist obligatorisch. Bei diesem Konzept handelt es sich um die grafische Präsentation der simulierten Inhalte. Somit stellt die Grafik Engine eine Schnittstelle zu den Probanden innerhalb des Experimentes dar. Das Konzept besteht aus der für die Umsetzung nötigen Bibliothek Slick, die hier als Feature eingefügt wurde und später mit anderen Bibliotheken als alternatives Features einsetzbar sein könnte, 47

57 4. Featuremodell von GenLabS 4.3. Featuremodell von GenLabS und der spezifizierten Auflösung, die ebenfalls obligatorisch ist. Es sind in der aktuellen Fassung zwei Auflösungen wählbar. Die alternative Wahl besteht zwischen Vollbildauflösung, im Featuremodell Fullscreen genannt, und einer 800x768 Pixel Auflösung. Ein Feature, welches zur grafischen Darstellung hinzugenommen werden kann, aber nicht obligatorisch ist, ist der Speed Indicator. Es handelt sich dabei um eine Geschwindigkeitsanzeige, d.h. um ein visuelles Feedback der Geschwindigkeit des Trackingobjektes, welches auf das Fahrobjekt projiziert werden kann. Das Konzept des Speed Indicators besteht aus einem Stil, d.h. der Art des verwendeten Geschwindigkeitsanzeigers, und einer Farbe. Es stehen drei unterschiedliche Stile zur Auswahl, die in Abbildung nebeneinander zu sehen sind. Der Stil FillingTachometer unterscheidet sich von den beiden anderen dadurch, dass sich das Trackingobjekt bei steigender Geschwindigkeit von unten nach oben, in der für den Speed Indicator gewählten Farbe, füllt. Bei Erreichen der maximalen Geschwindigkeit ist das Trackingobjekt komplett gefüllt, d.h. es hat die Farbe des Speed Indicators angenommen. Die beiden Stile Tachometer und TachometerConverse unterscheiden sich nur durch die Füllrichtung des Trackingobjektes, das ansonsten bei beiden kreisförmig geschieht. Beim Tachometer erfolgt die Füllung im Uhrzeigersinn und bei TachometerConverse entgegen dem Uhrzeiger. Alle Stile sind mit allen Formen des Trackingobjektes kompatibel. Abbildung Darstellung der Geschwindigkeitsanzeige von links TachometerConverse, FillingTachometer und Tachometer Tracking Simulation In diesem Konzept werden alle Features zusammengefasst, die direkt mit der Simulation zu tun haben. Es setzt sich aus den drei obligatorischen Features Bewegungsmodell, Eingabegerät und Simulationsobjekt zusammen. Wie bereits erwähnt handelt es sich bei diesem Feature um ein obligatorisches und außerdem um eines der zentralen Feature. Das Feature Eingabegerät stellt die Möglichkeiten die Zuführung von Informationen von außen 48

58 4. Featuremodell von GenLabS 4.3. Featuremodell von GenLabS in das System dar, d.h. es stellt eine Schnittstelle für Eingaben durch die Probanden dar. Es stehen aktuell zwei alternative Features zur Verfügung Keyboard und Joystick. Es ist im Moment noch nicht möglich beide Features gleichzeitig einzusetzen. Das Feature Bewegungsmodell abstrahiert die Funktionen zur Berechnung der Simulationswelt, d.h. unter anderem die Bewegung der Simulationsobjekte innerhalb der Simulationswelt. Hierunter fallen auch Interaktionen zwischen den Simulationsobjekten, wie sie z.b. bei Kollisionen auftreten. Ein Teilaspekt der Simulationswelt wird durch die Physik Engine dargestellt. Dieses Feature ist für die physikalische Berechnung von Simulationsobjekten und Simulationswelt zuständig. Dabei besteht dieses Konzept aus physikalischen Regeln, die durch optionale Feature repräsentiert werden. Im Moment ist nur ein Feature aus dieser Kategorie umgesetzt, jedoch sind weitere Features möglich. Diese würden dann zu Oder-Features. Das bereits umgesetzte Feature dieser Kategorie ist das Error Feedback. Bei diesem Feature wird das Verhalten des Trackingobjektes durch den befahrenen Untergrund beeinflusst. Das Trackingobjekt wird beim Verlassen der Fahrbahn sukzessive abgebremst. Der Faktor der Dämpfung der Geschwindigkeit ist dabei variabel konfigurierbar. Das Feature Simulationsobjekt umfasst als Konzept alle Objekte die innerhalb der Simulationswelt existieren. Aktuell sind dies das Trackingobjekt und die Hindernisse. Jedes konkrete Konzept von GenLabS besitzt ein Trackingobjekt, d.h. es handelt sich bei diesem Feature um ein obligatorisches Feature. Dieses stellt das Fahrobjekt dar, welches durch die Probanden innerhalb des durchgeführten Experimentes gesteuert wird. Das Konzept des Trackingobjektes setzt sich aus den obligatorischen Featuren Farbe, Form und Größe zusammen. Es kann dabei alternativ zwischen den Farben Rot, Grün und Blau gewählt werden. Das Trackingobjekt kann entweder eine runde oder rechteckige Form besitzen und ist in Höhe wie Breite variabel konfigurierbar. Das optionale Feature Hindernis abstrahiert alle Formen von Hindernissen. Dabei wird zwischen statischen und dynamischen Hindernissen unterschieden, welche auch zusammen zu einem konkreten Konzept von GenLabS gehören können. Die statischen Hindernisse stellen dabei Hindernisse dar, die eine konstante Position auf der Fahrstrecke haben. Die dynamischen Hindernisse hingegen bewegen sich der Strecke von links nach rechts. Dabei werden zwei Arten der Bewegung unterschieden. Bei der linearen Bewegung ist das Hindernis mit einer konstanten Geschwindigkeit unterwegs. Die adaptive Bewegung hingegen variiert die Geschwindigkeit des 49

59 4. Featuremodell von GenLabS 4.3. Featuremodell von GenLabS Hindernisses, je nachdem mit welcher Geschwindigkeit sich das Trackingobjekt fortbewegt. 50

60 5. Architektur von GenLabS 5.1. Überblick 5. Architektur von GenLabS Im folgenden Kapitel wird die Architektur von GenLabS vorgestellt. Einleitend wird ein allgemeiner Überblick über die Architektur und ihre Schichten gegeben um anschließend die einzelnen Schichten im Detail darzustellen. Um die Übersicht zu erleichtern werden Methoden und Attribute nur beschrieben, insofern sie zum Verständnis der Klassen beitragen. Gleiches gilt auch für verwendete Bibliothektskomponenten. Diese werden nur dann näher betrachtet, wenn sich daraus Besonderheiten für Klassen ergeben. Die Implementationdetails zu GenLabS werden in Kapitel 6. vorgestellt Überblick Die Architektur von GenLabS ist eine hierarchische Schichtenarchitekur mit einer strikten Ordnung. Bei dieser Art von Architektur dürfen Klassen nur auf Klassen der eigenen Schicht oder der hierarchisch nachgeordneten Schichten zugreifen. Durch die Einhaltung dieser Ordnung können Zyklen zwischen den Schichten ausgeschlossen werden. Bei der Architektur von GenLabS wurden einige strengere Prinzipien umgesetzt, die jedoch die beschriebenen Regeln nicht aufheben. Ein Zugriff zwischen den Schichten ist nur von der jeweils übergeordneten Schicht auf die nächst niedrigere Schicht erlaubt, d.h. es herscht eine lineare Ordnung, und darüber hinaus auch nur über Fassaden. Dies bedeutet, das eine Klasse nur auf Klassen aus der eigenen Schicht und Klassen aus der Schnittstelle der hierarchisch nächst nach geordneten Schicht zugreifen darf. Diese zusätzliche Einschränkung dient zur Verringerung der Kopplung zwischen den Schichten. Ziel ist eine leichtere Austauschbarkeit der Schichten sowie der Komponenten innerhalb der Schichten. GenLabS besteht aus drei Schichten Application, welche in der Hierachie an oberster Stelle eingeordnet ist, Management, welche die mittlere Schicht innerhalb der Architektur einnimmt, und Model, welche die Basis der Architektur darstellt. Einen Überblick über die Architektur 51

61 5. Architektur von GenLabS 5.2. Schicht Application vermittelt Abbildung Hier werden die Schichten auf Paketebene in UML 1 dargestellt. Der Namenskonvention von Java folgend hat GenLabS das Präfix hu.genlabs, welches durch die Pakete hu und genlabs realisiert wird. Durch dieses Präfix sind die Klassen innerhalb von GenLabS eindeutig identifizierbar. Dies wird durch die Vielzahl an Java-Bibliotheken nötig. Die Pakete app, management und model repräsentieren die Schichten Application, Management und Model. In den folgenden Abschnitten werden die einzelnen Schichten detailliert dargestellt Schicht Application Die Application Schicht ist für die Anwendungssteuerung zuständig. Die Klassen innerhalb dieser Schicht besitzen den höchsten Abstraktionsgrad, da sie von allen Aufgaben der Ein- und Ausgabe und der Simulation abstrahieren. Aufgrund dieser Tatsache wurde die oberste Position für diese Schicht in der Schichtenarchitektur gewählt. Auf Quelltextebene wird die Application Schicht durch das Paket hu.genlabs.app repräsentiert und besteht dem Paket control (siehe Abbildung ) Paket control Das Paket control ist für die Anwendungssteuerung von GenLabS zuständig. Es besteht aus den Klassen ApplicationControl, ExpControl und ExpStepControl die in Abbildung zu finden sind. Die Klasse ApplicationControl bildet mit der Methode run() den Einstiegspunkt in die Java- Anwendung GenLabS. Hier werden nacheinander die einzelnen Versuche initialisiert und gestartet. In der aktuellen Version ist dies noch nicht implementiert. Die Durchführung beschränkt sich im Moment auf einen singulären Versuch. Am Ende des Programmablaufs beendet die Klasse die Anwendung. Die Klasse ExpControl überwacht den Versuchsablauf. In der Methode run() wird dazu zuerst das Experiment initialisiert. Daraufhin werden die einzelnen Teilschritte des Experiments 1 Die Unified Modeling Language ist eine grafische Modellierungssprache die von Object Management Group (OMG) entwickelt wurde (OMG, 2009) 52

62 5. Architektur von GenLabS 5.2. Schicht Application Abbildung Architektur von GenLabS im UML 53

63 5. Architektur von GenLabS 5.2. Schicht Application Abbildung Die Schicht Application besteht aus den Paketen control und operator Abbildung Das Paket control aus der Schicht Application nach einander abgearbeitet. Am Anfang eines neuen Teilschrittes werden zuerst ein Experimentschritt und die dazugehörigen Strecke erzeugt. Mit den nun zur Verfügung stehenden Daten wird dann die Grafikengine gestartet bzw. in späteren Durchläufen rekonfiguriert. Nach jedem Versuchsschritt und nach dem Durchlaufen aller Versuchsschritte werden die zugehörigen Ressourcen wieder frei gegeben. Die Klasse ExpStepControl ist für die Steuerung der einzelnen Teilschritte (ExperimentSteps) zuständig. Dazu gehören die Durchführung der Simulationsschritte und die Protokollierung der Ergebnisse bzw. Teilergebnisse. Um diese Aufgabe zu erfüllen, besitzt sie einen Zugriff auf den Loggingmechanismus (loggingcontrol), sowie die eigene Id (expstepid) zur Identifikation des Schrittes innerhalb eines Versuchs. Bei der Initialisierung der Klasse wird sowohl eine Simulation sowie ein neuer Loggingmechanismus erzeugt, welche beide über die Methode setuptracking() initialisiert werden. Die Methode dotrackingstep() dient zur Durchführung eines Simulationsschritts. Parallel dazu werden an dieser Stelle die Ergebnisse der einzelnen Simulationsschritte erfasst und protokolliert. Die eigentliche Durchführung des Versuchsschrittes wird durch die Methode run() realisiert, die unter anderem alle 30 ms einmal dotrackingstep() aufruft. 54

64 5. Architektur von GenLabS 5.3. Schicht Management 5.3. Schicht Management Die Schicht Management steht hierarchisch zwischen den beiden anderen Schichten von Gen- LabS. Diese Schicht ist für die Ein- und Ausgabe zuständig.. Unter Eingabe zählt sowohl die direkte Eingabe über Eingabegeräte, wie Joystick und Tastatur, als auch das Einlesen von Dateien. Die Ausgabe umfasst die grafische Darstellung und die Ausgabe in Dateien. Zusätzlich vermittelt die Schicht zwischen der Schicht Application und der Schicht Model. Dies begründet die Position innerhalb der Schichtenarchitektur. Eine herausragende Rolle kommt dieser Schicht zu, da sie ebenfalls für das Variabilitätsmanagement innerhalb von GenLabS zuständig ist. Die Schicht besteht aus den Paketen managementinterface, welches die zentrale Schnittstelle dieser Schicht implementiert und somit den Zugriff aus der Schicht Application bedient, io, welches die Funktionen der Ein- und Ausgabe implementiert, und productconfigurator, welches das Variabilitätsmanagement realisiert. Die Pakete der Schicht sind in Abbildung dargestellt. Abbildung Die Schicht Management besteht aus den Paketen managementinterface, io (inklusive expconfig, input, logging, gui (inklusive der Pakete engine und speedindicator)) und productconfigurator (inklusive des Paketes config) 55

65 5. Architektur von GenLabS 5.3. Schicht Management Paket managementinterface Das Paket managementinterface stellt die zentrale Schnittstelle für Zugriffe auf die Management Schicht dar. Daraus ergibt sich, das Zugriffe auf die Klassen dieser Schicht nur von Klassen aus diesem Paket durchgeführt werden. Es handelt sich um die Realisierung des Design Patterns Fassade. Abbildung zeigt die Klassen des Pakets IOInterface, LoggingInterface und SimualtionIO. Abbildung Das Paket Managementinterface aus der Schicht Management Die Klasse ManagementInterface ist die zentrale Klasse des Pakets. Sie stellt den Einstiegspunkt für jeden Zugriff von außen dar. Zu diesem Zweck ist es nötig, dass es immer nur genau eine Instanz der Klasse gibt. Um dieses Ziel zu erreichen, wurde das Entwurfsmuster Singleton auf diese Klasse angewendet. Über die Methode getinstance() kann die Instanz der Klasse abgefragt werden. Die Klasse verteilt den Zugriff auf die Klassen SimulationIO (simstatus), welche Funktionen der Simualtion zur Verfügung stellt, und der Logging Schnittstelle (li). Darüber hinaus hält sie Instanzen der Grafik Engine (gec, tv) und der Klasse ConfigControl (expconfig), welche zur Konfiguration der Experimente dient. Mit Hilfe der Methode createexperiment(), kann die Erstellung der Versuche angestoßen werden. Die Methode createsimulation() dient der Erstellung der Simualtion und mit Hilfe der Methoden startgraphicengine() und reconfigergraphicengine() kann der Be- 56

66 5. Architektur von GenLabS 5.3. Schicht Management trieb der Grafik Engine durchgeführt werden. Abschließend ist noch die Methode getloggingcontrol() zu nennen, welche einen neuen Loggingcontroller zur Verfügung stellt. Die Klasse LoggingInterface ist ein Wrapper, der die Funktionen des Pakets logging zur Verfügung stellt. Dazu stellt werden die Methoden setuplogger(), zum aufsetzen eines Loggers, und writelogentry(), zum schreiben eines Logeintrags, bereitgestellt. Die Klasse SimulationIO ist ein Wrapper für die Funktionen der Simulation. Es stellt insbesondere den Status der Simulation zur Verfügung. Dies geschieht mit Hilfe der Methoden isgraphicenginestarted(), issimulationdisposed() und issimulationnextstep() welche jeweils einen boolean Wert zurückgeben Paket io Das Paket io umfasst alle Pakate welche die Ein- und Ausgabe umsetzen. Dazu gehören die Pakete gui, welches die grafische Darstellung umsetzt, input, welches die Eingabegeräte zur Verfügung stellt, logging, welches die Funktionen zur Protokollierung implementiert, und expconfig, welches die Konfiguration der einzelnen Experimente übernimmt,. In den Abschnitt ,Abschnitt , Abschnitt und Abschnitt werden diese Pakete näher beschrieben Paket input Das Paket input beinhaltet alle Klassen, die den Input über Eingabegeräte zur Verfügung stellen. Die Klassen dieses Paketes sind aktuell ControlDevice, JoystickControl und KeyboardControl und sind in UML in Abbildung zu finden. In der momentanen Version sind zwei mögliche Eingabegeräte implementiert. (siehe dazu Abschnitt 4.3.) Die abstrakte Klasse ControlDevice deklariert alle Funktionen die durch die Geräteklassen zur Verfügung gestellt werden müssen. Dazu gehören die Berechnung des Inputs (calculateinput()), sowie die Abfrage der aktuellen Eingaben für die X- bzw. Y-Achse (getcurrent- XInput(), getcurrentyinput()). Folgende Attribute sind ebenfalls in allen Geräteklassen vertreten der Name der Instanz (name), die Gewichtung der Eingabe (weight) und der mit dem Eingabegerät assoziierte MWB (associatedmwi). 57

67 5. Architektur von GenLabS 5.3. Schicht Management Abbildung Das Paket input aus der Schicht Management Das Eingabegerät Joystick wird in der Klasse JoystickControl implementiert. Sie stellt einen Wrapper des org.lwjgl.controller dar. Die Instanz von Controller wird vom org-.lwjgl.controllers bezogen. JoystickControl ist Subklasse von ControlDevice und erbt von dieser. Die Klasse KeyboardControl stellt einen Wrapper für org.lwjgl.input.keyboard dar. Durch diese Klasse sind Eingabe mit der Tastatur möglich. Die Klasse ist abgeleitet von der Superklasse ControlDevice Paket expconfig Das Paket expconfig konfiguriert die versuche innerhalb von GenLabS. Dazu greift es auf Konfigurationsdateien zu, mit deren Hilfe die Parameter eines Versuches festgelegt werden können. Das Paket besteht wie in Abbildung zu sehen aus den Klassen ConfigControl, ConfigParser, DynamicObstacleConfig, ExperimentConfig, ExperimentStepConfig, InputConfig, LoggingConfig, MWIConfig, ObstacleConfig, SAMConfig, StaticObstacleConfig und TrackConfigParser. Die Klasse ConfigControl stellt den Zugang zu den Funktionen des Paketes dar. Dazu hält es eine abrufbare Liste aller konfigurierten Experimente (experimentlist) bereit. Die zentrale Funktion der Klasse besteht im einlesen und erstellen der Experimente. Dies geschieht durch das Anstoßen der Methode createexperiment(). Das einlesen erfolgt mit Hilfe eines Parsers 58

68 5. Architektur von GenLabS 5.3. Schicht Management Abbildung Das Paket expconfig aus der Schicht Management 59

69 5. Architektur von GenLabS 5.3. Schicht Management (cp). Darüber hinaus besitzt die Klasse eine Liste aller verfügbaren Eingabegeräte (devices), die den einzulesenden MWBs zu geordnet werden. (siehe Abschnitt ) Die Klasse ConfigParser stellt einen XML Parser für die Konfigurationsdateien bereit. Die Klasse besitzt den Pfad zur Konfigurationsdatei (source), sowie die Möglichkeit mit Hilfe der Methode setsource() die Dateien auszutauschen. Die Klasse stellt einen Wrapper für das SimpleXMLFramework dar. Dazu wird die Klasse org.simpleframework.xml.serialiser benutzt und die Ergebnisse über die Methode getconfig() abrufbar gemacht. Die Klassen SAMConfig, ExperimentConfig, ExperimentStepConfig, InputConfig, MWI- Config, ObstacleConfig, StaticObstacleConfig und DynamicObstacleConfig stellen zusammen die Struktur der Konfigurationsdatei dar. Diese dienen dem Parser zu lesen der Dateien in XML. Es werden die Klassen Element, ElementList, Root, Attribute und Test aus dem Paket org.simpleframework.xml verwendet um die einzelnen Elemente der XML darzustellen. Die Klasse LoggingConfig stellt einen Parser zur Verfügung der die konfigurierten Loggingvariablen einliest und dem Programm zur Verfügung stellt. Die Klasse TrackConfigParser stellt einen XML-Parser dar, welcher die Konfiguration der Strecken einliesst Paket logging Das Paket logging stellt den Logging-Mechanismus von GenLabS zur Verfügung. Wie in Abschnitt beschrieben, gibt es drei grundsätzlich Unterschiedliche Logging-Modi. Der erste Modi stellt gar keine Loggingfunktionen zur Verfügung. Bei den beiden anderen unterscheidet sich das Logging durch das verwendete Format. So wird im ersten Fall das CSV 2 Format verwendet und im anderen das XML 3 Format. Das Paket besteht aus den Klassen LogEntryData, LoggingControl, LoggingControlDummy, LoggingDataCollector, NestedLogEntryData, RootLogEntryData, SimpleLogEntryData, SimpleXMLLogger und SimpleCSVLogger und den Interfaces ILogger und ILoggingControl, welche in Abbildung zu finden sind. 2 Comma-Separated Values ist ein Dateiformat das zur einfachen Strukturierung von Daten verwendet wird. 3 Extensible Markup Language ist eine Auszeichnungssprache die zur strukturierung von Daten verwendet wird (W3C, 2008). 60

70 5. Architektur von GenLabS 5.3. Schicht Management Abbildung Das Paket logging aus der Schicht Management 61

71 5. Architektur von GenLabS 5.3. Schicht Management Das Interface ILogger definiert die Methoden, welche durch jeden Logger implementiert werden müssen. Ein Logger muss eine neue Datei erstellen können (createnewlogfile()), es müssen neue Data geschrieben werden (writelogentry(), writerootentry()) und der Logger muss die Protokolldatei wieder schließen können (closelogfile()). Darüber hinaus muss der Logger Auskunft über die eigene Einsatzbereitschaft geben (isreadytolog()). Die Klassen SimpleXMLLogger und SimpleCSVLogger stellen konkrete Implementationen dieses Interfaces dar. Dabei werden die Daten im ersten Fall im XML und im zweiten Fall im CSV Format geloggt. Die Klassen LogEntryData, NestedLogEntryData, RootLogEntryData und SimpleLogEntryData werden zur Datenstrukturierung verwendet. Eine Ausführliche Beschreibung der Umsetzung findet sich in (Hildebrandt, 2009). Das Interface ILoggingControl legt fest, welche Funktionen durch das Logging von anderen Klassen verwendet werden können. Mit anderen Worten stellt ILoggingControl die Schnittstelle zum Paket logging dar. Die Funktionen sind das aufsetzen eines Loggers mit Hilfe der Methode setuplogger(), das Schreiben eines Eintrags (writelogentry()), sowie das Zurücksetzen des Loggers (resetlogger()) und das beenden des Loggers (teardownlogger()). Die Klasse LoggingControl implementiert das Interface ILoggingControl. Die beschriebenen Aufgaben werden mit Hilfe eines LoggingDataCollectors (datacollector), eines Loggers (logger) und einer Liste der zu loggenden Variablen (logentryvars, rootentryvars) erfüllt. Das Interface LoggingControlDummy implementiert ebenfalls das Interface ILoggingControl. Dabei werden keine Funktionalitäten implementiert. Die Klasse dient ausschließlich als Platzhalter. Die Klasse LoggingDataCollector stellt eine Abbildungsfunktion zwischen den im Logging verwendeten Variablen und den tatsächlichen Daten der Simulation dar. Die Klasse implementiert also eine Schnittstelle zwischen Logging und Simulation. Um diese Aufgabe zu erfüllen hält die Klasse die Methode update() bereit, mit deren Hilfe die aktuellen Werte der Simulation ausgelesen werden. Diese sind dann über die Methoden getrootentry() und getlogentry() abrufbar. 62

72 5. Architektur von GenLabS 5.3. Schicht Management Paket gui Das Paket gui subsumiert alle Funktionen, die für die grafische Darstellung benötigt werden. In der aktuellen Version besteht es aus den beiden Paketen engine, welches alle Klassen beheimatet die für den Betrieb der Grafik Engine benötigt werden, und speedindicator, welches alle Klassen beinhaltet die einen Tachometer implementieren. Letzteres stellt eine Erweiterung der Funktionen der Grafik Engine dar, gehört aber nicht zu der Kernfunktionalität. Abbildung zeigt das Paket in der Übersicht. Das Paket engine besteht aus den Klassen GraphicEngineController, TrackView, ParcoursView, TOView und ObstacleView. Die Klasse GraphicEngineController stellt einen Wrapper für die Funktionen der Grafik Engine dar. Er baut dabei auf der Klasse org.newdawn.slick.appgamecontainer auf. Diese stellt eine Containerklasse dar, in die org.newdawn.slick.basicgame Klassen geladen werden können, und die den Rendering und Updateprozess steuert. Mit Hilfe der Methode run() kann die Grafik Engine in einem eignen Thread gestartet und mit stopapp() gestoppt werden. Die Klasse TrackView ist eine Subklasse von org.newdawn.slick.basicgame und implementiert die Methoden init(), mit deren Hilfe der darzustellende Kontext initialisiert wird, render(), welche zur grafischen Umsetzung des Kontextes führt, und update(), die den Kontext aktuallisiert. Darüber hinaus kann die Instanz der Klasse neukonfiguriert werden (reinit()). Die Klassen ParcoursView, TOView und ObstacleView werden zur Darstellung der Strecke, des Trackingobjekts und der Hindernisse benutzt und besitzen ihrerseits jeweils die Methoden init(), render() und update(). Das Paket speedindicator besteht aus den Klassen SpeedIndicator, SpeedIndicatorDummy, Tachometer, TachometerConverse und GlassFillingLikeSI. Sie implementieren das Feature SpeedIndicator (siehe Abbildung ). Die abstrakte Klasse SpeedIndicator definiert die Funktionalität einer SpeedIndicatorklasse. Zum einen muss der Speedindicator berechnet werden, dies geschieht mit Hilfe der Methode update(), zum anderen muss die grafische Darstellung des Speedindicators abrufbar sein (getspeedindicator()). Es gibt vier von SpeedIndicator abgeleitete Klassen. Die einfachste ist die Klasse Speed- 63

73 5. Architektur von GenLabS 5.3. Schicht Management Abbildung Das Paket gui, mit den Paketen engine und speedindicator, aus der Schicht Management 64

74 5. Architektur von GenLabS 5.3. Schicht Management IndicatorDummy dar, die nur als Platzhalter fungiert und keine Funktionalität implementiert. Die Klasse GlassFillingLikeSI füllt das Trackingobjekt von oben nach unten aus. Die Klassen Tachometer und TachometerConverse implementieren jeweils das Verhalten eines normalen Tachometers, bei dem das Trackingobjekt kreisförmig gefüllt wird. Bei ersteren füllt sich das Trackingobjekt im Uhrzeigersinn und beim anderen gegen diesen Paket productconfigurator Das Paket productconfigurator beinhaltet die Klassen des Variabilitätsmanagements. Wie der Name andeutet werden die Klassen dieses Paketes zur Konfiguration der Anwendung Gen- LabS benutzt. Die Konfiguration erfolgt über XML-Dateien. Die Beschreibung der technischen Umsetzung erfolgt in Kapitel 6.. Das Paket besteht aus der Klasse ProductConfigurator und dem Paket config, dass die Klassen FeaturesParser, Feature, FeatureList und Parameter beinhaltet. Eine Übersicht über das Paket bietet Abbildung Abbildung Das Paket productconfigurator aus der Schicht Management Die Klasse ProductConfigurator implementiert die Entscheidungsroutine, die für die Konfiguration von GenLabS zuständig ist. In der aktuellen Version von GenLabS können dabei folgende Entscheidungen getroffen werden. Mit der Methode getto() wird über die Form, Größe und Farbe des Trackingobjektes entschieden. Die Art des Eingabegerätes erfolgt mit der Methode getcontroldevice(). Die verwendeten physikalischen Regel gibt die Methode getphysicsrule() zurück. Ob und in welcher Form ein SpeedIndicator Anwendung findet wird mit der Methode getspeedindicator() entschieden. Die Methode getloggingcontrol() gibt die zu verwendende Form des Loggings zurück, wobei die Variation darin besteht 65

75 5. Architektur von GenLabS 5.4. Schicht Model ob und wenn ja in welchem Format ein Logging stattfindet. Als letztes entscheidet der ProductConfigurator über die Bildschirmauflösung, die über die Methode getdisplaymode() abgefragt werden kann. Diese Auswahlmöglichkeiten korrespondieren mit dem in Abschnitt 4.3. vorgestellten Featuremodell. Die Klasse FeatureParser stellt einen einfachen XML-Parser dar, der mit Hilfe der Methode initparser() initialisiert wird. Über die Methode getfeature() können im Folgenden die einzelnen Feature abgefragt werden. Die Klassen Feature, FeatureList und Parameter dienen zur Repräsentation der Struktur der XML-Datei. Hierbei wird das SimpleFramework verwendet Schicht Model Die Schicht Model umfasst alle Pakete und Klassen, die zur Berechnung des Trackings benötigt werden. Somit handelt es sich um die Fachkonzeptschicht von GenLabS. Nach Einführung eines Object Systems greifen die Klassen dieser Schicht nicht mehr auf Klassen der anderen Schichten zu. Im Gegenteil Klassen der IO Schicht greifen nun auf das Object System zu und befüllen es mit den Daten, die aus externen Dateien stammen oder durch Eingaben der Nutzer über Eingabegeräte. Somit erklärt sich die unterste Position dieser Schicht innerhalb der Hierarchie von GenLabS. Die Schicht besteht aus den Paketen modelinterface, welches die Schnittstelle der Schicht nach außen darstellt, dem Paket objectsystem, welches das bereits erwähnte Object System implementiert, und dem Paket sim, welches die Funktionalitäten zur Berechnung des Trackings beinhaltet. Letzteres beinhaltet die Pakete config, welches die Objekte der Versuchskonfiguration bereitstellt, simobject, die alle Simulationsobjekte beheimatet, und engine welches die Kernfunktionalität der Simulation bereitstellt. Die Abbildung bietet einen Überblick über diese Schicht Paket modelinterface Das Paket modelinterface implementiert die zentrale Schnittstelle für die Schicht Model. Alle Zugriffe von Klassen anderer Schichten werden über dieses Paket gesteuert. In der aktuellen Version ist dies noch nicht vollständig umgesetzt. Es finden immer noch direkte Zugriffe auf das Paket sim statt. Das Paket besteht aus den Klassen ModelInterface, ObjectSystem- 66

76 5. Architektur von GenLabS 5.4. Schicht Model Abbildung Die Schicht IO besteht aus den Paketen modelinteface, objectsystem und sim (inklusive der Pakete engine, config, simobject) Interface, SimualtionInterface und SimulationsStatus, welche in Abbildung wieder zu finden sind. Abbildung Das Paket modelinterface aus der Schicht Model Die Klasse ModelInterface stellt den zentralen Einstiegspunkt für Zugriffe von außen dar. Die Aufgabe dieser Klasse besteht in der Verteilung der Zugriffe auf die anderen Interfaces ObjectSystemInterface (getobjectsystem()) und SimualtionInterface (getsimulation()). Desweiteren kann die Klasse SimulationsStatus abgefragt werden (getsimulationstatus()). Die Klasse ObjectSystemInterface implementiert einen Wrapper für das Object System. Dazu werden Methoden des Object System umgesetzt. Hervorzuheben sind dabei die Methoden 67

77 5. Architektur von GenLabS 5.4. Schicht Model getvalue() und setvalue(), da hier ein Mapping der Attributnamen auf die Liste der möglichen Attributnamen stattfindet. Dies geschieht mit Hilfe der Methode getattributename(). Die Klasse SimulationInterface stellt einen Wrapper für die Simulation, d.h. die Klassen des Pakets sim, bereit. In dieser Funktion stellt es die Methoden createsimulation(), die eine Simulationserzeugung anstößt, settostartpositio(), welches die Anfangswerte der Simulation einstellt, und setnewpostion(), was zur Berechnung eines neuen Simulationsschrittes führt, zur Verfügung. Darüber hinaus liefert es, über die verschiedenen Getter, Informationen über Bestandteile der Simulation. Beispielhaft sei hier die Methode getparcours() genannt, die die Id des Parcours zurück gibt, über welche dieser im Object System abrufbar ist. Die Klasse SimulationsStatus ist eine Enumeration der möglichen Simulationszustände. Eine Auflistung der möglichen Zustände von GenLabS ist der Tabelle C.2.6. zu entnehmen Paket objectsystem Das Paket objectsystem implementiert das Object System von GenLabS. Es dient die zentralen Datenhaltung von Simulationsobjekten. Es basiert auf dem von Doherty vorgestellten Object System (Doherty, 2003) und wurde in einer früheren Arbeit implementiert (Wagner, 2012). Das Paket besteht zurzeit aus den Klassen StoredObject, SimObjectSystem und LegalAttributeNames, sowie dem Interface ObjectSystem, welche in Abbildung zu sehen sind. Abbildung Das Paket objectsystem aus der Schicht Model 68

78 5. Architektur von GenLabS 5.4. Schicht Model Die abstrakte Klasse StoredObject definiert ein durch das Object System benutzbares Simulationsobjekt. Dies bedeutet, dass jedes Objekt welches im Object System gehalten werden soll, ein Objekt einer Subklasse sein muss. Dabei besitzt die Klasse eine Id (id), welches das Objekt im Object System identifizierbar und somit ansteuerbar macht. Über die Methode getvalue() und setvalue() sind die Eigenschaften der Simulationsobjekte abrufbar und veränderbar. Das Interface ObjectSystem definiert die durch ein Object System er erfüllenden Aufgaben. Zu diesen gehört auf der einen Seite die Verwaltungsaufgabe, wie das Hinzufügen (addobject()), Löschen (removeobject()) und Zurückgeben (getstoredobject()) von Simulationsobjekten. Desweiteren müssen die Werte der Simulationsobjekte abrufbar (getvalue()) und Änderbar (setvalue()) sein. Die Klasse SimObjectSystem implementiert dieses Interface. Um die Aufgabe zu erfüllen hält es die Simulationsobjekte in einer Hashmap (objectstore). Außerdem verfügt es über einen Zähler für neue Ids (getnextid). Die Klasse LegalAttributeNames ist eine Aufzählung aller, durch das Object System, abrufbaren Attribute von Simulationsobjekten. In der aktuellen Version sind dies 33. Die genaue Auflistung befindet sich im Abschnitt C Paket sim Das Paket sim implementiert die Simulation von GenLabS. Dies beinhaltet die Berechnung der Simulationszustände, die Interaktion der Simulationsobjekte innerhalb der Strecke, sowie die Ablaufsteuerung der einzelnen Berechnungsschritte. Das Paket besteht aus den Klassen Track- Control, RectangleTOControl, EllipseTOControl, ParcoursControl, DynamicObstacleControl, StaticObstacleControl und dem Interface ITrackingObjectControl, sowie den Paketen config, simobject und engine (siehe Abbildung ). Die Klasse TrackControl stellt die zentrale Klasse dieses Pakets dar. Sie setzt die Simulation auf die Anfangswerte (settostartposition()), stößt einen neuen Berechnungsschritt an (setnewposition()) und berechnet Kollision zwischen den Simulationsobjekten und deren Auswirkungen (collisionoccurs()). Um diese Aufgabe zu erfüllen sind dem TrackControl eine Strecke (parcours), ein Trackingobjekt (trackingobject), dynamische (dynamic- Obstacle) und statische (staticobstacle) Hindernisse und eine Liste der MWBs (mwis) zugeordnet. Darüber hinaus besitzt sie Zugang zur Physik Engine (physics). 69

79 5. Architektur von GenLabS 5.4. Schicht Model Abbildung Das Paket sim mit den Unterpaketen config, engine und simobject aus der Schicht Model 70

80 5. Architektur von GenLabS 5.4. Schicht Model Die Klasse ParcoursControl umfasst sämtliche Funktionalität, die mit der Strecke der Simulation zusammenhängt. Dazu erzeugt die Klasse das Simulationsobjekt Parcours und führt die nötigen Berechnungen auf diesem aus. Dazu gehören, dass setzen der Anfangswerte (setto- StartingPosition()), das Bewegen der Strecke (scrolldownby()), sowie das Herstellen des aktuellen Zustandes (updatestate()). Darüber hinaus liefert die Klasse Informationen über die Farbwerte an bestimmten Stellen der Strecke (getrgbatpixel()), sowie über die aktuell sichtbaren Abschnitte der Strecke (getvisiblearea()) und über die Anzahl der in der Summe zurückgelegten Pixel (getpixelscrolleddown()), sowie der im letzten Schritt zurückgelegten Pixel (getlastscrolleddown()). Das Interface ITrackingObjectControl definiert die Funktionalität, die ein Trackingobjekt Controller besitzen muss. Dies umfasst alle Berechnungen, die auf einem Trackingobjekt durchgeführt werden. Dazu gehören das Setzen der Startposition (settostatingposition()), das Bewegen auf der X-Achse (movehorizontalby()), die Berechnung der Sensoren (getsensorvalue()), die Interaktion mit anderen Simulationsobjekten (intersectwith()) und die Rückgabe der aktuellen X- und Y-Position (getcurrentxposition(), getcurrentyposition()). Die Klassen RectangleTOControl und EllipseTOControl implementieren das beschriebene Interface. Erstes implementiert ein rechteckiges TrackingObjekt und die zweite Klasse ein rundes bzw. elliptisches (siehe Abschnitt ) Die Klasse StaticObstacleControl und DynamicObstacleControl umfassen die Funktionen zum Umgang mit statischen und dynamischen Hindernissen. Beide bieten Methoden zum Initialisieren der Hindernisse (init()), zum Bewegen der Hindernisse (moveobstacle()) und zur Abfrage der auf dem aktuellen Abschnitt sichtbaren Hindernisse (getvisibleobstacles()). DynamicObstacleControl besitzt darüber hinaus die Möglichkeit das Hindernis auf der vertikalen Y-Achse zu bewegen (movevertical()). Paket config Das Paket config subsumiert die Klassen, welche einen Versuch, mit anderen Worten ein Experiment, abstrahieren. Es enthält die Klassen Experiment, ExperimentStep und MWI, welche in Abbildung abgebildet sind. Die Klasse Experiment stellt dabei die Gesamtheit des Versuches dar und besteht aus einer Id (expid), einer Id des Operateurs (operatorid), einer Liste von Experimentschritten (stepconfigs), sowie dem aktuellen Versuchsschritt (currentstep) und dem zur Identifika- 71

81 5. Architektur von GenLabS 5.4. Schicht Model Abbildung Das Unterpaket config des Pakets sim aus der Schicht Model tion in der Liste nötigen Hashwert (currentstephashcode). Die Klasse bietet die Möglichkeit zum nächsten Versuchsschritt zu wechseln (switchtonextstep()). Darüber hinaus sind alle Attribute über Getter abfragbar. Die Klasse ExperimentStep stellt einen Teilschritt des Experimentes dar. Ein solcher Versuchsschritt zeichnet sich durch eine Strecke (trackconfig), einen oder mehrere MWBs (mwis), sowie dynamische (dynamicobstacles) und statische (staticobstacles) Hindernisse aus. Jeder Versuchsschritt wird über einen Id identifiziert (StepId). Die Klasse MWI abstrahiert die Mikroweltbewohner und enthält Informationen über das Geschlecht (sexofproband), die Teamnummer (experimentalteamid), die Gruppennummer (experimentalgroupid) und die Nummer des MWB (probandid). Außerdem werden der Steuerungsanteil (currentinputallocation) und die Werte der Eingabegeräte (currentx- Input, currentyinput) erfasst. Paket simobjects Das Paket simobjects beinhaltet alle Simulationsobjekte der Simulation von GenLabS. Diese sind Objekte, welche auf der Strecke mit einander interagieren. Darüber hinaus ist die Strecke selbst ein Simulationsobjekt. Das Paket besteht aus den Klassen Parcours, TrackSection, TrackSectionProperties, TrackingObject, RectangleTrackingObject, EllipseTrackingObject, Obstacle, StaticObstacle und DynamicObstacle. Für einen Üblick soll Abbildung dienen. Die Klasse Parocurs stellt die Strecke der Simulation dar. Eine Strecke besteht aus mehreren Abschnitten (sections) und einer definierten Länge (lengthoftrack). Die Klasse hält außerdem die bereits zurückgelegte Strecke (pixelscrolleddown) und die im letzten Berechnungsschritt zurückgelegte Strecke (lastscrolledpixel) bereit. Außerdem wird an dieser Stelle die Strecke zusammengebaut (createtrack()). Die Klasse ist Subklasse von StoredObject. 72

82 5. Architektur von GenLabS 5.4. Schicht Model Abbildung Das Unterpaket simobjects des Pakets sim aus der Schicht Model 73

83 5. Architektur von GenLabS 5.4. Schicht Model Die Klasse TrackSection bildet einen Teilabschnitt der Strecke und besteht unter anderem aus einem hinterlegten Bild (sectionimage) und einer Liste von Eigenschaften (sectionproperties), welche durch die Klasse TrackSectionProperties implementiert werden. Auf eine detailliertere Beschreibung wird an dieser Stelle verzichtet und auf die Arbeit von Hildebrandt verwiesen. (Hildebrandt, 2009) Die abstrakte Klasse TrackingObject steht als Superklasse für das Trackingobjekt in der Simulation. Die Klasse ist von StoredObject abgeleitet. Ein Trackingobjekt besteht aus einer Farbe (color), einer Form (objectshape), einer Position (refpos) und es besitzt eine Geschwindigkeit (speed). Die Klassen RectangleTrackingObject und EllipseTrackingObject sind Subklasse von TrackingObject und erweitern das Trackingobjekt um einen Typ (typofto), eine spezifische Form, welche im ersten Fall shapeasrectangle und im zweiten shapeasellipse ist, und eine Startposition (startingposition). Desweiteren werden an dieser Stelle die Sensoren festgelegt, die durch die Klasse Sensor beschrieben werden. Die abstrakte Klasse Obstacle implementiert die Hindernisse und ist Subklasse von Stored- Object. Sie setzt sich zusammen aus einer Form (obstacle), einer Position (xposition, yposition), sowie einer Höhe (heigth) und Breite (width). Die Klasse DynamicObstacle stellt eine Spezialisierung von Obstacle dar und zeichnet sich durch eine Geschwindigkeit (horizontalspeed) aus. Darüber hinaus kann sich die Geschwindigkeit dem Verhalten des Trackingobjektes anpassen. Dieses Verhalten wird adaptiv genannt (isadaptiv). Die Klasse StaticObstacle spezifiziert ein statisches Hindernis und ist abgeleitet von Obstacle. Ein statisches Hindernis besitzt eine Überdeckungsrate der Fahrbahn (trackcoverage). Diese Art von Hindernissen kann mit einem weiteren statischen Hindernis zusammen zu einem Slalom verbunden werden (associatedobstacle). Paket engine Das Paket engine stellte die Physik Engine bereit. Sie setzt sich in der aktuellen Version aus den Klassen Physics, PhysicsRule und ErrorFeedback zusammen. (siehe Abbildung ). Die Klasse Physics stellt die zentrale Klasse der Physik Engine dar. Die Engine besteht aus mehreren Regeln (rules), die nacheinander abgearbeitet werden. Es können Regeln hinzuge- 74

84 5. Architektur von GenLabS 5.4. Schicht Model Abbildung Das Unterpaket engine des Pakets sim aus der Schicht Model fügt (addrule()) und gelöscht (removerule()) werden. Die abstrakte Klasse PhysicsRule definiert die Oberklasse für alle physikalischen Regeln, die durch GenLabS realisiert werden sollen. Jede Regel muss die Methode calculate() implementieren. Die Klasse ErrorFeedback stellt im Moment die einzige physikalische Regel dar, die durch die Physik Engine angewendet werden kann. Ziel der Regel ist das sukzessive abbremsen des Trackingobjektes beim Verlassen der Fahrbahn. 75