Seminar Entwicklung verteilter eingebetteter Systeme

Transkript

1 Name Datum Autorin Stephanie Müller Titel: PuLSE Grundlagen

2 Inhaltsverzeichnis 1 Was sind Produktlinien? 1.1 Funktion 1.2 Vorteile einer Produktlinie 1.3 Bindungszeitpunkte der Variabilität 2 Feature Modellierung 2.1 Definition 2.2 Möglichkeiten der Feature Modellierung 2.3 Featuremodellierung am Beispiel eines Autos 2.4 Features und AOP 3 Einführung in PuLSE 3.1 Was ist PuLSE? Definition Eigenschaften und Entstehung 3.2 Komponenten von PuLSE Überblick über alle Komponenten Deployment Phases Technical Components PuLSE-Eco PuLSE-CDA PuLSE-DSSA PuLSE-EM Support Components 4 Überblick über KobrA 4.1 Definition und Eigenschaften 4.2 Bezug zu PuLSE 4.3 Activities Framework engineering Application engineering 5 Aktueller Einsatz 6 Literatur

3 Abbildungsverzeichnis: ABBILDUNG 1: BEISPIEL FÜR EINE PRODUKTLINIE ABBILDUNG 2: VERWENDUNG EINER PRODUKTLINIE ABBILDUNG 3: BINDUNGSZEITPUNKTE DER VARIABILITÄT ABBILDUNG 4: FEATURE MIT ZWEI GRUPPEN VON OR-FEATURES ABBILDUNG 5: FEATURE MIT ZWEI GRUPPEN VON ALTERNATIVE FEATURES ABBILDUNG 6: FEATUREMODELLIERUNG DES KONZEPTS AUTO ABBILDUNG 7: ABLAUF ASPEKTORIENTIERTE PROGRAMMIERUNG ABBILDUNG 8: FEATURES UND ASPEKTORIENTIERTE PROGRAMMIERUNG ABBILDUNG 9: KOMPONENTEN VON PULSE ABBILDUNG 10: ZUSAMMENHANG DER TECHNISCHEN KOMPONENTEN VON PULSE ABBILDUNG 11: ABLAUF VON PULSE-CDA ABBILDUNG 12: ABLAUF VON PULSE-DSSA ABBILDUNG 13: EVOLUTION UND MANAGEMENT BEI PULSE-EM ABBILDUNG 14: LEARNING BEI PULSE-EM ABBILDUNG 15: MODELLE BEIM FRAMEWORK ENGINEERING IN KOBRA ABBILDUNG 16: APPLICATION ENGINEERING BEI KOBRA

4 1 Was sind Produktlinien? 1.1 Funktion Die Grundidee einer Produktlinie besteht darin Funktionen in unterschiedlichen, aber sehr ähnlichen Produkten wieder zu verwenden. Am besten lässt sich die Motivation für eine Produktlinie an einem Beispiel erklären: Wir haben drei auf dem Bild dargestellte Autos, die sich nur in der Lack- und Reifenfarbe unterscheiden. Abbildung 1: Beispiel für eine Produktlinie In einer Produktlinie soll ein Produkt mit allen seinen möglichen Ausprägungen und Sonderausstattungen modelliert werden. Immer wenn der Kunde zwischen mehreren Varianten wählen kann, sollen alle Auswahlmöglichkeiten in der Produktlinie beschrieben werden. Eine Auswahlmöglichkeit kann Auswahlmöglichkeiten an anderen Stellen einschränken. Die Modellierung der Produktlinie wird auch als Domain Engineering bezeichnet. In unserem Beispiel sind die Lackfarbe mit den Ausprägungen rot und gelb und die Reifenfarbe mit den Ausprägungen grau und schwarz Entscheidungsmöglichkeiten in der Produktlinie. Wenn die verkaufende Firma einen potentiellen Kunden gefunden hat, äußert der Kunde seine Wünsche und Anforderungen an das Produkt. Der Verkäufer legt anhand der Kundenwünsche Entscheidungen innerhalb der Produktlinie fest. Möchte der Kunde das linke Auto im oberen Bild kaufen, legt der Verkäufer grau als Reifenfarbe und rot als Lackfarbe fest. Diesen Prozess nennt man Product Engineering. In der unteren Graphik wird die Verwendung der Produktlinie dargestellt: Domain Engineering Software Assets Product Engineering Production Mechanism / Process Product 2 Scope of the Product line Product 1 Product N Decision Model Product Decisions Abbildung 2: Verwendung einer Produktlinie

