Architektur

1. Architektur des BKT-Managers und seine Interaktion mit Schulportal und Testcenter

Der BKT-Manager ist als Webkomponente in das Schulportal integriert und übernimmt die Verwaltung von Klassenanmeldungen, Codelisten und Testergebnissen. Dabei interagiert er mit zwei zentralen Systemen: dem Schulportal, das die Authentifizierung und Benutzerverwaltung übernimmt und dem Testcenter, das die Durchführung der Tests ermöglicht.

1.1. Interaktion mit dem Schulportal

Der BKT-Manager wird als Webkomponente direkt im Schulportal eingebunden. Das Schulportal stellt die zentrale Plattform für Lehrkräfte dar, über die sie auf den BKT-Manager zugreifen können.

• Authentifizierung und Autorisierung: Die Anmeldung erfolgt über das Schulportal. Sobald sich eine Lehrkraft oder eine Administratorin im Schulportal anmeldet, wird der AuthKey an den BKT-Manager übergeben. Der BKT-Manager überprüft diesen Schlüssel über eine Authentifizierungs-API und gewährt Zugriff auf die entsprechenden Funktionen.
• Nutzung innerhalb des Schulportals: Nach erfolgreicher Anmeldung können Lehrkräfte über den BKT-Manager Klassen für Tests anmelden, Codelisten generieren und Testergebnisse einsehen.
• Keine separate Anmeldung erforderlich: Da die Authentifizierung durch das Schulportal erfolgt, müssen sich Nutzer*innen nicht zusätzlich im BKT-Manager anmelden.

1.2. Kommunikation mit dem Testcenter

Das Testcenter ist die Plattform, auf der die Tests durchgeführt werden. Der BKT-Manager überträgt die erforderlichen Daten an das Testcenter und empfängt Testergebnisse zurück.

• Übertragung der Anmeldedaten: Sobald Lehrkräfte ihre Klassen im BKT-Manager registriert haben, werden die Anmeldedaten der Schüler*innen an das Testcenter übermittelt. Dies geschieht über eine API-Schnittstelle, die eine Datei mit den Anmeldeinformationen an das Testcenter sendet.
• Zugriff der Schüler*innen auf das Testcenter: Die Schüler*innen erhalten individuelle Codes, die im BKT-Manager generiert werden. Diese Codes ermöglichen den Login im Testcenter, ohne dass dort weitere manuelle Anmeldungen erforderlich sind.
• Rückmeldung der Testergebnisse: Nach Abschluss der Tests übermittelt das Testcenter die Ergebnisse zurück an den BKT-Manager. Lehrkräfte können diese Daten anschließend im Schulportal abrufen und auswerten.

1.3. Datenverwaltung im BKT-Manager

Der BKT-Manager verfügt über eine eigene Datenbank (DB-BKT), in der alle relevanten Informationen gespeichert werden.

• Speicherung von Klassenanmeldungen: Die angemeldeten Klassen werden in der BKT-Datenbank gespeichert, sodass Lehrkräfte jederzeit Änderungen vornehmen oder weitere Schüler*innen hinzufügen können.
• Codelistenerstellung: Beim Erstellen der Codelisten werden individuelle Codes für die Schüler*innen generiert und gespeichert. Diese Codes bleiben über alle Messzeitpunkte und Fächer hinweg gleich.
• Ergebnisse und Auswertungen: Testergebnisse, die vom Testcenter zurückgemeldet werden, werden in der BKT-Datenbank gespeichert. Diese Ergebnisse können sowohl vom BKT-Manager als auch vom Schulportal abgerufen und eingesehen werden.

2. Technologien

2.1. Backend

Das Backend des BKT-Managers basiert auf NestJS, einem modernen Framework für Node.js. Es nutzt TypeScript, um eine stabile und gut wartbare Serverarchitektur zu gewährleisten.

Technologien:

• TypeScript: Eine Erweiterung von JavaScript mit statischer Typprüfung für weniger Fehler.
• NestJS: Ein Framework, das eine modulare Struktur und einfache Erweiterbarkeit bietet.
• REST API: Ermöglicht die Kommunikation zwischen Backend und Frontend.

