Softwareproduktlinien-Entwicklung Domain Engineering: Konzepte, Probleme und Lösungsansätze

Transkript

1 UNIVERSITÄT LEIPZIG Fakultät für Mathematik und Informatik Institut für Informatik Softwareproduktlinien-Entwicklung Domain Engineering: Konzepte, Probleme und Lösungsansätze Betrachtung im Rahmen einer Fallstudie über die Entwicklung eines Portals und eines Frameworks zur Unterstützung elektronischer Prüfungsabläufe Diplomarbeit Leipzig, April 2007 vorgelegt von Berger, Thorsten geboren am 26. Oktober 1981 Studiengang Informatik

2 Abstract Software Product Line Engineering (SPLE) has become the most successful approach for software reuse in the last ten years. It has proven to reduce development times, lower costs and improve the quality of software-intensive systems. One of its key points is the up-front development of a flexible and highly extensible platform (Domain Engineering) as a basis for deriving concrete applications (Application Engineering). The thesis describes the Domain Engineering in a case study that deals with the development of an Open Source project in the J2EE environment. It mainly focuses on concerns regarding the high-level architecture and process descriptions as proposed by the framework. To fit the needs of the project it also had to be tailored in numerours aspects. Furthermore, the experience gained during the lifecycle of the project yields an estimation of theoretical and practical issues of the development approach. The thesis also shows open questions in the SPLE research field. One of the most important enablers of SPLE in the case study has been the usage of J2EE portal standards, which provide an extensive infrastructure for web application delivery and integration. In a product line view, portals offer mechanisms for extreme late binding of complex functionality. However, there have been many more technologies and frameworks that supported building the platform. These have been e.g. an IoC component framework, MVC frameworks, AOP or model-driven/generative approaches, whose application in the product line context of the case study will be shown. The case study comprises the Domain Requirements Engineering, Domain Design and Domain Realisation subprocesses of the Product Line Framework. In addition, an overview of verification and validation techniques (static analysis as well as the Domain Testing) for the platform will be shown. 1

3 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Abgrenzung Aufbau der Arbeit Betrachtungsgegenstand Entstehung elateportal-projekt Technologien, Umgebungen und Ansätze Weitere Arbeiten Softwareproduktlinien Grundlagen und Definition Begriffsbestimmung Klassisches Domain Engineering Vorteile Kosten und Risiken Methodiken und Frameworks Produktlinien-Framework Referenzprozess Product Management Variabilitäts-Modell Einfluss agiler Prinzipien Domain Requirements Engineering Kontext Artefakte Vorgehen und Aktivitäten Basisanforderungen in der Fallstudie Commonality Analysis Variability Analysis Variability Modelling Auswertung Domain Design Kontext Artefakte Vorgehen und Aktivitäten Komponenten-Framework Referenzarchitektur

4 Inhaltsverzeichnis 6.6 Aufgaben-Framework elateportal Prüfungsserver Auswertung Domain Realisation Kontext Artefakte Vorgehen und Aktivitäten Build-Management und Deployment Detailliertes Design des Aufgaben-Frameworks Detailliertes Design des elateportals Detailliertes Design des Prüfungsservers Bindung von Variabilität Auswertung Verifikation und Validierung Inspektionstechniken Domain Testing Automatische statische Analyse Unit-Tests Integrations-Tests System-Tests Zusammenfassung Produktlinien-Forschung Tailoring und Praxis Ausblick Anhang A.1 Aufgaben-Framework: Implementierte Aufgabentypen A.2 Orthogonales Variabilitätsmodell A.3 Detaillierte Design-Artefakte A.4 Test-Strategien für Produktlinien Abbildungsverzeichnis Abkürzungsverzeichnis Literaturverzeichnis

5 Einleitung 1 Einleitung 1968 wurde auf einer NATO-Konferenz in Garmisch-Partenkirchen zum ersten Mal der Begriff des Software Engineering in Bezug auf die ingenieurmäßige Erstellung von softwareintensiven Systemen geprägt. Diese Disziplin stellte eine Antwort auf die damalige Software-Krise dar und hat im Laufe der Zeit verschiedene Methodiken zur Entwicklung von Software hervorgebracht. Während lange Zeit schwergewichtige und streng phasenorientierte Entwicklungsprozesse das Software Engineering dominierten, die sich für große Systeme mit einer langen Lebensdauer bewährt haben, sind seit den letzten zehn Jahren neue Trends erkennbar, die den geänderten Anforderungen an heutige Software Rechnung tragen sollen. Software muss schneller entwickelt werden können, soll besser an sich ändernde Umgebungen anpassbar sein und trotzdem weniger Kosten verursachen sowohl in der Entwicklung als auch in der Wartung. Außerdem werden heute viel seltener Systeme von Grund auf neu entwickelt, häufiger soll bestehende Software wiederverwendet oder mit anderen Legacy-Applikationen kombiniert werden. Ältere Entwicklungsmethoden erwiesen sich in diesen Bereichen als zu starr, wenig anpassbar und erzeugten häufig unnötigen Overhead. Der sich ändernde Kontext des Software Engineerings führte zu einem Umdenken in zwei Richtungen: zum einen in der Favorisierung leichtgewichtiger, stark adaptiver Entwicklungsparadigmen und zum anderen in der Serienfertigung von Software durch Ausnutzen des Wiederverwendungspotentials bestehender Produkte. Letzteres wird auch als Industrialisierung des Software Engineerings bezeichnet, in Anlehnung an traditionelle Entwicklungszweige wie die Automobilindustrie, die bereits seit langer Zeit auf standardisierte und flexibel verwendbare Bauteile setzen. Neben neuen Vorgehensweisen bestimmen aber mittlerweile auch neue Architekturansätze und Technologien das Software Engineering. Dazu gehören beispielsweise die Serviceorientierte Architektur, Generative bzw. Modellbasierte Entwicklung oder ausgereiftere Komponententechnologien. Trotz signifikanter Fortschritte stellt Software Engineering noch keine reife Disziplin in der Informatik dar [Pa98b]. Dazu gibt es nach wie vor zu viele Projekte, die nicht im anvisierten Zeitrahmen, nicht mit dem veranschlagten Budget oder sogar überhaupt nicht fertiggestellt werden können [St03]. Die Ursachen für diese Probleme sind vielfältig und ihre Identifizierung ist Aufgabe der aktuellen Forschung. 1.1 Motivation Mit Software-Wiederverwendung wird die Vorgehensweise bezeichnet, Softwareprodukte nicht von Grund auf neu zu erstellen, sondern aus bereits entwickelter Software abzuleiten. Obwohl die Idee bereits 1968 von McIlroy [Il68] innerhalb der NATO-Konferenz als einfache und leistungsfähige Lösung der Software-Krise aufgezeigt worden ist, dauerte es mehr als 20 Jahre bis man im Software Engineering von funktionierenden Ansätzen zur Software-Wiederverwendung sprechen konnte. Obwohl die Idee relativ einfach erschien, gestaltete sich die Praxis als ausgesprochen schwierig. Durch mittlerweile verfügbare neue Technologien und umfassendere Abstraktionskonzepte konnten sich in den letzten zehn bis 15 Jahren funktionierende Ansätze zur Software- Wiederverwendung etablieren. Einen der erfolgreichsten stellt dabei die Softwareprodukt- 4

6 Einleitung linien-entwicklung dar, die ihre praktische Anwendbarkeit in zahlreichen Projekten bewiesen hat. Dafür existieren verschiedene Studien, die den Erfolg von Produktlinien in großen Organisationen mit kommerziellem Hintergrund belegen [CN01]. Während auch Erfahrungsberichte zur Einführung von Produktlinienentwicklung in kleinen und mittelgroßen Unternehmen verfügbar sind [Kn00, VK05], ist mittlerweile noch keine Fallstudie bekannt, welche die Anwendbarkeit des Ansatzes im Rahmen von Open- Source-Projekten untersucht, die oft auf weiterer freier Software basiert und die teilweise ihren eigenen Gesetzen und Regeln folgt. 1.2 Zielsetzung In der vorliegenden Arbeit erfolgt eine Betrachtung des Softwareproduktlinien-Ansatzes anhand einer Fallstudie. Es wird die Entwicklung einer Plattform im Rahmen eines Open- Source-Projektes beschrieben, das aus den Anforderungen von drei Fakultäten an der Universität Leipzig entstanden ist. Die Ausarbeitung zielt auf eine Beantwortung der folgenden Fragestellungen, die sich auf zwei verschiedenen Abstraktionsebenen ergeben und eng miteinander verknüpft sind. Zum einen sind das auf einer theoretischen Ebene: (1) Wodurch ist die Produktlinienentwicklung charakterisiert, wie ist ihr Kontext im Software Engineering und von welchem Forschungsstand kann ausgegangen werden? (2) Welche Problemstellungen der Produktlinienentwicklung sind identifizierbar, für die weitere Forschung notwendig ist? Auf einer praxisorientierten Ebene wird im Rahmen der Fallstudie die Anwendung eines Produktlinien-Frameworks auf das Projekt erläutert. Insbesondere zielt die Arbeit auf eine Darstellung von Ansätzen, wie ein Tailoring auf Projekte mit ähnlicher Ausrichtung möglich ist. Auf dieser Ebene wird eine Beantwortung der folgenden Fragestellungen verfolgt: (3) Wie wurde das Framework auf die Anforderungen in der Fallstudie maßgeschneidert? (4) Welchen Einfluss hatten die verwendeten Technologien und wie konnten sie die Entwicklung unterstützen? 1.3 Abgrenzung Abbildung 1 zeigt vier Belange, mit denen sich die Produktlinienforschung befasst. Während die meisten Produktlinien-Methodiken auf eine umfassende Unterstützung der Entwicklung zielen, ist der Fokus dieser Arbeit auf die folgenden zwei Belange gerichtet. 5

