pdf 1.967 kB - Praktische Informatik - Universität Siegen

Universität Siegen
Fachbereich 12 - Elektrotechnik und Informatik
Diplomarbeit
Testportal zur Unterstützung
rechnerbasierter Experimente
Roman Gad
Erstprüfer: Prof. Dr. Udo Kelter, Universität Siegen
Zweitprüfer: Dr. Stefan Berlik, Universität Siegen
Siegen, im Juli 2007

Inhaltsverzeichnis
1 Einleitung und Motivation 2
2 Anforderungen und Randbedingungen 4
3 Entwicklung des Systems 6
3.1 Funktionsprinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Plugin-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Datenbankanbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Verwendete Datenstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.7 ID-Zuweisung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.8 Wichtige Variablen des Hauptsystems . . . . . . . . . . . . . . . . . . . . 21
3.9 Einbindung von Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.10 Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.11 Sprachunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.12 Speicherung von Systeminformationen . . . . . . . . . . . . . . . . . . . . 33
3.13 Aufbau der graphischen Oberfläche . . . . . . . . . . . . . . . . . . . . . . 34
3.14 Behandlung von Ereignissen . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4 Installation und Ausführung des Programms 39
4.1 Installation des Programms . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Starten des Programms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5 Bedienung des Werkzeugs 43
5.1 Programmübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1 Sprache wählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.2 Modus wählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.3 Erststart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.4 Server hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.1 Importieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.2 Eigenschaften verändern . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.3 Kommentar verfassen oder ändern . . . . . . . . . . . . . . . . . . 51
5.2.4 Datei-Freigabe und Archiv . . . . . . . . . . . . . . . . . . . . . . 51
5.2.5 Zur Auswahl der Testläufe hinzufügen . . . . . . . . . . . . . . . . 51
I

Inhaltsverzeichnis
5.2.6 Algorithmus löschen . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 Schemata und DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3.1 Die Schema/DTD-Ansicht . . . . . . . . . . . . . . . . . . . . . . . 52
5.3.2 Neues Schema/DTD . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.3 Importieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.4 Den Namen ändern . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3.5 Änderungen am Dokument oder Kommentar . . . . . . . . . . . . 54
5.3.6 Löschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Eingabe-, Konfigurations- und Stylesheetdokumente . . . . . . . . . . . . 55
5.4.1 Neues Dokument . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.4.2 Dokument importieren . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.4.3 Namen ändern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.4 Eigenschaften ändern . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.5 Inhalt und Kommentar ändern . . . . . . . . . . . . . . . . . . . . 57
5.4.6 Datei-Freigabe und Archiv . . . . . . . . . . . . . . . . . . . . . . 57
5.4.7 Zur Auswahl der Testläufe hinzufügen . . . . . . . . . . . . . . . . 58
5.4.8 Löschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.5 Testläufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5.1 Vorbedingung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5.2 Definition von Testläufen . . . . . . . . . . . . . . . . . . . . . . . 60
5.5.3 Komponenten aus der Run-Tabelle tauschen . . . . . . . . . . . . 60
5.5.4 Testläufe aus der Tabelle entfernen . . . . . . . . . . . . . . . . . . 60
5.5.5 Alle bevorstehenden Resultate anzeigen . . . . . . . . . . . . . . . 60
5.5.6 Resultat-Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5.7 Testläufe starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5.8 Testläufe speichern . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.6 Experimente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.6.1 Einzel-Experimente . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.6.2 Experimentsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.7 Archiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.7.1 Die Archivansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.7.2 Datei zum Arbeitsbereich verschieben oder löschen . . . . . . . . . 69
5.8 Darstellung, Log und Beendigung des Programms . . . . . . . . . . . . . . 69
5.8.1 Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.8.2 Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.8.3 Programm beenden . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6 Erweiterungsmöglichkeiten 70
6.1 Erstellung und Integration eines Plugins . . . . . . . . . . . . . . . . . . . 70
6.2 Integration eines neuen Sprachpakets . . . . . . . . . . . . . . . . . . . . . 73
7 Zusammenfassung und Ausblick 75
8 Anhang 78
II

Abbildungsverzeichnis
3.1 Prinzipelle Funktionsweise des Systems . . . . . . . . . . . . . . . . . . . . 6
3.2 Die Schichtenarchitektur des Systems . . . . . . . . . . . . . . . . . . . . . 7
3.3 Modulare Struktur des Programms . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Vereinfachte Darstellung der Plugineinbindung . . . . . . . . . . . . . . . 24
3.5 Vereinfachte Darstellung vom Ablauf des Datenaustauschs zwischen Scheduler,
Client und Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Der Installationsassistent . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1 Das Startfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Plugins hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Server hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4 Die Table-View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 Der Algorithm-Import-Wizard . . . . . . . . . . . . . . . . . . . . . . . . 48
5.6 Die Detail-View mit selektiertem Reiter “Algorithmus-Details“ . . . . . . 50
5.7 Die Schema/DTD-Ansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.8 Import-Wizard für Eingabe-Dateien . . . . . . . . . . . . . . . . . . . . . 56
5.9 Ein Dokument welches eine DTD einliest . . . . . . . . . . . . . . . . . . 57
5.10 Die Detail-View mit selektiertem Reiter “Testläufe“ und hinzugefügten
Dokumenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.11 Der Resultat-Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.12 Die Details eines Experimentes . . . . . . . . . . . . . . . . . . . . . . . . 64
5.13 Ansicht einer gespeicherten Ausgabe-Datei . . . . . . . . . . . . . . . . . . 65
5.14 Detail-Ansicht einer Experiment-Sequenz . . . . . . . . . . . . . . . . . . 66
5.15 Die Archivansicht mit selektiertem Archivbereich “Algorithmus“ . . . . . 68
6.1 Das Erscheinungsbild des Systems nach dem Einbinden des Testplugins . 72
6.2 Wahl der neu hinzugekommenen Sprache . . . . . . . . . . . . . . . . . . 74
III

Zusammenfassung
Abbildungsverzeichnis
In der heutigen Zeit werden zunehmend automatisierte Anlagen verwendet um den Alltag
zu erleichtern oder ihn angenehmer zu gestalten. Somit werden nicht nur im Umfeld
der Produktionsautomatisierung, sondern auch in allen Bereichen des alltäglichen Lebens
Geräte eingesetzt, die verschiedene Funktionen bieten. Der Entwurf solcher Geräte aber
vor allem die Entwicklung derer Funktionen, erfordert oft den Einsatz ausgeklügelter
Algorithmen. Um die Effizienz solcher Algorithmen zu untersuchen und zu optimieren
bedarf es meist experimenteller Testläufe unter Einsatz verschiedener Eingaben und
Konfigurationen.
In dieser Diplomarbeit soll die Entwicklung und der Gebrauch eines Werkzeugs vorgestellt
werden, welches eine komfortable Experimentierumgebung bereitstellt, die einen
Benutzer bei der Planung, Durchführung und Verwaltung rechnerbasierter Experimente
unterstützt.
1

1 Einleitung und Motivation
Seit den frühen Anfängen der Informatik und der Entwicklung der ersten programmierbaren
Rechner haben es sich viele Unternehmen zur Aufgabe gemacht, Programme zur
Bewältigung diverser Probleme zu erstellen. Solche Programme werden für viele Bereiche
der Industrie und der Unterhaltung benötigt. Sie dienen unter anderem zur Vereinfachung
von diversen Finanzberechnungen, Datenerfassung- und haltung, Maschinenund
Robotersteuerung, Kommunikation, bis hin zur privaten Unterhaltung in Form von
Computerspielen und Multimediaanwendungen. Die Software, die dazu benötigt wird,
erfordert oftmals den Einsatz spezieller Verfahren, sogenannter Algorithmen.
So müssen Verfahren zur Berechnung verschiedener Problemstellungen entwickelt werden.
Zu solchen Problemen gehören beispielsweise Algorithmen zur Sortierung der Daten
einer Datenbank und Verfahren, die den Zugriff auf diese ermöglichen. In anderen Bereichen
benötigt man wiederum Algorithmen, die bestimmte Arithmetische Werte, wie
z.B. Mittelwete und Statistiken, berechnen. Bei der Steuerung von Fertigungsabläufen,
in welche Roboter involviert sind, benötigt man Wegfindungs- und Wegbestimmungsalgorithmen.
Sogar bei der Entwicklung von Computerspielen benötigt man Algorithmen,
wie beispielsweise die erwähnten Wegfindungsalgorithmen aber auch Algorithmen zur
Berechnung der Künstlichen Inteligenz - die heutzutage eine der größten Herausforderungen
der Programmierung darstellen.
Für viele dieser Probleme liegen bereits seit geraumer Zeit Lösungen bzw. Lösungsansätze
vor. Da heutzutage die Menge der von Programmen zu verwaltenden Daten
steigt, die Berechnungszeit jedoch konstant bleiben oder gar reduziert werden muss,
kommt man nicht umher, die vorliegenden Algorithmen im Hinblick auf ihre Laufzeit zu
optimieren oder gar neue, effizientere Algorithmen zu entwickeln.
Um eine Aussage über die Effizienz bestehender Algorithmen treffen zu können oder
diese zu verbessern, ist es notwendig die Algorithmen bezüglich ihrer Laufzeit und ihres
Speicherbedarfs empirisch zu prüfen. Auch bei der Entwicklung neuer Algorithmen
zeigt es sich als unumgänglich diese Werte auf der Basis verschiedener Testeingaben,
die man auch als Benchmarks bezeichnet, empirisch zu erfassen um diese als Grundlage
für Verbesserungen und Optimierungen des Algorithmus zu verwenden. Dabei liefert
ein einzelner Testlauf in der Regel keine Aussage über die Effizienz eines Algorithmus.
Vielmehr erfordert es eine ganze Reihe von Testläufen um über den direkten Vergleich
der ermittelten Resultate die Leistungsfähigkeit eines Algorithmus zu bewerten.
Da komplexere Algorithmen zudem konfigurierbar sein können, mag es durchaus vorkommen,
dass diese nicht nur mit verschiedenen Eingabebenchmarks, sondern zudem
mit einer ganzen Reihe verschiedener Konfigurationen solchen Testläufen unterzogen
werden müssen. Dies führt dazu, dass bei der Optimierung eines einzelnen Algorithmus
womöglich hunderte von Testläufen durchgeführt werden müssen, bevor dieser einen für
2

KAPITEL 1. EINLEITUNG UND MOTIVATION
den Entwickler akzeptablen Effizienzgrad vorweist.
Das Durchführen solcher Testläufe und die Sammlung und Verwaltung der resultierenden
Ergebnisse bezeichnet man auch als Experiment bzw. als Experimentsequenz. Ein
Experiment ist somit durch die Kombination aus Eingabedaten, Algorithmen und ggf.
Konfigurationen und Transformationen definiert.
Um die Entwicklung und die Analyse solcher Algorithmen zu vereinfachen, soll im Rahmen
dieser Diplomarbeit eine komfortable Experimentierumgebung bereitgestellt werden,
welche auf den Namen “Cooperative Algorithm Engineering Workbench“ getauft
wird. Diese soll den Entwickler in erster Linie bei der Planung, Durchführung, Verwaltung
und Auswertung rechnerbasierender Experimente unterstützen.
Die Entwicklung dieses Programms unterteilt sich in zwei Phasen. In der ersten Phase
soll ein Einzelnutzersystem entwickelt und implementiert werden. Dieses soll dem potenziellen
Nutzer einen einfachen Einstieg in die Benutzung dieses Experimentierportals
bieten. Erreicht werden soll dies in erster Linie durch eine möglichst einfache Installation
des Einzelnutzersystems und einen denkbar geringen Einarbeitungsaufwand.
In der zweiten Phase soll die entwickelte Experimentierumgebung zu einem Mehrbenutzersystem
ausgebaut werden. Dieses soll sowohl das kooperative als auch kompetitive
Arbeiten verteilter Nutzer aber auch ganzer Benutzergruppen unterstützen.
Die Entwicklung der zweiten Phase des Systems ist nicht Bestandteil dieser Diplomarbeit,
sodass im weiteren Verlauf nur auf die Entwicklung und Funktionalität des Einzelnutzersystems
eingegangen wird. Als erstes sollen die Anforderungen, die an das Einzelnutzersystem
gestellt werden, ausführlich behandelt werden. Anschließend wird auf
die wichtigsten bzw. interessantesten Aspekte der Entwicklung und Implementierung
eingegangen. Das darauffolgende Kapitel konzentriert sich auf die Bedienung des Experimentiersystems.
Abschließend sollen die Möglichkeiten der Weiterentwicklung und
Erweiterung des Programms vorgestellt werden.
Aufbau der Ausarbeitung
Bei dieser Ausarbeitung wird der Erstellungsprozess eines Softwaresystems dokumentiert.
Hierzu werden Zunächst im Kapitel 2 die einzelnen Anforderungen und aufgestellten
Randbedingungen, welche an das zu entwickelnde System gestellt werden, ausführlich
erläutert. Anschließend widmet sich Kapitel 3 der Ausarbeitung, dem Prozess der
Planung und Entwicklung dieses Systems. Hierbei wird auf alle relevanten Aspekte
der Entwurfs- und Implementierungsphase eingegangen. Das anschließende Kapitel beschreibt
den Installations- und Startvorgang dieses Systems. Die Bedienung aller Funktionen
dieses Programms wird in dem darauffolgendem Kapitel 5 detailliert beschrieben.
Kapitel 6 behandelt die Möglichkeiten der modularen Erweiterung dieses Systems. Das
Abschließende Kapitel 7 soll eine Zusammenfassung der Ausarbeitung und einen Ausblick
auf die möglichen Folgeprojekte, welche der Weiterentwicklung des Systems dienen,
bieten.
3

2 Anforderungen und Randbedingungen
Um das komfortable Experimentieren mit Algorithmen zu ermöglichen, werden an das
zu entwerfende System verschiedene Anforderungen gestellt. Ein wichtiger Bestandteil
des Systems soll eine Verwaltung aller Eingabedaten sein. Um solche Daten zu erfassen
und vor allem persistent zu speichern, wird eine relationale Datenbank eingesetzt. Um
den Installationsaufwand zu minimieren, wird bei dem Einzelnutzersystem auf eine integrierte
Datenbank zurückgegriffen. Hierbei dient die Datenbank als ein dem Benutzer
des Systems exklusiv zur Verfügung gestellter Speicherort. Sie stellt die Dokumentmappe
des Benutzers dar, in der alle relevanten Dokumente - wie z.B. Algorithmen, Eingabedokumente
oder auch Benchmarks, Konfigurationen, Transformationen, Ausgabedaten
aber auch komplette Experimente - aufgenommen und verwaltet werden. Für Dokumente,
die zwar aktuell nicht benötigt werden, bei denen jedoch ein späterer Einsatz nicht
ausgeschlossen werden kann, soll ein Archiv zur Verfügung gestellt werden. Daten, die
ins Archiv ausgelagert wurden, sollen zu jeder Zeit problemlos wieder in den Arbeitsbereich
zurückverschoben werden können.
Ein anderer wichtiger Punkt bei der Entwicklung des Systems ist die Vereinfachung
der Durchführung von Einzelexperimenten aber auch kompletten Experimentsequenzen.
Hierbei soll das Hauptaugenmerk auf eine übersichtliche und nach Möglichkeit intuitiv
bedienbare Benutzeroberfläche gelegt werden. Es soll dem Benutzer die Möglichkeit
geboten werden, einzelne Experimente bzw. komplette Sequenzen von Experimenten erneut
Testläufen zu unterziehen.
Ferner soll der Experimentierkontext automatisch erfasst werden und die Möglichkeit
gegeben sein, diesen gegebenfalls in der Datenbank abzulegen. Der Kontext soll eine
Beschreibung des Rechners darstellen, auf dem ein Experiment ausgeführt wurde. Zu
den zu erfassenden Informationen des Kontextes gehören die Prozessorgeschwindigkeit,
die Hauptspeichergröße und der Name des auf dem Rechner eingesetzten Betriebssystem.
Zudem soll der Kontext den Namen des Rechners, auf dem der Testlauf ausgeführt
wird, sowie die für den Testlauf benötigte Ausführungsdauer erfassen. Die Experimentierresultate,
zu denen der Kontext aber auch die Ausgabe der Algorithmenberechnung
gehören, sollen ebenfalls in der Datenbank verwaltet werden können. Dies bedeutet, dass
die Option gegeben sein soll, diese Daten für eine mögliche Weiterverarbeitung bzw.
Auswertung persistent abspeichern zu können. Bei der Entwicklung der einzelnen Funktionalitäten
des Systems sollen einige Nebenbedingungen berücksichtigt werden. So soll
die Einschränkung bezüglich der Art der möglichen Experimente so gering wie möglich
gehalten werden. Ebenso sollen Ein- und Ausgabedokumente bezüglich ihres Formats
möglichst einschränkungsfrei gehalten werden. Dies bedeutet, dass bei der Festlegung
dieser Formate möglichst auf freie Standards zurückgegriffen werden soll. Bei dem Entwurf
der Struktur des Programms soll unbedingt eine modulare, durch Plugins erweiter-
4

KAPITEL 2. ANFORDERUNGEN UND RANDBEDINGUNGEN
bare Architektur realisiert werden. Dies soll die Weiterentwicklung und die Erweiterung
des Systems unterstützen. Um eine Abhängigkeit bezüglich des verwendeten Betriebssystems
zu vermeiden, soll eine plattformunabhängige Realisierung garantiert werden. Dies
soll durch den Einsatz der objektorientierten Programmiersprache Java T M , die unter
Berücksichtigung einiger Regeln eine Plattformunabhängigkeit bietet, erreicht werden 1 .
Da zur Analyse der Effizienz eines Algorithmus oft eine Vielzahl an Testläufen gestartet
wird, soll die Option geboten werden, die Berechnung einzelner Testläufe auf mehrere
Rechner eines Netzwerk-Clusters auszulagern. Dadurch soll eine parallele Abarbeitung
ganzer Experimentsequenzen garantiert werden, wodurch Wartezeiten, die bei Testläufen
entstehen, verringert werden.
Als eine zusätzliche Basisfunktion soll das System die englische Sprache als Standard
unterstützen, da die Möglichkeit geboten werden soll, das Programm Weltweit einzusetzen.
Zusätzlich soll es möglich sein die Sprachunterstützung modular zu erweitern. Als
eine Erweiterung der Sprachunterstützung soll bereits in der Basisversion Deutsch als
zusätzliche Sprache zur Verfügung stehen. Weitere Sprachen sollen mit möglichst wenig
Aufwand hinzugefügt werden können.
1 Java ist ein eingetragenes Markenzeichen der Firma Sun Microsystems Inc.
5

