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

entsprechend seinen Wünschen zu modifizieren. Außerdem müsste er noch das Feature dem
Ziel-Element des Präsentationsmodells über den Tagged Value riaFeature zuweisen.
Diese etwas mühsame Arbeit könnte ihm eine Erweiterung des MagicUWE-Plugins
abnehmen. Deren Funktionalität würde folgendermaßen aussehen:
Anstatt das Pattern-Template in der RIA-Bibliothek zu suchen und anschließend manuell in
das Zielpaket zu kopieren, öffnet der Modellierer das Kontext-Menü des
Präsentationselements, das mit dem RIA-Feature versehen werden soll. Unter einer Option
'RIA-Pattern-Vorlagen' kann er aus einer Liste der verfügbaren Pattern auswählen. Nachdem
ein Name für das Feature festgelegt worden ist, wird das ausgesuchte Pattern automatisch
unter diesem Namen als ConcreteRIAFeature in das RIA-Paket kopiert, wo es vom
Modellierer weiterverarbeitet werden kann. Der Modellierer kann sich optional dafür
entscheiden, dass die variablen Elemente des Patterns in der Vorlage automatisch durch ihre
Defaultwerte (falls vorhanden) ersetzt bzw. konkretisiert werden. Auch das Setzen des
entsprechenden Tag Values beim Ziel-UI-Element übernimmt das Tool. Außerdem wird im
generierten ConcreteRIAFeature an einer geeigneten Stelle vermerkt, welches RIA-
Pattern als Vorlage dient. Schließlich wird im Diagramm des gerade erzeugten Elements die
Schrift- und Zeichenfarbe verändert. Dadurch werden sich die durchgeführten Veränderungen
vom übrig gebliebenen Gerüst des RIA-Pattern optisch abheben, und der Modellierer kann
stets erkennen, welche Elemente er dem Pattern-Template hinzugefügt hat.
5.3 Ein Hybrid-Vorschlag zur Modellierung von RIA-Features
In den letzten beiden Sektionen wurden zwei Vorschläge diskutiert, die den UWE-Ansatz zur
RIA-Modellierung erweitern und ihm eine höhere Ausdruckskraft verleihen. Hinsichtlich
ihrer Stärken und Schwächen sind sie komplementär: Die zweite Modellierungstechnik,
welche auf der Erstellung eigener RIA-Zustandsautomaten basiert, ist sehr generisch: RIA-
Patterns dienen nur als Vorlagen, die beliebig an die Erfordernisse des konkret zu
modellierenden Features angepasst werden können. Allerdings bringt diese Allgemeinheit
einen gewissen 'Overhead' bei der Modellierung mit sich. Für jedes konkrete RIA-Feature, das
modelliert werden soll, muss ein eigener Zustandsautomat angelegt werden, selbst wenn das
zu modellierende Verhalten vollkommen 'standardmäßig' ist, d.h. durch ein RIA-Pattern aus
der Pattern-Bibliothek und seine Defaultwerte schon vollständig beschrieben ist. Zwar würde
durch CASE-Tool-Unterstützung wie oben beschrieben ein entsprechender
«ConcreteRIAFeature» - Automat automatisch generiert werden, so dass der
Modellierer kaum Arbeit zu verrichten hätte. Doch für den Entwickler, der die UWE-Modelle
umzusetzen hat, ist es bisweilen umständlich, bei jedem zu realisierenden RIA-Feature, auf
das er durch einen entsprechenden Tagged Value im Präsentationsdiagramm hingewiesen
wird, die genaue und ausführliche Spezifikation im RIA-Feature-Paket abzurufen. Gerade bei
einfachen Features, deren Verhalten durch ein RIA-Pattern inklusive Defaultwerte
ausreichend spezifiziert ist, würde ein kurzer Hinweis im entsprechenden Element des
Präsentationsmodells vollkommen genügen, um einen erfahrenen RIA-Entwickler
ausreichend zu instruieren - insbesondere dann, wenn dieser mit den UWE-RIA-Patterns
genügend vertraut ist. Und bei genau diesen Fällen liefert, wie oben dargelegt, der erste
Vorschlag eine knappe und gleichzeitig hinreichend präzise Modellierung.
Zur Auswahl stehen also zwei Modellierungstechniken, die sich hinsichtlich ihrer Stärken
vortrefflich ergänzen würden. In einer solchen Situation empfiehlt es sich, auf eine
Entscheidung für eine der beiden Alternativen und gegen die andere zu verzichten, und sich
stattdessen um eine Lösung zu bemühen, welche die Stärken beider Gegenspieler in sich
57