Produktionsregeln schließen Widersprüche nicht aus

Funktionale Sprachen sorgen für eine bessere Konsistenz

08.02.1991

* René Nowotny ist im Produktmarketing der Software AG, Darmstadt, verantwortlich für Wissensbasierte Systeme und Objektorientierung.

In dem Maße, wie Expertensysteme Einzug in die generelle Anwendungsentwicklung halten, stellt sich die Frage nach der Genauigkeit ihrer Ergebnisse. René Nowotny* verweist in diesem Zusammenhang auf die Schwachstellen der klassischen Produktionsregeln und die Vorteile sogenannter funktionaler Sprachen.

Nach Experimenten mit Nischenanwendungen und isolierten Expertensystemen werden die wissensbasierten Systeme allmählich zu Werkzeugen der generellen Anwendungsentwicklung. Welche Rolle werden sie dort spielen, und wie können sie dieser Rolle gerecht werden? Eines steht bereits fest: Die technische Integration allein wird nicht reichen.

Mit dem Wechsel der Einsatzgebiete haben sich auch die Eigenschaften wissensbasierter Systeme verändert. Bis vor kurzem war ein Expertensystem zur Fehlerdiagnose in einer Ablaufumgebung auf PC/MS-DOS-Basis ein typisches Anwendungsbeispiel.

Inzwischen aber werden wissensbasierte Ansätze auch in "alltäglichen" Bereichen verwendet. Zu denken ist etwa an die Erweiterung eines existierenden Management-Informationssystems um eine wissensbasierte Komponente, die zum Beispiel automatisch auf Probleme hinweist.

Für ein solches System wird dann natürlich eine geeignete Schnittstelle zur existierenden Applikation und zu einem Datenbanksystem benötigt. Die entsprechende Technologie wird bereits in einigen Mainframe-Werkzeugen angeboten. Eine gründliche Darstellung der technischen Probleme und eine ausführliche Werkzeug-Übersicht bietet beispielsweise R. Kerry in seinem 1990 bei Ellis Horwood erschienen Buch "Integrating Knowledge-based and Database Management Systems".

Die Frage noch der Korrektheit

In den beiden oben angeführten Beispielen werden allerdings unterschiedliche Probleme gelöst. Beim Diagnosesystem geht es darum, eine Anwendung möglichst schnell und problemlos zu realisieren. Das System braucht dafür nicht unbedingt widerspruchsfrei oder völlig korrekt zu sein. Eine Trefferquote von 80 Prozent oder noch weniger wäre wahrscheinlich völlig zufriedenstellend.

Im zweiten Beispiel aber geht es um etwas ganz anderes: Hier wird ein wissensbasiertes System als Werkzeug der Anwendungsentwicklung eingesetzt. Man kann sich leicht vorstellen, daß man im nächsten Schritt prozedurale - oder "klassische" - und wissensbasierte Module in ein und derselben Anwendung frei mischt, je nachdem, welcher Ansatz sich für die jeweilige Problemstellung besser eignet.

Neben der Forderung nach hoher Produktivität und leichter Wartbarkeit steht damit die Frage nach der Korrektheit der wissensbasierten Module im Raum. Denkt man zum Beispiel an Schreibzugriffe auf Datenbanken, an Fakturierung oder Entscheidungsunterstützung, so wird klar, daß man diesem Problem nicht ausweichen kann.

Damit erklärt sich der Trend, der sich im letzten Jahr herausgeschält hat: die Suche nach Methodologien zur Entwicklung wissensbasierter Systeme und die Entwicklung eines entsprechenden Software-Engineerings. Die althergebrachten Ansätze für Expertensysteme, wie zum Beispiel exploratives Programmieren, sind nämlich offensichtlich ungeeignet, um wirklich korrekte, konsistente Systeme zu entwickeln. Einen Beitrag zur Diskussion von Methodologien für wissensbasierte Systeme leistet der 1989 ebenfalls bei Ellis Horwood veröffentlichte Band "Analysis for Knowledge-based Systems" von F. R. Hickman, J. L. Killin, L. Land, T. Mulhall, D. Porter und R. M. Taylor.

Jedoch noch einen Schritt weiter: Nicht nur das explorative Programmieren ist untauglich für die Entwicklung konsistenter wissensbasierter Systeme. Auch die älteste und verbreitetste Wissensrepräsentations-Technik, nämlich die Produktionsregel, erweist sich als ungeeignet, wenn operative Anwendungen entwickelt werden sollen.

Eine Produktionsregel hat eine sehr einfache Struktur, nach dem Schema "IF Bedingung THEN Aktion" und war daher für den ursprünglich angestrebten Einsatz von wissensbasierten Systemen gut geeignet: Der Fachmann sollte wenn möglich, allein ein System entwickeln, und dazu brauchte er eine simple Wissensrepräsentations-Technik.

Möglichst stark problemorientiert

Inzwischen haben sich die Akzente zu operativen Anwendungen verschoben, man spricht von Wissensingenieuren und diskutiert über "Knowledge-Engineering", Systemanalyse und Methodologie. Damit entfällt die Notwendigkeit einer möglichst einfachen Wissensrepräsentations-Technik, es wird vielmehr ein stark problemorientierter Formalismus benötigt.

