Entwicklungsumgebungen für Expertensysteme: Vergleichende Darstellung ausgewählter Systeme [Reprint 2019 ed.] 9783110857573, 9783110112948

Table of contents :
Inhaltsverzeichnis
1. Einleitung
2. Einführung in Expertensysteme
3. Aspekte der Entwicklung
4. Bewertungskriterien für Entwicklungssysteme
5. Darstellung ausgewählter Expertensystem- Entwicklungsumgebungen
6. Bewertender Vergleich der Systeme
7. Ausblick
Literaturverzeichnis
Stichwortverzeichnis

Citation preview

Studien zur Wirtschaftsinformatik 1 Herausgegeben von Karl Kurbel, Uwe Pape und Hans-Jochen Schneider

Detlef Karras • Lutz Kredel • Uwe Pape

Entwicklungsumgebungen für Expertensysteme Vergleichende Darstellung ausgewählter Systeme

w DE

G_

Walter de Gruyter • Berlin • New York 1987

Detlef Karras Diplom-Informatiker, Diplom-Psychologe, Unternehmensberater für Expertensysteme, Berlin. Lutz Kredel, Dr.-Ing., Unternehmensberater für Expertensysteme, Berlin. Uwe Pape Professor, Dr., Institut für Angewandte Elektronische Datenverarbeitung (AEDV), Fachbereich Informatik der TU Berlin.

CIP-Kurztitelaufnahme der Deutschen Bibliothek Karras, Detlef: Entwicklungsumgebungen für Expertensysteme : vergleichende Darst. ausgew. Systeme / Detlef Karras ; Lutz Kredel ; Uwe Pape. - Berlin ; New York : de Gruyter, 1987. (Studien zur Wirtschaftsinformatik ; 1) ISBN 3-11-011294-9 NE: Kredel, Lutz:; Pape, Uwe:, GT

