Modellieren, spezifizieren oder lieber gleich programmieren?

Ein Kommentar meines Kollegen Manfred Broy zu dem Beitrag über Spezifizieren und Abstrahieren in diesem Blog überraschte mich etwas. Er lautete:

Ich denke, was Sie in dem Artikel vielleicht wirklich interessieren muss, ist weniger das Thema Spezifikation als das Thema Modellierung. Viele Anstrengungen der Wissenschaft bestehen darin Modelle aufzustellen, die natürlich immer mit den Fragen verbunden sind, wie stark sie den Gegenstand, den sie modellieren und damit die Wirklichkeit korrekt wiedergeben.

In besagtem Beitrag ging es um die Spezifizierung von dynamischem Verhalten und Interaktionen, also von Algorithmen, Programmen, Prozessen oder dynamischen (biologischen oder physikalischen) Systemen. Modellieren wird in der Tat mitunter als Alternative zum Spezifizieren gesehen. Dies halte ich nicht für richtig. Das ganze Gebiet der Datenmodellierung wird hier von der Betrachtung ausgeschlossen. Es unterliegt völlig andern Gesetzen. Wie so oft, ist selbst unsere Fachsprache zu undifferenziert und suggeriert Gemeinsamkeiten auch da, wo kaum welche gegeben sind. Vollkommen verwirrend wird die Situation, wenn auch noch gleichklingende Begriffe aus der Mathematik ins Spiel gebracht werden.

Ausgewählte Begriffe

Ehe ich die Vor- und Nachteile verschiedener Ansätze diskutiere, will ich kurz mein Verständnis der relevanten Begriffe erläutern. Dabei beschränke ich mich strikt auf die Bedeutung der Begriffe in der praktischen Informatik.

Ein Modell ist ein beschränkte Abbildung des Verhaltens und Handelns, wobei bestimmte Aspekte außer Acht gelassen sind. Gegenstand eines Modells kann ein physikalisches, biologisches oder technisches Objekt, Gebilde oder System sein. Weggelassen werden solche Details, die für die aktuelle Fragestellung nicht relevant sind. Ein anderer Grund für das Weglassen kann Zeitnot, Aufwand, Nichtwissen oder freiwillige Beschränkung wegen Informationsüberflutung (engl. Information overload) sein. Gerade der letztere Grund ist bei großen technischen Systemen, z.B. Software-Systemen, der überwiegende. Nur so besteht eine Chance, die Systeme gedanklich zu durchdringen und (einigermaßen) in den Griff zu bekommen. Da Informatiker den Computer sehr oft auch in Bezug auf sein soziales Umfeld betrachten, versuchen sie manchmal auch das aktive Handeln von Menschen zu modellieren. Es kommt dann zu betrieblicher, wirtschaftlicher oder soziologischer Modellierung.

Ein Programm ist eine teilweise oder vollständige Implementierung eines dynamischen Systems. Es ist ein Text oder eine Grafik, die von einem programmgesteuerten Rechner direkt (d.h. im Maschinencode) oder indirekt (d.h. durch ein anderes Programm) interpretiert wird und, als Konsequenz davon, eine (Rechen-) Maschine steuert. Bei der teilweisen Implementierung ist bekannt, für welche Werte der Eingabeparameter oder Parameterkombinationen das System noch nicht reaktionsfähig ist. Programme sind zwar reale technische Objekte, stellen aber ihrerseits Modelle dar (was leicht zu Verwirrung führt).

Ein Prototyp ist ein Programm, das weder einen Anspruch auf Vollständigkeit noch auf Korrektheit erhebt. Es kann aus einer Vielzahl von Gründen nützlich sein, ihn zu erzeugen. Er macht den Entwickler vertraut mit einer neuen Programmiersprache oder einem neuen Algorithmus. Er verschafft dem Entwickler ein Gefühl für den Aufwand, die Performanz oder die Ergonomie eines Entwurfs. Schließlich vermag er den Auftraggeber davon zu überzeugen, dass etwas Brauchbares im Entstehen ist. Es ist Fakt, dass die meisten Prototypen als Produkt ausgeliefert werden. Er wird zur ersten Version (engl. release) eines Mehr-Versionen-Produkts.

