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

Zur Vereinfachung soll angenommen werden, dass der Ablauf des Prozess komplett ohne
weitere Benutzeraktivitäten auskommt – technisch formuliert: Die Aktivität, die den Prozess
beschreibt, enthält keine «userAction»-Aktion. Ein typischer Anwendungsfall einer
solchen Navigationsstruktur könnte z.B. in einem Online-Shop auftreten. In der Detail-
Ansicht eines Produkts befindet sich u.a. eine Schaltfläche 'Zum Warenkorb hinzufügen'.
Wird diese betätigt, so wird ein serverseitiger Prozess initiiert, der entsprechende
Geschäftslogik ausführt (Hinzufügen des Produkts zum Inhalt des Warenkorbs, Aktualisierung
des Gesamtpreises etc.) und abschließend, im Falle eines synchronen Aufrufs, die Detailseite
des Produkts erneut an den Client sendet - diesmal allerdings mit einer Nachricht über den
Erfolg des Prozesses und mit einer aktualisierten Warenkorbanzeige (Es soll angenommen
werden, dass der Warenkorb des Benutzers in einer Sidebar angezeigt wird, die fest zum
Layout des Online-Shops gehört, also auf jeder Seite des Online-Shops zu sehen ist.)
Tatsächlich wäre es sinnvoll, wenn die Anwendung den Prozess nicht synchron, sondern
asynchron aufrufen würde. Es ist nicht nötig, nach Abschluss der serverseitigen
Aktualisierung des Modells die gesamte Detailseite neu zu laden – es genügt vollkommen,
nur die Nachricht in die Seite einzufügen und die Warenkorb-Anzeige zu aktualisieren 56 . Wie
sähe aber die Modellierung dieser asynchronen Variante mit UWE aus? Oder: Wie würde sie
sich von der synchronen Variante unterscheiden?
Es scheint wenig angebracht, den Unterschied zwischen den beiden Alternativen als ein RIA-
Feature zu modellieren, dessen Verhalten durch einen Zustandsautomaten beschrieben wird.
Tatsächlich geht es allein um zwei verschiedene Kommunikationsweisen mit dem Server. Und
alles, was benötigt wird, um den Entwickler für die Umsetzung der gewünschten
Funktionalität ausreichend zu instruieren, ist ein kurzer Hinweis, dass der entsprechende
Prozess nicht wie üblich synchron, sondern eben asynchron aufgerufen werden soll.
Es bietet sich an, diese Information direkt an den Prozesslink zu heften, der den Übergang von
der Produkt-Detailansicht zum Prozess der Warenkorb-Aktualisierung repräsentiert. Dies
kann mit Hilfe eines Tagged Values geschehen, dessen Wert die Art des Requests angibt. Dazu
wird im UWE-Profil dem Modellelement «processLink» am einfachsten ein Metaattribut
asynchronous vom Typ Boolean mit dem Defaultwert false hinzugefügt. Asynchron
zu realisierende Prozessaufrufe kann der Modellierer dann einfach dadurch kennzeichnen,
dass er den Wert dieses Tagged Values für den betreffenden Prozesslink auf true setzt.
Auch im PVS findet sich ein Anwendungsfall dieses Szenarios: Der Login-Mechanismus des
Systems wurde über einen asynchronen Serveraufruf realisiert.
Abbildung 42: PVS-Navigationsmodell (Ausschnitt): Login
Ein asynchroner Login-Request eignet sich hier vor allem deswegen, weil es die erfolgreiche
Anmeldung eines Benutzers nicht erfordert, eine komplett neue Seite an den Client zu senden.
Tatsächlich müssen nur einige UI-Komponenten aktualisiert werden, die zum festen
Seitenlayout der Anwendung gehören (analog zur Warenkorb-Anzeige im vorherigen
56 Ein Beispiel für eine solche Realisierung findet sich bei dem Online-Shop 'musicload' (www.musicload.de)
71