Textprobe: Kapitel 4, Umsetzung und Implementierung des Ansatzes: Nachdem in Kapitel 3 der Generische Ansatz zur Erstellung eines Bestätigungsgraphen auf Basis ausgewählter Anwendungsfälle schrittweise ausgearbeitet wurde, soll im folgenden Kapitel die Umsetzung und Implementierung des Ansatzes beschrieben werden. Dies betrifft das Festlegen der Use Cases, den grundlegenden Systementwurf, die Auswahl einer geeigneten Spatial Database, die Umsetzung eines Scanners und Parsers auf Basis der erarbeiteten Grammatik und vor allem die Implementierung auf Basis der objektorientierten Programmiersprache Java. 4.1, Use Cases und Systementwurf: Auf Basis der bisherigen Arbeit und mit Blick auf das Ziel den generischen Ansatz auch in der gewünschten Form als Server-Client-Applikation zu implementieren, wurden zunächst die Use Cases herausgearbeitet, die in Abbildung 19 zu sehen sind. Im Zentrum steht die 'Network Communication', über die die Kommunikation zwischen Client und Server abläuft. Auf der Client-Seite befindet sich der Use Case 'Create Report', der das Erstellen und Absenden eines neuen Reports zu einem beliebigen Anwendungsfall repräsentiert. Auf der Server-Seite findet sich der Use Case 'Check Report', der beim Eintreffen eines neuen Reports alle damit verbundenen Aktionen des Servers beinhaltet, wie z.B. das Überprüfen der Integrität des Reports und das Anstoßen einer Aktualisierung des Bestätigungsgraphen. Dieser Use Case wird von zwei weiteren Use Cases erweitert: 'Scan and Parse Rules Files' beinhaltet alle Funktionen, die mit dem Scannen und Parsen der Konfigurationsdatei und des Regelwerks zu tun haben, sowie die daraus entstehenden Folgefunktionen. 'Create Confirmation Graph' hingegen beinhaltet den Aufbau und die Aktualisierung des Bestätigungsgraphen. In der Model-Ebene finden sich auf der Server-Seite drei Subsysteme. 'Database Management' setzt auf der Datenbank des Servers auf und dient als Bindeglied zwischen allen anderen Subsystemen des Servers und der Datenbank. Dies ermöglicht es bei Bedarf auch eine andere Datenbank einzusetzen, ohne zu viel am gesamten Server verändern zu müssen. Hier muss zudem zunächst die Integrität eines Reports geprüft werden um fehlerhafte Reports erst gar nicht in die Datenbank zu übernehmen und nicht für die Erstellung eines Bestätigungsgraphen zu nutzen. Das Subsystem 'Rules Management' in Verbindung mit dem Subsystem 'Rules Scanner and Parser' kümmert sich um das Scannen und Parsen des Regelwerks und bereitet diese für andere Subsysteme des Servers auf. Auf der Client-Seite finden sich in der Model-Ebene keine eigenen Subsysteme, da der Client bewusst klein und rudimentär gehalten wurde, da er nur zum einfachen Erstellen und Versenden von Berichten dienen soll. Alle darüber hinausgehenden Funktionen sind für eine erste Implementierung des generischen Ansatzes eher unwichtig und daher nicht aufgenommen. Eine zukünftige weitere und umfangreichere Implementierung sollte natürlich auch bei diesem Aspekt in Betracht gezogen werden. Die Controller-Ebene verfügt auf Server-Seite über vier Subsysteme: Im Zentrum steht das Subsystem 'Controller', das alle Funktionen des Servers zentral regelt. Die Erstellung des Bestätigungsgraphen inklusive aller dazugehörigen Funktionen sind im Subsystem 'Confirmation Graph' hinterlegt. Das dritte Subsystem 'Network Communication' findet sich ebenso auf der Client-Seite und dient auf beiden Seiten zur Kommunikation zwischen den beiden Instanzen. Zudem findet sich auf Client-Seite ebenso ein Subsystem 'Controller' als zentrale Steuerungseinheit. Für die View-Ebene dient das Subsystem 'User Interface' auf Client-Seite für jegliche Interaktion mit dem Nutzer. Auf der Server-Seite findet sich das Subsystem 'Server Console'. Dieses hat zwei grundlegende Funktionen: Interaktion mit dem Server-Administrator damit sich beispielsweise der Server starten oder stoppen lässt. Und zusätzlich die Möglichkeit Ausgaben über das aktuelle Server-Geschehen auf der Server-Konsole auszugeben.