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

Eingaben sollen folgendermaßen validiert werden:
• Es besteht keine Pflicht zur Angabe von Tags, d.h. es ist erlaubt, dass beide Felder leer
bleiben. Allerdings sind unvollständige Angaben nicht erlaubt, d.h. wenn ein Feld
ausgefüllt ist, muss auch das andere einen nicht-leeren Wert besitzen. Insbesondere
bedeutet dies:
◦ Verliert das Wert-Eingabefeld den Fokus, so muss kontrolliert werden, ob
Schlüssel und Wert leer sind. Ist dies der Fall, so wird kein Validierungsfehler
angezeigt. Ist der Wert leer, nicht jedoch der Schlüssel, so muss im Textelement für
das Wert-Validierungsresultat eine Fehlermeldung angezeigt werden. Ist der
Schlüssel leer, nicht jedoch der Wert, so ist das Textelement für das Schlüssel-
Validierungsresultat mit einer Fehlermeldung zu aktualisieren.
◦ Verliert das Schlüssel-Eingabefeld den Fokus, so ist für den Fall, dass der
Schlüssel, nicht jedoch der Wert leer ist, analog zu oben zu verfahren. Ist
allerdings die Eingabe für den Schlüssel nicht-leer, die für den Wert aber, so ist im
Gegensatz zu oben kein Validierungsfehler anzuzeigen. Denn dann ist
anzunehmen, dass der Benutzer gerade mit der Eingabe der Tag-Daten begonnen
hat und das Wert-Feld nun zum ersten Mal fokussiert, d.h. noch gar nicht die
Chance hatte, dort eine Eingabe zu machen. In einem solchen Fall sollte er nicht
unnötig mit verfrühten Fehlerwarnungen gegängelt werden.
Es ist klar, dass diese Informationen unmöglich aus dem Präsentationsmodell oder dem
Pattern-Automaten extrahiert werden können. Die Modellierung enthält schlichtweg zu wenig
Informationen, um eine korrekte Realisierung des gewünschten Features anzuleiten.
Verallgemeinert man die Ergebnisse dieser beiden Fallbeispiele, so kann festgehalten werden:
Liefert die hier angewandte Modellierungstechnik bei einfachen, standardmäßigen
Ausprägungen eines RIA-Features noch brauchbare, wenn auch wenig präzise
Implementierungsanleitungen, so offenbaren sich ernsthafte Unzulänglichkeiten, je
komplizierter die Struktur der konkreten Instanz des Patterns ist bzw. je mehr diese vom
Standardfall abweicht. Sowohl die Ausdrucksstärke der RIA-Modellierung mit UWE als auch
deren Umsetzbarkeit lassen zu wünschen übrig.
5.2 Verbesserungsvorschläge
5.2.1 Variable Elemente, Kommentare und Defaultwerte
Die Diskussion im vorherigen Abschnitt hat gezeigt, dass eine hinreichend präzise und gut
umsetzbare Modellierung eines konkreten RIA-Features einen höheren Informationsgehalt
aufweisen muss als die Modellierung des RIA-Patterns, welches nur ein allgemeines Schema
vorgibt. Im Falle der Live-Validierung wurden bereits diejenigen Elemente identifiziert,
welche für eine konkrete Anwendung des Patterns einer Konkretisierung bedürfen: der
Trigger userInteraction des Validierungsmechanismus, die do-Aktivität
validate(input), in deren Rahmen die eigentliche Validierung durchgeführt wird, sowie
die Transitionsaktivität displayValidationResult, die für die Darstellung des
Validierungsresultats verantwortlich ist.
50