Ausarbeitung DA FINAL - NeoOffice Writer - UZH...Kapitel 7 enthält Information über die durchgeführten Performance- und JUnit-Tests. Im Kapitel 8 werden weiterführende Arbeiten

DBDocEntwurf und Implementierung

einer Anwendung zur partiellenAutomation des Dokumentations-

Prozesses für Datenbanken

Diplomarbeit im Fach Informatik

Sascha NedkoffZürich, Switzerland

Matrikelnummer: 00-709-733

Betreuer: Boris GlavicProfessor: Prof. Dr. Klaus R. Dittrich

Prof. Abraham Bernstein

Abgabe: 20. Januar 2008

University of Zurich

DIP

LOM

AR

BE

IT –

Dat

abas

e Te

chno

logy

Res

earc

h G

roup

, Pro

f. D

r. K

laus

R. D

ittric

h / P

rof.

Abr

aham

Ber

nste

in

Department of Informatics

Department of Informatics (IFI)Binzmühlestrasse 14, CH-8050 Zürich, Switzerland

iii

Abstract

Nowadays most relational database systems support the specification and storage of user-de-fined comments for database objects. Those comments can be considered as a rudimentarydocumentation of the database schema. But alone they are insufficient and inconvenient todocument a database, because they can only be accessed in a cumbersome way and for adocumentation many other schema informations are also relevant.

Within this thesis an application for a partial automation of the documentation process is de-veloped and implemented, which is capable to generate a database documentation by ac-cessing the user-defined comments and schema informations. Thereby it should generallysupport various output formats and various database systems as well as database design pat-terns.

iv

v

Zusammenfassung

Heutzutage unterstützen die meisten relationalen Datenbanksysteme die Spezifikation undSpeicherung von benutzerdefinierten Kommentaren für Datenbankobjekte. Diese Kommen-tare können als rudimentäre Dokumentation eines Datenbankschemas angesehen werden.Allein sind sie aber ungenügend und nicht komfortabel, um Datenbanken zu dokumentieren.Einerseits weil nur umständlich auf sie zugegriffen werden kann und andererseits weil füreine Dokumentation viele andere Schemainformationen ebenfalls relevant sind.

Im Rahmen dieser Diplomarbeit wird eine Anwendung zur partiellen Automation des Doku-mentations-Prozesses erstellt, welche über Zugriffe auf Schemainformationen und benutzer-definierte Kommentare eine Dokumentation dieser Datenbank generieren kann. Dabei sol-len generell verschiedene Ausgabeformat und verschiedene Datenbankanbindungen möglichsein sowie Datenbankentwurfsmuster unterstützt werden können.

vi

vii

Inhaltsverzeichnis 1 Einleitung............................................................................................................................1

1.1 Motivation....................................................................................................................1 1.2 Ziele der Arbeit.............................................................................................................2 1.3 Aufbau der Arbeit.........................................................................................................3

2 Grundlagen.........................................................................................................................4 2.1 Software Dokumentation..............................................................................................4

2.1.1 Aufgaben der Dokumentation...............................................................................4 2.1.2 Arten von Dokumentationen.................................................................................5

2.1.2.1 Projektdokumentation...................................................................................5 2.1.2.2 Produktdokumentation..................................................................................6

2.1.3 Problematik von Dokumentationen......................................................................7 2.2 Automatische Software Dokumentation.......................................................................7 2.3 Dokumentation von Programmcode.............................................................................8 2.4 Dokumentation von Datenbanken................................................................................8

3 Verwandte Arbeiten.........................................................................................................10 3.1 Werkzeuge für die Dokumentation von Programmcode............................................10

3.1.1 Javadoc................................................................................................................10 3.1.1.1 Tags.............................................................................................................11 3.1.1.2 Doclet..........................................................................................................12

3.2 Werkzeuge für die Dokumentation von Datenbanken................................................13 3.2.1 DBScribe.............................................................................................................13 3.2.2 SQL Doc.............................................................................................................14 3.2.3 SqlSpec...............................................................................................................15 3.2.4 ApexSQL Doc.....................................................................................................15 3.2.5 Zusammenfassende Feststellungen über die Werkzeuge....................................16

4 Anforderungsspezifikation..............................................................................................18 4.1 Grundlegende Anforderungen....................................................................................18

4.1.1 Anbindung unterschiedlicher Datenbanksysteme...............................................18 4.1.2 Verschiedene Ausgabeformen und Formate.......................................................18 4.1.3 Unterstützung von Datenbankentwurfsmuster....................................................19 4.1.4 Kommentare und Annotationen..........................................................................19 4.1.5 Flexible Architektur............................................................................................20 4.1.6 Generisches Datenmodell...................................................................................20 4.1.7 Weitere Anforderungen.......................................................................................21

4.2 Spezielle Anforderungen............................................................................................21

viii

5 Design................................................................................................................................22 5.1 Datenmodell...............................................................................................................22

5.1.1 Schnittstellenhierarchie.......................................................................................23 5.1.2 Erzeugung der Objekte.......................................................................................26 5.1.3 Namen und Referenzierung................................................................................26 5.1.4 Verlinkung...........................................................................................................27

5.2 Plug-in Architektur.....................................................................................................29 5.2.1 Model-Plug-in.....................................................................................................32 5.2.2 Input-Plug-in.......................................................................................................32 5.2.3 Output-Plug-in....................................................................................................32 5.2.4 Transformator-Plug-in........................................................................................33 5.2.5 Plug-in Manager.................................................................................................33

5.3 Kommentare und Annotationen.................................................................................34 5.3.1 Speicherung........................................................................................................34 5.3.2 Annotationen.......................................................................................................35

5.3.2.1 Tags mit Informationen...............................................................................35 5.3.2.2 Tags zur Formatierung................................................................................39

6 Implementierung..............................................................................................................41 6.1 Datenmodell...............................................................................................................41 6.2 Kommentare und Tags................................................................................................41

6.2.1 Tag-Definitionen.................................................................................................42 6.2.2 Parser..................................................................................................................44

6.3 Applikationsmanager..................................................................................................45 6.3.1 XML-Konfigurationsdatei..................................................................................45 6.3.2 Kommandozeilen Argumente.............................................................................47 6.3.3 Protokollierung...................................................................................................47

6.4 Plug-ins.......................................................................................................................47 6.4.1 Standard-Model-Plug-in.....................................................................................48 6.4.2 PostgreSQL-Input-Plug-in..................................................................................49 6.4.3 Output-Plug-ins...................................................................................................51

6.4.3.1 HTML-Output-Plug-in................................................................................51 6.4.3.2 Konsolen-Output-Plug-in............................................................................56

6.4.4 Transformator-Plug-ins.......................................................................................56 6.4.4.1 Kommentar-Transformator.........................................................................56 6.4.4.2 SQL-Reconstructor.....................................................................................60 6.4.4.3 View-Properties-Setter................................................................................61 6.4.4.4 Simulated Constraint Analyser...................................................................62

7 Tests...................................................................................................................................64

ix

7.1 Performance................................................................................................................64 7.2 JUnit...........................................................................................................................66

8 Weiterführende Arbeiten.................................................................................................67 8.1 Graphische Benutzeroberfläche (GUI).......................................................................67 8.2 Weitere Datenbankanbindungen.................................................................................68 8.3 Weitere Ausgabeformate............................................................................................68 8.4 Erweiterung des Datenmodells...................................................................................68 8.5 Weitere Transformatoren............................................................................................69 8.6 Persistente Speicherung der Informationen über Datenbankobjekte..........................69

9 Zusammenfassung und Schlussfolgerungen..................................................................70

x

xi

1 Einleitung

1 Einleitung

1.1 MotivationIn der Softwareentwicklung sollte dem Dokumentationsprozess sowie der Dokumentationeine wichtige Rolle zukommen. Dokumentationen erfüllen verschiedene wichtige Aufga-ben, vom Hilfsmittel für eine bessere Kommunikation bis hin zur Wissenssicherung. Ebensowie Programme und Programmcode einer Dokumentation bedürfen so benötigen auch Da-tenbanken beziehungsweise Datenbankschemas eine ausführliche Dokumentation. Insbeson-dere wenn Datenbanken grösser und komplexer werden, aber auch wenn sie über längereZeit im Einsatz sein sollen, sind gute Dokumentationen unerlässlich.

Heutzutage bieten viele Datenbanksysteme die Möglichkeit benutzerdefinierte Kommentarefür einzelne Datenbankobjekte zu spezifizieren und zu speichern. Diese Möglichkeit kanneingesetzt werden um Datenbankschemas rudimentär zu dokumentieren. Jedoch ist eine sol-che Möglichkeit allein ungenügend und nicht komfortabel um ein Datenbankschema ausrei-chend zu dokumentieren. Denn auf die Kommentare kann nur umständlich zugegriffen wer-den und es ist keine Navigation zwischen Kommentaren von verschiedenen Datenbankob-jekten möglich. Ausserdem möchte man eine separate Dokumentation ohne direkt auf dieDatenbank und deren Objekte zugreifen zu müssen und eine vollständige Dokumentationsollte neben Kommentaren für Datenbankobjekte auch eine Vielzahl weiterer Informatio-nen, welche das Datenbankschema detaillierter beschreiben, enthalten.

Wie bei der Dokumentation von Programmcode bietet sich auch bei der Dokumentation vonDatenbankschemas der Einsatz von Werkzeugen an, um automatisch die benutzerdefiniertenKommentare sowie weitere relevante Informationen aus dem Programmcode beziehungs-weise dem Datenbankschema auszulesen oder abzuleiten und daraus eine Dokumentation zugenerieren.

Für die automatische Generierung von Dokumentationen für Datenbanken existieren bereitsverschiedene Werkzeuge. Jedoch weisen die momentan vorhandene Werkzeuge viele Ein-schränkungen auf. Zum einen können die meisten Werkzeuge nur Datenbanken auf be-stimmten Datenbanksystemen dokumentieren und zum anderen werden nur wenige Ausga-beformate angeboten und es existiert keine Möglichkeit neue Ausgabeformate oder Daten-bankanbindungen hinzuzufügen. Ebenfalls bieten sie wenig Freiheiten auf den Inhalt derDokumentation Einfluss zu nehmen und bieten keine Unterstützung bei der Dokumentationvon Datenbankentwurfsmustern.

1

1.2 Ziele der Arbeit

1.2 Ziele der ArbeitIm Rahmen dieser Diplomarbeit soll, angelehnt an Javadoc, eine Anwendung zur partiellenAutomation des Dokumentations-Prozesses für Datenbanken entwickelt werden. Die An-wendung soll über Zugriffe auf Datenbankschema-Informationen und benutzerdefinierteKommentare eine Dokumention einer Datenbank generieren können. Ziel ist es ein vollfunktionstüchtige und getestete Anwendung zu entwerfen und zu implementieren sowie Lö-sungsvorschläge für die grundlegenden Probleme zu erarbeiten und die Machbarkeit undEignung anhand der Implementierung aufzuzeigen.

Die grundlegenden Herausforderungen beim Entwurf der Anwendung sind erstens, dieSchaffung einer Möglichkeit für die Anwendung um unterschiedliche relationale Daten-banksysteme unterstützen zu können. Damit beliebige relationale Datenbanken auf unter-schiedlichen Datenbanksystemen dokumentiert werden können. Zweitens, dass die Anwen-dung grundsätzlich in der Lage sein muss beliebige Ausgabeformate für die Dokumentationzu unterstützen. Neben den von der Anwendung angebotenen Ausgabeformaten soll esebenfalls möglich sein beliebige neue Ausgabeformat hinzuzufügen. Deshalb ist es von zen-traler Bedeutung eine flexible Architektur sowie klare Schnittstellen zu entwerfen, um dieseAnforderung erfüllen zu können. Zusätzlich soll die Anwendung einen Mechanismus anbie-ten um die Dokumentation von Datenbankentwurfsmustern zu unterstützen. Dadurch soll esmöglich werden Datenbankentwurfsmuster in der Dokumentation angemessen zu dokumen-tieren. Als Beispiel für eine grössere und komplexere Datenbank, welche mehrere Entwurfs-muster verwendet, wird in dieser Arbeit die sesamDB1 verwendet. Anhand dieser Datenbanksollen die Möglichkeiten zur Unterstützung von Datenbankentwurfsmustern getestet wer-den.

Weitere wichtige Anforderungen an die Anwendung sind, dass neben der grundsätzlichenUnterstützung von verschiedenen Datenbankanbindungen, mindestens eine konkrete Anbin-dung für PostgreSQL Datenbanksysteme entwickelt wird. Ebenfalls soll neben der grund-sätzlichen Möglichkeit verschiedene Ausgabeformate zu erzeugen, mindestens eine konkre-te Lösung zur Generierung von HTML-Dokumentationen implementiert werden.

Angelehnt an Javadoc soll zusätzlich eine Möglichkeit angeboten werden um Annotationenin benutzerdefinierten Kommentaren zu unterstützen. Mit solchen Annotationen soll esmöglich sein spezielle Informationen in Kommentaren auszuzeichnen, Kommentare zu for-matieren sowie Referenzen auf andere Datenbankobjekte zu setzen.

1 http://www.sesamswiss.ch

2

1 Einleitung

1.3 Aufbau der ArbeitDie vorliegende Diplomarbeit ist thematisch in neun Kapiteln gegliedert:

Im Kapitel 2 werden zuerst die Grundlagen bezüglich Softwaredokumentationen im allge-meinen und automatischer Generierung von Softwaredokumentationen im speziellen be-schrieben.

Kapitel 3 befasst sich im ersten Teil mit Javadoc als Werkzeug für die Dokumentation vonProgrammcode und in einem zweiten Teil mit den schon vorhandenen Werkzeugen zur Do-kumentation von Datenbanken.

Im Kapitel 4 werden die allgemeinen Anforderungen an eine Anwendung zur Dokumentati-on von Datenbanken und die im Rahmen dieser Arbeit geltenden speziellen Anforderungspezifiziert.

Kapitel 5 beschreibt den Entwurf der Anwendung und erläutert die Konzepte, welche entwi-ckelt wurden, um den gestellten Anforderungen gerecht zu werden.

Im Kapitel 6 wird detaillierter auf die Implementierung der Anwendung eingegangen undwichtige Ausschnitte beleuchtet.

Kapitel 7 enthält Information über die durchgeführten Performance- und JUnit-Tests.

Im Kapitel 8 werden weiterführende Arbeiten und Erweiterungen der entwickelten Anwen-dung besprochen.

Kapitel 9 schliesst die Arbeit mit einer Zusammenfassung und Schlussfolgerungen ab.

3

2 Grundlagen

2 Grundlagen

2.1 Software DokumentationDokumentationen spielen in allen Bereichen der Informatik eine wichtige Rolle. Nicht nurbei Datenbanken sondern auch in der Softwareentwicklung sind Dokumentationen von gros-ser Bedeutung.

Bei der Entwicklung von Software entsteht kein materielles Produkt. Alle Entwicklungstä-tigkeiten manifestieren sich letztlich nur in Form von Dokumenten (im weitesten Sinn istauch Programmcode ein Dokument). Den Dokumenten kommt daher in der Softwareent-wicklung eine besondere Bedeutung zu [Glinz01].

Genau wie bei der Entwicklung von Software entsteht auch bei der Entwicklung von Daten-banken kein materielles Produkt und die Entwicklungstätigkeiten manifestieren sich nur inForm von Datenbankschemas. Diese können im weitesten Sinn ebenfalls als Dokument an-gesehen werden und genau wie bei den Dokumenten in der Softwareentwicklung kommt ih-nen ein hoher Stellenwert zu.

2.1.1 Aufgaben der DokumentationWie in [Glinz01] beschrieben, erfüllen Dokumentation drei Hauptaufgaben:

● Wissenssicherung: Die Informationen aus den Köpfen holen

Das Wissen (Know-How) über ein System macht einen beträchtlichen Teil des Wertseines Systems aus. Die Dokumentation hat die Aufgabe, dieses Wissen schriftlichoder elektronisch festzuhalten, damit es gesichert ist und nicht verloren geht.

● Kommunikation: Reden miteinander genügt nicht

Eine geordnete Systementwicklung und -pflege ist ohne Kommunikation nicht mög-lich. Dies gilt sogar für Ein-Personen-Projekte, wenn das Produkt länger als ein paarWochen leben soll. Mündliche Kommunikation ist bei Arbeiten in einem kleinenPersonenkreis sehr effizient. Ausschliesslich mündliche Kommunikation verursachtjedoch erhöhte Kosten (und wird letztlich ineffizient), wenn der Personenkreis sichändert oder die Systembetreuung auf einen anderen Personenkreis übergeht. Letzte-res ist typisch der Fall beim Übergang von der Entwicklung zur Nutzung.

Daher müssen auch in Kleinprojekten alle für ein System wichtigen mündlichen In-

4

2 Grundlagen

formationen und Absprachen in Dokumenten festgehalten werden. Mündliche Kom-munikation genügt nicht, da Erzeugung und Benutzung von Informationen unterUmständen um Jahre auseinander liegen können.

● Sichtbarmachen des Projektfortschritts: Dokumente sind greifbare Resultate

Der Abschluss jeder Phase der Softwareentwicklung wird nachprüfbar markiertdurch die Fertigstellung und Freigabe von Dokumenten. Bei den Produktdokumen-ten wird stets die Endfassung eines Dokuments erzeugt, welches nur noch über eingeordnetes Änderungswesen modifizierbar ist. Das Erstellen von Zwischendoku-menten nur mit dem Zweck des Nachweises abgeschlossener Tätigkeiten ist zu ver-meiden.

Dadurch, dass die Abschlussdokumentation schritthaltend mit der Entwicklung ent-steht, ist der Projektfortschritt besser quantifizierbar.

2.1.2 Arten von DokumentationenDamit Dokumentationen ihre Aufgaben zufriedenstellend erfüllen können, existieren ver-schiedene Arten von Dokumentationen. Je nach Art der Dokumentation entstehen sie amAnfang, während oder gegen Ende des Softwareentwicklungsprozesses.

Generell wird zwischen der Produktdokumentation (Systemdokumentation), die das Softwa-reprodukt und seine Benutzung dokumentiert, und der Projektdokumentation, die die Ent-wicklung eines Softwareprodukts dokumentiert, unterschieden [Glinz01].

2.1.2.1 ProjektdokumentationProjektdokumentationen, auch Prozessdokumentation genannt, beschreiben den Prozess derEntwicklung und Wartung von Softwaresystemen. Sie werden erstellt um das Managementvon Softwareentwicklungsprojekten zu unterstützen, indem sie den Projektprozess sichtbarmachen. Ein Hauptmerkmal von Projektdokumentationen ist, dass die meisten mit dem Pro-jektfortschritt veralten [Sommervile01].

Die wichtigsten Arten von Projektdokumenten sind [Glinz01]:

● Der Projektplan dokumentiert den geplanten Projektablauf, wobei den Soll-Vorgabenwährend der Projektabwicklung laufend die Ist-Werte gegenübergestellt werden.

● Der Qualitätsplan enthält die Vorgaben, die das Projekt betreffend Qualität zu beach-ten hat. Ist ein standardisierter Rahmen-Qualitätsplan vorhanden, sind projektspezifi-sche Qualitätspläne häufig nicht erforderlich.

● Das Projektprotokoll enthält alle Schriftstücke und Berichte (z.B. Änderungsanträge,

5

2.1 Software Dokumentation

Review- und Testprotokolle, Fortschrittsberichte, Sitzungsprotokolle), die im Verlaufder Projektabwicklung anfallen.

2.1.2.2 ProduktdokumentationProduktdokumentationen beschreiben das Softwareprodukt und Entstehen parallel zumSoftwareprodukt, das sie beschreiben. Grundsätzlich werden in Produktdokumentation dieAnforderungen an ein System, das Konzept und die Einzelheiten der Lösung sowie dieHandhabung des Systems dokumentiert. Verwendet werden sie hauptsächlich nach der Fer-tigstellung des Softwareprodukts, sind aber trotzdem wichtig für das Management der Soft-wareentwicklung, weil die Fertigstellung solcher Dokumente, zum Beispiel einer Systems-pezifikation, als Meilensteine im Entwicklungsprozess angesehen werden können [Sommer-vile01].

Die wichtigsten Arten von Projektdokumentationen sind [Glinz01][Sommervile01]:

● Systemdokumentationen, beinhalten alle Dokumente, die das System selber be-schreiben. Angefangen von den Anforderungsspezifikationen bis hin zu Abnahme-vorschriften.

○ Die Anforderungsspezifikation legt präzise, detailliert und soweit wie möglichnachprüfbar fest, was von dem zu entwickelnden System verlangt wird.

○ Das Lösungskonzept beschreibt die Architektur der Lösung. Dies umfasst insbe-sondere die Gliederung der Lösung in Komponenten, die Kommunikation zwi-schen diesen Komponenten, die Verteilung auf Software und Hardware sowie dieVerteilung der Software auf die vorhandenen Ressourcen.

○ Entwürfe und Programmcode beschreiben die Lösungsdetails. Entwürfe werdenentweder separat vom Programmcode dokumentiert oder sie sind in Form vonausführlichen Kommentaren im Programmcode integriert.

○ Die Testvorschriften legen fest, welche Tests für die einzelnen Komponentennach ihrer Fertigstellung durchzuführen sind und welche Tests nach welchem In-tegrationsschritt auszuführen sind.

○ Der in der Abnahmevorschrift beschriebene Abnahmetest bildet den formalenAbschluss einer Entwicklung. Der Auftraggeber überprüft mit diesem Test, obdas System die in der Anforderungsspezifikation gestellten Anforderungen er-füllt.

● Benutzerdokumentationen

○ Die Installationsanleitung beschreibt, wie ein auf der Zielhardware lauffähiges

6

2 Grundlagen

System konfiguriert und auf der Zielhardware installiert wird.

○ Das Benutzerhandbuch enthält die Bedienungsanleitung für das System. Es be-schreibt aus Benutzersicht, welche Funktionen das System bereitstellt und wieman es startet und bedient.

