Abb.: Die schematische Gruppeneinteilung
In diesem Teil der Dokumentation soll ein Überblick über die Arbeit der Datenbankgruppe gegeben werden. Hierbei stehen vor allem die Organisation der Datenbank, die Datenstrukturen sowie die dafür relevanten Zielvorstellungen im Vordergrund. Nähere Informationen zur Implementierung, insbesondere den erforderlichen Javatreibern und -konzepten, finden sich in einem weiteren Kapitel sowie in der JavaDoc-Beschreibung. Außerdem wurde im Hinblick auf den praktischen Einsatz ein Sicherheitskonzept entwickelt.
An dieser Stelle werden noch einmal kurz die Argumente skizziert, die zur gewählten Architektur geführt haben. Dabei spielten vor allem softwaretechinsche Erwägungen eine Rolle. Zum einen mußte eine vernüftige Gruppeneinteilung gefunden werden, die die Aufgaben gleich verteilt, die Zusammenarbeit aber durch zu starke Abhängigkeiten nicht behindert, zum anderen mußte eine Technologie gewählt werden, die den projektierten Aufgaben gewachsen war. Dazu zählte unter Anderem die Möglichkeit, mehreren Benutzer gleichzeitig den Zugriff auf das virtuelle Gebäude zu erlauben.
Die Abbildung zeigt stark vereinfacht die gewählte Gruppenstruktur. Dabei ist vor allem die zentrale Position der Datenbank bemerkenswert. Einerseits spiegelt sich darin die zentrale Rolle der gemeinsamen Datenbasis, außerdem wurden dadurch die Entwicklungsprozesse der Editor- und der Browserfrontends entkoppelt.
In dieser Einteilung ist auch die technologische Komponente berücksichtigt, denn Java bietet eine leistungsfähige Datenbankanbindung, die auch größeren Anforderungen gewachsen ist.
Bei der Konzeption wurde auch ein vollständig objektorientierter Ansatz erwogen, der sich durch die Benutzung von Java aufdrängte. Dies ergab aber im Hinblick auf eine "verteilte" Benutzung des "virtuellen Gebäudes" durch mehrere Benutzer konzeptionelle Probleme, vor allem bei der Frage nach der Persistenz und Synchronisation der "verteilten Objekte". Da sich auch hier der zentralistische Ansatz konzeptionell als der einfachere erwies, und die gängingen Datenbanksysteme von Hause aus mit Synchronisationsmechanismen ausgestattet sind, fiel die Wahl schliesslich auf eine klassische relationale Datenbank. Dadurch hat man außerdem den Vorteil einer mächtigen Zugriffssprache und optimierter Datenspeicherung.
Das "klare Konzept" wurde natürlich auf Kosten einer relativ starken Abhängigkeit des Gesamtprojektes von der Datenbank erkauft. Allerdings konnte die Browsergruppe mit Testdaten arbeiten und war somit in den ersten Entwicklungszyklen nicht essentiell vom Funktionieren der Datenbank abhängig. Auch der Editor konnte seine Daten zunächst unabhängig von der Datenbank speichern.
Der erste Kernpunkt der Entwicklung war die Entwicklung einer tragfähigen Datenstruktur. Ziel war dabei eine einfache aber überzeugende 3D-Darstellung eines beliebigen Gebäudes zu erreichen, das mit einem Editor möglichst einfach zu erstellen sein sollte. Prinzipiell sind dabei verschiedene Vorgehensweisen denkbar.
Ein naheliegender Ansatz wäre, das Gebäude gleich als dreidimesionales Modell zu erstellen und auch zu speichern. Damit sind alle geometrischen Aspekte des Gebäudes beschrieben, die dann noch mit verschiedenen weiteren Informationen angereichert werden müssten. Dafür gibt es verschiedene erprobte Standards, im Zusammenhang mit Internetanwendungen ist vor allem der VRML-Standard zu nennen. Bei diesem Vorgehen hätten der Editor und der Browser entsprechende Import- und Exportfilter enthalten müssen und die Modellierung und Speicherung der Daten hätte dem Rahmen der Möglichkeiten des verwendeten Objektformates angepasst werden müssen. Besonders bei Objekten wie Türen, die einerseits interaktiv manipuliebar (d.h., man sollte sie öffnen und schliessen können) sein und andererseits Zustände wie "abgeschossen" oder "geöffnet" persistent besitzen sollten, gab es auch hier schon bei Konzeption Probleme.
Nach langer Diskussion einigte man sich dann auf einen Kompromiss, der die modellierbaren Gebäude zunächst auf solche mit geraden Wänden und Decken einschränkt.
Die Abbildung zeigt schematisch, wie die logische Struktur zusammen mit der Geometrie des Gebäudes in eine Datenstruktur integriert wurde. Räume werden dabei geometrisch alleine durch die Innenseiten der sie umschliessenden Wände beschrieben. Die Verbindungen zwischen Räumen, also die "Stellen" an denen man von einem Raum in einen anderen gelangt (typischerweise Türschwellen) sind sogenannte "Passagen". Diese bezeichnen immer die (logische) Verbindung zwischen zwei Räumen. Geometrisch spiegelt sich dieser Sachverhalt in "Durchbrüchen" (Breakthrough) der jeweiligen Wände wieder. Außerdem können Passagen auch Objekte, wie z.B. Türen, enthalten. Damit wurde auch das Problem umgangen, zu welchem Raum eine Tür gehört.
Die folgende Abbildung zeigt das gesamte Datenmodell in der Entity-Relationship-Notation.
Da für den Datenbankzugriff die "Sprache" SQL (Structured Query Language) verwendet wurde, die Relations nicht direkt enthält, mußte das Modell entsprechend umgewandelt werden, um in die SQL-Tabellen-Struktur zu passen. Bei einfachen 1:1 Relationen lässt sich das mit zusätzlichen Index-Attributen bewerkstelligen:
Die obige Relation würde man also über ein zusätzliches Attribut in der Tabelle "Wall" umsetzen, in diesem Fall "RoomID":
TABLE Wall:
id: Index
Name:
p1_x: "linke" x-Koordinate
p1_y: "linke" y-Koordinate
p2_x: "rechte" x-Koordinate
p2_y: "rechte" y-Koordinate
RoomID: Verweis auf den Raum (Relationship: has_wall)
Es wurde versucht diese Umstellung konsistent vorzunehmen, allerdings wurde z.B. die Relation "BreakThrough" aus Geschwindigkeitsgründen in einer eigenen Tabelle kodiert. Um diese Sonderfälle vor dem Programmierer zu verstecken, wurde für jede Entity der Datenbank eine Java-Wrapper-Klasse definiert, die das Laden, sowie die Updates, entsprechend der tatsächlich Datenbankstruktur durchführt. Eine Informationen zu diesen Klassen finden sich in der JavaDoc-Dokumentation.
Das beschriebene Konzept wurde engagiert diskutiert, es stellte aber im Laufe der Implementierungsphase heraus, daß es nicht detailliert genug war, um als wirkliche Arbeitsgrundlage dreier, getrennt arbeitender Gruppen zu dienen. Dabei gab es insbesondere die angesprochenen Probleme mit der Datenbankstruktur, die nie einen wirklich stabilen Charakter erhielt und damit zu Mißverständnissen führte. Zum Schluss stellte es sich außerdem als kritisch heraus, daß nach der Spezifikation keine eindeutigen und verbindlichen Testfälle festgelegt worden waren.
Zu den organisatorischen Problemen kamen einige technische hinzu. Da die meisten Java-Klassen zum Zugriff auf Daten URLs benutzen, konnte z.B. Bilder nicht als Bilddateien in der Datenbank gespeichert werden, sondern mußten als Image-Objekte abgelegt werden, da die Imageklassen keine Streams einlesen.
Ein Thema, das bei der Konzeption des Projektes schon berücksichtigt wurde, aber innerhalb eines Semesters nicht mehr implementiert werden konnte, war die Kommunikation zwischen mehreren Browser-Clients, die zusammen in einem virtuellen Gebäude interagieren können sollten.
Die folgende Abbildung zeigt den schematischen Aufbau der Client-Server Architektur, in der die Datenbank ein zentrale Rolle spielt. Der Server als solcher gibt die Anfragen direkt an die Datenbank weiter, informiert aber die anderen Clients über sie betreffende Änderungen. Dies sind vor allem solche Veränderungen, die Räume betreffen, in denen sich mehrere Clients "aufhalten".
Eine logische Erweiterung dieser Architektur sind sogenannte Avatare. Diese sind zunächst mal allgemein geometrische Objekte, die den Benutzer in der "virtuellen Welt" vertreten und seinen "Aufenthaltsort" für andere sichtbar machen. In der Datenstruktur sollen sie genau als "geometrische Objekte" Räumen zugeordnet werden. Animationen wurden im bestehenden Konzept noch nicht berücksichtigt, immerhin können so die Bewegungen der Avatare verfolgt werden.
Es wurde durch die Kapselung der Datenbankzugriffe angestrebt, eine solche Erweiterung "transparent" für Entwickler und bestehende Programme implementieren zu können. Allerdings ergeben sich durch die Notwendigkeit einer "Ereignissbehandlung" andere Anforderungen an die Programmstruktur der Clients. Immerhin lässt sich die bestehende API ohne größere Probleme um entsprechende zusätzliche Routinen erweitern.
Ein weiterer Vorteil der sich durch einen solchen Kommunikationsserver ergibt, ist die Möglichkeit, die Datenbank durch sichere Anmelde und Authentifikationsmechanismen zu schützen und ein maßgeschneidertes Sicherheitskonzept zu implementieren. Diese Überlegungen werden detailliert in Kapitel 3 dieser Dokumentation beschrieben.