Aus wwwicg.informatik.uni-rostock.de :

Nikolaus Wirth

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 Faellen ueblich, sucht sie einen Kompromiss und hofft, die Loesung im Hinzufuegen von neuen Features in alten Systemen zu finden. Dies fuehrt jedoch unweigerlich zu immer umfangreicheren Konstruktionen, deren Inneres komplex und undurchsichtig wird und die vielbeschworenen Prinzipien der systematischen Struktur, Klarheit und Zuverlaessigkeit, Luegen 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 Abstuetzung auf bestehende Systeme, aufgebaut. Sozusagen als Nebenprodukt entstand die Sprache Oberon als auf das Wesentliche reduzierte Version von Pascal und Modula, vergroessert jedoch um das neue Konzept der erweiterbaren Datentypen, das fuer den Objekt-orientierten Programmierstil unerlaesslich ist. Das Oberon-System ist sehr flexibel, maechtig und leicht erweiterbar, aber dennoch kompakt und oekonomisch. Wir legen seine hauptsaechlichen, innovativen Konzepte dar. Sie haben unsere Faehigkeiten, moderne Software zu konstruieren, vervielfacht. Das System wurde seit seiner Konzeption 1986 auf zahlreiche kommerzielle Rechner uebertragen.

Einleitung

Moderne Software zum Betrieb eines Rechners am Arbeitsplatz (workstation) erfordert heute typischerweise einen Speicher von mehreren Megabyte Kapazitaet. Oft erhoeht eine neue, verbesserte oder korrigierte Version die Speicheranforderung substantiell. Wenn diese die bestehende Kapazitaet uebersteigt, wird zusaetzlicher Speicher eingekauft. Wird die Grenze der Erweiterbarkeit ueberschritten, muss ein neuer Rechner beschafft werden. Es stellt sich spaetestens dann die Frage, ob die zusaetzliche Funktionalitaet die aufgezwungenen Kosten rechtfertigt. Meistens tut sie es nicht.

Ich erinnere mich noch daran, dass vor ungefaehr 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. Gaebe es keine tausendmal schnellere Hardware, muesste man heute Software als schlechthin unbrauchbar bezeichnen. Natuerlich dient die erhoehte Benutzerfreundlichkeit und die erweiterte Funktionalitaet als Rechtfertigung der massiv erhoehten Ansprueche an Ressourcen. Bei genauerem Hinsehen stehen jedoch viele dieser Rechtfertigungen auf wackligen Beinen. Ein Texteditor dient noch immer dem Einfuegen, Verschieben und Loeschen von Teilen eines Textes, ein Compiler uebersetzt noch immer Quelltexte in Maschinencode, und ein Betriebssystem verwaltet noch immer die Ressourcen eines Rechners, Primaerspeicher, Plattenspeicher, Prozessorzyklen. Die grundlegenden Aufgaben haben sich durch Fenstertechnik, cut and paste-Strategien, pop up windows nicht veraendert, auch nicht durch das Ersetzen sinnvoller Befehlswoerter durch lustige icons.

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

Aussichten fuer eine weitere Leistungssteigerung sind nach wie vor vorhanden. Gleichzeitig gibt es keine Anzeichen dafuer, dass der Appetit neuer Software abnehmen wird [1]. Diese Entwicklung der Dinge war bereits Anlass fuer einige Faustregeln, Gesetze und Korollare. Sie sind - wie ueblich in solchen Faellen - eher vage und unverbindlich formuliert und weder beweisbar noch widerlegbar. Obwohl sie zunaechst eher sarkastisch erscheinen moegen, stellen sie doch den Sachverhalt erschreckend klar dar:

Software expandiert, bis der Speicher gefuellt ist. (Parkinson)

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