Eine Spezifikation legt normalerweise fest, was ein Programm, wenn es einmal vollständig und fertig ist, tun soll (Soll-Spezifikation). Dabei kann nur die Beziehung zwischen Parametern und Ergebnis (Ein-/Ausgabe-Relation) gegeben sein, nicht jedoch der Lösungsweg oder gar Eigenschaften der Lösung (z.B. Performanz). Eine zweite Form von Spezifikation beschreibt in zuverlässiger Weise, was ein vorliegendes Programm tut (Ist-Spezifikation). Beide unterscheiden sich vor allem bezüglich der für die Spezifikation möglichen Korrektheitsaussage. Eine Soll-Spezifikation muss ihre Korrektheit aus der Aufgabenstellung und den verfügbaren Lösungsverfahren ableiten, also aus nicht formalisierten und formalisierbaren Vorgaben. Die Ist-Spezifikation muss die Semantik des vorliegenden Programms richtig wiedergeben. Eine Spezifikation besteht wie das Programm aus Text oder Grafiken. Sie sollte – muss aber nicht – maschinell verarbeitet werden können. Dabei handelt es sich lediglich um eine syntaktische und semantische Überprüfung. Ist die Spezifikation ausführbar, d.h. produziert sie Ergebnisse wie ein Programm, kann ihre Notation als Programmiersprache angesehen werden. In beiden Fällen von Spezifikation kann der Abstraktionsgrad variieren. Geht dies auf Kosten der Vollständigkeit haben wir es eher mit Modellen als mit Spezifikationen zu tun.

Modellieren statt Spezifizieren

Manchmal ist Spezifizieren ganz einfach, vor allem dann, wenn nur das Problem, aber nicht der Lösungsweg vorgegeben ist. Ein Beispiel ist Peter Naurs berühmtes Textverarbeitungsproblem, mit dem sich Münchner Kollegen bereits 1977 befassten:

Gegeben ein fortlaufender Text, der in Zeilen der Länge n aufgeteilt werden soll, wobei die Zeilen optimal ausgenutzt sind.

Bekanntlich gibt es seither verschiedene Implementierungen, die sich vor allem in der Anzahl der Fehler unterscheiden, aber keine bessere Spezifikation (oder etwa ein Modell). Aber selbst diese Spezifikation sollte ausreichen, um die Korrektheit einer gegebenen Implementierung zu beweisen, eine Aufgabe, die seit 35 Jahren immer noch auf ihre Lösung wartet.

Auf einem ähnlichen Niveau liegt das Beispiel, auf das Herbert Klaeren [1] verweist Es ist eine Form des Parkplatzproblems:

Gegeben eine Fläche für n Räder; wie viele Autos oder Krafträder passen darauf?

Die Spezifikation sieht einfach aus, hat es aber in sich. Hier liegt die besondere Schwierigkeit darin, dass eine wesentliche Annahme, selbst wenn sie angegeben wäre, nur sehr schwer zu formalisieren ist. Alle Restriktionen, die sich aus der zwei-dimensionalen euklidischen Geometrie ergeben, müssen bei der Implementierung nämlich berücksichtigt werden, obwohl sie nicht angesprochen sind. Für ein etwas größeres Programm eine einigermaßen vollständige Spezifikation zu erstellen – gleichgültig ob Soll- oder Ist-Spezifikation – ist Knochenarbeit. Wenn irgendwie möglich, versucht man sich dem zu entziehen. Die Alternative heißt dann, lasst uns doch modellieren.

Bei beiden Beispielen könnte man erwarten, dass es ein Leichtes ist, Modelle zu entwickeln. Umso überraschender ist es, dass die Fachliteratur in dieser Hinsicht nicht sehr ergiebig ist. Ein Modell sollte die Lösung der entsprechenden Aufgaben unterstützen, ja erleichtern. Selbst ein Datenmodell, also eine Formalisierung der für die Lösung verwendbaren Datenstrukturen, könnte helfen.

Besonders unter Akademikern scheint sich Modellieren zum Hobby entwickelt zu haben. Leider habe ich nicht den Eindruck, dass es darum geht, bisher nicht bearbeitete Problemdomänen besser zu verstehen. Natürlich wäre die Mathematisierung weiterer Anwendungsgebiete eine dankbare Aufgabe. Auch scheint es akademisch nicht als besonders verdienstvoll angesehen zu werden, vorhandene Systeme in der Natur, in Technik oder Wirtschaft, oder gar in der Software-Industrie zu modellieren. Im letzteren Fall schimpft man und nutzt sie. 

