Mit Problemen der Sanierung von Software befasst sich die Gesellschaft fuer Mathematik und Datenverarbeitung (GMD) schon seit laengerem. Im Projekt "Methoden fuer objektorientiertes Re- Engineering" (Moore) wird untersucht, in welchem Masse sich vorhandene Cobol-Programme in objektorientierte Form ueberfuehren lassen, um so fuer weitere Anpassungen besser geeignet zu sein. Zielsprache ist dabei objektorientiertes Cobol.
Informationstechnische Innovationen erfolgen heute so schnell, dass Produkte oft schon ueberholt sind, bevor sie beim Anwender zum Einsatz kommen. Dies gilt auch fuer Software.
Noch unbefriedigender fuer den Anwender ist die Situation bei altgedienter Software, die in Aufbau, Aussehen und Leistung trotz dauernder Wartung selten dem Stand der Kunst entspricht und haeufig weder den Anforderungen des Benutzers noch des Wartungspersonals genuegt.
Software anpassen oder durch neue ersetzen?
Aendern sich Leistungsanforderungen, muss sich ein Unternehmen die Frage stellen, ob es guenstiger ist, die vorhandene Software anzupassen oder sie durch neue zu ersetzen. Wichtige Gesichtspunkte bei der Beantwortung dieser Frage sind, wann die neuen oder ueberarbeiteten Programme zur Verfuegung stehen, welche Kosten vertretbar sind, wie Benutzer und DV-Personal mit der Umstellung und ihrem Ergebnis zurechtkommen werden und welche mittel- bis langfristigen Auswirkungen die Entscheidung auf die Arbeit der betroffenen Personen, den Betrieb und seine Wettbewerbsfaehigkeit haben wird.
Eine allgemeingueltige Loesung dieses Problems kann es nicht geben, wohl aber einige fundierte Empfehlungen.
Kennzeichnend fuer die heutige Situation des Anwenders ist eine sich abschwaechende Bindung an Systemlieferanten, seien sie aus dem eigenen Hause oder extern. Das Wort von der Emanzipation der Anwender galt zunaechst fuer die Hardware, seit geraumer Zeit aber auch fuer die Software. Vor allem hauseigene Entwicklungen muessen sich immer staerker gegen sogenannte Standardsoftware behaupten, die nicht an eine bestimmte Hardware gebunden ist. Der Trend geht eindeutig und berechtigterweise hin zu offenen, nicht proprietaeren Systemen. Langfristiges Ziel eines Unternehmens muss es daher sein, den Anteil an selbstgeschriebener Software auf das unumgaengliche Mass zu beschraenken und dabei gleichzeitig eine weitgehende Hardware-Unabhaengigkeit zu erzielen. Damit einhergehen muss eine Vereinheitlichung der In- formations- und Datenstrukturen ("einheitliches betriebliches Datenmodell") und eine Bereinigung der Daten und Verfahren, was nicht zuletzt auch eine Straffung der Organisation bedeutet.
Im Zuge der Aufloesung zentraler Strukturen in der DV muss auch die Software in einer fuer den Benutzer (zum Beispiel den Sachbearbeiter) leichter zu verstehenden Form zugaenglich werden. Die Aenderbarkeit von Programmen muss nicht nur auf dem Papier den Rang eines Qualitaetskriteriums bekommen, sondern auch in der taeglichen Arbeit.
Was aber kann der Anwender derzeit tun? Der Markt wird von einer eher verwirrenden Vielfalt von Ansaetzen und Produkten ueberflutet, und was sich langfristig durchsetzen wird, ist nicht klar zu sehen. Sicherlich werden fuer verschiedene Anwendungsgebiete auch weiterhin verschiedene Techniken erforderlich sein.
Alle werden verstaerkt ein ingenieurmaessiges Vorgehen unterstuetzen, und alle werden mehr oder weniger schnell von neuen Techniken abgeloest werden. Konstant wird nur der Wandel bleiben. Fuer Unternehmen bedeutet dies die Notwendigkeit zur staendigen Ueberpruefung und abgewogenen Modernisierung ihrer Betriebsmittel - und somit auch ihrer DV.
Jedes Konzept zur Sanierung alter Software wird sich am konkreten Fall orientieren muessen. Je nach Situation wird den Phasen der Bereinigung der Daten oder zur Sichtung, Aussortierung, Restrukturierung, Abloesung beziehungsweise Renovierung der vorhandenen Programme unterschiedliche Bedeutung zukommen.
Im Projekt Moore der GMD konzentrieren sich die Arbeiten auf die Renovierung vorhandener Programme. Ziel ist dabei die Bereitstellung von Methoden und Werkzeugen zur Aufarbeitung der Programme, gekoppelt mit einer schrittweisen Ueberfuehrung in ablauffaehige objektorientierte Form. Die dabei gebildeten Konstrukte objektorientierter Art werden in eine Klassenbibliothek (Repository) aufgenommen und koennen dann bei der Umstellung weiterer Programme beziehungsweise bei der Neuprogrammierung (wieder)- verwendet werden. Die Projektarbeit ist von vornherein auf eine inkrementelle Sanierungstechnik ausgerichtet.
Flexibles Design durch einen OO-Ansatz
Warum Objektorientierung? Software, die in ihrem Leistungsangebot Schritt halten muss mit den sich aendernden Wuenschen ihrer Benutzer, muss notwendigerweise weiterentwickelt, das heisst veraendert werden. Anpassung und Erweiterbarkeit verlangen ebenso wie auch Wiederverwendbarkeit und Kompatibilitaet ein flexibles Design, und dafuer stellt der objektorientierte Ansatz die gegenwaertig wohl beste Loesung dar (siehe Lite- raturangaben 1) und 2); naehere technische Einzelheiten siehe 3)).
Eine zentrale Fragestellung des Projektes ist, in welchem Mass und mit welchen Verfahren die Aufarbeitung alter Programme und ihre Transformation in objektorientierte Form technisch und oekonomisch sinnvoll ist.
Da im kommerziellen Bereich der Bestand an sanierungsbeduerftiger Software besonders gross ist, hat das Projektteam den Schwerpunkt seiner Arbeiten zunaechst auf die Entwicklung eines Prototypen zur Transformation von Cobol-85-Programmen in objektorientierte Form gelegt.
Betrachtet man das Marktangebot an rechnergestuetzten Werkzeugen zur Entwicklung und Pflege von Software (gewoehnlich Software- Entwicklungsumgebungen genannt), faellt auf, wie stark die Anbieter die Integration aller Werkzeuge sowie die Existenz entsprechender Schnittstellen nach innen und aussen und einer zentralen Entwicklungsdatenbank betonen. Meist fehlt auch nicht der Hinweis auf die Erweiterbarkeit der Entwicklungsumgebung durch neue Werkzeuge und Methoden, sobald diese verfuegbar werden.
So einleuchtend die Argumentation der Anbieter solcher Umgebungen auch auf den ersten Blick scheint, so wenig ueberrascht es, dass sie es bisher nicht vermocht haben, mit ihren Produkten auf breiter Front Einzug in die Software-Abteilungen der Anwender zu halten. Die Umgebungen sind einfach zu gross und verlangen zu viele Hintergrundkenntnisse, so dass die meisten Nichtinformatiker ueberfordert sind, wenn sie mit ihnen arbeiten sollen (siehe 4), 5)). Gelernte Informatiker sind aber die wenigsten der in den DV- Abteilungen der Unternehmen beschaeftigten Mitarbeiter. Es treten also Wissens- und Akzeptanzprobleme auf.
Mit den GMD-Methoden versucht man, diesen Problemen dadurch zu begegnen, dass der Benutzer des spaeteren Produkts ein homogenes, leicht handhabbares und in sich geschlossenes Werkzeug angeboten bekommt. Um mit dem System erfolgreich arbeiten zu koennen, genuegen eine entsprechende Einweisung und Grundkenntnisse des objektorientierten Programmierens. Damit ist das Arbeiten mit dem System zunaechst entkoppelt von den vielen, meist technischen Problemen und Abhaengigkeiten umfaenglicher (CASE-)Umgebungen, solange diese noch so schwer beherrschbar sind. Zu einem spaeteren Zeitpunkt kann es durchaus sinnvoll sein, ein aus dem Moore- Prototypen weiterentwickeltes Produkt in eine dann leichter handhabbare CASE-Umgebung zu integrieren.
Die Arbeit mit dem Prototypen erfolgt interaktiv am Bildschirm, wobei der Benutzer direkt beeinflussen kann, wie seine Altsoftware schrittweise aufgearbeitet und in objektorientierte Form ueberfuehrt wird. Er laesst sich zum Beispiel Vorschlaege fuer eine Klasse oder eine Methode anzeigen, kann deren Konsequenzen ueberblicken, einen Vorschlag akzeptieren, veraendern oder verwerfen, er vergibt die Namen von Klassen, Methoden und gegebe- nenfalls zusaetzlich einzufuehrenden Variablen etc. In einzelnen Faellen mag er auch entscheiden, Methoden losgeloest von vorhandenen Codesequenzen in der Zielsprache neu zu programmieren. Fuer all diese Massnahmen steht ihm eine die Transformationen veranschaulichende Benutzeroberflaeche in Mehrfenstertechnik zur Verfuegung.
Im Gegensatz zu einigen anderen Ansaetzen (zum Beispiel beim Esprit-Projekt "Redo" 6)) erfolgt bei der GMD-Methode die Umsetzung von Quellprogrammen nicht in der Form, dass zunaechst die vollstaendige Leistungsbeschreibung in einer Spezifikationssprache rekonstruiert werden muss, aus der dann ein Generator den Programmcode in der Zielsprache erzeugt. Dieser Ansatz ist zwar formal befriedigend, nicht jedoch praktisch. Man denke nur an die Umstellung grosser Programmkomplexe mit all ihren historisch bedingten Besonderheiten und Hilfskonstruktionen. Wer von den bisher mit dieser Software befassten Mitarbeitern ist zu einer vollstaendigen formalen Respezifikation bereit und in der Lage? Und wer kann anschliessend die umfangreichen, anderen oft sehr schwer zu vermittelnden formalen Spezifikationen pflegen?
Transformationsteil bildet den Schwerpunkt
"Moore" verbindet die bisher getrennten Disziplinen Reverse Engineering und objektorientierte Software-Entwicklung. Damit die Anwender sich auf die zu verfolgenden Entwurfsziele konzentrieren koennen, ist sehr bewusst der moeglichst umfangreiche Einsatz bereits existierender Werkzeuge angestrebt.
Einen Ueberblick ueber das zum Einsatz kommende Verfahren gibt die Abbildung. Es besteht im wesentlichen aus einem Analyseteil, in dem aus dem vorliegenden Cobol-Quellcode ein Grossteil der fuer die weitere Arbeit benoetigten Informationen gewonnen wird, und einem Syntheseteil, in dem die fuer die Transformation in objektorientierte Form in Frage kommenden Programmteile identifiziert, transformiert und anschliessend durch den neuen objektorientierten Cobol-Code ersetzt werden.
Den Schwerpunkt der Arbeiten bildet der Transformationsteil. In ihm erfolgt die sukzessive Umwandlung der aufzuarbeitenden Software in die angestrebte objektorientierte Form. Dabei wird eine moeglichst weitgehende Fuehrung des Benutzers durch das System angestrebt, das dazu intern sowohl mit algorithmischen als auch mit heuristischen Verfahren arbeitet, wobei noch geprueft werden muss, ob auch anwendereigene Ansaetze aufgenommen werden koennen.
Wenn eine vom System vorgeschlagene Umwandlungsmassnahme nicht den Ueberlegungen des Systembenutzers entspricht, muss dieser eigene Schritte veranlassen. Dabei ist zu unterscheiden, ob er nur einen Vorschlag des Systems ohne Aenderung der Programmsemantik variiert, oder ob er ueber den Vorschlag hinausgeht und bisher vom System noch nicht untersuchte Programmteile einbezieht.
In diesem Fall gibt das System die Kontrolle an den Benutzer ab, um ihm dann weitere Aktivitaeten mit allen Risiken zu ueberlassen, im erstgenannten Fall dagegen uebernimmt das System den Benutzervorschlag und kann Umwandlungsschritte wieder per Vorschlag anbieten.
Die Analyse und Aufarbeitung einzelner Cobol-Programme fuehrt in der Regel nur zur Ableitung weniger und einfacher objektorientierter Konstrukte. In der Praxis hat man es aber zum groessten Teil mit der Aufarbeitung mehrerer Programme aus dem gleichen Anwendungsbereich zu tun. In solchen Programmfamilien findet man haeufig aehnliche oder gleiche Datenstrukturen. Die umgesetzten Programme sollen - "objektorientiert" ausgedrueckt - in diesen Faellen gleiche oder zumindest aehnliche Klassen, das heisst benutzerdefinierte abstrakte Datentypen mitsamt den in ihnen definierten Variablen (Attributen) und den auf ihnen erlaubten Zugriffsoperationen (Methoden) benutzen.
Diese Klassen zu verwalten und auf Nachfrage anzubieten ist Aufgabe der bereits erwaehnten Klassenbibliothek. Bei der Umsetzung eines weiteren Programms wird der Benutzer dann auf bereits vorhandene gleiche oder aehnliche Klassen hingewiesen. Er kann sie entweder unveraendert in sein Programm uebernehmen oder um zusaetzliche Attribute und Methoden anreichern und dann geaendert in die Klassenbibliothek zurueckschreiben. Dabei finden Konsistenzpruefungen statt, die sicherstellen, dass bereits umgesetzte Programme auch nach Aenderung an von ihnen verwendeten Klassen weiter lauffaehig sind. Der Benutzer hat jedoch auch die Moeglichkeit, zu einer bereits in der Bibliothek vorhandenen Klasse eine neue Unterklasse mit speziellen Attributen und Methoden zu definieren, ohne die vorhandene Oberklasse zu veraendern. Auch die nachtraegliche Bildung einer Oberklasse aus mehreren aehnlichen Unterklassen ist moeglich.
Auf diese Weise sammeln sich waehrend der Umsetzung einer Programmfamilie neue Klassen, die immer wieder revidiert und verbessert werden. Es entsteht schliesslich ein Satz von stabilen, ausgereiften Anwendungskomponenten, die sowohl bei der Entwicklung neuer Programme als Basisbausteine als auch bei einer erneuten Durchsicht schon bearbeiteter oder ausgewerteter Programme wiederverwendet werden koennen.
Der Sprachumfang des objektorientierten Cobol wird zur Zeit in den internationalen Normungsgremien beraten. Da das objektorientierte Cobol das bisherige Cobol 85 als Teilmenge enthaelt, werden die Unternehmen eher dazu bereit sein, auf die neue, erweiterte Form ueberzugehen. Sie werden zu ueberlegen haben, wie sie Pflege und Weiterentwicklung ihrer Altsoftware und die Entwicklung neuer Programme organisatorisch und personell am besten werden bewaeltigen koennen.
Erste Compiler fuer objektorientiertes Cobol werden voraussichtlich im Laufe des Jahres 1994 freigegeben werden. Damit besteht die Aussicht, dass die in Moore entwickelten Instrumente bereits prototypisch fertiggestellt sind, wenn sich bei den Unternehmen der Bedarf an solchen Umstellungshilfen einstellt. Die Aufbereitung alter Software herkoemmlicher Programmiertechnik mit angeschlossener Transformation in Software objektorientierten Zuschnitts ist durchfuehrbar. Natuerlich werden die mit der beschriebenen Technik zu erzielenden Ergebnisse gegenueber denen einer Neuprogrammierung direkt in objektorientiertem Stil immer etwas abfallen. Der Einsatz einer solchen Technik wird jedoch fuer viele Unternehmen eine praktikable und oekonomisch sinnvolle Chance sein, Altlasten im Bereich der Software gleitend und unter Einbeziehung des bisher schon mit der Pflege der Programme beauftragten Personals umzustellen.
Die in dem GMD-Projekt entwickelte Technik sollte verwendet werden, wenn ein konkreter betrieblicher Bedarf zur Umstellung und Bereinigung der Programmbasis vorliegt, etwa ein sich abzeichnender Plattformwechsel.
Literatur
1) Bertrand Meyer: Object-oriented Software Construction, Prentice Hall, 1988
2) Grady Booch: Object Oriented Design, Benjamin/Cummings, 1991
3) C. Pflueger und H. Roth, Objektorientiertes Re-Engineering alter Cobol-Programme, GMD-Spiegel 3/4, 1992
4) Hartmut Skubsch: SW-Landschaft in Bewegung; Warum viele CASE- Einfuehrungen scheitern., COMPUTERWOCHE Nr. 35 vom 28. August 1992, Beilage "FOCUS"
5) Heiko Seebode: Objektorientiertes Programmieren - Allheilmittel oder Duftwaesserchen. PC-Woche, 14. September 1992
6) P. Breuer, K. Lano: Creating Specifications from Code: Reverse- engineering Techniques, Software Maintenance: Research and Practice, Band 3, 1991