thesis/chapters/realisation/realisation.tex

\chapter{Umsetzung und Realisierung}

Nachdem nun die Anforderungen an die Zustandsverwaltungssysteme definiert worden sind, bedarf es eines Versuchsaufbaus, um die Zustandsverwaltungssysteme einer Evaluation unterziehen zu können.

Um die Evaluation möglichst praxisnah zu gestalten, ist es sinnvoll, diese anhand einer Beispielanwendung durchzuführen. Dies bietet die Vorteile, dass die Zustandsverwaltungssysteme im Test realistischen Bedingungen unterzogen werden und somit die Aussagekraft der Evaluation höher ist. Dieses Vorgehen birgt allerdings das Risiko, dass andere Variablen, die nicht Teil der Evaluation sind, die Ergebnisse beeinflussen. Um dieses Risiko zu minimieren werden Maßnahmen getroffen, die sicherstellen sollen, dass ausschließlich die Auswirkungen der Implementierung mit einem Zustandsverwaltungssystem überprüft werden.


\section{Anforderungen an die Beispielanwendung}

Bevor nun eine solche Beispielanwendung konstruiert wird, ist es erforderlich, Anforderungen an diese zu definieren und darauf aufbauend einen Entwurf zu planen.

\subsection{Implizierte Anforderungen}

Die wichtigste Anforderung an die Beispielanwendung ist es, dass sie es ermöglicht eine Evaluation anhand der in \autoref{tab:criteria} definierten Kriterien durchzuführen. Im Folgenden sollte daher erst die Bewertungskriterien darauf untersucht werden, ob sie spezielle Anforderungen an eine Beispielanwendung stellen. Kriterien, die keine speziellen Anforderungen stellen, werden im Folgenden nicht weiter aufgeführt.

Bei der \nameref{sec:changeablility} ist es nötig, einen gewissen Grad von Kopplung von Zuständen zu erreichen, damit die entsprechende Funktion der Zustandsverwaltungssysteme getestet werden kann.

Zur Überprüfung der \nameref{sec:testability} ist es erforderlich, Widgets so zu erstellen, dass sie im Rahmen der Implementierung von automatisierten Tests diese Implementierung nicht behindern. Zudem sollte es Anwendungsfälle geben, die auch die Verarbeitung von Zuständen erfordert, um eine gewisse Art von Geschäftslogik mit den Zustandsverwaltungssystemen implementieren und im Anschluss testen zu können.

Die Messung der \nameref{sec:efficiency} erfolgt an verschiedenen Messpunkten. Daher ist es erforderlich, Widgets zur Verfügung zu stellen, die dafür geeignet sind. Besonders gut geeignet sind dabei Widgets, die außerhalb einer Listendarstellung sind, und somit unabhängig vom Rendering der Liste sind.

Um das Verhalten bei tiefer Verschachtlung (engl. nesting) für das Kriterium der \nameref{sec:readability} prüfen zu können, ist es erforderlich dieses zu provozieren. Am besten kann dies umgesetzt werden, indem es Seiten gibt, die mehrere voneinander unabhängige, seitenweite Zustände haben.

\subsection{Explizite Anforderungen}

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 Zustands-verä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 Produkt\-auswahl- und Warenkorb\-ansicht 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 Benutzeroberflä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 notwendig, 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.
  
Der gesamte Quelltext wird in einem Git-Repository \autocite{repo} öffentlich zur Verfügung gestellt.
\newpage
\section{Ergebnis der Beispielanwendung}

Die Beispielanwendung wurde im Material-Design mit Flutter in der Version 2.10.1 erstellt. Das Design weicht dabei nur leicht von dem in den Wireframes konzipierten Design ab, wie in \autoref{fig:realisation} zu sehen ist. 

Die Funktionen sind abgesehen von der Navigation noch nicht implementiert, da dies, wie beschrieben, durch die Implementierung mit den Zustandsverwaltungssystemen erfolgt.

\begin{figure}[h]%
    \centering
    \subfloat[\centering Produktliste]{{\includegraphics[width=.4\linewidth]{chapters/realisation/product_list.png} }}%
    \qquad
    \subfloat[\centering Warenkorb]{{\includegraphics[width=.4\linewidth]{chapters/realisation/cart.png} }}%
    \caption{Umsetzung der Wireframes in Flutter unter iOS}%
    \label{fig:realisation}%
\end{figure}

\subsection{Versuchsaufbau}

Neben den sichtbaren Elementen der Anwendung wurde auch eine Infrastruktur zur Durchführung der Messung für die \nameref{sec:efficiency} und \nameref{sec:complexity} geschaffen.

Die Messung der \nameref{sec:complexity} erfolgt über die Metrik des \acl{mi}. Dieser Wert wird mit dem Tool \texttt{dart\_code\_metrics} ermittelt. Um die Berechnung unabhängig von der Laufzeitumgebung zu machen, wird die Berechnung in einem Docker-Container mit einem \ac{ci} durchgeführt. Die einzelnen Durchführungsschritte sind dabei in der \ac{ci}-Konfigurationsdatei \autocite[.drone.yml]{repo} im Unterschritt \texttt{generate\_metrics} dokumentiert. Die vollständigen Testergebnisse sind dieser Ausarbeitung im Anhang beigefügt.

Für die Messung der \nameref{sec:efficiency} wird an zwei Messpunkten gemessen, wie oft ein Widget neu gebaut werden muss. Dazu wird ein Zähler erhöht, wenn die Build-Methode des entsprechenden Widgets aufgerufen worden ist. Zur Messung wird ein automatisierter Test \autocite[test/\-efficiency\_\-bechmark\_\-test\-.dart]{repo} durchgeführt, welcher mehrere Produkte zum Warenkorb hinzufügt und wieder entfernt, und die An- und Abmeldung des Benutzenden auslöst. Im letzten Schritt wird zur Warenkorbansicht navigiert. 

Die beiden Messpunkte wurden dabei an folgenden Stellen angebracht. Der erste Messpunkt \texttt{cartButton} wird ausgelöst beim Rendern des Warenkorb-Buttons und der zweite Messpunkt \texttt{userSwitch} wird ausgelöst beim Rendern des Schalters zum An- und Abmelden. Diese beiden Widgets wurden gewählt, da sie von Zustandsänderungen betroffen sind, allerdings nicht von allen Zustandsänderungen der Anwendung und außerhalb einer Listenansicht sind.

Beim Ausführen des Tests für die beschriebene Basisanwendung ohne Zustandsverwaltung wurde folgendes Ergebnis ermittelt:

Anzahl der Rendervorgänge:

\lstinputlisting[caption={Anzahl der Rendervorgänge}]{results/main/benchmarks.txt}

Diese Ergebnisse stellen die Minimalwerte für den Test dar.

% * Anforderungen an die Beispielanwendung (/)
% * Beschreibung der Beispielanwendung (/)
% * Skizze der Beispielanwendung (/)
% * Vorgehen beim Implementieren (/)
% * Ergebnis der Beispielanwendung (/)
% * Beschreibung des Versuchsaufbaus (/)