Software Produktlinien                                     ¨                      Einfuhrung und Uberblick                ...
Definition von Software Produktlinen. Der Abschnitt 3.1 behandelt die Syste-martefakte, welche die Grundbausteine der Softw...
ner Produktfamilie auszusch¨pfen, indem die dazu n¨tige Infrastruktur geschaf-                             o              ...
temartefakte sind daher die Grundbausteine der Produktlinie zur Erstellung derSoftwareprodukte. Eine besondere Bedeutung k...
Gemeinsamkeiten zwischen den Softwareprodukten der Produktlinie zu identifi-zieren. Featuregraphen werden dazu genutzt um A...
bedeutet, dass das Receive Message Feature das Pop3 oder aber das IMAP Fea-ture zum Empfangen von E-Mails verwenden kann. ...
3.4   Produktlinien ArchitekturEine explizit definierte Produktlinienarchitektur ist von zentraler Bedeutung f¨r           ...
Domain Engineering Das Domain Engineering stellt den zentralen Teilprozessdes Produktlinien Engineering dar. In ihm wird d...
Management Das Management ist der zentrale Teilprozess des ProduktlinienEngineering, der die beiden anderen Prozesse unter...
eine hohe Vorabinvestition n¨tig, um eine Produktlinie erfolgreich einzuf¨hren.                             o             ...
Nächste SlideShare
Wird geladen in …5
×

Software Produktlinien: Einführung und Überblick (Ausarbeitung)

752 Aufrufe

Veröffentlicht am

