joss/beleg
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

text: rewrote main part a bit

Browse source
This commit is contained in:
joss 2025-07-18 11:50:12 +02:00
parent 9a7e8e97fd
commit dbb4e64b64
1 changed files with 26 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

38
text/content.troff
View file

@ -18,26 +18,40 @@ Zusätzliche externe Abhängigkeiten werden nicht eingebunden.
.NH 1 .NH 1
Hauptteil Hauptteil
.NH 2 .NH 2
Problemanalyse und Lösungsansätze Problemanalyse
.LP .LP
Um die oben genannten Ziele zu erreichen muss die Arbeit eine Reihe an Problemen lösen. 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. 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. 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. Kernproblem der Arbeit ist dann das Verwenden der Daten um eine Ressourcenverteilung, also unter Anderem einen Stundenplan, zu erzeugen.
.NH 2
Lösungsansätze
.LP .LP
Zur Aufgabentrennung ist die Anwendung mit einer Art Model-View-Controller Pattern entworfen. Die Anwendung ist mit einer Variante des 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. Dabei übernehmen die Views die Anzeige der Daten, der Controller verwendet die eingegebenen Daten zur Weiterverarbeitung und das Model speichert die Daten.
In dem Fall einer Webanwendung kann eine View dann jeweils einem Endpunkt entsprechen - so ist es in dieser Anwendung umgesetzt. Allerdings haben die Views direkten Zugriff auf das Model, und müssen zum Anzeigen der Daten nicht den Controller anfragen.
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 .LP
Nach dem Pattern erfolgt das Speichern der Daten nun in einem Model. Die Views sind als Endpunkte der Webanwendung umgesetzt.
Das Model kann flexibel entworfen werden, theoretisch auch als Interface, um verscheidenartige Speichermethoden zu ermöglichen. So befindet sich zum Beispiel die View die eine Objektübersicht anzeigt unter \fC/tree\fR.
Anbindungen an ein LDAP-Verzeichnis oder eine relationale Datenbank sind beispielsweise denkbar. Die Views reagieren auch auf POST-Anfragen, die Daten verändern können; so wird zum Beispiel das Bearbeiten von Datensätzen realisiert.
Views können direkt Funktionen des Controllers aufrufen.
Das wird zum Beispiel verwendet um den Zeitplan zu generieren.
.LP
Das Speichern der Daten erfolgt im Model.
Das Model kann flexibel entworfen werden, theoretisch auch als Interface, um verscheidenartige Speichermethoden zu ermöglichen.\**
.FS
Beispielsweise LDAP oder eine relationale Datenbank.
.FE
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. 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 .LP
Ein weiterer Zentraler Punkt der Arbeit ist der Algorithmus zur Ressourcenverteilung. Ein weiterer Zentraler Punkt und Hauptaufgabe des Controllers ist der Algorithmus zur Ressourcenverteilung.
Dabei werden die in der Datenbank vorhandenen Ressourcen (zum Beispiel Module und Räume) sinnvoll auf Zeit-Slots in der Woche aufgeteilt.
Im weiteren Verlauf wird angenommen dass das zu lösende Problem hierbei zur Klasse der NP-vollständigen Probleme gehört.\**
.FS
Der Beweis würde den Rahmen der Arbeit überschreiten. Ein möglicher Ansatz ist das Reduzieren des Rucksackproblems auf dieses Problem.
.FE
Folglich wird angenommen dass es keinen Algorithmus zum deterministischen Lösen des Problems in Polynomialer Zeit gibt.
Es muss also eine Heuristik gefunden werden, die es erlaubt das Problem trotzdem in annehmbarer Zeit zu lösen.
.TODO Scheduling-Algorithmus!\" .TODO Scheduling-Algorithmus!\"
.NH 2 .NH 2
Architektur Architektur
@ -92,7 +106,7 @@ Zum Kompilieren der Anwendung selbst wird ein aktuelles JDK\**
.FS .FS
Zum Zeitpunkt des Schreibens Version 21 LTS. Zum Zeitpunkt des Schreibens Version 21 LTS.
.FE .FE
sowie eine aktuell Installation von Apache ANT\** sowie eine aktuelle Installation von Apache ANT\**
.FS .FS
Zum Zeitpunkt des Schreibens Version 1.10.15. Zum Zeitpunkt des Schreibens Version 1.10.15.
.FE .FE