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.

21.10.1994

Mageres Tool-Angebot fuer komplexe Client-Server-Anwendungen Entwicklungsmethode haengt von Reichweite und Bedeutung ab

Von Michael Bauer*

Nur wenige 4GL-Tools eignen sich fuer komplexe Anwendungen. Deshalb haben Cobol und C trotz der Vielfalt an Entwicklungswerkzeugen hier auch bei einer Client-Server-Umgebung die Nase vorn. Bei Quick-and-dirty-Loesungen oder grafischen Benutzeroberflaechen bieten neue Tools und Programmiermethoden wie Objektorientierung und Prototyping allerdings Vorteile.

Client-Server ist die Architektur, die benoetigt wird, um operative Anwendungen auf Basis verteilter Systeme zu realisieren. Dabei ist die Verteilung von Applikationen ueber mehrere Rechner wegen der damit verbundenen Probleme keineswegs Selbstzweck. Vielmehr nimmt man den Mehraufwand gegenueber einer Zentralrechnerloesung in Kauf, um:

- dezentrale Unternehmensbereiche durch Verarbeitung vor Ort besser unterstuetzen zu koennen;

- durch Verlagerung der Verarbeitung auf kleinere preisguenstigere Rechner Kosten zu sparen - was selten gelingt - und

- durch den Einsatz von PCs als Arbeitsplatzrechner qualitativ anspruchsvollere DV-Loesungen zu schaffen.

Zu letzterem gehoeren eine bessere Ergonomie durch grafische Benutzeroberflaechen (GUI) sowie ganz neue Anwendungsloesungen durch die Integration operativer Systeme mit Textverarbeitung, Image- Processing und Multimedia. Damit betreten die meisten Applikationsentwickler Neuland. Gegenueber bisherigen Terminalanwendungen stellt eine Client-Server-Loesung folgende zusaetzliche Anforderungen:

- Aufteilung der Anwendung in Client- und Server-Komponenten;

- Schaffung einer GUI-Oberflaeche;

- Realisierung der Kommunikation zwischen Client- und Server- Komponenten;

- Integration von Desktop-Tools, Buerosystemen und Multimedia- Komponenten in die Anwendung sowie

- Aufbau eines offenen Systems - also der Unabhaengigkeit der Anwendung von Softwarekomponenten wie Betriebssystem, Window- Manager, Datenbanksystem oder TP-Monitor.

Client-Server-Anwendungen sind nicht von vornherein offen - also herstellerunabhaengig -, wie manche glauben, sondern ebenfalls wieder in einer proprietaeren Umwelt eingebunden. Wenn man die bisherige Abhaengigkeit von IBM nicht gegen eine neue Abhaengigkeit von Microsoft eintauschen will, muss man besondere zusaetzliche Anstrengungen unternehmen. "Offene Systeme" stellen also eine Steigerung von

"Client-Server" dar.

Im Zusammenhang mit Client-Server herrscht noch die Erwartung vor, dass die Anwendungsentwicklung viel einfacher und schneller wuerde. Doch das trifft nicht zu. Zum einen gibt es keinen Grund, warum fuer eine bestimmte betriebswirtschaftliche Funktion wie zum Beispiel Buchhaltung weniger Zeilen Code benoetigt werden, nur weil die Anwendung auf einem PC ablaeuft. Bei gleicher Funktionsqualitaet ist der Programmieraufwand fuer alle Rechnergroessen gleich. Darueber hinaus erhoeht sich der Programmieraufwand sogar gravierend, wenn statt einer Terminaloberflaeche eine komfortable GUI-Oberflaeche entwickelt werden muss.

Hier koennen nur Tools diesen Mehraufwand wieder einigermassen kompensieren helfen. Doch was bieten diese Tools? Grundsaetzlich laesst sich zwischen drei Kategorien unterscheiden:

- Realisierung nur der GUI-Oberflaeche: Hierzu zaehlen die sogenannten User-Interface-Management-Systeme wie "ISA Dialogmanager", "Grit plus", "Visual Basic", "XVT" etc.;

- Entwicklung von PC-Anwendungen mit GUI: Hierfuer gibt es ein breites Spektrum von Produkten wie "Powerbuilder",

"Oracle-Forms", "Axiant", "Rosi-SQL", "Ingres/Windows", "SQL/

Windows", "Uniface" und viele andere mehr. Neben diesen Sprachen der vierten Generation (4GL) fallen in diese Kategorie auch OO- Tools wie "Enfin", "Viasual Age", "mic Wop" etc.;

- Entwicklung komplexer Client-Server-Anwendungen: Hierzu werden Tools benoetigt, mit denen man nicht nur den Front-end-Teil, sondern auch Server-Komponenten programmieren kann. Diese Tools muessen deshalb auch eine Programm-zu-Programm-Kommunikation enthalten. In diesem Bereich gibt es nur wenige Vertreter, etwa "Natural New Dimension", "ABAP/4" oder Generatoren wie "APS" und "IEF". Zwar lassen sich solche Loesungen auch mittels Trigger und Stored Procedures von Datenbanksystemen schaffen, doch bieten nur wenige DB-Systeme diese Funktionalitaet. Zudem werden Anwendungen damit fest an das DBMS gekoppelt, da die Programmierung in der Sprache des jeweiligen DBMS erfolgt.

