Re-Engineering darf kein Therapieversuch fuer unwartbare Programme sein Objektorientiert Software und Geschaeftsprozesse neugestalten

10.02.1995

Von Juergen Dunkel*

In vielen Unternehmen waechst der Leidensdruck, der zum Aufsetzen von Re-Engineering-Projekten fuehrt. Dabei sind zwei Zielrichtungen zu unterscheiden: Zum einen gilt es, die eingesetzte Software zu sanieren. Zum anderen reicht es oft nicht aus, nur die Programme zu erneuern - auch Geschaeftsprozesse muessen analysiert und neu gestaltet werden.

Die in den Unternehmen eingesetzten Programme koennen aus verschiedenen Gruenden einer Sanierung beduerfen: Auch Software ist einem Lebenszyklus und somit einer begrenzten Lebensdauer unterworfen. Mit neuen Anforderungen und den damit verbundenen Aenderungs- und Wartungsarbeiten verschlechtert sich die Struktur der Systemarchitektur. Da Software-Aenderungen oft schlecht dokumentiert werden, lassen sie sich nach einer gewissen Zeit nur mit einem unvertretbar hohen Aufwand durchfuehren. Dies kann zu einer Wartungskrise fuehren.

Neue Technik allein tut es nicht

Zusaetzlich werden die Innovationszyklen in der Informationstechnologie immer kuerzer, und die technologischen Anforderungen an die Systeme aendern sich entsprechend. Offene Systeme, Client-Server-Systeme, grafische Benutzeroberflaechen etc. haben neue Bedingungen geschaffen.

Um signifikante Verbesserungen im Unternehmen zu erreichen, genuegt es oft nicht, nur die Technik zu aendern. Vielmehr bedarf es einer Analyse und Erneuerung jener Geschaeftsprozesse, die zum Erreichen der Unternehmensziele relevant sind. Ein erster Schritt ist es dabei, die bestehenden Prozesse exakt zu spezifizieren und zu beschreiben.

Aufwand und Vorgehensweise eines Re-Engineerings differieren je nach Ziel und Ausgangssituation erheblich: Den groessten Aufwand - mit einem hohen Verbesserungspotential - verursacht ein Re- Engineering der Geschaeftsprozesse. Meist sind in den Unternehmen nur deren statische Strukturen (Organigramme), nicht aber die dort ablaufenden, das eigentliche Geschaeft ausmachenden Prozesse dokumentiert. Folglich muessen zunaechst die Geschaeftsprozesse spezifiziert und in einem exakten formalen Modell dargestellt werden. Zur Entwicklung dieser Modelle werden entsprechend geeignete Analyse- und Darstellungsverfahren benoetigt.

Sollen die bestehenden Softwaresysteme einem Re-Engineering unterworfen werden, so ist zunaechst zu entscheiden, welche Systeme ueberhaupt noch genuegend Substanz - unter anderem Struktur und Dokumentation - dafuer aufweisen. Re-Engineering darf nicht als letzter Therapieversuch fuer Software missbraucht werden, die eigentlich gar nicht mehr gewartet werden kann.

Re-Engineering bedeutet auch nicht nur eine marginale Aenderung der Altsysteme, beispielsweise durch blosses Aufpolieren der Benutzeroberflaeche. Ein solcher Ansatz vertuscht die Schwaechen nur fuer kurze Zeit. Ein erfolgreiches Re-Engineering sollte das Altsystem vielmehr in eine saubere, dokumentierte, flexible und modulare Struktur ueberfuehren. Die Softwaremodule muessen erstens eine hohe Kohaesion besitzen, das heisst, ein Softwarebaustein soll logisch zusammenhaengende Teilprobleme behandeln. Zweitens sollten sie eine geringe Kopplung aufweisen; die Abhaengigkeiten zwischen Bausteinen sollten moeglichst gering sein.

Gesucht ist somit eine Methode, Systeme mit genau diesen Eigenschaften zu entwerfen. Eine Modifikation des Codes oder gar die Ueberfuehrung in eine neue Programmiersprache reichen offensichtlich nur in den wenigsten Faellen aus.

Vielmehr ist ein Redesign oder sogar eine Respezifikation erforderlich.Objektorientierte Analyse- und Designmethoden weisen einen Weg, um die obengenannten Aufgaben zu bewaeltigen. Zunaechst einmal kann Objektorientierung (OO) aufzeigen, in welche Zielrichtung das Redesign vorhandener Altsysteme gehen sollte. Die Methoden der Objektorientierung entsprechen dem heutigen Stand der Softwaretechnologie und liefern Loesungen, die im obigen Sinne gut strukturiert, das heisst flexibel und in hohem Grade modular sind.

In OO-Systemen sind Datenstrukturen (Attribute) und die zu ihrer Bearbeitung erforderlichen Operationen (Methoden) in Klassen zusammengefasst. Das heisst, Daten und deren zugehoerige Operationen werden gemeinsam betrachtet, was wesentlich zu einer besseren Verstaendlichkeit und damit auch Wartbarkeit der Systeme beitraegt.