Ausser der Leistungssteigerung der Hardware gibt es einen weiteren Grund fuer die geduldige Akzeptanz des unkontrollierten Software-Wildwuchses, naemlich die weitverbreitete Unfaehigkeit der Benutzer, zwischen zur Loesung einer Aufgabe wirklich benoetigten und nice to have-Features zu unterscheiden. Ein Beispiel sind die heute ueblichen ueberlappenden Bildschirm-Fenster, die zwar ein elegantes Abbild unseres Schreibtisches sein moegen, gegenueber nicht-ueberlappenden und wesentlich einfacher zu realisierenden Fenstern jedoch keine zusaetzliche Funktionalitaet bringen. Ein anderes Beispiel sind die beruehmten icons, die den Bildschirm mit Briefkaesten und Abfallkuebeln amerikanischer Praegung dekorieren, ergaenzt durch das Sichtbarmachen der Bewegung ausgewaehlter Objekte vom Bildschirm zu ihrem endgueltigen Bestimmungsort, eben dem Abfallkuebel. Diese Spielzeuge moegen 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 nuetzlich oder gar unerlaesslich, sind diese Werkzeuge in uebertriebener Weise gewachsen, und sie haben zu der weitverbreiteten Ansicht beigetragen, dass das Programmieren lediglich aus wiederholtem Probieren und Korrigieren besteht. Dadurch wurde leider eine eher unprofessionelle Haltung gegenueber dem Konstruieren von Programmen gefoerdert. Die unausweichliche Konsequenz davon ist, dass 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.

Gruende fuer Fat Software

So haben wir denn zwei Faktoren identifiziert, die die Akzeptanz aufgeblaehter Software ermoeglichen, naemlich die schnelle Leistungssteigerung der Hardware und die Nachlaessigkeit der Kunden bezueglich kritischer Evaluation. Doch wichtiger als die Gruende fuer die Akzeptanz ist die Frage Was macht Software komplex?

Hier scheint mir die Tatsache ausschlaggebend, dass Hersteller kritiklos jedes Feature implementieren, das von Kunden gewuenscht wird, unabhaengig davon, wie (un)begruendet solche Wuensche sein moegen. Sind die gewuenschten Features inkompatibel mit dem Konzept des bestehenden Systems, wird dies entweder nicht bemerkt oder geflissentlich uebersehen. Das jedoch fuehrt zu komplexeren und vertrackten Konstruktionen und zu muehsamerem Erlernen ihrer Verwendung. Der Grund fuer die unbesehene Uebernahme neuer Features ist letztlich die Ansicht, dass Quantitaet wichtiger ist als Qualitaet. In der Tat wird die Guete eines Systems meist mit der Anzahl seiner Features gemessen. Jede nachfolgende Version muss zwangslaeufig zusaetzliche Features aufweisen, selbst wenn sie die Funktionalitaet des Systems gar nicht erhoehen.

Ein weiterer Grund liegt im ueblichen monolithischen Design. Beim Bau eines Systems werden alle erdenklichen Features sogleich beruecksichtigt und eingebaut. Jeder Kunde muss fuer sie alle bezahlen; er hat keine Auswahl, obwohl er typischerweise nur wenige dieser Features benutzen wird. Die vernuenftige Loesung besteht im Bau eines Systemkerns, der nur die wichtigen und unabdingbaren Features anbietet, jedoch leicht erweiterbar ist. Jeder Kunde kann dann jene Erweiterungen auswaehlen, die seinen spezifischen Beduerfnissen entsprechen.

Zweifellos war die gesteigerte Leistung der Hardware immer der primaere Anreiz, komplexere Probleme mittels Computer anzugehen. Komplexere Probleme bedingen meistens auch komplexere Loesungen. Ich spreche hier aber nicht diese inhaerente Komplexitaet an, sondern die hausgemachte, durch mangelhafte Analyse, mangelhaftes Koennen, unzweckmaessiges Vorgehen verursachte. Wer kennt nicht Probleme, fuer die schon vor vielen Jahren Software vorhanden war und fuer die heute viel umfangreichere Software angeboten wird.

Ein grosser Teil des zusaetzlichen Umfangs geht ohne Zweifel auf das Konto der vielgepriesenen Benutzerfreundlichkeit. (...) Ich habe die Einfachheit der Bedienung eines Systems stets als Primaerziel bei der Software-Entwicklung betrachtet, glaube aber, dass diese auf einer Systematik des zugrundeliegenden Konzepts beruhen muss, die die Benutzung gleichsam offensichtlich und selbstverstaendlich macht. Ich stelle jedoch fest, dass viele Leute von Komplexitaet fasziniert sind, sie sozusagen als Mehrwert empfinden. Dieser psychologische Trend ist mir ein Raetsel, und ich meine, dass sich gegenueber dem Unerklaerlichen eher Argwohn als Faszination einstellen sollte. Vielleicht ist dieser Trend auf das Gefuehl zurueckzufuehren - das von Geraeten eingefloesst wird, deren Komplexitaet jedes vollstaendige Verstehen ausschliesst - , eine Aura von Macht zu erhalten, die anderen nicht so leicht zugaenglich ist. Leichter verstaendlich waere jedenfalls ein Gefuehl der Hilflosigkeit oder gar Ohnmacht gegenueber diesen komplexen Artefakten. Die obige Hypothese aber laesst den Gebrauch von Komplexitaet zur Foerderung des Verkaufs verstaendlich werden. Komplexitaet ist zu einem wichtigen Mittel geworden, um die Abhaengigkeit der Kunden vom Hersteller zu foerdern. Zu diesem Zweck haben grosse Software-Haeuser stark in ihre Kundendienste investiert und gar Hunderte von Mitarbeitern eingestellt, die rund um die Uhr Hilferufe von Kunden beantworten und sie damit staerker an den Hersteller binden.

