social_media_platform/doc/bachelorarbeit_EstherKleinhenz/chapters/prototyp.tex

\chapter{Prototyp}
\label{ch:prototyp}
Um die wissenschaftliche Frage, nicht nur zu beantworten, sondern zu beweisen, wird in dieser Arbeit die Methode des Prototypings genutzt. Der Prototyp dient zum experimentellen Arbeiten und sichert eine strukturell fundierte Umsetzung des darauf folgenden Endprodukts. Der Fokus liegt dabei zunächst auf der Funktionalität der Anwendung. Prototyping wird als bevorzugte Methode gewählt um schnell ein Ergebnis zu erzielen (vgl. [Abr16]). Zudem soll aufbauend auf Diesem ein Produkt realisiert werden, das als Erweiterung in das Netzwerk der Hochschule integriert werden soll.

\section{Forschungsdesign}
Das Kapitel zeigt eine kurze Übersicht der Vorgehensweise und den Leitfaden an den sich die Implementierung des Prototyps anlehnt (vgl. Abbildung 3.1.). 
Zu Beginn der Arbeit wird, des sich aus der Forschungsfrage ergebenden Problems analysiert und alle wichtigen Anforderungen erfasst. Dies bildet die Basis für alle weitern notwendigen Schritte um am Ende eine sinnvolle Lösung bereitstellen zu können. Die Recherche dient der Sammlung aller notwendigen Werkzeuge und gibt einen Überblick über verschiedene Hilfsbibliotheken. Das Implementieren der Applikation kann nun auf Basis der Recherche durchgeführt werden. Dazu gehört das Testen verschiedener Bibliotheken und Erweiterungen um die bestmögliche Ergebnis zu eruieren. Abschlie"send wird die Funktionalität des Prototypen getestet und evaluiert ob die Forschungsfrage ausreichend beantwortet wird. Handlungsempfehlungen und mögliche Funktionen zum Erweitern finalisieren die Arbeit.

\begin{figure}[!h]
\centering
\includegraphics[width=0.8\textwidth]{figures/forschungsdesign}
\caption{Forschungsdesign}
\hfill
\end{figure} 

\section{Organisation}

Zum Entwickeln des Prototypen wird die Open-Source- Entwicklungsumgebung Visual Studio Code von Microsoft verwendet. Die dynamische Oberfläche ist sehr performant, da sie wenig Speicherplatz bedarf und zunächst ohne grö"sere Ergänzungen sofort einsetzbar ist. Um den Code mit Shortcuts übersichtlicher zu gestalten und auf Python und Django abstimmen zu können werden aus der üppigen \textit{Extension-Bibliothek} kostenlose Erweiterungen eingebunden. Unter Anderem sind die folgenden Add-on's während der Arbeit zum Einsatz gekommen (vgl. [Mic18]):

\begin{itemize}
\item Python von Microsoft (Linting und Debugging)
\item MagicPython von MagicStack Inc. (Syntax-Highlighter)
\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 neue Branches angelegt und diese, falls Sie sich als hilfreich erweisen, mit dem Master-Branch fusionieren.

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}
Die Struktur der bereits bestehenden Datenbank im Django-Framework und die Erweiterungen dessen werden hier genauer erläutert. Zunächst wird auf die Ergänzung des bestehenden \textit{UserModel} eingegangen, nachdem veranschaulicht der Abschnitt das \textit{PostModel} und abschlie"send werden die Zusammenhänge der Modelle dargestellt.

Alle Modelle werden als Django-Modelle deklariert um beim kompilieren des Codes dem Compiler mitzuteilen, dass diese integriert werden müssen (vgl. [Dja18]). Mit der folgenden Eingabe 
\\
\noindent\hspace*{10mm}%
\$ python3 manage.py makemigrations
\\
werden die neun Tabellen der Modelle erstellt. Um diese dann auch anwenden zu können, muss der Befehl 
\\
\noindent\hspace*{10mm}%
\$ python3 manage.py migrate
\\
 darauffolgend ebenso in die Kommandozeile eingegeben werden.\\ 