7 Einleitung Business Architecture Process Organisation Abbildung 1 BAPO-Modell (nach [Li02]) So konzentriert sich die Arbeit auf die Architektur und den Prozess zur Entwicklung der Plattform (Architecture und Process), sie beschäftigt sich weder mit wirtschaftlichen noch mit organisationsspezifischen Aspekten (Business und Organisation). Zu letzteren wird jedoch eine Übersicht gegeben, die zur Charakterisierung der Produktlinienentwicklung notwendig ist und ihre Popularität aufzeigt. Weiterhin wird in der Produktlinienentwicklung zwischen zwei Hauptprozessen unterschieden: Domain Engineering, das der Entwicklung einer (Produktlinien-)Plattform dient Application Engineering, das konkrete Applikationen aus der Plattform ableitet Die Arbeit fokussiert in der Fallstudie das Domain Engineering. Hingegen werden zum Application Engineering nur einige Charakteristika aufgezeigt, die Auswirkungen auf das Tailoring des verwendeten Produktlinien-Frameworks hatten. In der Arbeit werden Ausschnitte von Diagrammen und Modellen dargestellt, die zur Erläuterung relevanter Artefakte bzw. Vorgehensweisen notwendig sind. Aufgrund des Projekt-Umfangs ist keine detaillierte Darstellung des gesamten Entwicklungsprozesses möglich. Für weitergehende Implementierungs-Details sei auf die Projekt-Homepage (siehe Kapitel 2.2) verwiesen. 1.4 Aufbau der Arbeit Das Kapitel 2 stellt zunächst den Betrachtungsgegenstand der Fallstudie vor. Kapitel 3 enthält eine Einführung in den Produktlinien-Ansatz, in der eine grundlegende Charakterisierung erfolgt. Insbesondere werden Punkte betrachtet, die den Erfolg von Softwareproduktlinien im Software Engineering erläutern. Daran schließt sich eine Übersicht zu den wichtigsten Produktlinien-Frameworks an und Kapitel 4 beschreibt das ausgewählte Framework im Hinblick auf die Fallstudie genauer. Die nächsten drei Kapitel stellen den Hauptteil der Arbeit dar, in denen mit einem Top- Down-Ansatz jeweils die produktlinienspezifischen Aspekte bei der Entwicklung des Projekts dargestellt werden. So befasst sich Kapitel 5 mit dem Requirements Engineering, Kapitel 6 mit dem groben Design in Form der Referenzarchitektur und Kapitel 7 mit dem detaillierten Design sowie der Implementierung. In jedem Kapitel erfolgt zunächst eine Erläuterung der Theorie, daran schließt sich eine spezifische Betrachtung innerhalb der 6

8 Einleitung Fallstudie an und am Ende wird eine Auswertung sowohl nach praktischen als auch theoretischen Gesichtspunkten gegeben. Kapitel 8 enthält darüber hinaus Ausführungen zur Verifikation und Validierung der entwickelten Plattform. Die Arbeit schließt mit einer Zusammenfassung der gesamten Vorgehensweise in Kapitel 9 ab, in der eine Beurteilung erfolgt, wie die Fragestellungen aus der Zielsetzung beantwortet werden konnten. 7

9 Betrachtungsgegenstand 2 Betrachtungsgegenstand In diesem Kapitel erfolgt eine Einführung in das elateportal-projekt als Betrachtungsgegenstand der Fallstudie. Beginnend mit einem kurzen Abriss über die Entstehungsgeschichte werden fachliche Aspekte des Projekts erläutert. Das beinhaltet zum einen die Funktionalität des Systems sowie eine Beschreibung von Einsatzszenarien an der Universität Leipzig, aber auch technische und organisatorische Rahmenbedingungen. Insbesondere werden Gründe aufgezeigt, die zur Anwendung eines Produktlinien-Ansatzes geführt haben. Das Gesamtprojekt ist bereits in [BW06] vorgestellt worden, wobei der Fokus auf Architektur-Gesichtspunkten lag. Insbesondere enthält die Veröffentlichung eine Schilderung von Praxiserfahrungen, die durch den Einsatz des elateportals gewonnen werden konnten. 2.1 Entstehung Die Idee hinter der Einführung des elateportal-projekts lässt sich auf das ältere und wesentlich kleinere Open-Source-Projekt UebManager 1 zurückführen, das eine webbasierte Umgebung zur Unterstützung von Übungsseminaren bereitstellte und erfolgreich an der Abteilung Betriebliche Informationssysteme 2 (BIS) der Universität Leipzig eingesetzt worden ist. Es war ausgerichtet auf typische Abläufe in einem Übungsbetrieb wie Einschreibungen, Bereitstellung von Unterrichtsmaterialien oder die Kommunikation mittels Foren. Hauptbestandteil war die Durchführung und Korrektur von Übungsserien, bei denen von Teilnehmern Lösungen in Form von PDF-Dateien hochgeladen oder Multiple-Choice-Fragen beantwortet werden konnten. Basierend auf den Ergebnissen wurden die Teilnehmer automatisch zur Klausur zugelassen. Nach der reinen Verwendung im Übungsbetrieb kamen weitere Einsatzszenarien hinzu, welche auf die Durchführung von Prüfungsklausuren unter Examensbedingungen in der Erziehungswissenschaftlichen Fakultät 3 zielten. Gründe dafür stellten hohe Prüfungsbelastungen in Grundstudiums-Vorlesungen durch bis zu 900 Teilnehmer sowie eine aufwendig zu korrigierende Papierklausur dar. Auf Basis des UebManager-Projekts wurde zunächst ein Prototyp entwickelt, der zur ersten elektronischen Klausur im Wintersemester 2004 an der Erziehungswissenschaftlichen Fakultät führte. Da das vorhandene alte Aufgabenmodell für den Übungsbetrieb die neuen Anforderungen nicht realisieren konnte, bestand ein Hauptteil der Arbeit in der Entwicklung eines neuen Modells für komplexere Aufgaben sowie einen umfassenderen Prüfungsablauf. Eine Eigenentwicklung war notwendig, da verfügbare Lösungen entweder kommerziell waren oder für den anvisierten Einsatz nur einen ungenügenden Funktionsumfang aufwiesen und keine vollständige Unterstützung von Prüfungsprozessen besaßen. Außerdem fehlten den meisten Lösungen angemessene Erweiterungsmöglichkeiten, mit denen man sie hätte adaptieren können

10 Betrachtungsgegenstand Obwohl der Prototyp ausgeprochen stabil lief und der erste Einsatz uneingeschränkt positiv ausfiel, zeigten sich schnell Grenzen auf. So war die Architektur des UebManagers nicht auf derartige Erweiterungen wie das neue Aufgabenmodell ausgelegt, es mussten viele Änderungen, auch in Kernbereichen, vorgenommen werden. Das machte den Prototypen inkompatibel mit anderen Versionen des UebManagers. Die Folge war, dass mit angemessenem Aufwand keine konsistente Weiterentwicklung der UebManager-Basis mehr möglich war. Darüber hinaus hatte das Projekt verschiedene weitere Grenzen, die seine Einsatzmöglichkeiten beschränkten (vgl. [Be05a]). Inzwischen bestand auch Interesse am Einsatz für elektronische Prüfungen seitens der Selbständigen Abteilung für Allgemeinmedizin 1, die außerdem eine Web-Präsenz benötigte. So existierten schließlich Anforderungen an ein neues System in unterschiedlichen Ausprägungen von drei verschiedenen Abteilungen. Einerseits war die Unterstützung eines integrierten Ablaufs für Prüfungsklausuren und Übungsaufgaben von zentraler Bedeutung, andererseits sollten weitere universitäre Abläufe durch das System umgesetzt werden. Dazu kamen hohe Sicherheitsanforderungen, welche z.b. eine Trennung sensibler Prüfungsdaten von (ebenso sensiblen) Einschreibungs- und Studentendaten erforderten. 2.2 elateportal-projekt Neben den genannten Anforderungen und Einsatzszenarien lag ein weiteres Ziel in der Entwicklung einer Plattform, die auch für weitere Projekte ähnlicher Ausrichtung verwendet werden kann und sich in ein Umfeld vorhandener (Hochschul-) Informationssysteme integrieren lässt. Das elateportal-projekt startete im Sommer 2005 und ist unter der GNU Public License (GPL v.2) lizenziert. Die Projektseite ist über erreichbar und wird von SourceForge.net 2 gehostet. Über sie sind die Quelltexte, Dokumentationen, Bug- und Feature-Tracker sowie die Mailinglisten des Projekts verfügbar

