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.

08.05.1992 - 

Ohne Tools geht es eigentlich besser

Auch unter MVS/TSO lassen sich objektorientierte Systeme bauen

Objektorientierung ist nicht an die Verfügbarkeit entsprechender Tools gebunden. Die von Martin Rösch* beschriebene Implementierung eines objektorientierten Systems für die Übergabe von CSP-Applikationen wurde auf einem IBM-Mainframe des Typs 3090-300E unter MVS und TSO mit Hilfe von C/370 und DB2 realisiert.

Nicht ein objektorientiertes Tool ist die erste Voraussetzung für die Nutzung der Objektorientierung, sondern die Umstellung des Denkens von "funktionsorieniert" auf "objektorientiert". Dieses Umdenken wird dadurch gefördert, daß man sehr früh im Projekt mit der Objektorientierung beginnt.

Diese Regel haben wir denn auch beherzigt, als wir daran gingen, mit dem Landschaftsverband Rheinland ein System für die Übergabe von CSP-Applikationen zu erstellen: Dadurch, daß bereits in der Analyse objektorientiert vorgegangen wurde, waren die folgenden Schritte - Entwurf und Codierung - einfacher zu realisieren. Die Analyse erfolgte mit OOA, das Design mit OOD und die Realisierung mit C/370; als Datenbanksystem kam DB2 zum Einsatz.

Ein anfänglicher Versuch, die Analyse mit einem der heute gängigen CASE-Werkzeuge durchzuführen, scheiterte an der Komplexität der Datenstrukturen: Die Trennung von funktionaler Dekomposition und Datenbeschreibung brachte kein zufriedenstellendes Ergebnis.

Daraufhin fiel die Entscheidung, das von Object International angebotene Werkzeug "OOA-Tool" zu prüfen. Rückblickend war dies die vielleicht wichtigste Entscheidung im Projektablauf. Auf diese Weise konnte sich das Projektteam nämlich schnell mit dem objektorientierten Denken vertraut machen.

Von AD/Cycle blieb nur der Aufbau der Datenbasis

Im Vordergrund des Projekts für den Landschaftsverband Rheinland stand zunächst die Übernahme der von einem Drittunternehmen erstellten CSP-Software in das Rechenzentrum des Landschaftsverbands. Zur Zeit wird das Projekt dahingehend erweitert, daß es auch die Produktionsübernahme von Cobol, PL/1 etc. unterstützt.

Ursprünglich sollte das neue Übergabeverfahren soweit wie möglich mit den für AD/Cycle vorgesehenen Mitteln realisiert werden. Doch von AD/Cycle blieb am Ende nur noch der grundlegende Aufbau der Datenbasis übrig; weder das Informationsmodell Cycle noch die absehbaren Software-Angebote im AD/Cycle-Umfeld schienen uns geeignet, die anstehenden Probleme zu lösen.

Bei einer genaueren Untersuchung stellte das Projektteam fest, daß die grundlegende Datenbankarchitektur des Repository weitgehend der von Edgar Codd veröffentlichten "Version 2 des relationalen Modells" folgt. Codd beschreibt in seinem gleichnamigen Buch eine Weiterentwicklung des relationalen Modells, die geradewegs in die Objektorientierung führt. Diese Richtung haben auch die Repository-Entwickler deutlich erkennbar eingeschlagen - was von IBM übrigens nach wie vor hartnäckig geleugnet wird.

Nach dieser Voruntersuchung wurde beim Landschaftsverband entschieden, die eigene Datenbank mit DB2 aufzubauen und bei Datenbank- und Systementwurf die folgende Leitlinie zu beachten:

- grundlegende Architektur der AD/Cycle-Datenbank,

- Codds relationales Modell Version 2,

- Objektorientierung.

Das Projektteam hatte keine Zweifel, die beste heute mögliche Entscheidung getroffen zu haben: Zum einen ist es auf diese Weise möglich, schon heute (und nicht erst 1996) Nutzen aus der im Grunde guten AD/Cycle-Architektur zu ziehen; zum anderen ist die Entscheidung hinreichend zukunftssicher, da die Informationsmodelle des Repository kaum anders aussehen können als die jetzt für das Übergabeverfahren des Landschaftsverbandes Rheinland erstellte Datenbank.

