\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}