5 Aus dem Domain Engineering, in der Graphik gelb dargestellt, resultieren Beschreibungen (Software Assets) und ein Entscheidungsmodel (Decision Model), in dem alle möglichen Variationen der Produktlinie beschrieben werden. Diese Resultate werden beim Product Engineering, oben blau dargestellt, verwendet, um ein einzelnes Produkt zu erzeugen. Aus jeder Produktlinie kann man eine begrenzte Anzahl N von verschiedenen Produkten erzeugen, indem man alle verschiedenen Entscheidungsmöglichkeiten miteinander kombiniert. Die Menge der verschiedenen möglichen Produkte wird als Scope of the Product Line, oben grün dargestellt, bezeichnet. 1.2 Vorteile einer Produktlinie Mit Hilfe der Produktlinie wird eine hohe Widerverwendbarkeit des Programmcodes realisiert, durch die folgende Vorteile entstehen: Kürzere Entwicklungszeit: Mit weniger Programmcode wird dieselbe Wirkung erzielt. Geringere Komplexität der Software: Dieselbe Funktionalität existiert idealer Weise nicht doppelt. Leichtere Anpassbarkeit: Viele möglichen Varianten wurden in der Produktlinie und daher auch bei der Implementierung bereits berücksichtigt. Senkung der Produktionskosten durch die drei oben aufgeführten Punkte. Einfache Wiederverwendung in der Zukunft durch klar umrissene Features. Funktionalität verhält sich in jedem Produkt identisch, weil alle Produkte dasselbe Feature enthalten. Bessere Wartbarkeit durch einfache Wiederverwendung in der Zukunft und sich identisch verhaltene Funktionalität. 1.3 Bindungszeitpunkte der Variabilität Die folgende Graphik zeigt den Zeitablauf von allen möglichen Bindungszeitpunkten: Abbildung 3: Bindungszeitpunkte der Variabilität

6 Im Design und bei der Wiederverwendung von Software bestehen die ersten Möglichkeiten durch Variationspunkte in Modellen Variabilität zu realisieren. In diesem frühen Stadium wirken sich einmal getroffene Entscheidungen sehr lange aus und nur wirklich essentielle Variabilität sollte hier festgelegt werden. Bei der Kompilierung kann im Präkompiler z.b. in C oder C++ oder durch das Einbinden von Aspekten Variabilität erzeugt werden. Die Abkürzung AOP in der Graphik steht für Aspektorientierte Programmierung. Diese ersten Bindungszeitpunkte bezeichnet man auch als Variability in narrow sense. Bei der Produktion oder in der Werkstatt kann durch Kallibrierung, die auch als Parametrisierung bezeichnet wird, Variabilität hergestellt werden. Hier wird durch das Setzen von einzelnen Parametern das Systemverhalten festgelegt. Zur Laufzeit bietet sich nur noch die Möglichkeit über if then else -Abfragen verschiedene Möglichkeiten auszuwählen. Der Umfang dieser Variabilität ist jedoch durch vorherige Festlegungen eingeschränkt. Die hinteren Bindungszeitpunkte werden auch unter dem Begriff Configuration Management zusammengefasst. Alle Bindungszeitpunkte werden als Variability in border sense bezeichnet.

7 2 Feature Modellierung 2.1 Definition Feature Modelle sind eine einfache Möglichkeit Produktlinien zu modellieren. Features werden in einer Baumstruktur dargestellt. An der Wurzel des Baumes steht das Konzept C, das modelliert werden soll. Unterhalb davon sind die Features, die zu diesem Konzept gehören dargestellt. Die genaue Definition eines Feature Models nach [Czar] Kapitel 5.4. lautet: A feature model represents the common and the variable features of concept instances and the dependencies between the variable features. Ein Feature kann ebenfalls aus Subfeatures zusammengesetzt werden. Jedes Feature kann optional oder verpflichtend sein. Optionale Features werden durch einen weißen Kreis dargestellt, verpflichtende durch einen schwarzen Kreis. 2.2 Möglichkeiten der Feature Modellierung Es gibt auch Auswahlmöglichkeiten zwischen den einzelnen Subfeatures: Ist ein Feature F entweder aus dem Subfeature S1 oder aus dem Subfeature S2 oder aus beiden zusammengesetzt, befindet sich ein schwarz ausgefüllter Bogen zwischen S1 und S2. Diese Features werden als OR-Features bezeichnet. Besteht ein Feature F entweder aus dem Subfeature S1 oder aus dem Subfeature S2 und in keinem Fall aus beiden Features, wird dies mit einem Bogen zwischen S1 und S2, der nicht ausgefüllt ist, dargestellt. Diese Features heißen alternative features. Beide Auswahlmöglichkeiten können auch über Gruppen (sets) von Subfeatures erfolgen: In der folgenden Darstellung haben wir zwei Gruppen {S1, S2} und {S3, S4} von OR-Features. Das Feature F1 kann entweder aus S1 oder S2 oder beiden und entweder aus S3 oder S4 oder beiden bestehen. F1 kann sich daher aus zwei, drei oder vier Subfeatures zusammensetzen. Abbildung 4: Feature mit zwei Gruppen von OR-Features Besteht F1 aus zwei Subfeatures, ergeben sich vier Möglichkeiten: (S1, S3), (S1,S4), (S2,S3), (S2,S4). Setzt sich F1 aus drei Subfeatures zusammen, gibt es folgende Möglichkeiten: (S1, S2, S3), (S1, S2, S4), (S1, S3, S4), (S2, S3, S4). Vereint F1 vier Features unter sich, ergibt sich nur noch die Möglichkeit: (S1, S2, S3, S4). Ingesamt ergeben sich neun mögliche Zusammensetzungen von F1. Im folgenden Bild setzt sich das Feature F2 nur aus zwei Subfeatures zusammen, da entweder S1 oder S2 und entweder S3 oder S4 Bestandteil von F2 sind:

