Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

08.03.1985 - 

Hohe Hardware-Anforderungen hemmen noch den Masseneinsatz, dennoch:

Objektorientierte SWE ist auf dem Vormarsch

Neben der prozeduralen, funktionalen und relationalen Programmierung ist der Begriff der "objektorientierten Softwareentwicklung" in letzter Zeit ins Bewußtsein einer breiteren Öffentlichkeit getreten. Dies hat sicher unterschiedliche Gründe, ist aber wohl hauptsächlich auf einige Veröffentlichungen und Symposien zurückzuführen. Im folgenden sollen die Grundideen dieses Programmierstils und die ihn tragenden Softwaresysteme vorgestellt und diskutiert werden.

Objektorientierte Programmierung definiert Programme als Modelle problemrelevanter Realitätsausschnitte. Problemlösung ist aus einer solchen Sicht dann der Prozeß der Simulation des Verhaltens konkreter Objekte und ihrer Interaktionen. Nach dieser Auffassung ist jegliche Art von Programmentwicklung ein Modellbildungsprozeß, für den Strukturierungsideen der Simulationstechnik genutzt werden können.

In der Simulationsprogrammierung werden Modelle durch simultan existierende, kooperierende oder konkurierende Objekte beschrieben. Sie haben eine Attributsstruktur, können bestimmte Klassen von Aktionen durchführen, und kommunizieren untereinander über Nachrichten. Die solchermaßen durchgeführten Aktionsfolgen werden bei der Modellausführung in Berechnungsprozesse eingebunden.

Wissenschaft klassifiziert interessierende Realitätsaspekte in Modellstrukturen. Klassifikation und differenzierende Beschreibung sind wesentliche Aspekte jeglicher Art von Wissensorganisation. Wenn man von Individualität und unterschiedlichen Wertausprägungen abstrahiert, können Objekte mit gleicher Struktur und gleichen Verhaltensmustern zu Klassen zusammengesetzt werden.

Die Klasse "Vogel" könnte so beispielsweise die Tatsache beschrieben, daß Vögel üblicherweise Gefieder und Flügel besitzen und singen und flattern können. Der Ausdruck "differenzierende Beschreibung" bezeichnet eine Vorgehensweise, die neu einzuführende Objekte dadurch

klassifiziert, daß sie angibt, wie sie sich von bereits bekannten Objekten unterscheiden.

Vögel sind Warmblüter und haben daher Aspekte, die allen Warmblütern gemeinsam sind (zum Beispiel eine Körpertemperatur). Warmblüter sind wiederum Lebewesen und daher auch materielle Objekte. Alle materiellen Objekte haben Gewicht und Masse; außerdem können sie bewegt werden. Dies gilt auch für Lebewesen und daher auch für Warmblüter, also auch Vögel.

Die bloße Klassifikation als Vogel assoziiert ein individuelles Objekt also mit einer Vielzahl von Eigenschaften, Aktionen und Prozessen die in anderen Objektbeschreibungen bereits vorliegen. Man spricht von einer sogenannten Vererbungshierarchie oder einem Netzwerk. durch die Unterklassen an Oberklassen gebunden und Attribute sowie Aktionsmuster von "oben nach unten" vererbt werden. Unterklassen stellen so Spezialfälle ihrer Oberklassen dar. Die Programmiersprachen Simula und Smalltalk beschränken sich auf strikt hierarchische Vererbung, während einige Lisp-Dialekte Vererbungsnetze (eine Klasse kann Aspekte mehrerer Oberklassen erben) zulassen.