Da die Benutzer eines Systems nicht alle identisch sind, sollte die Benutzerdoku-mentation in verschiedene Teile aufgeteilt werden. Benutzer können sich Auf-grund ihres Fachwissens, ihrer Erfahrung sowie den auszuführenden Tätigkeitenunterscheiden. Insbesondere ist zwischen Endnutzern einerseits und Entwicklernund Systemadministratoren andererseits zu unterscheiden.

○ Ein Glossar, welches die verwendeten Begriffe und Abkürzungen erklärt, ist so-wohl in der Entwicklung als auch nachher für den Benutzer sehr hilfreich. Einsolches Glossar sollte daher in jedem grösseren Entwicklungsprojekt erstellt wer-den.

2.1.3 Problematik von DokumentationenBei der Erstellung von Softwaredokumentationen existieren in der Praxis verschiedene Pro-bleme. Zu den Hauptproblemen gehört erstens, dass Dokumentation für Softwaresystemefälschlicherweise oft erst sehr spät oder am Ende des Entwicklungsprozesses erstellt wer-den. Diese kann dann dazu führen, dass sie unter Zeit und Kostendruck nur unzureichendoder schlimmstenfalls gar nicht erstellt werden. Zweitens zählt das Erstellen von Dokumen-tationen unter Entwicklern nicht zu den beliebtesten Aufgaben, was wiederum dazu führenkann, dass die Aufgabe nicht mit der nötigen Genauigkeit und Sorgfalt durchgeführt wird.Drittens wird der Dokumentationsprozess oft unterschätzt, denn es ist eine zeitintensive undkeine leichte Aufgabe eine gute Dokumentation zu erstellen. Ebenfalls werden Dokumenta-tionen häufig nicht aktuell gehalten und über die Zeit entstehen immer grössere Unterschie-de zwischen der Dokumentation und der tatsächlichen Software.

2.2 Automatische Software DokumentationDie automatische Erstellung von Softwaredokumentationen ist für einige Arten von Doku-mentationen sehr gut möglich und es existieren viele Werkzeuge, die diese Aufgabe über-nehmen oder zumindest erleichtern.

Die Automation oder Teil-Automation des Dokumentations-Prozesses kann in mehreren Be-reichen Vorteile bringen und es kann einigen im Kapitel 2.1.3 angesprochenen Problemenbegegnet werden. Durch eine Automation kann der Aufwand für die Erstellung einer Doku-

7

2.2 Automatische Software Dokumentation

mentation verringert werden, woraus dann in weiterer Konsequenz Zeit- und Kostenerspar-nisse resultieren können. Ebenfalls ermöglichen Werkzeuge die Dokumentation bei Ände-rungen einfach zu aktualisieren und damit synchron mit der Software zu halten. Dies erhöht,zusammen mit dem verringertem Aufwand, die Wahrscheinlichkeit, dass Dokumentationenaktuell gehalten werden. Ein weiterer wichtiger Punkt beim Einsatz von Werkzeugen ist,dass diese in der Lage sind automatisch zusätzliche Informationen aus dem Softwaresystemzu extrahieren und in die Dokumentation zu integrieren.

Für Benutzer von automatisch generierten Dokumentationen könnte ebenfalls positiv ver-merkt werden, dass die generierten Dokumentationen ein standardisiertes Aussehen besitzenund sie sich somit leichter zurecht finden, wenn sie damit einmal vertraut sind.

2.3 Dokumentation von ProgrammcodeDie Dokumentation von Programmcode mittels direkt im Code untergebrachten Kommenta-ren ist schon seit langem gängige Praxis. Um es aber Werkzeugen zu ermöglichen aus sol-chen Kommentaren eine separate Dokumentation zu generieren, ist es erstens nötig dieKommentare speziell auszuzeichnen, damit sie erkannt werden können und zweitens müs-sen die Kommentare an genau definierten Stellen im Code platziert werden, damit festgelegtist welchen Teil des Codes ein Kommentar beschreibt. Ein Werkzeug kann so aus diesenKommentaren und zusätzlichen Struktur- und Beziehungsinformationen, die es aus der Ana-lyse des Programmcodes gewinnen kann, eine vollständige Dokumentation erstellen.

2.4 Dokumentation von DatenbankenNeben den im Kapitel 2.1.1 aufgelisteten Aufgaben, die auch von einer Datenbankdoku-mentation erfüllt werden müssen existieren weitere Erwartungen an ein Datenbankdoku-mentation. Diese hängen dabei hauptsächlich vom anvisierten Zielpublikum und demZweck der Dokumentation ab. Unterschiedlich Benutzergruppen haben auch unterschiedli-che Anforderungen an eine Dokumentation und benötigen unterschiedliche Informationenüber die Datenbank. Während Endnutzer nur relative oberflächliche aber einfach Verständli-che Informationen brauchen, benötigen Entwickler sehr viel detaillierte Informationen undDatenbankadministratoren können nochmals auf andere sehr spezifische Informationen an-gewiesen sein. Daneben haben Dokumentationen auch unterschiedliche Verwendungszwe-cke. Einige Benutzer möchten sie verwenden, um sich einen Überblick über die Datenbankzu verschaffen, andere benötigen sie um spezifische Details nachzuschlagen.

Die im Bereich der Dokumentation von Programmcode verwendeten Konzepte und Ideensind teilweise auch auf den Bereich der Dokumentation von Datenbanken übertragbar. Wie

8

2 Grundlagen

bei der Dokumentation von Programmcode sind auch bei der Dokumentation von Datenban-ken einerseits die Kommentare von Codeteilen beziehungsweise hier Datenbankobjektenund andererseits die Struktur- und Beziehungsinformationen zwischen diesen Objektenwichtig. Deshalb sollten Dokumentationswerkzeuge die vorhandene Informationen im Da-tenbankschema möglichst gut nutzen um eine vollständige Dokumentation erstellen zu kön-nen. So bringt auch im Bereich von Datenbanken eine Automation des Dokumentations-Prozesses verschieden Vorteile mit sich. Wenn Dokumentationswerkzeuge automatisch In-formationen aus einem Datenbankschema auslesen können, ersparen sie so den Aufwanddiese Informationen manuell in eine Dokumentation mit aufzunehmen. Zusätzlich lässt sichder Aufwand für die Erstellung einer Dokumentation verringern wenn grosse Teil dieserAufgabe durch Werkzeuge übernommen werden. Des weiteren kann der Aufwand, um beiÄnderungen in der Datenbank die Dokumentation zu aktualisieren und synchronisieren aufein Minimum reduziert werden. Was die Wahrscheinlichkeit erhöht, dass die Dokumentationimmer aktuell ist und den genauen Zustand der momentanen Datenbank widerspiegelt. Alldiese Zusammen kann im Idealfall dann auch zu Zeit- und Kostenersparnissen führen.

9

3 Verwandte Arbeiten


3.1 Werkzeuge für die Dokumentation von ProgrammcodeWerkzeuge zur Dokumentation von Programmcode gibt es viele, einige sind nur für be-stimmte Programmiersprachen geeignet, andere sind generischer und können für verschie-dene Sprachen eingesetzt werden. Ansonsten sind sich die Werkzeuge in ihrer Funktions-weise sehr ähnlich. Da Java heutzutage eine sehr häufig eingesetzte Programmiersprache istund von Sun Microsystems direkt ein Dokumentationswerkzeug namens Javadoc2 mitgelie-fert wird, ist dieses Werkzeuge heute sehr bekannt und weit verbreitet. Deshalb und weil diein dieser Arbeit entwickelte Anwendung in gewissen Bereichen an Javadoc angelehnt ist,wird im folgenden Unterkapitel genauer auf Javadoc, als Vertreter für die Gruppe dieserWerkzeuge, eingegangen. Andere bekannte Werkzeuge sind Doxygen3 oder TwinText4, aufdie hier aber nicht weiter eingegangen wird.

3.1.1 JavadocJavadoc ist ein Werkzeug, das in Java Quelldateien die Deklarationen von Schnittstellen,Klassen, Methoden und Feldern sowie Dokumentationskommentare analysiert und darauseine Menge von HTML-Seiten generiert, welche diese Elemente dokumentieren. Für jedeKlassendatei wird eine HTML-Seite erstellt, die über verschiedene Querverweise mit ande-ren Seiten in Verbindung steht. Zusätzlich generiert Javadoc diverse Index- und Hilfsdatei-en, die das Navigieren in den Dokumentationsdateien erleichtern [SunJavaDoc].

Auch ohne zusätzliche Kommentare erstellt Javadoc aus den Java-Quelldateien eine brauch-bare Dokumentation aller Klassen und Schnittstellen. Durch das Einfügen von Dokumenta-tions-Kommentaren kann die Ausgabe aber zusätzlich bereichert werden. Ein Javadoc Kom-mentar beginnt mit /** und endet mit */ und sieht damit einem gewöhnlichen Kommentarsehr ähnlich. Er muss im Quelltext immer unmittelbar vor dem zu dokumentierenden Ele-ment (Klassen-, Methoden- oder Feld-Definition) platziert werden. Er kann aus mehrerenZeilen bestehen. Der erste Satz des Kommentars wird später als Kurzbeschreibung verwen-det. Zur Erhöhung der Übersichtlichkeit darf am Anfang jeder Zeile ein Sternchen stehen,welches später ignoriert wird. Innerhalb der Kommentare dürfen neben normalem Text auchHTML-Tags vorkommen. Sie werden unverändert in die Dokumentation übernommen und

2 http://java.sun.com/j2se/javadoc/3 http://www.doxygen.org4 http://www.ptlogica.com

10


erlauben es damit, bereits im Quelltext die Formatierung der späteren Dokumentation vor-zugeben. Javadoc erkennt des weiteren markierte Absätze innerhalb von Kommentaren sogenannte Tags. Die Tags müssen mit dem Zeichen @ beginnen und abgesehen von Leerzei-chen am Anfang einer Zeile stehen. Jeder Tag leitet einen eigenen Abschnitt innerhalb derBeschreibung ein, alle Tags eines Typs müssen hintereinander stehen [MerkblattJavaDoc].

Ein Javadoc-Kommentar besteht also grundsätzlich aus zwei Teilen, einer Beschreibung ge-folgt von einem Tag-Abschnitt. Die Beschreibung endet mit der ersten Zeile, die ein @ ent-hält. Zwischen der Beschreibung und den Tags sollte eine Leerzeile sein. Jeder Javadoc-Kommentar kann nur einen Beschreibungsblock enthalten. Nach den Tags kann die Be-schreibung nicht fortgesetzt werden [EinfJava] [SunJavaDoc].

3.1.1.1 TagsJavadoc kennt spezielle Annotationen, auch Tags genannt, die in Dokumentationskommen-taren eingebettet werden können. Diese Tags ermöglichen es eine besser strukturierte undformatierte Ausgabe zu erzeugen, indem wichtige Information speziell ausgezeichnet wer-den können. Zusätzlich ermöglichen sie Links auf andere Element im Programmcode oderexterne Ressource zu setzen, um so in der generierten Dokumentation eine bessere Navigati-on zu erhalten.

Ein Tag beginnt mit einem @ gefolgt vom Namen des Tags. Für Tag-Namen ist die Gross-und Kleinschreibung von Bedeutung. Ein Block-Tag muss am Anfang der Zeile stehen undkann höchstens von Leerzeichen und einem optionalen *, ansonsten wird es als normalerText betrachtet.

Es gibt zwei Arten von Tags: Block-Tags und Inline-Tags. Block-Tags können nur im Tag-Abschnitt, welcher nach der Beschreibung folgt, verwendet werden. Sie haben die Form:@tag. Inline-Tags können überall in der Beschreibung oder in Kommentaren von Block-Tags eingesetzt werden. Sie müssen von geschwungenen Klammern umgeben werden undhaben die Form: {@tag} [SunJavaDoc].

11

3.1 Werkzeuge für die Dokumentation von Programmcode

Zu den wichtigsten Tags gehören [MerkblattJavaDoc]:

Tag und Parameter Beschreibung

@author Name Kann verwendet werden um den Autor eines Elements zu do-kumentieren.

@version Version Kann eingesetzt werden um eine Versionsnummer für Ele-mente zu führen. Statt einer eigenen Versionsnummer ist esauch möglich die Versionsnummern von Quellcodeverwal-tungssystemen zu verwenden.

@see Referenz Erzeugt einen Querverweis auf ein anderes Element der Do-kumentation. Es gibt drei Arten von Verweisen. Die erste isteinfacher Text. Die zweite ist eine URL, wie sie in HTMLverwendet wird und die dritte verweist auf andere Javadoc-Elemente. Zusätzlich kann optional noch eine Beschriftungangegeben werden, die anstelle der Referenz angezeigt wird.

@param Name Beschrei-bung

Wird verwendet um die Parameter einer Methode zu beschrei-ben.

@return Beschreibung Wird verwendet um den Rückgabewert einer Methode zu be-schreiben.

@exception Klassenna-me Beschreibung

Wird verwendet um die Ausnahmen, die von einer Methodegeworfen werden, zu dokumentieren.

@deprecated Beschrei-bung

Markiert eine veraltete Methode, die zukünftig nicht mehrverwendet werden sollte.

Tabelle 1: Javadoc Tags

3.1.1.2 DocletSeit Java 1.2 existiert die Möglichkeit über das Konzept der Doclets die Ausgabe von Java-doc den eigenen Bedürfnissen anzupassen. Doclets sind für die Ausgabe der eigentlichenDokumentation verantwortlich und bestimmt somit das Aussehen der Dokumentation. Jenach Programmierung des Doclets kann Javadoc Dokumentationen in den verschiedenenFormaten generieren. Wenn beim Aufruf von Javadoc keine Doclet angegeben wird, wirddas Java Standard Doclet verwendet, welches eine Ausgabe in HTML erzeugt.

12


Um die Ausgabe von Javadoc den eigenen Wünschen anzupassen, muss man nur eigeneDoclets schreiben. Dadurch kann man dann eigene Tags und eigene Kommandozeilenoptio-nen verarbeiten, als auch andere Ausgabeformate als HTML erzeugen, ohne das man die zudokumentierenden Quelldateien ändern muss [SunJavaDoc].

3.2 Werkzeuge für die Dokumentation von DatenbankenIn diesem Unterkapitel werden einige existierende Werkzeuge näher vorgestellt, die automa-tisch Dokumentationen für Datenbanken erstellen können. Grundsätzlich ist die Arbeitswei-se aller Programme sehr ähnlich, sie unterscheiden sich dann aber zum Teil im Funktions-umfang, der Benutzung und den unterstützten Datenbanksystemen. Für ausgewählte Werk-zeuge werden deren Möglichkeiten, Besonderheiten und Vor- und Nachteile genauer be-schrieben.

3.2.1 DBScribeDBScribe ist eine von der Firma Leadum Software5 entwickelte Applikation zur Dokumen-tation von Datenbankenschemas. Es existieren fünf verschiedene Versionen der Software,von denen jede für ein bestimmtes Datenbanksystem vorgesehen ist. So gibt es Versionenfür Microsoft SQL Server 7 oder neuere Versionen, für Oracle Database 8i oder neuere Ver-sionen, für MySQL Server 3.23 oder neuere Versionen, für IBM DB2 Server 8.2 oder neuereVersionen und für PostgreSQL Server 7.4 oder neuere Versionen. In weiten Teilen sind sichdiese Versionen sehr ähnlich und unterscheiden sich nur geringfügig in den Möglichkeitenzur Dokumentation von Datenbankobjekten. Alle Versionen verfügen über eine grafischeOberfläche, die mit Hilfe von „Wizards“ durch den Prozess der Dokumentationsgenerierungführen. Daneben besitzen alle Versionen ebenfalls die Möglichkeit das Programm über dieKommandozeile zu steuern.

Als Ausgabeformate für die Dokumentation werden HTML, HTML-Help und MS Word an-geboten. Bei der HTML-Ausgabe ist es möglich zwischen einer ein- oder einer mehrseitigenHTML-Dokumentation zu wählen. Ebenfalls können für alle Ausgabeformate verschiedeneStile für die Darstellung, zum Beispiel elegant oder modern, ausgewählt werden. Neben deneben genannten Möglichkeiten die Ausgabe zu formatieren, gibt es weitere Möglichkeitenum den Inhalt der Dokumentation zu konfigurieren. DBScribe unterstützt eine grosse An-zahl von Datenbankobjekttypen und bietet für jeden von ihnen eine Vielzahl von Eigen-schaften, die dokumentiert werden können. Speziell hervorzuheben ist an diesem Werkzeug,dass für jeden Datenbankobjekttyp genau festgelegt werden kann, welche Eigenschaften

5 http://www.leadum.com

13

3.2 Werkzeuge für die Dokumentation von Datenbanken

dieses Typs dokumentiert werden sollen und ob die Objekte dieses Typs überhaupt doku-mentiert werden sollen. In einer feineren Auswahl kann zusätzlich noch für jedes einzelneDatenbankobjekt festgelegt werden, ob es in die Dokumentation miteinbezogen werden soll.Alle Konfigurationseinstellungen können gespeichert werden und erleichtern damit die wie-derholte Ausführung.

Je nach Version von DBScribe und damit je nach Datenbankanbindung sind die Datenban-kobjekttypen, welche kommentiert werden können, unterschiedlich. Alle Versionen, abgese-hen von der Version für PostgreSQL, besitzen ebenfalls die Möglichkeit Kommentare direktin DBScribe zu editieren. Trotzdem werden aber auch für PostgreSQL die schon vorhande-nen Kommentare ausgelesen und in die Dokumentation übernommen.

Allgemein scheint es, dass in DBScribe den Kommentaren von Datenbankobjekten keinebesondere Stellung in Bezug auf die anderen Eigenschaften der Objekte zukommt, da sie inder Ausgabe nur als eine unter vielen Eigenschaften eines Datenbankobjekts ausgegebenwerden und nicht besonders abgegrenzt oder gekennzeichnet werden. So hat dann auch dieDokumentation einen eher technischen Charakter. Trotzdem kann man aber zur Ausgabe po-sitiv vermerken, dass sie sauber strukturiert ist und im mehrseitigen HTML-Format über einpraktisches Menü verfügt. Dieses Menü besitzt für alle Datenbankobjekttypen einen Ein-trag, der auf und zugeklappt werden kann und alle Objekte dieses Typs enthält. Damit er-leichtert es die Navigation und erhöht die Übersichtlichkeit der Dokumentation in bedeuten-dem Masse. Was besonders im Vergleich mit der Navigationsfreundlichkeit mit anderenFormaten auffällt, wo es einiges umständlicher ist im Dokument zu navigieren. [DBScribe]

3.2.2 SQL DocVon der Firma Red Gate Software6 wird die Applikation SQL Doc angeboten. SQL Doc istausschliesslich für die Dokumentation von Microsoft SQL Server Datenbanken geeignet. Esist in einer Standard- und einer Professional-Version verfügbar. Die Professional-Versionverfügt zusätzlich über eine Kommandozeilen-Schnittstelle, welche es erlaubt das Pro-gramm automatisch zu starten.

SQL Doc ermöglicht es alle im Datenbankschema vorhandenen Objekt einzeln zu dokumen-tieren und auch Kommentare für alle Objekte zu spezifizieren. Die Kommentare werdenüber die von Microsoft SQL Server angebotene Möglichkeit von „Extended Properties“ ge-speichert. Für die Benutzerführung bietet SQL Doc eine gute und intuitive grafische Ober-fläche. Hilfereich ist auch, dass die erzeugte HTML-Dokumentation sehr ähnlich aussiehtwie die grafische Oberfläche. Dies erleichtert die Orientierung in beiden Teilen.

6 http://www.red-gate.com

14


Zu den Vorteilen von SQL Doc zählt, dass mehre Datenbanken gleichzeitig dokumentiertwerden können, wobei auch die Abhängigkeiten zwischen den Objekten aus verschiedenenDatenbanken aufgezeigt werden. Die grösste Einschränkung ist, dass SQL Doc nur zur Do-kumentation von Datenbanken auf Microsoft SQL Server 2000 und SQL Server 2005 fähigist. Dies ist möglicherweise auf die Verwendung der proprietären Funktion von „ExtendedProperties“ zurückzuführen, die nur in Microsoft SQL Server Datenbanksystemen vorhan-den ist. Ein weiterer Nachteil ist, dass als Ausgabeformate nur HTML und HTML-Help zurVerfügung stehen. [SQLDoc]

3.2.3 SqlSpecSqlSpec ist ein Datenbankdokumentationswerkzeug von der Firma Elsasoft7. Es bietet so-wohl ein grafische Benutzeroberfläche als auch eine sehr umfangreiche Kommandozeilen-Schnittstelle zur Konfiguration der Applikation. Bemerkenswert ist, dass SqlSpec sehr vieleDatenbanksysteme unterstützt. So können Datenbanken auf Microsoft SQL Server 200,2005 oder neuere Versionen, Analysis Server 2005, Oracle Database 9i oder neuere, DB28.2 oder neuere, Sybase ASE 12.0 oder neuere, Informix IDS 10.0 oder neuere, PostgreSQL8.0 oder neuere, MySQL 5.0 oder neuere, Access 97 oder neuere, VistaDB 3.0 oder neuere,ENEA Polyhedra 7.0 oder neuere Versionen dokumentiert werden.

Als Ausgabeformate bietet es dann aber nur HTML oder HTML-Help. Dafür ist die HTML-Ausgabe gut gestaltet und mit vielen Grafiken ausgestattet. So können für alle Datenban-kobjekte Abhängigkeitsgraphen ausgegeben werden. Die Graphen werden aber im VML(Vector Markup Language) Format ausgegeben, welches momentan nur der Microsoft Inter-net-Explorer anzeigen kann.