8 Abbildung 5: Feature mit zwei Gruppen von alternative features S1 und S2 sind alternative features. Die möglichen Zusammensetzungen von F2 entsprechen den oben genannten Zusammensetzungen von F1 aus zwei Subfeatures. OR-Features können auch mit alternative features ausgedrückt werden. 2.3 Featuremodellierung am Beispiel eines Autos In der folgenden Graphik ist am Beispiel des Konzepts Auto eine Featuremodellierung dargestellt: Abbildung 6: Featuremodellierung des Konzepts Auto

9 Das Auto besteht aus den verpflichtenden Features Motor, Karosserie, Lenkung und Komfort und aus dem optionalen Feature Anhänger. Die Lenkung kann entweder durch ein Schaltgetriebe oder durch eine Automatikschaltung erfolgen, jedoch nicht durch beide Varianten. Das Auto hat entweder einen Benzin- oder einen Elektromotor oder beide Motoren parallel. Bei der Komfortausstattung des Autos kann der Kunde zwischen einem normalen Radio oder einem Radio mit CD player wählen. Das Produkt enthält immer eines der beiden Features. Außerdem hat der Kunde die Wahl zwischen einer einfachen Heizung oder einer Heizung mit Klimaanlage. Das Radio kann Lautsprecher hinten oder vorne oder hinten und vorne gleichzeitig haben. Außerdem kann das Display des Radios die Uhrzeit, den aktuell eingestellten Sender oder beides anzeigen. 2.4 Features und AOP Die Abkürzung AOP steht für aspektorientiert Programmierung. Bei der aspektorientierten Programmierung wird ein Aspekt beim Methodenaufruf in die ursprüngliche Methode quellmethod() eingebunden. Die Stelle, an der der Aspekt eingebunden wird, bezeichnet man als Joint Point. Die folgende aus [Wiki] übernommene Graphik zeigt diesen Ablauf: Abbildung 7: Ablauf Aspektorientierte Programmierung Jede Modellierungstechnik bietet besondere Vorteile. Um jedes Problem so effektiv wie möglich modellieren zu können, bietet sich die Integration verschiedener Modellierungstechniken, besonders der Aspektorientierten und der Featuremodellierung, an. Ein Beispiel dafür die DEMRAL (Domain Engineering Method for Algorithmic Libraries). DEMRAL verbindet vier Modellierungstechniken: Modulare Modellierung (Modular Decomposition) beinhaltet abstract data types (ADTs) und Algorithmen als Konzepte. Aspektorientierte Modellierung (Aspectual Decomposition) wird in DEMRAL zusammen mit der Feature Modellierung angewendet. Jedes Konzept wir in Aspekte zerlegt. Featuremodellierung (Feature Modelling) wird auf jeden Aspekt angewendet.

10 Subjektive Modellierung (Subjective Decomposition) betrachtet das System aus verschiedenen Perspektiven z.b. der Nutzer- oder der Entwicklerperspektive. In DEMRAL wird jedes Konzept C wird als eine Menge von Aspekten modelliert. Die einzelnen Aspekte werden danach aus Features zusammengesetzt. Die folgende Darstellung zeigt diesen Vorgang: Abbildung 8: Features und Aspektorientierte Programmierung Der Entwicklungsprozess ist rekursiv und wird ständig verbessert. Eine genauere Beschreibung von DEMRAL findet man in [Czar] Kapitel 9.

11 3 Einführung in PuLSE 3.1 Was ist PuLSE? Definition PuLSE bedeutet Product Line Software Engineering (PuLSE) und ist eine Methode zur Konzeption und Entwicklung von Produktlinien. PuLSE kann sich einfach an eine vorgegebene Projektumgebung anpassen und ist daher in vielfältigen Projekten einsetzbar. Die Methode umfasst den gesamten Entwicklungszyklus einer Produktlinie Eigenschaften und Entstehung PuLSE zeichnet sich durch folgende Eigenschaften aus: Das Produkt steht im Mittelpunkt. Die einzelnen Komponenten sind leicht anpassbar. Die Modellierung kann schrittweise erweitert werden. Eine ständige Verbesserung ist möglich und erwünscht. Einige grundlegende Entwicklungssituationen sind vordefiniert. Frühere Methoden zur Entwicklung von Produktlinien waren schwer anwendbar und boten keine Unterstützung von Instanzen an. Der Einsatz einer Produktlinie bietet jedoch in vielen Bereichen Vorteile, die in Kapitel eins bereits erläutert wurden. Um die Produktlinienmodellierung zu fördern und populärer zu machen, wurde PuLSE im Jahr 2000 am Fraunhofer IESE entwickelt. PuLSE bietet Lösungen für beide oben genannten Probleme: Es ist einfach anwendbar und unterstützt Instanzen. 3.2 Komponenten von PuLSE Überblick über alle Komponenten Die folgende Darstellung bietet einen Überblick über alle Komponenten von PuLSE: Abbildung 9: Komponenten von PuLSE