Obwohl diese Investitionen sich offenbar bezahlt gemacht haben, glaube ich, dass ein Produkt basierend auf einem systematischen Konzept, begleitet von einem konzisen Manual und einem ausgefeilten Tutorial sowohl fuer den Kunden als auch fuer den Hersteller letztlich wesentlich oekonomischer waere. Allerdings ist nicht zu bestreiten, dass ein weiterhin vom offerierten Kundendienst abhaengiger Kunde eine dauerhaftere Quelle von Einkuenften ist als ein Kunde, der das Produkt voellig beherrscht und versteht. Der Verdacht liegt nahe, dass in dieser Beziehung Industrie und Universitaet grundsaetzlich verschiedene Zielsetzungen haben, und ihm verdankt folgendes Wirtschafts-Gesetz seinen Ursprung:

Die Abhaengigkeit der Kunden ist eintraeglicher als ihre Ausbildung.

Manuale mit Hunderten von Seiten sind heute ueblich fuer Programmiersprachen, Betriebssysteme und alle Arten von Software-Werkzeugen. Sie sind untruegliche Zeichen von vertracktem Design, unklarem Konzept, aber auch von der Absicht, den Kunden abhaengig zu machen. Denn wer moechte schon auf ein Konkurrenzprodukt wechseln, nachdem er endlich den Inhalt dieser Waelzer gemeistert hat?

Nun sind dies aber sicher nicht die einzigen Gruende fuer die Software-Explosion. Meistens ist sie nicht geplant; sie ist einfach ploetzlich da. Bestimmt ist die Loesung komplexer Probleme schwierig und zeitaufwendig. Dies gilt uebrigens fuer 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 zurueckzufuehren. Sie beruht hauptsaechlich auf besserer Fabrikationstechnik, d.h. der Technik der Duplizierung. Hingegen ist im Software-Bereich alles Design; Duplikation war seit jeher gratis.

Erste Ansaetze bei der Software-Konstruktion fuehren meist zu komplexen Gebilden. Erst wiederholte Verbesserungen oder gar Neuanfaenge unter Beruecksichtigung der erhaltenen Erkenntnisse erbringen die gewuenschte Qualitaet. Die erfolgreichsten Schritte sind diejenigen, die eine Vereinfachung herbeifuehren oder gar Teile eines Programms als ueberfluessig erscheinen lassen. Entwicklungen dieser Art trifft man jedoch in der Praxis selten an, weil sie ein zeitaufwendiges Ueberdenken erfordern, das meistens kaum belohnt wird. Stattdessen werden Unzulaenglichkeiten durch rasch gefundene Zusaetze ueberdeckt, deren Summe schliesslich zur bekannten fat software fuehrt.

Man beachte, dass rasch gefundene Zusaetze im Gegensatz zu zeitaufwendigem Ueberdenken steht. In der Tat ist ein Hauptgrund fuer wuchernde Software der Zeitdruck, unter dem Ingenieure stehen. Zeitdruck verhindert sorgfaeltiges Planen, und noch mehr verhindert er die Suche nach besseren Loesungen. Er verleitet zu rasch gefundenen Zusaetzen und Korrekturen. Zeitdruck fordert hohe Qualitaetsmassstaebe als Opfer. Er hat einen negativen Einfluss auf Mensch und Produkt.