In objektorientierten Systemen ist das Prinzip der Datenkapselung inhaerent vorhanden. Einen Softwarebaustein (hier: eine Klasse) kann man nur kontrolliert ueber seine definierte Schnittstelle (hier: die Menge ihrer Methoden) benutzen. Die Kommunikation zwischen Softwarebausteinen laeuft ausschliesslich ueber diese spezifizierten Schnittstellen. Die Kollaboration von Softwarebausteinen laesst sich mit einem Kontrakt vergleichen: Jeder Baustein hat die Verantwortung, die an ihn gestellten Anforderungen zu erfuellen.

Details ueber die interne Realisierung eines Bausteins wirken nicht nach aussen und sind auch anderen Bausteinen nicht bekannt. Dadurch lassen sich bausteininterne Aenderungen durchfuehren, ohne auf andere Systemteile durchzuschlagen - eine wichtige Eigenschaft fuer einen modularen, wartungsfreundlichen Software-Aufbau.

Eine solche, auf dem Prinzip der Datenkapselung basierende Software-Architektur erfordert nicht unbedingt den Einsatz objektorientierter Methoden. Sie laesst sich auch mit klassischen Verfahren realisieren. So bieten Programmiersprachen wie Ada oder Modula-2 entsprechende Konzepte.

Vererbungsmechanismen und Redefinition stellen in rein objektorientierten Systemen weitere Mechanismen zur Verfuegung, die fuer eine leichte, kontrollierte Wartung und Aenderbarkeit des Systems wesentlich sind. Es lassen sich neue Klassen (Unterklassen) erzeugen, die saemtliche Attribute und Methoden aus bereits vorhandenen Klassen (Oberklassen) uebernehmen (erben) und diese um zusaetzliche Attribute und Methoden erweitern. Ist in einer Unterklasse eine Methode der Oberklasse zu modifizieren, so kann diese in der Unterklasse erneut definiert werden (Redefiniton).

Durch Vererbung und Redefinition ist eine kontrollierte Aenderung und Erweiterung vorhandener Softwarebausteine moeglich: Man muss nicht im alten und oft unuebersichtlichen Code fehleranfaellige Modifikationen vornehmen. Statt dessen lassen sich neue Bausteine generieren, die die Funktionalitaet vorhandener Bausteine durch Vererbung uebernehmen (wiederverwenden), diese entsprechend modifizieren und erweitern.

Objektorientierung ist die Softwaretechnologie der Zukunft, auf die alle grossen Anbieter setzen. Bezeichnend ist, dass traditionelle Technologien verstaerkt um objektorientierte Ansaetze erweitert wurden, so zum Beispiel C zu C++ oder Cobol zu Object- Cobol. Der Einsatz objektorientierter Systemtechnik ist eine Investition, die auch in der Zukunft Bestand haben wird. Spaetestens mit einer groesseren Verbreitung des zunehmend wichtigen Corba-Standards der Object Management Group (OMG), der eine Verteilung von Objekten in heterogenen verteilten Systemen ermoeglicht, wird kaum ein Weg an objektorientierten Systemen vorbeifuehren.

In juengster Zeit zeigt sich, dass die Objektorientierung ein universelles und maechtiges Paradigma auch zur Modellierung von Geschaeftsprozessen liefert. Die objektorientierten Analysemethoden bieten ein umfangreiches Instrumentarium, um Ablaeufe in Unternehmen zu beschreiben und zu definieren. Mit Hilfe von Objekten, die miteinander kommunizieren und kollaborieren, lassen sich anschauliche und verstaendliche Modelle von Geschaeftsvorfaellen entwickeln.

Zur Einfuehrung objektorientierter Methoden ist ein inkrementelles Vorgehen sinnvoll. Die Methoden und Werkzeuge muessen eingefuehrt werden, und fuer jede vorhandene Softwarekomponente ist zu entscheiden, ob sie durch eine Neuentwicklung oder durch Standardsoftware ersetzt, einem Re-Engineering unterworfen werden muss oder vorlaeufig bestehen bleiben kann. Damit werden in einer Uebergangsphase zunaechst einzelne Systemteile, zum Beispiel die Benutzer-Schnittstelle, mit Hilfe neuer, objektorientierter Technologie realisiert.

Auf diesem - unter Umstaenden weiten - Migrationsweg muessen Altsysteme und neue (objektorientierte) Loesungen nebeneinander bestehen, und es gilt, Schnittstellen sowie Mechanismen zu schaffen, damit Altsysteme und objektorientierte Software miteinander kooperieren koennen. Entsprechende Techniken, insbesondere fuer die Anbindung vorhandener (relationaler) Datenbanken, sind aber bereits auf dem Markt.

In jedem Re-Engineering-Projekt ist zunaechst festzulegen, welche genauen Ziele verfolgt werden sollen. Sie koennen von der Sanierung vorhandener Altsysteme bis hin zur Analyse und zum Re-Engineering der vorhandenen Geschaeftsprozesse reichen. Objektorientierte Analysemethoden bieten ein anerkanntes, maechtiges und ausgereiftes Instrumentarium, das sich zur angemessenen Beschreibung sowohl von Softwaresystemen als auch von Unternehmen verwenden laesst. Die erforderlichen Methoden und Werkzeuge sind in ausreichendem Masse vorhanden. Objektorientierung ist zweifelsfrei die Softwaretechnologie der Zukunft. Gerade in Re-Engineering- Projekten gilt es auf diese Zukunft zu setzen.

* Dr. Juergen Dunkel ist Projektleiter bei der Integrata AG, Geschaeftsstelle Duesseldorf