12 Links oben sind unter deployment phases alle logischen Abschnitte im Lebenszyklus einer Produktlinie dargestellt. Die einzelnen Abschnitte umfassen die Erschaffung, Benutzung und Weiterentwicklung der Produktlinie. Rechts oben in der Graphik befinden sich unter technical components alle technischen Komponenten, die die unter deployment phases definierten Abschnitte realisieren und mit Inhalt füllen. Die technische Komponente und der unter deployment phases definierte Abschnitt sind jeweils in derselben Farbe dargestellt. In der Graphik werden nur die Abkürzungen der einzelnen Komponenten verwendet. Die vollständigen Namen lauten: BC Eco CDA DSSA I EM Base lining and Customization Economic scoping Customizable Domain Analysis Domain Specific Software Architecture Development Instantiation Evolution and Management Die drei Komponenten unter support components dienen der Unterstützung der anderen Komponenten und der Entwicklungsphasen Deployment Phases Im Folgenden möchte ich einen Überblick über alle Deployment Phases geben: In der Initialisierungsphase ( Initialisation ), in der Graphik rot dargestellt, werden die Projektstruktur und die Organisation der Produktlinie festgelegt. Dazu gehören z.b. Vereinbarungen, ob andere Methoden z.b. KobrA zur Unterstützung von PuLSE verwendet werden. Schon in dieser Phase sollte der Aspekt der Widerverwendbarkeit eine große Rolle spielen. PuLSE-BC realisiert diese Entwicklungsphase. Die Entwicklungsphase Product line infrastructure construction, in der Graphik gelb dargestellt, ist die umfangsreichste im gesamten Entwicklungsprozess, weil in diesem Stadium die Produktlinie entsteht und modelliert wird. Am Ende dieses Prozesses steht die vollständige Produktlinienarchitektur. Bei der Modellierung müssen alle Rahmenbedingungen berücksichtigt werden. Product line infrastructure construction wird durch drei technische Komponenten realisiert: PuLSE-Eco, PuLSE-CDA, PuLSE- DSSA Um ein einzelnes Produkt oder eine einzelne Produktausführung aus einer Produktlinie zu kreieren, benötigt man die Phase Product line infrastructure usage, die in der Graphik grün dargestellt ist. Diese Entwicklungsphase stellt eine wesentliche Verbesserung im Gegensatz zu früheren Methoden zur Produktlinienmodellierung, die meistens keine Instanzenunterstützung vorweisen konnten, dar. PuLSE-I realisiert diese Phase. Product line infrastructure evolution unterstützt alle anderen Komponenten und garantiert die langfristige Nutzung und die ständige Verbesserung und Weiterentwicklung der Produktlinie. Sie wird durch PuLSE-EM, in der Graphik türkis dargestellt, realisiert Technical Components Die folgende Tabelle zeigt einen Überblick über alle technischen Komponenten und ihre Aufgaben. Im Weiteren wird jede Komponente einzeln vorgestellt.

13 Technical component Base lining and customization (BC) Economic scoping (Eco) Customizable domain analysis (CDA) Domain specific software architecture development (DSSA) Instantiation (I) Evolution and management (EM) Aufgaben PuLSE auf die Grundvoraussetzungen der Applikation ausrichten Identifikation, Beschreibung, Binden der Produktlinie Herausfiltern der Anforderungen einer Domain, Betrachten der Domain aus verschiedenen Sichtweisen Entwickeln einer Referenzarchitektur und (optional) eines Prototypen Spezifizieren, Konstruieren und Verifizieren eines Mitgliedes der Produktlinie Unterstützung von PuLSE in allen anderen Entwicklungsphasen Die technischen Komponenten realisieren die Entwicklungsphasen und bilden zusammen eine Kette. Die folgende Graphik zeigt den Zusammenhang zwischen den einzelnen Komponenten: Abbildung 10: Zusammenhang der technischen Komponenten von PuLSE In der oberen Graphik sind alle Komponenten, die zur Initialisierung (Initialisation) gehören, rot, alle Komponenten und Modelle, die zur Infrastructure Construction Phase gehören, gelb, und alle Komponenten und Modelle, die zur Infrastructure Usage Phase gehören, grün dargestellt. Alle Rechtecke beinhalten Komponenten, alle Ellipsen Modelle. Die von den einzelnen Komponenten erstellten Modelle stehen auf den von ihnen wegführenden Pfeilen und werden an alle nachfolgenden Komponenten weitergegeben. Der gestrichelte Pfeil führt zu einem optionalen Modell. PuLSE-BC erhält eine Anforderungsbeschreibung (description), erstellt daraus eine Instanz von PuLSE (instance of PuLSE) und gibt diese an PuLSE-Eco weiter. In der Instanz von PuLSE kann z.b. die Verwendung der KobrA Methode festgelegt sein.