Wichtige verwendete Bibliotheken:

• @nestjs/jwt: JWT Token Generierung und Validierung
• @nestjs/typeorm: Verbindet die Anwendung mit der Datenbank
• class-validator: Prüft Eingaben auf Korrektheit
• axios: Ermöglicht externe API-Aufrufe

2.2. Frontend

Das Frontend des BKT-Managers wurde als Single Page Application (SPA) entwickelt. Es basiert auf Vue.js 3. Die Anwendung ist vollständig in TypeScript implementiert, was die Codequalität und Wartbarkeit durch statische Typisierung erhöht.

Technologien:

• Vue.js 3: Ein flexibles Framework für die Entwicklung von modernen Benutzeroberflächen
• Vite: Ein schneller Entwicklungsserver und Build-Tool für optimale Performance
• Pinia: Ein State Management System speziell für Vue.js, das eine Verwaltung des Anwendungszustands bietet.
• Vue Router: Ermöglicht das clientseitige Routing und die Navigation zwischen verschiedenen Seiten.

UI-Framework:

• Vuetify 3: Stellt vorgefertigte UI-Komponenten und Design bereit

Wichtige Bibliotheken:

• axios: Ein HTTP-Client für die Kommunikation mit dem Backend
• @vueuse/core: Enthällt eine Sammlung von Funktionen für Vue, die häufig benötigt werden
• vue-i18n: Ermöglicht mehrsprachige Inhalte
• @vuelidate/core: Ermöglicht eine umfangreiche clientseitige Formularvalidierung

2.3. Datenbank

Das BKT-Manager-System nutzt MySQL als Datenbankmanagementsystem. MySQL wurde aufgrund seiner Zuverlässigkeit und Performance gewählt.

Datenbankzugriff mit TypeORM

Für den Zugriff auf die Datenbank kommt TypeORM zum Einsatz, ein sogenannter Object-Relational Mapper (ORM). TypeORM erleichtert die Interaktion mit der Datenbank, indem es Tabellen als TypeScript-Klassen darstellt und dadurch einen typsicheren und strukturierten Zugriff ermöglicht.

Besonderheiten der Implementierung

• Alle Datenbankzugriffe erfolgen ausschließlich über TypeORM Repositories, um eine klare und einheitliche Struktur zu gewährleisten.
• Automatische Validierungen stellen sicher, dass nur gültige und korrekt formatierte Daten gespeichert werden.
• Durch den Einsatz von Migrations bleiben Änderungen am Datenbankschema reproduzierbar und nachvollziehbar.

3. Schnittstellen und Kommunikation

Interne Schnittstellen:

• Beschreibung der Kommunikation zwischen Frontend und Backend: https://bkt.ktest.de/api

Externe Schnittstellen:

• Beschreibung der Kommunikation mit dem Testcenter: https://pages.cms.hu-berlin.de/iqb/testcenter/dist/api/index.html
• Beschreibung der Kommunikation mit dem KT-Schulportal: https://api.inio.de/report_data#/Informations/get_surveys

4. Sicherheit

4.1. Authentifizierung und Autorisierung

Als Webkomponente des kompetenztest.de Portals nutzt der BKT-Manager dessen Authentifizierungsinfrastruktur und erweitert diese um eigene Sicherheitsmechanismen.

Authentifizierungsablauf

Die Authentifizierung erfolgt in zwei Stufen:

1. Primäre Authentifizierung Der erste Authentifizierungsschritt erfolgt über das kompetenztest.de Portal. Nutzer authentifizieren sich dort mit ihren Zugangsdaten und erhalten bei erfolgreicher Anmeldung einen KT-Token (kompetenztest.de Token). Dieser Token wird automatisch an den BKT-Manager weitergeleitet und dient als Nachweis der erfolgreichen Portal-Authentifizierung.

