Schriftliche Ausarbeitung - Alexander Willner | Masterarbeit

Georg-August-Universität
Göttingen
Zentrum für Informatik
Masterarbeit
im Studiengang "Angewandte Informatik"
ISSN 1612-6793
Nummer ZFI-BM-2006-36
Entwurf und Implementierung einer
Ressourcen-Datenbank für das
Instant-Grid-Projekt der GWDG
Alexander Willner
am Lehrstuhl für
Praktische Informatik
Bachelor- und Masterarbeiten
des Zentrums für Informatik
an der Georg-August-Universität Göttingen
27. Oktober 2006

Georg-August-Universität Göttingen
Zentrum für Informatik
Lotzestraße 16-18
37083 Göttingen
Germany
Tel. +49 (5 51) 39-1 44 14
Fax +49 (5 51) 39-1 44 15
Email office@informatik.uni-goettingen.de
WWW www.informatik.uni-goettingen.de

Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst
und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet
habe.
Göttingen, den 27. Oktober 2006

Masterarbeit
Entwurf und Implementierung einer
Ressourcen-Datenbank für das
Instant-Grid-Projekt der GWDG
Alexander Willner
27. Oktober 2006
Erstgutachter Prof. Dr. Oswald Haan ∗
Zweitgutachter Prof. Dr. Bernhard Neumair †
Betreuer Dr. Christian Boehme ‡
Zentrum für Informatik
Georg-August-Universität Göttingen
∗ Leiter der Arbeitsgruppe Anwendungs- und Informationssysteme der Gesellschaft für wissenschaftliche
Datenverarbeitung mbH Göttingen.
† Geschäftsführer der Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen und
Inhaber des Lehrstuhls für Praktische Informatik an der Universität Göttingen.
‡ Wissenschaftlicher Mitarbeiter der Arbeitsgruppe Anwendungs- und Informationssysteme der
Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen.

Gegenstand der vorliegenden Arbeit ist der Entwurf und die Implementierung einer einheitlichen
Ressourcen-Datenbank für das Instant-Grid-Projekt 1 der Gesellschaft für wissenschaftliche
Datenverarbeitung mbH Göttingen 2 . Dieses wird innerhalb des Verbundvorhabens
des D-Grid-Integrationsprojektes als Demonstrationsumgebung für Grid-Software
vom Bundesministerium für Bildung und Forschung finanziert.
Im Rahmen dieser Arbeit wird die automatische Erstellung einer Datenbank der im
Grid vorhandenen Hardware-Ressourcen mittels existierender Information-Provider ermöglicht.
Dazu ist eine entsprechende Erweiterung der Instant-Grid-Infrastruktur erforderlich.
Die gesammelten Informationen werden in ein einheitliches Datenformat überführt
und eine Anbindung an das Instant-Grid-Portal implementiert. In diesem Zusammenhang
werden Bedienelemente zur einheitlichen Benutzeroberfläche des Portals hinzugefügt
und so eine Benutzer-Schnittstelle zur Datenbank geschaffen.
„Man hält die Erzeugung von Information für ein Zeichen von Intelligenz,
während in Wirklichkeit das Gegenteil richtig ist: Die Reduktion, die Auswahl
der Information ist die viel höhere Leistung.“ [Heinz Zemanek, österreichischer
Informatiker]
1 http://www.instant-grid.org
2 http://www.gwdg.de

Inhaltsverzeichnis
1. Einleitung 1
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3. Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Grundlagen 4
2.1. Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Instant-Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Grid-Workflowmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Anforderungsanalyse 15
3.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Beschreibung der Systemidee und Zielsetzung . . . . . . . . . . . . . . . . . 15
3.3. Identifizierung der Anforderungsbeitragenden . . . . . . . . . . . . . . . . . 16
3.4. Identifizierung der Interessen der Anforderungsbeitragenden . . . . . . . . 16
3.5. Beschreibung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6. Konkretisierung der Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . 24
3.7. Beschreibung der Systemschnittstelle . . . . . . . . . . . . . . . . . . . . . . . 33
4. Design 36
4.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2. Anwendungsarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3. Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4. Klassenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5. Implementierung und Test 46
5.1. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2. Statische Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3. Dynamische Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
i

Inhaltsverzeichnis
6. Zusammenfassung, Kritik und Ausblick 59
6.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2. Kritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A. Verwendete Konfiguration 61
A.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B. Dokumentation 63
B.1. Quelltexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.2. Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.3. GRDB-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.4. GRDB-Portletübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.5. D-GRDL-Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Glossar 80
Abbildungsverzeichnis 84
Tabellenverzeichnis 85
Literaturverzeichnis 86
ii

1. Einleitung
1.1. Motivation
Viele der weltweit verteilten, enormen Rechnerkapazitäten werden zu einem großen Teil
nicht verwendet. Die Idee, ungenutzte Hardware-Ressourcen für eigene Aufgaben einzusetzen,
findet nicht nur schon seit längerem in Fachkreisen Anwendung (vgl. [1, 2, 3]),
sondern wird auch seit einigen Jahren in darüber hinaus bekannten Projekten (vgl. [4, 5])
umgesetzt. Hierbei handelt es sich fast ausschließlich um Techniken, bei denen ungenutzte
Rechenzyklen für einzelne Prozesse einer, auf mehrere Computer verteilten, Anwendung
genutzt werden, um ein gemeinsames Ergebnis einer speziellen Aufgabe zu berechnen.
Dies ist insbesondere bei vielen wissenschaftlichen Anwendungen notwendig, da die erforderliche
Rechenleistung häufig nicht mehr von einem einzigen Computer oder einer
einzigen Einrichtung zur Verfügung gestellt werden kann.
Einen Schritt weiter gehen so genannte Grid-Systeme, die geforderte Dienste und Ressourcen
unabhängig von ihrer räumlichen Entfernung transparent bereitstellen. Dabei ist
es gleichgültig, ob es sich wie oben genannt um Rechenleistung, Speicherkapazität oder
Softwareanwendungen handelt (s. Kap. 2.1). Der Aufbau und die Inbetriebnahme eines
Grids und der damit zusammenhängenden Komponenten kann jedoch sehr aufwendig
sein. Diesem Umstand hat das Instant-Grid-Projekt Rechnung getragen und eine selbstkonfigurierende
Grid-Umgebung geschaffen (s. Kap. 2.2). Die Demonstration der Anwendungen
im IG folgt jedoch sehr einfachen Mechanismen zur Verteilung von Rechenaufgaben
und Identifizierung der im Netz verfügbaren Hardware-Ressourcen. Das Fraunhofer
Institut für Rechnerarchitektur und Softwaretechnik (FIRST) widmet sich diesem Thema
und entwickelt in diesem Zusammenhang ein Grid-Workflowmanagement-System (s.
Kap. 2.3). Die Bereitstellung und Visualisierung der hierfür benötigten Informationen sind
der Kern dieser Arbeit.
1.2. Zielsetzung
Das Ziel der vorliegenden Arbeit ist der Entwurf und die Implementierung einer Ressourcen-Datenbank
für das Instant-Grid-Projekt. Das zu entwickelnde System hat zur Aufgabe,
Informationen über im Netz vorhandene Hardware-Ressourcen zu sammeln und
diese in einer im System zugänglichen Datenbank zu speichern. In diesem Zusammen-
1