14 In PuLSE-Eco beginnt die eigentliche Modellierung der Produktlinie: Zusätzlich zu der von BC erzeugten Instanz erhält Eco eine Produkttabelle (Product map). Aus diesen Informationen modelliert Eco eine Rahmendefinition (scope definition) und eine genaue Produktbeschreibung (product characteristic information). PuLSE-CDA generiert das Domain und das Domain Decision Model und reicht beide Modelle an PuLSE-DSSA und PuLSE-I weiter. PuLSE-DSSA erzeugt einen optionalen Prototyp und die Architektur der Produktlinie (architecture decision model). PuLSE-I kann mehrfach auf der bestehenden Architektur angewendet werden, um neue Produkte zu erzeugen. Es erstellt ein Mitglied der Produktlinie (member of the product line). PuLSE-Eco, PuLSE-CDA und PuLSE-DSSA werden in den folgenden Kapiteln genauer beschrieben PuLSE-Eco Ein Resultat von PuLSE-Eco ist die Produktbeschreibung (product characteristic information), die ich hier an einem Beispiel kurz vorstellen möchte. In unserem Beispiel betrachten wir das Getriebe und die Kommunikation in einem Auto. Die folgende Tabelle zeigt die Produktbeschreibung unseres Autos: Area Feature NT Getriebe Kommunikation Cars Schaltung X X Automatik Radio normal X X Radio mit CD player Satellitennavigation X X Die erste Spalte beinhaltet die einzelnen Bereiche des Autos (Area) und stellt eine grobe Einteilung dar. In der zweiten Spalte wird die Einteilung verfeinert. Hier stehen alle Features, die zum jeweiligen Bereich gehören. Die Bezeichnung NT in der dritten Spalte steht für Not Typical (ungebräuchlich). Kann ein Feature eventuell auch in einem anderen Bereich (Area) eingeordnet werden, trägt diese Spalte ein Kreuz. Das Feature Satellitennavigation in unserem Beispiel könnte man auch in einem eigenen Bereich einordnen. In der vierten und fünften Spalte stehen zwei Produkte A und B der Produktlinie. Kann ein Produkt ein bestimmtes Feature enthalten, steht in der Tabelle ein Kreuz. Ansonsten steht in der Tabelle ein leeres Feld. In unserem Beispiel enthält das Auto A die möglichen Features Schaltung, Automatik und Radio normal. Das Auto B kann nur mit Schaltung und nicht mit Automatik geliefert werden. Dafür kann B ein normales Radio, ein Radio mit CD player und ein Satellitennavigationssystem enthalten. Weitere Beispiele für PuLSE-Eco findet man in der GoPhone Case Study [Muth1] PuLSE-CDA PuLSE-CDA kann durch die KobrA Methode, die in Kapitel drei vorgestellt wird, unterstützt werden. CDA erzeugt ein Domain und ein Domain Decision Model. Ein Beispiel für ein Domain Decision Model möchte ich hier kurz vorstellen. Der folgende Prozessgraph enthält den Variation Point CD player. A X B X

15 Music Radio <<variant>> CD player Das dazugehörige Decision Model wird als Tabelle dargestellt: ID Question Variation Point Resolution Effect 1 Process CD player supported? CD player yes no Remove stereotype <<variant>> Remove Process CD player Die erste Spalte enthält eine Nummer (ID) für jeden Variation Point. In der dritten Spalte steht der Variation Point, ein kurzer Name, der die Entscheidungsmöglichkeit charakterisiert und durch die Frage (Question) in der zweiten Spalte genauer definiert wird. Das Feld Resolution hat nur zwei mögliche Einträge: yes oder no. Effect beschreibt die Handlung, die auf eine bestimmte Entscheidung (Resolution) folgt. In unserem Beispiel ergibt sich der linke Prozessgraph, wenn der Variation Point unterstützt wird d.h. in der Spalte Resolution yes steht, und der rechte Prozessgraph, wenn als Entscheidung (Resolution) no festgelegt wurde: Music Music Radio CD player Radio Das Tool Diversity / CDA unterstützt den Entwicklungsprozess von PuLSE-CDA. Die folgende Abbildung wurde aus [Bayer2] entnommen und zeigt den Zusammenhang zwischen PuLSE und anderen Komponenten: Abbildung 11: Ablauf von PuLSE-CDA

