klassendiagramm und wording digitization

chapters/konzeption-entwicklung.tex

@@ -54,26 +54,41 @@ Nachdem in Erfahrung gebracht wurde, welche konkreten Datenobjekte benötigt wer
 wurden Attribute dieser Objekte dem Pflichtenheft entnommen. Diese wurden in einem
 formalen Klassendiagramm festgehalten und in Rücksprache mit dem \ac{PO}
 weiter bis zu festen Datentypen und Auswahlmöglichkeiten konkretisiert.
-Beispielsweise, dass Wettbewerbskategorien als TYPO3-Categories verschachtelt gepflegt
-werden und dass Geschmacksrichtungen, Qualitätsstufen, Rebsorten, Weinlagen und
-Weineigenschaften eigene Datenobjekte
-sein sollen. Geschmack und Qualität sollen daher eigene Objekte sein, damit sich Nutzer
-für einen festen, nominalen Eintrag via einem Dropdown-Menü entscheiden müssen,
-diese allerdings immer noch im TYPO3-Backend pflegbar sind. Weinlagen sind allerdings im Brown-Field bereits vorhanden, also sollen hierfür
-existierenden Einträge verwendet werden. Weineigenschaften sollen pro Wein beliebig viele
-auswählbar sein, Wettbewerbskategorien, etc, jeweils genau ein Element.
-Notizen zu diesem Gespräch sind im Anhang unter \fullref{chap:anhang-notizen-digitization}
+
+Beispielsweise, dass Wettbewerbskategorien durch TYPO3-Categories repräsentiert werden sollen.
+Das hat den Vorteil, dass TYPO3-Categories bereits native Bestandteile eines TYPO3-Redaktionssystemes sind
+und bereits alle relevanten Attribute anbieten. Diese sind ein Titel,
+eine Parentkategorie und eine Beschreibung.
+Das Parent-Attribut ist benötigt, da $n$ dieser Attribute einen Attributbaum bilden
+\cite{bib:typo3-docs-sys-category}.
+Somit ist es möglich Unterkategorien zu erstellen. Beispiele hierfür sind die
+Unterkategorien \enquote{Trockener Riesling} und \enquote{Halbtrockener Riesling} für die Überkategorie
+\enquote{Riesling}.
+
+Rebsorten, Geschmack, Weineigenschaften und Qualität sollen eigene Datentypen
+anstatt einfacher Zeichenfolgen sein.
+Ziel davon ist, dass sich Nutzer für einen vorgefertigten, nominalen Eintrag in einem Dropdown-Menü
+entscheiden müssen und diese Auswahlmöglichkeiten immer noch im TYPO3-Backend pflegbar sind.
+
+Weinlagen sind im Brown-Field-Projekt bereits vorhanden, also sollen hierfür existierenden Daten
+eingebunden werden.
+
+Pro Wein sollen beliebig viele Weineigenschaften auswählbar sein, Wettbewerbskategorien,
+Geschmacksrichtung, etc, jeweils nur ein Element.
+
+Weitere Notizen zu diesem Gespräch sind im Anhang unter \fullref{chap:anhang-notizen-digitization}
 zu finden.
 \\
 \\
-Da das Klassendiagramm gegeben lesbarer Schrift nicht auf eine Textseite passt,
+Da das Klassendiagramm gegeben lesbare Schrift nicht auf eine Textseite passt,
 befindet es sich vollseitig im Anhang unter \fullref{chap:anhang-class-diagram}.
 Die weitere Implementation der Datenobjekte ist unkompliziert und besteht hauptsächlich aus
 repetitivem Schreiben von SQL-Tabellen, Domain-Model-Klassen und \acp{TCA}.
-Um $m,n$-Beziehungen wie Beispielsweise der Menge der für eine Probe zugelassenen Weinlagen
-\enquote{allowedVinesites} zwischen \enquote{Jahresauswahlprobe} und \enquote{Vineyardsite} zu
-ermöglichen, werden MM-Tabellen (many-to-many) benötigt, die diese Beziehungen in Form zweier
-Foreign Keys speichern. Die Repository-Klassen können \enquote{leer} gelassen werden,
+Um $m,n$-Beziehungen wie Beispielsweise der Menge der für eine Probe zugelassenen Kategorien
+\enquote{allowedCategories} zwischen $m$ \enquote{Jahresauswahlprobe}-Objekten und
+$n$ \enquote{Category}-Objekten zu ermöglichen, werden MM-Tabellen (many-to-many) benötigt,
+diese Beziehungen in Form zweier Foreign Keys speichern.
+Die Repository-Klassen können \enquote{leer} gelassen werden,
 da zu diesem Zeitpunkt keine erweiterte Auswahllogik für Datenbankanfragen benötigt wird.
 Wichtig ist hierbei, dass eine Repository-Klasse existiert. Alle unverzichtbaren
 Schnittstellen werden über die Basisklasse \enquote{Repository} geerbt

chapters/stand-der-technik.tex

