Add readability

chapters/analyse/analyse.tex

@@ -66,9 +66,9 @@ Für dieses Bewertungskriterium wird eine qualitative Bewertungsskala verwendet,
 
 Für die Testbarkeit sind diverse Blickpunkte von Relevanz. Zuerst sollte geprüft werden, inwiefern sich die mit dem Zustandsverwaltungssystem abgebildete Geschäftslogik testen lässt. Hier kann beispielsweise geprüft werden, ob es ohne Veränderung am Ausgangsquelltext möglich ist, einzelne Funktionen zu testen, die den Zustand verändern. Grundlage dafür sollten automatisierte Unit-Tests sein.
 
-Ein anderer Blickpunkt ist die Testbarkeit von Widgets, die auf geteilte Zustände zugreifen. Hier sollte zum einen geprüft werden, ob sich die Widgets vom Zustandsverwaltungssystem entkoppeln lassen und so eigenständig getestet werden können, und zum anderen sollte geprüft werden, ob die Zustände zum Test von Widgets einfach durch Platzhalter (engl. mocks) ausgetauscht werden können.
+Ein anderer Blickpunkt ist die Testbarkeit von Widgets, die auf geteilte Zustände zugreifen. Hier sollte geprüft werden, ob die geteilten Zustände zum Test von Widgets einfach durch Platzhalter (engl. mocks) ausgetauscht werden können.
 
-Ausgehend von der Prüfung dieser Eigenschaften, wird eine Bewertung von einer Skala von 0/3 bis 3/3 vorgenommen, wobei die Ziffer die Anzahl der erfüllten Prüfungen darstellt.
+Ausgehend von der Prüfung dieser Eigenschaften, wird eine Bewertung mit den Werten \textquote{nicht erfüllt}, \textquote{teilweise erfüllt} und \textquote{vollständig erfüllt} vorgenommen.
 
 \subsection{Effizienz}
 \label{sec:efficiency}

chapters/evaluation/evaluation.tex

@@ -22,7 +22,7 @@ Dieser Ansatz konnte nicht die Mindestanforderungen an die Beispielanwendung ums
 
 \newcommand{\cmark}{\ding{51}}%
 \newcommand{\xmark}{\ding{55}}%
-\begin{longtable}[]{@{}l|llllllll@{}}
+\begin{longtable}[]{@{}l|ccccccc@{}}
     \caption{Ergebnisse der Evaluation}\\
     \toprule
     Zustandsverwaltung & \rot{Änderbarkeit/Skalierbarkeit} & \rot{Testbarkeit} &
@@ -30,8 +30,8 @@ Dieser Ansatz konnte nicht die Mindestanforderungen an die Beispielanwendung ums
     \rot{Dokumentierung} & \rot{Strukturbestimmung} \\
     \midrule
     \endhead
-    setstate & \multicolumn{8}{c}{nicht umsetzbar} \\
-    inheritedwidget & / & TBD & TBD & TBD & TBD & TBD & TBD & TBD \\
+    setState & \multicolumn{7}{c}{nicht umsetzbar} \\
+    InheritedWidget & / & \cmark & 8;6 & 83 & \xmark & \xmark & \xmark  \\
     \bottomrule
-    \multicolumn{9}{c}{Legende: \cmark=vollständig erfüllt; /=teilweise erfüllt; \xmark=nicht erfüllt}
+    \multicolumn{8}{c}{Legende: \cmark=vollständig erfüllt; /=teilweise erfüllt; \xmark=nicht erfüllt}
 \end{longtable}

chapters/evaluation/inheritedwidget.tex

@@ -23,15 +23,56 @@ Negativ bewertet wird hier aber die Tatsache, dass ein Zustand beziehungsweise S
 
 Ein weiter Nachteil ist es, dass es erforderlich ist, im InheritedWidget eine Methode zu implementieren, die feststellt, ob sich der Zustand im Vergleich zu einem anderen Zustand verändert hat. Dies wird bei wachsender Größe oder Datenstrukturkomplexität eines Zustands unübersichtlich und auch komplex.
 
