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

vergessen wird, den Tagged Value isAutomatic für automatisch zu durchlaufene Links zu
setzen. Ansonsten kann der Entwickler schnell in die Irre geführt werden und wird
möglicherweise für einen solchen Link eine überflüssige Action implementieren. Seinen
Fehler wird er dann erst beim Studium des Präsentationsmodells erkennen, wenn er
herausfindet, dass sich die Präsentationsgruppen der beiden über den Link verbundenen
Navigationsklassen im selben Container befinden und damit gleichzeitig darzustellen sind.
In dieser Hinsicht sind die Workflow-Aktivitäten des Prozessmodells übrigens besser zu
lesen: Durch die Unterscheidung zwischen UserActions, die Useraktivitäten auf der
Weboberfläche repräsentieren, und SystemActions ist relativ einfach zu erkennen, welche
UML-Actions in einer Rails-Controller-Action zusammenzufassen sind. Generell können wir
feststellen, dass die Prozess-Aktivitäten eine sehr brauchbare Anleitung für die
Implementierung von (Rails-)Actions lieferten.
Die Tatsache, dass es bei Rails keine Entsprechung zu den UWE-Konzepten der Navigations-
und Prozessklasse gibt, haben wir bei der Umsetzung als wenig problematisch empfunden.
Die Spezifikation von Navigations- und Prozesseigenschaften erachten wir sogar als sehr
hilfreich, auch wenn diese Konstrukte nicht 1:1 auf Rails-Ebene abgebildet werden. Dadurch
erhält man schon auf Navigations- bzw. Prozessebene einen kompakten Überblick über die
Daten, die später auf Präsentationsebene darzustellen sind bzw. (bei Prozesseigenschaften) im
Rahmen der Prozessdurchführung vom Benutzer auf der UI anzugeben und vom System zu
verarbeiten sind.
Allerdings sei im Zusammenhang mit dem Fehlen der Navigationsschicht bei Rails auf eine
'Unhandlichkeit' hingewiesen, mit der man bei der Implementierung mit Rails konfrontiert
wird, wenn man, anders als in unserem Fall, als Programmierer nicht auch für die
Modellierung verantwortlich war und sich demzufolge erst einen Überblick über die
Zusammenhänge zwischen den einzelnen Modellen verschaffen muss. Eine typische
Vorgehensweise bei der Realisierung eines einfachen Anwendungsfalls, der, sagen wir einen
HTTP-Request beinhaltet, ist es, zunächst die Controller-Action zu programmieren, die den
Request verarbeitet, und im Anschluss daran das Template zu kreieren, das von der Action
gerendert wird. Modell-Grundlage für den ersten Schritt wird das Navigationsmodell (und
unter Umständen auch das Prozessmodell) sein. Für die Realisierung des zweiten Schritts
findet der Entwickler im Navigationsmodell zwar den Navigationsknoten, der dort
gewissermaßen als abstrakte Repräsentation des Templates dient; doch was er wirklich als
Anleitung zur Programmierung des Templates benötigt, ist die Präsentationsgruppe, die mit
diesem Knoten verknüpft ist. Und in Anbetracht des Umfangs, den UWE-
Präsentationsmodelle in der Regel aufweisen, kann die Suche nach ihr je nach verwendetem
CASE-Tool zu einer Suche nach der Stecknadel im Heuhaufen ausarten. Bei Verwendung von
MagicDraw muss man glücklicherweise das Präsentationsdiagramm nicht 'zu Fuß'
durchkämmen, da hier sehr gute Suchfunktionalitäten zur Verfügung stehen: Für die Suche
nach einem Modellelement in einem Diagramm kann als Suchparameter z.B. ein Tagged
Value samt gewünschtem Wert angegeben werden, d.h. die gesuchte Präsentationsgruppe
kann über ihren navigationNode-Tagged Value mit relativ wenig Aufwand gefunden
werden. Angenehmer allerdings wäre es, wenn man von dem betreffenden Navigationsknoten
direkt ins Präsentationsdiagramm zum zugehörigen UI-Element springen könnte. Eine solche
'Sprung'-Funktionalität, die man als MagicUWE-Erweiterung realisieren könnte, würde es
dem Entwickler deutlich erleichtern, die Bezüge zwischen Navigations- und
Präsentationsmodell zu erfassen.
Mit diesem Vorschlag für ein weiteres MagicUWE-Feature wollen wir die Diskussion der
Umsetzbarkeit von Navigations- und Prozessmodell beenden. Trotz der kleineren
93