Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

11.06.1993

Strategien fuer das Downsizing von Host-Programmen (Teil 3) Der Datenbankzugriff spielt bei SW-Zerlegung eine grosse Rolle

Unabhaengig vom jeweiligen Ansatz der Programm-Modularisierung muessen die Daten entsprechend der prozeduralen Gliederung aufgeteilt werden. Ideal waere es, jedem Modul nur die Daten zur Verfuegung zu stellen, die es braucht. Leider ist dies nicht moeglich, da sich die Saetze und Tabellen, Masken und Berichte nicht so einfach auseinanderreissen lassen. Das wuerde zu unvorhersehbaren Fehlern in der Adressierung fuehren. Harry Sneed* zeigt in der letzten Folge seiner Artikelreihe die Strategien fuer die Datenverteilung auf.

*Harry Sneed ist Technischer Direktor bei der SES Software- Engineering Service GmbH in Ottobrunn bei Muenchen.

Um die Datengruppen verteilen zu koennen, muessen sie zuerst abgegrenzt werden. In PL/1 lassen sich Datenfelder einzeln deklarieren, auch wenn sie nicht zu einer Struktur gehoeren. In Cobol gibt es elementare Stufe-1-Felder sowie die bekannten 77 Felder. Aus diesen einzelnen Feldern gilt es, Gruppen zu bilden - eine Gruppe pro Modul -, die als Parameter vom Hauptprogramm an die Unterprogramme uebergeben werden.

Die vorhandenen Datenstrukturen werden in bezug auf jedes Modul darauf untersucht, ob untergeordnete Felder von dem jeweiligen Modul referenziert sind und, wenn ja, wie: als Eingabe, Ausgabe oder Praedikat. Falls nur ein Feld verwendet wird, muss die ganze Struktur als Parameter an das Modul uebergeben werden. Fuer diese Untersuchung ist eine Querverweisliste unentbehrlich. Am besten ist es jedoch, wenn ein Analysewerkzeug die Felder nach Nutzungsart markiert und die betroffenen Datenstrukturen gleich in eine Parameterliste ueberfuehrt.

Im Grunde genommen geht es hier um einen Optimierungsvorgang, denn im Prinzip laesst sich der Arbeitsspeicher als Ganzes an jedes Unterprogramm uebergeben.

Physisch praesent sind die Daten sowieso ausschliesslich im Adressraum des Hauptprogramms, aber wegen der Einschraenkung der Verfuegbarkeit kommt es darauf an, jedem Unterprogramm nur die von ihm referenzierten Datengruppen bereitzustellen. In Cobol kommen alle dieser Strukturen in der Linkage Section vor.

Es spricht fuer den objektorientierten Ansatz, dass sich die Daten zusammen mit den Prozeduren aufteilen lassen. Mit dem Ansatz werden zunaechst die Datengruppen auseinanderdividiert. Anschliessend wird der prozedurale Code entsprechend der Datenaufteilung zerlegt. Insofern ist eine zusaetzliche Datenaufteilung nicht erforderlich.

Bei den beiden anderen Ansaetzen, dem ablaufbezogenen und dem funktionalen, ist die Datenaufteilung ein sekundaerer Schritt, der auf die prozedurale Aufteilung folgt. Er ist trotzdem unentbehrlich, zum einen wegen der Effizienz, zum anderen um die Wartung und das Testen zu erleichtern. Ausserdem stoesst man mit allzu grossen Datenbereichen an die Grenzen vieler Minirechner, da ihr Adressraum nicht reicht. Daher wird man zum Aufteilen der Daten gezwungen.

Die meisten Host-Anwendungen benutzen ein hierarchisches oder netzartiges Datenbanksystem. Einige arbeiten noch mit VSAM oder ISAM. Das Zielsystem in der Client/Server-Welt ist in der Regel ein relationales

Datenbanksystem. Die Daten, die bisher in grossen Saetzen zusammengefasst waren, werden kuenftig auf mehrere Tabellen verteilt. Neue Programme koennen auf das neue Datenmodell zugeschnitten werden.

Wie verhaelt es sich aber mit den alten Programmen? Hier haben wir es mit einem Strukturbruch zu tun, da die alten Programme die Daten als Saetze oder Segmente brauchen, die sie in Ketten abarbeiten. Die neuen Daten sind aber als relationale Tabellen gespeichert. Ein Modifizieren der Zugriffsalgorithmen der betroffenen Programme kommt dem Aufwand einer Neuprogrammierung gleich.

Es bleibt also nichts anderes uebrig, als eine Schnittstelle in Form eines Ein- und Ausgabe-Moduls zu schaffen, das die Datenanforderungen der Programme empfaengt und sie in relationale Zugriffe umsetzt. Die Daten werden aus den Tabellen mit SELECT und FETCH geholt und zu klassischen Saetzen zusammengefasst und uebergeben. Umgekehrt werden die alten Saetze auf Relationen verteilt und in die Tabellen zurueckgespeichert.

Das Zugriffsmodul erhaelt somit eine Umsetzungsroutine fuer jeden der alten Zugriffe sowie eine Parameterliste mit Zugriffsart, Returncode, Schluessel und Satzinhalt, ueber die er mit den aufgerufenen Programmen kommuniziert. Solche Zugriffsmodule existieren bereits haeufig in der Praxis.

