Bei der Entwicklung von Expertensystemen sind eine schlechte Projektplanung und der falsche Einsatz von Technologien häufig der Grund für vorzeitige Projektabbrüche. Dies würde nach Einschätzung von Hartmut Krasemann nicht passieren, wenn sich die Anwender die Tugenden des Software-Engineerings ins Gedächtnis riefen. Das Vorgehen läßt sich großen Teils auch auf die Expertensystem-Entwicklung anwenden, wenngleich aufgrund der Komplexität der Aufgabe einige Ergänzungen nötig werden. (Teil 1 in CW Nr. 6, Seite 29).

Die vorgestellte Projektierungsphase für ein Expertensystem kann vollständig auf dem Papier erfolgen. Die Ergänzung der Projektierungsphase durch den Bau eines Prototypen ist in vielen Fällen möglich, aber verzichtbar, in einigen Fällen angezeigt, zum Teil aber auch absolut unverzichtbar.

Zunächst einmal sei festgestellt, wozu Prototyping nicht eingesetzt werden kann: Mit Prototyping allein können weder Anforderungen ermittelt noch Lösungskonzepte gefunden werden. Die Expertensystem-Welt wimmelt nur so von Beispielen. Viele Prototypen sind so entstanden, daß mit einer Anwendungsidee eine Shell beschafft wurde und dann explorativ, das heißt Anforderungen und Lösungskonzepte erforschend, eine Wissensbasis versuchsweise implementiert und erweitert wurde.

Anstoß zu besseren Lösungskonzepten

Mir ist kein Fall bekannt, der zu einem erfolgreichen System geführt hätte. Allerdings gibt es eine - eingangs beschriebene - Konstellation, in der exploratives Prototyping angebracht ist: wenn für die Aufarbeitung eines Wissensgebietes noch Forschungsarbeit zu leisten ist.

Mit Prototyping allein ist auch keine inkrementelle Systementwicklung möglich. Auch die muß sorgfältig geplant werden, wenn die Kosten nicht ins Uferlose davonlaufen sollen. Eine inkrementelle Systementwicklung ist gegebenenfalls Ergebnis der Realisierungsplanung.

Trotzdem ist Prototyping in einer kontrollierten Form (Vergleiche Abbildung 3) sinnvoll und in folgenden Fällen sogar notwendig:

1. Wenn die Lösungskonzepte vorliegen, können sie mit Hilfe eines Prototyps validiert werden. Dafür werden die Wissensstrukturen und Lösungsalgorithmen, die zu den Bereichen des Systems mit besonders hohem technischen Risiko gehören, im Prototyp implementiert, um das Risiko zu senken. Mit anderen Worten: Ein Teil der Wissenserhebung und Implementierung wird vorweggenommen, um zu beweisen, daß die Lösungskonzepte Bestand haben.

Hier kann sich zeigen, daß bestimmte Lösungskonzepte falsch sind. Die prototypische Implementierung gibt oft auch den Anstoß zu vorher nicht bedachten neuen und besseren Lösungskonzepten. Damit wird der Prototyp zum Ausgangspunkt für ein Redesign.

2. Die Benutzer-Schnittstelle kann prototypisch, das heißt in ihren wesentlichen Zügen, implementiert werden. Damit kann die Oberfläche schon in der Projektierungsphase von den späteren Anwendern validiert werden. Da Benutzer-Schnittstellen von Expertensystemen in Unternehmen meistens keine Vorbilder haben, ist ihre Funktionalität ohne einen Prototyp für die späteren Anwender kaum vorstellbar.

Hier gilt, daß die Änderung von Anforderungen während der Projektierung mit viel geringeren Kosten verbunden ist als wenn dies in späteren Phasen geschähe. Hinzu kommt, daß eine überzeugende Demonstration des späteren Systemnutzens ohne einen Prototyp mit Benutzeroberfläche nur schwer möglich ist.

Was ist zu beachten für das kontrollierte Prototyping? Auch ein Prototyp kann nur Antworten geben auf Fragen, die vorher gestellt wurden. Das heißt, vor dem Prototyping ist festzulegen, welche "kritischen Fragen" durch den Prototyp beantwortet werden sollen. Kritische Fragen können solche nach der Gültigkeit bestimmter Lösungskonzepte sein oder nach der Handhabung bestimmter Teile der Benutzeroberfläche.