Ein weiteres spezielles Merkmal von SqlSpec ist, dass für Microsoft SQL Server Daten-banksysteme über „Extended Properties“ Kommentare mit Tags spezifiziert werden können.Zusätzlich ist es für gespeicherte Prozeduren, benutzerdefinierte Datentypen und Sichtenmöglich Kommentare und Tags im SQL-Code dieser Datenbankobjekte zu hinterlegen.Dazu wird ein spezielles XML-Format verwendet um die Kommentare und Tags auszu-zeichnen. Die möglichen Tags bieten aber nur relativ wenig Funktionalität und allgemeinkönnen sie nur für bestimmte Objekte und auch nur bei Microsoft SQL Server Datenbankenverwendet werden. [SqlSpec]

3.2.4 ApexSQL DocVon der Firma ApexSQL LLC8 wird das Dokumentationswerkzeug ApexSQL Doc vertrie-7 http://www.elsasoft.org8 http://www.apexsql.com

15

3.2 Werkzeuge für die Dokumentation von Datenbanken

ben. Dieses Werkzeug verfügt über eine grafische Benutzeroberfläche sowie eine Komman-dozeilen-Schnittstelle zur Konfiguration. Wobei die grafische Oberfläche über sehr vieleOptionen verfügt, um genau festlegen zu können, welche Datenbankobjekttypen mit wel-chen Informationen dokumentiert werden sollen.

Eine grundlegende Einschränkung von ApexSQL Doc ist, dass es nur Datenbanken auf Mi-crosoft SQL Server Datenbanksystemen dokumentieren kann. Dafür ist es in der Lage meh-rere Datenbanken gleichzeitig zu dokumentieren. Als Ausgabeformate stehen ebenfalls nurHTML und HTML-Help zur Verfügung. Aber die HTML-Ausgabe verfügt über ein komfor-tables Menü zur Navigation und für alle Datenbankobjekte werden Abhängigkeitsgraphenausgegeben.

In ApexSQL Doc werden die benutzerdefinierten Kommentare ebenfalls über die MicrosoftSQL Server „Extended Properties“ gespeichert. Zusätzlich gibt es die Möglichkeit Kom-mentare in SQL-Skripts für diejenigen Datenbankobjekte, für welche der SQL Server dieSQL-Skripts speichert, zu spezifizieren. Speziell an ApexSQL Doc ist, dass es möglich ist indiesen Kommentaren vordefinierte Tags zu verwenden. Es stehen sechs verschiedene Tagszur Verfügung: „Summery“, „Remarks“, „Returns“, „Seealso“, „Param“ und „Isnew“. Aberleider können die meisten dieser Tags nur für Relationen, Sichten, benutzerdefiniert Daten-typen, gespeicherte Prozeduren, Trigger, Regeln und Indexes verwendet werden. [Apex-SQLDoc]

3.2.5 Zusammenfassende Feststellungen über die WerkzeugeNeben den hier beschriebenen Werkzeugen existieren noch weitere Werkzeuge zur Doku-mentation von Datenbanken, da sie aber alle relative ähnliche Grundfunktionalitäten haben,wurde darauf verzichtet alle Werkzeuge im Detail zu beschreiben. Weitere Werkzeuge wä-ren unter anderem dbdesc9, SchemaToDoc10, BI Documenter11, SQL Scribe DocumentationBuilder12 oder SQL Documentation Tool13.

Als erstes fällt auf, dass viele Werkzeuge nur Microsoft SQL Server Datenbanksysteme un-terstützen und es nur sehr wenige gibt, die wirklich viele verschiedene Datenbanksystemeunterstützen. Ausserdem bieten die meisten Werkzeuge nur HTML und HTML-Help alsAusgabeformate an oder eventuell noch Microsoft Word oder PDF, aber keine speziellen,wie zum Beispiel Gegenstands-Beziehungs-Diagramme. Und leider bietet auch keines die-ser Werkzeuge eine Möglichkeit neue Datenbankanbindungen oder neue Ausgabeformate zu

9 http://www.dbdesc.com/10 http://www.schematodoc.com/11 http://www.bidocumenter.com/Public/Default.aspx12 http://www.geckoware.com.au/Content.aspx?Doc_id=100113 http://www.winnershtriangle.com/w/Products.SQLDocumentationTool.asp

16


definieren und hinzuzufügen.

Einige Werkzeuge erlauben die Spezifikation von benutzerdefinierten Kommentaren mitTags, doch weisen sie alle sehr viele Einschränkungen diesbezüglich auf. Meistens werdensolche Kommentare mit Tags von Werkzeugen nur in Verbindung mit Microsoft SQL ServerDatenbanksystemen über den „Extended Properties“ Mechanismus unterstützt. Oder nur fürbestimmte Datenbankobjekttypen, für welche SQL-Skripts im Datenbanksystem gespeichertwerden. Ferner sind die von Tags gebotenen Möglichkeiten als relativ einfach zu betrachten.So existiert beispielsweise selten eine Möglichkeit über Verweise andere Datenbankobjektezu referenzieren, besonders nicht um solche Verweise direkt im fliessenden Kommentartextzu spezifizieren. Ausserdem bietet keines dieser Werkzeuge auch nur ansatzweise eine Un-terstützung für die Dokumentation von Datenbankentwurfsmustern.

17

4 Anforderungsspezifikation

4 AnforderungsspezifikationIn diesem Kapitel werden im ersten Teil die allgemeinen Anforderungen, die an eine Soft-ware zur automatischen Dokumentation von Datenbanken gestellt werden, beschrieben undin einem zweiten Teil die speziellen Anforderungen für die im Rahmen dieser Diplomarbeiterstellten Anwendung spezifiziert.

4.1 Grundlegende AnforderungenIn den folgenden Unterkapiteln werden die wichtigsten Anforderungen detailliert erläutert.

4.1.1 Anbindung unterschiedlicher DatenbanksystemeUm ein breites Einsatzgebiet für die Anwendung zu erschliessen, ist es essentiell, dass dieAnwendung mit verschiedenen relationalen Datenbanksystemen zusammenarbeiten kann.Die Anwendung soll deshalb standardmässig die Anbindung von unterschiedlichen relatio-nalen Datenbanksystemen unterstützen sowie ebenfalls die Anbindung von neuen Daten-banksystemen erlauben. Dadurch soll es möglich werden relationale Datenbanken zu doku-mentieren, die auf einem beliebigen relationalen Datenbanksystem installiert sind.

4.1.2 Verschiedene Ausgabeformen und FormateEine Anwendung zur Dokumentation von Datenbanken muss in der Lage sein eine Daten-bank in verschiedenen Formen und Formaten zu dokumentieren. Für die Dokumentationvon Datenbanken können ganz unterschiedliche Formen eingesetzt werden. So können Da-tenbanken beispielsweise durch Gegenstands-Beziehungs-Diagramme oder durch reineTextdokumente beschrieben und dokumentiert werden. Deshalb soll die Anwendung ver-schiedene Formen der Dokumentation anbieten. Weiter soll die Anwendung in der Lage seinverschiedene Formen der Dokumentation auch in verschiedenen Dateiformaten auszugeben.So können Gegenstands-Beziehungs-Diagramme als Bilddatei oder als XML-Datei undTextdokumente können als HTML- oder als PDF-Dokument ausgegeben werden.

Die Anwendung soll deshalb von sich aus schon verschiedene Ausgabeformen und Formateanbieten, aber zusätzlich sollte sie auch die Erstellung von neuen Ausgabeformen und For-maten ermöglichen. Als standardmässige Ausgabeformate wären da sicher an HTML, PDFoder auch Microsoft Word beziehungsweise ODF14 zu denken. Des weiteren sind sicherauch Gegenstands-Beziehungs-Diagramme eine wichtige Form der Dokumentation von Da-14 OASIS Open Document Format for Office Applications

18


tenbanken.

4.1.3 Unterstützung von DatenbankentwurfsmusterVon der Anwendung muss ein Mechanismus angeboten werden um die Dokumentation vonDatenbankentwurfsmustern zu unterstützen. Dabei soll für einfache Datenbankentwurfs-muster eine direkte interne Unterstützung angeboten werden und für komplexere Entwurfs-muster soll es eine Möglichkeit geben eine Unterstützung hinzuzufügen. Da Entwurfsmustersehr unterschiedlich und komplex sein können, kann es schwierig sein, solche direkt zu un-terstützen. Deshalb muss es für Anwender möglich sein durch die Definition von eigenenKomponenten eine Unterstützung für spezielle Datenbankentwurfsmuster hinzuzufügen. So-mit können unterschiedlichste Entwurfsmuster verarbeiten und angemessen dokumentiertwerden.

4.1.4 Kommentare und AnnotationenUm eine gute und ausführliche Dokumentation einer Datenbank erstellen zu können, sindbenutzerdefinierte Kommentare zur Beschreibungen von Datenbankobjekten unerlässlich.Deshalb muss die Anwendung einige Anforderungen bezüglich benutzerdefinierten Kom-mentaren erfüllen. Erstens muss es möglich sein alle vorhandenen Datenbankobjekte einzelnmit einem Kommentar zu versehen. Zweitens sollen Kommentare irgendwo persistent ge-speichert werden können, am besten direkt in der Datenbank und in einer standardisiertenArt und Weise, um dann von der Anwendung ausgelesen werden zu können. Drittens soll esebenfalls möglich sein Kommentare über die Anwendung zu definieren, zu ändern oder zulöschen.

Eine weitere sehr wichtige Anforderung für Kommentare ist, dass in Kommentaren auchAnnotationen verwendet werden können. Annotationen bieten die Möglichkeit Metadatenim Kommentar unterzubringen. Durch solche Metadaten können zum einen verschiedeneTeile eines Kommentars und zum anderen das mit dem Kommentar beschriebene Objektspeziell ausgezeichnet werden. Deshalb muss die Anwendung in der Lage sein solche Anno-tationen verarbeiten zu können. Sie soll standardmässig verschiedene Annotationen für ver-schiedene Zwecke anbieten und genau definieren wie und wo diese Annotationen eingesetztwerden können. Zusätzlich ist es aber auch wünschenswert, dass der Benutzer eigene Anno-tationen definieren und verwenden kann.

Allgemein muss es spezielle Annotationen geben um das Aussehen und die Struktur, bezie-hungsweise die Formatierung eines Kommentars in der Dokumentation, bestimmen zu kön-nen. Beispielsweise indem spezielle Information abgegrenzt, versteckt oder hervorgehoben

19

4.1 Grundlegende Anforderungen

werden. Dann muss es Annotationen geben um den Inhalt eines Kommentars an verschiede-nen Situationen beziehungsweise Benutzergruppen anpassen zu können. Weiter müssen An-notationen vorhanden sein um im Kommentar eines Datenbankobjekts andere Datenbankob-jekte referenzieren zu können, um so Verbindungen zwischen Datenbankobjekten zu schaf-fen. Als letztes soll es auch noch Annotationen geben mit welchen Metadaten über das Da-tenbankobjekt selber hinzugefügt werden können, um eine spezielle Behandlung dieser Ob-jekte in der Anwendung zu erlauben. Beispielsweise indem so ausgezeichnete Objekte inder Dokumentation speziell hervorgehoben oder aber ganz ausgelassen werden.

4.1.5 Flexible ArchitekturZwei Aspekte sind bei der Architektur von besonderer Bedeutung. Erstens muss die Anwen-dung grundsätzlich über eine flexible Architektur verfügen und zweitens müssen klareSchnittstellendefinitionen für die einzelnen Komponenten vorhanden sein. Beides zusam-men ist notwendig, um eine einfache Erweiterung der Anwendung zu gewährleisten. So solles möglich sein einzelne Komponenten der Anwendung zu erweitern, auszutauschen oderneu zu kombinieren, um so die Funktionalität der Anwendung an verschiedene Gegebenhei-ten anpassen zu können.

4.1.6 Generisches DatenmodellDie Anforderung bezüglich des internen Datenmodells sind eher für die Implementierungwichtig, aber trotzdem entscheidend für eine flexible und erweiterbare Anwendung.

Als Basis für die Anwendung muss ein internes Datenmodell definiert werden. Im Zusam-menhang mit dieser Anwendung wird unter dem internem Datenmodell eine Datenstrukturzur temporären Speicherung von Informationen über eine Datenbank verstanden. Für dengeordneten Zugriff auf die im Datenmodell gespeichert Informationen müssen klare Schnitt-stellendefinitionen erstellt werden. Und da viele Komponenten mit den Information aus demDatenmodell arbeiten müssen, ist es von entscheidender Bedeutung, dass die Schnittstellenleicht verständlich und gut strukturiert sind sowie sich nicht ändern. Klare Schnittstellende-finitionen im Datenmodell sind ebenfalls für die Erweiterbarkeit und den Austausch vonKomponenten extrem wichtig.

Eine weitere wichtige Anforderung an des Datenmodell ist, dass es möglichst generisch seinmuss. Wodurch es möglich sein soll Informationen über Datenbanken von verschiedenstenDatenbanksystemen zu speichern. Es soll also so allgemein sein, dass es sich für die Anbin-dung von unterschiedlichen Datenbanksystemen und auch für die Erstellung von verschie-denen Ausgabeformaten eignet.

20


4.1.7 Weitere AnforderungenWeitere, aber weniger zentrale Anforderungen an eine Anwendung zu Dokumentation vonDatenbanken sind: Erstens sollte die Anwendung möglichst benutzerfreundlich sein und zudiesem Zweck einerseits eine grafische Oberfläche sowie andererseits eine Mechanismuszur automatischen Ausführung ohne Benutzerinteraktion bereitstellen. Für die automatischeAusführung muss es deshalb möglich sein alle Konfigurationseinstellungen zu speichernund die Anwendung über die Kommandozeile zu starten. Zweitens ist es besonders bei derautomatischen Ausführung wichtig, dass die Anwendung auch im Fall von Fehlern oder un-erwarteten Vorkommnissen während der Ausführung angemessen reagieren kann und denBenutzer über die Vorkommnisse detailliert informieren kann. Drittens und letztens mussdie Anwendung in der Lage sein die Dokumentation einer Datenbank in einer angemesse-nen Zeit zu generieren.

4.2 Spezielle AnforderungenFür die in Rahmen dieser Diplomarbeit entwickelten Anwendung gelten einige spezielleAnforderungen. Hauptsächlich weil für die Erstellung der Anwendung nur sehr begrenzteRessourcen zur Verfügung stehen. Dies erlaubt es nicht alle gestellten Anforderungen in ih-rer ganzen Breite und Tiefe zu implementieren. Dies ist aber auch nicht das Ziel, sondern essollen Lösungsvorschläge für die grundlegenden Probleme entwickelt und die Machbarkeitund Eignung anhand einer Implementierung aufgezeigt werden.

Für die Implementierung der Anwendung soll als Programmiersprache ausschliesslich Javain der Version 1.5 eingesetzt werden. Für die Anbindung von Datenbanksystemen soll esgrundsätzlich möglich sein unterschiedliche Datenbanksysteme zu unterstützen und es mussmindestens eine Datenbankanbindung für die Anbindung von PostgreSQL Datenbanksyste-men implementiert werden. Für die Ausgabe der Dokumentation bestehen ähnliche Anfor-derungen. So sollen grundsätzlich verschiedene Ausgabeformate möglich sein und es mussmindestens die Ausgabe einer Dokumentation im HTML-Format implementiert werden.Um die Möglichkeiten der Anwendung zur Unterstützung von Datenbankentwurfsmuster zuzeigen, sollen verschiedene Entwurfsmuster, die in der sesamDB zum Einsatz kommen, un-terstützt werden.

21

5 Design

5 DesignUm die im vorhergehenden Kapitel gestellten Anforderung an die Anwendung erfüllen zukönnen, wurden verschieden Konzepte entwickelt, die in diesem Kapitel beschrieben wer-den. Aus den Anforderungen geht hervor, dass beim Design besonderen Wert auf die Er-weiterbarkeit und Flexibilität gelegt werden muss. Zu den wichtigsten Designkriterien zähltdeshalb die Erweiterbarkeit, die Flexibilität sowie die Wiederverwendung von einzelnenKomponenten und eine klare Definition der Schnittstellen zwischen den einzelnen Kompo-nenten.

In den folgenden Unterkapiteln wird jeweils auf einen Teilaspekt des Designs eingegangen.Wobei zuerst das Design des internen Datenmodells, anschliessend die Plug-in Architekturmit den verschiedenen Plug-in Typen und zum Schluss noch das Design für Kommentareund Annotationen beschrieben wird.

5.1 DatenmodellDie meisten Komponenten einer Anwendung zur Dokumentation von Datenbanken müssenin irgendeiner Form mit Informationen über eine Datenbank arbeiten. Komponenten zumEinlesen von Informationen aus einer Datenbank müssen diese Information irgendwo tem-porär speichern können damit andere Komponenten später darauf zugreifen können. Kom-ponenten zur Ausgabe der Dokumentation müssen irgendwo die Information über die Da-tenbank beziehen können und zwischen diesen Phasen sollten weitere Komponenten solcheInformationen auch verändern und anpassen können.

Für die Anwendung ist deshalb die Definition eines internen Datenmodells, zur temporärenSpeicherung der Informationen über die Datenbank, von zentraler Bedeutung. Bei diesen In-formationen handelt es sich vorwiegend um Information über in der Datenbank vorhandeneDatenbankobjekte. So werden mit dem Datenmodell diese Datenbankobjekte, ihre Strukturund ihre Beziehungen beschrieben. Konkret werden Datenbankobjekte durch Schnittstellenbeschrieben. Diese Schnittstellen spezifizieren die Eigenschaften und die Beziehungen vonDatenbankobjekten und ermöglichen den Zugang zu diesen Informationen. Eine klare Defi-nition der Schnittstellen ist wichtig, weil sich andere Komponenten darauf verlassen müs-sen, wenn sie mit Information über Datenbankobjekte arbeiten wollen.

Beim Design des Datenmodells musste auf verschiedene Punkte bezüglich der Flexibilitätund der Allgemeingültigkeit des Modells geachtet werden. Zum einen soll das Datenmodellso allgemeingültig sein, dass darin Informationen über Datenbankobjekte aus unterschiedli-

22

5 Design

chen Datenbanksystemen gespeichert werden können, um so eine Anbindung von unter-schiedlichen Datenbanksystemen zu ermöglichen. Zum anderen sollen die im Datenmodellgespeicherten Informationen so allgemein repräsentiert werden, dass sich daraus verschiede-ne Ausgaben generieren lassen.

5.1.1 SchnittstellenhierarchieWie schon angesprochen handelt es sich bei den Informationen über eine Datenbank haupt-sächlich um Informationen über Datenbankobjekte. In einer Datenbank existieren viele ver-schiedene Arten von Datenbankobjekten. Objekte einer Datenbank sind unter anderemSchemas, Relationen, Sichten, Spalten, Datentypen, Indexes, Einschränkungen oder Trigger.Um im Datenmodell die verschiedenen Typen von Datenbankobjekten zu repräsentieren,wurde für jeden Typ eine eigene Schnittstelle entwickelt. Zusätzlich wurde für die generi-sche Repräsentation von Datenbankobjekten eine übergeordnete Schnittstelle erstellt, wel-che die Eigenschaften beschreibt, die allen Datenbankobjekten gemeinsam sind. Das Ergeb-nis dieses Designschrittes ist eine Schnittstellenhierarchie, in welcher alle Schnittstellen zuDatenbankobjekten definiert werden. Weil diese Schnittstellenhierarchie mit 26 Schnittstel-len zur Beschreibung von Datenbankobjekten sehr umfangreich ist, wird in Abbildung 1 nurein Ausschnitt der Schnittstellenhierarchie mit einigen zentralen Schnittstellen dargestellt.

23

5.1 Datenmodell

24

5 Design

25

Abbildung 1: Ausschnitt aus der Schnittstellenhierarchie

5.1 Datenmodell

Zuoberst in der Hierarchie befindet sich die Schnittstelle DBObjectInfo. Diese Schnitt-stelle abstrahiert vom konkreten Typ eines Datenbankobjekts und repräsentiert damit gene-risch ein beliebiges Datenbankobjekt. Von dieser allgemeinen Schnittstelle erben andereSchnittstellen, um sie zu erweitern und spezifische Eigenschaften von Datenbankobjektty-pen zu repräsentieren. So erbt die Schnittstelle OwnedDBObjectInfo von DBObject-Info. Diese repräsentiert generell ein Datenbankobjekttyp, welcher einen Besitzer hat. DerBesitzer eines Datenbankobjekts ist ein Datenbankbenutzer, welcher über spezielle Rechtefür dieses Datenbankobjekt verfügt. Von der Schnittstelle OwnedDBObjectInfo erbenweiter Schnittstellen, wie zum Beispiel RelationInfo, welche Datenbankobjekttypen re-präsentiert, die eine „tabellenartige“ Struktur haben, wie Relationen und Sichten. Deshalberben von RelationInfo die Schnittstellen TableInfo und ViewInfo, welche kon-krete Datenbankobjekttypen, nämlich eine Relation beziehungsweise eine Sicht beschrei-ben. Neben diesen Schnittstellen existieren noch viele weitere Schnittstellen, je eine pro Da-tenbankobjekttyp.

Noch wichtig zu erwähnen ist, dass die Schnittstelle DBObjectInfo von der SchnittstelleComparable erbt. Dadurch wird es möglich, beliebige Datenbankobjekt miteinander zuvergleichen und in weiterer Konsequenz auch zu sortieren. Datenbankobjekte werden in ers-ter Instanz alphabetisch anhand ihres Typs und in zweiter Instanz alphabetisch anhand ihresvollen Namens sortiert. Nur für Spalten wurde geringfügig davon abgewichen. Und zwarwerden Spalten, die sich in der selben Relation oder Sicht befinden, nicht nach ihrem Spal-tennamen sondern nach ihrer Spaltennummer sortiert. Die Entscheidung alle Datenbankob-jekttypen die Schnittstelle Comparable implementieren zu lassen, wurde getroffen, weil,wenn in anderen Komponenten mit Mengen oder Sets von Datenbankobjekten gearbeitetwerden muss, diese immer schon sortiert sind und die Arbeit dadurch erleichtert wird.