1. Einleitung
hang sollen die vorhandene Instant-Grid-Infrastruktur erweitert und Bedienelemente zur
einheitlichen Benutzeroberfläche des Anwender-Portals hinzugefügt werden.
Die technischen Voraussetzungen und detaillierten Anforderungen an ein solches System
sind herauszuarbeiten und ein geeigneter Lösungsweg aufzuzeigen. Die enge Zusammenarbeit
mit dem Projektpartner FIRST spielt dabei eine wesentliche Rolle.
1.3. Methodik
Aspekte der Integration in das vorhandene Projekt, die Nutzung einer Vielzahl verschiedener
Technologien und das Zusammenwirken unterschiedlicher Reflexionsebenen durch
mehrere Projektbeteiligte sind zu beachten. Dies muss sich in der Vorgehensweise und der
angebrachten Wahl der entsprechenden Methoden der Informatik widerspiegeln.
Die im Folgenden eingesetzte Methodik zur Analyse und Entwurf des Systems basiert
auf dem sog. „Object Engineering Process“ (OEP) 1 und orientiert sich weitestgehend an
dem Lehrbuch von Bernd Oestereich[6]. Ziel des OEP ist die Entwicklung hochwertiger
Anforderungsformulierungen als Grundlage für die Systementwicklung. Ein strukturiertes
Vorgehen in diesem Bereich ist besonders wichtig, da Fehler in der Anforderung ein exponentielles
Wachstum des Aufwands zur Korrektur im Laufe des Entwicklungsprozesses
zur Folge hat (vgl. [7, 8]). Diese Beobachtung unterstreicht auch das Ergebnis einer Studie
der Standish Group[9] in der angegeben wird, dass die Gründe für das Fehlschlagen von
Projekten zu über ein Viertel in einer unvollständigen Dokumentation der Anforderungen
und einer unzureichenden Einbeziehung der Nutzer liegen.
Aufgrund des technischen Charakters der zu entwickelnden Anwendung wurde das
Verfahren zusätzlich durch weitere Aspekte aus den einschlägigen Fachbüchern von Helmut
Balzert[8], Chris Rupp[10] und Bernd Brügge[11] modifiziert und ergänzt. Die verschiedenen
Kernabschnitte der Softwareentwicklung, Analyse, Design, Implementierung
und Test, werden im Entwicklungsprozess iterativ und inkrementell durchlaufen. Dadurch
können schrittweise Zwischenergebnisse präsentiert und damit eine kontinuierliche und
effektive Kommunikation zwischen den beteiligten Gruppen gewährleistet werden.
1.4. Aufbau
Nach der einleitenden Beschreibung des genauen Umfeldes der Arbeit wird, mit Blick
auf die Integration der Arbeit in die verschiedenen Projekte, ein entsprechendes Anforderungsprofil
abgeleitet. Die detaillierte Analyse der Anforderungen und Rahmenbedingungen
bildet im Anschluss die Grundlage für das Design der Anwendung. Gefolgt von der
1 Eine Entwicklung der oose.de GmbH (s. http://www.oose.de/oep/).
2

1. Einleitung
Beschreibung der entsprechenden Implementation, die sich insbesondere durch kontinuierliche
Maßnahmen der Qualitätssicherung auszeichnet, wird abschließend eine kritische
Zusammenfassung der Arbeit und ein Ausblick auf weiterführende Tätigkeiten gegeben.
Die verwendete Konfiguration und weitere Dokumentationen finden sich im Anhang.
3

2. Grundlagen
2.1. Grid
2.1.1. Definition
Bei einem Grid handelt es sich um eine Infrastruktur, die eine integrierte, gemeinschaftliche
Verwendung von meist geographisch auseinander liegenden, autonomen Ressourcen
erlaubt. Versuche einer einheitlichen Definition in der Literatur gibt es jedoch viele (vgl.
[12, 13, 14]). Dieser Problematik hat sich Ian Foster, einer der treibenden Mitbegründer
der Grid-Technologie der Universität Chicago, angenommen und hat eine übersichtliche
3-Punkte-Checkliste[15] aufgestellt. Die Eigenschaften eines Grid-Systems werden in kurzen
Worten wie folgt definiert: Ein Grid. . .
(i) . . . koordiniert Ressourcen, die nicht einer zentralen Instanz untergeordnet sind...
Ein Grid koordiniert und integriert Ressourcen und Benutzer unterschiedlicher administrativer
Domänen innerhalb des selben Unternehmens oder innerhalb unterschiedlicher
Länder. In diesem Zusammenhang werden u.a. auf die Bereiche Sicherheit,
Abrechnung und Mitgliedschaft Rücksicht genommen (vgl. [16, 17]). Ressourcen
können unter anderem Cluster, Massenspeicher, Datenbanken, Anwendungen
oder Messgeräte sein.
(ii) . . . und verwendet offene, standardisierte Protokolle und Schnittstellen,...
Ein Grid nutzt offene und allgemein gehaltene Protokolle und Schnittstellen, die
grundsätzliche Funktionen für die Authentifizierung, die Autorisierung, die Ressourcen-Ermittlung
und den Ressourcen-Zugriff gewährleisten.
(iii) . . . um nicht triviale Dienstgüten bereitzustellen.
Ein Grid verwendet bestehende Ressourcen in einer koordinierten Art und Weise, um
verschiedene Dienstgüten bereitzustellen, abhängig von beispielsweise der Antwortzeit,
dem Durchsatz, der Erreichbarkeit oder Sicherheit. Oder es erfolgt, um komplexen
Benutzererwartungen zu entsprechen, eine Neueinteilung mehrerer Ressourcentypen,
damit der Nutzen des kombinierten Systems signifikant größer ist als die
Summe seiner Teile.
Diese Definition ist hilfreich bei der Abgrenzung verschiedener Technologien zu einem
Grid. So werden sehr häufig Systeme, die in die Bereiche des „Distributed computing“,
4

2. Grundlagen
„Cluster computing“, „Peer to peer computing“ oder „Meta computing“ fallen, fälschlicherweise
als Grid-Systeme bezeichnet. Wenngleich viele Aspekte der genannten Technologien
in einem Grid Anwendung finden.
2.1.2. Herkunft
Konzepte für die Verteilung rechenintensiver Aufgaben hat es bereits in den 60er Jahren
gegeben. Die meisten der heutigen Forschungsarbeiten an Grid-Systemen haben ihren Ursprung
jedoch in frühen Experimenten mit Hochgeschwindigkeitsnetzen, wie etwa innerhalb
der Gigabit-Testumgebung an der University of Illinois im Jahr 1992[18]. Insbesondere
jedoch machte das I-Way-Experiment[19] im Jahre 1995, in dem 17 Einrichtungen in den
USA und Kanada zu einem Hochgeschwindigkeitsnetz zusammengeschlossen wurden,
die Grid-Technologie außerhalb des alleinigen Forschungsfeldes der Netzwerktechnik publik.
Der Begriff „Grid“ hat seinen Ursprung in dem Vergleich dieser Technologie zum Stromnetz
(engl. „Power Grid“). Demnach soll das Grid einem Benutzer ebenso einfach Ressourcen
wie z.B. Rechenleistung oder Speicherplatz über das Internet zur Verfügung stellen,
wie es möglich ist Strom aus einer Steckdose zu beziehen (s. Tab. 2.1).
Tabelle 2.1.: Vergleich: Stromnetz und Grid. Angelehnt an [20].
Eigenschaft Stromnetz Grid
Infrastruktur Verbindung verschiedener
Transparenz
Kraftwerke und Wandlerstationen
über Stromleitungen
Herkunft des Stroms für den
Endnutzer unbedeutend.
Verfügbarkeit Eine sehr gute Infrastruktur des
Stromnetzes ist durch die Anbindung
fast aller Haushalte ge-
geben.
Abrechnung Die Abrechnung erfolgt auf
Grundlage der verwendeten
Menge an Strom.
2.1.3. Zielsetzung
Verbindung verschiedener Ressourcen
über das Internet mit
Hilfe offener Standards.
Herkunft der Ressource (z.B. Re-
chenleistung) unbedeutend.
Durch die Nutzung verschiedener
Plattformen und des Internets
ist eine sehr gute Infrastruk-
tur gegeben.
Die Abrechnung erfolgt auf
Grundlage der verwendeten
Mengen an Ressourcen.
Die motivierende Zielsetzung, die zu der Entwicklung der Grid-Technologie geführt hat,
war die gemeinsame, koordinierte Nutzung von Ressourcen und die gemeinsame Lösung
5

2. Grundlagen
von Problemen innerhalb dynamischer, institutionsübergreifender, virtueller Organisationen
(vgl. [13]). Das bedeutet, nach der Festlegung von Abrechnungsdaten und Rechten
soll ein direkter Zugang zu beispielsweise Rechenleistungen, Anwendungen, Daten oder
Instrumenten gemeinschaftlich ermöglicht werden. Eine virtuelle Organisation (VO) ist
in diesem Zusammenhang ein dynamischer Zusammenschluss von Individuen und/oder
Institutionen, die gemeinsame Ziele bei der Nutzung des Grids verfolgen.
Zwar liegt der Fokus vieler Arbeiten im Bereich des verteilten Rechnens, dennoch ist
oberstes Ziel, analog zu der Entstehung des Internets, die Entwicklung eines einheitlichen,
globalen Grids. Dieses könnte in vielen Bereichen u.a. der Wissenschaft, Medizin und Lehre
eingesetzt werden (vgl. [21, 20]).
2.1.4. Architektur
2.1.4.1. Einleitung
Das Ergebnis nach etwa einem Jahrzehnt der intensiven Forschung und Entwicklung von
Grid-Technologien war unter anderem ein Konsens über die Anforderungen und die Architektur
eines Grids. Auch wurden offene Standardprotokolle zur Nachrichtenkommunikation
und Steuerung entworfen, um eine Basis für weitere interoperable Entwicklungen
zu schaffen. Die Bedeutung solch einer Grundlage wird in Abbildung 2.1 ersichtlich.
Abbildung 2.1.: Architektur eines Grids [21]
Protokolle und Schnittstellen können abhängig von ihrer Funktion in verschiedene Kategorien
eingeteilt werden. Die Architektur eines Grids wird daher häufig funktional in
verschiedene Ebenen aufgeteilt. Komponenten auf einer Schicht besitzen ähnliche Charakteristiken
und können auf Fähigkeiten und Verhaltensweisen von tieferen Schichten aufbauen.
6

2. Grundlagen
Fabric. Die unterste Ebene dient dazu, ein gemeinsames Interface auf alle denkbaren
Arten von Ressourcen zur Verfügung zu stellen. Von höheren Schichten aus erfolgt der
Zugriff über standardisierte Verfahren. Alle Ressourcen, auf die eine solche einheitliche
Schnittstelle anwendbar ist, können in das Grid-Konzept eingebunden werden. Dies beinhaltet
Computer, Speichersysteme, Netzwerke oder Sensoren.
Resource and connectivity protocols. Die Verbindungsschicht definiert die Grundkommunikations-
und Authentifikationsprotokolle, die für das Grid benötigt werden. Während
die Kommunikationsprotokolle den Austausch von Daten zwischen verschiedenen,
durch die erste Ebene verbundenen Ressourcen ermöglichen, erlauben die Authentifikationsprotokolle,
eine Kommunikation vertraulich stattfinden zu lassen und die Identität der
beiden Kommunikationspartner sicherzustellen. Hierzu gehören auch die Delegation von
Rechten und Verfahren zur einmaligen Authentifizierung (single sign-on).
Auf der Ressourcenschicht wird der gemeinsame Zugriff auf einzelne Ressourcen organisiert.
Dies beinhaltet die Initiierung, Beobachtung, Kontrolle, Abrechnung und die Verhandlung
von Sicherheitsparametern. Ebenso werden Ressourcen zugewiesen, reserviert,
beobachtet und gesteuert. Die OGSA 1 [22] ist eine noch in der Entwicklung befindliche
Architektur, die in vielen Grid-Projekten die Realisierung dieser Schicht übernimmt. Das
Globus Toolkit 4 (GT4) stellt eine bekannte Implementierung der OGSA-Spezifikation dar
und bietet Software-Dienste und Bibliotheken, um ein Grid nach der OGSA Spezifikation
zu realisieren (s. Kap. 2.1.4.2).
Collective services. Die Aufgabe dieser Schicht ist die Koordination mehrerer Ressourcen.
Der Zugriff auf die Ressourcen erfolgt hierbei nicht mehr direkt, sondern lediglich
über die darunterliegenden Protokolle und Schnittstellen. Zu den Funktionen dieser Ebene
gehören unter anderem die Erstellung eines Verzeichnisdienstes und die Bereitstellung
von Monitoring-, Diagnose- und Datenreplikationsdiensten. Des Weiteren werden Grid
taugliche Entwicklungssysteme zur Verfügung gestellt, um bekannte Programmiermodelle
auch in der Grid-Umgebung verwenden zu können.
User applications. In dieser Schicht werden alle Anwendungen zusammengefasst, die
in der Umgebung einer virtuellen Organisation operieren. Die Dienste der unterliegenden
Schichten werden von Benutzeranwendungen aufgerufen und können Ressourcen transparent
verwenden.
1 http://www.globus.org/ogsa
7

2.1.4.2. Globus-Toolkit
2. Grundlagen
Das Globus-Toolkit 2 [23, 24] der Globus-Alliance 3 ist eine Middleware für Grid-Systeme.
Obwohl es sich noch in der Entwicklung befindet, setzen, wie auch das Instant-Grid-
Projekt, fast alle größeren Grid-Projekte auf dieses Toolkit auf. Es wird daher als Referenzimplementierung
der OGSA-Spezifikation in diesem Zusammenhang kurz beschrieben.
Das Globus-Projekt entstand aus einer Zusammenarbeit der University of Chicago und
der University of Southern California unter Beteiligung von IBM und der NASA. Es basiert
unter anderem auf den Erfahrungen anderer, zur Grid-Technologie verwandter Projekte
wie Condor[25], Codine[26], Legion[27], Nimrod[28] und Unicore[29]. Das GT4 bietet alle
notwendigen Komponenten zur Umsetzung von Grid-Systemen. Dies beinhaltet Bereiche
der Sicherheit und der Daten-, Ressourcen- sowie Aufgabenverwaltung. Des Weiteren bietet
es Schnittstellen und Bibliotheken für gängige Programmierumgebungen (s. Abb. 2.2).
Abbildung 2.2.: Komponenten des Globus-Toolkit 4 [30]
Security. Dieser Bereich umfasst Maßnahmen zur Authentifikation und Autorisierung
2 http://www.globus.org/toolkit
3 http://www.globus.org/alliance
8

2. Grundlagen
von Benutzern und Ressourcen. Die Kommunikation zwischen den Beteiligten wird abgesichert,
und Funktionen zur Verwaltung von Benutzer- und Gruppenrechten werden zur
Verfügung gestellt.
Data Management. Module in diesem Abschnitt ermöglichen es, verteilte Daten im Grid
zu lokalisieren (RLS), zu verschieben (GridFTP, RFT, DRS) und zu verwalten (OGSA-DAI).
Execution Management. Die Werkzeuge zur Ausführungsverwaltung befassen sich mit
der Initialisierung, Beobachtung, Planung und Koordination von verteilten Aufgaben. Von
diesem Service (GRAM) machen die Scheduling-Mechanismen vom FIRST (s. Kap. 2.3) intensiven
Gebrauch.
Information Services. Der Informationsdienst (MDS4) und die zusammenhängenden
Komponenten dienen der Überwachung und der Identifikation von Ressourcen und Diensten
im Grid. Der Dienst wird als Informationsquelle vom zu entwickelnden System genutzt
(s. Kap. 4).
Common Runtime. Die allgemeine Laufzeitumgebung dient der plattformunabhängigen
Implementierung der oben genannten Dienste. Es werden Bibliotheken bereitgestellt,
die die Erstellung von Abstraktionsschichten vereinfachen und die Umsetzung von Funktionalitäten
auf Basis von Web-Services (WSRF) bequem ermöglichen.
Die Installation und Konfiguration des GT4 erfordert aufgrund seiner Komplexität ein hohes
Maß an Fachkenntnis und einen deutlichen Zeitaufwand. Eine detaillierte Beschreibung
des Vorgangs findet sich unter anderem in [31, 32]. Einen einfachen Weg zur Demonstration
des Toolkits schlägt das Instant-Grid-Projekt ein.
2.2. Instant-Grid
2.2.1. Einleitung
Das Instant-Grid-Projekt der GWDG (nicht zu verwechseln mit [33]) ist ein Partnerprojekt
der D-Grid-Initiative 4 und wird vom Bundesministerium für Bildung und Forschung
finanziert. Die Entwicklung erfolgt durch die Gesellschaft für wissenschaftliche Datenverarbeitung
Göttingen. Unterstützt wird diese durch die Partner ed-media 5 , die FernUniver-
4 http://www.d-grid.de
5 http://ed-media.org
9

2. Grundlagen
sität in Hagen 6 , FIZ Chemie 7 und das FIRST 8 .
2.2.2. Zielsetzung
Das Ziel des Projektes ist, eine - auch ohne Vorkenntnisse einsetzbare - Demonstrationsumgebung
für Grid-Technologien bereit zu stellen. Zur Unterstützung der Bildung einer
allgemeinen und nachhaltigen Grid-Basis-Infrastruktur in Deutschland werden dabei die
selben Technologien und Software-Pakete verwendet, die im Rahmen der D-Grid-Initiative
empfohlen sind.
Die bereitgestellten Anwendungen sollen dem Benutzer das Potential von Grids näher
bringen und einen Einblick in die zugrunde liegende Grid-Technologien gewähren. Hierzu
gehört unter anderem die Demonstration des Leistungsgewinns bei der Verwendung verteilter
Berechnungen über die Grid-Architektur. Auf der deutschen e-Science-Konferenz 9
im Mai 2007 soll das Projekt als Demonstration von Grid- Funktionalitäten und Grid-
Anwendungen zum Einsatz kommen.
2.2.3. Architektur
Das Instant-Grid stellt eine CD-ROM (basierend auf Knoppix 10 ) zur Verfügung, mit der ein
x86-Rechner gestartet werden kann. Dieser Computer dient im weiteren Verlauf als Frontend
und stellt Mechanismen bereit, mit Hilfe derer weitere x86-Clients über das Netzwerk
initialisiert werden können (s. 2.3(a)).
Zu diesem Zweck werden während des Bootvorgangs auf dem Frontend DHCP-, TFTPund
NFS-Server eingerichtet und gestartet (s. Abb. 2.3(b)). Für die Verteilung weiterer
Konfigurationen wird ein zusätzlicher Dienst (Distributor) benötigt. Des Weiteren werden
alle Komponenten der Grid-Middleware (GT4) und ein Zertifizierungsdienst initialisiert.
Das Instant-Grid besteht aus verschiedenen Teilkomponenten, die jeweils in einer
GNU/Linux-Umgebung betrieben werden (s. Abb. 2.3(c)):
Instant-Grid Infrastructure. Die Infrastruktur, die im Rahmen des Instant-Grid-Projektes
geschaffen wurde, besteht hauptsächlich aus zwei Teilbereichen. Der „IP-Collector“ hat
unter anderem die Aufgabe, grundlegende Informationen über vorhandene Hardware-
Ressourcen im Grid zu aktualisieren. Dieser Dienst berührt inhaltlich Aspekte der vorliegenden
Arbeit und wird in Kapitel 3 nochmals erwähnt. Der „Distributor“ verteilt verschiedene
Konfigurationsinformationen innerhalb des Grids über die NFS-Dateistruktur.
6 http://www.fernuni-hagen.de
7 http://www.fiz-chemie.de
8 http://www.first.fraunhofer.de
9 http://www.ges2007.de
10 http://www.knopper.net/knoppix
10

2. Grundlagen
(a) Distributionsstruktur (b) Bootvorgang (c) Komponenten
Abbildung 2.3.: Architektur des Instant-Grid [34]
Globus Toolkit. Das GT4 und die damit zusammenhängenden Komponenten für die
Dateiübertragung (GridFTP), Job-Submitierung (WS-GRAM) und Identifikation von Ressourcen
und Diensten im Grid (MDS4) können vom Benutzer über die Kommandozeile
oder eine webbasierte Oberfläche gesteuert werden.
Apache. Neben der Kommandozeile ist die webbasierte Oberfläche, die über den Apache
HTTP-Server und den Apache Servlet-Container (Tomcat) bereitgestellt wird, die wichtigste
Schnittstelle zum Anwender. Die meisten Funktionen werden über das GridSphere-
Portal bereitgestellt. Zusätzlich werden Informationen über die Ressourcenauslastung von
Ganglia dargestellt und die Demonstrationsanwendung „POV-Ray“ gesteuert.
Die Verteilung und Administration von Aufgaben innerhalb des Grids erfolgt im Instant-
Grid direkt über die Schnittstelle (WS-GRAM) des GT4. Die Demonstrationsanwendungen
müssen jeweils geeignete Ressourcen selbst auswählen und Ergebnisse zusammenführen.
Zur Standardisierung und Erleichterung dieser Vorgänge wird ein Workflowmanagement-
System des FIRST in die derzeitige Infrastruktur integriert.
11

2.3. Grid-Workflowmanagement
2.3.1. Einleitung
2. Grundlagen
Das Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik (FIRST) engagiert
sich, neben der Tätigkeit als Projektpartner des Instant-Grids (IG), an verschiedenen anderen
Grid-Projekten. Dazu gehören das Fraunhofer IuK Resource-Grid 11 , K-Wf-Grid 12 , CoreGrid
13 und MediGrid 14 . Das FIRST entwickelt in diesem Zusammenhang den im Resource-Grid
entworfenen Job Handler zu einem generischen Workflowmanagement-System
für Grid-Anwendungen weiter. Teil dieses Vorhabens, welches im Rahmen des Grid Workflow
Forums 15 koordiniert wird, ist die Spezifikation einer Workflow- sowie Ressourcenbeschreibungssprache
und die Implementierung der hierzu notwendigen Middleware-
Komponenten. Das Workflow-System soll zukünftig auch im Instant-Grid Verwendung
finden.
2.3.2. Zielsetzung
Ziel des Workflowmanagement-Systems (WFMS) für Grid-Anwendungen ist die Verwaltung
und Automatisierung von komplexen Prozessabläufen in Grid-Umgebungen. Zur
Unabhängigkeit einer konkreten Infrastruktur soll dabei die Modellierung der Anwendungen
auf einer abstrakten Ebene erfolgen. Eine Kompatibilität sowohl zu Grid-Technologien
wie dem Globus-Toolkit, Condor oder Web-Services als auch zu Windows- und Unix-Betriebssystemen
soll gewährleistet sein. Eine intuitiv bedienbare Benutzerschnittstelle soll
den Anwender bei der Erzeugung und Bearbeitung von dynamischen Workflows unterstützen.
Des Weiteren soll die Prozessmodellierungssprache ausdrucksstark genug sein,
um die Struktur während der Laufzeit an die konkrete Grid-Infrastruktur anzupassen.
2.3.3. Architektur
Die Komponenten des WFMS und die Integration des Systems in die Infrastruktur des IG
sind in Abbildung 2.4(a) dargestellt und werden im Folgenden kurz erläutert.
GWorkflowDL. Die Grid Workflow Description Language ist eine Petri-Netz-basierte
XML-Beschreibungssprache für Prozessabläufe. Eine Eigenschaft ist die Unterstützung verschiedener
Abstraktionsebenen. So kann die Sprache zur Beschreibung von einfachen Kontrollaufgaben
bis hin zur Formulierung von ausführbaren Grid-Operationen verwendet
11 http://www.fhrg.fraunhofer.de
12 http://www.kwfgrid.net
13 http://www.coregrid.net
14 http://www.medigrid.de
15 http://www.gridworkflow.org
12

n
n
Run
Simple
Globus
Job
Run
Workflow
Assemble/
Monitor
Workflow
Application Portlet
(POV-Ray, ERAMAS)
Grid Workflow User
Interface (GWUI)
RSL (WS-GRAM)
GWorkflowDL
2. Grundlagen
Grid Portlet
GWorkflowDL
Grid Workflow Execution Service
(GWES)
Run
Simple
Globus
Job
Run
Workflow
Run Application
Grid Portlet
User
GResourceDL
GWorkflowDL
GResourceDL
GWorkflowDL
Resource
Matcher
Globus 4
GResourceDL
Web Service
Exist XML DB
Scheduler
Web Services
Ganglia
(a) Grid-Workflowmanagement-System des FIRST
Assemble/
Monitor
Workflow
Application Portlet
(POV-Ray, ERAMAS)
Grid Workflow User
Interface (GWUI)
RSL (WS-GRAM)
GWorkflowDL
Grid Portlet
GWorkflowDL
Grid Workflow Execution Service
(GWES)
Run Application
Grid Portlet
User
GResourceDL
GWorkflowDL
GResourceDL
GWorkflowDL
Resource
Matcher
Globus 4
GResourceDL
Web Service
Exist XML DB
Scheduler
Web Services
GRDL
GRDL
View Resources /
Control Daemon
Gangliia-
Connector
GRDB Portlet
GRDB Portlet
GRDB Daemon
GRDB Daemon
or
Ganglia MDS4
(b) Grid-Workflowmanagement-System mit Entwicklungen der vorliegenden Arbeit
Abbildung 2.4.: Architektur des Workflowmanagement-Systems [34]
13
MDS4-
Connector

werden (s. [35]).
2. Grundlagen
D-GRDL. Die D-Grid Resource Description Language ist eine XML-Beschreibung von
Ressourcen innerhalb eines Grids. Ziel der Spezifikation ist eine gemeinsame Sprache zu
definieren, die es erlaubt Ressourcen unterschiedlicher Grid-Infrastrukturen mit einem
einzigen Formalismus zu beschreiben (s. Anhang B.5).
XML DB. Die XML-Datenbank dient als Container und Austauschmedium für die Beschreibungen
der im Grid vorhandenen Ressourcen und der formulierten Prozesse.
Application Portlet. Das Portlet der jeweiligen Anwendung dient dem Benutzer als
Schnittstelle zur Applikation und generiert die notwendige Beschreibung der Prozessabläufe.
Im Rahmen des Instant-Grids werden dies voraussichtlich Pov-Ray und ERAMAS 16
sein.
GWUI. Das Grid Workflow User Interface unterstützt den Benutzer bei der Auswahl
von Diensten und der Erstellung komplexer Workflows für Grid-Anwendungen. Vorhandene
Prozessabläufe können visualisiert und komfortabel bearbeitet werden.
GWES. Der Grid Workflow Execution Service beinhaltet verschiedene Komponenten
unter anderem zur Analyse und Verifikation von Prozessabläufen und dient der Ausführung
von Programmen im Grid (s. [36]).
Resource Matcher. Der Resource Matcher sucht auf Grundlage der in der GWorkflowDL
angegebenen Eigenschaften passende Ressourcen zur Ausführung einer Anwendung aus.
Die jeweiligen Ressourcen, die zu überprüfen sind, wurden zuvor in der D-GRDL beschrieben
und befinden sich in der XML-Datenbank.
Scheduler. Der Scheduler optimiert auf Grundlage der Auslastungsinformationen aus
den D-GRDL-Beschreibungen der passenden Ressourcen und weiteren Angaben aus der
zugehörigen GWorkflowDL die Auswahl der Ressourcen für die Ausführung von Grid-
Anwendungen.
Der oben beschriebe Ansatz geht von bereits existierenden Beschreibungen der im Grid
vorhandenen Ressourcen aus. Diesem Teilaspekt widmet sich die vorliegende Arbeit und
ergänzt die vorhandene Architektur um weitere Komponenten (s. Abb. 2.4(b)). Eine detaillierte
Beschreibung des Systems, im Weiteren als Grid Resource Database (GRDB) bezeichnet,
findet sich in den folgenden Kapiteln.
16 http://www.eramas.de
14

3. Anforderungsanalyse
3.1. Einleitung
Gründe für das Scheitern von Software-Projekten gibt es viele. Empirische Untersuchungen
(siehe u.a. [37, 9]) haben ergeben, dass insbesondere unklare Anforderungen und die
fehlende Einbeziehung der Endnutzer zu den mit Abstand häufigsten Fehlern zählen. Die
Analyse, als Phase des Software-Entwicklungsprozesses, ist daher einer der wichtigsten
Schritte zum fertigen Produkt. Auch sorgen Ungenauigkeiten in den frühen Phasen des
Entwicklungsprozesses zu einem Summationseffekt, in dem sich Fehler fortpflanzen und
potenzieren. Die Dokumentation der Anforderungen dient daher allen an der Systementwicklung
Beteiligten als Kommunikations-, Diskussions- und Argumentationsgrundlage.
Ihre Aufgabe ist es, das gemeinsame Verständnis und Wissen der Teammitglieder widerzuspiegeln
(vgl. [10, 6]). Die Aufnahme und Erfassung der Anforderungen sollte vor allem
vollständig, verständlich und identifizierbar sein. Insbesondere die eindeutige Nummerierung
der Anforderungen und deren Qualifizierung helfen bei der Querreferenzierung und
der späteren Verifizierung und Abnahme des Produktes. Die Nummerierung erfolgt dabei
zunächst in Zehnerschritten, um ggf. zusätzliche Anforderungen nachtragen zu können.
Die Grundlagen der im Folgenden beschriebenen Anforderungen und Ziele ergaben sich
aus Interviews mit den jeweiligen Fachexperten, Anforderungsverantwortlichen und Systembetroffenen.
Durch die Wahl eines inkrementellen Entwicklungsprozesses wurden Erweiterungen
der Anforderungen im Laufe des Projektes unterstützt und auf Änderungen
konnte flexibel eingegangen werden.
3.2. Beschreibung der Systemidee und Zielsetzung
Die Formulierung der Systemidee ist das Ergebnis von Diskussionen innerhalb der Arbeitsgruppe
für Anwendungssysteme der GWDG. Diese wurde im Laufe von Gesprächen
mit Mitgliedern der Projektgruppe des FIRST ergänzt.
Das zu entwickelnde System soll die existierende Instant-Grid-Infrastruktur dahingehend
erweitern, dass eine einheitliche Ressourcen-Datenbank zur Verfügung steht. Diese soll
automatisch mit Daten über die im Grid vorhandenen Hardware-Ressourcen mittels existierender
Information-Provider aktualisiert werden. Die gesammelten Informationen sollen
in ein einheitliches Datenformat überführt und insbesondere eine Anbindung an das
15

3. Anforderungsanalyse
Instant-Grid-Portal geschaffen werden. In diesem Zusammenhang sind Bedienelemente
zur Benutzeroberfläche des Portals hinzuzufügen, um so eine Benutzer-Schnittstelle zur
Datenbank zu schaffen. Des Weiteren besteht eine enge Kooperation mit dem Institut für
Rechnerarchitektur und Softwaretechnik der Fraunhofer Gesellschaft. Die dort entwickelten
Systeme (insbesondere der Scheduler und Matcher) sollen direkten Zugriff auf diese
Datenbank haben und eine gemeinsame Datenbasis nutzen können.
3.3. Identifizierung der Anforderungsbeitragenden
Bevor detailliertere Anforderungen an das zu erstellende System erhoben werden können,
müssen alle wichtige Projektbeteiligte identifiziert und diesen geeignete Ansprechpartner
zugeordnet werden. Können nicht alle Mitwirkende eines Systems ermittelt werden, so
erhöht dies die Wahrscheinlichkeit, eine Vielzahl von Anforderungen nicht rechtzeitig zu
erkennen.
3.3.1. Stakeholder
Der Begriff Stakeholder (engl. Interessenvertreter) bezeichnet allgemein alle Projektbeteiligte,
die durch das entwickelte System direkt oder indirekt betroffen sind. Die in Abbildung
3.1 dargestellten Gruppen haben entscheidenden Einfluss auf die gestellten Anforderungen
an das System und nehmen im Laufe der Anforderungsanalyse eine zentrale Rolle
ein.
3.3.2. Ansprechpartner
Für die in Abbildung 3.1 dargestellten Stakeholdergruppen gilt es, anschließend die jeweiligen
Ansprechpartner zu identifizieren. Die Qualität der Analyseergebnisse ist insbesondere
von der Wahl der richtigen Ansprechpartner geprägt. Die korrekte Einordnung in die
entsprechenden Kompetenzbereiche hilft bei einer möglichst reibungslosen Kommunikation.
Die ermittelten Gesprächspartner sind in der Tabelle 3.1 aufgeführt.
3.4. Identifizierung der Interessen der Anforderungsbeitragenden
Nach der Identifikation der Anforderungsbeitragenden (s. Kap. 3.3.1 und 3.3.2) sind anschließend
deren grundsätzliche Interessen und Ziele zu ermitteln und zu dokumentieren.
So wird eine Basis zur weiteren Verfeinerung und Gliederung der Anforderungen geschaffen.
16

ud: Stakeholder
IG−Entwickler
3. Anforderungsanalyse
Ressourcen−Datenbank
Datenbank nutzen
Portal−Anwender
FIRST−Entwickler
Abbildung 3.1.: UML-Anwendungsfalldiagramm: ermittelte Stakeholder
Tabelle 3.1.: Projekt-Ansprechpartner
Verantwortliche Ansprechpartner
IG-Projektleiter Herr Dr. Ulrich Schwardmann von der GWDG
K-Wf-Grid-Projektleiter Herr Andreas Hoheisel vom Fraunhofer FIRST
Fachexperten Ansprechpartner
IG-Entwickler Herr Dr. Christian Boehme von der GWDG
FIRST-Entwickler Herr Andreas Hoheisel vom Fraunhofer FIRST
FIRST-
Beschreibungsentwickler
Herr Dr. Armin Wolf vom Fraunhofer FIRST
Systembetroffene Ansprechpartner
Portal-Anwender Herr Dr. Christian Boehme von der GWDG
17

3.4.1. Ziele und Interessen
3. Anforderungsanalyse
Die Dokumentation der Interessen bzw. der gewünschten Ziele der Anforderungsbeitragenden
findet sich in den Tabellen 3.2, 3.3 und 3.4). Die Aussagen werden in diesem Zusammenhang
noch nicht bewertet, sondern lediglich schriftlich festgehalten. Die Formulierungen
dienen jedoch der Generierung einer Übersicht aller Anwendungsfälle, die das
Verhalten des Systems nach außen wiedergeben. Die detaillierten Beschreibungen aller Anforderungen
sind in Kapitel 3.5 aufgeführt.
Tabelle 3.2.: Interessen der Anforderungsbeitragenden (IG-Entwickler)
Kennzeichnung Verbindlichkeit Beschreibung
/Z10/ Pflicht Nahtlose Integration des Systems in die vorhandene
Struktur.
/Z11/ Pflicht Keinerlei Benutzerinteraktionen für die Aktualisierung
der Ressourcen-Informationen.
/Z20/ Pflicht Bereitstellung der Ressourcen-Informationen
für andere Anwendungen, wie etwa den Grid-
Portlets.
Tabelle 3.3.: Interessen der Anforderungsbeitragenden (FIRST-Entwickler)
Kennzeichnung Verbindlichkeit Beschreibung
/Z30/ Pflicht Erhebung von dynamischen Informationen
über Hardware-Ressourcen (insbes. Auslastungsdaten).
/Z31/ Pflicht Bereitstellung einer Schnittstelle zur Kontrolle
der Informationsbeschaffung.
/Z32/ Pflicht Erhebung von Informationen über Software-
Ressourcen.
/Z40/ Pflicht Konformität der Datenbank zu XPath[38],
XQuery[39] und XUpdate[40].
/Z50/ Pflicht Datenaustausch mittels der vom FIRST spezifizierten
D-GRDL (siehe B.5).
/Z60/ Optional Verwendung der eXist XML-Datenbank.
18

3. Anforderungsanalyse
Tabelle 3.4.: Interessen der Anforderungsbeitragenden (Portal-Benutzer)
Kennzeichnung Verbindlichkeit Beschreibung
/Z70/ Pflicht Einfache Übersicht der existierenden
Hardware-Ressourcen.
/Z80/ Pflicht Anbindung an Workflow-Editor des FIRST.
/Z90/ Optional Graphische Darstellung der Auslastungsinformationen.
/Z100/ Pflicht Bereitstellung einer graphischen Schnittstelle
zur Kontrolle der Informationsbeschaffung.
3.4.2. Essenzielle Anwendungsfälle
Auf Grundlage der vorliegenden Informationen über die Ziele der Anforderungsbeitragenden
(s. Kap. 3.4.1) können nun essenzielle Anwendungsfälle abgeleitet werden. Diese
beschreiben das zukünftige System vereinfacht, sehr abstrakt und grundsätzlich unabhängig
von konkreten Implementierungen. Die in der Abbildung 3.2 dargestellten Anwendungsfälle
beziehen sich daher weniger auf konkrete Rahmenbedingungen und technologische
Gegebenheiten. Vielmehr konzentrieren sie sich auf die eigentliche fachliche Intention
und werden im weiteren Verlauf konkretisiert. Zur späteren Referenzierung sind die
Anwendungsfälle mit einer eindeutigen Bezeichnung (z.B. "/U10/") gekennzeichnet.
ud: Grundlegende Anwendungsfälle
Portal−Anwender
>
Information Provider
Ressourcen−Datenbank
Ressourceninformationen
darstellen (/U10/)
Ressourceninformations−
aktualisierung steuern (/U20/)
Ressourceninformationen
exportieren (/U30/)
Ressourceninformationen
auswerten (/U40/)
>
FIRST−Editor
>
FIRST−Scheduler
>
Grid Portlet
>
Zeitsteuerung
Abbildung 3.2.: UML-Anwendungsfalldiagramm: grundlegende Anwendungsfälle
19

