Die grafische Expertensystemschale
EMA-XPS

Benutzerhandbuch

Inhaltsverzeichnis

1. Danksagungen
2. Hauptmenü und Systemdialoge
3. Debugger PAD
4. Erklärungskomponente
5. Tracer 6. Editoren
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

1. Danksagungen

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

2. Hauptmenü und Systemdialoge

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.

a)
 b)
 c)
 d)

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.

3. Debugger PAD

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

4. Erklärungskomponente

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.

5. Tracer

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

6. Editoren

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.

6.1 Der Taskmechanismus von EMA-XPS

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.

(deftask task-name (arg1 arg2 &key key) "Optionaler Kommentar"
(anweisung-1 ...)
(anweisung-2 ...)
;; ...
(anweisung-n ...)
;; Das Ergebnis der anweisung-n ist zugleich
;; der Rückgabewert der Task
)
;; ein möglicher Taskaufruf: (setf resultat
(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.

6.2 Editor für die Regelverarbeitung

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).

6.3 Editoren zur objektorientierten Programmierung

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

6.4 Editoren für den Constraint-Mechanismus

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

6.5 Der Prolog-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.

6.6 Editor für sonstige Wissenskonstrukte

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.

7. Hilfewerkzeug

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

8. Die Endbenutzerschnittstelle und ihre Dialoge

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

    9. Die Online-Hilfeseiten von EMA-XPS 

       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