Expertensystem-Praktikum | springerprofessional.de

Springer Professional

Top

1987 | Book

Read chapter Read first chapter

Expertensystem-Praktikum

Authors: Dr. Peter Schnupp, Chau Thuy Nguyen Huu

Publisher: Springer Berlin Heidelberg

Book Series : Springer Compass

Included in: Professional Book Archive

Login to get access

About this book

Schwimmen lernt man beim Schwimmen. Programmieren beim Programmieren. Und Expertensysteme zu schreiben beim Schreiben von Expertensystemen. Deshalb entstand dieses Buch: aus einem Expertensystem-Praktikum, das Soft ware-Praktiker in die neuen Entwurfs-und Programmiertechniken einführt, welche die wissensbasierte Datenverarbeitung in die Softwaretechnologie einbrachte. Dabei wird bewußt die Programmierung betont, nicht die Generierung eines Expertensy stems durch "Einfüllen" von Fachwissen in eine Shell. Was natürlich nicht heißen soll, daß sich nicht auch der Programmierer eines Expertensystems die eine oder andere Aufgabe erleichtern kann, indem er ein derartiges Metasystem als "Werk zeug" benutzt. Aber auch dann - das ist jedenfalls die Erfahrung der Autoren - können gute, benutzerfreundliche und leicht in die bereits vorhandenen konventionellen Daten basen und Anwendungen integrierbare Expertensysteme nur entstehen, wenn der Entwickler problemlos sich all die Komponenten selbst programmieren kann, die er in seinem vorgefertigten Werkzeugkasten überhaupt nicht, nicht in geeigneter Form oder nicht mit den richtigen Schnittstellen vorfindet. Im traditionellen Maschinenbau ist der "Werkzeugmacher" der gesuchteste und höchstbezahlte Fachspezialist. In unserem Handwerk ist das nicht viel anders.

Advertisement

Table of Contents

Frontmatter

1. Einführung

Zusammenfassung

Unser Expertensystem-Praktikum soll Ihnen helfen, den Entwurf und die Realisierung wissensbasierter Software-Systeme an Hand von praktischen Beispielen einzuüben. Dazu müssen natürlich ein paar Voraussetzungen erfüllt sein. Zum einen, daß Sie bereits wissen, was ein Expertensystem ist (andernfalls hätten Sie dieses Buch vermutlich gar nicht gekauft). Trotzdem werden wir im folgenden noch einmal kurz aufschreiben, was wir darunter verstehen, damit es keine Mißverständnisse in den grundlegenden Begriffen und Mo- dellen gibt. Zum zweiten müsssen wir annehmen, daß Sie die von uns verwendete Programmiersprache, Prolog, kennen und möglichst auch eine Implementierung von ihr verfügbar haben — andernfalls bliebe dieses Praktikum zu theoretisch. Denn, gleichgültig was manche Informatiker sagen, die Basissoftware bestimmt auch heute noch weitgehend, was Sie wie auf Ihrem Computer sinnvoll realisieren können. Und die von Ihnen implementierten Anwendungen wiederum bestimmen das weitere “Leben“ eines oder gar mehrerer Computer — als Mauerblümchen oder als akzeptiertes und beliebtes Mitglied eines erfolgreichen Arbeitsteams.

Peter Schnupp, Chau Thuy Nguyen Huu

2. Eigenschaften und Komponenten eines Expertensystems

Zusammenfassung

Expertensysteme sind eine neue Klasse von Anwendungs-Programmen. Sie sollen das “Wissen“ eines Experten in einem Fachgebiet, meist als interaktives Dialogsystem, auf einem Rechner verfügbar machen. Der wesentlichste Unterschied zur traditionellen Programmierung ist, daß nicht nur die “Daten“ sondern auch die Verarbeitungsregeln für sie in einer Wissensbasis gehalten werden. Der Kern eines Expertensystems ist eine Inferenzmaschine. Sie zieht aus dem dort gespeicherten Wissen nach einer bestimmten Strategie Schlüsse und erarbeitet so neues Wissen. Geeignete Heuristiken müssen dafür sorgen, daß diese Wissensbearbeitung gezielt verläuft, und daß so in vertretbarer Zeit die Informationen erhalten werden, welche die Benutzer-Anfragen beantworten. Nicht für alle Aufgabenbereiche sind (heute) Expertensysteme sinnvoll realisierbar. Und je nach dem Einsatzgebiet kann man verschiedene Typen von ihnen unterscheiden.

