Schriftliche Ausarbeitung - Alexander Willner | Masterarbeit
Schriftliche Ausarbeitung - Alexander Willner | Masterarbeit
Schriftliche Ausarbeitung - Alexander Willner | Masterarbeit
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Georg-August-Universität<br />
Göttingen<br />
Zentrum für Informatik<br />
<strong>Masterarbeit</strong><br />
im Studiengang "Angewandte Informatik"<br />
ISSN 1612-6793<br />
Nummer ZFI-BM-2006-36<br />
Entwurf und Implementierung einer<br />
Ressourcen-Datenbank für das<br />
Instant-Grid-Projekt der GWDG<br />
<strong>Alexander</strong> <strong>Willner</strong><br />
am Lehrstuhl für<br />
Praktische Informatik<br />
Bachelor- und <strong>Masterarbeit</strong>en<br />
des Zentrums für Informatik<br />
an der Georg-August-Universität Göttingen<br />
27. Oktober 2006
Georg-August-Universität Göttingen<br />
Zentrum für Informatik<br />
Lotzestraße 16-18<br />
37083 Göttingen<br />
Germany<br />
Tel. +49 (5 51) 39-1 44 14<br />
Fax +49 (5 51) 39-1 44 15<br />
Email office@informatik.uni-goettingen.de<br />
WWW www.informatik.uni-goettingen.de
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst<br />
und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet<br />
habe.<br />
Göttingen, den 27. Oktober 2006
<strong>Masterarbeit</strong><br />
Entwurf und Implementierung einer<br />
Ressourcen-Datenbank für das<br />
Instant-Grid-Projekt der GWDG<br />
<strong>Alexander</strong> <strong>Willner</strong><br />
27. Oktober 2006<br />
Erstgutachter Prof. Dr. Oswald Haan ∗<br />
Zweitgutachter Prof. Dr. Bernhard Neumair †<br />
Betreuer Dr. Christian Boehme ‡<br />
Zentrum für Informatik<br />
Georg-August-Universität Göttingen<br />
∗ Leiter der Arbeitsgruppe Anwendungs- und Informationssysteme der Gesellschaft für wissenschaftliche<br />
Datenverarbeitung mbH Göttingen.<br />
† Geschäftsführer der Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen und<br />
Inhaber des Lehrstuhls für Praktische Informatik an der Universität Göttingen.<br />
‡ Wissenschaftlicher Mitarbeiter der Arbeitsgruppe Anwendungs- und Informationssysteme der<br />
Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen.
Gegenstand der vorliegenden Arbeit ist der Entwurf und die Implementierung einer einheitlichen<br />
Ressourcen-Datenbank für das Instant-Grid-Projekt 1 der Gesellschaft für wissenschaftliche<br />
Datenverarbeitung mbH Göttingen 2 . Dieses wird innerhalb des Verbundvorhabens<br />
des D-Grid-Integrationsprojektes als Demonstrationsumgebung für Grid-Software<br />
vom Bundesministerium für Bildung und Forschung finanziert.<br />
Im Rahmen dieser Arbeit wird die automatische Erstellung einer Datenbank der im<br />
Grid vorhandenen Hardware-Ressourcen mittels existierender Information-Provider ermöglicht.<br />
Dazu ist eine entsprechende Erweiterung der Instant-Grid-Infrastruktur erforderlich.<br />
Die gesammelten Informationen werden in ein einheitliches Datenformat überführt<br />
und eine Anbindung an das Instant-Grid-Portal implementiert. In diesem Zusammenhang<br />
werden Bedienelemente zur einheitlichen Benutzeroberfläche des Portals hinzugefügt<br />
und so eine Benutzer-Schnittstelle zur Datenbank geschaffen.<br />
„Man hält die Erzeugung von Information für ein Zeichen von Intelligenz,<br />
während in Wirklichkeit das Gegenteil richtig ist: Die Reduktion, die Auswahl<br />
der Information ist die viel höhere Leistung.“ [Heinz Zemanek, österreichischer<br />
Informatiker]<br />
1 http://www.instant-grid.org<br />
2 http://www.gwdg.de
Inhaltsverzeichnis<br />
1. Einleitung 1<br />
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.2. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.3. Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
1.4. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
2. Grundlagen 4<br />
2.1. Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
2.2. Instant-Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.3. Grid-Workflowmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
3. Anforderungsanalyse 15<br />
3.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
3.2. Beschreibung der Systemidee und Zielsetzung . . . . . . . . . . . . . . . . . 15<br />
3.3. Identifizierung der Anforderungsbeitragenden . . . . . . . . . . . . . . . . . 16<br />
3.4. Identifizierung der Interessen der Anforderungsbeitragenden . . . . . . . . 16<br />
3.5. Beschreibung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 20<br />
3.6. Konkretisierung der Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . 24<br />
3.7. Beschreibung der Systemschnittstelle . . . . . . . . . . . . . . . . . . . . . . . 33<br />
4. Design 36<br />
4.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
4.2. Anwendungsarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
4.3. Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
4.4. Klassenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
5. Implementierung und Test 46<br />
5.1. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46<br />
5.2. Statische Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
5.3. Dynamische Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />
i
Inhaltsverzeichnis<br />
6. Zusammenfassung, Kritik und Ausblick 59<br />
6.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59<br />
6.2. Kritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59<br />
6.3. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
A. Verwendete Konfiguration 61<br />
A.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
A.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
B. Dokumentation 63<br />
B.1. Quelltexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
B.2. Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
B.3. GRDB-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
B.4. GRDB-Portletübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
B.5. D-GRDL-Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
Glossar 80<br />
Abbildungsverzeichnis 84<br />
Tabellenverzeichnis 85<br />
Literaturverzeichnis 86<br />
ii
1. Einleitung<br />
1.1. Motivation<br />
Viele der weltweit verteilten, enormen Rechnerkapazitäten werden zu einem großen Teil<br />
nicht verwendet. Die Idee, ungenutzte Hardware-Ressourcen für eigene Aufgaben einzusetzen,<br />
findet nicht nur schon seit längerem in Fachkreisen Anwendung (vgl. [1, 2, 3]),<br />
sondern wird auch seit einigen Jahren in darüber hinaus bekannten Projekten (vgl. [4, 5])<br />
umgesetzt. Hierbei handelt es sich fast ausschließlich um Techniken, bei denen ungenutzte<br />
Rechenzyklen für einzelne Prozesse einer, auf mehrere Computer verteilten, Anwendung<br />
genutzt werden, um ein gemeinsames Ergebnis einer speziellen Aufgabe zu berechnen.<br />
Dies ist insbesondere bei vielen wissenschaftlichen Anwendungen notwendig, da die erforderliche<br />
Rechenleistung häufig nicht mehr von einem einzigen Computer oder einer<br />
einzigen Einrichtung zur Verfügung gestellt werden kann.<br />
Einen Schritt weiter gehen so genannte Grid-Systeme, die geforderte Dienste und Ressourcen<br />
unabhängig von ihrer räumlichen Entfernung transparent bereitstellen. Dabei ist<br />
es gleichgültig, ob es sich wie oben genannt um Rechenleistung, Speicherkapazität oder<br />
Softwareanwendungen handelt (s. Kap. 2.1). Der Aufbau und die Inbetriebnahme eines<br />
Grids und der damit zusammenhängenden Komponenten kann jedoch sehr aufwendig<br />
sein. Diesem Umstand hat das Instant-Grid-Projekt Rechnung getragen und eine selbstkonfigurierende<br />
Grid-Umgebung geschaffen (s. Kap. 2.2). Die Demonstration der Anwendungen<br />
im IG folgt jedoch sehr einfachen Mechanismen zur Verteilung von Rechenaufgaben<br />
und Identifizierung der im Netz verfügbaren Hardware-Ressourcen. Das Fraunhofer<br />
Institut für Rechnerarchitektur und Softwaretechnik (FIRST) widmet sich diesem Thema<br />
und entwickelt in diesem Zusammenhang ein Grid-Workflowmanagement-System (s.<br />
Kap. 2.3). Die Bereitstellung und Visualisierung der hierfür benötigten Informationen sind<br />
der Kern dieser Arbeit.<br />
1.2. Zielsetzung<br />
Das Ziel der vorliegenden Arbeit ist der Entwurf und die Implementierung einer Ressourcen-Datenbank<br />
für das Instant-Grid-Projekt. Das zu entwickelnde System hat zur Aufgabe,<br />
Informationen über im Netz vorhandene Hardware-Ressourcen zu sammeln und<br />
diese in einer im System zugänglichen Datenbank zu speichern. In diesem Zusammen-<br />
1
1. Einleitung<br />
hang sollen die vorhandene Instant-Grid-Infrastruktur erweitert und Bedienelemente zur<br />
einheitlichen Benutzeroberfläche des Anwender-Portals hinzugefügt werden.<br />
Die technischen Voraussetzungen und detaillierten Anforderungen an ein solches System<br />
sind herauszuarbeiten und ein geeigneter Lösungsweg aufzuzeigen. Die enge Zusammenarbeit<br />
mit dem Projektpartner FIRST spielt dabei eine wesentliche Rolle.<br />
1.3. Methodik<br />
Aspekte der Integration in das vorhandene Projekt, die Nutzung einer Vielzahl verschiedener<br />
Technologien und das Zusammenwirken unterschiedlicher Reflexionsebenen durch<br />
mehrere Projektbeteiligte sind zu beachten. Dies muss sich in der Vorgehensweise und der<br />
angebrachten Wahl der entsprechenden Methoden der Informatik widerspiegeln.<br />
Die im Folgenden eingesetzte Methodik zur Analyse und Entwurf des Systems basiert<br />
auf dem sog. „Object Engineering Process“ (OEP) 1 und orientiert sich weitestgehend an<br />
dem Lehrbuch von Bernd Oestereich[6]. Ziel des OEP ist die Entwicklung hochwertiger<br />
Anforderungsformulierungen als Grundlage für die Systementwicklung. Ein strukturiertes<br />
Vorgehen in diesem Bereich ist besonders wichtig, da Fehler in der Anforderung ein exponentielles<br />
Wachstum des Aufwands zur Korrektur im Laufe des Entwicklungsprozesses<br />
zur Folge hat (vgl. [7, 8]). Diese Beobachtung unterstreicht auch das Ergebnis einer Studie<br />
der Standish Group[9] in der angegeben wird, dass die Gründe für das Fehlschlagen von<br />
Projekten zu über ein Viertel in einer unvollständigen Dokumentation der Anforderungen<br />
und einer unzureichenden Einbeziehung der Nutzer liegen.<br />
Aufgrund des technischen Charakters der zu entwickelnden Anwendung wurde das<br />
Verfahren zusätzlich durch weitere Aspekte aus den einschlägigen Fachbüchern von Helmut<br />
Balzert[8], Chris Rupp[10] und Bernd Brügge[11] modifiziert und ergänzt. Die verschiedenen<br />
Kernabschnitte der Softwareentwicklung, Analyse, Design, Implementierung<br />
und Test, werden im Entwicklungsprozess iterativ und inkrementell durchlaufen. Dadurch<br />
können schrittweise Zwischenergebnisse präsentiert und damit eine kontinuierliche und<br />
effektive Kommunikation zwischen den beteiligten Gruppen gewährleistet werden.<br />
1.4. Aufbau<br />
Nach der einleitenden Beschreibung des genauen Umfeldes der Arbeit wird, mit Blick<br />
auf die Integration der Arbeit in die verschiedenen Projekte, ein entsprechendes Anforderungsprofil<br />
abgeleitet. Die detaillierte Analyse der Anforderungen und Rahmenbedingungen<br />
bildet im Anschluss die Grundlage für das Design der Anwendung. Gefolgt von der<br />
1 Eine Entwicklung der oose.de GmbH (s. http://www.oose.de/oep/).<br />
2
1. Einleitung<br />
Beschreibung der entsprechenden Implementation, die sich insbesondere durch kontinuierliche<br />
Maßnahmen der Qualitätssicherung auszeichnet, wird abschließend eine kritische<br />
Zusammenfassung der Arbeit und ein Ausblick auf weiterführende Tätigkeiten gegeben.<br />
Die verwendete Konfiguration und weitere Dokumentationen finden sich im Anhang.<br />
3
2. Grundlagen<br />
2.1. Grid<br />
2.1.1. Definition<br />
Bei einem Grid handelt es sich um eine Infrastruktur, die eine integrierte, gemeinschaftliche<br />
Verwendung von meist geographisch auseinander liegenden, autonomen Ressourcen<br />
erlaubt. Versuche einer einheitlichen Definition in der Literatur gibt es jedoch viele (vgl.<br />
[12, 13, 14]). Dieser Problematik hat sich Ian Foster, einer der treibenden Mitbegründer<br />
der Grid-Technologie der Universität Chicago, angenommen und hat eine übersichtliche<br />
3-Punkte-Checkliste[15] aufgestellt. Die Eigenschaften eines Grid-Systems werden in kurzen<br />
Worten wie folgt definiert: Ein Grid. . .<br />
(i) . . . koordiniert Ressourcen, die nicht einer zentralen Instanz untergeordnet sind...<br />
Ein Grid koordiniert und integriert Ressourcen und Benutzer unterschiedlicher administrativer<br />
Domänen innerhalb des selben Unternehmens oder innerhalb unterschiedlicher<br />
Länder. In diesem Zusammenhang werden u.a. auf die Bereiche Sicherheit,<br />
Abrechnung und Mitgliedschaft Rücksicht genommen (vgl. [16, 17]). Ressourcen<br />
können unter anderem Cluster, Massenspeicher, Datenbanken, Anwendungen<br />
oder Messgeräte sein.<br />
(ii) . . . und verwendet offene, standardisierte Protokolle und Schnittstellen,...<br />
Ein Grid nutzt offene und allgemein gehaltene Protokolle und Schnittstellen, die<br />
grundsätzliche Funktionen für die Authentifizierung, die Autorisierung, die Ressourcen-Ermittlung<br />
und den Ressourcen-Zugriff gewährleisten.<br />
(iii) . . . um nicht triviale Dienstgüten bereitzustellen.<br />
Ein Grid verwendet bestehende Ressourcen in einer koordinierten Art und Weise, um<br />
verschiedene Dienstgüten bereitzustellen, abhängig von beispielsweise der Antwortzeit,<br />
dem Durchsatz, der Erreichbarkeit oder Sicherheit. Oder es erfolgt, um komplexen<br />
Benutzererwartungen zu entsprechen, eine Neueinteilung mehrerer Ressourcentypen,<br />
damit der Nutzen des kombinierten Systems signifikant größer ist als die<br />
Summe seiner Teile.<br />
Diese Definition ist hilfreich bei der Abgrenzung verschiedener Technologien zu einem<br />
Grid. So werden sehr häufig Systeme, die in die Bereiche des „Distributed computing“,<br />
4
2. Grundlagen<br />
„Cluster computing“, „Peer to peer computing“ oder „Meta computing“ fallen, fälschlicherweise<br />
als Grid-Systeme bezeichnet. Wenngleich viele Aspekte der genannten Technologien<br />
in einem Grid Anwendung finden.<br />
2.1.2. Herkunft<br />
Konzepte für die Verteilung rechenintensiver Aufgaben hat es bereits in den 60er Jahren<br />
gegeben. Die meisten der heutigen Forschungsarbeiten an Grid-Systemen haben ihren Ursprung<br />
jedoch in frühen Experimenten mit Hochgeschwindigkeitsnetzen, wie etwa innerhalb<br />
der Gigabit-Testumgebung an der University of Illinois im Jahr 1992[18]. Insbesondere<br />
jedoch machte das I-Way-Experiment[19] im Jahre 1995, in dem 17 Einrichtungen in den<br />
USA und Kanada zu einem Hochgeschwindigkeitsnetz zusammengeschlossen wurden,<br />
die Grid-Technologie außerhalb des alleinigen Forschungsfeldes der Netzwerktechnik publik.<br />
Der Begriff „Grid“ hat seinen Ursprung in dem Vergleich dieser Technologie zum Stromnetz<br />
(engl. „Power Grid“). Demnach soll das Grid einem Benutzer ebenso einfach Ressourcen<br />
wie z.B. Rechenleistung oder Speicherplatz über das Internet zur Verfügung stellen,<br />
wie es möglich ist Strom aus einer Steckdose zu beziehen (s. Tab. 2.1).<br />
Tabelle 2.1.: Vergleich: Stromnetz und Grid. Angelehnt an [20].<br />
Eigenschaft Stromnetz Grid<br />
Infrastruktur Verbindung verschiedener<br />
Transparenz<br />
Kraftwerke und Wandlerstationen<br />
über Stromleitungen<br />
Herkunft des Stroms für den<br />
Endnutzer unbedeutend.<br />
Verfügbarkeit Eine sehr gute Infrastruktur des<br />
Stromnetzes ist durch die Anbindung<br />
fast aller Haushalte ge-<br />
geben.<br />
Abrechnung Die Abrechnung erfolgt auf<br />
Grundlage der verwendeten<br />
Menge an Strom.<br />
2.1.3. Zielsetzung<br />
Verbindung verschiedener Ressourcen<br />
über das Internet mit<br />
Hilfe offener Standards.<br />
Herkunft der Ressource (z.B. Re-<br />
chenleistung) unbedeutend.<br />
Durch die Nutzung verschiedener<br />
Plattformen und des Internets<br />
ist eine sehr gute Infrastruk-<br />
tur gegeben.<br />
Die Abrechnung erfolgt auf<br />
Grundlage der verwendeten<br />
Mengen an Ressourcen.<br />
Die motivierende Zielsetzung, die zu der Entwicklung der Grid-Technologie geführt hat,<br />
war die gemeinsame, koordinierte Nutzung von Ressourcen und die gemeinsame Lösung<br />
5
2. Grundlagen<br />
von Problemen innerhalb dynamischer, institutionsübergreifender, virtueller Organisationen<br />
(vgl. [13]). Das bedeutet, nach der Festlegung von Abrechnungsdaten und Rechten<br />
soll ein direkter Zugang zu beispielsweise Rechenleistungen, Anwendungen, Daten oder<br />
Instrumenten gemeinschaftlich ermöglicht werden. Eine virtuelle Organisation (VO) ist<br />
in diesem Zusammenhang ein dynamischer Zusammenschluss von Individuen und/oder<br />
Institutionen, die gemeinsame Ziele bei der Nutzung des Grids verfolgen.<br />
Zwar liegt der Fokus vieler Arbeiten im Bereich des verteilten Rechnens, dennoch ist<br />
oberstes Ziel, analog zu der Entstehung des Internets, die Entwicklung eines einheitlichen,<br />
globalen Grids. Dieses könnte in vielen Bereichen u.a. der Wissenschaft, Medizin und Lehre<br />
eingesetzt werden (vgl. [21, 20]).<br />
2.1.4. Architektur<br />
2.1.4.1. Einleitung<br />
Das Ergebnis nach etwa einem Jahrzehnt der intensiven Forschung und Entwicklung von<br />
Grid-Technologien war unter anderem ein Konsens über die Anforderungen und die Architektur<br />
eines Grids. Auch wurden offene Standardprotokolle zur Nachrichtenkommunikation<br />
und Steuerung entworfen, um eine Basis für weitere interoperable Entwicklungen<br />
zu schaffen. Die Bedeutung solch einer Grundlage wird in Abbildung 2.1 ersichtlich.<br />
Abbildung 2.1.: Architektur eines Grids [21]<br />
Protokolle und Schnittstellen können abhängig von ihrer Funktion in verschiedene Kategorien<br />
eingeteilt werden. Die Architektur eines Grids wird daher häufig funktional in<br />
verschiedene Ebenen aufgeteilt. Komponenten auf einer Schicht besitzen ähnliche Charakteristiken<br />
und können auf Fähigkeiten und Verhaltensweisen von tieferen Schichten aufbauen.<br />
6
2. Grundlagen<br />
Fabric. Die unterste Ebene dient dazu, ein gemeinsames Interface auf alle denkbaren<br />
Arten von Ressourcen zur Verfügung zu stellen. Von höheren Schichten aus erfolgt der<br />
Zugriff über standardisierte Verfahren. Alle Ressourcen, auf die eine solche einheitliche<br />
Schnittstelle anwendbar ist, können in das Grid-Konzept eingebunden werden. Dies beinhaltet<br />
Computer, Speichersysteme, Netzwerke oder Sensoren.<br />
Resource and connectivity protocols. Die Verbindungsschicht definiert die Grundkommunikations-<br />
und Authentifikationsprotokolle, die für das Grid benötigt werden. Während<br />
die Kommunikationsprotokolle den Austausch von Daten zwischen verschiedenen,<br />
durch die erste Ebene verbundenen Ressourcen ermöglichen, erlauben die Authentifikationsprotokolle,<br />
eine Kommunikation vertraulich stattfinden zu lassen und die Identität der<br />
beiden Kommunikationspartner sicherzustellen. Hierzu gehören auch die Delegation von<br />
Rechten und Verfahren zur einmaligen Authentifizierung (single sign-on).<br />
Auf der Ressourcenschicht wird der gemeinsame Zugriff auf einzelne Ressourcen organisiert.<br />
Dies beinhaltet die Initiierung, Beobachtung, Kontrolle, Abrechnung und die Verhandlung<br />
von Sicherheitsparametern. Ebenso werden Ressourcen zugewiesen, reserviert,<br />
beobachtet und gesteuert. Die OGSA 1 [22] ist eine noch in der Entwicklung befindliche<br />
Architektur, die in vielen Grid-Projekten die Realisierung dieser Schicht übernimmt. Das<br />
Globus Toolkit 4 (GT4) stellt eine bekannte Implementierung der OGSA-Spezifikation dar<br />
und bietet Software-Dienste und Bibliotheken, um ein Grid nach der OGSA Spezifikation<br />
zu realisieren (s. Kap. 2.1.4.2).<br />
Collective services. Die Aufgabe dieser Schicht ist die Koordination mehrerer Ressourcen.<br />
Der Zugriff auf die Ressourcen erfolgt hierbei nicht mehr direkt, sondern lediglich<br />
über die darunterliegenden Protokolle und Schnittstellen. Zu den Funktionen dieser Ebene<br />
gehören unter anderem die Erstellung eines Verzeichnisdienstes und die Bereitstellung<br />
von Monitoring-, Diagnose- und Datenreplikationsdiensten. Des Weiteren werden Grid<br />
taugliche Entwicklungssysteme zur Verfügung gestellt, um bekannte Programmiermodelle<br />
auch in der Grid-Umgebung verwenden zu können.<br />
User applications. In dieser Schicht werden alle Anwendungen zusammengefasst, die<br />
in der Umgebung einer virtuellen Organisation operieren. Die Dienste der unterliegenden<br />
Schichten werden von Benutzeranwendungen aufgerufen und können Ressourcen transparent<br />
verwenden.<br />
1 http://www.globus.org/ogsa<br />
7
2.1.4.2. Globus-Toolkit<br />
2. Grundlagen<br />
Das Globus-Toolkit 2 [23, 24] der Globus-Alliance 3 ist eine Middleware für Grid-Systeme.<br />
Obwohl es sich noch in der Entwicklung befindet, setzen, wie auch das Instant-Grid-<br />
Projekt, fast alle größeren Grid-Projekte auf dieses Toolkit auf. Es wird daher als Referenzimplementierung<br />
der OGSA-Spezifikation in diesem Zusammenhang kurz beschrieben.<br />
Das Globus-Projekt entstand aus einer Zusammenarbeit der University of Chicago und<br />
der University of Southern California unter Beteiligung von IBM und der NASA. Es basiert<br />
unter anderem auf den Erfahrungen anderer, zur Grid-Technologie verwandter Projekte<br />
wie Condor[25], Codine[26], Legion[27], Nimrod[28] und Unicore[29]. Das GT4 bietet alle<br />
notwendigen Komponenten zur Umsetzung von Grid-Systemen. Dies beinhaltet Bereiche<br />
der Sicherheit und der Daten-, Ressourcen- sowie Aufgabenverwaltung. Des Weiteren bietet<br />
es Schnittstellen und Bibliotheken für gängige Programmierumgebungen (s. Abb. 2.2).<br />
Abbildung 2.2.: Komponenten des Globus-Toolkit 4 [30]<br />
Security. Dieser Bereich umfasst Maßnahmen zur Authentifikation und Autorisierung<br />
2 http://www.globus.org/toolkit<br />
3 http://www.globus.org/alliance<br />
8
2. Grundlagen<br />
von Benutzern und Ressourcen. Die Kommunikation zwischen den Beteiligten wird abgesichert,<br />
und Funktionen zur Verwaltung von Benutzer- und Gruppenrechten werden zur<br />
Verfügung gestellt.<br />
Data Management. Module in diesem Abschnitt ermöglichen es, verteilte Daten im Grid<br />
zu lokalisieren (RLS), zu verschieben (GridFTP, RFT, DRS) und zu verwalten (OGSA-DAI).<br />
Execution Management. Die Werkzeuge zur Ausführungsverwaltung befassen sich mit<br />
der Initialisierung, Beobachtung, Planung und Koordination von verteilten Aufgaben. Von<br />
diesem Service (GRAM) machen die Scheduling-Mechanismen vom FIRST (s. Kap. 2.3) intensiven<br />
Gebrauch.<br />
Information Services. Der Informationsdienst (MDS4) und die zusammenhängenden<br />
Komponenten dienen der Überwachung und der Identifikation von Ressourcen und Diensten<br />
im Grid. Der Dienst wird als Informationsquelle vom zu entwickelnden System genutzt<br />
(s. Kap. 4).<br />
Common Runtime. Die allgemeine Laufzeitumgebung dient der plattformunabhängigen<br />
Implementierung der oben genannten Dienste. Es werden Bibliotheken bereitgestellt,<br />
die die Erstellung von Abstraktionsschichten vereinfachen und die Umsetzung von Funktionalitäten<br />
auf Basis von Web-Services (WSRF) bequem ermöglichen.<br />
Die Installation und Konfiguration des GT4 erfordert aufgrund seiner Komplexität ein hohes<br />
Maß an Fachkenntnis und einen deutlichen Zeitaufwand. Eine detaillierte Beschreibung<br />
des Vorgangs findet sich unter anderem in [31, 32]. Einen einfachen Weg zur Demonstration<br />
des Toolkits schlägt das Instant-Grid-Projekt ein.<br />
2.2. Instant-Grid<br />
2.2.1. Einleitung<br />
Das Instant-Grid-Projekt der GWDG (nicht zu verwechseln mit [33]) ist ein Partnerprojekt<br />
der D-Grid-Initiative 4 und wird vom Bundesministerium für Bildung und Forschung<br />
finanziert. Die Entwicklung erfolgt durch die Gesellschaft für wissenschaftliche Datenverarbeitung<br />
Göttingen. Unterstützt wird diese durch die Partner ed-media 5 , die FernUniver-<br />
4 http://www.d-grid.de<br />
5 http://ed-media.org<br />
9
2. Grundlagen<br />
sität in Hagen 6 , FIZ Chemie 7 und das FIRST 8 .<br />
2.2.2. Zielsetzung<br />
Das Ziel des Projektes ist, eine - auch ohne Vorkenntnisse einsetzbare - Demonstrationsumgebung<br />
für Grid-Technologien bereit zu stellen. Zur Unterstützung der Bildung einer<br />
allgemeinen und nachhaltigen Grid-Basis-Infrastruktur in Deutschland werden dabei die<br />
selben Technologien und Software-Pakete verwendet, die im Rahmen der D-Grid-Initiative<br />
empfohlen sind.<br />
Die bereitgestellten Anwendungen sollen dem Benutzer das Potential von Grids näher<br />
bringen und einen Einblick in die zugrunde liegende Grid-Technologien gewähren. Hierzu<br />
gehört unter anderem die Demonstration des Leistungsgewinns bei der Verwendung verteilter<br />
Berechnungen über die Grid-Architektur. Auf der deutschen e-Science-Konferenz 9<br />
im Mai 2007 soll das Projekt als Demonstration von Grid- Funktionalitäten und Grid-<br />
Anwendungen zum Einsatz kommen.<br />
2.2.3. Architektur<br />
Das Instant-Grid stellt eine CD-ROM (basierend auf Knoppix 10 ) zur Verfügung, mit der ein<br />
x86-Rechner gestartet werden kann. Dieser Computer dient im weiteren Verlauf als Frontend<br />
und stellt Mechanismen bereit, mit Hilfe derer weitere x86-Clients über das Netzwerk<br />
initialisiert werden können (s. 2.3(a)).<br />
Zu diesem Zweck werden während des Bootvorgangs auf dem Frontend DHCP-, TFTPund<br />
NFS-Server eingerichtet und gestartet (s. Abb. 2.3(b)). Für die Verteilung weiterer<br />
Konfigurationen wird ein zusätzlicher Dienst (Distributor) benötigt. Des Weiteren werden<br />
alle Komponenten der Grid-Middleware (GT4) und ein Zertifizierungsdienst initialisiert.<br />
Das Instant-Grid besteht aus verschiedenen Teilkomponenten, die jeweils in einer<br />
GNU/Linux-Umgebung betrieben werden (s. Abb. 2.3(c)):<br />
Instant-Grid Infrastructure. Die Infrastruktur, die im Rahmen des Instant-Grid-Projektes<br />
geschaffen wurde, besteht hauptsächlich aus zwei Teilbereichen. Der „IP-Collector“ hat<br />
unter anderem die Aufgabe, grundlegende Informationen über vorhandene Hardware-<br />
Ressourcen im Grid zu aktualisieren. Dieser Dienst berührt inhaltlich Aspekte der vorliegenden<br />
Arbeit und wird in Kapitel 3 nochmals erwähnt. Der „Distributor“ verteilt verschiedene<br />
Konfigurationsinformationen innerhalb des Grids über die NFS-Dateistruktur.<br />
6 http://www.fernuni-hagen.de<br />
7 http://www.fiz-chemie.de<br />
8 http://www.first.fraunhofer.de<br />
9 http://www.ges2007.de<br />
10 http://www.knopper.net/knoppix<br />
10
2. Grundlagen<br />
(a) Distributionsstruktur (b) Bootvorgang (c) Komponenten<br />
Abbildung 2.3.: Architektur des Instant-Grid [34]<br />
Globus Toolkit. Das GT4 und die damit zusammenhängenden Komponenten für die<br />
Dateiübertragung (GridFTP), Job-Submitierung (WS-GRAM) und Identifikation von Ressourcen<br />
und Diensten im Grid (MDS4) können vom Benutzer über die Kommandozeile<br />
oder eine webbasierte Oberfläche gesteuert werden.<br />
Apache. Neben der Kommandozeile ist die webbasierte Oberfläche, die über den Apache<br />
HTTP-Server und den Apache Servlet-Container (Tomcat) bereitgestellt wird, die wichtigste<br />
Schnittstelle zum Anwender. Die meisten Funktionen werden über das GridSphere-<br />
Portal bereitgestellt. Zusätzlich werden Informationen über die Ressourcenauslastung von<br />
Ganglia dargestellt und die Demonstrationsanwendung „POV-Ray“ gesteuert.<br />
Die Verteilung und Administration von Aufgaben innerhalb des Grids erfolgt im Instant-<br />
Grid direkt über die Schnittstelle (WS-GRAM) des GT4. Die Demonstrationsanwendungen<br />
müssen jeweils geeignete Ressourcen selbst auswählen und Ergebnisse zusammenführen.<br />
Zur Standardisierung und Erleichterung dieser Vorgänge wird ein Workflowmanagement-<br />
System des FIRST in die derzeitige Infrastruktur integriert.<br />
11
2.3. Grid-Workflowmanagement<br />
2.3.1. Einleitung<br />
2. Grundlagen<br />
Das Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik (FIRST) engagiert<br />
sich, neben der Tätigkeit als Projektpartner des Instant-Grids (IG), an verschiedenen anderen<br />
Grid-Projekten. Dazu gehören das Fraunhofer IuK Resource-Grid 11 , K-Wf-Grid 12 , CoreGrid<br />
13 und MediGrid 14 . Das FIRST entwickelt in diesem Zusammenhang den im Resource-Grid<br />
entworfenen Job Handler zu einem generischen Workflowmanagement-System<br />
für Grid-Anwendungen weiter. Teil dieses Vorhabens, welches im Rahmen des Grid Workflow<br />
Forums 15 koordiniert wird, ist die Spezifikation einer Workflow- sowie Ressourcenbeschreibungssprache<br />
und die Implementierung der hierzu notwendigen Middleware-<br />
Komponenten. Das Workflow-System soll zukünftig auch im Instant-Grid Verwendung<br />
finden.<br />
2.3.2. Zielsetzung<br />
Ziel des Workflowmanagement-Systems (WFMS) für Grid-Anwendungen ist die Verwaltung<br />
und Automatisierung von komplexen Prozessabläufen in Grid-Umgebungen. Zur<br />
Unabhängigkeit einer konkreten Infrastruktur soll dabei die Modellierung der Anwendungen<br />
auf einer abstrakten Ebene erfolgen. Eine Kompatibilität sowohl zu Grid-Technologien<br />
wie dem Globus-Toolkit, Condor oder Web-Services als auch zu Windows- und Unix-Betriebssystemen<br />
soll gewährleistet sein. Eine intuitiv bedienbare Benutzerschnittstelle soll<br />
den Anwender bei der Erzeugung und Bearbeitung von dynamischen Workflows unterstützen.<br />
Des Weiteren soll die Prozessmodellierungssprache ausdrucksstark genug sein,<br />
um die Struktur während der Laufzeit an die konkrete Grid-Infrastruktur anzupassen.<br />
2.3.3. Architektur<br />
Die Komponenten des WFMS und die Integration des Systems in die Infrastruktur des IG<br />
sind in Abbildung 2.4(a) dargestellt und werden im Folgenden kurz erläutert.<br />
GWorkflowDL. Die Grid Workflow Description Language ist eine Petri-Netz-basierte<br />
XML-Beschreibungssprache für Prozessabläufe. Eine Eigenschaft ist die Unterstützung verschiedener<br />
Abstraktionsebenen. So kann die Sprache zur Beschreibung von einfachen Kontrollaufgaben<br />
bis hin zur Formulierung von ausführbaren Grid-Operationen verwendet<br />
11 http://www.fhrg.fraunhofer.de<br />
12 http://www.kwfgrid.net<br />
13 http://www.coregrid.net<br />
14 http://www.medigrid.de<br />
15 http://www.gridworkflow.org<br />
12
n<br />
n<br />
Run<br />
Simple<br />
Globus<br />
Job<br />
Run<br />
Workflow<br />
Assemble/<br />
Monitor<br />
Workflow<br />
Application Portlet<br />
(POV-Ray, ERAMAS)<br />
Grid Workflow User<br />
Interface (GWUI)<br />
RSL (WS-GRAM)<br />
GWorkflowDL<br />
2. Grundlagen<br />
Grid Portlet<br />
GWorkflowDL<br />
Grid Workflow Execution Service<br />
(GWES)<br />
Run<br />
Simple<br />
Globus<br />
Job<br />
Run<br />
Workflow<br />
Run Application<br />
Grid Portlet<br />
User<br />
GResourceDL<br />
GWorkflowDL<br />
GResourceDL<br />
GWorkflowDL<br />
Resource<br />
Matcher<br />
Globus 4<br />
GResourceDL<br />
Web Service<br />
Exist XML DB<br />
<br />
<br />
Scheduler<br />
Web Services<br />
Ganglia<br />
(a) Grid-Workflowmanagement-System des FIRST<br />
Assemble/<br />
Monitor<br />
Workflow<br />
Application Portlet<br />
(POV-Ray, ERAMAS)<br />
Grid Workflow User<br />
Interface (GWUI)<br />
RSL (WS-GRAM)<br />
GWorkflowDL<br />
Grid Portlet<br />
GWorkflowDL<br />
Grid Workflow Execution Service<br />
(GWES)<br />
Run Application<br />
Grid Portlet<br />
User<br />
GResourceDL<br />
GWorkflowDL<br />
GResourceDL<br />
GWorkflowDL<br />
Resource<br />
Matcher<br />
Globus 4<br />
GResourceDL<br />
Web Service<br />
Exist XML DB<br />
<br />
<br />
Scheduler<br />
Web Services<br />
GRDL<br />
GRDL<br />
View Resources /<br />
Control Daemon<br />
Gangliia-<br />
Connector<br />
GRDB Portlet<br />
GRDB Portlet<br />
GRDB Daemon<br />
GRDB Daemon<br />
or<br />
Ganglia MDS4<br />
(b) Grid-Workflowmanagement-System mit Entwicklungen der vorliegenden Arbeit<br />
Abbildung 2.4.: Architektur des Workflowmanagement-Systems [34]<br />
13<br />
MDS4-<br />
Connector
werden (s. [35]).<br />
2. Grundlagen<br />
D-GRDL. Die D-Grid Resource Description Language ist eine XML-Beschreibung von<br />
Ressourcen innerhalb eines Grids. Ziel der Spezifikation ist eine gemeinsame Sprache zu<br />
definieren, die es erlaubt Ressourcen unterschiedlicher Grid-Infrastrukturen mit einem<br />
einzigen Formalismus zu beschreiben (s. Anhang B.5).<br />
XML DB. Die XML-Datenbank dient als Container und Austauschmedium für die Beschreibungen<br />
der im Grid vorhandenen Ressourcen und der formulierten Prozesse.<br />
Application Portlet. Das Portlet der jeweiligen Anwendung dient dem Benutzer als<br />
Schnittstelle zur Applikation und generiert die notwendige Beschreibung der Prozessabläufe.<br />
Im Rahmen des Instant-Grids werden dies voraussichtlich Pov-Ray und ERAMAS 16<br />
sein.<br />
GWUI. Das Grid Workflow User Interface unterstützt den Benutzer bei der Auswahl<br />
von Diensten und der Erstellung komplexer Workflows für Grid-Anwendungen. Vorhandene<br />
Prozessabläufe können visualisiert und komfortabel bearbeitet werden.<br />
GWES. Der Grid Workflow Execution Service beinhaltet verschiedene Komponenten<br />
unter anderem zur Analyse und Verifikation von Prozessabläufen und dient der Ausführung<br />
von Programmen im Grid (s. [36]).<br />
Resource Matcher. Der Resource Matcher sucht auf Grundlage der in der GWorkflowDL<br />
angegebenen Eigenschaften passende Ressourcen zur Ausführung einer Anwendung aus.<br />
Die jeweiligen Ressourcen, die zu überprüfen sind, wurden zuvor in der D-GRDL beschrieben<br />
und befinden sich in der XML-Datenbank.<br />
Scheduler. Der Scheduler optimiert auf Grundlage der Auslastungsinformationen aus<br />
den D-GRDL-Beschreibungen der passenden Ressourcen und weiteren Angaben aus der<br />
zugehörigen GWorkflowDL die Auswahl der Ressourcen für die Ausführung von Grid-<br />
Anwendungen.<br />
Der oben beschriebe Ansatz geht von bereits existierenden Beschreibungen der im Grid<br />
vorhandenen Ressourcen aus. Diesem Teilaspekt widmet sich die vorliegende Arbeit und<br />
ergänzt die vorhandene Architektur um weitere Komponenten (s. Abb. 2.4(b)). Eine detaillierte<br />
Beschreibung des Systems, im Weiteren als Grid Resource Database (GRDB) bezeichnet,<br />
findet sich in den folgenden Kapiteln.<br />
16 http://www.eramas.de<br />
14
3. Anforderungsanalyse<br />
3.1. Einleitung<br />
Gründe für das Scheitern von Software-Projekten gibt es viele. Empirische Untersuchungen<br />
(siehe u.a. [37, 9]) haben ergeben, dass insbesondere unklare Anforderungen und die<br />
fehlende Einbeziehung der Endnutzer zu den mit Abstand häufigsten Fehlern zählen. Die<br />
Analyse, als Phase des Software-Entwicklungsprozesses, ist daher einer der wichtigsten<br />
Schritte zum fertigen Produkt. Auch sorgen Ungenauigkeiten in den frühen Phasen des<br />
Entwicklungsprozesses zu einem Summationseffekt, in dem sich Fehler fortpflanzen und<br />
potenzieren. Die Dokumentation der Anforderungen dient daher allen an der Systementwicklung<br />
Beteiligten als Kommunikations-, Diskussions- und Argumentationsgrundlage.<br />
Ihre Aufgabe ist es, das gemeinsame Verständnis und Wissen der Teammitglieder widerzuspiegeln<br />
(vgl. [10, 6]). Die Aufnahme und Erfassung der Anforderungen sollte vor allem<br />
vollständig, verständlich und identifizierbar sein. Insbesondere die eindeutige Nummerierung<br />
der Anforderungen und deren Qualifizierung helfen bei der Querreferenzierung und<br />
der späteren Verifizierung und Abnahme des Produktes. Die Nummerierung erfolgt dabei<br />
zunächst in Zehnerschritten, um ggf. zusätzliche Anforderungen nachtragen zu können.<br />
Die Grundlagen der im Folgenden beschriebenen Anforderungen und Ziele ergaben sich<br />
aus Interviews mit den jeweiligen Fachexperten, Anforderungsverantwortlichen und Systembetroffenen.<br />
Durch die Wahl eines inkrementellen Entwicklungsprozesses wurden Erweiterungen<br />
der Anforderungen im Laufe des Projektes unterstützt und auf Änderungen<br />
konnte flexibel eingegangen werden.<br />
3.2. Beschreibung der Systemidee und Zielsetzung<br />
Die Formulierung der Systemidee ist das Ergebnis von Diskussionen innerhalb der Arbeitsgruppe<br />
für Anwendungssysteme der GWDG. Diese wurde im Laufe von Gesprächen<br />
mit Mitgliedern der Projektgruppe des FIRST ergänzt.<br />
Das zu entwickelnde System soll die existierende Instant-Grid-Infrastruktur dahingehend<br />
erweitern, dass eine einheitliche Ressourcen-Datenbank zur Verfügung steht. Diese soll<br />
automatisch mit Daten über die im Grid vorhandenen Hardware-Ressourcen mittels existierender<br />
Information-Provider aktualisiert werden. Die gesammelten Informationen sollen<br />
in ein einheitliches Datenformat überführt und insbesondere eine Anbindung an das<br />
15
3. Anforderungsanalyse<br />
Instant-Grid-Portal geschaffen werden. In diesem Zusammenhang sind Bedienelemente<br />
zur Benutzeroberfläche des Portals hinzuzufügen, um so eine Benutzer-Schnittstelle zur<br />
Datenbank zu schaffen. Des Weiteren besteht eine enge Kooperation mit dem Institut für<br />
Rechnerarchitektur und Softwaretechnik der Fraunhofer Gesellschaft. Die dort entwickelten<br />
Systeme (insbesondere der Scheduler und Matcher) sollen direkten Zugriff auf diese<br />
Datenbank haben und eine gemeinsame Datenbasis nutzen können.<br />
3.3. Identifizierung der Anforderungsbeitragenden<br />
Bevor detailliertere Anforderungen an das zu erstellende System erhoben werden können,<br />
müssen alle wichtige Projektbeteiligte identifiziert und diesen geeignete Ansprechpartner<br />
zugeordnet werden. Können nicht alle Mitwirkende eines Systems ermittelt werden, so<br />
erhöht dies die Wahrscheinlichkeit, eine Vielzahl von Anforderungen nicht rechtzeitig zu<br />
erkennen.<br />
3.3.1. Stakeholder<br />
Der Begriff Stakeholder (engl. Interessenvertreter) bezeichnet allgemein alle Projektbeteiligte,<br />
die durch das entwickelte System direkt oder indirekt betroffen sind. Die in Abbildung<br />
3.1 dargestellten Gruppen haben entscheidenden Einfluss auf die gestellten Anforderungen<br />
an das System und nehmen im Laufe der Anforderungsanalyse eine zentrale Rolle<br />
ein.<br />
3.3.2. Ansprechpartner<br />
Für die in Abbildung 3.1 dargestellten Stakeholdergruppen gilt es, anschließend die jeweiligen<br />
Ansprechpartner zu identifizieren. Die Qualität der Analyseergebnisse ist insbesondere<br />
von der Wahl der richtigen Ansprechpartner geprägt. Die korrekte Einordnung in die<br />
entsprechenden Kompetenzbereiche hilft bei einer möglichst reibungslosen Kommunikation.<br />
Die ermittelten Gesprächspartner sind in der Tabelle 3.1 aufgeführt.<br />
3.4. Identifizierung der Interessen der Anforderungsbeitragenden<br />
Nach der Identifikation der Anforderungsbeitragenden (s. Kap. 3.3.1 und 3.3.2) sind anschließend<br />
deren grundsätzliche Interessen und Ziele zu ermitteln und zu dokumentieren.<br />
So wird eine Basis zur weiteren Verfeinerung und Gliederung der Anforderungen geschaffen.<br />
16
ud: Stakeholder<br />
IG−Entwickler<br />
3. Anforderungsanalyse<br />
Ressourcen−Datenbank<br />
Datenbank nutzen<br />
Portal−Anwender<br />
FIRST−Entwickler<br />
Abbildung 3.1.: UML-Anwendungsfalldiagramm: ermittelte Stakeholder<br />
Tabelle 3.1.: Projekt-Ansprechpartner<br />
Verantwortliche Ansprechpartner<br />
IG-Projektleiter Herr Dr. Ulrich Schwardmann von der GWDG<br />
K-Wf-Grid-Projektleiter Herr Andreas Hoheisel vom Fraunhofer FIRST<br />
Fachexperten Ansprechpartner<br />
IG-Entwickler Herr Dr. Christian Boehme von der GWDG<br />
FIRST-Entwickler Herr Andreas Hoheisel vom Fraunhofer FIRST<br />
FIRST-<br />
Beschreibungsentwickler<br />
Herr Dr. Armin Wolf vom Fraunhofer FIRST<br />
Systembetroffene Ansprechpartner<br />
Portal-Anwender Herr Dr. Christian Boehme von der GWDG<br />
17
3.4.1. Ziele und Interessen<br />
3. Anforderungsanalyse<br />
Die Dokumentation der Interessen bzw. der gewünschten Ziele der Anforderungsbeitragenden<br />
findet sich in den Tabellen 3.2, 3.3 und 3.4). Die Aussagen werden in diesem Zusammenhang<br />
noch nicht bewertet, sondern lediglich schriftlich festgehalten. Die Formulierungen<br />
dienen jedoch der Generierung einer Übersicht aller Anwendungsfälle, die das<br />
Verhalten des Systems nach außen wiedergeben. Die detaillierten Beschreibungen aller Anforderungen<br />
sind in Kapitel 3.5 aufgeführt.<br />
Tabelle 3.2.: Interessen der Anforderungsbeitragenden (IG-Entwickler)<br />
Kennzeichnung Verbindlichkeit Beschreibung<br />
/Z10/ Pflicht Nahtlose Integration des Systems in die vorhandene<br />
Struktur.<br />
/Z11/ Pflicht Keinerlei Benutzerinteraktionen für die Aktualisierung<br />
der Ressourcen-Informationen.<br />
/Z20/ Pflicht Bereitstellung der Ressourcen-Informationen<br />
für andere Anwendungen, wie etwa den Grid-<br />
Portlets.<br />
Tabelle 3.3.: Interessen der Anforderungsbeitragenden (FIRST-Entwickler)<br />
Kennzeichnung Verbindlichkeit Beschreibung<br />
/Z30/ Pflicht Erhebung von dynamischen Informationen<br />
über Hardware-Ressourcen (insbes. Auslastungsdaten).<br />
/Z31/ Pflicht Bereitstellung einer Schnittstelle zur Kontrolle<br />
der Informationsbeschaffung.<br />
/Z32/ Pflicht Erhebung von Informationen über Software-<br />
Ressourcen.<br />
/Z40/ Pflicht Konformität der Datenbank zu XPath[38],<br />
XQuery[39] und XUpdate[40].<br />
/Z50/ Pflicht Datenaustausch mittels der vom FIRST spezifizierten<br />
D-GRDL (siehe B.5).<br />
/Z60/ Optional Verwendung der eXist XML-Datenbank.<br />
18
3. Anforderungsanalyse<br />
Tabelle 3.4.: Interessen der Anforderungsbeitragenden (Portal-Benutzer)<br />
Kennzeichnung Verbindlichkeit Beschreibung<br />
/Z70/ Pflicht Einfache Übersicht der existierenden<br />
Hardware-Ressourcen.<br />
/Z80/ Pflicht Anbindung an Workflow-Editor des FIRST.<br />
/Z90/ Optional Graphische Darstellung der Auslastungsinformationen.<br />
/Z100/ Pflicht Bereitstellung einer graphischen Schnittstelle<br />
zur Kontrolle der Informationsbeschaffung.<br />
3.4.2. Essenzielle Anwendungsfälle<br />
Auf Grundlage der vorliegenden Informationen über die Ziele der Anforderungsbeitragenden<br />
(s. Kap. 3.4.1) können nun essenzielle Anwendungsfälle abgeleitet werden. Diese<br />
beschreiben das zukünftige System vereinfacht, sehr abstrakt und grundsätzlich unabhängig<br />
von konkreten Implementierungen. Die in der Abbildung 3.2 dargestellten Anwendungsfälle<br />
beziehen sich daher weniger auf konkrete Rahmenbedingungen und technologische<br />
Gegebenheiten. Vielmehr konzentrieren sie sich auf die eigentliche fachliche Intention<br />
und werden im weiteren Verlauf konkretisiert. Zur späteren Referenzierung sind die<br />
Anwendungsfälle mit einer eindeutigen Bezeichnung (z.B. "/U10/") gekennzeichnet.<br />
ud: Grundlegende Anwendungsfälle<br />
Portal−Anwender<br />
><br />
Information Provider<br />
Ressourcen−Datenbank<br />
Ressourceninformationen<br />
darstellen (/U10/)<br />
Ressourceninformations−<br />
aktualisierung steuern (/U20/)<br />
Ressourceninformationen<br />
exportieren (/U30/)<br />
Ressourceninformationen<br />
auswerten (/U40/)<br />
><br />
FIRST−Editor<br />
><br />
FIRST−Scheduler<br />
><br />
Grid Portlet<br />
><br />
Zeitsteuerung<br />
Abbildung 3.2.: UML-Anwendungsfalldiagramm: grundlegende Anwendungsfälle<br />
19
3. Anforderungsanalyse<br />
3.5. Beschreibung der Anforderungen<br />
Die in Abbildung 3.2 dargestellten essenziellen Anwendungsfälle und in Kapitel 3.4.1 beschriebenen<br />
Ziele bieten einen guten Rahmen und Einstiegspunkt zur Analyse und Beschreibung<br />
der Anforderungen an das zu entwickelnde System. Methodische Richtlinien<br />
und standardisierte Verfahren zur systematischen Anforderungsbeschreibung gibt es viele<br />
(vgl. [41, 42, 43, 44]). Im Folgenden werden die Vorgaben aus dem Lehrbuch von Bernd<br />
Oestereich[6] verwendet und durch weitere Angaben[10, 8, 45] ergänzt.<br />
3.5.1. Probleme<br />
Probleme des bestehenden Systems, die zu der Entwicklung des neuen Systems geführt<br />
haben, sind in Tabelle 3.5 aufgeführt. Grundlage der formulierten Defizite sind die Erfahrungswerte<br />
der IG-Entwickler. Die Priorisierung, in wie fern das neue System diese<br />
Probleme beheben soll, findet sich in der Angabe der Verbindlichkeit.<br />
Tabelle 3.5.: Anforderungsbeschreibung: vorhandenen Probleme<br />
Nr. Verbindlichkeit Beschreibung<br />
/P10/ Pflicht Die Darstellung von Ressourcen-<br />
Informationen ist z.Z. nicht einheitlich<br />
in das Portal integriert.<br />
/P20/ Pflicht Eine Anbindung an Entwicklungen<br />
des FIRST fehlt.<br />
/P30/ Pflicht Es besteht z.Z. keine sinnvolle Verwendung<br />
des MDS4.<br />
/P40/ Optional Die Optionen zur Aktualisierung<br />
von Ressourcen-Informationen<br />
können derzeit nicht über eine<br />
Webschnittstelle gesteuert werden.<br />
/P50/ Optional Die derzeitige Umsetzung der<br />
Aktualisierung von Ressourcen-<br />
Informationen für die Grid-Portlets<br />
könnte überarbeitet werden.<br />
3.5.2. Funktionale Anforderungen<br />
Die in Kapitel 3.4.1 beschriebenen Interessen ziehen funktionale Anforderungen an das<br />
System nach sich. Diese beschreiben grundsätzlich die Interaktion eines technischen Systems<br />
mit seiner Umgebung. Die entsprechenden Anforderungen werden in Tabelle 3.6 aufgelistet,<br />
eindeutig gekennzeichnet, priorisiert und dem jeweiligen Ziel zugeordnet.<br />
20
3. Anforderungsanalyse<br />
Tabelle 3.6.: Anforderungsbeschreibung: funktionale Anforderungen<br />
Nr. Verbindlichkeit Ziel Beschreibung<br />
/F10/ Pflicht /Z10/ Integration des Systems in die<br />
Paket- und Verzeichnisverwaltung<br />
des IG.<br />
/F20/ Pflicht /Z10/ Integration des Systems in den<br />
Startvorgang des IG.<br />
/F21/ Pflicht /Z20/ Bereitstellung der statischen<br />
Informationen aus Information-<br />
Providern.<br />
/F30/ Pflicht /Z20/ Bereitstellung von Schnittstellen<br />
für den Zugriff auf die Daten.<br />
/F31/ Pflicht /Z31/ Bereitstellung von Schnittstellen<br />
für die Steuerung der Informationsbeschaffung.<br />
/F40/ Optional /Z20/ Aktualisierung der Ressourcen-<br />
Informationen der Grid-Portlets.<br />
/F50/ Pflicht /Z30/ Auswertung der statischen und<br />
dynamischen Informationen über<br />
Ressourcen aus Information-<br />
Providern.<br />
/F51/ Pflicht /Z32/ Erhebung von Informationen über<br />
installierte Software-Ressourcen.<br />
/F60/ Pflicht /Z40/ Nutzung einer XPath, XQuery<br />
und XUpdate kompatiblen Datenbankstruktur.<br />
/F70/ Pflicht /Z50/ Verwendung der D-GRDL zur Ressourcenbeschreibung.<br />
/F80/ Pflicht /Z70/ Textuelle Darstellung der<br />
Ressourcen-Informationen innerhalb<br />
eines Portlets.<br />
/F90/ Pflicht /Z70/ Graphische Darstellung der<br />
Ressourcen-Informationen innerhalb<br />
eines Portlets.<br />
/F100/ Pflicht /Z80/ Bereitstellung einer Schnittstelle<br />
zur Verknüpfung einer Ressourcen-<br />
Darstellung.<br />
21
3. Anforderungsanalyse<br />
/F110/ Optional /Z90/ Graphische Darstellung von<br />
Auslastungsinformationen über<br />
ein Zeitintervall innerhalb eines<br />
Portlets.<br />
3.5.3. Produktdaten<br />
Zur Realisierung der zuvor herausgearbeiteten, funktionalen Anforderungen (s. Kap. 3.5.2)<br />
ist die Speicherung und Verwaltung von zugehörigen Daten notwendig. Die langfristig zu<br />
speichernden Informationen zur Erfüllung der funktionalen Anforderungen werden in der<br />
nachfolgenden Tabelle festgehalten.<br />
Tabelle 3.7.: Anforderungsbeschreibung: zu speichernden Daten<br />
Nr. Verbindlichkeit Funktion Beschreibung<br />
/D10/ Pflicht /F21/ Name der Hardware-Ressource.<br />
/D20/ Pflicht /F21/ IP der Hardware-Ressource.<br />
/D30/ Pflicht /F50/ Freier Hauptspeicher der Hardware-Ressource.<br />
/D40/ Pflicht /F50/ CPU-Durchschnittsbelastung der<br />
Hardware-Ressource.<br />
/D50/ Pflicht /F51/ Installierte Software auf der Hardware-Ressource.<br />
/D60/ Abgrenzung /F51/ Installierte Software nicht dynamisch<br />
ermitteln.<br />
/D70/ Optional /F50/ Anzahl der CPUs der Hardware-<br />
Ressource.<br />
/D80/ Optional /F50/ CPU-Takt der Hardware-<br />
Ressource.<br />
/D90/ Optional /F50/ Größe des Hauptspeichers der<br />
Hardware-Ressource.<br />
/D100/ Optional /F21/ Rechnerarchitektur der Hardware-<br />
Ressource.<br />
3.5.4. Randbedingungen<br />
Als Randbedingungen werden Aspekte der Anforderungsanalyse bezeichnet, die nicht<br />
funktionaler Natur sind. Sie vervollständigen die Spezifikation, wirken unterstützend auf<br />
die konfliktfreie Kommunikation mit den Anforderungsbeitragenden und sind hilfreich<br />
beim Entwurfsprozess des Softwaresystems. In den folgenden Unterkapiteln werden nicht-<br />
22
3. Anforderungsanalyse<br />
funktionale Anforderungen aufgeführt, die im Rahmen des Projektes von Relevanz sind.<br />
3.5.4.1. Technische Anforderungen<br />
Aufgrund der Integration des zu entwickelnden Systems in eine bestehende Infrastruktur<br />
und durch bereits beschlossene technische Erweiterungen, ist die Produktumgebung und<br />
die Auswahl technischer Systeme bereits weitestgehend festgelegt. Die Analyse alternativer<br />
Lösungswege ist daher nicht Inhalt der vorliegenden Arbeit, sollte jedoch in weiterführenden<br />
Arbeiten in Betracht gezogen werden. Die beschriebenen Vorgaben sind in der<br />
Tabelle 3.8 zusammengefasst.<br />
Tabelle 3.8.: Randbedingungen: technische Anforderungen<br />
Nr. Verbindlichkeit Beschreibung<br />
/A10/ Pflicht Datenbank: eXist oder kompatible Lösung.<br />
/A20/ Pflicht Portalsystem: GridSphere-Portalsystem.<br />
/A21/ Pflicht Java-Container: Tomcat-Server.<br />
/A30/ Pflicht Information-Provider: MDS4 und Ganglia.<br />
/A40/ Pflicht Beschreibungssprache: D-GRDL.<br />
3.5.4.2. Testanforderungen<br />
Der Test der Anwendung ist integraler Bestandteil des verwendeten Entwicklungsprozesses.<br />
Nachfolgend werden in Tabelle 3.9 spezifizierte Testfälle aufgezählt, die das Produkt<br />
mindestens zu durchlaufen hat.<br />
Tabelle 3.9.: Randbedingungen: Testanforderungen<br />
Nr. Verbindlichkeit Beschreibung<br />
/T10/ Pflicht Hinzufügen von Hardware-Ressourcen.<br />
/T20/ Pflicht Entfernen von Hardware-Ressourcen.<br />
/T30/ Pflicht Ausfall des Information-Providers.<br />
/T40/ Pflicht Falsche Verwendung des Portlets.<br />
/T50/ Optional Lasttest bzgl. des Abfrageintervalls.<br />
/T60/ Optional Lasttest bzgl. der Anzahl an Hardware-<br />
Ressourcen.<br />
23
3. Anforderungsanalyse<br />
3.6. Konkretisierung der Anwendungsfälle<br />
Auf Basis der herausgearbeiteten Anforderungen an das System aus der Analyse in Kapitel<br />
3.5 gilt es nun, die bereits in Abbildung 3.2 skizzierten Anwendungsfälle weiter zu<br />
konkretisieren und zu beschreiben. Aufbauend auf der erweiterten Abbildung der Anwendungsfälle<br />
(s. Abb. 3.3) werden diese im Folgenden anhand einer semi-formalen Vorlage<br />
(angelehnt an [46]) beschrieben und das zugehörige Ablaufmodell angegeben. Das jeweilige<br />
Ablaufmodell dient zum einen der Beschreibung der gegebenen Vorgänge des Anwendungsfalles,<br />
zum anderen werden die Aktionspfade der Modelle zur Testfallgenerierung<br />
verwendet. Dies dient der Validierung der Anwendung gegenüber der Anforderungsspezifikation<br />
(s. Kap. 5.3).<br />
24
ud: Vollständiges Anwendungsfalldiagramm<br />
Portal−Anwender<br />
><br />
Information Provider<br />
Übersicht<br />
darstellen (/U11/)<br />
Aktualisierungs−<br />
interval setzen (/U21/)<br />
Resourceninformationen<br />
auslesen (/U31/)<br />
Ressourceninformationen<br />
hinzugügen (/U41/)<br />
3. Anforderungsanalyse<br />
Ressourcen−Datenbank<br />
Ressourceninformationen<br />
darstellen (/U10/)<br />
Ressourceninformations−<br />
aktualisierung steuern (/U20/)<br />
Information Provider<br />
auswählen (/U23/)<br />
Ressourceninformationen<br />
exportieren (/U30/)<br />
Ressourceninformationen<br />
auswerten (/U40/)<br />
Ressourceninformationen<br />
aktualisieren (/U43/)<br />
Ressource<br />
darstellen (/U12/)<br />
><br />
Aktualisierung<br />
starten (/U22/)<br />
Resourceninformationen<br />
konvertieren (/U32/)<br />
Ressourceninformationen<br />
entfernen (/U42/)<br />
><br />
FIRST−Editor<br />
><br />
FIRST−Scheduler<br />
><br />
Grid Portlet<br />
><br />
Zeitsteuerung<br />
Abbildung 3.3.: UML-Anwendungsfalldiagramm: Übersicht des zu entwickelnden Systems<br />
25
3. Anforderungsanalyse<br />
3.6.1. Anwendungsfall U10 (Ressourceninformationen darstellen)<br />
3.6.1.1. Aktivitätsdiagramm<br />
3.6.1.2. Konkretisierung U11<br />
ad: U10 (R.informationen darstellen)<br />
2. DB auslesen<br />
(/U11/)<br />
[Nein]<br />
1. Mit DB verbinden<br />
1.1 [OK]<br />
Ressource<br />
ausgewählt<br />
[Ja]<br />
2.1 [OK] 3.1 [OK]<br />
R.informationen darstellen<br />
1.2 [Fehler]<br />
3. R.information auslesen<br />
(/U12/)<br />
2.2 {Fehler]<br />
3.2 [Fehler]<br />
Fehler darstellen<br />
Abbildung 3.4.: UML-Aktivitätsdiagramm: Anwendungsfall U10<br />
Tabelle 3.10.: Anwendungsfall U10: Konkretisierung U11<br />
Name: Übersicht darstellen<br />
Kurzbeschreibung Es werden statische und dynamische Informationen<br />
über Hardware-Ressourcen dargestellt.<br />
Akteure Portal-Nutzer.<br />
Auslöser Der Nutzer öffnet eine entsprechende Seite des<br />
Portals.<br />
Eingehende Informationen<br />
Ergebnisse Darstellung der Ressourcen-Information.<br />
Ablauf 1. Nutzer öffnet entsprechende Portalseite.<br />
2. Übersichtsseite wird dargestellt.<br />
26
3.6.1.3. Konkretisierung U12<br />
3. Anforderungsanalyse<br />
Tabelle 3.11.: Anwendungsfall U10: Konkretisierung U12<br />
Name: Ressource darstellen<br />
Kurzbeschreibung Es werden statische und dynamische Informationen<br />
über eine spezifische Hardware-<br />
Ressource dargestellt.<br />
Akteure Portal-Nutzer.<br />
Auslöser Der Nutzer öffnet eine entsprechende Seite des<br />
Portals.<br />
Eingehende Informationen Eindeutige Kennung der Ressource.<br />
Ergebnisse Darstellung der Ressourcen-Information.<br />
Ablauf 1. Nutzer öffnet entsprechende Portalseite.<br />
2. Auswahl einer Ressource.<br />
3. Auswahl bestätigen.<br />
3.6.2. Anwendungsfall U20 (Ressourceninformationsaktualisierung steuern)<br />
3.6.2.1. Aktivitätsdiagramm<br />
ad: U20 (R.inform.aktualisierung steuern)<br />
1. Mit Steuerung verbinden<br />
1.2 [Fehler]<br />
1.1 [OK]<br />
[Update starten]<br />
[Interval setzen]<br />
[IP auswählen]<br />
2. Update starten (/U22/)<br />
2.2 [Fehler]<br />
Abbildung 3.5.: UML-Aktivitätsdiagramm: Anwendungsfall U20<br />
27<br />
3. IP auswählen (/U23/)<br />
3.2 [Fehler]<br />
4. Interval setzen (/U21/)<br />
4.2 [Fehler]<br />
2.1 [OK]<br />
3.1 [OK]<br />
2.1 [OK]<br />
Update−Signal<br />
Interval nicht gesetzt<br />
Steuerung vollständig
3.6.2.2. Konkretisierung U21<br />
3. Anforderungsanalyse<br />
Tabelle 3.12.: Anwendungsfall U20: Konkretisierung U21<br />
Name: Aktualisierungsintervall setzen<br />
Kurzbeschreibung Änderung des Intervalls in dem die Daten der<br />
Information-Provider ausgewertet werden.<br />
Akteure Portal-Nutzer / Komponente des FIRST.<br />
Auslöser Nutzer klickt auf ein entsprechendes Formular<br />
/ Komponente ruft Funktion auf.<br />
Eingehende Informationen Das neue Intervall in Sekunden.<br />
Ergebnisse Setzen eines neuen Aktualisierungsintervalls.<br />
Ablauf 1. Verbindung mit der Daemon-Steuerung (Portal<br />
/ Funktion).<br />
2. Auswahl eines neuen Intervalls.<br />
3. Aufruf des Schnittstellenelements (Portal /<br />
Funktion).<br />
3.6.2.3. Konkretisierung U22<br />
Tabelle 3.13.: Anwendungsfall U20: Konkretisierung U22<br />
Name: Aktualisierung starten<br />
Kurzbeschreibung Die Daten des Information-Providers sollen sofort<br />
ausgewertet werden.<br />
Akteure Portal-Nutzer / Komponente des FIRST.<br />
Auslöser Nutzer klickt auf ein entsprechendes Formular<br />
/ Komponente ruft Funktion auf.<br />
Eingehende Informationen<br />
Ergebnisse Einleitung der Aktualisierung der Daten und<br />
Versenden eines Update-Signals an registrierte<br />
Komponenten.<br />
Ablauf 1. Verbindung mit der Daemon-Steuerung (Portal<br />
/ Funktion).<br />
2. Aufruf des Schnittstellenelements (Portal /<br />
Funktion).<br />
28
3.6.2.4. Konkretisierung U23<br />
3. Anforderungsanalyse<br />
Tabelle 3.14.: Anwendungsfall U20: Konkretisierung U23<br />
Name: Information-Provider auswählen<br />
Kurzbeschreibung Auswahl eines neuen Information-Providers.<br />
Akteure Portal-Nutzer / Komponente des FIRST.<br />
Auslöser Nutzer klickt auf ein entsprechendes Formular<br />
/ Komponente ruft Funktion auf.<br />
Eingehende Informationen Vollständiger Klassenname der neuen Verbindungskomponente.<br />
Ergebnisse Änderung der Verbindungsklasse zum<br />
Information-Provider.<br />
Ablauf 1. Verbindung mit der Daemon-Steuerung (Portal<br />
/ Funktion).<br />
2. Auswahl der Verbindungskomponente.<br />
3. Aufruf des Schnittstellenelements (Portal /<br />
Funktion).<br />
3.6.3. Anwendungsfall U30 (Ressourceninformationen exportieren)<br />
3.6.3.1. Aktivitätsdiagramm<br />
ad: U30 (R.informationen exportieren)<br />
2.1 [OK]<br />
Daten ausgelesen<br />
1. Mit DB verbinden<br />
1.1 [OK]<br />
2. R.informationen auslesen<br />
(/U31/)<br />
[Datenexport]<br />
Update−Signal<br />
[Datenexport]<br />
3. Daten konvertieren<br />
(/U32/<br />
3.1 [OK]<br />
Daten konvertiert<br />
1.2 [Fehler]<br />
2.2 [Fehler]<br />
3.2 [Fehler]<br />
Fehlerrückgabe<br />
Abbildung 3.6.: UML-Aktivitätsdiagramm: Anwendungsfall U30<br />
29
3.6.3.2. Konkretisierung U31<br />
3. Anforderungsanalyse<br />
Tabelle 3.15.: Anwendungsfall U30: Konkretisierung U31<br />
Name: Ressourceninformationen auslesen<br />
Kurzbeschreibung Auslesen von Ressourcen-Informationen aus<br />
der Datenbank.<br />
Akteure Portal-Nutzer / Komponente des FIRST.<br />
Auslöser Nutzer klickt auf ein entsprechendes Formular<br />
/ Komponente ruft Funktion auf.<br />
Eingehende Informationen (Optional) Die eindeutige Bezeichnung einer<br />
Ressource.<br />
Ergebnisse (Teil-)Auszug der Datenbankinhalte.<br />
Ablauf 1. Verbindung mit der Datenbank.<br />
2. (Optional) Auswahl einer Ressourcenbezeichnung.<br />
3. Aufruf der Datenbank-Schnittstelle.<br />
3.6.3.3. Konkretisierung U32<br />
Tabelle 3.16.: Anwendungsfall U30: Konkretisierung U32<br />
Name: Ressourceninformationen konvertieren<br />
Kurzbeschreibung Exportieren von Ressourcen-Informationen aus<br />
der Datenbank.<br />
Akteure Softwarekomponente zur Konvertierung.<br />
Auslöser Komponente ruft Funktion auf / Empfang eines<br />
Update-Signals.<br />
Eingehende Informationen (Optional) Die eindeutige Bezeichnung einer<br />
Ressource<br />
Ergebnisse (Teil-)Auszug der Datenbankinhalte.<br />
Ablauf 1. Verbindung mit der Datenbank<br />
2. (Optional) Auswahl einer Ressourcenbezeichnung.<br />
3. Aufruf der Datenbank-Schnittstelle.<br />
4. Konvertierung der Daten in gewünschtes<br />
Format.<br />
30
3.6.4. Anwendungsfall U40<br />
3.6.4.1. Aktivitätsdiagramm<br />
ad: U40 (R.information auswerten)<br />
[Neue R.informationen]<br />
6.1 [OK]<br />
Ressource hinzugefügt<br />
3. Anforderungsanalyse<br />
1. Verbinden zum IP<br />
1.1 [OK]<br />
2. Informationen konvertieren<br />
2.1 [OK]<br />
3. Mit DB verbinden<br />
3.1 [OK]<br />
[Ressource entfernt]<br />
4. Ressource hinzufügen<br />
(/U41/)<br />
5. Ressource entfernen<br />
(/U42/)<br />
6. R.information aktualisieren<br />
(/U43/)<br />
5.1[OK]<br />
4.1 [OK]<br />
[Neue Ressource]<br />
5.2 [Fehler]<br />
6.2 [Fehler]<br />
Zeitsignal<br />
1.2 [Fehler]<br />
2.2 [Fehler]<br />
3.2 [Fehler]<br />
4.2 [Fehler]<br />
Fehlerrückgabe<br />
Abbildung 3.7.: UML-Aktivitätsdiagramm: Anwendungsfall U40<br />
31
3.6.4.2. Konkretisierung U41<br />
3. Anforderungsanalyse<br />
Tabelle 3.17.: Anwendungsfall U40: Konkretisierung U41<br />
Name: Ressourceninformationen hinzufügen<br />
Kurzbeschreibung Aufnahme neuer Hardware-Ressourcen in die<br />
Datenbank.<br />
Akteure Information-Provider.<br />
Auslöser Zeitsignal / Hinzufügen einer Hardware-<br />
Ressource.<br />
Eingehende Informationen Statische und dynamische Daten über die neue<br />
Hardware-Ressource.<br />
Ergebnisse Informationen über die neue Hardware-<br />
Ressource werden in der Datenbank gespeichert.<br />
Ablauf 1. Verbindung zum Information-Provider.<br />
2. Konvertierung und Auswertung der Daten<br />
des Information-Providers.<br />
3. Verbindung zur Datenbank.<br />
4. Einbinden der neuen Informationen in die<br />
Datenbank.<br />
3.6.4.3. Konkretisierung U42<br />
Tabelle 3.18.: Anwendungsfall U40: Konkretisierung U42<br />
Name: Ressourceninformationen entfernen<br />
Kurzbeschreibung Entfernung einer Hardware-Ressource aus der<br />
Datenbank.<br />
Akteure Information-Provider.<br />
Auslöser Zeitsignal / Entfernung einer Hardware-<br />
Ressource.<br />
Eingehende Informationen Ggf. Name der entfernten Hardware-<br />
Ressource.<br />
Ergebnisse Entfernung der Informationen der Hardware-<br />
Ressource aus der Datenbank.<br />
Ablauf 1. Verbindung zum Information-Provider.<br />
2. Konvertierung und Auswertung der Daten<br />
des Information-Providers.<br />
3. Verbindung zur Datenbank.<br />
32
3.6.4.4. Konkretisierung U43<br />
3. Anforderungsanalyse<br />
4. Löschen der Informationen aus der Datenbank.<br />
Tabelle 3.19.: Anwendungsfall U40: Konkretisierung U43<br />
Name: Ressourceninformationen aktualisieren<br />
Kurzbeschreibung Aktualisierung der dynamischen Daten über<br />
eine Hardware-Ressource.<br />
Akteure Information-Provider.<br />
Auslöser Zeitsignal.<br />
Eingehende Informationen Eindeutige Bezeichnung der Hardware-<br />
Ressource.<br />
Ergebnisse Aktualisierung der Informationen der<br />
Hardware-Ressource in der Datenbank.<br />
Ablauf 1. Verbindung zum Information-Provider.<br />
2. Konvertierung und Auswertung der Daten<br />
des Information-Providers.<br />
3. Verbindung zur Datenbank.<br />
4. Aktualisierung der Informationen aus der<br />
Datenbank.<br />
3.7. Beschreibung der Systemschnittstelle<br />
Nach der Analyse und Beschreibung der Anwendungsfälle können im nächsten Schritt<br />
nun die Strukturelemente, die an der äußeren Systemgrenze liegen, identifiziert werden.<br />
Dabei gilt es, die involvierten Schnittstellenelemente zu finden, die für Interaktionen des<br />
zu entwickelnden Systems mit der Umgebung notwendig sind. In Tabelle 3.20 sind die<br />
entsprechenden Schnittstellen für die herausgearbeiteten Anwendungsfälle aufgeführt.<br />
Anwendungsfallschritt/aktivität<br />
/U10/ (Ressourceninformationen<br />
darstellen)<br />
/U20/ (Ressourceninformationsaktualisierung<br />
steuern)<br />
/U30/ (Ressourceninformationen<br />
exportieren)<br />
Tabelle 3.20.: Zuordnung der involvierten Schnittstellen<br />
Involvierte Schnittstelle<br />
Dialog/Interface: Ressourcendarstellung I10<br />
Dialog/Interface: Steuerung I20<br />
Interface: Datenexport I30<br />
33
U40/ (Ressourceninformationen<br />
auswerten)<br />
3. Anforderungsanalyse<br />
3.7.1. Dialog/Interface I10 (Ressourcendarstellung)<br />
Interface: Information-Provider-Treiber I40<br />
Tabelle 3.21.: Dialog/Interface: Ressourcendarstellung I10<br />
Name Ressourcendarstellung<br />
Kurzbeschreibung Mit diesem Dialog kann der Benutzer eine Ressource<br />
zur Darstellung auswählen.<br />
Verwendung Zur Auswahl bei der Darstellung aller vorhandenen<br />
Ressourcen und als Verknüpfung über den<br />
Fraunhofer Workfloweditor.<br />
Eingabefelder Eindeutige Bezeichnung der Ressource (z.B. über<br />
die URL).<br />
Anzeigefelder Eindeutige Bezeichnungen aller Ressourcen.<br />
Verzweigungsmöglichkeit Zurück zur Übersicht aller Ressourcen.<br />
Aktionen Reduzierung der Anzeige auf eine Ressource.<br />
3.7.2. Dialog/Interface I20 (Steuerung)<br />
Tabelle 3.22.: Dialog/Interface: Steuerung I20<br />
Name Steuerung<br />
Kurzbeschreibung Steuerung der Datenverwertung.<br />
Verwendung Als Einstellmöglichkeit für jeden Portal-Benutzer<br />
und als Interface für Komponenten des FIRST.<br />
Eingabefelder Aktualisierungsintervall in Sekunden, Name des<br />
zu verwendenden Information-Providers und<br />
Aktualisierungsfunktion<br />
Anzeigefelder Derzeitiges Aktualisierungsintervall, Name des<br />
Information-Providers und eine Aktualisierungsfunktion.<br />
Verzweigungsmöglichkeit Keine.<br />
Aktionen Aktualisierung der Daten und Änderung des Aktualisierungsintervalls<br />
und des Information Providers.<br />
34
3.7.3. Interface I30 (Datenexport)<br />
3. Anforderungsanalyse<br />
Tabelle 3.23.: Interface: Datenexport I30<br />
Name Datenexport<br />
Kurzbeschreibung Export der in der Datenbank vorhandenen Daten.<br />
Betroffene Systeme Komponente zur Anbindung der Grid-Portlets<br />
und Komponenten des FIRST.<br />
Eingabedaten Registrierungsinformationen zur Benachrichtigung.<br />
Ausgabedaten Update-Signal und Datenbankinhalte.<br />
3.7.4. Interface: I40 (Information-Provider-Treiber)<br />
Tabelle 3.24.: Interface: Information-Provider-Treiber I40<br />
Name Information-Provider-Treiber<br />
Kurzbeschreibung Komponente zur Umwandlung und Strukturierung<br />
von Daten eines Information-Providers.<br />
Betroffene Systeme Information-Provider und eine Zeitsteuerung.<br />
Eingabedaten Update-Signal und Daten des Information Providers.<br />
Ausgabedaten Strukturierte Daten des Information-Providers.<br />
35
4. Design<br />
4.1. Einleitung<br />
Unter dem Begriff „Design“ wird die kreative Erarbeitung eines Lösungskonzeptes für<br />
ein Problem unter Berücksichtigung gegebener Rahmenbedingungen verstanden. Die vorausgegangene<br />
Analyse des zu entwerfenden Systems (s. Kap. 3) bietet alle notwendigen<br />
Informationen und Annahmen, um im weiteren Verlauf einen geeigneten Lösungsweg<br />
aufzuzeigen und die Softwarearchitektur zu spezifizieren die in Abbildung 2.4 bereits angedeutet<br />
wurde. In den folgenden Kapiteln werden daher — mit Bezug auf die entsprechenden<br />
Ergebnisse der Anforderungsanalyse — Modelle, Komponenten und Schnittstellen<br />
beschrieben, die als Grundlage der anschließenden Implementierung dienen. Das zu<br />
entwickelnde System wird im weiteren Verlauf als “Grid Ressourcen Datenbank” (GRDB)<br />
bezeichnet.<br />
Bei der Konzeption der GRDB wird oftmals Gebrauch von verschiedenen Entwurfsmustern<br />
gemacht. Dies gewährleistet die Wahl von etablierten und effizienten Lösungen zu<br />
bekannten Problemen und unterstützt den Entwurf einer stabilen und erweiterbaren Architektur.<br />
Ein Muster drückt nach Christopher <strong>Alexander</strong> 1 die Beziehung zwischen einem<br />
Problem, seiner Lösung und einem Kontext aus. Diese Definition eines Entwurfsmusters<br />
(engl. „design pattern“) aus dem Bereich des Bauwesens und der Architektur wurde Ende<br />
der 80er Jahre von Erich Gamma in das Gebiet der Softwareentwicklung übernommen. In<br />
seinem Buch[48] werden 23 Entwurfsmuster beschrieben. Die jeweiligen Muster sind unabhängig<br />
von einer speziellen Programmiersprache zu betrachten und bieten vorgefertigte<br />
und bewährte Lösungen für eine bestimmte Art von Entwurfsproblemen.<br />
4.2. Anwendungsarchitektur<br />
Als ersten Schritt wird die grundlegende Architektur der Anwendung festgelegt. Diese<br />
bestimmt unter anderem, welche Arten von Klassen und Schnittstellen entworfen werden<br />
müssen. Eine saubere Anwendungsarchitektur dient auch der sinnvollen Arbeitsaufteilung<br />
innerhalb des Systems und gibt eine Übersicht der zu entwerfenden Komponenten.<br />
In der Literatur werden, je nach Zielsetzung und Umgebung des zu entwickelnden Systems,<br />
eine Vielzahl von möglichen Architekturmustern beschrieben[49]. Für den Entwurf<br />
1 Architekt und Mathematiker und Autor des Buches „A Pattern Language“[47].<br />
36
4. Design<br />
eines interaktiven Systems mit graphischer Oberfläche, wie es die GRDB-Software eine ist<br />
(/Z70 /Z80 /Z90 /Z100/), sind das Model-View-Controller- (MVC) und das Presentation--<br />
Abstraction-Control-Entwurfsmuster (PAC) von Relevanz. Diese unterteilen das System<br />
in Einheiten für die Darstellung und Benutzerinteraktionen, die Datenverwaltung und die<br />
Steuerung. Das PAC-Muster geht jedoch noch einen Schritt weiter und segmentiert das<br />
System nach Teilaufgaben in eine hierarchische Struktur, was für die geforderte Anwendung<br />
nicht notwendig ist.<br />
cd: Architekturübersicht<br />
><br />
Java−Container / Portalsystem<br />
−JSR 154 − / − JSR 168 −<br />
(Tomcat) / (GridSphere)<br />
Präsentationsschicht<br />
Kontrollschicht<br />
Datenschicht<br />
><br />
Update−Listener<br />
><br />
GRDB−<br />
IP−Connector<br />
><br />
Information−Provider<br />
(Ganglia und MDS4)<br />
><br />
GRDB−Daemon<br />
><br />
GRDB−Portlet<br />
GRDB−Servlet<br />
><br />
GRDB−<br />
DB−Connector<br />
><br />
XML−Datenbank<br />
− XPath / XQuery−<br />
(eXist)<br />
Kommunikation über<br />
Datentransferobjekte<br />
Abbildung 4.1.: UML-Komponentendiagramm: Architektur der GRDB-Anwendung<br />
Die Abgrenzung einer Schicht zur Datenverwaltung ist aufgrund der geforderten, gemeinsamen<br />
Datenbasis zwischen der GRDB und den Entwicklungen des FIRST (/Z40 /Z50<br />
/Z60/) sinnvoll und notwendig. Ebenso ist die Darstellung und visuelle Steuerung von<br />
der Aktualisierung der Informationen abzugrenzen, da diese ohne Benutzerinteraktion im<br />
Hintergrund zu erfolgen hat (/Z11/). Die entwickelte Architektur der GRDB-Anwendung<br />
(s. Abb. 4.1) spiegelt die Unterteilung in die erwähnten Bereiche wider. Von der Anwen-<br />
37
4. Design<br />
dung benötigte Fremdsysteme sind hierbei dunkel hinterlegt. Die jeweiligen Bausteine<br />
greifen ausschließlich auf festgelegte Schnittstellen anderer Komponenten zu und sind<br />
getrennt voneinander zu betrachten. Die Kommunikation erfolgt in der Regel über Datentransferobjekte,<br />
die die notwendigen Informationen einheitlich und zur vereinfachten<br />
Handhabung kapseln. Die Aufgaben der jeweiligen Schicht und ihrer Komponenten werden<br />
im Folgenden kurz erläutert und anschließend in Form von Klassen- und Schnittstellenbeschreibungen<br />
weiter detailliert.<br />
4.3. Komponenten<br />
4.3.1. Präsentationsschicht<br />
Die Komponenten der Präsentationsschicht haben zur Aufgabe, dem Benutzer eine graphische<br />
Benutzeroberfläche zur Verfügung zu stellen. Dies beinhaltet unter anderem die<br />
Erstellung einer Übersicht von Hardware-Ressourcen (/Z70/) und die Steuerung der Informationsbeschaffung<br />
(/P50 /Z100/).<br />
Portalsystem. Technische Grundlage für die Realisierung der graphischen Oberfläche ist<br />
der Einsatz des Apache Tomcat Servers und das GridSphere Portal-Systems (/A20 /A21<br />
/F90/). Bei der Umsetzung des Systems wird jedoch ausschließlich auf die jeweiligen standardisierten<br />
Schnittstellen JSR-154[50] und JSR-168[51] zugegriffen. Dies ermöglicht den<br />
einfachen Austausch der eingesetzten Portallösung durch alternative Systeme.<br />
GRDB-Portlet / GRDB-Servlet. Die Integration in das vorhandene Portalsystem (/P10 /Z10/)<br />
erfolgt durch die Erweiterung der jeweiligen Servlet- und Portlet-Schnittstellen. Für die<br />
Darstellung von erfassten Informationen (/F21 /F80 /F90 /I10/) ist der lesende Zugriff auf<br />
die gespeicherten Daten über eine definierte Schnittstelle notwendig. Die Steuerung der<br />
Informationsaktualisierung (/P40 /Z100 /F30 /I20/) bedingt den Zugriff auf Schnittstellen<br />
der Kontrollschicht.<br />
4.3.2. Kontrollschicht.<br />
Die Kontrollschicht stellt den organisatorischen Kern der Anwendung dar. Eingehende<br />
Benutzereingaben und Informationen der Information-Provider werden ausgewertet und<br />
der notwendige Kontrollfluss gesteuert.<br />
GRDB-Daemon. Der GRDB-Daemon steuert den Datenfluss des Systems und hat eine<br />
Vielzahl von Aufgaben. Insbesondere werden erhobene Daten der Information-Provider<br />
ausgelesen und eine Überführung der Informationen in die Datenbank veranlasst. Des<br />
38
4. Design<br />
Weiteren werden Benutzereingaben zur Steuerung der Information-Provider ausgewertet<br />
und weitergeleitet.<br />
Update-Listener. Durch einen Update-Mechanismus wird sichergestellt, dass externe Anwendungen<br />
über neue Daten informiert werden (/P20 /P50 /Z20 /F30 /F40 /I30/). Eine Anwendung<br />
kann sich beim GRDB-Daemon registrieren und erhält beim Eintreffen neuer<br />
Daten automatisch ein entsprechendes Signal.<br />
4.3.3. Datenschicht<br />
Komponenten der Datenschicht haben die Aufgabe Informationen auszulesen und Daten<br />
dauerhaft abzuspeichern. Die jeweiligen Elemente können einer Vielzahl von Kontrollund<br />
Präsentationsschichten als Datenbasis dienen.<br />
XML-Datenbank. Zur Speicherung der Informationen kommt die XML-Datenbank eXist<br />
zum Einsatz (/Z60 /A10/). Der Zugriff auf die Datenbank erfolgt jedoch ausschließlich über<br />
standardisierte Schnittstellen (/Z40 /F60/), so dass ein Austausch durch alternative Produkte<br />
möglich ist. Die Datenbank stellt die wichtigste Schnittstelle zwischen der GRDB<br />
und den Entwicklungen des FIRST dar. Auch andere Anwendungen können mit Hilfe der<br />
Datenbank über Informationen zu gespeicherten Ressourcen in standardisierter Form verfügen.<br />
(/Z20 /F30 /I30/).<br />
GRDB-DB-Connector. Da die Informationen in der Datenbank intensiv vom FIRST genutzt<br />
werden, müssen diese exakt den geforderten Spezifikationen (s. B.5) entsprechen<br />
(/A40 /Z50 /F70/). Die Komponente hat daher die Aufgabe Informationen aus der Datenbank<br />
in standardisierter Form auszulesen, abzulegen und zu modifizieren (s. Listing 4.1).<br />
<br />
<br />
< resource xsi:noNamespaceSchemaLocation =<br />
" http: // server:8080 / gwes / xsd / instantgrid -d- grdl . xsd "<br />
uri =" hardware:moscow "><br />
< ofClass uri =" urn:dgrdl:hardware "/><br />
moscow <br />
< simpleProperty ident =" WSRF . ManagedJobFactoryService "<br />
type =" uri "<br />
unit =""><br />
https: // moscow:8443 / wsrf / services / ManagedJobFactoryService<br />
<br />
< simpleProperty ident =" CPUClockSpeed "<br />
type =" int " unit =" mhz ">1695<br />
<br />
< simpleProperty ident =" CPUInstructionSet "<br />
type =" string " unit ="">x86<br />
<br />
< simpleProperty ident =" CPUCount "<br />
type =" int " unit =" pcs ">1<br />
39
4. Design<br />
<br />
< simpleProperty ident =" CPULoad15Min "<br />
type =" int " unit =" percent ">24<br />
<br />
< simpleProperty ident =" CPULoad5Min "<br />
type =" int " unit =" percent ">18<br />
<br />
< simpleProperty ident =" CPULoad1Min "<br />
type =" int " unit =" percent ">98<br />
<br />
< simpleProperty ident =" RAMPhysicalAvailable "<br />
type =" int " unit ="mb">208<br />
<br />
< simpleProperty ident =" RAMPhysicalSize "<br />
type =" int " unit ="mb">501<br />
<br />
< simpleProperty ident =" RAMVirtualAvailable "<br />
type =" int " unit =" mhz ">1257<br />
<br />
< simpleProperty ident =" RAMVirtualSize "<br />
type =" int " unit =" mhz ">1557<br />
<br />
< simpleProperty ident =" FSAvailable "<br />
type =" int " unit ="mb">3<br />
<br />
< simpleProperty ident =" FSSize "<br />
type =" int " unit ="mb">1664<br />
<br />
< simpleProperty ident =" FSReadOnly "<br />
type =" string " unit =""/><br />
< simpleProperty ident =" NetIP "<br />
type =" string " unit ="">172.24.127.249<br />
<br />
< simpleProperty ident =" NetName "<br />
type =" string " unit ="">moscow<br />
<br />
< simpleProperty ident =" TimeStamp "<br />
type =" float " unit =" msec ">1161009879<br />
<br />
<br />
<br />
Listing 4.1: Beschreibung einer Hardware-Ressource<br />
GRDB-IP-Connector. Der GRDB-IP-Connector hat zur Aufgabe, statische und dynamische<br />
Daten (insbes. Auslastungsdaten) über im Netzwerk vorhandene Hardware-Ressourcen<br />
(/Z30 /F50 /I40/) zu erheben. Ausgewertet werden unter anderem Name, IP, Größe und<br />
Auslastung des Hauptspeichers, CPU-Durchschnittsbelastung, Anzahl der Prozessoren,<br />
CPU-Takt und Architektur der jeweiligen Hardware-Ressource (/D10 /D20 /D30 /D40 /D70<br />
/D80 /D90 /D100/). Des Weiteren werden statisch vorgegebene Software-Beschreibungen<br />
eingebunden (/Z32 /D50 /D60/) und in die D-GRDL überführt (s. Listing 4.1). Als Quelle<br />
können unterschiedliche Information-Provider dienen.<br />
Information-Provider. Die notwendigen Information über in einem Grid bzw. Netzwerk<br />
vorhandene Ressourcen liefern sogenannte Information-Provider (IP). Unterstützt werden<br />
Ganglia<br />
(/A30/) und MDS4 (/A30 /P30/), eine Erweiterung für weitere Information-Provider ist einfach<br />
möglich.<br />
40
4.4. Klassenmodell<br />
4. Design<br />
Aus den Phasen der Analyse und des Designs haben sich schon einige mögliche Operationen<br />
ergeben, die bei weiterer Betrachtung und Detaillierung neue notwendige Methoden<br />
aufzeigen. Die weitere Konkretisierung der Architektur mit Ihren Komponenten<br />
hin zu einer groben Klassendefinition helfen bei der anschließenden Implementierung der<br />
gewünschten Funktionen. Ebenso erleichtert die frühzeitige Festlegung von Schnittstellen<br />
die Kommunikation zwischen den Projektpartnern. Die Einteilung der Anwendung erfolgt<br />
in unterschiedliche Pakete (s. Abb. 4.2) die im Folgenden weiter ausgeführt werden.<br />
Paket−Übersicht: grdb<br />
daemon<br />
(from org ::instantgrid ::grdb )<br />
model<br />
(from org ::instantgrid ::grdb )<br />
portlet<br />
(from org ::instantgrid ::grdb )<br />
config<br />
(from org ::instantgrid ::grdb )<br />
test<br />
(from org ::instantgrid ::grdb )<br />
servlet<br />
(from org ::instantgrid ::grdb )<br />
Abbildung 4.2.: UML-Paketdiagramm: org.instantgrid.grdb<br />
4.4.1. Paket: org.instantgrid.grdb.model<br />
Das Paket org.instantgrid.grdb.model (s. Abb. 4.3) ist zuständig für die Datenverwaltung<br />
und beinhaltet hauptsächlich die Schnittstelle zur Datenbank und Klassen zur internen<br />
Datenkommunikation. Die in Listing 4.1 dargestellte Datenstruktur wird in der Klasse<br />
GridResource gehalten und modifiziert. Die jeweiligen Instanzen der Klasse dienen<br />
innerhalb des gesamten Systems als Austauschobjekt und werden lediglich in der Klasse<br />
XmlDBConnector zur Speicherung in die Datenbank wieder in das D-GRDL-Format<br />
überführt. Zur Erzeugung von GridResource-Objekten aus der Datenbank kommt das<br />
„Erbauer-Entwurfsmuster“ mit der Klasse GridResourceFactory zum Einsatz.<br />
41
Paket−Übersicht: model<br />
GridResource<br />
> + GridResource ():GridResource<br />
+ setClassUri (classType :URI):void<br />
+ getClassUri ():URI<br />
+ setDescription (text :String ):void<br />
+ getDescription ():String<br />
+ setName (text :String ):void<br />
+ getName ():String<br />
+ getDbName ():String<br />
+ getDbPrefix ():String<br />
+ setUri (text :URI):void<br />
+ getUri ():URI<br />
+ addSimpleProperty (property :GridResourceSimpleProperty ):void<br />
+ getSimpleProperty (propertyName :String ):GridResourceSimpleProperty<br />
+ getSimpleProperties ():Collection<br />
+ addResource (resource :URI):void<br />
+ getResources ():Collection<br />
+ toString ():String<br />
+ clear ():void<br />
+ getNode ():Node<br />
+ setNode (xmlNode :Node ):void<br />
product<br />
<br />
><br />
> −GridResourceFactory ():anonym<br />
+ getGridResources (document :Document ):List<br />
Builder−Pattern<br />
builder<br />
4. Design<br />
GridResourceSimpleProperty<br />
> + GridResourceSimpleProperty ():GridResourceSimpleProperty<br />
+ getName ():String<br />
+ setName (string :String ):void<br />
+ getType ():String<br />
+ setType (string :String ):void<br />
+ getUnit ():String<br />
+ setUnit (string :String ):void<br />
+ getValue ():String<br />
+ setValue (string :String ):void<br />
+ toString ():String<br />
+ clear ():void<br />
XmlDB<br />
> + XmlDB():XmlDB<br />
> + XmlDB(driver :String ,uri :URI):XmlDB<br />
+ query (query :String ):Document<br />
+ update (query :String ):long<br />
+ storeGridResource (resource :GridResource ):void<br />
+ createCollection (name :String ):Collection<br />
+ removeCollection (name :String ):void<br />
+ removeFile (name :String ):void<br />
+ listFiles ():String[]<br />
+ selectCollection (collectionName :String ):void<br />
+ updateRessources (currentResources :List ):void<br />
+ formatXML (xml :String ):String<br />
+ transformXML (inout document :Document ,stylesheet :String ):Document<br />
+ readXML(filename :String ):String<br />
Abbildung 4.3.: UML-Paketdiagramm: org.instantgrid.grdb.model<br />
4.4.2. Paket: org.instantgrid.grdb.daemon<br />
Das Paket org.instantgrid.grdb.daemon (s. Abb. 4.4) beinhaltet den GRDB-Daemon,<br />
GRDB-IP-Konnektoren und alle in diesem Zusammenhang notwendigen Schnittstellenbeschreibungen.<br />
Die Schnittstelle zur Steuerung des GRDB-Daemons ist in dem Interface<br />
GrdbDaemonInterface definiert. Das Aktualisierungsintervall und der Treiber für den Information-Provider<br />
kann gesetzt und ausgelesen werden und die Einleitung einer sofortigen<br />
Aktualisierung ist möglich. Des Weiteren können über die Schnittstelle direkt Daten<br />
aus der Datenbank abgefragt werden.<br />
Die Registrierung externer Systeme in den Aktualisierungsprozess wird über das „Beobachter-Entwurfsmuster“<br />
und die Schnittstelle GrdbDaemonListener (/I30/) implementiert.<br />
Erhält der GRDB-Daemon neue Daten vom Information-Provider, werden alle eingetragenen<br />
Klassen über den Aufruf update() informiert. Zur einfachen Erweiterung des Systems<br />
durch neue Konnektoren/Treiber für Information-Provider wird das „Adapter-Entwurfsmuster“<br />
genutzt. Die Treiberklassen müssen lediglich die abstrakte Klasse AbstractGrdb-<br />
Connector (/I40/) erweitern, die Funktion update() implementieren und die Daten in das<br />
D-GRDL-Format überführen.<br />
42
cd: Paket−Übersicht: daemon<br />
Observer−Pattern<br />
subject<br />
observer<br />
+ update ():void<br />
><br />
GrdbDaemonInterface<br />
><br />
GrdbDaemonListener<br />
4. Design<br />
+ setInterval (interval :int ):void<br />
+ getInterval ():int<br />
+ getDriver ():String<br />
+ setDriver (driver :String ):void<br />
+ update ():void<br />
+ query (query :String ):Document<br />
+ addListener (listener :GrdbDaemonListener ):void<br />
+ removeListener (listener :GrdbDaemonListener ):void<br />
+ notifyListeners ():void<br />
GrdbDaemon<br />
<br />
− listeners<br />
− iProvider<br />
client<br />
AbstractGrdbConnector<br />
+ getGrdlDocument ():Document<br />
#setGrdlDocument (document :Document ):void<br />
+ update ():void<br />
MdsConnector<br />
adapter<br />
target<br />
Adapter−Pattern<br />
Abbildung 4.4.: UML-Paketdiagramm: org.instantgrid.grdb.daemon<br />
4.4.3. Paket: org.instantgrid.grdb.portlet<br />
GangliaConnector<br />
Die Klassen für die graphische Oberflächengestaltung (/I10 /I20/) finden sich im Paket<br />
org.instantgrid.grdb.portlet (s. Abb. 4.5). Zur einfachen Trennung von XHTML-Oberflächenbeschreibungen<br />
und Java-Quelltexten wird die Klasse Template genutzt. Diese öffnet<br />
entsprechende GUI-Dateien und ersetzt gegebene Zeichenketten durch Ergebnisse der<br />
Klasse GrdbPortlet. Diese Klasse erweitert das GenericPortlet und hat damit Zugriff<br />
auf alle Daten und Funktionen, die für die Benutzerinteraktion notwendig sind.<br />
4.4.4. Paket: org.instantgrid.grdb.servlet<br />
Zur Generierung von graphischen Auswertungen von Ressourcen-Informationen wird in<br />
dem Paket org.instantgrid.grdb.servlet (s. Abb. 4.6) mit Hilfe der Klasse GrdbServlet<br />
ein entsprechender Servlet-Service zur Verfügung gestellt. Diese Klasse wird in der graphischen<br />
Oberfläche des Portlets als Graphik verknüpft und erhält Daten zum Namen der ausgewählten<br />
Ressource und der darzustellenden Informationen. Die zuständige Werkzeug-<br />
Klasse zur Generierung der Abbildungen ist die GridResourceChartFactory.<br />
43<br />
adapter
Paket−Übersicht: portlet<br />
4. Design<br />
GenericPortlet<br />
GrdbPortlet<br />
> + DaemonController ():void<br />
+ doView (request :RenderRequest ,response :RenderResponse ):void<br />
+ init (config :PortletConfig ):void<br />
+ processAction (request :ActionRequest ,response :ActionResponse ):void<br />
− template<br />
Template<br />
> + Template ():Template<br />
> + Template (templateFile :String ):Template<br />
+ open (templateFile :String ):void<br />
+ toString ():String<br />
+ set(tagString :String ,replaceString :String ):void<br />
Abbildung 4.5.: UML-Paketdiagramm: org.instantgrid.grdb.portlet<br />
cd: Paket−Übersicht: servlet<br />
HttpServlet<br />
GrdbServlet<br />
+ doGet (req :HttpServletRequest ,res:HttpServletResponse ):void<br />
−writeChart (request :HttpServletRequest ,response :HttpServletResponse ):void<br />
><br />
GridResourceChartFactory<br />
> −GridResourceChartFactory ():GridResourceChartFactory<br />
+ createFsChart (resource :GridResource ,outputStream :OutputStream ):void<br />
+ createMemoryChart (resource :GridResource ,outputStream :OutputStream ):void<br />
+ createLoadChart (resource :GridResource ,outputStream :OutputStream ):void<br />
Abbildung 4.6.: UML-Paketdiagramm: org.instantgrid.grdb.servlet<br />
44
4.4.5. Paket: org.instantgrid.grdb.config<br />
4. Design<br />
Die Konfiguration der Anwendung erfolgt durch die Werkzeug-Klasse Config im Paket<br />
org.instantgrid.grdb.config (s. Abb. 4.7). Diese wertet die Datei grdb.properties aus,<br />
die Informationen zu Zugangsdaten, Verzeichnisse und Parameter enthält. Des Weiteren<br />
ist durch die Werkzeug-Klasse I18N eine Unterstützung für die Internationalisierung der<br />
Portlet-Oberfläche bereits implementiert.<br />
cd: Paket−Übersicht: config<br />
><br />
Config<br />
> −Config ():Config<br />
+ getString (key:String ):String<br />
><br />
I18N<br />
> −I18N ():I18N<br />
+ getString (key:String ,language :String ):String<br />
Abbildung 4.7.: UML-Paketdiagramm: org.instantgrid.grdb.config<br />
4.4.6. Paket: org.instantgrid.grdb.test<br />
Die implementierten Klassentests finden sich in dem Paket org.instantgrid.grdb.test (s.<br />
Abb. 4.8). Soweit möglich sollte jede implementierte Funktion einen Test besitzen. Mindestens<br />
jedoch müssen die definierten Testziele (/T10 /T20 /T30 /T40/) erreicht werden. Siehe<br />
auch Kapitel 5.2 und 5.3.<br />
cd: Paket−Übersicht: test<br />
DaemonTest<br />
> + DaemonTest (name :String ):DaemonTest<br />
+ suite ():Test<br />
#runTest ():void<br />
+ testMdsConnector ():void<br />
+ testDaemon ():void<br />
+ update ():void<br />
+ isInvoked ():boolean<br />
GrdbDaemonListernerStub<br />
+ main (args :String[] ):void<br />
+ suite ():Test<br />
AllTests<br />
ConfigTest<br />
> + ConfigTest (name :String ):ConfigTest<br />
+ suite ():Test<br />
#runTest ():void<br />
+ testGetString ():void<br />
+ testGetTranslation ():void<br />
Abbildung 4.8.: UML-Paketdiagramm: org.instantgrid.grdb.test<br />
45<br />
ModelTest<br />
> + ModelTest (name :String ):ModelTest<br />
+ suite ():Test<br />
#runTest ():void<br />
+ testXmlDB ():void<br />
+ testResource ():void<br />
+ testObjects ():void
5. Implementierung und Test<br />
5.1. Implementierung<br />
Die erfolgte Implementierung des in Abschnitt 4 entworfenen Systems soll kurz erläutert<br />
werden. Dazu wird auf die beiden Hauptkomponenten, das GRDB-Portlet und den<br />
GRDB-Daemon, eingegangen und die Integration in die vorhandene Systemstruktur des<br />
IG beschrieben.<br />
5.1.1. Integration<br />
Die Installation der entwickelten Anwendung erfolgt, wie im IG für Zusatzapplikationen<br />
vorgesehen, über das Einspielen eines Debian-Pakets mit jeweiligen vor- und nachgeschalteten<br />
Installationsskripten (/Z10/F10/F20/). Die Änderungen, die das Paket an der<br />
Verzeichnis- und Dateistruktur der CD-ROM des Instant-Grid-Projektes vornimmt, werden<br />
im Weiteren beschrieben. Die Schilderung jeder einzelnen Datei würde den Rahmen<br />
dieser Arbeit jedoch sprengen, daher werden Inhalte weniger relevanter Verzeichnisse ausgespart.<br />
Verzeichnis: /etc/<br />
• Datei: ./init.d/grdbd Link zum Startskript „grdbd.init.debian“ (s.u.).<br />
• Datei: ./ig-software.xml D-GRDL-Beispielbeschreibungen von Softwarekomponenten.<br />
Diese Datei wird vom GRDB-Daemon eingelesen und der Inhalt regelmäßig in<br />
die Datenbank überführt (/F51/).<br />
Verzeichnis: /usr/local/instant-grid-tomcat5/init<br />
• Datei: ./grdbd-init.sh Link zu der Konfigurationsdatei „grdbd.config“ (s.u.) zur Initialisierung<br />
der notwendigen Umgebungsvariablen.<br />
Verzeichnis: $CATALINA_HOME/webapps/grdb<br />
• Verzeichnis: ./css Cascading-Stylesheet-Angaben für das Portlet und die Übersichtsseite.<br />
46
5. Implementierung und Test<br />
• Verzeichnis: ./docs Dokumentation und weitere Informationen zum System.<br />
• Verzeichnis: ./exampledata Beispieldaten von D-GRDL-, Ganglia- und GLUE-Beschreibungen.<br />
• Verzeichnis: ./images Bilder für die Übersichtsseite der Anwendung.<br />
• Verzeichnis: ./logs Ausgabeverzeichnis für Protokolle des GRDB-Daemons.<br />
• Verzeichnis: ./META-INF Meta-Informationen des entsprechenden WAR-Archives.<br />
• Verzeichnis: ./shell Start- und Konfigurationsskripte des Systems (s.u.).<br />
• Verzeichnis: ./WEB-INF Meta-Informationen über das Portlet.<br />
• Verzeichnis: ./wsdd Web Service Deployment Deskriptoren zur Nutzung von WSRF-<br />
Diensten wie MDS4.<br />
• Verzeichnis: ./xhtml XHTML-Template-Dateien für das Portlet.<br />
• Verzeichnis: ./xmlschema XML-Schema-Definitionen der verwendeten XML-Beschreibungssprachen.<br />
• Verzeichnis: ./xquery Die benötigten XQuery-Abfragen sind aus der Anwendung<br />
ausgelagert und somit einfach über dieses Verzeichnis zu modifizieren.<br />
• Verzeichnis: ./xslt XSLT-Skripte zur Umwandlung verschiedener XML-Eingaben.<br />
• Datei: ./build.properties Enthält die Versionsnummer des Projektes für die Integration<br />
ins IG und weitere Informationen zur Compilierung.<br />
• Datei: ./grdbd.javapolicy Berechtigungsangaben des GRDB-Daemon für das Java Sicherheitsmodell.<br />
Diese Datei wird im Rahmen der IG-Tomcat-Init-Skripte eingelesen.<br />
• Datei: ./grdb.javapolicy Berechtigungsangaben des GRDB-Portlets für das Java Sicherheitsmodell.<br />
Diese Datei wird im Rahmen der IG-Tomcat-Init-Skripte eingelesen.<br />
• Datei: ./ig-software.xml Link zu der gleichnamigen Datei im Verzeichnis /etc/ (s.o.).<br />
• Datei: ./index.html Beschreibung und Übersicht der Anwendung.<br />
• Datei: ./LICENCE Lizenzbestimmungen (GPL-Lizenz).<br />
47
5. Implementierung und Test<br />
Verzeichnis: $CATALINA_HOME/webapps/grdb/shell<br />
• Datei: ./grdbd.config Umgebungsvariablen für Portlet und Daemon.<br />
• Datei: ./grdbd.import-cert.sh Skript zur Unterstützung des Imports der Grid-Zertifikate<br />
zum Java-Zertifikatscontainer. Der Import ist notwendig, um auf abgesicherte<br />
WSRF-Dienste wie MDS4 zugreifen zu können. Dies wird im Rahmen des IG jedoch<br />
nicht benötigt.<br />
• Datei: ./grdbd.init.debian.sh GNU/Linux-Init-Skript für Debian Systeme.<br />
• Datei: ./grdbd.init.suse.sh GNU/Linux-Init-Skript für SuSE Systeme.<br />
• Datei: ./grdbd-lokal.sh Skript zur Unterstützung des manuellen Aufrufs des GRDB-<br />
Daemons.<br />
• Datei: ./grdbd.sh Start-Skript des GRDB-Daemons.<br />
• Datei: ./queryDpkg.sh Skript zur Konvertierung von Debian-Paketmanagementinformationen<br />
in eine XML-Darstellung. Wird im Rahmen des IG jedoch nicht benötigt.<br />
5.1.2. Daemon<br />
Der GRDB-Daemon ist ein Kernstück des entwickelten Systems. Er wird während des<br />
Startvorgangs des IG initialisiert und geht im Hintergrund seinen Tätigkeiten nach (/Z11/).<br />
Die Hauptaufgabe des Daemons ist die Abfrage eines Information-Providers zu Daten von<br />
im Grid vorhandenen Hardware-Ressourcen und die Speicherung dieser Informationen in<br />
der Datenbank (s. Kap. 4).<br />
Neben Programmierschnittstellen zur Steuerung und Nutzung des Dienstes existiert eine<br />
Kommandozeilenschnittstelle die es dem Anwender erlaubt, das Verhalten des Daemons<br />
beim Start zu beeinflussen (s. Listing 5.1). Die notwendigen Skripte zur Ausführung<br />
der Komponente finden sich im Verzeichnis $CATALINA_HOME / webapps / grdb /<br />
shell.<br />
knoppix@server : shell > ./ grdbd - lokal .sh -- help<br />
usage : class org . instantgrid . grdb . daemon . GrdbDaemon<br />
-d,-- driver The driver for the Information - Provider<br />
-h,-- help This help<br />
-i,-- interval The interval in seconds for polling the<br />
Information - Provider<br />
-n,--no - loop Runs the daemon only once (i.e. for<br />
debugging and testing )<br />
-p,-- port The listener port for the daemon<br />
Listing 5.1: Kommandozeilenschnittstelle des Daemons<br />
48
5.1.3. Portlet<br />
5.1.3.1. Die Oberfläche<br />
5. Implementierung und Test<br />
Die Oberfläche des GRDB-Portlets (s. Abb. B.1) stellt die wichtigste Schnittstelle zum Benutzer<br />
dar (/Z31/Z100/). Sie ist nahtlos in die Oberfläche anderer IG-Anwendungen integriert<br />
und dient sowohl der Auskunft über Hardware-Ressourcen als auch der Steuerung<br />
des GRDB-Daemons. Die graphische Anwenderschnittstelle ist in insgesamt vier Teilabschnitte<br />
untergliedert, die im Folgenden kurz beschrieben werden.<br />
5.1.3.2. Übersicht und Auswahl der Hardware-Ressourcen<br />
Die im Grid vorhandenen Hardware-Ressourcen werden in dem Feld „Available hardware<br />
resources“ dargestellt (s. Abb. 5.1). Jede Zeile enthält Informationen über den Namen,<br />
die CPU-Auslastung und den freien Haupt- sowie Festplattenspeicher der Ressource<br />
(/Z70/I10/). Die Zeile mit der Beschriftung „Total“ enthält hingegen die Summe bzw. den<br />
Durchschnitt aller Daten der dargestellten Ressourcen. Weiter besteht die Möglichkeit die<br />
Liste nach den angegebenen Kategorien auf- und absteigend zu sortieren.<br />
Abbildung 5.1.: Screenshot: Ressourcenübersicht und -auswahl im Portlet<br />
Wird der Name einer Ressource ausgewählt, so beziehen sich anschließend alle Informationen<br />
der Seite auf sie. Anwendung findet diese Möglichkeit zum Beispiel bei der Verknüpfung<br />
des Fraunhofer Workflow-Editors mit der GRDB-Oberfläche (/Z80/P20/F100/).<br />
Die Auswahl einer geeigneten Ressource kann daher auch direkt über die URL der Seite<br />
erfolgen (s. Listing 5.2). Dabei gilt es die Zeichenkette RESOURCE_ID durch die eindeutige<br />
Kennzeichnung einer Hardware-Ressource zu ersetzen.<br />
49
5. Implementierung und Test<br />
http :// server :8080/ gridsphere / gridsphere /? cid = grdbtab & resourceID = RESOURCE_ID<br />
Listing 5.2: Auswahl einer Ressource über die URL<br />
5.1.3.3. Visualisierung der Auslastungsinformationen<br />
Um einen schnellen und intuitiv begreifbaren Überblick über den Status der Hardware-<br />
Ressourcen im Grid zu erhalten (/P10 /Z90 /F90/), werden auf der rechten Seite der Oberfläche<br />
ausgewählte Auslastungsinformationen graphisch aufbereitet dargestellt (s. Abb.<br />
5.2). Grundlage dieser Daten ist entweder die gebildete Summe bzw. der Durchschnitt aller<br />
Ressourcen-Informationen oder die Daten einer zuvor ausgewählten Hardware-Ressource.<br />
(a) CPU-Auslastung (b) Hautspeicher-Auslastung (c) Festplatten-Auslastung<br />
Abbildung 5.2.: Screenshots: Graphische Auswertung der Auslastungsinformationen<br />
5.1.3.4. Steuerung des GRDB-Daemons<br />
Neben der Anzeige von Ressourcen-Informationen kann über die graphische Oberfläche<br />
auch der GRDB-Daemon gesteuert werden (s. Abb. 5.3). In dem Feld „Daemon controller“<br />
wird der Zugriffspfad auf den GRDB-Daemon angegeben und aktuelle Daten können<br />
angefordert werden. Des Weiteren ist es möglich, das Intervall für die automatische Aktualisierung<br />
der Ressourcen-Informationen anzugeben. Als dritter Punkt wird eine Auswahl<br />
verschiedener Information-Provider (derzeit Ganglia und MDS4) gegeben zu denen im<br />
laufenden Betrieb gewechselt werden kann (/P40 /I20 /P40 /F31/).<br />
Abbildung 5.3.: Screenshot: Daemon-Controller im Portlet<br />
50
5.1.3.5. Auflistung der Details<br />
5. Implementierung und Test<br />
Die Darstellung der Informationen basiert auf Daten, die in der Datenbank in Form der<br />
D-GRDL gespeichert sind. Eine der wichtigsten Eigenschaften der verwendeten Beschreibungssprache<br />
ist ihre Erweiterbarkeit. Auf der Oberfläche können, auch aufgrund der<br />
Übersichtlichkeit, daher nicht alle Informationen graphisch wiedergegeben werden. Das<br />
Feld „XML result“ stellt dem interessierten Benutzer daher die verwendeten Eingabedaten<br />
für die Oberflächengenerierung zur Verfügung (s. Abb. 5.4). Wurde zuvor eine Hardware-<br />
Ressource zur Darstellung ausgewählt, so werden lediglich Informationen über diese aufgelistet<br />
(/I30/F80/).<br />
5.2. Statische Testverfahren<br />
Abbildung 5.4.: Screenshot: XML-Details im Portlet<br />
Werkzeuggestützte Quelltextanalysen können sehr erfolgreich zur Qualitätssteigerung von<br />
Software-Projekten eingesetzt werden. Das Ziel der Untersuchungen ist die Ermittlung<br />
von potentiellen Fehlern und Verstößen gegen vorhandene Spezifikationen. Mängel und<br />
Abweichungen sollen hierbei so früh wie möglich erkannt werden, noch bevor sie im weiteren<br />
Verlauf der Softwareentwicklung zum Tragen kommen (vgl. [52, 53]). Im Rahmen<br />
dieser Arbeit kamen daher verschiedene Analysewerkzeuge zum Einsatz, um die Qualität<br />
des zu entwickelnden Systems gewährleisten zu können.<br />
5.2.1. Kodierungsrichtlinien<br />
Einleitung<br />
Fehler, die ein Programmierer während der Implementierung macht, sind häufig auf Eigenheiten<br />
der menschlichen Wahrnehmung zurückzuführen. Mit dieser Thematik haben<br />
51
5. Implementierung und Test<br />
sich unter anderem Weinberg[54], Schneiderman[55] und Grams[56] befasst. Demnach lassen<br />
sich durch die Beachtung einiger Regeln viele Fehler vermeiden. Insbesondere die<br />
Verwendung von Kodierungsrichtlinien und automatisierten Testverfahren können eine<br />
Vielzahl von Fehlern vermeiden (vgl. [8]).<br />
Im Rahmen dieser Arbeit wurde auf die strikte Einhaltung der „Code Conventions for<br />
the Java Programming Language“ 1 von Sun geachtet. Das Unternehmen führt zusätzlich<br />
folgende Gründe für die Verwendung der Richtlinien an:<br />
• 80% der Kosten innerhalb der Lebenszeit einer Software besteht aus Wartung.<br />
• Die meiste Software wird im Laufe ihrer Lebensspanne in der Regel nicht nur vom<br />
ursprünglichen Autor gewartet.<br />
• Kodierungsrichtlinien erhöhen die Lesbarkeit von Software und erlauben Entwicklern<br />
ein schnelleres Verständnis von unbekannten Quelltexten.<br />
• Der Quelltext eines Programmes sollte ebenso einheitlich und strukturiert sein wie<br />
das Produkt selbst.<br />
Verwendete Software<br />
Zur Einhaltung der oben genannten Kodierungsrichtlinien wurde die Software Checkstyle<br />
2 verwendet. Das Programm unterstützt den Entwickler bei der automatischen Überprüfung<br />
aller Quelltexte gegen diverse Kodierungsrichtlinien. Zur Optimierung des Ablaufes<br />
wurde Checkstyle in die Entwicklungsumgebung integriert, damit direkt bei der Eingabe<br />
Verstöße gemeldet und eine einfache projektweite Analyse der Codes ermöglicht werden<br />
konnte.<br />
5.2.2. Bug-Patterns<br />
Einleitung<br />
Analog zu Entwurfsmustern im Softwareentwurf, die die Software im positiven Sinne<br />
strukturieren, existieren Muster, die auf eine fehlerhafte Ausführung hindeuten. Die Erkenntnis<br />
der Vielzahl von Ausdrücken in einer Programmiersprache, die möglicherweise<br />
ein unerwünschtes Verhalten hervorrufen, ist aus Erfahrungen größerer und kleinerer<br />
Projekte der letzten Jahrzehnte hervorgegangen. Zu häufig auftretenden Fehlern gehören<br />
beispielsweise Nullzeigerdereferenzierungen oder ungültige Vergleiche von Zeichenkettenobjekten.<br />
Software-Systeme, die Programme auf diese und ähnliche Fehler hin untersuchen,<br />
verwenden hierzu Verfahren zur Daten- und Kontrollflussanalyse im Quelltext oder<br />
1 http://java.sun.com/docs/codeconv<br />
2 http://checkstyle.sourceforge.net<br />
52
5. Implementierung und Test<br />
Objektcode. Bug-Patterns werden ausführlich anhand der Programmiersprache Java in einem<br />
Buch von E. Allen[57] beschrieben.<br />
Verwendete Software<br />
Eine detaillierte Analyse verschiedener Softwaresysteme für statische Testverfahren findet<br />
sich in [58]. Die Tabelle 5.1 gibt einen komprimierten Vergleich der in dieser Arbeit verwendeten<br />
Software wieder. Die jeweiligen Anwendungen konnten in die Entwicklungsumgebung<br />
integriert werden, um, wie bei der Überprüfung auf Einhaltung der Kodierungsrichtlinien,<br />
auch hier während der Programmierung direkt den Entwicklungsprozess zu<br />
unterstützen.<br />
Tabelle 5.1.: Analysierte Fehlertypen. Angelehnt an [58].<br />
Kategorie Beispiel FindBugs JLint PMD Lint4J<br />
Allgemeines Nullzeigerreferenzierung x x x x<br />
Nebenläufigkeit Auftritt von Deadlocks x x x x<br />
Array Länge kleiner 0 x x o o<br />
Mathematik Division durch Null o x o o<br />
Bedingungen Unerreichbarer Code x o x x<br />
Zeichenketten Stringvergleich mittels == x x x x<br />
E/A-Ströme Nicht geschlossener Strom x o o o<br />
Ungenutzte Anw. Ungenutzte lokale Variable x o x x<br />
Entwurf Leerer Konstruktor x o x x<br />
Unnötige Anw. Unnötiger Rückgabewert o o x x<br />
Performance Objekterzeugung in Schleifen x o x x<br />
FindBugs. FindBugs 3 [59] ist ein Erkennungsystem von Bug-Patterns für Java. Es nutzt<br />
verschiedene Techniken, um Präzision, Effizienz und Benutzbarkeit zu vereinen. Ein Hauptmerkmal<br />
ist die Verwendung von abstrakten Syntax-Bäumen (ähnlich zu [60]), um verdächtige<br />
Quelltextabschnitte zu identifizieren. In vielen Fällen werden auch Datenflussanalysen<br />
durchgeführt, etwa um Nullzeigerreferenzierung zu entdecken.<br />
JLint. JLint 4 [61] analysiert syntaktisch, wie FindBugs, den Java Bytecode und überprüft<br />
den Datenfluss im Programm. JLint erstellt zusätzlich einen Graphen aller Blockierungen,<br />
um zyklische Wiederholungen in diesem zu entdecken. Dies ermöglicht die Aufdeckung<br />
3 http://findbugs.sourceforge.net<br />
4 http://jlint.sourceforge.net<br />
53
5. Implementierung und Test<br />
von möglichen Deadlocks. Des Weiteren beinhaltet das Programm Analysen für Abhängigkeiten<br />
von Threads innerhalb einer Applikation.<br />
PMD. Die Funktionsweise von PMD 5 entspricht grundsätzlich der von FindBugs und<br />
JLint, jedoch ohne Datenflussanalyse. PMD untersucht den Quelltext aber zusätzlich nach<br />
Kodierungsrichtlinien, die ebenfalls eine fehlerhafte, oder aber zumindest eine unsaubere<br />
Programmierung vermuten lassen.<br />
Lint4J. Auch Lint4J 6 untersucht den Quelltext und Bytecode nach Problemen bzgl. der<br />
Performance, Skalierbarkeit und Threadsicherheit, analysiert den Datenfluss und erstellt<br />
Blockierungsgraphen. Die durchgeführten Analysen basieren laut Aussagen des Herstellers<br />
auf Erfahrungswerten, die während der Implementierung von Performance- und sicherheitskritischen<br />
Anwendungen gewonnen wurden.<br />
Neben diesen Programmen existieren weitere Überprüfungssysteme wie z.B. Bandera 7 [62]<br />
und ESC/Java 8 [63], welche jedoch deutlich weitergehende Ansätze verfolgen. Diese basieren<br />
auf Beweisen von zuvor bestimmten, formalen Vor- und Nachbedingungen (vgl.<br />
[64, 65]) und Verifikation von Zustandsmodellen. Aufgrund der hohen Komplexität und<br />
des wissenschaftlichen Schwerpunkts dieser Möglichkeiten wurde von deren Nutzung im<br />
Rahmen dieser Arbeit abgesehen.<br />
5.2.3. Bewertung<br />
Der Einsatz statischer, automatisierter Analyseverfahren hat deutlich zur Lesbarkeit und<br />
Qualität der geschriebenen Quelltexte beigetragen. Insbesondere die Integration in die Entwicklungsumgebung<br />
erleichterte den Umgang wesentlich und Hinweise konnten sofort<br />
umgesetzt werden. Diese Hinweise waren aufgrund der hohen Zahl an formalisierten Erfahrungen<br />
zu weit verbreiteten und häufig gemachten Fehlern sehr zahlreich und führten<br />
zu einem ständigen Lernprozess während der Entwicklung. So wurden insbesondere<br />
robustere und effizientere Lösungen implementiert, deren Funktionsweise im Anschluss<br />
durch dynamische Testfälle überprüft werden konnten.<br />
Es liegt jedoch in der Natur der Sache, dass nicht alle Meldungen zu Quelltextabschnitten<br />
auf existierende Probleme oder Fehler hinweisen. Je nach Kontext sind verschiedene,<br />
gleichwertige Lösungsansätze möglich und Falschmeldungen sind nicht gänzlich zu vermeiden.<br />
5 http://pmd.sourceforge.net<br />
6 http://www.jutils.com<br />
7 http://bandera.projects.cis.ksu.edu<br />
8 http://secure.ucd.ie/products/opensource/ESCJava<br />
54
5.3. Dynamische Testverfahren<br />
5.3.1. Einleitung<br />
5. Implementierung und Test<br />
Unter dynamischen Testverfahren wird das Testen von Software durch Ausführung von<br />
Testobjekten beschrieben. Dabei wird ein Teil der Software über definierte Schnittstellen<br />
mit vorgegebenen Eingaben ausgeführt und das Ergebnis mit zuvor spezifizierten Erwartungswerten<br />
verglichen. Das Ziel des dynamischen Testens ist der Nachweis der Erfüllung<br />
von festgelegten Anforderungen durch das implementierte Programmstück und die Aufdeckung<br />
von eventuellen Abweichungen und Fehlerwirkungen (vgl. [52, 53]). Dynamische<br />
Testverfahren werden ebenfalls bei der inkrementellen Softwareentwicklung benötigt.<br />
Während der Überarbeitung der Programmstruktur als Reaktion auf neue Anforderungen,<br />
darf sich das Verhalten der restlichen Funktionen nicht ändern. Um dies gewährleisten zu<br />
können, sind entsprechende Testverfahren erforderlich.<br />
Im Gegensatz zu automatisierten Quelltextanalysen ist ein vollständiger Test der Anwendung<br />
im Allgemeinen jedoch nicht möglich. Die Überprüfung aller in Frage kommenden<br />
Eingabedaten und deren Kombinationen, unter Berücksichtigung jeder Randbedingung,<br />
ergäben eine nahezu unbegrenzte Anzahl an Möglichkeiten (vgl. [66]). Daher beschränken<br />
sich Tests auf eine systematisch festgelegte Teilmenge der Eingabewerte. Die<br />
Testergebnisse des entwickelten Systems finden sich in Anhang B.2.<br />
5.3.2. Testverfahren<br />
Um eine sinnvolle Teilmenge der möglichen Eingabewerte zu bestimmen, bieten sich bei<br />
der Testfallgenerierung je nach Verfügbarkeit der Quelltexte drei systematische Verfahren<br />
an. Von diesen wurde in der vorliegenden Arbeit jeweils Gebrauch gemacht; sie werden<br />
im Folgenden kurz beschrieben. Eine ausführlichere Schilderung der Verfahren ist im Rahmen<br />
dieser Arbeit nicht möglich, daher sei auf die einschlägige Fachliteratur verwiesen<br />
(vgl. [67, 68, 66]).<br />
Blackbox-Verfahren. Bei Blackbox-Verfahren ist der innere Aufbau der Testobjekte nicht<br />
bekannt. Sinnvolle Werte für Testbeschreibungen werden aus Spezifikationen ermittelt<br />
und anhand verschiedener Methoden geprüft. So werden Eingabewerte, bei denen davon<br />
ausgegangen wird, dass sich das Testobjekt jeweils gleich verhält, in Äquivalenzklassen<br />
eingeteilt. Da Fehlerzustände in Programmen häufig an Grenzbereichen dieser Äquivalenzklassen<br />
auftreten, werden in der Grenzwertanalyse die äußersten Werte der Klassen<br />
einer Prüfung unterzogen. Zusätzlich können viele Testobjekte unterschiedliche Zustände<br />
annehmen, die z.B. von Funktionsaufrufen ausgelöst werden. Daher werden häufig ebenfalls<br />
zustandsbezogene Tests durchgeführt. Die Grundlage zur Anwendung von Blackbox-<br />
Verfahren bieten in diesem Zusammenhang unter anderem die Aktivitätsdiagramme aus<br />
55
Abschnitt 3.6.<br />
5. Implementierung und Test<br />
Whitebox-Verfahren. Im Rahmen von Whitebox-Verfahren wird der innere Aufbau der<br />
Testobjekte herangezogen und aufgrund der Programmlogik Testfälle ermittelt. Dabei sollten<br />
grundsätzlich alle Quellcodeteile eines Testobjektes mindestens einmal zur Ausführung<br />
gebracht werden. Bei der Testfallgenerierung kann grundsätzlich eine Anweisungs-,<br />
Zweig-, Bedingungs- und Pfadüberdeckung angestrebt werden. Im Rahmen der vorliegenden<br />
Arbeit wurden Softwaresysteme zur Ermittlung dieser Quelltextüberdeckungen<br />
bei Tests angewendet, um eine hohe und sinnvolle Überdeckung zu gewährleisten.<br />
Intuitive Testfallermittlung. Systematisch ermittelte Testfälle lassen sich durch die intuitive<br />
Testfallermittlung sinnvoll ergänzen, jedoch nicht ersetzen. Grundlage dieser Methode<br />
sind meist Erfahrungen des Testfallerstellers, wo Fehlhandlungen in der Vergangenheit<br />
aufgetreten sind. Dadurch können gegebenenfalls Fehlerwirkungen aufgedeckt werden,<br />
die in den oben genannten Verfahren übersehen worden sind.<br />
5.3.3. Teststufen<br />
Der Softwaretest ist integraler Bestandteil des verwendeten Entwicklungsprozesses. Aus<br />
Sicht des Testens spielt hierbei das allgemeine V-Modell[69] eine besondere Rolle, dessen<br />
Testprinzipien sich auf andere Vorgehensmodelle leicht übertragen lassen. Demnach sind<br />
Testarbeiten zu Entwicklungsarbeiten gleichberechtigte Tätigkeiten, die sich wie folgt gliedern<br />
lassen:<br />
Komponententest. Beim Komponententest werden einzelne Softwarebausteine isoliert<br />
vom Gesamtsystem gegenüber seiner Spezifikation überprüft. Die Grundlagen für die<br />
Testfallgenerierung ergeben sich im vorliegenden System sowohl aus der Anforderungsanalyse<br />
(Kapitel 3), als auch aus sich periodisch wiederholenden Gesprächen mit Projektmitgliedern<br />
und -partnern. Insbesondere kann auf die Ablaufdiagramme der jeweiligen<br />
Anwendungsfälle zurückgegriffen werden. Jeder Aktionszweig wird mittels eines Tests<br />
durchlaufen (gekennzeichnet durch «Aktivitätsnummer».«Transitionsnummer» in Kapitel<br />
3.6), um somit die geforderte Funktionalität im System überprüft. Zum anderen sind<br />
Whitebox-Verfahren angewendet worden, um eine möglichst hohe und vor allem sinnvolle<br />
Überdeckung der Quelltextausführung zu erreichen.<br />
Integrationstest. Das Zusammenspiel von Komponentengruppen, wie es im technischen<br />
Systementwurf der Anwendung spezifiziert wurde (s. Kap. 4), ist Inhalt des Integrationstests.<br />
Gegenstand sind insbesondere die Schnittstellen zur Systemumgebung. Diesem<br />
Aspekt des Testens wurde neben der entsprechenden Testfallgenerierung auch dadurch<br />
Rechnung getragen, dass das System auf zwei unterschiedlichen Hard- und Softwareum-<br />
56
5. Implementierung und Test<br />
gebungen entwickelt und getestet wurde. Die Entwicklungsumgebungen (s. Anhang A)<br />
stellten jeweils alle Kommunikationskomponenten zur Verfügung, die zur Ausführung<br />
von Testfällen zur Verifikation des Systementwurfs notwendig waren.<br />
Systemtest. Beim Systemtest wird überprüft, ob das System als Ganzes die spezifizierten<br />
Anforderungen erfüllt. Dieser Schritt ist notwendig, da viele Funktionen und Systemeigenschaften<br />
aus dem Ineinandergreifen aller Systemkomponenten resultieren und somit erst<br />
auf der Ebene des Gesamtsystems beobachtbar und testbar sind. Durch die Möglichkeit,<br />
das IG in einer virtuellen Umgebung zu nutzen (verwendet wurde VMWare 9 ), konnte im<br />
Laufe des Entwicklungsprozesses immer eine aktuelle Testumgebung geschaffen werden.<br />
Abnahmetest. Der Abnahmetest überprüft abschließend, ob das System alle vereinbarten<br />
Leistungsmerkmale aufweist. Schon während der Implementierung wurden Projektmitgliedern<br />
lauffähige Versionen der Anwendung präsentiert und auf Vollständigkeit hin<br />
überprüft. Zum Abschluss der vorliegenden Arbeit ist das System nochmals im Detail auf<br />
alle geforderten Merkmale hin untersucht worden.<br />
5.3.4. Verwendete Software<br />
Zur Gewährleistung der korrekten Funktionsweise der einzelnen Komponenten des entwickelten<br />
Systems und einer systematischen Generierung der notwendigen Tests kam verschiedene<br />
Software zum Einsatz.<br />
JUnit. JUnit[70] ist ein bekanntes Framework zur einfachen Erstellung von Klassen- und<br />
Interaktionstests. Es ermöglicht die Durchführung von automatisierten, selbst überprüfenden<br />
Klassen- und Komponententests. Das Testobjekt wird hierbei von anderen im Zusammenhang<br />
eines Programms benötigten, mitwirkenden Programmeinheiten isoliert und mit<br />
vorgegebenen Werten zur Ausführung gebracht. Das Ergebnis wird, wie bei dynamischen<br />
Testsystemen üblich, mit einem definierten Wert verglichen. JUnit war Bestandteil der genutzten<br />
Entwicklungsumgebung und erlaubte die kontinuierliche Durchführung der Tests<br />
während der Implementierung.<br />
Coverlipse. Coverlipse 10 ist eine Erweiterung für das verwendete Entwicklungssystem<br />
und kennzeichnet visuell getestete und ungetestete Quelltextzeilen. Es unterstützt den<br />
Entwickler bei der Generierung geeigneter Whitebox-Testfälle und der Aufdeckung nicht<br />
getesteter Quelltextabschnitte.<br />
9 http://www.vmware.com<br />
10 http://coverlipse.sourceforge.net<br />
57
5. Implementierung und Test<br />
Emma. Emma 11 analysiert ebenso wie Coverlipse die Quelltextüberdeckung der verwendeten<br />
Testfälle. Der Schwerpunkt liegt bei Emma jedoch weniger in der Integration in die<br />
Entwicklungsumgebung als vielmehr in der Erstellung übersichtlicher Ergebnisberichte<br />
(siehe B.2).<br />
5.3.5. Bewertung<br />
Die entwickelten, automatisierten Testfälle für das System unterstützten insbesondere die<br />
Umstrukturierung der Quellen und vereinfachten die Fehlerbehebung. Für Komponenten,<br />
für die Testfälle existierten, musste während aufwändiger Fehleranalysen mit Abstand am<br />
wenigsten Zeit investiert werden. Ebenso konnte Programmcode früher Prototypen mittels<br />
geeigneter Testfälle weiterverwendet und einfach in neue Quelltexte integriert werden.<br />
Die Entwicklung von Testfällen zu existierendem Code oder noch zu schreibenden Funktionen<br />
verlangt jedoch ein wenig Selbstdisziplin, da sich deren Nutzen erst im Laufe der<br />
späteren Entwicklung erschließt. Des Weiteren eigneten sich nicht alle Komponenten im<br />
gleichen Maß zum automatisierten Testen. Speziell Komponenten zur Benutzerinteraktion<br />
mussten manuell in regelmäßigen Abständen überprüft werden.<br />
11 http://emma.sourceforge.net<br />
58
6. Zusammenfassung, Kritik und Ausblick<br />
6.1. Zusammenfassung<br />
In der vorliegenden Arbeit wurde eine Ressourcen-Datenbank für das Instant-Grid-Projekt<br />
entwickelt. Die Software ist das Ergebnis einer iterativen und inkrementellen Vorgehensweise<br />
bei der Definition und Umsetzung der Projekt-Anforderungen. Das System integriert<br />
sich vollständig in die vorhandene Infrastruktur und stellt Schnittstellen sowohl für<br />
Anwender, als auch für Entwickler zur Verfügung. Im Rahmen des nächsten Releasezyklus’<br />
wird es Bestandteil der veröffentlichten CD-ROM sein.<br />
Der Schwerpunkt des Entwicklungsprozesses lag in der Integration in die vorhandene<br />
Infrastruktur und der softwaregestützten Qualitätskontrolle während der Implementierung.<br />
Die Kommunikation mit den Projektbetroffenen stand hierbei im Vordergrund der<br />
Arbeit und spielte eine wesentliche Rolle beim Entstehungsprozess.<br />
6.2. Kritik<br />
Trotz einer engen Zusammenarbeit aller Beteiligten wurde zum Ende der Projektlaufzeit<br />
deutlich, dass die Priorisierung während der Implementierung etwas besser hätte gewählt<br />
werden können. Dies betraf insbesondere die Verzahnung der Softwarekomponenten des<br />
FIRST und des GRDB-Daemons. So war es notwendig, die Datenbankstruktur zu einem<br />
späten Zeitpunkt zu modifizieren, und die Entwicklung temporärer Module zur Aktualisierung<br />
von Ressourceninformationen seitens des Fraunhofer Instituts waren unumgänglich.<br />
Die genannten Probleme sind darauf zurückzuführen, dass für die Implementierung des<br />
Systems eine Vielzahl moderner Technologien verwendet werden mussten. Die Einarbeitung<br />
in diese Technologien und Fehler in den verwendeten Software-Systemen haben zu<br />
einem verzögerten Entwicklungsprozess geführt und die Präsentation lauffähiger Prototypen<br />
musste so mehrmals verschoben werden. Um dennoch Aspekte der Oberflächengestaltung<br />
und zu nutzende Funktionen möglichst früh kommunizieren zu können, wurde<br />
die Priorität bei der Entwicklung auf eine lauffähige Version des Portlets und die Integration<br />
in die CD gelegt. Eine stärkere Konzentration auf die Entwicklung des GRDBD wäre<br />
in diesem Zusammenhang sinnvoller gewesen.<br />
59
6.3. Ausblick<br />
6. Zusammenfassung, Kritik und Ausblick<br />
Projekte dieser Größenordnung bieten genügend Potential für weitere Entwicklungen. Die<br />
Dynamik und Evolution von zusammenhängenden Softwaresystemen stellen zukünftige<br />
Herausforderungen dar. So steht etwa die JSR-286-Portletspezifikation[71] kurz vor ihrer<br />
Veröffentlichung, und Datenbanksysteme, die sowohl relationale auch XML basierte Daten<br />
verwalten, werden dedizierte Systeme vermutlich ablösen.<br />
Dies führt auch zu Optimierungsmöglichkeiten innerhalb des Instant-Grid-Projektes.<br />
Insbesondere der Speicheraufwand der für den Betrieb zweier unabhängiger Datenbanksysteme<br />
notwendig ist, könnte so reduziert werden. Aufgrund des hohen Speicherbedarfs<br />
von Java Anwendungen innerhalb einer virtuellen Maschine, ist ebenfalls eine Umsetzung<br />
des GRDBD als native Anwendung denkbar. Ansätze, Java Bytecode in nativen Code zu<br />
überführen, gibt es schon seit längerem[72], und aktuelle Projekte wie der GNU Compiler<br />
für Java 1 könnten eine Umstellung vereinfachen. Ebenso kann eine eingehende Analyse<br />
der vorausgesetzten, technischen Anforderungen (s. Abs. 3.5.4.1) zu einer Herausbildung<br />
von möglichen Alternativen führen.<br />
Ein weiterer Aspekt sind Analysen der Performanz des entwickelten Systems in Bezug<br />
auf die Anzahl der existierenden Hardware-Ressourcen, der Menge an Software-Beschreibungen<br />
und des Aktualisierungsintervalls des GRDB-Daemons und der Information-Provider.<br />
Diese Ergebnisse haben einen direkten Einfluss auf die Struktur der Datenbank und<br />
dem Zusammenspiel des GRDBD, der IP und des GWES (/T50/T60/). Ebenso können Möglichkeiten<br />
der automatisierten Ermittlung von Software-Ressourcen untersucht werden<br />
(/D60/ F51/).<br />
Darüber hinaus sind Erweiterungen der Benutzeroberfläche denkbar. So können zur Gestaltung<br />
der Interaktionsstruktur Punkte der ISO 13407 2 herangezogen werden und die<br />
einschlägige Literatur[73, 74] für das Design der Oberfläche berücksichtigt werden. Auch<br />
sind weitere Auswertungen der gesammelten Daten in Betracht zu ziehen, wie etwa die<br />
graphische Darstellung von Auslastungsdaten innerhalb eines gesetzten Zeitintervalls -<br />
eine Erweiterung der Datenbankstruktur zur Speicherung von Zeitinformationen vorausgesetzt<br />
(/F110/). Als letzte Punkte sind eine mögliche Internationalisierung des Portlets<br />
und die Einbindung eines Editors zur Bearbeitung von Software-Beschreibungen zu nennen.<br />
1 http://gcc.gnu.org/java<br />
2 Benutzer-orientierte Gestaltung interaktiver Systeme<br />
60
A. Verwendete Konfiguration<br />
A.1. Hardware<br />
Die Entwicklung des Systems erfolgte abwechselnd auf zwei unterschiedlichen Arbeitsplatzrechnern.<br />
Durch diese Maßnahme werden unter anderem unvollständige Teilpakete<br />
des zu entwickelnden Systems frühzeitig erkannt und mögliche Inkompatibilitäten rechtzeitig<br />
aufgedeckt.<br />
Tabelle A.1.: Verwendete Hardware<br />
Kategorie Arbeitsplatzrechner 1 Arbeitsplatzrechner 2<br />
Bezeichnung Dell Precision 380 Fujitsu-Siemens A7600<br />
Architektur 64 Bit (EM64T) 32 Bit (x86)<br />
Prozessor Intel Pentium 4HT Mobile AMD Athlon 2000+<br />
Taktung 3,00 GHz 1,60 GHz<br />
Speicher 1024 MB 512 MB<br />
Betriebssystem SuSE Linux 10.1 (Kernel 2.6.12) SuSE Linux 10.1 (Kernel 2.6.16)<br />
A.2. Software<br />
Nachfolgend sind alle relevanten Software-Pakete aufgeführt, die zum Aufbau eines, zur<br />
verwendeten Entwicklungsumgebung identischen, Arbeitsumfeldes dienen.<br />
Tabelle A.2.: Verwendete Software<br />
Kategorie Name Version URL<br />
Dokumentation Auriga 0.1b www.aurigalogic.com<br />
Dokumentation Poseidon for UML 4.2.1 (CE) www.gentleware.com<br />
Dokumentation Xref 1.6.8 www.xref-tech.com<br />
Dynamisches Testen Coverlipse 0.9.5.2 http://coverlipse.sf.net<br />
Dynamisches Testen Emma 2.0.5312 emma.sf.net<br />
Dynamisches Testen JUnit 3.8.1 junit.sf.net<br />
Entwicklungsumgebung Ant 1.6.5 ant.apache.org<br />
Entwicklungsumgebung Eclipse SDK 3.2 www.eclipse.org<br />
61
A. Verwendete Konfiguration<br />
Entwicklungsumgebung GridSphere Portal 2.2.5 www.gridsphere.org<br />
Entwicklungsumgebung Instant-Grid 0.4nb www.instant-grid.org<br />
Entwicklungsumgebung Java SDK 1.5.0_07 java.sun.com<br />
Entwicklungsumgebung Linux Kernel 2.6.12 www.kernel.org<br />
Entwicklungsumgebung Tomcat 5.0.28 tomcat.apache.org<br />
Entwicklungsumgebung Subversion 1.3 subversion.tigris.org<br />
Entwicklungsumgebung VMWare 5.5.1 http://www.vmware.com/<br />
Quelltextanalyse Checkstyle 4.2 checkstyle.sf.net<br />
Quelltextanalyse FindBugs 1.1.0 findbugs.sf.net<br />
Quelltextanalyse Lint4J 0.9.11 www.jutils.com<br />
Quelltextanalyse PMD 3.7 pmd.sf.net<br />
62
B. Dokumentation<br />
B.1. Quelltexte<br />
Aus Platzgründen befinden sich die Quelltexte auf der beigefügten CD-ROM oder kann<br />
unter grid.alexanderwillner.de heruntergeladen werden.<br />
B.2. Testergebnisse<br />
Die Übersicht der getesteten Quelltextabschnitte befindet sich auf den Seiten 64ff.<br />
B.3. GRDB-API<br />
Aus Platzgründen befindet sich die Dokumentation der API auf der beigefügten CD-ROM<br />
oder kann unter grid.alexanderwillner.de heruntergeladen werden.<br />
B.4. GRDB-Portletübersicht<br />
Die Übersichtsgraphik des GRDB-Portlets befindet sich auf Seite 66.<br />
B.5. D-GRDL-Spezifikation<br />
Die Spezifikation der D-GRDL befindet sich auf den Seiten 67ff.<br />
63
[all classes]<br />
nameclas,%method,%block,%line,%<br />
all classes 100%(12/12) 100%(88/88) 91%(1458/1606) 91%(441/486)<br />
file:/home/awilner/Software3/gridsp.ap/docs/coverage/_files/overview.html #1 EMACoverageReport(generatedWedSep2710:23:12CEST206) 16.10.206<br />
OVERALCOVERAGESUMARY<br />
OVERALSTATSUMARY<br />
totalpackages: 3<br />
totalexecutablefiles: 12<br />
totalclasses: 12<br />
totalmethods: 88<br />
totalexecutablelines: 486<br />
name clas,%method,%block,%line,% COVERAGEBREAKDOWNBYPACKAGE<br />
org.instantgrid.grdb.daemon 100%(4/4) 100%(32/32) 82%(586/715) 84%(194/231)<br />
org.instantgrid.grdb.model 100%(6/6) 100%(51/51) 98%(817/836) 97%(234/242)<br />
org.instantgrid.grdb.config 100%(2/2) 100%(5/5) 100%(55/55) 100%(13/13)<br />
[all classes]<br />
EMMA2.0.5312(C)VladimirRoubtsov EMACoverageReport(generatedWedSep2710:23:12CEST206)<br />
[all classes] COVERAGESUMARYFORPACKAGE[org.instantgrid.grdb.daemon]<br />
clas,%method,%block,%line,% name org.instantgrid.grdb.daemon 100%(4/4) 100%(32/32) 82%(586/715) 84%(194/231)<br />
name clas,%method,%block,%line,% COVERAGEBREAKDOWNBYSOURCEFILE<br />
GangliaConnector.java 100%(1/1) 100%(4/4) 81%(79/98) 81%(30/37)<br />
GrdbDaemon.java 100%(1/1) 100%(21/21) 81%(449/556) 84%(145/173)<br />
MdsConnector.java 100%(1/1) 100%(3/3) 94%(44/47) 87%(13/15)<br />
AbstractGrdbConnector.java 100%(1/1) 100%(4/4) 100%(14/14) 100%(6/6)<br />
[all classes]<br />
EMMA2.0.5312(C)VladimirRoubtsov EMACoverageReport(generatedWedSep2710:23:12CEST206)<br />
[all classes] COVERAGESUMARYFORPACKAGE[org.instantgrid.grdb.model]<br />
clas,%method,%block,%line,% name org.instantgrid.grdb.model 100%(6/6) 100%(51/51) 98%(817/836) 97%(234/242)<br />
name clas,%method,%block,%line,% COVERAGEBREAKDOWNBYSOURCEFILE<br />
XmlTransformer.java 100%(1/1) 100%(3/3) 91%(74/81) 83%(20/24)<br />
GridResourceFactory.java 100%(1/1) 100%(2/2) 96%(139/145) 95%(37/39)<br />
XmlDB.java 100%(1/1) 100%(13/13) 98%(293/299) 98%(80/82)<br />
GridResource.java 100%(1/1) 100%(20/20) 100%(223/223) 100%(66/66)<br />
GridResourceSimpleProperty.java 100%(1/1) 100%(11/11) 100%(80/80) 100%(27/27)<br />
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<br />
EMMA2.0.5312(C)VladimirRoubtsov EMACoverageReport(generatedWedSep2710:23:12CEST206)<br />
[all classes] COVERAGESUMARYFORPACKAGE[org.instantgrid.grdb.config]<br />
clas,%method,%block,%line,% name org.instantgrid.grdb.config 100%(2/2) 100%(5/5) 100%(55/55) 100%(13/13)<br />
nameclas,%method,%block,%line,% COVERAGEBREAKDOWNBYSOURCEFILE<br />
Config.java 100%(1/1) 100%(3/3) 100%(26/26) 100%(7/7)<br />
I18N.java 100%(1/1) 100%(2/2) 100%(29/29) 100%(6/6)<br />
[all classes]<br />
EMMA2.0.5312(C)VladimirRoubtsov
B. Dokumentation<br />
Abbildung B.1.: Screenshot: Übersicht des GRDB-Portlets<br />
66
DGI FG 2–4<br />
Spezifikation der<br />
D-Grid-Ressourcenbeschreibungssprache<br />
D-GRDL<br />
Auszüge für das InstantGrid-Projekt<br />
Dr. Armin Wolf<br />
Fraunhofer FIRST, Kekuléstr. 7, D-12489 Berlin<br />
Stand: September 2006<br />
zur projektinternen Verwendung
Auszug aus der D-GRDL für das InstantGrid-Projekt 1<br />
Inhaltsverzeichnis<br />
1 Ziele und Grenzen 2<br />
2 Grundlagen der Sprachdefinition 3<br />
2.1 Kontextfreie Grammatiken . . . . . . . . . . . . . . . . . . . . . 3<br />
2.2 XML und XML-Schema sowie XPath . . . . . . . . . . . . . . . . 4<br />
3 Beschreibungssprache 4<br />
3.1 Bezeichner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
3.2 Ressourcen und deren Klassen . . . . . . . . . . . . . . . . . . . . 5<br />
3.3 Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
3.4 Ressourcen-Aggregation . . . . . . . . . . . . . . . . . . . . . . . 10<br />
3.4.1 Einfache Aggregation . . . . . . . . . . . . . . . . . . . . 10
Auszug aus der D-GRDL für das InstantGrid-Projekt 2<br />
1 Ziele und Grenzen<br />
Ein Ziel dieser Spezifikation ist es, eine (Ziel-)Sprache D-GRDL zu definieren,<br />
die möglichst vielen der bestehenden (und teilweise im Umbruch befindlichen)<br />
Ressourcenbeschreibungen gerecht wird. Übersetzer zwischen bestehenden Sprachen<br />
und D-GRDL kann es von unserer Seite innerhalb des jetzigen Projekts<br />
aufgrund des damit verbundenen Aufwands nicht geben. Es gilt mit D-GRDL<br />
eine gemeinsame Sprache zu haben, die es erlaubt, Ressourcen unterschiedlicher<br />
Grid-Infrastrukturen mit einem einzigen Formalismus zu beschreiben. Darüber<br />
hinaus soll Software zu deren Verarbeitung bereit gestellt werden, z. B. um<br />
Ressourcen über Infrastrukturgrenzen zu verwalten und aufzufinden. Die so gewonnene<br />
Information kann dann bei und mit der jeweiligen Infrastruktur mit<br />
ihren individuellen Spezifika weiter verarbeitet werden.<br />
In diesem Dokument wird deshalb nicht nur die D-Grid-<br />
Ressourcenbeschreibungssprache, im Folgenden kurz ” D-GRDL“ genannt,<br />
formal spezifiziert und anhand von Beispielen erläutert. Es werden ergänzend<br />
auch Konzepte, Methoden und Verfahren festgelegt, um Beschreibungen von<br />
Grid-Ressourcen zu prüfen, zu speichern, zu aktualisieren und abzufragen.<br />
Ihre Umsetzung und Implementierung soll eine zentrale Aufgabe im Grid-<br />
Computing unterstützen, nämlich das Resource-Matching. Dabei geht es darum,<br />
beschriebene Ressourcen anhand zu erfüllender Eigenschaften aufzufinden,<br />
d. h. Ressourcen zu finden, die gegebenen Anforderungen genügen, so dass<br />
ein Job prinzipiell/potentiell auf einer Grid-Infrastruktur ausführbar ist: seine<br />
Ressourcenbedarfe (requests) müssen durch passende Angebote (matching bids)<br />
erfüllt sein. Dieses Zuordnungsproblem gilt es zu lösen: jeder Nachfrage ist ein<br />
Angebot oder einer Menge (alternativer) passender Angebote zuzuordnen.<br />
Diese Zuordnung erfolgt anhand von Ressourcen-Eigenschaften, die generell statischer<br />
Natur sind. Dynamische Eigenschaften der Ressourcen, wie z. B. aktuelle<br />
Prozessor- oder Speicherauslastungen bleiben dabei unberücksichtigt. Diese Daten<br />
werden erst bei der anschließenden Einlastung des Jobs bei der Auswahl<br />
konkreter Ressourcenangebote aus den passenden ermittelt und eingesetzt. Die<br />
konkrete Einlastung der Jobs auf passende Ressourcen wird Resource-Mapping<br />
bezeichnet und ist nicht Gegenstand der folgenden Überlegungen.<br />
Die D-GRDL und die sie unterstützenden Implementierungen ist daher so<br />
ausgelegt, dass in Ressourcenbeschreibungen grundsätzlich nur auf absehbare<br />
Zeit konstante Informationen repräsentier- und verarbeitbar ist. Die unmittelbare<br />
Repräsentation zeitlich kontinuierlicher oder feingranular diskretisierter<br />
Informationen ist in der D-GRDL nicht möglich. Jedoch bietet die D-<br />
GRDL mit ihrem offenen Mechanismus zur Definition von Eigenschaften (properties)<br />
die Möglichkeit der indirekten Repäsentation solcher Informationen:<br />
Damit können Referenzen auf Dienste festgelegt werden, die einen Zugriff auf<br />
zeit-kontinuierliche Informationen erlauben (z. B. Zugriff auf ein Monitoring-<br />
System). Somit lassen sich Doppelungen separater Formalismen für dynamische<br />
Ressourcen-Informationen, deren Semantik mit der D-GRDL überlappen müsste,<br />
vermeiden, ohne dass sofort den Ressourcenbeschreibungen die gesamte Last<br />
aller dynamischen Informationen aufgebürdet wird.
Auszug aus der D-GRDL für das InstantGrid-Projekt 3<br />
2 Grundlagen der Sprachdefinition<br />
2.1 Kontextfreie Grammatiken<br />
Die formalen Definition der Sprachsyntax basiert auf einer kontextfreien Grammatik<br />
G = (N, T, P, S) bestehend aus<br />
• einer endlichen Menge von Nichtterminalen N<br />
• einer endlichen, zu N disjunkten Menge von Terminalen T, d. h. T ∩N = ∅,<br />
welche im folgenden durch Hochkommata hervorgehoben werden, z. B.:<br />
’
Auszug aus der D-GRDL für das InstantGrid-Projekt 4<br />
Beispiel: Als Beispiel seien im folgenden die Produktionen einer Grammatik<br />
mit Startsymbol Id angegeben, die die Bezeichner einer Programmiersprache<br />
in üblicher Form beschreibt, nämlich als nichtleere Folgen von Buchstaben und<br />
Ziffern, die mit einem Buchstaben beginnen:<br />
Id −> Letter ( Letter | Digit )∗<br />
Letter −> ’a ’ | . . . | ’z ’ | ’A’ | . . . | ’Z’<br />
Digit −> ’0 ’ | ’1 ’ | . . . | ’9 ’<br />
Da sich unmittelbar aus den Produktionen die Nichtterminale und Terminale<br />
der Grammatik ergeben, werden wir im Folgenden auf eine explizite Angabe<br />
dieser Mengen und des Quadrupels G = (N, T, P, S) verzichten.<br />
2.2 XML und XML-Schema sowie XPath<br />
Die D-GRDL ist eine Teilmenge der eXtended Markup Language (XML) 1 , die<br />
einem XML-Schema 2 genügt, wobei wir der Einfachheit halber im Folgenden<br />
die Sprache mit Hilfe einer kontextfreien Grammatik formulieren, jedoch auch<br />
ein entsprechendes XML-Schema angeben, dass u. a. zur Evaluierung oder zu<br />
korrekten Konstruktion von D-GRDL-Konstrukten eingesetzt werden kann.<br />
Um die Semantik der D-GRDL z.B. mittels einzuhaltender Bedingungen zu<br />
formulieren, nutzen wir die Sprache XPath 3 , mit der man auf Teilkonstrukte<br />
einer XML-Sprachkonstrukts referenzieren kann.<br />
Eine Beschreibung dieser Formalismen ist nicht Gegenstand dieses Dokuments.<br />
Detaillierte Definitionen und Spezifikationen dieser Formalismen finden sich in<br />
der einschlägigen und vielfältig verfügbaren Literatur.<br />
3 Beschreibungssprache<br />
3.1 Bezeichner<br />
Bezeichner in D-GRDL-Beschreibungen sind Uniform Resource Identifier<br />
(URI), die im Allgemeinen durch Element-Attribute wiedergegeben werden. Als<br />
URI dürfen beliebige zulässige Bezeichner anyURI verwendet werden, wobei<br />
gängige aber auch eigene Konventionen zu deren Strukturierung umsetzbar sind.<br />
Diese Konventionen sind nicht Bestandteil der D-GRDL und somit durch die<br />
Nutzer der Sprache festzulegen. 4<br />
URI −> ’ uri =”’ anyURI ’” ’<br />
1 siehe http://de.wikipedia.org/wiki/XML zur Übersicht mit weiterführenden Verweisen,<br />
u. a. zu den offiziellen Dokumenten des W3C.<br />
2 siehe http://de.wikipedia.org/wiki/XML_Schema zur Übersicht mit weiterführenden<br />
Verweisen, u. a. zu den offiziellen Dokumenten des W3C.<br />
3 siehe http://de.wikipedia.org/wiki/XPath zur Übersicht mit weiterführenden Verweisen,<br />
u. a. zu den offiziellen Dokumenten des W3C.<br />
4 siehe http://de.wikipedia.org/wiki/Uniform_Resource_Identifier zur Übersicht über<br />
den Aufbau und die Struktur von URIs.
Auszug aus der D-GRDL für das InstantGrid-Projekt 5<br />
3.2 Ressourcen und deren Klassen<br />
Eine Ressource wird in D-GRDL durch ein XML-Element ” “ beschrieben.<br />
Dieses hat obligatorisch einen (eindeutigen) Bezeichner (URI) und<br />
ist einer Ressourcenklasse, benannt durch einen (abstrakten) Bezeichner (URI),<br />
zugeordnet (OfClass). Des weiteren kann eine Ressourcenbeschreibung optional<br />
über einen Namen (Name) sowie über eine Beschreibung (Description) verfügen.<br />
Weitere optionale Teile der Beschreibung sind Angaben über Ressourceneigenschaften<br />
und darüber, welche Ressourcen aggregiert werden (Provides).<br />
Schließlich kann eine Ressourcenbeschreibungen optional nicht weiter unterstützte<br />
oder semantisch interpretierte Beschreibungen in XML enthalten (Unsupported):<br />
Resource −> ’’<br />
OfClass<br />
Name?<br />
Description ?<br />
SimpleProperty∗<br />
Provides?<br />
’’<br />
Integritätsbedingung: Ist eine Menge von Ressourcenbeschreibungen R gegeben,<br />
so müssen deren Bezeichner eindeutig sein. Semantisch bedeutet dies,<br />
dass zwei Beschreibungen gleich sein müssen, wenn es ihre URIs sind:<br />
∀x ∀y : (x ∈ R ∧ y ∈ R<br />
=⇒ x = y .<br />
∧ x/resource[1]/@uri = y/resource[1]/@uri)<br />
Die Zugehörigkeit einer beschriebenen Ressource zu einer Klasse, wird mit dem<br />
Konstrukt<br />
OfClass −> ’’<br />
ausgedrückt. Es besagt, dass die Ressource ein Element der (abstrakten) Menge<br />
ist, die durch den Klassenbezeichner benannt ist. Ferner sollen die Ressourcenund<br />
die Klassenbezeichner disjunkt sein.<br />
Integritätsbedingungen: Die Bezeichner der Ressourcen und ihrer Klassen<br />
müssen disjunkt sein, d. h. für eine gegebene Menge von Ressourcenbeschreibungen<br />
R muss gelten:<br />
∀x ∀y : (x ∈ R ∧ y ∈ R)<br />
=⇒ x/resource[1]/ofClass[1]/@uri = y/resource[1]/@uri .<br />
Formale Semantik: Beschriebene Ressourcen sind Elemente der genannten<br />
Klassen, welche wiederum Teilmengen der Ressourcen sind. — Für jede Menge
Auszug aus der D-GRDL für das InstantGrid-Projekt 6<br />
von Ressourcenbeschreibungen gilt:<br />
∀x : x ∈ R<br />
=⇒ x/resource[1]/@uri ∈ x/resource[1]/ofClass[1]/@uri ,<br />
∀x : x ∈ R<br />
=⇒ x/resource[1]/ofClass[1]/@uri ⊆ {y/resource[1]/@uri | y ∈ R} .<br />
Beispiel: Mit den bis hier vorgestellten Konstrukten ist bereits eine minimale<br />
Ressourcenbeschreibung möglich, die einer Ressource einen eindeutigen Bezeichner<br />
gibt und eindeutig einer Klasse von (gleichartigen) Ressourcen zuordnet:<br />
<br />
<br />
<br />
Die Beschreibung besagt, dass die Ressource xemacs:win:xp ein Element der Ressourcenklasse<br />
urn:dgrdl:software:win:editor ist, welche wiederum eine Teilmenge<br />
aller beschriebenen Ressourcen ist.<br />
Zur besseren Verständlichkeit einer solchen Beschreibung gerade für den Benutzer,<br />
kann sie um optionale Konstrukte zur detaillierten Benennung und Beschreibung<br />
erweitert werden. Diese können beliebige Folgen zulässiger Zeichen<br />
anyString des gewählten Zeichensatzes (z. B. UTF-8) sein.<br />
Das Konstrukt<br />
Name −> ’’ anyString ’’<br />
gibt einer Ressourcenbeschreibung einen optionalen Namen und<br />
Description −> ’< description >’<br />
anyString<br />
’’<br />
versieht es mit einer optionalen Beschreibung, die lediglich deklarativen Charakter<br />
hat. Für die formale Sprachsemantik hat sie keine Relevanz.<br />
Damit kann unsere Ressourcenbeschreibung für xemacs:win:xp für einen Benutzer<br />
verständlicher gestaltet werden:<br />
<br />
<br />
XEmacs i n st a l l a t i o n for MS−Windows−XP<br />
<br />
a window−based text −editor with various features<br />
<br />
<br />
Der ebenfalls semantisch nicht unterstützte, optionale Beschreibungsteil kann<br />
weitere beliebige zulässige XML-Strukuren anyXML enthalten, die zwar für den<br />
Nutzer eine Bedeutung haben, jedoch nicht innerhalb der D-GRDL:<br />
Unsupported −> ’’<br />
anyXML<br />
’’
Auszug aus der D-GRDL für das InstantGrid-Projekt 7<br />
3.3 Eigenschaften<br />
Die einfachste Art eine Eigenschaft von Ressourcen zu beschreiben, besteht darin,<br />
diese zu benennen, ihr einen Typ sowie eine Dimension zu geben und letzlich<br />
mit einem Wert zu versehen. Dazu steht in Ressourcenbeschreibungen das folgende<br />
Konstrukt<br />
SimpleProperty<br />
−> ’’<br />
Value<br />
’’<br />
zur Verfügung, deren Bestandteile durch<br />
Type −> ’ type =”’ TypeId ’”’<br />
TypeId −> BaseTypeId<br />
definiert sind.<br />
Der Eigenschaftswert (Value) ist ein Wert der definierten Basistypen (Integer,<br />
Decimal, . . .DateTime):<br />
Value −> BaseValue<br />
BaseValue −> Integer | Decimal | Boolean | String<br />
| anyURI | Date | Time | DateTime<br />
Die Werte der Basistypen haben dabei folgende syntaktische Struktur:<br />
Integer −> ( ’ −’ | ’+’ )? Unsigned<br />
Decimal −> Integer ( ’ . ’ Unsigned )?<br />
String −> ( Letter | Symbol | Digit | ’ ’)+<br />
Boolean −> ’ true ’ | ’ false ’<br />
Date −> FourDigits ’ −’ TwoDigits ’ −’ TwoDigits<br />
Time −> TwoDigits ’: ’ TwoDigits ’: ’ TwoDigits<br />
DateTime −> Date ’T’ Time<br />
Unsigned −> Digit+<br />
Letter −> ’a ’ | . . . | ’z ’<br />
| ’A’ | . . . | ’Z’<br />
Symbol −> ’ ’ | ’: ’ | ’@’ | ’/ ’ | ’. ’<br />
Digit −> ’0 ’ | ’1 ’ | . . . | ’9 ’<br />
TwoDigits −> Digit Digit<br />
FourDigits −−> TwoDigits TwoDigits<br />
Integritätsbedingungen: Für jede Ressourcenbeschreibung einer Menge sollen<br />
die einfachen Eigenschaftsdefinition eindeutig sein, d. h. mehrere Definitionen<br />
von Eigenschaften mit gleichem Namen sind unzulässig. Ist eine Menge von<br />
Ressourcenbeschreibungen R gegeben, so gilt<br />
ICsimplePropUnique(R,resource) ,
Auszug aus der D-GRDL für das InstantGrid-Projekt 8<br />
wobei<br />
ICsimplePropUnique(R, $P) ≡ {<br />
∀x ∀α ∀β : (x ∈ R<br />
∧ α ∈ x/$P/simpleProperty<br />
∧ β ∈ x/$P/simpleProperty<br />
∧ α/@ident = β/@ident)<br />
=⇒ α = β }<br />
sei, d. h. die eigentlichen Bedingungen sich durch Substitution des Parameter<br />
$P durch resource ergeben. 5<br />
Die möglichen Werte einer einfachen Eigenschaftsdefinition wird durch ihren<br />
Typ eingeschränkt, d. h. wenn dieser Typ ein Basistyp ist, so gilt für eine Menge<br />
von Ressourcenbeschreibungen R<br />
wobei<br />
ICsimplePropBtype(R,resource, ’int’, Integer)<br />
∧ ICsimplePropBtype(R,resource, ’float’, Decimal)<br />
∧ ICsimplePropBtype(R,resource, ’bool’, Boolean)<br />
∧ ICsimplePropBtype(R,resource, ’string’, String)<br />
∧ ICsimplePropBtype(R,resource, ’uri’, anyURI)<br />
∧ ICsimplePropBtype(R,resource, ’date’, Date)<br />
∧ ICsimplePropBtype(R,resource, ’time’, Time)<br />
∧ ICsimplePropBtype(R,resource, ’dateTime’, DateTime) ,<br />
ICsimplePropBtype(R, $P, $T, $S) ≡ {<br />
∀x ∀α : (x ∈ R ∧ α ∈ x/$P/simpleProperty[@type = $T])<br />
=⇒ α/text() ∈ $S }<br />
sei. Das heißt, alle Werte einfacher Eigenschaftsbedinungen müssen dem definierten<br />
Typ entsprechen. Die eigentlichen Bedingungen ergeben sich auch hier durch<br />
Substitution des Parameters, wobei Integer, Decimal, String, anyURI, Date, Time<br />
sowie DateTime die Mengen möglicher Werte (syntaktische Konstrukte) seien,<br />
die durch die Produktionen der gleichnamigen Nichtterminale definiert sind.<br />
Formale Semantik: Einfache Eigenschaftsdefintionen innerhalb von Ressourcenbeschreibungen<br />
legen entsprechend benannte, typisierte und quantifizierte<br />
Eigenschaften der Ressourcen fest. Da diese viel mit mit Feldern (engl. fields)<br />
von Objekten gemein haben, verwenden wir die gleiche Schreibweise wie in objektorientierten<br />
Programmiersprachen (z. B. Java):<br />
∀x : x ∈ R =⇒ evalSimpleProperties(x) ,<br />
wobei bei einer gegebenen Menge von Verbundtypen T und Erfüllung der Integritätsbedingungen<br />
die einfachen Eigenschaftsdefinitionen der Struktur y für<br />
5 Wir benutzen diese abkürzende Schreibweise, um im weiteren Verlauf der Sprachdefinition<br />
eine explizite Auflistung von Bedingungen, die sich von den hier vorgestellten nur in wenigen<br />
Bezeichern unterscheiden, zu vermeiden.
Auszug aus der D-GRDL für das InstantGrid-Projekt 9<br />
eine Ressource r als Konjunktion von Gleichungen interpretiert wird:<br />
evalSimpleProperties(x)<br />
<br />
:=<br />
y∈x/resource/simpleProperty<br />
<br />
E(α,y)<br />
(x/resource[1]/@uri.α/@ident = α/text()<br />
∧ type(x/resource[1]/@uri.α/@ident) = α/@type<br />
∧ unit(x/resource[1]/@uri.α/@ident) = α/@unit) .<br />
Dabei sei die Bedingung der Konjunktion wie folgt definiert:<br />
E(α, y) := α ∈ y[@type=’int’ or . . . or @type=’dateTime’] .<br />
Beispiel: Zur Semantik einfacher Eigenschaften mit elementaren Werten ein<br />
erläuterndes Beispiel, bei der eine Ressourcenbeschreibung vier Eigenschaften<br />
hat, wobeicpuload undtimestamp sicher dynamischer Natur sind, deren Werte<br />
kontinuierlich zu aktualisieren sind. Eine Alternative dazu stellt die Eigenschaft<br />
monitor dar, die auf einen entsprechenden Service verweist, bei dem aktuelle<br />
Eigenschaftswerte abgerufen werden können:<br />
h ≡<br />
<br />
<br />
harlekin<br />
<br />
harlekin PC at Fraunhofer FIRST in room 128<br />
<br />
<br />
2<br />
<br />
<br />
42<br />
<br />
<br />
12234567890<br />
<br />
<br />
http: // localhost:8080 /monitoring/ services /query?wsdl<br />
<br />
Auszug aus der D-GRDL für das InstantGrid-Projekt 10<br />
Es gilt dann<br />
evalSimpleProperties(h) :=<br />
harlekin.cpucount = 2<br />
∧ type(harlekin.cpucount) = int<br />
∧ unit(harlekin.cpucount) = pcs<br />
∧ . . .<br />
Bemerkungen:<br />
∧ harlekin.monitor<br />
= http://localhost:8080/monitoring/services/query?wsdl<br />
∧ type(harlekin.monitor) = uri<br />
∧ unit(harlekin.monitor) = wsdl .<br />
Temporale Aspekte wie zeitliche Änderungen von Eigenschaftswerten in der<br />
Semantik, die auf Prädikatenlogik beruht, nicht berücksichtigt werden. D. h. es<br />
gelten immer die Formeln und damit insbesondere die Eigenschaftswerte zum<br />
Zeitpunkt der Betrachtung. Eine Aussage über Gültigkeitszeiten oder -zeiträume<br />
ist nur indirekt mit Hilfe einer weiteren Eigenschaft möglich. Die Änderung von<br />
Eigenschaftswerten und der sich daraus ergebenden Konsequenzen liegen bei der<br />
Verantwortung des Benutzers.<br />
3.4 Ressourcen-Aggregation<br />
Dem Umstand, dass eine Ressource andere Ressourcen aggregieren kann, wird<br />
in der D-GRDL mit dem optionalen Konstrukt<br />
Provides −> ’’<br />
ObjRef+<br />
’’<br />
Rechnung getragen, das im einfachsten Fall aus einer nichtleeren Folge von<br />
Ressourcen-Referenzen, sprich Verweisen auf Ressourcenbezeichner, besteht:<br />
ObjRef −> ’’<br />
3.4.1 Einfache Aggregation<br />
Unter (einfacher) Aggregation verstehen wir dabei ein (unmittelbares) ” zur Verfügung<br />
stellen“ weiterer Ressourcen. 6 D. h. anders als bei der Klassenzugehörigkeit<br />
ist eine aggregierte Ressource nicht Element der aggregierenden Ressource,<br />
sondern steht lediglich in Relation zu ihr, was wir im folgenden noch formal<br />
präzisieren.<br />
Integritätsbedingung: Damit diese Relation wohldefiniert muss jede aggregierte<br />
Ressource auch beschrieben sein. Mit anderen Worten: auf einer Menge<br />
gegebener Ressourcenbeschreibungen R muss<br />
ICprovidesExists(R,resourceRef)<br />
6 Dies wird auch durch den Elementnamen ” provides“ hervorgehoben.
Auszug aus der D-GRDL für das InstantGrid-Projekt 11<br />
gelten, wobei<br />
sei.<br />
ICprovidesExists(R, $P) ≡ {<br />
∀x ∀α ∃y : (x ∈ R ∧ y ∈ R<br />
∧ α ∈ x/resource/provides/$P)<br />
=⇒ α/@uri = y/resource[1]/@uri }<br />
Formale Semantik: Wie besagt, definiert die Aggregation eine binäre Relation<br />
provides auf Ressourcen: Ist eine Menge von Ressourcenbeschreibungen R<br />
gegeben, dann gilt<br />
wobei<br />
und<br />
sei.<br />
evalProvides(x)<br />
:=<br />
∀x : x ∈ R =⇒ evalProvides(x) ,<br />
<br />
α∈x/resource/provides/resourceRef<br />
evalSimpleProvides(x, α)<br />
evalSimpleProvides(x, y) := x/resource[1]/@uri provides y/@uri<br />
Beispiel: Zur Semantik der Relation provides ein erläuterndes Beispiel, bei dem<br />
drei Ressourcenbeschreibungen gegeben sind:<br />
h ≡<br />
<br />
<br />
harlekin<br />
<br />
harlekin PC at Fraunhofer FIRST in room 128<br />
<br />
<br />
<br />
<br />
<br />
<br />
c ≡<br />
<br />
<br />
cat<br />
<br />
the cat program<br />
<br />
Auszug aus der D-GRDL für das InstantGrid-Projekt 12<br />
u ≡<br />
<br />
<br />
xyz<br />
<br />
anything that have to be s pe c ified<br />
<br />
<br />
Die Beschreibung ist wohldefiniert, da zu jeder Ressourcen-Referenz eine entsprechende<br />
Beschreibung existiert und es gilt:<br />
evalProvides(h) = harlekin provides cat ∧ harlekin provides xyz .<br />
Bemerkung: Es sei bemerkt, dass hier keinerlei Aussage darüber getroffen<br />
wird, ob die Relation provides ggf. weitere Eigenschaften wie z. B. Transitivität<br />
oder Asymmetrie hat.
Glossar<br />
Begriff Beschreibung<br />
Anforderungsverantwortliche Personen, die befugt sind Anforderungen an das<br />
neue System festzulegen.<br />
Apache Der Apache HTTP Server ist ein kostenloser und im<br />
Internet der verbreitetste Webserver.<br />
Cluster Eine Anzahl von eng miteinander vernetzten, gleichartigen<br />
Computern, zur Erhöhung der Rechenkapazität<br />
oder Verfügbarkeit.<br />
Distributed computing Das verteilte Rechnen ist eine Technik, bei der eine<br />
Anwendung auf verschiedene Rechner verteilt und<br />
somit die Aufgabe zur Lösung eines Problems auf<br />
mehrere Ressourcen aufgeteilt wird.<br />
Fachexperten Personen, die als Experten im entsprechenden Anwendungsgebiet<br />
sind. Diese sind häufig Anwender<br />
des späteren Systems und helfen fachliche Fragen<br />
qualifiziert zu beantworten.<br />
Ganglia Ein verteilter Information-Provider der häufig in<br />
Cluster- und Gridsystemen eingesetzt wird.<br />
Globus Toolkit Ein Paket von Softwarekomponenten, die häufig zum<br />
Aufbau und Betrieb einer Grid Plattform verwendet<br />
wird. Siehe auch Abschnitt 2.1.<br />
GLUE Das GLUE Schema ist eine abstrakte Beschreibungssprache<br />
für Grid-Ressourcen. Sie wird im Rahmen<br />
des MDS4 verwendet.<br />
80
B. Dokumentation<br />
Grid Aus dem englischen Sprachraum: Gitter. Ein Grid ist<br />
ein verteiltes System das erlaubt, geographisch auseinander<br />
liegende, autonome Ressourcen dynamisch<br />
zur Laufzeit auszuwählen, zu nutzen und zusammenzufassen.<br />
Dies erfolgt abhängig von ihrer Verfügbarkeit,<br />
Kapazität, Performance, den entstehenden<br />
Kosten und anderen benutzerdefinierten Qualitätsmerkmalen.<br />
Siehe auch Abschnitt 2.1.<br />
GridSphere Ein JSR-168-kompatibles[51] Portal-Framework. Es<br />
wird im Rahmen des D-Grid Integrationsprojektes als<br />
Webportal-Lösung empfohlen.<br />
Information-Provider Software-Komponenten, die detaillierte Informationen<br />
über in einem Netzwerk vorhandene Ressourcen<br />
bereitstellen. Siehe auch MDS4 oder Ganglia.<br />
MDS4 Der Globus Toolkit Monitoring and Discovery Service<br />
ist ein Information-Provider zur Überwachung<br />
von Hardware-Ressourcen in einem Grid.<br />
Meta computing Bezeichnung für eine besondere Form des distributed<br />
computing bei der ausschließlich Großrechenzentren<br />
über ein Hochgeschwindigkeitsnetz verbunden sind.<br />
Middleware Middleware (auch Zwischenanwendung) bezeichnet<br />
in der Informatik anwendungsunabhängige Technologien,<br />
die Dienstleistungen zur Vermittlung zwischen<br />
Anwendungen anbieten, so dass die Komplexität<br />
der zugrunde liegenden Applikationen und Infrastruktur<br />
verborgen wird [75].<br />
OGSA Beschreibung einer Architektur für eine Serviceorientierte<br />
Grid-Umgebung für betriebswirtschaftliche<br />
und wissenschaftliche Zwecke, die im Rahmen<br />
des Global Grid Forums entwickelt wird.<br />
81
B. Dokumentation<br />
Peer-to-peer computing Eine Technik bei der alle Rechner in einem Netz<br />
als gleichberechtigte Kommunikationspartner wirken<br />
und sowohl Server- wie auch Client-Funktionen<br />
übernehmen.<br />
Portlet Ein in Java geschriebenes Programm, dass die Fähigkeiten<br />
eines Portalservers (z.B. GridSphere) erweitert.<br />
Pov-Ray Eine Ray-Tracer Anwendung. Diese nutzen Algorithmen<br />
zur Verdeckungsberechnung von dreidimensionalen<br />
Objekten im Raum, etwa bei der Darstellungsberechnung<br />
im Bereich der 3D-Computergraphik.<br />
Stakeholder Aus dem englischen Sprachraum. Kann in diesem<br />
Zusammenhang als Projekt-, System- oder Anforderungsbetroffene<br />
übersetzt werden.<br />
Systembetroffene Personen, die vom fertigen System direkt betroffen<br />
sind, so z.B. die späteren Anwender.<br />
Hardware-Ressource Ein Sammelbegriff für die Einheit aller Baugruppen<br />
und Peripheriegeräte eines Computers. Eine<br />
Hardware-Ressource entspricht in der Regel einem<br />
physisch existierenden Computer.<br />
Scheduler Bestandteil der verwendeten Grid-Workflow-<br />
Architektur. Der Scheduler verwaltet verschiedene<br />
Workflow-Prozesse und verteilt die Aufgaben auf<br />
die vorhandenen Hardware-Ressourcen. Siehe auch<br />
Abschnitt 2.3.<br />
Tomcat Der Apache Tomcat-Server ist die offizielle Referenzimplementierung<br />
der JSR-154-Spezifikation[50]<br />
(Servlets). Es handelt sich hierbei um eine Umgebung<br />
für Java-Anwendungen, um diese in<br />
Request/Response-orientierten Web-Server zu<br />
integrieren.<br />
82
B. Dokumentation<br />
WSRF Das Web Service Resource Framework gehört zu einer<br />
Reihe von OASIS-Spezifikationen für Web Services.<br />
83
Abbildungsverzeichnis<br />
2.1. Architektur eines Grids [21] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
2.2. Komponenten des Globus-Toolkit 4 [30] . . . . . . . . . . . . . . . . . . . . . 8<br />
2.3. Architektur des Instant-Grid [34] . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
2.4. Architektur des Workflowmanagement-Systems [34] . . . . . . . . . . . . . 13<br />
3.1. UML-Anwendungsfalldiagramm: ermittelte Stakeholder . . . . . . . . . . . 17<br />
3.2. UML-Anwendungsfalldiagramm: grundlegende Anwendungsfälle . . . . . 19<br />
3.3. UML-Anwendungsfalldiagramm: Übersicht des zu entwickelnden Systems 25<br />
3.4. UML-Aktivitätsdiagramm: Anwendungsfall U10 . . . . . . . . . . . . . . . . 26<br />
3.5. UML-Aktivitätsdiagramm: Anwendungsfall U20 . . . . . . . . . . . . . . . . 27<br />
3.6. UML-Aktivitätsdiagramm: Anwendungsfall U30 . . . . . . . . . . . . . . . . 29<br />
3.7. UML-Aktivitätsdiagramm: Anwendungsfall U40 . . . . . . . . . . . . . . . . 31<br />
4.1. UML-Komponentendiagramm: Architektur der GRDB-Anwendung . . . . 37<br />
4.2. UML-Paketdiagramm: org.instantgrid.grdb . . . . . . . . . . . . . . . . . . . 41<br />
4.3. UML-Paketdiagramm: org.instantgrid.grdb.model . . . . . . . . . . . . . . . 42<br />
4.4. UML-Paketdiagramm: org.instantgrid.grdb.daemon . . . . . . . . . . . . . . 43<br />
4.5. UML-Paketdiagramm: org.instantgrid.grdb.portlet . . . . . . . . . . . . . . . 44<br />
4.6. UML-Paketdiagramm: org.instantgrid.grdb.servlet . . . . . . . . . . . . . . . 44<br />
4.7. UML-Paketdiagramm: org.instantgrid.grdb.config . . . . . . . . . . . . . . . 45<br />
4.8. UML-Paketdiagramm: org.instantgrid.grdb.test . . . . . . . . . . . . . . . . 45<br />
5.1. Screenshot: Ressourcenübersicht und -auswahl im Portlet . . . . . . . . . . . 49<br />
5.2. Screenshots: Graphische Auswertung der Auslastungsinformationen . . . . 50<br />
5.3. Screenshot: Daemon-Controller im Portlet . . . . . . . . . . . . . . . . . . . . 50<br />
5.4. Screenshot: XML-Details im Portlet . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
B.1. Screenshot: Übersicht des GRDB-Portlets . . . . . . . . . . . . . . . . . . . . 66<br />
84
Tabellenverzeichnis<br />
2.1. Vergleich: Stromnetz und Grid. Angelehnt an [20]. . . . . . . . . . . . . . . . 5<br />
3.1. Projekt-Ansprechpartner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
3.2. Interessen der Anforderungsbeitragenden (IG-Entwickler) . . . . . . . . . . 18<br />
3.3. Interessen der Anforderungsbeitragenden (FIRST-Entwickler) . . . . . . . . 18<br />
3.4. Interessen der Anforderungsbeitragenden (Portal-Benutzer) . . . . . . . . . 19<br />
3.5. Anforderungsbeschreibung: vorhandenen Probleme . . . . . . . . . . . . . . 20<br />
3.6. Anforderungsbeschreibung: funktionale Anforderungen . . . . . . . . . . . 21<br />
3.7. Anforderungsbeschreibung: zu speichernden Daten . . . . . . . . . . . . . . 22<br />
3.8. Randbedingungen: technische Anforderungen . . . . . . . . . . . . . . . . . 23<br />
3.9. Randbedingungen: Testanforderungen . . . . . . . . . . . . . . . . . . . . . . 23<br />
3.10. Anwendungsfall U10: Konkretisierung U11 . . . . . . . . . . . . . . . . . . . 26<br />
3.11. Anwendungsfall U10: Konkretisierung U12 . . . . . . . . . . . . . . . . . . . 27<br />
3.12. Anwendungsfall U20: Konkretisierung U21 . . . . . . . . . . . . . . . . . . . 28<br />
3.13. Anwendungsfall U20: Konkretisierung U22 . . . . . . . . . . . . . . . . . . . 28<br />
3.14. Anwendungsfall U20: Konkretisierung U23 . . . . . . . . . . . . . . . . . . . 29<br />
3.15. Anwendungsfall U30: Konkretisierung U31 . . . . . . . . . . . . . . . . . . . 30<br />
3.16. Anwendungsfall U30: Konkretisierung U32 . . . . . . . . . . . . . . . . . . . 30<br />
3.17. Anwendungsfall U40: Konkretisierung U41 . . . . . . . . . . . . . . . . . . . 32<br />
3.18. Anwendungsfall U40: Konkretisierung U42 . . . . . . . . . . . . . . . . . . . 32<br />
3.19. Anwendungsfall U40: Konkretisierung U43 . . . . . . . . . . . . . . . . . . . 33<br />
3.20. Zuordnung der involvierten Schnittstellen . . . . . . . . . . . . . . . . . . . 33<br />
3.21. Dialog/Interface: Ressourcendarstellung I10 . . . . . . . . . . . . . . . . . . 34<br />
3.22. Dialog/Interface: Steuerung I20 . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
3.23. Interface: Datenexport I30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
3.24. Interface: Information-Provider-Treiber I40 . . . . . . . . . . . . . . . . . . . 35<br />
5.1. Analysierte Fehlertypen. Angelehnt an [58]. . . . . . . . . . . . . . . . . . . . 53<br />
A.1. Verwendete Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
A.2. Verwendete Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
85
Literaturverzeichnis<br />
[1] A. Chowdhury, L. Nicklas, S. Setia, and E. White, “Supporting Dynamic Space-sharing<br />
on Clusters of Non-dedicated Workstations,” Proceedings of the 17th International Conference<br />
on Distributed Computing Systems (ICDS-97), pp. 28–30, 1997.<br />
[2] A. Acharya, G. Edjlali, and J. Saltz, “The utility of exploiting idle workstations for parallel<br />
computation,” ACM SIGMETRICS Performance Evaluation Review, vol. 25, no. 1,<br />
pp. 225–234, 1997.<br />
[3] M. Litzkow and M. Livny, “Experiences with the condor distributed batch system,”<br />
in IEEE Workshop on Experimental Distributed Systems, 1990, pp. 97–101.<br />
[4] D. Anderson, J. Cobb, E. Korpela, M. Lebofsky, and D. Werthimer, “SETI@ home: an<br />
experiment in public-resource computing,” Communications of the ACM, vol. 45, no. 11,<br />
pp. 56–61, 2002.<br />
[5] S. Larson, C. Snow, M. Shirts, and V. Pande, “Folding@home and genome@home:<br />
Using distributed computing to tackle previously intractable problems in computational<br />
biology,” Computational Genomics, 2002.<br />
[6] B. Oestereich, Objektorientierte Softwareentwicklung: Analyse und Design mit der UML<br />
2.0. Oldenbourg Wissenschaftsverlag GmbH, München, 2004.<br />
[7] R. Dumke, “Software Engineering: Eine Einführung für Informatiker und Ingenieure:<br />
Systeme, Erfahrungen, Methoden, Tools,” Vieweg-Verlag, Braunschweig, 2001.<br />
[8] H. Balzert, Lehrbuch der Software-Technik. Spektrum Akademischer Verlag, Heidelberg,<br />
2001.<br />
[9] T. S. G. I. Inc., “The chaos report,” Empirische Untersuchungen über Projekte in<br />
den USA, 2001, fetched on the 20th of June 2006. [Online]. Available: http:<br />
//www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf<br />
[10] C. Rupp, Requirements-Engineering und -Management. Hanser Fachbuchverlag, 2004.<br />
[11] A. H. D. Bernd Brügge, Objektorientierte Softwaretechnik mit UML, Entwurfsmustern und<br />
Java. Pearson Education Deutschland GmbH, 2004.<br />
86
Literaturverzeichnis<br />
[12] I. Foster and C. Kesselman, “The grid: Blueprint for a new computing infrastructure,”<br />
Morgan Kaufmann, Tech. Rep., 1999.<br />
[13] I. Foster, C. Kesselman, and S. Tuecke, “The Anatomy of the Grid: Enabling Scalable<br />
Virtual Organizations,” International Journal of High Performance Computing Applications,<br />
vol. 15, no. 3, pp. 200–222, 2001.<br />
[14] I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke, “The physiology of the grid,” IBM<br />
Corporation, Poughkeepie, NY 12601, Tech. Rep., June 2002.<br />
[15] I. Foster, “What is the grid? a three point checklist,” July 2002.<br />
[16] I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke, “A security architecture for<br />
computational grids,” in ACM Conference on Computer and Communications Security,<br />
1998, pp. 83–92, fetched on the 13rd of August 2006. [Online]. Available:<br />
http://citeseer.ist.psu.edu/foster98security.html<br />
[17] M. Humphrey and M. Thompson, “Security implications of typical grid computing<br />
usage scenarios,” in Proceedings of Intl Symposium on High Performance Distributed Computing.<br />
(HPDC), San Francisco, CA., August 2001, pp. 7–9.<br />
[18] C. Catlett, “In search of gigabit applications,” Communications Magazine, IEEE, vol. 30,<br />
no. 4, pp. 42–51, 1992.<br />
[19] T. DeFanti, I. Foster, M. Papka, R. Stevens, and T. Kuhfuss, “Overview of the i-way:<br />
Widearea visual supercomputing,” in International Journal of Supercomputer Applications,<br />
vol. 10, 1996, pp. 123–130.<br />
[20] CERN - European Organization for Nuclear Research, “Gridcafé - a brief<br />
explanation of the grid,” fetched on the 21st of September 2006. [Online]. Available:<br />
http://gridcafe.web.cern.ch/gridcafe<br />
[21] I. Foster, “The Grid: A New Infrastructure for 21st Century Science,” Physics Today,<br />
vol. 55, no. 2, pp. 42–47, 2002.<br />
[22] P. Janson, J. Dayka, A. Nadalin, N. Nagaratnam, F. Siebenlist, V. Welch, I. Foster, and<br />
S. Tuecke, “The security architecture for open grid services,” IBM Corporation, Zurich<br />
Research Lab, Switzerland and Mathematics and Computer Science Division, Argonne<br />
National Laboratory, Argonne, Tech. Rep., July 2002.<br />
[23] I. Foster and C. Kesselman, “Globus: A metacomputing infrastructure toolkit,”<br />
The International Journal of Supercomputer Applications and High Performance Computing,<br />
vol. 11, no. 2, pp. 115–128, Summer 1997, fetched on the 21st of September 2006.<br />
[Online]. Available: http://citeseer.ist.psu.edu/article/foster96globu.html<br />
87
Literaturverzeichnis<br />
[24] I. Foster, “A globus primer,” An Early and Incomplete Draft, August 2005.<br />
[25] M. Litzkow, M. Livny, and M. Mutka, “Condor-a hunter of idle workstations,” Distributed<br />
Computing Systems, 1988., 8th International Conference on, pp. 104–111, 1988.<br />
[26] W. Gentzsch et al., “Sun Grid Engine: Towards Creating a Compute Power Grid,”<br />
Proceedings of the First IEEE/ACM International Symposium on Cluster Computing and the<br />
Grid, 2002.<br />
[27] A. Natrajan, A. Nguyen-Tuong, M. Humphrey, M. Herrick, B. Clarke, and A. Grimshaw,<br />
“The Legion Grid Portal,” Concurrency and Computation: Practice and Experience,<br />
vol. 14, no. 13-15, pp. 1365–1394, 2002.<br />
[28] R. Buyya, D. Abramson, and J. Giddy, “Nimrod/g: An architecture for a resource<br />
management and scheduling system in a global computational grid,” in Proceedings<br />
of the HPC ASIA2000, the 4th International Conference on High Performance Computing in<br />
Asia-Pacific Region, Beijing, China. IEEE Computer Society Press, USA, 2000.<br />
[29] D. Erwin et al., “UNICORE: A Grid computing environment,” Concurrency and Computation:<br />
Practice and Experience, vol. 14, no. 13-15, pp. 1395–1410, 2002.<br />
[30] Globus Documentation Project, “The Globus Toolkit 4 Programmer’s Tutorial,”<br />
fetched on the 21st of September 2006. [Online]. Available: http://gdp.globus.org/<br />
gt4-tutorial<br />
[31] ——, “GT4 Admin Guide,” fetched on the 22nd of September 2006. [Online].<br />
Available: http://www.globus.org/toolkit/docs/4.0/admin/docbook<br />
[32] Leibniz-Rechenzentrum der Wissenschaften, “Installationsanleitung für Globus<br />
Toolkit 4.0.1,” fetched on the 22nd of September 2006. [Online]. Available:<br />
http://www.grid.lrz.de/de/mware/globus/GT4InstallGuide1-0.html<br />
[33] R. Ho, K. Yin, D. Lee, D. Hung, C. Wang, and F. Lau, “InstantGrid: A Framework for<br />
On-Demand Grid Point Construction,” LECTURE NOTES IN COMPUTER SCIENCE,<br />
pp. 911–914, 2004.<br />
[34] Instant-Grid-Projekt, “Vorträge und Publikationen,” fetched on the 21st of September<br />
2006. [Online]. Available: http://instant-grid.de/?q=de/node/80<br />
[35] H.-W. P. Martin Alt, Andreas Hoheisel and S. Gorlatch, “Using High Level Petri-Nets<br />
for Describing and Analysing Hierarchical Grid Workflows,” in Proceedings of the CoreGRID<br />
Integration Workshop, 2005.<br />
88
Literaturverzeichnis<br />
[36] A. Hoheisel, “Grid Workflow Execution Service (GWES),” 2006,<br />
fetched on the 21st of September 2006. [Online]. Available:<br />
http://www.gridwork\begingroup\let\relax\relax\endgroup[Pleaseinsert\<br />
PrerenderUnicode{ïňĆ}intopreamble]ow.org/kwfgrid/gwes/docs<br />
[37] P. C. Group, “Studie zur effizienz von projekten in unternehmen,”<br />
Offizielle Fallstudien, 2004, fetched on the 20th of June<br />
2006. [Online]. Available: http://www.paconsultinggroup.com/NR/rdonlyres/<br />
408B35CB-1C45-49BF-8A71-2F608C1D7196/0/2003_EffizienzStudie_final.pdf<br />
[38] W3C, “XML Path Language (XPath) - Recommendation,” November 1999, fetched<br />
on the 20th of June 2006. [Online]. Available: http://www.w3.org/TR/xpath<br />
[39] ——, “XQuery 1.0: An XML Query Language - Candidate Recommendation,” June<br />
2006, fetched on the 20th of June 2006. [Online]. Available: http://www.w3.org/TR/<br />
xquery/<br />
[40] L. M. Andreas Laux, “XUpdate Working Draft,” September 2000, fetched on the<br />
20th of June 2006. [Online]. Available: http://xmldb-org.sourceforge.net/xupdate/<br />
xupdate-wd.html<br />
[41] IEEE, “Ieee std 830-1998,” IEEE Computer Society Press, USA, Tech. Rep., 1988,<br />
fetched on the 21st of September 2006. [Online]. Available: http://ieeexplore.ieee.<br />
org/xpl/tocresult.jsp?isNumber=15571<br />
[42] M. Meisinger, A. Rausch, M. Deubler, M. Gnatz, U. Hammerschall, I. Küffer, and S. Vogel,<br />
“Das V Modell 200x - ein modulares Vorgehensmodell,” in 11. Workshop der Fachgruppe<br />
WI-VM der Gesellschaft für Informatik e.V. (GI) zur Akzeptanz von Vorgehensmodellen,<br />
R. Kneuper, R. Petrasch, and M. Wiemers, Eds. Shaker Verlag, 2004.<br />
[43] A. Rausch, C. Bartelt, T. Ternité, and M. Kuhrmann, “The V-Modell XT Applied -<br />
Model-Driven and Document-Centric Development,” in 3rd World Congress for Software<br />
Quality, VOLUME III, Online Supplement, no. 3-9809145-3-4. International Software<br />
Quality Institute GmbH, sep 2005, pp. 131 – 138.<br />
[44] U. D. of Defense, “Software Requirements Specification, DI-MCCR-80025A,” Feb<br />
1988.<br />
[45] H. Partsch, Requirements-Engineering systematisch. Springer-Verlag Berlin, 1998.<br />
[46] A. Cockburn, Writing Effective Use Cases. Addison-Wesley, 2001.<br />
[47] C. <strong>Alexander</strong>, S. Ishikawa, M. Silverstein, et al., A pattern language. Oxford Univ. Pr.,<br />
1977.<br />
89
Literaturverzeichnis<br />
[48] R. J. Erich Gamma, Richard Helm and J. Vlissides, Design Patterns - Elements of Reusable<br />
Object-Oriented Software. Addison-Wesley, 2004.<br />
[49] P. Avgeriou and U. Zdun, “Architectural patterns revisited–a pattern language,” 10th<br />
European Conference on Pattern Languages of Programs (EuroPlop 2005), Irsee, Germany,<br />
July, 2005.<br />
[50] Java Community Process, “JSR-154 Servlet Specification,” Mai 2006, fetched on the<br />
20th of June 2006. [Online]. Available: http://jcp.org/aboutJava/communityprocess/<br />
final/jsr154<br />
[51] ——, “JSR-168 Portlet Specification,” October 2003, fetched on the 20th of June 2006.<br />
[Online]. Available: http://jcp.org/aboutJava/communityprocess/final/jsr168<br />
[52] A. Spillner and T. Linz, Basiswissen Softwaretest. dpunkt-Verl., 2004.<br />
[53] W. E. Perry, Software testen. mitp, 2003.<br />
[54] G. Weinberg, The psychology of computer programming. Van Nostrand Reinhold Co.<br />
New York, NY, USA, 1988.<br />
[55] B. Schneiderman, “Software Psychology,” Winthrop, Cambridge, Mass, 1980.<br />
[56] T. Grams, Denkfallen und Programmierfehler. Springer, 1990.<br />
[57] E. Allen, Bug patterns in Java. Apress, 2002.<br />
[58] J. S. F. Nick Rutar, Christian B. Almazan, “A Comparison of Bug Finding Tools for<br />
Java,” University of Maryland, College Park, 2004, fetched on the 20th of June 2006.<br />
[Online]. Available: http://www.cs.umd.edu/~jfoster/papers/issre04.pdf<br />
[59] D. Hovemeyer and W. Pugh, “Finding Bugs Is Easy,” 2003, fetched on the 28th of June<br />
2006. [Online]. Available: http://findbugs.sourceforge.net/docs/oopsla2004.pdf<br />
[60] R. Crew et al., “ASTLOG: A language for examining abstract syntax trees,” Proceedings<br />
of the USENIX Conference on Domain-Specific Languages, pp. 229–242, 1997.<br />
[61] C. Artho, “Finding faults in multi-threaded programs,” 2001, master’s thesis, ETH<br />
Zürich.<br />
[62] J. C. Corbett, M. B. Dwyer, J. Hatcliff, S. Laubach, C. S. Pasareanu, Robby, and<br />
H. Zheng, “Bandera: Extracting finite-state models from java source code,” in In Proceedings<br />
of the 22nd International Conference on Software Engineering, Limerick Ireland,<br />
2000, p. 439–448.<br />
90
Literaturverzeichnis<br />
[63] D. R. Cok1 and J. R. Kiniry2, “Esc/java2: Uniting esc/java and jml. progress<br />
and issues in building and using esc/java2,” Nijmegen Institute for Computing and<br />
Information Science, University of Nijmegen, The Netherlands, 2004, fetched on the 21st<br />
of September 2006. [Online]. Available: http://secure.ucd.ie/products/opensource/<br />
ESCJava2/ESCTools/papers/NIII-R0413.pdf<br />
[64] G. Leavens, A. Baker, and C. Ruby, “JML: A notation for detailed design,” Behavioral<br />
Specifications of Businesses and Systems, pp. 175–188, 1999.<br />
[65] G. T. L. Patrice Chalin, Joe Kiniry and E. Poll, “Beyond assertions: Advanced specification<br />
and verification with jml and esc/java2,” Proceedings of Formal Methods for<br />
Components and Object (FMCO) Amsterdam, The Netherlands, 2006.<br />
[66] G. Myers, Methodisches Testen von Programmen. Oldenbourg, 1989.<br />
[67] H. Sneed and M. Winter, Testen objektorientierter Software. Hanser, 2002.<br />
[68] E. Riedemann, Testmethoden für sequentielle und nebenläufige Software-Systeme. Teubner,<br />
1997.<br />
[69] B. Boehm, “Guidelines for Verifying and Validating Software Requirements and Design<br />
Specifications,” in Proceedings of Euro IFIP, 1979, pp. 711–719.<br />
[70] K. Beck and E. Gamma, “JUnit Cookbook,” fetched on the 21st of September 2006.<br />
[Online]. Available: http://junit.sourceforge.net/doc/cookbook/cookbook.htm<br />
[71] Java Community Process, “JSR-286 Portlet Specification,” September 2006, fetched on<br />
the 20th of September 2006. [Online]. Available: http://jcp.org/en/jsr/detail?id=286<br />
[72] C.-H. A. Hsieh, J. C. Gyllenhaal, and W. mei W. Hwu, “Java bytecode to native code<br />
translation: the caffeine prototype and preliminary results,” in MICRO 29: Proceedings<br />
of the 29th annual ACM/IEEE international symposium on Microarchitecture. Washington,<br />
DC, USA: IEEE Computer Society, 1996, pp. 90–99.<br />
[73] J. Raskin, The Humane Interface. New Directions for Designing Interactive Systems. Addison<br />
Wesley, 2000.<br />
[74] S. Krug, Don’t Make Me Think! A Common Sense Approach to Web Usability. New Riders,<br />
2005.<br />
[75] W. Ruh, F. Maginnis, and W. Brown, Enterprise Application Integration: A Wiley Tech<br />
Brief. John Wiley, 2001.<br />
91
Danksagung<br />
An dieser Stelle möchte ich mich herzlich bei Herrn Prof. Dr. Neumair bedanken, der mir<br />
die Anfertigung der Arbeit an der GWDG ermöglichte. Besonderer Dank gilt Prof. Dr.<br />
Haan und meinem Betreuer Dr. Boehme für ihre fachliche und persönliche Unterstützung<br />
während der letzten sechs Monate. Bedanken möchte ich mich auch bei allen Mitarbeitern<br />
der „Arbeitsgruppe A“ für die wöchentlichen Diskussionsrunden und das angenehme Arbeitsklima.<br />
Nicht zuletzt bedanke ich mich bei meiner Familie und meiner Freundin. Ihr Verständnis<br />
und ihre Unterstützung haben maßgeblich am Erfolg der Arbeit beigetragen.<br />
92