Als Werkzeug für das Prototyping von Benutzer-Schnittstellen kommt im Idealfall ein mächtiger GUI-(Graphical User Interface) Baukasten in Frage. Für das Prototyping der Lösungskonzepte, also der Wissensstrukturen und Algorithmen, sollte eine wissensbasierte Spezifikationssprache zum Einsatz kommen, die durch das teilweise Auffüllen mit Wissen als Prototyp animiert wird.

Dieser ldealfall ist nicht unrealistisch. Der Prototyp für ein Computerdiagnose-System wurde beispielsweise auf diese Art erstellt: Die Wissensbasis über Computer-Hardware-Komponenten mit ihren Eigenschaften wurde mit der wissensbasierten Spezifikationssprache SML spezifiziert und anschließend mit Wissen gefüllt. Dazu kam die Implementierung eines Lösungskonzepts in Prolog, nämlich die Diagnose-Strategie. Die Benutzerschnittstelle schließlich wurde mit dem objektorientierten GUI-Baukasten PCE erstellt.

Dies alles, hergestellt in wenigen Personenwochen, ist als Prototyp bereits ein lauffähiges Programm, allerdings ohne jede Optimierung.

Prototyping mit kleinen Abstrichen

In der Praxis trifft man oft Randbedingungen, die den eben beschriebenen Idealfall ausschließen. Dazu zählen Hardware- oder Software-Anforderungen - zum Beispiel der Einsatz von Betriebssystemen, unter denen Werkzeuge der eben beschriebenen Art nicht verfügbar sind. Dann läßt sich Prototyping auch mit kleinen Produktivitätsabstrichen einfach mit universellen KI-Programmiersprachen und Standard-GUI-Paketen durchführen, zum Beispiel auf erneut PC mit der einfachen Kombination von Prolog und GEM.

Die Realisierungsphase gründet auf den in der Projektierungsphase entwickelten Plänen, sie ist geprägt von dem dort ausgewählten Werkzeug. Möglicherweise wurde eine Expertensystem-Schale benutzt, die alle Anforderungen bezüglich Einsatz, Nutzung und Pflege abdecken kann. Vielleicht muß aber auch wegen der vielen anwendungsspezifischen Funktionen auf einen Verbund von konventionellen und KI-Programmiersprachen zurückgegriffen werden - dann ist der größte Anteil der Software, die hier erstellt wird, konventionell.

Selbst in Stand-alone-Expertensystemen liegt dieser konventionelle Anteil oft zwischen 50 und 80 Prozent. Dahinter stecken viele Zusatzfunktionen, die für den Einsatz des Expertensystems unverzichtbar sind. Dazu zählen nicht nur die Wissenspflege-Komponente und die Anbindung an vorhandene Datenbanken, sondern auch Mechanismen zum Schutz der Wissensbasis gegen unbefugte Verwendung, zur Sicherung vor Ort erhobenen Wissens, zum Aktualisieren der Wissensbasis seitens der Zentrale, zum Datenaustausch mit anderen Programmen, zur Protokollierung der Konsultationen der Wissensbasis oder weitere Hilfsprogramme zur Aufbereitung der Protokolle für die Wissenspflege.

Insgesamt haben wir es also mit einem komplexen, konventionellen Softwaresystem zu tun, das eine wesentliche wissensbasierte Programmkomponente enthält. Für das konventionelle System gelten alle Regeln des traditionellen Software-Engineering, für die wissensbasierte Komponente kommt etwas hinzu. Nach diesen Regeln verläuft die Realisierung in den Schritten "Detailliertes Design und Testspezifikation", "Implementierung und Formulierung der Tests", "Durchführung der Tests und Abnahme", die wir an dieser Stelle nicht weiter diskutieren müssen.

Für die wissensbasierte Komponente finden wir auf jeden Fall die Aktivitäten

- Detaillierte Wissenserhebung und Erstellung der Wissensbasis,

- Testen der Wissensbasis,

- Dokumentation der Wissensbasis.

Genausowenig wie heute eine allgemeingültige Theorie der Wissensrepräsentation besteht, die sich etwa in einem standardisierten Wissensrepräsentations-Formalismus niederschlägt, gibt es eine Theorie der Wissenserhebung. Deshalb ist die Methodik der Wissenserhebung im Einzelfall festzulegen. Sie wird abhängig sein von der Komplexität und Struktur des Wissens selbst sowie von der Verfügbarkeit und dem Temperament des Experten. Die Praktiker sind sich einig, daß verschiedene Arten des Interviews - je nach Experte - herangezogen werden können.