16 PuLSE-CDA hat drei Hauptaufgaben: refine scope definition, elicit raw domain knowledge und model domain knowledge. Refine scope definition legt die Grenze der Produktlinie fest. Im zweiten Schritt elicit raw domain knowledge sammelt man das gesamte über die einzelnen Produkte und die Produktlinie vorhandene Wissen. Die gesammelte Information wird unstrukturiert festgehalten (raw work products). Im dritten und letzten Schritt model domain knowledge wird die nicht strukturierte Information modelliert (model domain knowledge) und es entstehen das domain model und das domain decision model. Werden der bei Modellierung zusätzliche, bisher nicht berücksichtigte Informationen benötigt, beginnt man wieder bei Schritt zwei. PuLSE-EM sendet Aufträge (tasks) an CDA, die CDA bei der Modellierung berücksichtigt muss, und CDA kann Änderungsanforderungen für andere Komponenten (change requests) an EM senden. Der genaue Zusammenhang zwischen CDA und EM wird in Kapitel beschrieben. Eine genaue Beschreibung von PuLSE-CDA findet man unter [Bayer2] PuLSE-DSSA Auch PuLSE-DSSA kann durch die in Kapitel drei beschriebene KobrA Methode unterstützt werden. Die folgende Graphik zeigt stark vereinfacht den Ablauf von PuLSE-DSSA: Abbildung 12: Ablauf von PuLSE-DSSA Alle Ellipsen in der Graphik enthalten Modelle, alle Rechtecke Prozesse.

17 Als Eingabe erhält DSSA die scope definition aus Eco und das domain decision model und das domain model aus CDA. Aus dem domain model erzeugt DSSA Szenarios, die mögliche Abläufe im System beschreiben (create scenarios). Die entstandenen Szenarios werden anschließend nach ihrer Relevanz für die korrekte Funktion des Systems geordnet (select scenarios with highest significance). Als Informationsquelle dient dabei die scope definition. Beginnend mit dem wichtigsten Szenario werden nun alle Szenarien nacheinander ins System integriert (apply scenario to architecture). Bei der Anwendung eines Szenarios auf das System wird dafür gesorgt, dass alle vorher ins System integrierten Szenarien ihre Gültigkeit behalten. Wenn alle Szenarien auf das System angewendet wurden, steht das architecture decision model. Die konkrete Anwendung von PuLSE-DSSA und PuLSE-CDA hängt davon ab, welche weiteren Methoden z.b. KobrA verwendet werden. Eine genauere Beschreibung von PuLSE-DSSA findet man unter [Anas1] PuLSE-EM PuLSE-EM hat drei Aufgaben: Evolution, Management und Learning. EM steht zwischen allen anderen Komponenten und hat den Überblick über alle Bereiche. Evolution beinhaltet die Verbesserung aller Komponenten im laufenden Entwicklungsprozess. PuLSE- EM kann als eine Art Koordinator für alle anderen Komponenten verstanden werden. Die folgende Graphik zeigt die Beziehung zwischen EM und allen anderen Komponenten: BC Eco Information (evolution) EM task (evolution) I CDA DSSA change request Abbildung 13: Evolution und Management bei PuLSE-EM Beim Evolution Prozess übergeben alle anderen Komponenten ihre Ergebnisse und Informationen an EM. Dieser Vorgang wird durch die durchgängigen schwarzen Pfeile dargestellt. EM vergleicht alle Ergebnisse miteinander und erkennt sich widersprechende Modellierungen und Aussagen. In PuLSE- EM werden sinnvolle Änderungen zur Behebung von Unstimmigkeiten erarbeitet und an die betroffenen Komponenten zur Umsetzung weitergeleitet. Die roten Pfeile stellen diesen Vorgang dar. Beim Management werden von anderen Komponenten empfangene change requests bearbeitet. Ist der Änderungsvorschlag sinnvoll, wird er an die zuständige Komponenten weitergeleitet. Die gestrichelten Pfeile charakterisieren diesen Ablauf. Learning ist ein theoretisch unendlicher Prozess, der in der folgenden Abbildung dargestellt ist:

18 Abbildung 14: Learning bei PuLSE-EM Auf der linken Seite steht die eigentliche Entwicklung, die ihre Ergebnisse an die rechte Optimierungsseite, die von EM realisiert wird, weitergibt. Die von EM vorgeschlagenen Verbesserungen erhält die linke Seite und der Vorgang startet erneut Support Components Die Support Komponente Project Entry Points stellt Startpunkte für einige Standartsituationen bereit und realisiert damit einige grundlegende vordefinierte Entwicklungssituationen, die in Kapitel bereits als entscheidender Vorteil von PuLSE vorgestellt wurden. Maturity Scale beinhaltet das Qualitätsmanagement von PuLSE. Sie erkennt und verbessert Schwachpunkte. Vorschläge für die betriebliche Organisationsstruktur bei einem Einsatz von PuLSE findet man unter Organizational Issues.

