6008 lines
277 KiB
TeX
6008 lines
277 KiB
TeX
% Options for packages loaded elsewhere
|
||
\PassOptionsToPackage{unicode}{hyperref}
|
||
\PassOptionsToPackage{hyphens}{url}
|
||
\documentclass[
|
||
12pt,
|
||
twoside]{article}
|
||
\usepackage{xcolor}
|
||
\usepackage[top=2.5cm, bottom=2cm, left=3cm, right=2cm, a4paper]{geometry}
|
||
\usepackage{amsmath,amssymb}
|
||
\setcounter{secnumdepth}{5}
|
||
\usepackage{iftex}
|
||
\ifPDFTeX
|
||
\usepackage[T1]{fontenc}
|
||
\usepackage[utf8]{inputenc}
|
||
\usepackage{textcomp} % provide euro and other symbols
|
||
\else % if luatex or xetex
|
||
\usepackage{unicode-math} % this also loads fontspec
|
||
\defaultfontfeatures{Scale=MatchLowercase}
|
||
\defaultfontfeatures[\rmfamily]{Ligatures=TeX,Scale=1}
|
||
\fi
|
||
\usepackage{lmodern}
|
||
\ifPDFTeX\else
|
||
% xetex/luatex font selection
|
||
\fi
|
||
% Use upquote if available, for straight quotes in verbatim environments
|
||
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
|
||
\IfFileExists{microtype.sty}{% use microtype if available
|
||
\usepackage[]{microtype}
|
||
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
|
||
}{}
|
||
\usepackage{setspace}
|
||
\makeatletter
|
||
\@ifundefined{KOMAClassName}{% if non-KOMA class
|
||
\IfFileExists{parskip.sty}{%
|
||
\usepackage{parskip}
|
||
}{% else
|
||
\setlength{\parindent}{0pt}
|
||
\setlength{\parskip}{6pt plus 2pt minus 1pt}}
|
||
}{% if KOMA class
|
||
\KOMAoptions{parskip=half}}
|
||
\makeatother
|
||
\usepackage{color}
|
||
\usepackage{fancyvrb}
|
||
\newcommand{\VerbBar}{|}
|
||
\newcommand{\VERB}{\Verb[commandchars=\\\{\}]}
|
||
\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}}
|
||
% Add ',fontsize=\small' for more characters per line
|
||
\newenvironment{Shaded}{}{}
|
||
\newcommand{\AlertTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}}
|
||
\newcommand{\AnnotationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
|
||
\newcommand{\AttributeTok}[1]{\textcolor[rgb]{0.49,0.56,0.16}{#1}}
|
||
\newcommand{\BaseNTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
|
||
\newcommand{\BuiltInTok}[1]{\textcolor[rgb]{0.00,0.50,0.00}{#1}}
|
||
\newcommand{\CharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
|
||
\newcommand{\CommentTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textit{#1}}}
|
||
\newcommand{\CommentVarTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
|
||
\newcommand{\ConstantTok}[1]{\textcolor[rgb]{0.53,0.00,0.00}{#1}}
|
||
\newcommand{\ControlFlowTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}}
|
||
\newcommand{\DataTypeTok}[1]{\textcolor[rgb]{0.56,0.13,0.00}{#1}}
|
||
\newcommand{\DecValTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
|
||
\newcommand{\DocumentationTok}[1]{\textcolor[rgb]{0.73,0.13,0.13}{\textit{#1}}}
|
||
\newcommand{\ErrorTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}}
|
||
\newcommand{\ExtensionTok}[1]{#1}
|
||
\newcommand{\FloatTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
|
||
\newcommand{\FunctionTok}[1]{\textcolor[rgb]{0.02,0.16,0.49}{#1}}
|
||
\newcommand{\ImportTok}[1]{\textcolor[rgb]{0.00,0.50,0.00}{\textbf{#1}}}
|
||
\newcommand{\InformationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
|
||
\newcommand{\KeywordTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}}
|
||
\newcommand{\NormalTok}[1]{#1}
|
||
\newcommand{\OperatorTok}[1]{\textcolor[rgb]{0.40,0.40,0.40}{#1}}
|
||
\newcommand{\OtherTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{#1}}
|
||
\newcommand{\PreprocessorTok}[1]{\textcolor[rgb]{0.74,0.48,0.00}{#1}}
|
||
\newcommand{\RegionMarkerTok}[1]{#1}
|
||
\newcommand{\SpecialCharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
|
||
\newcommand{\SpecialStringTok}[1]{\textcolor[rgb]{0.73,0.40,0.53}{#1}}
|
||
\newcommand{\StringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
|
||
\newcommand{\VariableTok}[1]{\textcolor[rgb]{0.10,0.09,0.49}{#1}}
|
||
\newcommand{\VerbatimStringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
|
||
\newcommand{\WarningTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
|
||
\usepackage{longtable,booktabs,array}
|
||
\usepackage{calc} % for calculating minipage widths
|
||
% Correct order of tables after \paragraph or \subparagraph
|
||
\usepackage{etoolbox}
|
||
\makeatletter
|
||
\patchcmd\longtable{\par}{\if@noskipsec\mbox{}\fi\par}{}{}
|
||
\makeatother
|
||
% Allow footnotes in longtable head/foot
|
||
\IfFileExists{footnotehyper.sty}{\usepackage{footnotehyper}}{\usepackage{footnote}}
|
||
\makesavenoteenv{longtable}
|
||
\usepackage{graphicx}
|
||
\makeatletter
|
||
\newsavebox\pandoc@box
|
||
\newcommand*\pandocbounded[1]{% scales image to fit in text height/width
|
||
\sbox\pandoc@box{#1}%
|
||
\Gscale@div\@tempa{\textheight}{\dimexpr\ht\pandoc@box+\dp\pandoc@box\relax}%
|
||
\Gscale@div\@tempb{\linewidth}{\wd\pandoc@box}%
|
||
\ifdim\@tempb\p@<\@tempa\p@\let\@tempa\@tempb\fi% select the smaller of both
|
||
\ifdim\@tempa\p@<\p@\scalebox{\@tempa}{\usebox\pandoc@box}%
|
||
\else\usebox{\pandoc@box}%
|
||
\fi%
|
||
}
|
||
% Set default figure placement to htbp
|
||
\def\fps@figure{htbp}
|
||
\makeatother
|
||
% definitions for citeproc citations
|
||
\NewDocumentCommand\citeproctext{}{}
|
||
\NewDocumentCommand\citeproc{mm}{%
|
||
\begingroup\def\citeproctext{#2}\cite{#1}\endgroup}
|
||
\makeatletter
|
||
% allow citations to break across lines
|
||
\let\@cite@ofmt\@firstofone
|
||
% avoid brackets around text for \cite:
|
||
\def\@biblabel#1{}
|
||
\def\@cite#1#2{{#1\if@tempswa , #2\fi}}
|
||
\makeatother
|
||
\newlength{\cslhangindent}
|
||
\setlength{\cslhangindent}{1.5em}
|
||
\newlength{\csllabelwidth}
|
||
\setlength{\csllabelwidth}{3em}
|
||
\newenvironment{CSLReferences}[2] % #1 hanging-indent, #2 entry-spacing
|
||
{\begin{list}{}{%
|
||
\setlength{\itemindent}{0pt}
|
||
\setlength{\leftmargin}{0pt}
|
||
\setlength{\parsep}{0pt}
|
||
% turn on hanging indent if param 1 is 1
|
||
\ifodd #1
|
||
\setlength{\leftmargin}{\cslhangindent}
|
||
\setlength{\itemindent}{-1\cslhangindent}
|
||
\fi
|
||
% set entry spacing
|
||
\setlength{\itemsep}{#2\baselineskip}}}
|
||
{\end{list}}
|
||
\usepackage{calc}
|
||
\newcommand{\CSLBlock}[1]{\hfill\break\parbox[t]{\linewidth}{\strut\ignorespaces#1\strut}}
|
||
\newcommand{\CSLLeftMargin}[1]{\parbox[t]{\csllabelwidth}{\strut#1\strut}}
|
||
\newcommand{\CSLRightInline}[1]{\parbox[t]{\linewidth - \csllabelwidth}{\strut#1\strut}}
|
||
\newcommand{\CSLIndent}[1]{\hspace{\cslhangindent}#1}
|
||
\setlength{\emergencystretch}{3em} % prevent overfull lines
|
||
\providecommand{\tightlist}{%
|
||
\setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
|
||
\usepackage{float}
|
||
\floatplacement{figure}{H}
|
||
\raggedbottom
|
||
\usepackage{etoolbox}
|
||
\makeatletter
|
||
\patchcmd{\LT@array}{\tabskip\z@}{\tabskip\fill}{}{}
|
||
\makeatother
|
||
|
||
% Rename Table prefix to Tab.
|
||
\AtBeginDocument{%
|
||
\renewcommand{\tablename}{Tab.}
|
||
\renewcommand{\figurename}{Abb.}
|
||
\renewcommand{\listtablename}{Tabellenverzeichnis}
|
||
}
|
||
|
||
\usepackage[hyphens]{url}
|
||
\usepackage[hidelinks]{hyperref}
|
||
\usepackage[htt]{hyphenat}
|
||
\usepackage{microtype}
|
||
\setlength{\emergencystretch}{5em} % Increased to solve overfull lines
|
||
|
||
\usepackage{tocloft}
|
||
|
||
% Dotted lines for all levels in TOC
|
||
\renewcommand{\cftsecleader}{\cftdotfill{\cftdotsep}}
|
||
\renewcommand{\cftsubsecleader}{\cftdotfill{\cftdotsep}}
|
||
\renewcommand{\cftsubsubsecleader}{\cftdotfill{\cftdotsep}}
|
||
|
||
% Bold section numbers and names
|
||
\renewcommand{\cftsecfont}{\bfseries}
|
||
\renewcommand{\cftsecpagefont}{\bfseries}
|
||
|
||
% Adjust vertical spacing before sections
|
||
\setlength{\cftbeforesecskip}{0.5em}
|
||
|
||
\usepackage{fvextra}
|
||
\fvset{breaklines=true}
|
||
|
||
\usepackage{needspace}
|
||
\let\oldShaded\Shaded
|
||
\let\oldendShaded\endShaded
|
||
\renewenvironment{Shaded}{\needspace{8\baselineskip}\oldShaded}{\oldendShaded}
|
||
|
||
\usepackage{fancyhdr}
|
||
|
||
% Define the fancy style but don't activate yet
|
||
\fancypagestyle{fancy}{
|
||
\fancyhf{} % clear all header and footer fields
|
||
\fancyhead[RO,LE]{\includegraphics[height=2cm]{images/preamble/logo.png}}
|
||
\fancyhead[LO,RE]{\nouppercase{\leftmark}}
|
||
\fancyfoot[RO,LE]{\thepage}
|
||
\renewcommand{\headrulewidth}{0.4pt}
|
||
\renewcommand{\footrulewidth}{0.4pt}
|
||
\newgeometry{top=2.5cm, bottom=4cm, left=3cm, right=2cm, includehead, includefoot, a4paper}
|
||
\setlength{\headheight}{2cm}
|
||
\setlength{\footskip}{1.5cm}
|
||
}
|
||
|
||
\renewcommand{\sectionmark}[1]{\markboth{#1}{}} % Set section title to \leftmark
|
||
|
||
% Default style for preamble/TOC
|
||
\pagestyle{plain}
|
||
\fancyhf{}
|
||
\fancyfoot[C]{\thepage}
|
||
\renewcommand{\headrulewidth}{0pt}
|
||
\renewcommand{\footrulewidth}{0pt}
|
||
\usepackage{bookmark}
|
||
\IfFileExists{xurl.sty}{\usepackage{xurl}}{} % add URL line breaks if available
|
||
\urlstyle{same}
|
||
\hypersetup{
|
||
hidelinks,
|
||
pdfcreator={LaTeX via pandoc}}
|
||
|
||
\author{}
|
||
\date{}
|
||
|
||
\begin{document}
|
||
|
||
\begin{titlepage}
|
||
\begin{minipage}[c]{0.25\textwidth}
|
||
\includegraphics[width=\textwidth]{images/preamble/szu.png}
|
||
\end{minipage}
|
||
\hfill
|
||
\begin{minipage}[c]{0.7\textwidth}
|
||
\raggedleft
|
||
\textbf{Schulzentrum HTL HAK Ungargasse} \\
|
||
Höhere Lehranstalt für Informationstechnologie \\
|
||
Ausbildungsschwerpunkt Netzwerktechnik
|
||
\end{minipage}
|
||
\rule{\textwidth}{0.4pt}
|
||
|
||
\vspace{1cm}
|
||
|
||
\begin{center}
|
||
\includegraphics[width=0.6\textwidth]{images/preamble/logo.png} \\
|
||
\vspace{1.5cm}
|
||
|
||
\textbf{\Huge DIPLOMARBEIT} \\
|
||
\vspace{1cm}
|
||
\textbf{\huge AlumniHub} \\
|
||
\vspace{0.5cm}
|
||
\textit{\Large Plattform für den Absolventenverein des SZ HTL HAK Ungargasse}
|
||
\end{center}
|
||
|
||
\vspace{1.75cm}
|
||
|
||
\begin{minipage}[t]{0.5\textwidth}
|
||
\textbf{Verfasser:} \\
|
||
Adam Gaiswinkler \\
|
||
Florian Edlmayer \\
|
||
Konstantin Hintermayer
|
||
\end{minipage}
|
||
\begin{minipage}[t]{0.4\textwidth}
|
||
\textbf{Betreuer:} \\
|
||
Prof. Thomas Gürth
|
||
\end{minipage}
|
||
|
||
\vspace{0.5cm}
|
||
|
||
\begin{minipage}[t]{0.5\textwidth}
|
||
\textbf{Klasse:} \\
|
||
5BHITN
|
||
\end{minipage}
|
||
\begin{minipage}[t]{0.4\textwidth}
|
||
\textbf{Schuljahr:} \\
|
||
2025/26
|
||
\end{minipage}
|
||
|
||
\vspace{0.75cm}
|
||
|
||
\begin{minipage}[t]{0.5\textwidth}
|
||
\textbf{Abgabevermerk:} \\
|
||
Wien, am 26.03.2026
|
||
\end{minipage}
|
||
\begin{minipage}[t]{0.4\textwidth}
|
||
\textbf{Projektnummer:} \\
|
||
3U\_HI\_2026\_04 \\
|
||
\hrulefill
|
||
\end{minipage}
|
||
|
||
\vspace{0.25cm}
|
||
|
||
\textbf{übernommen von:} \\
|
||
\hrulefill
|
||
\end{titlepage}
|
||
|
||
\newpage
|
||
\pagenumbering{Roman}
|
||
\cleardoublepage
|
||
\section*{Eidesstattliche Erklärung}
|
||
Ich erkläre, dass ich die vorliegende Diplomarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt, sowie die aus anderen Werken übernommene Inhalte durch Quellenangaben erkenntlich gemacht habe.
|
||
|
||
\vspace{1.5cm}
|
||
|
||
\begin{tabular}{@{}p{5cm}p{1cm}p{7cm}@{}}
|
||
Wien, am 26.03.2026 & & \hrulefill \\
|
||
& & Adam Gaiswinkler
|
||
\end{tabular}
|
||
|
||
\vspace{1.2cm}
|
||
|
||
\begin{tabular}{@{}p{5cm}p{1cm}p{7cm}@{}}
|
||
Wien, am 26.03.2026 & & \hrulefill \\
|
||
& & Florian Edlmayer
|
||
\end{tabular}
|
||
|
||
\vspace{1.2cm}
|
||
|
||
\begin{tabular}{@{}p{5cm}p{1cm}p{7cm}@{}}
|
||
Wien, am 26.03.2026 & & \hrulefill \\
|
||
& & Konstantin Hintermayer
|
||
\end{tabular}
|
||
|
||
\makeatletter
|
||
\renewcommand{\tableofcontents}{%
|
||
\@starttoc{toc}%
|
||
}
|
||
\renewcommand{\listoffigures}{%
|
||
\@starttoc{lof}%
|
||
}
|
||
\renewcommand{\listoftables}{%
|
||
\@starttoc{lot}%
|
||
}
|
||
|
||
\setstretch{1.5}
|
||
\newpage
|
||
|
||
\section*{Kurzfassung}\label{kurzfassung}
|
||
|
||
In dieser Diplomarbeit geht es um die Entwicklung von „AlumniHub`` --
|
||
einer Webanwendung für den Absolventenverein der HTL Ungargasse. Wir
|
||
haben die alte, händische Verwaltung durch ein modernes, automatisiertes
|
||
System ersetzt, das auf ASP.NET Core, Blazor und dem Oqtane CMS basiert.
|
||
Ziel war es, eine Plattform zu schaffen, die Kommunikation,
|
||
Event-Planung und Networking an einem zentralen Ort bündelt.
|
||
|
||
Die technische Arbeit haben wir uns im Team aufgeteilt: Konstantin
|
||
Hintermayer hat als Product Owner die Linux-Serverinfrastruktur, die
|
||
PostgreSQL-Datenbank und die CI/CD-Pipelines aufgesetzt sowie das
|
||
digitale „Schwarze Brett`` programmiert. Adam Gaiswinkler hat das
|
||
responsive Design im Stil der Schule entworfen und das Event-Anmeldetool
|
||
sowie die „Hall of Fame`` inklusive PDF-Export umgesetzt. Florian
|
||
Edlmayer war für den Premiumbereich mit seinem Freigabe-Workflow
|
||
verantwortlich, hat die DSGVO-Vorgaben umgesetzt und den sicheren Login
|
||
über LinkedIn (OAuth 2.0) eingebaut. Das Ergebnis ist eine
|
||
leistungsstarke Plattform, die dem Verein die tägliche Verwaltungsarbeit
|
||
deutlich erleichtert. \cleardoublepage
|
||
|
||
\section*{Abstract}\label{abstract}
|
||
|
||
This diploma thesis covers the development of ``AlumniHub,'' a web
|
||
platform designed for the alumni association of the HTL Ungargasse. Our
|
||
goal was to replace their old, manual administration with an automated
|
||
system using ASP.NET Core, Blazor, and the Oqtane CMS. The platform now
|
||
handles communication, event planning, and networking in one central
|
||
place.
|
||
|
||
The technical work was split between the team: Konstantin Hintermayer
|
||
(Product Owner) was responsible for the Linux server infrastructure, the
|
||
PostgreSQL database, and CI/CD pipelines, while also building the
|
||
digital ``Blackboard.'' Adam Gaiswinkler created the responsive UI in
|
||
the school's style and implemented the event registration tool and the
|
||
``Hall of Fame'' with automated PDF exports. Florian Edlmayer developed
|
||
the premium area and its approval workflow, ensured GDPR compliance, and
|
||
integrated the LinkedIn Login (OAuth 2.0). Overall, we built a
|
||
high-performance system that significantly simplifies the association's
|
||
daily administrative work.
|
||
|
||
\newpage
|
||
|
||
\section*{Danksagung}\label{danksagung}
|
||
|
||
Obwohl die Umsetzung dieses Projektes durch das Projektteam selbst
|
||
erfolgte, gab es eine Reihe an Personen, die uns tatkräftig unterstützt
|
||
haben.
|
||
|
||
An erster Stelle möchten wir uns bei Herrn Prof.~Thomas Gürth und Herrn
|
||
Prof.~Johannes Kreuzer bedanken. Ohne Ihre umfangreiche Unterstützung,
|
||
Kreativität und fachliche Kompetenz wäre das Projekt in dieser Form
|
||
nicht realisierbar gewesen. Sie beide haben uns durch dieses Projekt
|
||
begleitet, uns mit wertvollen Ideen und Hilfestellungen versorgt und uns
|
||
gleichzeitig den notwendigen Freiraum für eigenständiges Lernen und
|
||
Arbeiten gelassen.
|
||
|
||
Neben einer exzellenten Betreuung bedarf eine Diplomarbeit auch eines
|
||
engagierten Auftraggebers. Bei Lukas Aigner bedanken wir uns für das
|
||
Vertrauen in unser Team und die Ermöglichung dieses Projektes. Trotz
|
||
zeitlicher Verzögerungen im Rahmen der Arbeit, erfuhren wir von seiner
|
||
Seite großes Verständnis und fanden stets eine konstruktive Basis für
|
||
Diskussionen vor.
|
||
|
||
Ein besonders komplexer Aspekt dieser Arbeit war die Infrastruktur, für
|
||
die im Prozess drei verschiedene Lösungen evaluiert wurden. Wir danken
|
||
Stefan Reinel und dem Team von LiveDesign für die bereitwillige
|
||
Unterstützung. Ohne die aktuelle Infrastruktur hätten wir bis heute
|
||
keine zufriedenstellende Lösung für unsere Homepage gefunden.
|
||
|
||
Als wir im Oktober kurzfristig eine neue Produktionsumgebung benötigten,
|
||
wurde uns unbürokratisch durch die Schule geholfen. Herr Prof.~Harald
|
||
Dassler und Herr Prof.~Andreas Resch haben uns zur Weiterentwicklung
|
||
eine virtuelle Maschine zur Verfügung gestellt und den externen Zugriff
|
||
ermöglicht. Es ist nicht selbstverständlich, dass in einer Institution
|
||
dieser Größe ein solcher Wunsch so schnell und unkompliziert umgesetzt
|
||
wird.
|
||
|
||
Für den „frischen Wind`` und das sorgfältige Korrekturlesen der Arbeit
|
||
bedanken wir uns herzlich bei Frau Prof.~Gertrude Brindlmayer. Ihr
|
||
geschulter Blick auf Details, die dem Team im Arbeitsprozess entgangen
|
||
waren, stellte eine große Bereicherung für die finale Qualität dieser
|
||
Arbeit dar.
|
||
|
||
\newpage
|
||
|
||
\section*{Vorwort}\label{vorwort}
|
||
|
||
Diese Diplomarbeit ist im Schuljahr 2025/2026 an der HTL SZU Ungargasse
|
||
im Rahmen des Projekts Alumnihub entstanden. Unser Ziel war es, zusammen
|
||
mit dem Absolventenverein die veraltete Mitgliederverwaltung zu
|
||
modernisieren und eine neue digitale Plattform für ehemalige
|
||
Schülerinnen und Schüler zu entwickeln. Was am Anfang nur eine
|
||
Pflichtaufgabe für die Schule war, wurde für uns schnell zu einem
|
||
Projekt, mit dem wir uns voll identifiziert haben. Besonders
|
||
herausfordernd war, dass unser Team im Laufe der Zeit kleiner wurde und
|
||
wir am Ende nur noch zu dritt waren. Konstantin Hintermayer, Florian
|
||
Edlmayer und Adam Gaiswinkler mussten deshalb viel mehr Verantwortung
|
||
übernehmen und technisches Wissen schneller aufbauen als eigentlich
|
||
geplant. Die Arbeit am AlumniHub war für uns die ideale Chance, das
|
||
Wissen aus der Theorie endlich mal in einem echten und anspruchsvollen
|
||
Softwareprojekt einzusetzen. Es war eine stressige, aber sehr lehrreiche
|
||
Zeit, und wir sind stolz auf das, was wir am Ende als Team abgeliefert
|
||
haben.
|
||
|
||
\newpage
|
||
|
||
\section*{Einsatz Künstlicher Intelligenz
|
||
(KI-Disclaimer)}\label{einsatz-kuxfcnstlicher-intelligenz-ki-disclaimer}
|
||
|
||
Diese Diplomarbeit und die Software Alumnihub wurden von uns
|
||
eigenständig entwickelt. KI-Tools haben wir lediglich als Unterstützung
|
||
für Aufgaben wie Korrekturlesen, Übersetzungen oder zur gezielten
|
||
Recherche genutzt. Auch beim Debugging im Code war die KI eine Hilfe.
|
||
Der eigentliche Quellcode, die inhaltliche Ausarbeitung und alle
|
||
technischen Entscheidungen stammen jedoch direkt von uns. Sämtliche
|
||
KI-Vorschläge wurden von uns kritisch hinterfragt und nur nach eigener
|
||
Prüfung übernommen.
|
||
|
||
\cleardoublepage
|
||
\pagestyle{empty}
|
||
\pagenumbering{arabic}
|
||
\setcounter{page}{1}
|
||
|
||
\cleardoublepage
|
||
|
||
\section*{Inhaltsverzeichnis}\label{inhaltsverzeichnis}
|
||
|
||
\tableofcontents
|
||
|
||
\cleardoublepage
|
||
\pagestyle{fancy}
|
||
\pagenumbering{arabic}
|
||
|
||
\section{Einleitung Allgemeiner Teil}\label{einleitung-allgemeiner-teil}
|
||
|
||
\subsection{Diplomarbeitsantrag}\label{diplomarbeitsantrag}
|
||
|
||
\subsubsection{Ausgangslage}\label{ausgangslage}
|
||
|
||
Der Absolventenverein verwaltet derzeit rund 300 Alumni, deren Daten in
|
||
einer CSV-Datei gepflegt werden. Die Event-Anmeldungen der letzten Jahre
|
||
erfolgten über ``Perspective Funnels'', dessen Lizenz mittlerweile
|
||
abgelaufen ist. Für die kommenden Veranstaltungen wird daher ein Ersatz
|
||
für die Event-Registrierung benötigt. Die aktuellen Abläufe sind
|
||
dezentral und teilweise manuell, was zu einem erhöhten
|
||
Verwaltungsaufwand und fehlender Übersicht führt. Eine integrierte
|
||
Plattform für Mitgliederverwaltung, Kommunikation und Event-Organisation
|
||
existiert bislang nicht.
|
||
|
||
\subsubsection{Zielsetzung}\label{zielsetzung}
|
||
|
||
Ziel der Diplomarbeit ist es, ein Content-Management-System als Basis
|
||
für eine innovative, barrierefreie und sichere Webseite des
|
||
Absolventenvereins zu nutzen, dabei vorhandene Funktionen des CMS
|
||
anzupassen und eigene Module wie eine Eventanmeldung, eine Hall of Fame,
|
||
ein Schwarzes Brett als Kommunikationsplattform sowie einen
|
||
Premiumbereich zu entwickeln. Die Anwendung soll modular, erweiterbar
|
||
und leicht wartbar sein und auf einem Schulserver betrieben werden, um
|
||
eine kontrollierte und geschützte Umgebung für die Verwaltung der
|
||
Mitglieder- und Veranstaltungsdaten zu gewährleisten.
|
||
|
||
\subsubsection{Tatsächliches Ergebnis}\label{tatsuxe4chliches-ergebnis}
|
||
|
||
Im Rahmen des Projekts konnten alle priorisierten Tickets aus dem
|
||
Product Backlog erfolgreich umgesetzt werden.
|
||
|
||
Konstantin Hintermayer übernahm als Product Owner die Kommunikation mit
|
||
dem Auftraggeber und stellte einen funktionsfähigen Linux-Server als
|
||
technische Grundlage bereit. Zusätzlich erarbeitete er Skripte sowie
|
||
Dokumentationen zur Serverlandschaft und führte die Grundkonfiguration
|
||
des CMS durch. Weiters wurden die Module „Auswertung`` und „Schwarzes
|
||
Brett`` erfolgreich an den Kunden übergeben.
|
||
|
||
Adam Gaiswinkler war für die Dokumentation der Benutzeroberfläche und
|
||
des Backends sowie für die Entwicklung eines CMS-Moduls zur Anmeldung
|
||
und für die „Hall of Fame`` verantwortlich. Auch die grundlegende
|
||
Konfiguration des CMS wurde erfolgreich umgesetzt.
|
||
|
||
Florian Edlmayer entwickelte ein funktionierendes CMS-Modul für den
|
||
Premiumbereich der Absolventen. Zusätzlich erstellte er eine
|
||
vollständige und gesetzeskonforme Datenschutzerklärung. Ein weiterer
|
||
wichtiger Bestandteil war die erfolgreiche Implementierung einer
|
||
OAuth-Authentifizierung über LinkedIn.
|
||
|
||
\subsection{Das Team}\label{das-team}
|
||
|
||
Konstantin Hintermayer
|
||
|
||
Geboren am: 25.05.2007
|
||
|
||
E-Mail: {[}konstantin.hintermayer@edu.szu.at{]}
|
||
|
||
Individuelle Themenstellung: Projektleitung (Product Owner), (Server-)
|
||
Infrastruktur, Aufsetzen und Installieren der Server / Linux /
|
||
Datenbank, Adminzugriff, Skripten, Entwicklung der Auswertungen und des
|
||
schwarzen Bretts.
|
||
|
||
Florian Edlmayer
|
||
|
||
Geboren am: 20.08.2006
|
||
|
||
E-Mail: {[}florian.edlmayer@edu.szu.at{]}
|
||
|
||
Individuelle Themenstellung: Entwicklung eines CMS-Moduls für den
|
||
Premiumbereich des Absolventenvereins,Verfassung der
|
||
Datenschutzerklärung und zuständig für Informationssicherheit,
|
||
Implementierung von OAuth, Datenbankmanagement.
|
||
|
||
Adam Gaiswinkler
|
||
|
||
Geboren am: 11.10.2006
|
||
|
||
E-Mail: {[}adam.gaiswinkler@edu.szu.at{]}
|
||
|
||
Individuelle Themenstellung:Entwicklung zweier CMS-Module: (Anmeldetool
|
||
für Treffen und Hall of Fame), Grundkonfiguration des CMS, Starker Fokus
|
||
auf nutzerfreundliches und responsives Design, Web-Entwicklung mit C\#
|
||
und ASP.NET.
|
||
|
||
\subsection{Fachliches
|
||
Umfeld(Technologien)}\label{fachliches-umfeldtechnologien}
|
||
|
||
Im fachlichen Umfeld dieser Diplomarbeit kommt das
|
||
Content-Management-System Oqtane zum Einsatz. Oqtane basiert auf
|
||
modernen Webtechnologien wie ASP.NET Core und der Plattform .NET und
|
||
ermöglicht die Entwicklung modularer und skalierbarer Webanwendungen.
|
||
Durch seine komponentenbasierte Architektur können Funktionen in Form
|
||
von Modulen flexibel entwickelt und in die Anwendung integriert werden.
|
||
Dies erleichtert sowohl die Erweiterbarkeit als auch die Wartung der
|
||
Plattform. Besonders im Kontext dieser Arbeit bietet Oqtane eine
|
||
geeignete Grundlage, um eine dynamische und benutzerorientierte
|
||
Alumni-Plattform umzusetzen, da sowohl Inhalte als auch
|
||
Benutzerverwaltung effizient verwaltet werden können.
|
||
|
||
Siehe Details unter: Konstantin Hintermayer individueller Teil
|
||
|
||
\section{Projektplanung}\label{projektplanung}
|
||
|
||
\subsection{Projektziele}\label{projektziele}
|
||
|
||
\subsubsection{Hauptziele}\label{hauptziele}
|
||
|
||
\begin{itemize}
|
||
\item
|
||
\textbf{HZ01 -- Verwaltung von Absolventenprofilen} Das System
|
||
ermöglicht die zentrale Erstellung und Pflege individueller Profile
|
||
für Absolventen.
|
||
\item
|
||
\textbf{HZ02 -- Organisation von Veranstaltungen} Die Applikation
|
||
stellt Funktionen zur Planung und Durchführung von Vereinstreffen und
|
||
Events bereit.
|
||
\item
|
||
\textbf{HZ03 -- Darstellung der Hall of Fame} Besondere Leistungen und
|
||
Erfolge von Absolventen werden in einer digitalen Ehrengalerie
|
||
präsentiert.
|
||
\item
|
||
\textbf{HZ04 -- Firmen- und Jobstellenmarkt} Integration einer
|
||
Plattform für Stellenangebote, Praktika und die Vernetzung mit
|
||
Partnerunternehmen.
|
||
\item
|
||
\textbf{HZ05 -- Zugriffsverwaltung und Sicherheit} Implementierung
|
||
einer rollenbasierten Zugriffskontrolle und Gewährleistung der
|
||
Datensicherheit nach DSGVO-Standard.
|
||
\item
|
||
\textbf{HZ06 -- Schülerzugang und CMS} Einbindung eines
|
||
Redaktionssystems für Beiträge und eines speziellen Zugangs für
|
||
aktuelle Schüler.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Hardwareanforderungen und
|
||
Infrastruktur}\label{hardwareanforderungen-und-infrastruktur}
|
||
|
||
\begin{itemize}
|
||
\item
|
||
\textbf{HW01 -- Benutzerkapazität (300 Nutzer)} Das System unterstützt
|
||
mindestens 300 gleichzeitig registrierte Benutzer für Administration
|
||
und Nutzung.
|
||
\item
|
||
\textbf{HW02 -- Aktive Zugriffsrate (50 Zugriffe/Tag)} Die
|
||
Infrastruktur ist auf ca. 50 tägliche aktive Nutzer ohne
|
||
Performanceverluste ausgelegt.
|
||
\item
|
||
\textbf{HW03 -- Einfache Skalierbarkeit} Die Architektur erlaubt eine
|
||
flexible Erweiterung der Ressourcen ohne strukturelle Änderungen.
|
||
\item
|
||
\textbf{HW04/05 -- Hochverfügbarkeit (99,5 \%)} Der Betrieb erfolgt
|
||
auf skalierbaren Cloud-Servern mit einer angestrebten Verfügbarkeit
|
||
von 99,5 \% pro Jahr.
|
||
\item
|
||
\textbf{HW07 -- Disaster Recovery (24h)} Im Falle eines Totalausfalls
|
||
muss das System innerhalb von 24 Stunden wieder benutzbar sein.
|
||
\end{itemize}
|
||
|
||
• \textbf{HW12/13 -- Automatisierte Sicherung} Implementierung einer
|
||
automatisierten Datensicherung für Datenbanken und Binaries auf
|
||
unabhängigen Speichern.
|
||
|
||
• \textbf{RED-1 -- Redundanz der Datenbank} Die Datenbank wird zur
|
||
Ausfallsicherheit redundant geführt und nutzt automatische
|
||
Master-Promotion im Fehlerfall.
|
||
|
||
\subsubsection{Schnittstellenanforderungen}\label{schnittstellenanforderungen}
|
||
|
||
\begin{itemize}
|
||
\item
|
||
\textbf{SnT-1 -- REST-API (Frontend/Backend)} Bereitstellung einer API
|
||
zur Kommunikation zwischen dem Oqtane-CMS und dem Blazor-Frontend für
|
||
dynamische CRUD-Operationen.
|
||
\item
|
||
\textbf{SnT-2 -- SMTP-E-Mail-Versand (Brevo)} Einbindung des Brevo
|
||
SMTP-Dienstes für den Versand von bis zu 300 transaktionalen E-Mails
|
||
pro Tag.
|
||
\item
|
||
\textbf{SnT-3 -- LinkedIn OAuth (Phase 2)} Schnittstelle zur
|
||
Authentifizierung und zum automatisierten Abruf von Profildaten über
|
||
LinkedIn.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Software und
|
||
Zugriffsverwaltung}\label{software-und-zugriffsverwaltung}
|
||
|
||
\begin{itemize}
|
||
\item
|
||
\textbf{SW-1/2 -- Barrierefreiheit und Browser-Support} Unterstützung
|
||
gängiger Browser und Einhaltung des WCAG 2.1 AA Standards für
|
||
Barrierefreiheit.
|
||
\item
|
||
\textbf{SW-4 -- Sicherer Administrationszugriff} Administrativer
|
||
Zugriff erfolgt ausschließlich über eine verschlüsselte VPN-Verbindung
|
||
(Wireguard) und SSH.
|
||
\item
|
||
\textbf{ZUG-1--4 -- Authentifizierung und Rollen} Implementierung
|
||
klassischer Login-Verfahren, Passwort-Reset-Funktionen und einer
|
||
detaillierten Benutzerverwaltung für Administratoren.
|
||
\item
|
||
\textbf{ZUG-6/7 -- Magic Link und 2FA (Phase 2)} Erweiterung der
|
||
Sicherheit durch passwortlose Anmeldung via E-Mail-Link und
|
||
Zwei-Faktor-Authentifizierung.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Funktionsmodule (Phase 2)}\label{funktionsmodule-phase-2}
|
||
|
||
\begin{itemize}
|
||
\item
|
||
\textbf{HoF-1/2 -- Hall of Fame Funktionen} Nutzer können ihre Erfolge
|
||
online präsentieren und als ansprechendes PDF für Treffen exportieren.
|
||
\item
|
||
\textbf{JOB-1/2 -- Job- und Praktikumsbörse} Plattform für
|
||
Stellenanzeigen und Bewerbungen inklusive Dashboard für Arbeitgeber
|
||
und statistischen Auswertungen.
|
||
\item
|
||
\textbf{PRE-1--3 -- Premiumbereich} Exklusiver Zugang für
|
||
Premiummitglieder inklusive Einsicht in Ingenieuranträge und
|
||
erweiterter Event-Organisation.
|
||
\item
|
||
\textbf{ScB-1--4 -- Schwarzes Brett} Ein interaktiver Feed für
|
||
Nachrichten, Event-Ankündigungen und Werbung mit integriertem
|
||
Meldesystem für Inhalte.
|
||
\item
|
||
\textbf{AfT-1--5 -- Anmeldetool für Treffen} Umfassendes Tool zur
|
||
Eventerstellung, zum Versand von Einladungen (E-Mail/SMS) und zur
|
||
Zielgruppenfilterung.
|
||
\item
|
||
\textbf{Pro-1--4 -- Erweiterte Profilverwaltung} Nutzer können ihre
|
||
Daten manuell pflegen oder automatisiert mit ihrem LinkedIn-Profil
|
||
abgleichen lassen.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Daten und Dokumentation}\label{daten-und-dokumentation}
|
||
|
||
\begin{itemize}
|
||
\item
|
||
\textbf{DB-1 -- PostgreSQL Datenbank} Entwicklung eines relationalen
|
||
Datenbankdesigns inklusive Indizierung und Verschlüsselung zur
|
||
Gewährleistung der Datenintegrität.
|
||
\item
|
||
\textbf{DOK-1--6 -- Projektdokumentation} Erstellung aller notwendigen
|
||
Handbücher (Benutzer, Admin, Git) und des Disaster-Recovery-Handbuchs.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Nicht-Ziele}\label{nicht-ziele}
|
||
|
||
\begin{itemize}
|
||
\item
|
||
\textbf{NZ01 -- Zahlungsprozesse} Die technische Abwicklung von
|
||
Zahlungen im Premiumbereich liegt außerhalb des Projektscopes.
|
||
\item
|
||
\textbf{NZ02 -- Externe Kalenderlösungen} Die Integration externer
|
||
Dienste wie V-Calendar oder V-Event ist nicht vorgesehen.
|
||
\end{itemize}
|
||
|
||
\subsection{Aufgabenverteilung}\label{aufgabenverteilung}
|
||
|
||
\subsubsection{Konstantin Hintermayer}\label{konstantin-hintermayer}
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.2051}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.7949}}@{}}
|
||
\caption{Aufgabenverteilung Konstantin Hintermayer}\tabularnewline
|
||
\toprule\noalign{}
|
||
\endfirsthead
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
Themenstellung: & Die individuelle Themenstellung umfasst die Konzeption
|
||
und Umsetzung der Infrastruktur sowie die Entwicklung von Modulen für
|
||
Auswertungen und ein Schwarzes Brett innerhalb der Plattform. \\
|
||
Ziele und Anforderungen & HW01, HW02, HW03, HW04/05, HW07, RED-1, SW-4,
|
||
ScB-1--4 \\
|
||
\end{longtable}
|
||
|
||
\subsubsection{Florian Edlmayer}\label{florian-edlmayer}
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.1943}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.8057}}@{}}
|
||
\caption{Aufgabenverteilung Florian Edlmayer}\tabularnewline
|
||
\toprule\noalign{}
|
||
\endfirsthead
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
Themenstellung: & Die individuelle Themenstellung umfasst die
|
||
Entwicklung eines Premiumbereichs sowie die Umsetzung von Datenschutz-
|
||
und Informationssicherheitsmaßnahmen, einschließlich Zugriffs- und
|
||
Profilverwaltung. \\
|
||
Ziele und Anforderungen & HZ01, HZ05, HW12/13, SnT-3, ZUG-1--4, ZUG-6/7,
|
||
PRE-1--3, Pro-1--4, DB-1 \\
|
||
\end{longtable}
|
||
|
||
\subsubsection{Adam Gaiswinkler}\label{adam-gaiswinkler}
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.2087}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.7913}}@{}}
|
||
\caption{Aufgabenverteilung Adam Gaiswinkler}\tabularnewline
|
||
\toprule\noalign{}
|
||
\endfirsthead
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
Themenstellung: & Die individuelle Themenstellung umfasst die
|
||
Entwicklung einer Hall of Fame, die Implementierung eines Anmeldetools
|
||
für Treffen sowie die Konfiguration des Content-Management-Systems. \\
|
||
Ziele und Anforderungen & HZ02, HZ03, HZ06, SnT-2, SW-1/2, HoF-1/2,
|
||
AfT-1--5 \\
|
||
\end{longtable}
|
||
|
||
\subsection{Geplante Projektablauf}\label{geplante-projektablauf}
|
||
|
||
\subsubsection{Meilensteine}\label{meilensteine}
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.0087}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.0405}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.9509}}@{}}
|
||
\caption{Meilensteine}\tabularnewline
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
\#
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Datum
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
\#
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Datum
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
\emph{1} & \emph{19.09.2025} & Fertigstellung und Abgabe des
|
||
Diplomarbeitsantrags. \\
|
||
\emph{2} & \emph{30.10.2025} & {[}cite\_start{]}Server-Setup mit
|
||
SSH-Zugriff {[}cite: 83{]}{[}cite\_start{]}, CMS-Grundkonfiguration
|
||
(Oqtane) im SZU-Design {[}cite: 69, 83{]}{[}cite\_start{]},
|
||
Implementierung der Eingabemaske und API für das Anmeldetool {[}cite:
|
||
137{]} {[}cite\_start{]}sowie Erstellung der DSGVO-Richtlinien {[}cite:
|
||
38{]} {[}cite\_start{]}und Backupstrategie{[}cite: 55, 62{]}. \\
|
||
\emph{3} & \emph{27.11.2025} & {[}cite\_start{]}Entwicklung grafischer
|
||
Auswertungen für Anmeldedaten {[}cite: 120{]} {[}cite\_start{]}und
|
||
Integration der OAuth-Authentifizierung zum automatisierten Abruf von
|
||
Profildaten{[}cite: 78, 148{]}. \\
|
||
\emph{4} & \emph{18.12.2025} & Realisierung des Schwarzen Bretts inkl.
|
||
{[}cite\_start{]}Sperrfunktion für Administratoren {[}cite:
|
||
133{]}{[}cite\_start{]}, Entwicklung des Hall of Fame Moduls mit
|
||
PDF-Generierung {[}cite: 105{]} {[}cite\_start{]}sowie Aufbau der
|
||
Premiumkunden-Verwaltung{[}cite: 113{]}. \\
|
||
\emph{5} & \emph{21.01.2026} & {[}cite\_start{]}Erstellung der
|
||
technischen Systemdokumentation {[}cite: 155{]}{[}cite\_start{]},
|
||
Durchführung von Modultests und Implementierung der
|
||
Premium-Serviceverwaltung{[}cite: 113{]}. \\
|
||
\emph{6} & \emph{08.02.2026} & {[}cite\_start{]}Projektabschluss der
|
||
Infrastruktur-Tasks, Übergabe der Disaster-Recovery-Skripte {[}cite:
|
||
58{]} {[}cite\_start{]}und Finalisierung der gesamten
|
||
Projektdokumentation{[}cite: 155{]}. \\
|
||
\emph{7} & \emph{12.03.2026} & Finale Abgabe des Diplomarbeitsbuchs. \\
|
||
\emph{8} & \emph{22.04.2026} & Defensio (Projektabschluss). \\
|
||
\end{longtable}
|
||
|
||
\subsubsection{Sprints}\label{sprints}
|
||
|
||
\begin{longtable}[]{@{}lllll@{}}
|
||
\caption{Sprints und deren Schwerpunkte}\tabularnewline
|
||
\toprule\noalign{}
|
||
\# & Beginn & Ende & Hinweis & Meilensteine \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\# & Beginn & Ende & Hinweis & Meilensteine \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
1 & 02.10.2025 & 16.10.2025 & & \\
|
||
2 & 16.10.2025 & 30.10.2025 & & 1. Meilenstein \\
|
||
3 & 30.10.2025 & 13.11.2025 & Herbstferien & \\
|
||
4 & 13.11.2025 & 27.11.2025 & & 2. Meilenstein \\
|
||
5 & 27.11.2025 & 11.12.2025 & & \\
|
||
6 & 11.12.2025 & 25.12.2025 & Weihnachtsferien & 3. Meilenstein \\
|
||
7 & 25.12.2025 & 08.01.2026 & Weihnachtsferien & \\
|
||
8 & 08.01.2026 & 22.01.2026 & & 4. Meilenstein \\
|
||
9 & 22.01.2026 & 05.02.2026 & Semesterferien & \\
|
||
10 & 05.02.2026 & 19.02.2026 & & 5. Meilenstein \\
|
||
11 & 19.02.2026 & 05.03.2026 & & \\
|
||
12 & 05.03.2026 & 19.03.2026 & & 6. Meilenstein \\
|
||
\end{longtable}
|
||
|
||
\subsection{Projektumfeld Analyse}\label{projektumfeld-analyse}
|
||
|
||
\subsubsection{Grafische Darstellung}\label{grafische-darstellung}
|
||
|
||
\pandocbounded{\includegraphics[keepaspectratio]{39eb1359e85e22bd63fd1e8e89e8c71f3b107392.pdf}}
|
||
|
||
\subsubsection{Beschreibung der wichtigsten
|
||
Umfelder}\label{beschreibung-der-wichtigsten-umfelder}
|
||
|
||
\begin{longtable}[]{@{}llll@{}}
|
||
\caption{Projektumfelder und deren Bewertung}\tabularnewline
|
||
\toprule\noalign{}
|
||
ID & Name & Beschreibung & Bewertung \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
ID & Name & Beschreibung & Bewertung \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
8 & Konkurrenz & Potenziell vorhandene Konkurrenz & - \\
|
||
\end{longtable}
|
||
|
||
\subsection{Risikoanalyse}\label{risikoanalyse}
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 10\tabcolsep) * \real{0.0153}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 10\tabcolsep) * \real{0.0918}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 10\tabcolsep) * \real{0.6582}}
|
||
>{\centering\arraybackslash}p{(\linewidth - 10\tabcolsep) * \real{0.1122}}
|
||
>{\centering\arraybackslash}p{(\linewidth - 10\tabcolsep) * \real{0.0714}}
|
||
>{\centering\arraybackslash}p{(\linewidth - 10\tabcolsep) * \real{0.0510}}@{}}
|
||
\caption{Risikoanalyse und Bewertung}\tabularnewline
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
\#
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Bezeichnung
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\centering
|
||
Wahrscheinlichkeit (\%)
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\centering
|
||
Auswirkung (\%)
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\centering
|
||
Risikowert
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
\#
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Bezeichnung
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\centering
|
||
Wahrscheinlichkeit (\%)
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\centering
|
||
Auswirkung (\%)
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\centering
|
||
Risikowert
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
1 & Infrastruktur & {[}cite\_start{]}Instabilität oder Fehlkonfiguration
|
||
der Cloud-Server (Hetzner CX22), die den Live-Betrieb
|
||
unterbrechen{[}cite: 45, 51{]}. & 60 & 90 & 5400 \\
|
||
2 & Datenverlust & {[}cite\_start{]}Kritischer Ausfall der Datenbank
|
||
ohne erfolgreiche Wiederherstellung durch automatisierte Backups{[}cite:
|
||
51, 62{]}. & 15 & 95 & 1425 \\
|
||
3 & DSGVO-Verstoß & {[}cite\_start{]}Fehlende Konformität bei der
|
||
Speicherung personenbezogener Daten oder beim Opt-In-Verfahren{[}cite:
|
||
38, 39, 128{]}. & 10 & 100 & 1000 \\
|
||
4 & Sicherheitslücke & {[}cite\_start{]}Unbefugter Zugriff auf das
|
||
System durch Schwachstellen in der VPN- oder SSH-Verbindung{[}cite:
|
||
83{]}. & 15 & 85 & 1275 \\
|
||
5 & API-Schnittstellen & {[}cite\_start{]}Ausfall oder Inkompatibilität
|
||
externer Dienste wie LinkedIn OAuth oder Brevo Mailservice{[}cite: 74,
|
||
78{]}. & 30 & 50 & 1500 \\
|
||
6 & Performance & {[}cite\_start{]}Beeinträchtigung der Systemleistung
|
||
bei steigenden Zugriffszahlen in Phase 2{[}cite: 44, 46{]}. & 40 & 40 &
|
||
1600 \\
|
||
7 & Wiederherstellung & {[}cite\_start{]}Überschreitung des geplanten
|
||
Disaster-Recovery-Zeitraums von 24 Stunden{[}cite: 51, 66{]}. & 25 & 70
|
||
& 1750 \\
|
||
8 & Oqtane-Integration & {[}cite\_start{]}Komplexität bei der
|
||
Entwicklung und Einbindung benutzerdefinierter CMS-Module{[}cite: 69,
|
||
72{]}. & 30 & 45 & 1350 \\
|
||
9 & Dokumentation & {[}cite\_start{]}Lückenhafte technische
|
||
Dokumentation erschwert die Wartung durch den Absolventenverein{[}cite:
|
||
155{]}. & 20 & 30 & 600 \\
|
||
\end{longtable}
|
||
|
||
\subsubsection{Grafische Darstellung}\label{grafische-darstellung-1}
|
||
|
||
\pandocbounded{\includegraphics[keepaspectratio]{663e9454cc5dacd0b2a92b630e8be28bbcb7a29d.pdf}}
|
||
|
||
\subsection{Projektressourcen}\label{projektressourcen}
|
||
|
||
\subsubsection{2.6.3 Personelle Ressourcen
|
||
(geplant)}\label{personelle-ressourcen-geplant}
|
||
|
||
\begin{longtable}[]{@{}lc@{}}
|
||
\caption{Personelle Ressourcen}\tabularnewline
|
||
\toprule\noalign{}
|
||
Teammitglied & Personenstunden \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
Teammitglied & Personenstunden \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
\textbf{Konstantin Hintermayer} & 180 \\
|
||
\textbf{Florian Edlmayer} & 180 \\
|
||
\textbf{Adam Gaiswinkler} & 180 \\
|
||
\textbf{SUMME} & \textbf{540} \\
|
||
\end{longtable}
|
||
|
||
\subsubsection{Persönliche
|
||
Ressourcen(real)}\label{persuxf6nliche-ressourcenreal}
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.1692}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.2462}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.2462}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.3385}}@{}}
|
||
\caption{Persönliche Ressourcen(real)}\tabularnewline
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Monat/Datum
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Florian Edlmayer
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Adam Gaiswinkler
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Konstantin Hintermayer
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Monat/Datum
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Florian Edlmayer
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Adam Gaiswinkler
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Konstantin Hintermayer
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
30.05. & 1.0h & 1.0h & 0.2h \\
|
||
13.06. & 0.5h & 0.8h & 13.8h \\
|
||
27.06. & 1.2h & 2.1h & 1.5h \\
|
||
11.07. & 0.8h & 0.5h & 5.0h \\
|
||
25.07. & 1.5h & 1.2h & 2.5h \\
|
||
08.08. & 0.5h & 1.5h & 1.0h \\
|
||
22.08. & 1.0h & 2.0h & 1.8h \\
|
||
05.09. & 2.3h & 1.4h & 3.2h \\
|
||
19.09. & 1.8h & 2.8h & 4.5h \\
|
||
03.10. & 10.8h & 18.1h & 22.8h \\
|
||
17.10. & 1.0h & 5.5h & 10.8h \\
|
||
31.10. & 8.0h & 3.5h & 2.2h \\
|
||
14.11. & 3.8h & 10.0h & 5.0h \\
|
||
28.11. & 6.0h & 14.3h & 22.5h \\
|
||
12.12. & 25.0h & 20.0h & 30.0h \\
|
||
26.12. & 15.0h & 14.7h & 25.0h \\
|
||
09.01. & 3.0h & 20.0h & 25.0h \\
|
||
23.01. & 30.0h & 12.5h & 24.0h \\
|
||
06.02. & 17.5h & 47.9h & 16.0h \\
|
||
20.02. & 31.0h & 9.5h & 24.0h \\
|
||
06.03. & 42.9h & 24.0h & 8.7h \\
|
||
\textbf{Gesamt} & \textbf{204.6h} & \textbf{213.3h} & \textbf{249.5h} \\
|
||
\end{longtable}
|
||
|
||
\subsection{Projektmanagement mit
|
||
Scrum}\label{projektmanagement-mit-scrum}
|
||
|
||
\subsubsection{Grundlagen der
|
||
Scrum-Methode}\label{grundlagen-der-scrum-methode}
|
||
|
||
Für die Organisation und Umsetzung des Projekts wurde das agile
|
||
Projektmanagement-Framework Scrum verwendet. Scrum ist ein weit
|
||
verbreitetes Vorgehensmodell in der Softwareentwicklung, das besonders
|
||
für Projekte geeignet ist, bei denen sich Anforderungen im Laufe der
|
||
Entwicklung verändern können. Im Gegensatz zu klassischen
|
||
Projektmanagementmethoden arbeitet Scrum nicht mit einer vollständig im
|
||
Voraus geplanten Entwicklung, sondern mit kurzen, wiederkehrenden
|
||
Entwicklungszyklen.
|
||
|
||
Das zentrale Element von Scrum ist der sogenannte Sprint. Ein Sprint
|
||
stellt einen fest definierten Zeitraum dar, in dem bestimmte Funktionen
|
||
oder Anforderungen umgesetzt werden. In diesem Projekt betrug die Dauer
|
||
eines Sprints zwei Wochen. Innerhalb dieses Zeitraums arbeitete das
|
||
Entwicklungsteam daran, ausgewählte Aufgaben zu implementieren und am
|
||
Ende des Sprints ein funktionsfähiges Ergebnis zu präsentieren.
|
||
|
||
Die agile Arbeitsweise von Scrum basiert auf einer iterativen und
|
||
inkrementellen Entwicklung. Das bedeutet, dass die Software Schritt für
|
||
Schritt erweitert wird. Nach jedem Sprint steht eine neue Version der
|
||
Anwendung zur Verfügung, die zusätzliche Funktionen enthält. Dadurch
|
||
können Änderungen oder neue Anforderungen flexibel in zukünftige Sprints
|
||
integriert werden.
|
||
|
||
Die grundlegende Struktur und der Ablauf eines Scrum-Projekts sind in
|
||
Abbildung X dargestellt.
|
||
|
||
\pandocbounded{\includegraphics[keepaspectratio]{./images/02-Allgemein/scrum-framework.png}}
|
||
\emph{Abbildung X: Übersicht des Scrum-Frameworks mit Rollen, Artefakten
|
||
und Ereignissen}
|
||
|
||
Die Abbildung zeigt die wichtigsten Elemente des Scrum-Frameworks. Auf
|
||
der linken Seite sind die Anforderungen des Projekts dargestellt, die im
|
||
sogenannten Product Backlog gesammelt werden. Dieses Backlog enthält
|
||
alle geplanten Funktionen, Verbesserungen und Aufgaben des Projekts.
|
||
Diese Anforderungen stammen häufig von Stakeholdern oder zukünftigen
|
||
Benutzern der Anwendung.
|
||
|
||
Während der Sprintplanung wählt das Entwicklungsteam gemeinsam mit dem
|
||
Product Owner jene Aufgaben aus dem Product Backlog aus, die im nächsten
|
||
Sprint umgesetzt werden sollen. Diese Aufgaben werden anschließend im
|
||
Sprint Backlog gesammelt und bilden die Grundlage für die Arbeit während
|
||
des Sprints.
|
||
|
||
Im Zentrum der Abbildung befindet sich der Sprint-Zyklus, der
|
||
typischerweise zwischen einer und vier Wochen dauert. In diesem Projekt
|
||
wurde eine Sprintdauer von zwei Wochen festgelegt. Während dieser Phase
|
||
arbeitet das Entwicklungsteam an der Umsetzung der definierten Aufgaben.
|
||
Dabei durchläuft die Entwicklung mehrere Schritte, wie beispielsweise
|
||
Design, Entwicklung, Testen und Deployment.
|
||
|
||
Ein wichtiger Bestandteil des Scrum-Prozesses ist das Daily Scrum, ein
|
||
kurzes tägliches Meeting des Teams. In diesem Meeting berichten die
|
||
Teammitglieder über ihren aktuellen Fortschritt, geplante Aufgaben sowie
|
||
mögliche Hindernisse im Entwicklungsprozess. Ziel dieses Meetings ist
|
||
es, den Arbeitsfortschritt zu koordinieren und Probleme frühzeitig zu
|
||
erkennen.
|
||
|
||
Am Ende jedes Sprints findet das Sprint Review statt. Dabei präsentiert
|
||
das Entwicklungsteam die umgesetzten Funktionen des Produkts.
|
||
Stakeholder und Projektbeteiligte haben in diesem Meeting die
|
||
Möglichkeit, Feedback zu geben und neue Anforderungen einzubringen.
|
||
|
||
Anschließend folgt die Sprint Retrospective, in der das Team den Ablauf
|
||
des vergangenen Sprints reflektiert. Dabei wird analysiert, welche
|
||
Aspekte des Arbeitsprozesses gut funktioniert haben und welche
|
||
Verbesserungen für zukünftige Sprints möglich sind.
|
||
|
||
Durch diese strukturierte Vorgehensweise ermöglicht Scrum eine
|
||
kontinuierliche Weiterentwicklung der Software sowie eine regelmäßige
|
||
Überprüfung des Projektfortschritts.
|
||
|
||
\subsubsection{Rollenverteilung im
|
||
Projektteam}\label{rollenverteilung-im-projektteam}
|
||
|
||
Das Scrum-Framework definiert drei zentrale Rollen, die jeweils
|
||
unterschiedliche Aufgaben innerhalb des Projekts übernehmen. Diese
|
||
Rollen tragen dazu bei, Verantwortlichkeiten klar zu strukturieren und
|
||
den Entwicklungsprozess effizient zu gestalten.
|
||
|
||
Der Product Owner ist für die inhaltliche Planung des Produkts
|
||
verantwortlich. Zu seinen Aufgaben gehört die Verwaltung und
|
||
Priorisierung des Product Backlogs. Er entscheidet, welche Funktionen
|
||
oder Anforderungen für das Produkt am wichtigsten sind und sorgt dafür,
|
||
dass das Entwicklungsteam stets an den relevantesten Aufgaben arbeitet.
|
||
Außerdem fungiert der Product Owner als Verbindung zwischen Stakeholdern
|
||
und Entwicklungsteam.
|
||
|
||
Der Scrum Master unterstützt das Team bei der Anwendung der
|
||
Scrum-Methodik und stellt sicher, dass die Scrum-Prinzipien im Projekt
|
||
eingehalten werden. Zu seinen Aufgaben gehört unter anderem die
|
||
Organisation und Moderation der Scrum-Meetings. Darüber hinaus hilft er
|
||
dem Team dabei, Hindernisse im Entwicklungsprozess zu identifizieren und
|
||
zu beseitigen.
|
||
|
||
Das Entwicklungsteam ist für die technische Umsetzung der Anforderungen
|
||
verantwortlich. Es besteht aus den Entwicklern, die die Software planen,
|
||
implementieren, testen und integrieren. Das Team organisiert seine
|
||
Arbeit weitgehend selbstständig und entscheidet gemeinsam über die
|
||
technische Umsetzung der Aufgaben.
|
||
|
||
Durch diese klar definierten Rollen wird sichergestellt, dass
|
||
organisatorische und technische Aufgaben effizient verteilt werden
|
||
können und der Entwicklungsprozess strukturiert abläuft.
|
||
|
||
\subsubsection{Sprintplanung und
|
||
Umsetzung}\label{sprintplanung-und-umsetzung}
|
||
|
||
Die Sprintplanung stellt einen wichtigen Bestandteil des Scrum-Prozesses
|
||
dar. Zu Beginn jedes neuen Sprints trifft sich das Team, um gemeinsam zu
|
||
entscheiden, welche Aufgaben innerhalb des kommenden Zeitraums umgesetzt
|
||
werden sollen.
|
||
|
||
Als Grundlage dient das Product Backlog, in dem alle bekannten
|
||
Anforderungen des Projekts gesammelt werden. Während der Sprintplanung
|
||
wählt das Team jene Aufgaben aus, die innerhalb der nächsten zwei Wochen
|
||
realistisch umgesetzt werden können. Diese Aufgaben werden anschließend
|
||
in das Sprint Backlog übernommen.
|
||
|
||
Während des Sprints arbeitet das Entwicklungsteam an der Umsetzung
|
||
dieser Aufgaben. Die Arbeit wird dabei häufig in kleinere Teilaufgaben
|
||
unterteilt, um die Fortschritte besser verfolgen zu können.
|
||
|
||
Zur Koordination der täglichen Arbeit findet das sogenannte Daily Scrum
|
||
statt. Dieses kurze Meeting dauert in der Regel maximal 15 Minuten und
|
||
dient dazu, den aktuellen Stand der Entwicklung zu besprechen. Jedes
|
||
Teammitglied beantwortet dabei typischerweise drei Fragen:
|
||
|
||
• Was habe ich seit dem letzten Meeting erledigt? • Woran werde ich
|
||
heute arbeiten? • Welche Hindernisse gibt es aktuell?
|
||
|
||
Durch diese regelmäßige Abstimmung wird sichergestellt, dass alle
|
||
Teammitglieder über den aktuellen Projektstand informiert sind und
|
||
mögliche Probleme frühzeitig erkannt werden.
|
||
|
||
Am Ende eines Sprints werden die entwickelten Funktionen im Sprint
|
||
Review präsentiert. In diesem Meeting wird überprüft, welche
|
||
Anforderungen erfolgreich umgesetzt wurden und ob weitere Anpassungen
|
||
notwendig sind. Anschließend reflektiert das Team im Rahmen der Sprint
|
||
Retrospective den Arbeitsprozess und identifiziert mögliche
|
||
Verbesserungen für zukünftige Sprints.
|
||
|
||
\subsubsection{Vorteile von Scrum für die
|
||
Webentwicklung}\label{vorteile-von-scrum-fuxfcr-die-webentwicklung}
|
||
|
||
Die Verwendung von Scrum bietet insbesondere für Webentwicklungsprojekte
|
||
zahlreiche Vorteile. Webanwendungen entwickeln sich häufig dynamisch
|
||
weiter, da sich Anforderungen, Technologien oder Benutzerbedürfnisse im
|
||
Laufe der Zeit verändern können.
|
||
|
||
Durch die Aufteilung der Entwicklung in kurze Sprints kann das Projekt
|
||
flexibel auf solche Veränderungen reagieren. Neue Anforderungen können
|
||
einfach in zukünftige Sprints integriert werden, ohne den gesamten
|
||
Projektplan neu strukturieren zu müssen.
|
||
|
||
Ein weiterer Vorteil liegt in der kontinuierlichen Überprüfung der
|
||
entwickelten Funktionen. Da am Ende jedes Sprints ein funktionierender
|
||
Teil der Software präsentiert wird, können Fehler oder
|
||
Verbesserungsmöglichkeiten frühzeitig erkannt werden. Dies reduziert das
|
||
Risiko größerer Probleme in späteren Projektphasen.
|
||
|
||
Darüber hinaus fördert Scrum die Zusammenarbeit innerhalb des Teams.
|
||
Regelmäßige Meetings und eine transparente Aufgabenverteilung sorgen
|
||
dafür, dass alle Teammitglieder stets über den aktuellen Stand des
|
||
Projekts informiert sind.
|
||
|
||
Insgesamt ermöglicht Scrum eine strukturierte, flexible und transparente
|
||
Vorgehensweise bei der Entwicklung von Webanwendungen. Dadurch kann die
|
||
Qualität der entwickelten Software verbessert und der
|
||
Entwicklungsprozess effizienter gestaltet werden.
|
||
|
||
\cleardoublepage
|
||
|
||
\section{Adam Gaiswinkler}\label{adam-gaiswinkler-1}
|
||
|
||
\subsection{1. Einleitung des individuellen
|
||
Teils}\label{einleitung-des-individuellen-teils}
|
||
|
||
\subsubsection{1.1 Motivation}\label{motivation}
|
||
|
||
Zu Beginn des Projekts war meine persönliche Motivation überschaubar.
|
||
Wie viele Schulprojekte startete auch AlumniHub zunächst als eine
|
||
Pflichtaufgabe -- ich war zwar von Anfang an dabei, jedoch ohne
|
||
besonders großes Interesse am Thema. Das Projekt war zu Beginn eine von
|
||
vielen schulischen Anforderungen, und ich sah es zunächst nicht als
|
||
etwas, mit dem ich mich wirklich identifizieren würde. Die
|
||
Aufgabenstellung klang zwar interessant, aber der persönliche Bezug
|
||
fehlte noch.
|
||
|
||
Das änderte sich im Laufe des Projekts grundlegend -- und zwar durch
|
||
einen Umstand, den ich anfangs nicht als Chance gesehen hätte: die
|
||
Teamverkleinerung. Als das Team von ursprünglich sechs auf drei Personen
|
||
verkleinert wurde, änderte sich meine Rolle schlagartig. Plötzlich trug
|
||
ich deutlich mehr Verantwortung -- nicht nur für meinen eigenen Bereich,
|
||
sondern auch für das Gesamtprojekt. Aufgaben, die ursprünglich andere
|
||
übernehmen sollten, lagen nun in meinen Händen. Diese Situation zwang
|
||
mich, proaktiver zu handeln, eigenständiger zu entscheiden und tiefer in
|
||
die Materie einzutauchen als ursprünglich geplant.
|
||
|
||
Genau in diesem Moment begann mein Interesse zu wachsen. Je mehr
|
||
Verantwortung ich übernahm, desto mehr identifizierte ich mich mit dem
|
||
Projekt und seinen Zielen. Ich merkte, dass die Entscheidungen, die ich
|
||
traf, direkte Auswirkungen auf das Endergebnis hatten -- und das
|
||
motivierte mich, die Arbeit wirklich gut zu machen und nicht nur
|
||
fertigzustellen.
|
||
|
||
Die technische Herausforderung, eine moderne Webanwendung mit Blazor und
|
||
ASP.NET umzusetzen, sowie die Möglichkeit, ein echtes System für eine
|
||
reale Organisation zu entwickeln, wurden zur echten Motivation. Die
|
||
Aufgabenstellung bot mir die Chance, theoretisches Wissen aus dem
|
||
Unterricht in einem praxisnahen Umfeld anzuwenden und gleichzeitig einen
|
||
konkreten Mehrwert für den Absolventenverein zu schaffen. Rückblickend
|
||
war die Teamverkleinerung -- obwohl sie damals als Problem wahrgenommen
|
||
wurde -- einer der wichtigsten Faktoren für meine persönliche
|
||
Entwicklung im Rahmen dieses Projekts.
|
||
|
||
\subsubsection{1.2 Individuelle
|
||
Themenstellung}\label{individuelle-themenstellung}
|
||
|
||
Entwicklung des Anmeldetools und Hall-of-Fame-Moduls für Oqtane,
|
||
Integration in das bestehende CMS-System, Responsive UI-Entwicklung mit
|
||
Blazor und ASP.NET Core
|
||
|
||
\subsubsection{1.3 Teamrolle}\label{teamrolle}
|
||
|
||
Developer, Tester der eigenen Module
|
||
|
||
\subsubsection{1.4 Untersuchungsanliegen}\label{untersuchungsanliegen}
|
||
|
||
Modulentwicklung mit Blazor und ASP.NET Core, Integration eigenständiger
|
||
Module in die Oqtane-Architektur, Entwicklung reaktiver
|
||
Benutzeroberflächen mit Blazor-Komponenten, Responsive UI-Design mit
|
||
Bootstrap und eigenem CSS, PDF-Generierung mit QuestPDF, Fehlerbehebung
|
||
und Optimierung der mobilen Darstellung
|
||
|
||
\subsubsection{1.5 Persönlicher
|
||
Aufgabenbereich}\label{persuxf6nlicher-aufgabenbereich}
|
||
|
||
Der persönliche Aufgabenbereich umfasste die Entwicklung der beiden
|
||
zentralen CMS-Module der Plattform: das Anmeldetool für Veranstaltungen
|
||
sowie das Hall-of-Fame-Modul. Beide Module wurden als eigenständige,
|
||
wiederverwendbare Oqtane-Module konzipiert und vollständig in C\# und
|
||
Blazor implementiert. Neben der technischen Umsetzung lag ein besonderer
|
||
Fokus auf der Benutzerfreundlichkeit, der responsiven Darstellung und
|
||
der nahtlosen Integration in das bestehende CMS-System.
|
||
|
||
\subsubsection{1.6 Abgrenzung der Arbeit}\label{abgrenzung-der-arbeit}
|
||
|
||
Das Datenbankdesign sowie die Infrastruktur und das Server-Setup waren
|
||
nicht Teil meines persönlichen Aufgabenbereichs und wurden von anderen
|
||
Teammitgliedern verantwortet. Mein persönlicher Anteil beschränkt sich
|
||
auf die Entwicklung der Anwendungsschicht, konkret auf die
|
||
Implementierung der beiden CMS-Module -- das Anmeldetool und das
|
||
Hall-of-Fame-Modul -- sowie deren Integration in das bestehende System.
|
||
|
||
\subsection{2. Technologien}\label{technologien}
|
||
|
||
In diesem Kapitel werden die Technologien und Werkzeuge vorgestellt, die
|
||
für die Entwicklung des Anmeldetools, des Hall-of-Fame-Moduls und des
|
||
Oqtane-Themes eingesetzt wurden. Die Beschreibungen sind dabei so
|
||
gestaltet, dass sie auch für Leserinnen und Leser ohne technischen
|
||
Hintergrund verständlich sind.
|
||
|
||
\subsubsection{2.1 C\# und ASP.NET Core}\label{c-und-asp.net-core}
|
||
|
||
C\# ist eine moderne Programmiersprache von Microsoft, die besonders für
|
||
die Entwicklung von Webanwendungen und Softwaresystemen geeignet ist.
|
||
Sie ist klar strukturiert, gut lesbar und weit verbreitet in der
|
||
professionellen Softwareentwicklung. ASP.NET Core ist ein Framework --
|
||
also eine Art Werkzeugkasten -- das auf C\# aufbaut und die Entwicklung
|
||
von Webseiten und Webanwendungen vereinfacht.\footnote{Microsoft (2026a)
|
||
(siehe Internet-/Intranetverzeichnis).} Es stellt vorgefertigte
|
||
Bausteine bereit, sodass man nicht alles von Grund auf neu programmieren
|
||
muss. Für AlumniHub bildete ASP.NET Core die technische Grundlage aller
|
||
entwickelten Module.
|
||
|
||
\subsubsection{2.2 Blazor}\label{blazor}
|
||
|
||
Blazor ist ein Framework, das es ermöglicht, interaktive Weboberflächen
|
||
direkt in C\# zu entwickeln.\footnote{Microsoft (2026b) (siehe
|
||
Internet-/Intranetverzeichnis).} Normalerweise werden solche
|
||
Oberflächen -- also alles, was der Benutzer auf dem Bildschirm sieht und
|
||
mit dem er interagiert -- mit einer anderen Programmiersprache namens
|
||
JavaScript umgesetzt. Blazor erlaubt es, dasselbe in C\# zu schreiben,
|
||
was die Entwicklung vereinheitlicht und übersichtlicher macht. Konkret
|
||
bedeutet das: Wenn ein Benutzer beispielsweise auf den „Zusagen''-Button
|
||
klickt, reagiert die Seite sofort und aktualisiert sich automatisch --
|
||
ohne dass die gesamte Seite neu geladen werden muss.
|
||
|
||
\subsubsection{2.3 Oqtane}\label{oqtane}
|
||
|
||
Oqtane ist ein Content-Management-System (CMS) -- also eine Software,
|
||
mit der Webseiten und deren Inhalte verwaltet werden können, ähnlich wie
|
||
WordPress oder Typo3.\footnote{Oqtane Foundation (2026a) (siehe
|
||
Internet-/Intranetverzeichnis).} Das Besondere an Oqtane ist, dass es
|
||
vollständig auf Blazor und C\# aufbaut und eine modulare Architektur
|
||
besitzt: Man kann eigene Erweiterungen -- sogenannte Module --
|
||
entwickeln und in das System einbinden, ohne den Kern der Software
|
||
verändern zu müssen.\footnote{Oqtane Foundation (2026b) (siehe
|
||
Internet-/Intranetverzeichnis).} Für AlumniHub wurde Oqtane als
|
||
Grundlage gewählt, weil es Benutzerverwaltung, Seitenstruktur und viele
|
||
weitere Standardfunktionen bereits mitbringt und somit viel
|
||
Entwicklungsaufwand spart.
|
||
|
||
\subsubsection{2.4 Bootstrap und CSS}\label{bootstrap-und-css}
|
||
|
||
CSS (Cascading Style Sheets) ist die Sprache, mit der das Aussehen einer
|
||
Webseite festgelegt wird -- also Farben, Schriftarten, Abstände und das
|
||
Layout. Bootstrap ist eine fertige Sammlung von CSS-Regeln und
|
||
Hilfsmitteln, die von Twitter entwickelt wurde und kostenlos verfügbar
|
||
ist.\footnote{Bootstrap (2026) (siehe Internet-/Intranetverzeichnis).}
|
||
Der große Vorteil von Bootstrap ist, dass es sogenanntes Responsive
|
||
Design einfach umsetzbar macht: Die Webseite passt sich automatisch an
|
||
verschiedene Bildschirmgrößen an -- egal ob Desktop, Tablet oder
|
||
Smartphone. Für AlumniHub wurde Bootstrap als Basis verwendet, ergänzt
|
||
durch eigenes CSS für das individuelle Erscheinungsbild der Plattform.
|
||
|
||
\subsubsection{2.5 QuestPDF}\label{questpdf}
|
||
|
||
QuestPDF ist eine kostenlose Open-Source-Bibliothek -- also eine fertige
|
||
Programmsammlung -- die es ermöglicht, PDF-Dokumente direkt aus C\#-Code
|
||
heraus zu erstellen.\footnote{QuestPDF (2026) (siehe
|
||
Internet-/Intranetverzeichnis).} Anstatt ein PDF manuell zu gestalten,
|
||
beschreibt man im Code wie das Dokument aussehen soll, und QuestPDF
|
||
generiert daraus automatisch eine fertige PDF-Datei. Im
|
||
Hall-of-Fame-Modul wurde QuestPDF eingesetzt, um jedem Absolventen zu
|
||
ermöglichen, sein eigenes Profil als visuell ansprechendes PDF
|
||
herunterzuladen.
|
||
|
||
\subsubsection{2.6 Gitea}\label{gitea}
|
||
|
||
Wenn mehrere Personen gemeinsam an einem Softwareprojekt arbeiten,
|
||
braucht man ein System, das alle Änderungen am Code nachverfolgt und
|
||
verhindert, dass sich Änderungen verschiedener Personen gegenseitig
|
||
überschreiben. Dieses Konzept nennt sich Versionskontrolle. Gitea ist
|
||
eine selbst gehostete Plattform für genau diesen Zweck -- ähnlich wie
|
||
GitHub, aber auf einem eigenen Server betrieben.\footnote{Gitea (2026)
|
||
(siehe Internet-/Intranetverzeichnis).} Jede Änderung am Code wird als
|
||
sogenannter „Commit'' gespeichert, sodass man jederzeit nachvollziehen
|
||
kann, wer wann was geändert hat, und bei Bedarf auf eine ältere Version
|
||
zurückwechseln kann.
|
||
|
||
\subsubsection{2.7 Entwicklungsumgebung}\label{entwicklungsumgebung}
|
||
|
||
Eine Entwicklungsumgebung -- auch IDE (Integrated Development
|
||
Environment) genannt -- ist ein Programm, das Entwicklerinnen und
|
||
Entwickler beim Schreiben von Code unterstützt. Sie bietet unter anderem
|
||
Funktionen wie automatische Vervollständigung, Fehlererkennung und
|
||
integrierte Debugging-Werkzeuge, die das Auffinden und Beheben von
|
||
Fehlern im Code erleichtern.
|
||
|
||
Zu Beginn des Projekts wurde Visual Studio 2022 auf Windows verwendet.
|
||
Visual Studio 2022 ist die führende Entwicklungsumgebung von Microsoft
|
||
für .NET-Projekte und bietet eine umfangreiche Unterstützung für ASP.NET
|
||
Core und Blazor. Im Laufe des Projekts erfolgte jedoch ein Wechsel von
|
||
Windows auf macOS. Da Visual Studio 2022 auf Mac nicht mehr verfügbar
|
||
ist -- Microsoft hat die Mac-Version eingestellt -- wurde als Ersatz
|
||
JetBrains Rider eingesetzt.\footnote{JetBrains (2026) (siehe
|
||
Internet-/Intranetverzeichnis).} JetBrains Rider ist eine
|
||
next-generation IDE von JetBrains, die plattformübergreifend
|
||
funktioniert und eine moderne Entwicklungsumgebung für .NET-Projekte auf
|
||
macOS bietet. Der Umstieg auf JetBrains Rider ermöglichte es, die
|
||
Entwicklung auf dem neuen System ohne größere Unterbrechungen
|
||
fortzusetzen.
|
||
|
||
\subsubsection{2.8 Plattformwechsel: Windows zu
|
||
macOS}\label{plattformwechsel-windows-zu-macos}
|
||
|
||
Ein besonderer Aspekt der Entwicklung war der Wechsel von Windows auf
|
||
macOS während des Projektverlaufs. Unter Plattform versteht man in der
|
||
Softwareentwicklung das Betriebssystem, auf dem eine Anwendung läuft --
|
||
also etwa Windows, macOS oder Linux. Dieser Wechsel brachte spezifische
|
||
Herausforderungen mit sich, da Oqtane primär für Windows entwickelt
|
||
wurde. Obwohl Oqtane grundsätzlich auch auf macOS und Linux lauffähig
|
||
ist, ist die Unterstützung für diese Plattformen veraltet und nicht
|
||
vollständig angepasst. In der Praxis bedeutete das: Der Code ließ sich
|
||
teilweise nicht fehlerfrei kompilieren -- also in ein lauffähiges
|
||
Programm umwandeln -- und Oqtane startete zunächst nur mit
|
||
Fehlermeldungen. Durch den Einsatz von JetBrains Rider als IDE konnten
|
||
diese Probleme weitgehend gelöst werden, da JetBrains Rider eine bessere
|
||
plattformübergreifende Integration bietet als die ursprünglich
|
||
verwendete Entwicklungsumgebung.
|
||
|
||
\subsection{3. Module}\label{module}
|
||
|
||
\subsubsection{3.1 Entwicklung des Oqtane
|
||
Themes}\label{entwicklung-des-oqtane-themes}
|
||
|
||
\paragraph{3.1.1 Ziel des Themes}\label{ziel-des-themes}
|
||
|
||
Im Rahmen des Projekts AlumniHub wurde ein eigenes Theme für das
|
||
Content-Management-System Oqtane entwickelt. Ziel dieser Entwicklung war
|
||
es, das Standarddesign von Oqtane vollständig durch eine
|
||
projektspezifische Benutzeroberfläche zu ersetzen, die den Anforderungen
|
||
des Absolventenvereins der HTL Ungargasse entspricht. Das Standardtheme
|
||
von Oqtane ist funktional, jedoch generisch gehalten und bietet keinen
|
||
Bezug zur Schule oder zum Projekt. Aus diesem Grund wurde frühzeitig die
|
||
Entscheidung getroffen, ein vollständig eigenes Theme zu entwickeln, das
|
||
sowohl optisch als auch technisch auf die Bedürfnisse der Plattform
|
||
zugeschnitten ist.
|
||
|
||
Das visuelle Design orientiert sich dabei am bestehenden
|
||
Erscheinungsbild der offiziellen Schulwebseite szu.at. Es wurde bewusst
|
||
ein schlichtes Grau-Weiß-Farbschema gewählt, das eine klare,
|
||
professionelle und zeitlose Optik erzeugt. Auf auffällige Farben oder
|
||
komplexe Animationen wurde verzichtet, um die Inhalte in den Vordergrund
|
||
zu stellen und eine ruhige Benutzeroberfläche zu schaffen, die für ein
|
||
breites Publikum -- von Schülerinnen und Schülern über Lehrkräfte bis
|
||
hin zu ehemaligen Absolventinnen und Absolventen -- zugänglich ist.
|
||
|
||
Neben der visuellen Gestaltung standen auch technische Anforderungen im
|
||
Mittelpunkt. Das Theme sollte auf unterschiedlichen Endgeräten -- sowohl
|
||
auf Desktop-Computern als auch auf Smartphones und Tablets --
|
||
zuverlässig und benutzerfreundlich funktionieren. Responsive Design war
|
||
daher von Anfang an eine zentrale Anforderung. Darüber hinaus sollte das
|
||
Theme vollständig in die Oqtane-Architektur integriert sein, sodass alle
|
||
Standardfunktionen des CMS wie Benutzerverwaltung, Seitenverwaltung und
|
||
Modulintegration weiterhin ohne Einschränkungen genutzt werden können.
|
||
|
||
\paragraph{3.1.2 Technische Umsetzung}\label{technische-umsetzung}
|
||
|
||
Als technische Grundlage diente die Theme-Architektur von Oqtane. Das
|
||
Layout wurde in einer zentralen Razor-Datei (\texttt{Theme.razor})
|
||
definiert, welche von der Basisklasse \texttt{ThemeBase} erbt. Durch
|
||
diese Vererbung stehen im Theme automatisch zentrale Funktionen des
|
||
Frameworks zur Verfügung, darunter der Seitenzustand
|
||
(\texttt{PageState}), Navigationsdaten, Systemeinstellungen sowie
|
||
Informationen über den aktuell angemeldeten Benutzer. Dies ermöglicht
|
||
eine tiefe Integration des Themes in das CMS, ohne dass zusätzliche
|
||
Schnittstellen oder externe Datenzugriffe notwendig sind.
|
||
|
||
\subparagraph{3.1.2.1 Navigationsleiste}\label{navigationsleiste}
|
||
|
||
Ein zentrales Element des Themes ist die fixierte Navigationsleiste am
|
||
oberen Rand der Seite. Sie ist in drei klar voneinander getrennte
|
||
Bereiche gegliedert: Auf der linken Seite befindet sich das Logo der HTL
|
||
Ungargasse, das als visuelles Erkennungsmerkmal der Schule dient und
|
||
beim Klick zur Startseite führt. In der Mitte werden die
|
||
Navigationspunkte der Plattform angezeigt, die dynamisch aus der
|
||
Seitenstruktur des CMS generiert werden. Auf der rechten Seite befinden
|
||
sich die Benutzerfunktionen, also Login, Registrierung und bei
|
||
angemeldeten Benutzern ein Link zum eigenen Profil.
|
||
|
||
Die dynamische Generierung der Navigationspunkte stellte dabei eine
|
||
besondere Herausforderung dar. Das Oqtane-Framework stellt standardmäßig
|
||
eine \texttt{\textless{}Menu\textgreater{}}-Komponente bereit, die
|
||
automatisch alle im System registrierten Seiten in der Navigation
|
||
anzeigt. Diese Komponente gibt jedoch nicht nur öffentlich sichtbare
|
||
Inhaltsseiten aus, sondern auch interne Systemseiten wie Login,
|
||
Register, Reset, Profile, Search, Privacy, Terms, Not Found oder Admin.
|
||
Diese Seiten sind für den normalen Benutzer nicht relevant und sollten
|
||
daher nicht in der Hauptnavigation erscheinen.
|
||
|
||
Da die Standardkomponente das Burger-Menü automatisch generierte und
|
||
keine Möglichkeit bot, dieses individuell anzupassen, wurde auf sie
|
||
verzichtet. Da ein eigenes, maßgeschneidertes Burger-Menü benötigt
|
||
wurde, wurde stattdessen eine vollständig eigene Navigation
|
||
implementiert. Dabei wurde auf die Basisklassen \texttt{MenuBase} und
|
||
\texttt{MenuItemsBase} zurückgegriffen, die von Oqtane bereitgestellt
|
||
werden und den Zugriff auf die Seitenliste ermöglichen. Die
|
||
Navigationspunkte werden direkt über \texttt{PageState.Pages} abgerufen
|
||
und anschließend mittels LINQ gefiltert. Dabei werden nur Root-Seiten
|
||
berücksichtigt, also Seiten ohne übergeordnete Seite
|
||
(\texttt{ParentId\ ==\ null}), die als Navigationsseite markiert sind
|
||
und nicht in einer manuell definierten Ausschlussliste
|
||
(\texttt{hiddenNames}) stehen.
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\DataTypeTok{var}\NormalTok{ hiddenNames }\OperatorTok{=} \KeywordTok{new}\OperatorTok{[]}
|
||
\OperatorTok{\{}
|
||
\StringTok{"Login"}\OperatorTok{,} \StringTok{"Register"}\OperatorTok{,} \StringTok{"Reset"}\OperatorTok{,} \StringTok{"Profile"}\OperatorTok{,}
|
||
\StringTok{"Search"}\OperatorTok{,} \StringTok{"Privacy"}\OperatorTok{,} \StringTok{"Terms"}\OperatorTok{,} \StringTok{"Not Found"}\OperatorTok{,} \StringTok{"Admin"}
|
||
\OperatorTok{\};}
|
||
|
||
\KeywordTok{foreach} \OperatorTok{(}\DataTypeTok{var}\NormalTok{ item }\KeywordTok{in}\NormalTok{ PageState}\OperatorTok{.}\FunctionTok{Pages}
|
||
\OperatorTok{.}\FunctionTok{Where}\OperatorTok{(}\NormalTok{p }\OperatorTok{=\textgreater{}}\NormalTok{ p}\OperatorTok{.}\FunctionTok{ParentId} \OperatorTok{==} \KeywordTok{null}
|
||
\OperatorTok{\&\&} \OperatorTok{!}\NormalTok{hiddenNames}\OperatorTok{.}\FunctionTok{Contains}\OperatorTok{(}\NormalTok{p}\OperatorTok{.}\FunctionTok{Name}\OperatorTok{)))}
|
||
\OperatorTok{\{}
|
||
\NormalTok{ @item}\OperatorTok{.}\FunctionTok{Name}
|
||
\OperatorTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Durch diesen Ansatz werden ausschließlich die für Benutzer relevanten
|
||
Inhaltsseiten in der Navigation angezeigt. Gleichzeitig bleibt die
|
||
Navigation vollständig dynamisch: Werden im CMS neue Seiten angelegt und
|
||
als Navigationsseiten markiert, erscheinen diese automatisch im Menü,
|
||
ohne dass eine Anpassung am Theme-Code notwendig ist.
|
||
|
||
!{[}Abbildung 4.2: Filterlogik der Oqtane-Navigation{]}
|
||
(./images/06-Adam/navigationsfilter\_v2.svg) \emph{Abbildung 4.2:
|
||
Filterlogik zur Bereinigung der Oqtane-Navigation (Theme.razor)} Dies
|
||
reduziert den Wartungsaufwand erheblich und stellt sicher, dass die
|
||
Navigation stets dem aktuellen Stand der Plattform entspricht.
|
||
|
||
\subparagraph{3.1.2.2 Responsive Design und
|
||
Burger-Menü}\label{responsive-design-und-burger-menuxfc}
|
||
|
||
Da die Plattform auch auf mobilen Endgeräten genutzt werden soll, war
|
||
die Umsetzung eines responsiven Layouts eine wichtige Anforderung. Auf
|
||
Desktop-Geräten werden alle Navigationspunkte direkt in der
|
||
Navigationsleiste angezeigt. Auf kleineren Bildschirmen wie Smartphones
|
||
oder Tablets würde dies jedoch zu Platzproblemen führen, da die Anzahl
|
||
der Navigationspunkte die verfügbare Breite überschreiten kann.
|
||
|
||
Aus diesem Grund wurde für mobile Endgeräte ein sogenanntes Burger-Menü
|
||
implementiert. Dabei handelt es sich um ein Icon mit drei horizontalen
|
||
Linien, das auf kleinen Bildschirmen anstelle der ausgeschriebenen
|
||
Navigationspunkte angezeigt wird. Beim Anklicken öffnet sich eine
|
||
seitliche Sidebar, in der alle Navigationspunkte vertikal untereinander
|
||
dargestellt werden. Die Sidebar ist so aufgebaut, dass der obere Bereich
|
||
die Navigationspunkte enthält und bei einer großen Anzahl von Einträgen
|
||
gescrollt werden kann. Am unteren Rand der Sidebar sind die Login- und
|
||
Registrierungsfunktionen fixiert, sodass diese unabhängig von der Anzahl
|
||
der Navigationspunkte immer sichtbar und erreichbar sind.
|
||
|
||
Die technische Umsetzung des Burger-Menüs basiert auf einer
|
||
CSS-Checkbox-Lösung. Das Öffnen und Schließen der Sidebar wird über den
|
||
Zustand einer versteckten Checkbox gesteuert, der mittels CSS-Selektoren
|
||
ausgewertet wird. Dieser Ansatz ermöglicht eine funktionsfähige mobile
|
||
Navigation ohne den Einsatz zusätzlicher JavaScript-Frameworks oder
|
||
komplexer Logik. Die gesamte Darstellungslogik -- also welche Elemente
|
||
auf welcher Bildschirmgröße sichtbar sind -- wird über CSS Media Queries
|
||
gesteuert, die zwischen der Desktop- und der mobilen Ansicht
|
||
unterscheiden.
|
||
|
||
\subparagraph{3.1.2.3 Pane-Struktur}\label{pane-struktur}
|
||
|
||
Für den Inhaltsbereich der Plattform wurden mehrere sogenannte Panes
|
||
definiert. Panes sind in Oqtane Platzhalter-Bereiche innerhalb eines
|
||
Themes, in die später Module oder Inhalte eingefügt werden können. Durch
|
||
die Definition mehrerer Panes mit unterschiedlichen Breiten und
|
||
Positionen können Seiten sehr flexibel und ohne Änderungen am Theme-Code
|
||
strukturiert werden.
|
||
|
||
Im entwickelten Theme stehen unter anderem folgende Panes zur Verfügung:
|
||
ein vollbreiter Bereich oben (\texttt{Top\ 100\%}), ein linker Bereich
|
||
(\texttt{Left\ 50\%}), eine rechte Seitenleiste
|
||
(\texttt{Right\ Sidebar\ 33\%}) sowie ein vollbreiter Bereich am unteren
|
||
Rand (\texttt{Bottom\ 100\%}). Diese Struktur ermöglicht es, Seiten
|
||
sowohl ein- als auch mehrspaltig aufzubauen, je nach den Anforderungen
|
||
des jeweiligen Inhalts.
|
||
|
||
\subparagraph{3.1.2.4 Weitere
|
||
Integrationen}\label{weitere-integrationen}
|
||
|
||
Neben Navigation und Layout wurden weitere Funktionen in das Theme
|
||
integriert. Die Cookie-Consent-Komponente von Oqtane wurde eingebunden,
|
||
sodass beim ersten Besuch der Plattform ein Hinweis zur Verwendung von
|
||
Cookies angezeigt wird. Diese Funktion ist über die Site-Einstellungen
|
||
von Oqtane steuerbar, das Theme rendert lediglich die entsprechende
|
||
Komponente.
|
||
|
||
Darüber hinaus wurde das ControlPanel von Oqtane integriert, das
|
||
Administratorinnen und Administratoren direkten Zugriff auf
|
||
Verwaltungsfunktionen bietet. Login- und Registrierungsoptionen werden
|
||
über den \texttt{SettingService} aus den Site-Einstellungen geladen,
|
||
sodass diese Funktionen ohne Anpassungen am Code aktiviert oder
|
||
deaktiviert werden können.
|
||
|
||
\paragraph{3.1.3 Herausforderungen}\label{herausforderungen}
|
||
|
||
Die eigene Implementierung der Navigation über \texttt{PageState.Pages}
|
||
und eine LINQ-basierte Filterlogik erwies sich als die richtige
|
||
Entscheidung. Sie löste nicht nur das Problem der fehlenden
|
||
Anpassbarkeit der Standardkomponente, sondern brachte gleichzeitig einen
|
||
wesentlichen Mehrwert: Die Navigation ist vollständig wartungsfrei.
|
||
Werden im CMS neue Seiten angelegt, erscheinen diese automatisch im Menü
|
||
-- ohne dass eine einzige Zeile Code angepasst werden muss. Zudem
|
||
ermöglichte dieser Ansatz die vollständige Kontrolle über das
|
||
Erscheinungsbild des Burger-Menüs, was mit der Standardkomponente nicht
|
||
möglich gewesen wäre.
|
||
|
||
\subsubsection{3.2 Anmeldetool}\label{anmeldetool}
|
||
|
||
\paragraph{3.2.1 Ziel des Moduls}\label{ziel-des-moduls}
|
||
|
||
Das Anmeldetool wurde entwickelt, um Mitgliedern des Absolventenvereins
|
||
eine einfache und strukturierte Möglichkeit zu bieten, sich zu
|
||
Veranstaltungen und Treffen an- oder abzumelden. Ziel des Moduls ist es,
|
||
den organisatorischen Aufwand bei der Planung und Verwaltung von Treffen
|
||
deutlich zu reduzieren und gleichzeitig eine benutzerfreundliche
|
||
Oberfläche für alle Beteiligten bereitzustellen.
|
||
|
||
Das Modul wurde als zusätzliche Funktionserweiterung in das bestehende
|
||
Content-Management-System integriert. Es ermöglicht sowohl die
|
||
Verwaltung der Veranstaltungen auf Seiten der Organisatoren als auch
|
||
eine intuitive Interaktion für die Teilnehmerinnen und Teilnehmer. Durch
|
||
den Einsatz moderner Webtechnologien konnte dabei eine reaktionsschnelle
|
||
und geräteübergreifend nutzbare Lösung geschaffen werden.
|
||
|
||
\paragraph{3.2.2 Frontend (Eingabemaske)}\label{frontend-eingabemaske}
|
||
|
||
Die Benutzeroberfläche des Anmeldetools wurde mithilfe von Blazor
|
||
realisiert, einem Framework der ASP.NET-Technologieplattform, das die
|
||
Entwicklung interaktiver Weboberflächen in C\# ermöglicht. Die
|
||
Eingabemaske wurde als eigenständige Blazor-Komponente implementiert,
|
||
die flexibel in verschiedene Seiten der Anwendung eingebettet werden
|
||
kann.
|
||
|
||
Beim Aufruf der Seite wird dem Benutzer zunächst eine kurze Beschreibung
|
||
der jeweiligen Veranstaltung angezeigt. Im Anschluss stehen zwei klar
|
||
gekennzeichnete Schaltflächen zur Verfügung: Zusagen zur Bestätigung der
|
||
Teilnahme sowie Absagen zur Ablehnung. Die Schaltflächen wurden farblich
|
||
differenziert gestaltet -- eine grüne Hervorhebung signalisiert die
|
||
Zusage, eine rote Darstellung steht für die Absage. Diese Gestaltung
|
||
orientiert sich an etablierten Designkonventionen moderner
|
||
Webanwendungen und verbessert die intuitive Bedienbarkeit erheblich.
|
||
Darüber hinaus wurde besonderer Wert auf eine responsive Darstellung
|
||
gelegt, damit das Tool sowohl auf Desktop-Geräten als auch auf
|
||
Smartphones und Tablets problemlos genutzt werden kann.
|
||
|
||
\paragraph{3.2.3 API-Schnittstelle}\label{api-schnittstelle}
|
||
|
||
Die Anbindung des Anmeldetools an das bestehende CMS erfolgt über klar
|
||
definierte Schnittstellen innerhalb der ASP.NET-Architektur. Die
|
||
Komponente kommuniziert mit dem Backend, um Veranstaltungsdaten
|
||
abzurufen sowie Anmelde- und Absagestatus der Teilnehmenden zu
|
||
übermitteln und zu persistieren.
|
||
|
||
Die Datenübertragung erfolgt nach dem Prinzip der sauberen
|
||
Komponentenarchitektur: Die Blazor-Komponente ist als eigenständige
|
||
Einheit konzipiert, die über Parameter und Rückruffunktionen mit
|
||
übergeordneten Seitenkomponenten kommuniziert. Diese Struktur
|
||
gewährleistet eine klare Trennung zwischen Darstellungslogik und
|
||
Datenzugriff und erleichtert zukünftige Erweiterungen der Schnittstelle
|
||
erheblich.
|
||
|
||
\paragraph{3.2.4 Datenauswertung}\label{datenauswertung}
|
||
|
||
Die im Anmeldetool erfassten Daten bilden die Grundlage für die
|
||
Verwaltung und Auswertung von Veranstaltungsteilnahmen. Organisatoren
|
||
können auf Basis der gespeicherten An- und Abmeldungen die
|
||
Teilnehmerzahlen einsehen und die Planung entsprechend anpassen.
|
||
|
||
Die Architektur des Moduls ist bereits auf zukünftige Erweiterungen
|
||
ausgelegt. Geplante Erweiterungen umfassen eine übersichtliche
|
||
Teilnehmerliste mit Namen und Anmeldestatus, die Möglichkeit, eine
|
||
maximale Teilnehmeranzahl je Veranstaltung festzulegen sowie eine
|
||
direkte Speicherung und Auswertung der Anmeldedaten in einer Datenbank.
|
||
Durch diese Erweiterungen soll das Anmeldetool künftig nicht nur als
|
||
Interaktionselement für Teilnehmer, sondern auch als vollwertiges
|
||
Verwaltungswerkzeug für Veranstaltungsorganisatoren dienen.
|
||
|
||
\paragraph{3.2.5 UX-Überlegungen (User
|
||
Experience)}\label{ux-uxfcberlegungen-user-experience}
|
||
|
||
Ein zentraler Aspekt bei der Entwicklung des Anmeldetools war die
|
||
Benutzerfreundlichkeit der Oberfläche. UX (User Experience) bezeichnet
|
||
dabei die Gesamtheit aller Erfahrungen, die ein Benutzer bei der
|
||
Interaktion mit einer Anwendung macht -- von der visuellen Gestaltung
|
||
über die Bedienbarkeit bis hin zur allgemeinen Zufriedenheit mit dem
|
||
System. Die Module wurden so gestaltet, dass Benutzerinnen und Benutzer
|
||
die Funktionen ohne zusätzliche Schulung verwenden können. Eine klare
|
||
Struktur, eine intuitive Bedienung sowie ein konsistentes
|
||
Erscheinungsbild innerhalb des bestehenden Systems standen dabei im
|
||
Vordergrund.
|
||
|
||
Während der Testphase wurden mehrere visuelle Darstellungsprobleme
|
||
identifiziert und behoben. Dazu zählten Fehler bei der
|
||
Overlay-Darstellung -- insbesondere in Bezug auf Hintergrundfarben,
|
||
Transparenzen und z-Index-Ebenen -- sowie sogenannte Clipping-Fehler auf
|
||
mobilen Endgeräten, bei denen Inhalte teilweise abgeschnitten oder
|
||
außerhalb des sichtbaren Bereichs angezeigt wurden. Die Layoutstruktur
|
||
und Elementgrößen wurden angepasst, ausreichende Abstände zu
|
||
Seitenrändern sichergestellt und Tests auf verschiedenen Browser- und
|
||
Gerätevarianten durchgeführt.
|
||
|
||
Diese Maßnahmen stellen einen ersten Schritt in der kontinuierlichen
|
||
Verbesserung der mobilen Benutzeroberfläche dar. Weitere
|
||
Feinabstimmungen sind geplant, um das Anmeldetool langfristig als
|
||
stabile, benutzerfreundliche und geräteübergreifend konsistente Lösung
|
||
zu etablieren.
|
||
|
||
\subsubsection{3.3 Hall of Fame}\label{hall-of-fame}
|
||
|
||
Das Hall-of-Fame-Modul ist ein zentrales Modul der AlumniHub-Plattform.
|
||
Es dient dazu, ehemalige Absolventinnen und Absolventen der HTL
|
||
Ungargasse sichtbar zu machen und ihre beruflichen Werdegänge zu
|
||
präsentieren. Das Modul wurde als eigenständiges, wiederverwendbares
|
||
Oqtane-Modul entwickelt und ermöglicht es registrierten Benutzerinnen
|
||
und Benutzern, sich selbst mit einem persönlichen Profil einzutragen.
|
||
|
||
\paragraph{3.3.1 Benutzeroberfläche}\label{benutzeroberfluxe4che}
|
||
|
||
Die Benutzeroberfläche des Moduls besteht aus mehreren Komponenten, die
|
||
zusammen eine vollständige und benutzerfreundliche Verwaltung der
|
||
Hall-of-Fame-Einträge ermöglichen.
|
||
|
||
\subparagraph{3.3.1.1 Übersichtsseite
|
||
(Index.razor)}\label{uxfcbersichtsseite-index.razor}
|
||
|
||
Die Hauptseite der Hall of Fame ist die erste Seite, die Besucherinnen
|
||
und Besucher zu sehen bekommen. Sie zeigt alle veröffentlichten Einträge
|
||
in einem responsiven Kartenlayout. Auf Desktop-Geräten werden die Karten
|
||
in drei Spalten nebeneinander dargestellt, auf kleineren Bildschirmen
|
||
passt sich das Layout automatisch an und zeigt die Karten einspaltig
|
||
untereinander an.
|
||
|
||
Jede Karte enthält das Foto der jeweiligen Person als großes
|
||
Vorschaubild im oberen Bereich. Darunter werden Name und
|
||
Abschlussjahrgang als Überschrift angezeigt. Im unteren Bereich der
|
||
Karte befindet sich ein Teaser der Beschreibung, also ein kurzer
|
||
Ausschnitt aus dem Werdegang der Person. Da Beschreibungen
|
||
unterschiedlich lang sein können, wurde die Kartenhöhe durch eine
|
||
Kombination aus CSS-Flexbox und einer Maximalhöhe mit
|
||
\texttt{overflow:\ hidden} vereinheitlicht. Dadurch weisen alle Karten
|
||
in einer Zeile dieselbe Höhe auf, was ein sauberes und gleichmäßiges
|
||
Erscheinungsbild der Übersichtsseite gewährleistet. Am unteren Rand
|
||
jeder Karte befindet sich ein „Details ansehen''-Button, der die
|
||
Besucherin oder den Besucher zur vollständigen Detailseite des Eintrags
|
||
weiterleitet.
|
||
|
||
Über der Kartenliste befindet sich eine Filterleiste mit einer
|
||
Suchfunktion und einer Sortieroption. Die Suchleiste ermöglicht eine
|
||
Echtzeit-Suche über Name und Beschreibung aller Einträge -- die
|
||
Ergebnisse aktualisieren sich direkt beim Tippen, ohne dass die Seite
|
||
neu geladen werden muss. Neben der Suchleiste befindet sich ein
|
||
Sortier-Dropdown, über das zwischen verschiedenen Sortierkriterien
|
||
gewählt werden kann, darunter Datum, Name und Jahrgang. Ein
|
||
Toggle-Button mit dynamischem Pfeil-Icon ermöglicht das Umschalten
|
||
zwischen aufsteigender und absteigender Sortierrichtung.
|
||
|
||
Für angemeldete Benutzerinnen und Benutzer wird im oberen rechten
|
||
Bereich der Seite ein zusätzlicher Button angezeigt. Hat die Person noch
|
||
keinen eigenen Eintrag erstellt, erscheint ein „Eintragen''-Button.
|
||
Existiert bereits ein Eintrag, ändert sich der Button automatisch zu
|
||
„Mein Eintrag'', über den der bestehende Eintrag bearbeitet werden kann.
|
||
Administratorinnen und Administratoren sehen zusätzlich Warnhinweise bei
|
||
gemeldeten Einträgen sowie einen Lösch-Button bei jedem Eintrag.
|
||
|
||
\subparagraph{3.3.1.2 Detailseite
|
||
(Details.razor)}\label{detailseite-details.razor}
|
||
|
||
Die Detailseite zeigt einen einzelnen Hall-of-Fame-Eintrag in seiner
|
||
vollständigen Form. Das Layout ist zweispaltig aufgebaut: Auf der linken
|
||
Seite befindet sich das Foto der Person, eingebettet in einen unscharfen
|
||
Bildhintergrund, der dasselbe Foto in einer größeren, weichgezeichneten
|
||
Version als Hintergrund verwendet. Dieser Effekt verleiht der Seite eine
|
||
moderne und ansprechende Optik. Das eigentliche Foto ist dabei als klar
|
||
umrandetes Porträtbild in der Mitte des linken Bereichs positioniert.
|
||
|
||
Auf der rechten Seite werden zunächst eine Breadcrumb-Navigation („Hall
|
||
of Fame / Details'') sowie Name und Jahrgang der Person angezeigt. Der
|
||
Jahrgang wird in blauer Schrift als „Absolvent des Jahrgangs
|
||
{[}Jahr{]}'' dargestellt, was einen visuellen Akzent setzt und den
|
||
Jahrgang klar hervorhebt. Darunter folgt die vollständige Beschreibung
|
||
unter der Überschrift „Werdegang \& Erfolge''.
|
||
|
||
Am unteren Rand der Seite befinden sich je nach Konfiguration des
|
||
Eintrags bis zu vier Buttons. Der „PDF Vorschau''-Button öffnet einen
|
||
modalen Dialog mit einer vollständigen Vorschau des generierten PDFs
|
||
sowie einem „Herunterladen''-Button. Der „Zurück''-Button führt zurück
|
||
zur Übersichtsseite. Falls die Person einen optionalen Link hinterlegt
|
||
hat, wird zusätzlich ein „Webseite besuchen''-Button angezeigt, der die
|
||
Besucherin oder den Besucher direkt zur externen Webseite der Person
|
||
führt. Für eingeloggte Benutzer gibt es außerdem einen „Melden''-Button,
|
||
über den ein Eintrag gemeldet werden kann.
|
||
|
||
\subparagraph{3.3.1.3 Edit-Seite
|
||
(Edit.razor)}\label{edit-seite-edit.razor}
|
||
|
||
Die Edit-Komponente dient sowohl zum Erstellen eines neuen Eintrags als
|
||
auch zum Bearbeiten eines bestehenden. Das Formular ist klar
|
||
strukturiert und enthält alle notwendigen Felder für einen vollständigen
|
||
Hall-of-Fame-Eintrag.
|
||
|
||
Das Formular enthält zunächst ein Textfeld für den Namen der Person
|
||
sowie ein Zahlenfeld für den Abschlussjahrgang. Für die Beschreibung
|
||
wird ein Rich-Text-Editor eingesetzt, der Formatierungsmöglichkeiten wie
|
||
Fett, Kursiv, Listen und weitere Optionen bietet. Unterhalb des Editors
|
||
wird ein Live-Zeichenzähler angezeigt, der die aktuelle Zeichenanzahl in
|
||
Echtzeit aktualisiert und die maximal erlaubte Zeichenanzahl von 504
|
||
Zeichen anzeigt. Dadurch sehen Benutzerinnen und Benutzer jederzeit, wie
|
||
viel Platz noch zur Verfügung steht.
|
||
|
||
Für das Foto gibt es ein Upload-Feld mit einer Vorschaufunktion. Wird
|
||
ein Bild ausgewählt, wird es sofort als Vorschau angezeigt, bevor der
|
||
Eintrag gespeichert wird. Erlaubt sind nur JPG- und PNG-Dateien mit
|
||
einer maximalen Größe von 5 MB. Zusätzlich gibt es ein optionales
|
||
Link-Feld, in das eine externe Webseite der Person eingetragen werden
|
||
kann.
|
||
|
||
Am unteren Rand des Formulars befinden sich zwei Speicheroptionen: „Als
|
||
Entwurf speichern'' und „Veröffentlichen''. Einträge im Entwurfsmodus
|
||
sind nur für die eigene Person sichtbar und erscheinen nicht in der
|
||
öffentlichen Übersicht. Erst durch das Veröffentlichen wird der Eintrag
|
||
für alle Besucherinnen und Besucher sichtbar. Eine Eigentümerprüfung
|
||
verhindert, dass Benutzerinnen und Benutzer fremde Einträge bearbeiten,
|
||
und eine Duplikatprüfung stellt sicher, dass pro Person nur ein Eintrag
|
||
erstellt werden kann. Dabei greifen die beiden Prüfungen zu
|
||
unterschiedlichen Zeitpunkten: Die Duplikatprüfung wird beim Erstellen
|
||
eines neuen Eintrags ausgeführt und verhindert, dass eine Person mehrere
|
||
Einträge anlegt. Die Eigentümerprüfung hingegen greift beim Bearbeiten
|
||
eines bestehenden Eintrags und stellt sicher, dass nur die Person, die
|
||
den Eintrag erstellt hat, diesen auch ändern kann.
|
||
|
||
Der folgende Lebenszyklus zeigt die möglichen Zustände eines Eintrags
|
||
und die Übergänge zwischen ihnen:
|
||
|
||
!{[}Abbildung 4.1: Lebenszyklus eines Hall-of-Fame-Eintrags{]}
|
||
(./images/06-Adam/hall\_of\_fame\_lebenszyklus\_v4.svg) \emph{Abbildung
|
||
4.1: Lebenszyklus eines Hall-of-Fame-Eintrags}
|
||
|
||
\subparagraph{3.3.1.4 Meldefunktion}\label{meldefunktion}
|
||
|
||
Die Meldefunktion ermöglicht es angemeldeten Benutzerinnen und
|
||
Benutzern, einen Hall-of-Fame-Eintrag zu melden, wenn dieser
|
||
unangemessene oder falsche Inhalte enthält. Durch Klicken auf den
|
||
„Melden''-Button auf der Detailseite öffnet sich ein kleines
|
||
Popup-Fenster, in das der Meldegrund eingetragen werden kann. Nach dem
|
||
Absenden wird die Meldung in der Datenbank gespeichert und im
|
||
Admin-Modul angezeigt. Administratorinnen und Administratoren können
|
||
dort alle eingegangenen Meldungen einsehen und bei Bedarf den
|
||
betreffenden Eintrag löschen oder freigeben.
|
||
|
||
Die Meldefunktion ist dabei nicht direkt im Hall-of-Fame-Modul
|
||
implementiert, sondern wird über eine zentrale Schnittstelle aus einem
|
||
gemeinsamen Interfaces-Paket eingebunden. Dieses Konzept ermöglicht es,
|
||
dieselbe Melde-Oberfläche in beliebig vielen weiteren Modulen
|
||
wiederzuverwenden, ohne die Logik mehrfach implementieren zu müssen.
|
||
|
||
!{[}Abbildung 6.1: Ablauf des globalen Reporting-Systems{]}
|
||
(./images/06-Adam/reporting\_sequence\_diagram.svg) \emph{Abbildung 6.1:
|
||
Ablauf des globalen Reporting-Systems (Sequenzdiagramm)}
|
||
|
||
\subparagraph{3.3.1.5 PDF-Export}\label{pdf-export}
|
||
|
||
Der PDF-Export ist eine besondere Funktion des Hall-of-Fame-Moduls. Er
|
||
ermöglicht es Benutzerinnen und Benutzern, ihren Eintrag als visuell
|
||
ansprechendes PDF-Dokument herunterzuladen. Die PDF-Generierung wird
|
||
über die Open-Source-Bibliothek QuestPDF in der Community-Edition
|
||
realisiert.
|
||
|
||
Das generierte PDF folgt einem Glasmorphismus-Design und ist im Format
|
||
DIN A4 gehalten. Das Foto der Person wird als vollflächiges
|
||
Hintergrundbild verwendet, das die gesamte Seite ausfüllt. Im oberen
|
||
Bereich der Seite befindet sich ein halbtransparenter dunkler Bereich,
|
||
in dem der Name der Person in großen Großbuchstaben mit weitem
|
||
Zeichenabstand dargestellt wird. Darunter wird der Jahrgang mit erhöhtem
|
||
Zeichenabstand angezeigt. Im unteren Bereich der Seite befindet sich ein
|
||
weiterer halbtransparenter Bereich mit der vollständigen Beschreibung.
|
||
Der charakteristische Glaseffekt wird durch mehrschichtige
|
||
halbtransparente Hintergründe mit abgerundeten Ecken erzeugt, die dem
|
||
Dokument ein modernes und professionelles Erscheinungsbild verleihen.
|
||
|
||
Die PDF-Vorschau kann direkt auf der Detailseite über den „PDF
|
||
Vorschau''-Button geöffnet werden. Es öffnet sich ein modaler Dialog,
|
||
der das generierte PDF in einer Vorschau anzeigt. Über einen
|
||
„Herunterladen''-Button kann das PDF direkt auf das Gerät gespeichert
|
||
werden.
|
||
|
||
\paragraph{3.3.2 Datenmodell}\label{datenmodell}
|
||
|
||
Das Modul verwendet zwei Entitäten, die in der Datenbank als Tabellen
|
||
abgebildet werden.
|
||
|
||
\textbf{Entität HallOfFame}
|
||
|
||
Die zentrale Entität repräsentiert einen einzelnen Absolventeneintrag
|
||
und wird in der Datenbanktabelle \texttt{SZUAbsolventenvereinHallOfFame}
|
||
gespeichert.
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.1875}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.1875}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.6250}}@{}}
|
||
\caption{Entität HallOfFame}\tabularnewline
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Spalte
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Datentyp
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Spalte
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Datentyp
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
\texttt{HallOfFameId} & \texttt{int} (PK, Auto-Inkrement) &
|
||
Primärschlüssel \\
|
||
\texttt{ModuleId} & \texttt{int} (FK → \texttt{Module}) & Fremdschlüssel
|
||
zur Oqtane-Modulinstanz \\
|
||
\texttt{Name} & \texttt{string} & Name der Person \\
|
||
\texttt{Year} & \texttt{int} & Abschlussjahrgang \\
|
||
\texttt{Description} & \texttt{string} & Beschreibung bzw. Werdegang \\
|
||
\texttt{Image} & \texttt{string} & Relativer Pfad zum hochgeladenen
|
||
Foto \\
|
||
\texttt{Link} & \texttt{string} & Optionaler externer Link \\
|
||
\texttt{Status} & \texttt{string} (max. 50) & Veröffentlichungsstatus:
|
||
„Draft'' oder „Published'' \\
|
||
\texttt{UserId} & \texttt{int} & ID der Benutzerin bzw. des Benutzers,
|
||
der den Eintrag erstellt hat \\
|
||
\texttt{IsReported} & \texttt{bool} & Kennzeichnung, ob der Eintrag
|
||
gemeldet wurde \\
|
||
\texttt{ReportReason} & \texttt{string} & (Legacy) Ursprüngliches Feld
|
||
für Meldegrund, abgelöst durch die Report-Tabelle \\
|
||
\texttt{CreatedBy} & \texttt{string} & Erstellt von (Audit) \\
|
||
\texttt{CreatedOn} & \texttt{DateTime} & Erstellzeitpunkt (Audit) \\
|
||
\texttt{ModifiedBy} & \texttt{string} & Zuletzt geändert von (Audit) \\
|
||
\texttt{ModifiedOn} & \texttt{DateTime} & Zeitpunkt der letzten Änderung
|
||
(Audit) \\
|
||
\end{longtable}
|
||
|
||
Die Entität implementiert das Oqtane-Interface \texttt{IAuditable},
|
||
wodurch die Audit-Felder automatisch vom Framework befüllt werden. Der
|
||
Fremdschlüssel \texttt{ModuleId} verknüpft jeden Eintrag mit einer
|
||
bestimmten Modulinstanz und ermöglicht so den Multi-Tenant-Betrieb.
|
||
|
||
\textbf{Entität HallOfFameReport}
|
||
|
||
Die zweite Entität bildet einzelne Meldungen zu einem Eintrag ab und
|
||
wird in der Tabelle \texttt{SZUAbsolventenvereinHallOfFameReport}
|
||
gespeichert.
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.2277}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.1782}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.5941}}@{}}
|
||
\caption{Entität HallOfFameReport}\tabularnewline
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Spalte
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Datentyp
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Spalte
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Datentyp
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
\texttt{HallOfFameReportId} & \texttt{int} (PK, Auto-Inkrement) &
|
||
Primärschlüssel \\
|
||
\texttt{HallOfFameId} & \texttt{int} (FK →
|
||
\texttt{SZUAbsolventenvereinHallOfFame}) & Zugehöriger Eintrag \\
|
||
\texttt{Reason} & \texttt{string} & Meldegrund \\
|
||
\texttt{CreatedBy} & \texttt{string} & Erstellt von (Audit) \\
|
||
\texttt{CreatedOn} & \texttt{DateTime} & Erstellzeitpunkt (Audit) \\
|
||
\texttt{ModifiedBy} & \texttt{string} & Zuletzt geändert von (Audit) \\
|
||
\texttt{ModifiedOn} & \texttt{DateTime} & Zeitpunkt der letzten Änderung
|
||
(Audit) \\
|
||
\end{longtable}
|
||
|
||
Der Fremdschlüssel zu \texttt{SZUAbsolventenvereinHallOfFame} ist mit
|
||
kaskadierendem Löschen konfiguriert, sodass beim Löschen eines Eintrags
|
||
automatisch alle zugehörigen Meldungen entfernt werden. Zwischen den
|
||
beiden Entitäten besteht eine 1:n-Beziehung: Ein Eintrag kann beliebig
|
||
viele Meldungen besitzen.
|
||
|
||
\paragraph{3.3.3 Datenbankmigrationen}\label{datenbankmigrationen}
|
||
|
||
Die Datenbankstruktur wird über Entity Framework Core Migrationen
|
||
versioniert verwaltet.\footnote{Microsoft (2026c) (siehe
|
||
Internet-/Intranetverzeichnis).}
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.4545}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3636}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.1818}}@{}}
|
||
\caption{Datenbankmigrationen im Hall-of-Fame-Modul}\tabularnewline
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Migration
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Versionsnummer
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Inhalt
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Migration
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Versionsnummer
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Inhalt
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
\texttt{InitializeModule} & \texttt{01.00.00.00} & Erstellt die
|
||
Haupttabelle mit allen Grundspalten sowie den Audit-Spalten \\
|
||
\texttt{AddReportingColumns} & \texttt{01.00.00.02} & Erweitert die
|
||
Haupttabelle um die Spalten \texttt{IsReported} und
|
||
\texttt{ReportReason} \\
|
||
\texttt{AddReportTable} & \texttt{01.00.00.03} & Erstellt die
|
||
eigenständige Report-Tabelle mit Fremdschlüssel zur Haupttabelle \\
|
||
\end{longtable}
|
||
|
||
\begin{quote}
|
||
\textbf{Hinweis:} Version \texttt{01.00.00.01} wurde im
|
||
Entwicklungsprozess übersprungen, da eine fehlerhafte Migration erstellt
|
||
und anschließend wieder gelöscht werden musste.
|
||
\end{quote}
|
||
|
||
\paragraph{3.3.4 Implementierungsdetails und
|
||
Problemlösungen}\label{implementierungsdetails-und-problemluxf6sungen}
|
||
|
||
Während der Entwicklung traten mehrere technische Herausforderungen auf,
|
||
die im Folgenden zusammen mit ihren Lösungen beschrieben werden.
|
||
|
||
\textbf{Bild-Upload-System}
|
||
|
||
In der ursprünglichen Version des Moduls mussten Benutzerinnen und
|
||
Benutzer eine Bild-URL manuell in ein Textfeld eingeben. Dies war wenig
|
||
benutzerfreundlich und erforderte, dass Bilder zunächst anderweitig
|
||
hochgeladen und verlinkt werden mussten. Das implementierte
|
||
Bild-Upload-System ersetzt dies durch eine
|
||
Blazor-\texttt{InputFile}-Komponente mit Live-Vorschau,
|
||
Fortschrittsanzeige und Lösch-Button. Die Upload-Methode prüft die
|
||
Dateigröße (maximal 5 MB), öffnet die Datei als Stream und übermittelt
|
||
sie als \texttt{MultipartFormDataContent} an den Server, der den
|
||
Dateityp serverseitig validiert, einen UUID-Dateinamen (Universally
|
||
Unique Identifier -- eine zufällig generierte, global eindeutige
|
||
Zeichenkette) generiert und die Datei speichert. Das System unterstützt
|
||
beide Blazor-Rendering-Modi.
|
||
|
||
\textbf{Concurrency Exception beim Löschen}
|
||
|
||
Beim Löschen von Einträgen mit vorhandenen Meldungen trat eine
|
||
\texttt{DbUpdateConcurrencyException} auf, verursacht durch Konflikte im
|
||
Entity Framework Change Tracker. Die Lösung bestand in der Aufteilung
|
||
der Löschoperation in zwei separate Transaktionen mit jeweils eigenem
|
||
DbContext: zuerst werden alle zugehörigen Meldungen gelöscht, danach der
|
||
Haupteintrag.
|
||
|
||
\textbf{Kartendesign-Optimierung}
|
||
|
||
Karten hatten ursprünglich unterschiedliche Höhen durch variierende
|
||
Beschreibungslängen. Die Lösung kombiniert CSS-Flexbox auf dem
|
||
Kartenelement mit einer Maximalhöhe von 150 Pixeln und
|
||
\texttt{overflow:\ hidden} auf dem Beschreibungscontainer, sodass alle
|
||
Karten einer Zeile dieselbe Höhe aufweisen.
|
||
|
||
\textbf{Sortier-Toggle}
|
||
|
||
Die ursprünglich fest codierten Sortierrichtungen wurden durch einen
|
||
Toggle-Button neben dem Sortier-Dropdown ersetzt, der mit einem
|
||
dynamischen Pfeil-Icon zwischen aufsteigender und absteigender
|
||
Sortierung umschaltet. Die Sortierlogik ist in einer berechneten
|
||
Eigenschaft gekapselt, die Suche und Sortierung kombiniert.
|
||
|
||
\subsection{4. Übergangslösung \&
|
||
Probleme}\label{uxfcbergangsluxf6sung-probleme}
|
||
|
||
\subsubsection{4.1 Übergangslösung (Sommer
|
||
2025)}\label{uxfcbergangsluxf6sung-sommer-2025}
|
||
|
||
\paragraph{4.1.1 Gründe \& Technische
|
||
Umsetzung}\label{gruxfcnde-technische-umsetzung}
|
||
|
||
Da AlumniHub zum Zeitpunkt des ersten Absolvententreffens im Sommer 2025
|
||
noch nicht vollständig fertiggestellt war und das Hosting von Oqtane auf
|
||
dem Hetzner-Server zu unerwarteten technischen Problemen geführt hatte,
|
||
wurde im Team die Entscheidung getroffen, eine eigenständige
|
||
Übergangslösung zu entwickeln. Diese sollte pünktlich zur Veranstaltung
|
||
einsatzbereit sein und die wichtigsten Funktionen abdecken: die
|
||
Möglichkeit für Absolventinnen und Absolventen, ihre Teilnahme am
|
||
Treffen zu bestätigen oder abzusagen, sowie die Möglichkeit, direktes
|
||
Feedback zum Diplomprojekt AlumniHub abzugeben.
|
||
|
||
Da für die Entwicklung nur wenig Zeit zur Verfügung stand und eine
|
||
vollständige Integration in die noch nicht fertige AlumniHub-Plattform
|
||
nicht realistisch war, wurde bewusst auf einen schlanken, eigenständigen
|
||
Technologie-Stack gesetzt. Dieser sollte schnell entwickelt, einfach
|
||
deploybar und zuverlässig betreibbar sein -- ohne die Komplexität eines
|
||
vollständigen CMS-Systems.
|
||
|
||
Das Frontend der Übergangslösung wurde mit den grundlegenden
|
||
Webtechnologien HTML, CSS und JavaScript umgesetzt. Die Hauptseite
|
||
(\texttt{index.html}) präsentiert den Besucherinnen und Besuchern eine
|
||
übersichtliche und schlichte Oberfläche, die sich am Erscheinungsbild
|
||
der HTL Ungargasse orientiert -- mit dem Schullogo im Header und einem
|
||
Grau-Weiß-Farbschema. Im Mittelpunkt der Seite befindet sich ein
|
||
zentraler Button, über den ein modales Overlay-Formular geöffnet werden
|
||
kann. Über dieses Formular konnten Nutzerinnen und Nutzer ihre
|
||
E-Mail-Adresse eingeben und ihr Feedback zum Projekt abgeben. Die
|
||
Steuerung des Overlays erfolgt über JavaScript: Das Formular öffnet sich
|
||
beim Klick auf den Button und schließt sich automatisch, wenn außerhalb
|
||
des Formularfensters geklickt wird. Dadurch ist eine intuitive Bedienung
|
||
ohne zusätzliche Schaltflächen möglich.
|
||
|
||
Für die Verarbeitung von Zu- und Absagen zum Absolvententreffen wurden
|
||
zusätzlich zwei separate Bestätigungsseiten erstellt:
|
||
\texttt{zusage.html} und \texttt{absage.html}. Diese Seiten werden dem
|
||
Nutzer nach dem erfolgreichen Absenden des jeweiligen Formulars
|
||
angezeigt und bestätigen den Eingang der Rückmeldung. Das Design aller
|
||
drei Seiten ist einheitlich gehalten und folgt dem gleichen
|
||
Layout-Prinzip mit Header, Logo und zentriertem Hauptinhalt.
|
||
|
||
Das Backend der Lösung, das für die Verarbeitung der Formulardaten und
|
||
den Versand von Bestätigungs-E-Mails zuständig war, wurde von einem
|
||
Teammitglied entwickelt und war nicht Teil des eigenen Aufgabenbereichs.
|
||
Es wurde mit Node.js und dem Framework Express umgesetzt und auf einem
|
||
virtuellen Server bei Hetzner Cloud gehostet.
|
||
|
||
\paragraph{4.1.2 Differenzen zur finalen
|
||
Lösung}\label{differenzen-zur-finalen-luxf6sung}
|
||
|
||
Im direkten Vergleich zur finalen AlumniHub-Plattform unterscheidet sich
|
||
die Übergangslösung in mehreren wesentlichen Punkten. Während AlumniHub
|
||
auf dem vollständigen CMS Oqtane basiert und eine umfangreiche
|
||
Funktionspalette bietet -- darunter Benutzerverwaltung, Hall of Fame,
|
||
Anmeldetool, Datenauswertung und ein individuelles Theme -- beschränkte
|
||
sich die Übergangslösung bewusst auf das absolut Notwendige.
|
||
|
||
Es gab keine Benutzerkonten und keine Authentifizierung. Jede Person,
|
||
die die Seite aufrief, konnte das Formular ausfüllen und absenden, ohne
|
||
sich vorher registrieren oder anmelden zu müssen. Es gab keine Datenbank
|
||
im klassischen Sinne -- die eingegangenen Formulardaten wurden
|
||
serverseitig als einfache JSON-Dateien gespeichert. Es gab keine
|
||
administrativen Funktionen, keine Übersichten und keine Möglichkeit, die
|
||
Daten direkt über eine Benutzeroberfläche auszuwerten.
|
||
|
||
Diese bewusste Reduktion auf das Wesentliche war jedoch kein Nachteil,
|
||
sondern eine pragmatische Entscheidung: Die Lösung musste schnell
|
||
funktionieren und zuverlässig sein -- und das war sie. Nach dem
|
||
Absolvententreffen wurde die Seite nicht einfach abgeschaltet, sondern
|
||
zu einer reinen Feedback-Seite für das Diplomprojekt umfunktioniert.
|
||
Über diese Seite konnten Interessierte -- darunter Lehrkräfte,
|
||
Mitschülerinnen und Mitschüler sowie externe Besucher der Präsentation
|
||
-- weiterhin direktes Feedback zum Projekt abgeben. Die Seite blieb so
|
||
lange in Betrieb, bis die vollständig entwickelte AlumniHub-Plattform
|
||
diese Funktion nativ übernahm.
|
||
|
||
\subsubsection{4.2 Probleme}\label{probleme}
|
||
|
||
\paragraph{4.2.1 Technische Probleme}\label{technische-probleme}
|
||
|
||
Eine der größten technischen Herausforderungen im gesamten
|
||
Projektverlauf war der Zeitdruck, der insbesondere im Vorfeld des ersten
|
||
Absolvententreffens spürbar war. Da AlumniHub zu diesem Zeitpunkt noch
|
||
nicht einsatzbereit war, musste die Übergangslösung in sehr kurzer Zeit
|
||
konzipiert, entwickelt und in Betrieb genommen werden. Dieser Zeitdruck
|
||
führte dazu, dass keine ausreichende Zeit für gründliches Testen oder
|
||
für die Umsetzung zusätzlicher Funktionen blieb.
|
||
|
||
Ein weiteres technisches Problem ergab sich durch den Wechsel von
|
||
Windows auf macOS während der Entwicklung. Da Oqtane primär für Windows
|
||
entwickelt ist und die macOS-Unterstützung veraltet bzw. nicht
|
||
vollständig angepasst ist, traten nach dem Plattformwechsel Build-Fehler
|
||
auf und Oqtane startete zunächst nur mit Fehlern. Diese Probleme
|
||
erschwerten die Weiterentwicklung erheblich, da zunächst die
|
||
Entwicklungsumgebung stabilisiert werden musste, bevor die eigentliche
|
||
Arbeit an den Modulen fortgesetzt werden konnte. Durch den Wechsel auf
|
||
JetBrains Rider als Entwicklungsumgebung konnten die Build-Probleme
|
||
schließlich behoben und die Arbeit an den Modulen erfolgreich
|
||
fortgesetzt werden.
|
||
|
||
Ein weiteres technisches Problem betraf das Hosting von Oqtane auf dem
|
||
Hetzner-Server. Die Einrichtung und der Betrieb von Oqtane auf dem
|
||
Server bereiteten unerwartete Schwierigkeiten, die den regulären
|
||
Entwicklungsfortschritt verlangsamten. Da dieser Bereich nicht zum
|
||
eigenen Aufgabengebiet gehörte, konnten die genauen Ursachen nicht
|
||
vollständig nachvollzogen werden. Die Probleme wirkten sich jedoch auf
|
||
den gesamten Zeitplan des Projekts aus und waren mitverantwortlich
|
||
dafür, dass AlumniHub zum Zeitpunkt des ersten Treffens noch nicht
|
||
fertig war.
|
||
|
||
In den letzten Monaten des Projekts wurde daher ein Wechsel des
|
||
Hosting-Anbieters vorgenommen. Statt Hetzner wird die Plattform nun bei
|
||
LiveDesign gehostet, einem österreichischen Unternehmen, das sich auf
|
||
Hosting, Webdesign und individuelle Webservices spezialisiert
|
||
hat.\footnote{LiveDesign (2026) (siehe Internet-/Intranetverzeichnis).}
|
||
LiveDesign betreibt seine Datacenter ausschließlich in Österreich und
|
||
bietet eine zuverlässige Infrastruktur für CMS-Systeme wie Oqtane. Durch
|
||
diesen Wechsel konnten die bestehenden Stabilitätsprobleme behoben und
|
||
der Betrieb der Plattform deutlich verbessert werden.
|
||
|
||
\paragraph{4.2.2 Kontakt mit Oqtane- und
|
||
Hetzner-Support}\label{kontakt-mit-oqtane--und-hetzner-support}
|
||
|
||
Im Verlauf des Projekts wurde sowohl der Support von Oqtane als auch der
|
||
Support von Hetzner kontaktiert, um Hilfe bei den aufgetretenen
|
||
technischen Problemen zu erhalten.
|
||
|
||
Der Kontakt mit dem Oqtane-Support erfolgte über GitHub Issues sowie per
|
||
E-Mail. Die gemeldeten Probleme betrafen spezifische Verhaltensweisen
|
||
des Frameworks beim Hosting auf dem Hetzner-Server. Trotz der
|
||
Kontaktaufnahme konnte keine hilfreiche Antwort erhalten werden, die zur
|
||
Lösung der Probleme beigetragen hätte. Die offizielle Dokumentation
|
||
sowie vorhandene Community-Beiträge lieferten ebenfalls keine
|
||
ausreichenden Antworten auf die spezifischen Konfigurationsprobleme.
|
||
|
||
Auch der Hetzner-Support wurde bezüglich der Serverprobleme kontaktiert.
|
||
Die Anfragen bezogen sich auf die Serverkonfiguration und mögliche
|
||
Ursachen für die Instabilität beim Betrieb von Oqtane. Auch hier führten
|
||
die Rückmeldungen nicht zu einer vollständigen Lösung des Problems. Die
|
||
Erfahrung zeigte, dass bei der Nutzung spezialisierter Frameworks auf
|
||
externen Hosting-Plattformen mit eingeschränktem Support gerechnet
|
||
werden muss und eine intensive Eigenrecherche oft unumgänglich ist.
|
||
|
||
\paragraph{4.2.3 Organisatorische
|
||
Probleme}\label{organisatorische-probleme}
|
||
|
||
Neben den technischen Herausforderungen gab es auch auf
|
||
organisatorischer Ebene ein zentrales Problem, das den Projektverlauf im
|
||
Sommer 2025 erheblich beeinflusste. Während der Sommermonate war die
|
||
aktive Mitarbeit innerhalb des Teams sehr ungleich verteilt. Ein
|
||
Großteil der Teammitglieder war urlaubsbedingt nicht oder nur
|
||
eingeschränkt erreichbar und beteiligte sich in dieser Zeit kaum am
|
||
Projekt. Nur ein kleiner Teil des Teams arbeitete in dieser Phase aktiv
|
||
weiter und trieb den Fortschritt voran.
|
||
|
||
Diese Situation führte zu einer deutlichen Ungleichverteilung der
|
||
Arbeitsbelastung. Wenige Personen mussten in dieser Zeit deutlich mehr
|
||
Verantwortung übernehmen als ursprünglich geplant, was zu Frustration
|
||
und Verzögerungen führte. Im Nachhinein zeigt sich, dass klarere
|
||
Absprachen und verbindlichere Vereinbarungen zu Beginn des Sommers dazu
|
||
beigetragen hätten, diese Situation zu vermeiden oder zumindest
|
||
abzumildern.
|
||
|
||
\subsection{5. Learnings}\label{learnings}
|
||
|
||
\subsubsection{5.1 Technisch}\label{technisch}
|
||
|
||
Das Projekt hat auf technischer Ebene wertvolle praktische Kenntnisse
|
||
vermittelt, die über den schulischen Rahmen hinausgehen. Der konsequente
|
||
Einsatz von Git zur Versionskontrolle war dabei eine der wichtigsten
|
||
Erfahrungen. Durch die tägliche Arbeit mit Branches, Commits und Merges
|
||
wurde ein tiefes Verständnis für kollaborative Softwareentwicklung
|
||
aufgebaut. Es wurde deutlich, wie wichtig aussagekräftige
|
||
Commit-Nachrichten, regelmäßige Commits und eine saubere Branch-Struktur
|
||
für die Zusammenarbeit im Team sind.
|
||
|
||
Im Bereich Responsive Design wurden durch die praktische Umsetzung des
|
||
Themes und der Übergangslösung wichtige Kenntnisse vertieft. Dabei wurde
|
||
gelernt, wie man mit CSS Media Queries und Flexbox Layouts baut, die
|
||
sich zuverlässig an unterschiedliche Bildschirmgrößen anpassen.
|
||
Besonders die Umsetzung des Burger-Menüs für mobile Geräte war eine
|
||
lehrreiche Erfahrung, die zeigte, wie man komplexe UI-Funktionen mit
|
||
minimalem JavaScript-Einsatz realisieren kann.
|
||
|
||
Auch der Umgang mit JavaScript zur Steuerung von UI-Elementen wurde
|
||
durch die Arbeit am Projekt verbessert. Die Implementierung der
|
||
Overlay-Steuerung in der Übergangslösung sowie die Menü-Logik im Theme
|
||
haben gezeigt, wie JavaScript gezielt und effizient eingesetzt werden
|
||
kann, um eine bessere Benutzererfahrung zu schaffen.
|
||
|
||
\subsubsection{5.2 Methodisch}\label{methodisch}
|
||
|
||
Auf methodischer Ebene hat das Projekt gezeigt, wie wichtig eine klare
|
||
und verbindliche Aufgabenverteilung von Beginn an ist. In Phasen, in
|
||
denen nicht klar war, wer welche Aufgaben übernimmt, entstanden Lücken
|
||
und Verzögerungen. Eine strukturiertere Planung mit klar definierten
|
||
Zuständigkeiten hätte in solchen Situationen geholfen, den Überblick zu
|
||
behalten und die Arbeit effizienter aufzuteilen.
|
||
|
||
Darüber hinaus hat sich gezeigt, dass regelmäßige Team-Meetings ein
|
||
wichtiges Werkzeug für den Projekterfolg sind. In Phasen, in denen der
|
||
Austausch im Team spärlicher war, dauerte es länger, bis Probleme
|
||
erkannt und gelöst wurden. Kurze, regelmäßige Abstimmungen hätten dazu
|
||
beigetragen, den aktuellen Stand besser zu kommunizieren und gemeinsam
|
||
schneller auf Hindernisse zu reagieren.
|
||
|
||
\subsubsection{5.3 Persönlich}\label{persuxf6nlich}
|
||
|
||
Auf persönlicher Ebene war die wichtigste Erkenntnis aus diesem Projekt
|
||
die Bedeutung von Eigeninitiative. In einem größeren Teamprojekt kann
|
||
man sich nicht immer darauf verlassen, dass andere Aufgaben erledigen
|
||
oder Entscheidungen treffen. Gerade in den Phasen, in denen nicht alle
|
||
Teammitglieder aktiv waren, hat sich gezeigt, dass proaktives Handeln
|
||
entscheidend ist, um das Projekt voranzubringen. Diese Erfahrung hat das
|
||
Bewusstsein dafür gestärkt, Verantwortung nicht nur für den eigenen
|
||
Bereich, sondern auch für das Gesamtprojekt zu übernehmen und bei Bedarf
|
||
auch Aufgaben außerhalb des ursprünglich geplanten Bereichs zu
|
||
übernehmen.
|
||
|
||
\subsection{6. Testen \&
|
||
Qualitätssicherung}\label{testen-qualituxe4tssicherung}
|
||
|
||
\subsubsection{6.1 Funktionstests der
|
||
Module}\label{funktionstests-der-module}
|
||
|
||
Alle entwickelten Module -- das Anmeldetool und das Hall-of-Fame-Modul
|
||
-- wurden manuell auf ihre korrekte Funktionsweise getestet. Dabei
|
||
wurden sämtliche Benutzeraktionen systematisch durchgegangen, darunter
|
||
das An- und Abmelden zu Veranstaltungen, das Erstellen, Bearbeiten und
|
||
Veröffentlichen von Hall-of-Fame-Einträgen, das Hochladen von Bildern
|
||
sowie die Melde- und Löschfunktionen. Fehler und unerwartetes Verhalten
|
||
wurden dokumentiert und im Anschluss behoben.
|
||
|
||
Beim Anmeldetool wurde insbesondere geprüft, ob die Zusage- und
|
||
Absage-Buttons korrekt reagieren und der Status unmittelbar in der
|
||
Oberfläche angezeigt wird. Beim Hall-of-Fame-Modul lag ein besonderer
|
||
Fokus auf dem Bild-Upload: Es wurde getestet, ob die Größenbeschränkung
|
||
von 5 MB korrekt greift, ob die Vorschau sofort erscheint und ob
|
||
ungültige Dateiformate abgelehnt werden. Auch die Duplikatprüfung --
|
||
also die Sicherstellung, dass pro Person nur ein Eintrag erstellt werden
|
||
kann -- sowie die Eigentümerprüfung wurden gezielt getestet.
|
||
|
||
\subsubsection{6.2 Theme-Tests}\label{theme-tests}
|
||
|
||
Das entwickelte Oqtane-Theme wurde auf verschiedenen Browsern und
|
||
Geräten getestet, um eine konsistente Darstellung sicherzustellen.
|
||
Getestet wurde unter anderem auf aktuellen Versionen von Chrome, Firefox
|
||
und Safari sowie auf mobilen Geräten mit unterschiedlichen
|
||
Bildschirmgrößen. Ein besonderer Fokus lag dabei auf der korrekten
|
||
Darstellung des Burger-Menüs auf mobilen Endgeräten sowie auf der
|
||
Funktionsfähigkeit der dynamischen Navigation.
|
||
|
||
\subsubsection{6.3 Usability-Tests}\label{usability-tests}
|
||
|
||
Neben den technischen Tests wurde die Plattform auch von weiteren
|
||
Personen -- darunter Mitschülerinnen und Mitschüler sowie Lehrkräfte --
|
||
auf ihre Benutzerfreundlichkeit geprüft. Das Feedback aus diesen Tests
|
||
floss in die weitere Entwicklung ein und führte unter anderem zu
|
||
Anpassungen in der Darstellung und Bedienung einzelner Elemente.
|
||
|
||
Ein häufiges Feedback war, dass die Unterscheidung zwischen Zusage und
|
||
Absage auf den ersten Blick nicht immer sofort klar war. Daraufhin
|
||
wurden die Schaltflächen farblich deutlicher gestaltet -- Grün für die
|
||
Zusage, Rot für die Absage -- und die Beschriftungen präzisiert. Solche
|
||
Rückmeldungen aus echten Nutzertests sind wertvoll, weil Entwicklerinnen
|
||
und Entwickler ihre eigene Anwendung oft anders wahrnehmen als Personen,
|
||
die das System zum ersten Mal sehen.
|
||
|
||
\subsection{7. Fazit und Ausblick}\label{fazit-und-ausblick}
|
||
|
||
\subsubsection{7.1 Zielerreichung}\label{zielerreichung}
|
||
|
||
Rückblickend auf das Projekt AlumniHub lässt sich festhalten, dass die
|
||
zentralen Ziele meines individuellen Aufgabenbereichs erfolgreich
|
||
umgesetzt wurden.
|
||
|
||
Das \textbf{Hall-of-Fame-Modul} wurde vollständig fertiggestellt. Es
|
||
umfasst die Übersichtsseite mit responsivem Kartenlayout, die
|
||
Detailseite mit Glasmorphismus-Design, die Edit-Seite mit
|
||
Rich-Text-Editor und Bild-Upload, die Meldefunktion sowie den PDF-Export
|
||
mit QuestPDF. Das Modul ist in das Oqtane-CMS integriert und produktiv
|
||
einsetzbar.
|
||
|
||
Das \textbf{Anmeldetool} wurde ebenfalls implementiert und ist
|
||
funktionsfähig. Grundfunktionen wie Zusage und Absage zu Veranstaltungen
|
||
sowie die responsive Darstellung sind vollständig umgesetzt.
|
||
Weiterführende Funktionen wie eine vollständige Teilnehmerliste mit
|
||
Datenbankanbindung und die Möglichkeit, maximale Teilnehmerzahlen
|
||
festzulegen, sind architektonisch bereits vorbereitet, jedoch noch nicht
|
||
vollständig implementiert.
|
||
|
||
Das \textbf{Theme} wurde von einem anderen Teammitglied entwickelt und
|
||
ist ebenfalls fertiggestellt. Der Wechsel des Hostings von Hetzner zu
|
||
LiveDesign hat die Stabilität der Plattform deutlich verbessert.
|
||
|
||
Insgesamt bin ich mit dem erreichten Stand zufrieden -- insbesondere
|
||
angesichts der Herausforderungen durch die Teamverkleinerung, den
|
||
Plattformwechsel von Windows auf macOS und die technischen Probleme mit
|
||
dem ursprünglichen Hosting.
|
||
|
||
\subsubsection{7.2 Ausblick}\label{ausblick}
|
||
|
||
Für die Weiterentwicklung der Plattform gibt es mehrere sinnvolle
|
||
nächste Schritte. Im Bereich des Anmeldetools wäre die Implementierung
|
||
einer vollständigen Teilnehmerliste mit direkter Datenbankanbindung der
|
||
wichtigste nächste Schritt. Ergänzend dazu sollte die Möglichkeit
|
||
geschaffen werden, maximale Teilnehmerzahlen pro Veranstaltung
|
||
festzulegen, sodass Organisatoren die Kapazität von Treffen besser
|
||
steuern können.
|
||
|
||
Langfristig könnte die Plattform um eine automatische
|
||
E-Mail-Benachrichtigung erweitert werden, die Mitglieder an
|
||
bevorstehende Veranstaltungen erinnert. Auch eine Exportfunktion für die
|
||
Anmeldedaten -- beispielsweise als CSV oder PDF -- wäre für die
|
||
Vereinsverwaltung hilfreich.
|
||
|
||
AlumniHub bietet als Plattform eine solide Grundlage, die in den
|
||
kommenden Jahren kontinuierlich erweitert werden kann, um den
|
||
Absolventenverein der HTL Ungargasse langfristig digital zu
|
||
unterstützen.
|
||
|
||
\cleardoublepage
|
||
|
||
\section{Florian Edlmayer}\label{florian-edlmayer-1}
|
||
|
||
\subsection{Einleitung des individuellen
|
||
Teils}\label{einleitung-des-individuellen-teils-1}
|
||
|
||
\subsubsection{Ausgangssituation}\label{ausgangssituation}
|
||
|
||
Der Absolventenverein der HTL Ungargasse hatte keine digitale
|
||
Infrastruktur zur Vernetzung seiner Mitglieder. AlumniHub soll das
|
||
ändern: eine zentrale Plattform für Mitgliederverwaltung,
|
||
Veranstaltungen und Netzwerkfunktionen.
|
||
|
||
\subsubsection{Zielsetzung}\label{zielsetzung-1}
|
||
|
||
Mein persönlicher Beitrag umfasst die DSGVO-konforme
|
||
Datenschutzimplementierung, ein automatisiertes Backup- und
|
||
Restore-System, die Anbindung von LinkedIn als externem
|
||
Identitätsanbieter sowie den Premium-Bereich.
|
||
|
||
\subsubsection{Nutzen für den
|
||
Absolventenverein}\label{nutzen-fuxfcr-den-absolventenverein}
|
||
|
||
Für den Verein bedeutet das: rechtskonforme Datenverarbeitung,
|
||
gesicherte Datenverfügbarkeit und ein niedrigschwelliger Login für
|
||
Absolventinnen und Absolventen mit bestehendem LinkedIn-Konto.
|
||
|
||
\subsubsection{Themenstellung}\label{themenstellung}
|
||
|
||
\paragraph{Entwicklung eines
|
||
CMS-Moduls}\label{entwicklung-eines-cms-moduls}
|
||
|
||
• \textbf{Premiumbereich:} Ein Schwerpunkt der Arbeit ist die
|
||
Entwicklung eines Oqtane-Moduls, das einen Premiumbereich bereitstellt.
|
||
Dieser Bereich soll ausschließlich autorisierten Benutzerinnen und
|
||
Benutzern zugänglich sein und spezielle Inhalte oder Funktionen anbieten
|
||
wie zum Beispiel das hochladen und ansehen von Ingeneuranträgen als
|
||
Vorlage oder das finden und Kontakt aufnehmen mit anderen Benutzern.
|
||
Dabei werden grundlegende Konzepte wie Benutzerrollen, Zugriffsrechte
|
||
und die Integration in das bestehende CMS eingebunden.
|
||
|
||
\subparagraph{Erstellung einer
|
||
Datenschutzerklärung}\label{erstellung-einer-datenschutzerkluxe4rung}
|
||
|
||
Eine weitere wichtige Aufgabe war die Erstellung einer gesetzeskonformen
|
||
Datenschutzerklärung. Diese ist erforderlich, um die Nutzerinnen und
|
||
Nutzer unserer Webanwendung transparent und verständlich darüber zu
|
||
informieren, welche personenbezogenen Daten erhoben, verarbeitet und
|
||
gespeichert werden, zu welchem Zweck dies geschieht und welche Rechte
|
||
ihnen in Bezug auf ihre Daten zustehen.
|
||
|
||
\paragraph{LinkedIn-Anmeldung}\label{linkedin-anmeldung}
|
||
|
||
Zur Verbesserung der Benutzerfreundlichkeit und zur vereinfachten
|
||
Anmeldung wird eine Anmeldung über LinkedIn mithilfe des
|
||
OAuth-2.0-Protokolls implementiert. Diese ermöglicht es Benutzerinnen
|
||
und Benutzern, sich mit einem bestehenden LinkedIn-Konto zu registrieren
|
||
oder anzumelden.
|
||
|
||
\paragraph{Datenbank-Backup und
|
||
Restore}\label{datenbank-backup-und-restore}
|
||
|
||
Abschließend wurde das Thema Datensicherung umfassend behandelt, da die
|
||
Sicherstellung der Datenintegrität und Systemverfügbarkeit einen
|
||
zentralen Bestandteil moderner Webanwendungen darstellt. In diesem
|
||
Zusammenhang wurde ein Skript zur automatisierten Erstellung von
|
||
Datenbank-Backups entwickelt, das in regelmäßigen Abständen
|
||
Sicherungskopien der relevanten Daten erzeugt. Zusätzlich wurde ein
|
||
weiteres Skript implementiert, das im Falle eines Datenverlusts oder
|
||
Systemausfalls eine strukturierte und zuverlässige Wiederherstellung der
|
||
gesicherten Daten ermöglicht.
|
||
|
||
Ziel dieser Maßnahmen ist es, das Risiko von Datenverlusten zu
|
||
minimieren und einen stabilen sowie sicheren Betrieb der Webanwendung zu
|
||
gewährleisten. Die Backup- und Restore-Prozesse sollen automatisiert
|
||
ablaufen, um menschliche Fehler zu reduzieren und eine kontinuierliche,
|
||
regelmäßige Datensicherung sicherzustellen. Dadurch wird eine hohe
|
||
Ausfallsicherheit sowie die langfristige Verfügbarkeit der gespeicherten
|
||
Informationen gewährleistet.
|
||
|
||
\subsubsection{Detail-Zielsetzungen}\label{detail-zielsetzungen}
|
||
|
||
\paragraph{Zielsetzung}\label{zielsetzung-2}
|
||
|
||
\subparagraph{Technische Zielsetzung}\label{technische-zielsetzung}
|
||
|
||
Die technische Zielsetzung dieses Diplomarbeitsprojekts bestand darin,
|
||
eine stabile und sichere Webplattform für Alumni zu entwickeln. Als
|
||
technische Grundlage wurde das Content-Management-System Oqtane
|
||
verwendet, welches auf modernen Webtechnologien basiert und eine
|
||
modulare Erweiterung von Funktionen ermöglicht. Die Implementierung
|
||
erfolgte innerhalb der von Oqtane bereitgestellten Architektur, wodurch
|
||
verschiedene Funktionen effizient integriert werden konnten.
|
||
|
||
Ein zentraler Bestandteil der technischen Umsetzung war die Integration
|
||
einer externen Authentifizierung über LinkedIn mithilfe des Protokolls
|
||
OAuth 2.0. Dadurch können sich Benutzer direkt mit ihrem LinkedIn-Konto
|
||
auf der Plattform anmelden, ohne ein separates Benutzerkonto erstellen
|
||
zu müssen. Dies vereinfacht den Registrierungsprozess und erhöht
|
||
gleichzeitig die Sicherheit, da sensible Zugangsdaten ausschließlich
|
||
beim externen Anbieter verbleiben.
|
||
|
||
Zusätzlich wurde eine Datenbank auf Basis von PostgreSQL eingesetzt, um
|
||
Benutzerinformationen, Inhalte sowie weitere Systemdaten zuverlässig zu
|
||
speichern. Um die langfristige Verfügbarkeit dieser Daten
|
||
sicherzustellen, wurde ein automatisiertes Backup-System implementiert.
|
||
Dieses System erstellt regelmäßig Sicherungskopien der Datenbank sowie
|
||
der wichtigsten Systemdateien. Ergänzend dazu wurde ein Restore-Skript
|
||
entwickelt, mit dem gespeicherte Daten im Falle eines Systemfehlers oder
|
||
Datenverlustes wiederhergestellt werden können.
|
||
|
||
Ein weiterer wichtiger Aspekt der technischen Zielsetzung war die
|
||
Einhaltung rechtlicher Anforderungen im Bereich Datenschutz. Daher wurde
|
||
eine Datenschutzerklärung erstellt und die Plattform so konzipiert, dass
|
||
personenbezogene Daten der Benutzer entsprechend den Vorgaben der
|
||
Datenschutz-Grundverordnung verarbeitet werden.
|
||
|
||
\subparagraph{Funktionale Zielsetzung}\label{funktionale-zielsetzung}
|
||
|
||
Die funktionale Zielsetzung des Projekts bestand darin, eine
|
||
Onlineplattform zu entwickeln, die ehemaligen Schülerinnen und Schülern
|
||
die Möglichkeit bietet, miteinander in Kontakt zu bleiben und sich über
|
||
aktuelle Veranstaltungen zu informieren. Die Plattform dient somit als
|
||
digitales Netzwerk für Alumni und soll den Austausch zwischen ehemaligen
|
||
Mitgliedern der Bildungseinrichtung fördern.
|
||
|
||
Eine zentrale Funktion der Anwendung ist die Anmeldung über LinkedIn,
|
||
wodurch Benutzer schnell und unkompliziert Zugriff auf die Plattform
|
||
erhalten können. Nach der erfolgreichen Anmeldung wird automatisch ein
|
||
Benutzerkonto erstellt oder ein bestehendes Konto zugeordnet.
|
||
|
||
Darüber hinaus bietet die Plattform Funktionen zur Darstellung und
|
||
Verwaltung von Veranstaltungen. Alumni können sich über kommende Events
|
||
informieren und sich für diese anmelden. Dadurch wird die Organisation
|
||
von Treffen oder Veranstaltungen erleichtert und die Vernetzung
|
||
innerhalb der Alumni-Community gefördert.
|
||
|
||
Zusätzlich wurde ein Premiumbereich entwickelt, der bestimmte Inhalte
|
||
oder Funktionen exklusiv für berechtigte Benutzer bereitstellt. Dieser
|
||
Bereich erweitert die Möglichkeiten der Plattform und ermöglicht es,
|
||
spezielle Inhalte nur bestimmten Benutzergruppen zugänglich zu machen.
|
||
|
||
Durch diese Funktionen entsteht eine Plattform, die nicht nur als
|
||
Informationsquelle dient, sondern auch aktiv zur Vernetzung der Alumni
|
||
beiträgt.
|
||
|
||
\subparagraph{Gestalterische
|
||
Zielsetzung}\label{gestalterische-zielsetzung}
|
||
|
||
Neben den technischen und funktionalen Anforderungen spielte auch die
|
||
Gestaltung der Plattform eine wichtige Rolle. Ziel war es, eine
|
||
übersichtliche und benutzerfreundliche Oberfläche zu entwickeln, die
|
||
eine einfache Navigation und intuitive Bedienung ermöglicht.
|
||
|
||
Die Struktur der Webseite wurde so aufgebaut, dass wichtige Funktionen
|
||
wie Login, Benutzerprofil oder Eventübersicht schnell erreichbar sind.
|
||
Ein klares Layout und eine strukturierte Seitenaufteilung tragen dazu
|
||
bei, dass sich Benutzer auf der Plattform leicht orientieren können.
|
||
|
||
Darüber hinaus wurde darauf geachtet, dass die Plattform ein modernes
|
||
Erscheinungsbild besitzt und den Erwartungen einer zeitgemäßen
|
||
Webanwendung entspricht. Durch eine klare Gestaltung und eine reduzierte
|
||
Benutzeroberfläche wird sichergestellt, dass Inhalte übersichtlich
|
||
dargestellt werden und die Nutzung der Plattform möglichst komfortabel
|
||
ist.
|
||
|
||
Insgesamt verfolgt die gestalterische Zielsetzung das Ziel, eine
|
||
Plattform zu schaffen, die sowohl funktional als auch optisch
|
||
ansprechend ist und den Benutzern eine positive Nutzungserfahrung
|
||
bietet.
|
||
|
||
\subsection{Anforderungen an das entwickelte Modul bzw. die
|
||
Funktionalität}\label{anforderungen-an-das-entwickelte-modul-bzw.-die-funktionalituxe4t}
|
||
|
||
funktionale / nicht‑funktionale Anforderungen
|
||
|
||
Use Cases
|
||
|
||
\subsection{Technologien}\label{technologien-1}
|
||
|
||
\subsubsection{ASP.NET und .NET}\label{asp.net-und-.net}
|
||
|
||
Für die Entwicklung der Webanwendung wurde das Framework ASP.NET in
|
||
Kombination mit der Plattform .NET verwendet. .NET ist eine von
|
||
Microsoft entwickelte Entwicklungsplattform zur Erstellung moderner
|
||
Anwendungen für Web, Desktop, Cloud und mobile Systeme.
|
||
|
||
ASP.NET stellt innerhalb der .NET-Plattform ein Framework dar, das
|
||
speziell für die Entwicklung von Webanwendungen und Webservices
|
||
konzipiert wurde. Es bietet eine Vielzahl an Funktionen zur Verarbeitung
|
||
von HTTP-Anfragen, zur Verwaltung von Benutzersitzungen sowie zur
|
||
Integration von Datenbanken und externen Diensten.
|
||
|
||
Die Anwendung basiert auf .NET 8, einer aktuellen Version der Plattform,
|
||
welche insbesondere Verbesserungen in den Bereichen Performance,
|
||
Sicherheit und Skalierbarkeit bietet. Durch die Nutzung dieser Plattform
|
||
ist es möglich, stabile und performante Webanwendungen zu entwickeln,
|
||
die auch bei steigender Benutzeranzahl zuverlässig funktionieren.
|
||
|
||
Ein wesentliches Konzept von ASP.NET ist die serverseitige Verarbeitung
|
||
von Webanfragen. Wenn ein Benutzer eine Seite im Browser aufruft, wird
|
||
zunächst eine Anfrage an den Webserver gesendet. Der Server verarbeitet
|
||
diese Anfrage innerhalb der ASP.NET-Anwendung und sendet anschließend
|
||
eine generierte Antwort zurück an den Browser.
|
||
|
||
Durch diese Architektur wird sichergestellt, dass die eigentliche Logik
|
||
der Anwendung auf dem Server ausgeführt wird, während der Browser
|
||
lediglich für die Darstellung der Benutzeroberfläche zuständig ist.
|
||
|
||
Ein weiterer Vorteil von ASP.NET besteht in der klar strukturierten
|
||
Architektur moderner Webanwendungen. Typischerweise wird eine Anwendung
|
||
in mehrere Schichten unterteilt, beispielsweise:
|
||
|
||
• Präsentationsschicht (Benutzeroberfläche) • Geschäftslogik •
|
||
Datenzugriffsschicht
|
||
|
||
Diese Struktur erleichtert die Wartung und Erweiterung der Anwendung
|
||
erheblich, da Änderungen gezielt innerhalb einzelner Komponenten
|
||
vorgenommen werden können.
|
||
|
||
\subsubsection{PostgreSQL-Datenbank}\label{postgresql-datenbank}
|
||
|
||
Zur Speicherung der Daten der Plattform wurde das relationale
|
||
Datenbanksystem PostgreSQL eingesetzt. PostgreSQL gehört zu den
|
||
leistungsfähigsten Open-Source-Datenbanken und wird weltweit in vielen
|
||
professionellen Anwendungen verwendet.
|
||
|
||
Eine relationale Datenbank speichert Informationen in Tabellen, die aus
|
||
Zeilen und Spalten bestehen. Jede Tabelle repräsentiert eine bestimmte
|
||
Art von Daten, beispielsweise Benutzer, Veranstaltungen oder
|
||
Systeminformationen. Beziehungen zwischen Tabellen werden durch
|
||
sogenannte Schlüssel definiert.
|
||
|
||
Durch diese Struktur kann beispielsweise gespeichert werden:
|
||
|
||
• welcher Benutzer existiert • welche Veranstaltungen geplant sind •
|
||
welcher Benutzer sich für welches Event angemeldet hat
|
||
|
||
PostgreSQL bietet darüber hinaus zahlreiche Funktionen, die für moderne
|
||
Webanwendungen wichtig sind. Dazu gehören unter anderem:
|
||
|
||
• hohe Stabilität und Zuverlässigkeit • Unterstützung komplexer
|
||
Datenabfragen mittels SQL • Transaktionssicherheit zur Vermeidung von
|
||
Datenverlust • Erweiterbarkeit durch zusätzliche Module
|
||
|
||
Ein weiterer wichtiger Vorteil besteht darin, dass PostgreSQL sehr gut
|
||
mit modernen Webframeworks wie ASP.NET zusammenarbeitet. Dadurch kann
|
||
die Anwendung effizient auf gespeicherte Daten zugreifen und diese
|
||
verarbeiten.
|
||
|
||
Da die Plattform personenbezogene Daten von Benutzern speichert, wurde
|
||
zusätzlich ein Backup-System implementiert, das regelmäßige Sicherungen
|
||
der Datenbank erstellt. Dadurch können Daten im Falle eines Fehlers oder
|
||
eines Systemausfalls wiederhergestellt werden.
|
||
|
||
\subsubsection{OAuth 2.0}\label{oauth-2.0}
|
||
|
||
Für die sichere Anmeldung über externe Identitätsanbieter wurde das
|
||
Protokoll OAuth 2.0 implementiert. OAuth 2.0 ist ein branchenweiter
|
||
Standard für die Autorisierung, der es Benutzern ermöglicht, Anwendungen
|
||
von Drittanbietern Zugriff auf ihre Daten zu gewähren, ohne ihre
|
||
Passwörter für das jeweilige Portal preiszugeben. Im Rahmen dieses
|
||
Projekts wurde OAuth 2.0 als Authentifizierungsverfahren mit LinkedIn
|
||
gewählt, um den Registrierungsprozess der Benutzer signifikant zu
|
||
vereinfachen, da bestehende LinkedIn-Accounts genutzt werden können.
|
||
Gleichzeitig wird dadurch ein hohes Sicherheitsniveau sichergestellt.
|
||
|
||
\subsection{Module}\label{module-1}
|
||
|
||
\subsubsection{Datenschutz und rechtliche
|
||
Grundlagen}\label{datenschutz-und-rechtliche-grundlagen}
|
||
|
||
\paragraph[Bedeutung der Datenschutz-Grundverordnung
|
||
(DSGVO)]{\texorpdfstring{Bedeutung der Datenschutz-Grundverordnung
|
||
(DSGVO)\footnote{Europäische Union (2016) (siehe
|
||
Internet-/Intranetverzeichnis).}}{Bedeutung der Datenschutz-Grundverordnung (DSGVO)}}\label{bedeutung-der-datenschutz-grundverordnung-dsgvo-dsgvo}
|
||
|
||
Die Datenschutz-Grundverordnung (DSGVO) ist eine rechtsverbindliche
|
||
Verordnung der Europäischen Union, die seit dem 25. Mai 2018 unmittelbar
|
||
in allen EU-Mitgliedstaaten gilt und den Schutz personenbezogener Daten
|
||
regelt. Sie wurde erlassen, um die Rechte natürlicher Personen bei der
|
||
Verarbeitung ihrer Daten zu stärken und ein einheitliches
|
||
Datenschutzniveau innerhalb der EU zu gewährleisten.
|
||
|
||
Der Anwendungsbereich der DSGVO umfasst alle Verarbeitungen
|
||
personenbezogener Daten, unabhängig davon, ob diese automatisiert oder
|
||
in nicht-automatisierten Akten erfolgt. Personenbezogene Daten sind
|
||
dabei definiert als alle Informationen, die sich auf eine identifizierte
|
||
oder identifizierbare natürliche Person beziehen.
|
||
|
||
Die DSGVO verfolgt mehrere grundsätzliche Ziele:
|
||
|
||
• Schutz der Grundrechte natürlicher Personen bei der Verarbeitung ihrer
|
||
personenbezogenen Daten sowie die Gewährleistung ihrer Grundfreiheiten.
|
||
• Einheitlicher Datenschutz in der EU, sodass sowohl Unternehmen
|
||
innerhalb als auch außerhalb der EU, die Daten von EU-Bürgern
|
||
verarbeiten, denselben Regeln unterliegen. • Schaffung klarer Pflichten
|
||
für Datenverantwortliche und -verarbeiter zur rechtskonformen
|
||
Datenverarbeitung.
|
||
|
||
Die DSGVO enthält dabei zentral die Grundsätze der Datenverarbeitung
|
||
(Art. 5 DSGVO), die sicherstellen, dass personenbezogene Daten nur
|
||
rechtmäßig, zweckgebunden und in transparentem Umfang verarbeitet
|
||
werden. Dazu gehören unter anderem:
|
||
|
||
• Rechtmäßigkeit, Fairness und Transparenz der Verarbeitung •
|
||
Zweckbindung der Datenerhebung • Datenminimierung und Speicherbegrenzung
|
||
• Integrität und Vertraulichkeit der Datenverarbeitung
|
||
|
||
Die Einhaltung dieser Prinzipien ist für jede Organisation
|
||
verpflichtend, die personenbezogene Daten verarbeitet -- unabhängig von
|
||
ihrer Größe oder Branche. Dies umfasst sowohl technische Aspekte der
|
||
Datenverarbeitung als auch die Informationspflichten gegenüber
|
||
Betroffenen, wie sie etwa in Datenschutzerklärungen umgesetzt werden
|
||
müssen.
|
||
|
||
\paragraph[Umsetzung der Datenschutzanforderungen auf der
|
||
Webseite]{\texorpdfstring{Umsetzung der Datenschutzanforderungen auf der
|
||
Webseite\footnote{Bundeskanzleramt Österreich (2024) (siehe
|
||
Internet-/Intranetverzeichnis).}}{Umsetzung der Datenschutzanforderungen auf der Webseite}}\label{umsetzung-der-datenschutzanforderungen-auf-der-webseite-ris}
|
||
|
||
Im Rahmen der Diplomarbeit wurde eine umfassende Analyse der
|
||
Datenschutzanforderungen durchgeführt und entsprechende Maßnahmen zur
|
||
Umsetzung auf der Webseite implementiert. Dabei wurden insbesondere die
|
||
Vorgaben der DSGVO berücksichtigt, um sicherzustellen, dass die Webseite
|
||
den geltenden Datenschutzbestimmungen entspricht.
|
||
|
||
Ein zentrales Element der Umsetzung war die Erstellung einer
|
||
gesetzeskonformen Datenschutzerklärung. Diese informiert die Nutzerinnen
|
||
und Nutzer über:
|
||
|
||
• die Art der verarbeiteten personenbezogenen Daten, • den Zweck der
|
||
Datenverarbeitung, • die Rechtsgrundlagen der Verarbeitung, • die
|
||
Speicherdauer der Daten, • die Weitergabe von Daten an Dritte • sowie
|
||
über die Rechte der Betroffenen gemäß Art. 15--22 DSGVO.
|
||
|
||
Die Datenschutzerklärung wird auf der Webseite gut sichtbar eingebunden
|
||
und ist für alle Nutzerinnen und Nutzer jederzeit zugänglich.
|
||
|
||
Neben der Informationspflicht wurden auch technische und
|
||
organisatorische Maßnahmen umgesetzt, um die Sicherheit der
|
||
verarbeiteten Daten zu gewährleisten. Dazu gehören unter anderem:
|
||
|
||
• Verschlüsselte Übertragung von Daten mittels HTTPS •
|
||
Passwortgeschützter Zugriff auf sensible Daten • Regelmäßige
|
||
Sicherheitsupdates der eingesetzten Software • Minimierung der
|
||
Datenerhebung auf das Notwendige: Es werden nur die Daten erhoben, die
|
||
für die Funktion der Webseite unbedingt erforderlich sind. (Grundprinzip
|
||
der Datenminimierung nach Art. 5 Abs. 1 lit. c DSGVO)
|
||
|
||
\paragraph[Schutz personenbezogener Daten der
|
||
Benutzer]{\texorpdfstring{Schutz personenbezogener Daten der
|
||
Benutzer\footnote{Datenschutzbehörde (2024) (siehe
|
||
Internet-/Intranetverzeichnis).}}{Schutz personenbezogener Daten der Benutzer}}\label{schutz-personenbezogener-daten-der-benutzer-dsb}
|
||
|
||
Der Schutz personenbezogener Daten der Benutzer stellt einen zentralen
|
||
Bestandteil der Webseite des Absolventenvereins dar. Sämtliche
|
||
Datenverarbeitungen erfolgen unter Berücksichtigung der Vorgaben der
|
||
Datenschutz-Grundverordnung (DSGVO) sowie des österreichischen
|
||
Datenschutzgesetzes (DSG).
|
||
|
||
Gemäß Art. 5 Abs. 1 lit. c DSGVO gilt der Grundsatz der
|
||
Datenminimierung, wonach nur jene personenbezogenen Daten erhoben werden
|
||
dürfen, die für den jeweiligen Zweck erforderlich sind. Auf der Webseite
|
||
werden daher ausschließlich solche Daten verarbeitet, die für die
|
||
Verwaltung der Mitgliedschaft, die Organisation von Veranstaltungen
|
||
sowie die Kommunikation mit Absolventinnen und Absolventen notwendig
|
||
sind.
|
||
|
||
Darüber hinaus wird der Grundsatz der Zweckbindung gemäß Art. 5 Abs. 1
|
||
lit. b DSGVO eingehalten. Die erhobenen Daten werden ausschließlich für
|
||
die in der Datenschutzerklärung definierten Zwecke verarbeitet,
|
||
insbesondere zur Organisation der Vereinstätigkeit und zur Durchführung
|
||
von Absolvententreffen.
|
||
|
||
Eine darüber hinausgehende Weitergabe an Dritte erfolgt grundsätzlich
|
||
nicht, außer wenn dies zur Erfüllung der Vereinszwecke erforderlich ist
|
||
oder eine gesetzliche Verpflichtung besteht.
|
||
|
||
Zur Gewährleistung der Integrität und Vertraulichkeit gemäß Art. 5 Abs.
|
||
1 lit. f DSGVO werden geeignete technische und organisatorische
|
||
Maßnahmen eingesetzt. Dazu zählen insbesondere der Betrieb der Webseite
|
||
auf einem Server innerhalb Österreichs, der Abschluss von
|
||
Auftragsverarbeitungsverträgen gemäß Art. 28 DSGVO mit externen
|
||
Dienstleistern sowie Maßnahmen zum Schutz vor unbefugtem Zugriff,
|
||
Verlust oder Missbrauch von Daten.
|
||
|
||
Zusätzlich werden die Betroffenenrechte gemäß Art. 15--22 DSGVO
|
||
ausdrücklich gewährleistet. Benutzerinnen und Benutzer haben das Recht
|
||
auf Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung,
|
||
Datenübertragbarkeit sowie Widerspruch gegen die Verarbeitung.
|
||
|
||
Darüber hinaus besteht das Recht, sich bei der österreichischen
|
||
Datenschutzbehörde zu beschweren, sofern eine rechtswidrige Verarbeitung
|
||
vermutet wird.
|
||
|
||
Durch die Kombination aus klar definierten Rechtsgrundlagen,
|
||
transparenten Informationspflichten und technischen Schutzmaßnahmen wird
|
||
ein hohes Datenschutzniveau gewährleistet und der verantwortungsvolle
|
||
Umgang mit personenbezogenen Daten sichergestellt.
|
||
|
||
\subsubsection{Backup \& Restore}\label{backup-restore}
|
||
|
||
\paragraph[Notwendigkeit von Datensicherung
|
||
{[}{]}]{\texorpdfstring{Notwendigkeit von Datensicherung {[}Bundesamt
|
||
für Sicherheit in der Informationstechnik
|
||
(BSI)\footnote{(2024) (siehe Internet-/Intranetverzeichnis).}{]}\footnote{BSI
|
||
(2023) (siehe Internet-/Intranetverzeichnis).}}{Notwendigkeit von Datensicherung {[}Bundesamt für Sicherheit in der Informationstechnik (BSI){]}}}\label{notwendigkeit-von-datensicherung-bsi_datensicherungbsi_grundschutz}
|
||
|
||
Die Datensicherung ist ein wesentlicher Bestandteil der Webseite des
|
||
Absolventenvereins. Sie dient dazu, die auf der Webseite gespeicherten
|
||
Daten vor Verlust oder Beschädigung zu schützen. Digitale Daten bilden
|
||
die Grundlage für die Funktion der Webseite und müssen daher regelmäßig
|
||
gesichert werden. Ein Verlust oder eine Beschädigung der Daten kann zu
|
||
erheblichen Problemen führen.
|
||
|
||
Mögliche Ursachen für einen Datenverlust sind unter anderem
|
||
Hardwaredefekte, Softwarefehler, menschliches Versagen oder
|
||
Cyberangriffe. Ohne geeignete Sicherheitsmaßnahmen besteht das Risiko,
|
||
dass Daten unwiederbringlich verloren gehen oder nur mit erheblichen
|
||
Kosten wiederhergestellt werden können.
|
||
|
||
Neben der technischen besteht ebenfalls eine rechtliche und
|
||
organisatorische Notwendigkeit der Datensicherung. Gemäß Art. 5 Abs. 1
|
||
lit. f DSGVO müssen personenbezogene Daten gesichert werden, um die
|
||
Integrität und Vertraulichkeit der Daten zu gewährleisten. Dazu zählt
|
||
auch der Schutz vor unbeabsichtigtem Verlust. Eine Backup-Sicherung ist
|
||
daher ein notwendiger Schritt, um die Daten vor Verlust zu schützen.
|
||
|
||
\paragraph{Konzeption des
|
||
Backup-Systems}\label{konzeption-des-backup-systems}
|
||
|
||
Ziel des Backup-Systems war es im Falle eines Datenverlustes oder eines
|
||
Systemausfalls die Daten wiederherstellen zu können. Es wurde eine
|
||
Strategie entwickelt die es ermöglicht sowohl die Datenbank als auch die
|
||
Dateien auf dem Server zu sichern. Der Umfang des Backups besteht aus
|
||
zwei zentralen Komponenten:
|
||
|
||
\begin{enumerate}
|
||
\def\labelenumi{\arabic{enumi}.}
|
||
\item
|
||
Die PostgreSQL-Datenbank
|
||
\item
|
||
Der Ordner ``oqtane.server'' auf dem Server
|
||
|
||
Damit wird eine vollständige Sicherung der Webseite ermöglicht, da bei
|
||
einer reinen Datenbanksicherung wichtige Anwendungsdateien fehlen
|
||
würden.
|
||
\end{enumerate}
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.8\linewidth,height=0.7\textheight]{flowchart-backup-system.pdf}
|
||
\caption{Ablaufdiagramm des Backup-Systems}
|
||
\end{figure}
|
||
|
||
Alle Backups werden lokal auf dem Server gespeichert. Diese Backups sind
|
||
alle zu finden unter: /var/backups Für jedes Backup wird in diesem
|
||
Verzeichnis ein Unterordner erstellt, dessen Name einen UTC-Zeitstempel
|
||
enthält. Das ermöglicht eine saubere Trennung der Sicherungsstände und
|
||
einfache chronologische Zuordnung.
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\VariableTok{TS}\OperatorTok{=}\StringTok{"}\VariableTok{$(}\FunctionTok{date} \AttributeTok{{-}u}\NormalTok{ +}\StringTok{\textquotesingle{}\%Y\%m\%dT\%H\%M\%SZ\textquotesingle{}}\VariableTok{)}\StringTok{"}
|
||
\VariableTok{DEST\_DIR}\OperatorTok{=}\StringTok{"}\VariableTok{$\{BACKUP\_ROOT\}}\StringTok{/}\VariableTok{$\{TS\}}\StringTok{"}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
date -u erzeugt einen Zeitstempel in UTC, wodurch die Benennung
|
||
unabhängig von Zeitzonen eindeutig bleibt. Der Zeitstempel wird als
|
||
Ordnername verwendet, sodass jedes Backup separat abgelegt wird (z. B.
|
||
20260226T023000Z).
|
||
|
||
Die Sicherung der PostgreSQL-Datenbank erfolgt mithilfe des Programms
|
||
pg\_dump, welches ein vollständiges Abbild der Datenbank erzeugt:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\ExtensionTok{pg\_dump} \AttributeTok{{-}h} \StringTok{"}\VariableTok{$PGHOST}\StringTok{"} \AttributeTok{{-}p} \StringTok{"}\VariableTok{$PGPORT}\StringTok{"} \AttributeTok{{-}U} \StringTok{"}\VariableTok{$PGUSER}\StringTok{"} \AttributeTok{{-}d} \StringTok{"}\VariableTok{$PGDATABASE}\StringTok{"} \AttributeTok{{-}Fc} \DataTypeTok{\textbackslash{}}
|
||
\AttributeTok{{-}f} \StringTok{"}\VariableTok{$\{DEST\_DIR\}}\StringTok{/db\_}\VariableTok{$\{PGDATABASE\}}\StringTok{.dump"}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Hierbei werden Host, Port, Benutzer und Datenbankname über Variablen
|
||
definiert, wodurch das Skript flexibel einsetzbar bleibt. Der Parameter
|
||
-Fc erstellt das Backup im sogenannten Custom-Format. Dieses Format
|
||
bietet den Vorteil, dass beim Wiederherstellen einzelne Tabellen oder
|
||
Datenbankobjekte selektiv importiert werden können. Zudem ist es
|
||
komprimiert und effizienter als ein reines SQL-Textdump. Die Ausgabe
|
||
wird direkt in eine Datei im zuvor erstellten Backup-Ordner geschrieben.
|
||
Die Authentifizierung erfolgt über eine .pgpass-Datei, wodurch das
|
||
Backup automatisiert und ohne manuelle Passworteingabe ausgeführt werden
|
||
kann.
|
||
|
||
Neben der Datenbank wird auch der gesamte Anwendungsordner gesichert.
|
||
Dies geschieht mithilfe des tar-Programms, das Dateien zu einem
|
||
komprimierten Archiv zusammenfasst:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\FunctionTok{tar} \AttributeTok{{-}cvpzf} \StringTok{"}\VariableTok{$\{DEST\_DIR\}}\StringTok{/oqtane\_files.tar.gz"} \DataTypeTok{\textbackslash{}}
|
||
\AttributeTok{{-}{-}absolute{-}names} \StringTok{"}\VariableTok{$OQTANE\_DIR}\StringTok{"}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Das Programm tar steht für Tape Archive und wurde ursprünglich
|
||
entwickelt, um mehrere Dateien auf Magnetbändern zu sichern. Heute wird
|
||
es unter Linux und Unix-Systemen verwendet, um mehrere Dateien und
|
||
Verzeichnisse zu einem einzigen Archiv zusammenzufassen. Dabei kann das
|
||
Archiv optional komprimiert werden.
|
||
|
||
Der Parameter -c erstellt ein neues Archiv, -v gibt die verarbeiteten
|
||
Dateien aus, -p erhält die ursprünglichen Dateiberechtigungen und -z
|
||
aktiviert die gzip-Komprimierung. Die Komprimierung reduziert den
|
||
Speicherbedarf der Sicherung erheblich. Besonders relevant ist die
|
||
Option --absolute-names, da dadurch die vollständigen Pfadangaben im
|
||
Archiv gespeichert werden. Dies erleichtert eine spätere exakte
|
||
Wiederherstellung der ursprünglichen Verzeichnisstruktur. Durch die
|
||
Kombination aus Datenbank-Dump und komprimiertem Dateisystem-Archiv
|
||
entsteht ein vollständiges Vollbackup des Systems.
|
||
|
||
Ein Cronjob ist eine zeitgesteuerte Aufgabe unter Linux-Systemen, die
|
||
automatisch zu einem festgelegten Zeitpunkt ausgeführt wird. Er basiert
|
||
auf dem Hintergrunddienst cron, der regelmäßig überprüft, ob geplante
|
||
Befehle gestartet werden müssen.
|
||
|
||
Im vorliegenden Projekt wird ein Cronjob verwendet, um das Backup-Skript
|
||
täglich automatisiert auszuführen. Der entsprechende Eintrag lautet:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\ExtensionTok{30}\NormalTok{ 2 }\PreprocessorTok{*} \PreprocessorTok{*} \PreprocessorTok{*}\NormalTok{ /home/florian/backup{-}script.sh }\OperatorTok{\textgreater{}\textgreater{}}\NormalTok{ /home/florian/backup.log }\DecValTok{2}\OperatorTok{\textgreater{}\&}\DecValTok{1}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Die ersten fünf Felder definieren den Ausführungszeitpunkt. In diesem
|
||
Fall bedeutet die Konfiguration, dass das Skript täglich um 02:30 Uhr
|
||
gestartet wird. Die nächtliche Ausführung reduziert die Systembelastung
|
||
während der regulären Nutzung.
|
||
|
||
Der hintere Teil des Befehls (\textgreater\textgreater{}
|
||
/home/florian/backup.log 2\textgreater\&1) sorgt dafür, dass sowohl
|
||
normale Ausgaben als auch Fehlermeldungen in einer Logdatei gespeichert
|
||
werden. Dadurch kann überprüft werden, ob das Backup erfolgreich
|
||
durchgeführt wurde.
|
||
|
||
Durch den Einsatz eines Cronjobs wird eine regelmäßige und zuverlässige
|
||
Datensicherung ohne manuelles Eingreifen gewährleistet.
|
||
|
||
Ein weiterer Bestandteil des Backup-Systems ist ein automatischer
|
||
Mechanismus zur Verwaltung alter Sicherungen. Da Backups langfristig
|
||
Speicherplatz beanspruchen können, wurde eine Funktion implementiert,
|
||
die nur eine definierte Anzahl an Sicherungen beibehält. In der
|
||
Konfiguration des Skripts wird festgelegt, dass maximal 30 Backups
|
||
gespeichert werden.
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\VariableTok{RETAIN}\OperatorTok{=}\NormalTok{30}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Während der Ausführung überprüft das Skript, wie viele Backup-Ordner im
|
||
Backup-Verzeichnis vorhanden sind. Die Ordner werden anhand ihres
|
||
Zeitstempels sortiert, wodurch die chronologische Reihenfolge der
|
||
Sicherungen eindeutig bestimmt werden kann. Sollte die Anzahl der
|
||
vorhandenen Backups den definierten Wert überschreiten, werden
|
||
automatisch die ältesten Sicherungen gelöscht.
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\ControlFlowTok{if} \KeywordTok{((} \VariableTok{$\{}\OperatorTok{\#}\VariableTok{backups}\OperatorTok{[@]}\VariableTok{\}} \OperatorTok{\textgreater{}} \VariableTok{RETAIN} \KeywordTok{));} \ControlFlowTok{then}
|
||
\ControlFlowTok{for}\NormalTok{ old }\KeywordTok{in} \StringTok{"}\VariableTok{$\{backups}\OperatorTok{[@]:}\NormalTok{RETAIN}\VariableTok{\}}\StringTok{"}\KeywordTok{;} \ControlFlowTok{do}
|
||
\FunctionTok{rm} \AttributeTok{{-}rf} \AttributeTok{{-}{-}} \StringTok{"}\VariableTok{$old}\StringTok{"}
|
||
\ControlFlowTok{done}
|
||
\ControlFlowTok{fi}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Durch diesen Rotationsmechanismus wird verhindert, dass sich im Laufe
|
||
der Zeit eine unbegrenzte Anzahl von Backups ansammelt und dadurch der
|
||
verfügbare Speicherplatz auf dem Server erschöpft wird. Gleichzeitig
|
||
bleibt eine ausreichende Anzahl an Sicherungsständen erhalten, um im
|
||
Fehlerfall auf frühere Systemzustände zurückgreifen zu können.
|
||
|
||
Die gewählte Anzahl von 30 Sicherungen ermöglicht es, bei täglicher
|
||
Ausführung des Backup-Skripts ungefähr einen Monat an
|
||
Wiederherstellungspunkten vorzuhalten. Dadurch wird ein sinnvoller
|
||
Kompromiss zwischen Datensicherheit und effizienter Speicherverwaltung
|
||
erreicht.
|
||
|
||
\paragraph{Implementierung der
|
||
Backup-Skripte}\label{implementierung-der-backup-skripte}
|
||
|
||
Die Implementierung des Backup-Systems erfolgte mittels eines
|
||
Bash-Skripts, das auf dem Linux-Server ausgeführt wird. Bash eignet sich
|
||
besonders für administrative Aufgaben, da sie direkten Zugriff auf
|
||
Systembefehle, Dateien und Prozesse bietet. Das Skript wurde so
|
||
aufgebaut, dass es robust, automatisierbar und nachvollziehbar arbeitet.
|
||
|
||
Zu Beginn des Skripts wird folgende Konfiguration gesetzt:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\CommentTok{\#\#!/usr/bin/env bash}
|
||
\BuiltInTok{set} \AttributeTok{{-}euo}\NormalTok{ pipefail}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Die erste Zeile definiert den Interpreter, mit dem das Skript ausgeführt
|
||
wird. Dadurch wird sichergestellt, dass unabhängig von der
|
||
Systemkonfiguration die korrekte Bash-Version verwendet wird.
|
||
|
||
Die Anweisung set -euo pipefail erhöht die Sicherheit und Stabilität des
|
||
Skripts:
|
||
|
||
• \texttt{-e} beendet das Skript sofort, wenn ein Befehl fehlschlägt •
|
||
\texttt{-u} verhindert die Verwendung nicht definierter Variablen •
|
||
\texttt{-o\ pipefail} sorgt dafür, dass auch Fehler innerhalb von
|
||
Befehls-Pipelines erkannt werden
|
||
|
||
Diese Einstellungen verhindern, dass das Backup bei Fehlern unbemerkt
|
||
unvollständig ausgeführt wird.
|
||
|
||
Im nächsten Schritt werden zentrale Konfigurationsvariablen definiert:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\VariableTok{BACKUP\_ROOT}\OperatorTok{=}\StringTok{"/var/backups/fullserver"}
|
||
\VariableTok{RETAIN}\OperatorTok{=}\NormalTok{30}
|
||
|
||
\VariableTok{PGHOST}\OperatorTok{=}\StringTok{"localhost"}
|
||
\VariableTok{PGPORT}\OperatorTok{=}\StringTok{"5432"}
|
||
\VariableTok{PGUSER}\OperatorTok{=}\StringTok{"florian"}
|
||
\VariableTok{PGDATABASE}\OperatorTok{=}\StringTok{"oqtane"}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Durch die Verwendung von Variablen bleibt das Skript flexibel und
|
||
wartbar. Änderungen, beispielsweise am Speicherort oder an der
|
||
Datenbank, können an einer zentralen Stelle vorgenommen werden, ohne den
|
||
restlichen Code anzupassen.
|
||
|
||
Die Sicherung der PostgreSQL-Datenbank erfolgt mittels pg\_dump im
|
||
Custom-Format. Dieses Format ist besonders geeignet, da es eine flexible
|
||
Wiederherstellung ermöglicht. Die Ausgabe wird direkt in den jeweiligen
|
||
Backup-Ordner geschrieben. Die Authentifizierung erfolgt über eine
|
||
.pgpass-Datei, wodurch das Backup ohne interaktive Passworteingabe
|
||
automatisiert durchgeführt werden kann.
|
||
|
||
Anschließend wird der gesamte Anwendungsordner mit tar archiviert und
|
||
komprimiert. Dabei werden Dateirechte und Verzeichnisstrukturen
|
||
vollständig erhalten. Dies ist insbesondere bei Webanwendungen wichtig,
|
||
da falsche Berechtigungen nach einer Wiederherstellung zu
|
||
Funktionsstörungen führen könnten.
|
||
|
||
Ein weiterer wichtiger Bestandteil der Implementierung ist das
|
||
integrierte Rotationsprinzip. Das Skript überprüft automatisch, wie
|
||
viele Backup-Ordner vorhanden sind. Falls die definierte Grenze von 30
|
||
Sicherungen überschritten wird, werden die ältesten Backups gelöscht.
|
||
Dadurch wird verhindert, dass der verfügbare Speicherplatz durch alte
|
||
Sicherungen dauerhaft belegt wird. Die Sortierung erfolgt anhand der
|
||
Zeitstempel im Ordnernamen, wodurch die chronologische Reihenfolge
|
||
eindeutig bestimmbar ist.
|
||
|
||
Zusätzlich gibt das Skript Statusmeldungen mit Zeitangaben aus:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\BuiltInTok{echo} \StringTok{"[}\VariableTok{$(}\FunctionTok{date} \AttributeTok{{-}Iseconds}\VariableTok{)}\StringTok{] Backup{-}Job abgeschlossen."}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Diese Meldungen werden bei automatischer Ausführung über den Cronjob in
|
||
eine Logdatei geschrieben. Dadurch kann jederzeit überprüft werden, ob
|
||
das Backup erfolgreich abgeschlossen wurde oder ob Fehler aufgetreten
|
||
sind.
|
||
|
||
Die Implementierung zeichnet sich durch folgende Eigenschaften aus:
|
||
|
||
• vollständige Sicherung von Datenbank und Anwendungsdateien •
|
||
automatische tägliche Ausführung • integrierte Fehlerbehandlung •
|
||
strukturierte Archivierung mit Zeitstempel • automatische
|
||
Speicherverwaltung durch Rotationsmechanismus
|
||
|
||
Durch diese Umsetzung wurde ein zuverlässiges und wartbares
|
||
Backup-System geschaffen, das den kontinuierlichen Betrieb der
|
||
Webanwendung unterstützt und im Fehlerfall eine schnelle
|
||
Wiederherstellung ermöglicht.
|
||
|
||
\paragraph{Wiederherstellung von Daten mittels
|
||
Restore-Skripten}\label{wiederherstellung-von-daten-mittels-restore-skripten}
|
||
|
||
Neben der Datensicherung stellt die strukturierte Wiederherstellung der
|
||
Daten einen zentralen Bestandteil des Backup-Systems dar. Zu diesem
|
||
Zweck wurde ein eigenes Bash-Skript implementiert, das sowohl die
|
||
PostgreSQL-Datenbank als auch die Anwendungsdateien aus einem gewählten
|
||
Backup-Ordner wiederherstellt (Restore-Skript). Ziel war es, einen klar
|
||
definierten und kontrollierten Prozess zu schaffen, der im Fehlerfall
|
||
eine vollständige Rücksetzung des Systems ermöglicht.
|
||
|
||
Das Skript beginnt -- analog zum Backup-Skript -- mit einer sicheren
|
||
Ausführungskonfiguration:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\CommentTok{\#\#!/usr/bin/env bash}
|
||
\BuiltInTok{set} \AttributeTok{{-}euo}\NormalTok{ pipefail}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Auch hier sorgt set -euo pipefail dafür, dass das Skript bei Fehlern
|
||
sofort abbricht, keine undefinierten Variablen verwendet werden und
|
||
Fehler innerhalb von Befehls-Pipelines korrekt erkannt werden. Dadurch
|
||
wird verhindert, dass ein unvollständiger oder fehlerhafter Restore
|
||
durchgeführt wird.
|
||
|
||
Zu Beginn wird festgelegt, welcher Backup-Ordner verwendet werden soll.
|
||
Wird beim Start ein Argument übergeben, wird dieses als
|
||
Backup-Verzeichnis interpretiert. Andernfalls wird automatisch das
|
||
neueste Backup ausgewählt:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\ControlFlowTok{if} \KeywordTok{[[} \VariableTok{$\#} \OtherTok{{-}ge}\NormalTok{ 1 }\KeywordTok{]];} \ControlFlowTok{then}
|
||
\VariableTok{BACKUP\_SUBDIR}\OperatorTok{=}\StringTok{"}\VariableTok{$1}\StringTok{"}
|
||
\ControlFlowTok{else}
|
||
\VariableTok{BACKUP\_SUBDIR}\OperatorTok{=}\StringTok{"}\VariableTok{$(}\FunctionTok{ls} \AttributeTok{{-}1} \StringTok{"}\VariableTok{$\{BACKUP\_ROOT\}}\StringTok{"} \KeywordTok{|} \FunctionTok{sort} \KeywordTok{|} \FunctionTok{tail} \AttributeTok{{-}n}\NormalTok{ 1}\VariableTok{)}\StringTok{"}
|
||
\ControlFlowTok{fi}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Diese Logik ermöglicht eine flexible Nutzung des Skripts.
|
||
Administratoren können gezielt einen bestimmten Sicherungsstand
|
||
auswählen oder standardmäßig den aktuellsten verwenden.
|
||
|
||
Vor Beginn der Wiederherstellung erfolgt eine deutliche
|
||
Sicherheitswarnung:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\BuiltInTok{read} \AttributeTok{{-}rp} \StringTok{"Fortfahren? (ja/nein): "} \VariableTok{answer}
|
||
\ControlFlowTok{if} \KeywordTok{[[} \StringTok{"}\VariableTok{$answer}\StringTok{"} \OtherTok{!=} \StringTok{"ja"} \KeywordTok{]];} \ControlFlowTok{then}
|
||
\BuiltInTok{exit}\NormalTok{ 0}
|
||
\ControlFlowTok{fi}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Diese Abfrage dient als Schutzmechanismus, da der Restore-Prozess
|
||
bestehende Daten überschreibt. Erst nach expliziter Bestätigung wird die
|
||
Wiederherstellung gestartet.
|
||
|
||
Die Wiederherstellung der PostgreSQL-Datenbank erfolgt in mehreren
|
||
Schritten. Zunächst wird -- falls vorhanden -- die bestehende Datenbank
|
||
gelöscht:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\ExtensionTok{dropdb} \AttributeTok{{-}h} \StringTok{"}\VariableTok{$PGHOST}\StringTok{"} \AttributeTok{{-}p} \StringTok{"}\VariableTok{$PGPORT}\StringTok{"} \AttributeTok{{-}U} \StringTok{"}\VariableTok{$PGUSER}\StringTok{"} \StringTok{"}\VariableTok{$PGDATABASE}\StringTok{"}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Anschließend wird eine neue, leere Datenbank erstellt:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\ExtensionTok{createdb} \AttributeTok{{-}h} \StringTok{"}\VariableTok{$PGHOST}\StringTok{"} \AttributeTok{{-}p} \StringTok{"}\VariableTok{$PGPORT}\StringTok{"} \AttributeTok{{-}U} \StringTok{"}\VariableTok{$PGUSER}\StringTok{"} \StringTok{"}\VariableTok{$PGDATABASE}\StringTok{"}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Danach wird der zuvor gesicherte Dump eingespielt:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\ExtensionTok{pg\_restore} \AttributeTok{{-}h} \StringTok{"}\VariableTok{$PGHOST}\StringTok{"} \AttributeTok{{-}p} \StringTok{"}\VariableTok{$PGPORT}\StringTok{"} \AttributeTok{{-}U} \StringTok{"}\VariableTok{$PGUSER}\StringTok{"} \DataTypeTok{\textbackslash{}}
|
||
\AttributeTok{{-}d} \StringTok{"}\VariableTok{$PGDATABASE}\StringTok{"} \AttributeTok{{-}c} \StringTok{"}\VariableTok{$DUMP\_FILE}\StringTok{"}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Das Programm pg\_restore liest das im Custom-Format gespeicherte Backup
|
||
ein und stellt sämtliche Tabellen, Indizes und Datenbankobjekte wieder
|
||
her. Die Option -c sorgt dafür, dass bestehende Objekte vor dem Import
|
||
entfernt werden, wodurch Konflikte vermieden werden.
|
||
|
||
Neben der Datenbank wird auch der Anwendungsordner wiederhergestellt.
|
||
Bevor die neuen Dateien entpackt werden, wird der aktuell vorhandene
|
||
Ordner zur Sicherheit umbenannt:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\FunctionTok{mv} \StringTok{"}\VariableTok{$OQTANE\_DIR}\StringTok{"} \StringTok{"}\VariableTok{$\{OQTANE\_DIR\}}\StringTok{.old.}\VariableTok{$(}\FunctionTok{date}\NormalTok{ +\%s}\VariableTok{)}\StringTok{"}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Diese Maßnahme verhindert einen vollständigen Datenverlust, falls beim
|
||
Restore ein Problem auftreten sollte. Anschließend wird das Archiv
|
||
entpackt:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\FunctionTok{tar} \AttributeTok{{-}xvpzf} \StringTok{"}\VariableTok{$FILES\_ARCHIVE}\StringTok{"}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Der Parameter -x extrahiert das Archiv, -p stellt die ursprünglichen
|
||
Dateiberechtigungen wieder her und -z dekomprimiert das gzip-Archiv.
|
||
Dadurch wird die komplette Ordnerstruktur in ihrem ursprünglichen
|
||
Zustand wiederhergestellt.
|
||
|
||
Zusammenfassend ermöglicht das Restore-Skript eine vollständige
|
||
Rücksetzung der Webanwendung auf einen definierten Sicherungsstand.
|
||
Durch die Kombination aus Sicherheitsabfrage, kontrollierter
|
||
Datenbank-Neuerstellung und strukturiertem Dateirestore wird ein
|
||
zuverlässiger und nachvollziehbarer Wiederherstellungsprozess
|
||
gewährleistet. Das System ergänzt somit das Backup-Konzept um eine
|
||
praxisnahe und technisch saubere Lösung für den Ernstfall.
|
||
|
||
\paragraph{Fazit zur Datensicherung}\label{fazit-zur-datensicherung}
|
||
|
||
Durch die Implementierung eines automatisierten Backup- und
|
||
Restore-Systems wurde eine zuverlässige Grundlage für die
|
||
Datensicherheit der Webanwendung geschaffen. Das entwickelte System
|
||
ermöglicht eine regelmäßige Sicherung sowohl der PostgreSQL-Datenbank
|
||
als auch der vollständigen Anwendungsdateien. Durch die automatisierte
|
||
Ausführung mittels Cronjob wird sichergestellt, dass die Backups ohne
|
||
manuelles Eingreifen täglich erstellt werden.
|
||
|
||
Zusätzlich sorgt das integrierte Rotationsprinzip dafür, dass ältere
|
||
Sicherungen automatisch entfernt werden und der verfügbare Speicherplatz
|
||
effizient genutzt wird. Die strukturierte Ablage der Backups mit
|
||
Zeitstempeln erleichtert die Auswahl eines bestimmten Sicherungsstandes.
|
||
|
||
Neben der Datensicherung wurde auch ein Restore-Skript implementiert,
|
||
das eine vollständige Wiederherstellung des Systems ermöglicht. Dabei
|
||
werden sowohl die Datenbank als auch die Anwendungsdateien aus einem
|
||
ausgewählten Backup wiederhergestellt. Sicherheitsmechanismen wie
|
||
Bestätigungsabfragen und das temporäre Umbenennen bestehender Daten
|
||
reduzieren das Risiko von Datenverlust während des
|
||
Wiederherstellungsprozesses.
|
||
|
||
Insgesamt stellt das entwickelte Backup-System eine robuste und
|
||
praxisnahe Lösung dar, die den sicheren Betrieb der Webanwendung
|
||
unterstützt und im Fehlerfall eine schnelle Wiederherstellung der Daten
|
||
ermöglicht.
|
||
|
||
\subsubsection{Benutzerverwaltung und Authentifizierung per
|
||
LinkedIn}\label{benutzerverwaltung-und-authentifizierung-per-linkedin}
|
||
|
||
\paragraph{Authentifizierung mittels OAuth
|
||
2.0}\label{authentifizierung-mittels-oauth-2.0}
|
||
|
||
Zur Anmeldung auf der entwickelten Webplattform wurde eine
|
||
Authentifizierung über das Business-Netzwerk LinkedIn implementiert.
|
||
Dabei kommt das standardisierte Autorisierungsprotokoll OAuth 2.0 zum
|
||
Einsatz.\footnote{IETF (2012) (siehe Internet-/Intranetverzeichnis).}
|
||
Dieses Verfahren ermöglicht es, Benutzer über externe Identitätsanbieter
|
||
zu authentifizieren, ohne dass deren Zugangsdaten direkt an die
|
||
Webanwendung übertragen werden müssen.
|
||
|
||
OAuth 2.0 basiert auf dem Prinzip der delegierten Autorisierung. Dabei
|
||
erlaubt ein Benutzer einer Anwendung, bestimmte Informationen seines
|
||
Kontos bei einem externen Dienst zu verwenden. Die eigentlichen
|
||
Zugangsdaten -- beispielsweise das LinkedIn-Passwort -- verbleiben dabei
|
||
ausschließlich beim Identitätsanbieter.
|
||
|
||
Der grundlegende Ablauf einer OAuth-Authentifizierung ist in Abbildung X
|
||
dargestellt. Dabei wird der Benutzer zunächst zur Login-Seite des
|
||
externen Anbieters weitergeleitet. Nach erfolgreicher Anmeldung
|
||
bestätigt der Benutzer, dass die Anwendung Zugriff auf bestimmte
|
||
Profildaten erhalten darf.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\pandocbounded{\includegraphics[keepaspectratio]{./images/04-Florian/oauth-flow.png}}
|
||
\caption{Ablauf der OAuth-Authentifizierung (Erstellt mit ChatGPT)}
|
||
\end{figure}
|
||
|
||
Die Abbildung zeigt den Ablauf der OAuth-Authentifizierung. Zunächst
|
||
erfolgt die Weiterleitung zur LinkedIn-Anmeldeseite, anschließend wird
|
||
ein Autorisierungscode (Authorization Code) an die Webanwendung
|
||
zurückgegeben, welcher gegen einen Zugriffstoken (Access Token)
|
||
ausgetauscht wird.
|
||
|
||
Nach der Autorisierung sendet LinkedIn einen solchen Autorisierungscode
|
||
an die Webanwendung zurück. Dieser Code wird anschließend vom Server der
|
||
Anwendung gegen ein Zugriffstoken ausgetauscht. Mit Hilfe dieses Tokens
|
||
kann die Webanwendung anschließend die freigegebenen Benutzerdaten vom
|
||
LinkedIn-Server abrufen.
|
||
|
||
Der Vorteil dieses Verfahrens liegt darin, dass die Webanwendung zu
|
||
keinem Zeitpunkt Zugriff auf das Passwort des Benutzers erhält. Dadurch
|
||
wird ein höheres Sicherheitsniveau erreicht und gleichzeitig die
|
||
Benutzerfreundlichkeit verbessert, da sich Benutzer mit ihrem
|
||
bestehenden LinkedIn-Konto anmelden können.
|
||
|
||
\paragraph{Technische Umsetzung der LinkedIn-Anmeldung in
|
||
Oqtane}\label{technische-umsetzung-der-linkedin-anmeldung-in-oqtane}
|
||
|
||
Die technische Umsetzung der LinkedIn-Authentifizierung erfolgte über
|
||
das integrierte External Login System\footnote{Oqtane Foundation (2024a)
|
||
(siehe Internet-/Intranetverzeichnis).} des Content-Management-Systems
|
||
Oqtane. Dieses System ermöglicht die Integration externer
|
||
Identitätsanbieter über standardisierte Protokolle wie OAuth 2.0.
|
||
|
||
Für die Verbindung mit LinkedIn wurde zunächst eine Entwickleranwendung
|
||
im LinkedIn Developer Portal\footnote{Microsoft (2026d) (siehe
|
||
Internet-/Intranetverzeichnis).} erstellt. Dabei werden zwei zentrale
|
||
Zugangsdaten generiert:
|
||
|
||
• Client ID • Client Secret
|
||
|
||
Diese dienen zur Identifikation der Webanwendung gegenüber den
|
||
LinkedIn-Servern.
|
||
|
||
Innerhalb der Oqtane-Konfiguration wurde anschließend ein neuer
|
||
OAuth-Provider eingerichtet. Dabei mussten mehrere Parameter definiert
|
||
werden, darunter die Autorisierungs- und Token-Endpunkte von LinkedIn.
|
||
|
||
Beispielsweise wird für die Benutzerautorisierung folgende Adresse
|
||
verwendet:
|
||
|
||
https://www.linkedin.com/oauth/v2/authorization
|
||
|
||
Nach erfolgreicher Anmeldung stellt LinkedIn über folgenden Endpunkt ein
|
||
Zugriffstoken bereit:
|
||
|
||
https://www.linkedin.com/oauth/v2/accessToken
|
||
|
||
Zusätzlich wurde eine sogenannte Redirect-URL definiert. Diese URL wird
|
||
von LinkedIn verwendet, um den Benutzer nach erfolgreicher
|
||
Authentifizierung wieder zurück zur Webanwendung zu leiten.
|
||
|
||
In der Konfiguration wurde außerdem festgelegt, welche Benutzerdaten von
|
||
LinkedIn übernommen werden sollen. Dazu gehören unter anderem:
|
||
|
||
• Benutzername • E-Mail-Adresse • eindeutige Benutzer-ID
|
||
|
||
Diese Daten werden von Oqtane als sogenannte Claims verarbeitet und
|
||
anschließend dem Benutzerkonto der Plattform zugeordnet.
|
||
|
||
Darüber hinaus wurde in den Einstellungen aktiviert, dass bei der ersten
|
||
Anmeldung automatisch ein neues Benutzerkonto erstellt werden kann.
|
||
Dadurch können sich neue Nutzer direkt über ihr LinkedIn-Konto
|
||
registrieren.
|
||
|
||
\paragraph{Ablauf des
|
||
Anmeldeprozesses}\label{ablauf-des-anmeldeprozesses}
|
||
|
||
Der eigentliche Anmeldevorgang erfolgt in mehreren aufeinanderfolgenden
|
||
Schritten. Zunächst wählt der Benutzer auf der Login-Seite der
|
||
Webplattform die Option zur Anmeldung über LinkedIn aus.
|
||
|
||
Daraufhin wird der Benutzer zur LinkedIn-Authentifizierungsseite
|
||
weitergeleitet. Dort meldet sich der Benutzer mit seinem LinkedIn-Konto
|
||
an und bestätigt die Autorisierung der Anwendung.
|
||
|
||
Nach erfolgreicher Authentifizierung sendet LinkedIn eine Antwort an die
|
||
zuvor definierte Redirect-URL der Webanwendung. Diese Antwort enthält
|
||
einen Autorisierungscode, der anschließend vom Server der Webanwendung
|
||
gegen ein Zugriffstoken ausgetauscht wird.
|
||
|
||
Wie in Abschnitt 4.3.1 beschrieben, werden die abgerufenen Profildaten
|
||
zur Identifikation oder Neuanlage des Benutzerkontos in der lokalen
|
||
Datenbank verwendet.
|
||
|
||
\subsubsection{Implementierung des
|
||
Premium-Bereichs}\label{implementierung-des-premium-bereichs}
|
||
|
||
\paragraph{Ziel und Zweck des
|
||
Premium-Bereichs}\label{ziel-und-zweck-des-premium-bereichs}
|
||
|
||
Der Premium-Bereich wurde mit dem Ziel entwickelt, den Mitgliedern des
|
||
SZU Absolventenvereins einen klar abgegrenzten, exklusiven Bereich
|
||
innerhalb der VereinsWebseite bereitzustellen. Das Premium-Bereich-Modul
|
||
ist eine Erweiterung für das Content-Management-System Oqtane und bildet
|
||
das Kernstück des digitalen Mitgliederbereichs. Es ermöglicht
|
||
Mitgliedern, sich über das Hochladen eines Ingenieur-Antrags als
|
||
PDF-Dokument für eine zeitlich begrenzte Premium-Mitgliedschaft zu
|
||
qualifizieren. Premium-Mitglieder erhalten Zugang zu exklusiven
|
||
Funktionen wie dem Einsehen genehmigter Anträge anderer Mitglieder sowie
|
||
einer Mitgliedersuche mit integrierter Kontaktfunktion.
|
||
|
||
Der zentrale Zweck besteht darin, einen Anreiz für aktives Engagement im
|
||
Verein zu schaffen. Dadurch entsteht ein Kreislauf, in dem qualitativ
|
||
hochwertige Anträge die Wissensbasis der Gemeinschaft bereichern und
|
||
gleichzeitig den einreichenden Mitgliedern einen konkreten Gegenwert in
|
||
Form von Premium-Funktionen bieten. Der Premium-Bereich dient darüber
|
||
hinaus als digitales Netzwerk-Instrument. Durch die Kombination aus
|
||
Antrags-Einsicht, Mitgliedersuche und Kontaktfunktion wird eine
|
||
Plattform geschaffen, die den fachlichen Austausch zwischen Absolventen
|
||
fördert und die Vernetzung innerhalb der Gemeinschaft stärkt. Die
|
||
zeitliche Begrenzung der Premium-Mitgliedschaft auf 12 Monate sorgt
|
||
dafür, dass Mitglieder regelmäßig aktiv bleiben und neue Inhalte
|
||
beitragen, um ihren Premium-Status aufrechtzuerhalten.
|
||
|
||
Die Entwicklung erfolgte als eigenständiges Oqtane-Modul, wodurch eine
|
||
nahtlose Integration in die bestehende VereinsWebseite gewährleistet
|
||
wird. Das Modul nutzt dabei die vom Framework bereitgestellten
|
||
Mechanismen für Authentifizierung, Autorisierung, Datenbankzugriff und
|
||
Dateiverwaltung. Die Architektur folgt etablierten Entwurfsmustern wie
|
||
dem Repository-Pattern, Dependency Injection und dem
|
||
Service-Layer-Muster. Das kumulative Premium-System mit vollständigem
|
||
Audit-Trail stellt sicher, dass alle Statusänderungen transparent und
|
||
nachvollziehbar sind. Die modulare Struktur erlaubt eine einfache
|
||
Erweiterung um zusätzliche Funktionen, ohne die bestehende Codebasis
|
||
grundlegend verändern zu müssen.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.8\linewidth,height=0.7\textheight]{architecture-premium-module.pdf}
|
||
\caption{Architektur des Premium-Bereich-Moduls}
|
||
\end{figure}
|
||
|
||
\paragraph{Funktionalität und Features des
|
||
Premium-Bereichs}\label{funktionalituxe4t-und-features-des-premium-bereichs}
|
||
|
||
Der Premium-Bereich umfasst mehrere miteinander verknüpfte Funktionen,
|
||
die gemeinsam ein geschlossenes System bilden.
|
||
|
||
\textbf{Ingenieur-Antrags-Workflow}
|
||
|
||
Das Kernfeature ist der Ingenieur-Antrags-Workflow. Mitglieder können
|
||
über eine dedizierte Seite einen Antrag mit Titel, Kurzbeschreibung und
|
||
PDF-Dokument einreichen. Die zentrale Datenstruktur dafür ist die Klasse
|
||
\texttt{EngineerApplication}, die in der Tabelle
|
||
\texttt{SZUAbsolventenvereinEngineerApplications} gespeichert wird:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\OperatorTok{[}\FunctionTok{Table}\OperatorTok{(}\StringTok{"SZUAbsolventenvereinEngineerApplications"}\OperatorTok{)]}
|
||
\KeywordTok{public} \KeywordTok{class}\NormalTok{ EngineerApplication }\OperatorTok{:}\NormalTok{ ModelBase}
|
||
\OperatorTok{\{}
|
||
\OperatorTok{[}\NormalTok{Key}\OperatorTok{]} \KeywordTok{public} \DataTypeTok{int}\NormalTok{ ApplicationId }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\KeywordTok{public} \DataTypeTok{int}\NormalTok{ UserId }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\KeywordTok{public} \DataTypeTok{int}\NormalTok{ ModuleId }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\KeywordTok{public} \DataTypeTok{int}\NormalTok{ FileId }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\OperatorTok{[}\FunctionTok{StringLength}\OperatorTok{(}\DecValTok{256}\OperatorTok{)]} \KeywordTok{public} \DataTypeTok{string}\NormalTok{ Title }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\KeywordTok{public} \DataTypeTok{string}\NormalTok{ ShortDescription }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\OperatorTok{[}\FunctionTok{StringLength}\OperatorTok{(}\DecValTok{50}\OperatorTok{)]} \KeywordTok{public} \DataTypeTok{string}\NormalTok{ Status }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\KeywordTok{public}\NormalTok{ DateTime}\OperatorTok{?}\NormalTok{ SubmittedOn }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\KeywordTok{public}\NormalTok{ DateTime}\OperatorTok{?}\NormalTok{ ApprovedOn }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\OperatorTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Die Klasse erbt von \texttt{ModelBase}, wodurch automatisch die
|
||
Audit-Felder \texttt{CreatedBy}, \texttt{CreatedOn}, \texttt{ModifiedBy}
|
||
und \texttt{ModifiedOn} zur Verfügung stehen. Das Feld \texttt{Status}
|
||
bildet den aktuellen Workflow-Schritt ab und kann die Werte „Draft'',
|
||
„Submitted'', „Approved'' oder „Rejected'' annehmen. Die hochgeladene
|
||
PDF-Datei wird nicht direkt gespeichert, sondern über eine
|
||
\texttt{FileId} im Oqtane-Dateisystem referenziert. Das nachfolgende
|
||
Klassendiagramm veranschaulicht diese Struktur und zeigt, wie
|
||
Basis-Metadaten durch die Vorfahrenklasse abgedeckt werden, während
|
||
antragsbezogene Daten in der Hauptklasse gekapselt bleiben.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\pandocbounded{\includegraphics[keepaspectratio]{classdiagram-engineer-application.pdf}}
|
||
\caption{Klassendiagramm der EngineerApplication-Entität}
|
||
\end{figure}
|
||
|
||
Der Lebenszyklus eines Antrags durchläuft mehrere Phasen. Der Benutzer
|
||
beginnt auf der Antragsseite \texttt{Apply.razor}, wo ein Formular mit
|
||
Feldern für Titel, Kurzbeschreibung und einer Dateiauswahl über den
|
||
integrierten Oqtane FileManager bereitgestellt wird. Der FileManager
|
||
stellt eine benutzerfreundliche Upload-Oberfläche mit
|
||
Fortschrittsanzeige bereit und akzeptiert ausschließlich PDF-Dateien.
|
||
Die hochgeladene Datei wird dabei im Oqtane-Dateisystem abgelegt und das
|
||
Modul speichert lediglich die resultierende Datei-ID in der
|
||
Antragstabelle.
|
||
|
||
Beim Absenden des Formulars erstellt die clientseitige Methode
|
||
\texttt{SubmitApplication} ein neues \texttt{EngineerApplication}-Objekt
|
||
und befüllt es mit den Formulardaten. Der Status wird dabei automatisch
|
||
auf „Published'' gesetzt, zusammen mit den Zeitstempeln für Einreichung
|
||
und Genehmigung. Die Methode unterscheidet anhand der
|
||
\texttt{ApplicationId}, ob ein neuer Antrag über den Service
|
||
\texttt{AddApplicationAsync} erstellt oder ein bestehender über
|
||
\texttt{UpdateApplicationAsync} aktualisiert werden soll. Falls keine
|
||
Datei ausgewählt wurde, wird der Vorgang mit einer entsprechenden
|
||
Fehlermeldung abgebrochen. Die Kommunikation mit dem Server erfolgt über
|
||
den injizierten \texttt{ApplicationService}, der als HTTP-Client die
|
||
Anfragen an den REST-Controller weiterleitet. Wie die nachfolgende
|
||
Abbildung zeigt, führt die klare Gestaltung der Benutzeroberfläche den
|
||
Benutzer im Browser intuitiv durch den Einreichungsprozess und stellt
|
||
auch den Bearbeitungsstatus des Antrags übersichtlich dar.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\pandocbounded{\includegraphics[keepaspectratio]{./images/04-Florian/ingenieur-antrag-status.png}}
|
||
\caption{Formular zum Einreichen eines Ingenieur-Antrags}
|
||
\end{figure}
|
||
|
||
Serverseitig nimmt die Methode \texttt{AddApplicationAsync} im
|
||
\texttt{ServerEngineerApplicationService} den Antrag entgegen. Dort wird
|
||
zunächst geprüft, ob der Benutzer authentifiziert ist und die
|
||
View-Berechtigung für das Modul besitzt. Die User-ID wird aus dem
|
||
HTTP-Kontext extrahiert und dem Antrag zugewiesen, um sicherzustellen,
|
||
dass kein Benutzer Anträge im Namen anderer erstellen kann. Anschließend
|
||
wird der Antrag über das Repository in der Datenbank persistiert.
|
||
|
||
Ein Administrator kann den Antrag entweder genehmigen oder ablehnen. Bei
|
||
einer Genehmigung wird der Status auf „Approved'' gesetzt und
|
||
automatisch über den \texttt{PremiumService} eine 12-monatige
|
||
Premium-Mitgliedschaft vergeben. Bei einer Ablehnung wechselt der Status
|
||
auf „Rejected'' und der Benutzer hat die Möglichkeit, einen
|
||
überarbeiteten Antrag erneut einzureichen.
|
||
|
||
\textbf{Anzeige genehmigter Anträge}
|
||
|
||
Die Antrags-Listenansicht bildet das zweite zentrale Feature. Wie in der
|
||
nachfolgenden Abbildung zu sehen ist, sehen Premium-Mitglieder alle
|
||
genehmigten und veröffentlichten Anträge in einer benutzerfreundlichen
|
||
Kartenansicht und können Titel, Autor sowie Kurzbeschreibung auf einen
|
||
Blick erfassen. Jede Karte enthält das Veröffentlichungsdatum und
|
||
integrierte Schaltflächen, über welche das zugehörige PDF-Dokument bei
|
||
Bedarf direkt im Browser via eingebettetem iFrame betrachtet oder
|
||
heruntergeladen werden kann.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\pandocbounded{\includegraphics[keepaspectratio]{./images/04-Florian/ingenieur-antraege-liste.png}}
|
||
\caption{Ansicht der genehmigten Ingenieur-Anträge}
|
||
\end{figure}
|
||
|
||
Die serverseitige Methode \texttt{GetApplicationsAsync} steuert dabei
|
||
die rollenbasierte Zugriffslogik und entscheidet, welche Anträge ein
|
||
Benutzer sehen darf:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\KeywordTok{public}\NormalTok{ Task}\OperatorTok{\textless{}}\NormalTok{List}\OperatorTok{\textless{}}\NormalTok{EngineerApplication}\OperatorTok{\textgreater{}\textgreater{}} \FunctionTok{GetApplicationsAsync}\OperatorTok{(}\DataTypeTok{int}\NormalTok{ ModuleId}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\DataTypeTok{var}\NormalTok{ user }\OperatorTok{=}\NormalTok{ \_accessor}\OperatorTok{.}\FunctionTok{HttpContext}\OperatorTok{.}\FunctionTok{User}\OperatorTok{;}
|
||
\KeywordTok{if} \OperatorTok{(}\NormalTok{\_userPermissions}\OperatorTok{.}\FunctionTok{IsAuthorized}\OperatorTok{(}\NormalTok{user}\OperatorTok{,}\NormalTok{ \_alias}\OperatorTok{.}\FunctionTok{SiteId}\OperatorTok{,}\NormalTok{ EntityNames}\OperatorTok{.}\FunctionTok{Module}\OperatorTok{,}\NormalTok{ ModuleId}\OperatorTok{,}\NormalTok{ PermissionNames}\OperatorTok{.}\FunctionTok{Edit}\OperatorTok{))}
|
||
\OperatorTok{\{}
|
||
\KeywordTok{return}\NormalTok{ Task}\OperatorTok{.}\FunctionTok{FromResult}\OperatorTok{(}\NormalTok{\_repository}\OperatorTok{.}\FunctionTok{GetEngineerApplications}\OperatorTok{(}\NormalTok{ModuleId}\OperatorTok{).}\FunctionTok{ToList}\OperatorTok{());}
|
||
\OperatorTok{\}}
|
||
|
||
\DataTypeTok{var}\NormalTok{ userId }\OperatorTok{=}\NormalTok{ \_accessor}\OperatorTok{.}\FunctionTok{HttpContext}\OperatorTok{.}\FunctionTok{GetUserId}\OperatorTok{();}
|
||
\DataTypeTok{var}\NormalTok{ results }\OperatorTok{=} \KeywordTok{new}\NormalTok{ List}\OperatorTok{\textless{}}\NormalTok{EngineerApplication}\OperatorTok{\textgreater{}();}
|
||
|
||
\KeywordTok{if} \OperatorTok{(}\NormalTok{userId }\OperatorTok{!=} \OperatorTok{{-}}\DecValTok{1}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\DataTypeTok{var}\NormalTok{ ownApps }\OperatorTok{=}\NormalTok{ \_repository}\OperatorTok{.}\FunctionTok{GetEngineerApplications}\OperatorTok{(}\NormalTok{ModuleId}\OperatorTok{)}
|
||
\OperatorTok{.}\FunctionTok{Where}\OperatorTok{(}\NormalTok{a }\OperatorTok{=\textgreater{}}\NormalTok{ a}\OperatorTok{.}\FunctionTok{UserId} \OperatorTok{==}\NormalTok{ userId}\OperatorTok{).}\FunctionTok{ToList}\OperatorTok{();}
|
||
\NormalTok{ results}\OperatorTok{.}\FunctionTok{AddRange}\OperatorTok{(}\NormalTok{ownApps}\OperatorTok{);}
|
||
\OperatorTok{\}}
|
||
|
||
\KeywordTok{if} \OperatorTok{(}\FunctionTok{IsUserPremium}\OperatorTok{(}\NormalTok{user}\OperatorTok{))}
|
||
\OperatorTok{\{}
|
||
\DataTypeTok{var}\NormalTok{ approved }\OperatorTok{=}\NormalTok{ \_repository}\OperatorTok{.}\FunctionTok{GetEngineerApplications}\OperatorTok{(}\NormalTok{ModuleId}\OperatorTok{,} \StringTok{"Approved"}\OperatorTok{);}
|
||
\DataTypeTok{var}\NormalTok{ published }\OperatorTok{=}\NormalTok{ \_repository}\OperatorTok{.}\FunctionTok{GetEngineerApplications}\OperatorTok{(}\NormalTok{ModuleId}\OperatorTok{,} \StringTok{"Published"}\OperatorTok{);}
|
||
\NormalTok{ results}\OperatorTok{.}\FunctionTok{AddRange}\OperatorTok{(}\NormalTok{approved}\OperatorTok{.}\FunctionTok{Union}\OperatorTok{(}\NormalTok{published}\OperatorTok{));}
|
||
\NormalTok{ results }\OperatorTok{=}\NormalTok{ results}\OperatorTok{.}\FunctionTok{GroupBy}\OperatorTok{(}\NormalTok{a }\OperatorTok{=\textgreater{}}\NormalTok{ a}\OperatorTok{.}\FunctionTok{ApplicationId}\OperatorTok{).}\FunctionTok{Select}\OperatorTok{(}\NormalTok{g }\OperatorTok{=\textgreater{}}\NormalTok{ g}\OperatorTok{.}\FunctionTok{First}\OperatorTok{()).}\FunctionTok{ToList}\OperatorTok{();}
|
||
\OperatorTok{\}}
|
||
|
||
\KeywordTok{return}\NormalTok{ Task}\OperatorTok{.}\FunctionTok{FromResult}\OperatorTok{(}\NormalTok{results}\OperatorTok{);}
|
||
\OperatorTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Administratoren erhalten alle Anträge zurück. Für andere Benutzer werden
|
||
zunächst die eigenen Anträge geladen. Wenn der Benutzer Premium-Status
|
||
hat, werden zusätzlich alle genehmigten und veröffentlichten Anträge
|
||
anderer Benutzer ergänzt. Durch \texttt{GroupBy} werden Duplikate
|
||
entfernt, die entstehen können, wenn ein eigener Antrag gleichzeitig den
|
||
Status „Approved'' trägt.
|
||
|
||
\textbf{Mitgliedersuche und Kontaktfunktion}
|
||
|
||
Die in der nachfolgenden Abbildung gezeigte Mitgliedersuche ermöglicht
|
||
Premium-Mitgliedern das gezielte Auffinden anderer registrierter
|
||
Benutzer. Die clientseitige Blazor-Komponente \texttt{UserSearch.razor}
|
||
stellt ein Eingabefeld bereit, über das der Benutzer seinen Suchbegriff
|
||
eingibt. Aus der dann resultierenden Listenansicht heraus ermöglicht
|
||
eine Kontaktfunktion, Nachrichten sicher an die gefundenen Personen zu
|
||
senden, ohne deren direkte E-Mail-Adresse offenzulegen. Bei jeder Suche
|
||
wird der eingegebene Text an den \texttt{ServerUserContactService} auf
|
||
dem Server übermittelt, der die eigentliche Suchlogik implementiert.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\pandocbounded{\includegraphics[keepaspectratio]{./images/04-Florian/premium-mitglieder-suche.png}}
|
||
\caption{Mitgliedersuche und Kontaktfunktion für Premium-Mitglieder}
|
||
\end{figure}
|
||
|
||
Die serverseitige Methode \texttt{SearchUsersAsync} prüft zunächst, ob
|
||
der Suchbegriff mindestens drei Zeichen umfasst, um übermäßig breite
|
||
Abfragen zu vermeiden, und ob der anfragende Benutzer authentifiziert
|
||
ist. Anschließend durchsucht sie die Benutzerdatenbank sowohl nach
|
||
Anzeigenamen als auch nach Benutzernamen, wobei die Suche
|
||
groß-/kleinschreibungsunabhängig erfolgt. Die Ergebnisse werden auf
|
||
maximal 20 Treffer begrenzt.
|
||
|
||
Besonders wichtig ist die Datenschutzfilterung: Anstatt die
|
||
vollständigen \texttt{User}-Objekte aus der Datenbank zurückzugeben,
|
||
erstellt die Methode neue, reduzierte Objekte, die nur die Felder
|
||
\texttt{UserId}, \texttt{Username}, \texttt{DisplayName} und
|
||
\texttt{PhotoFileId} enthalten. E-Mail-Adressen, Passwort-Hashes und
|
||
andere sensible Daten werden dadurch serverseitig herausgefiltert, bevor
|
||
die Ergebnisse an den Client gesendet werden. Dieser Ansatz folgt dem
|
||
Prinzip der Datenminimierung --- es werden nur die Informationen
|
||
übertragen, die für die Anzeige der Suchergebnisse tatsächlich benötigt
|
||
werden.
|
||
|
||
Die Kontaktfunktion ermöglicht es Premium-Mitgliedern, aus den
|
||
Suchergebnissen heraus direkt eine Nachricht an den gefundenen Benutzer
|
||
zu senden. Der Nachrichtenversand erfolgt über das
|
||
Oqtane-Benachrichtigungssystem. Dabei werden pro Nachricht zwei separate
|
||
Benachrichtigungen erstellt: Die erste Benachrichtigung hat ein leeres
|
||
\texttt{ToEmail}-Feld und wird daher ausschließlich als In-App-Nachricht
|
||
zugestellt, die der Empfänger beim nächsten Login in seinem
|
||
Benachrichtigungsbereich sieht. Die zweite Benachrichtigung enthält die
|
||
E-Mail-Adresse des Empfängers und löst zusätzlich eine E-Mail-Zustellung
|
||
aus. Durch diesen dualen Mechanismus wird sichergestellt, dass der
|
||
Empfänger sowohl innerhalb als auch außerhalb der Plattform erreicht
|
||
wird, ohne dass der Absender die E-Mail-Adresse des Empfängers jemals zu
|
||
sehen bekommt.
|
||
|
||
Ergänzend steht eine Meldefunktion zur Verfügung, über die
|
||
Premium-Mitglieder Anträge mit unangemessenen oder fehlerhaften Inhalten
|
||
melden können. Diese Community-Moderationsfunktion unterstützt die
|
||
Administratoren bei der Qualitätssicherung der veröffentlichten Inhalte.
|
||
|
||
\textbf{Datenbank und Persistenz}
|
||
|
||
Alle Entitäten werden über einen Entity-Framework-Core-Datenbankkontext
|
||
verwaltet, der die Multi-Tenant-Datenbankverbindung automatisch
|
||
handhabt:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\KeywordTok{public} \KeywordTok{class}\NormalTok{ PremiumAreaContext }\OperatorTok{:}\NormalTok{ DBContextBase}\OperatorTok{,}\NormalTok{ ITransientService}\OperatorTok{,}\NormalTok{ IMultiDatabase}
|
||
\OperatorTok{\{}
|
||
\KeywordTok{public} \KeywordTok{virtual}\NormalTok{ DbSet}\OperatorTok{\textless{}}\NormalTok{Models}\OperatorTok{.}\FunctionTok{PremiumArea}\OperatorTok{\textgreater{}}\NormalTok{ PremiumArea }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\KeywordTok{public} \KeywordTok{virtual}\NormalTok{ DbSet}\OperatorTok{\textless{}}\NormalTok{Models}\OperatorTok{.}\FunctionTok{EngineerApplication}\OperatorTok{\textgreater{}}\NormalTok{ EngineerApplication }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\KeywordTok{public} \KeywordTok{virtual}\NormalTok{ DbSet}\OperatorTok{\textless{}}\NormalTok{Models}\OperatorTok{.}\FunctionTok{UserPremium}\OperatorTok{\textgreater{}}\NormalTok{ UserPremium }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
\KeywordTok{public} \KeywordTok{virtual}\NormalTok{ DbSet}\OperatorTok{\textless{}}\NormalTok{Models}\OperatorTok{.}\FunctionTok{PremiumEvent}\OperatorTok{\textgreater{}}\NormalTok{ PremiumEvent }\OperatorTok{\{} \KeywordTok{get}\OperatorTok{;} \KeywordTok{set}\OperatorTok{;} \OperatorTok{\}}
|
||
|
||
\KeywordTok{public} \FunctionTok{PremiumAreaContext}\OperatorTok{(}\NormalTok{IDBContextDependencies DBContextDependencies}\OperatorTok{)} \OperatorTok{:} \KeywordTok{base}\OperatorTok{(}\NormalTok{DBContextDependencies}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\OperatorTok{\}}
|
||
|
||
\KeywordTok{protected} \KeywordTok{override} \DataTypeTok{void} \FunctionTok{OnModelCreating}\OperatorTok{(}\NormalTok{ModelBuilder builder}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\KeywordTok{base}\OperatorTok{.}\FunctionTok{OnModelCreating}\OperatorTok{(}\NormalTok{builder}\OperatorTok{);}
|
||
\NormalTok{ builder}\OperatorTok{.}\FunctionTok{Entity}\OperatorTok{\textless{}}\NormalTok{Models}\OperatorTok{.}\FunctionTok{PremiumArea}\OperatorTok{\textgreater{}().}\FunctionTok{ToTable}\OperatorTok{(}\NormalTok{ActiveDatabase}\OperatorTok{.}\FunctionTok{RewriteName}\OperatorTok{(}\StringTok{"SZUAbsolventenvereinPremiumArea"}\OperatorTok{));}
|
||
\NormalTok{ builder}\OperatorTok{.}\FunctionTok{Entity}\OperatorTok{\textless{}}\NormalTok{Models}\OperatorTok{.}\FunctionTok{EngineerApplication}\OperatorTok{\textgreater{}().}\FunctionTok{ToTable}\OperatorTok{(}\NormalTok{ActiveDatabase}\OperatorTok{.}\FunctionTok{RewriteName}\OperatorTok{(}\StringTok{"SZUAbsolventenvereinEngineerApplications"}\OperatorTok{));}
|
||
\NormalTok{ builder}\OperatorTok{.}\FunctionTok{Entity}\OperatorTok{\textless{}}\NormalTok{Models}\OperatorTok{.}\FunctionTok{UserPremium}\OperatorTok{\textgreater{}().}\FunctionTok{ToTable}\OperatorTok{(}\NormalTok{ActiveDatabase}\OperatorTok{.}\FunctionTok{RewriteName}\OperatorTok{(}\StringTok{"SZUAbsolventenvereinUserPremium"}\OperatorTok{));}
|
||
\NormalTok{ builder}\OperatorTok{.}\FunctionTok{Entity}\OperatorTok{\textless{}}\NormalTok{Models}\OperatorTok{.}\FunctionTok{PremiumEvent}\OperatorTok{\textgreater{}().}\FunctionTok{ToTable}\OperatorTok{(}\NormalTok{ActiveDatabase}\OperatorTok{.}\FunctionTok{RewriteName}\OperatorTok{(}\StringTok{"SZUAbsolventenvereinPremiumEvents"}\OperatorTok{));}
|
||
\OperatorTok{\}}
|
||
\OperatorTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Die Tabellennamen werden über \texttt{ActiveDatabase.RewriteName()}
|
||
datenbankunabhängig gehalten, sodass das Modul mit verschiedenen
|
||
Datenbanksystemen betrieben werden kann. Neben der Antragstabelle
|
||
speichert das Modul den Premium-Status der Benutzer in der Tabelle
|
||
\texttt{UserPremium} mit einem Ablaufdatum und einer Quellenangabe.
|
||
Ergänzend protokolliert die Tabelle \texttt{PremiumEvent} jede Änderung
|
||
am Premium-Status als Audit-Trail, wodurch die vollständige Historie
|
||
aller Premium-Vergaben nachvollziehbar bleibt.
|
||
|
||
Die Datenbankstruktur wird über Oqtane's Migrationssystem aufgebaut. Die
|
||
folgende Migration zeigt exemplarisch die Erstellung der drei
|
||
Kerntabellen:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\OperatorTok{[}\FunctionTok{DbContext}\OperatorTok{(}\KeywordTok{typeof}\OperatorTok{(}\NormalTok{PremiumAreaContext}\OperatorTok{))]}
|
||
\OperatorTok{[}\FunctionTok{Migration}\OperatorTok{(}\StringTok{"SZUAbsolventenverein.Module.PremiumArea.01.00.00.01"}\OperatorTok{)]}
|
||
\KeywordTok{public} \KeywordTok{class}\NormalTok{ AddPremiumTables }\OperatorTok{:}\NormalTok{ MultiDatabaseMigration}
|
||
\OperatorTok{\{}
|
||
\KeywordTok{public} \FunctionTok{AddPremiumTables}\OperatorTok{(}\NormalTok{IDatabase database}\OperatorTok{)} \OperatorTok{:} \KeywordTok{base}\OperatorTok{(}\NormalTok{database}\OperatorTok{)} \OperatorTok{\{} \OperatorTok{\}}
|
||
|
||
\KeywordTok{protected} \KeywordTok{override} \DataTypeTok{void} \FunctionTok{Up}\OperatorTok{(}\NormalTok{MigrationBuilder migrationBuilder}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\DataTypeTok{var}\NormalTok{ engAppBuilder }\OperatorTok{=} \KeywordTok{new} \FunctionTok{EngineerApplicationEntityBuilder}\OperatorTok{(}\NormalTok{migrationBuilder}\OperatorTok{,}\NormalTok{ ActiveDatabase}\OperatorTok{);}
|
||
\NormalTok{ engAppBuilder}\OperatorTok{.}\FunctionTok{Create}\OperatorTok{();}
|
||
|
||
\DataTypeTok{var}\NormalTok{ userPremBuilder }\OperatorTok{=} \KeywordTok{new} \FunctionTok{UserPremiumEntityBuilder}\OperatorTok{(}\NormalTok{migrationBuilder}\OperatorTok{,}\NormalTok{ ActiveDatabase}\OperatorTok{);}
|
||
\NormalTok{ userPremBuilder}\OperatorTok{.}\FunctionTok{Create}\OperatorTok{();}
|
||
|
||
\DataTypeTok{var}\NormalTok{ premEventBuilder }\OperatorTok{=} \KeywordTok{new} \FunctionTok{PremiumEventEntityBuilder}\OperatorTok{(}\NormalTok{migrationBuilder}\OperatorTok{,}\NormalTok{ ActiveDatabase}\OperatorTok{);}
|
||
\NormalTok{ premEventBuilder}\OperatorTok{.}\FunctionTok{Create}\OperatorTok{();}
|
||
\OperatorTok{\}}
|
||
|
||
\KeywordTok{protected} \KeywordTok{override} \DataTypeTok{void} \FunctionTok{Down}\OperatorTok{(}\NormalTok{MigrationBuilder migrationBuilder}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\DataTypeTok{var}\NormalTok{ engAppBuilder }\OperatorTok{=} \KeywordTok{new} \FunctionTok{EngineerApplicationEntityBuilder}\OperatorTok{(}\NormalTok{migrationBuilder}\OperatorTok{,}\NormalTok{ ActiveDatabase}\OperatorTok{);}
|
||
\NormalTok{ engAppBuilder}\OperatorTok{.}\FunctionTok{Drop}\OperatorTok{();}
|
||
|
||
\DataTypeTok{var}\NormalTok{ userPremBuilder }\OperatorTok{=} \KeywordTok{new} \FunctionTok{UserPremiumEntityBuilder}\OperatorTok{(}\NormalTok{migrationBuilder}\OperatorTok{,}\NormalTok{ ActiveDatabase}\OperatorTok{);}
|
||
\NormalTok{ us}
|
||
\NormalTok{ erPremBuilder}\OperatorTok{.}\FunctionTok{Drop}\OperatorTok{();}
|
||
|
||
\DataTypeTok{var}\NormalTok{ premEventBuilder }\OperatorTok{=} \KeywordTok{new} \FunctionTok{PremiumEventEntityBuilder}\OperatorTok{(}\NormalTok{migrationBuilder}\OperatorTok{,}\NormalTok{ ActiveDatabase}\OperatorTok{);}
|
||
\NormalTok{ premEventBuilder}\OperatorTok{.}\FunctionTok{Drop}\OperatorTok{();}
|
||
\OperatorTok{\}}
|
||
\OperatorTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Insgesamt definieren vier Migrationen die Datenbankstruktur: Die erste
|
||
erstellt die Basistabelle des Moduls, die zweite fügt die drei Tabellen
|
||
für Ingenieur-Anträge, Premium-Status und Premium-Events hinzu, die
|
||
dritte entfernt nicht mehr benötigte Spalten nach der Umstellung auf den
|
||
Oqtane FileManager, und die vierte ergänzt die Felder für Titel und
|
||
Kurzbeschreibung. Alle Migrationen werden bei der Modulinstallation
|
||
automatisch ausgeführt.
|
||
|
||
\paragraph{Zugriffsbeschränkung und
|
||
Benutzerrechte}\label{zugriffsbeschruxe4nkung-und-benutzerrechte}
|
||
|
||
Der Zugriff auf den Premium-Bereich wird durch ein mehrstufiges
|
||
Berechtigungssystem gesteuert, das sowohl auf Server- als auch auf
|
||
Client-Seite durchgesetzt wird. Die verfügbaren Berechtigungen werden in
|
||
der \texttt{ModuleInfo}-Klasse registriert:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\KeywordTok{public} \KeywordTok{class}\NormalTok{ ModuleInfo }\OperatorTok{:}\NormalTok{ IModule}
|
||
\OperatorTok{\{}
|
||
\KeywordTok{public}\NormalTok{ ModuleDefinition ModuleDefinition }\OperatorTok{=\textgreater{}} \KeywordTok{new}\NormalTok{ ModuleDefinition}
|
||
\OperatorTok{\{}
|
||
\NormalTok{ Name }\OperatorTok{=} \StringTok{"PremiumArea"}\OperatorTok{,}
|
||
\NormalTok{ Description }\OperatorTok{=} \StringTok{"This module adds a premium member system to Octane."}\OperatorTok{,}
|
||
\NormalTok{ Version }\OperatorTok{=} \StringTok{"1.0.3"}\OperatorTok{,}
|
||
\NormalTok{ ServerManagerType }\OperatorTok{=} \StringTok{"SZUAbsolventenverein.Module.PremiumArea.Manager.PremiumAreaManager, SZUAbsolventenverein.Module.PremiumArea.Server.Oqtane"}\OperatorTok{,}
|
||
\NormalTok{ ReleaseVersions }\OperatorTok{=} \StringTok{"1.0.0,1.0.1,1.0.2,1.0.3"}\OperatorTok{,}
|
||
\NormalTok{ Dependencies }\OperatorTok{=} \StringTok{"SZUAbsolventenverein.Module.PremiumArea.Shared.Oqtane"}\OperatorTok{,}
|
||
\NormalTok{ PermissionNames }\OperatorTok{=}\NormalTok{ $}\StringTok{"\{PermissionNames.View\},\{PermissionNames.Edit\},\{PermissionNames.Browse\}"}
|
||
\OperatorTok{\};}
|
||
\OperatorTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Die Eigenschaft \texttt{PermissionNames} legt fest, welche
|
||
Berechtigungen für das Modul verfügbar sind. Die View-Berechtigung
|
||
erlaubt grundlegende Funktionen wie das Einreichen eigener Anträge. Die
|
||
Edit-Berechtigung gewährt administrative Funktionen wie das Genehmigen
|
||
und Ablehnen von Anträgen. Über \texttt{ReleaseVersions} wird die
|
||
Migrationshistorie definiert, sodass Oqtane bei Updates die korrekten
|
||
Migrationsschritte ausführt.
|
||
|
||
Grundsätzlich wird zwischen drei Zugriffsebenen unterschieden:
|
||
Standardbenutzer können ausschließlich eigene Ingenieur-Anträge
|
||
einreichen und verwalten. Sie haben keinen Einblick in die Anträge
|
||
anderer Mitglieder und können weder die Mitgliedersuche noch die
|
||
Kontaktfunktion nutzen. Premium-Mitglieder erhalten Zugang zu allen
|
||
Funktionen des Premium-Bereichs. Administratoren besitzen
|
||
uneingeschränkten Zugriff und können sämtliche Anträge unabhängig vom
|
||
Status einsehen, genehmigen oder ablehnen.
|
||
|
||
Der Premium-Status kann auf zwei Wegen erlangt werden: durch die
|
||
Genehmigung eines Ingenieur-Antrags mit automatischer 12-monatiger
|
||
Mitgliedschaft oder durch manuelle Zuweisung der Oqtane-Rolle „Premium
|
||
Member'' durch einen Administrator. Die serverseitige Methode
|
||
\texttt{IsUserPremium} berücksichtigt beide Wege:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\KeywordTok{private} \DataTypeTok{bool} \FunctionTok{IsUserPremium}\OperatorTok{(}\NormalTok{System}\OperatorTok{.}\FunctionTok{Security}\OperatorTok{.}\FunctionTok{Claims}\OperatorTok{.}\FunctionTok{ClaimsPrincipal}\NormalTok{ user}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\KeywordTok{if} \OperatorTok{(!}\NormalTok{user}\OperatorTok{.}\FunctionTok{Identity}\OperatorTok{.}\FunctionTok{IsAuthenticated}\OperatorTok{)}
|
||
\KeywordTok{return} \KeywordTok{false}\OperatorTok{;}
|
||
|
||
\KeywordTok{if} \OperatorTok{(}\NormalTok{user}\OperatorTok{.}\FunctionTok{IsInRole}\OperatorTok{(}\StringTok{"Premium Member"}\OperatorTok{))}
|
||
\KeywordTok{return} \KeywordTok{true}\OperatorTok{;}
|
||
|
||
\DataTypeTok{int}\NormalTok{ userId }\OperatorTok{=} \OperatorTok{{-}}\DecValTok{1}\OperatorTok{;}
|
||
\DataTypeTok{var}\NormalTok{ claim }\OperatorTok{=}\NormalTok{ user}\OperatorTok{.}\FunctionTok{Claims}\OperatorTok{.}\FunctionTok{FirstOrDefault}\OperatorTok{(}\NormalTok{item }\OperatorTok{=\textgreater{}}
|
||
\NormalTok{ item}\OperatorTok{.}\FunctionTok{Type} \OperatorTok{==}\NormalTok{ System}\OperatorTok{.}\FunctionTok{Security}\OperatorTok{.}\FunctionTok{Claims}\OperatorTok{.}\FunctionTok{ClaimTypes}\OperatorTok{.}\FunctionTok{NameIdentifier}\OperatorTok{);}
|
||
\KeywordTok{if} \OperatorTok{(}\NormalTok{claim }\OperatorTok{!=} \KeywordTok{null}\OperatorTok{)}
|
||
\DataTypeTok{int}\OperatorTok{.}\FunctionTok{TryParse}\OperatorTok{(}\NormalTok{claim}\OperatorTok{.}\FunctionTok{Value}\OperatorTok{,} \KeywordTok{out}\NormalTok{ userId}\OperatorTok{);}
|
||
|
||
\KeywordTok{if} \OperatorTok{(}\NormalTok{userId }\OperatorTok{!=} \OperatorTok{{-}}\DecValTok{1}\OperatorTok{)}
|
||
\KeywordTok{return}\NormalTok{ \_premiumService}\OperatorTok{.}\FunctionTok{IsPremium}\OperatorTok{(}\NormalTok{userId}\OperatorTok{);}
|
||
|
||
\KeywordTok{return} \KeywordTok{false}\OperatorTok{;}
|
||
\OperatorTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.8\linewidth,height=0.7\textheight]{flowchart-premium-access.pdf}
|
||
\caption{Zugriffsprüfung für Premium-Inhalte}
|
||
\end{figure}
|
||
|
||
Zuerst wird die Oqtane-Rollenzugehörigkeit geprüft, anschließend der
|
||
datenbankbasierte Premium-Status mit Ablaufdatum. Das kumulative System
|
||
sorgt dafür, dass bei mehrfacher Vergabe die Laufzeiten addiert und
|
||
nicht überschrieben werden --- ein Mitglied, das während einer laufenden
|
||
Premium-Mitgliedschaft einen weiteren Antrag genehmigt bekommt, erhält
|
||
die zusätzlichen 12 Monate auf das bestehende Ablaufdatum aufgeschlagen.
|
||
|
||
Die Zugriffsbeschränkung wird konsequent auf beiden Seiten durchgesetzt:
|
||
Clientseitig entscheidet die Blazor-Komponente anhand der Benutzerrolle,
|
||
welche UI-Elemente angezeigt werden. Serverseitig prüft jeder
|
||
Service-Aufruf die Berechtigung des anfragenden Benutzers über das
|
||
\texttt{{[}Authorize{]}}-Attribut mit Policies wie
|
||
\texttt{PolicyNames.ViewModule} und \texttt{PolicyNames.EditModule},
|
||
bevor Daten zurückgegeben oder Änderungen vorgenommen werden. Dadurch
|
||
wird sichergestellt, dass selbst bei einer Manipulation der
|
||
Client-Anfrage keine unberechtigten Zugriffe möglich sind.
|
||
|
||
\paragraph{Mehrwert für registrierte
|
||
Mitglieder}\label{mehrwert-fuxfcr-registrierte-mitglieder}
|
||
|
||
Der Premium-Bereich schafft einen konkreten Mehrwert für registrierte
|
||
Mitglieder auf mehreren Ebenen. Auf fachlicher Ebene entsteht durch die
|
||
gesammelten Ingenieur-Anträge eine wachsende Wissensbasis, die allen
|
||
Premium-Mitgliedern zugänglich ist. Absolventen können von den Arbeiten
|
||
anderer Mitglieder lernen, sich inspirieren lassen und fachliche Ansätze
|
||
vergleichen. Durch die Möglichkeit, Titel und Kurzbeschreibungen zu
|
||
hinterlegen, können Mitglieder gezielt nach relevanten Themen suchen,
|
||
ohne jedes PDF-Dokument einzeln öffnen zu müssen.
|
||
|
||
Auf sozialer Ebene fördert der Premium-Bereich die Vernetzung innerhalb
|
||
der Absolventengemeinschaft. Die Mitgliedersuche mit integrierter
|
||
Kontaktfunktion ermöglicht es, gezielt nach ehemaligen Kommilitonen oder
|
||
Fachkollegen zu suchen und direkt Kontakt aufzunehmen. Der duale
|
||
Benachrichtigungsmechanismus --- bestehend aus In-App-Nachricht und
|
||
E-Mail --- stellt sicher, dass Kontaktanfragen zuverlässig zugestellt
|
||
werden und kein Mitglied eine Nachricht verpasst.
|
||
|
||
Auf motivationaler Ebene bietet das zeitlich begrenzte Premium-System
|
||
einen Anreiz zur aktiven Teilnahme. Die Aussicht auf exklusive
|
||
Funktionen motiviert Mitglieder, eigene Ingenieur-Anträge einzureichen
|
||
und damit sowohl den eigenen Premium-Status zu erlangen als auch zur
|
||
Wissensbasis der Gemeinschaft beizutragen. Die Meldefunktion gibt
|
||
Mitgliedern zusätzlich die Möglichkeit, aktiv zur Qualitätssicherung
|
||
beizutragen und unangemessene Inhalte zu kennzeichnen.
|
||
|
||
Der Datenschutz wird dabei konsequent gewahrt. Die Mitgliedersuche gibt
|
||
nur ausgewählte, nicht-sensible Informationen wie Anzeigenamen und
|
||
Benutzernamen zurück. E-Mail-Adressen und andere persönliche Daten
|
||
werden serverseitig herausgefiltert und sind für andere Mitglieder nicht
|
||
einsehbar. Die Kontaktaufnahme erfolgt ausschließlich über das
|
||
plattformeigene Benachrichtigungssystem, sodass kein Mitglied seine
|
||
persönlichen Kontaktdaten preisgeben muss.
|
||
|
||
\subsection{Learnings}\label{learnings-1}
|
||
|
||
\subsubsection{Technische und fachliche
|
||
Erkenntnisse}\label{technische-und-fachliche-erkenntnisse}
|
||
|
||
Während der Umsetzung meiner Diplomarbeit konnte ich umfangreiche
|
||
technische Erfahrungen in der Entwicklung moderner Webanwendungen
|
||
sammeln. Ein zentraler Bestandteil der Arbeit war die Implementierung
|
||
einer Alumni-Plattform, die ehemaligen Studierenden eine Möglichkeit
|
||
bietet, sich zu vernetzen, Profile zu verwalten und sich für
|
||
Veranstaltungen anzumelden.
|
||
|
||
Ein wesentlicher Lernaspekt war die praktische Anwendung des
|
||
Webframeworks ASP.NET auf Basis der Plattform .NET 8. Dabei konnte ich
|
||
ein tieferes Verständnis für die Architektur moderner Webanwendungen
|
||
entwickeln. Besonders wichtig war das Zusammenspiel zwischen
|
||
Backend-Logik, Datenbankzugriff und Benutzeroberfläche. Durch die
|
||
Entwicklung verschiedener Funktionen, wie beispielsweise
|
||
Eventverwaltung, Benutzerprofile und Premiumbereiche, wurde deutlich,
|
||
wie wichtig eine klare Strukturierung der Anwendung ist.
|
||
|
||
Ein weiterer technischer Schwerpunkt war die Arbeit mit der relationalen
|
||
Datenbank PostgreSQL. Hier lernte ich, Datenmodelle zu entwerfen,
|
||
Tabellenbeziehungen zu definieren und effiziente Datenbankabfragen zu
|
||
erstellen. Da die Plattform personenbezogene Daten verwaltet, musste
|
||
auch auf Aspekte wie Datensicherheit und Datenintegrität geachtet
|
||
werden. In diesem Zusammenhang wurde zusätzlich ein Backup- und
|
||
Restore-System implementiert, das eine Wiederherstellung der Datenbank
|
||
im Falle eines Fehlers ermöglicht. Dadurch konnte ich praktische
|
||
Erfahrungen im Bereich Datensicherung und Systemstabilität sammeln.
|
||
|
||
Ein weiterer wichtiger Bestandteil der Arbeit war die Integration eines
|
||
externen Authentifizierungssystems über LinkedIn. Dabei wurde das
|
||
Autorisierungsprotokoll OAuth 2.0 eingesetzt. Durch diese
|
||
Implementierung konnte ich ein besseres Verständnis für moderne
|
||
Authentifizierungsverfahren entwickeln. Besonders interessant war dabei
|
||
der Ablauf des OAuth-Authentifizierungsprozesses, bei dem Benutzer über
|
||
einen externen Anbieter authentifiziert werden, ohne dass ihre
|
||
Zugangsdaten direkt an die eigene Anwendung übermittelt werden.
|
||
|
||
Zusätzlich wurden Funktionen im Bereich Datenschutz umgesetzt, die den
|
||
Anforderungen der DSGVO entsprechen. Dazu zählen unter anderem
|
||
Möglichkeiten zur Verwaltung personenbezogener Daten sowie
|
||
automatisierte Löschmechanismen. Diese Aspekte haben mir gezeigt, wie
|
||
wichtig Datenschutz und rechtliche Anforderungen bei der Entwicklung
|
||
moderner Webanwendungen sind.
|
||
|
||
Insgesamt konnte ich durch die praktische Umsetzung der Plattform ein
|
||
deutlich tieferes Verständnis für Webtechnologien, Systemarchitekturen
|
||
und Backend-Entwicklung gewinnen.
|
||
|
||
\subsubsection{Agile Projektarbeit und Teamarbeit
|
||
(Zeitmanagement)}\label{agile-projektarbeit-und-teamarbeit-zeitmanagement}
|
||
|
||
Neben den technischen Aspekten konnte ich auch wichtige Erfahrungen im
|
||
Bereich der agilen Projektarbeit sammeln. Für die Organisation des
|
||
Projekts wurde das agile Framework Scrum eingesetzt.
|
||
|
||
Die Arbeit wurde in Sprints von jeweils zwei Wochen unterteilt.
|
||
Innerhalb eines Sprints wurden konkrete Aufgaben definiert, die bis zum
|
||
Ende des Zeitraums umgesetzt werden sollten. Diese Struktur ermöglichte
|
||
eine klare Planung der Arbeitsschritte und half dabei, größere
|
||
Entwicklungsaufgaben in kleinere, überschaubare Teilaufgaben zu
|
||
unterteilen.
|
||
|
||
Ein wichtiger Bestandteil der Scrum-Arbeitsweise war die regelmäßige
|
||
Reflexion der Arbeit. Nach jedem Sprint konnte überprüft werden, welche
|
||
Funktionen erfolgreich umgesetzt wurden und welche Aufgaben
|
||
möglicherweise angepasst werden mussten. Dadurch entstand ein iterativer
|
||
Entwicklungsprozess, bei dem das System kontinuierlich verbessert wurde.
|
||
|
||
Auch das Zeitmanagement spielte eine zentrale Rolle. Da die Entwicklung
|
||
der Plattform mehrere unterschiedliche Komponenten umfasste --
|
||
beispielsweise Datenbankstruktur, Benutzerverwaltung,
|
||
Authentifizierungssystem und Eventverwaltung -- war eine gute Planung
|
||
notwendig. Durch die Aufteilung in Sprints konnte ich meine Arbeitszeit
|
||
besser strukturieren und Prioritäten setzen.
|
||
|
||
Darüber hinaus zeigte sich, dass agile Methoden besonders gut für
|
||
Softwareprojekte geeignet sind, da sie flexible Anpassungen während der
|
||
Entwicklung ermöglichen. Neue Anforderungen oder Verbesserungen konnten
|
||
relativ einfach in zukünftige Sprints integriert werden.
|
||
|
||
Diese Erfahrungen haben mir ein besseres Verständnis für moderne
|
||
Softwareentwicklungsprozesse vermittelt und gezeigt, wie wichtig
|
||
strukturierte Planung und kontinuierliche Verbesserung in technischen
|
||
Projekten sind.
|
||
|
||
\subsubsection{Persönliche
|
||
Weiterentwicklung}\label{persuxf6nliche-weiterentwicklung}
|
||
|
||
Neben den technischen und organisatorischen Erkenntnissen stellte die
|
||
Diplomarbeit auch eine wichtige persönliche Weiterentwicklung dar. Die
|
||
eigenständige Planung und Umsetzung eines komplexen Softwareprojekts
|
||
erforderte ein hohes Maß an Selbstorganisation und Durchhaltevermögen.
|
||
|
||
Während der Entwicklung der Alumni-Plattform musste ich regelmäßig neue
|
||
Technologien und Konzepte erlernen. Dazu gehörten unter anderem
|
||
Webframeworks, Datenbanksysteme, Authentifizierungsprotokolle sowie
|
||
Aspekte der IT-Sicherheit und des Datenschutzes. Der Umgang mit diesen
|
||
Technologien hat meine Fähigkeiten im Bereich der Softwareentwicklung
|
||
deutlich erweitert.
|
||
|
||
Darüber hinaus lernte ich, technische Probleme systematisch zu
|
||
analysieren und eigenständig Lösungen zu entwickeln. Besonders bei der
|
||
Integration verschiedener Systeme -- beispielsweise der
|
||
LinkedIn-Authentifizierung oder der Datenbankfunktionen -- traten immer
|
||
wieder Herausforderungen auf, die eine intensive Recherche und
|
||
Fehlersuche erforderten.
|
||
|
||
Ein weiterer wichtiger Lernaspekt war die Verbesserung meiner
|
||
Fähigkeiten im Bereich der Dokumentation. Die Erstellung eines
|
||
Diplomarbeitsbuchs erfordert eine strukturierte und verständliche
|
||
Beschreibung technischer Inhalte. Dadurch konnte ich lernen, komplexe
|
||
technische Zusammenhänge klar und nachvollziehbar darzustellen.
|
||
|
||
Zusammenfassend hat mir die Diplomarbeit nicht nur tiefere technische
|
||
Kenntnisse vermittelt, sondern auch meine Fähigkeiten im Bereich
|
||
Problemlösung, Selbstorganisation und Projektplanung gestärkt. Diese
|
||
Kompetenzen stellen eine wichtige Grundlage für zukünftige berufliche
|
||
Tätigkeiten im Bereich der Softwareentwicklung dar.
|
||
|
||
\subsection{Fazit und Ausblick}\label{fazit-und-ausblick-1}
|
||
|
||
\subsubsection{Zusammenfassung der
|
||
Arbeit}\label{zusammenfassung-der-arbeit}
|
||
|
||
Ziel dieser Diplomarbeit war die Konzeption und Entwicklung einer
|
||
webbasierten Alumni-Plattform für den Absolventenverein. Die Plattform
|
||
soll ehemaligen Studierenden ermöglichen, miteinander in Kontakt zu
|
||
bleiben, Informationen auszutauschen und an Veranstaltungen des Vereins
|
||
teilzunehmen. Dadurch wird die Kommunikation zwischen Absolventinnen und
|
||
Absolventen sowie der Bildungseinrichtung langfristig gestärkt.
|
||
|
||
Im Rahmen der Arbeit wurde eine moderne Webanwendung entwickelt, die auf
|
||
dem Framework ASP.NET und der Plattform .NET 8 basiert. Die Speicherung
|
||
der Daten erfolgt in der relationalen Datenbank PostgreSQL, welche eine
|
||
strukturierte Verwaltung der Benutzerdaten, Eventinformationen und
|
||
Systemdaten ermöglicht.
|
||
|
||
Ein wichtiger Bestandteil der Plattform ist die Benutzerverwaltung. Um
|
||
den Registrierungs- und Loginprozess zu vereinfachen, wurde eine
|
||
Authentifizierung über LinkedIn implementiert. Dabei wird das
|
||
Autorisierungsprotokoll OAuth 2.0 verwendet, wodurch sich Benutzer mit
|
||
ihrem bestehenden LinkedIn-Konto anmelden können. Dies erhöht die
|
||
Benutzerfreundlichkeit und reduziert gleichzeitig den Verwaltungsaufwand
|
||
für eigene Login-Daten.
|
||
|
||
Neben der Benutzerverwaltung wurden auch weitere Funktionen umgesetzt.
|
||
Dazu zählen unter anderem die Verwaltung von Veranstaltungen, für die
|
||
sich Alumni anmelden können, sowie ein Premiumbereich mit erweiterten
|
||
Funktionen für Mitglieder. Zusätzlich wurden Maßnahmen im Bereich
|
||
Datenschutz umgesetzt, um den Anforderungen der DSGVO gerecht zu werden.
|
||
Dazu gehört beispielsweise die Möglichkeit zur Verwaltung und Löschung
|
||
personenbezogener Daten sowie ein System zur Sicherung der Datenbank
|
||
mittels Backup- und Restore-Funktionen.
|
||
|
||
Die Entwicklung der Plattform erfolgte nach agilen Prinzipien mithilfe
|
||
des Scrum-Frameworks. Die Arbeit wurde in mehrere zweiwöchige Sprints
|
||
unterteilt, wodurch eine strukturierte und iterative Entwicklung der
|
||
einzelnen Funktionen möglich war.
|
||
|
||
Zusammenfassend konnte mit der Diplomarbeit eine funktionale und
|
||
erweiterbare Plattform entwickelt werden, die eine moderne Grundlage für
|
||
die digitale Vernetzung von Alumni darstellt.
|
||
|
||
\subsubsection{Mögliche Erweiterungen der
|
||
Webseite}\label{muxf6gliche-erweiterungen-der-webseite}
|
||
|
||
Obwohl bereits viele grundlegende Funktionen implementiert wurden,
|
||
bietet die Plattform weiteres Potenzial für zukünftige Erweiterungen und
|
||
Verbesserungen.
|
||
|
||
Eine mögliche Erweiterung wäre beispielsweise die Integration eines
|
||
internen Nachrichtensystems. Dadurch könnten Alumni direkt über die
|
||
Plattform miteinander kommunizieren und Kontakte einfacher pflegen.
|
||
Ebenso wäre die Implementierung eines Forums oder einer
|
||
Diskussionsplattform denkbar, in der Mitglieder Erfahrungen austauschen
|
||
oder berufliche Themen diskutieren können.
|
||
|
||
Auch im Bereich der Eventverwaltung könnten zusätzliche Funktionen
|
||
integriert werden. Beispielsweise wäre es möglich, automatische
|
||
Erinnerungen für Veranstaltungen zu versenden oder Teilnehmerlisten
|
||
übersichtlich darzustellen. Darüber hinaus könnten Eventberichte oder
|
||
Fotogalerien vergangener Veranstaltungen integriert werden.
|
||
|
||
Ein weiterer möglicher Ausbau betrifft den Premiumbereich der Plattform.
|
||
Hier könnten zusätzliche Inhalte oder exklusive Funktionen für
|
||
Mitglieder bereitgestellt werden, etwa spezielle Networking-Angebote
|
||
oder Zugriff auf besondere Veranstaltungen.
|
||
|
||
Auch technische Erweiterungen sind denkbar. Dazu zählen beispielsweise:
|
||
|
||
eine mobile Optimierung der Plattform
|
||
|
||
eine eigene mobile App
|
||
|
||
Integration weiterer Social-Media-Plattformen
|
||
|
||
erweiterte Such- und Filterfunktionen für Alumni-Profile
|
||
|
||
Durch diese Erweiterungen könnte die Plattform langfristig noch
|
||
attraktiver und vielseitiger gestaltet werden.
|
||
|
||
\subsubsection{Zukunftspotenzial für den
|
||
Absolventenverein}\label{zukunftspotenzial-fuxfcr-den-absolventenverein}
|
||
|
||
Die entwickelte Alumni-Plattform bietet dem Absolventenverein eine
|
||
moderne digitale Infrastruktur zur Verwaltung und Vernetzung seiner
|
||
Mitglieder. Durch die zentrale Plattform können Informationen,
|
||
Veranstaltungen und Kontakte effizient organisiert werden.
|
||
|
||
Ein wesentlicher Vorteil besteht darin, dass der Verein seine Mitglieder
|
||
dauerhaft an die Institution binden kann. Ehemalige Studierende haben
|
||
die Möglichkeit, weiterhin mit ihrer Ausbildungsstätte und anderen
|
||
Absolventinnen und Absolventen in Verbindung zu bleiben. Dies stärkt das
|
||
Netzwerk des Vereins und kann langfristig auch neue Kooperationen oder
|
||
berufliche Kontakte ermöglichen.
|
||
|
||
Darüber hinaus kann die Plattform auch zur Organisation von
|
||
Veranstaltungen genutzt werden. Alumni können sich direkt online für
|
||
Events anmelden und erhalten Informationen zu kommenden Aktivitäten.
|
||
Dadurch wird die Planung von Veranstaltungen für den Verein deutlich
|
||
erleichtert.
|
||
|
||
Langfristig kann die Plattform zu einem zentralen digitalen Treffpunkt
|
||
für Absolventinnen und Absolventen werden. Besonders im beruflichen
|
||
Umfeld kann ein starkes Alumni-Netzwerk einen großen Mehrwert bieten,
|
||
beispielsweise durch den Austausch von Erfahrungen oder beruflichen
|
||
Möglichkeiten.
|
||
|
||
Insgesamt besitzt die entwickelte Plattform ein großes
|
||
Zukunftspotenzial. Durch kontinuierliche Erweiterungen und die aktive
|
||
Nutzung durch die Mitglieder kann sie zu einem wichtigen Instrument für
|
||
die Vernetzung und Weiterentwicklung des Absolventenvereins werden.
|
||
|
||
\cleardoublepage
|
||
|
||
\section{Konstantin Hintermayer}\label{konstantin-hintermayer-1}
|
||
|
||
\subsection{Einleitung}\label{einleitung}
|
||
|
||
\subsubsection{Motivation}\label{motivation-1}
|
||
|
||
Gegenstand der Diplomarbeit ist die Entwicklung modularer Webanwendungen
|
||
mit Blazor und Oqtane. Aufbauend auf fundierten Kenntnissen in der
|
||
Fullstack-Entwicklung (React, Node.js, Golang), welche privat bei
|
||
diversen Projekten gesammelt worden sind, fokussiert sich die Arbeit auf
|
||
die Architekturvorteile des .NET-Stacks. Besonders im Fokus stehen die
|
||
Konsistenz durch statische Typisierung sowie das Zusammenspiel modularer
|
||
Komponenten in verteilten Systemen.
|
||
|
||
Mein Untersuchungsanliegen: Inwieweit optimiert die Integration von
|
||
Blazor und dem Oqtane-Framework die Konsistenz und Wartbarkeit modularer
|
||
Web-Architekturen im Vergleich zu den für mich gewohnten
|
||
Technologie-Stacks (React/Node.js)?
|
||
|
||
\subsubsection{Auftrag und persönliche
|
||
Aufgabenstellungen}\label{auftrag-und-persuxf6nliche-aufgabenstellungen}
|
||
|
||
Mein Aufgabenbereich in diesem Projekt war vielseitig und umfasste
|
||
sowohl leitende als auch tiefgreifende technische Aspekte. Die Rollen
|
||
lassen sich in drei Kerngebiete unterteilen:
|
||
|
||
\paragraph{Projektleitung und Organisation (Product
|
||
Owner)}\label{projektleitung-und-organisation-product-owner}
|
||
|
||
~
|
||
|
||
Als Product Owner war ich für die Definition der Produktvision und die
|
||
Priorisierung des Backlogs verantwortlich. Dies beinhaltete: -
|
||
\textbf{Anforderungsmanagement}: Erhebung und Strukturierung der
|
||
Anforderungen in Zusammenarbeit mit den Betreuern und dem Team. -
|
||
\textbf{Sprint-Planung}: Organisation der 14-tägigen Sprints in
|
||
YouTrack, um einen kontinuierlichen Entwicklungsfluss sicherzustellen. -
|
||
\textbf{Qualitätssicherung}: Definition der \emph{Definition of Done}
|
||
(DoD) und Durchführung von Code-Reviews zur Einhaltung von
|
||
Architekturstandards.
|
||
|
||
\paragraph{Infrastruktur und
|
||
Systemarchitektur}\label{infrastruktur-und-systemarchitektur}
|
||
|
||
~
|
||
|
||
Ein wesentlicher Teil meiner Arbeit lag in der Bereitstellung der
|
||
technischen Basis für das gesamte Team: - \textbf{Deployment-Strategie}:
|
||
Konzeption und Umsetzung der Server-Infrastruktur auf Basis von Debian
|
||
Linux und NginX als Reverse-Proxy. - \textbf{Datenbankdesign}: Entwurf
|
||
des relationalen Datenmodells in PostgreSQL, inklusive der Absicherung
|
||
durch SSL/TLS. - \textbf{CI/CD-Pipeline}: Automatisierung der Build- und
|
||
Deployment-Prozesse mittels Gitea Actions für eine effiziente
|
||
Integration der Teambeiträge.
|
||
|
||
\paragraph{Modulentwicklung}\label{modulentwicklung}
|
||
|
||
~
|
||
|
||
Zusätzlich zur Infrastruktur habe ich drei zentrale Module für den
|
||
Alumnihub entworfen und implementiert:
|
||
|
||
\begin{enumerate}
|
||
\def\labelenumi{\arabic{enumi}.}
|
||
\tightlist
|
||
\item
|
||
\textbf{Anmeldetool (EventRegistration)}: Ein Modul zum verwalten von
|
||
Anmeldungen für Veranstaltungen. Es ermöglicht die einfache Erstellung
|
||
von Einladungen zu Veranstaltungen und die Verwaltung von Anmeldungen.
|
||
\item
|
||
\textbf{Reporting System}: Ein generisches System zur Meldung von
|
||
Inhalten, das nach dem \emph{Open-Closed-Prinzip} entworfen wurde, um
|
||
eine einfache Erweiterbarkeit für alle anderen Module zu bieten.
|
||
\item
|
||
\textbf{Schwarzes Brett (BlackBoard)}: Ein Community-Modul für den
|
||
Austausch von Informationen, inklusive eines automatisierten
|
||
E-Mail-Digest-Systems zur Nutzerbenachrichtigung.
|
||
\end{enumerate}
|
||
|
||
\subsection{Anforderungen an das entwickelte Modul bzw. die
|
||
Funktionalität}\label{anforderungen-an-das-entwickelte-modul-bzw.-die-funktionalituxe4t-1}
|
||
|
||
\subsubsection{Modulanforderungen / funktionale
|
||
Anforderungen}\label{modulanforderungen-funktionale-anforderungen}
|
||
|
||
Die funktionalen Anforderungen beschreiben die spezifischen Dienste und
|
||
Funktionen, die das System für die Benutzer bereitstellen muss. Im
|
||
Rahmen der individuellen Aufgabenstellung wurden Anforderungen für fünf
|
||
Teilbereiche definiert:
|
||
|
||
\paragraph{Anmeldetool
|
||
(EventRegistration)}\label{anmeldetool-eventregistration}
|
||
|
||
~
|
||
|
||
Das Ziel des Anmeldetools ist die effiziente Organisation von
|
||
Vereinsveranstaltungen.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{Veranstaltungsmanagement}: Administratoren müssen in der Lage
|
||
sein, neue Veranstaltungen anzulegen. Dabei müssen Name, Beschreibung,
|
||
Datum, Zeit und Ort festlegbar sein.
|
||
\item
|
||
\textbf{Anmeldeprozess}: Registrierte Benutzer müssen sich für eine
|
||
Veranstaltung an- oder abmelden können.
|
||
\item
|
||
\textbf{Teilnehmerliste}: Für jede Veranstaltung muss eine Übersicht
|
||
der Rückmeldungen (Anmeldungen/Absagen) für Administratoren einsehbar
|
||
sein.
|
||
\item
|
||
\textbf{Statistische Auswertung}: Die Rückmeldungen sollen grafisch
|
||
(z. B. als Tortendiagramm) aufbereitet werden, um die Planung zu
|
||
erleichtern.
|
||
\end{itemize}
|
||
|
||
\paragraph{Globales Reporting System}\label{globales-reporting-system}
|
||
|
||
~
|
||
|
||
Das Reporting System dient der Qualitätssicherung von Benutzerinhalten
|
||
über alle Module hinweg.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{Inhalte melden}: Benutzer müssen die Möglichkeit haben,
|
||
unangemessene Einträge (z. B. am Schwarzen Brett) zu melden. Dabei
|
||
muss ein Grund für die Meldung angegeben werden können.
|
||
\item
|
||
\textbf{Generische Schnittstelle}: Das System muss so entworfen sein,
|
||
dass beliebige andere Module (z. B. Hall of Fame) die Meldefunktion
|
||
ohne Änderungen am Kern des Reporting-Systems einbinden können.
|
||
\item
|
||
\textbf{Administrations-Dashboard}: Gemeldete Inhalte müssen in einer
|
||
zentralen Übersicht für Administratoren aufgelistet werden.
|
||
\item
|
||
\textbf{Moderationsaktionen}: Administratoren müssen gemeldete Inhalte
|
||
löschen, die Meldung ignorieren oder den Ersteller verwarnen/sperren
|
||
können.
|
||
\end{itemize}
|
||
|
||
\paragraph{Schwarzes Brett
|
||
(BlackBoard)}\label{schwarzes-brett-blackboard}
|
||
|
||
~
|
||
|
||
Das Schwarze Brett fungiert als digitale Kommunikationsplattform für den
|
||
Verein.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{Beiträge erstellen}: Benutzer müssen Textbeiträge erstellen
|
||
können. Die Formatierung der Texte soll über einen Rich-Text-Editor
|
||
möglich sein.
|
||
\item
|
||
\textbf{Bilder-Upload}: Zu jedem Beitrag soll optional ein Bild
|
||
hochgeladen werden können, welches automatisch für die Vorschau
|
||
skaliert wird.
|
||
\item
|
||
\textbf{Benachrichtigungs-System}: Das System soll regelmäßig
|
||
(täglich/wöchentlich) eine Zusammenfassung neuer Beiträge per E-Mail
|
||
an alle interessierten Mitglieder versenden.
|
||
\end{itemize}
|
||
|
||
\paragraph{Mass Mailing (Admin)}\label{mass-mailing-admin}
|
||
|
||
~
|
||
|
||
Dieses Modul ermöglicht die direkte Kommunikation des Vorstandes mit
|
||
allen Mitgliedern.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{Rundmails verfassen}: Administratoren müssen E-Mails mit
|
||
Betreff und Inhalt an alle registrierten Benutzer verfassen können.
|
||
\item
|
||
\textbf{Personalisierung}: Die E-Mails sollen automatisch mit dem
|
||
Namen des Empfängers personalisiert werden können.
|
||
\item
|
||
\textbf{Verspätetes Senden}: Aufgrund von Versandlimits des Providers
|
||
(Brevo) müssen die E-Mails in eine Warteschlange eingereiht und
|
||
zeitversetzt in Batches versendet werden.
|
||
\end{itemize}
|
||
|
||
\paragraph{Token Lifetime Management
|
||
(Admin)}\label{token-lifetime-management-admin}
|
||
|
||
~
|
||
|
||
Dies dient der Konfiguration sicherheitsrelevanter Parameter.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{Gültigkeitsdauer}: Administratoren müssen die Gültigkeitsdauer
|
||
für temporäre Links (z. B. Passwort-Reset, E-Mail-Bestätigung) über
|
||
eine grafische Oberfläche anpassen können.
|
||
\item
|
||
\textbf{Einstellungs-Persistenz}: Die geänderten Werte müssen
|
||
dauerhaft gespeichert werden und sofort für neue Token-Generierungen
|
||
wirksam sein.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Use Cases}\label{use-cases}
|
||
|
||
Um die Interaktion der Benutzer mit den Modulen zu verdeutlichen, wurden
|
||
folgende Use Cases definiert:
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.0660}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.2170}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.1698}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.5472}}@{}}
|
||
\caption{Wesentliche Use Cases der entwickelten Module}\tabularnewline
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
ID
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Name
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Akteur
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
ID
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Name
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Akteur
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Beschreibung
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
UC-01 & Veranstaltung erstellen & Administrator & Ein Administrator legt
|
||
ein neues Absolvententreffen mit Ort und Datum an. \\
|
||
UC-02 & Zu Event anmelden & Mitglied & Ein Absolvent bestätigt seine
|
||
Teilnahme an einem Event über die Weboberfläche. \\
|
||
UC-03 & Inhalt melden & Mitglied & Ein Benutzer meldet einen
|
||
beleidigenden Post am Schwarzen Brett über den ``Melden''-Button. \\
|
||
UC-04 & Meldung bearbeiten & Moderator & Ein Vorstandsmitglied sichtet
|
||
eine Meldung und löscht den entsprechenden Beitrag. \\
|
||
UC-05 & Rundmail versenden & Administrator & Der Vorstand erstellt eine
|
||
Einladung zur Generalversammlung für alle 500 Mitglieder. \\
|
||
\end{longtable}
|
||
|
||
Es ist zu beachten, dass es sich hierbei um eine Auswahl handelt und
|
||
nicht alle Use Cases der Module abgebildet werden.
|
||
|
||
\subsection{Technisches Umfeld}\label{technisches-umfeld}
|
||
|
||
Mein Aufgabenbereich umfasst einerseits die Entwicklung eigener Module,
|
||
sowie das Bereitstellen des Services.
|
||
|
||
\subsubsection{Auswahlverfahren}\label{auswahlverfahren}
|
||
|
||
\paragraph{Entscheidungsfindung CMS}\label{entscheidungsfindung-cms}
|
||
|
||
~
|
||
|
||
Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir
|
||
im Unterricht fast ausschließlich mit C\# entwickelt haben und nicht in
|
||
eine komplett unbekannte Entwicklungsumgebung abdriften wollten, haben
|
||
wir uns für die Webentwicklung mit ASP.NET Core 9 (Upgrade im Lauf der
|
||
Diplomarbeit auf .NET Core 10) und dem CMS Oqtane entschieden. Auch hier
|
||
gab es einige Kandidaten:
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
Piranha CMS \textgreater{} Piranha erscheint auf den ersten Blick
|
||
nicht so flexibel wie Oqtane, es basiert auf .NET 8.0 und wird nicht
|
||
so aktiv gewartet.
|
||
\item
|
||
Umbraco \textgreater{} Bei Umbraco muss viel in der Admin Oberfläche
|
||
von dem CMS gearbeitet werden, im Großen und Ganzen wirkt dieses CMS
|
||
nicht so flexibel. Die Dokumentation wirkt auf den ersten Blick sehr
|
||
gut!
|
||
\item
|
||
DNN / Dot Net Nuke \textgreater{} Dieses CMS ist der Platzhirsch. Es
|
||
wird von der DNN Foundation gewartet, arbeitet mit dem Dotnet
|
||
Framework, welches nicht unter Linux läuft. Und ein Windows Server ist
|
||
im Betrieb teurer und in der Absicherung aufwändiger.
|
||
\item
|
||
Oqtane \textgreater{} Oqtane wirkt auf sehr modular und flexibel, auch
|
||
innerhalb von Modulen kann man auf alle Funktionen des ASP.NET Core
|
||
Frameworks verwenden. Die Dokumentation wirkt nicht besonders gut,
|
||
aber ausreichend. Die enthaltenen Fehlinformationen und mangelnden
|
||
Anleitungen für den Betrieb mit Linux sind erst im Nachhinein
|
||
aufgefallen.
|
||
\end{itemize}
|
||
|
||
Insbesondere aufgrund seiner sehr hohen Flexibilität, haben wir uns am
|
||
Ende für Oqtane entschieden.
|
||
|
||
\paragraph{Entscheidungsfindung restliche
|
||
Infrastruktur}\label{entscheidungsfindung-restliche-infrastruktur}
|
||
|
||
~
|
||
|
||
Als Betriebssystem habe ich mich für Linux entschieden, einfach, da ich
|
||
mit Linux im Serverumfeld die meisten und besten Erfahrungen gemacht
|
||
habe.
|
||
|
||
Im Bereich der Datenbanken musste ich mir ein paar Fragen stellen:
|
||
|
||
\begin{enumerate}
|
||
\def\labelenumi{\arabic{enumi}.}
|
||
\tightlist
|
||
\item
|
||
Auf welche Art Datenbank setzen wir? SQL, NoSQL, Graph, \ldots{}
|
||
\item
|
||
Mit welcher speziellen Implementierung bekommen wir Support und bei
|
||
welcher haben wir Vorwissen im Team?
|
||
\item
|
||
Ist das auserkorene System kompatibel mit dem CMS, auf dem wir
|
||
aufbauen?
|
||
\end{enumerate}
|
||
|
||
Es war von Anfang an klar, dass es ein SQL-basiertes System wird, da wir
|
||
im Team nur mit SQL-basierten Systemen Erfahrungen haben. Außerdem
|
||
unterstützt unser CMS (Oqtane) nur SQL-basierte Systeme. In der
|
||
Linuxwelt kommen jetzt nur noch ein paar Datenbankmanagementsysteme in
|
||
die Auswahl: PostgreSQL, MySQL / MariaDB, SQLite. Da ist die Wahl auf
|
||
PostgreSQL gefallen. Grund dafür war meine Vorerfahrung mit diesem
|
||
Datenbankmanagementsystem, welche ich in meinem Nebenjob erlangt habe.
|
||
|
||
\subsubsection{Beschreibung und Architektur von
|
||
Oqtane}\label{beschreibung-und-architektur-von-oqtane}
|
||
|
||
Oqtane ist ein Framework und CMS zur Entwicklung von Webseiten mithilfe
|
||
von ASP.NET und Blazor.\footnote{Oqtane Foundation (2024a) (siehe
|
||
Internet-/Intranetverzeichnis).} Ein Oqtane-System besteht aus
|
||
mehreren Komponenten.
|
||
|
||
In dieser Diplomarbeit fokussieren wir uns hauptsächlich auf
|
||
\texttt{Themes} und \texttt{Modules}, aber es gibt auch
|
||
\texttt{Language\ Packs} und \texttt{Pure\ Extensions}.\footnote{Oqtane
|
||
Foundation (2024b) (siehe Internet-/Intranetverzeichnis).}
|
||
|
||
Ein \texttt{Module} (Modul) soll neue Funktionalitäten in das CMS
|
||
hinzufügen und ein \texttt{Theme} soll die ganze Gestaltung der Webseite
|
||
(die Shell) festlegen.\footnote{Ebenda.}
|
||
|
||
\paragraph{Architektur eines Moduls}\label{architektur-eines-moduls}
|
||
|
||
~
|
||
|
||
Ein Modul in Oqtane besteht aus vier Projekten:
|
||
|
||
\begin{itemize}
|
||
\item
|
||
Im Server-Projekt liegt Sourcecode, welcher serverseitig ausgeführt
|
||
werden soll. Dazu gehören unter anderem alle Repositories, Controller,
|
||
Manager, Migrationen und Server-Services und Server-Startuplogik.
|
||
\item
|
||
Im Client-Projekt liegen Code und Razor-Komponenten für den Client.
|
||
Also Client-Startuplogik, Client-Services, Ressourcendateien (.resx),
|
||
die Komponenten / das User Interface und die Moduldefinitionen für
|
||
jedes Modul.
|
||
\item
|
||
Im Shared-Projekt wird geteilter Sourcecode abgelegt, der server- und
|
||
clientseitig verwendet wird. In der Praxis bleibt es hierbei bei den
|
||
EntityFramework-Modellen zum Speichern der Daten im Arbeitsspeicher.
|
||
\item
|
||
Im Package Projekt findet man Skripte zum Debuggen und Releasen eines
|
||
Moduls und die NuGet-Spezifikation.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
Beim Debug werden die DLLs, PDBs und statischen Assets wie Skripte
|
||
und Stylesheets der drei anderen Projekte in den bereits gebauten
|
||
Oqtane.Server
|
||
\texttt{oqtane.framework/oqtane.server/bin/debug/net10.0/...}
|
||
kopiert.
|
||
\item
|
||
Beim Release wird ein NuGet-Paket erstellt und unter
|
||
oqtane.framework/oqtane.server/Packages abgelegt. Dort abgelegte
|
||
NuGet-Pakete werden beim nächsten Start des Oqtane Servers
|
||
installiert (Datenbank Migrationen werden gemacht und die Pakete
|
||
entpackt).
|
||
\end{itemize}
|
||
\end{itemize}
|
||
|
||
\subsubsection{Zusammenspiel der
|
||
Infrastruktur}\label{zusammenspiel-der-infrastruktur}
|
||
|
||
In diesem Kapitel erkläre ich wie die ausgewählten Komponenten
|
||
zusammenspielen.
|
||
|
||
\paragraph{NginX as Reverse Proxy}\label{nginx-as-reverse-proxy}
|
||
|
||
~
|
||
|
||
NginX fungiert in unserer Infrastruktur als \texttt{Reverse\ Proxy}. Ein
|
||
Reverse Proxy nimmt Anfragen aus dem Internet entgegen und leitet sie an
|
||
interne Server (wie Kestrel) weiter. Dies bietet mehrere Vorteile:
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{Sicherheit}: Die interne Applikation ist nicht direkt dem
|
||
Internet ausgesetzt.
|
||
\item
|
||
\textbf{SSL-Terminierung}: NginX übernimmt die rechenintensive
|
||
Verschlüsselung (HTTPS), während die Applikation dahinter über
|
||
einfaches HTTP kommuniziert.
|
||
\item
|
||
\textbf{Statische Inhalte}: NginX kann statische Dateien (Bilder, CSS)
|
||
effizienter ausliefern als ein Applikationsserver.
|
||
\end{itemize}
|
||
|
||
Wir verwenden NginX für die SSL Terminierung. Das Zertifikat wird von
|
||
Let's Encrypt bereit gestellt und mittels HTTP-Challenges und dem
|
||
Certbot auf dem Server aktualisiert.
|
||
|
||
Hier ist ein Auszug der NginX-Konfiguration (\texttt{nginx.conf}) für
|
||
den Alumnihub:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\DataTypeTok{server} \OperatorTok{\{}
|
||
\DataTypeTok{listen} \DecValTok{443} \KeywordTok{ssl}\OperatorTok{;}
|
||
\DataTypeTok{server\_name}\NormalTok{ alumni.example.com}\OperatorTok{;}
|
||
|
||
\DataTypeTok{ssl\_certificate}\NormalTok{ /etc/letsencrypt/live/alumni.example.com/fullchain.pem}\OperatorTok{;}
|
||
\DataTypeTok{ssl\_certificate\_key}\NormalTok{ /etc/letsencrypt/live/alumni.example.com/privkey.pem}\OperatorTok{;}
|
||
|
||
\DataTypeTok{location}\NormalTok{ / }\OperatorTok{\{}
|
||
\DataTypeTok{proxy\_pass}\NormalTok{ http://}\DecValTok{127}\NormalTok{.}\DecValTok{0}\NormalTok{.}\DecValTok{0}\NormalTok{.}\DecValTok{1}\NormalTok{:}\DecValTok{5000}\OperatorTok{;}
|
||
\DataTypeTok{proxy\_http\_version} \DecValTok{1}\NormalTok{.}\DecValTok{1}\OperatorTok{;}
|
||
\DataTypeTok{proxy\_set\_header}\NormalTok{ Upgrade }\VariableTok{$http\_upgrade}\OperatorTok{;}
|
||
\DataTypeTok{proxy\_set\_header}\NormalTok{ Connection keep{-}alive}\OperatorTok{;}
|
||
\DataTypeTok{proxy\_set\_header}\NormalTok{ Host }\VariableTok{$host}\OperatorTok{;}
|
||
\DataTypeTok{proxy\_cache\_bypass} \VariableTok{$http\_upgrade}\OperatorTok{;}
|
||
\OperatorTok{\}}
|
||
\OperatorTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Oqtane selber läuft als Systemd-Service im Kestrel Backend. Kestrel ist
|
||
ein kleiner Webserver, welcher in das ASP.NET Core Framework eingebaut
|
||
worden ist. Oqtane (bzw. der ASP.NET Core Server ``Kestrel'') hört auf
|
||
der Loopback IP und Port 5000. Damit ist Oqtane nur durch NginX
|
||
erreichbar. PostgreSQL ist die Datenbank in dem System: Sie hört wieder
|
||
auf der Loopback IP und Port 5432. In der folgenden Grafik ist das
|
||
System Schematisch dargestellt.
|
||
|
||
\pandocbounded{\includegraphics[keepaspectratio]{783200d10c9c35d1be650f901b7a01885746de85.pdf}}
|
||
|
||
Zusätzlich gab es einen Administrationszugang zu den Servern, welcher
|
||
über SSH möglich war. Dieser wurde für die Installation und
|
||
Konfiguration der einzelnen Komponenten verwendet. Der SSH Service ist
|
||
in jeder Umgebung anders erreichbar gewesen.
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.3182}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 2\tabcolsep) * \real{0.6818}}@{}}
|
||
\caption{SSH Zugänge in den unterschiedlichen Umgebungen}\tabularnewline
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Umgebung
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Administrationszugang
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Umgebung
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Administrationszugang
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
Hetzner & Wireguard \\
|
||
Schule & Highport \\
|
||
LiveDesign & IPSEC VPN \\
|
||
\end{longtable}
|
||
|
||
Die VPN basierten Zugänge sind tendenziell schwieriger zu finden und
|
||
auszunutzen, während die Lösung in der Schule mittels Highport den SSH
|
||
Service öffentlich erreichbar macht. Durch den \texttt{Highport} ist der
|
||
SSH Service schwieriger zu finden. Zur Authentifizierung mit SSH
|
||
verwenden wir SSH-Keys, da diese durch ihre komplexität sicherer sind,
|
||
als Passwörter.
|
||
|
||
\subsubsection{Entwicklung mit ASP.NET}\label{entwicklung-mit-asp.net}
|
||
|
||
\paragraph[Blazor]{\texorpdfstring{Blazor\footnote{Wikipedia (2024)
|
||
(siehe Internet-/Intranetverzeichnis).}}{Blazor}}\label{blazor-wikipedia_blazor}
|
||
|
||
~
|
||
|
||
Blazor ist ein kostenloses und quelloffenes Web-Framework, welches es
|
||
möglich macht Benutzeroberflächen für Web-Browser, basierend auf C\# und
|
||
HTML, zu erstellen. Es wird von Microsoft als teil des ASP.NET Core
|
||
Frameworks entwickelt.
|
||
|
||
Blazor hat mehrere Hosting-Modelle:
|
||
|
||
\begin{longtable}[]{@{}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.2967}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.1978}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.1978}}
|
||
>{\raggedright\arraybackslash}p{(\linewidth - 6\tabcolsep) * \real{0.3077}}@{}}
|
||
\caption{Vergleich der Blazor Hosting-Modelle}\tabularnewline
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Hosting-Modell
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Ausführungsort
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Interaktivität
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Kommunikation
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endfirsthead
|
||
\toprule\noalign{}
|
||
\begin{minipage}[b]{\linewidth}\raggedright
|
||
Hosting-Modell
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Ausführungsort
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Interaktivität
|
||
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
|
||
Kommunikation
|
||
\end{minipage} \\
|
||
\midrule\noalign{}
|
||
\endhead
|
||
\bottomrule\noalign{}
|
||
\endlastfoot
|
||
\textbf{Static Server} & Server & Keine & HTTP (Initialer Load) \\
|
||
\textbf{Interactive Server} & Server & Hoch (Echtzeit) & SignalR /
|
||
WebSockets \\
|
||
\textbf{Interactive WebAssembly} & Client (Browser) & Hoch (Lokal) &
|
||
REST API / HTTP \\
|
||
\textbf{Interactive Auto } & Server \& Client (ab zweitem Besuch) & Hoch
|
||
(Echtzeit / Lokal) & SignalR / Websockets / RestAPI / HTTP \\
|
||
\textbf{Hybrid} & Native App (WebView) & Hoch (Lokal) & n/a
|
||
(Mutterprozess) \\
|
||
\end{longtable}
|
||
|
||
Im Rahmen dieser Diplomarbeit haben wir und für den RenderModus
|
||
Interactive Server entschieden. Dieser Modus ist für Oqtane die
|
||
Standardeinstellung und bietet eine gute Balance zwischen Leistung und
|
||
Benutzerfreundlichkeit. Das ist für unseren Anwendungsfall auch die
|
||
Empfehlung von Oqtane selbst.\footnote{Oqtane Foundation (2024c) (siehe
|
||
Internet-/Intranetverzeichnis).}
|
||
|
||
Razor-Komponenten (in dieser Arbeit, sowie umgangssprachlich, auch oft
|
||
nur Komponenten genannt) sind der Grundbaustein für Blazor Web Apps. Sie
|
||
bestehen aus HTML, welches mit der Verwendung von inline C\# beeinflusst
|
||
werden kann. Blazor stellt sicher, dass das gerenderte Markup
|
||
aktualisiert wird, wenn sich der Status der Komponente ändert. Dieser
|
||
Code kann entweder vollständig in einer .razor Datei liegen, oder in
|
||
einer seperaten Code-Behind-Datei. Inline C\# Code wird mithilfe von
|
||
\texttt{@}- Zeichen markiert. Hier ist ein Beispiel für einen einfachen
|
||
Counter:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\DataTypeTok{\textless{}}\KeywordTok{h1}\DataTypeTok{\textgreater{}}\NormalTok{Counter}\DataTypeTok{\textless{}/}\KeywordTok{h1}\DataTypeTok{\textgreater{}}
|
||
|
||
\DataTypeTok{\textless{}}\KeywordTok{p}\DataTypeTok{\textgreater{}}\NormalTok{Count: }\ControlFlowTok{@count}\DataTypeTok{\textless{}/}\KeywordTok{p}\DataTypeTok{\textgreater{}}
|
||
|
||
\DataTypeTok{\textless{}}\KeywordTok{button}\OtherTok{ }\ErrorTok{@}\OtherTok{onclick}\OperatorTok{=}\StringTok{"Increment"}\DataTypeTok{\textgreater{}}\NormalTok{Increment}\DataTypeTok{\textless{}/}\KeywordTok{button}\DataTypeTok{\textgreater{}}
|
||
|
||
\ControlFlowTok{@code}
|
||
\NormalTok{\{}
|
||
\NormalTok{ private int count = 0;}
|
||
|
||
\NormalTok{ private void Increment()}
|
||
\NormalTok{ \{}
|
||
\NormalTok{ count++;}
|
||
\NormalTok{ \}}
|
||
\NormalTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Mit\texttt{@count} in Zeile 3 wird der Wert der Variablen count in den
|
||
\texttt{\textless{}p\textgreater{}} Tag mit eingebaut. Mit
|
||
\texttt{@onclick="Increment"} in Zeile 5 wird die onclick Property vom
|
||
\texttt{\textless{}button\textgreater{}}Tag auf die Increment Methode im
|
||
C\# Code gesetzt. Der \texttt{@code} Block in Zeile 7 ist der C\# Code,
|
||
welcher diese Komponente dynamisch macht. Hier ist die Variable count
|
||
und die Methode Increment definiert, welche dieser Komponente interaktiv
|
||
macht.
|
||
|
||
Razor hat auch eine Reihe an Keywords, wie zum Beispiel (nur
|
||
Auszugsweise, bzw. die die wir verwendet haben):
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
namespace: Gibt den aktuellen Namespace in der Razor Datei an.
|
||
\item
|
||
inherits: Gibt die Superklasse der generierten C\# Klasse an.
|
||
\item
|
||
using: Gibt die im C\# Code benutzen/verfügbaren Namespaces an
|
||
\item
|
||
foreach: Für Wiederholungen im Markup
|
||
\item
|
||
if: Für Verzweigungen im Markup
|
||
\end{itemize}
|
||
|
||
\paragraph{Kommunikation zwischen Front- und
|
||
Backend}\label{kommunikation-zwischen-front--und-backend}
|
||
|
||
~
|
||
|
||
Die Interaktion zwischen Client und Server folgt in Oqtane einem klaren
|
||
Architekturmuster, das je nach Render-Modus unterschiedliche
|
||
Technologien nutzt.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{SignalR (Interactive Server)}: Für Echtzeit-Interaktionen
|
||
nutzt Oqtane SignalR. Dabei wird eine persistente WebSocket-Verbindung
|
||
(oder Fallbacks wie Long-Polling) aufgebaut. Zustandsänderungen im UI
|
||
lösen C\#-Events auf dem Server aus, und das resultierende ``Diff''
|
||
des DOMs wird zurück an den Client gestreamt.
|
||
\item
|
||
\textbf{REST API (WebAssembly/Shared)}: Bei Modulen, die Daten
|
||
asynchron laden (im WebAssembly-Modus), kommuniziert der Client über
|
||
einen \texttt{HttpClient} mit dem Controller.
|
||
\end{itemize}
|
||
|
||
Der folgende Ablauf zeigt die Kommunikation bei einer typischen
|
||
Datenabfrage in einem Oqtane-Modul:
|
||
|
||
\pandocbounded{\includegraphics[keepaspectratio]{fdabef25f189cc75c2e232304f32645db4899631.pdf}}
|
||
|
||
Durch diese Abstraktion bleibt die Geschäftslogik im Backend
|
||
(Repository/Controller) gekapselt, während das Frontend lediglich die
|
||
Daten präsentiert und Benutzereingaben entgegennimmt. Dies unterstützt
|
||
die Testbarkeit, da Repositories unabhängig vom UI getestet werden
|
||
können.
|
||
|
||
\subsubsection{Dependency Injection}\label{dependency-injection}
|
||
|
||
Dependency Injection ist ein Entwurfsmuster, bei dem die Abhängigkeiten
|
||
eines Objekts nicht von diesem selbst erzeugt, sondern von außen
|
||
„injiziert`` werden.
|
||
|
||
Wie der Software-Architekt Martin Fowler, der den Begriff im Jahr 2004
|
||
maßgeblich prägte, beschreibt, geht es im Kern darum, die Erzeugung von
|
||
Objekten von deren Nutzung zu trennen.\footnote{Fowler, Martin (2004)
|
||
(siehe Internet-/Intranetverzeichnis).} Anstatt dass eine Klasse ihre
|
||
Hilfsobjekte mittels des new-Operators selbst instanziiert, werden ihr
|
||
diese meist über den Konstruktor zur Verfügung gestellt.
|
||
|
||
In den folgenden beiden Kapiteln wird das Dependency Inversion Principle
|
||
und das Microsoft Dependency Injection Framework genauer vorgestellt.
|
||
|
||
\paragraph[Dependency Inversion Principle ]{\texorpdfstring{Dependency
|
||
Inversion Principle\footnote{Microsoft (2024a) (siehe
|
||
Internet-/Intranetverzeichnis).}
|
||
\footnote{LogRocket (2024) (siehe Internet-/Intranetverzeichnis).}}{Dependency Inversion Principle }}\label{dependency-inversion-principle-ms_dependency_inversion-logrocket_dependency_inversion}
|
||
|
||
~
|
||
|
||
Das Dependency-Inversion-Principle (DIP / auf Deutsch:
|
||
Abhängigkeits-Umkehr-Prinzip) ist eines von den fünf \texttt{SOLID}
|
||
Prinzipien in der Softwareentwicklung.
|
||
|
||
Das DIP unterscheidet zwischen high-level und low-level Modulen.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
Die High-Level-Module beschreiben die Applikations- / Businesslogik,
|
||
ohne direkt mit den Low-Level-Modulen zu interagieren, sondern
|
||
lediglich auf Abstraktionen.\footnote{OO Design (2024) (siehe
|
||
Internet-/Intranetverzeichnis).}
|
||
\item
|
||
Die Abstraktionen sollen nicht von Implementierungsdetails abhängig
|
||
sein, sondern die Low-Level-Implementierung sollen gemäß der
|
||
Abstraktionsschicht implementiert werden.\footnote{Ebenda.}
|
||
\end{itemize}
|
||
|
||
Ausgangslage ist eine Softwarearchitektur im
|
||
Direct-Dependency-Graph-Modell.
|
||
|
||
\pandocbounded{\includegraphics[keepaspectratio]{e08c4f02a7a60ce024375d5f7f40dd2b284b916f.pdf}}
|
||
|
||
Bei diesem Beispiel ist die Klasse A ein high-level Modul, welches
|
||
direkt auf die Klasse B referenziert, was das DI-Prinzip verbietet. Das
|
||
Problem dabei: Die einzelnen Klassen sind eng gekoppelt, was das
|
||
Austauschen von B mit einer anderen Klasse unmöglich macht. Genau dieses
|
||
Problem wird vom DIP gelöst.
|
||
|
||
\pandocbounded{\includegraphics[keepaspectratio]{e3614678caacf98b36a36fa9f5451a214d4f21c6.pdf}}
|
||
|
||
Das High-Level-Modul ruft lediglich eine Abstraktion eines
|
||
Low-Level-Moduls auf, welche von einem, oder mehreren Low-Level-Modulen
|
||
implementiert wurde. Für das High-Level-Modul ist es hier egal, welches
|
||
Low-Level-Modul die Implementierung bereitstellt. Dadurch erhält man
|
||
einen viel modulareren Aufbau in der Software. Die einzelnen Module sind
|
||
auch leichter austauschbar und testbar. Genau diese Modularität macht
|
||
Dependency Injection möglich.
|
||
|
||
\paragraph{Microsoft Dependency Injection
|
||
Framework}\label{microsoft-dependency-injection-framework}
|
||
|
||
~
|
||
|
||
Dependency Injection ist in .NET genau so wie Konfiguration,
|
||
Protokollierung und das Optionsmuster ins Framework
|
||
integriert.\footnote{Microsoft (2024b) (siehe
|
||
Internet-/Intranetverzeichnis).}
|
||
|
||
Alle Dependencies werden in einem \texttt{Service-Container} zur
|
||
Verwaltung registriert. .NET hat einen eingebauten
|
||
\texttt{Service-Container} (eine Implementierung des
|
||
\texttt{IServiceProvider}).\footnote{Ebenda.}
|
||
|
||
Das Dependency Injection Framework verwaltet alle Instanzen. Nach Bedarf
|
||
werden Instanzen erstellt, oder wieder entsorgt (sofern das Service
|
||
nicht mehr gebraucht wird). Beim Instanziieren einer Klasse werden alle
|
||
im Konstruktor erwarteten Dependencies bereitgestellt, bzw. selbst
|
||
instanziiert und danach bereitgestellt.\footnote{Ebenda.}
|
||
|
||
Hier ein Beispiel aus der Dokumentation von Microsoft:\footnote{Ebenda.}
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\NormalTok{HostApplicationBuilder builder }\OperatorTok{=}\NormalTok{ Host}\OperatorTok{.}\FunctionTok{CreateApplicationBuilder}\OperatorTok{(}\NormalTok{args}\OperatorTok{);}
|
||
|
||
\NormalTok{builder}\OperatorTok{.}\FunctionTok{Services}\OperatorTok{.}\FunctionTok{AddHostedService}\OperatorTok{\textless{}}\NormalTok{Worker}\OperatorTok{\textgreater{}();}
|
||
\NormalTok{builder}\OperatorTok{.}\FunctionTok{Services}\OperatorTok{.}\FunctionTok{AddSingleton}\OperatorTok{\textless{}}\NormalTok{IMessageWriter}\OperatorTok{,}\NormalTok{ MessageWriter}\OperatorTok{\textgreater{}();}
|
||
|
||
\KeywordTok{using}\NormalTok{ IHost host }\OperatorTok{=}\NormalTok{ builder}\OperatorTok{.}\FunctionTok{Build}\OperatorTok{();}
|
||
|
||
\NormalTok{host}\OperatorTok{.}\FunctionTok{Run}\OperatorTok{();}
|
||
|
||
\KeywordTok{public} \KeywordTok{class}\NormalTok{ MessageWriter }\OperatorTok{:}\NormalTok{ IMessageWriter}
|
||
\OperatorTok{\{}
|
||
\KeywordTok{public} \DataTypeTok{void} \FunctionTok{Write}\OperatorTok{(}\DataTypeTok{string}\NormalTok{ message}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\NormalTok{ Console}\OperatorTok{.}\FunctionTok{WriteLine}\OperatorTok{(}\NormalTok{$}\StringTok{"MessageWriter.Write(message: }\SpecialCharTok{\textbackslash{}"}\StringTok{\{message\}}\SpecialCharTok{\textbackslash{}"}\StringTok{)"}\OperatorTok{);}
|
||
\OperatorTok{\}}
|
||
\OperatorTok{\}}
|
||
|
||
\KeywordTok{public} \KeywordTok{interface}\NormalTok{ IMessageWriter}
|
||
\OperatorTok{\{}
|
||
\DataTypeTok{void} \FunctionTok{Write}\OperatorTok{(}\DataTypeTok{string}\NormalTok{ message}\OperatorTok{);}
|
||
\OperatorTok{\}}
|
||
|
||
\KeywordTok{public} \KeywordTok{sealed} \KeywordTok{class} \FunctionTok{Worker}\OperatorTok{(}\NormalTok{IMessageWriter messageWriter}\OperatorTok{)} \OperatorTok{:}\NormalTok{ BackgroundService}
|
||
\OperatorTok{\{}
|
||
\KeywordTok{protected} \KeywordTok{override}\NormalTok{ async Task }\FunctionTok{ExecuteAsync}\OperatorTok{(}\NormalTok{CancellationToken stoppingToken}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\KeywordTok{while} \OperatorTok{(!}\NormalTok{stoppingToken}\OperatorTok{.}\FunctionTok{IsCancellationRequested}\OperatorTok{)}
|
||
\OperatorTok{\{}
|
||
\NormalTok{ messageWriter}\OperatorTok{.}\FunctionTok{Write}\OperatorTok{(}\NormalTok{$}\StringTok{"Worker running at: \{DateTimeOffset.Now\}"}\OperatorTok{);}
|
||
\NormalTok{ await Task}\OperatorTok{.}\FunctionTok{Delay}\OperatorTok{(}\DecValTok{1}\NormalTok{\_000}\OperatorTok{,}\NormalTok{ stoppingToken}\OperatorTok{);}
|
||
\OperatorTok{\}}
|
||
\OperatorTok{\}}
|
||
\OperatorTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Das ist ein simples Beispiel, welches Teile des DI Frameworks zeigt. Wir
|
||
haben einen Service (Klasse Worker), ein Dependency (Klasse
|
||
MessageWriter) und eine Abstraktionsebene, von dem Dependency (Interface
|
||
IMessageWriter).
|
||
|
||
Bei Programmstart wird zuerst manuell der \texttt{Service-Container}
|
||
erstellt, danach alle Module registriert (entweder als HostedService,
|
||
oder als Modul mit einer spezifischen Lifetime (Scoped, Transient,
|
||
Singleton)).
|
||
|
||
Mit dem Aufruf von \texttt{builder.Build()} wird intern ein Dependency
|
||
Graph erstellt und mit \texttt{host.Run()} wird versucht die Klasse
|
||
Worker zu instanziieren und zu starten. Nachdem Worker ein Dependency
|
||
auf IMessageWriter hat, wird über den zuvor erstellten Dependency-Graph
|
||
die Implementierung von IMessageWriter gesucht. Jetzt wird MessageWriter
|
||
instanziiert und dem Konstruktor von Worker übergeben, damit seine
|
||
Dependencies befriedigt werden.
|
||
|
||
So sieht der Abhängigkeitsgraph bei diesem Beispiel aus.
|
||
|
||
\pandocbounded{\includegraphics[keepaspectratio]{f39b4f0675636b8f1bfe34f890466e3db009627c.pdf}}
|
||
|
||
\subsubsection{Continuous Integration}\label{sec:continuous-integration}
|
||
|
||
Gitea, das Versionskontrollsystem dieser Diplomarbeit, hat einen
|
||
Continuous-Integration-System eingebaut. Im Kern ist es baugleich zu den
|
||
GitHub-Pipelines. Man kann im \texttt{.gitea/workflow} Ordner
|
||
\texttt{.yml} Dateien ablegen, welche dann das Verhalten der Workflows
|
||
definieren.
|
||
|
||
Man kann definieren auf welcher Änderung im Git Repository die Pipeline
|
||
losgetreten wird (Keyword: \texttt{on}) und entweder eigene Kommandos
|
||
aufreihen, oder auf bestehende \texttt{actions} zurückgreifen, welche
|
||
dann der Reihe nach ausgeführt werden (Keyword: \texttt{jobs}).
|
||
|
||
Die meisten Pipelines sind folgendermaßen Aufgebaut: Clone
|
||
-\textgreater{} Checkout -\textgreater{} Submodule Checkout (optional)
|
||
-\textgreater{} Dependencies einrichten (zum Beispiel das dotnet SDK)
|
||
-\textgreater{} Build ausführen. -\textgreater{} Release erstellen und
|
||
Artefakte veröffentlichen (z.B. in Registries). Aber man kann auch
|
||
andere Dinge tun, z.B. mithilfe von Künstlicher Intelligenz Code und
|
||
Dokumentation überprüfen.
|
||
|
||
Anwendungen von Gitea Actions bei dieser Diplomarbeit:
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{APT-Package Repository}: Zum Bauen von Oqtane und allen
|
||
Modulen, verpacken in ein .deb Paket und in die Registry pushen.
|
||
\item
|
||
\textbf{Interfaces Projekt}: Zum Bauen vom Interfaces-Projekt,
|
||
verpacken in ein NuGet Paket und in die Registry pushen. Die
|
||
Versionierung des NuGet-Pakets erfolgt dabei automatisiert über
|
||
Git-Tags, was eine konsistente Verknüpfung zwischen Quellcode-Stand
|
||
und Paketversion sicherstellt.
|
||
\item
|
||
\textbf{ursprünglich: oqtane.framework}: Zum bauen und Verpacken in
|
||
einen Docker Container und in die Registry pushen.
|
||
\item
|
||
\textbf{PM Repository}: Zum automatischen Überprüfen der Dokumente,
|
||
unter anderem, mithilfe von KI, wie zum Beispiel Gemini.
|
||
\end{itemize}
|
||
|
||
Ein Beispiel für eine Konfiguration einer Gitea Action:
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\FunctionTok{name}\KeywordTok{:}\AttributeTok{ build{-}debian{-}package}
|
||
\FunctionTok{on}\KeywordTok{:}
|
||
\AttributeTok{ }\FunctionTok{push}\KeywordTok{:}
|
||
\AttributeTok{ }\FunctionTok{tags}\KeywordTok{:}
|
||
\AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ }\StringTok{"*"}
|
||
|
||
\FunctionTok{jobs}\KeywordTok{:}
|
||
\AttributeTok{ }\FunctionTok{build}\KeywordTok{:}
|
||
\AttributeTok{ }\FunctionTok{name}\KeywordTok{:}\AttributeTok{ Build the debian package}
|
||
\AttributeTok{ }\FunctionTok{runs{-}on}\KeywordTok{:}\AttributeTok{ ubuntu{-}latest}
|
||
\AttributeTok{ }\FunctionTok{steps}\KeywordTok{:}
|
||
\AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ }\FunctionTok{name}\KeywordTok{:}\AttributeTok{ }\StringTok{"Git clone"}
|
||
\AttributeTok{ }\FunctionTok{run}\KeywordTok{:}\AttributeTok{ git clone $\{\{ gitea.server\_url \}\}/$\{\{ gitea.repository \}\}.git .}
|
||
\AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ }\FunctionTok{name}\KeywordTok{:}\AttributeTok{ }\StringTok{"Git checkout"}
|
||
\AttributeTok{ }\FunctionTok{run}\KeywordTok{:}\AttributeTok{ git checkout "$\{\{ gitea.sha \}\}"}
|
||
\AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ }\FunctionTok{name}\KeywordTok{:}\AttributeTok{ }\StringTok{"Submodules auschecken"}
|
||
\AttributeTok{ }\FunctionTok{run}\KeywordTok{:}\AttributeTok{ git submodule update {-}{-}init}
|
||
\AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ }\FunctionTok{name}\KeywordTok{:}\AttributeTok{ }\StringTok{"Dotnet SDK einrichten"}
|
||
\AttributeTok{ }\FunctionTok{uses}\KeywordTok{:}\AttributeTok{ actions/setup{-}dotnet@v4}
|
||
\AttributeTok{ }\FunctionTok{with}\KeywordTok{:}
|
||
\AttributeTok{ }\FunctionTok{dotnet{-}version}\KeywordTok{:}\AttributeTok{ }\StringTok{"10.0.x"}
|
||
\AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ }\FunctionTok{name}\KeywordTok{:}\AttributeTok{ }\StringTok{"Configure nuget source"}
|
||
\AttributeTok{ }\FunctionTok{run}\KeywordTok{:}\AttributeTok{ dotnet nuget add source {-}{-}name DAV {-}{-}username kocoder {-}{-}password $\{\{ secrets.REGISTRY\_TOKEN\_KOCODER \}\} https://git.kocoder.xyz/api/packages/Diplomarbeit{-}Absolventenverein/nuget/index.json {-}{-}store{-}password{-}in{-}clear{-}text}
|
||
\AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ }\FunctionTok{name}\KeywordTok{:}\AttributeTok{ }\StringTok{"Build .deb"}
|
||
\AttributeTok{ }\FunctionTok{run}\KeywordTok{:}\AttributeTok{ ./run{-}build.sh "$\{\{ gitea.ref\_name \}\}" "./alumnihub" "Release"}
|
||
\AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ }\FunctionTok{name}\KeywordTok{:}\AttributeTok{ }\StringTok{"Upload .deb"}
|
||
\AttributeTok{ }\FunctionTok{run}\KeywordTok{:}\AttributeTok{ curl {-}{-}user kocoder:$\{\{ secrets.REGISTRY\_TOKEN\_KOCODER \}\} {-}{-}upload{-}file ./alumnihub.deb https://git.kocoder.xyz/api/packages/Diplomarbeit{-}Absolventenverein/debian/pool/trixie/main/upload}
|
||
\AttributeTok{ }\KeywordTok{{-}}\AttributeTok{ }\FunctionTok{name}\KeywordTok{:}\AttributeTok{ }\StringTok{"Create release"}
|
||
\AttributeTok{ }\FunctionTok{uses}\KeywordTok{:}\AttributeTok{ akkuman/gitea{-}release{-}action@v1}
|
||
\AttributeTok{ }\FunctionTok{with}\KeywordTok{:}
|
||
\FunctionTok{ files}\KeywordTok{: }\CharTok{|{-}}
|
||
\NormalTok{ ./alumnihub.deb}
|
||
\NormalTok{ ./alumnihub/opt/alumnihub/Packages/*.nupkg}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Die Konfiguration führt teilweise vorgefertigte Actions aus, wie zum
|
||
Beispiel das Einrichten des .NET SDKs oder das Erstellen eines Releases.
|
||
Aber es werden auch eigene Skripte ausgeführt, wie zum Beispiel das
|
||
Bauen des .deb Pakets. Dieses ist im Repository unter
|
||
\texttt{./run-build.sh} zu finden. Dieses Skript ist für die
|
||
Automatisierung des Build-Prozesses zuständig und kümmert sich um das
|
||
Kompilieren der Anwendung, das Erstellen des Debian-Pakets und das
|
||
Hochladen in die Registry. Abgelegt ist es im APT-Package Repository
|
||
unter \texttt{./gitea/workflows}.
|
||
|
||
\subsubsection{Debian Paket}\label{debian-paket}
|
||
|
||
Um die Anwendung und ihre Abhängigkeiten konsistent auf dem Zielserver
|
||
(Linux/Hetzner) zu installieren, wurde ein eigenes Debian-Paket
|
||
(\texttt{.deb}) erstellt. Das Debian-Paketformat bietet den Vorteil,
|
||
dass es Metadaten über Versionen, Abhängigkeiten und
|
||
Installationsskripte (Maintainer Scripts) enthält.
|
||
|
||
\paragraph{Struktur eines
|
||
Debian-Pakets}\label{struktur-eines-debian-pakets}
|
||
|
||
~
|
||
|
||
Ein \texttt{.deb}-Paket ist im Grunde ein \texttt{ar}-Archiv, das drei
|
||
wesentliche Bestandteile enthält:
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{debian-binary}: Eine Textdatei mit der Versionsnummer des
|
||
Paketformats.
|
||
\item
|
||
\textbf{control.tar.gz}: Enthält die Metadaten
|
||
(\texttt{control}-Datei) und Skripte, die vor oder nach der
|
||
Installation ausgeführt werden (z. B. \texttt{postinst} zum Starten
|
||
des Systemd-Services).
|
||
\item
|
||
\textbf{data.tar.gz}: Enthält die eigentlichen Anwendungsdateien (die
|
||
kompilierten Oqtane-DLLs und statischen Assets), die in das
|
||
Zielverzeichnis (z. B. \texttt{/opt/alumnihub}) entpackt werden.
|
||
\end{itemize}
|
||
|
||
\paragraph{Automatisierung im
|
||
Build-Prozess}\label{automatisierung-im-build-prozess}
|
||
|
||
~
|
||
|
||
Der Bau des Pakets erfolgt vollautomatisch in der Gitea-CI-Pipeline.
|
||
Dabei werden die folgenden Schritte durchlaufen:
|
||
|
||
\begin{enumerate}
|
||
\def\labelenumi{\arabic{enumi}.}
|
||
\tightlist
|
||
\item
|
||
\textbf{Dotnet Publish}: Kompilieren der Anwendung für Linux-x64.
|
||
\item
|
||
\textbf{Paketierung}: Erstellen der Verzeichnisstruktur gemäß dem FHS
|
||
(Filesystem Hierarchy Standard).
|
||
\item
|
||
\textbf{dpkg-deb}: Aufruf des Standard-Werkzeugs
|
||
\texttt{dpkg-deb\ -\/-build}, um das fertige Paket zu schnüren. Dabei
|
||
wird auch hier ein Git-Tag als Grundlage für die Paketversion
|
||
verwendet.
|
||
\item
|
||
\textbf{Publish}: Das Paket wird in die Gitea Package Registry
|
||
hochgeladen und steht dort für das Deployment via \texttt{apt} zur
|
||
Verfügung.
|
||
\end{enumerate}
|
||
|
||
Durch diesen Prozess wird sichergestellt, dass jede Version der Software
|
||
eindeutig identifizierbar und einfach rückrollbar (Rollback) ist.
|
||
|
||
\subsection{Projektmanagement \& Tools}\label{projektmanagement-tools}
|
||
|
||
\subsubsection{Scrum}\label{scrum}
|
||
|
||
Zum verwalten des Projektes haben wir uns an den Grundprinzipien von
|
||
Scrum orientiert, um flexibel auf Änderungen reagieren zu können. Die
|
||
Arbeit wurde in 14-tägige Sprints unterteilt.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\textbf{Sprint Planning}: Zu Beginn jedes Sprints wurden die Aufgaben
|
||
aus dem Product Backlog in das Sprint Backlog übernommen.
|
||
\item
|
||
\textbf{Dailies/Weekly}: Wir hielten wöchentliche Treffen ab, um den
|
||
Fortschritt zu synchronisieren und Blocker zu identifizieren.
|
||
\item
|
||
\textbf{Sprint Review}: Am Ende eines Sprints wurden die funktionalen
|
||
Module präsentiert und der Stand der Diplomarbeit mit dem Betreuer
|
||
besprochen.
|
||
\item
|
||
\textbf{Sprint Retrospective}: Am Ende eines Sprints wurde der Sprint
|
||
reflektiert und es wurden Maßnahmen zur Verbesserung des Prozesses
|
||
abgeleitet.
|
||
\item
|
||
\textbf{Definition of Done}: Zu Beginn der Diplomarbeit haben wir uns
|
||
auf eine Definition of Done geeinigt, welche im Laufe der Diplomarbeit
|
||
immer wieder angepasst wurde.
|
||
\end{itemize}
|
||
|
||
Mehr zum Projektmanagementprozess steht im allgemeinen Teil
|
||
\hyperref[projektmanagement-mit-scrum]{Projektmanagement mit Scrum}.
|
||
|
||
\subsubsection{Projektmanagement-Tools (YouTrack \&
|
||
Gitea)}\label{projektmanagement-tools-youtrack-gitea}
|
||
|
||
Für die initiale Planung und die ersten Sprints wurde YouTrack von
|
||
JetBrains eingesetzt. Im Vergleich zu einfachen To-Do-Listen bietet
|
||
YouTrack mächtige Features für Softwareteams wie agile Boards, Time
|
||
Tracking und Gantt-Diagramme.
|
||
|
||
Im weiteren Verlauf der Diplomarbeit sind wir jedoch auf die
|
||
integrierten Projektmanagement-Funktionen von Gitea umgestiegen.
|
||
\hyperref[issues]{Siehe Issues}. Dieser Wechsel erfolgte, um den
|
||
gesamten Entwicklungsprozess --- von der Aufgabenverwaltung
|
||
(Issues/Boards) über die Versionskontrolle bis hin zur CI/CD-Pipeline
|
||
(Gitea Actions) --- an einem zentralen Ort zu bündeln. Dies verbesserte
|
||
die Übersichtlichkeit und reduzierte den administrativen Aufwand für die
|
||
Pflege unterschiedlicher Systeme.
|
||
|
||
\subsubsection{Git}\label{git}
|
||
|
||
Git fungierte im Rahmen dieser Diplomarbeit als zentrales Werkzeug zur
|
||
Versionskontrolle und Koordination sämtlicher Entwicklungsschritte. Die
|
||
wichtigste Komponente stellt dabei der Commit dar, welcher als
|
||
eindeutiger Snapshot des Projektzustands dient und über eine spezifische
|
||
Commit-SHA (Secure Hash Algorithm) referenziert werden kann. Um eine
|
||
lückenlose Nachvollziehbarkeit zu gewährleisten, wurde für jeden
|
||
abgeschlossenen Arbeitsschritt ein eigener Commit erstellt.
|
||
|
||
Im Gegensatz zu zentralisierten Systemen wie SVN, welches wir im
|
||
Unterricht beigebracht bekommen haben, speichert Git die vollständige
|
||
Historie eines Projekts lokal auf dem Rechner jedes Beteiligten. Dies
|
||
ermöglicht nicht nur ein Offline-Arbeiten, sondern bietet auch eine hohe
|
||
Ausfallsicherheit.
|
||
|
||
Der Workflow in Git basiert auf drei Hauptbereichen:
|
||
|
||
\begin{enumerate}
|
||
\def\labelenumi{\arabic{enumi}.}
|
||
\tightlist
|
||
\item
|
||
Working Directory: Der aktuelle Zustand der Dateien auf der
|
||
Festplatte.
|
||
\item
|
||
Staging Area (Index): Eine Zwischenebene, in der Änderungen für den
|
||
nächsten Snapshot vorgemerkt werden.
|
||
\item
|
||
Repository (HEAD): Der dauerhafte Speicher der versionierten Stände
|
||
(Commits).
|
||
\end{enumerate}
|
||
|
||
Eines der mächtigsten Features von Git ist das Branching. Es erlaubt es,
|
||
isolierte Entwicklungszweige zu erstellen, um neue Features oder
|
||
experimentelle Analysen zu implementieren, ohne die Stabilität des
|
||
Hauptzweigs \texttt{main} zu gefährden.
|
||
|
||
Sobald eine Änderung erfolgreich getestet wurde, wird sie durch einen
|
||
Merge wieder in den Hauptzweig integriert. Sollten dabei
|
||
widersprüchliche Änderungen an denselben Dateizeilen auftreten,
|
||
unterstützt Git den Nutzer bei der Auflösung dieser sogenannten
|
||
Merge-Konflikte.
|
||
|
||
Für die Sicherung und Zusammenarbeit wurde im Rahmen dieser Arbeit
|
||
Remote-Repositories auf einer Gitea Instanz verwendet. Durch die Befehle
|
||
push und pull wird der lokale Stand mit dem Server synchronisiert. Dies
|
||
gewährleistet eine konsistente Datenbasis und dient gleichzeitig als
|
||
kontinuierliches Backup des Projektfortschritts.
|
||
|
||
\subsubsection{Gitea}\label{gitea-1}
|
||
|
||
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.\footnote{Gitea
|
||
(2024a) (siehe Internet-/Intranetverzeichnis).}
|
||
|
||
\paragraph{Repositories}\label{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.\footnote{Ebenda.}
|
||
|
||
\paragraph{Issues}\label{issues}
|
||
|
||
~
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth,height=\textheight,keepaspectratio]{./images/05-Konstantin/GiteaIssues-TaskBoard.png}
|
||
\caption{Gitea Issues Board}
|
||
\end{figure}
|
||
|
||
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.\footnote{Ebenda.} \footnote{Gitea (2024b)
|
||
(siehe Internet-/Intranetverzeichnis).}
|
||
|
||
\paragraph{Pull Requests}\label{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.\footnote{Gitea (2024a) (siehe Internet-/Intranetverzeichnis).}
|
||
\footnote{Gitea (2024c) (siehe Internet-/Intranetverzeichnis).}
|
||
|
||
\paragraph{Actions}\label{actions}
|
||
|
||
~
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth,height=\textheight,keepaspectratio]{./images/05-Konstantin/GiteaActions-Overview.png}
|
||
\caption{Gitea Actions}
|
||
\end{figure}
|
||
|
||
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. {[}Siehe Abschnitt
|
||
\ref{sec:continuous-integration}{]}\footnote{Gitea (2024a) (siehe
|
||
Internet-/Intranetverzeichnis).} \footnote{Gitea (2024d) (siehe
|
||
Internet-/Intranetverzeichnis).}
|
||
|
||
\paragraph{Releases}\label{releases}
|
||
|
||
~
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth,height=\textheight,keepaspectratio]{./images/05-Konstantin/GiteaActions-Releases.png}
|
||
\caption{Gitea Releases}
|
||
\end{figure}
|
||
|
||
Ü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.\footnote{Gitea (2024a)
|
||
(siehe Internet-/Intranetverzeichnis).}
|
||
|
||
\paragraph{Package Repositories}\label{package-repositories}
|
||
|
||
~
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth,height=\textheight,keepaspectratio]{./images/05-Konstantin/GiteaPackageRepository.png}
|
||
\caption{Gitea Packages}
|
||
\end{figure}
|
||
|
||
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.\footnote{Ebenda.} \footnote{Gitea (2024e) (siehe
|
||
Internet-/Intranetverzeichnis).}
|
||
|
||
\subsubsection{Kommunikation}\label{kommunikation}
|
||
|
||
\subsection{Module}\label{module-2}
|
||
|
||
\subsubsection{Admin Modules}\label{admin-modules}
|
||
|
||
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.
|
||
|
||
\paragraph{Mass Mailing}\label{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.
|
||
|
||
\subparagraph{Integration von Brevo}\label{integration-von-brevo}
|
||
|
||
\hfill\break
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth,height=\textheight,keepaspectratio]{./images/05-Konstantin/Brevo.png}
|
||
\caption{Brevo Integration}
|
||
\end{figure}
|
||
|
||
Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst
|
||
Brevo. Dieser bietet eine zuverlässige Zustellung (hohe Reputation der
|
||
Mailserver), sowie die Möglichkeit die Zustell-, Öffnungs- und
|
||
Klickraten zu beobachten. Das Limit von 300 E-Mails pro Tag stellt uns
|
||
jedoch in der kostenlosen Variante vor eine Herausforderung.
|
||
|
||
\texttt{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 \texttt{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.
|
||
|
||
\paragraph{Token Lifetime}\label{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
|
||
\texttt{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.
|
||
|
||
Technisch bedeutet das, dass die standardmäßig vorkonfigurierten
|
||
\texttt{DataProtectionTokenProviderOptions} explizit konfiguriert werden
|
||
müssen.\footnote{Lock, Andrew (2024) (siehe
|
||
Internet-/Intranetverzeichnis).} Der ASP.NET Core
|
||
\texttt{UserManager}, welcher das generieren der Tokens übernimmt,
|
||
verwendet einen \texttt{DataProtectorTokenProvider} und dieser wiederum
|
||
kann mithilfe der \texttt{DataProtectionTokenProviderOptions}
|
||
konfiguriert werden.
|
||
|
||
Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\texttt{der\ Workaround}: Ein eigenes Modul, welches in seiner
|
||
\texttt{Server/Startup.cs} die benötigten Werte korrekt setzt. Das hat
|
||
den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern
|
||
nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte
|
||
durch die undeterministische Ladereihenfolge eine
|
||
\texttt{race-condition} auftreten.\footnote{Maryland, University of
|
||
(2024) (siehe Internet-/Intranetverzeichnis).} Darüber hinaus
|
||
besteht kein gleichzeitiger Zugriff auf die appsettings.json und den
|
||
IServiceProvider, in dem die Konfiguration gesetzt werden muss.
|
||
=\textgreater{} Nachdem wir in der Konfigurationsphase auch noch
|
||
keinen Datenbankzugriff haben, können die Werte nicht aus der
|
||
Datenbank geladen werden, sondern wir müssen auf eine Textdatei
|
||
zurückgreifen.
|
||
\item
|
||
\texttt{die\ saubere\ Lösung}: Eine Änderung im Kern von Oqtane. Also
|
||
wird in unserem Fork von Oqtane die Konfigurationslogik für die
|
||
Tokenlifetime implementiert. In diesem Fall könnte die
|
||
Konfigurationslogik direkt in
|
||
\texttt{OqtaneServiceCollectionExtensions.cs} hinzugefügt werden, da
|
||
hier auch alle anderen Oqtane Spezifischen Konfigurationen gesetzt
|
||
werden. Das hat den Vorteil, dass der Code aufgeräumter und sauberer
|
||
ist und die \texttt{race-condition} verhindert werden kann.\footnote{Ebenda.}
|
||
Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository
|
||
zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht
|
||
mehr mit Upstream Commit-gleich ist.
|
||
\end{itemize}
|
||
|
||
\texttt{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
|
||
\texttt{die\ saubere\ Lösung} implementieren.
|
||
|
||
\paragraph{Reporting System}\label{reporting-system}
|
||
|
||
~
|
||
|
||
Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie
|
||
der \texttt{Hall\ of\ Fame}, dem \texttt{Schwarzen\ Brett} und dem
|
||
Premium Bereich (\texttt{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.
|
||
|
||
Angestrebt wurde folgender Ablauf für das Melden eines Eintrags:
|
||
|
||
\pandocbounded{\includegraphics[keepaspectratio]{896637356e9d54db4c95ce116530ff0191d7fcce.pdf}}
|
||
|
||
Im oben dargestellten Ablaufdiagram werden das ReportingComponent und
|
||
der ReportingHandler vom Reporting System über Dependency Injection
|
||
bereitgestellt, nicht vom Modul selbst. Dadurch erreichen wir eine
|
||
bessere Trennung der Zuständigkeiten und halten das S in SOLID ein:
|
||
\texttt{Single\ responsibility}. Die Module sind jetzt nicht mehr für
|
||
das Reporting selber verantwortlich, sondern müssen nur das Reportings
|
||
System einbinden.
|
||
|
||
Darüber hinaus erfüllt dieses Design das \textbf{Open/Closed Principle}:
|
||
Das Reporting-System ist offen für Erweiterungen (neue Module können
|
||
einfach andocken), aber geschlossen für Modifikationen (der Kern des
|
||
Reporting-Systems muss nicht für jedes neue Modul geändert werden).
|
||
|
||
Damit DI funktioniert muss für den DI Consumer
|
||
(\texttt{also\ das\ Modul,\ welches\ das\ Reporting\ System\ einbinden\ möchte})
|
||
das Interface zur Kompilierzeit zur Verfügung stehen. Um das zu
|
||
erreichen habe ich eine neue Klassenbibliothek erstellt: Sie heißt
|
||
\texttt{Interfaces}, wird per Gitea Actions automatisch in ein
|
||
NuGet-Paket gebaut und in der \texttt{Gitea\ Actions\ NuGet\ Registry}
|
||
veröffentlicht. Die Versionierung folgt dabei strikt den Git-Tags im
|
||
Repository, was eine saubere Release-History ermöglicht. Dieses
|
||
NuGet-Paket wird dann in jedem notwendigen Modul als Dependency
|
||
hinzugefügt und damit kann man Modulübergreifend auf die Services und
|
||
das \texttt{IReportingComponent} zugreifen.
|
||
|
||
Die Implementierung des \texttt{IReportingComponents} stellt nur eine
|
||
Property (\texttt{ReportType}, welche den TypeName der Razor Komponente
|
||
zurückliefert, damit \texttt{DynamicComponent} sie laden kann) und eine
|
||
Methode (\texttt{ConstructParameterList}, welche das Parameter
|
||
Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit
|
||
dem \texttt{DynamicComponent} von Razor ist es möglich, per C\# Code
|
||
unterschiedliche Komponenten zu rendern und damit auch die per DI
|
||
injizierte Klasse.
|
||
|
||
\begin{Shaded}
|
||
\begin{Highlighting}[]
|
||
\ControlFlowTok{@inject}\NormalTok{ IReportUI ReportUI}
|
||
|
||
\DataTypeTok{\textless{}}\KeywordTok{DynamicComponent}
|
||
\OtherTok{ Type}\OperatorTok{=}\StringTok{"@ReportUI.ReportType"}
|
||
\OtherTok{ Parameters}\OperatorTok{=}\StringTok{"@ReportUI.ConstructParameterList(\_item, RenderModeBoundary)"}
|
||
\DataTypeTok{/\textgreater{}}
|
||
|
||
\ControlFlowTok{@code}\NormalTok{ \{}
|
||
\NormalTok{ private IReportable \_item;}
|
||
\NormalTok{\}}
|
||
\end{Highlighting}
|
||
\end{Shaded}
|
||
|
||
Die Bereitstellung des Moduls geschieht im \texttt{AdminModules} Modul.
|
||
|
||
\subsubsection{Event Registration}\label{event-registration}
|
||
|
||
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.
|
||
|
||
\paragraph{Backend und Datenhaltung}\label{backend-und-datenhaltung}
|
||
|
||
~
|
||
|
||
Die serverseitige Implementierung basiert auf dem Repository-Pattern des
|
||
Oqtane-Frameworks. Hierbei kommen zwei zentrale Repositories zum
|
||
Einsatz:
|
||
|
||
Das \texttt{EventRepository} verwaltet die Metadaten der Veranstaltungen
|
||
wie Name, Beschreibung, Datum und Ort. Das \texttt{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 \texttt{EventRegistrationController}, der
|
||
sicherstellt, dass nur autorisierte Benutzer Änderungen vornehmen oder
|
||
detaillierte Statistiken einsehen können.
|
||
|
||
\subparagraph{Entity Relationship
|
||
Diagram}\label{entity-relationship-diagram}
|
||
|
||
\hfill\break
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.5\linewidth,height=\textheight,keepaspectratio]{erd-event-registration.pdf}
|
||
\caption{ER Diagramm des Event Registration Moduls}
|
||
\end{figure}
|
||
|
||
\paragraph{Statistik und
|
||
Visualisierung}\label{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.
|
||
|
||
Um die Brücke zwischen dem C\#-basierten Blazor-Frontend und der
|
||
JavaScript-Bibliothek Chart.js zu schlagen, wurde ein dedizierter
|
||
Interop-Service implementiert. Der JS-Interop-Layer ist zwar
|
||
standardmäßig in Oqtane-Modulen vorgesehen, wurde jedoch in diesem Modul
|
||
zum ersten Mal angepasst und produktiv eingesetzt. Der Ablauf der
|
||
grafischen Darstellung gestaltet sich wie folgt:
|
||
|
||
\begin{enumerate}
|
||
\def\labelenumi{\arabic{enumi}.}
|
||
\tightlist
|
||
\item
|
||
Datenaufbereitung: In der Edit-Komponente werden alle Rückmeldungen zu
|
||
einem Event geladen und nach ihrem Typ, oder beliebigen anderen
|
||
Merkmalen aggregiert.
|
||
\item
|
||
JS-Interop: Über die \texttt{CreateChart}-Methode der Interop-Klasse
|
||
wird die JavaScript-Funktion \texttt{createChart} in der
|
||
\texttt{Module.js} aufgerufen. Dabei werden die aggregierten Daten,
|
||
Beschriftungen und Konfigurationsoptionen übergeben.
|
||
\item
|
||
Canvas-Rendering: Die JavaScript-Logik erzeugt dynamisch ein
|
||
HTML5-canvas-Element innerhalb eines Container-Divs und initialisiert
|
||
daraufhin die Chart.js-Instanz, welche ein übersichtliches Pie-Chart
|
||
mit den Registrierungsstatistiken rendert.
|
||
\end{enumerate}
|
||
|
||
Durch diese Trennung bleibt die Geschäftslogik im C\#-Code, während für
|
||
die performante und ansprechende Darstellung auf etablierte
|
||
Web-Technologien zurückgegriffen wird.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.4\linewidth,height=\textheight,keepaspectratio]{./images/05-Konstantin/EventRegistration-PieChart.png}
|
||
\caption{EventRegistration Pie Chart}
|
||
\end{figure}
|
||
|
||
\subsubsection{Schwarzes Brett}\label{schwarzes-brett}
|
||
|
||
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.
|
||
|
||
\paragraph{Struktur und Anzeige}\label{struktur-und-anzeige}
|
||
|
||
~
|
||
|
||
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.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth,height=\textheight,keepaspectratio]{./images/05-Konstantin/BlackBoard-Overview.png}
|
||
\caption{Übersicht der Einträge auf dem Schwarzen Brett}
|
||
\end{figure}
|
||
|
||
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. Für die Eingabe und
|
||
Formatierung der Texte wird auf die von Oqtane standardmäßig
|
||
bereitgestellten Rich-Text-Editoren zurückgegriffen, was eine
|
||
konsistente Nutzerführung im gesamten CMS gewährleistet. Ergänzt wird
|
||
dies durch Metadaten wie Erstellungsdatum und Autor.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth,height=\textheight,keepaspectratio]{./images/05-Konstantin/BlackBoard-Details.png}
|
||
\caption{Detailansicht eines Eintrags auf dem Schwarzen Brett}
|
||
\end{figure}
|
||
|
||
\paragraph{Automatisierter
|
||
E-Mail-Digest}\label{automatisierter-e-mail-digest}
|
||
|
||
~
|
||
|
||
Um die Mitglieder regelmäßig über neue Inhalte zu informieren, wurde ein
|
||
automatisierter \texttt{Cronjob} implementiert. Dieser Job läuft im
|
||
Hintergrund des Oqtane-Frameworks und führt folgende Schritte aus:
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
Filterung: Der Job identifiziert alle Einträge, die seit dem letzten
|
||
Versand erstellt wurden.
|
||
\item
|
||
Zielgruppenselektion: Es werden alle Benutzer identifiziert, die der
|
||
Rolle ``Absolventen'' angehören.
|
||
\item
|
||
Zusammenstellung: Für jeden dieser Benutzer wird eine personalisierte
|
||
Email-Notification generiert, welche eine Zusammenfassung der neuen
|
||
Einträge enthält.
|
||
\item
|
||
Versand: Die generierten Notifications werden in die Warteschlange der
|
||
Notification-Infrastruktur eingereiht und sukzessive versendet.
|
||
Integration des Reporting-Systems
|
||
\end{itemize}
|
||
|
||
\paragraph{Reporting System}\label{reporting-system-1}
|
||
|
||
~
|
||
|
||
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.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.7\linewidth,height=\textheight,keepaspectratio]{./images/05-Konstantin/ReportSystem-HandleReport.png}
|
||
\caption{Reporting System}
|
||
\end{figure}
|
||
|
||
\paragraph{Technischer Hintergrund}\label{technischer-hintergrund}
|
||
|
||
~
|
||
|
||
Auf der Serverseite folgt das Modul dem etablierten Muster mit einem
|
||
\texttt{BlackBoardRepository} für den effizienten Datenbankzugriff und
|
||
einem \texttt{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.
|
||
|
||
\subsection{Learnings}\label{learnings-2}
|
||
|
||
\subsubsection{Produktion != Staging}\label{produktion-staging}
|
||
|
||
Ein Learning, welches doch relativ schnell aufkam ist im Bereich der IT
|
||
eigentlich kein unbekanntes. Wir hatten dieses Learning relativ bald, im
|
||
Frühling 2025, als die ersten Probleme mit dem Deployment von Oqtane
|
||
aufkamen. Oqtane war zwar in unserer Entwicklungsumgebung sehr einfach
|
||
zum einrichten gewesen, das Deployment in der Cloud vom Hetzner war
|
||
jedoch geplagt von Problemen. Im Zeitraum von Mai bis Okober hatten wir
|
||
keine laufende Produktivumgebung. Dadurch sind wir mit dieser
|
||
Diplomarbeit auch in
|
||
\hyperref[arbeitszeiteinschuxe4tzung-zeitverzug]{Zeitverzug} gekommen.
|
||
Hätte ich mich vor dem Start der Diplomarbeit mit dem Deployment von
|
||
Oqtane auseinander gesetzt, dann wäre das in
|
||
\hyperref[fehlende-dokumentation]{Fehlende Dokumentation} beschriebene
|
||
Problem früher aufgekommen und der Zeitverzug wäre nicht so groß, oder
|
||
noch ganz vermeidbar gewesen.
|
||
|
||
\subsubsection{Teamleitung (Motivation /
|
||
Downsizing)}\label{teamleitung-motivation-downsizing}
|
||
|
||
Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von
|
||
Oqtane gestürzt habe, habe ich meine Rolle als Teamleitung etwas
|
||
schleifen lassen. Dadurch fehlte bei einigen Teammitgliedern initial die
|
||
Identifikation mit dem Projekt und in weitererfolge auch die Motivation
|
||
an diesem Projekt mitzuarbeiten. Nachdem im Verlauf des Frühlings und
|
||
über den Sommer von der hälfte des Teams trotz Besprechungen und
|
||
Mahnungen keine Beiträge zu dem Projekt kamen, haben Hr. Prof.~Gürth und
|
||
ich uns dazu entschieden uns von 2 Personen vor unterschreiben des
|
||
Projektantrages zu trennen. Grund dazu war die Angst, die mangelnde
|
||
Motivation zieht das restliche Team mit hinunter. Wir wollten uns trotz
|
||
des Downsizings nicht an Funktionalitäten sparen und haben uns für das
|
||
nächste halbe bis dreiviertel Jahr einen ziemlich strikten Zeitplan
|
||
vorgenommen.
|
||
|
||
\subsubsection{Arbeitszeiteinschätzung
|
||
(Zeitverzug)}\label{arbeitszeiteinschuxe4tzung-zeitverzug}
|
||
|
||
Ein wesentliches Learning aus dem Projektverlauf war die Diskrepanz
|
||
zwischen der initialen Planung und dem tatsächlichen Aufwand.
|
||
Ursprünglich wurde der Zeitaufwand für das Aufsetzen der Infrastruktur
|
||
und die Einarbeitung in das Oqtane-Framework auf etwa drei Wochen
|
||
geschätzt. In der Realität nahm dieser Prozess jedoch mehrere Monate in
|
||
Anspruch.
|
||
|
||
Es gibt mehrere Gründe dafür:
|
||
|
||
\paragraph{Fehlende Dokumentation}\label{fehlende-dokumentation}
|
||
|
||
~
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
\texttt{Fehlende\ oder\ nur\ schlechte\ Dokumentation\ von\ Oqtane}:
|
||
Einige Probleme im Deployment wurden in langer und mühseliger Arbeit
|
||
auseinander gebrochen und in weitere immer kleinere Probleme
|
||
unterteilt. Dadurch, dass wir alle keine Erfahrung mit der Entwicklung
|
||
und dem Deployment von ASP.NET Code Anwendungen hatten und die
|
||
Dokumentation doch schlecht war, blieb uns manchmal nichts anderes
|
||
übrig als mit WireShark den Netzwerktraffic mit zu schneiden und
|
||
nebenbei im Git Repository die geloggten Zeilen Code zu finden und so
|
||
das Framework von innen heraus kennen zu lernen. Dadurch hatte ich
|
||
dann nach einer Einarbeitungszeit von 4 Monaten ziemlich jede Stelle
|
||
im Sourcecode von Oqtane gesehen und finde mich um das schneller
|
||
zurecht.
|
||
\item
|
||
\texttt{Team-Konsolidierung}: Durch das notwendige Downsizing des
|
||
Teams mussten Aufgaben neu verteilt werden, was die individuelle
|
||
Arbeitslast erhöhte und die Konzentration auf die Kernentwicklung
|
||
zeitweise verzögert hat.
|
||
\item
|
||
\texttt{Abhängigkeit\ von\ der\ Infrastruktur}: Dadurch, dass wir bis
|
||
in den Oktober / November hinein nicht wussten, ob wir weiter bei
|
||
Oqtane bleiben können, haben die anderen Teammitglieder nicht mit der
|
||
sinnvollen Entwicklung ihrer Module starten können. Zitat: ``Und was
|
||
wenn wir am Ende doch noch das CMS umstellen müssen?'' =\textgreater{}
|
||
Auch wenn der Auftrag war, mit der Modulentwicklung zu starten war die
|
||
Motivation meiner Teammitglieder nicht so hoch. Selbst wenn sie nicht
|
||
direkt von der Infrastruktur mit der Ausführung ihrer Aufgaben
|
||
abhängig waren, motiviert waren sie wegen der Umstände auch nicht.
|
||
\end{itemize}
|
||
|
||
Reaktion auf den Verzug: Um das Projektziel dennoch zu erreichen, wurde
|
||
der Zeitplan im Herbst 2025 massiv gestrafft. Durch die Umstellung auf
|
||
einen strikteren 14-tägigen Sprint-Rhythmus und die Priorisierung von
|
||
Core-Funktionalitäten (MVP-Ansatz) konnte der Rückstand teilweise
|
||
aufgeholt werden.
|
||
|
||
\begin{quote}
|
||
Fazit: Die Erfahrung zeigt, dass gerade bei ``Nischen-Frameworks'' wie
|
||
Oqtane ein deutlich höherer Puffer für die Einarbeitungs- und
|
||
Infrastrukturphase (Faktor 2 bis 3 der ursprünglichen Schätzung)
|
||
eingeplant werden muss.
|
||
\end{quote}
|
||
|
||
\texttt{90\%\ fertig,\ oder\ fertig?}: Es gibt einige ``Regeln'', wie:
|
||
das \texttt{Paretoprinzip}, \texttt{Hofstadter’s\ Law} und die
|
||
\texttt{90-90\ Regel}. Letztere wurde im Jahr 1985 von Jon Bentley in
|
||
einer Kolumne ``Programming pearls'' veröffentlicht. Ausgeschrieben
|
||
lautet sie:
|
||
|
||
\begin{quote}
|
||
{[}Rule of Credibility{]} The first 90 percent of the code accounts for
|
||
the first 90 percent of the development time. The remaining 10 percent
|
||
of the code accounts for the other 90 percent of the development
|
||
time.\footnote{Bentley, Jon (1985).} Diese Diplomarbeit liefert weitere
|
||
Evidenz, dass diese Faustregel stimmt.
|
||
\end{quote}
|
||
|
||
\subsubsection{Sprints und Meetings (in Zukunft ja
|
||
asynchron)}\label{sprints-und-meetings-in-zukunft-ja-asynchron}
|
||
|
||
Ein zentrales Problem in unserer ursprünglichen Arbeitsweise war die
|
||
Kopplung von Besprechungsterminen mit festen „Commit-Deadlines`` (dem
|
||
Ende des aktuellen Sprint zyklusses). Da wir uns einmal pro Woche für
|
||
sechs Stunden am Stück trafen, entstand ein destruktives Muster:
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
Der ``Last-Minute-Commit''-Druck: In den Stunden unmittelbar vor dem
|
||
Meeting wurden Aufgaben unter Zeitdruck abgeschlossen, um im Meeting
|
||
Fortschritte präsentieren zu können. Dies führte dazu, dass unfertiger
|
||
oder unzureichend getesteter Code („Quick and Dirty``) in das
|
||
Repository gepusht wurde.
|
||
\item
|
||
Fehlende Review-Kultur: Da die Commits erst kurz vor dem Meeting
|
||
eintrafen, blieb dem restlichen Team keine Zeit für fundierte
|
||
Code-Reviews. Die Besprechungszeit wurde somit für die Fehlersuche
|
||
statt für strategische Planung genutzt.
|
||
\item
|
||
Ineffizienz: Lange Präsenz-Meetings blockierten wertvolle
|
||
Entwicklungszeit, ohne die technische Qualität zu steigern.
|
||
\end{itemize}
|
||
|
||
Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
|
||
|
||
\begin{itemize}
|
||
\tightlist
|
||
\item
|
||
Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B.
|
||
in Gitea Issues oder YouTrack), nicht mehr in stundenlangen
|
||
Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen
|
||
Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende
|
||
des Tages automatisch an alle Teammitglieder zum Überblick gesendet
|
||
werden (eventuell mit @username tagging, um eine Person nochmal genau
|
||
anzusprechen)
|
||
\item
|
||
Review-First-Policy: Ein Feature gilt erst dann als „fertig``, wenn es
|
||
einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting
|
||
dient nur noch der Klärung von Blockern, nicht der Präsentation von
|
||
Code. Das war eigentlich schon von Anfang an in unserer
|
||
\texttt{Definition\ of\ Done} festgelegt worden.
|
||
\item
|
||
Entkoppelung von Meeting und Deadline: Meetings sollten der
|
||
Synchronisation dienen, während die Abgabe von Arbeitspaketen
|
||
kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen
|
||
(in der \hyperref[continuous-integration]{Gitea Actions} Pipeline) am
|
||
Tag der Besprechung zu vermeiden.
|
||
\end{itemize}
|
||
|
||
\pagebreak
|
||
|
||
\cleardoublepage
|
||
|
||
\section{Tabellenverzeichnis}\label{tabellenverzeichnis}
|
||
|
||
\listoftables
|
||
|
||
\cleardoublepage
|
||
|
||
\section{Abbildungsverzeichnis}\label{abbildungsverzeichnis}
|
||
|
||
\listoffigures
|
||
|
||
\cleardoublepage
|
||
|
||
\section{Quellenverzeichnis}\label{quellenverzeichnis}
|
||
|
||
\phantomsection\label{refs}
|
||
\begin{CSLReferences}{1}{1}
|
||
\bibitem[\citeproctext]{ref-bentley1985programming}
|
||
\textbf{Bentley, Jon (\textbf{1985}):} Programming pearls\emph{ In:
|
||
Communications of the ACM}, Band 28, Ausgabe 9, 1985896--901, DOI:
|
||
\href{https://doi.org/10.1145/4284.315122}{10.1145/4284.315122}.
|
||
|
||
\bibitem[\citeproctext]{ref-bootstrap}
|
||
\textbf{Bootstrap (\textbf{2026}):} Bootstrap Framework, 2026, abgerufen
|
||
am 17.03.2026, \url{https://getbootstrap.com/}.
|
||
|
||
\bibitem[\citeproctext]{ref-bsi_grundschutz}
|
||
\textbf{BSI (\textbf{2023}):} IT-Grundschutz-Kompendium -- CON.3:
|
||
Datensicherungskonzept, 2023, abgerufen am 19.03.2026,
|
||
\url{https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium/IT_Grundschutz_Kompendium_Edition2023.pdf}.
|
||
|
||
\bibitem[\citeproctext]{ref-bsi_datensicherung}
|
||
\textbf{Bundesamt für Sicherheit in der Informationstechnik (BSI)
|
||
(\textbf{2024}):} Datensicherung und Datenverlust, 2024, abgerufen am
|
||
19.03.2026,
|
||
\url{https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Daten-sichern-verschluesseln-und-loeschen/Datensicherung-und-Datenverlust/Datensicherung-wie-geht-das/datensicherung-wie-geht-das_node.html}.
|
||
|
||
\bibitem[\citeproctext]{ref-ris}
|
||
\textbf{Bundeskanzleramt Österreich (\textbf{2024}):}
|
||
Rechtsinformationssystem des Bundes (RIS), 2024, abgerufen am
|
||
19.03.2026, \url{https://www.ris.bka.gv.at/}.
|
||
|
||
\bibitem[\citeproctext]{ref-dsb}
|
||
\textbf{Datenschutzbehörde (\textbf{2024}):} Österreichische
|
||
Datenschutzbehörde (DSB), 2024, abgerufen am 19.03.2026,
|
||
\url{https://dsb.gv.at/}.
|
||
|
||
\bibitem[\citeproctext]{ref-dsgvo}
|
||
\textbf{Europäische Union (\textbf{2016}):} Datenschutz-Grundverordnung
|
||
(DSGVO), 2016, abgerufen am 19.03.2026,
|
||
\url{https://eur-lex.europa.eu/eli/reg/2016/679/}.
|
||
|
||
\bibitem[\citeproctext]{ref-fowler_dependency_injection}
|
||
\textbf{Fowler, Martin (\textbf{2004}):} Inversion of Control Containers
|
||
and the Dependency Injection pattern, 2004, abgerufen am 19.03.2026,
|
||
\url{https://martinfowler.com/articles/injection.html}.
|
||
|
||
\bibitem[\citeproctext]{ref-gitea_docs}
|
||
\textbf{Gitea (\textbf{2024a}):} Gitea Documentation, 2024, abgerufen am
|
||
19.03.2026, \url{https://docs.gitea.com/}.
|
||
|
||
\bibitem[\citeproctext]{ref-gitea_issue_tracker}
|
||
\textbf{Gitea (\textbf{2024b}):} Gitea Issue Tracker Comparison, 2024,
|
||
abgerufen am 19.03.2026,
|
||
\url{https://docs.gitea.com/installation/comparison\#issue-tracker}.
|
||
|
||
\bibitem[\citeproctext]{ref-gitea_pull_requests}
|
||
\textbf{Gitea (\textbf{2024c}):} Gitea Pull Requests, 2024, abgerufen am
|
||
19.03.2026, \url{https://docs.gitea.com/usage/pull-request}.
|
||
|
||
\bibitem[\citeproctext]{ref-gitea_actions}
|
||
\textbf{Gitea (\textbf{2024d}):} Gitea Actions Overview, 2024, abgerufen
|
||
am 19.03.2026, \url{https://docs.gitea.com/usage/actions/overview}.
|
||
|
||
\bibitem[\citeproctext]{ref-gitea_packages}
|
||
\textbf{Gitea (\textbf{2024e}):} Gitea Packages Overview, 2024,
|
||
abgerufen am 19.03.2026,
|
||
\url{https://docs.gitea.com/usage/packages/overview}.
|
||
|
||
\bibitem[\citeproctext]{ref-gitea_about}
|
||
\textbf{Gitea (\textbf{2026}):} Gitea -- Open Source Git Service, 2026,
|
||
abgerufen am 17.03.2026, \url{https://about.gitea.com/}.
|
||
|
||
\bibitem[\citeproctext]{ref-rfc6749}
|
||
\textbf{IETF (\textbf{2012}):} IETF RFC 6749 -- The OAuth 2.0
|
||
Authorization Framework, 2012, abgerufen am 19.03.2026,
|
||
\url{https://datatracker.ietf.org/doc/html/rfc6749}.
|
||
|
||
\bibitem[\citeproctext]{ref-jetbrains_rider}
|
||
\textbf{JetBrains (\textbf{2026}):} JetBrains Rider, 2026, abgerufen am
|
||
17.03.2026, \url{https://www.jetbrains.com/rider/}.
|
||
|
||
\bibitem[\citeproctext]{ref-livedesign}
|
||
\textbf{LiveDesign (\textbf{2026}):} LiveDesign -- Hosting, Design \&
|
||
Branding, 2026, abgerufen am 17.03.2026, \url{https://livedesign.at/}.
|
||
|
||
\bibitem[\citeproctext]{ref-andrewlock_token_lifetime}
|
||
\textbf{Lock, Andrew (\textbf{2024}):} Implementing custom token
|
||
providers for passwordless authentication in ASP.NET Core Identity,
|
||
2024, abgerufen am 19.03.2026,
|
||
\url{https://andrewlock.net/implementing-custom-token-providers-for-passwordless-authentication-in-asp-net-core-identity/\#changing-the-default-token-lifetime}.
|
||
|
||
\bibitem[\citeproctext]{ref-logrocket_dependency_inversion}
|
||
\textbf{LogRocket (\textbf{2024}):} Dependency Inversion Principle,
|
||
2024, abgerufen am 19.03.2026,
|
||
\url{https://blog.logrocket.com/dependency-inversion-principle/}.
|
||
|
||
\bibitem[\citeproctext]{ref-race_conditions_pdf}
|
||
\textbf{Maryland, University of (\textbf{2024}):} Race Conditions, 2024,
|
||
abgerufen am 19.03.2026,
|
||
\url{https://www.cs.umd.edu/projects/syschat/raceConditions.pdf}.
|
||
|
||
\bibitem[\citeproctext]{ref-ms_dependency_inversion}
|
||
\textbf{Microsoft (\textbf{2024a}):} Dependency Inversion, 2024,
|
||
abgerufen am 19.03.2026,
|
||
\url{https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles\#dependency-inversion}.
|
||
|
||
\bibitem[\citeproctext]{ref-ms_di_overview}
|
||
\textbf{Microsoft (\textbf{2024b}):} Dependency Injection Overview,
|
||
2024, abgerufen am 19.03.2026,
|
||
\url{https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection/overview}.
|
||
|
||
\bibitem[\citeproctext]{ref-aspnet_core_docs}
|
||
\textbf{Microsoft (\textbf{2026a}):} ASP.NET Core Documentation, 2026,
|
||
abgerufen am 17.03.2026,
|
||
\url{https://learn.microsoft.com/en-us/aspnet/core/}.
|
||
|
||
\bibitem[\citeproctext]{ref-blazor_docs}
|
||
\textbf{Microsoft (\textbf{2026b}):} Blazor Documentation, 2026,
|
||
abgerufen am 17.03.2026,
|
||
\url{https://learn.microsoft.com/en-us/aspnet/core/blazor/}.
|
||
|
||
\bibitem[\citeproctext]{ref-ef_core_migrations}
|
||
\textbf{Microsoft (\textbf{2026c}):} Entity Framework Core --
|
||
Migrations, 2026, abgerufen am 17.03.2026,
|
||
\url{https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/}.
|
||
|
||
\bibitem[\citeproctext]{ref-linkedin_auth_flow}
|
||
\textbf{Microsoft (\textbf{2026d}):} LinkedIn Developer Documentation --
|
||
Authorization Code Flow, 2026, abgerufen am 19.03.2026,
|
||
\url{https://learn.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow}.
|
||
|
||
\bibitem[\citeproctext]{ref-oodesign_dependency_inversion}
|
||
\textbf{OO Design (\textbf{2024}):} Dependency Inversion Principle,
|
||
2024, abgerufen am 19.03.2026,
|
||
\url{https://www.oodesign.com/dependency-inversion-principle}.
|
||
|
||
\bibitem[\citeproctext]{ref-oqtane_about}
|
||
\textbf{Oqtane Foundation (\textbf{2024a}):} About Oqtane, 2024,
|
||
abgerufen am 19.03.2026, \url{https://www.oqtane.org/\#about}.
|
||
|
||
\bibitem[\citeproctext]{ref-oqtane_docs_extensions}
|
||
\textbf{Oqtane Foundation (\textbf{2024b}):} Oqtane Extensions, 2024,
|
||
abgerufen am 19.03.2026,
|
||
\url{https://docs.oqtane.org/dev/extensions/index.html}.
|
||
|
||
\bibitem[\citeproctext]{ref-oqtane_docs_rendermodes}
|
||
\textbf{Oqtane Foundation (\textbf{2024c}):} Oqtane Render Modes, 2024,
|
||
abgerufen am 19.03.2026,
|
||
\url{https://docs.oqtane.org/guides/concepts/render-modes/index.html}.
|
||
|
||
\bibitem[\citeproctext]{ref-oqtane_framework_site}
|
||
\textbf{Oqtane Foundation (\textbf{2026a}):} Oqtane Framework, 2026,
|
||
abgerufen am 17.03.2026, \url{https://www.oqtane.org/}.
|
||
|
||
\bibitem[\citeproctext]{ref-oqtane_docs_dev}
|
||
\textbf{Oqtane Foundation (\textbf{2026b}):} Oqtane Developer
|
||
Documentation, 2026, abgerufen am 17.03.2026,
|
||
\url{https://docs.oqtane.org/}.
|
||
|
||
\bibitem[\citeproctext]{ref-questpdf}
|
||
\textbf{QuestPDF (\textbf{2026}):} QuestPDF Open Source Library, 2026,
|
||
abgerufen am 17.03.2026, \url{https://www.questpdf.com/}.
|
||
|
||
\bibitem[\citeproctext]{ref-wikipedia_blazor}
|
||
\textbf{Wikipedia (\textbf{2024}):} Blazor, 2024, abgerufen am
|
||
19.03.2026, \url{https://en.wikipedia.org/wiki/Blazor}.
|
||
|
||
\end{CSLReferences}
|
||
|
||
\end{document}
|