11 Betrachtungsgegenstand Taskmodel-CORE-VIEW Taskmodel-API Taskmodel-CORE (RI mit Spring) TaskletContainer Lifecycle Tasklet TaskDef TaskletCorrection Web Service examserver J2EE-Webapplikation elateportal J2EE-Portalapplikation Abbildung 2 elateportal, Prüfungsserver und Aufgaben-Framework Dabei bezeichnet das elateportal-projekt die Gesamtheit aus dem elateportal, dem Prüfungsserver, einem Aufgaben-Framework sowie einem Editor zur Erstellung von komplexen Aufgaben bzw. von Aufgaben-Pools. In Abbildung 2 sind die beiden erstgenannten Systeme, in denen jeweils eine Implementierung des Aufgaben-Frameworks enthalten ist, dargestellt elateportal Das elateportal ist eine J2EE-Portalapplikation [AH03], die zur Organisation und zum Management von Lehrveranstaltungen eingesetzt wird, wobei hier der Fokus auf einer Integrierbarkeit mit vorhandenen (Hochschul-) Informationssystemen sowie der Unterstützung elektronischer Klausuren liegt. Die folgenden Screenshots vermitteln einen ersten Eindruck 1 über das elateportal. In Abbildung 3 ist die persönliche Oberfläche eines Nutzers dargestellt, die er an seine Bedürfnisse anpassen kann, wie in Abbildung 4 zu sehen ist. Insbesondere ermöglicht das Portal das Hinzufügen weiterer Anwendungen (Portlets), wie bspw. das Portlet zur Darstellung von RSS-Feeds links unten. 1 siehe auch: 10

12 Betrachtungsgegenstand Abbildung 3 Persönliche Oberfläche Abbildung 4 Anpassung der Oberfläche 11

13 Betrachtungsgegenstand Die nächsten Abbildungen zeigen jeweils verschiedene Administrations-Portlets. Abbildung 5 -benachrichtigungen In Abbildung 5 ist ein Portlet zum Editieren von -vorlagen abgebildet. Derartige s werden auf verschiedene Ereignisse von Komponenten verschickt, z.b. bei der Erstellung von News- und Foren-Beiträgen oder bei der Registrierung am Portal. Abbildung 6 Veranstaltungs-interne Einschreibungen 12

14 Betrachtungsgegenstand Abbildung 6 zeigt die Administration von Einschreibungen, die innerhalb von Veranstaltungen angelegt werden können, wie bspw. Tutorien, Übungsgruppen oder die Wahl des Prüfungstermins. Abbildung 7 Veranstaltungs-Konfiguration 13

15 Betrachtungsgegenstand Die Oberfläche zur Konfiguration von Veranstaltungen ist in Abbildung 7 dargestellt und ermöglicht neben allgemeinen Einstellungen auch die Konfiguration von Fragen zur Einschreibung sowie deren Restriktion durch Kennungen und Transaktionsnummern (TANs) Prüfungsserver Der Prüfungsserver stellt eine leichtgewichtige Webapplikation für die Durchführung von Prüfungsklausuren dar, wobei er entweder eigenständig oder mit Anbindung an das elateportal verwendet werden kann. Seine Installation erfolgt nur zur Prüfung und der Zugriff ist auf das Computerkabinett beschränkt. Nach Ende einer Prüfungsperiode kann er archiviert und wieder gelöscht werden. Abbildung 8 Prüfungsserver Aufgaben-Framework Zur Unterstützung umfassender Prüfungsabläufe wurde ein eigenständiges Framework mit der folgenden Zielsetzung entwickelt: Erweiterbarkeit mit neuen Aufgabentypen Integrierbarkeit in verschiedene (Java-)Systeme Unterstützung eines Prüfungsprozesses, der von Einschreibung über die Durchführung bis zur Einsichtnahme reicht. Derzeit sind fünf Aufgabentypen implementiert: Multiple-Choice (Einfach- als auch Mehrfachauswahl), Zuordnung, Lückentext, Freitext und Graphische Darstellung. Abbildungen von Beispiel-Aufgaben sind in Anhang A.1 zu finden. Das Framework unterstützt die Erstellung von Fragenpools, die randomisierte Zusammenstellung individueller Prüfungen und insbesondere die semiautomatische Korrektur von Aufgaben. Letzteres bedeutet, dass nicht automatisch auswertbare Aufgaben Korrektoren zugeordnet werden können. 14

16 Betrachtungsgegenstand In der Praxis erfolgte die Korrektur von bis zu 900 Klausuren in einer Korrektursitzung mit ca. 15 studentischen Hilfskräften (SHK) innerhalb von ca. zwei Stunden. Es mussten nur Freitext- und Graphikaufgaben manuell korrigiert werden. Lückentexte wurden nur in Zweifelsfällen den SHKs vorgelegt. Das Aufgaben-Framework stellt ein zentrales Artefakt im elateportal-projekt dar, dessen Referenzimplementierung in das elateportal und den Prüfungsserver integriert ist. Abbildung 9 zeigt beispielhaft die Oberfläche einer Pädagogik-Übungsklausur. Abbildung 9 Klausur-Oberfläche Aufgaben-Editor Der als Desktop-Applikation eigenständige Aufgaben-Editor dient der Erstellung und Bearbeitung von Aufgaben-Pools, die als XML-Dokumente abgespeichert werden. Aufgrund der Komplexität des dazugehörigen XML-Schemas (siehe Abbildung 55, Anhang A.3) wurde zur Entwicklung des Editors ein modellbasierter Ansatz in Form des kommerziellen JAXFront 1 verwendet. Obwohl während der Entwicklung des Editors umfangreiche Erfahrungen mit dem in dieser Form einzigartigen modellbasierten Ansatz von JAXFront gemacht werden konnten, stellt er keinen Betrachtungsgegenstand der Fallstudie dar. Interessant ist jedoch, dass JAXFront zwar zu den modellbasierten Ansätzen, jedoch nicht zu den generativen [CE00] gehört, da es keinen Code erzeugt. Stattdessen erstellt JAXFront erst zur Laufzeit eine

17 Betrachtungsgegenstand Editor-Oberfläche, die entsprechend aus einem Objekt-Baum in Form von Java-Swing- Elementen besteht. Sie repräsentieren die Struktur des XML-Schemas. Abbildung 10 zeigt die Erstellung einer Aufgabe des Typs Graphische Darstellung mit dem Editor. Abbildung 10 Graphik-Aufgabe im Aufgaben-Editor 2.3 Technologien, Umgebungen und Ansätze Das gesamte Projekt wurde überwiegend mit Frameworks und Technologien aus der J2EE- Plattform [Su03a] sowie deren Umfeld entwickelt. Von zentraler Bedeutung für das elateportal war die Verwendung eines Portalservers in Form von Apache Jetspeed-2 1, der zum Java-Portlet-Standard JSR168 [AH03] kompatibel ist. Der Vorteil von Portalen lag zum einen in der Bereitstellung einer grundlegenden Infrastruktur für das elateportal sowie in der Erweiterbarkeit mit fremden, JSR168- kompatiblen Portlets. Letztere stellen in Portalen die eigentliche und auch beliebig umfangreiche Funktionalität dar. Sie werden wiederum zu sog. Portletapplikationen zusammengefasst. Außerdem stellen Portale eine einheitliche, personalisierbare Oberfläche, Single-Sign-On-Funktionalität (SSO) und Sicherheitsmodelle (i.d.r. basierend auf dem JAAS 2 -Framework) bereit. Für einen Überblick über J2EE-Portalserver sowie eine Einführung in verschiedene Standards aus diesem Bereich sei an dieser Stelle auf [LM04, Be05b] verwiesen. Darüber hinaus kamen bei der Entwicklung des elateportal-projekts u.a. auch aspektorientierte Programmierung (AOP) und Generative (GSE) bzw. Modellbasierte Ansätze (MDE) zum Einsatz. Ein Standardwerk zu GSE stellt [CE00] dar, das die Erstellung von Produktlinien durch Code-Generierung verfolgt. Für eine Einführung in MDE-Techniken,