Welche Tool-Kategorie benoetigt wird, haengt von der Gestaltung der Client-Server-Architektur ab. Es gibt einfache Systeme, bei denen die gesamte Verarbeitung auf dem PC ablaeuft und nur die Datenzugriffe an einen zentralen Datenbank-Server gesandt werden. Eine solche Loesung reicht fuer eine Anwendung in einem LAN mit weniger Arbeitsplaetzen aus.

Aufgrund der Flut von Nachrichten, die durch die SQL-Befehle entsteht, empfiehlt sich dieses Konzept bei einer grossen Anzahl von Arbeitsplaetzen oder Zugriffen auf den DB-Server ueber ein WAN aber nicht.

In diesen Faellen teilt man die Funktionalitaet der Anwendung auf. Ein substantieller Teil, der im wesentlichen den Dialog mit dem Benutzer umfasst, laeuft auf dem Front-end-Rechner ab, waehrend die Verarbeitung und Datenverwaltung auf einem Server-System stattfindet. Diese mehrschichtige Architektur (englisch "multi- tier" genannt) ist fuer Bereichsapplikationen mit einem lokalen Server und fuer unternehmensweite Anwendungen mit zentralem Server gleichermassen geeignet und damit das universelle Konzept fuer Client-Server-Loesungen.

Quick and dirty oder Mission-critical?

Ein weiterer Aspekt der Tool-Auswahl betrifft Reichweite und Bedeutung einer Applikation. Es besteht ein Unterschied, ob eine firmenweite oder eine kleine Anwendung entwickelt werden soll, die nur einen oder wenige Mitarbeiter betrifft und nicht von lebenswichtiger Bedeutung fuer das Unternehmen ist. Beispiele dazu koennen sein: Verwaltung des Bueromaterials, Besucherkartei oder Kantinenabrechnung. Solche Programme lassen sich schnell mit "MS Access" oder "Visual Basic" schreiben.

Anders sieht es dagegen bei unternehmensweiten "Mission-critical"- Anwendungen aus. Damit sind zum Beispiel die Kontofuehrung bei einer Bank, die Auftragsverwaltung, Lagerbestandsfuehrung oder Fertigungsplanung gemeint. Hier sind unter anderem Stabilitaet, Sicherheit, ordentliche Dokumentation, Strukturierung, Wartbarkeit, Integration mit Data Dictionary gefragt - kurz: eine "professionelle Anwendungsentwicklung".

In diesem Umfeld entstehen komplexe Dialog- aber auch Batch- Programme. Fuer diese Anforderungen muessen 4GLs ausgelegt sein, wenn sie Cobol oder C den Rang ablaufen wollen. Und das koennen nicht viele.

Mit der Positionierung einer Applikation zwischen einer Einzelplatzloesung auf der einen und einer unternehmensweiten auf der anderen Seite steigt der Anspruch an Professionalitaet in der Anwendungsentwicklung.

GUI: Die Interaktion ist von grosser Bedeutung

Die meisten der vielen hundert Produkte, die diesbezueglich angeboten werden, eignen sich fuer PC-Programme mit mehr oder weniger guter GUI-Unterstuetzung. Die wenigsten lassen sich aber fuer eine professionelle Anwendungsentwicklung fuer unternehmensweite Client-Server-Loesungen einsetzen. Deshalb sind die meisten grossen Client-Server-Programme fast ausschliesslich in Cobol oder C realisiert.

Obwohl "GUI" als grafische Benutzeroberflaeche uebersetzt wird, steckt mehr dahinter als nur eine oberflaechliche Veraenderung des Bildschirmlayouts. Mittels 3D-Darstellung, Pulldown-Menues, Radio- Buttons und Select-Boxes laesst sich das Gefuehl eines GUI vermitteln. Doch wenn die Interaktion zwischen Mensch und Maschine wie zum Beispiel bei SAP R/3 nur bildschirmweise erfolgt, dann ist dies kein richtiges GUI, sondern nur eine "GUIfizierung".

Grafische Oberflaechen erfordern Prototyping

Richtige GUI-Loesungen gehen darauf ein, dass jeder Tastendruck oder Mausklick des Benutzers abgefangen und behandelt werden kann. Dadurch ergeben sich feldweise Operationen wie Datenpruefung, Benutzerunterstuetzung und -fuehrung. Zusaetzliche Boxen oder Windows lassen sich dann kontextabhaengig dynamisch oeffnen. Zugleich stehen dem Benutzer - anders als bei Bildschirmanwendungen - mehrere Windows zur Verfuegung, die objektbezogen konzipiert sind: etwa ein Fenster fuer die Kundendaten, eins fuer den Auftrag, eins fuer den Artikel etc.