Zusätzlich zu den Schnittstellen für Datenbankobjekttypen wurde noch eine Schnittstelle na-mens RootInfo erstellt, welche den zentralen Zugangspunkt zum Datenmodell darstellt.Über diese Schnittstelle ist es möglich auf alle vorhandenen Datenbankobjekte zuzugreifen.Sie bietet Methoden um alle Datenbankobjekte eines Typs zu erhalten oder auch um be-stimmte Datenbankobjekt aufgrund von bestimmten Eigenschaften zu suchen.

Für das Design des Datenmodells wurde eine Schnittstellenhierarchie einer Klassenhierar-chie vorgezogen, da diese generischer und flexibler ist. Durch diese Wahl bleibt die Imple-mentierung des Datenmodells austauschbar, weil andere Komponenten nicht spezielle Klas-sen sondern Schnittstellen referenzieren.

26

5 Design

5.1.2 Erzeugung der ObjekteUm nicht nur bei der Repräsentation der Datenbankobjekte sondern auch bei deren Erzeu-gung zu abstrahieren und somit von ihrer Implementierung unabhängig zu sein, wurde einEntwurfsmuster, das unter dem Namen „Abstrakte Fabrik“ bekannt ist, eingesetzt. Die Ab-strakte Fabrik gehört zur Gruppe der objektbasierten Erzeugungsmustern und bietet eineSchnittstelle zum Erzeugen von Objekten, ohne ihre konkreten Klassen zu benennen [Gam-ma04].

Das Entwurfsmuster besteht aus den Teilen:

● Abstrakte Fabrik, in diesem Fall die Schnittstelle DBObjectFactory. Sie dekla-riert eine abstrakte Schnittstelle für Methoden, die konkrete Produktobjekte erzeu-gen.

● Konkrete Fabrik, hier die Klasse POJOFactory, welche die Methoden zur Erzeu-gung konkreter Produktobjekte implementiert.

● Abstrakte Produkte sind hier die Schnittstellen der einzelnen Datenbankobjekte.Zum Beispiel TableInfo oder ColumnInfo.

● Konkrete Produkte sind hier die Klassen, welche die Schnittstellen implementieren.Zum Beispiel TableImpl oder ColumnImpl.

● Klienten, sind hier die alle Komponente, die Datenbankobjekte erzeugen möchten.Sie verwenden nur die Schnittstellen von der abstrakten Fabrik und von den abstrak-ten Produkten ohne ihre konkreten Implementierungen kennen zu müssen.

5.1.3 Namen und ReferenzierungAlle Schnittstellen von Datenbankobjekttypen besitzen Methoden um verschiedene Eigen-schaften von Objekten zu setzen und sie dann auch wieder auszulesen. Nur der Name einesDatenbankobjekts kann nicht verändert werden. Der Name wird bei der Erzeugung des Ob-jekts spezifiziert und kann dann nicht mehr geändert werden. Wie nachfolgend erklärt wirdist dies nötig, weil Datenbankobjekte häufig anhand ihres Namens und nicht ihrer Objekt-Referenz referenziert werden.

Bei den Methoden von Datenbankobjekttypen wird generell zwischen Methoden unterschei-den, welche einfache Werte, wie Zahlen oder Text, setzen und lesen und Methoden, welcheReferenzen auf andere Datenbankobjekte setzen und lesen. Bei Methoden die Referenzenauf andere Datenbankobjekte setzten werden die Referenzen in Form einer einfachen Zei-chenfolge, die den Namen des zu referenzierenden Objekts enthält übergeben.

27

5.1 Datenmodell

Beim Namen eines Datenbankobjekts handelt es sich um den SQL-Namen des Datenban-kobjekts wie er in der Datenbank definiert und verwendet wird, also den selben Namen denman auch in Datenbankanfragen verwenden würde, um auf das Objekt zuzugreifen. DerName eines Datenbankobjekts kann, wie im SQL-Standard definiert, aus mehreren Teilenbestehen. Je nachdem auf welcher Ebene die Namen von Datenbankobjekttypen eindeutigsind, müssen sie unterumständen mit dem Namen eines Schemas oder eines Schemas undeiner Relation qualifiziert werden, damit der Name über alle Datenbankobjekte eindeutig ist.Im folgenden wird deshalb zwischen dem einfachen und dem voll qualifizierten Namen vonDatenbankobjekten unterschieden.

Wenn die Methode einen bestimmten Typ eines Datenbankobjektes erwartet, kann entwederder qualifizierte oder der einfache Namen des Datenbankobjekts übergeben werden. Dereinfache Namen kann aber nur solange verwendet werden, wie der einfache Name über alleDatenbankobjekt dieses Typs eindeutig ist, ansonsten muss der qualifizierte Namen überge-ben werden. Erwartet die Methode keinen bestimmten Typ, das heisst es können beliebigeDatenbankobjekte übergeben werden dann kann es nötig sein zusätzlich noch den Typ desDatenbankobjekts dem qualifizierten Namen voran zustellen. Die Kombination dieser zweiInformationen ist notwendig, da die voll qualifizierten Namen von Datenbankobjekten zwareindeutig sind innerhalb des gleichen Typs, aber es ist möglich, dass ein Datenbankobjektvon einem anderen Typ mit dem selben voll qualifizierten Namen existiert. Zur eindeutigeIdentifikation eines Datenbankobjekte dient deshalb der Typ das Datenbankobjekts sowieder voll qualifizierte Namen des Datenbankobjekts.

5.1.4 VerlinkungDa in den Datenbankobjekten bei den Methoden zum Setzen von Referenzen nur Namenübergeben werden, ist es in einem späteren Schritt notwendig alle diese Referenzen aufzulö-sen und die tatsächlichen Objekt-Referenzen in den Datenbankobjekten zu speichern. Diesgeschieht nachdem alle Datenbankobjekte erzeugt wurden. Das RootInfo-Objekt verfügtüber Objekt-Referenzen auf alle Objekte, da alle Objekte direkt bei ihrer Erzeugung dort re-gistriert werden und deshalb ist es in der Lage alle Objekte zu verlinken. Nachdem alle Ob-jekte verlinkt sind können andere Komponenten ganz normal mit den Objekt-Referenzen ar-beiten und brauchen sich keine Gedanken mehr über die Namen zu machen.

Anstatt der Angabe von einfachen Zeichenfolgen bei den Methoden um Referenzen auf an-derer Datenbankobjekte zu setzen, wäre es auch möglich gewesen direkt die Referenzen aufObjekte anzugeben. Der Vorteil wäre, dass keine separate Verlinkung der Objekte nötig

28

5 Design

wäre und ebenfalls sichergestellt wäre, dass keine unbekannten Referenzen gesetzt werdenkönnten. Dies würde die Implementierung des Datenmodells erheblich vereinfachen, da dieObjekte dann wirklich nur noch einfache Java-Objekte mit Instanzvariablen und zugehöri-gen Methoden zum Setzen und Holen der Werte dieser Instanzvariablen.

Der grosse Nachteil dieser Variante käme aber bei der Implementierung einer Einlese-Kom-ponente zum Vorschein. Eine Einlese-Komponente bezeichnet hier eine Komponente mitder Informationen aus der Datenbank eingelesen werden. Dort müsste viel mehr Aufwandbetrieben werden, um die verschiedenen Datenbankobjekte korrekt zu erzeugen.

Es macht aber mehr Sinn diesen Aufwand in der Modell-Komponente zu betreiben, als inder Einlese-Komponente, denn Einlese-Komponenten wird es mehrere geben, während esnur eine Modell-Komponente geben wird. Dies vereinfacht die Erstellung von neuen Einle-se-Komponenten massiv und damit die Wahrscheinlichkeit, dass zusätzliche Einlese-Kom-ponenten für verschiedene Datenbanksysteme entwickelt werden.

Denn bei der Reihenfolge der Erzeugung und dem Setzten von Eigenschaften der Objektemüsste genau auf die Abhängigkeiten zwischen den Objekten Rücksicht genommen werden.Da aber viele Objekte sich gegenseitig referenzieren führt nicht einmal die strikte Einhal-tung der Reihenfolge beim Erzeugen der Objekte zum Ziel, denn wenn sich zwei Objektesich gegenseitig referenzieren ist es nicht möglich zu entscheiden welches Objekte zuerst er-stellt und dessen Eigenschaften gesetzt werden sollten. Denn beim setzen der Eigenschaftenbraucht man schon die Referenz auf das andere Objekt. So wäre die einfachste Lösung fürdie Einlese-Komponente nur zuerst alle Datenbankobjekte zu erzeugen und danach wennalle Referenzen vorhanden sind für jedes Objekt dessen Eigenschaften zu setzen. Diese führtaber zu einem erheblich grösseren Aufwand in der Einlese-Komponente, weil alle Referen-zen auf erzeugte Objekte gespeichert werden müssten um wieder auf sie zugreifen zu kön-nen. Oder die Referenzen können auch im Datenmodell gespeichert werden, damit dieserAufwand entfällt, aber trotzdem müssten viele Datenbankobjekt mehrmals verändert werdenum alle Eigenschaften vollständig zu konfigurieren.

Hingegen erlaubt der hier gewählte Ansatz der Einlese-Komponente sich mit jedem Daten-bankobjekte nur ein einziges mal zu beschäftigen. Das heisst ein Datenbankobjekt kann er-zeugt werden und gleich danach vollständig konfiguriert indem alle Eigenschaften gesetztwerden können. Dies wird ermöglicht indem Beziehungen zu anderen Objekten nicht direktüber die Objekt-Referenzen gesetzt werden müssen sondern nur über die Angabe des Na-men des zu referenzierendem Objekt. So können Referenzen auf andere Objekte gesetztwerden die zum diesem Zeitpunkt noch gar nicht existieren.

Natürlich ist es nötig das am Ende des Einlese-Prozesses alle Datenbankobjekte auf welche

29

5.1 Datenmodell

Referenzen existieren erzeugt wurden ansonsten wird das Modell nicht in der Lage sein alleReferenzen aufzulösen und es würden Fehlmeldungen für die nicht existierenden Objekteausgegeben.

5.2 Plug-in ArchitekturWie im Kapitel über die Anforderungen beschrieben, wird für die Gesamtarchitektur eineLösung gesucht, welche flexibel und erweiterbar ist. Ebenso soll die Anwendung verschie-dene Datenbankanbindungen, Ausgabeformate und Möglichkeiten zur Unterstützung vonDatenbankentwurfsmustern anbieten können. Diese funktional verschiedenen Bereiche derAnwendung eignen sich hervorragend um die Anwendung entsprechend in verschiedeneKomponenten zu unterteilen.

So wurden als erstes einzelne Komponenten aufgrund ihrer Zuständigkeiten identifiziert unddefiniert. Es entstand eine Aufteilung der Anwendung in vier Komponenten. Eine Kompo-nente ist für die Datenbankanbindung und damit für das Einlesen der Daten verantwortlich.Eine weitere Komponente ist für die Ausgabe der Daten und somit für die Generierung dereigentlichen Dokumentation zuständig. Eine dritte Komponente soll eine allgemeine Trans-formation der Daten erlauben und dadurch unter anderem ermöglichen Datenbankentwurfs-muster zu unterstützen. Die letzte Komponente schliesslich ist für die Realisierung des Da-tenmodells verantwortlich. Dieses Datenmodell wird von den anderen drei Komponentenverwendet um dort einerseits die eingelesenen Daten zu speichern und andererseits um zurWeiterverarbeitung wieder auf die Daten zugreifen zu können.

In einen zweiten Schritt wurde festgelegt, dass es verschiedene Varianten der einzelnenKomponenten geben kann um so verschiedene Datenbankanbindungen, verschiedene Aus-gaben, verschiedene Transformationen und verschiedene Implementierungen des Datenmo-dells zu ermöglichen. Wenn es verschiedene Varianten einer Komponenten gibt, kann derFunktionsumfang einer Variante auf ein bestimmtes Gebiet beschränkt werden. Zum Bei-spiel kann es für die Eingabe-Komponente eine Variante geben, die für die Anbindung vonPostgreSQL Datenbanksystemen verantwortlich ist und eine Variante, die für die Anbindungvon Microsoft SQL Server Datenbanksystemen verantwortlich ist. Oder bei der Ausgabe-Komponente kann es eine Variante geben, die Dokumentationen im HTML-Format erstelltund eine andere Variante, die Dokumentationen im PDF-Format erstellt. Der offensichtlicheVorteil von verschiedenen Varianten einer Komponente ist, dass eine Variante einen genaudefinierten Umfang hat und dadurch leichter zu verstehen und ebenfalls einfacher zu imple-mentieren ist.

Die Herausforderung beim Entwurf der Anwendung bestand nun darin eine Möglichkeit zu

30

5 Design

finden um den Umstand von verschiedenen Komponenten und verschiedenen Varianten vondiesen Komponenten im Design widerzuspiegeln. Sowie eine Architektur zu finden, die esder Anwendung ermöglicht verschiedene Varianten von Komponenten flexibel zu kombi-nieren, um so ihre Aufgabe zu erfüllen. So wurde angelehnt an die Konzepte von [Plugin-Arch] eine so genannte Plug-in Architektur entwickelt. Unter einem Plug-in verstehen wirhier eine Variante einer Komponente. Die Plug-in Architektur soll es der Anwendung er-möglichen ihre Funktionalität durch eine geeignete Kombination von Plug-ins zu erreichen.Und die Anwendung kann einfach an verschiedene Gegebenheiten angepasst werden indemPlug-ins hinzugefügt, entfernt oder ausgetauscht werden.

Die Plug-in Architektur besteht grundsätzlich aus einem Plug-in Manager und den einzelnenPlug-ins. Damit der Plug-in Manager mit verschiedenen Plug-ins zusammenzuarbeiten, be-ziehungsweise diese verwenden kann, ist es notwendig, dass Plug-ins über einheitlicheSchnittstellen verfügen, auf die sich der Plug-in Manager verlassen kann. Deshalb wurde einallgemeines Java Interface erstellt, das die grundlegende Schnittstelle eines Plug-ins be-schreibt. Analog zu den vier zuvor identifizierten Komponenten der Anwendung wurdenvier Plug-in Typen definiert und für jeden Typ wurde ein Java Interface spezifiziert. DieseInterfaces sind Untertypen des allgemeinen Plug-ins.

31

Abbildung 2: Plug-in Typen

5.2 Plug-in Architektur

Wie in Abbildung 2 zu erkennen ist, gibt es eine Schnittstelle namens DBDocPlugin, wel-ches die allgemeine Schnittstelle eines Plug-ins und dessen Grundfunktionen beschreibt.Von diesem wurde dann für jeden Typ von Plug-in eine Schnittstelle abgeleitet, welche diespeziellen Funktionen des Plug-in Typs spezifiziert.

Jedes Plug-in kennt die Methoden:

● name()

Gibt den den Namen des Plug-ins zurück.

● usage()

Gibt einen kurzen Text zurück, welcher Hinweise über die korrekte Verwendung so-wie möglichen Optionen des Plug-ins enthält.

● initialize(reporter : PluginReporter)

Initialisiert das Plug-in und sollte deshalb bei einem neue erstellten Plug-in als erstesaufgerufen werden. Ebenfalls übergibt es ihm einen PluginReporter zur Mel-dung von Statusinformationen.

● setupOptions(options : Map<String, String>)

Damit können dem Plug-in spezifische Optionen, in der Form von Schlüssel-WertePaaren, zur Konfiguration übergeben werden.

Die Methoden initialize() und setupOptions() können beide auch eine PluginExceptionwerfen, um dem Plug-in Manager eine Ausnahmesituation zu melden.

Das Ziel der Plug-in Architektur ist, dass es einfach und ohne Änderungen in der Anwen-dung möglich ist Plug-ins auszutauschen, neue hinzuzufügen oder sie anders zu kombinie-ren. Dies ist möglich, da der Plug-in Manager, welcher für die Verwaltung der Plug-ins ver-antwortlich ist, sich auf die Plug-in Schnittstellen verlassen kann, um die benötigten Metho-den der Plug-ins aufzurufen. Und zusätzlich werden ihm über Konfigurationsangaben dieKlassennamen der Plug-ins bekannt gegeben. So kann der Plug-in Manager die Klassen dy-namisch laden und danach gemäss ihrer Plug-in Schnittstelle verwenden. Durch diese Ar-chitektur werden nirgends im Code Klassennamen von Plug-in direkt codiert, sondern dieNamen der Klassen werden dem Plug-in Manager zur Laufzeit übergeben und erst dannwerden die Klassen dynamisch geladen. Neben dem Namen der Klasse benötigt der Plug-inManager noch weitere Angaben. Er muss wissen in welcher Reihenfolge die Plug-ins auszu-führen sind. Dies geschieht mit einer einfachen Zahl. Die Zahlen müssen dabei nicht fortlau-

32

5 Design

fend sein. Der Plug-in Manager führt einfach das Plug-in mit der kleinsten Zahl zuerst ausund dann der Reihe nach alle anderen. Zusätzlich muss der Plug-in Manager ebenfalls überalle Optionen der einzelnen Plug-ins verfügen, damit er sie den Plug-ins nachdem initialisie-ren übergeben kann. Um für die Anwendung zu spezifizieren, welche Plug-ins mit welchenOptionen ausgeführt werden sollten, gibt es zwei Möglichkeiten. Zum einen können Plug-ins und ihre Optionen auf der Kommandozeile und zum anderen in einer speziellen XML-Datei spezifiziert werden. Diese beiden Möglichkeiten werden im Kapitel 6 näher beschrie-ben.

5.2.1 Model-Plug-inEin Model-Plug-in ist allgemein gesagt eine Komponente, welche das Datenmodell imple-mentiert. Das Datenmodell ist eine zentrale Schnittstellenhierarchie, die unabhängig von derPlug-in Architektur definiert wurde. Und obwohl das Datenmodell selber nicht geändertwerden kann, so kann doch die Implementierung geändert werden. Deshalb wurde entschie-den die Implementierung des Datenmodells ebenfalls als Plug-in zu definieren, um so dieImplementierung des Datenmodells einfach austauschbar zu machen.

Über die Methoden provideRootInfo() stellt das Plug-in eine so genanntes RootInfo-Ob-jekt zur Verfügung, welches als Hauptzugangspunkt auf das Datenmodell fungiert und somitden Zugriff auf alle Informationen über die Datenbank ermöglicht.

Die Methode linkAllDBObjectInfos(rootinfo : RootInfo) übernimmt nach dem Einlesen undErstellen aller Datenbankobjekte die Verlinkung dieser Objekte in dem übergebenen Root-Info-Objekt.

5.2.2 Input-Plug-inEin Input-Plug-in ist eine Komponente, die zur Anbindung eines Datenbanksystems dient.Ein Input-Plug-in kann eine Verbindung zu einem Datenbanksystem aufnehmen, um dannInformationen über eine Datenbank auszulesen. Es kann über den Zugriff auf Schema-Infor-mationen, Informationen über vorhandene Datenbankobjekte gewinnen und mit diesen In-formationen und unter zur Hilfenahme des RootInfo-Objektes kann das Input-Plug-indann die entsprechenden Datenbankobjekte erstellen, um die Informationen für die spätereVerarbeitung zu speichern. Zu diesem Zweck besitzt ein Input-Plug-in die Methode readIn-put(rootinfo : RootInfo).

5.2.3 Output-Plug-inEin Output-Plug-in ist eine Komponente, welche die im Datenmodell beziehungsweise im

33

5.2 Plug-in Architektur

RootInfo-Objekt vorhandenen Informationen ausgeben kann und somit die eigentlicheDokumentation der Datenbank erstellt. Wie angesprochen kann es sehr verschiedene Out-put-Plug-ins geben.

Eine HTML-Ausgabe wurde gewählt, weil es eine sehr benutzerfreundliches Format ist. Ei-nerseits können HTML-Seiten plattformunabhängig auf allen Computersystemen angesehenwerden. Andererseits ist HTML sehr gut für die Benutzerführung geeignet, da Verlinkungenzur Verfügung stehen, dies im Gegensatz zu MS Word oder PDF Dokumenten wo nur einesehr eingeschränkte Verlinkung möglich ist. Ebenfalls eignen sich HTML-Dokumente bes-tens für die Veröffentlichung der Dokumentation über Inter- oder Intranet. Beim Design undder Implementierung der HTML-Ausgabe war es wichtig ein optisch ansprechendes Ergeb-nis zu produzieren sowie eine komfortable Navigation zur Verfügung zu stellen.

5.2.4 Transformator-Plug-inEin Transformator-Plug-in ist eine Komponente, welche die Informationen im Datenmodellbeziehungsweise die Datenbankobjekte im RootInfo-Objekt in irgendeiner Weise verän-dert. Sei es indem bestimmte Eigenschaftswerte von Datenbankobjekten geändert werden,neue Eigenschaften zu Datenbankobjekten hinzugefügt werden oder Datenbankobjekte ganzneu erzeugt werden. Die Schnittstelle von Transformator-Plug-ins wurde bewusst sehr allge-mein gehalten, womit erreicht wird, dass Transformator-Plug-ins für ganz verschiedeneZwecke eingesetzt werden können. Sie können verwendet werden, um fehlenden Informa-tionen, wie Eigenschaften oder Kommentare, zu bestimmten Datenbankobjekten hinzuzufü-gen. Dies kann nützlich sein, wenn gewisse Information in der Datenbank nicht vorhandensind oder wenn bestimmte Aspekte besonderes dokumentiert werden sollen. Ebenfalls er-möglichen Transformator-Plug-in die im RootInfo-Objekt vorhandenen Datenbankob-jekt zu filtern, um unerwünschte Objekte aus der Dokumentation auszuschliessen. Dies kannnötig sein, wenn man datenbanksystemspezifische Objekte nicht dokumentieren möchteoder wenn man Dokumentationen für bestimmte Benutzergruppen erstellt und den Detailge-halt der Dokumentation anpassen möchte.

