Development of an internal social media platform with personalised dashboards for students
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

prototyp.tex 6.3KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394
  1. \chapter{Prototyp}
  2. \label{ch:prototyp}
  3. 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.
  4. \section{Forschungsdesign}
  5. Das Kapitel zeigt eine kurze Übersicht der Vorgehensweise und den Leitfaden an den sich die Implementierung des Prototyps anlehnt (vgl. Abbildung 3.1.).
  6. 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.
  7. \begin{figure}[!h]
  8. \centering
  9. \includegraphics[width=0.8\textwidth]{figures/forschungsdesign}
  10. \caption{Forschungsdesign}
  11. \hfill
  12. \end{figure}
  13. \section{Organisation}
  14. Grundlegender Aufbau der Website, Verwaltung der Daten evlt nochmal auf Taggable-Manager (ManyToMany) ...
  15. \subsection{Datenmodellierung}
  16. 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.
  17. 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
  18. \\
  19. \noindent\hspace*{10mm}%
  20. \$ python3 manage.py makemigrations
  21. \\
  22. werden die neun Tabellen der Modelle erstellt. Um diese dann auch anwenden zu können, muss der Befehl
  23. \\
  24. \noindent\hspace*{10mm}%
  25. \$ python3 manage.py migrate
  26. \\
  27. darauffolgend ebenso in die Kommandozeile eingegeben werden.
  28. \textbf{UserModel:}
  29. \begin{addmargin}[25pt]{0pt}
  30. 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]):
  31. \begin{itemize}
  32. \item username, fist\_name, last\_name, email, groups, user\_permissions, is\_staff, is\_active, is\_superuser, last\_login, date\_joined, tags
  33. \end{itemize}
  34. 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.
  35. \begin{figure}[!h]
  36. \centering
  37. \includegraphics[width=1\textwidth]{figures/custommodelcode}
  38. \caption{CustomUserModel in models.py}
  39. \hfill
  40. \end{figure}
  41. \end{addmargin}
  42. \textbf{PostModel:}
  43. \begin{addmargin}[25pt]{0pt}
  44. Das \textit{PostModel} beschreibt alle Felder die ein Post enthalten kann. Basierend auf der Blog-Lösung von Djangogirls.com gehören dazu folgende:
  45. \begin{itemize}
  46. \item author, title, text, created\_date, published\_date, tags
  47. \end{itemize}
  48. 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.
  49. \end{addmargin}
  50. \textbf{Gesamtmodellierung:}
  51. \begin{addmargin}[25pt]{0pt}
  52. \end{addmargin}
  53. \subsection{Verwaltung im Administrator-Back-end}
  54. 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.
  55. 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.
  56. \subsection{Berechtigung der User}
  57. Welche Berechtigungen gibt es im Prototyp, welche werden vom Active Directory übernommen?
  58. \section{Funktionen}
  59. User Stories einbinden als Grafik
  60. \subsection{Verwalten}
  61. Posts erstellen, editieren und löschen
  62. (draft-list und post new für Mitarbeiter)
  63. \subsection{Abonnieren}
  64. Tags als eingeloggter User abonnieren und verwalten Front-end und Admin-Backend?
  65. \subsection{Filtern}
  66. Tag-map? Filtern nach abonnierten Posts, alle Posts und Posts mit bestimmten Tags
  67. \subsection{Benachrichtigung}
  68. Mail-Benachrichtigung wöchentlich