Gedanken zur Software-Explosion

Die Software-Industrie steht vor dem Dilemma, entweder ihre bisherigen Investitionen in der Form von Programmen und Systemen beizubehalten oder von den modernen Paradigmen und Methoden der Software-Entwicklung zu profitieren. Wie in solchen Fällen üblich, sucht sie einen Kompromiß und hofft, die Lösung im Hinzufügen von neuen Features in alten Systemen zu finden. Dies führt jedoch unweigerlich zu immer umfangreicheren Konstruktionen, deren Inneres komplex und undurchsichtig wird und die vielbeschworenen Prinzipien der systematischen Struktur, Klarheit und Zuverlässigkeit, Lügen straft. Solche Systeme sind nur noch dank der stetig wachsenden Leistung moderner Hardware implementierbar, wobei letztere oft sehr ineffektiv eingesetzt ist.

Als Versuch, diesem Trend entgegenzutreten, haben wir das System Oberon von Grund auf, d.h. ohne Abstützung auf bestehende Systeme, aufgebaut. Sozusagen als Nebenprodukt entstand die Sprache Oberon als auf das Wesentliche reduzierte Version von Pascal und Modula, vergrößert jedoch um das neue Konzept der erweiterbaren Datentypen, das für den Objekt-orientierten Programmierstil unerläßlich ist. Das Oberon-System ist sehr flexibel, mächtig und leicht erweiterbar, aber dennoch kompakt und ökonomisch. Wir legen seine hauptsächlichen, innovativen Konzepte dar. Sie haben unsere Fähigkeiten, moderne Software zu konstruieren, vervielfacht. Das System wurde seit seiner Konzeption 1986 auf zahlreiche kommerzielle Rechner übertragen.

Einleitung

Moderne Software zum Betrieb eines Rechners am Arbeitsplatz (workstation) erfordert heute typischerweise einen Speicher von mehreren Megabyte Kapazität. Oft erhöht eine neue, verbesserte oder korrigierte Version die Speicheranforderung substantiell. Wenn diese die bestehende Kapazität übersteigt, wird zusätzlicher Speicher eingekauft. Wird die Grenze der Erweiterbarkeit überschritten, muß ein neuer Rechner beschafft werden. Es stellt sich spätestens dann die Frage, ob die zusätzliche Funktionalität die aufgezwungenen Kosten rechtfertigt. Meistens tut sie es nicht.

Ich erinnere mich noch daran, daß vor ungefähr 25 Jahren ein interaktiver Texteditor mit einem Speicher von 8000 Byte als realistisch angesehen wurde. (...) Ist durch den Mehraufwand etwa die Geschwindigkeit dieser Software gestiegen? Beileibe nicht. Gäbe es keine tausendmal schnellere Hardware, müßte man heute Software als schlechthin unbrauchbar bezeichnen. Natürlich dient die erhöhte Benutzerfreundlichkeit und die erweiterte Funktionalität als Rechtfertigung der massiv erhöhten Ansprüche an Ressourcen. Bei genauerem Hinsehen stehen jedoch viele dieser Rechtfertigungen auf wackligen Beinen. Ein Texteditor dient noch immer dem Einfügen, Verschieben und Löschen von Teilen eines Textes, ein Compiler übersetzt noch immer Quelltexte in Maschinencode, und ein Betriebssystem verwaltet noch immer die Ressourcen eines Rechners, Primärspeicher, Plattenspeicher, Prozessorzyklen. Die grundlegenden Aufgaben haben sich durch Fenstertechnik, cut and paste-Strategien, pop up windows nicht verändert, auch nicht durch das Ersetzen sinnvoller Befehlswörter durch lustige icons.

Der offensichtliche Wildwuchs der Software wird von der Gemeinschaft ihrer Benutzer nur dank des unglaublichen Fortschritts der Halbleitertechnik akzeptiert, die das Verhältnis Leistung zu Kosten in einem Grad verbessert hat, der in keinem andern Gebiet der Technik auch nur annähernd erreicht wurde. (...)

