Niederlassung Regensburg. Diplomarbeit

Diplomarbeit – SS 99/00 -1- -_______________________________________________________________________________________________________________________...
3 downloads 0 Views 1MB Size
Diplomarbeit – SS 99/00

-1-

-____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Hochschule für Technik, Wirtschaft und Sozialwesen Regensburg (FH) Fachbereich Informatik

Fa. Heitec GmbH / Niederlassung Regensburg

Diplomarbeit Eine Internet-/Intranet-Anwendung zur Automatisierung von Projektkontrollen

Christian Schmidbauer 30.11.1999

Betreuer: Prof. Jürgen Sauer Hochschule für Technik, Wirtschaft und Sozialwesen Regensburg (FH) Dipl.-Math. Thomas Aigner Firma Heitec GmbH / Niederlassung Regensburg ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

-2-

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Inhaltsverzeichnis 1

Einleitung................................................................................... 3

2

Was heißt „Review“?................................................................ 4

3

Eigentliche Problemstellung.................................................... 5

4

Kurze Einführung in die Programmiersprache Java.............. 6 4.1

Grundlagen.......................................................................................6

4.2

Eigenschaften von Java....................................................................6

4.2.1

4.2.1.1

Variablen.......................................................................... 7

4.2.1.2

Escape-Sequenzen............................................................ 9

4.2.1.3

Vergleichsoperatoren........................................................9

4.2.1.4

Kommentare................................................................... 10

4.2.2

5

Einige besondere Sprachelemente........................................... 7

Packages ................................................................................ 10

4.3

Applikationen und Applets............................................................ 11

4.4

Objektorientierte Elemente von Java.............................................14

4.4.1

Klassen und Instanzen............................................................ 15

4.4.2

Methoden und Attribute......................................................... 15

4.4.3

Vererbung...............................................................................16

4.4.4

Interfaces................................................................................ 16

Die Client-Server-Architektur.................................................. 17 5.1

Java und Datenbanken / JDBC ..................................................... 19

5.1.1

Funktionsweise von Datenbankzugriffen mit JDBC..............20

5.1.2

Die JDBC-API........................................................................23

5.2

RMI (Remote Method Invocation) ............................................... 25

5.2.1

Idee von RMI..........................................................................27

5.2.2

Architektur eines RMI-Systems............................................. 28

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

-3-

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

6

5.2.2.1

Client und Server............................................................29

5.2.2.2

Stub und Skeleton...........................................................29

5.2.2.3

Remote Reference-Schicht............................................. 31

5.2.2.4

Transportschicht............................................................. 31

Das „Review“-Tool.................................................................. 32 6.1

Grundsätzlicher Aufbau................................................................. 32

6.1.1

Netzwerkstruktur....................................................................32

6.1.2

Verzeichnisstruktur................................................................ 33

6.1.3

Server..................................................................................... 39

6.1.3.1

Embedded SQL mit SQLJ.............................................. 41

6.1.3.2

Wie arbeitet SQLJ?.........................................................41

6.1.3.3

Kompilierung von SQLJ-Programmen........................... 44

6.1.3.4

Interview von der Zeitschrift JavaSpektrum mit Jeremy Burton von der Oracle Corporation................... 46

6.1.3.5

Verwendete Bibliotheken............................................... 48

6.1.3.6

Klassenvariablen.............................................................49

6.1.3.7

Klassenfunktionen.......................................................... 50

6.1.3.8

Das Hauptprogramm.......................................................52

6.1.3.9

Aufbau der SQLJ-Dateien.............................................. 55

6.1.4

Interfaces und Datenstrukturen.............................................. 63

6.1.5

Client...................................................................................... 71

6.1.5.1

Oberflächendesign und Layout von Java........................72

6.1.5.2

RMI-Handling im Client.................................................81

6.1.6 7

8

Tools.......................................................................................83

Die Review-Datenbank............................................................ 88 7.1

Importierung der Daten..................................................................88

7.2

Ursprüngliche Datenbank.............................................................. 89

7.3

Erweiterung der vorhandenen Datenbank......................................91

Beschreibung des Review-Tools........................................... 94

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

-4-

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.1

Login.............................................................................................. 95

8.2

Benutzerverwaltung....................................................................... 95

8.3

MainSelection................................................................................ 96

8.4

Administration-Panel..................................................................... 99

8.5

Admin Global Catalog................................................................. 100

8.5.1 8.6

Admin Special Catalog................................................................ 103

8.6.1

Admin Special Topics.......................................................... 104

8.6.2

Catalogs................................................................................105

8.7

9

Admin Topics.......................................................................102

Admin Projects.............................................................................106

8.7.1

Project Questions................................................................. 108

8.7.2

Admin Project Topics.......................................................... 109

8.8

Administration............................................................................. 110

8.9

Admin Document Type................................................................112

8.10

Admin Release Date.................................................................. 113

8.11

Select Project............................................................................. 114

8.12

Project Invitations...................................................................... 115

8.12.1

Checkliste...........................................................................118

8.12.2

Participants.........................................................................119

8.12.3

Documents..........................................................................120

Zusammenfassung und Ausblick........................................ 121

Abbildungsverzeichnis.................................................................122 Tabellenverzeichnis......................................................................123 Literaturverzeichnis......................................................................124

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

-5-

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

1 Einleitung Das Internet als modernes Medium der Informationsverbreitung gewinnt zunehmend an Bedeutung. Mit dem täglich größer werdenden Angebotsvolumen öffnet es sich einem zunehmend vielschichtigeren Publikum. Während noch vor einem Jahr hauptsächlich Informatik-Interessierte das Internet nutzten, wird es heute mit Themenbereichen, die von der aktuellen Tagesschau über Musikzeitschriften bis hin zu Kochrezepten reichen, von vielen Gruppen genutzt.

Seit gegen Ende 1995 die Programmiersprache Java eingeführt wurde, hat Java das Internet in Windeseile erobert. Das im Rahmen dieser Diplomarbeit entwickelte Programm „Review“ ermöglicht es Siemens-Mitarbeitern aus aller Welt auf die Daten eines bei Siemens in Regensburg postierten Oracle-Servers zuzugreifen und gegebenenfalls zu verändern.

Die für das Programm „Review“ gewählte Programmiersprache ist Java. Java ist besonders für diese Aufgabe geeignet, da die Sprache plattform- und systemunabhängig ist, was impliziert, daß Java-Programme auf beliebigen WWW-Clients mit JavaUnterstützung laufen. Ferner weist Java durch seine integrierte Internetunterstützung den Vorteil auf, daß der Programmierumfang im Vergleich zu herkömmlichen Programmiersprachen wesentlich geringer ist. Im folgenden werden zunächst die Merkmale und Besonderheiten von Java als Programmiersprache für das Internet angeführt. Wie die Client-Server-Kommunikation funktioniert, wird unter dem Punkt Client-Server-Architektur erläutert. Der zweite Hauptteil der Arbeit beschäftigt sich mit dem Aufbau und der Bedienung des Programms „Review“ und zeigt die verwendete Programmiertechnik auf.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

-6-

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

2 Was ist „Review“? Ganz am Anfang stellt sich für den Leser noch die Frage: Was ist „Review“ überhaupt, bzw. in welchem Bereich wird ein solches Tool eingesetzt? Die Erstellung von Reviews in der Entwicklungsphase eines Produkts ist eine einflußreiche Methode, um die Qualität der Produkte und des Herstellungsprozesses zu erhöhen.

Die wichtigsten Ziele von Reviews sind: ●

frühes Erkennen und Korrektur von Abweichungen in der Entwicklungsphase eines Produktes



Vermeidung von Fehlern infolge von sofortigen Feedbacks an den Autor



Reduktion von Fehlerbehebungskosten



Übermittlung von gewonnenen Kenntnissen an andere Review-Teilnehmer und Verbesserung der internen Schnittstellen



Erfahrungsaustausch zwischen den Projekt-Teams



Minimierung von Zeit in der Entwicklungsphase durch die Vermeidung von großartigen Änderungen

Tabelle 1: Ziele des Review-Tools

Reviews sind formale Prozesse, die wie folgt ablaufen: ●

Das Review wird geplant



Definierte Ziele, Vorbedingungen, Verantwortliche, unterstützende Dokumente usw. werden festgelegt



Die entsprechenden Prozeduren für das Review werden schriftlich festgelegt



Die Ergebnisse und die Korrektur-Aktionen werden dokumentiert

Tabelle 2: Prozeß eines Reviews Um überhaupt Auswertungen und Ansätze zur Verbesserung mancher Arbeitsgänge machen zu können, war die Generierung separater Checklisten eine sinnvolle Methode. Solche Checklisten enthalten allerhand Fragen zu entsprechenden Arbeitsgängen. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

-7-

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Auf diese und die Funktionsweise des Programms wird aber im Punkt 8 noch tiefer eingegangen. Zunächst soll das als Grobüberblick über den Sinn und die Funktionsweise eines solchen Review-Tools reichen.

3 Eigentliche Problemstellung Das Programm „Review“ lag mir vor dem Beginn meiner Diplomarbeit schon als Access-Tool vor. Dieses Tool war bereits zwei Jahre bei Siemens im Einsatz, bevor man sich entschloß, einiges Kapital in eine Internet-Version zu investieren. Obwohl es ja heutzutage mit den vorhandenen Tools kein Problem mehr darstellt, eine Access-Anwendung als Internet-Applikation laufen zu lassen, ließ man sich doch dazu „verleiten“, eine komplett neue Implementierung der Software in Auftrag zu geben. Ein triftiger Grund für eine komplette Neuimplementierung waren auch einige Programmerweiterungen, die in Access nicht ohne weiteres realisiert werden hätten können. Diese zusätzlichen Punkte werden im weiteren Verlauf der Arbeit in den Abschnitten „Programmbeschreibung“ und „Besonderheiten der Implementierung“ näher beschrieben. Ein weiterer Grund waren die großen Datenmengen, die mit Access bekanntermaßen nur schwer bzw. mit viel Geduld verarbeitet werden können. Das ganze sollte nun auf Oracle 8i umgestellt werden, welches keine Schwierigkeiten mit großen Datenmengen hat. Das Zusammenspiel zwischen Java-Applets bzw. -Servlets und Oracle ist zur Zeit die unumstrittene und führende Verfahrensweise im Wettbewerb um die „Interaktive Kommunikation“. Im Anschluß folgt eine kurze Einführung in die Programmiersprache Java und deren Besonderheiten.

4 Kurze Einführung in die Programmiersprache Java 4.1 Grundlagen Die folgende Einführung in die Programmiersprache Java setzt die Kenntnis einer Programmiersprache und Basiswissen über objektorientierte Programmierung voraus. Sie dient dazu, die Programmierungen im Rahmen dieser Diplomarbeit nach____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

-8-

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

vollziehen zu können. Die Programmierumgebung, die ich beim Entwickeln des „Review-Tools“ verwendete, bezog sich auf einen Linux-Server, Exceed für NT, den Editor Emacs, den JDK 1.1.7 bzw. JDK 1.2.1 und einen Oracle-Server mit der sich darauf befindlichen Oracle-Version 7.2.2.4.0.

Im folgenden werden zunächst grundlegende Eigenschaften und objektorientierte Elemente von Java vorgestellt.

4.2 Eigenschaften von Java Java ist eine Programmiersprache, die auf den Grundlagen von C++ aufbaut. Im Vergleich zu C++ wird in Java die Objektorientierung weiterentwickelt. Hierdurch ist es dem Programmierer in Java möglich, flexible modulare Programme zu schreiben, außerdem wird die Wiederverwendbarkeit des Codes erhöht. 1 Java eignet sich durch die integrierten Netzwerkfunktionen, wie schon erwähnt, besonders für die Internet-Programmierung. Einfache Internetzugriffe sind in Java, wie auch im folgenden erklärt wird, durch wenige Programmierzeilen zu realisieren. Im Vergleich zu anderen Sprachen weist Java folgende Besonderheiten auf, die größtenteils als Vorteile gewertet werden können: ●

Einfachheit: Die Sprache ist kompakt und vermeidet durch den Wegfall von Mehrfachvererbungen, Zeigern und Zeiger-Arithmetik viele beim Programmieren schwer lokalisierbare Fehler. Aufgrund der Ähnlichkeit mit C++ ist die Sprache für Programmierer mit C++ Kenntnissen leicht zu erlernen.



Portabilität und Plattformunabhängigkeit: In Java geschriebene und kompilierte Programme können auf allen Rechnertypen und Betriebssystemen ausgeführt werden, sofern eine Java-Umgebung existiert.



Sicherheit: In Java sind Sicherheitsmechanismen eingebaut, die verhindern, daß in Java geschriebene Programme unbefugt Daten vom Rechner, auf dem die Programme ausgeführt werden, lesen und manipulieren können.



Multithreading: Java unterstützt die Nutzung von Threads, die Prozesse kontinu-

1 Vgl. Lemay/Perkins (1996), S.35 ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

-9-

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

ierlich und unabhängig voneinander ausführen. ●

Robustheit: Durch den Wegfall von Mehrfachvererbungen, Zeigern, Zeiger-Arithmetik und die Änderung des Speichermanagements können relativ robuste Programme entwickelt werden.

4.2.1 Einige besondere Sprachelemente 4.2.1.1 Variablen Die in Java enthaltenen Datentypen unterscheiden sich kaum von denen der herkömmlichen Programmiersprachen. Sie weisen allerdings größtenteils den Vorteil auf, daß ihr Wertebereich an die heutigen hohen Anforderungen an eine Programmiersprache angepaßt sind.

Folgende Basisdatentypen (Primitivtypen) sind in Java enthalten:2 Datentyp

Größe

Wertebereich

Byte

1 Byte

-128 bis 127

Short

2 Byte

-32768 bis 32767

Int

4 Byte

-2147483648 bis 214748367

Long

8 Byte

-9223372036854775808 bis 9223372036854775807

Float

4 Byte

Max.: ±3.40282347e+38 Min.: ±1.40239846e-45

Double

8 Byte

Max.: ±1.79769313486231570e+308 Min.: ±4.94065645841246544e-324

Char

2 Byte

Unicode Zeichen

Boolean

1 Byte

True oder False

Tabelle 3: Datentypen und Wertebereiche in Java Bei der Benutzung von Gleitpunktzahlen ist zu beachten, daß sie auf älteren Rechnern, deren Prozessoren die Bearbeitung von Gleitpunktzahlen nicht unterstützen, sehr langsam laufen. Die Gleitpunktzahlentypen float und double werden in Java 2 Peter Norton's Guide to Java Programming ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 10 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

nach der Norm IEEE 754 bearbeitet. Für den Datentyp char verwendet Java nicht den üblichen ASCII-Zeichensatz, sondern den Unicode-Zeichensatz. In diesem Unicode-Zeichensatz sind Sonderzeichen und länderspezifische Zeichen vieler Länder integriert.3 Als Nachteil ergibt sich, daß ein Zeichen zwei Byte lang ist, anstatt wie bei dem ASCII-Zeichensatz ein Byte.

4.2.1.2 Escape-Sequenzen Steuerzeichen in Variablen vom Typ char und vom Typ String - der Erweiterung von char - werden wie folgt dargestellt:4

Beschreibung der Escape-Sequenz Zeichen

Escape-Sequenz

Ausgabe

"A"

A

‘a’

a

Rückschritt (Backspace)

‘\b’

Horizontaler Tabulator

‘\t’

Zeilenvorschub

‘\n’

Formularvorschub