@@ -86,8 +86,10 @@ Spezielle Styles sind nicht erwähnt. Ein Großteil der Issues und Pull-Requests
 BaconQrCode ist mit einer BSD-2-Clause-Lizenz lizensiert
 \cite{bib:bacon-baconqrcode}.
 
-\subsection{Vergleich in Bezug auf die Problemstellung}
-Um eine Bibliothek als \enquote{die Beste} für einen Anwendungsfall kurieren zu können,
+\subsection{Subjektiver Vergleich in Bezug auf die Problemstellung}
+Im Folgenden weden subjektive Einschätzungen und Meinungen des Autors über die Eignung der beleuchteten
+Bibliotheken vorgestellt.
+Um eine Bibliothek als \enquote{am geeignetsten} für einen Anwendungsfall kurieren,
 müssen die konkreten Anforderungen und Constraints für diesen Anwendungsfall beachtet werden.
 Das ist so, da verschiedene Eigenschaften der Bibliotheken verschiedene Auswirkung in Gewichtung und Richtung
 je nach Anwendungsfall aufweisen.
@@ -110,8 +112,9 @@ Hierfür werden die zuvor vorgestellten Bibliotheken zur Erstellung von QR-Codes
         ob die Lizenz einer Bibliothek überhaupt deren Einbundung gestattet, bzw. welche Bedingungen gelten.
 \end{description}
 
-Hierfür werden den verschiedenen Bibliotheken Punkte ($[0,10]$) in den zuvor genannten Kategorien vergeben.
-Die Kumulativpunktzahl einer Bibltiothek beschreibt deren Gesamteignung.
+Dabei werden den verschiedenen Bibliotheken Punkte ($[0,10]$) in den drei zuvor genannten Kategorien vergeben.
+Die Kumulativpunktzahl ($[0,30]$) einer Bibltiothek beschreibt deren Gesamteignung, nach subjektivem
+Empfinden des Autors.
 
 \subsubsection*{kjua}
 Kjua ist funktional für dieses Projekt gut aufgestellt, da es optisch ansprechende QR-Codes mit Logo unterstützt. Das wird
@@ -122,6 +125,16 @@ Kjua ist als Javascript-Bibliothek nur schwer mit den Anforderungen vereinbar,
 da der QR-Code in einem PDF eingebunden werden soll. Hierfür wäre ein serverseitiger Generator prädestiniert.
 Kjuas Lizenz erlaubt Verwendung in kommerziellen, Closed-Source Projekten \cite{bib:opensource-license-mit}.
 Die Exklusivität für Nutzung in Webbrowsern schließt eine Einbindung in den Workflow aus.
+\begin{table}[htbp]
+    \centering
+    \begin{tabular}{|l|l|l|l|}
+        \hline
+        \textbf{Funktionalität} & \textbf{Gepflegtheit} & \textbf{Workflow-Eignung} & \textbf{$\Sigma$}\\
+        \hline
+        8 & 2 & 0 & 10\\
+        \hline
+    \end{tabular}
+\end{table}
 
 \subsubsection*{soldair/node-qrcode}
 Soldairs Lösung sieht dokumentativ und funktional vielversprechend aus.
@@ -133,6 +146,16 @@ ein vermeidbarer Mehraufwand und ggf. imperformant generierte QR-Codes aus einer
 übertragen. Das bildet sich mit vier Punkten in \enquote{Workflow-Eignung} ab.
 Darüberhinaus macht Soldair/node-qrcode einen verbesserungswürdigen Eindruck der Projektpflege, wofür es lediglich
 drei Punkte gibt.
+\begin{table}[htbp]
+    \centering
+    \begin{tabular}{|l|l|l|l|}
+        \hline
+        \textbf{Funktionalität} & \textbf{Gepflegtheit} & \textbf{Workflow-Eignung} & \textbf{$\Sigma$}\\
+        \hline
+        8 & 3 & 4 & 15\\
+        \hline
+    \end{tabular}
+\end{table}
 
 \subsubsection*{chillerlan/php-qrcode}
 Rochkos Lösung macht einen aktiv gepflegten Eindruck und wird von großen Downloadzahlen gestützt.
@@ -148,6 +171,16 @@ Die von Rochko verwendete Lizenz gestattet eine unkomplizierte Verwendung. Chill
 PHP $7.x$ und $8.x$. Die Bibliothek benötigt zwei weitere Abhängigkeiten. Eine dieser Abhängigkeiten ist ebenfalls von Rochko
 bereitgestellt \cite{bib:chillerlan-php-qrcode-composerjson} und weist eine ähnlich gute Projektpflege auf
 \cite{bib:chillerlan-php-settings-container}. Das wird mit der Maximalwertung in \enquote{Workflow-Eignung} berechnet.
+\begin{table}[htbp]
+    \centering
+    \begin{tabular}{|l|l|l|l|}
+        \hline
+        \textbf{Funktionalität} & \textbf{Gepflegtheit} & \textbf{Workflow-Eignung} & \textbf{$\Sigma$}\\
+        \hline
+        10 & 10 & 10 & 30\\
+        \hline
+    \end{tabular}
+\end{table}
 
 \subsubsection*{kreativekorp/barcode}
 Kreativekorp beeindruckt durch Nutzungsbeispiele und Dokumentation in der Readme-Datei, sowie einer Vielzahl unterstützter
