Entfernen doppelter Überschriftsnummerierungen, Testen vom Tabellenverzeichnis.

04-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md

@@ -202,7 +202,7 @@ architecture-beta
     service b(mdi:package-variant-closed)[Klasse B]
     service ib(mdi:car-clutch)[Interface B]
 
-    a:B --> T:ib
+    a:R --> L:ib
     ib:R <-- L:b
 ```
 
@@ -326,27 +326,27 @@ Für die Sicherung und Zusammenarbeit wurde im Rahmen dieser Arbeit Remote-Repos
 
 Als schlanke und selbst gehostete Open-Source-Alternative zu Plattformen wie GitHub oder GitLab wurde für die Verwaltung der Repositories Gitea eingesetzt. Hauptgrund für die Benutzung von Gitea war meine bereits aufgesetzte Instanz, welche schon mehrere Jahre in Verwendung war und mit der es im Team auch schon Erfahrungen gab. Gitea bietet neben der reinen Git-Verwaltung essenzielle Werkzeuge für den Software-Lebenszyklus, wie ein integriertes Issue-Tracking, Code-Reviews über Pull-Requests sowie eine Benutzerverwaltung, und unterstützt somit die strukturierte Umsetzung der Diplomarbeit im Team.[@gitea_docs]
 
-#### 4.4.1 Repositories
+#### Repositories
 
 Ein Repository bildet den zentralen Speicherort für einen Projektteil. In Gitea wurden separate Repositories für die einzelnen Module und Themes, das Oqtane Framework, Skripte, die Dokumentation angelegt. Ein zusätzliches Repository bindet alle übrigen Quellcode-Repositories als Submodule ein, das macht die Einrichtung einer neuen Entwicklungsumgebung sehr kompfortabel. Dies ermöglichte eine saubere Trennung der verschiedenen Projektkomponenten. [@gitea_docs]
 
-#### 4.4.2 Issues
+#### Issues
 
 Zur Aufgabenplanung und Fehlerverfolgung wurde das integrierte Issue-System genutzt. Jede anstehende Aufgabe oder entdeckte Schwachstelle wurde als „Issue“ erfasst, einem Verantwortlichen zugewiesen und mit Labels (z. B. „Bug“, „Feature“ oder „Dokumentation“) versehen. Dies half dabei, den Überblick über den Projektfortschritt zu behalten und die Anforderungen aus dem Lastenheft strukturiert abzuarbeiten. [@gitea_docs][@gitea_issue_tracker]
 
-#### 4.4.3 Pull Requests
+#### Pull Requests
 
 Um die Qualität des Codes zu sichern, wurden Änderungen nicht direkt in den Hauptzweig eingespielt, sondern über Pull Requests eingereicht. Ein Teammitglied konnte so die Änderungen eines anderen sichten, kommentieren und bei Bedarf Korrekturen anfordern. Erst nach einer erfolgreichen Überprüfung wurde der Code in den main-Branch gemergt. [@gitea_docs][@gitea_pull_requests]
 
-#### 4.4.4 Actions
+#### Actions
 
 Gitea Actions wurden eingesetzt, um CI/CD-Pipelines (Continuous Integration / Continuous Deployment) zu realisieren. Bei jedem Push oder Pull Request wurden automatisierte Skripte ausgeführt, die das Projekt bauten. Dies reduzierte manuelle Fehlerquellen erheblich. Außerdem konnten wir mithilfe von CI/CD den Release Prozess einmalig festlegen und automatisieren, ohne bei jedem Update manuell den selben Prozess wiederholt durchgehen zu müssen. Das APT-Package Projekt enthält die CI/CD Konfiguration für das bauen von Oqtane, der Module und Themes, sowie das verpacken in ein APT Paket und dem veröffentlichen aller Pakete als eingenes Gitea Release. [@gitea_docs][@gitea_actions]
 
-#### 4.4.5 Releases
+#### Releases
 
 Über die Release-Funktion wurden wichtige Meilensteine der Diplomarbeit festgeschrieben. Hierbei wird ein spezifischer Git-Tag mit einer Versionsnummer versehen und die dazugehörigen Binärdateien, Pakete und Dokumente archiviert. So lässt sich jederzeit auf einen stabilen, abgabebereiten Stand des Projekts zugreifen. [@gitea_docs]
 
-#### 4.4.6 Package Repositories
+#### Package Repositories
 
 Gitea fungierte zusätzlich als Register für Pakete und Container-Images. Selbst erstellte Artefakte, wie das Debian Paket für die Bereitstellung der Anwendung, wurden direkt in der Gitea-Instanz versioniert gespeichert. Dadurch waren alle notwendigen Komponenten für das Deployment an einem zentralen Ort verfügbar und abrufbar. Gitea selbst unterstützt verschiedenste Pakettypen. Darunter fallen unteranderem NuGet- und Debianpakete. Für beide haben wir in dieser Arbeit verwendung gefunden. [@gitea_docs][@gitea_packages]
 
@@ -358,7 +358,7 @@ Gitea fungierte zusätzlich als Register für Pakete und Container-Images. Selbs
 
 Eine C#-Solution, welche einige Module, welche für den Admineinsatz geschrieben worden sind beinhaltet. Dieses Modul besteht aus 3 Teilmodulen. Einem Modul für den Versand von Rundmails, eines für die Einstellung von der Token Lebenszeit bei Tokens, welche per E-Mail verschickt werden und eines, welches das Reporting-System übernimmt.
 
-#### 5.1.1 Mass Mailing
+#### Mass Mailing
 
 Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, die es dem Vorstand ermöglicht, personalisierte Rundschreiben an alle registrierten Mitglieder zu versenden. Da die Pflege der Mitgliederdaten direkt im CMS erfolgt, bietet dieses Modul eine nahtlose Integration ohne den Export von CSV-Listen in externe Newsletter-Tools.
 
@@ -368,7 +368,7 @@ Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. D
 
 `Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, wird diese gleich zum `schedulen` unserer E-Mails genutzt. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit Funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
 