18 Betrachtungsgegenstand die häufig GSE zugeordnet werden 1, sei auf [VS06, BBG05] verwiesen. Neben dem JAXFront-Beispiel, das bzgl. dieser Zuordnung eine Ausnahme darstellt, wird insbesondere in Kapitel eine auf Templates und in Kapitel eine auf Modelltransformation basierende MDE-Technik erläutert. 2.4 Weitere Arbeiten Derzeit befindet sich eine weitere Arbeit in der Entstehung, deren Fokus speziell auf das Aufgaben-Framework gerichtet ist und die auf den Ergebnissen der vorliegenden aufbaut. Während sich das Aufgaben-Framework seit über zwei Jahren in Prüfungen unter Examensbedingungen bewährt hat, sind für erweiterte Einsatzszenarien umfangreichere Aufgabentypen und differenziertere Lebenszyklen notwendig. Dazu gehören z.b. Aufgaben aus der theoretischen oder praktischen Informatik, deren Auswertung weitaus aufwendiger ist. Bezüglich ersteren wird eine Anbindung an das System Autotool [Wa02] und bzgl. zweiteren die Verwendung von Unit-Test-Frameworks (vgl. Kapitel 8.2.1) zur dynamischen Verifizierung von Programmieraufgaben angestrebt. Die Basis der Arbeit ist eine Weiterführung des Produktlinien-Ansatzes unter Evaluierung und (voraussichtlicher) Anwendung des OSGi-Frameworks [OS03], das ein dynamisches Modulsystem in Form einer serviceorientierten Architektur (SOA) bereitstellt. Die Bindung von Variationspunkten erfolgt durch das Deployment sog. Service-Bundles. Durch diesen Ansatz wird ein flexibleres Hinzufügen neuer Aufgabentypen verfolgt. 1 auch AOP wird oft den generativen Ansätzen zugeordnet 17

19 Softwareproduktlinien 3 Softwareproduktlinien Der erste Teil dieses Kapitels stellt zunächst den Softwareproduktlinien-Ansatz vor. Neben grundlegenden Prinzipien und Voraussetzungen werden auch wirtschaftliche Aspekte beschrieben, die wesentlich zum Erfolg von Produktlinien beigetragen haben. Für die Anwendung der Produktlinienentwicklung existiert eine Vielzahl von Methodiken bzw. Frameworks, von denen die wichtigsten im zweiten Teil dargestellt sind. Dabei werden jeweils verschiedene Eckpunkte beschrieben und ihre Eignung für das elateportal- Projekt erläutert. 3.1 Grundlagen und Definition Damit Wiederverwendung von Software funktioniert muss sie durch Vorgehensmodelle geplant und organisiert werden, da sonst die Gefahr besteht, dass mehr Kosten als für eine Neuentwicklung verursacht werden [PBL05, Kapitel 2]. Auf diesem Grundsatz basierend ist die Softwareproduktlinien-Entwicklung ein Ansatz im Software-Engineering, der die schnellere und effizientere Erstellung von qualitativ hochwertiger Software verfolgt. Durch die zielgerichtete Verwendung von Produktlinien- Artefakten werden Gruppen von Softwaresystemen für eine bestimmte Domain entwickelt, die alle eine gemeinsame Menge von Merkmalen aufweisen: 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 in a prescribed way. [CN01] Die Produktlinienentwicklung stellt unter den oben genannten Bedingungen einen Meilenstein im Software-Engineering gegenüber den traditionellen Entwicklungsprozessen, wie z.b. Wasserfall-, Spiral- oder V-Modell [BF99] dar, die nicht auf die speziellen Anforderungen von Produktlinien ausgerichtet sind. Es wird nicht mehr der Fokus auf die reaktive Entwicklung kompletter Systeme auf Kundenwunsch gesetzt, sondern die proaktive Schaffung einer Basisplattform favorisiert. Diese besteht aus einer Menge von Produktlinien-Artefakten, die im sog. Domain Engineering-Prozess entwickelt werden. Zentral ist dabei die Modellierung von Variabilität in den Artefakten, um später im Rahmen des Application Engineering eine Vielzahl konkreter Applikationen ableiten zu können Prinzipien Von wesentlicher Bedeutung für die Softwareproduktlinienentwicklung sind die folgenden zwei Grundlagen [Bo04b]: Modellierung von Variabilität in Produktlinien Trennung von Domain und Application Engineering [WL99] In Abbildung 11 ist ein Produktlinien-Referenzprozess aus dem europäischen Forschungsprojekt PRAISE [Es97] dargestellt, der die beiden genannten Grundsätze veranschaulicht. Alle Produktlinien-Methodiken basieren im Wesentlichen auf dieser Struktur, unterschei- 18

20 Softwareproduktlinien den sich aber häufig hinsichtlich der Herangehensweise an bestimmte Teilgebiete sowie der unterschiedlichen Gewichtung einzelner Prozesse. Domain engineering Legacy code Domain expertise Domain analysis Domain terminology Feedback / adaptations / reverse architecting Domain Domain design implementation Reference architecture Reusable components Reference requirements... Requirements Traceability Traceability Components Family asset repository Application engineering New requirements Application requirements Application design Application coding Abbildung 11 PRAISE-Referenzprozess [Es97] Für die erfolgreiche Entwicklung und Etablierung einer Softwareproduktlinie genügen nicht nur technische Beschreibungen von Vorgehensmodellen. Produktlinienentwicklung betrifft in gleichem Maße auch die organisatorischen Maßnahmen, die in Unternehmen durchgeführt werden müssen. Sie benötigen unternehmerische Voraussicht, Investitionen, Planung und Führung, d.h. strategisches Denken, das über den Horizont einer einzelnen Applikation hinausgeht (vgl. BAPO-Modell, Kapitel 1.3) Voraussetzungen Der Erfolg des Produktlinienansatzes geht neben den genannten Entwicklungsparadigmen einher mit neuen Lösungen und Technologien im Bereich der Software-Architekturen, Laufzeit-Umgebungen und Kommunikationsinfrastrukturen. In der Praxis bedeutet das derzeit eine Fokussierung auf die Verwendung von Komponententechnologien in Verbindung mit objektorientierten Programmiersprachen. Wie bereits in der Einleitung erwähnt, kamen mittlerweile weitere Ansätze bzw. Technologien dazu, wie bspw. AOP, GSE/MDE oder SOA. Abbildung 12 zeigt das im Laufe der Zeit gesteigerte Wiederverwendungspotential verschiedener Entwicklungsparadigmen, die von strukturierter und objektorientierter Programmierung über komponentenbasierte Entwicklung bis zu den genannten modellbasierten Ansätzen reichen. Außerdem ist im Diagramm die agentenbasierte Entwicklung dargestellt, dessen Konzept auf die Anwendung künstlicher Intelligenz und einer SOA ausgerichtet ist, indem sog. Agenten autonom miteinander interagieren (Multi- Agentensysteme) [LAI04]. 19

21 Softwareproduktlinien Reuse level Single systems multiple system families Domainpervasive reuse Architected reuse Managed reuse Planned reuse Informal code reuse No reuse Structured programming Object-oriented development Component-based development Model-Driven Development Agent-based development?? Abbildung 12 Development paradigms Steigerung Software-Wiederverwendbarkeit (erweiterte Version von [Li02]) Die Begriffe der Komponente und des Komponenten-Frameworks werden für die weiteren Ausführungen in der Arbeit eine wichtige Rolle spielen. Weil insbesondere ersterer bereits sehr überladen und in der Literatur nicht eindeutig definiert ist, sei an dieser Stelle auf eine der bekanntesten Definitionen von Szyperski [Sz02] verwiesen. Da es auch Komponenten- Frameworks im J2EE-Bereich gibt, die nicht vollständig konform zu dieser Definition sind, ist der Komponentenbegriff immer im Kontext zu sehen. Insbesondere wird in [CE00, Kapitel 1] auf die allgemeine Problematik bei der Definition von Komponenten hingewiesen. 3.2 Begriffsbestimmung Für Softwareproduktlinien existieren verschiedene Bezeichnungen, die teilweise synonym verwendet werden. So gibt es für den in der amerikanischen Forschung geprägten Begriff Product Line im europäischen Raum die Bezeichnung Product Family, genauso wie ihre Bestandteile entweder Core Assets oder Artefacts genannt werden. Das lässt sich darauf zurückführen, dass sich ursprünglich amerikanische und europäische Forschungsgemeinschaften getrennt mit der Software-Produktlinienentwicklung beschäftigt haben. Als es 1996 in Las Navas, Spanien zu einem ersten Arbeitskontakt kam, waren beide Terminologien bereits etabliert [Li02]. Außerdem gibt es in Europa noch eine weitere Bedeutung für Software-Produktlinien: so bezeichnen einige Unternehmen mit Product Line eine Menge ähnlicher Produkte, die aber auf unterschiedlichen Technologien basieren. Viele Geräte in der Unterhaltungsindustrie sehen für Endanwender ähnlich aus (VCRs, CD-Player, DVD-Player usw.), obwohl sie sich intern stark unterscheiden können. Um keine Verwechslungen zu provozieren wurde deshalb in vielen europäischen Forschungsprojekten explizit Product Family (oder auch System Family) verwendet. Außerdem gilt es hier zu beachten, dass Product Lines in Product Families enthalten sein können und umgekehrt. Bezüglich dieser Terminologie ist also der Begriff Product Line markt- und kundenorientiert, wohingegen eine Product Family ein technologie- bzw. implementierungsabhängiges Konzept ist. Für weitere Informationen sei an dieser Stelle auf [CE00, Kapitel 2] verwiesen, das beide Begriffe im europäischen Sinn definiert. Clements und Northrop [CN01, Kapitel 1] setzen darüber hinaus beide Terminologien in Relation zueinander. 20