@@ -158,6 +191,16 @@ Unterstützung für Paketmanager, wodurch eine saubere Verwendung in dem Brownfi
 selbst erfordern würde.
 Die Funktionalität wurde aufgrund der desaströsen Gepflegtheit und Eignung nicht näher untersucht,
 da eine Verwendung selbst mit guter Funktionalität nicht infrage käme.
+\begin{table}[htbp]
+    \centering
+    \begin{tabular}{|l|l|l|l|}
+        \hline
+        \textbf{Funktionalität} & \textbf{Gepflegtheit} & \textbf{Workflow-Eignung} & \textbf{$\Sigma$}\\
+        \hline
+        0 & 3 & 4 & 7\\
+        \hline
+    \end{tabular}
+\end{table}
 
 \subsubsection*{Bacon/BaconQrCode}
 BaconQrCode nennt keine speziellen Optionen um näheren Einfluss auf den generierten QR-Code auszuüben.
@@ -170,15 +213,36 @@ Da es sich hierbei um eine PHP-Bibliothek handelt, die über Composer in PHP- $7
 und eine API bereitstellt, ist die \enquote{Workflow-Eignung} gut. Die BSD-2-Clause-Lizenz verkompliziert eine Integration,
 da dadurch eine Copyright-Notiz an Nutzer gezeigt werden muss \cite{bib:opensource-license-bsd-2}.
 Dadurch werden drei Punkte einer vollkommenen Workflow-Eignung abgezogen, wodurch sieben Punkte vergeben werden.
+\begin{table}[htbp]
+    \centering
+    \begin{tabular}{|l|l|l|l|}
+        \hline
+        \textbf{Funktionalität} & \textbf{Gepflegtheit} & \textbf{Workflow-Eignung} & \textbf{$\Sigma$}\\
+        \hline
+        5 & 8 & 4 & 17\\
+        \hline
+    \end{tabular}
+\end{table}
 
 \subsection{Fazit}
-\begin{nicepic}
-    \includegraphics[width=1\textwidth]{images/qrlib-compare-barchart.png}
-    \captionof{figure}{Vergleichsergebnisse QR-Code Bibliotheken}
-    \caption*{Quelle: Eigene Darstellung}
-    \label{fig:qrlib-compare-barchart}
-\end{nicepic}
+\begin{table}[htbp]
+    \centering
+    \begin{tabular}{|l||l|l||l|l|}
+        \hline
+        \textbf{Bib.} & \textbf{Funkt.} & \textbf{Gepflegtht.} & \textbf{WF.-Eignung} & \textbf{$\Sigma$}\\
+        \hline
+        \hline
+        chillerlan/php-qrcode & 10 & 10 & 10 & 30\\\hdashline
+        baconqrcode & 5 & 8 & 4 & 17\\\hdashline
+        soldair/node-qrcode & 8 & 3 & 4 & 15\\\hdashline
+        kjua & 8 & 2 & 0 & 10\\\hdashline
+        kreativekorp/barcode & 0 & 3 & 4 & 7\\
+        \hline
+    \end{tabular}
+    \caption{Subjektive Evaluation der QR-Code Bibliotheken}
+    \label{tbl:qrlib-compare-barchart}
+\end{table}
 
-Nach Evaluation der verschiedenen QR-Code-Bibliotheken im Kontext der vorliegenden Problemstellung erweist sich
+Nach Evaluation der verschiedenen QR-Code-Bibliotheken im Kontext der vorliegenden Problemstellung erweist sich aus Sicht des Autors
 \textit{chillerlan/php-qrcode} mit 30 Gesamtpunkten als die am besten geeignetste Bibliothek.
 Somit wird \textit{chillerlan/php-qrcode} als QR-Code Technologie in der Lösung dieser Problemstellung verwendet werden.

dexes/literature.bib

@@ -351,3 +351,11 @@
   year         = {2023},
   note         = {Zugriff: Februar 2023}
 }
+
+@misc{bib:typo3-docs-sys-category,
+  author       = {{TYPO3 Contributors}},
+  howpublished = "\url{https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Categories/Index.html}",
+  title        = {{System categories}},
+  year         = {2023},
+  note         = {Zugriff: März 2023}
+}

images/class-diagram.puml

@@ -156,12 +156,8 @@ class Jahresauswahlprobe #IMPLEMENTED_COLOR {
   -dateAllowRegistration_end: Date
   -dateAllowShow_start: Date
   -dateAllowShow_end: Date
-  +getAllowedVinesites(): List<Vinesite>
-  +setAllowedVinesites(allowedVinesites: List<Vinesite>): void
   +getAllowedCategories(): List<Category>
   +setAllowedCategories(allowedCategories: List<Category>): void
-  +getAllowedGrapes(): List<Grape>
-  +setAllowedGrapes(allowedGrapes: List<Grape>): void
   +getName(): String
   +setName(name: String): void
   +getDescription(): String