-#### 5.1.2 Token Lifetime
+#### Token Lifetime
 
 Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gültig sein zu lassen. Durch das `Batch Processing` war es möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind manche Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
 
@@ -381,7 +381,7 @@ Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 
 `Der Workaround` ist die Möglichkeit für die wir uns entschieden haben, allerdings ist das nicht die schönste Lösung. Eine eventuell nachfolgende Diplomarbeit kann an dieser Stelle ansetzen und `die saubere Lösung` implementieren.
 
-#### 5.1.3 Reporting System
+#### Reporting System
 
 Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu Inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
 
@@ -412,9 +412,12 @@ Damit DI funktioniert muss für den DI Consumer (`also das Modul, welches das Re
 Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injizierte Klasse.
 
 ```razor
-@inject IReportUI ReportingComponent
+@inject IReportUI ReportUI
 
-<DynamicComponent Type="@ReportingComponent.ReportType" Parameters="@ReportingComponent.ConstructParameterList(_item, RenderModeBoundary)"/>
+<DynamicComponent
+  Type="@ReportUI.ReportType"
+  Parameters="@ReportUI.ConstructParameterList(_item, RenderModeBoundary)"
+/>
 
 @code {
   private IReportable _item;
@@ -427,7 +430,7 @@ Die Bereitstellung des Moduls geschieht im `AdminModules` Modul.
 
 Dieses Modul ermöglicht es Administratoren und Absolventen, Veranstaltungen zu erstellen, auf der Seite zu veröffentlichen und zu verwalten, während Mitglieder ihre Teilnahme direkt über das Portal bestätigen oder absagen können. Dieses Modul dient der organisatorischen Unterstützung von Absolvententreffen und anderen Vereinsaktivitäten. Dieses Modul wurde gemeinsam mit Adam Gaiswinkler geschrieben, wobei er sich um die Darstellung der Events im Frontend gekümmert hat, während ich mich der Infrastruktur im Hintergrund angenommen habe.
 
-#### 5.2.1 Backend und Datenhaltung
+#### Backend und Datenhaltung
 
 Die serverseitige Implementierung basiert auf dem Repository-Pattern des Oqtane-Frameworks. Hierbei kommen zwei zentrale Repositories zum Einsatz:
 
@@ -435,7 +438,46 @@ Das `EventRepository` verwaltet die Metadaten der Veranstaltungen wie Name, Besc
 Das `ResponseRepository` speichert die Rückmeldungen der Benutzer. Ein Eintrag verknüpft dabei die UserId mit der EventId und dem Status der Rückmeldung.
 Die Kommunikation zwischen dem Client und dem Server erfolgt über einen REST-API-Controller `EventRegistrationController`, der sicherstellt, dass nur autorisierte Benutzer Änderungen vornehmen oder detaillierte Statistiken einsehen können.
 
-#### 5.2.2 Statistik und Visualisierung
+##### Entity Relationship Diagram
+
+\
+
+```mermaid
+%%| filename: erd-event-registration
+%%| fig-cap: ER Diagramm des Event Registration Moduls
+erDiagram
+    direction LR
+    EVENT ||--o{ RESPONSE : "has"
+    EVENT {
+        int EventId PK
+        int ModuleId
+        string Name
+        string Description
+        datetime EventDate
+        string Location
+        string CreatedBy
+        datetime CreatedOn
+        string ModifiedBy
+        datetime ModifiedOn
+    }
+    RESPONSE {
+        int EventResponseId PK
+        bool ResponseType
+        int OwnerId FK
+        int EventRegistrationId FK
+        int ModuleId
+        string CreatedBy
+        datetime CreatedOn
+        string ModifiedBy
+        datetime ModifiedOn
+    }
+    USER ||--o{ RESPONSE : "has"
+    USER {
+        int UserId PK
+    }
+```
+
+#### Statistik und Visualisierung
 
 Ein wesentlicher Teil der administrativen Ansicht ist die Visualisierung der Anmeldezahlen. Hierfür wurde eine Integration von Chart.js realisiert, um den aktuellen Stand der Rückmeldungen grafisch aufzubereiten.
 
@@ -451,14 +493,20 @@ Durch diese Trennung bleibt die Geschäftslogik im C#-Code, während für die pe
 
 Das Modul "Schwarzes Brett" dient als digitale Anschlagtafel für den Absolventenverein. Mitglieder können hier Gesuche, Angebote oder allgemeine Informationen veröffentlichen. Es stellt eine zentrale Informationsdrehscheibe dar, die den informellen Austausch innerhalb des Vereins fördern soll.
 
-#### 5.3.1 Struktur und Anzeige
+#### Struktur und Anzeige
+
+![Detailansicht eines Eintrags auf dem Schwarzen Brett](./images/04-Konstantin/BlackBoard-Details.png){ latex-placement="ht" }
+
+<!-- ![Detailansicht eines Eintrags auf dem Schwarzen Brett][img-ref] -->
 
 Die Anzeige der Einträge erfolgt in einer responsiven Grid-Ansicht (Index-Komponente), wobei jeder Eintrag als Karte (Card) dargestellt wird. Dieses Design sorgt für eine übersichtliche Präsentation auch bei einer größeren Anzahl von Mitteilungen.
 
 - Bilderunterstützung: Das Modul nutzt die Oqtane-interne Dateiverwaltung. Wenn ein Bild für einen Eintrag hochgeladen wurde, wird dieses über einen Image-Proxy skaliert und als Vorschaubild angezeigt. Fehlt ein Bild, wird ein konsistenter Platzhalter verwendet, um das visuelle Gleichgewicht der Grid-Ansicht zu wahren.
 - Detailansicht: Die Details-Komponente bietet eine fokussierte Ansicht des Eintrags mit vollständiger HTML-Beschreibung, die über einen Rich-Text-Editor gepflegt werden kann. Ergänzt wird dies durch Metadaten wie Erstellungsdatum und Autor.
 
-#### 5.3.2 Automatisierter E-Mail-Digest
+<!-- [img-ref]: BlackBoard-Details.png "Detailansicht eines Eintrags auf dem Schwarzen Brett" -->
+
+#### Automatisierter E-Mail-Digest
 
 Um die Mitglieder regelmäßig über neue Inhalte zu informieren, wurde ein automatisierter `Cronjob` implementiert. Dieser Job läuft im Hintergrund des Oqtane-Frameworks und führt folgende Schritte aus:
 
@@ -468,11 +516,11 @@ Um die Mitglieder regelmäßig über neue Inhalte zu informieren, wurde ein auto
 - Versand: Die generierten Notifications werden in die Warteschlange der Notification-Infrastruktur eingereiht und sukzessive versendet.
   Integration des Reporting-Systems
 
-#### 5.3.3 Reporting System
+#### Reporting System
 
 Ein wichtiges Merkmal des Schwarzen Bretts zur Sicherstellung der Inhaltsqualität ist die Anbindung an das globale Reporting-System (siehe 5.4). In der Detailansicht wird über Dependency Injection die IReportUI-Komponente eingebunden. Mithilfe der DynamicComponent von Blazor wird die Melde-Funktion nahtlos in die Oberfläche des Moduls integriert. Dadurch können unangemessene Inhalte direkt von Benutzern gemeldet werden.
 
-#### 5.3.4 Technischer Hintergrund
+#### Technischer Hintergrund
 
 Auf der Serverseite folgt das Modul dem etablierten Muster mit einem `BlackBoardRepository` für den effizienten Datenbankzugriff und einem `BlackBoardController` für die API-Bereitstellung. Die Implementierung des Scheduled Jobs als HostedServiceBase ermöglicht eine tiefe Integration in die Oqtane-Infrastruktur bei gleichzeitig geringem Ressourcenverbrauch.