added organisation

doc/bachelorarbeit_EstherKleinhenz/chapters/prototyp.tex

@@ -23,11 +23,9 @@ Zum Entwickeln des Prototypen wird die Open-Source- Entwicklungsumgebung Visual
 \item Python Extension Pack (Django Code-Vervollständigung)
 \end{itemize}
 
-Der entwickelte Syntax wird regelmä"sig auf das hochschulinterne Git-Repository geladen. Hier kann man mit Hilfe der verwendeten IDE bei der Überarbeitung im sogenannten \textit {Working-Tree} die Änderungen visuell einsehen und wenn nötig bearbeiten. Es wird ausschlie"slich auf den Master-Branch gepusht, da nur ein Entwickler an dem Prototyp tätig ist. Lediglich zum Testen experimenteller Bibliotheken werden eine Branches angelegt und diese, falls Sie sich als hilfreich erweisen, in den Master-Branch gemerged.---
+Der entwickelte Syntax wird regelmä"sig auf das hochschulinterne Git-Repository geladen. Hier kann man mit Hilfe der verwendeten IDE bei der Überarbeitung im sogenannten \textit {Working-Tree} die Änderungen visuell einsehen und wenn nötig bearbeiten. Es wird ausschlie"slich auf den Master-Branch gepusht, da nur ein Entwickler an dem Prototyp tätig ist. Lediglich zum Testen experimenteller Bibliotheken werden neue Branches angelegt und diese, falls Sie sich als hilfreich erweisen, mit dem Master-Branch fusionieren.
 
-Um einen generellen Einblick in den Aufbau eines Django-Projektes zu erlangen wird dies im folgenden genauer beschrieben.
-
-Grundlegender Aufbau der Website, Verwaltung der Daten evlt nochmal auf Taggable-Manager (ManyToMany) ...
+Um einen Einblick in den Aufbau eines Django-Projektes zu erlangen wird dies im folgenden genauer beschrieben. Die unterste Projektebene wird durch die manage.py-Datei gebildet. Sie wird unter Anderem genutzt um den lokalen Server starten zu können. In der Ebene darüber findet sich im Ordner \glqq mysite\grqq\ die Datei settings.py. Hier werden die allgemeinen Einstellungen der Website vorgenommen, wie zum Beispiel das Integrieren der Erweiterungen und der Pfad zu den hinterlegten Templates. Au"serdem ist die urls.py dort zu finden, deren Funktion bereits im Kapitel Django erläutert wurde. Die \_\_init\_\_.py und wsgi.py sind trivial und deshalb wird hier nicht weiter darauf eingegangen. Im Ordner \glqq thisisenv\grqq\ sind alle Bibliotheken und Add-on's der virtuellen Umgebung hinterlegt. Der Fokus dieser Arbeit liegt im Ordner \glqq application\grqq. Hier sind die Datenbank-Migrationen, die Static-Files wie bootstrap und css, und alle Templates abgelegt. Zudem befindet sich hier die Logik des Prototypen, auf die im Kapitel \glqq Funktionen\grqq\ weiter eingegangen wird.
 
 
 \subsection{Datenmodellierung}
@@ -47,11 +45,11 @@ werden die neun Tabellen der Modelle erstellt. Um diese dann auch anwenden zu k
 
 \textbf{UserModel:}
 \begin{addmargin}[25pt]{0pt} 
-Hierbei ist das Authentifizierungssystem von Django mit einem \textit{UserModel} bereits angelegt. Dies muss für den Prototyp um das Feld \glqq tags \grqq erweitert werden, sodass ein Benutzer folgende Felder aufweist (vgl. [Fou18a]):
+Hierbei ist das Authentifizierungssystem von Django mit einem \textit{UserModel} bereits angelegt. Dies muss für den Prototyp um das Feld \glqq tags \grqq\ erweitert werden, sodass ein Benutzer folgende Felder aufweist (vgl. [Fou18a]):
 \begin{itemize}
 \item username, fist\_name, last\_name, email, groups, user\_permissions, is\_staff, is\_active, is\_superuser, last\_login, date\_joined, tags
 \end{itemize}
-In models.py ist der \textit{CustomUser} dafür verantwortlich das neue Feld mit dem \textit{Default-User} zu verknüpfen. Durch das \textit{OneToOneField} (siehe Abbildung 3.2.) wird die Verbindung zum schon bestehenden Modell hergestellt. \textit{OneToOne} bildet eine einzigartige Verbindung von zwei Objekten, sodass der Rückgabewert nur aus einem Objekt besteht (vgl. [Fou18a]). Das hei"st, dass bei dieser Verbindung keine Rekursiven, also ---blaaaa oder \textit{lazy} Beziehungen möglich sind um Konflikte bei der Authentifizierung zu vermeiden. Dies ist die übliche Vorgehensweise um mit einem Primärschlüssel das Default-Model zu erweitern. 
+In models.py ist der \textit{CustomUser} dafür verantwortlich das neue Feld mit dem \textit{Default-User} zu verknüpfen. Durch das \textit{OneToOneField} (siehe Abbildung 3.2.) wird die Verbindung zum schon bestehenden Modell hergestellt. \textit{OneToOne} bildet eine einzigartige Zuordnung von zwei Objekten, sodass der Rückgabewert nur aus einem Objekt besteht (vgl. [Fou18a]). Das hei"st, dass hier keine Rekursiven, also auf sich selbst verlinkende oder \textit{lazy} Beziehungen möglich sind um Konflikte bei der Authentifizierung zu vermeiden. Dies ist die übliche Vorgehensweise um mit einem Primärschlüssel das Default-Model zu erweitern. 
 \begin{figure}[!h]
 \centering
 \includegraphics[width=1\textwidth]{figures/custommodelcode}
@@ -75,11 +73,18 @@ Der Autor ist durch einen \textit{ForeignKey} mit dem \textit{UserModel} verbund
 
 \textbf{Gesamtmodellierung:}
 \begin{addmargin}[25pt]{0pt} 
+
+\begin{figure}[!h]
+\centering
+\includegraphics[width=0.8\textwidth]{figures/datamodel}
+\caption{Forschungsdesign}
+\hfill
+\end{figure} 
 \end{addmargin}
 	
 
 \subsection{Verwaltung im Administrator-Back-end}
-In diesem Kapitel wird beschrieben wie das Administrations-back-end genutzt werden kann. Es ist jedoch zu beachten, dass die Applikation vorwiegend von Dozenten und Angestellten der Hochschule ohne Administratorrechte verwendet werden soll. Die gestaffelten Berechtigungen werden im Kapitel \glqq Berechtigung der User \grqq genauer beschreiben.
+In diesem Kapitel wird beschrieben wie das Administrations-back-end genutzt werden kann. Es ist jedoch zu beachten, dass die Applikation vorwiegend von Dozenten und Angestellten der Hochschule ohne Administratorrechte verwendet werden soll. Die gestaffelten Berechtigungen werden im Kapitel \glqq Berechtigung der User \grqq\ genauer beschreiben.
 
 Ein Django-Projekt bildet bereits beim Einrichten, \textit{per Default}, eine Administrator-Oberfläche um die Inhalte der Website kontrollieren zu können. Nach der Migration von den oben genannten Modellen wird diese erweitert. Nich zu vergessen sind die externen Tabellen der installierten Add-on's, die nach der Migration das Back-end expandieren.