Lösungsansätze

In der Projektplanung sind folgende Grundlegende Fragen aufgetreten:

Programmausführung als Servlet oder als Applet?

2 Alternativen standen für unser Projekt zur Auswahl:

Verwendung von Servlets im Business Layer (serverseitige Anwendung um dynamisch HTML zu erzeugen, Datenbankzugriffe zu regeln, etc.). Vorteile: Instanzen liegen nur einfach vor. Performance liegt in unserer Hand.
Durchgehend Applets (in HTML eingebettete Java-Programme, die dynamisch über das Netzwerk geladen werden) verwenden. Das Datenbank-Interface muss selbst dafür sorgen, dass die Daten konsistent bleiben. Es muss gegenüber dem Business-Layer Sperrungen vornehmen, damit nicht mehrere Instanzen vom eigentlich selben Objekt entstehen. Die Performance wird bei Verwendung von Applets vorwiegend vom User bestimmt.

Wir haben uns für die Verwendung von Applets entschieden, da dies die schnellste Variante in der Implementierung für einfache GUI's ist. Es muss daher auch darauf geachtet werden, dass der Benutzer ohne grössere Probleme und ohne langes Herunterladen von benötigten libaries arbeiten kann. Die Verwendung von Applets wurde in einem Prototypen getestet.

Datenbankzugriff

Wir greifen mittels JDBC-Interface (Java Database Connectivity) direkt auf eine relationale Datenbank zu.

Um eine möglichst schnelle Bearbeitung und Verwendung der Daten zu erreichen haben wir uns entschlossen nicht bei jeder Datenänderung auf die Datenbank zuzugreifen, sondern die Daten in Objekten zwischen zu halten. Dies hat den Preis dass zusätzlich geregelt werden muss, das nicht 2 Personen gleichzeitig an einem Artefakt arbeiten und somit die Konsistenz der Datenbank gefärdet wird. Nur beim holen der Daten und beim Abspeichern der Daten muss auf den Server und somit die Datenbank zugegriffen werden. Alle anderen arbeiten werden vom Applet direkt beim Benutzer erledigt.

Die ursprünglich geplante Datenhaltung als XML-Objekte wurde aus Performancegründen verworfen. Es sollte nur mehr ein Datenbankinterface zur Verfügung gestellt werden, das Routinen zur Verfügung stellt, die XML-Objekte aus den gespeicherten Daten liefern können (etwa für Katalogerstellung).

Verteilung der Benutzerrechte

Die Unterteilung der Bunutzerrechte sollte sehr fein sein, es sollte die Möglichkeit bestehen die Rechte mit einer Art Wizard zu verändern oder neue zu erzeugen.

In unserer Lösung gibt es keine vordefinierten Gruppen (bis auf den Verwalter der alle Rechte insbesondere administrative hat). Der Verwalter kann die Rechte an Mitarbeiter vergeben. Er hat aber auch die Möglichkeit sogenannte Objektgruppen zu erstellen und die Rechte der Mitarbeiter diesen Objektgruppen zuzuweisen. Das Ergebnis sind die unterschiedlichsten Rechte für die Mitarbeiter, somit ist die Gestaltung der Rechte und der Gruppen sehr dynamisch und flexibel.

Im weiteren Entwurfsverlauf haben wir uns dazu entschlossen die Rechte (Funktionalitäten) in der Datenbank in einer Klasse <<UserGr_ObjGr>> zu speichern. Diese Klasse enthält Objekte mit den Attributen: userId (ID der Usergroup), objId(ID der Objektgruppe) und funct (Funktionalitäten). Dies ermöglicht nun die Zuweisung bestimmter Rechte bezogen auf Benutzer und Objektgruppe. Die Rechte werden in einem Byte codiert, um eine möglichst vielfältige Rechtevergabe zu erhalten.