Copyright © 1987 by Walter de Gruyter & Co., Berlin 30. Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Übersetzung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (durch Photokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des Verlages reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Druck: Gerike GmbH, Berlin. - Bindung: Lüderitz & Bauer GmbH, Berlin. - Printed in Germany.

Inhaltsverzeichnis 1. Einleitung

1

2. Einführung in Expertensysteme 2.1 Prinzipien 2.2 Aufbau 2.3 Anwendungsbereiche

5 5 6 9

3. Aspekte der Entwicklung 3.1 Phasen und Paradigmen Wechsel 3.2 Forschungsgebiete der Künstlichen Intelligenz 3.3 Programmiersprachen der Künstlichen Intelligenz 3.3.1 LISP 3.3.2 PROLOG 3.3.3 Vergleich 3.4 Programmierwerkzeuge 3.5 Bestehende Expertensysteme 3.6 Angebotene Entwicklungssysteme

13 13 16 17 17 18 19 19 21 23

4. Bewertungskriterien für Entwicklungssysteme 4.1 Wissensbasis und -repräsentation 4.1.1 Einleitung 4.1.2 Regelorientierte Wissensrepräsentation 4.1.3 Strukturierte Wissensrepräsentation 4.1.3.1 Semantische Netze 4.1.3.2 Frames 4.1.3.3 Objektorientierte Repräsentation 4.1.4 Darstellung unsicheren und vagen Wissens 4.1.4.1 Certainty Factors 4.1.4.2 Bayes'sches Theorem 4.1.4.3 Dempster-Shafer-Theorie 4.1.4.4 Fuzzy-Logik 4.1.5 Erweiterungen zur Wissenrepräsentation 4.1.5.1 Einbindung von Prozeduren 4.1.5.2 Zugriffsorientierte Darstellung (Active Values) 4.1.5.4 Randbedingungen (Constraints) 4.1.6 Hybride Systeme

31 31 31 34 39 40 43 45 47 48 51 52 54 55 55 56 57 59

VI

Inhaltsverzeichnis 4.1.7 Verwaltung der Wissensbasis 4.2 Inferenzsystem 4.2.1 Einleitung 4.2.2 Prinzipien der Inferenz 4.2.3 Kontroll- und Problemlösestrategien 4.2.3.1 Allgemeiner Überblick 4.2.3.2 Vorwärts-Rückwärts-Verkettung 4.2.3.3 Depth-first- vs. Breadth-first-search 4.2.3.4 Nichtmonotones Schließen 4.2.3.5 Blackboard-Architektur 4.2.3.6 Meta-Inferenz 4.3 Dialogkomponente 4.3.1 Wissenserwerbskomponente 4.3.2 Interviewerkomponente 4.3.3 Erklärungskomponente 4.4 Sonstige Einheiten 4.4.1 Benutzeroberfläche 4.4.2 Systemumgebung und Kostenfaktor

60 61 61 63 64 65 66 69 70 72 74 75 76 80 84 87 87 88

5. Darstellung ausgewählter ExpertensystemEntwicklungsumgebungen 5.1 LOOPS 5.1.1 INTERLISP-Umgebung 5.1.2 Programmierparadigmen 5.1.3 Objektorientierte Programmierung 5.1.3.1 Klassenkonzept 5.1.3.2 Variablen 5.1.3.3 Methoden 5.1.3.4 Vererbungs-Mechanismen 5.1.3.5 Zusammenfassung der Klassendefinition 5.1.3.6 Erzeugen und Ansprechen von Objekten 5.1.3.7 Zusammengesetzte Objekte 5.1.4 Datenorientierte Programmierung 5.1.4.1 Notation 5.1.4.2 Zugriffsfunktionen 5.1.4.3 Verschachtelte Active Values 5.1.5 Regelorientierte Programmierung 5.1.5.1 Repräsentation der Regeln 5.1.5.2 Kontrollstrukturen

91 91 91 92 93 93 94 94 95 96 99 99 100 100 100 101 101 102 103

Inhaltsverzeichnis

vn

5.1.5.4 AuditTrail 5.1.5.4 Tasks 5.1.6 Struktur der Wissensbasis 5.1.6.1 Konzept 5.1.6.2 Community Knowledge Base 5.1.6.3 Unique Identifiers 5.1.6.4 Persönliche Arbeitsumgebung 5.1.7 Bewertung

104 104 105 105 105 106 106 106

5.2 KEE 5.2.1 Gestaltung der Benutzerschnittstelle 5.2.2 Objektorientierte Programmierung 5.2.2.1 Darstellung der Units 5.2.2.2 Klassenkonzept 5.2.2.3 Member- und Own-Slots 5.2.2.4 Vererbungs-Mechanismen 5.2.2.5 Value Class 5.2.2.6 Cardinality 5.2.2.7 Methoden 5.2.3 Active Values 5.2.4 Regelorientierte Programmierung 5.2.5 Hypothetische Welten 5.2.6 TellAndAsk 5.2.7 KEEpictures und Activelmages 5.2.8 Bewertung

107 108 109 109 112 112 113 115 118 118 119 121 124 125 126 128

5.3 ART 5.3.1 Deklarative Wissensrepräsentation 5.3.1.1 Definition von Fakten 5.3.1.2 Definition von Relationen 5.3.1.3 Arbeiten mit Fakten 5.3.1.4 Schemata 5.3.1.5 Vererbungsmechanismen 5.3.1.6 Relationen ohne Vererbung 5.3.1.7 Repräsentation von Mengen 5.3.2 Regelorientierte Programmierung 5.3.2.1 Vorwärtsverkettende Regeln 5.3.2.1.1 Regeltypen 5.3.2.1.2 Prämissen

129 129 129 130 130 131 132 134 135 135 135 136 136

vm

Inhaltsverzeichnis 5.3.2.1.3 Konklusionen 5.3.2.2 Rückwärts-Regeln 5.3.2.3 Kontrollstatements 5.3.3 Inferenzmechanismus und Kontrollfluß 5.3.4 Objektorientierte Programmierung und Active Values 5.3.5 Viewpoint-Mechanismus 5.3.5.1 Hypothetische Welten 5.3.5.2 Darstellung zeitlicher Abläufe 5.3.5.3 Vereinigung von Viewpoints 5.3.5.4 Viewpoints auf mehreren Ebenen 5.3.6 ART Studio Interface 5.3.6.1 Browser 5.3.6.2 Execution Monitor 5.3.6.3 ARTIST 5.3.7 Bewertung

138 138 140 140 142 142 143 144 146 146 148 148 149 149 150

5.4 BABYLON 5.4.1 Systemaufbau 5.4.2 Gestaltung der Benutzerschnittstelle 5.4.3 Objektorientierte Programmierung 5.4.3.1 Frames und Instanzen 5.4.3.2 Beschreibung der Slots 5.4.3.3 Methoden und Nachrichten 5.4.3.4 Objektfunktionen und Frame-Referenzen 5.4.3.5 History 5.4.4 Active Values 5.4.5 Produktionsregeln 5.4.5.1 Darstellung der Regeln 5.4.5.2 Inferenzstrategien 5.4.6 BABYLON-PROLOG 5.4.7 Struktur einer Wissensbasis 5.4.8 Bewertung

151 151 153 155 155 156 157 159 159 160 162 162 164 165 166 168

5.5 TWAICE 5.5.1 Überblick 5.5.2 Aufbau des Produktionssystems 5.5.2.1 Darstellung der Produktionsregeln 5.5.2.1.1 Syntax 5.5.2.1.2 Semantik

171 171 175 176 176 177

Inhaltsverzeichnis 5.5.2.1.3 Prämissen 5.5.2.1.4 Konklusionen 5.5.2.1.5 Konfidenzfaktoren 5.5.2.2 Taxonomie 5.5.2.3 Inferenzmechanismus 5.5.2.4 Erklärungskomponente 5.5.3 Gestaltung der Konsultationsoberfläche 5.5.4 Hilfsmittel zum Testen eines Konsultationsprogramms 5.5.4.1 Falldatenverwalter 5.5.4.2 TRACE-Funktion 5.5.4.3 Erklärungskomponente 5.5.4.4 Wissensanalysator 5.5.5 Systemmodule 5.5.6 Bewertung 6. Bewertender Vergleich der Systeme 6.1 Kriterienkatalog 6.2 Allgemeine Bewertung 6.3 Bewertung als Konsultationssystem 6.4 Bewertung als Simulationssystem 6.5 Zusammenfassung

IX 178 180 182 183 185 185 186 187 187 188 188 188 189 190 193 193 196 199 201 203

7. Ausblick

205

Literaturverzeichnis

207

Stichwortverzeichnis

213

1. Einleitung Expertensysteme stehen zwischen dem Ruf des Modisch-Exotischen und der optimistischen Einschätzung, sich zur Schlüsseltechnologie zu entwickeln. Sie stellen neben der Robotik und der Sprachverarbeitung das wichtigste Anwendungsgebiet der Künstlichen Intelligenz dar. Am deutlichsten wird die Bedeutung dieser Technologie an der Marktentwicklung, die in Abb. 1-1 - Aufwendungen für Anwendungsbereiche der Künstlichen Intelligenz in Mio. US$ - aufgezeigt wird.

1982 1983 1984 1985 1986 1987 1988 1989 1990

Segment

9

18

35

67

126

231

408

678 1017

Software für Kommun. 8 in natürl. Sprache Computergestützte 5 Ausbildung Bildverarbeitung 22

18

34

64

117

208

357

574

832

8

14

24

40

66

103

150

195

50

90

133

210

322

472

642

770

7

11

18

35

70

115

180

263

342

51

105

191

323

563

Expertensysteme

Akustische Spracheingabe Summe

942 1520 2307 3156

Abb. 1-1: Marktentwicklung der KI in Mio. US$ (Quelle: SCHNUPP,

1986, S. 89)

Anfang der siebziger Jahre entstanden die ersten Expertensysteme auf LISP-Basis. Da alle Repräsentations- und Inferenzmechanismen neu implementiert werden mußten, war deren Erstellung ein mühsames Unterfangen. Daher entstanden Ende der siebziger, Anfang der achtziger Jahre einzelne Entwicklungswerkzeuge (Tools) zur Programmierunterstützung bzw. Expertensystem-Shells, die ein fertiges System darstellen, in das nur das bereichsspezifische Wissen eingegeben zu werden braucht. Zur gleichen Zeit wurde die Programmiersprache - oder besser gesagt: Programmierumgebung - PROLOG entwickelt, die aufgrund ihrer vorgegebenen Wissensdarstellungs- und Ableitungsstruktur das schnelle Erstellen kleinerer Systeme gestattet.

2

Einleitung

In den letzten Jahren sind immer komfortablere Entwicklungsumgebungen entstanden, die eine intelligente Benutzeroberfläche mit mächtigen Verarbeitungsmechanismen kombinieren. BROWN (1984) weist bezüglich der Anwendung der Methoden der Künstlichen Intelligenz darauf hin, daß Fortschritte in diesem Bereich nicht so sehr von der Weiterentwicklung theoretischer Konzepte abhängen. Anwendersysteme bedienen sich häufig der Methoden, die seit mehreren Jahrzehnten bekannt sind. Entscheidend sei vielmehr die Entwicklung und die Kostengestaltung auf dem Bereich der Hardware. Leistungsfähige Computersysteme gestatten eben eine leistungsfähige Softwareumgebung. Auch auf dem Gebiet der Expertensysteme wird sich die Durchsetzungsfähigkeit am Markt nach wirtschaftlichen Gesichtpunkten entscheiden. Dieses Buch beschreibt und vergleicht fünf bekannte Entwicklungssysteme, die den Aufbau von Expertensystemen ermöglichen. Es sind dies LOOPS, KEE, ART, BABYLON und TWAICE. Die ersten drei Systeme stammen aus den USA, wobei LOOPS von XEROX in der Tradition von SMALLTALK als experimentelles Tool entwickelt wurde, während KEE und ART ausgereifte, kommerzielle Entwicklungsumgebungen darstellen. Die beiden letztgenannten Systeme wurden in Deutschland entwickelt und repräsentieren ein "hybrides" und ein regelbasiertes System. Zunächst wird in Kapitel 2 eine Einführung in den Problemkreis "Expertensysteme" gegeben mit einer Ausführung über Prinzipien, Aufbau und Anwendungsbereiche. Kapitel 3 gibt einen Überblick über geschichtliche Entwicklung, Forschungsbereiche und Programmiersprachen der Künstlichen Intelligenz und benennt bereits bestehende Expertensysteme und angebotene Entwicklungsumgebungen. Den Hauptteil der theoretischen Grundlagen bildet Kapitel 4, in dem die einzelnen Komponenten von Expertensystemen beschrieben werden, um daraus Bewertungskriterien für Entwicklungssysteme zu gewinnen. In Kapitel 5 werden die fünf genannten Expertensystem-Entwicklungsumgebungen ausführlich dargestellt und einzeln bewertet Kapitel 6 enthält einen bewertenden Vergleich der Systeme, wofür ein strukturierter Kriterienkatalog aufgestellt und nach der Methode der Nutzwertanalyse auf die einzelnen Systeme angewandt wurde. Dabei ergibt sich die interessante Möglichkeit, je nach Anwendungsgebiet verschiedene Bewertungen vorzunehmen. Diese Bewertungs-

Einleitung

3

methode stellt einen Versuch dar, Expertensysteme etwas detaillierter und objektiver zu beurteilen, und könnte den Anstoß für weitere Untersuchungen bilden. Kapitel 7 beschließt die Ausführungen mit einem Ausblick auf zukünftige Entwicklungen und mögliche Aufgabenstellungen.

2. Einführung in Expertensysteme In den folgenden Abschnitten dieses Kapitels über Prinzipien, Aufbau und Anwendungsbereiche von Expertensystemen soll geklärt werden, was ein Expertensystem ist und wo seine hauptsächlichen Anwendungsgebiete liegen.

2.1 Prinzipien Ein menschlicher Experte ist ein speziell ausgebildeter und erfahrener Fachmann auf einem zumeist engumrissenen, aber anspruchsvollen Gebiet. Sein fachliches Knowhow setzt sich aus der Kenntnis von Fakten, wie sie im Lehrbuch stehen und oftmals mathematisch formulierbar sind, und aus Erfahrungswissen ("Faustregeln") zusammen. Er kann Probleme effizient lösen, wobei er relevante von irrelevanter Information unterscheiden kann. Bei neuartigen Problembereichen entwickelt er kreative Lösungsansätze. Da Experten oftmals schwer verfügbar und teuer sind, wird seit Anfang der siebziger Jahren versucht, intelligente Computerprogramme zu entwickeln, die sich wie Experten verhalten. Dabei wurden insbesondere Methoden der Künstlichen Intelligenz verwandt, die RICH (1983, S. 1) folgendermaßen - rein pragmatisch - definiert: "Künstliche Intelligenz ist das Bemühen darum, den Computer Dinge tun zu lassen, die Menschen im Augenblick noch besser können." Diese "intelligenten" Methoden bewirken im wesentlichen zweierlei: Durch logische Ableitung kann aus vorhandenem Wissen neues Wissen erschlossen werden. • Bei Problemen mit sehr vielen Lösungsmöglichkeiten begrenzen sie den Suchaufwand durch heuristische Methoden, allerdings ohne Garantie, die beste Lösung zu finden. Der Kern eines Expertensystems besteht im wesentlichen aus zwei Teilen: Der Wissensbasis (knowledge base) mit dem fachspezifischen Wissen des Experten, bestehend hauptsächlich aus Fakten und Regeln, und dem Inferenzsystem (inference machine), das Methoden zur Anwendung des Wissens zur Lösung anfallender Probleme zur Verfügung stellt. Expertensysteme sind also stets wissensbasierte Systeme, wobei auch - im Gegensatz z. B. zu Datenbanken - unsicheres und vages

6

Einführung in Expertensysteme

Wissen zugelassen ist. Die Hauptarbeit bei der Erstellung eines solchen Systems besteht darin, das Wissen des Experten zu erfassen und auf angemessene Weise zu repräsentieren. Dies wird als "knowledge engineering" bezeichnet, der ausführende Fachmann ist der "knowledge engineer". Wesentlich ist die inhaltliche und logische Trennung von Wissensbasis und Inferenzsystem, weil hierdurch die Erstellung, Veränderung und Erweiterung eines Expertensystems erleichtert wird. Die Beziehung von Expertensystemen zu Wissensbasierten Systemen und Methoden der Künstlichen Intelligenz soll das folgende Diagramm (Abb. 2-1) veranschaulichen:

Methoden und Techniken der Künstlichen Intelligenz zeigt intelligentes Verhalten durch geschickte Anwendung von Heuristiken Wissensbasierte Systeme macht bereichsspezifisches Wissen explizit und teilt es vom restlichen System ab Expertensysteme wendet Expertenwissen auf schwierige Probleme der realen Welt an Abb. 2-1: Expertensysteme im methodischen Kontext (nach WATERMAN, 1986, S. 18)

2.2 Aufbau Ein Expertensystem besteht zunächst aus dem "Systemkern", der die Wissensbasis mit den bereichsspezifischen Regeln und Fakten und das Inferenzsystem mit dem Mustervergleicher (pattem matcher) und der Kontrollstrategie zur Auswahl der passenden Regeln und dem Regelinterpreter zur Abarbeitung der ausgewählten Regeln enthält (Abb. 2-2). Außerdem kann der Systemkern Zugriff auf Datenbanken und Massenspeicher haben.

Aufbau

7

Abb. 2-2: Expertensystem-Kern (nach WATERMAN,

1986, S. 19)

Um diesen Kern herum sind verschiedene Komponenten gruppiert, die dem Aufbau eines Expertensystems dienen und den Dialog mit dem Benutzer steuern. Diese Komponenten werden im folgenden überblicksartig aufgeführt und in Kapitel 4 näher erläutert. Wissenserwerbskomponente: • Regeleditor • Expertendialogsteuerung • natürlich-sprachlicher Wissenseingang • automatische Regel-Buchführung • Syntax-Überprüfung • Konsistenz-Prüfung • automatisches Lernen Fehlersuchhilfen: • Einzelschrittsteuerung (trace) • Haltepunkte (break points) • automatisches Testen

Einführung in Expertensysteme

8 Ein-/Ausgabe: • Menues •Grafik • Wissenserwerb während des Benutzerdialogs • Zugriff auf das Betriebssystem

^

Experte

Fragen i f Probleme

^ Antworten Lösungen

[ Knowledge V| Strategien l Engineer J) Regeln

Wissenserwerbskomponente

r I I I

Wissensbasis

Inferenzsystem

Ein-/Ausgabe

c

Benutzer

Abb. 2-3: "Wissensfluß" in einem Expertensystem

J

Anwendungsbereiche

9

Erklärungskomponente: • Erklärung des Lösungsweges (how?) • Begründung von Systemfragen (why?) • Hypothetische Lösungen • Erklärung von nicht abgeleiteten Folgerungen Lehrkomponente (Computer Aided Instruction, CAI) Der "Wissensfluß" vom Experten über das Expertensystem zum Benutzer wird in Abb. 2-3 grafisch veranschaulicht.

2.3 Anwendungsbereiche Um die Anwendungsbereiche für Expertensysteme klar zu umreißen, sollen nochmals deren Charakteristika - in Abhebung von konventionellen Programmiermethoden - hervorgehoben werden: • Expertensysteme sind wissensbasierte Systeme, wobei Wissen über die Anwendung des Wissens im System enthalten ist. • Problemlösen geschieht durch logisches Ableiten neuen Wissens aus vorhandenem Wissen - und nicht durch feste Algorithmen wie bei der Berechnung numerischer Aufgaben oder der Suche in Datenbeständen. Die beiden folgenden Punkte sind ebenfalls typisch für Expertensysteme, wenn auch nicht immer vorhanden: • Die Darstellung unsicheren und vagen Wissens ist zugelassen. • Bei einer übergroßen Anzahl an Lösungsmöglichkeiten ("kombinatorische Explosion") kann der Suchraum und damit die Bearbeitungszeit durch die Anwendung heuristischer Methoden begrenzt werden. Daraus abgeleitet sind folgende Eigenschaften der Anwendungsbereiche für Expertensysteme charakteristisch: • großer Lösungsraum • verrauschte, unvollständige Daten

10

Einführung in Expertensysteme

• keine geschlossene Theorie • hypothetische Annahmen • teilweise zeitabhängige Daten • unsicheres Wissen über Beziehungen von Sachverhalten Folgende Anforderungen sollten beim Einsatz eines Expertensystems erfüllt sein: • Der Aufgabenbereich sollte gegenüber schwer formalisierbarem Allgemeinwissen deutlich abgrenzbar sein. • Der Aufgabenbereich sollte einen gewissen Grad an wissenschaftlicher Durchdringung und Systematisierung aufweisen. • Mindestens ein anerkannter menschlicher Experte sollte für das betreffende Gebiet verfügbar sein. Weniger geeignet ist die Anwendung in folgenden Bereichen: • sehr einfache Probleme (weniger als 10 Regeln) • zu komplexe Bereiche (mehr als 10000 Regeln) • klar strukturierte, numerische Probleme • wenn Informationen besser durch Menschen verarbeitet werden (menschliche Sinne, Zeichenerkennung usw.) • bei umfangreichen und belanglosen Problemen ("wide and shallow") BASDEN (1984) stellt allerdings die genannten Grenzen der Anwendbarkeit von Expertensystemen in Frage, da alternative Ansätze oft auch nicht besser sind und nicht immer Vollständigkeit und höchste Genauigkeit bei der Lösung erwartet wird. Die Anwendungsbereiche für Expertensysteme lassen sich nach WATERMAN (1985, S. 33) in folgende grundsätzliche Kategorien einteilen:

Anwendungsbereiche

11

Kategorie

Angesprochenes

Interpretation Vorhersage

Situationsbeschreibung aufgrund sensorischer Daten Erschließen wahrscheinlicher Konsequenzen aufgrund einer gegebenen Situation Ableitung von Systemfehlern aufgrund von Beobachtungen Konfiguration von Objekten unter Randbedingungen Gestaltung von Handlungen Vergleich von Ist- und Sollwert Vorschlag zur Abhilfe bei Fehlfunktionen Ausarbeitung eines Plans zur Fehlerbeseitigung Diagnose, Fehlersuche und Reparatur von studentischem Verhalten Steuerung des Gesamtsystem-Verhaltens

Diagnose Gestaltung Planung Überwachung Fehlersuche Reparatur Unterweisung Kontrolle

Problem

3. Aspekte der Entwicklung In diesem Kapitel wird ein kurzer historischer Abriß von den ersten Ideen zur Realisierung einer "künstlichen Intelligenz", den Entwicklungsphasen mit ihren unterschiedlichen Paradigmen, den wichtigsten Programmiersprachen der KI, LISP und PROLOG, bis hin zu ausgefeilten Systemen zur Unterstützung des Entwicklers und Anwenders von Expertensystemen gegeben. Aus diesem Kontext heraus werden bestehende Expertensysteme und angebotene Entwicklungssysteme (Tools und Shells) vorgestellt.

3.1 Phasen und Paradigmenwechsel Seit Ende der 50er Jahre wird auf dem Gebiet der "Artificial Intelligence" (AI), zu deutsch: "Künstliche Intelligenz" (KI), gearbeitet, anfänglich ausschließlich in den USA. Als Pioniere dieser jungen Wissenschaft gelten Newell, Simon, Minsky und McCarthy. Es war deren Anliegen, in Zusammenhang mit psychologischer Forschung die Struktur intelligenter Leistungen (Wahrnehmung, Gedächtnis, Problemlösen, Sprache usw.) zu erfassen und durch Computerprogramme (und teilweise auch Hardware) effizient nachzubilden bzw. zu simulieren. Die grundlegende Idee war dabei, daß sich Datenverarbeitung nicht nur auf numerische Probleme zu beziehen braucht, sondern daß auch eine symbolische Repräsentation der "Umwelt" möglich ist, die im Sinne der Problemlösung logische Schlußfolgerungen zuläßt FORSYTH (1984) faßt die Entwicklung hin zu heutigen Expertensystemen - in sehr vereinfachter Form - in vier zeitlich aufeinanderfolgende Phasen zusammen, wobei er für jede das zentrale Forschungsparadigma, die wichtigsten Persönlichkeiten und ein typisches System angibt (Abb. 3-1). Es läßt sich dabei generell eine Entwicklung von sehr allgemein gehaltenen Annahmen und Regeln hin zur Bearbeitung sehr spezieller Wissensbereiche ablesen. Eine etwas detailliertere Einteilung in fünf Phasen wird von SCHEFE (1986) in Anlehnung an DREYFUS (1979) vorgenommen. 1. Phase: Heuristisches Programmieren (1957 - 1962). Diese Zeit ist durch den Versuch gekennzeichnet, mit generellen, einfachen Methoden beliebige Probleme

14

Aspekte der Entwicklung

lösen zu können. Sie wurde auch als Phase der kognitiven Simulation bezeichnet. Als zentral für intelligente Prozesse wurde das heuristisch gelenkte Durchsuchen sehr großer Zustandsräume möglicher Lösungen angesehen. Auf dem Gebiet der Mustererkennung wurde die hardwaremäßige Nachbildung des menschlichen Gehirns zu realisieren versucht, um einfache Muster wie z. B. Buchstaben erkennen und klassifizieren zu können.

Paradigma

Vertreter

System

1950...

Neurale Netze

Rosenblatt (Wiener, McCulloch)

PERCEPTRON

1960...

Heuristische Suche

Newell, Simon (Shannon, Turing)

GPS

1970...

Wissensrepräsentation

Shortliffe (Minsky, McCarthy)

MYCIN

1980...

Maschinelles Lernen

Lenat (Samuel, Holland)

EURISCO

Abb. 3-1: Expertensysteme im historischen Kontext (nach FORSYTH, 1984, S. 4)

In der Simulation kognitiver Prozesse gelang der Beweis von Theoremen der Aussagenlogik. Diese Methode wurde zum "General Problem Solver" (GPS) erweitert, der in einer formalisierten Mikroweit engumrissene Probleme lösen konnte, die leider jeglicher Relevanz entbehrten. Ebenso wurden Spielprogramme entwickelt (Dame, Schach), die auf ausgedehnten Suchvorgängen beruhten. Auf dem Gebiet der Sprachverarbeitung nahm man zunächst an, daß eine lexikalische Auflistung von Wörtern und die Kenntnis der Syntax für das Verstehen von Sätzen ausreichend wäre. Nach einer anfänglichen Euphorie, die als die "Täuschung über den ersten erfolgreichen Schritt" (DREYFUS, 1979) beschrieben wurde, setzte eine baldige Ernüchterung ein.

Phasen und Paradigmenwechsel

15

2. Phase: Semantische Informationsverarbeitung (1963 - 1967). Diese Phase wird am stärksten durch die Arbeiten von Minsky dokumentiert, der erkannte, daß die Methoden der ersten Phase nur für einfache Probleme geeignet sind, und daraufhin ein bewußtes ad-hoc-Vorgehen propagierte. Es wurden spezialisierte Programme entwikkelt wie z. B. Bobrows STUDENT (ein Programm zur Lösung algebraischer Textaufgaben), Evans ANALOGY PROGRAM (Erkennen der Analogie von Objekten) und Quillians SEMANTIC MEMORY (Semantisches Gedächtnisprogramm). Es wird erstmals deutlich, daß erfolgreiche Programme auf das Einbeziehen von Spezialwissen angewiesen sind. 3. Phase: Die Bearbeitung von Mikroweiten (1967 - 1972). Das Jahr 1967 wird als ein Wendepunkt angesehen, weil Programme entwickelt wurden, die sich auf konkrete Anwendungsgebiete bezogen, damit aber den engen Rahmen früherer KIMethoden sprengten. MACSYMA von Moses, das Methoden zur Unterstützung mathematischer Arbeiten bereitstellt, ist das erste Anwendungsprogramm von Bedeutung. Gleichzeitig wurde DENDRAL (Feigenbaum) erstellt, das das Wissen eines Chemikers auf dem Gebiet der Massenspektroskopie enthält. Mit SHRDLU von Winograd entstand ein Programm, das geradezu als d a s Kl-Programm schlechthin (HOFSTADTER, 1979) angesehen wurde und damit einen Wechsel der Kl-Philosophie signalisierte. Es manipuliert eine Mini-Blockwelt, indem es natürlich-sprachliche Fragen in engen Grenzen versteht, beantwortet und Befehle ausführt. Der in früheren Zeiten syntaktisch gesteuerte Sprachprozeß wurde mehr auf die semantische Ebene verlagert. 4. Phase: Technologie der Wissensverarbeitung (1972 - 1977). Die Beschreibung, Organisation und Verarbeitung von Wissen wurde zum zentralen Thema dieser Phase. MINSKY (1975) entwickelte das Konzept der "Frames", das großen Einfluß auf die Technik der Wissensrepräsentation nahm. Newell schuf das Konzept des Produktionssystems (Problemlösen durch Anwendung von Regeln) zur Simulation kognitiver Vorgänge. Es brach die Zeit berühmt gewordener Expertensysteme an, und Feigenbaum prägte diesbezüglich den Begriff "knowledge engineer". Das bis heute meistzitierte Expertensystem, MYCIN (Diagnose und Behandlungsempfehlungen bei bakteriellen Infektionen), wurde hauptsächlich von Shortliffe (BUCHANAN & SHORTLIFFE, 1984) entwickelt. Es vereinigt ein Produktionssystem mit einem Wissensaneignungsmodell und der Theorie des Certainty Factors. In dieser Zeit entstand auch die Sprache PROLOG (Kowalski, Colmerauer).

16

Aspekte der Entwicklung

5. Phase: Entwicklung von Werkzeugen (1977 - 1982). Diese Phase ist gekennzeichnet durch das weitere Erstellen anwendungsbezogener Expertensysteme, der Bereitstellung von Expertensystem-Entwicklungsumgebungen, der Erforschung robuster natürlich-sprachlicher Dialogsysteme, der Anwendung abweichender Logiken (nicht-monoton, Fuzzy) und der Nutzung von KI-Methoden in Datenbanken. Es erscheint das bisher wichtigste Buch über Expertensysteme von HAYES-ROTH et al. (1983). Auf diesem Gebiet findet eine fortschreitende Kommerzialisierung statt, die auch in Zukunft anhalten wird. Da die heute verfügbaren Expertensysteme dem Paradigma wissensbasierter Systeme folgen, stellt sich die Aufnahme und Kodierung von Wissen in eine dem System verständliche Form als der Flaschenhals der Konstruktion dar. Daher ist das automatisches Lernen ein Schlüsselkonzept für intelligente Computersysteme der Zukunft, zumal man bedenkt, wieviel Zeit ein Mensch für das Erlernen komplexer Fertigkeiten benötigt.

3.2 Forschungsgebiete der Künstlichen Intelligenz Wie bereits in Abschn. 3.1 beschrieben, begann in den 50er Jahren das Interesse Uber die Berechnung rein numerischer Probleme hinauszugehen, und es wurde versucht, menschliche Denk- und Verstandesleistungen auf dem Computer nachzuahmen. Künstliche Intelligenz entwickelt sich heute zu einem Schlüsselbegriff für die Software der Zukunft, da hierdurch nicht nur Werkzeuge zur Verfügung gestellt werden, um anspruchsvollere Probleme anzugehen, sondern auch eine bedienerfreundlichere Benutzeroberfläche geschaffen werden kann. Das Gebiet der Künstlichen Intelligenz stellt eine breite Pallette von Methoden und Prinzipien zur Verfügung, die in Programmsysteme - wie z. B. Expertensysteme integriert werden können. Die bedeutendsten Anwendungs- und Forschungsgebiete der KI zeigt die folgende Zusammenstellung {STEINACKER, 1984, S. 16): Wahrnehmen: Denken:

Bildanalyse (Vision) Spracherkennung (akustisch) Problemlösen Schlüsse ziehen Lernen Spiele Automatische Beweisverfahren

Programmiersprachen der Künstlichen Intelligenz Anwendung von Wissen: Sprachverstehen:

17

Expertensysteme Dialoge führen Texte nacherzählen Maschinenübersetzung

Roboter Maschinelles Lernen

3.3 Programmiersprachen der Künstlichen Intelligenz Auf dem Gebiet der KI behaupten sich zwei Programmiersprachen, LISP und PROLOG, deren Aufbau sich grundlegend von dem anderer gebräuchlicher Sprachen unterscheidet. Sie sollen im folgenden kurz beschrieben und dann in ihrer Anwendbarkeit verglichen werden.

3.3.1 LISP LISP steht für "LISt Processing language" und wurde um 1960 von John McCarthy am MIT entwickelt. Es ist eine funktionale Programmiersprache, die insbesondere für Symbolmanipulation und Listenverarbeitung geeignet und daher auf die Behandlung von Kl-Problemen zugeschnitten ist. Insbesondere in den USA wird LISP auf dem Gebiet der KI am häufigsten eingesetzt und hat eine Fülle von Dialekten, insbesondere aber von ausgefeilten Programmiersystemen hervorgebracht. Es ist eine interpretative Sprache und eignet sich von daher für einen interaktiven Programmierstil. Zur Verbesserung der Laufzeiteigenschaft kann es außerdem meist kompiliert werden. LISP ist eine sehr flexible Sprache, die eine kleine Menge "primitiver" Funktionen zur Verfügung stellt, aus denen dann höherstrukturierte Elemente aufgebaut werden können. Es besitzt eine dynamische Speicherverwaltung und behandelt Programmcode und Daten vom Prinzip her gleich, so daß ein LISP-Programm sich selbst verändern kann. Aus der Vielzahl von Dialekten können drei besonders hervorgehoben werden: • MACLISP, das am MIT entwickelt und zu ZETALISP ausgebaut wurde und insbesondere auf LISP-Maschinen von Symbolics und LMI eingesetzt wird.

18

Aspekte der Entwicklung

• INTERLISP, das von Xerox zu INTERLISP-D weiterentwickelt wurde. Es wurde von SIEMENS übernommen und unter dem Namen SIEMENS-INTERLISP an das Betriebssystem BS 2000 angepaßt. • COMMON LISP stellt den Versuch der Carnegie-Mellon University dar, einen Quasi-Standard zu schaffen, der mit möglichst vielen Dialekten kompatibel und auf einer Vielzahl von Geräten einsetzbar ist. Für den effektiveren Einsatz wurden sog. LISP-Maschinen entwickelt, die durch einen schnellen Prozessor mit LISP-Funktionen auf Mikroprogrammebene, einen großen Hauptspeicher (3,5...65 MByte), hochauflösenden Grafikbildschirm, Pointing devices ("Maus") und eine ausgefeilte Software-Umgebung (Editor, File-Verwaltung usw.) die z. Z. leistungsfähigsten Programmierumgebungen zur Verfügung stellen. Einen ausführlichen Überblick über die Leistungsfähigkeit von Kl-Workstations und deren Marktsituation bieten ROME & UTHMANN (1987).

3.3.2 PROLOG PROLOG (PROgramming in LOGic) wird insbesondere in Westeuropa und Japan angewandt und wurde 1972 von A. Colmerauer unter Rückgriff auf die theoretischen Arbeiten von R. A. Kowalski entwickelt. Es ist eine deskriptive, logische Sprache und folgt dem Paradigma des automatischen Theorembeweisens auf der Basis der Prädikatenlogik 1. Ordnung. Ein PROLOG-Programm besteht aus Fakten und Regeln, die durch logische Formeln (Horn-Klauseln) beschrieben werden. Logische Ableitungen erfolgen durch eine rückwärtsverkettende Inferenzprozedur mit Backtracking. Dabei werden zur Bearbeitung einer Benutzeranfrage die anwendbaren Regeln nacheinander ausgesucht (pattem matching), die Variablen durch eingegebene Werte ersetzt (Substitution) und die Regeln ausgeführt, wobei eine Verkettung mehrerer Regeln stattfinden kann. Da PROLOG ein vollständiges Programmsystem mit standardisierten Bearbeitungsprozeduren darstellt, ist das schnelle Erstellen kleinerer Demonstrationsprogramme möglich. Andererseits bietet es nur eine eingeschränkte Programmierumgebung und ist in seiner Inferenzprozedur einseitig, so daß es leicht ineffektiv werden kann. Eine Veränderung des inneren Programmablaufs ist nicht vorgesehen und daher nur schwer durchführbar.

Programmiersprachen der Künstlichen Intelligenz

19

Andererseits wird PROLOG im Rahmen des japanischen Fifth Generation Projects ein hoher Stellenwert beigemessen, indem es als eine Art Assemblersprache aufgefaßt und hardwaremäßig nach neuen Architekturprinzipien realisiert wird. Darauf sollen dann höhere Sprachen implementiert werden.

3.3.3 Vergleich LISP-Systeme bieten sehr flexible und leistungsfähige Programmierumgebungen, sind dafür aber meist an teure Workstations gebunden. Vorteile

LISP

sehr flexibel komfortable Programmierumgebung moderne Konzepte (objektorientiert) schnell auf LISP-Maschinen

Nachteile ungewöhnliche Notation schwer verständlich für Dritte internspeicherintensiv teure Hardwareumgebung

PROLOG ist zwar ein einfach zu handhabendes Programmiersystem, wird aber bei größeren Programmen unübersichtlich und ineffizient. Es ist bisher kein wirklich leistungsfähiges Expertensystem auf PROLOG-Basis bekannt. Außerdem bietet das Paradigma der regelbasierten Systeme keinen Ansatz für eine konzeptionelle Weiterentwicklung. Erst eine hardwaregemäße Realisierung von PROLOG als "Maschinensprache" im Rahmen des japanischen Fifth Generation Projects dürfte für eine erweiterte Anwendung sorgen. PROLOG Vorteile Nachteile einfach zu handhaben eingeschränkt auf Prädikatenlogik anschaulich Inferenzstrategie festgelegt schnelles Erstellen kleinerer Systeme Gefahr der Ineffizienz Anwendung auf Personal-Computern keine leistungsfäh. Programmierumg.

3.4 Programmierwerkzeuge Für die Konstruktion eines Expertensystems gibt es eine Reihe von Software-Werkzeugen, die sich in drei Kategorien unterteilen lassen:

20

Aspekte der Entwicklung

• Hilfsmittel für engumrissene Aufgaben und Probleme, die z. T. auch in anderen Bereichen der Programmerstellung verwendet werden können (Editoren, grafische Hilfsmittel usw.). Diese werden auch als "Tool" bezeichnet. • Fertige Expertensysteme, aus denen die ursprüngliche Wissensbasis entfernt wurde, so daß sie für andere Fachgebiete verwendet werden können, wobei Komponenten für die Repräsentation des Expertenwissens hinzugefügt wurden. Ein Beipiel bietet EMYCIN, das aus MYCIN hervorgegangen ist. Ein solches System wird als "Shell" bezeichnet. Dabei besteht die Gefahr, daß es naturgemäß unflexibel bezüglich der Systemstruktur, insbesondere des Inferenzmechanismus und der Verarbeitung unsicheren Wissens ist. • Ein Gerüst aller zum Bau eines Expertensystems benötigten Komponenten, die aber nicht wie im vorigen Fall aus einem bereits fertiggestellten System abgeleitet, sondern für universelle Anwendungsfälle konzipiert wurden. Diese sind naturgemäß flexibler und werden häufig ebenfalls als "Shell" bezeichnet. WATERMAN (1986) gebraucht bei Shells den Begriff "Knowledge Engineering Language".

höhere Programmiersprachen

Programmierumgebungen

ExpertensystemShells W

LISP

PROLOG INTERLISP

OPS5

KEE LOOPS ART

FORTRAN PASCAL

EMYCIN S.l M.l TIMM INSIGHT

Abb. 3-2: Das Programmiersprachen-Shell-Kontinuum (nach HARMON & KING, 1985, S. 83)

Ein Expertensystem-Shell kann gerade zu Beginn eines Projektes den Arbeitsfortschritt wesentlich beschleunigen und stellt insgesamt eine erhebliche Arbeitserleichterung dar. Kritisch wird es erst dann, wenn spezielle Schemata nicht zur Aufgabenstellung passen und das System in wesentlichen Teilen verändert werden muß. Dann schlägt der anfängliche Vorteil leicht ins Gegenteil um. Hier haben spezielle Software-Tools ihre Berechtigung, die den kreativen Systementwickler von Routinearbei-

21

Bestehende Expertensysteme

ten entlasten und ihm gleichzeitig genügend Freiheit für eine problemgerechte Gestaltung des Expertensystems bieten, wobei die einzelnen Tools aufeinander abgestimmt sein und eine gemeinsame sprachliche Oberfläche aufweisen sollten. Eine strenge Kategorisierung - insbesondere in Shells und Tools - ist allerdings wegen der Vielzahl von Übergängen nur schwer möglich und wird auch in der Literatur nicht streng durchgeführt Man kann sich die Software-Werkzeuge vielmehr auf einer gleitenden Skala - höhere Programmiersprache - Programmierumgebung - Expertensystem-Shell - abgebildet vorstellen. Dies soll ein Diagramm (Abb. 3-2) verdeutlichen.

3.5 Bestehende Expertensysteme Im Laufe der Zeit wurde eine Vielzahl von Expertensystemen der unterschiedlichsten Fachgebiete erstellt. Es folgt eine Aufstellung von knapp 200 in der Literatur (BUNDY, 1984, 1986; HARMON & KING, 1985, 1986; HAYES-ROTH et al., 1983; WATERMAN, 1986) beschriebenen Systemen, nach Fachgebieten geordnet und ohne Anspruch auf Vollständigkeit. Die reine Aufzählung der Systeme mag unbefriedigend sein, eine eingehendere Beschreibung würde aber den Rahmen dieser Arbeit sprengen. Chemie: CONGEN CRYSALIS C-13 DENDRAL GA1

META-DENDRAL MOLGEN OCSS SECS SEQ

SPEX SYNCHEM SYNCHEM2 TQMSTUNE

Computersysteme: CRIB DART IDT ISA

MIXER Rl-SOAR TIMM/TUNER XCON (Rl)

XSEL YES/MVS

Elektronik: ACE BDS CADHELP COMPASS CRITTER DAA

REDESIGN EURISCO FG502-TASP SADO SOPHIE FOREST SYN IN-ATE MESSAGE TRACE AN. TALIB TRANSISTOR NDS

22

Aspekte der Entwicklung DFT EL

Geologie: DIPMETER ADVISOR DRILLING ADVISOR ELAS

PALLADIO PEACE HYDRO LITHO MUD

SIZING SYSTEM

PROSPECTOR

Informations-Management: FOLIO CARG GCA CODES IR-NLI ED AAS

PROJCON RABBIT RESEDA

Landwirtschaft: PLANT/cd

PLANT/ds

POMME

Mathematik: ADVISOR

MACSYMA

MATHLAB 68

Medizin: ABEL EMERGE EXAMINER AVCOAG AI/MM GALEN AI/RHEUM GUIDON ANGY HDDSS ANNA HEADMED ARAMIS HEART IM. INTERPR. HEME ATTENDING BABY HT-ATTENDING BLUE BOX INTERNIST/CADUC. CASNET/GLAUCOMA IRIS MDX CENTAUR MECS-AI CLOT DIAGNOSER MEDICO DIALYSIS THER. ADV. MED1 MI DIGITALIS ADVISOR DRUG INTERACT.CRIT. MODIS EEG ANALYSIS SYST. MYCIN Meteorologie: WILLARD Mikrobiologie: GENESIS

NEOMYCIN NEUREX NEUROLOGIST OCULAR HERPES MODEL ONCOCIN PATHFINDER PATREC PEC PIP PUFF RADEX RX SPE SYSTEM D THYROID MODEL VM WHEEZE

23

Bestehende Expertensysteme Militär: ACES ADEPT AIRID AIRPLAN AMUID ANALYST ASTA ATR BATTLE

DART EPES EXPERT NAVIGATOR HANNIBAL I&W KNOBS MES OCEAN SURVEILL. RTC

RUBRIC SCENARIO-AG. SIAP SPAM SWIRL TATR TWIRL

Physik: GAMMA

MECHO

Produktion: IMACS

ISIS

Prozeßsteuerung: FALCON

PDS

Raumfahrt: ECESIS FAITH KNEECAP

LES NAVEX RBMS

RPMS

Rechtswissenschaft: AUDITOR DSCAS JUDITH LDS

LEGAL ANAL. SYST. LRS SAL SARA

TAXADVISOR TAXMAN

REACTOR SACON SPERIL

STEAMER

PTRANS

Sprachverstehen: HEARSAY Technik: CONPHYDE DELTA/CATSNPPC

3.6 Angebotene

Entwicklungssysteme

Im Laufe der Zeit wurde eine Reihe von Entwicklungssystemen angebotenen, angesiedelt auf dem gleitenden Spektrum Programmierumgebung - Tool - Shell, die das Erstellen eines Expertensystems unterstützen.

24

Aspekte der Entwicklung

1965

1970 |

HEARSAY I

1975

1980 I

HARPY HEARSAY II

AGE

|

HEARSAY III j

INTERNIST

OPS

CADUCEUS EXPERT

CASNET H

1985

OPS 4

S

"MICRO" OPS 5

XCON

PROSPECTOR

H

OPS 5e

'

XSEL

1 KAS } PERSONAL CONS. | TWAICE """] DRILLING ADV]

H |

KS 300

PUFF

H N 1

UNITS

DENDRALM

METADENDRAL

Abb. 3-3: Entwicklungslinien einzelner Expertensysteme (nach HARMON & KING, 1986, S. 106)

S. 1 M. 1

1

Angebotene Entwicklungssysteme

25

Diese Systeme sind teils aus domainspezifischen Expertensystemen unter Abzug der Wissensbasis entstanden, teils aus einer Programmierumgebung heraus in Integration spezieller Tools entwickelt worden. Abb. 3-3 zeigt die Entwicklungslinien einzelner Systeme. Die wichtigsten in der Literatur beschriebenen Entwicklungsumgebungen für Expertensysteme seien im folgenden kurz skizziert, wobei die Auswahl durchaus subjektiv sein mag. Die Beschreibung enthält eine knappe Charakterisierung sowie Angaben zur Repräsentations-Methodik und zur Implementationssprache. AGE Sammlung vielseitig einsetzbarer Tools, die sowohl die Systemstruktur (BlackboardArchitektur, Vorwärts-Rückwärts-Verkettung u. a.) als auch grundlegende Mechanismen (z. B. Produktionsregeln) unterstützen. Außerdem enthält es Komponenten zum Wissenserwerb, zur Fehlersuche und zur Erklärung. Implementationssprache: INTERLISP ART "Advanced Reasoning Tool". Expertensystem-Entwicklungsumgebung in hybrider Technik, das regelbasierte und prozedurale Methoden und Frames unterstützt. Es erlaubt Vorwärts- und Rückwärts-Verkettung, die Handhabung unsicheren Wissens und die Definition von "Hypothetischen Welten" als Kontext für die Anwendung von Fakten und Regeln. Außerdem enthält es die gebräuchlichen Fehlerhilfen und arbeitet mit Grafikunterstützung. Implementationssprache: LISP BABYLON Expertensystem-Entwicklunsumgebung in hybrider Technik, das verschiedene Wissensrepräsentationsmethoden vereinigt (objektorientiert) und mit intensiver Grafikunterstützung die gängigen Entwicklungskomponenten enthält. Es wird von der Gesellschaft für Mathematik und Datenverarbeitung (GMD) erstellt und ist das erste deutsche System, das den "State of the Art" auf diesem Gebiet zu verwirklichen versucht Implementationssprache: ZETALISP EMYCIN Anwendungsneutraler Systemrahmen für regelbasierte Diagnosesysteme, aus MYCIN entstanden. Das System enthält eine restriktive backward-chaining-Kontrollstrategie und unterstützt den Wissenserwerb und die Handhabung unsicheren Wissens

26

Aspekte der Entwicklung

(Konfidenzfaktoren). Die Erklärungskomponente ist sehr ausgeprägt. Nachfolger dieses Shells sind KS 300, S.l und M.l. Implementationssprache: INTERLISP EXPERT Expertensystem-Shell zur Entwicklung einfacher Diagnosesysteme, das am meisten verwandte System für medizinische Anwendungen. Es ist regelbasiert mit Vorwärtsverkettung und Konfidenzfaktoren und enthält Komponenten zur Fehlersuche, Erklärung, zum Wissenserwerb und zur Konsistenzüberprüfung. Implementationssprache: FORTRAN FRL "Frames Representation Language". Frame-orientiertes Wissensrepräsentationssystem mit Möglichkeiten zur objektorientierten Programmierung (Vererbung), für Constraints und zur Einbindung von Prozeduren. Implementationssprache: LISP HEARSEY-III Anwendungsneutrale Verallgemeinerung von HEARSEY-Ü, einem System zur Verarbeitung natürlicher Sprache mit Blackboard-Architektur. Es vereint regelbasierte Wissensrepräsentation mit einem "scheduler" zur Steuerung der Anwendung des domainspezifischen Wissens. Implementationssprache: LISP KEE "Knowledge Engineering Environment". Es vereint in hybrider Technik Frameorientierte, regelbasierte, prozedurale und objektorientierte Repräsentationsmechanismen und ist eine komfortable, grafikunterstützte Expertensystem-Entwicklungsumgebung. Es unterstützt den modularen Aufbau der Wissensbasis und bietet Vorwärts* und Rückwärts-Verkettung. Implementationssprache: LISP KES "Knowledge Engineering System". Ein Entwicklungssystem mit regelbasierter und Frame-orientierter Repräsentation, Backward-chaining, statistischer Verarbeitung nach Bayes* Theorem, Erklärungskomponente und Möglichkeiten zum Wissenserwerb. Implementationssprache: FRANZ LISP

Angebotene Entwicklungssysteme

27

LOOPS "LISP Object oriented Programming System". Experimentelle Programmierumgebung für die interaktive Entwicklung wissensbasierter Systeme mit der Integration regelbasierten, objektorientierten und datenorienterten ("active values") Programmierens in die Programmierumgebung von INTERLISP-D. Es wird durch ein komfortables Grafiksystem unterstützt. Implementationssprache: INTERLISP-D M.l Regelbasiertes Expertensystem-Shell in der Nachfolge von EMYCIN mit Backwardchaining und englisch-sprachiger Regeleingabe. Es enthält grafikunterstützte Fehlersuche, eine Eiklärungskomponente und automatische Anfragebehandlung bei lückenhafter Wissensbasis. M.1 ist eines der wenigen Systeme, das auf Personal Computern (IBM PC) lauffähig ist. Implementationssprache: PROLOG OPS Das meistbenutzte Entwicklungssystem für Expertensysteme, das seit 1977 kontinuierlich weiterentwickelt in verschiedenen Versionen vorliegt (OPS4, OPS5, OPS5e, OPS-83). Es ist ein regelbasiertes System mit Vorwärts-Verkettung und einer sehr leistungsfähigen Inferenzkomponente. Implementationssprache für OPS5: MACLISP, FRANZ LISP Implementationssprache für OPS5e: ZETALISP PERSONAL CONSULTANT Ein regelbasiertes Entwicklungssystem, das auch eine Frame-orientierte Repräsentation unterstützt. Es enthält Vorwärts- und Rückwärts-Verkettung, verarbeitet unsicheres Wissen, besitzt eine Vererbungshierarchie und ermöglicht den Zugriff auf LISP-Prozeduren. Das Benutzerinterface enthält Fenstertechnik auf einem Farbbildschirm, eine Erklärungskomponente, einen Wissenseditor auch für den Benutzerdialog und Testmöglichkeiten. Es läuft auf Personal Computern unter MS-DOS. Implementationssprache: IQLISP und PCScheme RLL Strukturierte Kollektion von Entwicklungs-Tools nach Art einer Metasprache zur Definition von Wissensrepräsentationssprachen. Es ist selbst ein Expertensystem mit dem Wissen über den Aufbau einer Wissensbasis und einer Sammlung von nützlichen Konstrukten für Repräsentation, Vererbungsmechanismen und Kontrollstrukturen. Die Wissensrepräsentation ist Frame-orientiert.

28

Aspekte der Entwicklung

Implementationssprache: INTERLISP ROSIE Ursprünglich regelorientiertes Allzweck-Entwicklungssystem mit Produktionsregeln in englisch-sprachiger Syntax, später in Richtung eines natürlichsprachlichen Wissenseingabe- und Repräsentationssystems weiterentwickelt mit der Unterstützung verschiedener Inferenzmechanismen, komfortabler Dialogschnittstelle, Erklärungskomponente und einem mächtigen Pattern matcher. Implementationssprache: INTERLISP SRL+ "Schema Representation Language". Frame-basiertes Entwicklungssystem, das logik- und objektorientierte Methoden unterstützt Es ermöglicht das Einbinden von Prozeduren und Bestimmen von Vererbungsbeziehungen, unterstützt einen AgendaMechanismus und enthält einen Sprachteil für Simulation und Grafik. Es wurde zu CRL ("Carnegie Representation Language") weiterentwickelt, das wiederum Bestandteil der Entwicklungsumgebung "Knowledge Craft" ist. Implementationssprache: LISP S.l Expertensystem-Shell in der Nachfolge von EMYCIN, aber komfortabler als M.l. Die Repräsentation ist regelbasiert, es unterstützt aber auch Frame-orientierte und prozedurale Methoden. Die Verkettung ist backward. Es enthält Konfidenzfaktoren, sog. "control blocks" zur Anbindung von Prozeduren, eine Erklärungskomponente und grafikunterstützte Fehlerbehandlung. Implementationssprache: INTERLISP TIMM Entwicklungs-Tool für den Fachmann eines Anwendungsgebietes, der selbst ein Expertensystem erstellen möchte. Anhand von Beispielen erstellt das System einen Entscheidungsbaum und formuliert Regeln für die Wissensbasis, Konfidenzfaktoren sind möglich. Das System ist auch für Personal Computer (IBM PC) verfügbar. Implementationssprache: FORTRAN TWAICE "True Wisdom Artificial Intelligence & Computerized Expertise". Regelorientiertes Entwicklungssystem nach dem MYCIN-Paradigma deutscher Produktion. Es ist ein rückwärtsverkettendes System mit Vorwärtsregeln, enthält eine Erklärungskomponente und ermöglicht die natürlichsprachliche Eingabe der Regeln mit automatischer

Angebotene Entwicklungssysteme

29

Umformung in die interne Repräsentation (Objekt-Attribut-Wert-Tripel) und die Darstellung hierarchischer Objektbeziehungen durch einen Objektbaum. Außerdem können Textmodule für eine verständliche Gestaltung des Dialogablaufs erstellt werden. Es ist besonders für die Bereiche Diagnose und Klassifikation geeignet. Implementationssprache: PROLOG

4. Bewertungskriterien für Entwicklungssysteme Da später ausgewählte Expertensystem-Entwicklungsumgebungen miteinander verglichen und bewertet werden sollen, werden in diesem Kapitel Kriterien für die Bewertung solcher Systeme erarbeitet, indem die einzelnen Komponenten eines Expertensystems beschrieben und in ihrer Bedeutung für die Funktionstüchtigkeit und Bedienungsfreundlichkeit gewürdigt werden.

4.1 Wissensbasis und -repräsentation 4.1.1 Einleitung "In the knowledge lies the power" {FEIGENBAUM, 1977) ist die wichtigste Erkenntnis beim Umgang mit Problemen der Künstlichen Intelligenz seit Beginn der siebziger Jahre, als sich das Navigieren in großen Problemlöseräumen mit Hilfe heuristischer Suchmethoden als alleiniges Paradigma als ungenügend herausstellte. Daher ist die Wissensrepräsentation eines der zentralen Designprobleme. Der Begriff "Wissen" soll den Unterschied zu Daten in konventionellen Programmen - bei der Möglichkeit gleitender Übergänge - kennzeichnen. Wissen beinhaltet in seiner Repräsentation gleichzeitig Metawissen über den Gebrauch des Wissens (z. B. durch Angabe der Relation zwischen Argumenten). Durch logische Ableitung kann neues Wissen erschlossen werden. Daten können zwar auch weiterverarbeitet werden, der Algorithmus dafür ist aber von den Daten (bis auf deren Typ) unabhängig.

/

;

"N

Wissen semantisches lexikalisches

episodisches

enzyklopädisches

V Abb. 4-1: Klassifikation von Wissen (nach HABEL,

1985, S. 444)

J

32

Wissensbasis- und repräsentation

Eine aus der kognitiven Psychologie abgeleitete Klassifikation von Wissen ist in Abb. 4-1 dargestellt. Episodisches Wissen bezieht sich auf die situationsbezogene Erfahrung eines einzelnen, während das semantische Wissen das "Wissen einer Sprachgemeinschaft" umfaßt. Beim letzteren wird zwischen lexikalischem - Definition und Erklärung einzelner Begriffe - und enzyklopädischem Wissen ("Weltwissen") unterschieden. Die Darstellung enzyklopädischen Wissens ist in einem Expertensystem wegen des Umfanges am schwierigsten, obwohl gerade im Bereich natürlichsprachlicher Systeme das Verständis einer Aussage vom Kontext - auch im weitesten Sinne - abhängig ist. Am besten werden eng umrissene, fachbezogene Wissensgebiete verarbeitet, wobei aber das System, sollte es an seine Wissensgrenzen stoßen, über seine eigenen Beschränkungen informiert sein sollte ("Metawissen"), womit ein Schritt in Richtung "Weltwissen" erforderlich werden könnte. Der Systemkern besteht - wie bereits in Abschnitt 2.1 beschrieben - aus der Wissensbasis und dem bereichsunabhängigen Inferenzsystem. Die Wissensbasis wiederum läßt sich während der Konsultation des Expertensystems in drei Bereiche unterteilen: • Das bereichsspezifische Expertenwissen, das im Prozeß des Knowledge engineering eingegeben wird und sich im Verlauf der Konsultation (meist) nicht ändert. Auf diesen Teil bezieht sich das Thema der Wissensrepräsentation. • Das fallbezogene Faktenwissen, das der Benutzer im Laufe einer Konsultation eingibt. • Die Zwischen- und Endergebnisse, die das System durch seinen Inferenzmechanismus logisch ableitet und dem Benutzer anzeigen kann. Das bereichsspezifische Expertenwissen kann im Prinzip durch eine einzige Form der Darstellung, nämlich durch Regeln (Produktionsregeln), abgebildet werden. Viele Systeme beschränken sich auf diese Repräsentationsart. Jede andere Form der Wissensrepräsentation ist eine konzeptionelle Erweiterung zur Annäherung an menschliche Denkabläufe und Gedächtnismechanismen und unterstützt den Dialogpartner durch eine ihm angenäherte Systemoberfläche, bietet aber keine höhere Mächtigkeit bezüglich der Problemlösefähigkeit Häufig wird die Darstellung von Wissen unter zwei gegensätzlich erscheinenden Aspekten betrachtet, nämlich prozedural vs. deklarativ. Die prozedurale Darstellung betont mehr den aktiven Gebrauch des Wissens in Form von Anweisungen und wird

Einleitung

33

mit dem regelorientierten Paradigma in Verbindung gesetzt, da der Aktionsteil einer Regel als "Prozedur" verstanden werden kann. Der deklarative Aspekt betont mehr die passive Beschreibung eines Zustandes und lehnt sich damit an die Idee der Objekt* und Frameorientierten Darstellung an. Beide Aspekte der Wissensdarstellung ergänzen sich aber und sind - mit unterschiedlichem Akzent - in jeder Repräsentationsform enthalten. Die vorgenannte Unterscheidung hat auf der Ebene der Wissensbasierten Systeme ihre Gültigkeit. Gehen wir von den höheren Programmiersprachen und dem allgemeinen Ablauf von Programmen aus, lassen sich zwei Arten der Programmierung unterscheiden: • Der imperative bzw. prozedurale Stil, der einen Programmablauf in Form einer Sequenz von Anweisungen gestaltet. Hier könnten wir uns ein konventionelles Pascal-Programm vorstellen. • Der deskriptive Programmierstil beschreibt ein Problem (z. B. in Form von Regeln und Fakten) und erschließt die Lösung durch logische Schlußfolgerungen. Dies ist die Methode der Wissensbasierten Systeme einschließlich der Sprache PROLOG. Diese beiden Sprachregelungen können leicht zur Verwirrung beitragen, deshalb bedürfen sie einer grafischen Verdeutlichung (Abb. 4-2):

prozedural Numerische Datenverarbeitung Höhere Programmiersprachen

» deskriptiv Wissensbasierte Systeme

deklarativ Frames, Objekte, Units, usw.

prozedural Regeln

Ebene der Programmiersprachen

Ebene der Wissensrepräsentation

Abb. 4-2: Arten der Programmierung Im Bereich der Wissensrepräsentation existieren verschiedene Repräsentationsformen, die eigentlich unterschiedliche Programmierstile darstellen. Logische Ableitungen lassen sich nur auf Regeln anwenden. Die darüber hinausgehenden Darstellungsarten dienen zum einen der besseren Strukturierung größerer Regelmengen, die für eine

34

Wissensbasis- und repräsentation

Übersichtlichkeit und Verständlichkeit von entscheidender Bedeutung ist Außerdem lassen sich "Tiefenstrukturen" von Wissen in Form von Hierarchien und Beziehungsstrukturen darstellen und andere Prinzipien der Programmierung einbinden. Eine objektorientierte Repräsentation eignet sich gut für die Simulation von Systemabläufen (z. B. Fabrikationsprozesse), vor allem in Verbindung mit grafischen Gestaltungsmöglichkeiten, obgleich dies kein typisches Anwendungsfeld für Expertensysteme darstellt. Soll aber in diesem System eine logische Ableitung vorgenommen werden, wie es bei einer Konsultation üblich ist, so muß das Wissen ebenfalls in Regeln abgebildet sein, wobei jede Regel einem Objekt als Methode zugewiesen sein muß. Es kann vorteilhaft sein, wenn ein Expertensystem Zugriff auf eine exteme Datenbank besitzt. Deshalb werden für viele Systeme Schnittstellen angeboten, die eine Datenbankanfragesprache besitzen. Umgekehrt können Datenbanken eine wissensbasierte Dialogkomponente enthalten, die den Benutzer bei seinen Anfragen unterstützt.

4.1.2 Regelorientierte Wissensrepräsentation Eine Regel hat für gewöhnlich folgende Form: WENN (Prämisse) DANN (Konklusion). Sowohl die Prämisse als auch die Konklusion können Einzelaussagen oder Konjunktionen von Einzelaussagen sein, wie z. B. WENN AI UND A2 UND..UND An DANN B. Disjunktionen von Aussagen sind in manchen Systemen in der Prämisse zugelassen, diese können aber dadurch umgangen werden, daß die Regel mehrfach formuliert wird: WENN AI ODER A2 DANN B entspricht WENN AI DANN B; WENN A2 DANN B. In der Konklusion hingegen sind keine Disjunktionen erlaubt.

Regelorientierte Wissensrepräsentation

35

Die Prämisse einer Regel wird auch als LHS ("left hand side"), die Konklusion als RHS ("right hand side") bezeichnet, eine gegenüber den unterschiedlichen Verkettungsrichtungen etwas neutralere Betrachtungsweise. Regelorientierte Systeme werden auch als Produktionssysteme bezeichnet, ein häufig verwendeter Begriff, weshalb er hier näher erläutert werden soll. Ein Produktionssystem umfaßt drei Teile: • Eine Menge von Regeln (Produktionsregeln oder Produktionen), deren linker Teil ihre Anwendbarkeit und deren rechter Teil die Auswirkung nach ihrer Anwendung beschreibt. • Eine Datenbasis, die eine Menge von Fakten zur Beschreibung einer konkreten Situation enthält, die entweder überdauernd im System verbleiben oder temporär während einer Konsultation eingegeben oder abgeleitet werden. • Ein Kontrollssystem für die Anwendung der Regeln, das den Lösungsweg möglichst effizient beschreitet und im Konfliktfalle bestimmt, welche Regel als nächste ausgeführt werden soll. Produktionssysteme liefern also eine vollständige Struktur, die in Zusammenhang mit Problembeschreibungen den Lösungsprozeß ermöglichen und unterstützen. Die Kontrollstrategien werden im nächsten Abschnitt (4.2) eingehend behandelt, während hier mehr auf die generelle Aufstellung und Anwendung von Regeln eingegangen wird. RICH (1983, S. 27ff.) beschreibt ein für die Anfänge der KI-Forschung charakteristisches, einfaches Beispiel, nämlich das Wasserkrug(water jug)-Problem. Zwei Krüge mit drei und vier Litern Inhalt sollen ohne weitere Meßmöglichkeiten so mit Wasser ge- und umgefüllt werden, daß im 4-Liter-Krug schließlich zwei Liter Wasser enthalten sind. Zur formalen Beschreibung wird der 4-Liter-Krug mit X, der 3-Liter- Krug mit Y bezeichnet, der Inhalt beider Krüge mit Zahlen in Klammern. Der Ausgangszustand ist dann (0,0), der Endzustand (2,0). Die Produktionsregeln aller möglichen Aktionen sind in Abb. 4-3 dargestellt.

Wissensbasis- und repräsentation

36

1 (X.Y 1 X0) — • (X.Y-D) Pour some water out of the 3-gallon jug (X, Y 1 X>0) - (O.Y) Empty the 4-gallon jug on the ground Empty the 3-gallon jug (X.Y 1 Y>0) - (X.O) on the ground Pour water from the (X.Y 1 X + Y > = 4 A Y>0) (4,Y — (4 — X)) 3-gallon jug into the 4-gallon jug until the 4-gallon jug is full (X.Y I X + Y > = 3 A X>0) -> Pour water from the (X- (3 -Y),3) 4-gallon jug into the 3-gallon jug until the 3-gallon jug is full (X,Y I X + Y < = 4 A Y>0) -* Pour all the water (X+Y.O) from the 3-gallon jug into the 4-gallon jug (X.Y I X + Y < = 3 A X>0) -» Pour all the water (0,X+Y) from the 4-gallon jug into the 3-gallon jug - »

(4. Y) (X, 3) (X-D.Y)

Abb. 4-3: Produktionsregeln des Wasserkrug-Problems (Quelle: RICH, 1983, S. 28)

Den Lösungsweg können wir uns als einen Baum dargestellt vorstellen, der als Knoten alle möglichen Zustände enthält. Abb. 4-4 zeigt den Lösungsbaum, der bis zur zweiten Ebene alle möglichen Nachfolgeknoten aufzeigt, dann aber nur noch einen relevanten Weg verfolgt Die Kontrollstrategie, die im Inferenzsystem enthalten ist, sorgt für die richtige Auswahl und Anwendung der Regeln (in unserem Fall der Regeln 2, 9, 2, 7, 5, 9), bis das Problem einer Lösung zugeführt worden ist. Allgemein gesagt, arbeitet ein Produktionssystem nach folgendem Zyklus: 1. Durch Mustervergleich (Pattern matching) wird eine anwendbare Regel aus der Wissensbasis ausgesucht. Existieren mehrere anwendbare Regeln, entscheidet die Kontrollstrategie über die Auswahl (Konfliktlösung).

Regelorientierte Wissensrepräsentation

37

2. Der Regelinterpreter bringt die ausgewählte Regel zur Anwendung, d. h. die Regel "feuert". 3. Wenn der Zielzustand erreicht ist, terminiert das Produktionssystem. Sonst weiter bei 1. Diese Schritte werden als recognize-act-Zyklus bezeichnet Ist keine Regel mehr anwendbar, terminiert das System.

Abb. 4-4: Lösungsbaum zum Wasserkrug-Problem Die einzelnen Aussagen innerhalb einer Regel können als "assoziative Tripel" vom Typ Objekt-Attribut-Wert aufgefaßt werden. Die Konklusion der Regel 2 des obigen Wasserkrug-Problems besagt z. B., daß der 3- Liter-Krug Y mit Wasser gefüllt ist: Objekt: 3-Liter-Krug Y Attribut: Wasser-Inhalt Wert: drei Liter

38

Wissensbasis- und repräsentation

Diese Art der Darstellung ist insbesondere für Frames typisch (s. Abschn. 4.1.3.2), bei denen oft mehrere Attribute einem Objekt zugeordnet sind. Eine erweiterte Darstellungsform ist die "strukturierte" Regel {PUPPE, 1986). Sie enthält in der Prämisse neben den (konjunktiv verknüpften) Aussagen Aktivierungsbedingungen (Randbedingungen, Schwellwerte usw.) und eine Liste von Ausnahmefällen mit den zugehörigen Defaultwerten. Eine spezielle Art der Darstellung von Aussagen in Regeln und der logischen Ableitung fußt auf der Prädikatenlogik 1. Stufe und wird in PROLOG verwandt. Dies wird häufig als "logische Programmierung" bezeichnet Es gibt regelorientierte Expertensysteme, die in PROLOG geschrieben sind, aber eine der natürlichen Sprache angelehnte Eingabe gestatten. Da intern die Repräsentation des Wissens ebenfalls in Form der Prädikatenlogik erfolgt, sei auf die hier relevante Teilmenge eingegangen. Wie bereits erwähnt, besteht die Datenbasis aus Fakten und Regeln. Fakten werden in Form einer einzelnen Aussage (Atom) dargestellt, die eine Beziehung oder eine Eigenschaft beschreibt und ein Prädikat, gefolgt von einer Liste von Argumenten, enthält: Prädikat (Argumentl Argument2 Argument3...) Das Prädikat beschreibt die Beziehung zwischen den Argumenten (Parametern) und korrespondiert mit dem Verb (Prädikat!) eines Satzes, während die Argumente mit den Substantiven (Subjekt, Objekt) korrespondieren. Die Aussage "Franz liebt Fußball" wird prädikatenlogisch ausgedrückt durch: liebt (Franz Fußball). Das Prädikat ist ein Wort. Die Argumente der Liste sind Einzelausdriicke (Terme) und dürfen ein Wort, eine Zahl, eine Variable oder eine Liste sein. Die eben dargestellte Aussage liegt in Präfix-Notation vor, da das Prädikat am Anfang steht Diese Form der Darstellung läßt eine beliebige Anzahl von Argumenten zu. Bei bestimmten Aussagen sind aber noch zwei weitere Darstellungsformen zugelassen: • Infix-Notation: Diese ist bei einer Liste mit zwei Argumenten (wie oben) gestattet, "liebt (Franz Fußball)" ist also äquivalent zu "Franz liebt Fußball".

Strukturierte Wissensrepräsentation

39

• Postfix-Notation: Es liegt nur ein Argument vor. "raucht (Franz)" entspricht der Darstellung "Franz raucht". In dieser Notation wird das Prädikat auch "Eigenschaft" (property) genannt. Bei mehr als zwei Argumenten muß die Präfix-Notation gewählt werden. Regeln werden derart gebildet, daß die Prämisse eine oder mehrere konjunktiv verknüpfte Aussagen (Atome) enthält und die einelementige Konklusion vorangestellt wird. Spezielle Anfragen an ein PROLOG-System arbeiten nach Art eines Theorembeweisers unter Anwendung der Rückwärts-Verkettung mit Backtracking. Dabei gilt die Negation einer Formel als bewiesen, wenn die Formel selbst nicht bewiesen werden kann. Die Ausdrucksfähigkeit der Prädikatenlogik ist beschränkt, dafür können auf ihr basierende Systeme aber bis zu einem gewissen Ausmaß effizient arbeiten. Insgesamt gesehen sind regelbasierte Systeme, die seit Entstehung der ersten Expertensysteme angewandt werden, einfach zu handhaben und bieten den Vorteil, daß eine Erklärungskomponente leicht zu verwirklichen ist. Unter anwendungsorientiertem Gesichtspunkt betrachtet, ermöglichen sie dem Entwickler schnelle und praktikable Erfolge. Andererseits muß gesagt werden, daß seit längerem keine prinzipiellen Neuerungen und Weiterentwicklungen zu verzeichnen sind und das Paradigma weitgehend ausgereizt zu sein scheint. Neuere Ideen, die sowohl die interne Repräsentation als auch die Benutzeroberfläche betreffen, sind vielmehr im Bereich der objektorientierten Darstellung zu finden.

4.1.3 Strukturierte Wissensrepräsentation Dieser Abschnitt umfaßt drei Bereiche: Semantische Netze, Frames und die objektorientierte Darstellung. Die Bezeichnung "Strukturierte Wissensrepräsentation" wurde in Anlehnung an RICH (1983) gewählt Es ist zwar auch in Produktionssystemen eine Strukturierung der Regeln möglich, diese Sruktur wird dann aber von außen herangetragen und liegt nicht in der Natur der Regeldarstellung begründet. Mit der Einführung der Idee von den Semantischen Netzen wurde eine prinzipiell neue Klasse von Formalismen zur Wissensrepräsentation geschaffen und stellt in ihrer Konkretisierung (Frames, objektorientierte Darstellung) ein Paradigma dar, das seit Beginn der 80er Jahre einen Fortschritt in Richtung vertiefter Abbildung von Struktur und Funktion von Wissen und dessen temporaler und kausaler Beziehungen

40

Wissensbasis- und repräsentation

ermöglichte. Damit wuchs die Wissenserfassung über eine Anhäufung von Einzelaussagen hinaus.

4.1.3.1 Sematische Netze Semantische Netze spiegeln die Struktur des menschlichen Gedächtnisses wider und sind aus den Konzepten der kognitiven Psychologie entstanden. Das menschliche Gedächtnis ist kein "random access"-Speicher, in dem ein wahlfreier Zugriff auf einzelne Elemente erfolgt, sondern nach Art eines Assoziativspeichers organisiert, wobei hierarchische Bedeutungsklassen gebildet werden, deren Elemente durch assoziative Relationen veibunden sind. Ein Semantisches Netz ist von seiner Struktur her ein gerichteter Graph, der eine Menge von Knoten enthält, die Objekte, Konzepte oder Ereignisse repräsentieren. Die Knoten sind durch benannte Kanten veibunden, wodurch die binären Relationen zwischen ihnen beschrieben werden. Vom Prinzip her kann jede sprachliche Aussage in einem Semantischen Netz dargestellt werden, wobei sich eine "unendliche" Menge von Relationen ergeben kann. In der praktischen Realisierung werden die Möglichkeiten konzeptuell stark eingeschränkt. COLLINS & QUILLIAN (1969) entwickelten einen einfachen Typ von Netzen, der im Prinzip allgemeine Anwendung fand. In diesen Netzen existieren zwei Arten von Knoten: • "Konzepte", die eine hierarchische Organisation verkörpern und auch "individuelle Ausprägungen" enthalten können, und • "Eigenschaften", die den Konzept-Knoten zugeordnet sind. Die Kanten drücken zwei Arten von Beziehungen aus: • "is-a" drückt die Verbindung eines Knotens zum übergeordneten, generalisierenden Konzept aus und kann als Klassen-Instanzen-Relation verstanden werden. Dabei schließt diese Relation auch individuelle Ausprägungen ein, die in anderen Darstellungen als "instance-of'- oder "member-of'-Relationen getrennt behandelt werden. • "has-prop", auch als "has-a" oder "part-of' bezeichnet, ordnet Konzepten Eigenschaften zu. Diese können auch Teile oder Funktionen beinhalten.

41

Semantische Netze

Die wesentliche Neuerung in der hierarchischen Abbildung der Semantischen Netze ist der Vererbungsmechanismus, der auch für die nachfolgenden Konzepte der Wissensrepräsentation (Frames, Objekte) entscheidende Bedeutung hat. Eigenschaften generellerer Strukturen werden auf "tieferliegende" Konzepte übertragen. Abb. 4-5 zeigt als Beispiel ein Semantisches Netz aus dem Tierreich.

Abb. 4-5: Beispiel eines Semantischen Netzes (nach HABEL,

1985, S. 451)

Wie aus dem Beispiel des Vogels Strauß hervorgeht, können Vererbungen auch blockiert werden. Dies entspricht durchaus der menschlichen Konzeptbildung, die sich in dem Sprichwort ausdrückt: "Ausnahmen bestätigen die Regel." Interessant ist, daß sich die Nähe zur menschlichen Denkweise durch ReaktionszeitUntersuchungen bestätigen ließ. Collins & Quillian stellten fest, daß Probanden die Frage "Sind Kanarienvögel gelb?" schneller bejahten als die Frage "Können Kanarienvögel fliegen?". Dies liegt daran, daß im Gedächtnis eine direkte Verbindung "Kanarienvogel-gelb" vorliegt, während bei der Frage nach dem Fliegen erst auf das höhere Konzept "Vogel" zurückgegriffen werden muß.

42

Wissensbasis- und repräsentation

Eine Wissensrepräsentation in Form von Semantischen Netzen hat direkt in Expertensysteme und ihre Entwicklungsumgebungen keinen Eingang gefunden. Sie dient vielmehr als konzeptuelle Grundlage der Frame- und objektorientierten Darstellung. Im Bereich sprachverarbeitender Systeme wird diese Repräsentationsform eher angewandt und führt zur Abbildung sematischer Tiefenstrukturen. Die stark deklarative Wissensrepräsentationssprache KLONE (BRACHMAN et al„ 1978) stellt einen Versuch der Anwendung dieses Konzepts insbesondere im Bereich der Textverarbeitung dar.

Sentence:

Bill told Laura t h a t h e gave Judy a g i f t .

Abb. 4-6: Semantisches Netz eines englischen Satzes (Quelle: WATERMAN, 1985, S. 73)

Obwohl die Abbildung sprachlicher Strukturen auf Semantische Netze für das vorliegende Thema nicht relevant ist, sei zur Veranschaulichung dennoch in Abb. 4-6 die Repräsentation eines komplexen englischen Satzes vorgestellt.

Frames

43

4.1.3.2 Frames Greift man aus einem Semantischen Netz einen Knoten, der ein Objekt, Konzept oder Ereignis repräsentiert, heraus und sucht nach einer geeigneten Darstellungsart, die eine Beschreibung der hierarchischen Beziehungen und der Eigenschaften einschließt, so bietet sich das Konzept der "Frames" an, das eine Erweiterung der Property-Listen in LISP darstellt. MINSKY entwickelte diese Idee in Zusammenhang mit der Erfassung visueller Informationen, Beschreibung von Szenen und Lernen durch Beispiele und schuf somit ein Werkzeug zur strukturierten Wissensrepräsentation. Er beschreibt (1975, S. 212) dieses Konzept wie folgt: "Eine Frame ist eine Datenstruktur zur Darstellung gleichförmiger Situationen. Zu jedem Frame gehören unterschiedliche Arten von Information. Einige dieser Informationen geben Auskunft darüber, wie der Frame benutzt wird. Andere besagen, was als nächstes zu erwarten ist. Wiederum andere besagen, was zu tun ist, wenn sich diese Erwartungen nicht bestätigen sollten. Wir können uns ein Frame als ein Netz von Knoten und Beziehungen vorstellen." Die einzelnen Informationen der "Wissenseinheit" werden im Frame in sog. "slots" abgelegt. Slots sind benannte Platzhalter, die aktuellen Belegungen heißen "fillers" oder "entries". Für die Einträge können Typdefinitionen und Wertebereiche vorgegeben werden. Weitere Möglichkeiten einer Belegung: Defaultwerte, Zeiger auf andere Frames, Regelmengen, Active values und Prozeduren. Die letzten beiden Möglichkeiten werden in Abschnitt 4.1.5 behandelt Frames werden häufig als eine Menge von Objekt-Attribut-Wert-Tripeln beschrieben (s. Absch. 4.1.2), wobei der Frame das Objekt darstellt, die Slots die Attribute, die die zugehörigen Werte aufnehmen. Jeder Slot kann eine beliebige Anzahl von Prozeduren enthalten (procedural attachment). Drei nützliche Arten von Prozeduren sind häufig mit einem Slot verbunden und werden bei Bedarf aktiviert:

44

Wissensbasis- und repräsentation

Vogel Eintrag

Slot Oberbegriff

TIER

Unterklassen

ZUGVOGEL, SCHWIMMVOGEL, SINGVOGEL if-added, benutze Subframe

Fortbewegungsart

BEREICH: fliegen, laufen, schwimmen DEFAULT: fliegen

Heimat

BEREICH: Europa, Afrika DEFAULT: Europa if-needed, falls ZUGVOGEL, dann Sommer: Europa, Winter: Afrika

Körperteile

Flügel, Schnabel, ...

Abb. 4-7: Frame für das Objekt "Vogel" (nach HABEL, 1985, S. 460) • if-added: Falls der Slot instantiiert ist, wird bei Eintrag eines Wertes eine vorgegebene Aktion ausgeführt. • if-needed: Sollte der Slot instantiiert werden, wird hier seine zukünftige mögliche Belegung mitgeteilt. • if-removed: Falls die Informations des Slots gelöscht werden sollte, wird eine vorgegebene Aktion ausgeführt In Abb. 4-7 ist ein Frame für das Objekt "Vogel" als Beispiel dargestellt Ein Frame kann im Prinzip eine beliebige Menge von Slots enthalten. Durch den Zeiger auf konzeptuell übergeordnete Frames werden Strukturen ererbt, d. h. der neue Frame erhält die Slots und Belegungen (z. B. Defaultwerte) "seines" Klassen-

Objektorientierte Repräsentation

45

Frame. Diese ererbten Strukturen können verändert und erweitert werden, so daß auch eine Blockierung der Vererbung möglich ist. Allerdings ist diese Möglichkeit der Vererbung nicht in allen Systemen gegeben, die eine Frame-artige Wissensrepräsentation erlauben. In diesen Fällen wird nur auf die Darstellung von Objekt-Attribut-Wert-Tripeln in Frames Bezug genommen.

4.1.3.3 Objektorientierte Repräsentation Die objektorientierte Programmierung hat in der Darstellung der "Objekte" Ähnlichkeit mit dem Konzept der Frames. Objekte sind benannte Wissens- oder Programmeinheiten, die eine interne Struktur nach Art eines abstrakten Datentyps besitzen. Ihre Struktur ist dabei allgemeiner als die der Frames, nicht nur auf "Objekt-Attribut- Wert-Tripel" bezogen. Es existiert ebenfalls eine Hierarchie von Klassen und Instanzen, die eine Vererbung ermöglicht. Das entscheidend neue an diesem Konzept liegt darin begründet, daß die einzelen Objekte über Nachrichten ("messages") miteinander kommunizieren. Sendet ein Objekt eine Nachricht an ein anderes Objekt, z. B. die Aufforderung, den Wert einer Variablen zurückzuliefern, so werden beim Adressaten "Methoden" aktiviert, die das gewünschte Resultat liefern. Der Sender braucht dabei nicht zu wissen, wie der Empfänger intern die Nachricht verarbeitet. Dieser kann seinen internen Zustand ändern, eine Nachricht zurücksenden oder andere Objekte einbeziehen. Das Senden einer Nachricht könnte mit einem Unterprogramm- oder Prozeduraufruf in konventionellen Programmiersprachen einschließlich Parameterübergabe verglichen werden. Spezifisch ist hier aber die "Autonomie" der einzelnen Objekte und die Möglichkeit der Vererbung von Methoden. Die objektorientierte Programmierung bietet damit in erster Linie eine neue Sicht der Informationsverarbeitung. In der Hierarchie der Objekte gibt es zwei Arten von Verwandschaftsbeziehungen: • Element-Beziehung, die sich auf die Relation zwischen einem Element und seiner Klasse bezieht, und • Teilklasse-Beziehung, d. h. die Relation zwischen Klasse und Oberklasse.

46

Wissensbasis- und repräsentation

Ein Objekt wird als Instanz (Inkarnation) einer Klasse gebildet, indem an diese eine Erzeugungsnachricht gesendet wird. Damit erbt das neugebildete Objekt die interne Struktur einschließlich der Verarbeitungsmethoden. In einer Variante der objektorientierten Programmierung (ATC-1) gibt es keine besonderen Klassenobjekte in einer hierarchisch höher gelegenen Ebene, sondern jedes Objekt kann in Form eines Prototyps Kopien seiner selbst bilden. Die Programmierung in einem objektorientierten System besteht im Definieren von Klassen, Erzeugen von Instanzen dieser Klassen und Senden von Nachrichten an diese Instanzen. Die Entwicklung der objektorientierten Programmierung aus dem Klassenkonzept heraus verlief unabhängig vom Konzept der Frames, obwohl von der Idee der Repräsentation her Ähnlichkeit besteht und heutige, sog. hybride Entwicklungssysteme beide Konzepte vereinen und die Objekte häufig als "Frame" bezeichnen. In der Programmiersprache SIMULA wurde zum ersten Mal das Klassenkonzept mit seiner hierarchischen Ordnung verwendet 1969 erweiterte dann A. Kay dieses Konzept um die Kontrollstruktur des Nachrichtenaustausches. Es entstand die Sprache SMALLTALK, die von XEROX in verschiedenen Versionen herausgegeben und schließlich zur Programmierumgebung LOOPS weiterentwickelt wurde. Eine zweite Entwicklungslinie wurde von C. Hewitt 1972 gebildet, dessen Actor- Modell in den Sprachen PLANNER, PLASMA und ACT-1 weiterentwickelt wurde. Die objektorientierte Darstellung geht somit über den Bereich der Wissensrepräsentation hinaus und bildet ein Konzept, das für spezielle Programmstrukturen wie Simulation, Blackboard-Architektur usw. geeignet ist, läßt sich aber auch in eine Expertensystem-Entwicklungsumgebung mit Gewinn integrieren und schließt in diesem Falle das Konzept der Sematischen Netze und der Frames mit ein. Ein in diesem Programmierstil entwickeltes System zeichnet sich durch Verständlichkeit, Überschaubarkeit und Modularität aus. Objektorientierte Entwicklungsumgebungen sind ausnahmslos in LISP geschrieben, wovon einige bedeutende Dialekte erwähnt seien: • FRANZ LISP: KBS, ein Entwicklungstool, das Frames und Simulationsmodelle mit einschließt; ROSS, eine Systementwicklungsumgebung einschließlich Simulation;

Darstellung unsicheren und vagen Wissens

47

• INTERLISP-D: LOOPS, ein Entwicklungstool (s. Abschnitt 5.1); STROBE, eine Entwicklungsumgebung; • ZETALISP: FLAVORS, eine Systementwicklungsumgebung. In Zusammenhang mit diesem Konzept (d. h. schon mit SMALLTALK) wurde eine Benutzerschnittstelle geschaffen, die sehr populär wurde und zu den modernsten Hilfsmitteln gehört: Die Verwendung hochauflösender Grafikbildschirme mit Fenstertechnik ("windows") und Pointing devices ("Maus").

4.1.4 Darstellung unsicheren und vagen Wissens Bisher wurde bei der Darstellung und Verarbeitung von Wissen stets von einer zweiwertigen Logik ausgegangen: Eine Aussage ist entweder richtig oder falsch, eine andere Möglichkeit gibt es nicht. Sowohl im Bereich eines Experten als auch im Alltagsverständnis ist Wissen allerdings nicht immer vollständig, eindeutig und gesichert. Es gibt Aussagen wie "vielleicht", "wahrscheinlich", "es könnte sein", die in der Wissensbasis berücksichtigt und durch das Inferenzsystem bearbeitbar sein sollten, weil sonst wesentliche Teile der Expertenkompetenz verloren gingen. Zur Erweiterung der Darstellungsmöglichkeit könnte eine dreiwertige Logik folgende Werte annehmen: "wahr", "vielleicht", "falsch". Selbst diese Darstellung ist noch zu eingeschränkt, so daß sich die sog. "mehrwertige Logik" durchgesetzt hat, die alle Werte zwischen 0 und 1 bzw. zwischen -1 und +1 zuläßt An Fakten und Regeln, die mit derart ungesichertem Wissen arbeiten, wird der entsprechende Wert angefügt Eine solche Art der Darstellung ist für folgende Fälle denkbar: • Eine Aussage ist mit Unsicherheit behaftet (z. B. Wettervorhersage). • Zwischen mehreren Attributen besteht eine ungesicherte, nicht eindeutige Beziehung (z. B. Symptom - Krankheit). • Wissen ist unvollständig. • Einzelne Fakten sind unbekannt. In solchen Fällen könnten Defaultwerte angegeben werden (z. B. der Mittelwert einer Stichprobe als Schätzwert).

48

Wissensbasis- und repräsentation

In den genannten Fällen kann das Modell der Konfidenzfaktoren (Certainty Factors, auch Gewißheits- oder Evidenzfaktoren genannt) oder des Probabilistischen Schließens (Bayes'sches Theorem) Anwendung finden. • Eine Aussage ist vage und unscharf und wird von verschiedenen Personen unterschiedlich interpretiert (z. B. jemand sei "ziemlich jung"). Eine Darstellung und Verarbeitung solcher Aussagen wird durch die Fuzzy-Logik ermöglicht.

4.1.4.1 Certainty Factors Die am häufigsten gebrauchte Methode, das Ausmaß an Gewißheit einer Aussage auszudrücken, wurde für das Expertensystem MYCIN entwickelt und wird durch das Modell der Gewißheits- bzw. Konfidenzfaktoren (Certainty Factors, CF) beschrieben. Eine Regel aus dem medizinischen Bereich soll ausdrücken, mit welcher Gewißheit auf eine Krankheit geschlossen werden kann, wenn ein bestimmtes Symptom beobachtet wird. Dies könnte folgendermaßen ausgedrückt werden: WENN E DANN (Hmitx%). E stellt die Bedingung (Evidenz, Symptom), H die Hypothese (Krankheit) mit Angabe der Auftretenswahrscheinlichkeit dar. Die Regel kann als bedingte Wahrscheinlichkeit aufgefaßt werden, nämlich als den Anteil der Elemente aus E mit dem Merkmal H an der Gesamtmenge mit dem Merkmal E. Die Beziehung zwischen E und H könnte statistischen Erhebungen entnommen werden, wie dies z. B. im Bayes'schen Theorem geschieht Im Modell der Konfidenzfaktoren wurden dagegen von Medizinern Schätzungen erbeten, da eine statistische Erhebung Nachteile aufweist und vor allem nicht der Denkweise von Experten entspricht. Der Wertebereich der Schätzungen und damit des Konfidenzfaktors CF bewegt sich zwischen +1 und -1: CF = 1 Wenn E, dann ganz sicher H. CF = 0 Es besteht kein Zusammenhang. CF =-1 Wenn E, dann garaniert nicht H.

Certainty Factors

49

Eine - häufig zitierte - Regel würde dann folgendermaßen lauten (BUCHANAN & SHORTLIFFE, 1984, S. 238): IF: 1) The stain of the organism is gram positive, and 2) The morphology of the organism is coccus, and 3) The growth conformation of the organism is chains THEN: There is suggestive evidence (.7) that the identity of the organism is streptococcus. In einer Wissensbasis sind hunderte solcher Regeln gespeichert (MYCIN: 800 Regeln). Bei einer Schätzung werden nun die bestätigenden (E+) und die widerlegenden Anzeichen (E-) für die Hypothese H eingegeben. Dies ergibt zwei Werte mit dem jeweiligen Wertebereich 0...1: Measure of increased Belief: Measure of increased Disbelief:

MB (h, E+): 0...1 MD (h, E-): 0...1

Der Certainty Factor ergibt sich dann zu: CF = MB - MD. Es gibt nun verschiedene Möglichkeiten, Certainty Factors in Prämisse, Konklusion und Gesamtregel zu kombinieren. Nehmen wir an, wir könnten ein Faktum durch mehrere Regeln, von denen jede einen CF

THEN führe diese Aktion aus) • Hypothetische Regel: Sie kann einen oder mehrere parallele Lösungsansätze bereitstellen, falls die vorliegenden Daten noch keine eindeutige Entscheidung ermöglichen. • Einschränkende Regel (constraint rule): Diese Regel formuliert Zustände, die auf keinen Fall eintreten dürfen. Sie besitzt eine hohe Priorität und verhindert sinnlose oder verbotene Lösungsansätze. • Bestätigende Regel (belief rule): Sie wandelt einen bisher nur vermuteten, durch hypothetische Regeln gebildeten Lösungsansatz in einen sicher akzeptierten um. Die abgeleiteten Fakten werden als "wahr" anerkannt, widersprechende Lösungsversuche werden entfernt Diese Regeln stehen dem Viewpoint-Mechanismus zur Verfügung, der der Untersuchung von hypothetischen Alternativen und von zeitlichen Veränderungen von Systemen dient.

5.3.2.1.2

Prämissen

Damit eine Regel aktiviert werden kann, müssen ihre Prämissen mit den Fakten der Datenbasis übereinstimmen, d. h. sie müssen sich als wahr erweisen. Dabei löst jedes neu in die Datenbasis eingetragene Faktum einen Vergleichsprozeß aus, um anwendbare Regeln herauszufinden. Für die Beschreibung des Bedingungsteiles einer Regel steht eine Vielzahl von logischen Operatoren zur Verfügung, die sowohl eine logische Verknüpfung von Aussagen als auch die Suche nach der Existenz von Sachverhalten (Quantorenlogik) ermöglichen:

Regelorientierte Programmierung

137

• Implizites AND: Bei der Benennung mehrerer Bedingungen gilt automatisch deren Schnittmenge als Prämisse. • OR: Bei der Verknüpfung mehrerer Bedingungen durch OR werden mehrere unabhängige Regeln compiliert, die dann auch unabhängig feuern, so daß eine Aktion mehrfach ausgeführt wird. Diese oftmals unerwünschte Eigenschaft kann durch den Existenzquantor "EXIST" umgangen werden. • Explizites AND: Es wird in Verbindung mit OR gebraucht, wenn beide logischen Operatoren im Bedingungsteil auftauchen. • NOT bezieht sich auf die Nichterfüllbarkeit der gesamten Bedingung. Dies kann eine sehr aufwendige Suchaktion in der Datenbasis zur Folge haben. • FORALL: Für jedes Faktum, das der ersten Bedingung genügt, muß gelten, daß es auch einer zweiten Bedingung (oder mehreren Bedingungen) genügt. • EXIST bezieht sich wiederum auf zwei Bedingungen: Beim Auftreten des ersten Faktums, das beiden Bedingungen genügt, feuert die Regel. Der Mustervergleich (pattem matching) zwischen Prämisse und Faktum ist dann am eindeutigsten, wenn beide gleich formuliert sind (literal pattern). Der Aufbau der Regelbasis gestaltet sich aber flexibler, wenn die Möglichkeit gegeben ist, in der Prämisse statt der Benennung eines konkreten Objektes oder eines Attributes eine Variablenbeschreibung abzugeben und das zugehörige Element erst während des Inferenzprozesses in der Datenbasis zu suchen. Es wird dann an die Variable - lokal innerhalb der Regel - gebunden und kann an andere Variablen in Prämisse und Konklusion weitergereicht werden. Die Variablenbeschreibung ist in ART sehr vielfältig und erlaubt einen ausgedehnten Mustervergleich. Es können Elemente eines Faktums für sich genommen oder in logischen Verknüpfungen angegeben werden, wobei die Gefahr der kombinatorischen Explosion oder der Schleifenbildung besteht. Daher erfordert deren Anwendung einige Erfahrung, da eine Unterstützung vom System her nur schwer möglich ist.

ART

138

5.3.2.1.3

Konklusionen

Die Konklusion einer Regel bewirkt eine Veränderung der Datenbasis oder eine Interaktion mit dem Benutzer. Ein neues Faktum kann mit "assert" in die Datenbasis eingefügt werden, wobei die Möglichkeit besteht, gebundene Variablen aus der Prämisse zu übergeben. Entfernt werden Fakten mit "retract". Beide Befehle zusammengenommen bewirken die Veränderung eines Faktums, da hierfür kein gesondertes Kommando zur Verfügung steht. In gleicher Weise können Operationen auf Schemata vorgenommen werden. Ein Schema kann hinzugefügt oder entfernt, Slots können eingefügt, und die Werte einzelner Slots können verändert oder gelöscht werden. Abgeleitete Aktionen beinhalten eine Auswahl von Operationen, die an unterschiedliche Bedingungen gebunden sind. "Split" verbindet dabei eine Aktion mit einer spezifischen Bedingung, während mit dem CASE-Operator zwischen mehreren Alternativen ausgewählt werden kann. Für die Interaktion mit dem Benutzer existieren einige einfache Befehle: • printout druckt Text auf dem Bildschirm aus, • read nimmt eine Eingabe vom Benutzer entgegen, • bind weist einer Variablen in der Ausgabeanweisung einen Wert zu, • lislS bewirtet eine Datentypkonversion auf Listen von ART- in LISP-Format.

5.3.2.2

Rückwärts-Regeln

Rückwärts-Regeln können mit vorwärtsveikettenden Regeln kombiniert werden, wobei die Vorwärtsverkettung im Vordergrund steht Sie dienen dabei zweierlei Zielen: In Diagnosesystemen können an den Benutzer intelligente Fragen gestellt werden. Außerdem kann mit ihrer Hilfe die Datenbasis so klein wie möglich gehalten werden, indem Fakten erst bei Bedarf generiert werden. Eine Backward-Regel ist durch ein sogenanntes "goal" spezifiziert. Es beschreibt das gesuchte Faktum, das durch die Regel abgeleitet oder erfragt werden soll. Die Idee ist dabei, daß innerhalb einer vorwärtsverkettenden Regel die Elemente einer Prämisse

Regelorientierte Programmierung

139

verifiziert werden müssen. Kann nun eine Bedingung durch die Datenbasis nicht erfüllt werden, wird die Regel übergangen, wenn nicht eine entsprechende RückwärtsRegel existiert, die das erforderliche Faktum erzeugt. Die Rückwärtsverkettung wird also dadurch eingeleitet, daß zu einer Prämisse in einer Vorwärts-Regel eine passende Rückwärts-Regel existiert. Beide Regelarten stehen dabei in einem wechselseitigen Informationsaustausch. Vorwärts-Regeln kommunizieren mit Rückwärts-Regeln, indem sie "goals" gewissermaßen als Hilferuf für nicht verifizierbare Prämissen formulieren. Rückwärts-Regeln kommunizieren mit Vorwärts-Regeln durch die Generierung von Fakten. Innerhalb einer Rückwärts-Regel ist nur ein Ziel (goal) zulässig, das als erste Bedingung der Prämisse aufgeführt wird: (defrule (goal (goal pattem)) (mögliche weitere Fakten) =>

(auszuführende Aktion)) Es wird eine Liste der Relationen und Slotnamen, die in den Goal-pattern auftauchen, geführt, so daß der rückwärtsverkettende Mechanismus automatisch in Gang gesetzt wird, sobald ein entsprechendes Datenmuster in der Prämisse einer VorwärtsRegel auftaucht. Das Ziel einer Rückwärts-Regel kann ebenso wie sonstige Prämissen mit Hilfe von Variablen und Wildcards verallgemeinert werden, so daß es von einer definierten Menge von Vorwärts-Prämissen aktiviert werden kann. Dabei ist zu beachten, daß das Ziel nicht zu allgemein formuliert wird, weil dies eine ausgedehnte, oft sinnlose Suche zur Folge hätte. Andererseits darf es nicht zu speziell sein, damit überhaupt eine Aktivierung erfolgen kann. Aus der Regelbeschreibung wird deutlich, daß in ART eine nur geringe Trennung zwischen Regel- und Kontrollwissen vorgenommen wird. Das System ist vom Prinzip her vorwärtsverkettend, Rückwärts-Regeln müssen speziell eingepaßt werden, wobei jede Regel nur ein Ziel enthalten darf. Eine Rückwärts-"Verkettung" mit Backtracking wie in PROLOG-Systemen wird hierdurch nicht unterstützt, sie muß vielmehr in Vorwärtsverkettung implementiert werden, wobei die Hypothese den Ausgangspunkt bildet.

140

ART

5.3.2.3

Kontrollstatements

Innerhalb von Regeln können Schleifen und Verzweigungen formuliert werden. Eine Wiederholungsschleife hat dabei folgende Struktur FOR FROM TO DO Die Schrittweite kann durch "BY:" definiert werden. Diese Schleife ist sowohl in der Prämisse als auch in der Konklusion einer Regel anwendbar. • Innerhalb einer Konklusion bewirkt sie die mehrfache Ausführung einer Aktion. Dies kann in Zusammenhang mit einer Testbedingung in der Prämisse geschehen. • In der Prämisse angewandt, feuert eine Regel mehrfach, bis eine Abbruchbedingung erfüllt ist. Dies dient der Überprüfung einer oder mehrerer Prämissen, wobei automatisch unterschiedliche Prüfmuster erzeugt werden. Insbesondere der letzte Fall dient der Anwendung von Iterationen. Dabei können auf unterschiedliche Art Variablen oder Listen an die Interationsvariable gebunden werden. Auch hier wird das Kontrollwissen direkt in die einzelne Regel eingebunden, eine Trennung und damit eine Anwendung der Kontrollinformation auf Regelgruppen (durch DO..., WHILE...) ist nicht möglich. Eine Verzweigung läßt sich in einer Konklusion als IF...THEN...ELSE-Statement formulieren, wodurch eine Auswahl von Aktionen ermöglicht wird.

5.3.3 Inferenzmechanismus und Kontrollfluß In dem für Produktionssysteme typischen Inferenzzyklus wählt das System alle anwendbaren Regeln aus, deren Prämissen sich durch die Fakten der Datenbasis verifizieren lassen. Dieser Zyklus wird durch den Eintrag eines Faktums oder mehrerer Fakten in die Datenbasis in Gang gesetzt. Die Menge der ausgewählten Regeln bildet die Konfliktmenge und wird in eine Liste eingetragen. In ART wird diese Liste "Agenda" genannt, ein etwas hochgestochener Begriff, da eine Angenda Aufgabenbereiche (tasks) verwaltet und nicht einzelne Regeln. Da während eines Zyklus nur eine Regel ausgeführt werden kann (d. h. feuert), spielt der Kontrollmechanismus zur Auswahl der Regel aus der Konfliktmenge gerade in

Inferenzmechanismus und Kontrollfluß

141

großen, vorwärtsverkettenden Systemen eine entscheidende Rolle im Hinblick auf die Effizienz. ART bietet hierfür drei verschiedene Steuerungsmöglichkeiten: • Jeder Regel wird ein Prioritätsmaß (salience) in Form einer Zahl zugeordnet Hierdurch findet eine Strukturierung der Wissensbasis je nach Wichtigkeit statt. Regeln mit hoher Priorität enthalten einschränkende Bedingungen (constraints) oder zeitkritische Informationen. Solche mit niedriger Priorität bilden den Programmschluß, wie z. B. ein System-reset. Eine dynamische Änderung der Priorität ist nicht möglich. Abb. 5-13 ist eine Zusammenstellung typischer Prioritätswerte.

Variable default-salience constraint-salience minimum-salience maximum-salience

Wert 0 1000001 -1000000 1000000

Abb. 5-13: Prioritätswerte von Regeln (Quelle: CLAYTON, 1985b, S. 159)

• Regelprämissen können ein "Kontrollmuster" enthalten, das mit einem Kontrollfaktum in der Datenbasis korrespondiert Hierdurch können ganze Regelmengen einund ausgeschaltet werden. • Die vorgenannten Kontrollfakten der Datenbasis können mit Hilfe von "selection rules" verändert werden, wodurch eine dynamische Steuerung von Regelmengen möglich wird. Auch hier wird die enge Einbindung von Kontrollmechanismen in die einzelnen Regeln deutlich, eine stärkere Trennung und Generalisierung des Kontrollflusses durch die Vorgabe von strukturierten Regelmengen ist nicht vorgesehen. Stehen mehrere Regeln mit gleicher Prioritätsangabe in der Agenda, ist die Auswahl nicht vorhersehbar, sondern zufällig. Die zeitliche Abfolge des Inferenzprozesses und der Erzeugung der Fakten wird dabei nicht ausgewertet.

142

ART

Die Verwendung von Konfidenz-Faktoren und die Erstellung einer Erklärungskomponente, die für Diagnosesysteme unabdingbar sind, werden vom System nicht direkt unterstützt, sondern müssen extra programmiert werden. Konfidenz-Faktoren können auf dreierlei Art realisiert werden: • Der Konfidenzwert wird einem Faktum als Argument beigefügt und mit Hilfe von LISP-Prozeduren verarbeitet • Er wird in einem Schema als Slotwert abgelegt, wobei er als Active value seine eigene Verarbeitungsprozedur aktiviert • Die plausibelsten Alternativen werden im Viewpoint-Mechanismus als hypothetische Welten simultan abgearbeitet Eine Erklärungskomponente setzt auf dem grafisch und textuell darstellbaren Inferenzprozeß bzw. auf den Zielen der Rückwärtsregeln auf und muß für den Benutzer verständlich aufbereitet werden.

5.3.4 Objektorientierte Programmierung und Active Values Ab Version 3.0 bietet ART die Möglichkeit, LISP-Prozeduren an Objekte oder Klassen von Objekten als Methoden anzubinden ("procedural attachment") und durch das Senden von Nachrichten zu aktivieren. Diese Methoden werden innerhalb der Schema-Hierarchie vererbt. Dies ist das typische Paradigma der objektorientierten Programmierung. Eine Besonderheit besteht darin, daß eine Prozedur mehreren Objekten zugeordnet werden kann. Außerdem können Slotwerte zu Active values erklärt werden, so daß ein Zugriff auf dieses Attribut auf vielfältige Art - bezogen auf die Art des Zugriffs und den Zeitpunkt der Aktivierung - prozedurale Aktionen hervorrufen kann.

5.3.5

Viewpoint-Mechanismus

Die Bildung von Viewpoints zur Ableitung hypothetischer Welten und zeitlicher Veränderungen stellt den mächtigsten Mechanismus in ART dar. Ein Viewpoint ist

Viewpoint-Mechanismus

143

dabei eine Ansammlung von Fakten, die unter einem speziellen Gesichtspunkt betrachtet werden.

5.3.5.1 Hypothetische Welten Bei Planungs- und Problemlöseaufgaben, die von vorgegebenen Fakten ausgehen und nach einer Lösung suchen, besteht im Viewpoint-Mechanismus die Möglichkeit, alle hypothetischen Alternativen in Form eines "Lösungsbaumes" durchzuspielen. Als Beispiel kann das Wasserkrug-Problem aus Abschn. 4.1.2 dienen. Jede Möglichkeit der Füllung bildet dabei einen gesonderten Viewpoint. Abb. 5-14 zeigt die ersten Lösungsschritte.

Abb. 5-14: Viewpoints des Wasserkrug-Problems Das System entfaltet dabei einen vollständigen Lösungsbaum nach dem depth-firstsearch-Prinzip. Solche hypothetischen Verzweigungen können auch angewandt werden, wenn die Prämisse einer Regel nicht eindeutig zu bestimmen ist und mehrere Möglichkeiten offen läßt Das System der hypothetischen Welten wird mit den in Abschn. 5.3.2.1.1 beschriebenen Regeltypen (hypothetische Regeln, constraint rules, belief rules) erstellt

144

ART

Entlang eines jeden Pfades findet eine Vererbung der Fakten statt. In Abb. 5-14 hat sich z. B. in den Viewpoints 1 - 2a - 3b der Inhalt des rechts angegebenen 3-LiterKruges (0,0) - (4,0) - (0,0) nicht verändert, die angewandten Regeln bezogen sich lediglich auf eine Veränderung des 4-Liter-Kruges. Die Werte des unverändert gebliebenen Kruges wurden also durch Vererbung weitergereicht Fakten enthalten je nach Gültigkeitsbereich eine Kennzeichnung: • Aktuelle Fakten sind unter allen Umständen wahr und enthalten einen eindeutigen Wert • Vermutete Fakten äußern eine Hypothese und können unter verschiedenen Viewpoints unterschiedliche Werte annehmen. Ungünstige oder veibotene Wege können durch eine constraint-Regel blockiert werden, der entsprechende Viewpoint wird "vergiftet" (poisoned), und die zugehörigen Fakten werden aus der Datenbasis entfernt Stellt sich ein hypothetischer Lösungspfad als richtig heraus, können mit Hilfe der belief-Regel alle vermuteten Fakten entlang des Pfades in aktuelle Fakten umgewandelt werden. Der bestätigte Viewpoint wird zur neuen Wurzel weiterer Lösungswege. Wird im Laufe einer Problemlösung der vollständige Lösungsbaum abgearbeitet, kann es leicht zu Zirkelschlüssel kommen, wenn ein Viewpoint mit Fakten abgeleitet wird, die bereits in einem vorangegangenen Viewpoint enthalten waren. Um dies zu verhindern, muß eine Regel formuliert werden, die eine entsprechende Testbedingung enthält. Dafür existieren zwei Prädikate, die zwei Viewpoints auf Gleichheit untersuchen und feststellen, ob einer von ihnen der Nachfolger des anderen ist

5.3.5.2 Darstellung zeitlicher Abläufe Mit Hilfe von Viewpoints können Situationen beschrieben werden, die sich mit der Zeit verändern. Jeder beschriebene Zeitpunkt entspricht dabei einem Viewpoint. Die sich verändernde Situation kann durch ein Schema beschrieben werden, deren Attributwerte sich den zeitlichen Veränderungen anpassen. Da Attribute als Fakten in die Datenbasis eingetragen werden, erscheint das Weiterreichen von unveränderten

Viewpoint-Mechanismus

145

Fakten von einem Viewpoint zum nächsten als Vererbung. Dabei wird der Gültigkeitsbereich eines Faktums in seinem "Extent" beschrieben, wodurch die Vererbung unterbrochen werden kann und die Zuweisung neuer Werte möglich ist l.Tag

2. Tag

Bus-Nr.: 23 Fahrgäste: 53 Ort: Berlin Zeit: Sonntag

Ort Zeit

3. Tag

München Montag

Fahrgäste: 40 Ort Rom Zeit Dienstag

Abb. 5-15: Beispiel einer Reiseroute In Abb. 5-15 wird die Fahrt eines Reisebusses als Beispiel einer zeitlichen Abfolge dargestellt Die Respräsentation kann als Schema erfolgen: Schema: Reisebus Slotl: Zeitplan Slot2: Bus-Nr. Slot3: Anzahl der Fahrgäste Slot4: Reiseort Slot5: Tag In den Viewpoint tauchen die entsprechen Fakten auf, wobei unveränderte Fakten einfach weitergereicht werden (z. B. die Bus-Nummer durch alle Viewpoints). Ändert sich der Wert eines Attributs, wird das Faktum überschrieben (z. B. Anzahl der Fahrgäste am 3. Tag). Die Viewpoints können mit Hilfe des Befehls "sprout" sowohl vor der Programmausführung bei der Deklaration von Fakten als auch während des Programmablaufs im Konklusionsteil einer Regel erzeugt werden. Die Darstellung eines zeitlichen Ablaufes kann als nicht-monotone Schlußfolgerung angesehen werden, da Fakten eingefügt, aber auch verändert, entfernt und für ungültig erklärt werden können.

146

ART

5.3.5.3 Die Vereinigung von Viewpoints Bei der Bildung unterschiedlicher Hypothesen mit ihren Ableitungen ist es denkbar, daß diese zu dem gleichen Ergebnis gelangen bzw. daß sich zwei Viewpoints zu einem vereinigen ("merging"). Als Beispiel diene ein Teil des Lösungsbaumes des bereits beschriebenen Wasserkrug-Problems.

Abb. 5-16: Merging Zunächst teilt sich gemäß Abb. 5-16 der Baum in die Viewpoints (4,0) und (0,3). Durch Anwendung der Regeln 2 und 1 aus Abb. 4-3 wird der gemeinsame Zustand (4,3) abgeleitet. Dies tritt häufig bei Planungsprozessen auf, in denen das gleiche Resultat auf unterschiedlichen Wegen erreicht werden kann. Das Zusammengehen von Viewpoints kann durch das Kommando "merge" im Konklusionsteil einer Regel erzwungen werden. Möglich ist aber auch eine automatische Vereinigung, wenn z. B. eine Regel gleichzeitig auf zwei hypothetische Viewpoints zugreift Dies stellt die häufigste Anwendung dieses Prinzips dar.

5.3.5.4 Viewpoints auf mehreren Ebenen Bisher haben wir die Abfolge von Viewpoints unter nur einem Veränderungsaspekt betrachtet, entweder der Bildung hypothetischer Alternativen oder des zeitlichen Ablaufs. Wir können diese Darstellungsweise aber auf eine beliebige Anzahl von Betrachtungsebenen ausweiten.

147

Viewpoint-Mechanismus

Abstrakt ausgedrückt, können wir uns parallele hypothetische Welten darstellen, UNIVERSUM... benannt, die z. B. unterschiedliche Planungsstrategien verfolgen. Innerhalb eines jeden Universums ist wiederum eine Abfolge zeitlicher Veränderungen als zweite Ebene der Betrachtung denkbar. ART bezeichnet dies als "two level viewpoint". Dabei ist eine beliebige Anzahl von Ebenen zugelassen, die sich aber für gewöhnlich auf maximal zwei beschränkt Wir können uns die Viewpoints ineinander verschachtelt vorstellen (Abb. 5-17), wobei automatisch ein "Meta"- Viewpoint generiert wird, der die übrigen Viewpoints verwaltet, für den Benutzer aber nicht sichtbar ist.

Meta-Viewpoint UNIVERSUM-1

UNIVERSUM-2

Zeit 1

Zeit 1

Zeit 2

Zeit 2

Zeit 3

Zeit 3

Abb. 5-17: Viewpoint-Struktur Die innere, zeitliche Struktur wird als "inner level" oder als Kontext bezeichnet, während die darüberliegende Ebene der Universen mit "outer level" benannt wird. Die grafische Darstellung der Viewpoints (Abb. 5-18) folgt den bisherigen Abbildungen, allerdings unter Angabe der Level-Parameter, die mit in die Fakten aufgenommen werden.

148

ART

Universum-1, Zeit-1

Universum-1, Zeit-2

Univers um-2, Zeit-1

Universum-2, Zeit-2

Abb. 5-18: Two-Level-Viewpoint Zur Verwaltung der Viewpoints und Kontrolle des Inferenzprozesses steht eine Vielzahl von Aktionen und Prädikaten zur Verfügung, die eine komfortable Gestaltung eines vorwärtsverkettenden Systems ermöglichen.

5.3.6 ART Studio Interface Sowohl für den Entwickler als auch für den Anwender eines Expertensystems stellt ART eine komfortable und benutzerfreundliche Oberfläche zur Verfügung, das ART Studio Interface, das den Dialog in eine grafische Fenster- und Maustechnologie einbettet.

5.3.6.1

Browser

Der Browser dient der anschaulichen Darstellung und der Veränderung der Wissensbasis, nachdem diese mit einem externen Texteditor aufgebaut wurde. Mit Hilfe von Menüs kann auf einzelne Teile, wie Fakten, Schemata, Regeln und Viewpoints, zugegriffen werden. Die Abhängigkeit zwischen Schemata und Viewpoints im Sinne der Vererbung und die Ableitungskette einzelner Fakten lassen sich grafisch darstellen. Es sind Anfragen an das System nach Inhalt und Wahrheitsgehalt einzelner Fakten möglich. Die Auswirkungen von inkrementellen Änderungen der Datenbasis lassen sich direkt beobachten. Außerdem verbessert ein "spelling corrector" kleinere Eingabefehler.

ART Studio Interface

149

Zum besseren Verständnis des eingegebenen Wissens lassen sich Fakten und Regeln in einer der natürlichen, englischen Sprache angenäherten Form darstellen. Dadurch wird die Wissensbasis auch dem Nicht-Programmierer verständlicher. Außerdem können Anfragen an den Benutzer flüssiger formuliert werden.

5.3.6.2 Execution Monitor Zum Testen des Systems einschließlich der Fehlersuche und zum Aufbau der Schnittstelle zwischen dem lauffähigen Expertensystem und dem Endbenutzer stellt ART den Execution Monitor zur Verfügung. Als Testhilfe kann das erstellte Programm schrittweise abgearbeitet werden, Haltepunkte lassen sich einfügen, bei einem vollständigen Probelauf sind ausgedehnte Statistiken über das Systemverhalten (Match-Prozesse, Feuern von Regeln, Speicherplatzbelegung) abrufbar. Dadurch sind Fehlersuche und Optimierung des Laufzeitverhaltens möglich. Als zweiter Bereich wird im Execution Monitor die Benutzeroberfläche des Systems bestimmt. Anzahl und Format der Fenster, Ablauf des Dialoges und Art der dargebotenen Informationen einschließlich Grafik können hier festgelegt werden. ART benutzt damit die üblichen Möglichkeiten von LISP-Maschinen zur Gestaltung eines Interface.

5.3.6.3 ARTIST Das ART Image Synthesis Tool (ARTIST) gestattet die Bildung von grafischen Elementen auf Symbolics- und LMI LISP-Maschinen. Wie in einem Grafikprogramm stehen 12 Grundelemente der Gestaltung zur Verfügung, die zu Anzeigeeinheiten und Diagrammen zusammengesetzt werden können. Jede Grafik ist als Schema repräsentiert, kann an Schema-Slots angebunden werden bzw. ist von jeder Regel der Wissensbasis aus ansprechbar, so daß sich während des Programmablaufs ändernde Attributwerte leicht veranschaulichen lassen.

150

ART

5.3.7 Bewertung ART ist ein sehr mächtiges Entwicklungssystem für Expertensysteme mit regelund framebasierten und objektorientierten Wissenrepräsentationsmechanismen. Der entscheidende Vorteil gegenüber anderen Systemen ist sein Laufzeitverhalten, das Echtzeitanwendungen ermöglicht. Die Verarbeitungsgeschwindigkeit wurde in der Version 3.0 noch verbessert durch die Art des Pattern matching und das weitestgehende Vermeiden der Speicherumstrukturierung durch Garbage collection. Dadurch eignet sich das System zur Überwachung und Kontrolle bei Prozeßsteuerungen und zur Darstellung zeitlicher Veränderungen. Das Entwicklungssystem ist auf einer Reihe von Workstations und LISP-Maschinen lauffähig, kann aber auch auf andere Rechner übertragen werden, da es in einer CVersion vorliegt Der Schwerpunkt in der Anwendung liegt sicherlich in datengesteuerten, vorwärtsverkettenden Systemen, in denen der Viewpoint-Mechanismus zur Entfaltung gelangen kann, wie z. B. in Planungs- und Kontrollsystemen. Die zugehörigen Regeltypen und die Möglichkeiten des Pattem matching sind sehr ausgefeilt. Die Wissensbasis kann durch den Knowledge Engineer ausführlich ausgetestet werden. Die Stärken des Systems werden mit einigen Einschränkungen erkauft, die sich insbesondere auf die Wissensrepräsentation beziehen. Regeln bilden die Grundlage der Wissensbasis, da alle Schemata in sie auflöst werden. Dadurch geht die Struktur verloren, und es können sich unerwünschte Effekte (z. B. der mehrfachen Ausführung einer Aktion) ergeben. Das gesamte Kontrollwissen ist an einzelne Regeln gebunden oder muß durch Regeln erzeugt werden. Dadurch erscheint sowohl die Strukturierung des Wissens als auch die Trennung von Regel- und Kontrollwissen nur ungenügend ausgebildet. Dies macht sich gerade beim Bau von größeren Systemen störend bemerkbar. Die Auswahl der zu feuernden Regel aus der Konfliktmenge erscheint undurchsichtig und zufallsbedingt. Hier sind bessere Kontrollstrategien, die den Verlauf des Infeienzprozesses und den Zeitpunkt der Erzeugung eines Faktums berücksichtigen, denkbar. Die Darstellung des Wissens und die Programmierung des Problemlöseprozesses erfolgt in einer LISP-nahen Notation und Denkweise. Nicht zu Unrecht weist der Hersteller in seinem Handbuch mehrfach darauf hin, daß die Anwender von ART Freude am Programmieren besitzen - sie müssen es auch.

Bewertung

151

Die Anwendung von Rückwärtsregeln ist in das vorwärtsverkettende System eingebettet, so daß sich bei Diagnosesystemen mit Erklärungskomponente und Konfidenzfaktoren eine etwas ungewohnte Darstellungsart ergibt Wie in vielen anderen Entwicklungsumgebungen auch, wird vom Prinzip her keine Unterstützung zur Erfassung und Strukturierung des Wissens angeboten. Der systemerfahrene Knowledge Engineer kann nicht ersetzt werden, da eine Programmierung durch den Anwender kaum möglich erscheint Es werden Grafikroutinen angeboten, die auf den LISP-Maschinen von LMI und Symbolics einsetzbar sind und dort die Erstellung und Anwendung grafischer Objekte ermöglichen. Dadurch können Attributweite anschaulich dargesellt werden, allerdings ist die umgekehrte Veränderung von Werten durch Manipulation der Grafiken nicht möglich. ART ist ein leistungsfähiges Entwicklungssystem, wenn es seinen Stärken gemäß eingesetzt wird.

5.4 BABYLON BABYLON ist eine hybride Entwicklungsumgebung für Expertensysteme mit den dafür üblichen Repräsentationsmechanismen (objekt-, daten- und regelorientiert, prozedural) und einem PROLOG-Teil. Es läuft bisher als Prototyp nur auf LISP-Maschinen von Symbolics und wurde in Zeta-LISP implementiert. Eine Portierung auf andere Hardware-Umgebungen ist geplant

5.4.1 Systemaufbau Mit BABYLON wurde das Konzept eines hybriden Systems bisher am konsequentesten verfolgt. Die Verarbeitung unterschiedlich repräsentierten Wissens erfolgt nach dem Prinzip des "verteilten Problemlösens". Dabei unterscheidet die Architektur des Systems zwischen Basisbausteinen, die für die Bearbeitung der einzelnen Wissensrepräsentationsformalismen zuständig sind, und einem Meta- Prozessor, der die Koordination der einzelnen Basisbausteine übernimmt und deren Kommunikation steuert. Es existieren vier Wissensrepräsentationskonstrukte:

152

BABYLON

Abb. 5-19: Wissensrepräsentationskonstrukte in BABYLON (Quelle: DI PRIMIO & BREWKA, 1985, S.4)

• Objekte: Sie stellen den zentralen Repräsentationsmechanismus dar, da alle anderen Bereiche auf sie Bezug nehmen. Sie weiden in Klassen und Instanzen unterteilt, wobei letztere die dynamische Datenbasis bilden. • Relationen: Sie stellen das Wissen in Form von Horn-Klauseln dar und bilden den PROLOG-Teil von BABYLON. • Produktionsregeln: Mit ihrer Hilfe können in der üblichen Darstellungsform von IF-THEN-Regeln Produktionssysteme gebildet werden. • Constraints: Sie bilden in Form von Äquivalenzregeln die Randbedingungen des Systems und überwachen bei Ausführung der Aktionen von Produktionsregeln deren Einhaltung. Abb. 5-19 zeigt die vier Bereiche der Wissensrepräsentation. Für jedes der genannten Konstrukte existiert ein eigenständiger Sprachprozessor. Deren Koordination übernimmt der übergeordnete Meta- Prozessor. Eine genaue Beschreibung des Zusammenspiels der Basis- Prozessoren und des Meta-Prozessors findet sich in DI PRIMIO & BREWKA (1985).

Gestaltung der Benutzerschnittstelle

153

Von den anderen derzeit bekannten hybriden Entwicklungssystemen wird ein anderer Ansatz verfolgt Wie in Abschn. 4.1.6 beschrieben, erlauben sie entweder eine direkte Kommunikation zwischen den verschiedenen Konstmkten, oder sie übersetzen die Formalismen ineinander oder in einen einzigen tieferliegenden Formalismus (z. B. Kompilieren in LISP). Der hier gewählte Ansatz, bei dem jede Kommunikation über den Meta-Prozessor läuft (s. Abb. 4-12), mag bezüglich der Ausführungszeiten aufgrund der gegenwärtigen Hardware-Konfiguration ineffizienter sein. Es sind jedoch parallel arbeitende Rechnerarchitektueren vorstellbar, die diesen Nachteil aufzuheben in der Lage sind. Der entscheidende Vorteil liegt aber darin, daß Erweiterungen und Veränderungen des Systems relativ einfach vorzunehmen sind. Es lassen sich zusätzliche Basisbausteine hinzufügen, um die vorhandenen Repräsentationsmechanismen zu erweitern. Außerdem ist durch die Änderung des Meta-Prozessors eine Erweiterung und Umstrukturierung des Gesamtsystems denkbar.

5.4.2 Gestaltung der Benutzerschnittstelle Aufgrund der mächtigen Soft- und Hardware-Umgebung auf LISP-Basis bietet BABYLON eine komfortable und übersichtliche Benutzeroberfläche. Der Grafikbildschirm ermöglicht eine Fenstertechnik, die von einer Maus-Steuerung unterstützt wird. Das System versucht sich weitgehend selbst zu erklären, eine Auswahl von Programmschritten wird durch Menüs erleichtert. Der Bildschirm umfaßt in der Basiskonfiguration (Abb. 5-20) drei Bereiche: • Das BABYLON-Kommando-Menü auf der rechten Seite ermöglicht die Auswahl grundlegender Aktionen. • Das Dialog-Window steht für Eingaben durch den Benutzer zur Verfügung. • Das Trace-Window zeigt Reaktionen des Systems an. Je nach Bedarf können weitere Fenster hinzukommen. Am unteren schwarzen Rand erscheint in inverser Darstellung die "Mouse Documentation Line", die erläutert, welche Aktion durch Anklicken einer Maustaste gegenwärtig ausgelöst würde.

154

BABYLON

BABYLON C o m m a n d !

Save Current Knowledge Base S t a r t Current Knowledge Base R e s e t Current Knowledge Base E d i t Rule S e t s E d i t Rule C r e a t e Rule Display Rule D e l e t e Rule I n s p e c t Rule T e r m s B r o w s e On Rule T e r m s Edit Object Describe Object Change I n s t a n c e Describe Relations Edit Relations Call P r o l o g S e t Configuration S e t Language Change f o n t Browser

EXPERT TRACE MIMDOM

Help

3A3YLorJ DIALOGUE MIMDOH - HPSl:>SPOOL>VlCP>r.

Abb. 5-20: Systemfenster in BABYLON (Quelle: BACHEM et al., 1985, S. 60)

Das Erstellen eines Expertensystems wird durch diese interaktive Technik weitgehend unterstützt und erleichtert Dabei kann jederzeit auf die LISP-Umgebung zugegriffen werden. Eine Browser-Komponente veranschaulicht den hierarchischen Aufbau eines Objektbaums. Außerdem ist ein System zur grafischen Exploration der Wissensbasis in der Erprobung, genannt KbExplorer (WITTUR, 1987), das die verschiedenen Wissensbereiche ausführlicher darstellen soll. Eine Konsultation wird durch die vorhandenen Dialog- und Erklärungskomponenten in besonderer Weise erleichtert. Grafische Objekte sind allerdings in BABYLON gar nicht vorhanden, so daß eine Simulation - wie z. B. in KEE möglich - nur unanschaulich darstellbar ist.

Objektorientierte Programmierung

155

5.4.3 Objektorientierte Programmierung 5.4.3.1 Frames und Instanzen Frames beschreiben in BABYLON stets Objektklassen, die Objekte selbst sind als Instanzen von Frames repräsentiert. Es ist zu beachten, daß die Nomenklatur hier sehr speziell ist In LOOPS werden Klassen, Metaklassen und Instanzen als Objekte bezeichnet. In KEE heißen diese Units, wobei die hierarchischen Ebenen als Parent und Child erscheinen, während sie in ART Schemata genannt werden. In BABYLON werden nur Klassen als Frames bezeichnet, Metaklassen heißen Super-Frames und die individuellen Instanzen Objekte. Frames enthalten Slots, die Attribute beschreiben. Sie werden definiert durch: (DEFFRAME {(SUPERS. )} (SLOTS. cListe von Slot-Spezifikationen>)) In der Supers-Frameliste sind die Parents, d. h. die zugehörigen Super-Frames bzw. Metaklassen angegeben. Deren Attribute und Methoden werden nach dem üblichen Schema vererbt. Sind diese mehrfach unter gleichem Namen in der Vererbungshierarchie vorhanden, so werden die am nächsten gelegenen Inhalte übernommen. Den Slots eines Frames können ein oder mehrere Werte zugewiesen werden (einoder mehrwertige Slots), und es ist möglich, einen Default-Wert vorzugegeben. Außerdem können für jeden Slot Properties angegeben werden, die ihrerseits Werte besitzen. Für einen Frame können Methoden definiert werden, die in BABYLON "Behaviors" heißen. Das sind Aktionen, die jede Instanz des Frames ausführen kann, wenn sie durch entsprechende Nachrichten aktiviert werden. Für jeden Slot einer Instanz wird eine "History" geführt, d. h. alle Werte, die ein Slot während eines Programmlaufs annimmt, werden in eine Liste eingetragen, so daß Wertzuweisungen wieder rückgängig gemacht werden können. Die Instanzen eines Frames werden folgendermaßen definiert:

156

BABYLON (DEFINSTANCE OF WITH = = )

Im Bereich der Slot-Initialisierung kann ein Wert und zusätzlich eine Property-Liste mit den zugehörigen Werten angegeben werden. Die Frame- und Objektkonstrukte basieren von der Implementierung her auf dem FLAVORS-Konzept von ZetaLISP. Frames entsprechen den Flavors, Behaviors den Methoden von Flavors und die Instanzen von Frames den Instanzen von Flavors, wobei allerdings wesentliche konzeptionelle Erweiterungen vorgenommen worden sind.

5.4.3.2 Beschreibung der Slots Slots können ein- oder mehrwertig sein. Dafür können in den Properties nähere Angaben über dessen mögliche Werte gemacht werden: • ANY •BOOLEAN • SYMBOL •NUMBER •LIST

•STRING •INTERVAL • ONE-OF • SOME-OF

Es können Einschränkungen und Randbedingungen (constraints) angegeben werden, wobei das Vorhandensein oder Ausgeschlossensein eines Wertes andere Werte erzwingen oder ausschließen kann. Als Wert eines Slots kann der Name einer Instanz eines Frames erscheinen. Es kann eine Liste von "Possible-Value-Spezifikationen" aufgeführt werden, für die eine logische Verknüpfung angegeben wird (AND, OR, NOT), der der Wert genügen muß. Außerdem besteht die Möglichkeit, daß der Benutzer einen eigenen Wertebereich spezifiziert.

Objektorientierte Programmierung

157

Unabhängig von der Werte-Definition kann stets als Wert auch "-" (unbestimmt) oder "UNKNOWN" auftreten. Außer durch programmabhängige Zuweisung können Slotwerte durch Fragen an den Benutzer bestimmt werden. Dabei nehmen folgende Properties Einfluß auf das Frageverhalten des Systems: ASK: Anstelle des Standard-Fragetextes kann ein vom Benutzer formulierter Text ausgegeben werden. EXPLAIN-ANSWERS: Neben dem Fragetext kann sich der Benutzer die möglichen Antworten vom System anzeigen lassen. BEFORE-ASKING: Bevor ein Wert erfragt wird, müssen eine oder alle der angegebenen Frame-Referenzen wahr sein. AFTER-ASKING enthält eine Liste von Frageregeln, die erst ausgewertet werden, wenn der Wert des Slots bei der Abarbeitung von Produktionsregeln erfragt worden ist. Die Frageregeln erfragen je nach Wertvergleich dann weitere Werte vom Benutzer. Im Konzept der Slots von BABYLON wird nicht zwischen Member- und Own-Slots (wie in KEE) oder zwischen Instanz- und Klassenvariablen (wie in LOOPS) unterschieden.

5.4.3.3 Methoden und Nachrichten Methoden werden in BABYLON als "Behaviors" bezeichnet und beinhalten LISPAusdrücke, die prozedurale Aktionen ausführen. Sie werden unter einem Schlüsselwort einem Frame zugeordnet und können dann von jeder Instanz dieses Frames ausgeführt werden. Behaviors werden durch Nachrichten aktiviert. Dies geschieht entweder durch das ZetaLISP-Makro "SEND" oder das BABYLON-Zeichen "