Von Werner Achtert*

Die Vorteile der Objektorientierung werden mittlerweile von den meisten Entwicklern und auch Anwendern erkannt. Die praktische Umsetzung macht jedoch nicht selten Probleme, da die Einfuehrung der neuen Technik den gesamten Entwicklungsprozess beeinflusst. Vor allem die Integration objektorientierter und klassischer Systeme erfordert eine detaillierte Umstellungsstrategie.

Die Anforderungen an DV-Systeme sind in der Vergangenheit stetig gestiegen, wobei auch die Leistungsfaehigkeit der technischen Komponenten staendig zugenommen hat. Diese Entwicklung wird sich in absehbarer Zeit fortsetzen, denn der Trend geht zu immer komplexeren Aufgaben, deren Bearbeitung zunehmend in Client- Server-Systemen verteilt wird.

Die Objektorientierung ist eine Technik zur Entwicklung von Software, die diesen Anforderungen besser gerecht wird als die klassischen Verfahren. Dies ist inzwischen auch in vielen Unternehmen anerkannt. Bei einer kompletten Neuentwicklung eines Systems auf der vielzitierten gruenen Wiese stellt sich die Situation relativ einfach dar, da vom ersten Moment an mit den entsprechenden Techniken gearbeitet werden kann. Will ein Unternehmen mit schon existierenden Systemen auf Objektorientierung umsteigen, so muessen neben den reinen Neuentwicklungen auch die aelteren Verfahren beruecksichtigt werden. Ein kompletter Umstieg aller Softwaresysteme eines Unternehmens zum selben Zeitpunkt waere zwar ideal, scheitert jedoch an mehreren Faktoren:

- Eine umfassende Neuentwicklung aller Systeme wuerde in der Regel laufende Entwicklungsarbeiten erheblich beeintraechtigen. In den meisten Unternehmen sind erhebliche Kapazitaeten mit der Pflege bestehender Anwendungen gebunden.

- Investitionen in bisher entwickelte Systeme wuerden auf einen Schlag erheblich an Wert verlieren.

- Die Kosten eines solchen Umstiegs uebersteigen in vielen Faellen die kurzfristig verfuegbaren Mittel.

Aus diesen Gruenden benoetigen Unternehmen ein Konzept fuer den schrittweisen Umstieg ueber einen laengeren Zeitraum hinweg. Ziel einer derartigen Umstellung auf objektorientierte Entwicklung ist die Einfuehrung einer einheitlichen Vorgehensweise bei der Entwicklung von Software in allen Unternehmensbereichen. Die Objektorientierung ist dabei nicht nur eine Programmiertechnik, sondern eine allgemeine Abstraktionsmethode, um Modelle von betrieblichen Strukturen und Ablaeufen zu bilden. Sie eignet sich auch zur Modellierung im Rahmen einer Geschaeftsprozessanalyse.

Zunaechst muss ein Klassenmodell des Aufgabengebiets unabhaengig von einer konkreten Umgebung zur Realisierung erstellt werden. Idealerweise wird dazu ein Modell des Gesamtunternehmens gebildet.

Der zweite Schritt ist die Umsetzung dieses Modells in ein objektorientiertes Design. Dazu gehoert neben der Definition der Klassenstrukturen die Festlegung der Architektur der einzelnen Anwendungen. Fuer jede Klasse muessen die von aussen zugaenglichen Bestandteile definiert werden. Dieses Design kann schliesslich mit geeigneten Programmiersprachen in konkrete Programme umgesetzt werden.

Die so realisierten Anwendungen werden getestet und implementiert. Auf diese Weise entsteht ein System von DV-Applikationen, die direkt aus dem Unternehmensmodell abgeleitet sind. Das objektorientierte System laesst sich besser warten und auch erweitern als bei ablauforientierter Struktur, da Aenderungen in Klassen stattfinden. Die Wirkungszusammenhaenge sind besser erkennbar, da alle zusammengehoerigen Methoden und Daten innnerhalb einer Klasse definiert sind. Bei einer Modifikation wird zunaechst das Unternehmensmodell angepasst, darauf aufbauend Analyse und Design und schliesslich die realisierten Programme.

Auf diese Weise entwickelte Verfahren lassen sich auch langfristig an Veraenderungen anpassen, durch die objektorientierte Modellierung ist auch ein spaeterer Umstieg auf andere Sprachen und Architekturen moeglich. Vor allem Standardarchitekturen wie Corba (Common Object Request Broker Architecture) werden dazu beitragen, dass objektorientierte Systeme zunehmend offener werden fuer spaetere Erweiterungen und Schnittstellen zu anderen Systemen.

Der Uebergang von der ablauforientierten zur objektorientierten Entwicklung ist ein schwieriger Umstieg einer kompletten Entwicklungstechnik, es tritt dabei eine Reihe praktischer Probleme auf. Das Vorgehen bei der Strukturierung einer Aufgabe muss vollkommen veraendert werden, neue Methoden und Tools werden benoetigt. Objektorientierte Strukturen koennen nur mit geeigneten Sprachen abgebildet werden, mit denen sich die Programmierer erst vertraut machen muessen. Objektorientierung wird in vielen Unternehmen nicht als einzige Neuerung eingefuehrt, sondern oft im Zusammenhang mit anderen neuen Techniken wie Client-Server- Strukturen und grafischen Oberflaechen. Die gleichzeitige Einfuehrung mehrerer neuer Techniken schafft zusaetzliche Probleme.

