2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...

auftreten können, weil der Programmierer die Intentionen des Modellierers nicht vollständig
erfasst, bleiben möglicherweise unentdeckt, wenn der System-'Designer' selbst die
Realisierung seiner Modelle durchführt.
Zweitens muss klar sein, dass im Rahmen dieser Arbeit nur die Umsetzbarkeit bzgl. eines
bestimmten Web-Frameworks (Ruby on Rails in unserem Fall) bewertet werden konnte.
Darüber, wie gut UWE mit anderen Implementierungstechnologien zusammenspielt, müssen
andere Fallstudien Aufschluss geben.
Drittens wird keine Evaluierung der Umsetzbarkeit der RIA-Modellierung erfolgen, aus dem
einfachen Grund, weil sie schon in Kapitel 5.1 vorweggenommen wurde. Diese Kritik betraf
die Umsetzbarkeit der RIA-Modelle, die mit den 'alten' Modellierungstechniken für RIAs
erstellt wurden. Die Verbesserungsvorschläge, die wir daraufhin unterbreitet haben, können
als direktes Resultat der Evaluation des ursprünglichen Ansatzes betrachtet werden. Wir sind
natürlich der Meinung, dass mit dem erweiterten Ansatz, den wir vorgeschlagen haben, die
Probleme, die wir bei der ursprünglichen Version ausgemacht haben, beseitigt sind. Doch für
eine Validierung dieser These sind neue Praxistests notwendig, die PVS-Fallstudie konnte nur
zur Bewertung des alten Ansatzes dienen.
Nach dieser zugegebenermaßen langen Vorrede nun zur Bewertung:
Das UWE-Inhalts- und Präsentationsmodell wurden in ihren plattformspezifischen
Entsprechungen der Rails-Architektur, dem Modell- und der View-Komponente, umgesetzt.
Bei der Implementierung des Inhaltsmodells gab es zwar, wie schon ausführlich dargelegt,
Komplikationen bei der Abbildung der Publikations-Vererbungshierarchie auf
Datenbankebene, die uns zu nicht unwesentlichen Modifikationen des Modells zwangen. Aber
diese Schwierigkeiten können kaum UWE als dem verwendeten Modellierungsansatz
angelastet werden. Verantwortlich war vielmehr die in Rails integrierte Persistenzschicht: Für
unseren Geschmack bewirkt das ActiveRecord-Modul von Rails einfach eine zu starke
Koppelung von Objekt- und Persistenzebene.
Die Realisierung des Präsentationsmodells können wir als reibungslos beschreiben. Die
Weboberfläche des PVS konnte ohne Probleme so realisiert werden, dass alle Modellvorgaben
bzgl. der Struktur der Webseiten und ihrer dynamischen Inhalte eingehalten wurden.
Allerdings war hier auch am meisten 'eigenständige' Arbeit zu leisten, die über die Umsetzung
der im Modell spezifizierten Informationen hinausging, da in der UWE-Methodologie eine
detaillierte Spezifikation des Erscheinungsbilds von Webseiten nicht vorgesehen ist.
Am wenigsten geradlinig verlief die Realisierung von Navigations- und Prozessmodell. Dies
liegt daran, dass bei der UWE-Modellierung der Navigationsstruktur eines Websystems keine
expliziten Angaben darüber gemacht werden, an welchen Stellen ein HTTP-Request zu
lancieren ist, der auf Serverseite der Anwendung zu verarbeiten ist. Gerade diese
Informationen werden aber für die Implementierung der Rails-Controller-Klassen benötigt.
Zwar finden sich diese Informationen durchaus im Navigationsmodell, allerdings müssen sie
etwas mühsam extrahiert werden: Hierzu haben wir im entsprechenden Abschnitt über die
Umsetzung (Kapitel 7.3.2) einige Regeln formuliert, mit denen Navigationslinks identifiziert
werden können, deren Durchlaufen keinen HTTP-Request impliziert, der von einer
Controller-Action verarbeitet werden muss. Diese Regeln mögen trivial erscheinen, und bei
der Implementierung des PVS haben wir sie sicher nicht bewusst angewendet: Dies war
schlichtweg nicht nötig, da wir das gesamte System ja selbst entworfen hatten und daher
wussten, für welche Übergänge eine eigene Action benötigt wird. Einem Software-Entwickler,
dem die UWE-Modelle zur Implementierung vorgelegt werden, bleibt aber nichts anderes
übrig, als durch Anwendung dieser Regeln die Request-Response-Struktur der Anwendung zu
erfassen. In diesem Zusammenhang ist es besonders wichtig, dass bei der Modellierung nicht
92