GradeBook Abschlussbericht

Master Thesis Nummer MAS-07-02.16
GradeBook
Abschlussbericht
Abstract:
GradeBook ist eine Webapplikation mit Datenbankanbindung in der Lernende aus dem Berufsbildungscenter Gewerbeschul- und Modulnoten eigenständig erfassen und verwalten
können. Berufsbildner können die von ihren Lernenden eingegebenen Noten überwachen
und mittels Newsletters werden weitere Ausbildungsverantwortliche monatlich über die Notenstände informiert. Berichte als PDF, Statistikmöglichkeiten und Alarmierungsmöglichkeiten runden den Produktumfang ab. Vorliegendes Dokument beinhaltet den Abschlussbericht
mit den Inhalten Analyse, Design und Implementierung zur Master Thesis MT-07-02.16
Schlüsselwörter: Webanwendung, Notenverwaltung, Datenbank, PHP, MySQL
Student
Remo Seiler, Husmattstrasse 1, 3123 Belp,
Telefon: P: 031 859 21 09, G: 031 999 21 63, M: 078 627 99 22
[email protected]
Klasse, Datum
MAS-07-02, 18. Februar 2010
Dokumentversion
V 1.0.0
Betreuer
Experte
Patrick Aebi
Ascom (Schweiz) AG
Bahnhöheweg 70
3018 Bern
G: 031 999 31 39
Matthias Stalder
Ascom (Schweiz) AG
Bahnhöheweg 70
3018 Bern
G: 031 999 41 31
[email protected]
[email protected]
André-Claude Godet
Softwareschule Schweiz
Wankdorffeldstrasse 102
3014 Bern
033 335 06 06
[email protected]
Änderungskontrolle
Revision
Datum
Autor
Änderungen
0.10
01.12.2009
Remo Seiler
Entwurf, Dokumentstruktur
0.20
10.12.2009
Remo Seiler
Grobdesign dokumentiert
0.30
21.12.2009
Remo Seiler
Detaildesign dokumentiert
0.40
18.01.2010
Remo Seiler
Analysen und Designs überarbeitet
0.50
21.01.2010
Remo Seiler
Implementierungsdetails dokumentiert
0.60
31.01.2010
Remo Seiler
Modul-Tests dokumentiert
0.70
04.02.2010
Remo Seiler
Abnahmetests dokumentiert
0.80
10.02.2010
Remo Seiler
Einleitende und ausleitende Kapitel
0.81
10.02.2010
Remo Seiler
Erste Korrekturversion
0.82
14.02.2010
Remo Seiler
Korrigierte Version bereit zur Prüfung
0.90
17.02.2010
Remo Seiler
Geprüfte Version
1.00
18.02.2010
Remo Seiler
Abgabeversion
Remo Seiler, MAS-07-02
Seite 2 von 124
Zusammenfassung (Management Summary)
Das Berufsbildungscenter der Ascom (Schweiz) AG in Bern bildet jährlich über 100 Lernende
für mehr als 40 Partnerfirmen in verschiedenen Berufen aus. Während der Grundausbildung
im Berufsbildungscenter und während der weiteren Ausbildung in ihren Lehrbetrieben, besuchen die Lernenden jeweils während zwei Tagen die Berufsfachschule. Die Erfassung und
Überwachung von Beurteilungen, welche die Lernenden von verschiedenen Institutionen
erhalten ist ein wichtiges Werkzeug um die Lernzielerreichung und die Leistungstendenzen
dieser Lernenden zu beurteilen. Um diesen Geschäftsprozess professionell und automatisiert umzusetzen, soll ein neues webbasiertes Werkzeug eingeführt werden: die Webapplikation GradeBook. Im Unterschied zu bestehenden Softwareprodukten, dient GradeBook als
Notenverwaltung für die Lernenden selbst und nicht für Lehrpersonen bietet aber umfangreiche Überwachungsfunktionen für Berufsbildner und weitere Ausbildungsverantwortliche.
Das Ziel dieser Master Thesis ist es nun, das Softwareprodukt GradeBook Release 1 zu realisieren. Dazu muss vorerst eine umfangreiche Vorstudie gemacht werden, um die Anforderungen an das Produkt festzulegen. Anschliessend wird die Softwarearchitektur analysiert,
ein Design erstellt und eine lauffähige Software programmiert und dokumentiert. Umfangreiche Tests und die Integration der Software auf dem Zielsystem (dem Webserver des Berufsbildungscenters) stellen schliesslich die reibungslose Einführung der Software ab August
2010 sicher. GradeBook wird den Lernenden die Möglichkeit bieten alle ihre Beurteilungen
(Noten) online zu erfassen. Zudem können die Berufsbildner des Berufsbildungscenters die
Noten einsehen, überwachen und bei Bedarf auf Ausrutscher und negative Tendenzen reagieren. Dank einer umfangreichen Newsletter-Funktionalität können auch Verantwortliche
aus den Lehrbetrieben an der Überwachung teilnehmen, erhalten monatlich einen NotenNewsletter ihrer Lernenden und haben so stets alle benötigten Leistungsausweise zur Hand.
GradeBook ist also ein Werkzeug um deutlich schneller und effizienter auf Probleme der
Lernenden reagieren zu können, nicht erst bei der halbjährlichen Zeugnisvergabe.
Als Ergebnis liegen nun die komplette Anforderungsspezifikation, der Projektabschlussbericht und eine lauffähige Softwarelösung vor. Alle Ziele, welche für die Einführung des Produktes ab August 2010 notwendig sind konnten komplett umgesetzt werden. In einer ersten
Testphase mit realen Benutzern wird GradeBook Release 1 nun ab März 2010 einem intensiven Praxistest unterzogen und das Nachfolgeprojekt GradeBook Release 2 gestartet, das
mit vielen zusätzlichen Funktionen aufwarten wird.
Der Autor stützt sich einerseits auf neuste Fachliteratur zu Webdesign und den verwendeten
Technologien und andererseits auf intensive Internet-Recherchen zum Thema. Die Erfahrungen aus den Ausbildungen zum Dipl.El.Ing.FH und zum MAS IT trugen ebenso zum Projekterfolg bei wie die vielen kleineren Softwareprojekte die in der Firma und in der Softwareschule bereits umgesetzt werden konnten. Ausserdem wurden verschiedene Fachleute für
Entscheidungsprozesse mit einbezogen und die Bedürfnisse an das Produkt vorgängig mit
vielen Stakeholdern analysiert.
Die geforderten Ziele wurden erreicht und das Produkt ist für die weitere Verwendung bereit.
Trotzdem sind noch einige Verbesserungen möglich und auch Ergänzungen sind geplant.
Während der Arbeit sind verschiedene nützliche Ideen aufgetaucht, die im Nachfolgeprojekt
GradeBook Release 2 umgesetzt werden.
Remo Seiler, MAS-07-02
Seite 3 von 124
Inhaltsverzeichnis
1 EINLEITUNG ................................................................................................................... 7
1.1
1.2
1.3
1.4
1.5
1.6
Umfeld und Ausgangslage ....................................................................................... 7
Zweck des Dokuments............................................................................................. 7
Lesehilfe .................................................................................................................. 8
Leserkreis ................................................................................................................ 8
Referenzen .............................................................................................................. 9
Definitionen, Akronyme, Abkürzungen ..................................................................... 9
2 ARCHITEKTUR UND DESIGN .......................................................................................10
2.1 Übersicht ................................................................................................................10
2.1.1 Schichtenmodell und Entwurfsmuster ......................................................... 10
2.1.2 Framework .................................................................................................. 11
2.2 Grobanalyse ...........................................................................................................14
2.2.1 Anwendungsfall-Übersicht .......................................................................... 14
2.2.2 Paketdiagramm........................................................................................... 16
2.2.3 Architektur .................................................................................................. 17
2.2.4 Sicherheitsaspekte ..................................................................................... 18
2.3 Statische Analyse ...................................................................................................20
2.3.1 Namen und Konventionen........................................................................... 20
2.3.2 Controller Designklassen ............................................................................ 22
2.3.3 Model Designklassen .................................................................................. 34
2.3.4 View............................................................................................................ 37
2.4 Dynamische Analyse ..............................................................................................44
2.4.1 Login (alle Benutzer) ................................................................................... 44
2.4.2 Semesterübersicht (Lernender) .................................................................. 45
2.4.3 Semester bearbeiten (Lernender) ............................................................... 46
2.4.4 Note eingeben oder bearbeiten (Lernender) ............................................... 48
2.4.5 Monatsabschluss und Noten-Newsletter (Lernender).................................. 51
2.4.6 Details Lernender anzeigen (Berufsbildner) ................................................ 53
2.4.7 Newsletter beantragen (beliebige Person) .................................................. 54
2.5 Datenbank ..............................................................................................................55
2.5.1 Geschäftsdatenmodell ................................................................................ 55
2.5.2 Relationen-Modell (ERM) ............................................................................ 57
3 IMPLEMENTIERUNG .....................................................................................................60
3.1 Tools.......................................................................................................................60
3.1.1 Enterprise Architect..................................................................................... 60
3.1.2 Notepad ++ ................................................................................................. 60
3.1.3 XAMPP ....................................................................................................... 60
3.1.4 MySQL Workbench ..................................................................................... 60
3.1.5 WinSCP ...................................................................................................... 61
3.1.6 Web Developer ........................................................................................... 61
3.1.7 Weitere ....................................................................................................... 61
3.2 Installation GradeBook............................................................................................61
3.2.1 Lokal ........................................................................................................... 61
Remo Seiler, MAS-07-02
Seite 4 von 124
3.2.2 Zielsystem .................................................................................................. 63
3.3 Dokumentation Source-Code ..................................................................................64
4 TEST ..............................................................................................................................65
4.1 Testkonzepte ..........................................................................................................65
4.2 Testumgebung, Voraussetzungen ..........................................................................66
4.2.1 Testaufbau.................................................................................................. 66
4.2.2 Entwicklungssystem.................................................................................... 67
4.2.3 Zielsystem .................................................................................................. 67
4.3 Datenbank ..............................................................................................................68
4.3.1 Testdaten.................................................................................................... 68
4.3.2 Testabfragen............................................................................................... 68
4.4 Unit-Tests der Models .............................................................................................71
4.4.1 Testframework Toast .................................................................................. 71
4.4.2 Installation des Testframeworks Toast ........................................................ 72
4.4.3 Implementierung der Unit-Test-Klassen ...................................................... 72
4.4.4 Testablauf ................................................................................................... 73
4.4.5 Resultate und Auswertung .......................................................................... 74
4.5 Manuelle Tests .......................................................................................................75
4.5.1 Benutzeroberfläche, Layout, Navigation...................................................... 75
4.5.2 Eingabeformulare ....................................................................................... 77
4.6 Abnahmetests.........................................................................................................86
4.6.1 Testablauf ................................................................................................... 86
4.6.2 Benutzer Lernender .................................................................................... 87
4.6.3 Benutzer Berufsbildner ............................................................................... 91
4.6.4 Benutzer Newsletter-Empfänger oder beliebige Person .............................. 96
4.6.5 Authentifizieren (über ADS) ........................................................................ 98
5 RESULTATE ..................................................................................................................99
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Konventionen..........................................................................................................99
Zielerreichung funktionale Anforderungen Lernender .............................................99
Zielerreichung funktionale Anforderungen Benutzer .............................................101
Zielerreichung funktionale Anforderungen Newsletter-Empfänger ........................101
Zielerreichung funktionale Anforderungen mehrere Benutzergruppen ..................102
Zielerreichung funktionale Anforderungen System ................................................102
Zielerreichung nicht funktionale Anforderungen ....................................................103
6 AUSBLICK ...................................................................................................................104
6.1 Offene Punkte.......................................................................................................104
6.2 Verbesserungsmöglichkeiten ................................................................................104
6.3 Erweiterungsvorschläge........................................................................................105
6.3.1 Checkliste und Change Management ........................................................105
6.4 Nachfolgeprojekt (GradeBook Release 2) .............................................................108
6.4.1 Betatest-Phase ..........................................................................................108
6.4.2 Termine .....................................................................................................108
7 AUSWERTUNGEN, ERFAHRUNGEN, FAZIT .............................................................110
Remo Seiler, MAS-07-02
Seite 5 von 124
7.1
7.2
7.3
7.4
7.5
Resultate ..............................................................................................................110
Auswertung der Zeitaufwände und Termine..........................................................110
Projektverlauf und Erfahrungen ............................................................................113
Schlussbetrachtung, Fazit .....................................................................................115
Danksagung .........................................................................................................115
A TERMINPLAN ..............................................................................................................116
B GLOSSAR FACHBEGRIFFE .......................................................................................117
C GLOSSAR INFORMATIKBEGRIFFE ...........................................................................119
D ABKÜRZUNGEN UND AKRONYME............................................................................120
E ABBILDUNGSVERZEICHNIS ......................................................................................121
F TABELLENVERZEICHNIS ...........................................................................................122
G QUELLEN.....................................................................................................................123
Remo Seiler, MAS-07-02
Seite 6 von 124
1
Einleitung
1.1
Umfeld und Ausgangslage
Das Berufsbildungscenter der Ascom (Schweiz) AG führt Basisausbildungen für mehr als 40
Partnerfirmen durch. Jährlich absolvieren somit mehr als 100 Lernende aus fünf verschiedenen Berufen ihre Grundausbildung im Berufsbildungscenter.
Die Lernenden erhalten während ihrer Lehrzeit in der betrieblichen Ausbildung, in der Gewerbeschule und an Prüfungen von verschiedenen Instanzen, Beurteilungen in Form von
Noten. Diese Noten müssen die Lernenden sammeln und den Berufsbildnern, Betreuern und
Coachs der Lehrbetriebe und des Berufsbildungscenters in regelmässigen Zeitabständen
melden.
Die Möglichkeit die Noten der Lernenden nicht nur bei Zeugnisvergabe, sondern auch
während des Semesters kontrollieren zu können, ist für Berufsbildner und weitere
Verantwortliche ein wichtiges Instrument zur Überprüfung der Lernzielerreichung.
Somit kann zum Beispiel frühzeitig auf Negativtendenzen bei Schulnoten reagiert und es
können entsprechende Gegenmassnahmen eingeleitet werden.
Zu bemerken gilt es, dass die Lernenden ihre Noten selbständig verwalten sollen. Die Berufsbildner müssen die durch den Lernenden erfassten Noten einsehen und darauf reagieren
können. Die Erfassung der Noten erfolgt in erster Linie auf Vertrauensbasis kann aber nach
der Zeugnisvergabe nachträglich auch kontrolliert werden.
Quelle der Abschnitte in diesem Kapitel [dok1 & dok2].
1.2
Zweck des Dokuments
Im Rahmen der Master Thesis MT-07-02.16 wurde das Projekt GradeBook Release 1 realisiert. Der vorliegende Abschlussbericht beschreibt die verschiedenen Projektphasen und
deren Resultate exklusive der Sourcecode-Dokumentation. Das Dokument beinhaltet also
die Analyse- und Design-Resultate, Informationen zur Implementierung, Testkonzept, Testresultate und Beschreibungen zum Projektablauf (Termine, Zielerreichung, persönliche Erfahrungen des Autors, etc.).
Für die Master Thesis MT-07-02.16 wurde ein Pflichtenheft erstellt (siehe [dok1]), welches
die Zielsetzung der Projektarbeit festlegt. Anschliessend wurde eine ausführliche Anforderungsspezifikation (siehe [dok2]) erstellt in welcher die Anforderungen an das Endprodukt
GradeBook Release 1 und 2 analysiert und spezifiziert wurden. Diese beiden Dokumente
bilden die Grundlage für das vorliegende Dokument und die gesamte projektarbeit.
Der Abschlussbericht beinhaltet, im Gegensatz zu den beiden vorangehenden Dokumenten
ausschliesslich die im Release 1 der Software implementierten Teile. Für Informationen zu
GradeBook Release 2 wird auf das Anschluss-Projekt und dessen Dokumentation verwiesen.
Hinweis: Einzelne wichtige Abschnitte des Abschlussberichtes werden, trotz der Gefahr mögliche Inkonsistenzen zu erzeugen, redundant aus der Anforderungsspezifikation [dok2] oder
dem Pflichtenheft [dok1] übernommen. Dies um die Verständlichkeit der Inhalte auch für Leser die die vorangehenden Dokumente nicht zur Hand haben zu erhöhen. Wörtliche Zitate
werden mit entsprechenden Quellen-Angaben versehen.
Remo Seiler, MAS-07-02
Seite 7 von 124
1.3
Lesehilfe
Das vorliegende Dokument orientiert sich an diversen Richtlinien für technische Berichte.
Zum einen Sind dies die Normen DIN1421 („Gliederung und Benummerung in Texten, Abschnitte, Absätze, Aufzählungen“) und ISO 5966 („Documentation – Presentation of scientific
and technical reports“) und zum anderen firmeninterne Richtlinien (siehe [dok3]). Bei Differenzen werden firmeninterne Richtlinien priorisiert. Einige Details wurden aus Gründen der
Übersichtlichkeit nicht komplett Normgetreu gestaltet. So sind zum Beispiel mehr als 3 Gliederungsebenen in der Kapitelstruktur vorgesehen, im Inhaltsverzeichnis werden aber nur
deren 3 aufgeführt. Zudem beginnen im Inhaltsverzeichnis nicht alle Abschnitte auf derselben Fluchtlinie, da dies deutlich umständlicher zu lesen ist, als die gewählte Form. Die meisten anderen Inhalte wie zum Beispiel das Management Summary, die Dokumentstruktur, die
Layout-Aspekte, etc. wurden aber gemäss den Richtlinien (siehe oben) umgesetzt.
Die gewählte Dokument- und Kapitelstruktur ist folgendermassen aufgebaut:
Im Kapitel 1 sind Beschreibungen zum Dokument, zur Ausgangslage und Umfeld des
Projektes und zu weiteren einführenden Teilen zu finden.
Im Kapitel 2 werden mithilfe von UML-Graphiken und verschiedenen anderen Darstellungsarten die Analyse- und Design-Resultate dokumentiert. Dieses Kapitel dient als
Grundlage für die Implementierung der Software.
Im Kapitel 3 sind einige wichtige Details der Implementierung beschrieben. Die Dokumentation des Programmcodes und weiterer Implementierungs-Details sind aber in
der Doxygen-Code-Dokumentation zu finden.
Im Kapitel 4 werden alle Testkonzepte und Resultate der manuellen und automatisierten Software-Tests dokumentiert.
Im Kapitel 5 folgt die Überprüfung der erreichten Ziele die für die Master Thesis MT07-02.16 gesetzt wurden.
Im Kapitel 6 wird das weitere Vorgehen im Gesamtprojekt GradeBook (Release 1 und
2) definiert. Es werden offene Punkte diskutiert und das Change Management während der Master Thesis beschrieben (inkl. Checkliste der offenen Punkte).
Im Kapitel 7 erfolgt die Schlussbetrachtung und Auswertung zum Projekt GradeBook
resp. der Master Thesis. Auswertungen des Projektablaufes, der Termine sind ebenso
enthalten wie persönliche Erfahrungen, Danksagung und das Fazit des Autors.
1.4
Leserkreis
Der Abschlussbericht hat grundsätzlich zwei Zielgruppen. Einerseits dokumentiert er die Arbeits-Methodik und Resultate der Master Thesis MT-07-02.16 und richtet sich somit an den
Betreuer und Auftraggeber (Ascom, Leiter Berufsbildung Informatik, P. Aebi) und an den Experten (Softwareschule Schweiz, A.C. Godet) dieser Arbeit.
Andererseits richtet sich das Dokument an den oder die Entwickler des Release 2 von GradeBook und soll ihnen das Einarbeiten in die Softwarearchitektur ermöglichen. Diesen Zweck
kann der Abschlussbericht aber nur in Kombination mit den weiteren, während der Master
Thesis erstellten, Dokumente wie der Anforderungsspezifikation und der SourcecodeDokumentation erfüllen.
Remo Seiler, MAS-07-02
Seite 8 von 124
Für weitere interessierte Leser werden Grundkenntnisse im Software-Engineering, in Webdesign mit PHP, verteilten Applikationen, Datenbanken und verschiedenen weiteren Themen
der Informatik vorausgesetzt.
1.5
Referenzen
Für den Inhalt des vorliegenden Abschlussberichts sind verschiedene weitere Dokumente
von Bedeutung. Die Dokumente werden jeweils mit einem entsprechenden Quellenverweis
in eckigen Klammern referenziert. Die Quellen sind im Anhang G zu finden.
1.6
Definitionen, Akronyme, Abkürzungen
Die in diesem Dokument verwendeten Fach- und Spezialausdrücke sind im Glossar in den
Anhängen B und C erläutert. Die verwendeten Abkürzungen und Akronyme sind im Abkürzungsverzeichnis in Anhang D spezifiziert.
Remo Seiler, MAS-07-02
Seite 9 von 124
2
Architektur und Design
2.1
Übersicht
2.1.1
Schichtenmodell und Entwurfsmuster
Die Webapplikation GradeBook soll wie in der Anforderungsspezifikation festgelegt, nur mit
der Programmiersprache PHP und mit Darstellungssprachen wie HTML, CSS, etc. umgesetzt werden. Die Sprache PHP ist grundsätzlich eine Skriptsprache, welche dazu dient den
statischen HTML-Seiten serverseitig Funktionalität zur Verfügung zu stellen. Seit PHP 4.3
unterstützt die Sprache nun aber auch objekteorientierte Ansätze und ermöglicht so komplexe Webapplikationen strukturierter und als ausgewachsene Enterprise Applications zu entwickeln.
Als besonders geeignet erscheint der Ansatz, die zu lösenden Probleme in mehrere Schichten (englisch Tiers) aufzuteilen. Für das geplante interaktive System soll als Architekturmuster das Model View Controller – Konzept (bekannt auch als Entwurfsmuster in nicht verteilten
Systemen) herangezogen werden.
2.1.1.1 Model View Control
Das MVC-Konzept wurde ursprünglich für Benutzeroberflächen in SmallTalk beschrieben.
Heute wird es in vielen komplexen Softwaresystemen für den Grobentwurf verwendet und
hat auch in der Webentwicklung einen grossen verbreitungsgrad erreicht. Abbildung 1 zeigt
das grundsätzliche ereignisorientierte MVC-Konzept für eine nicht verteilte Applikation.
System
View
(Präsentation)
Model
(Daten)
Control
(Steuerung)
Benutzer
Abbildung 1: MVC-Entwurfsmuster
In einer Webapplikation ist ein Beobachter-Ansatz für die Model-View-Assoziation nicht sinnvoll umsetzbar, da nur der Benutzer Ereignisse auslösen kann. Für GradeBook muss also
ein Ansatz gewählt werden, bei dem der Controller die Vermittlerrolle übernimmt. Das angepasste MVC-Entwurfsmuster, das für GradeBook zum Einsatz kommen soll, ist in Abbildung
2 dargestellt.
Remo Seiler, MAS-07-02
Seite 10 von 124
Server
Client
View
(Präsentation)
HTTP_Response
Model
(Daten)
Browser
Control
(Steuerung)
HTTP_Request
Benutzer
Abbildung 2: Angepasstes MVC-Entwurfsmuster
Da das beschriebene MVC-Konzept für Entwicklungen von Webapplikationen weit verbreitet
ist, existieren zahlreiche entsprechende Frameworks. Viele davon sind als Open sourceVarianten erhältlich. Die meisten neueren PHP-Frameworks, setzen mehr oder weniger genau das in Abbildung 2 gezeigte Konzept um und bieten ausserdem häufig noch viele zusätzliche Funktionalitäten.
Für die Implementierung von GradeBook sind vor allem die Geschäftslogik und die strukturierte und verständliche Umsetzung der Applikation von zentraler Bedeutung. Unter anderem
aus diesen Gründen wurde in Absprache mit dem Auftraggeber beschlossen, ein möglichst
einfaches aber robustes Open source-Framework für die Implementierung zu evaluieren und
zu verwenden. Das Framework muss kostenlos erhältlich und einfach zu erlernen sein (auch
für Lernende Informatik) und soll die Möglichkeiten der objektorientierten PHPProgrammierung nutzen. Grundsätzliche Sicherheitsmechanismen und eine einfache Möglichkeit eigene Libraries und Erweiterungen zu erstellen müssen vorhanden sein. Genauere
Beschreibungen zu dem gewählten Framework finden sich im nachfolgenden Kapitel 2.1.2.
2.1.2
Framework
2.1.2.1 Evaluation
Wie in Kapitel 2.1.1.1 beschrieben, werden an das zu evaluierende Framework verschiedene
grundsätzliche Anforderungen gestellt. Um aus der Fülle aller verfügbaren Open-SourceFrameworks eines auszuwählen wurde deshalb vorerst eine Vorauswahl getroffen und für
diese eine Nutzwertanalyse erstellt. Für die nähere Betrachtung wurden die nachfolgend
aufgelisteten Frameworks ausgewählt:
CakePHP [net1]
Zend [net2]
Fusebox [net3]
CodeIgniter [net4]
Symfonie [net5]
Kohana [net6]
Diese Auswahl wurde aufgrund ausgiebiger Internet-Recherchen getroffen. Letztere haben
gezeigt, dass die genannten Frameworks am weitesten verbreitet sind und die grössten
Communities aufweisen. In Tabelle 1 werden die Frameworks nun miteinander verglichen.
Die Kriterien für den Vergleich sind gemäss ihrer Priorität gewichtet. Die einzelnen FrameRemo Seiler, MAS-07-02
Seite 11 von 124
works erhalten für diese Kriterien eine Bewertung mit einer Note von 1-6. Die Bewertung
erhebt nicht Anspruch auf absolute Korrektheit, stellt aber den aktuellen Stand der Recherchen (Dezember 2009) durch den Autor dieses Dokuments dar. Die Internet-Quellen für Informationen und Bewertungen sind im Quellennachweis Anhang G aufgeführt.
Varianten
Kriterien
Gewicht CakePHP
Note
Zend
Fusebox
CodeIgniter
N x G Note N x G Note N x G Note
N xG
Symfonie
Kohana
Note N x G Note N x G
Einfachheit / Lernkurve
30
4
120
4
120
5
150
6
180
3
90
5
150
Flexibilität / Erweiterbarkeit
15
6
90
5
75
6
90
6
90
6
90
6
90
MVC-Umsetzung
15
6
90
6
90
6
90
6
90
6
90
6
90
Libraries
15
6
90
6
90
5
75
5
75
5
75
6
90
Voraussetzungen, Kompatibilität (PHP4/5)
5
6
30
4
20
6
30
6
30
5
25
5
25
Installation
5
6
30
4
20
6
30
6
30
5
25
6
30
Dokumentation
5
4
20
6
30
4
20
6
30
6
30
3
15
Community
5
5
25
5
25
4
20
6
30
5
25
4
20
Verbreitungsgrad
5
6
30
6
30
4
20
5.5
27.5
6
30
4
Total
100
Normierter Nutzwert in %:
20
525
500
525
582.5
480
530
87.50%
83.33%
87.50%
97.08%
80.00%
88.33%
Tabelle 1: Vergleich und Nutzwertanalyse Framework
Die Analyse in Tabelle 1 zeigt, dass das PHP-Framework CodeIgniter die Anforderungen für
das Produkt GradeBook mit 97% am besten erfüllt. Das wichtigste Kriterium, die Einfachheit
wird durch den sehr verständlichen und kompakten Aufbau des Frameworks am besten erfüllt. Dieses Kriterium ist zentral, weil auch Lernende der Informatik, in nützlicher Frist und
ohne sehr grosse Vorkenntnisse die Möglichkeit haben müssen sich in das Framework einzuarbeiten. Trotz seinem kompakten Aufbau bietet CodeIgniter aber eine Fülle von Libraries,
die mit Ausnahme einer Autorisierungs-Library alle Bedürfnisse für GradeBook abdecken. Es
ist ausserdem sehr flexibel für Erweiterungen (siehe auch Kapitel 2.1.2.2) und hat eine äusserst aktive Community. Die konsequente Umsetzung des MVC-Entwurfsmusters, die Kompatibilität auch mit PHP4 (und nicht ausschliesslich PHP5) und die sehr einfache Installation
auf dem Zielsystem sind weitere Vorteile. Obschon das Framework (noch) nicht den Verbreitungsgrad von CakePHP, Zend oder Symfonie erreicht hat, ist eine starke Zunahme dahingehend sehr wahrscheinlich. Zu guter Letzt ist auch die Dokumentation der neusten Version
des Frameworks (aktuelle Version Dezember 2009: 1.72) sehr ausführlich und verständlich
gehalten, was Kriterium 1 ebenfalls unterstreicht.
Stärkster Konkurrent für CodeIgniter ist das relativ neue Framework Kohana, das auf CodeIgniter aufbaut und einige Bereiche verbessert und erweitert (Session, zusätzliche Libraries, etc.). Kohana hat aber den Nachteil, dass die Dokumentation momentan noch sehr
spärlich, der Verbreitungsgrad klein, und die Community erst im Entstehen ist. Somit ist es
nicht gerade einfach zu erlernen und kann so auch im wichtigsten Punkt nicht überzeugen.
Falls Kohana entsprechende Fortschritte machen sollte, wäre eine Portierung von GradeBook auf dieses Framework dank dem sehr ähnlichen Aufbau aber mit vertretbarem Aufwand möglich.
Die restlichen Konkurrenten haben alle den Nachteil, dass Sie für den vorgesehenen Verwendungszweck stark Überdimensioniert sind und somit bei verschiedenen Kriterien schwächeln.
Fazit: Die Wahl fällt aus oben genannten Gründen auf das Framework CodeIgniter.
Remo Seiler, MAS-07-02
Seite 12 von 124
2.1.2.2 Beschreibung Framework CodeIgniter
Wie in Kapitel 2.1.2.1 bereits erwähnt ist das Framework CodeIgniter einfach aufgebaut. In
der Abbildung 3 ist dieser Aufbau schematisch dargestellt.
Abbildung 3: Aufbau Framework CodeIgniter, Quelle [net4]
Sämtliche Benutzeranfragen (HTTP Requests) werden an den Front-Controller (index.php)
des Frameworks gerichtet. Dieser ist für das Routing der Anfrage zum benötigten Controller
resp. zur benötigten Controller-Methode verantwortlich. Ausserdem besteht die Möglichkeit
die Sicherheits-Konzepte des Frameworks automatisch zu verwenden. Dies sind zum Beispiel eine XSS-Filterung aller übertragenen Daten (siehe auch Kapitel 2.2.4) zur Verhinderung von Cross-Site-Scripting oder automatisches Escaping von SQL-Abfragen zur Verhinderung von SQL-Injections.
Die an den Benutzer gesendeten Webseiten sind in den View-Files abgelegt. Diese beinhalten ausschliesslich den HTML-Code und binden die Style-Sheets für die Layout- und Darstellungsinformationen ein. Eine Template-Funktionalität ist grundsätzlich nicht gegeben, es
können aber mehrere View-Files kombiniert und somit die Redundanz verringert werden1.
CodeIgniter bietet auch die Möglichkeit eines Seiten-Cachs um häufig verwendete statische
Inhalte zwischen zu speichern und somit die Performanz zu steigern. Aufgrund der vielen
dynamischen Inhalte auf den GradeBook-Webseiten wird darauf aber verzichtet.
Die Application-Controller sind die eigentliche Schnittstelle zwischen der Datenschicht (Models) und der Präsentationsschicht (Benutzer/Browser). Sie sind verantwortlich für das Abfragen der Informationen von den Models, das Aufbereiten dieser Daten und deren Integration in die View-Files. Die Controller-Methoden laden also nach ihrem Aufruf die aufbereiteten
Daten zusammen mit einem View-File und senden das Resultat zurück an den Browser.
Die Application-Controller können nicht nur auf Models, sondern auch auf Libraries, Helpers
(nicht OOP-konforme einfache PHP-Methoden), Plugins und weitere Scripts von CodeIgniter
zugreifen. Das Erstellen eigener solcher Zusatzmodule ist vom Handling her trivial. Die eigentliche Flexibilität von CodeIgniter zeichnet sich aber dadurch aus, dass für Erweiterung
oder Anpassung bestehender Module die Kernfunktionalität nicht verändert werden muss.
Das Framework bietet dazu einfache Möglichkeiten mittels entsprechender Namenskonventionen. Somit ist gewährleistet, dass die Software ohne Komplikationen auf zukünftige Versionen von CodeIgniter portiert werden kann.
1
Eine effizientere Methode würde hier eine Template-Library bieten, mit der zum Beispiel Master-Templates für
das grundsätzliche Webseitenlayout verwendet werden können. CodeIgniter bietet in der Standardinstallation
zwar keine solche an, verschiedene open source Template-Libraries stehen aber zur Verfügung.
Remo Seiler, MAS-07-02
Seite 13 von 124
Zu guter Letzt bietet das Framework mit den Model-Klassen eine ausgereifte Schnittstelle zu
den Daten. Umfangreiche Datenbank-Libraries bieten nicht nur Treiber zu verschiedenen
Datenbanksystemen sondern auch Sicherheits-Mechanismen, Active-Record-Klassen, etc.
2.2
Grobanalyse
2.2.1
Anwendungsfall-Übersicht
Sämtliche Anwendungsfälle für die Webapplikation GradeBook sind in der Anforderungsspezifikation [dok2] ausführlich beschrieben. Die nachfolgenden Abbildungen sollen aber einen
Überblick über die implementierten und in vorliegendem Abschlussbericht analysierten Anwendungsfälle ermöglichen um somit das Verständnis der Berichtsinhalte zu erhöhen. Die
Anwendungsfälle werden nicht weiter kommentiert. Interessierte Leser konsultieren bitte
[dok2].
Die grau hinterlegten Elemente stellen jeweils SOLL- oder KANN-Anwendungsfälle für die
Implementierung im Rahmen der Master Thesis dar. Da sie aber ebenfalls ganz oder Teilweise implementiert wurden, mussten sie in der Analyse und im Design ebenfalls mit einbezogen werden.
Abbildung 4: Anwendungsfälle Lernender
Remo Seiler, MAS-07-02
Seite 14 von 124
Abbildung 5: Anwendungsfälle Berufsbildner
uc UC_Mehrere Benutzer
Anwendungsfälle Mehrere Benutzer
Def. Berufsbildner
Berufsbildner
MUC.01: Authentifizieren
(über ADS)
Lerne nder
New sletter -Empfänger
NUC.01 :
New sletter-Abonnement
beantragen
beliebige Person
Abbildung 6: Anwendungsfälle mehrere Benutzer
Remo Seiler, MAS-07-02
Seite 15 von 124
2.2.2
Paketdiagramm
Das Paketdiagramm in Abbildung 7 zeigt alle in der Webapplikation GradeBook verwendeten
Pakete. Im Paket CodeIgniter sind alle vom Framework zur Verfügung gestellten Basisklassen, Libraries, Helpers, Plugins, Konfigurationsfiles und Datenbank-Treiber enthalten. Die
einzelnen Module werden hier nicht einzeln aufgeführt um die Übersichtlichkeit nicht zu gefährden. Eingesetzt werden aber vor allem die Basisklassen der Controller und der Models
und verschiedene Libraries und Helpers. Als Datenbanktreiber kommt nur der MySQLTreiber zum Einsatz.
Das Paket GradeBook zeigt die Aufteilung aller im Rahmen der Entwicklung zum Release 1
zu erstellenden PHP-Klassen (Controller, Models und Libraries), Helpers sowie View-,
Template- und Layoutfiles (CSS). Die Assoziationen zwischen den GradeBook-Internen Paketen sind ersichtlich, diejenigen zu den Paketen des Frameworks und den open source
Libraries werden hier nicht explizit dargestellt.
Die Vier in GradeBook verwendeten open source Produkte sind dem entsprechenden Paket
zugeteilt. Letzteres ist unterteilt in CodeIgniter-Libraries welche ohne weitere Anpassungen
integriert werden können und PHP-Libraries, die für den Einsatz mit CodeIgniter leicht angepasst oder erweitert werden (oder schlicht als Basisklasse für eigene CodeIgniter-Libraries
verwendet werden).
Abbildung 7: Paketdiagramm GradeBook
Remo Seiler, MAS-07-02
Seite 16 von 124
2.2.3
Architektur
Das gewählte MVC-Konzept beschreibt prinzipiell nicht ein gängiges Schichtenmodell. Dies
weil beispielsweise sowohl Model, als auch Controller Teile der Geschäftslogik-Schicht implementieren. Die Grenze zwischen diesen beiden Teilen ist also grundsätzlich etwas unscharf und muss hier klarer definiert werden. Die Präsentationsschicht kann hingegen klar
dem View-Teil des MVC-Konzepts zugeordnet werden und die Schnittstelle zu den unteren
Schichten bieten ausschliesslich die Controller.
Die Abbildung 8 zeigt die einzelnen Elemente von GradeBook, ihre Zuordnung zu den MVCTeilen und wie sie in den einzelnen Schichten positioniert sind.
View
login_view
confirm_fach_entfernen_view
confirm_note_loeschen_view
monatsabschluss_info_view
monatsabschluss_view
note_eingeben_view
noten_uebersicht_view
sem_bearbeiten_view
sem_uebersicht_view
confirm_nla_ablehnen_view
confirm_nla_loeschen_view
confirm_nle_loeschen_view
lernende_bearbeiten_view
lernende_uebersicht_view
lernender_details_view
nla_detail_view
nla_hinzufuegen_view
nla_uebersicht_view
nle_bearbeiten_view
nle_uebersicht_view
nl_auswahl_view
nl_bestaetigung_view
nl_emaileingabe_view
nl_registrierung_view
email_newsletter_view
email_ablehnung_nla_view
email_anfrage_nla_view
menu_lernender_view
menu_berufsbildner_view
template
login.css
layout.css
template_nl
nlAbonnement.css
tabellen.css, email.css
Control
Login
Lernender
Model
M_login
M_benutzer
M_lernender
M_semester
M_fach
M_note
M_berufsbildner
Berufsbildner
NewsletterAnfrage
M_newsletter
M_email
RDBMS
MySQL 5.x - Datenbank mit InnoDB-Tabellen
Abbildung 8: Architektur GradeBook
Die nachfolgende Auflistung verdeutlicht die Aufgaben der einzelnen MVC-Teile:
Model: Die Models sind ausschliesslich zuständig für die Datenbankabfragen im
RDBMS. Einzelne oder verknüpfte Tabellen werden gelesen und die Daten teilweise
umgeformt oder berechnet und anschliessend als PHP-Arrays an den aufrufenden
Controller zurückgegeben.
Control: In den Controllern werden die Daten von den Models gelesen und aufbereitet. Die Umsetzung der Daten in eine HTML-konforme Form geschieht also hier und
nicht wie auch häufig anzutreffen in den Models.
Remo Seiler, MAS-07-02
Seite 17 von 124
View: Beinhaltet alle darstellungsrelevanten Inhalte in XHTML formatiert mit CSS.
Die View-Files beinhalten weitestgehend keine Anwendungslogik und somit auch
keinen PHP-Code. Einzige Ausnahme sind, die dynamisch von den Controllern generierten und an die Views übergebenen Daten, die mittels PHP-echo-Befehlen ausgegeben werden.
2.2.4
Sicherheitsaspekte
Mit GradeBook werden bezüglich des Datenschutzes, sehr sensible Daten erfasst und verarbeitet. Die Notendaten der Lernenden dürfen in keiner Weise für nicht autorisierte Personen sichtbar werden. Diesem Umstand muss bei der Entwicklung und Analyse grosse Bedeutung zugemessen werden, insbesondere da es sich hier um eine Webapplikation handelt
die vom Internet aus zugänglich ist. Ein weiterer Aspekt für ein gutes Sicherheitskonzept ist,
dass die Hauptbenutzer der Software technisch versierte Jugendliche mit zum Teil hohem
Informatik-Wissen sind1. Das Framework CodeIgniter bietet für viele Sicherheitsprobleme
bereits ausgereifte Lösungen an, diese müssen konsequent eingesetzt werden. Andere Sicherheitsprobleme sind teilweise durch administrative Massnahmen zu beheben. Nachfolgend werden die wichtigsten Sicherheitsrisiken und Massnahmen dagegen aufgezeigt.
Veröffentlichung des
Source-Codes
Cross-Site Scripting
(XSS)
SQL Injection
Fehlermeldungen
Verzeichniszugriff
Öffentlicher Programmcode bietet potenziellen Angreiffern die
Möglichkeit auch die kleinsten Sicherheitslücken aufzuspüren
und auszunutzen. Da GradeBook im Rahmen einer Master
Thesis an der SWS umgesetzt wird, muss sichergestellt werden, dass kein Programmcode auf deren Webseite veröffentlicht wird.
Eine der häufigsten und einfachsten Angriffsstrategien ist das
Attackieren von Eingabeformularen (z.B. das LoginFormular). Sämtliche Formulareingaben müssen vor deren
Verarbeitung im Skript entsprechend gefiltert und geprüft
werden. Diese Aufgabe übernimmt zu grossen Teilen die
XSS-Filter-Funktionalität von CodeIgniter.
Um die Möglichkeit auszuschliessen, dass Angreifer SQLQueries durch entsprechende Eingaben in Formularfeldern
verändern können, werden sämtliche solche Eingaben mit
den CodeIgniter-Escape-Methoden gereinigt. Das bedeutet
alle Datenbankzugriffe werden ausschliesslich mit der CIDatenbank-Library vollzogen.
Es sollen, durch entsprechende Codierung, möglichst keine
PHP- oder MySQL-Fehlermeldungen direkt an den Browser
gesendet werden und somit einem potentiellen Angreifer
nützliche Hinweise liefern. Die Fehlermeldungen werden,
soweit möglich, durch entsprechende Codierung abgefangen.
Der Verzeichnis-Zugriff auf die Applikationsverzeichnisse wird
eingeschränkt. Um zu verhindern, dass Inhalte eines Verzeichnisses an den Browser gesendet werden, wird zudem in
jedem Verzeichnis eine index.htm-Datei mit einer Fehlermeldung abgelegt.
1
Den Benutzern wird zwar nicht unterstellt böswillige Angriffe umsetzen zu wollen aber das Austesten
von Grenzen und Möglichkeiten gehören bei vielen Personen dieser Altersgruppe zum normalen Verhaltensmuster, was Erfahrungen zeigen.
Remo Seiler, MAS-07-02
Seite 18 von 124
Session-Hacking
Damit ein Benutzer nicht ohne weiteres seine Session-Daten
verändern und somit Zugriff auf geschützte Bereiche der
Software erhält, werden die Daten nicht in einem Cookie
sondern serverseitig in der Datenbank gespeichert. Lediglich
die Session-ID ist Client-Seitig im Cookie abgelegt und wird
jeweils mit der DB-Seitigen Session-ID validiert (kann also
nicht verändert werden).
Session-Hijacking
Damit eine aktive Session nicht durch einen Angreifer „entführt“ werden kann, muss sichergestellt werden, dass der
Client nicht ausspioniert wird. Die Sicherste und zugleich einfachste Gegenmassnahme ist das Verschlüsseln aller Daten
über eine HTTPS-Verbindung. Es werden also nicht nur Login- und persönliche Daten, sondern alle Datenübertragungen
über HTTPS stattfinden. Zudem müssen die Sessions über
ein genügend kurzes Timeout verfügen (falls kein „sauberes“
Logout stattfindet -> dabei werden sie umgehend gelöscht)
um nicht von einem anderen Benutzer auf demselben Computer missbraucht werden zu können.
Datei- und URL-Namen
Es muss für alle Dateinamen ein sinnvoller Kompromiss zwischen lesbaren und für Hacker einladenden Namen gefunden
werden.
BruteForce-Attacken
Um BruteForce-Attacken auf die Benutzer-Accounts zu verhindern (oder zumindest erschweren) wird in GradeBook Release 2 ein Timeout nach drei erfolglosen Login-Versuchen
vorgesehen (siehe auch Checkliste in Kapitel 6.3.1).
Fremde Seiteninhalte
Es werden keinerlei fremde Inhalte wie Werbung, Banner,
etc. auf den Webseiten eingesetzt. So wird verhindert, dass
ein Benutzer von solchen Fremd-Applikationen getäuscht
werden kann oder dass diese Applikationen unerwünschten
Skript-Code ausführen können.
Spamschutz
Um zu verhindern, dass zum Beispiel Bots das Registrierungsformular für Newsletter-Empfänger missbrauchen können (z.B. für das füllen der Datenbank mit Spaminhalten oder
Dummy-Usern um diese zu überlasten) wird das entsprechende Formular mit einer nicht automatisiert lesbaren Sicherheitsabfrage (Captcha-Graphik) versehen.
Serverseitige Sicherheit
Einige wichtige Sicherheitsaspekte auf dem Webserver kann
der Entwickler nicht selbst konfigurieren. Beispielsweise
müssen in der Datenbank die Zugriffsrechte klar geregelt sein
(keine passwortlosen root- oder test-Benutzer etc.). Ein anderer Aspekt sind PHP-Sicherheitslücken (werden auf dem Server vom Suhosin-Patch geschlossen) oder andere Angriffsmöglichkeiten der Infrastruktur. Für die Sicherheit der Serverumgebung ist der entsprechende Webserver-Verantwortliche
zuständig.
Weitere Sicherheitsaspekte, wie zum Beispiel das verwenden sicherer Passwörter für Ihre
ADS-Accounts, werden in der Ausbildung im Berufsbildungscenter thematisiert und sind in
Informatik-Richtlinien festgehalten. Die Sicherung der Datenbestände erfolgt mit automatischen Backups aller Datenbanken des Webservers und ist bereits in Betrieb.
Remo Seiler, MAS-07-02
Seite 19 von 124
2.3
Statische Analyse
In diesem Kapitel wird das statische Design der Software GradeBook dokumentiert. Die zu
entwickelnde PHP-Applikation ist zwar objektorientiert, sie weist aber eine grundsätzlich andere Struktur als eine normale (nicht verteilte) objektorientierte Software auf. Letzteres vor
allem aufgrund der transaktionsorientierten Arbeitsweise und der Tatsache, dass mit einem
MVC-PHP-Framework gearbeitet wird.
Für das Design der Applikation kann nur eine Teilmenge der Verfügbaren UML-Werkzeuge
sinnvoll eingesetzt werden. So kann zum Beispiel die statische Struktur der Applikation gut
mit Klassendiagrammen dargestellt werden hingegen sind zum Beispiel Objektdiagramme
für die Darstellung einzelner Szenarien wenig sinnvoll. Dies, weil die einzelnen Objekte praktisch keine Attribute aufweisen und die Datenhaltung ausschliesslich persistent in der Serverdatenbank und in Sessions geschieht. Auch sind die Assoziationen zwischen einzelnen
Objekten trivial, da beispielsweise alle benötigten Models bei jedem HTTP-Request neu geladen werden und jeweils nur einmal vorhanden sind.
Die für das statische Design verwendeten UML-Diagramme beschränken sich also auf Klassen- und Zustandsdiagramme. Für dynamische Betrachtungen des Systems wurden vor allem Sequenzdiagramme verwendet, in welchen die Kommunikation zwischen Objekten (und
auch Benutzer) verdeutlicht wird. Die Erstellung der Sequenzdiagramme war sehr hilfreich
für die Überprüfung der gewählten Software-Strukturen und führte zu etlichen Korrekturen in
diesem Bereich. So konnten Strukturelle Probleme grösstenteils bereits während der DesignPhase gelöst werden und die Codierung wurde entsprechend vereinfacht.
Die folgenden Unterkapitel dokumentieren die Designphase beginnend mit der Festlegung
der Namenskonventionen. Letztere existieren beim Auftraggeber nicht in geeigneter Form,
da das Hauptgeschäft des Berufsbildungscenters nicht die Softwareentwicklung, sondern die
Ausbildung darstellt.
2.3.1
Namen und Konventionen
Als erste Konvention lässt sich definieren, dass alle verwendeten Bezeichner in GradeBook
(Klassen, Methoden, Variablen, Files) in deutscher Sprache gehalten werden sollen. Dies
weil für die Software viele Bezeichner sinnvoll sind, die in der englischen Sprache keine oder
sinngemäss nur ungenügend übereinstimmende Äquivalente besitzen (z.B. Lernender, Berufsbildner, Note, etc.).
Ausnahmen: Für einige Namen ist es trotzdem sinnvoll englische Bezeichner zu verwenden.
So werden zum Beispiel in den Modelklassen die meisten Methoden mit kurzen, aussagekräftigen, englischen Präfixen versehen (get, add, …). Um die Präfixe entsprechend von
den rein deutschen Bezeichnungen auch optisch zu unterscheiden, werden die englischen
Teile nicht mit CamelCaps sondern mit einem Underscore von den deutschen Teilen getrennt (z.B. get_Daten()).
2.3.1.1 Vorgaben durch CodeIgniter
Das gewählte PHP-Framework CodeIgniter definiert bereits einen Satz von Namenskonventionen, die zwingend eingehalten werden müssen. Die folgende Auflistung beinhaltet die
wichtigsten dieser Konventionen:
Klassennamen von Controller und Models beginnen mit einem Grossbuchstaben, die
restlichen Buchstaben werden kleingeschrieben. Die Klassen werden in Dateien mit
Remo Seiler, MAS-07-02
Seite 20 von 124
identischem Namen aber mit kleinem Anfangsbuchstaben abgelegt (z.B.: Klasse
Lernender in Datei lernender.php).
Die Namen von Library-Klassen beginnen mit Grossbuchstaben und die Namen deren Dateien ebenfalls (im Gegensatz zu den Controller- und Model-Dateien). Die Namen der Library-Klassen dürfen zudem weitere Grossbuchstaben enthalten (ermöglicht für diese die CamelCaps-Schreibweise)
Helpers (Dateien mit einzelnen PHP-Hilfsfunktionen) sind keine Klassen. Für die Helpers ist aber der Dateiname vorgeschrieben. Damit CodeIgniter diese identifizieren
kann müssen die Dateien mit dem Präfix _helper enden (z.B. table_helper.php)
Private Methoden sind in Controllern aufgrund des Framework-Aufbaus nicht möglich.
Wenn eine Methode aber nur Controller-intern verwendet werden soll, kann ihr ein
Underscore vorangestellt werden (z.B. _foo()). Eine solche Methode kann nicht über
die URL aufgerufen werden, wie die restlichen Controller-Methoden.
Im Unterschied zu anderen Frameworks, definiert CodeIgniter nur die oben genannten Namensvorschriften. Damit ein einheitlicher Programmcode erstellt werden kann, werden weitere Konventionen in den folgenden Kapiteln definiert.
2.3.1.2 Klassen
Controller-Klasse
Controller-Klassen werden in GradeBook entsprechend ihrer Aufgabe und
ohne Prä- oder Postfix-Elemente benannt.
Beispiel: class Lernender {…}
Model-Klasse
Model-Klassen müssten aufgrund Ihrer Aufgabe häufig die gleichen Namen besitzen wie Controller-Klassen, was sie theoretisch auch dürften.
Da dies aber zu Verwirrungen führen könnte, werden sämtliche Models
mit einem Präfix m_ versehen.
Beispiel: class M_lernender {…}
Library-Klasse
Libraries werden gemäss Ihrer Aufgabe bezeichnet und beginnen mit
einem Grossbuchstaben. Zusammengesetzte Wörter für die Namen werden in CamelCaps-Schreibweise definiert.
Beispiel: class Bericht {…}
2.3.1.3 Methoden
Methodennamen werden in CamelCaps-Schreibweise (d.h. mit Binnenmajuskeln) und kleinen Anfangsbuchstaben verfasst. Diese Schreibweise ist weit verbreitet und ergibt eine sehr
gute Lesbarkeit. Wie bereits erwähnt, werden aber Wortteile in englischer Sprache, die als
Präfixe verwendet werden, mit einem Underscore von den Restlichen Wörtern getrennt.
Beispiele:
function get_AktuellesSemester($idLernender) {}
function newsletterAnfrageAblehnen() {}
2.3.1.4 Variablennamen
Variablennamen werden ebenfalls in CamelCaps-Schreibweise verfasst und beginnen mit
einem kleinen Anfangsbuchstaben.
Beispiel: $listeNlEmpfaenger
Remo Seiler, MAS-07-02
Seite 21 von 124
2.3.2
Controller Designklassen
Das Klassendiagramm in Abbildung 9 zeigt die vier erstellten Controller-Klassen und deren
Assoziationen zu der erstellten Library Bericht und den Libraries- und Basisklassen des CodeIgniter-Frameworks. Ausserdem ist die Vererbungshierarchie ersichtlich, welche durch die
Framework-Struktur zwingend vorgegeben ist. Zu den Framework-Klassen und der verwendeten open source Library sind nur wenn nötig die Attribute und Methoden eingeblendet.
Weitere Informationen zu diesen finden sich im CodeIgniter-Usermanual [net4] oder im Manual zur TCPDF-Library [net10].
Die Beschreibungen der einzelnen Klassen und Methoden folgen in den nachfolgenden Unterkapiteln.
class Klassendiagramm
«CodeIgniter»
Controller
«GBController»
New slette rAnfrage
«GBController»
Login
-
_TestOhneLdap: var = false
_TestNurAktive: var = false
_TestPasswort: var = false
+
+
+
+
Login()
index()
authentifizieren()
check_user(str)
verwendet
verwendet
0..*
1
1
«CILibrary»
CI_Se ssion
1
+
+
+
+
+
0..* +
+
+
+
+
+
+
+
NewsletterAnfrage()
index()
emailEingabe()
emailEingabeBestaetigen()
registrierung()
registrierungBestaetigen()
_check_select(str)
_check_captcha(captcha)
_check_email_exist(email)
auswahlLernende()
auswahlLernendeBestaetigen()
_check_session(str)
bestaetigungAnzeigen()
1
verwendet
verwendet
0..*
«GBController»
Berufsbildner
0..*
«GBController»
Lerne nder
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Lernender()
index()
semesterUebersicht(semNummer)
semesterBearbeiten()
faecherBearbeiten()
notenUebersicht(fachNummer)
noteBearbeiten(notenNummer)
noteEingeben(edit)
noteVerarbeiten()
notePruefen(strNote)
noteLoeschen(notenNummer)
noteLoeschenBestaetigen()
monatsabschluss()
monatsabschlussBestaetigen()
berichtErstellen()
«GBLibrary»
Beri cht
verwendet
0..*
1
#
#
_CI: var
_idLernender: var
+
+
+
+
+
#
#
Bericht()
Header()
Footer()
generieren(idLernender, open, path, filename)
loeschen(file)
_initBericht()
_tabelleGenerieren(header, data, totwidth, colw,
colalign, headerw, sfontc, sfonth)
_lernenderInfosGenerieren(lernender)
_uebersichtSemesterGenerieren()
_uebersichtAlleFaecherGenerieren()
#
#
#
«OSLibrary»
TCPDF
+
+
verwendet
1
1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Berufsbildner()
index()
lernendeUebersicht()
zuteilungLernende()
zuteilungLernendeVerarbeiten()
lernenderDetails(idLernender, semNummer)
nlAbonnementHinzufuegen(idLernender)
nlAbonnementHinzufuegenBestaetigen()
nlAbonnementLoeschen(idLernender, idNLE)
nlAbonnementLoeschenBestaetigen()
newsletterAnfragen()
newsletterAnfrageDetails(idNLE)
newsletterAnfrageBestaetigen()
newsletterAnfrageAblehnen()
newsletterEmpfaengerUebersicht()
newsletterEmpfaengerBearbeiten(idNLE)
newsletterEmpfaengerSpeichern()
_check_select(str)
_check_email_exist(email)
newsletterEmpfaengerLoeschen(idNLE)
newsletterEmpfaengerLoeschenBestaetigen()
statistikErstellen()
berichtErstellen(idLernender)
Header()
Footer()
Abbildung 9: Systemklassendiagramm Controller
2.3.2.1 Controller Login
Die Controller-Klasse Login ist zuständig für die Steuerung der gesamten Login- Funktionalität. Sie wird bei einem Aufruf der Webseite GradeBook vom CI-Front- Controller (index.php)
als erstes instanziiert und Übermittelt an den aufrufenden Browser die login_viewKomponente (Login-Screen). Ausserdem ist die Klasse nach erfolgreichem Login eines Benutzers verantwortlich für das erzeugen der Session und für das Routing zum entsprechenden Benutzer-Controller oder zum NewsletterAnfrage-Controller.
Die Klasse erbt von der abstrakten Klasse Controller des CodeIgniter-Frameworks.
Remo Seiler, MAS-07-02
Seite 22 von 124
class Klassendiagramm
«GBController»
Login
-
_TestOhneLdap: var = false
_TestNurAktive: var = false
_TestPasswort: var = false
+
+
+
+
Login()
index()
authentifizieren()
check_user(str)
Abbildung 10: Klasse Login
Damit die Controller-Klasse Login auch auf einem lokalen Entwicklungssystem (ohne ADSZugriff über LDAP und somit ohne ADS-Authentifizierung) betrieben und getestet werden
kann, sind spezielle Testattribute definiert. Die Nachfolgende Auflistung zeigt deren Verwendungszweck:
private $_TestOhneLdap
(true/false)
Deaktiviert sämtlich ADS-Zugriffe über LDAP. Setzt voraus, dass ein
Testpasswort gesetzt wird um sich mit den vorhandenen Benutzern
einzuloggen.
private $_TestNurAktive
(true/false)
Deaktiviert die Abfrage von Benutzerdaten im ADS und deren Aktualisierung in der GradeBook-Datenbank. Wenn _TestOhneLdap = false wird
aber die Authentifizierung über ADS gemacht.
private $_TestPasswort
(false/Testpasswort)
Falls != false wird anstelle des ADS-Passworts das Benutzers das hier
angegebene verwendet (Vorsicht unsicher!). Wird in der Testphase
verwendet um reale ADS-Benutzer ohne deren Passwort oder alle lokal
bereits erfassten Benutzer zu verwenden.
In Tabelle 2 sind die Attribute der Controller-Klasse Login beschrieben.
Methode
Beschreibung
Login()
Konstruktor der Klasse. Ruft den Konstruktor der Basisklasse auf, lädt
verschiedene benötigte Models und Libraries.
index()
Wird vom CI-Front-Controller standardmässig aufgerufen, falls keine andere Methode spezifiziert wird. index() lädt die Login-View-Komponente
und sendet diese an den Browser zurück.
authentifizieren()
Wird ausgeführt, sobald der Login-Button gedrückt wird. Validiert die Eingabedaten (korrekte und vollständige Angaben, LDAP-Verifizierung von
user und password, xss-Filter, ...) und gibt im Fehlerfall eine Fehlermeldung aus. Bei erfolgreichem Login werden die Benutzerdaten (von ADS)
in der Datenbank aktualisiert, eine Session erzeugt, und je nach Benutzer
zum zuständigen Controller umgeleitet.
check_user()
Callback-Funktion für die CI-FormValidation-Library. Überprüft den Benutzernamen und das Passwort (über LDAP im ADS).
Parameter:
$str
Der zu validierende Wert
Tabelle 2: Methoden der Klasse Login
2.3.2.2 Controller Lernender
Die Controller-Klasse Lernender ist für die Steuerung der gesamten Funktionalität, die dem
Lernenden zur Verfügung steht verantwortlich. Von Ihr werden alle Views des Lernenden
erzeugt, geladen und an den Browser gesendet. Die Klasse übernimmt die Navigation auf
den Webseiten des Lernenden und lädt die benötigten Models für das auslesen, verändern
und löschen von Daten.
Remo Seiler, MAS-07-02
Seite 23 von 124
class Klassendiagramm
Die Klasse erbt von der abstrakten
Klasse Controller des CodeIgniter-Frameworks.
«GBController»
Lerne nder
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Lernender()
index()
semesterUebersicht(semNummer)
semesterBearbeiten()
faecherBearbeiten()
notenUebersicht(fachNummer)
noteBearbeiten(notenNummer)
noteEingeben(edit)
noteVerarbeiten()
notePruefen(strNote)
noteLoeschen(notenNummer)
noteLoeschenBestaetigen()
monatsabschluss()
monatsabschlussBestaetigen()
berichtErstellen()
Abbildung 11: Klasse Lernender
Methode
Beschreibung
Lernender()
Konstruktor der Controller-Klasse Lernender Ruft den Konstruktor der
Basisklasse auf und lädt alle benötigten Models. Da Objekte der Klasse
Lernender bei jedem Seitenaufruf neu erzeugt werden (->und somit der
Konstruktor jedes Mal abgearbeitet), wird hier auch überprüft ob der aufrufende Browser die nötige Berechtigung verfügt (mittels Session-Daten).
index()
Die Methode index() wird vom CI-Front-Controller standardmässig aufgerufen, falls der Controller Lernender geladen wird ohne eine Methode
anzugeben. index() ruft die Methode semesterUebersicht() für das aktuelle Semester des Lernenden auf.
semesterUebersicht()
Die Methode lädt die benötigten Models für die Abfrage aller Daten eines
Semesters, lädt das entsprechende View-File
(lernender /
sem_uebersicht_view.php) mit den erhaltenen Daten und sendet es an
den Browser.
Parameter:
$semNummer
Anzuzeigendes Semester (Semesternummer von 18). Wird der Wert 0 übergeben und wurde zuvor noch
kein Semester ausgewählt, wird das aktuelle Semester des Lernenden ermittelt und angezeigt.
semesterBearbeiten()
Die Methode lädt das View-File sem_bearbeiten_view.php mit einem Bearbeitungsformular für das Semester (Fächer hinzufügen oder löschen)
und sendet dieses an den Browser.
faecherBearbeiten()
Wird aufgerufen, wenn in der sem_bearbeiten_view.php der Button ">"
(hinzufügen) oder "<" (entfernen) geklickt wird. Liest aus den SessionDaten das angezeigte Semester und die id des Lernenden und aus den
Post-Daten die gewählten Fächer aus. Die Fächer werden entsprechend
dem Semester hinzugefügt oder von ihm entfernt. Vor dem entfernen, wird
eine Bestätigung vom Benutzer abgefragt. Anschliessend wird wieder das
View-File lernender/sem_bearbeiten_view.php geladen und an den Browser gesendet.
notenUebersicht()
Wird aufgerufen, wenn in der Semesterübersicht auf ein Fach geklickt
wird. Lädt aus den Session-Daten die Fächer-IDs zur Fachliste (semUebersicht) und ermittelt gemäss der übergebenen Fachnummer die id des
anzuzeigenden Fachs. Anschliessend werden mit den entsprechenden
Models die Noten zum gewählten Fach aus der Datenbank gelesen, eine
Tabelle erzeugt, das View-File noten_uebersicht_view.php geladen, mit
Remo Seiler, MAS-07-02
Seite 24 von 124
der Notenübersicht ergänzt und an den Browser gesendet.
Parameter:
$fachNummer
noteBearbeiten()
Wird aufgerufen, falls in der Notenübersicht auf ein Bearbeitungssymbol
einer spezifischen Note geklickt wird. Die Methode ermittelt aus der Notennummer der Übersichtsliste die Identifikationsnummer der Note und
ruft im Erfolgsfall die Methode noteEingeben() auf.
Parameter:
$notenNummer
noteEingeben()
Die Nummer der angeklickten Note (aus Sicherheitsgründen wird hier nicht die Identifikationsnummer
übergeben.). Default = 0.
Callback-Funktion für die CI-FormValidation-Library. Prüft ob im übergebenen String ein gültiger Notenwert zwischen 1-6 und mit max. 2 Kommastellen und enthalten ist.
Parameter:
$strNote
noteLoeschen()
Gibt an ob eine neue Note erstellt (false) oder eine
bestehende editiert (true) werden soll. Default=false
Wird aufgerufen, falls in der Notenübersicht auf ein Bearbeitungssymbol
einer spezifischen Note geklickt wird. Die Methode ermittelt aus der Notennummer der Übersichtsliste die Identifikationsnummer der Note und
ruft im Erfolgsfall die Methode noteEingeben() auf.
Parameter:
$notenNummer
notePruefen()
Die Nummer der angeklickten Note (aus Sicherheitsgründen wird hier nicht die Identifikationsnummer übergeben). Default = 0.
Wird aufgerufen, falls in der Notenübersicht auf den Button "Note hinzufügen" oder auf ein Bearbeitungssymbol einer spezifischen Note geklickt
wird (letzteres via noteBearbeiten()). Die Methode lädt anschliessend das
View-File lernender/note_eingeben_view.php mit einem entsprechenden
Eingabeformular (wenn nötig ausgefüllt mit den vorh. Notenwerten) und
sendet es an den Browser.
Parameter:
$edit
noteVerarbeiten()
Nummer des Fachs auf der Liste in der Semesterübersicht. Aus Sicherheitsgründen wird hier nicht die
Fach-id übergeben -> diese werden in den SessionDaten (Serverseitig) zwischengespeichert.
Der zu validierende Wert als String
Wird aufgerufen, falls in der Notenübersicht auf ein Lösch-Symbol einer
Note geklickt wird. Speichert die id der zu löschenden Note in den Session-Daten, lädt das View-File confirm_note_loeschen_view.php (Bestätigung des Löschvorgangs) und sendet dieses an den Browser.
Parameter:
$notenNummer
Die Nummer (Notenübersicht) der zu löschenden
Note.
noteLoeschenBestaetigen()
Wird aufgerufen, wenn im View-File confirm_note_loeschen_view.php
einer der Buttons geklickt wurde. Falls der Bestätigen-Button geklickt wurde, wird die gewählte Note mittels des entsprechenden Models gelöscht.
monatsabschluss()
Wird aufgerufen, falls der Monatsabschluss-Infobalken angezeigt wird und
der Benutzer auf den Button "Monat abschliessen klickt". Generiert eine
Tabelle mit den Newsletter-Empfängern des Lernenden, lädt das View-
Remo Seiler, MAS-07-02
Seite 25 von 124
File monatsabschluss_view.php und sendet dieses an den Browser.
monatsabschlussBestaetigen()
Wird aufgerufen wenn im Monatsabschlussformular ein Button gedrückt
wird. Die Methode ist zuständig für die Validierung und Speicherung des
Monatsabschlusses (mittels Model m_lernender) und die Generierung und
Versendung der Notennewsletter (mittels Model m_email).
berichtErstellen()
Erzeugt mithilfe der Library Bericht einen Bericht im PDF-Format und
sendet diesen zum Download an den Browser.
Tabelle 3: Methoden der Klasse Lernender
2.3.2.3 Controller Berufsbildner
Die Controller-Klasse Berufsbildner ist für die Steuerung der gesamten Funktionalität, die
dem Berufsbildner zur Verfügung steht verantwortlich. Von Ihr werden alle Views des Berufsbildners erzeugt, geladen und an den Browser gesendet. Die Klasse übernimmt die Navigation auf den Webseiten des Berufsbildners und lädt die benötigten Models für das auslesen, verändern und löschen von Daten. Die Berufsbildner-Klasse verwendet ausserdem verschiedene Libraries und greift auch auf die Models für die Lernenden-Daten (Noten, Zuteilungen, Benutzerdaten, etc.) zu. Die Klasse erbt von der abstrakten Klasse Controller des
CodeIgniter-Frameworks. class Klassendiagramm
«GBController»
Berufsbildner
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Berufsbildner()
index()
lernendeUebersicht()
zuteilungLernende()
zuteilungLernendeVerarbeiten()
lernenderDetails(idLernender, semNummer)
nlAbonnementHinzufuegen(idLernender)
nlAbonnementHinzufuegenBestaetigen()
nlAbonnementLoeschen(idLernender, idNLE)
nlAbonnementLoeschenBestaetigen()
newsletterAnfragen()
newsletterAnfrageDetails(idNLE)
newsletterAnfrageBestaetigen()
newsletterAnfrageAblehnen()
newsletterEmpfaengerUebersicht()
newsletterEmpfaengerBearbeiten(idNLE)
newsletterEmpfaengerSpeichern()
_check_select(str)
_check_email_exist(email)
newsletterEmpfaengerLoeschen(idNLE)
newsletterEmpfaengerLoeschenBestaetigen()
statistikErstellen()
berichtErstellen(idLernender)
Abbildung 12: Klasse Berufsbildner
Methode
Beschreibung
Berufsbildner()
Konstruktor der Controller-Klasse Berufsbildner Ruft den Konstruktor
der Basisklasse auf und lädt alle benötigten Models. Da Objekte der
Klasse Lernender bei jedem Seitenaufruf neu erzeugt werden (->und
somit der Konstruktor jedes Mal abgearbeitet), wird hier auch überprüft ob der aufrufende Browser die nötige Berechtigung verfügt (mittels Session-Daten).
index()
Die Methode index() wird vom CI-Front-Controller standardmässig
aufgerufen, falls der Controller Berufsbildner geladen wird ohne eine
Methode anzugeben. index() leitet den Browser zur uebersichtLernende um.
Remo Seiler, MAS-07-02
Seite 26 von 124
lernendeUebersicht()
Generiert die Tabelle mit den Lernenden die dem Berufsbildner zugeteilt sind, lädt das View-File lernende_uebersicht_view.php und
sendet das File mit den Daten an den Browser.
zuteilungLernende()
Lädt das View-File lernende_bearbeiten_view.php mit einem Bearbeitungsformular für die zugeteilten Lernenden des Berufsbildners
(Lernende hinzufügen oder entfernen) und sendet dieses an den
Browser.
zuteilungLernendeVerarbeiten()
Wird aufgerufen, wenn im View-File lernende_bearbeiten_view.php
der Button ">" (hinzufügen) oder "<" (entfernen) geklickt wird. Liest
aus den Post-Daten die gewählten Lernenden aus und fügt diese
hinzu oder entfernt sie je nach Wahl durch den Berufsbildner. Anschliessend wird wieder auf "lernendeBearbeiten" umgeleitet (HTTP
redirect).
lernenderDetails()
Wird aufgerufen, wenn in der Lernenden-Übersicht auf den Namen
eines Lernenden geklickt wird. Die Methode erzeugt Tabellen mit der
Semesterübersicht, den Newsletter-Empfängern und den persönlichen Daten des Lernenden. Anschliessend wird das View-File lernender_details_view.php geladen und an den Browser gesendet.
Parameter:
nlAbonnementHinzufuegen()
$idLernender
Die Identifikationsnummer des Lernenden
$semNummer
Die Nummer des Semesters (1-8) das angezeigt
werden soll. Wenn der Wert 0 übergeben wird,
wird das aktuelle Semester des Lernenden ermittelt und angezeigt.
Generiert eine Liste mit allen Newsletter-Empfängern die dem Lernenden noch nicht zugeteilt sind und generiert eine Tabelle mit Auswahlmöglichkeiten.
Lädt
anschliessend
das
View-File
nla_hinzufuegen_view.php und sendet es an den Browser.
Parameter:
$idLernender
Die Identifikationsnummer des Lernenden
nlAbonnementHinzufuegenBestaetigen()
Validiert das Auswahlformular für Newsletter-Empfänger. Im Erfolgsfall werden für die gewählten Newsletter-Empfänger mittels Model
m_newsletter neue Newsletter-Abonnemente erzeugt und die Newsletter-Anfragen aus der Datenbank gelöscht. Anschliessend wird
wieder zur Detailansicht Lernender umgeleitet (HTTP redirect).
nlAbonnementLoeschen()
Lädt das View-File confirm_nla_loeschen_view.php und sendet das
Bestätigungsformular für das Löschen eines NewsletterAbonnements an den Browser.
Parameter:
$idLernender
Die Identifikationsnummer des Lernenden
$idNLE
Die Identifikationsnummer des NewsletterEmpfängers
nlAbonnementLoeschenBestaetigen()
Wird aufgerufen, wenn im View-File confirm_nle_loeschen_view.php
einer der Buttons geklickt wurde. Falls der Bestätigen-Button geklickt
wurde, wird der Newsletter-Empfänger mithilfe des entsprechenden
Models gelöscht.
newsletterAnfragen()
Falls für die zugeteilten Lernenden des Berufsbildners NewsletterAnfragen vorhanden sind, generiert die Methode eine Übersichtstabelle mit allen offenen Newsletter-Anfragen und pro Newsletter-
Remo Seiler, MAS-07-02
Seite 27 von 124
Empfänger eine Navigationsmöglichkeit um auf die detaillierte Ansicht zu gelangen. Anschliessend lädt die Methode das View-File
nla_uebersicht_view.php und sendet dieses an den Browser.
newsletterAnfrageDetails()
Generiert Tabellen für die Detailansicht eines NewsletterAntragstellers mit folgenden Informationen: Persönliche Angaben
Newsletter-Empfänger (NLE) und eine Tabelle mit allen Lernenden
des Berufsbildners für die eine Anfrage vom NLE offen ist mit Auswahlmöglichkeit für die Bestätigung oder Ablehnung der Anfragen.
Anschliessend wird das View-File nla_detail_view.php geladen, mit
den Daten versehen und an den Browser gesendet.
Parameter:
$idNLE
Identifikationsnummer des Newsletter-Empfängers
newsletterAnfrageBestaetigen()
Wird aufgerufen, wenn auf der Newsletter-Anfrage-Detailansicht
Anfragen ausgewählt und das Formular durch klicken eines Button
abgesendet wurde. Falls die ausgewählten Anfragen bestätigt wurden, werden die entsprechenden Newsletter-Abonnemente mittels
Model m_newsletter erzeugt, die Anfragen gelöscht und wieder auf
newsletterAnfrageDetails() umgeleitet. Falls die ausgewählten Anfragen
abgelehnt
wurden,
wird
das
View-File
confirm_nla_ablehnen_view.php mit einem Bestätigungsformular geladen und an den Browser gesendet.
newsletterAnfrageAblehnen()
Wird aufgerufen, wenn auf dem Anfrage-Bestätigungsformular ein
Button geklickt wurde. Falls der Bestätigen-Button betätigt wurde,
werden die Newsletter-Anfragen mittels Model m_newsletter gelöscht und mittels Model m_email ein entsprechendes Mail an den
Antragsteller gesendet. Anschliessend wird auf die NewsletterAnfrage- Detailansicht umgeleitet (HTTP redirect).
newsletterEmpfaengerUebersicht()
Generiert eine Tabelle mit allen erfassten Newsletter-Empfängern
mit Bearbeitungs- und Lösch-Symbolen. Anschliessend lädt die Methode das View-File nle_uebersicht_view.php und sendet es mit den
Anzeigedaten an den Browser.
newsletterEmpfaengerBearbeiten()
Wird aufgerufen, wenn in der Übersicht Newsletter-Empfänger auf
einen Bearbeiten-Button oder den Button "Newsletter-Empfänger
erfassen" geklickt wird. Lädt das View-File nle_earbeiten_view.php
mit einem Formular für die Eingabe der Daten und sendet dieses an
den Browser.
Parameter:
$idNLE
Identifikationsnummer des Newsletter-Empfängers
newsletterEmpfaengerSpeichern ()
Die Methode ist zuständig für die Validierung und Speicherung der
eingegebenen Daten zum Newsletter-Empfänger (mittels entsprechendem Model). Die Formular- Daten werden zuvor geprüft (Daten
vorhanden, korrekt, Längen, etc.) und gefiltert (xss, trim). Im Fehlerfall wird eine Meldung ausgegeben und das View-File für das Formular neu geladen, ansonsten werden die Daten gespeichert und per
HTTP redirect wieder auf die Übersicht umgeleitet.
_check_select()
Callback-Funktion für die CI-FormValidation-Library. Überprüft ob
aus dem Dropdown-Menu (HTML-select) eine Auswahl getroffen
wurde.
Parameter:
$str
Remo Seiler, MAS-07-02
Enthält die Auswahl als String.
Seite 28 von 124
_check_email_exist()
Callback-Funktion für die CI-FormValidation-Library. Überprüft ob für
die eingegebene Email-Adresse bereits ein anderer NewsletterEmpfänger registriert ist.
Parameter:
$email
newsletterEmpfaengerLoeschen()
Enthält die eingegebene Email-Adresse als String
Wird aufgerufen, wenn in der Newsletter-Empfänger-Übersicht auf
ein Löschen- Symbol geklickt wird. Lädt das View-File confirm_nle_loeschen_view.php (Bestätigung des Löschvorgangs) und
sendet dieses an den Browser.
Parameter:
$idNLE
Identifikationsnummer des Newsletter-Empfängers
newsletterEmpfaengerLoeschenBestaetigen()
Wird aufgerufen, wenn im Bestätigungsformular für das Löschen
eines Newsletter-Empfängers ein Button betätigt wird. Falls der
Löschvorgang bestätigt wurde, wird der Newsletter-Empfänger mittels Model M_newsletter gelöscht.
statistikErstellen()
Wird in GradeBook Release 2 umgesetzt.
berichtErstellen()
Erstellt mittels Library Bericht zum Lernenden dessen Identifikationsnummer übergeben wird einen Bericht als PDF-File und sendet diesen zum Download an den Browser.
Parameter:
$idLernender
Identifikationsnummer des Lernenden
Tabelle 4: Methoden der Klasse Berufsbildner
2.3.2.4 Controller NewsletterAnfrage
Die Controller-Klasse Newsletter-Anfrage ist für die Steuerung der Funktionalitäten für die
Newsletter-Anfragen verantwortlich. Sie wird instantziert, sobald auf der Login-Seite (siehe
Kapitel 2.3.2.1) auf den Link „Newsletter beantragen“ geklickt wird. sie beinhaltet die Controller-Elemente für die Abfrage und Überprüfung der Email-Adresse des Antragstellers, allfällige Registrierung eines neuen Newsletter-Empfängers, Auswahl von Lernenden für Newsletter-Anfragen durch einen bestehenden Newsletter-Empfänger und versenden von AnfrageMails an die entsprechenden Berufsbildner.
Die Klasse erbt von der abstrakten
Controller des CodeIgniter-Frameworks.
class Klasse
Klassendiagramm
«GBController»
New slette rAnfrage
+
+
+
+
+
+
+
+
+
+
+
+
+
NewsletterAnfrage()
index()
emailEingabe()
emailEingabeBestaetigen()
registrierung()
registrierungBestaetigen()
_check_select(str)
_check_captcha(captcha)
_check_email_exist(email)
auswahlLernende()
auswahlLernendeBestaetigen()
_check_session(str)
bestaetigungAnzeigen()
Abbildung 13: Klasse NewsletterAnfrage
Remo Seiler, MAS-07-02
Seite 29 von 124
Methode
Beschreibung
NewsletterAnfrage()
Konstruktor der Klasse NewsletterAnfrage. Ruft den Basisklassenkonstruktor auf und initialisiert das Template für die Anzeige.
index()
Die Methode index() wird vom CI-Front-Controller standardmässig
aufgerufen, falls der Controller NewsletterAnfrage geladen wird ohne
eine Methode anzugeben. index() ruft lediglich die Methode emailEingabe() auf.
emailEingabe()
Wird aufgerufen sobald jemand auf den Link Newsletter beantragen
auf der GradeBook-Login-Seite klickt. Die Methode lädt ein Formular
zur Email-Eingabe und zeigt dieses an.
emailEingabeBestaetigen()
Wird aufgerufen wenn im Email-Eingabeformular auf einen Button
geklickt wird. Validiert die eingegebene Email-Adresse, prüft ob bereits
ein NL-Empfänger mit dieser Adresse vorhanden ist und leitet entsprechend auf das Lernende- Auswählen-Formular oder auf das Registrierungsformular um. Falls die eingegebene Email-Adresse ungültig ist, wird das Formular mit einer Fehlermeldung erneut ausgegeben.
registrierung()
Lädt das View-File nl_registrierung_view.php mit dem Registrierungsformular, erzeugt eine Captcha-Grafik, speichert die Captcha-Daten in
der Session-Tabelle und sendet das View-File an den Browser.
registrierungBestaetigen()
Wird aufgerufen, wenn auf "Senden" oder "Abbrechen" im Registrierungsformular geklickt wird. Validiert die Formulardaten (Korrekte Werte, alle zwingenden Felder vorhanden, Captcha-Zeichen korrekt, xssFilter, ...) und lädt im Fehlerfall das entsprechende View neu, ergänzt
es mit einer Fehlermeldung und sendet dieses erneut an den Browser.
Falls alle Eingaben korrekt sind wird ein neuer Newsletter-Empfänger
mit den Registrierungsdaten erfasst und in der Datenbank abgelegt.
Anschliessend wird das View-File für die Lernenden-Auswahl geladen
und an den Browsergesendet.
_check_select()
Callback-Funktion für die CI-FormValidation-Library. Überprüft ob aus
dem Dropdown-Menu (HTML-select) eine Auswahl getroffen wurde.
Parameter:
$str
_check_captcha()
Enthält die Auswahl als String.
Callback-Funktion für die CI-FormValidation-Library. Überprüft ob die
übergebenen Captcha-Zeichen mit der erzeugten Grafik übereinstimmen.
Parameter:
$captcha
_check_email_exist()
Enthält die eingegebenen Zeichen als String.
Callback-Funktion für die CI-FormValidation-Library. Überprüft ob für
die eingegebene Email-Adresse bereits ein Newsletter-Empfänger
registriert ist.
Parameter:
$email
Enthält die Eingegebene Email-Adresse als String
auswahlLernende()
Generiert eine Tabelle mit allen Lernenden des Berufsbildungscenters
mit Checkbox-Auswahlmöglichkeiten. Lädt anschliessend das ViewFile nl_auswahl_view.php, ergänzt diese mit der Tabelle und weiteren
Informationen und sendet sie an den aufrufenden Browser.
auswahlLernendeBestaetigen()
Wird aufgerufen falls im Lernenden-Auswahl-Formular auf Newsletter
beantragen oder abbrechen geklickt wird. Validiert die eingaben und
Remo Seiler, MAS-07-02
Seite 30 von 124
speichert im Erfolgsfall für jeden Ausgewählten Lernenden eine Newsletter-Anfrage (->m_newsletter). Anschliessend wird zur bestaetigungAnzeigen()-Methode umgeleitet (HTTP-redirect).
_check_session()
Callback-Funktion für die CI-FormValidation-Library. Überprüft ob die
Session noch aktiv oder bereits abgelaufen ist.
bestaetigungAnzeigen()
Generiert eine Liste mit allen ausgewählten Lernenden, lädt das ViewFile nl_bestaetigung_view.php mit dem entsprechenden Bestätigungstext und sendet diese an den Browser.
Tabelle 5: Methoden der Klasse Newsletter-Anfrage
2.3.2.5 Library Bericht
Die Library-Klasse Bericht dient dazu Berichte eines Lernenden als PDF-File zu erstellen.
Die Berichte beinhalten die aktuelle Semesterübersicht und die Übersicht über alle Semester
mit allen Fächern und dazu eingegebenen Noten des Lernenden. Die Berichte können entweder direkt an den Browser gesendet oder als File auf dem Server abgelegt werden um sie
als Email-Anhang verwenden zu können. Die Klasse erbt von der Klasse TCPDF aus der
open source-Library tcppdf [net10]. Letzteres, damit die Funktionalität für das schreiben in
PDF-Files direkt zur Verfügung steht und weil die Header- und Footer-Methoden der Basisklasse überschrieben werden müssen um eigene Kopf- und Fusszeilen im PDF-Dokument
erzeugen zu können.
class Klassendiagramm
«OSLibrary»
TCPDF
+
+
Header()
Footer()
«GBLibrary»
Beri cht
#
#
_CI: var
_idLernender: var
+
+
+
+
+
#
#
#
#
#
Bericht()
Header()
Footer()
generieren(idLernender, open, path, filename)
loeschen(file)
_initBericht()
_tabelleGenerieren(header, data, totwidth, colw, colalign, headerw, sfontc, sfonth)
_lernenderInfosGenerieren(lernender)
_uebersichtSemesterGenerieren()
_uebersichtAlleFaecherGenerieren()
Abbildung 14: Library Bericht mit Basisklasse (tcpdf-Library)
Methode
Beschreibung
Bericht()
Konstruktor der Library-Klasse Bericht. Ruft den Konstruktor der Basisklasse TCPDF mit den benötigten Übergabeparametern auf und lädt alle
für die Berichterzeugung benötigten Models.
Header()
Methode zur Erzeugung der Kopfzeile (Überschriebene Methode der
Basisklasse TCPDF)
Footer()
Methode zur Erzeugung der Fusszeile (Überschriebene Methode der
Remo Seiler, MAS-07-02
Seite 31 von 124
Basisklasse TCPDF)
generieren()
loeschen()
Generiert einen Bericht als PDF-File und ruft dazu die verschiedenen
Hilfs- Methoden auf.
Parameter:
$idLernender
Die Identifikationsnummer des Lernenden
$open
Definiert ob das PDF-File an den Browser gesendet (true) oder auf dem Server gespeichert (false)
werden soll. Default = true
$path
Definiert den relativen Pfad (relativ zum index.php
-root-Verzeichnis) für das File falls es auf dem
Server gespeichert werden soll. Default='berichte/'
$filename
Definiert den Dateinamen falls ein anderer als der
automatisch generierte ('{datum}_Bericht_{name
lernender}.pdf') gewünscht wird (null = automatisch). Default=null.
Löscht das durch den Parameter $file definierte File vom Server. Dient
dazu einen generierten Bericht nach dem Versenden per Mail wieder
vom Server zu löschen.
Parameter:
$file
Zu löschende Datei mit relativem Pfad zum zum
index.php-root-Verzeichnis und komplettem Dateinamen
_initBericht()
Initialisiert ein PDF-File mit allen benötigten Einstellungen (Papierformat,
Ausrichtung, Ränder, Dokumentinformationen, etc.) zum erstellen eines
Berichts.
_tabelleGenerieren()
Generiert eine Tabelle abhängig von den übergebenen Parametern und
von den darzustellenden Zelleninhalten. Die Tabelle wird mit der Multicell-Methode aus der Basisklasse aufgebaut. Die Methode kann universell eingesetzt werden und wird für das Erzeugen beider Tabellenarten
(Semesterübersicht und Gesamtübersicht) verwendet.
Parameter:
Remo Seiler, MAS-07-02
$header
Array aus Strings mit den Inhalten der TabellenHeader-Zeile.
$data
Array aus Arrays mit den Inhalten aller Zeilen. Pro
Zeile ist ein Array enthalten, in dem für jede Spalte ein String mit dem Zelleninhalt enthalten ist.
$totwidth
Gesamte Tabellenbreite in [mm]. Aus ihr werden
die Spaltenbreiten berechnet, da diese relativ (als
Faktor) übergeben werden. Wenn der Wert 0
übergeben wird, gilt die gesamte Seitenbreite
(ohne Ränder) als Tabellenbreite.
$colw
Array aus Doubles welche die Spaltenbreiten
definieren. Werte sind als Faktoren zu verstehen
(zwischen 0-1) die Mit der gesamtbreite/Anzahl
Spalten verrechnet werden. Die Summe der Faktoren sollte sinnvollerweise 1 ergeben.
$colalign
Array aus Strings mit den Ausrichtungs-Symbolen
(Buchstaben L, R, C) für jede einzelne Spalte.
Siehe dazu auch Multicell-Methode der Klasse
TCPDF.
Seite 32 von 124
_lernenderInfosGenerieren()
$headerw
Array aus Doubles welche die Spaltenbreiten der
Header-Zeile definieren. Werte sind als Faktoren
zu verstehen (zwischen 0-1) die mit der gesamtbreite/Anzahl Spalten verrechnet werden. Die
Summe der Faktoren sollte sinnvollerweise 1
ergeben. Falls headerw = null wird die gleiche
Breite wie bei den Datenzeilen angenommen
(Default)
$sfontc
Schriftgösse für Datenzeilen. Default=9
$sfonth
Schriftgrösse für Header-Zeile. Default=7
Der Methode werden die Daten eines Lernenden in einem Array übergeben und sie generiert daraus den PDF-Teil mit den persönlichen Informationen zum Lernenden.
Parameter:
$lernender
Array mit Daten des Lernenden (siehe
m_lernender ->get_LernenderInfos() )
_uebersichtSemesterGenerieren()
Liest mittels der entsprechenden Models die Semester, Fach und Notendaten des Lernenden aus der Datenbank, generiert daraus eine Tabelle mit der Semesterübersicht (aktuelles Semester) und fügt diese im
PDF-File ein.
_uebersichtAlleFaecherGenerieren()
Liest mittels der entsprechenden Models die Semester, Fach und Notendaten des Lernenden aus der Datenbank, generiert daraus Tabellen
mit den Gesamtübersichten (alle Semester, alle Fächer und alle Noten)
und fügt diese im PDF-File ein.
Tabelle 6: Methoden der Klasse Newsletter-Anfrage
2.3.2.6 CodeIgniter-Klassen
class Klassendiagr...
«CodeIgniter»
Controller
Die Klasse Controller ist die Basisklasse für alle GradeBook-Controllerklassen. Sie wird vom
CodeIgniter-Framework (siehe Kapitel 2.1.2.2) zur Verfügung gestellt und bietet verschiedene grundlegende Funktionalitäten, dieclass
vonKlassendiagr...
allen Controllern benötigt werden.
«CILibrary»
Sess ion
Die Session-Klasse ist eine CodeIgniter-Library die das gesamte Handling mit SessionDaten übernimmt. Sie arbeitet mit eigenen Methoden und nicht mit den nativen php-SessionFunktionen. Ein grosser Vorteil dieser Session-Klasse ist, dass Sie viele Funktionalitäten wie
zum Beispiel die Verschlüsselung von Cookie-Daten und das Ablegen der kompletten Session-Daten in einer Datenbank-Tabelle zur Verfügung stellt. So kann für die sensiblen Daten
die in der Session abgelegt werden grösstmögliche Sicherheit gewährleistet werden.
Remo Seiler, MAS-07-02
Seite 33 von 124
2.3.3
Model Designklassen
Im Klassendiagramm in Abbildung 15 sind die erstellten Model-Klassen und deren Assoziationen zu den verwendeten Libraries dargestellt. Wie
auch im Controller-Klassendiagramm (siehe Kapitel 2.3.2) werden hier nicht alle Attribute und Methoden dargestellt. Die Assoziationen der Models
zu den Controllern sind unter anderem in der Dynamischen Analyse genauer erläutert. Die Beschreibungen der einzelnen Klassen folgen in den
nachfolgenden
Unterkapiteln.
class Klassendiagramm Model
«OSLibrary»
Ldap
«GBModel»
M_new s letter
«GBModel»
M_benutzer
«GBModel»
M_login
verwendet
+
+
+
#
verwendet
1
+
#
0..* +
+
+
«GBModel»
M_berufs bildner
+
+
+
+
+
+
+
+
+
+
+
+
«GBModel»
M_e ma il
TCPDF
«GBLibrary»
Klassendiagram m Controller::
Beri cht
M_login()
authentifizierung(Benutzername, Passwort)
update_Benutzerdaten(Benutzername, newData)
get_BenutzerdatenLdap(Benutzername)
M_berufsbildner()
get_Lernende(idBerufsbildner, zugeteilt)
get_idBerufsbildner(Benutzername)
get_DatenBerufsbildner(idBerufsbildner)
add_Lernender(idBerufsbildner,
idLernender)
remove_Lernender(idBerufsbildner,
idLernender)
get_BerufsbildnerZuLernenden(lernende)
M_benutzer()
get_Benutzer(Benutzername)
get_idBerufsgruppe(Berufsgruppe)
get_loginStatus(idBenutzer, idBenutzergruppe)
logoff_Andere(idSession)
«Abstract / CI»
Model
M_email()
send_email(email, anhang)
send_nlaAblehnen(idNLE, idAnfragen)
send_notenNewsletter(idLernender, mAbschluss,
notenErhalten)
send_anfrageMails(berufsbildner, idNLE)
«GBModel»
M_lernender
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
M_newsletter()
add_nlAbonnement(idLernender, idNLE)
delete_nlAbonnement(idLernender, idNLE)
add_nlAnfrage(idLernender, idNLE, ipAdresse)
delete_nlAnfrage(idLernender, idNLE)
confirm_nlAnfrage(idAnfrage, confirm)
add_nlEmpfaenger(daten)
update_nlEmpfaenger(idNLE, data)
delete_nlEmpfaenger(idNLE)
get_nlAnfragen(idBerufsbildner, idNLE)
get_AnzahlNlAnfragen(idBerufsbildner)
get_idAnfrage(idLernender, idNLE)
get_nlAnfrage(idAnfrage)
get_nlEmpfaengerLernender(idLernender, zugeteilt)
get_AlleNlEmpfaenger()
get_LernendeNlEmpfaenger(idNLE)
get_nlEmpfaenger(idNLE)
get_idNLE(email)
«GBModel»
M_fach
M_lernender()
get_AktuellesSemester(idLernender)
get_AlleLernende()
get_Daten(idLernender)
get_idLernender(Benutzername)
get_Berufsgruppe(idLernender)
get_Monatsabschluss(idLernender)
set_Monatsabschluss(idLernender, notenErhalten)
«GBModel»
M_sem ester
+
+
+
+
+
M_semester()
get_Faecher(idSemester)
get_idSemester(idLernender, Nummer)
add_Fach(idSemester, idFach)
remove_Fach(idSemester, idFach)
+
+
+
+
+
+
+
M_fach()
get_alleFaecher(idBerufsgruppe,
idLernender)
get_alleFaecherLernender(idLernender)
get_Infos(idFach)
get_Noten(idSemester, idFach)
get_Durchschnitt(idSemester, idFach)
add_Neu(idLernender, fachName)
«GBModel»
M_note
+
+
+
+
+
+
+
M_note()
add_NeueNote(note, idSemester, idFach)
update_Note(idNote, note)
delete_Note(idNote)
get_Notengewichte()
get_Notentypen()
get_NotenDaten(idNote)
Abbildung 15: Systemklassendiagramm Models
Remo Seiler, MAS-07-02
Seite 34 von 124
2.3.3.1 Beschreibung der Klassen
Das Einsatzgebiet und der Zweck der einzelnen Model-Klassen und Libraries wird in der
nachfolgenden Tabelle 7 erläutert (mit Ausnahme der Library Bericht, siehe dazu Kapitel
2.3.2.5). Aufgrund der grösstenteils selbsterklärenden Namensgebung der einzelnen ModelMethoden, wird aber auf deren detaillierte Beschreibung verzichtet. Die Methoden werden im
Source-Code ausführlich kommentiert und können bei Bedarf dort genauer studiert werden.
Klasse
class
Klassendiagramm Model
«Abstract / CI»
Model
class Klassendiagramm Model
«GBModel»
M_login
+
+
+
#
M_login()
authentifizierung(Benutzername, Passwort)
update_Benutzerdaten(Benutzername, newData)
get_BenutzerdatenLdap(Benutzername)
class Klassendiagramm Model
«GBModel»
M_e ma il
+
#
+
+
M_email()
send_email(email, anhang)
send_nlaAblehnen(idNLE, idAnfragen)
send_notenNewsletter(idLernender, mAbschluss,
notenErhalten)
send_anfrageMails(berufsbildner,
idNLE)
class+ Klassendiagramm
Model
«GBModel»
M_berufs bildner
+
+
+
+
+
M_berufsbildner()
get_Lernende(idBerufsbildner, zugeteilt)
get_idBerufsbildner(Benutzername)
get_DatenBerufsbildner(idBerufsbildner)
add_Lernender(idBerufsbildner,
idLernender)
+ remove_Lernender(idBerufsbildner,
idLernender)
get_BerufsbildnerZuLernenden(lernende)
class+ Klassendiagramm
Model
«GBModel»
M_lernender
+ M_lernender()
+ get_AktuellesSemester(idLernender)
+ get_AlleLernende()
+ get_Daten(idLernender)
+ get_idLernender(Benutzername)
+ get_Berufsgruppe(idLernender)
+ get_Monatsabschluss(idLernender)
set_Monatsabschluss(idLernender,
notenErhalten)
class+ Klassendiagramm
Model
«GBModel»
M_sem ester
+
+
+
+
+
M_semester()
get_Faecher(idSemester)
get_idSemester(idLernender, Nummer)
add_Fach(idSemester, idFach)
remove_Fach(idSemester, idFach)
Remo Seiler, MAS-07-02
Beschreibung
Die Klasse Model ist die Basisklasse für alle GradeBook-Modelklassen. Sie wird vom CodeIgniterFramework (siehe Kapitel 2.1.2.2) zur Verfügung gestellt und bietet verschiedene grundlegende Funktionalitäten, die von allen Modeln benötigt werden.
Verantwortlich für den Zugriff über LDAPs (SSL) auf die
DomainController des BBCnet-ADS mittels der open source-Library adLDAP. Dies wird verwendet für die Authentifizierung von Benutzern und für das Auslesen der im ADS
für diese Benutzer erfassten Daten. Zudem werden diverse
Datenbankzugriffe realisiert um Benutzer erfassen und
deren Daten aktualisieren zu können.
Verantwortlich für die Generierung und Versendung aller
Email-Nachrichten aus GradeBook. Das Model verwendet
dazu die CodeIgniter-Library Email und versendet die
Nachrichten über den SMTP-Server des Berufsbildungscenters und mit dem Konto
[email protected]
Stellt Methoden für die Daten des Benutzers Berufsbildner
zur Verfügung. Mit dem Model können aus der GradeBookDatenbank Daten zu den Lernenden die dem Berufsbildner
zugeteilt sind oder Daten zum Berufsbildner selbst verarbeitet (gelesen oder verändert) werden.
Stellt Methoden für die Daten des Benutzers Lernender zur
Verfügung. Mit dem Model können aus der GradeBookDatenbank Daten zu den Lernenden, deren Semester,
Monatsabschlüsse etc. verarbeitet (gelesen oder verändert)
werden.
Stellt Methoden für die Daten der Semester zur Verfügung.
Mit dem Model können aus der GradeBook-Datenbank
Daten zu Semestern und zu Fächern die dem Semester
zugeteilt sind verarbeitet (gelesen oder verändert) werden.
Seite 35 von 124
class Klassendiagramm Model
«GBModel»
M_fach
+
+
M_fach()
get_alleFaecher(idBerufsgruppe,
idLernender)
+ get_alleFaecherLernender(idLernender)
+ get_Infos(idFach)
+ get_Noten(idSemester, idFach)
+ get_Durchschnitt(idSemester, idFach)
add_Neu(idLernender,
class+ Klassendiagramm
ModelfachName)
«GBModel»
M_note
+ M_note()
+ add_NeueNote(note, idSemester, idFach)
+ update_Note(idNote, note)
+ delete_Note(idNote)
+ get_Notengewichte()
+ get_Notentypen()
get_NotenDaten(idNote)
class+ Klassendiagramm
Model
«GBModel»
M_new s letter
+ M_newsletter()
+ add_nlAbonnement(idLernender, idNLE)
+ delete_nlAbonnement(idLernender, idNLE)
+ add_nlAnfrage(idLernender, idNLE, ipAdresse)
+ delete_nlAnfrage(idLernender, idNLE)
+ confirm_nlAnfrage(idAnfrage, confirm)
+ add_nlEmpfaenger(daten)
+ update_nlEmpfaenger(idNLE, data)
+ delete_nlEmpfaenger(idNLE)
+ get_nlAnfragen(idBerufsbildner, idNLE)
+ get_AnzahlNlAnfragen(idBerufsbildner)
+ get_idAnfrage(idLernender, idNLE)
+ get_nlAnfrage(idAnfrage)
+ get_nlEmpfaengerLernender(idLernender, zugeteilt)
+ get_AlleNlEmpfaenger()
+ get_LernendeNlEmpfaenger(idNLE)
+ get_nlEmpfaenger(idNLE)
get_idNLE(email) Model
class+ Klassendiagramm
«GBModel»
M_benutzer
+ M_benutzer()
+ get_Benutzer(Benutzername)
+ get_idBerufsgruppe(Berufsgruppe)
+ get_loginStatus(idBenutzer, idBenutzergruppe)
+ logoff_Andere(idSession)
class Klassendiagramm Model
«OSLibrary»
Ldap
Stellt Methoden für die Daten der Fächer zur Verfügung.
Mit dem Model können Daten aus der GradeBookDatenbank zu Fächern, zu Noten die spezifischen Fächern
(resp. FachSemester-Kombinationen) zugeteilt sind und zu
Durchschnitten derselben verarbeitet werden.
Stellt Methoden für die Verarbeitung von Notendaten zur
Verfügung. Mit ihr werden einzelne Noten gespeichert,
aktualisiert, gelöscht und auf die Noten-relevanten zusätzlichen Daten zugegriffen (Notentypen, Notengewichte,
Durchschnitte, ...).
Stellt Methoden für die Verarbeitung der Daten zu Newsletter-Empfängern, deren Newsletter-Abonnementen und
allfälliger Newsletter-Anfragen zur Verfügung.
Dient dazu die Datenbank-Tabelle Benutzer abzubilden
und die Identifikationsnummer einer Berufsgruppe aus der
Datenbank zu lesen. letzteres wird im Model M_login verwendet. Zudem stellt M_benutzer Möglichkeiten für die
Anmeldestatus-Überprüfung und das automatische abmelden von Benutzern (verhindern von MehrfachAnmeldungen am System) zur Verfügung.
Dient für alle LDAP Zugriffe auf die Domaincontroller des
BBCnet (über SSL).
Die Library Ldap entspricht der open source Library adLDAP wurde aber wegen CodeIgniter eigenen Namenskonventionen umbenannt. Ausserdem wurden die Konfigurationen für den Zugriff auf die Domaincontroller des BBCnet
direkt in der Library definiert und kleine Anpassungen für
den Einsatz in CodeIgniter vorgenommen.
Die Library adLDAP selbst wurde von Scott Barnett und
Richard Hyland geschrieben und unter der „GNU Lesser
General Public“ - Lizenz (Version 2.1) veröffentlicht. Alle
weiteren Informationen zu dieser Library sind unter [net11]
zu finden
Tabelle 7: Model-Klassen
Remo Seiler, MAS-07-02
Seite 36 von 124
2.3.4
View
Da die optische Gestaltung für eine Webapplikation von zentraler Bedeutung ist, muss dieser
bei der Analyse der Präsentationsschicht eine entsprechend hohe Beachtung geschenkt
werden. In der Anforderungsspezifikation wurde festgelegt, dass die Bedienung der Benutzerschnittstellen intuitiv sein muss und so einfach wie möglich gehalten werden soll. Diese
Bedingungen sprechen für einen simplen und allgemein bekannten Aufbau der Interfaces
und ein „Look & Feel“, dass dem Benutzer von Beginn weg vertraut ist. Im nachfolgenden
Kapitel wird beschrieben wie dieses Layout definiert ist.
2.3.4.1 Aufbau und Layout
Um das Layout und die Farbkonzepte mit den Stakeholdern diskutieren zu können, wurde
ein Prototyp für die Benutzerinterfaces des Berufsbildners und des Lernenden erstellt. Da
der Prototyp möglichst unabhängig zu einer späteren Implementierung sein soll, wurde er
nicht in einem Webdesign-Tool sondern der Einfachheit halber in MS Excel erstellt. Im Prototyp wurden die Farbzusammenstellungen, die Platzierung der Elemente und die wichtigsten
Masse (in Pixel) festgelegt (siehe Abbildung 16).
627 Pixel
128 Pixel
5 Pixel
33 Px
berfsbildungscenter.ch
GradeBook
Postion: link1 >> link2 >> link3
Navigation
Menupunkt1
Infobalken (eingeblendet z.B. wenn Monatsabschluss fällig)
Menupunkt2
min. 460 Pixel (abhängig vom Inhalt)
Menupunkt3
Titel des Seiteninhalts (z.B. Semester Nummer xy)
Logout
Seiteninhalt (z.B. Semester-Übersichts-Tabelle)
Abbildung 16: Prototyp Webseiten-Layout
Die Ausmasse des Benutzerinterfaces wurden so gewählt dass die Anzeige auch mit einer
kleinen Bildschirmauflösung von 800x600 Pixeln noch ohne horizontales Scrollen möglich ist
(für die gängigen Browser müssen auch der Fensterrand und die vertikalen Scroll-Balken mit
einkalkuliert werden).
Remo Seiler, MAS-07-02
Seite 37 von 124
Bei der Farbzusammenstellung für die Webseite wurde darauf geachtet ein möglichst einheitliches Konzept zu definieren, dass aus blau- und grau-Tönen besteht. Behilflich war dabei auch das Online-Tool „kuler“ von Adobe [net12]. Farblich etwas aus dem Rahmen fällt
der rote Hintergrund des Info-Balkens. Dies wurde aber bewusst so gewählt um eine gewisse Signalwirkung zu erzielen. Die gewählten Hintergrundfarben sind in Tabelle 8 mit den zugehörigen RGB-Werten (dezimal) aufgeführt.
Rot
Grün
Blau
Hintergrund Gesamtseite
49
49
49
Hintergrund Menu-Container
123
125
140
Hintergrund Menu-Spalte
79
129
189
Hintergrund Titel-Zeile
184
204
228
Hintergrund Inhalt
247
243
255
Hintergrund Info-Balken
255
0
0
Tabelle 8: Hintergrundfarben GradeBook
Gemäss dem CD des Berufsbildungscenters ist die Schriftart Arial für alle öffentlichen Auftritte Pflicht. Dementsprechend wurde diese Schriftart gewählt. Die einzelnen Schriftdekorationen und Schriftgrössen können hier noch nicht festgelegt werden, da sie stark vom einsatzort im Benutzerinterface abhängig sind. Die wichtigsten Schriftarten wurden aber bereits definiert und sind in Tabelle 9 ersichtlich.
Rot
Grün
Blau
Schriftfarbe dunkler Hintergrund
255
255
255
Schriftfarbe heller Hintergrund
0
0
0
Schriftfarbe Hyperlink
0
0
255
Schriftfarbe Hyperlink Hoover
0
153
153
Tabelle 9: Schriftfarben GradeBook
2.3.4.2 Layout mit Cascading Style Sheets
Das Gesamte Layout der Webseite soll mittels CSS aufgebaut werden und nicht mit blinden
Tabellen wie das früher üblich war oder wie dies häufig noch von Wysiwyg-Editoren umgesetzt wird. Ein CSS-Layout ist robuster, wartbarer, moderner und ermöglicht einfache Erweiterungen für andere Darstellungsarten wie zum Beispiel mobile Browser (für Mobiltelefone).
Die einzigen Bereiche, die der Einfachheit halber noch mit blinden Tabellen positioniert werden, sind Eingabe-Formulare.
Für die Verschiedenen Webseiten von GradeBook mit unterschiedlichen Layouts, müssen
nun also die folgenden Stylesheets erzeugt werden:
login.css für die Startseite
layout.css für die Benutzerinterfaces des Berufsbildners und des Lernenden
nlAbonnement.css für die Newsletter-Antrags-Seiten
email.css für Alle HTML-Email-Inhalte
Remo Seiler, MAS-07-02
Seite 38 von 124
Zudem wird noch ein Stylesheet tabellen.css erstellt, das für die Datentabellen in den
verschiedenen Benutzerinterfaces verantwortlich ist.
Am Beispiel der Benutzerinterfaces für Berufsbildner und Lernender soll nun der Prinzipielle
Aufbau des Layouts verdeutlicht werden (Stylesheet layout.css). Die grobe Struktur wird
mittels HTML-div-Container-Elementen realisiert. Da die einzelnen Struktur-Elemente nur
einmal pro Seite vorkommen, werden für die Identifikation die id- und nicht die KlassenAttribute verwendet. In Abbildung 17 sind die wichtigsten div-Container mit ihrer Position und
Bezeichnung dargestellt.
div id=logoleft
div id=logotop
berfsbildungscenter.ch
div id=topbar
div id=infobar
div id=content
div id=sidebar
div id=menucontainer
div id=container
Abbildung 17: Layout der Webseiten mittels HTML-div-Container
Ein Problem, dass das Layout mit Cascading Style Sheets mit sich bringt ist, dass die Unterschiedlichen Browser den CSS-Standard nicht alle komplett umsetzen oder unterschiedlich
interpretieren. Die Browser mit den grössten Differenzen zum Standard sind die Versionen
des MS Internet-Explorers bis und mit Version 7 (Version 8 ist besser geworden). Da diese
Browser gleichzeitig aber auch die am weitesten verbreiteten sind, muss bei der Codierung
der CSS-Files speziell darauf geachtet werden.
Erste Tests und umfangreiche Internet-Recherchen haben ausserdem ergeben, dass zwei
Div-Spalten die nebeneinander angeordnet werden (mittels float=left oder ähnlich) bei dynamischer Höhe (inhaltsabhängig) Probleme bereiten. Es ist leider mit dem aktuellen CSSStandard nicht möglich, für beide Spalten die gleiche Höhe zu erreichen wenn sich die Höhe
einer der beiden ändert (auch nicht wenn sie im gleichen Container untergebracht sind und
die Höhe als 100% angegeben wird). Um das geplante Layout trotzdem umsetzen zu könRemo Seiler, MAS-07-02
Seite 39 von 124
nen, wird ein einfacher Trick angewendet: Eine kleine Graphik (balken1.gif) welche die
gesamte Breite der beiden Spalten abdeckt, wird als Hintergrund des übergeordneten Containers verwendet und in diesem über die gesamte Höhe wiederholt. So entsteht der Eindruck von zwei Spalten und die Höhe der beiden echten Spalten spielt keine Rolle mehr (die
höhere der Beiden bestimmt die gesamte Höhe).
Für die Analyse und später auch für die Entwicklung der Stylesheets ist die Quelle [net13] als
Referenz sehr zu empfehlen. Viele Beispiele und Informationen finden sich auch unter
[net14].
2.3.4.3 Templates
Durch die Beschreibungen des vorangehenden Kapitels fällt auf, dass die Benutzerinterfaces
des Berufsbildners und des Lernenden vom Aufbau her identisch sind. Da für beide Benutzer
verschiedene Seiten vorgesehen sind, stellt sich die Frage, ob jeweils für jede Seite ein
View-File mit dem kompletten Strukturellen Inhalt notwendig ist.
Um dies zu optimieren und Redundanzen zu vermeiden wurde eine open source TemplateLibrary zu CodeIgniter evaluiert. Mit dieser können Master-Templates erstellt werden und für
die jeweiligen Bereiche einzelne View-Files.
Nachfolgend die beiden in GradeBook benötigten Templates:
template.php -> Master-Template für alle Seiten der Benutzer Berufsbildner und
Lernender.
template_nl.php -> Master-Template für alle Seiten im Zusammenhang mit dem
Newsletter-Anfrage-Vorgang
Für die Benutzer Lernender und Berufsbildner werden ausserdem die Menu-View-Files (menu_berufsbildner_view.php, menu_lernender_view.php) standardmässig in die Templates
geladen, da sie nicht dynamisch angepasst werden müssen.
2.3.4.4 Navigation und View-Files
In den Zustandsdiagrammen der nachfolgenden Kapitel wird analog zu den HMIBeschreibungen der Anforderungsspezifikation [dok2] die Navigation auf den Internetseiten
von GradeBook dargestellt. Die kleinen Änderungen zur ursprünglichen Spezifikation die sich
während der Designphase aufgedrängt haben, sind in den Diagrammen mit entsprechenden
Kommentaren versehen. Änderungen haben sich allgemein aber vor allem bei den Darstellungen von Fehlermeldungen in Formularen ergeben. Diese werden nicht wie ursprünglich
geplant auf einer jeweils neuen Seite dargestellt, sondern direkt im entsprechenden Formular
und zu den jeweiligen Feldern. Das Formular wird dazu jeweils mit den bereits eingegebenen
Daten neu geladen und ergänzt mit einer rot dargestellten Fehlermeldung.
Zu bemerken gilt auch, dass die dargestellten View-Files teilweise komplette HTML-Seiten
repräsentieren und teilweise nur Bereiche einer solchen, falls für die entsprechende Seite ein
Master-Template vorhanden ist (siehe auch Kapitel 2.3.4.3).
Das Laden und Übermitteln der View-Files zum aufrufenden Browser, übernehmen die dafür
verantwortlichen Controller-Methoden (siehe Kapitel 2.3.2). Letztere werden entweder durch
anklicken eines entsprechenden Links in der HTML-Seite aufgerufen oder durch einen vom
Server ausgelösten HTTP redirect (Umleitung via URL zu einer neuen Controller-Methode).
Remo Seiler, MAS-07-02
Seite 40 von 124
2.3.4.4.1 Navigation Login
Die Startseite mit dem Login-Formular (gelb hinterlegt) wird beim Aufruf von GradeBook als
erstes geladen. Von dieser Seite aus kann sich ein Benutzer mit Benutzername und Passwort einloggen und gelangt anschliessend je nach Benutzergruppe (Lernender oder Berufsbildner) auf die entsprechende Startseite seines GradeBook-Accounts.
Wenn eine beliebige Person einen Newsletter zu einem Lernenden abonnieren möchte, kann
sie dies ebenfalls von der Login-Seite aus tun, indem Sie den Link „Newsletter abonnieren“
wählt und dann durch den darauf folgenden Anfragevorgang navigiert.
Abbildung 18: Navigation Login und Newsletter-Abonnement anfragen
2.3.4.4.2 Navigation Lernender
Sobald sich ein Lernender eingeloggt hat, gelangt er zur Semesterübersicht, der Startseite
seines Accounts (gelb hinterlegt). Auf dieser Seite kann der Lernende zwischen den einzelnen Semestern vor- und zurück-navigieren, was ein erneutes Laden der Semesterübersicht
mit dem neu gewählten Semester zur Folge hat. Zudem kann der Lernende „Semester bearbeiten“ wählen um auf die Bearbeitungs-Seite des jeweils angezeigten Semesters zu gelangen und diesem dort Fächer hinzuzufügen oder solche zu entfernen.
Remo Seiler, MAS-07-02
Seite 41 von 124
Falls der Lernende in der Semesterübersicht auf den Namen eines Fachs klickt (diese sind
Navigations-Links) gelangt er in die Notenübersicht zum entsprechenden Fach, wo er Noten
eingeben, bearbeiten und entfernen kann.
Auf der Semesterübersichtsseite wird falls der aktuelle Monatsabschluss fällig ist ein rot hinterlegter Informations-Balken angezeigt (monatsabschluss_info_view.php). Durch klicken auf den Button „Monat abschliessen…“ in diesem Balken gelangt der Lernende auf das
entsprechende Monatsabschluss-Formular. Hinweis: Auf letzteres kann nur in diesem Zusammenhang navigiert werden.
Einen Bericht als PDF-File kann der Lernende erstellen, indem er auf den entsprechenden
Link im Navigationsmenu klickt. Der Bericht wird nicht wie in der Anforderungsspezifikation
[dok2] geplant in einem neuen Browserfenster geöffnet, sondern zum Download angeboten.
Dies ist sinnvoller, da dies für den Benutzer einfacher nachvollziehbar ist durch die mögliche
Auswahl von Speichern oder Öffnen. Klickt der Benutzer im Download-Fenster des Browsers
auf „Öffnen“, führt dies ausserdem zu einem vergleichbare Resultat wie das geforderte.
Abbildung 19: Navigation Benutzerinterface Lernender
2.3.4.4.3 Navigation Berufsbildner
Sobald sich ein Berufsbildner eingeloggt hat, gelangt er zu Übersicht über die ihm zugeteilten Lernenden. Auf dieser Seite hat der Berufsbildner die Möglichkeit „Meine Lernende Bearbeiten…“ zu wählen und gelangt so auf eine Bearbeitungsseite, auf der er sich Lernende
zuteilen oder bereits zugeteilte wieder entfernen kann. Eine kleine Änderung gegenüber der
Remo Seiler, MAS-07-02
Seite 42 von 124
Anforderungsspezifikation ist hier noch, dass die jeweiligen Änderungen nicht erst bei einer
Bestätigung gespeichert werden, sondern direkt nach jeder Zuteilung oder Entfernung. Dies
macht mehr Sinn, da mit einer Änderung ja keine Daten verloren gehen können (Die Lernenden können z.B. nach einem Entfernen ohne Datenverlust auch wieder hinzugefügt werden).
Falls der Berufsbildner in der Lernender-Übersicht auf den Namen eines Lernenden klickt,
gelangt er in die Detail-Ansicht dieses Lernenden. Auf dieser Seite kann er Detaillierte Informationen zum Lernenden abrufen (Semesterübersichten, persönliche Daten, Statusinformationen, …), einen Bericht zum Lernenden in PDF-Form erstellen oder die NewsletterAbonnemente des Lernenden verwalten.
Der Berufsbildner hat ausserdem die Möglichkeit im Navigationsmenu verschiedene Punkte
zu wählen. Mit „Newsletter-Anfragen“ gelangt er in die Übersicht aller offenen NewsletterAnfragen zu den ihm zugeteilten Lernenden. Mit „Newsletter-Empfänger“ gelangt er auf die
Übersicht über alle im System erfassten Newsletter-Empfänger und kann dort neue Empfänger erfassen und solche löschen oder bearbeiten.
Abbildung 20: Navigation Benutzerinterface Berufsbildner
Remo Seiler, MAS-07-02
Seite 43 von 124
2.4
Dynamische Analyse
Für die Interaktions-Analyse der Klassen-Struktur wurden verschiedene Sequenzdiagramme
erstellt. Sie dienen hauptsächlich dazu, die Interaktion zwischen Controller und Model darzustellen und verdeutlichen, welche Daten zu welchem Zeitpunkt ermittelt werden müssen. In
den Sequenzdiagrammen kommen auch einige deskriptive Stereotypen zum Einsatz um die
Spezialitäten einer Webapplikation zu verdeutlichen. So wurde zum Beispiel die Kommunikation zwischen Client (Benutzer, Lernender, Berufsbildner) und dem jeweiligen Controller auf
dem Server mit <<HTTP request>>, <<HTTP response>> und <<HTTP redirect>> genauer
spezifiziert. So kann verdeutlicht werden, wie die Interaktion mit dem System mittels HTTPProtokoll geschieht. Es gilt noch zu bemerken, dass die Rückgaben der einzelnen Methoden
der Übersicht halber auf den Antwort-Pfeilen dargestellt wurden und nicht bereits beim Methodenaufruf.
Die nachfolgenden Kapitel beinhalten die Sequenzdiagramme für die wichtigsten Abläufe in
GradeBook. Einige Diagramm mit ähnlicher Struktur werden der Übersichtlichkeit halber
nicht aufgeführt.
2.4.1
Login (alle Benutzer)
Das Sequenzdiagramm in Abbildung 21 zeigt den Ablauf des Authentifizierungsvorgangs
eines beliebigen Benutzers.
Abbildung 21: Sequenzdiagramm Login
Remo Seiler, MAS-07-02
Seite 44 von 124
2.4.2
Semesterübersicht (Lernender)
Sobald sich ein Lernender erfolgreich am System angemeldet hat, gelangt er zur Semesterübersicht. Diese kann aber auch im späteren Programmverlauf durch Auswahl der entsprechenden Links aufgerufen werden. Die Auswahl eines Semesters im Sequenzdiagramm
ebenfalls enthalten, dieser geschieht durch die Übergabe einer entsprechenden Semesternummer an die Methode semesterUebersicht(), was wiederum durch einen entsprechenden Link einer HTML-Seite realisiert wird. Falls eine ungültige Semesternummer (resp.
z.B. der Wert 0) übergeben wird, wird das aktuelle Semester des Lernenden ermittelt und
dieses ausgegeben.
Das Sequenzdiagramm in Abbildung 22 zeigt nun den chronologischen Ablauf für die Ermittlung aller für die Semesterübersicht benötigten Daten. Die Umsetzung der Daten in Entsprechende HTML-Tabellen wird hier nicht dargestellt. Letzteres geschieht aber ebenfalls in der
Methode semesterUebersicht():
Abbildung 22: Sequenzdiagramm Semesterübersicht (Lernender)
Remo Seiler, MAS-07-02
Seite 45 von 124
2.4.3
Semester bearbeiten (Lernender)
Der Lernende kann ein in der Semesterübersicht angezeigtes Semester bearbeiten. Dazu
klickt er auf den Button „Semester bearbeiten…“ was die Methode semesterBearbeiten() des
Controllers Lernender aufruft. Diese Methode ermittelt alle Daten für das Bearbeitungsformular, generiert dieses und sendet es an den Browser zurück. Für die Datenermittlung wird aus
Sicherheitsgründen nicht die Semester-ID oder Semester-Nummer an die Methode übergeben (via URL) sondern die entsprechenden Daten zuvor in den Session-Daten abgelegt. Zu
Beginn des in Abbildung 23 dargestellten Ablaufs wird dann die Semesternummer aus den
Session-Daten (der Datenbank) ausgelesen und anschliessend alle weiteren, notwenigen
Information.
Abbildung 23: Sequenzdiagramm Formular Semester bearbeiten laden
Nachdem das Bearbeitungsformular angezeigt wurde, kann der Lernende aus zwei Listen
ein oder mehrere Fächer auswählen und das Formular mittels der Buttons hinzufügen („>“)
oder entfernen („<“) absenden. Auch hier wurden aus Sicherheitsgründen keine Identifikationsnummern von Fächern in den Listen des HTML-Formulars abgelegt. Die Listen beinhalten Nummern, welche einer Fach-id entsprechen. Die Zuordnungen dieser Nummern ist in
den Session-Daten (also in der Datenbank) abgelegt und für den Benutzer nicht zugänglich.
Der Benutzer hat somit keine Möglichkeit, die Fach-IDs beliebig zu ändern, indem er beispielsweise die Formulardaten oder die URL ändert. So ist sichergestellt, dass dem Semester nur die Fächer hinzugefügt werden können, welche für den Lernenden vorgesehen sind
und nur solche entfernt werden können, die auch wirklich dem Semester zugeordnet sind.
Das Sequenzdiagramm in Abbildung 24 zeigt den Ablauf einer Bearbeitung (hinzufügen oder
löschen von Fächern).
Remo Seiler, MAS-07-02
Seite 46 von 124
Abbildung 24: Sequenzdiagramm Fächer hinzufügen/entfernen
Remo Seiler, MAS-07-02
Seite 47 von 124
2.4.4
Note eingeben oder bearbeiten (Lernender)
Die Eingabe oder Bearbeitung einer Note ist für den Benutzer Lernender einer der wichtigsten Abläufe. Grundsätzlich funktioniert der gesamte Ablauf ähnlich wie der Ablauf einer Semester-Bearbeitung. Nachdem ein Lernender in der Semesterübersicht ein Fach auswählt
(klicken auf den Fachnamen) wird vorerst eine Übersicht aller Noten zu einem gewählten
Fach angezeigt und aus dieser dann die Bearbeitung gestartet.
Für die Anzeige der Notenübersicht muss der Controllermethode notenUebersicht() das
Fach übergeben werden, zu welchem die Noten angezeigt werden sollen. Auch hier wurden
aus Sicherheitsgründen nur Fachnummern verwendet, die zuvor in der Semesterübersicht
definiert wurden und eine entsprechende Zuordnungstabelle in den Session-Daten aufweisen. Falls der Benutzer trotzdem versucht über die URL ein Fach auszuwählen, dass nicht
seinem Semester zugeteilt wurde, wird er wieder zur Semesterübersicht umgeleitet. Falls
des gültig ist, müssen alle Informationen zum Fach zu den erfassten Noten und zum Notenschnitt aus den Models gelesen werden. Anschliessend generiert die Methode notenUebersicht() die entsprechende View mit einer Notentabelle inkl. Bearbeitungs- und LöschSymbolen und sendet diese an den Browser zurück.
Der gesamte Ablauf ist in Abbildung 25 dargestellt.
Abbildung 25: Sequenzdiagramm Notenübersicht anzeigen
Remo Seiler, MAS-07-02
Seite 48 von 124
Wenn einem Benutzer die Notenübersicht angezeigt wird, kann er auf dieser eine neue Note
erfassen oder eine bereits bestehende bearbeiten. Da die Bearbeitung einer Note im selben
Formular erfolgt wie die Erfassung einer neuen, wird zuerst der Ablauf einer Bearbeitung
beschrieben.
Abbildung 26: Sequenzdiagramm Note bearbeiten
Wie im Sequenzdiagramm (Abbildung 26) ersichtlich, wird auch hier das Prinzip einer Notennummer mit zugehöriger Noten-id in den Session-Daten verwendet (siehe dazu auch Kapitel 2.4.3). Wenn eine gültige Note für die Bearbeitung ausgewählt wurde, werden die entsprechenden Notendaten aus dem Model M_note gelesen und in der Session Flash-Daten
zwischengespeichert. Flash-Daten sind Session-Daten, die nur für den nächsten Serveraufruf gültig sind und anschliessend automatisch gelöscht werden. Somit kann z.B. auch verhindert werden, dass eine Note ein zweites Mal gespeichert wird, falls mittels Zurück-Button
erneut auf das Noteneingabe-Formular navigiert wird.
Nachdem die alte Note in den Session-Daten abgelegt wurde, wird die Controllermethode
noteEingeben() aufgerufen. Letzteres ist auch der Fall, wenn auf der Notenübersicht der
Button „Note hinzufügen…“ gewählt wird.
Das Aufrufen der Controllermethode noteEingeben() führt zum Ablauf der im Sequenzdiagramm in Abbildung 27 dargestellt ist.
Hinweis: die Methode noteEingeben()wird bei jedem Absenden des Formulars in der Notenübersicht aufgerufen und dementsprechend auch wenn der Button „Zurück“ gewählt wird.
Deshalb ist diese Zurück-Funktion im nachfolgenden Sequenzdiagramm ebenfalls enthalten.
Im Sequenzdiagramm ist ersichtlich, dass zuerst überprüft wird, ob eine neue Note eingegeben oder eine alte bearbeitet werden soll. Definiert wird dies durch den Übergabeparameter
$edit. Wenn für Letzteren der Wert true übergeben wird, werden die Notendaten aus den
Session-Daten gelesen. Falls diese nicht vorhanden sein sollten (Fehlerhafter Aufruf des
Remo Seiler, MAS-07-02
Seite 49 von 124
Eingabeformulars, nicht erwünschte Aktualisierung durch den Browser oder ähnlich) erfolgt
aus Sicherheitsgründen eine Umleitung zurück zur Notenübersicht.
Nach der Prüfung und nach dem eventuellen Lesen der alten Notendaten aus der Session,
wird das Eingabeformular erzeugt. Dazu müssen vorerst die Informationen zum Benutzer
und zum Fach ermittelt (wiederum aus den Session-Daten) und anschliessend die Informationen zu Notentypen und zu Notengewichten aus der Datenbank gelesen werden. Die Notentypen und Notengewichte werden benötigt um die entsprechenden Auswahlfelder zu generieren und die Informationen zum Benutzer und zum Fach für die Erzeugung der Hinweise im
Formular („Geben Sie eine Note für das Fach X, Semester Y (Institut Z) ein:“).
Das Sequenzdiagramm in Abbildung 27 zeigt den beschriebenen Ablauf.
Abbildung 27: Sequenzdiagramm Formular Note eingeben
Remo Seiler, MAS-07-02
Seite 50 von 124
Nachdem das Notenformular generiert und angezeigt wurde, kann der Benutzer die Notendaten eingeben (resp. Ändern) und mit betätigen des „Speichern“-Buttons absenden. Nach
dem Absenden wird die Controllermethode noteVerarbeiten() aufgerufen welche die
eingegebenen Daten prüft und bei Gültigkeit mit dem Model M_note speichert. Falls die Notendaten nicht gültig sind, wird erneut die Methode noteEingeben() aufgerufen und das
Formular mit den bereits eingegebenen Daten und einer entsprechenden Fehlermeldung neu
angezeigt.
Ein Sequenzdiagramm dieses Vorgangs und des Vorgangs „Note löschen“ wird hier nicht
aufgeführt, weil die entsprechenden Abläufe relativ simpel sind und auch in der SourceCode-Dokumentation einfach nachvollziehbar sein sollten. Ausserdem soll der Umfang des
Abschlussberichtes nicht unnötig überladen werden.
2.4.5
Monatsabschluss und Noten-Newsletter (Lernender)
Jeder Lernende der GradeBook einsetzt, muss jeweils ende Monat einen Monatsabschluss
tätigen, mit dem er bestätigt, dass er alle Noten eingetragen hat oder im aktuellen Monat
keine Noten erhalten hat. Falls ein Monatsabschluss fällig ist, wird dies in der Semesterübersicht mit einem roten Info-Balken angezeigt. Die Anzeige dieses Balkens ist also Teil der
Semesterübersicht, weswegen im Sequenzdiagramm in Abbildung 28 auch auf diese verwiesen wird (Referenz Semesterübersicht).
Falls der Lernende in dem genannten Info-Balken den Button „Monat abschliessen“ betätigt,
wird der folgende Ablauf injiziert:
Abbildung 28: Sequenzdiagramm Formular Monatsabschluss
Es wird ein Formular für den Monatsabschluss erzeugt, für das verschiedene Daten wie zum
Beispiel die Newsletter-Empfänger des Lernenden benötigt werden (siehe Abbildung 28).
Remo Seiler, MAS-07-02
Seite 51 von 124
Wenn der Lernende das Formular absendet erfolgt der Ablauf wie er im Sequenzdiagramm
(Abbildung 29) dargestellt ist. Als erstes wird überprüft, ob der Monatsabschluss überhaupt
fällig ist (Sicherheitsmassnahme). Wenn dem so ist und im Formular eine Auswahl getroffen
wurde (Noten eingegeben/keine erhalten), wird der Monatsabschluss mit dem Model
M_lernender gesetzt (in der Datenbank gespeichert). Anschliessend werden zum Lernenden ein Bericht erzeugt (PDF-Datei), für alle seine Newsletter-Empfänger ein Email generiert
(mit dem Bericht als Anhang) und diese Mails versendet.
Wie der Controller Lernender und die verwendeten Models in diesem Ablauf interagieren, ist
im Sequenzdiagramm in Abbildung 29 dargestellt.
Abbildung 29: Sequenzdiagramm Monatsabschluss und Noten-Newsletter
Remo Seiler, MAS-07-02
Seite 52 von 124
2.4.6
Details Lernender anzeigen (Berufsbildner)
Da die Abläufe für den Benutzer Berufsbildner in vielen Bereichen denen des Lernenden
ähnlich sind (Beispiel Semester bearbeiten <-> Lernende Bearbeiten), wird an dieser Stelle
exemplarisch nur der Ablauf „Details Lernender anzeigen“ beschrieben.
Falls ein Berufsbildner in der Lernenden-Übersicht auf den Namen eines Lernenden klickt,
wird folgender Ablauf angestossen:
Abbildung 30: Sequenzdiagramm Details Lernender
Im Unterschied zu Lernenden wird der Benutzer Berufsbildner als geringeres Risiko für Angriffe betrachtet. Das führt dazu, dass einige Abläufe etwas vereinfacht werden könne, da
Identifikationsnummern (z.B. des Lernenden) direkt in den HTML-Formularen und Links festgelegt werden können. Somit entfällt das umständliche und Ressourcen-intensive Zwischenspeichern von Zuordnungstabellen in den Session-Daten.
Wie im Sequenzdiagramm dargestellt, werden für die Anzeige von Detailinformationen zu
einem lernenden viele unterschiedliche Informationen aus der Datenbank gelesen. Zu diesem Zweck werden verschiedene Models verwendet, die auch für die Controller des Lernenden zum Einsatz kommen. Zu bemerken gilt es hier noch, dass für die Abfragen im Zusammenhang mit der Semesterübersicht des Lernenden eine Untersequenz eingefügt wurde, da
dieser Ablauf demjenigen der Semesterübersicht entspricht (siehe dazu Kapitel 2.4.2).
Remo Seiler, MAS-07-02
Seite 53 von 124
2.4.7
Newsletter beantragen (beliebige Person)
Auch für das Beantragen eines Noten-Newsletter durch eine beliebige Person soll hier nur
exemplarisch ein Ablauf dargestellt werden.
Das Sequenzdiagramm in Abbildung 31 zeigt das Verhalten des Systems nachdem eine beliebige Person auf der GradeBook-Loginseite den Link „Newsletter abonnieren“ wählt. Wenn
die genannte Aktion stattfindet, wird die index()-Methode des Controllers NewsletterAnfrage aufgerufen. Diese ruft die Controller-Methode emailEingabe() auf welche ein entsprechendes Eingabeformular an den Browser sendet. Im dargestellten Ablauf ist zudem ersichtlich, wie die Arbeit mit einem Formular und das erneute Anzeigen desselben bei ungültigen
Eingaben funktioniert. Falls nämlich der Benutzer das Formular absendet, wird die Methode
emaileingabeBestaetigen() aufgerufen. Diese validiert die Eingaben und ruft im Fehlerfall erneut die Controllermethode emailEingabe() auf (es erfolgt also keine Umleitung
mit http redirect). Im Erfolgsfall wird geprüft ob der Newsletter-Empfänger bereits vorhanden
ist oder nicht und je nach dem auf das Registrierungsformular oder das Auswahlformular für
Lernende umgeleitet.
Abbildung 31: Sequenzdiagramm Email Eingabe
Remo Seiler, MAS-07-02
Seite 54 von 124
2.5
Datenbank
Zur Analyse der Datenbankstruktur wurden vorerst die Geschäftsdaten analysiert und sind
im entsprechenden Klassendiagramm (Geschäftsdatenmodell) in Kapitel 2.5.1 dokumentiert.
Die Abbildung der Klassen in die Tabellen resp. in das Relationen-Modell sind im Kapitel
2.5.2 zu finden. Die Analysierten Inhalte beziehen sich grösstenteils auf die für die Implementierung von GradeBook Release 1 notwendigen Datenstrukturen. Einige Details wurden
aber bereits im Datenbankschema vorgesehen obschon sie im Release 1 noch nicht zum
Einsatz kommen. Dies, weil der nachträgliche Einbau dieser Elemente unter Umständen
grössere strukturelle Änderungen der Datenbank nach sich ziehen würde und die spätere
Verwendung der Elemente bei der Programmierung an verschiedenen Stellen bereits beachtet werden muss.
2.5.1
Geschäftsdatenmodell
Das Geschäftsdatenmodell in Abbildung 32 zeigt welche Daten für die Applikation GradeBook verarbeitet werden müssen und wie sie zueinander in Beziehung stehen. Im Modell
werden zwei Stereotypen verwendet. Zum einen die business-Klassen, welche die zu speichernden Daten repräsentieren und zum anderen die „business constants“, die für Konstant
erfasste Daten wie Berufsgruppen oder Fächer stehen. Die „business constant“-Daten werden mittels Skripts oder DB-Tools direkt in die Datenbank geladen und können vom späteren
Benutzer nicht verändert werden. Falls in GradeBook Release 2 Benutzerinterfaces für die
Veränderung vorerst konstanter Daten erstellt werden (z.B. Fächer festlegen durch Berufsbildner) ändert sich das hier dargestellte Geschäftsdatenmodell dementsprechend.
class Business
«business»
New sletter -Empfänger
1
«business constant»
InstitutX, InstitutY, ...
macht
+
+
+
+
+
+
+
+
+
Email: TEXT
Name: TEXT
Vorname: TEXT
Firma: TEXT
Adresse: TEXT
TelefonG : TEXT
TelefonP : TEXT
TelefonM : TEXT
Bemerkung en: TEXT
«business»
Benutzer
hat
«business constant»
Benutze rgruppe
1
0..*
«business»
New sletter Abonnement
+
+
ipAdresse: TEXT
ZeitDatum: DATETIME
«business»
Institution
«business constant»
GruppeX, Gr uppeY, ...
0..*
«business»
New slette r-Anfrage
1
0..*
+
ZeitDatum: DATETIME
ist in
ist für
ist für
+
+
+
+
+
+
+
+
+
+
Benutzerna me: TEXT
Email-Adre sse: TEXT
Name: TEXT
Vorname: TEXT
Firma: TEXT
Adresse: TEXT
TelefonG : TEXT
TelefonP : TEXT
TelefonM : TEXT
LetzterLogin : DATETIME
ist ein
0..*
ist ein
gehört zu
1
0..*
0..*
«business»
Fa ch
«business»
Seme ster
hat
0..*
«business»
Lerne nder
hat
Semetsernummer: int 8
0..* -
1
0..* +
gehört zu
1
0..*
0..*
Note: DOUBLE
Gewicht: DOUBLE
Typ: TEXT
Erfassungszeitp unkt: DATETIME
ist ein
0..*
«business»
Note
+
+
+
-
0..*
macht
gehört zu
0..*
«business constant»
FachX, Fa chY, ...
0..*
Lehrstart: YEAR
1
«business»
Berufsbildner
ist zuge teilt zu
gehört zu
gehört zu
«business»
Monatsabschluss
+
+
+
+
«business»
DefaultBer ufsbildner
ZeitDatum: DATETIME
Monat: DATETIME
Jahr: DATETIME
NotenErhalte n: BOOLEAN
1
1
gehört zu
«business constant»
Inform atiker
1
«business»
Berufs gruppe
«business constant»
Elektr oniker
«business constant»
Kauffrau - Kaufmann
Abbildung 32: Geschäftsdatenmodell
Remo Seiler, MAS-07-02
Seite 55 von 124
Die meisten Tabellen der Datenbank enthalten Identifikationsnummern als Primärschlüssel,
diese sind im Geschäftsdatenmodell nicht dargestellt.
Alle in diesem Diagramm dargestellten „1 zu n“ - Assoziationen können ohne strukturelle
Anpassungen direkt auf Tabellen des Relationen-Modells abgebildet werden. Für die „n zu
m“-Assoziationen müssen hingegen Verknüpfungstabellen erstellt werden (um mindestens
die 3. Normalform zu erreichen).
An dieser Stelle sei bereits darauf hingewiesen, dass die Benutzer und die NewsletterEmpfänger grösstenteils identische Spalten aufweisen aber aus Performance- und Logikgründen (Applikationssicht) in der Datenbank separat gehalten werden.
Nachfolgend werden die einzelnen Klassen des Geschäftsdatenmodells kurz beschrieben:
Benutzer
Enthält alle persönlichen Informationen eines Benutzers die aus
dem ADS gelesen werden können. Einige Zusätzliche Inhalte
die nicht im ADS erfasst sind, sind ebenfalls enthalten und werden erst im Release 2 von GradeBook zum Einsatz kommen.
Datum und Zeit des letzten Logins eines Benutzers werden direkt beim Benutzer gespeichert.
Benutzergruppe
Beinhaltet die Benutzergruppe welche auch die grundsätzlichen
Benutzerrechte festlegt (Lernender, Berufsbildner, DefaultBerufsbildner, …).
Lernender
Der Lernende ist ein Benutzer. Zum Lernenden wird das Lehrstartjahr erfasst und eine Zuteilung zu seiner Berufsgruppe gespeichert. Der Lernende hat Semester mit Fächern und Noten
und macht Monatsabschlüsse.
Berufsbildner
Der Berufsbildner ist ebenfalls ein Benutzer. Ihm sind Lernende
zugeteilt und er selbst ist einer Berufsgruppe zugeteilt.
Default Berufsbildner
Der DefaultBerufsbildner ist ein spezieller Berufsbildner. Er hat
eine fixe Identifikationsnummer und ihm werden alle neu erfassten Lernenden standardmässig zugeteilt.
Berufsgruppe
Die Berufsgruppe beinhaltet die Konstanten für einzelne Berufe
(Elektroniker, Informatiker, Kauffrau-Kaufmann, evtl. weitere).
Newsletter-Empfänger
Enthält Daten zu einem Newsletter-Empfänger. Obschon die
Daten grösstenteils identisch zu den Benutzerdaten sind, ist aus
Applikationssicht effizienter den NL-Empfänger separat abzulegen. Ein Benutzer kann zwar auch ein NL-Empfänger werden,
ein NL-Empfänger ist aber nicht zwingend ein Benutzer des
Systems (er hat keinen ADS-Account).
Newsletter-Abonnement
Ist eine Zuteilung eines Newsletter-Empfängers zu einem Lernenden (Abonnement) und enthält auch den Erfassungszeitpunkt des Abonnements.
Newsletter-Anfrage
Ist eine Zuteilung eines Newsletter-Empfängers zu einem Lernenden (Anfrage) und enthält auch den Anfragezeitpunkt und
Remo Seiler, MAS-07-02
Seite 56 von 124
die IP-Adresse von der die Anfrage getätigt wurde.
Semester
Jeder Lernende hat 8 Semester mit einer entsprechenden Semesternummer zu welchen er Fächer hinzufügt.
Fach
Jedem Semester werden Fächer zugeordnet. Die Fächer sind
konstant in der Datenbank erfasst und sind einer Institution zugeordnet.
Institution
Die Institutionen sind die konstant erfassten notengebenden
Institutionen (BBC, BMS, GIBB, Prüfungen, etc.). Institutionen
können auch Lehrabschlussprüfungen sein (diese Noten sind
nicht eindeutig einer Institution zuzuweisen.)
Note
Eine Note ist jeweils einem Fach und einem Semester zugeordnet. Die Note enthält den Notenwert, das Notengewicht, den
Notentyp und den Erfassungszeitpunkt der Note.
Monatsabschluss
Beinhaltet die Informationen zu den getätigten Monatsabschlüssen (Der Monat und das Jahr, ob Noten eingegeben wurden
und den Zeitpunkt des Abschlusses)
2.5.2
Relationen-Modell (ERM)
Die Umsetzung des Geschäftsdatenmodells aus Kapitel 2.5.1 in das Relationen-Modell, wird
in diesem Kapitel beschrieben. Zu beachten ist dabei, dass verschiedene Verknüpfungstabellen notwendig sind um die einzelnen Assoziationen korrekt abzubilden. Zudem sind die
Relationen mit den Spalten für die Identifikationsnummern und die Fremdschlüssel ergänzt.
Einige der künstlichen Primärschlüssel (meist Identifikationsnummern) wurden ins Design
aufgenommen, obschon sie nichts mit der abstrakten Beschreibung der Anwendungsobjekte
zu tun haben. Dies dient einerseits dazu, die Schlüssellänge für Fremdschlüssel zu verringern und andererseits wird so sichergestellt, dass jede Relation (auch die Zuordnungstabellen) einen einzelnen und in keiner Weise von anderen Schlüsselkandidaten funktional abhängigen Primärschlüssel besitzen.
Die verwendeten Tabellen sind allesamt InnoDB-Tabellen, damit Constraints möglich werden
und somit die Kaskadierung von Löschvorgängen nicht in der Software gelöst werden muss.
Die Constraints wurden in diesem Sinne auch umgesetzt sind aber im Diagramm nicht speziell aufgeführt.
Die Datenbank ist mit einigen wenigen Ausnahmen in der 3. Normalform gehalten. Einzig bei
Benutzer und Newsletter-Empfänger wurden hier Ausnahmen gemacht. Beispielsweise
könnten die Adressinformationen noch in weitere Tabellen aufgespalten werden um eine
Redundanz komplett zu vermeiden, dies wurde aber zugunsten einer weniger starken Segmentierung der Datenbank nicht gemacht. Eine zu starke Segmentierung würde die Performance senken und die Applikation unnötig komplizieren.
Um den Zugriff durch die Applikation noch zu vereinfachen, könnten für verschiedene Abfragen Views erstellt werden. Views werden aber erst im 2. Release von GradeBook in Betracht
gezogen.
Ein weiterer Hinweis auf Release 2: Die Assoziation der Fach-Relation zu einem Lernenden
wird benötigt falls Lernende eigene Fächer erstellen können. Da dies noch nicht umgesetzt
Remo Seiler, MAS-07-02
Seite 57 von 124
wurde, fehlt die Assoziation im Diagramm, das entsprechende Attribut (idOwner) ist aber
bereits enthalten und wird auf den Standardwert -1 gesetzt (entspricht Besitzer = Alle). Das
Attribut Aktiv ist ebenfalls noch nicht in Verwendung wird aber für die spätere Aktivierung/Deaktivierung eines selbst erstellten Fachs dienen.
class GradeBook
Im Unterschied
zum Geschäftsdatenmodell wurden im Relationen-Modell das Notengwicht
SessionData
und
der Notentyp nun als eigene Relationen definiert. Das ermöglicht die statische Erfassung
«column»
*PK session_id: VARCHAR(40) = 0
dieser
als V ARCHAR(16)
Konstanten
und vermeidet Redundanz (Normalisierung). Ausserdem muss das
*
ip_address:
=0
*
user_agent: VARCHAR(50)
Notengesicht
nicht
nur als Wert, sondern auch als Text gespeichert werden können.
*
last_activity: INT(10)
=0
*
user_dat a: TEXT
Abbildung 33 zeigt das oben beschriebene Relationen-Modell.
Benutzer
New sletter Empfaenger
«column»
*PK idNLE: INTEGER
*
Email: VARCHAR(50)
*
Anrede: VARCHAR(10)
*
Name: VARCHAR(50)
*
Vorname: VARCHAR(50)
Firma: VARCHAR(50)
Strasse: VARCHAR(50)
PLZ: INTEGER
Ort: VARCHAR(50)
TelefonG: VARCHAR(20)
TelefonP: VARCHAR(20)
TelefonM: VARCHAR(20)
Bemerkung en: TEXT
1
«column»
*PK Benutzername: VARCHAR(50) 0..*
*FK idBenutzergru ppe: TINYINT
*
Email: VARCHAR(50)
*
Name: VARCHAR(50)
*
Vorname: VARCHAR(50)
Firma: VARCHAR(50)
Strasse: VARCHAR(50)
PLZ: INTEGER
Ort: VARCHAR(50)
TelefonG: VARCHAR(20)
1
TelefonP: VARCHAR(20)
TelefonM: VARCHAR(20)
*
LetzterLogin : TIMESTAMP
0..*
New slette rAnfrage
«column»
*PK idAnfrage: INTEGER
*FK idNLE: INTEGER
*FK idLernender: INTEGER
*
ipAdresse: VARCHAR(20)
*
zeitDatum: TIMESTAMP
0..*
1
Berufsbildner
«column»
0..*
0..* *PK idBerufsbildner: INTEGER
*FK Benutzername: VARCHAR(50)
*FK idBerufsgruppe: INTEGER
1
1
0..*
New sletter Abonnement
«column»
*PK idAbonnement: INTEGER
*FK idNLE: INTEGER
*FK idLernender: INTEGER
*
zeitDatum: TIMESTAMP
Benutze rgruppe
«column»
1 *PK idBenutzergru ppe: TINYINT
*
Name: VARCHAR(20)
1
0..*
0..*
Lerne nder
0..*
1
1
ZuteilungBe rufsbildner
«column»
1
*PK idLernender: INTEGER
*FK Benutzername: VARCHAR(50)
*FK idBerufsgruppe: INTEGER
*
Lehrstart: YEAR
1
0..*
«column»
*PK idZuteilungBL: INTEGER
*FK idBerufsbildner: INTEGER
*FK idLernender: INTEGER
0..*
8
Monatsabschluss
1
Seme ster
«column»
*PK idMonatsabschluss: INTEGER
0..*
*FK idLernender: INTEGER
*
Monat: TINYINT
*
Jahr: YEAR
*
NotenErhalten: BOOL
*
ZeitDatum: TIMESTAMP
Berufs gruppe
«column»
*PK idSemester: INTEGER
*FK idLernender: INTEGER
*
Semesternumm er: TINYINT
«column»
*PK idBerufsgruppe: INTEGER
Name: VARCHAR(20)
1
1
0..*
0..*
Fa ch
ZuteilungFa chSemester
«column»
*PK idZuteilungFS: INTEGER
*FK idSemester: INTEGER
*FK idFach: INTEGER
Note ntyp
«column»
*PK idNotentyp : TINYINT
*
Name: VARCHAR(20)
1
1
0..*
1
1
«column»
*PK idFach: INTEGER
*
Name: VARCHAR(200)
*FK idBerufsgruppe: INTEGER
*FK idInstitut: INTEGER
*
idOwner: INTEG ER = -1
*
Aktiv: BOOL = true
0..*
0..*
Note
0..*
Notengew icht
«column»
*PK idNotengewicht: TINYINT
*
Wert: DOUBLE
*
Name: VARCHAR(10)
1
«column»
0..* *PK idNote: INTEGER
*FK idZuteilungFS: INTEGER
*
Wert: DOUBLE
*FK idNotengewicht: TI NYINT = 1
*FK idNotent yp: TINYINT = 1
*
zeitDatum: TIMESTAMP
1
Institution
«column»
*PK idInstitut: INTEGER
*
Name: VARCHAR(20)
Abbildung 33: Relationen-Modell Datenbank
Zusätzlich zu den Geschäftsdaten, werden auch die Daten des Session-Handlings in der
Datenbank abgelegt. Dies weil aus Sicherheitsgründen keine Daten für die Steuerung der
Remo Seiler, MAS-07-02
Seite 58 von 124
Applikation und der Datenzugriffe in einem Cookie abgelegt werden sollen (siehe auch Kapitel 2.2.4).
CodeIgniter stellt wie in Kapitel 2.1.2.2 bereits erwähnt eine eigene Session-Library zur Verfügung. Diese setzt eine spezielle Datenbank-Tabelle voraus und legt auch deren Attribute
explizit fest. In Abbildung 34 ist diese Tabelle dargestellt und ersichtlich, dass diese keine
Assoziationen zu weiteren Tabellen aufweist. Die Serialisierung von Daten (z.B. Arrays) und
Speicherung dieser in der Tabelle, wird komplett von der Session-Library übernommen.
class GradeBook
SessionData
«column»
*PK session_id: VARCHAR(40) = 0
*
ip_address: V ARCHAR(16) = 0
*
user_agent: VARCHAR(50)
*
last_activity: INT(10) = 0
*
user_dat a: TEXT
Abbildung 34: Spezielle Tabelle für Session-Handling
In Release 2 von GradeBook sollen zu jedem Lernenden (und evtl. auch Berufsbildner) noch
die Klassenzugehörigkeit zu einer oder mehreren Klassen im BBC und in der Schule Gespeichert werden können. Dieser Sachverhalt wurde analysiert um sicherzustellen, dass mit
der geplanten Datenbankstruktur eine einfache Erweiterung für solche Informationen möglich
ist. Da die entsprechende Umsetzung in der aktuellen Softwareversion noch fehlen wird,
wurden auch die Datenbanktabellen noch nicht erstellt. Abbildung 35 zeigt aber wie die Klasseninformation mittels der Tabelle Klasse und zwei Zuordnungstabellen für den Lernenden in
GradeBook
2 gelöst wird.
dm ER-Diagramm Release
Klassenzuteilung
ER-Diagramm ::Lernender
ZuteilungKlasse
0..*
«column»
*PK idZuteilung KL: BIGINT
*FK idLernender: INTEGER
*FK idKlasse: INTEGER
0..*
«column»
*PK idLernender: INTEGER
1 *FK Benutzername: VARCHAR(50)
*FK idBerufsgruppe: INTEGER
*
Lehrstart: YEAR
0..*
1
1
Kla sse
«column»
1
*PK idKlasse: INTEGER
*
Bezeichnung: VARCHAR(50)
0..*
ZuteilungBerufsbildnerKlasse
«column»
*PK idZuteilungKB: INTEGER
*FK idBerufsbildner: INTEGER
*FK idKlasse: INTEGER
ER-Diagramm::Berufsbildner
«column»
*PK idBerufsbildner: INTEGER
*FK Benutzername: VARCHAR(50)
*FK idBerufsgruppe: INTEGER
Abbildung 35: Tabellen für die Speicherung von Klasseninformationen
Remo Seiler, MAS-07-02
Seite 59 von 124
3
Implementierung
Da die Implementierung der Software in Sourcecode-Dokumentation beschrieben ist, werden
in diesem Kapitel lediglich die Entwicklungs- und Dokumentations-Werkzeuge und die Installation der Anwendung auf dem Server beschrieben.
3.1
Tools
Für Analyse- und Design sowie Entwicklung der Applikation GradeBook kamen die in den
nachfolgenden Kapiteln beschriebenen Tools zum Einsatz.
3.1.1
Enterprise Architect
Mit dem Enterprise Architect Version 7.0.818 (EA) wurden sämtliche UML-Diagramme während der Analyse- und Design-Phase erstellt. Ausserdem wurde die automatische CodeErzeugung des Tools intensiv genutzt und in ihm das gesamte Projekt mit Ausnahme des
eigentlichen Source-Codes umgesetzt. Der erstellte Source-Code wurde aber jeweils wieder
mit dem EA synchronisiert und in diesem mit allen weiteren Informationen wie z.B. den Doxygen-Kommentaren ergänzt.
Aufgrund der vielfältigen Möglichkeiten des Tools konnte auch auf den Einsatz einer Umfangreichen IDE wie zum Beispiel Eclipse verzichtet werden. Letzteres führte zu einem deutlich geringeren Aufwand bei der Einarbeitung und Konfiguration von Tools, da nur die Spezialitäten eines solchen erarbeitet werden mussten.
(für Informationen und Download siehe [net18])
3.1.2
Notepad ++
Das Notepad ++ ist ein sehr einfacher aber trotzdem ausgereifter Sourcecode-Editor. Mit ihm
können Programme in zahlreichen Sprachen verfasst werden und er bietet dank der Möglichkeit viele zusätzliche Plugins (FTP-Synchronize, HTML-Tags, etc.) zu installieren alles
was für die Programmierung benötigt wurde. Der Editor ist ausserdem im Gegensatz zu
grossen Entwicklungsumgebungen sehr schnell geladen und bietet wenig „Stolpersteine“.
Einzige Nachteile, waren das Fehlen eines Projekt-Handlings (wurde aber vom EA ersetzt)
und der fehlende PHP-Debugger.
(für Informationen und Download siehe [net19])
3.1.3
XAMPP
Als lokaler Webserver wurde das Apache Friends XAMPP Basispaket Version 1.7.2 eingesetzt. Dank der einfachen und geführten Installation konnte so, innert kürzester Zeit eine
funktionierende Webserver-Umgebung mit Apache-Webserver, PHP, MySQL, OpenSSL etc.
installiert werden.
(für Informationen und Download siehe [net20])
3.1.4
MySQL Workbench
Im Paket MySQL Workbench Version 5.1.18a ist unter anderem der verwendete und sehr
praktische Query-Browser enthalten. Mit ihm wurden sämtliche Zugriffe (DDL und DML) auf
die Lokale Datenbank realisiert. So konnten die Tabellen erstellt, Testdaten-Skripte in diese
geladen, Abfragen entwickelt und Daten-Manipulationen durch GradeBook überprüft werden.
(für Informationen und Download siehe [net21])
Remo Seiler, MAS-07-02
Seite 60 von 124
3.1.5
WinSCP
WinSCP Version 4.2.5 ist ein open source SFTP und FTP - Client für Windows. Mit ihm wurde in der Firma und zu Hause auf den Linux-Webserver des Berufsbildungscenter zugegriffen. Sämtliche Datei-Uploads und Manipulationen konnten dank der Umfangreichen Funktionalität dieses Tools sehr effizient getätigt werden. Das Tool bietet beispielsweise die Möglichkeit der Verzeichnissynchronisation. Somit konnten Dateien auf dem Live-System direkt
mit dem Notepad++ geöffnet, bearbeitet und wieder gespeichert werden, was das Testen
von Inhalten die nur auf dem Live-System realisiert werden konnten enorm vereinfachte.
(für Informationen und Download siehe [net21])
3.1.6
Web Developer
Der Web Developer Version 1.1.8 ist ein Firefox-Plug-In und bietet eine Fülle von Werkzeugen für die Entwicklung von Webseiten. Beispielsweise können mit ihm CSS-Attribute zur
Laufzeit verändert werden und so das Layout sehr effizient optimiert werden. Zudem bietet er
viele Möglichkeiten für die Validierung von HTML, XHTML, CSS was intensiv genutzt wurde.
Alle Seiten von GradeBook sind in XHTML1.0 Strict codiert und wurden erfolgreich validiert.
3.1.7
Weitere
Zusätzlich zu den in vorangehenden Kapiteln beschriebenen wurden noch weitere Tools
verwendet, die aber keiner genaueren Beschreibung bedürfen oder nur selten eingesetzt
wurden. Die Tools sind in nachfolgender Auflistung zu sehen:
MS Office Word 2007 Professional
MS Office Excel 2007 Professional
MS Office Visio 2007 Professional
Adobe Photoshop CS2 (für Bildbearbeitungen)
Doxygen Version 1.6.2 (Siehe Kapitel 3.3)
PrintKey2000 Version 5.10 (für Screenshots)
Onlinetool Adobe Kuler (für Farbkonzepte) siehe [web12]
phpMyAdmin (für Datenbankzugriff auf dem Zielsystem)
3.2
Installation GradeBook
Die Installation der Applikation GradeBook setzt verschiedene Installierte und konfigurierte
Systeme voraus. In den folgenden Kapiteln folgt eine Installationsanleitung für ein lokales
Entwicklungssystem System mit Windows und für das Zielsystem (Webserver des Berufsbildungscenters.
3.2.1
Lokal
Um GradeBook auf einem lokalen Entwicklungssystem betreiben zu können sind folgende
Schritte notwendig:
1. Download und Installation einer Webserver- und Datenbankumgebung. Dazu kann
z.B. das XAMPP-Packet unter [net20] herunter geladen und installiert werden (Installationsanleitungen finden sich unter demselben Link).
2. Das Webroot-Verzeichnis htdocs im xampp-Verzeichnis beinhaltet nach der Installation die Konfigurations-Webseiten für den Webserver. Nachdem dieser konfiguriert
wurde, können alle Files aus dem htdocs-Verzeichnis gelöscht werden.
Remo Seiler, MAS-07-02
Seite 61 von 124
3. Download des PHP-Frameworks CodeIgniter (min. Version 1.7.2) unter [net4]. Das
entsprechende ZIP-File wird in das htdocs-Verzeichnis der XAMPP-Installation entpackt (htdocs). Das htdocs-Verzeichnis sollte nun folgendes enthalten:
4. Der Ordner user_guide kann gelöscht werden, er wird nicht benötigt (die aktuellen
Benutzermanuals sind auch online unter [net4] zu finden).
5. Die mitgelieferten Beispiel-Files löschen (system\application\controllers
\welcome.php und system\application\views\welcome_message.php).
6. Nun kann das Packet GradeBook.zip in das htdocs-Verzeichnis entpackt werden. Einige Config-Files der CodeIgniter-Installation werden dabei überschrieben, also bitte
eine allfällige Meldung bestätigen. Im Verzeichnis system\application\ müssten
nun in den entsprechenden Unterverzeichnissen (config, controllers, helpers, libraries, models und views) die GradeBook-Dateien abgelegt sein.
7. Als nächsten Schritt sollten Sie die Datenbank konfigurieren. Erstellen Sie vorerst die
MySQL-Datenbank „gradebook“ (via Eingabeaufforderung oder z.B. dem QueryBrowser), erstellen Sie einen Benutzer (sinnvollerweise mit Passwort) und geben Sie
diesem alle Rechte auf die Datenbank.
8. Erstellen Sie nun die Tabellen und laden Sie die Konstanten Daten und wenn benötigt auch die Testdaten in die Datenbank. Führen Sie dazu die Skripts GradeBook_DDL_V100.SQL, insert_constants.sql und insert_testdata.sql in
dieser Reihenfolge aus (das letzte Skript kann auch weggelassen werden, falls keine
Testdaten erwünscht sind).
9. Als nächstes werden die Konfigurationen für CodeIgniter definiert. Nehmen Sie in den
Files im Verzeichnis system\application\config folgende Einstellungen vor:
File
Array und Key
Änderung
config.php
$config['base_url']
database.php
$db['default']['username']
email.php
$db['default']['password']
Weitere nach Bedarf
$config['smtp_host']
Sinnvollerweise auf ihre IP-Adresse oder localhost
(ersteres ist zu bevorzugen)
Der definierte Benutzername für Ihre Datenbank
(falls nicht root).
Das zugehörige Passwort.
$config['smtp_user']
$config['smtp_pass']
$config['smtp_port']
Die Adresse ihres SMTP-Servers (z.B.
ssl://smtp.googlemail.com). Um Probleme mit Spam-Filtern zu
vermeiden empfiehlt sich nicht einen lokalen zu verwenden.
Ihr Benutzername auf dem SMTP-Server.
(z.B. [email protected])
Ihr Passwort zum SMTP-Account.
Der SMTP-Port z.B. 25
(ist auf 465 gestellt für Google-SMTP-Server mit SSL)
Weitere nach Bedarf
Tabelle 10: Konfiguration CodeIgniter für GradeBook
Remo Seiler, MAS-07-02
Seite 62 von 124
10. GradeBook ist nun konfiguriert und kann im Browser zum Beispiel über https://ihre-ipadresse aufgerufen werden
Hinweise:
Im Controller system\application\controllers\login.php können noch die Test-Variablen geändert werden (siehe auch Kapitel 2.3.2.1).
Es wurden mit mod_rewrite verschiedene Umleitungen realisiert (HTTPS, index.php wird
entfernt, …). Ihr Apache-Server muss dieses mod_rewrite unterstützen und OpenSSL oder
eine andere SSL-Unterstützung muss installiert sein. Ausserdem sollte für Unit-Tests die
cURL-Library installiert sein. Ob die nötigen Tools installiert und aktiviert sind, kann z.B. mit
php_info() überprüft werden. In der Standardinstallation von XAMPP sind alle benötigten
Tools vorhanden und aktiviert.
3.2.2
Zielsystem
Die Installation auf dem Zielsystem (dem Webserver des Berufsbildungscenters) läuft, mit
ein paar Ausnahmen, im gleichen Stil ab wie eine lokale Installation. Die 10 Installationsschritte der lokalen Installation entsprechen den nachfolgend aufgeführten Punkten. Diese
werden nur ergänzt oder korrigiert.
1. Auf dem Zielsystem ist der Webserver bereits installiert (Betriebssystem ist Linux, ->
Pfadangaben mit Slash anstatt Backslash).
2. Eigenes Webroot-Verzeichnis muss vorhanden sein. Das Verzeichnis auf dem Zielsystem ist /srv/web/gradebook/public/.
3. Entpacken in das Webroot-Verzeichnis auf dem Server.
4. Gleich wie in Kapitel 3.2.1.
5. Gleich wie in Kapitel 3.2.1.
6. Gleich wie in Kapitel 3.2.1 aber ins entsprechende Webroot-Verzeichnis (siehe auch
Punkt 2).
7. Gleich wie in Kapitel 3.2.1.
8. Gleich wie in Kapitel 3.2.1.
9. Die Konfigurationen auf dem Zielsystem sind wie folgt:
File
Array und Key
Änderung
config.php
database.php
$config['base_url']
$db['default']['username']
$db['default']['password']
$config['smtp_host']
$config['smtp_user']
$config['smtp_pass']
$config['smtp_port']
https://gradebook.cornet.ch/
gradebook
Das zugehörige Passwort.
10.10.10.6
gradebook
Das zugehörige Passwort.
25
email.php
10. Als nächstes müssen die Test-Variablen (siehe Kapitel 2.3.2.1) im Controller Login
konfiguriert werden um den Zugriff auf das ADS des Berufsbildungscenters zu aktivieren und die Authentifizierung einzuschalten (alle drei Variablen auf false).
11. Für den ADS-Zugriff müssen noch die LDAP-Parameter konfiguriert werden. Diese
sind in der Library system/application/libraries/Ldap.php zu finden. Für die Konfigurierung müssen folgende Variablen gesetzt werden: $_account_suffix, $_base_dn,
$_domain_controllers, $_ad_username, $_ad_password,
Remo Seiler, MAS-07-02
Seite 63 von 124
$_real_primarygroup, und $_use_ssl. Die einzelnen Werte werden hier aus Sicherheitsgründen nicht angegeben.
12. GradeBook ist nun konfiguriert und kann über die Adresse www.gradebook.cornet.ch
oder gradebook.cornet.ch aufgerufen werden (Umleitung auf HTTPS erfolgt automatisch).
3.3
Dokumentation Source-Code
Der Source Code von GradeBook wurde wie bereits verschiedentlich erwähnt ausschliesslich mit Doxygen-Kommentaren dokumentiert. Doxygen ist ein Source-Dokumentationstool,
mit dem Dokumentationen in HTML- oder Textformaten automatisch erzeugt werden können
(vergleichbar mit JavaDoc oder phpDoc). Das Tool stammt ursprünglich aus der C++-Welt,
es wird aber heute für verschiedenste weitere Sprachen, unter anderem auch für PHP eingesetzt.
Die Verwendeten Doxygen-Kommentare (Tags) im Source sind die folgenden:
Tag
@file
@brief
@author
@date
@version
@created
@updated
@class
@param
@return
@todo
Beschreibung
Dateinamen
Kurzbeschreibung (Dateien, Klassen, etc.)
Namen und Email des Autors
Erstelldatum (Dateien)
Version (Dateien, Klassen)
Erstelldatum (Klassen)
Änderungsdatum (Klassen)
Klassen-Beschreibung
Methoden-Parameter
Methoden Rückgabeparameter
Offene Punkte
Tabelle 11: Doxygen-Tags
Die Dokumentation wurde in HTML-Form erzeugt und kann über folgendes Index-File aufgerufen werden:
MT-07-02.16\Dokumente\Source\index.html
Die Source-Files selber sind in der Dokumentation ebenfalls integriert. Lediglich sicherheitsrelevante Daten wie Passwörter und Server-Adressen wurden aus dem Source entfernt.
Remo Seiler, MAS-07-02
Seite 64 von 124
4
Test
4.1
Testkonzepte
Um das SoftwareProdukt GradeBook adäquat Testen zu können bedarf es verschiedener
Testkonzepte. Grundsätzlich sollen diese Tests mit Ausnahme der Abnahmetests möglichst
viele Fehler in der Software aufdecken und nicht die Korrektheit der Software bestätigen. Um
das Ziel zu erreichen wurden folgende Tests geplant und durchgeführt:
Manuelles Testen der Datenbank-Struktur mittels einer angemessenen Menge von
Testdaten und Testabfragen (Test SQL-Queries) für alle Tabellen und sinnvollen
Verknüpfungen derselben.
Unit-Tests für die Modelklassen zum Test der Implementierung oben genannter Datenbankabfragen.
White-Box-Tests während der Entwicklung ohne entsprechende Dokumentation.
Diese Tests sind während der Entwicklung direkt in die Korrekturen und Optimierungen eingeflossen. Es stand leider kein brauchbarer Debugger zur Verfügung, da es
nicht viele PHP-Debugger gibt, die sich ohne Umstände in CodeIgniter integrieren
lassen und PHP-Debugging an sich eher ein umständliches Verfahren ist.
Manuelle Tests der Benutzeroberfläche als Gesamt-Integrationstests. Diese Tests
können nur schwer automatisiert werden, da hierfür eine Mocking-Umgebung notwendig wäre, die den Rahmen der Masterthesis sprengen würde.
Manuelle Tests der Eingabe-Formulare. Hierfür werden für die jeweiligen Formulare
Test-Äquivalenzklassen gebildet und diese Manuell abgearbeitet. Auch diese Tests
sind nicht ohne beträchtlichen Aufwand zu automatisieren.
Abnahmetests in Form von Testszenarien. Diese Tests wurden zu grossen Teilen
bereits in der Anforderungsspezifikation festgelegt und können leicht angepasst und
erweitert von dort übernommen werden.
Wie erwähnt sind die meisten aufgeführten Tests nicht oder nur sehr schwer zu automatisieren. Dies vor allem daher, weil die Software von sehr vielen Benutzeraktionen abhängt. Letztere könnten zwar mit Mocking-Objekten und automatisierten GUI-Test-Tools simuliert werden, was aber in einem Ein-Mann-Projekt aus verschiedenen Gründen nicht sinnvoll ist:
1. Tests sollten von einer unabhängigen Stelle (z.B. einem zweiten Entwicklungsteam)
entwickelt werden, um zu vermeiden, dass der Fokus auf der Beweisführung für die
Korrektheit der Software liegt.
2. Die allenfalls zu entwickelnden Mocking-Objekte währen zu Programmieren, was eine
zusätzliche Fehlerquelle darstellen würde und einen unverhältnismässigen Aufwand
zur Folge hätte.
3. Das Benutzerinterface sollte von einer unabhängigen Stelle auf Usability und ergonomische Aspekte getestet werden, da die Endbenutzer nicht die gleichen Voraussetzungen haben wie der Entwickler der Software. Letzterer kann somit nicht unvoreingenommen solche Tests durchführen.
Aus genannten Gründen wurden also alle Tests, ausser den Unit-Tests der Model-Klassen
manuell durchgeführt und sind in den Nachfolgenden Kapiteln beschrieben.
Remo Seiler, MAS-07-02
Seite 65 von 124
4.2
Testumgebung, Voraussetzungen
4.2.1
Testaufbau
Um die Softwaretests durchführen zu können muss mindestens eine Webserver-Umgebung,
ein MySQL-Datenbanksystem und die nötigen Client-Programme zur Verfügung stehen. In
Abbildung 36 ist der Testaufbau dargestellt, der für die kompletten Softwaretests notwendig
ist.
Abbildung 36: Testaufbau
Die Softwaretests wurden soweit möglich auf einem lokalen Entwicklungssystem und auch
auf dem Webserver des Berufsbildungscenters (Zielsystem) durchgeführt.
Sämtliche Tests die einen Domain-Controller des BBCnet voraussetzen (Login-Vorgang)
konnten ausschliesslich auf dem Zielsystem getestet werden. Die Email-Funktionalitäten
konnten zwar Lokal mit einem Privaten Email-Account (Gmail) teilweise überprüft werden,
die eigentlichen Tests wurden aber direkt auf dem Zielsystem mit Verbindung zum MailServer des BBCnet getätigt. Die blau hinterlegten Komponenten sind also auf dem Entwicklungssystem nur eingeschränkt oder gar nicht testbar.
Die gelb hinterlegten Komponenten stellen die Benutzer-Programme dar, welche bei beiden
Testarten auf die gleiche Weise eingesetzt werden. Mit diesen Programmen werden die Benutzerinteraktionen und der Mailversand getestet und überprüft.
Zur Überprüfung der Datenbank-Zugriffe, wird auf dem Entwicklungssystem der MySQLQuery-Browser eingesetzt. Für den Datenbank-Zugriff auf dem Zielsystem kommt phpMyAdmin zum Einsatz, mit welchem Datenbankeinträge komfortabel über ein Webinterface betrachtet und manipuliert werden können.
Remo Seiler, MAS-07-02
Seite 66 von 124
Das Deployment des Source Codes erfolgt auf dem lokalen System direkt aus der IDE, hier
Notepad++ (einfacher Source-Editor). Auf das Live-System werden die Daten mittels
WinSCP über FTP geladen.
4.2.2
Entwicklungssystem
Das Entwicklungssystem ist folgendermassen konfiguriert:
Betriebssystem: Windows XP SP3
Browser: MS Internet Explorer 8, Mozilla Firefox 3.5.7, Opera 9.8, Google Chrome
3.0.195.38, Safari 3.1.2
Apache Friends XAMPP (basic package) Version 1.7.2 mit
o
Webserver: Apache 2.2.12
o
Datenbank: MySQL 5.1.37
o
PHP 5.3.0
o
Perl 5.10.0
o
phpMyAdmin 3.2.0.1
o
OpenSSL 0.9.8k
o
…
IDE: Notepad++ 5.6.2
Mail-Client: MS Office Outlook 2007 SP2
4.2.3
Zielsystem
Die für GradeBook relevanten Parameter des Zielsystems sehen wie folgt aus:
Betriebssystem: Linux ubuntu 5.10
Webserver: Apache 2.2.8 (ubuntu) mit Suhosin Patch
PHP 5.2.4
OpenSSL 0.9.8g
Remo Seiler, MAS-07-02
Seite 67 von 124
4.3
Datenbank
Die in Kapitel 2.5 beschriebene Datenbankstruktur wurde mittels automatisch generierten
DDL-Skripten erzeugt und muss mit einer genügend grossen Menge Testdaten gefüllt werden um die Query-Tests durchführen zu können.
4.3.1
Testdaten
Folgende Skripts wurden erstellt um die Datenbank aufzusetzen:
Erstellt alle Tabellen, Schlüssel und Constraints. Löscht und Erstellt keine neue Datenbank, da dies auf dem Live-System aus
Berechtigungsgründen nicht möglich ist.
Fügt alle konstanten Daten in die entsprechenden Tabellen ein.
Diese Daten sind nicht nur Testdaten sondern bereits die momentan bekannten Daten für das Endsystem (Berufsgruppen,
Benutzergruppen, Fächer, Institutionen, Notentypen, Notengewichte und der Default-Berufsbildner).
Erstellt Testdaten zu allen Tabellen. Es wurden unter anderem
folgende Daten erfasst:
19 Benutzer, davon 13 Lernende und 6 Berufsbildner
17 Zuteilungen Lernender-Berufsbildner
6 Newsletter-Empfänger
17 Newsletter-Abonnemente und 11 Newsletter-Anfragen
32 Monatsabschlüsse
13x8 also 104 Semester für alle Test-Lernenden
104x6 also 624 Fach-Semester-Zuteilungen
5000 Noten
Die Testdaten wurden zum Teil willkürlich definiert, zufällig generiert (mit MS Excel) oder gemäss der grösstmöglichen Funktionsabdeckung festgelegt.
Die Benutzer entsprechen realen Benutzern die auch im ADS
des Berufsbildungscenters erfasst sind, wurden aber teilweise
mit imaginären Zusatzinformationen erweitert. Die verwendeten
Email-Adressen sind mit wenigen Ausnahmen abgeändert um
die Testdaten ohne Einschränkung auch für die Softwaretests
während der Entwicklungsphase verwenden zu können (ohne
die Benutzer mit Testmail-Spam zuzudecken).
Die Skripts sind in folgendem Verzeichnis (Abgabe-Paket Master Thesis) zu finden:
MT-07-02.16\Test\Datenbank\SQL_Scripts\
4.3.2
Testabfragen
Um die erstellte Datenbank zu testen wurde eine Fülle von Testabfragen erstellt, welche einen Grossteil aller auch später in den Models benötigten Abfragen umfasst und die Struktur
gut abbildet. Der Fokus der Testreihe liegt vor allem auf der Effizienz der Struktur und soll
sicher stellen, dass diese nicht durch einen zu hohen Normalisierungsgrad beeinträchtigt
wird.
Remo Seiler, MAS-07-02
Seite 68 von 124
Alle Tests wurden mit der Software MySQL Query Browser erstellt und ausgeführt. Die Resultate der Abfragen und weitere Informationen (z.B. Abfragezeiten) konnten ebenfalls im
Query Browser überprüft werden.
Die Testabfragen können später mehrheitlich unverändert für die Implementierung der Models eingesetzt werden.
Die Tabelle 12 zeigt eine Auflistung der erstellten Testabfragen und die Resultate der Tests.
Testnummer
Erwartete Rückgabedaten
TA_SQL_01
Alle Lernenden die dem Berufsbildner xy zugeteilt sind.
TA_SQL_02
Res. Tester /
Datum

RS/23.12.09
Alle Lernenden die nicht dem Berufsbildner xy zugeteilt sind
("except"-Workaround für MySQL)

RS/23.12.09
TA_SQL_03
Alle Lernenden die Fach 'Physik' in der GIBB besuchen mit
Benutzername, Semesternummer, Fachnamen und Institut

RS/23.12.09
TA_SQL_04
Alle Monatsabschlüsse mit Benutzer und Zeitpunkt

RS/23.12.09
TA_SQL_05
Berufsgruppe mit BG-id und BG-Namen eines Lernenden

RS/23.12.09
TA_SQL_06
Alle Fächer aller Lernenden mit Benutzername, Semesternummer, Fachnamen und Institut

RS/23.12.09
TA_SQL_07
Alle Fächer der Berufsgruppe ‚xy‘

RS/23.12.09
TA_SQL_08
Alle Fächer mit Berufsgruppe und Institut

RS/23.12.09
TA_SQL_09
Alle BMS-Fächer mit Berufsgruppe und Institut

RS/23.12.09
TA_SQL_10
Alle Fächer von 'xschlm' mit Benutzername, Semesternummer, Fachnamen und Institut

RS/23.12.09
TA_SQL_11
Semesternummer von Lernender 'nburkl' im Semester 4

RS/23.12.09
TA_SQL_12
Fachinfos von idFach

RS/23.12.09
TA_SQL_13
Alle Newsletter-Empfänger mit Abonnement eines Lernenden

RS/23.12.09
TA_SQL_14
Alle Lernende die entweder bereits einem NLE zugeteilt sind
oder für die eine NL-Anfrage zu einem bestimmten NLE existiert.

RS/23.12.09
TA_SQL_15
Alle Newsletter-Empfänger, die keine Abonnemente besitzen

RS/23.12.09
TA_SQL_16
Anzahl Newsletter-Anfragen zu einem Lernenden

RS/23.12.09
TA_SQL_17
Alle offenen Anfragen eines Newsletter-Empfängers mit Daten zu Lernenden

RS/23.12.09
TA_SQL_18
Liste mit allen offenen Anfragen von Newsletter-Empfänger
mit Daten zu Lernenden

RS/23.12.09
TA_SQL_19
Liste mit offenen Anfragen von Newsletter-Empfänger (Zuständigkeit eines Berufsbildners) mit Daten zu Lernenden

RS/23.12.09
TA_SQL_20
Alle Newsletter-Empfänger mit Anzahl offener NewsletterAnfragen

RS/23.12.09
TA_SQL_21
Alle Lernenden mit Anzahl Newsletter-Anfragen

RS/23.12.09
Remo Seiler, MAS-07-02
Seite 69 von 124
TA_SQL_22
Alle Lernenden eines Berufsbildners mit Daten und Anzahl
Newsletter-Anfragen

RS/23.12.09
TA_SQL_23
Alle Lernenden die nicht zu einem Berufsbildner gehören mit
Daten und Anzahl Newsletter-Anfragen

RS/23.12.09
TA_SQL_24
Alle Newsletter-Empfänger mit Anzahl Anfragen und Abonnemente

RS/23.12.09
TA_SQL_25
Anzahl Noten mit Wert 6 im gesamten Notenpool

RS/23.12.09
TA_SQL_26
Alle Noten aller Lernenden mit zusätzlichen Angaben aus
Benutzer

RS/23.12.09
TA_SQL_27
Alle Noten im Fach Chemie des Lernenden xschlm

RS/23.12.09
TA_SQL_28
Noten im Fach Chemie im Semester 5 des Lernenden nburkl

RS/23.12.09
TA_SQL_29
Noten eines Semesters in einem bestimmten Fach

RS/23.12.09
TA_SQL_30
Durchschnitt des Fachs Chemie im Semester 5 des Lernenden nburkl

RS/23.12.09
Tabelle 12: Testabfragen Datenbank
An dieser Stelle wird noch darauf hingewiesen, dass in MySQL kein except-Befehl für Abfragen existiert wie das in anderen RDBMS der Fall ist (z.B. Oracle). Dieser Befehl wäre aber in
verschiedenen Bereichen für Mengenoperationen notwendig gewesen um bei Verknüpfungen von Zuordnungstabellen (häufig notwendig für 3. Normalform) Schnittmengen ausschliessen zu können. Das Beispiel in Abbildung 37 verdeutlicht, wie diesem Problem mit
dem üblichen MySQL-Workaround mittels left-outer-Joins begegnet wurde. Ausserdem zeigt
das Beispiel auch wie komplexere Verknüpfungen (inkl. Ermittlung einer Anzahl Elemente)
mittels joins gelöst wurden.
Abbildung 37: Code-Snippet MySQL-Except-Workaround
Der Source-Code dieser und aller weiteren Abfragen ist in der entsprechenden MySQLQuery-Browser-Datei (Betrachtung mit Texteditor ebenfalls möglich) zu finden, unter:
MT-07-02.16\Test\Datenbank\SQL_Scripts\Testabfragen.qbquery
Remo Seiler, MAS-07-02
Seite 70 von 124
4.4
Unit-Tests der Models
Für Tests der eingesetzten Models und deren Methoden, wurden die in nachfolgenden Kapiteln erläuterten Unit-Tests programmiert. In einer Webapplikation können die Benutzerinterfaces und Benutzerinteraktionen nicht ohne weiteres mit solchen Tests automatisiert werden,
sie wurden deshalb ausschliesslich für die Model-Klassen implementiert.
Mit den Umgesetzten Unit-Tests können also die Model-Methoden getestet werden. Dies
ermöglicht im Hinblick auf die Entwicklung von GradeBook Release 2 eine effizientere Weiterentwicklung der Datenschicht. Sollten für das Release 2 Änderungen an Letzterer Vorgenommen werden müssen, können diese Änderungen automatisiert getestet und somit die
Qualität der im ersten Release umgesetzten Funktionalität sichergestellt werden (Regressionstests).
Die Implementierung dieser Tests wurde aus Effizienz-Gründen erst im Anschluss an die
eigentliche Software-Entwicklung realisiert. Es wurde nicht der Ansatz einer testgetriebenen
Entwicklung verfolgt.
4.4.1
Testframework Toast
Das CodeIgniter-Framework stellt zwar für Unit-Tests eine eigene Library zur Verfügung,
diese ist aber sehr rudimentär gehalten und bietet für den geplanten Einsatz eine zu geringe
Funktionalität. Grosse Testframeworks für PHP wie beispielsweise phpUnit [net7], haben den
Nachteil, dass sie nur umständlich in CodeIgniter integrierbar und zudem für den geplanten
Einsatz klar überdimensioniert sind. Dies würde ausserdem den Grundsatz verletzen, GradeBook und die eingesetzten Technologien so verständlich wie möglich zu halten (z.B. für
Lernende).
Aus diesen Gründen wurde die open source Unit-Test-Implementierung Toast [net8] evaluiert und eingesetzt.
Toast ist nicht als CodeIgniter-Library oder -Plugin implementiert und setzt auch nicht auf
weiteren Libraries wie z.B. phpUnit auf. Die Unit-Test-Funktionalität ist als einfacher CodeIgniter-Controller implementiert, was verschiedene Vorteile bringt:
Benötigt keine zusätzlichen Libraries oder Frameworks.
Keine Anpassung des CodeIgniter-Frameworks oder der Applikation nötig.
Benötigt keine weiteren Tools (wie z.B. das Kommandozeilenprogramm von phpUnit).
Der Testvorgang wird über die URL auf einem beliebigen Webbrowser gestartet.
Komplette CodeIgniter- und Applikations-Funktionalität steht uneingeschränkt zur
Verfügung.
Installation und Inbetriebnahme sind trivial. Toast kann einfach als weiterer Controller
im Webroot installiert/deinstalliert werden.
Die wenigen Nachteile die Toast mit sich bringt, sind für den geplanten Einsatz nicht von
zentraler Bedeutung (es fehlen beispielsweise Export-Möglichkeiten für die Testresultate).
Remo Seiler, MAS-07-02
Seite 71 von 124
4.4.2
Installation des Testframeworks Toast
Die Installation von Toast ist wie bereits erwähnt trivial. Eine ausführliche Anleitung dazu und
alle weiteren Informationen finden sich auf der Webseite des Entwicklers [net8]. An dieser
Stelle nur eine kurze Anleitung wie die Testumgebung für GradeBook installiert wird:
1. Download des Test-Frameworks von [net8].
2. Im CodeIgniter-Verzeichnis zwei neue Verzeichnisse erstellen:
a. /system/application/controller/test
b. /system/application/views/test
3. Die Files Toast.php und Toast_all.php ins erste Verzeichnis (a) kopieren
4. Die Files header.php, results.php und footer.php ins zweite Verzeichnis (b)
kopieren
5. Toast-Files anpassen für den BBCnet-Webserver: in den View-Files alle Short-tags
<? in <?php echo ändern.
Zum Testen der Installation kann noch das Beispiel example_tests.php ins erste Verzeichnis (a) kopiert und mittels Eingabe folgender URL aufgerufen werden:
http://{your server}/test/example_tests
Alle selbst erzeugten Test-Klassen werden ebenfalls in dem genannten Verzeichnis (a) gespeichert.
4.4.3
Implementierung der Unit-Test-Klassen
Das Vorgehen um mit Toast (siehe Kapitel 4.4.1) Unit-Tests umzusetzen ist denkbar einfach.
Es muss für jede zu testende Einheit (hier ausschliesslich die Model-Klassen) eine Klasse
angelegt werden, die von der Controller-Klasse Toast erbt. Damit Toast die Klassen später
finden kann, muss die Namenskonvention für die Dateinamen eingehalten werden, sprich
jeder Dateiname endet zwingend mit dem Postfix _tests. In der erstellten Testklasse kann
nun, wie in CodeIgniter üblich, im Konstruktor das benötigte Model (oder auch mehrere benötigte Models) geladen werden.
Für die eigentlichen Testmethoden gibt es eine zwingende Namenskonvention. Damit der
Basis-Controller Toast die Methoden finden kann, müssen sie mit einem Präfix test_ versehen werden. Sinnvollerweise werden die Methodennamen selbst, gemäss der zu testenden Model-Methode benannt. Ein Beispiel:
Die Testmethoden haben keine Übergabe- und Rückgabeparameter. Für den Test-Ablauf
werden dann die _assert-Methoden der Basis-Controller-Klasse aufgerufen. Diese produzieren die entsprechenden Browserausgaben mittels View-Files.
Ein weiteres sehr hilfreiches Werkzeug, das von Toast zur Verfügung gestellt wird, sind die
beiden speziellen Methoden _pre() und _post(). Diese werden in der Test-Klasse überschrieben und beim Testablauf vor und nach allen Testmethoden ausgeführt. Somit können
zum Beispiel vor den Tests „Dummy“-Daten in die Datenbank gespeichert und diese nach
Remo Seiler, MAS-07-02
Seite 72 von 124
den Tests wieder gelöscht werden1. Für die Unit-Tests der GradeBook-Models wurden diese
„Dummy“-Daten in entsprechenden privaten Attributen abgelegt und für die Tests verwendet
(siehe auch Klassendiagramm in Abbildung 38).
class UnitTests
«GBUnitTest»
M_benutzer_tests
«OSController»
Toast
-
benutzer
sessions
+
+
+
+
+
+
+
M_benutzer_tests()
_pre()
_post()
test_get_Benutzer()
test_get_idBerufsgruppe()
test_get_loginStatus()
test_logoff_Andere()
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
«GBUnitTest»
M_berufsbil dner_tests
-
benutzer
berufsbildner
lern ende
nl e
nlAnf ragen
+
+
+
+
+
+
+
M_berufsbildner_tests()
_pre()
_post()
test_get_Lernende()
test_get_idBerufsbildner()
test_get_DatenBerufsbildner()
test_add_remove_Lernender()
«GBUnitTest»
M_lernender_tests
-
benutzer
lernender
+
+
+
+
+
+
+
+
+
M_lernender_tests()
_pre()
_post()
test_get_aktuellesSemester()
test_get_AlleLernende()
test_get_Daten()
test_get_idLernender()
test_get_Berufsgruppe()
test_get_set_Monatsabschluss()
«GBUnitTest»
M_semester_tests
-
benutzer
lernender
semester
zuteilungFS
+
+
+
+
+
+
M_semester_tests()
_pre()
_post()
test_get_Faecher()
test_get_idSemester()
test_add_remove_Fach()
«CodeIgniter»
Contr oller
Toast(name)
index()
show_results()
_show_all()
_show(method)
_run_all()
_run(method)
_get_test_methods()
_remap(method)
_pre()
_post()
_assert_true(assertion)
_assert_false(assertion)
_assert_equals(base, check)
_assert_not_equals(base, check)
_assert_equals_strict(base, check)
_assert_not_equals_strict(base, check)
_assert_empty(assertion)
_assert_not_empty(assertion)
«GBUnitTest»
M_fach_tests
+
+
+
+
+
+
+
+
benutzer
lernender
semester
faecher
zuteilungFS
not en
nGewi chte
nT yp
M_fach_tests()
_pre()
_post()
test_get_alleFaecher()
test_get_alleFaecherLernender()
test_get_Infos()
test_get_Noten()
test_get_Durchschnitt()
«OSController»
Toast_all
verwendet
+
+
+
+
+
«GBUnitTest»
M_note _tests
-
benutzer
lernender
semester
fach
not en
nGewi chte
nTypen
+
+
+
+
+
+
+
M_note_tests()
_pre()
_post()
test_add_update_delete_Note()
test_get_Notengewichte()
test_get_Notentypen()
test_get_NotenDaten()
Toast_all()
index()
_get_test_files()
_curl_get(urls)
_curl_get_multi(urls)
«GBUnitTest»
M_new sletter_tests
-
benutzer
berufsbildner
lern ende
nl e
nlAnf ragen
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
M_newsletter_tests()
_pre()
_post()
test_add_delete_nlAbonnement()
test_add_delete_nlAnfrage()
test_confirm_nlAnfrage()
test_add_update_delete_nlEmpfaenger()
test_get_nlAnfragen()
test_get_AnzahlNlAnfragen()
test_get_idAnfrage()
test_get_nlAnfrage()
test_get_nlEmpfaengerLernender()
test_get_AlleNlEmpfaenger()
test_get_LernendeNlEmpfaenger()
test_get_nlEmpfaenger()
test_get_idNLE()
Abbildung 38: Klassendiagramm Unit-Tests
Da eine Beschreibung aller Testmethoden dank deren logischer Namensgebung überflüssig
erscheint, wird an dieser Stelle nur auf die Source-Dokumentation verwiesen wo kurze Beschreibungen und Kommentare die Umsetzung erläutern (siehe auch Kapitel 3.2).
Eine Bemerkung am Rande: einige Methoden (add-, update, und delete) wurden sinnvollerweise nicht einzeln sondern nur in Kombination getestet und weisen deshalb lediglich eine
gemeinsame Testmethode auf (siehe auch Abbildung 38).
4.4.4
Testablauf
Die Tests können nun einzeln, Modulweise oder alle miteinander gestartet werden wie nachfolgende Beispiele zeigen:
Einzeltest für get_nlAnfrage:
URL: http://server/test/m_newsletter_tests/get_nlAnfrage
1
Für die Tests wurden bewusst nicht die Testdaten der Datenbank (siehe Kapitel 4.3.1) verwendet,
damit die Unit-Tests auch im späteren Live-System uneingeschränkt eingesetzt werden können.
Remo Seiler, MAS-07-02
Seite 73 von 124
M_newsletter-Klasse komplett testen:
URL: http://server/test/m_newsletter_tests
Alle Tests ausführen: 1
URL: http://server/test/m_newsletter_tests/toast_all
4.4.5
Resultate und Auswertung
Die Unit-Tests wurden nach ihrer Entwicklung manuell getestet, indem in den jeweiligen Modelmethoden bewusst Fehler eingebaut wurden. Da aber die Unit-Test-Klassen ebenfalls
Source Code darstellen, kann mit diesen manuellen Tests nicht bewiesen und somit auch
nicht garantiert werden, dass sie selbst komplett Fehlerfrei sind. Dank sorgfältiger Überprüfungen ist aber eine genügend hohe Qualität gegeben.
Die Tests wurden gemäss dem definierten Testablauf (siehe Kapitel 4.4.4) durchgeführt und
sind für die aktuelle Version der Applikation GradeBook erfolgreich. Eine Auflistung der
knapp 40 erfolgreichen Tests macht hier wenig Sinn, es wird aber nachfolgend mittels zwei
Screenshots gezeigt wie die Resultate eines Testablaufs dargestellt werden und wie sie zu
interpretieren sind.
Links:
Rechts:
nicht erfolgreicher Test, in zwei Model-Methoden wurden Fehler eingebaut,
erfolgreicher Test, nach Korrektur der Fehler
Abbildung 39: Nicht erfolgreicher und erfolgreicher Unit-Test (Model Newsletter)
Alle Unit-Tests wurden auf dem lokalen Entwicklungssystem durchgeführt, sind aber auf dem
Webserver des Berufsbildungscenters ebenfalls installiert. Die Installation auf dem LiveSystem wird aber mit Start der Betatestphase Anfang März 2010 entfernt und nur bei Bedarf
wieder aufgeschaltet.
1
Damit dies funktioniert muss auf dem Webserver zwingend cURL [net9] installiert sein!
Remo Seiler, MAS-07-02
Seite 74 von 124
4.5
Manuelle Tests
In diesem Kapitel werden die manuell durchgeführten Tests zu allen Teilen, die Benutzerinteraktionen erfordern getestet. Einen wichtigen Bestandteil bilden hier die Tests der Eingabeformulare. Diese bieten ein relativ hohes Fehlerpotential, da das Benutzerverhalten für diese
Formulare sehr vielfältig und schwer voraussehbar ist. Deshalb müssen alle Formulare, mit
denen Daten für die Speicherung in der Datenbank eingegeben werden, intensiv auf Fehler
untersucht werden. In Kapitel 4.5.2 werden die durchgeführten Tests dokumentiert. Da die
nicht erfolgreichen Tests (resp. je nach Betrachtung die erfolgreichen) direkt in Korrekturen
und Optimierungen eingeflossen sind, und alle Korrekturen noch umgesetzt werden konnten,
sind keine Tests mehr als nicht erfolgreich gekennzeichnet.
4.5.1
Benutzeroberfläche, Layout, Navigation
Die Optik und das Layout einer Webanwendung sind sehr subjektive Eigenschaften des Produkts (oder anders formuliert Geschmackssache) und daher nur schwer für eine ganze Zielgruppe zu Testen. Getestet wurden diese Eigenschaften deshalb auch nur in direkter Zusammenarbeit mit den Stakeholdern. Die aktuelle Version der Applikation wurde den wichtigsten Stakeholdern vorgeführt und entspricht deren Erwartungen. Ausserdem konnte mit
dem Design-Verantwortlichen des Berufsbildungscenters (Marc Grimmbühler, Berufsbildner
Informatik, Projekte: z.B. [net15]) ein Walktrough der Webseiten durchgeführt und dabei viele
Nützliche Inputs eingeholt werden.
Sämtliche Webseiten wurden in XHTML1.0 Strict umgesetzt. Die Validierung aller Seiten
konnte mit dem Web Developer (Firefox Plugin, siehe Kapitel 3.1.6) realisiert werden. Sämtliche Seiten wurden auf Konformität überprüft und die doch recht vielen, aber meist kleineren
Fehler korrigiert (Tag schliessen vergessen bei <br/> oder <img…/>, Gross-/Kleinschreibung
missachtet, …). Alle Seiten entsprechen nun komplett dem XHTML 1.0 Strict Standard. Abbildung 40 zeigt exemplarisch eine entsprechende Ausgabe der XHTML1.0-Validierung für
das Login-Formular.
Abbildung 40: Validierung des XHTML1.0 Strict Standards
Die Stylesheets der Webseiten wurden, ebenfalls mit dem Web Developer bezüglich
CSS2.1-Konformität validiert und erfüllen alle diesen Standard. Aufgrund der Test-Resultate,
wird vom Web Developer Team empfohlen auf den Seiten folgende Qualitäts-Siegel zu platzieren um zu zeigen, dass interoperable Seiten erzeugt wurden.
Remo Seiler, MAS-07-02
Seite 75 von 124
Die beiden Graphiken werden voraussichtlich nach der Fertigstellung von GradeBook Release 2 auf der Webseite platziert. Sie dienen auch dafür, technisch versierten Benutzern
das Sicherheitsgefühl zu steigern, weil ihnen so gezeigt wird, dass die wichtigsten Standards
bezüglich Codierung eingehalten wurden.
Die Tests der Benutzeroberfläche wurden ansonsten hauptsächlich im Browser Microsoft
Internet Explorer 8 durchgeführt. Die Navigation auf den Webseiten, optische Aspekte und
die wichtigsten Formulare wurden mit reduziertem Test-Umfang zusätzlich auch mit folgenden Browsern geprüft:
Mozilla Firefox 3.5.7
Opera 9.8
Google Chrome 3.0.195.38
Safari 4 für Windows
Safari 4 für iPhone mit OS 3.x
Die Webseite wird mit all diesen Browsern problemlos dargestellt und ist ohne Einschränkungen zu bedienen. Einzig im Safari 4 für das iPhone ist die Darstellung der Auswahllisten
etwas unschön, da diese dort nicht als Listenfelder sonder als Auswahl-Rad ähnlich einer
Dropdown-Box dargestellt werden. Die Bedienung ist dadurch zwar nicht beeinträchtigt, aber
die Optik ist nicht optimal.
Für die Navigation auf den Webseiten wurde keine separate Test-Dokumentation erstellt. Die
Navigation wurde während der Entwicklungsphase implizit getestet und optimiert. Ausserdem ist diese bei allen nachfolgenden, manuellen Tests sowie bei den Abnahmetests eine
Grundvoraussetzung und wurde somit dort ebenfalls ausgiebig überprüft.
Remo Seiler, MAS-07-02
Seite 76 von 124
4.5.2
Eingabeformulare
Für die manuelle Prüfung der Eingabeformulare werden in den nachfolgenden Kapiteln entsprechende Testfälle definiert und in Tabellen aufgelistet. Zu den jeweiligen Testfällen ist das
Textfeld (Spalte „Feld“) mit den entsprechenden Eingaben (Spalte „Eingabedaten“) dargestellt und vermerkt ob es sich dabei um einen Normalfall (Spalte „N“) oder einen Fehlerfall
(Spalte „F“) handelt.
Hinweis: Für die Überprüfung der Formulare sind vor allem die Fehlerfälle interessant und
deshalb deutlich stärker vertreten als die Normalfälle.
In der Spalte „Resultat“ wird der Erfolg der Tests jeweils mit OK oder NOK dokumentiert und
bei Fehlschlägen ergänzend kommentiert.
Aufgrund der grossen Menge an möglichen Eingabedaten werden Test-Äquivalenzklassen
gebildet um möglichst eine surjektive Abbildung1 der Eingabedaten auf die Ausgaben
(hauptsächlich Fehlermeldungen) zu erreichen. Pro Äquivalenzklasse werden jeweils, je
nach Relevanz, ein oder mehrere Tests durchgeführt.
4.5.2.1 Login-Formular
Das Login-Formular (siehe Abbildung 41) besteht aus zwei Eingabefeldern und dem Button
Login. Die Felder erlauben eine maximale Eingabe von je 100 Zeichen und die Eingaben
werden unter anderem mit der CodeIgniter Formvalidation-Library geprüft. Fehlermeldungen
werden, wie in Abbildung 41 ersichtlich, direkt im Formular ausgegeben.
PW ungültig
Abbildung 41: Formular Login
In der Tabelle 13 sind die Tests für eine Auswahl von gültigen und ungültigen Eingaben in
dieses Formular dokumentiert. Die gültigen Passwörter für die im ADS erfassten Testbenutzer werden aus Sicherheitsgründen nicht abgebildet.
1
Surjektivität: definiert die Eigenschaft einer mathematischen Funktion und besagt für diese, dass jedes Element
der Zielmenge mindestens einmal als Funktionswert angenommen wird. Da Software im weitesten Sinne als
mathematische Funktion betrachtet werden kann (Eine Menge von Eingabedaten erzeugt eine Menge von Ausgabedaten) eignet sich der Begriff in diesem Sinne auch für Softwaretests.
Remo Seiler, MAS-07-02
Seite 77 von 124
Test-id
Feld
Eingabedaten
Bemerkung
N F Erwartetes Resultat
Resultat
Tester
TForm.01
Benutzername
Passwort
inf-aus-gb
korrektes Passwort
Benutzername und
Passwort korrekt
X
TForm.02
Benutzername
Passwort
INF-AUS-GB
korrektes Passwort
Benutzername ist nicht
Case-Sensitiv
X
TForm.03
Benutzername
Passwort
inf-aus
korrektes Passwort
Benutzername falsch
TForm.04
Benutzername
Passwort
inf-aus-gb
ungültiges Passwort
TForm.05
Benutzername
Passwort
TForm.06
Login erfolgreich, Weiterleitung an Startseite
OK
RS
01.02.2010
Login erfolgreich, Weiterleitung an Startseite
OK
RS
01.02.2010
X
Fehlermeldung:
Benutzername oder Passwort falsch!
OK
RS
01.02.2010
Benutzername korrekt,
Passwort falsch
X
Fehlermeldung:
Benutzername oder Passwort falsch!
OK
RS
01.02.2010
leer
korrektes Passwort
Benutzername fehlt
X
Fehlermeldung:
Das Feld "Benutzername" darf nicht leer sein!
OK
RS
01.02.2010
Benutzername
Passwort
inf-aus-gb
leer
Benutzername korrekt,
Passwort fehlt
X
Fehlermeldung:
Das Feld "Passwort" darf nicht leer sein!
OK
RS
01.02.2010
TForm.07
Benutzername
Passwort
leer
leer
Beide Eingaben fehlen
X
Fehlermeldungen:
Das Feld "Benutzername" darf nicht leer sein!
Das Feld "Passwort" darf nicht leer sein!
OK
RS
01.02.2010
TForm.08
Benutzername
Passwort
Überlanger Text
Überlanger Text
Eingabe von mehr als
100 Zeichen sollte nicht
möglich sein.
X
OK
RS
01.02.2010
Spezielle Sonderzeichen
im Passwort.
X
OK
RS
01.02.2010
TForm.09
Benutzername
Passwort
Inf-aus-gb
“ “) || 1==1
1.
2.
Begrenzung der Eingabe bei 100 Zeichen.
Fehlermeldung:
Benutzername oder Passwort falsch!
Fehlermeldung:
Benutzername oder Passwort falsch!
Datum
Tabelle 13: Test Login-Formular
Remo Seiler, MAS-07-02
Seite 78 von 124
4.5.2.2 Noteneingabe-Formular
Das wichtigste Formular in einer Notenverwaltung ist sicherlich dasjenige für die Eingabe
von Noten. Aus diesem Grund sollen für diese mehrere Tests pro Test-Äquivalenzklasse
durchgeführt werden um somit alle Grenzwerte, sowie weitere gültige und ungültige Werte zu
prüfen.
In Abbildung 41 ist ersichtlich, dass die Fehlermeldungen direkt im Formular ausgegeben
werden und die eingegebenen Daten dabei erhalten bleiben. Im Beispiel wird versucht den
ungültigen Wert 0 für eine Note zu definieren.
ungültig
Abbildung 42: Formular Noteneingabe
Bei allen Tests zum Eingabefeld „Note“ wird nach der Eingabe jeweils der Button speichern
betätigt und bei Erfolg das Resultat in der Datenbank überprüft (mittels MySQL-QueryBrowser oder phpMyAdmin). Für diese Tests sind die beiden Auswahlfelder „Gewicht“ und
„Notentyp“ nicht von Bedeutung.
Hinweis: Wenn zukünftig eine Option für die Eingabe einer Skala pro Note umgesetzt werden
soll (siehe Checkliste in Kapitel 6.3.1), werden die Tests dieses Kapitels obsolet und müssen
neu festgelegt werden.
Remo Seiler, MAS-07-02
Seite 79 von 124
Test-id
Feld
Eingabedaten
Bemerkung
N F
TForm.10
Note
-10
Ungültig negativ
X
TForm.11
Note
0
Ungültig 0
TForm.12
Note
0.99
Ungültig Grenzwert
TForm.13
Note
1
Gültig Grenzwert
TForm.14
Note
4
TForm.15
Note
TForm.16
Erwartetes Resultat
Resultat
Tester, Datum
Fehlermeldung: Eingegebener Notenwert ungültig!
OK
RS, 02.02.2010
X
Fehlermeldung: Eingegebener Notenwert ungültig!
OK
RS, 02.02.2010
X
Fehlermeldung: Eingegebener Notenwert ungültig!
OK
RS, 02.02.2010
X
Eingabe i.O., Note, Gewicht und Notentyp wird gespeichert
OK
RS, 02.02.2010
Gültig Normalwert
X
Eingabe i.O., Note, Gewicht und Notentyp wird gespeichert
OK
RS, 02.02.2010
6
Gültig Grenzwert
X
Eingabe i.O., Note, Gewicht und Notentyp wird gespeichert
OK
RS, 02.02.2010
Note
6.01
Ungültig Grenzwert
X
Fehlermeldung: Eingegebener Notenwert ungültig!
OK
RS, 02.02.2010
TForm.17
Note
10
Ungültig
X
Fehlermeldung: Eingegebener Notenwert ungültig!
OK
RS, 02.02.2010
TForm.18
Note
5.1
Gültig 1 Dezimalstelle
X
Eingabe i.O., Note, Gewicht und Notentyp wird gespeichert
OK
RS, 02.02.2010
TForm.19
Note
5.12
Gültig 2 Dezimalstellen
X
Eingabe i.O., Note, Gewicht und Notentyp wird gespeichert
OK
RS, 02.02.2010
TForm.20
Note
5.123
Ungültig 3 Dezimalst.
X
Fehlermeldung: Die Note darf maximal 2 Dezimalstellen haben!
OK
RS, 02.02.2010
TForm.21
Note
abc
Ungültig keine Zahlen
X
Fehlermeldung: Eingegebener Notenwert ungültig!
OK
RS, 02.02.2010
TForm.22
Note
leer
X
Fehlermeldung: Das Feld "Note" darf nicht leer sein!
OK
RS, 02.02.2010
TForm.23
Note
Gewicht
Notentyp
5.00
1/4
Einzelnote
Test der Auswahlfelder
(korrekte Speicherung
in DB)
X
Eingabe i.O., Note, Gewicht und Notentyp wird gespeichert
OK
RS, 02.02.2010
TForm.24
Note
Gewicht
Notentyp
5.00
10
Einzelnote
Test der Auswahlfelder
(korrekte Speicherung
in DB)
X
Eingabe i.O., Note, Gewicht und Notentyp wird gespeichert
OK
RS, 02.02.2010
TForm.25
Note
Gewicht
Notentyp
5.00
2
Prüfungsnote
Test der Auswahlfelder
(korrekte Speicherung
in DB)
X
Eingabe i.O., Note, Gewicht und Notentyp wird gespeichert
OK
RS, 02.02.2010
TForm.26
undef.
Button Abbrechen
Unabhängig von Eingabedaten
X
Es werden keine Daten gespeichert -> zurück zur Übersicht
OK
RS, 02.02.2010
Tabelle 14: Test Noteneingabe-Formular
Remo Seiler, MAS-07-02
Seite 80 von 124
4.5.2.3 Formulare Newsletter-Abonnement beantragen
Für die Anfrage eines Newsletters zu einem Lernenden sind zwei Formulare von Bedeutung.
Zum einen die Eingabe der Email-Adresse für die Abfrage ob der Newsletter-Empfänger bereits erfasst ist und falls nicht das Registrierungsformular für einen neuen Empfänger. Durch
Klicken auf den Link „Newsletter abonnieren“ gelangt man zum ersten der beiden Formulare.
Die Tests zu diesem sind in Tabelle 15 dokumentiert.
Da die Anforderung NUC.01 FA.03 (siehe [dok2]) umgesetzt wurde, muss zusätzlich Überprüft werden, ob die Syntax der Email-Adresse korrekt validiert wird. Die Fehlermeldungen
bei nicht korrektem Email-Format oder bei leerem Eingabefeld, werden direkt im Formular
ausgegeben (Das Formular wird neu geladen, behält aber die bereits eingegebenen Daten).
In Abbildung 43 ist dargestellt, wie eine solche Ausgabe für eine nicht korrekte Eingabe aussieht.
ungültig
Abbildung 43: Formular Email-Eingabe
Für die Format-Prüfung wurden nicht alle theoretisch möglichen Email-Adressen in Betracht
gezogen. Die speziellen aber gemäss Definition trotzdem gültigen Email-Adressen wie zum
Beispiel [email protected], test@localhost
oder „Satz
mit
leerschlag“@test.ch werden von GradeBook nicht als gültige Adresse akzeptiert. Da lokale
Adressen aber nicht akzeptiert werden müssen und andere sehr spezielle Formen bei den
meisten Mail-Anbietern und Mail-Servern von Firmen nicht verwendet werden ist dieser Umstand nicht von Belang. Alle gängigen Email-Adressen werden akzeptiert und korrekt geprüft.
Remo Seiler, MAS-07-02
Seite 81 von 124
Test-id
Feld
Eingabedaten
Bemerkung
N F
Erwartetes Resultat
Resultat
Tester, Datum
TForm.27
Email-Adresse
[email protected]
Gültige nicht registrierte
Adresse
X
Weiterleitung an Registrierungsformular
OK
RS, 02.02.2010
TForm.28
Email-Adresse
[email protected]
Gültige registrierte
Adresse
X
Weiterleitung zu Formular Auswahl Lernende
OK
RS, 02.02.2010
TForm.28
Email-Adresse
Test?test.ch
Ungültiges EmailFormat
X
Fehlermeldung:
Die eingegebene Email-Adresse hat kein gültiges Format!
OK
RS, 02.02.2010
TForm.30
Email-Adresse
test.ch
Ungültiges EmailFormat
X
Fehlermeldung:
Die eingegebene Email-Adresse hat kein gültiges Format!
OK
RS, 02.02.2010
TForm.31
Email-Adresse
test_äöü@test.ch
Ungültiges EmailFormat
X
Fehlermeldung:
Die eingegebene Email-Adresse hat kein gültiges Format!
OK
RS, 02.02.2010
TForm.32
Email-Adresse
Eingabe verschiedener
ungültiger Sonderzeichen
Gemäss RFC5322
X
Fehlermeldung:
Die eingegebene Email-Adresse hat kein gültiges Format!
OK
RS, 02.02.2010
TForm.33
Email-Adresse
leer
X
Fehlermeldung:
Das Feld "Email-Adresse" darf nicht leer sein!
OK
RS, 02.02.2010
TForm.34
Email-Adresse
Überlanger Text
Eingabe von mehr als
50 Zeichen sollte nicht
möglich sein.
X
Begrenzung der Eingabe bei 50 Zeichen.
Falls Eingabeformat Falsch: Fehlermeldung.
OK
RS, 02.02.2010
TForm.35
Email-Adresse
test@localhost
Ist zwar theoretisch
gültig soll aber nicht
akzeptiert werden
X
Fehlermeldung:
Die eingegebene Email-Adresse hat kein gültiges Format!
OK
RS, 02.02.2010
Tabelle 15: Test Email-Formular
Remo Seiler, MAS-07-02
Seite 82 von 124
4.5.2.4 Formulare Registrierung
Das Registrierungsformular für neue Newsletter-Empfänger ist das umfangreichste Eingabeformular in GradeBook, da hierfür alle persönlichen Daten des Newsletter-Empfängers erfasst werden müssen. In Abbildung 44 ist ersichtlich, dass auch bei diesem Formular alle
Fehlermeldungen direkt bei den entsprechenden Eingabefeldern angezeigt werden (Im Beispiel wurde der „Daten senden“-Button betätigt ohne Daten eingegeben zu haben).
Daten fehlen
Abbildung 44: Formular Registrierung
Um eine sinnvolle Menge und Aufteilung von möglichen Testdaten zu erhalten wird für die
Tests in Tabelle 16 jedes Eingabefeld einzeln, also unabhängig der Daten in den anderen
Feldern betrachtet. Effekte die im Zusammenhang mit mehreren Feldern stehen könnten
(solche sollten eigentlich nicht existieren), werden dementsprechend nicht geprüft.
Weitere Hinweise:
Die Email-Adresse wird automatisch vom vorangehenden Formular übernommen,
kann aber hier nochmals geändert werden. Sie muss aus diesem Grund erneut validiert werden, was zu weiteren Fehlermeldungen führen kann (z.B. Email bereits vergeben). Um die Tests nicht zu überladen, werden nur die, gegenüber dem EmailFormular, neuen Fehlerfälle getestet (keine Formatfehler).
Die Captcha-Graphik wird bei jedem Laden des Formulars neu generiert. Falls also
Fehler ausgegeben werden wird die zuvor angezeigte Graphik obsolet und die Zeichen müssen zwingend neu eingegeben werden (sie werden also auch nicht ins neue
Formular geladen).
Remo Seiler, MAS-07-02
Seite 83 von 124
Test-id
Feld
Eingabedaten
Bemerkung
N F
Erwartetes Resultat
TForm.36
Email
[email protected]
Gültige nicht registrierte
Adresse
X
TForm.37
Email
[email protected]
Gültige bereits registrierte
Adresse
TForm.38
Email
leer
Pflichtfeld
TForm.39
Anrede
Frau
Gültige Auswahl
TForm.40
Anrede
Bitte wählen
Auswahl fehlt
TForm.41
Name
Seiler
Gültige Eingabe
TForm.42
Name
Überlanger Text
Maximal 50 Zeichen
X
TForm.43
Name
leer
Pflichtfeld
X
TForm.44
Vorname
Remo
Gültige Eingabe
TForm.45
Vorname
Überlanger Text
Maximal 50 Zeichen
TForm.46
Vorname
Leer
Pflichtfeld
TForm.47
Firma
Ascom (Schweiz) AG
Gültige Eingabe
TForm.48
Firma
Überlanger Text
Maximal 50 Zeichen
TForm.49
Firma
Leer
Pflichtfeld
TForm.50
Strasse
Bahnhöheweg 70
Gültige Eingabe
TForm.51
Strasse
Überlanger Text
Maximal 50 Zeichen
X
TForm.52
Strasse
Leer
Pflichtfeld
X
TForm.53
PLZ
3018
Gültige Eingabe
TForm54
PLZ
123
Zu kleine Zahl
TForm.55
PLZ
abc
Ungültige Zahl
Remo Seiler, MAS-07-02
Resultat
Tester, Datum
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
X
Fehlermeldung:
Die eingegebene Email-Adresse ist bereits vergeben!
OK
RS, 02.02.2010
X
Fehlermeldung:
Das Feld "Email" darf nicht leer sein!
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
Fehlermeldung:
Bitte wählen Sie eine Anrede!
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
Begrenzung der Eingabe bei 50 Zeichen.
OK
RS, 02.02.2010
Fehlermeldung:
Das Feld "Name" darf nicht leer sein!
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
X
Begrenzung der Eingabe bei 50 Zeichen.
OK
RS, 02.02.2010
X
Fehlermeldung:
Das Feld "Vorname" darf nicht leer sein!
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
X
Begrenzung der Eingabe bei 50 Zeichen.
OK
RS, 02.02.2010
X
Fehlermeldung:
Das Feld "Firma" darf nicht leer sein!
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
Begrenzung der Eingabe bei 50 Zeichen.
OK
RS, 02.02.2010
Fehlermeldung:
Das Feld "Strasse" darf nicht leer sein!
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
X
Fehlermeldung:
Die Eingabe im Feld "PLZ" ist ungültig
OK
RS, 02.02.2010
X
Fehlermeldung:
Die Eingabe im Feld "PLZ" ist ungültig
OK
RS, 02.02.2010
X
X
X
X
X
X
Seite 84 von 124
TForm.56
PLZ
Mehr als 4 Zeichen
Nicht möglich
TForm.57
PLZ
Leer
Pflichtfeld
Begrenzung der Eingabe bei 4 Zeichen.
TForm.58
Ort
Bern
Gültige Eingabe
TForm.59
Ort
Leer
Pflichtfeld
TForm.60
Ort
Überlanger Text
Maximal 50 Zeichen
TForm.61
Telefon Geschäft
078 333 33 33
Gültige Eingabe
TForm.62
Telefon Geschäft
Leer
Pflichtfeld
TForm.63
Telefon Geschäft
Überlanger Text
Maximal 20 Zeichen
TForm.64
Telefon Privat
031 333 33 33
Gültige Eingabe
TForm.65
Telefon Privat
Leer
Kein Pflichtfeld
TForm.66
Telefon Privat
Überlanger Text
Maximal 20 Zeichen
TForm.67
Telefon Mobile
078 333 33 33
Gültige Eingabe
TForm.68
Telefon Mobile
Leer
Kein Pflichtfeld
TForm.69
Telefon Mobile
Überlanger Text
Maximal 20 Zeichen
TForm.70
Zeichen
Korrekte Zeichen
Wie in Graphik dargestellt
X
TForm.71
Zeichen
Korrekte Zeichen, in
Grossbuchstaben
Captcha-Algorithmus ist
nicht Case-sensitiv
X
TForm.72
Zeichen
Falsche Zeichen
Nicht wie in Graphik dargestellt
TForm.73
Zeichen
leer
TForm.74
Zeichen
TForm.75
TForm.76
X
X
Fehlermeldung:
Das Feld "PLZ" darf nicht leer sein!
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
X
Fehlermeldung:
Das Feld "Ort" darf nicht leer sein!
OK
RS, 02.02.2010
X
Begrenzung der Eingabe bei 50 Zeichen.
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
X
Fehlermeldung:
Das Feld "Telefon Geschäft" darf nicht leer sein!
OK
RS, 02.02.2010
X
Begrenzung der Eingabe bei 20 Zeichen.
OK
RS, 02.02.2010
X
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
X
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
Begrenzung der Eingabe bei 20 Zeichen.
OK
RS, 02.02.2010
X
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
X
Eingabe i.O., keine Fehlermeldung
Begrenzung der Eingabe bei 20 Zeichen.
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
Eingabe i.O., keine Fehlermeldung
OK
RS, 02.02.2010
X
Fehlermeldung:
Die eingegebene Zeichenfolge ist nicht korrekt!
OK
RS, 02.02.2010
Pflichtfeld
X
Fehlermeldung:
Das Feld "Zeichen" darf nicht leer sein!
OK
RS, 02.02.2010
Korrekte Eingabe
aber zu spät
Die Captcha-Graphiken
sind für max. 5min gültig.
X
Fehlermeldung:
Die eingegebene Zeichenfolge ist nicht korrekt!
OK
RS, 02.02.2010
Alle
Button Senden
Alle Felder enthalten gültige und korrekte Eingabedaten
X
Newsletter-Empfänger wird in Datenbank gespeichert, Weiterleitung zum Formular Auswahl Lernende.
OK
RS, 02.02.2010
Alle
Button Abbrechen
Feldinhalte egal
X
Newsletter-Empfänger wird nicht in Datenbank gespeichert, Weiterleitung zur Loginseite.
OK
RS, 02.02.2010
X
X
X
Tabelle 16: Test Registrierungsformular
Remo Seiler, MAS-07-02
Seite 85 von 124
4.6
Abnahmetests
In der Anforderungsspezifikation [dok2] wurden die Abnahmekriterien für das Projekt GradeBook festgelegt. Diese Abnahmekriterien mussten aufgrund des Projektverlaufs und der Tatsache, dass deutlich mehr Soll- und Kann-Ziele umgesetzt werden konnten als geplant ergänzt, überarbeitet und zusammengefasst werden. Dieses Kapitel umfasst nun die definitiven Abnahmetests.
Die Tests dieses Kapitels dienen dazu bei der Projektabnahme zu zeigen, dass die geforderten Funktionalitäten umgesetzt wurden. Die Tests dienen nicht mehr dazu Fehler zu finden
und umfassen dementsprechend nicht mehr alle möglichen Fehlerfälle, resp. die Fehlerfälle
wurden zum Teil stark zusammengefasst. Detailliertere Tests mit Test-Äquivalenzklassen für
die Fehlerfälle sind wie erwähnt in den vorangehenden Kapiteln (z.B. bei den Tests der Eingabe-Formulare) zu finden.
In den Tabellen der nachfolgenden Kapitel, sind jeweils die zugehörigen Anforderungen aus
[dok2] (Spalte AF), die neuen Test-Identifikationsnummern (Spalte TID) und die Testfälle aus
der Anforderungsspezifikation (Spalte SRS) dargestellt. Somit können die Überarbeitungen,
Zusammenfassungen und Änderungen nachvollzogen werden. Zu jedem Test werden auch
die entsprechende Ausgangslage, das auslösende Ereignis und die erwarteten Resultate
angegeben. In der Spalte Res wir das Resultat angegeben (OK oder Fehlergrad 1-3, siehe
auch [dok2]), letzteres erfolgt während der Abnahme durch den Betreuer und den Experten
der Master Thesis und wird anschliessend hier dokumentiert.
4.6.1
Testablauf
Die Abnahmetests können in der (durch den Tabellenaufbau) spezifizierten Reihenfolge
durchgeführt werden. Einzige Ausnahme bilden die Testfälle zum Login-Vorgang (Kapitel
4.6.5) die sinnvollerweise auch vorgezogen werden können. Die Resultate können grösstenteils direkt im Browser überprüft werden. In einigen Fällen muss der Zugriff auf die Datenbank oder der Zugriff auf ein Email-Konto eines Testbenutzers möglich sein, um die Resultate komplett verifizieren zu können.
Für die Tests stehen zwei spezielle Testbenutzer zur Verfügung die im ADS zu diesem
Zweck erfasst wurden (Passwort wird separat geliefert):
Testbenutzer Informatik-Berufsbildner (Benutzername = inf-aus-gb)
Testbenutzer Elektronik-Lernender (Benutzername = elo-stu-gb)
Die Testbenutzer bleiben bis zum Beginn der Betatest-Phase im ADS erhalten, anschliessend werden sie gelöscht. Für Tests mit mehreren Benutzern, stehen ebenfalls in diesem
Zeitrahmen die Benutzer aus den Testdaten (echte ADS-Benutzer) zur Verfügung. Für die
Verwendung letzterer muss aber eine Modifikation im Source-Code vorgenommen werden,
da die Passwörter nicht zugänglich sein dürfen. Die Modifikation wird vorgenommen indem
im Controller Login die Testvariablen (Kapitel 2.3.2.1) folgendermassen gesetzt werden.
private $_TestOhneLdap = false;
private $_TestNurAktive = false;
private $_TestPasswort = 'gb1234';
Die Benutzer können sich dann mit korrektem Benutzernamen und dem Testpasswort anmelden. Diese Funktion wird nach der Testphase aus dem Source-Code entfernt.
Remo Seiler, MAS-07-02
Seite 86 von 124
4.6.2
AF
Benutzer Lernender
TID
SRS
Ausgangslage, Beschreibung
Ereignis / Input
Erwartete Resultate
Res
Tester, Datum
OK
P. Aebi
16.02.10
Semesterübersicht anzeigen
LUC.01
FA.01-06
LUC.02
FA.03
LUC.03
FA.01
LUC.07
FA.01
LUC.01
FA.01-02
TA.01
T01
T04
T05
T09
T10
Dem aktuellen Semester sind
Fächer zugeordnet und in allen
Fächern sind Noten erfasst
Auswahl Semesterübersicht
(Navigation über Menu, Login, Positions-Navigation oder Zurück/BeendenButtons)
TA.02
T02
Dem aktuellen Semester sind
keine Fächer zugeordnet
Auswahl Semesterübersicht
(Navigation über Menu, Login oder
Positions-Navigation)
Anzeige einer entsprechenden Meldung
OK
P. Aebi
16.02.10
TA.03
T03
T06
In mindestens einem Fach sind
noch keine Noten erfasst.
Auswahl Semesterübersicht
(Navigation über Menu, Login oder
Positions-Navigation)
Anzeige der Semesterübersicht (wie zu T01). Das Fach ohne
Noten wird angezeigt, aber mit Leeren Spalten für Einzelnoten und
Durchschnitt.
OK
P. Aebi
16.02.10
TA.04
T08
Die Semesterübersicht zu Semester #3 wird angezeigt.
Auswahl des vorherigen Semesters #2
(klicken auf „<“ )
Anzeige der Semesterübersicht Semester #2 (siehe auch Resultat
T01).
OK
P. Aebi
16.02.10
Anzeige eines Bearbeitungsformulars für Semester #2.
In der Auswahlliste „Zur Auswahl stehen“ sind nur die Fächer
der eigenen Berufsgrupe angezeigt.
OK
P. Aebi
16.02.10
Anzeige Semesterübersicht
(Tabelle mit Fächern pro Zeile, Einzelnoten und Durchschnittsnoten).
Die Fachnamen werden als Link angezeigt.
Alle Noten mit Wert <4 werden in roter Farbe dargestellt.
GradeBook berechnet pro Fach die Durchschnittsnote und
zeigt diese in einer eigenen Spalte an.
Im Titel wird die Semesternummer angezeigt
Im Titel wird eine Navigationsmöglichkeit (Semester) angeboten
Unter der Fächer/Noten-Tabelle wird ein Button „Semester
bearbeiten…“ angezeigt.
Semester bearbeiten (Fächer hinzufügen und entfernen)
LUC.03
FA.01
TA.05
T11
Die Semesterübersicht zu Semester #2 wird angezeigt.
Button „Semester bearbeiten…“
LUC.03
FA.02
TA.06
T12
Das Bearbeitungsformular für
Semester #2 wird angezeigt.
Auswahl eines Fachs aus der Liste
„Zur Auswahl stehen“ und bestätigen
mit Button „>“ (hinzufügen)
Anzeige des Bearbeitungsformulars für Semester #2, in der Liste
„Bereits hinzugefügte Fächer“ ist das neue Fach enthalten.
OK
P. Aebi
16.02.10
LUC.03
FA.04
TA.07
T13
Das Bearbeitungsformular für
Semester #2 wird angezeigt.
Auswahl eines Fachs aus der Liste
“Bereits hinzugefügte Fächer“ und
bestätigen mit Button „<“ (entfernen)
Ein Bestätigungsformular für den Löschvorgang mit Hinweis auf
das allfällige Löschen aller Noten zu dem gewählten Fach wird
angezeigt.
OK
P. Aebi
16.02.10
TA.08
T14
Ein Bestätigungsformular für
das Entfernen des gewählten
Fachs wird angezeigt (Siehe
TA.07).
Bestätigung des Vorgangs durch klicken des Buttons „Entfernen“
OK
P. Aebi
16.02.10
Remo Seiler, MAS-07-02
Anzeige des Bearbeitungsformulars für Semester #2
In der Liste „Bereits hinzugefügte Fächer“ ist das entferne
Fach nicht mehr enthalten.
Alle erfassten Noten des entfernten Fachs sind aus der Datenbank gelöscht.
Seite 87 von 124
TA.09
T15
Ein Bestätigungsformular für
das Entfernen des gewählten
Fachs wird angezeigt (Siehe
TA.07).
Abbrechen des Vorgangs durch klicken
des Buttons „Abbrechen“
Anzeige des unveränderten Bearbeitungsformulars für Semester
#2.
OK
P. Aebi
16.02.10
Noten anzeigen und verwalten (hinzufügen, ändern, löschen) inkl. Fach auswählen
LUC.01
FA.08
LUC.04
FA.01
LUC.05
FA.01
LUC.06
FA.01
LUC.07
FA.02-03
TA.10
T07
T18
T26
T36
T41
T43
Die Semesterübersicht zu Semester #2 wird angezeigt.
Auswahl eines Fachs zu dem bereits
ein oder mehrere Noten erfasst wurden
durch klicken auf den Fachnamen
Anzeige Notenübersicht
In einer Tabelle werden pro Note der Wert, das Notengewicht,
der Notentyp und der Erfassungszeitpunkt angezeigt.
Pro Note wird ein Symbol „Bearbeiten“ angezeigt.
Pro Note wird ein Symbol „Löschen“ angezeigt.
Im Titel wird der Fachnamen, die Fachinstitution und die
Semesternummer angezeigt
Unter der Noten-Tabelle wird ein Button „Note hinzufügen…“
und ein Button „Zurück“ angezeigt.
OK
P. Aebi
16.02.10
TA.11
T27
T37
T42
Die Semesterübersicht zu Semester #2 wird angezeigt.
Auswahl eines Fachs zu dem noch
keine Noten erfasst wurden durch
klicken auf den Fachnamen
Anzeige Notenübersicht
Ein Hinweis, dass noch keine Noten erfasst wurden wird
angezeigt.
Im Titel wird der Fachnamen, die Fachinstitution und die
Semesternummer angezeigt
Unter dem Hinweis wird ein Button „Note hinzufügen…“ und ein
Button „Zurück“ angezeigt.
OK
P. Aebi
16.02.10
LUC.04
FA.01-02
TA.12
T19
Die Notenübersicht zum gewählten Fach wird angezeigt (siehe
TA.10)
Auswahl „Note hinzufügen…“
Anzeige Noten-Eingabeformular mit Eingabefeld, zwei Auswahlfeldern (Notengwicht und Notentyp) und zwei Buttons („Speichern“
und „Abbrechen“).
OK
P. Aebi
16.02.10
LUC.04
FA.02-05
TA.13
T19
T20
T24
Das Noten-Eingabeformular
zum gewählten Fach wird angezeigt (siehe TA.12).
Eingabe eines gültigen Notenwertes,
Auswahl eines Gewichts und eines
Notentyps. Bestätigen der Eingabe mit
Button „Speichern“
Die Note wird mit Wert, Notengewicht, Notentyp und Zeitstempel in der Datenbank gespeichert.
Die Notenübersicht zum gewählten Fach wird angezeigt (die
neue Note ist enthalten).
OK
P. Aebi
16.02.10
TA.14
T21
T22
T23
Das Noten-Eingabeformular
zum gewählten Fach wird angezeigt (siehe TA.12).
Eingabe eines ungültigen Notenwerts.
Bestätigen der Eingabe mit Button
„Speichern“
Das Noten-Eingabeformular wird mit einer Fehlermeldung
angezeigt.
Der bereits eingegebene Notenwert bleibt im Eingabefeld
erhalten.
OK
P. Aebi
16.02.10
LUC.04
FA.07
TA.15
T25
Das Noten-Eingabeformular
zum gewählten Fach wird angezeigt (siehe TA.12).
Eingabe eines gültigen Notenwertes,
Auswahl eines Gewichts und eines
Notentyps. Abbrechen der Eingabe mit
Button „Abbrechen“
Die Eingaben werden nicht in der Datenbank gespeichert.
Die unveränderte Notenübersicht zum gewählten Fach wird
angezeigt.
OK
P. Aebi
16.02.10
LUC.05
FA.01
TA.16
-
Die Notenübersicht zum gewählten Fach wird angezeigt (siehe
TA.10)
Auswahl „Note bearbeiten“ durch
klicken des entsprechenden Symbols
einer Note.
Noten-Eingabeformular wird angezeigt (siehe TA.12).
Das Eingabefeld beinhaltet den bereits erfassten Notenwert.
Die Auswahlfelder sind mit den Werten der bereits erfassten
Noten eingestellt.
OK
P. Aebi
16.02.10
Remo Seiler, MAS-07-02
Seite 88 von 124
TA.17
T28
T29
T33
T35
Eine Note wurde zum Bearbeiten ausgewählt. Das NotenEingabeformular zu der gewählten Note wird angezeigt (siehe
TA.12).
Änderung des Notenwerts auf einen
neuen gültigen Notenwert, Auswahl
eines neuen Notengewichts und eines
neuen Notentyps. Bestätigen der Eingabe mit Button „Speichern“
Die geänderte Note wird mit neuem Wert, neuem Notengewicht, neuem Notentyp und altem Zeitstempel in der Datenbank gespeichert.
Die Notenübersicht zum gewählten Fach wird angezeigt (Die
geänderte Note wird anstelle der alten angezeigt).
OK
P. Aebi
16.02.10
TA.18
T30
T31
T32
Eine Note wurde zum Bearbeiten ausgewählt. Das NotenEingabeformular zu der gewählten Note wird angezeigt (siehe
TA.12).
Änderung des Notenwerts auf einen
neuen ungültigen Notenwert, Auswahl
eines neuen Notengewichts und eines
neuen Notentyps. Bestätigen der Eingabe mit Button „Speichern“
Das Noten-Eingabeformular wird mit einer Fehlermeldung
angezeigt.
Der bereits geänderte Notenwert bleibt im Eingabefeld erhalten.
OK
P. Aebi
16.02.10
LUC.05
FA.06
TA.19
T34
Eine Note wurde zum Bearbeiten ausgewählt. Das NotenEingabeformular zu der gewählten Note wird angezeigt (siehe
TA.12).
Änderung des Notenwerts auf einen
neuen gültigen Notenwert, Auswahl
eines neuen Notengewichts und eines
neuen Notentyps. Abbrechen der
Eingabe mit Button „Abbrechen“
Die Eingaben werden nicht in der Datenbank gespeichert.
Die unveränderte Notenübersicht zum gewählten Fach wird
angezeigt.
OK
P. Aebi
16.02.10
LUC.06
FA.02
TA.20
T38
Die Notenübersicht zum gewählten Fach wird angezeigt (siehe
TA.10)
Auswahl „Note Löschen“ durch klicken
des entsprechenden Symbols einer
Note.
OK
P. Aebi
16.02.10
TA.21
T39
Ein Bestätigungsformular für
das Löschen einer Note wird
angezeigt (siehe TA.20).
Bestätigung des Vorgangs durch klicken des Buttons „Löschen“
Die Note wird aus der Datenbank gelöscht.
Die Notenübersicht zum gewählten Fach wird angezeigt (die
gelöschte Note ist nicht mehr enthalten).
OK
P. Aebi
16.02.10
TA.22
T40
Ein Bestätigungsformular für
das Löschen einer Note wird
angezeigt (siehe TA.20).
Abbrechen des Vorgangs durch klicken
des Buttons „Abbrechen“
Die Note wird nicht aus der Datenbank gelöscht.
Die unveränderte Notenübersicht zum gewählten Fach wird
angezeigt.
OK
P. Aebi
16.02.10
TA.23
T44
T45
Im Navigationsmenu wird ein
Link „Bericht erstellen“ angezeigt.
Mindestens eine Note ist erfasst
(impliziert, das mindestens ein
Fach einem Semester zugeteilt
wurde).
Auswahl „Bericht erstellen“ im Navigationsmenu.
GradeBook generiert einen Bericht als PDF-Datei.
Der Bericht wird zum Download angeboten.
Im Bericht sind die persönlichen Daten des Lernenden enthalten.
Im Bericht ist die Semesterübersicht des aktuellen Semesters
enthalten.
Im Bericht ist die Übersicht über alle Semester, alle Institutionen und alle Fächer enthalten.
OK
P. Aebi
16.02.10
TA.24
T46
Im Navigationsmenu wird ein
Link „Bericht erstellen“ angezeigt.
Es wurden noch keine Noten
erfasst aber bereits mindestens
ein Fach einem Semester zugeordnet.
Auswahl „Bericht erstellen“ im Navigationsmenu.
GradeBook generiert einen Bericht als PDF-Datei.
Der Bericht wird zum Download angeboten.
Im Bericht sind die persönlichen Daten des Lernenden enthalten.
Im Bericht ist die Semesterübersicht des aktuellen Semesters
mit dem Hinweis „Keine Daten vorhanden“ enthalten.
Im Bericht ist die leere Übersichtstabelle über alle Semester,
alle Institutionen und alle Fächer enthalten.
OK
P. Aebi
16.02.10
LUC.05
FA.02-05
LUC.05
FA.07
Ein Bestätigungsformular für den Löschvorgang wird angezeigt.
Bericht erstellen
LUC08
FA.01-02
Remo Seiler, MAS-07-02
Seite 89 von 124
TA.25
-
m Navigationsmenu wird ein
Link „Bericht erstellen“ angezeigt.
Es wurden noch keine Noten
erfasst und noch keinem Semester ein Fach zugeordnet.
Auswahl „Bericht erstellen“ im Navigationsmenu.
GradeBook generiert einen Bericht als PDF-Datei.
Der Bericht wird zum Download angeboten.
Im Bericht sind die persönlichen Daten des Lernenden enthalten.
Im Bericht ist die Semesterübersicht des aktuellen Semesters
mit dem Hinweis „Keine Daten vorhanden“ enthalten.
Die Übersicht über alle Semester ist im Bericht nicht enthalten.
OK
P. Aebi
16.02.10
Die Semesterübersicht wird angezeigt (siehe TA.01).
Ein Informationsbalken „Monatsabschluss ist in/seit X Tagen
fällig“ wird angezeigt.
Im Informationsbalken wird ein Button „Monat abschliessen…“
angezeigt.
OK
P. Aebi
16.02.10
Anzeige Formular Monatsabschluss.
Das Monatsabschluss-Formular mit Auswahlmöglichkeit für
„Alle Noten eingegeben“ und „Keine Noten erhalten“ wird angezeigt.
Im Formular werden alle Newsletter-Empfänger des Lernenden angezeigt.
Zwei Buttons („Monat abschliessen“ und „Abbrechen“) werden
angezeigt.
OK
P. Aebi
16.02.10
OK
P. Aebi
16.02.10
Monatsabschluss
LUC.09
FA.01
TA.26
T47
Das aktuelle Datum ist weniger
als 7 Tage vor dem Monatsende. Der Monatsabschluss wurde
noch nicht getätigt.
XODER
Das aktuelle Datum ist nicht
weniger als 7 Tage vor dem
Monatsende aber der letzte
Monatsabschluss wurde noch
nicht getätigt.
Anmeldung am System oder Auswahl
„Semesterübersicht“ im Navigationsmenu
LUC.09
FA.02-04
LUC.10
FA.01
TA.27
T48
T49
Der Informationsbalken für den
fälligen Monatsabschluss wird
angezeigt (siehe TA.26)
Auswahl „Monat abschliessen…“
TA.28
T50
Das Formular Monatsabschluss
wird angezeigt (siehe TA.27)
Auswahl ob „Noten eingetragen“ oder
„keine erhalten“ und Bestätigen mit
Button „Monat abschliessen“
TA.29
-
Das Formular Monatsabschluss
wird angezeigt (siehe TA.27)
Auswahl ob „Noten eingetragen“ oder
„keine erhalten“ und Abbrechen mit
Button „Abbrechen“
Die Semesterübersicht (inkl. dem Informationsbalken für den Monatsabschluss) wird angezeigt.
OK
P. Aebi
16.02.10
TA.30
-
Das Formular Monatsabschluss
wird angezeigt (siehe TA.27)
Auswahl fehlt und Bestätigen mit Button „Monat abschliessen…“
Das Formular Monatsabschluss wird mit einer Fehlermeldung
(„Bitte wählen Sie eine der Optionen...“) angezeigt.
OK
P. Aebi
16.02.10
GradeBook generiert einen Bericht für den Lernenden.
GradeBook generiert ein Newsletter-Mail mit dem Bericht als
Anhang und versendet dieses an alle Newsletter-Empfänger
des Lernenden.
Anzeige der Semesterübersicht, der Informationsbalken für
den Monatsabschluss wird nicht mehr angezeigt.
Tabelle 17: Abnahmetests zu Benutzer Lernender
Remo Seiler, MAS-07-02
Seite 90 von 124
4.6.3
AF
Benutzer Berufsbildner
TID
SRS
Ausgangslage, Beschreibung
Ereignis / Input
Erwartete Resultate
Res
Tester, Datum
OK
P. Aebi
16.02.10
Übersicht eigene Lernende anzeigen
BUC.01
FA.01-02
BUC.01
FA.05
TA.31
T51
T52
Dem Berufsbildner sind Lernende zugeteilt.
Auswahl „Meine Lernenden“
(Navigation über Menu, Login, Positions-Navigation oder Zurück/BeendenButtons)
TA.32
T53
Dem Berufsbildner sind keine
Lernenden zugeteilt.
Auswahl „Meine Lernenden“
(Navigation über Menu, Login, Positions-Navigation oder Zurück/BeendenButtons)
Anzeige einer entsprechenden Meldung.
OK
P. Aebi
16.02.10
Die Übersicht eigene Lernende
wird angezeigt (siehe TA.31).
Auswahl eines Lernenden durch klicken auf dessen Namen.
Der gewählte Lernende hat im aktuellen Semester mindestens eine Note
erfasst.
Zum gewählten Lernenden existiert
mindestens ein NewsletterAbonnement.
Anzeige Detailansicht Lernender. Die Anzeige beinhaltet:
Einen Button „Bericht erstellen“
Die Semesterübersicht des Lernenden (aktuelles Semester)
im gleichen Stiel wie bei TA.01. Im Titel der Semesterübersicht ist eine Navigationsmöglichkeit integriert.
Eine Tabelle mit allen Newsletter-Empfängern (Abonnemente) des Lernenden. Pro Zeile jeweils ein NewsletterEmpfänger mit Name, Firma und Email-Adresse und ein
Lösch-Symbol für diesen.
Unterhalb der NLE-Tabelle ein Button „Abonnement hinzufügen…“
Eine Tabelle mit detaillierten Informationen zum Lernenden
(Benutzername, Benutzergruppe, Berufsgruppe, Lehrstart,
letzter Login, Alarm-Status und Offene Newsletter-Anträge).
OK
P. Aebi
16.02.10
Die Übersicht eigene Lernende
wird angezeigt (siehe TA.31).
Auswahl eines Lernenden durch klicken auf dessen Namen.
Der gewählte Lernende hat im aktuellen Semester keine Noten erfasst und
zum Lernenden existiert kein Newsletter-Abonnement.
Anzeige Detailansicht Lernender wie in TA.33 aber statt Tabellen
für die Semesterübersicht und die Newsletter-Empfänger eine
Meldung (keine Daten vorhanden o.ä.) ausgegeben.
OK
P. Aebi
16.02.10
Anzeige Übersicht eigene Lernende (Tabelle mit Lernender
pro Zeile, Berufsgruppe, Lehrstart, Letzter Login, Alarme und
Offenen Newsletter-Anträgen).
Die Namen der Lernenden werden als Link angezeigt.
Unter der Lernenden-Tabelle wird ein Button „Meine Lernenden bearbeiten…“ angezeigt.
Details Lernender anzeigen
BUC.01
FA.03
BUC.02
FA.01
TA.33
TA.34
T54
T56
Remo Seiler, MAS-07-02
Seite 91 von 124
Liste eigene Lernende bearbeiten
BUC.01
FA.05
BUC.03
FA.06
BUC.03
FA.01-02
BUC.03
FA.04
(BUC.03
FA.05)
TA.35
T57
Die Übersicht eigene Lernende
wird angezeigt (siehe TA.31).
Es ist mindestens ein Lernender
in der GradeBook-Datenbank
erfasst.
Button „Meine Lernende bearbeiten…“
TA.36
T60
Die Übersicht eigene Lernende
wird angezeigt (siehe TA.31).
Es ist noch kein Lernender in
der GradeBook-Datenbank
erfasst.
Button „Meine Lernende bearbeiten…“
TA.37
T58
Das Bearbeitungsformular für
meine Lernende wird angezeigt
(siehe TA.35).
TA.38
-
TA.39
OK
P. Aebi
16.02.10
Anzeige des Bearbeitungsformulars für die Lernenden-Zuteilung
(siehe TA.35) aber mit zwei leeren Auswahllisten.
OK
P. Aebi
16.02.10
Auswahl einer oder mehrerer Lernende
aus der Liste „Alle Lernende“ und
bestätigen mit Button „>“ (hinzufügen)
Anzeige des Bearbeitungsformulars für die Lernenden-Zuteilung, in
der Liste „Ihre Lernende“ sind die neuen Lernenden enthalten (in
der Liste „Alle Lernenden“ nicht mehr).
Die neuen Zuteilungen sind in der Datenbank gespeichert.
OK
P. Aebi
16.02.10
Das Bearbeitungsformular für
meine Lernende wird angezeigt
(siehe TA.35).
Auswahl eines oder mehrerer Lernenden aus der Liste „Ihre Lernenden“
und bestätigen mit Button „<“ (entfernen)
Anzeige des Bearbeitungsformulars für die Lernenden-Zuteilung, in
der Liste „Ihre Lernende“ sind die entfernten Lernenden nicht mehr
enthalten (aber wieder in der Liste „Alle Lernenden“).
Die entsprechenden Zuteilungen sind aus der Datenbank gelöscht.
OK
P. Aebi
16.02.10
(T59)
Das Bearbeitungsformular für
meine Lernende wird angezeigt
(siehe TA.35).
Auswahl „Bearbeitung beenden“
Anzeige der Übersicht eigene Lernende (siehe TA.31). In der
Übersicht sind die neuen Lernenden vorhanden und die entfernten
nicht mehr.
OK
P. Aebi
16.02.10
T61
Die Detailansicht eines Lernenden wird angezeigt (siehe
TA.33)
Auswahl „Bericht erstellen“
GradeBook generiert zum Lernenden einen Bericht als PDF-Datei
und bietet ihn zum Download an (gleich wie in TA.23).
OK
P. Aebi
16.02.10
Anzeige der Übersicht über alle im System erfassten Newsletter-Empfänger in einer Tabelle.
In der Tabelle wird pro Zeile ein Newsletter-Empfänger angezeigt, mit Name, Firma, Email-Adresse, Anzahl NLAbonnemente, und Anzahl NL-Anfragen.
Pro Newsletter-Empfänger wird ein Symbol „Bearbeiten“ und
ein Symbol „Löschen“ angezeigt.
Unterhalb der Tabelle wird ein Button „Zurück“ und ein Button
„Newsletter-Empfänger erfassen…“ angezeigt.
OK
P. Aebi
16.02.10
Anzeige eines Bearbeitungsformulars für die LernendenZuteilung.
In der Auswahlliste „Alle Lernende“ sind alle in GradeBook
erfassten Lernenden, exklusive den bereits dem Berufsbildner
zugeteilten, sortiert nach Berufsgruppen/Namen aufgelistet.
In der Auswahlliste „Ihre Lernende“ Sind alle dem Berufsbildner zugeteilten Lernenden, sortiert nach Berufsgruppe und
Namen aufgelistet.
Ein Button „Bearbeitung beenden“ wird angezeigt.
Bericht erstellen
BUC.04
FA.01
TA.40
Newsletter-Empfänger verwalten
BUC.06
FA.01-06
TA.41
-
Die Übersicht eigene Lernende
oder eine beliebige andere Seite
des Berufsbildners wird angezeigt (siehe TA.31).
Remo Seiler, MAS-07-02
Auswahl „Newsletter-Empfänger“ im
Navigationsmenu
Seite 92 von 124
TA.42
-
Die Übersicht NewsletterEmpfänger wird angezeigt
(siehe TA.41)
Auswahl „NL-Empfänger löschen“
durch klicken des entsprechenden
Symbols eines NL-Empfängers.
TA.43
-
Ein Bestätigungsformular für
das Löschen eines NewsletterEmpfängers wird angezeigt
(siehe TA.42).
TA.44
-
TA.45
Ein Bestätigungsformular für den Löschvorgang wird angezeigt mit
Hinweisen auf die Konsequenzen eines Löschvorgangs (alle Abos,
Anfragen etc. werden gelöscht).
OK
P. Aebi
16.02.10
Bestätigung des Vorgangs durch klicken des Buttons „Löschen“
Der Newsletter-Empfänger, alle seine NewsletterAbonnemente und –Anfragen werden aus der Datenbank gelöscht.
Die Übersicht Newsletter-Empfänger wird angezeigt (der
gelöschte NL-Empfänger ist nicht mehr enthalten).
OK
P. Aebi
16.02.10
Ein Bestätigungsformular für
das Löschen eines NewsletterEmpfängers wird angezeigt
(siehe TA.42).
Abbrechen des Vorgangs durch klicken
des Buttons „Abbrechen“
Der Newsletter-Empfängerwird nicht aus der Datenbank
gelöscht.
Die unveränderte Übersicht Newsletter-Empfänger wird angezeigt.
OK
P. Aebi
16.02.10
-
Die Übersicht NewsletterEmpfänger wird angezeigt
(siehe TA.41)
Auswahl „Newsletter-Empfänger erfassen…“
Anzeige Eingabeformular für die Daten des NewsletterEmpfängers.
Das Formular beinhaltet Eingabefelder für Email, Anrede,
Name, Vorname, Firma, Strasse, PLZ, Ort, Telefon Geschäft,
Telefon Privat, Telefon Mobile und Bemerkungen.
Unterhalb des Formulars werden ein Button „Speichern“ und
ein Button „Abbrechen“ angezeigt.
Die Eingabefelder Email, Anrede, Name und Vorname sind
als Pflichtfelder markiert.
OK
P. Aebi
16.02.10
TA.46
-
Das Eingabeformular für die
Daten eines neuen NLEmpfängers wird angezeigt
(siehe TA.45).
Eingabe von gültigen Daten und bestätigen der Eingabe mit Button „Speichern“
Der NL-Empfänger wird mit allen eingegebenen Daten in der
Datenbank gespeichert.
Die Übersicht NL-Empfänger wird angezeigt (der neue Empfänger ist enthalten)
OK
P. Aebi
16.02.10
TA.47
-
Das Eingabeformular für die
Daten eines neuen NLEmpfängers wird angezeigt
(siehe TA.45).
Eingabe von ungültigen Daten und
bestätigen der Eingabe mit Button
„Speichern“. Ungültig heisst, es sind
nicht alle Pflichtfelder ausgefüllt, oder
das Format (z.B. Emailformat) in mindestens einem Feld ist falsch.
Das Eingabeformular wird mit einer oder mehreren Fehlermeldungen angezeigt.
Die bereits eingegebenen Daten bleiben erhalten.
OK
P. Aebi
16.02.10
TA.48
-
Das Eingabeformular für die
Daten eines neuen NLEmpfängers wird angezeigt
(siehe TA.45).
Eingabe von gültigen Daten und abbrechen der Eingabe mit Button „Abbrechen“
Die Eingaben werden nicht in der Datenbank gespeichert.
Die unveränderte Übersicht NL-Empfänger wird angezeigt.
OK
P. Aebi
16.02.10
TA.49
-
Die Übersicht NewsletterEmpfänger wird angezeigt
(siehe TA.41)
Auswahl „NL-Empfänger bearbeiten“
durch klicken des entsprechenden
Symbols eines NL-Empfängers.
Anzeige Eingabeformular für Daten NL-Empfänger (siehe
TA.45).
Die Eingabefelder beinhalteten die bereits erfassten Daten
des NL-Empfängers.
OK
P. Aebi
16.02.10
TA.50
-
Ein NL-Empfänger wurde zum
Bearbeiten ausgewählt. Das
Eingabeformular für die Daten
Gültige Änderung oder Ergänzung von
Daten des NL-Empfängers.
Bestätigen der Eingabe mit Button
Die neuen Daten des NL-Empfängers werden in der Datenbank gespeichert.
Die Übersicht NL-Empfänger wird angezeigt (die Daten des
OK
P. Aebi
16.02.10
Remo Seiler, MAS-07-02
Seite 93 von 124
des NL-Empfängers wird angezeigt (siehe TA.49).
„Speichern“
NL-Empfängers sind geändert.)
TA.51
-
Ein NL-Empfänger wurde zum
Bearbeiten ausgewählt. Das
Eingabeformular für die Daten
des NL-Empfängers wird angezeigt (siehe TA.49).
Ungültige Änderung oder Ergänzung
von Daten des NL-Empfängers.
Bestätigen der Eingabe mit Button
„Speichern“
Das Eingabeformular wird mit einer oder mehreren Fehlermeldungen angezeigt.
Die bereits eingegebenen Daten bleiben erhalten.
OK
P. Aebi
16.02.10
TA.52
-
Ein NL-Empfänger wurde zum
Bearbeiten ausgewählt. Das
Eingabeformular für die Daten
des NL-Empfängers wird angezeigt (siehe TA.49).
Gültige Änderung oder Ergänzung von
Daten des NL-Empfängers.
Abbrechen der Eingabe mit Button
„Abbrechen“
Die Änderungen oder Ergänzungen werden nicht in der Datenbank gespeichert.
Die unveränderte Übersicht NL-Empfänger wird angezeigt.
OK
P. Aebi
16.02.10
Newsletter-Abonnemente verwalten (hinzufügen oder löschen)
BUC.07
FA.01
TA.53
-
Die Detailansicht eines Lernenden wird angezeigt (siehe
TA.33)
Auswahl „Abonnement hinzufügen…“
Anzeige einer Tabelle mit allen erfassten NL-Empfängern, die
zum Lernenden noch kein NL-Abonnement besitzen.
Pro Tabellenzeile wird ein NL-Empfänger mit Name, Vorname, Firma und Email-Adresse angezeigt.
Pro NL-Empfänger wird eine Checkbox für dessen Auswahl
angezeigt.
OK
P. Aebi
16.02.10
BUC.07
FA.02
TA.54
-
Die Tabelle mit allen NLEmpfängern ohne NLAbonnement zum Lernenden
wird angezeigt (siehe TA.53).
Auswahl von ein oder mehreren NLEmpfängern durch aktivieren der entsprechenden Checkboxen.
Bestätigen der Auswahl durch klicken
des Button „Hinzufügen“
Die neuen Newsletter-Abonnemente werden in der Datenbank gespeichert.
Die Detailansicht des Lernenden wird angezeigt (in der Tabelle der Newsletter-Abonnemente sind die neuen Abonnemente
enthalten).
OK
P. Aebi
16.02.10
-
TA.55
-
Die Tabelle mit allen NLEmpfängern ohne NLAbonnement zum Lernenden
wird angezeigt (siehe TA.53).
Auswahl von ein oder mehreren NLEmpfängern durch aktivieren der entsprechenden Checkboxen.
Abbrechen des Vorgangs durch klicken
des Button „Abbrechen“
Es werden keine neuen Abonnemente gespeichert und die unveränderte Detailansicht des Lernenden wird wieder angezeigt.
OK
P. Aebi
16.02.10
BUC.07
FA.03
TA.56
T62
Die Detailansicht eines Lernenden wird angezeigt (siehe
TA.33)
Auswahl „NL-Abonnement löschen“
durch klicken des entsprechenden
Symbols eines NL-Empfängers.
Ein Bestätigungsformular für den Löschvorgang wird angezeigt.
OK
P. Aebi
16.02.10
BUC.07
FA.04
TA.57
T63
Ein Bestätigungsformular für
das Löschen eines NewsletterAbonnements wird angezeigt
(siehe TA.56).
Bestätigung des Vorgangs durch klicken des Buttons „Löschen“
Das Newsletter-Abonnement wird aus der Datenbank gelöscht.
Die Detailansicht Lernender wird angezeigt (das gelöschte
NL-Abonnement ist nicht mehr enthalten).
OK
P. Aebi
16.02.10
TA.58
T64
Ein Bestätigungsformular für
das Löschen eines NewsletterAbonnements wird angezeigt
(siehe TA.56).
Abbrechen des Vorgangs durch klicken
des Buttons „Abbrechen“
Das Newsletter-Abonnement wird nicht aus der Datenbank
gelöscht.
Die unveränderte Detailansicht Lernender wird angezeigt.
OK
P. Aebi
16.02.10
Remo Seiler, MAS-07-02
Seite 94 von 124
Newsletter-Antrag bestätigen
BUC.08
FA.01
BUC.08
FA.02-05
TA.59
T65
Es ist mindestens eine offene
NL-Anfrage zu Lernenden des
Berufsbildners vorhanden.
Im Navigationsmenu wird beim
Punkt „Newsletter-Anfragen“ die
Anzahl offener Anfragen angezeigt (in Klammern)
Auswahl „Newsletter-Anfragen“ im
Navigationsmenu.
TA.60
T66
Es sind keine offenen NLAnfragen zu Lernenden des
Berufsbildners vorhanden.
Auswahl „Newsletter-Anfragen“ im
Navigationsmenu.
TA.61
T67
Die Übersicht der offenen NLAnfragen wird angezeigt (siehe
TA.59)
TA.62
T68
(T69)
TA.63
TA.64
Anzeige einer Übersicht über alle offenen NL-Anfragen in
einer Tabelle.
Pro Tabellenzeile wird ein NL-Empfänger angezeigt der einen
oder mehrere Anträge gestellt hat.
Pro NL-Empfänger wird eine Liste mit Lernenden angezeigt
zu denen der NL-Empfänger eine NL-Anfrage gestellt hat mit
den zugehörigen Anfragezeiten.
Pro NL-Empfänger wird ein Button „Details…“ angezeigt.
Unter der Tabelle wird ein Button „Zurück zur Übersicht angezeigt“.
Anzeige einer entsprechenden Meldung.
OK
P. Aebi
16.02.10
OK
P. Aebi
16.02.10
Auswahl „Details…“ bei einem spezifischen NL-Empfänger
Detailanzeige zu der Anfrage / den Anfragen des gewählten NLEmpfängers mit folgenden Inhalten:
Persönliche Daten des Anfragestellers (NL-Empfänger)
Tabelle mit den einzelnen NL-Anfragen pro Zeile mit Namen
des Lernenden, Zeitpunkt der Anfragestellung, IP-Adresse
von der die Anfrage gestellt wurde und Checkboxen zur
Auswahl der einzelnen Anfragen
Unterhalb der Tabelle: Buttons „Auswahl bestätigen“, „Auswahl ablehnen“ und „Abbrechen“.
OK
P. Aebi
16.02.10
Detailanzeige der NL-Anfragen
eines NL-Empfängers wird
angezeigt (siehe TA.61)
Auswahl von ein oder mehreren Anfragen durch aktivieren der entsprechenden Checkboxen und bestätigen der
Anfragen durch klicken des Buttons
„Auswahl bestätigen“.
GradeBook löscht die Newsletter-Anfragen und speichert die
neuen Newsletter-Abonnemente in der Datenbank.
Anzeige der Übersicht über alle offenen NL-Anfragen (siehe
TA.65). Die bestätigten Anfragen werden nicht mehr angezeigt.
OK
P. Aebi
16.02.10
T70
Detailanzeige der NL-Anfragen
eines NL-Empfängers wird
angezeigt (siehe TA.61)
Auswahl von ein oder mehreren Anfragen durch aktivieren der entsprechenden Checkboxen und ablehnen der
Anfragen durch klicken des Buttons
„Auswahl ablehnen“.
OK
P. Aebi
16.02.10
T71
Ein Bestätigungsformular für
das Ablehnen einer NL-Anfrage
wird angezeigt.
Ablehnung bestätigen durch klicken
des Buttons „Bestätigen“
OK
P. Aebi
16.02.10
Remo Seiler, MAS-07-02
Ein Bestätigungsformular für das Ablehnen wird angezeigt.
GradeBook löscht die Newsletter-Anfragen aus der DB.
GradeBook generiert ein Informations-Mail zur Ablehnung
und versendet es an den NL-Empfänger.
Anzeige der Übersicht über alle offenen NL-Anfragen (siehe
TA.65). Die abgelehnten Anfragen werden nicht mehr angezeigt.
Seite 95 von 124
TA.65
T72
Ein Bestätigungsformular für
das Ablehnen einer NL-Anfrage
wird angezeigt.
Vorgang abbrechen durch klicken des
Buttons „Abbrechen“
GradeBook löscht die Newsletter-Anfragen aus der DB.
GradeBook generiert ein Informations-Mail zur Ablehnung
und versendet es an den NL-Empfänger.
Anzeige der Übersicht über alle offenen NL-Anfragen (siehe
TA.65). Die abgelehnten Anfragen werden nicht mehr angezeigt.
OK
P. Aebi
16.02.10
Tabelle 18: Abnahmetests zu Benutzer Berufsbildner
4.6.4
AF
Benutzer Newsletter-Empfänger oder beliebige Person
TID
SRS
Ausgangslage, Beschreibung
Ereignis / Input
Erwartete Resultate
Res
Tester, Datum
Newsletter-Abonnement beantragen
NUC.01
FA.01
TA.66
T73
Die GradeBook-Seite wurde
aufgerufen und die Login-Seite
wird angezeigt.
Auswahl „Newsletter beantragen“
Anzeige eines Formulars zur Eingabe der Email-Adresse mit einem
Button „Senden“ und einem Button „Abbrechen“.
OK
P. Aebi
16.02.10
NUC.01
FA.02-06
TA.67
-
Das Formular zur Eingabe der
Email-Adresse wird angezeigt.
Eingabe einer ungültigen EmailAdresse (Format).
Das Eingabeformular wird, ergänzt mit einer Fehlermeldung, erneut
angezeigt. Die bereits eingegebenen Daten bleiben erhalten.
OK
P. Aebi
16.02.10
TA.68
-
Das Formular zur Eingabe der
Email-Adresse wird angezeigt.
Eingabe einer gültigen Email-Adresse
und Auswahl „Abbrechen“.
Die Login-Seite wird angezeigt.
OK
P. Aebi
16.02.10
TA.69
T75
Das Formular zur Eingabe der
Email-Adresse wird angezeigt.
Eingabe einer gültigen Email-Adresse,
für die bereits ein NL-Empfänger erfasst ist und bestätigen durch klicken
auf den Button „Senden“.
Anzeige der Übersicht aller Lernenden in einer Tabelle.
Pro Tabellenzeile ist ein Lernender mit Name, Vorname,
Berufsgruppe, Lehrstart und Firma angezeigt.
Wenn zu einem Lernenden noch kein NL-Abonnement und
keine NL-Anfrage des NL-Empfängers existieren, wird eine
Checkbox für die Auswahl des Lernenden angezeigt.
Unterhalb der Tabelle befindet sich ein Button „Newsletter
beantragen…“ und ein Button „Abbrechen“.
OK
P. Aebi
16.02.10
TA.70
T74
Das Formular zur Eingabe der
Email-Adresse wird angezeigt.
Eingabe einer gültigen Email-Adresse,
für die noch kein NL-Empfänger erfasst
ist und bestätigen durch klicken auf den
Button „Senden“.
Anzeige Registrierungsformular für die persönlichen Daten.
Das Formular beinhaltet Eingabefelder für Email, Anrede,
Name, Vorname, Firma, Strasse, PLZ, Ort, Telefon Geschäft,
Telefon Privat und Telefon Mobile.
Im Eingabefeld Email ist die im vorherigen Formular eingegebene Email-Adresse bereits enthalten.
Das Formular beinhaltet eine automatisch generierte
Captcha-Graphik und ein Eingabefeld Zeichen für die Eingabe der Captcha-Zeichen.
Unterhalb des Formulars werden ein Button „Daten senden“
und ein Button „Abbrechen“ angezeigt.
Die Eingabefelder Email, Anrede, Name, Vorname, Firma,
Strasse, PLZ, Ort, Telefon Geschäft und Zeichen (Captcha)
sind als Pflichtfelder markiert.
OK
P. Aebi
16.02.10
Remo Seiler, MAS-07-02
Seite 96 von 124
NUC.01
FA.07-10
TA.71
T76
Das Registrierungsformular wird
angezeigt (siehe TA.70).
Eingabe gültiger Daten in allen Feldern
(alle Pflichtfelder sind ausgefüllt und
haben ein korrektes Format, die Captcha-Zeichen sind korrekt).
GradeBook speichert den neuen NL-Empfänger mit den
eingegebenen Daten in der Datenbank.
Anzeige der Übersicht aller Lernenden (siehe TA.69).
OK
P. Aebi
16.02.10
TA.72
T77
Das Registrierungsformular wird
angezeigt (siehe TA.70).
Eingabe von ungültigen Daten in ein
oder mehreren Felder, nicht alle Pflichtfelder sind ausgefüllt oder die CaptchaZeichen sind nicht korrekt.
Das Registrierungsformular wird mit einer oder mehreren
Fehlermeldungen erneut angezeigt.
Die bereits eingegebenen Daten bleiben mit Ausnahme der
Captcha-Zeichen erhalten.
Eine neue Captcha-Graphik wurde erzeugt und wird dargestellt.
OK
P. Aebi
16.02.10
TA.73
T78
Die Übersicht aller Lernenden
wird angezeigt (siehe TA.69).
Auswahl von einem oder mehreren
Lernenden und Bestätigen durch klicken des Buttons „Newsletter beantragen…“.
GradeBook speichert die NL-Anfragen in der Datenbank.
GradeBook generiert für jeden Berufsbildner der sich einen
oder mehrere der ausgewählten Lernenden zugeteilt hat ein
Anfrage-Mail und versendet dieses.
Anzeige einer Bestätigungsseite mit Informationen zu den
gemachten Anfragen und einem Button „OK“
OK
P. Aebi
16.02.10
TA.74
-
Die Übersicht aller Lernenden
wird angezeigt (siehe TA.69).
Keine Auswahl getroffen oder mehr als
20min inaktiv (Session abgelaufen) und
Bestätigen durch klicken des Buttons
„Newsletter beantragen…“.
OK
P. Aebi
16.02.10
Die Übersicht aller Lernenden wird mit einer Fehlermeldung erneut
ausgegeben. Wenn die Session abgelaufen ist, muss der Benutzer
den Vorgang abbrechen (Button „Abbrechen“) und neu beginnen.
Tabelle 19: Abnahmetests zu Benutzer Newsletter-Empfänger
Remo Seiler, MAS-07-02
Seite 97 von 124
4.6.5
AF
Authentifizieren (über ADS)
TID
SRS
Ausgangslage, Beschreibung
Ereignis / Input
Erwartete Resultate
Res
Tester, Datum
Newsletter-Abonnement beantragen
MUC.01
FA.01
TA.75
T80
-
Die GradeBook-Seite wird aufgerufen
(www.gradebook.cornet.ch oder gradebook.cornet.ch).
Umleitung auf https://gradebook.cornet.ch (mit mod_rewrite)
für SSL und einheitliche URL.
Anzeige des Login-Formulars mit Eingabefeldern für Benutzername und Passwort.
OK
P. Aebi
16.02.10
MUC.01
FA.02-04
MUC.01
Fa.06
TA.76
T84
Das Login-Formular wird angezeigt (siehe TA.76). Ein Lernender loggt sich zum ersten Mal
ein.
Eingabe eines gültigen ADSBenutzernamens und des gültigen
Passworts durch einen Lernenden.
GradeBook prüft Benutzernamen und Passwort.
GradeBook liest alle gespeicherten Benutzerdaten aus dem
ADS und erstellt einen neuen Benutzer in der GradeBookDatenbank.
Für den neuen Benutzer wird in der Datenbank ein Lernender
und 8 Semester angelegt und der Lernende dem DefaultBerufsbildner zugeteilt.
Anzeige der Startseite des Lernenden (Semesterübersicht).
OK
P. Aebi
16.02.10
TA.77
T81
T86
Das Login-Formular wird angezeigt (siehe TA.76). Ein Berufsbildner loggt sich zum ersten
Mal ein.
Eingabe eines gültigen ADSBenutzernamens und des gültigen
Passworts durch einen Berufsbildner.
GradeBook prüft Benutzernamen und Passwort.
GradeBook liest alle gespeicherten Benutzerdaten aus dem
ADS und erstellt einen neuen Benutzer in der GradeBookDatenbank.
Für den neuen Benutzer wird in der Datenbank ein Berufsbildner angelegt
Anzeige der Startseite des Berufsbildners (Übersicht eigene
Lernende).
OK
P. Aebi
16.02.10
TA.78
-
Das Login-Formular wird angezeigt (siehe TA.76). Ein bereits
erfasster Lernender loggt sich
ein.
Eingabe eines gültigen ADSBenutzernamens und des gültigen
Passworts durch einen Lernenden.
GradeBook prüft Benutzernamen und Passwort.
GradeBook liest alle gespeicherten Benutzerdaten aus dem
ADS und aktualisiert den vorhandenen Benutzer.
Anzeige der Startseite des Lernenden (Semesterübersicht).
OK
P. Aebi
16.02.10
TA.79
-
Das Login-Formular wird angezeigt (siehe TA.76). Ein bereits
erfasster Berufsbildner loggt
sich ein.
Eingabe eines gültigen ADSBenutzernamens und des gültigen
Passworts durch einen Berufsbildner.
GradeBook prüft Benutzernamen und Passwort.
GradeBook liest alle gespeicherten Benutzerdaten aus dem
ADS und aktualisiert den vorhandenen Benutzer.
Anzeige der Startseite des Lernenden (Semesterübersicht).
OK
P. Aebi
16.02.10
TA.80
T82
T83
Das Login-Formular wird angezeigt (siehe TA.76).
Eingabe eines ungültigen ADSBenutzernamens oder eines ungültigen
Passworts durch einen Lernenden.
Leere Felder sind ebenfalls ungültig.
Erneute Anzeige des Login-Formulars mit einer entsprechenden
Fehlermeldung. Die Eingaben für den Benutzernamen bleiben
erhalten.
OK
P. Aebi
16.02.10
TA.81
T85
T87
T88
Das Login-Formular wird angezeigt (siehe TA.76).
Eingabe eines ungültigen ADSBenutzernamens oder eines ungültigen
Passworts durch einen Berufsbildner.
Erneute Anzeige des Login-Formulars mit einer entsprechenden
Fehlermeldung. Die Eingaben für den Benutzernamen bleiben
erhalten.
OK
P. Aebi
16.02.10
Tabelle 20: Abnahmetests zum Login-Vorgang (Authentifizieren)
Remo Seiler, MAS-07-02
Seite 98 von 124
5
Resultate
Dieses Kapitel beinhaltet eine Übersicht der Ziele, die im Rahmen der Master Thesis erreichten werden konnten. Die implementierten Inhalte werden mit den spezifizierten Anforderungen aus [dok2] verglichen und Abweichungen kommentiert. An dieser Stelle werden also die
Anforderungen verifiziert. Die vom Student vor der Abnahme durchgeführten Abnahmetests
sind in die Erkenntnisse mit eingeflossen.
5.1
Konventionen
Wie erwähnt werden in den nachfolgenden Unterkapiteln alle in [dok2] spezifizierten Anforderungen der Prioritätsstufen A bis C in Tabellen aufgelistet und mit dem implementierten
Funktionsumfang verglichen. Die Anforderungen der Prioritätsstufe D werden mit wenigen
Ausnahmen nicht aufgeführt, da deren Umsetzung für GradeBook Release 1 nicht in Betracht gezogen wurde. Die Ausnahmen beziehen sich auf D-Anforderungen, die während der
Entwicklung trotzdem umgesetzt wurden, weil sie in der Umsetzung trivial oder eine logische
Konsequenz anderer implementierter Inhalte waren.
Die in den Tabellen-Spalte ‚R‘ zur Festlegung der Zielerreichung verwendeten Symbole sind
folgendermassen zu interpretieren:

Komplett gemäss Anforderung implementiert und getestet.

Komplett gemäss Anforderung implementiert und getestet. Anforderung wurde aber in Absprache mit dem Auftraggeber leicht angepasst
oder korrigiert aufgrund von Erkenntnissen während der Entwicklungsphase.
()
Teilweise implementiert oder aufgrund angepasster Anforderung nicht
mehr nötig.
X
Nicht implementiert, Implementierung wird Teil des Release 2.
Die Anforderungen sind mit der in [dok2] festgelegten Identifikations-Nummer aufgeführt.
Ausserdem ist zu jeder Anforderung eine Kurzbeschreibung vorhanden um eine bessere
Übersicht und weniger Nachschlageaufwand zu gewährleisten. Die Prioritäten in der Spalte
P entsprechen jenen die in [dok2] festgelegt wurden. Die MUSS-Ziele der Master-Thesis
(Priorität A) sind zudem grün hinterlegt. In der Spalte Bemerkungen sind Hinweise zu Änderungen von Anforderungen oder Änderungen verwendeter Begriffe vermerkt.
5.2
Zielerreichung funktionale Anforderungen Lernender
In Tabelle 25 ist ersichtlich, dass alle Anforderungen bezüglich des Benutzers Lernender mit
Prioritäten A und B und einige mit Priorität C erreicht werden konnten.
Anforderung
Kurzbeschreibung
P
R
LUC.01 FA.01
LUC.01 FA.02
LUC.01 FA.03
LUC.01 FA.04
LUC.01 FA.05
LUC.01 FA.06
LUC.01 FA.07
Semesterübersichts-Tabelle
Noch keine Fächer erfasst
Einzelnoten pro Fach anzeigen
Darstellung der Noten
Darstellung ungenügende Note
Durchschnitt anzeigen
Lehrjahresdurchschnitt
A
A
A
C
B
A
C

 Hinweis statt leere Tabelle

 Gewichtete Note wird unterstrichen


Remo Seiler, MAS-07-02
Bemerkung
X
Seite 99 von 124
LUC.01 FA.08
LUC.01 FA.09
LUC.02 FA.01
LUC.02 FA.02
LUC.02 FA.03
LUC.03 FA.01
LUC.03 FA.02
LUC.03 FA.03
LUC.03 FA.04
LUC.03 FA.06
LUC.04 FA.01
LUC.04 FA.02
LUC.04 FA.03
LUC.04 FA.04
LUC.04 FA.05
LUC.04 FA.07
LUC.05 FA.01
LUC.05 FA.02
LUC.05 FA.03
LUC.05 FA.04
LUC.05 FA.05
LUC.05 FA.06
LUC.05 FA.07
LUC.06 FA.01
LUC.06 FA.02
LUC.07 FA.01
LUC.07 FA.02
LUC.07 FA.03
LUC.08 FA.01
LUC.08 FA.02
LUC.08 FA.03
LUC.09 FA.01
LUC.09 FA.02
LUC.09 FA.03
LUC.09 FA.04
LUC.10 FA.01
LUC.10 FA.02
Fach auswählen
Ordnung der Fächer (alphab.)
Anderes Semester wählen
Neu gew. Semester anzeigen
Semesternummer anzeigen
Link Semester bearbeiten
Fächer dem Sem. hinzufügen
A
C
A
A
A
A






A

Nur Fächer der eigenen Berufsg.
Fächer aus Sem. Löschen
Eigene Fächer definieren
Notenübersicht Fach anzeigen
Note eingeben
Noteneingabe ungültig -> Fehler
Notengewicht eingeben
Notentyp eingeben
C
A
C
A
A
A
B


D

Symbol Note bearbeiten
Note ändern / bearbeiten
Noteneingabe (ändern) prüfen
Noteneingabe (ändern) ungültig
Notengewicht ändern
Notentyp ändern
Änderung abbrechen
Änderung speichern
Symbol Note löschen
Bestätigung abfragen & löschen
Fach auswählen
Notenübersicht Fach anzeigen
Fach in Notenübersicht anzeigen
Link Bericht erstellen
Bericht (PDF) erstellen und in
neuem Browserfenster öffnen
Übersicht NLE und BB in Bericht
Info-Anzeige Monatsabschluss
Monatsabschluss tätigen
Liste mit Newsletter-Empfängern
Noten-Newsletter versenden
Noten-Newsletter versenden
Newsletter-Abonnement künden
A
B
B
B
B
D
A
B
A
A
A
A
A
C














C

C
A
A
B
A
A
C
X
Button statt Link
Institution nicht im Fachnamen sondern in Tabelle (BG nicht nötig)
X




Notentyp definierbar wird aber noch
nicht verwendet.
Siehe LUC.04 FA.05
Alter Zeitstempel bleibt (sinnvoller)
Button-Namen angepasst
Bericht wird zum Download angeboten (nicht in Browser geöffnet)





X
Tabelle 21: Vergleich Anforderungen – Resultate, Benutzer Lernender
Remo Seiler, MAS-07-02
Seite 100 von 124
5.3
Zielerreichung funktionale Anforderungen Benutzer
Die Tabelle 22 zeigt, dass auch für den Benutzer Berufsbildner sämtliche Anforderungen der
Prioritätsstufe A und B und einige der Stufe C erreicht werden konnten. Die Ausnahme bilden hier lediglich die beiden Anforderungen BUC.03 FA.04 und 05 welche aufgrund einer
Änderung der Anforderungen nicht mehr notwendig sind und deshalb nicht implementiert
werden mussten. Für die Anforderung BUC.08 FA.03 und 04 wurde während der Entwicklungsphase eine sinnvollere Lösung als die in der Anforderungsspezifikation [dok2] spezifizierte gefunden und umgesetzt.
Anforderung
Kurzbeschreibung
P
R
Bemerkung
BUC.01 FA.01
BUC.01 FA.02
BUC.01 FA.03
BUC.01 FA.04
BUC.01 FA.05
BUC.02 FA.01
Übersicht eigene Lernende
Weitere Informationen in Übers.
Lernenden auswählen
Filtern und sortieren
Button Lernende bearbeiten
Detailansicht Lernender
Eigene Lernende hinzufügen oder
entfernen
Mehrere Lernende gleichz. Ausw.
Auswahllisten filtern und sortieren
Zuteilung bestätigen
A
C
A
C
A
A



Alarmstatus noch nicht implementiert
A

C
C
A
A
A
C
C
C
C
C
C
C
C
C
B
B
B
B

()
( )














B

B
B


BUC.03 FA.01
BUC.03 FA.02
BUC.03 FA.03
BUC.03 FA.04
BUC.03 FA.05
BUC.03 FA.06
BUC.04 FA.01
BUC.06 FA.01
BUC.06 FA.02
BUC.06 FA.03
BUC.06 FA.04
BUC.06 FA.05
BUC.06 FA.06
BUC.07 FA.01
BUC.07 FA.02
BUC.07 FA.03
BUC.07 FA.04
BUC.08 FA.01
BUC.08 FA.02
BUC.08 FA.03
BUC.08 FA.04
BUC.08 FA.05
Zuteilung abbrechen
In DB sind keine Lernende erfasst
Bericht zu Lernendem erstellen
Neuen NL-Empfänger erfassen
Daten NL-Empfänger bearbeiten
NL-Empfänger löschen
Minimale Daten eingeben
Alle Daten eingeben
Syntax der Email-Adresse prüfen
NL-Abonnement hinzufügen
NL-Empfänger auswählen
NL-Abonnement löschen
Bestätigung NL-Abo. löschen
NL-Anträge abfragen
NL-Antrag bestätigen / ablehnen
NL-Abonnement speichern
NL-Empfänger speichern
Bestätigung bei Ablehnung + Mail
X


X
Nicht nötig da direkt gespeichert wird
Nicht nötig da direkt gespeichert wird
Hinweis statt leere Tabelle
Status (gem. BUC.06 FA07) n.impl.
Linknamen angepasst
Sinnvolleres Handling umgesetzt
(siehe auch Kapitel 2.3.4.4.3)
Wird schon beim Beantragen gesp.
Tabelle 22: Vergleich Anforderungen – Resultate, Benutzer Berufsbildner
5.4
Zielerreichung funktionale Anforderungen Newsletter-Empfänger
Obschon in dieser Kategorie keine Anforderungen der Priorität A spezifiziert wurden, konnten mit zwei Ausnahmen alle komplett umgesetzt werden (siehe Tabelle 23). Die zwei genannten Ausnahmen sind ebenfalls bereits teilweise implementiert.
Remo Seiler, MAS-07-02
Seite 101 von 124
Anforderung
Kurzbeschreibung
P
R
NUC.01 FA.01
NUC.01 FA.02
NUC.01 FA.03
NUC.01 FA.04
NUC.01 FA.05
NUC.01 FA.06
NUC.01 FA.07
NUC.01 FA.08
NUC.01 FA.09
NUC.01 FA.10
Link Newsletter beantragen
Email eingeben
Email-Syntax prüfen
Prüfen ob Email bereits registriert
Registrierung neuer NL-Empf.
Auswahlliste Lernende anzeigen
Newsletter-Anfrage speichern
Anfrage-Mails versenden
Anfrage-Bestätigung anzeigen
Fehlermeldungen
B
B
C
B
B
B
B
C
B
B





( )



( )
Bemerkung
RFC2822 obsoleted by RFC5322
Filtern noch nicht umgesetzt
Teilweise umgesetzt
Tabelle 23: Vergleich Anforderungen – Resultate, Benutzer NL-Empfänger
5.5
Zielerreichung funktionale Anforderungen mehrere Benutzergruppen
Alle Anforderungen die im Zusammenhang mit dem Login-Vorgang stehen wurden mit Priorität A spezifiziert. Es konnten alle Anforderungen umgesetzt und getestet werden. Bei der
Anforderung MUC.01 FA.03 musste aber ein Detail wegelassen werden, da die dazu benötigten Informationen im ADS des Berufsbildungscenters nicht für alle ADS-Benutzer erfasst
sind. MUC.01 FA.06 ist hier als Teilweise umgesetzt dargestellt, da eine Ausgabe von Fehlermeldungen im Sinne der Spezifikation gemäss den Erkanntnissen aus der Entwicklungsphase wenig Sinn machen würde (dem Benutzer sollten nicht System-Fehlermeldungen
ausgegeben werden). Fehler werden zwar behandelt, aber ignoriert.
Anforderung
Kurzbeschreibung
P
R
MUC.01 FA.01
MUC.01 FA.02
Loginformular anzeigen
Benutzer und Passwort prüfen
Benutzerdaten im ADS abfragen
und in GradeBook-DB speichern
Benutzer-Startseite anzeigen
Fehlermeldungen
A
A


A

A

A
( )
MUC.01 FA.03
MUC.01 FA.04
MUC.01 FA.06
Bemerkung
Information zur BBC-Klasse wird
noch nicht gespeichert.
Fehler werden nicht direkt ausgegeben.
Tabelle 24: Vergleich Anforderungen – Resultate, mehrere Benutzergruppen
5.6
Zielerreichung funktionale Anforderungen System
Die Anforderungen im Zusammenhang mit den automatisch zu versenden Erinnerungs- und
Alarm-Mails wurden aus Zeitgründen weggelassen und sind Teil des Release 2 von GradeBook.
Anforderung
Kurzbeschreibung
P
R
SUC.02 FA.01
SUC.02 FA.02
SUC.02 FA.03
SUC.03 FA.01
SUC.04 FA.01
Zykl. Monatsabschlüsse prüfen
Erinnerungsmail versenden
Alarmmail versenden
Erinnerungsmail generieren
Alarmmail generieren
B
B
B
B
B
X
X
X
X
X
Bemerkung
Tabelle 25: Vergleich Anforderungen – Resultate, System
Remo Seiler, MAS-07-02
Seite 102 von 124
5.7
Zielerreichung nicht funktionale Anforderungen
Wie in Tabelle 26 ersichtlich konnten die nicht funktionalen Anforderungen mit einer Ausnahme komplett umgesetzt werden. Dazu gilt es aber zu bemerken, dass nicht alle dieser
Anforderungen während der Projektzeit überprüfbar waren (markiert mit --). Die einen werden während der Betatest-Phase überprüft (Performanz und Verfügbarkeit) und die anderen
sind administrative Anforderungen (Liefergegenstände) die erst nach Abschluss der Arbeit
bestätigt werden können.
Anforderung
NFA.01
NFA.02
NFA.03
NFA.04
NFA.05
NFA.06
NFA.07
NFA.08
NFA.10
Kurzbeschreibung
Benutzer nur einmal gleichzeitig
am System angemeldet
100 Benutzer gleichzeitig
90% in PHP, XHTML, CSS, JS
Einfachheit
LDAP über SSL
LDAP DMZ -> LAN
Lauffähig auf BBCnet-Webserver
Browser min. MS Internet Explorer 7.0 und Mozilla Firefox 3.0
Verfügbarkeit 90%
P
A
A
A
A
A
A
A
B
D
NFA.17
NFA.18
Alle Anforderungen Prio. A erfüllt
Lieferung lauffähige Software
A
A
NFA.19
Liefergegenstände
A
NFA.20
Daten für nicht autorisierte Personen unzugänglich
A
NFA.12
NFA.13
NFA.14
NFA.15
NFA.16

-





A
Zeitpunkt Erinnerungs- und
Alarmmails
Deutsche Sprache
Keine maschinellen Zugriffe auf
Formulare
Session läuft nach 20min ab
Navigationsmenu
Intuitive Bedienung
NFA.11
R
B
A
D
A
A
-X






--
Bemerkung
Umgesetzt, wird aber in R2 wohl
wieder entfernt, da Nutzen klein.
Nicht getestet
100% erreicht
Schwer zu testen
Getestet mit MS Internet Explorer 8,
Mozilla Firefox 3.5.7, Opera 9.8,
Google Chrome 3.0.195.38, Safari
3.1.2 und Safari für iPhone.
Nicht getestet
Noch nicht umgesetzt
Wurde beim Registrierungsformular
für NLE mit Captcha-Graphik gelöst
Navigationsmenu links statt rechts
Von 5 unabhängigen Test-Benutzern
bestätigt.
Liefergegenstände werden geliefert
Tabelle 26: Vergleich Anforderungen – Resultate, nicht funktionale Anforderungen
Remo Seiler, MAS-07-02
Seite 103 von 124
6
Ausblick
In diesem Kapitel werden die noch zu erledigenden Arbeiten und der weitere Verlauf des
Projekts GradeBook (inkl. Release2 und der geplanten Testphase) beschrieben.
6.1
Offene Punkte
Einige Punkte sind nach der Entwicklung und den Tests während der Master Thesis MT-0702.16 noch offen. Nachfolgende Auflistung zeigt diese administrativen und technischen Arbeiten:
Für den Default-Berufsbildner muss im ADS noch ein neuer Benutzer erfasst werden.
Die Testbenutzer (inf-aus-gb und elo-stu-gb) werden per 1. März 2010 entfernt.
Für den Email-Account [email protected] muss eine automatische
Antwort auf allfällige Mails, mittels entsprechender Regel erstellt werden. Evtl. werden
auch alle Mails auf diese Adresse geblockt, da sie ausschliesslich als Absender der
GradeBook-Emails gedacht ist. -> Wird mit dem Verantwortlichen des Mailservers
geklärt.
Um zu testen ob wirklich alle ADS-Benutzer korrekt in GradeBook erfasst werden
können, sollte dies vor der Einführung des Tools im August 2010 geprüft werden. Es
muss dazu ein temporärer Softwareteil im Login-Controller programmiert werden um
alle Benutzer des ADS zu ermitteln und diese automatisch einzuloggen. So kann
überprüft werden, ob alle Benutzer im ADS GradeBook-konform (sprich mit den minimal notwendigen Feldern) erfasst sind.
Es muss noch überprüft werden, wie sich das System verhält, wenn ein Passwort eines ADS-Benutzers abgelaufen oder der Benutzer deaktiviert ist. Vermutung: Authentifizierung schlägt fehl, es wird keine entsprechende Meldung ausgegeben. Da dies
abhängig von der verwendeten open source-Library ist, muss der Sachverhalt aber
zuerst überprüft werden.
Es muss geprüft werden, was mit den GradeBook-Cookies beim Client geschieht,
falls gleichzeitig und auf demselben Client eine andere Applikation auf dem Webserver gestartet wird, die ebenfalls mit Sessions arbeitet (z.B. die Intranet-Seite cornet.ch oder die Moodle-Applikationen).
Aus Sicherheitsgründen soll noch analysiert werden, ob eine Verschlüsselung des
GradeBook-Cookies, trotz der Tatsache, dass die Session-Daten in der Datenbank
abgelegt werden, notwendig ist. Das Cookie beinhaltet lediglich die Session-ID.
Sämtliche Texte die auf den Webseiten ausgegeben werden müssen noch einer orthographischen und sprachlichen Überprüfung unterzogen werden.
6.2
Verbesserungsmöglichkeiten
Während der Entwicklungsphase sind verschiedene Verbesserungs- und Optimierungsmöglichkeiten für die Applikation erkannt worden. Diese waren zwar für die Erreichung der spezifizierten Anforderungen nicht zwingend umzusetzen, sollen aber in Release 2 von GradeBook genauer analysiert und gegebenenfalls realisiert werden. Die nachfolgende Auflistung
zeigt die entsprechenden Erkenntnisse:
In der Semesterübersicht des Lernenden könnte die Tabelle auch auf mehrere Tabellen abhängig der Institutionen aufgeteilt werden um die Übersicht zu verbessern.
Remo Seiler, MAS-07-02
Seite 104 von 124
Die Erzeugung der Semesterübersichts-Tabelle sollte in eine eigene Methode (z.B. in
einem Helper oder in einem Model) ausgelagert werden, da sie an mehreren Stellen
benötigt wird.
Für die Erzeugung der Auswahllisten in der Semester-bearbeiten-Methode, könnte
eine Datenbankabfrage, anstelle der verschachtelten Foreach-Schleifen verwendet
werden um die Effizienz zu erhöhen.
Die genannten Auswahllisten müssen noch für lange Fächernamen optimiert werden.
Dazu wird ein horizontaler Scroll-Balken benötigt (existieren in HTML nicht).
Datenbankabfragen sollten allgemein noch bezüglich Geschwindigkeit, Wartbarkeit
und Ressourcenbedarf optimiert werden (z.B. durch Views)
Die Auswahllisten unter Semester bearbeiten (Lernender) und Meine Lernenden bearbeiten (Berufsbildner) könnten mittels Ajax-Funktionalitäten gelöst werden um die
Belastung von Server und Datenbank durch viele Zugriffe zu verringern.
Im Noteneingabeformular wäre eine Information bezüglich der Notentypen hilfreich
(z.B. als Hinweis).
Im Noteneingabeformular werden die Auswahlfelder für den Notentyp und das Notengewicht bei Fehlermeldungen auf den Standardwert zurückgesetzt -> korrigieren.
Beim Benutzerinterface des Berufsbildners, in der Übersicht der Newsletter-Anfragen
sollte der Details-Button beim Darüberfahren mit der Maus einen Hoover-Effekt aufweisen und den Maus-Cursor entsprechend verändern.
In den HTML-Inhalten der Emails werden teilweise Zeichen nicht korrekt dargestellt
(sie werden durch das Zeichen ‚=‘ ersetzt). Dieses Phänomen ist aber bisher nur beobachtet worden, wenn die Mails im Outlook oder im OWA des Berufsbildungscenters
betrachtet werden. Bei anderen Email-Diensten wie Googlemail, GMX, oder bei Betrachtung der Mails (von einem BBC-Mail-Account) auf dem iPhone, konnten keine
solchen Probleme festgestellt werden. Wo die Fehlerquelle liegt muss noch analysiert
werden.
6.3
Erweiterungsvorschläge
In der Anforderungsspezifikation [dok2] wurden die Ziele für GradeBook Release 1 und 2
festgelegt und soweit möglich „eingefroren“. Einige kleinere Anpassungen wurden trotzdem
Notwendig und sind unter anderem in Kapitel 5 beschrieben. Während der Projektzeit sind
aber diverse Änderungswünsche und zusätzliche Anforderungen seitens des Auftraggebers,
des Experten der Master Thesis und des Entwicklers aufgetaucht. Um das Projekt GradeBook Release 1 terminlich nicht zu gefährden wurden diese Änderungswünsche lediglich in
einer Checkliste erfasst und sind im nachfolgenden Unterkapitel Aufgelistet. Die bereits spezifizierten Erweiterungen (siehe [dok2]) werden nicht aufgeführt.
6.3.1
Checkliste und Change Management
Dieses Kapitel beinhaltet die Während der Projekt-Zeit erfassten Änderungswünsche/Vorschläge des Auftraggebers, des Experten der Master Thesis und des Entwicklers.
Die Inhalte der Checkliste sind als Ideen zu verstehen und müssen für GradeBook Release 2
noch genauer analysiert und ausformuliert werden.
Benutzer Lernender
Ein Lernender sollte einen getätigten Monatsabschluss rückgängig machen können
um ihm so die Möglichkeit zu bieten eine Fehleingabe im entsprechenden Formular
Remo Seiler, MAS-07-02
Seite 105 von 124
zu korrigieren. Dazu müsste aber der Zeitpunkt der Newsletter-Versendung ebenfalls
überdacht werden.
Der Lernende sollte die Möglichkeit haben auch ohne das Formular Monatsabschluss, die ihm zugeteilten Newsletter-Empfänger und auch seine Berufsbildner zu
betrachten (entsprechender Menüpunkt im Navigationsmenu).
Für Noten sollte sinnvollerweise eine Skala resp. eine Definition des Wertebereichs
eingeführt werden. So könnten nicht nur Noten im Bereich 1-6 erfasst werden, sondern auch z.B. Prozentangaben (0-100%) oder Grades (F-A).
Der Lernende sollte zu einer Note zusätzlich eine Bemerkung eingeben können. Diese Bemerkung würde dann in den Notenübersichten ebenfalls angezeigt.
Ein zusätzlicher Notentyp „Streichnote“ soll eingeführt werden. Mit diesem kann eine
Note als Streichnote markiert werden. Die Note bleibt dann zwar immer noch in der
Datenbank erfasst, wird aber für Durchschnittsberechnungen nicht mit einbezogen.
Der Notentyp „Prüfungsnote“ sollte pro Fach und Semester nur einmal möglich sein.
Für einen Lernenden sollten auch mehr oder weniger als 8 Semester definiert werden
können (Kauffrau-Kaufmann hat nur deren 6, Repetenten haben evtl. mehr als 8 Semester).
In einem Bericht sollten noch folgende zusätzliche Informationen enthalten sein:
o Liste mit allen Newsletter-Empfängern des Lernenden
o Liste mit allen zugeteilten Berufsbildnern des Lernenden
o Informationen zu speziellen Noten (Gewichtete Note, Prüfungsnote, …)
o Hyperlinks zu Webseiten und Email-Adressen
In der Semesterübersicht des Lernenden sollte zusätzlich zur umgesetzten Navigationsmöglichkeit (Semester vorwärts oder zurück) noch eine Combobox zur direkten
Auswahl eines Semesters ergänzt werden. Ausserdem sollte noch der GesamtDurchschnitt des Semesters und eine Legende für die Darstellung der Farben und
Schriftarten in der Tabelle (Ungültige, Notentypen- und Gewichte) angezeigt werden.
Der Noten-Newsletter sollte auch an den Lernenden selbst gesendet werden, damit
dieser eine Bestätigung des Monatsabschlusses für seine Ablage hat.
Benutzer Berufsbildner
Ein Interface zum verwalten der Fächer wäre sinnvoll (neue Fächer erfassen, Fächer
bearbeiten oder aktivieren/deaktivieren). Momentan geschieht dies direkt in der Datenbank.
Die Lernenden sollten Klassen (BBC und Gewerbeschule) zugeteilt werden können
und ein Berufsbildner sollte die Verantwortung einer solchen Klasse übernehmen
können.
Zu den Lernenden sollte eine Übersicht über alle seine Monatsabschlüsse, mit Zeitpunkten und vor allem den fehlenden Abschlüssen, abgefragt werden können.
Anstelle des Alarm-Status (oder evtl. auch zusätzlich) soll in der Übersicht der Lernenden der letzte Monatsabschluss angezeigt werden.
In der Detailansicht eines Lernenden sollte der Berufsbildner in der Semesterübersichts-Tabelle die einzelnen Fächer auswählen können um eine Notenübersicht zu
erhalten (wie dies der Lernende auch kann, aber ohne Noteneingabe-Möglichkeit).
Remo Seiler, MAS-07-02
Seite 106 von 124
Zusätzlich zu den in [dok2] spezifizierten Filter- und Sortiermöglichkeiten, werden
noch weitere benötigt: in den Übersichten der NL-Empfänger und -Anfragen, bei der
Tabelle NL-Empfänger hinzufügen, etc.
Bei der Ablehnung eines Newsletter-Antrags könnte die Möglichkeit eine Begründung
einzugeben ergänzt werden. Diese Begründung ist dann im entsprechenden Mail an
den Antragsteller enthalten.
In der Detail-Ansicht einer Newsletter-Anfrage sollten zum Antragsteller alle bereits
existierenden Newsletter-Abonnemente angezeigt werden. Dies beschleunigt unter
Umständen die Überprüfung, ob der Newsletter-Empfänger vertrauenswürdig ist oder
nicht.
Eine Möglichkeit für die Überprüfung ob ein Lernender wirklich alle Noten eingetragen
hat, wäre für den Berufsbildner hilfreich. Dies könnte beispielsweise mit einem Vergleich der Lernenden einer Klasse (sobald die Klassen umgesetzt sind) realisiert
werden.
Eine Login-Status-Anzeige für alle dem Berufsbildner zugeteilten Lernenden könnte
ergänz werden. Der Berufsbildner hätte so die Möglichkeit zu sehen, welche und wie
viele seiner Lernenden gerade online sind.
Newsletter-Empfänger
Für die Newsletter-Empfänger soll aus Sicherheits- und Datenschutzgründen ein eigenes Benutzer-Account-System (unabhängig vom ADS) umgesetzt werden. Die Registrierung eines NL-Empfängers könnte dann beispielsweise durch einen Berufsbildner bestätigt werden. Anschliessend kann sich ein NL-Empfänger einloggen um einen Newsletter für Lernende zu beantragen (dieser Punkt bleibt gleich).
Die Möglichkeit bei einem NL-Antrag eine Nachricht/Bemerkung an alle Berufsbildner
zu ergänzen wäre sinnvoll.
Allgemein
Falls das ADS-Passwort eines Benutzers abgelaufen ist, sollte GradeBook die Möglichkeit bieten dieses zu ändern (ähnlich wie dies im Outlook Web Access gelöst ist).
Da in GradeBook bereits eine umfangreiche LDAP-Library zum Einsatz kommt, könnte diese verwendet werden um Benutzerdaten im ADS zu ändern. GradeBook könnte
also dem Benutzer die Möglichkeit bieten, seine persönlichen Daten anzupassen und
diese so auch im ADS aktuell zu halten. Bis anhin müssen die Benutzerdaten vom
Sekretariat und dem ADS-Verantwortlichen aktualisiert werden, was einen unverhältnismässigen Aufwand darstellt. Zusätzlich könnten dann beim ersten Login, die im
ADS fehlenden Daten vom Benutzer angefordert werden. Die genannten Features
sind aber eigentlich nicht die Kernaufgabe des Tools und ob GradeBook der richtige
Ort für diese Funktionalität ist muss noch abgeklärt werden.
Es sollte ein Wartungsmodus für GradeBook umgesetzt werden. Im Wartungsmodus
werden alle Benutzer ausgeloggt und können sich nicht mehr einloggen (erhalten
aber eine entsprechende Meldung). So können gefahrlos Änderungen an der Software und der Datenbank vorgenommen werden.
Beim Login-Vorgang soll nach 3 erfolglosen Login-Versuchen eine Wartezeit für weitere Versuche definiert werden um das System vor BrutForce-Attacken zu schützen.
Remo Seiler, MAS-07-02
Seite 107 von 124
6.4
Nachfolgeprojekt (GradeBook Release 2)
Im Nachfolgeprojekt für GradeBook Release 2 sollen die wichtigsten der noch nicht realisierten Ziele umgesetzt werden. Dazu muss aber vorerst die Anforderungsspezifikation überarbeitet und mit den Erweiterungsvorschlägen ergänzt werden. Da diverse Erweiterungsvorschläge voraussichtlich eine höhere Priorität haben als die, für Release 2 spezifizierten Anforderungen (siehe auch [dok2]) muss auch die Priorisierung entsprechend überarbeitet werden.
Parallel zum Beginn des neuen Nachfolgeprojektes wird auch die Betatest-Phase anlaufen
(siehe Kapitel 6.4.1). Eine grobe Übersicht über die Terminplanung des Projektes ist in Kapitel 6.4.2 zu finden.
6.4.1
Betatest-Phase
Die Betatest-Phase startet direkt im Anschluss an die Master Thesis MT-07-02.16 in der ersten Woche März 2010. Für den Betatest sind vorerst zwei Gruppen von Benutzern vorgesehen. Die eine Gruppe besteht aus 7 Elektroniker-Lernenden im 2. Lehrjahr (momentan in der
erweiterten Ausbildung im BBC), welche per Anfang März bereits produktiv mit dem System
GradeBook arbeiten werden. Diese Lernenden werden ihre bisher geführten Notentabellen
(der ersten 3 Semester) übertragen und erfassen ab diesem Zeitpunkt alle ihre Noten in
GradeBook. Das bedeutet auch, dass mit dem Start der Testphase die Backups der Datenbank geführt werden müssen (findet bereits statt) und dass diese im Notfall auch zurückgespielt werden können. Die Elektroniker-Lernenden werden zu Beginn der Kalenderwoche 09,
2010 durch den Verantwortlichen R. Seiler eingeführt.
Die zweite Testgruppe besteht aus Informatik-Lernenden, die durch den Betreuer P. Aebi
bestimmt werden. Diese haben bis anhin nicht wie die Elektroniker eine Notentabelle geführt
und Monatlich an verantwortliche Personen gesendet. Die Notenerfassung fand auf eine andere Weise statt und die Lernenden sind als Testpersonen somit weniger vorbelastet. Die
Informatik-Lernenden werden zu Beginn der Kalenderwoche 09, 2010 durch den Verantwortlichen P. Aebi eingeführt.
Die Erkenntnisse der Betatest-Phase sollen direkt in Optimierungen und in die Analyse für
Release 2 einfliessen. Die Testbenutzer werden also aufgefordert, möglichst viele Rückmeldungen zu liefern. Sie sollen dementsprechend auch versuchen Fehler oder Sicherheitslücken durch intensives „ausprobieren“ aufzudecken.
6.4.2
Termine
Der Auftraggeber konnte von der Wichtigkeit der Wartungsphase überzeugt und die nötigen
Zeitaufwände konnten ihm entsprechend begründet werden. In Zusammenarbeit mit dem
direkten Vorgesetzten (2. Betreuer der Master Thesis, M. Stalder) wurden die Termine für die
Produkteinführung, die Wartung und das Nachfolgeprojet (resp. die Nachfolgeprojekte) grob
beschrieben und entsprechende Zeitbudgets festgelegt. Eine detaillierte Termin- und Ressourcenplanung wird erst zu Beginn des nächsten Projektes festgelegt.
In Tabelle 27 sind die grob geplanten Termine und Zeitspannen aufgeführt.
Remo Seiler, MAS-07-02
Seite 108 von 124
Beschreibung der Arbeiten
Zeitspanne / Termine
Verantwortlich
Start der Betatest-Phase, Einführung der Testgruppen,
Auswertungen/Optimierung
März-Juli 2010
R. Seiler,
P. Aebi
Analyse und Entwicklung GradeBook Release 2
März-Juli 2010
R. Seiler
Produkteinführung Berufsbildner Ascom/Post
März 2010
R. Seiler
(an KE-Sitzung)
Konzepte Produkteinführung, Wartung, Änderungsmanagement, Verantwortlichkeiten
Juli 2010
R. Seiler
Einführung Lernende 2. Lehrjahr (ELO)
(Einführung INF und KK wird noch abgeklärt)
Juni-Juli 2010
M. Stalder
Einführung Lernende 1. Lehrjahr (ELO/INF/KK)
August 2010
Bereichsleiter
Einführung Lernende 3./4.. Lehrjahr (ELO)
(Einführung INF und KK wird noch abgeklärt)
August-September 2010
Coachs
Einführung Kunden (inkl. Zukünftig NL-Empfänger)
August-September 2010
Coachs
Knowhow-Transfer (Technologie) für Berufsbildner
Informatik (M. Blumenthal)
März-Oktober 2010
R. Seiler
Wartungsphase Release 1 und 2
August-Dezember 2010
R. Seiler
Konzeptionierung, Planung, Analyse und Entwicklung
Release 3 (Weitere Zusatzmodule)
Januar-Juli 2011
R. Seiler,
P. Aebi,
M. Blumenthal
Tabelle 27: Termine Projekt GradeBook Release 2
Remo Seiler, MAS-07-02
Seite 109 von 124
7
Auswertungen, Erfahrungen, Fazit
7.1
Resultate
Die gesamthaft erreichten Resultate während der Master Thesis sind sehr erfreulich. Wie die
Tabelle 28 zeigt, konnten 100% der gesteckten MUSS-Ziele erreicht und somit eine funktionierende und produktiv einsetzbare Softwarelösung für den Auftraggeber erstellt werden.
Priorität
Anzahl AF total
Implementiert
Prozentsatz der Implementierung
A
38
38
100%
B
28
23
82%
C
24
18
75%
D
26
2
8%
Tabelle 28: Zusammenfassung der Resultate
Dank der Möglichkeit während der Winterferien viel Zeit in die Implementierung investieren
zu können, wurden auch viele der optionalen Ziele erreicht. So ist auch sichergestellt, dass
die Software bereits jetzt einen hohen Komfort bezüglich Bedienung bietet und die vorhandene Funktionalität die wichtigsten Bereiche abdeckt.
Alles in Allem bin ich wie auch der Auftraggeber und die verschiedenen Stakeholder mit dem
Resultat der Arbeit sehr zufrieden.
7.2
Auswertung der Zeitaufwände und Termine
In Anhang A ist der Terminplan mit den eingetragenen Ist-Zeiten aufgeführt. In diesem Kapitel sollen nun die Termine, Zeitaufwände und Verschiebungen derselben diskutiert werden.
Der gesamte Zeitaufwand für das Projekt GradeBook beträgt nun schliesslich über 540
Stunden, was einer Differenz von mehr als 160 Stunden auf die ursprünglich budgetierte
Projektzeit entspricht (oder etwas mehr als 140%). Die 380 veranschlagten Stunden hätten
aber ungefähr gereicht, wenn nicht viele zusätzliche Ziele mit tieferer Priorität umgesetzt
worden wären. So hätten bei der Implementierung beispielsweise rund 60 Stunden gespart
werden können, wenn nur die Anforderungen der Priorität A umgesetzt worden wären. Dies
hätte auch dazu geführt, dass sich der Aufwand für Analyse, Tests und Abschlussbericht um
viele Stunden reduziert hätte. Nach meinen Schätzungen, wäre der Gesamtzeitaufwand des
Projektes für die Umsetzung aller A-Ziele bei rund 400 Stunden gelegen.
Die einzelnen Projektphasen wurden bezüglich des prozentualen Anteils am Projekt recht
gut Geschätzt, wie Tabelle 29 zeigt. Die Prozentangaben beziehen sich jeweils auf die Totale Zeit (sowohl bei Soll- wie auch bei Ist-Zeiten).
Die grösste Abweichung weist das Requirements Engineering auf. Hier wurden 132.5 anstatt
82.5 Stunden benötigt, also genau 50 Stunden mehr als geplant. Das ergibt eine Abweichung von rund 60%. Der Zeitaufwand für Gespräche und vor allem für die Dokumentation
der Anforderungen wurde massiv unterschätzt. In einem nächsten Projekt könnten aber, gemäss Feedback des Experten, einige Optimierungen vorgenommen werden. So könnte beispielsweise der Detaillierungsgrad der Anwendungsfälle etwas reduziert und somit einige
Redundanzen vermieden werden. Das würde in dieser Phase wahrscheinlich rund 10-20%
Remo Seiler, MAS-07-02
Seite 110 von 124
Zeiteinsparung einbringen. Trotz dem bleibt eine recht grosse Abweichung, die aber, dank
der gemachten Erfahrungen, bei weiteren Projekten einkalkuliert werden kann.
Die nächste grössere Abweichung gab es in der Implementierungsphase. Dort wurde rund
das Doppelte der geplanten Zeit investiert. Wie aber bereits erwähnt lag dies vor allem an
den recht ambitiösen Zielen für die Umsetzung. So habe ich mir an dieser Stelle zwar viel
Aufwand eingehandelt, aber dafür ein ansprechendes und umfangreiches Resultat erzielt.
Die Zeitaufwände für den Abschlussbericht waren ebenfalls deutlich höher als in der Planung
vorgesehen. Dies vor allem deshalb, weil ich bei der Planung für den Abschlussbericht davon ausgegangen war, dass ich grosse Teile bereits während der Analyse und DesignPhase umsetzen werde. Dies habe ich zwar auch erreicht, aber die Aufwände für die Restlichen Inhalte, insbesondere auch die Dokumentierung der Tests war deutlich zeitintensiver
als gedacht.
Wie bereits erwähnt sind in der nachfolgenden Tabelle 29 alle Soll- und Ist-Zeiten, inklusive
den prozentualen Anteilen aufgeführt.
Projektphase / Arbeitsbereich
Soll
Ist
Soll
Ist
Projektmanagement
19
18
5.0%
3.3%
Reviews, Sitzungen
10.5
17.25
2.8%
3.2%
Pflichtenheft Masterthesis
22
21
5.8%
3.9%
Requirements Engineering
82.5
132.5
21.7%
24.4%
Analyse, Design (SW und DB)
66.5
73.5
17.5%
13.5%
65
120
17.1%
22.1%
54.5
64
14.3%
11.8%
Integration
16
0
4.2%
0.0%
Abnahmetests
8
8
2.1%
1.5%
Berichte, Dokumentation
22
77
5.8%
14.2%
Präsentation
14
12
3.7%
2.2%
Implementierung
Test
Tabelle 29: Übersicht Zeitaufwände
Um die Daten der Tabelle 29 noch etwas zu verdeutlichen, werden die Zeitaufwände im Balkendiagramm in Abbildung 45 einander gegenübergestellt.
Remo Seiler, MAS-07-02
Seite 111 von 124
Präsentation
Berichte, Dokumentation
Abnahmetests
Integration
Test
Implementierung
Analyse, Design (SW und DB)
Requirements Engineering
Pflichtenheft Masterthesis
Reviews, Sitzungen
Projektmanagement
Ist
Soll
0
20
40
60
80
100
120
140
Abbildung 45: Balkendiagramm Zeitaufwände
Um die Erfahrungen in diesem Projekt möglichst gewinnbringend in nachfolgenden Projekten
einsetzen zu können, wird hier die prozentuale Verteilung der einzelnen Aufwände noch etwas genauer betrachtet (siehe Abbildung 46).
Anteile der Projektphasen (ist-Aufwände)
2%
0%
2% 3% 3% 4%
14%
24%
12%
22%
14%
Projektmanagement
Reviews, Sitzungen
Pflichtenheft Masterthesis
Requirements Engineering
Analyse, Design (SW und DB)
Implementierung
Test
Integration
Abnahmetests
Berichte, Dokumentation
Präsentation
Abbildung 46: Prozentuale Verteilung der Zeitaufwände
Auffällig dabei ist, dass die Implementierung lediglich 22% ausmacht, obschon sie deutlich
aufwändiger war als geplant. Die gesamte Analyse-Phase, also Pflichtenheft, Requirements
Engineering und Analyse- und Design machen zusammen den Löwenanteil von 42% der
gesamten Projektzeit aus, wobei die RE-Phase mit 24% die aufwändigste des gesamten
Projektes war. Ebenfalls erstaunlich für mich war, dass die Testphase effektiv 12% der Zeitaufwände beträgt. Das der Bericht mit Rund 14% zu Buche schlägt hängt wohl auch etwas
mit dem speziellen Projektumfeld zusammen, resp. mit der Tatsache, dass es sich hier um
eine Abschlussarbeit eines Studiums handelt. Letzteres führte sicherlich zu einem etwas
erhöhten Aufwand für die Dokumentation, da in einem Kundenprojekt wohl einige allgemeine
Kapitel etwas knapper gehalten werden könnten. Alles in allem entspricht zwar die Aufwandsverteilung meines Projekts nicht exakt der Verteilung wie sie in der Literatur proklamiert wird, aber die Grössenordnungen gehen in diese Richtung.
Remo Seiler, MAS-07-02
Seite 112 von 124
7.3
Projektverlauf und Erfahrungen
Eingabe: Der Start der Diplomarbeit (Einreichung der Aufgabenstellung) war etwas holprig
und kann wohl nicht gerade als sehr erfolgreich bezeichnet werden. Die erste Projekteingabe
wurde abgelehnt, mit der Begründung „Umfang und Anspruch zu tief“. Dank der grossen Unterstützung in dieser Phase, durch den jetzigen Experten Herr Godet konnten die Probleme
aber relativ schnell erkannt und gelöst werden. Die Aufgabenstellung war aufgrund falscher
Annahmen meinerseits zu offen formuliert und deutete somit auf eine geplante Minimallösung hin, was so natürlich nicht gemeint war. Im zweiten Anlauf wurde die Aufgabenstellung
dann auch genehmigt und ich konnte mich an die Arbeit machen.
Pflichtenheft: Die erste, etwas überraschende Erkenntnis war, dass für die Arbeit zusätzlich
zur Anforderungsspezifikation auch ein Pflichtenheft notwendig war. Dies war zwar aufgrund
des grossen Requirements Engineering - Anteils des Projekts sehr sinnvoll, verzögerte aber
auch etwas den geplanten Projektstart. Nicht zuletzt wegen der bereits eingeleiteten Anforderungs-Analyse (eine frühere und ausführlichere Information seitens der SWS wäre diesbezüglich hilfreich). Es musste nun also ein Weg gefunden werden, die Ziele der Master Thesis
zu beschreiben, ohne der Anforderungsspezifikation zu stark vorzugreifen. Dies erwies sich
zwar als eine recht schwierige aber lösbare Aufgabe. Ein telefonisches Review mit dem Experten hat auch gezeigt, dass ein guter Mittelweg gefunden wurde.
Requirements Engineering: Nachdem die Ziele für das Projekt inklusive der SRS fest standen, startete die erste eigentliche Projektphase, das Requirements Engineering. Letzteres
war bereits deutlich intensiver als ich das erwartet habe. Die Zusammenarbeit mit den Stakeholdern erwiese sich zwar als äusserst interessant und informativ, sie war aber auch geprägt von sehr zeitaufwändigen Gesprächen und viel Dokumentationsarbeit. Die Dokumentation der Arbeiten (was schliesslich zu mehr als 110 Seiten SRS führte) wurde zu Beginn unterschätzt, was bereits in der Anfangsphase des Projekts terminliche Engpässe zur Folge
hatte. Die ausgiebigen Abklärungen zu den Anforderungen haben sich aber, wie sich später
zeigte, sehr positiv auf die nachfolgenden Projektteile ausgewirkt. So konnte beispielsweise
die Analyse und Designphase gradlinig und ohne unvorhergesehene „Stolpersteine“ durchlaufen werden.
Analyse- und Design: Was sich in der Analyse- und Designphase stark bemerkbar machte,
war das fehlende Knowhow zu Webtechnologien und den eingesetzten Werkzeugen. So
musste ich bereits hier einige Reservezeit einsetzen um die fehlenden Inhalte (oder zumindest deren Grundlagen) zu erarbeiten. Diese Reservezeit währe in einem Kundenprojekt
natürlich nicht zu verrechnen und ich habe sie somit auch nicht in die ZeitaufwandsRechnung mit einbezogen. Nichts desto trotz konnte ich die Analyse-Phase mit einer guten
Woche Verspätung abschliessen.
Implementierung: Nach knapp 230 Stunden Arbeit und noch keiner einzigen Zeile Source
Code (mit Ausnahme der paar einfachen Prototypen) kam nun der Teil den ich sehnlichst
erwartet hatte, die Implementierung. Diese Projektphase war sehr intensiv und spannend.
Nun zeigte sich, ob die Analysearbeiten gut gemacht worden waren. Dabei viel mir erneut
auf, wie wichtig die Rolle der ersten Projektphase war. Dank den ausführlich spezifizierten
Zielen, habe ich mich in keinerlei „Sackgassen“ programmiert und ich konnte mich voll und
ganz auf die Lösung der technischen Probleme fokussieren. Einziger Wehrmutstropfen, die
Softwareanalyse und das Design mussten nach der Codierung stark überarbeitet werden. Es
Remo Seiler, MAS-07-02
Seite 113 von 124
zeigte sich, dass sich aufgrund meiner, zu Beginn doch eher rudimentären Kenntnisse1, einige Fehlüberlegungen (technischer Natur) eingeschlichen haben.
Nach rund 120 Stunden musste ich dann schliesslich die Codierung weiterer Inhalte abbrechen, da ich bereits deutlich mehr Ziele als geplant umgesetzt habe. Letzteres machte sich
auch bemerkbar, durch den steigenden Aufwand für Analyse und Design bei jedem zusätzlich angestrebten Ziel. Zudem wurde mir auch der zusätzliche dokumentations-Aufwand bewusst, den ich mir mit jedem weiteren implementierten Detail aufhalsen würde.
Erfreuliches Zwischenfazit zu diesem Zeitpunkt: der Terminplan konnte wieder eingeholt
werden2.
Dokumentation: Nun folgte fürs erste wieder viel Dokumentationsarbeit. Einerseits mussten
die Analyse- und Design-Dokumente überarbeitet und andererseits der Source Code ausführlich dokumentiert (resp. kommentiert) werden. Kommentare wurden zwar bereits während der Programmierung ausführlich eingesetzt, die Doxygen-konformen Kommentare
mussten aber noch definiert werden. Hier halfen auch wieder die bereits geleisteten Arbeiten
in der Analysephase. In dieser wurden beispielsweise die meisten Klassen, Methoden und
Attribute beschrieben und die Texte konnten mit wenigen Änderungen übernommen werden.
Test: Nachdem die wichtigsten Dokumente überarbeitet waren, folgte die Testphase der
Software. Es zeigte sich in dieser, dass zwar die Anforderungen korrekt umgesetzt wurden,
aber es tauchten etliche kleinere und grössere Fehler auf (wer sucht der findet). Die Fehler
beschränkten sich aber ausschliesslich auf Programmierfehler oder nicht einhalten von
Standards. Die Korrektur dieser Fehler ging denn auch relativ schnell von statten (glücklicherweise). Erneut war ich heilfroh, frühzeitig die Anforderungen geprüft und diese genau
durchdacht zu haben. Nicht auszudenken, wie gross der Aufwand gewesen wäre, grundsätzliche Softwarestrukturen oder ganze Bereiche der Software anpassen zu müssen3. Ich bin
dementsprechend glücklich darüber, dass ich mich gezwungen habe, den grossen Anfangsaufwand zu betreiben und mir somit grössere Probleme in der Schlussphase erspart
habe.
Was ich aber hier noch anmerken muss, ist dass der grösste Aufwand in der Testphase die
Konzeptionierung und vor allem die Dokumentation dieser Tests war. Die Definition der
Tests werde ich bei einer nächsten Arbeit wohl in eine frühere Projektphase verlegen. Es hat
sich gezeigt, dass die Tests bereits während der Entwicklung sehr hilfreich gewesen wären
und dass mir das Prinzip des „testdriven development“ einiges an Ärger und vor allem doppelter Arbeit erspart hätte.
Abschluss: Nun ist die letzte Projektphase angebrochen und wie der geneigte Leser vermuten wird schreibe ich gerade die letzten Kapitel meines Abschlussberichts. Der grösste Teil
des Berichts steht und es fehlen lediglich das aktuelle Kapitel und einige Administrative Inhalte (Abkürzungsverzeichnisse, Glossar etc.). Alles in allem, bin ich mit dem gesamten Projektverlauf sehr zufrieden und freue mich auf die Abgabe der Arbeit nächste Woche und vor
allem auf den Einsatz der Entwickelten Software Anfang nächsten Monat.
1
Bezieht sich auf die Kenntnisse der eingesetzten Technologien wie Webdesign, PHP, ApacheWebserver, Session-Handling, etc.
2
Die Feiertage und Ferien fanden dafür dieses Jahr mehrheitlich ohne mich statt…
3
Inklusive dem ganzen Rattenschwanz den das hinter sich her ziehen würde wie: Erneute Analysen,
Designs, Codierungen, Dokumentationen und Tests mit eventuell nochmals Korrekturen…
Remo Seiler, MAS-07-02
Seite 114 von 124
7.4
Schlussbetrachtung, Fazit
Nach mehr als 250 produzierten A4-Seiten Dokumentation, mit mehr als 65‘000 geschriebenen Wörtern resp. fast einer halben Million geschriebener Zeichen und rund 10‘000 programmierten Codezeilen geht nun eine der intensivsten Zeiten meiner ganzen Ausbildungskarriere zu Ende. Die Master Thesis war eine spannende, sehr lehrreiche aber auch enorm
anstrengende und zeitintensive Arbeit. Obschon ich mir eigentlich vorgenommen hatte, meine Freunde und Bekannte während dieser Zeit nicht allzu stark zu vernachlässigen, ist mir
dies gegen Schluss nicht immer ganz gelungen. Die letzten Wochen waren gezeichnet von
wenig Schlaf und fehlender Freizeit. Die vielen Erfahrungen die ich gesammelt habe, die
neuen Technologien die ich mir aneignen konnte, die vielen guten Rückmeldungen der zukünftigen Benutzer und nicht zu Letzt das befriedigende Resultat der Arbeit endschädigen
mich aber für viele Entbehrungen der letzen Monate.
Ich freue mich nun auf eine erholsame Nach-Master-Thesis-Zeit!
7.5
Danksagung
An dieser Stelle möchte ich mich bei den Personen bedanken, die mich während des gesamten Studiums und während der Master Thesis unterstützt haben:
Patrick Aebi für seine kompetente Betreuung und die vielen Stunden die er für das
Lesen meiner Dokumente, für Reviews und Besprechungen eingesetzt hat.
André-Claude Godet für das aufgebrachte Interesse und die Unterstützung vor allem
in der Anfangsphase des Projektes.
Matthias Stalder für die Unterstützung aller meiner bisherigen Ausbildungen, die Hilfe
bei der Suche nach einem geeigneten Projekt für die Master Thesis, die Unterstützung bei der Projekteingabe beim Arbeitgeber und die vielen motivierenden Feedbacks während der gesamten Zeit.
Hanspeter Linder für die Möglichkeit die Arbeit für die Firma zu schreiben.
Den verschiedenen Stakeholdern für ihre gute Mitarbeit während des Requirement
Engineerings und die vielen guten Inputs.
Den Mittstudenten Christian und Patrick für die amüsanten Stunden neben der Ausbildung, die guten Gespräche, die gemeinsamen „Feierabendbiere“ und die Zusammenarbeit während des Studiums.
Und besonders grossen Dank gilt meiner Lebenspartnerin Seraina Brunner, die mich
während des gesamten Studiums und insbesondere während den letzten fünf Monaten stets motiviert, aufgemuntert, von Alltagssorgen entlastet und tatkräftig unterstützt
hat und zudem Verständnis dafür hatte das nur wenig gemeinsame Freizeit vorhanden war.
Remo Seiler, MAS-07-02
Seite 115 von 124
A
Terminplan
Remo Seiler, MAS-07-02
Seite 116 von 124
B
Glossar Fachbegriffe
Die in diesem und dem nachfolgenden Kapitel erklärten Begriffe wurden grösstenteils aus
der Anforderungsspezifikation [dok2] übernommen und lediglich mit ein paar zusätzlichen
Begriffen ergänzt.
Begriff
Erklärung
Ascom
Die Ascom Holding AG (oder Ascom (Schweiz) AG) ist
eine international tätige Unternehmensgruppe für Telekommunikation und Service aus der Schweiz. Die Ascom
führt ein Berufsbildungszentrum (siehe Berufsbildungscenter) für technische Berufe in Bern. Sie ist der indirekte Auftraggeber für das Produkt GradeBook.
Basisausbildung
Lernende der Berufe Elektronik, Informatik und Kauffrau/Kaufmann der Ascom und von über 40 Partnerfirmen
absolvieren eine Basisausbildung im Berufsbildungscenter. Diese Basisausbildung deckt die Grundlagen (theoretische und praktische) der betrieblichen Ausbildung der
Lernenden ab, parallel dazu besuchen diese 2 Tage pro
Woche die Gewerbeschule.
Bericht
Ein Bericht ist in GradeBook ein PDF-Dokument mit Noteninformationen, dass zu einem Lernenden erstellt wird
(durch ihn selber oder einen Berufsbildner). Der Bericht
dient als Besprechungsgrundlage für Gespräche zwischen
Lernendem und Berufsbildner und als Ablagedokument für
den Lernenden.
Berufsbildner
Ein Berufsbildner ist ein gemäss Berufsbildungsverordnung legitimierter Ausbildungsverantwortlicher. Er ist im
Betrieb unter anderem für die Ausbildung und Betreuung
der Lernenden Verantwortlich.
Berufsbildungscenter
Das Berufsbildungscenter ist ein Kompetenzzentrum für
die Berufsausbildung und wird geführt von den drei Firmen
Ascom, Login und Post. Die Ascom Berufsbildung bildet in
einem Ausbildungsverbund mit über 40 Partnerfirmen Lernende in den Berufen Elektroniker, Informatiker und Kauffrau/Kaufmann im Berufsbildungscenter aus.
Die nachfolgende Beschreibung der Dienstleistungen der
Ascom Berufsbildung ist der Internetseite des Berufsbildungscenters [net15] entnommen:
Das Berufsbildungscenter hat ein modernes und auf die
Ansprüche der Zukunft ausgerichtetes Ausbildungs- und
Förderungskonzept aufgebaut, mit dem jungen Menschen
heute die notwendigen Qualifikationen und Fähigkeiten für
morgen vermittelt werden.
Junior Enterprise, die Beratungs- und Dienstleistungsstelle
im Berufsbildungscenter, ermöglicht es KMU, Industrie-,
Kantons-, Bundes- und Dienstleistungsbetrieben unsere
Ausbildungsinfrastruktur und -kompetenz gemeinsam zu
nutzen. Neben der Beratung rund um die Ausbildung von
Remo Seiler, MAS-07-02
Seite 117 von 124
Lernenden verkauft Junior Enterprise insbesondere Ausbildungsleistungen wie: Basisausbildungen oder einzelne
Module daraus, überbetriebliche Kurse/ Einführungskurse,
Vertiefungsmodule und Prüfungsvorbereitungen. Sie können aber auch das gesamte Ausbildungsmanagement von
der Auswahl der Lernenden bis zum Abschluss der Lehre
oder Teile davon an Junior Enterprise übergeben bzw.
outsourcen
Die in vorliegendem Pflichtenheft beschriebene Master
Thesis wird im Auftrag des Berufsbildungscenters durchgeführt.
Koordinaten:
Ascom (Schweiz) AG
Berufsbildungscenter
Bahnhöheweg 70
3018 Bern
Telefon: 031 999 33 33
www.berufsbildungscenter.ch
Der Student R. Seiler ist Mitarbeiter der Ascom (Schweiz)
AG und im Berufsbildungscenter als Berufsbildner Elektronik angestellt.
Coach
Den Lernenden die in der Ascom Berufsbildung eine Basisausbildung besuchen und deren Firma ein OutsourcingVertrag für die Ausbildung mit der Ascom hat ist während
der gesamten Lehrzeit ein persönlicher Coach zugeteilt.
Der Coach ist ein Mitarbeiter des Berufsbildungscenters
und zuständig für Hilfestellungen bei Problemen aller Art
und den Aufbau der beruflichen Förderung der Lernenden.
Er hat unter anderem auch eine Kontrollfunktion und
überwacht die Lernzielerreichung in den verschiedenen
Bereichen der Ausbildung (z.B. in der Gewerbeschule)
Fach
Mit Fach ist ein Schulfach der Berufsschule (Gewerbeschule) oder ein Ausbildungsmodul im Berufsbildungscenter gemeint.
Gewerbeschulnoten
Noten welche Lernende in der Gewerbeschule die sie parallel zur betrieblichen Berufsausbildung besuchen erhalten (siehe dazu auch Modulnoten)
GradeBook
GradeBook ist der Name und Arbeitstitel der Notenverwaltungs-Webapplikation die während der Master Thesis MT07-02.16 erstellt wurde. Sie wurde im Auftrag des Berufsbildungscenters erarbeitet und ist in vorliegendem Abschlussbericht ausführlich beschrieben.
Lernende
Der / Die Lernende ist die Kurzform für Lernende Person
in der beruflichen Ausbildung (früher Lehrling). Gemäss
Berufsbildungsverordnung 2008 ist dieser Begriff zwingend zu verwenden, da er geschlechtsneutral ist. Auszubildende als alternative ist nicht sinnvoll, da dieser Begriff
in Deutschland verwendet wird und dort eine nicht ver-
Remo Seiler, MAS-07-02
Seite 118 von 124
gleichbare Art der beruflichen Ausbildung beschreibt.
Note
Mit Note ist allgemein eine Schulnote aus der Berufsschule oder eine Modulnote gemeint.
Partnerfirma
Partnerfirmen sind alle Firmen, die bei der Ascom Berufsbildung die Basisausbildung für ihre Lernenden durchführen lassen.
Release 1
Das Release 1 von GradeBook ist die Pilot-Software die
ab Anfang März 2010 von einer definierten Benutzergruppe zu Testzwecken bereits produktiv eingesetzt wird.
Release 2
Das Release 2 ist die definitive Webapplikation GradeBook die ab August 2010 von allen Benutzergruppen produktiv eingesetzt wird. Ab diesem Zeitpunkt beginnt die
Wartungsphase des Produktes GradeBook.
C
Glossar Informatikbegriffe
Begriff
Erklärung
Betaversion
Wird in diesem Dokument als Synonym für die PilotSoftware verwendet (siehe Begriff Pilot-Software).
Dropdown-Menu
Ist ein Element einer graphischen Benutzeroberfläche. Ein
Menu wird beim klicken auf das Element ausgefahren. Es
wird häufig auch synonym mit Dropdown-Liste verwendet.
Newsletter
Der Newsletter ist eine regelmässig versendete MailNachricht an eine definierte Anzahl Empfänger.
Normalform
Relationale Datenbanken lassen sich zur Vermeidung von
Redundanzen und aus Performance-Gründen normalisieren. Normalformen – es gibt deren 5 – sind Abstufungen
dieser Normalisierung.
PHPMyAdmin
Ist ein Tool zur manuellen Bearbeitung von Datenbanken
über ein Webinterface.
Requirements Engineering
Ist die Projektphase in der, in Zusammenarbeit mit den
Stakeholdern, die Anforderungen an das zu erstellende
Softwareprodukt gesucht, definiert und dokumentiert werden.
Reviews
Als Reviews werden Sitzungen bezeichnet, welche die
Validierung und Verifizierung von Dokumenten und Sourcecodes zum Ziel haben.
Stakeholder
Jemand, der direkt oder indirekt Einfluss auf die Anforderungen hat.
Webapplikation
Eine Applikation die auf einem Webserver läuft. Benutzerinteraktionen laufen ausschliesslich über ein Webinterface.
Webspace
Speicherplatz für Dateien auf einem Server auf welchen
über das Internet dauerhaft zugegriffen werden kann.
Remo Seiler, MAS-07-02
Seite 119 von 124
D
Abkürzungen und Akronyme
Abk.
Bedeutung
Abk.
Bedeutung
ADS
AF
AGB
BBC
BBCnet
BG
BMS
BUC
CAPTCHA
Active Directory Service
Anforderung
Allgemeine Geschäftsbedingungen
Berufsbildungscenter
Berufsbildungscenter-Intranet
Berufsgruppe
Berufsmaturitätsschule
UseCase Berufsbildner
Completely Automated Public Turing test to
tell Computers and Humans Apart
CD
Corporate Design
LDAPS
LUC
M
MAS
mm
MT
MUC
MVC
MySQL
N
NL
LDAP über SSL
UseCase Lernender
Model
Master of Advanced Studies
Millimeter
Master Thesis
UseCase mehre Benutzer
Model-View-Controller
MY Sequential Query Language
Normalfall
Newsletter
CI
CS2
CSS
CURL
DB
DDL
DIN
DML
DMZ
EA
ERM
evtl.
F
FA
FTP
GB
GIBB
Gmail
GNU
HMI
HTML
HTTPS
ID
IDE
InnoDB
INT
IP
ISO
KW
LAN
LDAP
Corporate Identity
Creative Suite (Adobe-Produktpacket)
Cascading Style Sheets
Client for URLs
Datenbank
Data Definition Language
Deutsche Industrie-Norm
Data Manipulation Language
DeMilitarized-Zone
Enterprise Architect
Entity-Relationship-Modell
Eventuell
Fehlerfall
Funktionale Anforderung
File Transfer Protocol
GradeBook
Gewerbliche Industrielle Berufsschule Bern
Google Mail
GNU's Not Unix, open source Lizenz
Human Machine Interface
HyperText Markup Language
HyperText Transfer Protocol Secure
Identifikationsnummer
Integrated Development Environment
Storage engine für MySQL
Integer
Internet Protocol
International Standards Organisation
Kalenderwoche
Local Area Network
Lightweight Directory Access Protocol
NLE
OOP
P
PDF
PHP
Px
R
RDBMS
Res
RS
SFTP
SMTP
SQL
SRS
srv
SSL
SW
SWS
T
TA
TForm
TID
UML
URL
UTF-8
VPN
Wysiwyg
XAMPP
XHTML
XSS
ZIP
Newsletter-Empfänger
Objektorientierte Programmierung
Priorität
Portable Document Format
Hypertext Preprozessor
Pixel
Resultat
Relational DataBase Management System
Resultat
Remo Seiler
Secure File Transfer Protocol
Simple Mail Transfer Protocol
Structured Query Language
Software Requirements Specification
Server
Secure Sockets Layer
Software
Software Schule Schweiz
Testfall
Test-Abfrage
Testfall Formular
Test-Identifikationsnummer
Unified Modeling Language
Uniform Resource Locator
8-bit Unicode Transformation Format
Virtual Private Network
What You See Is What You Get
?, Apache, MySQL, Perl, PHP
Extensible Hypertext Markup Language
Cross-Site Scripting
Komprimiertes File
Tabelle 30: Abkürzungen und Akronyme
Remo Seiler, MAS-07-02
Seite 120 von 124
E
Abbildungsverzeichnis
Abbildung 1: MVC-Entwurfsmuster .......................................................................................10
Abbildung 2: Angepasstes MVC-Entwurfsmuster ................................................................11
Abbildung 3: Aufbau Framework CodeIgniter, Quelle [net4] .................................................13
Abbildung 4: Anwendungsfälle Lernender ............................................................................14
Abbildung 5: Anwendungsfälle Berufsbildner ........................................................................15
Abbildung 6: Anwendungsfälle mehrere Benutzer ................................................................15
Abbildung 7: Paketdiagramm GradeBook .............................................................................16
Abbildung 8: Architektur GradeBook.....................................................................................17
Abbildung 9: Systemklassendiagramm Controller.................................................................22
Abbildung 10: Klasse Login ..................................................................................................23
Abbildung 11: Klasse Lernender ...........................................................................................24
Abbildung 12: Klasse Berufsbildner ......................................................................................26
Abbildung 13: Klasse NewsletterAnfrage ..............................................................................29
Abbildung 14: Library Bericht mit Basisklasse (tcpdf-Library) ...............................................31
Abbildung 15: Systemklassendiagramm Models...................................................................34
Abbildung 16: Prototyp Webseiten-Layout ............................................................................37
Abbildung 17: Layout der Webseiten mittels HTML-div-Container ........................................39
Abbildung 18: Navigation Login und Newsletter-Abonnement anfragen ...............................41
Abbildung 19: Navigation Benutzerinterface Lernender ........................................................42
Abbildung 20: Navigation Benutzerinterface Berufsbildner ...................................................43
Abbildung 21: Sequenzdiagramm Login ...............................................................................44
Abbildung 22: Sequenzdiagramm Semesterübersicht (Lernender) .......................................45
Abbildung 23: Sequenzdiagramm Formular Semester bearbeiten laden ..............................46
Abbildung 24: Sequenzdiagramm Fächer hinzufügen/entfernen ...........................................47
Abbildung 25: Sequenzdiagramm Notenübersicht anzeigen .................................................48
Abbildung 26: Sequenzdiagramm Note bearbeiten...............................................................49
Abbildung 27: Sequenzdiagramm Formular Note eingeben ..................................................50
Abbildung 28: Sequenzdiagramm Formular Monatsabschluss .............................................51
Abbildung 29: Sequenzdiagramm Monatsabschluss und Noten-Newsletter .........................52
Abbildung 30: Sequenzdiagramm Details Lernender ............................................................53
Abbildung 31: Sequenzdiagramm Email Eingabe .................................................................54
Abbildung 32: Geschäftsdatenmodell ...................................................................................55
Abbildung 33: Relationen-Modell Datenbank ........................................................................58
Abbildung 34: Spezielle Tabelle für Session-Handling ..........................................................59
Abbildung 35: Tabellen für die Speicherung von Klasseninformationen ................................59
Abbildung 36: Testaufbau .....................................................................................................66
Abbildung 37: Code-Snippet MySQL-Except-Workaround ....................................................70
Abbildung 38: Klassendiagramm Unit-Tests .........................................................................73
Abbildung 39: Nicht erfolgreicher und erfolgreicher Unit-Test (Model Newsletter) ................74
Abbildung 40: Validierung des XHTML1.0 Strict Standards ..................................................75
Abbildung 41: Formular Login...............................................................................................77
Abbildung 42: Formular Noteneingabe .................................................................................79
Abbildung 43: Formular Email-Eingabe ................................................................................81
Abbildung 44: Formular Registrierung ..................................................................................83
Remo Seiler, MAS-07-02
Seite 121 von 124
Abbildung 45: Balkendiagramm Zeitaufwände ....................................................................112
Abbildung 46: Prozentuale Verteilung der Zeitaufwände ....................................................112
F
Tabellenverzeichnis
Tabelle 1: Vergleich und Nutzwertanalyse Framework .........................................................12
Tabelle 2: Methoden der Klasse Login ................................................................................23
Tabelle 3: Methoden der Klasse Lernender ..........................................................................26
Tabelle 4: Methoden der Klasse Berufsbildner .....................................................................29
Tabelle 5: Methoden der Klasse Newsletter-Anfrage ............................................................31
Tabelle 6: Methoden der Klasse Newsletter-Anfrage ............................................................33
Tabelle 7: Model-Klassen .....................................................................................................36
Tabelle 8: Hintergrundfarben GradeBook .............................................................................38
Tabelle 9: Schriftfarben GradeBook......................................................................................38
Tabelle 10: Konfiguration CodeIgniter für GradeBook...........................................................62
Tabelle 11: Doxygen-Tags ...................................................................................................64
Tabelle 12: Testabfragen Datenbank ....................................................................................70
Tabelle 13: Test Login-Formular...........................................................................................78
Tabelle 14: Test Noteneingabe-Formular .............................................................................80
Tabelle 15: Test Email-Formular ..........................................................................................82
Tabelle 16: Test Registrierungsformular ...............................................................................85
Tabelle 17: Abnahmetests zu Benutzer Lernender ...............................................................90
Tabelle 18: Abnahmetests zu Benutzer Berufsbildner ..........................................................96
Tabelle 19: Abnahmetests zu Benutzer Newsletter-Empfänger ............................................97
Tabelle 20: Abnahmetests zum Login-Vorgang (Authentifizieren) ........................................98
Tabelle 21: Vergleich Anforderungen – Resultate, Benutzer Lernender .............................100
Tabelle 22: Vergleich Anforderungen – Resultate, Benutzer Berufsbildner .........................101
Tabelle 23: Vergleich Anforderungen – Resultate, Benutzer NL-Empfänger.......................102
Tabelle 24: Vergleich Anforderungen – Resultate, mehrere Benutzergruppen ...................102
Tabelle 25: Vergleich Anforderungen – Resultate, System .................................................102
Tabelle 26: Vergleich Anforderungen – Resultate, nicht funktionale Anforderungen ...........103
Tabelle 27: Termine Projekt GradeBook Release 2 ............................................................109
Tabelle 28: Zusammenfassung der Resultate ....................................................................110
Tabelle 29: Übersicht Zeitaufwände ...................................................................................111
Tabelle 30: Abkürzungen und Akronyme ............................................................................120
Remo Seiler, MAS-07-02
Seite 122 von 124
G
Quellen
Dokumente:
[dok1]
Ascom (Schweiz) AG, Remo Seiler, Berufsbildungscenter, Pflichtenheft Master Thesis MT-0702.16, 04.11.2009, MAS-07-02-16-spec.pdf
[dok2]
Ascom (Schweiz) AG, Remo Seiler, Berufsbildungscenter, Anforderungsspezifikation Master Thesis
MT-07-02.16, 27.11.2009, dok.nseire.20091011.113.Anforderungsspezifikation GradeBook.pdf
[dok3]
Ascom (Schweiz) AG, Matthias Stalder, Berufsbildungscenter, Leitfaden technischer Bericht,
15.02.2004, dok.nstalm.20041015.101.TechnischerBericht.pdf
[dok4]
Fachhochschule Pforzheim, Dipl.-Phys. Michael Bauer, Einführung Technische Berichte,
22.08.2002, Erstellung technischer Berichte.pdf
[dok5]
DIN1421, 1983, DK 001.816 : 655.535.56 : 001.4, DIN 1421.pdf
[dok6]
Softwareschule Schweiz, André-Claude Godet, OOSD Objekt-orientierter Software-Design mit
UML, Vorlesungsskript, Ausgabe 2007 / 2
[dok7]
Softwareschule Schweiz, Othmar Bürgi, Projekt-Management
Vorlesungsskript, 2008 Version 95
[dok8]
Softwareschule Schweiz, Othmar Bürgi, Systematisches Testen von Dokumenten, Vorlesungsskript, 2007 Version 2.0
[dok9]
Softwareschule Schweiz, Dr. Simon Moser, RDB-SQL Relationale Datenbanken „Datenmodellierung und SQL I“, Vorlesungsskript, Ausgabe Oktober 2007
von SW-Entwicklungs-Projekten,
Literatur:
[lit1]
Pearson Studium, Ian Sommerville, Software Engineering, 6. Auflage, ISBN-10: 3-8273-7001-9
[lit2]
vdf Hochschulverlag AG, Carl August Zehnder, Informatik-Projektentwicklung, 4. Auflage, 2003,
ISBN-10: 3-7281-2869-4
[lit3]
Oldenbourg Wissenschaftsverlag GmbH, Bernd Oestereich, Analyse und Design mit UML2.1, 8.
Auflage, 2006, ISBN1-10: 3-4865-7926-6
[lit4]
O’Reilly Verlag GmbH, Alan Beaulieu, Einführung in SQL, 1. Korr. Nachdruck 2007, ISBN-10: 38972-1443-1
[lit5]
Galileo Computing, Thomas Theis, Einstieg in PHP 5.3 & MySQL 5.1, 5. aktualisierte Auflage 2009,
ISBN-13: 978-3-8362-1427-8
[lit6]
Galileo Computing, Gunner Thies & Stefan Reimers, PHP 5.3 und MySQL 5.1 das umfassende
Handbuch, 2. Auflage 2009, ISBN-13: 987-3-8362-1377-6
Internet:
[net1]
www.cakephp.org, Dez. 2009, Webseite des PHP-Frameworks CakePHP
[net2]
www.framework.zend.com, Dez. 2009, Webseite des Zend-PHP-Frameworks
[net3]
www.fusebox.org, Dez. 2009, Webseite des PHP-Frameworks Fusebox
[net4]
www.codeigniter.com, Dez.09 - Feb.10, Webseite des eingesetzten PHP-Frameworks CodeIgniter
mit Usermanuals, Download etc.
[net5]
www.symfony-project.org, Dez.09, Webseite des PHP-Frameworks Symfonie
[net6]
www.kohanaphp.com, Dez.09, Webseite des PHP-Frameworks Kohana
[net7]
www.phpunit.de, Jan.09, Webseite mit Informationen zum UnitTest-Framework phpUnit.
[net8]
www.jensroland.com/projects/toast, Jan.09, Webseite der UnitTest-Library Toast
[net9]
www.curl.haxx.se, Feb.09, Webseite des CURL-Tools
Remo Seiler, MAS-07-02
Seite 123 von 124
[net10]
www.tcpdf.org, Dez.09-Jan.10, Webseite der eingesetzten PDF-Library für PHP
[net11]
www.adldap.sourceforge.net, Dez.09 – Jan.10, Webseite der Eingesetzten LDAP-Library adLDAP
[net12]
kuler.adobe.com, Dez.09-Jan.10, Onlinetool von Adobe für die Zusammenstallung von Farbdesigns.
[net13]
www.css4you.de, Dez.09-Feb.10, Sehr ausführliches und verständliches CSS-Manual in deutscher
Sprache, viele gute Beispiele
[net14]
www.dynamicdrive.com/style, Dez.09-Jan.10, viele gute CSS-Beispiele
[net15]
www.berufsbildungscenter.ch, Oktober 2009, Webseite des Berufsbildungscenters Ascom, Login,
Post in Bern
[net16]
www.homepage-total.de/php/sicherheit.php, Jan.10, viele nützliche Informationen zum Thema
Web-Sicherheit.
[net17]
www.webdesignblog.de/webdesign/, Jan.10, Verschiedene Artikel unter anderem zum Thema
Sicherheit
[net18]
www.sparxsystems.com, Nov.09-Feb.10, Webseite der Firma Sparx Systems, Anbieter des UMLTools Enterprise Archtitect
[net19]
www.notepad-plus.sourceforge.net, Nov.09, Download und Information zum open source-Tool
Notepad++
[net20]
www.apachefriends.org/xampp.html, Dez.09, Download und Information zum Webserver-Paket
XAMPP
[net21]
www.mysql.de/products/workbench, Nov.09, Download und Information zu MySQL Workbench
[net22]
www.winscp.net, Nov.09, Download und Information zum FTP-Client WinSCP
[net23]
addons.mozilla.org/en-US/firefox/addon/60, Dez.09, Download des Webdeveloper-Addons für
Firefox
[net24]
www.selfhtml.org, Nov.09-Feb.10, Sehr ausführliches und verständliches HTML-Manual
[net25]
www.ch.php.net/manual/de/index.php, Dez.09-Feb.10, umfangreiches PHP-Manual (auch in deutscher Sprache)
[net26]
www.web-toolbox.net/webtoolbox, Dez.09, viele hilfreiche Tipps und Beispiele zu Webdesign, CSS,
HTML etc. (Beispiele für CSS-Buttons wurden verwendet).
[net27]
www.somacon.com, Dez.09 verschiedene Inhalte zum Thema Webdesign
[net28]
openbook.galileocomputing.de/oo, Bernhard Lahres, Gregor Raýman, Galileo Computing, Praxisbuch Objektorientierung, ISBN 3-89842-624-6, als OpenBook
[net29]
www.doxygen.org, Jan.10, open source Tool Doxygen zur Dokumentierung von Source Code.
[net30]
v.hdm-stuttgart.de/~riekert/lehre/db-kelz/, Nov.09, Andreas Kelz, Relationale Datenbanken
[net31]
http://dev.mysql.com/doc/, Dez.09-Jan.10, Reference Manuals MySQL
[net32]
www.phpframeworks.com/index.php, Nov.09, Übersicht verschiedener PHP-Frameworks.
[net33]
www.de.wikipedia.org, Okt.09-Feb.10, Verschiedene Artikel zu den Themen Webdesign, Analyse,
Design, UML, Tools, Sicherheit, etc.
[net34]
www.google.ch, 1997-2010, no comment…
Remo Seiler, MAS-07-02
Seite 124 von 124