MSP:HÜ Nachrichten

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Dokumentation
Arbeitstitel MSP:HÜ Nachrichten
Kurs Methoden des Software-Entwicklungsprozesses
Semester WS 09/10
Teilnehmer Nils Asmussen, Fabian Becker
Programmiersprache PHP

Diese Wiki-Seite dient zur Dokumentation der Hausübung "Nachrichten", die im Rahmen des Moduls "Methoden des Softwareentwicklungsprozesses (MSP)" an der Fachhochschule Gießen-Friedberg im Wintersemester 09/10 bearbeitet wird. Verantwortlich für die Hausübung sind Nils Asmussen und Fabian Becker.

Einleitung

Das Nachrichten-Modul ermöglicht es den Mitgliedern des eStudy sich untereinander Nachrichten zu schicken. Zusätzlich ermöglicht das Modul die Suche nach Mitgliedern, wobei zwischen Kursmitgliedern und Mitgliedern des eStudy unterschieden werden kann.


Aufgabenstellung

Folgendes war zu bearbeiten:

Reverse-Engineering:

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

Software-Metriken

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

Neue Features

  • Versand von PNs/Emails an Gruppen, Teams, Rollen und Fachbereiche. Dabei ist Mehrfachauswahl stets möglich. Buddies sollen als Gruppe behandelt werden.
  • Berücksichtigung der Rechte: Die zur Verfügung stehenden Auswahlelemente (Gruppen, Teams, ...) richten sich nach der Benutzergruppe
  • Beim Versand von Nachrichten soll oben in der AJAX-Suche auch die Suche nach dem Vornamen möglich sein.
  • Zusätzlich zum "TO" soll es möglich sein Nachrichten als CC und BCC abzuschicken.

Analyse

  • W3C Validität
  • Performance

Autoren des Moduls

Das komplette Modul wurde von folgenden drei Personen entwickelt:

  • Alexander Rausch [Refactoring WS 08/09]
  • Waldemar Krampetz
  • Dennis Bayer

Umsetzung

Reverse-Engineering

Im folgenden soll beschrieben werden, was beim Betrachten des Quellcodes des Nachrichten-Moduls auffällt:

  • Der Code ist ausnahmslos auf PHP5 ausgelegt. Dies lässt sich aufgrund des Vorkommens der Keywords 'private' und 'public' feststellen (PHP4 kannte diese Keywords nicht)
  • Eine Trennung zwischen Präsentationsschicht und Anwendungslogik findet nicht bzw. kaum statt (HTML wird wahllos mit PHP vermischt)

Use-Case-Diagramm

Im folgenden Diagramm sind die Use-Cases des Moduls dargestellt. Die hierarchische Darstellung soll verdeutlichen, an welcher Stelle die Aktionen zur Verfügung stehen.

Msp-hue-nachrichten-use-cases.png

Klassendiagramm

Klassen-Diagramm des Nachrichten-Moduls

DB-Schema

Wie an diesem Diagramm zu sehen, besteht das Nachrichten Modul aus drei Tabellen (+ die User-Tabelle, welche als Referenztabelle dient).

Das komplette ER-Modell (link) des eStudy, in diesem Fall ohne Referenzbeziehungen, da diese sich aufgrund der Benutzung von MyISAM nicht Reverse-Engineren lassen.

ER-Modell des Nachrichten-Moduls

Code-Dokumentation

Die Dokumentation wurde mit doxygen erstellt und kann hier heruntergeladen werden.

Software-Metriken

Um die wenigen vorhandenen Unit-Tests überhaupt ausführen zu können, mussten kleine Anpassungen an der Testsuite vorgenommen werden. Dennoch waren nicht alle Tests erfolgreich, so dass hier noch weitere Arbeit investiert werden muss. Die mit PHPUnit generierten Metriken können hier ([1]) gefunden werden. Diesen kann die Code-Coverage, die zyklomatische Komplexität und der C.R.A.P.-Index entnommen werden.

Performance-Analyse

Um die Performance des Moduls zu testen haben wir uns mittels Xdebug mehrere Output-Files erzeugen lassen um diese im Anschluss mit KCacheGrind analysieren zu können. Um festzustellen, ob einzelne Teile des Moduls optimiert werden können ist das beschriebene Verfahren jeweils für alle beschriebenen Use-Cases ausgeführt worden.