22 Softwareproduktlinien Mit Product Population führte Van Ommering [Om00] eine weitere Bezeichnung für spezielle Produktlinien ein, die zwar auf unterschiedlichen Technologien basieren, aber auch viele gemeinsame Komponenten besitzen. Bezogen auf das Unterhaltungsindustrie- Beispiel haben neue Geräte häufig Funktionen, die man früher nur in separaten Geräten fand, etwa Dolby-Digital-Soundsysteme oder DVD-Player in Fernsehern. Inzwischen wird allerdings auch in der europäischen Literatur häufiger der Begriff Produktlinie bzw. Product Line verwendet (vgl. [PBL05]), sodass er auch in der vorliegenden Arbeit benutzt wird. Im Sinne der Definition von Kapitel 3.1 bezeichnet eine Produktlinie in der vorliegenden Arbeit immer eine Menge von Produkten bzw. Artefakten, die auf derselben technischen Basis realisiert worden sind. 3.3 Klassisches Domain Engineering Klassische Domain Engineering-Methoden basieren auf der Idee einer Domain, welche den Fachbereich einer Software bestimmt und den Umfang der Wiederverwendung impliziert. Czarnecki und Eisenecker [CE00, Kapitel 2] definieren Domain Engineering folgendermaßen: Domain Engineering is the activity of collecting, organizing and storing past experiences in building systems or parts of systems in a particular domain in the form of reuseable assets (i.e., reusable work products), as well as providing an adequate means for reusing these assets (i.e., retrieval, qualification, dissemination, adaption, assembly, and so on) when building new systems. In ihrem Buch ist auch eine umfangreiche Übersicht zu Domain Engineering-Methoden zu finden, die in Form eines Stammbaums dargestellt sind. Da ohne zusätzliche Abgrenzung immer eine annähernd vollständige Betrachtung der Domain durchgeführt wird, umfassen klassische Domain Engineering-Methoden meist alle möglichen Applikationen, die aus der Domain entwickelt werden können. Es hat sich nach Bayer et al. [Ba99] herausgestellt, dass der Ansatz viel zu weit gefasst und deswegen problematisch bei der Entwicklung großer Systeme ist. Oftmals müssen zu viele Bereiche betrachtet werden, die ohne Belang für die zu entwickelnden Applikationen sind. Stattdessen fokussieren Unternehmen ganz zielgerichtet bestimmte Produkte, die in der Regel nur einen kleinen Teil der Domain betreffen. Zur Lösung dieses Problems wird im Produktlinien-Ansatz der sog. Scoping-Prozess eingeführt, welcher die Tätigkeiten im Domain Engineering auf die wirklich benötigten Bereiche beschränkt. Zusammen mit weiteren wichtigen Aktivitäten verfolgt der Produktlinien-Ansatz eine gesamtheitliche, produktzentrierte Betrachtung von sowohl Domain als auch Application Engineering und geht damit über klassische Domain Engineering-Methoden hinaus. 3.4 Vorteile Die Entscheidung für oder gegen die Einführung von Produktlinienentwicklung in Unternehmen hat in der Regel wirtschaftliche Gründe und kann wesentlich den Erfolg in einem Marksegment bestimmen. Zu den häufigsten Gründen für die Einführung einer Produktlinie gehören die Steigerung der Produktivität, Verkürzung der Time-To-Market, 21

23 Softwareproduktlinien Verbesserung der Produkt-Qualität oder sogar die Kompensation von Fachkräftemangel [CN01, Kapitel 2]. Mit der Etablierung einer Produktlinien-Plattform lassen sich im Rahmen des Application Engineerings Einsparungen durch Wiederverwendung von Plattform-Artefakten erreichen. Dazu zählen nicht nur Quelltexte, sondern auch Requirements, Architekturen, Komponenten sowie Modelle und Analysen. Auch Test-Pläne, unternehmensspezifische Prozesse und Analysen können wiederverwendet werden. Darüber hinaus lassen sich Entwickler flexibler im Projekt einsetzen. Ein höherer Reifegrad der Plattform führt außerdem zu weniger Softwarefehlern. Erkannte Fehler werden einmal entdeckt und beseitigt in keiner Applikation der Produktlinie wieder vorkommen. Dem steht allerdings auch die Gefahr der Fehlerfortpflanzung aus der Plattform in alle Produkte gegenüber, was besonders in sicherheitskritischen Bereichen von Relevanz ist. Neben organisatorischen Benefits ergeben sich auch persönliche Vorteile für viele Beteiligte, auf die hier nicht näher eingegangen wird. Clements und Northrop [CN01, Kapitel 2] erläutern praxisorientiert den Nutzen für Manager, Entwickler, Kunden und Endbenutzer. 3.5 Kosten und Risiken Die Entscheidung zur Einführung einer Produktlinie sollte nicht wahllos getroffen werden, sondern muss mit konkreten Geschäftszielen verknüpft werden. Neben den oben genannten Vorteilen ist die Einführung auch mit Kosten verbunden, welche in die Entscheidungsfindung mit einfließen müssen. Dies sind einerseits Start-Investitionen für die Etablierung der Produktlinie und andererseits Wartungs- und Pflegekosten, um den Pool von Artefakten instand zu halten. Erstere spielen aber mit jeder neuen Applikation aus der Produktlinie eine mehr und mehr untergeordnete Rolle und amortisieren sich in der Regel nach wenigen Releases. Nach den Erfahrungen von McGregor [Gr02] kann der Break Even bereits nach drei Applikation erreicht sein. Neuere Erfahrungsberichte sprechen mitunter auch von nur zwei entwickelten Produkten [Za07]. In [Co02] werden allerdings auch Risiken genannt, die sich insbesondere auf Widerstände in der Organisation, dem Management und von Entwicklern beziehen. In Tabelle 1 sind die Ergebnisse einer Befragung zu den häufigsten Risiken von Produktlinien dargestellt. Probleme Genannt von Widerstände in der Organisation 52% Widerstände im Management 36% Widerstände von Entwicklern 32% Bedenken bzgl. Zusatzinvestitionen 45% Fehlen entsprechend geschulten Personals 29% Unfähigkeit Auswirkungen einschätzen zu können 19% Bedenken bzgl. der langen Vorlaufzeit 18% Tabelle 1 Einschätzung der Risiken von Produktlinien [Co02] 22

24 Softwareproduktlinien So passen Produktlinien-Ansätze nicht immer zum Marktsegment eines Unternehmens. Wenn sich Märkte zu schnell zu stark ändern, sich vorhandene Produkte zu sehr unterscheiden oder die Zukunft des Marktsegments ungewiss ist, bieten sich nicht genügend Möglichkeiten, einen Return-On-Invest (ROI) zu erreichen. In diesen Fällen sollte von einer Produktlinie abgesehen werden. Interessant ist an dieser Stelle jedoch, dass die in Tabelle 1 dargestellten Risiken nur sehr begrenzt auf Open-Source-Projekte zutreffen Einführungs-Strategien Bei der Einführung von Produktlinienentwicklung wird zwischen leichtgewichtigen und schwergewichtigen Strategien unterschieden, die jeweils den Break Even beeinflussen [Gr02]. Mit schwergewichtigen wird die Produktion in einem Schritt umgestellt, wodurch wesentlich höhere Startkosten nötig sind. Hingegen verfolgen leichtgewichtige Strategien den Ansatz, Artefakte von bestehenden oder in Entwicklung befindlichen Produkten für die Einführung zu verwenden. Ihre Startkosten bewegen sich dann zwischen denen von Einzelsystemen und denen schwergewichtiger Strategien. Abbildung 13 verdeutlicht diesen Sachverhalt. 600, ,000 Single product Heavyweight Lightweight 400, , , ,000 o Number of products Abbildung 13 Kostenvergleich Einführungsstrategien [Gr02] Cumulative costs of products (US dollars) Zur genaueren Berechnung der Einführungskosten von Produktlinien existieren Kostenmodelle auf unterschiedlichen Abstraktionsstufen. An dieser Stelle sei vor allem auf das detaillierte Modell COCOMO II von [Bo00] sowie einen allgemeineren Ansatz in [Bo04a] verwiesen Change Requests Ein weiteres Risiko in der Produktlinienentwicklung stellen nachträgliche Änderungen in Form von Change Requests dar. So muss immer explizit entschieden werden, ob diese nur in der Applikation umgesetzt werden oder auch in die Plattform einfließen sollen. Die erste Strategie führt zwar schneller zur gewünschten Änderung, schöpft aber das Wiederverwendungspotential nicht voll aus und kann die Konsistenz der gesamten Produktlinie in Gefahr bringen. Bei der zweiten Strategie kann es wiederum passieren, dass Kunden durch die Anpassung der Plattform unverhältnismäßig lange auf kleine Änderungen warten müssen [Bo04b, Kapitel 1]. 23