Um so wichtiger ist die Überprüfung des formalisierten, vom Programm verwendeten Wissens. Dessen Kontrolle sollte in jedem Falle der Experte vornehmen - deshalb kommt es sehr auf die Lesbarkeit und Verständlichkeit des repräsentierten Wissens an. Aus diesem Grunde sollte der Wissensingenieur das Wissensmodell anwendungsnah programmieren und so wenig softwaretechnische "Tricks" wie möglich einbauen.

Um dies zu erreichen, müssen die in der Analyse- und Designphase gefundenen Wissensschichten angemessen repräsentiert sein. Der Experte muß im ersten Validierungsschritt beurteilen, ob das im Wissensmodell enthaltene Wissen korrekt und ausreichend ist.

Die Validierung wird erheblich einfacher, wenn das Programm, das auf der Wissensbasis arbeitet, bereits vorhanden ist. Setzt der Anwender keine Shell ein, so sollte er die erste Version der Inferenzmaschine zu diesem Zeitpunkt nach Möglichkeit schon zur Verfügung haben. Dann nämlich läßt sich die Wissensbasis ausführen, das heißt, ein Prototyp steht zur Verfügung, der das Verstehen und Beurteilen der Wissensbasis erheblich erleichtert.

Wissensbasen müssen gut dokumentiert sein

Die Schritte Interview, Modellieren, Ausfüllen der Strukturen mit Wissen, prototypisches Ausführen des Modells und Beurteilen des Modells hinsichtlich Korrektheit und Vollständigkeit sollten in zwei bis drei Zyklen durchlaufen werden mit jeweils wachsender Wissensbasis. Parallel dazu werden Tests für die Wissensbasis festgelegt. Diese haben wie üblich zwei Funktionen: Sie belegen die Abnahmereife der Wissensbasis, und sie dienen als Grundstock der Regressionstests, die der Anwender für die Weiterentwicklung des Expertensystems in der Einsatzphase braucht.

Tests haben zwei Ziele: Erstens sollen sie die Korrektheit eines Systems zeigen und zweitens die Vollständigkeit bezüglich der Anforderungen. Das zweite Ziel müssen wir für die Wissensbasis relativieren, da ihr Wissensumfang während der System-Benutzungszeit wachsen soll - die Vollständigkeit ist also nie eindeutig definiert. Um so wichtiger sind die Tests für den Nachweis der Korrektheit der Wissensbasis.

Während es in konventionellen Programmen viele Programmierfehler gibt, stehen in Wissensbasen Designerfehler im Vordergrund, und zwar unzureichende Strukturen des Wissens oder auch fehlende Wissenselemente. Hoffnung auf eine mächtige Unterstützung durch die Maschine selbst lassen hier die ersten logikbasierten Wissensrepräsentations-Formalismen aufkommen, die es gestatten, zumindest die Widerspruchsfreiheit der Wissensbasis zu beweisen.

Wenn der Experte darüber hinaus die einzelnen Wissenselemente als richtig beurteilt, ist eine hohe Sicherheit für die Korrektheit des Systems erreicht. Wissensbasen müssen natürlich im Hinblick auf die Wissenspflege besonders gut dokumentiert werden. Wird eine Shell verwendet, so ist man vollständig auf die Dokumentationsmittel der Shell festgelegt.

Bei der Verwendung einer Programmiersprache stellt sich oft die Aufgabe, auch entsprechende Dokumentationswerkzeuge zu schaffen. Ein "Listing" der Wissensbasis im Sinne der verwendeten Programmiersprache reicht in den seltensten Fällen aus.

Hier kommt es darauf an, die Strukturen der Wissensbasis aus allen wesentlichen Aspekten zu dokumentieren, das heißt, für jede wichtige Sicht auf die Wissensbasis eine Dokumentation zu erzeugen. Dies muß automatisiert ablaufen, schon um die Fortschreibung der Dokumentation im Betrieb des Expertensystems zu gewährleisten. Das Projektmanagement schließlich ist in Expertensystem-Projekten gefordert, diese Aktivitäten zu berücksichtigen, zu planen und zu kontrollieren. Die Qualitätssicherung legt zu Beginn des Projektes formale Prüfungen bezüglich der hier diskutierten Inhalte fest.