Peter Schnupp, Chau Thuy Nguyen Huu

3. Ein Modellsystem zur Tarif-Auskunft

Zusammenfassung

An einem kleinen Beispiel wollen wir Ihnen einige der wichtigsten Konzepte und Programmiermethoden für ein Expertensystem vorführen. Das System soll den Benutzer bei der Wahl der preiswertesten Beförderung mit dem MVV, dem Münchner Verkehrsverbund, beraten. Es fragt ihn zuerst nach den spezifischen Falldaten - zum Beispiel, wieviel Geld er hat — und empfiehlt anschließend die günstigste Fahrkarte. Auch ein so einfaches Expertensystem sollte bereits eine Erklärungskomponente haben. Deshalb merkt sich der MVV-Experte die Folge der Fragen und Antworten. Damit kann er auf Wunsch erläutern, warum er die jeweilige Frage stellt und wie er zu seinem Ergebnis kommt.

Peter Schnupp, Chau Thuy Nguyen Huu

4. Wissensdarstellung und Wissensverarbeitung

Zusammenfassung

Das Tarifauskunfts-System zeigte bereits eine Reihe verschiedener Komponenten und Funktionen eines Expertensystems: die Wissensbasis, in welcher das vorhandene Wissen deklarativ dargestellt wird, die zielgerichtete Verarbeitung und fallspezifische Ergänzung dieses Wissens entsprechend einer Kontrollstruktur, und die Erklärungsfunktion, welche auf Wunsch die gestellten Fragen und erzielten Ergebnisse an Hand eines Protokolls des bisherigen Dialogs und der aktuellen Zustandsparameter erläutert. Sicher ließ jedoch das hier gezeigte, kleine System beim Leser einige Fragen offen. So zum Beispiel die nach der Systemarchitektur: wo sind welche Datenstrukturen und welche Funktionen lokalisiert, und wie wirken sie zusammen? Oder das Problem der Darstellungs- und Verarbeitungsweise des Systemwissens: sind die gewählte Wissensdarstellung und die Strategie der Wissensverarbeitung eigentlich durch irgendwelche theoretischen oder praktischen Gesetzmäßigkeiten und Zwänge vorgegeben, oder hätten wir sie genausogut anders realisieren können? Und schließlich vielleicht auch softwaretechnologische Fragen: plant und programmiert man Expertensysteme “genauso“ wie traditionelle Software oder “ganz anders“? Dieses Kapitel soll hierauf Antwort geben. Es wird damit zugleich eine solidere Ausgangsbasis für die folgenden legen.

Peter Schnupp, Chau Thuy Nguyen Huu

5. Dialogführung und Erklärungskomponenten

Zusammenfassung

Unser einfaches MVV-Beratungssystem hatte bereits eine primitive Erklärungskomponente. Sie konnte dem Benutzer sagen, warum eine bestimmte Frage gestellt wird. Aber bei einem “ernsthaften“ Expertensystem kann und soll man mehr verlangen. Das System muß auch erklären können, wie es ein bestimmtes Resultat erzielt hat und warum nicht ein anderes. Außerdem ist es weit besser, wenn die Erklärungen nicht getrennt von den Regeln gespeichert sondern in sie integriert werden. An Hand eines etwas anspruchsvolleren Beispiels möchten wir Ihnen jetzt eine professionellere Implementierung für die Dialogführung und die Erklärungskomponente vorführen. Hierzu verwenden wir eine Teilmenge eines existierenden Expertensystems für die Diagnose von KFZ-Defekten. Seine Wissensbasis reduzieren wir dabei auf die Autoheizung.

Peter Schnupp, Chau Thuy Nguyen Huu

