Gehören Sie etwa auch zu den fortschrittlichen und mutigen Anwendern, die trotz Einsatz einer relationalen Datenbank und Verwendung der passenden Sprache der 4. Generation weder Kosten gespart, noch Vorteile für Ihr Unternehmen erzielt haben? Oder sind Sie ein eher konservativer Entscheider, der heute kaum noch die Pflege seiner Standardsoftware bezahlen kann, die zudem niemals richtig zu seinem Unternehmen passte? Wo liegen also bei richtiger Anwendung der OO-Techniken die entscheidenden Vorteile?

Durch den Einsatz von Programmiersprachen, die objektorientierte Vorgehensweisen unterstützen, ergeben sich zunächst für die Produktion von Software neue Strategien. Objekte bestimmen die Struktur von Programmen. Diese Objekte beinhalten Daten und Anweisungen, d.h. jedes Objekt weiß selbst, mit welchen Programmzeilen seine Daten manipuliert werden können. Die Schnittstelle zu anderen Objekten bilden immer Zugriffsmethoden, die den anderen Objekten zur Verfügung gestellt werden. Gleichartige Objekte werden zu Klassen zusammengefasst, so dass Zugriffsmethoden im besten Fall nur einmal definiert werden müssen.

Nehmen wir hierzu ein Beispiel. Eine Klasse "Datumsberechnung" verwaltet alle Möglichkeiten der Datumsberechnung an einer einzigen Stelle im System. Sie kennt alle realen Möglichkeiten, ein Datum zu manipulieren. Als Schnittstelle zu anderen Objekten legt es zum Beispiel die Methoden "Umrechnung in Kalenderwoche", "Anzeige Wochentag", "Anzeige Datum in Form DD/MM/JJ" oder "Addiere Anzahl Tage" frei. Ist nun ein System in dieser Weise ordentlich strukturiert, so ergeben sich im Hinblick auf Wartung und notwendige Erweiterungen erhebliche Vorteile. Ein Wechsel des Jahrtausends hat nur Änderungen innerhalb dieser einen Klasse zur Folge. Lediglich Änderungen an der Schnittstelle müssen überprüft und getestet werden. In obigem Beispiel müsste nicht einmal eine Methode der Schnittstelle überprüft werden außer einer eventuell neu entwickelten Methode "Anzeige Datum in Form DD/MM/JJJJ". Das Jahr 2000 würde mit objektorientierter Vorgehensweise keine programmier-technischen Probleme aufwerfen. Die Vorteile der neuen Programmstruktur ergeben damit auch entscheidende Vorteile für Endkunden.

Ist eine Klasse über einen Zeitraum gewachsen und beinhaltet alle Funktionen, die für den Bereich relevant sind, kann diese Klasse in ähnlichen Projekten leicht wieder verwendet werden. Über Bibliotheken mit wiederverwendbaren Klassen erzielen Softwarehäuser Produktivitätssteigerungen bei gleichzeitiger Kostenersparnis. Selbst wenn diese Kosten keine Auswirkungen auf die Preisgestaltung haben sollten, so dürfen Anwender doch in Zukunft perfekt ausgetestete Funktionen erwarten. Sog. "Bananensoftware" (d.h. Software, die erst beim Kunden ausreift) bei Grundbausteinen sollte bald der Vergangenheit angehören.

Was aber, wenn ein solcher Grundbaustein nicht zu 100 Prozent die Anforderungen eines Unternehmens abbildet? Hier greifen zwei weitere Grundmechanismen der objektorientierten Sprachen: die Möglichkeit der Zusammenfassung von Klassen zu hierarchischen Strukturen, d.h. die Bildung von allgemein-gültigen Oberklassen und speziellen Unterklassen sowie die Vererbung von Daten und Methoden über diese Hierarchien hinweg.

Ein Beispiel soll dies verdeutlichen. Es besteht bereits ein Basisbaustein, der Artikel verwaltet. Die zugehörige Struktur könnte wie folgt aussehen:

Artikel

Attribute:

Artikelnummer

Bezeichnung

Grundpreis

Methoden:

Verwalten

Anzeigen

Löschen

• zu allen Artikeln ist die englische Bezeichnug zu verwalten.
• zu Sonderartikeln, die projektbezogen produziert werden, ist das Projekt zu verwalten.
• bei Handelsware ist der Lieferant anzugeben und der Einkaufspreis zuzuordnen.

