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

Abbildung 29: Verknüpfung der TagData-Präsentationsgruppe mit dem RIA-Feature-Automaten
TagValidation
Dieser Ansatz zur Modellierung von RIA-Features und Integration in ein UWE-
Präsentationsmodell zeichnet sich durch ein hohes Maß an Freiheit bei der Modellierung aus:
Einzige Vorgabe für den Modellierer ist die Verwendung eines UML-Zustandsautomaten für
jedes konkrete RIA-Feature des zu entwerfenden Websystems. Im Gegensatz zum ersten
Vorschlag, bei dem für jedes konkrete RIA-Feature eine feste Struktur in Form des
entsprechenden Pattern-Automaten vorgegeben ist und nur an einigen wenigen 'Schrauben'
gedreht werden darf (den variablen Elementen des Patterns), werden hier keinerlei
Einschränkungen gemacht. Insbesondere ist der Modellierer nicht verpflichtet, sich an die
festen Vorgaben eines der RIA-Pattern-Automaten (z.B. dessen Zustands-Transitions-
Struktur) zu halten. Falls es das zu modellierende, konkrete RIA-Feature erforderlich macht,
wird er einen Zustandsautomaten erstellen, dessen Grund-Struktur von keinem der bereits
vorhandenen Pattern-Automaten abgedeckt ist.
Dies darf jedoch nicht als Abkehr von einer patternbasierten Modellierungstechnik
missverstanden werden: Die Attraktivität des UWE-Ansatzes besteht ja darin, dass der
Modellierer immer wiederkehrende Strukturen und Verhalten in einer Rich Internet
Application nicht stets von Neuem modellieren muss, sondern auf vorgefertigte Muster
zurückgreifen kann. Diese Muster kommen nun auch bei dem gerade vorgestellten Ansatz
zum Einsatz: Allerdings nicht mehr als fest vorgegebene Strukturen, durch die feste Grenzen
bei der Modellierung eines konkreten RIA-Features vorgegeben sind - die RIA-Pattern dienen
dem Modellierer vielmehr als Vorschläge, die er bei der Modellierung eines RIA-Features als
Vorlagen oder Templates benutzen kann – und von denen er jederzeit in beliebiger Form
abweichen darf. Ein solcher Fall kann z.B. dann auftreten, wenn das zu integrierende RIA-
Feature derart unkonventionell ist, dass es keinen Zustandsautomaten aus der RIA-Pattern-
Bibliothek gibt, dessen Struktur (selbst bei maximaler Anpassung der variablen Elemente)
geeignet ist, um das zu modellierende Verhalten adäquat zu erfassen. In einer solchen
Situation wählt er den 'am besten passendsten' als Vorlage aus und gestaltet ihn anschließend
nach seinem Bedarf um.
Zusätzlich gewinnt der Vorschlag der 'customized RIA state machines' dadurch an
Attraktivität, dass sich Möglichkeiten zur semi-automatischen CASE-Tool-Unterstützung für
den Modellierer anbieten 46 . Ohne Maschinenunterstützung sähe seine Vorgehensweise zur
Modellierung eines RIA-Features folgendermaßen aus: Er würde die im UWE-Profil
befindliche RIA-Pattern-Bibliothek nach einem geeigneten Pattern absuchen und dieses 'per
Hand' als Vorlage in das RIA-Features-Paket seines UWE-Modells kopieren, um es dort
46 Diesen Vorschlag verdanke ich Christian Kroiß und Nora Koch.
56