Der Umstand, dass der Hersteller, dessen Produkt zuerst auf dem Markt erscheint, erfolgreicher sein wird als sein Konkurrent, der seinen Leuten mehr Zeit laesst und dadurch zweiter wird mit einem besseren Produkt, hat ebenfalls einen negativen Einfluss auf die Produktqualitaet 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 Massstaebe von Prozessorleistung und Speicherkapazitaet ueberaus rasch wechseln. Serioese Konstruktions-Disziplin scheint kurzfristig nicht mehr lohnend zu sein, zumal die Tendenz vorherrscht, dass das zuerst auf dem Markt erscheinende Produkt zum de-facto-Standard fuer alle Zeiten erkoren wird.

Sprachen und Entwurfsmethodik

Wir sind alle in dem Glauben aufgewachsen, dass die Forschung eine entscheidende Rolle fuer die Zukunft unserer Gesellschaft spielt, insbesondere fuer die zukuenftige Technik. Daher wurde auch viel Aufwand in die Entwicklung einer Software-Methodik gesteckt. Aus dem soeben Gesagten laesst sich aber schliessen, dass diese Bemuehungen fuer die Industrie nur von beschraenkter Relevanz sein koennen. Vorschlaege fuer methodisches Vorgehen werden eher skeptisch beurteilt, weil sie zuviel time to market erfordern.

Vorschlaege fuer analytische Verifikation von Programmen und Korrektheitsbeweise fahren sogar noch schlechter, da sie hoehere intellektuelle Anforderungen stellen als der uebliche Ansatz unter dem Motto Probieren und Korrigieren. Vorschlaege, die Komplexitaet durch kompromisslose Einschraenkung auf das Wesentliche einzudaemmen, gelten als akademisch oder laecherlich im Hinblick auf das Verlangen der Kunden nach Verzierungen und Firlefanz. Wir schliessen daraus zwangslaeufig, dass sich Forschung auf diesem Gebiet nicht mehr lohnt. Methodik und Disziplin sind ohnehin verpoent 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, dass Programmentwurf auf strukturierten Methoden basieren muesse und durch Schichten von Abstraktionen mit klar definierten Spezifikationen charakterisiert sei. Die Begriffe abstrakter Datentyp und Kapselung haben dies trefflich verkoerpert, 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 bezueglich Entwicklung von Methodik und Sprachstruktur auf dem Stand der 60er Jahre steht. Das Konzept der Datentypen hatte in C hoechstens rudimentaer Eingang gefunden, jedenfalls nicht annaehernd so, dass ein Compiler zuverlaessig Typenkonsistenzpruefungen durchfuehren koennte. Aus reicher Erfahrung wissen wir aber heute, dass gerade das konsequent durchgezogene Typenkonzept die Hilfe bringt, deren Fehlen durch kein noch so ausgekluegeltes Debugging-Tool wettgemacht werden kann. C verfuehrt durch weitgehendes Fehlen von sinnvollen Einschraenkungen, was dem Motto alles ist erlaubt in idealer Weise entspricht. Dabei weiss man heute, dass eine Sprache sich nicht nur durch das auszeichnet, was sie auszudruecken 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, dass jede Sprache, die die Bezeichnung Objekt-orientiert verdient, ein striktes Typenkonzept postulieren muss, auf das sich ein Compiler zur Konsistenzpruefung abstuetzen 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 aufwaertskompatibel mit ihrem Ahnen C erklaert wurde. Sie bestaetigt damit eine Regel, die wir unserer Liste beifuegen wollen:

Fortschritt ist dann akzeptabel, wenn er mit der Vergangenheit kompatibel ist.

Durch den Zwang zur Kompatibilitaet wird dem Programmierer das Konzept vorenthalten, mit dem sich methodische Arbeit leichter bewerkstelligen laesst und das vielleicht einen Weg ermoeglichen wuerde, der dem stetigen Wachsen der Software nicht verpflichtet ist.

An diesem Punkt muss der Leser wohl ueberzeugt sein, dass hier ein allzu graues Bild der Zustaende gemalt wird, ein Bild, das einem krankhaften Pessimismus entstammen muss und das jene helle Zukunft unbarmherzig ausschliesst, die wir fuer das Gebiet der Informatik fuer unumstoesslich halten. Obwohl das Bild leider recht realistisch ist, moechte ich doch nicht in dieser trueben Stimmung abschliessen ohne zu erwaehnen, dass es durchaus moeglich ist, die erwaehnten Umstaende zu veraendern und lean software zu erstellen, allerdings unter der Bedingung, dass man dazu auch willens ist.

Das Projekt Oberon

