Softwareproduktlinien-Entwicklung – Domain Engineering ...berger/Diplomarbeit.pdf · kleinen und...

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

1

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.

Inhaltsverzeichnis

2

Inhaltsverzeichnis

1 Einleitung ............................................................................................................ 4 1.1 Motivation..................................................................................................... 4 1.2 Zielsetzung.................................................................................................... 5 1.3 Abgrenzung................................................................................................... 5 1.4 Aufbau der Arbeit ......................................................................................... 6

2 Betrachtungsgegenstand .................................................................................... 8 2.1 Entstehung .................................................................................................... 8 2.2 elatePortal-Projekt ........................................................................................ 9 2.3 Technologien, Umgebungen und Ansätze .................................................. 16 2.4 Weitere Arbeiten......................................................................................... 17

3 Softwareproduktlinien ..................................................................................... 18 3.1 Grundlagen und Definition ......................................................................... 18 3.2 Begriffsbestimmung.................................................................................... 20 3.3 Klassisches Domain Engineering ............................................................... 21 3.4 Vorteile ....................................................................................................... 21 3.5 Kosten und Risiken..................................................................................... 22 3.6 Methodiken und Frameworks ..................................................................... 24

4 Produktlinien-Framework............................................................................... 30 4.1 Referenzprozess .......................................................................................... 30 4.2 Product Management .................................................................................. 31 4.3 Variabilitäts-Modell.................................................................................... 32 4.4 Einfluss agiler Prinzipien............................................................................ 34

5 Domain Requirements Engineering................................................................ 37 5.1 Kontext........................................................................................................ 37 5.2 Artefakte ..................................................................................................... 37 5.3 Vorgehen und Aktivitäten........................................................................... 39 5.4 Basisanforderungen in der Fallstudie ......................................................... 40 5.5 Commonality Analysis ............................................................................... 43 5.6 Variability Analysis .................................................................................... 44 5.7 Variability Modelling ................................................................................. 46 5.8 Auswertung................................................................................................. 48

6 Domain Design .................................................................................................. 50 6.1 Kontext........................................................................................................ 50 6.2 Artefakte ..................................................................................................... 51 6.3 Vorgehen und Aktivitäten........................................................................... 53 6.4 Komponenten-Framework .......................................................................... 55 6.5 Referenzarchitektur..................................................................................... 57

Inhaltsverzeichnis

3

6.6 Aufgaben-Framework................................................................................. 59 6.7 elatePortal ................................................................................................... 62 6.8 Prüfungsserver ............................................................................................ 64 6.9 Auswertung................................................................................................. 65

7 Domain Realisation .......................................................................................... 68 7.1 Kontext........................................................................................................ 68 7.2 Artefakte ..................................................................................................... 68 7.3 Vorgehen und Aktivitäten........................................................................... 70 7.4 Build-Management und Deployment.......................................................... 72 7.5 Detailliertes Design des Aufgaben-Frameworks ........................................ 74 7.6 Detailliertes Design des elatePortals........................................................... 76 7.7 Detailliertes Design des Prüfungsservers ................................................... 79 7.8 Bindung von Variabilität ............................................................................ 79 7.9 Auswertung................................................................................................. 81

8 Verifikation und Validierung .......................................................................... 83 8.1 Inspektionstechniken .................................................................................. 83 8.2 Domain Testing........................................................................................... 84 8.3 Automatische statische Analyse ................................................................. 85 8.4 Unit-Tests.................................................................................................... 86 8.5 Integrations-Tests........................................................................................ 87 8.6 System-Tests............................................................................................... 89

9 Zusammenfassung ............................................................................................ 90 9.1 Produktlinien-Forschung ............................................................................ 90 9.2 Tailoring und Praxis.................................................................................... 91 9.3 Ausblick ...................................................................................................... 91

Anhang.................................................................................................................. 93 A.1 Aufgaben-Framework: Implementierte Aufgabentypen............................ 93 A.2 Orthogonales Variabilitätsmodell .............................................................. 95 A.3 Detaillierte Design-Artefakte..................................................................... 95 A.4 Test-Strategien für Produktlinien .............................................................. 99

Abbildungsverzeichnis ...................................................................................... 100

Abkürzungsverzeichnis ..................................................................................... 102

Literaturverzeichnis .......................................................................................... 105

Einleitung

4

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 Entwick-lungsparadigmen 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 Serviceori-entierte 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-

Einleitung

5

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 wer-den?

(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ßgeschnei-dert?

(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.

Einleitung

6

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 Charakteri-sierung erfolgt. Insbesondere werden Punkte betrachtet, die den Erfolg von Softwarepro-duktlinien 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

Einleitung

7

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.

Betrachtungsgegenstand

8

2 Betrachtungsgegenstand

In diesem Kapitel erfolgt eine Einführung in das elatePortal-Projekt als Betrachtungsge-genstand der Fallstudie. Beginnend mit einem kurzen Abriss über die Entstehungsge-schichte 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 UebManager1 zurückführen, das eine webbasierte Umgebung zur Unterstützung von Übungsseminaren bereitstellte und erfolgreich an der Abteilung Betriebliche Informationssysteme2 (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ät3 zielten. Gründe dafür stellten hohe Prüfungsbelas-tungen 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 Erziehungswissenschaftli-chen 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 Funktions-umfang 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.

1 http://uebman.sourceforge.net 2 http://bis.informatik.uni-leipzig.de 3 http://www.uni-leipzig.de/~erzwiss


9

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 Allgemeinmedizin1, die außerdem eine Web-Präsenz benötigte. So existierten schließlich Anforderungen an ein neues System in unterschiedli-chen 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-) Informations-systeme 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

http://www.elateportal.de

erreichbar und wird von SourceForge.net2 gehostet. Über sie sind die Quelltexte, Dokumentationen, Bug- und Feature-Tracker sowie die Mailinglisten des Projekts verfügbar.

1 http://db.uni-leipzig.de/lageplan/index.php?kst=89980126 2 http://www.sourceforge.net


10

elatePortalJ2EE-Portalapplikation

examServerJ2EE-Webapplikation

Web Service

Tasklet

TaskletCorrection

TaskDef

TaskletContainer

Life-cycle

Taskmodel-API

Taskmodel-CORE (RI mit Spring)

Taskmodel-CORE-VIEW

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.

2.2.1 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 Eindruck1 ü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: http://www.uni-leipzig.de/medienportal/toolfinder/elate.html


11

Abbildung 3 Persönliche Oberfläche

Abbildung 4 Anpassung der Oberfläche


12

Die nächsten Abbildungen zeigen jeweils verschiedene Administrations-Portlets.

Abbildung 5 eMail-Benachrichtigungen

In Abbildung 5 ist ein Portlet zum Editieren von eMail-Vorlagen abgebildet. Derartige eMails 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


13

Abbildung 6 zeigt die Administration von Einschreibungen, die innerhalb von Veranstal-tungen angelegt werden können, wie bspw. Tutorien, Übungsgruppen oder die Wahl des Prüfungstermins.

Abbildung 7 Veranstaltungs-Konfiguration


14

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).

2.2.2 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

2.2.3 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üh-rung 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 Zusammen-stellung individueller Prüfungen und insbesondere die semiautomatische Korrektur von Aufgaben. Letzteres bedeutet, dass nicht automatisch auswertbare Aufgaben Korrektoren zugeordnet werden können.


15

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

2.2.4 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 JAXFront1 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

1 http://www.jaxfront.com


16

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-21, 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 JAAS2-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 aspektorien-tierte 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,

1 http://portals.apache.org/jetspeed-2/ 2 http://java.sun.com/products/jaas


17

die häufig GSE zugeordnet werden1, sei auf [VS06, BBG05] verwiesen. Neben dem JAXFront-Beispiel, das bzgl. dieser Zuordnung eine Ausnahme darstellt, wird insbesonde-re in Kapitel 7.6.5 eine auf Templates und in Kapitel 7.5.3 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

Softwareproduktlinien

18

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 com-mon, 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 Entwicklungsprozes-sen, 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.

3.1.1 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 Forschungs-projekt PRAISE [Es97] dargestellt, der die beiden genannten Grundsätze veranschaulicht. Alle Produktlinien-Methodiken basieren im Wesentlichen auf dieser Struktur, unterschei-


19

den sich aber häufig hinsichtlich der Herangehensweise an bestimmte Teilgebiete sowie der unterschiedlichen Gewichtung einzelner Prozesse.

Requirements Components

Familyassetrepository

Applicationengineering

Applicationrequirements

Applicationdesign

Applicationcoding

Newrequirements

Domainengineering

Domainanalysis

Legacy code

Domainexpertise Domain

implementationDomaindesign

TraceabilityTraceability

Domain terminology

Reference requirements...

Reference architecture Reusable components

Feedback / adaptations /reverse architecting

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).

3.1.2 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 modellba-sierten 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].


20

Reus

ele

vel

Sing

lesy

ste

ms

mul

tiple

syst

em

fam

ilie

s

Development paradigms

Structuredprogramming

Object-orienteddevelopment

Component-baseddevelopment

Agent-baseddevelopment ??

Domain-pervasive

reuse

Architectedreuse

Managedreuse

Plannedreuse

Informalcode reuse

Noreuse

Model-DrivenDevelopment

Abbildung 12 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 Forschungsgemein-schaften getrennt mit der Software-Produktlinienentwicklung beschäftigt haben. Als es 1996 in Las Navas, Spanien zu einem ersten Arbeitskontakt kam, waren beide Terminolo-gien 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.


21

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, dis-semination, 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,


22

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, Komponen-ten 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 Entscheidungsfin-dung 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]


23

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.

3.5.1 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

500,000

400,000

300,000

200,000

100,000

o1 2 3

Number of products4 5

Cum

ulat

ive co

sts o

f pro

duct

s (US

dol

lars)

Single productHeavyweightLightweight

Abbildung 13 Kostenvergleich Einführungsstrategien [Gr02]

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.

3.5.2 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 Wiederver-wendungspotential 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].


24

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].

3.6.1 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].

Domain EngineeringDefine the family and develop

production facilities

ProcessProduct

Application Engineering:Produce Applications

Feedback(Customer needs)

Feedback(Production

needs)

Production Facilities:ApplicationEngineeringEnvironment

ApplicationsKey:

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


25

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.

3.6.2 Fraunhofer PuLSE