In fortgeschrittenen Werkzeugen wird nun oft ein objektorientierter Ansatz verwendet. Objektorientierung an sich ist aber keine Repräsentations-, sondern eine Organisationstechnik; man spricht in diesem Zusammenhang auch von "Programming in the Small" und "Programming in the Large".

Ein objektorientierter Ansatz kann mit jeder beliebigen Repräsentationstechnik verknüpft werden, typischerweise mit prozeduralem Code und Produktionsregeln. Nur durch die objektorientierte Organisation kann man beim Aufbau großer wissensbasierter Systeme überhaupt mit Produktionsregeln "leben".

Wo liegt also das Problem? Weil Produktionsregeln "einfach" sind, ist es leicht, damit "einfache" Dinge abzubilden, aber extrem schwierig, komplexere Sachverhalte zu formalisieren - schlimmer noch: Es ist praktisch unmöglich sicherzustellen, daß eine Menge von Produktionsregeln tatsächlich ein konsistentes System darstellt, so daß nicht widersprüchliche Tatsachen gleichzeitig wahr sein können. (Aus einem Widerspruch folgt bekanntlich die Wahrheit jeder beliebigen Aussage.)

Diesem Problem ist grundsätzlich nicht beizukommen, weil es auf einer kombinatorischen Explosion beruht. Begriffe wie "Conflict Resolution Mechanism" und "Erklärungskomponente" werden eigentlich nur aufgrund dieser Tatsache diskutiert.

Will man ein komplexes Problem im Rahmen einer Anwendung mit einem wissensbasierten System lösen, wäre es wünschenswert, wenn das Werkzeug die formale Korrektheit und Widerspruchsfreiheit automatisch garantieren könnte. Das ist aber sowohl für prozeduralen Code als auch für Produktionsregeln praktisch unmöglich.

Inzwischen gibt es jedoch die Repräsentationstechnik der funktionalen Sprachen. Diese Sprachen basieren, wie auch die Programmiersprache Lisp, auf dem Lambda-Kalkül, was man den stark typisierten Vertretern dieser Gattung wie Hope, Miranda oder Natural EL aber nicht mehr sofort ansieht.

Der Sprachkern ist typischerweise sehr klein, aber recht mächtig, denn Funktionen sind dort "Bürger erster Klasse"; man kann also zum Beispiel eine Funktion als Parameter an eine andere übergeben, und eine neue Funktion zurückerhalten (daher übrigens auch die Bezeichnung "funktionale Sprachen").

Um ein System zu bauen, schreibt der Entwickler eine Reihe von Definitionen auf. Da es nur Definitionen gibt, arbeitet er rein deklarativ; im Gegensatz zu Produktionsregelsystemen läßt sich alles, was es über ein Objekt zu wissen gibt, aus seiner Definition beziehen.

Diese als "referentielle Transparenz" bezeichnete Eigenschaft schließt Seiteneffekte aus und ermöglicht eine Behandlung der Wissensbasis mit mathematischen Methoden. Damit können Konsistenz, Vollständigkeit und formale Korrektheit der Wissensbasis automatisch garantiert werden. Die Vorteile für Produktivität und Wartungsphase liegen auf der Hand.

Da jede neue Definition den ursprünglichen Sprachumfang erweitert, kann man problemorientiert arbeiten, indem man jeweils benötigte Konstrukte einfach definiert. Polymorphe abstrakte Datentypen ermöglichen sofort objektbasiertes Programmieren; durch Einführen eines Vererbungskonzepts läßt sich auch voll objektorientiert arbeiten.

Diese inhärenten Eigenschaften machen funktionale Sprachen zu einer hervorragenden Wissensrepräsentationstechnik. Es ist sogar möglich, sie einzusetzen wie eine formale Spezifikationssprache, nur ist das Ergebnis sofort ausführbar.

Noch sind funktionale Sprachen ziemlich unbekannt, aber es gibt bereits die ersten kommerziellen Anwendungen. In den 90er Jahren wird dieser moderne Ansatz mit Sicherheit seine Rolle in wissensbasierten Systemen und im Software-Engineering spielen.

Eine Liste aller Vorteile funktionaler Sprachen wäre im Rahmen dieses Artikels zu lang, besonders wenn man auch noch die allgemeine Rolle funktionaler Sprachen im Software-Engineering diskutiert. Eine gut verständliche, knappe Einführung geben die ersten Kapitel des von S. Eisenbach herausgegebenen und 1987 bei Ellis Horwood erschienenen Buches "Functional Programming".

Darüber hinaus behandeln D. Ince und D. Andrews dieses Thema in drei Kapiteln ihres 1990 bei Butterworths publizierten Buches "The Software Life Cycle". Wer wenig Zeit hat, dem sei der Artikel "Functional Programming Languages as a Software Engineering Tool" von S. L. Peyton Jones empfohlen, der in dem 1986 bei Peter Peregrinus erschienenen und von D. Ince herausgegebenen Band "Software Engineering - The Critical Decade" zu finden ist.