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

Ausblick
RIAs zeichnen sich unter anderem dadurch aus, dass sie durch asynchrone Kommunikation
Ladezeiten verkürzen und dem Benutzer das Gefühl vermitteln, er arbeite mit einer Desktop-
Anwendung. Auf den letzten Seiten wurde eine allgemeine Möglichkeit zur Modellierung
asynchroner Requests vorgestellt. Damit ist ein Ausgangspunkt für weitere Überlegungen in
diese Richtung gegeben – Überlegungen, die u.a. die Präzisierung und Ausweitung der
vorgestellten Idee betreffen. Eine detaillierte Ausarbeitung kann im Rahmen dieser Arbeit
nicht erfolgen, deshalb sollen sie an dieser Stelle nur anskizziert werden.
• In einigen Fällen kann sich die Auszeichnung eines Prozesslinks als asynchronous
als zu grobkörnig erweisen. Prozessklassen dienen im Navigationsmodell als
Einstiegspunkte in einen Geschäftsprozess, der eine beliebig komplexe Struktur
aufweisen und unter Umständen eine oder mehrere UserActions enthalten kann, d.h.
Stellen, an denen der Kontrollfluss des Prozesses zum Benutzer zurückkehrt. Die
Realisierung solcher Geschäftsprozesse wird dann notwendigerweise mehrere Requests
an den Server beinhalten – das Ende jeder UserAction impliziert je einen Request. In
einer solchen Situation wird mit der hier vorgeschlagenen Modellierung nicht eindeutig
festgelegt, welche dieser Anfragen asynchron durchgeführt werden sollen. Auch der
gerade diskutierte Anwendungsfall ist in dieser Hinsicht nicht ganz eindeutig. Soll das
Präsentationselement, welches mit der Login-User Action verknüpft ist (also das Login-
Formular), asynchron geladen werden, oder die Verarbeitung der Formulardaten
asynchron erfolgen? In diesem konkreten Fall ergibt sich aus dem Kontext eindeutig,
dass letzteres gemeint sein muss, denn das Login-Formular gehört zum Seitenlayout des
PVS, ist also für nicht-angemeldete Benutzer stets verfügbar. Eine Anweisung, zu Beginn
des Login-Prozesses das Formular dynamisch in die Seite zu laden, würde somit keinen
Sinn ergeben.
In anderen Fällen wird sich diese Unbestimmtheit allerdings nicht über den Kontext
klären lassen. Deshalb ist zu überlegen, ob eine Spezifikation des Request-Typs nicht
(auch) auf feingranularer Ebene in der Aktivität erfolgen muss, die den Workflow des
Prozesses beschreibt – z.B. durch eine geeignete Auszeichnung von Kontrollflusskanten
oder «SystemAction»-Aktionen.
• Übergänge im Navigationsmodell implizieren nicht nur dann Server-Requests, wenn
Prozessklassen im Spiel sind – auch ein Übergang zischen zwei Navigationseinheiten,
die im Modell als gewöhnliche Navigationsklassen repräsentiert sind, bedarf in der Regel
einer Anfrage an den Server. Damit stellt sich auch bei solchen Transitionen die Frage, ob
asynchron oder synchron mit dem Server kommuniziert werden soll. Aus diesem Grund
ist zu überlegen, ob das asynchronous-Metaattribut im Profil nicht direkt an das
Modellelement «link» (der Oberklasse von «navigationLink» und
«processLink») vergeben werden sollte.
• Aktionen, die in einer Prozessaktivität die Aktualisierung der Web-UI beschreiben,
interagieren natürlicherweise mit der Präsentationsschicht. Es ist allerdings nicht klar, ob
eine solche Abhängigkeit eines Prozesses von der Präsentationsschicht in der UWE-
Architektur erwünscht ist. Immerhin ist auf Metaebene das UWE-Prozesspaket nicht vom
Präsentationspaket abhängig. Möglicherweise muss deshalb ein geeigneterer Platz für die
Modellierung der Oberflächenaktualisierung gefunden werden, die am Ende der
Bearbeitung eines asynchronen Requests durchzuführen ist.
73