.NH 1
Einleitung
.TODO Aufreisser!\"
.NH 2
Aufgabenstellung
.LP
Das Ziel dieser Arbeit ist das Schreiben einer Software, welche das Verwalten der Grundabläufe einer Hochschule effizient ermöglicht.
Dazu soll die Software Studierende und Dozenten erfassen, Studiengänge abbilden und zu einer Liste von Modulen zuordnen.
Weitere zu Erfüllende Aufgaben sind nachträgliche Veränderung von erfassten Daten und das erstellen von Stundenplänen für den Regelbetrieb.
.NH 2
Spezifikation
.LP
Die Software soll für die Verwendung ein grafisches Interface über HTTP anbieten.
Dieses Interface soll die Eingabe und Änderung von Stammdaten sowie das Benutzen der weiteren Funktionen ermöglichen.
Geschrieben wird die Software in der Programmiersprache Java.
Dabei sollen die Möglichkeit der Java-Standardbibliothek sowie Objektorientierung genutzt werden.
Zusätzliche externe Abhängigkeiten werden nicht eingebunden.
.NH 1
Hauptteil
.NH 2
Problemanalyse und Lösungsansätze
.LP
Um die oben genannten Ziele zu erreichen muss die Arbeit eine Reihe an Problemen lösen.
Grundlegender Bestandteil ist das Erfassen und Speichern von Informationen über Studierende, Dozierende, weitere Ressourcen, Studiengänge und deren Beziehungen.
Ein weiteres zu lösendes Problem besteht in der Präsentation der Daten für die Benutzenden.
Kernproblem der Arbeit ist dann das Verwenden der Daten um eine Ressourcenverteilung, also unter Anderem einen Stundenplan, zu erzeugen.
.LP
Zur Aufgabentrennung ist die Anwendung mit einer Art Model-View-Controller Pattern entworfen.
Dabei ist das Model dafür zuständig den Zugriff auf die Daten zu gewährleisten, die View übernimmt die Anzeige der Daten und der Controller beinhaltet die Steuerlogik für Interaktionen mit dem Benutzenden.
In dem Fall einer Webanwendung kann eine View dann jeweils einem Endpunkt entsprechen - so ist es in dieser Anwendung umgesetzt.
Ein Endpunkt ist in diesem Kontext das Dokument welches durch einen bestimmten Pfad unter der Webanwendung erreichbar ist, beispielsweise \fC/auth\fR für den Endpunkt welcher die Anmeldemaske bereitstellt.
Das Erfassen der Daten kann über diese Endpunkte beziehungsweise die Dokumente darunter erreicht werden.
.LP
Nach dem Pattern erfolgt das Speichern der Daten nun in einem Model.
Das Model kann flexibel entworfen werden, theoretisch auch als Interface, um verscheidenartige Speichermethoden zu ermöglichen.
Anbindungen an ein LDAP-Verzeichnis oder eine relationale Datenbank sind beispielsweise denkbar.
Da persistente Speicherung nicht Teil der Aufgabenstellung ist wurde in dieser Implementierung darauf verzichtet und das Model arbeitet vollständig volatil, speichert alle Informationen also lediglich im Hauptspeicher.
Die Daten selber können nun mithilfe von Oblektorientierung dargestellt werden, dazu mehr in den Implementationsdetails.
.LP
Ein weiterer Zentraler Punkt der Arbeit ist der Algorithmus zur Ressourcenverteilung.
.TODO Scheduling-Algorithmus!\"
.NH 2
Architektur
.LP
Der gesamte Code der Anwendung befindet sich im Paket \fChsmw.jotto5.beleg\fR.
Direkt in diesem Paket befindet sich die Main-Klasse mit dem Einstiegspunkt.
Darunter befindet sich das Paket \fCviews\fR, in dem die Klassen für die einzelnen Views liegen, und das Paket \fCdata\fR, in dem alle Klassen implementiert sind die sich mit Datenverwaltung und Abfrage beschäftigen, zum Beispiel das Model.
.NH 3
Datenverwaltung
.LP
.PS
.so uml.pic
.PE
.LP
Das vorliegende vereinfachte\**
.FS
\**eine genauere Beschreibung der Klassen befindet sich im Anhang.
.FE
UML Klassendiagramm beschreibt die Struktur der Datenverwaltung.
Dabei ist das DataObject die Basisklasse aller verwalteten Objekte.
.NH 3
Der Webserver und die Views
.LP
Der Webserver selber ist mithilfe der Bibliotheken aus dem JDK entwickelt, und nutzt die Klassen aus \fCcom.sun.net.httpserver\fR.
Dazu wird die Klasse \fCHttpServer\fR in der Main-Methode einmal instanziiert und die Endpunkte werden festgelegt.
Dafür wird vor dem Start des Webservers für jeden Endpunkt ein \fCHttpContext\fR erzeugt und an eine View gebunden.
Die Routing-Logik wird dann vom \fCHttpServer\fR selbst übernommen.
.LP
Die Views selber befinden sich als einzelne Klassen im Paket \fChsmw.jotto5.beleg.views\fR.
Sie erben von \fCcom.sun.net.httpserver.HttpHandler\fR und implementieren ihre \fChandle\fR-Methode.
Diese Methode wird aufgerufen wenn der an die View gebundene Endpunkt angefragt wird, und verarbeitet einen als Argument übergebenen \fCHttpExchange\fR.
.LP
Manche Views bieten interaktive Möglichkeiten an, zum Beispiel Formulare.
Diese Views prüfen bei jedem Aufruf den HTTP-Anfragetyp.
Bei einer GET-Anfrage wird einfach nur das Formular zurückgegeben.
Wenn die benutzende Person ein Formular abschickt wird es als POST-Request übergeben, in diesem Fall führt die View Logik zum Bearbeiten des Models aus.
.LP
In der Regel ist jede View für genau einen Endpunkt zuständig.
Die RootView ist eine Ausnahme. Sie wird auch für alle nicht zugeordneten Endpunkte aufgerufen.
In diesem Fall prüft die RootView nach einer Datei mit dem angefragten Namen im Ordner \fCstatic\fR.
Das wird zum Beispiel für CSS-Stylesheets und Bilder verwendet.
Wenn es keine Datei mit dem Namen gibt wird schlussendlich ein HTTP-404-Fehler geworfen.
.LP
Besonders ist auch die Klasse \fChsmw.jotto5.beleg.views.Defaults\fR.
Sie stellt selber keine View dar, bietet aber statische Methoden und Variablen an welche zwischen allen Views geteilt werden, zum Beispiel ein Grundgerüst für die HTML-Dokumente welche zurückgegeben werden.