3. Anforderungsanalyse
3.5. Beschreibung der Anforderungen
Die in Abbildung 3.2 dargestellten essenziellen Anwendungsfälle und in Kapitel 3.4.1 beschriebenen
Ziele bieten einen guten Rahmen und Einstiegspunkt zur Analyse und Beschreibung
der Anforderungen an das zu entwickelnde System. Methodische Richtlinien
und standardisierte Verfahren zur systematischen Anforderungsbeschreibung gibt es viele
(vgl. [41, 42, 43, 44]). Im Folgenden werden die Vorgaben aus dem Lehrbuch von Bernd
Oestereich[6] verwendet und durch weitere Angaben[10, 8, 45] ergänzt.
3.5.1. Probleme
Probleme des bestehenden Systems, die zu der Entwicklung des neuen Systems geführt
haben, sind in Tabelle 3.5 aufgeführt. Grundlage der formulierten Defizite sind die Erfahrungswerte
der IG-Entwickler. Die Priorisierung, in wie fern das neue System diese
Probleme beheben soll, findet sich in der Angabe der Verbindlichkeit.
Tabelle 3.5.: Anforderungsbeschreibung: vorhandenen Probleme
Nr. Verbindlichkeit Beschreibung
/P10/ Pflicht Die Darstellung von Ressourcen-
Informationen ist z.Z. nicht einheitlich
in das Portal integriert.
/P20/ Pflicht Eine Anbindung an Entwicklungen
des FIRST fehlt.
/P30/ Pflicht Es besteht z.Z. keine sinnvolle Verwendung
des MDS4.
/P40/ Optional Die Optionen zur Aktualisierung
von Ressourcen-Informationen
können derzeit nicht über eine
Webschnittstelle gesteuert werden.
/P50/ Optional Die derzeitige Umsetzung der
Aktualisierung von Ressourcen-
Informationen für die Grid-Portlets
könnte überarbeitet werden.
3.5.2. Funktionale Anforderungen
Die in Kapitel 3.4.1 beschriebenen Interessen ziehen funktionale Anforderungen an das
System nach sich. Diese beschreiben grundsätzlich die Interaktion eines technischen Systems
mit seiner Umgebung. Die entsprechenden Anforderungen werden in Tabelle 3.6 aufgelistet,
eindeutig gekennzeichnet, priorisiert und dem jeweiligen Ziel zugeordnet.
20

3. Anforderungsanalyse
Tabelle 3.6.: Anforderungsbeschreibung: funktionale Anforderungen
Nr. Verbindlichkeit Ziel Beschreibung
/F10/ Pflicht /Z10/ Integration des Systems in die
Paket- und Verzeichnisverwaltung
des IG.
/F20/ Pflicht /Z10/ Integration des Systems in den
Startvorgang des IG.
/F21/ Pflicht /Z20/ Bereitstellung der statischen
Informationen aus Information-
Providern.
/F30/ Pflicht /Z20/ Bereitstellung von Schnittstellen
für den Zugriff auf die Daten.
/F31/ Pflicht /Z31/ Bereitstellung von Schnittstellen
für die Steuerung der Informationsbeschaffung.
/F40/ Optional /Z20/ Aktualisierung der Ressourcen-
Informationen der Grid-Portlets.
/F50/ Pflicht /Z30/ Auswertung der statischen und
dynamischen Informationen über
Ressourcen aus Information-
Providern.
/F51/ Pflicht /Z32/ Erhebung von Informationen über
installierte Software-Ressourcen.
/F60/ Pflicht /Z40/ Nutzung einer XPath, XQuery
und XUpdate kompatiblen Datenbankstruktur.
/F70/ Pflicht /Z50/ Verwendung der D-GRDL zur Ressourcenbeschreibung.
/F80/ Pflicht /Z70/ Textuelle Darstellung der
Ressourcen-Informationen innerhalb
eines Portlets.
/F90/ Pflicht /Z70/ Graphische Darstellung der
Ressourcen-Informationen innerhalb
eines Portlets.
/F100/ Pflicht /Z80/ Bereitstellung einer Schnittstelle
zur Verknüpfung einer Ressourcen-
Darstellung.
21

3. Anforderungsanalyse
/F110/ Optional /Z90/ Graphische Darstellung von
Auslastungsinformationen über
ein Zeitintervall innerhalb eines
Portlets.
3.5.3. Produktdaten
Zur Realisierung der zuvor herausgearbeiteten, funktionalen Anforderungen (s. Kap. 3.5.2)
ist die Speicherung und Verwaltung von zugehörigen Daten notwendig. Die langfristig zu
speichernden Informationen zur Erfüllung der funktionalen Anforderungen werden in der
nachfolgenden Tabelle festgehalten.
Tabelle 3.7.: Anforderungsbeschreibung: zu speichernden Daten
Nr. Verbindlichkeit Funktion Beschreibung
/D10/ Pflicht /F21/ Name der Hardware-Ressource.
/D20/ Pflicht /F21/ IP der Hardware-Ressource.
/D30/ Pflicht /F50/ Freier Hauptspeicher der Hardware-Ressource.
/D40/ Pflicht /F50/ CPU-Durchschnittsbelastung der
Hardware-Ressource.
/D50/ Pflicht /F51/ Installierte Software auf der Hardware-Ressource.
/D60/ Abgrenzung /F51/ Installierte Software nicht dynamisch
ermitteln.
/D70/ Optional /F50/ Anzahl der CPUs der Hardware-
Ressource.
/D80/ Optional /F50/ CPU-Takt der Hardware-
Ressource.
/D90/ Optional /F50/ Größe des Hauptspeichers der
Hardware-Ressource.
/D100/ Optional /F21/ Rechnerarchitektur der Hardware-
Ressource.
3.5.4. Randbedingungen
Als Randbedingungen werden Aspekte der Anforderungsanalyse bezeichnet, die nicht
funktionaler Natur sind. Sie vervollständigen die Spezifikation, wirken unterstützend auf
die konfliktfreie Kommunikation mit den Anforderungsbeitragenden und sind hilfreich
beim Entwurfsprozess des Softwaresystems. In den folgenden Unterkapiteln werden nicht-
22

3. Anforderungsanalyse
funktionale Anforderungen aufgeführt, die im Rahmen des Projektes von Relevanz sind.
3.5.4.1. Technische Anforderungen
Aufgrund der Integration des zu entwickelnden Systems in eine bestehende Infrastruktur
und durch bereits beschlossene technische Erweiterungen, ist die Produktumgebung und
die Auswahl technischer Systeme bereits weitestgehend festgelegt. Die Analyse alternativer
Lösungswege ist daher nicht Inhalt der vorliegenden Arbeit, sollte jedoch in weiterführenden
Arbeiten in Betracht gezogen werden. Die beschriebenen Vorgaben sind in der
Tabelle 3.8 zusammengefasst.
Tabelle 3.8.: Randbedingungen: technische Anforderungen
Nr. Verbindlichkeit Beschreibung
/A10/ Pflicht Datenbank: eXist oder kompatible Lösung.
/A20/ Pflicht Portalsystem: GridSphere-Portalsystem.
/A21/ Pflicht Java-Container: Tomcat-Server.
/A30/ Pflicht Information-Provider: MDS4 und Ganglia.
/A40/ Pflicht Beschreibungssprache: D-GRDL.
3.5.4.2. Testanforderungen
Der Test der Anwendung ist integraler Bestandteil des verwendeten Entwicklungsprozesses.
Nachfolgend werden in Tabelle 3.9 spezifizierte Testfälle aufgezählt, die das Produkt
mindestens zu durchlaufen hat.
Tabelle 3.9.: Randbedingungen: Testanforderungen
Nr. Verbindlichkeit Beschreibung
/T10/ Pflicht Hinzufügen von Hardware-Ressourcen.
/T20/ Pflicht Entfernen von Hardware-Ressourcen.
/T30/ Pflicht Ausfall des Information-Providers.
/T40/ Pflicht Falsche Verwendung des Portlets.
/T50/ Optional Lasttest bzgl. des Abfrageintervalls.
/T60/ Optional Lasttest bzgl. der Anzahl an Hardware-
Ressourcen.
23

3. Anforderungsanalyse
3.6. Konkretisierung der Anwendungsfälle
Auf Basis der herausgearbeiteten Anforderungen an das System aus der Analyse in Kapitel
3.5 gilt es nun, die bereits in Abbildung 3.2 skizzierten Anwendungsfälle weiter zu
konkretisieren und zu beschreiben. Aufbauend auf der erweiterten Abbildung der Anwendungsfälle
(s. Abb. 3.3) werden diese im Folgenden anhand einer semi-formalen Vorlage
(angelehnt an [46]) beschrieben und das zugehörige Ablaufmodell angegeben. Das jeweilige
Ablaufmodell dient zum einen der Beschreibung der gegebenen Vorgänge des Anwendungsfalles,
zum anderen werden die Aktionspfade der Modelle zur Testfallgenerierung
verwendet. Dies dient der Validierung der Anwendung gegenüber der Anforderungsspezifikation
(s. Kap. 5.3).
24

ud: Vollständiges Anwendungsfalldiagramm
Portal−Anwender
>
Information Provider
Übersicht
darstellen (/U11/)
Aktualisierungs−
interval setzen (/U21/)
Resourceninformationen
auslesen (/U31/)
Ressourceninformationen
hinzugügen (/U41/)
3. Anforderungsanalyse
Ressourcen−Datenbank
Ressourceninformationen
darstellen (/U10/)
Ressourceninformations−
aktualisierung steuern (/U20/)
Information Provider
auswählen (/U23/)
Ressourceninformationen
exportieren (/U30/)
Ressourceninformationen
auswerten (/U40/)
Ressourceninformationen
aktualisieren (/U43/)
Ressource
darstellen (/U12/)
>
Aktualisierung
starten (/U22/)
Resourceninformationen
konvertieren (/U32/)
Ressourceninformationen
entfernen (/U42/)
>
FIRST−Editor
>
FIRST−Scheduler
>
Grid Portlet
>
Zeitsteuerung
Abbildung 3.3.: UML-Anwendungsfalldiagramm: Übersicht des zu entwickelnden Systems
25

3. Anforderungsanalyse
3.6.1. Anwendungsfall U10 (Ressourceninformationen darstellen)
3.6.1.1. Aktivitätsdiagramm
3.6.1.2. Konkretisierung U11
ad: U10 (R.informationen darstellen)
2. DB auslesen
(/U11/)
[Nein]
1. Mit DB verbinden
1.1 [OK]
Ressource
ausgewählt
[Ja]
2.1 [OK] 3.1 [OK]
R.informationen darstellen
1.2 [Fehler]
3. R.information auslesen
(/U12/)
2.2 {Fehler]
3.2 [Fehler]
Fehler darstellen
Abbildung 3.4.: UML-Aktivitätsdiagramm: Anwendungsfall U10
Tabelle 3.10.: Anwendungsfall U10: Konkretisierung U11
Name: Übersicht darstellen
Kurzbeschreibung Es werden statische und dynamische Informationen
über Hardware-Ressourcen dargestellt.
Akteure Portal-Nutzer.
Auslöser Der Nutzer öffnet eine entsprechende Seite des
Portals.
Eingehende Informationen
Ergebnisse Darstellung der Ressourcen-Information.
Ablauf 1. Nutzer öffnet entsprechende Portalseite.
2. Übersichtsseite wird dargestellt.
26

3.6.1.3. Konkretisierung U12
3. Anforderungsanalyse
Tabelle 3.11.: Anwendungsfall U10: Konkretisierung U12
Name: Ressource darstellen
Kurzbeschreibung Es werden statische und dynamische Informationen
über eine spezifische Hardware-
Ressource dargestellt.
Akteure Portal-Nutzer.
Auslöser Der Nutzer öffnet eine entsprechende Seite des
Portals.
Eingehende Informationen Eindeutige Kennung der Ressource.
Ergebnisse Darstellung der Ressourcen-Information.
Ablauf 1. Nutzer öffnet entsprechende Portalseite.
2. Auswahl einer Ressource.
3. Auswahl bestätigen.
3.6.2. Anwendungsfall U20 (Ressourceninformationsaktualisierung steuern)
3.6.2.1. Aktivitätsdiagramm
ad: U20 (R.inform.aktualisierung steuern)
1. Mit Steuerung verbinden
1.2 [Fehler]
1.1 [OK]
[Update starten]
[Interval setzen]
[IP auswählen]
2. Update starten (/U22/)
2.2 [Fehler]
Abbildung 3.5.: UML-Aktivitätsdiagramm: Anwendungsfall U20
27
3. IP auswählen (/U23/)
3.2 [Fehler]
4. Interval setzen (/U21/)
4.2 [Fehler]
2.1 [OK]
3.1 [OK]
2.1 [OK]
Update−Signal
Interval nicht gesetzt
Steuerung vollständig

3.6.2.2. Konkretisierung U21
3. Anforderungsanalyse
Tabelle 3.12.: Anwendungsfall U20: Konkretisierung U21
Name: Aktualisierungsintervall setzen
Kurzbeschreibung Änderung des Intervalls in dem die Daten der
Information-Provider ausgewertet werden.
Akteure Portal-Nutzer / Komponente des FIRST.
Auslöser Nutzer klickt auf ein entsprechendes Formular
/ Komponente ruft Funktion auf.
Eingehende Informationen Das neue Intervall in Sekunden.
Ergebnisse Setzen eines neuen Aktualisierungsintervalls.
Ablauf 1. Verbindung mit der Daemon-Steuerung (Portal
/ Funktion).
2. Auswahl eines neuen Intervalls.
3. Aufruf des Schnittstellenelements (Portal /
Funktion).
3.6.2.3. Konkretisierung U22
Tabelle 3.13.: Anwendungsfall U20: Konkretisierung U22
Name: Aktualisierung starten
Kurzbeschreibung Die Daten des Information-Providers sollen sofort
ausgewertet werden.
Akteure Portal-Nutzer / Komponente des FIRST.
Auslöser Nutzer klickt auf ein entsprechendes Formular
/ Komponente ruft Funktion auf.
Eingehende Informationen
Ergebnisse Einleitung der Aktualisierung der Daten und
Versenden eines Update-Signals an registrierte
Komponenten.
Ablauf 1. Verbindung mit der Daemon-Steuerung (Portal
/ Funktion).
2. Aufruf des Schnittstellenelements (Portal /
Funktion).
28

