Rapid Prototyping von CRUD Anwendungen

Abgeschlossene Projekte

Projektteam: Benjamin Möllerke, Thomas Fox

In diesem Projekt wurde untersucht, ob Rapid Prototyping von Java Web Anwendungen in der Praxis einen sinnvolle Alternative zu herkömmlichen Vorgehensweisen ist. Das Rapid Prototyping wurde so implementiert, dass der Quellcode der Anwendung zuerst durch einen Code-Generator generiert wurde (die Entwicklung des Code-Generators war nicht Teil des Projektes), um anschließend den Code der Anwendung manuell zu modifizieren. Dieser Ansatz wurde gewählt, da oft ein Großteil des Codes Standard-Funktionalität bereitstellt, die sich gut durch Code Generierung abdecken lässt, aber dennoch kleinere Änderungen an der generierten Funktionalität nötig sind, um die funktionalen Anforderungen an die Software zu erfüllen. Diese zusätzlichen Änderungen lassen sich oft nur schwer durch Generator-Anpassungen abdecken, aber sehr leicht dadurch, dass der generierte Code modifiziert wird.

Jedoch ist aufgrund von geänderten Anforderungen auch der generierte Code im Projektverlauf oft noch Änderungen unterworfen. Das erzeugt die Herausforderung, die Änderungen am generierten Code und manuelle Code Änderungen zusammenzuführen. Hierfür sind mehrere Ansätze bekannt, z.B. Protected Regions, Vererbung, Delegation oder Mixins. Für Web Applikationen sind diese Ansätze aber nur teilweise geeignet, da außer Java Code unter anderem auch XML- und HTML- Dateien generiert (und ggf. modifiziert) werden sollen (was die Ansätze Vererbung, Delegation und Mixins ausschließt) und die Stellen, an denen Änderungen nötig sind, nicht immer beim Generieren bekannt sind (was den Protected Regions Ansatz ausschließt). Deswegen wurde der Ansatz gewählt, generierten und manuell geänderten Code automatisch zusammenzuführen [2].

Ziel des Projektes war es, zu untersuchen, ob dieser Ansatz auch für "real Life" Anwendungen funktioniert. Hierfür wurde eine Test-Anwendung erstellt, mit der ein Veranstaltungskalender verwaltet werden kann. Die Anwendung bietet hauptsächlich CRUD (Create Read Update Delete) Operationen auf einer Datenbank an, i. e Veranstaltungen können angelegt, gelesen, geändert und gelöscht werden. Eine Anwendung mit reiner CRUD Funktionalität lässt sich gut durch Code-Generierung erstellen.

Ausgangspunkt der Untersuchung war demnach eine vollständig generierte Web-Anwendung, die die Grundanforderungen erfüllte. Es wurden daraufhin weitere Anforderungen an die Software definiert, die der generierte Stand der Anwendung nicht erfüllte (z.B. Änderungen am Layout, Datenmodell, Internationalisierung der ursprünglich einsprachigen Anwendung). Diese Anforderungen wurden manuell und/oder im Generator implementiert und dann wurde untersucht, wie schwierig das Zusammenführen der Änderungen ist. Schwierigkeiten treten immer dann auf, wenn dieselbe Codestelle sowohl manuell als auch im Generator geändert werden.

Ergebnis des Projektes war, dass das Zusammenführen im Normalfall gut möglich ist, d.h. der Merging-Ansatz funktioniert in der Praxis. Es wurden dennoch einige Schwierigkeiten identifiziert:

- Features, die eine große Anzahl an verteilten Änderungen bedingen (wie z.B. Internationalisierung der Anwendung) sind nachträglich nur noch mit größerem Aufwand möglich.
- Strukturelle Änderungen am Code (Verschieben von Codeblöcken, Änderung der Codeformatierung) wurden vom verwendeten Merge-Algorithmus nicht als solches erkannt, sondern als Löschen und Neuneinfügen. Deswegen sind großflächige strukturelle Änderungen problematisch, aber insbesondere bei Layout-Änderungen in HTML-Dokumenten oft nur schwierig zu vermeiden, wenn z.B. die Anordnung von Elementen auf einer HTML-Seite geändert werden soll.

Trotz dieser Schwierigkeiten hat das Projekt gezeigt, dass der Merging-Ansatz auch in der Praxis geeignet ist, um einerseits die Basis-Features einer Anwendung durch Code Generierung zu erzeugen und andererseits manuelle Anpassungen in die Anwendung einzubauen.

[1] Rapid Prototyping von CRUD Anwendungen, Bachelorarbeit von Benjamin Möllerke an der HTWG Konstanz, 31.01.2013
[2] Für einen Vergleich der verschiedenen Ansätze siehe diesen Blog-Artikel