MSP:HÜ Planspiel

Aus THM-Wiki
Wechseln zu: Navigation, Suche


Allgemein

Diese Wiki-Seite dient zur Dokumentation der Hausübung "Planspiel" der Masterveranstaltung "Methoden des Softwareentwicklungsprozesses (MSP)" im Wintersemester 2009/10 an der Fachhochschule Gießen-Friedberg. Im Rahmen dieser Hausübung soll das Modul "Planspiel" refaktorisiert und durch die Implementierung eines neuen Features erweitert werden.

Funktionalität des Moduls

Ein Planspiel ist kein Vorgehensmodell und nicht auf Softwaretechnik beschränkt (siehe hier). Planspiele können allgemein für strategisches Planen eingesetzt werden. Die zentralen Komponenten eines Planspiels sind Phasen, welche Dokumente enthalten. Dokumente kann man als eine Art Container verstehen, welche neben dem eigentlichen Arbeitsdokument bestimmte "Verwaltungsdaten" besitzen (Titel, Bearbeiter, Reviewer, usw.). Das eigentliche Arbeitsdokument wird als Datei hochgeladen und im Dokumentencontainer hinterlegt.

Weiterführende Informationen zur Modulgruppe Planspiel erhalten Sie auf folgender Wiki-Seite(http://wiki.mni.fh-giessen-friedberg.de/index.php/Planspiel).

Bisherige Autoren

Die Modulgruppe Planspiel wurde von folgenden Autoren implementiert:

  • Christian Thomas Weber
  • Clemens Weiß
  • Daniel Legner
  • Dennis Sack
  • Eugen Hubert
  • Marcel Knapp
  • Timo Schmidt

Gruppenmitglieder

Das Team dieser Hausübung setzt sich aus folgenden Mitgliedern zusammen:

  • Stefan Bußweiler
  • Nils Ruppel

Aufgabenstellung

Die Hausübung behandelt die Bearbeitung von folgenden Punkten:

  • Reverse Engineering
    Reverse Engineering des Planspiel-Moduls. Klassendiagramm, DB-Schema, Use Cases und Code Dokumentationen.
  • Software Metriken
    Analyse durch Software Metriken des Planspiel-Moduls. Erstellung von C.R.A.P.-Index & Zyklomatische Komplexität, Code Coverage und Bad Smells .
  • Feature Implementierung & Refaktorisierung
    Für das Planspiel-Modul soll ein neues Feature implementiert werden. Im Zuge der Implementierung sollen die betroffenen Abschnitte im Hinblick auf nicht funktionale Anforderungen refaktorisiert werden. Die Refaktorisierung hat das Ziel die Qualität des vorhandenen Quellcodes zu steigern.

    Bei der Refaktorisierung sollen die unten aufgeführten nicht funktionale Anforderungen umgesetzt werden.

Nicht funktionale Anforderungen

Das Modul soll die folgenden nicht funktionalen Anforderungen erfüllen:

  • Wartbarkeit
  • Sicherheit
    • Datenschutz
    • Datensicherheit
  • Performance
  • Useability
  • Barrierefreiheit
  • Internationalisierung
  • Benutzerdokumentation
    • Wiki

Hinweise

Für die Nutzung des Planspiels in einem Kurs ist die Aktivierung der Module Planspiel, Dateien, Rollenspiel und Team notwendig. Erst durch das Freischalten des Moduls Rollenspiel, können die Benutzer des Planspiels die verschiedenen Rollen einnehmen. Weitere Hinweise zur Benutzung des Planspiel finden Sie auf dieser Wiki-Seite(http://wiki.mni.fh-giessen-friedberg.de/index.php/Planspiel) .

Reverse Engineering

Klassendiagramm

Das Klassendiagramm beschreibt die Klassen, die Bestandteil der Modulgruppe Planspiel sind. Neben den hier abgebildeten Klassen werden zusätzlich die Modulgruppen Roleplay und Teams innerhalb des Planspiels verwendet. Hilfklassen wie z.B. zur Datenbankverbindung wurden zur besseren Übersicht nicht im Diagramm berücksichtigt.

Klassendiagramm
  • Planspiel
    Erstellen eines Planspiel-Objektes mit den entsprechenden Funktionen.
  • PlanspielList
    Auflisten der Planspiele eines Kurses.
  • ProjectDetails
    Anzeige der Details eines Planspiel-Projekts.
  • PlanspielContainer
    Template Container für das Planspiel Modul.
  • Phase
    Erstellen eines Phasen-Objektes mit den entsprechenden Funktionen.
  • PhaseDetails
    Anzeige der Details einer Phase eines Planspiels.
  • Document
    Erstellen eines Document-Objektes mit den entsprechenden Funktionen.
  • BarChart
    Generiert ein BarCharting Diagramm.
  • PlanspielBudget
    Budget Abfrage.
  • BudgetIndicators
    Budget Anzeige.
  • ColorIndicator
    Setzt die Farben des BarCharting Diagramms.
  • TabMembers
    Auflisten der Statistiken aller Mitglieder eines Planspiels.

Datenbank Schema

Das ER-Diagramm beschreibt die Datenbank-Tabellen, die Bestandteil der Modulgruppe Planspiel sind.

  • ER-Diagramm


  • Eine kurze Beschreibung der Tabellen ist folgender Übersicht zu entnehmen:
Tabelle Verwendung
planspiel enthält "Stammdaten" eines Planspiels wie z.B. zugehöriger Kurs, Planspielleiter, Name, usw.
planspiel_document verwaltet die "Metadaten" + Datei eines Dokuments, z.B. Bearbeiter, Reviewer, Deadline Aufwand, usw.
planspiel_doc_type Dokumenten Typ
planspiel_phase_team Ordnet ein Team einer Planspielphase zu
planspiel_phase enthält die Daten der Planspiel Phasen
planspiel_creditpoints Verwaltet die Zuordnung von CreditPoints der User eines Planspiels

Use-Case-Diagramm

Das Use-Case-Diagramm beschreibt abstrakt die grundlegenden Anwendungsfälle des Planspiel-Moduls. Die verschiedenen Akteure spiegeln die Rollen wieder, die beim Erstellen eines Planspiels durch das Modul Rollenspiel erzeugt werden. Durch die Zuweisung und Übernahme der Rollen, erlangen die Akteure die aufgeführten Rechte und Funktionalitäten.



Code Dokumentation

Die Dokumentation wurde mit Doxygen erstellt und ist unter folgendem Link verfügbar: Dokumentation.


Software Metriken

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

Mit Hilfe von phpUnit erstellte Metriken sind hier zu finden.

Besonders umfangreiche Klassen:

Klasse LOC
Planspiel (class.planspiel.inc.php) 1081
Document(class.document.inc.php) 1927
Phase (class.phase.inc.php) 998

Auffällige Methoden:

Methode Cyclomatic Complexity CRAP Index
BarChart::draw() 38 1482
MemberDetails::show() 37 1406
ProjectDetails::ProjectDetails() 32 1056
Document::showEditForum() 93 8742
Document::setData() 72 5256

Code Coverage

Es existieren zur Zeit (Stand vor der Refaktorisierung) keine Testfälle, die Coverage beträgt daher 0. Zur automatisierten Erstellung von Metriken mit phpUnit wurden von uns lediglich Unit-Test-Skeletons erstellt die keinerlei Testfunktionalitäten enthalten.

Bad Smells

  • Large Class: mehrere große (LOC > 500), teilweise sehr große (LOC>1000) Klassen.
  • Long Method: mehrere sehr umfangreiche Methoden.
  • Duplicate Code: an mehreren Stellen im Code ist Ausgabecode zur Erzeugung von HTML-Tabellen zu finden.


  • Sonstige Auffälligkeiten:
    • Mix aus deutschen und englischen Bezeichnern
    • keine klare Trennung von Geschäftslogik und Darstellung: Die Ausgabetexte sind hart codiert und mit dem der Geschäftslogik stark vermischt. Zur Darstellung werden HTML-Tabellen genutzt. Zur Durchführung von Änderungen am Layout müssen weitreichende Eingriffe in den Code erfolgen. Der Änderungs- und Wartungsaufwand ist durch die Vermischung von Logik und Darstellung sehr hoch. Die Lesbarkeit wird durch die teilweise sehr umfangreichen Ausgabeblöcke stark eingeschränkt.
    • DB-Anfragen innerhalb von Schleifen: an einigen Stellen werden Datenbankabfragen innerhalb von Schleifen durchgeführt. Um die Performance zu erhöhen, sollte auf Datenbankabfragen wenn möglich in Schleifen verzichtet werden.
    • es existieren keine Unit-Tests: Zur Erhöhung der Testbarkeit sollten Unit-Tests implementiert werden.


Feature Implementierung & Refaktorisierung

Für das Planspiel-Modul soll ein neues Feature implementiert werden. Im Zuge der Implementierung sollen die betroffenen Abschnitte im Hinblick auf nicht funktionale Anforderungen refaktorisiert werden. Die Refaktorisierung hat das Ziel die Qualität des vorhandenen Quellcodes zu steigern. Bei der Refaktorisierung sollen die oben aufgeführten nicht funktionale Anforderungen umgesetzt werden.

Probleme im Vorfeld

Bevor wir mit der Implementierung des Features und der Refaktorisierung beginnen konnten, mussten wir uns in die allgemeinen Abläufe und Vorgehensweisen im Umgang mit dem Modul einarbeiten. Die erste Hürde stellte die Aktivierung des Planspielmoduls dar. Es war an keiner Stelle dokumentiert, das dieses Modul die Aktivierung verschiedener anderer Module (z.B. Teams, Rollenspiel) voraussetzt. Wir konnten daher die Anleitung zur Erstellung eines Planspiels (Planspiel) nicht nachvollziehen. Nach Rücksprache mit Herrn Quibeldey-Cirkel wurde dann klar, das zur Verwendung des Planspiels andere Module aktiviert werden müssen. Nach der Aktivierung des Planspiels haben wir verschiedene Testbenutzer und Planspiele angelegt um uns einen Eindruck über die Funktionsweise und Abläufe eines Planspiels zu verschaffen. Im Rückblick mussten wir viel Zeit für das eigentliche Verständnis des Moduls aufwenden.

Implementierung des neuen Features

Ziel der Hausübung ist die Überarbeitung der Dokumenten-Kompenente des Planspiels. Im aktuellen Entwicklungsstand (16.11 2009) ist es nur möglich Dateien als Arbeitsdokument zu verwenden. Eine Verlinkung von Dokumenten im WWW ist nicht möglich.

Bei der Arbeit mit dem Planspiel in einer Online-Plattform ist es unabdingbar auch Dokumente im Internet zu verlinken. Das neue Feature besteht darin Links/URLs als Arbeitsdokument anzugeben. Dadurch soll z.B. ermöglicht werden auf Wiki-Einträge oder Dateien im Trac zu verweisen und diese als Arbeitsdokument zu verwenden. Analog zur Verwaltung einer Datei als Arbeitsdokument sollen die Links auch nachhaltig bearbeitet werden können.

Zur Speicherung der Links wurde auf die bereits vorhandene Infrastruktur von eStudy zurückgegriffen. Das Dateien-Modul sieht die Speicherung von Dateien und Links vor. Dazu stellt das Modul in der Datenbank die Tabelle filelist und entsprechende Methoden in der Klasse Insert zur Verfügung. Aus diesem Grund wurde auf das Anlegen von neuen Tabellen verzichtet.


Beschreibung des umgesetzten Features

  • Linkeingabe
    Für die Eingabe eines Links wurde das Formular zur Dokumentenbearbeitung angepasst. Durch Radiobuttons kann der Benutzer den Typ der zu veröffentlichen Ressource auswählen. Für die Eingabe einer Datei und eines Links stehen entsprechende Formularfelder zur Verfügung. Durch die Auswahl eines Radiobuttons wird das entsprechende Feld für die Eingabe freigegeben.

    Folgende Grafik zeigt einen Ausschnitt des Formulars:


Abschnitt zur Angabe des Arbeitsdokuments


  • Linkbearbeitung
    Die Bearbeitung eines vorhandenen Links wurde analog der Bearbeitung für eine Datei implementiert. Der Link wird durch die Angabe eines neuen Links überschrieben. Ein Link ist häufig sehr kurz oder wird in der Regel kopiert. Eine Editierung eines vorhandenen Links durch ein eigenes Feld wäre zu überladen für ein solches triviales Vorgehen. Ein Link kann ebenfalls mit einer Datei überschrieben werden.

    Wurde für ein Dokument eine Ressource (Datei bzw. Link) hochgeladen, wird die entsprechende Ressource jetzt auch in der Dokumentenbearbeitungs-Ansicht verlinkt. Dadurch kann der Benutzer während der Dokumentenbearbeitung die aktuelle Ressource einsehen.

Abschnitt zur Angabe des Arbeitsdokuments


  • Linkvalidierung
    Beim Absenden des Formulars wird der Link validiert. Handelt es sich um keinen gültigen Link, wird eine entsprechende Fehlermeldung ausgegeben. Erst wenn der Link sich als gültig erweist, wird er in der Datenbank abgespeichert. Dadurch wird der Missbrauch und gezielte Angriffe auf die Datenbank unterbunden. Zur Linkvalidierung wurde die bereits vorhandene eStudy-Klasse "Utilities" verwendet.
Abschnitt zur Angabe des Arbeitsdokuments



  • Dokumentenübersicht
    Die Dokumentenübersicht wurde ebenfalls angepasst. Wurde für ein Dokument bereits eine Ressource hochgeladen wird diese über den Namen des Dokumentes verlinkt. Der Name gibt Auskunft über den Typ der abgelegten Ressource, Datei oder Link. Ein Link wird in einem neuen Fenster geöffnet.


Abschnitt zur Angabe des Arbeitsdokuments

Usability

Die Verwendung in der Dokumentenbearbeitungsansicht war nicht auf dem ersten Blick ersichtlich. Durch die Einführung eines neuens Abschnitts wurde die Bearbeitung eines Dokumentes klarer strukturiert. Das Einstellen einer Datei bzw. eines Links zu einem Dokument findet im Abschnitt Ressource bearbeiten statt. Ein weiterer Punkt der die Benutzerfreundlichkeit steigert ist die Hinzunahme von Verlinkungen zur Ressource in der Dokumentenbearbeitungsansicht und in der Gesamtübersicht der Dokumente. Treffende Namen und Kommentare unterstützen das Verständis des Benutzers.

Anpassungen nach dem Modul-Walkthrough

Bei dem Walk-Through zur Vorstellung des Implementierten Features haben sich einige Punkte zur Überarbeitung ergeben.

  • Zuzätzliche Auswahlmöglichkeit "keine Datei"
    Neben den beiden Möglichkeiten "Datei hochladen" und "Link angeben" zur Angabe eines Arbeitsdokumentes sollte außerdem eine weitere Möglichkeit "keine Angabe" implementiert werden. Diese Auswahlmöglichkeit kommt zum Einsatz, wenn ein Dokument mit den entsprechenden Rahmendaten, wie z.B. Bearbeiter, Reviewer, Deadline, Aufwand, usw., erstellt wird, aber noch kein konkretes Arbeitsdokument in Form einer Datei oder eines Links vorliegt.
  • Überarbeitung der Link-Validierung
    Zur Link Validierung wurde von uns eine PEAR-Erweiterung verwendet. Da eStudy aber an zentraler Stelle eine Funktionalität zur Linkvalidierung bereitstellt, sollte die Validierung mit Hilfe dieser zentralen Klasse erfolgen.
  • Bugfixes
    Beim Walk-Through merkten wir an, dass eine mehrfache Speicherung eines Links nicht möglich sei. Dabei handelte es sich um einen Bug im Dateien-Modul. Herr Quibeldey-Cirkel bat uns den Fehler zu beheben. Für weitere Informationen siehe nächstes Kapitel Abschnitt Keine Speicherung von gleichnamigen URLs.

Bugfixes

Das Modul Planspiel weist eine hohe Komplexität und große Abhängigkeit von anderen Modulen vor. Da während der Durchführung der Hausübung auch die anderen Module refaktorisiert wurden, kam es innerhalb des Planspiels immer wieder zu schwer nachvollziehbaren Fehlern. Die Implementierung des Planspiels musste ständig an die Änderungen in anderen Modulen angepasst werden. Wir mussten viel Zeit für die Fehlersuche und Koordination mit anderen Teams aufbringen.

Hier ein kurzer Auszug:

Keine Speicherung von gleichnamigen URLs

Beim Testen des neuen Features fiel auf, dass mehrere gleichnamige Links nicht abgespeichert werden konnten. Bei der Speicherung von Links im Dateien-Modul besteht die Möglichkeit die URL mit einem zugehörigen Namen anzugeben. Laut der Dokumentation im Quellcode können in einem Verzeichnis gleichnamige URLs gespeichert werden. Mehrere gleichnamige Namen zu den Links dürfen nicht möglich sein. Die Implementierung war jedoch verdreht. Eine Speicherung von mehreren gleichnamigen URLs in einem Verzeichnis war nicht möglich.

Da die Speicherung von Ressourcen unter derselben URL ein sehr häufiger Anwendungsfall im Planspiel ist, wurde der Fehler im Dateien-Modul behoben.

Team Zuweisungen nicht möglich

Bei der Verwendung des Planspiels ist es durch die Hinzunahme des Moduls Team möglich, einzelne Benutzer des Spiels in einem Team zu gruppieren. Bei der Zuweisung von Phasenverantwortlichen und Dokumentenbearbeiter/-reviewer müssen die Benutzer aus den einzelnen Teams ausgewählt werden. Dies war nach der Refaktorisierung des Team Moduls nicht mehr möglich, da es Probleme mit der Sichtbarkeit von Attributen gab und entsprechende Getter-Methoden fehlten.

Nach der Feststellung des Problems wurde der Fehler analysiert und im Team Modul behoben.

Anlegen von Verzeichnissen nicht möglich

Beim Erzeugen eines Planspiel wird im Dateien-Modul ein gleichnamiges Verzeichnis angelegt. Dieses kann später die einzelnen Dateien bzw. Links des Spiels enthalten. Die Erzeugung eines Verzeichnisses im Dateien-Modul war im Laufe der Implementierung nicht mehr möglich. Durch ein Treffen mit einem Verantwortlichen des Dateien-Teams wurde das Problem gemeinsam analysiert.

Refaktorisierung

Die Implementierung des Features erfolgt in der Datei planspiel/classes/class.document.inc.php. Die Refaktorisierung bezieht sich daher grundsätzlich auf diese Datei.

HTML-Code

In der Document Klasse wird an vielen Stellen HTML-Code zur Ausgabe erzeugt. Der Umgang mit Umlauten innerhalb des HTML-Codes war vor der Refaktorisierung nicht einheitlich gestaltet. An einigen Stellen wurden Umlaute direkt im Quelltext eingegeben, an anderen Stellen mit HTML-Entities codiert. Der Quellcode wurde so überarbeitet, dass alle Umlaute der HTML-Ausgabe durch HTML-Entities erfolgt.

Kommentare

Sämtliche Attribute und Methoden der Klasse Document wurden mit Kommentaren versehen. Dadurch wird eine lückenlose API-Dokumentation der Klasse sichergestellt.

Zugriffsmodifikatoren

Sämtliche Attribute und Methoden der Klasse Document wurden mit Zugriffsmodifikatoren versehen.

UnitTests

Vor der Durchführung der Hausübung lagen keine Testfälle für die Modulgruppe Planspiel vor. Für das von uns implementierte Feature wurden Testfälle erstellt. Die Erstellung von Testfällen für die komplette Modulgruppe konnte im Rahmen dieser Hausübung nicht realisiert werden.

Precommit Hooks

Der erste Commit-Vorgang der Dokument Klasse im MSP-Branch wurde aufgrund der Nicht-Einhaltung von Formatierungs- und Namenskonventionen verweigert. Zur Einhaltung der Programmierrichtlinien wurden die meisten der Codesniffer Fehler und Warnungen beseitigt und auf eine geringe Anzahl reduziert. Die häufigsten Fehlerursachen waren:

  • Namensgebung von Methoden und Attributen: es wurde nicht die CamelCase-Schreibweise verwendet
  • Vorgegebene Zeilenlänge überschritten
  • Keine Verwendung von Sichtbarkeitsattributen


Liste der überarbeiteten Dateien

planspiel/tests

planspiel/tests/datasets

planspiel/classes

ressourcen/classes