Im Jahr 1985 fassten J. Gutknecht und ich den Entschluss, das gesamte Software-System fuer eine Arbeitsstation von Grund auf zu entwerfen und zu programmieren. Sein Name ist Oberon [2].

Das wichtigste Ziel war zu zeigen, dass ein solches System ohne Einbusse an wesentlicher Funktionalitaet und Flexibilitaet mit einem Bruchteil der Ressourcen gebaut werden kann, die gemeinhin ueblich sind. Das resultierende System wurde von uns wie vorgesehen in drei Jahren programmiert und wird seither taeglich im ganzen Institut (...) benutzt, (...)

Das zweite wichtige Ziel war die Schaffung eines Systems, das in Einzelheiten studiert und erklaert 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 bewusst wird, wenn man eine einschlaegige Vorlesung mit Praktikum halten soll. Das Resultat unserer Arbeiten ist ein einziges Buch, das das gesamte System beschreibt und seinen Quellcode enthaelt [4].

Wie ist es ueberhaupt moeglich, ein komplettes System inklusive Speicherverwaltung, Fensterverwaltung, File-System, Texteditor, Compiler, Grafikeditor und Netzwerk mit einem Aufwand von ungefaehr fuenf Mannjahren zu realisieren, dessen Beschreibung den Umfang eines Buches nicht uebersteigt? Ich will erklaeren, was ich fuer die wichtigsten Gruende halte:

Der erste Grundsatz war, sich auf das Wesentliche zu konzentrieren und das Nebensaechliche wegzulassen, auf Ausschmueckungen (zumindest vorerst) konsequent zu verzichten. Zum Beispiel hatten wir die Benutzerinteraktion im Basissystem auf textuelle Information beschraenkt und Grafiken, Bilder und icons weggelassen.

Der zweite Grundsatz war die Verwendung einer tatsaechlich hoeheren, d.h. Typen-sicheren, strukturierten Progammiersprache, die auch den Objekt-orientierten Programmstil unterstuetzt. Gerade dies und die Ueberzeugung, dass der erste Grundsatz nicht nur fuer das zu bauende System, sondern insbesondere auch fuer die dafuer verwendeten Werkzeuge gelten muesse, zwang uns zum gleichzeitigen Entwurf einer eigenen Programmiersprache und ihrer Implementierung. Das fuehrte zur Sprache Oberon [3], einem Derivat von Modula-2 und damit indirekt von Pascal.

Der dritte Grundsatz kam aus der Erkenntnis, dass ein System, das sowohl einfach als auch effizient sein soll, unbedingt leicht erweiterbar sein muss. Unter erweiterbar verstehen wir nicht nur die Zufuegbarkeit von Modulen, die neue, sich auf das Vorhandene abstuetzende Prozeduren enthalten, sondern auch, dass neue Datentypen, sog. erweiterte Typen, vereinbart werden koennen, die mit bestehenden kompatibel sind.

Ein Datentyp T1, der eine Erweiterung von T0 ist, uebernimmt 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 moeglich, 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 Einfuehrung einer voellig 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 heisst es: T1 ist eine Erweiterung von T0. Offenbar gilt unser erster Grundsatz nicht nur fuer System und Sprache, sondern auch fuer die Terminologie. (...)

Schlussfolgerungen

Zum Schluss einige Erfahrungen, die wir mit diesem Projekt gemacht haben. Vielleicht koennen sie beim Bau anderer Systeme beherzigt werden.

Die ausschliessliche Verwendung einer Programmiersprache mit statischen Datentypen war wohl der einflussreichste Faktor, der die Implementation eines ganzen Systems in derart kurzer Zeit ermoeglichte. Der Aufwand an manpower war denn auch nur ein Bruchteil dessen, was sonst in vergleichbaren Unterfangen benoetigt wird. Statische Typenpruefung erlaubt es dem Compiler, Inkonsistenzen, d.h. Programmierfehler vor der Ausfuehrung aufzuzeigen, und dem Programmierer, Datendefinitionen und -strukturen zu aendern ohne grosse Gefahr, dass bestimmte Konsequenzen der �nderung uebersehen werden. Statische Typenpruefung beschleunigt nicht nur die �nderung; sehr oft wuerde man gar nicht wagen, sie ohne die Typenpruefung vorzunehmen.