Performanceanalyse mit KCacheGrind

Neue Features

Versand an Gruppen, Teams, Rollen und Fachbereiche

Benutzersicht

Um das Senden von PNs/Emails zur vereinfachen, sollte die Möglichkeit bestehen an die Mitglieder eine ganzen Benutzergruppe, eines Teams, einer Rolle oder eines Fachbereichs zu senden. In Anbetracht dessen, dass ebenfalls gewünscht wurde CC und BCC verwenden zu können, haben wir uns dazu entschieden eine spezielle Syntax zu verwenden um an die genannten Elemente eine Nachricht schicken zu können. D.h. diese werden ebenfalls textuell als Empfänger dargestellt. Desweiteren befindet sich eine Box mit Checkboxen für Gruppen, Teams, Rollen usw. unter dem Sendeformular. Dort können die gewünschten Empfänger ausgewählt werden und anschließend mit Hilfe der Buttons "An", "CC" oder "BCC" via Javascript in die entsprechende Textbox eingefügt werden.

Dies bietet den Vorteil, dass wir die Box mit den Checkboxen nur einmal benötigen. Außerdem kann so auf der Text in einer Empfängerzeile auch kopiert und gespeichert werden und später einfach wieder eingefügt werden, falls an diese Empfänger häufiger gesendet werden soll.

Wir haben uns für folgende Syntax entschieden:

[Groups:GruppenName=Id1,Gruppenname2=Id2]

Die Angabe von Rollen und Teams erfolgt analog. Fachbereiche haben lediglich einen Namen:

[Departments:MNI,ABC]

Einzelne Benutzer werden wie bisher angegeben, d.h. über "Nachname, Vorname [, User-ID | User-Kennung ]". Die einzelnen Elemente werden mit ";" getrennt, ebenfalls wie bisher. Die Syntax muss natürlich niemand kennen, da - wie gesagt - dies üblicherweise durch Javascript generiert wird. Jedoch ist es möglich die Empfänger ohne Probleme abzulesen (dies ist der einzige Sinn des Namens; dieser wird ignoriert).

Screenshot des implementierten Features

Implementierung

Um die Empfängerzeile zu parsen, die enthaltenen Elemente zur Verfügung zu stellen und diese wieder in einen String verwandeln zu können, haben wir die Klasse Receiver geschrieben. Diese nimmt im Konstruktor die Empfängerzeile, parsed sie und bietet get-Methoden für die Elemente (Gruppen, Teams, ...) an. Mit der Methode __toString() können diese Elemente wieder in einen String umgewandelt werden.

Desweiteren haben wir für die Überprüfung der Benutzerrechte, Zusammenstellung der Benutzer aus der Datenbank und schließlich das Versenden der PNs/Emails die Klasse MessageSender entwickelt. Diese nimmt die Rechte und Zugehörigkeiten (Team, Rolle, Benutzergruppe, User-Id, ...) sowie die drei Empfängerlisten für "An", "CC" und "BCC" als Parameter im Konstruktur. Sie bietet die Methode send() um eine Nachricht zu versenden. Dabei werden zunächst die Rechte überprüft, anschließend die Benutzer ermittelt und am Ende die Nachrichten verschickt. Falls der Benutzer keine ausreichenden Rechte besitzt, gibt die Methode einen entsprechenden Fehlercode zurück.

Berücksichtigung der Rechte

Um nicht jedem Benutzer zu gestatten an ganze Gruppen, Fachbereiche usw. PNs/Emails zu versenden, sollten die Möglichkeiten abhängig von der Benutzergruppe eingeschränkt werden. Wir haben uns für folgende Rechte entschieden:

Recht Admin Moderator Student Dozent Sekretariat Alumnus Schüler Gast
Gruppen Ja Nein Nein Nein Nein Nein Nein Nein
Buddies Ja Ja Ja Ja Ja Ja Ja Ja
Eigenes Team im Kurs Ja Ja Ja Ja Ja Ja Ja Ja
Andere Teams im Kurs Ja Ja Nein Ja Nein Nein Nein Nein
Eigene Rolle im Kurs Ja Ja Ja Ja Ja Ja Ja Ja
Andere Rollen im Kurs Ja Ja Nein Ja Nein Nein Nein Nein
Fachbereiche Ja Nein Nein Ja Ja Nein Nein Nein
Unbeschränkte User-Anzahl Ja Ja Nein Ja Ja Nein Nein Nein

