4.3 Modell-Validierung und Feedback

Die Restriktionen der Editierfunktionalitäten werden auf die Ausführbarkeit von Commands abgebildet. Ein Command übernimmt im MVC-Konzept von GEF die Änderungen am Modell, die der aktuell vom Anwender beschriebenen Editierung entsprechen. Commands können mitteilen, ob sie ausführbar sind oder nicht. Beschreibt ein Command also eine Änderung, die zu einem ungüligen Modell führen würde, so lässt sich die Ausführung dieses Commands verweigern. Der Anwender wird dann durch einen veränderten Mauszeiger auf die Nichtausführbarkeit seines Editierwunsches aufmerksam gemacht, indem er zum Beispiel ein Verbotschild angezeigt bekommt.

Bei der Editierung von Properties eines GUI-Elements, sei es über den Properties-View oder über den Eigenschaften-Dialog, wird zur Validierung der Wertzuweisungen auf die von dem jeweiligen Property bereitgestellten PropertyValidator (Abb. 4.11) zurückgegriffen. Der Property-Validator bekommt den Wert übermittelt, den der Anwender dem Property zuweisen möchte und kann daraufhin diesen ablehnen, indem er eine Fehlermeldung zurückliefert, oder er kann den Wert akzeptieren. Nur wenn der Property-Validator den Wert akzeptiert, kann der Benutzer die Wertzuweisung erfolgreich abschließen. Von einem Property-Validator zurückgelieferte Fehlermeldungen werden dabei dem Benutzer an geeigneter Stelle angezeigt.

Figure 4.11: Klassenstruktur der Validatoren

 

Von diesen restriktiven Möglichkeiten der Validierung wird aber in den meisten Fällen aus den in der Konzeption bereits erläuterten Gründen abgesehen, und durch die statische Validierung substituiert. Die statische Validierung wird von einem Validator durchgeführt. Ein Validator ist dabei erstmal nur ein Manager für die in ihm gekapselte ValidationUnit. Diese Validation-Unit übernimmt die eigentliche Validierungsarbeit. Sie allein ist über das zu validierende Objekt informiert und hat die Fähigkeit, Probleme in diesem festzustellen. Durch diese Struktur ist es möglich, die Verwaltungsstruktur des Validators für beliebige Validierungen wiederzuverwenden. Es ist nur noch notwendig, eine entsprechende Validation-Unit zu schreiben, die vollständig auf die eigentliche Validierungsarbeit reduziert ist.

Der Validator übernimmt die Steuerung der ValidationUnit. Er stößt Validierungsprozesse an oder bricht diese ab. Die Validierung läuft dabei in einem separaten Prozess (Job) im Hintergund ab. Desweiteren übernimmt der Validator die Verwaltung der durch die ValidationUnit entdeckten Probleme. Unterstützt wird er dabei durch das ProblemRepository (Abb. 4.12).

Figure 4.12: Klassenstruktur der Validierung

 

Um wirklich so wenig Intelligenz und damit vebundenen Aufwand wie nur möglich in die Validation-Unit zu stecken, ist diese lediglich dazu in der Lage, einen kompletten Validierungsdurchgang auf dem zu validierenden Objekt durchführen. Es ist ihr nicht möglich, den aktuellen Durchlauf mit bereits vorher durchgeführten Validierungsdurchläufen zu vergleichen und so einzuschätzen, welche Probleme neu entstanden, welche geblieben und welche beseitigt wurden. Alle diese Aufgaben übernimmt das Problem-Repository des Validators, welches von der konkrekt durchzuführenden Validierung losgelöst ist und somit als Teil der Verwaltungsfunktionen des Validators voll wiederverwendbar ist.

Das Problem-Repository übernimmt also die Verwaltung von Problemen und kann feststellen, wie sich die vorhandenen Probleme von einem Validierungsdurchlauf zum Anderen verändern. Nur diese Veränderungen teilt das Problem-Repository dem Validator mit, der dann daraufhin die betroffenen Modellteile informiert (vgl. Abb. 4.13).

Figure 4.13: Validierungsprozess

 