6. “Erfahrung“ und “Lernen“

Zusammenfassung

Bis jetzt verhält sich unser KFZ-Diagnosesystem noch sehr unflexibel: es folgt “stur“ der durch die Regelstruktur und -anordnung in der Wissensbasis vorgegebenen Inferenzstrategie. Und es merkt sich von den eingegebenen Falldaten gerade nur das, was für die aktuelle Diagnose nötig ist. Von einem Experten-System sollte man aber mehr erwarten. Wenn der Benutzer bereits einen Verdacht hat, dann will er den Dialog gezielt in die vermutete Richtung lenken. Umgekehrt sollte das System seinerseits, so wie der erfahrene Mechaniker, durch ein paar vorbereitende Tests (“brennt das Licht?“) bestimmte Problembereiche als wahrscheinliche Fehlerquellen lokalisieren. Ein menschlicher Experte lernt zudem laufend dazu. Aus der relativen Häufigkeit der jeweils diagnostizierten Fehler gewinnt er Erfahrungen über die speziellen Schwächen der verschiedenen Fahrzeugtypen. Dieses Wissen ist ebenso wertvoll für ihn wie für die Qualitätskontrolle des Herstellers. Wenn er nach den häufigsten Fehlern zuerst sucht, hat er schneller Erfolg. In diesem Kapitel zeigen wir Techniken, mit denen man derartige Fähigkeiten nachbilden kann.

Peter Schnupp, Chau Thuy Nguyen Huu

7. Objektorientierte Wissensverwaltung

Zusammenfassung

Die “flache“ Wissensdarstellung durch Fakten und Prozeduren wird unübersichtlich, wenn komplexere Wissensstrukturen verwaltet werden sollen. In einigen prozeduralen Sprachen sowie in Lisp-Erweiterungen haben sich hierfür objektorientierte Techniken bewährt. Sie erlauben es, Objekte so zu beschreiben, daß ihnen nicht nur Fakten, sondern auch prozedurales Wissen zugeordnet wird. Dabei können spezialisiertere Objektklassen derartiges Wissen von allgemeineren “erben“, was eine hohe Ökonomie in der Erfassung und Repräsentation der Informationen erlaubt. Eine besonders günstige Organisationsform für objektorientiertes Wissen sind Rahmen. Wir zeigen am Beispiel einer Lizenzverwaltung, wie leicht sich mit ihnen eine derartige Wissensbasis in Prolog realisieren läßt.

Peter Schnupp, Chau Thuy Nguyen Huu

8. Rahmen und Prozeduren

Zusammenfassung

Die im letzten Kapitel vorgestellte Wissensverwaltung mit Rahmen ist noch nicht viel mehr als eine einfache, objektorientierte Erweiterung von Prolog. Als “Expertensystem“ qualifiziert sie sich wohl noch ebenso wenig wie ein Prologinterpreter ohne in Prolog implementierte Wissensbasis. Rahmen werden vielmehr erst dadurch von einer Daten- zu einer Wissensorganisationsform, daß man in sie auch Prozeduren einbettet, die aktiv Aufgaben bei der Sammlung und Aufbereitung von Informationen übernehmen. In diesem Kapitel zeigen wir Ihnen derartige Techniken an Hand der über den generischen Rahmen gesteuerten Erfassung neuer Objekte sowie einer “intelligenten“ Verwaltung von Aktennotizen. Die letztere ergänzt unsere Lizenzverwaltung und ist ein typisches Beispiel für wissensbasierte Programmiertechniken auf rahmen-orientierter Grundlage. Sie werden sehen, daß sie sehr stark auf die Möglichkeiten zurückgreift, welche die Einbettung von prozeduralen Anhängseln in Facet-Einträge der Rahmen eröffnet.

Peter Schnupp, Chau Thuy Nguyen Huu

9. Darstellung und Verwendung von Bedingungen

Zusammenfassung