Aussichten für eine weitere Leistungssteigerung sind nach wie vor vorhanden. Gleichzeitig gibt es keine Anzeichen dafür, daß der Appetit neuer Software abnehmen wird [1]. Diese Entwicklung der Dinge war bereits Anlaß für einige Faustregeln, Gesetze und Korollare. Sie sind - wie üblich in solchen Fällen - eher vage und unverbindlich formuliert und weder beweisbar noch widerlegbar. Obwohl sie zunächst eher sarkastisch erscheinen mögen, stellen sie doch den Sachverhalt erschreckend klar dar:

Software expandiert, bis der Speicher gefüllt ist. (Parkinson)

Software wird schneller langsamer, als die Hardware schneller wird. (Reiser)

Außer der Leistungssteigerung der Hardware gibt es einen weiteren Grund für die geduldige Akzeptanz des unkontrollierten Software-Wildwuchses, nämlich die weitverbreitete Unfähigkeit der Benutzer, zwischen zur Lösung einer Aufgabe wirklich benötigten und nice to have-Features zu unterscheiden. Ein Beispiel sind die heute üblichen überlappenden Bildschirm-Fenster, die zwar ein elegantes Abbild unseres Schreibtisches sein mögen, gegenüber nicht-überlappenden und wesentlich einfacher zu realisierenden Fenstern jedoch keine zusätzliche Funktionalität bringen. Ein anderes Beispiel sind die berühmten icons, die den Bildschirm mit Briefkästen und Abfallkübeln amerikanischer Prägung dekorieren, ergänzt durch das Sichtbarmachen der Bewegung ausgewählter Objekte vom Bildschirm zu ihrem endgültigen Bestimmungsort, eben dem Abfallkübel. Diese Spielzeuge mögen zwar attraktiv und suggestiv erscheinen, sie sind aber unwesentlich und haben ihre versteckten Kosten.

Ein bedeutungsvolleres Beispiel sind Systeme, die bei der Fehlersuche in Programmen behilflich sein sollen (debugging aids). Obwohl bis zu einem gewissen Grad ohne Zweifel nützlich oder gar unerläßlich, sind diese Werkzeuge in übertriebener Weise gewachsen, und sie haben zu der weitverbreiteten Ansicht beigetragen, daß das Programmieren lediglich aus wiederholtem Probieren und Korrigieren besteht. Dadurch wurde leider eine eher unprofessionelle Haltung gegenüber dem Konstruieren von Programmen gefördert. Die unausweichliche Konsequenz davon ist, daß der Software-Kunde graduell zum Mitarbeiter wurde, wenn vielleicht auch nicht beim Korrigieren, so doch sicher beim Probieren. Man stelle sich diese Situation im Flugzeug- oder Kraftwerkbau vor! Doch auch dort wird vermehrt Software eingesetzt.

Gründe für Fat Software

So haben wir denn zwei Faktoren identifiziert, die die Akzeptanz aufgeblähter Software ermöglichen, nämlich die schnelle Leistungssteigerung der Hardware und die Nachlässigkeit der Kunden bezüglich kritischer Evaluation. Doch wichtiger als die Gründe für die Akzeptanz ist die Frage Was macht Software komplex?

Hier scheint mir die Tatsache ausschlaggebend, daß Hersteller kritiklos jedes Feature implementieren, das von Kunden gewünscht wird, unabhängig davon, wie (un)begründet solche Wünsche sein mögen. Sind die gewünschten Features inkompatibel mit dem Konzept des bestehenden Systems, wird dies entweder nicht bemerkt oder geflissentlich übersehen. Das jedoch führt zu komplexeren und vertrackten Konstruktionen und zu mühsamerem Erlernen ihrer Verwendung. Der Grund für die unbesehene Übernahme neuer Features ist letztlich die Ansicht, daß Quantität wichtiger ist als Qualität. In der Tat wird die Güte eines Systems meist mit der Anzahl seiner Features gemessen. Jede nachfolgende Version muß zwangsläufig zusätzliche Features aufweisen, selbst wenn sie die Funktionalität des Systems gar nicht erhöhen.

Ein weiterer Grund liegt im üblichen monolithischen Design. Beim Bau eines Systems werden alle erdenklichen Features sogleich berücksichtigt und eingebaut. Jeder Kunde muß für sie alle bezahlen; er hat keine Auswahl, obwohl er typischerweise nur wenige dieser Features benutzen wird. Die vernünftige Lösung besteht im Bau eines Systemkerns, der nur die wichtigen und unabdingbaren Features anbietet, jedoch leicht erweiterbar ist. Jeder Kunde kann dann jene Erweiterungen auswählen, die seinen spezifischen Bedürfnissen entsprechen.

