MSP: HÜ Termine

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Diese Wiki-Seite dient zur Dokumentation der Hausübung "Termine", die im Rahmen des Moduls "Methoden des Softwareentwicklungsprozesses (MSP)" an der Fachhochschule Gießen-Friedberg im Wintersemester 08/09 bearbeitet wird. Verantwortlich für die Hausübung sind Jochen Clemens und Steffen Rupp.

Einleitung

In den folgenden Kapiteln wird die Arbeit an dem Termin-Modul von eStudy der FH Giessen-Friedberg dokumentiert. In diesem Artikel werden die Aufgaben beschrieben, die während dieser Hausübung von den Teammitgliedern zu erbringen waren. Ferner werden alle hierfür geleisteten Arbeiten an diesem Modul dokumentiert. Die jeweiligen Aufgaben wurden in einem Gespräch mit dem Dozenten abgesprochen und wurden bis zu definierten Terminen erfüllt.

Mit Hilfe des Terminkalenders können angemeldete Nutzer des eStudy persönliche Termine, Kurstermine und Foyertermine verwalten. Dabei besteht die Möglichkeit die Terminansicht zu filtern , um z.B. nur persönliche Termine angezeigt zu bekommen. Um die erstellten Termine auch in einer anderen Anwendung zu nutzen, können alle Termine in das iCalendar Format exportiert werden. Als weiteres Feature können die Termine eines Google-Accounts direkt im Terminkalender von eStudy angezeigt werden.

Bisherige Modulauthoren:

  • Benjamin Stadin <stadin@gmx.de>
  • Michel Kraemer <michel.kraemer@mni.fh-giessen.de>
  • Nadja Kruemmel <nadja@kruemmel.info>
  • Johannes Heinemann
  • Andreas Kahres <andreas.kahres@mni.fh-giessen.de>
  • Di Chang
  • Paul-Christian Volkmer <paul-christian.volkmer@mni.fh-giessen.de>
  • Sascha Henry <sascha.henry@mni.fh-giessen.de>
  • Jochen Clemens <jochen.clemens@mni.fh-giessen.de> Refactoring MSP WS 09/10
  • Steffen Rupp <steffen.rupp@mni.fh-giessen.de> Refactoring MSP WS 09/10

Verwandte Wiki Artikel

Aufgabenstellung

Folgende Aufgaben sind zu bearbeiten:

Bestandsaufnahme mittels Reverse Engineering

  • Use-Case-Diagramm
  • Klassendiagramm
  • DB-Schema
  • Code-Dokumentation mit Quelltext

Analyse mit Software Metriken

  • Code-Coverage
  • Zyklomatische Komplexität
  • C.R.A.P.-Index
  • DB-Queries

Refaktorisierung

  • Coderefaktorisierung hinsichtlich Performance-Optimierung. Lasttests mit dem Tool 'Apache JMeter'
  • Reduktion und Optimierung der DB-Abfragen
  • Caching mit Memcached
  • Code einheitlich strukturieren nach eStudy Programmiervorgaben (Wird kontrolliert durch Pre-commit Hooks beim Einchecken in SVN)
  • HTML Ausgabe vorbereiten für Internationalisierung
  • Einbindung des Moduls in den Datenauszug
  • HTML Ausgabe auf WAI-Konformität prüfen

Implementierung eines neuen Features

  • Import von Terminen im iCalendar Format
  • Teilweise Anpassung des iCalendar Exports, um konform zu bleiben
  • Erweiterung der DB um zusätzlich benötigte Attribute

Bestandsaufnahme des Moduls Termine

Use-Case Diagramm

Use Case Diagramm vom Gruppenterminkalender

Im Rahmen der ersten Aufgabe zur Hausübung wurde eine Bestandsaufnahme des Terminkalenders durchgeführt. Die Funktionalität des Kalenders wird durch das nebenstehende Use Case Diagramm abgebildet. Es gibt zwei Benutzergruppen, die unterschiedliche Rechte des Zugriffs auf den Kalender haben. Zum Einen sind dies Studenten, zu denen unter anderen auch noch Schüler, Alumnus, Sekretariat oder Gäste gezählt werden können. Zum Anderen gibt es die Gruppe Admins, zu denen auch die jeweiligen Dozenten des Kurses zählen. Der Akteur Student ist dabei bewusst größer dargestellt als der Akteur Admin. Dies soll symbolisieren, dass die Gruppe der Studenten zahlenmäßig größer ist als die der Admins und somit die Hauptnutzer darstellt. Bei der Bearbeitung der Aufgabe wurden folgende Use Cases des derzeitigen Kalenders herausgefiltert:

Termin Funktionalität

  • Termin anlegen
  • Termin löschen
  • Termin bearbeiten
  • Zu- und Absagen von Terminen verwalten

Bei der Terminverwaltung ist zu beachten, dass Studenten nur ihre eigenen Termine bearbeiten können. Administratoren sind in der Lage alle Termine zu verwalten, was allerdings beim Refactoring geändert wurde, die Verwaltung aller Termine ist dann nur noch als Admin direkt über die Datenbank machbar. Es können private Termine oder Gruppen-/Kurstermine angelegt und verwaltet werden. Je nach Terminart ist die Sichtbarkeit des jeweiligen Termins für die Gruppe/Kurs eingeschränkt. Auf diese Weise sind private Termine nur im eigenen Kalender und nicht durch andere Nutzer sichtbar, wohingegen Gruppen-/Kurstermine für alle Mitglieder des Kurses/Gruppe sichtbar sind.

Kalender Funktionalität

  • Termine anzeigen
  • Ansicht filtern
  • Google Kalender anzeigen
  • Kalenderlayout ändern
  • Kalender in das iCalendar Format exportieren

Die eingetragenen Termine werden automatisch in die Ansicht des Kalenders übernommen. Dabei werden unterschiedliche Farbcodierungen für Kurstermine, Foyertermine und private Termine benutzt. Die unterschiedlichen Terminarten besitzen verschiedene Eigenschaften. Bei Kursterminen haben Teilnehmer die Möglichkeit einen Termin zu- oder abzusagen, falls der Termin freiwillig ist oder innerhalb einer vom Dozenten definierten Gruppenzeit liegt. Bei verpflichtenden Kursterminen wird eine automatisierte Zusage generiert. Weiterhin kann man sich die Zu-/Absagen zum genannten Termin anzeigen lassen. Bei privaten Terminen stehen diese Möglichkeiten nicht zur Verfügung, da diese nur im eigenen Kalender angezeigt werden. Um die Übersichtlichkeit zu verbessern kann man die Ansicht des Kalenders nach Terminart (private, Team-, Kurs- oder Foyertermine) filtern. Auf diese Weise bekommt der Anwender eine Übersicht über die Termine, die ihn gerade interessieren. Alle anderen Termine werden ausgeblendet. Weiterhin bestehen zwei Kalenderlayouts, zum einen die Monatsansicht und zum anderen eine Wochenansicht. In beiden Ansichten besteht die Möglichkeit vor- oder zurückzublättern. Zum Schluss kann man noch alle seine Termine in das iCalendar Format exportieren.

Klassendiagramm

Klassendiagramm des Kalenders

Das Klassendiagramm zeigt die verwendeten Klassen des Moduls Kalender. Die Hauptklasse ist die Klasse 'Calendar' mit der die Termine verwaltet werden. Die Klasse 'GrouptimesOrganisation' verwaltet die gemeinsamen Gruppenzeiten eines Teams. Mit der Klasse 'Template' werden HTML Templates für die anderen Klassen bereitgestellt. Mit der Klasse 'Filter' können Termine in der Ansicht gefiltert werden. In der Klasse 'Functions' stehen Hilfsfunktionen des Kalenders bereit. Die Klasse 'KW' dient der Berechnung und Umrechnung verschiedenster Tage, Monate und Jahre, allerdings wird sie allem Anschein nach nicht verwendet. Schließlich stehen noch insgesamt drei Klassen für den Im- und Export der Termine im iCalendar Format in separaten Paketen bereit. Diese Klassen sind erst vor kurzem hinzugekommen, jedoch verfügt keine der Klassen bzw. keine der enthaltenen Methoden über eine Code-Dokumentation.

Übersicht über die Klassen des Moduls Termine

Die Beschreibung der Klassen ist hauptsächlich der Code-Dokumentation entnommen. Dort wo die Code-Dokumentation dürftig war, wurde eine Vermutung auf Grund der implementierten Methoden über die jeweilige Funktion der Klasse aufgestellt, d.h. es ist nicht sicher ob die unten stehende Beschreibung wirklich die Intension der ursprünglichen Entwickler ausdrückt.