3.6.2.4. Konkretisierung U23
3. Anforderungsanalyse
Tabelle 3.14.: Anwendungsfall U20: Konkretisierung U23
Name: Information-Provider auswählen
Kurzbeschreibung Auswahl eines neuen Information-Providers.
Akteure Portal-Nutzer / Komponente des FIRST.
Auslöser Nutzer klickt auf ein entsprechendes Formular
/ Komponente ruft Funktion auf.
Eingehende Informationen Vollständiger Klassenname der neuen Verbindungskomponente.
Ergebnisse Änderung der Verbindungsklasse zum
Information-Provider.
Ablauf 1. Verbindung mit der Daemon-Steuerung (Portal
/ Funktion).
2. Auswahl der Verbindungskomponente.
3. Aufruf des Schnittstellenelements (Portal /
Funktion).
3.6.3. Anwendungsfall U30 (Ressourceninformationen exportieren)
3.6.3.1. Aktivitätsdiagramm
ad: U30 (R.informationen exportieren)
2.1 [OK]
Daten ausgelesen
1. Mit DB verbinden
1.1 [OK]
2. R.informationen auslesen
(/U31/)
[Datenexport]
Update−Signal
[Datenexport]
3. Daten konvertieren
(/U32/
3.1 [OK]
Daten konvertiert
1.2 [Fehler]
2.2 [Fehler]
3.2 [Fehler]
Fehlerrückgabe
Abbildung 3.6.: UML-Aktivitätsdiagramm: Anwendungsfall U30
29

3.6.3.2. Konkretisierung U31
3. Anforderungsanalyse
Tabelle 3.15.: Anwendungsfall U30: Konkretisierung U31
Name: Ressourceninformationen auslesen
Kurzbeschreibung Auslesen von Ressourcen-Informationen aus
der Datenbank.
Akteure Portal-Nutzer / Komponente des FIRST.
Auslöser Nutzer klickt auf ein entsprechendes Formular
/ Komponente ruft Funktion auf.
Eingehende Informationen (Optional) Die eindeutige Bezeichnung einer
Ressource.
Ergebnisse (Teil-)Auszug der Datenbankinhalte.
Ablauf 1. Verbindung mit der Datenbank.
2. (Optional) Auswahl einer Ressourcenbezeichnung.
3. Aufruf der Datenbank-Schnittstelle.
3.6.3.3. Konkretisierung U32
Tabelle 3.16.: Anwendungsfall U30: Konkretisierung U32
Name: Ressourceninformationen konvertieren
Kurzbeschreibung Exportieren von Ressourcen-Informationen aus
der Datenbank.
Akteure Softwarekomponente zur Konvertierung.
Auslöser Komponente ruft Funktion auf / Empfang eines
Update-Signals.
Eingehende Informationen (Optional) Die eindeutige Bezeichnung einer
Ressource
Ergebnisse (Teil-)Auszug der Datenbankinhalte.
Ablauf 1. Verbindung mit der Datenbank
2. (Optional) Auswahl einer Ressourcenbezeichnung.
3. Aufruf der Datenbank-Schnittstelle.
4. Konvertierung der Daten in gewünschtes
Format.
30

3.6.4. Anwendungsfall U40
3.6.4.1. Aktivitätsdiagramm
ad: U40 (R.information auswerten)
[Neue R.informationen]
6.1 [OK]
Ressource hinzugefügt
3. Anforderungsanalyse
1. Verbinden zum IP
1.1 [OK]
2. Informationen konvertieren
2.1 [OK]
3. Mit DB verbinden
3.1 [OK]
[Ressource entfernt]
4. Ressource hinzufügen
(/U41/)
5. Ressource entfernen
(/U42/)
6. R.information aktualisieren
(/U43/)
5.1[OK]
4.1 [OK]
[Neue Ressource]
5.2 [Fehler]
6.2 [Fehler]
Zeitsignal
1.2 [Fehler]
2.2 [Fehler]
3.2 [Fehler]
4.2 [Fehler]
Fehlerrückgabe
Abbildung 3.7.: UML-Aktivitätsdiagramm: Anwendungsfall U40
31

3.6.4.2. Konkretisierung U41
3. Anforderungsanalyse
Tabelle 3.17.: Anwendungsfall U40: Konkretisierung U41
Name: Ressourceninformationen hinzufügen
Kurzbeschreibung Aufnahme neuer Hardware-Ressourcen in die
Datenbank.
Akteure Information-Provider.
Auslöser Zeitsignal / Hinzufügen einer Hardware-
Ressource.
Eingehende Informationen Statische und dynamische Daten über die neue
Hardware-Ressource.
Ergebnisse Informationen über die neue Hardware-
Ressource werden in der Datenbank gespeichert.
Ablauf 1. Verbindung zum Information-Provider.
2. Konvertierung und Auswertung der Daten
des Information-Providers.
3. Verbindung zur Datenbank.
4. Einbinden der neuen Informationen in die
Datenbank.
3.6.4.3. Konkretisierung U42
Tabelle 3.18.: Anwendungsfall U40: Konkretisierung U42
Name: Ressourceninformationen entfernen
Kurzbeschreibung Entfernung einer Hardware-Ressource aus der
Datenbank.
Akteure Information-Provider.
Auslöser Zeitsignal / Entfernung einer Hardware-
Ressource.
Eingehende Informationen Ggf. Name der entfernten Hardware-
Ressource.
Ergebnisse Entfernung der Informationen der Hardware-
Ressource aus der Datenbank.
Ablauf 1. Verbindung zum Information-Provider.
2. Konvertierung und Auswertung der Daten
des Information-Providers.
3. Verbindung zur Datenbank.
32

3.6.4.4. Konkretisierung U43
3. Anforderungsanalyse
4. Löschen der Informationen aus der Datenbank.
Tabelle 3.19.: Anwendungsfall U40: Konkretisierung U43
Name: Ressourceninformationen aktualisieren
Kurzbeschreibung Aktualisierung der dynamischen Daten über
eine Hardware-Ressource.
Akteure Information-Provider.
Auslöser Zeitsignal.
Eingehende Informationen Eindeutige Bezeichnung der Hardware-
Ressource.
Ergebnisse Aktualisierung der Informationen der
Hardware-Ressource in der Datenbank.
Ablauf 1. Verbindung zum Information-Provider.
2. Konvertierung und Auswertung der Daten
des Information-Providers.
3. Verbindung zur Datenbank.
4. Aktualisierung der Informationen aus der
Datenbank.
3.7. Beschreibung der Systemschnittstelle
Nach der Analyse und Beschreibung der Anwendungsfälle können im nächsten Schritt
nun die Strukturelemente, die an der äußeren Systemgrenze liegen, identifiziert werden.
Dabei gilt es, die involvierten Schnittstellenelemente zu finden, die für Interaktionen des
zu entwickelnden Systems mit der Umgebung notwendig sind. In Tabelle 3.20 sind die
entsprechenden Schnittstellen für die herausgearbeiteten Anwendungsfälle aufgeführt.
Anwendungsfallschritt/aktivität
/U10/ (Ressourceninformationen
darstellen)
/U20/ (Ressourceninformationsaktualisierung
steuern)
/U30/ (Ressourceninformationen
exportieren)
Tabelle 3.20.: Zuordnung der involvierten Schnittstellen
Involvierte Schnittstelle
Dialog/Interface: Ressourcendarstellung I10
Dialog/Interface: Steuerung I20
Interface: Datenexport I30
33

U40/ (Ressourceninformationen
auswerten)
3. Anforderungsanalyse
3.7.1. Dialog/Interface I10 (Ressourcendarstellung)
Interface: Information-Provider-Treiber I40
Tabelle 3.21.: Dialog/Interface: Ressourcendarstellung I10
Name Ressourcendarstellung
Kurzbeschreibung Mit diesem Dialog kann der Benutzer eine Ressource
zur Darstellung auswählen.
Verwendung Zur Auswahl bei der Darstellung aller vorhandenen
Ressourcen und als Verknüpfung über den
Fraunhofer Workfloweditor.
Eingabefelder Eindeutige Bezeichnung der Ressource (z.B. über
die URL).
Anzeigefelder Eindeutige Bezeichnungen aller Ressourcen.
Verzweigungsmöglichkeit Zurück zur Übersicht aller Ressourcen.
Aktionen Reduzierung der Anzeige auf eine Ressource.
3.7.2. Dialog/Interface I20 (Steuerung)
Tabelle 3.22.: Dialog/Interface: Steuerung I20
Name Steuerung
Kurzbeschreibung Steuerung der Datenverwertung.
Verwendung Als Einstellmöglichkeit für jeden Portal-Benutzer
und als Interface für Komponenten des FIRST.
Eingabefelder Aktualisierungsintervall in Sekunden, Name des
zu verwendenden Information-Providers und
Aktualisierungsfunktion
Anzeigefelder Derzeitiges Aktualisierungsintervall, Name des
Information-Providers und eine Aktualisierungsfunktion.
Verzweigungsmöglichkeit Keine.
Aktionen Aktualisierung der Daten und Änderung des Aktualisierungsintervalls
und des Information Providers.
34

3.7.3. Interface I30 (Datenexport)
3. Anforderungsanalyse
Tabelle 3.23.: Interface: Datenexport I30
Name Datenexport
Kurzbeschreibung Export der in der Datenbank vorhandenen Daten.
Betroffene Systeme Komponente zur Anbindung der Grid-Portlets
und Komponenten des FIRST.
Eingabedaten Registrierungsinformationen zur Benachrichtigung.
Ausgabedaten Update-Signal und Datenbankinhalte.
3.7.4. Interface: I40 (Information-Provider-Treiber)
Tabelle 3.24.: Interface: Information-Provider-Treiber I40
Name Information-Provider-Treiber
Kurzbeschreibung Komponente zur Umwandlung und Strukturierung
von Daten eines Information-Providers.
Betroffene Systeme Information-Provider und eine Zeitsteuerung.
Eingabedaten Update-Signal und Daten des Information Providers.
Ausgabedaten Strukturierte Daten des Information-Providers.
35

4. Design
4.1. Einleitung
Unter dem Begriff „Design“ wird die kreative Erarbeitung eines Lösungskonzeptes für
ein Problem unter Berücksichtigung gegebener Rahmenbedingungen verstanden. Die vorausgegangene
Analyse des zu entwerfenden Systems (s. Kap. 3) bietet alle notwendigen
Informationen und Annahmen, um im weiteren Verlauf einen geeigneten Lösungsweg
aufzuzeigen und die Softwarearchitektur zu spezifizieren die in Abbildung 2.4 bereits angedeutet
wurde. In den folgenden Kapiteln werden daher — mit Bezug auf die entsprechenden
Ergebnisse der Anforderungsanalyse — Modelle, Komponenten und Schnittstellen
beschrieben, die als Grundlage der anschließenden Implementierung dienen. Das zu
entwickelnde System wird im weiteren Verlauf als “Grid Ressourcen Datenbank” (GRDB)
bezeichnet.
Bei der Konzeption der GRDB wird oftmals Gebrauch von verschiedenen Entwurfsmustern
gemacht. Dies gewährleistet die Wahl von etablierten und effizienten Lösungen zu
bekannten Problemen und unterstützt den Entwurf einer stabilen und erweiterbaren Architektur.
Ein Muster drückt nach Christopher Alexander 1 die Beziehung zwischen einem
Problem, seiner Lösung und einem Kontext aus. Diese Definition eines Entwurfsmusters
(engl. „design pattern“) aus dem Bereich des Bauwesens und der Architektur wurde Ende
der 80er Jahre von Erich Gamma in das Gebiet der Softwareentwicklung übernommen. In
seinem Buch[48] werden 23 Entwurfsmuster beschrieben. Die jeweiligen Muster sind unabhängig
von einer speziellen Programmiersprache zu betrachten und bieten vorgefertigte
und bewährte Lösungen für eine bestimmte Art von Entwurfsproblemen.
4.2. Anwendungsarchitektur
Als ersten Schritt wird die grundlegende Architektur der Anwendung festgelegt. Diese
bestimmt unter anderem, welche Arten von Klassen und Schnittstellen entworfen werden
müssen. Eine saubere Anwendungsarchitektur dient auch der sinnvollen Arbeitsaufteilung
innerhalb des Systems und gibt eine Übersicht der zu entwerfenden Komponenten.
In der Literatur werden, je nach Zielsetzung und Umgebung des zu entwickelnden Systems,
eine Vielzahl von möglichen Architekturmustern beschrieben[49]. Für den Entwurf
1 Architekt und Mathematiker und Autor des Buches „A Pattern Language“[47].
36

4. Design
eines interaktiven Systems mit graphischer Oberfläche, wie es die GRDB-Software eine ist
(/Z70 /Z80 /Z90 /Z100/), sind das Model-View-Controller- (MVC) und das Presentation--
Abstraction-Control-Entwurfsmuster (PAC) von Relevanz. Diese unterteilen das System
in Einheiten für die Darstellung und Benutzerinteraktionen, die Datenverwaltung und die
Steuerung. Das PAC-Muster geht jedoch noch einen Schritt weiter und segmentiert das
System nach Teilaufgaben in eine hierarchische Struktur, was für die geforderte Anwendung
nicht notwendig ist.
cd: Architekturübersicht
>
Java−Container / Portalsystem
−JSR 154 − / − JSR 168 −
(Tomcat) / (GridSphere)
Präsentationsschicht
Kontrollschicht
Datenschicht
>
Update−Listener
>
GRDB−
IP−Connector
>
Information−Provider
(Ganglia und MDS4)
>
GRDB−Daemon
>
GRDB−Portlet
GRDB−Servlet
>
GRDB−
DB−Connector
>
XML−Datenbank
− XPath / XQuery−
(eXist)
Kommunikation über
Datentransferobjekte
Abbildung 4.1.: UML-Komponentendiagramm: Architektur der GRDB-Anwendung
Die Abgrenzung einer Schicht zur Datenverwaltung ist aufgrund der geforderten, gemeinsamen
Datenbasis zwischen der GRDB und den Entwicklungen des FIRST (/Z40 /Z50
/Z60/) sinnvoll und notwendig. Ebenso ist die Darstellung und visuelle Steuerung von
der Aktualisierung der Informationen abzugrenzen, da diese ohne Benutzerinteraktion im
Hintergrund zu erfolgen hat (/Z11/). Die entwickelte Architektur der GRDB-Anwendung
(s. Abb. 4.1) spiegelt die Unterteilung in die erwähnten Bereiche wider. Von der Anwen-
37

4. Design
dung benötigte Fremdsysteme sind hierbei dunkel hinterlegt. Die jeweiligen Bausteine
greifen ausschließlich auf festgelegte Schnittstellen anderer Komponenten zu und sind
getrennt voneinander zu betrachten. Die Kommunikation erfolgt in der Regel über Datentransferobjekte,
die die notwendigen Informationen einheitlich und zur vereinfachten
Handhabung kapseln. Die Aufgaben der jeweiligen Schicht und ihrer Komponenten werden
im Folgenden kurz erläutert und anschließend in Form von Klassen- und Schnittstellenbeschreibungen
weiter detailliert.
4.3. Komponenten
4.3.1. Präsentationsschicht
Die Komponenten der Präsentationsschicht haben zur Aufgabe, dem Benutzer eine graphische
Benutzeroberfläche zur Verfügung zu stellen. Dies beinhaltet unter anderem die
Erstellung einer Übersicht von Hardware-Ressourcen (/Z70/) und die Steuerung der Informationsbeschaffung
(/P50 /Z100/).
Portalsystem. Technische Grundlage für die Realisierung der graphischen Oberfläche ist
der Einsatz des Apache Tomcat Servers und das GridSphere Portal-Systems (/A20 /A21
/F90/). Bei der Umsetzung des Systems wird jedoch ausschließlich auf die jeweiligen standardisierten
Schnittstellen JSR-154[50] und JSR-168[51] zugegriffen. Dies ermöglicht den
einfachen Austausch der eingesetzten Portallösung durch alternative Systeme.
GRDB-Portlet / GRDB-Servlet. Die Integration in das vorhandene Portalsystem (/P10 /Z10/)
erfolgt durch die Erweiterung der jeweiligen Servlet- und Portlet-Schnittstellen. Für die
Darstellung von erfassten Informationen (/F21 /F80 /F90 /I10/) ist der lesende Zugriff auf
die gespeicherten Daten über eine definierte Schnittstelle notwendig. Die Steuerung der
Informationsaktualisierung (/P40 /Z100 /F30 /I20/) bedingt den Zugriff auf Schnittstellen
der Kontrollschicht.
4.3.2. Kontrollschicht.
Die Kontrollschicht stellt den organisatorischen Kern der Anwendung dar. Eingehende
Benutzereingaben und Informationen der Information-Provider werden ausgewertet und
der notwendige Kontrollfluss gesteuert.
GRDB-Daemon. Der GRDB-Daemon steuert den Datenfluss des Systems und hat eine
Vielzahl von Aufgaben. Insbesondere werden erhobene Daten der Information-Provider
ausgelesen und eine Überführung der Informationen in die Datenbank veranlasst. Des
38

4. Design
Weiteren werden Benutzereingaben zur Steuerung der Information-Provider ausgewertet
und weitergeleitet.
Update-Listener. Durch einen Update-Mechanismus wird sichergestellt, dass externe Anwendungen
über neue Daten informiert werden (/P20 /P50 /Z20 /F30 /F40 /I30/). Eine Anwendung
kann sich beim GRDB-Daemon registrieren und erhält beim Eintreffen neuer
Daten automatisch ein entsprechendes Signal.
4.3.3. Datenschicht
Komponenten der Datenschicht haben die Aufgabe Informationen auszulesen und Daten
dauerhaft abzuspeichern. Die jeweiligen Elemente können einer Vielzahl von Kontrollund
Präsentationsschichten als Datenbasis dienen.
XML-Datenbank. Zur Speicherung der Informationen kommt die XML-Datenbank eXist
zum Einsatz (/Z60 /A10/). Der Zugriff auf die Datenbank erfolgt jedoch ausschließlich über
standardisierte Schnittstellen (/Z40 /F60/), so dass ein Austausch durch alternative Produkte
möglich ist. Die Datenbank stellt die wichtigste Schnittstelle zwischen der GRDB
und den Entwicklungen des FIRST dar. Auch andere Anwendungen können mit Hilfe der
Datenbank über Informationen zu gespeicherten Ressourcen in standardisierter Form verfügen.
(/Z20 /F30 /I30/).
GRDB-DB-Connector. Da die Informationen in der Datenbank intensiv vom FIRST genutzt
werden, müssen diese exakt den geforderten Spezifikationen (s. B.5) entsprechen
(/A40 /Z50 /F70/). Die Komponente hat daher die Aufgabe Informationen aus der Datenbank
in standardisierter Form auszulesen, abzulegen und zu modifizieren (s. Listing 4.1).
< resource xsi:noNamespaceSchemaLocation =
" http: // server:8080 / gwes / xsd / instantgrid -d- grdl . xsd "
uri =" hardware:moscow ">
< ofClass uri =" urn:dgrdl:hardware "/>
moscow
< simpleProperty ident =" WSRF . ManagedJobFactoryService "
type =" uri "
unit ="">
https: // moscow:8443 / wsrf / services / ManagedJobFactoryService
< simpleProperty ident =" CPUClockSpeed "
type =" int " unit =" mhz ">1695
< simpleProperty ident =" CPUInstructionSet "
type =" string " unit ="">x86
< simpleProperty ident =" CPUCount "
type =" int " unit =" pcs ">1
39

4. Design
< simpleProperty ident =" CPULoad15Min "
type =" int " unit =" percent ">24
< simpleProperty ident =" CPULoad5Min "
type =" int " unit =" percent ">18
< simpleProperty ident =" CPULoad1Min "
type =" int " unit =" percent ">98
< simpleProperty ident =" RAMPhysicalAvailable "
type =" int " unit ="mb">208
< simpleProperty ident =" RAMPhysicalSize "
type =" int " unit ="mb">501
< simpleProperty ident =" RAMVirtualAvailable "
type =" int " unit =" mhz ">1257
< simpleProperty ident =" RAMVirtualSize "
type =" int " unit =" mhz ">1557
< simpleProperty ident =" FSAvailable "
type =" int " unit ="mb">3
< simpleProperty ident =" FSSize "
type =" int " unit ="mb">1664
< simpleProperty ident =" FSReadOnly "
type =" string " unit =""/>
< simpleProperty ident =" NetIP "
type =" string " unit ="">172.24.127.249
< simpleProperty ident =" NetName "
type =" string " unit ="">moscow
< simpleProperty ident =" TimeStamp "
type =" float " unit =" msec ">1161009879
Listing 4.1: Beschreibung einer Hardware-Ressource
GRDB-IP-Connector. Der GRDB-IP-Connector hat zur Aufgabe, statische und dynamische
Daten (insbes. Auslastungsdaten) über im Netzwerk vorhandene Hardware-Ressourcen
(/Z30 /F50 /I40/) zu erheben. Ausgewertet werden unter anderem Name, IP, Größe und
Auslastung des Hauptspeichers, CPU-Durchschnittsbelastung, Anzahl der Prozessoren,
CPU-Takt und Architektur der jeweiligen Hardware-Ressource (/D10 /D20 /D30 /D40 /D70
/D80 /D90 /D100/). Des Weiteren werden statisch vorgegebene Software-Beschreibungen
eingebunden (/Z32 /D50 /D60/) und in die D-GRDL überführt (s. Listing 4.1). Als Quelle
können unterschiedliche Information-Provider dienen.
Information-Provider. Die notwendigen Information über in einem Grid bzw. Netzwerk
vorhandene Ressourcen liefern sogenannte Information-Provider (IP). Unterstützt werden
Ganglia
(/A30/) und MDS4 (/A30 /P30/), eine Erweiterung für weitere Information-Provider ist einfach
möglich.
40

4.4. Klassenmodell
4. Design
Aus den Phasen der Analyse und des Designs haben sich schon einige mögliche Operationen
ergeben, die bei weiterer Betrachtung und Detaillierung neue notwendige Methoden
aufzeigen. Die weitere Konkretisierung der Architektur mit Ihren Komponenten
hin zu einer groben Klassendefinition helfen bei der anschließenden Implementierung der
gewünschten Funktionen. Ebenso erleichtert die frühzeitige Festlegung von Schnittstellen
die Kommunikation zwischen den Projektpartnern. Die Einteilung der Anwendung erfolgt
in unterschiedliche Pakete (s. Abb. 4.2) die im Folgenden weiter ausgeführt werden.
Paket−Übersicht: grdb
daemon
(from org ::instantgrid ::grdb )
model
(from org ::instantgrid ::grdb )
portlet
(from org ::instantgrid ::grdb )
config
(from org ::instantgrid ::grdb )
test
(from org ::instantgrid ::grdb )
servlet
(from org ::instantgrid ::grdb )
Abbildung 4.2.: UML-Paketdiagramm: org.instantgrid.grdb
4.4.1. Paket: org.instantgrid.grdb.model
Das Paket org.instantgrid.grdb.model (s. Abb. 4.3) ist zuständig für die Datenverwaltung
und beinhaltet hauptsächlich die Schnittstelle zur Datenbank und Klassen zur internen
Datenkommunikation. Die in Listing 4.1 dargestellte Datenstruktur wird in der Klasse
GridResource gehalten und modifiziert. Die jeweiligen Instanzen der Klasse dienen
innerhalb des gesamten Systems als Austauschobjekt und werden lediglich in der Klasse
XmlDBConnector zur Speicherung in die Datenbank wieder in das D-GRDL-Format
überführt. Zur Erzeugung von GridResource-Objekten aus der Datenbank kommt das
„Erbauer-Entwurfsmuster“ mit der Klasse GridResourceFactory zum Einsatz.
41

Paket−Übersicht: model
GridResource
> + GridResource ():GridResource
+ setClassUri (classType :URI):void
+ getClassUri ():URI
+ setDescription (text :String ):void
+ getDescription ():String
+ setName (text :String ):void
+ getName ():String
+ getDbName ():String
+ getDbPrefix ():String
+ setUri (text :URI):void
+ getUri ():URI
+ addSimpleProperty (property :GridResourceSimpleProperty ):void
+ getSimpleProperty (propertyName :String ):GridResourceSimpleProperty
+ getSimpleProperties ():Collection
+ addResource (resource :URI):void
+ getResources ():Collection
+ toString ():String
+ clear ():void
+ getNode ():Node
+ setNode (xmlNode :Node ):void
product
>
> −GridResourceFactory ():anonym
+ getGridResources (document :Document ):List
Builder−Pattern
builder
4. Design
GridResourceSimpleProperty
> + GridResourceSimpleProperty ():GridResourceSimpleProperty
+ getName ():String
+ setName (string :String ):void
+ getType ():String
+ setType (string :String ):void
+ getUnit ():String
+ setUnit (string :String ):void
+ getValue ():String
+ setValue (string :String ):void
+ toString ():String
+ clear ():void
XmlDB
> + XmlDB():XmlDB
> + XmlDB(driver :String ,uri :URI):XmlDB
+ query (query :String ):Document
+ update (query :String ):long
+ storeGridResource (resource :GridResource ):void
+ createCollection (name :String ):Collection
+ removeCollection (name :String ):void
+ removeFile (name :String ):void
+ listFiles ():String[]
+ selectCollection (collectionName :String ):void
+ updateRessources (currentResources :List ):void
+ formatXML (xml :String ):String
+ transformXML (inout document :Document ,stylesheet :String ):Document
+ readXML(filename :String ):String
Abbildung 4.3.: UML-Paketdiagramm: org.instantgrid.grdb.model
4.4.2. Paket: org.instantgrid.grdb.daemon
Das Paket org.instantgrid.grdb.daemon (s. Abb. 4.4) beinhaltet den GRDB-Daemon,
GRDB-IP-Konnektoren und alle in diesem Zusammenhang notwendigen Schnittstellenbeschreibungen.
Die Schnittstelle zur Steuerung des GRDB-Daemons ist in dem Interface
GrdbDaemonInterface definiert. Das Aktualisierungsintervall und der Treiber für den Information-Provider
kann gesetzt und ausgelesen werden und die Einleitung einer sofortigen
Aktualisierung ist möglich. Des Weiteren können über die Schnittstelle direkt Daten
aus der Datenbank abgefragt werden.
Die Registrierung externer Systeme in den Aktualisierungsprozess wird über das „Beobachter-Entwurfsmuster“
und die Schnittstelle GrdbDaemonListener (/I30/) implementiert.
Erhält der GRDB-Daemon neue Daten vom Information-Provider, werden alle eingetragenen
Klassen über den Aufruf update() informiert. Zur einfachen Erweiterung des Systems
durch neue Konnektoren/Treiber für Information-Provider wird das „Adapter-Entwurfsmuster“
genutzt. Die Treiberklassen müssen lediglich die abstrakte Klasse AbstractGrdb-
Connector (/I40/) erweitern, die Funktion update() implementieren und die Daten in das
D-GRDL-Format überführen.
42

cd: Paket−Übersicht: daemon
Observer−Pattern
subject
observer
+ update ():void
>
GrdbDaemonInterface
>
GrdbDaemonListener
4. Design
+ setInterval (interval :int ):void
+ getInterval ():int
+ getDriver ():String
+ setDriver (driver :String ):void
+ update ():void
+ query (query :String ):Document
+ addListener (listener :GrdbDaemonListener ):void
+ removeListener (listener :GrdbDaemonListener ):void
+ notifyListeners ():void
GrdbDaemon
− listeners
− iProvider
client
AbstractGrdbConnector
+ getGrdlDocument ():Document
#setGrdlDocument (document :Document ):void
+ update ():void
MdsConnector
adapter
target
Adapter−Pattern
Abbildung 4.4.: UML-Paketdiagramm: org.instantgrid.grdb.daemon
4.4.3. Paket: org.instantgrid.grdb.portlet
GangliaConnector
Die Klassen für die graphische Oberflächengestaltung (/I10 /I20/) finden sich im Paket
org.instantgrid.grdb.portlet (s. Abb. 4.5). Zur einfachen Trennung von XHTML-Oberflächenbeschreibungen
und Java-Quelltexten wird die Klasse Template genutzt. Diese öffnet
entsprechende GUI-Dateien und ersetzt gegebene Zeichenketten durch Ergebnisse der
Klasse GrdbPortlet. Diese Klasse erweitert das GenericPortlet und hat damit Zugriff
auf alle Daten und Funktionen, die für die Benutzerinteraktion notwendig sind.
4.4.4. Paket: org.instantgrid.grdb.servlet
Zur Generierung von graphischen Auswertungen von Ressourcen-Informationen wird in
dem Paket org.instantgrid.grdb.servlet (s. Abb. 4.6) mit Hilfe der Klasse GrdbServlet
ein entsprechender Servlet-Service zur Verfügung gestellt. Diese Klasse wird in der graphischen
Oberfläche des Portlets als Graphik verknüpft und erhält Daten zum Namen der ausgewählten
Ressource und der darzustellenden Informationen. Die zuständige Werkzeug-
Klasse zur Generierung der Abbildungen ist die GridResourceChartFactory.
43
adapter

Paket−Übersicht: portlet
4. Design
GenericPortlet
GrdbPortlet
> + DaemonController ():void
+ doView (request :RenderRequest ,response :RenderResponse ):void
+ init (config :PortletConfig ):void
+ processAction (request :ActionRequest ,response :ActionResponse ):void
− template
Template
> + Template ():Template
> + Template (templateFile :String ):Template
+ open (templateFile :String ):void
+ toString ():String
+ set(tagString :String ,replaceString :String ):void
Abbildung 4.5.: UML-Paketdiagramm: org.instantgrid.grdb.portlet
cd: Paket−Übersicht: servlet
HttpServlet
GrdbServlet
+ doGet (req :HttpServletRequest ,res:HttpServletResponse ):void
−writeChart (request :HttpServletRequest ,response :HttpServletResponse ):void
>
GridResourceChartFactory
> −GridResourceChartFactory ():GridResourceChartFactory
+ createFsChart (resource :GridResource ,outputStream :OutputStream ):void
+ createMemoryChart (resource :GridResource ,outputStream :OutputStream ):void
+ createLoadChart (resource :GridResource ,outputStream :OutputStream ):void
Abbildung 4.6.: UML-Paketdiagramm: org.instantgrid.grdb.servlet
44

4.4.5. Paket: org.instantgrid.grdb.config
4. Design
Die Konfiguration der Anwendung erfolgt durch die Werkzeug-Klasse Config im Paket
org.instantgrid.grdb.config (s. Abb. 4.7). Diese wertet die Datei grdb.properties aus,
die Informationen zu Zugangsdaten, Verzeichnisse und Parameter enthält. Des Weiteren
ist durch die Werkzeug-Klasse I18N eine Unterstützung für die Internationalisierung der
Portlet-Oberfläche bereits implementiert.
cd: Paket−Übersicht: config
>
Config
> −Config ():Config
+ getString (key:String ):String
>
I18N
> −I18N ():I18N
+ getString (key:String ,language :String ):String
Abbildung 4.7.: UML-Paketdiagramm: org.instantgrid.grdb.config
4.4.6. Paket: org.instantgrid.grdb.test
Die implementierten Klassentests finden sich in dem Paket org.instantgrid.grdb.test (s.
Abb. 4.8). Soweit möglich sollte jede implementierte Funktion einen Test besitzen. Mindestens
jedoch müssen die definierten Testziele (/T10 /T20 /T30 /T40/) erreicht werden. Siehe
auch Kapitel 5.2 und 5.3.
cd: Paket−Übersicht: test
DaemonTest
> + DaemonTest (name :String ):DaemonTest
+ suite ():Test
#runTest ():void
+ testMdsConnector ():void
+ testDaemon ():void
+ update ():void
+ isInvoked ():boolean
GrdbDaemonListernerStub
+ main (args :String[] ):void
+ suite ():Test
AllTests
ConfigTest
> + ConfigTest (name :String ):ConfigTest
+ suite ():Test
#runTest ():void
+ testGetString ():void
+ testGetTranslation ():void
Abbildung 4.8.: UML-Paketdiagramm: org.instantgrid.grdb.test
45
ModelTest
> + ModelTest (name :String ):ModelTest
+ suite ():Test
#runTest ():void
+ testXmlDB ():void
+ testResource ():void
+ testObjects ():void

5. Implementierung und Test
5.1. Implementierung
Die erfolgte Implementierung des in Abschnitt 4 entworfenen Systems soll kurz erläutert
werden. Dazu wird auf die beiden Hauptkomponenten, das GRDB-Portlet und den
GRDB-Daemon, eingegangen und die Integration in die vorhandene Systemstruktur des
IG beschrieben.
5.1.1. Integration
Die Installation der entwickelten Anwendung erfolgt, wie im IG für Zusatzapplikationen
vorgesehen, über das Einspielen eines Debian-Pakets mit jeweiligen vor- und nachgeschalteten
Installationsskripten (/Z10/F10/F20/). Die Änderungen, die das Paket an der
Verzeichnis- und Dateistruktur der CD-ROM des Instant-Grid-Projektes vornimmt, werden
im Weiteren beschrieben. Die Schilderung jeder einzelnen Datei würde den Rahmen
dieser Arbeit jedoch sprengen, daher werden Inhalte weniger relevanter Verzeichnisse ausgespart.
Verzeichnis: /etc/
• Datei: ./init.d/grdbd Link zum Startskript „grdbd.init.debian“ (s.u.).
• Datei: ./ig-software.xml D-GRDL-Beispielbeschreibungen von Softwarekomponenten.
Diese Datei wird vom GRDB-Daemon eingelesen und der Inhalt regelmäßig in
die Datenbank überführt (/F51/).
Verzeichnis: /usr/local/instant-grid-tomcat5/init
• Datei: ./grdbd-init.sh Link zu der Konfigurationsdatei „grdbd.config“ (s.u.) zur Initialisierung
der notwendigen Umgebungsvariablen.
Verzeichnis: $CATALINA_HOME/webapps/grdb
• Verzeichnis: ./css Cascading-Stylesheet-Angaben für das Portlet und die Übersichtsseite.
46

5. Implementierung und Test
• Verzeichnis: ./docs Dokumentation und weitere Informationen zum System.
• Verzeichnis: ./exampledata Beispieldaten von D-GRDL-, Ganglia- und GLUE-Beschreibungen.
• Verzeichnis: ./images Bilder für die Übersichtsseite der Anwendung.
• Verzeichnis: ./logs Ausgabeverzeichnis für Protokolle des GRDB-Daemons.
• Verzeichnis: ./META-INF Meta-Informationen des entsprechenden WAR-Archives.
• Verzeichnis: ./shell Start- und Konfigurationsskripte des Systems (s.u.).
• Verzeichnis: ./WEB-INF Meta-Informationen über das Portlet.
• Verzeichnis: ./wsdd Web Service Deployment Deskriptoren zur Nutzung von WSRF-
Diensten wie MDS4.
• Verzeichnis: ./xhtml XHTML-Template-Dateien für das Portlet.
• Verzeichnis: ./xmlschema XML-Schema-Definitionen der verwendeten XML-Beschreibungssprachen.
• Verzeichnis: ./xquery Die benötigten XQuery-Abfragen sind aus der Anwendung
ausgelagert und somit einfach über dieses Verzeichnis zu modifizieren.
• Verzeichnis: ./xslt XSLT-Skripte zur Umwandlung verschiedener XML-Eingaben.
• Datei: ./build.properties Enthält die Versionsnummer des Projektes für die Integration
ins IG und weitere Informationen zur Compilierung.
• Datei: ./grdbd.javapolicy Berechtigungsangaben des GRDB-Daemon für das Java Sicherheitsmodell.
Diese Datei wird im Rahmen der IG-Tomcat-Init-Skripte eingelesen.
• Datei: ./grdb.javapolicy Berechtigungsangaben des GRDB-Portlets für das Java Sicherheitsmodell.
Diese Datei wird im Rahmen der IG-Tomcat-Init-Skripte eingelesen.
• Datei: ./ig-software.xml Link zu der gleichnamigen Datei im Verzeichnis /etc/ (s.o.).
• Datei: ./index.html Beschreibung und Übersicht der Anwendung.
• Datei: ./LICENCE Lizenzbestimmungen (GPL-Lizenz).
47

5. Implementierung und Test
Verzeichnis: $CATALINA_HOME/webapps/grdb/shell
• Datei: ./grdbd.config Umgebungsvariablen für Portlet und Daemon.
• Datei: ./grdbd.import-cert.sh Skript zur Unterstützung des Imports der Grid-Zertifikate
zum Java-Zertifikatscontainer. Der Import ist notwendig, um auf abgesicherte
WSRF-Dienste wie MDS4 zugreifen zu können. Dies wird im Rahmen des IG jedoch
nicht benötigt.
• Datei: ./grdbd.init.debian.sh GNU/Linux-Init-Skript für Debian Systeme.
• Datei: ./grdbd.init.suse.sh GNU/Linux-Init-Skript für SuSE Systeme.
• Datei: ./grdbd-lokal.sh Skript zur Unterstützung des manuellen Aufrufs des GRDB-
Daemons.
• Datei: ./grdbd.sh Start-Skript des GRDB-Daemons.
• Datei: ./queryDpkg.sh Skript zur Konvertierung von Debian-Paketmanagementinformationen
in eine XML-Darstellung. Wird im Rahmen des IG jedoch nicht benötigt.
5.1.2. Daemon
Der GRDB-Daemon ist ein Kernstück des entwickelten Systems. Er wird während des
Startvorgangs des IG initialisiert und geht im Hintergrund seinen Tätigkeiten nach (/Z11/).
Die Hauptaufgabe des Daemons ist die Abfrage eines Information-Providers zu Daten von
im Grid vorhandenen Hardware-Ressourcen und die Speicherung dieser Informationen in
der Datenbank (s. Kap. 4).
Neben Programmierschnittstellen zur Steuerung und Nutzung des Dienstes existiert eine
Kommandozeilenschnittstelle die es dem Anwender erlaubt, das Verhalten des Daemons
beim Start zu beeinflussen (s. Listing 5.1). Die notwendigen Skripte zur Ausführung
der Komponente finden sich im Verzeichnis $CATALINA_HOME / webapps / grdb /
shell.
knoppix@server : shell > ./ grdbd - lokal .sh -- help
usage : class org . instantgrid . grdb . daemon . GrdbDaemon
-d,-- driver The driver for the Information - Provider
-h,-- help This help
-i,-- interval The interval in seconds for polling the
Information - Provider
-n,--no - loop Runs the daemon only once (i.e. for
debugging and testing )
-p,-- port The listener port for the daemon
Listing 5.1: Kommandozeilenschnittstelle des Daemons
48

5.1.3. Portlet
5.1.3.1. Die Oberfläche
5. Implementierung und Test
Die Oberfläche des GRDB-Portlets (s. Abb. B.1) stellt die wichtigste Schnittstelle zum Benutzer
dar (/Z31/Z100/). Sie ist nahtlos in die Oberfläche anderer IG-Anwendungen integriert
und dient sowohl der Auskunft über Hardware-Ressourcen als auch der Steuerung
des GRDB-Daemons. Die graphische Anwenderschnittstelle ist in insgesamt vier Teilabschnitte
untergliedert, die im Folgenden kurz beschrieben werden.
5.1.3.2. Übersicht und Auswahl der Hardware-Ressourcen
Die im Grid vorhandenen Hardware-Ressourcen werden in dem Feld „Available hardware
resources“ dargestellt (s. Abb. 5.1). Jede Zeile enthält Informationen über den Namen,
die CPU-Auslastung und den freien Haupt- sowie Festplattenspeicher der Ressource
(/Z70/I10/). Die Zeile mit der Beschriftung „Total“ enthält hingegen die Summe bzw. den
Durchschnitt aller Daten der dargestellten Ressourcen. Weiter besteht die Möglichkeit die
Liste nach den angegebenen Kategorien auf- und absteigend zu sortieren.
Abbildung 5.1.: Screenshot: Ressourcenübersicht und -auswahl im Portlet
Wird der Name einer Ressource ausgewählt, so beziehen sich anschließend alle Informationen
der Seite auf sie. Anwendung findet diese Möglichkeit zum Beispiel bei der Verknüpfung
des Fraunhofer Workflow-Editors mit der GRDB-Oberfläche (/Z80/P20/F100/).
Die Auswahl einer geeigneten Ressource kann daher auch direkt über die URL der Seite
erfolgen (s. Listing 5.2). Dabei gilt es die Zeichenkette RESOURCE_ID durch die eindeutige
Kennzeichnung einer Hardware-Ressource zu ersetzen.
49

5. Implementierung und Test
http :// server :8080/ gridsphere / gridsphere /? cid = grdbtab & resourceID = RESOURCE_ID
Listing 5.2: Auswahl einer Ressource über die URL
5.1.3.3. Visualisierung der Auslastungsinformationen
Um einen schnellen und intuitiv begreifbaren Überblick über den Status der Hardware-
Ressourcen im Grid zu erhalten (/P10 /Z90 /F90/), werden auf der rechten Seite der Oberfläche
ausgewählte Auslastungsinformationen graphisch aufbereitet dargestellt (s. Abb.
5.2). Grundlage dieser Daten ist entweder die gebildete Summe bzw. der Durchschnitt aller
Ressourcen-Informationen oder die Daten einer zuvor ausgewählten Hardware-Ressource.
(a) CPU-Auslastung (b) Hautspeicher-Auslastung (c) Festplatten-Auslastung
Abbildung 5.2.: Screenshots: Graphische Auswertung der Auslastungsinformationen
5.1.3.4. Steuerung des GRDB-Daemons
Neben der Anzeige von Ressourcen-Informationen kann über die graphische Oberfläche
auch der GRDB-Daemon gesteuert werden (s. Abb. 5.3). In dem Feld „Daemon controller“
wird der Zugriffspfad auf den GRDB-Daemon angegeben und aktuelle Daten können
angefordert werden. Des Weiteren ist es möglich, das Intervall für die automatische Aktualisierung
der Ressourcen-Informationen anzugeben. Als dritter Punkt wird eine Auswahl
verschiedener Information-Provider (derzeit Ganglia und MDS4) gegeben zu denen im
laufenden Betrieb gewechselt werden kann (/P40 /I20 /P40 /F31/).
Abbildung 5.3.: Screenshot: Daemon-Controller im Portlet
50

5.1.3.5. Auflistung der Details
5. Implementierung und Test
Die Darstellung der Informationen basiert auf Daten, die in der Datenbank in Form der
D-GRDL gespeichert sind. Eine der wichtigsten Eigenschaften der verwendeten Beschreibungssprache
ist ihre Erweiterbarkeit. Auf der Oberfläche können, auch aufgrund der
Übersichtlichkeit, daher nicht alle Informationen graphisch wiedergegeben werden. Das
Feld „XML result“ stellt dem interessierten Benutzer daher die verwendeten Eingabedaten
für die Oberflächengenerierung zur Verfügung (s. Abb. 5.4). Wurde zuvor eine Hardware-
Ressource zur Darstellung ausgewählt, so werden lediglich Informationen über diese aufgelistet
(/I30/F80/).
5.2. Statische Testverfahren
Abbildung 5.4.: Screenshot: XML-Details im Portlet
Werkzeuggestützte Quelltextanalysen können sehr erfolgreich zur Qualitätssteigerung von
Software-Projekten eingesetzt werden. Das Ziel der Untersuchungen ist die Ermittlung
von potentiellen Fehlern und Verstößen gegen vorhandene Spezifikationen. Mängel und
Abweichungen sollen hierbei so früh wie möglich erkannt werden, noch bevor sie im weiteren
Verlauf der Softwareentwicklung zum Tragen kommen (vgl. [52, 53]). Im Rahmen
dieser Arbeit kamen daher verschiedene Analysewerkzeuge zum Einsatz, um die Qualität
des zu entwickelnden Systems gewährleisten zu können.
5.2.1. Kodierungsrichtlinien
Einleitung
Fehler, die ein Programmierer während der Implementierung macht, sind häufig auf Eigenheiten
der menschlichen Wahrnehmung zurückzuführen. Mit dieser Thematik haben
51

5. Implementierung und Test
sich unter anderem Weinberg[54], Schneiderman[55] und Grams[56] befasst. Demnach lassen
sich durch die Beachtung einiger Regeln viele Fehler vermeiden. Insbesondere die
Verwendung von Kodierungsrichtlinien und automatisierten Testverfahren können eine
Vielzahl von Fehlern vermeiden (vgl. [8]).
Im Rahmen dieser Arbeit wurde auf die strikte Einhaltung der „Code Conventions for
the Java Programming Language“ 1 von Sun geachtet. Das Unternehmen führt zusätzlich
folgende Gründe für die Verwendung der Richtlinien an:
• 80% der Kosten innerhalb der Lebenszeit einer Software besteht aus Wartung.
• Die meiste Software wird im Laufe ihrer Lebensspanne in der Regel nicht nur vom
ursprünglichen Autor gewartet.
• Kodierungsrichtlinien erhöhen die Lesbarkeit von Software und erlauben Entwicklern
ein schnelleres Verständnis von unbekannten Quelltexten.
• Der Quelltext eines Programmes sollte ebenso einheitlich und strukturiert sein wie
das Produkt selbst.
Verwendete Software
Zur Einhaltung der oben genannten Kodierungsrichtlinien wurde die Software Checkstyle
2 verwendet. Das Programm unterstützt den Entwickler bei der automatischen Überprüfung
aller Quelltexte gegen diverse Kodierungsrichtlinien. Zur Optimierung des Ablaufes
wurde Checkstyle in die Entwicklungsumgebung integriert, damit direkt bei der Eingabe
Verstöße gemeldet und eine einfache projektweite Analyse der Codes ermöglicht werden
konnte.
5.2.2. Bug-Patterns
Einleitung
Analog zu Entwurfsmustern im Softwareentwurf, die die Software im positiven Sinne
strukturieren, existieren Muster, die auf eine fehlerhafte Ausführung hindeuten. Die Erkenntnis
der Vielzahl von Ausdrücken in einer Programmiersprache, die möglicherweise
ein unerwünschtes Verhalten hervorrufen, ist aus Erfahrungen größerer und kleinerer
Projekte der letzten Jahrzehnte hervorgegangen. Zu häufig auftretenden Fehlern gehören
beispielsweise Nullzeigerdereferenzierungen oder ungültige Vergleiche von Zeichenkettenobjekten.
Software-Systeme, die Programme auf diese und ähnliche Fehler hin untersuchen,
verwenden hierzu Verfahren zur Daten- und Kontrollflussanalyse im Quelltext oder
1 http://java.sun.com/docs/codeconv
2 http://checkstyle.sourceforge.net
52

5. Implementierung und Test
Objektcode. Bug-Patterns werden ausführlich anhand der Programmiersprache Java in einem
Buch von E. Allen[57] beschrieben.
Verwendete Software
Eine detaillierte Analyse verschiedener Softwaresysteme für statische Testverfahren findet
sich in [58]. Die Tabelle 5.1 gibt einen komprimierten Vergleich der in dieser Arbeit verwendeten
Software wieder. Die jeweiligen Anwendungen konnten in die Entwicklungsumgebung
integriert werden, um, wie bei der Überprüfung auf Einhaltung der Kodierungsrichtlinien,
auch hier während der Programmierung direkt den Entwicklungsprozess zu
unterstützen.
Tabelle 5.1.: Analysierte Fehlertypen. Angelehnt an [58].
Kategorie Beispiel FindBugs JLint PMD Lint4J
Allgemeines Nullzeigerreferenzierung x x x x
Nebenläufigkeit Auftritt von Deadlocks x x x x
Array Länge kleiner 0 x x o o
Mathematik Division durch Null o x o o
Bedingungen Unerreichbarer Code x o x x
Zeichenketten Stringvergleich mittels == x x x x
E/A-Ströme Nicht geschlossener Strom x o o o
Ungenutzte Anw. Ungenutzte lokale Variable x o x x
Entwurf Leerer Konstruktor x o x x
Unnötige Anw. Unnötiger Rückgabewert o o x x
Performance Objekterzeugung in Schleifen x o x x
FindBugs. FindBugs 3 [59] ist ein Erkennungsystem von Bug-Patterns für Java. Es nutzt
verschiedene Techniken, um Präzision, Effizienz und Benutzbarkeit zu vereinen. Ein Hauptmerkmal
ist die Verwendung von abstrakten Syntax-Bäumen (ähnlich zu [60]), um verdächtige
Quelltextabschnitte zu identifizieren. In vielen Fällen werden auch Datenflussanalysen
durchgeführt, etwa um Nullzeigerreferenzierung zu entdecken.
JLint. JLint 4 [61] analysiert syntaktisch, wie FindBugs, den Java Bytecode und überprüft
den Datenfluss im Programm. JLint erstellt zusätzlich einen Graphen aller Blockierungen,
um zyklische Wiederholungen in diesem zu entdecken. Dies ermöglicht die Aufdeckung
3 http://findbugs.sourceforge.net
4 http://jlint.sourceforge.net
53

5. Implementierung und Test
von möglichen Deadlocks. Des Weiteren beinhaltet das Programm Analysen für Abhängigkeiten
von Threads innerhalb einer Applikation.
PMD. Die Funktionsweise von PMD 5 entspricht grundsätzlich der von FindBugs und
JLint, jedoch ohne Datenflussanalyse. PMD untersucht den Quelltext aber zusätzlich nach
Kodierungsrichtlinien, die ebenfalls eine fehlerhafte, oder aber zumindest eine unsaubere
Programmierung vermuten lassen.
Lint4J. Auch Lint4J 6 untersucht den Quelltext und Bytecode nach Problemen bzgl. der
Performance, Skalierbarkeit und Threadsicherheit, analysiert den Datenfluss und erstellt
Blockierungsgraphen. Die durchgeführten Analysen basieren laut Aussagen des Herstellers
auf Erfahrungswerten, die während der Implementierung von Performance- und sicherheitskritischen
Anwendungen gewonnen wurden.
Neben diesen Programmen existieren weitere Überprüfungssysteme wie z.B. Bandera 7 [62]
und ESC/Java 8 [63], welche jedoch deutlich weitergehende Ansätze verfolgen. Diese basieren
auf Beweisen von zuvor bestimmten, formalen Vor- und Nachbedingungen (vgl.
[64, 65]) und Verifikation von Zustandsmodellen. Aufgrund der hohen Komplexität und
des wissenschaftlichen Schwerpunkts dieser Möglichkeiten wurde von deren Nutzung im
Rahmen dieser Arbeit abgesehen.
5.2.3. Bewertung
Der Einsatz statischer, automatisierter Analyseverfahren hat deutlich zur Lesbarkeit und
Qualität der geschriebenen Quelltexte beigetragen. Insbesondere die Integration in die Entwicklungsumgebung
erleichterte den Umgang wesentlich und Hinweise konnten sofort
umgesetzt werden. Diese Hinweise waren aufgrund der hohen Zahl an formalisierten Erfahrungen
zu weit verbreiteten und häufig gemachten Fehlern sehr zahlreich und führten
zu einem ständigen Lernprozess während der Entwicklung. So wurden insbesondere
robustere und effizientere Lösungen implementiert, deren Funktionsweise im Anschluss
durch dynamische Testfälle überprüft werden konnten.
Es liegt jedoch in der Natur der Sache, dass nicht alle Meldungen zu Quelltextabschnitten
auf existierende Probleme oder Fehler hinweisen. Je nach Kontext sind verschiedene,
gleichwertige Lösungsansätze möglich und Falschmeldungen sind nicht gänzlich zu vermeiden.
5 http://pmd.sourceforge.net
6 http://www.jutils.com
7 http://bandera.projects.cis.ksu.edu
8 http://secure.ucd.ie/products/opensource/ESCJava
54

5.3. Dynamische Testverfahren
5.3.1. Einleitung
5. Implementierung und Test
Unter dynamischen Testverfahren wird das Testen von Software durch Ausführung von
Testobjekten beschrieben. Dabei wird ein Teil der Software über definierte Schnittstellen
mit vorgegebenen Eingaben ausgeführt und das Ergebnis mit zuvor spezifizierten Erwartungswerten
verglichen. Das Ziel des dynamischen Testens ist der Nachweis der Erfüllung
von festgelegten Anforderungen durch das implementierte Programmstück und die Aufdeckung
von eventuellen Abweichungen und Fehlerwirkungen (vgl. [52, 53]). Dynamische
Testverfahren werden ebenfalls bei der inkrementellen Softwareentwicklung benötigt.
Während der Überarbeitung der Programmstruktur als Reaktion auf neue Anforderungen,
darf sich das Verhalten der restlichen Funktionen nicht ändern. Um dies gewährleisten zu
können, sind entsprechende Testverfahren erforderlich.
Im Gegensatz zu automatisierten Quelltextanalysen ist ein vollständiger Test der Anwendung
im Allgemeinen jedoch nicht möglich. Die Überprüfung aller in Frage kommenden
Eingabedaten und deren Kombinationen, unter Berücksichtigung jeder Randbedingung,
ergäben eine nahezu unbegrenzte Anzahl an Möglichkeiten (vgl. [66]). Daher beschränken
sich Tests auf eine systematisch festgelegte Teilmenge der Eingabewerte. Die
Testergebnisse des entwickelten Systems finden sich in Anhang B.2.
5.3.2. Testverfahren
Um eine sinnvolle Teilmenge der möglichen Eingabewerte zu bestimmen, bieten sich bei
der Testfallgenerierung je nach Verfügbarkeit der Quelltexte drei systematische Verfahren
an. Von diesen wurde in der vorliegenden Arbeit jeweils Gebrauch gemacht; sie werden
im Folgenden kurz beschrieben. Eine ausführlichere Schilderung der Verfahren ist im Rahmen
dieser Arbeit nicht möglich, daher sei auf die einschlägige Fachliteratur verwiesen
(vgl. [67, 68, 66]).
Blackbox-Verfahren. Bei Blackbox-Verfahren ist der innere Aufbau der Testobjekte nicht
bekannt. Sinnvolle Werte für Testbeschreibungen werden aus Spezifikationen ermittelt
und anhand verschiedener Methoden geprüft. So werden Eingabewerte, bei denen davon
ausgegangen wird, dass sich das Testobjekt jeweils gleich verhält, in Äquivalenzklassen
eingeteilt. Da Fehlerzustände in Programmen häufig an Grenzbereichen dieser Äquivalenzklassen
auftreten, werden in der Grenzwertanalyse die äußersten Werte der Klassen
einer Prüfung unterzogen. Zusätzlich können viele Testobjekte unterschiedliche Zustände
annehmen, die z.B. von Funktionsaufrufen ausgelöst werden. Daher werden häufig ebenfalls
zustandsbezogene Tests durchgeführt. Die Grundlage zur Anwendung von Blackbox-
Verfahren bieten in diesem Zusammenhang unter anderem die Aktivitätsdiagramme aus
55

Abschnitt 3.6.
5. Implementierung und Test
Whitebox-Verfahren. Im Rahmen von Whitebox-Verfahren wird der innere Aufbau der
Testobjekte herangezogen und aufgrund der Programmlogik Testfälle ermittelt. Dabei sollten
grundsätzlich alle Quellcodeteile eines Testobjektes mindestens einmal zur Ausführung
gebracht werden. Bei der Testfallgenerierung kann grundsätzlich eine Anweisungs-,
Zweig-, Bedingungs- und Pfadüberdeckung angestrebt werden. Im Rahmen der vorliegenden
Arbeit wurden Softwaresysteme zur Ermittlung dieser Quelltextüberdeckungen
bei Tests angewendet, um eine hohe und sinnvolle Überdeckung zu gewährleisten.
Intuitive Testfallermittlung. Systematisch ermittelte Testfälle lassen sich durch die intuitive
Testfallermittlung sinnvoll ergänzen, jedoch nicht ersetzen. Grundlage dieser Methode
sind meist Erfahrungen des Testfallerstellers, wo Fehlhandlungen in der Vergangenheit
aufgetreten sind. Dadurch können gegebenenfalls Fehlerwirkungen aufgedeckt werden,
die in den oben genannten Verfahren übersehen worden sind.
5.3.3. Teststufen
Der Softwaretest ist integraler Bestandteil des verwendeten Entwicklungsprozesses. Aus
Sicht des Testens spielt hierbei das allgemeine V-Modell[69] eine besondere Rolle, dessen
Testprinzipien sich auf andere Vorgehensmodelle leicht übertragen lassen. Demnach sind
Testarbeiten zu Entwicklungsarbeiten gleichberechtigte Tätigkeiten, die sich wie folgt gliedern
lassen:
Komponententest. Beim Komponententest werden einzelne Softwarebausteine isoliert
vom Gesamtsystem gegenüber seiner Spezifikation überprüft. Die Grundlagen für die
Testfallgenerierung ergeben sich im vorliegenden System sowohl aus der Anforderungsanalyse
(Kapitel 3), als auch aus sich periodisch wiederholenden Gesprächen mit Projektmitgliedern
und -partnern. Insbesondere kann auf die Ablaufdiagramme der jeweiligen
Anwendungsfälle zurückgegriffen werden. Jeder Aktionszweig wird mittels eines Tests
durchlaufen (gekennzeichnet durch «Aktivitätsnummer».«Transitionsnummer» in Kapitel
3.6), um somit die geforderte Funktionalität im System überprüft. Zum anderen sind
Whitebox-Verfahren angewendet worden, um eine möglichst hohe und vor allem sinnvolle
Überdeckung der Quelltextausführung zu erreichen.
Integrationstest. Das Zusammenspiel von Komponentengruppen, wie es im technischen
Systementwurf der Anwendung spezifiziert wurde (s. Kap. 4), ist Inhalt des Integrationstests.
Gegenstand sind insbesondere die Schnittstellen zur Systemumgebung. Diesem
Aspekt des Testens wurde neben der entsprechenden Testfallgenerierung auch dadurch
Rechnung getragen, dass das System auf zwei unterschiedlichen Hard- und Softwareum-
56

5. Implementierung und Test
gebungen entwickelt und getestet wurde. Die Entwicklungsumgebungen (s. Anhang A)
stellten jeweils alle Kommunikationskomponenten zur Verfügung, die zur Ausführung
von Testfällen zur Verifikation des Systementwurfs notwendig waren.
Systemtest. Beim Systemtest wird überprüft, ob das System als Ganzes die spezifizierten
Anforderungen erfüllt. Dieser Schritt ist notwendig, da viele Funktionen und Systemeigenschaften
aus dem Ineinandergreifen aller Systemkomponenten resultieren und somit erst
auf der Ebene des Gesamtsystems beobachtbar und testbar sind. Durch die Möglichkeit,
das IG in einer virtuellen Umgebung zu nutzen (verwendet wurde VMWare 9 ), konnte im
Laufe des Entwicklungsprozesses immer eine aktuelle Testumgebung geschaffen werden.
Abnahmetest. Der Abnahmetest überprüft abschließend, ob das System alle vereinbarten
Leistungsmerkmale aufweist. Schon während der Implementierung wurden Projektmitgliedern
lauffähige Versionen der Anwendung präsentiert und auf Vollständigkeit hin
überprüft. Zum Abschluss der vorliegenden Arbeit ist das System nochmals im Detail auf
alle geforderten Merkmale hin untersucht worden.
5.3.4. Verwendete Software
Zur Gewährleistung der korrekten Funktionsweise der einzelnen Komponenten des entwickelten
Systems und einer systematischen Generierung der notwendigen Tests kam verschiedene
Software zum Einsatz.
JUnit. JUnit[70] ist ein bekanntes Framework zur einfachen Erstellung von Klassen- und
Interaktionstests. Es ermöglicht die Durchführung von automatisierten, selbst überprüfenden
Klassen- und Komponententests. Das Testobjekt wird hierbei von anderen im Zusammenhang
eines Programms benötigten, mitwirkenden Programmeinheiten isoliert und mit
vorgegebenen Werten zur Ausführung gebracht. Das Ergebnis wird, wie bei dynamischen
Testsystemen üblich, mit einem definierten Wert verglichen. JUnit war Bestandteil der genutzten
Entwicklungsumgebung und erlaubte die kontinuierliche Durchführung der Tests
während der Implementierung.
Coverlipse. Coverlipse 10 ist eine Erweiterung für das verwendete Entwicklungssystem
und kennzeichnet visuell getestete und ungetestete Quelltextzeilen. Es unterstützt den
Entwickler bei der Generierung geeigneter Whitebox-Testfälle und der Aufdeckung nicht
getesteter Quelltextabschnitte.
9 http://www.vmware.com
10 http://coverlipse.sourceforge.net
57

5. Implementierung und Test
Emma. Emma 11 analysiert ebenso wie Coverlipse die Quelltextüberdeckung der verwendeten
Testfälle. Der Schwerpunkt liegt bei Emma jedoch weniger in der Integration in die
Entwicklungsumgebung als vielmehr in der Erstellung übersichtlicher Ergebnisberichte
(siehe B.2).
5.3.5. Bewertung
Die entwickelten, automatisierten Testfälle für das System unterstützten insbesondere die
Umstrukturierung der Quellen und vereinfachten die Fehlerbehebung. Für Komponenten,
für die Testfälle existierten, musste während aufwändiger Fehleranalysen mit Abstand am
wenigsten Zeit investiert werden. Ebenso konnte Programmcode früher Prototypen mittels
geeigneter Testfälle weiterverwendet und einfach in neue Quelltexte integriert werden.
Die Entwicklung von Testfällen zu existierendem Code oder noch zu schreibenden Funktionen
verlangt jedoch ein wenig Selbstdisziplin, da sich deren Nutzen erst im Laufe der
späteren Entwicklung erschließt. Des Weiteren eigneten sich nicht alle Komponenten im
gleichen Maß zum automatisierten Testen. Speziell Komponenten zur Benutzerinteraktion
mussten manuell in regelmäßigen Abständen überprüft werden.
11 http://emma.sourceforge.net
58

6. Zusammenfassung, Kritik und Ausblick
6.1. Zusammenfassung
In der vorliegenden Arbeit wurde eine Ressourcen-Datenbank für das Instant-Grid-Projekt
entwickelt. Die Software ist das Ergebnis einer iterativen und inkrementellen Vorgehensweise
bei der Definition und Umsetzung der Projekt-Anforderungen. Das System integriert
sich vollständig in die vorhandene Infrastruktur und stellt Schnittstellen sowohl für
Anwender, als auch für Entwickler zur Verfügung. Im Rahmen des nächsten Releasezyklus’
wird es Bestandteil der veröffentlichten CD-ROM sein.
Der Schwerpunkt des Entwicklungsprozesses lag in der Integration in die vorhandene
Infrastruktur und der softwaregestützten Qualitätskontrolle während der Implementierung.
Die Kommunikation mit den Projektbetroffenen stand hierbei im Vordergrund der
Arbeit und spielte eine wesentliche Rolle beim Entstehungsprozess.
6.2. Kritik
Trotz einer engen Zusammenarbeit aller Beteiligten wurde zum Ende der Projektlaufzeit
deutlich, dass die Priorisierung während der Implementierung etwas besser hätte gewählt
werden können. Dies betraf insbesondere die Verzahnung der Softwarekomponenten des
FIRST und des GRDB-Daemons. So war es notwendig, die Datenbankstruktur zu einem
späten Zeitpunkt zu modifizieren, und die Entwicklung temporärer Module zur Aktualisierung
von Ressourceninformationen seitens des Fraunhofer Instituts waren unumgänglich.
Die genannten Probleme sind darauf zurückzuführen, dass für die Implementierung des
Systems eine Vielzahl moderner Technologien verwendet werden mussten. Die Einarbeitung
in diese Technologien und Fehler in den verwendeten Software-Systemen haben zu
einem verzögerten Entwicklungsprozess geführt und die Präsentation lauffähiger Prototypen
musste so mehrmals verschoben werden. Um dennoch Aspekte der Oberflächengestaltung
und zu nutzende Funktionen möglichst früh kommunizieren zu können, wurde
die Priorität bei der Entwicklung auf eine lauffähige Version des Portlets und die Integration
in die CD gelegt. Eine stärkere Konzentration auf die Entwicklung des GRDBD wäre
in diesem Zusammenhang sinnvoller gewesen.
59

6.3. Ausblick
6. Zusammenfassung, Kritik und Ausblick
Projekte dieser Größenordnung bieten genügend Potential für weitere Entwicklungen. Die
Dynamik und Evolution von zusammenhängenden Softwaresystemen stellen zukünftige
Herausforderungen dar. So steht etwa die JSR-286-Portletspezifikation[71] kurz vor ihrer
Veröffentlichung, und Datenbanksysteme, die sowohl relationale auch XML basierte Daten
verwalten, werden dedizierte Systeme vermutlich ablösen.
Dies führt auch zu Optimierungsmöglichkeiten innerhalb des Instant-Grid-Projektes.
Insbesondere der Speicheraufwand der für den Betrieb zweier unabhängiger Datenbanksysteme
notwendig ist, könnte so reduziert werden. Aufgrund des hohen Speicherbedarfs
von Java Anwendungen innerhalb einer virtuellen Maschine, ist ebenfalls eine Umsetzung
des GRDBD als native Anwendung denkbar. Ansätze, Java Bytecode in nativen Code zu
überführen, gibt es schon seit längerem[72], und aktuelle Projekte wie der GNU Compiler
für Java 1 könnten eine Umstellung vereinfachen. Ebenso kann eine eingehende Analyse
der vorausgesetzten, technischen Anforderungen (s. Abs. 3.5.4.1) zu einer Herausbildung
von möglichen Alternativen führen.
Ein weiterer Aspekt sind Analysen der Performanz des entwickelten Systems in Bezug
auf die Anzahl der existierenden Hardware-Ressourcen, der Menge an Software-Beschreibungen
und des Aktualisierungsintervalls des GRDB-Daemons und der Information-Provider.
Diese Ergebnisse haben einen direkten Einfluss auf die Struktur der Datenbank und
dem Zusammenspiel des GRDBD, der IP und des GWES (/T50/T60/). Ebenso können Möglichkeiten
der automatisierten Ermittlung von Software-Ressourcen untersucht werden
(/D60/ F51/).
Darüber hinaus sind Erweiterungen der Benutzeroberfläche denkbar. So können zur Gestaltung
der Interaktionsstruktur Punkte der ISO 13407 2 herangezogen werden und die
einschlägige Literatur[73, 74] für das Design der Oberfläche berücksichtigt werden. Auch
sind weitere Auswertungen der gesammelten Daten in Betracht zu ziehen, wie etwa die
graphische Darstellung von Auslastungsdaten innerhalb eines gesetzten Zeitintervalls -
eine Erweiterung der Datenbankstruktur zur Speicherung von Zeitinformationen vorausgesetzt
(/F110/). Als letzte Punkte sind eine mögliche Internationalisierung des Portlets
und die Einbindung eines Editors zur Bearbeitung von Software-Beschreibungen zu nennen.
1 http://gcc.gnu.org/java
2 Benutzer-orientierte Gestaltung interaktiver Systeme
60

A. Verwendete Konfiguration
A.1. Hardware
Die Entwicklung des Systems erfolgte abwechselnd auf zwei unterschiedlichen Arbeitsplatzrechnern.
Durch diese Maßnahme werden unter anderem unvollständige Teilpakete
des zu entwickelnden Systems frühzeitig erkannt und mögliche Inkompatibilitäten rechtzeitig
aufgedeckt.
Tabelle A.1.: Verwendete Hardware
Kategorie Arbeitsplatzrechner 1 Arbeitsplatzrechner 2
Bezeichnung Dell Precision 380 Fujitsu-Siemens A7600
Architektur 64 Bit (EM64T) 32 Bit (x86)
Prozessor Intel Pentium 4HT Mobile AMD Athlon 2000+
Taktung 3,00 GHz 1,60 GHz
Speicher 1024 MB 512 MB
Betriebssystem SuSE Linux 10.1 (Kernel 2.6.12) SuSE Linux 10.1 (Kernel 2.6.16)
A.2. Software
Nachfolgend sind alle relevanten Software-Pakete aufgeführt, die zum Aufbau eines, zur
verwendeten Entwicklungsumgebung identischen, Arbeitsumfeldes dienen.
Tabelle A.2.: Verwendete Software
Kategorie Name Version URL
Dokumentation Auriga 0.1b www.aurigalogic.com
Dokumentation Poseidon for UML 4.2.1 (CE) www.gentleware.com
Dokumentation Xref 1.6.8 www.xref-tech.com
Dynamisches Testen Coverlipse 0.9.5.2 http://coverlipse.sf.net
Dynamisches Testen Emma 2.0.5312 emma.sf.net
Dynamisches Testen JUnit 3.8.1 junit.sf.net
Entwicklungsumgebung Ant 1.6.5 ant.apache.org
Entwicklungsumgebung Eclipse SDK 3.2 www.eclipse.org
61

A. Verwendete Konfiguration
Entwicklungsumgebung GridSphere Portal 2.2.5 www.gridsphere.org
Entwicklungsumgebung Instant-Grid 0.4nb www.instant-grid.org
Entwicklungsumgebung Java SDK 1.5.0_07 java.sun.com
Entwicklungsumgebung Linux Kernel 2.6.12 www.kernel.org
Entwicklungsumgebung Tomcat 5.0.28 tomcat.apache.org
Entwicklungsumgebung Subversion 1.3 subversion.tigris.org
Entwicklungsumgebung VMWare 5.5.1 http://www.vmware.com/
Quelltextanalyse Checkstyle 4.2 checkstyle.sf.net
Quelltextanalyse FindBugs 1.1.0 findbugs.sf.net
Quelltextanalyse Lint4J 0.9.11 www.jutils.com
Quelltextanalyse PMD 3.7 pmd.sf.net
62

B. Dokumentation
B.1. Quelltexte
Aus Platzgründen befinden sich die Quelltexte auf der beigefügten CD-ROM oder kann
unter grid.alexanderwillner.de heruntergeladen werden.
B.2. Testergebnisse
Die Übersicht der getesteten Quelltextabschnitte befindet sich auf den Seiten 64ff.
B.3. GRDB-API
Aus Platzgründen befindet sich die Dokumentation der API auf der beigefügten CD-ROM
oder kann unter grid.alexanderwillner.de heruntergeladen werden.
B.4. GRDB-Portletübersicht
Die Übersichtsgraphik des GRDB-Portlets befindet sich auf Seite 66.
B.5. D-GRDL-Spezifikation
Die Spezifikation der D-GRDL befindet sich auf den Seiten 67ff.
63

[all classes]
nameclas,%method,%block,%line,%
all classes 100%(12/12) 100%(88/88) 91%(1458/1606) 91%(441/486)
file:/home/awilner/Software3/gridsp.ap/docs/coverage/_files/overview.html #1 EMACoverageReport(generatedWedSep2710:23:12CEST206) 16.10.206
OVERALCOVERAGESUMARY
OVERALSTATSUMARY
totalpackages: 3
totalexecutablefiles: 12
totalclasses: 12
totalmethods: 88
totalexecutablelines: 486
name clas,%method,%block,%line,% COVERAGEBREAKDOWNBYPACKAGE
org.instantgrid.grdb.daemon 100%(4/4) 100%(32/32) 82%(586/715) 84%(194/231)
org.instantgrid.grdb.model 100%(6/6) 100%(51/51) 98%(817/836) 97%(234/242)
org.instantgrid.grdb.config 100%(2/2) 100%(5/5) 100%(55/55) 100%(13/13)
[all classes]
EMMA2.0.5312(C)VladimirRoubtsov EMACoverageReport(generatedWedSep2710:23:12CEST206)
[all classes] COVERAGESUMARYFORPACKAGE[org.instantgrid.grdb.daemon]
clas,%method,%block,%line,% name org.instantgrid.grdb.daemon 100%(4/4) 100%(32/32) 82%(586/715) 84%(194/231)
name clas,%method,%block,%line,% COVERAGEBREAKDOWNBYSOURCEFILE
GangliaConnector.java 100%(1/1) 100%(4/4) 81%(79/98) 81%(30/37)
GrdbDaemon.java 100%(1/1) 100%(21/21) 81%(449/556) 84%(145/173)
MdsConnector.java 100%(1/1) 100%(3/3) 94%(44/47) 87%(13/15)
AbstractGrdbConnector.java 100%(1/1) 100%(4/4) 100%(14/14) 100%(6/6)
[all classes]
EMMA2.0.5312(C)VladimirRoubtsov EMACoverageReport(generatedWedSep2710:23:12CEST206)
[all classes] COVERAGESUMARYFORPACKAGE[org.instantgrid.grdb.model]
clas,%method,%block,%line,% name org.instantgrid.grdb.model 100%(6/6) 100%(51/51) 98%(817/836) 97%(234/242)
name clas,%method,%block,%line,% COVERAGEBREAKDOWNBYSOURCEFILE
XmlTransformer.java 100%(1/1) 100%(3/3) 91%(74/81) 83%(20/24)
GridResourceFactory.java 100%(1/1) 100%(2/2) 96%(139/145) 95%(37/39)
XmlDB.java 100%(1/1) 100%(13/13) 98%(293/299) 98%(80/82)
GridResource.java 100%(1/1) 100%(20/20) 100%(223/223) 100%(66/66)
GridResourceSimpleProperty.java 100%(1/1) 100%(11/11) 100%(80/80) 100%(27/27)
ResourceNotFoundException.java 100%(1/1) 100%(2/2) 100%(8/8) 100%(4/4)

[all classes] #2 file:/home/awilner/Software3/gridsp.ap/docs/coverage/_files/overview.html 16.10.206
EMMA2.0.5312(C)VladimirRoubtsov EMACoverageReport(generatedWedSep2710:23:12CEST206)
[all classes] COVERAGESUMARYFORPACKAGE[org.instantgrid.grdb.config]
clas,%method,%block,%line,% name org.instantgrid.grdb.config 100%(2/2) 100%(5/5) 100%(55/55) 100%(13/13)
nameclas,%method,%block,%line,% COVERAGEBREAKDOWNBYSOURCEFILE
Config.java 100%(1/1) 100%(3/3) 100%(26/26) 100%(7/7)
I18N.java 100%(1/1) 100%(2/2) 100%(29/29) 100%(6/6)
[all classes]
EMMA2.0.5312(C)VladimirRoubtsov

B. Dokumentation
Abbildung B.1.: Screenshot: Übersicht des GRDB-Portlets
66

DGI FG 2–4
Spezifikation der
D-Grid-Ressourcenbeschreibungssprache
D-GRDL
Auszüge für das InstantGrid-Projekt
Dr. Armin Wolf
Fraunhofer FIRST, Kekuléstr. 7, D-12489 Berlin
Stand: September 2006
zur projektinternen Verwendung

Auszug aus der D-GRDL für das InstantGrid-Projekt 1
Inhaltsverzeichnis
1 Ziele und Grenzen 2
2 Grundlagen der Sprachdefinition 3
2.1 Kontextfreie Grammatiken . . . . . . . . . . . . . . . . . . . . . 3
2.2 XML und XML-Schema sowie XPath . . . . . . . . . . . . . . . . 4
3 Beschreibungssprache 4
3.1 Bezeichner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Ressourcen und deren Klassen . . . . . . . . . . . . . . . . . . . . 5
3.3 Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Ressourcen-Aggregation . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1 Einfache Aggregation . . . . . . . . . . . . . . . . . . . . 10

Auszug aus der D-GRDL für das InstantGrid-Projekt 2
1 Ziele und Grenzen
Ein Ziel dieser Spezifikation ist es, eine (Ziel-)Sprache D-GRDL zu definieren,
die möglichst vielen der bestehenden (und teilweise im Umbruch befindlichen)
Ressourcenbeschreibungen gerecht wird. Übersetzer zwischen bestehenden Sprachen
und D-GRDL kann es von unserer Seite innerhalb des jetzigen Projekts
aufgrund des damit verbundenen Aufwands nicht geben. Es gilt mit D-GRDL
eine gemeinsame Sprache zu haben, die es erlaubt, Ressourcen unterschiedlicher
Grid-Infrastrukturen mit einem einzigen Formalismus zu beschreiben. Darüber
hinaus soll Software zu deren Verarbeitung bereit gestellt werden, z. B. um
Ressourcen über Infrastrukturgrenzen zu verwalten und aufzufinden. Die so gewonnene
Information kann dann bei und mit der jeweiligen Infrastruktur mit
ihren individuellen Spezifika weiter verarbeitet werden.
In diesem Dokument wird deshalb nicht nur die D-Grid-
Ressourcenbeschreibungssprache, im Folgenden kurz ” D-GRDL“ genannt,
formal spezifiziert und anhand von Beispielen erläutert. Es werden ergänzend
auch Konzepte, Methoden und Verfahren festgelegt, um Beschreibungen von
Grid-Ressourcen zu prüfen, zu speichern, zu aktualisieren und abzufragen.
Ihre Umsetzung und Implementierung soll eine zentrale Aufgabe im Grid-
Computing unterstützen, nämlich das Resource-Matching. Dabei geht es darum,
beschriebene Ressourcen anhand zu erfüllender Eigenschaften aufzufinden,
d. h. Ressourcen zu finden, die gegebenen Anforderungen genügen, so dass
ein Job prinzipiell/potentiell auf einer Grid-Infrastruktur ausführbar ist: seine
Ressourcenbedarfe (requests) müssen durch passende Angebote (matching bids)
erfüllt sein. Dieses Zuordnungsproblem gilt es zu lösen: jeder Nachfrage ist ein
Angebot oder einer Menge (alternativer) passender Angebote zuzuordnen.
Diese Zuordnung erfolgt anhand von Ressourcen-Eigenschaften, die generell statischer
Natur sind. Dynamische Eigenschaften der Ressourcen, wie z. B. aktuelle
Prozessor- oder Speicherauslastungen bleiben dabei unberücksichtigt. Diese Daten
werden erst bei der anschließenden Einlastung des Jobs bei der Auswahl
konkreter Ressourcenangebote aus den passenden ermittelt und eingesetzt. Die
konkrete Einlastung der Jobs auf passende Ressourcen wird Resource-Mapping
bezeichnet und ist nicht Gegenstand der folgenden Überlegungen.
Die D-GRDL und die sie unterstützenden Implementierungen ist daher so
ausgelegt, dass in Ressourcenbeschreibungen grundsätzlich nur auf absehbare
Zeit konstante Informationen repräsentier- und verarbeitbar ist. Die unmittelbare
Repräsentation zeitlich kontinuierlicher oder feingranular diskretisierter
Informationen ist in der D-GRDL nicht möglich. Jedoch bietet die D-
GRDL mit ihrem offenen Mechanismus zur Definition von Eigenschaften (properties)
die Möglichkeit der indirekten Repäsentation solcher Informationen:
Damit können Referenzen auf Dienste festgelegt werden, die einen Zugriff auf
zeit-kontinuierliche Informationen erlauben (z. B. Zugriff auf ein Monitoring-
System). Somit lassen sich Doppelungen separater Formalismen für dynamische
Ressourcen-Informationen, deren Semantik mit der D-GRDL überlappen müsste,
vermeiden, ohne dass sofort den Ressourcenbeschreibungen die gesamte Last
aller dynamischen Informationen aufgebürdet wird.

Auszug aus der D-GRDL für das InstantGrid-Projekt 3
2 Grundlagen der Sprachdefinition
2.1 Kontextfreie Grammatiken
Die formalen Definition der Sprachsyntax basiert auf einer kontextfreien Grammatik
G = (N, T, P, S) bestehend aus
• einer endlichen Menge von Nichtterminalen N
• einer endlichen, zu N disjunkten Menge von Terminalen T, d. h. T ∩N = ∅,
welche im folgenden durch Hochkommata hervorgehoben werden, z. B.:
’

Auszug aus der D-GRDL für das InstantGrid-Projekt 4
Beispiel: Als Beispiel seien im folgenden die Produktionen einer Grammatik
mit Startsymbol Id angegeben, die die Bezeichner einer Programmiersprache
in üblicher Form beschreibt, nämlich als nichtleere Folgen von Buchstaben und
Ziffern, die mit einem Buchstaben beginnen:
Id −> Letter ( Letter | Digit )∗
Letter −> ’a ’ | . . . | ’z ’ | ’A’ | . . . | ’Z’
Digit −> ’0 ’ | ’1 ’ | . . . | ’9 ’
Da sich unmittelbar aus den Produktionen die Nichtterminale und Terminale
der Grammatik ergeben, werden wir im Folgenden auf eine explizite Angabe
dieser Mengen und des Quadrupels G = (N, T, P, S) verzichten.
2.2 XML und XML-Schema sowie XPath
Die D-GRDL ist eine Teilmenge der eXtended Markup Language (XML) 1 , die
einem XML-Schema 2 genügt, wobei wir der Einfachheit halber im Folgenden
die Sprache mit Hilfe einer kontextfreien Grammatik formulieren, jedoch auch
ein entsprechendes XML-Schema angeben, dass u. a. zur Evaluierung oder zu
korrekten Konstruktion von D-GRDL-Konstrukten eingesetzt werden kann.
Um die Semantik der D-GRDL z.B. mittels einzuhaltender Bedingungen zu
formulieren, nutzen wir die Sprache XPath 3 , mit der man auf Teilkonstrukte
einer XML-Sprachkonstrukts referenzieren kann.
Eine Beschreibung dieser Formalismen ist nicht Gegenstand dieses Dokuments.
Detaillierte Definitionen und Spezifikationen dieser Formalismen finden sich in
der einschlägigen und vielfältig verfügbaren Literatur.
3 Beschreibungssprache
3.1 Bezeichner
Bezeichner in D-GRDL-Beschreibungen sind Uniform Resource Identifier
(URI), die im Allgemeinen durch Element-Attribute wiedergegeben werden. Als
URI dürfen beliebige zulässige Bezeichner anyURI verwendet werden, wobei
gängige aber auch eigene Konventionen zu deren Strukturierung umsetzbar sind.
Diese Konventionen sind nicht Bestandteil der D-GRDL und somit durch die
Nutzer der Sprache festzulegen. 4
URI −> ’ uri =”’ anyURI ’” ’
1 siehe http://de.wikipedia.org/wiki/XML zur Übersicht mit weiterführenden Verweisen,
u. a. zu den offiziellen Dokumenten des W3C.
2 siehe http://de.wikipedia.org/wiki/XML_Schema zur Übersicht mit weiterführenden
Verweisen, u. a. zu den offiziellen Dokumenten des W3C.
3 siehe http://de.wikipedia.org/wiki/XPath zur Übersicht mit weiterführenden Verweisen,
u. a. zu den offiziellen Dokumenten des W3C.
4 siehe http://de.wikipedia.org/wiki/Uniform_Resource_Identifier zur Übersicht über
den Aufbau und die Struktur von URIs.

Auszug aus der D-GRDL für das InstantGrid-Projekt 5
3.2 Ressourcen und deren Klassen
Eine Ressource wird in D-GRDL durch ein XML-Element ” “ beschrieben.
Dieses hat obligatorisch einen (eindeutigen) Bezeichner (URI) und
ist einer Ressourcenklasse, benannt durch einen (abstrakten) Bezeichner (URI),
zugeordnet (OfClass). Des weiteren kann eine Ressourcenbeschreibung optional
über einen Namen (Name) sowie über eine Beschreibung (Description) verfügen.
Weitere optionale Teile der Beschreibung sind Angaben über Ressourceneigenschaften
und darüber, welche Ressourcen aggregiert werden (Provides).
Schließlich kann eine Ressourcenbeschreibungen optional nicht weiter unterstützte
oder semantisch interpretierte Beschreibungen in XML enthalten (Unsupported):
Resource −> ’’
OfClass
Name?
Description ?
SimpleProperty∗
Provides?
’’
Integritätsbedingung: Ist eine Menge von Ressourcenbeschreibungen R gegeben,
so müssen deren Bezeichner eindeutig sein. Semantisch bedeutet dies,
dass zwei Beschreibungen gleich sein müssen, wenn es ihre URIs sind:
∀x ∀y : (x ∈ R ∧ y ∈ R
=⇒ x = y .
∧ x/resource[1]/@uri = y/resource[1]/@uri)
Die Zugehörigkeit einer beschriebenen Ressource zu einer Klasse, wird mit dem
Konstrukt
OfClass −> ’’
ausgedrückt. Es besagt, dass die Ressource ein Element der (abstrakten) Menge
ist, die durch den Klassenbezeichner benannt ist. Ferner sollen die Ressourcenund
die Klassenbezeichner disjunkt sein.
Integritätsbedingungen: Die Bezeichner der Ressourcen und ihrer Klassen
müssen disjunkt sein, d. h. für eine gegebene Menge von Ressourcenbeschreibungen
R muss gelten:
∀x ∀y : (x ∈ R ∧ y ∈ R)
=⇒ x/resource[1]/ofClass[1]/@uri = y/resource[1]/@uri .
Formale Semantik: Beschriebene Ressourcen sind Elemente der genannten
Klassen, welche wiederum Teilmengen der Ressourcen sind. — Für jede Menge

Auszug aus der D-GRDL für das InstantGrid-Projekt 6
von Ressourcenbeschreibungen gilt:
∀x : x ∈ R
=⇒ x/resource[1]/@uri ∈ x/resource[1]/ofClass[1]/@uri ,
∀x : x ∈ R
=⇒ x/resource[1]/ofClass[1]/@uri ⊆ {y/resource[1]/@uri | y ∈ R} .
Beispiel: Mit den bis hier vorgestellten Konstrukten ist bereits eine minimale
Ressourcenbeschreibung möglich, die einer Ressource einen eindeutigen Bezeichner
gibt und eindeutig einer Klasse von (gleichartigen) Ressourcen zuordnet:
Die Beschreibung besagt, dass die Ressource xemacs:win:xp ein Element der Ressourcenklasse
urn:dgrdl:software:win:editor ist, welche wiederum eine Teilmenge
aller beschriebenen Ressourcen ist.
Zur besseren Verständlichkeit einer solchen Beschreibung gerade für den Benutzer,
kann sie um optionale Konstrukte zur detaillierten Benennung und Beschreibung
erweitert werden. Diese können beliebige Folgen zulässiger Zeichen
anyString des gewählten Zeichensatzes (z. B. UTF-8) sein.
Das Konstrukt
Name −> ’’ anyString ’’
gibt einer Ressourcenbeschreibung einen optionalen Namen und
Description −> ’< description >’
anyString
’’
versieht es mit einer optionalen Beschreibung, die lediglich deklarativen Charakter
hat. Für die formale Sprachsemantik hat sie keine Relevanz.
Damit kann unsere Ressourcenbeschreibung für xemacs:win:xp für einen Benutzer
verständlicher gestaltet werden:
XEmacs i n st a l l a t i o n for MS−Windows−XP
a window−based text −editor with various features
Der ebenfalls semantisch nicht unterstützte, optionale Beschreibungsteil kann
weitere beliebige zulässige XML-Strukuren anyXML enthalten, die zwar für den
Nutzer eine Bedeutung haben, jedoch nicht innerhalb der D-GRDL:
Unsupported −> ’’
anyXML
’’

Auszug aus der D-GRDL für das InstantGrid-Projekt 7
3.3 Eigenschaften
Die einfachste Art eine Eigenschaft von Ressourcen zu beschreiben, besteht darin,
diese zu benennen, ihr einen Typ sowie eine Dimension zu geben und letzlich
mit einem Wert zu versehen. Dazu steht in Ressourcenbeschreibungen das folgende
Konstrukt
SimpleProperty
−> ’’
Value
’’
zur Verfügung, deren Bestandteile durch
Type −> ’ type =”’ TypeId ’”’
TypeId −> BaseTypeId
definiert sind.
Der Eigenschaftswert (Value) ist ein Wert der definierten Basistypen (Integer,
Decimal, . . .DateTime):
Value −> BaseValue
BaseValue −> Integer | Decimal | Boolean | String
| anyURI | Date | Time | DateTime
Die Werte der Basistypen haben dabei folgende syntaktische Struktur:
Integer −> ( ’ −’ | ’+’ )? Unsigned
Decimal −> Integer ( ’ . ’ Unsigned )?
String −> ( Letter | Symbol | Digit | ’ ’)+
Boolean −> ’ true ’ | ’ false ’
Date −> FourDigits ’ −’ TwoDigits ’ −’ TwoDigits
Time −> TwoDigits ’: ’ TwoDigits ’: ’ TwoDigits
DateTime −> Date ’T’ Time
Unsigned −> Digit+
Letter −> ’a ’ | . . . | ’z ’
| ’A’ | . . . | ’Z’
Symbol −> ’ ’ | ’: ’ | ’@’ | ’/ ’ | ’. ’
Digit −> ’0 ’ | ’1 ’ | . . . | ’9 ’
TwoDigits −> Digit Digit
FourDigits −−> TwoDigits TwoDigits
Integritätsbedingungen: Für jede Ressourcenbeschreibung einer Menge sollen
die einfachen Eigenschaftsdefinition eindeutig sein, d. h. mehrere Definitionen
von Eigenschaften mit gleichem Namen sind unzulässig. Ist eine Menge von
Ressourcenbeschreibungen R gegeben, so gilt
ICsimplePropUnique(R,resource) ,

Auszug aus der D-GRDL für das InstantGrid-Projekt 8
wobei
ICsimplePropUnique(R, $P) ≡ {
∀x ∀α ∀β : (x ∈ R
∧ α ∈ x/$P/simpleProperty
∧ β ∈ x/$P/simpleProperty
∧ α/@ident = β/@ident)
=⇒ α = β }
sei, d. h. die eigentlichen Bedingungen sich durch Substitution des Parameter
$P durch resource ergeben. 5
Die möglichen Werte einer einfachen Eigenschaftsdefinition wird durch ihren
Typ eingeschränkt, d. h. wenn dieser Typ ein Basistyp ist, so gilt für eine Menge
von Ressourcenbeschreibungen R
wobei
ICsimplePropBtype(R,resource, ’int’, Integer)
∧ ICsimplePropBtype(R,resource, ’float’, Decimal)
∧ ICsimplePropBtype(R,resource, ’bool’, Boolean)
∧ ICsimplePropBtype(R,resource, ’string’, String)
∧ ICsimplePropBtype(R,resource, ’uri’, anyURI)
∧ ICsimplePropBtype(R,resource, ’date’, Date)
∧ ICsimplePropBtype(R,resource, ’time’, Time)
∧ ICsimplePropBtype(R,resource, ’dateTime’, DateTime) ,
ICsimplePropBtype(R, $P, $T, $S) ≡ {
∀x ∀α : (x ∈ R ∧ α ∈ x/$P/simpleProperty[@type = $T])
=⇒ α/text() ∈ $S }
sei. Das heißt, alle Werte einfacher Eigenschaftsbedinungen müssen dem definierten
Typ entsprechen. Die eigentlichen Bedingungen ergeben sich auch hier durch
Substitution des Parameters, wobei Integer, Decimal, String, anyURI, Date, Time
sowie DateTime die Mengen möglicher Werte (syntaktische Konstrukte) seien,
die durch die Produktionen der gleichnamigen Nichtterminale definiert sind.
Formale Semantik: Einfache Eigenschaftsdefintionen innerhalb von Ressourcenbeschreibungen
legen entsprechend benannte, typisierte und quantifizierte
Eigenschaften der Ressourcen fest. Da diese viel mit mit Feldern (engl. fields)
von Objekten gemein haben, verwenden wir die gleiche Schreibweise wie in objektorientierten
Programmiersprachen (z. B. Java):
∀x : x ∈ R =⇒ evalSimpleProperties(x) ,
wobei bei einer gegebenen Menge von Verbundtypen T und Erfüllung der Integritätsbedingungen
die einfachen Eigenschaftsdefinitionen der Struktur y für
5 Wir benutzen diese abkürzende Schreibweise, um im weiteren Verlauf der Sprachdefinition
eine explizite Auflistung von Bedingungen, die sich von den hier vorgestellten nur in wenigen
Bezeichern unterscheiden, zu vermeiden.

Auszug aus der D-GRDL für das InstantGrid-Projekt 9
eine Ressource r als Konjunktion von Gleichungen interpretiert wird:
evalSimpleProperties(x)
:=
y∈x/resource/simpleProperty
E(α,y)
(x/resource[1]/@uri.α/@ident = α/text()
∧ type(x/resource[1]/@uri.α/@ident) = α/@type
∧ unit(x/resource[1]/@uri.α/@ident) = α/@unit) .
Dabei sei die Bedingung der Konjunktion wie folgt definiert:
E(α, y) := α ∈ y[@type=’int’ or . . . or @type=’dateTime’] .
Beispiel: Zur Semantik einfacher Eigenschaften mit elementaren Werten ein
erläuterndes Beispiel, bei der eine Ressourcenbeschreibung vier Eigenschaften
hat, wobeicpuload undtimestamp sicher dynamischer Natur sind, deren Werte
kontinuierlich zu aktualisieren sind. Eine Alternative dazu stellt die Eigenschaft
monitor dar, die auf einen entsprechenden Service verweist, bei dem aktuelle
Eigenschaftswerte abgerufen werden können:
h ≡
harlekin
harlekin PC at Fraunhofer FIRST in room 128
2
42
12234567890
http: // localhost:8080 /monitoring/ services /query?wsdl

Auszug aus der D-GRDL für das InstantGrid-Projekt 10
Es gilt dann
evalSimpleProperties(h) :=
harlekin.cpucount = 2
∧ type(harlekin.cpucount) = int
∧ unit(harlekin.cpucount) = pcs
∧ . . .
Bemerkungen:
∧ harlekin.monitor
= http://localhost:8080/monitoring/services/query?wsdl
∧ type(harlekin.monitor) = uri
∧ unit(harlekin.monitor) = wsdl .
Temporale Aspekte wie zeitliche Änderungen von Eigenschaftswerten in der
Semantik, die auf Prädikatenlogik beruht, nicht berücksichtigt werden. D. h. es
gelten immer die Formeln und damit insbesondere die Eigenschaftswerte zum
Zeitpunkt der Betrachtung. Eine Aussage über Gültigkeitszeiten oder -zeiträume
ist nur indirekt mit Hilfe einer weiteren Eigenschaft möglich. Die Änderung von
Eigenschaftswerten und der sich daraus ergebenden Konsequenzen liegen bei der
Verantwortung des Benutzers.
3.4 Ressourcen-Aggregation
Dem Umstand, dass eine Ressource andere Ressourcen aggregieren kann, wird
in der D-GRDL mit dem optionalen Konstrukt
Provides −> ’’
ObjRef+
’’
Rechnung getragen, das im einfachsten Fall aus einer nichtleeren Folge von
Ressourcen-Referenzen, sprich Verweisen auf Ressourcenbezeichner, besteht:
ObjRef −> ’’
3.4.1 Einfache Aggregation
Unter (einfacher) Aggregation verstehen wir dabei ein (unmittelbares) ” zur Verfügung
stellen“ weiterer Ressourcen. 6 D. h. anders als bei der Klassenzugehörigkeit
ist eine aggregierte Ressource nicht Element der aggregierenden Ressource,
sondern steht lediglich in Relation zu ihr, was wir im folgenden noch formal
präzisieren.
Integritätsbedingung: Damit diese Relation wohldefiniert muss jede aggregierte
Ressource auch beschrieben sein. Mit anderen Worten: auf einer Menge
gegebener Ressourcenbeschreibungen R muss
ICprovidesExists(R,resourceRef)
6 Dies wird auch durch den Elementnamen ” provides“ hervorgehoben.

Auszug aus der D-GRDL für das InstantGrid-Projekt 11
gelten, wobei
sei.
ICprovidesExists(R, $P) ≡ {
∀x ∀α ∃y : (x ∈ R ∧ y ∈ R
∧ α ∈ x/resource/provides/$P)
=⇒ α/@uri = y/resource[1]/@uri }
Formale Semantik: Wie besagt, definiert die Aggregation eine binäre Relation
provides auf Ressourcen: Ist eine Menge von Ressourcenbeschreibungen R
gegeben, dann gilt
wobei
und
sei.
evalProvides(x)
:=
∀x : x ∈ R =⇒ evalProvides(x) ,
α∈x/resource/provides/resourceRef
evalSimpleProvides(x, α)
evalSimpleProvides(x, y) := x/resource[1]/@uri provides y/@uri
Beispiel: Zur Semantik der Relation provides ein erläuterndes Beispiel, bei dem
drei Ressourcenbeschreibungen gegeben sind:
h ≡
harlekin
harlekin PC at Fraunhofer FIRST in room 128
c ≡
cat
the cat program

Auszug aus der D-GRDL für das InstantGrid-Projekt 12
u ≡
xyz
anything that have to be s pe c ified
Die Beschreibung ist wohldefiniert, da zu jeder Ressourcen-Referenz eine entsprechende
Beschreibung existiert und es gilt:
evalProvides(h) = harlekin provides cat ∧ harlekin provides xyz .
Bemerkung: Es sei bemerkt, dass hier keinerlei Aussage darüber getroffen
wird, ob die Relation provides ggf. weitere Eigenschaften wie z. B. Transitivität
oder Asymmetrie hat.

Glossar
Begriff Beschreibung
Anforderungsverantwortliche Personen, die befugt sind Anforderungen an das
neue System festzulegen.
Apache Der Apache HTTP Server ist ein kostenloser und im
Internet der verbreitetste Webserver.
Cluster Eine Anzahl von eng miteinander vernetzten, gleichartigen
Computern, zur Erhöhung der Rechenkapazität
oder Verfügbarkeit.
Distributed computing Das verteilte Rechnen ist eine Technik, bei der eine
Anwendung auf verschiedene Rechner verteilt und
somit die Aufgabe zur Lösung eines Problems auf
mehrere Ressourcen aufgeteilt wird.
Fachexperten Personen, die als Experten im entsprechenden Anwendungsgebiet
sind. Diese sind häufig Anwender
des späteren Systems und helfen fachliche Fragen
qualifiziert zu beantworten.
Ganglia Ein verteilter Information-Provider der häufig in
Cluster- und Gridsystemen eingesetzt wird.
Globus Toolkit Ein Paket von Softwarekomponenten, die häufig zum
Aufbau und Betrieb einer Grid Plattform verwendet
wird. Siehe auch Abschnitt 2.1.
GLUE Das GLUE Schema ist eine abstrakte Beschreibungssprache
für Grid-Ressourcen. Sie wird im Rahmen
des MDS4 verwendet.
80

B. Dokumentation
Grid Aus dem englischen Sprachraum: Gitter. Ein Grid ist
ein verteiltes System das erlaubt, geographisch auseinander
liegende, autonome Ressourcen dynamisch
zur Laufzeit auszuwählen, zu nutzen und zusammenzufassen.
Dies erfolgt abhängig von ihrer Verfügbarkeit,
Kapazität, Performance, den entstehenden
Kosten und anderen benutzerdefinierten Qualitätsmerkmalen.
Siehe auch Abschnitt 2.1.
GridSphere Ein JSR-168-kompatibles[51] Portal-Framework. Es
wird im Rahmen des D-Grid Integrationsprojektes als
Webportal-Lösung empfohlen.
Information-Provider Software-Komponenten, die detaillierte Informationen
über in einem Netzwerk vorhandene Ressourcen
bereitstellen. Siehe auch MDS4 oder Ganglia.
MDS4 Der Globus Toolkit Monitoring and Discovery Service
ist ein Information-Provider zur Überwachung
von Hardware-Ressourcen in einem Grid.
Meta computing Bezeichnung für eine besondere Form des distributed
computing bei der ausschließlich Großrechenzentren
über ein Hochgeschwindigkeitsnetz verbunden sind.
Middleware Middleware (auch Zwischenanwendung) bezeichnet
in der Informatik anwendungsunabhängige Technologien,
die Dienstleistungen zur Vermittlung zwischen
Anwendungen anbieten, so dass die Komplexität
der zugrunde liegenden Applikationen und Infrastruktur
verborgen wird [75].
OGSA Beschreibung einer Architektur für eine Serviceorientierte
Grid-Umgebung für betriebswirtschaftliche
und wissenschaftliche Zwecke, die im Rahmen
des Global Grid Forums entwickelt wird.
81

B. Dokumentation
Peer-to-peer computing Eine Technik bei der alle Rechner in einem Netz
als gleichberechtigte Kommunikationspartner wirken
und sowohl Server- wie auch Client-Funktionen
übernehmen.
Portlet Ein in Java geschriebenes Programm, dass die Fähigkeiten
eines Portalservers (z.B. GridSphere) erweitert.
Pov-Ray Eine Ray-Tracer Anwendung. Diese nutzen Algorithmen
zur Verdeckungsberechnung von dreidimensionalen
Objekten im Raum, etwa bei der Darstellungsberechnung
im Bereich der 3D-Computergraphik.
Stakeholder Aus dem englischen Sprachraum. Kann in diesem
Zusammenhang als Projekt-, System- oder Anforderungsbetroffene
übersetzt werden.
Systembetroffene Personen, die vom fertigen System direkt betroffen
sind, so z.B. die späteren Anwender.
Hardware-Ressource Ein Sammelbegriff für die Einheit aller Baugruppen
und Peripheriegeräte eines Computers. Eine
Hardware-Ressource entspricht in der Regel einem
physisch existierenden Computer.
Scheduler Bestandteil der verwendeten Grid-Workflow-
Architektur. Der Scheduler verwaltet verschiedene
Workflow-Prozesse und verteilt die Aufgaben auf
die vorhandenen Hardware-Ressourcen. Siehe auch
Abschnitt 2.3.
Tomcat Der Apache Tomcat-Server ist die offizielle Referenzimplementierung
der JSR-154-Spezifikation[50]
(Servlets). Es handelt sich hierbei um eine Umgebung
für Java-Anwendungen, um diese in
Request/Response-orientierten Web-Server zu
integrieren.
82

B. Dokumentation
WSRF Das Web Service Resource Framework gehört zu einer
Reihe von OASIS-Spezifikationen für Web Services.
83

Abbildungsverzeichnis
2.1. Architektur eines Grids [21] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Komponenten des Globus-Toolkit 4 [30] . . . . . . . . . . . . . . . . . . . . . 8
2.3. Architektur des Instant-Grid [34] . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Architektur des Workflowmanagement-Systems [34] . . . . . . . . . . . . . 13
3.1. UML-Anwendungsfalldiagramm: ermittelte Stakeholder . . . . . . . . . . . 17
3.2. UML-Anwendungsfalldiagramm: grundlegende Anwendungsfälle . . . . . 19
3.3. UML-Anwendungsfalldiagramm: Übersicht des zu entwickelnden Systems 25
3.4. UML-Aktivitätsdiagramm: Anwendungsfall U10 . . . . . . . . . . . . . . . . 26
3.5. UML-Aktivitätsdiagramm: Anwendungsfall U20 . . . . . . . . . . . . . . . . 27
3.6. UML-Aktivitätsdiagramm: Anwendungsfall U30 . . . . . . . . . . . . . . . . 29
3.7. UML-Aktivitätsdiagramm: Anwendungsfall U40 . . . . . . . . . . . . . . . . 31
4.1. UML-Komponentendiagramm: Architektur der GRDB-Anwendung . . . . 37
4.2. UML-Paketdiagramm: org.instantgrid.grdb . . . . . . . . . . . . . . . . . . . 41
4.3. UML-Paketdiagramm: org.instantgrid.grdb.model . . . . . . . . . . . . . . . 42
4.4. UML-Paketdiagramm: org.instantgrid.grdb.daemon . . . . . . . . . . . . . . 43
4.5. UML-Paketdiagramm: org.instantgrid.grdb.portlet . . . . . . . . . . . . . . . 44
4.6. UML-Paketdiagramm: org.instantgrid.grdb.servlet . . . . . . . . . . . . . . . 44
4.7. UML-Paketdiagramm: org.instantgrid.grdb.config . . . . . . . . . . . . . . . 45
4.8. UML-Paketdiagramm: org.instantgrid.grdb.test . . . . . . . . . . . . . . . . 45
5.1. Screenshot: Ressourcenübersicht und -auswahl im Portlet . . . . . . . . . . . 49
5.2. Screenshots: Graphische Auswertung der Auslastungsinformationen . . . . 50
5.3. Screenshot: Daemon-Controller im Portlet . . . . . . . . . . . . . . . . . . . . 50
5.4. Screenshot: XML-Details im Portlet . . . . . . . . . . . . . . . . . . . . . . . . 51
B.1. Screenshot: Übersicht des GRDB-Portlets . . . . . . . . . . . . . . . . . . . . 66
84

Tabellenverzeichnis
2.1. Vergleich: Stromnetz und Grid. Angelehnt an [20]. . . . . . . . . . . . . . . . 5
3.1. Projekt-Ansprechpartner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Interessen der Anforderungsbeitragenden (IG-Entwickler) . . . . . . . . . . 18
3.3. Interessen der Anforderungsbeitragenden (FIRST-Entwickler) . . . . . . . . 18
3.4. Interessen der Anforderungsbeitragenden (Portal-Benutzer) . . . . . . . . . 19
3.5. Anforderungsbeschreibung: vorhandenen Probleme . . . . . . . . . . . . . . 20
3.6. Anforderungsbeschreibung: funktionale Anforderungen . . . . . . . . . . . 21
3.7. Anforderungsbeschreibung: zu speichernden Daten . . . . . . . . . . . . . . 22
3.8. Randbedingungen: technische Anforderungen . . . . . . . . . . . . . . . . . 23
3.9. Randbedingungen: Testanforderungen . . . . . . . . . . . . . . . . . . . . . . 23
3.10. Anwendungsfall U10: Konkretisierung U11 . . . . . . . . . . . . . . . . . . . 26
3.11. Anwendungsfall U10: Konkretisierung U12 . . . . . . . . . . . . . . . . . . . 27
3.12. Anwendungsfall U20: Konkretisierung U21 . . . . . . . . . . . . . . . . . . . 28
3.13. Anwendungsfall U20: Konkretisierung U22 . . . . . . . . . . . . . . . . . . . 28
3.14. Anwendungsfall U20: Konkretisierung U23 . . . . . . . . . . . . . . . . . . . 29
3.15. Anwendungsfall U30: Konkretisierung U31 . . . . . . . . . . . . . . . . . . . 30
3.16. Anwendungsfall U30: Konkretisierung U32 . . . . . . . . . . . . . . . . . . . 30
3.17. Anwendungsfall U40: Konkretisierung U41 . . . . . . . . . . . . . . . . . . . 32
3.18. Anwendungsfall U40: Konkretisierung U42 . . . . . . . . . . . . . . . . . . . 32
3.19. Anwendungsfall U40: Konkretisierung U43 . . . . . . . . . . . . . . . . . . . 33
3.20. Zuordnung der involvierten Schnittstellen . . . . . . . . . . . . . . . . . . . 33
3.21. Dialog/Interface: Ressourcendarstellung I10 . . . . . . . . . . . . . . . . . . 34
3.22. Dialog/Interface: Steuerung I20 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.23. Interface: Datenexport I30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.24. Interface: Information-Provider-Treiber I40 . . . . . . . . . . . . . . . . . . . 35
5.1. Analysierte Fehlertypen. Angelehnt an [58]. . . . . . . . . . . . . . . . . . . . 53
A.1. Verwendete Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.2. Verwendete Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
85

Literaturverzeichnis
[1] A. Chowdhury, L. Nicklas, S. Setia, and E. White, “Supporting Dynamic Space-sharing
on Clusters of Non-dedicated Workstations,” Proceedings of the 17th International Conference
on Distributed Computing Systems (ICDS-97), pp. 28–30, 1997.
[2] A. Acharya, G. Edjlali, and J. Saltz, “The utility of exploiting idle workstations for parallel
computation,” ACM SIGMETRICS Performance Evaluation Review, vol. 25, no. 1,
pp. 225–234, 1997.
[3] M. Litzkow and M. Livny, “Experiences with the condor distributed batch system,”
in IEEE Workshop on Experimental Distributed Systems, 1990, pp. 97–101.
[4] D. Anderson, J. Cobb, E. Korpela, M. Lebofsky, and D. Werthimer, “SETI@ home: an
experiment in public-resource computing,” Communications of the ACM, vol. 45, no. 11,
pp. 56–61, 2002.
[5] S. Larson, C. Snow, M. Shirts, and V. Pande, “Folding@home and genome@home:
Using distributed computing to tackle previously intractable problems in computational
biology,” Computational Genomics, 2002.
[6] B. Oestereich, Objektorientierte Softwareentwicklung: Analyse und Design mit der UML
2.0. Oldenbourg Wissenschaftsverlag GmbH, München, 2004.
[7] R. Dumke, “Software Engineering: Eine Einführung für Informatiker und Ingenieure:
Systeme, Erfahrungen, Methoden, Tools,” Vieweg-Verlag, Braunschweig, 2001.
[8] H. Balzert, Lehrbuch der Software-Technik. Spektrum Akademischer Verlag, Heidelberg,
2001.
[9] T. S. G. I. Inc., “The chaos report,” Empirische Untersuchungen über Projekte in
den USA, 2001, fetched on the 20th of June 2006. [Online]. Available: http:
//www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf
[10] C. Rupp, Requirements-Engineering und -Management. Hanser Fachbuchverlag, 2004.
[11] A. H. D. Bernd Brügge, Objektorientierte Softwaretechnik mit UML, Entwurfsmustern und
Java. Pearson Education Deutschland GmbH, 2004.
86

Literaturverzeichnis
[12] I. Foster and C. Kesselman, “The grid: Blueprint for a new computing infrastructure,”
Morgan Kaufmann, Tech. Rep., 1999.
[13] I. Foster, C. Kesselman, and S. Tuecke, “The Anatomy of the Grid: Enabling Scalable
Virtual Organizations,” International Journal of High Performance Computing Applications,
vol. 15, no. 3, pp. 200–222, 2001.
[14] I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke, “The physiology of the grid,” IBM
Corporation, Poughkeepie, NY 12601, Tech. Rep., June 2002.
[15] I. Foster, “What is the grid? a three point checklist,” July 2002.
[16] I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke, “A security architecture for
computational grids,” in ACM Conference on Computer and Communications Security,
1998, pp. 83–92, fetched on the 13rd of August 2006. [Online]. Available:
http://citeseer.ist.psu.edu/foster98security.html
[17] M. Humphrey and M. Thompson, “Security implications of typical grid computing
usage scenarios,” in Proceedings of Intl Symposium on High Performance Distributed Computing.
(HPDC), San Francisco, CA., August 2001, pp. 7–9.
[18] C. Catlett, “In search of gigabit applications,” Communications Magazine, IEEE, vol. 30,
no. 4, pp. 42–51, 1992.
[19] T. DeFanti, I. Foster, M. Papka, R. Stevens, and T. Kuhfuss, “Overview of the i-way:
Widearea visual supercomputing,” in International Journal of Supercomputer Applications,
vol. 10, 1996, pp. 123–130.
[20] CERN - European Organization for Nuclear Research, “Gridcafé - a brief
explanation of the grid,” fetched on the 21st of September 2006. [Online]. Available:
http://gridcafe.web.cern.ch/gridcafe
[21] I. Foster, “The Grid: A New Infrastructure for 21st Century Science,” Physics Today,
vol. 55, no. 2, pp. 42–47, 2002.
[22] P. Janson, J. Dayka, A. Nadalin, N. Nagaratnam, F. Siebenlist, V. Welch, I. Foster, and
S. Tuecke, “The security architecture for open grid services,” IBM Corporation, Zurich
Research Lab, Switzerland and Mathematics and Computer Science Division, Argonne
National Laboratory, Argonne, Tech. Rep., July 2002.
[23] I. Foster and C. Kesselman, “Globus: A metacomputing infrastructure toolkit,”
The International Journal of Supercomputer Applications and High Performance Computing,
vol. 11, no. 2, pp. 115–128, Summer 1997, fetched on the 21st of September 2006.
[Online]. Available: http://citeseer.ist.psu.edu/article/foster96globu.html
87

Literaturverzeichnis
[24] I. Foster, “A globus primer,” An Early and Incomplete Draft, August 2005.
[25] M. Litzkow, M. Livny, and M. Mutka, “Condor-a hunter of idle workstations,” Distributed
Computing Systems, 1988., 8th International Conference on, pp. 104–111, 1988.
[26] W. Gentzsch et al., “Sun Grid Engine: Towards Creating a Compute Power Grid,”
Proceedings of the First IEEE/ACM International Symposium on Cluster Computing and the
Grid, 2002.
[27] A. Natrajan, A. Nguyen-Tuong, M. Humphrey, M. Herrick, B. Clarke, and A. Grimshaw,
“The Legion Grid Portal,” Concurrency and Computation: Practice and Experience,
vol. 14, no. 13-15, pp. 1365–1394, 2002.
[28] R. Buyya, D. Abramson, and J. Giddy, “Nimrod/g: An architecture for a resource
management and scheduling system in a global computational grid,” in Proceedings
of the HPC ASIA2000, the 4th International Conference on High Performance Computing in
Asia-Pacific Region, Beijing, China. IEEE Computer Society Press, USA, 2000.
[29] D. Erwin et al., “UNICORE: A Grid computing environment,” Concurrency and Computation:
Practice and Experience, vol. 14, no. 13-15, pp. 1395–1410, 2002.
[30] Globus Documentation Project, “The Globus Toolkit 4 Programmer’s Tutorial,”
fetched on the 21st of September 2006. [Online]. Available: http://gdp.globus.org/
gt4-tutorial
[31] ——, “GT4 Admin Guide,” fetched on the 22nd of September 2006. [Online].
Available: http://www.globus.org/toolkit/docs/4.0/admin/docbook
[32] Leibniz-Rechenzentrum der Wissenschaften, “Installationsanleitung für Globus
Toolkit 4.0.1,” fetched on the 22nd of September 2006. [Online]. Available:
http://www.grid.lrz.de/de/mware/globus/GT4InstallGuide1-0.html
[33] R. Ho, K. Yin, D. Lee, D. Hung, C. Wang, and F. Lau, “InstantGrid: A Framework for
On-Demand Grid Point Construction,” LECTURE NOTES IN COMPUTER SCIENCE,
pp. 911–914, 2004.
[34] Instant-Grid-Projekt, “Vorträge und Publikationen,” fetched on the 21st of September
2006. [Online]. Available: http://instant-grid.de/?q=de/node/80
[35] H.-W. P. Martin Alt, Andreas Hoheisel and S. Gorlatch, “Using High Level Petri-Nets
for Describing and Analysing Hierarchical Grid Workflows,” in Proceedings of the CoreGRID
Integration Workshop, 2005.
88

Literaturverzeichnis
[36] A. Hoheisel, “Grid Workflow Execution Service (GWES),” 2006,
fetched on the 21st of September 2006. [Online]. Available:
http://www.gridwork\begingroup\let\relax\relax\endgroup[Pleaseinsert\
PrerenderUnicode{ïňĆ}intopreamble]ow.org/kwfgrid/gwes/docs
[37] P. C. Group, “Studie zur effizienz von projekten in unternehmen,”
Offizielle Fallstudien, 2004, fetched on the 20th of June
2006. [Online]. Available: http://www.paconsultinggroup.com/NR/rdonlyres/
408B35CB-1C45-49BF-8A71-2F608C1D7196/0/2003_EffizienzStudie_final.pdf
[38] W3C, “XML Path Language (XPath) - Recommendation,” November 1999, fetched
on the 20th of June 2006. [Online]. Available: http://www.w3.org/TR/xpath
[39] ——, “XQuery 1.0: An XML Query Language - Candidate Recommendation,” June
2006, fetched on the 20th of June 2006. [Online]. Available: http://www.w3.org/TR/
xquery/
[40] L. M. Andreas Laux, “XUpdate Working Draft,” September 2000, fetched on the
20th of June 2006. [Online]. Available: http://xmldb-org.sourceforge.net/xupdate/
xupdate-wd.html
[41] IEEE, “Ieee std 830-1998,” IEEE Computer Society Press, USA, Tech. Rep., 1988,
fetched on the 21st of September 2006. [Online]. Available: http://ieeexplore.ieee.
org/xpl/tocresult.jsp?isNumber=15571
[42] M. Meisinger, A. Rausch, M. Deubler, M. Gnatz, U. Hammerschall, I. Küffer, and S. Vogel,
“Das V Modell 200x - ein modulares Vorgehensmodell,” in 11. Workshop der Fachgruppe
WI-VM der Gesellschaft für Informatik e.V. (GI) zur Akzeptanz von Vorgehensmodellen,
R. Kneuper, R. Petrasch, and M. Wiemers, Eds. Shaker Verlag, 2004.
[43] A. Rausch, C. Bartelt, T. Ternité, and M. Kuhrmann, “The V-Modell XT Applied -
Model-Driven and Document-Centric Development,” in 3rd World Congress for Software
Quality, VOLUME III, Online Supplement, no. 3-9809145-3-4. International Software
Quality Institute GmbH, sep 2005, pp. 131 – 138.
[44] U. D. of Defense, “Software Requirements Specification, DI-MCCR-80025A,” Feb
1988.
[45] H. Partsch, Requirements-Engineering systematisch. Springer-Verlag Berlin, 1998.
[46] A. Cockburn, Writing Effective Use Cases. Addison-Wesley, 2001.
[47] C. Alexander, S. Ishikawa, M. Silverstein, et al., A pattern language. Oxford Univ. Pr.,
1977.
89

