90 lines
5.2 KiB
TeX
90 lines
5.2 KiB
TeX
\section{Aufbau}
|
|
|
|
\subsection{Architektur}
|
|
|
|
\subsubsection{Aufteilung in Pakete}
|
|
|
|
Das Backend wird in Pakete aufgeteilt, die den einzelnen implementierten
|
|
\Glspl{api} der gpodder.net \Gls{api} entsprechen.
|
|
Dies entspricht hier den \Glspl{api}: Subscriptions, Episode Actions und Authentication.
|
|
Außerdem gibt es ein Model-Paket, welches die in den Logikschichten verwendeten Objekte modelliert.
|
|
|
|
Für den Webserver selbst werden die \Glspl{api} um zusätzliche Funktionen erweitert. Denn die vorhandenen \Glspl{api} bieten nicht alle Funktionalitäten, die der Webserver benötigt, um die im Pflichtenheft beschriebenen Kriterien zu erfüllen.
|
|
% (TODO: WebAPI bestimmen)
|
|
|
|
\subsubsection{Die Architektur in den Paketen}
|
|
|
|
In den Paketen selber herrscht eine 3-schichtige Architektur aus den Schichten: Controller, Service und Data-Access (siehe \ref{DAO_Pattern}).
|
|
|
|
Die Controller-Schicht nimmt die Anfragen des Clients entgegen, lässt diese in den untergeordneten Schichten verarbeiten und gibt den Status der abgeschlossenen Handlung an den Client zurück.
|
|
|
|
Die Service-Schicht ist die \Gls{business} des Programmes und überprüft bspw. Eingaben oder verschickt E-Mails. Sollte ein \Gls{db}aufruf nötig sein, so ruft der Service die Data-Access-Schicht auf und übergibt ihr die nötigen Informationen, was gespeichert, gelöscht, aktualisiert oder gelesen werden soll.
|
|
|
|
Die Data-Access-Schicht ist für den Datenzugriff auf \Glspl{db} verantwortlich. Alle verantwortlichen Klassen für einen solchen Zugriff folgen dem \Gls{crud}-Prinzip.
|
|
\Gls{crud} steht für die Funktionen Create (erschaffen), Read (lesen), Update (aktualisieren) und Delete (löschen). Entsprechend können Einträge in einer \Gls{db} auch nur erschaffen, gelesen, aktualisiert und gelöscht werden.
|
|
|
|
\subsubsection{Das Model-Paket}\label{p:model}
|
|
|
|
In einem globalen Model-Paket befinden sich alle Klassen, die für die Modellierungen von Objekten zuständig sind.
|
|
Diese Objekte werden später in \Gls{db}abfragen gelesen und mittels objektrelationaler Abbildung (siehe \ref{t:orm}) gespeichert.
|
|
In einer Antwort an den Client werden die Objekte, falls benötigt, als Antwort-Klassen gewrappt im \Gls{json}-Format zurückgeschickt.
|
|
Auch kann der Client in einer Anfrage ein Objekt im \Gls{json}-Format übergeben, welches dann mithilfe von Spring als \Gls{java}-Objekt der korrespondierenden Anfrage-Klasse interpretiert wird.
|
|
Aus diesem wird dann in Controller- und Service-Schicht das Objekt der entsprechenden Model-Klasse extrahiert.
|
|
|
|
\subsubsection{Die Datenhaltungsschicht}
|
|
|
|
Mit den Paketen ist bereits eine 3-schichtige Architektur aufgebaut.
|
|
Damit Daten aber auch gelesen und gespeichert werden können ist eine vierte globale Schicht nötig - die Datenhaltungsschicht.
|
|
|
|
Die Datenhaltungsschicht ist für die persistente Speicherung aller Daten zuständig.
|
|
Diese werden meist (wie in diesem Fall) in einer \Gls{db} gespeichert.
|
|
Der Zugriff auf die Datenhaltungsschicht erfolgt gemäß der intransparenten Schichtenarchitektur nur über die Data-Access-Schicht der Pakete.
|
|
|
|
Der Vorteil dieser mehrschichtigen Architektur ist die klare Strukturierung des Programmes, womit der Code leserlicher und einfacher zu warten ist.
|
|
|
|
\begin{landscape}
|
|
|
|
\subsection{Klassendiagramm Backend}
|
|
Das Klassendiagramm zeigt alle für den Entwurf relevanten Klassen des Backends mit ihren öffentlichen Methoden.
|
|
Weiter zeigt das Diagramm die Aufteilung der Klassen in Pakete sowie schemenhaft dargestellte Verbindungen zu \Gls{db} und Webserver.
|
|
|
|
% \input{assets/diagrams/classdiagram.latex}
|
|
\includegraphics[width=\linewidth]{assets/diagrams/classdiagram}
|
|
\end{landscape}
|
|
|
|
\subsection{Sequenzdiagramme}
|
|
|
|
\subsubsection{Authentication \Gls{api}}
|
|
\subsubsection*{Registrierung \scriptsize{(\ref{a:register})}}
|
|
\includegraphics[width=\textwidth]{assets/diagrams/sequencediagram-register}
|
|
\subsubsection*{Passwort vergessen und zurücksetzen \scriptsize{(\ref{a:forgot}, \ref{a:resetpassword})}}
|
|
\includegraphics[width=\textwidth]{assets/diagrams/sequencediagram-forgotAndResetPW}
|
|
|
|
\subsubsection{Subscriptions \Gls{api}}
|
|
\subsubsection*{Abonnements hochladen \scriptsize{(\ref{a:uploadSubs})}}
|
|
\includegraphics[width=\textwidth]{assets/diagrams/sequencediagram-uploadSubscriptions}
|
|
|
|
\subsubsection*{Abrufen aller Abonnements \scriptsize{(\ref{a:getSubs})}}
|
|
\includegraphics[width=\textwidth]{assets/diagrams/sequencediagram-getSubscriptions}
|
|
|
|
\subsubsection{Episode Actions \Gls{api}}
|
|
\subsubsection*{Episode Actions hochladen \scriptsize{(\ref{a:uploadEpisodeActions})}}
|
|
\includegraphics[width=\textwidth]{assets/diagrams/sequencediagram-uploadEpisodeActions}
|
|
|
|
\subsubsection*{Abrufen aller Episode Actions seit einem Zeitpunkt \scriptsize{(\ref{a:getEpisodeActions})}}
|
|
\includegraphics[width=\textwidth]{assets/diagrams/sequencediagram-getEpisodeActionsOfPodcastSince}
|
|
|
|
\subsubsection*{Abrufen aller Episode Actions \scriptsize{(\ref{a:getEpisodeActions})}}
|
|
\includegraphics[width=\textwidth]{assets/diagrams/sequencediagram-getEpisodeActions}
|
|
|
|
\subsection{Komponentendiagramm Backend}
|
|
\includegraphics[width=\textwidth]{assets/diagrams/backendComponentDiagram}
|
|
|
|
\subsection{Verteilungsdiagram}
|
|
\includegraphics[width=\textwidth]{assets/diagrams/deployment}
|
|
|
|
\subsection{\Gls{db}-Modell}
|
|
|
|
\includegraphics[width=\textwidth]{assets/diagrams/db}
|
|
|