<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\chapter{Analyse}

Nachdem nun die diversen existierenden Ansätze für die Zustandsverwaltung in Flutter vorgestellt worden sind, muss im nächsten Schritt untersucht werden, welche Anforderungen an solche Systeme gestellt werden. Zudem soll daraus abgeleitet werden, welche Kriterien für die spätere Evaluation entscheidend sind.

\section{Anforderungsanalyse}

Die grundlegende Anforderung für Zustandsverwaltungssysteme ist es, dass sie den Zustand einer Anwendung und bestimmter Teile einer Anwendung wie eines Widgets oder einer ganzen Seite verwalten können. Alle bereits vorgestellten Lösungsansätze können dies mit mehr oder weniger Aufwand auch erfüllen. Allerdings ist es neben der Aussage, ob ein System diese Anforderung umsetzen kann, auch wichtig wie und in welcher Qualität diese umgesetzt werden.

\subsection{Allgemeine Anforderungen}

Die Wahl eines Zustandsverwaltungssystems bestimmt die Architektur einer Anwendung signifikant mit. Daher sind die Anforderungen an eine gute Architektur oder ein gutes Software-Design auch in Teilen auf Zustandsverwaltungssysteme übertragbar. Um nun daraus Anforderungen zu konstruieren, ist es also erforderlich, sich anzuschauen, was ein gutes Software-Design überhaupt ausmacht.

Zur Bewertung von Software-Qualität wurden diverse Anforderungen und Kriterien entwickelt. Diese wurden mit der ISO-Norm 9126 standardisiert. Eines der Qualitätsmerkmale ist die Wartbarkeit von Software, die wie folgt beschrieben wird:

\blockcquote[470]{Balzert2009}{Fähigkeit des Softwareprodukts änderungsfähig zu sein. Änderungen können Korrekturen, Verbesserungen oder Anpassungen der Software an Änderungen der Umgebung, der Anforderungen und der funktionalen Spezifikationen einschließen}

Daraus ergeben sich auch Anforderungen an die Quelltext-Qualität. Darunter wird beispielsweise die Anforderungen der \textcquote[470]{Balzert2009}{Änderbarkeit[...] [und] Testbarkeit} verstanden. Diese Anforderungen können auch für Zustandsverwaltungssysteme übernommen werden. Zustandsverwaltungssysteme und die Anwendungen, die diese verwenden, müssen effizient veränderbar und erweiterbar sein. Zusätzlich ist eine wichtige Anforderung diese, dass die resultierende Anwendung auch automatisiert testbar sein muss, um zu prüfen, ob sie den gewünschten Anforderungen entspricht.

Zusätzlich zu diesen beiden Anforderungen spielen auch noch weitere Anforderungen zur Sicherstellung von Software-Qualität eine Rolle wie in \citetitle{rosenberg1997software} beschrieben wird. So seien die Attribute der Effizienz, Komplexität, Verständlichkeit, Wiederverwendbarkeit und Testbarkeit/Wartbarkeit von Bedeutung. \Autocite[vgl.][1]{rosenberg1997software} Diese Anforderungen lassen sich auf den beschriebenen Evaluationsfall übertragen, müssen allerdings noch auf diesen Anwendungsfall hin angewandt werden.

Angewendet auf Zustandsverwaltungssysteme könnte die Effizienz dadurch beschrieben werden, wie effizient das Aktualisieren der Widgets im Widgetbaum erfolgt. Beispielsweise könnte hier untersucht werden, ob nur die Widgets neu erstellt werden, die von einer Änderung wirklich betroffen sind.

Die Verständlichkeit kann angewendet so gedeutet werden, ob die durch die Verwendung des Systems neu geschaffenen Strukturen auch einfach zu verstehen - also verständlich sind.

Die Wiederverwendbarkeit lässt sich nicht gut auf Zustandsverwaltungssysteme übertragen, da die geschaffenen Strukturen immer auf den spezifischen Anwendungsfall ausgerichtet sind, und somit eine Wiederverwendbarkeit keine hohe Relevanz hat.

Die Testbarkeit/Wartbarkeit wurden bereits bei der Erläutungen zum ISO-Standard berücksichtigt und lassen sich auch auf den Anwendungsfall wie beschrieben anwenden.

\subsection{Spezifische Anforderungen}

Neben diesen allgemeinen Anforderungen, stellen sich noch spezifische Anforderungen an die Zustandsverwaltungssysteme. 

Für die Integration und Einbindung der Systeme durch Entwickler*innnen, ist es erforderlich, dass das System hinreichend dokumentiert ist, damit die Einbindung und Umsetzung erleichtert wird. 

Gerade bei Anwendungen, die mit agilen Methoden entwickelt werden, wird oft iterativ vorgegangen und die Anwendung so schrittweise erweitert. Daraus ergibt sich die Anforderung, dass die Systeme mit den Wachstum der Anwendung mithalten können - also skalierbar sind. Dies erweitert die bereits beschriebene Anforderung der Änderbarkeit.

Da wie bereits erwähnt, die Zustandsverwaltung ein integraler und architekturbestimmender Teil der Anwendung ist, ist es bei der Entwicklung ebenfalls hilfreich, wenn durch dieses System bereits eine gewisse Struktur vorgegeben wird. Dies hilft dabei, auch bei größeren Projekte einheitliche Vorgehensweisen durchzusetzen und somit einen homogenen Quelltextstil zu forcieren.

\subsection{Zusammenfassung}

Wenn man nun die allgemeinen und spezifischen Anforderungen zusammenfasst, erhält man folgenden Anforderungskatalog:

\begin{itemize}
    \item Änderbarkeit / Skalierbarkeit
    \item Testbarkeit
    \item Effizienz
    \item Komplexität / Wartbarkeit
    \item Verständlichkeit
    \item Dokumentierung
    \item Strukturbestimmung
\end{itemize}

\section{Bewertungskriterien}

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}

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}

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.

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}

Erfolgt das neu-bauen von Widgets nur, wenn dies wirklich notwendig ist

\subsection{Komplexität / Wartbarkeit}

Kombination mit quantitativer Bewertung
https://dartcodemetrics.dev/docs/metrics/maintainability-index

\subsection{Verständlichkeit / Lesbarkeit}

begründete qualitative Bewertung

\subsection{Dokumentierung}

Gibt es eine Dokumentation? Sind die Grundkonzepte dokumentiert? Gibt es umfangreiche Beispiele?

\subsection{Strukturbestimmung}

Qualitative Bewertung; Inwiefern macht das System Vorgaben an die Struktur der Anwendung? Werden diese forciert?

% Änderbarkeit/Skalierbarkeit:
% - Wie gut lassen sich diverse Stores verknüpfen?
% - Wie geht das System mit wachsender Größe des Zustands um?

% Testbarkeit / Wartbarkeit
% - Lässt sich die Geschäftslogik einfach automatisiert testen?
% - Lassen sich Widgets, die auf den State zugreifen decoupled testen? (mocking z.B.)
% -&gt; Qualitative Bewertung jeweils

% Effizienz
% -

% Komplexität / Wartbarkeit


% Verständlichkeit / Lesbarkeit
% - 

% Dokumentierung
% - 

% Strukturbestimmung


% https://learning.oreilly.com/library/view/fundamentals-of-software/9781492043447/ch04.xhtml#idm46005305800936

% Darstellung Was ist ein gutes Software-Design? Kriterien aus der Literatur

% Explizite Anforderungen für State Management
% Klare Strukturvorgaben
% Kommunikation zwischen States
% Dokumentation
% Performance -&gt; Neubau nur bei related Changes
% Bedienbarkeit</pre></body></html>