Der angedachte Hauptverwendungszweck für Transformator-Plug-ins ist aber die Unterstüt-zung von Datenbankentwurfsmustern. Weil Datenbankentwurfsmuster sehr unterschiedlichsein können und auch die Art und Weise der Dokumentation von Entwurfsmuster sehr un-terschiedlich ausfallen könnte, ist es schwierig ein allgemeines Transformator-Plug-in zu er-stellen.

Die Schnittstelle eines Transformator-Plug-ins besitzt gegenüber einem abstrakten Plug-inebenfalls nur eine zusätzliche Methode. Es ist die Methode transform(rootinfo : RootInfo).

34

5 Design

5.2.5 Plug-in ManagerDer Plug-in Manager ist jener Teil der Anwendung, welcher die Verwaltung der Plug-insübernimmt. Er ist verantwortlich für die Initialisierung, Konfiguration und Ausführung derPlug-ins. Wobei er selber auf Konfigurationsangaben zurückgreift, um allen Plug-ins ihreOptionen zu übergeben und sie in der richtigen Reihenfolge auszuführen.

5.3 Kommentare und AnnotationenBeim Design der Komponenten für die Unterstützung von benutzerdefinierten Kommenta-ren für Datenbankobjekte und Annotationen mussten einerseits die Anforderungen aus Ka-pitel 4.1.4 erfüllt werden und andererseits mussten weitere Ideen entwickelt werden, wie be-nutzerdefinierte Kommentare und Annotationen angemessen unterstützt werden können. Ingewissen Bereichen diente auch Javadoc als Inspiration für neue Ideen und mögliche Lösun-gen.

5.3.1 SpeicherungEine Entscheidung bezüglich benutzerdefinierten Kommentaren für Datenbankobjekte war,wie und wo solche Kommentare gespeichert werden sollten, damit sie von der Anwendungausgelesen werden können. Für die Spezifikation und Speicherung sowie den Zugriff aufKommentare sind mehrere Möglichkeiten denkbar. Eine unbefriedigende Lösung wäre,wenn Kommentare von Benutzer nur über die Anwendung selber spezifiziert werden könn-ten und die Anwendung für die Speicherung verantwortlich wäre. Bei einer solchen Lösungwürden die Kommentare aber ausserhalb der Datenbank und damit völlig unabhängig vonden eigentlichen Datenbankobjekten gespeichert. Was dazu führen kann, dass Kommentarenicht mehr mit dem Zustand der Datenbank übereinstimmen, falls sich Änderungen in derDatenbank ergeben. Ausserdem ist eine solche Lösung höchst proprietär, denn nur diese An-wendung kann auf die Kommentare zugreifen und sie ändern. Eine andere Möglichkeit zurSpeicherung von Kommentaren wäre die Unterbringung als SQL-Kommentar in SQL Skrip-ten. Dies ist aber nur möglich für Datenbankobjekt, die durch ein SQL Skript definiert wer-den und wenn diese SQL Skripts auch vom Datenbanksystem gespeichert werden. Für alleanderen Datenbankobjekte wäre es nicht möglich Kommentare zu spezifizieren und zu spei-chern. Aber immerhin wäre ein Kommentar zusammen mit dem zugehörigen Datenbankob-jekt in der Datenbank gespeichert. Und durch Zugriff auf die Datenbank können die Kom-mentare auch von beliebigen Anwendungen ausgelesen werden. Eine weitere Möglichkeitwäre die Nutzung einer vom Datenbanksystem angebotener proprietären Funktion zur Do-

35

5.3 Kommentare und Annotationen

kumentation. Denn einige Datenbanksysteme bieten eigene Funktionen, um Datenbankob-jekte zu kommentieren. So bieten zum Beispiel MS SQL Server Datenbanksysteme eineMöglichkeit namens „Extended Properties“ um Kommentare oder andere Eigenschaften fürDatenbankobjekte zu spezifizieren. Die Nutzung einer solchen Funktionalität würde aberden Einsatzbereich der Anwendung extrem einschränken, da nur spezielle Datenbanksystemunterstützt werden könnten. Eine letzte Möglichkeit ist der im SQL Standard definiertenMechanismus zur Spezifikation von Kommentaren. Mit Hilfe des SQL Befehls „COM-MENT ON“ können Kommentare für Datenbankobjekte spezifiziert werden.

Da dieser Mechanismus die Anforderungen am besten abdeckt, wurde entschieden dieseMöglichkeit in der Anwendung zu verwenden. Denn diese Möglichkeit bietet mehrere Vor-teile. Erstens ermöglicht sie Kommentare direkt zusammen mit dem eigentlichen Datenban-kobjekt in der Datenbank zu speichern. Zweitens ist es ein offizieller Standard, welche vonvielen Datenbanksystemen unterstützt wird. Drittens ist es über diesem Mechanismus in ei-ner einfachen und standardisiertem Art und Weise möglich Kommentare zu spezifizierenund wieder auszulesen.

5.3.2 AnnotationenUm Annotationen in benutzerdefinierten Kommentaren, wie im Kapitel 4.1.4 gefordert, zuunterstützen, mussten mehrere Probleme gelöst werden. Einerseits mussten Komponentenfür die Verarbeitung und die Repräsentation von Annotationen entworfen werden und ande-rerseits musste eine Syntax entworfen werden, mit der Annotationen in Kommentaren spezi-fiziert werden können. Inspiriert von Javadoc wurde entschieden für Annotationen so ge-nannte Tags zu verwenden. Sowie die Syntax für Tags ähnlich wie diese von Javadoc zu de-finieren.

Aus der Analyse der Anforderungen wird klar, dass es verschiedene Tags für verschiedeneZwecke geben muss. So ist erkennbar, dass es grundsätzlich zwei Gruppen von Tags gibt.Einerseits Tags um spezielle Informationen im Kommentar auszuzeichnen beziehungsweiseanzufügen und andererseits Tags für die Formatierung des Kommentars. Tags zur Formatie-rung werden nur für eine bessere optische Darstellung der Kommentare verwendet undbeinhalten keine eigentlichen Informationen über das Datenbankobjekt. Was sie weniger in-teressant, aber trotzdem nützlich macht. In den nachfolgend Ausführungen werden diesebeiden Gruppen von Tags getrennt behandelt. Denn neben dem unterschiedlichen Zweck,verwenden sie auch eine unterschiedliche Syntax und werden durch andere Schnittstellenbeschrieben.

36

5 Design

5.3.2.1 Tags mit InformationenGestützt auf die Anforderungen und weiteren Überlegungen wurden bei den Tags, die Infor-mationen, enthalten verschiedene Typen von Tags identifiziert. Diese Typen werden in derunten stehenden Liste aufgeführt und näher beschrieben. Um das Design von Tags allge-meingültig und flexibel zu halten, wurden nur Typen von Tags definiert und keine konkretenAusprägungen. Um konkrete Tags zu spezifizieren, wurde ein zusätzlicher Mechanismusentwickelt, welcher in Kapitel 6.2.1 näher erläutert wird. Kurz gesagt ermöglicht dieser Me-chanismus über eine Konfigurationsdatei konkrete Ausprägungen von Tags zu definieren.Durch diese Konfigurationsdatei beziehungsweise der Definition von Tags, wird die An-wendungen dann in der Lage versetzt diese Tags im Kommentar zu erkennen und zu verar-beiten. Der grosse Vorteil dieser Lösung ist, dass es für den Benutzer sehr einfach ist neueTags hinzuzufügen oder bestehende zu ändern. Und sie erfüllt damit die Anforderung, dassBenutzer eigene Tags definieren können.

Die allgemeine Syntax für die Spezifikation von Tags in Kommentaren ist sehr einfach ge-halten und im Gegensatz zu Javadoc gibt es auch keine Einschränkungen an welchen Stellenim Kommentar Tags erlaubt sind. Sie können grundsätzlich an jeder beliebigen Stelle ste-hen. Ein Tag wird immer mit der Zeichenfolge „{@“ eingeleitet, darauf folgt direkt ansch-liessend der Name des Tags und dann je nach Tag-Typ die Parameter, Referenzen oder wei-terer Text. Abgeschlossen wird der Tag mit dem Zeichen „}“. Das bedeutet die Zeichen „{“und „}“ haben eine spezielle Bedeutung, weil sie zur Einleitung und zum Abschluss einesTags dienen. Möchte man aber, dass diese Zeichen nicht als spezielle Tag-Begrenzungszei-chen interpretiert werden, weil man sie anderweitig im Kommentar verwenden möchte,kann diesen Zeichen ein „\“ (Backslash) vorangestellte werden um ihnen ihre spezielle Be-deutung zu nehmen und sie im Kommentar zu belassen.

Die verschiedenen Typen von Tags:

● Einfacher-Tag: {@[Tagname]}

Einfache-Tags bestehen nur aus ihrem Name und enthalten keine weiteren Informa-tionen. Solche Tags können eingesetzt werden, um ganz einfache Informationen überdas Datenbankobjekt im Kommentar zu hinterlegen. Ein häufiger Verwendungs-zweck dieser Tags dürfte dabei die Markierung von Datenbankobjekten sein, um sievon der Anwendung speziell behandeln zu lassen. Zum Beispiel kann ein Tag, wie{@omit} dem Kommentar eines Datenbankobjekts hinzugefügt werden, um der An-wendung zu signalisieren, dass dieses Datenbankobjekt in der Dokumentation ausge-lassen werden soll.

37


● Parameter-Tag: {@[Tagname] [Parameter]*}

Parameter-Tags bestehen neben ihrem Name noch aus beliebigen und beliebig vielenParametern. Mit diesen Tags können ausführlichere Informationen zu Datenbankob-jekten hinzugefügt werden. Und so sind sie geeignet um Eigenschaften von Daten-bankobjekten zu beschreiben, die unterschiedliche Werte annehmen können. Bei-spielsweise können über Tags wie {@since 1.0} oder {@author ''Sascha Nedkoff''}zusätzlich Information zu Datenbankobjekten hinzugefügt werden, die ansonstennicht verfügbar wären, da sie im Datenbankschema nicht vorhanden sind.

● Referenz-Tag: {@[Tagname] [Referenz] [Beschriftung]}

Referenz-Tags bestehen aus den drei Teilen, Namen, Referenz und Beschriftung.Durch diese Tags wird es möglich, Referenzen auf andere Datenbankobjekte oderandere Ressourcen zu setzen. Somit kann auf andere Objekte verwiesen werden, undfalls es das Ausgabeformate der Dokumentation erlaubt, kann dadurch eine Naviga-tion zwischen Objekten realisiert werden. Mit der Beschriftung kann ein alternativerText angegeben werden, der in der Dokumentation anstelle der eigentlichen Refe-renz angezeigt wird. Es sind grundsätzlich verschiedene Arten von Referenzen mög-lich und die Form, wie eine Referenz angegeben werden muss, damit sie richtig in-terpretiert werden kann, hängt von der Art der Referenz ab. Es gibt drei Arten vonReferenzen:

○ Datenbankobjekt-Referenzen

Solche Referenzen werden ähnlich, wie im Abschnitt 5.1.3 erklärt, in der Form:[Datenbankobjekt-Typ]:[Datenbankobjekt-Name] angegeben. So lange der Nameeindeutig ist, kann die Angabe des Typs weggelassen werden. Ebenfalls kann derNamen des Datenbankobjekts in der einfachen oder der qualifizierten Form an-gegeben werden. Ein Beispiel wäre {@link TABLE:public.person ''Relation mitPersonendaten''}.

○ Bezeichner für Ressourcen

Werden auf englisch auch Uniform Resource Identifiers (URI) genannt. Durchsolche Referenzen ist es sehr allgemein möglich auf andere Ressourcen zu ver-weisen. Sie werden durch eines der Präfix „URI:“, „INTERN_URI:“ oder „EX-

38

5 Design

TERN_URI:“ eingeleitet und danach folgt eine gültige URI, wie es im Standard15

definiert wurde. Dieser erlaubt unter anderem lokale oder externe sowie relativeoder absolute Verweise und anderes mehr.

