Die Spezifikationssprache Prolog, die auf theoretischen Grundlagen aufgebaut ist und sowohl den Wunsch der Softwaretechnologen nach einer formalen Spezifikation als auch den der Anwender nach einem brauchbaren Prototyping-Hilfsmittel erfüllt, wird von der Fachwelt immer stärker beachtet. Auf der NCC wurde die erste kommerziell vertriebene Implementierung angekündigt Auch an der Universität Karlsruhe ist diese Sprache bereits als Basis eines Software-Technologie-Kurses im Einsatz. Dr. Peter Schnupp, Gesellschafter der Interface Computer GmbH aus München, die diese Spezifikationssprache als einen ihrer Arbeitsschwerpunkte sieht, beschreibt in seinem Beitrag Grundlagen und Spezialitäten von Prolog.
Die Ziele der Softwaretechnologie-Theorie sind anspruchsvoll: Einer Realisierung soll eine formale Spezifikation der zu erstellenden Softwareprodukte vorausgehen. Aus ihr soll dann die Korrektheit einer Implementierung formal bewiesen oder vielleicht sogar diese Implementierung mit automatisierter Unterstützung erzeugt werden.
Die Anwender wünschen sich dagegen vor allem die Ausführbarkeit formaler Spezifikationen auf einem Rechner um die Übereinstimmung des spezifizierten Produkts mit den Vorgaben der Auftraggeber und Benutzer überprüfen und den Auftraggebern demonstrieren zu können.
Praktikable Lösungsansätze hierzu stammten denn auch bis jetzt nahezu ausschließlich aus dem Bereich der praktischen Anwendung. Beispiele sind Formularsprachen, mit denen die Folge der Bildschirmformulare eines Benutzerdialogs beschrieben und im Dialog erprobt werden kann oder VHLL-Zusätze zu Datenbanksystemen wie Natural, die ein "Rapid-Prototyping" und zuweilen auch benutzernahes Programmieren von Datenbank-Anwendungen ermöglichen.
Naturgemäß beschränken sich derartige Lösungen auf Teilgebiete (beispielsweise die Dialogführung oder den Datenbankzugriff).
Ab diesem Semester verwenden jedoch die Studenten in Lehrveranstaltungen der Universität Karlsruhe erstmals eine neue Spezifikationssprache, die das Problem auf solider theoretischer Grundlage zu lösen verspricht. Prolog, bisher "Geheimtip" im Bereich der künstlichen Intelligenz (und bei den Japanern, die sie als Basis ihrer neuen "Fifth Generation"-Rechnerarchitektur auswählten), wird zum Standardwerkzeug.
Prototyping per "Expertensystem"
Prolog erfüllt über einen weiten Anwendungsbereich sowohl den Wunsch der Softwaretechnologie nach einer formalen Spezifikation der Softwareprodukte als auch den der Anwender nach einem brauchbaren Prototyping-Hilfsmittel. Grundlage seiner Entwicklung waren zum einen die Ideen von Kowalski und Colmerauer über eine nichtprozedurale "Programmierung in Logik" (daher der Name) und zum anderen die dem Bereich der Intelligenztechnologie entstammende Konstruktion von Experten-Systemen.
Die Eignung von Prolog als Spezifikationssprache ist vor allem in seiner Fundierung auf einer spezieller Form des Logikkalküls erster Ordnung, den sogenannten Hornklauseln, begründet. Seine Eignung für das Prototyping beruht auf dem einem Experten-System zugrunde liegenden Konzept:
Es ist ein Problem- der konventionellen Softwareentwicklung, daß sowohl das Programm (der Algorithmus) als auch die Datenstrukturen gleichzeitig entwickelt werden müssen, und daß dabei sowohl programmiertechnische Kenntnisse als auch Wissen aus dem jeweiligen Fachbereich benötigt werden( siehe Abb. 1). Diese beiden Spezialwissens-Bereiche können nicht klar getrennt werden, woraus sich die bekannten Kommunikations- und Zusammenarbeitsprobleme von Datenverarbeitung und Fachbereichen ergeben.
Experten-Systeme (siehe Abb. 2) sind nun dadurch gekennzeichnet, daß die Programmierung getrennt ist von der Entwicklung der Datenstrukturen, die eine Anwendung modellieren.
Die Softwareentwickler programmieren eine allgemein gültige "Inferenz-Maschine", und die Fachspezialisten beschreiben die jeweilige Anwendung durch Fakten (das heißt, durch ein relationales Datenmodell in der Sprechweise der Informatik) sowie logische Schlußregeln zur Ableitung neuer Sachverhalte.
Ein Prolog-Interpreter ist eine derartige "Inferenz-Maschine", deren Basis die inzwischen entwickelten, formallogischen Beweisverfahren sind. Prolog betrachtet eine Benutzeranfrage als "zu beweisendes Theorem". Bei der Beweisführung ("Resolution") bindet es die freien Variablen in Fakten, Regeln und Benutzeranfragen ( "Goals") durch einen "pattern-matching" -Algorithmus an Konstanten oder Datenstrukturen ( "Unifizierung").
Sieht man diesen Vorgang jetzt wieder aus der Sicht der gewohnten Datenverarbeitung, so ist diese Unifizierung nichts anderes als ein "Information Retrieval" aus den Fakten und Regeln der Datenbasis: Für die Variablen einer Benutzeranfrage werden Werte oder Strukturen ("Records") gefunden oder konstruiert, welche die Benutzeranfrage befriedigen.
Wesentlich ist hierbei, daß die formallogische und implementierungstechnische Basis dieses Algorithmus im Prolog-Interpreter verborgen ist. Der Spezifizierer oder der Entwickler eines
Prototyps braucht sie nicht im Detail zu kennen. Für ihn reichen in den meisten Fällen die Kenntnisse der Notationsweise (das heißt, die im Vergleich zu gewohnten Programmiersprachen einfache und kompakte Syntax von Prolog) und ein intuitives logisches Verständnis zur Formulierung seiner fachtechnischen Vorgaben aus.
Unterlaufen dem Spezifizierer formale, logische oder Flüchtigkeitsfehler, so kann er sie mit Hilfe der in den Prolog-Interpreter eingebauten Testhilfen lokalisieren und korrigieren. Dies ist vielleicht das wichtigste Argument, warum eine formale Spezifikationssprache mit einem Interpreter implementiert und damit auf einem Computer ablauffähig sein sollte. Untersuchungen haben gezeigt, daß in installierten Programmen bis zu 80 Prozent der Fehler "logische" Spezifikationsfehler sind.
Wie etwas praktische Erfahrung mit der formalen Spezifikation
schnell zeigt, stammen diese Fehler aus zwei Bereichen. Es sind zum einen die Fehler, die wir auch aus der Programmiererfahrung in herkömmlichen Programmiersprachen kennen: Flüchtigkeitsfehler, vergessene Sonderfälle, mißverständliche Vorgaben und schlichte Denkfehler.
Es sind aber auch die subtilen Probleme, die dadurch entstehen, daß die intuitive Logik (in der wir alle denken) und die strenge, formale Logik nicht immer übereinstimmen. Alle diese Fehler sind aus einer nicht-ausführbaren, formalen Spezifikation praktisch nicht zu eliminieren. Auch Konsistenzprüfungen können nur eine bescheidene Untermenge von ihnen finden.
Eine formale Spezifikationssprache ist deshalb nur dann wirklich nützlich, wenn sie Spezifikationsfehler aller Art aufzuspüren und zu lokalisieren gestattet - mit Hilfe ähnlicher Testmethoden, wie sie in der Programmierung seit jeher üblich sind. Hier zeigt sich die grundsätzliche Überlegenheit einer auf einer formalen Basis beruhenden Spezifikationssprache gegenüber Ad-hoc-Lösungen: Ein guter Prolog Interpreter bietet heute eine Testunterstützung, die derjeniger moderner Programmiersprachen-Umgebungen gleichwertig ist.
Zudem entstehen beim Test von Prolog-Spezifikationen "nebenbei" auch Spezifikationen für die benötigten Testrahmen, die dann später bei der Realisierung ebenso wie das Softwareprodukt auf der Grundlage einer formalen Spezifikation programmiert werden können.
Läßt Prolog damit für die formale Spezifikation kaum Wünsche offen so gilt dies noch nicht für das Prototyping. Dies liegt vor allem an der sehr eingeschränkten Ein-/Ausgabeumgebung derzeitiger Prolog Interpreter.
Vor allem ist die Schnittstelle zum Endbenutzer auf dem Modell sequentieller Zeichenströme aufgebaut, das heißt, sie simuliert praktisch eine Schreibmaschine. Dies reicht für das Prototyping moderner, dialogorientierter Anwendersoftware nicht aus. Hierfür sollte Prolog zumindest eine seiten-, wenn nicht sogar formatorientierte Bildschirm-Schnittstelle bieten.