19 4 Überblick über KobrA 4.1 Definition und Eigenschaften KobrA ist eine Modellierungsmethode, die Text basierte, UML basierte und graphische Modelle verwendet. Der Entwicklungsprozess der KobrA Methode ist rekursiv: Aus einem vorherigen Entwicklungsschritt wird ein nachfolgender Entwicklungsschritt generiert. Stellt man im nachfolgenden Entwicklungsschritt fest, dass der vorherige Entwicklungsschritt die Anforderungen nicht oder nicht optimal erfüllt, werden beide Entwicklungsschritte weiter verbessert. Dieser Prozess kann theoretisch unendlich lange laufen. Die KobrA Methode modelliert die gegebenen Anforderungen so konkret wie möglich und trennt strikt zwischen Prozessen und Produkten. 4.2 Bezug zu PuLSE Die KobrA Methode stellt eine Objekt orientiert Anwendung von PuLSE dar. Jede Entwicklungsphase von PuLSE kann mit einer KobrA activity modelliert werden. Die folgende Tabelle zeigt die Zusammenhänge zwischen Entwicklungsphasen von PuLSE und KobrA Aktivitäten: PuLSE development phase Infrastructure construction phase KorbA activity Framework engineering activity Infrastructure usage phase Application engineering activity Product line evolution phase Maintenance of frameworks and applications 4.3 Activities KobrA einhält die beiden Aktivitäten Framework Engineering und Applikation Engineering. Zuerst wird mit Hilfe des Framework Engineering die Produktlinie modelliert. Diese Aktivität ist mit dem als Domain Engineering bezeichneten Prozess in Kapitel 1.1 vergleichbar. Danach erhält das Applikation Engineering die Resultate des Framework Engineering und erzeugt daraus ein konkretes Produkt. Das Applikation Engineering ist mit dem Product Engineering genannten Prozess in Kapitel 1.1 vergleichbar Framework engineering Die folgende Graphik stellt alle Bestandteile des Framework Engineering dar:

20 Abbildung 15: Modelle beim Framework Engineering in KobrA Alle in der Graphik enthaltenen UML Modelle sind grün dargestellt. Die gestrichelten Pfeile führen zu optionalen Bestandteilen. Beim Framework Engineering werden zuerst einzelne Komponenten, die miteinander in Beziehung stehen, gebildet. Die Context Realisation setzt die Rahmenbedingungen für das Framework. Ihre genaue Struktur hängt vom einzelnen Projekt ab und ist in KobrA nicht fest vorgegeben. Die einzelnen Komponenten sind in einer baumartigen Struktur organisiert. Für jede Komponenten werden danach ihre Spezifikation und ihre Realisation modelliert. Die Spezifikation beinhaltet alle extern sichtbaren Funktionen der Komponente, die Realisation beschreibt die interne Realisierung der Komponente. Um die Graphik übersichtlich zu gestalten wurden die Spezifikation und die Realisation nur für die Komponente zwei dargestellt. Die Spezifikation besteht aus vier Modellen, die in der obigen Graphik blau dargestellt sind: Das Decision Model stellt die verschiedenen Varianten der Komponente dar. Das Structural Model beschreibt in welchem Zusammenhang die Komponente zu anderen Komponenten steht und beinhaltet ein UML Klassendiagramm und optional ein UML Object Diagram. Das Behavioural Model beschreibt die Reaktion der Komponente auf externe Aufrufe und setzt sich aus mehreren UML Statecharts Diagrammen und einer optionalen Event Map zusammen. Das Functional Model beinhaltet die externen Effekte nach dem Aufruf einer Operation, die die Komponente zur Verfügung stellt, und setzt sich aus mehreren UML operation schemata zusammen. Die Spezifikation wird vom Decision Model über das Structural und Behavioural Model bis hin zum Functional Model immer weiter verfeinert.

21 Die Realisation setzt sich aus dem Decision Model, den Activity Diagrams, den Interaction Models und dem Structural Model zusammen. Alle genannten Modelle sind in der obigen Graphik rot dargestellt. Das Decision Model wurde bereits oben beschrieben. Die Activity Diagrams bilden einen Übergang zwischen den Functional Models der Spezifikation, d.h. den Operation Schemata, und den Interaction Models. Für jede Operation Schemata wird ein Activity Diagram erstellt. Die Interaction Models beschreiben die Kommunikation von Objektgruppen zur Laufzeit. Ein Interaction Model ist entweder ein UML Collaboration Model oder ein UML Sequence Diagram. Das Structural Diagram beinhaltet die Architektur der Komponente und wird durch mehrere UML Klassen- und Objektdiagramme realisiert. Die Komponentenrealisation dient der Erzeugung von Unterklassen und deren Modellierung Application engineering Ziel des Application Engineering ist es ein Produkt zu erstellen, das die Wünsche des Kunden voll befriedigt. Das Application Engineering erfolgt, wenn das Framework Engineering bereits abgeschlossen wurde. Die folgende Graphik zeigt den Ablauf des Application Engineering in KobrA: Abbildung 16: Application Engineering bei KobrA Das Application Engineering kann in zwei Stufen unterteilt werden: die Application Context Realisation, in der Graphik gelb dargestellt, und die Framework Instantiation, in der Graphik grün dargestellt. Der Kunde (Customer) und ein Firmenmitarbeiter im technischen Vertrieb oder in der Kundenberatung (Consultant) legen im gemeinsamen Gespräch die Anforderungen für das Produkt fest. Der Mitarbeiter instanziiert anhand der Kundenentscheidungen das Framework (instantiate framework) und integriert neue Anforderungen (integrate new requirements). Am Ende legt der Vertriebsmitarbeiter die im Framework notwendigen Entscheidungen (Context Decisions) fest. Treten dabei Probleme auf, erfolgt eine erneute Absprache mit dem Kunden. Probleme können zum Beispiel Konflikte zwischen verschiedenen Anforderungen sein. Die Entwickler (Developer) erhalten die festgelegten Entscheidungen und passen danach die Basissoftware an. Der Kunde kann auch völlig neue Features bestellen, wenn für seine Anforderungen keine andere Lösung gefunden werden kann. Diese Features werden ebenfalls von den Entwicklern umgesetzt. Am Ende steht das fertige vom Kunden gewünschte Produkt (concrete realisation).

