Design des Recherche-Applets

Allgemeines

Das Recherche-Applet ist in mehrere Klassen und Interfaces aufgeteilt, wobei die Aufteilung dem Model-View-Controller (MVC) Konzept entspricht:

Die Models bestehen aus Klassen, die im allgemeinen lediglich DB-Daten und Zustandsdaten festhalten. So hält z.B. DefTreeModel die hierarchisierten Definitions-Daten vor, RechercheModel speichert die internen Zustandsdaten der Recherche etc.
Die Views implementieren allesamt das Interface Page und stellen im wesentlichen die Fensterinhalte zu verschiedenen Phasen der Recherche dar: QueryPage z.B. stellt das UI für die inhaltliche Auswahl zur Verfügung, RechAuswahlPage zeigt alle verfügbaren Recherchen an etc.
Die Controller-Funktionalität wird einerseits durch das Applet Recherche übernommen: Das Applet wird in allen Pages als ActionListener eingetragen. Das Fortschreiten in der Recherche wird durch den Austausch der Pages und das Ändern/Update der Models realisiert. Weiterhin werden größere Operationen auf den Datenbeständen durch die Klasse RechercheModel erledigt. Kleinere Anfragen an die weiteren Models führen die Views teilweise eigenständig durch.

Eine der Hauptaufgaben der Recherche liegt in der Umsetzung der Tabelleneinträge in Objekte. Dabei muß Folgendes beachtet werden:

Die Einträge in den Tabellen sind nach dem Entity-Relationship-Modell (ERM) angelegt, d.h. die Daten liegen in einer Tabelle, ihre Beziehung untereinander aber in einer anderen (Beispiel: DEF und RELATIONEN, Gegenbeispiel: BEGRIFFE). In der Objektumgebung von Java werden die Daten dagegen als Baum dargestellt. Ebenso wird ein Teil der Relationsdaten auch direkt in den objektorientierten Repräsentationen der Tabellenzeilen vorgehalten, z.B. der Name der zugehörigen Merkmalsgruppe in DefRec (wenn dieses ein Merkmal repräsentiert) und der Vater und das 1. Kind in BegriffRec.
Die Daten aus der Datenbank sind überwiegend "read-only"-Daten, was angesichts ihrer Fülle ein Laden im Hintergrund von Daten vor ihrer eigentlichen Verwendung sinnvoll macht. Dies geschieht beispielsweise bei der Erzeugung des DefTreeModels. Dort wird die Methode initialize(), die den Aufbau des MDEF-Baumes aus der Datenbank übernimmt, direkt nach dem Login in einem separaten Thread aufgerufen, so bereits Daten geladen werden, während der Anwender noch mit der Auswahl oder Neuerstellung der Recherche beschäftigt ist. Desweiteren ist es auch möglich, (und angesichts der relative langen Ladezeit im Minutenbereich auch sinnvoll)den Definitionsdatenbaum bereits als vorinitialisiertes Objekt auf dem Server bereitzuhalten z.B. über Object Serialization bzw. RMI (s. dazu Leistungsoptimierung der HLFB-Recherche).

Hier finden sich die durch javadoc generierten Dokumentationen.