Literaturverzeichnis
[48] R. J. Erich Gamma, Richard Helm and J. Vlissides, Design Patterns - Elements of Reusable
Object-Oriented Software. Addison-Wesley, 2004.
[49] P. Avgeriou and U. Zdun, “Architectural patterns revisited–a pattern language,” 10th
European Conference on Pattern Languages of Programs (EuroPlop 2005), Irsee, Germany,
July, 2005.
[50] Java Community Process, “JSR-154 Servlet Specification,” Mai 2006, fetched on the
20th of June 2006. [Online]. Available: http://jcp.org/aboutJava/communityprocess/
final/jsr154
[51] ——, “JSR-168 Portlet Specification,” October 2003, fetched on the 20th of June 2006.
[Online]. Available: http://jcp.org/aboutJava/communityprocess/final/jsr168
[52] A. Spillner and T. Linz, Basiswissen Softwaretest. dpunkt-Verl., 2004.
[53] W. E. Perry, Software testen. mitp, 2003.
[54] G. Weinberg, The psychology of computer programming. Van Nostrand Reinhold Co.
New York, NY, USA, 1988.
[55] B. Schneiderman, “Software Psychology,” Winthrop, Cambridge, Mass, 1980.
[56] T. Grams, Denkfallen und Programmierfehler. Springer, 1990.
[57] E. Allen, Bug patterns in Java. Apress, 2002.
[58] J. S. F. Nick Rutar, Christian B. Almazan, “A Comparison of Bug Finding Tools for
Java,” University of Maryland, College Park, 2004, fetched on the 20th of June 2006.
[Online]. Available: http://www.cs.umd.edu/~jfoster/papers/issre04.pdf
[59] D. Hovemeyer and W. Pugh, “Finding Bugs Is Easy,” 2003, fetched on the 28th of June
2006. [Online]. Available: http://findbugs.sourceforge.net/docs/oopsla2004.pdf
[60] R. Crew et al., “ASTLOG: A language for examining abstract syntax trees,” Proceedings
of the USENIX Conference on Domain-Specific Languages, pp. 229–242, 1997.
[61] C. Artho, “Finding faults in multi-threaded programs,” 2001, master’s thesis, ETH
Zürich.
[62] J. C. Corbett, M. B. Dwyer, J. Hatcliff, S. Laubach, C. S. Pasareanu, Robby, and
H. Zheng, “Bandera: Extracting finite-state models from java source code,” in In Proceedings
of the 22nd International Conference on Software Engineering, Limerick Ireland,
2000, p. 439–448.
90

