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

könnte man sagen, dass diese erste Controller-Action bzw. der von ihr verarbeitete HTTP-
Request dem zur Prozessklasse hinführenden Prozesslink entspricht.
Die zweite Action, die benötigt wird, ist in der Regel wesentlich komplexer als die erste, da
sie ein wesentlich höheres Maß an Kommunikation mit Modell-Klassen enthält. Sie steuert
die Verarbeitung der Daten, die der Benutzer über die Prozess-UI an den Server gesendet hat.
Ihr Ablauf entspricht dem Teil der UML-Workflow-Aktivität des betreffenden Prozesses, der
auf die UserAction folgt und aus einer Abfolge von SystemActions besteht: Benutzerdaten
werden in Modellobjekten zusammengefasst, Validierungsfunktionalität von Modellklassen
wird aufgerufen, die Modell-Schicht wird beauftragt, Datenbankoperationen durchzuführen
etc., um nur einige typische Bestandteile des Ablaufs einer solchen Controller-Action zu
nennen.
Es ist allerdings zu beachten, dass es Prozesse geben kann, für deren Realisierung mehr als
zwei Controller-Actions erforderlich sind: Dies trifft auf solche Prozesse zu, in dessen
Workflow es mehr als nur eine Stelle gibt, an der der Benutzer Eingaben machen muss, um
den Workflow voranzutreiben - die entsprechende UML-Aktivität enthält mehr als eine
UserAction. In einem solchen Fall muss die Workflow-Aktivität auf mehrere
(Controller-)Actions aufgeteilt werden, da das Ende einer jeden UserAction in der Regel einen
eigenen HTTP-Request nach sich zieht: Der Benutzer schickt an mehreren Stellen im Prozess-
Fluss Daten zur (Weiter-)Verarbeitung auf Serverseite ab.
Wie für Navigationsklassen gilt schließlich auch für Prozesse, die in die Navigationsstruktur
eingebunden sind, dass eine explizite Definition von Prozesseigenschaften in der Rails-
Controller-Komponente nicht vorgesehen ist. Alle Daten, die ein Benutzer z.B. in einem
Formular angegeben hat, stehen der Action, die für deren Verarbeitung zuständig ist,
gesammelt in dem schon oben erwähnten params-Objekt zu Verfügung. Die Daten müssen
'per Hand' zunächst aus diesem Objekt ausgelesen werden, um in der Folge geeignet
verarbeitet werden zu können.
7.3.3 Umsetzung des Präsentationsmodells
Wie schon im letzten Abschnitt vorweggenommen, wird ein UWE-Präsentationsmodell in der
View-Komponente einer Rails-Anwendung realisiert. Es ist klar, dass aufgrund des
Abstraktionsprozesses, der das Modellieren begleitet, der HTML- und CSS-Code echter
Webseiten - und so auch der Code der Webseiten des PVS – wesentlich mehr
Detailinformationen beinhaltet, als im Präsentationsmodell spezifiziert sind. Insbesondere
wird bei UWE vollkommen darauf verzichtet, Layout-Informationen über das
Erscheinungsbild (wie z.B. Farbe oder Schriftgröße) und die Position von UI-Elementen auf
einer Webseite zu spezifizieren. Was also die konkrete Gestaltung der Webseiten angeht, so
dient das UWE-Präsentationsmodell in erster Linie als Skizze, welche die wesentlichen
Aspekte der Weboberfläche festlegt.
Die Umsetzung der Modellierung der PVS-Präsentationsschicht orientierte sich im
Wesentlichen an drei Richtlinien: Erstens wurden Präsentationsgruppen, die mehr oder
weniger eigenständige UI-Einheiten verkörpern und für die Darstellung eines Knotens aus
dem Navigationsmodell zuständig sind, als (ERb)-Templates umgesetzt. Zweitens wurden UI-
Eigenschaften wie z.B. «anchor»-, «textInput»-, «selection»- oder «text»-
Elemente, die als Parts von Präsentationsgruppen Interaktionsmöglichkeiten für den Benutzer
repräsentieren oder für die Präsentation konkreter Inhalte zuständig sind, innerhalb des
jeweiligen Templates mit Hilfe geeigneter HTML-Elemente realisiert. Diese wurden entweder
85