Der Einsatz von Expertensystemen beim Software-Engineering steckt noch in den Kinderschuhen. Bereits existierende Systeme unterstützen bestenfalls einzelne Entwicklungsphasen. Die Arbeit eines Entwicklers wird ein KI-System auch in ferner Zukunft nicht ersetzen können, so Gerhard Barth.

Die wichtigste Frage im Zusammenhang mit der Entwicklung und dem Einsatz von Expertensystemen für Software-Engineering muß lauten, welchen Nutzen eine solche Vorgehensweise erbringt. Es gibt eine ganze Reihe von Voraussetzungen und Gründen an, welche die Berücksichtigung der Expertensystem-Technologie bei der Lösung von Problemen rechtfertigen. So ist zum Beispiel zu prüfen, ob

* der massive Einsatz von Alltagswissen (common sense) erforderlich ist,

* Experten des betrachteten Themenkreises zur Verfügung stehen,

* Kriterien für die Beurteilung der Qualität von Lösungen existieren,

* die zu lösenden Probleme eine nicht zu hohe Komplexität besitzen,

* die Erstellung von Lösungen heuristische Methoden erfordert.

Expertensysteme noch stark unterentwickelt

Die Erstellung von Software ist sicherlich keine algorithmisch lesbare Aufgabe. Trotz aller Fortschritte bei der Entwicklung formaler Hilfsmittel entziehen sich insbesondere die frühzeitig zu durchlaufenden Phasen, nämlich Anforderungsdefinition, Analyse und Design, sowie die spätere Wartung allen versuchen einer programmierbaren Behandlung. Mit Sicherheit fließen hier heuristische Überlegungen in die Gedanken und Ideen eines jeden Software Engineers ein.

Heutige Expertensysteme sind hinsichtlich der Berücksichtigung alltäglichen Wissens noch stark unterentwickelt. Dies liegt zum einen an der Masse der Erkenntnisse; ihre explizite Darstellung und Speicherung würde Wissensbasen leicht zum Überlaufen bringen. Nun ist aber die Erstellung von Softwaresystemen in erster Linie ein ingenieurmäßig betriebener Vorgang, bei dem üblicherweise die Verwendung von Alltagswissen keine dominierende Rolle spielt.

Es gibt sicher eine ganze Reihe von Software-Entwicklern, die sich für die Erstellung von Programmen Fähigkeiten angeeignet haben und damit Expertenstatus erreichen. Dazu gehören Fertigkeiten zur Spezialisierung und Verallgemeinerung von Lösungsprinzipien, zum Erkennen kritischer Sonderfälle und Ausnahmen, Lernfähigkeit, Beherrschung komplizierter und spezialisierter Werkzeuge und ähnliche Dinge mehr. Software-Experten stimmen meist auch überein, wenn es um die Beurteilungskriterien für die Qualität eines Systems in seiner jeweiligen Einsatzumgebung geht. Damit sind bis auf Punkt vier alle eingangs erwähnten Kriterien erfüllt.

Entwickler bedient sich mehrerer KI-Systeme

Kritisch wird die Debatte nach der Verwendbarkeit von Expertensystemen beim Software-Engineering in der Frage, ob die Komplexität der Problemstellung für ihren Einsatz hinreichend eingeschränkt ist. Viele Entwickler können von der Mitwirkung bei Projekten mit Hunderten von Mannjahren, Millionen an Programmzeilen, einer Vielzahl hochinteraktiver Module berichten. Die Erwartung, derartige Mammutvorhaben mittels eines Expertensystems auf das Niveau von routinemäßigen Arbeitsvorgängen zu vereinfachen ist natürlich utopisch.

In erster Linie lassen sich nur Teilbereiche des Software-Engineerings von Expertensystemen übernehmen. Es ist vorstellbar, daß sich der Software-Entwickler mehrerer Expertensysteme bedient, die ihn während verschiedener Phasen bei seiner Arbeit unterstützen. Expertensysteme erfüllen keine Handlangertätigkeiten, sondern sind in der Lage, komplizierte Dienste zu leisten, vorausgesetzt sie weiden vom Benutzer auf kompetente Art und Weise eingesetzt. Selbst wenn eines Tages ausgefeilte und leistungsfähige Expertensysteme für die Unterstützung einzelner Phasen der Software-Engineerings existieren werden, so werden diese Systeme keinesfalls gute Entwickler von Programmen überflüssig machen. Die hohe Kunst der menschlichen Experten wird dann darin bestehen als integrierendes Bindeglied zwischen Expertensystemen und anderen Werkzeugen zu fungieren.

Fazit 1: Die bestehende Technologie von Expertensystemen eignet sich für die Anwendung auf einzelne Phasen des Software-Engineerings. Welche dafür in Frage kommen, wird etwas später diskutiert werden.

Die Feststellung, daß Expertensysteme für einen bestimmten Problembereich realisierbar sind, darf nicht die einzige Motivation für ihre Entwicklung sein. Weitere Gründe rechtfertigen die Realisierung von Expertensystemen:

* Menschliche Expertise ist im Moment noch vorhanden, es besteht aber die Gefahr, sie zu verlieren (Arbeitsplatzwechsel, Ruhestand).

* Menschliche Expertise ist nicht an ausreichend vielen Stellen vorhanden (Filialen, verteilte Projekte).

* Menschliche Expertise ist aufgrund eines kleinen Angebots aber hoher Nachfrage teuer.

Menschliche Expertise nicht immer vorhanden

Jeder dieser Punkte ist bereits für sich alleine genommen ein ausreichender Grund für den Versuch, menschliche Expertise in Form maschineller Expertensysteme zu modellieren. Für das Software-Engineering treffen ohne Zweifel sogar alle Aspekte zu. Nicht das eifrige Studium von Literatur und Produkten anderer Leute, sondern erst eigenständige praktische Erfahrungen machen einen guten Entwickler. Eine Konservierung von Software-Engineering Expertise ist deshalb äußerst erstrebenswert. Daß gute Software-Engineers knapp und teuer sind, und außerdem aufgrund des immer stärker wachsenden Einsatzes von Computern und der damit steigenden Nachfrage an Programmen ein zunehmender Bedarf an Experten besteht, weiß jeder Kenner der Materie.

Es gibt zahlreiche Varianten zur Modellierung des Software Engineering. Üblicherweise werden als einzelne Phasen Anforderungsanalyse, Spezifikation, Entwurf, Codierung, Test und Wartung unterschieden. Doch welche dieser Entwicklungsabschnitte eignen sich für den Einsatz von Expertensystemen?

Anforderungsanalyse hat zum Ziel, die Wünsche des Auftraggebers mit Merkmalen des jeweiligen Problembereichs in Einklang zu bringen. Dabei ist in erster Linie auf Vollständigkeit und Konsistenz der Anforderungen zu achten. Es existieren derzeit einige Werkzeuge, welche in dieser Phase des Software-Engineering einsetzbar sind, wie etwa SREM und SADT. Die richtige Verwendung dieser Hilfssysteme erfordert sicherlich Expertise, die nicht algorithmisierbar ist.

In erster Linie auf Vollständigkeit achten

SADT ist jedoch von dem jeweiligen Anwendungsbereich abhängig. Ein entsprechendes Expertensystem müßte also nicht nur SADT-spezifisches Wissen, sondern auch in ganz beträchtlichem Umfang Wissen über das entsprechende Problemgebiet beinhalten. Existierende wissensbasierte Systeme für die Durchführung von Konfigurationsaufgaben, etwa das legendäre XCON, könnten eine Orientierungshilfe für die Entwicklung von Expertensystemen sein, welche die Anforderungsanalyse unterstützen sollen. XCON durchforstet zunächst Kundenwünsche hinsichtlich Vollständigkeit und Widerspruchsfreiheit. Das System weist auf fehlende Angaben hin, schlägt Ergänzungen vor, macht auf nicht miteinander zu vereinbarende oder nicht sinnvoll kombinierbare Anforderungen aufmerksam, führt also Anforderungsanalysen durch.

Die Spezifikationsphase des Software-Engineering geht häufig Hand in Hand mit der Anforderungsanalyse. Die Verzahnung dieser beiden Phasen ist ja auch naheliegend, denn einerseits müssen Anforderungen formal erfaßt werden, und andererseits kann gerade das Erstellen von funktionalen Spezifikationen Lücken in den Kundenwünschen hinsichtlich Vollständigkeit und Konsistenz aufdecken. Folglich sollte es auch möglich sein, Expertensysteme für die Spezifikation von Softwaresystemen zu erstellen. Diese müßten sinnvollerweise auf Protokolle der Anforderungsanalyse zugreifen können. Das Expertensystem könnte somit einen direkten Bezug zu den Vorstellungen des Auftraggebers hinsichtlich quantitativer und qualitativer Merkmale des zu entwickelnden Programms herstellen.

Ein existierendes Expertensystem dieser Art führt den Entwurf von Programmen nach der Jackson-Methode durch. Es unterstützt dabei in seiner bisher fertiggestellten Version die Strukturierung von Daten sowie die Erstellung von Relationen zwischen Datentypen. Es wurde ein Regelsystem entwickelt, welches alle kennzeichnenden Merkmale der Jackson-Methode erfaßt. Diese ist nur eine von vielen verschiedenen Vorgehensweisen beim Entwurf von Softwaresystemen. Sie hat gegenüber anderen Techniken, wie etwa der schrittweisen Verfeinerung oder HIPO, den großen Vorzug einer recht hohen Formalisierbarkeit, ohne jedoch vollständig algorithmisierbar zu sein. Dies bietet gute Ansatzpunkte für die Erfassung der Jackson-Entwurfsmethode durch Expertensysteme.

Automatische Generatoren für jede gängige Sprache

