Wir sind die Erben einer Compiler-Kultur, einer Kultur, die sich auf Programmieren, Programmiersprachen und Compiler stützt. Diese Kultur ist im wesentlichen durch drei Merkmale gekennzeichnet: Erstens konzentriert sich die Software-Entwicklung auf ein einziges Thema, die durchzuführende Berechnung; zweitens beschreibt sie diese Berechnung in nur einer Sprache der jeweiligen Programmiersprache; drittens wird dazu nur eine einzige Tool-basierte Entwicklungsoperation verwendet, nämlich das Kompilieren .

Die Beschränkungen dieser Kultur sind offensichtlich. Neben der Berechnung selbst müssen wir uns um viele andere Themen kümmern - als da wären Zweck, Problemfeld, Benutzerprotokolle, Datenbankstrukturen, Speicherverwaltung, Systemumgebung, Leistung, Prozeßplanung etc. Und wir müssen jedes dieser Themen in vielen separaten Beschreibungen genau abklären.

Diese zahlreichen Beschreibungen nutzen zwangsläufig eine ganze Reihe von Sprachen und Notationen. So wie Automobilkonstrukteure Glas für die Fenster und Stahl für die Kurbelwelle einsetzen, müssen wir für unsere Beschreibungen die jeweils geeigneten Sprachen verwenden: Wir dürfen nicht versuchen, das Problemfeld in Ada, die Datenbankstruktur in finiten Automaten oder die Benutzerprotokolle in Entity-Relationship-Diagrammen zu beschreiben.

Und diese Spezialisierung reicht sogar noch weiter: Für die Windschutzscheibe des Autos darf nicht irgendein Glas verwendet werden, sondern nur gehärtetes oder Schichtsiecherheitsglas. Entsprechend werde wir für manche Sequenzbeschreibungen auf reguläre Ausdrücke zurückgreifen müssen, für andere auf finite Automaten, mit denen sich Zustände bezeichnen lassen, für wieder andere auf reguläre Grammaken mit denen wir bestimmte Episoden benennen können.

Um diese zahlreichen Beschreibungen in ihren vielen unterschiedlichen Sprachen zu

erstellen, zu manipulieren und zu verknüpfen, benötigen wir ebenso vielfältige Tools, die ein umfassendes Repertoire von Operationen unterstützen. Jede Sprache oder Notation verfügt über einen Satz von Standardoperationen zum Umwandeln und Verknüpfen von Beschreibungen, die sich ihrer bedienen

Operationen wie Decoration, Renaming und Abstraction beispielsweise lassen sich auf die meisten Beschreibungen - ungeachtet der jeweiligen Sprache oder Notation - anwenden.

Vor allem aber brauchen wir Operationen zum Verknüpfen von Beschreibungen, die in unterschiedlichen Sprachen abgefaßt sind. Was voneinander getrennt wurde, muß jetzt wieder miteinander verbunden werden. Nachdem wir die Stämme zum Zweck der Eroberung isoliert haben, müssen wir sie nun, um sie regieren zu können, wieder vereinigen.

Ich behaupte, daß wir auf diesem Weg zu wenige Fortschritte gemacht haben, und möchte diesen Standpunkt nachfolgend mit vier Argumenten untermauern: Zum einen ist die Zahl der Programmiersprachen stark ins Kraut geschossen, doch wurden diese Sprachen zu meist in separaten Umgebungen isoliert. Zwar besteht bereits seit 35 Jahren die Möglichkeit, eine in einer Sprache geschriebene Prozedur von einer in einer anderen Sprache abgefaßten aufzurufen, doch handelt es sich dabei um eine relativ unzulängliche Form der Verknüpfung. Es gibt heute zahlreiche Programmierumgebungen - für Lisp, Prolog, Smalltalk, Ada etc. - , aber eine jede legt de Entwickler auf eine einzige Programmiersprache fest.