25 Softwareproduktlinien Mit den Auswirkungen von Change Requests auf die Produktlinienentwicklung befasst sich auch Carbon et al. [Ca06]. Sie vergleichen diese mit Change Requests bei agilen Methodiken anhand eines dafür erarbeiteten ROI-Frameworks. Es soll zu weitergehenden Betrachtungen und einem besseren Verständnis bezüglich einer Kombination von agilen und Produktlinien-Methodiken führen (vgl. agile Prinzipien in Kapitel 4.4). Da die Ergebnisse in dem Paper noch nicht vollständig analysiert worden sind, können an dieser Stelle keine Rückschlüsse gezogen werden. 3.6 Methodiken und Frameworks Basierend auf dem Erfolg des Produktlinien-Ansatzes sind verschiedene Methodiken bzw. Frameworks entwickelt worden, welche die Umsetzung in der Praxis ermöglichen sollen. Im Folgenden werden die wichtigsten Entwicklungsmethoden charakterisiert und ihre Eignung für die vorliegende Arbeit erläutert. Die Auswahl orientiert sich an [TH03] FAST Die von Weiss [We95] eingeführte Methodik Family-oriented abstraction, specification and translation (FAST) war die erste, die den klassischen Produktlinienprozess mit expliziter Trennung von Domain und Application Engineering einführte, wie in Abbildung 14 dargestellt. So konzentrierte sich FAST bzgl. des erstgenannten Prozesses auf eine systematische Vorgehensweise zur Analyse möglicher Produktlinien und bzgl. des zweitgenannten auf Techniken zur effizienten Ableitung konkreter Applikationen aus den Produktlinien-Artefakten. Außerdem existieren zwischen den beiden Prozessen Feedback- Schleifen [WL99]. Feedback (Customer needs) Domain Engineering Define the family and develop production facilities Feedback (Production needs) Production Facilities: Application Engineering Environment Application Engineering: Produce Applications Key: Applications Product Process Abbildung 14 Der FAST-Prozess [We95] FAST identifiziert insbesondere die Notwendigkeit einer ausführlichen Analyse der Anforderungen an die Produktlinie (Domain-Analyse) sowie des Findens angemessener 24

26 Softwareproduktlinien Abstraktionen. Wichtig ist, dass die Abstraktionen während des gesamten Lebenszyklusses der Produktlinie stabil bleiben müssen. FAST war für das elateportal-projekt aufgrund der folgenden Eigenschaften nicht geeignet: Die Domain-Analyse und Requirements-Spezifikation ist zu komplex, da die Anforderungen sehr präzise definiert werden müssen, um daraus Code erzeugen zu können [TH03]. Die Traceability von Requirements ist nicht betrachtet worden, was später zu Problemen durch Inkonsistenzen führen kann [TH03]. FAST beschreibt nur einen Prozess und würde im elateportal-projekt ein zu aufwendiges Tailoring implizieren Fraunhofer PuLSE Die Product Line Software Engineering-Methodik (PuLSE) [Ba99] ist eine Entwicklung des Fraunhofer-Instituts für Experimentelles Software-Engineering 1 (IESE) und basiert auf Erfahrungen, die aus der Auftragsforschung mit Industrie-Partnern stammen. Das Institut bietet mit PuLSE kommerzielle Beratungsleistungen an, um Kunden in der Produktlinienentwicklung zu unterstützen. Deployment Phases Technical Components PuLSE Initialization Product Line Infrastructure Construction Product Line Infrastructure Usage Product Line Infrastructure Evolution Customizing Scoping Modeling Architecting Designing Coding Testing and Inspection Evolving and Managing Instantiating Project Entry Points Organizational Issues Maturity Scale Support Components Abbildung 15 PuLSE-Übersicht [Ba99] Das Design der Methodik beruht auf der Erkenntnis, dass bestehende Domain Engineering- Methoden zu sehr auf organisatorische Prozesse fokussiert waren, wohingegen PuLSE einen produkt-zentrierten Ansatz verfolgt. In Abbildung 15 sind die Hauptkomponenten von PuLSE dargestellt

27 Softwareproduktlinien Die Grundlagen der Methodik lassen sich folgendermaßen charakterisieren [TH03]: Mit PuLSE wird ein vollständiges Framework angeboten, das den gesamten Entwicklungsprozess unterstützt, der in drei Phasen unterteilt wird (Deployment Phases). PuLSE ist modular und anpassbar. Es besteht aus sechs technischen (Technical Components) und drei unterstützenden Komponenten (Support Components), die spezielle Bedürfnisse der zu etablierenden Produktlinie abdecken. Sie werden ausgewählt, instanziiert und in den Entwicklungsphasen angewendet. PuLSE kann inkrementell eingeführt und an bestehende Prozesse bzw. Systeme adaptiert werden, um speziellen Anforderungen zu entsprechen. PuLSE führt bereits etablierte Notationen fort und erweitert sie entsprechend, anstatt neue einzuführen. Allerdings konzentriert sich auch PuLSE auf den Entwicklungsprozess auf einem abstrakten Niveau und muss an die konkrete Umgebung durch ein Tailoring angepasst werden. Eine Adaption stellt z.b. das nachfolgend erläuterte KobrA dar. Obwohl PuLSE sich nach [Ba99] auch für kleine und mittelgroße Projekte eignet, war es durch den kommerziellen Charakter und das Fehlen umfassender freier Dokumentation nicht für das elateportal-projekt geeignet Fraunhofer KobrA Die Komponentenbasierte Anwendungsentwicklungs-Methode [ABM00] des IESE ist eine auf die Unified Modeling Language (UML) [OMG04] und komponentenbasierte Entwicklung maßgeschneiderte Version von PuLSE. Ziel ist eine Verbindung der Wiederverwendung im Großen mit der Wiederverwendung im Kleinen. Die Autoren erklären: the product-line and component-based approaches to software development seem to have complementary strengths. They both represent powerful techniques to support reuse, but essentially at the opposite ends of the granularity spectrum [ABM00]. KobrA bietet sehr spezifische Lösungen für die Umsetzung der Produktlinienentwicklung und deckt aufgrund seiner Herkunft nahezu alle wichtigen Aspekte des Ansatzes ab. Interessant ist weiterhin, dass das Design der Methodik sich nicht nur auf Produktlinien, sondern auch auf Einzelsysteme anwenden lassen soll [Ma04]. Außerdem unterstützt es einen modellgetriebenen Ansatz für die abstrakte Beschreibung der Architektur. KobrA ist produktlinien-typisch wieder in zwei Prozesse unterteilt, die als Framework Engineering und Application Engineering bezeichnet werden. In ersterem wird die Plattform entwickelt, welche nach KobrA eine Art Framework darstellen, das aus einer Menge sog. KobrA-Komponenten besteht, die in einer baumartigen Hierarchie angeordnet sind. Zusammengefasst stellt KobrA eine einfache Methodik dar, die nicht zu viel Entwicklungs-Overhead erzeugt und mit angemessenem Aufwand von Entwicklern anwendbar ist [Ma04]. Außerdem ist KobrA in Buchform dokumentiert [ABB01]. Nachteilig wirkt sich die Verwendung von UML in der Version 1.0 auf die Möglichkeiten 26