‘\f`’

Wagenrücklauf

‘\r’

Doppeltes Anführungszeichen

‘\"’

"

Einfaches Anführungszeichen

‘\’’



Backslash

‘\\’

\

Oktal

‘\45’

%

Unicode Zeichen

‘\u2122’



Tabelle 4: Escape-Sequenzen in Java

4.2.1.3 Vergleichsoperatoren

3 Vgl. Java Unleashed 4 Vgl. Peter Norton's Guide to Java Programming ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 11 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Um Werte zu vergleichen, stellt Java folgende Vergleichsoperatoren zur Verfügung:5 Operator

Beschreibung




Größer als

=

Größer als oder gleich

==

Gleich

!=

Nicht gleich

Tabelle 5: Vergleichsoperatoren in Java

Die Ausdrücke mit den Vergleichsoperatoren geben die booleschen Werte true oder false zurück. Um komplexere Vergleiche zu realisieren, gibt es die logische AND (&&), OR (||) und NOT (!) Verknüpfung.

4.2.1.4 Kommentare In Java kann man auf drei Arten Kommentare in den Quellcode einfügen. Mehrzeilige Kommentare werden zwischen /* und */ gesetzt. Alles, was sich zwischen den beiden Befehlen befindet, wird beim Übersetzen des Quellcodes ignoriert. Es ist nicht zulässig, Kommentare ineinander zu verschachteln. Die zweite Art ist der einzeilige Kommentar. Dafür wird in einer Zeile ein doppelter Slash (//) benutzt. In der Zeile werden sämtliche Zeichen hinter dem doppelten Slash beim Kompilieren ignoriert. Bis hierher war die Kommentierung identisch mit der in C++. Die letzte Kommentarart dient der automatischen Dokumentationserzeugung und wird zwischen /** und */ geschrieben. Mit dem Programm javadoc, das mit dem JDK ausgeliefert wird, können anschließend Dokumentationen im HTML-Format erzeugt und ähnlich aufgebaut werden wie die Java API.

4.2.2 Packages

5 Vgl. Java Unleashed ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 12 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Packages sind Sammlungen von Klassen, die nach logischen Gesichtspunkten gruppiert sind.6 Sie werden mit dem Befehl „import“ in ein Programm eingebunden. Im Programm kann dann auf die Klassen und Methoden der importierten Packages zugegriffen werden. Eine Reihe von Grundfunktionen ist schon in den mit Java ausgelieferten Packages enthalten. Man erkennt die Standard Java Packages daran, daß sie mit „java." anfangen. Es ist darüber hinaus möglich, eigene Packages zu erstellen. Dabei muß man allerdings beachten, daß diese Packages auf dem Rechner vorhanden sein müssen, auf dem Programme mit selbst erstellten Packages verwendet werden sollen. Der Packagename ist ein Dateiname, bei dem die Zeichen Slash (/) bei Unix- und Linux-Systemen bzw. Backslash (\) bei MS Windows durch einen Punkt ersetzt werden.7 Es ist möglich, mehrere Klassen auf einmal zu importieren, indem man das Zeichen "*" als Joker benutzt, der Befehl sieht dann wie folgt aus:

import java.util.*;

Wie Packages im Rahmen des Review-Tools verwendet wurden, wird an späterer Stelle noch erklärt.

4.3 Applikationen und Applets Zum grundsätzlichen Verständnis möchte ich in diesem Abschnitt kurz den Unterschied zwischen Applikationen und Applets deutlich machen, unabhängig vom entsprechenden Projekt.

Programme, die in Java geschrieben sind, können in zwei Gruppen eingeteilt werden, in die Applikationen und die Applets. Applikationen sind eigenständige Programme, die unabhängig von einem WWW-Browser gestartet werden können. Applets sind Java-Programme, die für WWW-Seiten geschrieben sind. Beim Aufruf der WWW6 Vgl. Special Edition Using Java 7 Vgl. Special Edition Using Java ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 13 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Seite mit einem javafähigen Browser wird das Applet gestartet und kann u. a. dazu genutzt werden, die Seite dynamisch und interaktiv zu gestalten.

Als nächstes werden Java Programme, die als Applet geschrieben sind, beispielhaft untersucht. Ein Applet ist eine Anwendung, die für die Ausführung in einem Webbrowser auf einer HTML-Seite gedacht ist. Bei einem Java-Applet, das in einer HTML-Datei im WWW referenziert (d.h. mit einem Applet-Tag auf der HTML-Seite plaziert und über Parameter-Tags mit Parametern versorgt) ist, wird der ausführbare Programmcode in den Arbeitsspeicher des aufrufenden Rechners geladen und dort vom JavaInterpreter des WWW-Browsers ausgeführt. Applets unterscheiden sich in einer Reihe von Punkten von normalen Applikationen. Einer der wichtigsten ist, daß sie bei der Ausführung einer Reihe von Sicherheitsbeschränkungen unterliegen, die bei der Entwicklung von umfassender Funktionalität auch Probleme bereitet. Der größte Unterschied zwischen einem Applet und einer Applikation besteht darin, daß das Applet keine main()-Funktion besitzt. Es kann also nicht direkt gestartet werden. Vielmehr ruft der Browser bestimmte Methoden der Applet-Superklasse zu bestimmten Zeiten und genau definierten Bedingungen auf. Diese Methoden müssen vom Anwendungsentwickler implementiert werden. Da ein Applet über das WWW geladen werden muß, sollte es sehr "klein" sein, damit das Laden der Seite nicht unnötig lange dauert. Aus diesem Grund sollten alle von dem Applet benutzten Dateien und die Applet-Klasse selbst in ein JAR-Archiv verlagert werden. So werden alle Dateien in einem HTTP-Request komprimiert und wesentlich effizienter übertragen, als das im konventionellen Stil der Fall wäre.8 Um Applets auszuführen, kann auch statt einem WWW-Browser der Appletviewer, der mit dem JDK ausgeliefert wird, verwendet werden. Als erstes wird, wie gesagt, eine HTML-Seite benötigt, in der das Java-Applet aufgerufen wird. Die HTML-Seite könnte in etwa wie folgt aussehen:

8 http://iundg.informatik.uni-dortmund.de ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 14 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Meine Diplomarbeit

Dieses HTML-Dokument zeigt durch den Befehl auf ein vorhandenes Applet. Dieses kann in dem durch Breite und Höhe angegebenen Bereich angezeigt werden. Wird das HTML-Dokument von einem javafähigen Browser aufgerufen, lädt dieser das Applet und führt es aus.

Ein Applet zu dieser HTML-Seite kann zum Beispiel die Gestalt haben:

import java.awt.*; import java.applet.*;

public class MeineDiplomarbeit extends Applet { public void paint(Graphics g) { g.drawString("Meine Diplomarbeit",20,40); } }

Als erstes werden die Packages java.awt.* und java.applet.* importiert. Das Package java.awt.* enthält Methoden für die Grafikausgabe, die benötigt werden, um dem Applet die Fähigkeiten zu geben, etwas auf der HTML-Seite auszugeben. Es ist nämlich nicht möglich, wie bei einer Applikation auf die Standard____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 15 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

ausgabekonsole zu schreiben, um eine Ausgabe auf der HTML-Seite zu erzielen. Die Klassen aus java.applet.* müssen importiert werden, da jedes Applet von dieser Klasse abgeleitet werden muß.

Einige wichtige Methoden, die die Klasse java.applet.Applet enthält und die in fast jedem Applet gebraucht werden, sind:



void init(): Wird automatisch beim Initialisieren des Applets aufgerufen.



void start(): Wird automatisch bei der Aktivierung und Reaktivierung des Applets aufgerufen.



void stop(): Wird automatisch aufgerufen, wenn das Applet im Moment nicht angezeigt wird. Bei erneuter Anzeige wird es mit der Methode start() reaktiviert.



void destroy(): Wird automatisch zur Zerstörung des Applets und zur Freigabe der Ressourcen aufgerufen.



void paint(Graphics): Zeichnet den Applet Bereich und wird von init (), beim Verschieben des Fensters und wenn das Fenster mit dem Applet in den Vordergrund gebracht wird, automatisch aufgerufen. Die Methode ist für die Grafikausgabe des Applets zuständig.

Als nächstes wird die Klasse MeineDiplomarbeit definiert. Die Klasse erweitert die Klasse Applet, die die Grundfunktionen eines Applets enthält. Dann wird die Methode paint mit einem Parameter vom Typ Graphics definiert. Diese Methode ist schon in dem importierten Package enthalten und wird erweitert. Sie zeichnet den Bereich des Applets. Der Parameter vom Typ Graphics liefert einen Bezug zum aktuellen Grafikobjekt. In dieses Grafikobjekt wird dann der Text mit der Methode drawString(String, int x, int y) geschrieben. Als Stringvariable gibt man den auszugebenen String an, und die Integervariablen beschreiben die x- und yKoordinate der Ausgabe in dem Anzeigefeld des Applets.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 16 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

4.4 Objektorientierte Elemente von Java Da große Java-Projekte aus einer Vielzahl von Klassen bestehen, halte ich es vollständigkeitshalber für notwendig, auf diese Objektform kurz einzugehen und den Zweck solcher Klassen zu erläutern.

4.4.1 Klassen und Instanzen Klassen werden mit class ClassName{} definiert. Um mit einer Klasse arbeiten zu können, muß man eine Instanz - häufig auch als Objekt bezeichnet - einer Klasse erstellen. Eine Klassenvariable ist eine abstrakte Darstellung eines Objekts; eine Instanz ist dessen konkrete Darstellung. Von Klassen können mehrere Instanzen erzeugt werden, von denen jede Instanz eigene Instanzvariablen besitzt. Dieses Prinzip nennt sich Datenkapselung. Eine Instanz von einer Klasse wird wie folgt gebildet:

ClassName nameOfInstance = new ClassName();

Es wird eine Variable vom Typ ClassName erzeugt. Hierbei handelt es sich um eine Variable, die eine Instanz vom Typ ClassName aufnehmen kann, dieser Variablen wird eine Instanz von ClassName zugewiesen. In den runden Klammern können Werte angegeben werden, die beim Initialisieren der Instanz gebraucht werden, falls das in der Klasse vorgesehen ist. Bei der Hauptklasse, die bei den Applets und Applikationen aufgerufen wird, wird durch den Aufruf eine Instanz der jeweiligen Klasse erstellt.

4.4.2 Methoden und Attribute ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 17 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Jede größere Klasse, die in Java geschrieben wird, enthält Methoden und Attribute. Methoden sind Funktionen, die in den Klassen definiert werden. Sie können u. a. Attribute ändern, mit Methoden aus anderen Instanzen kommunizieren und den Status einer Instanz ausgeben. Methoden kann man am einfachsten an einem Beispiel erklären. Man kann sich eine Klasse "Autos" vorstellen. Die Autos können fahren oder stehen und eine bestimmte PS-Zahl haben. Des weiteren können sie gestartet oder ausgeschaltet werden. Die Attribute liefern Angaben über die Zustände der Instanz, z. B. 100 PS, fahrend. Als Methode kann das Anlassen des Motors und das Ausschalten des Motors definiert werden, wobei beim Aufruf dieser Methode das Attribut Motor an/Motor aus geändert wird.

4.4.3 Vererbung Die Vererbung ist ein wichtiges Konzept der objektorientierten Programmierung. Durch sie erreicht man, daß Klassen in einer Vererbungsstruktur hierarchisch angeordnet sind und Methoden und Variablen von den übergeordneten Klassen erben. Die Realisation erfolgt in der Klassendefinition durch das Schlüsselwort extends und die Angabe der Superklasse. In Java ist es nicht möglich, eine Mehrfachverbung das Erben von mehreren Superklassen - zu erstellen. Als Ersatz existieren in Java Schnittstellen, die Masken mit Eigenschaften bieten, die in andere Klassen implementiert werden sollen.9 Das Erben von Variablen kann besonders bei der Erstellung einer Datenstruktur sinnvoll eingesetzt werden.

4.4.4 Interfaces Bei einem Interface werden abstrakte Methoden und Konstanten verbunden. Abstrakte Methoden sind noch nicht implementierte Methoden, die in der Klasse, in die das jeweilige Interface importiert wird, konkretisiert werden. Diesen Vorgang kann man sich wie das Ausfüllen einer Schablone vorstellen.10 Das folgende Beispiel 9

Vgl. Lemay/Perkins (1996), S. 383

10 Vgl. Kühnel (1996), S. 28 ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 18 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

verdeutlicht die Benutzung einer Schnittstelle:

public interface ITextAusgabe { static final String string = "Linux"; void textAnzeige(); } class SuSE implements Textausgabe { public void textAnzeige() { System.out.println("SuSE-" + string); } } class RedHat implements Textausgabe { public void Textanzeige() { System.out.println("RedHat-" + string); } } public class MyInterface { public static void main(String[] args) { SuSE linux1 = new SuSE(); RedHat linux2 = new RedHat(); linux1.Textanzeige(); linux2.Textanzeige(); } } Das Interface ITextausgabe enthält eine Konstante mit dem Namen string, die mit dem Inhalt "Linux" vordefiniert wird. Des weiteren beinhaltet sie die abstrakte Methode textAnzeige(). Die Klassen SuSE und RedHat implementieren das Interface. Beide Klassen konkretisieren die abstrakte Methode Textanzeige. In der main-Methode werden dann Instanzen von den Klassen erstellt, und die Schnittstellenmethoden aufgerufen. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 19 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

5 Die Client-Server-Architektur Von einer Client-Server-Architektur spricht man, wenn Server und intelligente Workstations über ein Netzwerk miteinander verbunden sind. Die Client-Server-Architektur nutzt das Potential des Servers sowie das des Client- Computers, um die Aufgaben im Netz zu erledigen. Dazu werden die Aufgaben folgendermaßen auf den Client und den Server verteilt. Die Serverkomponente ist u. a. für die zentrale Datenspeicherung und Zugriffskontrollen auf die Daten verantwortlich, die Clientkomponente verarbeitet die Daten und bereitet sie auf. Bei dem Client-Computer handelt es sich um eine Single-User-Arbeitsstation, die die benötigten Netzwerkfunktionalitäten sowie geeignete Schnittstellen zur Kommunikation mit dem Server bereitstellt. Der Server bearbeitet Aufträge von einem oder mehreren Benutzern, stellt die Netzwerkfunktionalitäten zur Verfügung und unterstützt die Schnittstellen zur Kommunikation mit den Clients.11 Die Kommunikation beginnt in der Regel mit einer Anfrage des Clients, diese wird dann vom Server bearbeitet, und das Ergebnis wird an den Client zurückgeschickt. Das Prinzip einer solchen Client-Server-Architektur zeigt folgende Abbildung:

Anfrage

Rückgabe

Client

WWW-Server (Apache)

Abbildung 1: Client-Server-Architektur

11 Vgl. Client/Server Computing ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 20 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Da die Funktionsweise des Internets auf der Client-/Server-Architektur aufsetzt, sollen zunächst einige Begriffe geklärt werden, die im direkten Zusammenhang mit dieser Architektur stehen: ●

Server: Der Server oder WWW-Server ist ein Programm, das ständig auf einem Rechner läuft und auf Anfragen von den verschiedenen Clients im Internet reagiert. Es stellt Informationen in Form von HTML-Dokumenten zur Verfügung, die unter Einsatz eines Browsers über das Netzwerk geladen werden können.



Client: Der Client im WWW wird durch den Browser eines Benutzers repräsentiert, der über das Internet auf einen WWW-Server zugreift, um ein bestimmtes Dokument zu laden.



Browser: Der Browser ist ein Programm, mit dem es möglich ist, HTML-Dokumente über das Internet zu laden und anzuzeigen. Mit Hilfe des Browsers kann im Internet navigiert werden.



HTML: HTML steht für Hyper Text Markup Language. Es handelt sich bei HTML um eine standardisierte Dokumentbeschreibungssprache, mit der Dokumente für das Internet verfaßt werden können. Neben der formatierten Darstellung von Text können Grafiken in ein HTML-Dokument eingebunden werden. Des weiteren werden eine Reihe von interaktiven und multimedialen Elementen unterstützt (z.B. CGI-Skripte, Java, JavaScript, ...). Mit Hilfe von Hyperlinks kann zwischen Dokumenten im Internet navigiert werden.



HTTP: HTTP steht für Hyper Text Transfer Protokoll und stellt ein Protokoll dar, über das Client und Server im WWW miteinander kommunizieren. Es bietet zudem Möglichkeiten, andere Internet-Dienste (z.B. FTP oder Telnet) zu integrieren.



URL: Hinter einer URL (Uniform Ressource Locator) verbirgt sich die Adresse eines HTML-Dokuments oder allgemeiner einer Datei im Internet.



Port: Damit auf einem Rechner mehrere Server (z.B. WWW- und FTP-Server) gleichzeitig laufen können, verfügt jeder Server über einen für den Rechner eindeutigen Port. Bei einem Port handelt es sich um eine Softwareschnittstelle, der die aus dem Internet kommenden Pakete zugeordnet werden. Als Standardport für

den FTP-Dienst hat sich z.B. Port 21 durchgesetzt.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 21 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

5.1 Java und Datenbanken / JDBC JDBC (Java Database Connectivity) wurde als Standard definiert, um aus Java-Programmen heraus über SQL-Befehle auf relationale Datenbanksysteme zugreifen zu können SQL ist ein auf nahezu allen Datenbanken zu benutzender Abfrage-Standard, mit dessen Befehlen man Operationen auf relationalen Datenbanken, also Datenbanken, die ihren Inhalt in zweidimensionalen Tabellen verwalten, auslösen kann. Im Prinzip ist JDBC mit dem bereits bekannten ODBC-Standard von Microsoft zu vergleichen, aufgrund der Java-Implementierung aber die plattformunabhängige Variante. Der Datenbankzugriff erfolgt unabhängig vom verwendeten DBMS (Database Management System), d.h. der Client, muß sich nicht um Eigenheiten der verwendeten Datenbank kümmern. Alle DBMS-spezifischen Details übernimmt ein JDBCTreiber, der als Java-Klasse von Datenbankherstellern oder Dritten angeboten wird. Voraussetzung für die Benutzung von JDBC mit einer bestimmten Datenbank ist also das Vorhandensein eines JDBC-Treibers. Die folgende Abbildung zeigt die Anbindung eines Java-Applets an eine Datenbank mit JDBC, die über das Internet miteinander kommunizieren. Das Applet wird zunächst von einem WWW-Server über einen Browser auf einen Client geladen. Nach dem Start des Applets auf dem Client hat dieser die Möglichkeit, über die Datenbestände einer Datenbank zu verfügen.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 22 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

WWW-Server Java-Applet

JDBC

Client-Maschine

Datenbank-Server

Netzwerk (Internet)

Server-Maschine

Abbildung 2: Anbindung eines Java-Applets

Um eine Verbindung zu einer Datenbank aus einem Java-Applet heraus herzustellen, ist es notwendig, daß der Browser die Funktionalitäten der JDBC-API unterstützt, die bei der Entwicklung des Java-Programms verwendet wurden.

5.1.1 Funktionsweise von Datenbankzugriffen mit JDBC Die JDBC-API setzt sich aus einer Reihe von Klassen und Interfaces zusammen, die ausschließlich in Java implementiert sind. Abgelegt sind diese im package java.sql der Klassenbibliothek des JDK. Diese Ansammlung von Klassen und Interfaces stellen Methoden zur Verfügung, mit denen Abfragen oder Datenmanipulationen auf dem Datenbestand einer Datenbank ausgeführt werden können. Weiter bietet JDBC die Möglichkeit, die Ergebnisse solcher Datenbankoperationen entgegenzunehmen, um sie anschließend verarbeiten zu können. Die Art und Weise, wie diese Zugriffe mittels der JDBC-API in Java realisiert werden, ist dabei unabhängig von dem darunter liegenden Datenbanksystem. Dadurch ist eine Unabhängigkeit zwischen einer JavaAnwendung bzw. einem Java-Applet und dem Datenbanksystem gewährleistet. Die Verbindung zu einem Datenbanksystem wird durch einen JDBC-Treiber realisiert, der von einer Java-Anwendung dynamisch vor dem Aufbau einer Verbindung geladen werden muß. Dieser Treiber ist die einzige datenbankabhängige ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 23 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Komponente im Zusammenspiel einer Java-Anwendung mit einer Datenbank. Geladen wird ein JDBC-Treiber durch den sogenannten DriverManager, der als Klasse zum JDBC-API gehört. Der DriverManager dient als Schnittstelle zwischen einem Java-Programm und einem JDBC-Treiber. Die Aufgaben des DriverManagers teilen sich in zwei Bereiche auf. Zunächst übergibt er die mittels der JDBC-API erstellten SQL-Anfragen an den passenden JDBC-Treiber. Die übersetzten Anfragen werden dann mit Hilfe des Treibers der Datenbank übermittelt. Auf der anderen Seite nimmt der DriverManager die Ergebnisse einer Datenbankoperation entgegen, die von der Datenbank mit Hilfe des JDBC-Treibers zurück geliefert werden. Die umgesetzten Ergebnisse können anschließend durch Funktionen der JDBC-API weiterverarbeitet werden12. Die folgende Abbildung zeigt in Form eines Schichtenmodells, wo die Aufgabe des DriverManagers einzuordnen ist. Unterhalb des DriverManagers sind die JDBCTreiber angeordnet. Die Abbildung verdeutlicht, daß ein Java-Programm die Möglichkeit hat, über den DriverManager mehrere JDBC-Treiber zu laden. Somit kann eine solche Anwendung gleichzeitig auf mehrere Datenbanken, verteilt auf unterschiedliche Datenbanksysteme, zugreifen. Abbildung 3: JDBC-Treiber-Manager

12 The Java Tutorial ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 24 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Java-Applikation / Applet JDBC-API JDBC Driver Manager

JDBC-Net Driver

JDBC-ODBC Bridge Driver

Driver A

ODBC-Driver

Driver B JDBC-Treiber

Datenbanksysteme

Mit dem Zusammenspiel von Java und JDBC ist es nun möglich, eine Datenbankanwendung zu entwickeln, die sowohl unabhängig von der Plattform als auch von dem darunterliegenden Datenbanksystem ist. Es spielt demnach keine Rolle, ob eine solche Java-Anwendung z.B. unter UNIX oder unter Windows NT entwickelt wurde. Um die Zugriffe einer Anwendung auf eine andere Datenbank umzustellen muß lediglich ein anderer JDBC-Treiber geladen werden. Konkret bedeutet dies die Änderung einer Codezeile im Programm oder eines Eintrages in einer Konfigurationsdatei, über die der zu ladende JDBC-Treiber festgelegt wird. Die Plattformabhängigkeit, die der JDBC-Treiber besitzt, wird hier nicht berücksichtigt, da dieser von der eigentlichen Java-Anwendung unabhängig ist. Eine bestehende Java-Anwendung mit Datenbankanbindung kann unter einem anderen Betriebssystem nur mit dem passenden JDBC-Treiber laufen. Daß es vier JDBC-Treiber-Typen gibt, soll hier nur kurz erwähnt werden, da es in diesem Rahmen nicht so wichtig ist.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 25 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Typ

Treiber-Name

Kurze Erklärung Die Verbindung zur Datenbank wird mit Hilfe

1

JDBC / ODBC-Bridge-Treiber

eines ODBC-Treibers realisiert. Der ODBCTreiber stellt dabei das Bindeglied zur Datenbank dar. Im Gegensatz zur Architektur mit Treibern vom Typ 1 wird bei diesem Ansatz eine native

2

Native-API Partial Java-Treiber

Schnittstelle als Alternative zu den ODBCElementen eingesetzt, die auf Seiten eines Clients installiert sein muß. JDBC-Treiber dieser Art sind dadurch gekennzeichnet, daß sie durchweg in Java implementiert sind. Ein Client in Form eines Applets kann einen solchen Treiber vollständig zur Lauf-

3

Net Protocol All-Java-Treiber

zeit über das Netzwerk von einem WWW-Server laden. Es ist daher kein weiterer Installationsaufwand in Form von nativem Code auf Seite des Clients erforderlich, wie dies beim Einsatz der ersten beiden Treibertypen der Fall ist. Treiber dieses Typs besitzen die Eigenschaft, direkt mit einem Datenbank-Server kommunizieren zu können. Eine Zwischenkomponente

4

Native Protocol All-Java-Treiber

wie bei der Treiberarchitektur vom Typ 3 wird hier daher nicht unbedingt benötigt, kann aber eingesetzt werden. Typ 4-Treiber sind außerdem vollständig in Java implementiert und besitzen keinerlei nativen Code.

Tabelle 6: JDBC-Treiber-Typen

5.1.2 Die JDBC-API Abschließend in diesem Kapitel soll die JDBC-API und deren Funktionsweise verdeutlicht werden. Diese Beschreibung der einzelnen Komponenten des JDBC-Paketes soll einen Überblick über die API geben. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 26 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

ResultSetMetaData

getMetaData

XX get X

DataTypes: Date, Time, Numeric etc.

ex

X

ec u

t XX ge

te Q ue

ry

ResultSet

s ubClass

Statement

s ubClass

CallableStatement

S at e cre tat

re St at em

en

t

PreparedStatement

nt

pr ep a

e em

getConnection

DriverManager

ge t Dr i ve

r

ge tM et aD

at a

Connection

ll reCa prepa

DatabaseMetaData

Driver

DriverPropertyInfro

getPropertyInfo

Abbildung 4: Überblick über die JDBC-API

In obiger Abbildung wird die JDBC-API dargestellt, wie sie in Form des package java.sql im JDK vorliegt. Die Grafik enthält alle Klassen und Interfaces der API und erklärt in groben Zügen die Abhängigkeiten, die zwischen diesen Komponenten bestehen.

Das Kernstück dieser API bildet die Klasse DriverManager, über die ein JDBCTreiber geladen werden kann. Die Aufgaben dieser Klasse lassen sich grob in zwei Bereiche aufteilen. Auf der einen Seite bietet ein Objekt der Klasse DriverManager Möglichkeiten, Informationen über einen geladenen JDBC-Treiber auszugeben. Über die Methode getDriver() kann ein Objekt des Interfaces Driver erzeugt werden, das die Eigenschaften eines JDBC-Treibers widerspiegelt. Mit einem Aufruf von ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 27 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

getPropertyInfo() liefert ein Driver-Objekt Informationen zu dem geladenen Treiber, die in einem neu instanzierten Objekt der Klasse DriverPropertyInfo festgehalten werden.

Auf der anderen Seite verfügt die Klasse DriverManager über Methoden, mit denen eine Verbindung zu einer Datenbank aufgenommen werden kann. Nachdem ein JDBC-Treiber geladen wurde, kann über die Methode getConnection() eine Datenbankverbindung konfiguriert und aufgebaut werden. Mit Konfiguration ist die Übergabe von Parametern wie Benutzername, Paßwort und Name der Datenbank gemeint. Der Aufruf der Methode liefert ein Objekt des Interface Connection, das die Verbindung zu einer Datenbank repräsentiert. Ein solches Objekt kann maximal eine Datenbankverbindung aufrechterhalten. In einem Java-Programm können allerdings mehrere Connection-Objekte über den DriverManager erzeugt werden, die auf unterschiedlichen Treibern basieren und damit den Zugriff auf unterschiedliche Datenbanken ermöglichen13.

5.2 RMI (Remote Method Invocation) Da nun der Grundstein für das Verständnis von netzwerkorientierter Programmierung gelegt sein sollte, kommt jetzt eine sehr interessante Art der Programmierung von verteilten Systemen zur Sprache, die sogenannten RMI-Calls. Die zumeist komplizierte und sehr verwirrende Konzeption und Implementierung von Netzwerkprogrammen hat zur Entwicklung von RMI geführt. Hier wird der Ansatz verfolgt, nicht über komplizierte Kommunikationsmechanismen mit Anwendungen auf einem anderen Rechner zu interagieren, sondern diese entfernte Anwendung oder die entsprechenden Objekte so zu behandeln, als liefen sie auf der eigenen, lokalen Maschine. RMI ist ein interface-basiertes System, welches es erlaubt, Objekte auf entfernten Rechnern in der eigenen Client-Anwendung quasi zu „referenzieren" und sie wie lokale Objekte zu nutzen, was das Implementieren von entsprechender Funktionalität natürlich extrem vereinfacht. Dieses Prinzip der RMI-Calls wurde auch im 13 Java Unleashed ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 28 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Review-Tool verwendet, da es, wie weiter oben schon beschrieben ein relativ einfacher Aufbau und Ablauf der Kommunikation zwischen Client und Server darstellt.

Die folgende Abbildung stellt ein Client/Server-System im Internet bzw. Intranet dar, dessen Kommunikation auf RMI basiert. Mit Hilfe des Server-Objektes hat das Applet Zugriff auf die Daten eines Datenbank-Servers und auf Dateien des lokalen Dateisystems. Mit der rmiregistry (einer Komponente des JDKs), die in Verbindung mit dem Server-Objekt steht, wird ein solches Objekt mit einem Namen und einem Port in der Systemumgebung registriert. Ein Client-Objekt kann dann über den Namen des Server-Objektes die Verbindung herstellen.

WWW-Client (Browser)

Internet, Intranet

Java-Applet

RMI

WWW-Client (Browser)

Datenbank-Server

rmiregistry

Server Objekt lokales Dateisystem RMI

Abbildung 5: Kommunikation im Client/Server-System mit RMI

RMI und der Begriff „verteilte Anwendungen“ sind eng miteinander verwandt. Verteilte Anwendungen führen Funktionen auf unterschiedlichen Host-Systemen aus. Objekte, die auf einem Host-Rechner ausgeführt werden benutzen Objektmethoden auf anderen Hosts, um ihre Aufgaben zu erledigen. Diese Methoden werden sozusagen auf einem Remote Host ausgeführt. Die auf dem Remote Host benutzten Methoden führen so Berechnungen aus und geben eventuell Werte an die lokalen Objekte zurück14.

Folgende Abbildung soll dieses Konzept nochmals verdeutlichen: 14 Java Unleashed ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 29 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Host B

Host A

Host C

Host D

Objekt Method Invocation

Abbildung 6: Eine verteilte Anwendung

5.2.1 Idee von RMI Die Idee, die hinter RMI steckt, beruht auf den Konzepten von Corba (Common Object Request Broker Architectur), welches eine Alternative zu RMI darstellt, hier aber nicht näher beschrieben werden soll. Danach basiert RMI auf einem verteilten Objektmodell, in dem Java-Objekte über ein Netzwerk miteinander kommunizieren können. Dieses Objektmodell entspricht weitestgehend dem Objektmodell und damit den Vorteilen der Programmiersprache Java. Dies betrifft z.B. die bereits angesprochenen Sicherheitsmechanismen oder die automatische Garbage Collection, die auch über das Netzwerk ohne Einschränkung arbeiten. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 30 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Bei den Objekten, die über ein verteiltes Objektmodell miteinander kommunizieren, wird zwischen Client- und Server- oder Remote-Objekten unterschieden. Bei dem Client-Objekt kann es sich z.B. um ein Applet handeln, welches über das Internet die Methoden eines Server-Objektes aufruft. Ein Server-Objekt wird durch eine JavaApplikation dargestellt. Diese Applikation stellt Methoden (Dienste) zur Verfügung, die ein Applet nutzen kann, das von einem WWW-Server geladen wurde. Bedingung ist hier allerdings, daß die Server-Applikation und der WWW-Server auf dem gleichen Rechner laufen, um die Sicherheitsrestriktionen des Applets nicht zu verletzen. Die Verbindung zwischen einem Client- und einem Server-Objekt bildet ein Interface. In diesem Interface (bestehend aus einer Java-Klasse) müssen alle Methoden deklariert sein, die über den Aufruf eines Clients auf einem Server-Objekt ausgeführt werden sollen. Die Implementierungen dieser Methoden befinden sich in dem ServerObjekt15.

Client-Objekt

Interface

Rückgabew ert

open() getData() close()

RMI

Server-Objekt RMI

Aufruf

Abbildung 7: Kommunikation verteilter Objekte

In obiger Abbildung wird der Methodenaufruf eines Client-Objekts auf einem Server-Objekt dargestellt. Das Interface als Schnittstelle für die Aufrufe enthält Methoden, mit denen die Verbindung mit einer Datenbank über das Server-Objekt betrieben werden könnte.

5.2.2 Architektur eines RMI-Systems Ein auf RMI basierendes Client/Server-System setzt sich aus mehreren Schichten zusammen, die in diesem Abschnitt erläutert werden. Die einzelnen Schichten stellen 15 Thinking in Java ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 31 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Ebenen dar, die ein Methodenaufruf, ausgehend von einem Client-Objekt, durchlaufen muß, bis schließlich das Ergebnis dieses Aufrufs wiederum auf der Seite des Client-Objekts vorliegt. Jede Ebene ist durch eine bestimmte Schnittstelle und ein Protokoll definiert. Grundlage für die Übertragung von Daten im Netzwerk ist das OSI-Schichtenmodell (Open Systems Interconnection). Die verschiedenen Ebenen eines Netzwerksystems lassen sich auf sieben Schichten aus Software und Hardware abbilden. Die folgende Beschreibung der Schichten eines RMI-Systems wird anhand des OSI-Modells durchgeführt. Folgende Abbildung zeigt das vollständige Gebilde mit allen Schichten. 7. Anwendungsschicht

Client

6. Darstellungsschicht

Stub

5. Sitzungsschicht

Remote Reference Schicht

4. Transportschicht

TCP (UDP)

3. Vermittlungsschicht 2. Sicherungsschicht 1. Bitübertragungsschicht

Server

Skeleton

IP Interface zur Hardware Netzwerk

Abbildung 8: Einordnung von RMI in das OSI-Schichtenmodell

5.2.2.1 Client und Server Die oberste Schicht in diesem Modell entspricht der Anwendungsschicht. Auf der einen Seite befindet sich hier die Client-Anwendung, von der die Kommunikation in einem RMI-System ausgeht. Auf der anderen Seite liegt die Server-Anwendung oder das Server-Objekt. 5.2.2.2 Stub und Skeleton Bei der nächsten Schicht handelt es sich um die Darstellungsschicht, die auf Seite ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 32 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

des Clients durch den sogenannten Stub und beim Server durch den Skeleton gebildet wird. Bei beiden handelt es sich um Java-Klassen, die mit dem RMI-Compiler rmic des JDK gebildet werden. Mit rmic wird dazu die Klasse des Server-Objekts übersetzt, welche die Implementierung der im Interface deklarierten Methoden beinhaltet.

Die Stub-Klasse enthält die vollständige Implementierung der Funktionen aus dem Server-Objekt. In dem Moment, wo der Client die Verbindung zum Server-Objekt herstellt, wird die Stub-Klasse zum Client übertragen und als Objekt angelegt. Aufgabe des Stub-Objektes ist das Übertragen der Parameter aus den Methodenaufrufen des Clients zur nächsten Schicht. Die RMI-Technik erlaubt es, Java-Objekte zwischen Client und Server auszutauschen. Der Stub zerlegt dazu die Objekte in Datenströme, sogenannte Streams. Im Gegenzug ist das Stub-Objekt für die Zusammensetzung der Rückgabeobjekte verantwortlich, die vom Server ebenfalls in Form von Streams zurückgesendet werden.

Im Gegensatz zum Stub liegt das Aufgabengebiet des Skeleton-Objekts auf Seiten des Servers. Das Skeleton-Objekt bekommt die Parameter, ausgelöst durch den Methodenaufruf eines Clients, und leitet den Methodenaufruf im Server-Objekt ein. Des weiteren ist der Skeleton für die Entgegennahme der Rückgabewerte eines Methodenaufrufs verantwortlich16.

Folgende Abbildung soll die Funktionsweise von Stubs und Skeletons innerhalb der RMI-Hierachie nochmal verdeutlichen:

16 Java Unleashed ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 33 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Local Host

Remote Host

Object A

Object B

Object B Stub

Reference Layer

Transport Layer

Object B Skeleton

Reference Layer

Remote Registry

Transport Layer

Abbildung 9: Kommunikation von Stubs und Skeletons

5.2.2.3 Remote Reference-Schicht Die Remote Reference-Schicht nimmt im OSI-Modell den Platz der Sitzungsschicht ein. Sie dient als Schnittstelle zwischen dem Stub bzw. dem Skeleton-Objekt und der darunterliegenden Transportschicht. Sie leitet die Übertragung von Daten zwischen den Objekten im Netzwerk ein. Die Remote Reference-Schicht verfügt über verschiedene Protokolle, die in Abhängigkeit der Stubs und Skeletons eingesetzt werden. In einem RMI-System besteht zum einen die Möglichkeit, daß ein Client die Methode lediglich eines Servers aufruft (entspricht dem eigentlichen Client/ServerPrinzip). In dem Fall leitet die Remote Reference-Schicht eine Point to Point-Verbindung zwischen den beiden Objekten ein. Auf der anderen Seite kann sich ein Server-Objekt in einem RMI-System durch Replikation an mehreren Orten im Netzwerk befinden. Die Remote Reference-Schicht sorgt dann dafür, daß alle Server-Objekte vom Aufruf des Clients betroffen sind (könnte z.B. für das Verteilen von Emails in Form einer Mailing-Liste eingesetzt werden).

5.2.2.4 Transportschicht

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 34 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Die Transportschicht wird in einem RMI-System standardmäßig durch TCP (Transmission Control Protocol) besetzt. Es ist allerdings auch möglich alternative Transportprotokolle (z.B. UDP) einzusetzen. Die Transportschicht übernimmt das Management der Verbindungen zwischen Client- und Server-Objekten. Sie kann als eine Art Schnittstelle zwischen den eher anwendungsbezogenen Schichten 5-7 und den eher systembezogenen Schichten 1-3 des OSI-Modells angesehen werden17. Auf die Ebenen unterhalb der Transportschicht wird hier nicht weiter eingegangen, die sie unabhängig von einem RMI-System arbeiten.

6 Das „Review“-Tool In diesem Abschnitt möchte ich ausführlich den Aufbau, die Funktionalität und Einsetzbarkeit des Review-Tools beschreiben. Zusammen mit den Erklärungen werden auch die Besonderheiten und Schwierigkeiten der Implementierung ausführlich erklärt.

6.1 Grundsätzlicher Aufbau 6.1.1 Netzwerkstruktur Es stellte sich anfangs die Frage, wie man ein solches Tool wohl verzeichnismäßig strukturieren könnte. Als Entwicklungs-Betriebssystem stand SuSE Linux 6.1 zur Verfügung zusammen mit den Tools Emacs, vi, der freie Java-Compiler Jikes, das Emacs-Plugin JDE und die entsprechenden Konsolen.

Das Netzwerk innerhalb der Softwareabteilung hatte folgenden Aufbau:

17 Java Unleashed ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 35 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Domäne: HEITEC_RBG

WS-SYDNEY-RBG

HEINUX - Linux Server (WWW-Server Apache)

WS-MEXIKO-RBG

Softw are-Abteilung

Oracle 7 WS-INSTALL-RBG

Mailer

Abbildung 10: Softwareabteilung bei Heitec

Wie schon aus Grafik ersichtlich wird, fungierte der Rechner Mailer auch zusätzlich als Datenbank-Server. Da alle Rechner in der Domäne HEITEC_RBG mit dem Linux-Server HEINUX arbeiteten, diente das Programm „Exceed“ als X-Server-Emulation für Windows NT 4.0. Somit war es möglich, daß alle Workstations ein virtuelles Linux auf ihrem Rechner zur Verfügung hatten, in Wirklichkeit aber alle auf dem Rechner HEINUX arbeiteten.

6.1.2 Verzeichnisstruktur Die Verzeichnisstruktur für das Review-Tool wurde folgendermaßen festgelegt: ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 36 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Abbildung 11: Verzeichnisstruktur des Review-Tools HEINUX - Linux Server (WWW-Server Apache)

/vol

/bin

/opt

.....

/vol

.....

/home

.....

/scch

/public

/HEITEC

.....

/Review

/Database

/Docs

/Siemens

/Code

/review

/client

/server

/interfaces

/tools

/pdf

/be /images /ac

/rug

/text

/pdf

Wenn man der dicken Linie in diesem Verzeichnisbaum folgt, kommt man an die Pfade:

[email protected]:~/HEITEC/Review/Code/review/client>, [email protected]:~/HEITEC/Review/Code/review/server>, ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 37 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

[email protected]:~/HEITEC/Review/Code/review/interfaces>, [email protected]:~/HEITEC/Review/Code/review/tools> und [email protected]:~/HEITEC/Review/Code/review/pdf>

Für was das letzte Verzeichnis benötigt wurde, wird an späterer Stelle erklärt. In diesen Verzeichnissen wurde das ganze Tool entwickelt.

Dieser ganze Verzeichnisbaum wurde in ein sogenanntes CVS-System eingebunden. CVS heißt „Concurrent Versions System“ und hat die Aufgabe, für eine Vielzahl von Programmierern jeweils die aktuellen Sourcen zur Verfügung zu stellen. Da an diesem Projekt manchmal bis zu drei Entwicklern tätig waren, tat das CVS sehr wohl seine Dienste. Um das CVS-System ein wenig verständlicher zu machen, möchte ich an dieser Stelle ein kleines Beispiel einfügen: Programmierer 1 macht Veränderungen an irgendeiner Datei im Client. Er muß also die aktuellen Sourcen zuerst „auschecken“, indem er folgenden Befehl im Verzeichnis „/vol/home/scch/HEITEC/Review/Code/review/client“ mit ENTER bestätigt: cvs update Er bekommt so eine Liste aller in diesem Verzeichnis befindlichen Dateien, die ins CVS eingecheckt wurden. Eingecheckt wird im übrigen mit: cvs add Diese Liste, die der Benutzer bei cvs update bekommt, könnte eventuell so aussehen:

usw.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 38 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

U

AdminGlobalCatalog.java

U

ReleaseDatePanel.java

U

Administration.java

M

ProjectInvitations.java

A

Documents.java

C

AdminDocumentType.java

?

Participants.class

?

Documents.class

?

ProjectTopics.class

?

ProjectQuestions.class

?

MainSelection.class

?

CheckList.class

?

CheckList$CommentEditor.class

?

CheckList$ReviewStatus.class

?

AdminProjects.class

?

Administration.class

?

Administration$1.class

?

Administration$AddCatalog.class

?

Administration$MileStonesDescription.class

? Administration$MileStonesTableModel.class #sql {delete questid from glbquestion where questid = 5}; ? SelectProject.class ?

SelectProject$GlobalTableModel.class

?

ProjectQuestions.class

?

SpecialCatalog.class

Die obige Tabelle ist nur ein kleiner Ausschnitt aus dem, was das cvs im /clientVerzeichnis ausgeben würde. Absichtlich sind hier alle Optionen (U, M, A, C und ?) mit angegeben worden, die es im CVS gibt.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 39 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Option

Erklärung

U

Wird, wie im obigen Beispiel, vor einer Datei die Option U ausgegeben, so ist die entsprechende *.java Datei von Programmierer X verändert worden. Diese veränderte Datei steht nun mit einer neuen Versionsnummer dem Programmierer 1 zur Verfügung. Er kann mit dieser neueren

int questid=0; #SQL {SELECT QUESTID INTO :questid FROM GLBQUESTION WHERE TOPICID = 20};

Datei weiterarbeiten und selber wieder verändern. Es ist hier vielleicht noch hinzuzufügen, daß der Programmierer X den entsprechenden Source-Code mit einem cvs update fürs CVS vorbereitet und mit einem cvs commit ins CVS eingecheckt hat. Erst somit ist die Datei für andere als verändert sichtbar. M

Wird, wie im obigen Beispiel die Datei „ProjectInvitations.java“ mit einem M markiert, so ist sie von Programmierer 1 verändert worden. Sie muß noch mit einem cvs commit ins CVS aufgenommen werden und ist anschließend für alle anderen Programmierer sichtbar (Bei Programmierer X erscheint diese Datei anschließend mit der Option U). Sie erhält dadurch natürlich auch eine neue Versionsnummer.

A

Die Option A erscheint dann, wenn eine Datei frisch ins CVS aufgenommen wurde. Der Befehl dafür ist cvs add . Die Datei ist anschließend im CVS auch für alle anderen Programmierer sichtbar.

C

C ist die „schlechteste“ Option für eine Datei. Wenn vor einer Datei C steht, so ist ein Konflikt (engl. Conflict) aufgetreten. Man kann sich das so vorstellen, daß zwei Programmierer an der gleichen Stelle was veränderten und ihren neuen Source-Code einchecken. Man kann sich den Konflikt anschließend mit dem Befehl cvs diff ansehen und entsprechende Vorkehrungen treffen.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 40 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Option ?

Erklärung Wenn vor einer Datei ein „?“ steht, so heißt das, daß das CVS-System sie nicht erkennt. Logischerweise steht ein „?“ immer vor *.class Dateien, da diese nicht ins CVS mit eingecheckt werden. Sie werden ja auch in dem Sinn nicht von einem Programmierer editiert.

Tabelle 7: CVS-Optionen Wenn ein Benutzer also nun einen Quellcode verändern will, führt er zunächst cvs update aus, womit er an die aktuellen Sourcen kommt, vorausgesetzt, sie wurden von den anderen Benutzern bereits eingecheckt. Anschließend kann er den Code verändern und wieder mit cvs update; cvs commit einchecken.

Packages Hier solle auch noch auf die sogenannten „Packages“ eingegangen werden. In den Verzeichnissen [email protected]:~/HEITEC/Review/Code/review/client>, [email protected]:~/HEITEC/Review/Code/review/server>, [email protected]:~/HEITEC/Review/Code/review/interfaces>, [email protected]:~/HEITEC/Review/Code/review/tools> und [email protected]:~/HEITEC/Review/Code/review/pdf>

wurde jeweils ein Link auf die über-übergeordnete Verzeichnisebene angelegt, um das Einbinden der jeweiligen Packages package review.server; package review.client; package review.interfaces; package review.tools; package review.pdf;

Tabelle 8: Verwendete Packages

zu ermöglichen. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 41 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

In jedem Verzeichnis wurde über den Befehl: ln –s ../../review review dieser Link erzeugt und somit das Verzeichnis: [email protected]:~/HEITEC/Review/Code>

als Basisverzeichnis festgelegt.

6.1.3 Server Wie kann man sich einen Server vorstellen? Ein Server muß nicht unbedingt eine Hardware-Komponente sein, wie z. B. ein File-Server, ein DNS-Server oder ein Mail-Server. In diesem Fall stellt der Server eine Software-Komponente dar, die ähnlich arbeitet wie ein File-Server. Er stellt im Gegensatz zu einem File-Server keine Verzeichnisstruktur zur Verfügung, sondern ist vielmehr die Schnittstelle zwischen DatenbankServer und Java-Applikation. Man nennt einen solchen Server auch ApplicationServer.18 Man kann sich einen solchen Server folgendermaßen vorstellen: Back -End Se rve r

Back -End Se rve r

Application Server

Clie nt

Clie nt

Clie nt

Abbildung 12: Application-Server

18 Java Unleashed S. 785 ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 42 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Es wird sozusagen ein Software-Server gestartet, auf den beliebig viele Clients zugreifen können. Einem Server muß aber, bevor er seine Dienste tun kann, zuerst gesagt werden, wie er auf die Datenbanktabellen zugreifen kann. Die eigentliche Verbindung zur Datenbank erledigt die Datei „ReviewServer.java“ im Server-Verzeichnis.

Zwischen Client und Server befindet sich aber noch eine dritte Komponente, die sogenannten Interfaces. Die Interfaces sind wiederrum die Schnittstelle zwischen Client und Server.

Wie die Datei „ReviewServer.java“ arbeitet, soll im folgenden ausführlich erklärt werden. Da sich die Datei im Verzeichnis [email protected]:~/HEITEC/Review/Code/review/server>

befindet, muß zuerst das Package „review.server“ mit eingebunden werden. Über den entsprechenden Link weiß nun der Server, welches Verzeichnis er als Basis nehmen soll.

6.1.3.1 Embedded SQL mit SQLJ Für Zugriffe auf relationale Datenbanken stand bisher nur die „low level“-Programmierschnittstelle JDBC (Java Database Connectivity) zur Verfügung, die bereits in einem früheren Kapitel behandelt wurde. Sie wird seit dem JDK 1.1 standardmäßig von Sun im Package java.sql mitgeliefert. Die JDBC-Schnittstelle arbeitet mit SQL-Befehlen, die einem JDBC-Treiber als Zeichenkette übermittelt werden. SQLJ bezeichnet man auch als "high-level"-Schnittstelle. Mit ihr können SQL-Befehle direkt in den Java-Code eingebettet werden (embedded SQL), um so die Entwicklung von Datenbankanwendungen zu vereinfachen.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 43 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

6.1.3.2 Wie arbeitet SQLJ? Der Pre-Compiler wandelt die SQLJ-Anweisungen in gewöhnlichen Java-Quellcode (mit der Endung "*.java") um, von dem dann ein Java-Compiler den Bytecode erzeugen kann. Der vom Pre-Compiler umgewandelte Code enthält die JDBCAnweisungen, die weiterhin für die Kommunikation mit einem Datenbanksystem benutzt werden. Optional kann vom Pre-Compiler während des Umwandlungsvorgangs eine Datenbankverbindung genutzt werden, um die Datentypen im Java-Programm hinsichtlich ihrer Richtigkeit mit den Datenbankfeldern zu überprüfen. Folgende Abbildung zeigt schematisch den Aufbau, wie mit einer *.sqlj-Datei umgegangen wird: SQLJ Code

SQLJ-Übersetzung

Java Source File

Java Compiler

Java Class File

Oracle

Java Compiler

RUN

Oracle

Abbildung 13: Umgang mit SQLJ

Die Einbettung von SQL-Befehlen in Java-Programmen wird mit #SQL gekennzeichnet. Da dies kein gültiges Java-Wort ist, ist es sofort als SQLJ-Programm erkennbar und kann von einem gewöhnlichen Java-Compiler auch nicht umgewandelt werden. Die SQL-Anweisungen werden in geschweifte Klammern eingeschlossen. Ein einfacher Befehl hat beispielsweise folgendes Aussehen: Dieser SQL-Befehl löscht beispielsweise aus der Tabelle glbquestion den Datensatz, bei dem die questid gleich 5 ist. Da in der Tabelle glbquestion die questid der Primärschlüssel ist, wird hier logischerweise nur ein Datensatz gelöscht. Mit SQLJ ist es möglich, Datenbankabfragen durchzuführen (SELECT), Transaktionen zu steuern (COMMIT, ROLLBACK, DDL-Anweisungen durchzuführen (CREATE, DROP etc.) und alle sonstigen Manipulationsbefehle von SQL zu nutzen ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 44 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

(UPDATE, DELETE etc.). Auch gespeicherte Funktionen und Prozeduren können über SQLJ aufgerufen werden. Dabei wird auch PL/SQL unterstützt, wobei Java-Programme PL/SQL-Programme aufrufen können und umgekehrt.

Es werden innerhalb der SQL-Anweisungen sogenannte Host-Variablen benutzt. Als Host-Variablen bezeichnet man bei SQLJ die Variablennamen in der Java-Applikation, die in den SQL-Anweisungen direkt benutzt werden können. Sie werden dort mit einem Doppelpunkt vor dem Namen gekennzeichnet. Das folgende Beispiel zeigt die Verwendung von Host-Variablen in einer SELECT-Anweisung: Die in Großbuchstaben geschriebenen Namen sind die Feldnamen in der SQL-Datenbank, der in Kleinbuchstaben geschriebene Name mit Doppelpunkt ist ein Variablenname im Java-Programm. Da sich die Datentypen der Host-Variablen von denen aus der Datenbank unterscheiden, müssen die Datentypen jeweils in die entsprechenden Formate umgewandelt werden. Dieses Umwandeln wird als Mapping19 bezeichnet. Folgende Tabelle zeigt die wichtigsten Datentypen von SQL und ihr Gegenüber als Java-Datentyp: SQL-Typ

Java-Typ

VARCHAR; VARCHAR2

String

NUMERIC

java.math.Decimal

BOOLEAN

boolean

TINYINT

byte

SMALLINT

short

INTEGER

int

BIGINT

long

REAL

float

DOUBLE

double

VARBINARY; LONGVARBINARY

byte[]

DATE

java.sql.Date

TIME

java.sql.Time

TIMESTAMP

java.sql.Timestamp

19 http://ourworld.compuserve.com/homepages/huebenthal/huebenthal.htm ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 45 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Tabelle 9: Oracle-Datentypen Dabei ist zu beachten, daß manche Datenbanksysteme (wie MS Access) teilweise andere Typbezeichnungen verwenden (z. B. Text in Access statt VARCHAR in SQL). Um eine Abfrage zu bearbeiten, die eine Ergebnismenge zurückgegeben hat, wird in SQLJ eine Iterator-Klasse verwendet. Die einzelnen Tabellenfelder in den Datensätzen werden in Form von Java-Datentypen zurückgegeben und können vom Java-Programm verarbeitet werden. In einem Iterator-Objekt kann man sich leider nur vorwärts bewegen, d. h. die Datensätze der Ergebnismenge vom ersten bis zum letzten Ergebnissatz bearbeiten. Daß man sich in einem Iterator-Objekt nicht rückwärts bewegen kann, hat seinen Ursprung in JDBC, wo dies auch nicht möglich ist. Sobald JDBC diese Funktionalität aber bietet, wird auch die SQLJ-Spezifikation erweitert. Man wird sich fragen, wo die großen Vorzüge von SQLJ liegen. Folgende Vorteile liegen auf der Hand:



Mit SQLJ erhält man einen kompakteren Code als mit JDBC



Um das Öffnen und Schließen von Verbindungen und die Festlegung der Treiber-Klassen muß man sich im Programm-Code weniger kümmern



Man kann SQL so verwenden, als wenn es zur Programmiersprache Java gehören würde



Die mögliche Typüberprüfung zur Übersetzungszeit durch die Option -online des Pre-Compilers. So können viele Fehler rechtzeitig entdeckt werden. Da JDBC die SQL-Befehle nur als Zeichenkette zur Datenbank schickt, treten die Fehler dort erst zur Laufzeit auf.

Tabelle 10: Vorteile von SQLJ gegenüber JDBC

Ein Nachteil ist hier allerdings der zwingend zu verwendende Pre-Compiler, der die Umwandlungszeit verzögert und der einen Java-Quellcode erzeugt, der nicht gerade gut zu lesen und damit auch nicht gut zu debuggen ist. Das Erstellen eines SQLBefehls mit einer Zeichenkette hat aber den großen Vorteil, daß die Befehle dyna____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 46 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

misch zur Laufzeit zusammengesetzt werden können. So kann z. B. der Tabellenname einer Abfrage erst von der Programmlogik bestimmt werden und später zu einer Zeichenkette mit der SQL-Anweisung hinzugefügt werden. SQLJ-Befehle dagegen sind immer statisch (was auch ein Unterschied zu embedded SQL für andere Sprachen ist), d. h. die SQLJ-Befehle können von der Programmlogik nicht mehr verändert werden. Man muß noch hinzufügen, daß sowohl JDBC als auch SQLJ in einem Programm gut zusammenarbeiten können und kein System das andere ausschließt.

6.1.3.3 Kompilierung von SQLJ-Programmen Eine kompilierte SQLJ-Applikation ist ein Standard-Java-Programm, das überall dort ausgeführt werden kann, wo zum einen eine Java Virtual Machine, eine SQLJ-Laufzeitumgebung und ein JDBC-Treiber zur Verfügung stehen20

Es gibt einen wichtige Aspekte bei der Ausführung von SQLJ-Applikation zu betrachten: ●

SQLJ-Runtime - Zur Laufzeit kommuniziert eine SQLJ-Applikation mit einer Datenbank über die SQLJ-Laufzeit-Bibliothek SQLJ Applikation

SQLJ Laufzeitumgebung

Javasoft ODBC based Driver

Oracle JDBC/OCI Driver

Oracle Thin JDBC Driver

ODBC C Library

OCI C Library

Java sockets

Abbildung 14: SQLJ Laufzeitkonfiguration Das Übersetzen einer SQLJ-Datei mit dem Precompiler kann z. B. folgendes Ausse20 Java Developers Journal ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 47 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

hen haben: >> sqlj AdministrationSer.sqlj

Mit diesem Befehl erstellt der Precompiler zunächst die Datei Administration.java (s. Abb. in 6.1.3.2). Warum diese Datei mit „Ser“ endet, hat seinen Grund in der allgemeinen Konvention, die wir bei Server-Dateien verwendeten. Somit ist es leichter möglich, Client-, Interface- und Server-Dateien auseinanderzuhalten. Anschließend werden automatisch *.class-Dateien erzeugt, welche mit dem Java-Compiler übersetzt werden, der standardmäßig eingestellt ist, also im Normalfall javac. Da beim Review-Tool allerdings der jikes verwendet wurde, wurden *.sqlj-Dateien mit dem Schalter –compile=false übersetzt: >> sqlj –compile=false Administration.sqlj >> jikes Administration.java

Dies liefert das gleiche Ergebnis wie im obigen Fall. Es werden nun allerhand *.class-Dateien erzeugt:

Administration.class crbusifield.class crcatalog.class crmilestone.class crlocation.class

6.1.3.4 Interview von der Zeitschrift JavaSpektrum mit Jeremy Burton von der Oracle Corporation Ich halte es für interessant, wenn ich hier einen kurzen Abschnitt einfüge, welcher einen kurzen Ausschnitt eines Interviews mit Jeremy Burton von der Oracle Corporation wiederspiegelt, bzw. dessen Prognosen kundgibt. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 48 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

JavaSpektrum: Mit SQLJ wollen Sie SQL Java-fähig machen. Was sind die wesentlichen Vorteile von SQLJ? J. Burton: Oracle hat mit Herstellern wie IBM, Tandem, Sybase und JavaSoft zusammengearbeitet, um durch SQLJ SQL-Statements in Java-Programme einbetten zu können. SQLJ besitzt gegenüber JDBC eine einfachere und produktivere Programmierschnittstelle. Über diese Schnittstelle können Anwendungen auf relationale Daten zugreifen und genauso mit den Datenbanken der verschiedensten Hersteller über Standard-JDBC-Treiber kommunizieren. Mit SQLJ lassen sich Client- aber auch Mittelschicht-Anwendungen, die über Java auf Datenbanken zugreifen, auf sehr einfache Weise bauen [....] SQLJ-Programme besitzen gegenüber JDBC einen kompakteren Code und weisen eine höhere Abstraktion bei der Programmierung auf. Sie sind deshalb weniger fehleranfällig, leichter zu verstehen und leichter zu warten. Das Debugging ist ebenfalls leichter. Ein weiterer Vorteil ist die verständliche Funktionalität: SQLJ bietet Zugriff auf Standardfunktionen von Anwendungen, wie gleichzeitige Verbindungen zu mehreren Datenbanken, Transaktionsmanagement, Abfragen, DDL-Statements, um die Objektschemata zu erzeugen und freizugeben [....] SQLJ-Translator führt die Überprüfung von Typen und Schemata durch, um Fehler der Syntax und der Semantik in SQL-Statements schon bei der Entwicklung von Programmen und nicht erst zur Laufzeit herauszufinden. Dies ist ein Vorteil gegenüber JDBC. Bei einer dynamischen Programmierschnittstelle wie JDBC kennt man die Syntax der SQL-Statements und der Argumentetypen erst zur Laufzeit. Dynamisches SQL ist flexibler als statisches SQL, weil die SQL-Statements selbst zur Laufzeit als Textzeichenketten zusammengefügt werden können, um an die Datenbank geschickt zu werden. Als Ergebnis dieser Flexibilität stellt dynamisches SQL die Überprüfung der Syntax, der Typen und Schemata hintan bis zur Laufzeit. Programme, die in SQLJ geschrieben sind, sind deshalb gegenüber JDBC-Programmen robuster, da eine statische Typüberprüfung unabhängig von der Flußkontrolle zur Laufzeit durchgeführt werden kann. Interessant an SQL ist auch seine Hersteller-Interoperabilität: Ein SQLJ-Programm ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 49 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

wird in Aufrufe für das SQLJ-Laufzeitpaket übersetzt. Dieses SQLJ-Laufzeitpaket greift über JDBC auf die Datenbank zu. SQLJ-Programme können deshalb auf jeden Daten-Server zugreifen, für den es JDBC-Treiber gibt. Jeder JDBC-Treiber, der mit der Standard-Spezifikation von JavaSoft konform ist, kann mit dem Code eingesetzt werden, den der SQLJ-Translator erzeugt. SQLJ nutzt somit die Datenbankunabhängigkeit von JDBC, durch das Anwendungen, die aus Standard-Java-Klassen bestehen, auf die relationalen Datenbanken der verschiedenen Hersteller zugreifen können21 [....]

JavaSpektrum: Was können Sie über die Performance von SQLJ sagen? J. Burton: SQLJ ist bereits auf JDBC kompiliert und Oracle verbessert, wie oben angesprochen, die Performance von JDBC, indem es native Treiber zur Verfügung stellt22.

6.1.3.5 Verwendete Bibliotheken Es wurden noch folgende Bibliotheken in den Review-Server mit aufgenommen:



import review.tools.*;

Diese Klassen sind weniger wichtig für den Server, wurden aber der Vollständigkeit halber mit aufgenommen. ●

import review.interfaces.*;

Diese Klassen sind unerläßlich für den Server. ●

import sqlj.runtime.ref.DefaultContext;

Dieses Paket wurde mit eingebunden, da es eine komplette Standardimplementierung eines Verbindungs-Kontextes beinhaltet. Diese Klassen werden für den SQLJ-Precompiler gebraucht. ●

import java.util.*;

Diese Klassen beinhalten das Event Model, Datum- und Zeitunterstützung, Interna21 Java Spektrum 22 Java Spektrum ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 50 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

tionalisierung und verschiedene Utility-Klassen (StringTokenizer, Zufallszahlengenerator). Außerdem wird im ganzen Review-Tool mit dem Objekt „Vector“ gearbeitet, das zusätzlich in diesem Paket enthalten ist. ●

import java.io.*;

Diese Klassen wurden mit eingebunden, da sie für die Log-Datei gebraucht wurde. Es beinhaltet u. a. auch die Unterstützung von Data-Streams und Serialization von Objekten. ●

import java.rmi.*;

Diese Klassen sind zuständig für die ganze RMI-Verfügbarkeit in Client und Server. Sie sind in der Datei „ReviewServer.java“ auch unerläßlich. ●

import java.rmi.server.*;

Dieses Paket wird benötigt, um die serverseitigen Implementierungen von RMI realisieren zu können. ●

import java.sql.*;

Es beinhaltet das ganze JDBC-Paket. Es sind Klassen und Interfaces für die Implementierung von SQL-Statements vorhanden.

6.1.3.6 Klassenvariablen Es werden im folgenden Abschnitt mehrere Zeilen des Source-Codes angegeben. Es ist meiner Meinung nach für das Verständnis des Aufbaus eines RMI-Servers unerläßlich. Es wurden im Review-Server folgende Klassenvariablen verwendet, die zur Anbindung an die Oracle-Datenbank gebraucht werden:

private static String uid;

// db user id

private static String pwd;

// db user password

private static String dburl;

// db url

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 51 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Diese Variablen werden im folgenden Abschnitt erklärt. Man muß an dieser Stelle hinzufügen, daß im Review-Home-Verzeichnis (/HEITEC/Review/Code/review) eine Datei namens review.properties angelegt wurde, welche folgendes Aussehen hat:

1.jdbc.drivers=oracle.jdbc.driver.OracleDriver 2.review.DatabaseURL=jdbc:oracle:thin:@heinux:1521:orcl 3.review.DatabaseUser=revi 4.review.DatabasePasswd=ORACLE 5.review.ServerName=HEINux

Mit Hilfe dieser Datei werden dem Server folgende Informationen mitgeteilt: 1. Name des zu verwendenden Oracle-Treibers 2. Datebase-URL mit Angabe der Art des Treibers, des Host-Namen, des Datenbank-Listener-Ports und der SID 3. Zu verwendender User-Name 4. Zu verwendendes Paßwort 5. Name des Datenbank-Servers

6.1.3.7 Klassenfunktionen In der Funktion public static void initConnectionManager() werden die benötigten Daten nun wie folgt eingelesen: Properties prop = new Properties(System.getProperties());

Anlegen eines neuen Properties-Objekts

dburl = prop.getProperty("review.DatabaseURL");

Einlesen der URL-Informationen aus der Datei

uid = prop.getProperty("review.DatabaseUser");

Einlesen der User-ID aus der Datei ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 52 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

pwd = prop.getProperty("review.DatabasePasswd");

Einlesen des Paßworts aus der Datei

Diese Anweisungen stammen natürlich nicht von mir selbst, sondern sind mehr oder weniger aus dem Java Tutorial übernommen. Es ist dort ein leicht nachvollziehbares Beispiel angegeben, welches hier nach den entsprechenden Anforderungen wiedergespiegelt wurde. Es wäre auch möglich gewesen, die Strings aus der Datei direkt im Funktionsaufruf zu übergeben, allerdings wären dann etwaige Änderungen schwerer durchzuführen gewesen und hätten an mehreren Stellen bearbeitet werden müssen.

Nun folgt der Aufbau der tatsächlichen Verbindung mit der Oracle-Datenbank. Diese Funktion heißt public static Connection newConnection() throws DBException und wurde folgendermaßen aufgebaut:

(1) Connection conn = null; (2) if (uid== null || pwd==null || dburl==null ) { System.err.println("Please set DBURL, UID, and PWD" ); System.exit(1); } (3) try { conn = DriverManager.getConnection(dburl, uid, pwd); } (4) catch (Exception e) { System.err.println("Could not establish the connection"); System.err.println(e); (5) return conn;

Erklärung: (1)Es wird eine Connection-Variable conn angelegt und mit null initialisiert. Innerhalb eines Kontextes von Connection können SQL-Abfragen ausgeführt werden. Es enthält außerdem über die vorhandenen Tabellen und unterstützt die ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 53 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

SQL-Grammatik23 (2)Hier wird überprüft, ob die statischen Variablen richtig gesetzt wurden, oder ob noch Werte fehlen. Falls eine der überprüften Variablen nicht gesetzt wurden, d. h. in der Datei review.properties nicht vorhanden sind, wird eine Fehlermeldung ausgegeben (3)Nun folgt der eigentliche Aufbau der Verbindung, und zwar mittels des Schlüsselwortes try („versuche“). Ein try muß immer mit catch abgefangen werden. Dieses Verfahren nennt man Exception-Handling. Es muß bei Datenbankzugriffen grundsätzlich das Exception-Handling verwendet werden. Mittels der Klasse DriverManager aus dem java.sql-Package kann nun über die Methode getConnection (String url, String user, String password) ein Zugriff auf die Datenbank gestartet werden (4)Hier beginnt die catch-Routine. Sie wird dann aktiv, wenn die Verbindung zur Datenbank scheiterte und es wird eine entsprechende Fehlermeldung ausgegeben (5)Wenn alles erfolgreich ablief, wird hier das Handle auf die Datenbankverbindung als Resultat zurückgeliefert

Als nächstes folgt die Funktion public static void setDefaultContext(), welche aber nicht so genau erklärt werden soll. Diese Funktion stammt aus dem sqlj-Package, welches mit import eingebunden wurde. Die Klasse DefaultContext beinhaltet eine komplette Standard-Implementierung eines Connection-Kontextes24 und ist hier unbedingt nötig. Wie die Funktion genau aufgebaut ist, kann dem Java Tutorial entnommen werden. Sie kann von dort direkt übernommen werden und braucht nicht individuell an einzelne Bedürfnisse angepaßt werden.

6.1.3.8 Das Hauptprogramm Nun kommen wir auch schon zum Hauptprogramm der „ReviewServer.java“-Datei. Es wird wie folgt vorgegangen: 23 Java Platform 1.2 API Specification 24 SQLJ-API ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 54 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

(1) public static void main (String[] args) { (2)

Properties prop = new Properties(System.getProperties());

(3)

try {

(4)

LogFile.setLog(new PrintStream (new FileOutputStream ("Review.log")));

(5)

prop.load(new BufferedInputStream (new FileInputStream("review.property")));

(6)

System.setProperties(prop);

(7)

initConnectionManager();

(8)

setDefaultContext();

(9)

System.err.println("DB connected");

(10)

LogFile.log.println("DB connected");

(11)

if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); }

(12)

String host = "//" + prop.getProperty("review.ServerName");

(13)

MainSelSer admSrv = new MainSelSer();

(14)

String interfaces = admSrv.getInterface();

(15)

Naming.rebind(host + "/" + interfaces, admSrv);

(16)

System.out.println("MainSelSer bound");

(17)

LogFile.log.println("MainSelSer bound");

(18)

host = "//" + prop.getProperty("review.ServerName"); AdministrationSer AS = new AdministrationSer(); interfaces = AS.getInterface(); Naming.rebind(host + "/" + interfaces, AS); System.out.println("AdministrationSer bound"); LogFile.log.println("AdministrationSer bound");

..... ..... ..... ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 55 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

(19)

} catch (Exception e) { System.err.println("Review Server exception: " + e.getMessage()); }

}

Zur Erklärung: (1)Beginn der Funktion main() (2)Einlesen der derzeitigen Systemeigenschaften. Folgende Tabelle enthält die vorhandenen Systemeigenschaften25: Key

Description of Associated Value

java.version

Java Runtime Environment version

java.vendor

Java Runtime Environment vendor

java.vendor.url

Java vendor URL

java.home

Java installation directory

java.vm.specification.version

Java Virtual Machine specification version

java.vm.specification.vendor

Java Virtual Machine specification vendor

java.vm.specification.name

Java Virtual Machine specification name

java.vm.version

Java Virtual Machine implementation version

java.vm.vendor

Java Virtual Machine implementation vendor

java.vm.name

Java Virtual Machine implementation name

java.specification.version

Java Runtime Environment specification version

java.specification.vendor

Java Runtime Environment specification vendor

java.specification.name

Java Runtime Environment specification name

java.class.version

Java class format version number

java.class.path

Java class path

os.name

Operating system name

os.arch

Operating system architecture

os.version

Operating system version

file.separator

File separator ("/" on UNIX)

path.separator

Path separator (":" on UNIX)

line.separator

Line separator ("\n" on UNIX)

25 Java Platform 1.2 API Specification ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 56 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Key

Description of Associated Value

user.name

User's account name

user.home

User's home directory

user.dir

User's current working directory

Tabelle 11: Systemeigenschaften aus der Methode getProperty() (3)Beginn der Initialisierung (4)Für alle kritischen Serveraktivitäten werden eventuelle Fehlermeldungen in eine Log-Datei namens Review.log geschrieben, um die Fehlersuche zu erleichtern (5)Die Daten aus der vorher schon angesprochenen Datei review.property werden in die Instanz des Property-Objekts eingelesen (6)Die vorher eingelesenen Werte werden dem System mitgeteilt (7)Aufruf der Funktion initConnectionManager() (8)Aufruf der Funktion setDefaultContext() (9)Bei erfolgreicher Ausführung der vorangegangen Funktionen wird eine entsprechende Debug-Meldung auf die Standardfehlerausgabe ausgegeben (10)Diese Debug-Meldung wird auch ins Logfile geschrieben (11)Anlegen eines neuen SecurityManagers. Ein SecurityManager wird benötigt, um Zugang zu Systemressourcen in der Virtual Machine zu erhalten. Des weiteren regelt er den Zugriff auf das lokale Dateisystem. Alle Applikationen oder Applets, die RMI verwenden, müssen auch einen SecurityManager installieren, da RMI ansonsten nicht funktioniert, bzw. die erforderlichen Klassen nicht lädt26 (12)Die Benutzervariable Host wird mit den entsprechenden Parametern aus der Datei review.properties initialisiert. Der Variablen wird hier der String „//heinux“ übergeben (13)Es wird eine Instanz der Klasse MainSelSer erzeugt. Bei dieser Datei handelt es sich um eine Sqlj-Datei mit statischen SQL-Statements (14)Es wird an die Variable interface der Name des Interfaces übergeben, welche zur Sqlj-Datei gehört (15)Das entsprechende Interface wird an das neue Remote Objekt gebunden 26 Java Tutorial ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 57 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

(16)Die Information, daß das Binden erfolgreich war, wird auf der Standardausgabe ausgegeben (17)Diese Information wird zusätzlich noch in die Logdatei geschrieben (18)Das ist die gleiche Prozedur wie ab (12) (19)Hier wird ein eventueller Fehler mit catch(Exception e) abgefangen und die Fehlermeldung wird auf der Standardfehlerausgabe ausgegeben. Mit e.getMessage() aus der Klasse java.lang.Throwable wird der Grund des Fehlers mit ausgegeben

Alle Sqlj-Dateien werden in diesem ReviewServer „gebunden“, die Namen der Interfaces werden an den Namensdienst angemeldet. Die eigentliche Server-Datei sollte hiermit geklärt sein.

6.1.3.9 Aufbau der SQLJ-Dateien Im vorigen Abschnitt hat man schon gesehen, daß verschiedene Dateien mit der Endung "Ser" gebunden wurden. Das sind die SQLJ-Dateien, die die Abfragen auf die Oracle-Datenbank beinhalten. Wie diese SQLJ-Dateien im Review-Tool aufgebaut wurden, soll in diesem Abschnitt näher erläutert werden. Logischerweise haben diese Dateien die Endung *.sqlj, wie schon früher erwähnt wurde. Als Beispiel für eine SQLJ-Datei möchte ich hier die Datei AdministrationSer.sqlj nehmen. Die verwendeten Packages stimmen mit denen überein, die bereits in ReviewServer.java verwendet wurden. Als nächstes werden sogenannte Iteratoren definiert. Ein Iterator kann beispielsweise folgendes Aussehen haben:

#SQL ITERATOR crcatalog(int catid, String catname, java.sql.Date releasedate, Double maxpartic, Double maxdocu); ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 58 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Ein solcher Iterator stellt einen Rückgabewert eines SQL-Anweisung dar. Man kann diesen Iterator auch Cursor nennen. Er wird dann eingesetzt, wenn die Rückgabemenge eines SQL-Befehls einen Datensatz übersteigt. Mit einer entsprechenden Foroder While-Schleife kann dann durch die Datensätze, die dem SQL-Befehl entsprechen, gescrollt werden. In obigem Beispiel spiegelt der Iterator den Inhalt der Datenbank-Tabelle glbCatalog wieder. Man beachte, daß der Kopf einer *.sqlj-Datei immer folgendes Aussehen hat: (1)public class AdministrationSer extends UnicastRemoteObject (2)

implements IAdministration {

(3)

public AdministrationSer() throws RemoteException {

(4)

super(); }

.....

(1)Wenn eine Server-Datei das Prinzip des RMI verwendet, muß sie von UnicatRemoteObject abgeleitet werden. UnicastRemoteObject ist eine Unterklasse von java.rmi.server.RemoteServer und beinhaltet Methoden und Funktionen, die für RMI unerläßlich sind (2)Des weiteren muß hinter die Direktive implements das Interface stehen, das in dieser Datei implementiert bzw. codiert wird. In diesem Fall heißt das Interface IAdministration. Alle Funktionen, die in diesem Interface enthalten sind, müssen in AdministraitonSer.sqlj implementiert werden, ansonsten meldet der Java-Compiler einen Fehler (3)Dies ist der Konstruktor der Datei. Das Schlüsselwort throws RemoteException bringt zum Ausdruck, daß Verbindungsprobleme auftreten können, die automatisch abgefangen werden und ist an dieser Stelle unbedingt notwendig (4)Das Schlüsselwort super() bedeutet nur, daß der Konstruktor der Super-Klasse, in diesem Fall der Klasse UnicastRemoteObject aufgerufen wird

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 59 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Nun zurück zum Cursor - um durch einen Cursor zu scrollen muß zunächst ein entsprechender Datentyp vom Typ crcatalog definiert werden: crcatalog readcat;

Anschließend wird die #SQL-Anweisung statisch definiert und mit dem Datentyp readcat gleichgesetzt:

#sql readcat = {select catid, catname, releasedate, maxpartic, maxdocu from glbcatalog order by catname};

Somit repräsentiert readcat das Ergebnis der SQL-Anweisung. Dann kann mit einer while-Schleife durch die Datensätze gescrollt werden. Der Datentyp Catalog beinhaltet die Felder für die Informationen eines Kataloges. Es folgt ein Auszug aus der Datei AdministrationSer.sqlj:

1.Catalog catalog = new Catalog(); 2.while(readcat.next()) { 3.catalog.id = readcat.catid(); 4.catalog.catname = readcat.catname(); 5.catalog.releasedate = 6.

new java.util.Date(readcat.releasedate().getTime());

7.catalog.maxpartic = (readcat.maxpartic()); 8.catalog.maxdocu = (readcat.maxdocu()); 9.AD.catalogV.addElement(catalog); 10.catalog = new Catalog(); 11.} ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 60 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

12.readcat.close();

Es folgt eine kurze Erklärung: 1. Anlegen einer Instanz vom Typ Catalog 2. While-Schleife mit Abfrage, ob es einen nächsten Datensatz gibt 3. Die Informationen aus der Datenbank werden in die dafür vorgesehenen Felder in der Catalog-Klasse geschrieben. Es ist zu beachten, daß die Felder der Datenbank immer mit einer Doppelklammer enden (readcat.catid()) 4. siehe Punkt 3 5. Um die Datums-Struktur der Java- und Oracle-Implementierung zueinander kompatibel zu machen, muß hier die Funktion getTime() verwendet werden 6.-8. siehe Punkt 3 9. Aufnehmen der Informationen, die aus der Datenbank geholt wurden und mittlerweile in der Catalog-Klasse stehen. 10.Die Datenstruktur AD ist im Punkt Interfaces ausführlich erklärt 11.Anlegen einer neuen Instanz der Klasse Catalog 12.Ende der While-Schleife 13.Schließen des Iterators

In diesem Beispiel wurden alle Kataloge zusammen mit ihren zusätzlichen Informationen über maximale Anzahl der Review-Teilnehmer usw. in die dafür angelegte Datenstruktur geschrieben und an den Client zurückgegeben. Der Client kann nun diesen Vektor auswerten und die benötigten Informationen in die Masken schreiben. In obigem Fall füllt der Client eine ComboBox; um genau zu sein, eine JComboBox. Es ist Aufgabe des Clients, die Oberflächencontrols mit Daten zu füllen. Der Server und seine SQL-Befehle sind lediglich dazu da, die Anfragen des Clients zu bearbeiten und die benötigten Informationen als Ergebnismenge zurückzuliefern. Warum für Ergebnismengen die Klasse java.util.Vector verwendet wurde, liegt darin begründet, daß es sich in zweierlei Hinsicht bewährt hat. Zum ersten kann in der While-Schleife im Server mit der Methode Vector.addElement(Object obj) der Vector ganz einfach ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 61 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Element für Element gefüllt werden und zum anderen können Elemente eines Vektors verschiedene von der Klasse java.lang.Object abgeleitete Klassen enthalten. Man hätte statt Vector auch ein Object-Array verwenden können. Es wäre aber im großen und ganzen umständlicher zu handhaben gewesen.

So sind mehr oder weniger alle SQLJ-Routinen aufgebaut, die für das Review-Tool verwendet wurden. Nicht alle Methoden wurden nach dem SQLJ-Prinzip aufgebaut, so z. B. alle Suchfunktionen für bestimmte Elemente. Ich greife aus der Vielzahl an Suchfunktionen einfach das Beispiel "Projekte suchen" heraus. Für kompliziertere Suchfunktionen wurde ein eigener View in der Datenbank angelegt. Was ein View ist, wird im Abschnitt 7 näher erklärt. Momentan kann man sich unter einem View einfach eine ganz normale Datenbanktabelle vorstellen, die aus verschiedenen Tabellen zusammengewürfelt wurde. Nun zurück zur Funktion "Projekte suchen". Es wurde hierfür eine eigene Funktion in der dafür zuständigen Datei ProjectBaseSer.sqlj definiert, namens public Vector analyseQueryAP(Vector args). Der Vector args wird in der Suchfunktion aus der jeweiligen Maske erstellt und sieht in etwa wie folgt aus:

Catalog Location Business Field

"catname" "Project Review" "location" "Regensburg" "busifield" "AT PT SI"

Tabelle 12: Search-Vektor

In einer anderen Schreibweise sieht das in etwa wie folgt aus: Vector searchV = {{"catname","Project Review"},{"location","Regensburg"}, {"busifield","AT PT SI"}}; --> {{[Spaltenname in der Tabelle],[zu suchende Zeichenkette]},{...}} Diese Schreibweise übergibt also an den Server im ersten Element den Spalten____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 62 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

namen in der Datenbanktabelle in der das zweite Element gesucht werden soll. Die Suche bezieht sich ja nur auf den einen View, von dem vorher die Rede war, in diesem Fall projView. Auf diese Weise kann die Suchfunktion sehr leicht implementiert werden. Wie zuvor schon erwähnt, kann aber der SQL-Befehl nicht statisch ausgeführt werden, sondern er muß vor der Ausführung zuerst dynamisch festgelegt werden, da ja die Suche nach Elementen nicht immer gleich ist, bzw. nicht immer nach demselben Schema gesucht wird. Wie der dynamische SQL-Befehl nun zusammengesetzt wird, wird anschließend erläutert. In der Datei ProjectBaseSer.sqlj hat die Suche folgenden Aufbau: 1

try {

2

String query = DBTools.getSearchSQL(args,"projview");

3

LogFile.log.println("query: " + query);

4

Connection con = DefaultContext.getDefaultContext().getConnection();

5

Statement stmt = con.createStatement();

6

ResultSet rs = stmt.executeQuery(query); // Daten in Struktur kopieren

7

while (rs.next()) { project.proid = rs.getInt(1); project.radno = DBTools.copyString(rs.getString(2)); project.syspro = DBTools.copyString(rs.getString(3)); project.catalog.catname =

DBTools.copyString(rs.getString(4));

project.bf.bf = DBTools.copyString(rs.getString(5)); 8

project.proleader = DBTools.copyString(rs.getString(6)); project.proleaderdepart = DBTools.copyString(rs.getString(7)); project.teamleader = rs.getString(8); project.teamleaderdepart = DBTools.copyString(rs.getString(9)); project.qresponsname = DBTools.copyString(rs.getString(10)); project.qresponsdepart = DBTools.copyString(rs.getString(11));

9

retV.addElement(project); // Projekt zur Liste hinzufügen

10 project = new Project(); } 11 rs.close(); // cursor schließen 12 } catch (SQLException e) { 13 e.printStackTrace(LogFile.log); 14 throw new DBException("SQLException " + e.getMessage()); ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 63 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

11 rs.close(); // cursor schließen 15 } catch (Exception e) { 16 e.printStackTrace(LogFile.log); 17 throw new DBException("Server Exception " + e.getMessage()); } 18 return retV; // Datentransfer zum Client

Tabelle 13: Search-Funktion

Zur Erklärung: (1)Beginn des Try-Statements (2)Der String query wird mit einem Defaultstring vorbelegt. Query ist der String, der in dieser Funktion dynamisch erzeugt wird und anschließend an die Datenbank geschickt wird (3)Der String wird zur Kontrolle in die Logdatei Review.log geschrieben (4)Eine Instanz des Interfaces Connection wird erzeugt und vorbelegt (5)Eine Instanz des Interfaces Statement wird erzeugt und vorbelegt (6)Ein Objekt des Interfaces ResultSet wird erzeugt. Ein ResultSet wird durch das Ausführen des soeben generierten SQL-Befehls erzeugt. Die Zeilen (4)-(6) wurden ebenfalls aus dem Java Tutorial übernommen und können in dieser Form immer bei dynamisch generierten SQL-Befehlen verwendet werden. Auch ein ResultSet kann als Cursor betrachtet werden, wie es bei Iteratoren auch schon üblich war (7)Nun wird die zurückgelieferte Ergebnismenge untersucht. Es wird hier ebenfalls wie bei statischen SQL-Befehlen eine While-Schleife verwendet, um durch die Datensätze zu scrollen (8)Der Datentyp Project bzw. dessen Instanz wird so lange mit Daten gefüllt, solange es gültige Datensätze gibt. Ein ResultSet beinhaltet logischerweise wieder verschiedene Datentypen (Integer, String, Date, Boolean usw.), sodaß sie unterschiedlich in die Datenstruktur eingelesen werden müssen. Integerwerte aus dem ResultSet werden mit rs.getInt(int x) ausgelesen, wobei x den Spaltenindex darstellt. Strings werden mit rs.getString(int x) ausgelesen und Datumswerte mit ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 64 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

rs.getDate(int x) usw. Vielleicht kann man hier die Verwandtschaft zu Iteratoren feststellen (9)Der Datentyp Project wird an den Rückgabe-Vektor angefügt (10)Eine neue Instanz des Datentyps wird erzeugt, um Speicher für den nächsten Datensatz zu erhalten (11)Es sind keine weiteren Datensätze vorhanden. Aus diesem Grund wird der Cursor geschlossen (12)Es folgen die Fehlerbehandlungsroutinen. Zuerst wird SQLException abgefangen (13)Falls SQLException eintritt, wird eine entsprechende Fehlermeldung in die Logdatei geschrieben (14)Anschließend wird eine Datenbankausnahmebehandlung durch das Programm provoziert, um den Fehler noch genauer spezifizieren zu können (15)Eine allgemeine Exception wird abgefangen (16)Auch diese Fehlermeldung wird in der Logdatei vermerkt (17)Wieder wird eine allgemeine Exception abgefangen und eine entsprechende Fehlermeldung ausgegeben (18)Der in der While-Schleife gefüllte Vektor wird hier an den Client zurückgegeben. Man kann sich diesen Vektor in etwa folgendermaßen vorstellen:

Index

proid

radno

syspro

catalog.catname

[0]

1

71000186

Gate Unit 4

Project Review

[1]

2

31000215

Simtec70

Project Review

[2]

3

56000493

VLC-Stellsystem

Project Review

[3]

4

89490129

MS42

Project Review

.....

.....

.....

.....

.....

..........

.....

Tabelle 14: Gefüllter Vektor mit Projekt-Daten

Man kann dieser Tabelle leicht einen Teil der Datenstruktur des Typs Project entnehmen. Diese wird im Abschnitt Interfaces noch genauer erläutert.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 65 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

6.1.4 Interfaces und Datenstrukturen Interfaces spielen in der RMI-Architektur eine ganz entscheidende Rolle. Ein Interface ist, wie es auch in der deutschen Sprache übersetzt heißt, die Schnittstelle zwischen Client und Server (s. Kommunikation verteilter Objekte). Alle Interfaces, die zum Review-Tool gehören, wurden in dem dafür vorgesehenen Verzeichnis abgelegt (/HEITEC/Review/Code/review/interfaces).

Um sich ein Interface besser vorstellen zu können, folgt ein kleiner Ausschnitt aus dem Interface IAdministration: package review.interfaces; import java.rmi.Remote; import java.rmi.RemoteException; import java.util.*; import java.io.*;

public interface IAdministration extends Remote { public AdministrationData getAll() throws RemoteException, DBException; public void saveCatalog (Catalog catalog,int anzmil,String bezmil) throws RemoteException, DBException; public void saveMileStones(Vector descriptionV) throws RemoteException, DBException; public void removeCatalog(Catalog catalog) throws RemoteException, DBException; public void removeBF(BF bf) throws RemoteException, DBException; ..... ..... public int[][] getKoord(String catname) ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 66 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

throws RemoteException, DBException; public void saveKoord(int[][] koor, int catid) throws RemoteException, DBException; }

Wie man hier deutlich erkennen kann, besteht ein Interface mehr oder weniger nur aus Funktionsköpfen. Die Packages, die eingebunden wurden, stehen wie bei den Server-Dateien ganz am Anfang des Source-Codes. Typischerweise heißt das eingebundene Package der Übersichtlichkeit wegen review.interfaces. Die Import-Dateien java.rmi.Remote und java.rmi.RemoteException sind für das Anlegen von Interfaces im Zusammenhang mit RMI auch unbedingt notwendig. Warum diese nötig sind, werden wir gleich sehen. Der Kopf eines Interfaces wird anstatt mit public class mit public interface deklariert. Jedes RMI-Interface muß vom Remote-Interface aus dem java.rmi-Package abgeleitet sein. "Jedes Objekt, welches ein Remote Object darstellt, muß das Interface Remote direkt oder indirekt implementieren. Nur diese Interfaces sind remotemäßig verfügbar27". Ich möchte an dieser Stelle erwähnen, daß sich im Interface-Package des ReviewTools nicht nur Interfaces befinden, sondern auch die ganzen Datenstukturen, die da Tool umfaßt. Man braucht diese Information, um den ersten Funktionskopf public AdministrationData getAll() throws RemoteException, DBException;

in oben stehendem Interface zu verstehen. getAll() heißt in diesem Fall, daß eine ganze Maske des Clients gefüllt werden soll. Der Verständlichkeit wegen möchte ich hier die Administrationsmaske einmal anzeigen:

27 Java Plaform 1.2 API Specification ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 67 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Abbildung 15: Administrations-Maske Wie man sieht, sind hier drei Comboboxen mit Daten zu füllen. Um diese Aufgabe zu erledigen, ruft der Client die obenstehende Funktion auf. Doch was soll der Rückgabewert AdministrationData genau sein?

Wenn über ein Netzwerk Daten ausgetauscht werden, versucht man, den Aufbau von Verbindungen möglichst gering zu halten. Theoretisch wäre es möglich und auch einfacher, drei Funktionen im Interface zu verwenden:

public Vector getCatalogs() throws RemoteException, DBException;

 zum Holen der Catalog-Daten aus der Datenbank

public Vector getBF() throws RemoteException, DBException;

 zum Holen der Business-Field Daten aus der Datenbank

public Vector getLocations() throws RemoteException, DBException;

 zum Holen der locationspezifischen Daten aus der Datenbank ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 68 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Es müßten hier allerdings drei Verbindungen aufgebaut, sprich drei verschiedene Funktionen aufgerufen werden. Wenn man den im Review-Tool verwendeten Datentyp betrachtet, stellt man fest, daß nur eine Verbindung benötigt wird. Um sich die ganze Theorie besser vorstellen zu können, ist es sinnvoll, die Datenstruktur AdministrationData hier kurz vorzustellen: public class AdministrationData implements Serializable { public Vector catalogV = new Vector(); public Vector bfV = new Vector(); public Vector locationV = new Vector(); }

Wiederrum kommt in den Datenstrukturen, die mit RMI arbeiten, eine Besonderheit vor. Sie müssen, wie man oben sieht, vom Interface Serializable abgeleitet werden, um "serialisierbar" zu sein. Serialisierbarkeit einer Klasse wird eben durch diese Direktive ermöglicht. Klassen, die dieses Interface nicht implementieren, haben diesen Status nicht. Alle Subtypen von serialisierbaren Klassen haben ihrerseits diese Funktion. Das Serializable Interface beinhaltet keinerlei Funktionen, Methoden oder Felder. Es ist nur dazu da, die Semantik der Serialisierbarkeit zu ermöglichen28. Dem Funktionskopf in obiger Klasse folgen drei Variablen vom Typ Vector. Das "V" hinter jeder Variable bedeutet Vector und dient lediglich der besseren Übersichtlichkeit und wurde von mir als Konvention für das Review-Tool festgelegt. In der Definitionszeile wird auch gleich ein neues Objekt des Typs erzeugt, um ihn gleich verwenden zu können. Sicherlich ist aufgefallen, daß die Namen der Variablen mit den Namen der Comboboxen in obiger Maske übereinstimmen. Vielleicht wird nun das Prinzip der Funktion getAll() im Interface etwas klarer. Um es noch klarer zu machen, kommt an dieser Stelle eine kleine Tabelle, die den mit Informationen ge-

istrationData

füllten Datentyp AdministrationData zeigt, wie er vom Server zurückgeliefert wird:

28 Java Plaform 1.2 API Specification ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Ad

Diplomarbeit SS 99/00

- 69 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Vector catalogV id

catname

releasedate

maxpartic

maxdocu

1

Project Review

14.08.99

14

8

2

Project Review

19.10.99

10

7

3

Project Review

24.11.99

14

3

.........

.........

.........

.........

.........

Vector bfV id

bf

1

AT PT SI

2

AT PT EL

3

AT SE SC3

.........

......... Vector locationV

lid

lname

1

Regensburg

2

Würzburg

3

München

Tabelle 15: Beispiel der Datenstruktur AdminisrationData

Man kann sich mit dieser Tabelle wahrscheinlich jetzt besser vorstellen, welche Datenmengen zwischen Client und Server ausgetauscht werden, jedoch alles nur in einer strukturierten Klasse - AdministrationData.

Aus dieser Tabelle ist leicht ersichtlich, wie die drei Vektoren aufgebaut sind. Der Verständlichkeit wegen, möchte ich sie hier nochmal kurz aufführen:

class Catalog int id; String catnam e; java.util.Date releas edate; Double m axpartic; Double m axdocu;

class BF int id; String bf;

class Location int lid; String lnam e;

Abbildung 16: Klassen Catalog, Business Fields und Location ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 70 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Die Funktionsweise und das Arbeiten mit Interfaces sollte jetzt ungefähr klar geworden sein.

Um bei diesem Ansatz des Designs von Datenstrukturen weiter zu machen, möchte ich jetzt auf das komplizierteste Beispiel eingehen, das innerhalb des Review-Tools verwendet wurde. Strukturen wie AdministrationData wurden zahlreich verwendet und eingesetzt. Ich möchte aber hier als Beispiel noch die Struktur CheckListData anbringen, die einige Überlegungen kostete. Wie der Name der Struktur schon sagt, ging es hier um eine Checkliste für Reviews, die aus verschiedenen Daten bestand. Zum ersten beinhaltet eine Checkliste sogenannte Topics, zu deutsch Überschriften für bestimmte Review-Fragen. Diese Topics mußten wieder in einzelne diesen Topics zugeordneten Fragen untergliedert werden, die anschließend wiederum vom Benutzer entsprechend bewertet werden mußten. Um sich unter der ganzen Theorie etwas vorstellen zu können, möchte ich hier die Maske Checklist einmal anzeigen:

Abbildung 17: Maske Checklist

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 71 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Man kann hier einen Fragenkatalog erkennen, der einem bestimmten Catalog, einem BusinessField, einer oder mehreren Locations und einem Topic zugeordnet ist. Zusätzlich sieht man hinter den Fragen die Werte Not Relevant, OK und Comment. All diese Daten mußten zusammengefaßt werden. Die ganze Systematik in Worten zu erklären, stiftet meistens große Verwirrung. Deshalb möchte ich hier die erstellte Datenstuktur graphisch darstellen:

Abbildung 18: Datenstruktur der Klasse CheckListData ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 72 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Topic

Catalog int id String catname Date releasedate Double maxpartic Double maxdocu

CheckListData Catalog BF Location TopicQuestion[] ...

BF

int id String topicD String topicE String topicF

TopicQuestion[] QuestionCheck[] questioncheck Boolean notrelevant Boolean ok Boolean comment

int id String bf

Question Location int lid String location

Integer questid Catalog catalog Topic topic Location location Vector bfV int doc int eop String questnamed String questnamee String questnamef int mandatory

QuestionCheck[] Boolean notrelevant Boolean ok Boolean comment

Hier kann in der Mitte deutlich die Klasse CheckListData erkennen, welche sozusagen die Hauptklasse für obige Liste darstellt und alle Daten beinhaltet, die dafür notwendig sind. Die Arrays TopicQuestion[] und QuestionCheck[], jeweils von der Oberklasse Topic und Question abgeleitet, werden deshalb gebraucht, weil eine Checkliste mehrere Topics und ein Topic wieder mehrere Questions haben kann. Dies wird klarer, wenn man bedenkt, daß in der Combobox Topic viele verschiedene Werte zur Auswahl stehen, für die jeweils wieder eine eigene Question-Liste generiert wird.

6.1.5 Client Der Client stellt den eigentlichen „Auftraggeber“ für den Server dar und beauftragt ihn, bestimmte Daten aus der Datenbank zu holen. Der Client im Review-Tool besteht aus folgenden Komponenten: ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 73 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________



Einbindung der benötigten Bibliotheken



Klassenkopf mit dem Namen der Klasse



Klassenvariablen, die im Client verwendet werden. Dazu zählen neben den Laufvariablen die Definition der Oberflächenelemente, auch Controls genannt und die Hilfsvariablen



Im Konstruktor wird das globale Layout einer Maske aufgebaut und für bestimmte Controls sogenannte Listener definiert



Funktionen, die innerhalb der Maske verwendet werden

Tabelle 16: Aufbau eines Client-Programms

Wie schon in der Tabelle ersichtlich ist, werden im Client das Layout und die Oberflächenelemente festgelegt und entsprechend initialisiert. Wie sich ein solches Layout bzw. das Oberflächendesign aufbaut, wird anschließend erklärt.

6.1.5.1 Oberflächendesign und Layout von Java In diesem Abschnitt soll gesondert auf die Entwicklung graphischer Benutzeroberflächen unter Java eingegangen werden, da sie einen Schwerpunkt des Review-Tools darstellt.

In den meisten Fällen werden die Komponenten der graphischen Benutzeroberflächen durch Angabe absoluter Koordinaten vorgenommen. Für jede Komponente wird manuell oder mit Hilfe eines GUI-Builders die pixelgenaue Position bestimmt, an der sie erscheinen soll. Anwendungen, die in Java geschrieben wurden, sollen auf unterschiedlichen Plattformen mit unterschiedlichen Ausgabegeräten laufen können. Aus diesem Grund reicht die Anordnung der Komponenten mit absoluten Koordinaten nicht aus, da die verschiedenen Systeme auch jeweils unterschiedliche Darstellungsarten unterstützen. Als Lösung entwickelte die Firma Sun den Umweg über Layoutmanager, die für die Anordnung der Komponenten verantwortlich sind. Jede Komponente, die andere graphische Komponenten aufnehmen und darstellen kann (auch als Container be____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 74 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

zeichnet, z.B. Applets, Frames, Dialoge usw.), enthält einen Layoutmanager, der wiederum verschiedene Layouts annehmen kann. Mit der Klassenbibliothek des JDK werden sechs Layoutvarianten ausgeliefert. Diese Layouts können allerdings beliebig erweitert werden. Die Eigenschaften dieser sechs Layoutmanager werden im folgenden kurz erläutert. Sie wurden im übrigen aus dem Java Tutorial übernommen.

FlowLayout Das FlowLayout entspricht der einfachsten Layoutvariante, die das JDK bietet. Das FlowLayout ordnet die graphischen Elemente nebeneinander in einer Zeile an. Wenn keine weiteren Elemente in die Zeile passen, wird in der nächsten Zeile fortgefahren. Die Anordnung der Elemente wird durch die Reihenfolge bestimmt, in der sie aufgrund des Programmcodes eingefügt werden. Die Größe der Komponenten wird dabei vom System bestimmt. Die Größe einer Schaltfläche (Button) wird z.B. aufgrund seiner Beschriftung (Label) festgelegt. Als weitere Einstellung kann hier lediglich zwischen linksbündiger, rechtsbündiger oder zentrierter Anordnung der Komponenten gewählt werden. Ein Beispiel für ein FlowLayout sieht folgendermaßen aus:

Abbildung 19: FlowLayout

GridLayout Das GridLayout ordnet graphische Elemente in einem rechteckigen Gitter an. Die Spalten- und Zeilenzahl dieses Gitters sind einstellbar. Die Größe der Komponenten wird durch die Maße der einzelnen Zellen des Gitters bestimmt und ist weiter nicht veränderbar. Verändert man hingegen die Größe des Containers, ändert sich die Größe der Felder im GridLayout und in Abhängigkeit davon auch die Maße der eingefügten Komponenten. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 75 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Ein Beispiel für ein GridLayout sieht folgendermaßen aus:

Abbildung 20: GridLayout

BorderLayout Mit dem BorderLayout können graphische Elemente auf die vier Randbereiche und den Mittelbereich eines Containers (z.B. eines Fensters) aufgeteilt werden. Der Plazierungsbereich wird durch die vier Himmelsrichtungen South, North, East, West und durch Center bestimmt. Bezüglich der Skalierung der Komponenten kann das BorderLayout als eine Art Mischform zwischen dem FlowLayout und dem GridLayout betrachtet werden. Beim BorderLayout sind die nördlich und südlich angeordneten Elemente in horizontale Richtung skalierbar und in der Höhe konstant. Die westlich und östlich angeordneten Elemente werden dagegen in vertikaler Richtung skaliert, wenn z.B. die Größe eines Fensters mit der Maus verändert wird. Anders verhält sich ein graphisches Element, das im "Center"-Bereich eines Fensters angeordnet wurde. Dieses paßt sich den Größenänderungen des Fensters sowohl in vertikaler als auch in horizontaler Richtung an. Ein Beispiel für ein BorderLayout sieht folgendermaßen aus:

Abbildung 21: BorderLayout

CardLayout Das CardLayout ist in der Lage, mehrere verschiedene Seiten anzulegen, wobei ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 76 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

immer nur eine Seite sichtbar ist (ähnlich einem Karteikasten). Jede Seite kann nur ein grafisches Element aufnehmen. Über Methoden der Klasse CardLayout kann zwischen den einzelnen Seiten umgeschaltet werden. Ein Beispiel für ein CardLayout sieht folgendermaßen aus:

Abbildung 22: CardLayout

BoxLayout Das BoxLayout ordnet seine Komponenten in einer einzigen Reihe oder Spalte an. Es nimmt die maximale Größe der jeweiligen Komponenten und erlaubt auch das Ausrichten der Elemente. Ein Beispiel für ein BoxLayout sieht folgendermaßen aus:

Abbildung 23: BoxLayout

GridBagLayout Das GridBagLayout bildet das komplexeste Layout des JDK mit den meisten Möglichkeiten für die Anordnung der Komponenten in einem Container. Bei diesem Layout wird die mit Komponenten zu bestückende Fläche wie beim GridLayout in Spalten und Zeilen unterteilt, die sich allerdings in Breite und Höhe unterscheiden können. Mit Hilfe von Bedingungsobjekten, den sogenannten GridBagConstraints, können graphische Komponenten in diesem Layout positioniert werden. Auch die ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 77 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Eigenschaften des BorderLayouts können hier mit Hilfe der Bedingungsobjekte umgesetzt werden. Neben den angesprochenen Möglichkeiten können graphische Komponenten auch ohne einen Layoutmanager in einem Container positioniert werden. Dies geschieht über das Null-Layout oder anders ausgedrückt, es wird kein Layoutmanager verwendet. In diesem Fall können die Komponenten auch mit Angabe fester Koordinaten gesetzt werden. Die Komponenten passen sich dann allerdings nicht dynamisch den Größenveränderungen z.B. eines Fensters (Frame) an, sondern verhalten sich ausnahmslos statisch. Um mit Hilfe der Layoutmanager eine gewünschte Benutzeroberfläche realisieren zu können, reicht das normale Verwenden der Layoutmanager nicht aus. In Java ist es allerdings möglich, mehrere Layouts ineinander zu verschachteln, bis die Oberfläche das erforderliche Maß an Flexibilität bietet. Dies kann z.B. über die Zuhilfenahme von Panel-Objekten geschehen. Bei einem Panel handelt es sich um ein graphisches Element, das in einem Container plaziert werden kann. Ein Panel kann ebenfalls graphische Elemente, angeordnet durch Layoutmanager, aufnehmen. Durch Aufnahme von Panel-Objekte lassen sich diese beliebig verschachteln. Ein Beispiel für ein GridBagLayout sieht folgendermaßen aus:

Abbildung 24: GridBagLayout

Im Review-Tool wurden allerdings nur die Layouts ●

FlowLayout



BorderLayout



GridLayout

und ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 78 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________



GridBagLayout

verwendet. Meiner Meinung nach reichen diese vier Layouts auch völlig aus, um jegliche Art von Masken zu erstellen.Die obigen Dialoge sind sichtlich recht einfach aufgebaut und dienen hier nur als Beispiel für das grundlegende Verständnis. Im Review-Tool mußten in den Masken mehrere Layouts ineinandergeschachtelt werden, um brauchbare Ergebnisse zu erzielen. Als Beispiel möchte ich hier die Maske AdminGlobalCatalog verwenden:

GridBagLayout FlowLayout

GridBagLayout GridLayout

Abbildung 25: Beispiel für Layouts im Review-Tool Man kann an diesem Beispiel sicherlich erkennen, wie die einzelnen Layouts inein____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 79 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

andergeschachtelt wurden. Ein FlowLayout, wie es oben sichtbar ist, würde man in Java folgendermaßen definieren: JPanel pane = new JPanel(new FlowLayout()); JPanel entspricht einem container-artigen Objekt und es können mehrere Elemente in das Panel aufgenommen werden. Im übrigen wurden alle Layouts mittels dieser Panels realisiert. Dieses Verfahren gewährleistet eine optimale Übersichtlichkeit, gerade dann, wenn komplexere Layouts darzustellen sind. Das FlowLayout ist wohl das einfachste und am schnellsten zu implementierende Layout, das Java unterstützt.

Das zweite Layout in obiger Maske ist das GridLayout, das wie folgt definiert wird: JPanel pane = new JPanel(new GridLayout(6,1,0,0));

Die in den Klammern erforderlichen Parameter bedeuten, daß 6 Zeilen und 1 Spalte mit minimalem Abstand erzeugt werden sollen. Der dritte und vierte Parameter könnten hier den Abstand zur nächsten Zeile und zur nächsten Spalte in Pixel angeben. GridLayouts sind eine weitere Möglichkeit, schnell gutaussehende Layouts zu erzeugen, wenn sie nicht zu kompliziert sind.

Kommen wir nun zu dem kompliziertesten Layoutmanager, dem GridBagLayout. Das GridBagLayout kann optimal benutzerdefiniert angepaßt werden, benötigt aber einige Einarbeitungszeit, um halbwegs vernünftige Ergebnisse damit erzielen zu können. Man sieht an der Grafik schon die willkürliche Anordnung der Elemente. Diese Diplomarbeit soll kein Manual darstellen, deshalb möchte ich hier nur kurz und oberflächlich auf die Einsetzung des GridBagLayouts im Review-Tool eingehen. Es wurde in allen komplizierteren Masken im Review-Tool ein globales GridBagLayout folgendermaßen definiert: JPanel pane = new JPanel(); GridBagLayout gridbag = new GridBagLayout(); GridBagConstraints c = new GridBagConstraints(); pane.setLayout(gridbag);

Damit steht das Grundgerüst eines GridBagLayouts und es müssen nun noch die ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 80 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Controls und Elemente hinzugefügt werden. Wenn man wieder die obige Maske vor Augen hat, so wurde das innere GridBagLayout in etwa wie folgt zusammengesetzt: // Add Label "QuestionID" c.gridx = 0; c.gridy = 0;

Diese beiden Befehle geben die Position bzw. die Koordinaten an, an der das entsprechende Element plaziert werden soll. Es wird mit Hilfe der GridBagContraints gelöst. c.insets = new Insets(3,3,3,5);

Dieser Befehl ist für den Abstand zwischen den jeweiligen Controls verantwortlich und zwar in der Reihenfolge NORTH, WEST, SOUTH und EAST. Die Werte bleiben auch für nachfolgende Elemente bestehen, außer sie werden explizit geändert. c.anchor = GridBagConstraints.WEST;

Dieser Befehl ist für das Ausrichten des Elements in seinem eigenen Bereich zuständig. In diesem Fall wird das Element ganz links plaziert. gridbag.setConstraints(questionIDL,c);

Hier werden die zuvor festgelegten Constraints quasi in das Layout mit übernommen und festgelegt. pane.add(questionIDL);

Das Label „Question ID“ wird nun endlich in das Panel mit aufgenommen. // Add TextField "QuestionID" c.gridx = 1; c.gridy = 0; gridbag.setConstraints(questionIDTF,c); questionIDTF.setEditable(false); pane.add(questionIDTF); // Add Label "Topic" c.gridx = 0; c.gridy = 1; c.anchor = GridBagConstraints.WEST; gridbag.setConstraints(topicL,c); pane.add(topicL); // Add ComboBox "Topic" c.gridx = 1; c.gridy = 1; ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 81 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

gridbag.setConstraints(topicCoB,c); pane.add(topicCoB); // Add Label "Catalog" c.gridx = 0; c.gridy = 2; gridbag.setConstraints(catalogL,c); pane.add(catalogL); ...... ......

Wenn man sich den Ausschnitt des Listings einmal genauer ansieht und es mit der Maske vergleicht, kann man sehr schnell feststellen, wie sich das Layout zusammensetzt. Auch wenn das Erstellen eines GridBagLayouts sehr umständlich und zeitaufwendig ist, kann man doch so die maximale benutzerdefinierte Ausrichtung der Elemente erreichen. Man sollte jedoch zuvor überlegen, ob man nicht doch mit einem einfacheren Layoutmanager auskommt, da der besagte nicht unbedingt einfach zu handhaben ist.

Um nochmal auf die Maske Admin Global Catalog zurückzukommen - es existiert auch noch ein globales GridBagLayout. Alle Panels, die zuvor erstellt wurden, sei es FlowLayout, GridLayout oder BorderLayout, wurden wiederrum mit einem GridBagLayout in die Maske mit eingebunden.

So und in ähnlicher Weise wurden alle Layouts des Review-Tools erstellt. Wer über Oberflächendesign in Java noch mehr in Erfahrung bringen will, der sei auf das Java Tutorial von der Firma Sun verwiesen. Es ist dort auf der Homepage zum Download bereitgestellt.

6.1.5.2 RMI-Handling im Client ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 82 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Logischerweise gehört zu einem RMI-System neben dem Server und den Interfaces auch ein Client, der seinerseits RMI-Variablen und –Konstrukte initialisieren muß. Um der Form treu zu bleiben, möchte ich kurz ein kleines Beispiel anführen, wie die RMI-Architektur im Client aussieht. Zur Demonstration werden die Variablen aus der Datei MainSelection.java verwendet:

// RMI Variables "MainSelection" (1)String rmiHost = Host.rmiHost; (2)String rmiInterfaceName = "/review/interfaces/IMainSelection"; (3)IMainSelection handle; (4)String serverName = "//" + rmiHost + rmiInterfaceName;

In dieser Form wurde in allen Client-Dateien jeder Maske das RMI-Handling festgelegt. Was bedeuten diese Befehle nun im einzelnen?

(1)Der String-Variablen rmiHost wird der Name des Hosts zugewiesen, der in der Klasse Host mit HEINux festgelegt wurde (2)Anschließend wird die Variable rmiInterfaceName mit dem Namen des jeweiligen Interfaces initialisiert, in diesem Fall mit IMainSelection (3)Hier wird eine Instanz bzw. ein Handle auf das jeweilige Interface definiert, mit dem später im Programm auf die Funktionen, die im Interface definiert wurden, zugegriffen werden kann (4)Hier wurde sozusagen der String zusammengesetzt, mit dem später das Handle auf das Interface initialisiert wird

Wie wird nun im Hauptprogramm des Clients vorgegangen, um die Kommunikation mit dem Server über die Interfaces zu ermöglichen?

Da die ganze Problematik mit Kommunikation zu tun hat und es natürlich Probleme innerhalb der Kommunikation geben kann, beispielsweise, wenn der Review-Server nicht gestartet wurde, müssen die entsprechenden Befehle innerhalb eines try-State____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 83 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

ments stehen. Dies sieht in etwa wie folgt aus:

// RMI Calls (1)try { (2)handle = (IMainSelection)Naming.lookup(serverName); // Catalogs, Business Fields and Locations (3)MainSelectionData mainSelectionData = new MainSelectionData(); (4)mainSelectionData = handle.getAll(); // Put data in ComboBoxes (5)for (int i=0; i < mainSelectionData.catalogV.size(); i++) { catalogCoB.addItem(((Catalog)mainSelectionData. catalogV.elementAt(i)).catname); catid[i] = ((Catalog)mainSelectionData.catalogV.elementAt(i)).id; } ...... ......

Zur Erklärung: (1)Das Try-Statement beginnt (2)Hier wird das zuvor angelegte Handle bzw. der Zeiger auf das Interface IMainSelection am Namensdienst angemeldet, so daß die sogenannte RMI-Registry weiß, welches Interface dem Server zur Verfügung gestellt werden muß (3)Eine Instanz der Datenstruktur MainSelectionData wird angelegt, in die anschließend die Werte, die der Server zurückliefert, gespeichert werden können (4)Der eigentliche RMI-Call wird gestartet und die Struktur mit den Daten, die der Server liefert, gefüllt (5)Nun ist aber bekanntlich die weitere Aufgabe des Clients nicht nur das Holen der Daten vom Server, sondern auch das Auswerten und das Füllen der Oberflächenelemente in der Maske selbst. In diesem Beispiel wird eine for-Schleife so lange durchlaufen, bis alle Elemente aus dem Vektor catalogV ausgelesen und in die dafür angelegte Combobox geschrieben wurden ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 84 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

So läuft praktisch das ganze RMI-Handling im Review-Tool von der Client-Seite ab. Es gibt eigentlich dazu nicht mehr zu sagen, da sich dieses Verfahren durch das ganze Tool zieht.

6.1.6 Tools Im Verzeichnis „/HEITEC/Review/Code/review/tools“ befinden sich einige spezielle Hilfsroutinen, die in das Review-Tool mit aufgenommen wurden. Es werden im Tool ja ziemlich viel Tabellen verwendet, die verschiedene Besonderheiten aufweisen müssen. Als Beispiel sei hier ein Datumswert erwähnt, der nicht als normaler String behandelt werden soll. Vielmehr soll gleich bei der Eingabe des Datums in einer Tabelle die Korrektheit der Eingabe überprüft und Datum anschließend in der Zelle zentriert werden. Die Überprüfung hat man sich so vorzustellen:

Beispiele: Aus 3.1.99 wird 03.01.1999 Aus 25/07/99 wird 25.07.1999 oder nach der Eingabe von 31.xa.99 erscheint eine entsprechende Fehlermeldung mit der Aufforderung zur Korrektur des Datums. Dazu ist sowohl das Umschreiben des Standard-TableCellRenderers als auch des Standard-TableCellEditors nötig. Es müssen also zwei neue Klassen von diesen beiden abgeleitet werden und den Bedürfnissen entsprechend angepaßt werden. Auf eine Source-Code-Beispiel möchte ich an dieser Stelle verzichten. Der Renderer sorgt für die zentrierte Darstellung des Datums-Objekts und der Editor ist für die korrekte Eingabe zuständig. Man kann vielleicht an diesem Beispiel auch sehen, wie mächtig die Sprache Java ist. Es kann im Prinzip alles so angepaßt werden, wie man es wünscht, vorausgesetzt, man hat das nötige Knowhow. Solche und ähnliche Funktionen wurden also im Verzeichnis tools festgehalten. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 85 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Kommen wir nun aber zu einem etwas komplexerem Beispiel, der Search-Funktion des Review-Tools. Auf diese Funktion bin ich ganz besonders stolz, da sie sehr trickreich gestaltet wurde. Um sich die Suchfunktion vorstellen zu können, folgt ein Screenshot:

Abbildung 26: Suchfunktion des Review-Tools Diese Suchmaske wird in jeder Maske, in der eine Suche vorgesehen ist, verwendet und den jeweiligen Anforderungen angepaßt. Welche Suchkriterien in der jeweiligen Maske verwendet werden dürfen, wird durch die roten Felder in der ersten Spalte gekennzeichnet. Obige Suche entspricht der Maske AdminProjects: ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 86 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Abbildung 27: Maske Admin Projects

Nun kommen wir zu den Besonderheiten der Implementierung in obiger Suchmaske. Man kann sehen, daß dort ein Tabellenelement, sprich die Swing-Klasse JTable verwendet wurde. Betrachtet wird im folgenden die 3. Spalte dieser Tabelle, also die, in der die Suchkriterien eingegeben werden. Es wurden hier verschiedene Controls in einer Spalte verwendet, zum einen sind es Comboboxen, wie z. B. bei Catalog, zum anderen sind es Checkboxen und Textfelder. Eine solche Tabelle ist aber nicht so ohne weiteres zu entwerfen, das das zuständige TableModel nur ein bestimmtes Element in einer Spalte unterstützt, also z. B. nur Comboboxen oder nur Textfelder. Die zuständige Funktion im TableModel, die die entsprechende Spalte als Wert zurückgibt, heißt public Class getColumnClass(int c) { ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 87 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

return getValueAt(0, c).getClass(); }

Diese Funktion liefert die Klasse oder das Element einer Spalte zurück. Ich habe aber in obiger Maske verschiedene Elemente in einer Spalte gebraucht und deshalb war es notwendig, die Tabelle folgendermaßen anzulegen:

void paintFields() { TableColumn tableColumn; searchTable = new JTable(29,3) { public TableCellRenderer getCellRenderer(int row, int column) { tableColumn = getColumnModel().getColumn(column); TableCellRenderer renderer = tableColumn.getCellRenderer(); if (renderer == null) { Class c = getColumnClass(column); if(c.equals(Object.class)) { Object object = getValueAt(row,column); if(object != null) { c = getValueAt(row,column).getClass(); } } renderer = getDefaultRenderer(c); } return renderer; } public TableCellEditor getCellEditor(int row, int column) { TableColumn tableColumn = getColumnModel().getColumn(column); TableCellEditor editor = tableColumn.getCellEditor(); if (editor == null) { Class c = getColumnClass(column); if(c.equals(Object.class)) { Object object = getValueAt(row,column); if(object != null) { ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 88 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

c = getValueAt(row,column).getClass(); } } editor = getDefaultEditor(c); } return editor; } }; ..... .....

Ich bin der Meinung, daß auf dieses Code-Beispiel auf keinen Fall verzichtet werden kann, da es einen Kernpunkt der Tools darstellt und auch jederzeit weiterverwendet werden kann, falls eine solche Tabelle benutzt wird. Auf die einzelnen Befehle möchte ich jetzt nicht weiter eingehen, da das den Rahmen sicherlich sprengen würde.

7 Die Review-Datenbank Durch die vorangegangen Seiten sollte sich der Leser einen kleinen Überblick über die vorhandene Problematik geschaffen haben, so daß er nun in der Lage ist, die kommenden Ansätze zu verstehen und nachvollziehen zu können.

7.1 Importierung der Daten Da ja das Review-Tool bereits in Access existierte und der Datenbank-Aufbau sehr übersichtlich und gut gestaltet war, konnte man eine Migration der Datenbank in Oracle vornehmen. Eine solche Datenbank-Importierung kann mit dem Oracle Migration Assistant recht einfach und zügig durchgeführt werden. Dieses Tool erstellt neben den Tabellen und deren Beziehungen auch Tablespaces (Festplattenplatz für Datensätze), Trigger (Datenbank-Makros, z. B. zur Indexverwaltung) und kleine ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 89 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

PL/SQL-Skripte. Wenn man diese Datenbank nun noch einem Benutzer zuordnet, den man vor oder nach der Migration anlegt, kann über diesen auf die entsprechenden Tabellen zugegriffen werden.

7.2 Ursprüngliche Datenbank Die vorhandene Datenbank sah ursprünglich folgendermaßen aus: Global Questions

Edit Date: 07.12.99 21:04:50

Description:

Target DB: Access

Rev: 0

Filename: Draw ing1

Creator: Chris Company: My Company

glbQuestBusiField

glbBusifield

QuestID BFID

BFID BusiField glbQuestion QuestID glbCatalog CatID CatName ReleaseDate MaxPartic MaxDocu

CatID TopicID DOC EOP QuestNameD QuestNameD2 QuestNameE QuestNameE2 QuestNameF QuestNameF2

glbQuestMileStone QuestID MileStoneID CatID

glbTopic TopicID TopicNameD TopicNameE TopicNameF

glbMileStone

relCbiMileStone

MileStoneID CatID

MileStoneID CatID CombiNo

MileStoneName MileStoneFullName

Abbildung 28: Datenbankstruktur Global Questions Abbildung 29: Datenbankstruktur Projects und Questions

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 90 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Project Questions

Edit Date: 07.12.99 21:06:30

Description:

Target DB: Access

Rev: 0

Filename: Draw ing1

Company: My Company

proInvit proGeneral

InvitID

ProID

ProID RevDate RevBegin RevEnd Room Location ModerName ModerDepart ModerTelefon RevName

CatID BFID RaDNo SysPro TeamLeaderName TeamLeaderDepart QResponsName QResponsDepart ProLeaderName ProLeaderDepart

Creator: Chris

proDocument DocID InvitID DocTitle DocNo DocType

proPartic ParticID

proQuestion

InvitID ParticName ParticDepart ParticLocation ParticInformed ParticAuthor ParticModerator

QuestID proTopic TopicID TopicNameD TopicNameE TopicNameF

ProID TopicID QuestNameD QuestNameE QuestNameF QuestNameD2 QuestNameE2 QuestNameF2

proQuestMileStone QuestID MileStoneID CatID

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 91 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Project Questions

Edit Date: 07.12.99 21:06:56

Description:

Target DB: Access

Rev: 0

Filename: Draw ing1

Creator: Chris Company: My Company

locCatalog CatID CatName

locQuestion

locQuestBusiField

QuestID

QuestID BFID

CatID TopicID QuestNameD QuestNameE QuestNameF QuestNameD2 QuestNameE2 QuestNameF2

locTopic TopicID TopicNameD TopicNameE TopicNameF

Abbildung 30: Datenbankstruktur Special Questions

7.3 Erweiterung der vorhandenen Datenbank Die von Siemens geforderten Erweiterungen des Review-Tools erforderten auch eine weitgehende Erweiterung der Datenbank-Struktur. Die Erweiterungen wurden folgendermaßen formuliert: ●

Weltweite Verfügbarkeit und Änderbarkeit über Intranet bzw. Internet



Hierarchischer Paßwortschutz



Eingabemöglichkeit der Reviewergebnisse: ausgefüllte Checklisten, Kommentare, Status



Kopplung der Teilnehmerauswahl an Email-System (automatischer Versand der Unterlagen)



Generierung von Berichten aus Review-Ergebnissen ➔

ABC-Analyse über häufigste Fehlerursachen



Statusverfolgung über alle Projekte in einem GZ

Tabelle 17: Zusätzliche Anforderungen für die Neuimplementierung des Review-Tools Nach Absprache mit dem Einkauf von Siemens wurden noch folgende zusätzliche ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 92 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Erweiterungen angeboten: ●

Checklisten können zusätzlich auch noch spezifisch für eine „Location“ sein, d. h. die Fragen, die zu einer Location gehören, werden an die Standard-Fragen angehängt



Administration von Catalogs, Business Fields, Location und Milestones



Benutzerverwaltung und -administration



Klassifizierung von Comments

Tabelle 18: Angebotene Erweiterungen

Die Datenbank mußte aufgrund dieser Erweiterungen entsprechend angepaßt werden. Die folgende Grafik zeigt die erweiterte Datenbankstruktur. Die fettgedruckten Tabellennamen stellen die neuen Elemente dar: glbBusifield Docum e nt

BFID

glbQuestBusiField

BusiField

QuestID BFID

Doc CatID DocName

glbQuestion QuestID CatID TopicID DOC EOP QuestNameD QuestNameD2 QuestNameE QuestNameE2 QuestNameF QuestNameF2 LID

GQue s tToDoc QuestID Doc CatID

glbCatalog CatID CatName ReleaseDate MaxPartic MaxDocu

glbQuestMileStone QuestID MileStoneID CatID

Com m e nts CLID QuestID Comments Type

glbTopic TopicID

glbMileStone

relCbiMileStone

TopicNameD TopicNameE TopicNameF

MileStoneID CatID

MileStoneID CatID CombiNo

Location LID LName

CLQue s t CLID TopicID QuestID NotRelev Ok Comm FullComm

MileStoneName MileStoneFullName

RUs e r

Che ck Lis t CLID

Groups

GID LID BFID CatID

GID GName

UsrID GID Acc Pas ExpDate FamName FirstName Comm

Rights AID GID Rig

Actions AID Acti

Abbildung 31: Erweiterte Datenbank Es sind folgende Tabellen hinzugekommen: ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 93 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Neue Tabellen CheckList CLQuest

Beschreibung Diese beiden Tabellen sind für die Checkliste (s. Abb. Maske Checkliste) zuständig und halten die entsprechenden Daten bereit Diese beiden Tabellen sind für die User-Verwaltung

RUser

ausschlaggebend. In RUser werden die ganzen Informationen über den Benutzer gespeichert und in Rights werden die Rechte aus der Tabelle Actions dem User je nach Berechtigungen zugewiesen

Rights

Diese Tabelle beinhaltet eine Beschreibung der mögliActions

chen Aktionen, die ein User ausführen oder nicht ausführen darf

Groups Comments

Hier werden die vier Gruppen Administrator, BF-Responsible, Review Agent und Guest verwaltet In dieser Tabelle werden die Kommentare in der Checkliste zu den entsprechenden Fragen festgehalten Hier werden die sogenannten Sub-Dokumente zu den

Document

Fragen festgehalten. Jeder Catalog ist nochmal in verschiedene Sub-Dokumente untergliedert, so daß eine nähere Spezifizierung der Fragen festgehalten werden kann

GQuestToDoc Location

Dies ist eine Verknüpfungstabelle, in der die Fragen aus Global Questions einem Dokument zugeordnet werden In dieser Tabelle werden die Standorte der Siemens-Niederlassungen eingetragen

Tabelle 19: Neue Datenbanktabellen

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 94 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8 Beschreibung des Review-Tools In diesem Kapitel soll die Funktionsweise des Review-Tools ausführlich beschrieben werden. Für was das Tool gebraucht wird, wird im Kapitel 2 kurz beschrieben. Hier werde alle Masken zusammen mit ihren Eingabemöglichkeiten erklärt. Angefangen wird mit dem Login-Dialog.

8.1 Login Maske

Abbildung 32: Login-Dialog

Erklärung Hier loggt sich der Benutzer ein. Ein Benutzer ist einem der vier Gruppen Administrator, BF-Responsible, Review-Agent oder Guest zugeordnet. Je nachdem werden ihm hier aus der Datenbank entsprechende Rechte zugewiesen.

Gehen wir als nächstes zur Administration im Login-Dialog, welches die BenutzerVerwaltung darstellt.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 95 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.2 Benutzerverwaltung Maske

Abbildung 33: Benutzer-Verwaltung

Erklärung In dieser Maske können Benutzer angelegt und gelöscht sowie das Paßwort eines bestehenden Benutzers verändert werden. Die angelegten Benutzer werden der Gruppe zugewiesen, der sie angehören. Wenn der Exit-Button geklickt wird, wird wieder beim Login-Dialog fortgefahren. Nun wird auf den Button Review geklickt. Es öffnet sich folgende Maske.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 96 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.3 MainSelection Maske

Abbildung 34: Maske MainSelection

Erklärung In dieser Maske können die Angaben für ein geplantes Review gemacht werden.

Felder: ●

Catalog: Der Katalog wird für ein globas Review ausgewählt - Project Review: Reviews für Produktentwicklungen - Software Review: Reviews für Softwareentwicklungen

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 97 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

- Component Review: Reviews für Systemkomponentenentwicklungen ●

Business Field: Nur diese Fragen, die als relevant für das ausgewählte Business Field im globalen oder special Catalog ausgewählt wurden, erscheinen in der Checkliste



Location: Das Review kann für einen bestimmten Ort angelegt werden. Dieses Vorgehen strukturiert die Fragen besser



Doc/EoP: Typ des Reviews: - Document Review für technische Aspekte (In der Tabelle können die einzelnen technischen Aspekte nochmal aufgeteilt werden. - End of Phase Review für Aspekte des Projektmanagements



Milestones: Es kann ein Review für einen bestimmten Meilenstein im Fertigungsprozeß angelegt werden (Es muß immer ein Meilenstein definiert werden)



Language: Es können die drei Sprachen Deutsch, Englisch und Französisch für die Fragen und die Topics ausgewählt werden

Buttons ●

Select Project: Öffnet die Maske, in der die Projekte ausgewählt werden können. Die Projektdaten sind für die Review Templates notwendig. Sie erscheinen in der Fußzeile jeder Checkliste



Administration: Es wird die Administrationsmaske geöffnet, in der verschiedene Punkte administriert werden können. Es lassen sich Projekte, Projektfragen, entsprechende Topics und diverse andere Sachen administrieren. Für einen GastBenutzer ist die Maske nicht zugänglich (s. 8.4)



Preview Templates: Hier werden leere Formulare erstellt, die später per Hand ausgefüllt werden können



Special Catalog: Hier können Special Catalogs zuerst angesehen und anschließend gedruckt werden. Ein Special Catalog ist nicht von einem Meilenstein abhängig. Es wird folgende Maske geöffnet:

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 98 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Abbildung 35: Preview Special Catalog

Es können hier ein oder mehrere Kataloge ausgewählt werden und anschließend durch den Klick auf Preview Special Catalog angesehen werden.

8.4 Administration-Panel Maske

Abbildung 36: Administration Panel

Erklärung In dieser Maske können alle Elemente des Review-Tools administriert werden. Um die komplette Administrierung vornehmen zu dürfen, muß man allerdings Adminis____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 99 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

trator-Rechte haben.

8.5 Admin Global Catalog Maske

Abbildung 37: Admin Global Catalog

Erklärung Die Global Questions sind für alle Business Fields verfügbar. Fragen, die für ein BusinessField nicht mehr relevant sind, können vom Administrator abgewählt werden. Jede Frage und jedes Topic haben eine ID, auf welche man sich bei einer Änderung der Frage oder des Topics beziehen sollte. Die Maske ist vor allem dazu gedacht, globale Fragen zu administrieren. Beim Öffnen der Form sind noch keine ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 100 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Fragen ausgewählt.

Felder ●

Topic: Überschrift für einen bestimmten Block von Fragen



Catalog: Globaler Catalog



Doc/EoP: Typ des Reviews



Question(D), Question(E), Question(F): Fragen in Deutsch, Englisch oder Französisch, jeweils mit 255 Zeichen



Milestones: Ein Meilenstein muß mindestens selektiert sein, um eine Frage anzulegen



Business Fields: Es werden hier die Business Fields angewählt, für welche eine Frage nicht relevant ist



Location: Bei Angabe einer Location werden die Fragen ortsspezifisch abgespeichert



Mandatory: Die Fragen, bei denen Mandatory selektiert wird, sind nur für den Administrator zugänglich und dürfen von diesem verändert werden

Buttons ●

New, Save und Delete: Die Fragen können gelöscht oder gespeichert werden. Mit New werden alle Felder in der Maske gelöscht, so daß ein neuer Datensatz eingegeben werden kann



Preview All: Alle Fragen, die bereits zum aktuellen Catalog gehören, werden ausgegeben



Admin Topics: Hier wird die Maske geöffnet, in der globale Topics administriert werden können (s. 8.5.1)



Exit: Die Maske Admin Global Catalog wird verlassen

8.5.1 Admin Topics

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 101 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Maske

Abbildung 38: Admin Topics

Erklärung Hier werden die globalen Topics administriert. Es können in den drei Sprachen Deutsch, Englisch und Französisch Fragen zu den bestehenden hinzugefügt werden. Des weiteren können die Fragen sowohl gelöscht werden als auch eine Übersicht über die bereits existierenden Fragen erstellt werden.

8.6 Admin Special Catalog

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 102 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Maske

Abbildung 39: Admin Special Catalog

Erklärung Die Special Questions sind für spezifische Arbeitsgänge in der Entwicklung gedacht. Aus diesem Grund sind hier auch keine Milestones aufgeführt, da diese Arbeitsgänge von vordefinierten Meilensteinen unabhängig sind. Die Fragen sind im übrigen für alle Business Fields verfügbar.

Felder ●

Topic: Ein globales Topic muß ausgewählt werden

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 103 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________



Catalog: Ein globaler Catalog muß ausgewählt werden



Location: Dieses Feld ist in der Maske deaktiviert, da Special Questions nicht ortsspezifisch sein können



Question(D), Question(E), Question(F): Die Frage in Deutsch, Englisch oder Französisch



Business Fields: Hier wird das Business Field angewählt, für welches die Frage nicht relevant ist

8.6.1 Admin Special Topics Maske

Abbildung 40: Admin Special Topics

Erklärung Wie bei den globalen Topics trifft hier die gleiche Erklärung . Sie können auch ge____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 104 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

ändert, neu angelegt und gelöscht werden und sie werden auch durch eine eindeutige ID identifiziert.

8.6.2 Catalogs Maske

Abbildung 41: Special Catalog

Erklärung In dieser Maske können ganze Kataloge hinzugefügt und gelöscht werden, denen dann in Admin Special Questions wieder Fragen zugeordnet werden können. Nach dem Hinzufügen des Katalogs ist es möglich, die entsprechenden Fragen durch Klick auf Preview Special Catalog anzuzeigen. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 105 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.7 Admin Projects Maske

Abbildung 42: Admin Projects

Erklärung In dieser Maske können Projektdaten gespeichert bzw. erweitert werden, wenn ein anderes Review innerhalb des Projekts geplant werden soll. Diese Daten sind nur für eine bestimmte Arbeitsgruppe verfügbar.

Felder ●

Catalog: Hier wird ein bestimmter Katalog festgelegt



Business Field: Das Business Field für ein Projekt kann eingegeben werden



Location: Das Projekt kann einem bestimmten Ort zugewiesen werden oder un-

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 106 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

abhängig von einem Ort sein (Location = All) ●

R&D Number: Es kann eine sogenannte Research & Development Nummer festgelegt werden



Project Name: Der Name des Projektes

Es sind des weiteren Felder für den Namen und die Abteilung des Projekt-Betreuers, den Namen und die Abteilung des Team-Betreuers und Daten für den Qualitätsmanagement vorhanden.

8.8 Project Questions Maske

Abbildung 43: Project Questions

Erklärung Hier werden spezifische Fragen für jedes Projekt administriert werden. Sie erscheinen in der Checkliste, wenn der entsprechende Meilenstein angewählt wird. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 107 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Felder ●

Topic: Ein globales Topic muß ausgewählt werden



Question(D), Question(E), Question(F): Die Fragen in den jeweiligen Sprachen



Milestones: Es muß mindestens ein Meilenstein ausgewählt werden, dem die entsprechende Frage zugeordnet wird

Der Projektname, die Projekt-ID und die R&D-Nummer werden aus der vorherigen Maske mit übernommen.

8.8.1 Admin Project Topics Maske

Abbildung 44: Admin Project Topics

Erklärung Hier möchte ich gar keine lange Erklärung einfügen. Diese Maske ist dazu da, projektbezogene Topics zu administrieren. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 108 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.9 Administration Maske

Abbildung 45: Globale Administration

Erklärung Dies ist die globale Administrationsmaske, in der ganze Kataloge hinzugefügt und gelöscht werden können. Des weiteren ist es möglich, Business Fields und Locations hinzuzufügen und zu löschen. Ein weiterer Punkt ist die Administration der Milestones, die wie folgt aussieht:

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 109 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Abbildung 46: Administration der Milestones

In dieser Maske können die zu einem Katalog gehörenden Milestone-Kombinationen festgelegt werden. In obigem Fall wurde das Beispiel des Katalogs Project Review angeführt (Milestone-Kürzel 'R'). Es wäre hier in der Maske MainSelection nur eine Milestone-Kombination möglich und zwar R1 mit R2. Man kann diese Kombinationen in der Maske beliebig erweitern. Als nächstes folgt die Maske der Catalog-Administration, in der ein ganzer Katalog dem Review-Tool hinzugefügt wird:

Abbildung 47: Hinzufügen eines Katalogs ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 110 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Nachdem die entsprechenden Werte in die Maske eingegeben wurden, folgt nach Anklicken des Add-Buttons folgende Tabelle:

Abbildung 48: Meilenstein-Beschreibung

In dieser Maske kann zu den jeweiligen Meilensteinen, die in Add Catalog festgelegt wurden, eine kurze Beschreibung dessen erfolgen, um nachher im Fertigungsprozeß besser überprüfen zu können, welche Tätigkeit welchem Meilenstein zuzuordnen ist. Mittels des Buttons Save können die Werte übernommen und somit in der Datenbank gespeichert werden (s. Tabelle glbMilestones).

Beim Anlegen eines Business Fields oder einer Location müssen keine zusätzlichen Masken aufgerufen werden, da es sich nur um einzelne Werte handelt.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 111 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.10 Admin Document Type Maske

Abbildung 49: Admin Document Type

Erklärung Wie im Punkt 7.3 schon angesprochen wurde, sollten die Kataloge in einzelne Dokument-Typen unterteilt werden, um eine genauere Spezifizierung und Zuordnung der Fragen zu einem bestimmten Thema zu ermöglichen. In obiger Maske ist das Anlegen und Löschen eines Dokument-Typs zu einem Katalog möglich (s. auch 8.3). Die Dokument-Typen, die hier angelegt werden, findet man anschließend z. B. in der Maske MainSelection wieder.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 112 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.11 Admin Release Date Maske

Abbildung 50: Administration des Release Dates

Erklärung Man könnte zu einem Release Date genauso gut Erstellungsdatum sagen. Man kann hier das Erstellungsdatum eines Kataloges verändern. Mit Save speichert man die veränderten Werte dann ab. Hinweis: Man sieht, daß die Datumswerte zentriert worden sind und amerikanisches Format haben. Dies wurde mittels DateCellRenderers realisiert (s. 6.1.6). Mehr ist zu dieser Maske an sich nicht zu sagen.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 113 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.12 Select Project Maske

Abbildung 51: Projektauswahl

Erklärung Wenn in der ersten Maske MainSelection ein Katalog, ein Business Field, eine Location und ein Meilenstein ausgewählt wurde und anschließend auf Select Project geklickt wird, kommt man zu dieser Maske, in der alle aktuellen Projekte aufgelistet werden, die zu den ausgewählten Optionen gehören. Man kann nun ein Projekt aus den vorhandenen auswählen, um ein Review zu planen. Des weiteren gibt es die Möglichkeit, das ausgewählte Projekt zu administrieren, indem auf AdminProjects (s. 8.7) geklickt wird. Das Projekt wird übernommen und kann entweder verändert oder gelöscht werden. Hat der Benutzer vor, ein Review zu planen, klickt er auf den Button Review und die folgende Maske wird geöffnet. ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 114 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.13 Project Invitations Maske

Abbildung 52: Project Invitations

Erklärung Diese Maske zeigt alle Reviews, die zu dem ausgewählten Projekt schon einmal erzeugt wurden und zwar nach dem Datum sortiert. Es ist hier möglich, Einladungen zu einem Review-Meeting durchzuführen. Um zu anderen Datensätzen zu kommen, ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 115 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

können entweder die Pfeiltasten im unteren Teil der Maske oder die Search-Funktion verwendet werden.

Felder ●

R&D No. und Project Name: Diese Felder beinhalten die R&D/ppa Nummer und den Namen des aktuell angelegten Projekts. Sie können in dieser Maske nicht geändert werden



Date, Time Begin und Time End: Hier wird der Beginn und das Ende des ReviewMeetings angezeigt



No., Name und Doc/EoP: Es werden Informationen über den aktuell ausgewählten Meilenstein und Review-Typs angezeigt. Diese Werte können hier auch nicht verändert werden



Room, Location: Hier kann der aktuelle Raum und Ort des Review-Meetings eingegeben werden, bzw. diese Werte werden angezeigt



Name, Department und Telephone: Moderator und Review Agent



Name, Date, Part Project: Hier werden detaillierte Informationen über das Review Objekt, den Beispiel-Status oder der Teil-Projekte angezeigt. Diese Felder haben optionalen Charakter und werden hauptsächlich in Doc-Reviews benutzt



Reason: Der Hauptgrund für das geplante Review



Comment: Der Hauptschwerpunkt des Reviews

Buttons ●

Participants: Öffnet die Maske, die die Teilnehmer des Reviews festlegt



Documents: Öffnet die Maske, in der die unterstützten Dokumente und das Review-Objekt festgehalten werden können



Copy: Die Werte der aktuellen Einladung zusammen mit Participants und Documents werden in das zu planende Review kopiert



Preview: Hier werden die Templates Review Invitation, Commentlist, Review Status und Checklist erstellt



Preview Checklist: Diese Funktion generiert aus den vorhandenen Werten eine

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 116 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Checkliste, die dann manuell nachbearbeitet werden kann (s. 8.12.3) ●

Review Status: Diese Funktion zeigt den Fortschritt des aktuellen Reviews an und kann auch manuell nachbearbeitet werden



Preview Commentlist: Diese Funktion generiert aus den vorhandenen Werten eine PDF-Datei, in der eine Liste aller Fragen zusammen mit ihren Kommentaren erstellt werden

8.13.1 Checkliste Maske

Abbildung 53: Checkliste

Erklärung Wenn in Project Invitations auf Preview Checklist gedrückt wird, kommt obige Maske zum Vorschein. Man sieht alle Fragen über einen bestimmten Fertigungsprozeß zusammen mit ihren Attributen Catalog, Business Field, Location und Topic. In den drei rechten Spalten Not Relevant, Ok und Comment sieht man Häkchen, die der ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 117 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Benutzer setzen kann. Er geht nun alle Fragen durch und kann sie dann als Not Relevant oder Ok abhaken. Wenn zu einem bestimmten Prozeß noch mehr zu sagen ist, dann wählt er Comment an und es erscheint folgende Maske:

Abbildung 54: Editor für Kommentare

Hier kann der Benutzer einen die Frage betreffenden Kommentar zusammen mit einem Typ des Kommentars eingeben und das ganze anschließend abspeichern.

8.13.2 Participants Maske

Abbildung 55: Teilnehmer des Reviews

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 118 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Erklärung Wenn in der Maske Project Invitations der Button Participants geklickt wird, wird obige Maske geöffnet. Hier können die Teilnehmer des geplanten Reviews zusammen mit ihrer Aufgabe und den Personen, die informiert werden müssen, angelegt werden, bzw. die schon angelegten bearbeitet oder gelöscht werden. Die Projektdaten des Reviews sieht man im oberen Teil der Maske. Sie werden von Project Invitations übernommen und können hier nicht verändert werden.

8.13.3 Documents Maske

Abbildung 56: Dokumente des Reviews

Erklärung Zu dieser Maske kommt man, wenn in Project Invitations auf Documents geklickt wird. Hier legt man die Dokumente, die in dem geplanten Review diskutiert werden, ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 119 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

an, sodaß das Team sie vorbereiten kann. Wie bei Participants werden im oberen Teil der Maske die unveränderbaren Projektdaten wiedergegeben. Die Dokumentennummer in der Tabelle ist die Referenz-Nummer des Dokuments. Als Typ des Dokuments stehen Supporting Document (SD) und Review Object (RO) zur Auswahl.

9 Zusammenfassung und Ausblick Um nochmal auf den Titel meiner Diplomarbeit, „Eine Internet-/IntranetAnwendung zur Automatisierung von Projektkontrollen“ zurückzukommen, möchte ich abschließend sagen, daß diese Thematik in Zukunft immer mehr zum Einsatz kommen wird, da eine Bearbeitung von Daten stattfinden kann, die unabhängig vom jeweiligen Aufenthaltsort ist. Wie man am Beispiel dieses Review-Tools sieht, hat es sich immer mehr fortentwickelt. Am Anfang wurden alle Daten in ein Word-Dokument kopiert und ausgedruckt. Dieses Verfahren erwies sich letztendlich als umständlich und unpraktikabel, deshalb gab man ein Tool in Auftrag, in dem die Daten interaktiv gestaltet werden konnten und das in Microsoft Access geschrieben werden sollte. Fast drei Jahre arbeitete man mit diesem Access-Tool, bevor man sich wiederrum entschloß, eine Internet-Version in Auftrag zu geben, sodaß an allen möglichen Standorten der Welt auf die gleichen Daten zugegriffen werden kann. Mit dem Ende der Diplomarbeit waren schon wieder seitens des Auftraggebers viele Erweiterungen geplant, z. B. statistische Auswertungen über die Fehler der Fertigung, so daß es möglich wird, ein Optimum an Qualitätsarbeit zu liefern. Abschließend möchte ich der Firma Heitec GmbH mit ihrem Niederlassungsleiter Herrn Stefan Fink danken, der mir die Anfertigung meiner Diplomarbeit in einem Industriebetrieb ermöglicht hat. Mein Dank gilt auch meinem Betreuer Thomas Aigner, der mir bei Problemen stets zur Seite stand, und der mich auf viele interessante und nützliche Ideen innerhalb meiner Arbeit brachte.

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 120 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Abbildungsverzeichnis 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

Client-Server-Architektur Anbindung eines Java-Applets JDBC-Treiber-Manager Überblick über die JDBC-API Kommunikation im Client/Server-System mit RMI Eine verteilte Anwendung Kommunikation verteilter Objekte Einordnung von RMI in das OSI-Schichtenmodell Kommunikation von Stubs und Skeletons Softwareabteilung bei Heitec Verzeichnisstruktur des Review-Tools Application-Server Umgang mit SQLJ SQLJ-Laufzeitkonfiguration Administrationsmaske Klassen Catalog, Business Fields und Location Maske Checklist Datenstruktur der Klasse CheckListData FlowLayout GridLayout BorderLayout CardLayout BoxLayout GridBagLayout Beispiel für Layouts im Review-Tool Suchfunktion des Review-Tools Maske Admin Projects Datenbankstruktur Global Questions Datenbankstruktur Projects und Questions Datenbankstruktur Special Questions Erweitererte Datenbank Login-Dialog Benutzer-Verwaltung MainSelection Preview Special Catalog Administration Panel Admin Global Catalog Admin Topics Admin Special Catalog Admin Special Topics

18 20 22 24 26 27 28 29 31 33 34 39 41 44 64 67 68 69 71 72 72 73 73 74 75 82 83 86 87 88 89 91 92 93 95 95 96 98 99 100

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 121 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

Special Catalog Admin Projects Project Questions Admin Project Topics Globale Administration Administration der Milestones Hinzufügen eines Katalogs Meilenstein-Beschreibung Admin Document Type Administration des Release Dates Projektauswahl Project Invitations Checkliste Editor für Kommentare Teilnehmer des Reviews Dokumente des Reviews

101 102 103 104 105 106 106 107 108 109 110 111 113 114 114 115

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 122 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Tabellenverzeichnis 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Ziele des Review-Tools Prozeß eines Reviews Datentypen und Wertebereiche in Java Escape-Sequenzen in Java Vergleichsoperatoren in Java JDBC-Treiber-Typen CVS-Optionen Verwendete Packages Oracle-Datentypen Vorteile von SQLJ gegenüber JDBC Systemeigenschaften aus der Methode getProperty() Search-Vektor Search-Funktion Gefüllter Vektor mit Projektdaten Beispiel der Datenstuktur AdministrationData Aufbau eines Client-Programms Zusätzliche Anforderungen für die Neuimplementierung des Review-Tools Angebotene Erweiterungen Neue Datenbanktabellen

5 5 8 9 10 23 37 38 42 43 53 59 61 62 66 70 88 89 90

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W

Diplomarbeit SS 99/00

- 123 -

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Literaturverzeichnis [1]

LEMAY/PERKINS: Java in 21 Tagen, 1996

[2]

PETER NORTON: Guide to Java Programming, 1997

[3]

JAMIE JAWORSKI: Java 1.2 Unleashed, Sams Verlag, 1998

[4]

JOE, WEBER: Special Edition Using Java, 2nd Edition, 1997

[5]

RALF KÜHNEL: Programmierung von Threads und Applets, 1996

[6]

Redbooks Technical Manuals (IBM) Client/Server Computing, 1996

[7]

MARY CAMPIONY, KATHY WALRATH:: The Java Tutorial, 1998

[8]

BRUCE ECKEL: Thinking in Java, Prentice Hall, 1998

[9]

http://iundg.informatik.uni-dortmund.de/

[10]

http://ourworld.compuserve.com/

[11]

Java Developers Journal, 6/99

[12]

Java Spektrum, 8/99

[13]

SUN MICROSYSTEMS: Java Platform 1.2 API Specification, 1999

[14]

SUN MICROSYSTEMS: SQLJ-API, 1999

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Christian Schmidbauer, I8W