You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
206 lines
15 KiB
206 lines
15 KiB
\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.
|
|
|
|
In \citetitle{stateManagementThesis}\autocite{stateManagementThesis} wurden bereits Bewertungskriterien für eine Evaluation von Zustandsverwaltungssystemen aufgestellt, allerdings kann die Herleitung der Bewertungskriterien nicht nachvollzogen werden, da die verwendeten Quellen nicht die zitierten Bewertungskriterien enthalten. Daher werden nun neue Bewertungskriterien definiert.
|
|
|
|
\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, dass die resultierende Anwendung auch automatisiert testbar sein muss, um zu prüfen, ob sie den gewünschten Anforderungen entspricht.
|
|
|
|
Hinzukommend spieln 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 Widget-Baum 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 wurde bereits bei den Erläuterungen zum ISO-Standard berücksichtigt und lässt 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*innen, 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 dem 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 Architektur-bestimmender 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}
|
|
\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 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.
|
|
|
|
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 mit den Werten \textquote{nicht erfüllt}, \textquote{teilweise erfüllt} und \textquote{vollständig erfüllt} vorgenommen.
|
|
|
|
\subsection{Effizienz}
|
|
\label{sec:efficiency}
|
|
|
|
Die Effizienz eines Zustandsverwaltungssystemes lässt sich auch dadurch messen, wie effizient es das Neubauen von Widgets nach Veränderungen orchestriert. So sollte ein Widget nur dann neu gebaut 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 quantitativ 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 Hal\-stead-Volumen ($aveV$), die durchschnittliche zyklo\-matische Komplex\-itä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}
|
|
|
|
\begin{equation}
|
|
\begin{split}
|
|
\label{eqn:mi}
|
|
\text{Maintainability index} = 171 - 5,2 * ln(aveV) \\- 0,23*aveVG2 \\- 16,2*ln(aveLOC)
|
|
\end{split}
|
|
\end{equation}
|
|
|
|
Um diese Metrik für die einzelnen Systeme zu bestimmen, wird das Werkzeug \textit{Dart Code Metrics} eingesetzt, welches diverse Metriken für Dart-Quell\-text bestimmen kann. Der von dem Werkzeug berechnete Wert wird leicht abweichend, wie in \autoref{eqn:miImproved} zu sehen, von der Original-Formel auf eine Skala von 0 bis 100 abgebildet, wobei 100 den besten erzielbaren Wert darstellt. \autocite{miDart}
|
|
|
|
\begin{equation}
|
|
\begin{split}
|
|
\label{eqn:miImproved}
|
|
\text{Maintainability index} = max(0, (171 \\- 5,2 * log(HALVOL) \\- 0,23 * log(CYCLO) \\- 16,2 * log(SLOC)) * 100 / 171)
|
|
\end{split}
|
|
\end{equation}
|
|
|
|
Diese Metrik wird als Bewertungsmaßstab verwendet.% und mit erklärenden Auslegungshinweisen ergänzt.
|
|
|
|
%Kombination mit quantitativer
|
|
%Bewertung
|
|
%https://dartcodemetrics.dev/docs/metrics/maintainability-index
|
|
|
|
\subsection{Verständlichkeit / Lesbarkeit}
|
|
\label{sec:readability}
|
|
|
|
Die Lesbarkeit und Verständlichkeit eines Quelltextes lassen sich nur schwer quantifizieren. Daher erfolgt hier eine begründete qualitative Bewertung anhand von mehreren Fragestellungen.
|
|
|
|
So ist beispielsweise für die Verständlichkeit dienlich, wenn bereits in Flutter eingeführte Konzepte verwendet werden, sodass Entwickler*innen, die noch keine Erfahrungen mit dem Zustandsverwaltungssystem haben, ihre bereits existierenden Kenntnisse anwenden können.
|
|
|
|
Eine weitere Eigenschaft von lesbaren und verständlichen Quelltext ist es, dass die Struktur nachvollziehbar und klar ist. Bei der Einschätzung muss berücksichtigt werden, dass der Einfluss des Zustandsverwaltungssystems auf diese Eigenschaft unterschiedlich stark ausgeprägt ist.
|
|
|
|
In Flutter werden Widget-Bäume wie in \autoref{sec:widgets} gezeigt durch das Instanziieren von Widgets durch Konstruktor-Aufrufe erzeugt. Dabei kann es zu einer tiefen Verschachtlung (engl. nesting) kommen, die die Lesbarkeit erschwert. Daher sollten die Zustandsverwaltungssysteme diesem Problem mit geeigneten Maßnahmen entgegenwirken.
|
|
|
|
Abschließend wird auch hier eine Skala von \textquote{nicht erfüllt}, \textquote{teilweise erfüllt} bis \textquote{vollständig erfüllt} verwendet.
|
|
|
|
\subsection{Dokumentierung}
|
|
\label{sec:documentation}
|
|
|
|
Bei der Dokumentation ist es entscheidend, dass sie für die Entwicklung hilfreich ist. Dabei sollte zuerst geprüft werden, ob es überhaupt eine entsprechende Dokumentation gibt und falls ja, ob die Grundkonzepte des Zustandsverwaltungssystems beschrieben sind. Zusätzlich stellt ein weiteres Kriterium das Zurverfügungstellen von umfangreichen Beispielen dar.
|
|
|
|
Von diesen Kriterien ausgehend wird eine qualitative Bewertung anhand einer Skala von \textquote{nicht erfüllt}, \textquote{teilweise erfüllt} bis \textquote{vollständig erfüllt} verwendet.
|
|
|
|
|
|
\subsection{Strukturbestimmung}
|
|
\label{sec:structure}
|
|
|
|
Die Strukturbestimmung bewertet, inwiefern ein System Vorgaben an die Struktur der Anwendung stellt. Zusätzlich sollte untersucht werden, ob diese auch technisch forciert werden.
|
|
|
|
Dies wird auch mit einer qualitativen Bewertung von \textquote{nicht erfüllt}, \textquote{teilweise erfüllt} bis \textquote{vollständig erfüllt} bewertet.
|
|
\pagebreak
|
|
\section{Zusammenfassung}
|
|
|
|
Zusammengefasst ergibt sich aus den Anforderungen und den Bewertungskriterien eine Bewertungsmatrix, wie in \autoref{tab:criteria} zu sehen ist, welche im folgenden Teil auf einen Entwurf für jedes Zustandsverwaltungssystem angewandt werden soll.
|
|
|
|
\newcommand{\bracketCriteria}{$\left.\begin{tabular}{@{}l@{}}
|
|
nicht \\
|
|
teilweise \\
|
|
vollständig
|
|
\end{tabular}\right\}\text{erfüllt}$}
|
|
|
|
\begin{table}[h]
|
|
\myfloatalign
|
|
\begin{tabularx}{\textwidth}{cXX} \toprule
|
|
\tableheadline{Anforderung} & \tableheadline{Metrik}
|
|
& \tableheadline{Skala} \\ \midrule
|
|
Änderbarkeit / Skalierbarkeit & qualitativ & \bracketCriteria \\
|
|
\midrule
|
|
Testbarkeit & qualitativ & \bracketCriteria \\
|
|
\midrule
|
|
Effizienz & Anzahl der Widget-Rebuilds & $\mathbb{N};\mathbb{N}$ \\
|
|
\midrule
|
|
Komplexität/Wartbarkeit & \ac{mi} & 0-100 \\
|
|
\midrule
|
|
Verständlichkeit / Lesbarkeit & qualitativ & \bracketCriteria \\
|
|
\midrule
|
|
Dokumentierung & qualitativ & \bracketCriteria \\
|
|
\midrule
|
|
Strukturbestimmung & qualitativ & \bracketCriteria \\
|
|
\bottomrule
|
|
\end{tabularx}
|
|
\caption{Bewertungsmatrix}
|
|
\label{tab:criteria}
|
|
\end{table}
|
|
|
|
% Was passiert bei einem Timeout?
|
|
|
|
% Ä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.)
|
|
% -> 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 -> Neubau nur bei related Changes
|
|
% Bedienbarkeit |