Restructured text
This commit is contained in:
parent
43a86ab5a5
commit
a000e15264
3 changed files with 104 additions and 64 deletions
96
text/content.troff
Normal file
96
text/content.troff
Normal file
|
|
@ -0,0 +1,96 @@
|
|||
.H1 Einleitung
|
||||
.br
|
||||
.H2 Aufgabenstellung
|
||||
Das Ziel dieser Arbeit ist das Schreiben einer Software, welche das Verwalten von Studierenden einer Hochschule effizient ermöglicht.
|
||||
Dazu soll die Software aus gegebenen Beziehungen einen Stundenplan generieren können und dabei Ressourcen wie zum Beispiel Räume und Technik automatisch aufteilen.
|
||||
Für die Verwendung der Software soll sowohl für Studierende als auch für Dozierende und die Verwaltung ein Web-basiertes Interface angeboten werden.
|
||||
.H2 Spezifikation
|
||||
Die Software soll in Java geschrieben werden. Dabei soll wenn möglich auf die Optionen der Standardbibliothek zurückgegriffen werden, besonders für die Implementation des Webservers für das Interface. Objektorientierung soll wo sinnvoll angewendet werden.
|
||||
.sp
|
||||
.H1 Hauptteil
|
||||
.br
|
||||
.H2 Problemanalyse und Lösungsansätze
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Ein weiterer Zentraler Punkt der Arbeit ist der Algorithmus zur Ressourcenverteilung.
|
||||
.TODO Scheduling-Algorithmus!\"
|
||||
.H2 Architektur
|
||||
Die vorliegende Software ist in Java geschrieben und arbeitet stark mit Objektorientierung.
|
||||
Auf externe Abhängigkeiten außerhalb des JDKs wurde der Einfachheit halber verzichtet.
|
||||
|
||||
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.
|
||||
|
||||
.H3 Datenverwaltung
|
||||
Die zentrale Klasse der Datenverwaltung ist die abstrakte Klasse \fCDataObject\fR.
|
||||
Sie stellt die Superklasse für alle im Model verwalteten Objekte dar.
|
||||
Ihre Implementation ist bewusst sehr einfach gehalten.
|
||||
.sp
|
||||
.TS
|
||||
box center;
|
||||
cb
|
||||
-
|
||||
l
|
||||
l
|
||||
-
|
||||
l.
|
||||
DataObject
|
||||
+ displayName: String
|
||||
+ uid: String
|
||||
# DataObject(String uid, String displayName)
|
||||
.TE
|
||||
.sp
|
||||
Die UID ist ein String, welcher eine eineindeutige Zeichenkette für das Objekt enthält.
|
||||
Strukturiert werden kann sie als Hierarchie mit / als Trennzeichen, zum Beispiel \fCstudents/jotto5\fR.
|
||||
Das ist nicht benötigt, aber einige Views verwenden diese Syntax für eine etwas bessere Übersicht.
|
||||
Der DisplayName ist ein frei wählbarer String welcher einen menschenlesbare Namen für das Objekt enthält, im Fall einer Studierenden Person zum Beispiel eine Zeichenkette im Format \fCVorname, Nachname\fR.
|
||||
|
||||
Die Klasse enthält einen Konstruktor der die UID und den Anzeigenamen initialisiert.
|
||||
Dieser ist bewusst protected gehalten, da die DataObject-Klasse abstrakt ist und nur als Superklasse dient.
|
||||
Setter und Getter sind nicht vorgesehen, da die Felder public sein müssen.
|
||||
.TODO Referenz auf Formular-Annotation-System!\"
|
||||
|
||||
Von dem DataObject erben nun mehrere Klassen, welche spezifischere Felder und Methoden beinhalten können, zum Beispiel die Klasse \fCStudent\fR oder die Klasse \fCGroup\fR.
|
||||
Das hat den Vorteil dass das Model selber sich nur um die Verwaltung einer Liste von DataObjects kümmern muss ohne die genaue Semantik zu kennen oder eine Trennung zwischen verschiedenen Typen machen zu müssen.
|
||||
Für das Verwenden der Objekte werden dann Javas Möglichkeiten der Reflexion bzw. Introspektion benutzt.
|
||||
|
||||
.TODO Model erklären!\"
|
||||
.H3 Der Webserver und die Views
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
|
@ -10,68 +10,6 @@
|
|||
.TITLEITEM "Einreichung:" "Mittweida, irgendwann 2025"
|
||||
.CONTENT
|
||||
.bp
|
||||
.H1 I. Inhaltsverzeichnis
|
||||
.sp
|
||||
.TOCITEM "Erster Punkt" 1
|
||||
.TOCITEM "Zweiter Punkt" 2
|
||||
.TOCITEM "Dritter Punkt" 3
|
||||
.TODO TOC hinzufügen!\"
|
||||
.so toc.troff
|
||||
.bp
|
||||
.H1 Einleitung
|
||||
.br
|
||||
.H2 Aufgabenstellung
|
||||
Das Ziel dieser Arbeit ist das Schreiben einer Software, welche das Verwalten von Studierenden einer Hochschule effizient ermöglicht. Dazu soll die Software aus gegebenen Beziehungen einen Stundenplan generieren können und dabei Ressourcen wie zum Beispiel Räume und Technik automatisch aufteilen. Für die Verwendung der Software soll sowohl für Studierende als auch für Dozierende und die Verwaltung ein Web-basiertes Interface angeboten werden.
|
||||
.H2 Spezifikation
|
||||
Die Software soll in Java geschrieben werden. Dabei soll wenn möglich auf die Optionen der Standardbibliothek zurückgegriffen werden, besonders für die Implementation des Webservers für das Interface. Objektorientierung soll wo sinnvoll angewendet werden.
|
||||
.sp
|
||||
.H1 Hauptteil
|
||||
.br
|
||||
.H2 Problemanalyse und Lösungsansätze
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Ein weiterer Zentraler Punkt der Arbeit ist der Algorithmus zur Ressourcenverteilung.
|
||||
.TODO Scheduling-Algorithmus!\"
|
||||
.H2 Architektur
|
||||
Die vorliegende Software ist in Java geschrieben und arbeitet stark mit Objektorientierung. Auf externe Abhängigkeiten außerhalb des JDKs wurde der Einfachheit halber verzichtet.
|
||||
|
||||
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.
|
||||
|
||||
.H3 Datenverwaltung
|
||||
Die zentrale Klasse der Datenverwaltung ist die abstrakte Klasse \fCDataObject\fR. Sie stellt die Superklasse für alle im Model verwalteten Objekte dar. Ihre Implementation ist bewusst sehr einfach gehalten.
|
||||
.sp
|
||||
.TS
|
||||
box center;
|
||||
cb
|
||||
-
|
||||
l
|
||||
l
|
||||
-
|
||||
l.
|
||||
DataObject
|
||||
+ displayName: String
|
||||
+ uid: String
|
||||
# DataObject(String uid, String displayName)
|
||||
.TE
|
||||
.sp
|
||||
Die UID ist ein String, welcher eine eineindeutige Zeichenkette für das Objekt enthält. Strukturiert werden kann sie als Hierarchie mit / als Trennzeichen, zum Beispiel \fCstudents/jotto5\fR. Das ist nicht benötigt, aber einige Views verwenden diese Syntax für eine etwas bessere Übersicht. Der DisplayName ist ein frei wählbarer String welcher einen menschenlesbare Namen für das Objekt enthält, im Fall einer Studierenden Person zum Beispiel eine Zeichenkette im Format \fCVorname, Nachname\fR.
|
||||
|
||||
Die Klasse enthält einen Konstruktor der die UID und den Anzeigenamen initialisiert. Dieser ist bewusst protected gehalten, da die DataObject-Klasse abstrakt ist und nur als Superklasse dient. Setter und Getter sind nicht vorgesehen, da die Felder public sein müssen.
|
||||
.TODO Referenz auf Formular-Annotation-System!\"
|
||||
|
||||
Von dem DataObject erben nun mehrere Klassen, welche spezifischere Felder und Methoden beinhalten können, zum Beispiel die Klasse \fCStudent\fR oder die Klasse \fCGroup\fR. Das hat den Vorteil dass das Model selber sich nur um die Verwaltung einer Liste von DataObjects kümmern muss ohne die genaue Semantik zu kennen oder eine Trennung zwischen verschiedenen Typen machen zu müssen. Für das Verwenden der Objekte werden dann Javas Möglichkeiten der Reflexion bzw. Introspektion benutzt.
|
||||
|
||||
.TODO Model erklären!\"
|
||||
.H3 Der Webserver und die Views
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
.so content.troff
|
||||
6
text/toc.troff
Normal file
6
text/toc.troff
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
.H1 I. Inhaltsverzeichnis
|
||||
.sp
|
||||
.TOCITEM "Erster Punkt" 1
|
||||
.TOCITEM "Zweiter Punkt" 2
|
||||
.TOCITEM "Dritter Punkt" 3
|
||||
.TODO TOC hinzufügen!\"
|
||||
Loading…
Add table
Add a link
Reference in a new issue