Reengineering eines Web-Content Management Systems

Im Rahmen meiner Bachelorarbeit möchte ich ein CMS von Grund auf erneuern. Es handelt sich dabei um ein Content Management System auf PHP-MySQL-Basis, das von mir 2005 entwickelt wurde.

Ausgangslage

Das System widmet sich den speziellen Anforderungen, die mit der Pflege einer Theater-Webseite einhergehen. Derzeit ist es bei 10 Theatern und Konzertveranstaltern im Einsatz.

Die Theater erhalten einen genau auf ihre Bedürfnisse zugeschnittenen Funktionsumfang, der u.U. auch individuelle Veränderungen am Code bedeutet. Auch nach erfolgter Einführung des CMS werden die Theater weiterhin von mir betreut. Es werden ständig neue Wünsche an mich herangetragen, so dass das jeweilige System um neue Features erweitert werden muss und die einzelnen Instanzen der Software stark voneinander abweichen.

Die mit der Webseitenpflege betrauten Theater-Mitarbeiter oder Praktikanten haben meist wenig Erfahrung im Umgang mit CM-Systemen. Gewünscht wird daher ein Administrationsbereich, der leicht zu verwenden ist und genau das abbildet, was für die gewünschte Funktionalität der jeweiligen Theaterwebseite notwendig ist.

Neben dem CMS für Theater nutze ich eine leichtgewichtige Variante des Systems für die Webseiten von Künstlern und kleineren Firmen, die in ihren Grundzügen vor langer Zeit aus dem Theater-CMS hervorgegangen ist. Es handelt sich im Wesentlichen nur um die grundlegenden CMS-Funktionalitäten wie Seiten-, Bild- und Navigationsverwaltung. Die theaterspezifischen Bereiche wie Spielpläne, Besetzungen, Abonnements etc. wurden herausgenommen.

Ist-Zustand

Das bestehende CMS ist über die Jahre stetig gewachsen und hat an Komplexität gewonnen. Es ist all die Jahre nie einer grundlegenden Überarbeitung oder Umstrukturierung unterzogen worden und stößt nun an seine Grenzen hinsichtlich der Erweiterbarkeit und Wartbarkeit. Im Laufe der Entwicklung wurde kaum Wert auf eine sinnvolle Architektur, eine konsistente Struktur oder sauberen und lesbaren Code gelegt.

Das Ergebnis ist ein schlecht strukturierter Code mit unzureichender Kapselung, extrem langen Methodendefinitionen und vielfach redundantem, nicht dokumentiertem Code. Dies wirkt sich negativ auf die Aufwände für Erweiterungen und Anpassungen, Defektsuche und die Einarbeitung von Mitarbeitern, die mein Unternehmen nach meinem Bachelor-Abschluss unterstützen sollen, aus.

Die beiden Systeme haben sich im Laufe der Zeit stark auseinanderentwickelt, so dass der Austausch von Funktionen zwischen den Projekten immer mit hohem Aufwand verbunden ist.

Die Theatermitarbeiter, die das System derzeit nutzen, sind weitestgehend zufrieden mit der Gebrauchstauglichkeit des Systems, so dass kein dringender Handlungsbedarf besteht. Dennoch sind einige Stellen bekannt, an denen die Usability weiter verbessert werden kann (z.B. im Bereich der Medienverwaltung oder Vorschau-Funktionalität).

Ziel-Setzung

Die beiden inzwischen stark verselbständigten Systeme sollen in einem Hauptentwicklungsstrang zusammengefasst werden und die verschiedenen Kundenprojekte wieder auf einer einheitlichen Code-Basis fußen. Ziel dabei ist es, große wie kleine Kunden mit demselben System bedienen zu können, um den Wartungsaufwand zu minimieren und beliebig aus einem Gesamt-Pool von Funktionen wählen zu können.

Für die individuellen Wünsche der einzelnen Kunden soll ein Konfigurationskonzept entwickelt werden, das eine individuelle Anpassbarkeit der Software ermöglicht.

Zudem sollen weite Bereiche des Codes durch Unittests abgedeckt werden. Integrationstests sollen sicherstellen, dass das Aktivieren oder Deaktivieren von Funktionalitäten keine unvorhergesehenen Probleme verursacht.

Umsetzung

Zur Zielerreichung sind drei verschiedene Wege gegeneinander abzuwägen: Ein Refactoring im Sinne einer strukturellen Verbesserung bei Funktionserhalt scheidet aus, da sich die beiden Systemvarianten bereits zu stark auseinanderentwickelt haben und derzeit auch eine Testautomatisierung fehlt.