Kurzum: Das GUI ermoeglicht eine andersartige, wesentlich dynamischere Gestaltung der Mensch-Maschine-Interaktion. Dies betrifft neben der Oberflaeche - also das Layout - insbesondere den Ablauf. Aber gerade letzteres laesst sich nicht einfach auf dem Papier entwickeln und auf diese Weise mit dem Benutzer abstimmen. Die Konsequenz ist, dass GUI-Oberflaechen ueber eine Erprobung modelliert werden muessen - also ueber "Prototyping".

Hier beweisen interpretative Systeme ihre Staerke. Zwischen Entwurfs- und Ausfuehrungsebene laesst sich im Handumdrehen umschalten, so dass der Entwickler zusammen mit dem Benutzer jede Veraenderung sofort umsetzen und ausprobieren kann.

Prototyping beschraenkt sich nicht auf PCs

Noch einen Schritt weiter geht die Modellierung der gesamten Anwendungslogik mittels Prototyping. Hier spricht die Werbung gern von "Rapid Application Development" und moechte uns glauben machen, dies sei eine Besonderheit neuer Tools. Das ist falsch: Anwendungsentwicklung mittels Prototyping ist weder an bestimmte Produkte noch an PCs gekoppelt. Dass dies auch auf einem Mainframe erfolgreich moeglich ist, beschrieb Dr. Thorsten Spitta von Schering schon vor fast zehn Jahren. Auf dem "Software-Forum '85" stellte er die Erfahrungen seines Unternehmens mit Prototyping vor:

- 30 Prozent Reduzierung der Analyse- und Designphase;

- 15 bis 20 Prozent Reduzierung der Programmierphase sowie

- 25 Prozent Reduzierung des Einfuehrungsaufwands.

Diese Ergebnisse wurden mit der 4GL "Natural" erzielt. Mit einem objektorientierten Ansatz lassen sich diese Effekte noch steigern.

Tools ermoeglichen offene Systeme

Fuer Client-Server-Anwendungen ist mindestens ein Tool fuer das GUI erforderlich, das den Programmieraufwand und die Komplexitaet verringern hilft. Damit besteht zugleich auch die Chance einer Unabhaengigkeit von den verschiedenen Window-Managern wie Windows 3.x, OSF/Motif, OS/2 Presentation Manager, Macintosh.

Sowohl GUI-Tools als auch Sprachen der vierten Generation bieten eine einheitliche und portable Programmierung fuer verschiedene Window-Manager an - allerdings haeufig noch sehr eingeschraenkt.

Ebensowichtig ist die Unabhaengigkeit bei der Programm-zu-Programm- Kommunikation zwischen Client und Server. Nicht nur, dass sich die Programmierung der Protokolle wie Named Pipes, Netbios, TCP/IP- Sockets, CPI-C etc. sehr aufwendig gestaltet, sie sind auch nicht miteinander kompatibel.

Wer also eine offene, unabhaengige Anwendung haben moechte, kommt um den Einsatz einer Middleware nicht herum. Diese Kommunikationskomponente kann entweder in Form eines selbstaendigen Produkts wie "DCE-RPC" und "Entire Broker" vorliegen oder in eine Laufzeitumgebung wie bei "CICS", "Natural" oder "SAP R/3" eingebettet sein.

Weiterhin ist fuer die Offenheit der Anwendung erforderlich, dass die Programmiersprache ueber mehrere Betriebssysteme hinweg portabel ist. Bei Cobol oder C stellt das nur ein geringes Problem dar. Anders dagegen bei 4GLs oder OO-Tools, die oft nur auf einem oder wenigen Betriebssystemen ablauffaehig sind. So unterstuetzen beispielsweise von 15 marktrelevanten 4GLs alle Windows 3.x, aber nur je drei Produkte OS/2 oder den Macintosh. Auch nuetzt die Aussage, dass eine Sprache auf Unix ablauffaehig ist, noch gar nichts. Es kommt darauf an, welche der vielen Unix-Derivate unterstuetzt werden.

Auch die DBMS-Abhaengigkeit der Sprachen gehoert auf die Problemseite. Werkzeuge wie "Ingres/Windows-4GL" oder "Informix- 4GL" lassen sich nur gemeinsam mit dem DBMS des gleichen Herstellers betreiben. Andere Produkte dagegen ermoeglichen durch eine Vielzahl von DB-Interfaces eine Zusammenarbeit mit verschiedenen Datenbanken. Inzwischen wird diese Huerde durch generalisierte Gateways wie ODBC niedriger. Doch ODBC nuetzt wiederum nur den Programmen, die unter Windows laufen.

Die Entwicklung von Client-Server-Anwendungen wird mit 4GLs oder OO-Tools sicherlich erleichtert. Allerdings sind nicht alle Tools gleichwertig; das bezieht sich sowohl auf das Einsatzspektrum, die Unterstuetzung professioneller Anwendungsentwicklung, die Unterstuetzung aller GUI-Funktionen und die Portabilitaet. Doch die hauptsaechlichen Anforderungen an die Client-Server-Programmierung werden sowieso nicht durch den Einsatz von Tools geloest. Erforderlich sind eine saubere Modularisierung der Client-Server- Anwendungen, um beliebig kombinierbare Funktionsbausteine zu erhalten, und die Schaffung einer benutzergerechten GUI- Oberflaeche.