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