Add implicit requirements

chapters/analyse/analyse.tex

@@ -55,12 +55,14 @@ Wenn man nun die allgemeinen und spezifischen Anforderungen zusammenfasst, erhä
 Da nun die Anforderungen an Zustandsverwaltungssysteme feststehen, können jetzt Kriterien für die Bewertung der Systeme beziehungsweise der Umsetzung mit diesen Systemen definiert werden. Ziel dabei ist es, möglichst aussagekräftige, objektive Bewertungskriterien zu definieren. Die Kriterien sollen auf die jeweiligen Anforderungen einzahlen.
 
 \subsection{Änderbarkeit/Skalierbarkeit}
+\label{sec:changeablility}
 
 Um zu untersuchen, ob ein Zustandsverwaltungssystem skalierbar oder nicht aufwendig änderbar ist, muss untersucht werden, wie dieses mit einer wachsenden Größe des Zustands umgeht. Dabei ist ein entscheidendes Kriterium, wie effektiv sich diverse Zustände sich untereinander verknüpfen lassen. Es ist nämlich damit zu rechnen, dass bei einer größer werdenden Anwendung auch die Koppelung zwischen den einzelnen Zuständen zunimmt. 
 
 Für dieses Bewertungskriterium wird eine qualitative Bewertungsskala verwendet, welche die Änderbarkeit/Skalierbarkeit mit den Werten \textquote{nicht erfüllt}, \textquote{teilweise erfüllt} und \textquote{vollständig erfüllt} bewertet.
 
 \subsection{Testbarkeit}
+\label{sec:testability}
 
 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.
 
@@ -69,12 +71,14 @@ Ein anderer Blickpunkt ist die Testbarkeit von Widgets, die auf geteilte Zustän
 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.
 
 \subsection{Effizienz}
+\label{sec:efficiency}
 
 Die Effizienz eines Zustandsverwaltungssystem lässt sich auch dadurch messen, wie effizient es das Neubauen von Widgets nach Veränderungen orchestriert. So sollte ein Widget nur dann neugebaut werden, wenn dies durch eine das Widget betreffende Änderung des Zustands es verlangt. Andere Betrachtungen der Performance sind nur schwer zu messen, da sich andere Variablen wie die Architektur oder Verwendung innerhalb der Anwendung einen großen Einfluss darauf haben. 
 
 Geprüft werden soll dieses Verhalten an x verschiedenen Prüfstellen in der Anwendung, indem an diesen stellen Zähler eingesetzt werden, die zählen, wann das Widget neu gebaut wird. Dabei wird eine für alle Zustandsverwaltungssysteme gleiche automatische Teststrecke erstellt, welche sicherstellen soll, dass immer die exakt gleichen Bedienhandlungen vorgenommen werden. Damit lässt sich dann abschätzen, wie effizient die Zustandsverwaltungssysteme die Zustandsänderungen an die Widgets propagieren. Erstrebenswert hierbei ist es, ein möglichst geringen Wert bei den Zählern zu erreichen, wobei sichergestellt werden muss, dass dabei alle Systeme die Funktionalität richtig implementieren. 
 
 \subsection{Komplexität / Wartbarkeit}
+\label{sec:complexity}
 
 Zur Messung der Komplexität ist es auch möglich, die Komplexität eine Anwendung quantiativ zu messen. Für diesen Anwendungsfall werden in der Literatur diverse Verfahren und Metriken beschrieben. Die Metrik \ac{mi} kombiniert dabei diverse Metriken und gewichtet sie. Im Detail wird wie in \autoref{eqn:mi} dargestellt, das durchschnittliche Halstead-Volumen ($aveV$), die durchschnittliche zyklomatische Komplexität ($aveVG2$) und die durchschnittliche Anzahl der Quelltextzeilen ($aveLOC$) verwendet. \autocite[133]{mi} Aufbauend auf dieser Kombination von Metriken soll eine ein-wertige Metrik geschaffen werden, die zum Ausdruck bringt, wie wartbar eine Software ist. \autocite[129]{mi}
 
@@ -101,6 +105,7 @@ Diese Metrik wird dabei als Bewertungsmaßstab verwendet und mit erklärenden Au
 %https://dartcodemetrics.dev/docs/metrics/maintainability-index
 
 \subsection{Verständlichkeit / Lesbarkeit}
+\label{sec:readability}
 
 Die Lesbarkeit und Verständlichkeit eines Quelltext lassen sich nur schwer quantifizieren. Daher erfolgt hier eine begründete qualitative Bewertung anhand von mehreren Fragestellungen. 
 

chapters/realisation/realisation.tex

@@ -1 +1,33 @@
-\chapter{Umsetzung und Realisierung}
+\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, macht es Sinn diese anhand einer Beispielanwendung durchzuführen. Dies bietet die Vorteile, dass die Zustandsverwaltungssystemen 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 
+
+% * Anforderungen an die Beispielanwendung (/)
+% * Beschreibung der Beispielanwendung
+% * Vorgehen beim Implementieren
+% * Skizze der Beispielanwendung
+% * Ergebnis der Beispielanwendung
+% * Beschreibung des Versuchsaufbaus