Oberklasse: Artikel

Attribute:

Artikelnummer

Bezeichnung

Bezeichnung

Englische Bezeichnung

Grundpreis

Methoden:

Verwalten

Anzeigen

Löschen

Unterklasse: Sonderartikel

Methoden:

Zu Projekt zuordnen

Unterklasse: Handelsware

Attribute:

Einkaufspreis

Methoden:

Zu Lieferanten zuordnen

Durch die Änderungsfreundlichkeit der Objektmodelle lassen sich aber auch Grenzen der Standardsoftware für Kunden aufbrechen. Früher waren Softwareproduzenten gezwungen, ein Geflecht von Software zu pflegen und zu warten. Diese Software konnte ein versierter Systembetreuer über unzählige Parameter auf Kundenbedürfnisse mit hohem Aufwand weitestgehend anpassen. Heute ist es einfacher, die vorgefertigte Software in einer Art Endmontage den Kundenbedürfnissen anzugleichen. Maßanzug statt Konfektion von der Stange mit den Vorteilen beider Verfahren bietet ungeahnte Möglichkeiten für den Anwender. Die jährlichen Updates beziehen sich in Zukunft nur noch auf für den Endkunden relevante Gebiete. Bei allgemeinen Änderungen, z.B. bedingt durch die Einführung des Euro, werden auch in Zukunft bei allen Anwendern die relevanten Klassen ausgetauscht, individuelle Erweiterungen bleiben individuell. Dies erspart in der objektorientierten Welt allen Beteiligten Aufwendungen und Kosten.

Die Strukturierung in Objekte mit wohldefinierten Schnittstellen stellt ebenfalls eine neue Möglichkeit dar, Software von unterschiedlichen Herstellern miteinander zu verbinden. Verschiedene Gremien der Softwareindustrie sind gerade dabei, Standards zu definieren, die, wie heute bereits bei Hardware üblich, die Kombination von Softwarebauteilen verschiedener Produzenten ermöglichen. Die Vorteile dieser Vorgehensweise liegen klar auf der Hand. In Zukunft müssen Käufer nicht mehr ihre gesamte Software von einem einzelnen Anbieter beziehen, der zwar durchaus Stärken auf einem Gebiet, dagegen aber auch Schwächen auf einem anderen aufweist. Jetzt kann die Buchhaltung vom Finanzbuchhaltungsexperten mit einem PPS-Paket des Produktionsspezialisten in Kombination mit Software des Inventurspezialisten eingesetzt werden. Die Erstellung und der Test aufwendiger und teuerer Schnittstellen entfällt. Schließlich kaufen Sie als Anwender heute auch einen PC und kombinieren diesen mit dem Equipment, das Ihre spezielle Anwendung erfordert: mit der für Ihre Zwecke passenden Grafikkarte und dem zur Grafikkarte und PC optimalen Bildschirm. Standards bei Steckern und Bussystem haben dies möglich gemacht. Das gleiche sollte bei Software heute auch möglich sein.

Kapselung, Vererbung und Wiederverwendung stellen technische Vorteile bei der Produktion von Software dar. Die gesamte Kette der Softwareproduktion umfasst aber den Bereich der Aufnahme der Kundenwünsche bis hin zur Realisierung und Abnahme. Kann hier die neue Sichtweise ebenfalls unterstützen ? Vermutlich ist Ihnen der bisherige Prozess bestens bekannt. Das liefernde Softwarehaus erstellt in Zusammenarbeit mit Ihrer DV-Fachabteilung ein Pflichtenheft. Aufgrund des Pflichtenhefts entsteht anschließend ein weiteres Papier (eventuell mit Hilfe eines Case-Tools), in dem die ursprünglich einfachen Anforderungen in Tabellen zersplittert dokumentiert sind. Im nächsten Arbeitsgang entsteht eine dem Anwender meist verborgene Programmiervorlage, die dann, mühevoll in kryptische Zeichen überführt, die ursprünglich einfache Anforderung abdecken soll.