Zweitens beobachte ich, daß viele der ernsthaften Bemühungen in den Bereichen Analyse, Spezifikation und Designmethodik auf der Annahme basieren, das Ziel bestehe in der Definition einer einzigen Sprache. So ging ein unlängst durchgeführtes Darpa-Projekt zum Prototyping beispielsweise - ohne diese Annahme zu hinterfragen - davon aus, daß ein zentraler Bestandteil des Prototyping Systems eine Sprache zur Beschreibung von Prototypen sein müsse.

Ich vermute, die Rechtfertigung dafür, eine einzige kohärente Sprache anzustreben, liegt darin, daß wir einzig auf diesen Wege so wünschenswerte Eigenschaften wie Orthogonalität und referentielle Transparenz erzielen können. Wir sollten uns jedoch die Frage stellen, ob diese Eigenschafen tatsächlich generell erstrebenswert sind.

Wie Automobilkonstrukteure befassen sich auch Software-Entwickler mit Spezialfällen. Dem Ingenieur geht es also nicht klar um, Glas- und Stahlteile grundsätzlich, also ungeachtet ihre Eigenschten, Formen und jeweiligen Einsatzmöglichkeit kombinieren zu können, sondern

er möchte dieses Spezialglas mit jener besonderen Sta1nut zusammen verarbeiten. Ganz ähnlich kommt es dem Software-Entwickler darauf an, diese bestimmte rekursive Funktion zu jener bestimmten Maschine mit finiten Zuständen in Beziehung zu setzen.

Zum dritten ist die Arbeit in dem Bereich, der allgemein unter dem Begriff Software-Engineering bekannt ist, nach wie vor fest in einer gänzlich manuellen Entwicklungsdisziplin verwurzelt. Wieder und wieder wird Parnas zukunftsweisende Schrift über Dekomposition erfolgreich und effizient zu nutzen, ist ein Tool vonnöten, mit dessen Hilfe sich Programme so schreiben lassen, als wären die Funktionen Unterprogramme, die auf die zur jeweiligen Implementierung passende Weise zusammengebaut werden."

Information-Hiding ist ein Kriterium, das auf bestimmte Untermengen unserer Beschreibung anzuwenden ist - in einem Kontext, in dem diese Beschreibungen dann mit Hilfe gänzlich anderer Kriterien manipuliert und umgewandelt werden. Also sollen Tools und Operationen einen zentralen Bestandteil unserer Szenerie darstellen.

Viertens und letztens zielen die derzeit gängigen Software-Entwicklungs-Tools zumeist darauf ab, die Arbeit zu mechansieren, die früher mit Papier und Bleistift erledigt wurde.

Dies mag ein akzeptabler Ausgangspunkt sein, mehr aber auch nicht. Das eigentliche Potential von Software-Entwicklungswerkzeugen liegt darin, daß mit ihnen Operationen angewendet werden können, deren manuelle Durchführung zu mühsam oder schwierig ist. Mittels eben dieser Operationen können wir das Spektrum der von uns erstellten Systeme und der für ihre Entwicklung verwendeten techniken erweitern.

Autos haben Preßblech-Karosserien, weil es Werkzeuge gibt, mit denen sich die Bleche pressen lassen, die per Hand nur schwer oder mit hohem Kostenaufwand formbar wären. Mikroschaltungen, stranggepreßte Kunstofferzeugnisse und Teile aus Sintermetall lassen sich ebenfalls nur maschinell herstellen. Solche Produkte, Materialien und Techniken verdanken ihre Entstehung dem Nachdenke über neue Fabrikationsprozesse und innovative Werkzeuge zu ihrer Unterstützung. Genau auf diese Weise müssen wir auch den Fortschritt der Software-Entwicklung in der modernen Welt vorantreiben.

Michael Jackson Erfinder des Jackson Structured Programming (JSP) und Inhaber

des Beratungsunternehmens Michael Jackson Ltd., London.