Add overview

chapters/evaluation/evaluation.tex

@@ -7,6 +7,7 @@ Dafür wird für jedes Zustandsverwaltungssystem die Anwendung vollständig impl
 Im darauf folgenden Kapitel werden dann die kumulierten Ergebnisse analysiert und ein Fazit gezogen. 
 
 \section{setState}
+\label{eval:setstate}
 
 Das erste zu evaluierende Zustandsverwaltungssystem stellt die in  \autoref{sec:setState} beschriebe Vorgehensweise zur Verwaltung des Zustands dar.
 
@@ -15,3 +16,21 @@ Dieser Ansatz konnte nicht die Mindestanforderungen an die Beispielanwendung ums
 %Navigation per Routen-Namen nicht möglich, da es erforderlich ist, dass a
 
 \input{chapters/evaluation/inheritedwidget.tex}
+
+\newpage
+\section{Übersicht}
+
+\newcommand{\cmark}{\ding{51}}%
+\newcommand{\xmark}{\ding{55}}%
+\begin{longtable}[]{@{}l|llllllll@{}}
+    \toprule
+    Zustandsverwaltung & \rot{Änderbarkeit/Skalierbarkeit} & \rot{Testbarkeit} &
+    \rot{Effizienz} & \rot{Komplexität/Wartbarkeit} & \rot{Verständlichkeit/Lesbarkeit} &
+    \rot{Dokumentierung} & \rot{Strukturbestimmung} \\
+    \midrule
+    \endhead
+    setstate & \multicolumn{8}{c}{nicht umsetzbar} \\
+    inheritedwidget & / & TBD & TBD & TBD & TBD & TBD & TBD & TBD \\
+    \bottomrule
+    \multicolumn{9}{c}{Legende: \cmark=vollständig erfüllt; /=teilweise erfüllt; \xmark=nicht erfüllt}
+\end{longtable}

chapters/evaluation/inheritedwidget.tex

@@ -1,4 +1,5 @@
 \section{InheritedWidget}
+\label{eval:inheritedwidget}
 
 Wie in \autoref{sec:inheritedWidget} beschrieben, stellen InheritedWidgets einen Lösung für das Zustandsverwaltung dar, die ohne externe Bibliotheken auskommt und somit nur Bordmittel des Flutter-Frameworks benutzen.
 
@@ -14,7 +15,13 @@ Der Funktionsumfang konnte dabei ohne Einschränkungen vollständig implementier
 
 Im folgenden Abschnitt wird die Implementierung mit InheritedWidget \autocite[branch=inheritedwidget]{repo} anhand der definierten Bewertungskriterien bewertet.
 
-\paragraph{\nameref{sec:changeablility}}
+\paragraph{\nameref{sec:changeablility}} Bei der Änderbarkeit und Skalierbarkeit wird dieses Zustandsverwaltungssystem mit \textquote{teilweise erfüllt} bewertet. 
+
+Eines der Merkmale von skalierbaren und änderbaren Zustandsverwaltungssystemen ist es, dass sich mehrere Zustände untereinander verknüpfen lassen. Dies ist hier eingeschränkt möglich, da um auf einen anderen Zustand zuzugreifen es erforderlich ist, dass dieser im Widget-Baum oberhalb des zugreifenden Zustandswidgets angeordnet ist. Falls dies der Fall ist, lässt sich der Zustand aber wie bei der Benutzeroberfläche (vgl. \autoref{sec:inheritedWidget}) über einen Methoden-Aufruf abrufen.
+
+Negativ bewertet wird hier aber die Tatsache, dass ein Zustand beziehungsweise Store immer aus mindestens drei Klassen bestehen muss. Dies macht es erforderlich, alle nach außen zugängliche Funktionen oder Variablen per Konstruktoraufruf von dem StatefulWidget zum InheritedWidget zu übergeben. Bei wachsender Größe eines Zustands wird dies unübersichtlich. 
+
+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}}
 

hdathesis.sty

@@ -47,6 +47,8 @@
 %*******************************************************************************
 \RequirePackage{amsmath}
 \RequirePackage{amssymb}
+\usepackage{amssymb}% http://ctan.org/pkg/amssymb
+\usepackage{pifont}% http://ctan.org/pkg/pifont
 \RequirePackage{theorem}
 \theoremstyle{plain} {
  \newtheorem{Theorem}{Theorem}