0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
752
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
9
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Software Produktlinien: Einführung und Überblick (Ausarbeitung)

  1. 1. Software Produktlinien ¨ Einfuhrung und Uberblick ¨ Johannes Diemke Universit¨t Oldenburg a Department f¨r Informatik u 26111 Oldenburg ¨ Zusammenfassung Dieser Artikel soll einen Uberblick uber den Soft- ¨ ware Produktlinien Ansatz verschaffen. Zu diesem Zweck werden die grundlegenden Konzepte, Vorteile und Herausforderungen von Softwa- re Produktlinien beschrieben. Dazu wird der Begriff der systematischen Wiederverwendung eingef¨hrt. Darauf aufbauend folgt die g¨ngige De- u a finition von Software Produktlinien. Es wird auf die drei zentralen Pro- zesse Domain Engineering, Application Engineering und Management eingegangen. Des Weiteren werden Begriffe wie Produktraum, Systemar- tefakte und Variablit¨t im Zusammenhang mit Produktlinien erl¨utert. a a Schließlich wird die Produktlinienarchitektur betrachtet und der Softwa- re Produktlinien Ansatz bewertet.1 Einfuhrung ¨Die steigende Komplexit¨t und Gr¨ße zu entwickelnder Softwaresysteme ist ein a ogegenw¨rtiges Problem der Software-Technik. Softwaresysteme sollen immer leis- atungsf¨higer, zuverl¨ssiger, komplexer, gleichzeitig aber immer g¨nstiger in Pro- a a uduktion und Wartung sowie schneller in Entwicklung und Auslieferung werden.Die systematische Wiederverwendung von Software erm¨glicht es diese scheinbar ounvereinbaren Ziele zu erreichen. Insbesondere hat sich gezeigt, dass gerade dieEntwicklung von Software Produktlinien einen der leistungsf¨higeren Ans¨tze a ader systematischen Wiederverwendung darstellt [8]. Die Realit¨t sieht jedoch anders aus. Der g¨ngige Ansatz zur Erstellung von a aSoftwareprodukten in Unternehmen beruht meist darauf, f¨r jedes durchzuf¨h- u urende Projekt ein eigenes Projektteam mit eigenem Budget zusammenzustel-len, welches isoliert von den anderen Teams die Entwicklung beginnt. Dadurchkommt es jedoch nicht selten zu mehrfacher und redundanter Durchf¨hrung uverschiedener Arbeiten der unterschiedlichen Projektteams. Genau dieser Pro-blematik versucht der Software Produktlinien Ansatz entgegenzuwirken [9]. Dieser Artikel beschreibt die grundlegenden Konzepte, Vorteile und Heraus-forderungen von Software Produktlinien. Da der Software Produktlinien Ansatzauf dem Konzept der systematischen Wiederverwendung beruht, wird in Ab-schnitt 2 dieses zun¨chst eingef¨hrt und auf dessen Nutzen eingegangen. An- a uschließend folgt in Abschnitt 3 nach einer einf¨hrenden Motivation die g¨ngige u a
  2. 2. Definition von Software Produktlinen. Der Abschnitt 3.1 behandelt die Syste-martefakte, welche die Grundbausteine der Software Produktlinie darstellen. Ein ¨kurzer Uberblick uber den Produktraum und dessen Beschreibung wird in Ab- ¨schnitt 3.2 gegeben. Abschnitt 3.3 beschreibt die Rolle der Variablit¨t in Soft- aware Produktlinien, M¨glichkeiten Variablit¨t mit Hilfe von Produkt×Feature- o aTabellen und Feature-Graphen zu beschreiben und f¨hrt den Begriff des Varia- utionspunkts ein. Daraufhin wird in Abschnitt 3.4 der grundlegende Unterschiedzwischen Softwarearchitekturen von Individualsoftware und Produktlinienarchi-tekturen der sich zum großen Teil daraus ergibt, dass eine Produktlinienarchi-tektur die Referenz f¨r alle Produkte der Produktline darstellt und gewisse Va- uriablit¨tsaspekte ber¨cksichtigt werden m¨ssen, beschrieben. Schließlich wird in a u uAbschnitt 3.5 auf die drei zentralen Prozesse Domain Engineering, ApplicationEngineering und Management eingegangen. Ein Fazit und eine abschließendeBewertung des Software Produktlinien Ansatzes folgt in Abschnitt 4.2 Systematische WiederverwendungDie Wiederverwendung ist ein schon lange verfolgter Ansatz, dessen Nutzen re-lativ fr¨h auch f¨r die Software-Technik erkannt wurde. Bei diesem Ansatz wer- u uden, wie in den meisten anderen technischen Disziplinen, im Entwurfsprozessvorgefertigte Komponenten, die schon in anderen Systemen getestet wurden, ge-nutzt. Vorteile der Wiederverwendung sind geringere Entwicklungskosten, eineh¨here Zuverl¨ssigkeit und eine beschleunigte Entwicklung. Um eine systema- o atische Wiederverwendung zu erreichen, muss diese allerdings fr¨hzeitig in den uEntwurfsprozess mit einbezogen werden und richtig geplant sein [8]. Zu diesem Zweck wurden im Laufe der Zeit eine Reihe von Konzepten entwi-ckelt, welche von der Wiederverwendung einzelner Funktionen bis hin zu ganzenAnwendungssystemen reichen. Das Konzept der Entwurfsmuster bietet beispiels-weise dom¨nenunabh¨ngige und generische L¨sungsschemata f¨r wiederkehrende a a o uEntwurfsprobleme. Mit den Referenzarchitekturen werden dom¨nenabh¨ngige a aund generische Softwarearchitekturen geboten. Die in den sp¨ten 90er Jahren aaufkommende komponentenbasierte Software-Technik konzentriert sich schließ-lich darauf, Softwaresysteme aus abstrakten, lose gekoppelten und wiederver-wendbaren Komponenten zu entwerfen [6].3 Software ProduktlinienEinen ¨ußerst leistungsf¨higen Ansatz zur systematischen Wiederverwendung a astellen die Software Produklinien, welche gelegentlich auch als Anwendungsfa-milien bezeichnet werden, dar. Diesem Ansatz liegt zugrunde, dass sich Soft-warehersteller h¨ufig auf spezielle Anwendungsdom¨nen spezialisieren und f¨r a a udiese eine Reihe von Produktvarianten entwickeln. Produktvarianten haben abernaturgem¨ß eine gemeinsame Grundstruktur und eine Vielzahl ¨hnlicher Eigen- a aschaften. Dies zeichnet jedoch eine Produktfamilie aus. Ziel des Software Pro-duktlinien Ansatzes ist es nun das vorhandene Wiederverwendungspotential ei-
  3. 3. ner Produktfamilie auszusch¨pfen, indem die dazu n¨tige Infrastruktur geschaf- o ofen wird [6]. Da in einer Software Produktlinie jedes Produkt auch immer eine Produkt-variante darstellt, sind die Begriffe Produkt und Produktvariante im Kontexteiner Produktlinie als synonym anzusehen. Im Folgenden wird eine Definitionvon Software Produktlinien in Anlehnung an [7] gegeben. Dabei wird der bis-her allgemein gehaltene Begriff der Produktvariante weiter auf Produktvariantenvon softwareintensiven Systemen eingegrenzt.Definition 1. Eine Software Produktlinie (SPL) ist eine Menge von softwar-eintensiven Systemen, die sich eine Reihe von Systemartefakten teilen, einerspeziellen Anwendungsdom¨ne angeh¨ren und eine gemeinsame systemspezifi- a osche Architektur besitzen. Jedes dieser Systeme ist auf die eine oder andere Artspezialisiert, der gemeinsame Kern der Systeme wird jedoch jedesmal wiederver-wendet. Der Software Produktlinien Ansatz erm¨glicht so f¨r eine spezielle Anwen- o udungsdom¨ne die Erstellung einer Reihe von softwareintensiven Systemen auf aBasis einer Menge gemeinsam genutzter Systemartefakte, eines gemeinsamenProduktionsprozesses und einer konsequenten Aufbau- und Ablauforganisation.Die systematische Wiederverwendung der Systemartefakte wird dabei von An-fang an in den Entwurfsprozess mit einbezogen. Die gemeinsam verwendetenSystemartefakte beschr¨nken sich dabei nicht auf wiederverwendbare Software- akomponenten wie Abschnitt 3.1 zeigt. Der Software Produktlinien Ansatz kann durch eine Analogie zu traditionel-len Industriebereichen wie der Autoindustrie veranschaulicht werden. So strebenAutohersteller die Erstellung einer Menge von Kraftfahrzeugen an und versuchendabei die Unterschiede der in den Fahrzeugen verwendeten Bauteile m¨glichst ogering zu halten. Dies erm¨glicht ihnen eine breite Wiederverwendung von Kom- oponenten. In dieser Analogie ist dann die Anwendungsdom¨ne die Erstellung von aKraftfahrzeugen in der Autoindustrie, die zu erstellenden Produktvarianten sinddann die im Produktportfolio vorhandenen Kraftfahrzeuge und die gemeinsamgenutzen Systemartefakte, die in den Fahrzeugen teilweise gemeinsam genutztenBauteile [3]. Da sich der Software Produktlinien Ansatz jedoch nicht f¨r jede Menge von uSoftwareprodukten eignet, ist vor der Entwicklung einer Produktlinie in einerMachbarkeits- und Rentabilit¨tsanalyse gr¨ndlich zu pr¨fen, ob sich diese lang- a u ufristig finanziell rentiert und gen¨gend ¨hnliche Eigenschaften in der Produkt- u amenge vorhanden sind, die sich sinnvoll zu Systemartefakten abstrahieren undin die Produktlinie integrieren lassen [6]. Im Folgenden werden einige f¨r Softwareproduktlinien grundlegende Begriffe ueingef¨hrt und anschließend in Zusammenhang gebracht. u3.1 SystemartefakteKonkrete Produktvarianten softwareintensiver Systeme werden im ProduktlinienAnsatz durch das Ausw¨hlen und Anpassen von Systemartefakten erzeugt. Sys- a
  4. 4. temartefakte sind daher die Grundbausteine der Produktlinie zur Erstellung derSoftwareprodukte. Eine besondere Bedeutung kommt dabei den Softwarearchi-tekturen (siehe Abschnitt 3.4) zu, die spezielle Systemartefakte darstellen, wel-che erst eine Wiederverwendung und Organisation der anderen Systemartefakteim Großen erm¨glichen. Weitere Systemartefakte sind die gemeinsam genutzten oFeatures der Software Produktlinie. Dabei handelt es sich meistens um wie-derverwendbare Softwarekomponenten, Subsysteme, Module, Frameworks oderPlattformdienste [9]. Hier hat sich gezeigt, dass die komponentenbasierte Soft-ware Entwicklung die Realisierung von Software Produktlinien vereinfacht [6].Mindestens genauso wichtig wie die bisher genannten Artefakte sind jedoch Sys-temartefakte in Form von Dokumenten, die Erfahrungen und das angesammeltestrategische Wissen der Anwendungsdom¨ne wiederspiegeln. Dazu geh¨ren Ge- a osch¨ftsmodelle, Anforderungszpezifikationen, Projektpl¨ne, Budgets, Testf¨lle, a a adom¨nenspezifische Muster sowie Prozesse und Richtlinien [7]. a Jedes erstellte Systemartefakt ist ein Teil der Software Produktline und wirdin einem Artefaktkatalog inventarisiert. Die Systemartefakte, mit den f¨r ei- une Porduktvariante produktspezifischen Entscheidungen, dienen, wie in Abbil-dung 1 dargestellt, im Produktions-Prozess als Basis zur Erstellung neuer Pro-duktvarianten. Dabei sind die Systemartefakte und die produktspezifischen Ent-scheidungen die Eingaben des Produktions-Prozesses und die konkreten Pro-duktvarianten die Ausgaben. Systemartefakte Produktionsprozess Produktvarianten produktspezifische EntscheidungenAbbildung 1. Systemartefakte als Basis zur Erstellung neuer Produktvarianten [9].3.2 ProduktraumDer Produktraum definiert den Umfang einer Software Produktlinie. Dazu wer-den die zu der Software Produktlinie geh¨renden Produktvarianten aufgelistet ound beschrieben. Er wird, wie Abschnitt 3.5 noch zeigen wird, in der Scoping-phase des Domain Engineering Prozess entwickelt. ¨ Ublicherweise werden detailliert die Anforderungen und Unterschiede zwi-schen den einzelnen Produktvarianten einer Software Produktlinie sowie funk-tionale und nichtfunktionale Anforderungen, die diese Produkte an die Softwa-re Produktlinie stellen, dokumentiert. Produkt×Feature-Tabellen helfen dabei
  5. 5. Gemeinsamkeiten zwischen den Softwareprodukten der Produktlinie zu identifi-zieren. Featuregraphen werden dazu genutzt um Abh¨ngigkeiten zwischen ver- aschiedenen Features darzustellen [6]. Im folgenden Abschnitt 3.3 wird noch aufdie Verwendung von Featuregraphen anhand eines Beispiels eingegangen. Da-zu muss jedoch zun¨chst der Begriff des Features im Zusammenhang mit der aVariablit¨t in Software Produktlinien eingef¨hrt werden. a u3.3 Variablit¨t aDie Produktvarianten einer Software Produktlinie zeichnen sich durch eine Viel-zahl gemeinsamer, unterschiedlicher und variierender Features aus. Aus diesemGrund spielen bei der Entwicklung von Software Produktlinien insbesondereVariablit¨tsaspekte eine ubergeordnete Rolle. Unter Variablit¨t wird im Allge- a ¨ ameinen die M¨glichkeit verstanden, Systeme oder Komponenten zu ¨ndern und o aan individuelle Bed¨rfnisse anzupassen. Bei Produktlinien bezeichnet sie die Un- uterschiede der Produktvarianten und definiert den Rahmen in dem diese durchSelektion von Systemartefakten individuell angepasst werden k¨nnen. Sie spielt odamit eine zentrale Rolle in der Produktlinienentwicklung und tritt in unter-schiedlichster Form auf. Dies kann von der Unterst¨tzung mehrerer Betriebssys- uteme bis zur komplexen Anpassung von Systemartefakten reichen [6]. Im Folgenden wird auf die Beschreibung der Variablit¨t des Produktraums aeingegangen und das Konzept des Variationspunkts eingef¨hrt. uProduktraum Variablit¨t Die Variablit¨t des Produktraums wird mit der a aHilfe von Feature×Produkt-Tabellen und Feature-Graphen dokumentiert. Fea-tures beschreiben dabei Merkmale der Software Produktlinie, die Gemeinsamkei-ten und Unterschiede der einzelnen Produktvarianten darstellen. Features lassensich dabei weiter klassifizieren in externe Features, notwendige Features und op-tionale Features. Externe Features zeichnen sich dadurch aus, dass sie nicht Teildes Produkts selbst sind, aber von diesem ben¨tigt werden. Notwendige Features osind grundlegende Features, ohne die das Produkt nicht funktionsf¨hig w¨re. Op- a ationale Features bieten zus¨tzliche Funktionalit¨t, die zum Betrieb des Produkts a anicht dringend notwendig ist. Feature×Produkt-Tabellen geben dabei Aufschlussuber den Umfang der geplanten Produkte und deren Features. Feature-Graphen¨dokumentieren Abh¨ngigkeiten zwischen Features und deren Variablit¨t [6]. a a Abbildung 2 beschreibt den Produktraum einer Software Produktlinie zurErstellung mehrerer Varianten eines Mail-Clients mit der Hilfe eines Feature-Graphen. Dazu wird eine zu der UML sehr ¨hnliche Notation verwendet, wel- ache Konstrukte zur Auszeichnung von Kompositionen von Features, OptionalenFeatures, OR- und XOR-Spezialisierungen von Features und externe Featuresenth¨lt. In der Abbildung ist zu erkennen, dass ein Mail-Client eine Komposi- ation aus den Features TCP Connection, Type Message, Receive Message, SendMessage und Runtime Platform darstellt. Weiterhin ist ihr zu entnehmen, dassdas Receive Message Feature, welches zum Empfangen von E-Mails dient, uber ¨einer OR-Spezialisierung mit den Features Pop3 und IMAP verbunden ist. Dies
  6. 6. bedeutet, dass das Receive Message Feature das Pop3 oder aber das IMAP Fea-ture zum Empfangen von E-Mails verwenden kann. Die Auszeichnung runtime“ ”weist darauf hin, dass die Wahl des tats¨chlich zu nutzenden Features zur Lauf- azeit entschieden wird. Der Abbildung ist außerdem zu entnehmen, dass die Run-time Platform uber eine XOR-Spezialisierung mit den Features win32 und linux ¨in Beziehung steht. Da die Beziehung weiterhin mit compiletime“ ausgezeichnet ”ist, bedeutet dies, dass ein Mail Client wahlweise Windows oder aber ein Linux- ¨Derivat nutzen kann, dies aber zum Zeitpunkt der Ubersetzung entschieden wer-den muß. Eine detaillierte Beschreibung zur Erstellung von Feature-Graphenwird in [5] und [4] gegeben. Orte im Feature-Graphen, an denen eine Entschei-dung bez¨glich des zu nutzenden Features getroffen werden muss, werden auch uVariationspunkte genannt und im folgenden Abschnitt n¨her erl¨utert. a a Mail Client « external » « external » Receive Message Send Message Runtime Platform TCP Connection Type Message runtime runtime compiletime « external » « external » Signature Edit Pop3 IMAP win32 linux runtime or specialization composition « external » « external » Internal Editor vi Emacs xor specialization optional featureAbbildung 2. Beschreibung eines Produktraums zur Erstellung eines Mail-Clients mitHilfe eines Feature-Graphen [4].Variationspunkte Produkt- und systemumgebungsspezifische Variablit¨t wird adurch so genannte Variationspunkte abgebildet. So werden variable und optio-nale Features erst durch Variationspunkte m¨glich. Variationspunkte sind also oPunkte im Entwicklungsablauf, an denen Entwurfsentscheidungen bez¨glich der uVariablit¨t getroffen werden m¨ssen, um eine konkrete Variante eines Features a uzu erhalten. Es muss also eine aus mehreren Entwurfsalternativen gew¨hlt wer- aden. Wird eine aus mehreren Entwurfsalternativen gew¨hlt so wird dies auch aals das Binden von Variationspunkten bezeichnet. Das Binden von Variations-punkten kann dabei zu unterschiedlichen Zeitpunkten stattfinden. Beispielsweisekann das Binden w¨hrend des Architekturentwurfs, dem Feinentwurf, der Im- a ¨plementierung, der Ubersetzung oder zur Laufzeit stattfinden [6].
  7. 7. 3.4 Produktlinien ArchitekturEine explizit definierte Produktlinienarchitektur ist von zentraler Bedeutung f¨r udie gesamte Produktlinieninfrastruktur. Sie stellt eine gemeinsame generischeReferenzarchitektur f¨r alle im Produktraum liegenden Softwareprodukte zur uVerf¨gung. u Konkrete Softwareprodukte leiten ihre Architektur von der Produktlinienar-chitektur ab. Durch diese f¨r die gesamte Produktlinie g¨ltige Architektur kann u uf¨r alle Produkte die Erf¨llung von nichtfunktionalen Anforderungen, wie Perfor- u umance, Verf¨gbarkeit, Skalierbarkeit und Erweiterbarkeit leichter sichergestellt uwerden, da diese Aspekte zu großen Teilen durch die Architektur abgedeckt wer-den [9]. Eine Besonderheit bei Referenzarchitekturen ist, dass produktspezifischeAnforderungen schon im Entwurf der Produktlinienarchitektur beachtet werdenm¨ssen, um eine m¨glichst generische Architektur, die f¨r alle Produkte nutz- u o ubar ist, zu schaffen. Wird dies nicht beachtet, so kann die Referenzarchitekturim schlimmsten Fall produktspezifische Anforderungen unm¨glich machen. Ziel oist es aber eine Produktlinienarchitektur zu entwickeln, welche den Anforderun-gen der Softwareprodukte der gesamten Produktlinie gen¨gt. Des Weiteren wird udurch sie auch die Kommunikation zwischen den verschiedenen Interessengrup-pen unterst¨tzt [3]. u Eine Produktlinienarchitektur bietet verschiedene Variationsm¨glichkeiten ohinsichtlich ihrer Konnektoren und Komponenten. Diese k¨nnen in verschiede- onen Varianten angeboten werden. In der Architektur sollte explizit definiert sein,welche Komponenten obligatorisch, optional und variabel sind und wie optiona-le und variable Komponenten durch konkrete Komponenten instanziiert werdenk¨nnen. Dabei bezeichnet eine Konfiguration die konkrete Auswahl von Syste- omartefakten die ein Softwareprodukt formen. Im Idealfall ist es f¨r konkrete Soft- uwareprodukte m¨glich, direkt die Referenzarchitektur der Software Produktlinie ozu nutzen, indem Variationspunkte durch Selektion konkreter Komponenten inder Architektur gebunden werden. Dazu ist es n¨tig standardisierte Schnittstel- olen zu schaffen. Im konkreten Fall k¨nnen Schnittstellen in der objektorientier- oten Programmierung durch Klassen implementiert werden. Variation kann danndurch unterschiedliche Konfigurationen und das Ableiten von Klassen erfolgen. Bereiche der Referenzarchitektur, die nicht ge¨ndert werden, nutzen gemein- asame Komponenten. Es kann jedoch auch vorkommen, dass neben der Auswahlkonkreter Komponenten an den Variationspunkten die Architekrur selbst teil-weise an die produktspezifischen Anforderungen angepasst werden muss [2].3.5 Produktlinien ProzesseBei der Entwicklung von Software Produktlinien wird zwischen drei zentralenund iterativen Prozessen, dem Domain Engineering, dem Application Enginee-ring und dem Management unterschieden [9]. Auf diese drei Prozesse wird imFolgenden genauer eingegangen.
  8. 8. Domain Engineering Das Domain Engineering stellt den zentralen Teilprozessdes Produktlinien Engineering dar. In ihm wird der Produktraum, die ben¨tig- ote Infrastruktur und gemeinsame Funktionalit¨t in Form wiederverwendbarer aSystemartefakte f¨r die zu erstellende Software Produktlinie einer spezifischen uDom¨ne konzipiert und entwickelt. Das Domain Engineering l¨sst sich in die a adrei Teilprozesse Dom¨nenanalyse & Scoping, Architekturentwurf und Imple- amentierung unterteilen. Die Dom¨nenanalyse umfasst die Anforderungsanalyse af¨r die gesamte Produktlinie und dokumentiert die Gemeinsamkeiten und Un- uterschiede aller geplanten Produktvarianten. In der Scopingphase werden alleInformationen zu den geplanten Produktvarianten gesammelt, beschrieben undin dem Produktraum festgehalten. Aus dem Wissen der Dom¨nenanalyse und adem Scoping wird in der Architekturentwurfsphase eine Produktlinienarchitek-tur entworfen, aus der die Architekturen der konkreten Produktvarianten ab-geleitet werden. In der Implementierungsphase werden die Systemartefakte, dieauch als Core Assets bezeichnet werden, konzipiert, entwickelt und anschließendin der Produktlinien-Infrastruktur archiviert. Zus¨tzlich wird in dieser Phase ain einem Produktionsplan festgehalten, wie die einzelnen Produktvarianten ausden Systemartefakten zu konstruieren sind [6]. Ziel des Domain Engineering istes, dem Application Engineering Prozess eine technische und organisatorischePlattform zur Verf¨gung zu stellen, welche die Erstellung von Produktvarian- uten der Anwendungsdom¨ne durch Verwendung systematisch wiederverwendba- arer Systemartefakte unterst¨tzt. Dazu werden die einzelnen Systemartefakte der uPlattform genau auf die Produktlinie zugeschnitten und f¨r eine hohe Wieder- uverwendbarkeit ausgelegt, so dass sie sich mit geringem Aufwand miteinanderkombinieren lassen [3].Application Engineering Das Application Engineering bezeichnet den Teil-prozess des Produktlinien Engineering, in dem einzelne Instanzen der SoftwareProduktlinie, also konkrete Produktvarianten, durch das Ausw¨hlen und An- apassen der von der Plattform zur Verf¨gung gestellten Systemartefakte und dem uImplementieren systemspezifischer Komponenten, erzeugt werden [6]. Im Ideal-fall entstehen neue Produktvarianten der Plattform durch das Zusammenbau-en nach einem Produktionsplan. Der Schwerpunkt wird so vom Programmierenzum Integrieren verlagert [3]. F¨r jede Produktvariante werden die Phasen Sys- utemanalyse, Systementwurf, Systemimplementierung und Systemtest durchlau-fen. In der Systemanalyse werden die softwaresystemspezifischen Anforderungen,die sich von denen der Produktlinie unterscheiden, ermittelt. Im Systementwurfwird die konkrete Systemarchitektur der Produktvariante durch Ableitung vonder Produktlinienarchitektur entwickelt. Bei der Systemimplementierung wirdschließlich durch Ausw¨hlen der Systemartefakte die konkrete Produktvariante aerstellt. Die Anforderungen eines konkreten Softwaresystems k¨nnen wiederum odazu f¨hren, dass der Domain Engineering Prozess angestoßen wird um die Platt- uform der Software Produktlinie entsprechend anzupassen und gegebenenfalls umweitere Systemartefakte zu erweitern [7].
  9. 9. Management Das Management ist der zentrale Teilprozess des ProduktlinienEngineering, der die beiden anderen Prozesse unterst¨tzt und koordiniert. Hier uwird zwischen technischem und organisatorischem Management unterschieden.Das technische Management uberwacht die Entwicklung der Systemartefakte ¨und der konkreten Produktvarianten. Es stellt sicher, dass alle Prozesse gem¨ß aden Vorgaben durchgef¨hrt werden. Dagegen ist das organisatorische Manage- ument f¨r die Planung, Priorisierung und Verteilung der Ressourcen zust¨ndig. Es u alegt weiterhin die grundlegende Unternehmensstrategie fest. Ein gut gef¨hrtes uManagement ist von entscheidender Bedeutung f¨r die erfolgreiche Umsetzung ueiner Software Produktlinie [7, 9]. Abbildung 3 zeigt die drei zentralen Prozesse und ihre Interaktion bei derEntwicklung von Software Produktlinien. Domain Engineering Process Prozesse Richtlinien Architektur Anforderungen Product Line Management Infrastruktur Neue Artefakte Process Werkzeuge Komponenten Application Engineering Produkte ProcessAbbildung 3. Die drei zentralen Prozesse Domain Engineering, Application Enginee-ring und Management bei der Entwicklung von Software Produktlinien [9].4 FazitDie Einf¨hrung von Software Produktlinien ist ein vielversprechender Ansatz zur uReduktion der Entwicklungskosten, Erh¨hung der Produktzuverl¨ssigkeit und o aProduktqualit¨t sowie einer beschleunigten Entwicklung [6]. Die Komplexit¨t der a aEinf¨hrung, des Aufbaus und des Betriebs einer Software Produktlinie in einem uUnternehmen stellt aber eine große H¨rde f¨r die Aussch¨pfung des vorhande- u u onen Wiederverwendungspotentials einer Produktfamilie dar. Es ist viel Zeit und
  10. 10. eine hohe Vorabinvestition n¨tig, um eine Produktlinie erfolgreich einzuf¨hren. o uW¨hrend der Aufbauphase einer Produktline wirft diese n¨mlich zun¨chst keine a a aErtr¨ge ab, sondern f¨hrt sogar zu h¨heren Kosten. Aus den besagten Gr¨nden a u o uscheitern viele Unternehmen bei dem Versuch eine Produktlinie einzuf¨hren,uselbst wenn die Andwendungsdom¨ne und die Produktvarianten pr¨destiniert a af¨r die Entwicklung einer Produktlinie sind. Ein Grund ist meistens das Fehlen ueines klar definierten Vorgehensmodells f¨r die Entwicklung einer Software Pro- uduktlinie. Ben¨tigt wird also eine ganzheitliche Methode, die ein klar definiertes oVorgehensmodell zur Entwicklung einer Produktline bereitstellt, denn der Soft-ware Produktlinien Ansatz ist zun¨chst nur ein Konzept. Eine vielversprechende aganzheitliche Methode zum erfolgreichen Aufbau, Betrieb, Einsatz und Wartungeiner Software Produktline definiert beispielsweise das vom Fraunhofer Institutentwickelte PuLSE (Product Line Software Engineering) [1]. Ist eine Produktfa-milie jedoch erst einmal etabliert, treten die genannten Nachteile immer mehr inden Hintergund und die Vorteile, wie h¨here Softwarequalit¨t, h¨here Produkti- o a ovit¨t und k¨rzere Entwicklungszeiten kommen zum Vorschein [2]. a uLiteratur[1] M. Anastasopoulos, C. Atkinson, and D. Muthig. A Concrete Method for Developing and Applying Product Line Architectures.[2] K. B¨llert. o Objektorientierte Entwicklung von Software-Produktlinien zur Serienfertigung von Software-Systemen, 2002. URL http://www. db-thueringen.de/servlets/DocumentServlet?id=1158.[3] P. Clements and L. Northrop. Software Product Lines: Practices and Patterns (The SEI Series in Software Engineering). Addison-Wesley Professional, 2001. ISBN 0201703327.[4] J. V. Gurp, J. Bosch, and M. Svahnberg. On the notion of variability in software product lines. In WICSA ’01: Proceedings of the Working IEEE/I- FIP Conference on Software Architecture (WICSA’01), page 45, Washing- ton, DC, USA, 2001. IEEE Computer Society. ISBN 0-7695-1360-3. doi: http://dx.doi.org/10.1109/WICSA.2001.948406.[5] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical re- port, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, 1990.[6] R. Reussner and W. Hasselbring. Handbuch der Software-Architektur. Dpunkt Verlag, 2006. ISBN 3898643727.[7] Software Engineering Institute. Product Lines, 2007. URL http://www. sei.cmu.edu/productlines/. Stand: 31.12.2007.[8] I. Sommerville. Software Engineering. Pearson Studium, 2007. ISBN 3827372577.[9] R. Zacharias. Produktlinien: Der n¨chste Schritt in Richtung Software- a Industrialisierung. Javamagazin, (3.07):69–79, 2007.

×