Literaturverzeichnis
[63] D. R. Cok1 and J. R. Kiniry2, “Esc/java2: Uniting esc/java and jml. progress
and issues in building and using esc/java2,” Nijmegen Institute for Computing and
Information Science, University of Nijmegen, The Netherlands, 2004, fetched on the 21st
of September 2006. [Online]. Available: http://secure.ucd.ie/products/opensource/
ESCJava2/ESCTools/papers/NIII-R0413.pdf
[64] G. Leavens, A. Baker, and C. Ruby, “JML: A notation for detailed design,” Behavioral
Specifications of Businesses and Systems, pp. 175–188, 1999.
[65] G. T. L. Patrice Chalin, Joe Kiniry and E. Poll, “Beyond assertions: Advanced specification
and verification with jml and esc/java2,” Proceedings of Formal Methods for
Components and Object (FMCO) Amsterdam, The Netherlands, 2006.
[66] G. Myers, Methodisches Testen von Programmen. Oldenbourg, 1989.
[67] H. Sneed and M. Winter, Testen objektorientierter Software. Hanser, 2002.
[68] E. Riedemann, Testmethoden für sequentielle und nebenläufige Software-Systeme. Teubner,
1997.
[69] B. Boehm, “Guidelines for Verifying and Validating Software Requirements and Design
Specifications,” in Proceedings of Euro IFIP, 1979, pp. 711–719.
[70] K. Beck and E. Gamma, “JUnit Cookbook,” fetched on the 21st of September 2006.
[Online]. Available: http://junit.sourceforge.net/doc/cookbook/cookbook.htm
[71] Java Community Process, “JSR-286 Portlet Specification,” September 2006, fetched on
the 20th of September 2006. [Online]. Available: http://jcp.org/en/jsr/detail?id=286
[72] C.-H. A. Hsieh, J. C. Gyllenhaal, and W. mei W. Hwu, “Java bytecode to native code
translation: the caffeine prototype and preliminary results,” in MICRO 29: Proceedings
of the 29th annual ACM/IEEE international symposium on Microarchitecture. Washington,
DC, USA: IEEE Computer Society, 1996, pp. 90–99.
[73] J. Raskin, The Humane Interface. New Directions for Designing Interactive Systems. Addison
Wesley, 2000.
[74] S. Krug, Don’t Make Me Think! A Common Sense Approach to Web Usability. New Riders,
2005.
[75] W. Ruh, F. Maginnis, and W. Brown, Enterprise Application Integration: A Wiley Tech
Brief. John Wiley, 2001.
91

Danksagung
An dieser Stelle möchte ich mich herzlich bei Herrn Prof. Dr. Neumair bedanken, der mir
die Anfertigung der Arbeit an der GWDG ermöglichte. Besonderer Dank gilt Prof. Dr.
Haan und meinem Betreuer Dr. Boehme für ihre fachliche und persönliche Unterstützung
während der letzten sechs Monate. Bedanken möchte ich mich auch bei allen Mitarbeitern
der „Arbeitsgruppe A“ für die wöchentlichen Diskussionsrunden und das angenehme Arbeitsklima.
Nicht zuletzt bedanke ich mich bei meiner Familie und meiner Freundin. Ihr Verständnis
und ihre Unterstützung haben maßgeblich am Erfolg der Arbeit beigetragen.
92