Klasse Beschreibung
Calendar Verwaltet den Kalender mit eigenen, Team-, Kurs- und Foyerterminen, Erzeugt auch viel HTML Code für die Anzeige im Browser, sowie SQL Abfragen
GrouptimesOrganisation Verwaltet gemeinsame Gruppenterminzeiten
Template Verwaltet HTML Templates, die zur Anzeige des Kalenders benötigt werden
Filter Verwaltet Filter für die Filterung von Terminen
Functions Verwaltet Hilfsfunktionen für die Klasse Calendar
CalendarAutomation Handelt die automatisierten Funktionen des Frameworks bezüglich des Kalenders ab
Database Stellt besondere Funktionen bereit, die beim Export von Terminen aus der Datenbank ins iCalendar Format benötigt werden
iCalendar Erzeugt allgemeinen iCalendar formatierten Code für den Export ins iCalendar Format
iCalendarEvent Erzeugt iCalendar formatierten Code für den Export von Terminen ins iCalendar Format
Import_GCalendar Importiert und verwaltet Termine aus einem Google Kalender
KW Stellt Methoden zur Umformung eines Datums für die Datenbank bereit

Datenbank Schema

Momentanes Datenbank Schema des Terminkalenders

Das Datenbank Schema des Moduls Termine wurde mit Hilfe des Tools MySQL Workbench erstellt. Dem Modul Termine werden insgesamt acht Tabellen innerhalb von eStudy zugeordnet. Die Tabellen stehen teilweise in Beziehung untereinander. Zusätzlich wird auf vier weitere Tabellen von eStudy zugegriffen. Diese sind im vorhandenen Datenbank Schema nur über die Fremdschlüssel referenziert. Folgende Tabellen werden innerhalb des Moduls Termine verwendet:

  • calendar
  • calendar_user
  • calendar_courses
  • calendar_teams
  • calendar_acknowledgement
  • calendar_frame
  • calendar_frame_teams
  • calendar_frame_courses

Mit Hilfe der Tabellen "calendar", "calendar_user", "calendar_teams", "calendar_courses" und "calendar_acknowledgement" werden die Termine unter der eindeutigen eventid in der Datenbank hinterlegt. Über die eventid, welche der Primärschlüssel von "calendar" ist und Fremdschlüssel der andern genannten Tabellen, lässt sich auf einen eingetragenen Termin immer exakt referenzieren. Auf die Tabellen "user", "teams", "courses" und "user_course" wird über die Fremdschlüssel zugegriffen und benötigte Verknüpfungen werden so ermöglicht. Durch diese Verknüpfung lässt sich erst exakt verifizieren, ob der Benutzer Mitglied im richtigen Team ist, bzw. den entsprechenden Kurs belegt. Diesbezüglich werden dann die entsprechenden Termine angezeigt. Über die drei verbleibenden Tabellen wird es dem Benutzer ermöglicht Gruppenzeiten zu definieren. Hier kann hinterlegt werden zu welchen Zeitpunkten ein Dozent Termine für die Gruppe festlegen kann, ohne dass die Gruppenmitglieder explizit zustimmen müssen. Dies können zum Beispiel Vorlesungszeiten oder ähnliches sein. Auch in diesen Tabellen werden Fremdschlüssel verwendet, um auf die Tabellen "courses" und "teams" zuzugreifen.

Verwendung von SQL DATETIME im PHP Code

Zur Umwandlung eines DATETIME Datentyps in ein PHP timestamp und umgekehrt wird folgende Vorgehensweise empfohlen:

  • Von MySQL DATETIME nach PHP timestamp: $phpstamp = strtotime($mysqldate); ($phpstamp enthält nun als integer-Wert die Sekunden seit dem 1.1.1970 00:00; negative integer-Werte liefern eine Zeit vor diesem Datum. Somit ist eine Zeitspanne von Fr, 13. Dez 1901 20:45:54 GMT bis Di, 19. Jan 2038 03:14:07 GMT ab PHP v5.1.0)
  • Von PHP timestamp in MySQL DATETIME: $mysqldate = Output::echoDate('Y-m-d H:i:s',$phpstamp); (Der Vorteil der Funktion Output::echoDate ist, dass statt einem PHP timestamp auch ein Datumsstring übergeben werden kann, da die Funktion dies erkennt und intern dann auch 'strtotime' verwendet und schließlich mit 'gmdate' formatiert.)

Beschreibung der Datenbanktabellen

