3.2 Validierung des GUI-Modells

Besonderen Wert haben wir auch auf die Validierung des erstellten Modells gelegt. Die von uns verwendeten Statechart-Diagramme unterliegen als Bestandteil der UML [UML03] festgelegten Spezifikationen und so sollen auch die mit unserem Werkzeug erstellten Statecharts gültig im Sinne der UML sein. Statecharts, die zu der definierten Sprache nicht vollständig konform sind, können weder in eindeutiger Weise interpretiert werden, noch können sichere Aussagen darüber gemacht werden, ob sie einen deterministischen Ablauf beschreiben. Ein deterministischer Ablauf ist mit Hinblick auf den Einsatz zur Modellierung des Verhaltens einer Benutzungsschnittstelle natürlich unabdingbar.

Daher ist es von essentieller Bedeutung, dass die erstellten Statecharts einer Validierung unterzogen werden, bevor dem Generierungsmodul die Freigabe für das entsprechende Statechart erteilt wird und eine Simulation der GUI stattfinden kann.

Dabei geht es nicht nur darum, die Fehler im Modell zu finden, sondern diese dem Anwender auch entsprechend zu präsentieren. Die Validierung darf dabei den Benutzer bei der Editierung des Modells nicht über die Maßen behindern. Dies wird durch zwei wesentliche Konzepte gewährleistet.

Zum einen erfolgt eine Validierung auf der Ebene des Editors, indem durch auferlegte Restriktionen Editierfunktionalitäten derart eingeschränkt werden, dass sie es dem Benutzer einfach nicht erlauben, fehlerhafte Dinge zu modellieren. So lassen sich grundlegende syntaktische Anforderungen an ein Statechart bereits durch eine entsprechende Konzeption der Editierfunktionalitäten sicherstellen. Es wird dem Anwender beispielsweise nicht erlaubt, eine eingehende Transition an einen Startzustand zu legen. Durch dieses Vorgehen werden von vornherein wichtige Korrektheitsmerkmale eingehalten und einfachste Regeln der Statechart-Syntax dem Benutzer nähergebracht.

Neben dieser syntaxgesteuerten Form der Validierung werden komplexere Korrektheitsüberprüfungen durch die statische Analyse durchgeführt. Das Statechart wird dabei intensiven Überprüfungen unterzogen. Hier werden syntaktische Probleme wie etwa uneindeutige Zustandsnamen, fehlende Startzustände oder Transitionen, die den deterministischen Ablauf verletzen, erkannt. Alle während eines Validierungsdurchlaufs gefundenen Probleme werden gesammelt, um anschließend detailliert Rückmeldung (Feedback) und Lösungsvorschläge für die gefundenen Probleme anbieten zu können. Erst nachdem ein GUI-Modell diese Validierungsebene einwandfrei passiert hat, wird es zur Generierung und damit zur Simulation freigegeben.

Dabei werden Probleme in zwei Kategorien unterteilt: Fehler und Warnungen. Fehler sind kritische Probleme, die behoben werden müssen, bevor eine Simulation stattfinden kann; Warnungen können dagegen vom Anwender ingnoriert werden und verhindern nicht die Simulation des GUI-Modells. Trotzdem sollte der Benutzer die Warnungen zur Kenntnis nehmen, da ihn diese auf schlechten Stil oder konzeptionelle Schwächen des Modells hinweisen. Somit ist die statische Analyse nicht nur in der Lage, ein syntaktisch korrektes Modell zu fordern, sondern assistiert dem Entwickler auch in der qualitativen Überprüfung der modellierten GUI.

Die statische Analyse bildet das Herzstück der Validierung. Hier werden die meisten Fehler des Modells entdeckt. Dies erlaubt es, die Restriktion der Editierfunktionalitäten auf ein Minimum zu beschränken und nur dort einzusetzen, wo es auch wirklich sinnvoll ist. Nichts ist schlimmer, als einen Anwender durch zu starke Einschränkungen der angebotenen Funktionen in seinem kreativen Gestaltungsprozess zu behindern. Es ist klar, dass im Laufe der Editierung das Modell zwischenzeitlich fehlerhafte Zustände annimmt. Dies sollte dem Anwender nicht zum Hindernis gemacht werden, solange er das Modell nicht generieren möchte. Daher werden durchaus problembehaftete Editierungen zugelassen, wobei lediglich in passiver Weise die dabei entstehenden Probleme registriert und angezeigt werden, anstatt aktiv einzugreifen und die Editiervorgänge direkt zu unterbinden. Die Editierfunktionen sind dazu da, den Anwender zu unterstützen und ihm einen möglichst großen Freiraum in der Modellierung einzuräumen, und nicht, um ihn in seinem Schaffen zu limitieren und in zu eng vorgeschriebenen Pfaden zu gängeln.

Alle in der statischen Validierung gefundenen Probleme werden dabei zum einen in einer separaten Ansicht gemeinsam präsentiert, und zum anderen dezentral direkt an den Modellelementen, die Ursache des jeweiligen Problems sind, kenntlich gemacht. So hat der Anwender die Möglichkeit, sich einen Überblick über die gefundenen Probleme zu verschaffen und kann gleichzeitg anhand der graphischen Repräsentation der Probleme an den ursächlichen Modellelementen diese leicht im Modell wiederfinden.

Figure 3.7: Graphisches Feedback über gefundene Probleme

 

Das graphische Feedback gibt dabei auch gleichzeitig näheren Aufschluss über die Art und die genauere Ursache des Problems. Fehler und Warnungen erhalten also unterschiedliche graphische Repräsentationen, welche zudem noch für jeden konkreten Fehler und jede konkrete Warnung unterschiedlich spezifiziert werden können.

Trotz der großen Bandbreite an Überprüfungen ist die statische Analyse noch nicht vollends ausreichend, um korrekte Statecharts zu gewährleisten. Einige komplexe und zeitaufwendige Korrektheitsanforderungen übernimmt die dynamische Analyse. Diese ist in die Simulation integriert und prüft zur Laufzeit, ob Anforderungen an das Statechart, mit besonderem Blick auf den Einsatz als Verhaltensbeschreibung einer GUI, verletzt werden.

Zu den überprüften Fehlern zählen zum Beispiel der Eintritt in eine Endlosschleife oder die Verletzung des deterministischen Verhaltens. Beim Auftreten eines solchen Problems wird die Simulation abgebrochen und der Anwender über das gefundene Problem, und damit die Ursache des Abbruchs, informiert.