foo
This commit is contained in:
parent
0b5ecf12d5
commit
e0cf0887a6
1 changed files with 54 additions and 0 deletions
54
aufgaben.txt
Normal file
54
aufgaben.txt
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.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.
|
||||
|
||||
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.
|
||||
Loading…
Add table
Reference in a new issue