MSP: HÜ Kurs/eCom organisieren

Aus THM-Wiki
Wechseln zu: Navigation, Suche


Allgemein

Auf dieser Wiki-Seite werden die Hausübungen unserer Gruppe im Fach Methoden des Softwareentwicklungsprozesses (WS 2009/2010) dokumentiert. Das Modul Kurs/eCom organisieren der Open Source Lern- und Kollaborationsplattform soll bearbeitet - genauer: refaktorisiert - werden.

Die Gruppe besteht aus:

  • Krauss, Christian
  • Eckel, Michael

Es sind folgende nicht-funktionale Anforderungen zu beachten.

Nicht-funktionale Anforderungen an das Modul

  • Internationalisierung
  • Benutzbarkeit
  • Performance
  • Fehlertoleranz
  • Verfügbarkeit
  • Sicherheit
  • Datenschutz
  • Barrierefreiheit
  • Benutzerdokumentation


Reverse Engineering

Datenbankschema (Auszug)

Datenbankschema
Tabelle Beschreibung
courses Speichert Informationen über Kurse und eCommunities. Beinhaltet eine Spalte Type, die angibt, ob es sich um einen Kurs oder eine eCommunity handelt.
courseassemblies Hier werden die Arten für Voreinstellungen eines Kurses gespeichert; auch "Vorlagen" oder "Konfektionierte Kurse" genannt.
courseassembly_settings Einstellungen für die oben genannten "Vorlagen" für Kurse.
course_policy Wenn ein Kurs eine Policy besitzt, dann ist diese hier zu finden.
course_tree Informationen zur Baum-basierten Kursansicht.

Use-Case-Diagramm

Info.png

Das Use-Case-Diagramm wurde überarbeitet und ist nun auf dem Stand nach der Refaktorisierung.

Use-Case-Diagramm

Klassendiagramm(e)

Tabelle Beschreibung
ModulegroupConfiguration Konfiguration der Modulgruppen
EditIndicator Statistik-Klasse
UserGroupManagement Administration der Kursbenutzergruppen
AssistController Kontrollsteuerung für Assistensmodus
CoursePolicy Kurs-Policy
ContextNews Stichwort-Extraktion
Settings Veranstaltungseinstellungen

Code-Dokumentation

Die Online-Version der Code-Dokumentation ist hier zu finden. Die Offline-Version kann hier heruntergeladen werden: Datei:Msp hue ecom-kurs-organisieren doxygen.zip


Software-Metriken

Code-Coverage

Die Ergebnisse der Code-Coverage-Analyse mittels phpUnit ist hier zu finden.

Die Code-Coverage-Analyse hat im ersten Durchlauf eine Coverage von 0% ergeben, weil keine Testfälle vorhanden waren. Mit Hilfe von phpUnit wurden daraufhin Skeletons erstellt, was Testklassen entspricht, die nur das Grundgerüst zum Testen beinhalten.

Zyklomatische Komplexität und C.R.A.P.-Index

Die Ergebnisse zur zyklomatischen Komplexität und des C.R.A.P.-Indexes für die verschiedenen Klassen sind hier zu finden. Das Analyse-Tool war auch hier phpUnit. Die von phpUnit erzeugte XML-Datei wurde mittels einer XSL-Transformation unter Zuhilfenahme des Linux-Kommandozeilentools xsltproc und eines geeigneten XSLT-Stylesheets in HTML umgewandelt.


CacheGrind

Mit Hilfe von Xdebug wurden Log-Dateien der Aufrufe erstellt, welche dann mittels kCacheGrind visuell zu einem Aufrufgraphen aufbereitet wurden. Um die Aufrufe mitzuloggen, mussten in der Datei /etc/php5/apache2/php.ini der eStudyDev-VM folgende Zeilen eingefügt (am Ende) werden:

xdebug.profiler_enable=1
#xdebug.profiler_output_dir /home/estudydev/Desktop/cachegrind
xdebug.profiler_output_name="%u_%H_%R_%s.out"

Die mit "#" auskommentierte Zeile hat keine Wirkung gezeigt, obwohl laut Dokumentation mit diesem Schalter der Default-Log-Datei-Pfad /tmp geändert werden kann. Deshalb wurde die Zeile hier auskommentiert und die og-Dateien wurden in /tmp abgelegt. Nach dieser Änderung musste der Apache Web-Server mit apache2ctl restart (als Root) neugestartet werden.

Im Folgenden sind die Aufrufgraphen für je einen Kurs und eine eCommunity zu sehen. Dabei wurde je ein Klick auf "Kurs|Ecom organisieren" ausgeführt.

Auffällig sind folgende Aspekte:

Viele Datenbankabfragen
Beim Aufrufsgraphen zu einem Kurs werden sehr viele Datenbankabfragen ausgeführt. Die Methode Style->getStyleTemplates ruft 49 Mal die Methode ezdb->get_var auf, welche ihrerseits wiederum 64 Mal die Methode ezdb->query aufruft. Letztere führt jedes Mal eine Datenbankabfrage durch. Der komplette Aufrufpfad bis zur Methode Style->getStyleTemplates ist {main} > Settings->echoSettingsDialog > SettingsDialog->__construct > SettingsDialog->printStyleRow > Style->getStyleTemplates.
Viele Aufrufe von Data->toHTML
Beim Aufrufsgraphen zu einer eCommunity wird die Methode 2309 Mal und beim Aufrufsgraphen zu einem Kurs 2311 Mal ausgeführt.

Refactoring und Feature-Implementierung

Zu implementierende Features (Teil 1)

1. Kurzname zur Teilnehmer-Auswahlliste hinzufügen (erledigt)
In der settings.php wird unten eine Liste mit Teilnehmern dargestellt. Diese Teilnehmer können zu einem Kurs bzw. einer eCommunity hinzugefügt werden. Momentan werden die Einträge in der Form Name, Vorname dargestellt. Da es aber einige Personen gibt, die den gleichen Namen haben, sollen zusätzlich die Kurznamen angezeigt werden.
Bearbeitungsdokumentation:
Gemäß Anforderung wurden die Kurznamen der Benutzer in Klammern hinter den normalen Namen der Benutzer angezeigt.
2. Reaktivierung eines archivierten Kurses (erledigt)
Nach dem Reaktivieren eines Kurses bzw. einer eCommunity wird das aktuelle Semester angezeigt und nicht das Semster, mit dem der Kurs archiviert wurde. Beispiel: Kurs wurde mit Semester WS08/09 archiviert und steht nach dem rearchivieren auf WS09/10. Bei der Reaktivierung eines archivierten Kurses soll aber das Semester angenommen werden, das in dem Kurs ursprünglich eingetragen war.
3. Einladung von neuen Kursteilnehmern - Teil 1 (erledigt)
Neuer Kursteilnehmer soll Einladung per PN und E-Mail erhalten.
Bearbeitungsdokumentation:
Zwei neue Checkboxen wurden zum Punkt "Hinzufügen neuer Teilnehmer durch Einladung" hinzugefügt. Durch Abhaken der Checkboxen kann entschieden werden ob der Benutzer bzw. ob die Benutzer, wenn durch Mehrfachauswahl mehrere gewählt wurden die Einladung durch E-Mail und/oder private Nachricht erhalten sollen.
Bei der Auswertung des Formulars wird eine individualisierte Nachricht erstellt und über die in eStudy integrierte Funktionalität eine E-Mail/PN an die/den ausgewählten Teilnehmer versendet.
Der Punkt "Manuelles Hinzufügen von Kurs/eCom Teilnehmern durch Einladung" wurde in das Erscheinungsbild integriert (siehe im Vergleich altes/neues Erscheinungsbild).
4. Einladung von neuen Kursteilnehmern - Teil 2 (erledigt)
Neuer Kursteilnehmer soll, wenn er dem Link auf der Einladung folgt, direkt auf der Seite des Kurses landen und nicht im Forum.
Bearbeitungsdokumentation:
Die vom Dozenten bzw. Moderator ausgesprochenen Einladungen enthalten einen Link für die direkte Anmeldung (siehe: Beispiel für eine Einladung per E-Mail unter Punkt 3). Beim Erstellen dieser Einladung wird diese in der Datenbank festgehalten. Folgt ein Benutzer dem Link in der Einladung, wird er auf ein neu angelegtes Formular geleitet in dem der Benutzer die Möglichkeit hat die Einladung anzunehmen bzw. abzulehnen. Aufgrund des Eintrages in der Datenbank kann die eStudy Software feststellen, ob eine Einladung vorliegt. Bei Annahme bzw. Ablehnung der Einladung wird der Link aus der Datenbank gelöscht und die Einladung ist nicht mehr gültig. Dadurch das eine Einladung gezielt durch einen Dozenten oder Moderator ausgesprochen wird ist ein direktes Anmelden möglich und eine evtl. Warteliste wird dabei übergangen.
5. Einladung von neuen Kursteilnehmern - Teil 3 (erledigt)
Einladender soll Vollzugsmeldung der Einladung per E-Mail erhalten. Das heißt, wenn der Eingeladene die Einladung annimmt oder auch ablehnt, soll der Einladende eine Meldung per PN und E-Mail darüber bekommen, ob der Eingeladene die Einladung angenommen bzw. abgelehnt hat.
Bearbeitungsdokumentation:
Bei Annahme bzw. Ablehnung der Einladung über das Formular aus Punkt 4 wird eine spezifische E-Mail erstellt die alle Dozenten bzw. Moderatoren über die Entscheidung des eingeladenen Benutzers informiert. Diese E-Mail wird über die in der eStudy Software vorhandene Funktionalität versendet.
6. Einladung von neuen Kursteilnehmern - Teil 4 (erledigt)
Einladender soll den Versand einer Einladung ansprechender angezeigt bekommen als bisher (evtl. mit einer grün unterlegeten Meldung).
Bearbeitungsdokumentation:
Der einladende Dozent erhält eine Anzeige, ob die Einladung wie gewünscht ausgeführt wurde (siehe Bild).
(Fehler beseitigt). In diesem Zusammenhang ist ein Fehler aufgetreten wenn aus der Liste kein Teilnehmer eingeladen wurde ist ein Fehler aufgetreten. Der Fehler wird jetzt abgefangen und dem Benutzer eine Meldung angezeigt.
7. Unterschiede in der Darstellung von Kursen und eCommunities machen (erledigt)
In den Eingabemasken (Formularen) soll zwischen Kurs und eCommunity unterschieden werden. Momentan werden Buttons mit z.B. der Beschriftung "Kurs/eCom archivieren" angezeigt, egal ob man sich in einer eCommunity befindet oder in einem Kurs. Es soll so abgeändert werden, dass in einer eCommunity die Beschriftung "eCom archivieren" lautet und in einem Kurs "Kurs archivieren". Die gilt für alle Buttons dieser Art.
Bearbeitungsdokumentation:
In der bisherigen Darstellung wurde sowohl in eCom's und in Kursen die gleichen zusammengesetzten Bezeichnungen verwendet (Kurs/eCom bzw. Dozent/Moderator). In der überarbeiteten Version wird festgestellt, ob es dich um einen Kurs oder eine eCom handelt und die richtigen Bezeichnungen in Variablen abgelegt, die an den entsprechenden Stellen in die Darstellung bzw. den Textfluss einsetzt.