Aus so in Klassendefinitionen verkapselten Objektbeschreibungen können dann zur Programmlaufzeit individuelle Objekte erzeugt werden (zum Beispiel "Woodstock

-NEW Vogel"). An diese Objekte können Nachrichten gesandt werden, auf die sie reagieren können. "Woodstock flapWings: 10" ist nur sinnvoll, falls das Nachrichtenmuster (Methode) "flapWings: anlnteger" als Teil des Nachrichtenprotokolls der Klasse Vogel oder einer ihrer Oberklassen gefunden werden kann.

Andernfalls reagiert das System bei Auswertung dieses Ausdrucks mit "Message not understood" und bietet Fehlersuchhilfen an Falls die Nachricht bekannt ist, wird bei ihrem Empfang die entsprechende Methode angestoßen und ausgeführt. Dies mag bewirken, daß die externe Repräsentation des Objektes "Woodstock" auf dem Bildschirm zehnmal mit den Flügeln flattert.

Interaktion zwischen Objekten geschieht nur durch Nachrichtenübertragung. Objekte können Nachrichten an andere Objekte senden, deren Namen ihnen bekannt sind, beispielsweise um Dienstleistungen zu erbitten. Empfangenden Objekten steht es dann frei, solche Anfragen zu akzeptieren oder abzulehnen. Sie können sich dadurch selbst vor der Außenwelt schützen.

Es ist grundsätzlich nicht möglich, auf interne Daten oder Prozeduren direkt zuzugreifen, ohne eine in das Nachrichtenprotokoll des angewählten Objekts aufgenommene Methode zu benutzen. Auch die Art der Implementierung seiner Methoden steht jeder Objektklasse frei und kann lokal, ohne Auswirkungen auf den Rest des Systems geändert werden.

Das Nachrichtenprotokoll definiert die Funktionalität einer Objektklasse. Implementierungsdetails sind Außenstehenden nicht zugänglich. Nachrichten gleichen Namens können, an Objekte unterschiedlicher Klassen gesandt, zu unterschiedlichem Verhalten führen.

Dies wird in anderen Sprachansätzen häufig als "Overloading" von Operationsnamen bezeichnet. Die Nachricht "sing: 1 inKey: g-moll" (vorausgesetzt "sing: aSongNumber inKey: "KeySymbol" ist für Objektklassen Hund und Vogel jeweils durch lokale Methoden implementiert) wird unterschiedliche Folgen haben wenn sie von -Woodstock" oder "Snoopy" empfangen wird.

Der Begriff "objektorientiertes Programmieren" ist ursprünglich von Smalltalk geprägt worden. Diese Sprache wurde in den frühen 70er Jahren von A. Kay entwickelt, wobei Ideen aus Piaget´s Entwicklungspsychologie, der Simulationssprache Simula und dem Grafiksystem Sketchpad einen starken Einfluß ausübten. Kay war zu diesem Zeitpunkt Mitglied der "Learning Research Group" des Xerox Forschungszentrums in Palo Alto (PARC). Davor hatte er an der University of Utah über das Flex-System promoviert.

Smalltalk war als Programmiersprache des sogenannten Dynabook vorgesehen; der Vision eines persönlichen Informationssystems, im Buchformat, mit dem Kinder durch symbolische, grafische, akustische und visuelle Techniken kommunizieren sollten.

Das Dynabook-Projekt ist inzwischen eingestellt, aber eine Reihe von Entwicklungen dieser Gruppe sind für die Informatik richtungsweisend gewesen. Die Idee eines leistungsfähigen Arbeitsplatzrechners (Alto) mit reaktiver Umgebung ("what you see is what you get" ), die Rastergrafik und das Ethernet können hierhin zurückverfolgt werden

Die neuste Version der Sprache ist Smalltalk-80. Sie wird am Xerox PARC von der "Software Concepts"-Gruppe unter Leitung von Adele Goldberg gewartet und weiterentwickelt.

Diese Version wurde nach einer Testphase unter Mitwirkung von Apple, Tektronix, DEC, Hewlett-Packard und der Berkeley University erst 1983 durch eine Serie von vier Büchern und einer lizenzpflichtigen , übertragbaren Implementierung einer breiteren Öffentlichkeit zugänglich gemacht. Der Einsatz auf einem neuen Rechner erfordert die Programmierung einer virtuellen Maschine und wird mit sechs bis zwölf Mann-Monaten veranschlagt.

Für ein akzeptables Leistungsverhalten benötigt Smalltalk leistungsfähige Arbeitsplatzrechner mit großem Speicherraum (1 MB). Außerdem wird Rastergrafik und ein Zeigegerät (Maus) vorausgesetzt. Die Sprache ist nicht sinnvoll auf einem Time-Sharing-Rechner einsetzbar.

Zur Zeit existieren nur wenige kommerziell verfügbare

Implementationen (Xerox, Tektronix). Die am weitesten

verbreitete Version dürfte der sogenannte Berkeley Interpreter sein; eine von D. Ungar auf einer Sun-2 unter Berkeley-Unix in "C" implementierte virtuelle Maschine. Diese Version ist auch von Prof. Ganzinger in Dortmund auf einen Cadmus-Rechner übertragen worden. Es existiert eine aktive Implementor´s Group, die auch einen Newsletter herausgibt.

A. Kay ist inzwischen, wie auch viele andere wichtige Mitarbeiter des ursprünglichen Smalltalk Teams (Tesler, Ingalls, . . .) zu Apple übergewechselt. Die Benutzerschnittstellen der Lisa- und Macintosh-Systeme können direkt auf Smalltalk zurückgeführt werden.

Diese Sprache bietet ein auf Objektklassen basierendes Datenmodell, ein methodenorientiertes Operationsmodell und ein nachrichtenorientiertes Modell des Kontrollflusses in Berechnungsprozessen. Am bekanntesten ist die Sprache durch

ihre Programmierumgebung, die Interaktionen durch Maus, Menüs und Fenstertechnik ermöglicht. Eine Vielzahl interessanter und nützlicher Softwarewerkzeuge zur interaktiv-grafischen Unterstützung komplexer Systementwicklung sind in diese Schnittstelle eingebettet. Die sogenannte "Schreibtisch"-Metapher ist ebenfalls hier anzusiedeln.

Prozesse können jederzeit suspendiert und später neu aufgesetzt werden. Der durch solch eine Programmierumgebung induzierte Programmierstil ist "explorativ" im Sinne der KI-Programmierung; das heißt, unterschiedliche Programmodule können rasch und ineinander verzahnt entwickelt, getestet, modifiziert und integriert werden. Er ist auch sehr gut für die Lisp-Programmierung geeignet und wird daher heute auch auf allen sogenannten Lisp-Maschinen geboten. Die Grundidee geht aber auf Smalltalk zurück.

Smalltalk bietet eine recht eigenwillige, aber in sich höchst konsistente, flexible und ausdrucksfähige Syntax. Es können beispielsweise sehr leicht neue Datenstrukturen (Objektklassen), Operatoren und sogar Kontrollstrukturen (Methoden) definiert werden. Überhaupt ist das gesamte System außerordentlich "soft" .

Es gibt keine Unterscheidung zwischen invariantem Kern und durch den Benutzer definierten Konzepten. Mit Hilfe des sogenannten "Browsers" kann der Programmierer interaktiv durch das System navigieren und jederzeit Codes inspizieren, modifizieren oder neu einfügen. Hierdurch trägt er natürlich auch erhebliche Verantwortung.

Unglückliche Modifikationen können unter Umständen das gesamte System zum Einsturz bringen, so daß es neu gestartet werden muß. Der für Smalltalk typische Programmierstil besteht nicht im Einbringen umfangreicher Mengen neuer Codes, sondern in der geschickten Modifikation und Erweiterung bereits existierender Module. Es wird glaubhaft berichtet, daß ein Programmierer am Xerox PARC nach Ausfall der Tastatur seinen Rechner mit Hilfe der Maus über einen längeren Zeitraum hinweg nahezu ohne große Beeinträchtigung weiter nutzen konnte.

Objektorientierte Programmiertechniken sind hauptsächlich aus zwei Entwicklungssträngen herworgegangen; der Simulationstechnik und der künstlichen Intelligenz (KI). In der Simulationsprogrammierung sind ihre Wurzeln bei den sogenannten "prozeßorientierten" Sprachen, und hier insbesondere bei Simula zu suchen. Simula ist eine schon recht alte (1968), aber in ihren Grundkonzepten immer noch erstaunlich aktuelle Systembeschreibungssprache. Sie wurde von Dahl und Nygaard am Norwegian Computing Center in Oslo entwickelt. Inzwischen stehen leistungsfähige Übersetzer für nahezu alle gängigen Rechnertypen zur Verfügung. Die Sprache ist hauptsächlich in Skandinavien und Europa verbreitet.

Wegen ihrer ausgezeichneten Text- und Listenverarbeitungsfähigkeiten, ihres Koroutinenkonzepts, sowie des durch Simula in die Informatik eingeführten Klassenkonzepts wurde sie als Basissprache einiger Simulationssysteme (Demos, Disco) verwendet. Simula ist für andere Sprachentwicklungen (Smalltalk, Clu, Modula, Ada, . . .) richtungsweisend gewesen.

Zur objektorientierten Programmierung hat sie die Idee der Objektklasse/Instanz, der differenzierenden Systembeschreibung (Vererbungshierarchien) sowie der in Objekten verkapselten Methoden beigetragen.

Simulas typischer Programmierstil ist Algol-ähnlich, mit objektorientierten Aspekten. Diese strenge Sichtweise von Systemen, bei der Objekte NUR durch Nachrichtenfolgen kommunizieren können, wurde in dieser Konsequenz erst von Smalltalk entwickelt.

Im Rahmen von Forschungsarbeiten zur künstlichen Intelligenz wurden Mitte der siebziger Jahre von M. Minsky und anderen sogenannte "Frames" als Verfahren kontextbezogener Wissensverkapselung diskutiert. Diese Idee hat unter verschiedenen Namen (frames, scripts, units) auch in einigen, in unterschiedlichen Lisp-Dialekten eingebetteten Programmiersprachen ihren Niederschlag gefunden (FRL, KRL, Units, Pearl, . . .).

Frames sind Datenstrukturen zur Darstellung prototypischer Objekte, Aktionen und Situationen. Sie sind in Vererbungsnetze eingebunden und haben sogenannte "slots", die im Verlauf von Berechnungsprozessen mit Werten belegt werden.

Slots repräsentieren Attribute, denen außer Wertausprägungen auch Defaults, Beschränkungen und durch Wertänderungen ausgelöste Prozeduren (sogenannte "Dämonen") zugeordnet sein können. Das Konzept wurde von M. Minsky zur "Society of Experts" erweitert; einer Weltsicht, in der Programme aus autonomen Modulen bestehen, die miteinander kooperieren, verhandeln und konkurrieren.

Unter Einfluß der von Smalltalk getragenen Idee, Programmentwicklung als Modellierung von Realitätsausschnitten zu betrachten, entwickelten sich parallel dazu die sogenannten Aktorensprachen. Der Name wurde von C. Hewitt eingeführt und reflektiert die Vorstellung daß Objekte als eigenständig aktive Agenten begriffen werden. Sie besitzen einen Namen, eine Struktur und eine Menge von Verhaltensmustern die sie auf Verlangen aufführen können. Dies ist die gleiche Idee, wie sie Smalltalk zugrunde liegt. Nur die Terminologie und Syntax (Lisp als Basissprache) ist anders. Plasma wurde als älteste Aktorensprache am MIT von Hewitt konzipiert.

Der Ansatz ist inzwischen in ACT weiterentwickelt worden. Glisp kann jedem der bedeutenderen Lisp-Dialekte als Spezialsprache aufgepfropft werden, um in ihnen objektorientiert zu programmieren. ObjTalk ist eine deutsche Entwicklung von J. Laubsch auf Maclisp Basis. "Flavors" ist der Name einer Untermenge von Zetalisp. Sie erlaubt den Einsatz objektorientierter Programmierstile auf "Symbolics Lisp-Maschinen". Der Name "Flavors" betont die Möglichkeit multiple Vererbungsstränge miteinander zu mischen.

Der Kopf des Vererbungsnetzes wird "Vanilla Flavor" genannt. Er kann mit allen anderen Flavors kombiniert werden. Loops ist ein auf Xerox-Lisp-Maschinen verfügbares

Programmierwerkzeug zur Entwicklung wissensbasierter Systeme. Neben der objektorientierten Wissensdarstellung unterstützt es prozedurale regelorientierte Beschreibungstechniken. Loops ist als Obermenge von Interlisp-D implementiert.

Die Idee der "Programmierung durch Modellbildung" bedingt eine enge Entsprechung von Objekten, Beziehungen, Aktionen und Prozessen eines relevanten Realitätsausschnitts und ihrer formalen Darstellung. Das darauf resultierende Konzept der "Verkapselung von Zustandsbeschreibung und Prozeduren in Objektstrukturen" führt zu einem hochgradig modularen Programmaufbau.

Diese Vorgehensweise ist naürlich am wirkungsvollsten, wenn separable Systeme betrachtet werden, in denen stark interagierende Subsysteme nur lose miteinander gekoppelt sind. Die Tatsache, daß Objektzustände nur durch über Nachrichten angestoßene, im Objekt selbst verkapselte Methoden geändert werden können, führt zu robusten Systemen, in denen Objekte sich gegenüber falschen Eingaben (Nachrichten) selbst verteidigen können.

In dieser Hinsicht bestehen Ahnlichkeiten mit der Idee der "abstrakten Datentypen" und Abstraktionsformen die von neueren Sprachen (Edison, Ada, Modula, . . .) als Datenverkapselungstechniken (clusters, packages, modules, ...) bereitgestellt werden. Entwicklungen in diesem Bereich sind letztlich ja auch auf Simulas Klassenkonzept zurückzuführen.

Allerdings sind Ziele und Leistungen beider Ideenkreise doch unterschiedlich. Bei der obiektorientierten Programmierung steht der Modellierungsgedanke im Vordergrund. Objektbeschreibungen werden in geschlossene Textmodule verkapselt, weil sie logisch zusammenhängende Aspekte eines Systemmodells beschreiben. Sie bilden mit ihren Nachrichtenprotokollen neue Abstraktionsebenen, auf denen man über ein zu modellierendes System in Anwendungskategorien reden kann. Objektinkarnationen werden im Verlauf von Berechnungsprozessen, die Systemsimulationen darstellen, bei Bedarf dynamisch erzeugt.

Bei der reinen Datenverkapselungstechnik werden durch Defimtion abstrakter Datentypen natürlich auch neue Abstaktionsebenen geschaffen. Die Betonung liegt hier jedoch auf dem Zuverlässigkeitsaspekt nach dem Prinzip des "information hiding". Module sollen nicht mehr Wissen über ihre Umgebung besitzen, als sie zur Durchführung ihrer Aufgaben unbedingt benötigen.

Die Fähigkeit, sich gegen unzulässige Zugriffe und inkorrekte Informationen selbst zu verteidigen, ist der wesentliche Aspekt, nicht der Modellierungsgedanke. Daher bestehen Sprachen, die diese Art der Wissensverkapselung unterstützen, aus Effizienzgründen üblicherweise darauf, Inkarnationen (Variablen) von Objekten bereits zur

Übersetzungszeit zu binden. Packages oder Modules in Ada und Modula können nicht im Verlauf eines Verhalten von Realsystemen darstellenden Berechnungsprozesses dynamisch erzeugt werden. Das primäre Ziel ist zuverlässige Systementwicklung, nicht Modellstrukturierung. Die Idee der differenzierenden Beschreibung durch Vererbung von Eigenschaften und Verhaltensmustern ist daher hier auch nicht relevant.

In der objektorientierten Programmierung dient die Technik der differenzierenden Beschreibung von Objekten als Spezialfällen bereits bekannter Objekte der Reduktion des Modellbeschreibungsaufwands .

In beiden Programmiertechniken können Änderungen des Systemverhaltens durch lokale Änderungen von Objektdefinitionen bewirkt werden. Dies verbessert Verständlichkeit und Wartung von Programmen und ermöglicht separate Entwicklung und Test von Modulen. Die Namensgebung erfolgt lokal für den Kontext einer Objektklasse. Globale Konventionen sind bis auf einige global sichtbare Strukturen wie Klassennamen, nicht erforderlich.

Da Objekte voneinander unabhängig sind und sich nur über Nachrichten synchronisieren, ist konzeptionelle Parallelität im Sinne von Koroutinen einfach zu implementieren. Wieder liegt hier die Betonung auf der Erleichterung der Modellbeschreibung. Modelle eines Realsystems bestehen aus koexistierenden Objekten mit individuellen, sich konzeptionell gleichzeitig entfaltenden Lebenszyklen. Systemimplementierungssprachen (zum Beispiel Ada, Modula, ...) benötigen hingegen Kontrollstrukturen zur zuverlässigen Koordination real-paralleler Prozesse.

Dies wird im objektorientierten Paradigma nicht berücksichtigt. Nach Versenden einer Nachricht warten Objekte auf Antwort. Wollte man die an sich vielversprechenden Modularisierungseigenschaften zur Implementierung von Realzeitparallelität nutzen, müßte man neue Konzepte der Prozeßkoordination einführen und Unterbrechungsmechanismen implementieren. Das ist bisher nur ansatzweise bei einigen experimentellen KI-Sprachen (NETL; ETHER, . . .) erfolgt.

Der Hauptnachteil objektorientierter Softwarearchitekturen liegt sicherlich in ihren hohen Anforderungen an Speicherausbau und Prozessorleistung. Es müssen eine Vielzahl transienter Objekte verwaltet und lange Ketten indirekter Referenzen verarbeitet werden. Dieses im Vergleich zu "klassischen" Systemen ineffiziente Laufzeitverhalten verliert aber durch den Preisverfall von Speichermodulen und Prozessorleistung zunehmend an Bedeutung.

Eine mögliche Lösung des Effizienzproblems liegt auch in der Entwicklung speziell auf spezifische Anforderungen dieses Programmierstils zugeschnittener Rechnerarchitekturen. Zwei Ansätze dieser Art (Suzuki, Japan, und Ungar, Berkeley) sind speziell für Smalltalk auch bereits bekanntgeworden. Experimentelle Entwicklungen existieren ebenfalls in der KI (ZMOB, Apiary, . . .). Erfolge sollten hier mit weniger Aufwand erzielbar sein als beispielsweise bei der Logikprogrammierung (Prolog).

Aus all den geschilderten Gründen wird der objektorientierte Programmierstil für die Entwicklung komplexer Softwaresysteme in Zukunft

wahrscheinlich stark an Bedeutung gewinnen. Er kann durchaus zu einem neuen Schlagwort, ähnlich dem der "strukturierten Programmierung" werden. Die aus Smalltalk stammende Idee einer graphisch interaktiven, mit Maus, Menüs und Fenstertechnik ausgestatteten Programmierumgebung hat sich auf anspruchsvollen Arbeitsplatzrechnern (Sun, Lisp-Maschinen, ...) bereits fest etabliert. Durch Apples Lisa und Macintosh initiiert, wird sie sich auch bei den Mikrocomputern durchsetzen. Grundsätzlich sehr gut geeignet ist die objektorientierte Programmierung für Modellierungsprobleme und zur Unterstützung komplexer Programmieraufgaben im Bereich der künstlichen Intelligenz. Eine Reihe von Werkzeuge für die Entwicklung sogenannter wissensbasierter Systeme (Expertensysteme)

nutzen, neben prozeduralen, logik- und regelorientierten Programmierstilen, die objektorientierte Sichtweise als dominierende Strukturierungsidee. Hier wären beispielsweise Loops (Xerox), KEE (IntelliCorp) und Babylon (GMD) zu nennen.

Auch als Systemimplementierungssprache haben sich objektorientierte Prozessoren als sehr tragfähig erwiesen. So sind die äußerst komfortabel ausgestalteten Programmierumgebungen der sogenannten Lisp-Maschinen alle unter Verwendung dieses Ansatzes (zum Beispiel Flavors bei Symbolics) implementiert. Auch das gesamte Smalltalk-System, einschließlich aller Werkzeuge (Browser, Editor, Viewer, Tracer, Compiler, . . .), den Grafikprozessoren und der Benutzerschnittstelle (Menüs, Fenster, . . .) ist vollständig objektorientiert und in Smalltalk selbst programmiert. Wie bereits erwähnt, hat Apple einer Untermenge von Smalltalks Programmierumgebung auf seine Rechner Lisa und Macintosh übertragen.

Es existiert auch intern eine Smalltalk-Implementierung, die aber zur Zeit für Kunden nicht verfügbar ist. Man war bei Apple wie auch in anderen Kreisen ursprünglich der Ansicht daß Smalltalks Benutzerschnittstelle und der objektorientierte Programmierstil separabel und voneinander weitgehend unabhängig seien. Die Software wurde daher in Assembler und Pascal geschrieben.

Auch für die Entwicklung von Anwendungspaketen für den Macintosh wurden im Rahmen einer "Toolbox" eine Vielzahl von Pascal-Dienst-programmen zur Verfügung gestellt. Inzwischen scheint sich aber aufgrund der hierbei gewonnenen Erfahrungen die Ansicht durchgesetzt zu haben, daß die Idee der objektorientierten Programmierung und die erfolgreiche Implementierung eines so komplexen, aber hervorragend strukturierten Softwaregebirges, wie es eine moderne Benutzerschnittstelle mit eingebetteten Programmierwerkzeugen á la Smalltalk darstellt, doch nicht völlig voneinander getrennt werden sollten.

Die objektorientierte Sicht der Programmmierung durch modular und differenzierend voranschreitende Modellierung von Realitätsausschnitten bietet eine hervorragend strukturierende und zuverlässige Vorgehensweise, die in ihrer Eignung für die Beschreibung komplexer Systeme von klassischen Sprachen wie Fortran, Cobol, C, Pascal oder PL/ 1 nicht erreicht werden kann.

Durch Einsatz der von neueren Sprachen wie Ada oder Modula angebotenen Datenverkapselungskonzepte können allerdings viele, wenn auch nicht alle Vorteile (nicht beispielsweise differenzierende Beschreibung, . . .) objektorientierter Programmierung genutzt werden. Neue Softwareentwicklungen werden daher bei Apple jetzt in Clascal geschrieben - einem Sprachdialekt der Pascal, um Ideen der objektorientierten Programmierung (Klassen, Nachrichten, . . .) erweitert.

Zur Zeit existiert neben Smalltalk, Clascal und den erwähnten Lisp-Derivaten nur noch eine objektorientierte Variante der Sprache C. Sie ist durch einen Vorübersetzer realisiert und wird kommerziell angeboten. Man kann bei genügender Selbstdisziplin allerdings auch in Simula objektorientiert programmieren.

Am umfangreicheren Anwendungen sind neben den bereits angeführten Aktivitäten im Bereich der KI und der Systemprogrammierung bisher hauptsächlich einige

experimentelle Systeme bekanntgeworden; beispielsweise an der Stanford University (ThingLab) und Xerox Parc (PIE).

Das liegt sicher zum einen an des bisher recht mangelhaften Verfügbarkeit der notwendigen Software und Hardware, andererseits aber wohl auch an mangelnder Publizität außerhalb des engeren Bereichs der Informatik. Parallelen sind hier vielleicht mit dem doch recht esoterischen Image des Unix-Systems bis in die späten siebziger Jahre zu sehen Es ist stark anzunehmen, daß sich dies bereits in naher Zukunft ändern wird.

So werden in einigen Ländern bereits jährliche Workshops zu Methoden der objektorientierten Programmierung veranstaltet. In diesem Jahr wird auch in Deutschland erstmals ein Fachgespräch und eine Einführung in innovative Programmierumgebungen mit Schwerpunkt auf Smalltalk stattfinden (im Mai an der TH Darmstadt).

Einen weiteren interessanten Indikator bietet das "Quality in Engineering" Projekt des norwegischen SI Instituts in Oslo. Dort wird in Zusammenarbeit mit einigen führenden norwegischen Forschungsinstituten und Industrieunternehmen ein umfangreiches Softwaresystem zur Unterstützung ingenieurtechnischer Entwurfsprozesse und aller hierbei anfallender Dienstfunktionen (Kommunikation, Konferenzen, Dokumentverarbeitung, Projektmanagement, ...) auf Arbeitsplatzrechnern entwickelt. Das Projekt wurde vor einem Jahr unter Einsatz von Apples Lisa begonnen.

Eine Pilotversion reduzierten Umfangs wurde im Januar diesen Jahres zu Testzwecken freigegeben. Obwohl noch keine Entscheidung darüber gefallen ist, auf welchen Arbeitsplatzrechnern die Software letztlich eingesetzt werden soll, ist das Institut doch von den Vorteilen der objektorientierten Sichtweise bei Entwurf und Implementierung komplexer Softwaresysteme so überzeugt, daß es sich für Smalltalk als Implementierungssprache (auf Tektronix 4044) entschieden hat.

Auch wenn die Programme später in eine konventionelle Sprache (wie "C") re-implementiert werden müssen - die hierdurch erzielbaren Vorteile bei Spezifikation, rascher und zuverlässiger Erstellung leicht modifizierbarer Prototypen, mit denen dann experimentiert werden kann, wiegen den zusätzlichen Ubertragungsaufwand bei weitem auf.

*Dr. Wolfgang Kreutzer lehrt Simulations- und Kl-Programmierung am Computer Sience Department der University of Canterbury Christchurch, Neuseeland, und leitet eine Forschungsgruppe zur Smalitalk-lmplementierung .