28 Softwareproduktlinien der Architekturbeschreibung aus [Ba04]. Inzwischen stehen mit UML 2.0 umfangreichere Modellierungsmöglichkeiten zur Verfügung FeatuRSEB Featured Reuse-Driven Software Engineering Business (FeatuRSEB) ist eine Erweiterung der Produktlinien-Methodik RSEB [JGJ97] mit Konzepten aus FODA [Ka90], einer klassischen Domain Engineering-Methode. Der Ansatz von RSEB basiert auf der Erstellung von Anwendungsfällen (Use Cases), welche die Anforderungen an die Produktlinie beschreiben. Darauf folgt eine Ausarbeitung der Architektur, aus der am Ende Objektmodellen abgeleitet werden, die mit den ursprünglichen Use Case-Diagrammen durch Traceability-Links verbunden sind. Zur Definition von Variationspunkten in den Modellen erweitert RSEB UML-Diagramme mit neuen Notationen. Im Einzelnen sind in RSEB die folgenden Prozesse definiert: Requirements Engineering Architecture Family Engineering Component System Engineering Application System Engineering Durch die Kombination mit FODA kommen in FeatuRSEB die beiden Schritte Domain Engineering und Feature Modelling hinzu. Insbesondere mit letzteren wurde RSEB um ein formales Feature-Modell zur Definition von Gemeinsamkeit und Variabilität der Plattform erweitert. In FeatuRSEB sind dementsprechend sowohl Use Case- als auch Feature-Modelle von zentraler Bedeutung. In Kapitel 4.3 wird jedoch eine kritische Betrachtung von Feature- Modellen zur Beschreibung der Variabilität von Produktlinien erfolgen. Beide Diagrammtypen werden nebeneinander erstellt und zwischen ihnen Traceability-Links spezifiziert. Die Notation von Variationspunkten erfolgt durch eigene Erweiterungen von UML- Diagrammen SEI Produktlinien-Framework Das Produktlinien-Framework des Software Engineering Institutes (SEI) der Carnegie Mellon University ist in [CN01] veröffentlicht und seitdem ständig weiterentwickelt worden. Die Dokumentation des Frameworks ist sowohl in Buchform als auch über die Webseiten der Produktlinien-Initiative 1 des SEI verfügbar. Das in Abbildung 16 dargestellte Logo der Initiative stellt die drei Hauptaktivitäten Core Asset Development, Product Development und Management in Relation. Die ersten beiden entsprechen den aus anderen Methodiken bekannten Prozessen Domain und Application Engineering. Der dritte stellt die technischen und organisatorischen Management- Tätigkeiten zur Initiierung und Erhaltung der Produktlinie dar

29 Softwareproduktlinien Charakteristisch ist die feste Verzahnung der drei Aktivitäten miteinander sowie der im Gegensatz zu anderen Frameworks stärker hervorgehobene Management-Prozess. Core Asset und Product Development stellen iterative Vorgehen dar, die nebenläufig durchgeführt werden können, da entweder Core-Assets aus bestehenden Produkten abgeleitet oder Produkte aus Core-Assets entwickelt werden. Die beiden Aktivitäten stehen dabei immer unter der Kontrolle des Management-Prozesses. Von zentraler Bedeutung sind auch wieder Feedback-Schleifen zwischen den Prozessen: Core Assets können mit den Erfahrungen jedes neuen Produktes verbessert werden und umgekehrt profitiert jedes neue Produkt von bewährten Core-Assets. Damit das Feedback seine Wirkung zielgerichtet entfalten kann, werden Traceability-Links zur Verbindung von Core Assets in beiden Entwicklungsprozessen definiert. Core Asset Development Product Development Management Abbildung 16 Hauptaktivitäten im Framework des SEI [CN01] Zur Umsetzung der drei Hauptprozesse enthält das Framework 29 sogenannte Practice Areas, die Richtlinien und Vorgehensweisen zu einzelnen Tätigkeiten in der Produktlinienentwicklung beschreiben und von Einzelsystemen adaptiert wurden. Sie sind in folgende Bereiche unterteilt: Software Engineering Practice Areas bezeichnen Tätigkeiten, die sich mit der Entwicklung und Wartung von Core-Assets sowie von Produkten beschäftigen. Dazu zählen z.b. Architekturentwicklung, Requirements Engineering, Komponenten-Entwicklung und Testen. Technical Management Practice Areas sind organisatorische Aktivitäten, wie bspw. Risikomanagement, Projektplanung, Scoping oder Konfigurationsmanagement. Organizational Management Practice Areas bezeichnen betriebswirtschaftliche Aufgaben, zu denen bspw. Marktanalyse, Organisationsplanung, Geschäftsmodellentwicklung oder Training gehören. Sie werden u.a. zur Einführung und Evolution der Produktlinienentwicklung im Unternehmen benötigt. Das SEI-Framework beschreibt Tätigkeiten auf einem abstrakten Niveau und kann an unterschiedliche Prozesse angepasst werden. Es ist nicht sofort einsetzbar, sondern es muss zunächst ein Tailoring auf die Projekt-Umgebung stattfinden. Das Framework stellt jedoch ein Standardwerk mit vielen Lösungen zu einzelnen Problemen dar, die auch unabhängig von der Entwicklungsmethodik anwendbar sind. 28

30 Softwareproduktlinien Framework nach Pohl, Böckle, Van der Linden Das Produktlinien-Framework nach [PBL05] basiert auf Ergebnissen der drei großen europäischen Forschungsprojekte ESAPS 1, CAFÉ 2 und FAMILIES 3. Es ist umfangreich in Lehrbuchform dokumentiert und deckt alle wichtigen Bereiche der Produktlinienentwicklung ab. Das Buch stellt das erste in einer Serie von drei Büchern dar, welche die Ergebnisse der Forschungsprojekte publizieren und systematisch aufbereiten. Es zählt damit zu den aktuellsten Werken auf dem Gebiet der Produktlinienentwicklung. An dieser Stelle sei auch auf das zweite Buch [KD06] aus der Serie verwiesen, das ein Sammelwerk von derzeit neuesten Forschungsbeiträgen ist. Das Framework enthält Lösungen zu allen Bereichen des BAPO-Modells (siehe Einleitung, Kapitel 1.3) auf einer abstrakten Ebene und muss durch ein Tailoring an die konkrete Projektumgebung angepasst werden. Ein wichtiges Merkmal des Frameworks gegenüber den anderen erläuterten Methodiken stellt ein Variabilitätsmodell dar, das orthogonal zu vorhanden Diagrammen definiert verwendet werden kann. Dazu ist keine Einführung neuer Notationen nötig. Außerdem unterstützt das Framework die Auswahl und Integration von COTS-Komponenten (commercial-off-the-shelf [PBL05, Kapitel 14]) in die Plattform. Der im Framework beschriebene Prozess ähnelt aufgrund der gleichen Herkunft dem PRAISE-Referenzprozess (vgl. Kapitel 3.1.1, Abbildung 11) mit der klassischen Trennung von Domain und Application Engineering. Zusätzlich fügt es einen Product Management- Teilprozess sowie Qualitätssicherungsmaßnahmen in Form des Domain und Application Testings ein. Die Autoren weisen darauf hin, dass für eine erfolgreiche Produktlinienentwicklung alle im Framework spezifizierten Teilprozesse zur Anwendung kommen müssen. Jedoch können sie in existierende, organisationsspezifische Prozesse eingebettet werden, wie bspw. in den FAST-Prozess [PBL05, Kapitel 2]. Für die Fallstudie wurde dieses Framework aufgrund seiner Flexibilität, der guten Dokumentation in Lehrbuchform sowie der Tatsache, dass es als derzeit modernste Produktlinien-Methodik bezeichnet werden kann, ausgewählt. Im nächsten Kapitel erfolgt eine umfassendere Einführung

31 Produktlinien-Framework 4 Produktlinien-Framework In den vorhergehenden Kapiteln wurden die Grundlagen der Produktlinienentwicklung erläutert und sechs konkrete Methodiken bzw. Frameworks vorgestellt, aus denen das Framework nach [PBL05] als Basis für das elateportal-projekt ausgewählt worden ist. Da es keinen expliziten Namen besitzt, wird es in den weiteren Erläuterungen mit der Bezeichnung SPL-Framework referenziert. Wie in der Einleitung erwähnt, liegt das Hauptaugenmerk der Fallstudie auf der Architektur sowie dem Entwicklungsprozess. Obwohl Geschäfts- und Organisationsbetrachtungen in kommerziellen Anwendungen eine sehr wichtige Rolle spielen, haben sie im Open-Source-Bereich oft eine eher untergeordnete Bedeutung was auch auf das elateportal-projekt zutrifft. 4.1 Referenzprozess Abbildung 17 zeigt eine Übersicht des Frameworks mit einer Darstellung der beiden Hauptprozesse Domain und Application Engineering sowie ihren entsprechenden Teilprozessen. Domain Engineering Product Management Domain Requirements Engineering Domain Design Domain Realisation Domain Artefacts incl. Variability Model Domain Testing Requirements Architecture Components Tests Application Engineering Application Requirements Engineering Application Design Application Realisation Application N Artefacts incl. Variability Model Application 1 Artefacts incl. Variability Model Application Testing Requirements Architecture Components Tests Abbildung 17 SPL-Framework [PBL05] Domain Engineering Im Domain Engineering wird die Produktlinien-Plattform mit ihren wiederverwendbaren Artefakten entwickelt. Dazu müssen zunächst die Gemeinsamkeit und Variabilität der Produktlinie ermittelt und die späteren Applikationen spezifiziert werden, bevor die Definition und Realisierung der Artefakte erfolgen kann. Das Domain Engineering besteht aus fünf Teilprozessen, von denen die in der Fallstudie betrachteten in Abbildung 17 gelb hinterlegt sind. 30