In den Anwendungsprogrammen muessen alle In- und Output- Operationen in Call-Aufrufe zum Zugriffsmodul umgewandelt werden. Dies hat natuerlich gewisse Konsequenzen fuer die Performance, aber dies ist der unumgaengliche Preis fuer die Beibehaltung des alten Codes. Ausserdem gibt es einen weiteren wichtigen Grund, warum ein Zugriffsmodul erforderlich ist. Im Falle konventioneller Dateien sind die I/O-Operationen wie OPEN, CLOSE, READ WRITE, REWRITE und DELETE auf das grosse monolithische Programm verteilt.

Wenn das Programm zerlegt wird, erscheint die gleiche Datei in verschiedenen Modulen. Wenn die Dateien nicht aufgeteilt sind, wird das modularisierte Programm nicht einmal kompilierfaehig sein. Das heisst, die Dateien muessen aus den Programmen entfernt und in ein

I/O-Modul verlagert werden. Die

Saetze, die bisher in der File Section waren, werden in die Working Storage Section versetzt und von dort aus als Parameter dem Zugriffsmodul uebergeben

Auf diese Weise ist es moeglich, zwei Fliegen mit einer Klappe zu schlagen. Zum einen wird das Problem der verteilten Ein- und Ausgabe-Operationen auf dieselben Dateien geloest. Zum anderen wird der Bruch zwischen dem alten und dem neuen Datenmodell ueberwunden.

Die Gruende fuer die Zerlegung allzu gross gewordener Programme sind mannigfaltig: Sie sprengen die Speichergrenzen, sind aufgrund ihres Umfangs nicht mehr zu warten oder erzeugen zu viele Ausgaben. Auch die Entscheidung fuer Downsizing und die Portierung der Software auf kleinere Rechner kann ein Anlass sein, die Software in kleinere Teile zu zerlegen.

Im Jahre 1992 uebernahmen der Autor und seine Mitarbeiter die Reorganisation von acht Programmen. Das erste, ein Assembler- Programm, musste in vier Programme aufgeteilt werden, weil es fuer die Operationsumgebung des neuen Rechners zu viele verschiedene Listen produzierte. Zerlegt wurde also nach der Liste beziehungsweise nach dem Objekt.

In einem weiteren Projekt sollten sechs Unisys-A5-Programme im Hinblick auf eine kuenftige Portierung reorganisiert werden. Bei dieser Software wurden alle drei Ansaetze ausprobiert. Zwei Programme wurden objektorientiert, zwei ablaufbezogen und zwei funktional aufgeteilt. Der jeweilige Ansatz ergab sich aus der Struktur des Programms. Es hat sich naemlich gezeigt, dass es kaum moeglich ist, alle Programme nach der gleichen Strategie zu zerlegen.

Es gibt Programme, bei denen eine objektorientierte Aufteilung auf der Hand liegt, und andere, bei denen diese Aufteilung nur mit einem grossen Aufwand zu erreichen ist. Das gleiche trifft fuer die funktionale Aufteilung zu. Darum mussten in einem und demselben Anwendungssystem verschiedene Strategien verfolgt werden. Die Entscheidung, welche Vorgehensweise fuer das jeweilige Programm am besten geeignet ist, setzt eine gruendliche Analyse des Programms voraus.

Ein weiteres Programm, eine Unisys-Cobol74-Software, musste im Rahmen eines Downsizing-Projekts zerlegt werden. Fuer den Zielrechner, eine IBM AS/400, war das Programm mit mehr als 28 000 Codezeilen viel zu gross. Ausserdem hat es mehr als 80 Dateien verarbeitet. Mehr als 100 Manntage waren noetig, das Programm in 14 Module funktional aufzuloesen, die Modulschnittstellen einzubauen, die Daten aufzuteilen und eine I/O-Schnittstelle zu den Dateien zu schaffen.

Aus den Projekten koennen einige Lehren gezogen werden. So darf das Programm-Downsizing nicht mit Restrukturierung verwechselt werden.

Den Programmablauf von einem unstrukturierten Netzwerk in einen strukturierten Baum zu versetzen oder das Programm in seiner Gesamtheit zu reorganisieren sind zwei verschiedene Vorgehensweisen.

Die erste Taetigkeit ist weitgehend automatisiert, die zweite nicht. Die zweite Lehre ist: Jedes System muss anders bearbeitet werden. Es hat sich ausserdem gezeigt, dass gute Werkzeuge absolut notwendig sind. Die Tools helfen, die Programme zu analysieren und nachzudokumentieren. Ihr Einsatz lohnt auch beim Einbau der Zugriffsschnittstellen und der Bildung der neuen Datenobjekte. Ferner zeigt die Erfahrung, dass sich die Zerlegung grosser Programme nicht vollstaendig automatisieren laesst, da nur ein DV- Experte in der Lage ist, die endgueltigen Modulgrenzen zu ziehen. Zu ungenau und problemspezifisch sind die Teilungskriterien. Ergo wird das Software-Downsizing in naechster Zukunft eine intellektuell anspruchsvolle und arbeitsintensive Aufgabe bleiben, obwohl sich einige Teilaufgaben durchaus automatisieren lassen.