-\paragraph{\nameref{sec:testability}}
+\paragraph{\nameref{sec:testability}} Zur Bewertung der Testbarkeit wurden mehrere Tests entsprechend der Anforderungen implementiert. 
+
+Das Testen der Geschäftslogik der Stores stellte sich als komplex heraus, da hier keine Unit-Tests sondern Widget-Tests von Nöten waren. Dies hat auch zur Folge, dass man sich während der Tests auch um den Lebenszyklus der Widgets kümmern muss. So muss man im Test die Hilfs-Funktion \texttt{tester.pump()}, wie in \autoref{lst:testabilityInheritedWidget} zu sehen ist, zum richtigen Moment aufrufen, damit das Framework die Zustandsänderungen umsetzt.
+
+\begin{lstlisting}[caption={Aufbau eines einfachen Flutter-Widgets in Dart}, label={lst:testabilityInheritedWidget}]
+testWidgets('test cart store', (tester) async {
+    final widgetTree = ProductStore(
+      products: RemoteResource.finished(demoProducts),
+      child: CartStoreImplementation(child: Container()),
+    );
+    await tester.pumpWidget(widgetTree);
+    final cartStoreFinder = find.byType(CartStore);
+    expect(cartStoreFinder, findsOneWidget);
+    var cartStore = tester.widget<CartStore>(cartStoreFinder);
+    cartStore.increaseAmount(demoProducts.first);
+    await tester.pump();
+    cartStore = tester.widget<CartStore>(cartStoreFinder);
+    expect(cartStore.amountOfProduct(demoProducts.first), 1);
+});
+\end{lstlisting}
+
+Die Tests für Widgets, die den Zustand konsumieren auf der anderen Hand sind einfach umzusetzen, da die Geschäftslogik im besten Fall komplett von der Speicherung der emittierten Daten getrennt wird. So ist es möglich ein InheritedWidget ohne das dazugehörige StatefulWidget zu initialiseren und die benötigten Mock-Daten über den Konstruktor zu übergeben.
+
+Abschließend erfolgt hier die Bewertung mit \textquote{vollständig erfüllt}, da besonders die einfache Testbarkeit von konsumierenden Widgets die Nachteile bei dem Test für die Geschäftslogik ausgleicht. 
+
+\paragraph{\nameref{sec:efficiency}} Nach der Ausführung der Teststrecke, ergaben die Zähler folgendes Ergebnis: 
+\lstinputlisting[caption={Anzahl der Render-Vorgänge bei InheritedWidget}]{results/inheritedwidget/benchmarks.txt}
 
-\paragraph{\nameref{sec:efficiency}}
+\paragraph{\nameref{sec:complexity}} Die Auswertung der Metriken (vgl. \autoref{metrics:inheritedwidget}) ergab eine \ac{mi} von 83 für das gesamte Projekt.
 
-\lstinputlisting[caption={Anzahl der Render-Vorgänge bei InheritedWidget}]{results/inheritedwidget/benchmarks.txt}
+\paragraph{\nameref{sec:readability}} Bei der Bewertung der Lesbarkeit sind mehrere Faktoren wichtig.
+
+Der erste Faktor ist die Frage, ob neue Konzepte eingeführt werden. Diese Frage kann mit nein beantwortet werden, da hier ausschließlich Komponenten aus dem Flutter-Framework in Form verschiedener Widgetes zum Einsatz kommen.
+
+Der zweite Faktor hierbei ist die Frage, inwiefern die Struktur klar nachvollziehbar und verständlich ist. Dies ist bei InheritedWidgets nicht der Fall, da besonders die Konstruktion aus mehreren Widgets und Widget-Typen schwer nachvollziehbar ist. So gibt es keinen zentralen Ort, welcher die Geschäftslogik übersichtlich zusammenfasst. Im Gegenteil ist es hier notwendig, die Geschäftslogik als Teil eines StatefulWidgets zu implementieren, was die Lesbarkeit definitiv erschwert. Hinzu kommt der große Umfang an Boilerplate-Quelltext, da selbst für einfache Zustände wie das Speichern des Anmeldezustands drei Klassen benötigt werden.
+
+Der letzte Faktor befasst sich mit der tiefen Verschachtlung von Widgets (engl. Nesting). Nesting wirkt sich negativ auf die Lesbarkeit von Widgets aus. Auf Nesting kann allerdings bei diesem Ansatz nicht verzichtet werden, da InheritedWidgets in die Baumstruktur eingebaut werden, wie in \autoref{lst:nestingInheritedWidget} zu sehen ist, und somit immer ein Child-Widget übergeben bekommen. 
 
-\paragraph{\nameref{sec:complexity}}
+\begin{lstlisting}[caption={Nesting bei InheritedWidgets in app.dart \cite{repo}}, label={lst:nestingInheritedWidget}]
+return UserStoreImplementation(
+    child: ProductStoreImplementation(
+      productService: productService,
+      child: CartStoreImplementation(
+        child: child,
+      ),
+    ),
+);
+\end{lstlisting}
 
-\paragraph{\nameref{sec:readability}}
+Zusammengefasst wird die Verständlichkeit/Lesbarkeit mit \textquote{nicht erfüllt} bewertet.
 
 \paragraph{\nameref{sec:documentation}}