Dokumentation - Zweiter Entwurf
Entwurf2.pdf





Planung, Implementierung, Test und Einführung eines web-basierten Notenerfassungssystems






Besondere Lernleistung

Technikwissenschaft

Dokumentation:





MVC-Framework und Benutzeroberfläche
Maximilian Weller

Datenbankdesign und Klassenstruktur
Moritz Willig














Betreut von: A. Rohde, B. Meuser Werner-von-Siemens-Schule Wetzlar 2012/13
















Copyright © 2012-2013 Max Weller, Moritz Willig


This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/.



Weitere Informationen, eine stets aktuelle Version dieses Dokuments sowie den Quelltext der Software finden Sie auch unter http://notendb-hilfe.wikilab.de/





Einführung

Thema dieser Besonderen Lernleistung ist die Entwicklung einer Notenerfassungssoftware. In diesem Dokument beschreiben wir die Entstehung und Implementierung dieser Software sowie die technischen und organisatorischen Hintergründe. Die entstandene Software trägt den internen Namen notendb2, der sich auch in der Dokumentation wiederfindet.

Hintergrund und Entstehung

Bereits Ende 2011 kam Herr Rohde mit der Idee auf uns zu, eine Verwaltungssoftware für Zeugnisnoten zu erstellen. Wir erstellten erste Entwürfe eines Datenbankschemas und entwickelten einen Prototyp für die Benutzeroberfläche. Dieser hieß notendb1, daher rührt die Bezeichnung der aktuellen Version notendb2.

Im Mai 2012 besprachen wir im Rahmen eines Treffens mit Herrn Hunke, Herrn Rohde und Herrn Meuser die Details des Projektes und begannen mit der eigentlichen Planung und Implementierung des Projekts. Besonderen Wert haben wir während der gesamten Entwicklungsdauer auf die kontinuierliche Zusammenarbeit mit den künftigen Nutzern der Software gelegt, also mit den Lehrern, insbesondere den Tutoren, des Beruflichen Gymnasiums.
Durch das frühe Testen von Prototypen war es möglich, Fehler in der Planung frühzeitig zu erkennen.[1] Auch einige Bugs, also Fehler in der Implementierung, wurden durch die Nutzer entdeckt und konnten so zeitnah behoben werden.[2]
Auch später erhielten wir regelmäßig Feedback, Verbesserungsvorschläge und konstruktive Kritik, die es ermöglichte, die Software benutzerfreundlicher zu gestalten und auf die Wünsche und Bedürfnisse der künftigen Nutzer einzugehen.


Verwendete Typographie

In dieser Arbeit werden zum besseren Verständnis folgende typographische Konventionen befolgt:
  • Datei- und Ordnernamen und -pfade sowie technische Bezeichnungen werden kursiv dargestellt.
  • Programmcode-Ausschnitte, Funktions- und Klassennamen, Namen von Datenbanktabellen und -attributen sowie Konsolenein- und ausgaben werden in Nichtproportionalschrift dargestellt.

Problemstellung

Im Folgenden beschreiben wir detailliert das Problem, welches wir bearbeitet haben. Auf einige der nummerierten Punkte wird später verwiesen, um gesondert auf ihre Umsetzung einzugehen.

Datenbanksystem

Die für die Zeugnisse des Beruflichen Gymnasiums der Werner-von-Siemens-Schule erforderlichen Daten, also Noten und Fehlstunden, sollen in einer Datenbank zur späteren Weiterverarbeitung erfasst werden.
1 Die Lehrer der Schule sollen verwaltet werden und die Möglichkeit haben, sich mit einem Kürzel und einem Passwort am System anzumelden.
2 Zu jedem Lehrer sollen Anrede, Titel, Vorname, Name und Kürzel gespeichert werden. Ferner soll gespeichert werden, ob es sich um einen Administrator handelt.
3 Zur einfacheren Handhabung sollen Kursvorlagen verwaltet werden, aus denen Kurse abgeleitet werden können.
4 Zu jeder Kursvorlage soll das Fach, das Thema, die Art des Kurses (Grundkurs / Leistungskurs), die Anzahl der Wochenstunden sowie eine Sortierreihenfolge und die Ausgabezeile auf dem Zeugnis gespeichert werden.

5 Es sollen Schüler und Kurse verwaltet werden, wobei ein Schüler an mehreren Kursen teilnehmen kann, und ein Kurs mehrere teilnehmende Schüler haben kann.
6 Zu jeder Kursteilnahme soll eine Zeugnisnote, die Anzahl der Fehlstunden sowie die Anzahl der unentschuldigten Fehlstunden verwaltet werden.
7 Zu jedem Kurs sollen die gleichen Daten wie zu einer Kursvorlage gespeichert werden, da diese zur Archivierung kopiert werden.
8 Außerdem soll zu jedem Kurs gespeichert werden, aus welcher Kursvorlage er erstellt wurde.
9 Des Weiteren sollen die Kursleiter (Lehrer) verwaltet werden, wobei ein Lehrer mehrere Kurse leiten kann, aber auch ein Kurs mehrere Kursleiter haben kann.
10 Die Schüler, Kurse und Zuordnungen sollen für jede Jahrgangsstufe in einem jeden Schulhalbjahr in einem unabhängigen Datenbestand („Datei”) verwaltet werden, um die Daten leichter archivieren zu können.
11 Jeder Datei werden durch den Administrator ein oder mehrere Lehrer zugeordnet, die für die Verwaltung dieser Datei zuständig sind („Tutor“). Ein Lehrer kann Tutor für mehrere Dateien sein.

Weiterverarbeitung

12 Die eingegebenen Daten sollen von den Tutoren zur weiteren Verwendung exportiert werden können.
13 Hierbei soll eine Auswahl der Daten nach Tutorengruppe möglich sein.
14 Die Daten sollen allgemeine Angaben zum Schüler, die Liste seiner belegten Kurse, die Lehrer, Themen und Noten in diesen Kursen sowie die Summe der entschuldigten und Gesamtfehlstunden enthalten.
15 Die Daten sollen zur Ausgabe eines Zeugnisses geeignet sein, beispielsweise mit der Seriendruck-Funktion von Microsoft Word.

Weitere Anforderungen und Ziele

16 Der Zugriff auf das System soll von verschiedenen schulinternen Computerarbeitsplätzen, eventuell auch von Lehrernotebooks, möglich sein.
17 Installations- und Wartungsaufwand an den Arbeitsplatzrechnern soll möglichst gering sein.
18 Die Software soll möglichst bedienerfreundlich sein, sodass auch Computerlaien sie nach Einweisung verwenden können.

Sicherheit

Aufgrund der sensiblen Daten, die mit dieser Software verwaltet werden, soll besonderer Wert auf Datenschutz und Sicherheit gelegt werden.
19 Jeder Benutzer muss mit Benutzername und Passwort authentifiziert werden.
20 Nur autorisierte Benutzer (Lehrer) sollen Zugang zu den Daten erhalten.
21 Lehrer sollen nur Zugang zu Daten ihrer eigenen Kurse erhalten.
22 Tutoren sollen Zugang zu Daten einer Tutorengruppe bzw. einer Jahrgangsstufe erhalten.
23 Die Verbindung zur Software über das Netzwerk soll mit einer gesicherten Verbindung erfolgen, um das Ausspähen von Zugängen oder Daten zu verhindern.
24 Die Software sollte nach Möglichkeit nicht anfällig für gängige Angriffsmethoden[3] sein.

Client-Server-Prinzip

Um die Anforderungen 16 und 17 zu erfüllen und dabei sicherzustellen, dass die Daten stets überall in der aktuellsten Version vorliegen, ist die Implementierung als Client-Server-Architektur auf Basis des HTTP-Protokolls naheliegend. Wir haben uns also dazu entschieden, die Software als serverseitige PHP-Anwendung zu entwickeln, die ihre Dienste über einen Apache-Webserver und das von diesem implementierte HTTP-Protokoll einem Web-Browser zur Verfügung stellt. Dies hat den großen Vorteil, dass auf den Client-Systemen außer einem (standardmäßig vorhandenen) Web-Browser keine weitere Software installiert und aktuell gehalten werden muss. Außerdem kann so Anforderung 23 leicht erfüllt werden, indem HTTPS aktiviert wird.

Verwendete Programmiersprachen, Techniken und Module

Serverseitig kommt die Programmiersprache PHP[4] (kurz für PHP: Hypertext Preprocessor) zum Einsatz. Diese wählten wir, da sie die am weitesten verbreitete und am häufigsten eingesetzte Sprache zum Erstellen von Websites und -anwendungen ist, als freie Software kostenfrei einsetzbar ist und wir bereits gute Kenntnisse darin besaßen. Außerdem ist PHP plattformunabhängig und leicht einzurichten. Es sind jedoch auch einige Unzulänglichkeiten aufzuführen, wie die teilweise fehlerträchtige schwache Typisierung, und die historisch gewachsene und daher meist nicht objektorientierte Standardbibliothek. Letzteres kann jedoch durch Entwicklung von objektorientierten Wrapperklassen für wichtige Bereiche wie den Datenbankzugriff behoben werden. Dies haben wir in unserem selbst entwickelten Framework, welches im nächsten Kapitel beschrieben wird, umgesetzt.
Die verhältnismäßig geringe Ausführungsgeschwindigkeit von PHP-Skripten stellt in dieser Anwendung dagegen kein Problem dar, da die Anzahl der Aufrufe, verglichen mit anderen Anwendungsfällen, extrem gering ist.

Zur Datenhaltung nutzen wir das relationale Datenbankverwaltungssystem MySQL[5], welches ebenfalls zu den am weitesten verbreiteten zählt. Es ist wie PHP als freie Open-Source-Software verfügbar.

Clientseitig werden, wie es bei Webanwendungen zwangsläufig der Fall ist, HTML, CSS und JavaScript eingesetzt. Bei HTML (kurz für Hypertext Markup Language) handelt es sich um eine „Auszeichnungssprache zur Strukturierung von Inhalten”[6]. Cascading Style Sheets (CSS) sind die dazu gehörige Sprache für Formatvorlagen, die nötig ist, um die Ausgabe zu gestalten.

JavaScript wird in unserer Anwendung nur vereinzelt genutzt, hauptsächlich um Eingabeüberprüfungen und ähnliche Aufgaben bereits clientseitig vornehmen zu können und somit durch schnellere Rückmeldungen die Benutzerfreundlichkeit zu erhöhen. Wir verwenden zur besseren Browserkompatibilität und zur Erleichterung der Entwicklung die JavaScript-Bibliothek jQuery[7].


Verwendete Entwicklertools

Zur Versionsverwaltung und Sicherung des Quellcodes verwenden wir Git, eine “freie Software zur verteilten Versionsverwaltung von Dateien”[8].
Zum Bearbeiten des Quellcodes verwendeten wir die Editoren Notepad++[9], ScriptIDE[10] und Sublime Text[11]. Der Serverzugriff fand außerdem mit ssh[12], PuTTY[13] und WinSCP[14] statt. Zum Datenbankzugriff wurde Adminer[15] und Sequel Pro[16] benutzt.

Zur Kommunikation während der Entwicklung untereinander haben wir meist Skype eingesetzt. Der Austausch mit den Benutzern fand sowohl persönlich in der Schule als auch per E-Mail statt.


2 MVC-Framework

Code-Architektur

Das Projekt ist nach dem in der Softwareentwicklung seit über 30 Jahren verbreiteten Model-View-Controller-Konzept[17] strukturiert. Dieses Konzept erleichtert die spätere Erweiterung der Software sowie die Anpassung an geänderte Anforderungen. Es hat sich während der Entwicklung der Anwendung bereits bewährt, da Wünsche und Feedback der Nutzer sowohl während als auch nach der Entwicklung schnell umgesetzt werden konnten.

Das Model-View-Controller-Konzept

Beim MVC-Konzept wird ein Programm in die drei Komponenten Model, Controller und View unterteilt. Die Aufgaben dieser Komponenten werden von verschiedenen Umsetzungen stark unterschiedlich interpretiert. Die Übergänge sind nicht mehr so klar definiert wie bei der ersten Beschreibung des Konzepts, die im Rahmen der Entwicklung von “Smalltalk” stattfand. Insbesondere die Übergänge zwischen Model und Controller können fließend sein.
Im Folgenden wird ein für Webanwendungen gängiges Verständnis dieser Komponenten beschrieben, dem auch wir uns bedient haben.

Das Model (dt. Modell) verwaltet die Daten und wickelt den Datenbankzugriff ab. Logik und Validierung der Daten können ebenfalls im Model enthalten sein.

Der Controller (dt. Steuerungsschicht) nimmt Anfragen (HTTP-Requests) vom Browser, und damit vom Benutzer der Anwendung, entgegen, und ruft entsprechend seiner internen Logik Daten aus den Modellen ab und lädt sie zur Darstellung in eine oder mehrere Präsentationen. Anhand von Benutzeraktionen kann der Controller Daten in den Modellen ändern. Außerdem entscheidet der Controller anhand verschiedener Bedingungen (z.B. Rechte des Benutzers), ob die möglichen Benutzeraktionen in der Präsentation eingeschränkt werden müssen.

Die Aufgabe des View (dt. Präsentation) ist die Darstellung der Daten aus den Modellen. Es ermöglicht dem Benutzer, die Daten einzusehen und sie über entsprechende Steuerelemente zu manipulieren. Ein View kann aus mehreren Unter-Views in Form einer Baumstruktur zusammengesetzt sein. Es entspricht damit dem composite pattern.

MVC_Framework

Als Grundlage zur Umsetzung dieses Projektes haben wir ein PHP-Framework nach diesem Konzept entwickelt. Es trägt den internen Namen “MVC_Framework”. Wir haben uns bewusst zur Entwicklung eines eigenen Frameworks entschieden, einerseits aufgrund des damit einhergehenden Lerneffekts und dem besseren Verständnis als bei der Nutzung eines vorgefertigten Frameworks, andererseits um die Anwendung möglichst einfach zu halten und nur die Funktionen zu integrieren, die tatsächlich benötigt werden.

Ordnerstruktur

Durch unser Framework ist eine bestimmte Ordnerstruktur für die Anwendung vorgegeben, in die die einzelnen Code-Dateien entsprechend ihrer Aufgabe eingeordnet werden.
Im folgenden wird kurz beschrieben, welche Dateien und Ordner es gibt und welchen Zweck diese haben. Zu einigen gibt es weiter unten einen gesonderten Abschnitt, der genauere Informationen enthält.
2.3.1.1 /index.php
Diese Datei stellt den zentralen Einsprungspunkt des Frameworks dar. Alle Aufrufe der Anwendung landen zunächst in der index.php. Sie ist dafür zuständig, alle benötigten Grundmodule sowie die Konfiguration zu laden und schließlich das Routing-Modul anzustoßen.
2.3.1.2 /.htconfig.php und /install.php
In der /.htconfig.php wird ein assoziatives Array mit dem Namen $SITE_CONFIG definiert, welches anwendungsglobale Konfigurationseinstellungen enthält. Sie sollte normalerweise nicht manuell bearbeitet werden, sondern nur mittels des unter /install.php erreichbaren Installationsassistenten.
2.3.1.3 /create_tables.sql
Dieses SQL-Skript enthält die nötigen Befehle, um die Datenbankstruktur für die Anwendung zu erzeugen.
2.3.1.4 /.htaccess
Die Konfigurationsdatei für den Apache-Webserver stellt ein, dass alle Aufrufe auf die oben beschriebene /index.php umgeleitet werden und macht diese damit zum globalen Einsprungspunkt des Frameworks. Davon wird nur die /install.php und der Ordner /content/ ausgenommen.
2.3.1.5 /system/
Der Systemordner enthält die Hauptbestandteile des Frameworks sowie einige Hilfsfunktionen und wird in einem eigenen Kapitel beschrieben. Normalerweise sind hier bei der Entwicklung einer Anwendung auf Basis des Frameworks keine Änderungen erforderlich.
2.3.1.6 /model/
Hier werden die Modelle als PHP-Dateien abgelegt, die die jeweilige Modellklasse enthalten.
Modelle werden mit dem Aufruf load_model(“beispiel”); geladen.
2.3.1.7 /controller/
Dieses Verzeichnis enthält die Controllerklassen (Steuerung), die in eigenen PHP-Dateien abgelegt sind. Eine beispiel.php enthielte also die Klasse BeispielController. Die Klassen erben immer (egal ob direkt oder indirekt) von Controller. Die Methoden der Controller sind direkt zugeordnet zu den HTTP-Zugriffspfaden. Diese Zuordnung wird im Abschnitt “Routing der HTTP-Anfragen” genauer erläutert.
2.3.1.8 /controller/controller.php
Diese Datei enthält die abstrakte Basisklasse Controller, von der alle Controller direkt oder indirekt abzuleiten sind. Es kann sinnvoll sein, hier Attribute und Methoden zu definieren, sowie Modelle zu laden, die in allen Controllern benötigt werden (z.B. zur Sitzungs-, Rechte- und Benutzerverwaltung).
Hinweis: Es ist aufgrund dieser Benennung weder möglich noch sinnvoll, einen ControllerController zu erstellen.

Konfiguration und Installationsassistent

Folgende Einstellungen sind hier standardmäßig zu finden:
  • Zugangsdaten zur Datenbank (IP-Adresse oder Hostname des MySQL-Servers, Benutzername, Passwort, Name der Datenbank)
  • Salt-Wert für die Passwort-Verschlüsselung
  • Das URL-Prefix der Anwendung, welches für die Generierung interner Links verwendet wird (meist “/”)

Der Installationsassistent führt dabei Schritt für Schritt durch die Installation:
1 Überprüfen der Dateiberechtigungen (“Ist die Konfigurationsdatei schreibbar?”)
2 Abfrage der MySQL-Zugangsdaten und Überprüfen der Verbindung
3 Erstellen der benötigten Datenbank-Tabellen anhand der /create_tables.sql
4 Abfrage weiterer globaler sowie anwendungsspezifischer Einstellungen
5 Schreiben der Konfigurationsdatei und Abschluss des Assistenten

Erweiterung der Konfiguration in der notendb2

Die Konfiguration wurde für die Notendatenbank um einige anwendungsspezifische Parameter ergänzt. Diese sind ein abweichender Seitentitel, ein einstellbares Schullogo sowie das Passwort für den Super-Administrator (root-Nutzer).

Die nachfolgende Tabelle beschreibt im Detail die Parameter, die in der Konfigurationsdatei .htconfig.php abgelegt werden. Ein Kreuz in der Spalte “Erw.” kennzeichnet Einträge, die notendb2-spezifische Erweiterungen gegenüber dem MVC_Framework darstellen.



Schlüssel des assoziativen $SITE_CONFIG-Arrays

Vorgabewert

Erw.

Beschreibung

DB_HOST

“localhost”



Hostname des zu nutzenden MySQL-Servers

DB_USER

“”



Benutzername zur Anmeldung am MySQL-Server

DB_PASSWORD

“”



Passwort zur Anmeldung am MySQL-Server



Schlüssel des assoziativen $SITE_CONFIG-Arrays

Vorgabewert

Erw.

Beschreibung

DB_NAME

“”



Name der Datenbank

LOGIN_SALT

(autom. gen.)



Saltwert zur Sicherung des Passwort-Hashs

INI_DONE

true



Wenn nicht gesetzt, wird bei jedem Aufruf automatisch der Installationsassistent gestartet. Wird nach dessen Abschluss automatisch auf true gesetzt.

URL_PREFIX

(autom. gen.)