Die Product Line Software Engineering-Methodik (PuLSE) [Ba99] ist eine Entwicklung des Fraunhofer-Instituts für Experimentelles Software-Engineering1 (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 Produktlinien-entwicklung zu unterstützen.

Support Components

Deployment Phases

PuLSE Initialization

Product Line Infrastructure Construction

Product Line Infrastructure Usage

ProductLine

InfrastructureEvolution

Project Entry Points Organizational Issues Maturity Scale

Technical Components

Customizing

Scoping

Modeling

Architecting

Designing

Coding

Testing and Inspection

Instantiating

Evolving and Managing

Support Components

Deployment Phases

PuLSE Initialization

Product Line Infrastructure Construction

Product Line Infrastructure Usage

ProductLine

InfrastructureEvolution

Project Entry Points Organizational Issues Maturity Scale

Technical Components

Customizing

Scoping

Modeling

Architecting

Designing

Coding

Testing and Inspection

Instantiating

Evolving and Managing

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.

1 http://www.iese.fraunhofer.de


26

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 aus-gewä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.

3.6.3 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 Ent-wicklungs-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


27

der Architekturbeschreibung aus [Ba04]. Inzwischen stehen mit UML 2.0 umfangreichere Modellierungsmöglichkeiten zur Verfügung.

3.6.4 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 Diagramm-typen werden nebeneinander erstellt und zwischen ihnen Traceability-Links spezifiziert. Die Notation von Variationspunkten erfolgt durch eigene Erweiterungen von UML-Diagrammen.

3.6.5 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-Initiative1 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.

1 http://www.sei.cmu.edu/productlines/plp_init.html


28

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 AssetDevelopment

ProductDevelopment

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 Produktli-nienentwicklung 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, Komponen-ten-Entwicklung und Testen.

• Technical Management Practice Areas sind organisatorische Aktivitäten, wie bspw. Risikomanagement, Projektplanung, Scoping oder Konfigurationsmanage-ment.

• Organizational Management Practice Areas bezeichnen betriebswirtschaftliche Aufgaben, zu denen bspw. Marktanalyse, Organisationsplanung, Geschäftsmodell-entwicklung 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.


29

3.6.6 Framework nach Pohl, Böckle, Van der Linden

Das Produktlinien-Framework nach [PBL05] basiert auf Ergebnissen der drei großen europäischen Forschungsprojekte ESAPS1, CAFÉ2 und FAMILIES3. Es ist umfangreich in Lehrbuchform dokumentiert und deckt alle wichtigen Bereiche der Produktlinienentwick-lung 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.

1 http://www.esi.es/esaps 2 http://www.esi.es/Cafe 3 http://www.esi.es/Families

Produktlinien-Framework

30

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 Organisationsbe-trachtungen 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.

Dom

ain

Eng

inee

ring

App

licat

ion

Eng

inee

ring

DomainRequirementsEngineering

DomainRealisation

DomainTesting

DomainDesign

ApplicationRequirementsEngineering

ApplicationRealisation

ApplicationTesting

Application 1 – Artefacts incl. Variability Model

Architecture Components TestsRequirements

Domain Artefacts incl. Variability Model

ProductManagement

Application N – Artefacts incl. Variability Model

ApplicationDesign

Requirements Architecture Components Tests

Abbildung 17 SPL-Framework [PBL05]

4.1.1 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.


31

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.

4.1.2 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-


32

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än-genden 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 Produktlinienent-wicklung, 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 nachver-folgt 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 Anforde-rungsmodellierung verwendet, da diese selbst bereits Variabilität enthalten [KLD02 , FFB02]. Allerdings haben speziell Feature-Modelle das Problem, dass deren Ausdrucks-kraft 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


33

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.

4.3.1 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.

Variation Point

Optional Mandatory

InternalVariation Point

ExternalVariation Point

{complete, disjoint}

Variant

VariabilityDependency

1..*1..*


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.

4.3.2 Traceability

Traceability gewährleistet die Nachverfolgbarkeit zwischen Elementen des Variabilitäts-modells und ihrer Repräsentation in anderen Artefakten, wie z.B. Diagrammen, Implementierungen und Testdokumenten, siehe Abbildung 19.

Variabilität

Requirements

Veranstaltungkonfigurieren

Einschreibungenverwalten

«include»

Forumadministrieren

«include»

FileAreaadministrieren

«include»

Design Realisation

/*** Generate the PSML tree from course hierarchy definitions* @throws ElatePortalException*/public synchronized void build() throws ElatePortalException {

RuntimeException e = (RuntimeException) Subject.doAsPrivileged( admin, new PrivilegedAction(){

public Object run(){try {

Test Abbildung 19 Traceability im Variabilitätsmodell (nach [PBL05])


34

Traceability-Links sind vor allem dann sinnvoll, wenn Änderungen in einem Artefakt vorgenommen werden müssen. Dann kann über die Links zu anderen Repräsentationen verzweigt und diese entsprechend geändert werden, um die Konsistenz der Artefakte sicherzustellen.

4.3.3 Graphische Notation

Abbildung 20 zeigt die graphische Notation des orthogonalen Variabilitätsmodells. Im oberen Teil sind Variationspunkte und Varianten skizziert. Einzelne Varianten können sich gegenseitig ausschließen (Alternative Choice) sowie entweder optional oder notwendig für einen Variationspunkt sein. Die Repräsentation von Traceability-Links ist in der Abbildung als Artifact Dependencies dargestellt.

Im unteren Teil befinden sich Beziehungen zwischen Variationspunkten und Varianten. Sie stellen die Einhaltung bestimmter Randbedingungen sicher, wie bspw. die Abhängig-keit einer Variante von einer anderen oder auch von einem weiteren Variationspunkt. Inbesondere können auch Variationspunkte von Varianten impliziert sein.

Variability DependenciesVariantVariation Point

VP

[name][name]

V optional

mandatory

Alternative Choice

[min..max]

Artefact Dependencies

artefact dependency

VP artefact dependency

Constraint Dependencies

requires_V_V requires_v_v requires_V_VP requires_v_vp requires_VP_VP requires_vp_vp

excludes_V_V requires_v_v excludes_V_VP requires_v_vp excludes_VP_VP requires_vp_vp

Abbildung 20 Graphische Notation des orthogonalen Variabilitätsmodells [PBL05]

4.4 Einfluss agiler Prinzipien

Während der Entwicklung des elatePortal-Projekts waren auch einige agile Prinzipien von Bedeutung und ließen sich zusätzlich zum SPL-Frameworks anwenden. Während sich agile und Produktlinien-Methodiken trotz gleicher Ziele mitunter grundlegend in ihren Praktiken und Prinzipien unterscheiden, wird häufig eine Verknüpfung empfohlen, um bestmöglichen Nutzen aus beiden zu ziehen [TC06, Bo02a]. So enthält z.B. das Produktlinien-Framework des SEI eine maßgeschneiderte Variante der agilen Methodik Rational Unified Process (RUP, vgl. [TC06]).

Die größten Unterschiede zwischen agilen und Produktlinien-Methodiken stellen die proaktive Entwicklung einer Basisplattform in Verbindung mit Vorab-Investitionen sowie


35

die Einführung von Variabilität und Flexibilität dar. Jedoch wird auch letzteres in der Literatur zu agilen Methoden kontrovers behandelt. Während oft argumentiert wird, dass sich der Zusatzaufwand bzgl. deren Umsetzung nicht auszahlt und Entwickler keine Entscheidungen vorziehen sollten, wird er in anderen Quellen empfohlen [HRS03], um flexibel auf Change Requests reagieren zu können und die Entwicklungsfähigkeit der Architektur zu verbessern.

Eine der wichtigsten Zusammenfassungen agiler Prinzipien entstand mit dem Agilen Manifest [Be01], auf dem die meisten agilen Methodiken basieren. Zu den bekanntesten gehören neben Extreme Programming (XP) [BA05] auch Adaptive Software Development [Hi00], Scrum [SB02], die Crystal-Methodenfamilie [Co06] sowie das bereits genannte RUP. Die Hauptaussage des Agilen Manifests ist, dass der Entwickler und die Kommuni-kation über Prozesse und Tools, funktionierende Software über vollständige Dokumentati-on, Kundeninteraktion über Vertragsverhandlungen und flexibles Change-Management über starre Pläne gestellt werden sollen.

4.4.1 Nebenläufige Entwicklung

Ein Software-Projekt versucht über einzelne Entwicklungs-Phasen hinweg einen Zustand der Stabilität zu erreichen. Dieser ist abhängig vom Fortschritt und von wichtigen Ereignissen, wie Abnahmen oder Reviews, die wiederum zu neuen Requirements führen können. Das impliziert eine Fluktuation von Stabilität im Projekt. Agile Methoden streben keine absolute Stabilität von einem Entwicklungszyklus zum nächsten an, wie es bei seriellen Entwicklungsprozessen der Fall ist. Stattdessen sollen sich die Phasen überlappen, um damit auf Kosten geringfügig erhöhten Aufwands Feedback und späte Änderungen zu vereinfachen.

Das ist eine Art nebenläufiger Entwicklung, die als Gold Rush Strategy bezeichnet wird [Co98] und deren zeitlicher Verlauf in Abbildung 21 skizziert ist. Dabei ist zu beachten, dass die Strategie nicht übertrieben wird, da zeitlich früher angesiedelte Phasen nach wie vor weniger Fluktuation aufweisen müssen als ihre Nachfolger. Ansonsten wird die Gesamtstabilität der Entwicklung gefährdet. In Extremfällen ist das Architektur-Design fertig, bevor das Requirements Engineering abgeschlossen werden konnte.

Requirements

Com

plet

enes

s, St

abili

ty

Testing

Time

UI & ObjectDesign

Programming

Abbildung 21 Nebenläufige Entwicklung [Co06]


36

Die Nebenläufigkeit ist auch deswegen sinnvoll, da selten perfekte Requirements definiert werden können, die nicht in späteren Entwicklungsphasen eine Überarbeitung benötigen [Co98].

4.4.2 Dokumentation

Eine weitere wichtige Frage ist die des Grades der Dokumentation. Während sie auch in der agilen Vorstellung von Softwareentwicklung nicht entfällt, wird stärker deren Notwendigkeit und Sinnhaftigkeit hinterfragt. Dokumentation soll nur erstellt werden wenn ein eindeutiger und wertschöpfender Grund für sie existiert, sie für eine bestimmte Zielgruppe nötig ist oder ein Sponsor dafür bezahlt. Cockburn [Co06] bezeichnet diesen Grundsatz mit light but sufficient.

Das elatePortal-Projekt verwendete zu Dokumentationszwecken eine Kombination aus Quelltext-Dokumentation (insb. in den APIs), einem für Entwickler zugängigen Wiki, Bug- und Feature-Trackern sowie zwei Mailinglisten. Bis auf die Quelltext-Dokumentation konnten die Dokumentationsformen durch Tools und Ressourcen unterstützt werden, die von Sourceforge (siehe Kapitel 2.2) bereitgestellt worden sind.

Domain Requirements Engineering

37

5 Domain Requirements Engineering

Im Rahmen der Produktlinienentwicklung dient das Requirements Engineering (RE) der Identifizierung und Dokumentation gemeinsamer bzw. variabler Anforderungen an die Plattform. RE im Allgemeinen gehört zu den wichtigsten Aktivitäten im Software Engineering und ist ein zentraler Faktor für den Erfolg des Projekts:

„The inability to produce complete, correct, and unambiguous software re-quirements is still considered the major cause of software failure today“. [Do97]

Requirements sind Aussagen über funktionale sowie nichtfunktionale Eigenschaften der zu entwickelnden Software, mit denen bestimmt wird, was das System später auf welche Art und Weise und mit welcher Qualität können soll. Eine ausführliche Definition ist in [IEEE90] zu finden. In den nachfolgenden Betrachtungen werden die Begriffe Require-ments und Anforderungen synonym verwendet.

5.1 Kontext

Die Ergebnisse der vorhergehenden Product Management-Phase, in der grundlegende Ziele bzgl. der Produktlinie festgelegt worden sind, stellen die Eingaben für das Domain RE dar. Aus diesen können wesentliche Anforderungen an die Produktlinie abgeleitet, ergänzt und gegebenenfalls mit Variabilität versehen werden. Sie bilden anschließend die Ausgangsba-sis für die Design-Phase.

In Abbildung 22 sind die Interaktionen des Domain RE mit den direkt angrenzenden Teilprozessen des SPL-Frameworks dargestellt.


ProductManagement

DomainDesign

ApplicationRequirementsEngineering

Abbildung 22 Kontext Domain Requirements Engineering

Ein wichtiger Aspekt ist die Wiederverwendung von Requirements aus der Plattform im Application RE. Im Optimalfall müssen keine zusätzlichen Requirements für die konkrete Applikation erstellt werden, sondern sie sind bereits vollständig als Plattform-Artefakte verfügbar. In umgekehrter Richtung ermöglicht eine Feedback-Schleife eine nachträgliche Übertragung applikationsspezifischer Anforderungen in die Plattform.

5.2 Artefakte

Die im RE zu erfassenden Anforderungen können in Form von textuellen Beschreibungen oder Modellen dokumentiert werden. Bei ersteren ist die Ausdruckskraft nur durch die natürliche Sprache begrenzt, dem aber mangels strenger Semantik die Gefahr der Zweideutigkeit gegenübersteht. Modelle bilden hier einen Kompromiss. Zu den


38

wichtigsten zählen Goal- und Feature-Modelle, Szenarien und Use Cases, aber auch Daten- und Verhaltensmodelle [So06, Pa98a]. Für eine ausführlichere Übersicht zu Modellie-rungsmethoden und ihrer Eignung für bestimmte Umgebungen sei auf [RK05] verwiesen. Darüber hinaus verfolgen Auer, Riechert und Fähnrich [ARF06] eine Anreicherung von textuellen Requirements-Artefakten mit Semantik zur agilen und verteilten Erfassung von Anforderungen

5.2.1 Szenarien

Es ist häufig einfacher zunächst die direkten Interaktionen von Nutzern mit dem System zu beschreiben und daraus dann Requirements in anderer Form zu erstellen. Dafür eignen sich Szenarien [So06, Kapitel 7], welche diese Interaktionen in einzelnen Schritten festhalten. Ihre Beschreibung kann entweder textuell, tabellarisch oder als UML-Sequenzdiagramm erfolgen.

Eine Ausprägung von Szenarien stellen die in agilen Methodiken, wie insb. XP favorisierten User Stories dar, die jeweils in Kooperation mit dem Auftraggeber erarbeitet werden. Ihre Notation erfolgt informal auf sog. Story Cards, aus welchen direkt Implementierungsschritte abgeleitet werden können.

Im elatePortal-Projekt wurden auf diese Weise häufig Anforderungen an die Plattform bzw. für eine der drei konkreten Applikationen festgehalten. Wenn sie zu umfangreich waren bildeten sie die Vorlage für formalere Darstellungen in UML.

5.2.2 Variabilität

Die Modellierung von Variabilität in Requirements-Modellen erfolgt im SPL-Framework mit Hilfe des orthogonalen Variabilitätsmodells. Da variable und gemeinsame Anforde-rungen häufig eng miteinander verknüpft sind, werden sie in der Regel nebeneinander in denselben Requirements-Artefakten modelliert. Abbildung 23 zeigt schematisch, wie das orthogonale Variabilitätsmodell zu diesen über Traceability-Links in Relation steht.

Orthogonales Variabilitätsmodell

VP

Variations-punkt 1

V

Variante 1.1

VP

Variations-punkt 2

V

Variante 2.1

V

Variante 2.2

V

Variante 2.3

V

Variante 1.2

Requirements-Artefakte

Gemeinsame Requirements(unveränderlicher Teil)

V 2.1 ... V 2.2 … V 2.3 ...

V 1.1 ... V 1.2 ...

Gemeinsame Requirements(unveränderlicher Teil)

Abbildung 23 Orthogonales Variabilitätsmodell und Requirements-Beschreibungen (nach [PBL05])


39

5.2.3 Priorisierung

Requirements können zusätzlich eine Priorisierung erhalten, die ihre Bedeutung für die Produktlinie genauer spezifiziert. Das unterstützt spätere Design-Entscheidungen, da die Referenzarchitektur in erster Linie von den wichtigeren Anforderungen bestimmt wird. Eine durchgängige Beschreibung der Priorisierung von Requirements wird jedoch weder im orthogonalen Variabilitätsmodell noch in UML-Diagrammen unterstützt.

5.3 Vorgehen und Aktivitäten

Traditionelle Aktivitäten im RE für einzelne Systeme umfassen das Finden und Verstehen von Anforderungen, ihre Analyse, Dokumentation, Verifizierung und das Management derselben [CN01, Kapitel 4.6]. Im Produktlinien-Kontext kommen noch einige Tätigkeiten hinzu, die sich mit den speziellen Aspekten von Variabilität in der Plattform beschäftigen und eng miteinander verknüpft sind [WL99]:

• Commonality Analysis: Analyse der gemeinsamen Anforderungen aller Systeme der Produktlinie

• Variability Analysis: Analyse der Anforderungen, die sich in den Systemen der Produktlinie unterscheiden

• Variability Modelling: Modellierung von Variationspunkten, möglichen Varianten und ihren Beziehungen

Diese Tätigkeiten sind auch Betrachtungsgegenstand der Fallstudie in diesem Kapitel und werden auf die Basisanforderungen drei konkreter Applikationen angewendet.

5.3.1 Schritte

Im Domain RE des SPL-Frameworks erfolgt die Erstellung von mit Variabilität versehenen Requirements-Artefakten in zwei Schritten. Diese werden zur Verfeinerung iterativ wiederholt und in ihnen spielen die eben genannten Tätigkeiten eine wichtige Rolle:

• Definition der gemeinsamen Requirements: Auf Basis der Commonality Analysis werden gemeinsame Anforderungen identifiziert und in geeigneter Form dokumen-tiert.

• Definition der variablen Requirements: In diesem Schritt erfolgt die Identifizierung variabler Anforderungen mit Hilfe der Variability Analysis sowie ihre Dokumenta-tion in geeigneten Modellen. Außerdem muss die Variabilität selbst definiert wer-den, was in der drittgenannten Tätigkeit Variability Modelling mit Hilfe des ortho-gonalen Variabilitätsmodells erfolgt.

5.3.2 Wechselwirkung mit der Design-Phase

Das RE kann insbesondere durch die Einführung von Variabilität sehr komplex werden. Um dem zu entgegnen forciert das SPL-Framework eine iterative Verfeinerung der Requirements in Wechselwirkung mit der Design-Phase sowie deren Modellierung in verschiedenen Abstraktionsstufen. Während die Architektur der Plattform immer stärker Formen annimmt, werden in der Regel auch genauer spezifizierte Requirements benötigt.


40

Dieser Verlauf wird mit einer Spirale im Twin Peaks Model [Nu01] charakterisiert, das in Abbildung 24 skizziert ist.

Requirements Architecture

Specification

DetailedIndependent Dependent

Coarse

RealisationDependence

Levelof

detail

ProblemView

Solution View

Abbildung 24 Twin Peaks Model (nach [Nu01])

Im Domain Design ist die Beurteilung der Umsetzbarkeit von (mit Variabilität versehenen) Requirements besser möglich. Ziel der iterativen Vorgehensweise ist es, die Requirements-Artefakte qualitativ so zu verbessern, dass sie eine stabile Ausgangsbasis für den weiteren Verlauf der Entwicklung darstellen.

5.4 Basisanforderungen in der Fallstudie

Im Folgenden sind grundlegende Anforderungen dargestellt, anhand derer die produktli-nienspezifischen Aktivitäten ausgeführt und im Hinblick auf ihre Eignung in der Fallstudie betrachtet werden.

In Anlehnung an ein Beispiel aus [PBL05, Kapitel 10] stellten die Verwendung von Goal- und Feature-Listen sowie die textuelle Beschreibung von Requirements eine solide Ausgangsbasis für die Commonality und Variability Analysis dar. Die ersten Entwürfe für die Erziehungswissenschaftliche Fakultät, die Abteilung für Betriebliche Informationssys-teme sowie die Abteilung für Allgemeinmedizin (vgl. Kapitel 2.1) sind in den folgenden drei Abbildungen skizziert.


41

Abbildung 25 Basisanforderungen Erziehungswissenschaftliche Fakultät

Es ist zwar auch möglich, bereits in dieser zeitigen Phase Anforderungen in Form von Modellen bzw. Diagrammen zu notieren, worauf aber verzichtet wurde. Als Gründe sind zum einen die bessere Lesbarkeit für Personen, die nicht mit den speziellen Notationen in Modellen vertraut sind und zum anderen die Tatsache zu nennen, dass die Anforderungen noch nicht sehr stabil waren.

Außerdem mussten die in den drei Abbildungen dargestellten ursprünglichen Anforderun-gen verfeinert und differenzierter strukturiert werden, da durch Architekturbetrachtungen im Domain Design die Entwicklung zweier Systeme (des elatePortals und des Prüfungs-servers) fokussiert wurde. Diese Entscheidung ist maßgeblich von hohen Sicherheitsanfor-derungen bestimmt worden, die eine strikte Trennung zwischen sensiblen Prüfungsdaten und anderen (ebenfalls sensiblen) studentischen Daten aus dem Portal vorsahen.

Goals: – G1: effizientere Durchführung von Prüfungsklausuren durch Computerunterstützung – G2: Organisation und Management von Lehrveranstaltungen – …

Features: – F1: Prüfungsmodul:

• F1.1: Aufgabentypen: Datei hochladen, Multiple Choice, Zuordnung, Lückentext, Freitext, Graphische Darstellung

• … – F2: Lehrveranstaltungen mit:

• F2.1: Einschreibungen • F2.2: Übungsaufgaben • F2.3: Forum • F2.4: Download-Bereich

– F3: Benutzerverwaltung – F4: Authentifizierung – …

Requirements: – R1.1: Unterstützung des kompletten Prüfungsablaufs – R1.2: Vermeidung von Medienbrüchen – R1.3: Sicherung der Prüfungsklausuren gegen Betrug, Täuschung und Manipulation – R1.4: Zugriff auf Prüfungsaufgaben nur unter klausurähnlichen kontrollierten Bedingungen – R1.5: sichere Identifikation der Teilnehmer – R1.6: Erweiterbarkeit mit versch. Aufgabentypen – R1.7: manuelle Korrektur mit 20 Tutoren – R1.7.1: Korrektur anonymisiert – R1.7.2: zufällige Zuordnung der Aufgaben – R1.8: Zugriff auf Übungsklausuren von zu Hause – R2: Integrierbarkeit mit vorhandenen Hochschulinformationssystemen – R3: hohe Sicherheit und Zuverlässigkeit – R3.1: Trennung Prüfungsdaten von Einschreibungs- u. Studentendaten – …


42

Abbildung 26 Basisanforderungen Abteilung Betriebliche Informationssysteme

Abbildung 27 Basisanforderungen Selbständige Abteilung für Allgemeinmedizin

Goals: – G1: effizientere Durchführung von Prüfungsklausuren durch Computerunterstützung – G2: Webpräsenz – …

Features: – F1: Prüfungsmodul:

• F1.1: Aufgabentypen: Multiple Choice • F1.2: Evaluation • …

– F2: Lehrveranstaltungen mit: • F2.2: Übungsklausur • F2.3: Forum


Requirements: – R1.1: Unterstützung des kompletten Prüfungsablaufs, Vermeidung von Medienbrüchen – R1.2: Sicherung der Prüfungsklausuren gegen Betrug, Täuschung und Manipulation – R1.3: Zugriff auf Prüfungsaufgaben nur unter klausurähnlichen kontrollierten Bedingungen – R1.4: sichere Identifikation der Teilnehmer – R1.5: editierbarer Fragenpool – …

Goals: – G1: Unterstützung des Übungsbetriebs – G2: Integrations-Plattform für verschiedene Belange in Lehre und Forschung – …

Features: – F1: Aufgabenmodul:

• F1.1: Aufgabentypen: Datei hochladen, Multiple Choice, Freitext, Remote (Anbindung an Korrektur-Server)

• … – F2: Allgemeine Veranstaltungen mit:

• F2.1: Einschreibungen • F2.2: Übungsaufgaben • F2.3: Wiki • F2.4: Download-Bereich


Requirements: – … – R4: Authentifizierung der Benutzer gegen eigene Datenbank, LDAP-Server oder Shibbo-

leth – R5: erweiterbarer Registrierungsprozess – R5.1: Prüfung von Vorbedingungen – R5.2: Ausführen von spezifischer Programmlogik nach der Registrierung


43

In den Abbildungen handelte es sich größtenteils um funktionale Anforderungen, die zu realisieren waren. Zu den nichtfunktionalen Anforderungen gehörten, neben der bereits genannten Sicherheit, insbesondere die Zuverlässigkeit beider Systeme, die Gewährleis-tung angemessener Antwortzeiten im Prüfungsbetrieb sowie eine umfassende Protokollie-rung. Dazu kamen weitere Anforderungen wie Erweiterbarkeit und Integrierbarkeit, die bereits zu Beginn genannt worden sind.

5.5 Commonality Analysis

Nachdem die grundlegenden Anforderungen des elatePortal-Projekts im vorhergehenden Kapitel auszugsweise dargestellt wurden, erfolgt die Identifizierung der Gemeinsamkeit der Produktlinie.

5.5.1 Methoden

Das SPL-Framework favorisiert drei Methoden zur Ermittlung gemeinsamer Anforderun-gen:

• Application Requirements-Matrix

• Priority-Based Analysis

• Checklist-Based Analysis

Die einfacheren Ansprüchen genügende und auch hier verwendete Methode ist die Application Requirements-Matrix. Die anderen beiden sind ausgefeiltere Vorgehenswei-sen, die an dieser Stelle nur kurz charakterisiert werden, da sie im Rahmen von Open-Source-Projekten nur bedingt einsetzbar sind.

Die Priority-Based Analysis lässt die Requirements-Prioritäten von den beteiligten Auftraggebern bzw. Stakeholdern anhand eines bestimmten Schemas bewerten. Häufig wird dabei eine Klassifizierung nach Kano [Ka96] verwendet. Basierend auf der Priorisierung erfolgt dann die Auswahl der gemeinsamen Requirements.

Checklist-Based Analysis stellt einen noch allgemeineren Ansatz zur Entscheidungsfindung dar, indem es potentielle gemeinsame Requirements zunächst in Kategorien einordnet. Das können z.B. Basisanforderungen, Anforderungen hoher Priorität, strategische oder gesetzlich vorgeschriebene Anforderungen sein. Insgesamt werden dabei mehr Aspekte als nur die Priorisierung von Requirements betrachtet.

5.5.2 Anwendung

In Tabelle 2 ist ein Auszug einer Application Requirements-Matrix für das elatePortal-Projekt dargestellt, anhand derer die gemeinsamen Requirements ermittelt werden können.

An dieser Stelle ist jedoch darauf hinzuweisen, dass ursprünglich im elatePortal-Projekt keine Commonality Analysis in der dargestellten Form stattgefunden hat, sondern die Gemeinsamkeit eher informal in einer agilen Weise, die sich an User Stories orientierte, bestimmt worden ist. Die folgenden Ausführungen dienen einer Charakterisierung der formalen Vorgehensweise des SPL-Frameworks.


44

Requirements Erziehungswiss. Fakultät

Betriebliche Informationssysteme

Selbst. Abt. für Allgemeinmedizin

Unterstützung eines vollständigen Prüfungsablaufs notwendig notwendig Vermeidung von Medienbrüchen notwendig notwendig Sicherung der Prüfungsklausuren gegen Betrug, Täuschung und Manipulation

notwendig notwendig

sichere Identifikation der Teilnehmer notwendig notwendig Aufgabentypen: Datei hochladen, Multiple Choice, Zuordnung, Lückentext, Freitext, Graphische Darstellung

notwendig

Aufgabentypen: Datei hochladen, Multiple Choice, Freitext, Remote

notwendig

Aufgabentypen: Multiple Choice notwendig Erweiterbarkeit mit versch. Aufgabentypen notwendig notwendig Trennung Prüfungsdaten von Einschreibungs- u. Studentendaten

……….. ……….. …………

Benutzerverwaltung notwendig notwendig notwendig Authentifizierung der Benutzer gegen eigene Datenbank

notwendig notwendig notwendig

Authentifizierung der Benutzer gegen LDAP-Server notwendig notwendig Authentifizierung der Benutzer gegen Shibboleth Eigenen Web-Content hinzufügen und verwalten (CMS)

notwendig notwendig

Erweiterbarkeit mit vorhandenen Webapplikationen notwendig notwendig notwendig

Tabelle 2 Application Requirements-Matrix

Die Identifizierung der gemeinsamen Requirements in der Application Requirements-Matrix erfolgt mit einem Top-Down-Ansatz von abstrakten zu detaillierten Anforderungen. In allen Applikationen benötigte Anforderungen bilden die Gemeinsamkeit der Produktli-nie (in Tabelle 2 grau markiert), die so umfangreich wie möglich ausfallen sollte. Das SPL-Framework empfiehlt darüber hinaus, in einem zweiten Schritt die Matrix auf weitere textuelle Charakteristika zu untersuchen (siehe [PBL05, Kapitel 10]).

5.6 Variability Analysis

Das Ziel der Variability Analysis ist die Identifizierung von Requirements, die nicht für alle späteren Applikationen gelten und somit Variabilität enthalten. Das stellt, wie bereits erwähnt, einen der Hauptunterschiede zur Entwicklung einzelner Systeme dar, in denen differierende Requirements entweder angepasst oder verworfen werden müssen. Stattdessen führt das SPL-Framework Variationspunkte ein, um verschiedene Varianten definieren zu können.

Auch die Variability Analysis wird hier nachträglich betrachtet. Für sie gelten die gleichen Anmerkungen wie zur Commonality Analysis.

5.6.1 Anwendung

Zur Identifizierung der Variabilität können die gleichen Methoden wie bei der Commonali-ty Analysis verwendet werden: Application Requirements-Matrix, Priority-Based oder Checklist-Based Analysis.

In der Fallstudie wurde wieder die Application Requirements-Matrix aus Tabelle 2 verwendet. Kandidaten für Requirements mit Variabilität sind Anforderungen, die nicht für alle Applikationen notwendig sind. In der Tabelle wurden sie gelb und blau hinterlegt.


45

Außerdem enthalten einige Requirements-Beschreibungen selbst verschiedene Charakteris-tika zur Identifizierung der Variabilität, wie bei den gelb markierten Anforderungen in der Matrix zu erkennen ist. Einen Sonderfall stellen hingegen die blau markierten Anforderun-gen dar: Sie enthalten die Authentifizierungs-Variante Shibboleth1, die für keine geplante Applikation notwendig war, aber in Zukunft von Relevanz sein könnte2.

5.6.2 Feedback

Von großer Bedeutung bei der Variability Analysis ist das Feedback des Design-Prozesses, da die Entscheidung für oder gegen die Einführung von Variationspunkten großen Einfluss auf die Architektur und damit auch auf den weiteren Verlauf der Entwicklung haben kann. Folgendes Beispiel verdeutlicht das.

Um die Teilnehmerverwaltung von Veranstaltungen so effizient wie möglich umzusetzen, wurden Veranstaltungen auf Gruppen in Jetspeed-2 gemappt, da über dessen API Benutzer neben Rollen auch in Gruppen eingetragen werden konnten, die wiederum für Autorisie-rungsentscheidungen benutzbar sind (vgl. Sicherheitsmodell von Jetspeed-2 [St05]). So konnten vorhandene Administrationstools verwendet und vom Portalserver bereitgestellte Sicherheitsmechanismen zur Zugriffssteuerung benutzt werden. Eine Alternative wäre die Speicherung der Teilnehmer in der elatePortal-eigenen Datenbank mit dem vermeintlich höheren Aufwand. Entsprechend ist kein Variationspunkt diesbezüglich eingeführt worden.

Leider stellte sich im späteren Betrieb die Jetspeed-API beim Auslesen von Gruppenteil-nehmern als sehr inperformant heraus, so dauerte der Aufbau einer Liste mit ca. 800 Teilnehmern annähernd zwei Minuten. Die Verwendung eines Object-Caches (JCS [Pe03]) brachte keine hinreichende Verbesserung. Darüber hinaus kam nachträglich noch folgende Anforderung hinzu: die Teilnehmer einer Veranstaltung sollten über eine Web-Service-Schnittstelle von anderen (Hochschul-) Informationssystemen ausgelesen werden können.

«interface»CourseManager CourseEnrollmentPortlet

WSCourseManagerImpl CourseManagerImpl

Participants by

VPVP

Course

Participants By

VelatePortal Database

V

Web Service Call

«realize» «realize»

«call»

Abbildung 28 Beispiel-Variationspunkt

Die Folge war die nachträgliche Einführung eines Variationspunktes Course Partici-pants By (siehe Abbildung 28) mit den Varianten elatePortal Database und Web Service Call (derzeit nicht implementiert), was Änderungen an der elatePortal-API und

1 eine Middleware des Internet2-Konsortiums zur verteilten Authentifizierung und Autorisation, http://shibboleth.internet2.edu 2 das Projekt SaxIS bietet für sächsische Hochschulen eine gemeinsame Autorisierungsschnittstelle mit Shibboleth, http://saxis.tu-freiberg.de


46

den Portlets, die diese aufrufen, nach sich zog. Außerdem musste ein neues Administrati-onsportlet entwickelt sowie Änderungen an bestimmten Sicherheitsmechanismen und Navigationsstrukturen vorgenommen werden.

5.7 Variability Modelling

Ausschlaggebend für die Anwendbarkeit des orthogonalen Variabilitätsmodells in der Praxis ist die Unterstützung durch adäquate Tools. Zu diesem Zweck existiert das VARMOD-Projekt1 der Abteilung Software Systems Engineering2 an der Universität Duisburg, die auch maßgeblich an der Entwicklung des orthogonalen Variabilitätsmodells sowie des SPL-Frameworks beteiligt war. Das Projekt bietet derzeit den VARMOD-Editor zur graphischen Erstellung von Diagrammen in der Notation des orthogonalen Variabili-tätsmodells mit Funktionen für darauf basierende Syntaxprüfungen. Darüber hinaus sind eine Erweiterung des VARMOD-Editors mit umfangreicheren Validierungsfunktionen sowie zwei weitere Tools geplant: der VARMOD-Modeller soll Traceability-Links ermöglichen und der VARMOD-Developer hat die Unterstützung des Application Requirements Engineering zum Ziel.

Leider befand sich der VARMOD-Editor noch in einem frühen Entwicklungsstadium und stellte sich in der Praxis als unzureichend heraus. Insbesondere fehlt für eine effiziente Anwendung der bereits angekündigte VARMOD-Modeller, um Traceability-Links zwischen unterschiedlichen Diagrammtypen erstellen zu können. Ferner entsprach die graphische Darstellung des orthogonalen Variabilitätsmodells im Editor nicht der in Kapitel 4.3 vorgestellten Notation.

5.7.1 Erste Iteration

Eine erste Verfeinerung der in Goal- und Feature-Listen definierten, grobgranularen Anforderungen umfasste die detailliertere Darstellung von Anwendungsfällen der zwei geplanten Systeme. Wie bereits erwähnt, führten insbesondere die Forderungen nach hoher Sicherheit und Zuverlässigkeit zur Aufteilung der Gesamtfunktionalität auf das elatePortal und den Prüfungsserver (examServer).

In Abbildung 29 ist ein Use-Case-Diagramm dargestellt, das die wichtigsten Anwendungs-fälle in Bezug auf beide Systeme skizziert. In jedem ist als UML-Subsystem das Aufgaben-Framework (TaskModel) enthalten. Außerdem ist im Diagramm der Aufgaben-Editor (ctEdit) abgebildet.

Das dazugehörige Variabilitätsmodell enthält eine Auswahl wichtiger Variationspunkte der Plattform. Einer der umfassendsten ist der durch Verwendung eines Portalservers mögliche Variationspunkt optional Portlet Applications, welcher die Erweiterbarkeit durch beliebige, JSR168-kompatible Anwendungen (vgl. Kapitel 2.3) gewährleistet. In der Abbildung sind Traceability-Links zwischen den Diagrammen weggelassen worden, da sonst die Darstellung zu unübersichtlich wäre.

1 http://www.sse.uni-due.de/wms/de/?go=56 2 http://www.sse.uni-due.de


47

„elatePortal“ Portal-Applikation

Student

Tutor

Dozent

Admin

„examServer“ Web-Applikation

„ctEdit“ Aufgaben-Editor

Portalbenutzerverwalten

Aufgabenpoolsverwalten und bearbeiten

Aufgaben-Vorschau

Veranstaltungenverwalten

Veranstaltungkonfigurieren

Einschreibungenverwalten

«include»

Forumadministrieren

JForumadministrieren

MiniForumadministrieren

«include»Aufgaben

administrieren

«include»

FileAreaadministrieren

«include»

Registrierungkonfigurieren

Mail-Templatesverwalten

Portletsverwalten

CMSadministrieren

Veranstaltungnutzen

Einschreibungennutzen FileArea nutzen

Forum nutzen

JForum nutzenMiniForum nutzen

«subsystem»Administration

«include» «include»

«include»

«subsystem»TaskModel

Aufgabenbearbeiten

«include»

Portal-Benutzer

"Upload"-Aufgabe

"Remote"-Aufgabe

Korrektur

«include»

Beinhaltet gesamtenAufgaben-Lebenszyklus

"Complex"-Aufgabe

Administration

«include»«include»

«include»

«include»

«include» «include»

Customization:Oberfläche anpassen

Aufgabenadministrieren

«subsystem»TaskModel

Aufgabenbearbeiten

Korrektur

«include»

"Upload"-Aufgabe

"Remote"-Aufgabe

"Complex"-Aufgabe

Variabilitätsmodell

VP

optionalPortlet

Applications

VP

UserAttributes

requires_v_vp

Authentifikation

VP

ComplexSubTask Types

Multiple ChoiceV

MappingV

ClozeV

TextV

Paint/DrawV

VP

TaskTypes

ComplexV

UploadV

RemoteV

VP

Forum

JForumV

MiniForumV

VP

Authentifikation

DatabaseV

LDAPV

ShibbolethV

Beinhaltet gesamtenAufgaben-Lebenszyklus

Abbildung 29 Use-Case-Diagramm und Variabilitätsmodell

5.7.2 Zweite Iteration

Zur genaueren Beschreibung bestimmter Abläufe ist eine weitere Verfeinerung der Requirements-Artefakte notwendig. An dieser Stelle wird ein Variationspunkt erläutert, der eine flexible Benutzer-Registrierung am Portal ermöglicht.


48

Initiiert ein neuer Benutzer die Registrierung am Portal, wird eine Kette von sog. Handlern durchlaufen, die einerseits bestimmte Aktionen vor und nach der Aktivierung des Accounts ausführen, aber andererseits auch den Vorgang abbrechen können. Die erste Variante (Course) des Variationspunktes Registration Handler verknüpft die Registrierung mit der Einschreibung in eine Veranstaltung. Je nach Konfiguration muss der Benutzer eine gültige Kennung oder Transaktionsnummer (TAN) einer Veranstaltung eingeben, um sich registrieren zu können. Nach der Mail-Aktivierung wird er automatisch in die entsprechende Veranstaltung eingeschrieben. Weitere Varianten ermöglichen die Verwendung von Erlaubnislisten und manuellen Administrator-Bestätigungen (derzeit nicht implementiert).

UserRegistrationManager

UserRegistration-Portlet

Mail-Aktivierung

VP

RegistrationHandler

Course(Key / TAN)

V

White List

V

Admin Approval

V

Abbildung 30 Variabilität in der Benutzer-Registrierung

Abbildung 30 skizziert den erläuterten Variationspunkt in einer informellen Darstellung (als Alternative zum in der Regel verwendeten Sequenz-Diagramm) sowie die Traceabili-ty-Links zum orthogonalen Variabilitätsmodell.

5.8 Auswertung

In diesem Kapitel wurde das Domain RE am Beispiel des elatePortals beschrieben und Requirements-Artefakte dargestellt, die zur Erläuterung des Variabilitätskonzepts relevant sind. RE stellt nach wie vor den Prozess im Software Engineering dar, der am wenigsten automatisiert werden kann und mit einer relativ informalen Vorgehensweise verknüpft ist, die viel Erfahrung des Anforderungs-Analytikers erfordert. Dass falsche Entscheidungen im RE einen hohen Änderungsaufwand nach sich ziehen können, zeigte das in Kapitel 5.6.2 erläuterte Beispiel.

Im Vergleich zur Einzelsystementwicklung sind die Aktivitäten im RE durch die Einführung von Variabilität komplexer. Insbesondere kann an dieser Stelle das Prinzip der meisten agilen Methodiken, Dokumentationen auf das Nötigste zu begrenzen (vgl. Kapitel 4.4.2), nur mit Einschränkungen angewendet werden, da bei Produktlinien die Dokumenta-tion einen sehr wichtigen Aspekt für das Application Engineering darstellt. Sinnvoll war jedoch die Verwendung von Story Cards und Szenarien zur Beschreibung von Interaktio-nen mit dem System.

5.8.1 Variabilität

Die Ermittlung von gemeinsamen und variablen Requirements an die Produktlinie stellte mit Hilfe der Application Requirements-Matrix eine zielgerichtete Aufgabe dar. Es besteht


49

jedoch die Gefahr, schnell an deren Grenzen zu stoßen. Zum einen ist sie nur begrenzt skalierbar und zum anderen erfordert das Erkennen gemeinsamer und variabler Anforde-rungen ein „gutes Auge“ sowie angemessene Erfahrung mangels weitergehender Strukturierung. Für komplexere Anforderungen sind die umfassenderen Vorgehensweisen Priority-Based bzw. Checklist-Based Analysis zu empfehlen.

Ein Hauptproblem für das Requirements Engineering im Produktlinienkontext ist die mangelnde Tool-Unterstützung. Einen Anfang stellt das in Kapitel 5.7 erwähnte VARMOD-Projekt dar, das einen Editor (in einer frühen Version) für das orthogonale Variabilitätsmodell bereitstellt. Dabei ist die Verfügbarkeit der weiteren geplanten Werkzeuge ebenso essentiell für die praktische Anwendbarkeit des Variabilitätsmodells. Jedoch ist abzusehen, dass die Unterstützung für Traceability-Links weitaus schwieriger zu realisieren sein wird. Probleme können insbesondere bei der konsistenten Adressierung von fremden Diagrammelementen (die aus unterschiedlichen Diagrammen stammen) und bei der Entwicklung einer adäquaten Benutzeroberfläche entstehen. Eine Lösungsmöglich-keit für zumindest das erste Problem stellt z.B. die Verwendung von UML-Diagrammen im standardisierten XMI-Format [OMG05] dar, dessen (XML-)Elemente adressiert werden können.

5.8.2 Modellbasierte Ansätze

Schließlich sei an dieser Stelle noch auf zwei weitergehende Ansätze für das Domain RE verwiesen. So entwickelten Czarnecki und Eisenecker [CE00] (vgl. GSE in Kapitel 2.3) einen auf Feature-Modelle ausgelegten generativen Ansatz. Darauf aufbauend kombinieren z.B. García et al. [Ga06] die Verwendung von Feature- und Goal-Modellen mit der Model Driven Architecture1 (MDA [OMG01]). Sie geben Graph-Transformationen in UML-Diagramme an, d.h. sie überführen Instanzen von Feature-/Goal-Modellen in Instanzen von UML-Klassendiagrammen.

Aus fachlicher Sicht existieren keine Argumente gegen die Verwendung der beschriebenen generativen Techniken in Verbindung mit dem SPL-Framework. Dazu ist die Erstellung von Transformationen geeigneter Requirements-Artefakte in (UML-)Architekturmodelle notwendig, welche jedoch durch die Entkopplung von Variabilität (mit dem orthogonalen Variabilitätsmodell) und den eigentlichen Anforderungen möglicherweise komplexer ausfallen würden.

1 MDA ist ein OMG-Standard (http://www.omg.org) und stellt einen Spezialfall von MDE dar

Domain Design

50

6 Domain Design

Das Domain Design nutzt die im vorhergehenden Domain RE erarbeiteten Requirements-Artefakte zur Entwicklung der Referenzarchitektur für die Produktlinie, indem Anforde-rungen mit technischen Lösungen verknüpft werden. Da die Referenzarchitektur die Umsetzbarkeit aller späteren Applikationen aus der Produktlinie bestimmt, sind die an sie gestellten Anforderungen hoch. Der Begriff Referenzarchitektur ist im SPL-Framework folgendermaßen definiert:

„The reference architecture is a core architecture that captures the high-level design for the applications of the software product line.“ [PBL05, Kapitel 6]

Im Domain Design spielt auch Variabilität wieder eine zentrale Rolle, welche die Architektur berücksichtigen muss. Außerdem führen viele technische Lösungen zur Einführung zusätzlicher interner Variabilität (vgl. orthogonales Variabilitätsmodell in Kapitel 4.3).

In diesem Kapitel werden die Haupteinflussfaktoren auf die Referenzarchitektur dargestellt sowie Praxislösungen und die Umsetzung im elatePortal-Projekt betrachtet.

6.1 Kontext

In Abbildung 31 sind die direkt an das Domain Design angrenzenden Prozesse dargestellt.

DomainDesign


DomainRealisation

ApplicationDesign

Abbildung 31 Kontext Domain Design

Eingabe für das Domain Design sind Requirements-Artefakte aus dem Domain RE und die Ausgabe stellen Design-Artefakte für das Domain Realisation dar. Daneben existieren wieder Feedback-Schleifen, die folgendermaßen charakterisiert sind:

• Feedback aus dem Domain Design zurück zum Domain RE mit dem Ziel, die Requirements zu verfeinern (vgl. Twin Peaks Model, Kapitel 5.3.2)

• Feedback aus dem Domain Realisation an das Domain Design zur Anpassung der Referenzarchitektur. Zum Beispiel führten im Projekt oft Besonderheiten des ver-wendeten Portal-Servers oder bestimmter Bibliotheken zur Anpassung der Archi-tektur.

• Feedback aus dem Application Design an das Domain Design in Form von Anfra-gen nach zusätzlichen oder geänderten Design-Artefakten. Zum Beispiel können Teile der Architektur nicht für eine bestimmte Applikation geeignet sein und zu Änderungen in der Referenzarchitektur führen. Dabei ist immer zu beachten, dass die Qualität der Architektur nicht beeinträchtigt wird.

Domain Design

51

Der letztgenannte Punkt beinhaltet insbesondere auch die nachträgliche Übernahme applikationsspezifischer Artefakte in die Plattform und erfordert eine sorgfältige Vorgehensweise. In einer kommerziellen Produktlinie muss dafür der Product Manage-ment-Teilprozess herangezogen werden (vgl. Kapitel 3.5.2 und 4.2).

6.2 Artefakte

Die im Domain-Design zu erstellenden Artefakte spezifizieren die Architektur der Plattform und spiegeln die getroffenen Designentscheidungen wider. Dabei enthalten Design-Artefakte in der Produktlinienentwicklung typischerweise gemeinsame und variable Aspekte, die wiederum auf unterschiedlichen Abstraktionsstufen modelliert werden.

Im SPL-Framework lassen sich Design-Artefakte in Anlehnung an Jazayeri et al. [JRL00] auf vier grundlegende Belange zurückführen, von denen die ersten beiden die Verbindung zum Domain RE herstellen:

• Architekturbeeinflussende Anforderungen (Architectural significant Requirements) bezeichnen Anforderungen, die einen besonderen Einfluss auf die Architektur ha-ben. Im elatePortal waren das insbesondere die mit elektronischen Klausuren und mit der Organisation von Lehrveranstaltungen zusammenhängenden Anforderun-gen (vgl. Basisanforderungen in Kapitel 5.4).

• Konzepte (Concepts) beschreiben die Architektur auf eine fachspezifische, konzep-tionelle Weise ohne Betrachtung technischer Lösungen. In der Fallstudie be-schränkte sich das auf informelle Graphiken (vgl. z.B. Kapitel 2.2, Abbildung 2), die in Besprechungen diskutiert worden sind. Eine Übersicht zu konzeptioneller Modellierung ist in [CE00, Anhang A] zu finden.

• Struktur (Structure) beschreibt die Aufteilung des Systems in einzelne Bestandteile und ihre Beziehungen zueinander: „The architectural structure is the decompositi-on of a software system into parts and relationships.“ [PBL05, Kapitel 6]

• Textur (Texture) ist ein von [JRL00] eingeführter Begriff, der eine Menge von Regeln bezeichnet, mit denen die Realisierung der Plattform erfolgt. Das umfasst beispielsweise Implementierungs-Richtlinien, Design-Patterns [Ga95] oder auch Styles. Letztere beschreiben topologische und semantische Randbedingungen für Architekturen [SG96]. Zusammengefasst spezifizieren damit Textur-Artefakte die Anwendung der Architektur und bieten Hilfestellung für deren Implementierung: „The architectural texture ist the collection of common development rules for reali-sing the system.“ [PBL05, Kapitel 6]

Die letzten beiden Belange bilden die Hauptpfeiler der Architektur und sind Betrachtungs-gegenstand der Fallstudie in diesem Kapitel. Im Folgenden werden zunächst verschiedene Modellierungsmethoden für die Referenzarchitektur charakterisiert.

6.2.1 Architektur-Sichten

Um eine hohe Beschreibungsfähigkeit zu erreichen, werden in der Regel verschiedene Sichten eingeführt, die bestimmte Aspekte des Systems exakt beschreiben. Sie bilden in ihrer Gesamtheit die Struktur der Architektur, können sich dabei auch überlappen und

Domain Design

52

müssen nicht unbedingt miteinander in Beziehung stehen. In Tabelle 3 sind Architektur-Sichten nach [Kr95] mit verschiedenen Diagrammtypen in UML 2.0 dargestellt.

Architektur-Sicht Charakteristik Modellierungsmethoden Logische Sicht (Logical view)

beinhaltet funktionale Anforderungen der Plattform

siehe Kapitel 5.2

Prozess-Sicht (Process view)

beschreibt Verhalten bzw. Abläufe im System zur Laufzeit (Prozesse, Threads und ihre Interaktionen)

Interaktionsübersichtsdiagramm Kommunikationsdiagramm Aktivitätsdiagramm Sequenzdiagramm Timing-Diagramm Zustandsdiagramm

Entwicklungs-Sicht (Development view)

beschreibt Architektur als Komposition von Schichten, Subsystemen, Komponenten, Klassen und Schnittstellen

Paketdiagramm Komponentendiagramm Kompositions-Strukturdiagramm Klassendiagramm Objektdiagramm

Physische Sicht (Physical view)

beschreibt die physische Verteilung von in den vorherigen Sichten identifizierten Elementen auf Dateien, Verzeichnisse und Ausführungseinheiten (Knoten, Betriebssysteme)

Verteilungsdiagramm

Tabelle 3 Architektur-Sichten (Sichten nach [Kr95], Diagramme nach [PBL05])

6.2.2 Formale Architekturbeschreibung

Neben UML gibt es auch stärker formalisierte Architekturbeschreibungssprachen (Architecture Description Language, ADL), die aber aufgrund ihrer geringeren Bedeutung im Domain Design nicht in der Tabelle aufgeführt sind. Das ist nach [PBL05, Kapitel 2] hauptsächlich auf die mangelnde Skalierbarkeit für große Systeme und die zusätzliche Komplexität im Produktlinienkontext zurückzuführen. Außerdem verlangt die hohe Formalität der Ansätze ein besonders ausgeprägtes Fachwissen.

Nennenswert sind an dieser Stelle jedoch die Architektur-Beschreibungssprachen Koala1 und Mae [Ho01], die Mechanismen zur Einführung von Variationspunkten besitzen. Beide unterstützen insbesondere auch die Evolution der Produktlinien-Architektur durch eine Versionierung der Komponenten. Auch mit xADL 2.0 [DH01], das einen auf XML basierten und stark erweiterbaren Ansatz darstellt, können Produktlinien-Architekturen beschrieben werden. Außerdem existiert ein Mapping von Koala und Mae auf xADL 2.0 [DH01]. Ein Problem von xADL ist jedoch, dass es keine ausreichende Trennung der strukturellen und dynamischen Aspekte von Produktlinien ermöglicht [Ba04].

Speziell für die Prozess-Sicht existieren darüber hinaus weitere formale Modellierungsme-thoden, die trotz ihrer geringen Bedeutung im Design für das spätere Domain Realisation relevant sein können. Nach [PBL05, Kapitel 6] haben beispielsweise COLD [FJM94] und SDL [BH93] ihre Eignung für Produktlinien im Embedded-Systems-Bereich bewiesen. Letztere kann darüber hinaus auch mit UML kombiniert werden.

1 http://www.extra.research.philips.com/SAE/koala

Domain Design

53


Das Vorgehen beim Design für Produktlinien unterscheidet sich neben der Modellierung von Variabilität insbesondere durch gesteigerte Qualitätsanforderungen von der Einzelsystementwicklung.

Zu den traditionellen Aktivitäten im Design gehören [PBL05, Kapitel 11]:

• Abstraktion, welche die Komplexität der Architektur reduziert, indem bestimmte Aspekte des Systems gruppiert und abstrahiert werden.

• Modellierung, welche Abstraktionen zueinander in Relation setzt, um Entschei-dungsfindungen bzgl. der Architekturentwicklung zu unterstützen.

• Simulation, welche verschiedene Aspekte von Modellen durch virtuelle Probeläufe misst.

• Prototyping, welches zukünftige Eckdaten der Software bestimmt, indem frühe Probeläufe von Prototypen, die initiale System-Versionen darstellen, durchgeführt werden. Häufig ist auch von throwaway prototyping die Rede [So06, Kapitel 17] wenn Prototypen keinen weitergehenden Nutzen haben.

• Validierung, welches die spätere Implementierung gegen das Architekturmodell prüft und so sicherstellen soll, dass die getätigten Designentscheidungen korrekt umgesetzt worden sind.

Das SPL-Framework fokussiert die ersten beiden Aktivitäten, die auch in diesem Kapitel bzgl. der Fallstudie durchgeführt werden. Simulation als formaler Prüfansatz von Architekturen ist kein Betrachtungsgegenstand des SPL-Frameworks, wohingegen Prototyping einen Bestandteil des Domain Testing-Teilprozesses darstellt. Bzgl. der Validierung werden im Domain Testing lediglich grundlegende Gesichtspunkte erläutert, die bei einem Walkthrough [SL03, Kapitel 4] zu beachten sind.

6.3.1 Einfluss nichtfunktionaler Anforderungen

Nichtfunktionale Anforderungen spezifizieren allgemeine Qualitäts- und Verhaltensaspek-te der Referenzarchitektur. Dazu gehören z.B. Ausführungsgeschwindigkeit, Antwortzeiten und Sicherheitsanforderungen, aber auch die Möglichkeit zu früher Integration und Test der Software (vgl. Rapid Prototyping bei inkrementeller Entwicklung [So06, Kapitel 17]). Die höchste Priorität im Produktlinienkontext haben neben Variabilität die nichtfunktiona-len Anforderungen Flexibilität, Entwicklungsfähigkeit und Wartbarkeit.

Flexibilität

Flexibilität bezeichnet die Fähigkeit, aus der Plattform auch neue Applikationen zu entwickeln, die erst in Zukunft relevant sein können und Anforderungen mit sich bringen, die nicht vorhersehbar waren. Die Plattform muss darauf ausgerichtet sein, mit solchen Änderungen umgehen zu können und dabei gleichzeitig eine hohe Qualität aufweisen, um auch weiterhin für viele Produktlinien-Applikationen einsetzbar zu bleiben.

Domain Design

54

Entwicklungsfähigkeit

Entwicklungsfähigkeit charakterisiert die Fähigkeit, die Referenzarchitektur anpassen zu können wenn sich Anforderungen ändern oder neue Technologien zur Verfügung stehen. Sie geht damit über Flexibilität hinaus, die nur Unterstützung für unvorhergesehene Applikationen fordert. Da auch existierende Applikationen weiterhin zur Plattform kompatibel sein müssen, ist eine Hauptaufgabe der Entwicklungsfähigkeit abzusichern, dass die Architektur später nicht zu stark geändert werden muss. Nichtsdestotrotz ist es aber kaum möglich, die Entwicklungsfähigkeit von Architekturen direkt zu messen, da ihr Grad maßgeblich von den erst in Zukunft notwendigen Änderungen abhängt.

Wartbarkeit

Wartbarkeit befasst sich mit Änderungen, die während des Lebenszyklus von Applikatio-nen durchgeführt werden müssen. Das betrifft insbesondere die Entdeckung und Behebung von Fehlern (z.B. durch Debugging und Auswertung von Logfiles), Verbesserungen des Laufzeitverhaltens (Profiling, Kapitel 8.6), aber auch kleinere Änderungen an Komponen-ten des Systems. Unterstützt wird Wartbarkeit durch die Verwendung von Techniken für spätes/dynamisches Binden, die das Entfernen und Hinzufügen von Teilen der Applikation ermöglichen (vgl. Bindungsmechanismen, Kapitel 7.8).

Wie die drei genannten Qualitätsanforderungen in der Architektur erreicht werden konnten und welche Frameworks/Technologien wesentlich dazu beigetragen haben, ist ein wichtiger Bestandteil der weiteren Ausführungen.

6.3.2 Separation of Concerns

Zentral für das Erreichen von Flexibilität und Entwicklungsfähigkeit in der Referenz-Architektur ist das Design-Prinzip Separation of Concerns. Es ist auch bekannt als Trennung der Zuständigkeiten und wurde zum ersten Mal von David Parnas in [Pa72] beschrieben. Die Bezeichnung als solche geht auf Edsger Dijkstra [Di76] zurück.

Das Prinzip fordert die Entwicklung von verschiedenen Lösungen für unterschiedliche Bereiche eines Systems. Ziel ist, es so in einzelne Teile zu zerlegen, dass innerhalb dieser eine hohe Kohäsion erreicht wird, um sie anschließend so lose wie möglich miteinander zu koppeln. Das begrenzt die Auswirkungen von späteren Änderungen maßgeblich. Insbesondere ermöglicht ein angemessen umgesetztes Separation of Concerns die Trennung von Lösungen für stabile Requirements von denen für instabile, was die iterative Verfeinerung von Design und Requirements erleichtert (vgl. Nebenläufige Entwicklung, Kapitel 4.4.1 und Twin Peaks Model, Kapitel 5.3.2).

Reine objektorientierte Programmierung (OOP) und objektorientiertes Design (OOD) ermöglichen die Zerlegung eines Systems nur aufgrund der Kernfunktionalität in sog. Hauptbelange1 (die sog. „dominante Dekomposition“ [Ta00]). Da aber häufig auch eine Zerlegung anhand anderer Gesichtspunkte sinnvoll ist, die sich teilweise mit den Hauptbelangen überschneiden, existieren verschiedene Ansätze, die eine Lösung dieses Problems ermöglichen. Im Folgenden werden der Hyperspace-Ansatz sowie aspektorien-

1 auch: core concerns

Domain Design

55

tierte Programmierung (AOP) charakterisiert. Beide werden in der Regel auch den generativen Ansätzen zugeordnet.

Hyperspace-Ansatz

Eine abstrakte und umfassende Lösung für Separation of Concerns ist mit dem Hyperspa-ce-Ansatz [OT00] möglich. Hyperspace löst das erwähnte Überschneidungsproblem, indem es ein Modell für die symmetrische Zerlegung des Systems in unterschiedlichen Dimensionen bereitstellt, das dementsprechend auch Multidimensional Separation of Concerns (MDSOC) genannt wird.

Der Ansatz unterscheidet im Gegensatz zu AOP nicht nur zwischen Haupt- und Querschnittsbelangen, sondern behandelt ausdrücklich alle Belange gleich. Der Ansatz ist sehr abstrakt und nicht an Modellierungs- bzw. Implementierungstechnologien gebunden. Mit Hyper/J1 steht eine Abbildung von Hyperspace auf Java zur Verfügung, die relativ feingranular ist: Abgebildete Java-Elemente sind Pakete, Klassen, Interfaces, Methoden, Konstruktoren und Felder. Darüber hinaus existiert eine Abbildung auf UML 1.4: Hyper/UML [PRB03]. Das heißt, dass mit Hyper/J die Generierung von Java-Code und mit Hyper/UML die von UML-Diagrammen möglich ist.

Hyperspace basiert wiederum auf früheren Ansätzen zur Umsetzung von Separation of Concerns, die an dieser Stelle nur erwähnt werden. Dazu zählen Adaptive Programming [Li95], Subject Oriented Programming [Os94] und Composition Filters [ABV92].

Aspektorientierte Programmierung

Zu den bekanntesten Lösungsansätzen für Separation of Concerns gehört die Aspektorien-tierte Programmierung. Wie bereits erwähnt unterscheidet sie zwischen Haupt- und Querschnittsbelangen2 in Systemen.

AOP erweitert damit OOD/OOP um die Fähigkeit der Modellierung und Ausführung von Querschnittsbelangen. Diese werden in Querschnittscode separat implementiert und mit einem sog. Weaving-Prozess in den normalen Code „eingewebt“. Für eine umfassende Einführung in aspektorientierte Programmierung sei an dieser Stelle auf [Wu05] verwiesen.

In der Praxis spielt AOP gegenüber Hyperspace eine größere Rolle, wodurch für die meisten Umgebungen und Programmiersprachen AOP-Frameworks zur Verfügung stehen. Zu den bekanntesten im Java-Umfeld gehört AspectJ3, das wie Hyper/J von IBM entwickelt worden ist.

6.4 Komponenten-Framework

Das elatePortal, der Prüfungsserver sowie das Aufgaben-Framework verwenden als Komponenten-Technologie das Spring-Framework4 [JH04, Wo05]. Es stellt einen

1 http://www.alphaworks.ibm.com/tech/hyperj 2 auch: cross-cutting concerns 3 http://www.eclipse.org/aspectj 4 http://www.springframework.com

Domain Design

56

alternativen Architekturansatz zum J2EE-Standard Enterprise Java Beans (EJB) in der Version 2.0 [Su03b] dar, indem es mit dem Konzept eines leichtgewichtigen Containers die Verwendung von Plain Old Java Objects (POJOs) als Komponenten ermöglicht.

POJOs stellen normale Java-Objekte bzw. -Klassen dar, die nicht durch externe Interfaces an eine bestimmte Laufzeitumgebung gebunden sind. Genau das ist bei der EJB-Spezifikation bis vor Version 3.0 der Fall: Enterprise Java Beans müssen verschiedene Interfaces implementieren und benötigen zur Laufzeit einen schwergewichtigen EJB-Container, der meist in einen Application Server eingebettet ist.

Spring-Komponenten besitzen hingegen keine Interfaces, die sie an das Framework binden. Ihre Komposition erfolgt zur Laufzeit durch einen Container, der in verschiedenen Ausprägungen für normale J2SE-Umgebungen zur Verfügung steht. Eines der wichtigsten Konzepte dabei stellt Inversion of Control (IoC)1 dar: Komponenten sind nicht selbst für ihre Konfiguration verantwortlich, sondern sie wird von außen durch den Container „injiziert“.

Spring core

AOP(declarative transaction,

object pooling,interceptors)

IoC (DI)Container

(dependency management, object

lifecycle management)

Component/-Service

abstraction

Spring DAO(transaction, jdbc

support, dao support)

Spring ORM(Hibernate, JDO, TopLink, iBatis)

Spring WEB(WebApplicationContext,

Web utilities)

Spring WEB MVC(Web MVC Framework, Web

Views JSP/Velocity/PDF/Excel/JasperReport)

Web remoting

(Web Services, RMI, Hession

Burlap)

EJB/JMS/JMX Mail Scheduling 1. Ehcache support

2. MockTesting3. Rich Client

Additional capabilities

Abbildung 32 Übersicht Spring-Framework [Al05]

Weiterhin stellt Spring über seine Kernfunktionalität hinaus eine Vielzahl von Lösungen und Frameworks bereit, die in Abbildung 32 dargestellt sind. Für das elatePortal-Projekt waren insbesondere die folgenden von Relevanz:

• Mit Spring AOP kann deklarativ in Komponenten Querschnittscode eingewebt werden. Das wurde im elatePortal dazu genutzt, Datenbankzugriffe transaktionssi-cher zu gestalten. In Zukunft ist auch die Realisierung von Sicherheits-Funktionen (Absicherung der elatePortal-API bzgl. der Authorisierung des Aufrufenden) durch AOP geplant.

• Persistence-Templates ermöglichen einen vereinfachten Zugriff auf APIs von Persistenz-Frameworks sowie ein einheitliches Exception-Konzept. Im elatePortal wurden entsprechend die bereitgestellten OJB-Templates verwendet.

1 auch: Dependency Injection

Domain Design

57

• Das Sicherheits-Framework „Acegi Security“1 kam im Prüfungsserver zur Anwen-dung und stellt Authentifizierung sowie Authorisierung sicher.

6.5 Referenzarchitektur

Nach den Vorbetrachtungen zu Aspekten der Architekturentwicklung im Produktlinien-kontext wird im Folgenden das Design des elatePortal-Projektes im Hinblick auf die erläuterten Qualitätsanforderungen dargestellt.

6.5.1 Übersicht

Zur Verdeutlichung der groben Architektur der Systeme ist in Abbildung 33 eine physische Sicht in Form eines UML-Verteilungs-Diagramms dargestellt. Zu erkennen sind zwei Serversysteme, die jeweils den J2EE Servlet Container Apache Tomcat2 enthalten.

«device»Prüfungsserver

«execution environment»Tomcat Servlet Container

«device»Portal-Server

«execution environment»Tomcat Servlet Container

«execution environment»Jetspeed Portal

«artifact»

examServer.war

«artifact»

taskmodel-api.jar

«artifact»

taskmodel-core-view.war

«artifact»

taskmodel-api.jar

«artifact»


«artifact»

elatePortal-api.jar

«artifact»

elatePA.war

«database»

jetspeed DB

«database»

elatePortal DB

«JDBC»

«Web Service»

«JDBC»

Orthogonales Variabilitätsmodel (Ausschnitt)

VP

AuthorizationProvider

Web Service Call

V

elatePortal

Vlocal User-Database

V

VP

WebServiceEndpoint

...

V

requires_v_vp

MySQL

V

VP

Database

Derby

V

Abbildung 33 Verteilungs-Diagramm

1 http://www.acegisecurity.org 2 http://tomcat.apache.org

Domain Design

58

Interessant ist, dass der Jetspeed2-Portalserver keinen vollständigen Application Server benötigt, was insbesondere an der Verwendung des leichtgewichtigen Komponenten-Frameworks Spring statt Enterprise Java Beans liegt.

In den folgenden Erläuterungen werden verschiedene Begriffe aus der Servlet- [Pe01] und der Portlet-Spezifikation verwendet [AH03].

6.5.2 Deployment

In Abbildung 33 ist die Verteilung der wichtigsten Artefakte des elatePortal-Projekts in Form von JAR- und WAR-Archiven auf die beiden Servlet Container dargestellt. Zu den WAR-Archiven gehören der Jetspeed2-Portalserver, die elatePortal-Portletapplikation (elatePA.war), der Prüfungsserver (examServer.war) und die Präsentations-Webapplikation des Aufgaben-Frameworks (taskmodel-core-view.war). Zu den JAR-Archiven zählen die API des elatePortals (elatePortal-api.jar) sowie des Aufgaben-Frameworks (taskmodel-api.jar). Nicht abgebildet sind weitere Portletapplikationen, externe Bibliotheken und die API von Jetspeed-2.

6.5.3 Kontextübergreifende Kommunikation

Ein wichtiger Aspekt, der durch die Verteilung des gesamten elatePortal-Projekts über verschiedene Artefakte entsteht, ist die Ermöglichung der Kommunikation zwischen den Artefakten innerhalb des Servlet Containers.

In Abbildung 34 sind die drei genannten APIs sowie die WAR-Artefakte skizziert, welche auf die Funktionalität andererer Kontexte zugreifen müssen. Die APIs kapseln jeweils die Funktionalität der mit ihnen durch gestrichelte Linien verbundenen Kontexte.

In der Abbildung ist zu erkennen, dass die elatePortal-API von anderen Portletapplikatio-nen wie bspw. dem JForum (siehe Use-Case-Diagramm in Kapitel 5.7.1) und außerdem durch Jetspeed selbst verwendet wird. Letzteres ist darauf zurückzuführen, dass in Jetspeed bestimmte Komponenten durch eigene Implementierungen ausgetauscht werden mussten, welche Zugriff auf die elatePortal-API benötigen.

«artifact»

examServer.war

«artifact»


«artifact»

jforum.war

TaskModel API

Jetspeed API«artifact»

elatePA.war

«artifact»

jetspeed.warelatePortal API

sd Jetspeed-Portalserver sd elatePortal sd examServer

Abbildung 34 Kontextübergreifende Kommunikation

In der Servlet-Spezifikation erzeugt das Deployment jedes WAR-Archives in den Container einen sog. Servlet-Kontext. Zu deren Ausführung verwendet der Tomcat gemäß

Domain Design

59

der Servlet-Spezifikation ein hierarchisches System von Classloadern, an dessen untersten Enden sich die sog. Kontext-Classloader befinden. Dadurch sind einzelne Kontexte strikt voneinander getrennt. Damit trotzdem eine kontext-übergreifende Kommunikation möglich ist, müssen die API-Archive von einem den Kontexten übergeordneten Classloader verwaltet werden, auf die jede Webapplikation zugreifen kann.

In einigen Fällen bereitete die auf diese Weise realisierte kontextübergreifende Kommuni-kation leider auch sehr komplexe Probleme. Sie resultierten meist daraus, dass Klassen und Bibliotheken von falschen Classloadern geladen wurden. In einigen Fällen führten auch Fehler in Fremdbibliotheken oder im Tomcat zu Schwierigkeiten.

Eine Alternative dazu stellt nur die Verwendung von socketbasierter Kommunikation über RMI1 (Remote Method Invocation) oder Web-Services2 dar, die aber auch wesentlich aufwendiger zu realisieren gewesen wäre.

6.5.4 Variabilität

Das unter dem Verteilungsdiagramm in Abbildung 33 dargestellte orthogonale Variabili-tätsmodell zeigt drei Variationspunkte. Damit der Prüfungsserver auch flexibel mit einer anderen Organisationsplattform verwendet werden kann, benötigt er eine Schnittstelle, über die Authorisierungsanfragen vor dem Start von Prüfungen durchführbar sind und die über Informationen aus der eigenen Benutzerdatenbank hinausgehen (Variationspunkt Authorization Provider).

Diese Schnittstelle wurde in Form eines Web-Service realisiert, mit dem die Server auch physikalisch voneinander getrennt werden können. Der Endpunkt auf Seiten des elatePortals ist auch für andere Systeme implementierbar (Variationspunkt Web Service Endpoint).

Der dritte Variationspunkt Database ermöglicht den Austausch der Datenbank, was aus der Verwendung eines objektrelationalen Mappers (Apache OJB3) und der Erstellung von datenbankunabhängigen Datenschemen resultiert (vgl. Kapitel 6.7 bzgl. einer kritischen Betrachtung dieses Variationspunktes).

6.6 Aufgaben-Framework

Das Aufgaben-Framework stellt eines der zentralen Artefakte im elatePortal-Projekt dar, das zur Umsetzung der Funktionalität für elektronische Klausuren entwickelt worden ist.

1 http://java.sun.com/products/jdk/rmi 2 http://www.w3.org/2002/ws 3 http://db.apache.org/ojb

Domain Design

60

Das Framework selbst ist wiederum durch verschiedene Variationspunkte erweiterbar und besteht aus folgenden drei Teilen:

• einer API, welche die Struktur des Frameworks beschreibt und den Zugriff auf die Implementierung kapselt,

• einer Referenzimplementierung (RI), die alle Interfaces implementiert und, je nach Anwendung, die benötigten Aufgabentypen unterstützt, sowie

• einer Webapplikation als Präsentationsschicht, welche die Interaktion mit den Nutzern durchführt.

Im Wesentlichen stellt das Aufgabenframework eine Container-Lösung dar, in welcher ein Container den Lifecycle von sog. Tasklets steuert, die in Ausführung befindliche Aufgaben bezeichnen. Jedes Tasklet referenziert wiederum eine sog. TaskDef, die seine Aufgabendefinition enthält.

initialized

in_progress

processed

correcting corrected

annotated annotation_acknowledged Abbildung 35 Aufgaben-Lebenszyklus

Von besonderer Bedeutung im Framework ist der für Prüfungsklausuren relevante Typ Complex, der wiederum aus verschiedenen Teilaufgaben, wie Multiple-Choice-, Zuordnungs-, Lückentext-, Freitext- oder Graphik-Aufgaben besteht. Für ihn ist der in Abbildung 35 skizzierte Lebenszyklus definiert.

6.6.1 Architektur und Interaktionen

Zur Erläuterung, wie die wichtigsten Komponenten des Aufgaben-Frameworks zur Laufzeit interagieren, enthält Abbildung 36 ein UML-Kompositions-Strukturdiagramm. Es zeigt den TaskletContainer, den TaskManager und die Webapplikation TaskModel View sowie die von ihnen verwalteten Elemente, welche in ihren Hierarchien dargestellt sind.

Domain Design

61

Orthogonales Variabilitätsmodell (Ausschnitt)

TaskletContainer TaskManager

«component»ComplexTaskFactory

«component»ComplexTaskBuilder

«component»ComplexTaskHandlingDAO

«component»ComplexTaskDefDAO

Management Control(store/delete task defs)Tasklet

ComplexTasklet UploadTaskletRemoteTasklet

*

SubTasklet

SubTasklet_MC

SubTasklet_Mapping

SubTasklet_Cloze

SubTasklet_Text

SubTasklet_Paint

TaskDef

ComplexTaskDef UploadTaskDefRemoteTaskDef

*

SubTaskDef

-taskDef

* 1

Lifecycle Control

TaskFactory

TaskFactory

TaskFactory is the interface of ahost-specific component offeringpersistence support.

TaskModel View

«component»SubTaskletViewFactory

SubTaskletView_MC SubTaskletView_Mapping SubTaskletView_Cloze

SubTaskletView_Text SubTaskletView_Paint

ExecuteAction

«create» «create» «create»

«create» «create»

CommitAction …..SavePageAction

requires_v_vp

VP

ComplexSubTask Types

Multiple ChoiceV

MappingV

ClozeV

TextV

Paint/Draw

V

VP

TaskTypes

ComplexV

UploadV

RemoteV

VP

PersistenceBy

Abbildung 36 Kompositions-Strukturdiagramm Aufgaben-Framework

6.6.2 Variabilität

Das unter dem Kompositions-Strukturdiagramm abgebildete Variabilitätsmodell enthält die bereits erwähnten Aufgaben- (Task Types) sowie die im Fall der Complex-Variante vorhandenen Teilaufgaben-Typen (SubTask Types).

Um die Übersichtlichkeit zu gewährleisten sind im Diagramm keine Traceability-Links eingezeichnet worden. Die Verbindung zwischen Varianten im Variationsmodell und Elementen im UML-Diagramm ist durch gleiche Bezeichnungen gegeben.

Dabei ist für die Variationspunkte weniger die Möglichkeit relevant, je nach Applikation bestimmte Aufgabentypen auslassen zu können, als die Erweiterbarkeit mit neuen Typen zu gewährleisten. Konkret können im Framework auf zwei Ebenen neue Aufgaben hinzugefügt werden: zum einen als Tasklet und zum anderen als SubTasklet, das eine Teilaufgabe einer größeren Complex-Aufgabe darstellt.

Domain Design

62

Damit die Referenz-Implementierung flexibel in das elatePortal, den Prüfungsserver oder in Fremdsysteme integriert werden kann, wurden Persistenzaufgaben in einer Komponente TaskFactory gekapselt (siehe Variationspunkt Persistence By in Abbildung 36), die spezifisch implementiert werden muss. Ihr Interface ist wichtiger Bestandteil der API.

6.7 elatePortal

Bei der Entwicklung der Referenzarchitektur des elatePortals spielten zwei Gesichtspunkte eine wichtige Rolle. Zum einen mussten die in den Vorbetrachtungen (siehe Kapitel 6.3.1) erläuterten nichtfunktionalen (Qualitäts-)Anforderungen in angemessener Weise berücksichtigt werden und zum anderen hatte die Verwendung von Portaltechnologie in Form des Portalservers Jetspeed-2 einen signifikanten Einfluss auf das Design.

In Abbildung 37 ist die grobe Schichtenarchitektur des elatePortals in Form eines UML-Paketdiagramms dargestellt. Daraus wird ersichtlich, wie jede einzelne Ebene ihre darunterliegende kapselt. Insbesondere greifen alle Portlets, Servlets bzw. WebServices nur über die elatePortal-API auf die Business-Schicht zu, die in Form von Spring-Komponenten realisiert wurde. Außerdem ist zu erkennen, in welche Ebenen die einzelnen Bestandteile des Aufgaben-Frameworks in das Portal integriert worden sind.

Middle Tier

Paketdiagramm zur Schichtenarchitektur im elatePortal

Portlets (JSR168, Apache Portals Bridges) Servlets Web-Service

«facade»elatePortal API

Spring Components

«facade»Data Access Objects

Data Access Objects for Apache OJB

«facade»TaskModel API

«framework»TaskModel RI

TaskModel View (Struts)

Client Tier

Application Tier Business Tier

Enterprise Information Tier

DBTomcat Servlet

Container

Jetspeed2 Portal Server

Spring ComponentsDAOsPersistence VOs

n-Tier-Modell

Abbildung 37 Grobe Architektur des elatePortals

Domain Design

63

Da in J2EE-Umgebungen Architekturen häufig mit dem n-Tier-Modell beschrieben werden [Ar05], ist eine entsprechende Darstellung unter dem Paketdiagramm abgebildet. Die Schichten des elatePortals bilden diesbezüglich den Middle-Tier, der wiederum aus dem Application1- und dem Business-Tier besteht.

Die strikte Kapselung der Schichten macht jeweils einen Austausch möglich, dessen Aufwand auf die jeweilige Schicht (mit Anpassung der darüber liegenden) beschränkt ist. Dieses Prinzip wird auch Dependency Inversion genannt. Die Austauschbarkeit gilt insbesondere für die Referenzimplementierung des Aufgaben-Frameworks sowie die unterste Datenzugriffsschicht für den objektrelationalen Mapper Apache OJB, die theoretisch gegen eine Implementierung mit z.B. Hibernate2 getauscht werden könnte.

Jedoch ist anzumerken, dass der Aufwand eines Austauschs zwar durch Verwendung eines modellbasierten Ansatzes zur Generierung datenbankspezifischer DDL-Skripte, der objektrelationalen Mapping-Konfiguration (siehe Kapitel 7.6.5) und der Entitäts-Klassen minimiert werden konnte, er aber dennoch nicht vollständig transparent durchführbar ist. Dafür sind Transaktionskonzepte, Datentypen und unterstützte SQL-Versionen zwischen verschiedenen Datenbanken zu unterschiedlich. Insbesondere existieren in der im elatePortal verwendeten MySQL-Datenbank3 Besonderheiten bzgl. der Behandlung von BLOB-Feldern sowie des nichtstandardisierten Autoincrement für Primärschlüssel4.

6.7.1 Struktur

Die in Abbildung 37 dargestellte oberste Schicht des elatePortals dient in erster Linie der Realisierung der Benutzeroberfläche, aber auch der Bereitstellung von Web-Services zur Anbindung anderer Systeme, wie des Prüfungsservers.

In dieser Schicht spielt der Einfluss von Portaltechnologie die größte Rolle. Sie unterscheidet sich teilweise maßgeblich von der Präsenationsschicht normaler Webapplika-tionen. Das lässt sich auf die spezielle Art des Deployments, den genauer definierten Lebenszyklus, die unterschiedliche Anfragebehandlung (Unterscheidung zwischen sog. Action- und Render-Requests) sowie die Einbettung von Portlets in Portal-Seiten zurückführen [AH03].

Portlets erzwingen durch die Spezifikation von separaten Action- und Render-Requests die Einhaltung des MVC-Patterns, wofür bei Servlets bekanntermaßen MVC-Frameworks dienen. MVC (Model-View-Controller) ist ein Design-Pattern, das Grundlage der meisten Webapplikations-Frameworks ist (vgl. Model 2 von Sun [SSJ02]).

Alle Portlets entsprechen der Portlet-Spezifikation JSR168 [AH03], wobei viele, je nach Komplexität, mit Hilfe eines weitergehenden Web-Frameworks konzipiert wurden. Zur Anwendung kam dafür die Struts Bridge aus dem Apache Portals Bridges-Projekt5, mit der Portlets nahezu wie normale Struts-Webapplikationen6 entwickelt werden konnten.

1 auch: Web-Tier 2 http://www.hibernate.org 3 http://www.mysql.org 4 Erläuterungen zu Datenbank-Termini z.B. in [HR01] 5 http://portals.apache.org/bridges 6 http://struts.apache.org

Domain Design

64

Darüber hinaus werden Servlets in der Präsentationsschicht für Funktionen benötigt, die Portlets aufgrund ihres Konzeptes nicht ausführen können. Dazu zählen beispielsweise Download-Funktionen oder die Unterstützung von AJAX-Funktionalität [Ga05]. Zur Realisierung der Web-Service-Schnittstelle kam Apache AXIS1 zum Einsatz.

In der mittleren Schicht befinden sich Spring-Komponenten, die aus einem oder mehreren POJOs bestehen. Ihre Komposition erfolgt durch den Spring-Container mit Hilfe von Konfigurationsdateien im XML-Format, die in Anhang A.3, Abbildung 52 zu finden sind.

6.7.2 Textur

Die unter den Spring-Komponenten liegende Kapselung der Datenzugriffsschicht wird durch Anwendung des DAO-Patterns [Su02] realisiert. So besteht die Schicht Data Access Objects nur aus Interfaces mit anwendungsfallbezogenen Methoden, die von den in der darunterliegenden Schicht befindlichen Implementierungen mit Apache OJB realisiert werden.

Weitere im elatePortal verwendete Design-Patterns waren:

• Value Objects2 (VO) [Su02] stellen ein wichtiges Pattern zur Kapselung der Schichten dar, indem sie in einem Objekt mehrere feingranulare Daten transportie-ren. Das vermeidet das Durchreichen von Referenzen aus niedrigeren Schichten, was sonst zur Folge hätte, dass obere Schichten an viel tiefere gebunden wären.

• Factories [Ga95] kapseln die Instanziierung von Objekten. Es wurde hauptsächlich im Aufgaben-Framework eingesetzt, außerdem realisiert der Spring-Container selbst das Factory-Pattern.

• Das Observer-Pattern [Ga95] ermöglicht die Weitergabe von Ereignissen in Komponenten an interessierte Abhörer (Listener). Darauf basiert im elatePortal ein spezielles Event-Modell, mit dem z.B. eMail-Benachrichtigungen von Benutzern realisiert wurden.

Zu wichtigen Styles der Referenzarchitektur zählten neben den bereits erläuterten Prinzipien Inversion of Control und Dependency Inversion insbesondere noch:

• Law of Demeter [LH89], das auch „Don’t talk to Strangers“ genannt wird, verrin-gert die Kopplung zwischen Klassen, indem Methoden nur Methoden von Klassen-, Instanz-, Paramter-, oder lokalen Variablen aufrufen dürfen.

• Service Abstraction forciert den Zugriff auf Implementierungen über Abstraktionen in Form von Interfaces. Das wird mit den APIs des elatePortals und des Aufgaben-Frameworks sowie dem Web-Service zur Anbindung des Prüfungsservers realisiert.

6.8 Prüfungsserver

Der Prüfungsserver wurde in Form einer Webapplikation konzipiert mit dem Ziel eines einfachen Deployments in einen Servlet Container. Dies geschieht bei J2EE-

1 http://ws.apache.org/axis 2 auch: Data Transfer Object (DTO)

Domain Design

65

Webapplikationen in der Regel durch Hochladen eines WAR-Archives über eine Management-Funktion des Containers.

Aus Gründen des einfacheren Deployments wurde vorerst auf den Einsatz einer Datenbank verzichtet. Die Speicherung persistenter Daten erfolgt im XML-Format in das Dateisystem, wofür das modellbasierte JAXB-Framework benutzt worden ist, welches im Rahmen des Domain Realisation (Kapitel 7.5.3) erläutert wird.

Diese Lösung hat Vor- und Nachteile. Zum einen erleichtert sie wesentlich das Aufsetzen des Prüfungsservers sowie dessen Backup, zum anderen muss die Speicherung aufwendig synchronisiert werden, um die Datenintegrität zu gewährleisten. Trotzdem erwies sich die XML-Lösung als erstaunlich performant und sehr stabil im Prüfungseinsatz. Für die Zukunft wäre jedoch ein möglicher Umstieg, z.B. auf die Java-basierte Datenbank Derby1, mit geringem Aufwand durch die Implementierung neuer DAOs möglich.

Für die Erstellung des Prüfungsservers wurde der so genannte Kickstarter AppFuse2 verwendet, der eine Integrationslösung zur agilen Entwicklung von Webapplikationen bereitstellt [PS06]. Darin sind bereits verschiedene Grundfunktionen, wie z.B. ein Sicherheitsmodell3 mit Benutzerverwaltung enthalten. Darüber hinaus war AppFuse durch die Verwendung von Spring sehr gut an die Anforderungen des Prüfungsservers anpassbar.

6.9 Auswertung

Das vorliegende Kapitel betrachtete die Umsetzung des Domain Designs im Rahmen des elatePortal-Projektes. Nachdem im ersten Teil die theoretische Vorgehensweise sowie wichtige Einflussfaktoren auf die Referenzarchitektur erläutert wurden, befasste sich der zweite mit der konkreten Anwendung und zeigte verschiedene Design-Aspekte sowie praxisrelevante Lösungen auf.

Gegenüber dem Design von Einzelsystemen definiert das SPL-Framework die Einführung von Variabilität und berücksichtigt von Anfang an die Qualitätsanforderungen Flexibilität, Entwicklungsfähigkeit und Wartbarkeit. Das SPL-Framework beschreibt weniger eine Vorgehensweise als wichtige Aktivitäten, die im Hinblick auf die genannten Einflussfakto-ren bei der Architekturentwicklung notwendig sind.

6.9.1 Portaltechnologie

Gegenüber einfacheren Webapplikationen ermöglicht die Verwendung von Portaltechno-logie die Entwicklung von sehr flexibel erweiterbaren Architekturen, indem später beliebige JSR168-kompatible Portletapplikationen hinzugefügt werden können. Außerdem wird der Architekt dazu gezwungen, etablierte Standards aus dem J2EE-Bereich zu verwenden, was von Design Patterns über Komponentenkonzepte bis hin zu einem standardisiertem Deployment-Prozess reicht. Insbesondere sind die einzelnen Portletappli-kationen durch den Portlet-Standard JSR168 nicht mehr direkt an einen bestimmten Portalserver gebunden. Das beeinflusst positiv die Entwicklungsfähigkeit der Plattform.

1 http://db.apache.org/derby/ 2 http://www.appfuse.net 3 Acegi-Security, siehe Kapitel 6.4

Domain Design

66

Portalserver stellen eine Infrastruktur bereit, welche bereits viele Lösungen und Funktionen mitbringt, die sonst selbst entwickelt werden müssten. Allerdings wird durch den JSR168 nur ein bestimmter Teil der Funktionalität abgedeckt. Wenn, wie beim elatePortal, der Zugriff auf die sonstige Portalserver-API angemessen gekapselt wird, kann die Bindung minimiert und späterer Migrationsaufwand deutlich verringert werden.

Auch eine Verbesserung der Wartbarkeit kann durch Portalserver erreicht werden. So besteht die Möglichkeit, neue Portletapplikationen während der Laufzeit zu deployen und bestehende zu aktualisieren. In Produktivumgebungen erhöht das die Verfügbarkeit und erspart langwierige Neustart-Prozeduren.

Den erwähnten Vorteilen stehen jedoch auch Nachteile und Risiken gegenüber. So entsteht durch Portaltechnologie eine deutlich höhere Komplexität, die während der Entwicklung zu beachten ist. Projekte müssen eine bestimmte Größe aufweisen, um von den Vorteilen eines Portalservers profitieren zu können. Im Produktlinienkontext ist das jedoch häufig der Fall. Außerdem entsteht bedingt durch den besonderen Render-Prozess von Portlets bei jedem Aufruf einer Portalseite ein nicht unerheblicher Overhead an Prozessor-Leistung, was den Einsatz angemessener Server-Hardware impliziert.

6.9.2 Komponenten-Framework

Das SPL-Framework erläutert grundlegende Konzepte in Bezug auf die Verwendung von Komponententechnologien, schreibt jedoch kein konkretes Framework vor.

Im Vergleich zum J2EE-Standard Enterprise Java Beans 2.0 stellt das Spring-Framework im Hinblick auf das Design-Prinzip Separation of Concerns die bessere Lösung dar. Spring-Komponenten sind flexibler in mehreren Umgebungen verwendbar, da sie zur Ausführung keinen schwergewichtigen Container benötigen und nicht durch Interface-Abhängigkeiten an Spring gebunden sind. Daraus resultiert auch eine wesentlich bessere Testbarkeit, was eine wichtige Eigenschaft für Produktlinien ist (vgl. Kapitel 8.4). Der Erfolg von Spring führte dazu, dass die EJB-Spezifikation in der neuesten Version 3.0 [MK06] auch in Richtung leichtgewichtiger Konzepte geht.

Das SPL-Framework betrachtet nicht weitergehende Ansätze für Separation of Concerns. Das betrifft insbesondere den Hyperspace-Ansatz, der zwar noch keine besondere Bedeutung in der Praxis besitzt, jedoch von den in Kapitel 6.3.2 genannten Ansätzen den umfassendsten darstellt. Außerdem wird im SPL-Framework zwar aspektorientierte Programmierung erläutert, aber es fehlen der Bezug zur Gesamtarchitektur sowie Betrachtungen zum Einfluss auf die nachfolgenden Prozesse des Domain Designs.

6.9.3 Variabilität

Das Hauptanliegen des SPL-Frameworks im Domain Design ist die Unterstützung von Variabilität in der Referenzarchitektur. Variationspunkte und Varianten konnten mit dem orthogonalen Variabilitätsmodell konsistent beschrieben und mit den bereits im Domain RE definierten verknüpft werden. Darüber hinaus stellt die Möglichkeit, Variabilität zunächst unabhängig von technischen Lösungen modellieren zu können, einen weiteren Vorteil dar. Eine vorherige, gesamtheitliche Betrachtung der Variabilität erleichtert die Auswahl von angemessenen Technologien und Architektur-Konzepten.

Domain Design

67

6.9.4 Kombination von Variabilität und Hyperspace

Das Variabilitätsmodell definiert insbesondere auch Abhängigkeitsbeziehungen zwischen einzelnen Varianten. Falls jedoch eine Variante auch von anderen Belangen, wie bspw. von der Zeit abhängig gemacht werden soll, muss die Einführung neuer Notationen und eine Änderung des Metamodells erfolgen. Ein weiteres orthogonales Modell stellt keine angemessene Alternative dazu dar.

Aus diesem Grund ist eine abstraktere Betrachtung von Variabilität in Produktlinien, wie z.B. durch eine Verknüpfung mit dem Hyperspace-Ansatz, sinnvoll. Da Variabilität letztlich wieder eine Aufteilung der Plattform darstellt, können Varianten als Teil einer eigenen Dimension im Hyperspace-Ansatz betrachtet werden. In Hyperspace-Terminologie bezeichnet dann ein sog. Hyper-Modul eine Applikation mit einer bestimmten Auswahl von Varianten. Traceability wird in diesem Fall direkt von Hyperspace übernommen. Durch Hinzufügen weiterer Dimensionen können unterschiedliche Zerlegungen zueinander in Relation gesetzt werden. Mit einer zusätzlichen Zeit-Dimension ist insbesondere eine konsistente Modellierung der Evolution des Variabilitätsmodells möglich. Denkbar ist aber auch die Einführung einer Priorisierung (vgl. Kapitel 5.2.3).

Ob auch eine vollständige Abbildung des orthogonalen Variabilitätsmodells auf den Hyperspace-Ansatz (wie bei Hyper/J und Hyper/UML) sinnvoll ist, kann an dieser Stelle nicht eingeschätzt werden. Es würde die Generierung eines gebundenen Variabilitätsmo-dells ermöglichen, d.h. eines Modells, in dem Variationspunkte mit Varianten für eine spezielle Applikation gebunden sind. Für die Beurteilung, ob ein darüber hinaus gehender Nutzen für die Produktlinien-Entwicklung erzielbar ist, sind weitere Untersuchungen notwendig.

Domain Realisation

68

7 Domain Realisation

Das vorhergehende Kapitel erläuterte die Entwicklung der Referenzarchitektur, die eine Grundlage für mehrere Applikationen darstellt. Das Domain Realisation beschäftigt sich mit der Verfeinerung und Implementierung der entstandenen Design-Artefakte. Das geschieht durch die Verwendung von Modellierungsmethoden, die feingranularer als die im Domain Design verwendeten sind und so als Ausgangsbasis für die Implementierung genutzt werden können. Letztere erzeugt die wiederverwendbaren Software-Artefakte, d.h. die eigentliche Plattform der Produktlinie.

Dieses Kapitel erläutert das detaillierte Design des Aufgabenframeworks und des elatePortals, die Entwicklung eines Build- und Deployment-Konzeptes sowie Mechanis-men, mit denen eine Bindung der Variabilität in den konkreten Applikationen realisierbar ist.

7.1 Kontext

Abbildung 38 stellt die im SPL-Framework direkt an das Domain Realisation angrenzen-den Prozesse dar. Ausgangspunkt ist die Referenzarchitektur des Domain Designs, anhand dessen die wiederverwendbaren Software-Artefakte detailliert modelliert und implemen-tiert werden.

DomainRealisation

DomainDesign

DomainTesting

ApplicationRealisation

Abbildung 38 Kontext Domain Realisation

Wie für die vorhergehenden Teilprozesse sind auch für das Domain Realisation Feedback-Schleifen vorgesehen:

• Feedback aus dem Domain Realisation zurück an das Domain Design (wurde bereits im Domain Design erläutert, vgl. Kapitel 6.1).

• Feedback des Domain Testing bzgl. der Testergebnisse, anhand derer Überarbei-tungen zur Fehlerbeseitigung durchgeführt werden. Kapitel 8 erläutert die Überprü-fung mit Tests und statischer Analyse, auf spezielle Methoden zur Architekturvali-dierung konnte verzichtet werden.

• Feedback des Application Realisation, das wichtig für die Evolution der Plattform ist, z.B. wenn sich Teile der Umgebung (Bibliotheken, Laufzeitumgebungen) än-dern und Implementierungen angepasst werden müssen.

7.2 Artefakte

Die Ergebnisse des Domain Realisation sind detaillierte Modelle der Architektur sowie implementierte Software-Artefakte. Dazu gehören hauptsächlich Komponenten und

Domain Realisation

69

Interfaces, aber auch Datenschemen, Protokolle, Build- und Deployment-Deskriptoren. Insbesondere die letzten beiden Artefakte spielten im Rahmen des Build-Managements eine wichtige Rolle. Es wird von Build-Tools unterstützt, die das System aus den Artefakten zusammenfügen und Abhängigkeiten zwischen diesen auflösen können.

Den größten Anteil der Tätigkeiten im Domain Realisation stellt die Entwicklung von Interfaces und Komponenten dar, für die das SPL-Framework folgende Charakteristika hervorhebt.

7.2.1 Interfaces

Interfaces sind der nach außen sichtbare Teil von Komponenten und werden zum Zusammenfügen der Gesamtplattform benötigt. Sie können nicht direkt Komponenten zugeordnet werden, da einerseits Komponenten mehrere Interfaces implementieren und andererseits mehrere Implementierungen für ein Interface existieren können.

Das Interface-Design sollte größtenteils in sich abgeschlossen sein und nicht zu viele externe Abhängigkeiten durch Referenzen auf andere Interfaces besitzen. Dadurch entsteht die Gefahr von zyklischen Abhängigkeiten zwischen Bereichen der Architektur, die ursprünglich voneinander unabhängig sein sollten. Solche Abhängigkeiten sind ein Verstoß gegen das Separation of Concerns und im Nachhinein nur schwer auflösbar.

7.2.2 Komponenten

Bei der Entwicklung von Komponenten muss ihre genaue Rolle und Position in der Referenzarchitektur bekannt sein, um Fehler in der Umsetzung zu vermeiden. Die wiederverwendbaren Komponenten der Produktlinien-Plattform müssen hohen Qualitäts-ansprüchen genügen, da sie Teil einer Vielzahl von Applikationen werden.

In der Regel werden die mit einer Komponente in Verbindung stehenden Interfaces in zwei Arten unterschieden [So06, Kapitel 19]: so stellen angebotene Interfaces1 die in der Komponente selbst vorhandene Funktionalität nach außen dar und benötigte Interfaces2 werden von der Komponente zum Aufruf fremder Funktionalität genutzt. Letztere werden auch als die externe Abhängigkeit bezeichnet.

7.2.3 Variabilität in Komponenten und Interfaces

Die Realisierung von Variabilität in Interfaces und Komponenten kann auf unterschiedli-che Art und Weise erfolgen. Die erste Möglichkeit besteht darin, Variabilität direkt in Interfaces einzuführen. Dazu müssten Komponenten immer eine bestimmte Variante der benötigten und öffentlichen Interfaces zugeordnet werden. Instabile Interfaces führen allerdings zu Konsistenzproblemen, weswegen der Ansatz vermieden werden sollte. Diese Vorgehensweise wird darüber hinaus von keinem bekannten Komponenten-Framework unterstützt. In Java müsste zu diesem Zweck die Introspection-/Reflection-Funktionalität verwendet werden.

1 auch: provided interfaces 2 auch: required interfaces

Domain Realisation

70

Vielmehr fokussiert das SPL-Framework die Realisierung von Variabilität auf Komponen-ten-Ebene. Dafür gibt es zwei Möglichkeiten, die auch beide im elatePortal-Projekt verwendet wurden:

• Variabilität innerhalb der Komponente

• Erstellung mehrerer Varianten einer Komponente

Das detaillierte Design von Komponenten wird in der Regel mit Klassendiagrammen dargestellt, die selbst bereits Variabilität durch Vererbung, multiple Assoziationen oder Klassenattribute enthalten. Das diese jedoch nicht für die Produktlinie relevant ist, forciert das SPL-Framework eine weitere Verfeinerung des orthogonalen Variabilitätsmodells, um wiederum Traceability-Links zu Klassendiagrammen definieren zu können.


Der Hauptunterschied zur Entwicklung von Einzelanwendungen besteht, analog zu den anderen Teilprozessen, im Vorhandensein von Variabilität, aber auch in der viel stärker bindenden Referenzarchitektur. Ein weiterer Punkt ist das Fehlen eines lauffähigen Systems, was Qualitätssicherungsmaßnahmen eine höhere Bedeutung zukommen lässt.

Zur Umsetzung von Interfaces und Komponenten forciert das SPL-Framework den Contract-First-Ansatz. Das heißt, dass Interfaces zunächst detailliert definiert werden müssen, bevor mit der Implementierung von Komponenten begonnen wird. Interfaces haben in Bezug auf spätere Änderungen eine gewisse Stabilität zu gewährleisten. Die durch Änderungen implizierten Anpassungen anderer Komponenten sollen reduziert und neue Fehlerquellen vermieden werden.

Contract-First ist das Gegenteil von Code-First. Das Vorgehen ist nicht neu, erlangte aber durch die Etablierung von Web-Services im Rahmen des SOA-Paradigmas besondere Bedeutung (vgl. [Fr05]).

7.3.1 Interface-Entwicklung

Beim Design von Interfaces ist darauf zu achten, dass nicht zu viele Details der implementierenden Komponenten mit aufgenommen werden. Sonst besteht die Gefahr, dass Variationspunkte zu zeitig gebunden werden und nicht mehr für alle Varianten im Application Realisation benutzbar sind. Das Finden eines angemessenen Detaillierungs-grades ist laut SPL-Framework ein wichtiger Aspekt des Interface-Designs.

7.3.2 Komponenten-Entwicklung

Die Entwicklung von Komponenten orientiert sich an zwei Gesichtspunkten. Den ersten stellen die hohen Qualitätsanforderungen dar, welche aufgrund der Verwendung in vielen Applikationen an sie gestellt werden. Komponenten müssen auf Robustheit hin entwickelt werden und dürfen keine impliziten Annahmen über vorhandene Ressourcen, Aufrufrei-henfolgen von Methoden bzw. deren Parameter machen. Der zweite Gesichtspunkt basiert auf der durch Variabilität eingeführten Komplexität in und zwischen den Komponenten. Variabilität kommt zwar hauptsächlich durch unterschiedliche Konfigurationen zustande, aber häufig werden auch mehrere Varianten einer Komponente entwickelt. Die richtige Balance zwischen den beiden Möglichkeiten zu finden und nicht in das Extrem der

Domain Realisation

71

exklusiven Verwendung nur einer zu kippen, stellt einen wichtigen Aspekt des Komponen-ten-Designs im SPL-Framework dar.

7.3.3 Exception-Konzept

Um auch zur Laufzeit die korrekte Funktionsweise von Komponenten sicherstellen zu können, ist die Entwicklung eines Exception-Konzepts notwendig [Ro01]. Dessen Design und Einhaltung ist häufig keine triviale Aufgabe, besonders wenn ganze Exception-Hierarchien verwendet werden. Betrachtungen zu Exception-Konzepten sind jedoch kein Bestandteil des SPL-Frameworks.

Wann welche Exception geworfen werden muss, ist in der Architektur-Textur definiert und die korrekte Umsetzung ist im Nachhinein nur schwer zu verifizieren. Ein typischer Fehler ist das Abfangen von Exceptions, die nicht behandelbar sind oder die Einführung zu vieler Exception-Klassen, woraus oft eine Maskierung von Fehlern resultiert.

«Java Class»CourseManagerException

ERROR_KEY_NOT_UNIQUE : StringERROR_ALREADY_ENROLLED : StringERROR_ENROLLMENT_INACTIVE : StringERROR_COURSE_FULL : StringERROR_ENROLLMENT_KEY_INVALID : StringERROR_ADDITIONAL_INFO_MISSING : StringERROR_ADDITIONAL_REQUIRED_INFO_NULL_VALUE : StringERROR_NOT_ENROLLED : StringERROR_NOT_CANCELLABLE : String

CourseManagerException ( )CourseManagerException ( )CourseManagerException ( )CourseManagerException ( )

Abbildung 39 Anwendungsfallbezogene Exception

In der API des elatePortals und des Aufgabenframeworks wurden für einige Komponenten geprüfte Exceptions definiert, die bestimmte Fehlerzustände1 mit anwendungsfallbezoge-nen Nachrichten an die oberen Schichten weiterleiteten. In Abbildung 39 ist beispielhaft eine CourseManagerException dargestellt.

Persistenz-Frameworks wie JDO2, Hibernate und OJB enthalten wiederum eigene Exception-Hierarchien zur Behandlung von Fehlern. Diese sind inkompatibel zueinander und verwenden häufig geprüfte Exceptions, die aber oft nicht sinnvoll behandelbar sind und als RuntimeException weitergeleitet werden müssen. Die zur Implementierung der DAO-Persistenz-Schicht verwendeten Spring Persistence-Templates ermöglichten die Verwendung eines einheitlichen Exception-Konzepts, das von spezifischen Exceptions der Persistenz-Frameworks (also OJB im elatePortal) abstrahiert.

1 Genaugenommen müsste von Ausnahmen statt Fehlern gesprochen werden. 2 Java Data Objects ist eine J2EE-Spezifikation (http://java.sun.com/products/jdo), die z.B. von OJB und Hibernate, neben eigenen APIs, implementiert wird.

Domain Realisation

72

7.4 Build-Management und Deployment

Obwohl Build-Prozesse bei Projekten wie dem elatePortal, die wiederum aus mehreren Teilprojekten bestehen, sehr komplex werden können, ist ein Build-Management kein Bestandteil des SPL-Frameworks. Dieses Kapitel beschreibt die Vorgehensweise im Rahmen des elatePortal-Projekts bei der Erstellung eines Build-Prozesses und geht anschließend auf das Deployment genauer ein.

Im Produktlinienkontext dienen Build-Prozesse der Erzeugung konkreter Applikationen aus der Plattform und werden im Application Realisation ausgeführt. Ein Build [BMN05, Kapitel 11] bezeichnet eine lauffähige Version eines Teil- oder des Gesamtprojektes. Das Build-Management befasst sich mit Einrichtung, Durchführung und Wartung von Build-Prozessen. Neben einem Build-Tool stellen wichtige Hilfsmittel Build-Skripte und die Build-Konfiguration dar.

7.4.1 Build-Umgebung

Negative Erfahrungen mit dem Build-Tool Apache Ant1 aus Vorgängerprojekten (wie z.B. dem UebManager), die sich insbesondere durch Probleme mit der Verwaltung von externen Abhängigkeiten sowie durch schnell unübersichtlich werdende Build-Skripte zeigten, führten zum Einsatz von Apache Maven2 für den Build- als auch für den Deployment-Prozess.

Maven verfolgt im Gegensatz zu Ant einen abstrakteren Ansatz, was in der Praxis bedeutet, dass der Build-Prozess eher deklarativ mit einem sog. Project Object Model (POM) als durch Build-Skripte beschrieben wird. Außerdem führt es eine in Java fehlende Versionierung von erstellten Artefakten (JAR-, WAR-, oder EAR-Archive [Su03a]) ein, forciert die Anwendung von Best-Practices durch standardisierte Verzeichnisstrukturen bzw. Namenskonventionen und bringt bereits eine Vielzahl von Plugins für weitergehende Aufgaben mit.

Das neuere Maven-2 [Kl06], das zusätzlich das Konzept eines Build-Lifecycles einführt, war zum Projektstart noch nicht verfügbar. Eine Migration ist jedoch perspektivisch geplant, da es außerdem weitere Verbesserungen zur Unterstützung großer Projekte enthält.

7.4.2 Projekt-Setup

Abbildung 40 zeigt die Projekt-Verzeichnisstruktur in Verbindung mit den Artefakten, die auch bereits im Verteilungs-Diagramm (Kapitel 6.5.1, Abbildung 33) des Domain Designs abgebildet sind. Jedes stellt in Maven ein Teilprojekt dar und wird mit einem POM beschrieben, das neben Metainformationen wie einer Artefakt-ID insbesondere die (internen und externen) Abhängigkeiten enthält. Daraus kann Maven im Build-Prozess die notwendige Reihenfolge bestimmen, in denen die einzelnen Artefakte erstellt werden müssen, und außerdem externe Bibliotheken aus einem öffentlichen Repository herunterladen.

1 http://ant.apache.org 2 http://maven.apache.org

Domain Realisation

73

Wichtig ist zudem, dass kein Zyklus bei der Definition von Abhängigkeiten entsteht, der einen Build verhindern würde. Das kann oft bei großen Projekten, wie auch bei Jetspeed-2, beobachtet werden. In diesem Fall werden zwingend frühere Versionen einzelner Artefakte benötigt um das Gesamtprojekt erstellen zu können.

Orthogonales Variabilitätsmodell«artifact»

elatePortal-api-0.2-dev.jar

«artifact»

jforum.war

«artifact»

miniforum.war

«artifact»

elatePA.war

«artifact»

jetspeed-deploy-0.2-dev.jar

«artifact»

taskmodel-api-0.2-dev.jar

«artifact»

taskmodel-core-0.2-dev.jar«artifact»


VP

optionalPortlet

Applications

VP

Forum

JForumV

Jetspeed DemoPortlets

V

RSS Portlets

VBedework

Calendar Portlet

V...

V

MiniForumV

«artifact»

bedework.war

Abbildung 40 Verteilung von Artefakten im Projekt-Setup

So stellte sich die Verwaltung der Abhängigkeiten auch als einer der größten Vorteile von Maven für das elatePortal-Projekt heraus, da es ca. 90 externe JAR-Archive benötigte. Maven lädt zum ersten Start des Build-Prozesses alle Archive in der angegebenen Version in ein lokales Repository, so dass sie nicht im Projekt-CVS liegen müssen. Ein weiterer Grund für die Verwendung von Maven war, dass in früheren Projekten des Öfteren Probleme durch Bibliotheken entstanden sind, die in einer falschen Version vorlagen.

Variabilität im Build-Prozess besteht in Form der Variationspunkte Forum und optional Portlet Applications, die verschiedene Portlet-Applikationen bezeichnen, welche je nach Konfiguration von Maven erstellt werden. Dabei referenzieren die Varianten Jetspeed Demo Portlets und RSS weitere Portlet-Applikationen, die bereits Bestandteil der Jetspeed-Distribution sind und nur von Maven heruntergeladen werden müssen.

7.4.3 Deployment

Obwohl das Deployment erst im Application Realisation ausgeführt wird, muss dessen Umsetzung (analog zum Build-Prozess) bereits im Domain Realisation erfolgen. Während die Definition des Build-Prozesses mit Maven nahezu vollständig deklarativ durch die jeweiligen POMs möglich war, mussten für das Deployment Skripte geschrieben werden. Sie realisieren das Gesamt-Deployment in mehreren Phasen. Dazu gehören das Erstellen der Datenbank sowie das Deployment von Jetspeed, des elatePortals und der Bestandteile des Aufgaben-Frameworks.

Variabilität im Deployment des elatePortals besteht wieder in Form verschiedener Portletapplikationen, wie sie in den Variationspunkten der Abbildung 40 dargestellt sind.

Domain Realisation

74

Die Auswahl von Varianten und damit die Bindung der Variabilität erfolgt analog zum Build-Prozess durch Maven-Konfigurationsdateien.

7.5 Detailliertes Design des Aufgaben-Frameworks

Im Domain Design wurde die grobe Struktur des Aufgaben-Frameworks erarbeitet, das aus der API, einer Referenzimplementierung und einer Webapplikation besteht. Im Folgenden wird das detaillierte Design der drei Bestandteile erläutert.

7.5.1 API

Da die API bereits aus ca. 50 Interfaces und die Referenzimplementierung aus etwa 116 Klassen besteht, ist in Abbildung 41 nur ein kleiner Ausschnitt der API dargestellt. Insbesondere ist in der Mitte das Interface TaskFactory abgebildet, das für Persisten-zaufgaben benötigt wird und vom Host-System implementiert werden muss. Es realisiert den Variationspunkt Persistence By, der während des Domain Designs in Kapitel 6.6.2 eingeführt worden ist.

«Java Interface»

getId ( ) : long

getTitle ( ) : String

getType ( ) : String

getShortDescription ( ) : String

isStopped ( ) : booleangetDeadline ( ) : Long

isActive ( ) : boolean

«Java Class»TaskApiException

TaskApiException (

)

TaskApiException ( message : String

)TaskApiException ( message : String, cause : Throwable )

TaskApiException ( cause : Throwable )

«Java Interface»

availableTypes ( ) : void

getCategories ( ) : void

getCategories ( categoryFilter : CategoryFilter ) : void

getTaskDef ( taskId : long ) : TaskDef

getTaskDefs ( ) : void

getTaskDefs ( filter : TaskFilter ) : voidgetTasklet ( userId : String, taskId : long ) : Tasklet

getTasklets ( taskId : long ) : void

getUserIdsOfAvailableTasklets ( taskId : long ) : void

createTasklet ( userId : String, taskId : long ) : Tasklet

storeTasklet ( tasklet : Tasklet ) : void

removeTasklet ( userId : String, taskId : long ) : void

logPostData ( msg : String, tasklet : Tasklet, ip : String ) : void

logPostData ( msg : String, throwable : Throwable, tasklet : Tasklet, ip : String ) : void

getUserIdsOfTaskletsAssignedToCorrector ( taskId : long, correctorId : String ) : void

getUserInfo ( login : String ) : UserInfo

«Java Interface»

createTasklet ( taskId : long, userId : String ) : Tasklet

getTasklet ( taskId : long, userId : String ) : Tasklet

getTasklets ( taskId : long ) : void

removeTasklet ( taskId : long, userId : String ) : void

calculateStatistics ( taskId : long ) : TaskStatistics

assignRandomTaskletToCorrector ( taskId : long, correctorId : String ) : void

getTaskletsAssignedToCorrector ( taskId : long, correctorId : String ) : void

getTaskFactory ( ) : TaskFactoryreset ( ) : void

«Java Interface»

order : int

value : StringFLAG_HAS_CORRECTOR_ANNOTATION : String = "has_corrector_annotation";

FLAG_HAS_STUDENT_ANNOTATION : String = "has_student_annotation";

getOrder ( ) : int

toString ( ) : String

getValue ( ) : String

Status ( order : int, value : String ) : voidupdate ( ) : void

getUserId ( ) : String

getTaskId ( ) : longgetStatus ( )

hasOrPassedStatus ( ) : boolean

getTaskletCorrection ( ) : TaskletCorrection

getFlags ( ) : void

addFlag ( flag : String ) : void

removeFlag ( flag : String ) : voidassignToCorrector ( correctorId : String ) : void

logPostData ( msg : String, ip : String ) : void

logPostData ( msg : String, throwable : Throwable, ip : String ) : void

«Java Interface»

getDate ( ) : long

getText ( ) : StringisAcknowledged ( ) : boolean

setAcknowledged ( acknowledged : boolean ) : void

«Java Interface»

getId ( ) : long

getName ( ) : String

getTaskDefs ( ) : void

«Java Interface»

getPoints ( ) : Float

getCorrectorAnnotation ( ) : StringgetStudentAnnotations ( ) : void

getCorrector ( ) : String

getCorrectorHistory ( ) : void

setPoints ( points : Float ) : void

setCorrectorAnnotation ( value : String ) : void

addStudentAnnotation ( annotation : String ) : void

setCorrector ( value : String ) : void

reset ( ) : void

«Java Interface»

matchesCriteria ( category : TaskCategory ) : boolean

«Java Interface»

getDescription ( ) : String

getCategories ( ) : void

getCategories ( categoryFilter : CategoryFilter ) : void

getTaskDefs ( ) : voidgetTaskDefs ( filter : TaskFilter ) : void

getTaskDef ( id : long ) : TaskDef

getTaskDef ( filter : TaskFilter, id : long ) : TaskDef

getTaskletContainer ( ) : TaskletContainer

getTaskFactory ( ) : TaskFactory

getReportBuilder ( ) : ReportBuilder

«Java Interface»

getLogin ( ) : String

getFirstName ( ) : String

getName ( ) : String

getEMail ( ) : String

«Java Class»TaskModelPersistenceException

TaskModelPersistenceException (

)TaskModelPersistenceException ( message : String

)

TaskModelPersistenceException ( message : String, cause : Throwable )

TaskModelPersistenceException ( cause : Throwable )

«use»

«use»

«use»

«use»

«use»

«use» «use»

«use»

«use»

«use»

«use»

«use»

«use»

Abbildung 41 Detailliertes Design der Framework-API (Ausschnitt)

Domain Realisation

75

7.5.2 Präsentations-Webapplikation

Die Präsentationsschicht im Aufgaben-Framework stellt eine auf Struts basierende Webapplikation dar. Struts ist ein seitenbasiertes MVC-Framework (vgl. Kapitel 6.7.1), dem aufgrund seiner Einfachheit und bereits bestehender Erfahrungen der Vorzug gegenüber moderneren, komponentenbasierten Frameworks wie Java Server Faces [BK06] gegeben wurde. Die Struktur der Webapplikation sowie der Fluss zwischen einzelnen Seiten (Struts Actions) ist in Anhang A.3, Abbildung 56 dargestellt.

Die Webapplikation greift über die API auf die Referenzimplementierung zu, welche sich im elatePortal bzw. im Prüfungsserver und damit in einem fremden Servlet-Kontext befindet und nicht direkt zugänglich ist. Als Lösung des Problems muss, wie bereits im Domain Design erwähnt (vgl. Kapitel 6.5.3), die API von einem den Kontexten übergeordneten Classloader verwaltet werden. In Abbildung 42 sind die für diesen Mechanismus relevanten Interfaces der API sowie ihre Implementierungen in der RI dargestellt.

«Java Interface»

getTaskDef ( )getTaskId ( )getReturnURL ( )

«Java Class»TaskModelViewDelegate

storeDelegateObject ( )getDelegateObject ( )removeSession ( )

«Java Interface»

getCorrectorLogin ( )getCorrectorUserName ( )getTaskManager ( )getTaskDef ( )getTasklets ( )isPrivileged ( )

«Java Interface»

getLogin ( )getUserName ( )getTasklet ( )

«Java Class»TaskModelViewDelegateObjectImpl

login : StringuserName : StringtaskId : longtaskManager : TaskManagerreturnURL : StringTaskModelViewDelegateObjectImpl ( )getLogin ( )getUserName ( )getTaskDef ( )getTaskId ( )getTasklet ( )getReturnURL ( )

«Java Class»CorrectorDelegateObjectImpl

correctorLogin : StringcorrectorUserName : StringtaskManager : TaskManagertaskDef : TaskDefprivileged : booleanreturnURL : StringCorrectorDelegateObjectImpl ( )getCorrectorLogin ( )getCorrectorUserName ( )getTaskManager ( )getTaskDef ( )getTasklets ( )getTaskId ( )isPrivileged ( )getReturnURL ( )

«use»

Abbildung 42 Kontextübergreifende Kommunikation

Die Klasse TaskModelViewDelegate, die von einem den Webapplikations-Kontexten übergeordneten Classloader (vgl. Kapitel 6.5.2) verwaltet wird, speichert unter der Session-ID des Benutzers Instanzen von Delegate-Object zwischen. Das heißt, dass letztere im Kontext der RI erzeugt, zwischengespeichert und schließlich im Kontext der Präsentations-Webapplikation wieder geladen werden. Zudem waren weitere Anpassungen im Servlet Container notwendig, damit Session-IDs für alle Kontexte gültig sind und kein Memory-Leak1 in der Klasse TaskModelViewDelegate entsteht.

1 Bezeichnet das Füllen des Heap-Speichers mit Instanzen, die vom Garbage Collector durch vorhandene Referenzen nicht gelöscht werden können.

Domain Realisation

76

7.5.3 Referenz-Implementierung

Die Referenz-Implementierung des Aufgaben-Frameworks besteht aus Spring-Komponenten, welche die Interfaces der API implementieren. Sie wurden damit wieder als POJOs realisiert und mit einer Konfigurationsdatei im XML-Format zusammengefügt (siehe Anhang A.3, Abbildung 52). Dadurch sind deklarativ Komponenten austauschbar und insbesondere wird an dieser Stelle die Implementierung des Interfaces TaskFactory spezifiziert.

Ein wichtiger Teil der RI beschäftigt sich mit der Verarbeitung von Aufgabendefinitionen für den Aufgabentyp Complex, die in XML-Dateien abgespeichert sind. Sie werden mit dem Aufgaben-Editor, der zu Beginn in Kapitel 2.2.4 genannt worden ist, erstellt und enthalten Teilaufgabendefinitionen, die in Blöcken und Kategorien hierarchisch angeordnet sind. Das dazugehörige XML-Schema ist in Anhang A.3, Abbildung 55 dargestellt.

Aufgrund der Komplexität des Schemas wäre der Zugriff auf die XML-Dateien mit einem XML-Parser, der auf einer „low level“-API wie z.B. JAXP1 basiert, viel zu aufwendig und auch fehleranfällig gewesen. Stattdessen kam ein modellbasierter Ansatz mit Hilfe der Java Architecture for XML Binding2 (JAXB) zum Einsatz, die ein „high level“-Framework für die XML-Verarbeitung darstellt. Aus dem XML-Schema konnten mit dem sog. JAXB Schema Compiler Klassen erzeugt werden, welche die einzelnen Elemente in der Struktur des Schemas widerspiegeln. Beim Laden (Unmarshalling) des XML-Dokuments wird ein Objekt-Baum erzeugt, über den ein direkter Zugriff auf dessen Elemente möglich ist.

7.6 Detailliertes Design des elatePortals

Die Beschreibung des detaillierten Designs des elatePortals erfolgt anhand seiner Schichten, wobei der Fokus wieder auf produktlinienspezifische Aspekte gerichtet ist.

7.6.1 Präsentationsschicht

Die oberste Schicht des elatePortals besteht derzeit aus 41 Portlets, fünf Servlets sowie der Web-Service-Schnittstelle3, welche gegen die elatePortal-API implementiert sind. Der sog. Portlet Deployment Descriptor, welcher alle Portlets des elatePortals definiert, ist in Anhang A.3, Abbildung 53 dargestellt.

Variabilität in der Präsentationsschicht selbst kommt nur indirekt mittels des Variations-punkts optional Portlet Applications vor, durch den je nach Konfiguration weitere Portlets in der Portal-Oberfläche zur Verfügung stehen.

1 http://java.sun.com/webservices/jaxp/ 2 http://java.sun.com/webservices/jaxb/ 3 die auch wieder ein Servlet darstellt

Domain Realisation

77

7.6.2 elatePortal-API

Die API besteht aus Interfaces und einigen Exceptions. Sie soll an dieser Stelle nicht weiter erläutert werden, da sie, entsprechend den Erläuterungen zur Stabilität von Interfaces (siehe Kapitel 7.2.3), keine Variabilität enthält.

7.6.3 Geschäftslogik

An dieser Stelle wird das Beispiel zur Benutzer-Registrierung aus dem Domain Requirements Engineering (Kapitel 5.7.2, Abbildung 30) noch einmal aufgegriffen. In Abbildung 43 ist das detaillierte dynamische Design der Komponente UserRegistrati-onManager in Form eines Sequenz-Diagramms dargestellt.

UserRegistrationManagerImpl CourseRegistrationHandlerUserRegistrationPortlet

doAddSubmittedUserToPendingUsers()

preCheckUserInput()

preCheckUserInput()

preCheckUserInput()

MailManagerImpl

sendMail()

URValidationAction

ActivationLinkClicked

doValidateAndInvoke()

MailContext

WhiteListRegistrationHandler

MailContext

AdminApprovalRegistrationHandler

MailContext

Activation Mail

invoke()

invoke()

invoke()

VP

RegistrationHandler

Course(Key / TAN)

V

White List

V

Admin Approval

V

Abbildung 43 Sequenz-Diagramm: Variabilität in der Benutzer-Registrierung

Der UserRegistrationManager lässt in einer ersten Phase die Benutzereingaben durch die UserRegistrationHandler prüfen und in einer zweiten, nach der Mail-Validierung, die eigentliche Registrierung ausführen. Welche UserRegistrationHand-ler konkret verwendet werden, ist in der Spring-Konfiguration angegeben.

7.6.4 DAO-Schicht

Wie in der API sind in dieser Schicht nur Interfaces ohne Variabilität enthalten. Als Beispiel ist in Abbildung 44 die TaskManagerDAO dargestellt, die insbesondere von der für das elatePortal implementierten TaskFactory-Komponente des Aufgaben-Frameworks verwendet wird (Variationspunkt Persistence By, Kapitel 6.6.2).

Domain Realisation

78

«Java Interface»

getTaskManager ( ) : voidgetTaskManagerByCourseId ( id : String ) : TaskManagerstoreTaskMana ger ( tm : TaskManager ) : voiddeleteTaskMana ger ( tm : TaskManager ) : voidgetTaskCategoriesByCourseId ( id : String ) : voidgetTaskCategory ( id : long ) : TaskCategorystoreTaskCate gory ( tc : TaskCategory ) : voiddeleteTaskCate gory ( tc : TaskCategory ) : voidgetTasks ( ) : voidgetTasksByCourseId ( id : String ) : voidgetTask ( id : long ) : TaskstoreTask ( t : Task ) : voiddeleteTask ( t : Task ) : void

Abbildung 44 Beispiel: Data Access Object

7.6.5 Implementierung der DAO-Schicht

Die Implementierung der DAO-Interfaces aus der darüberliegenden Schicht mit Hilfe des objektrelationalen Mappers Apache OJB erfolgte in drei Schritten:

• Erstellung eines datenbankunabhängigen relationalen Schemas

• Generierung von Entity-Klassen, die auf Datensätze gemappt werden

• Implementierung der DAOs gegen die generierten Entity-Klassen und die OJB API1, wobei hier die bereits erwähnten Templates von Spring (siehe Kapitel 6.4) zum Einsatz kamen, die den Quellcode noch einmal vereinfachten

Damit sind die DAOs noch nicht einsetzbar. Es muss zusätzlich die Generierung der Mapping-Konfiguration für OJB und eines DDL-Skripts, das spezifisch für die verwendete Datenbank ist, erfolgen. Mit diesem Mechanismus wird der im Domain Design eingeführte (und bereits kritisch betrachtete) Variationspunkt Database realisiert.

Interessant bei der Umsetzung der erläuterten Vorgehensweise war, dass das verwendete Open-Source-Tool Druid2 mit einigen Anpassungen die Datenmodellierung sowie alle genannten Generierungsaufgaben übernehmen konnte. Ein E/R-Diagramm das Datenbank-schemas ist in Anhang A.3, Abbildung 54 dargestellt.

Ein weiterer wichtiger Punkt war die Sicherstellung von Transaktionssicherheit (vgl. z.B. [HR01]) beim Datenbankzugriff, was durch die Verwendung von Spring-AOP rein deklarativ erfolgen konnte. Ohne an dieser Stelle auf die Details einzugehen, konnten Aspekte definiert werden, welche bei Vorhandensein einer bestimmten Java-Annotation (@Transactional) die aufgerufene Methode (mit einem sog. Around Advice [WB05, Kapitel 3]) in eine Transaktion einbettet. Das bedeutet konkret den Start einer Transaktion beim Aufruf und ein Commit beim Verlassen der Methode. Diese Vorgehensweise war für die Implementierung der Komponenten und DAOs völlig transparent.

Weitere Vorteile ergaben sich für die Performance durch Unterstützung des sog. Lazy Loadings. Durch Fremdschlüsselbeziehungen zwischen Tabellen enthalten materialisierte Objekte oft Referenzen, die zu entsprechenden weiteren Datensätzen verzweigen. Damit bei einer entsprechenden Datenbankanfrage nicht die vollständigen Objektbäume

1 OJB implementiert neben der eigenen Persistence Broker API auch die Spezifikationen JDO und ODMG 3.0. 2 http://druid.sourceforge.net

Domain Realisation

79

materialisiert werden müssen, bietet OJB dynamische Proxies, welche erst bei einer expliziten Verwendung der Objekte weitere Materialisierungen durchführen.

7.7 Detailliertes Design des Prüfungsservers

Auf den Prüfungsserver wird in diesem Kapitel nicht näher eingegangen. Durch die Verwendung von Appfuse (siehe Kapitel 6.8) konnte er innerhalb einer Woche implemen-tiert werden. In der vorkonfigurierten Appfuse-Distribution ist bereits viel Funktionalität vorhanden gewesen, welche direkt einsetzbar war. Darüber hinaus konnten viele Anpassungen durch Austausch vorhandener Spring-Komponenten vorgenommen werden.

7.8 Bindung von Variabilität

Im späteren Application Realisation müssen konkrete Varianten an Variationspunkte gebunden werden. Die Bindung kann mit unterschiedlichen Mechanismen sowie zu verschiedenen Zeitpunkten erfolgen. Aufgrund der Forderung nach hoher Flexibilität kommen, mit Ausnahme von modellbasierten Ansätzen, häufig Mechanismen zur späten Bindung von Variabilität zum Einsatz. Im Folgenden werden die im SPL-Framework unterschiedenen Bindungszeitpunkte mit möglichen sowie den im elatePortal-Projekt verwendeten Mechanismen erläutert.

7.8.1 Vor der Kompilierung

Die Bindung von Variabilität vor der Kompilierung setzt eine Generierung oder Modifizierung von Quelltexten voraus, wofür Techniken bzw. Ansätze wie bspw. GSE oder MDE zum Einsatz kommen (vgl. Kapitel 2.3).

Auch Aspektorientierte Programmierung kann zur Bindung von Variabilität genutzt werden, wenn diese in Querschnittsbelangen auftritt. Der Zeitpunkt des Einwebens von Querschnitts-Code liegt jedoch nicht bei jedem AOP-Framework vor dem Kompilieren. Häufig wird es auch erst danach (AspectJ) oder zur Laufzeit (Spring-AOP) durchgeführt.

Obwohl im elatePortal-Projekt sowohl Code-Generatoren als auch AOP verwendet wurden, betrafen sie nicht direkt die Bindung von Variabilität.

7.8.2 Während der Kompilierung

Während der Kompilierung ist eine Bindung von Variabilität auch durch Verwendung eines Pre-Compilers möglich. Die Realisierung von Variationspunkten erfolgt mit Makros, die beim Kompilieren mit konkreten Varianten aufgelöst und regulär übersetzt werden. Darüber hinaus kann in C/C++ mit dem IFDEF-Statement eine bedingte Kompilierung stattfinden.

Die Verwendung dieses Ansatzes ist jedoch durch die Einführung zusätzlicher Komplexität und möglicher Fehlerquellen nicht zu empfehlen. Außerdem haben Pre-Compiler in modernen Programmiersprachen durch neuere Konzepte (u.a. Dynamisches Binden und Polymorphie) an Bedeutung verloren und werden bspw. in Java und C# nur noch durch zusätzliche Tools unterstützt.

Domain Realisation

80

7.8.3 Während des Build-Prozesses

Dieser Bindungszeitpunkt ist im SPL-Framework mit „At Link Time“ bezeichnet worden und beschreibt die Verwendung von Makefiles zur Kompilierung und zum anschließenden Linken von Object-Code. Das Make-Tool ist zwar noch in bestimmten Bereichen, wie bspw. bei Embedded Systems mit C/C++ von Bedeutung, wurde aber in höheren Programmierumgebungen von modernen Build-Tools abgelöst. An dieser Stelle wird deshalb von einer Bindung während des Build-Prozesses gesprochen, dessen Realisierung bereits erläutert worden ist.

7.8.4 Während der Anwendungs-Initialisierung

Während des Starts der Applikation erfolgt das Einlesen von Konfigurationsdateien, mit denen die zur Laufzeit gültigen Komponenten und Artefakte geladen werden. Dieser Mechanismus wird vom Spring-Framework realisiert.

In Bezug auf das Beispiel der Benutzer-Registrierung zeigt Abbildung 45 den entspre-chenden Ausschnitt für den UserRegistrationManager, aus dem erkennbar ist, dass in dieser Version nur der CourseRegistrationHandler durchlaufen wird. Spring übergibt bei der Instanziierung der Komponente eine Liste mit Referenzen auf Registra-tionHandler als zweites Constructor-Argument (sog. Constructor Injection). Das erste stellt einen Konfigurationsparameter dar und die letzten beiden sind Abhängigkeiten zu benötigten Komponenten. Variabilität wird also innerhalb der Komponente realisiert.

<bean id="UserRegistrationManager" class="de.elatePortal.components.userregistration.UserRegistrationManagerImpl"> <constructor-arg index="0"> <value>${elatePortal.repository.path}/system/UserRegistration.xml</value> </constructor-arg> <constructor-arg index="1"> <list> <ref bean="CourseRegistrationHandler"/> </list> </constructor-arg> <constructor-arg index="2"> <ref bean="PendingRegistrationDAO"/> </constructor-arg> <constructor-arg index="3"> <ref bean="MailManager"/> </constructor-arg> </bean>

Abbildung 45 Komponenten-Konfiguration in Spring

7.8.5 Während der Laufzeit

Dieser Mechanismus flexibilisiert den vorhergehenden in dem Sinne, dass Komponenten bzw. Software-Artefakte zur Laufzeit geladen und ausgeführt werden können. Diese Variante wird oft als extrem spätes Binden bezeichnet.

Alle Application- und Portal-Server realisieren diesen Mechanismus als integralen Bestandteil, indem jederzeit Web- bzw. Portletapplikationen geladen und ausgeführt werden können.

Domain Realisation

81

7.9 Auswertung

Dieses Kapitel erläuterte das detaillierte Design von Bestandteilen des elatePortal-Projekts. Nach theoretischen Betrachtungen bezüglich Vorgehensweise und Besonderheiten der zu erstellenden Artefakte, ging der zweite Teil des Kapitels auf das Build-Management sowie die Verfeinerungen der Referenzarchitektur anhand des Aufgaben-Frameworks und des elatePortals ein. Außerdem wurden in der Praxis auftretende Probleme und Lösungen erläutert.

Das SPL-Framework musste im Domain Realisation mehr als in den vorhergehenden Teilprozessen maßgeschneidert werden, da es in diesem Bereich sehr allgemein bleibt und sich hauptsächlich auf Variabilitätsaspekte konzentriert.

Einen großen Vorteil bezüglich Portabilität und Flexibilität der Komponenten stellte das IoC-Prinzip des Spring-Containers dar. In der neueren Version 2.0 des Spring-Frameworks ist außerdem die Injektion von Abhängigkeiten in Objekte möglich, die nicht vom Container, sondern durch den new-Operator erzeugt werden. Dazu nutzt Spring 2.0 wiederum AspectJ.

7.9.1 Build- und Deployment-Management

Die korrekte Umsetzung von Build- und Deployment-Prozessen stellt einen nicht zu unterschätzenden Aufwand dar. Beide besitzen eine zentrale Bedeutung für das Application Engineering sowie auch für Qualitätssicherungsmaßnahmen wie das Testen. Da das SPL-Framework das Build-Management nicht abdeckt, wurden in der Fallstudie Best-Practices aus der Einzelsystementwicklung an die Anforderungen von Produktlinien angepasst. Diese konnten effizient mit dem Build-Tool Maven realisiert werden, wobei sich insbesondere die Verwaltung von Abhängigkeiten mit Versionierung als hilfreich herausstellte.

7.9.2 Variabilität

Die Einführung von Variabilität in das detaillierte Design hatte seine Grenzen, was am Beispiel des Variationspunktes Complex SubTask Types (siehe Architektur des Aufgaben-Frameworks, Kapitel 6.6) folgendermaßen erläutert werden kann: so müsste konsequenterweise neben Traceability-Links zu den implementierenden Klassen auch Variabilität in das XML-Schema der Aufgaben-Definitionen eingeführt werden. Entsprechend würde der JAXB Schema Compiler je nach Konfiguration auch weniger Code generieren. Obwohl das praktisch umsetzbar ist (z.B. durch Aufteilung des Schemas über mehrere Dateien), rechtfertigt der geringe Nutzen nicht den nötigen Aufwand, sodass derzeit noch eine XML-Schema-Datei für alle Aufgabentypen existiert.

Die Verwendung des Spring-Frameworks stellt für die Bindung der Variabilität einen großen Vorteil gegenüber schwergewichtigen Ansätzen dar, wie bereits im Domain Design erläutert. Da auch Jetspeed das Spring-Framework verwendet und bestimmte Jetspeed-Komponenten gegen eigene Implementierungen ausgetauscht werden mussten, konnte dies auf einfache Weise im Deployment-Prozess realisiert werden. Die neuen Komponenten wurden als JAR-Archiv in den Jetspeed-Kontext kopiert und Spring-Konfigurationsdateien durch eigene überschrieben.

Domain Realisation

82

Besonders hervorzuheben ist die Eignung von Portlets zur Einführung von Variabilität in der Oberfläche, was durch die höhere Abstraktionsebene von Portalen gegenüber normalen (auf Servlets basierenden) Webapplikationen möglich ist. Portlets abstrahieren aufgrund ihres Ansatzes und der Einbettung in Portal-Seiten von verschiedenen Spezifika, an die Servlets gebunden sind. Außerdem sind Webapplikationen oft sehr monolithisch, d.h. Seiten sind eng miteinander verzahnt, was die technische Umsetzung von Variabilität in der Oberfläche verhindert. In der Fallstudie wurden Traceability-Links vom orthogonalen Variabilitätsmodell zu Portlet-Applikationen definiert. Entsprechend sind aber auch feingranularere Links zu einzelnen Portlets möglich, die direkt im Deployment Descriptor (portlet.xml, siehe Anhang A.3, Abbildung 53) adressiert werden können.

Verifikation und Validierung

83

8 Verifikation und Validierung

Dieses Kapitel erläutert die Vorgehensweise bzgl. der Verifikation und Validierung der Plattform. Es orientiert sich einerseits am Domain Testing-Teilprozess des SPL-Frameworks, das die Erstellung eines umfassenden Testprozesses für die Plattform verfolgt und zum anderen an statischen Analysemethoden, die nicht Bestandteil des Frameworks sind. Insbesondere wird das Tailoring des Domain Testings aus dem SPL-Framework für das elatePortal-Projekt beschrieben.

Als Verifikation und Validierung (V&V) wird im Allgemeinen die Prüfung von Software zur Sicherstellung ihrer korrekten und angemessenen Funktionsweise bezeichnet [So06, Kapitel 22]. Trotz unterschiedlicher Bedeutung werden beide Begriffe häufig synonym verwendet. Boehm [Bo79] lieferte folgende Charakterisierung:

• „Validation: Are we building the right product?“

• „Verification: Are we building the product right?“

Verifikation prüft die entwickelten Software-Artefakte gegen ihre Spezifikation, während Validierung darüber hinausgeht und untersucht, ob das System auch die impliziten Anforderungen von Kunden bzw. Nutzern erfüllt. Letzteres sind Anforderungen, die in der Regel als selbstverständlich angenommen werden. Sie können durch die Frage, ob ein System in sinnvoller Weise seinen Zweck erfüllt, charakterisiert werden.

Im Rahmen von V&V existieren zwei unterschiedliche Ansätze [So06, Kapitel 22]:

• Inspektionstechniken und Peer-Reviews überprüfen jegliche Art von Artefakten (nicht nur Software) durch statische Analyse.

• Testen als eine dynamische Technik für V&V beinhaltet die Ausführung von Software-Artefakten mit Testdaten.

Obwohl Testen den meistverwendeten Ansatz darstellt, ist eine Kombination mit Inspektionstechniken sinnvoll. In der Fallstudie sind beide Ansätze verfolgt worden.

8.1 Inspektionstechniken

Zu Inspektionstechniken gehören z.B. Walkthroughs, automatische Analysemethoden und verschiedene formale Ansätze [So06]. Letztere basieren häufig auf einer formalen Architekturbeschreibung (siehe Kapitel 6.3.2). Einen der umfassendsten Ansätze stellt Cleanroom Software Development [PTL99] dar, das eine hundertprozentige Fehlerfreiheit als Zielsetzung hat. Der zusätzliche Aufwand ist aber nur bei extrem fehlerkritischen Systemen gerechtfertigt.

Inspektionstechniken für Produktlinien sind nicht Bestandteil des SPL-Frameworks. Nach [PBL05, Kapitel 2] existieren noch keine Erfahrungsberichte bezüglich notwendiger Anpassungen, die gegenüber Einzelsystemen notwendig sind.

Aus Sicht der Fallstudie war jedoch die Durchführung einer statischen Analyse sinnvoll, da der Quelltext nicht von Bindungsmechanismen beeinflusst worden ist (Verwendung später Bindung, vgl. Kapitel 7.8). Konkret kamen Tools zur automatisierten Inspektion zum


84

Einsatz, die ohne Einschränkungen gegenüber der Einzelsystementwicklung verwendet werden konnten. Eine explizite manuelle Inspektion fand nicht statt.

8.2 Domain Testing

Das Domain Testing nimmt eine zentrale Rolle im SPL-Framework ein. Testaspekte müssen bereits zu Beginn des Domain Engineering betrachtet werden um die regressive Testbarkeit von Architekturen und Komponenten zu gewährleisten.

Charakterisiert ist Testen durch die Ausführung von Software-Artefakten und das Aufdecken von Fehlern durch eine Laufzeitanalyse. Prinzipbedingt ist dadurch Testen im Einsatz beschränkt:

„Testing can only show the presence of errors, not their absence.“ [Di72]

8.2.1 Test-Ebenen

Beim Testen wird zwischen verschiedenen Granularitäts-Ebenen unterschieden, auf denen getestet werden kann [SL03, PBL05]. Für Produktlinien (und auch die meisten Einzelsys-teme) sind die folgenden Ebenen relevant:

• Unit-Tests befassen sich mit dem Prüfen von Komponenten

• Integrations-Tests untersuchen die Interaktionen zwischen Komponenten im Sinne der Referenzarchitektur

• System-Tests validieren das Gesamtsystem gegen seine Spezifikation, d.h. Domain-Requirements und implizite Anforderungen

Das Hauptproblem im Domain Testing ist das Fehlen von applikationsspezifischen Varianten, wodurch das Testen komplexer wird, da einige Fehler nur durch bestimmte Interaktionen in Erscheinung treten können.

8.2.2 Test-Strategien

Das Vorhandensein von Variabilität und das Fehlen vollständiger Applikationen erfordert Teststrategien, die sich von der Einzelsystementwicklung unterscheiden. Anhang A.4 enthält eine Evaluation von fünf Test-Strategien für Produktlinien. Das SPL-Framework favorisiert die folgenden zwei Strategien:

• Die Sample Application Strategy (SAS) ermöglicht ein frühzeitiges Testen durch das Zusammenstellen von repräsentativen Muster-Applikationen. Mit der SAS ist das Application Testing keinesfalls überflüssig, da nur eine geringe Auswahl späte-rer Applikationen getestet wird. In jedem Fall werden aber die gemeinsamen Arte-fakte der Produktlinie sowie die Bindungsmechanismen an Variationspunkten veri-fiziert.

• Die Commonality and Reuse Strategy (CRS) verteilt das Testen gleichermaßen auf Domain und Application Testing durch das Erzeugen wiederverwendbarer Test-Artefakte. Im Domain Testing werden demnach hauptsächlich Domain-Artefakte getestet, die zur Gemeinsamkeit der Produktlinie gehören, während gleichzeitig Tests vorbereitet werden, die das Testen von variablen Artefakten im Application


85

Testing ermöglichen. Das impliziert die Verwendung von Variabilität in Test-Artefakten selbst. CRS ist komplexer als SAS, ermöglicht aber durch die Einfüh-rung von Variabilität in den Test-Prozess einen höheren Wiederverwendungsgrad.

Um Synergieeffekte beider Strategien zu nutzen, kann auch eine Kombination stattfinden. Dabei ermöglicht SAS zum einen die frühe Verifizierung und CRS zum anderen die Wiederverwendung von Test-Artefakten.

In der Fallstudie wurde SAS verfolgt, da die Einführung von Variabilität in Test-Artefakten mit CRS für das elatePortal-Projekt zu komplex war und kein vorhandenes Test-Framework die dazu notwendige Funktionalität bereitstellt.

8.3 Automatische statische Analyse

Die Anwendung von Inspektionstechniken, welche Quellcode ohne deren Ausführung analysieren, hat verschiedene Vorteile gegenüber der alleinigen Verwendung von Tests:

• Eine Überprüfung unvollständiger Software-Artefakte ist möglich, insbesondere solcher, die mit Variabilität versehen sind.

• Es können allgemeine Qualitäts-Attribute des Quellcodes ermittelt werden, um ihn zielgerichtet zu optimieren.

• Im Testen aufgedeckte Fehler können wiederum andere maskieren, die unentdeckt bleiben. Statische Analyse erhöht die Wahrscheinlichkeit zur Aufdeckung solcher Fehler.

In bestimmten Umgebungen können Inspektionen effizienter als Tests sein und darüber hinaus eine größere Anzahl an Fehlern aufdecken [So06, Kapitel 22]. Dies gilt besonders für Systeme, die in älteren Sprachen wie C/C++ implementiert worden sind. Zum Beispiel konnten sich durch Zeigerarithmetik und die schwächere Typisierung Fehler im Quellcode einschleichen, die in moderneren Sprachen nicht mehr möglich sind. Enstprechend sind Tools zur automatisierten Analyse für Java zwar verfügbar, aber nicht sehr weit verbreitet. Zu ihnen gehören z.B. JLint1, PMD2, das SABER-Projekt3 oder das im Folgenden betrachtete FindBugs [HP04]. Für einen Vergleich der Tools sei auf [RAF04] verwiesen.

8.3.1 Nebenläufigkeits-Fehler

Neben der Überprüfung von Quellcode-Richtlinien und -Konventionen ist der Fokus von Tools zur statischen Analyse häufig auf die Überprüfung von Fehlern in nebenläufigen Systemen gerichtet. Obwohl Threads ein Hauptbestandteil der Java-Sprache sind, finden sich in vielen Systemen oft Fehler bzgl. der korrekten Programmierung von nebenläufigen Codeabschnitten. Sie lassen sich in der Regel auf ein falsches Verständnis nebenläufiger Konzepte zurückführen [HP04]. Darüber hinaus sind die Fehler meist nicht durch einfache Testfälle reproduzierbar, da sie nur sporadisch bzw. unter hoher Last auftreten.

1 http://jlint.sourceforge.net 2 http://pmd.sourceforge.net 3 http://www-128.ibm.com/developerworks/websphere/downloads/j2ee_code_validation.html


86

Im elatePortal-Projekt existieren aufgrund der Natur von Web-/Portalapplikationen viele nebenläufige Quelltext-Abschnitte, die korrekt synchronisiert sein müssen. Besonders wichtig war dies bei der Implementierung des Aufgaben-Frameworks, da während einer Prüfung hohe Anforderungen an die Stabilität und Datenkonsistenz zu gewährleisten sind.

Nach Hovemeyer und Pugh [HP04] lassen sich viele Nebenläufigkeits-Fehler durch einfache Analyse-Techniken finden. Das Tool FindBugs stellt einen umfangreichen Analysator dar, der sich besonders auf Nebenläufigkeit spezialisiert hat. Es sucht nach Instanzen bestimmter Fehler-Muster, die in der Regel auf eine nicht korrekte Implementie-rung hinweisen. Das Tool ist komfortabel über ein Eclipse-Plugin anwendbar.

Eine verbreitete Annahme ist, dass Synchronisierung die Performance von Systemen einschränkt und deswegen so oft wie möglich vermieden werden sollte. Jedoch konnte in neueren Java-Versionen der Overhead bei Synchronisierungen deutlich vermindert werden [KKO02]. Ein weiteres Problem stellt das Speichermodell von Java dar, welches nicht sequentiell konsistent ist. Das heißt, dass optimierende Java-Compiler (Just-In-Time-Compiler) die Ausführungsreihenfolge von Speicherzugriffen ändern können. Häufig erfolgt dies durch das sog. Inlining von Methoden. Dadurch können Fehler auftreten, die nach der Ausführungsreihenfolge im Quelltext nicht existieren sollten [Pu00].

In der Fallstudie fand FindBugs Nebenläufigkeits-Fehler, die auf eine inkonsistente Synchronisierung von Objekt-Feldern zurückzuführen waren. In der Synchronisierung der Persistenzfunktionen des Aufgaben-Frameworks im Prüfungsserver (siehe Kapitel 6.8), der keine Datenbank verwendet, wurden keine Fehler gefunden. Jedoch zeigten sich die Grenzen des Tools bei Fehlern, die nicht durch Muster innerhalb einer Klasse erkennbar waren. So existierten Fehler in einem Teil der elatePortal-API, der für Einschreibungen innerhalb von Lehrveranstaltungen zuständig ist. Die Fehler bestanden darin, dass atomare Logik in Nicht-Singleton-Objekten ausgeführt worden ist. Zur Beseitigung reichte keine einfache Synchronisierung, sondern es musste das Design der API geändert werden.

8.3.2 Qualitätssicherung von Test-Klassen

Sinnvoll ist auch die Verwendung einer statischen Analyse zur Überprüfung von Testklassen, um deren Qualität und Code-Abdeckung zu verbessern. Einen interessanten Ansatz verfolgt das Tool Jester1, welches Quelltext mutiert und anhand des Fehlschlagens von Tests auf die Code-Abdeckung schließt. Innerhalb der Fallstudie erwies sich die regressive Anwendung des Tools jedoch als zu inperformant und umständlich.

Ferner besitzt auch FindBugs Muster, die Fehler in Unit-Tests aufdecken können. Es überprüft verschiedene Konventionen, die seitens des JUnit-Frameworks vorgegeben sind, wie bspw. das Vorhandensein von Test-Methoden oder die Implementierung der Initialisierung bzw. De-Initialisierung der Test-Klasse.

8.4 Unit-Tests

Die Erstellung von Unit-Tests orientierte sich an Richtlinien des agilen Test-Driven-Developments (TDD) [Be02, LH06], die mit der Vorgehensweise des Domain Testing im

1 http://jester.sourceforge.net


87

SPL-Framework konform waren. TDD forciert die Erstellung von Testfällen vor der Implementierung von Komponenten und stellte eine wichtige Voraussetzung für frühzeitiges Feedback dar (siehe Feedback-Schleifen, Kapitel 4.1). Ersteres konnte zwar in der Fallstudie nicht immer eingehalten werden, stellte jedoch eine sinnvolle Vorgehens-weise dar, mit der sich die Implementierung stärker nach der Spezifikation der Komponen-ten (Interfaces bzw. ihre Inline-Dokumentation) richtet. Weiterhin ist TDD auf die Verwendung eines Test-Frameworks für Regressionstests ausgerichtet.

Als Test-Framework kam das im Java-Umfeld weit verbreitete JUnit1 zum Einsatz. Positiven Einfluss auf die Testbarkeit der Komponenten hatte die Verwendung des Spring-Frameworks. POJOs können direkt in der Entwicklungsumgebung oder während des Build-Prozesses getestet werden. Es ist kein aufwendiges Deployment in einen Applicati-on-Server notwendig, wie es bei EJB der Fall gewesen wäre. Dazu hätte außerdem ein In-Container-Testing Framework, wie bspw. Cactus2, verwendet werden müssen.

Obwohl bei Einzelsystemen häufig Unit-Tests nur in Verbindung mit Integrations-Tests ausgeführt werden, ist im Produktlinienkontext die isolierte Überprüfung von Komponen-ten notwendig. Das trifft insb. auf Artefakte zu, die nicht Bestandteil der Plattform sind. Zur Einzelüberprüfung müssen benötigte, aber nicht vorhandene Komponenten durch Dummies oder Mocks ersetzt werden.

8.5 Integrations-Tests

Die Durchführung von Integrations-Tests zur Verifikation der Interaktionen verschiedener Komponenten setzte die Verwendung eines Spring-Containers voraus. Er muss, wie zur Laufzeit, die Komposition der Komponenten durchführen. Speziell für Tests bietet das Spring-Framework Unterstützung in Form eines leichtgewichtigen Containers, der die Komposition durchführen kann und in einer Entwicklungsumgebung verwendbar ist. Gegenüber EJB entfiel dadurch auch bei Integrations-Tests das Deployment in einen Application-Server.

Die Komposition der Komponenten erfolgte nach der SAS-Strategie, sodass die XML-Konfigurationen der konkreten Applikationen direkt verwendet werden konnten. Da ferner die Initialisierungszeit aller Komponenten nicht vernachlässigbar ist, bietet Spring auch Caching-Funktionalitäten für diesen Zweck an. Dadurch wurde die Ausführung von Regressionstests beschleunigt.

Weiterhin existierten bei der Konzeption von Integrationstests in der Fallstudie die folgenden Problemstellungen:

• Komponenten sollten auch getestet werden können, wenn benötigte Komponenten noch nicht implementiert, ihre Interfaces aber bereits spezifiziert waren.

• Reguläre Testfälle ermöglichen nur die Verifizierung des Zustands von Komponen-ten, nachdem bestimmte Methoden mit Testdaten ausgeführt wurden. Eine Verifi-zierung des Verhaltens ist mit ihnen nicht möglich.

1 http://www.junit.org 2 http://jakarta.apache.org/cactus


88

• Die meisten Komponenten benötigten zur Ausführung ihrer Funktionalität Daten-bank-Zugriff.

8.5.1 Dummies und Mocks

Dummies und Mocks (vgl. [LH06]) implementieren Komponenten-Interfaces, die von den getesteten Komponenten benötigt werden. Mocks ermöglichen darüber hinaus eine spezielle Form des Testens: das sog. Endo Testing [MFC00], mit dem auch das Verhalten von Komponenten verifiziert werden kann. Normale Unit-Tests prüfen nur den Zustand.

Dummies stellen eine Implementierung von Interfaces dar, deren Methoden bestimmte Rückgabewerte besitzen, die im Dummy definiert worden sind. Um das richtige Aufrufverhalten des Dummies zu testen, kann er zu einem Mock erweitert werden. Dieser erwartet bestimmte Methodenaufrufe in einer definierten Reihenfolge. Wird diese nicht eingehalten, schlägt der Test fehl.

Da die manuelle Erstellung von Mock-Objekten in der Regel sehr zeitaufwendig ist, kam in der Fallstudie das Mock-Framework EasyMock1 zum Einsatz. Es verwendet dynamische Proxies von Java, um Interfaces zur Laufzeit zu implementieren und ermöglicht das Setzen des Zustands der Instanz. Dadurch war es auch für reine Dummies verwendbar und erübrigte die manuelle Erstellung einer Dummy-Klasse.

Außerdem enthält Spring Mocks für die Servlet-API, mit der Controller-Klassen aus der Präsentationsschicht getestet werden können. Das stellt wiederum eine Alternative zum In-Container-Testing dar.

8.5.2 Datenbank-Zugriff

Um Komponenten testen zu können, die einen Zugriff auf die Datenbank benötigen, existieren folgenden zwei Möglichkeiten: Zum einen können die DAOs durch Dummies ersetzt werden, die selbst Entitäts-Objekte füllen und zurückgeben, zum anderen ist die Erstellung einer Test-Datenbank möglich.

In der Regel waren die DAO-Implementierungen durch die Verwendung von OJB sehr einfach geschrieben und mussten nicht getestet werden. Sie konnten durch Dummies mit dem EasyMock-Framework ersetzt werden. Zum Testen komplexerer DAOs (z.B. für das Forum) war eine Test-Datenbank nötig. Sie enthielt eine Kopie der Produktivdatenbank einer der drei konkreten Applikationen. Da in der Entwicklungsumgebung getestet wurde, konnte nicht wie zur Laufzeit eine DataSource (und damit ein Connection-Pool) des Tomcat verwendet werden.

Spring bietet für Datenbank-Tests eine Super-Klasse (AbstractTransactionalData-SourceSpringContextTests) an, der eine DataSource-Bean übergeben werden kann. Eine Besonderheit dieser Klasse stellt die Einbettung von Datenbankzugriffen in Transaktionen dar, deren Schreibzugriffe bei Beendigung mit einem Rollback wieder rückgängig gemacht werden. Das erübrigt jeweils ein neues Erstellen der Datenbank mit Testdaten vor jeder Test-Ausführung.

1 http://www.easymock.org


89

8.6 System-Tests

Obwohl System-Tests in Grenzen auch im Domain Testing mit der SAS-Strategie durchgeführt werden könnten, sind sie für das Application Testing vorgesehen. Meist fehlen applikationsspezifische Artefakte, die nicht in der Plattform vorhanden sind (wenn Deltas zwischen Applikation und Plattform existieren). Aus diesem Grund sind weitergehende Betrachtungen zu System-Tests sowie zu den im elatePortal-Projekt durchgeführten Last- und Performancetests (Profiling, [Ho05]) in der vorliegenden Arbeit nicht enthalten.

Zusammenfassung

90

9 Zusammenfassung

Die vorliegende Arbeit verfolgte die Beantwortung von Fragestellungen der Softwarepro-duktlinien-Entwicklung auf zwei verschiedenen Abstraktionsebenen: einer theoretischen und einer darunterliegenden, praxisorientierten Ebene. Dazu betrachtete die Arbeit in Form einer Fallstudie die Entwicklung eines Open-Source-Projektes, dessen formaler Rahmen ein Produktlinien-Framework war.

Die Arbeit stellte den Produktlinien-Ansatz vor, ordnete ihn in das Software Engineering ein und charakterisierte den Forschungsstand, von dem derzeit ausgegangen werden kann. Der Hauptteil konzentrierte sich auf das Domain Engineering und erläuterte zu jedem Teilprozess zunächst die Theorie und anschließend die Umsetzung im konkreten Projekt, wofür das Produktlinien-Framework maßgeschneidert worden ist.

9.1 Produktlinien-Forschung

Im Rahmen der Arbeit konnten folgende Problemstellungen der Produktlinien-Entwicklung identifiziert werden, für die weitere Forschung notwendig ist.

Variabilität und Separation of Concerns sind zentrale Konzepte von Produktlinien. Mit dem orthogonalen Variabilitätsmodell (Kapitel 4.3) ist eine ausdrucksstarke und flexible Modellierung von Gemeinsamkeit und Variabilität der Produktlinie möglich. Außerdem wird die Konsistenz von Artefakten durch Traceability gesichert. Da es bereits orthogonal zu anderen Diagrammen ist, erfordert eine Erweiterung desselben die Einführung neuer Notationen. Eine abstraktere Betrachtung von Variabilität besteht möglicherweise in einer Kombination mit dem Hyperspace-Ansatz. In diesem könnte die Zerlegung der Plattform nach Variabilitätsaspekten eine eigene Dimension darstellen. Dadurch wäre wiederum eine nicht-invasive Erweiterung des Variabilitätsmodells möglich, wie bspw. die Abhängigkeit verschiedener Varianten von zusätzlichen Belangen (z.B. der Zeit). In Kombination mit vorhandenen Abbildungen des Hyperspace-Ansatzes auf Java und UML erscheinen weitere Untersuchungen in diese Richtung sinnvoll.

In [TC06, Bo02a] wird die Kombination agiler Software-Entwicklung mit Produktlinien bzw. allgemein mit phasenorientierten Methoden empfohlen. In der Fallstudie konnten die agilen Prinzipien nebenläufige Entwicklung, agile Dokumentation und Test Driven Development sinnvoll angewendet werden und waren mit der Vorgehensweise des SPL-Frameworks konform. Insbesondere kann auch die Erfassung von Anforderungen im Projekt als agil bezeichnet werden. Obwohl auf dem Gebiet erste Schritte gemacht wurden, existiert noch keine Methodik zur agilen Entwicklung von Produktlinien. Insbesondere sind Untersuchungen zur Auswirkung von Change Requests notwendig, welche über die ROI-zentrierten Betrachtungen von [Ca06] hinausgehen (vgl. Kapitel 3.5.2).

Als Qualitätssicherungsmaßnahmen fokussiert das verwendete SPL-Framework das Testen, da noch keine ausreichenden Erfahrungen mit Inspektionen im Produktlinien-Kontext existieren. In der Fallstudie kam erfolgreich eine Kombination von Testen und statischer Analyse zum Einsatz, die allerdings nicht explizit von Variabilitätsaspekten beeinflusst worden ist. In diesem Bereich sind weitere Untersuchungen notwendig.

Zusammenfassung

91

9.2 Tailoring und Praxis

Im elatePortal-Projekt konnte erfolgreich eine Plattform zur Unterstützung von Prüfungs-prozessen realisiert werden, deren Artefakte einen Gesamtumfang von derzeit ca. 65 kSLOC (Source Lines Of Code [Wh01]) aufweisen. Knapp die Hälfte entfällt auf generative Ansätze. Es ist anzumerken, dass der Aufwand zur Entwicklung und Etablierung der Plattform durch die verwendeten Technologien weitaus geringer ausfiel als zunächst vermutet.

Die Fallstudie hat gezeigt, wie das SPL-Framework auf die Anforderungen und die Umgebung des elatePortal-Projekts maßgeschneidert wurde. Außerdem sind für verschiedene Problemstellungen Lösungen aufgezeigt worden, die nicht Bestandteil des Frameworks waren. Dazu gehörte z.B. das Build- und Deployment-Management, welches für ein J2EE-Projekt dieser Größe mit vielen externen Abhängigkeiten zwingend notwendig ist. Hier zeigten sich die Wurzeln des Frameworks, die im Embedded-Systems-Bereich anzusiedeln sind.

Die im SPL-Framework definierte Vorgehensweise kann als adaptiv bezeichnet werden, die sich gut an unterschiedliche Rahmenbedingungen anpassen lässt. Als Kritikpunkt stellte sich die Praxistauglichkeit des orthogonalen Variabilitätsmodells heraus, für das derzeit geeignete Tools fehlen. Jedoch bildet es einen sehr konsistenten theoretischen Rahmen zur Modellierung von Variabilität.

Bei der Entwicklung des elatePortal-Projekts kam überwiegend Open-Source-Software zum Einsatz. Dabei erwies sich insbesondere die Verwendung von J2EE-Portaltechnologie als größter Enabler der Produktlinien-Entwicklung. Sie ermöglichte eine sehr flexible und entwicklungsfähige Architektur und brachte darüber hinaus Mechanismen zum extrem späten Binden komplexer Funktionalität mit. Außerdem setzen Portlets den Komponenten-gedanken bis an die Präsentationsschicht fort und ermöglichen dadurch eine einfache Umsetzung von Variabilität in der Oberfläche. Eine weitere wichtige technische Basis stellte das Komponenten-Framework Spring für die Business-Schicht dar, dessen zentrales Konzept der IoC-Container ist.

Basierend auf den Erkenntnissen und Lösungen der Fallstudie sind weitere Arbeiten möglich, die ein vollständiges Tailoring des SPL-Frameworks verfolgen und dabei auf J2EE-Portalapplikationen in Verbindung mit weiterer Open-Source-Software ausgerichtet sind.

9.3 Ausblick

In der Produktlinien-Entwicklung ist eine weitere Konsolidierung in Richtung modellba-sierter/generativer Vorgehensweisen zu erwarten, da sich deren Anwendung durch einen meist hohen initialen Aufwand eher für Produktlinien als für Einzelsysteme lohnt. Neben den auf Feature- und Goal-Modelle gerichteten Ansätzen sind Frameworks denkbar, die auch umfangreichere Requirements-Modelle unterstützen, wie bspw. mit Semantik hinterlegte textuelle Darstellungen. Derzeit kommt MDE größtenteils zur Umsetzung von

Zusammenfassung

92

Funktionalität zum Einsatz, die sich mit dem Akronym CRUD1 charakterisieren lässt, was auch auf die Anwendung im elatePortal-Projekt zutrifft.

Open-Source ist nicht mehr aus der Software-Landschaft wegzudenken und wird in Verbindung mit darauf zugeschnittenen Geschäftsmodellen einen noch höheren Stellenwert einnehmen. Insbesondere ermöglicht es bereits jetzt eine Lösung der Ressourcen-Probleme von kommerziellen Entwicklungen.

Neben dem Portal-Server Jetspeed-2 existieren weitere freie Portale, die eine Infrastruktur zur Integration von Web-Applikationen bereitstellen. Ein wichtiger Trend ist die Entwicklung hochinteraktiver Oberflächen mit der AJAX-Technologie, wie z.B. eines Desktops in Jetspeed-2, mit denen sich eine Konvergenz zwischen Web- und lokalen Applikationen abzeichnet. Bei den Komponenten-Frameworks kann besonders die Entwicklung hin zu leichtgewichtigen Konzepten beobachtet werden. Dabei stellt Spring nicht nur ein Framework, sondern auch eine Philosophie für J2EE-Systeme dar.

Die Ziele der weiteren Entwicklung des elatePortal-Projekts sind eine umfangreichere Unterstützung von Prüfungsprozessen durch weitere Aufgabentypen (Kapitel 2.4) und eine bessere Integration in bestehende (Hochschul-) Informationssysteme. Dazu gehört insbesondere die Nutzung gemeinsamer Autorisierungsschnittstellen, welche die Nutzung einer universitätsweiten Identität ermöglichen. Außerdem ist eine Erweiterung des Portals zur umfangreicheren Verwaltung von Lehrveranstaltungen geplant. Derzeit wird auch über weitergehende Sicherungsmaßnahmen der elektronischen Klausuren nachgedacht, die eine spätere Manipulation (seitens der Betreiber) von Eingabedaten durch kryptographische Prüfsummen einschränken. Eine noch höhere (Manipulations-) Sicherheit wäre nur durch die Verwendung asymmetrischer Verschlüsselung möglich, wobei der private Schlüssel lediglich dem Studierenden bekannt sein darf (bspw. durch Nutzung des Krypto-Prozessors auf Studentenausweisen). Das ist derzeit technisch leider noch zu aufwendig, wird aber in Zukunft bei stärkerem Einsatz elektronischer Prüfungen notwendig sein.

1 Create, Read, Update, Delete

Anhang

93

Anhang

A.1 Aufgaben-Framework: Implementierte Aufgabentypen

Die Autoren der dargestellten Aufgaben sind Prof. Dr. H.-W. Wollersheim (Abbildung 46, Abbildung 48, Abbildung 49), Dr. A. Frenzen (Abbildung 47) und Prof. Dr. H. Marx (Abbildung 50).

Abbildung 46 Multiple-Choice-Aufgabe (Mehrfachauswahl)

Abbildung 47 Multiple-Choice-Aufgabe (Einfachauswahl)

Abbildung 48 Lückentext-Aufgabe

Anhang

94

Abbildung 49 Zuordnungs-Aufgabe

Abbildung 50 Aufgabe Graphische Darstellung

Anhang

95

A.2 Orthogonales Variabilitätsmodell

ExcludesVP_VP

RequiresVP_VP

RequiresV_VP

ExcludesV_VP

RequiresV_V

ExcludesV_V

Variant PointConstaint

Dependency

Variation Point

ArtefactDependency

Optional Mandatory

Variation Point toVariant Constraint

Dependency

InternalVariation Point

ExternalVariation Point

VP ArtefactDependency

Variant ConstraintDependency

AlternativeChoice

minmax

{complete, disjoint} {complete, disjoint} {complete, disjoint}


0..*

0..*

constrains 0..*0..* constrains0..*

0..*

constrains

Variant

1..*

0..*

realised by

0..1

0..1

part of

2..*

VariabilityDependency

1..*1..*


0..*

0..*

represented by DevelopmentArtefact

Abbildung 51 Metamodell des orthogonalen Variabilitätsmodells [PBL05]

A.3 Detaillierte Design-Artefakte

Aufgrund des Umfangs wird an dieser Stelle auf die Online-Version im CVS-Repository verwiesen:

• elatePortal-Komponenten: http://elateportal.cvs.sourceforge.net/elateportal/elatePortal/elatePA/webapp/WEB-INF/conf/elatePortalSpring.xml?view=markup

• Komponenten der Aufgaben-Framework Referenz-Implementierung im elatePor-tal: http://elateportal.cvs.sourceforge.net/elateportal/elatePortal/elatePA/webapp/WEB-INF/conf/taskAPISpring.xml?view=markup

Abbildung 52 Komponenten-Konfiguration

Anhang

96

Auch an dieser Stelle wird auf das CVS-Repository verwiesen:

http://elateportal.cvs.sourceforge.net/elateportal/elatePortal/elatePA/webapp/WEB-INF/portlet.xml?view=markup

Abbildung 53 Portlet Application Deployment Descriptor

CourseParticipant

PK id bigint

FK course_ref Course(id) N login varchar-255 A enrollmentDate bigint

Template

PK pk bigint

N id varchar-255 N template blob N locale_string varchar-16

EventSubscription_Pref

PK id bigint

N pref_key varchar-255 A pref_value varchar-255 FK eventSubscription_ref EventSubscription(id)

EventSubscription

PK id bigint

N login varchar-255 N type varchar-255

NewsData

PK id bigint

FK course_ref Course(id)A creationDate bigintA lastModified bigintA text blobA idx bigint

TaskHandlingFlag

PK id bigint

N flag varchar-255 FK taskHandling_ref TaskHandling(id)

TaskHandlingStudentAnnotation

PK id bigint

N date bigint A text blob FK taskHandling_ref TaskHandling(id) N acknowledged BIT

CourseParticipantAdditionalInfo

PK id bigint

FK course_participants_additional_info_def_ref CourseParticipantsAdditionalInfoDef(id) A string_value varchar-255 A int_value INTEGER A boolean_value BIT N login varchar-255

CourseParticipantsAdditionalInfoDef

PK id bigint

N question varchar-255 FK course_ref Course(id) N type varchar-16 N required BIT N orderIndex INTEGER

CourseSubscriptionHintPage

PK id bigint

N pageNumber INTEGER N hint blob FK course_ref Course(id)

CHierarchyNode

PK id INTEGER

N name varchar-32 A title varchar-255 N level tinyint FK parent CHierarchyNode(id) N isCourse BIT

TaskCorrectorHistory

PK id bigint

FK taskHandling_ref TaskHandling(id) N correctorLogin varchar-255

TaskHandling

PK id bigint

N login varchar-255FK task_ref Task(id)N status varchar-32A points floatA annotation blobA correctorLogin varchar-255A content mediumblob

ComplexTaskDef

PK id INTEGER

N complexTaskFile varchar-255N showCorrectionToStudents BITN complexTaskDef mediumblob

UploadTaskDef

PK id INTEGER

A problem blob A problemResource varchar-255 A maxUploadFiles tinyint

Task

PK id bigint

FK taskCategory_ref TaskCategory(id) N title varchar-255 A shortDescription varchar-255 N type varchar-255 N stopped BIT A deadline bigintFK uploadTaskDef_ref UploadTaskDef(id)FK complexTaskDef_ref ComplexTaskDef(id)

TaskCategory

PK id bigint

N name varchar-255 A description blobFK taskManager_ref TaskManager(id)

TaskManager

PK id bigint

A description blobFK course_ref Course(id)

FileArea_File

PK id bigint

FK filearea_ref FileArea(id) N relativepath varchar-255 A title varchar-255 N read_access varchar-16

FileArea

PK id bigint

A description blob FK course_ref Course(id)

ForumThreadAnswer

PK id bigint

N answer blob FK forumthread_ref ForumThread(id) N author varchar-255 N postedTime bigint N login varchar-255

ForumThread

PK id bigint

N author varchar-255FK forum_ref Forum(id)N subject varchar-255N postedTime bigintN body blobA login varchar-255A closed BIT

Forum

PK id bigint

A description blobA title varchar-255FK course_ref Course(id)N active BITN view_access varchar-16N allow_richtext BIT

Course

PK id varchar-255

A shortDescription varchar-255A description blobN title varchar-255N active BITA courseKey varchar-255N enrollmentCancellable BITA enrollmentHint blobA maxEnrollment INTEGERN showFileAreaPage BITN showForumPage BITN showTasksPage BIT

Course_Tan

PK id bigint

N tanValue varchar-255 FK course_ref Course(id)

Subscription_SubscribedSubject

PK id bigint

FK subscription_itemdef_ref Subscription_ItemDef(id) N login varchar-255 N date bigint

Subscription_ItemDef

PK id bigint

FK subscription_ref Subscription(id) N maxEnrollment bigint A lastValidSubscriptionDate bigint N closed BIT A name varchar-255

Subscription_FieldDef

PK id bigint

A name varchar-255 FK subscription_ref Subscription(id)

Subscription_Field

PK id bigint

FK subscription_itemdef_ref Subscription_ItemDef(id) FK subscription_fielddef_ref Subscription_FieldDef(id) A field_value varchar-255

Subscription_AdditionalUserInfoDef

PK subscription_ref Subscription(id)

A description blob

Subscription_AdditionalUserInfo_FieldDef

PK id bigint

FK subscription_additionaluserinfodef_ref Subscription_AdditionalUserInfoDef(subscription_ref) N name varchar-255 N type varchar-255 N nullable BIT

Subscription_AdditionalUserInfo_Field

PK id bigint

FK subscription_subscribed_subject_ref Subscription_SubscribedSubject(id) FK subscription_additionaluserinfo_fielddef_ref Subscription_AdditionalUserInfo_FieldDef(id) A field_value blob

Subscription

PK id bigint

N type varchar-255 N title varchar-255 A short_description varchar-255 A description blob A cancellable BIT A changeable BIT N active BIT N hideInactivatedItems BIT A enrolled_users_visible BIT FK course_ref Course(id)

PendingPasswordChange

PK id bigint

N creationDate bigint N ip varchar-255 N login varchar-255 N password varchar-255

PendingRegistration

PK id bigint

N creationDate bigint N ip varchar-255 N login varchar-255 N firstname varchar-255 N name varchar-255 N email varchar-255 N password varchar-255 A courseKey varchar-255 A tan varchar-255

Abbildung 54 E/R-Diagramm: Datenbankschema elatePortal

Anhang

97

complexTaskDef

task definition (homework, exam etc.) that consists of several sub tasks

config

time

available time in minutes to solve the task,unbounded if left empty

tries

Number of possible tries to solve the task.Every new try results in a random aggregation of subtasks (and possibly answer combinations)

tasksPerPage

Number of tasks that are rendered per page, therefore implies the number of pages.

kindnessExtensionTime

Kindness extension in minutes. After expiration of the official processing time, the student can still edit his solution until this time expires.

title

description

startText

category

f1..Divide subtask blocks into categories.

Attributes: title - name of the category (opt.)PreserveOrderOfBlocks - soll die Reihenfolge der Blöcke erhalten bleiben oder zufällig festgelegt werden?MixAllSubTasks - damit werden alle Aufgaben aus allen Blöcken in zufälliger Reihenfolge angeordnet, überschreibt preserveOrderOfBlocks und preserveOrder der Aufgaben in Blöcken

f1..

mcTaskBlock

config

mc-config

f1..

mcSubTaskDef

problem

hint

displayedAnswers

correct

f1..

incorrect

f0..

choice mcSubTaskDef

f1..

clozeTaskBlock

config

cloze-config

f1..

clozeSubTaskDef

problem

hint

cloze

f0..

text

gap

choice clozeSubTaskDef

f1..

textTaskBlock

config

f1..

textSubTaskDef

problem

hint

correctionHint

choice textSubTaskDef

f1..

mappingTaskBlock

config

mapping-config

f1..

mappingSubTaskDef

problem

hint

concept

f1..

assignment

f1..

choice

paintTaskBlock

config

f1..

paintSubTaskDef

problem

images

mutableTemplateImage

immutableBackgroundImage

correctionTemplateImage

textualAnswertextFieldWidth

textFieldHeight

hint

colorChangeable

strokewidthChangeable

correctionHint

choice PaintSubTaskDef

f1.. Abbildung 55 XML-Schema: Aufgabenpool

Anhang

98

success

execute

success

success

success

success

success

success

success

success

success

success

error

success

doCorre...

success

success

/execute

/savePage

/execute.jsp

/error.jsp

/showSolution

/tutorCorrectionOverview

/saveStudentAnnotation

/showCorrectionToCorrector

/complexTaskStructure/statistics/complexTaskStructure.jsp

/ajaxSaveStudentAnnotation

/viewAllTasklets

/correction/viewAllTasklets.jsp

/ajaxResponse

/acknowledge

/commit

/committed.jsp

/NavigationHelp.jsp

/header.jsp

/footer.jsp

/showCorrection.jsp

/correction/tutorCorrectionOverview.jsp

/doCorrection

/saveCorrection

/assignTasklet

/correction/showCorrectionToCorrector.jsp

/correction/doCorrection.jsp

Abbildung 56 Aufgaben-Framework: Präsentations-Webapplikation

Anhang

99

A.4 Test-Strategien für Produktlinien

Tabelle 4 zeigt eine aus [PBL05] entnommene Beurteilung unterschiedlicher Strategien im Domain Testing bezüglich bestimmter Kriterien. Dabei bedeutet ein „+“ eine positive und „-“ eine negative Bewertung. Bei „0“ heben sich Vor- und Nachteile nahezu auf.

Die evaluierten Strategien sind im Einzelnen:

• Brute Force Strategy (BFS) testet alle möglichen Applikationen, die durch Kombi-nation von Variationspunkten mit Varianten entstehen können.

• Pure Application Strategy (PAS) testet nur vollständige Applikationen und ver-nachlässigt das Domain Testing.

• Sample Application Strategy (SAS) testet einige Musterapplikationen, die nach bestimmten Aspekten zusammengestellt werden.

• Commonality and Reuse Strategy (CRS) erstellt variable Test-Artefakte und befasst sich mit der Kombination von Domain und Application Testing.

• Combined SAS/CRS nutzt Synergieeffekte der beiden vorher genannten Strategien.

Die zur Bewertung herangezogenen Kriterien sind:

• Time to create bezeichnet den Aufwand, der zur Erstellung der relevanten Test-Artefakte notwendig ist.

• Absent variants bewertet die Fähigkeit der Strategie, mit Varianten umzugehen, die noch nicht zur Verfügung stehen (hauptsächlich Applikations-spezifische Varian-ten).

• Early validation kennzeichnet die zwischen Fertigstellung des zu testenden Arte-fakts und dem eigentlichen Test verstrichene Zeit.

• Learning effort ist der zusätzliche Aufwand bezüglich des Testens von Einzelappli-kationen, der im Produktlinienkontext notwendig ist.

• Overhead bezeichnet zusätzlichen Aufwand, der nicht unbedingt notwendig gewesen wäre um das gleiche Ziel zu erreichen.

Time to create

Absent variants

Early validation

Learning effort Overhead

BFS - - + 0 - PAS 0 + - + - SAS 0 + + + - CRS + + 0 - +

Combined SAS/CRS + + + 0 0

Tabelle 4 Strategie-Übersicht Domain Testing [PBL05]

Abbildungsverzeichnis

100


Abbildung 1 BAPO-Modell (nach [Li02])..................................................................... 6

Abbildung 2 elatePortal, Prüfungsserver und Aufgaben-Framework .......................... 10

Abbildung 3 Persönliche Oberfläche ........................................................................... 11

Abbildung 4 Anpassung der Oberfläche ...................................................................... 11

Abbildung 5 eMail-Benachrichtigungen...................................................................... 12

Abbildung 6 Veranstaltungs-interne Einschreibungen ................................................ 12

Abbildung 7 Veranstaltungs-Konfiguration................................................................. 13

Abbildung 8 Prüfungsserver......................................................................................... 14

Abbildung 9 Klausur-Oberfläche ................................................................................. 15

Abbildung 10 Graphik-Aufgabe im Aufgaben-Editor ................................................... 16

Abbildung 11 PRAISE-Referenzprozess [Es97]............................................................ 19

Abbildung 12 Steigerung Software-Wiederverwendbarkeit (erweiterte Version von [Li02]) ..................................................................................................... 20

Abbildung 13 Kostenvergleich Einführungsstrategien [Gr02] ...................................... 23

Abbildung 14 Der FAST-Prozess [We95] ..................................................................... 24

Abbildung 15 PuLSE-Übersicht [Ba99] ........................................................................ 25

Abbildung 16 Hauptaktivitäten im Framework des SEI [CN01]................................... 28

Abbildung 17 SPL-Framework [PBL05] ....................................................................... 30

Abbildung 18 Variationspunkt und Variante im Metamodell [PBL05]......................... 33

Abbildung 19 Traceability im Variabilitätsmodell (nach [PBL05]) .............................. 33

Abbildung 20 Graphische Notation des orthogonalen Variabilitätsmodells [PBL05]... 34

Abbildung 21 Nebenläufige Entwicklung [Co06] ......................................................... 35

Abbildung 22 Kontext Domain Requirements Engineering .......................................... 37

Abbildung 23 Orthogonales Variabilitätsmodell und Requirements-Beschreibungen (nach [PBL05])........................................................................................ 38

Abbildung 24 Twin Peaks Model (nach [Nu01])........................................................... 40

Abbildung 25 Basisanforderungen Erziehungswissenschaftliche Fakultät ................... 41

Abbildung 26 Basisanforderungen Abteilung Betriebliche Informationssysteme......... 42

Abbildung 27 Basisanforderungen Selbständige Abteilung für Allgemeinmedizin...... 42


101

Abbildung 28 Beispiel-Variationspunkt......................................................................... 45

Abbildung 29 Use-Case-Diagramm und Variabilitätsmodell ........................................ 47

Abbildung 30 Variabilität in der Benutzer-Registrierung.............................................. 48

Abbildung 31 Kontext Domain Design.......................................................................... 50

Abbildung 32 Übersicht Spring-Framework [Al05] ...................................................... 56

Abbildung 33 Verteilungs-Diagramm............................................................................ 57

Abbildung 34 Kontextübergreifende Kommunikation .................................................. 58

Abbildung 35 Aufgaben-Lebenszyklus.......................................................................... 60

Abbildung 36 Kompositions-Strukturdiagramm Aufgaben-Framework ....................... 61

Abbildung 37 Grobe Architektur des elatePortals ......................................................... 62

Abbildung 38 Kontext Domain Realisation ................................................................... 68

Abbildung 39 Anwendungsfallbezogene Exception ...................................................... 71

Abbildung 40 Verteilung von Artefakten im Projekt-Setup .......................................... 73

Abbildung 41 Detailliertes Design der Framework-API (Ausschnitt)........................... 74

Abbildung 42 Kontextübergreifende Kommunikation .................................................. 75

Abbildung 43 Sequenz-Diagramm: Variabilität in der Benutzer-Registrierung............ 77

Abbildung 44 Beispiel: Data Access Object .................................................................. 78

Abbildung 45 Komponenten-Konfiguration in Spring .................................................. 80

Abbildung 46 Multiple-Choice-Aufgabe (Mehrfachauswahl) ....................................... 93

Abbildung 47 Multiple-Choice-Aufgabe (Einfachauswahl) .......................................... 93

Abbildung 48 Lückentext-Aufgabe................................................................................ 93

Abbildung 49 Zuordnungs-Aufgabe .............................................................................. 94

Abbildung 50 Aufgabe Graphische Darstellung ............................................................ 94

Abbildung 51 Metamodell des orthogonalen Variabilitätsmodells [PBL05]................. 95

Abbildung 52 Komponenten-Konfiguration .................................................................. 95

Abbildung 53 Portlet Application Deployment Descriptor............................................ 96

Abbildung 54 E/R-Diagramm: Datenbankschema elatePortal....................................... 96

Abbildung 55 XML-Schema: Aufgabenpool ................................................................. 97

Abbildung 56 Aufgaben-Framework: Präsentations-Webapplikation........................... 98

Abkürzungsverzeichnis

102


ADL Architecture Description Language

AJAX Asynchronous JavaScript and XML

AOP Aspect Oriented Programming

API Application Programming Interface

BAPO Business, Architecture, Process, Organisation

BLOB Binary Large Object

BIS Betriebliche Informationssysteme

CMS Content Management System

COTS Commercial Off The Shelf

CRS Commonality and Reuse Strategy

CRUD Create, Read, Update, Delete

CVS Concurrent Versions System

DAO Data Access Objects

DDL Data Definition Language

EAR Enterprise Application Archive

EJB Enterprise Java Beans

E/R Entity Relationship

GPL GNU Public License

GSE Generative Software Engineering

HRBAC Hierarchical Role Based Access Control

IEEE Institute of Electrical and Electronics Engineers

IESE Institut für Experimentelles Software Engineering

IoC Inversion of Control

J2EE Java2 Enterprise Edition

J2SE Java2 Standard Edition

JAAS Java Authentication and Authorization Services

JAR Java Archive

JAXB Java Architecture for XML Binding


103

JAXP Java API for XML Processing

JCS Java Caching System

JSR Java Specification Request

LDAP Lightweight Directory Access Protocol

MDA Model Driven Architecture

MDE Model Driven Engineering

MDSOC Multidimensional Separation of Concerns

MVC Model View Controller

OOD Objektorientiertes Design

OOP Objektorientierte Programmierung

OSGi Open Services Gateway Initiative

PDF Portable Document Format

POJO Plain Old Java Object

POM Project Object Model

RE Requirements Engineering

RI Referenzimplementierung

RMI Remote Method Invocation

ROI Return On Invest

RSS Really Simple Syndication

RUP Rational Unified Process

SAS Sample Application Strategy

SEI Software Engineering Institute

SHK Studentische Hilfskraft

SLOC Source Lines Of Code

SOA Service Oriented Achitecture

SPL Softwareproduktlinien

SSO Single Sign On

TAN Transaktionsnummer

TDD Test Driven Development

UML Unified Modeling Language

VO Value Objects


104

V&V Verifikation und Validierung

WAR Web Archive

XMI XML Metadata Interchange

XML Extensible Markup Language

XP Extreme Programming

Literaturverzeichnis

105


[ABB01] Atkinson, C.; Bayer, J.; Bunse, C.: Component-based Product Line Engineer-ing with UML. Amsterdam, Niederlande: Addison-Wesley Longman, 09 2001

[ABM00] Atkinson, C.; Bayer, J.; Muthig, D.: Component-Based Product Line Development: The KobrA Approach. In: Software Product Lines: Experience and Research Directions. Boston, USA: Kluwer Academic Publishers, 2000, Seiten 289-309

[ABV92] Aksit, M.; Bergmans, L.; Vural, S.: An object-oriented language-database integration model: The composition filters approach. In: Proceedings of the European Conference on Object-Oriented Programming (ECOOP'92). Lon-don, GB: Springer-Verlag, 1992, Seiten 372-395

[AH03] Abdelnur, A.; Hepper, S.: Java Portlet Specification. http://www.jcp.org/en/jsr/detail?id=168 (12.02.2007). 10 2003

[Al05] Alexandrov, S.: The Spring Framework. http://lib.juga.ru/article/articleview/216/1/3/ (25.02.2007). 06 2005

[Ar05] Armstrong, E.; Ball, J.; Bodoff, S.; Carson, D.B.; Evans, I.; Green, D.; Haase, K.; Jendrock, E.: The J2EETM 1.4 Tutorial. Santa Clara, CA, USA: Sun Micro-systems, 12 2005

[ARF06] Auer, S.; Riechert, T.; Fähnrich, K.-P.: SoftWiki - Agiles Requirements-Engineering für Softwareprojekte mit einer großen Anzahl verteilter Stakehol-der. In: Gemeinschaft in neuen Medien (GeNeMe'06). Dresden, 09 2006

[Ba99] Bayer, J.; Flege, O.; Knauber, P.; Laqua, R.; Muthig, D.; Schmid, K.; Widen, T.; DeBaud, J.-M.: PuLSE: A Methodology to Develop Software Product Li-nes. In: Proceedings of the Fifth ACM SIGSOFT Symposium on Software Re-usability (SSR’99). Los Angeles, CA, USA, 1999, Seiten 122-131

[Ba03] Bachmann, F.; Goedicke, M.; Leite, J.; Pohl, K.; Ramesh, B.; Vilbig, A.: Managing Variability in Product Family Development, In: Proceedings of the 5th International Workshop on Product Family Engineering (PFE-5). Siena, Italy: Springer-Verlag, 11 2003

[Ba04] Bastarrica, M. C.; López, M.; Ochoa, S. F.; Rossel, P. O.: Using the Integrated Notation for Defining Product Line Architecture. In: First Conference on the Principles of Software Engineering (PRISE'2004). Buenos Aires, Argentinien, 11 2004, Seiten 22 – 27

[BA05] Beck, K.; Andres, C.: Extreme Programming Explained: embrace change, Second Edition. Addison-Wesley, 04 2005


106

[BBG05] Beydeda, S.; Book, M.; Gruhn, V.: Model-Driven Software Development. Berlin: Springer-Verlag, 07 2005

[Be99] Behlendorf, B.: Open Source as a Business Strategy. http://www.oreilly.com/catalog/opensources/book/brian.html (02.01.2007). 01 1999

[Be01] Beck, K. et al.: Manifesto for Agile Software Development. http://www.agilemanifesto.org (15.02.2007). 2001

[Be02] Beck, K.: Test Driven Development. By Example. Amsterdam, Niederlande: Addison-Wesley Longman, 12 2002

[Be05a] Berger, T.: Der UebManager und das elatePortal als eTesting-Systeme. http://www.bis.uni-leipzig.de/forschung/fobis/downloads/2005-11-24/berger_thorsten/vortrag.pdf (12.02.2007)

[Be05b] Berger, T.: Portale mit dem Java-Portlet-Standard JSR168, WSRP und Jetspeed 2. http://www.thorsten-berger.net/telematik/Java-Portaltechnologie%20-%20Thorsten%20Berger.pdf (12.02.2007). 07 2005

[BF99] Bullinger, H.-J.; Fähnrich, K.-P.: Betriebliche Informationssysteme. Grundlagen und Werkzeuge der methodischen Softwareentwicklung. Berlin: Springer-Verlag, 02 1999

[BH93] Bræk, R.; Haugen, Ø: Engineering Real Time Systems, BCS Prectitioner Series. Harlow, GB: Prentice Hall, 1993

[BK06] Burns, E.; Kitain, R.: JavaServer Faces 1.2. http://www.jcp.org/en/jsr/detail?id=252 (13.02.2007). 05 2006

[BLP04] Bühne, S.; Lauenroth, K.; Pohl, K.: Anforderungsmanagement in der Automobilindustrie: Variabilität in Zielen, Szenarien und Anforderungen. In: Dadam, P.; Reichert, M. (Hrsg.): Beiträge der 34. Jahrestagung der Gesell-schaft für Informatik e.V (INFORMATIK 2004). Ulm, Deutschland: GI-Edition - Lecture Notes in Informatics (LNI), P-51, 09 2004

[BMN05] Breu, R.; Matzner, T.; Nickl, F.: Software Engineering. Objektorientierte Techniken, Methoden und Prozesse in der Praxis. München, Deutschland: Ol-denbourg Wissenschaftsverlag, 03 2005

[Bo79] Boehm, B.: Software Engineering; R & D trends and defense needs. In: Research Directions in Software Technology. Cambridge, MA, USA: MIT-Press, 1979

[Bo00] Boehm, B. et al.: Software Cost Estimation with COCOMO II. Englewood Cliffs, New Jersey, USA: Prentice Hall, 2000


107

[Bo02a] Boehm, B.: Get Ready for Agile Methods, with Care. In: IEEE Computer 35 (2002), Nr. 1, Seiten 64-69

[Bo04a] Boeckle, G. et al.: Calculating ROI for Software Product Lines. In: IEEE Software 21 (2004), Nr. 3

[Bo04b] Boeckle, G.; Knauber, P.; Pohl, K.; Schmid, K.: Software-Produktlinien. Methoden, Einführung und Praxis. Dpunkt-Verlag, 06 2004

[BW06] Berger, T.; Wollersheim, H.-W.: Eine dienste- und komponentenbasierte Architektur zur elektronischen Durchführung von Prüfungen und zum Mana-gement von Lehrveranstaltungen. In: Hochberger, C.; Liskowsky, R. (Hrsg.): Beiträge der 36. Jahrestagung der Gesellschaft für Informatik e.V (INFOR-MATIK 2006). Dresden, Deutschland: GI-Edition - Lecture Notes in Informat-ics (LNI), P-93, 10 2006

[Ca06] Carbon, R.; Lindvall, M.; Muthig, D.; Costa, P.: Integrating Product Line Engineering and Agile Methods: Flexible Design Up-front vs. Incremental De-sign. In: APLE 1st International Workshop on Agile Product Line Engineering. Baltimore. ML, USA, 08 2006

[CE00] Czarnecki, K.; Eisenecker, U.W.: Generative Programming. Methods, Tools and Applications. Addison-Wesley, 06 2000

[CN01] Clements, P.; Northrop, L.M.: Software Product Lines: Practices and Patterns. Addison Wesley, 08 2001

[Co98] Cockburn, A.: Surviving Object-Oriented Projects: A Manager's Guide. Amsterdam, Niederlande: Addison-Wesley, 1998

[Co02] Cohen, S.: Product Line State of the Practice Report, Technical Note CMU/SEI-2002-TN-017. Software Engineering Institute, Carnegie Mellon U-niversity, 09 2002

[Co06] Cockburn, A.: Agile Software Development: The Cooperative Game, 2nd ed. Amsterdam, Niederlande: Addison-Wesley Longman, 11 2006

[DH01] Dashofy, E.; Van der Hoek, A.: Representing Product Family Architectures in an Extensible Architecture Description. In: Proceedings of the International Workshop on Product Family Engineering (PFE-4). Bilbao, Spanien, 10 2001.

[Di72] Dijkstra, E.W. et al.: Structured Programming. London, GB: Academic Press, 1972

[Di76] Dijkstra, E.W.: A Discipline of Programming. Englewood Cliffs, New Jersey: Prentice-Hall, 06 1976

[Do97] Dorfman, M.; Thayer, R.H.: Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press. 1997


108

[Es97] ESPRIT Consortium: PRAISE Project. http://web.archive.org/web/ 20030118143146/http://www.esi.es/Projects/Reuse/Praise/ (13.11.2006). 1997

[FFB02] Fey, D.; Fajita, R.; Boros, A.: Feature Modeling – A Meta-Model to Enhance Usability and Usefulness. In: Proceedings of the 2nd International Conference on Software Product Lines (SPLC-2). San Diego, USA: Springer-Verlag, 2002, Seiten 198-216

[FJM94] Feijs, L.M.G.; Jonkers, H.B.M.; Middleburg, C.A.: Notations for Software Design. FACIT series. Springer-Verlag, 1994

[Fr05] Frotscher, T.: In Zukunft Traum-Tools. Verbesserte Interoperabilität bei der Entwicklung von Web Services. In: Java-Magazin 06 (2005), Seiten 98-193

[Ga95] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Massachusetts, USA: Addision-Wesley, 03 1995

[Ga05] Garrett, J.J.: Ajax: A New Approach to Web Applications. http://www.adaptivepath.com/publications/essays/archives/000385.php (23.03.2007). 02 2005

[Ga06] García, F.J.P.; Laguna, M.A.; González-Carvajal, Y.C.; González-Baixauli, B.: Requirements Variability Support through MDD and Graph Transformations. In: International Workshop on Graph and Model Transformation (GraMoT05), Electronic Notes in Theoretical Computer Science. Tallinn, Estland: Elsevier, 03 2006, Seiten 161-173

[Gr02] McGregor, J.D.; Northrop, L.M.; Jarrad, S.; Pohl, P: Guest Editors' Introduc-tion: Initiating Software Product Lines. In: IEEE Software 19 (2002), Nr. 4, Seiten 24-27

[Hi00] Highsmith, J.: Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House Publishing, 01 2000

[Ho01] Van der Hoek, A.; Mikic-Rakic, M.; Roshandel, R.; Medvidovic, N.: Taming architectural evolution. In: Proceedings of the 8th European software engineer-ing conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering. Wien, Österreich, 2001, Seiten 1-10

[Ho05] Holzer, B.: Bottleneck Blues. Java Profiling: Flaschenhälse in Java-Programmen identifizieren. In: Java-Magazin 06 (2005), Seiten 80-86

[HP04] Hovemeyer, D.; Pugh, W.: Finding bugs is easy. In: SIGPLAN Not. 39 (2004), Nr. 12, New York, NY, USA: ACM Press, Seiten 92-106

[HR01] Härder, T.; Rahm, E.: Datenbanksysteme. Konzepte und Techniken der Implementierung. Springer-Verlag, 07 2007


109

[HRS03] Hruschka, P.; Rupp, C.; Starke, G.: Agility kompakt. Tipps für erfolgreiche Systementwicklung. Spektrum Akademischer Verlag, 10 2003

[IEEE90] Institute of Electrical and Electronics Engineers: IEEE Standard Glossary of Software Engineering Terminology (IEEE Std. 610.12-1990). New York, 1990

[Il68] McIlroy, M.D.: Mass produced software components. In: Naur, P.; Randell, B. (Hrsg.): Software Engineering; Report on a conference by the NATO Science Committee (Garmisch, Germany, Oct.). Brüssel, Belgien: NATO Scientific Af-fairs Division, 10 1968, Seiten 138-150

[JGJ97] Jacobson, I; Griss, M,; Jonsson, P.: Software Reuse. Architecture, Process and Organization for Business Success. Addison-Wesley, 1997

[JH04] Johnson, R.; Höller, J.: J2EE Development Without EJB. Wiley & Sons, 07 2004

[JM02] John, I.; Muthig, D.: Tailoring Use Cases for Product Line Modeling. In: Proceedings of the International Workshop on Requirements Engineering for Product Lines (REPL'02). 09 2002

[JRL00] Jazayeri, M.; Ran, A.; Van der Linden, F.J.: Software Architecture for Product Families. Reading, Massachusetts: Addison-Wesley, 2000

[Ka90] Kang, K.; Cohen, S.; Hess, J.; Novak, W.; Peterson, S.: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21. Software Engineering Institute, Carnegie Mellon University, 11 1990

[Ka96] Kano, N.; Seraku, N.; Takahashi, F.; Tsuji, S.: Attractive Quality and Must-be Quality. In: Hromi, J. D. (Hrsg.): The Best on Quality. Milwaukee, Wisconsin, USA: Quality Press, 1996

[KD06] Käkölä, T.; López, J.C.D.: Software Product Lines. Research Issues in Engineering and Management. Berlin: Springer-Verlag, 08 2006

[KKO02] Kawachiya, K.; Koseki, A.; Onodera, T.: Lock reservation: Java locks can mostly do without atomic operations. In: Proceedings of the 17th ACM SIG-PLAN conference on Object-oriented programming, systems, languages and applications. ACM Press, 2002, Seiten 130-141

[KLD02] Kang, K.; Lee, J.; Donohoe, P.: Feature-Oriented Product Line Engineering. In: IEEE Software 19 (2002), Nr. 4, Seiten 58-65

[Kl06] Kleineikenscheidt, S.: Build-Freak 2.0. Maven 2: Die neue Build-Tool-Generation. In: Java-Magazin 09 (2006), Seiten 94-96

[Kn00] Knauber, P.; Muthig, D.; Schmid, K.; Widen, T.: Applying Product Line Concepts in Small and Medium-Sized Companies. In: IEEE Software 17 (2000), Nr. 5, Seiten 88-95


110

[Kr95] Kruchten, P.: The 4+1 View Model of Architecture. In: IEEE Software 12 (1995), Nr. 6, Seiten 42-50

[LAI04] Luck, M.; Ashri, R.; D’Inverno, M.: Agent-Based Software Development (Agent-Oriented Systems). Artech House, 02 2004

[LH89] Lieberherr, K.J.; Holland, I.M.: Assuring Good Style for Object-Oriented Programs. In: IEEE Software 06 (1989), Nr. 5, Seiten 38-48

[LH06] Ludwig, R.; Hoffmann, T.: Attrappen im Testfeld. Einführung in Test Driven Design mit Dummies und Mocks. In: Java-Magazin 01 (2006), Seiten 23-29

[Li95] Lieberherr, K.J.: Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns. Boston, MA, USA: PWS Publishing Co., Boston, 1995

[Li02] Van der Linden, F.: Software Product Families in Europe: The Esaps & Café Projects. In: IEEE Software 19 (2002), Nr. 4, Seiten 41-49

[LM04] Linwood, J.; Minter, D.: Building Portals with the Java Portlet API. Berkeley, CA, USA: Apress, 08 2004

[Ma04] Matinlassi, M.: Comparison of Software Product Line Architecture Design Methods: COPA, FAST, FORM, KobrA and QADA. In: 26th International Conference on Software Engineering (ICSE'04). 2004, Seiten 127-136

[MFC00] Mackinnon, T.; Freeman, S.; Craig, P.: Endo-Testing: Unit Testing with Mock Objects. In: eXtreme Programming and Flexible Processes in Software Engi-neering (XP2000). Addison-Wesley, 06 2000

[MK06] DeMichiel, L.; Keith, M.: Enterprise JavaTM Beans, Version 3.0, Final Release. Sun Microsystems, 05 2006

[ML02] Von der Maßen, T.; Lichter, H.: Modeling Variability by UML Use Case Diagrams. In: Proceedings of the International Workshop on Requirements Engineering for Product Lines (REPL’02), 09 2002

[Nu01] Nuseibeh, B.: Weaving Together Requirements and Architectures. In: IEEE Software 34 (2001), Nr. 3, Seiten 115-117

[Om00] Van Ommering, R.: Beyond Product Families: Building a Product Population? In: Proceedings of the 3rd international workshop on the development and evo-lution of software architectures of product families. Las Palmas, Spanien, 03 2000

[OMG01] Object Management Group: Model driven Architecture (MDA). http://www.omg.org/mda/specs.htm (04.04.2007). 2001


111

[OMG04] Object Management Group: Unified Modeling Language (UML). http://www.omg.org/technology/documents/formal/uml.htm (16.02.2007). 07 2004

[OMG05] Object Management Group: MOF 2.0/XMI Mapping Specification, v2.1. http://www.omg.org/docs/formal/05-09-01.pdf (14.02.2007). 09 2005

[Os94] Ossher, H.; Harrison, W.; Budinsky, F.; Simmonds, I.: Subject-Oriented Programming: Supporting Decentralized Development of Objects. In: Proceed-ings of the 7th IBM Conference on Object-Oriented Technology. 07 1994

[OS03] OSGi Alliance: OSGi Service Platform. IOS Press, 12 2003

[OT00] Ossher, H.; Tarr, P.: Multi-Dimensional Separation of Concerns and The Hyperspace Approach. In: Proceedings of the Symposium on Software Archi-tectures and Component Technology: The State of the Art in Software Devel-opment. Kluwer, 2000

[Pa72] Parnas, D.L.: On the Criteria To Be Used in Decomposing Systems into Modules. In: Communications of the ACM 15 (1972), Nr. 12, Seiten 1053-1058

[Pa98a] Partsch, H.: Requirements Engineering systematisch: Modellbildung für softwaregestützte Systeme. Berlin: Springer-Verlag, 19 1998

[Pa98b] Parnas, D.L.: Software engineering programmes are not computer science programmes. In: Annals of Software Engineering 6 (1998). Baltzer Science Publishers, Seiten 19-37

[PBL05] Pohl, K.; Böckle, G.; Van der Linden, F.: Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag. 09 2005

[Pe01] Pelegri-Llopart, E.; Sun Microsystems et.al.: JavaTM Servlet Specification Version 2.3. http://www.jcp.org/en/jsr/detail?id=53 (26.02.2007). 09 2001

[Pe03] Penchikale, S.: Object Caching in a Web Portal Application Using JCS. http://www.onjava.com/pub/a/onjava/2003/12/23/caching.html (19.02.2007). 12 2003

[PRB03] Philippow, I.; Riebisch, M.; Böllert. K.: The Hyper/UML Approach for Feature Based Software Design. In: Proceedings of the 4th AOSD Modeling With UML Workshop. Sixth International Conference on the Unified Modeling Language (UML2003). San Francisco, CA, USA. 10 2003

[PS06] Petrov, D.; Schümann, B.: Integration delegieren! Integration in Java EE-Webapplikationen mit Appfuse, Teil 1: Komplexität beherrschbar? In: Java-Magazin 12 (2006), Seiten 32-35

[PTL99] Prowell, S.J.; Trammell, C.J.; Linger, R.C.: Cleanroom Software Engineering: Technology and Process. Reading, MA, USA: Addison-Wesley, 04 1999


112

[Pu00] Pugh, W. et al.: The double checked locking is broken declaration. http://www.cs.umd.edu/users/pugh/java/memoryModel/DoubleCheckedLocking.html (23.03.2007), 07 2000

[RAF04] Rutar, N.; Almazan, C.B.; Foster, J.S.: A Comparison of Bug Finding Tools for Java. In: 15th International Symposium on Software Reliability Engineering (ISSRE'04), 2004, Seiten 245-256

[RK05] Rupp, C.; Kellermann, C.: Gut dokumentiert ist schon halb gebaut. Require-ments Engineering, Teil 3: Zutaten für eine bekömmliche Prosaspezifikation. In: Java-Magazin 12 (2005), Seiten 63-65

[Ro01] Romanovsky, A.; Dony, C.; Knudsen, J.L.; Tripathi, A.: Advances in Exception Handling Techniques (Lecture Notes in Computer Science). Berlin: Springer-Verlag, 2001

[SB02] Schwaber, K.; Beedle, M.: Agile Software Development with Scrum. Prentice Hall, 02 2002

[SG96] Shaw, M.; Garlan, D.: Software Architecture: Perspectives on an Emerging Discipline. Englewood Cliffs, NJ, USA: Prentice Hall, 1996

[SL03] Spillner, A.; Linz, T.: Basiswissen Softwaretest. Heidelberg: dpunkt-Verlag, 2003

[So06] Sommerville, I.: Software Engineering, Eighth Edition. Amsterdam: Addison-Wesley Longman, 06 2006

[SSJ02] Sing, I.; Stearns, B.; Johnson, M.: Designing Enterprise Applications with the J2EE Platform. 2, Addison-Wesley, 03 2002

[St03] The Standish Group International: The CHAOS Report, Technical report. The Standish Group, 2003

[St05] Le Strat, D.: Jetspeed 2 Security Architecture. http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/index.html (06.01.2007). 2005

[Su02] Sun Microsystems: Core J2EE Patterns. http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html (06.02.2007). 2002

[Su03a] Sun Microsystems: Java™ 2 Platform Enterprise Edition Specification, v1.4. http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf (12.02.2007). 11 2003

[Su03b] Sun Microsystems: Enterprise JavaBeansTM Specification, Version 2.1. http://www.jcp.org/en/jsr/detail?id=153 (05.02.2007)


113

[Sz02] Szyperski, C.: Component Software: Beyond Object-oriented Programming. Amsterdam, Niederlande: Addison-Wesley Longman, 11 2002

[Ta00] Tarr, P.; Harrison, W.; Ossher, H.; Finkelstein, A.; Nuseibeh, B.; Perry, D.: Workshop on Multi-Dimensional Separation of Concerns in Software Engi-neering. In: Proceedings of the 22nd International Conference on Software Engineering (ICSE '00). Limerick, Irland: ACM, 2000, Seite 809

[TC06] Tian, K.; Cooper, K.: Agile and Software Product Line Methods: Are They So Different? In: 1st International Workshop on Agile Product Line Engineering (APLE'06). Baltimore, ML, USA, 08 2006

[TH03] Trigaux, J. C.; Heymans, P.: Software Product Lines: State of the art. Technical report PLENTY project. Naumur, Belgien: Institut d’Informatique FUNDP, 09 2003

[VK05] Verlage, M.; Kiesgen, T.: Five years of product line engineering in a small company. In: Proceedings of the 27th international conference on Software engineering (ICSE ’05). St. Louis, MO, USA, 2005, Seiten 534-543

[VS06] Völter, M.; Stahl, T.: Model-Driven Software Development. Wiley & Sons, 05 2006

[Wa02] Waldmann, J.; Rahn, M.: The Leipzig autotool System for Grading Student Homework. In: Hanus, M.; Krishnamurthi, S.; Thompson, S. (Hrsg.): Proceed-ings Functional and Declarative Programming in Education (FDPE-02). Kiel, 2002

[WB05] Walls, C.; Breidenbach, R.: Spring in Action. Greenwich, CT, USA: Manning, 03 2005

[We95] Weiss, D.: Software Synthesis: The FAST Process. In: Proceedings of the International Conference on Computing in High Energy Physics (CHEP). 09 1995

[Wh01] Wheeler, D.: Counting Source Lines of Code (SLOC). http://www.dwheeler.com/sloc (11.04.2007). 2001

[WL99] Weiss, D.M.; Lai, C.T.R.: Software Product-Line Engineering – A Family-Based Software Development Process. Reading, Masachusetts, USA: Addison-Wesley, 1999

[Wo05] Wolff, E.: Schon wieder Frühling? Spring, Teil 1: innovative Lösungen für Enterprise-Java-Anwendungen. In: Java-Magazin 04 (2005), Seiten 45-49

[Wu05] Wunderlich, L.: Die Post-OO-Welt. AOP, Teil 1: Was bedeutet AOP? Wo kommt sie her? Wo führt sie uns hin? In: Java-Magazin 12 (2005), Seiten 30-34


114

[Za07] Zacharias, R.: Industrialisierung, wir kommen! Produktlinien: Der nächste Schritt in Richtung Software-Industrialisierung. In: Java-Magazin 03 (2007), Seiten 69-79

Erklärung

Ich versichere, dass ich die vorliegende Arbeit selbständig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe.

Leipzig, 26. April 2007

Thorsten Berger

Softwareproduktlinien-Entwicklung – Domain Engineering ...berger/Diplomarbeit.pdf · kleinen und...

Documents

Transcript of Softwareproduktlinien-Entwicklung – Domain Engineering ...berger/Diplomarbeit.pdf · kleinen und...