2. BKT-spezifische Authentifizierung In der zweiten Stufe übernimmt der BKT-Manager die Authentifizierung. Das Backend prüft zunächst die Gültigkeit des übermittelten KT-Tokens. Nach erfolgreicher Validierung generiert das System einen eigenen JWT Token (JSON Web Token). Dieser Token wird für die gesamte weitere Kommunikation zwischen Frontend und Backend des BKT-Managers verwendet und stellt sicher, dass alle Anfragen authentifiziert und autorisiert sind.

Das System unterscheidet dabei zwei Zugriffsarten:

• SCHOOL: Für Lehrkräfte, die über das Schulportal zugreifen
• ADMIN: Für administrative Zugriffe über das Administrationsportal

Sicherheitsmechanismen

Die Sicherheit wird durch mehrere Ebenen gewährleistet:

• Validierung der KT-Authentifizierung
• Interne Zugriffskontrolle durch JWT
• Rollenbasierte Berechtigungen
• Geschützte API-Endpunkte

4.2. Datenschutz

Der BKT-Manager speichert keine personenbezogenen Daten wie Namen von Schüler*innen auf dem Server. Gleichzeitig ist es für Lehrkräfte wichtig, die Codes der Schüler*innen nachvollziehen zu können, um z.B. Testergebnisse richtig zuzuordnen.

Daher wurde eine Lösung entwickelt, die es ermöglicht, mit Namen zu arbeiten, ohne diese im System zu hinterlegen:

• Bei der erstmaligen Erstellung einer Codeliste können die Namen der Schüler*innen lokal erfasst werden.
• Die Namen werden nicht im System gespeichert, sondern in einer JSON-Datei exportiert. Diese Datei bleibt lokal auf dem Gerät der Lehrkraft und kann bei Bedarf wieder eingelesen werden.
• Dadurch entfällt eine erneute Eingabe der Namen bei weiteren Testungen oder Fächern.
• Neue Schüler*innen können bei einem späteren Import ergänzt werden.

5. Architekturentscheidungen

5.1. Eigenständige Applikation

Die Entscheidung, den BKT-Manager als eigenständige Anwendung zu entwickeln, basiert auf mehreren Faktoren:

• Die neuen Tests unterscheiden sich stark von den bisherigen Kompetenztests. Eine direkte Integration in das bestehende System hätte umfangreiche Anpassungen erfordert. Da der BKT ein Pilotprojekt ist, wollten wir zunächst die Praxistauglichkeit der neuen Tests evaluieren, bevor größere Änderungen am bestehenden System vorgenommen werden.
• Durch die entkoppelte Umsetzung kann der BKT-Manager flexibel in verschiedene Schulportale integriert werden, ohne tiefgehende Anpassungen an bestehenden Systemen oder Technologien vornehmen zu müssen. Selbst wenn Schulportale anderer Länder mit einer anderen technologischen Basis arbeiten, entstehen keine Konflikte in Design oder Funktionalität.
• Für Lehrkräfte bleibt die Nutzung nahtlos: Technisch gesehen betreten sie eine abgekapselte Umgebung, ohne dass dies in der Benutzererfahrung spürbar wird.

5.2. Datenschutzstrategie zur Zuordnung von Codes und Namen

Um den Datenschutz zu gewährleisten und gleichzeitig eine Zuordnung von Codes zu Namen zu ermöglichen, wurde von Schleswig-Holstein folgende Strategie gewählt:

• Die Namen der Schüler*innen werden in einer lokalen JSON-Datei gespeichert, die auf dem Gerät der Lehrkraft verbleibt. Dadurch bleiben die sensiblen Daten unter der Kontrolle der Lehrkraft und werden nicht auf externen Servern gespeichert.

Alternative Überlegung: Eine mögliche Alternative wäre die verschlüsselte Speicherung der Namen auf den Servern von kompetenztest.de. In diesem Szenario würden die Daten mit einem Passwort gesichert, das nur der Lehrkraft bekannt ist. Eine Entschlüsselung wäre dann nur lokal im Browser möglich. Diese Lösung wurde jedoch verworfen.