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

removed unnecessary details

Browse source
This commit is contained in:
joss 2025-04-30 09:41:05 +02:00
parent 3b9087864e
commit f64e4cb794
1 changed files with 1 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
text/thesis.troff
View file

@ -31,7 +31,7 @@ Um die oben genannten Ziele zu erreichen muss die Arbeit eine Reihe an Problemen
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. Anbinden an eine Datenbank beispielweise ist aber fast trivial, da ausschließlich die \fCModel\fR-Klasse neu implementiert werden muss. Die Daten selber können nun mithilfe von Oblektorientierung dargestellt werden, dazu mehr in den Implementationsdetails.
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!\"