DB-Tabelle Beschreibung
calendar Enthält alle zu einem Termin gespeicherten Daten. Dabei fehlt noch ein Eintrag dazu, wer den Termin angelegt hat.
calendar_user In der Tabelle werden alle privaten Termine eines Benutzers gespeichert, die über die eventID in der Tabelle calendar referenziert werden.
calendar_courses In der Tabelle werden alle Termine gespeichert, die für alle Kursmitglieder sichtbar sind. Referenziert wird über die eventID auf calendar.
calendar_teams Die Tabelle enthält alle Termine die einem bestimmten Team zugewiesen sind. Sie werden über die eventID auf calendar referenziert.
calendar_acknowledgement In der Tabelle werden die Zu- und Absagen zu Terminen verwaltet.
calendar_frame Hier werden die Gruppenzeiten von einem Administrator/Dozent hinterlegt.
calendar_frame_teams In der Tabelle werden die Gruppenzeiten mit einem Team verknüpft. Referenziert wird über die frameID als Fremdschlüssel aus der Tabelle calendar_frame.
calendar_frame_courses In dieser Tabelle werden die Gruppenzeiten mit einem Kurs verknüpft. Referenziert wird über die frameID als Fremdschlüssel aus der Tabelle calendar_frame.

Beschreibung der wichtigsten Attribute der Datenbanktabellen

Tabelle Attribut Beschreibung
calendar eventid Eindeutige ID eines Termins
eventtime Startzeit eines Termins im Format YYYY-MM-DD HH:MM:SS (DATETIME)
eventsubject Kurze Beschreibung eines Termins (bis zu 255 Zeichen)
eventtext Lange Beschreibung eines Termins (bis zu 65536 Zeichen)
eventactive Soll angeben ob ein Termin aktiv oder inaktiv ist, wird aber nicht genutzt und ist unserer Meinung nach überflüssig (Werte: 0 und 1, Standard: 1 (true))
wholetime Gibt an ob der Termin ganztägig ist oder nicht. Wirkt sich auf die Anzeige der Uhrzeit aus. Mehrtägige ganztägige Termine sollten den Wert 1 bekommen (Werte: 0 und 1, Standard: 0 (false))
facultative Gibt an ob ein Termin freiwillig ist (Werte: 0 und 1, Standard: 0). Unserer Meinung nach sollte die Spalte eher 'compulsory' heißen und angeben ob ein Termin verpflichtend ist und als Standard 0 haben.
calendar_acknowledgement eventID ID eines Termins in der Tabelle 'calendar'
userID ID eines Nutzers der zu dem Termin eingeladen wurde
ack Gibt an ob der Nutzer dem Termin zugesagt hat oder nicht (Werte: 0 und 1, Standard: 0)
reason Optionale Begründung für eine Zu- oder Absage
calendar_frame ID Eindeutige ID einer Gruppenzeit
startday Nummer des Wochentags, an dem die Gruppenzeit beginnt (Werte 1 bis 7, Standard: 1 (Montag))
endday Nummer des Wochentags, an dem eine Gruppenzeit endet (Werte 1 bis 7, Standard: 7 (Sonntag))
starttime Startuhrzeit am angegebenen Tag in 'startday' (Standard: 00:00)
endtime Enduhrzeit am angegebenen Tag in 'endday' (Standard: 23:59)

Code Dokumentation

Die Codedokumentation wurde mit dem Dokumentationstool DoxyGen erstellt und ist hier verfügbar. Durch spezielle Kommentare innerhalb der Klassen kann DoxyGen die Kommentare erkennen und für die Dokumentation der Klassen nutzen. Alle Klassen die für den Test des Moduls Termine existieren, wurden aus der Dokumentation ausgeschlossen, um eine gewisse Übersichtlichkeit zu wahren.

Software Metriken

Die Übersicht der Softwaremetriken des Moduls Termine wurde mit PHPUnit erstellt, welches ein XML Dokument erzeugt. Dieses Dokument wird mittels XSLT in HTML transformiert. Das Ergebnisdokument enthält alle wichtigen Metriken der im Modul Termine verwendeten Klassen und Methoden, unter anderem Code-Coverage, Zyklomatische Komplexität und den C.R.A.P.-Index. Eine graphische Übersicht der Code-Coverage wurde ebenfalls mit PHPUnit erstellt.

Um die Metriken überhaupt erfassen zu können, mussten wir die vorhandenen Unit Tests an einen neuere Version von phpUnit anpassen, damit wir sie überhaupt zum laufen bekamen. Dabei stellten wir fest, dass nicht alle Klassen und erst recht nicht alle Methoden einen Unit Test besaßen. Weiterhin schlugen über die Hälfte der Unit-Tests fehl, was einer weiteren Überprüfung bedurfte. Daraus resultieren auch die teilweise relativ schlechten Metriken, die der xml-Datei entnommen werden können.

