11.07.2015 Aufrufe

ODL-Sprachkonstrukte und interaktive Benutzerschnittstelle - TUM

ODL-Sprachkonstrukte und interaktive Benutzerschnittstelle - TUM

ODL-Sprachkonstrukte und interaktive Benutzerschnittstelle - TUM

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

120 KAPITEL 6: VERBESSERUNGSMÖGLICHKEITENAbfrage, die keine Kopie, sondern die Original-Komponente in ein Kanalbündel einsetzt, ist bereitsmit dem aktuellen Sprachumfang von <strong>ODL</strong> möglich). Die aktuelle Implementierung der Dialogflusskontrolleim <strong>ODL</strong>-Query-Subsystem erlaubt die Rückkehr zu früheren Eingabedialogen, speichertallerdings die Eingaben aus späteren Eingabedialogen nicht. Wenn der Benutzer also vom drittenTeilschritt zum ersten zurückkehrt, gehen die im dritten Teilschritt getroffenen Portzuorndnungenverloren, sodass er alle Eingaben wiederholen müsste, was nicht besonders benutzerfre<strong>und</strong>lich ist.Um hier Abhilfe zu schaffen, muss die Dialogflusskontrolle des <strong>ODL</strong>-Query-Subsystems erweitertwerden. Dafür gibt es zwei Möglichkeit, die sich in Implementierungsaufwand <strong>und</strong> der resultierendenFlexibilität unterscheiden. Wir wollen sie im folgenden besprechen <strong>und</strong> ihre Vorteile <strong>und</strong> Nachteileerörtern.1) Die einfachere Möglichkeit ist eine Erweiterung des bestehenden Systems, indem jeder context-Quantor sich den zuletzt eingegebenen Wert merkt <strong>und</strong>, falls ein Rückwärtsschritt vorgenommenwurde, bei der Rückkehr zu ihm diesen Wert anzeigt. Dabei muss allerdings eine Analyse vorgenommenwerden, ob der gespeicherte Eingabewert in der jetzigen Situation überhaupt möglichwäre. Betrachten wir die Beispielabfragecontext c:Component. context p:element( c.Ports ). trueFalls bei dieser Abfrage der Benutzer vom zweiten context-Quantor zum ersten zurückkehrt,dort eine andere Komponente auswählt <strong>und</strong> dann wieder zum zweiten context-Quantor übergeht,so wird der früher ausgewählte Port nicht mehr gültig sein, weil er zur früher ausgewähltenKomponente, nicht aber zur aktuell ausgewählten Komponente gehört <strong>und</strong> deshalb jetzt gar nichtausgewählt werden könnte. In einer solchen Situation muss der Eingabedialog für den zweitencontext-Quantor mit leerer Auswahl starten.Solche Gültigkeitsprüfungen müssen zwar bei jedem Wiedereintritt in einen zuvor verlassenenEingabedialog vorgenommen werden, stellen aber keine große Schwierigkeit dar, denn es ist bekannt,zu welchem Typ ein einzugebender Wert gehört (es ist gerade der Typ der abgefragtenVariablen), <strong>und</strong> es ist ganz einfach möglich, für einen abgespeicherten Wert zu überprüfen, ob erzu einem gegebenen Typ gehört: je nach Datentyp muss man über alle Typwerte iterieren <strong>und</strong> siemit dem abgespeicherten Wert vergleichen oder es muss, falls es sich um einen <strong>ODL</strong>-Gr<strong>und</strong>typhandelt (z.B. Boolean oder Integer), gar keine Überprüfung vorgenommen werden.2) Eine wesentlich aufwändiger zu implementierende <strong>und</strong> gleichzeitig viel flexiblere Lösung würdedas Konzept von Kontrollklassen zur Auswertung von <strong>ODL</strong>-Abfragen darstellen. Im Rahmendes bereits angesprochenen Systementwicklungsprojekts wurde eine auf den konkreten Anwendungsfallspezialisierte Kontrollklasse entwickelt, die für den dreischrittigen Vorgang der Kanalbündelauftrennungdie Navigation zwischen den Eingabedialogen für die einzelnen Teilschritteerlaubte, bei der sowohl Rückwärtsschritte mit Beibehaltung von getätigten Eingaben als auchVorwärtsschritte möglich waren ([Tracht], S.40-47). Bei einem Vorwärtsschritt wurden die abgespeichertenEingaben hinsichtlich ihrer Kompatibilität mit den neuen Eingaben aus vorherigenTeilschritten überprüft <strong>und</strong> ungültig gewordene Teile der abgespeicherten Eingaben gelöscht. Für<strong>ODL</strong>-Abfragen gestaltet sich die Situation komplizierter, weil hier beliebige Abläufe von Benutzereingabenmöglich sein sollen – eine ähnlich flexible Navigation ist dementsprechend schwierigerzu implementieren.In der aktuellen Version wird der Durchlauf durch einen <strong>ODL</strong>-Auswertungsbaum über Aufrufevon Methoden implementiert: der Auswertungsbaum ist, in gewissem Sinne, im Java-Callstackversteckt <strong>und</strong> für den expliziten Zugriff nicht ohne Weiteres zugänglich: die einzige Zugriffsmöglichkeitstellen Exceptions zum Abbruch einer momentan ausgeführten Methode dar – dieser Mechanismuswird in der aktuellen Implementierung für die Rückkehr zu vorherigen Eingabedialogenbenutzt.Um die Steuerung des Dialogflusses durch Kontrollklassen zu ermöglichen, müsste die Steuerung

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!