Modellteile, die fehleranfällig sind (Problematic), können Probleme temporär für eine laufende Sitzung von GuiBuilder aufnehmen, und diese entsprechend durch ihre graphische Darstellung visuell kenntlich machen (siehe Abb. 4.14).

Figure 4.14: Interface Problematic

 

Ein Problem besteht dabei aus einer textuellen Problembeschreibung (Description), einem Schweregrad (Severity), den Modellteilen, die von dem Problem betroffen sind und deshalb vom Validator über dieses informiert werden, und schließlich eventuell vorhandenen Lösungen für das Problem.

Jedes konkrete Problem ist dabei eine Spezialisierung der allgemeinen Problemklasse und lässt sich so auch über den Klassennamen identifizieren (Abb. 4.15). Ein Problem kapselt also alle relevanten Informationen, so dass die betroffenen Modellteile sowohl über ihre graphischen Repräsentationen (Figures) Feedback über die existierenden Probleme geben können als auch - wenn nötig - Lösungen des Problems bereitstellen können.

Figure 4.15: Hierarchie der Probleme

 

Das Feedback fällt je nach Problem unterschiedlich aus. Im Allgemeinen ändert sich die Farbe des jeweils betroffenen Modellelements. Eine rötliche Farbe kennzeichnet Elemente, die von Fehlern betroffen sind, und gelbliche Farben weisen auf Warnungen hin. Jede Figure eines Modellelements, das von Problemen betroffen sein kann, ist in der Lage, durch seine Schnittstelle über im Modell existierende Probleme informiert zu werden und dann sein Aussehen entsprechend anzupassen. Ändern sich also im Modellelement die Probleme, so wird die Steuerungskomponente des Elements diese Änderungen an die Figure weiterleiten, welche daraufhin diese Probleme entsprechend graphisch kenntlich macht (siehe Abb. 4.16).

Figure 4.16: Benachrichtigungsprozess über gefundene Probleme

 

Für die Auszeichnung von Inhalten einer Ressource (hier: Datei) bietet Eclipse sogenannte Marker an. Ein Marker lässt sich mit beliebigen Informationen beschreiben und mit einer Ressource temporär oder permanent verbinden. Für die Kennzeichnung von Problemen, die sich innerhalb einer Ressource befinden, bietet Eclipse einen speziellen Problem-Marker an, der mit standardisierten Informationen (Problembeschreibung, Schweregrad) beschrieben werden kann. Auszeichnungen, die in dieser Form an einer Ressource vorgenommen werden, finden sich automatisch im Problems-View wieder. Der Problems-View von Eclipse listet dann alle diese Probleme mit ihrer Beschreibung und ihrem Schweregrad auf.

Von dieser von Eclipse bereitgestellten Funktion machen wir Gebrauch. Probleme können dazu die in ihnen gekapselten Informationen über die Methode setMarkerAttributes auf einen übergebenen Marker schreiben. Diese Methode wird vom Problem-Repository für neu entdeckte Probleme aufgerufen. Das Problem-Repository lässt dazu vom Validator, der über die aktuell im Editor geöffnete Ressource Bescheid weiß, einen Marker erzeugen, der dann mit den Informationen des neu entdeckten Problems beschrieben wird und anschließend zusammen mit dem Problem im Problem-Repository verwaltet wird. Die Marker dienen dabei als Identifikatoren der Probleme innerhalb des Eclipse-Systems. Das Problem-Repository stellt deshalb Funktionen bereit, die einen Marker auf sein zugehöriges Problem abbilden können.

Wie bereits erwähnt, stellen Probleme gleichzeitig eventuell vorhandene Lösungen bereit. Lösungen (Resolutions) bestehen aus einer textuellen Beschriftung (Label) und kapseln Modifikationen am Modell, welche das Problem beseitigen (vgl. Abb. 4.17). Diese Modifikationen (Commands) werden ausgeführt, wenn die run-Methode einer Resolution aufgerufen wird. Egal wo das Problem auch präsentiert wird, es stehen immer die Lösungen zum Abruf bereit und lassen sich so dem Benutzer zum Beispiel in Form eines Dialogs zur Auswahl anbieten.

Figure 4.17: Hierarchie der Lösungen