Selbst die IBM kann sich dem Trend zur objektorientierten Programmierung (OOP) nicht mehr entziehen. Dabei haben sich die Armonker nicht für das boomende C + + -Produkt entschieden, sondern für die Sprache, die für die reine OOP-Lehre steht: für Smalltalk.
Smalltalk entstand in den siebziger Jahren in den Xerox-Parc-Labors mit der Zielsetzung, ein Programmiersystem zu entwickeln, das die reale Welt so natürlich abbildet, daß sogar Kinder damit umgehen können. Außerdem sollte damit die Vision eines kleinen, portablen, persönlichen und bedienerfreundlichen Computers realisierbar werden. Dafür wurden die objektorientierten Konzepte von Simula mit einer grafischen Benutzeroberfläche zusammengeführt, Smalltalk enstand. Die heutigen Versionen von Smalltalk lehnen sich an den letzten Stand der Xerox-Entwicklung an, die unter der Bezeichnung Smalltalk-80 als Standard gilt.
Smalltalk: Keine Typen und Funktionen
Doch Xerox konnte von seiner Entwicklung nicht profitieren. Andere, die das Unternehmen besuchten, machten mehr daraus. Zu ihnen gehört Apple-Mitbegründer Steven Jobs mit seinem Mac-Rechner und Jim Anderson, Mitgründer von Digitalk.
Smalltalk ist nicht nur ein OOP-System nach der reinen Lehre, sondern eine komplette, grafische Programmierumgebung (OO-Programming System = OOPS). Es gibt keine Typen und Funktionen mehr, sondern Objekte, die Daten und Funktionen enthalten und denen man eine Nachricht schicken kann. Die Art, wie diese Daten dort gespeichert und verarbeitet werden, nennt man "verkapselt". Damit ist gemeint, daß ein Objekt mit seinen Eigenschaften, sprich: Daten, in sich abgeschlossen ist.
Änderungen in der internen Repräsentation sollten keine Auswirkungen auf die Benutzung des Objekts haben. Zu den Regeln gehört auch, daß Objekte das Verhalten anderer erben können. Beim Erstellen eines neuen Objektes können so vorhandene Eigenschaften übernommen werden. Dies spart Zeit und Geld.
Die OOPS-Befürworter kritisieren den zähen Ablauf der klassischen Programmentwicklung. Selbst bei kleinen Änderungen muß dort das gesamte Programm neu kompiliert werden. Findet sich ein Fehler, geht das Ganze von vorne los. Ihnen ist das weder intuitiv noch schnell genug. Also konzipierten die Entwickler Smalltalk zu einem inkrementellen Compiler, der nur die geänderten Statements kompiliert.
Doch diese Features gingen auf Kosten des Laufzeitverhaltens. Smalltalk wurde langsam, es benötigte Grafikfähigkeit und hohe Prozessorleistung. Heute sind solche Anforderungen selbstverständlich und die Prozessoren entsprechend leistungsfähig.
Der Umgang mit objektorientierten Programmierumgebungen erfordert neue Denkansätze. Der klassische Software-Entwickler muß lernen, wie ein Computer zu denken. Ein Problem wird generalistisch angegangen und in immer kleinere Teile zerlegt, bis man auf einer Ebene ist, die der Computer Schritt für Schritt abarbeiten kann. Das Ganze heißt strukturierte Analyse und Design.
Ist der Entwickler dann beim Codieren angekommen, sucht er sich noch eine Programmiersprache aus, die dieses Umsetzen in eine vom Computer verstandene Sprache ermöglicht. Alle Sprachen, die hier in Frage kommen, von Assembler über Cobol zu C, haben gemein, daß sie dem Computer die Probleme häppchenweise darbieten.
Regelmäßig kommt es zu großen Schwierigkeiten, wenn sich nach der aufwendigen Analyse die Aufgabenstellung verändert, was praktisch bei jedem Projekt geschieht. Entweder der Programmierer fängt von vorne an, oder man ignoriert das Problem. Das ist der Grund, warum so viele Projekte nach Fertigstellung nicht zum Einsatz kommen.
Diese Tatsache war den Entwicklern von Smalltalk bewußt. Sie versuchten, eine Programmiersprache zu entwickeln, die die Probleme so erfaßt, wie sie in der wirklichen Welt vorkommen. Die Analyse verliert auf diese Art und Weise viel von ihrer Abstraktheit. Sie ähnelt eher dem Niederschreiben und Sortieren eines Abbildes der realen Welt.
Hat der Entwickler ein Gefühl für das gestellte Problem entwickelt, beginnt er, einen Prototypen herzustellen. Diesen präsentiert er den Anwendern, fragt ob alles in Ordnung ist und geht mit den neuen Anregungen wieder in den Analyse-Design-Prototyping-Prozeß solange bis der Anwender zufrieden ist. Auf diese Weise wird der Prototyp zum Produkt.
Aus dieser Vorgehensweise ergibt sich die sogenannte Paradigma-Krise: Die Software-Entwickler sollen nun plötzlich nicht mehr wie ein Computer denken, sondern wie ein Mensch. Das fällt vor allem den Profis schwer. Experten formulieren ihre Analyse in der Terminologie von Datenbanken, Bits und Bytes. Laien dagegen reden - wie echte OOP-Spezialisten - von Arbeitsabläufen, Rechnungen, Mülleimern und Schreibtischen (Desktops). Die große Aufgabe besteht also darin, wieder denken zu lernen wie ein Mensch.
Es geht bei der Objektorientierung weniger darum, eine neue Programmiersprache zu erlernen, als um eine neue (eigentlich alte) Art zu denken und ein Problem zu analysieren. Hier reicht Schulung allein nicht aus. Jeder Interessierte sollte daher soviel über das Thema lesen, wie er kann (vergleiche Literaturliste).
Es wird in Zukunft keine Analysegruppen, Chefdesigner und Anwendungsentwickler mehr geben. Durch die enge Verbingung von Analyse, Design, Programmierung und Test in objektorientierten Umgebungen lassen sich diese Aufgabenbereiche personell kaum trennen. Es entstehen neue Berufsfelder, etwa das des Objektwarts, der die firmeneigene Klassenbibliothek pflegen und Implementierungen auf ihre Wiederbenutzbarkeit prüft, und des Portierungs-Experten, der auf Betriebssystem-Unabhängigkeit achtet.
Auch wird der Anwender stärker eingebunden. Er hilft bei der Analyse und beurteilt die Prototypen. Es wird keine großen Endabnahme-Tests mehr geben, da die Entwicklung von ständigen Tests begleitet ist. Auf diese Weise sieht der Kunde frühzeitig, was er bekommt er sitzt mit im Boot. Aber auch die Vorgesetzten des Programmierers sind ständig über den Projektfortschritt informiert.
Diesen Vorteilen steht allerdings ein Nachteil gegenüber: Eine Aufwandschätzung wird praktisch unmöglich. Nach den bisherigen Verfahren mußte nach der Analysephase und dem Design festgelegt werden, wieviel Aufwand zu erwarten ist.
Die Erkenntnis, daß selbst die beste Analyse nicht vollständig sein kann, besonders wenn sich zwischenzeitlich das Problem ändert, hatte bisher keinen Einfluß auf die Schätzwerte. Die verzweifelten Versuche, metrische Verfahren in die Software-Entwicklung einzuführen, können getrost als gescheitert bezeichnet werden.
In der Folge rangierten daher Aufwandsabschätzungen meist hinter "Sachzwängen". Das hörte sich etwa so an: "Das Projekt muß bis gestern fertig sein, mehr Leute bekommt ihr nicht, und wehe, der Termin wird nicht gehalten - noch Fragen?".
Blickt man zurück, wird man feststellen, daß der beste Maßstab für die Aufwandsschätzung die Erfahrung der beteiligten Entwickler und Designer ist. Dem wird die OOP-Methode gerecht. Hat ein Entwickler ein paar Projekte realisiert, weiß er, wo der meiste Aufwand zu er. warten ist - in der Regel bei Analyse und Design. Eine Faustregel für Vorgesetzte, die mit i Zahlen argumentieren wollen: Wenn Sie ein erfahrenes Team haben, fragen Sie es, nachdem es sich ein paar Tage mit dem Problem beschäftigt hat, verdoppeln Sie die Angaben, und schon haben Sie eine realistische Schätzung für ein Abgabedatum.