32 Produktlinien-Framework Der Hauptunterschied zur Einzelsystementwicklung besteht in dem Vorhandensein von Variabilität, die im Variabilitätsmodell definiert ist. Jeder Teilprozess muss dieses Modell verfeinern und in der Regel auch zusätzliche Variabilität einführen. Außerdem erfolgt neben dem Erstellen von Artefakten für den nachfolgenden Prozess auch Feedback zurück zum vorhergehenden (Feedback-Schleifen). Die Fallstudie konzentriert sich auf Domain Requirements Engineering, Domain Design sowie Domain Realisation, welche die eigentlichen Entwicklungs-Prozesse darstellen. Im Domain Requirements Engineering erfolgt die Erfassung von variablen und gemeinsamen Anforderungen an die Produktlinie. Diese sind Vorausetzung für das Domain Design, das eine Referenzarchitektur (grobes Design) definiert, die schließlich im Domain Realisation verfeinert und implementiert wird. Eine Betrachtung des Domain Testings als zentraler Qualitätssicherungsprozess im SPL- Framework erfolgt in Kapitel 8, das eine allgemeine Sichtweise auf die Verifikation und Validierung der Plattform enthält. Es beschränkt sich nicht nur auf Testen, sondern erläutert auch Ansätze zur statischen Analyse des Quellcodes Application Engineering Im Application Engineering erfolgt die Erstellung konkreter Applikationen aus der Plattform mit dem Ziel, einen hohen Wiederverwendungsgrad zu erreichen. Wie in Abbildung 17 dargestellt, besteht es aus vier Teilprozessen, die jeweils in Relation zu ihrem Äquivalent im Domain Engineering stehen. Die Application Engineering- Teilprozesse nutzen einerseits die Plattformartefakte und bieten andererseits Feedback bzgl. ihrer Anwendbarkeit. Dazu gehören auch Anfragen nach neuer Funktionalität, die noch nicht Bestandteil der Plattform ist. Da die Plattform oft nicht alle für eine bestimmte Applikation nötigen Artefakte bereitstellen kann, besteht eine wichtige Aufgabe in der Ermittlung der sog. Deltas. Sie beschreiben, welche Artefakte im Application Engineering zusätzlich zu den bereits vorhandenen entwickelt werden müssen und ermöglichen damit eine Bestimmung des Aufwands bzw. der Zusatzkosten. Außerdem erfolgt im Application Engineering die Bindung der Variabilität durch Auswahl konkreter Varianten für Variationspunkte. Obwohl, wie bereits in der Einleitung erläutert, das Application Engineering keinen direkten Betrachtungsgegenstad der Fallstudie darstellt, sind vereinzelt Erfahrungen aus der Praxis enthalten, die zur Charakterisierung der Vorgehensweise sinnvoll sind. 4.2 Product Management Der Teilprozess des Product Management befasst sich mit den ökonomischen Aspekten von Produktlinien und hat damit wesentlichen Einfluss auf die wirtschaftliche Zukunft eines Unternehmens. Alle Teilprozesse des Domain und Application Engineerings sind von den Ergebnissen des Product Managements betroffen. Ergebnis des Product Managements ist eine Roadmap mit zukünftigen Produkten, ihren Features und einem Zeitplan. Features bezeichnen dabei die nach außen bzw. für Benutzer sichtbaren Funktionen der Produkte. Um auf neue Entwicklungen des Marktes reagieren zu können, sollte die Roadmap auch mögliche weitere, erst in Zukunft relevante Einsatzszena- 31

33 Produktlinien-Framework rien berücksichtigen. Wie bereits in Kapitel 3 erwähnt, fließen häufig auch bereits existierende Systeme in die Betrachtung mit ein. Dementsprechend nimmt das Product Management für Produktlinien einen wesentlich höheren Stellenwert als bei der Einzelsystementwicklung ein. Das SPL-Framework betrachtet ausführlich die mit Product Management zusammenhängenden Tätigkeiten, die von traditionellen Aktivitäten, wie Produktstrategieentwicklung und Produkteinführung, über das Portfolio-Management bis hin zum essentiellen Scoping (vgl. Kapitel 3.3) reichen. Ob diese ökonomischen Betrachtungen auch im Open-Source- Bereich nötig sind, hängt von den Sponsoren und Entwicklern ab, die evtl. ein bestimmtes Geschäftsmodell mit Open-Source-Software verknüpfen. Für ausführlichere Betrachtungen sei an dieser Stelle auf [Be99] verwiesen. Im Rahmen der Fallstudie beschränkte sich das Product Management auf konzeptionelle Betrachtungen zu möglichen späteren Einsatzfeldern sowie auf Abgrenzungskriterien zu bereits in der Hochschullandschaft existierenden Systemen, mit denen eine Integration angestrebt wurde. 4.3 Variabilitäts-Modell Die Modellierung von Variabilität ist eine grundlegende Tätigkeit der Produktlinienentwicklung, die alle Teilprozesse des Domain Engineerings betrifft. Einen wichtigen Vorteil des SPL-Frameworks stellt die Verwendung eines Variabilitätsmodells dar, das orthogonal zu bestehenden Diagrammen definiert wird. In den meisten Produktlinien-Frameworks wurde die Modellierung von Variabilität durch Erweiterung bestehender Metamodelle und durch Einführung neuer Notationen realisiert. So existieren insbesondere für UML verschiedene Erweiterungen, um sie mit Variabilität versehen zu können [JM02, ML02]. Diese Ansätze haben allerdings folgende Nachteile [BLP04]: Die Modelle werden durch die Erweiterungen komplexer und unübersichtlicher. Variationspunkte und Varianten können nicht modellübergreifend definiert und damit Änderungen schlecht bzgl. der Darstellung in anderen Diagrammen nachverfolgt werden. Die Variabilität kann nicht konsistent über mehrere Teilprozesse hinweg modelliert werden. Darüber hinaus werden oft Feature-Modelle (vgl. FODA in Kapitel 3.6.4) zur Anforderungsmodellierung verwendet, da diese selbst bereits Variabilität enthalten [KLD02, FFB02]. Allerdings haben speziell Feature-Modelle das Problem, dass deren Ausdruckskraft bestimmten Aspekten von Produktlinien nicht gerecht wird. Zum Beispiel muss oft Variabilität modelliert werden, die zur Implementierung bestimmter Funktionalität nötig, aber nicht für die Produktlinie relevant ist. Zum einen ist diese Unterscheidung in Feature- Modellen nicht möglich und zum anderen beschreiben sie nur eine statische Sicht der Produktlinie. Allerdings existieren wiederum verschiedene Erweiterungen für Feature- Modelle, auf die an dieser Stelle nicht näher eingegangen wird. Um den genannten Problemen zu begegnen enthält das SPL-Framework als integralen Bestandteil ein orthogonales Variabilitätsmodell. Eine erste Version des Modells ist bereits 32

34 Produktlinien-Framework von Bachmann et al. in [Ba03] vorgestellt worden. Von zentraler Bedeutung ist, dass damit die Modellierung von Variabilität über Artefakte und Prozessgrenzen hinweg ermöglicht wird und keine Eingriffe in bestehende Modelle notwendig sind Metamodell Das orthogonale Variabilitätsmodell besteht aus zwei Bestandteilen: einem Metamodell und einer darauf basierenden graphischen Notation. Das Metamodell definiert die beiden zentralen Elemente Variationspunkt (Variation Point) und Variante (Variant), die zueinander in Relation stehen. Abbildung 18 stellt den entsprechenden Ausschnitt des Metamodells dar, eine vollständige Version ist in Anhang A.1, Abbildung 51 zu finden. 1..* 1..* Variation Point Variant {complete, disjoint} Variability Dependency Internal Variation Point {complete, disjoint} External Variation Point Optional Mandatory Abbildung 18 Variationspunkt und Variante im Metamodell [PBL05] In der Abbildung ist zu erkennen, dass bei Variationspunkten zwischen externer und interner Variabilität unterschieden wird. Dabei bezeichnet erstere die nach außen, d.h. für Auftraggeber und Nutzer, sichtbare Variabilität. Zur Umsetzung impliziert sie oft die Einführung zusätzlicher, interner Variabilität, welche aus Gründen der Übersichtlichkeit und Komplexitätsreduktion nach außen versteckt werden soll. Darüber hinaus formalisiert das orthogonale Variabilitätsmodell weitergehende Beziehungen zwischen einzelnen Varianten sowie die Erstellung von Traceability-Links Traceability Traceability gewährleistet die Nachverfolgbarkeit zwischen Elementen des Variabilitätsmodells und ihrer Repräsentation in anderen Artefakten, wie z.b. Diagrammen, Implementierungen und Testdokumenten, siehe Abbildung 19. Variabilität Veranstaltung konfigurieren «include» «include» «include» /** * Generate the PSML tree from course hierarchy definitions ElatePortalException */ public synchronized void build() throws ElatePortalException { Einschreibungen verwalten FileArea administrieren RuntimeException e = (RuntimeException) Subject.doAsPrivileged( admin, new PrivilegedAction(){ Forum administrieren public Object run(){ try { Requirements Design Realisation Test Abbildung 19 Traceability im Variabilitätsmodell (nach [PBL05]) 33