Masterarbeit. Entwurf und Implementierung einer Ressourcen-Datenbank für das Instant-Grid-Projekt der GWDG

Transkript

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

2 Georg-August-Universität Göttingen Zentrum für Informatik Lotzestraße Göttingen Germany Tel. +49 (5 51) Fax +49 (5 51) WWW

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

4

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

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

7 Inhaltsverzeichnis 1. Einleitung Motivation Zielsetzung Methodik Aufbau Grundlagen Grid Instant-Grid Grid-Workflowmanagement Anforderungsanalyse Einleitung Beschreibung der Systemidee und Zielsetzung Identifizierung der Anforderungsbeitragenden Identifizierung der Interessen der Anforderungsbeitragenden Beschreibung der Anforderungen Konkretisierung der Anwendungsfälle Beschreibung der Systemschnittstelle Design Einleitung Anwendungsarchitektur Komponenten Klassenmodell Implementierung und Test Implementierung Statische Testverfahren Dynamische Testverfahren i

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

50 4. Design Paket Übersicht: model GridResource << create >> + GridResource ():GridResource + setclassuri (classtype :URI):void + getclassuri ():URI + setdescription (text :String ):void + getdescription ():String + setname (text :String ):void + getname ():String + getdbname ():String + getdbprefix ():String + seturi (text :URI):void + geturi ():URI + addsimpleproperty (property :GridResourceSimpleProperty ):void + getsimpleproperty (propertyname :String ):GridResourceSimpleProperty + getsimpleproperties ():Collection + addresource (resource :URI):void + getresources ():Collection + tostring ():String + clear ():void + getnode ():Node + setnode (xmlnode :Node ):void product <<creates>> << utility >> << create >> GridResourceFactory ():anonym + getgridresources (document :Document ):List Builder Pattern builder GridResourceSimpleProperty << create >> + GridResourceSimpleProperty ():GridResourceSimpleProperty + getname ():String + setname (string :String ):void + gettype ():String + settype (string :String ):void + getunit ():String + setunit (string :String ):void + getvalue ():String + setvalue (string :String ):void + tostring ():String + clear ():void XmlDB << create >> + XmlDB():XmlDB << create >> + XmlDB(driver :String,uri :URI):XmlDB + query (query :String ):Document + update (query :String ):long + storegridresource (resource :GridResource ):void + createcollection (name :String ):Collection + removecollection (name :String ):void + removefile (name :String ):void + listfiles ():String[] + selectcollection (collectionname :String ):void + updateressources (currentresources :List ):void + formatxml (xml :String ):String + transformxml (inout document :Document,stylesheet :String ):Document + readxml(filename :String ):String Abbildung 4.3.: UML-Paketdiagramm: org.instantgrid.grdb.model Paket: org.instantgrid.grdb.daemon Das Paket org.instantgrid.grdb.daemon (s. Abb. 4.4) beinhaltet den GRDB-Daemon, GRDB-IP-Konnektoren und alle in diesem Zusammenhang notwendigen Schnittstellenbeschreibungen. Die Schnittstelle zur Steuerung des GRDB-Daemons ist in dem Interface GrdbDaemonInterface definiert. Das Aktualisierungsintervall und der Treiber für den Information-Provider kann gesetzt und ausgelesen werden und die Einleitung einer sofortigen Aktualisierung ist möglich. Des Weiteren können über die Schnittstelle direkt Daten aus der Datenbank abgefragt werden. Die Registrierung externer Systeme in den Aktualisierungsprozess wird über das Beobachter-Entwurfsmuster und die Schnittstelle GrdbDaemonListener (/I30/) implementiert. Erhält der GRDB-Daemon neue Daten vom Information-Provider, werden alle eingetragenen Klassen über den Aufruf update() informiert. Zur einfachen Erweiterung des Systems durch neue Konnektoren/Treiber für Information-Provider wird das Adapter-Entwurfsmuster genutzt. Die Treiberklassen müssen lediglich die abstrakte Klasse AbstractGrdb- Connector (/I40/) erweitern, die Funktion update() implementieren und die Daten in das D-GRDL-Format überführen. 42

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

52 4. Design Paket Übersicht: portlet GenericPortlet GrdbPortlet << create >> + DaemonController ():void + doview (request :RenderRequest,response :RenderResponse ):void + init (config :PortletConfig ):void + processaction (request :ActionRequest,response :ActionResponse ):void template Template << create >> + Template ():Template << create >> + Template (templatefile :String ):Template + open (templatefile :String ):void + tostring ():String + set(tagstring :String,replaceString :String ):void Abbildung 4.5.: UML-Paketdiagramm: org.instantgrid.grdb.portlet cd: Paket Übersicht: servlet HttpServlet GrdbServlet + doget (req :HttpServletRequest,res:HttpServletResponse ):void writechart (request :HttpServletRequest,response :HttpServletResponse ):void << utility >> GridResourceChartFactory << create >> GridResourceChartFactory ():GridResourceChartFactory + createfschart (resource :GridResource,outputStream :OutputStream ):void + creatememorychart (resource :GridResource,outputStream :OutputStream ):void + createloadchart (resource :GridResource,outputStream :OutputStream ):void Abbildung 4.6.: UML-Paketdiagramm: org.instantgrid.grdb.servlet 44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

70 A. Verwendete Konfiguration Entwicklungsumgebung GridSphere Portal Entwicklungsumgebung Instant-Grid 0.4nb Entwicklungsumgebung Java SDK 1.5.0_07 java.sun.com Entwicklungsumgebung Linux Kernel Entwicklungsumgebung Tomcat tomcat.apache.org Entwicklungsumgebung Subversion 1.3 subversion.tigris.org Entwicklungsumgebung VMWare Quelltextanalyse Checkstyle 4.2 checkstyle.sf.net Quelltextanalyse FindBugs findbugs.sf.net Quelltextanalyse Lint4J Quelltextanalyse PMD 3.7 pmd.sf.net 62

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

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

73 file:/home/awilner/software3/gridspạp/docs/coverage/_files/overvieẉhtml #2 COVERAGESUMARYFORPACKAGE[orgịnstantgriḍgrdḃconfig] EMACoverageReport(generatedWedSep2710:23:12CEST206) name claș%method,%block,%line,% [all classes] COVERAGEBREAKDOWNBYSOURCEFILE nameclaș%method,%block,%line,% EMMA (C)VladimirRoubtsov [all classes] org.instantgrid.grdb.config 100%(2/2) 100%(5/5) 100%(55/55) 100%(13/13) Config.java 100%(1/1) 100%(3/3) 100%(26/26) 100%(7/7) I18N.java 100%(1/1) 100%(2/2) 100%(29/29) 100%(6/6) [all classes] EMMA (C)VladimirRoubtsov

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