adolfus
This commit is contained in:
parent
e0cf0887a6
commit
29d88205f9
1 changed files with 28 additions and 46 deletions
74
aufgaben.txt
74
aufgaben.txt
|
|
@ -1,54 +1,36 @@
|
|||
3.1 Zusammenfassung der Aufgaben
|
||||
Das Projekt „Ticketsystem für Raumbetreuer“ wurde auf Grundlage der vorgegebenen Aufgabenstellung als mehrschichtige Webanwendung konzipiert.
|
||||
Zentrale Vorgabe war die Entwicklung einer webbasierten Lösung, mit der Lehrkräfte technische Probleme melden und Raumbetreuer diese strukturiert bearbeiten können. Dabei sollten eine klare Trennung der Systemkomponenten, die Einhaltung von Datenschutzanforderungen sowie eine rollenbasierte Zugriffskontrolle umgesetzt werden.
|
||||
Gemäß den Anforderungen wurde das System in Frontend, Backend und Datenhaltung unterteilt. Ziel dieser Architektur war es, eine saubere Trennung zwischen Benutzeroberfläche, Geschäftslogik und persistenter Datenhaltung zu realisieren und gleichzeitig ein effizientes Zusammenspiel aller Komponenten sicherzustellen.
|
||||
Das Frontend dient als zentrale Benutzerschnittstelle für Lehrkräfte und Raumbetreuer. Über dieses können Lehrkräfte Tickets mit den vorgegebenen Pflichtangaben (Raum, Titel, Beschreibung) erfassen sowie ihre eigenen Tickets tabellarisch einsehen. Raumbetreuer erhalten eine Übersicht aller Tickets der von ihnen betreuten Räume und können den Bearbeitungsstatus gemäß den Vorgaben („offen“, „in Bearbeitung“, „fertig“) ändern.
|
||||
Das Backend übernimmt die Verarbeitung der vom Frontend gesendeten Anfragen, die Umsetzung der Geschäftslogik sowie die serverseitige Prüfung von Rollen- und Zugriffsrechten. Dadurch wird sichergestellt, dass Lehrkräfte und Raumbetreuer ausschließlich die für sie vorgesehenen Funktionen nutzen können. Die Kommunikation zwischen Frontend und Backend erfolgt über eine REST-Schnittstelle, wobei der Datenaustausch ausschließlich im JSON-Format stattfindet, wie in der Aufgabenstellung gefordert.
|
||||
Die Datenhaltung erfolgt in einer relationalen PostgreSQL-Datenbank. Diese speichert unter anderem Benutzerinformationen, Rollen, Räume sowie Ticketdaten inklusive Status und Zeitstempeln. Durch die Normalisierung des Datenmodells werden Redundanzen vermieden und eine konsistente Datenbasis gewährleistet.
|
||||
Alle Teilaufgaben greifen funktional ineinander:
|
||||
Benutzereingaben werden im Frontend erfasst, über die REST-Schnittstelle an das Backend übertragen, dort validiert und verarbeitet und anschließend in der Datenbank gespeichert oder aus dieser abgerufen. Die vom Backend bereitgestellten Daten werden im Frontend strukturiert dargestellt. Dadurch entsteht ein in sich geschlossenes, nachvollziehbares Gesamtsystem, das die in der Aufgabenstellung definierten Anforderungen vollständig abbildet.
|
||||
Das Projekt „Ticketsystem für Raumbetreuer“ wurde als praxisnahe Abschlussarbeit konzipiert, um den vollständigen Entwicklungszyklus einer modernen Webanwendung abzubilden.
|
||||
Die Kernaufgabe bestand darin, eine Plattform zu schaffen, auf der Lehrkräfte technische Mängel in Räumen melden können, während Raumbetreuer diese zentral verwalten und bearbeiten. Dabei lag der Fokus auf einer strikten Trennung der Verantwortlichkeiten, Datensicherheit und einer intuitiven Bedienbarkeit.
|
||||
Die Architektur wurde gemäß moderner Standards in Frontend (Next.js), Backend (Spring Boot) und Datenbank (PostgreSQL) unterteilt. Dies ermöglichte uns, die theoretischen Kenntnisse der Ausbildung – von der Datenbankmodellierung bis hin zur Integration von REST-Schnittstellen – praktisch anzuwenden.
|
||||
|
||||
3.2 Teilaufgabe – Erstellung der Webseite (Frontend)
|
||||
Herr Milkovic wurde mit der Konzeption und Umsetzung des Frontends beauftragt. Ziel dieser Teilaufgabe war die Entwicklung einer übersichtlichen und benutzerfreundlichen Weboberfläche, über welche Lehrkräfte und Raumbetreuer das Ticketsystem nutzen können.
|
||||
Das Frontend wurde mit React unter Verwendung von TypeScript umgesetzt. Die Entscheidung für TypeScript wurde getroffen, um eine höhere Typensicherheit zu gewährleisten und die Wartbarkeit des Codes zu verbessern. Die Anwendung ist komponentenbasiert aufgebaut, wodurch einzelne Funktionseinheiten klar voneinander getrennt und wiederverwendbar sind.
|
||||
Für die Benutzerverwaltung und Anmeldung wurde NextAuth eingesetzt. Dieses Authentifizierungssystem ermöglicht eine sichere Anmeldung und Sitzungsverwaltung, sodass sich Nutzer nicht bei jeder Nutzung erneut anmelden müssen. Die Authentifizierungsinformationen werden dabei sicher verarbeitet und im Frontend für rollenabhängige Ansichten genutzt.
|
||||
Die Benutzeroberfläche umfasst unter anderem:
|
||||
• eine Anmelde- und Registrierungsansicht,
|
||||
• eine Ticketübersicht in tabellarischer Form,
|
||||
• Formulare zur Erstellung neuer Tickets,
|
||||
• Funktionen zur Anzeige und Aktualisierung des Ticketstatus.
|
||||
Das Design der Anwendung wurde bewusst schlicht und funktional gehalten, um eine intuitive Bedienung zu ermöglichen. Die Navigation erfolgt über ein zentrales Menü, über das alle relevanten Funktionen erreichbar sind.
|
||||
Die Kommunikation mit dem Backend erfolgt über eine REST-API. Der Datenaustausch findet ausschließlich im JSON-Format statt. Während der Entwicklung wurde das Frontend regelmäßig getestet und schrittweise erweitert.
|
||||
Herr Milkovic übernahm die Konzeption und Realisierung des Frontends. Das Ziel war eine moderne Single-Page-Application (SPA), die sowohl auf Desktop- als auch auf mobilen Endgeräten performant läuft.
|
||||
Als Technologie wurde Next.js (React-Framework) mit TypeScript gewählt. TypeScript war hier besonders wertvoll, da es durch die statische Typisierung viele Fehler bereits zur Entwicklungszeit verhinderte und die Zusammenarbeit im Team durch klare Schnittstellendefinitionen erleichterte.
|
||||
Für ein professionelles Look-and-Feel wurde die Komponentenbibliothek "Shadcn UI" in Verbindung mit Tailwind CSS genutzt. Dies sparte viel Entwicklungszeit beim Styling und sorgte für eine konsistente Designsprache.
|
||||
Herausfordernd war die Integration von NextAuth.js für die Authentifizierung, da hier sichergestellt werden musste, dass der Benutzerstatus (Lehrer vs. Raumbetreuer) korrekt vom Backend übernommen und in der UI berücksichtigt wird.
|
||||
|
||||
3.3 Teilaufgabe – Implementierung des Backends
|
||||
Die Implementierung des Backends wurde von Herr Buchkamer übernommen. Ziel dieser Teilaufgabe war die Bereitstellung einer stabilen serverseitigen Anwendung zur Verarbeitung der Anfragen aus dem Frontends sowie zur Verwaltung der Projektdaten.
|
||||
Das Backend wurde mit Java und dem Framework Spring Boot umgesetzt. Spring Boot bietet eine strukturierte Grundlage für die Entwicklung von REST-basierten Anwendungen und unterstützt eine klare Trennung der Anwendung in logische Schichten.
|
||||
Die Backend-Architektur ist in folgende Schichten unterteilt:
|
||||
• Controller-Schicht zur Bereitstellung der REST-Endpunkte und zur Entgegennahme der Anfragen aus dem Frontend,
|
||||
• Service-Schicht zur Umsetzung der Geschäftslogik und zur Koordination der Anwendungsabläufe,
|
||||
• Repository-Schicht zur Kapselung des Datenbankzugriffs,
|
||||
• Entity-Schicht zur Abbildung der fachlichen Datenmodelle.
|
||||
Die Authentifizierung und Autorisierung der Nutzer erfolgte in Zusammenarbeit mit dem Frontend über eine gesicherte Schnittstelle. Benutzerrollen wie Lehrkraft und Raumbetreuer werden serverseitig geprüft, um unzulässige Zugriffe zu verhindern und die Sicherheit der Anwendung zu gewährleisten.
|
||||
Herr Buchkamer war für das Backend verantwortlich. Hierbei kam Java mit dem Spring Boot Framework (Version 3.2.2) zum Einsatz.
|
||||
Die Backend-Entwicklung umfasste:
|
||||
• Design und Implementierung der REST-API Endpunkte.
|
||||
• Umsetzung der Geschäftslogik (z.B. Ticket-Statusübergänge).
|
||||
• Sicherheitskonfiguration mittels Spring Security (Passwort-Hashing mit BCrypt).
|
||||
• Datenbankanbindung über Spring Data JPA.
|
||||
Besonderes Augenmerk lag auf der Validierung eingehender Daten, um inkonsistente Zustände in der Datenbank zu verhindern.
|
||||
|
||||
3.4 Teilaufgabe – Datenbankkonzeption und Umsetzung
|
||||
Als Datenbanksystem wurde PostgreSQL eingesetzt. Die Datenbank stellt einen zentralen Bestandteil des Projekts dar, da sie die dauerhafte Speicherung aller relevanten Informationen übernimmt.
|
||||
Gespeichert werden unter anderem:
|
||||
Benutzerdaten (z. B. Name, E-Mail-Adresse, Rolle),
|
||||
Ticketdaten (Raum, Titel, Beschreibung, Status, Erstellungsdatum),
|
||||
Zuordnungen zwischen Raumbetreuern und ihren betreuten Räumen.
|
||||
Die Datenbank wurde relational und normalisiert aufgebaut, um Redundanzen zu vermeiden und konsistente Daten sicherzustellen. Der Zugriff auf die Datenbank erfolgt ausschließlich über das Backend unter Verwendung eines ORM-Frameworks (JPA/Hibernate), wodurch direkte SQL-Abfragen im Anwendungscode vermieden werden.
|
||||
3.4 Teilaufgabe – Datenbankkonzeption
|
||||
Als persistenter Datenspeicher diente PostgreSQL. Das Datenmodell wurde vor der Implementierung in einem Entity-Relationship-Modell (ERM) geplant und anschließend normalisiert (3. Normalform), um Redundanzen zu vermeiden.
|
||||
Wichtige Entitäten waren User, Tickets, Rooms und Comments. Die Beziehungen (z.B. ein User betreut mehrere Räume) wurden über entsprechende Fremdschlüssel und Join-Tables (n:m Beziehungen) realisiert.
|
||||
|
||||
3.5 Abweichungen, Anpassungen und Entscheidungen
|
||||
Im Verlauf des Projekts wurden mehrere bewusste technische Entscheidungen getroffen, um die Anforderungen effizient und praxisnah umzusetzen:
|
||||
• Einsatz von React mit TypeScript im Frontend
|
||||
Diese Kombination wurde gewählt, um eine moderne, wartbare und erweiterbare Benutzeroberfläche zu realisieren. TypeScript unterstützt zusätzlich die Fehlervermeidung durch statische Typisierung und erleichtert die Weiterentwicklung des Codes.
|
||||
• Verwendung von NextAuth für die Authentifizierung
|
||||
NextAuth wurde eingesetzt, da es eine sichere und etablierte Lösung für die Anmeldung von Nutzern bietet und eine persistente Sitzung ermöglicht. Dadurch konnte der Authentifizierungsprozess zuverlässig umgesetzt werden.
|
||||
• Trennung von Frontend und Backend
|
||||
Die klare Trennung der beiden Komponenten wurde bewusst gewählt, um eine saubere Architektur zu gewährleisten. Dies erleichtert sowohl die Wartung als auch mögliche zukünftige Erweiterungen der Anwendung.
|
||||
• Verwendung von PostgreSQL als Datenbank
|
||||
PostgreSQL wurde aufgrund seiner Stabilität und seiner Eignung für relationale Datenmodelle ausgewählt. Die Datenbank ermöglicht eine strukturierte Speicherung der Tickets und Benutzerdaten.
|
||||
3.5 Probleme, Lösungen und Fazit
|
||||
Wie in jedem Entwicklungsprojekt lief nicht alles reibungslos. Wir sahen uns mit einigen technischen Hürden konfrontiert, die wir jedoch lösen konnten.
|
||||
|
||||
Während der Umsetzung traten Probleme bei der Kommunikation zwischen Frontend und Backend auf, insbesondere im Zusammenhang mit der CORS-Konfiguration. Dieses Problem konnte durch gezielte Anpassungen im Code behoben werden, sodass die Kommunikation anschließend fehlerfrei funktionierte.
|
||||
Insgesamt erwiesen sich die getroffenen Entscheidungen als sinnvoll und trugen maßgeblich zum erfolgreichen Abschluss des Projekts bei.
|
||||
Größere inhaltliche Abweichungen von der Aufgabenstellung traten nicht auf. Die Kernanforderungen wurden vollständig umgesetzt und bilden eine solide Grundlage für eine spätere Erweiterung des Systems.
|
||||
CORS (Cross-Origin Resource Sharing):
|
||||
Ein hartnäckiges Problem war die CORS-Policy. Da Frontend und Backend in der Entwicklungsumgebung (und auch im Docker-Setup) auf unterschiedlichen Ports bzw. Domains laufen, blockierte der Browser zunächst die API-Anfragen. Wir mussten uns intensiv mit der `SecurityConfig` in Spring Boot auseinandersetzen, um die korrekten Header und Origins freizugeben, ohne dabei Sicherheitslücken zu öffnen.
|
||||
|
||||
Login / Authentifizierung:
|
||||
Das größte Problem trat kurz vor der Abgabe auf: Der Login-Prozess funktionierte plötzlich nicht mehr zuverlässig. Es gab Schwierigkeiten bei der Sitzungsübergabe zwischen NextAuth (Frontend) und dem Spring Security Backend. Teilweise wurden Benutzer trotz korrekter Daten abgelehnt oder die Rolle wurde nicht richtig übertragen.
|
||||
Wir mussten in einer "Nachtschicht" kurz vor dem Deadline-Termin den gesamten Authentifizierungs-Flow debuggen. Letztendlich lag es an einem Detail in der Token-Verarbeitung und der Cookie-Konfiguration. Glücklicherweise konnten wir den Fehler rechtzeitig finden und beheben, sodass zur Präsentation ein funktionierendes System bereitstand.
|
||||
|
||||
Fazit:
|
||||
Trotz dieser Schwierigkeiten sind wir stolz auf das Ergebnis. Das Projekt hat uns gezeigt, wie wichtig saubere Schnittstellenabsprachen und frühzeitiges Testen (insbesondere von Integrationspunkten wie Login) sind. Wir haben als angehende Fachinformatiker viel über das Zusammenspiel komplexer Frameworks gelernt.
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue