Planung, Implementierung, Test und Einfhrung eines web-basierten Notenerfassungssystems

Besondere Lernleistung Technikwissenschaft Dokumentation:

MVC-Framework und Benutzeroberflche 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 AttributionNonCommercial-NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-ncnd/3.0/.

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

Inhaltsverzeichnis
1 Einfhrung ................................................................................ 5
1.1 Hintergrund und Entstehung .......................................................................... 5 1.2 Verwendete Typographie ................................................................................. 6 1.3 Problemstellung .................................................................................................... 6 1.3.1 Datenbanksystem................................................................................................6 1.3.2 Weiterverarbeitung ...........................................................................................7 1.3.3 Weitere Anforderungen und Ziele ...............................................................7 1.3.4 Sicherheit ................................................................................................................7 1.4 Client-Server-Prinzip .......................................................................................... 8 1.5 Verwendete Programmiersprachen, Techniken und Module ............ 8 1.6 Verwendete Entwicklertools ......................................................................... 10

MVC-Framework..................................................................... 11

2.1 Code-Architektur ................................................................................................ 11 2.2 Das Model-View-Controller-Konzept ......................................................... 11 2.3 MVC_Framework ................................................................................................ 12 2.3.1 Ordnerstruktur .................................................................................................. 12 2.3.2 Konfiguration und Installationsassistent ............................................. 14 2.3.3 Erweiterung der Konfiguration in der notendb2 .............................. 14 2.3.4 Routing der HTTP-Anfragen ....................................................................... 15 2.3.5 Schnittstelle der Controller ......................................................................... 16 2.3.6 Routing-Beispiele ............................................................................................. 16

Datenbank und Modelle ......................................................... 17

3.1 Datenbank ............................................................................................................. 17 3.1.1 Kriterien und Planung ................................................................................... 17 3.1.2 Umsetzung ........................................................................................................... 19 3.1.3 Sptere nderungen ....................................................................................... 21

Back-end ................................................................................ 22

4.1 Modelle ................................................................................................................... 22 4.1.1 Strukturierung der Modelle ........................................................................ 22 4.1.2 Modelle im MVC Framework....................................................................... 23 4.2 Sessionverwaltung ............................................................................................. 26 4.2.1 Lehrer Login ....................................................................................................... 26

Controller und Oberflche....................................................... 28

5.1 Willkommensbildschirm ................................................................................. 28 5.2 Controller ............................................................................................................... 30 5.2.1 controller.php .................................................................................................... 30 5.2.2 Alle Controller.................................................................................................... 31 5.3 Benutzeroberflche ........................................................................................... 33 5.3.1 Benutzermen ................................................................................................... 33 5.3.2 Administrationsmen..................................................................................... 33 5.3.3 Hauptmen ......................................................................................................... 33 5.3.4 Schnellauswahl fr Datei.............................................................................. 33 5.3.5 Onlinehilfe ........................................................................................................... 33 5.3.6 Detaillierte Liste aller aktuellen Dateien .............................................. 33

Praxis ..................................................................................... 35

6.1 Systemvoraussetzungen ................................................................................. 35 6.2 Installation ............................................................................................................ 36 6.3 Leitfaden zur Administration........................................................................ 38 6.4 Beispiel einer Erweiterung ............................................................................ 38 6.4.1 Datenbankfeld hinzufgen .......................................................................... 39 6.4.2 Modell anpassen (SchuelerModel) ........................................................... 39 6.4.3 Liste anpassen ................................................................................................... 40

7
7.1 7.2 7.3 7.4

Ausblick .................................................................................. 41
Fazit ......................................................................................................................... 41 Offene Punkte ...................................................................................................... 41 Mgliche Erweiterungen................................................................................. 41 Mgliche Verwendungen ................................................................................ 42

Anlagen .................................................................................. 43

1 Einfhrung
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 Hintergrnde. Die entstandene Software trgt den internen Namen notendb2, der sich auch in der Dokumentation wiederfindet.

1.1 Hintergrund und Entstehung

Bereits Ende 2011 kam Herr Rohde mit der Idee auf uns zu, eine Verwaltungssoftware fr Zeugnisnoten zu erstellen. Wir erstellten erste Entwrfe eines Datenbankschemas und entwickelten einen Prototyp fr die Benutzeroberflche. Dieser hie notendb1, daher rhrt 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 whrend der gesamten Entwicklungsdauer auf die kontinuierliche Zusammenarbeit mit den knftigen Nutzern der Software gelegt, also mit den Lehrern, insbesondere den Tutoren, des Beruflichen Gymnasiums. Durch das frhe Testen von Prototypen war es mglich, Fehler in der Planung frhzeitig zu erkennen.1 Auch einige Bugs, also Fehler in der Implementierung, wurden durch die Nutzer entdeckt und konnten so zeitnah behoben werden.2 Auch spter erhielten wir regelmig Feedback, Verbesserungsvorschlge und konstruktive Kritik, die es ermglichte, die Software benutzerfreundlicher zu gestalten und auf die Wnsche und Bedrfnisse der knftigen Nutzer einzugehen.

Anfangs war es vorgesehen, dass fr jedes Halbjahr die Kursthemen neu eingegeben werden mussten. Dies erwies sich als unpraktisch, sodass wir mit den Kursvorlagen eine Mglichkeit integrierten, die Kursdaten einmalig einzulesen und spter anzupassen. 2 Bei der gleichzeitigen Bearbeitung von Kurslisten durch mehrere Nutzer konnte es zu Datenverlusten kommen. Auch dieser Fehler wurde bereits sehr frh bei einem Probelauf mit Untersttzung von mehreren Tutoren entdeckt, bevor er Schden an echten Daten verursachen konnte.

1.2 Verwendete Typographie

In dieser Arbeit werden zum besseren Verstndnis 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.

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

1.3.1 Datenbanksystem
Die fr die Zeugnisse des Beruflichen Gymnasiums der Werner-vonSiemens-Schule erforderlichen Daten, also Noten und Fehlstunden, sollen in einer Datenbank zur spteren Weiterverarbeitung erfasst werden. 1 Die Lehrer der Schule sollen verwaltet werden und die Mglichkeit haben, sich mit einem Krzel und einem Passwort am System anzumelden. 2 Zu jedem Lehrer sollen Anrede, Titel, Vorname, Name und Krzel 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 knnen. 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 Schler und Kurse verwaltet werden, wobei ein Schler an mehreren Kursen teilnehmen kann, und ein Kurs mehrere teilnehmende Schler haben kann. Zu jeder Kursteilnahme soll eine Zeugnisnote, die Anzahl der Fehlstunden sowie die Anzahl der unentschuldigten Fehlstunden verwaltet werden. Zu jedem Kurs sollen die gleichen Daten wie zu einer Kursvorlage gespeichert werden, da diese zur Archivierung kopiert werden.

Auerdem 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 Schler, Kurse und Zuordnungen sollen fr jede Jahrgangsstufe in einem jeden Schulhalbjahr in einem unabhngigen Datenbestand (Datei) verwaltet werden, um die Daten leichter archivieren zu knnen. 11 Jeder Datei werden durch den Administrator ein oder mehrere Lehrer zugeordnet, die fr die Verwaltung dieser Datei zustndig sind (Tutor). Ein Lehrer kann Tutor fr mehrere Dateien sein.

1.3.2 Weiterverarbeitung
12 Die eingegebenen Daten sollen von den Tutoren zur weiteren Verwendung exportiert werden knnen. 13 Hierbei soll eine Auswahl der Daten nach Tutorengruppe mglich sein. 14 Die Daten sollen allgemeine Angaben zum Schler, 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.

1.3.3 Weitere Anforderungen und Ziele

16 Der Zugriff auf das System soll von verschiedenen schulinternen Computerarbeitspltzen, eventuell auch von Lehrernotebooks, mglich sein. 17 Installations- und Wartungsaufwand an den Arbeitsplatzrechnern soll mglichst gering sein. 18 Die Software soll mglichst bedienerfreundlich sein, sodass auch Computerlaien sie nach Einweisung verwenden knnen.

1.3.4 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 Aussphen von Zugngen oder Daten zu verhindern. 24 Die Software sollte nach Mglichkeit nicht anfllig fr gngige Angriffsmethoden3 sein.

1.4 Client-Server-Prinzip
Um die Anforderungen 16 und 17 zu erfllen 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 Verfgung stellt. Dies hat den groen Vorteil, dass auf den ClientSystemen auer einem (standardmig vorhandenen) Web-Browser keine weitere Software installiert und aktuell gehalten werden muss. Auerdem kann so Anforderung 23 leicht erfllt werden, indem HTTPS aktiviert wird.

1.5 Verwendete Programmiersprachen, Techniken und Module

Serverseitig kommt die Programmiersprache PHP4 (kurz fr PHP: Hypertext Preprocessor) zum Einsatz. Diese whlten wir, da sie die am weitesten verbreitete und am hufigsten eingesetzte Sprache zum Erstellen von Websites und -anwendungen ist, als freie Software kostenfrei einsetzbar ist und wir bereits gute Kenntnisse darin besaen. Auerdem ist PHP plattformunabhngig und leicht einzurichten. Es sind jedoch auch einige Unzulnglichkeiten aufzufhren, wie die teilweise fehlertrchtige schwache Typisierung, und die historisch gewachsene und daher meist nicht objektorientierte
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

Standardbibliothek. Letzteres kann jedoch durch Entwicklung von objektorientierten Wrapperklassen fr wichtige Bereiche wie den Datenbankzugriff behoben werden. Dies haben wir in unserem selbst entwickelten Framework, welches im nchsten Kapitel beschrieben wird, umgesetzt. Die verhltnismig geringe Ausfhrungsgeschwindigkeit von PHPSkripten stellt in dieser Anwendung dagegen kein Problem dar, da die Anzahl der Aufrufe, verglichen mit anderen Anwendungsfllen, extrem gering ist. Zur Datenhaltung nutzen wir das relationale Datenbankverwaltungssystem MySQL5, welches ebenfalls zu den am weitesten verbreiteten zhlt. Es ist wie PHP als freie Open-SourceSoftware verfgbar. Clientseitig werden, wie es bei Webanwendungen zwangslufig der Fall ist, HTML, CSS und JavaScript eingesetzt. Bei HTML (kurz fr Hypertext Markup Language) handelt es sich um eine Auszeichnungssprache zur Strukturierung von Inhalten6. Cascading Style Sheets (CSS) sind die dazu gehrige Sprache fr Formatvorlagen, die ntig ist, um die Ausgabe zu gestalten. JavaScript wird in unserer Anwendung nur vereinzelt genutzt, hauptschlich um Eingabeberprfungen und hnliche Aufgaben bereits clientseitig vornehmen zu knnen und somit durch schnellere Rckmeldungen die Benutzerfreundlichkeit zu erhhen. Wir verwenden zur besseren Browserkompatibilitt und zur Erleichterung der Entwicklung die JavaScript-Bibliothek jQuery7.

5 6

http://www.mysql.com/ http://de.wikipedia.org/wiki/Hypertext_Markup_Language 7 http://jquery.com/

1.6 Verwendete Entwicklertools

Zur Versionsverwaltung und Sicherung des Quellcodes verwenden wir Git, eine freie Software zur verteilten Versionsverwaltung von Dateien8. Zum Bearbeiten des Quellcodes verwendeten wir die Editoren Notepad++9, ScriptIDE10 und Sublime Text11. Der Serverzugriff fand auerdem mit ssh12, PuTTY13 und WinSCP14 statt. Zum Datenbankzugriff wurde Adminer15 und Sequel Pro16 benutzt. Zur Kommunikation whrend der Entwicklung untereinander haben wir meist Skype eingesetzt. Der Austausch mit den Benutzern fand sowohl persnlich in der Schule als auch per E-Mail statt.

8 9

http://de.wikipedia.org/wiki/Git 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/

2 MVC-Framework
2.1 Code-Architektur
Das Projekt ist nach dem in der Softwareentwicklung seit ber 30 Jahren verbreiteten Model-View-Controller-Konzept17 strukturiert. Dieses Konzept erleichtert die sptere Erweiterung der Software sowie die Anpassung an genderte Anforderungen. Es hat sich whrend der Entwicklung der Anwendung bereits bewhrt, da Wnsche und Feedback der Nutzer sowohl whrend als auch nach der Entwicklung schnell umgesetzt werden konnten.

2.2 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 bergnge sind nicht mehr so klar definiert wie bei der ersten Beschreibung des Konzepts, die im Rahmen der Entwicklung von Smalltalk stattfand. Insbesondere die bergnge zwischen Model und Controller knnen flieend sein. Im Folgenden wird ein fr Webanwendungen gngiges Verstndnis 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 knnen ebenfalls im Model enthalten sein. Der Controller (dt. Steuerungsschicht) nimmt Anfragen (HTTPRequests) vom Browser, und damit vom Benutzer der Anwendung, entgegen, und ruft entsprechend seiner internen Logik Daten aus den Modellen ab und ldt sie zur Darstellung in eine oder mehrere Prsentationen. Anhand von Benutzeraktionen kann der Controller
17

Quellen und weitere Informationen zum Thema MVC: http://openbook.galileocomputing.de/oo/oo_06_moduleundarchitektur_001.ht m http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Daten in den Modellen ndern. Auerdem entscheidet der Controller anhand verschiedener Bedingungen (z.B. Rechte des Benutzers), ob die mglichen Benutzeraktionen in der Prsentation eingeschrnkt werden mssen. Die Aufgabe des View (dt. Prsentation) ist die Darstellung der Daten aus den Modellen. Es ermglicht 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.

2.3 MVC_Framework
Als Grundlage zur Umsetzung dieses Projektes haben wir ein PHPFramework nach diesem Konzept entwickelt. Es trgt den internen Namen MVC_Framework. Wir haben uns bewusst zur Entwicklung eines eigenen Frameworks entschieden, einerseits aufgrund des damit einhergehenden Lerneffekts und dem besseren Verstndnis als bei der Nutzung eines vorgefertigten Frameworks, andererseits um die Anwendung mglichst einfach zu halten und nur die Funktionen zu integrieren, die tatschlich bentigt werden.

2.3.1 Ordnerstruktur
Durch unser Framework ist eine bestimmte Ordnerstruktur fr 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 enthlt. 2.3.1.1 /index.php Diese Datei stellt den zentralen Einsprungspunkt des Frameworks dar. Alle Aufrufe der Anwendung landen zunchst in der index.php. Sie ist dafr zustndig, alle bentigten Grundmodule sowie die Konfiguration zu laden und schlielich das Routing-Modul anzustoen. 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 enthlt. 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 enthlt die ntigen Befehle, um die Datenbankstruktur fr die Anwendung zu erzeugen. 2.3.1.4 /.htaccess Die Konfigurationsdatei fr 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 enthlt 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 enthlt 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 erlutert. 2.3.1.8 /controller/controller.php Diese Datei enthlt 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 bentigt werden (z.B. zur Sitzungs-, Rechte- und Benutzerverwaltung). Hinweis: Es ist aufgrund dieser Benennung weder mglich noch sinnvoll, einen ControllerController zu erstellen.

2.3.2 Konfiguration und Installationsassistent

Folgende Einstellungen sind hier standardmig zu finden: Zugangsdaten zur Datenbank (IP-Adresse oder Hostname des MySQL-Servers, Benutzername, Passwort, Name der Datenbank) Salt-Wert fr die Passwort-Verschlsselung Das URL-Prefix der Anwendung, welches fr die Generierung interner Links verwendet wird (meist /) Der Installationsassistent fhrt dabei Schritt fr Schritt durch die Installation: 1 berprfen der Dateiberechtigungen (Ist die Konfigurationsdatei schreibbar?) 2 Abfrage der MySQL-Zugangsdaten und berprfen der Verbindung 3 Erstellen der bentigten Datenbank-Tabellen anhand der /create_tables.sql 4 Abfrage weiterer globaler sowie anwendungsspezifischer Einstellungen 5 Schreiben der Konfigurationsdatei und Abschluss des Assistenten

2.3.3 Erweiterung der Konfiguration in der notendb2

Die Konfiguration wurde fr die Notendatenbank um einige anwendungsspezifische Parameter ergnzt. Diese sind ein abweichender Seitentitel, ein einstellbares Schullogo sowie das Passwort fr 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 Eintrge, die notendb2-spezifische Erweiterungen gegenber dem MVC_Framework darstellen. Schlssel des assoziativen $SITE_CONFIG-Arrays DB_HOST DB_USER DB_PASSWORD Vorgabewert localhost Erw. Beschreibung Hostname des zu nutzenden MySQLServers Benutzername zur Anmeldung am MySQL-Server Passwort zur Anmeldung am MySQLServer

Schlssel des assoziativen $SITE_CONFIG-Arrays DB_NAME LOGIN_SALT INI_DONE

Vorgabewert (autom. gen.) true

Erw.

Beschreibung Name der Datenbank Saltwert zur Sicherung des PasswortHashs Wenn nicht gesetzt, wird bei jedem Aufruf automatisch der Installationsassistent gestartet. Wird nach dessen Abschluss automatisch auf true gesetzt. Prfix zur Generierung interner Links (z.B. http://notendb.example.org/ oder /notendb2/) Muss mit / enden.

URL_PREFIX

(autom. gen.)

LOGIN_ROOTPASW

Passwort fr den SuperadministratorZugang root. Erforderlich, um den Installationsassistent ggf. erneut zu ffnen. Angezeigter Name der Anwendung. Erscheint in der Kopfzeile und im Browsertitel (<title>-Tag) Hintergrundfarbe der Kopfzeile der Anwendung URL zu einem Bild, welches auf der Begrungsseite nach Einloggen erscheint (z.B. Schullogo)

HEADER_SITE_TITLE

NotenVerwaltung #202020

HEADER_BG_COLOR HEADER_WELCOME_IMAGE

x x

2.3.4 Routing der HTTP-Anfragen

Eine HTTP-Abfrage wird, wenn sie den Serverrechner erreicht, zunchst von einem Webserver-Dienst entgegengenommen (blicherweise der Apache2-Webserver). Dieser ruft, sofern sich die Anfrage auf ein Verzeichnis bezieht, in dem eine MVC_FrameworkAnwendung abgelegt ist, seiner Konfiguration in der .htaccess folgend, zunchst das zentrale Einsprungs-Skript index.php auf. Dieses ldt zunchst alle bentigten Systemkomponenten. Anschlieend 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 zurckgibt. Die Pfadkomponenten bestimmen den zu ladenden Controller und die darin aufzurufende Methode. Das Routing erfolgt unabhngig von Sitzungszustand und HTTPMethode. Diese Umstnde werden im Controller selbst bercksichtigt.

2.3.5 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 Anhngen des Suffix .php ermittelt. Der Klassenname wird durch Umwandeln des ersten Buchstabens in Groschreibung und durch Anhngen des Suffix Controller ermittelt. Ist keine erste Pfadkomponente angegeben, wird als Standardwert default angenommen. Die zweite Pfadkomponente bestimmt die aufzurufende Methode des Controllers. Es knnen 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.

2.3.6 Routing-Beispiele
Aufruf
GET / GET /admin/dashboard POST /kurs/edit/25 GET /example

Controller-Datei controller/default.php controller/admin.php controller/kurs.php

Controller-Klasse
DefaultController AdminController KursController

Methodenaufruf
index() dashboard() edit(25) index()

controller/example.php ExampleController

3 Datenbank und Modelle

3.1 Datenbank
Zur Speicherung der anfallenden Daten haben wir uns fr eine Speicherung durch eine MySQL-Datenbank entschieden. Diese war in der Linux-Umgebung des Servers verfgbar 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 sptere Wartung oder Vernderung der Datenbankstruktur zu ermglichen, sowie eine mglichst fehlerfreie Entwicklung zu erreichen. Hierbei wurde die Datenbank weitestgehend normalisiert18 und im spteren Verlauf der Entwicklung um verschiedene bentigte oder geforderte Elemente erweitert.

3.1.1 Kriterien und Planung

Als Kriterien fr die Datenbank zur Notenerfassung wurden zu Beginn des Projekts folgende Anforderungen gestellt: 1. Die Zeugnisse mssen reproduzierbar sein Die Zeugnisse mssen dauerhaft in ihrer originalen Form reproduzierbar sein. Nachtrgliche nderung der Schlerdaten drfen sich daher nicht auf vorherige Zeugnisse auswirken. 2. Schler mssen einem Jahrgang zugeordnet sein Alle Schler im System mssen einem Jahrgang, einem Halbjahr und einer Klassenstufe zugeordnet werden. 3. Schler mssen Kursen zugeordnet werden knnen Alle Schler mssen den von ihnen belegten Kursen zugeordnet werden knnen. Dabei mssen jedem Schler im Kurs eine unabhngige Note, sowie Fehlstunden und unentschuldigte Fehlstunden, zugeordnet werden knnen. 4. Kurse mssen Lehrern zugeordnet werden knnen Fr die Zeugnisausgabe ist eine Zuordnung der Lehrer zu den von ihnen unterrichteten Kursen erforderlich. Dies dient zustzlich der Autorisierung eines Lehrers, um die Noten

18

http://de.wikipedia.org/wiki/Normalisierung_%28Datenbank%29

seiner Kurse eingeben oder ndern zu drfen. Ein Lehrer kann mehrere Kurse besitzen, ein Kurs kann durch mehrere Lehrer geleitet werden knnen. 5. Kurse mssen einem Jahrgang/Halbjahr zugeordnet sein 6. Ein Jahrgang/Halbjahr muss Tutoren enthalten Die Tutoren der Jahrgnge sind den entsprechenden Jahrgngen zuzuordnen. Diese Zuordnung ist unabhngig von den Kursen, die sie im Jahrgang unterrichten. Auerdem wurden Lehrer- und Schlerdaten aus der Lehrer- und Schlerdatenbank19 (LUSD) des Hessischen Kultusministeriums in den Datenbestand importiert. Diese schon vorhandenen Datenstze 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 gefhrt.
19

http://www.lusdportal.hessen.de

3.1.2 Umsetzung
Die Umsetzung des ERMs in ein relationales Datenbankmodell wurde mit einigen Einschrnkungen in der dritten Normalform durchgefhrt. Eine Ausnahme bilden hier die Schlerdaten, welche fr jede Datei neu gespeichert werden. Dies ist notwendig, um Zeugnisse reproduzierbar in der Datenbank zu halten. Bei einer nderung der Schlerdaten drfen diese nicht ltere Zeugnisse betreffen und werden deshalb fr jede Datei, und damit mit jedem Halbjahr, erneut angelegt. 3.1.2.1 Bezeichnungen Die Verbindungstabellen zur Auflsung der n:m-Beziehungen der Lehrer-Kurs und Schler-Kurs-Tabellen wurden nach dem Muster rel_tabelle1_tabelle2 angelegt. Da die Bezeichnung Tutor die Verbindung Lehrer-Datei in der Realitt 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 das Tabellennamens (als Kleinbuchstabe)+id wurden kombiniert. Beispiel: Der Primary Key der Tabelle datei wurde aus dem Anfangsbuchstaben d und id zu did zusammengefhrt. 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 fr 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 enthlt 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 aufgelst: datei Die Verbindung Jahrgang/Halbjahr/Klassenstufe ist das grundlegende Element der Tabellenstruktur. Diese Tabelle verbindet Tutoren, Schler und Kurse und gruppiert sie somit in der Datenbank zu logischen Zusammenschlssen. kurs Ein Kurs stellt die fr das Zeugnis und den Zeugnisdruck geforderten Kursdaten in der Datenbank dar. Diese Daten werden im Zeugnisdruck bercksichtigt und knnen pro Kurs gesetzt werden. Die Verbindung der Schler 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 Schler welche fr den spteren Zeugnisdruck bentigt werden. Jeder Schler ist ber die ID sid eindeutig in einem Datensatz identifizierbar. Um nachtrgliche Zeugnisdrucke zu ermglichen werden die Schlerdaten in jeder Datei neu erstellt und dieser ber den Foreign Key did zugeordnet. lehrer Diese Tabelle Lehrer beinhaltet die Logindaten der Notendatenbank sowie die fr den Zeugnisdruck relevanten Lehrerdaten. Die Verknpfung 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 zustzliche Feld is_admin speichert die Zugriffberechtigung auf den Adminbereich. Es sollte ausschlielich fr Administratorzugnge 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 fr zuknftige Verwendung reserviert und wird derzeit nicht benutzt. Es knnte fr 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 enthlt die Zuordnungen der einzelnen Schler zu ihren jeweiligen Kursen. In der Zuordnung werden zustzlich die Noten, Fehlstunden und unentschuldigten Fehlstunden gespeichert. Erfllte Anforderungen XXX

3.1.3 Sptere nderungen

Die Datenbank wurde im Verlauf der Entwicklung um verschiedene Attribute erweitert, die Beziehungen der Tabellen zueinander blieb aber, mit Ausnahme der Kursvorlagen, unverndert. 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 fhrte, hielten wir es fr sinnvoll, Kurse zustzlich whrend der Bearbeitung zu. Hierzu wurden im Datenbankdesign die Attribute editlocked_by_lid und editlocked_since in der Tabelle kurs eingefgt, welche durch Controller-Methoden die Sperrung von Kursen sicherstellen. Zur besseren bersicht der verschiedenen Sperren wird zustzlich das Datum der Sperrung gespeichert. Da die Sperren zeitlich unbegrenzt sind, knnen Administratoren alle Sperren im Adminbereich aufheben, wenn diese von Lehrern vergessen wurden. Zustzlich zu geplanten Daten wurden die Felder display_position und export_position eingefhrt, welche eine geordnete Ausgabe der Fcher im Zeugnis und in Kontrollansichten angeben. 3.1.3.2 Erweiterte Anforderungen zur Anwendungs- und Datensicherheit Aufgrund einiger Anfragen wurde die Mglichkeit eingefhrt, Dateien zu archivieren und Kurse einzureichen, um eine nachtrgliche nderungen der Daten zu verhindern. Hierzu wurde das Attribut archiviert in die Tabelle Datei eingefhrt, welche von

verschiedenen Controllern zur Steuerung der Schreibrechte verwendet wird. Des Weiteren knnen Kurse nun eingereicht werden. Dies wird in der Datenbank durch das Attribut eingereicht in der Tabelle kurs realisiert, welches die Bearbeitung fr Kurslehrer sperrt, so dass die Noten nach dem Einreichen nicht mehr verndert werden knnen.

4 Back-End
Unter dem Begriff Back-End bezeichnet man in der Informatik den Teil einer Anwendung, welcher anfallende Daten verwaltet und mit Systemschnittstellen interagiert20. 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 erfllenden Aufgaben sind die Verwaltung und Speicherung der anfallenden Schler, Lehrer und Kurs-Daten, sowie das Strukturieren der Ein- und Ausgabe dieser, welches im Folgenden ber Model-Objekte realisiert wurde.

4.1 Modelle
Modelle haben im MVC-Konzept die Aufgabe der Verbindung von Anwendung und Datenbestand. Zustzlich knnen Modelle Funktionen zur Vereinheitlichung verschiedener Ein- oder Ausgabedaten enthalten und Datenbankabfragen ausfhren. In unserem Notensystem wurde die Aufteilung der Modelle an die Datenbankstruktur angepasst, so dass jedes Model eine Tabelle der Datenbank reprsentiert. 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 zustzlich das Modell session bentigt, 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.

4.1.1 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
20 21

http://de.wikipedia.org/wiki/Front-End_und_Back-End http://www.latex-project.org/

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 folgendermaen 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, ermglicht hierbei den Zugriff auf Verbindungstabellen mit 2 Foreign Keys, welche mittels der Klassenattribute idLCol und idRCol angegeben werden knnen.

4.1.2 Modelle im MVC Framework

Die folgende Liste enthlt 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 knnen 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 dafr, dass SQL-Abfragen in der Klasse gekapselt werden knnen. Zum Schutz vor SQL-Injection-Angriffen22 wird die PHP-Funktion mysql_real_escape_string eingesetzt. Die Klasse kapselt die PHP-MySQL-Anbindung und stellt somit elementare Funktionen zum Abfragen einzelner Datenstze (Funktion: getsingle) oder aller Daten einer spezifischen
22

http://php.net/manual/de/security.database.sql-injection.php

Abfrage (Funktion: getall) zur Verfgung. Die Funktionen doQuery und execute dienen zum Senden von schreibenden SQL-Komandos an die Datenbank (INSERT, UPDATE, DELETE). Um eine mgliche 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 vsprintf23 in den SQL-Querystring geschrieben und stehen somit, unabhngig vom bergebenen Variablentyp, im gewnschten Format in der Zeichenkette. databaseRel -> database Diese Klasse erlaubt Zugriff auf Tabellen welche n:mBeziehungen auflsen, d.h. Foreign Keys zu zwei Tabellen enthalten. Die Variablen $idLCol und $idRCol mssen in abgeleiteten Klassen mit den Namen der Foreign-Keys beschrieben werden. In den abgeleiteten Klassen knnen so, Datenbank Eintrge 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 gefhrt. Alle Befehle knnen 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 Lschen einzelner LeftRight-Column-ID Kombinationen durch die Funktionen addByRel, deleteByRel und setByRel. Funktionen ohne Spaltenangabe im Namen bentigen zur korrekten Ausfhrung 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 zum bearbeiten der Editlocks welche von Controllern zum Sperren oder Entsperren verschiedener Kurse genutzt werden. Zustzlich wurde die Funktion get_ordered_list implementiert,

23

http://php.net/manual/de/function.vsprintf.php

welche eine fr die Anzeige sortierte Liste aller Kurse der Datei zurckgibt. kurs -> database Die Klasse reprsentiert die Tabelle kurs des DatenbankERMs. Die Implementation unterscheidet sich von der Parentklasse durch vorgefertige Abfragen, welche von Controllern hufig genutzt werden, um bestimmte Datenrelationen aus der Datenbank zu filtern. Zustzlich wurden die Funktionen set, get_all und get_by_id berschrieben um eine zustzliche Sortierung der QueryDaten zu implementieren. Nachtrglich wurde auerdem die Funktion delete abgendert, da diese einen Fehler in der Fehlstundenberechnung hervorrief (siehe Anhang). kurs_template -> database (keine zustzlichen Funktionen) lehrer -> database Dieses Model leitet sich von dem DatabaseModel ab und gibt eine Reprsentation der Tabelle lehrer wieder. Zustzlich enthlt sie Methoden um das Passwort eines Lehrers zu prfen und die entsprechenden Rechte, bei erfolgreichen Login, auszugeben sowie eine Methode zum Setzen von Passwrtern. rel_lehrer_kurs -> databaseRel (keine zustzlichen Funktionen) rel_schueler_kurs -> databaseRel (keine zustzlichen Funktionen) schueler -> database Diese Klasse reprsentiert die Tabelle Schler des ERMs. Die zustzliche Funktion get_noten_uebersicht erzeugt eine Liste aller Noten eines Schlers in der Datenbank. session -> model Das Session Model verwaltet die Rechte und Loginberechtigungen einzelner Sessions24. Die Methoden isRoot, isAdmin und isTutor geben eine Boolean Value zurck, welche von Controllern zur Rechteverwaltung in der GUI genutzt werden. Zustzlich knnen weitere Attribute des eingeloggten Users ber die Funktion getUser ausgelesen werden. tutor -> database (keine zustzlichen Funktionen) xmlexport -> database

24

http://php.net/manual/de/ref.session.php

Dieses Model wird intern zur Erstellung der Zeugnisse mittels LaTeX25 und PDFLaTeX26 bentigt. 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 Schlerdaten zu einer mglichen OfflineBearbeitung vorgesehen und wird derzeit nicht genutzt.

4.2 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 schtzt.

4.2.1 Lehrer Login

Der Zugriff auf die Anwendung wird nur fr Lehrer erlaubt. Fr eine Anmeldung stellt das System eine fftenliche Seite zur verfgung, welche die Authentifizierung des Lehrers mittels Benutzername und Passwort erlaubt. Die Logindaten werden nach dem Absenden durch das session und lehrer Model geprft. Hierzu wurden verschiedene Techniken verwendet, um die Passwort Daten, bei einem mglichen Datenverlust zu schtzen. 27 4.2.1.1 Datenverschlsselung Um die Passwrter bei Datenverlust weitestgehend zu sichern werden diese ber einen Hashalgorithmus verschlsselt und anschlieend in der Datenbank gesichert. Durch die Einwegverschlsselung mittels der md5 XXXSource Funktion sind die Passwrter unumkehrbar verschlsselt. 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 Passwrter ungltig werden gesetzt werden mssen. 4.2.1.2 Rainbowtables Zur Abwehr von Rainbow-Table-Angriffen auf die Datenbank wird ein zustzlicher Salt XXSource verwendet, welcher an das Passwort
25 26

http://www.latex-project.org/ http://www.tug.org/applications/pdftex/ 27 http://goo.gl/QTrKh

angehngt wird, um allgemeine Rainbow-Tables unwirksam zu machen. Weiterhin wird der Username im Hash verarbeitet um die Hashkombinationen fr jeden User zu variieren und somit eine allgemeine Rainbow-Table fr den gesamten Datenbestand unwirksam zu machen.

5 Controller und Oberflche

5.1 Willkommensbildschirm
Nachdem der Benutzer sich mit Krzel und Passwort authentisiert hat, erscheint der nachfolgend abgebildete Willkommensbildschirm.

Hier hat der Benutzer sofort Zugriff auf alle wichtigen Menpunkte: 1 Benutzermen und Administrationsmen 2 Hauptmen Kursliste Zuordnung von Schlern zu Kursen Tabelle zur Notenvergabe Schlerliste Zeugnisdruck 3 Schnellauswahl fr 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 bentigte Dateien mit dem require_onceBefehl 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 ldt 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 zunchst 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 anschlieend mit require_login sicher, dass ein Benutzer eingeloggt ist, und ldt weitere bentigte Modelle. Auerdem initialisiert er die View-Variable $Dateien, die spter die Datei-Schnellauswahl (3) befllt. Danach wird die entsprechende Controller-Methode aufgerufen, hier index(). Diese lsst 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-ViewVariablen Inhalt abgelegt. Schlielich wird die Methode Controller.display_layout aufgerufen, die durch das View default_layout.php die engltige Ausgabe erzeugen lsst 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();

5.2 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.

5.2.1 controller.php
Die Basisklasse Controller enthlt 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 ausgewhlte Datei erfordern. Der Konstruktor der Basisklasse enthlt Code zur Initialisierung der Anwendung. Es werden global bentigte Modelle geladen sowie globale View-Variablen zugewiesen. Auerdem 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.

5.2.2 Alle Controller

5.2.2.1 admin.php
Erreichbar ber den Menpunkt Administrationsbereich im Benutzer- und Administrationsmen

Dieser Controller enthlt Formulare und Aktionen fr administrative Aufgaben. Er ist nur fr Benutzer zugnglich, die als Administratoren eingetragen sind (Feld is_admin), sowie fr den SuperAdministrator root. Es erscheint zunchst eine bersichtsseite, die den Zugriff auf die verschiedenen Funktionen gewhrt. 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 zustndig fr die Ausgabe der Willkommensseite. 5.2.2.3 kurstemplate.php
Erreichbar ber den Menpunkt Kursvorlagen im Benutzer- und Administrationsmen

Der KurstemplateController wurde nachtrglich eingefhrt, um die hinzugefgte Anforderung 3 zu erfllen. Es ermglicht, Kursvorlagen zu erstellen, zu bearbeiten, zu lschen und eine Liste aller Kursvorlagen zu betrachten. 5.2.2.4 public.php
(reserviert fr sptere Verwendung)

5.2.2.5 statistics.php
(reserviert fr sptere Verwendung)

5.2.2.6 user.php
Erreichbar ber die Menpunkte Passwort ndern und Ausloggen im Benutzerund Administrationsmen

UserController ermglicht einem eingeloggten Nutzer, sein Passwort zu ndern sowie sich auszuloggen. Nicht eingeloggte Besucher werden bei allen Aufrufen mittels der Methode Controller.require_login zwangslufig auf UserController.login umgeleitet.

5.2.2.7 kurs.php
Erreichbar ber den Menpunkt 1. Liste der Kurse im Hauptmen

Der KursController stellt Methoden zur Verfgung, um die Liste der Kurse einer Datei abzurufen, Kurse aus Vorlagen zu erstellen, die betreuenden Lehrer des Kurses festzulegen, Kurse zu bearbeiten und zu lschen. 5.2.2.8 offline.php
(derzeit auer Betrieb) War erreichbar ber einen zustzlichen Punkt im Hauptmen Offline

Es war geplant, eine Offlineversion der Notenverwaltung zu erstellen. Die offline.php enthlt Methoden, um Kurse oder ganze Dateien fr die Offlineversion zu exportieren und um Daten aus der Offlineversion (eingegebene Noten) wieder zu importieren. 5.2.2.9 schueler.php
Erreichbar ber den Menpunkt Schlerliste im Hauptmen

Dieser Controller stellt eine Liste aller Schler in einer Datei dar und bietet Methoden an, um einzelne Schler einzufgen, um Schler gesammelt zu importieren sowie um einzelne Schler zu bearbeiten, zu lschen und Notenbersichten einzelner Schler zu generieren. Die Importfunktion akzeptiert Daten in folgendem Format, welches das Exportformat des an der Schule eingesetzten OpenSchoolServer28 nachbildet: Die erste Zeile enthlt 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 Menpunkte 2. Zuordnung, 3. Notenvergabe und Zeugnisdruck im Hauptmen

Dieser Controller ist fr die Ausgabe und das Bearbeiten der verschiedenen Kreuztabellen zustndig, die in der Anwendung dargestellt werden. Dies sind die Tabelle zur Anzeige der Schler-Kurs-Zuordnung, die Tabelle zur Zuordnung von Schlern zu einem Kurs sowie die Tabelle zur Anzeige der Noten und die Tabelle zur Notenvergabe.
28

http://www.openschoolserver.net/

Auerdem beinhaltet dieser Controller die Methoden zur Auswahl der zu exportierenden Daten und zum Export als Microsoft-ExcelArbeitsblatt, als CSV oder PDF-Datei.

5.3 Benutzeroberflche
5.3.1 Benutzermen
Das Benutzermen enthlt Aktionen, die sich direkt auf den Zugang des aktuell eingeloggten Lehrers beziehen. Er kann darin sein Krzel sehen sowie sein eigenes Zugangspasswort ndern. Auerdem befindet sich hier der Menpunkt Abmelden, der aus Sicherheitsgrnden nach der Verwendung der Anwendung immer benutzt werden sollte, um die Sitzung zu beenden.

5.3.2 Administrationsmen
Der Menpunkt Administrationsbereich ist nur fr Benutzer mit Administrationsrechten sichtbar. Er ffnet die Seite bersicht fr Administratoren (kurz Admin-Dashboard). Diese Seite wird im Kapitel Leitfaden zur Administration nher beschrieben. Der Menpunkt Kursvorlagen ist nur fr die Tutoren einer Datei sichtbar. Sie knnen hier die Vorlagen ndern, die den Fachlehrern bei Eingabe ihres Kurses angeboten werden.

5.3.3 Hauptmen
Das Hauptmen enthlt Menpunkte, die sich auf die aktuell ausgewhlte Datei beziehen. Die Menpunkte sind in der Reihenfolge nummeriert, in der sie von einem Fachlehrer blicherweise verwendet werden.

5.3.4 Schnellauswahl fr Datei

Die Schnellauswahl ist als Drop-Down-Listenfeld realisiert, in dem alle Dateien aufgelistet werden. Sie wird fr eingeloggte Nutzer auf jeder Seite dargestellt, um ein bequemes Wechseln der ausgewhlten Datei zu ermglichen.

5.3.5 Onlinehilfe
Der Link Onlinehilfe verweist auf die URL http://notendbhilfe.wikilab.de/anleitungen/, unter der verschiedene Anleitungen als PDF-Dateien zur Verfgung stehen. Die Anleitungen sind auch als Anlage B und C beigefgt.

5.3.6 Detaillierte Liste aller aktuellen Dateien

Die Liste der Dateien auf der Startseite enthlt mehr Informationen, als die Schnellauswahl. Hier werden die Dateien hervorgehoben, fr die der eingeloggte Benutzer als Tutor eingetragen ist.

6 Praxis
In diesem Kapitel fassen wir einige Hinweise und Anleitungen zur Installation, Wartung, Verwendung und Weiterentwicklung unserer Software zusammen. Ausfhrlichere Schritt-fr-Schritt-Anleitungen und Handbcher sind dagegen im Anhang zu finden.

6.1 Systemvoraussetzungen
Clientseitig wird zur Noteneingabe nur ein Webbrowser (Firefox, Chrome, Safari) bentigt. Um Zeugnisse zu drucken ist zustzlich entweder Microsoft Office oder ein PDF-Betrachter (z.B. Adobe Reader) erforderlich. Serverseitig kommt ein Linux-System zum Einsatz, auf dem fr die Grundfunktionen ein LAMP-Stack (weit verbreitete WebserverEinrichtung 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 ntig, die hier nicht beschrieben werden knnen. Hierzu sind jedoch ausfhrliche Anleitungen im Internet zu finden.29 Fr verschiedene Zusatzfunktionen sind folgende weitere Pakete ntig: Fr die Erstellung von Microsoft Excel- Arbeitsblttern muss das Java Runtime Environment installiert sein. Fr die Erstellung von PDF-Dateien muss die TeX-Distribution TeXLive muss installiert sein. Die Installation wird fr Ubuntu und OpenSUSE wie folgt durchgefhrt: Ubuntu: # apt-get install texlive OpenSUSE: # zypper install texlive texlive-latex

29

z.B. https://help.ubuntu.com/community/ApacheMySQLPHP https://help.ubuntu.com/12.04/serverguide/httpd.html

6.2 Installation
Wenn die oben angegebenen Systemanforderungen erfllt 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 mglich: $ git clone https://github.com/maxweller/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).

Folgen Sie den Anweisungen des Installationsassistenten. Sie sollten insbesondere, falls noch nicht geschehen, eine eigene MySQL-Datenbank fr die Installation der notendb2 auf dem MySQL-Server einrichten. Nachdem ein Schritt erfolgreich abgeschlossen wurde, wird das graue Kreuz in der berschrift jeweils durch ein grnes Hkchen 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 knnen.

Hinweis: Sie knnen die whrend der Installation angegebenen Parameter jederzeit verndern, indem Sie den Installationsassistenten erneut aufrufen. Hngen Sie dazu an die URL zum Hauptverzeichnis der Anwendung install.php an. Sie bentigen zum erneuten Starten das Passwort des Superadministrators root, welches Sie bei der Installation vergeben haben. Sollten Sie dieses Passwort nicht mehr wissen, knnen Sie in der Konfigurationsdatei .htconfig.php nachsehen. Es befindet sich in der Zeile, die mit $SITE_CONFIG[LOGIN_ROOTPASW] beginnt.

6.3 Leitfaden zur Administration

In diesem Abschnitt beschreiben wir einige mglicherweise auftretende Probleme sowie Lsungen dafr. 6.3.1.1 Ein Benutzer hat sein Passwort vergessen. Als Administrator knnen Sie das Passwort eines beliebigen Nutzers zurcksetzen. 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 mchte Noten fr seinen Kurs eintragen, erhlt aber den Fehler Diese Spalte wird gerade von (Lehrername) bearbeitet und ist daher gesperrt. Wenn diese Fehlermeldung lnger 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. Auerdem sollten man sich nach der Verwendung immer Abmelden. Um alle Sperrungen zurckzusetzen, verwenden Sie Administrationsbereich -> Sperren zurcksetzen. Besttigen Sie die Sicherheitsabfrage mit OK. 6.3.1.3 Neue Dateien anlegen zum Beginn eines Schul(halb)jahres Das Anlegen neuer Dateien ist mglich unter Administrationsbereich > Dateien verwalten -> Erstellen. Dabei sollten gleich die Tutoren des Jahrgangs ausgewhlt werden. Mehrfachauswahlen sind mit gehaltener Strg-Taste mglich. Anschlieend werden unter Schlerliste die Schler aus dem OpenSchoolServer-Export in die neue Datei importiert. Dazu whlen Sie mit Datei auswhlen die Exportdatei aus und klicken anschlieend auf Importieren.

6.4 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 Ergnzung eines zustzlichen Feldes, um die E-Mail-Adresse eines Schlers zu speichern.

6.4.1 Datenbankfeld hinzufgen

Zunchst wollen wir in der zustndigen Tabelle schueler ein Feld mit dem Namen email einfgen. Dazu knnen wir entweder ein grafisches Tool wie Adminer30 nutzen, um der ein entsprechendes Feld von Typ VARCHAR(256) hinzuzufgen, oder wir nutzen folgendes SQL-Statement: 01 ALTER TABLE `schueler` 02 ADD `email` VARCHAR(255);

6.4.2 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 ergnzt 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 ); (Ergnzte Zeile in Fett hervorgehoben) Damit sind bereits alle ntigen nderungen vorgenommen, da der SchuelerController und das View zum Bearbeiten eines Schlers Ihre Informationen aus dem eben genderten Array $structure beziehen.

30

http://www.adminer.org/ Why is Adminer better than phpMyAdmin?, http://www.adminer.org/de/phpmyadmin/

6.4.3 Liste anpassen

Optional knnten wir die E-Mail noch als Spalte in der Schlerliste ergnzen. Die relevante Datei ist view/schueler_list.php. Hier fgen wir zunchst 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 fgen wir die jeweilige E-Mail-Adresse aus der Datenbank ein (zwischen Zeile 25 und Zeile 26) 26 > 27 <td><?= $d["geburtsdatum"] ?></td> <td><?= $d["email"] ?></td> <td><?php if(!$archiv): ?>

7 Ausblick
7.1 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 frhzeitige Einbeziehung der Anwender konnten Fehler und nderungen rechtzeitig erkannt und behoben werden. Probleme, welche das Projekt in der Entwicklung in der Umsetzung beeintrchtigen, traten nicht auf. Durch gute Absprache wrend der Entwicklung wurden alle Bereiche ohne Konflikte in der Codeumsetzung geschrieben und getestet.

7.2 Offene Punkte

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

7.3 Mgliche Erweiterungen

Wie jede Software wird auch diese nie endgltig fertig sein, da immer noch Erweiterungen und Verbesserungen denkbar sind. Im folgenden fhren wir einige Ideen auf, die an uns herangetragen wurden und die wir bisher noch nicht umgesetzt haben. In der Datenbank liegen fast alle ntigen Informationen vor, um nach dem dreizehnten Schuljahr vollautomatisch das Abiturzeugnis fr einen Schler zu generieren. Es msste die Angabe ergnzt werden, welche Kurse ein Schler in das Abitur einbringen mchte. Auerdem mssten die notwendigen Rechenvorschriften implementiert sowie eine Vorlage, entweder mit Microsoft Word oder mit LaTeX, angepasst bzw. erstellt werden. Denkbar wre auch die Anbindung des Logins fr Lehrer (evtl. auch fr Schler - siehe nchster Vorschlag) an den schulinternen Verzeichnisdienst ber das LDAP-Protokoll. Damit wre es nicht mehr ntig, gesonderte Logins und Passworte fr die notendb2 zu verwalten.

Eine Funktion zur Einsichtnahme in die eigenen Noten fr Schler wre ebenfalls interessant. Mit einer Exportfunktion in einem geeigneten Datenaustauschformat wre auch die Anbindung an den Abi-Rechner, den Manuel Groh im Rahmen einer Besonderen Lernleistung erstellt hat, mglich. Somit wrde das mhsame und fehlertrchtige Abtippen aus den Zeugnissen entfallen.

7.4 Mgliche Verwendungen

Die Datenbank wird zur Zeit fr das Berufliche Gymnasium verwendet. Die Datenbankstruktur und Codeumsetzung kann, durch die generische Umsetzung, allerdings auch in anderen Schulformen verwendet werden. Fr eine Portierung mssen unter Umstnden die Zeugnisvorlagen angepasst sowie die GUI leicht modifiziert werden.

8 Anlagen
Anlage A: Datenbankschema Anlage B: Anleitung zur Eingabe von Noten Anlage C: Anleitung zum Ausdruck von Zeugnissen Anlage D: Erklrung zur eigenstndigen Anfertigung Anlage E: Verzeichnisstruktur Anlage F: Vollstndiger Quellcode der Software Anlage G: Letzte nderungen Anlage H: Todo-Liste vom Treffen mit den Tutoren Anlage I: Bildquellen Anlage J: Zeugnisvorlage