Mein Eindruck ist, dass es sehr oft nur darum geht, für unterschiedliche Notationen zu werben. Es ist dies der alte Programmiersprachenstreit, verschoben auf ein neues Terrain. Beim Modellieren kann man – im Gegensatz zum Programmieren – immer etwas weglassen. Wenn einem freigestellt ist, was man weglassen darf, ist das Spiel besonders einfach. Jemanden, der sich nur an Aufgaben misst, die er sich selbst stellt, – und dazu noch so, dass sie leicht lösbar sind – , darf man auch als Dünnbrettbohrer bezeichnen.

Programmieren statt Spezifizieren

Die Arbeit des Spezifizierens ist nicht nur lästig, sondern fehleranfällig und wenig nützlich. Da der Nutzen in keinem Verhältnis zum Aufwand steht, verliert Spezifizieren zunehmend an Bedeutung. Niemand kann auf Dauer, also über 20 Jahre hinweg, zwei formale Dokumente auf demselben Niveau halten.

Wird versucht, die Korrektheit eines Programms anhand einer Spezifikation zu beweisen, ist dies bestenfalls eine Pseudo-Korrektheit. Alles hängt dann von der Spezifikation ab und diese ist noch eine Stufe künstlicher als ein Programm. Es ist leichter, Konsistenz und Relevanz zwischen Programm und Realität zu überprüfen, als die zwischen Spezifikation und Realität. Das Programm ist Teil derselben, die Spezifikation nicht.

Es werden immer mehr Programme geschrieben, deren Problemstellungen und Lösungswege nicht in Lehrbüchern zu finden sind. In einem solchen Fall besteht der erste Schritt darin, das Problem als (mittels Computer lösbares) Problem zu erkennen. Danach kommt es darauf an, zu verstehen, was akzeptable Lösungen sind und diese in Angriff zu nehmen. Die Aufgabe und die Lösung adäquat zu dokumentieren, ist zwar löblich, aber sekundär. Es gibt kein einziges Programm, das ich verwende, für das ich im Detail wissen will, wie es funktioniert. Den Lizenzvertrag (Eula genannt) sehe ich sehr selten an, geschweige denn die Spezifikation (sofern ich sie überhaupt auftreiben könnte).

Die beigefügte Tabelle gibt an, wie viel Speicherplatz einige bekannte Programme auf meinem privaten PC belegen. Dividiert man diese Zahlen durch 4, so erhält man einen Anhaltspunkt für ihre Größe, ausgedrückt in MLOC. Bei Windows 7 ergibt dies etwa 600 MLOC. Natürlich ist nur ein Bruchteil davon ausführbarer Code. Aber ohne Nachrichten und Erklärungen ist Code nicht benutzbar. Papier-Manuale sind von Vorgestern [2].

Es ist für mich wie für die meisten Nutzer nicht sinnvoll, eine exakte Spezifikation von einem dieser Programme zu studieren. Wie in Broy/Endres [3] beschrieben, gibt es immer mehr ‚Übergroße Systeme‘ (engl. Ultra-large-scale systems). Sie werden mehr und mehr Teil der Infrastruktur, vergleichbar den Verkehrs- und Versorgungssystemen. Diese Systeme wachsen ungeplant in eine Größenordnung von mehreren GLOC. Es gibt nicht Informatiker genug auf der Welt, um sie zu analysieren.

Unterschied zwischen Modellieren und Simulieren

Ich möchte noch zwei Begriffe voneinander abzugrenzen versuchen, die oft gleich gesetzt werden. Ich mache es kurz. Haben die Modelle von Programmen, die man baut, eine Zeitdimension, dann sollten sie auch ausführbar sein. Dann sind sie gleichzeitig Simulationsprogramme. Dabei muss das Simulationsprogramm nicht dieselbe Art von Ergebnissen liefern oder dieselben externen Effekte haben, wie das simulierte Programm. Ist man z.B. nur an dem Zeitbedarf interessiert, wird nur der Kontrollfluss nachgeahmt. Anstatt die echten Werte zu berechnen, werden beim Erreichen eines Knotens nur die für einzelne Routinen und Operationen geschätzten Millisekunden aufaddiert.

Zusätzliche Referenzen und Hinweise

1. Klaeren, H.: Viren, Würmer und Trojaner. Streifzüge durch die Computerwelt. Tübingen: Klöpfer & Meyer 2006
2. Warum Dragon 11.5 zuerst 15,5 GB herunterläd, um anschließend 2,5 GB zu installieren, ist mir ein Rätsel. Vielleicht hatte man mir die englische und französische Version gleich mitverkauft.
3. Broy, M., Endres. A.: Informatik überall, jederzeit und für alle. Informatik-Spektrum 32,2 (2009), 153-162