@@ -350,7 +350,7 @@ Die agile Arbeitsweise von Scrum basiert auf einer iterativen und inkrementellen
|
||||
|
||||
Die grundlegende Struktur und der Ablauf eines Scrum-Projekts sind in Abbildung X dargestellt.
|
||||
|
||||
|
||||
|
||||
_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.
|
||||
|
||||
@@ -466,7 +466,7 @@ OAuth 2.0 basiert auf dem Prinzip der delegierten Autorisierung. Dabei erlaubt e
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
@@ -610,7 +610,7 @@ Der Lebenszyklus eines Antrags durchläuft mehrere Phasen. Der Benutzer beginnt
|
||||
|
||||
Beim Absenden des Formulars erstellt die clientseitige Methode `SubmitApplication` ein neues `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 `ApplicationId`, ob ein neuer Antrag über den Service `AddApplicationAsync` erstellt oder ein bestehender über `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 `ApplicationService`, der als HTTP-Client die Anfragen an den REST-Controller weiterleitet.
|
||||
|
||||
|
||||
|
||||
|
||||
Serverseitig nimmt die Methode `AddApplicationAsync` im `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.
|
||||
|
||||
@@ -620,7 +620,7 @@ Ein Administrator kann den Antrag entweder genehmigen oder ablehnen. Bei einer G
|
||||
|
||||
Die Antrags-Listenansicht bildet das zweite zentrale Feature. Premium-Mitglieder sehen alle genehmigten und veröffentlichten Anträge in einer übersichtlichen Kartenansicht. Jede Karte enthält den Titel, den Namen des Autors, die Kurzbeschreibung und das Veröffentlichungsdatum. Über integrierte Schaltflächen können die zugehörigen PDF-Dokumente direkt im Browser betrachtet oder heruntergeladen werden. Der PDF-Viewer wird als modales Fenster mit eingebettetem iFrame realisiert.
|
||||
|
||||
|
||||
|
||||
|
||||
Die serverseitige Methode `GetApplicationsAsync` steuert dabei die rollenbasierte Zugriffslogik und entscheidet, welche Anträge ein Benutzer sehen darf:
|
||||
|
||||
@@ -661,7 +661,7 @@ Administratoren erhalten alle Anträge zurück. Für andere Benutzer werden zun
|
||||
|
||||
Die Mitgliedersuche ermöglicht Premium-Mitgliedern das gezielte Auffinden anderer registrierter Benutzer. Die clientseitige Blazor-Komponente `UserSearch.razor` stellt ein Eingabefeld bereit, über das der Benutzer seinen Suchbegriff eingibt. Bei jeder Suche wird der eingegebene Text an den `ServerUserContactService` auf dem Server übermittelt, der die eigentliche Suchlogik implementiert.
|
||||
|
||||
|
||||
|
||||
|
||||
Die serverseitige Methode `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.
|
||||
|
||||
|
||||
@@ -495,7 +495,7 @@ Das Modul "Schwarzes Brett" dient als digitale Anschlagtafel für den Absolvente
|
||||
|
||||
#### Struktur und Anzeige
|
||||
|
||||
{ latex-placement="ht" }
|
||||
{ latex-placement="ht" }
|
||||
|
||||
<!-- ![Detailansicht eines Eintrags auf dem Schwarzen Brett][img-ref] -->
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 351 KiB After Width: | Height: | Size: 351 KiB |
|
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 471 KiB After Width: | Height: | Size: 471 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 508 KiB After Width: | Height: | Size: 508 KiB |
|
Before Width: | Height: | Size: 344 KiB After Width: | Height: | Size: 344 KiB |