Zweifellos war die gesteigerte Leistung der Hardware immer der primäre Anreiz, komplexere Probleme mittels Computer anzugehen. Komplexere Probleme bedingen meistens auch komplexere Lösungen. Ich spreche hier aber nicht diese inhärente Komplexität an, sondern die hausgemachte, durch mangelhafte Analyse, mangelhaftes Können, unzweckmäßiges Vorgehen verursachte. Wer kennt nicht Probleme, für die schon vor vielen Jahren Software vorhanden war und für die heute viel umfangreichere Software angeboten wird.

Ein großer Teil des zusätzlichen Umfangs geht ohne Zweifel auf das Konto der vielgepriesenen Benutzerfreundlichkeit. (...) Ich habe die Einfachheit der Bedienung eines Systems stets als Primärziel bei der Software-Entwicklung betrachtet, glaube aber, daß diese auf einer Systematik des zugrundeliegenden Konzepts beruhen muß, die die Benutzung gleichsam offensichtlich und selbstverständlich macht. Ich stelle jedoch fest, daß viele Leute von Komplexität fasziniert sind, sie sozusagen als Mehrwert empfinden. Dieser psychologische Trend ist mir ein Rätsel, und ich meine, daß sich gegenüber dem Unerklärlichen eher Argwohn als Faszination einstellen sollte. Vielleicht ist dieser Trend auf das Gefühl zurückzuführen - das von Geräten eingeflößt wird, deren Komplexität jedes vollständige Verstehen ausschließt - , eine Aura von Macht zu erhalten, die anderen nicht so leicht zugänglich ist. Leichter verständlich wäre jedenfalls ein Gefühl der Hilflosigkeit oder gar Ohnmacht gegenüber diesen komplexen Artefakten. Die obige Hypothese aber läßt den Gebrauch von Komplexität zur Förderung des Verkaufs verständlich werden. Komplexität ist zu einem wichtigen Mittel geworden, um die Abhängigkeit der Kunden vom Hersteller zu fördern. Zu diesem Zweck haben große Software-Häuser stark in ihre Kundendienste investiert und gar Hunderte von Mitarbeitern eingestellt, die rund um die Uhr Hilferufe von Kunden beantworten und sie damit stärker an den Hersteller binden.

Obwohl diese Investitionen sich offenbar bezahlt gemacht haben, glaube ich, daß ein Produkt basierend auf einem systematischen Konzept, begleitet von einem konzisen Manual und einem ausgefeilten Tutorial sowohl für den Kunden als auch für den Hersteller letztlich wesentlich ökonomischer wäre. Allerdings ist nicht zu bestreiten, daß ein weiterhin vom offerierten Kundendienst abhängiger Kunde eine dauerhaftere Quelle von Einkünften ist als ein Kunde, der das Produkt völlig beherrscht und versteht. Der Verdacht liegt nahe, daß in dieser Beziehung Industrie und Universität grundsätzlich verschiedene Zielsetzungen haben, und ihm verdankt folgendes Wirtschafts-Gesetz seinen Ursprung:

Manuale mit Hunderten von Seiten sind heute üblich für Programmiersprachen, Betriebssysteme und alle Arten von Software-Werkzeugen. Sie sind untrügliche Zeichen von vertracktem Design, unklarem Konzept, aber auch von der Absicht, den Kunden abhängig zu machen. Denn wer möchte schon auf ein Konkurrenzprodukt wechseln, nachdem er endlich den Inhalt dieser Wälzer gemeistert hat?

Nun sind dies aber sicher nicht die einzigen Gründe für die Software-Explosion. Meistens ist sie nicht geplant; sie ist einfach plötzlich da. Bestimmt ist die Lösung komplexer Probleme schwierig und zeitaufwendig. Dies gilt übrigens für Software und Hardware. Nebenbei bemerkt ist der Entwurf potenter Hardware extrem teuer, und die Kostensenkung im Hardware-Bereich ist nur zu einem geringen Teil auf bessere Design-Methoden zurückzuführen. Sie beruht hauptsächlich auf besserer Fabrikationstechnik, d.h. der Technik der Duplizierung. Hingegen ist im Software-Bereich alles Design; Duplikation war seit jeher gratis.