8. Datenbank Tabellen analysieren und im Wiki kurz dessen Funktion erläutern (erledigt)
Kurz die Funktion bzw. den Zweck der Tabellen in der Datenbank erläutern. Ein Satz reicht.
9. Use-Case-Diagramm anapssen (erledigt)
Das Use-Case-Diagramm soll auf den Stand nach der Implementierung der neuen Features angepasst werden. Außerdem soll die Sicht des Moderators hinzugefügt werden.
10. Die (benutzten) Klassen des Moduls sollen kurz erklärt werden (erledigt)
Analog zu den Beschreibungen der Datenbanktabellen (8.) sollen die benutzten und wichtigen Klassen des Moduls kurz in einem Satz erklärt werden.

Refactoring

Refactoring (z. dt. Refaktorisierung) bezeichnet die Technik, bestehenden Code so umzustrukturieren, dass er nicht-funktionalen Anforderungen gerecht wird, ohne dass die Funktion in irgendeiner Weise verändert bzw. beeinträchtigt wird. Während der Entwicklung an dem Modul wurde ein Style Checker eingeführt, der den Code unmittelbar vor dem "Einchecken" in die Versionsverwaltung Subversion auf einen festgelegten Programmierstil überprüft und bei Nicht-Einhaltung das Einchecken mit einer Fehlermeldung verweigert. Die Fehlermeldung gibt darüber Auskunft, an welchen Stellen und inwieweit dieser festgelegte Programmierstil nicht eingehalten wurde.

Bei der Entwicklung sind wir mit vielen PHP-Dateien in Kontakt gekommen, von denen einige natürlich auch Klassen-Definitionen enthalten. Wir haben alle Dateien, bei denen wir auch nur eine Code-Änderung gemacht haben, komplett dem vorgegebenen Programmierstil angepasst, was einen sehr großen Teil der Bearbeitungszeit in Anspruch genommen hat. Ein Problem bestand auch darin, dass der Style Checker Probleme hatte mit gemischten DOS- und UNIX-Zeilenumbrüchen. Dies äußerte sich darin, dass Zeilenlängen von 900 Zeichen angezeigt wurden, obwohl im Code die genannten Zeilen weit unter 100 Zeichen hatten. Mit dem Linux-Kommandozeilenprogramm dos2unix konnte dieses Problem sehr gut behoben werden.

Im Folgenden ist ein Auszug aus einer Fehlermeldung, die beim Einchecken der Datei class.SettingsDialog.inc.php in Subversion aufgetreten ist:

Some of selected resources were not committed.
Eine Aktion im Projektarchiv schlug fehl
svn: Übertragen schlug fehl (Details folgen):
svn: Commit blocked by pre-commit hook (exit code 1) with output:

FILE: branches/msp_09/web/courses/classes/class.SettingsDialog.inc.php
--------------------------------------------------------------------------------
FOUND 60 ERROR(S) AND 9 WARNING(S) AFFECTING 68 LINE(S)
--------------------------------------------------------------------------------
 46 | ERROR   | Scope modifier not specified for member variable "$settings"
 54 | ERROR   | Method name "SettingsDialog::SettingsDialog" is not in camel
    |         | caps format
 54 | ERROR   | PHP4 style constructors are not allowed; use "__construct()"
    |         | instead
 54 | ERROR   | Method name "SettingsDialog::SettingsDialog" does not have a
    |         | scope modifier. Expected public, protected or private.
 82 | WARNING | Line exceeds 120 characters; contains 122 characters
 83 | ERROR   | Opening parenthesis of a multi-line function call must be the
    |         | last content on the line
 85 | ERROR   | Closing parenthesis of a multi-line function call must be on a
    |         | line by itself
...
 93 | ERROR   | Space after opening parenthesis of function call prohibited
 93 | ERROR   | Space before closing parenthesis of function call prohibited
...
338 | ERROR   | Method name "SettingsDialog::printShortNameRow" does not have
    |         | a scope modifier. Expected public, protected or private.
343 | ERROR   | Line exceeds maximum limit of 140 characters; contains 152
    |         | characters
345 | ERROR   | Line exceeds maximum limit of 140 characters; contains 171
    |         | characters
360 | ERROR   | Method name "SettingsDialog::printModulShortCutRow" does not
    |         | have a scope modifier. Expected public, protected or private.
365 | ERROR   | Line exceeds maximum limit of 140 characters; contains 160
    |         | characters
...
    |         | characters
444 | ERROR   | Method name "SettingsDialog::printCloseRow" does not have a
    |         | scope modifier. Expected public, protected or private.
457 | WARNING | Line exceeds 120 characters; contains 127 characters
476 | ERROR   | Method name "SettingsDialog::printChangeViewRow" does not have
    |         | a scope modifier. Expected public, protected or private.
...
718 | ERROR   | Method name "SettingsDialog::printAssist" does not have a
    |         | scope modifier. Expected public, protected or private.
718 | ERROR   | Method name "SettingsDialog::printTeachersDesc" does not have
    |         | a scope modifier. Expected public, protected or private.
718 | ERROR   | Method name "SettingsDialog::printSubscribeDesc" does not have
    |         | a scope modifier. Expected public, protected or private.
718 | ERROR   | Method name "SettingsDialog::printViewDesc" does not have a
    |         | scope modifier. Expected public, protected or private.
720 | ERROR   | A closing tag is not permitted at the end of a PHP file
--------------------------------------------------------------------------------

Zu implementierende Features (Teil 2)

Nach dem Walkthrough wurden neue zu implementierende Features und weitere Orte, an denen Refactoring betrieben werden soll, festgelegt. Es folgt eine Liste dieser:

1. Style - Anzahl der Benutzungen (erledigt)
Beim Abfragen der verfügbaren eStudy-Styles soll bestimmbar sein, ob auch die Anzahl der Benutzungen zurückgegebenen wird oder nicht (standardmäßig war/ist es so). Da dies aber in sehr vielen DB-Abfragen resultiert (Performance-Probleme!?) und nicht überall diese Information benötigt wird, soll dies durch den Aufrufer der Funktion bestimmbar sein. In der Datei class.style.inc.php wurde der Methode getStyleTemplates (Klasse Style) ein zusätzlicher optionaler Boolean-Parameter ($styleUsageCount) hinzugefügt, der als Default den Wert true hat. Die genannte Methode wurde um die benötigte Funktionalität erweitert.
2. Datenauszug (erledigt)
Im Datenauszug soll erscheinen, wer in welchem Kurs bzw. eCommunity Dozent bzw. Moderator ist.
3. Testfälle (Unit-Tests) (erledigt)
Es sollen Testfälle für alle geänderten/erstellten Klassen und Methoden erstellt werden.

Dokumentation der Änderungen

Kurse/eCommunities

News / Registrierung für Eingeladene Teilnehmer

Style

SQL

Datenauszug

Test-Klassen

Test-Suite für alle Module
Test-Suite für Kurs-Modul
Test-Cases für Kurs-Modul

ToDo

In diesem Abschnitt werden Features, Bugfixes und sonstige "Todos" gelistet, zu denen wir zeitlich nicht mehr in der Lage waren sie zu implementieren.

Test Cases erstellen
Es müssten/sollten für alle (nicht nur geänderte) Klassen in diesem Modul Test-Cases erstellt werden.