Zwischen jedem notwendigen Schritt entstand bisher wegen technischer Restriktionen in der eigentlichen Programmierung ein Bruch der Sichtweise, der eine mehr oder minder große Informationsverfälschung oder sogar Informationsverlust zur Folge hatte. OOA (Objektorientierte Analyse), OOD (Objektorientiertes Design) und OOP (Objektorientierte Programmierung) stellen auch hier zukunftssichere und durchgängige Verfahren dar. Im besten Fall finden sich Objekte der Analysephase im Klartext auch bei der Programmierung wieder. Wie sollte der Entwickler da etwas vergessen? In den oben genannten Beispielen könnten sich im Quellcode als Beispiele tatsächlich die Methoden "addiereAnzahlTage" oder "zuProjektzuordnen" finden. Grammatikalische Probleme außen vorgelassen ein dramatischer Fortschritt.

Vorteile bei der Programmierung, Vorteile beim gesamten Produktionsprozess der Software - es bleibt die Frage, in wieweit Objekte und reale Welt, insbesondere Objekte und Veränderungen betriebswirtschaftlicher Anforderungen kongruieren? Bei Produktionsplanungs- und Steuerungssystemen besteht seit längerem die Forderung, dass systemrelevante Größen unabhängig vom Eingreifen des Anwenders zeitnah miteinander kommunizieren sollten.

Die Welt ist schneller und der Wettbewerb härter geworden. Nicht der Anwender sollte es sein, der nach stundenlangen Batchläufen aufgrund veralteter Zahlen Entscheidungen trifft, sondern die betroffenen Größen selbst (z.B. ein Artikel) melden ihren Bedarf beim Disponenten. Eine defekte Maschine reagiert selbständig und zeigt ihren Produktionsausfall an, ohne dass die Arbeitsvorbereitung mühsam die Fehlmenge ermitteln muss.... PPS-Größen sollten also in der Lage sein, auf Ereignisse zu reagieren und Nachrichten an andere PPS-Größen, aber auch den Anwender, zu senden. Selbstreagierende PPS-Einflußgrößen könnten etwa Artikel, Stücklisten, Arbeitsmittel und Material sein. Anforderungen und Funktionen legen den Schluss nahe, dass es sich hier um Objekte mit Methoden als Schnittstelle handelt. Die Technik bildet die Anforderungen der realen Welt im Maßstab 1:1 ab.

Intranet, Internet, Extranet und Outernet - allesamt Begriffe, die im Zuge der rasanten Entwicklung der weltweiten Vernetzung geboren wurden. Wie steht es mit technischen Veränderungen, auf die Sie reagieren müssen, und der neuen OO-Technik bei der Softwareerstellung? Netze sind verteilte Welten, in denen Informationen ausgetauscht und Dienste bereitgestellt werden müssen. Insbesondere hier hat man schon früh die Vorteile von Objekten als optimale Basisarchitektur für vernetzte Systeme erkannt. Die OMG zum Beispiel (Object Management Group) hat bereits 1992 mit CORBA eine Standardarchitektur definiert, die mit CORBA 2.0 (Common Object Request Broker Architecture) erstmals die Interoperabilität von Objekten auch unterschiedlicher Hersteller ermöglicht. Auf veränderte technische Rahmenbedingungen reagiert die objektorientierte Sicht bzw. die objektorientierte Technologie genauso flexibel wie auf betriebswirtschaftliche Änderungen. Beide Aspekte bedeuten Sicherung der Investitionen für die Zukunft.

Wohl erstmalig in der kurzen Geschichte der Softwareproduktion herrscht Einigkeit über die neue Sichtweise auf die in der Software abzubildenden Inhalte und deren technische Realisierung. Ob Smalltalk, Java, syntaktisch der Programmiersprache C sehr ähnlich, oder COBOL mit verschiedenen objektorientierten COBOL-Compilern - sie alle setzen die neue Technik mehr oder weniger geschickt um. Es gibt größere Forschungsprojekte namhafter Institutionen, die mit Hilfe der neuen Technik versuchen, das Know-how der über Jahre historisch gewachsenen COBOL-Programme durch Transformation zu retten. In Java wird versucht, Schwächen der C++-Variante gegenüber Smalltalk-Derivaten auszugleichen. Smalltalk selbst gilt als die reinste Umsetzung der neuen Sicht und hat den Vorteil, dass hier offensichtlich die besten Werkzeuge und Hilfsmittel für die Realisierung vorhanden sind. Bei derartiger Einigkeit am Softwaremarkt kann man wohl nicht von einem kurzen Trend sprechen.