Erste Ansätze bei der Software-Konstruktion führen meist zu komplexen Gebilden. Erst wiederholte Verbesserungen oder gar Neuanfänge unter Berücksichtigung der erhaltenen Erkenntnisse erbringen die gewünschte Qualität. Die erfolgreichsten Schritte sind diejenigen, die eine Vereinfachung herbeiführen oder gar Teile eines Programms als überflüssig erscheinen lassen. Entwicklungen dieser Art trifft man jedoch in der Praxis selten an, weil sie ein zeitaufwendiges Überdenken erfordern, das meistens kaum belohnt wird. Stattdessen werden Unzulänglichkeiten durch rasch gefundene Zusätze überdeckt, deren Summe schließlich zur bekannten fat software führt.

Man beachte, daß rasch gefundene Zusätze im Gegensatz zu zeitaufwendigem Überdenken steht. In der Tat ist ein Hauptgrund für wuchernde Software der Zeitdruck, unter dem Ingenieure stehen. Zeitdruck verhindert sorgfältiges Planen, und noch mehr verhindert er die Suche nach besseren Lösungen. Er verleitet zu rasch gefundenen Zusätzen und Korrekturen. Zeitdruck fordert hohe Qualitätsmaßstäbe als Opfer. Er hat einen negativen Einfluß auf Mensch und Produkt.

Der Umstand, daß der Hersteller, dessen Produkt zuerst auf dem Markt erscheint, erfolgreicher sein wird als sein Konkurrent, der seinen Leuten mehr Zeit läßt und dadurch zweiter wird mit einem besseren Produkt, hat ebenfalls einen negativen Einfluß auf die Produktqualität im Software-Sektor. Gutes Konstruieren zeichnet sich durch ein graduelles, schrittweises Verfeinern des Produktes aus, seine wachsende Leistung unter gegebenen Randbedingungen und limitierten Ressourcen. In der Software hingegen werden Begrenzungen von Ressourcen nicht mehr ernst genommen, weil die Maßstäbe von Prozessorleistung und Speicherkapazität überaus rasch wechseln. Seriöse Konstruktions-Disziplin scheint kurzfristig nicht mehr lohnend zu sein, zumal die Tendenz vorherrscht, daß das zuerst auf dem Markt erscheinende Produkt zum de-facto-Standard für alle Zeiten erkoren wird.

Sprachen und Entwurfsmethodik

Wir sind alle in dem Glauben aufgewachsen, daß die Forschung eine entscheidende Rolle für die Zukunft unserer Gesellschaft spielt, insbesondere für die zukünftige Technik. Daher wurde auch viel Aufwand in die Entwicklung einer Software-Methodik gesteckt. Aus dem soeben Gesagten läßt sich aber schließen, daß diese Bemühungen für die Industrie nur von beschränkter Relevanz sein können. Vorschläge für methodisches Vorgehen werden eher skeptisch beurteilt, weil sie zuviel time to market erfordern.

Vorschläge für analytische Verifikation von Programmen und Korrektheitsbeweise fahren sogar noch schlechter, da sie höhere intellektuelle Anforderungen stellen als der übliche Ansatz unter dem Motto Probieren und Korrigieren. Vorschläge, die Komplexität durch kompromißlose Einschränkung auf das Wesentliche einzudämmen, gelten als akademisch oder lächerlich im Hinblick auf das Verlangen der Kunden nach Verzierungen und Firlefanz. Wir schließen daraus zwangsläufig, daß sich Forschung auf diesem Gebiet nicht mehr lohnt. Methodik und Disziplin sind ohnehin verpönt in einem Zeitalter, in dem alles ist erlaubt als erstes Credo gilt.