Der wohl schwierigste Teil einer Entwurfsarbeit ist das Auffinden der geeignetsten Modul-Zerlegung. Die Sprache Oberon unterstuetzt diesen Prozess wesentlich, indem explizit angegeben wird, was von einem Modul importiert (verwendet) und exportiert (definiert) wird, und indem der Compiler die Typenpruefung auch ueber Modulgrenzen hinweg gewaehrleistet. Dies erlaubt den graduellen Aufbau der gewuenschten Modulhierarchie.

Oberons Konzept der Typen-Erweiterung hat sich als Schluessel fuer den Bau eines wirklich erweiterbaren Systems erwiesen, in dem neue Module nicht nur Funktionalitaet einbringen, sondern auch neue Arten von Objekten, die mit den bereits vorhandenen zweckdienlich integrierbar sind. Erweiterbarkeit ist die unerlaessliche Vorbedingung fuer ein System, das nicht von Anfang an schwerfaellig (bulky) ist und dennoch nach Bedarf erweitert werden und beliebigen Anforderungen genuegen kann.

Sowohl beim Kernsystem wie bei Erweiterungen ist das Schluesselproblem das Finden der richtigen Primitiva (Datentypen und Operationen), auf denen (weitere) Erweiterungen in einfacher Weise moeglich sind, ohne dass ihre Anzahl geschwuerartig waechst.

Der Glaube, dass der Bau komplexer Systeme Armeen von Mitarbeitern benoetigt, 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 Mass uebersteigt, waechst der Aufwand an Kommunikation und Koordination unverhaeltnismaessig. Beginnt er zu dominieren, sind Projekt und Team in ernsthaften Schwierigkeiten, oft ohne es zu merken.

Die Reduktion von Komplexitaet und Groesse muss das Ziel bei jedem Schritt sein, in der Spezifikation der Anforderungen, im Entwurf der Loesung und im detaillierten Programmieren. Eines Programmierers Kompetenz muss nach seiner Faehigkeit beurteilt werden, einfache Loesungen zu finden, und sicher nicht nach der Anzahl Programmzeilen, die er pro Zeiteinheit niederschreibt.

Um Erfahrungen im Systembau einzuholen, gibt es keinen Ersatz fuer die eigene Betaetigung. 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, fuer einige Zeit die Rolle des Benutzers uebernehmen. Dies bietet die beste Garantie, dass Fehler einigermassen rasch erkannt und behoben werden; und vielleicht sogar, dass ueberfluessige Funktionen eliminiert werden.

Programme sollten so geschrieben und poliert werden, dass sie veroeffentlicht werden koenn(t)en. Es ist sehr viel anspruchsvoller, ein publizierbares Programm zu erstellen, als eines, das laeuft.

Die Ansicht, dass Programme nur fuer den Computer geschrieben werden, ist leider weit verbreitet. Programme sollten (auch) fuer den menschlichen Leser zugaenglich sein, und sei es nur fuer den Autor selber. Falls diese Forderung bestimmten Interessen in der Industrie entgegenlaeuft, sollte sie wenigstens in der akademischen Welt keinem Widerstand begegnen.

Mit dem Projekt Oberon haben wir gezeigt, dass flexible und leistungsfaehige Systeme mit wesentlich geringerem Aufwand an Arbeit und Ressourcen gebaut werden koennen, als dies gemeinhin ueblich ist. Die Plage der Software-Explosion ist also nicht naturbedingt; es liegt an uns, sie einzudaemmen und zu beseitigen.

Literatur

1. Perratore, E., et al.: Fighting Fatware. BYTE, April 1993, S. 98- 108

2. Reiser, M.: The Oberon System. Reading: Addison-Wesley 1991

3. Reiser, M., Wirth, N.: Programming in Oberon - Steps beyond Pascal and Modula. Reading: Addison-Wesley 1992

4. Wirth, N., Gutknecht, J.: Project Oberon - The Design of an Operating System and Compiler. Reading: Addison-Wesley 1992

Den vorstehenden, von uns gekuerzten Artikel von N. Wirth haben wir mit freundlicher Genehmigung des Springer Verlages der Zeitschrift Informatik Spektrum (1994) 17, Seiten 5-10, entnommen. Wir danken dem Verlag fuer die Abdruckgenehmigung. Wir hoffen, dass sowohl Anwender als auch Programmierer (auch Anhaenger von C) aus diesem Artikel einige Anregungen beziehen.

Kuerzungen und Layout:

Frank Elsner, Tel.: 2343

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