22 5 Aktueller Einsatz PuLSE wird sowohl in der Industrie als auch in der Wissenschaft und Forschung eingesetzt. In der Industrie wurde bei der maxess systemhaus GmbH ein Warewirtschaftssystem, das WWS 2000 genannt wird, modelliert. Sechs kleineren und mittleren Unternehmen setzten PuLSE ein, um ihre Softwarepalette auszudehnen. Auch RAMSIS, ein von der tecmath AG entwickeltes Simulationssystem für den menschlichen Körper, wurde mit PuLSE modelliert. Mit dem 3D-CDA-Werkzeug RAMSIS können Cockpitumgebungen und Fahrzeuginnenräume ergonomisch gestaltet werden. [RAM] Über PuLSE wurden viele wissenschaftliche Arbeiten verfasst. Die meiste Literatur findet man beim Fraunhofer IESE, die PuLSE auch entwickelt haben. PuLSE wird weiterentwickelt und ständig verbessert. Ein aktuelles Forschungsprojekt über PuLSE ist ESAPS, Café, ein europäisches Verbundprojekt. Unter [Cafe] findet man weitere Informationen. In der GoPhone Case Study wird die PulSE Methode an einem fiktiven Beispiel eines Mobilfunkanbieters angewendet. In der Quelle [Muth1] wird die GoPhone Case Study, ein abgeschlossenes Forschungsprojekt, beschrieben. Information zur aktuellen Forschung und zu Ansprechpartnern findet man auf der Website des Fraunhofer Institutes [Fraun] und im PuLSE Flyer [Muth2].

23 6 Literatur [Anas1] Michalis Anastasopoulos, Joachim Bayer, Oliver Flege, Cristina Gacek, A Process for Product Line Architecture Creation and Evaluation, PuLSE-DSSA Version 2.0, IESE-Report No /E, Version 1.0, Fraunhofer IESE, Kaiserslautern, [Bayer1] Joachim Bayer, Oliver Flege, Peter Knauber, Roland Laqua, Dirk Muthig, Klaus Schmid, Tanya Widen, Jean-Marc DeBaud, PuLSE: A Methodology to Develop Software Product Lines, Fraunhofer IESE, Kaiserslautern, 05 / [Bayer2] Joachim Bayer, Dirk Muthig, Tanya Widen, Customizable Domain Analysis, Fraunhofer IESE, Kaiserslautern, 09/1999. [Cafe] [Czar] [Fraun] [Mar] [Muth1] [Muth2] [RAM] Homepage des Café Projektes, [aufgerufen am ] Krzysztof Czarnecki, Generative Programming, principles and techniques of software engineering based on automated configuration and fragment-based component models, Ilmenau, 1998 Fraunhofer Institut Experimentelles Software Engineering, Product & Services: PuLSE, URL: [aufgerufen am ] Market Maker Software AG, i*-product Line, kurzer Film zum Thema Produktlinien, URL: [aufgerufen am ] Dirk Muthig, Isabel John, Michalis Anastasopoulos, Thomas Forster, Jörg Dörr, Klaus Schmid, GoPhone A Software Product Line in the Mobile Phone Domain, IESE-Report No /E, Version 1.0, Fraunhofer IESE, Kaiserslautern, Dr. Dirk Muthig, PuLSE Product Lines for Software Systems, PuLSE Flyer, Kaiserslautern, 03/2003 RAMSIS, 3D-CAD-Ergonomiewerkzeug, Human Solutions, Kaiserslautern, URL: [aufgerufen am ] [Reiser] Mark-Oliver Reiser, Vorlesungsfolien, [Soft] [Wiki] Software Engineering Kompetenzzentrum, Stichwort: PuLSE, URL: [aufgerufen am ] Wikipedia, Die freie Enzyklopädie, Stichwort: AOP, URL: [aufgerufen am ].