Als auf der NATO-Tagung 1978 in Garmisch-Partenkirchen die Begriffe Software-Krise und Software-Engineering als Technik zur Lösung geprägt wurden sind, hatte McIlroy in seinem Vortrag die Vision, daß sich die Software-Produktion grundlegend ändern könnte. Statt alles jedesmal aufs Neue von Grund auf zu entwickeln (analog zum Handwerk), sollte es doch möglich sein, Standard-Komponenten mit präzisen Spezifikationen zu entwickeln, die nur noch zusammenzusetzen sind (analog zur industriellen Produktion).
Entscheidend bei der Entwicklung und dem Zusammenbau von Komponenten sind die Schnittstellen bzw. Protokolle, die in Form von Abstraktionen zusammengefaßt werden. Leider fehlten den klassischen Programmiersprachen (z.B. Fortran, Cobol, Algol, Pascal und C) jegliche Unterstützung zur Formulierung von Abstraktionen und der Gewährleistung von Schnittstellensicherheit.
Bei einigen Programmiersprachen der 70er Jahre (z.B. Mesa, CLU, Modula-2 und Ada) wurde ein Modulkonzept eingeführt, das eine erste Unterstützung brachte. Allerdings war dabei die Einschränkung, daß zu einer Abstraktion nur eine Implementierung gleichzeitig im Programm vorhanden sein konnte. Es war also nicht möglich, das gleiche Protokoll für Objekte unterschiedlichen Typs zu verwenden.
Dieses Defizit wurde mit der Einführung der objekt-orientierten Programmiersprachen geschlossen (z.B. Simula, Smalltalk, Eiffel, C++ und Java). Leider kann bei der großen Mehrheit dieser Sprachen eine Abstraktion nur einen Objekt-Typ umfassen - es ist somit nicht möglich, daß im Rahmen einer Abstraktion mehrere Objekt-Typen definiert und miteinander in Beziehung gebracht werden. Ausnahmen sind hier z.B. Oberon, Modula-3 und BETA.
Dabei verdient der Punkt Beachtung, daß Abstraktionen nicht nur innerhalb eines Programms oder abgeschlossenen Software-Systems relevant sind. Vielmehr basieren alle Formen der Interaktion auf dem Internet auf Abstraktionen. Wenn somit eine geeignete Infrastruktur zur Verfügung steht (z.B. CORBA von der OMG), dann können bei der Etablierung entsprechender Standards beispielsweise Bestellungen, Rechnungen und Kontobewegungen über ein globales Netz abgewickelt werden.
Entscheidend sind aber nicht nur die sprachlichen Voraussetzungen, sondern ein ganzes Bündel von Software-Entwicklungstechniken zur Verbesserung der Software-Qualität, die sich aufgrund einer geeigneten Programmiersprache besser und kontrollierter umsetzen lassen. Entsprechend der Definition von Bertrand Meyer ist eine Unterscheidung in äußere und innere Qualität möglich. Die äußere Qualität ist die, die von dem Benutzer der Software wahrgenommen werden kann. Dies betrifft die Korrektheit (inwieweit entspricht die Software der Spezifikation), die Robustheit (inwiefern werden abnormale Randbedingungen toleriert und überlebt) und schließlich ergonomische Aspekte. Diese äußere Qualität ist kein Himmelsgeschenk, sondern läßt sich nur auf Basis ingenieurmäßiger Techniken erreichen, die in den inneren Qualitäten der Software ihren Ausdruck finden.
Schlüsselfaktoren nach Bertrand Meyer sind dabei:
Die Techniken, die weitgehend diesen Zielen dienen, lassen sich vereinfacht unter dem Stichwort ``objekt-orientierte Entwicklung'' zusammenfassen, wenngleich es weder allgemein akzeptierte präzise Definitionen noch etablierte Standards dafür gibt. Der Begriff der Objekt-Orientierung selbst ist relativ unglücklich - es wäre wohl passender gewesen, den Begriff ``abstraktions-orientiert'' zu verwenden.
Die Hauptzielrichtung objekt-orientierter Entwicklungstechniken liegt darin, jede Software-Komponente in eine abstrakte Welt einzubetten, um Abhängigkeiten zur realen Welt (und der gegebenen Spezifikation) zu minimieren oder gar ganz zu entfernen. Das Problem liegt darin, geeignete abstrakte Welten zu finden und zu strukturieren, die zu dem vorgegebenen Problemfeld passen - jedoch gleichzeitig so allgemein sind, so daß sie invariant gegenüber Änderungen des Problemfeldes sind.
Wenn abstrakte Welten und Strukturen genügend allgemein sind, werden daraus geeignete Kandidaten für den Aufbau einer objekt-orientierten Bibliothek. Letztendlich ist das Ziel, daß bei einer neuen Anforderung es nur notwendig ist, Abbildungen vorhandener Abstraktionen aus der Bibliothek auf konkrete Gegebenheiten geeignet miteinander zu kombinieren.
Sofern dieses Ziel noch nicht erreicht ist, empfiehlt es sich, nicht die neuen Anwendungen unnötig aufzublähen, sondern stattdessen nach den neuen notwendigen Abstraktionen und Verallgemeinerungen zu suchen, die für die neue Anwendung noch fehlen. Das Problem ist hier natürlich immer, daß dies jeweils einen höheren Aufwand erfordert, der sich erst in der Zukunft auszahlen wird - sei es bei der späteren Wartung der Software oder bei der Entwicklung weiterer ähnlicher Anwendungen.
Das Ziel der Vorlesung ist es, eine Einführung in die dafür notwendigen Techniken zu geben und sie anhand einer Reihe von allgemein nützlichen Abstraktionen der Ulmer Oberon-Bibliothek zu demonstrieren. Diese Bibliothek wurde deswegen gewählt, weil die zugrundeliegende Programmiersprache angenehm einfach ist und damit keine zusätzliche Hürde darstellt. Ferner gibt es leider nur sehr wenige objekt-orientierten Bibliotheken in öffentlich frei verfügbarer Form - die Ulmer Oberon-Bibliothek ist da eine der ganz wenigen Ausnahmen.
Darüber hinaus sind diese Techniken weitgehend unabhängig von der verwendeten Programmiersprache. Sie können also beispielsweise auch für Eiffel oder C++ eingesetzt werden.