Die Codierungsphase der Programmierung ist weitgehend mechanisierbar. Automatische Codegeneratoren gibt es für jede gängige Programmiersprache. Ihre Arbeitsweise ist im allgemeinen nicht mit dem Prädikat "intelligent" zu versehen; vielmehr machen sie sich gängige Algorithmen des Übersetzerbaus zu eigen. Codegeneratoren arbeiten normalerweise syntaxgesteuert, das heißt auf einer syntaktischen Analyse werden Aktionen zur stufenweisen Umwandlung von vorhandenen Strukturen in Ausdrucksmittel einer Zielsprache ausgelöst. Diese Vorgehensweise ist effizient und in breitem Umfang anwendbar. Die Erstellung von Expertensystemen für die Codierungsphase erscheint damit wenig sinnvoll zu sein.

Die Durchführung geeigneter Tests ist eine unabdingbare Voraussetzung für die Erstellung sicherer Software. Leider wird diese Phase allzu häufig als ein lästiges Übel betrachtet und nicht als ein konstruktiver Beitrag zur Qualitätssicherung. Nur wenige Entwickler beherrschen eine hinreichend große Anzahl von Testverfahren, von denen es ein ganz beachtliches Spektrum gibt. Die Auswahl der richtigen Methode und ihre nutzbringende Anwendung verlangt Expertise.

Diese betrifft die Organisation von Tests, die Auswahl von Testdaten, die Vorhersage des Systemverhaltens, die Interpretation der Testresultate, sowie das Aufspüren von Fehlerquellen. Mit anderen Worten, wesentliche Gründe für den Bau eines Expertensystems sind gegeben. Bleibt die Frage nach der Machbarkeit eines solchen Unterfangens. Die einschlägige Literatur kommt zu eher pessimistischen Resultaten, sowohl was die Kategorie, von Black-box- als auch die von White-box-Tests anbelangt. Für Black-box-Methoden sei entweder noch zu wenig Expertenwissen vorhanden; oder aber es sei so schlecht strukturiert, daß es sich der Erfassung in einer Wissensbasis entzieht. White-box-Testverfahren würden viel zu tiefes Verständnis komplizierter semantischer Aspekte von Programmiersprachen erfordern.

Jedermann weiß um den dominierenden Wartungsanteil bei Entwicklungskosten. Es wäre deshalb in besonderem Maße wünschenswert, für diese Phase eine gute Unterstützung durch entsprechende Werkzeuge zu erhalten. Wartung umfaßt insbesondere die Beseitigung zu spät entdeckter Fehler. Es gibt, so könnte man argumentieren, eine ganze Reihe von Expertensystemen zur Diagnose von fehlerhaftem Verhalten von Hardwarekomponenten, folglich müßten doch auch entsprechende Systeme für Softwarepakete zu erstellen sein.

Automatische Fehlerdiagnose für Hardware ist im allgemeinen beschränkt auf Bauteile, deren richtige Funktionsweise und Aufbau wohlbekannt ist. Die Strukturen verschiedener Programme weichen meist jedoch so stark voneinander ab, daß der Umfang an benötigtem Wissen über mögliche Fehlerquellen und Fehlerursachen riesig ist. Das von der Wartung zu diagnostizierende und zu beseitigende Fehlverhalten von Softwaresystemen ist im allgemeinen ja von sehr verzwickter Natur, denn lexikalische und syntaktische Fehler hat der Compiler (hoffentlich!) längst aufgespart. Der Wurm steckt normalerweise noch in logischen Fehlern und kann zudem seit seiner eigentlichen Entstehung durch zahlreiche andere Entwurfsentscheidungen verfälscht worden sein. Es bleibt unter dem Strich also die Erkenntnis übrig, daß in erster Linie die frühen Phasen des Software Life Cycles von Expertensystemen profitieren könnten.

Die vorangegangenen Ausführungen waren stark geprägt von dem heutzutage noch dominierenden Phasen-Paradigma des Software-Engineering. Diese Vorgehensweise hat neben unbestreitbaren Vorzügen auch Nachteile. So pflanzen sich fehlerhafte Entwurfsentscheidungen einer Phase in späteren Phasen fort. Der im Idealfall linear ablaufende Entwicklungsprozeß ist in der Praxis deshalb von vielen Rückkopplungen durchsetzt.

Eine der wichtigsten Alternativen zum Phasenmodell ist das sogenannte Rapid Prototyping. Hier wird versucht, möglichst schnell eine Version des gewünschten Systems zu realisieren, dessen operationales Verhalten beobachtbar ist. Am einfachsten gelingt dies durch Erstellen von funktionalen Spezifikationen die mit Hilfe eines geeigneten Interpreters zum Leben erweckt werden können. Heutige wissensbasierte Expertensysteme sind eigentlich nichts anderes als besonders komplexe Ausprägungen dieser Idee. Die Wissensbasis enthält in Form von Rahmen, Produktionsregeln, Horn-Klauseln oder einer sonstigen Wissensrepräsentation die Spezifikationen zum jeweiligen Problembereich. Die Inferenzkomponente ist in der Lage, Wechselwirkungen der Spezifikationen aufzusparen und dem Benutzer anzuzeigen. Modernes Software-Engineering könnte sich beim Rapid Prototyping die Technik von Expertensystemen zunutze machen.