Expertensystemshell-Baukasten

Wiederverwendung möglichst mächtiger Komponenten ist ein wesentlicher Schlüssel zur kosteneffektiven Entwicklung von Informationssystemen. In diesem Kontext ist die enorme Popularität von VisualBASIC in der WINDOWS-Welt zu sehen, für das eine Vielzahl von sogenannten Custom Controls (VBX) oder OLE Controls (OCX) zur Verfügung stehen. Diese können, korrekte Funktionsweise vorausgesetzt, die Anwendungsentwicklung wesentlich beschleunigen.

Auch im Expertensystembereich wurde die Bedeutung von Wiederverwendung relativ früh erkannt und eine Vielzahl von Werkzeugen auf unterschiedlichen Abstraktionsniveau erstellt. Allgemeine, nicht problemspezifische Expertensystemwerkzeuge wie KAPPA oder SMART ELEMENTS erlauben zwar die Wiederbenutzung in Form von Regelinterpretern oder Objektsystemen, liegen jedoch auf einer sehr implementierungsnahen Ebene und bieten wenig konzeptionelle Unterstützung zur Realisierung der Problemlösung und für die Wissensakquisition. Zwischen den zur Verfügung gestellten Mechanismen und dem Denken des Experten klafft die oft beklagte Knowledge-Engineering-Lücke. Wesentlich erfolgversprechender ist die Entwicklung und Wiederbenutzung von konzeptuellen Modellen z.B. in Form von starken Problemlösungsmethoden, die eine modellbasierte Wissensakquisition erlauben.

Problemspezifische Expertensystemshells, die auf der Implementierung einer starken Problemlösungsmethode beruhen, erreichen einen sehr hohen Grad an Wiederverwendung. Im günstigsten Fall ist bei der Nutzung eines solchen Werkzeuges keine Implementierung in der zugrundeliegenden Programmiersprache nötig, der Aufwand zur Systemerstellung beschränkt sich auf den Aufbau der Wissensbasis. Durch das festgelegte Modell der Problemlösung ist es möglich, grafische Wissensakquisitionssysteme zu entwickeln, die von der internen Struktur der Wissensbasis abstrahieren und es Experten des Anwendungsbereichs nach kurzer Einarbeitungszeit erlauben, Expertensysteme selbständig ohne die Unterstützung durch eine Wissensingenieurin oder einen Wissensingenieur aufzubauen. Diese direkte Wissensakquisition durch Experten hat eine Reihe von signifikanten Vorteilen: Zum einen entfallen die üblichen Transfer- und Übersetzungsprobleme zwischen Wissensingenieur und Experte, zum anderen wird die Wartung immens erleichtert, die sonst von der weiteren Verfügbarkeit des Wissensingenieurs abhinge.

Obwohl problemspezifische Shells enorme Vorteile bieten, sofern sie für eine Anwendung geeignet sind, sind sie jedoch auf nur ein Modell der Problemlösung beschränkt und bezüglich der Integration neuer Mechanismen sehr unflexibel. Das kann dazu führen, daß Expertenwissen in unnatürlicher Weise umformuliert werden muß oder gar einen Werkzeugwechsel bedingen, so daß ein Irrtum bei der Werkzeugauswahl sehr hohe Kosten verursacht.

Expertensystemshell-Baukästen (Shell-Baukästen) stellen einen sehr attraktiven Kompromiß dar, der die Vorteile von problemspezifischen Shells beibehält, aber deren Flexibilität und damit auch das Einsatzspektrum deutlich erhöht. Die wesentlichen Ideen dabei sind die anwendungsspezifische Konfiguration von Problemlösungsmethoden und die Generierung zugehöriger Wissensakquisitionswerkzeuge.

Zur Konfigurierung einer Problemlösungsmethode werden die Methoden nicht mehr als monolithischer Block dargestellt und realisiert, sondern in kleinere Bausteine zerlegt. Zu einzelnen Bausteinen oder Unterbausteinen können alternative Realisierungen angegeben werden, so daß sich ein Konfigurationsbaum aus Aufgaben und Teilaufgaben ergibt, die jeweils von einer oder mehreren Methoden gelöst werden. Dieser Baum kann leicht um neue Realisierungsalternativen erweitert werden. Zusätzlich zu diesem Baum ist natürlich auch die Kontrolle und insbesondere die Wissensrepräsentation der Methoden zu spezifizieren. Sofern die Wissensrepräsentationen der zusammengehörigen Methoden nicht direkt verträglich sind, müssen entsprechende Abbildungsvorschriften angegeben werden, die das Wissen entsprechend transferieren. Zur Auswahl einer konkreten Problemlösungsmethode wird dann das Konfigurationsproblem gelöst, also Entscheidungen für alle Alternativen getroffen. Diese Entscheidungen können z.B. aufgrund der Verfügbarkeit von Wissen oder Laufzeitanforderungen an das System getroffen werden. Falls keine zufriedenstellende Konfiguration gefunden werden kann, ist der Konfigurationsbaum entsprechend zu erweitern. In Abb. 1 findet sich ein Konfigurationsbaum für die Diagnostik.