Bis auf zwei Klassen (Filter und Import_GCalendar) werden durch die Testfälle alle Klassen abgedeckt. Weiterhin werden allerdings nur 56% der Methoden und nur 30% der gesammten Codezeilen durch Testfälle abgedeckt. Den höchsten C.R.A.P Index haben die Methoden combineBlocks (1482), do_addGrouptimeBlock (1260) in der Klasse GrouptimesOrganisation und die Methode showEventList (870) in der Klasse Calendar. Viele andere Methoden haben Werte zwischen 50 und 400, was darauf deutet, dass der Code sowohl ziemlich komplex als auch von Testfällen nicht genügend abgedeckt ist. Daher ist es das Ziel des Teams neben dem Refactoring des Codes, vorhandene Testfälle zu prüfen und fehlende zu ergänzen. Das wird folgenden Entwicklern die Arbeit mit dem Code erleichtern, da dann eine gewisse Übersichtlichkeit des Codes und Sicherheit beim erneuten Refactoring oder der Weiterentwicklung gegeben ist.

DB-Queries und Performance (vorher)

Um etwas über die Performance des Moduls Termine herauszufinden wurden Daten durch das Profiling mit Xdebug gesammelt und mit Kcachegrind grafisch aufbereitet. Im Folgenden sieht man die Graphen der Aufrufe der Methoden iCalendarEvent->__construct(), calendar->__construct() und calendar->showCalendar().

Bad Smells

Ein "schlechter Geruch" des Programmcodes weißt auf Probleme im Programm hin. Um diese Gerüche zu identifizieren wurden von Fowler und Beck einige Bad Smells definiert. Im folgenden haben wir einige Bad Smells des eStudy Moduls Kalender zusammengestellt:

  • Duplicated Code: Die Klasse KW ist ebenfalls im Modul News enthalten. Im Modul Termine wird sie zudem nicht benutzt.
  • Large Class: Die Klasse Calendar ist sehr groß (1713 Zeilen);
  • Large Method: Die Methoden do_newcevent, showWeek, getFilteredEvents, showCalendar und sendGroupMessage der Klasse Calendar beeinhalten 100 oder mehr Zeilen. Die Methode d_addGrouptimeBlock der Klasse GrouptimesOrganisation beeinhaltet mehr als 100 Zeilen.
  • Long Parameter List: Die Methode in Grouptime der Klasse Kalendar hat sechs Parameter die beim Aufruf übergeben werden müssen. Ebenso die Methode sendGroupMessages.

