4GL in der objektorientierten Anwendungsentwicklung

Eine neue Rolle als Katalysator für die Objektkommunikation

07.02.1992

4GLs "denken" von Haus aus systemunabhängig und sind daher prädestiniert für eine objektorientierte Programmierung (OOP). Wenn das 4GL-Runtime-System auf möglichst vielen Plattformen bereit gehalten wird, ist es möglich, Objekte synergetisch zu nutzen. Folglich können 4GLs in einer Client-Server-Umgebung den starken Rationalisierungsschub bewirken, der von OOP erwartet wird.

Die Erfolgsmeldungen der Hardwarehersteller sind auf Dauer ermüdend: noch schneller, noch kleiner, noch mehr Kapazität! Im Softwarebereich hingegen ist die Rede voll einer Krise. Programmierer könnten ihre Aufträge nicht schnell genug abarbeiten. heißt es; die eingesetzte Software sei darüber hinaus fehlerhaft und die Wartung über Gebühr aufwendig.

Die Hardware ist der Software um Jahre voraus

Diese Phänomene hängen zusammen. Es hat den Anschein, als wäre die Hardware der Software um Jahre voraus, und die Software krabble mit hängenden Programmschleifen Codezeile für Codezeile hinterher. Klar ist: Mit den derzeit dominierenden Programmiertechniken und -sprachen wird sich an diesem Zustand nichts ändern. Daher kommt neuen Konzepten im Anwendungsentwicklungsbereich eilte besondere Bedeutung zu. Ein radikaler, dazu vielversprechender Ansatz ist die sogenannte Objektorientierung.