Die zweite Möglichkeit wäre die Anpassung eines bestehenden CM-Systems wie z.B. Joomla oder Typo3. Mir erscheint jedoch der Aufwand, um die speziellen Features in solch etablierte Systeme zu integrieren, sowie der Einarbeitungsaufwand in diese Systeme, zu hoch im Vergleich zu der dritten Möglichkeit: dem Reengineering, also dem Neuaufbau des Systems.

Ich habe mich daher für die letzte Variante entschieden. Diesmal soll jedoch ein PHP-Framework zum Einsatz kommen. Meine Wahl fiel dabei auf Yii, da es sich dabei um ein objektorientiertes PHP-Framework handelt, in das ich mich schon ein wenig eingearbeitet habe. Es bringt von Hause aus eine MVC-Architektur und ORM-Techniken mit und erzielt im Vergleich zu anderen vergleichbaren Frameworks gute Ergebnisse hinsichtlich der Performance.

Bachelor-Arbeit

Das Reengineering des gesamten Systems mit all seinen derzeit existierenden Funktionen erscheint mir, im Rahmen meiner Bachelorarbeit ein zu hoch gestecktes Ziel zu sein. Daher möchte ich iterativ vorgehen und den Arbeitsumfang zunächst auf die leichtgewichtigere Variante des Systems, deren Funktionalität auch für das Gesamtsystem unverzichtbar ist, begrenzen und die Grundlagen für die Erweiterung auf den Theaterkomplex schaffen.

Gliederung

1. Einleitung
   1. Kontext
   2. Motivation
   3. Zielsetzung
   4. Abwägung von grundlegenden Lösungsstrategien
   5. Vorgehen
   6. Aufbau dieser Arbeit
   7. Begrifflichkeiten
2. Grundlagen
   1. SOLID-Prinzipien
      1. S – Single-Responsibility-Prinzip
      2. O – Open-Closed-Prinzip
      3. L – Liskovsches Substitutionsprinzip
      4. I – Interface-Segregation-Prinzip
      5. D – Dependency-Inversion-Prinzip
   2. Objektorientierung
   3. Design-Patterns / Anti-Patterns
      1. MVC-Architekturmuster
      2. Active-Record-Pattern
      3. Decorator-Pattern
      4. Gott-Objekt
   4. Reengineering / Refactoring
   5. Analytische Qualitätssicherung
3. Analyse: Schwächen des Alt-Systems
   1. Schlechte Wiederverwendung und Redundanz
   2. Nicht zufriedenstellende Modularisierung und Kapselung
   3. Überlange Funktionen
   4. Undurchsichtige Konfigurationsmöglichkeiten
   5. Unzureichende Dokumentation
   6. Keine Testabdeckung
   7. Schlechte Usability der Navigation
   8. Unzureichende Medienverwaltung
   9. Schlechte Usability in der Benutzer- und Rechteverwaltung
   10. Unzureichende Unterstützung einer Freigabe- und Vorschaufunktionalität
4. Anforderungen für das Reengineering
   1. Umstellung auf Objektorientierung
   2. Einführung von zentralen Konfigurationsmechanismen
   3. Einführung einer Plugin-Architektur
   4. Entwickler-Dokumentation
   5. Einführung von Unittests und Funktionstests
   6. Übergreifende Navigationsverwaltung
   7. Einführung einer zentralen Medienverwaltung
   8. Verbesserung der Rechteverwaltung
5. Implementierung / Lösungsansätze
   1. Entscheidung für Yii als MVC-PHP-Framework
   2. Mehrsprachigkeit
   3. Projektweite Formular-Feld-Konfiguration
      1. Der generische Ansatz
      2. Der generische, übergreifende Ansatz
      3. Der relationale Ansatz
      4. Abwägung
   4. Plugin-Verwaltung
   5. Themes
   6. Interne Entwickler-Dokumentation
   7. Versionsverwaltung
   8. Automatisierte Tests
   9. Navigationsverwaltung
   10. Zentrale Bildverwaltung
       1. Filemanager
       2. Bildauswahl & Galerie-Zusammenstellung
       3. Bildausschnitte
       4. Bildbeschriftungen und IPTC
   11. Rollenbasierte Rechteverwaltung
6. Fazit und Ausblick

Meilensteine

Nr.	Aufgaben
1	Seitenverwaltung mit über die Datenbank konfigurierbaren Feldern und Mehrsprachigkeit steht. Zusammenstellung der Eingabemasken sind durch Tests abgedeckt.
2	Navigationsverwaltung über das Backend inkl. Tests ist abgeschlossen.
3	Grundlegende Medienverwaltung inkl. Tests ist abgeschlossen.
4	Verwaltung der Zugriffsberechtigungen der einzelnen Funktionalitäten inkl. Tests abgeschlossen.
5	Ein kleineres Plugin ist realisiert.

Comments