Die Lage ist besonders kontrovers auf dem Gebiet der Progammiersprachen. In den 70er Jahren wurde weitherum gelehrt und akzeptiert, daß Programmentwurf auf strukturierten Methoden basieren müsse und durch Schichten von Abstraktionen mit klar definierten Spezifikationen charakterisiert sei. Die Begriffe abstrakter Datentyp und Kapselung haben dies trefflich verkörpert, und sie fanden rasch Eingang in neuen Programmiersprachen wie Modula-2, Ada und anderen. Heute jedoch erleben wir eine Migration zahlreicher Programmierer weg von strukturierten Sprachen hin zur Sprache| C, die bezüglich Entwicklung von Methodik und Sprachstruktur auf dem Stand der 60er Jahre steht. Das Konzept der Datentypen hatte in C höchstens rudimentär Eingang gefunden, jedenfalls nicht annähernd so, daß ein Compiler zuverlässig Typenkonsistenzprüfungen durchführen könnte. Aus reicher Erfahrung wissen wir aber heute, daß gerade das konsequent durchgezogene Typenkonzept die Hilfe bringt, deren Fehlen durch kein noch so ausgeklügeltes Debugging-Tool wettgemacht werden kann. C verführt durch weitgehendes Fehlen von sinnvollen Einschränkungen, was dem Motto alles ist erlaubt in idealer Weise entspricht. Dabei weiß man heute, daß eine Sprache sich nicht nur durch das auszeichnet, was sie auszudrücken erlaubt, sondern noch mehr durch das, was sie verbietet.

Erstaunlicherweise erlebt das Konzept des abstrakten Datentyps aber heute doch eine Wiedergeburt, allerdings unter einem anderen Namen: Objekt-orientiert. Obwohl die Quintessenz dieses Begriffs - den leider viele als Universalheilmittel betrachten - den Aufbau von Hierarchien von Klassen (Datentypen) betrifft, greifen die meisten zur Objekt-orientierten Programmierung, weil sie darin den ihnen bisher unbekannten Begriff abstrakter Datentyp erkennen. Dies bedeutet aber, daß jede Sprache, die die Bezeichnung Objekt-orientiert verdient, ein striktes Typenkonzept postulieren muß, auf das sich ein Compiler zur Konsistenzprüfung abstützen kann. Ironischerweise tut dies jedoch gerade diejenige Sprache nicht, die heute in der Objekt-orientierten Programmierung dominiert: C. Sie kann es nicht, da sie als aufwärtskompatibel mit ihrem Ahnen C erklärt wurde. Sie bestätigt damit eine Regel, die wir unserer Liste beifügen wollen:

Durch den Zwang zur Kompatibilität wird dem Programmierer das Konzept vorenthalten, mit dem sich methodische Arbeit leichter bewerkstelligen läßt und das vielleicht einen Weg ermöglichen würde, der dem stetigen Wachsen der Software nicht verpflichtet ist.

An diesem Punkt muß der Leser wohl überzeugt sein, daß hier ein allzu graues Bild der Zustände gemalt wird, ein Bild, das einem krankhaften Pessimismus entstammen muß und das jene helle Zukunft unbarmherzig ausschließt, die wir für das Gebiet der Informatik für unumstößlich halten. Obwohl das Bild leider recht realistisch ist, möchte ich doch nicht in dieser trüben Stimmung abschließen ohne zu erwähnen, daß es durchaus möglich ist, die erwähnten Umstände zu verändern und lean software zu erstellen, allerdings unter der Bedingung, daß man dazu auch willens ist.

Das Projekt Oberon

Im Jahr 1985 faßten J. Gutknecht und ich den Entschluß, das gesamte Software-System für eine Arbeitsstation von Grund auf zu entwerfen und zu programmieren. Sein Name ist Oberon [2].

Das wichtigste Ziel war zu zeigen, daß ein solches System ohne Einbuße an wesentlicher Funktionalität und Flexibilität mit einem Bruchteil der Ressourcen gebaut werden kann, die gemeinhin üblich sind. Das resultierende System wurde von uns wie vorgesehen in drei Jahren programmiert und wird seither täglich im ganzen Institut (...) benutzt, (...)

Das zweite wichtige Ziel war die Schaffung eines Systems, das in Einzelheiten studiert und erklärt werden kann, als Fallstudie im Software-Entwurf geeignet ist, top-down untersucht und verstanden werden kann und dessen Entwurfsentscheidungen nachvollziehbar sind. Es besteht ein bedauerlicher Mangel an solchen Fallstudien in der Fachliteratur, der einem bewußt wird, wenn man eine einschlägige Vorlesung mit Praktikum halten soll. Das Resultat unserer Arbeiten ist ein einziges Buch, das das gesamte System beschreibt und seinen Quellcode enthält [4].