Die bisher von uns vorgestellten Systeme hatten gemeinsam, daß sie eine Benutzeranforderung oder eine Hypothese möglichst zielgerichtet bearbeiteten und — mit etwas Glück — auch lösten. Dies ist nicht immer der Fall. Vor allem Konfigurations- und Planungssysteme müssen ein befriedigendes Ergebnis aus einer großen Anzahl möglicher Varianten heraussuchen. Eine zentrale Rolle spielt dabei die Berücksichtigung von Bedingungen, im allgemeinen mit dem englischen Term constraints bezeichnet. Sie sollen nicht nur der Bewertung eines durch erschöpfende Suche gefundenen Lösungsvorschlags sondern auch der heuristischen Steuerung des Auswahlverfahrens dienen, um den Lösungsaufwand auf ein sinnvolles Maß zu reduzieren. Ein System zur Kupplungsauswahl demonstriert den Einsatz von Bedingungen. Zugleich wollen wir es auch verwenden, um noch eine weitere Alternative für die Benutzerschnittstelle, die Menüauswahl, vorzuführen.

Peter Schnupp, Chau Thuy Nguyen Huu

10. Die Systemeinbettung

Zusammenfassung

Bis jetzt hatten wir für die Systemeinbettung und, vor allem, die Interaktionen mit dem Benutzer wenig Aufwand investiert: im wesentlichen verließen wir uns hier auf die Dialogschnittstelle von Prolog. Für einen Prototypen, mit dem im wesentlichen die Funktionalität des Systemkonzepts erprobt und demonstriert werden soll, reicht dies in der Regel aus. Wir hatten aber auch schon mehrmals darauf hingewiesen, daß die Prolog-Schnittstelle für den Echteinsatz mit einer sowohl benutzerfreundlicheren als auch robusteren Dialog-Einbettung überdeckt werden muß. Eine Möglichkeit hierfür, die Menüführung, wollen wir in diesem Kapitel vorstellen. Außerdem werden wir darüber sprechen, wie man durch die Manipulation von “Metawissen“ die Suche intelligenter und damit effizienter ablaufen lassen kann; zum Beispiel dadurch, daß die Systemeinbettung für eine Protokollierung bereits erhaltener Ergebnisse sorgt, auf die dann später bei Bedarf wieder zurückgegriffen werden kann.

Peter Schnupp, Chau Thuy Nguyen Huu

11. Entwicklungspraxis

Zusammenfassung

Auch für die wissensbasierten Programmierung braucht man eine Projekttechnik. Aber man kann nicht unkritisch die klassische Softwaretechnologie übernehmen. Dafür gibt es eine Reihe Gründe. Den Unterschied zwischen Algorithmen und Daten, auf dem viele gewohnte Ideen und Techniken beruhen, gibt es nicht mehr. Weil “Wissen“ viel dynamischer ist als “Daten“, müssen Tätigkeiten wie Konzeption und Entwurfganz andere Ziele verfolgen und entsprechend umdefiniert werden. Das evolutorische Prototyping ist deshalb über alle “Phasen“ des Projekts hinweg die wichtigste und verbindende Technik. Dieses abschließende Kapitel versucht deshalb, eine Einführung in die “wissensbasierte“ Softwaretechnologie zu geben, die von der traditionellen Vorstellung eines Phasenmodells ausgeht. Es erklärt, warum die “Phasen“ jetzt keine Phasen mehr sind. Und es geht auf Konzepte ein, die es in der alten Technologie nicht gab, die jetzt aber eine wichtige Rolle in der Theorie und Praxis des Systementwurfs spielen; dies ist vor allem das Metawissen und wie man mit ihm umgeht. Vor allem aber geben wir Hinweise für die praktische Durchführung einer Expertensystem-Entwicklung.

Peter Schnupp, Chau Thuy Nguyen Huu

Backmatter

Title: Expertensystem-Praktikum
Authors: Dr. Peter Schnupp
Chau Thuy Nguyen Huu
Copyright Year: 1987
Publisher: Springer Berlin Heidelberg
Electronic ISBN: 978-3-662-00613-9
Print ISBN: 978-3-662-00614-6
DOI: https://doi.org/10.1007/978-3-662-00613-9