Präfix zur Generierung interner Links (z.B. http://notendb.example.org/ oder /notendb2/)

Muss mit / enden.

LOGIN_ROOTPASW

“”

x

Passwort für den Superadministrator-Zugang root.

Erforderlich, um den Installationsassistent ggf. erneut zu öffnen.

HEADER_SITE_TITLE

“Noten-Verwaltung”

x

Angezeigter Name der Anwendung.

Erscheint in der Kopfzeile und im Browsertitel (<title>-Tag)

HEADER_BG_COLOR

“#202020”

x

Hintergrundfarbe der Kopfzeile der Anwendung

HEADER_WELCOME_IMAGE

“”

x

URL zu einem Bild, welches auf der Begrüßungsseite nach Einloggen erscheint (z.B. Schullogo)


Routing der HTTP-Anfragen

Eine HTTP-Abfrage wird, wenn sie den Serverrechner erreicht, zunächst von einem Webserver-Dienst entgegengenommen (üblicherweise der Apache2-Webserver). Dieser ruft, sofern sich die Anfrage auf ein Verzeichnis bezieht, in dem eine MVC_Framework-Anwendung abgelegt ist, seiner Konfiguration in der .htaccess folgend, zunächst das zentrale Einsprungs-Skript index.php auf. Dieses lädt zunächst alle benötigten Systemkomponenten. Anschließend wird die Kontrolle an die Funktion load_controller (system/routing.php), übergeben. Hier wird der Pfad der Anfrage an die Funktion split_url weitergereicht, die ihn nach Komponenten (durch / abgetrennte Teile) zerlegt zurückgibt. Die Pfadkomponenten bestimmen den zu ladenden Controller und die darin aufzurufende Methode.
Das Routing erfolgt unabhängig von Sitzungszustand und HTTP-Methode. Diese Umstände werden im Controller selbst berücksichtigt.

Schnittstelle der Controller

Jeder Controller ist als Klasse implementiert, die in einer eigenen Datei im Verzeichnis /controller/ abgelegt ist. Die erste Pfadkomponente bestimmt den aufzurufenden Controller. Der Dateiname wird durch Anhängen des Suffix .php ermittelt. Der Klassenname wird durch Umwandeln des ersten Buchstabens in Großschreibung und durch Anhängen des Suffix Controller ermittelt.
Ist keine erste Pfadkomponente angegeben, wird als Standardwert default angenommen.
Die zweite Pfadkomponente bestimmt die aufzurufende Methode des Controllers. Es können nur als public deklarierte Methoden auf diesem Weg aufgerufen werden. Ist keine zweite Pfadkomponente angegeben, wird als Standardwert index angenommen.
Alle weiteren Pfadkomponenten werden als Parameter an die Methode weitergereicht.
Kann der Controller oder die Methode nicht gefunden werden, wird das View error_404 geladen.

Routing-Beispiele



Aufruf

Controller-Datei

Controller-Klasse

Methodenaufruf

GET /

controller/default.php

DefaultController

index()

GET /admin/dashboard

controller/admin.php

AdminController

dashboard()

POST /kurs/edit/25

controller/kurs.php

KursController

edit(“25”)

GET /example

controller/example.php

ExampleController

index()




Datenbank und Modelle3.1 Datenbank

Zur Speicherung der anfallenden Daten haben wir uns für eine Speicherung durch eine MySQL-Datenbank entschieden. Diese war in der Linux-Umgebung des Servers verfügbar und konnte durch eine schon vorhandene Implementation in PHP genutzt werden. Auch waren die erforderlichen Kenntnisse zum Einbinden und Benutzen im Projekt vorhanden, sodass keine Einarbeitung in eine neue Datenbank notwendig war. Das Datenbankdesign wurde weitestgehend den aktuellen Entwicklungs- und Design-Standards angepasst, um eine spätere Wartung oder Veränderung der Datenbankstruktur zu ermöglichen, sowie eine möglichst fehlerfreie Entwicklung zu erreichen. Hierbei wurde die Datenbank weitestgehend normalisiert[18] und im späteren Verlauf der Entwicklung um verschiedene benötigte oder geforderte Elemente erweitert.

Kriterien und Planung

Als Kriterien für die Datenbank zur Notenerfassung wurden zu Beginn des Projekts folgende Anforderungen gestellt:
1. Die Zeugnisse müssen reproduzierbar sein
Die Zeugnisse müssen dauerhaft in ihrer originalen Form reproduzierbar sein. Nachträgliche Änderung der Schülerdaten dürfen sich daher nicht auf vorherige Zeugnisse auswirken.

2. Schüler müssen einem Jahrgang zugeordnet sein
Alle Schüler im System müssen einem Jahrgang, einem Halbjahr und einer Klassenstufe zugeordnet werden.

3. Schüler müssen Kursen zugeordnet werden können
Alle Schüler müssen den von ihnen belegten Kursen zugeordnet werden können. Dabei müssen jedem Schüler im Kurs eine unabhängige Note, sowie Fehlstunden und unentschuldigte Fehlstunden, zugeordnet werden können.

4. Kurse müssen Lehrern zugeordnet werden können
Für die Zeugnisausgabe ist eine Zuordnung der Lehrer zu den von ihnen unterrichteten Kursen erforderlich. Dies dient zusätzlich der Autorisierung eines Lehrers, um die Noten seiner Kurse eingeben oder ändern zu dürfen. Ein Lehrer kann mehrere Kurse besitzen, ein Kurs kann durch mehrere Lehrer geleitet werden können.

5. Kurse müssen einem Jahrgang/Halbjahr zugeordnet sein

6. Ein Jahrgang/Halbjahr muss Tutoren enthalten
Die Tutoren der Jahrgänge sind den entsprechenden Jahrgängen zuzuordnen. Diese Zuordnung ist unabhängig von den Kursen, die sie im Jahrgang unterrichten.

Außerdem wurden Lehrer- und Schülerdaten aus der Lehrer- und Schülerdatenbank[19](LUSD) des Hessischen Kultusministeriums in den Datenbestand importiert. Diese schon vorhandenen Datensätze konnten somit in der Datenbank integriert und ohne manuelle Bearbeitung oder Eingabe weiterverwendet werden.
Aus den oben genannten Kriterien ergibt sich das folgende ERM, welches als grundlegende Datenbankstruktur des Notensystems anzusehen ist:
Die Kombination “Jahrgang/Halbjahr/Klassenstufe” ist eindeutig und wird deshalb in der Datenbank unter dem Begriff “Datei” geführt.

Umsetzung

Die Umsetzung des ERMs in ein relationales Datenbankmodell wurde mit einigen Einschränkungen in der dritten Normalform durchgeführt. Eine Ausnahme bilden hier die Schülerdaten, welche für jede Datei neu gespeichert werden. Dies ist notwendig, um Zeugnisse reproduzierbar in der Datenbank zu halten. Bei einer Änderung der Schülerdaten dürfen diese nicht ältere Zeugnisse betreffen und werden deshalb für jede Datei, und damit mit jedem Halbjahr, erneut angelegt.
3.1.2.1 Bezeichnungen
Die Verbindungstabellen zur Auflösung der n:m-Beziehungen der Lehrer-Kurs und Schüler-Kurs-Tabellen wurden nach dem Muster rel_tabelle1_tabelle2 angelegt. Da die Bezeichnung “Tutor” die Verbindung Lehrer-Datei in der Realität bezeichnet, wurde von dem vorherigen Muster abgewichen und die Tabelle mit der Bezeichnung Tutor angelegt. Tabellenattribute, welche eindeutige IDs enthalten wurden nach folgendem Schema benannt:
  • Der erste Buchstabe des Tabellennamens (als Kleinbuchstabe)+“id” wurden kombiniert.
Beispiel: Der Primary Key der Tabelle datei wurde aus dem Anfangsbuchstaben “d” und “id” zu “did” zusammengeführt.
○ Bei Namenskonflikten (welcher in der Datenbank bei den Tabellen kurs und kurs_template vorlag) wurde der zweite Buchstabe oder der erste Buchstabe des zweiten Wortes mit einbezogen:
kurs wurde zu kuid
kurs_template wurde zu ktid
○ Bei Verbindungstabellen wurde die ID immer mit “rid” (r für Relation) benannt, um eine Verwechslung mit anderen IDs zu vermeiden.
  • Bei Foreign-Keys (im folgenden FK) in relationen Tabellen wurde ein “r_” der Tabellen ID vorangestellt um das Attribut als Foreign-Key zu kennzeichnen:
Beispiel: Die Tabelle rel_lehrer_kurs enthält somit zwei Foreign-Keys auf die Tabellen lehrer und kurs mit folgender Bezeichnung:
FK auf lehrer : r_ + foreign id wird zu r_lid
FK auf kurs : r_ + foreign id wird zu r_kuid


3.1.2.2 Umsetzung der Tabellen
In der Umsetzung des ERM-Diagramms wurden die Anforderungen in den folgenden Tabellen aufgelöst:
datei
Die Verbindung Jahrgang/Halbjahr/Klassenstufe ist das grundlegende Element der Tabellenstruktur. Diese Tabelle verbindet Tutoren, Schüler und Kurse und gruppiert sie somit in der Datenbank zu logischen Zusammenschlüssen.
kurs
Ein Kurs stellt die für das Zeugnis und den Zeugnisdruck geforderten Kursdaten in der Datenbank dar. Diese Daten werden im Zeugnisdruck berücksichtigt und können pro Kurs gesetzt werden. Die Verbindung der Schüler und Lehrer erfolgt über die Tabellen rel_lehrer_kurs und rel_schueler_kurs mittels der Kurs ID (Attribut: kuid) als Foreign Key.
schueler
Diese Tabelle beinhaltet die Daten der Schüler welche für den späteren Zeugnisdruck benötigt werden. Jeder Schüler ist über die ID sid eindeutig in einem Datensatz identifizierbar. Um nachträgliche Zeugnisdrucke zu ermöglichen werden die Schülerdaten in jeder Datei neu erstellt und dieser über den Foreign Key did zugeordnet.
lehrer
Diese Tabelle Lehrer beinhaltet die Logindaten der Notendatenbank sowie die für den Zeugnisdruck relevanten Lehrerdaten. Die Verknüpfung zu Kursen, welche die erforderlichen Rechte zum Eintragen der Kurse und der Notenvergabe ergeben, sowie die Zuordnung der Tutoren der Dateien werden über die Tabellen rel_lehrer_kurs und tutor erstellt. Das zusätzliche Feld is_admin speichert die Zugriffberechtigung auf den Adminbereich. Es sollte ausschließlich für Administratorzugänge gesetzt werden, da damit weitreichende Rechte in der Notenverwaltung freigegeben werden.
kurs_template
Die Daten der Kursvorlagen werden in dieser Tabelle gespeichert. Sie geben die zum Zeugnisdruck erforderlichen Kursdaten und Zeilennummern sowie die Anzeigereihenfolge in der Notendatenbank an. Die Daten einer Kursvorlage wirken sich nicht auf schon bestehende Kurse aus, sondern dienen lediglich als Vorlagen zum Erstellen neuer Kurse.


Tutor
Diese Tabelle beinhaltet alle Lehrer einer Datei, welche Tutorenrechte bei Dateien erhalten. Das Attribut is_tutor ist für zukünftige Verwendung reserviert und wird derzeit nicht benutzt. Es könnte für Datenbanken mit Lehrern verschiedener Schulformen verwendet werden, um diese in der Auswahlliste zu trennen.
rel_lehrer_kurs
Durch die Beziehung Lehrer-Kurs werden die Rechte zur Notenvergabe einzelner Kurse gesetzt.
rel_schueler_kurs
Diese Tabelle enthält die Zuordnungen der einzelnen Schüler zu ihren jeweiligen Kursen. In der Zuordnung werden zusätzlich die Noten, Fehlstunden und unentschuldigten Fehlstunden gespeichert.

Spätere Änderungen

Die Datenbank wurde im Verlauf der Entwicklung um verschiedene Attribute erweitert, die Beziehungen der Tabellen zueinander blieb aber, mit Ausnahme der Kursvorlagen, unverändert.
3.1.3.1 Erweiterte Anforderungen durch das Graphical User Interface (GUI)
Nach Behebung einen Fehler in der Noteneingabe, der zum überschreiben parallel eingegebener Noten führte, hielten wir es für sinnvoll, Kurse zusätzlich während der Bearbeitung zu. Hierzu wurden im Datenbankdesign die Attribute editlocked_by_lid und editlocked_since in der Tabelle kurs eingefügt, welche durch Controller-Methoden die Sperrung von Kursen sicherstellen. Zur besseren Übersicht der verschiedenen Sperren wird zusätzlich das Datum der Sperrung gespeichert. Da die Sperren zeitlich unbegrenzt sind, können Administratoren alle Sperren im Adminbereich aufheben, wenn diese von Lehrern vergessen wurden. Zusätzlich zu geplanten Daten wurden die Felder display_position und export_position eingeführt, welche eine geordnete Ausgabe der Fächer im Zeugnis und in Kontrollansichten angeben.
3.1.3.2 Erweiterte Anforderungen zur Anwendungs- und Datensicherheit
Aufgrund einiger Anfragen wurde die Möglichkeit eingeführt, Dateien zu archivieren und Kurse einzureichen, um eine nachträgliche Änderungen der Daten zu verhindern. Hierzu wurde das Attribut archiviert in die Tabelle Datei eingeführt, welche von verschiedenen Controllern zur Steuerung der Schreibrechte verwendet wird. Des Weiteren können Kurse nun eingereicht werden. Dies wird in der Datenbank durch das Attribut eingereicht in der Tabelle kurs realisiert, welches die Bearbeitung für Kurslehrer sperrt, so dass die Noten nach dem Einreichen nicht mehr verändert werden können.

Back-End

Unter dem Begriff Back-End bezeichnet man in der Informatik den Teil einer Anwendung, welcher anfallende Daten verwaltet und mit Systemschnittstellen interagiert[20]. Das Back-End unserer Anwendung wurde in PHP und MySQL realisiert und bildet den Model- und Teile des Controller-Teils des MVC-Modells ab. Die zu erfüllenden Aufgaben sind die Verwaltung und Speicherung der anfallenden Schüler, Lehrer und Kurs-Daten, sowie das Strukturieren der Ein- und Ausgabe dieser, welches im Folgenden über “Model”-Objekte realisiert wurde.

Modelle

Modelle haben im MVC-Konzept die Aufgabe der Verbindung von Anwendung und Datenbestand. Zusätzlich können Modelle Funktionen zur Vereinheitlichung verschiedener Ein- oder Ausgabedaten enthalten und Datenbankabfragen ausführen. In unserem Notensystem wurde die Aufteilung der Modelle an die Datenbankstruktur angepasst, so dass jedes Model eine Tabelle der Datenbank repräsentiert. Der Datenbankzugriff der Modelle wird im Code von der Klasse DatabaseModel implementiert, welche als Parentklasse von jedem datenbankbezogenen Modell dient. Zur Bereitstellung eines gesicherten Bereichs im Projekt wurde zusätzlich das Modell session benötigt, sowie das Model lehrer mit Funktionen zur Passwortabfrage versehen. Zur Zeugnisausgabe aus dem Datenbestand wurde zuletzt das Model xmlexport erstellt, welches Zeugnisse über das LaTeX-Format [21] als PDF erstellt.

Strukturierung der Modelle

Alle Modelle leiten sich von der Basisklasse Model ab, welche keine eigenen Funktionen implementiert. Der Suchpfad der Modelle liegt unter /model/. Modelle werden im MVC-Framework über die Funktionen load_model und require_model der Datei /system/models.php angefordert, welche das Laden und Erstellen der Modelinstanzen verwaltet. Die Benennung der Klasse muss dem Dateinamen (ohne Dateiendung “.php”) mit dem Suffix Model entsprechen, damit sie vom MVC-Framework erkannt wird.
Als Beispiel wird das Model “schueler” folgendermaßen abgespeichert:
Dateipfad: /model/schueler.php
Klassenname: SchuelerModel
Weiterhin wurden Datenbankzugriffe über die Modelle DatabaseModel und DatabaseRelModel vereinheitlicht. Beide Klassen erlauben die einheitliche Nutzung der Datenbank in der gesamten Anwendung. Das zuletzt genannte DatabaseRelModel, welches eine abgeleitete Klasse von DatabaseModel ist, ermöglicht hierbei den Zugriff auf Verbindungstabellen mit 2 Foreign Keys, welche mittels der Klassenattribute idLCol und idRCol angegeben werden können.

Modelle im MVC Framework

Die folgende Liste enthält alle Modelle unserer Anwendung (das Suffix “Model” der Modellnamen wird zur besseren Lesbarkeit nicht explizit genannt). Parentklassen werden mit einem Pfeil (->) hinter dem Modellnamen gekennzeichnet um die Klassenhierarchie darzustellen.
database -> model
Dieses Modell stellt das Interface zur Datenbank dar. Alle Datenbankbefehle und -abfragen der Modelle werden durch Ableitung von dieser Klasse realisiert. Die Einstellungen zum Verbindungsaufbau werden durch das MVC Framework eingetragen. Die abgeleiteten Klassen können über diese Basisklasse SQL-Abfragen an die Datenbank senden. Die Variablen $table und $idcol geben in abgeleiteten Klassen die betreffende Tabelle und Primary-Key Spalte an. Weiterhin gibt die Variable $structure bei abgeleiteten Klassen die Datenstruktur der Tabelle wieder und sorgt so dafür, dass SQL-Abfragen in der Klasse gekapselt werden können. Zum Schutz vor SQL-Injection-Angriffen[22] wird die PHP-Funktion mysql_real_escape_string eingesetzt. Die Klasse kapselt die PHP-MySQL-Anbindung und stellt somit elementare Funktionen zum Abfragen einzelner Datensätze (Funktion: getsingle) oder aller Daten einer spezifischen Abfrage (Funktion: getall) zur Verfügung. Die Funktionen doQuery und execute dienen zum Senden von schreibenden SQL-Komandos an die Datenbank (INSERT, UPDATE, DELETE). Um eine mögliche SQL-Injektion zu vermeiden sollten stets die von der Klasse bereitgestellten Funktionen verwendet werden, welche den oben genannten Angriff verhindern. Hierbei ist zu beachten, dass alle Funktionen des Modells Parameter zur als SQL-Query verarbeiten. Alle folgenden Parameter werden mittels vsprintf[23] in den SQL-Querystring geschrieben und stehen somit, unabhängig vom übergebenen Variablentyp, im gewünschten Format in der Zeichenkette.

databaseRel -> database
Diese Klasse erlaubt Zugriff auf Tabellen welche n:m-Beziehungen auflösen, d.h. Foreign Keys zu zwei Tabellen enthalten. Die Variablen $idLCol und $idRCol müssen in abgeleiteten Klassen mit den Namen der Foreign-Keys beschrieben werden. In den abgeleiteten Klassen können so, Datenbankeinträge der jeweiligen Tabelle bearbeitet und selektiert werden, ohne die internen Bezeichner der Tabellen Attribute zu kennen. Je nach Anordnung der Spaltennamen in den Variablen $idLCol und $idRCol werden diese in der Klasse als Left- und Right-Column geführt. Alle Befehle können somit links- oder rechtsseitig (bezogen auf die Zuordnung der Spaltennamen zu den Variablen) auf die Tabelle angewandt werden. Somit erweitert diese Klasse das Model Database um Funktionen zur Selektion bestimmter IDs durch die Funktionen getByRel, getAllByLId und getAllByRId, sowie das Setzen und Löschen einzelner Left-Right-Column-ID Kombinationen durch die Funktionen addByRel, deleteByRel und setByRel. Funktionen ohne Spaltenangabe im Namen benötigen zur korrekten Ausführung beide Spalten-IDs als Parameter.
datei -> database
Das Model erweitert die Parentklasse um die Funktionen k_set_editlock, k_clear_editlocks_by_lid und k_clear_all_editlocks welche von Controllern zum Sperren oder Entsperren verschiedener Kurse genutzt werden. Zusätzlich wurde die Funktion get_ordered_list implementiert, welche eine für die Anzeige sortierte Liste aller Kurse der Datei zurückgibt.
kurs -> database
Die Klasse repräsentiert die Tabelle kurs des Datenbank-ERMs. Die Implementation unterscheidet sich von der Parentklasse durch vorgefertigte Abfragen, welche von Controllern häufig genutzt werden, um bestimmte Datenrelationen aus der Datenbank zu filtern. Zusätzlich wurden die Funktionen set, get_all und get_by_id überschrieben um eine zusätzliche Sortierung der Query-Daten zu implementieren. Nachträglich wurde außerdem die Funktion delete abgeändert, da diese einen Fehler in der Fehlstundenberechnung hervorrief (siehe Anhang).
kurs_template -> database
(keine zusätzlichen Funktionen)
lehrer -> database
Dieses Model leitet sich von dem DatabaseModel ab und gibt eine Repräsentation der Tabelle lehrer wieder. Zusätzlich enthält sie Methoden um das Passwort eines Lehrers zu prüfen und die entsprechenden Rechte, bei erfolgreichen Login, auszugeben sowie eine Methode zum Setzen von Passwörtern.
rel_lehrer_kurs -> databaseRel
(keine zusätzlichen Funktionen)
rel_schueler_kurs -> databaseRel
(keine zusätzlichen Funktionen)
schueler -> database
Diese Klasse repräsentiert die Tabelle Schüler des ERMs. Die zusätzliche Funktion get_noten_uebersicht erzeugt eine Liste aller Noten eines Schülers in der Datenbank.
session -> model
Das Session Model verwaltet die Rechte und Loginberechtigungen einzelner Sessions[24]. Die Methoden isRoot, isAdmin und isTutor geben eine Boolean Value zurück, welche von Controllern zur Rechteverwaltung in der GUI genutzt werden. Zusätzlich können weitere Attribute des eingeloggten Users über die Funktion getUser ausgelesen werden.
tutor -> database
(keine zusätzlichen Funktionen)
xmlexport -> database
Dieses Model wird intern zur Erstellung der Zeugnisse mittels LaTeX[25] und PDFLaTeX[26] benötigt. Die Funktion pdflatex erzeugt durch die Verwendung oben genannter Programme eine Zeugnisdatei im PDF-Format (siehe Anhang). Die Implementation der Funktion export_datei ist zum Exportieren der Schülerdaten zu einer möglichen Offline-Bearbeitung vorgesehen und wird derzeit nicht genutzt.

Sessionverwaltung

Die Sessionverwaltung erlaubt die Authentifizierung eines Benutzer in der Anwendung. Anforderung 19 sowie Anforderung 20 fordern eine gesicherte Nutzung der Datenbank. Hierzu wurde eine Authentifizierung der Nutzer implementiert, welche die Nutzeraccounts schützt.

Lehrer-Login

Der Zugriff auf die Anwendung wird nur für Lehrer erlaubt. Für eine Anmeldung stellt das System eine öffentliche Seite zur Verfügung, welche die Authentifizierung des Lehrers mittels Benutzername und Passwort erlaubt. Die Logindaten werden nach dem Absenden durch das session und lehrer Model geprüft. Hierzu wurden verschiedene Techniken verwendet, um die Passwortdaten bei einem möglichen Datendiebstahl zu schützen. [27]
4.2.1.1 Datenverschlüsselung
Um die Passwörter bei Datenverlust weitestgehend zu sichern werden diese über einen Hashalgorithmus verschlüsselt und anschließend in der Datenbank gesichert. Durch die Einwegverschlüsselung mittels der md5-Funktion sind die Passwörter unumkehrbar verschlüsselt.
Anmerkung: Der Algorithmus MD5 gilt als veraltet und sollte in absehbarer Zeit durch einen sicheren Algorithmus ersetzt werden. Hierbei sollte beachtet werden, das durch die Änderung des Hashalgorithmus alle Passwörter ungültig werden gesetzt werden müssen.
4.2.1.2 Rainbowtables
Zur Abwehr von Rainbow-Table-Angriffen auf die Datenbank wird ein zusätzlicher Salt verwendet, welcher an das Passwort angehängt wird, um allgemeine Rainbow-Tables unwirksam zu machen. Weiterhin wird der Username im Hash verarbeitet um die Hashkombinationen für jeden User zu variieren und somit eine Rainbow-Table für den gesamten Datenbestand zu verhindern.



Controller und Oberfläche5.1 Willkommensbildschirm

Nachdem der Benutzer sich mit Kürzel und Passwort authentisiert hat, erscheint der nachfolgend abgebildete Willkommensbildschirm.
Hier hat der Benutzer sofort Zugriff auf alle wichtigen Menüpunkte:
1 Benutzermenü und Administrationsmenü
2 Hauptmenü
○ Kursliste
○ Zuordnung von Schülern zu Kursen
○ Tabelle zur Notenvergabe
○ Schülerliste
○ Zeugnisdruck
3 Schnellauswahl für Datei
4 Onlinehilfe
5 Detaillierte Liste aller aktuellen Dateien

Am Beispiel dieses Willkommensbildschirms wird bereits das Zusammenspiel von Controllern und Views deutlich.

Der Apache-Webserver ruft aufgrund der Angaben in der .htaccess das Einsprungsskript index.php auf.

Dieses bindet einige benötigte Dateien mit dem require_once-Befehl ein, um danach die Kontrolle an die Funktion load_controller (system/routing.php) zu übergeben. Diese verarbeitet, wie im Abschnitt Routing der HTTP-Anfragen beschrieben, die Anfrage des Browsers, und lädt dann einen geeigneten Controller.

Im Fall des Willkommensbildschirms ist das der DefaultController in controller/default.php, der von load_controller instanziiert wird. Dieser ist abgeleitet von Controller und ruft in seinem Konstruktor zunächst mit parent::construct() den Konstruktor seiner Elternklasse auf. Darin wird, wie unten im Abschnitt controller.php beschrieben, die Anwendung initialisiert.
Der Konstruktor des DefaultController stellt anschließend mit require_login sicher, dass ein Benutzer eingeloggt ist, und lädt weitere benötigte Modelle. Außerdem initialisiert er die View-Variable $Dateien, die später die Datei-Schnellauswahl (3) befüllt.

Danach wird die entsprechende Controller-Methode aufgerufen, hier index(). Diese lässt sich vom DateiModel die Liste aller Dateien geben, die daraufhin noch mit der über SessionModel.isTutor abgefragten Information, ob der eingeloggte Nutzer Tutor dieser Datei ist, angereichert und an das View welcome.php übergeben wird. Der von diesem View generierte HTML-Code wird in der Layout-View-Variablen Inhalt abgelegt. Schließlich wird die Methode Controller.display_layout aufgerufen, die durch das View default_layout.php die engültige Ausgabe erzeugen lässt und diese an den Web-Browser sendet.



In Kurzform:
index.php
require_once(...); Systemdateien laden
load_controller();
split_url(...);
new DefaultController();
DefaultController.construct
Controller.
construct
load_model(...);
load_model(...);
require_login();
$controller->index();
DateiModel.get_all(...);
for each: SessionModel.isTutor($datei);
$Inhalt = get_view(welcome);
Controller.display_layout();


Controller

Die Controller stellen im MVC-Konzept das Bindeglied zwischen Modellen, Ansichten (Views) und dem Benutzer (genau genommen dem User-Agent, also dem Webbrowser) dar.

controller.php

Die Basisklasse Controller enthält Methoden, die zur Verwendung in allen Controllern relevant sind.
Hier sind etwa die Methoden require_login und require_datei abgelegt, die in den Konstruktoren der Controller aufgerufen werden, die zur korrekten Funktion einen eingeloggten Benutzer bzw. eine ausgewählte Datei erfordern.
Der Konstruktor der Basisklasse enthält Code zur Initialisierung der Anwendung. Es werden global benötigte Modelle geladen sowie globale View-Variablen zugewiesen. Außerdem hier die Funktion load_menu aufgerufen, die das Hauptmenü initialisiert.
Die Methode display_layout und das Feld $template_vars dienen zum Aufruf des Standardlayouts nach Abarbeitung der Methode eines abgeleiteten Controllers.




Alle Controller5.2.2.1 admin.php

Erreichbar über den Menüpunkt “Administrationsbereich” im Benutzer- und Administrationsmenü
Dieser Controller enthält Formulare und Aktionen für administrative Aufgaben. Er ist nur für Benutzer zugänglich, die als Administratoren eingetragen sind (Feld is_admin), sowie für den Super-Administrator root.
Es erscheint zunächst eine Übersichtsseite, die den Zugriff auf die verschiedenen Funktionen gewährt. Weitere Informationen finden Sie im Abschnitt „Leitfaden zur Administration“.
5.2.2.2 default.php
Der DefaultController wird aufgerufen, wenn ein Benutzer auf das Stammverzeichnis zugreift. Daher ist er zuständig für die Ausgabe der Willkommensseite.
5.2.2.3 kurstemplate.php
Erreichbar über den Menüpunkt “Kursvorlagen” im Benutzer- und Administrationsmenü
Der KurstemplateController wurde nachträglich eingeführt, um die hinzugefügte Anforderung 3 zu erfüllen. Es ermöglicht, Kursvorlagen zu erstellen, zu bearbeiten, zu löschen und eine Liste aller Kursvorlagen zu betrachten.
5.2.2.4 public.php
(reserviert für spätere Verwendung)
5.2.2.5 statistics.php
(reserviert für spätere Verwendung)
5.2.2.6 user.php
Erreichbar über die Menüpunkte “Passwort ändern” und “Ausloggen” im Benutzer- und Administrationsmenü
UserController ermöglicht einem eingeloggten Nutzer, sein Passwort zu ändern sowie sich auszuloggen.
Nicht eingeloggte Besucher werden bei allen Aufrufen mittels der Methode Controller.require_login zwangsläufig auf UserController.login umgeleitet.



5.2.2.7 kurs.php
Erreichbar über den Menüpunkt “1. Liste der Kurse” im Hauptmenü
Der KursController stellt Methoden zur Verfügung, um die Liste der Kurse einer Datei abzurufen, Kurse aus Vorlagen zu erstellen, die betreuenden Lehrer des Kurses festzulegen, Kurse zu bearbeiten und zu löschen.
5.2.2.8 offline.php
(derzeit außer Betrieb)
War erreichbar über einen zusätzlichen Punkt im Hauptmenü “Offline”
Es war geplant, eine Offlineversion der Notenverwaltung zu erstellen. Die offline.php enthält Methoden, um Kurse oder ganze Dateien für die Offlineversion zu exportieren und um Daten aus der Offlineversion (eingegebene Noten) wieder zu importieren.
5.2.2.9 schueler.php
Erreichbar über den Menüpunkt “Schülerliste” im Hauptmenü
Dieser Controller stellt eine Liste aller Schüler in einer Datei dar und bietet Methoden an, um einzelne Schüler einzufügen, um Schüler gesammelt zu importieren sowie um einzelne Schüler zu bearbeiten, zu löschen und Notenübersichten einzelner Schüler zu generieren.

Die Importfunktion akzeptiert Daten in folgendem Format, welches das Exportformat des an der Schule eingesetzten OpenSchoolServer[28] nachbildet:
Die erste Zeile enthält den Spaltenkopf und wird ignoriert, alle weiteren Zeilen enthalten durch Doppelpunkte (:) getrennt die eigentlichen Daten.

Username:Nachname:Vorname:Geburtsdatum:Klasse
5.2.2.10 tabelle.php
Erreichbar über die Menüpunkte “2. Zuordnung”, “3. Notenvergabe” und “Zeugnisdruck” im Hauptmenü
Dieser Controller ist für die Ausgabe und das Bearbeiten der verschiedenen Kreuztabellen zuständig, die in der Anwendung dargestellt werden.
Dies sind die Tabelle zur Anzeige der Schüler-Kurs-Zuordnung, die Tabelle zur Zuordnung von Schülern zu einem Kurs sowie die Tabelle zur Anzeige der Noten und die Tabelle zur Notenvergabe.
Außerdem beinhaltet dieser Controller die Methoden zur Auswahl der zu exportierenden Daten und zum Export als Microsoft-Excel-Arbeitsblatt, als CSV oder PDF-Datei.

Benutzeroberfläche5.3.1 Benutzermenü

Das Benutzermenü enthält Aktionen, die sich direkt auf den Zugang des aktuell eingeloggten Lehrers beziehen. Er kann darin sein Kürzel sehen sowie sein eigenes Zugangspasswort ändern. Außerdem befindet sich hier der Menüpunkt Abmelden, der aus Sicherheitsgründen nach der Verwendung der Anwendung immer benutzt werden sollte, um die Sitzung zu beenden.

Administrationsmenü

Der Menüpunkt Administrationsbereich ist nur für Benutzer mit Administrationsrechten sichtbar. Er öffnet die Seite Übersicht für Administratoren (kurz Admin-Dashboard). Diese Seite wird im Kapitel Leitfaden zur Administration näher beschrieben.
Der Menüpunkt Kursvorlagen ist nur für die Tutoren einer Datei sichtbar. Sie können hier die Vorlagen ändern, die den Fachlehrern bei Eingabe ihres Kurses angeboten werden.

Hauptmenü

Das Hauptmenü enthält Menüpunkte, die sich auf die aktuell ausgewählte Datei beziehen. Die Menüpunkte sind in der Reihenfolge nummeriert, in der sie von einem Fachlehrer üblicherweise verwendet werden.

Schnellauswahl für Datei

Die Schnellauswahl ist als Drop-Down-Listenfeld realisiert, in dem alle Dateien aufgelistet werden. Sie wird für eingeloggte Nutzer auf jeder Seite dargestellt, um ein bequemes Wechseln der ausgewählten Datei zu ermöglichen.

Onlinehilfe

Der Link Onlinehilfe verweist auf die URL http:
notendb-hilfe.wikilab.de/anleitungen/, unter der verschiedene Anleitungen als PDF-Dateien zur Verfügung stehen. Die Anleitungen sind auch als Anlage B und C beigefügt.

Detaillierte Liste aller aktuellen Dateien

Die Liste der Dateien auf der Startseite enthält mehr Informationen, als die Schnellauswahl. Hier werden die Dateien hervorgehoben, für die der eingeloggte Benutzer als Tutor eingetragen ist.



Praxis

In diesem Kapitel fassen wir einige Hinweise und Anleitungen zur Installation, Wartung, Verwendung und Weiterentwicklung unserer Software zusammen. Ausführlichere Schritt-für-Schritt-Anleitungen und Handbücher sind dagegen im Anhang zu finden.

Systemvoraussetzungen

Clientseitig wird zur Noteneingabe nur ein Webbrowser (Firefox, Chrome, Safari) benötigt.
Um Zeugnisse zu drucken ist zusätzlich entweder Microsoft Office oder ein PDF-Betrachter (z.B. Adobe Reader) erforderlich.

Serverseitig kommt ein Linux-System zum Einsatz, auf dem für die Grundfunktionen ein LAMP-Stack (weit verbreitete Webserver-Einrichtung bestehend aus Apache, MySQL und PHP) eingerichtet sein muss.

Ein LAMP-Stack kann unter Ubuntu sehr einfach mit folgenden Befehlen eingerichtet werden:
$ sudo apt-get install tasksel
$ sudo tasksel install lamp-server

Danach sind eventuell Anpassungen der Konfiguration nötig, die hier nicht beschrieben werden können. Hierzu sind jedoch ausführliche Anleitungen im Internet zu finden.[29]

Für verschiedene Zusatzfunktionen sind folgende weitere Pakete nötig:

  • Für die Erstellung von Microsoft Excel- Arbeitsblättern muss das Java Runtime Environment installiert sein.
  • Für die Erstellung von PDF-Dateien muss die TeX-Distribution TeXLive muss installiert sein. Die Installation wird für Ubuntu und OpenSUSE wie folgt durchgeführt:
Ubuntu:
  1. apt-get install texlive
OpenSUSE:
  1. zypper install texlive texlive-latex

Installation

Wenn die oben angegebenen Systemanforderungen erfüllt sind, ist die Installation in wenigen Schritten zu erledigen.

1 Kopieren Sie die Anwendung (Ordner notendb2) in ein Verzeichnis, welches über den Webserver erreichbar ist (DocumentRoot).

Wir empfehlen, die Anwendung direkt aus dem Git-Repository herunterzuladen, um die neueste Version zu erhalten. Diese ist mit folgendem Befehl möglich:

$ git clone https://github.com/max-weller/notendb2.git

2 Rufen Sie das Hauptverzeichnis der Anwendung über einen Webbrowser auf. Sie werden beim ersten Aufruf automatisch auf den Installationsassistenten weitergeleitet (./install.php).



3 Folgen Sie den Anweisungen des Installationsassistenten.
Sie sollten insbesondere, falls noch nicht geschehen, eine eigene MySQL-Datenbank für die Installation der notendb2 auf dem MySQL-Server einrichten.

4 Nachdem ein Schritt erfolgreich abgeschlossen wurde, wird das graue Kreuz in der Überschrift jeweils durch ein grünes Häkchen ersetzt.

Wenn alle Schritte abgeschlossen sind, klicken Sie auf “Konfiguration schreiben” und “Beenden”.


Mit Klick auf “Zur Startseite” gelangen Sie dann zum Loginformular, in dem Sie sich mit dem Benutzernamen “root” und dem eben vergebenen Passwort erstmalig einloggen können.


Hinweis: Sie können die während der Installation angegebenen Parameter jederzeit verändern, indem Sie den Installations-assistenten erneut aufrufen. Hängen Sie dazu an die URL zum Hauptverzeichnis der Anwendung install.php an. Sie benötigen zum erneuten Starten das Passwort des Superadministrators root, welches Sie bei der Installation vergeben haben.

Sollten Sie dieses Passwort nicht mehr wissen, können Sie in der Konfigurationsdatei .htconfig.php nachsehen. Es befindet sich in der Zeile, die mit $SITE_CONFIG[“LOGIN_ROOTPASW”] beginnt.


Leitfaden zur Administration

In diesem Abschnitt beschreiben wir einige möglicherweise auftretende Probleme sowie Lösungen dafür.
6.3.1.1 Ein Benutzer hat sein Passwort vergessen.
Als Administrator können Sie das Passwort eines beliebigen Nutzers zurücksetzen. Klicken Sie dazu auf Administrationsbereich -> Lehrer verwalten -> Passwort setzen. Geben Sie das neue Passwort zweimal ein, bzw. lassen Sie es den betroffenen Lehrer eingeben. Klicken Sie Ändern.
6.3.1.2 Ein Lehrer möchte Noten für seinen Kurs eintragen, erhält aber den Fehler “Diese Spalte wird gerade von (Lehrername) bearbeitet und ist daher gesperrt.”
Wenn diese Fehlermeldung länger besteht, hat ein anderer Lehrer die Bearbeitung nicht ordnungsgemäß bearbeitet. Die Bearbeitung einer Tabelle sollte immer mit den Buttons Abbrechen, Speichern oder Einreichen beendet werden. Außerdem sollten man sich nach der Verwendung immer Abmelden.

Um alle Sperrungen zurückzusetzen, verwenden Sie Administrationsbereich -> Sperren zurücksetzen. Bestätigen Sie die Sicherheitsabfrage mit OK.
6.3.1.3 Neue Dateien anlegen zum Beginn eines Schul(halb)jahres
Das Anlegen neuer Dateien ist möglich unter Administrationsbereich -> Dateien verwalten -> Erstellen. Dabei sollten gleich die Tutoren des Jahrgangs ausgewählt werden. Mehrfachauswahlen sind mit gehaltener Strg-Taste möglich.
Anschließend werden unter Schülerliste die Schüler aus dem OpenSchoolServer-Export in die neue Datei importiert. Dazu wählen Sie mit Datei auswählen die Exportdatei aus und klicken anschließend auf Importieren.

Beispiel einer Erweiterung

Um die gute Erweiterbarkeit der Anwendung zu dokumentieren, sowie um anderen Entwicklern, die eventuell Erweiterungen vornehmen wollen, die Arbeit zu erleichtern, zeigen wir in diesem Abschnitt die Ergänzung eines zusätzlichen Feldes, um die E-Mail-Adresse eines Schülers zu speichern.


Datenbankfeld hinzufügen

Zunächst wollen wir in der zuständigen Tabelle schueler ein Feld mit dem Namen email einfügen.
Dazu können wir entweder ein grafisches Tool wie Adminer[30] nutzen, um der ein entsprechendes Feld von Typ VARCHAR(256) hinzuzufügen, oder wir nutzen folgendes SQL-Statement:
01 ALTER TABLE `schueler`
02 ADD `email` VARCHAR(255);

Modell anpassen (SchuelerModel)

In jedem datenbankbezogenen Modell (also jedem von DatabaseModel abgeleiteten Modell) wird in einem Feld $structure die Tabellendefinition gespiegelt. In der Datei model/schueler.php muss also ebenfalls das Feld email ergänzt werden:
16 var $structure = array(
17 "did" => "'%s'",
18 "name" => "'%s'",
19 "vorname" => "'%s'",
20 "geburtsdatum" => "'%s'",
21 "username" => "'%s'",
22 "klasse" => "'%s'",
23 "strasse" => "'%s'",
24 "plz" => "'%s'",
25 "ort" => "'%s'",
26 "telefon" => "'%s'",
27 "bemerkungen" => "'%s'",
28 "kommentar" => "'%s'",
29 "ist_g8" => "'%s'",
30 "fachrichtung" => "'%s'",
> "email" => "'%s'"
31 );
(Ergänzte Zeile in Fett hervorgehoben)

Damit sind bereits alle nötigen Änderungen vorgenommen, da der SchuelerController und das View zum Bearbeiten eines Schülers Ihre Informationen aus dem eben geänderten Array $structure beziehen.

Liste anpassen

Optional könnten wir die E-Mail noch als Spalte in der Schülerliste ergänzen. Die relevante Datei ist view/schueler_list.php.
Hier fügen wir zunächst den Spaltenkopf “E-Mail-Adresse” ein
(Zeile 20)
20 <tr><th>Name</th><th>Vorname</th>
<th>Geburtsdatum</th>
<th>E-Mail-Adresse</th><th>Aktion</th></tr>

Danach fügen wir die jeweilige E-Mail-Adresse aus der Datenbank ein (zwischen Zeile 25 und Zeile 26)

26 <td><?= $d["geburtsdatum"] ?></td>
> <td><?= $d["email"] ?></td>
27 <td><?php if(!$archiv): ?>


Ausblick

Fazit

Die gesetzten Ziele des Projekts wurden erreicht und getestet, so dass die Anwendung in der Praxis erfolgreich eingesetzt werden konnte. Die strukturelle sowie zeitliche Planung des Projekts wurde eingehalten und das Projekt zur Abgabe fertiggestellt. Durch die frühzeitige Einbeziehung der Anwender konnten Fehler und Änderungen rechtzeitig erkannt und behoben werden. Probleme, welche das Projekt in der Entwicklung in der Umsetzung beeinträchtigen, traten nicht auf. Durch gute Absprache wärend der Entwicklung wurden alle Bereiche ohne Konflikte in der Codeumsetzung geschrieben und getestet.

Offene Punkte

Derzeit ist noch keine externe Datensicherung zum Schutz vor eventuellen Hardwaredefekten eingerichtet. Dies werden wir in den nächsten Monaten in Zusammenarbeit mit der Netzwerkadministration nachholen.
Eine interne Datensicherung zum Schutz vor Programm- und Bedienfehlern wird bereits durchgeführt.

Mögliche Erweiterungen

Wie jede Software wird auch diese nie endgültig “fertig” sein, da immer noch Erweiterungen und Verbesserungen denkbar sind. Im folgenden führen wir einige Ideen auf, die an uns herangetragen wurden und die wir bisher noch nicht umgesetzt haben.

  • In der Datenbank liegen fast alle nötigen Informationen vor, um nach dem dreizehnten Schuljahr vollautomatisch das Abiturzeugnis für einen Schüler zu generieren. Es müsste die Angabe ergänzt werden, welche Kurse ein Schüler in das Abitur einbringen möchte. Außerdem müssten die notwendigen Rechenvorschriften implementiert sowie eine Vorlage, entweder mit Microsoft Word oder mit LaTeX, angepasst bzw. erstellt werden.
  • Denkbar wäre auch die Anbindung des Logins für Lehrer (evtl. auch für Schüler - siehe nächster Vorschlag) an den schulinternen Verzeichnisdienst über das LDAP-Protokoll. Damit wäre es nicht mehr nötig, gesonderte Logins und Passworte für die notendb2 zu verwalten.
  • Eine Funktion zur Einsichtnahme in die eigenen Noten für Schüler wäre ebenfalls interessant. Mit einer Exportfunktion in einem geeigneten Datenaustauschformat wäre auch die Anbindung an den Abi-Rechner, den Manuel Groh im Rahmen einer Besonderen Lernleistung erstellt hat, möglich. Somit würde das mühsame und fehlerträchtige Abtippen aus den Zeugnissen entfallen.

Mögliche Verwendungen

Die Datenbank wird zur Zeit für das Berufliche Gymnasium verwendet. Die Datenbankstruktur und Codeumsetzung kann, durch die generische Umsetzung, allerdings auch in anderen Schulformen verwendet werden. Für eine Portierung müssen unter Umständen die Zeugnisvorlagen angepasst sowie die GUI leicht modifiziert werden.


Anlagen


Anlage A: Datenbankschema

Anlage B: Anleitung zur Eingabe von Noten

Anlage C: Anleitung zum Ausdruck von
Zeugnissen

Anlage D: Erklärung zur eigenständigen Anfertigung

Anlage E: Verzeichnisstruktur

Anlage F: Vollständiger Quellcode der Software

Anlage G: Letzte Änderungen

Anlage H: Todo-Liste vom Treffen mit den Tutoren

Anlage I: Bildquellen

Anlage J: Zeugnisvorlage


[1] Anfangs war es vorgesehen, dass für jedes Halbjahr die Kursthemen neu eingegeben werden mussten. Dies erwies sich als unpraktisch, sodass wir mit den Kursvorlagen eine Möglichkeit integrierten, die Kursdaten einmalig einzulesen und später anzupassen.
[2] Bei der gleichzeitigen Bearbeitung von Kurslisten durch mehrere Nutzer konnte es zu Datenverlusten kommen. Auch dieser Fehler wurde bereits sehr früh bei einem Probelauf mit Unterstützung von mehreren Tutoren entdeckt, bevor er Schäden an echten Daten verursachen konnte.
[3] Hierbei wurde besonders der Schutz vor SQL-Injection sowie vor Variableninjizierung mittels register_globals beachtet.
[4] Quellen und weitere Informationen zu PHP:
http://www.php.net
http://de.wikipedia.org/wiki/PHP
[5] http://www.mysql.com/
[6] http://de.wikipedia.org/wiki/Hypertext_Markup_Language
[7] http://jquery.com/
[8] http://de.wikipedia.org/wiki/Git
[9] http://notepad-plus-plus.org/
[10] http://scriptide.codeplex.com
[11] http://www.sublimetext.com/
[12] http://www.openssh.org/
[13] http://www.chiark.greenend.org.uk/~sgtatham/putty/
[14] http://winscp.net/eng/docs/lang:de
[15] http://www.adminer.org/
[16] http://www.sequelpro.com/
[17] Quellen und weitere Informationen zum Thema “MVC”:
http://openbook.galileocomputing.de/oo/oo_06_moduleundarchitektur_001.htm
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[18] http://de.wikipedia.org/wiki/Normalisierung_%28Datenbank%29
[19] http://www.lusdportal.hessen.de
[20] http://de.wikipedia.org/wiki/Front-End_und_Back-End
[21] http://www.latex-project.org/
[22] http://php.net/manual/de/security.database.sql-injection.php
[23] http://php.net/manual/de/function.vsprintf.php
[24] http://php.net/manual/de/ref.session.php
[25] http://www.latex-project.org/
[26] http://www.tug.org/applications/pdftex/
[27] http://goo.gl/QTrKh
[28] http://www.openschoolserver.net/
[29] z.B.
https://help.ubuntu.com/community/ApacheMySQLPHP
https://help.ubuntu.com/12.04/serverguide/httpd.html
[30] http://www.adminer.org/
“Why is Adminer better than phpMyAdmin?“, http://www.adminer.org/de/phpmyadmin/