Wie ist es überhaupt möglich, ein komplettes System inklusive Speicherverwaltung, Fensterverwaltung, File-System, Texteditor, Compiler, Grafikeditor und Netzwerk mit einem Aufwand von ungefähr fünf Mannjahren zu realisieren, dessen Beschreibung den Umfang eines Buches nicht übersteigt? Ich will erklären, was ich für die wichtigsten Gründe halte:

Der erste Grundsatz war, sich auf das Wesentliche zu konzentrieren und das Nebensächliche wegzulassen, auf Ausschmückungen (zumindest vorerst) konsequent zu verzichten. Zum Beispiel hatten wir die Benutzerinteraktion im Basissystem auf textuelle Information beschränkt und Grafiken, Bilder und icons weggelassen.

Der zweite Grundsatz war die Verwendung einer tatsächlich höheren, d.h. Typen-sicheren, strukturierten Progammiersprache, die auch den Objekt-orientierten Programmstil unterstützt. Gerade dies und die Überzeugung, daß der erste Grundsatz nicht nur für das zu bauende System, sondern insbesondere auch für die dafür verwendeten Werkzeuge gelten müsse, zwang uns zum gleichzeitigen Entwurf einer eigenen Programmiersprache und ihrer Implementierung. Das führte zur Sprache Oberon [3], einem Derivat von Modula-2 und damit indirekt von Pascal.

Der dritte Grundsatz kam aus der Erkenntnis, daß ein System, das sowohl einfach als auch effizient sein soll, unbedingt leicht erweiterbar sein muß. Unter erweiterbar verstehen wir nicht nur die Zufügbarkeit von Modulen, die neue, sich auf das Vorhandene abstützende Prozeduren enthalten, sondern auch, daß neue Datentypen, sog. erweiterte Typen, vereinbart werden können, die mit bestehenden kompatibel sind.

Ein Datentyp T1, der eine Erweiterung von T0 ist, übernimmt also alle Attribute von T0, und alle Operationen, die auf Daten vom Typ T0 anwendbar sind, sind auch auf T1 anwendbar. Die Typen-Erweiterung ist das einzige neue Konzept von Oberon, das in Modula-2 nicht bereits vorhanden war.

Dieses Konzept ist in der Objekt-orientierten Programmierung unter der Bezeichnung Unterklasse bekannt. Durch die Abbildung des Klassenbegriffs auf das Typenkonzept wurde es möglich, die Objekt-orientierte Programmierung als auf der klassischen, prozeduralen Programmierung aufbauend zu betrachten, wobei eben nur die Typenerweiterung als wesentlicher Zusatz hinzukommt. Wir vermeiden damit die Einführung einer völlig neuen Terminologie. So bleiben wir bei der Bezeichnung Typ anstelle von Klasse, bei Variable und Prozedur anstelle von Instanz und Methode sowie Erweiterung anstelle von Vererbung. Anstatt T1 erbt von T0 heißt es: T1 ist eine Erweiterung von T0. Offenbar gilt unser erster Grundsatz nicht nur für System und Sprache, sondern auch für die Terminologie. (...)

Schlußfolgerungen

Zum Schluß einige Erfahrungen, die wir mit diesem Projekt gemacht haben. Vielleicht können sie beim Bau anderer Systeme beherzigt werden.

Die ausschließliche Verwendung einer Programmiersprache mit statischen Datentypen war wohl der einflußreichste Faktor, der die Implementation eines ganzen Systems in derart kurzer Zeit ermöglichte. Der Aufwand an manpower war denn auch nur ein Bruchteil dessen, was sonst in vergleichbaren Unterfangen benötigt wird. Statische Typenprüfung erlaubt es dem Compiler, Inkonsistenzen, d.h. Programmierfehler vor der Ausführung aufzuzeigen, und dem Programmierer, Datendefinitionen und -strukturen zu ändern ohne große Gefahr, daß bestimmte Konsequenzen der Änderung übersehen werden. Statische Typenprüfung beschleunigt nicht nur die Änderung; sehr oft würde man gar nicht wagen, sie ohne die Typenprüfung vorzunehmen.

