08.12.2012 Aufrufe

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

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

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

MEHR ANZEIGEN
WENIGER ANZEIGEN

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!