Das Sende-Formular zeigt jeweils nur die laut den Rechten verfügbaren Elemente an. Auch vor der Absendung der Emails wird nochmal überprüft ob die Rechte eingehalten wurden. Die erwähnte Beschränkung der Empfängerzahl kann in den Einstellungen unter E-Mails -> "max. direkte Empfänger" angepasst werden.

AJAX-Suche auch nach dem Vornamen

Zuvor war es nicht möglich nur nach einem Vornamen zu suchen. Benutzer mussten stets in der Form "Nachname, Vorname [, User-ID | User-Kennung]" angegeben werden. Gab man im Empfänger-Eingabefeld lediglich den Vornamen ein, wurde dieser als Nachname betrachtet und daher danach gesucht. Da es häufiger der Fall sein dürfte, dass lediglich der Vorname bekannt ist, haben wir dies geändert. Dafür musste lediglich das SQL-Statement angepasst werden, so dass ohne Angabe eines Kommas sowohl im Feld "Nachname" als auch im Feld "Vorname" gesucht wird.

Hinzufügen von CC und BCC

Bis jetzt war es nur möglich direkte Empfänger anzugeben. Gewünscht wurde, dass auch CC und BCC zur Verfügung steht. Wir haben diese daher als "Empfängerfelder", analog zu dem bisher vorhandenem, ergänzt. Emails werden aus Datenschutzgründen grundsätzlich einzelnd verschickt, d.h. CC und BCC haben die gleiche Bedeutung wie "An". Somit werden keine Email-Adressen bekannt gemacht. Bei dem Versand von PNs wird CC und BCC jedoch der Bedeutung entsprechend berücksichtigt. D.h. die als CC angegebenen Empfänger sind auch bei der PN-Detail-Ansicht als CC ersichtlich, wohingegen BCC nicht sichtbar ist. Auch der Datenauszug des Moduls wurde geändert, so dass die CC-Empfänger sichtbar sind.

Analyse

W3C Validität

Die von dem Modul Nachrichten betroffenen Seiten wurden auf W3C Validität überprüft, d.h. der Nachrichten-Überblick, das Verfassen einer neuen Nachricht, der Eingang, der Ausgang und die Buddyliste. Bis auf das Verfassen einer Nachricht sind alle genannten Seiten W3C Valide. Bei dem Verfassen wird das Attribut "autocomplete" bei dem Eingabefeld "To" verwendet um den Browser daran zu hindern Vorschläge für den Wert anzuzeigen. Dies ist an dieser Stelle durchaus sinnvoll, da dort eine AJAX-Suche angeboten wird und sich diese ohne das Attribut mit den Vorschlägen überlappen würde.

Uns ist jedoch aufgefallen, dass teilweise HTML-Elemente nicht für den Inhalt, sondern die Präsentation verwendet werden bzw. Elemente für andere Zwecke missbraucht werden (siehe Semantic-HTML). Beispielsweise wird das Table-Element benutzt um ein Formular (mit einer Spalte) inkl. Rahmen und Innenabstand zu erzeugen.

Performance

Im Zuge der Performance-Analyse haben wir für den Nachrichtenein- und -ausgang jeweils mit etwa 1000 Nachrichten via XDebug Profiling-Informationen sammeln lassen und diese mit KCacheGrind analysiert. Auffällig ist, dass die Methode Zend_Date::get() einen großen Teil der Zeit beansprucht. Desweiteren haben wir gesehen, dass die Methode RoleArtefacts::getRoleForItem() für jede Nachricht eine Datenbankabfrage und - sofern der Benutzer eine Rolle hat - die Methode Role::getPropertiesLink() eine weitere durchführt. Neben den genannten Auffälligkeiten, die evtl. überarbeitet werden sollten, könnte unserer Meinung nach das Problem sehr verkleinert werden, indem die Anzeige der Nachrichten auf mehrere Seiten aufgeteilt wird, so dass auf jeder Seite nur eine bestimmte Anzahl Nachrichten dargestellt werden muss.

Quelltextänderungen

Innerhalb des Moduls

/classes

/js

/tests

/tests/messaging

/

Außerhalb des Moduls

/web/admin