Der wohl schwierigste Teil einer Entwurfsarbeit ist das Auffinden der geeignetsten Modul-Zerlegung. Die Sprache Oberon unterstützt diesen Prozeß wesentlich, indem explizit angegeben wird, was von einem Modul importiert (verwendet) und exportiert (definiert) wird, und indem der Compiler die Typenprüfung auch über Modulgrenzen hinweg gewährleistet. Dies erlaubt den graduellen Aufbau der gewünschten Modulhierarchie.

Oberons Konzept der Typen-Erweiterung hat sich als Schlüssel für den Bau eines wirklich erweiterbaren Systems erwiesen, in dem neue Module nicht nur Funktionalität einbringen, sondern auch neue Arten von Objekten, die mit den bereits vorhandenen zweckdienlich integrierbar sind. Erweiterbarkeit ist die unerläßliche Vorbedingung für ein System, das nicht von Anfang an schwerfällig (bulky) ist und dennoch nach Bedarf erweitert werden und beliebigen Anforderungen genügen kann.

Sowohl beim Kernsystem wie bei Erweiterungen ist das Schlüsselproblem das Finden der richtigen Primitiva (Datentypen und Operationen), auf denen (weitere) Erweiterungen in einfacher Weise möglich sind, ohne daß ihre Anzahl geschwürartig wächst.

Der Glaube, daß der Bau komplexer Systeme Armeen von Mitarbeitern benötigt, ist falsch. Systeme, die nicht von Einzelpersonen in ihrer Gesamtheit verstanden werden- wenigstens bis zu einem gewissen Grad an Einzelheiten - , sollten wohl besser gar nicht gebaut werden.

Wenn die Anzahl der Teilnehmer an einem Projekt ein bestimmtes Maß übersteigt, wächst der Aufwand an Kommunikation und Koordination unverhältnismäßig. Beginnt er zu dominieren, sind Projekt und Team in ernsthaften Schwierigkeiten, oft ohne es zu merken.

Die Reduktion von Komplexität und Größe muß das Ziel bei jedem Schritt sein, in der Spezifikation der Anforderungen, im Entwurf der Lösung und im detaillierten Programmieren. Eines Programmierers Kompetenz muß nach seiner Fähigkeit beurteilt werden, einfache Lösungen zu finden, und sicher nicht nach der Anzahl Programmzeilen, die er pro Zeiteinheit niederschreibt.

Um Erfahrungen im Systembau einzuholen, gibt es keinen Ersatz für die eigene Betätigung. Die strikte Aufteilung von Teams in Manager, Konstrukteure, Programmierer, Analysten und Benutzer ist nicht zweckdienlich. Alle sollten an allen Aspekten teilnehmen, wenn auch mit individuellen Schwerpunkten. Insbesondere sollten alle, Manager miteingeschlossen, für einige Zeit die Rolle des Benutzers übernehmen. Dies bietet die beste Garantie, daß Fehler einigermaßen rasch erkannt und behoben werden; und vielleicht sogar, daß überflüssige Funktionen eliminiert werden.

Programme sollten so geschrieben und poliert werden, daß sie veröffentlicht werden könn(t)en. Es ist sehr viel anspruchsvoller, ein publizierbares Programm zu erstellen, als eines, das läuft.

Die Ansicht, daß Programme nur für den Computer geschrieben werden, ist leider weit verbreitet. Programme sollten (auch) für den menschlichen Leser zugänglich sein, und sei es nur für den Autor selber. Falls diese Forderung bestimmten Interessen in der Industrie entgegenläuft, sollte sie wenigstens in der akademischen Welt keinem Widerstand begegnen.

Mit dem Projekt Oberon haben wir gezeigt, daß flexible und leistungsfähige Systeme mit wesentlich geringerem Aufwand an Arbeit und Ressourcen gebaut werden können, als dies gemeinhin üblich ist. Die Plage der Software-Explosion ist also nicht naturbedingt; es liegt an uns, sie einzudämmen und zu beseitigen.

Literatur

Kürzungen und Layout:

Frank Elsner, Tel.: 2343

E-Mail: elsner@titan.rz.uni-osnabrueck.de