3 Entwicklung des Systems
3.1 Funktionsprinzip
Da das zu entwickelnde System eine Fülle von Funktionen bieten soll, war es vorab
erforderlich eine grobe Planung des Ablaufs zu erstellen. Diese soll in diesem Kapitel
vorgestellt werden. Hierzu wird zunächst in der folgenden Abbildung der prinzipielle
Ablauf des Systems skizziert und anschließend erläutert.
Abbildung 3.1: Prinzipelle Funktionsweise des Systems
Das System soll bei der Durchführung rechnerbasierter Experimente unterstützen.
Ein Experiment besteht dabei aus einem Testlauf, in den ein Algorithmus und ein oder
mehrere Eingabedokumente - die in diesem Zusammenhang auch als Benchmarks bezeichnet
werden - involviert sind. Sollte ein Algorithmus Konfigurationsdokumente oder
6

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Transformationsdokumente zum Ablauf benötigen, so können diese optional zum Testlauf
hinzugefügt werden. Die so definierten Testläufe werden an einen Server, der die
Berechnung durchführt, übergeben. Der Server gibt als Resultat der Berechnung die
Ausgabe des Algorithmus in der Form eines Ausgabedokuments und den bei der Berechnung
erfassten Kontext an das System zurück. Alle Dokumente die ein Benutzer erstellt
bzw. importiert hat, wie beispielsweise Algorithmen oder Eingabedokumente aber auch
komplette Experimente, können in einer relationalen Datenbank persistent gespeichert
werden, von welcher sie zur jeder Zeit erneut eingelesen werden können.
3.2 Systemarchitektur
Eine der Anforderungen, die an das zu entwickelnde System gestellt werden, ist es eine
Modulare Architektur zu entwerfen, die eine relativ leichte Weiterentwicklung, Erweiterung
und Abänderung des Programms erlaubt. Um dies zu gewährleisten wurde als
Basis für die Struktur des Aufbaus des Systems eine Schichtenarchitektur 1 gewählt. Diese
unterteilt sich, wie in Abbildung 3.2 gezeigt, in die GUI-Schicht, Fachkonzeptschicht,
Netzwerkschicht und die Datenhaltungsschicht.
Abbildung 3.2: Die Schichtenarchitektur des Systems
In der GUI-Schicht wird festgelegt wie der Benutzer auf das System zugreifen und mit
diesem interagieren kann. Sie enthält Klassen, die die graphische Schnittstelle zwischen
dem Benutzer und dem Programmkern realisieren. In dieser Schicht wird zudem festgelegt,
wie einzelne Daten - z.B. Eingabedokumente, Konfigurationen, Algorithmen oder
Experimente - dem Benutzer graphisch präsentiert werden. Es werden der Aufbau und
1 “Grobarchitektur, bei der die Module in einer Folge von Gruppen (Schichten) eingeteilt werden, sodass
jede Schicht nur die Dienste der tieferliegenden Schichten benutzt.“[Kel1]
7

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
die Struktur der graphischen Oberfläche festgelegt. Die Fachkonzeptschicht stellt den
funktionellen Kern des Systems dar, der auch als Fachlogik bezeichnet wird. Diese Schicht
enthält Klassen, die die Verarbeitung der anwendungsspezifischen Funktionen übernehmen.
Sie ist nicht nur für den Start und die Initialisierung des Programms zuständig,
sondern fungiert auch teilweise als zentraler Knoten, an dem der Informationsfluß der
anderen Schichten zusammenläuft.
Die Datenhaltungsschicht beschreibt die Struktur aller im System persistent speicherbarer
Daten. Sie legt auf eindeutige Weise fest, wie solche Daten in einer Datenbank
abzulegen sind. Zudem beschreibt diese Schicht, zusammen mit der Fachkonzeptschicht,
wie auf gespeicherte Daten zugegriffen werden kann. Sie dient als Schnittstelle zwischen
dem Programmkern und der Datenbank selbst.
Die Art, wie das System mit anderen Instanzen dieses Programms zwecks Datenübertragung
kommuniziert, wird in der Netzwerkschicht definiert. Hier wird ebenfalls festgelegt,
welche Funktionen das Programm in der Rolle des Servers, der für die Testläufe
einzelner Clients zur Verfügung steht, bereit stellt.
3.3 Plugin-Struktur
Wie schon erwähnt, soll das System ohne größeren Aufwand erweitert und weiterentwickelt
werden können. Dies wird teils durch die im vorherigen Kapitel aufgezeigte
Schichtenarchitektur angestrebt. Um den Aufwand der Erweiterung von Systemen zu
minimieren, hat sich in der Softwareentwicklung das Konzept des modularen Aufbaus
als eine geeignete Methode erwiesen.
Bei der Entwicklung eines Softwaresystems mit modularem Aufbau wird zunächst ein
Kern implementiert, welches in erster Linie die Grundfunktionalität beinhaltet. Dieser
Kern ist sowohl für das Starten als auch für die Initialisierung des Programms verantwortlich.
Zu seinen wichtigsten Eigenschaften zählt jedoch die Bereitstellung von speziellen
Schnittstellen, die dazu dienen, zusätzliche, kompatible Softwaremodule einzubinden.
Diese sogenannten Plugins sind Teilprogramme, die zur Bewältigung verschiedener Aufgaben
dienen und sind in der Regel ohne die Hauptanwendung, für die sie geschrieben
wurden, nicht funktionsfähig.
Die Idee einer Modularen Struktur soll auch in dem zu entwickelnden System aufgegriffen
werden. Hierzu werden einzelne Teilfunktionen, wie z.B. die Verwltung und Umgang
mit Algorithmen oder das Definieren und Starten von Testläufen, als einzelne Plugins
realisiert. Die Abbildung 3.3 zeigt eine grobe Skizze dieser Architektur.
Hauptsystem
Die wichtigste Komponente der Architektur stellt das Hauptsystem dar, die den Kern
des Programms repräsentiert. Diese wird durch die jeweiligen Plugins, die unabhängig
voneinander agieren, erweitert. Alle Komponenten - das Hauptsystem und die einzelnen
Plugins - sind wiederum nach dem Muster der im vorherigen Kapitel beschriebenen
Schichtenarchitektur aufgebaut.
8

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Abbildung 3.3: Modulare Struktur des Programms
Neben dem Start- und dem Initialisierungsvorgang bietet das Hauptsystem eine Reihe
weiterer Funktionen:
• Main-Frame - Das Hauptsystem stellt die wichtigste Komponente der graphischen
Oberfläche zur Verfügung: das Hauptfenster, auch Main-Frame genannt. Das
Hauptfenster fungiert als eine Art Container in dem alle graphischen Elemente untergebracht
werden könen. Alle graphischen Elemente des Hauptsystems und das
Main-Frame selbst befinden sich im Paket "de.usi.caew.gui".
• Datenhaltung - Da eine Grundfunktionalität des Systems auch ohne Einbindung
von Plugins gegeben sein soll, ist die Datenhaltung und somit die Definition der
Struktur einzelner Daten ein Bestandteil des Hauptsystems. Der eigentliche Zugriff
auf die Datenbank ist jedoch auf das Hauptsystem und die Plugins verteilt. Diese
Aufteilung bietet den Vorteil, dass nachträglich hinzugefügte Plugins individuelle
Datenbankzugriffsmethoden implementieren können.
• ID-Verwaltung - Da die Daten, die persistent gespeichert werden sollen, in einer
Datenbank abgelegt werden, ist es notwendig diesen Daten eindeutige Identifizierer
zuzuweisen. Diese Aufgabe übernimmt ebenfalls das Hauptsystem. Hierzu bietet
9

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
die Klasse "IDWatcher", die im Paket "de.usi.caew.system" liegt, spezielle Methoden,
die die jeweiligen ID’s berechnen und als Resultat zurückgeben.
• Netzwerkkommunikation - Wie bereits erwähnt, soll die Testlaufphase auf
mehrere Rechner verteilt werden können. Um dies zu gewährleisten ist das Programm
so aufgebaut, dass es zum Teil als als Server und zum Teil als Client
betrieben wird. Dabei dient der Server, der als ein eigener Thread im Hintergrund
ausgeführt wird, zum Berechnen von Testläufen. Das eigentliche, vom Nutzer sichtbare
Programm, ist der Client, der die Aufträge an einen bzw. mehrere Server verteilt.
Dies mag im ersten Moment widersprüchlich erscheinen, da womöglich davon
ausgegangen wird, dass das Hauptprogramm der Server sei und die berechnenden
Threads die Clients, denen Aufgaben zugeteilt werden. In der Praxis ist es jedoch
so, dass ein Server seine Dienste anbietet, der Client diese wiederum nutzt. Somit
ist die oben beschriebene Rollenverteilung korrekt.
Die Funktionalität des Servers ist ebenfalls ein Bestandteil des Hauptsystems und
wurde gezielt nicht als Plugin implementiert. Dies macht es möglich das Programm
ohne Einbindung jeglicher Plugins als Server ausführen zu können. Dieser Server
kann anderen Instanzen des Programms seine Dienste anbieten und beispielsweise
zur verteilten Testlaufberechnung eingesetzt werden. Die dazugehörigen Klassen
befinden sich im Paket "de.usi.caew.rmi" des Hauptsystems.
• Sprachmanagement - Das System unterstützt den Einsatz verschiedener Sprachen.
Die Sprachunterstützung kann im späteren Verlauf modular erweitert werden.
Zwei Sprachen - Englisch und Deutsch - sind bereits ein Bestandteil der Basisversion.
Die Funktionen, die zum Zugriff auf Sprachelemente genutzt werden, sind ebenfalls
in das Hauptsystem integriert und lassen sich im Paket "de.usi.caew.lang"
finden.
• Dokumente im Hauptspeicher - Die Dokumente, die zur Ausführung von
Testläufen benötigt werden, befinden sich zum Zeitpunkt des Startens in der Datenbank.
Sollte man auf die Dokumente zugreifen wollen, so müssen diese zunächst
in den Hauptspeicher geladen werden. Um dies zu ermöglichen bietet die Klasse
"MainSys", die sich im Paket "de.usi.caew.system" befindet, verschiedene Variablen
und Arrays, die solche Daten aufnehmen können. Die Klasse "MainSys" ist
eine der wichtigsten Klassen des Hauptsystems, die einen zentralen Knotenpunkt
zwischen den Plugins und dem Hauptsystem selbst darstellt. Alle Plugins haben
die Möglichkeit auf die in ihr zentral abgelegten Daten zuzugreifen. Dies ermöglicht
einen wechselseitigen Datenaustausch zwischen einzelnen Plugins.
• Plugin-Nutzung - Da das Hauptsystem, abgesehen von seiner Funktion als
Server, nur wenig Funktionalität bietet, ist die Einbindung von Plugins eine seiner
Hauptaufgaben. Hierzu befinden sich Funktionen in der Klasse "MainSys", die
diese Aufgabe übernehmen.
10

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Nachfolgend werden die einzelnen Plugins beschrieben, die bereits als Bestandteil des
Basissystems implementiert sind. Je nach Wunsch des Nutzers kann das System mit
relativ geringem Aufwand durch weitere Plugins erweitert werden. Auf diesen Vorgang
wird im Kapitel 6 ausführlich eingegangen.
Algorithm-Plugin
Zum Umfang des Algorithm-Plugins gehören die meisten Funktionen, die eine Möglichkeit
des Zugriffs und der Veränderung von Algoritmendokumenten bieten. Zu diesem
Zweck stellt das Plugin diverse GUI-Elemente zur Verfügung, welche ins Hauptfenster
bzw. Main-Frame des Hauptsystems eingebettet werden. Zu diesen Elementen gehören
unter anderem die Exploreransicht, die die in der Datenbank abgespeicherten Algorithmendokumente
visualisiert, sowie eine detaillierte Ansicht eines einzelnen Algorithmendokuments.
Ferner bietet das Plugin verschiedene Zugriffsmethoden, die zur Interaktion mit der
Datenbank dienen.
Input-Plugin
Das Input-Plugin bietet eine Reihe von Funktionen, mit denen der Zugriff auf Eingabedokumente
realisiert wird. Ähnlich wie das Algorithm-Plugin stellt es verschiedene
GUI-Komponenten, die ebenfalls in das Main-Frame eingebettet werden, zur Verfügung.
Zudem erlaubt es den Zugriff auf die Eingabedokumente der Datenbank.
Config-Plugin
Analog zum Input-Plugin werden vom Config-Plugin verschiedene Funktionen und GUI-
Elemente zum Zugriff auf Konfigurationsdokumente der Datenbank bereitgestellt.
Transform-Plugin
Das Transform-Plugin funktioniert ebenfalls in der selben Weise wie das Input-Plugin.
Unter Verwendung dieses Plugins kann der Zugriff auf Stylesheetdokumente, die in der
Datenbank abgelegt sind, erfolgen.
Experiment-Plugin
Das Experiment-Plugin dient zur Verwaltung von Experimenten und Experimentsequenzen.
Es enthält diverse Funktionen, die das Manipulieren gespeicherter Experimente
bzw. Sequenzen erlauben. Hierzu bietet das Experiment-Plugin verschiedene GUI-
Komponenten, die diese Funktionalität ermöglichen.
Archive-Plugin
Das Archive-Plugin wird dazu verwendet ein Archiv zur Auslagerung nur noch selten
benutzter Daten bzw. Dokumente bereitzustellen. Zur Verwaltung archivierter Daten
11

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
werden dem Nutzer eine graphische Darstellung des Archivs und einige Zugriffsfunktionen
geboten.
Schema-Plugin
Bei der Durchführung von Experimenten, die auf Dokumente im XML-Format zurückgreifen,
ist es oftmals notwendig ihre Struktur zu beschreiben. Hierzu werden sogenannte
DTDs und auch XML-Schemata 2 verwendet. Das Schema-Plugin bietet die Möglichkeit
solche DTD- und Schemadokumente zu verwalten.
Run-Plugin
Das Run-Plugin ermöglicht in erster Linie das Definieren und Ausführen von Testläufen.
Des weiteren bietet dieses Plugin die Option erfolgreich beendete Testläufe als Experimente
aber auch Mengen solcher Testläufe als Experimentsequenzen in der Datenbank
abzuspeichern. Wie bereits angesprochen basiert die Berechnung von Testläufen auf einer
Client-Server-Architektur. Die Definition und Funktionalität des Servers ist ein Bestandteil
des Hauptsystems. Im Run-Plugin hingegen wird der Aufbau des Clients definiert.
Dieses Plugin enthält die relevanten Klassen, welche Methoden zur Kommunikation mit
dem Server bieten.
3.4 Datenbankanbindung
Dieses Programm ermöglicht die rechnerunterstützte Experimentdurchführung an Algorithmen.
Um dies gewährleisten zu können, verwaltet das System eine ganze Menge
an Dokumenten, die zur Ausführung bzw. Auswertung von Algorithmen erforderlich
sind. Solche vom Benutzer des Systems gesammelten bzw. erstellten Dokumente müssen
effizient und dauerhaft gespeichert werden können. Diese Eigenschaften bieten unter
anderem relationale Datenbanksysteme. Die Installation solcher Datenbanksysteme ist
jedoch oft mit einem gewissen Aufwand verbunden. Dies widerspricht der Anforderung
einer möglichst einfachen Installation, die an das System gestellt ist. Ein solcher Mehraufwand
könnte womöglich einen potenziellen Nutzer bereits beim Installationsvorgang
demotivieren das System zu nutzen. Der Einsatz einer Datenbank, wie beispielsweise
“MySQL“, ist eher der Mehrbenutzerversion des Programms vorbehalten, deren Implementierung
nicht zum Umfang dieser Diplomarbeit gehört. Dennoch müssen die besagten
Dokumente abgespeichert und verwaltet werden können. So entstand bei der
Planung die Idee - alternativ zu Datenbanksystemen - solche Dokumente direkt auf
dem Datenträger als Dateien im XML-Format abzuspeichern. Diese Art der persistenten
Datenhaltung wäre jedoch mit einem relativ großen Aufwand bei einem gezielten
Zugriff auf die gespeicherten Daten verbunden. Somit wurde dieses Vorhaben verworfen
und nach einer Alternative gesucht, welche die Vorteile beider Verfahren - geringer Installationsaufwand
und effizienter Zugriff auf gespeicherte Daten - bietet. Eine Lösung
2 Auf die Beschreibung und Definition von DTDs und XML-Schemata wird im weiteren Verlauf der
Ausarbeitung näher eingegangen.
12

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
dieses Problems boten die sogenannten “leichtgewichtigen Datenbanken“, die auch als
“integrierbare Datenbanken“ bekannt sind. Diese haben den Vorteil, dass der Aufwand
einer Installation komplett entfällt. Solche Datenbanksysteme werden direkt bei der Implementierung
in das zu entwickelnde System integriert und mit dem fertigen Programm
ausgeliefert. Dies wird aufgrund ihrer relativ geringen Größe, die in der Regel 4MB nicht
überschreitet, ermöglicht. In diesem System wird die Derby-Datenbank eingesetzt, die
ein Projekt der Apache Software Foundation ist und als freie Software von deren Website
bezogen werden kann. Diese Software bietet zudem den Vorteil, dass sie komplett
in der Programmiersprache Java implementiert ist und damit eine Betriebssystemübergreifende
Kompatibilität garantiert. Dadurch ist diese Datenbank relativ leicht in das
zu entwickelnde Projekt integrierbar.
Geschichtliches
Die Derby-Datenbank wurde ursprünglich unter dem Namen “JBMS“ von der Firma
Cloudscape Inc entwickelt und 1997 veröffentlicht. Im Laufe der Zeit wurde das Produkt
von “JBMS“ in “Cloudscape“ umbenannt. 1999 kaufte die Firma Informix Software Inc.
die Rechte an der Weiterentwicklung auf, die diese im Jahr 2001 an den IBM-Konzern
weitergab. IBM übergab 2004 die Cludscape-Software der Apache Software Foundation,
die die Datenbank unter dem Namen Derby als Open Source Projekt anbietet. Seit 2006
ist die Derby-Datenbank unter dem neuen Namen “Java DB“ ein fester Bestandteil des
Sun JDK 6(Java Development Kit).
Integration ins System
Die Derby Datenbank kann in zwei verschiedenen Modi betrieben werden; zum einen als
Netzwerkserver und zum anderen als eingebettetes Datenbanksystem. Im Netzwerkserver-
Modus funktioniert Derby ähnlich wie beispielsweise MySQL. Dabei “horcht“ Derby über
TCP/IP 3 an einem Netzwerkport, der standardmäßig auf den Wert 1527 eingestellt ist,
auf eingehende Verbindungen. Über diesen Port können unterschiedliche Clients auf die
Datenbank zugreifen. Der Betrieb der Datenbank in diesem Modus bringt jedoch ähnliche
Nachteile wie der Einsatz anderer Netzwerkserver-Datenbanken mit sich - eine relativ
aufwendige Installation der Datenbanksoftware und die Konfiguration des Betriebssystems.
Im zweiten Modus, in dem Derby als eingebettete Datenbank genutzt wird, entfallen
diese Nachteile. Es ist lediglich vom Programmierer darauf zu achten, dass die zu
Derby zugehörigen Bibliotheken vor der Ausführung des Programms in den Klassenpfad
hinzugefügt werden. Die Datenbankinstanz wird automatisch beim Start des entworfenen
Systems aktiviert. Der Zugriff auf die Datenbank kann beispielsweise mittels der
JDBC-Funktionalität von Java erfolgen. Hierzu muss zuerst ein JDBC-Treiber, welcher
mit dem Derby-Paket mitgeliefert wird, geladen werden. Da hier die Funktionalität der
integrierten Datenbank genutzt wird, muss der Treiber "EmbeddedDriver" aus dem Pa-
3 Transmission Control Protocol - meist verwendetes Protokoll für zuverlässige Übertragung von Da-
tenströmen
13

