generated from leonetienne/LaTeX-Paper-template
98 lines
5.3 KiB
TeX
98 lines
5.3 KiB
TeX
\chapter{Umsetzung}
|
|
\label{chap:umsetzung}
|
|
Infolge der Anforderungsanalyse befasst sich das Kapitel \enquote{Umsetzung} mit der Implementation der Anforderungen in dem
|
|
Brown-Field Projekt \cite{bib:schwarzer-vorlesung-swa} in Form einer TYPO3-Extension.
|
|
|
|
\section{Setup einer TYPO3-Extension}
|
|
TYPO3-Extension werden via Composer installiert \cite{bib:typo3-docs-managing-extensions}.
|
|
Um eine TYPO3-Extension zu erstellen muss also ein Composer-Paket erstellt werden.
|
|
Um vermeidbare Komplexität zu verhindern wird das Composer-Paket das eine die hier betrachtete
|
|
TYPO3-Extension darstellt, lokal in den versionierten Ordner \enquote{packages} gelegt.
|
|
Dieses Verzeichnis wird als Quelle für Composer-Pakete in der
|
|
Haupt-composer.json-Datei hinterlegt.
|
|
Somit wird ein Composer-Paket nur für dieses Projekt bereitgestellt,
|
|
ohne den Aufwand, der mit dem Bereitstellen eines Paketes einhergeht, zu haben.
|
|
\\
|
|
\\
|
|
Um das grundlegende Setup einer Extension effizient durchzuführen wurde eine
|
|
existierende Extension vergleichbarem Funktionsumfanges kopiert, umbenannt, und eingefügt.
|
|
Spezifisch ist der \enquote{vergleichbare Funktionsumfang}, dass es Datenmodelle und Plugins
|
|
gibt.
|
|
|
|
\section{Digitization}
|
|
Die Phase der Digitazion befasst sich mit der digitalen Abbildung von Objekten der realen Welt
|
|
in einer Art und Weise sodass diese elektronisch weiterverarbeitet werden können \cite{bib:dougherty, bib:loebbecke}.
|
|
Das bedeutet, dass in diese Phase Datenobjekte definiert und implementiert werden.
|
|
Ein Datenobjekt besteht nach firmeninternen Konventionen aus zumindest
|
|
vier Komponenten:
|
|
\begin{description}
|
|
\item{Datenbanktabelle} \\
|
|
Die Datenbanktabelle persistiert Informationen.
|
|
\item{Domain Model} \\
|
|
Das Domain Model (auch Model genannt) ist eine PHP-Klasse,
|
|
die jeweils die Daten einer Zeile der Datenbanktabelle abbildet.
|
|
\item{Repository} \\
|
|
Ein Repository ist eine PHP-Klasse, die die Schnittstelle
|
|
zwischen der Datenbank und der Model-Klasse darstellt.
|
|
\item{\ac{TCA}} \\
|
|
Der \ac{TCA} des Modells definiert, wie diese Objekte im TYPO3-Backend dargestellt werden
|
|
und bearbeitbar sind.
|
|
\end{description}
|
|
\cite{bib:typo3-docs-extbase-reference}.
|
|
|
|
Im Folgenden wurde ein semiformales Diagramm der Objekte und ihren Relationen nach dem
|
|
Pflichtenheft angefertigt und in Rücksprache mit dem \ac{PO} finalisiert.
|
|
|
|
\begin{nicepic}
|
|
\includegraphics[width=1\textwidth]{images/objektrelationen-weinlandmosel-einlieferungswerkzeug.png}
|
|
\captionof{figure}{Objektrelationen}
|
|
\caption*{Quelle: Eigene Darstellung}
|
|
\label{fig:objektrelationen}
|
|
\end{nicepic}
|
|
|
|
Nachdem in Erfahrung gebracht wurde, welche konkreten Datenobjekte benötigt werden,
|
|
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 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 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 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
|
|
\cite{bib:typo3-docs-extdev-tut-tea-repositories}.
|
|
Mit Abschluss der Digitization können alle Datenstrukturen im TYPO3-Backend händisch angelegt,
|
|
eingesehen, gelöscht und bearbeitet werden.
|