Die grafische Expertensystemschale
EMA-XPS
Benutzerhandbuch
Inhaltsverzeichnis
1. Danksagungen
2. Hauptmenü und Systemdialoge
3. Debugger PAD
4. Erklärungskomponente
5. Tracer
6.1 Der Taskmechanismus von EMA-XPS
6.2 Editor für die Regelverarbeitung
6.3 Editoren zur objektorientierten
Programmierung
6.4 Editoren für den
Constraint-Mechanismus
6.5 Der Prolog-Editor
6.6 Der Editor für sonstige
Wissenskonstrukte
7. Hilfewerkzeug
8. Die Endbenutzerschnittstelle und ihre
Dialoge
9. Die Online-Hilfeseiten von EMA-XPS
Ich möchte meine Danksagungen zeitlich ordnen:
Zunächst möchte ich meinem Professor Joachim
Holtz für die uneingeschränkte Unterstützung
während der gesamten Projektlaufzeit sowie die
Bereithaltung der jeweils aktuellsten Rechner-Hardware
(ApolloDomainOS, SunOS, Linux) danken.
Eingedenk der ersten Gehversuche in der X11/Motif®
Programmierung sowie dem Aufsetzen unterschiedlicher
Arten der UNIX® Interprozeßkommunikation möchte
ich Andreas Hennecke für seine Anteile am Quell-
text der X-Version des EMA-Labor Grafikstandards GRF3
danken. Damit wurde der Kennlinieneditor KLED reali-
siert, eine maus-orientierte grafische Anwendung zur
interaktiven Manipulation von Graphen. KLED ist Be-
standteil der EMA-XPS Distribution. In diesem Zu-
sammenhang ist das Konzept einer Zwei-Prozeß-Lösung
(einer arbeitet ereignisorientiert, der andere
sequentiell) entstanden. Die Inferenzmaschine von
Babylon2 (entwickelt von der GMD) unterstützt nur
reine Textein- und -ausgaben. Die Quelltexte sind aber
kostenfrei verfügbar. Um nicht "das Rad zweimal zu
erfinden" sollte nur die Grafikfähigkeit dadurch
ergänzt werden, daß der Babylon2-Prozeß von
einem Grafikmanager begleitet wird.
Joachim Kromberg trug seinen Anteil bei der Erprobung
und Implementierung einer ersten Version dieses
Lösungsansatzes in Form des Kernstücks von EMA-XPS
v1 bei. dafür sei ihm auch an dieser Stelle Dank
ausgesprochen.
Weiterhin muß die Arbeit von Klaus Senf besonders ge-
würdigt werden. Er schrieb den Rest der grafischen
Oberfläche von EMA-XPS v1. So konnten die großen
Chancen dieses Ansatzes verdeutlicht werden.
Obwohl es vielfach unerfreulich aufgenommen wurde,
daß "babylon 3.1-beta" von VW-GEDAS vom Markt genom-
men worden war, ergaben sich daraus stark wachsende
Hoffnungen in dieses Vorhaben.
Die Idee, EMA-XPS so anzupassen, daß es ein Ersatz
für babylon3 werden kann, setzten größere Sta-
bilität und Flexibilität der Lowlevel-Interprozeß-
Kommunikation voraus.
Zu diesem Zweck wurde die Nummer der physikalischen
Kanäle auf 1 reduziert. Bis zu 1000 virtuelle Kanäle
können mittlerweile darüber gemultiplext werden.
Die wichtigste Voraussetzung für die Herausforderung,
ein Ersatz für babylon3 zu werden, war die Schaffung
einer äquivalenten Endbenutzerschnittstelle. Diese
ist von Michael Block mit großer Liebe ins Detail
umgesetzt worden.
Für die Untersuchung der Wissenseingabesprachen von
von Babylon2 und babylon3, ihre Gemeinsamkeiten und
Unterschiede, möchte ich Jan Legenhausen danken.
Er stellte die Prinzipien für die Übersetzung von
babylon3 Konstrukten in Babylon2/EMA-XPS entsprechende
zusammen. Daraus entwickelte er den Übersetzer "3to2",
der mittlerweile von einem in EMA-XPS v2.1 integrierten
zur Ladezeit aktivierten Einlesefilter ersetzt wurde.
Nicht zum Schluß sei mein Dank gerichtet an Karsten
Vossberg und Stephan Peters, die die Wissenseditoren
von EMA-XPS v1 angepaßt und optimiert haben.
Dies schließt grundsätzliche Änderungen der
Quelltexte ein, um die komplette Mehrsprachunter-
stützung von EMA-XPS v2.1 mittels X-Resourcen hand-
haben zu können. Dies versetzt sogar Benutzer
reiner Binärdistributionen in die Lage, die Unter-
stützung weiterer Sprachen zu realisieren.
Last but not least möchte ich Frans Ceelen erwähnen,
der den Stand der babylon3 Emulation in Form einer
Online-Dokumentation ergänzte. Diese Hilfe zur Syntax
steht bei der Wissenseingabe innerhalb der Textfelder
der Wissenseditoren zur Verfügung.
Hans Groschwitz
EMA-XPS v2.1 unterstützt die grafische Ausgabe auf Farb-
, Graustufen und Monochromdisplays entsprechend der
Möglichkeiten des Motif-Widgetsets. Durch Setzen einer
Option kann aber auch eine ausschließlich schwarz-weiße
Darstellung erzwungen werden. Da alle Farbwerte über
Xresourcen gesetzt werden und nicht festgeschrieben worden
sind, kann auf diesem Wege ohne Rekompilation der C-
Quelltexte eine individuelle Farbwahl nachgetragen werden.
Ebenfalls wird der Native Language Support (NLS)
unterstützt. Derzeit sind die Sprachen Deutsch und Englisch
verfügbar. Dies geschieht unterRückgriff auf die
Mehrsprachenunterstützung der X Windows, die zu diesem
Zweck den Wert der Environmentvariablen LANG auszuwerten.
EMA-XPS verzichtet komplett auf das Hardcoden von
Textausgaben. Dementsprechend werden bei der grafischen
Initialisierung die Environmentvariablen HOME, XAPPLRESDIR
und LANG genutzt, um den jeweils gültigen Standort der
Xresourcen zu bestimmen. Das Hilfewerkzeug nutzt ebenfalls
diese Variablen, um die benötigte Version der
Hilfetextdatei zu lokalisieren. Der NLS wirkt sich damit
ausschließlich auf die Fensternamen, Menüs und
Knopfaufschriften von EMA-XPS aus.
Die Ausgaben des verwendeten LISP-Interpreters,
insbesondere bei Fehlermeldungen, sind davon nicht
betroffen. Zwar unterstützt CLISP die Sprachen Deutsch,
Englisch und Französisch. Da der NLS aber nicht in CLtL1
oder CLtL2 festgeschrieben ist, können derartige
Fähigkeiten nicht vorausgesetzt werden.
Bild U1: Eröffnungsdialog mit Rollbalken
Die Schale Babylon-2 unterstützt die Sprachen Deutsch
und Englisch. Die Erweiterungen, die mit EMA-XPS
eingebracht worden sind, sind so gehalten, daß der Babylon-
2-Kern - außer bei den Trace-Ausgaben und derzeit noch bei
den Erklärungen - keine Textausgaben mehr erzeugt. Ein
Wechsel der Ausgabesprache von der Voreinstellung Englisch
nach Deutsch kann bei Babylon-2 durch Setzen der globalen
Variablen *language* erfolgen.
(setf *language* 'deutsch)
Dafür eignet sich ein Eintrag in der Datei ema-xps-
init.lisp, die EMA-XPS während der Bootphase lädt.
Dem Benutzer präsentiert sich EMA-XPS zur Bootzeit, wie
in Bild U1 dargestellt. In dem xterm, aus dem heraus die
Schale gestartet wird, werden die einzelnen Phasen
visualisiert. Die Laufzeitversion von EMA-XPS bietet keine
Wissenseditoren an. Die Bootzeit ist dementsprechend
kürzer, weil die Gestalt der einzelnen Editoren nicht dem
Xserver bekanntgegeben werden muß. Im
Eröffnungsdialogfenster wird ein Rollbalken bewegt.
Sobald die Prozeßsynchronisierung erfolgt ist,
erscheint das Hauptfenster der Schale (Bild U2). In der
Entwickler- oder Vollversion stellt dieses zusätzlich zum
Umfang der Laufzeitversion ein Menü "Bearbeiten" zur
Verfügung, sowie die Möglichkeit, Wissensbasen
abzuspeichern und zu tracen.
Bild U2: Das Hauptfenster des Grafikservers
Unter EMA-XPS können maximal 9 Wissensbasen
gleichzeitig in der LISP-Welt vorhanden sein. Deren Namen
sind im Datei-Menü (Bild U3a) des Hauptfensters oberhalb
des Beenden-Eintrags aufgelistet. Es kann immer nur eine
Wissensbasis aktuell sein, die im Menü mit einem `>`
markiert ist. Auf der LISP-Seite werden entsprechende
Datenstrukturen gepflegt, die den Namen der Wissensbasis,
den damit verknüpften Dateinamen sowie eine Infomation
beinhalten, ob die in der LISP-Welt vorhandene Wissensbasis
gegenüber der aus der Datei geladenen Version verändert
worden ist. Über den privilegierten
Interprozeßkommunikationskanal 008 wird die C-Seite von
jeder Änderung dieser Datenstrukturen unterrichtet. C
pflegt eine exakte Kopie dieser Datenbestände.
Nur in der Vollversion der Schale steht ein Bearbeiten-
Menü (Bild U3b) zur Verfügung, von dem aus die grafischen
Wissenseditoren sichtbar gemacht werden können. Vom Sitzung-
Menü (Bild U3c) aus kann eine Sitzung der aktuellen
Wissensbasis gestartet werden. Weiterhin können der
Debugger PAD und das Erklärungsfenster und in der
Vollversion auch der Tracer aktiviert werden. Bild U3d
zeigt das Hilfe-Menü mit unterschiedlichen Themen. Diese
Einträge bewirken, daß das Hilfewerkzeug mit der jeweiligen
Hilfeseite aufgeschlagen aktiviert wird.
Bild U3: Die Pulldown-Menüs des Hauptfensters
Bei Anwahl von Einträgen in den Menüs werden mit
Ausnahme der Einträge des Datei-Menüs eigenständige X-
Applikationen aktiviert. Dazu werden keine eigenständigen
UNIX-Prozesse gestartet. Diese Eigenständigkeit betrifft
nur X und wird beim Erstellen von Xresourcen deutlich.
Die Aktionen, die vom Datei-Menü ausgelöst werden
können, aktivieren die Popupdialoge des Systems. Einige
dieser Dialoge können ausschließlich von der C-Seite
ausgelöst werden. Zum Laden (Bild U4a) oder Speichern
(Bild U4b) einer Wissensbasis steigern Dateiauswahldialoge
die Benutzerfreundlichkeit. Der LISP-Seite genügt aber die
Information "Lade die Datei XYZ". Im Fall, daß der Benutzer
nicht laden will und abbricht, müßten Sonderbehandlungen
LISP-seitig realisiert sein.
LISP hält pro Wissensbasis auch den kompletten Pfad der
zugehörigen Datei fest, um ihn beim Speichern zur Verfügung
zu haben. Da diese Kontrolldaten bereits für die Verwaltung
der Editoren ständig im Grafikserverprozeß gespiegelt
werden, genügt es, die komplette grafische Verwaltung C-
seitig abzuwickeln.
Beim Speichern einer Wissensbasis kann gewählt werden,
ob sie als zur Ladezeit zu interpretieren - und damit im
Klartext - abgelegt werden soll oder in einem binären, vom
LISP-Compiler vorbehandelten Format. Bild U4b zeigt auch
den untergeordneten Popupdialog zur Voreinstellung dieser
Präferenz.
a)
|
b)
|
c)
|
Bild U4: Vom Grafikserver initiierte Systemdialoge
a) für das Laden einer Wissensbasis
b) zum Speichern unter einem anderen Namen
c) Hinweis auf nicht gesicherte Änderungen
EMA-XPS v2.1 setzt für alle Wissensbasen die Verwendung
der leistungsfähigsten Ausprägungen der einzelnen
Wissensinterpreter von Babylon-2 voraus. Die einzige
Ausnahme ist der Freitextinterpreter. Auf seine Verwendung
wird verzichtet. Andererseits ist zur leichteren
Realisierung von Callbacks der Endbenutzerschnittstelle ein
Taskmechanismus eingeführt worden. Dieser ersetzt den
Instruktionen-Bereich von Babylon-2. Damit ändert sich das
Dateiformat von Wissensbasen für EMA-XPS v2.1 gegenüber dem
von Babylon-2. Zur Unterscheidung bevorzugt EMA-XPS für
eigene Wissensbasen die Dateinamenserweiterung `*.kb'.
|
Wissensbasen, die unter Babylon-2 erstellt worden sind,
können von EMA-XPS nicht korrekt eingelesen werden.
Vorbehandlungen dieser Dateien sind in geringem Umfang
notwendig.
|
Schließlich kann gewünscht werden, eine Wissensbasis zu
schließen, also aus der LISP-Welt zu entfernen, oder EMA-
XPS komplett zu beenden. Falls mittels der Editoren
Änderungen vorgenommen wurden, die noch nicht in die
zugeordnete Wissensbasisdatei übertragen worden sind, kann
der Grafikserver direkt eine Warnung (Bild U4c) auslösen.
a)
|
b)
|
Bild U5: Von der LISP-Welt initiierte Systemdialoge
a) Eingabe des Namens einer neuen Wissensbasis
b) Statistik der Wissensinhalte der aktuellen Wissensbasis
Bei anderen Systemdialogen erschien eine LISP-seitige
Kontrolle sinnvoller. Beispielsweise könnten für eine zu
speichernde Datei keine Schreibrechte existieren. Dies wird
der LISP-Prozeß erst beim Versuch, die Datei zu öffnen,
feststellen. Auch für das Erzeugen einer neuen Wissensbasis
reicht eine LISP-seitige Verwaltung (Bild U5a). Das
Anlegen einer neuen Wissensbasis findet zunächst nur in der
LISP-Welt statt. Demgemäß existiert noch kein zugeordneter
Dateiname. Einfaches Speichern versagt dann. Der
Menüeintrag "Speichern unter" ist zu verwenden. Auch die
Beschaffung der notwendigen Daten zur Ausgabe einer
Statistik der aktuellen Wissensbasis fällt unter LISP
leichter als unter C (Bild U5b).
Um bei den LISP-seitig initiierten Dialogen die
Aufrecherhaltung der Mehrsprachlichkeit gewährleisten zu
können, sind die Textstrings in den Xresourcen als
Formatdirektiven der C-Bibliotheksfunktion sprintf
formuliert worden. Der Nachrichtenkanal sendet die zu
ersetzenden Zeichenketten. Sprintf verbindet die während
der Bootphase aus den Xresourcen gewonnenen und gesicherten
Formatdirektiven mit den übertragenen Zeichenketten zu
einem Ausgabestring, der an den zu öffnenden Systemdialog
übergeben wird.
Wenn bei der Evaluierung von LISP-Ausdrücken ein Fehler
auftritt, ruft der Interpreter seinen Debugger auf. Unter
EMA-XPS wird dann der LISP Debugger PAD (Fehlerwerkzeug) im
Fensterstack nach vorne geholt und entikonifiziert. Er ist
ein portables grafisches Frontend für eine Vielzahl
unterschiedlicher textstromorientierter Debugger-Implemen
tierungen. Der Benutzer wird zur Fehlerbehebung LISP-
Kommandos direkt eingeben wollen. Dazu bietet der PAD unten
ein Texteingabefenster. Andere LISP-Eingaben löst der
Benutzer beispielsweise durch Mausaktionen aus. Mit der
Beschränkung auf einen einzigen physikalischen
Datenübertragungskanal ist die Einführung einer
Befehlswarteschlange notwendig geworden. Das mittlere
Textausgabefeld des PADs zeigt den aktuellen Inhalt der
Befehlsqueue an. Die Echos der Eingaben, soweit nicht
unterdrückt, und die Ausgaben der LISP-Welt werden im
obersten Fenster dargestellt.
Bild U6 zeigt den PAD im Anschluß an die Bootphase.
Nach der Synchronisierung beider Prozesse und dem Laden der
benutzerindividuellen Initialisierungsdatei ema-xps-
init.lisp sind über das Hauptmenü zunächst zwei
Wissensbasen geladen worden, die abwechselnd zur aktuellen
Wissensbasis erklärt worden sind. Für beide sind mittels
eines speziellen Systemdialogs (Bild U5b) Statistiken
ihrer Wissensinhalte angezeigt worden.
Mittels des Knopfes "Unterbrechen!" kann ein
Keyboardinterruptsignal (SIGINT) an den LISP-Prozeß gesandt
werden. Dieser wird dann die aktuellen Arbeiten
unterbrechen und den Debugger aufrufen. In diesem Fall
bietet der Debugger an, den unterbrochenen Vorgang
fortzusetzen.
Bild U6: Der LISP Debugger PAD von EMA-XPS v2.1
Die Erklärungskomponente von EMA-XPS nutzt derzeit
ausschließlich das Leistungsangebot von Babylon-2. Dort
werden Erklärungen menügesteuert angefordert. Zu diesem
Zweck bieten der Regel- und der Prologinterpreter Methoden
an, die nach einer interaktiven Auswahl die erläuternden
Texte über den *explain-stream* ausgeben. Eine Analyse der
zur Auswahl stehenden Erklärungstypen ergab wenige
Grundfunktionen, die - ohne die Auswahlmenüs in Anspruch
nehmen zu müssen - direkt aktiviert werden können. Dazu
wären aber die Babylon-2 LISP-Quelltexte zu überarbeiten
gewesen. Um diese nicht ändern zu müssen, wurden die
relevanten Codeanteile in eigene Funktionen übertragen.
Bild U7: Erklärungsfenster
Das Erklärungsfenster (Bild U8) bietet über seine
Menüs Erklärung und Zeigen die Möglichkeit, im Laufe einer
Sitzung mit einem Expertensystem Erklärungen anzufordern.
Dies ist immer dann der Fall, wenn das Expertensystem auf
Benutzerreaktionen wie das Betätigen eines Druckknopfes
wartet, nicht aber, wenn der Benutzer einen Popupdialog
bestätigen soll. Daher können diese Funktionen auch in den
Tasks der Wissensbasis verankert werden.
Das Fenster kann vom Hauptmenü aus sichtbar gemacht
werden. Jede Textausgabe in dieses Fenster öffnet es aber
auch und holt es im Fensterstack nach oben.
Die Meta-, Regel-, Prolog- und Constraintinterpreter
von Babylon-2 bieten in der leistungsstärksten Ausführung
jeweils die Möglichkeit, TraceAusgaben an- oder
auszuschalten. Jeder Interpreter schreibt diese Texte in
geeignete logische Ströme. Sie werden unter EMA-XPS v2.1 in
ein einzelnes eigens dafür vorgesehenes Ausgabefenster
geschrieben. Den Textausgaben werden je Interpreter
geeignete Kürzel vorangestellt. EMA-XPS stellt diesen
Ausgaben noch den Namen der aktuellen Wissensbasis voran
(Bild U8).
Unter EMA-XPS v2.1 ist zur Erleichterung einer
ereignisorientierten Sitzungsgestaltung ein weiterer
Interpreter geschaffen worden. Auch dieser Task-Interpreter
bietet Trace-Möglichkeiten an.
Oberhalb des Textausgabefeldes sind Schalter
angebracht, die - für die jeweilige Wissensbasis - den
gewünschten Umfang an Trace darstellen. Mit Hilfe der
Schalter kann dieser Umfang geändert werden.
Bild U8: Tracer
Die textstromorientierte Expertensystemschale Babylon-2
stellt keine definierte Wissensingenieurschnittstelle zur
Verfügung. Die Wissenseingabe erfolgt mittels eines
Texteditors. Dies geschieht unter Einhaltung einer gewissen
Programmierdisziplin durch Untereinanderschreiben von LISP-
Toplevelformen wie (defframe ...), (definstance
...),
(defbehavior ...) und dergleichen. Die einzelnen Interpreter
von Babylon-2 besitzen Methoden, die in ihrer Zuständigkeit
liegenden aktuellen Wissensbestände in einen bereits
geöffneten Datenstrom zu schreiben. Diese sind zur
Speicherung von EMA-XPS Wissensbasen herangezogen worden.
Aus dieser Funktionalität sind die Routinen entwickelt
worden, mit denen die zu bearbeitenden Formen in die
grafischen Editoren geladen werden. Schließlich sind für
die Übernahme der Änderungen in die LISP-Welt geeignete
LISP-Kommandos erstellt werden.
Die Editoren von EMA-XPS v2.1
benötigen daher nur, daß
LISP bei der Anforderung der aktuellen Versionen dieser
Formen und im Moment der Abspeicherung eingabebereit ist.
In der verbleibenden Zeit steht LISP für andere Aufgaben
zur Verfügung.
Sitzungen mit unter Babylon-2 erstellten
Expertensystemen verlaufen textstromorientiert, wie in Bild S4
verdeutlicht. Der Metaprozessor übernimmt die globale
Kontrolle des Sitzungsablaufs. Zu diesem Zweck werden in
der Wissensbasis die notwendigen Anweisungen zum Anstoßen
von Regelwerken und dergleichen in den Block (instructions
...) geschrieben [S2, S3].
Sollen Sitzungen ereignisorientiert ablaufen, wie in
Bild S5 angedeutet, sind unterschiedliche Arten von
Benutzereingaben möglich. Die Endbenutzerschnittstelle von
EMA-XPS v2.1 besteht aus einem Sitzungsfenster, auf dem in
erster Linie mittels frei platzierter Druckknöpfe und
Einträgen in Pulldownmenüs die Aktivierung von LISP-
Kommandos ausgelöst wird. Dazu ist pro grafischem Element
ein Callback registriert. Dies ist ein LISP-Kommando, das
in die Standardeingabe von LISP geschrieben wird. Die
Befehlswarteschlange des Debugger PADs wird damit zur
Eventqueue.
Dies setzt aber voraus, daß die ursprüngliche Babylon-2
Sitzung unterbrochen wird, um LISP-Kommandos einlesen zu
können. Innerhalb des Instruktionenbereichs von Babylon-2
ist die besondere Variable self an die Instanz des
aktuellen Expertensystems gebunden. Nachrichten an die
einzelnen Wissensinterpreter können daher mit ($send self
...) abgesetzt werden. Die Bindung von self wird am Ende
des Instruktionenbereichs aufgehoben. Trotzdem kann eine
Babylon-2 Sitzung danach weitergeführt werden. Unter
Verwendung des Babylon-2 Ausdrucks (send-kb
...) können
diese Interpreter in der gleichen Weise erreicht werden. Da
der LISP-Prozeß interpretativ arbeitet, gehen die aktuellen
Variablenwerte und Systemzustände nicht verloren.
Daher ist es möglich, unter EMA-XPS v2.1 den
Instruktionenbereich gegenüber dem Wissensingenieur für
unzugänglich zu erklären. Für alle Wissensbasen lautet
dieser Block daher gleich. Zunächst werden die
Wissensinterpreter und die Endbenutzerschnittstelle
reinitialisiert. Dann wird festgestellt, ob eine Task mit
dem Namen MAIN existiert. Existiert sie nicht, ist die
Sitzung beendet. Ansonsten geht die weitere Kontrolle der
Sitzung über an diese Eröffnungstask. Mit dem Ende von MAIN
endet der Instruktionenblock. Ereignisorientierte Sitzungen
unter EMA-XPS fangen im allgemeinen jetzt erst an, weil
MAIN zumeist nur die grafische Endbenutzerschnittstelle
sitzungsgerecht initialisiert.
Da bei EMA-XPS der Sitzungsverlauf oft unterbrochen
ist, ist in der Zwischenzeit prinzipiell sogar das
Editieren von Konstrukten der aktuellen Wissensbasis
möglich. Es können aber auch Erklärungen abgefragt werden
und Änderungen im Umfang des Trace vorgenommen werden.
Die Tasks von EMA-XPS werden definiert wie LISP-
Funktionen, nur daß anstelle des Konstruktors defun ein
deftask tritt (Bild U9). Sie werden auch abgearbeitet wie
LISP-Funktionen, nur sind ihre Definitionen nicht global
bekannt. Mit dem Entfernen einer Wissensbasis werden auch
die Taskdefinitionen gelöscht. Eine Interferenz zwischen
unterschiedlichen Definitionen einer Task in
unterschiedlichen Wissensbasen ist ausgeschlossen.
|
(anweisung-1 ...)
(anweisung-2 ...)
;; ...
(anweisung-n ...)
;; Das Ergebnis der anweisung-n ist zugleich
;; der Rückgabewert der Task
)
;; ein möglicher Taskaufruf:
(dotask 'task-name 1 2))
|
Bild U9: Definition und Aufrufform einer Task unter EMA-XPS
Unter Babylon-2 sollte auf die Verwendung von globalen
Variablen, Funktions- und Makrodefinitionen möglichst
verzichtet werden, weil alle in den Symboltabellen der USER-
Package abgelegt werden. Ständig besteht die Gefahr, daß
zwei Wissensbasen, die zur gleichen Zeit in der LISP-Welt
bekannt sind, zwei gleichlautende Konstrukte mit
unterschiedlicher Funktion definiert haben und nutzen
wollen. Dann kommt es zu Inkonsistenzen im Ablauf der
Expertensysteme. Nur die Definition der zuletzt geladenen
Wissensbasis ist verfügbar. Sie gilt aber für beide
Expertensysteme.
Schließlich ist zu bedenken, daß der Aufruf von Tasks
fast genauso schnell geschieht wie der Aufruf von LISP-
Funktionen. Dafür können Tasks auch Trace-Informationen
erzeugen.
Bild U10: Task-Editor
Der Kopfbereich aller Wissenseditoren von EMA-XPS ist
gleich gestaltet. Eine Menüleiste bietet ein Bearbeiten-
und ein Hilfe-Menü, über das Erklärungen zur Bedienung des
jeweiligen Editors abgerufen werden können. Außerdem wird
Hilfe zu einzelnen LISP-Kommandos angeboten. Unter Motif
kann durch Drücken der Funktionstaste F1 oder - falls
vorhanden - der Taste mit der Aufschrift HELP, diese Hilfe
ebenfalls aktiviert werden. Positioniert der
Wissensingenieur in einem Texteingabefeld den Textcursor
innerhalb eines Wortes und drückt F1 oder HELP, wird
versucht, Hilfe zur Syntax dieses LISP-Kommandos
anzubieten.
Unterhalb der Menüleiste ist als erstes ein Knopf
angeordnet, der den Namen der Wissensbasis trägt, deren
Konstrukte bearbeitet werden sollen. Drücken auf den Knopf
läßt einen Auswahldialog erscheinen, in dem die Namen der
aktuell verfügbaren Wissensbasen aufgeführt sind. Die Namen
sind den gespiegelten Kontrolldaten entnommen.
Beim Task-Editor (Bild U10) folgt darunter ein Knopf
mit dem Namen der Task, die bearbeitet werden soll. Bei
Betätigen des Knopfes mit dem Tasknamen wird ein Kommando
abgesetzt, das LISP auffordert, über einen bestimmten
Nachrichtenkanal die bekannten Tasknamen an die C-Seite zu
senden. Der C-seitig registrierte Handler baut einen
Auswahldialog auf. Nach erfolgter Auswahl wird LISP
angewiesen, die Definition der gewünschten Task über einen
weiteren Nachrichtenkanal zu übertragen. Diese wird in den
unten anschließenden Textfeldern für die Argumentzeile, den
optionalen Kommentar und den Taskkörper dargestellt.
Bild U11: Regeleditor mit bearbeiteter Regel sowie das Datei-Menü des
Hauptfensters mit der grafischen Aufbereitung der Kontrolldaten
über die geladenen Wissensbasen
Die bereits beschriebene Spiegelung der
Kontrolldatenbestände über geladene Wissensbasen ist in
erster Linie zur Sicherung aktueller Eingaben bei der
Wissensprogrammierung eingeführt worden. Jeder Editor
reagiert auf die Bearbeitung von Wissenskonstrukten, in dem
er die Grafik eines Ausrufungszeichens im Editorfenster
rechts neben dem Namen der betroffenen Wissensbasis anzeigt
(Bild U11). Gleichzeitig wird im Dateimenü des
Hauptfensters von EMA-XPS v2.1 hinter dem Namen der
Wissensbasis ein "!!" vermerkt.
Bild U12: Dialog zur Umsortierung von Regeln innerhalb einer Regelmenge
Jeder Editor bietet die Möglichkeit, die Änderungen zu
speichern. Dann werden diese in die LISP-Welt übertragen.
Die Ausrufungszeichen verschwinden und im Hauptfenster wird
ein "#" dargestellt. Durch Speichern einer Wissensbasis in
eine Datei wird dieses Zeichen wieder entfernt. Beim
Schießen von Wissensbasen, die C- oder LISP-seitig
verändert sind, aber nicht gesichert, wird eine
Sicherheitsabfrage durchgeführt.
Der Regeleditor ist prinzipiell ähnlich dem Taskeditor
aufgebaut. Zunächst ist eine Regelmenge auszuwählen. Daraus
kann eine Regel selektiert und zur Anzeige gebracht werden.
Bei der Eingabe von Regeldefinitionen sind die
Strategien einer Schale zur Konfliktauflösung zu beachten.
Babylon-2 - und damit auch EMA-XPS - verwendet die
einfachste mögliche. Wenn zwei Regeln mit gleichem
Bedingungsteil und unterschiedlichen Aktionsteilen in einem
Regelwerk existieren, wird Babylon-2 immer der zuerst
gefundenen zutreffenden Regel den Vorzug geben. Die Regeln
sind in Regelmengen zufsammengefaßt, die wiederum als
Listen organisiert sind, welche die Regelkörper enthalten.
Die Position eines Regelkörpers in der Regelmengenliste
entscheidet also über die Priorisierung der Regel.
Das Bearbeiten-Menü des Editors bietet daher einen
Dialog zur Umsortierung der Regeln innerhalb einer
Regelmenge (Bild U12).
Babylon-2 ist selbst objektorientiert realisiert
worden. Diese Mittel stehen auch für die Wissenseinbringung
zur Verfügung. Ein Frame-Editor (Bild U13), ein Editor zur
Erstellung statischer Instanzen (Bild U14), also von
Instanzen, die mit einer pro Wissensbasis gültigen global
ansprechbaren Variablen verknüpft sind, und ein Editor zum
Erstellen von Behaviors (Bild U15) unterstützen den
Wissensingenieur bei der Eingabe dieser Formen.
Bild U13: Frame-Editor
Bild U14: Instanz-Editor
Bild U15: Behavior-Editor
Der CONSAT-Interpreter von Babylon-2 unterscheidet
zwischen primitiven und Compound-Constraints. Die
Primitiven beschreiben die Zwänge zwischen ihren
Eingangsgrößen beispielsweise über mathematische
Zusammenhänge. Compound-Constraints werden zur Festlegung
von Constraint-Netzen verwendet. Die Zwänge zwischen ihren
Eingangsgrößen werden mittels primitiver oder anderer
Compound-Constraints festgelegt. Schließlich binden
Restriktionen die Eingangsgrößen der Constraints an die
Slots von statischen Instanzen. Die drei hierfür
spezialisierten Editoren sind in den Bildern U16 bis U18
dargestellt.
Bild U16: Editor für primitive Constraints
Bild U17: Editor für Constraint-Netze
Bild U18: Restriktionen-Editor
Damit Babylon-2 auch in der Lage ist, Horn-Klauseln zu
verarbeiten, ist mit den Mitteln der Programmiersprache
LISP ein Prologinterpreter realisiert worden. Die von ihm
bearbeiteten Klauseln werden in Klauselmengen
zusammengefaßt wie Regeln in Regelmengen. Ebenso ist die
Reihenfolge, also die Anordnung der Klauseln innerhalb der
Klauselmenge von Bedeutung.
Im Gegensatz zu den anderen Wissenskonstrukten werden
Klauselmengen nicht gelöscht, wenn die Wissensbasis, mit
der sie verknüpft sind, entfernt wird. Klauselmengen
unterliegen einer eigenen Verwaltung. Alle Klauselmengen,
die in die LISP-Welt geladen werden, ob innerhalb einer
Wissensbasis oder als eigene Dateien, werden in einer Liste
gespeichert, die mit der globalen Variable *axioms*
verknüpft ist. Theoretisch könnten Klauselmengen also
editiert werden, obwohl keine Wissensbasis in der LISP-Welt
vorhanden ist. Praktisch geht dies trotzdem nicht, da die
Prologinterpreter nur im Zusammenhang mit Wissensbasen
existieren.
Bild U19: Prolog-Editor mit Zuordnungsdialog für Klauselmengen
Für jede Wissensbasis existiert eine fest zugewiesene
Klauselmenge. Weitere Klauselmengen von *axioms* können der
Wissensbasis quasi als Bibliotheken zur Verfügung gestellt
werden. Bei der Suche nach treffenden Klauseln wird
zunächst in der festen Menge gesucht, danach in den freien
Mengen, den Bibliotheken. Dabei ist die Reihenfolge der
Zuordnung entscheident. Der Zuordnungsdialog des
Prologeditors (Bild U19) ist dafür zuständig.
Beim Speichern einer EMA-XPS Wissensbasis werden per
Konvention alle mit einer Wissensbasis verknüpften
Klauselmengen in die Datei übernommen, weil nicht
garantiert werden kann, daß bei der nächsten Sitzung die
Bibliotheken noch existieren und die alten Inhalte
aufweisen.
Stattdessen wird beim Einladen einer Wissensbasis
geprüft, ob Klauselmengen mit dem gleichen Namen bereits
existieren. Wenn dies der Fall ist, wird geprüft, ob sie
inhaltlich gleich sind. Ist dies nicht der Fall, wird der
Benutzer gefragt, ob er die alte Version mit der neuen
überschreiben will oder nicht.
Neben den gebräuchlichen Wissensrepräsentationsformen
von Babylon-2, für die individuell angepaßte Editoren
existieren, gibt es Konstrukte, die nur selten benötigt
werden. Ein Beispiel sind die Relation-Behaviors [S2, S3].
Um diese trotzdem grafisch eingeben zu können, bietet EMA-
XPS diesen Editor an (Bild U20). Pro Wissensbasis
existiert genau ein Block für sonstige Konstrukte.
Bild U20: Editor für sonstige Konstrukte
Um EMA-XPS nicht zu verwirren, sollten
Regeldefinitionen, sowie die anderen Formen, für die eigene
Editoren bereitstehen, nicht in diesem Block erscheinen.
Dies könnte zu Inkonsistenzen führen.
Hiermit lassen sich auch Funktionen und Makros, sowie
globale Variablen definieren. Die Gefahr eines Überladens,
wie bereits in Kapitel 4.8.1 zu den Tasks beschrieben, ist
dabei aber gegeben. Auf diese Mittel sollte daher nach
Möglichkeit verzichtet werden.
Nicht nur die Wissenseditoren besitzen eine schnelle
Anbindung an das Hilfesystem von EMA-XPS durch Betätigen
der F1- oder HELP-Taste, wie in Kapitel 4.8.1 beschrieben.
Auch das Hauptfenster, der Debugger PAD, der Tracer und das
Erklärungsfenster bieten diese Funktionalität.
Die Hilfe ist auf zwei Arten organisiert. Der Hilfetext
ist im Buchstil seitenweise thematisch angeordnet. Mit den
Knöpfen im Hilfewerkzeug (Bild U21) unten rechts kann vor-
und zurückgeblättert werden. Das Feld mit der Seitennummer
kann beschrieben werden, um eine bestimmte Seite direkt
anzuspringen. Mittels eines Browsers, in dem die
Überschriften der behandelten Themen beziehungsweise die
Namen der LISP-Kommandos aufgeführt sind, kann alphabetisch
gesucht werden.
Bild U21: Hilfewerkzeug mit Browser
Zur Generierung leistungsfähiger grafischer
Endbenutzerschnittstellen stehen dem Wisensingenieur ein
Hauptsitzungsfenster, das den gesamten physikalischen
Bildschirm ausfüllt, und 6 verschiedene Popupdialoge zur
Verfügung.
Die Dialoge sind in ihrem Leistungsumfang den LISP-
seitig initiierten Systemdialogen nachempfunden. Die
Dialogtexte werden von der Wissensbasis festgelegt.
Folgende Ausprägungen lassen sich unterscheiden:
ein Informationsdialog,
ein Entscheidungsdialog mit zwei Bestätigungsknöpfen,
ein Entscheidungsdialog mit drei Bestätigungsknöpfen,
ein Promptdialog mit einem einzeiligen Texteingabefeld,
eine 1-aus-N Auswahl, sowie
eine mehrere-aus-N Auswahl aus einer Liste von Möglichkeiten.
Das Sitzungshauptfenster wird automatisch angelegt,
sobald LISP die Aufforderung sendet, ein erstes grafisches
Element zu erzeugen. Mit dem speziellen Befehl ui-stop-session
werden alle existierenden grafischen Elemente - als
letztes der Sitzungsbildschirm - explizit zerstört.
Der Hauptbildschirm bietet die Möglichkeit, daß neben den
immer verfügbaren Menüs Sitzung und Hilfe weitere Menüs mit
geeigneten Menüeinträgen definiert werden.
Es können Pushbuttons und Labels
mit Textaufschriften
oder Bildern frei auf dem Sitzungsfenster platziert werden.
Auch Plazierungen an Orten, die die Auflösung des Displays
überschreiten, sind erlaubt. Dann erscheinen Rollbalken, um
den sichtbaren Fensterausschnitt zu verändern.
Weiterhin können senkrechte und waagrechte Linien
(Separatoren) plaziert werden.
Schließlich besteht die Möglichkeit, einzeilige
Texteingabefelder und mehrzeilige, rollbare
Textausgaben zu
positionieren.
Die Farb- und Schriftartfestlegungen können in der
Wissensbasis festgelegt sein (hardcoding) oder sich aus der
Auswertung von Xresourcen ergeben. Die Xresourcen werden
allerdings nur einmal beim Start von EMA-XPS in die
applikationseigene Resourcedatenbank übernommen.
Nachträgliche Änderungen zeigen daher erst nach einem
Neustart von EMA-XPS Wirkung. Die Option von EMA-XPS, eine
schwarz-weiße Darstellung zu erzwingen, kommt hier nicht
zum Tragen. Falls gewünscht, ist eine
Mehrsprachenunterstützung explizit in der Wissensbasis zu
realisieren. Nur die Namen der Fenster und die Farben und
Schriftarten der Dialoge werden über die Xresourcen von EMA-
XPS sprachabhängig bestimmt.
Als Positionierungshilfe bei der Entwicklung der
Sitzungsoberfläche kann ein Raster in den Hintergrund des
Hauptbildschirms eingeblendet werden. Zur Sitzungszeit
können eine Vielzahl der Eigenschaften dieser grafischen
Elemente geändert werden. Tabelle U1 gibt darüber
Aufschluß.
| |
Druck- knopf mit Be- schrift. |
Feld mit Be- schrift. |
Druck- knopf mit Grafik |
Feld mit Grafik |
Trenn- linie |
Ausgabe- Text- fenster |
Eingabe- Textfeld |
Menü |
Menü- eintrag |
| ui-set/get- geometry |
O |
O |
O |
O |
O |
O |
O |
- |
- |
| ui-set/get- foreground |
X |
X |
X |
X |
X |
X |
X |
- |
- |
| ui-set/get- background |
X |
X |
X |
X |
- |
X |
X |
- |
- |
| ui-set/get- font |
X |
X |
- |
- |
- |
X |
X |
- |
- |
| ui-set/get- bitmap |
- |
- |
O |
O |
- |
- |
- |
- |
- |
| ui-set/get- alignment |
X |
X |
- |
- |
- |
- |
- |
- |
- |
| ui-set/get- text |
X |
X |
- |
- |
- |
O |
- |
X |
X |
ui-add-
text |
- |
- |
- |
- |
- |
O |
- |
- |
- |
| ui-set/get- mnemonic |
- |
- |
- |
- |
- |
- |
- |
X |
X |
| ui-set/get- callback |
O |
- |
O |
- |
- |
- |
- |
- |
O |
| ui-set/get- visibility |
O |
O |
O |
O |
O |
O |
O |
O |
O |
| ui-set/get- sensitivity |
O |
- |
O |
- |
- |
- |
O |
O |
O |
(O) Oberflächenelement ist ansprechbar
(X) Oberflächenelement ist zusätzlich aus
Resource-Datei ansprechbar
Tabelle U1: Resourcen der Grundelemente der
Endbenutzerschnittstelle
Um die Bearbeitung der Endbenutzerschnittstelle während
einer laufenden Sitzung zu beschleunigen, sind Teile des
Protokolls zwischen Expertensystem und Grafikserver
asynchron voreingestellt. Beispielsweise ergänzt
ui-add-text den Text in einem mehrzeiligen Ausgabefeld. Bei
synchronem Protokoll wird nach jedem Aufruf der Erfolg der
Operation zurückgegeben. Es könnte der Versuch unternommen
worden sein, in ein nicht existentes Feld auszugeben. Im
allgemeinen ist diese ständige Überprüfung unnötig. Sie
kostet zusätzliche Zeit, weil LISP in jedem Fall auf den
Rückerhalt der Bestätigung des Grafikservers wartet, bevor
der Interpreter den nächsten Befehl bearbeitet. Pro
Grafikanweisung ist dementsprechend die doppelte
Protokollaufzeit abzuwarten. Bei asynchroner Übertragung
ist - außer der zeitlichen Verschiebung durch die
Protokollaufzeit - nur gelegentlich auf die Bereitschaft
des Ausgabestroms zur Annahme von Zeichen zu warten. Dies
kann auch bei synchroner Übertragung auftreten, dort sogar
zweimal pro Grafikanweisung.
Zum Beleg der Leistungsfähigkeit der grafischen
Endbenutzerschnittstelle von EMA-XPS zeigt Bild U22 einen
Schnappschuß aus einer Sitzung mit dem Expertensystem
DANTEX unter babylon-3. Bild U23 zeigt die gleiche
Aufnahme bei Betrieb der Wissensbasis unter EMA-XPS.
Bild U22: Ausschnitt aus einer Sitzung mit dem
Expertensystem DANTEX unter der Schale babylon-3
Bild U23: Ausschnitt aus einer Sitzung mit dem
Expertensystem DANTEX unter der Schale EMA-XPS v2.1
HAUPTMENÜ
SITZUNGSFENSTER
FEHLERWERKZEUG
ERKLÄRUNGSFENSTER
TRACER
EDITOREN
FRAME-EDITOR
INSTANZ-EDITOR
BEHAVIOR-EDITOR
REGEL-EDITOR
PROLOG-EDITOR
CONSTRAINT-EDITOR
CONSTRAINTNETZ-EDITOR
RESTRIKTIONEN-EDITOR
TASK-EDITOR
SONSTIGES-EDITOR
Zurück zum Inhaltsverzeichnis