\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]):
\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}
Das Feld \textit{groups} wird in dieser Arbeit nicht verwendet und deshalb im Folgenden ignoriert.

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}
\caption{CustomUserModel in models.py}
\hfill
\end{figure} 


\end{addmargin}

\textbf{PostModel:}
\begin{addmargin}[25pt]{0pt} 
Das \textit{PostModel} beschreibt alle Felder die ein Post enthalten kann. Basierend auf der Blog-Lösung von Djangogirls.com gehören dazu folgende:
\begin{itemize}
\item author, title, text, created\_date, published\_date, tags
\end{itemize}
Der Autor ist durch einen \textit{ForeignKey} mit dem \textit{UserModel} verbunden. Diese sogenannte \textit{ManyToOne} Verbindung reicht hier aus um einem Post den Autor, also dem eingeloggten User, zuzuweisen. Title ist ein \textit{CharField} und wird mit einer Zeichenbegrenzung festgelegt. Der Text hingegen kann eine beliebige Menge an Zeichen enthalten und wir deshalb als \textit{TextField} deklariert. Erstellungsdatum und Publikation sind beides \textit{DateTimeField}s. Ersteres muss vom Ersteller angegeben werden, Zweiteres kann zunächst offen gelassen werden durch die Zusatzangabe \glqq null=True\grqq. Ein weiteres Feld tags wird hinzugefügt um den Posts unabhängig von den Usern Tags zuordnen zu können.
\\
\end{addmargin}


\textbf{Gesamtmodellierung:}

\begin{addmargin}[25pt]{0pt} 
Die Abbildung 3.3. zeigt die Modellierung der Tabelle \glqq User\grqq\ und \glqq Post\grqq. Au"serdem verdeutlicht es die Erweiterung des User-Modells von Django mit dem in der Applikation angelegtem CustomUser. Die im User vorkommenden booleschen Felder werden im Kapitel Berechtigung der User genauer erörtert. 
\begin{figure}[!h]
\centering
\includegraphics[width=0.9\textwidth]{figures/datamodel}
\caption{Datenmodellierung von User und Post}
\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.

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.


\subsection{Berechtigung der User}
Im Allgemeinen verwendet man Berechtigungen um Benutzern Zugang zu bestimmten Resourcen in einem Netzwerk einzuräumen. Au"serdem bestimmt es die Arte des Zugangs, also ob der User die Resourcen nur lesen oder auch verändern oder löschen darf(vgl. [Com18]). Die Rechte werden meist einzelnen Individuen oder einer Gruppe zugeordnet.

Das gestaffeltes Berechtigungsmanagement ist im Prototyp notwendig um den Umgang mit Informationen so sicher wie möglich zu gestalten und um die Nachhaltigkeit dieser zu bewahren. Des Weiteren soll der Prototyp als Vorlage für die Erweiterung der Hochschulwebsite dienen und daher ist eine ähnliche Verteilung der Zugangsberechtigungen sinnvoll. 

Studenten sollen zunächst Informationen weder einpflegen, noch editieren dürfen. Die einzigen Änderungen die sie vornehmen können sind auf Ihre eigene Datenbank fokussiert. Das Hinzufügen von Tags um die damit verbunden Posts auf dem persönlichen Dashboard zu sehen wird ihnen gewährleistet. Dies soll verhindern, dass Informationen nicht zu leichtfertig geändert oder gelöscht werden. 