Daher ist es sinnvoll, diesen Uebergang in einzelne Phasen zu zerlegen, deren Durchfuehrung zeitlich an die Erfordernisse eines Unternehmens angepasst werden kann. Das folgende Phasenkonzept beruht auf der Ueberlegung, dass ein Umstieg auf eine neue Technik nur von einer stabilen Plattform aus gelingen kann. Daher werden in den ersten Phasen zunaechst bestehende Systemteile erfasst und gegeneinander abgegrenzt. Dadurch wird es moeglich, einzelne Verfahren in einem Unternehmen auf Objektorientierung umzustellen, waehrend andere Systemteile mit ihren klassischen Strukturen erhalten bleiben.

Phase 1: Erfassen der Ausgangslage

In der ersten Phase wird ein Ueberblick zu den aktuell benutzten DV-Verfahren erstellt. Zu erfassen und registrieren sind die bisher verwendeten Verfahren, Modelle, Analysen, Methoden, Programmiersprachen, Datenbanken und die technische Umgebung.

Die Bestandsaufnahme der gesamten DV-Landschaft eines Unternehmens ist noetig, um einen Ueberblick darueber zu gewinnen, welche bisherigen Vorgehensweisen auf Objektorientierung umgestellt werden muessen.

Phase 2: Konsolidierung der bestehenden Situation

In der zweiten Phase sollte als Voraussetzung fuer den Umstieg auf Objektorientierung das bestehende DV-System konsolidiert und vereinheitlicht werden. Die Umstellung auf objektorientierte Techniken faellt leichter auf der Basis einer stabilen Plattform. Wuenschenswert ist also ein objektorientiertes Modell des gesamten Unternehmens, was jedoch aus praktischen Gruenden nicht immer erreichbar ist. Ein moeglicher Kompromiss ist die Bildung eines sehr oberflaechlichen Klassenmodells fuer das Gesamtunternehmen. Detaillierte Modelle werden nur fuer die Teile entwickelt, die im ersten Schritt auf Objektorientierung umgestellt werden sollen.

Dieser Schritt schafft die Voraussetzung fuer die Untergliederung der gesamten Verfahrenslandschaft in Teilsysteme, in denen der Wechsel der Reihe nach vollzogen wird. Sollen ablauf- und objektorientierte Verfahren gleichzeitig in einem Unternehmen eingesetzt werden, so muessen sie ueber Schnittstellen Daten austauschen. In den meisten Faellen bietet sich dazu eine gemeinsame Datenbasis auf der Grundlage schon benutzter Dateisysteme oder Datenbanken an. Dadurch koennen die Altverfahren weitgehend unveraendert bleiben, die Objekte der objektorientierten Verfahren werden auf die vorhandenen Datenstrukturen abgebildet. Bei genauer Definition dieser Schnittstellen ist damit die getrennte Migration einzelner Verfahren moeglich.

Phase 3: Planung der Zielumgebung

In der dritten Phase muessen einige grundlegende Entscheidungen ueber Methoden, Sprachen und Tools fallen. Durch die Struktur der bereits vorhandenen Verfahren kann der Gestaltungsspielraum an dieser Stelle erheblich eingeschraenkt sein. Festzulegen sind die Architektur (Grossrechner, Unix, Client-Server, PC), eine Methode fuer objektorientierte Analyse und Design, die Tools fuer objektorientierte Analyse und Design, das Vorgehensmodell sowie die Programmiersprachen und Compiler.

Phase 4: Planung der Umstellung

Im vierten Schritt ist die Umstellung der zuvor definierten Teilverfahren detailliert zu planen. Dabei muss entschieden werden, welche Teilverfahren in welcher Reihenfolge umgestellt werden und welche unveraendert beibehalten werden sollen. Bei der Terminplanung sind Zeiten fuer die Einarbeitung des Personals in die gewandelte DV zu beruecksichtigen.

Phase 5: Beschaffung

Im fuenften Abschnitt geht es bereits um die materiellen Voraussetzungen des Umstiegs: Hard- und Software muessen eventuell erworben, auf jeden Fall aber organisiert werden. Dazu kommt die Schulung des Personals in internen oder externen Seminaren. Unter Umstaenden bietet sich der Einkauf von Beratungsleistung durch externe Spezialisten an.

Phase 6: Realisierung

Phase sechs dient der konkreten Umsetzung. Jedes Teilverfahren kann nun auf der Grundlage der konsolidierten Anforderungen auf objektorientierte Techniken umgestellt werden. Analyse, Design und Programmierung erfolgen objektorientiert, die Ergebnisse werden ueber die definierten Schnittstellen in das Gesamtsystem integriert. Der schrittweise Umstieg Teilverfahren nach Teilverfahren kann sich durchaus auch ueber einen laengeren Zeitraum erstrecken.

Das vorgestellte Phasenkonzept bringt fuer ein Unternehmen zwei grundlegende Vorteile: Zum einen kann der Aufwand fuer den Umstieg auf Objektorientierung auf einen laengeren Zeitraum verteilt werden, was ein kleineres Risiko bedeutet als ein Wechsel auf einen Schlag. Zum anderen koennen objektorientierte und klassische Verfahren prinzipiell nebeneinander existieren. Dies ist vor allem dann wichtig, wenn in einem Unternehmen Standardsoftware und selbstentwickelte Programme integriert werden muessen.

* Werner Achtert ist Berater in Obermeitingen.