2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...
2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...
2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Erweiterung des <strong>UWE</strong>-Profils:<br />
«presentationElement» wird um einen stringwertigen Tagged Value<br />
«dynamicDisplay» ergänzt.<br />
5.6 Asynchron angeforderte Prozesse<br />
Die Behandlung der Thematik 'RIA' im Rahmen des <strong>UWE</strong>-Ansatzes hat sich bisher darauf<br />
beschränkt, typische RIA-Features zu modellieren und in die alten <strong>UWE</strong>-Modelle zu<br />
integrieren. RIA-Features werden dabei als funktionale Einheiten aufgefasst, deren Verhalten<br />
sich abgesondert vom Rest der Anwendung zumindest schematisch beschreiben lässt, und die<br />
sich – gewissermaßen als in sich vollständige Pakete – in ein <strong>Web</strong>system integrieren lassen.<br />
Diese Sichtweise hat ihre Berechtigung, wenn man an typische Merkmale einer RIA wie<br />
Autovervollständigung von Benutzereingaben, Live-Validierung von Eingabefeldern eines<br />
<strong>Web</strong>formulars oder Drag&Drop-Funktionalität zur interaktiven Gestaltung einer<br />
<strong>Web</strong>oberfläche denkt. Im Folgenden soll ein wichtiger Aspekt von RIAs untersucht werden,<br />
der – zumindest potentiell – omnipräsent in einer RIA sein kann und sich deswegen nicht<br />
durch ein in sich abgeschlossenes Feature erfassen lässt: der Aspekt der asynchronen<br />
Datenübertragung.<br />
Herkömmliche '<strong>Web</strong> 1.0'-Anwendungen zeichnen sich dadurch aus, dass sie einem Request-<br />
Response-Paradigma gehorchen, das auf synchroner Kommunikation beruht: Ein Client,<br />
typischerweise ein Browser, stellt eine Anfrage an einen Server, diese wird dort behandelt,<br />
eine neue HTML-Seite wird an den Client geschickt. Dort wird sie im Browser dargestellt,<br />
und erst jetzt kann der Benutzer mit seinen Aktivitäten fortfahren, die während der<br />
serverseitigen Abarbeitung des Requests blockiert waren. RIAs überwinden dieses<br />
Kommunikationsmodell, indem sie auf asynchrone Kommunikation mit dem Server setzen.<br />
Der Kontrollfluss kehrt direkt nach Absenden eines asynchronen Requests zurück zum<br />
Browser, und der Benutzer kann normal weiterarbeiten, ohne auf die Antwort des Servers zu<br />
warten. Die Aktualisierung der <strong>Web</strong>-Oberfläche erfolgt dynamisch, insbesondere wird keine<br />
vollständige, neue HTML-Seite geladen: Als Antwort auf den Request werden in der Regel<br />
nur einzelne Teile der <strong>Web</strong>seite aktualisiert<br />
Zumindest theoretisch könnte eine RIA ihr Request-Verhalten vollständig 'asynchronisieren' –<br />
jede Anfrage, die der Benutzer über die <strong>Web</strong>-Oberfläche lanciert, wird asynchron an den<br />
Server gesendet. Wie würde man eine solche Anwendung mit <strong>UWE</strong> adäquat modellieren?<br />
Vermutlich nicht, indem für jede asynchrone Anfragemöglichkeit ein eigenes RIA-Feature in<br />
die Modellierung integriert wird.<br />
Abbildung 41 zeigt einen Ausschnitt aus einem <strong>UWE</strong>-Navigationsdiagramm, der ein simples,<br />
aber typisches Navigationsschema modelliert. Von einer Navigationsklasse aus kann ein<br />
Prozess aufgerufen werden, nach dessen Abarbeitung kehrt der Navigationsfluss zur<br />
Navigationsklasse zurück.<br />
Abbildung 41: Ausschnitt aus einem Navigationsdiagramm<br />
70