Der einzige Unterschied zwischen einer internen und einer extern URI ist, dassin der Dokumentation unterschieden werden kann, wie eine solche Referenz zuhandhaben ist. Besonders in einer HTML-Dokumentation kann dadurch festge-legt werden, ob die Referenz in einem neuen Fenster geöffnet werden soll odernicht. Beispiele für solche Tags wären: {@link URI:file:///home/user/doc.htmlDokumentation} oder {@link EXTERN_URI:http://www.ifi.uzh.ch ''UniversitätZürich''} oder {@link URI:mailto:[email protected]}.

○ Andere Referenzen

Solche Referenzen werden durch die Angabe von „OTHER:“ eingeleitet undkönnen verwendet werden, wenn keine Verarbeitung der Referenz gewünscht ist,weil zum Beispiel andere Komponenten diese Aufgabe übernehmen sollten.

● Text-Tag: {@[Tagname] [freier Text mit Tags]}

Text-Tags bestehen aus ihrem Namen gefolgt von beliebig viel Text, welcher seiner-seits auch gewisse Tags enthalten kann. Solche Text-Tags sind geeignet, wenn ein-zelne Teile eines Kommentars nur für einzelne Benutzer oder Gruppen angezeigtwerden sollen. Zum Beispiel können so Kommentare spezifiziert werden, die nur fürAdministratoren oder Entwickler interessant sind. Durch diese Tags wird es möglichin der Dokumentation solche verschiedenen Teile abzugrenzen oder Dokumentatio-nen nur für bestimmte Nutzer zu erstellen. Beispielsweise {@admin Dieser Kom-mentar ist nur für Datenbank-Administratoren... }

● EER-Tag: {@[Tagname] [EER-Typ]}

EER-Tags bestehen aus ihrem Namen gefolgt von einem Namen für ein Element ausdem erweiterten Gegenstands-Beziehungs-Modell. Durch diese Tags ist es möglichfür Datenbankobjekte das korrespondierende Element aus dem Gegenstands-Bezie-hungs-Modell zu definieren. Diese Information können beispielsweise zur Generie-rung von ER-Diagrammen herangezogen werden.

Nachdem die verschiedenen Typen von Tags identifiziert und definiert waren, musste für je-den Tag-Typ eine Schnittstelle entwickelt werden, welche diesen Tag-Typ repräsentiert so-wie dessen Eigenschaften beschreibt. Das Ergebnis dieses Entwicklungsschritts ist in Abbil-

15 Uniform Resource Identifiers (URI): Generic Syntax [http://www.ietf.org/rfc/rfc2396.txt]

39


dung Abbildung 3 zu sehen.

Zunächst einmal gibt es Eigenschaften, die allen Tags gemeinsam sind. Dazu gehören derName des Tags, die Position des Tags innerhalb des Kommentars und das Datenbankobjektin dessen Kommentar der Tag vorkommt. Um diese allgemeinen Information zu beschrei-ben, wurde zuerst eine generische Schnittstelle namens TagInfo zur Repräsentation einesTags erstellt. Ausgehend von dieser Schnittstelle wurden dann für alle speziellen Tag-Typeneigene Schnittstellen entwickelt, welche die TagInfo Schnittstelle erweitern. Wobei derParameter-Tag durch die Schnittstelle ParamTagInfo, der Referenz-Tag durch dieSchnittstelle RefTagInfo, der Text-Tag durch die Schnittstelle TextTagInfo und derEER-Tag durch die Schnittstelle EERTagInfo repräsentiert werden. Da der Einfache-Tagkeine zusätzlichen Eigenschaften definiert, gibt es für ihn auch keine separate Schnittstelle,sondern er wird durch die allgemeine TagInfo Schnittstelle repräsentiert.

5.3.2.2 Tags zur FormatierungWie zu Beginn des Abschnitts erwähnt, gibt es noch eine zweite Gruppe von Tags und zwar

40

Abbildung 3: Tag-Schnittstellen

5 Design

Tags zur Formatierung von Kommentaren. Diese Tags werden ausschliesslich eingesetzt,um das Aussehen der Kommentare in der Dokumentation zu bestimmen. In der Abbildung 3ist deshalb eine weiter Schnittstelle namens HTMLTagInfo vorhanden, welche diese Grup-pe von Tags repräsentiert. Wie der Name schon andeutet, wurden diese Tags den HTML-Tags nachempfunden und heissen deshalb ebenfalls so.

Die Syntax zur Spezifikation von HTML-Tag ist ebenfalls sehr einfach. HTML-Tags begin-nen immer mit „<“ und enden mit „>“. Dabei gibt es zwei Arten. Öffnende und schliessendeHTML-Tags, wobei die schliessenden HTML-Tag an zweiter Stelle ein „/“ besitzen. Wie ge-sagt, sind diese HTML-Tags den richtigen HTML-Tags sehr ähnlich. Jedoch erlaubt die indieser Anwendung verwendete Sprachdefinition jeglichen Text zwischen „<“ und „>“, umnicht eine komplette HTML-Validierung implementieren zu müssen. Trotzdem sollten nurgültige HTML-Tags verwendet werden, wodurch es zumindest bei der Generierung einerHTML-Dokumentation möglich ist diese Tags direkt zu übernehmen. Für andere Ausgabe-formate, die keine oder nur eingeschränkte Formatierungen ermöglichen, können diese Tagseinfach weggelassen werden. Oder eine Ausgabekomponente kann diese Tags interpretieren,um dann die Formatierung im eigenen Ausgabeformat entsprechend vornehmen. Deshalb istes auch für andere Ausgabeformate wichtig, dass die verwendeten HTML-Tags dem Stan-dard entsprechend korrekt verwendet werden, um so eine Interpretation zu ermöglichen.

Die Zeichen „<“ und „>“ haben ebenfalls wie die Zeichen „{“ und „}“ eine spezielle Bedeu-tung innerhalb des Kommentars, weil sie zur Einleitung und zum Abschluss von HTML-Tags dienen. Deshalb ist es auch bei diesen Zeichen möglich durch das Voranstellen eines„\“ (Backslash) ihnen ihre spezielle Bedeutung zu nehmen, wodurch sie nicht mehr alsHTML-Tag interpretiert und im Kommentar belassen werden.

41

6 Implementierung

6 ImplementierungIn diesem Kapitel wird die Implementierung der Anwendung beschrieben. Dabei wird ge-nauer auf die Implementierungsdetails des Datenmodells, des Applikationsmanagers unddes Parsers für Kommentare eingegangen. Anschliessend wird einzeln für alle Plug-ins, de-ren Funktionalität sowie die grundlegenden Implementierungsentscheidungen beschrieben.

6.1 DatenmodellDieses implementiert das Datenmodell, genauer gesagt implementiert es die im Datenmo-dell definierten Schnittstellen von Datenbankobjekten und Tags. Für die generischenSchnittstellen DBObjectInfo, OwnedDBObjectInfo und RelationInfo wurde je-weils eine abstrakte Klasse implementiert. Die restlichen Schnittstellen, welche konkreteDatenbankobjekttypen repräsentieren, wurden mit konkreten Klassen implementiert. Weiterwurde durch eine Klasse die RootInfo Schnittstelle realisiert.

Implementierung dieser Klassen ist, bis auf die link() Methode, relativ einfach, da es sichum simple Java-Klassen mit Methoden zum setzten und holen von Eigenschaften handelt.Nur die Implementierung der link() Methode benötigte mehr Zeit, weil für jeden Datenban-kobjekttyp unterschiedlich Objekte gelinkt werden müssten und zusätzlich müsste eineMöglichkeit geschaffen werden um im Fall von Fehlern beim Verlinken detaillierte Fehler-meldungen ausgeben zu können.

6.2 Kommentare und TagsUm benutzerdefinierte Kommentare und Tags, wie in dem Kapitel 5.3 beschrieben, zu un-terstützen, wurden zuerst konkreten Klassen für die Implementierung der verschiedenenTag-Schnittstellen erstellt. So existieren eine Klasse TagImpl für die Implementierung derTagInfo Schnittstelle. Und je eine Klasse, die von TagImpl erbt, für die Implementie-rung der Schnittstellen ParamTagInfo, RefTagInfo, TextTagInfo, EERTagInfound HTMLTagInfo.

42

6 Implementierung

6.2.1 Tag-DefinitionenWie erwähnt wurden beim Design von Tags nur Typen von Tags definiert und keine konkre-ten Ausprägungen. Um nun die Definition von konkreten Tags zu ermöglichen, wurde einer-seits ein spezielle XML-Datei mit zugehörigem XML-Schema erstellt und andererseits einspezielle Klasse implementiert, um diese XML-Datei mit den Tag-Definitionen einlesen zukönnen. Sind einmal die Tag-Definitionen bekannt, können diese auch an den im nächstenUnterkapitel beschriebenen Parser übergeben werden, um ihm zu ermögliche diese Tags inKommentaren erkennen und verarbeiten zu können.

Tags werden wie angesprochen in einer XML-Datei definiert. Die Integrität der XML-Dateiwird mittels eines XML-Schemas beim Einlesen sichergestellt, wodurch weniger Aufwandbetrieben werden muss um die Tag-Definitionen auf ihre Richtigkeit zu überprüfen. DieStruktur der XML-Datei ist einfach und so können Benutzer ohne Schwierigkeiten neueTags definierten.

43

Abbildung 4: Tag-Schnittstellen und Tag-Klassen

6.2 Kommentare und Tags

Innerhalb des <tagdefinitions>-Block können beliebig viele <tag>-Blöcke angegeben wer-den. Jeder <tag>-Block entspricht dabei einer Tag-Definition. Eine Tag-Definition bestehtdann aus fünf Elementen, welche die Eigenschaften eines Tags definieren:

● <name>:

Spezifiziert den eindeutigen Name des Tags.

● <type>

Bestimmt den Tag-Typ, wie sie im Design beschrieben sind. Mögliche Werte sind„SimpleTag“, „ParameterTag“, „ReferenceTag“, „TextTag“ oder „EERTag“.

● <numberOfParamerters>

Für Parameter-Tags, wird mit diesem Element die Anzahl der Parameter festgelegt.

● <isInline>

Boolesche Option, die spezifiziert, ob die Position des Tag innerhalb des Kommen-tars von Bedeutung ist oder ignoriert werden kann.

● <nonrecurring>

Boolesche Option, welche bestimmt, ob ein Tag nur einmal oder mehrmals innerhalbdesselben Kommentars vorkommen darf.

44

<tagdefinitions><tag>

<name> </name><type> </type><numberOfParameters> </numberOfParameters><isInline> </isInline><nonrecurring> </nonrecurring>

</tag></tagdefinitions>

6 Implementierung

Von der Anwendung sind schon viele Tags vordefiniert, welche sich allgemein als nützlicherweisen können. Diese vordefinierten Tags sind in der Tabelle 2 aufgeführt.

Name Typ Position vonBedeutung

EinmaligesAuftreten

AnzahlParameter

omit Einfacher-Tag Nein JaomitInOverview Einfacher-Tag Nein Jaauthor Parameter-Tag Nein Ja 1since Parameter-Tag Nein Ja 1see Referenz-Tag Nein Neinlink Referenz-Tag Ja Neinadmin Text-Tag Nein Jadesigner Text-Tag Nein Jaenduser Text-Tag Nein Japrogrammer Text-Tag Nein JaEER ERR-Tag Nein Ja

Tabelle 2: Vordefinierte Tags

6.2.2 ParserFür die Unterstützung von benutzerdefinierten Kommentaren mit benutzerdefinierten Tagswurde ein Parser entwickelt, mit dem Kommentare und die darin enthaltenen Tags verarbei-tet werden können. Um die durch den Parser gewonnenen Informationen über Kommentareund ihre Tags festzuhalten wurde eine eigene Klasse namens Comment erstellt. Diese bietetzahlreiche Methoden, um komfortabel auf den geparsten Kommentar und die erstellten Tag-Objekte zugreifen zu können. Für alle im Kommentar enthaltenen Tags werden vom Parserdie korrespondierenden Tag-Objekte erzeugt und über die Comment Klasse zur Verfügunggestellt.

Damit der Parser, wie gefordert mit benutzerdefinierten Tags umgehen kann, muss der Par-ser flexibel konfiguriert werden können. Dazu wird die angesprochen XML-Datei mit denDefinitionen von Tags verwendet. Anhand dieser Tag-Definitionen weiss der Parser für alleTags, welches Tag-Objekte erstellt und wie sie initialisiert werden müssen. Ebenfalls ist erin der Lage falsch formatierte Tags zu erkennen und detaillierte Fehlermeldungen zu gene-rieren. Unter anderem überprüft der Parser, ob Parameter-Tags über die richtige Anzahl Pa-rameter verfügen oder ob Tags die als einmalig spezifiziert wurden, wirklich nur einmal imKommentar vorkommen. Falls beim parsen falsch formatierte Tags oder andere Fehler auf-treten, werden diese mit Hilfe einer spezielle Ausnahmeklasse namens CommentParser-

45

6.2 Kommentare und Tags

Exception gemeldet. Diese Fehlermeldungen werden dann einerseits über das Log4J Fra-mework ausgegeben und andererseits im RootInfo-Objekt gespeichert. Durch die Spei-cherung im RootInfo-Objekt kann jederzeit auf die aufgetretenen Fehler zugegriffenwerden und sie eventuell auch in der Ausgabe mit einzubeziehen.

6.3 ApplikationsmanagerDer Applikationsmanager ist jener Teil der Anwendung, welcher die grundlegenden Konfi-gurations- und Verwaltungsaufgaben bei der Ausführung der Anwendung übernimmt.

Die wichtigsten Klassen dieser Komponente sind die Klassen ApplicationManager,ConfigurationManager und PluginManager. Der ApplicationManager istfür den Start der Anwendung und für die Steuerung des weiteren Ablaufs verantwortlich.Um seine Aufgabe erfüllen zu können, verwendet er den ConfigurationManager.Dieser versucht aus den Angaben in einer XML-Konfigurationsdatei und den Kommando-zeilen-Argumenten eine gültige Konfiguration für die Anwendung zu erstellen. Falls diesnicht möglich ist, weil die vom Benutzer gemachten Angaben zur Konfiguration inkorrektsind, wird die Ausführung abgebrochen. Um den Implementierungsaufwand für die nötigenÜberprüfungen der Konfigurationsangaben möglichst klein zu halten, wurde entschieden fürdiesen Zweck ein XML-Schema für die Validierung der XML-Konfigurationsdatei zu erstel-len und zu verwenden. Im nächsten Abschnitt wird die Struktur der XML-Konfigurationsda-tei und die durch das XML-Schema definierten Einschränkungen näher beschrieben.

Falls die Konfigurationen der Anwendung erfolgreich war, werden die Konfigurationsanga-ben an den PluginManager weitergegeben. Dieser ist für die Verwaltung und Ausfüh-rung aller konfigurierten Plug-ins zuständig. Dazu muss er sie zuerst initialisieren, dann diePlug-in spezifischen Optionen übergeben und dann die Plug-ins in der richtigen Reihenfolgeausführen. Ebenfalls ist er während dieser Vorgänge dafür verantwortlich im Fall von Feh-lern, die von den Plug-ins ausgelösten Fehlermeldung vom Typ PluginException auf-zufangen und je nach dem wo und wann eine Fehlermeldung auftritt, angemessen darauf zureagieren. Sei es indem die Ausführung des Plug-ins oder sogar die ganze Applikation abge-brochen wird.

46

6 Implementierung

6.3.1 XML-KonfigurationsdateiDie XML-Konfigurationsdatei, welche zur Konfiguration der Anwendung verwendet wer-den kann, hat folgenden Aufbau. Innerhalb des <configuration>-Block gibt es zuerst einen<application>-Block. In diesem werden die generellen Optionen, welche für die gesamteAnwendung gelten, spezifiziert. Danach folgt ein <plugins>-Block. In diesem werden dieeinzelnen Plug-in mit ihren Optionen spezifiziert.

47

6.3 Applikationsmanager

48

<configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="configuration.xsd">

<application><logger>logging.properties</logger>

</application>

<plugins>

<MODEL id="std"><name>Standard model</name>

<class>org.sesam.dbdoc.model.impl.StandardModelCreator</class><load_sequence>1</load_sequence><custom key="tagdef">tag_definitions.xml</custom><custom key="abortOnLinkingErrors">false</custom>

</MODEL>

<INPUT id="std"><name>PostgreSQL Catalog Reader</name><class>org.sesam.dbdoc.input.PostgresCatalogReader</class><load_sequence>2</load_sequence><custom key="driver">org.postgresql.Driver</custom><custom key="url">jdbc:postgresql:sesam_test</custom><custom key="username">admin</custom><custom key="password">adminpassword</custom><custom key="sqlqueries">sql-

queries_for_postgres.xml</custom><custom key="readtypes">ALL</custom>

</INPUT>

<TRANSFORM id="sql"><name>SQL Reconstructor Transformer</name><class>org.sesam.dbdoc.transform.SQLReconstructor</class><load_sequence>3</load_sequence>

</TRANSFORM>

<OUTPUT id="html"><name>HTML Generator</name><class>org.sesam.dbdoc.output.html.HTMLDocgen</class><load_sequence>4</load_sequence><custom

key="outputFolderLocation">gen_output/html</custom><custom key="outputFolderName">DBDoc_for_{DBNAME}</custom><custom key="overwrite">true</custom><custom key="includeErrorReport">true</custom><custom key="showOmitObjectsInHTMLTables">true</custom><custom key="useImagesForLinks">true</custom><custom key="useframes">true</custom>

</OUTPUT>

</plugins></configuration>

6 Implementierung

6.3.2 Kommandozeilen ArgumenteNeben der Möglichkeit die Anwendung mit Hilfe der XML-Konfigurationsdatei zu konfigu-rieren gibt es zusätzlich die Möglichkeit die Anwendung über Kommandozeilen-Argumentezu konfigurieren. Auf der Kommandozeile bestehen genau dieselben Möglichkeiten zurKonfiguration, wie mit einer XML-Datei. Nur das Format für die Spezifikation von Optio-nen ist unterschiedlich.

Zusätzlich ist es auch möglich diese beiden Varianten flexibel miteinander zu kombinieren.So können einzelne Optionen in der Konfigurationsdatei und andere auf der Kommandozei-le spezifiziert werden. Wichtig zu beachten ist, dass Optionen, die auf der Kommandozeilespezifiziert werden, eine höher Priorität als Optionen in der Konfigurationsdatei haben unddiese deshalb überschreiben. So ist es denkbar eine Grundkonfiguration der Anwendung inder Konfigurationsdatei zu spezifizieren und dann auf der Kommandozeile, an die Situationangepasst, noch gewisse Optionen zu überschreiben.

6.3.3 ProtokollierungIn der gesamten Applikation wird die Protokollierung mit Hilfe des Log4J Logging Frame-works implementiert. Durch dieses Framework ist es möglich Status- und Fehlermeldungenkomfortabel zu formatieren und auszugeben. Das Log4J Framework wurde gegenüber ande-ren Lösungen bevorzugt, weil es einfach in der Anwendung ist und vielseitig konfiguriertwerden kann. Durch die Konfigurationsmöglichkeiten kann die Protokollierung an verschie-dene Einsatzszenarien angepasst werden. So können bei einer direkten Ausführung durchden Benutzer die Meldungen auf der Konsole ausgegeben werden und bei einer automati-schen Ausführung im Batch-Verfahren können die Meldungen in einer Datei gespeichertwerden.

6.4 Plug-insBevor konkrete Plug-ins implementiert wurden, wurden zuerst abstrakte Klassen erstellt, umdie allen Plug-ins und die allen Typen von Plug-ins gemeinsame Funktionalität zu realisie-ren. Diese Struktur ist in der Abbildung 5 zu sehen.

49

6.4 Plug-ins

6.4.1 Standard-Model-Plug-inAls Model-Plug-in wurde nur ein Plug-in entwickelt und zwar das Standard-Model-Plug-in.Weil es zwar denkbar aber nicht nötig ist verschiedene Implementierungen des Datenmo-dells zu haben. Deshalb verwendet das Standard-Model-Plug-in die Standardimplementie-rung des Datenmodells.

Die eigentliche Verantwortlichkeit des Model-Plug-ins besteht darin ein RootInfo-Objek-te bereitzustellen sowie in einem späteren Zeitpunkt alle im RootInfo-Objekt vorhande-nen Datenbankobjekt zu verlinken. Um diese Aufgaben erfüllen zu können, verwendet esaber einfach die in der Implementierung des Datenmodells vorhandenen Funktionalitäten.Des weiteren ist das Model-Plug-in für die Konfiguration des Parsers verantwortlich. Umdiesen konfigurieren zu können, benötigt das Model-Plug-in Zugriff auf die XML-Datei, inwelcher die erlaubten Tags definiert sind.

50

Abbildung 5: Plug-in Implementierungen

6 Implementierung

Optionen des Standard-Model-Plug-ins:

name Name des Plug-in.

tagdef XML-Datei mit den Definitionen von Tags.

abortOnLinkingErrors Boolesche Option mit der bestimmt werden kann, ob imFall von Verlinkungs-Fehlern die Ausführung abgebrochenwerden soll.

Tabelle 3: Optionen des Standard-Model-Plug-ins

6.4.2 PostgreSQL-Input-Plug-inAls Input-Plug-in wurde das PostgreSQL-Input-Plug-in entwickelt, welches die Anbindungvon PostgreSQL Datenbanksystemen ermöglicht. Dazu wurden zwei Klassen implementiert.Zum einen die Klasse PostgresCatalogReader, welche durch Vererbung von Ab-stractDBReader und eigenen Erweiterungen die InputPlugin Schnittstelle imple-mentiert. Zu den Aufgaben von PostgresCatalogReader zählt erstens, das Laden desspezifizierten JDBC Datenbanktreibers. Zweitens der Auf- und Abbau einer Verbindung zuder spezifizierten Datenbank. Und drittens das Auslesen aller benötigten Informationen ausder Datenbank. Für diese dritte Aufgabe wurde eine eigene Klasse namens ReaderHel-per erstellt, die den PostgresCatalogReader hierbei unterstützt. Sie übernimmt dieeigentliche Verarbeitung der ausgelesenen Informationen über Datenbankobjekte und er-zeugt über die DBObjectInfoFactory die korrespondierenden DBObjectInfo-Ob-jekte.

Um Informationen über Datenbankobjekte aus einer PostgreSQL Datenbank auszulesen,gibt es neben den vom JBDC Treiber angebotenen Methoden, welche als ungenügend ange-sehen werden, noch zwei weitere Möglichkeiten. Erstens die Verwendung des im SQL Stan-dard definierten und von PostgreSQL implementierten „Information-Schema“ oder zweitensdie Verwendung des PostgreSQL eigenen Datenkatalogs namens „pg_catalog“. Weil imPostgreSQL eigenen Datenkatalog mehr Informationen vorhanden sind oder anders gesagt,weil im „Information-Schema“ keine Informationen über PostgreSQL spezifische Featuresvorhanden sind und ohnehin für einige Informationen auf das PostgreSQL eigenen Datenka-talog zugegriffen werden muss, wurde entschieden zum Auslesen der Informationen aussch-liesslich den PostgreSQL eigenen Datenkatalog zu verwenden. Um so eine bessere und de-tailliertere Dokumentation erstellen zu können. Da dieses Plug-in ja gerade für PostgreSQLDatenbanksystem ausgelegt ist, bedeutet dies auch keine wirkliche Einschränkung.

Das einzige Problem bei der Verwendung des PostgreSQL eigenen Datenkatalogs ist, dass

51

6.4 Plug-ins

dieser im Gegensatz zum „Information-Schema“ Veränderungen unterworfen sein könnte.Wie es in Kapitel 32 von [PostgreSQL07] beschrieben wird. Dies bedeutet, dass sich derDatenkatalog in zukünftigen Versionen des PostgreSQL Datenbanksystems verändern könn-te, wenn auch nur in Details. Um aber gegenüber solchen Änderungen im PostgreSQL Da-tenkatalog gewappnet zu sein, wurden die SQL-Statements zur Abfrage der einzelnen Infor-mationen in eine separate XML-Property-Datei ausgelagert. So müssten bei allfälligen Än-derungen nur diese SQL-Statements angepasst werden, was bedeutend einfacher ist undauch keine neue Kompilierung der Anwendung erfordert.

Obwohl das PostgreSQL-Input-Plug-in speziell für PostgreSQL Datenbanken gedacht ist, istes durch seine allgemein gehaltene Implementierung theoretisch sogar denkbar es ohne vielAufwand auch für andere Datenbanksysteme zu verwenden. Dazu müssten eigentlich nurdie SQL-Statements in der XML-Property-Datei angepasst werden. Denn die XML-Proper-ty-Datei in Kombination mit dem ReaderHelper bietet theoretisch die Möglichkeit auchandere Datenbanksysteme zu unterstützen. Ebenfalls wären kleine Änderungen im Post-gresCatalogReader nötig, aber der grösste Teil der besprochenen Funktionalität desPostgresCatalogReader könnte wiederverwendet werden.

Optionen des PostgreSQL-Input-Plug-ins:

name Name des Plug-in.

driver JDBC Treiber für das Datenbanksystem.

url JDBC URL der Datenbank.

username Name des Datenbankbenutzers.

password Passwort des Datenbankbenutzers.

commentTable Relation mit zusätzlichen benutzerdefinierten Kommentaren.

sqlqueries XML-Property-Datei mit den SQL Anfragen.

readtypes Komma separierte Liste mit Namen von Datenbankobjekttypenüber welche Information eingelesen werden sollen. Oder „ALL“für alle Datenbankobjekttypen.

Tabelle 4: Optionen des PostgreSQL-Input-Plug-ins

Über die Option -readtypes kann der Benutzer angeben, über welche Datenbankobjekt-typen Information eingelesen werden sollen. Diese erlaubt schon früh im Dokumentations-

52

6 Implementierung

prozess zu definieren, welche Information benötigt werden. Durch Ausschluss von nicht be-nötigten Objekten zu diesem Zeitpunkt kann Rechenzeit eingespart werden, da es kein Sinnmacht Daten von solchen Objekten einzulesen, zu verarbeiten und wieder auszugeben. Dader Ausschluss von allen Datenbankobjekten eines Typs häufig zu rigoros ist, hat der Benut-zer auch die Möglichkeit die SQL Anfragen in der XML-Property-Datei zu ändern. DieseDatei wird dem Plug-in über die Option -sqlqueries übergeben. In dieser Datei sindsehr genaue und flexible Einstellung möglich, welche Objekte der verschiedenen Typen ein-gelesen werden sollen. Natürlich ist es häufig einfacher spezielle Objekte durch Transforma-tor-Plug-ins zu behandeln und auszufiltern, doch falls bestimmte Objekte nie gebraucht wer-den, kann es aus Performance Gründen sinnvoll sein dies schon beim Einlesen zu machen.So ist diese Möglichkeit vor allem für den Ausschluss von Systemobjekten geeignet. Bei-spielsweise werden die im PostgreSQL Datenbanksystem standardmässig vorhandenen Re-lationen und Sichten, welche den Datenkatalog und das „Information-Schema“ ausmachen,nicht eingelesen, da sie für die Dokumentation der eigentlichen Datenbank unwichtig sind.Hingegen werden die standardmässig vorhandenen Funktionen, Datentypen, Domänen undso weiter eingelesen, da sie wichtig für die Dokumentation sein können. Durch die Auslage-rung der SQL Anfragen in eine XML-Property-Datei ist es aber jederzeit sehr einfach mög-lich dieses Standardverhalten zu ändern.

Mit der Option -commentTable kann dem Plug-in der Name einer Relation übergebenwerden, die zusätzliche benutzerdefinierte Kommentare enthält. Die Relation mit benutzer-definierten Kommentaren muss drei Spalten besitzen. Die Spalte „dbobject_type“ muss denTyp des Datenbankobjekts , die Spalte „dbobject_name“ den Namen des Datenbankobjektsund die Spalte „comment“ den Kommentare für das zu kommentierende Datenbankobjektenthalten. Durch diese Option können auch Datenbankobjekttypen, für welche es nicht mög-lich ist einen Kommentar mit SQL „COMMENT ON“ zu spezifizieren, mit Kommentarenversehen und dadurch besser dokumentiert werden. Zum Beispiel ist es in älteren Versionenvon PostgreSQL Datenbanksystemen noch nicht möglich für alle Datenbankobjekttypen mitSQL „COMMENT ON“ einen Kommentar zu spezifizieren. In der Version 8.1 von Post-greSQL wurde die Kommentierung von „Role“ und „Tablespace“ noch nicht unterstützt.

6.4.3 Output-Plug-ins

6.4.3.1 HTML-Output-Plug-inAls wichtigstes Output-Plug-in wurde ein so genanntes HTML-Output-Plug-in entwickelt,welches in der Lage ist eine HTML-Dokumentation der Datenbank zu erstellen.

Dazu wurde als eigentliche Plug-in Klasse, die Klasse HTMLDocgen erstellt, welche durch

53

6.4 Plug-ins

Vererbung von AbstractDocgen und eigenen Erweiterungen die OutputPluginSchnittstelle implementiert. Weiter wurde, wie in Abbildung 6 zu sehen ist, ein abstrakteKlasse HTMLWriter implementiert, die viele Methoden besitzt um allgemeine HTML-Code Fragmente mit Hilfe eines Java PrintWriter in eine Datei zu schreiben. Von dieserKlasse erbt eine weiter abstrakte Klasse DBObjectWriter. Diese erweitert den Funkti-onsumfang um Methoden zum Schreiben von HTML-Code für Datenbankobjekt spezifi-schen Informationen, wie Kommentare, Tags oder andere Eigenschaften. Von diesen zweiabstrakten Klassen erben dann mehrere konkrete Klassen. Jede dieser konkreten Klassen istfür die Generierung eines ganz bestimmten Teils der HTML-Dokumentation zuständig. Beidieser Vererbungshierarchie handelt es sich um eine reine Implementierungsvererbung.

Der IndexWriter erstellte die index.html Datei, die als Einstiegspunkt in die Dokumen-tation dient. Diese Datei enthält den HTML-Code für die Darstellung von zwei Rahmen imBrowser. Ein Rahmen für das Menü und ein Rahmen für die Detailseiten über Datenbankob-jekte. Das eigentlich Menü wird dann von den Klassen MenuWriter und MenuCode-Writer erstellt. Zusätzlich generiert der MainWriter die Haupt- beziehungsweise dieStartseite der Dokumentation. Alle Detailseiten mit den Informationen über Datenbankob-jekt werden von der Klasse AllDBObjectWriter erstellt und alle Übersichtsseiten diebei der Navigation im Menü angezeigt werden, werden durch die Klasse OverviewWri-

54

Abbildung 6: Implementierungsvererbung imHTML-Output-Plug-in

6 Implementierung

ter generiert. Dann gibt es noch den ErrorReportWriter, welcher alle aufgetretenenFehler beim Parsen von Kommentaren und beim Verlinken von Datenbankobjekten in einerseparaten HTML-Seite dokumentiert.

Wie schon kurz erwähnt und in der Abbildung 7 zu erkennen, besteht die Ansicht der gene-rierten HTML-Dokumentation grundsätzlich aus zwei Teilen.

Auf der linken Seite wird ein interaktives Menü zur Navigation bereitgestellt und auf derrechten Seite werden die Informationen über Datenbankobjekte angezeigt. Da es relativ auf-wändig ist ein professionell aussehendes und gut konfigurierbares Menü mit JavaScript zuimplementieren und es schon viele gute und frei verfügbare Lösungen für dieses Problemgibt, wurde für diesen Teil auf eine Lösung von [TreeMenu] zurückgegriffen. Unter vielenzur Verfügung stehender Menüs, wurde dieses ausgewählt, weil es sehr viele Möglichkeitenfür Anpassungen und zur Konfiguration bietet. Beispielsweise kann für jeden Menü-Eintrageinzeln ein Symbol für diesen definiert werden oder auch für eine Gruppe von Einträgen.

55

Abbildung 7: Generierte HTML-Dokumentation

6.4 Plug-ins

Ebenso wichtig ist, dass es auch bei einer sehr grossen Anzahl von Menü-Einträgen nochvernünftig funktioniert und genügend schnell reagiert. Weiter ist das Menü in der Lage sichdie auf- und zusammengeklappten Menü-Einträge zu merken. Eine andere praktische Fähig-keit des Menüs ist die Möglichkeit der Verfolgung der aktuellen Position im Menü. Wennman über Links in der Dokumentation und nicht im Menü zu anderen Detailseiten von Da-tenbankobjekten navigiert, wird im Menü automatisch der aktuelle Menü-Eintrag geöffnetund markiert, so dass man immer direkt sieht, wo man sich in der Dokumentation befindet.

Auf der rechten Seite werden die Informationen über die Datenbankobjekte angezeigt. Fürjedes zu dokumentierende Datenbankobjekt wird eine eigene HTML-Seite generiert. DieseDetailseiten über Datenbankobjekte haben alle einen ähnlichen Aufbau. Sie beginnen mitdem Typ und Namen des Datenbankobjekts als Titel, gefolgt vom benutzerdefinierten Kom-mentar und den Tags. Danach kommt das rekonstruierte SQL-Statement. Da dieses unterUmständen relative lang werden kann, kann es für eine bessere Übersicht auch ausgeblendetwerden. Daran anschliessend folgen in tabellarischer Form alle Eigenschaften des Objekts.Der restliche Teil der Detailseiten ist unterschiedlich und hängt vom Typ des Datenbankob-jekts ab. Bei Relationen beispielsweise folgt nach den Eigenschaften der Relation eine Ta-belle mit den in der Relation vorhandenen Spalten und deren wichtigsten Eigenschaften. Diein dieser Tabelle aufgeführten Einschränkungen von Spalten, werden um die Darstellungkompakt zu halten, nur als Symbole dargestellt. Jedoch besitzen alle einen so genannten„Mouse over“-Tooltip, welcher genauere Information über die Einschränkung enthält. Ab-schliessend folgen falls vorhanden noch Tabellen mit den auf der Relation definierten Ein-schränkungen, Triggern und Indexen sowie Tabellen mit den vererbten Relationen.

Zur attraktiven Gestaltung der HTML-Dokumentation und zur optischen Orientierung wur-de für jeden Typ von Datenbankobjekt eine eigene Farbe und zwei Symbole definiert. Fürjeden Datenbankobjekttyp gibt es ein Symbol zur Repräsentation eines Objekts und einzweites Symbol zur Repräsentation mehrerer Objekte dieses Typs. Die momentan verwen-deten Symbole stammen ursprünglich aus der Applikation pgAdmin III16 einem Administra-tion und Management Tool für PostgreSQL Datenbanksysteme. Die verwendeten Symbolekönnen aber jederzeit leicht ausgetauscht werden, da sie zusammen mit den Farben in einereigenen XML-Property-Datei spezifiziert wurden.

Da das HTML-Output-Plug-in einerseits sehr umfangreich ist und andererseits eine komfor-table Konfiguration möglich sein soll, bietet es mehrere Optionen, die nachstehend erläutertwerden.

Optionen des HTML-Output-Plug-ins:

16 http://www.pgadmin.org

56

6 Implementierung

outputFolderLocation Pfad eines Ordners, in welchem der Ordner mit der gene-rierten HTML-Dokumentation gespeichert werden soll.

outputFolderName Name für den Ordner in welchem die Dokumentation ge-speichert werden soll. Im Namen können drei verschiedeneVariablen verwendet werden, welche später durch ihren ak-tuellen Wert ersetzt werden. {DBNAME} wird ersetzt mitdem Namen der dokumentierten Datenbank. {DATE} wirddurch das aktuelle Datum und {TIME} durch die aktuelleUhrzeit ersetzt.

overwrite Boolesche Option, welche bestimmt, ob eine unter demsel-ben Pfad und Namen allenfalls schon vorhandene Doku-mentation überschrieben werden darf.

includeErrorReport Boolesche Option, die festlegt ob der Dokumentation einFehlerbericht hinzugefügt werden soll.

useImagesForLinks Boolesche Option mit der bestimmt werden kann, ob beiLinks neben dem eigentlichen Link-Text auch ein kleinesSymbol verwendet werden soll.

additionalTextforMainPage

Variabler Text, welcher auf der Titelseite der Dokumentati-on erscheinen soll.

additionalTextforMainPageFromFile

Der Name einer Datei dessen Inhalt auf der Titelseite derDokumentation erscheinen soll.

additionalMenuEntries Fügt eigene Einträge ins Hauptmenü der Dokumentationein, um zum Beispiel wichtige andere Dokumente zu verlin-ken. Hierfür wird eine spezielle Syntax verwendet und zwarmuss für jeden Eintrag angegeben werden:MENUENTRY([Name], [Link], [Bild]);

folderToCopyToOutput Beliebiger Ordner, welcher samt Inhalt in den generiertenAusgabeordner kopiert werden soll.

showOmitObjectsInHTMLTables

Boolesche Option, die festgelegt, ob Datenbankobjekte, dieeinen @omit-Tag besitzen in der Dokumentation ganz aus-gelassen werden oder noch in den Übersichtstabellen auf-tauchen sollen.

57

6.4 Plug-ins

Tabelle 5: Optionen des HTML-Output-Plug-ins

6.4.3.2 Konsolen-Output-Plug-inDas Konsolen-Output-Plug-in ist ein extrem einfaches Plug-in. Seine einzige Fähigkeit istes die Namen, Kommentare und Tags von Datenbankobjekten auf der Konsole auszugeben.Wobei über eine boolesche Option namens -verbose eingestellt werden kann, ob nur dieNamen oder auch die Kommentare und Tags ausgegeben werden sollen.

Dieses Output-Plug-in ist viel zu primitiv, als das es für die Erstellung einer Datenbankdo-kumentation verwendet werden könnte, vielmehr ist es nur zum Testen und Debuggen derAnwendung gedacht.

6.4.4 Transformator-Plug-insBei den Transformator-Plug-ins wurden insgesamt vier verschiedene Transformatoren im-plementiert. Allen ist gemeinsam, dass sie die vorhandenen Informationen über Datenban-kobjekte im Datenmodell analysieren und darauf aufbauend Informationen ändern oder hin-zufügen. Mit den verschiedenen implementieren Transformatoren wurde versucht die Mäch-tigkeit und die Möglichkeiten des Transformator Konzepts zu demonstrieren. Einer dieserTransformatoren wurde sehr allgemein gehalten und kann deshalb für unterschiedlichsteZwecke eingesetzt werden. Die anderen drei Transformatoren wurden dagegen für spezielleEinsatzzwecke entwickelt und erlauben verschiedene Teilaspekte der Dokumentation zuverbessern.

In den nachfolgenden Unterkapiteln werden die einzelnen Transformator-Plug-ins detaillier-ter beschrieben. Grundsätzlich erben alle entwickelten Transformator-Plug-ins von der ab-strakten Klasse AbstractTransformer, welche die TransformPlugin Schnittstelleimplementiert.

6.4.4.1 Kommentar-TransformatorDas Kommentare-Transformator-Plug-in ist ein sehr allgemein gehaltenes Plug-in, dasdurch die Klasse CommentTransformer implementiert wird. Wie der Name schon sagt,besteht die Hauptaufgabe dieses Plug-ins darin, die benutzerdefinierten Kommentare dervorhandenen Datenbankobjekte zu verändern. Vorhandene Kommentare können gelöscht,neue Kommentare spezifiziert oder Kommentare können an schon vorhandenen angehängtwerden. Da Kommentare auch Tags enthalten können, ist es natürlich auch möglich Tagseinzufügen, zu löschen oder anzuhängen. Zusätzlich können mit diesem Plug-in auch nochallgemeine Eigenschaften zu Datenbankobjekten hinzugefügt werden.

58

6 Implementierung

Damit dieses Plug-in allgemein einsetzbar ist und an viele Situationen angepasst werdenkann, musste eine Möglichkeit geschaffen werden um es flexibel konfigurieren zu können.Wie andere Plug-ins auch, kann es über angebotene Optionen konfiguriert werden. Da abereinfache Optionen allein nicht flexibel genug sind, wurde zusätzlich eine eigene kleineSprache zur Konfiguration des Plug-ins entwickelt. Das Plug-in verfügt über genau eine ei-gene Option namens -statement, welcher in dieser Sprache formulierte Ausdrückeübergeben werden können.

Sprachdefinition für Kommentar-Transformations-Statements

Die Sprache für Kommentar-Transformations-Statements wurde an die Sprache SQL ange-lehnt und ist deshalb ebenfalls eine deklarative Sprache. Es wurde eine zu SQL ähnliche,aber einfachere Syntax definiert und es wurden einige wenige Schlüsselwörter aus SQLübernommen.

Syntax für Kommentar-Transformations-Statements:

{Kommentar}: Beliebiger Text mit Tags, der als Kommentar für Datenbankobjekte ver-wendet werden soll. Falls DELETE COMMENT spezifiziert wurde, hat der Kommentarkeine Bedeutung. Innerhalb von Kommentaren können zusätzlich noch spezielle Schlüssel-wörter verwendet werden, diese werden dann während der Verarbeitung des Statementsdurch ihre tatsächlichen Werte ersetzt. Diese Wörter sind „[DBOBJECT_NAME]“, „[DB-OBJECT_QNAME]“ und „[DBOBJECT_TYPE]“. Zusätzlich existiert noch eine Funktionum Text-Ersetzungen während der Verarbeitung des Statements vorzunehmen. Diese Funkti-on hat die Form: REPLACE_FUNC( [P1], [P2],[P3])

Wobei [P1] der Text ist indem die Ersetzung vorgenommen werden soll. [P2] bezeichnetden zu ersetzenden Text und [P3] bezeichnet den Text, der anstelle von [P2] eingefügtwerden soll.

{Datenbankobjekttypen}: Komma separierte Liste von Namen von Datenbankob-jekttypen, bei denen der Kommentare verändert werden soll. Als Namen können alle in derEnum Klasse DBObjectType definierten Einträge angegeben werden. Zum BeispielSCHEMA, TABLE, COLUMN und so weiter. Diese Namen können gross oder klein sowiein Ein- oder Mehrzahl geschrieben werden. Zusätzlich gibt es auch noch das SchlüsselwortALL, wenn man alle Datenbankobjekttypen spezifizieren möchte.

59

[ADD|REPLACE|DELETE] COMMENT {Kommentar}[FROM|INTO] {Datenbankobjekttypen}[WHERE {Bedingungen}];;;

6.4 Plug-ins

{Bedingung}: Der WHERE Abschnitt ist gänzlich optional. Falls er aber angegebenwird, kann über Bedingungen die Auswahl von Datenbankobjekten, neben den zuvor defi-nierten Typen, weiter beschränkt werden. Mehrere Bedingung können über AND verknüpftwerden, wobei eine einzelne Bedingung die Form hat:

Durch eine Bedingung kann man Datenbankobjekte mit bestimmten Eigenschaften für dieTransformation auswählen oder von ihr ausschliessen. So können Datenbankobjekte anhandvon ihrem Namen, qualifiziertem Namen, Pfad oder vorhandenen Tags gefiltert werden.Wenn man nach Namen oder Pfaden sucht, wird der {Text} als regulärer Ausdruck interpre-tiert. Wenn man hingegen nach Tags sucht wird der {Text} als einfacher Name eines Tagsangesehen.

Wie erwähnt, kann man mit dem Kommentar-Transformator nicht nur Kommentare verän-dern, sondern zusätzlich bietet er auch die Möglichkeit allgemeine Eigenschaften zu Daten-bankobjekten hinzuzufügen. Mit allgemeinen Eigenschaften sind die Eigenschaften in derDBObjectInfo Schnittstelle gemeint, welche mit den MethodenaddProperty(String name, String value) und addPropertyDBObjec-tReference(String name, String dbobjRef) gesetzt werden können.

Syntax für Eigenschaft-Transformation-Statements:

{Property-Name} bezeichnet den Name der Eigenschaft und {Property-Value}bezeichnet den Wert der Eigenschaft. In beiden Teilen sind die selben Ersetzungsmechanis-men wie in {Kommentar} verfügbar. Die restlichen Teile der Syntax sind identisch mitder von Kommentar-Transformation-Statements.

Auf den ersten Blick lässt sich eventuell nicht direkt erkennen, welche Möglichkeiten diesesTransformator-Plug-in einem Benutzer bieten kann. Es erscheint, als ob nur Kommentaregeändert werden könnten. Was richtig und falsch ist. Durch den Umstand, dass Kommentareauch Tags enthalten können und es spezielle Tags, wie @omit oder @omitInOverview gibt,eröffnen sich aber vielseitige Möglichkeiten, um neben dem Inhalt auch auf dem Umfang ei-ner Dokumentation Einfluss zu nehmen.

60

[name|qname|path|tag][=|!=]{Text}

ADD PROPERTY [REFERENCE] {Property-Name} = {Property-Value}[FROM|INTO] {Datenbankobjekttypen}[WHERE {Bedingungen}];;;

6 Implementierung

Zum Beispiel können mit dem CommentTransformer Plug-in die vorhandenen Datenban-kobjekte gefiltert werden, um so beispielsweise Datenbanksysteme spezifische Datenban-kobjekte von der Dokumentation auszuschliessen.

Ebenfalls können mit Hilfe des CommentTransformer Plug-in Datenbankentwurfsmusterunterstützt werden. Als Beispiel hierfür kann das in der sesamDB zum Einsatz kommendeHistorisierungsrelations-Entwurfsmuster unterstützt werden.

Die Kommentar-Transformation-Statements für die Unterstützung des Historisierungsrelati-on-Entwurfsmusters:

Das erste Statement bewirkt, dass bei alle Relationen deren Namen auf „_old“ enden unddie nicht schon einen „omitInOverview“-Tag besitzen ein „omitInOverview“-Tag hinzuge-fügt wird. Das zweite Statement fügt bei allen Relationen, deren Namen auf „_now“ endet,einen zusätzlichen Kommentar ein. Dieser angehängte Kommentar enthält einen Link aufdie korrespondierende Historisierungs-Relation. Dazu ist es notwendig mit Hilfe des Erset-zungsmechanismus den Namen dieser alten Relation zu konstruieren. Das dritte Statementist dem zweiten sehr ähnlich, nur wird der Link auf die korrespondierende alte Relationnicht im Kommentar, sondern als allgemeine Eigenschaft der Relation gesetzt.

Anschliessend sind noch einige andere Beispiele für praktische Kommentar-Transformati-on-Statements aufgelistet:

61

ADD COMMENT {@omitInOverview}INTO tablesWHERE name=.*_old AND tag!=omitInOverview;;;

ADD COMMENT <font color="red">History relation:</font> {@link TABLE:REPLACE_FUNC([DBOBJECT_QNAME], _now, _old) REPLACE_FUNC([DBOBJECT_NAME], _now, _old)}INTO tablesWHERE name=.*_now;;;

ADD PROPERTY REFERENCE History relation = TABLE:REPLACE_FUNC([DBOBJECT_QNAME], _now, _old)INTO tablesWHERE name=.*_now;;;

6.4 Plug-ins

6.4.4.2 SQL-ReconstructorDas SQL-Reconstructor-Plug-in wird durch die Klasse SQLReconstructor implemen-tiert. Es wurde entwickelt, weil nicht bei allen Datenbanksystemen die SQL-Create-State-ments von Datenbankobjekten ausgelesen werden können, da sie nicht direkt vorhandensind. Diese SQL-Create-Statements können aber für Benutzer einer Datenbankdokumentati-on, die mit SQL vertraut sind, sehr hilfreich sein. Glücklicherweise ist es aber möglichdurch die Analyse anderer Informationen über ein Datenbankobjekt dessen SQL-Create-Statement, wie der Name des Plug-ins schon andeutet, zu rekonstruieren.

Zum Beispiel können bei PostgreSQL Datenbanksystemen nur für einige Datenbankobjekt-typen die SQL-Create-Statements direkt aus dem Datenbankschema ausgelesen werden. Fürandere wichtige Datenbankobjekttypen, wie Schemas, Relationen, Spalten, Typumwandlun-gen und die Datenbank selbst, sind keine SQL-Create-Statements vorhanden. Deshalb be-sitzt dieses Plug-in die Fähigkeit für genau diese Datenbankobjekttypen ihre SQL-Create-Statements zu rekonstruieren.

Dieses Plug-in könnte aber ohne grossen Aufwand erweitert werden, um SQL-Create-State-ments für alle Datenbankobjekttypen zu rekonstruieren. Dann kann es noch allgemeiner ein-gesetzt werden, um je nach Datenbanksystem, die fehlenden SQL-Create-Statements zu re-konstruieren und sie im Datenmodell zu speichern.

6.4.4.3 View-Properties-SetterDas View-Properties-Setter-Plug-in ist ein relativ einfaches Plug-in, welches durch die

62

ADD COMMENT {@omitInOverview}INTO schemaWHERE name=pg_catalog AND tag!=omitInOverview;;;

ADD COMMENT {@omitInOverview}INTO triggersWHERE name=RI_ConstraintTrigger_.* AND tag!=omitInOverview;;;

ADD COMMENT {@author "Sascha Nedkoff"}INTO allWHERE name=.* AND tag!=author;;;

6 Implementierung

Klassse ViewPropertiesSetter implementiert wurde. Der Grund für die Entwicklungist, dass im Datenbankschema von PostgreSQL Datenbanksystemen einige Eigenschaftenvon Sichten nicht direkt verfügbar sind. Das heisst man kann sie nicht einfach auslesen son-dern man muss sie aus anderen ausgelesenen Informationen ableiten. Bei diesen Eigenschaf-ten handelt es sich um die auf einer Sicht erlaubten Aktionen, also um Angaben, ob es aufeiner Sichten möglich ist Tupel einzufügen, zu ändern oder zu löschen. Um aber im Post-greSQL-Input-Plug-in keinen zusätzlichen Aufwand betreiben zu müssen, um diese Infor-mationen zu erhalten, wurde es als wesentlich einfacher angesehen ein kleines Transforma-tor-Plug-in zu implementieren, welches in einem späteren Zeitpunkt diese Information überSichten hinzufügt, indem es diese aus anderen Information ableitet.

Das View-Properties-Setter-Plug-in analysiert die für eine Sicht definierten Regeln und de-ren Event-Typ. Aus dem Vorhandensein einer Regel und ihrem Event-Typ erkennt das Plug-in, dass eine entsprechende Aktion auf der Sicht möglich ist und kann so diese Informationüber die Sicht zu den anderen Information über die Sicht hinzufügen. Wenn also zum Bei-spiel auf einer Sicht eine Regel definiert wurde deren Event-Typ „INSERT“ lautet, bedeutetdies dass Aktionen zum Einfügen von Tupeln in die Sicht erlaubt sind. Ist hingegen keinesolche Regel vorhanden, sind auch keine Einfüge-Aktionen erlaubt. Für detailliertere Infor-mationen zu diesem Thema wird auf die PostgreSQL Dokumentation über „Rewrite Rules“verwiesen [PostgreSQL07].

Um zu zeigen wie einfach dieses Plug-in aufgebaut ist und zur Illustration, wie einfach essein kann ein Transformator-Plug-in zu implementieren, ist in Abbildung 8 der gesamt Java-Code des implementierten View-Properties-Setter Plug-ins abgebildet.

Das Plug-in erbt von der abstrakten Klasse AbstractTransformer. Dadurch kann imVergleich zur direkten Implementierung der TransformatorPlugin Schnittstelle vielArbeit eingespart werden. Denn es entfällt der Aufwand, um die allgemeinen Methoden ei-nes Transformator-Plug-ins zu implementieren, weil auf die generische Implementierungder AbstractTransformer Klasse zurückgegriffen werden kann. Es musste nur dieMethode transform() überschrieben werden, um dem Plug-in die angesprochene Funk-tionalität zu verleihen.

63

6.4 Plug-ins

6.4.4.4 Simulated Constraint AnalyserDas Simulated-Constraint-Analyser-Plug-in ist ein Transformator-Plug-in das speziell fürdie Unterstützung eines in der sesamDB verwendeten Entwurfsmusters und damit für einebessere Dokumentation der sesamDB implementiert wurde.

In der sesamDB werden viele Einschränkungen auf Relationen und Spalten nicht mit nor-malen Einschränkungen, sondern mit Triggerfunktionen realisiert. Und zwar deshalb, weilEinschränkungen nicht über alle Relationen einer Vererbungshierarchien betrachtet werden,sondern nur auf einer Relation wirksam sind. So kann mit Einschränkungen allein zum Bei-

64

package org.sesam.dbdoc.transform;

import org.sesam.dbdoc.*;

public class ViewPropertiesSetter extends AbstractTransformer {

public ViewPropertiesSetter() {super();

}

public RootInfo transform(RootInfo root) throwsPluginException {

RootInfo rootinfo = super.transform(root);

for (ViewInfo view : rootinfo.getAllViews()) {for (RuleInfo rule : view.getRules()) {

switch (rule.getEventType()) {case 'U':

view.setIsUpdatable(true);break;

case 'I':view.setIsInsertable(true);break;

case 'D':view.setIsDeletable(true);break;

default:break;

}}

}return rootinfo;

}}

Abbildung 8: Kompletter Java-Code des ViewPropertiesSetter-Plug-ins

6 Implementierung

spiel nicht sichergestellt werden, dass eine Primärschlüssel über mehrere Relationen in derVererbungshierarchie eindeutige ist. Zusätzlich kann es einfacher sein eine Einschränkungfür alle Relationen gemeinsam mit einer Triggerfunktionen zu realisieren, als für jede Rela-tion einzeln eine Einschränkung zu definieren.

Durch diesen Mechanismus entsteht aber ein Problem für die Dokumentation dieser Relatio-nen. Denn über solche durch Triggerfunktionen realisierte Einschränkungen gibt es im Da-tenbankschema keine direkten Informationen. Deshalb können diese Informationen überEinschränkungen auch nicht ausgelesen werden und folglich auch keine entsprechendenEinschränkungsobjekte im Datenmodell erzeugt werden. Diese Einschränkungsobjekte wä-ren aber wichtig, um den Umstand von vorhandenen Einschränkungen auf einer Relation zudokumentieren. Deshalb wurde dieses Transformator-Plug-in entwickelt, welches durch dieAnalyse von Triggerfunktionen diese Informationen über Einschränkungen rekonstruierenkann und um so die entsprechenden Einschränkungsobjekte im Datenmodell zu erzeugen,wodurch die gewonnenen Informationen repräsentiert und in der Dokumentation verwendetwerden können.

65

7 Tests

7 Tests

7.1 PerformanceDie Ausführungsgeschwindigkeit spielt für diese Anwendung zwar nur eine untergeordneteRolle, trotzdem ist sie nicht völlig vernachlässigbar, da es natürlich wünschenswert ist, dassdie Dokumentation so schnell wie möglich generiert wird und zur Verfügung steht. Haupt-sächlich hängt die Ausführungszeit der Anwendung von der Grösse der zu dokumentieren-den Datenbank ab. Genauer gesagt von der Anzahl zu dokumentierenden Datenbankobjek-ten. Je mehr Datenbankobjekte vorhanden sind, desto mehr Informationen müssen ausgele-sen, verarbeitet und wieder ausgegeben werden.

Als Testumgebung diente ein Desktop Computer mit einem Intel Pentium 4 Prozessor mit1.60GHz und 768 MB Arbeitsspeicher. Als Betriebssystem kam „openSUSE 10.2“ zumEinsatz und ausgeführt wurde die Anwendung in der Eclipse Entwicklungsumgebung mitdem JRE 1.5.

Für die eigentlich Durchführung der Performance-Tests wurde auf einem PostgreSQL Da-tenbanksystem eine Testdatenbank aufgesetzt, deren Umfang durch Hinzufügen von neuenRelationen kontinuierlich vergrössert wurde. Nach jedem Hinzufügen von neuen Relationenwurde die Anwendung erneut ausgeführt und die Zeiten für die Ausführung von einzelnenPlug-ins sowie die Gesamtzeit gemessen.

Die für den Test verwendeten Relationen haben alle dieselbe Struktur wie sie in Abbildung9 zu sehen ist. Sie haben 4 Spalten wovon die ersten zwei „Integer“ und die zweiten zwei„Text“ als Datentyp haben. Die erste Spalte ist als Primärschlüssel und die zweite als ein-deutige („unique“) definiert. Dies bedeutet für jede Relation sind zwei Einschränkungen de-finiert.

66

7 Tests

In PostgreSQL wird automatisch für jede Relation zusätzlich ein Datentyp erzeugt, welcherden Zeilen-Datentyp dieser Relation repräsentiert. Ebenfalls wird in PostgreSQL für jedenPrimärschlüssel und jede Unique-Einschränkung ein Index erzeugt. So werden für jede Re-lation insgesamt 10 Datenbankobjekte erzeugt. Ein Relation-, ein Datentyp-, vier Spalten-,zwei Einschränkungs-, und zwei Index-Objekte.

Die Resultate der Tests für Datenbanken mit unterschiedlicher Grösse:

Aus den Testresultaten von Tabelle 6 sich herauslesen, dass die Zeiten für das Auslesen derInformationen sowie die Generierung der Ausgabe ziemlich linear anwachsen. Aber die Zei-ten für die Verlinkung der Datenbankobjekte überproportional ansteigen. Bei einer Anzahlvon 2000 und 3000 Relationen sind die hohen Zeiten für die Verlinkung hauptsächlich aufdie sehr grosse Anzahl von Objekten des gleichen Typs zurückzuführen. Bei 3000 Relatio-nen existieren 12000 Spalten, 6000 Einschränkungen und 6000 Indexes. Und so benötigeneinige Suchoperationen, wenn sie alle Objekte eines Typs durchsuchen müssen, immer län-

67

CREATE TABLE test_table_1 ( col_1 bigint NOT NULL, col_2 bigint NOT NULL, col_3 text, col_4 text, CONSTRAINT pkey_con PRIMARY KEY (col_1), CONSTRAINT unique_con UNIQUE (col_2) ) WITHOUT OIDS;

Abbildung 9: SQL Create Statement für Test-Relationen

Tabelle 6: Detaillierte Ausführungszeiten für Datenbanken unterschiedlicher Grösse

Anzahl Zeit in Sekunden HTML-AusgabeRelationen Objekte Einlesen Transformation Ausgabe Total Grösse Dateien

0 3026 5,7 0,7 0,02 6,1 13,4 13,9 MB 31281 3036 5,7 0,7 0,03 6,1 13,4 14,0 MB 3143

10 3126 5,7 0,7 0,05 6,5 13,8 14,5 MB 3260100 4026 6,7 1,0 0,30 8,1 17,1 19,6 MB 4430

1000 13026 13,2 11,9 0,60 24,4 51,0 71,7 MB 161302000 23026 20,4 38,2 0,80 42,5 102,9 130,0 MB 291303000 33026 27,6 80,0 1,45 62,8 172,9 188,7 MB 42130

Verlinkung

7.1 Performance

ger je mehr Objekte existieren.

Gesamthaft lässt sich sagen, dass die Ausführungszeiten für kleine und mittelgrosse Daten-banken als angemessen angesehen werden können. Nur bei übergrossen Datenbanken, mitsehr vielen Objekten des selben Typs, werden die Zeiten relativ lang, sie sind aber immernoch akzeptabel.

7.2 JUnitMit Hilfe des JUnit Frameworks17 zum automatisiertem Testen von Code-Einheiten wurdenverschiedene Tests implementiert. Es wurde als besonders wichtig angesehen, automatisierteTest für diejenigen Teile der Anwendung zu erstellen, welche Daten verarbeiten, die vomBenutzer eingegeben werden. Solche Daten sind durch ihre Herkunft bedingt in gewisserWeise unvorhersehbar und beliebig. Zu den wichtigsten vom Benutzer eingegebenen Datenzählen die benutzerdefinierten Kommentare für Datenbankobjekte. Da diese KommentareTags enthalten können, müssen sie speziell analysiert und weiterverarbeitet werden.

So wurden JUnit-Tests für den Kommentar-Parser, die Kommentar-Klasse und die Tag-Klassen implementiert. Diese Tests sind darauf ausgelegt den Parser auf Korrektheit sowiedie Erstellung und Konfiguration von Kommentar- und Tag-Objekten zu überprüfen. Zu-sätzlich wird das Verhalten bei falsch formatierten Kommentaren und Tags getestet.

Zu anderen vom Benutzer gemachte Angaben zählen die Angaben in der Konfigurationsda-tei und in der Tag-Definitionsdatei. Bei beiden handelt es sich um XML-Dateien für welcheein XML-Schema definiert wurde, um die Korrektheit beim Einlesen der Datei zu prüfen.

17 http://www.junit.org

68

8 Weiterführende Arbeiten

8 Weiterführende ArbeitenIn der vorliegenden Arbeit wurde eine Applikation zur Dokumentation von Datenbanken er-stellt. Diese Applikation kann einerseits durch den für diesen Zweck vorgesehenen Mecha-nismus der Plug-ins erweitert werden und andererseits können auch schon vorhandene Plug-ins erweitert werden. Durch die Erstellung neuer Plug-ins kann der Applikation in verschie-denen Bereichen weitere Funktionalität verliehen werden oder es können zusätzliche Daten-banksysteme angebunden werden.

Nachfolgend werden einige denkbare Erweiterungen detaillierter beschrieben.

8.1 Graphische Benutzeroberfläche (GUI)Eine für den Benutzer sehr angenehme Erweiterung wäre sicherlich das Hinzufügen einergraphischen Benutzeroberfläche. Hierfür gibt es grundsätzlich zwei Varianten. Es könnteeine allgemeine graphische Oberfläche für die Hauptapplikation zur Steuerung des Ablaufsund der Konfiguration der Plug-ins erstellt werden. Das ähnliche Möglichkeiten zur Konfi-guration bietet würde, wie die zurzeit verwendete Methode zur Konfiguration über dieKommandozeile und die spezielle XML-Datei. Als zweite Variante könnten einzelne Plug-ins ihre eigene graphische Oberfläche zur Konfiguration und Interaktion mit dem Benutzeranbieten.

Beispielsweise könnte ein Transformator-Plug-in eine graphische Oberfläche anbieten, wel-che alle vorhandenen Datenbankobjekte anzeigt und es erlaubt sie nach Typen oder aucheinzeln an- beziehungsweise abzuwählen, um so genau zu bestimmen welche Objekte doku-mentiert werden sollen. Ebenfalls könnten über eine solche Benutzeroberfläche die Kom-mentare und Eigenschaften von Datenbankobjekten geändert werden. Und eventuell könntedas Transformator-Plug-in die Änderungen in den Kommentaren sogar zurück in die Daten-bank speichern.

Eine sehr ähnlich Möglichkeit existiert bereits mit dem „Comment-Transformer“ Plug-in.Dieses erlaubt ebenfalls die Auswahl der zu dokumentierenden Objekte und Änderung derKommentare sowie das Hinzufügen neuer Eigenschaften. Allerdings funktioniert dies überdie Angabe von speziellen Transformator-Statements, die als Parameter dem Plug-in über-geben werden. Eine graphische Oberfläche wäre hier intuitiver und benutzerfreundlicher.

69

8.2 Weitere Datenbankanbindungen

8.2 Weitere DatenbankanbindungenDas Einsatzgebiet der Applikation kann mit Hilfe des Plug-in Mechanismus sehr einfachweiter ausgedehnt werden. Momentan existiert nur ein Input-Plug-in für die Anbindung vonPostgreSQL Datenbanksystemen, aber es können zusätzliche Input-Plug-ins entwickelt wer-den, um die Anbindung zu anderen relationalen Datenbanksystemen zu ermöglichen. Einsolches Plug-in kann entweder speziell für ein bestimmtes Datenbanksystem und dessen Da-tenkatalog entwickelt werden oder es könnte allgemeiner gehalten werden und über das imSQL Standard definierte „Information-Schema“ Informationen aus der Datenbank auslesen.Ein solches Input-Plug-in könnte dann mit allen Datenbanksystemen verwendet werden, diedas „Information-Schema“ gemäss dem SQL Standard implementieren. Um noch allgemei-ner zu sein, könnte ein Input-Plug-in die in der Java-Datenbankschnittstelle JDBC18 angebo-tenen Methoden verwenden, um Informationen über die Datenbank auszulesen. Somit könn-ten alle Datenbanksysteme die einen JDBC Treiber zur Verfügung stellen, dokumentiertwerden.

8.3 Weitere AusgabeformateZusätzlich zu dem momentan existierendem Output-Plug-in zur Erstellung einer HTML-Do-kumentation wären viel andere Formate für die Ausgabe der Dokumentation vorstellbar.Denkbar wären zum Beispiel eine Ausgabe im PDF oder auch im ODF beziehungsweise imMS Word Format. Weiter Ausgabeformate könnten XML oder normaler Text sein.

Zusätzlich zur Ausgabe der eigentliche Dokumentation in verschiedenen Dateiformaten sindauch andere Arten von Ausgaben denkbar. Beispielsweise wäre eine Art Analyse-Ausgabe,die Auskunft über Verbindungen, Verbindungsgrade oder Abhängigkeiten zwischen Daten-bankobjekten gibt. Diese Ausgabe könnte ihrerseits natürlich wieder in verschiedenen Aus-gabeformaten ausgegeben werden. Oder es könnte ein Output-Plug-in entwickelt werden,dass ein „SQL Create Script“ für die Datenbank generieren kann.

Ebenfalls interessant wären Ausgaben in speziellen Formaten, die in andere Programme ge-laden werden können. Zum Beispiel für ER-Diagramm Editoren oder allgemeine Visualisie-rungswerkzeuge für Graphen.

8.4 Erweiterung des DatenmodellsEbenfalls möglich wäre eine Erweiterung des Datenmodells, um mehr Daten über einzelneDatenbankobjekte zu speichern. Obwohl schon generische Methoden für die Speicherung

18 Java Database Connectivity

70

8 Weiterführende Arbeiten

von beliebigen Datenbankobjekt-Informationen und -Referenzen existieren, könnten spezi-elle Methoden für spezifische Informationen hinzugefügt werden. Durch das explizite Hin-zufügen von speziellen Methoden würde dann klar ausgezeichnet werden, welche Informa-tionen in den verschiedenen Datenbankobjekttypen noch vorhanden sind. Eine Idee wärezum Beispiel Informationen über die gegenseitigen Abhängigkeiten von Datenbankobjektenhinzuzufügen. Natürlich müssten dann auch die Input-Plug-ins und Output-Plug-ins erwei-tert werden, um diese zusätzlichen Informationen aus der Datenbank auszulesen, bezie-hungsweise in der generierten Dokumentation auszugeben.

8.5 Weitere TransformatorenWeitere Transformator-Plug-ins sind vor allem sinnvoll, um auf spezielle Gegebenheitenvon spezifischen Datenbanken oder Datenbanksystemen eingehen zu können. Transformato-ren erlauben so differenziert auf spezielle Situationen zu reagieren. Deshalb bieten sichTransformator-Plug-ins geradezu an, um spezielle Datenbankentwurfsmuster zu unterstüt-zen und sie in der Dokumentation angemessen dokumentieren zu können.

8.6 Persistente Speicherung der Informationen überDatenbankobjekte

Falls man die Applikation um die Fähigkeit erweitern würde, alle Informationen über Da-tenbankobjekte die im Datenmodell vorhanden sind persistent zu speichern, eröffneten sichneue Möglichkeiten in der Anwendung der Applikation. Ist einmal die Fähigkeit gegebenden aktuellen Zustand des Datenmodells persistent, zum Beispiel in einer XML-Datei zuspeichern, kann die Applikation zu verschiedenen Zeitpunkten ausgeführt werden und aufältere Zustände zurückgreifen.

Eine denkbare Lösung hierfür wäre die Serialisierung aller im Datenmodell vorhandenenObjekte, inklusive ihrer Zustände, zu implementieren. Ein Transformator-Plug-in würdedann die tatsächliche Serialisierung alle Datenbankobjekte vornehmen und eine weiteresTransformator-Plug-in könnte zu einem späteren Zeitpunkt die Daten wieder einlesen, umden Zustand des Datenmodells zu rekonstruierten. Daneben müssten aber zusätzlich Ände-rungen in der Hauptapplikation und der Schnittstelle für Output-Plug-ins gemacht werden,damit mehr als eine Instanz von einem Datenmodell übergeben werden könnte. Wenn dannaber einem Output-Plug-in mehrere Instanzen eines Datenmodells zur Verfügung stehen, er-geben sich die neuen Möglichkeit in der Ausgabe. So könnte beispielsweise eine Art„Diff“-Ausgabe generiert werden, also eine Ausgabe, welche die Unterschiede zwischenzwei Instanzen des Datenmodells und damit zwischen zwei verschiedenen Datenbankzu-

71

8.6 Persistente Speicherung der Informationen über Datenbankobjekte

ständen dokumentiert. Eine solche Ausgabe könnte gut eingesetzt werden, um die Änderun-gen in Datenbanken über die Zeit zu dokumentieren. Ebenfalls denkbar wäre eine inkremen-telle Generierung der Dokumentation, so könnten nur neu hinzugekommene oder geänderteDatenbankobjekte in eine schon vorhandene Dokumentation eingefügt werden.

72

9 Zusammenfassung und Schlussfolgerungen

9 Zusammenfassung undSchlussfolgerungen

In dieser Arbeit wurde eine Anwendung zur Dokumentation von Datenbanken entworfenund implementiert, welche über den Zugriff auf benutzerdefinierte Kommentare und Sche-mainformationen in der Lage ist eine HTML-Dokumentation der Datenbank zu generieren.Dazu wurden zuerst die in diesem Bereich schon vorhandenen Programme untersucht undderen Stärken und Schwächen identifiziert. In einem zweiten Schritt konnten aus diesen Er-kenntnissen und inspiriert von Javadoc, die allgemeinen Anforderungen an eine Anwendungzur Dokumentation von Datenbanken abgeleitet und spezifiziert werden.

Durch den Entwurf eines generischen Datenmodells, zur temporären Speicherung von Da-tenbankinformation sowie einer Plug-in Architektur zur flexiblen Konfiguration der Anwen-dung wurde versucht diesen Anforderungen gerecht zu werden.

Während der Implementierung zeigte sich, dass durch die Plug-in Architektur eine einfacheaber sehr flexible Möglichkeit geschaffen werden konnte, um grundsätzlich verschiedeneDatenbankanbindungen und verschiedene Ausgabeformate zu ermöglichen. Mit demHTML-Plug-in ist es gelungen eine Komponente zu implementieren, die in der Lage ist einestrukturierte und aussagekräftige HTML-Dokumentation zu generieren, welche auch tat-sächlich Potential hat in der Zukunft eingesetzt werden zu können. Die HTML-Ausgabekann flexibel konfiguriert werden um sie verschiedenen Bedürfnissen anzupassen.

Das weite Feld der Datenbankdokumentation in Verbindung mit der Plug-in Architektur bie-tet sich gerade zu an, um die Anwendung mit neuen Plug-ins zu erweitern. Es könnten neueInput-Plug-ins erstellt werden, um zusätzliche Datenbankanbindungen zu realisieren oder eskönnten neue Output-Plug-ins implementiert werden, um zusätzliche Ausgabeformate an-bieten zu können.

Zusätzlich konnten mit der Plug-in Architektur und Transformator-Plug-ins eine attraktiveMöglichkeit für die Unterstützung von Datenbankentwurfsmuster geschaffen werden. Stan-dardmässig werden von der Anwendung schon einige Transformator-Plug-ins angeboten,wobei besonders der Kommentar-Transformator als generischer Transformator eingesetztwerden kann um Entwurfsmuster zu dokumentieren. Zusätzlich können in der Zukunft neueTransformator-Plug-ins entwickelt werden, um so komplexere oder sehr spezifische Ent-wurfsmuster zu unterstützen.

Durch ein Konzept für Tags wird es, wie im Bereich der Dokumentationswerkzeuge für Pro-

73

9 Zusammenfassung und Schlussfolgerungen

grammcode schon üblich, möglich die benutzerdefinierten Kommentare zu formatieren undspezielle Informationen auszuzeichnen sowie Verweise auf andere Objekte zu definieren.Zusätzlich erlauben spezielle Tags, Kommentare nur für bestimmte Benutzergruppen zuspezifizieren. Durch eine geeignete Kombination dieser Tags mit anderen Konfigurations-möglichkeiten, wie den Kommentare-Transformator, wird es möglich die Dokumentationfür bestimmte Benutzergruppen zu individualisieren.

74

Literaturverzeichnis[ApexSQLDoc]: Apex LLC, ApexSQL Doc, ,

http://www.apexsql.com/datasheets/ApexSQL_doc_datasheet.pdf

[DBScribe]: Leadum Software, DBScribe, ,

http://www.leadum.com/product.datasheet.php?prod_id=18

[EinfJava]: Klein, Robert, Einführung in JavaDoc, 2005,

http://daxue.xyzzy.de/javadoc.pdf

[Gamma04]: Gamma, Erich [et al.], Entwurfsmuster: Elemente

wiederverwendbarer objektorientierter Software, 2004

[Glinz01]: Glinz, Martin, Vorlesungsskript in Software Engineering 1, 2001

[MerkblattJavaDoc]: Merkblatt JavaDoc, , http://qe-

informatik.uibk.ac.at/lehre/ss04/se4/download/merkblaetter/

JavaDoc.pdf

[PluginArch]: Hansen, H. Keld, Plug-in to Reusability in Java, ,

http://javaboutique.internet.com/tutorials/keldplugins/

[PostgreSQL07]: PostgreSQL, PostgreSQL 8.2.6 Documentation, 2007,

http://www.postgresql.org/docs/8.2/static/index.html

[Sommervile01]: Ian Sommerville, Software Documentation, 2001,

http://www.literateprogramming.com/documentation.pdf

[SQLDoc]: Redgate Software, SQL Doc, 2008, http://www.red-

gate.com/products/SQL_Doc/SQL_Doc.pdf

[SqlSpec]: Elsasoft, SqlSpec, , http://www.elsasoft.org/

[SunJavaDoc]: Sun Microsystems, Sun Microsystems Javadoc Tool, ,

http://java.sun.com/j2se/javadoc/

[TreeMenu]: Morten, JavaScript Tree Menu, 2008, http://www.treemenu.org/

75

AbbildungsverzeichnisAbbildung 1: Ausschnitt aus der Schnittstellenhierarchie.....................................................24

Abbildung 2: Plug-in Typen...................................................................................................30

Abbildung 3: Tag-Schnittstellen.............................................................................................39

Abbildung 4: Tag-Schnittstellen und Tag-Klassen.................................................................42

Abbildung 5: Plug-in Implementierungen..............................................................................48

Abbildung 6: Implementierungsvererbung im HTML-Output-Plug-in.................................52

Abbildung 7: Generierte HTML-Dokumentation..................................................................53

Abbildung 8: Kompletter Java-Code des ViewPropertiesSetter-Plug-ins..............................62

Abbildung 9: SQL Create Statement für Test-Relationen......................................................64

76

TabellenverzeichnisTabelle 1: Javadoc Tags..........................................................................................................12

Tabelle 2: Vordefinierte Tags..................................................................................................44

Tabelle 3: Optionen des Standard-Model-Plug-ins................................................................49

Tabelle 4: Optionen des PostgreSQL-Input-Plug-ins.............................................................50

Tabelle 5: Optionen des HTML-Output-Plug-ins..................................................................55

Tabelle 6: Detaillierte Ausführungszeiten für Datenbanken unterschiedlicher Grösse.........65

77

Documents

Ausarbeitung DA FINAL - NeoOffice Writer - UZH...Kapitel 7 enthält Information über die durchgeführten Performance- und JUnit-Tests. Im Kapitel 8 werden weiterführende Arbeiten