Objektorientiertes Programmieren (OOP) soll vor allem eines: möglichst viel Code wiederverwendbar machen. Allerdings stellt sich die Frage, inwieweit OOP-Techniken in bestehende Systeme, Entwicklungsumgebungen der vierten Generation (4GL) und (Client-Server-Konzepte integriert werden können.

Unter einem Objekt verstellt man eine nach außen abgeschlossene Programmeinheit, die lokalen Daten - Attribute genannt - und Funktionen beziehungsweise Prozeduren oder Methoden zusammenfaßt. Die Technik, Attribute und Methoden zu einer undurchsichtigen Einheit zu verschmelzen, nennt matt Datenabstraktion oder Einkapselung (Encapsulation). Sie schützt unter anderem vor unerwünschten Effekten bei nachträglichen Änderungen. Ein direkter Datenzugriff von außen ist nicht mehr möglich, da das Objekt nur über festgelegte "Nachrichten" angesprochen werden kann. Diese Schnittstellen eines Objektes verhalten sich immer gleich.

Der Programmfluß wird durch die Kommunikation der Objekte untereinander - mittels der Nachrichten - erreicht. Dabei wird vorausgesetzt, daß jedes Objekt die Nachrichten selbständig und intelligent verarbeitet, was zu einer größeren Flexibilität und Überschaubarkeit der Strukturen führt.

Die Klasse ist ein Sonderfall eines Objekts. Als Element enthält und kontrolliert sie eine Anzahl von "Kind"-Objekten; diese Unterklassen kennen nicht nur ihre eigenen, sondern auch alle in der Deklaration der Oberklasse festgelegten Methoden. Die, Klasse zeigt nach außen hin ein homogenes Verhalten. Heimtückische Fehler zum Beispiel Verweise auf nicht initialisierte Objekte, können auf diese Weise vermieden werden. Eine Subklasse erbt alle Eigenschaften und das Wissen, wie auf Nachrichten reagiert werden muß, voll ihrer Oberklasse.

Der Vorteil des objektorientierten Paradigmas für die Anwendungsentwicklung ist der, daß nur die Teile des Codes neu geschrieben werden müssen, die tatsächlich neu sind. Es muß also nicht jede Applikation komplett neu erstellt werden, sondern der Rest des Programms kann aus den verfügbaren Klassen und Objekten rekombiniert werden. Um diesen Effekt zu erzielen, müssen aber soviele Objekte wie möglich zur Verfügung stehen. Der eigentliche Trick beim OOP-Konzept besteht demnach im Einsatz existierender Standard-Objekte - egal ob sie zugekauft oder selbst erstellt worden sind.

Bei den Objekten ist die Trennung zwischen den Daten und den Funktionen, die man mit ihnen durchführen kann, aufgehoben. Von daher kommt die objektorientierte Programmierung der natürlichen Denkweise wesentlich näher als herkömmliche Methoden der Anwendungsentwicklung. Ein weiterer Vorteil bestellt darin, daß es unmöglich ist, Objekte mit ihren Funktionen anders einzusetzen, als es gestattet ist: Objekte folgen einzig und allein ihrem dedizierten Zweck.

Die ideale Unterstützung für diesen Ansatz bieten Umgebungen, die nach dem Client-Server-Modell ausgerichtet sind. Auch in einer solchen Umgebung sind den einzelnen Arbeitsstationen bestimmte Aufgaben zugeordnet. In einer Grobeinteilung heißt das: Der Server ist für die Verwaltung der Daten -verantwortlich; mit den Clients werden die Daten lediglich bearbeitet.

Aus der Sicht des Anwendungsprogrammierers sollte Client-Server zunächst bedeuten, daß sich die Anwendung um die technischen Belange zur Pflege des Datenbestandes nicht kümmern muß. Dafür hat sie ihren "Sklaven", den Server. Der Client (Kunde) befiehlt also dem Server (Diener), einen Datensatz zu speichern, zu löschen oder zu finden. Die eigentliche Ausführung findet dann in dem Teil des Systems statt, der ausschließlich für diese Aufgabe existiert.

Es liegt folglich eine starke Ähnlichkeit zwischen der Client-Server-Verarbeitung und der Arbeitsweise objektorientierter Umgebungen vor. Das Ideal von einem "Software-IC" oder einer "Black Box" wird damit theoretisch erreichbar. Dazu kommen die hinlänglich bekannten Vorteile der (Client-Server-Umgebungen hinsichtlich einer optimierten Datenverwaltung: Statt als Datensammelsurium auf verschiedenen Anwender-Workstations ist der Datenbestand in klarer Form mit genau definierten Beziehungen auf den Servern abgelegt.

Um die Verbindung von Client-Server und OOP wirklich nutzen zu können, ist es jedoch erforderlich, eine Programmiersprache der vierten Generation (4GL) einzusetzen. Der Grund liegt in der Forderung nach möglichst vielen Standard-Objekten, die in der Lage sind, miteinander zu kommunizieren.

Diese Objekte stammen möglicherweise von vielen verschiedenen Hersteller. Insofern sind Systemunabhängigkeit beziehungsweise Standards und Normierungen, wie sie zur Zeit in Gremien wie der Object Management Group (OMG) diskutiert werden, dringend geboten.

An Systemunabhängigkeit mangelt es beispeilsweise auch C+ +, der gegenwärtig prominentesten Vertreterin der objektorientierten Programmiersprachen. C + + ist ebenso wie C eine Sprache der dritten Generation und somit vom System abhängig. Das schließt aus, daß die mit ihr entwickelten Objekte auf jeder gewünschten Plattform eingesetzt werden könnten. Es liegt also nahe, die Vorzüge von OOP mit einem wesentlichen Vorzug von Sprachen der vierten Generation zusammenwirken zu lassen, nämlich der Systemunabhängigkeit dieser Sprachen.

Mangels Normierungen für den Nachrichtenaustausch von Objekten untereinander hat die Verallgemeinerung von Programmcode derzeit nur dann Aussicht auf Erfolg, wenn auf allen gewünschten Plattformen die gleiche Ausführungsumgebung für die Objekte verfügbar ist. Der kleinste gemeinsame Nenner spielt dabei eine gewichtige Rolle: Eine zeichenbasierte Benutzer-Schnittstellen (CUI) gibt es für jeden Computer; sie ist auch in grafikorientierter Peripherie (GUI) enthalten.

Umgekehrt funktioniert es leider nicht. Daher muß die Ausführungsumgebung die zeichenbasierten Schnittstellen unterstützen. OOP und 4GLs sind entgegen der landläufigen Auffassung nicht an Grafik gebunden, obwohl eine grafische Unterstützung dem Ansatz selbstverständlich entgegenkommt. Objekte sind abstrakte Datentypen, deren Repräsentation grafisch erfolgen kann, aber nicht muß. Viel wichtiger ist, daß sie auf möglichst vielen Systemen einsetzbar sind.

*Axel Druschel ist Geschäftsführer der Data Access Europe GmbH und der Data Access Deutschland GmbH.