Teilweise wurden extrem viele if Statements verwendet, die ineinander verschachtelt sind. Die Prüfung auf true oder false ist in vielen Fällen nicht mehr nachvollziehbar. Ein Beispiel dafür findet sich in der Klasse GrouptimesOrganisation, Methode combineBlocks:

  • ($startday < $e_startday && $endday < $e_startday && ($startday+7) > $e_endday) || ($startday > $e_endday && $endday > $e_endday && ($endday-7) < $e_startday) || ($startday == $endday && $startday == $e_startday && $endday == $e_endday && ($starttime > $e_endtime || $endtime < $e_starttime)

Im Modul Kalendar ist dies kein Einzelfall und erschwert die Lesbarkeit des Codes enorm.

  • Viele Methoden geben direkt HTML Code aus. Dieser könnte auch in Templates ausgelagert werden, um die Klassen besser zu testen. Weiterhin solltem CSS Anweisungen in die schon vorhandene css-Datei fließen.
  • Viele Testfälle schlagen fehl, was im nachhinein behoben wurde
  • Viele öffnentliche Methoden geben keinen konkreten Wert (z.B. true/ false) zurück, sondern geben Fehlermeldungen durch einen redirect auf eine andere Seite aus und leiten dann wieder zurück zum Kalender, dadurch wird das Testen ebenfalls erschwert.
  • Ein Großteil der Methoden gibt keinen konkreten Rückgabewert zurück, sondern führt am Ende direkt eine Redirect auf eine andere Seite aus, dadurch wird das Testen erschwert. Dies schlägt sich auch in der Art und Weise wieder, wie die vorhandenen Testmethoden geschrieben wurden. Viele machen keine Unit Tests sondern Oberflächen (GUI) Tests, in denen der HTML Code des Redirects überprüft wird, ob ein bestimmter String enthalten ist.

Erweiterung des Kalenders & Refaktorisierung

Definition eines neuen Features

Im Rahmen dieser Veranstaltung soll der Kalender um ein Feature erweitert werden. Der Kalender beinhaltet bereits einen Export ins iCal Format. Ein entsprechender Import des Formats in den Kalender soll durch das neue Feature ermöglicht werden. Dazu sind folgende Schritte durchzuführen:

  • Erstellen eines Templates zum Hochladen von iCal-Dateien (erledigt)
  • Erstellen neuer Klasse, die das Importieren von iCal-Dateien ermöglichen (Scanner, Parser, ...) (erledigt)
  • Erstellen von Testfällen für die neuen Klasse. (erledigt)
  • Überarbeiten der Kalendertabellen in der Datenbank.
    • Feld für Endzeit eines Termins hinzufügen. (erledigt)
    • Anpassen des vorhandenen Codes um auch Endzeiten von Terminen zu verwalten. (erledigt)
  • Import wiederholender Termine. (erledigt)
    • Datenbankfeld in der Tabelle calendar für wiederholende Termine hinzufügen. (erledigt)
  • Löschen und bearbeiten (Titel und Beschreibung) von wiederholenden Terminen als Gruppe. (erledigt)

Wie wurden die Features umgesetzt?

Um das Feature für den Import von iCal Dateien umzusetzen haben wir zunächst ein HTML Formular programmiert, mit dem man .ics Dateien auswählen und importieren kann. Dasu muss der Nutzer nun auf den neuen Link "iCalendar-Import" über dem Kalender klicken. Diese Platzierung haben wir aufgrund der Tatsache vorgenommen, dass der Export dort auch zu finden ist. Später könnte der Link auch durch ein entsprechendes Symbol ersetzt werden.

Da Termine nicht nur einen Startzeitpunkt haben sondern auch einen Endzeitpunkt musste ein neues Feld 'endtime' (DATETIME) zur Tabelle 'calendar' hinzugefügt werden und alle Klassen und HTML Dateien dementsprechend angepasst werden, was viel Zeit gekostet hat.

Das Parsing der ics-Datei erfolgt in der neuen Klasse 'ICalendarImport' mittels eines riesigen Switch-Case Konstrukts. Dieses erstellt ein mehrdimensionales Array von Terminen und übergibt es an die eigentliche import-Methode, welche das Array auswertet und mit Hilfe der Methode 'doNewcevent' der Klasse 'Calendar' in die Datenbank einträgt. Die Switch-Case Methodik ist nicht die eleganteste Methode für einen Parser, jedoch am schnellsten zu realisieren. Eine bessere Methode wäre es gewesen, für jede Komponente des iCal Formates eine eigene parsing Methode zu schreiben, welche dann gemeinsam das große Array erstellen. Der Code wäre dann besser wartbar und erweiterbar und nicht mehr so unübersichtlich. Ähnlich sieht es aus bei der Auswertung von wiederholenden Terminen. Dabei benutzen wir eine Menge If-Else-Konstrukte. Es wäre allerdings besser bei zukünftigen Refactorings sich den Code des RRULE Auswerters des Programms 'PHP iCalendar' anzuschauen oder den RRule-Helper Klasse des Programms 'SG-iCalendar'. Dazu hatten wir allerdings nicht mehr die Zeit. Wiederholende Termine werden daher nur importiert und eingetragen wenn folgende Regel in der iCal Datei angegeben wird:

  • RRULE:FREQ=WEEKLY;UNTIL=...;BYDAY=...

Damit ist es immerhin möglich exportierte Stundenpläne von der MNI Homepage zu importieren. Für weitere Möglichkeiten muss dann unser Code dem RFC entsprchend erweitert werden. Zusätzlich können zusammenhängende wiederholende Termine gemeinsam bearbeitet (beschränkt sich allerdings auf den Titel und die Beschreibung) und gelöscht werden. Dazu haben wir ein zusätzliches Feld 'recurringid' in die Tabelle 'calendar' eingefügt. Der Inhalt hat folgende Bedeutung:

  • Bei nicht wiederholenden Terminen wird dieses Feld mit einer 0 gefüllt
  • Beim ersten aller zusammenhängender wiederholender Termine steht in diesem Feld eine -1
  • Alle anderen wiederholenden Termine bekommen die eventid des ersten wiederholenden Termins eingetragen.

Weitere Änderungen und Ergänzungen des Kalenders

Beim Walkthrough mit dem Dozenten durch das Modul wurden einige Eigenschaften des Kalenders angesprochen, die verändert werden sollen, falls noch Zeit bleibt. Ansonsten könnten dies Aufgaben für zukünftige Refactorings sein:

erledigte Aufgaben

  • Umbenennung von "Fakultativer Termin" -> Kein Mensch kann sich etwas darunter vorstellen
  • Anlegen von leeren Terminen (ohne Titel) unterbinden
  • Beim Löschen eines Termins erscheint ein Popup mit einem Rechtschreibfehler
  • Aktuellen Tag stärker/farblich hervorheben. Eine neue Style Klasse wurde definiert, welche den aktuellen Tag grau hinterlegt. Diese Style Klasse kann von dem Standard Style für einheitliche Darstellung überschrieben werden.
  • KW farblich hinterlegen z.B. grau wie die erste Zeile (Wochentage) der Tabelle
  • Eingabemaske für das Anlegen von Terminen erweitern um ein von...bis... Feld
  • Admin darf die Termine von Kursmitgliedern und Teammitgliedern nicht sehen und auch keine Termine für Kurse anlegen, wenn er nicht die Dozentenrachte für den jeweiligen Kurs besitzt.
  • Beim iCal Export wird der lange Beschreibungstext eines Termins auf 100 Zeichen beschnitten, dieser sollte jedoch nach 75 Zeichen laut RFC 5545 umgebrochen werden, wobei jede neue Zeile mit einem whitespace-Zeichen beginnen muss.
  • Endzeit von Terminen wird beim Export nicht berücksichtigt
  • Beim Löschen eines Termins in einem zukünftigen Monat wird automatisch zum aktuellen Monat zurückgesprungen, es sollte jedoch zum Monat zurückgekehrt werden, in dem der Termin gelöscht wurde
  • Entfernen der ungenutzten Klasse KW und der Testfälle, da die gleiche Klasse im Modul Aktuell vorhanden ist und dort genutzt wird.
  • Entfernen einer veralteten SQL Datei und aktualisieren der aktuellen calender.sql sowie erstellen einer migration.sql mit den neusten DB-Anpassungen
  • Datenauszug vom Kalendermodul unterstützen
  • Einführung von Auswahlfeldern für Jahr, Monat, Tag, Stunde und Minute beim Neuanlegen und Ändern von Terminen und Beschränkung der Auswahl von Minuten auf einen 5-Minuten-Takt, da Termine nicht genauer geplant werden müssen.

nicht erledigte Aufgaben

  • Übersetzung der Texte, die im Modul Kalender verwendet werden
  • Farbsemantik der verschiedenen Termine als Tooltip oder Legende erklären
  • Überprüfung des Codes auf WAI-Konformität -> Code ist insofern nicht WAI-konform, da eine Vielzahl von in sich verschachtelten Tabellen verwendet werden. Die muss in einem umfangreichen Refactoring beseitigt werden mit z.B. div-Elementen und entsprechendem CSS

Übersicht über Dateien, die während des Refactorings bearbeitet wurden

Beim Refactoring, Anpassen von Dateien, Ändern wegen Precommits und Umsetzen der neuen Features wurden im Modul Kalender unter anderem zwei neue Klassen eingeführt und viele Dateien angepasst, damit das Feature iCal-Import umgesetzt werden konnte. Es folgt eine Auflistung aller geänderter Dateien die das Modul Kalender betreffen:

Allgemein

Klassen

Unit Tests

Templates

Skripte

Allgemeine Änderungen

Änderungen an Dateien fremder Module

Was ist nötig für eine Migration in den Trunk?

  • Dateien im Modul Calender im Branch sind mit dem entsprechenden Ordner im Trunk gemerged
  • Einspielen der Datei migration.sql in die Datenbank
  • Übernehmen der Änderungen aus dem Branch

TODO für spätere Refactorings

  • Der Datenauszug wurde so implementiert, dass dem eingeloggten Benutzer die Termine angezeigt werden die ihm zugewiesen werden können. Dies sind alle privaten Termine die in der Tabelle calendar_user gespeichert werden. Wenn der zur Zeit angemeldete Benutzer einen Teamtermin eingetragen hat, kann dies über die DB nicht mehr nachvollzogen werden.
    • --> Allgemein ist hier Handlungsbedarf um zu einem Terminen abzuspeichern, wer diesen angelegt hat. Dazu müsste die Tabelle calendar erweitert werden und die SQL-Anweisungen für einfügen, bearbeiten und löschen im Modul angepasst werden.
  • Beim Datenauszug wurden die Benutzerrechte außer Acht gelassen. Das heißt Foyer Termine werden dem Administrator nicht angezeigt, obwohl nur dieser einen Foyer Termin eintragen kann. Ebenso für Dozenten, die Kurstermine eintragen. Eine Lösung würde ebenfalls der vorangegangene Punkt bringen.
  • Trennen von Datenbank-, Unit- und GUI-Tests
  • Eliminierung der Fehler- oder Erfolgsmeldung während eines Redirects (dies wird nur 2 Sekunden angezeigt, längere Zeiten sind auch keine Lösung) => Besser Fehler in Rot über dem soeben abgesendeten Formular und Erfolgsmeldungen in grün über dem Kalender
  • Ersetzen der Links über dem Kalender (Ansicht filtern, iCalendar-Export, iCalendar-Import, Google-Termine anzeigen) durch entsprechende Symbole
  • Die Symbole zum Wechseln der Ansicht zum nächsten/vorherigen Monat/Woche, welche nur aus >> und << bestehen sind viel zu klein selbst für motorisch nicht beeinträchtigte Nutzer schwer zu treffen.
  • Außer einer Monats- und Wochenansicht wäre eine Listenansicht und eine Tagesansicht sinnvoll. Bei einer Listenansicht könnte man die angezeigten Termine durch eine Auswahl beschränken auf 'Alle Termine', 'Heutige Termine', 'Termine in den nächsten 7 Tagen', 'Termine in den nächsten 14 Tagen', 'Termine in den nächsten 31 Tagen', 'Termine in diesem Monat' 'Termine im nächsten Monat', 'Alle vergangenen Termine' und 'Alle zukünftigen Termine'.
  • Optionales senden einer Erinnerung an einen Termin z.B. eine Stunde vor Beginn per Mail an den Ersteller bzw. an alle Teilnehmer (Weiteres optionales Auswahlhäckchen im Formular für neue Termine)
  • Natürlich sollten die von uns noch nicht erledigten Aufgaben ebenfalls zeitnah umgesetzt werden.
Mögliches zukünftiges Tabellen Schema für das Modul Terminkalender
  • Für einen zukunftsweisenden Terminkalendar müsste das Datenbankschema komplett überarbeitet werden und demzufolge auch alle SQL-Abfrage in den Klassen. Wir haben uns überlegt, dass die Tabellen calender_teams, calendar_courses und calendar_user komplett wegfallen könnten, da im Programmcode beim Anlegen eines Termins höchstens ein Eintrag in höchstens eine der drei Tabelle geschrieben wird. D.h. obwohl logisch gesehen zwischen den drei Tabellen und der Tabelle calendar eine 1:n Beziehung besteht wird im Programm eine 1:1 Beziehung implementiert. Bei Teams und Kursen ist das nicht weiter schlimm, es verhindert jedoch, dass es zu einem Termin mehrere Teilnehmer geben kann. Dies wird momentan indirekt abgebildet. In der Tabelle calendar_user steht nur der Benutzer der den Termin angelegt hat und das auch nur wenn es ein privater Termin ist. Da die drei Tabellen sonst auch keine weiteren Informationen abspeichern, können die drei Felder in die Tabelle integriert werden. Der Programmcode müsste dann so abgeändert werden, dass zu einem Termin immer eine Benutzer ID abgespeichert wird und zusätzlich die Team ID bei Teamterminen oder die Kurs ID bei Kursterminen. Bei privaten Terminen bleiben Team ID und Kurs ID leer und ein Feld is_private könnte auf eins gesetzt werden. Das erleichtert die Abfrage von privaten Terminen. Zusätzlich könnten noch weitere Felder hinzugefügt werden, die weitere Informationen über einen Termin enthalten. Das Attribut eventactive fällt komplett weg, da es momentan nicht benutzt wird und inaktive Termine logisch gesehen keinen Sinn machen. Um das Konzept zu verdeutlichen haben wir hier ein MYSQL Schema für den Kalender erstellt, wie es bei zukünftigen Refactorings umgesetzt werden könnte. Der Einfachheit halber haben wir daraus gleich ein sql-Skript generiert, welches dann benutzt werden kann.

Vorschlag für Organisation der Wikiartikel bei zukünftigen Refactorings

  • Für jedes eStudy Modul gibt es einen zentralen Wikiartikel, wo grundlegende aktuelle Informationen über das Modul drin stehen (Was bezweckt das Modul, welche Gedanken stecken dahinter, Klassendiagramme, Use-Cases, Datenbankschemata, usw.) Alle Artikel der Module sollten schematisch gleich aufgebaut sein.
  • Für jede Refactoring Gruppe ist dieser zentrale Artikel der Leitartikel für das Modul. Alle von der Gruppe gemachten Änderungen werden in einem separaten Wikiartikel dokumentiert und der Leitartikel muss nach getaner Arbeit auch auf den aktuellen Stand gebracht werden. Was vorher war interessiert eh nicht bzw. kann immer noch in der Versionierung nachgeschlagen werden.