ket "org.apache.derby.jdbc" verwendet weden.
Somit ergäbe sich der folgende Aufruf:
KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
Connection con = DriverManager.getConnection
("jdbc:derby:MyDatabase;create=true");
Mit dieser Codesequenz wurde der JDBC-Treiber geladen. Zudem wurde eine Verbindung
zur Datenbank aufgebaut. Die hier genutzten Funktionen sind in den Klassen der
JDK-Bibliothek im Paket "java.sql" enthalten.
Um die Manipulation der sich in der Datenbank befindlichen Daten zu ermöglichen, ist es
notwendig zunächst ein Anweisungsobjekt vom Typ "Statement" zu erzeugen. Hat man
ein Statement-Objekt beschafft, kann dessen Methode "executeQuery" dazu verwendet
werden, Daten aus der Datenbank zu lesen. Die Methode erwartet einen SQL-String
in Form einer gültigen SELECT-Anweisung und gibt ein Objekt vom Typ ResultSet
zurück, das die Ergebnismenge repräsentiert. Um Datenbankänderungen durchzuführen,
stellt das Anweisungsobjekt die Methode "executeUpdate" zur Verfügung. Auch sie erwartet
als Argument einen String mit einer gültigen SQL-Anweisung. Nachfolgend wird
ein simples Beispiel präsentiert, in dem eine Tabelle in der Datenbank erstellt wird.
Anschließend werden zwei Objekte vom Typ in die Tabelle eingefügt. Ein Objekt vom
Typ "User" ist hierbei die Instanz einer Klasse, welche die beiden Strings "name" und
surname sowie die entsprechenden Zugriffsmethoden beinhaltet. Als letzter Schritt werden
die eingefügten Vornamen ausgelesen und mit Hilfe der Standardausgabe visualisiert.
Hierbei wurde bereits im Vorfeld eine Verbindung, gemäß der oben gezeigten Methode,
aufgebaut. Zu beachten ist, dass die hier verwendeten Methoden eine "SQLException"
werfen können, welche aufgefangen oder weitergereicht werden muss.
Statement stm = conn.createStatement();
stm.executeUpdate("CREATE TABLE users
(id INTEGER, name CHAR(30), surname CHAR(30))");
String tempName = user1.getName();
String tempSurname = user1.getSurname();
stm.executeUpdate("INSERT INTO users VALUES
(1, ’"+ tempName +"’, ’"+ tempSurname +"’)");
String tempName2 = user2.getName();
String tempSurname2 = user2.getSurname();
stm.executeUpdate("INSERT INTO users VALUES
(2, ’"+ tempName2 +"’, ’"+ tempSurname2 +"’)");
ResultSet res1 = stm.executeQuery
("SELECT name FROM users WHERE id=’"+user1.getID()+"’");
ResultSet res2 = stm.executeQuery
("SELECT surname FROM users WHERE id=’"+user2.getID()+"’");
ResultSet res3 = stm.executeQuery
("SELECT name FROM users WHERE id=’"+user1.getID()+"’");
ResultSet res4 = stm.executeQuery
14

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
("SELECT surname FROM users WHERE id=’"+user2.getID()+"’");
User newUser1 = new User();
User newUser2 = new User();
newUser1.setName(res1.getString("name"));
newUser1.setSurname(res3.getString("name"));
newUser2.setName(res2.getString("name"));
newUser2.setSurname(res4.getString("name"));
System.out.println(newUser1.getName());
System.out.println(newUser2.getName());
3.5 Verwendete Datenstrukturen
Ein Benutzer des Systems führt Experimente auf der Basis verschiedener Dokumente.
Zu solchen Dokumenten gehören bespielsweise Algorithmen, Eingabedokumente, Konfigurationsdokumente
etc. Damit das System diese Daten verarbeiten kann, müssen diese
Dokumente Objekten verschiedener Typen zugewiesen werden. Diese Objekte enthalten
alle relevanten Informationen über die zugehörigen Dateien. Im folgenden sollen all diese
Datentypen und ihre Bedeutung kurz beschrieben werden. Sofern nicht anders angegeben,
befinden sich alle Klassen, deren Instanzen durch die genannten Objekte dargestellt
werden, im Paket "de.usi.caew.data". Die Beschreibung der Variablen der einzelnen
Klassen kann im Anhang X nachgeschlagen werden.
Beschreibung der Daten, die in der Datenbank persistent gespeichert werden:
Algorithm Die Klasse "Algorithm" repräsentiert die einzelnen importierten Algorithmen.
InputData Die Klasse "InputData" repräsentiert die Eingabedokumente bzw. Benchmarks.
Config Die Klasse "Config" repräsentiert die Konfigurationsdokumente, die zur Ausführung
einiger Algorithmen benötigt werden.
Transformation Die Klasse "Transformation" repräsentiert die Stylesheetdokumente,
die zur Ausführung mancher Algorithmen benötigt werden.
Context Die Klasse "Context" repräsentiert den Kontext, der während eines Testlaufs
vom System erfasst wurde. "Context"-Objekte werden im Programm von Dokumenten
des Typs "Experiment" referenziert.
OutputData Die Klasse "OutputData" repräsentiert die Ausgabe, die während eines
Testlaufs erstellt wurde. "OutputData"-Objekte werden im Programm ebenfalls von Dokumenten
des Typs "Experiment" referenziert.
15

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Experiment Die Klasse "Experiment" repräsentiert ein bestimmtes Experiment. Hierzu
referenziert ein "Experiment"-Objekt den entsprechenden Algorithmus und die jeweiligen
Eingabe-, Konfigurations- und Stylesheetdokumente, die bei diesem Experiment
eingesetzt wurden. Zudem werden das Ausgabedokument, welches bei dem Testlauf des
Experiments erzeugt wurde, und der vom System erfasste Kontext referenziert.
ExpSequence Die Klasse "ExpSequence" repräsentiert eine Sequenz von Experimenten.
Hierzu referenziert die Klasse einzelne "Experiment"-Objekte.
Schema Die Klasse "Schema" repräsentiert die Schemata- bzw. DTD-Dokumente, die
in manchen Fällen zur Beschreibung von Dokumenten im XML-Format benötigt werden.
ResourcePart Den Dokumenten, die zur Ausführung von Experimenten benötigt werden,
liegt immer eine importierte Datei zugrunde. Bei Algorithmen handelt es sich dabei
meist um eigenständige Programme und bei Eingabedokumenten meist um textuelle
Dateien, die beispielsweise im XML-Format vorliegen. Diese Dateien müssen neben anderen
Informationen auch in der Datenbank abgespeichert werden. Im Programm wird
dies durch das separate Ablegen der einzelnen Dateien, welche in 1MB große Blöcke aufgeteilt
sind, realisiert. Diese Blöcke werden durch die Klasse ResourcePart repräsentiert.
User Die Klasse "User" beschreibt einen Benutzer. Sie enthält Informationen über
seine Zugriffsrechte und referenziert die Klasse "PersonallyData", die seine persönlichen
Daten verwaltet. Diese Klasse wird im Einzelbenutzersystem genau ein Mal genutzt. Dies
geschieht bei dem allerersten Start des Programms zur Erstellung eines Default-Users.
Da es sich hierbei um ein Einzelnutzersystem handelt können keine weiteren Benutzer
angelegt werden. Diese Klasse wurde bereits im Hinblick auf das Mehrbenutzersystem
implementiert.
PersonallyData Die Klasse "PersonallyData" beschreibt die persönlichen Daten eines
Benutzers, beispielsweise den Vor- und Nachnamen und die Adresse aber auch optionale
Daten wie die Telefonnummer oder Homepage des Benutzers. Die Objekte dieser Klasse
werden von der Klasse "User" referenziert.
UserGroup Die Klasse "UserGroup" repräsentiert eine komplette Benutzergruppe. Hierzu
referenziert sie Objekte der Klasse "User", welche die einzelnen Gruppenmitglieder
darstellen. Zudem verwaltet sie die Zugriffsrechte der Gruppe. Diese Klasse wurde ebenfalls
im Hinblick auf das Mehrbenutzersystem implementiert.
IDContainer Die Klasse "IDContainer" verwaltet die Identifizierer, die an alle im
Programm verwendeten, persistent gespeicherten Objekte, vergeben werden müssen.
16

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Beschreibung der Daten, die das System zum Ablauf benötigt:
Run Die Klasse "Run" dient zur Verwaltung von Dokumentsammlungen aber auch zur
Verwaltung ganzer Testlaufdefinitionen.
SysInfo Die Klasse "SysInfo" enthält Informationen über das System, die persistent
auf der Festplatte abgespeichert werden. Diese werden beim Starten des Systems eingelesen.
Result Die Klasse "Result" repäsentiert das Resultat eines Testlaufs. Hierzu verwaltet
es alle vom System erfassten, relevanten Daten.
3.6 Hibernate
Im Abschnitt 3.4 wurde anhand eines Beispiels eine Möglichkeit vorgestellt, auf relationale
Datenbanken mit Hilfe von JDBC und SQL-Anweisungen zuzugreifen. Hierbei muss
der Programmierer das Abbilden von Objekten auf die Tabellen der Datenbank selbst
übernehmen. Eine Alternative hierzu liefert das Open Source Framework “Hibernate“,
welches unter http://www.hibernate.org/ heruntergaladen werden kann. Dieses Framework
übernimmt durch objektrelationales Mapping die Abbildung der Objekte auf
relationale Datenbanken. Dadurch bietet “Hibernate“ Programmierern eine objektorientierte
Sicht auf Tabellen und Beziehungen in relationalen Datenbank-Management-
Systemen. Statt mit SQL-Anweisungen wird mit Objekten operiert. Bei einer Vielzahl
verschiedener zu implementierender Datenbankzugriffe kann hierdurch der Implementierungsaufwand
wesentlich reduziert werden. Wegen der Vorteile, die sich aus der Nutzung
dieses Frameworks ergeben, werden die Datenbankzugriffe im System nicht mittels
JDBC, sondern mit Hilfe von “Hibernate“ realisiert. Zu diesem Zweck müssen die Bibliotheken,
die im “Hibernate“-Paket als Dateien im ".jar"-Format vorliegen, ins Programm
integriert werden. Um dies zu gewährleisten müssen diese zum Klassenpfad des
Programms hinzugefügt werden.
Nachfolgend soll anhand eines einfachen Beispiels die Nutzung von “Hibernate“ in Verbindung
mit Java-Programmen verdeutlicht werden. Hierbei soll der gleiche Vorgang der
im Beispiel des Kapitels 3.4 beschrieben wurde, mit Einsatz von “Hibernate“ umgesetzt
werden. Hierzu wird ebenfalls auf die beiden Objekte "user1" und "user2" des Typs
"User" des im Kapitel 3.4 aufgeführten Beispiels zurückgegriffen.
Einsatz von Hibernate
Zu Anfang sollte erwähnt werden, dass alle Objekte des Programms, die mittels der
“Hibernate“-Funktionalität persistent in der Datenbank abgespeichert werden sollen,
der POJO-Architektur entsprechen müssen. POJO is ein Akronym für “Plain Old Java
Object“. Bei solchen Objekten muss zu jeder Variable die sie beinhalten eine “get“- und
eine “set“- Methode vorhanden sein.
17

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
“Hibernate“ kann mit vielen verschiedenen Datenbanken betrieben werden. Die Anpassung
erfolgt in der SessionFactory-Konfigurationsdatei "hibernate.cfg.xml", die bei
dem vorgestellten Beispiel wie folgt aussieht:
org.apache.derby.jdbc.EmbeddedDriver
jdbc:derby:derbyDB/db; create=true
username
password
org.hibernate.dialect.HSQLDialect
false
org.hibernate.transaction.JDBCTransactionFactory
org.hibernate.cache.HashtableCacheProvider
create
Alle Objekte, die mit Hilfe von “Hibernate“ persistent in der Datenbank gespeichert werden
sollen, benötigen eine Mapping-XML-Datei. Diese sollte die Endung ".hbm.xml" haben
und zur besseren Übersichtlichkeit den Namen der Klasse besitzen. Bei dem Beispiel
der "User"-Klasse wäre es der Name "User.hbm.xml". Die relativen Pfade zu solchen
Dateien müssen in den Tags " der SessionFactory-Konfigurationsdatei angegeben
werden. Für die User-Klasse würde die Mapping-XML-Datei wie folgt aussehen:
18

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Die bei dem zu entwickelnden System verwendeten Konfigurations- und Mapping-Dateien
können im Anhang B nachgeschlagen werden.
Die SessionFactory-Konfigurationsdatei und die Mapping-XML-Dateien werden - für den
Datenbankzugriff mit Hilfe von “Hibernate“ - einmalig angelegt. Um nun aus dem Programm
auf die Datenbank zugreifen zu können, benötigt man ein Objekt, welches die
Instanz der "SessionFactory"-Klasse aus dem Paket "org.hibernate" ist. Dieses Objekt
wird zum Laden der SessionFactory-Konfigurationsdatei und der Mapping-XML-
Dateien verwendet. Es ist üblich, pro Datenbank jeweils nur ein solches Objekt zu erzeugen.
Für den eigentlichen Zugriff auf die Datenbank wird ein Objekt der Klasse
"Session" desselben Pakets benötigt. Dieses Objekt stellt das Bindeglied zwischen der
Applikation und den “Hibernate“-Diensten dar, indem es Methoden für Insert-, Update-,
Delete- und Query-Operationen bereitstellt. Für jeden Datenbankzugriff wird jeweils ein
"Transaction"-Objekt benötigt, dessen Klasse sich ebenfalls im Paket "org.hibernate"
befindet. Die Verwendung dieser Objekte soll nun anhand eines Quellcodeausschnittes
gezeigt werden.
SessionFactury sessFact = new Configuration().
configure().buildSessionFactory();
Session sess = sessFact.openSession()
Transaction trx = sess.beginTransaction();
sess.save(user1);
trx.commit();
trx = sess.beginTransaction();
sess.save(user2);
trx.commit();
trx = sess.beginTransaction();
User newUser1 = (User) sess.load(User.class, user1.getID());
trx.commit();
trx = sess.beginTransaction();
User newUser2 = (User) sess.load(User.class, user2.getID());
trx.commit();
System.out.println(newUser1.getName());
System.out.println(newUser2.getName());
Zudem ist es möglich, mit dem folgenden Befehl, eine Menge von Objekten als Resultat
einer Datenbankabfrage zu erhalten:
java.util.List moreUsers =
sess.createQuery("from Users where NAME=’Michael’").list();
19

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Auf den ersten Blick mag es vorkommen, dass die Nutzung von “Hibernate“ aufwendiger
als der Datenbankzugriff mittels JDBC erscheint. Dies liegt an der Erstellung
der SessionFactory-Konfigurationsdatei und der Mapping-XML-Dateien, was auf einen
Mehraufwand für den Benutzer deutet. Diese müssen jedoch nur einmal erstellt werden,
die Einbindung dieser Dateien funktioniert dann automatisch. Vergleicht man hingegen
die beiden Codesequenzen, erkennt man, dass durch den Einsatz von “Hibernate“ die
Implementierung kompakter und intuitiver gestaltet wird. Dies wird dadurch erreicht,
dass das Mapping der Objekte - wie schon erwähnt - von “Hibernate“ übernommen wird
und nicht mehr zu den Aufgaben des Programmierers gehört. Zudem müssen Tabellen
nicht explizit erstellt werden, diese Aufgabe wird beim Erzeugen des "SessionFactory"-
Objektes ebenfalls automatisch von “Hibernate“ übernommen. Vergleicht man nun beide
Verfahren, kommt man zu der Erkenntnis, dass sich JDBC eher für Applikationen mit
wenigen zu implementierenden Datenbankzugriffen eignet. Ist eine Implementierung vieler
verschiedener Datenbankzugriffe erforderlich, so sollte der Einsatz von “Hibernate“
in Betracht gezogen werden.
Eine ausführliche Beschreibung der Funktionsweise von “Hibernate“ kann im [BaKi05]
nachgeschlagen werden.
3.7 ID-Zuweisung
Daten und Objekte, die in einer relationalen Datenbank abgelegt werden, benötigen zur
deren Unterscheidung eindeutige Identifizierer, sogenannte IDs. Das bei der Entwicklung
des Systems verwendete “Hibernate“-Framework bietet die Möglichkeit solche IDs automatisch
erstellen zu lassen. Auf diese Funktion wurde bei der Implementierung jedoch
bewusst verzichtet. Aus Gründen der Übersichtlichkeit und besserer Kontrolle über die
IDs, übernimmt das System deren Verwaltung. Anhand einiger IDs soll der Aufbau bzw.
die Struktur dieser Identifizierer aufgezeigt werden:
alg01- Algorithmus-ID
inp01- Eingabedokument-ID
cfg01- Konfigurationsdokument-ID
exp01- Experiment-ID
Die ersten drei Zeichen beschreiben hierbei den Typ des Dokuments, dem diese ID
zugeordnet ist. Die Nummer, die diesen Zeichen folgt, soll die Einduetigkeit der ID
garantieren. Die Klasse "IDWatcher", die im Paket "de.usi.caew.system" aufzufinden
ist, übernimmt die Verwaltung und die Vergabe der IDs. Für die Vergabe einer neuen
ID bietet sie dokumenttypspezifische Zugriffsmethoden, die bei Bedarf vom System aufgerufen
werden. Für eine solche Anfrage wird hierbei die zum Dokumenttyp passende
Methode aufgerufen. Diese lädt die zuletzt verwendete ID aus der Datenbank und inkrementiert
deren Zahlenwert. Die so gewonnene neue ID wird als Resultat der Anfrage
20

zurückgegeben und der Eintrag der Datenbank aktualisiert.
3.8 Wichtige Variablen des Hauptsystems
KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Die Daten und Dokumente, die zum Durchführen von Experimenten benötigt werden,
speichert das System - wie schon erwähnt - in einer Datenbank persistent. Um mit diesen
Dokumenten arbeiten zu können, müssen sie zunächst in den Hauptspeicher geladen
werden. Hierzu ist es notwendig, solche Daten im Programm in entsprechenden Variablen
des jeweiligen Typs abzulegen. Da das System eine modulare Struktur besitzt und
zum größten Teil aus separaten Plugins besteht, die keinen direkten Zugriff aufeinander
haben, bietet es sich an die Implementierung so zu planen, dass solche Variablen
möglichst zentral gehalten werden. Dies bietet den Vorteil des einfachen Austausches
von benötigten Daten zwischen den einzelnen Plugins. So lag es nahe, eine Klasse des
Hauptsystems für den Ort dieser Variablen zu wählen. Die Klasse "MainSys" des Pakets
"de.usi.caew.system" erwies sich als besonders guter Kandidat für die Platzierung
der Variablen, da alle Plugins direkten Zugriff auf diese Klasse besitzen. Die Ursache
dieses direkten Zugriffs liegt in der Art wie das Programm Plugins einbindet und wird
im Abschnitt 3.9 ausführlich beschrieben. Wie bereits erwähnt werden die Daten in die
entsprechenden Variablen geladen, wenn ein Benutzer auf diese zugreift. Programmbedingt
kann der Benutzer zum selben Zeitpunkt nur jeweils ein Dokument des gleichen
Typs bearbeiten. So ergibt sich, dass für jeden Dokumenttyp, der beim Zugriff des Benutzers
aus der Datenbank in den Hauptspeicher geladen wird, jeweils nur eine Variable
zur Verfügung stehen muss.
Um Dokumente für die Definition eines Testlaufs zur Verfügung zu stellen, müssen diese
zunächst zur einer Auswahl, welche dem Benutzer in Form von mehreren Tabellen
präsentiert wird, hinzugefügt werden. Aus diesen Tabellen kann der Benutzer anschließend
die jeweiligen Dokumente wählen, die er zur Definition eines Testlaufs benötigt. Die
Sammlung dieser Daten wird ebenfalls in einer Variable der Klasse MainSys abgelegt.
Die Definition von Testläufen erzeugt wiederum eine Sammlung von Daten. Da hierbei
die Dokumente einzelner Testläufe strikt voneinander getrennt werden müssen, legt das
Programm diese jeweils in verschiedenen Bereichen eines Vectors 4 der Klasse MainSys
ab. Es folgt nun eine tabellarische Auflistung dieser Variablen.
Name Typ Beschreibung
shownAlgorithm Algorithm Enthält das Algorithmendokument, welches aus
der Exploreransicht der Datenbank ausgewählt
wurde.
shownInputData InputData Enthält das Eingabedokument, welches aus der
Exploreransicht der Datenbank ausgewählt wurde.
4 Hierbei handelt es sich um ein Objekt der Klasse “java.util.Vector“
21

Name Typ Beschreibung
KAPITEL 3. ENTWICKLUNG DES SYSTEMS
shownConfiguration Config Enthält das Konfigurationsdokument, welches aus
der Exploreransicht der Datenbank ausgewählt
wurde.
shownTransformation Transformation Enthält das Stylesheetdokument, welches aus der
Exploreransicht der Datenbank ausgewählt wurde.
shownExperiment Experiment Enthält das Experimentdokument, welches aus
der Exploreransicht der Datenbank ausgewählt
wurde.
shownExpSequence ExpSequence Enthält das Experimentsequenzdokument, welches
aus der Exploreransicht der Datenbank ausgewählt
wurde.
shownContext Context Enthält das Contextdokument, welches bei der
Auswahl eines Experimentes automatisch geladen
wurde.
shownOutputData OutputData Enthält das Ausgabedokument, welches bei der
Auswahl eines Experimentes automatisch geladen
wurde.
shownSchema Schema Enthält das Contextdokument, welches in der
DTD-Ansicht des Programms selektiert wurde.
collectedData Run Enthält Daten, die zu den Auswahltabellen für die
Testlaufdefinition hinzugefügt worden sind.
dataToRun Vector Enthält einen Vector mit den Daten aller
Testläufe, die vom Benutzer definiert wurden.
All diese Variablen besitzen geeignete Zugriffsmethoden, die die Plugins nutzen können
um Werte in ihnen abzulegen oder diese aus ihnen auszulesen.
3.9 Einbindung von Plugins
Wie bereits im Abschnitt 3.3 erwähnt, ist der Aufbau des kompletten Systems in das
Hauptsystem und die einzelnen Plugins aufgeteilt. Zu den Hauptaufgaben des Hauptsystems
gehören einerseits seine Funktion als Server für die Testlaufberechnung, andererseits
die Einbindung weiterer Programmblöcke, welche die Funktionalität des Programms
ergänzen bzw. erweitern sollen - den Plugins. Dieses Kapitel soll nun aufzeigen, wie die
im Abschnitt 3.3 vorgestellten Plugins in das System eingebunden werden.
Zunächst soll das Interface "Plugin", welches sich im Paket "de.usi.caew.system"
befindet, vorgestellt werden. Dieses bietet die folgenden zwei Methoden:
public void setMainFrame(de.usi.caew.gui.MFrame mainFrame);
public void setMainSys(de.usi.caew.system.MainSys mainSys);
22

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Es ist zwingend notwendig, dass dieses Interface von der Hauptklasse eines jeden Plugins
implementiert wird. Es bildet die Schnittstelle bzw. die Verbindung zwischen dem
Hauptsystem und den einzubindenden Programmblöcken.
Mit der Methode "setMainFrame(...)" wird der Klasse, die das "Plugin"-Interface
implementiert, eine Referenz auf die Hauptklasse der GUI-Verwaltung übergeben. Diese
GUI-Hauptklasse bietet diverse Methoden, die dazu verwendet werden können die GUI-
Elemente des Plugins in die graphische Benutzeroberfläche zu integrieren. Die Methode
"setMainSys(...)" übergibt dem Plugin wiederum eine Referenz auf die Fachkonzept-
Hauptklasse, welche diesem bestimmte Methoden zur Verfügung stellt, mit denen man
den Ablauf des Programms beeinflussen kann. Ein Plugin, welches nach diesen Regeln
entworfen und implementiert wurde, wird vermutlich eine ganze Reihe neuer Klassen
beinhalten. Diese Klassen müssen in einem eigenen Ordner platziert werden. Der Name
dieses Ordners kann frei gewählt werden. Es muss jedoch darauf geachtet werden, dass
der gewählte Name nicht bereits einem der Unterordner des Verzeichnisses Plugin vergeben
wurde. Beim Platzieren der Plugindateien im neuen Ordner muss unbedingt die
Paketstruktur der Klassen beachtet werden. Der neu erstellte Ordner wird anschließend
im Verzeichnis "Plugin" untergebracht.
Das Hauptsystem besitzt zu diesem Zeitpunkt noch keine Kenntnis über den Ort und
Namen der Klasse, die das "Plugin"-Interface implementiert. Damit es diese Informationen
erhalten kann, werden diese in Form einer XML-Datei bereitgestellt. Die XML-Datei
muss in dem neu erstellten Ordner deponiert werden und den Namen "plugin.xml" erhalten.
Der Aufbau dieser Datei wird durch die folgende DTD definiert:
Hierbei wird mit dem Attribut "Name" der Name angegeben, den der Entwickler diesem
Plugin vergeben hat. Zwar ist die Wahl des zu vergebenen Namen beliebig, dennoch
sollte ein Name gewählt werden, der eine ungefähre Aussage über die Funktion des
Plugins liefert. Das Attribut "Classname" beschreibt den Namen der Klasse, die das
"Plugin"-Interface implementiert und somit die Hauptklasse des Plugins darstellt. Sollte
sich die Klasse in einer Paketstruktur befinden, so muss dies entsprechend angegeben
werden. Für eine Klasse mit dem Namen "MyPlugin", welche sich beispielsweise im
Paket "myPackage" befindet, würde die Angabe des "Classname"-Attributes wie folgt
aussehen:
Classname=’mypackage.MyClass’
23

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Beim Programmstart überprüft das System alle sich im Ordner "plugin" befindlichen
Pluginverzeichnisse. Dabei liest es die jeweiligen "plugin.xml"-Dateien ein und
übernimmt die darin enthaltenen Pluginnamen in eine Tabelle. Diese Tabelle beinhaltet
die Namen aller verfügbaren Plugins und die Information, ob diese auch benutzt werden
sollen. Sie wird vom System auf dem Datenträger gespeichert und bei jedem Starten
des Programms erneut eingelesen. Ist der Zustand eines Plugins auf “nicht anwenden“
gesetzt, so ignoriert das System dieses beim Einlesevorgang. Ein neu erstelltes Plugin
wird dabei immer zunächst mit “nicht anwenden“ markiert. Ein Benutzer mit Administratorrechten
hat die Möglichkeit die Tabelleneinträge jederzeit zu modifizieren. Wird
der Zustand eines Plugins in der Tabelle auf “anwenden“ gesetzt, so wird bei einem
Neustart die Funktionalität des Plugins vom System übernommen.
Um ein Plugin einzulesen übernimmt das System zunächst den Klassennamen, den es
aus der "plugin.xml"-Datei des jeweiligen Plugins bezieht. Diese Klasse wird mittels
eines "URLClassLoader"-Objektes geladen und in einer Variable des Typs "Class" gespeichert.
Da davon ausgegangen werden kann, dass diese Klasse das Interface "Plugin"
implementiert, wandelt das System das Objekt der geladenen Klasse in ein "Plugin"-
Objekt um. Anschließend werden die oben erwähnten Methoden - "setMainFrame(...)"
und "setMainSys(...)" - des Plugins ausgeführt, wobei die Referenzen auf die Objekte
der GUI- und der Fachkonzepthauptklasse übergeben werden. Das Plugin kann diese
Referenzen nun zur Integration seiner Funktionalität in das System nutzen. Abbildung
3.4 soll die Einbindung von Plugins in das System verdeutlichen.
Abbildung 3.4: Vereinfachte Darstellung der Plugineinbindung
24

3.10 Datenaustausch
KAPITEL 3. ENTWICKLUNG DES SYSTEMS
In vorherigen Kapiteln wurde bereits erwähnt, dass die Hauptaufgabe des Systems die
Durchführung von algorithmenbasierenden Experimenten und die Verwaltung derer Resultate
zum Zwecke der Optimierung von Algorithmen ist. Es wurde zudem auch schon
darauf eingegangen, dass eine Verbesserung bzw. Optimierung eines Algorithmus in der
Regel eine Vielzahl von Testläufen mit verschiedenen Benchmarks und Konfigurationen
benötigt. Die Anzahl dieser Testläufe bis hin zu einer möglichst optimalen Implementierung
solcher Algorithmen bzw. der Ermittlung zufriedenstellender Einstellungen der
Konfigurationen steigt dabei oft mit der Komplexität dieser Algorithmen. Das Programm
soll deswegen den Benutzer nicht nur bei der Verwaltung und Ausführung der Experimente
unterstützen, sondern ihm die Möglichkeit bieten, die benötigte Zeit zur Ausführung
der erforderlichen Testläufe zu minimieren. 5 Dies soll dadurch erreicht werden, dass mehrere
Testläufe gleichzeitig auf mehreren Rechnern ausgeführt werden können, welche die
Resultate an das System senden. In diesem Kapitel soll nun diese Funktionalität detailliert
erklärt werden. Zunächst sei erwähnt, dass der Austausch von Daten zwischen den
einzelnen Rechnern auf der “Remote Method Invocation“-Funktionalität, die auch unter
dem Akronym RMI bekannt ist, basiert. Zum besseren Verständnis des netzwerkbasierten
Datenaustauschs des Systems soll zunächst die RMI-Funktionalität des JDK 5 grob
beschrieben werden.
RMI - Remote Method Invocation
Bei der Entwicklung objektorientierter Java-Programme ist bekannt, dass man innerhalb
eines Programms, welches in einer Java-Virtual-Machine (JVM) abläuft, die Methoden
verschiedener Klassen aufrufen kann. Dafür benötigt man lediglich ein Objekt, das eine
Instanz dieser Klasse darstellt. RMI bietet einen ähnlichen Zugriff auf Methoden verschiedener
Klassen, jedoch über die Grenzen der JVM und sogar über Rechnergrenzen
hinaus. Hierzu müssen ein Paar zusätzliche Vorbedingungen erfüllt werden. Eine Klasse,
die eine oder mehrere remote ausführbarer Methoden zur Verfügung stellt, wird als
Server-Klasse bezeichnet, die Instanzen dieser Klasse werden Server-Objekte genannt.
Es ist zwingend notwendig, dass eine sogenannte Remote-Schnittstelle bereitgestellt
wird, welche von der Server-Klasse implementiert wird. Diese Schnittstelle beschreibt
die Methoden, die netzwerkweit ausgeführt werden können. Die Protokolle wie beispielsweise
TCP/IP, die zur Datenübertragung über das Netzwerk benötigt werden, erstellt
der RMICompiler (rmic). Zu diesem Zweck muss die Server-Klasse mit rmic compiliert
werden, worauf automatisch eine so genannte Stub-Klasse erzeugt wird, die diese Kommunikationsprotokolle
einbindet. Um Programme über das Netzwerk miteinander mittels
RMI kommunizieren lassen zu können, ist es notwendig,dass ein zusätzliches Programm
im Hintergrund ausgeführt wird - die RMI-Registry. Die RMI-Registry könnte man auch
als Knotenpunkt bei der Kommunikation zwischen Server und Client bezeichnen. Das
Programm hat die Aufgabe, auf die Anfragen von angemeldeten Clients, die über einen
5 Mit “minimieren“ ist hier eine Verkürzung der Zeit gemeint. Es ist nicht garantiert, dass durch die
Verwendung dieses Systems wirklich eine minimale Zeit zur Durchführung der Testläufe erreicht wird.
25

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
vordefinierten Netzwerk-Port ankommen, zu warten und diese dann an angemeldete Server
weiterzuleiten. Genauso funktioniert es in die entgegengesetzte Richtung: die vom
Server berechneten Resultate werden von der RMI-Registry weiter an die Clients geleitet.
Die RMI-Registry liegt dem JDK bei und kann von dort aus gestartet werden. Es
ist jedoch notwendig diesem Zusatzprogramm mitzuteilen, in welchem Ordner die mit
Hilfe von rmic erstellten Stub-Klassen aufzufinden sind.
Ein Aufruf von RMI-Registry könnte unter Linux beispielsweise folgendermassen aussehen:
rmiregistry -J-Djava.class.path=’myProject/myStubClasses/’
Bei der Implementierung der Server-Klasse ist es wichtig, dass diese entweder von der
Klasse "UnicastRemoteObject", welche sich im Paket "java.rmi.server" des JDK
befindet, abgeleitet ist oder sie beim initialisieren die statische Methode
"exportObject(java.rmi.Remote)" der Klasse "UnicastRemoteObject" mit sich selbst
als Argument aufruft. Die so erstellte Server-Klasse muss sich als nächstes bei der RMI-
Registry anmelden. Dies geschieht über den Aufruf der Methode "rebind" der Klasse
"Naming", welche sich im Paket "java.rmi" des JDK befindet. Als erster Parameter ist
bei dieser Methode die URL des Servers anzugeben. Die als String übergebene URL hat
die folgende Form: "rmi://Hostname/Servicename". Dabei beschreibt "rmi://" das
zu verwendende Protokoll, "Hostname" den Namen des Servers und "ServiceName" den
Namen der Verbindung über welchen potentielle Clients die RMI-Registry kontaktieren
können. Als zweiter Parameter wird der "rebind"-Methode die Server-Klasse selbst
übergeben. Ein Aufruf dieser Methode könnte beispielsweise folgendermaßen aussehen:
Naming.rebind("rmi://MyServer.MyIdentification", this);
Bei der Implementierung einer Client-Klasse ist darauf zu achten, dass sich diese ebenfalls
bei der RMI-Registry anmeldet, jedoch mit der "lookup"-Methode der Klasse "Naming".
Dieser Methode muss lediglich die URL des Servers in der vorhin beschriebenen Form
übergeben werden. Sie liefert als Rückgabewert ein Objekt vom Typ der Schnittstelle,
welche von der Server-Klasse implementiert wird. Über dieses Objekt kann man in
der gewohnten Art der objektorientierten Programmierung auf die Remote-Methoden
der Server-Klasse zugereifen. Ein Aufruf der "lookup"-Methode und ein anschließender
Aufruf einer Remote-Methode des Servers könnte wie folgt aussehen:
ServerInterface server =
(ServerInterface)Naming.lookup("rmi://MyServer.MyIdentification");
String result = server.myRemoteMethod();
26

Netzwerkkommunikation des Systems
KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Das zu entwickelnde System unterteilt sich, zwecks der Verteilung der Testläufe auf verschiedene
Rechner, in einen Client- und einen Server-Part. Der Client ist dabei, aus der
Sicht des Benutzers, das Programm selbst. Der Server wiederum läuft im Hintergrund
als eigenständiger Thread bzw. als eine andere Instanz des Systems auf einem anderen
Rechner. Das System startet das von RMI geforderte Hintergrundprogramm RMI-
Registry automatisch beim Starten. Hierfür wird ein eigenständiger Prozess erweckt,
in welchem das Zusatzprogramm ausgeführt werden kann. Zudem wird beim Start des
Systems die Funktionalität des Servers als eigenständiger Thread gestartet. Die Server-
Klasse "RunServer", welche sich im Paket "de.usi.caew.rmi" des Hauptsystems befindet,
implementiert die speziell hierfür entworfene Schnittstelle "ServerInterface"
des gleichen Pakets. Diese Schnittstelle beschreibt die folgenden Methoden:
public void setExeVec(Vector exeVec) - dient zur Übertragung des Algorithmus-
Programms in Form von einem oder mehreren Byte-Arrays.
public void setInputVec(Vector inputVec) - dient zur Übertragung der eigentlichen
Eingabedateien in Form von einem oder mehreren Byte-Arrays.
public void setConfigVec(Vector configVec) - dient zur Übertragung der eigentlichen
Konfigurationsdateien in Form von einem oder mehreren Byte-Arrays.
public void setTrnfVec(Vector trnfVec) - dient zur Übertragung der eigentlichen Stylesheetdateien
in Form von einem oder mehreren Byte-Arrays.
public void setBuildVec(Vector buildVec) - dient zur Übertragung der vom Algorithmus
benötigten Zusatzbibliotheken in Form von einem oder mehreren Byte-Arrays.
public void setBuildDirVec(Vector buildDirVec) - dient zur Übertragung der vom
Algorithmus benötigten Ordner in Form von einem oder mehreren Byte-Arrays.
public void setConfigDTD(Vector configDTD) - dient zur Übertragung der Schemata
bzw. DTDs, die zur Beschreibung der Eingabedokumente benötigt werden, in Form von
einem oder mehreren Byte-Arrays.
public void setInputDTD(Vector inputDTD) - dient zur Übertragung der Schemata
bzw. DTDs, die zur Beschreibung der Konfigurationsdokumente benötigt werden, in
Form von einem oder mehreren Byte-Arrays.
public void setTrnfDTD(Vector trnfDTD) - dient zur Übertragung der Schemata bzw.
DTDs, die zur Beschreibung der Stylesheetdokumente benötigt werden, in Form von
einem oder mehreren Byte-Arrays.
public Result runAlgorithm(Run run) - dient zum Starten des Testlaufs auf dem Server.
Als Rückgabewert wird ein Objekt vom Typ "de.usi.caew.system.Result" geliefert,
welches die relevanten Informationen zum abgeschlossenen Testlauf beinhaltet.
public String getServerName() - dient zum Erfragen des Servernamens auf dem der
Testlauf durchgeführt werden soll.
public String getOS() - dient zum Erfragen des Betriebssystems des Rechners auf dem
der Server ausgeführt wird.
public boolean isBuisy() - dient zum Erfragen des Bereitschaftszustandes des Servers.
27

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Die Serverklasse ruft beim Initialisiarungsprozess die geforderte statische Methode
"exportObject(java.rmi.Remote)" der Klasse
"java.rmi.server.UnicastRemoteObject" auf. Anschließend meldet sie sich mit dem
nachfolgenden Aufruf bei der RMI-Registry an und steht für die Aufträge potenzieller
Clients zur Verfügung.
Naming.rebind("rmi://"+
InetAddress.getLocalHost().getHostName()+"/CAEWServer", this);
Die Funktionalität des Clients gehört nicht mehr zu der Funktionalität des Hauptsystems,
sondern wird als Plugin mit dem Namen "Run-Plugin" in das System integriert.
Dies bietet den Vorteil, diese Funktionalität relativ einfach verändern, aktualisieren bzw.
ersetzen zu können. Das System aktiviert die Client-Funktion erst nachdem ein Benutzer
einen bzw. eine Reihe von Testläufen definiert hat und den Befehl zur Berechnung dieser
gegeben hat. Die definierten Testläufe befinden sich in einer tabellarisch strukturierten
Anordnung in einem Vector. 6 Wurde nun der Befehl erteilt eine Reihe von Testläufen
zu starten, beschafft das System die vom Benutzer erstellte Liste der Servernamen, die
für Testlaufberechnungen zur Verfügung stehen. Nach einer Verbindungsprüfung wird
als nächstes zu jedem Server, der in der Liste als verfügbar eingetragen ist, ein Client-
Objekt 7 erstellt. Somit ist jedem Client-Objekt genau ein Server zugeteilt mit dem dieser
kommuniziert. Als nächstes werden diese Client-Objekte an ein Scheduler-Objekt
des Typs "runPlugin.de.usi.caew.rmi.ServerScheduler" übergeben, welches unter
anderem die Aufgabe hat, die definierten Testläufe an die einzelnen Clients zu verteilen.
Das Scheduler-Objekt startet anschließend die Ausführung der einzelnen Client-Objekte,
die als eigenständige Threads ausgeführt werden und wartet auf deren Anfragen.
Nachdem ein Client-Objekt als eigener Thread gestartet wurde, fordert es beim Scheduler-
Objekt den nächsten anstehenden Testlauf an.
Um zu vermeiden, dass eine fehlerhafte Zuteilung von Testläufen an die Clients auftritt
- wie beispielsweise das Berechnen der selben Läufe auf mehreren Servern zur gleichen
Zeit oder das mehrmalige Zuteilen des gleichen Testlaufs an den selben Client - besitzen
die definierten Testläufe zusätzliche Informationen. Diese Informationen stehen in Form
einer Integer-Variablen bei jedem Testlauf zur Verfügung und geben den Zustand dieses
Testlaufs an. Dabei haben die Zustände folgende Bedeutungen:
0 - Testlauf bereit zur Vergabe an nächsten Client um die Berechnung zu durchlaufen.
1 - Testlauf wird zur Zeit berechnet.
2 - Testlauf wurde bereits erfolgreich berechnet
Zudem übermittelt jeder Client bei der Anfrage an den Scheduler eine Liste der Testläufe,
6 Objekte der Klasse java.util.Vector bieten eine ähnliche Funktionsweise wie Arrays. Somit ist es
möglich, Werte bzw. Objekte in ihnen abzulegen und auf diese zuzugreifen.
7 Die Client-Objekte sind Instanzen der Klasse “RunClient“, die im Paket “runPlugin.de.usi.caew.rmi“
des Run-Plugins zu finden ist.
28

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
deren Durchführung auf seinem zugeordneten Server bereits versucht worden ist. Aus
diesen Informationen kann der Scheduler bestimmen welcher Testlauf an welches Client-
Objekt weitergeleitet werden kann bzw. wann die Berechnung aller Testläufe abgeschlossen
ist.
Hat ein Client einen Testlauf zugeordnet bekommen, vermerkt er dies als allererstes, indem
er dessen ID zu der Liste der versuchten Testläufe hinzufügt. Als nächstes nimmt er
die Verbindung mit dem ihm zugeordneten Server auf. Dies geschieht durch den Aufruf
der RMI-Methode "lookup". Der Methodenaufruf sieht folgendermaßen aus:
ServerInterface server =
(ServerInterface)Naming.lookup("rmi://"+serverName+"/CAEWServer");
Wurde eine Verbindung erfolgreich aufgebaut, wird als nächstes der Status des Servers
mit der Remote-Methode "server.isBuisy()" abgefragt. Ist dieser mit der Berechnung
eines anderen Testlaufs, welcher ihm als Auftrag durch eine andere Instanz
des Programms erteilt wurde, beschäftigt, wird solange abgewartet bis der Server das
“Ready“-Signal zurückliefert. Ist der Server nicht beschäftigt, wird zunächst der Status
des Testlaufs auf “Testlauf wird berechnet“ gesetzt. Als nächstes wird mit Hilfe der
Remote-Methode "server.getOS()" das Betriebssystem des Rechners, auf dem der Server
ausgeführt wird, abgefragt. Ist das Betriebssystem nicht kompatibel zu den Einstellungen
des Algorithmus des Testlaufs, wird die Verbindung an dieser Stelle abgebrochen
und die Zuweisung des nächsten Testlaufs beim Scheduler angefordert. Ist das Betriebssystem
jedoch kompatibel, beginnt der eigentliche Datenaustausch zwischen Client und
Server.
Der erste Schritt ist hierbei die Übertragung aller relevanter Daten zum Server. Hierfür
ruft der Client die Remote-Methoden des Servers auf, die für die Datenübermittlung
zuständig sind:
server.setExeVec(exeVec);
server.setInputVec(inputVec);
server.setConfigVec(configVec);
server.setTrnfVec(trnfVec);
server.setBuildVec(buildVec);
server.setBuildDirVec(buildDirVec);
server.setInputDTD(inputDTD);
server.setConfigDTD(configDTD);
server.setTrnfDTD(trnfDTD);
Als Argumente werden hierbei Vectoren übergeben, welche die relevanten Daten in Form
von Byte-Arrays beinhalten.
Ist die Datenübertagung abgeschlossen, wird die Remote-Methode "server.run()" gestartet,
die den Server anweist, die Berechnung des Testlaufs zu beginnen. Während
die Berechnung durch den Server andauert, befindet sich der Client im Wartemodus.
Ist der Testlauf nach der benötigten Zeit abgeschlossen, sammelt der Server alle relevanten
Informationen zum Testlauf in Form eines "Result"-Objektes. Dieses Objekt
29

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
bietet die entsprechenden Variablen und Methoden zur Speicherung dieser Werte. Anschließend
wird das "Result"-Objekt als Rückgabewert der vom Client aufgerufenen
"server.run()"-Methode an den Client zurück übertragen.
Ist die Berechnung korrekt abgelaufen, setzt der Client den Status des Testlaufs auf
“Testlauf wurde bereit erfolgreich berechnet“. War die Berechnung jedoch fehlerbehaftet,
so setzt der Client den Status des Testlaufs auf “Testlauf bereit zur neuen Vergabe“.
Als letzter Schritt wird das Result-Objekt an den Scheduler zur weiteren Verarbeitung
übergeben und der nächste Testlauf beim Scheduler angefordert.
Der Ablauf wiederholt sich solange, bis alle Testläufe an alle Clients zur Berechnung
übergeben worden sind und dies mit einer erfolgreichen Berechnung oder einem Fehler
endete.
Die folgende Abbildung zeigt nochmals die wichtigsten Schritte bei der Kommunikation
zwischen Scheduler, Client und Server.
Abbildung 3.5: Vereinfachte Darstellung vom Ablauf des Datenaustauschs zwischen
Scheduler, Client und Server
30

3.11 Sprachunterstützung
KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Eine der Anforderungen, die an das System gestellt worden sind, war die Unterstützung
von mehr als nur einer Sprache, mit der Möglichkeit der modularen Erweiterung der unterstützten
Sprachen. Dies wird mit Hilfe der Java-Internationalization-Funktionalität
gewährleistet. Java-Internationalization ist auch unter dem Akronym “i18n“ bekannt,
welches darauf zurückzuführen ist, dass sich zwischen dem ersten Buchstaben “i“ und
dem letzten Buchstaben “n“ des Wortes “internalization“ genau achtzehn zusätzliche
Buchstaben befinden. “i18n“ bietet die Möglichkeit, bei Textausgaben - beispielsweise
bei einer graphischen Oberfläche - zwischen verschiedenen Sprachen zu wechseln ohne
den Quellcode verändern zu müssen. Mit dieser Funktionalität kann - vorausgesetzt,
dass das Programm entsprechend implementiert worden ist - sogar während des Ablaufs
des Programms die textuelle Sprachausgabe umgeschaltet werden. Um “i18n“ nutzen zu
können, ist es erforderlich für jede verwendete Sprache eine Textdatei zu erstellen, die
die im Programm verwendeten Strings beinhaltet. Diesen Strings müssen zudem Identifizierungsschlüssel
vergeben werden. Diese Schlüssel können beliebige Zeichenketten sein.
Es ist jedoch darauf zu achten, dass jeder Schlüssel exakt nur ein mal in dieser Datei
verwendet wird. Der Aufbau dieser Datei gestaltet sich nach folgendem Muster:
key1=String1
key2=String2
key3=String3
.
.
.
Diese Dateien werden, wie schon erwähnt, für alle gewünschten Sprachen erstellt, wobei
darauf zu achten ist, dass in jeder Version der Datei exakt die gleichen Schlüssel vorkommen
und den Schlüsseln Strings mit gleicher Bedeutung zugewiesen werden. Nach der
Fertigstellung dieser Dateien werden sie in einem vom Programm erreichbaren Ordner
abgespeichert. Dabei müssen die Namen der Dateien nach folgendem Muster vergeben
werden:
Dateiname_SK_LK.properties
Hierbei kann für den Platzhalter Dateiname ein beliebiger Name eingesetzt werden,
dieser muss jedoch bei allen Versionen der Sprachdatei gleich sein. SB steht für den
Sprach-Kennbuchstaben, der beispielsweise für englisch en ist und für deutsch de. LB
hat eine ähnliche Bedeutung - es steht für den Länder-Kennbuchstaben. Für die meisten
Länder entspricht dieser dem SK, wird jedoch in Großbuchstaben geschrieben. Mit dem
LB wird die Möglichkeit geboten, zwischen verschiedenen Sprachdialekten unterscheiden
zu können. So wird beim “englichen Englisch“ der Länder-Kennbuchstabe EN verwendet
und beim “amerikanischen Englisch“ der Länder-Kennbuchstabe US. Die Endung
“.properties“ muss genauso übernommen werden wie in dem Beispiel gezeigt.
31

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Im Programm selbst müssen nun zwei Objekte erzeugt werden. Als erstes ein
"java.util.Locale"-Objekt, das die Informationen über die eingestellte Sprache beinhaltet.
Dieses wird als Resultat des folgenden Aufrufs erstellt:
Locale locale = new Locale(langStr, countryStr);
Dem Konstruktor dieser Klasse werden beim Erstellen des Objekts die beiden Kennbuchstaben
SK und LK einer der erzeugten Sprachdateien übergeben. Diese werden
beispielsweise in dem zu entwickelnden System aus einer XML-Datei eingelesen. Die
richtigen Kennbuchstaben werden mit Hilfe einer Abfragefunktion der graphischen Oberfläche
ermittelt.
Hiernach wird ein Objekt des Typs "java.util.ResourceBundle" mittels des folgenden
Befehls beschafft:
ResourceBundle ressBundle =
ResourceBundle.getBundle(Dateiname,locale);
Um das Objekt zu beschaffen, muss - wie oben gezeigt - die statische Methode der Klasse
"ResourceBundle" aufgerufen werden. Bei diesem Aufruf werden zum einen der durch
den Platzhalter Dateiname dargestellte Dateiname, welcher bei der Namensvergabe der
einzelnen Sprachdateien verwendet wurde, zum anderen das erzeugte "Locale"-Objekt
übergeben. Das "ResourceBundle"-Objekt dient zur Verknüpfung der Kennbuchstaben
und der entsprechenden Textdateien. Das so erstellte "ResourceBundle"-Objekt kann
nun zum Besorgen der gewünschten Zeichenketten verwendet werden. Hierzu wird der
im folgenden Beispiel aufgezeigte Aufruf verwendet:
String text = ressBundle.getString("key1");
Der "getString"-Methode des "ResourceBundle"-Objektes wird hierbei der Schlüssel
einer in der Sprachdatei gespeicherten Zeichenkette als String übergeben.
Zur Unterstützung der “i18n“-Funktionalität befindet sich im Paket "de.usi.caew.lang"
die Klasse "Lang", welche die beschriebenen Aufgaben beim Starten des Systems erledigt.
Sie bietet zudem die statische Funktion
"public static String getString(String key)", die mögliche Anfragen an das
"ResourceBundle"-Objekt und die Ergebnisse an die anfragende Instanzen weiterleitet.
32

3.12 Speicherung von Systeminformationen
KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Bei der Nutzung des Systems werden Daten und Informationen erzeugt, die auf geeignete
Weise persistent gespeichert werden müssen. Wie schon erwähnt, legt das System
Dokumente und Daten, die ein Benutzer erstellt oder importiert bzw. vom System generieren
lassen hat, in einer relationalen Datenbank ab, auf welche mit den Funktionen
des Hibernate-Frameworks zugegriffen werden kann. Neben diesen Daten ergeben sich
bei der Benutzung des Systems jedoch noch andere Informationen, die nicht unbedingt
in einer Datenbak abgelegt werden sollten. Zu diesen Informationen zählen:
• das Flag, welches angibt ob das System im Einzelnutzer- oder Mehrbenutzermodus
betrieben wird
• die Liste aller verfügbaren Plugins; mit der zusätzlichen Information, die angibt,
welche der Plugins für den Betrieb genutzt werden sollen
• die Liste aller Server; mit der zusätzlichen Information, die angibt, welche der
Server für die Berechnung von Testläufen genutzt werden sollen
• zusätzliche Systeminformationen, wie beispielsweise die Liste von definierten Interpretern,
die für den Import von Algorithmen benötigt wird
Da die Entwicklung des Einzelnutzersystems bereits mit dem Gedanken erfolgte, den
Entwurf des Mehrbenutzersystems zu erleichtern und zu unterstützen, lag es nahe, die
aufgezeigten Systeminformationen nicht Global in der Datenbank, sondern eher zentral
auf dem Rechner, auf dem das Programm ausgeführt wird, zu speichern. Für diesen
Zweck wurde die Klasse "SysInfo", die sich im Paket
"de.usi.caew.system" befindet, implementiert. Diese stellt Variablen und Methoden
zur Verfügung um die besagten Informationen in ihr abzuspeichern. Um das Objekt der
Klasse "SysInfo" jedoch persistent zu speichern, wird die Funktionalität der Serialisierung
des JDK genutzt. Hierzu befinden sich in der Klasse "MainSys" des gleichen
Pakets zwei statische Methoden, welche von dem Hauptsystem und allen Plugins jederzeit
aufgerufen werden können um das Objekt vom Datenträger zu laden bzw. um es
abzuspeichern. Der Aufbau der Funktion zum Laden sieht wie folgt aus:
public static SysInfo loadSysInfo()
{
java.io.FileInputStream fi =
new java.io.FileInputStream("SystemData/system.sav");
ObjectInputStream oi = new ObjectInputStream(fi);
SysInfo sysInfo = (SysInfo)oi.readObject();
oi.close();
return sysInfo;
}
33

Die statische Speicherfunktion hat einen ähnlichen Aufbau:
KAPITEL 3. ENTWICKLUNG DES SYSTEMS
public static void saveSysInfo(SysInfo sysInfo)
{
java.io.FileOutputStream fs =
new java.io.FileOutputStream("SystemData/system.sav");
ObjectOutputStream os = new ObjectOutputStream(fs);
os.writeObject(sysInfo);
os.close();
}
Wie man an der Implementierung erkennen kann, befindet sich die abgespeicherte Datei
im Ordner "SystemData" und trägt den Namen "system.sav".
3.13 Aufbau der graphischen Oberfläche
Um dem Benutzer eine möglichst intuitive und leicht bedienbare Benutzung des Programms
zu ermöglichen, wird für die Interaktion zwischen dem System und dem Benutzer
eine graphische Oberfläche vom System bereitgestellt. Die Nutzung von graphischen
Oberflächen, die auch unter dem Akronym “GUI“ bekannt sind, gehört heutzutage zum
Standard bei der Implementierung der meisten Softwarewerkzeuge. Der Hauptgrund
hierfür ist die Tatsache, dass die Bedienung mittels graphischer Oberfläche dem Anwender
eine komfortable Möglichkeit bietet, mit dem System zu interagieren. Systeme
die auf eine GUI-Schnittstelle verzichten, bieten oft als Alternative der Kommunikation
zwischen Anwender und System die Nutzung der angebotenen Funktionen mittels
Kommandozeileneingabe. Dies geschieht mit Hilfe eines speziell dafür bereitgestellten
Terminals, welches meist auch die Funktion der visuellen Ausgabe der Resultate übernimmt.
Diese Art der Interaktion erfordert in der Regel eine relativ lange Phase der
Einarbeitung, da hierbei oft eine ganze Reihe von werkzeugspezifischen textuellen Befehlen
erlernt werden muss, welche für die Bedienung erforderlich sind. Da zudem die
Bedienung bestimmter Funktionen mittels Kommandozeile in der Regel nicht intuitiv
ist, ist diese Art der Interaktion für den Anwender wenig attraktiv. Aus den genannten
Gründen scheint sich der Einsatz solcher Eingabefunktionalität eher für weniger umfangreiche
Softwaresysteme zu eignen. Solche Systeme bieten oft relativ wenig Funktionalität,
weswegen die Entwicklung einer graphischen Oberfläche den Aufwand der Implementierung
des Fachkonzepts deutlich überwiegen würde.
Das im Rahmen dieser Diplomarbeit zu entwickelnde System bietet, mit der in den vorherigen
Abschnitten erwähnten Funktionalität, einen relativ großen Umfang an verschiedenen
vom Benutzer aufrufbaren Funktionen. Dies und die Tatsache, dass die mittels des
Programms errechneten Testlaufresultate dem Benutzer in geeigneter und übersichtlicher
Weise präsentiert werden sollen, macht die Einbindung einer graphischen Oberfläche unverzichtbar.
Bei der Wahl der gebotenen Softwarebibliotheken, welche die Entwichklung von graphischen
Benutzerschnittstellen unterstützen, wurde bei der Implementierung dieses
34

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Systems auf die Graphikbibliothek “Swing“, welche mit dem JDK 5 mitgeliefert wird,
zurückgegriffen. Diese Bibliothek bietet eine ganze Reihe von graphischen Elementen, die
als leichtgewichtige Komponenten bezeichnet werden und bei der GUI-Entwicklung in
das Programm eingebunden werden können. Die Bezeichnung “leichtgewichtige Kompnenten“
beruht auf der Eigenschaft dieser Elemente, nicht mit Hilfe nativer Methoden
des Betriebssystems, sondern von Java selbst gerendert zu werden. Die Vorteile, die
sich daraus ergeben, sind zum einen die Möglichkeit einem Programm auf verschiedenen
Plattformen - unabhängig vom Betriebssystem - gleiches Aussehen zu verleihen
und zum anderen die Option die Optik der Swing-Komponenten zwischen vordefinierten
Look-and-Feels[Sun99] zu wechseln. Mit Look-and-Feel wird das Erscheinungsbild und
Verhalten von Swing-Komponenten bezeichnet, welche durch den Entwickler selbst definiert
werden können. Die “Cooperative Algorithm Engineering Workbench“ nutzt die
dem JDK 5 beiliegenden Look-and-Feels “Metal-Look-and-Feel“, “Motif-Look-amd-Feel“
und “Windows-Look-and-Feel. Das letztgenannte Look-and-Feel ist jedoch aus rechtlichen
Gründen nur bei der Verwendung des Programms unter Windows-Betriebssystemen
auswählbar.
Graphische Oberfläche des Systems
Bei der Entwicklung des Aufbaus der graphischen Oberfläche musste, aufgrund der modularen
Architektur des kompletten Systems, darauf geachtet werden, diese Struktur zu
unterstützen. Dies wird mit Hilfe einer hierbei eingesetzten Container-Architektur sichergestellt.
Diese Architektur bietet als Basis ein graphisches Element, meist ein Fenster
bzw. Frame, das als Container betrachtet werden kann, welcher diverse andere graphische
Elemente in seine innere Struktur aufnehmen kann. Um solche Elemente einbinden
zu können, bietet der Container eine Reihe von geeigneten Funktionen bzw. Methoden.
Durch den Aufruf solcher Methoden wird der Container dazu veranlasst, neue Komponenten
aufzunehmen, deren derzeitige Position zu verändern oder bereits enthaltene
Komponenten zu entfernen. Diese Art der GUI-Programmierung kann sehr gut dazu
eingesetzt werden im nachhinein graphische Elemente einzubinden, die zur Zeit der Erstellung
des Systems noch nicht verfügbar waren und die erst mit der Integration der
Funktionalität eines Plugins dem Programm zur Verfügung gestellt werden.
Bei der Implementierung der “CAEW“ wurde dieses Prinzip aufgegriffen, indem bei
der Entwicklung der GUI-Struktur die benannte Methodik angewandt wurde. Als Container,
der die Basis bildet, fungiert hierbei ein graphisches Fenster, welches eine Instanz
der Klasse "JFrame" darstellt. Diese und andere Klassen, welche die jeweiligen
Swing-Komponenten definieren, befinden sich im Paket "javax.swing" des JDK.
Der Container wird hierbei als Hauptfenster angesehen und ist ein Objekt der Klasse
"usi.caew.gui.MFrame" des Hauptsystems. Das Hauptfenster wird in drei Untersektionen
aufgeteilt, die jeweils verschiedene Funktionsbereiche des Systems visualisieren
sollen. Der Gedanke dabei ist, einen Teil des Fensters zur Anzeige eines Explorers 8
8 Der Begriff Explorer bezeichnet in diesem Zusammenhang einen graphischen Dateimanager, der den
Zugriff auf Dateisysteme bzw. Datenbanken visualisiert.
35

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
für den Zugriff auf die Datenbank bereitzustellen. Der Zweite Teil des Hauptfensters
soll zur detaillierten Ansicht der ausgewählten Dokumente aber auch zur Visualisierung
diverser Arbeitsabläufe dienen. Der dritte und letzte Bereich soll der textuellen Erfassung
der Arbeitsabläufe zur Verfügung gestellt werden. Nach der Initialisierung sieht die
geometrische Anordnung der Bereiche wie folgt aus: Die komplette Hauptfensterdarstellungsfläche
teilt sich zunächst horizontal in zwei Bereiche, wobei die untere Sektion ca.
ein Viertel der Gesamtfläche zugeordnet bekommt. Die textuelle Erfassung von Arbeitsabläufen
wird in diesem Bereich graphisch ausgegeben.
Der obere Bereich teilt sich vertikal in zwei separate Gebiete. Der linke Bereich wird
dabei für die Explorer-Ansicht reserviert, der rechte wird der Detail-Ansicht zugewiesen.
Die Unterteilung in die jeweiligen Bereiche wird mit Hilfe von Objekten der Swing-Klasse
"JSplitPane" realisiert.
Um der Visualisierung der Swing-Elemente der zwei erstgenannten Bereiche eine geeignete
Umgebung zur Verfügung zu stellen, werden in diese Untersektionen virtuelle Areale
eingebunden, welche die Integration von bestimmten graphischen Elementen erlauben.
Diese Areale sind Objekte der Swing-Klasse "JTabbedPane" und bieten die Möglichkeit,
Objekte des Typs "JPanel" als durch Reiter anwählbare Graphikflächen einzubinden.
Ein "JPanel"-Objekt ist wiederum die einfachste Form einer Fläche zur Darstellung aller
graphischen Swing-Elemente. Der untere Bereich, der für die textuelle Erfassung von
Arbeitsabläufen reserviert ist und auch als Log-Bereich bezeichnet wird, bekommt als
Textdarstellungsfläche ein Objekt des Swing-Typs "JTextArea" zugewiesen. Der Log-
Bereich ist als einziger der drei Bereiche nicht dazu geeignet graphische Elemente darzustellen.
Das Hauptfenster stellt jedoch Methoden zur Verfügung, mit denen textuelle
Nachrichten in diesem Bereich angezeigt werden können. Damit ein potentielles Plugin
die Möglichkeit bekommt seine graphischen Elemente einzubinden, bietet das Hauptfenster
die folgenden Funktionen:
• public JTabbedPane getMainView()
• public JTabbedPane getTreeView()
• public void updateLog()
Zudem wird in der Klasse "de.usi.caew.MainSys" die folgende Methode zur Verfügung
gestellt:
• public void updateLog(String text)
Ein Plugin, welches graphische Elemente in der Detaillansicht anzeigen soll, muss zunächst
ein Objekt des Typs "JPanel" erstellen, in dem er seine graphischen Elemente entsprechend
platziert. Durch den Aufruf der Methode "getMainView()" erstellt das Plugin
eine Referenz auf das "JTabbedPane"-Objekt des Hauptfensters. Anschließend ruft es
die von der "JTabbedPane"-Klasse angebotene Methode
"addTab(String tabname, Object jpanel);" auf. Der erste Parameter, der hierbei
übergeben wird, stellt den Namen des Reiters dieser Ansicht dar. Als zweiter Parameter
wird das erstellte "JPanel"-Objekt übergeben. Mit dieser Methode wird das "JPanel"
36

KAPITEL 3. ENTWICKLUNG DES SYSTEMS
mit all seinen enthaltenen Elementen zu der Detaillansicht hinzugefügt und kann über
den Reiter mit dem als String übergebenen Namen angewählt werden.
Der Ablauf des Hinzufügens graphischer Elemente zur Explorer-Ansicht verhält sich
analog, wobei hier die Methode "getTreeView()" des Hauptfensters aufgerufen werden
muss.
Soll durch das Plugin die Ausgabe des Log-Bereichs aktualisiert werden, muss zunächst
die Methode updateLog(String text) der "MainSys"-Klasse aufgerufen werden, welcher
als Parameter die entsprechende auszugebende Nachricht als String übergeben wird.
Diese Nachricht wird durch die "MainSys"-Klasse um eine vorangestellte Zeitangabe
ergänzt und an die bereits vorhandenen Nachrichten angefügt. Anschließen muss der
Aufruf der Methode "updateLog()" des Hauptfensters erfolgen um die Nachrichtenausgabe
zu aktualisieren.
Zu dem Aufgabengebiet des Hauptfensters gehört, neben der beschriebenen Funktion als
Container für graphische Elemente, zusätzlich die visuelle Darstellung eines Hauptmenüs.
Das Hauptenü hat die Aufgabe Funktionen des Systems zu aktivieren, welche durch Optionspunkte
dieses Menüs dargestellt werden. Das Hauptsystem bietet eine Reihe von
Grundfunktionen, die über dieses Menü aufrufbar sind. Es ist zudem möglich Funktionsaufrufe
potentieller Plugins in das Hauptmenü zu integrieren. Hierfür bietet das
Hauptfenster die Methode "public JMenuBar getMenu()". Mit dieser Methode kann
dem Plugin eine Referenz auf das Hauptmenü-Objekt des Hauptfensters beschafft werden.
Mit Hilfe dieses Objekts kann durch den Aufruf seiner Methoden "add(JMenuItem)"
und "add(JMenu)" ein Optionspunkt des Typs "JMenuItem" bzw. ein komplettes Untermenü
des Typs "JMenu" hinzugefügt werden.
Die folgende Abbildung zeigt eine Skizze der hier beschriebenen Abläufe:
37

3.14 Behandlung von Ereignissen
KAPITEL 3. ENTWICKLUNG DES SYSTEMS
Im vorherigen Kapitel wurde gezeigt, wie graphische Elemente in das System integriert
werden. Diese Elemente können beispielsweise graphische Tasten, welche auch als
“Buttons“ bezeichnet werden, Kontrollkästchen, aufklappbare oder erscheinende Menüs,
auch Pull-Down- bzw. Pop-Up-Menüs genannt, Tabellen, Listen und andere Elemente
sein. Diese Elemente haben zunächst noch keine definierte Funktion. Um nun die Elemente
der graphischen Oberfläche mit den Funktionen des Fachkonzepts zu kombinieren,
wird eine geeignete Schnittstelle benötigt. So eine Schnittstelle wird auch als Ereignisbehandlungsschnittstelle
oder als Event-Handler bezeichnet.
In dem zu entwickelnden Programm wird die von Java ab der Version 1.2 angebotene
Ereignisbehandlungsmethodik angewandt.
Prinzip der Ereignisbehandlung des JDK
Zur Unterstützung der Ereignisbehandlung bietet Java eine Bibliothek mit Klassen und
Schnittstellen, welche zu diesem Zweck eingesetzt werden können. Das Prinzip sieht
dabei so aus, dass graphische Elemente mit speziell gekennzeichneten Klassen gekoppelt
werden, die die Ereignisbehandlung übernehmen. Für verschiedene Ereignisse bzw.
Events bietet das JDK wiederum spezielle Schnittstellen, die die geeigneten Behandlungsmethoden
beschreiben. Eine Klasse, welche die Behandlung von diversen Events
übernehmen soll, muss die entsprechende Schnittstelle und somit die von ihr beschriebenen
Behandlungsmethoden in geeigneter Weise implementieren. Diese Klasse kann auch
als Ereignisbehandlungsklasse oder auch Event-Listener bezeichnet werden.
Die Klassen der graphischen Swing-Elemente verfügen alle über bestimmte Methoden,
mit denen sie sich an diese Event-Listener koppeln können. Dabei kann ein einzelnes
Swing-Element durchaus an mehrere Eventhandler gekoppelt sein. Wird nun eine Aktion
vom Nutzer der graphischen Oberfläche gestartet - beispielsweise ein Klick mit der
Maus auf einen Button oder das Verändern der Einträge einer Tabelle - so verschickt
das jeweilige graphische Element die entsprechende Event-Mitteilung an die gekoppelten
Event-Handler. Der Event-Handler entscheidet anhand des Typs der Event-Mitteilung,
welche der zur Verfügung stehenden Methoden ausgeführt werden muss. Diese Methoden
können den internen Ablauf des Systems beeinflussen und bieten somit die Verbindung
der GUI mit dem Fachkonzept.
Einbindung ins System
Das zu entwickelnde System nutzt das genannte Prinzip der Ereignisbehandlung. Hierfür
stehen dem Hauptsystem und allen entwickelten Plugins diese Ereignisbehandlungsklassen
zur Verfügung. Diese implementieren in der Regel die folgenden Ereignisbehandlungsschnittstellen
des JDK, welche sich im Paket "java.awt.event" befinden:
• ActionListener - dient speziell zur Behandlung von Button-Events
• MouseListener - dient zur Behandlung sonstiger Mausaktionen
• ComponentListener - dient zur Behandlung von Komponentenverschiebungen
38

4 Installation und Ausführung des
Programms
Für das Installieren, Starten und Ausführen des Programms wird eine funktionsfähige
Java-Umgebung benötigt. Außerdem ist es notwendig, dass das SDK mindestens in der
Version 5.0 vorliegt. Das neueste Java-Development-Kit kann von der Seite http://www.
java.sun.com/ heruntergeladen werden. Zusätzlich sollte bei Verwendung einer Firewall
der Port 1099 freigegeben werden.
4.1 Installation des Programms
Um die “Cooperative Algorithm Engineering Workbench“ auf einem Rechner zu installieren,
muss zunächst die beigefügte CD ins Laufwerk eingelegt werden. Falls es sich bei
dem verwendeten Betriebssystem um Windows handelt und die “Autostart“-Funktion
aktiviert ist, startet der Insallationsassistent automatisch. Sollte diese Funktion ausgeschaltet
sein bzw. es sich um ein anderes Betriebssystem handeln, muss der Startvorgang
des Installationsassistenten manuell eingeleitet werden. Bei Windows startet man den
Installationsprozess manuell, indem man die Datei “install.bat“ der CD mittels eines
Doppelklicks aktiviert. Bei Linux-Systemen muss zunächst ein Terminal geöffnet werden,
in welches der Befehl, der aus der Textdatei “command.txt“ der beigefügten CD
kopiert werden kann, eingegeben wird. Dieser Befehl sieht wie folgt aus:
cd /media/CAEW
java -cp bin:CAEW_Single/bin: de.usi.caew.installer.Installer
Nach dem Anklicken des “OK“-Buttons des Begrüßungsbildschirms erscheint ein Dialogfenster,
das die Lizenzvereinbarung anzeigt. Möchte man diese Vereinbarung akzeptieren,
muss der Optionspunkt “I agree“ selektiert und mittels eines Klicks auf den
“OK“-Button bestätigt werden. Das Folgefenster ermöglicht es einen Ordner auf dem
Datenträger für die Installation des Programms auszuwählen. Soll hierbei der Standardwert
verändert werden, so drückt man auf den Button “Browse“ und wählt in dem
erscheinenden Dateiexplorer den gewünschten Ordner aus. Zudem bietet dieser Bildschirm
die Möglichkeit den Modus der Installation zu wählen. Wählt man hierbei den
Optionspunkt “Singleuser mode“ so wird im späteren Verlauf das Programm als Einzelnutzersystem
installiert. Andernfalls wird die Mehrbenutzerversion des Programms
auf dem Datenträger eingerichtet. Bei dieser Version des Programms ist die Wahl der
Installation des Mehrbenutzersystems jedoch noch nicht möglich, sie wurde allerdings im
Hinblick auf die Weiterentwicklung in den Assistenten integriert. Wurde die Ordnerwahl
39

KAPITEL 4. INSTALLATION UND AUSFÜHRUNG DES PROGRAMMS
und die Wahl des Installationsmodus mit dem Drücken des “OK“-Buttons abgeschlossen,
erscheint ein Fenster, welches den Benutzer auffordert, die Merkmale des Systems einzugeben.
Durch Anklicken des “OK“-Buttons erscheint ein Bestätigungsfenster, in dem
man den Installationsprozess starten kann. Nach dem Betätigen des Buttons “Install“
wird das Programm in der gewünschten Weise auf dem Datenträger installiert. Nach
Abschluss dieses Vorgangs ist das Programm auf dem Datenträger installiert und der
Installationsassistent kann mittels eines Klicks auf den “Quit“-Button beendet werden.
4.2 Starten des Programms
Abbildung 4.1: Der Installationsassistent
Die Standardmethode das Programm zu starten ist zugleich die einfachste. Hierzu öffnet
man das Fenster des Ordners, in dem das Programm installiert wurde. In diesem
Ordner befinden sich spezielle Dateien, die den Start des Programms ermöglichen. Unter
Windows-Betriebssystemen ist hierbei die Datei “Start.bat“ und unter Linux Systemen
die Datei “Start.sh“ mittels eines Doppelklicks zu aktivieren. Das Programm startet
anschließend automatisch. Zusätzlich gibt es noch zwei alternative Methoden das Programm
zu starten:
• Benutzung des Eclipse-Workspaces
• Manuelles Starten
Eclipse-Workspace
Für das Starten des Programms aus der Eclipse-Umgebung heraus, benötigt man zum
einen das Entwicklungs-Werkzeug Eclipse, das unter http://www.eclipse.org/ heur-
40

KAPITEL 4. INSTALLATION UND AUSFÜHRUNG DES PROGRAMMS
untergeladen werden kann.
Zum anderen benötigt man den kompletten Workspace-Ordner, welcher bei der
Installation erstellt wurde. Da der Instalationsordner alle von Eclipse benötigten Initialisierungsdateien
enthält, dient er zugleich als Workspace-Ordner. Das Workspace von
Eclipse muss auf den kopierten Ordner gesetzt werden.
Es ist darauf zu achten, dass der Compiler, der für dieses Projekt ausgewählt wurde,
mindestens die Version 5.0 hat.
Für den korrekten Ablauf des Programms ist es erforderlich, dem Java-Interpreter die
folgenden zwei Attribute zu übergeben:
• -Xms100m
• -Xmx400m
Diese Attribute bestimmen die Größe des Speichers, der minimal bzw. maximal zugewiesen
wird. Die Klasse, die gestartet werden muss, hat den Namen “Start.class“ und
befindet sich im Standard-Paket.
Manuelles Starten
Das manuelle Starten erfordert das Setzen aller mitgelieferten Hilfsdateien in den Klassenpfad.
Folgende Dateien müssen im Klassenpfad enthalten sein:
• asm.jar
• cglib-2.1.3.jar
• checkstyle-all.jar
• commons-collections-2.1.1.jar
• derby.jar
• derbyclient.jar
• derbyLocale.jar
• derbynet.jar
• derbyrun.jar
• derbytools.jar
• dom4j-1.6.1.jar
• hibernate3.jar
• jta.jar
41

KAPITEL 4. INSTALLATION UND AUSFÜHRUNG DES PROGRAMMS
• log4j-1.2.11.jar
• mysql-connector-java-5.0.4-bin.jar
Diese Dateien befinden sich im Ordner ’lib’“, welcher sich wiederum im Installationsordner
befindet. Außerdem ist es notwendig, die Ordner “bin“, “Language“ und “Plugins“
des Installationsordners zum Klassenpfad hinzuzufügen.
Auch beim manuellen Start ist es erforderlich, für den korrekten Ablauf des Programms,
dem Java-Interpreter die folgenden zwei Attribute zu übergeben:
• -Xms100m
• -Xmx400m
Die Start-Klasse ist ebenfalls unter dem Namen “Start.class“ im Standard-Packet zu
finden.
In einer Konsole wechselt man zum Ordner CAEW-Aktuell und gibt das folgende
Kommando ein:
javaw.exe -cp “./bin;./plugins:./Language:./lib/asm.jar:./lib/cglib-2.1.3.jar:
./lib/checkstyle-all.jar:./lib/commons-collections-2.1.1.jar:./lib/derby.jar:
./lib/derbyclient.jar:./lib/derby-Locale de DE.jar:./lib/derbynet.jar:./lib/derbyrun.jar:
./lib/derbytools.jar:./lib/dom4j-1.6.1.jar:./lib/hibernate3.jar:./lib/jta.jar:
./lib/log4j-1.2.11.jar:./lib/mysql-connector-java-5.0.4-bin.jar“%CLASSPATH%
-Xms100m -Xmx400m Start
42

5 Bedienung des Werkzeugs
5.1 Programmübersicht
Um als allererstes einen Gesamtüberblick über das Erscheinungsbild des Programms
zu erhalten, soll zunächst die Aufteilung der graphischen Oberfläche in verschiedene
Bereiche anhand der unteren Abbildung erläutert werden. Wie schon angedeutet, ist
die Ansicht des Programms in vier verschiedene Bereiche unterteilt: die Table-View, die
Detail-View, das Hauptmenü und der Logbereich.
• Die Table-View dient dem Benutzer als Browserfenster für den Zugriff auf die
Dokumente, die in der Datenbank abgelegt sind. Um benötigte Daten schneller zu
finden und auf sie zugreifen zu können, stellt die Table-View eine Filterfunktion
zur Verfügung.
• Die Detail-View hat einerseits die Aufgabe einzelne Dokumente detailiert darzustellen,
andererseits dient sie auch als Arbeitsfläche, auf der man Dokumente
verändern aber auch Testläufe definieren und starten kann.
• Das Hauptmenü bietet verschiedene Optionspunkte um auf bestimmte Hauptfunktionen
des Programms - u.a. Administratoroperationen - zugreifen zu können.
• Der Log-Bereich dient dazu, verschiedene Aktionen und Arbeitsabläufe zu dokumentieren
und diese als Folge von Einzelschritten darzustellen.
43

5.1.1 Sprache wählen
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Nachdem das Programm erfolgreich gestartet wurde, erscheint das Startfenster in dem
die Möglichkeit gegeben wird, die gewünschte Sprache zu wählen. Standartmäßig stehen
zwei Sprachen zur Verfügung: Englisch und Deutsch. Die gewünschte Sprache ist über
das Pull-Down-Menü des Startfensters [Abbildung 5.1] zu wählen.
5.1.2 Modus wählen
Abbildung 5.1: Das Startfenster
Bei der Basisversion des Programms stehen dem Benutzer zwei verschiedene Ausführungsmodi
zur Verfügung:
• Only-server-mode
• Full-function-mode
Der gewünschte Modus wird durch Anklicken des jeweiligen Buttons gewählt.
Only-server-mode
Im “Only-server-mode“-Modus wird das Programm lediglich als Server zur Berechnung
von Algorithmen gestartet. In diesem Modus steht der Server anderen Rechnern zur
Verfügung, die ihn zur Berechnung der gestarteten Experimente nutzen können.
Full-function-mode
Der “Full-function-mode“-Modus bietet die volle Funktionalität der Experimentierumgebung.
Es wird sowohl das GUI-Basierte Hauptprogramm gestartet als auch der im
“Only-server-mode“ erwähnte Server.
44

5.1.3 Erststart
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Bei dem ersten Starten des Programms werden zunächst keine Plugins geladen. Um
diese dem Programm zur Verfügung zu stellen, muss man in der Hauptmenüleiste das
Untermenü “Admin“ anwählen und den Punkt “Plugins“ anklicken.
Für diese Aktion benötigt man allerdings eine Administrator-Berechtigung. Da es sich
hierbei um die Basisversion im Einzelnutzerbetrieb handelt, wird dem Nutzer die Berechtigung
automatisch zugewiesen.
Es wird eine Liste [Abbildung 5.2] mit den verfügbaren Plugins angezeigt, die zu diesem
Zeitpunkt nicht selektiert sind. Über die Check-Boxen wählt man die gewünschten Plugins
aus und fügt sie mit dem “OK“-Button dem Hauptprogramm hinzu. Diese werden
nach einem Neustart automatisch gestartet.
5.1.4 Server hinzufügen
Abbildung 5.2: Plugins hinzufügen
Beim Erststart wird zur Berechnung von Experimenten nur der Rechner zur Verfügung
gestellt, auf dem das Programm ausgeführt wird. Um weitere Server zur Verfügung
zu stellen, öffnet man “Admin“ aus der Hauptmenüleiste und wählt den Menüpunkt
“Server“ wonach eine Liste [Abbildung 5.3] mit den hinzugefügten Servern erscheint.
Abbildung 5.3: Server hinzufügen
45

KAPITEL 5. BEDIENUNG DES WERKZEUGS
Als nächstes gibt man in dem unteren Textfeld den Namen des neuen Servers ein
und bestätigt diesen mit dem Button “ADD“. Dieser erscheint selektiert in der Liste
der verfügbaren Server. Nach dem Anklicken des Buttons “OK“ werden die Änderungen
übernommen.
46

5.2 Algorithmen
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Algorithmen sind die wichtigsten Komponenten in der Workbench. “Ein Algorithmus ist
ein Verfahren zur Lösung einer Klasse (Menge) von Einzelproblemen (Probleminstanzen).
Das Verfahren legt auf eindeutige Weise fest, wie aus der Darstellung des Einzelproblems
durch eine Folge primitiver Operationen die Darstellung der Lösung effektiv
herzustellen ist.“[Merz04] Aus der Sicht des Programms sind Algorithmen wiederum Programme
die genau das leisten 1 . Solche Algorithmen werden extern implementiert und
compiliert und erst danach in das Programm importiert. Dabei werden sowohl selbstausführbare
als auch zu interpretierende Programme von der Workbench akzeptiert und
unterstützt. Somit ist es möglich, Algorithmen in Sprachen wie Java und Pearl aber auch
C und C++ zu entwickeln und mittels dieser Workbench diese zu testen und mit denen
zu experimentieren. Dazu soll gesagt werden, dass diese Workbench nicht dazu dient
semantische bzw. syntaktische Fehler im Algorithmus-Programm zu finden, sondern vor
allem um lauffähige Algorithmen bezüglich des Laufzeitverhaltens zu verbessern und zu
perfektionieren und um rauszufinden, zu welchem Grad die an sie gestellten Anforderungen
erfüllt werden.
5.2.1 Importieren
Hat man einen Algorithmus erfolgreich implementiert und compiliert, muss dieser in das
Programm importiert werden. Um einen Algorithmus zu importieren wählt man in der
Table-View 2 [Abbildung 5.4] den Reiter “Algorithmen“ und klickt dann mit der rechten
Maustaste auf eine freie Fläche der Table-View, bzw. auf einen Eintrag der Tabelle.
Abbildung 5.4: Die Table-View
Bei dem nun erscheinenden Popup-Menü wählt man den Eintrag “Algorithmus importieren“,
worauf ein Fenster mit dem Titel “Algorithm-Import-Wizard“ [Abbildung
5.5] erscheint.
1
Im weiteren Verlauf wird öffters die Rede von Algorithmen sein, dabei sind i.d.R. die Algorithmen-
Programme gemeint.
2
Die Tabel-View ist das linke Fenster, in dem eine Tabelle mit allen verfügbaren Dokumenten zu sehen
ist.
47

Name
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Abbildung 5.5: Der Algorithm-Import-Wizard
Als erstes wählt man für den Algorithmus einen beliebigen Namen, der aber mindestens
ein Zeichen enthalten muss und gibt diesen in das oberste rechte Textfeld ein.
Dateien
Als nächstes wird die Algorithmus-Datei auf dem Datenträger gewählt. Dazu drückt man
den Button “Suchen“ neben dem entsprechendem Textfeld. Es erscheint ein Dialog, in
dem man die entsprechende Datei auf dem Datenträger finden kann. Hat man die Datei
gefunden, bestätigt man dies mit einem Klick auf den Button “Öffnen“. Der Pfad zur
Algorithmus-Datei wird nun in dem Textfeld angezeigt. Man hat auch die Möglichkeit,
im Textfeld darunter, seine eigenen Kommentare und Erklärungen zum Algorithmus zu
verfassen.
Systemeinstellungen
Mit dem Pull-Down-Menü “Betriebssystem“ wird das Betriebssystem eingestellt, auf
dem der zu importierende Algorithmus ausführbar ist. Stellt man hierbei z.B. “Linux“
ein, werden bei späteren Durchläufen alle Server mit anderen Betriebssystemen ignoriert.
Zur Auswahl stehen drei Betriebssysteme: Windows, Linux und OSX. Man hat auch die
Möglichkeit “All“ zu wählen, damit wird signalisiert, dass dieser Algorithmus auf allen
Betriebssystemen lauffähig ist. Dies ist oft bei Programmen der Fall, die erst von einem
Interpreter interpretiert werden müssen, wie z.B. Java.
Mit dem Pull-Down-Menü “Art der Ausführung“ wird festgelegt, ob der Algorithmus
selbstständig ausgeführt werden kann, wobei man hierbei den Punkt “Executable“
wählen muss oder dieser mit Hilfe eines Interpreters gestartet werden muss. Hierbei
wählt man den Menüeintrag “Interpreter“.
48

Eingabe- und Ausgabedateien
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Die nächsten drei Pull-Down-Menüs bieten die Möglichkeit die Art, in der die benötigten
Dokumente (Eingabe-Dokumente, Konfigurationen und Stylesheets) eingelesen werden,
einzustellen. Sollen die entsprechenden Dokumente dem Algorithmus als Argumente
beim Aufruf übergeben werden, stellt man die Option auf “As Arguments“. Findet der
Zugriff auf diese aus dem Algorithmus selbst statt, muss man die Option “From programm
inside“ wählen.
Beim Punkt “Aufruf-Schablone“ hat man die Möglichkeit mittels “Drag&Drop“ die
Reihenfolge der einzulesenden Dokumentarten zu wählen, wobei hier nur diese beachtet
werden, die dem Algorithmus beim Startaufruf als Argumente übergeben werden.
Die Bedeutung der einzelnen Punkte ist:
• {INP} - Alle Eingabe-Dokumente
• {CONF} - Alle Konfigurations-Dokumente
• {STY} - Alle Stylesheet-Dokumente
Im untersten rechten Textfeld gibt man den relativen Pfad vom Algorithmus zu seiner
Ausgabe-Datei an. Gibt dieser die Ausgabe-Datei in dem Ordner aus in dem er sich
selbst befindet, lässt man dieses Feld frei.
Nun gibt man in den drei rechten unteren Blöcken jeweils die Anzahl der Eingabe–
Konfigurations– und Stylesheet–Dokumente an, die der Algorithmus benötigt. Beträgt
diese bei einem Dokumenttyp mehr als null, wird der Button für die Namenseingabe
aktiv. Hat man für diesen Dokumenttyp die Einleseart auf “From programm inside’“gestellt,
so wird auch das Textfeld aktiv, in das man den relativen Pfad vom Algorithmus
zu den jeweiligen Dokumenten eingibt. Nach dem Drücken des Buttons “Namen“
erscheint ein Dialog mit einer Tabelle mit den Namen der einzelnen Dokumente. Hier
gibt man diese genau so ein, wie sie später vom Algorithmus gelesen werden. Außerdem
kann man, sofern die einzelnen Dokumente beim Startaufruf eigene Attribute benötigen,
diese als Teil des Names eintragen.
Beispiel: Der Algorithmus liest eine Eingabe-Datei mit dem Namen test.xml ein, diese
benötigt ein Attibut um den Dateityp festzulegen. Der Name dieses Dokumentes könnte
dann so eingegeben werden: −xml test.xml
Interpreter
Als letztes, sofern man “Art der Ausführung“ auf “Interpreter“ gestellt hat, führt man
die Interpreter-Einstellungen durch.
Zuerst stellt man hierzu mittels des Pull-Down-Menüs “Interpreter“ die Art des Interpreters
ein. Sollte der gewünschte Interpreter in der Auswahl nicht vorhanden sein,
kann man, indem man den Punkt “- - ADD OTHER - -“ wählt, einen neuen definieren.
Dieser sollte so eingegeben werden, wie das System ihn auch später aufruft und nicht
etwa wie der richtige Name lautet.
49

KAPITEL 5. BEDIENUNG DES WERKZEUGS
Abbildung 5.6: Die Detail-View mit selektiertem Reiter “Algorithmus-Details“
- Hinweis: Bei der Programmiersprache Java T M 3 ist der Aufruf des Interpreters: java -
Anschließend müssen alle Hilfsdateien und Ordner angegeben werden, die der Algorithmus
benötigt um einwandfrei zu funktionieren. Hierzu betätigt man den Button “ADD“
der sich im gleichen Block befindet. Dieser öffnet ein Datei-Auswahl-Dialog, in welchem
man die benötigte Datei wählt. Dies führt man für alle Hilfsdateien und Ordner, die
benötigt werden, durch.
Hat man alle Informationen eingegeben, bestätigt man dies mit dem Button “OK“,
wodurch der neue Algorithmus in die Workbench importiert wird. Die Zeit, die für den
Datenimport benötigt wird, ist von der Rechnergeschwindigkeit und Gesamtgröße aller
Dateien abhängig. Sobald der Import beendet ist, erscheint der neue Algorithmus in der
Tabelle der Table-View. In der Detail-View 4 werden alle seine relevanten Eigenschaften
und eine graphische Darstellung angezeigt.
5.2.2 Eigenschaften verändern
Alle Eigenschaften und Einstellungen, die man beim Import eines Algorithmus getätigt
hat, kann man zu einem späteren Zeitpunkt noch verändern bzw. anpassen. Hierzu
3 Java ist ein eingetragenes Markenzeichen der Firma Sun Microsystems Inc.
4 Die Detail-View ist das rechte Fenster, in dem alle Details des ausgewählten Dokumentes angezeigt
werden bzw. weitere Arbeitsschritte vorgenommen werden können
50

KAPITEL 5. BEDIENUNG DES WERKZEUGS
wählt man durch einen Linksklick den Algorithmus, den man bearbeiten möchte, aus
der Tabelle der Table-View. Sobald der Algorithmus in der Detail-View angezeigt wird,
betätigt man den Button “Eigenschaften ändern“, wodurch ein Dialog zum Verändern
von Algorithmen-Eigenschaften erscheint. Dieser entspricht im Aussehen und in der
Funktionalität dem Algorithm-Import-Wizard, der im Abschnitt “Importieren“ genau
beschrieben wurde. Die einzige Abweichung besteht darin, dass man die Algorithmus-
Datei nicht mehr neu bestimmen kann.
5.2.3 Kommentar verfassen oder ändern
Wie schon oben erwähnt besteht die Möglichkeit einen Kommentar zum gegebenen Algorithmus
zu verfassen. Dies erledigt man im Kommentar-Textfeld der Detail-View. Nachdem
man den Kommentar verfasst hat, muss man dies mittels des Buttons “Änderungen
übernehmen“ bestätigen.
5.2.4 Datei-Freigabe und Archiv
Das Programm bietet die Möglichkeit Dokumente, die man zur Zeit nicht mehr benötigt,
die womöglich zu einem Mangel an Übersichtlichkeit führen, in ein Archiv zu verschieben.
Dies hat den Vorteil, dass die Tabelle der Table-View nicht mit alten Dokumenten
überladen ist, was die Suche eines benötigten Dokumentes vereinfachen kann. Um einen
Algorithmus in das Archiv zu verschieben, öffnet man, mittels eines Rechtsklicks auf dem
richtigen Eintrag der Table-View, das Popup-Menü und wählt die Option “Zum Archiv“.
Der Algorithmus wird ins Archiv verschoben und aus dem Arbeitsbereich entfernt.
Desweiteren besteht die Möglichkeit eine Datei für andere Benutzer des Systems zum
Kopieren freizugeben. Hierzu öffnet man, wie oben beschrieben, das Popup-Menü der
Table-View und aktiviert das Kontrollkästchen “Freigabe“. Dieses Feature ist der Mehrbenutzer-Version
der Workbench vorbehalten, weswegen hier nicht weiter auf diese Funktion
eingegangen wird.
5.2.5 Zur Auswahl der Testläufe hinzufügen
Um einen Algorithmus ausführen zu können, muss man diesen erst einmal zur Auswahl-
Tabelle der Testläfe hinzufügen. Dies erreicht man, indem man den gewünschten Algorithmus
in der Tabelle der Table-View mittels Linksklick selektiert und, sobald dieser in
der Detail-View angezeigt wird, den Button “Zur Testlauf-Auswahl hinzufügen“ betätigt.
Die Detail-Ansicht wechselt anschließend zur Ansicht der Testläufe. Der weitere Ablauf
wird im Kapitel “Testläufe“[Seite 59] beschrieben.
5.2.6 Algorithmus löschen
Um einen Algorithmus aus dem System endgültig zu entfernen, ruft man wiederum,
mittels Rechtsklick auf dem gewünschten Eintrag der Table-View-Tabelle, das Popup-
Menü und wählt den Menüpunkt “Löschen“, worauf eine Bestätigungsanfrage folgt.
Bestätigt man diese, wird das Dokument unwiderruflich aus dem System entfernt.
51

5.3 Schemata und DTDs
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Um die Struktur XML-basierter Eingabedateien, Konfigurationen bzw. Stylesheets eindeutig
beschreiben zu können, bietet das Programm die Möglichkeit, diesen Dokumenten
DTDs bzw. Schemata zuzuordnen.
Def.: Die Dokumenttyp-Definition (englisch Document Type Definition, DTD, auch
Schema-Definition) ist ein Bestandteil der XML-Spezifikation. Sie wird dazu verwendet,
die Struktur bzw. den Aufbau von XML-Dokumenten genau zu definieren. Dies bedeutet,
sie legt fest welche Elemente es gibt und wie diese im Dokument angeordnet werden
müssen.
Def.: XML-Schemata liefern eine Alternative zu DTDs, da diese viele Schwächen, z.B.
im Bezug auf datenbankorientierte Anwendungen von XML, aufweisen. Die Schemata
bieten den Vorteil, dass sie selbst in der Form eines XML-Dokumentes vorliegen. Das
W3C hat XML-Schema im Jahr 2001 zum offiziellen Standard gemacht.
Die Entscheidung, welche dieser beiden Methoden man in der Workbench einsetzt,
ist völlig freigestellt. Desweiteren besteht die Möglichkeit für seine Eingabe-Dokumente
wie Eingabe-Dateien, Konfigurationen und Stylesheets keine DTD’s bzw Schemata zu
verwenden, dazu in den folgenden Kapiteln mehr.
Bedingung
Um als Benutzer dieses Systems DTDs bzw. Schemata erstellen, importieren oder manipulieren
zu können, benötigt man die “DTD-Developer“- Berechtigung. Da es sich
hierbei, wie schon weiter oben erwähnt, um die Basisversion im Einbenutzerbetrieb handelt,
wird dem Nutzer die Berechtigung automatisch zugewiesen.
5.3.1 Die Schema/DTD-Ansicht
Um zur Schema/DTD-Ansicht zu gelangen, öffnet man im Hauptmenü das Untermenü
“Work“ und wählt den Punkt “Schema/DTD-View öffnen“, worauf ein neues Fenster
zur Bearbeitung von DTDs bzw. Schemata erscheint [Abbildung 5.7]. Dieses ist ähnlich
aufgebaut wie das Hauptprogramm selbst: Auf der linken Seite befindet sich die DTD-
Table-View und auf der rechten die DTD-Detail-View.
52

5.3.2 Neues Schema/DTD
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Abbildung 5.7: Die Schema/DTD-Ansicht
Um ein neues Schema 5 zu erstellen, klickt man mit der rechten Maustaste auf eiene freie
Fläche oder einen Eintrag der DTD-Table-View um das Popup-Menü aufzurufen. Aus
diesem Menü wählt man die Option “Neues Schema/DTD“, worauf ein Eingabedialog
erscheint, in den man den Namen für das neue Schema eingibt. Nach der Bestätigung
der Eingabe erscheint ein neuer Eintrag in der DTD-Table-View, außerdem wird das
neue Schema auch in der DTD-Detail-View angezeigt. Man kann nun sein Schema in
dem Editor der DTD-Detail-View erstellen, wobei man die Möglichkeit hat, mit dem
Kontrollkästchen “XML-Highlighting aktivieren“ eine farbliche Text-Hervorhebung für
XML-Dateien zu aktivieren. Nach Fertigstellung des Dokuments muss die Eingabe des
Inhalts mit dem Button “Änderungen übernehmen“ bestätigt werden.
5.3.3 Importieren
Um ein vorhandenes Schema vom Datenträger zu importieren, öffnet man, wie im vorangehenden
Abschnitt beschrieben, das Popup-Menü und wählt den Menüeintrag
“Schema/DTD importieren“. Im erscheinenden “DTD/Schema-Import-Wizard“ gibt man
den Namen des neuen Dokumentes ein und legt die Datei, die importiert werden soll,
über den durch ein Betätigen des Buttons “Suchen“ erreichbaren Dateiexplorer fest.
Zusätzlich kann man im Textfeld “Kommentare“ ein Kommentar für dieses Dokument
verfassen. Diese Eingaben bestätigt man anschließend mit dem Button “OK“, wonach
5 Der Einfachheit halber wird im weiteren Verlauf von “Schema“ gesprochen, gemeint ist in der Regel
DTD oder Schema
53

KAPITEL 5. BEDIENUNG DES WERKZEUGS
ein neuer Eintrag in der Tabelle der DTD-Table-View erscheint und die Datei detailliert
in der DTD-Detail-View angezeigt wird.
5.3.4 Den Namen ändern
Den Namen eines Schemas ändert man, indem man im Popup-Menü eines Tabelleneintrags
den Punkt “Name ändern“ wählt, anschließend den Namen im erscheinenden
Eingabedialog eingibt und die Eingabe mit “OK“ bestätigt.
5.3.5 Änderungen am Dokument oder Kommentar
Um Änderungen am Dokument vorzunehmen, wählt man dieses zunächst mit einem
Linksklick aus der rechten Tabelle aus, welches darauf in der DTD-Detail-View erscheint.
Für Änderungen am Inhalt des Dokuments steht ein Editor mit farblicher Texthervorhebung
und einigen Editierfunktionen, die über ein Popup-Menü erreichbar sind, zur
Verfügung. Im darunter liegenden Eingabefeld kann man einen Kommentar verfassen
bzw. abändern. Verändert man den Inhalt oder den Kommentar des Dokumentes, müssen
diese Änderungen anschließend mit dem Button “Änderungen übernehmen“ bestätigt
werden.
5.3.6 Löschen
Schließlich hat man auch noch die Möglichkeit ein Schema endgültig aus dem System zu
entfernen, was man durch das Anwählen des Menüpunktes “Löschen“ des Popupmenüs
eines Tabelleneintrages erreichen kann.
54

KAPITEL 5. BEDIENUNG DES WERKZEUGS
5.4 Eingabe-, Konfigurations- und Stylesheetdokumente
In der Regel benötigen Algorithmen ein bzw. mehrere Eingabe-Dokumente auf denen
sie ihre Berechnung durchführen. Manche dieser Algorithmen benötigen zusätzlich
Konfigurations-Dokumente um verschiedene Konfigurationseinstellungen zu übernehmen.
Andere Algorithmen wiederum benötigen zusätzlich sogenannte Stylesheets um
die Eingabe-Dokumente, die ggf. als XML-Dateien vorliegen, vor der Berechnung in ein
geeignetes Format zu transformieren. Die Workbench bietet die Möglichkeit diese drei
Dokumentarten getrennt voneinander zu verwalten. Um die gewünschte Dokumentart zu
bearbeiten, wählt man in der Table-View bzw. Detail-View den entsprechenden Reiter:
Dokumentart Table-View Detail-View
Eingabe-Dokumente Eingabe-Dateien Eingabe-Details
Konfigfigurations-Dokumente Konfigurationen Konfigurations-Details
Stylesheet-Dokumente Stylesheets Stylesheet-Details
5.4.1 Neues Dokument
Um ein neues Dokument 6 anzulegen, ruft man durch einen Rechtsklick auf die jeweilige
Table-View das Popup-Menü auf und wählt den Menüpunkt “Neue Eingabe-Datei“,
“Neue Konfiguration“ bzw. “Neues Stylesheet“. Im erscheinenden Eingabedialog tippt
man den Namen des neuen Dokumentes ein und bestätigt diesen mit “OK“. Hat man
den Namen bestätigt, erscheint in der Tabelle der Table-View ein neuer Eintrag und das
neue Dokument wird in der Detail-View angezeigt. Im Editor der Detail-View kann man
nun den Inhalt des Dokumentes erstellen, wobei man die Editierfunktionen, die über das
Popup-Menü des Editors erreichbar sind, und die farbliche Texthervorhebung für XML-
Dateien zuhilfe nehmen kann. Im unteren Eingabefenster kann man ein Kommentar für
dieses Dokument verfassen. Diese Eingaben muss man nach der Fertigstellung mit dem
Button “Änderungen übernehmen“ bestätigen.
5.4.2 Dokument importieren
Möchte man eine vorhandene Datei vom Datenträger importieren, muss zunächst der
Import-Wizard [Abbildung 5.8] über den Menüpunkt “Eingabe-Datei importieren“, “Konfig.
importieren“, bzw. “Stylesh. importieren“ des Popup-Menüs der jeweiligen Table-View
aufgerufen werden.
Im Import-Wizard gibt man als erstes im obersten Textfeld einen Namen für dieses
Dokument ein, danach öffnet man durch einen Klick auf den Button “Suchen“ die Datei-
Ansicht und bestimmt mit deren Hilfe die Datei auf dem Datenträger, die importiert
werden soll. Unterhalb des Eingabefeldes für Kommentare hat man die Möglichkeit, per
6 Im Verlauf dieses Kapitels wird vom “Dokument“ gesprochen, idR. ist damit, je nach Fall, ein Eingabe-,
Konfigurations- oder Stylesheet-Dokument gemeint
55

KAPITEL 5. BEDIENUNG DES WERKZEUGS
Abbildung 5.8: Import-Wizard für Eingabe-Dateien
Auswahl einer Option zu bestimmen, ob dieses Dokument eine DTD bzw. Schema zur
Validierung des Inhaltes nutzt oder nicht. Soll dieses Dokument ein Schema nutzen, muss
der Optionspunkt “Nutzt ein Schema/DTD“ angewählt werden. Durch einen Klick auf
den unteren Button “Suchen“ hat man die Möglichkeit, ein Dokument aus der Liste
der verfügbaren DTDs bzw. Schemata zu wählen. Im Textfeld “Eingelesener Name des
Schemas/DTDs“ gibt man den Namen des Schemas ein und im Textfeld “Relativer Pfad
zum Schema/DTD“ den relativen Pfad vom Dokument zum Schema und zwar so wie
das Dokument diese später einliest.
Beispiel: In Abbildung 5.9 ist eine XML-Datei angezeigt, die die DTD “meineDTD.dtd“
aus dem Ordner “./dtd“ einliest. Die Passage ist orange hervorgehoben.
Die Eingaben bestätigt man mit dem Button “OK“, wonach ein neuer Eintrag in der
Tabelle der Table-View erscheint und das neue Dokument in der Detail-View angezeigt
wird.
5.4.3 Namen ändern
Um den Namen eines Dokuments zu ändern, wählt man im Popup-Menü des jeweiligen
Tabelleneintrages in der Table-View die Option “Name ändern“. Im erscheinenden Dialog
gibt man den neuen Namen ein und bestätigt diesen mit dem Button “OK“. Die
Änderung kann man in der Tabelle und der Detail-View beobachten.
5.4.4 Eigenschaften ändern
Möchte man die Eigenschaften eines selektierten Dokumentes ändern, ruft man mit Hilfe
des Buttons “Eigenschaften ändern“ den benötigten Wizard auf. Dieser entspricht
56

KAPITEL 5. BEDIENUNG DES WERKZEUGS
Abbildung 5.9: Ein Dokument welches eine DTD einliest
im Aussehen und Funktionalität dem Import-Wizard, der im Abschnitt ”Dokument importieren“
[Abschnitt 5.4.2] genau beschrieben wurde. Der einzige Unterschied zu dem
Import-Wizard ist, dass man die eigentliche Datei vom Datenträger nicht mehr wählen
kann.
5.4.5 Inhalt und Kommentar ändern
Um den Inhalt eines Dokumentes zu ändern, muss dieses erstmal in der Tabelle der Table-
View selektiert werden. Anschließend hat man die Möglichkeit im Editor der Detail-View
den Inhalt zu verändern und im unteren Eingabefenster einen Kommentar zu verfassen
bzw. zu ändern. Hat man den Inhalt bzw. den Kommentar verändert, muss dies mit dem
Button “Änderungen übernehmen“ bestätigt werden.
5.4.6 Datei-Freigabe und Archiv
Wie schon im Kapitel “Algorithmen“ erwähnt, bietet das Programm die Möglichkeit,
Dokumente die man zur Zeit nicht mehr benötigt, in ein Archiv zu verschieben. Dies hat
den Vorteil der schnelleren Auffindung von aktuellen Dokumenten. Um ein Dokument in
das Archiv zu verschieben, öffnet man, mit einem Rechtsklick auf den jeweiligen Eintrag
der Table-View, das Popup-Menü und wählt die Option “Ins Archiv“. Das Dokument
wird ins Archiv verschoben und aus dem Arbeitsberech enfernt.
Wie ebenfalls im Kapitel “Algorithmen“ erwähnt, besteht die Möglichkeit, ein Dokument
für andere Benutzer des Systems zum Kopieren freizugeben. Hierzu öffnet man, wie
oben beschrieben, das Popup-Menü der Table-View und aktiviert das Kontrollkästchen
“Freigabe“.
57

5.4.7 Zur Auswahl der Testläufe hinzufügen
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Um eine der drei Dokumentarten einem bzw. mehreren Algorithmen für Testläufe zur
Verfügung zu stellen, muss man das Dokument erst einmal zur Auswahl-Tabelle der
Testläufe hinzufügen. Dies erreicht man indem man das gewünschte Dokument in der
Tabelle der Table-View mittels Linksklick selektiert und nach Erscheinen in der Detail-
View den Button “Zur Testlauf-Auswahl hinzufügen“ betätigt. Hierfür ist es notwendig,
dass davor bereits mindestens ein Algorithmus vom Benutzer zur Auswahl-Tabelle der
Testläufe hinzugefügt wurde. Die Detail-Ansicht wechselt anschließend zur Ansicht der
Testläufe. Der weitere Ablauf wird im Kapitel “Testläufe“[Seite 59] näher beschrieben.
5.4.8 Löschen
Durch das Anklicken des Menüpunktes “Löschen“ des Popupmenüs eines Tabelleneintrages
ist es möglich, nach dem Bestätigen einer Sicherheitsanfrage, dieses Dokument
dauerhaft aus dem System zu entfernen.
58

5.5 Testläufe
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Der Grundgedanke dieses Systems ist es Algorithmen bezüglich ihrer Laufzeit und Funktionalität
zu verfeinern und zu optimieren. Zu diesem Zweck ist es notwendig, einzelne
Algorithmen oder Algorithmenreihen verschiedenen Tests zu unterziehen. Die so ermittelten
Resultate und die daraus folgenden Überlegungen lässt man in die Optimierung
dieser Algorithmen, zum Beispiel durch Anpassung von Konfigurationsdokumenten, einfliessen.
Um solche Testläufe starten zu können, ist es notwendig, diese zunächst zu
definieren.
5.5.1 Vorbedingung
Wählt man in der Detail-View den Reiter “Testläufe“ erscheint die Ansicht der Testläufe
[Abbildung 5.10]. Um Testläufe definieren zu können, muss der Benutzer im Vorfeld,
wie in den Kapiteln “Algorithmen“ und “Eingabe-, Konfigurations- und Stylesheet-
Dokumente“ beschrieben, Algorithmen und Eingabe-Dokumente zur Testlaufauswahl
hinzugefügt haben.
Abbildung 5.10: Die Detail-View mit selektiertem Reiter “Testläufe“ und hinzugefügten
Dokumenten
59

5.5.2 Definition von Testläufen
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Um einen oder mehrere Testläufe zu definieren, selektiert man per Linksklick den jeweiligen
Algorithmus und die Eingabe-Dokumente in den entsprechenden Tabellen der
Detail-View, anschließend bestätigt man diese Auswahl mit dem “ADD“-Button. Alle
sich daraus ergebenden Kombinationen werden zur Tabelle “Testläufe“ hinzugefügt. Auf
diese Art definiert man alle Kombinationen die man für das gewünschte Experiment 7
benötigt.
5.5.3 Komponenten aus der Run-Tabelle tauschen
Es besteht die Möglichkeit einzelne Dokumente oder Dokumentgruppen, die zur Testlauftabelle
hinzugefügt wurden, gegen andere Dokumente, die in den anderen Tabellen der
Detail-View angezeigt werden, zu tauschen. Hierzu klickt man mit der rechten Maustaste
auf die jeweilige Komponente der Testlauf-Tabelle um ein Popup-Menü zu öffnen. Über
dieses Menü hat man nun die Möglichkeit, durch Drücken der jeweiligen Option, diese
Komponente oder alle Komponenten dieser Spalte gegen das markierte Dokument der
selben Art zu tauschen.
5.5.4 Testläufe aus der Tabelle entfernen
Es gibt drei Möglichkeiten die definierten Testläufe aus der Testlauftabelle zu entfernen:
• in der Testlauftabelle, in der Spalte in der sich der zu entfernende Testlauf befindet,
betätigt man den Button “DEL“. Hiermit wird der entsprechende Lauf aus der
Testlauftabelle entfernt.
• durch Betätigen des Buttons “Testlauftabelle“ löschen. Hiermit löscht man den
gesamten Inhalt der Testlauftabelle.
• durch Betätigen des Buttons “Alles löschen“. Diese Funktion entfernt nicht nur
alle Einträge der Testlauftabelle, sondern löscht alle Einträge von allen Tabellen
der Detail-View.
5.5.5 Alle bevorstehenden Resultate anzeigen
Vor dem Start hat man die Möglichkeit das Kontrollkästchen “Alle Ausgaben zeigen“
zu aktivieren. Dies hat zur Folge, dass während der späteren Läufe die Ausgaben aller
Algorithmenberechnungen sofort angezeigt werden und man nicht erst einmal die Resultate
abspeichern muss um diese zu betrachten. Diese Option kann man allerdings auch
noch nach dem Start, vor dem Ablauf aller Testläufe aktivieren.
7 Als Experiment versteht man im Zusammenhang mit der CAEW einen Testlauf, den man zu einem
späteren Zeitpunkt mit gleichen oder veränderten Werten wiederholt durchführen kann
60

5.5.6 Resultat-Graph
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Zusätzlich zu den Ausgabedokumenten lassen sich die Laufzeitdifferenzen zwischen den
einzelnen Testläufen als Graph [Abbildung 5.11] darstellen. Dies hat den Vorteil, mögliche
Unterschiede beim zeitlichen Ablauf der Testläufe einfacher erkennen zu können. Um
diese Funktion zu aktivieren, wird das Kontrollkästchen “Resultat-Graph anzeigen“ vor
dem Ablauf des letzten Testlaufs angeklickt.
5.5.7 Testläufe starten
Abbildung 5.11: Der Resultat-Graph
Nachdem man die gewünschten Testläufe definiert hat, werden die Berechnungen mit
Hilfe des Buttons “Start“ gestartet. In der Spalte “Status“ der Testlauf-Tabelle kann man
beobachten welche Testläufe aktuell auf welchem Server berechnet werden. Nach dem
Ablauf jedes Testlaufs kann man in dieser Spalte ablesen, ob dieser korrekt durchlaufen
wurde oder fehlgeschlagen ist. Ist ein Testlauf fehlgeschlagen, wird dies in der “Status“-
Spalte durch den Ausdruck “FAILED“ angezeigt. Durch ein Rechtsklick auf dieses Feld
kann man sich die Fehlerausgabe anzeigen lassen, falls eine vom Algorithmus erzeugt
wurde. Es besteht jederzeit die Möglichkeit, die Testläufe durch Betätigen des Buttons
“Abbrechen“ vorzeitig zu beenden.
61

5.5.8 Testläufe speichern
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Nach Beendigung aller Testläufe besteht die Option, diese als Experimente zu speichern.
Hierzu bestätigt man den erscheinenden Abfrage-Dialog mit “Ja“. Es erscheint
ein neuer Dialog, der dem Benutzer die Möglichkeit bietet, diverse Einstellungen vor
dem Speichern vorzunehmen. Zuallererst selektiert man die Testläufe, die als Experimente
gespeichert werden sollen, wobei nur die korrekt berechneten zur Auswahl stehen.
Hat man einen oder mehrere Testläufe selektiert, können sich die daraus ergebenden
Experimente zu einer Experiment-Sequenz zusammenfassen lassen um diese zusätzlich
gruppiert abzuspeichern. Dieser Sequenz wird automatisch ein Standard-Name zugewiesen,
der jedoch vom Benutzer im unteren Textfeld geändert werden kann. Nach dem
Betätigen des “Speichern“-Buttons werden alle selektierten Testläufe als Experimente
und ggf. die Experiment-Sequenz in das System übernommen.
62

5.6 Experimente
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Unter einem Experiment versteht man, im Zusammenhang mit der CAEW, einen Testlauf,
den man zu einem späteren Zeitpunkt, mit gleichen oder veränderten Werten, erneut
durchführen kann.
5.6.1 Einzel-Experimente
Übersicht
Beabsichtigt man ein gespeichertes Experiment aufzurufen, öffnet man in der Table-
View die Sektion Experimente und selektiert das gewünschte Experiment, wobei zu
beachten ist, dass der untere Reiter “Einzel-Experimente“ gewählt sein muss. Hat man
ein Experiment selektiert, erscheint dessen detaillierte Beschreibung in der Detail-View
[Abbildung 5.12]. Diese Ansicht ist in vier Bereiche unterteilt:
• Name des Experiments und Informationen zu seiner Generierung
• Komponenten, die für den Testlauf verwendet wurden: Oben wird der Name des
Algorithmus angezeigt. Alle Eingabe-Dokumente (Eingabedateien, Konfigurationen
und Stylesheets) werden in den entsprechenden Tabellen dargestellt.
• Kontext, der die Testlaufbedingungen dokumentiert: Es werden das Betriebssystem,
der Prozessortyp, der Gesamtspeicher und der Name des Servers angezeigt,
auf dem der Testlauf dieses Experiments durchgeführt wurde. Zudem wird die Zeit
angezeigt, die der Algorithmus gebraucht hat um die Berechnungen durchzuführen.
• Kommentar, der das jeweilige Experiment näher beschreibt.
Namen ändern
Den Namen eines Experiments ändert man, indem man mit der rechten Maustaste
auf den entsprechenden Eintrag der Table-View-Tabelle klickt und somit das Popup-
Menü öffnet. Aus diesem Menü wählt man den Punkt “Name ändern“ und gibt anschließend,
in dem erscheinenden Dialog, den neuen Namen ein.
Kommentar verfassen bzw. ändern
Wird im Textfeld “Kommentar“ ein neuer Kommentar verfasst oder ein bestehender
verändert, muss die Eingabe mit dem Button “Änderungen übernehmen“ bestätigt werden.
63

Ins Archiv verschieben
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Abbildung 5.12: Die Details eines Experimentes
Durch Anklicken des Menüpunktes “Ins Archiv“ des Popup-Menüs eines Dokumentes in
der Tabelle der Table-View, wird dieses ins Archiv verschoben und aus dem Arbeitsbereich
entfernt.
Zur Tabelle der Testläufe hinzufügen
Hat man sich dafür entschieden, ein bestehendes Experiment einem wiederholten Testlauf
zu unterziehen, selektiert man dieses in der Table-View, sodass es in der Detail-View
erscheint. Nun betätigt man den Button “Zur Testlauftabelle hinzufügen“, woraufhin das
Experiment zu der besagten Tabelle hinzugefügt wird und die Detail-View zur Ansicht
der Testläufe wechselt. Das Verändern der Attribute des Testlaufs und das Starten der
Berechnung wurde ausführlich im Kapitel “Testläufe“ beschrieben.
Löschen
Um ein Experiment zu löschen, öffnet man, wie schon zuvor beschrieben, das Popup-
Menü des zu löschenden Eintrags und wählt die Option “Löschen“. Nachdem man die
Sicherheitsanfrage bestätigt hat, wird das Experiment endgültig aus dem System entfernt.
64

Ausgabe
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Übersicht Bei jedem korrekt berechneten Testlauf wird auch eine Ausgabe erzeugt, die
die Resultate anzeigt. Diese Ausgabe wird ebenfalls beim Speichern eines Experiments
in der Datenbank abgelegt. Um die Ausgebe eines selektierten Experiments zu betrachten
[Abbildung 5.13], wählt man den Reiter “Ausgabe-Datei“ in der Detail-View des
Experiments.
Abbildung 5.13: Ansicht einer gespeicherten Ausgabe-Datei
In dem nun erscheinenden Texteditor sieht man den Inhalt der Ausgabe-Datei, während
weiter unten die Standard-Ausgabe des Testlaufs als grau unterlegtes Textfeld zu sehen
ist.
Kommentar verfassen bzw. ändern Es besteht die Möglichkeit ebenfalls die Ausgabe-
Datei, im “Kommentar“-Textfeld, mit einem Kommentar zu versehen. Jede Abänderung
des Kommentars muss mit dem “Änderungen übernehmen“-Button bestätigt werden.
Exportieren Das Programm bietet die Option, die Ausgabedatei als eine Datei beliebigen
Formats auf den Datenträger zu exportieren. Hierzu betätigt man, bei selektiertem
Experiment und gewählter “Ausgabedatei“-Ansicht, den Button “Exportieren“. Es
erscheint ein Dateizugriffsdialog in dem man den Namen der neuen Datei und das Speicherziel
wählen kann. Gibt man beim Dateinamen keine Endung an, so wird automatisch
die Endung “.xml“ vergeben.
65

5.6.2 Experimentsequenzen
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Eine Erweiterung der Experimente stellt die Experiment-Sequenz dar. Eine Experimentsequenz
ist eine Ansammlung mehrerer Experimente. Diese eignet sich sehr gut dazu,
ganze Testlauf-Serien wiederholt berechnen zu lassen.
Übersicht
Um eine Experiment-Sequenz zu selektieren, muss bei der Table-View der Bereich
“Experimente“ ausgewählt und der “Experiment-Sequenzen“-Reiter dieser Ansicht aktiviert
sein. Klickt man auf einen Eintrag der Tabelle, erscheint in der Detail-View eine
detaillierte Ansicht dieser Sequenz [Abbildung 5.14]. Diese Ansicht zeigt eine Tabelle mit
allen Experimenten, die von dieser Sequenz referenziert werden.
Namen ändern
Abbildung 5.14: Detail-Ansicht einer Experiment-Sequenz
Durch einen Klick auf den Punkt “Name ändern“ des Popup-Menüs eines Sequenz-
Eintrags in der Table-View, ist es möglich die jeweilige Sequenz umzubenennen.
Kommentar verfassen bzw. ändern
Auch bei der Experimentsequenz besteht die Möglichkeit individuelle Kommentare zu
verfassen. Diese gibt man im Textfeld “Kommentare“ der Detail-View ein und bestätigt
deren Änderung mit dem Button “Änderungen übernehmen“.
66

Ins Archiv verschieben
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Analog zu Einzelexperimenten, lassen sich Experimentsequenzen ebenfalls durch ein
Klick auf den Popup-Menü-Eintrag “Ins Archiv“ ins Archiv auslagern.
Zur Tabelle der Testläufe hinzufügen
Die referenzierten Experimente einer Experimentsequenz fügt man mit dem “Zur Testlauftabelle
hinzufügen“-Button in der Detailansicht der Sequenz zur Testlauftabelle hinzu.
Die Detailansicht wechselt anschließend automatisch zur Ansicht der Testläufe. Das
Starten und Abändern dieser Testläufe wurde im Kapitel “Testläufe“ detailliert beschrieben.
Löschen
Das Löschen einer Experimentsequenz erfolgt indem man den Punkt “Löschen“ im
Popup-Menü des entsprechenden Eintrags in der Table-View anwählt.
67

5.7 Archiv
KAPITEL 5. BEDIENUNG DES WERKZEUGS
Das Archiv bietet die Möglichkeit Dokumente, die man zwar aktuell nicht benötigt, die
man aber nicht endgültig aus dem System entfernen möchte, aus dem Arbeitsbereich
zu entfernen. Dies bietet einen besseren Überblick beim Experimentieren mit aktuellen
Algorithmen. Sollte man die archivierten Dokumente wieder benötigen, ist es jederzeit
möglich, diese aus dem Archiv in den Arbeitsbereich zurück zu verschieben.
5.7.1 Die Archivansicht
Um die Archivansicht [Abbildung 5.15] zu öffnen, klappt man das Untermenü “Work“
des Hauptmenüs auf und wählt den Punkt “Archiv öffnen“. Es erscheint die Archivansicht
mit Archivbereichen für jeden im Programm verwendeten Dokumenttyp. Wie
Dokumente archiviert werden, wurde in den vorangehenden Kapiteln genau beschrieben.
Um zu einem Archivbereich eines bestimmten Dokumenttyps zu wechseln, klickt man
auf den jeweiligen Reiter. Die Dokumente selbst werden, wie auch in der Table-View des
Arbeitsbereiches, durch Einträge in einer Tabelle dargestellt.
Abbildung 5.15: Die Archivansicht mit selektiertem Archivbereich “Algorithmus“
68

KAPITEL 5. BEDIENUNG DES WERKZEUGS
5.7.2 Datei zum Arbeitsbereich verschieben oder löschen
Um eine Datei wieder zum Arbeitsbereich zu verschieben, hat man die Möglichkeit, diese
zunächst mittels des eingebauten Filters zu suchen. Hat man das entsprechende Dokument
gefunden, klickt man in dieser Zeile der Archivtabelle auf den Button “Zurück“,
worauf dieses sofort wieder zum Arbeitsbereich zurück verschoben wird.
Um eine Datei direkt aus dem Archiv heraus zu löschen, betätigt man den “Löschen“-
Button des jeweiligen Tabelleneintrages, worauf eine Sicherheitsabfrage bestätigt werden
muss. Anschließend wird dieses Dokument endgültig aus dem System entfernt.
5.8 Darstellung, Log und Beendigung des Programms
5.8.1 Darstellung
Der Benutzer hat die Möglichkeit, zwischen drei verschiedenen Erscheinungsbildern der
graphischen Oberfläche zu wählen:
• Metal-Look
• Motif-Look
• Windows-Look
Um das Aussehen der graphischen Oberfläche zu ändern, öffnet man im Hauptmenü das
Untermenü “Einstellungen“ und wählt den entsprechenden Menüpunkt. Zu beachten ist,
dass die Option “Windows-Look“ aus rechtlichen Gründen nur Nutzern des Betriebssystems
“Microsoft W INDOW S T M “ 8 vorbehalten ist.
5.8.2 Log
Die wichtigsten Aktionen, die der Benutzer durchführt, werden im unteren Log-Fenster
festgehalten. Somit ist es möglich die Arbeitsschritte, die man getätigt hat, jederzeit
nachzuvollziehen.
5.8.3 Programm beenden
Um das Programm zu beenden, öffnet man im Hauptmenü das Untermenü “System“
und wählt den Punkt “Exit“. Die zweite Möglichkeit das Programm zu beenden besteht
darin, das X-Zeichen des Hauptfensters zu betätigen.
8 Windows ist ein eingetragenes Markenzeichen der Firma Microsoft Corporation
69

6 Erweiterungsmöglichkeiten
Das System verfügt über eine modulare Architektur, welche es erlaubt, neue Funktionalität
ohne größeren Aufwand in das Programm zu integrieren. Im diesem Kapitel sollen
zunächst die Schritte beschrieben werden, die zur Erstellung der funktionserweiternden
Plugins benötigt werden. Anschließend wird der Vorgang der Integration neuer Sprachmodule
detailliert vorgestellt.
6.1 Erstellung und Integration eines Plugins
Die einfachste Methode ein neues Plugin für die “CAEW“ zu Entwickeln, ist, dieses
mit dem Entwicklungstool ’Eclipse“ zu erstellen. Hierfür muss zunächst der bei der Installation
des Programms erstellte Ordner als Workspace von Eclipse definiert werden.
Bei der Erstellung eines neuen Projektes für die Entwicklung des Plugins muss das
“CAEW“-Projekt zum Klassenpfad hinzugefügt werden. Die Entwicklung von Plugins
ohne den Einsatz von “Eclipse“ ist ebenfalls möglich, hierbei muss darauf geachtet werden,
dass das Verzeichnis “bin“, das ein direkter Unterordner des Installationsordners ist,
zum Klassenpfad des eingesetzten Entwicklungwerkzeugs hinzugefügt wird. Im Folgenden
wird als Beispiel ein Plugin erstellt, welches keine relevante Funktion für das System
mitbringt, es fügt lediglich die Worte “PLUGIN ERFOLGREICH HINZUGEFÜGT“ in
die beiden Ansichtsfenster und in die Nachrichtenausgabe ein. Zudem ergänzt es das
Hauptmenü des Systems um den Eintrag “NEUER MENÜPUNKT“. Bei der Entwicklung
dieses Plugins wird auf die Strukturierung in ein Schichtenmodell verzichtet, es wird
lediglich eine Klasse implementiert,die alle benötigten Methoden bereitstellt. Hierdurch
soll der Aufwand der Erstellung des Beispielplugins so gering wie möglich gehalten werden.
Dieses Beispiel kann selbstverständlich als Referenz für die Entwicklung weiterer
Plugins verwendet werden.
Zunächst müssen die oben beschriebenen Vorkehrungen getroffen werden.
Anschließend wird die Klasse “MyPlugin“ erstellt. Diese muss als Hauptklasse des Pluins
die Schnittstelle "de.usi.caew.system.Plugin" des “CAEW“-Projektes implementieren.
Die Schnittstelle beschreibt die zwei Methoden
"setMainSys(de.usi.caew.system.MainSys mainSys)" und
"setMainFrame(de.usi.caew.gui.MFrame mainFrame)", die ebenfalls von der Klasse
Implementiert werden müssen. Mit der Implementierung dieser Methoden beschafft man
die Referenzen auf die Klassen "MainSys" und "MFrame" des “CAEW“-Hauptsystems.
Zudem beherbergt die erstgenannte Methode den Aufruf der zunächst leeren Initialisierungsmethode
start(). Das Listing des Quellcodes der bis hierhin erstellten Klasse
sieht wie folgt aus:
70

import de.usi.caew.system.*;
import de.usi.caew.gui.*;
import javax.swing.*;
public class MyPlugin implements Plugin{
private MainSys mainSys;
private MFrame mainFrame;
public void setMainSys(MainSys mainSys){
this.mainSys = mainSys;
start();
}
public void setMainFrame(MFrame mainFrame){
this.mainFrame = mainFrame;
}
public void start(){
}
}
KAPITEL 6. ERWEITERUNGSM ÖGLICHKEITEN
Die folgende Funktionalität wird als Inhalt der "start"-Methode implementiert. Zunächst
werden zwei "JPanel"-Objekte erstellt, denen wird jeweils ein "Label"-Objekt zugeordnet.
Bei der Erstellung dieser "Label"-Objekte wird deren Konstruktoren der String
"PLUGIN ERFOLGREICH HINZUGEFÜGT" übergeben. Die "JPanel"-Objekte werden mit
Hilfe der Aufrufe der Methoden "getMainView()" und "getTreeView()" des Hauptfensters
in dieses integriert. Anschließend wird mittels der Methode "updateLog(String text)"
der "MainSys"-Klasse und der Methode "updateLog()" des Hauptfensters die Nachrichtenausgabe
des Systems aktualisiert.
JPanel pan1 = new JPanel();
pan1.add(new JLabel("PLUGIN ERFOLGREICH HINZUGEFÜGT"));
JPanel pan2 = new JPanel();
pan2.add(new JLabel("PLUGIN ERFOLGREICH HINZUGEFÜGT"));
mainFrame.getMainView().addTab("tab1", pan1);
mainFrame.getTreeView().addTab("tab2", pan2);
mainSys.updateLog("PLUGIN ERFOLGREICH HINZUGEFÜGT");
mainFrame.updateLog();
Als nächstes soll das Hauptmenü um den Eintrag “NEUER MENÜPUNKT“ erweitert
werden, welcher im Untermenü “Work“ erscheint. Hierzu wird die Methode "getMenu()"
des Hauptfensters verwendet, die ein Objekt des Typs "UsedMenu" zurückgibt. Die
"UsedMenu"-Klasse ist eine Erweiterung der Swing-Klasse "JMenuBar", die einige Zusatzfunktionen
bietet. Dem Hauptmenü, welches durch das "UsedMenu"-Objekt repräsentiert
wird, wird ein neuer Menüpunkt in Form eines "JMenuItem"-Objektes übergeben.
71

KAPITEL 6. ERWEITERUNGSM ÖGLICHKEITEN
JMenuItem menuItem = new JMenuItem("NEUER MENÜPUNKT");
UsedMenu mainMenu = mainFrame.getMenu();
mainMenu.getImports().add(menuItem);
Nach der Compilierung ist die Entwicklung dieses Plugins abgeschlossen. Dieses muss
dem System jetzt zur Verfügung gestellt werden. Aus diesem Grund wird im Verzeichniss
“Plugin“ des Installationsordners ein neuer Ordner mit dem Namen “TestPlugin“
erstellt, in den die compilierte Klasse eingefügt wird. Als zweiter Schritt muss nun eine
XML-Datei, welche nach den Regeln der im Abschnitt “Einbindung von Plugins“ des Kapitels
3.9 gezeigten DTD aufgebaut ist, erstellt werden. Der Inhalt dieser Datei, die unter
dem Namen plugin.xmlëbenalls im Ordner TestPlugin“begelegt wird, sieht wie folgt aus:
In dieser Datei definiert man den Namen des Plugins, der in diesem Fall “Test Plugin“
lautet und gibt mit dem Attribut “Classname“ die Hauptklasse des Plugins, die vom
Hauptsystem geladen wird, an.
Nach dem Start des Systems muss man mittels der Option “Plugins“, die sich im Untermenü
“Admin“ des Hauptmenüs befindet, das erstellte Plugin aktivieren. Bei einem
erneuten Start lädt das System das Plugin und übernimmt dessen Funktionalität. Das
Programm bekommt durch das Plugin das folgende Erscheinungsbild, wobei die relevanten
Stellen rot markiert wurden:
Abbildung 6.1: Das Erscheinungsbild des Systems nach dem Einbinden des Testplugins
72

6.2 Integration eines neuen Sprachpakets
KAPITEL 6. ERWEITERUNGSM ÖGLICHKEITEN
Die Eigenschaft der modularen Spracherweiterung des Systems erlaubt es dem Entwickler,
die Unterstützung von zusätzlichen Sprachen in relativ einfacher Weise und ohne
großen Aufwand in das System zu integrieren. Die Integration eines Pakets, welches das
Programm um die Sprache Französisch erweitert, soll im Folgenden erläutert werden.
Zunächst wird eine leere Textdatei erzeugt und unter dem Namen “Lang fr FR.properties“
im Verzeichnis “Language“, welches ein Unterordner des Installationsordners ist, abgespeichert.
In diese Datei werden nun alle vom Programm genutzten Zeichenketten
mit der Zuweisung eines Schlüssels abgelegt. Dabei werden nur Schlüssel verwendet,
die auch schon in der Datei “Lang en US.properties“ vorkamen. Diesen Schlüsseln wird
die französische Übersetzung der in der Datei “Lang en US.properties“ vorkommenen
Zeichenketten in geeigneter Weise zugeordnet. Ein kurzer Auszug der Datei soll im Folgenden
gezeigt werden:
1=Des filtres supprimer
2=De retour
3=Supprimer
4=Serveur
5=Nom servuer
6=Application
7=Nouveau servuer
8=Nom:
9=Ajouter
.
.
.
Es ist nicht zwingend notwendig allen Schlüsseln eine Übersetzung zuzuordnen. Zeichenketten,
deren Schlüssel in der neuen Sprachdatei nicht vorkommen, werden im Programm
ersatzweise in der englischen Sprache ausgegeben.
Nach der Erstellung der Sprachdatei ist es notwendig, in der XML-Datei “Lang.xml“,
welche sich ebenfalls im Ordner “Language“ befindet, im Tag ein neues
XML-Element hinzuzufügen, mit deren Hilfe dem System Informationen über das neue
Sprachpaket übergeben werden. Nach dem hinzufügen des neuen Elements hat die Datei
folgende Form:
73

KAPITEL 6. ERWEITERUNGSM ÖGLICHKEITEN
Nach dem Systemstart kann im erscheinenden Dialog, wie in Abbildung 6.2 dargestellt,
die neu hinzugekommene Sprache aus dem Pull-Down-Menü ausgewählt werden.
Die Ausgabe der Texte im Programm findet nun in der Sprache des neu hinzugefügten
Sprachpakets statt.
Abbildung 6.2: Wahl der neu hinzugekommenen Sprache
74

7 Zusammenfassung und Ausblick
Zusammenfassung
In dieser Arbeit wurde die Entwicklung und die Bedienung eines Werkzeugs vorgestellt,
welches zur Unterstützung rechnergestützter Experimente eingesetzt werden kann. Diese
Experimente dienen dazu, Algorithmen diversen Testläufen zu unterziehen, bei denen
verschiedene Eingaben und Konfigurationen eingesetzt werden um das Laufzeitverhalten
dieser Algorithmen zu ermitteln. Die Verbesserung der Effizienz von Algorithmen kann
oft nur durch wiederholtes Testen und Neukonfigurieren erreicht werden.
Das Werkzeug unterstützt den Nutzer - wie gezeigt wurde - nicht nur bei der Verwaltung
der benötigten Dokumente, die zur Ausführung solcher Experimente eingesetzt werden,
sondern auch bei der Durchführung der Testläufe. Um den Nutzer bei der Berechnung
von mehreren Testläufen zu unterstützen, bietet es die Möglichkeit, diese Berechnungen
auf mehrere Server eines Netzwerkclusters zu verteilen und die einzelnen Testläufe
parallel auszuwerten.
Bevor in dieser Ausarbeitung auf den Entwurf des Werkzeugs und seiner einzelnen
Komponenten eingegangen wurde, wurden vorab die an das System gestellten Anforderungen
und Bedingungen vorgestellt.
Bei der Dokumentation der Entwicklung des Systems wurde gezeigt, dass dessen Aufbau
auf einer modularen Struktur beruht. Die einzelnen Module wiederum weisen eine
Schichtenarchitektur auf, wie sie in dieser Ausarbeitung vorgestellt wurde.
Es wurde gezeigt wie die Einbindung einer relationallen Datenbank mit Hilfe des Frameworks
“Hibernate“ funktioniert und in das System integriert wurde. Hierbei wurden die
verwendeten Datenstrukturen und deren Abbildung auf die eingesetzte Datenbankstruktur
erklärt. Zudem wurde das Verfahren der individuellen Verteilung von eindeutigen
Identifizierern, welche für die persistente Speicherung in einer relationalen Datenbank
benötigt werden, detaillierter vorgestellt.
Nachdem demonstriert wurde, wie das System Dokumente intern verwaltet, wurde auf
die Fähigkeit der Integration neuer Funktionen in das System, mit Hilfe der Einbindung
von Plugins, eingegangen. Anschließend wurde die Funktionalität des Programms
erläutert, die es erlaubt, die Anzahl der unterstützten Sprachen in Form von Sprachpaketen
zu erweitern. Zudem wurde gezeigt, in welcher Weise der Einsatz der graphischen
Oberfläche die modulare Struktur des Systems unterstützt. Um die Funktionalität des
Werkzeugs zu demonstrieren, wurde dessen Installation und Bedienung sehr detailliert
beschrieben.
Anschließend wurde die Entwicklung und Integration eines neuen Plugins sowie eines
neuen Sprachpakets anhand von zwei praktischen Beispielen demonstriert.
75

Ausblick
KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK
Das hier entwickelte System stellt den ersten Schritt zur Realisierung eines Werkzeugs
dar, mit dem kooperative und kompetitive algorithmenbasierte Experimentdurchführung
verteilter Nutzer ermöglicht werden soll. Um diese Funktionalität bieten zu können, muss
das System konzeptionell so erweitert werden, dass ein paralleles Arbeiten mehrerer Nutzer,
aber auch ganzer Benutzergruppen, auf der Basis gemeinsamer Dokumentmappen
möglich ist. Um dies zu garantieren, wären die folgenden konzeptionellen Erweiterungen
denkbar:
• Die Verwaltung von vielen Einzelnutzern und Benutzergruppen erfordert eine Funktion
zur Vergabe und Prüfung von Rechten, die diesen Nutzern bzw. Gruppen
zugeteilt werden müssen. Hierzu ist es notwendig, ein administratives System zu
entwickeln, welches durch den Eingriff von als Administrator gekennzeichneten
Nutzer, diese Aufgaben übernimmt. Die Administratoren sollten dabei nicht nur
für den einwandfreien Ablauf des Systems verantwortlich sein, sondern auch die
Aufgabe übernehmen, einzelne Nutzer in das Mehrbenutzersystem aufzunehmen
bzw. diese aus dem System zu entfernen.
• Da bei einem Mehrbenutzersystem viele Nutzer und Nutzergruppen mit dem System
interagieren, ist es womöglich erforderlich - zwecks Identifikation und Kontaktierung
- deren prsönlichen Daten aufzunehmen und zu verwalten. Aus Datenschutzgründen
wäre hierbei ein besonderes Verschlüsselungsverfahren zu empfehlen.
• Der Einsatz einer integrierten Datenbank ist in einem Mehrbenutzersystem nicht
mehr von Interesse. Um die Möglichkeit des Zugriffs vieler Nutzer zu unterstützen,
müsste die Anbindung an einen bestehenden Datenbankserver, wie beispielsweise
MySQL, in das System integriert werden
• Bei der Verwendung eines Datenbankservers müsste die Kommunikation und insbesondere
die Datenübertragung zwischen Client und Server angepasst werden.
Da hierbei davon auszugehen ist, dass die an das Netzwerkcluster angeschlossenen
Server einen direkten Zugriff auf die Datenbank erhalten können, kann die Datenübertragung
direkt zwischen diesen beiden Instanzen ablaufen und nicht mehr
auf dem indirekten Wege über den Client stattfinden.
• Die Übertragung von Daten zwischen Datenbank und Server könnte zudem minimiert
werden. Dies könnte durch eine temporäre Speicherung der vom Server
empfangenen Daten realisiert werden. Bei dem Versuch der Neuübertragung gleicher
Daten könnte anhand einer Checksummenprüfung dies unterbunden werden
um die auf dem Server temporär gespeicherten Daten für eine Berechnung zu nutzen.
• Da einzelne Nutzer bzw. Nutzergruppen nicht unbedingt in einem lokalen Netzwerk
arbeiten, wäre der Zugriff auf das Mehrbenutzersystem über das Internet
76

KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK
wünschenswert. Hierzu müssten geeignete Methoden, welche die Datenübertragung
im WWW ermöglichen, zur Verfügung gestellt werden.
• Zur Unterstützung der Entwicklung von Softwareprojekten werden oft Medien,
wie beispielsweise Repositories, eingesetzt. Es wäre in der Mehrbenutzerversion des
Systems von Interesse, den Zugriff auf CVS- bzw SVN-Repositories zu ermöglichen.
Dies stellt jedoch eine besondere Herausforderung dar, da in Repositories in der
Regel Quelltexte der Programme abgelegt werden. Es müsste somit eine Funktion
bereitgestellt werden, welche solche Quellcodes in geeigneter Weise compiliert.
• Die Weiterverarbeiung von Resultaten sollte gefördert werden. Hierzu wäre es sinnvoll,
ein einheitliches Format für diese Ausgabedokumente zu entwickeln. Somit
wäre eine Unterstützung der Weiterverarbeitung mittels verschiedener Werkzeuge,
wie etwa LaTex oder Matlab, relativ einfach zu realisieren.
Die in dieser Ausarbeitung vorgestellte modulare Architektur, welche im Hinblick auf
das Mehrbenutzersystem entwickelt wurde, erlaubt es, eine solche Funktionalität mit
relativ geringem Aufwand in das System zu integrieren. Die Entwicklung der Mehrbenutzerfunktionalität
soll als Nachfolgeprojekt Gegenstand einer weiteren Diplomarbeit
sein.
77

8 Anhang
Anhang A
Der Aufbau aller persistent zu speichernden Daten des Systems:
78

Anhang B
KAPITEL 8. ANHANG
In diesem Anhang sind alle für die Nutzung von “Hibernate“ verwendeten Konfigurationsund
Mappingdateien aufgelistet.
SessionFactory-Konfigurationsdatei (“hibernate.cfg.xml“)
org.apache.derby.jdbc.EmbeddedDriver
jdbc:derby:derbyDB/db; create=true
sa
org.hibernate.dialect.HSQLDialect
false
org.hibernate.transaction.JDBCTransactionFactory
org.hibernate.cache.HashtableCacheProvider
create
79

Mapping-XML-Datei für das Mapping von Algorithm-Objekten
(“Algorithm.hbm.xml“)
KAPITEL 8. ANHANG
80

KAPITEL 8. ANHANG
Mapping-XML-Datei für das Mapping von InputData-Objekten
(“InputData.hbm.xml“)
Mapping-XML-Datei für das Mapping von Config-Objekten (“Config.hbm.xml“)
81

KAPITEL 8. ANHANG
Mapping-XML-Datei für das Mapping von User-Objekten (“User.hbm.xml“)
Mapping-XML-Datei für das Mapping von User-Objekten (“User.hbm.xml“)
Mapping-XML-Datei für das Mapping von RessourcePart-Objekten
(“RessourcePart.hbm.xml“)
82

KAPITEL 8. ANHANG
Mapping-XML-Datei für das Mapping von Context-Objekten (“Context.hbm.xml“)
Mapping-XML-Datei für das Mapping von OutputData-Objekten
(“OutputData.hbm.xml“)
83

KAPITEL 8. ANHANG
Mapping-XML-Datei für das Mapping von Experiment-Objekten
(“Experiment.hbm.xml“)
Mapping-XML-Datei für das Mapping von ExpSequence-Objekten
(“ExpSequence.hbm.xml“)

KAPITEL 8. ANHANG
’-//Hibernate/Hibernate Mapping DTD 3.0//EN’
’http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd’>
Mapping-XML-Datei für das Mapping von Schema-Objekten (“Schema.hbm.xml“)
Mapping-XML-Datei für das Mapping von IDContainer-Objekten
(“IDContainer.hbm.xml“)
85

KAPITEL 8. ANHANG
86

Literaturverzeichnis
[Merz04] Vorlesung: Algorithmen, W.Merzenich, Uni-Siegen 2004
[Kel1] Software-Architekturen, Vorlesung Softwaretechnik II, Udo Kelter; 2003
[Kel2] Vorlesung Datenbanken, Udo Kelter; 2007
[Kel3] Vorlesung Datenbanken II, Udo Kelter; 2007
[Sun99] Java Look and Feel Design Guidelines, Inc. Sun Microsystems 1999
[Ba07] Java 6 Anwendungen programmieren. Von der GUI-Programmierung bis
zur Datenbank-Anbindung, Helmut Balzert, W3l 2007
[ZiBa05] Apache Derby - Off to the Races, Paul C. Zikopoulos, George Baklarz und
Dan Scott 2005
[BaKi05] Java persistance with hibernate, Christian Bauer und Gavin King, Manning
Publications Co. 2005
[BeHa07] Hibernate, Robert F. Beeger, Arno Haase, Stefan Roock, Dpunkt Verlag
2007
[HiKe07] Hibernate und die Java Persistence API, Robert Hien, Markus Kehle, Entwickler.Press
Verlag 2006
[SaSa03] Datenbanken und Java, Gunter Saake und Kai-Uwe Sattler, Dpunkt Verlag
2003
[SaSa01] JDBC in der Praxis. Datenbankanwendungen in Intranet und Internet, Rainer
Klute , Addison Wesley Verlag; 2001
[GoWe01] Java als erste Programmiersprache,
Joachim Goll, Cornelia Weiß und Frank Müller, Teubner Verlag 2001
[Ho00] Datenbanken programmieren mit JDBC in 21 Tagen,
Ashton Hobbs, Pearson Education 2000
[Be02] Verteilte Systeme. Client-Server-Computing für Studenten und Praktiker,
Günther Bengel, Vieweg Verlag 2002
[DeCz01] Netzwerkprogrammierung unter LINUX und UNIX,
Andrew Deitsch, David Czarnecki, O’Reilly Media 2001
87

Literaturverzeichnis
[FiMü02] Java Internationalization,
Stefan Fischer, Walter Müller, Hanser Fachbuch 1998 Java Internationalization
[He03] Grundlegende Algorithmen,
Folker Heun, Vieweg Verlag 2003
[Sch01] Algorithmik,
Uwe Schöning, Spektrum Akademischer Verlag 2001
88

Erklärung
Literaturverzeichnis
Ich versichere, dass ich meine Arbeit selbständig verfasst und keine anderen
als die angegebenen Quellen und Hilfsmittel benutzt sowie alle Stellen, die
wörtlich oder sinngemäß aus Veröffentlichungen entnommen worden sind, als
solche kenntlich gemacht habe.
Siegen, Juli 2007
89