Die hier beschriebene Implementierung eines objektorientierten Systems auf einem IBM-Mainframe kommt ohne eine objektorientierte Programmiersprache und auch ohne eine objektorientierte Datenbank aus. Statt dessen konzentriert sie sich auf die grundlegende Systemarchitektur und den Nachrichtenmechanismus ("Postverteiler").

Konzentration auf die grundlegende Architektur

Diese Entscheidung wurde übrigens im Januar 1992 (ein halbes Jahr nach Projektbeginn) von der Object Management Group (OMG) mit der Vorstellung der Common Object Request Broker Architecture (Corba) bestätigt. Derzeit überprüfen wir, inwieweit der für den Landschaftsverband Rheinland erstellte "Postverteiler" mit den Corba-Spezifikationen der OMG übereinstimmt.

Die Implementierung des Übergabeverfahrens erfolgte in vier Schritten:

1. Produktentscheidung für eine Standardsoftware (Endevor von Legent),

2. Objektorientierte Analyse,

3. Objektorientierter Systementwurf,

4. Realisierung unter MVS/TSO mit C/370 und DB2.

Die Entscheidung für Ende- vor wurde deshalb getroffen, weil das Produkt in der Lage ist, Generierungsabhängigkeiten zuverlässig zu erkennen.

Keine Brüche zwischen den Entwicklungsphasen

Bei der Analyse gingen wir nach der von Peter Coad und Ed Yourdon beschriebenen Methode "Objektorientierte Analyse" vor, durchgeführt haben wir sie mit dem OOA-Tool von Object International. Durch den Einsatz der Objektorientierten Analyse und des OOA-Tools entstand schon sehr früh ein Objektmodell, das auch später - während der Design- und Implementierungsphase - bis zur Fertigstellung des Systems stabil blieb.

Hier erfüllte sich eines der mit der Objektorientierung verbundenen Versprechen: Die bei CASE üblichen Brüche zwischen Analyse, Design und Implementierung konnten tatsächlich vermieden werden.

Jedes Objekt in der gesamten Datenbank wird eindeutig (über alle Tabellen hinweg) mit Hilfe einer "Objekt-ID" identifiziert, die zentral vergeben wird und über die gesamte Lebenszeit des Objektes erhalten bleibt. Die Objekt-ID wird als "Postadresse" benutzt, wenn eine Nachricht an ein Objekt geschickt werden soll. Der "Briefträger" kennt jedes Objekt und weiß, welches Programm gestartet werden muß, um die richtige Bearbeitung der Nachricht zu veranlassen.

Unsere Vorgehensweise wurde auch hier wiederum dadurch bestätigt, wie die Prioritäten von der Object Management Group gesetzt wurden. Deren erste Architekturempfehlung (derzeit noch im Druck) hat nämlich nicht Datenbanken oder Programmiersprachen, sondern den Nachrichtenverteil-Mechanismus zum Thema.

Bisher stehen in der täglichen Praxis Programme im Vordergrund der Entwicklungsarbeiten:

Man "schreibt Programme" zur Automatisierung von Vorgängen. Die Objekte, um die es dabei geht, werden zwar im Rahmen des Datenbankdesigns berücksichtigt, doch sind die mit den Objekten betriebenen Funktionen über viele Programme verstreut. Die Folge: Der Zusammenhang zwischen einem Objekt und allen dazugehörigen Funktionen wird mit zunehmendem Umfang des Programmbestandes leicht aus den Augen verloren.

Bei der Objektorientierung wird die separate Behandlung von Daten und Funktionen aufgehoben. Datenobjekte und ihre zugehörigen Funktionen wachsen zusammen. Datenobjekte können nur noch über die definierten Methoden ihrer Klasse verändert oder abgefragt werden. Der interne Aufbau der Methoden und der Objekte wird nach außen nicht sichtbar. Wenn ein Objekt zur Abarbeitung einer Methode Informationen von anderen Objekten benötigt, wendet es sich mit Hilfe von Nachrichten an die anderen Objekte, die auch wieder nur über ihre Methoden erreichbar sind.

