Add details for the implementation

chapters/realisation/realisation.tex

@@ -23,11 +23,58 @@ Um das Verhalten bei tiefer Verschachtlung (engl. nesting) für das Kriterium de
 
 \subsection{Explizite Anforderungen}
 
-Nachdem 
+Nachdem nun die impliziten Anforderungen definiert worden sind, sollten nun weitere Anforderungen an die Beispielanwendung gestellt werden, um andere Faktoren mitberücksichtigen zu können. In dieser Untersektion werden nun andere explizite Anforderungen aufgestellt, die dafür sorgen sollen, dass ein möglichst praxisnahe Evaluation entsteht und somit ein realistisches Szenario getestet werden kann.
+
+Die Beispielanwendung sollte so mehrere Seiten haben, um das Verhalten der Zustandsverwaltung auch nach einer Navigation testen zu können. Hier ist es wichtig, dass auf allen Seiten in der App die Daten persistent sind, und sich nicht unterscheiden.
+
+In einer mobilen Anwendung werden oft Eingabemöglichkeiten für Nutzer*innen bereitgestellt, die den Zustand der Anwendung verändern. Daher sollte auch diese Beispielanwendung eine Form von zustandsverändernden Interaktion besitzen. 
+
+Auch das Laden von Daten für den Anwendungszustand aus anderen Quellen wie beispielsweise von einem Server sollte implementiert werden, damit im gleichen Zug auch getestet werden kann, was im Falle einer Zeitüberschreitung oder eines Verbindungsfehlers passiert und wie die Fehlerbehandlung der Zustandsverwaltung funktioniert.
+
+\section{Konzeption einer Beispielanwendung}
+
+Anhand der aufgestellten Kriterien wird im folgenden Abschnitt die Beispielanwendung für die Evaluation konzipiert.
+
+Als Anwendungsfall für die Beispielanwendung wurde hier die Produktauswahl- und Warenkorbansicht eines Internetshops gewählt. Dieser Anwendungsfall bietet den Vorteil, das mit ihm alle gestellten Anforderungen umgesetzt werden können und gleichzeitig ein realistisches Szenario zum Einsatz gelangt. 
+
+Grundlage bildet eine Liste mit verschiedenen Produkten, die aus dem Internet geladen wird, aus der die Benutzer*innen eine gewisse Anzahl eines oder mehrerer Produkte in einen Warenkorb legen können. Zudem existiert eine Warenkorbansicht, in der alle Produkte und ein Gesamtpreis zu sehen sind, die sich aktuell im Warenkorb befinden. Hiermit werden bereits alle expliziten Anforderungen erfüllt.
+
+\subsection{Anwendung der impliziten Anforderungen}
+
+Aufbauend auf diesen Anwendungsfall werden nun einzelne Funktionen anhand der gestellten Anforderungen beschrieben.
+
+Um die Koppelung verschiedener Zustände testen zu können, wird in der Beispielanwendung die Möglichkeit angeboten, sich als registrierte*r Benutzer*in an- und abzumelden. Dies geschieht durch einen Schalter, welcher den aktuellen Anmeldezustand darstellt. Die Kopplung besteht nun darin, dass registrierten Benutzer*innen ein Rabatt von 20\% gewährt wird, und somit eine Kopplung zwischen der Berechnung des Warenkorbgesamtpreises und des Anmeldezustands notwendig wird.
+
+Gleichzeitig wird hier auch die Anforderung zum Testen der tiefen Verschachtlung (engl. nesting) erfüllt, da hier mehrere unabhängige Zustände auf einer Seite benötigt werden. 
+
+Durch die Berechnung des Warenkorbgesamtpreises wird zudem die Anforderung der Testbarkeit umgesetzt, da hier ein geforderter Anwendungsfall für die  Implementierung von Geschäftslogik in einem Zustand umgesetzt wird.
+
+Um die Messung der Effizienz umsetzen zu können, wird ein Button hinzugefügt, welcher anzeigt, wie viele Produkte sich im Warenkorb befinden. Dieser Button hat zusätzlich die Aufgabe nach Berührung zur Detailansicht des Warenkorbs zu wechseln. Da dieser Button außerhalb der Listendarstellung angebracht werden soll, ist er auch unabhängig von Änderungen dieser Liste.
+
+\subsection{Wireframes}
+
+Nachdem nun der Funktionsumfang der Anwendung beschrieben wurde, wird daraus eine Benutzer*innenoberfläche konzipiert. Dazu werden vor der Umsetzung in Flutter ein Entwurf anhand von Wireframes erstellt. Diese zeigen, wie in \autoref{fig:wireframes} dargestellt, die einzelnen Seiten (engl. screens) der App mit einem konsistenten Beispielzustand sowie die Navigationsmöglichkeiten, welche hier mit einem roten Pfeil angedeutet werden.
+
+\begin{figure}[h]
+    \centering
+    \includegraphics[width=\textwidth]{chapters/realisation/wireframes.png}
+    \caption{Wireframes der Beispielanwendung}
+    \label{fig:wireframes}
+\end{figure}
+
+\section{Vorgehen bei der Implementierung}
+
+Um diese Beispielanwendung für die Evaluation passend umsetzen zu können, ist eine nähere Beschreibung des Vorgehens bei der Implementierung von Nöten, um den späteren Versuchsaufbau nachvollziehen zu können.
+
+Für jedes zu evaluierende Zustandsverwaltungssystem muss eine eigene Anwendung entwickelt werden. Um sowohl den Aufwand der Implementierung zu verringern und die Vergleichbarkeit zu verbessern, bietet es sich an, eine gemeinsame Grundlage für alle Anwendungen zu schaffen. Diese sollte nur die Benutzeroberfläche mit Platzhaltern, sowie die Geschäftslogik zum Abrufen von Daten für die Produktliste beinhalteten.
+
+Hierfür wird das Versionsverwaltungssystem Git eingesetzt. Die einzelnen Anwendungen für die Zustandsverwaltungssysteme zweigen dabei von einem gemeinsamen Arbeitszweig ab und setzen darin ihre eigenen Anpassungen um.
+
+Außerdem wird in dem gemeinsamen Arbeitszweig die Versuchsvorrichtung für die Effizienz-Messung bereits vorbereitet, damit für alle Zustandsverwaltungssysteme das gleiche Messverfahren zum Einsatz kommen kann.
 
 % * Anforderungen an die Beispielanwendung (/)
-% * Beschreibung der Beispielanwendung
-% * Vorgehen beim Implementieren
-% * Skizze der Beispielanwendung
+% * Beschreibung der Beispielanwendung (/)
+% * Skizze der Beispielanwendung (/)
+% * Vorgehen beim Implementieren (/)
 % * Ergebnis der Beispielanwendung
 % * Beschreibung des Versuchsaufbaus