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

vereint. Dies wird mit dem folgenden, umfassenden Vorschlag für die Erweiterung des UWE-
Ansatzes zur RIA-Modellierung versucht:
Vorschlag 2, der auf der Erstellung eines eigenen Zustandsautomaten für jedes konkrete RIA-
Feature basiert, wird vollständig in den UWE-Ansatz übernommen. Damit wird dem
Modellierer maximale Freiheit bei der Beschreibung von RIA-Features gegeben. Die RIA-
Patterns samt ihrer Defaultwerte sind als Templates unverzichtbarer Bestandteil dieser
Vorgehensweise. Da jedoch potentiell jedes Element eines Pattern-Automaten veränderbar ist,
erfolgt keine Unterscheidung mehr zwischen variablen und festen Elementen eines Pattern,
nur noch zwischen Elementen mit einem Default-Wert und Elementen ohne einen solchen.
Dem Modellierer kann durch eine noch zu realisierende Erweiterung des MagicUWE-Plugins
ein gewisser Teil der Modellierarbeit abgenommen werden.
Vorschlag 1 wird in veränderter Form übernommen, um die Modellierung von Standard-RIA-
Features zu vereinfachen. Die Idee hinter der Übernahme dieser Vorgehensweise ist es, dem
Modellierer die Möglichkeit zu geben, mit einer kurzen, informellen Beschreibung des
gewünschten RIA-Verhaltens ein Präsentationselement mit einem RIA-Feature zu versehen,
ohne einen eigenen Zustandsautomaten erstellen zu müssen. Bei der Formulierung eines
solcher Verhaltensbeschreibung ist der Modellierer an keinerlei Vorgaben gebunden. Alles ist
erlaubt, was dem für die Umsetzung der Modelle verantwortlichen Software-Entwickler
ermöglicht, das Verhalten des zu modellierenden Features zu erfassen. Intendiert sind jedoch
extrem kurze Kommentare bzw. Schlagworte, die vor allem von erfahrenen RIA-Entwicklern
verstanden werden. Für eine Live-Validierung eines verpflichtend auszufüllenden Email-
Eingabefeldes, das sich ansonsten standardmäßig verhält (blur-Ereignis als Auslöser, Anzeige
von Validierungsfehlern direkt unter dem Eingabefeld) könnte eine solche informelle
Spezifikation schlicht 'match emailRegExp, not empty' lauten. Die restlichen Informationen
hat sich der Entwickler aus dem Kontext oder durch einen Blick auf die Defaultwerte des
entsprechenden RIA-Patterns zu erschließen.
Für einen solchen Hinweis sollte allerdings kein UML-Kommentar verwendet werden. Das
Präsentationsdiagramm in UWE-Modellen ist in der Regel sehr groß und allein aufgrund
seiner Ausmaße unübersichtlich. Angesichts dessen ist es sinnvoll, die Anzahl der grafischen
Elemente in diesem Diagramm nicht noch zusätzlich durch Kommentare zu erhöhen.
Stattdessen bietet es sich an, die 'alten', boolschen Tagged Values, die in der ursprünglichen
Version des RIA-Modellierungsansatzes allein zur Angabe des RIA-Patterns dienten, zu
modifizieren und ihre Funktion zu erweitern: Sie werden in stringwertige Tagged Values
verwandelt und können damit zusätzlich zu einer kurzen Verhaltensbeschreibung des RIA-
Features verwendet werden.
Wichtig ist, dass dieser Mechanismus nicht missbraucht werden sollte, um detaillierte
Informationen über ein RIA-Feature zu spezifizieren. Er sollte nur dann eingesetzt werden,
wenn davon ausgegangen werden kann, dass durch einige wenige Worte der Entwickler in die
Lage versetzt wird, das Feature wunschgemäß zu realisieren. Für die Bereitstellung
ausführlicherer Informationen ist auf jeden Fall ein «concreteRIAFeature»-Automat zu
verwenden.
Wir sind uns bewusst, dass bei dieser Vorgehensweise das Prinzip der Trennung von Struktur
und Verhalten bei der Modellierung eines Systems zu einem gewissen Grad verletzt wird.
Denn durch die Angaben in den Tagged Values fließen verhaltensbeschreibende Elemente in
das Präsentationsmodell ein, das streng genommen nur für die Festlegung struktureller
58