Die Structured Query Language (SQL) war für den Erfolg unserer Implementierung unwichtig. Nur wenige Methoden im System müssen auf die Datenbank zugreifen, also nutzen auch nur wenige Methoden die Datenbank-Abfragesprache SQL. Deswegen ist die hier beschriebene Vorgehensweise auch nicht an SQL gebunden.

Diesen Effekt kann man auch beim IBM-Repository beobachten: Das hochgelobte SQL ist "out". Es wird nicht mehr benötigt. An seine Stelle treten beim Repository Nachrichten, die an "Tools" geschickt werden.

Ein Baukasten aus Fertigteilen

Es hat sich bewährt, alle Methoden einer Objektklasse in einem einzigen C/370-Programm zusammenzufassen. Zusätzlich kann über das Sicherheitssystem des Landschaftsverbands Rheinland (RACF) erzwungen werden, daß die Spielregeln der Objektorientierung eingehalten werden, indem die Datenobjekte wirklich nur mit Hilfe der definierten Methoden zugänglich sind. So entsteht ein Baukasten mit Fertigteilen, die mit definierter Qualität überall einsetzbar sind.

Bei einem objektorientierten System ist der Datenbankentwurf das Wichtigste. Gleichzeitig ist der Datenbankentwurf in einem solchen System einfacher als bei der herkömmlichen Vorgehensweise, da er fast eins zu eins aus der objektorientierten Analyse abgeleitet werden kann.

Probleme mit dem Betriebssystem

Wenn bisher alles relativ einfach aussieht, so soll doch nicht verschwiegen werden, daß auch bei der hier beschriebenen Vorgehensweise der Teufel im Detail steckte. Gerade in der Anfangsphase der Codierung stand das Realisierungsteam mehr als einmal vor zunächst unlösbaren Problemen. Schwierigkeiten gab es vor allem in drei Punkten:

- in der Speicherverwaltung bei den zahlreichen Programmaktivierungen und -deaktivierungen,

- in der Zeitmessung unter TSO bei Performance-Tests und bei

- Programmaufrufen von Cobol nach C/370 in einer DB2-Umgebung.

Zum Glück ließen sich aber für alle diese (und noch einige andere) Problembereiche Lösungen und Umgehungsmöglichkeiten finden.

Die erste Übergabe mit dem neu erstellten Verfahren umfaßte insgesamt etwa 10 000 Softwarebestandteile. Die objektorientierte Systemarchitektur hat den Mainframe zwar deutlich belastet, aber dennoch funktioniert das System. Die hier beschriebene Implementierung ist beim Landschaftsverband Rheinland unter TSO im täglichen Einsatz. Sie wird auch unter CICS und IMS/DC und auf PC-Netzen sowie bei einer Verbindung dieser Umgebungen möglich sein.

Mit einfachen Mitteln große Vorteile erreicht

Es ist überraschend, mit welch einfachen Mitteln die Vorteile der Objektorientierung in der Mainframe-Umgebung erreichbar sind. Diese Vorteile bestehen vor allem in einer klaren Softwaregliederung, einer guten Übersichtlichkeit der erstellten Systeme, einer hohen Mehrfachverwendung der erstellten Funktionen und einer leichten Verständlichkeit der Softwaresysteme sowie in leistungsfähigeren Systemen, einem geringeren Aufwand für die Einarbeitung und in der Reduzierung von Softwarekosten.

Ein einfaches Fazit nach einem interessanten Projekt: Objektorientierung auf dem Mainframe ist möglich. Das Fehlen von objektorientierten Tools in der MVS-Umgebung ist dabei weniger ein Hinderungsgrund als eher eine Hilfe für die Konzentration auf das Wesentliche: Wichtiger als alle objektorientierten Tools, Datenbanken oder Programmiersprachen ist objektorientiertes Denken und die

Verwendung einer objektorientierten Systemarchitektur.

*Martin Rösch leitet die Unternehmensberatung Rösch GmbH in Kaarst.