Dozenten und Angestellte der Hochschule sind dazu berechtigt, Posts zu erstellen, zu editieren und wieder zu löschen. Zudem können sie, wie Studenten, Tags abonnieren und somit ebenso das persönliche Dashboard gestalten. Das Einloggen in die Administratoroberfläche kann vorgenommen werden, jedoch sind der Gruppe noch keinerlei Rechte zugewiesen. Möchte man dies ändern, kann man das von Django bereitgestellte Feld \glqq User Permissions\grqq\ im Admin-back-end unter Users, und dem Namen der Person, die gewünschte Berechtigung zuteilen. Diese sind von Django vorgegeben und betreffen alle vorhandenen Modelle der Applikation. Soll ein User zum Beispiel erlaubt sein einen Tag aus dem Archiv zu löschen, so wählt er das Feld \glqq taggit \textbar Tag \textbar can delete Tag\grqq\ und schiebt es von der Auswahl zu den Berechtigungen.
Durch das Setzen des booleschen Wert \glqq is\_staff\grqq\ auf \glqq True\grqq\ beim Erstellen der Benutzer, ist es möglich im Code der Applikation Abfragen durchzuführen. Dadurch lassen sich bestimmte Views  an die eingeloggte Personengruppe anpassen. So ist das Menü für Dozenten und Angestellte ein umfangreicheres als das, der Studenten.


\section{Funktionen}
Um die wichtigsten Funktionen des Prototypen festlegen zu können werden User Stories erstellt (vgl. Abbildung 3.4.). Diese bestehen aus kurzen Sätzen und beschreiben aus Sicht des Nutzers das Verwenden einer Funktion. Die Priorisierung bezieht sich hierbei auf die Relevanz der Funktion, wobei die Funktionen mit einem rotem Punkt sehr wichtig für den Prototypen sind, Orang wichtige Funktionen sind aber nicht unbedingt notwendig und Grün kaum relevant sind.

\begin{figure}[!h]
\centering
\includegraphics[width=0.9\textwidth]{figures/userstories}
\caption{User Stories}
\hfill
\end{figure} 

\subsection{Verwalten}
Das Verwalten der Artikel soll von berechtigten Nutzern hauptsächlich im Front-end stattfinden. Der Vorgang des Erstellens, des Löschens und des Editierens der einzelnen Einträge wird im Folgenden konkretisiert.

Ein neuer Artikel wird erstellt. Das \glqq +\grqq\ in der Menüleiste leitet den Benutzer zu einer Unterseite. Hier können alle Felder befüllt werden, die im PostForm-Formular in der Datei forms.py festgelegt wurden. Dazu gehören der Titel und der Text, die als Pflichtfelder gelten. Das Feld \glqq Tags \grqq\ muss ebenfalls mindestens einen Wert enthalten um die Validierung der Eingaben sichern zu können. Eine Ausnahme bildet das Datum der Veröffentlichung. Bleibt das Feld leer so wird der Post automatisch der Liste der Entwürfe beigefügt. 

Die eindeutige Zuordnung der Eingabe im Front-end zur Verarbeitung der verschiedenen Artikel im Back-end ist mit einem \textit{Primary Key} realisiert. In der View \glqq post\_new \grqq\ wird zunächst die Validität aller Eingaben geprüft. Falls dies der Fall ist, wird der Post als Objekt zurückgegeben, jedoch durch das optionale \textit{Keywort} \glqq commit=false \grqq\ noch nicht in der Datenbank abgelegt. Das ist notwendig um dem Objekt spezifische Informationen mitzugeben. In diesem Kontext wird der aktuell eingeloggte User als Autor hinterlegt. Jedoch birgt die Vorgehensweise eine Problematik im Speichervorgang einer \textit{ManyToMany} Relation zwischen zwei Modellen. Da Informationen nur auf ein bereits in der Datenbank bestehendes Objekt gesichert werden können ist dies zunächst nicht möglich.
Im Prototyp nutzt das \textit{PostModel} die \textit{ManyToMany} Konnektivität mit dem Modell des TaggabelManagers. Um die Eingabe des Tag-Felds trotzdem im neuen Artikel speichern zu können, wird zunächst das Objekt gespeichert, um nachdem explizit das von Django zur Verfügung gestellte \glqq form.save\_m2m() \grqq\ aufrufen zu können. 
--- pk erklären


\subsection{Abonnieren}
Tags als eingeloggter User abonnieren und verwalten Front-end und Admin-Backend?

\subsection{Filtern}
Tag-map? Filtern nach abonnierten Posts, alle Posts und Posts mit bestimmten Tags

\subsection{Benachrichtigung}
Mail-Benachrichtigung wöchentlich