die Tools-Anbieter Anwendungen quasi auf Knopfdruck. Dieser Hoffnung steht jedoch eine stattliche Zahl von fehlgeschlagenen Client-Server-Projekten gegenueber. Der folgende Ueberblick zeigt die Moeglichkeiten und Grenzen moderner Entwicklungs-Tools auf.

Von Roland Strauss*

Der Wunsch der Entwickler nach Rapid Application Development ist verstaendlich. Er bezeichnet den Versuch, Software-Erstellung mit der maximalen Ausnutzung von Computerunterstuetzung zu betreiben. Der Komplexitaet heutiger Softwareprojekte - mit verteilter Datenhaltung, grafischer Benutzeroberflaeche und hoher Parallelitaet - steht eine beschraenkte Aufnahme- und Leistungsfaehigkeit der Programmierer gegenueber. Vom Termindruck ganz zu schweigen.

Eigentlich gehoert ja die Mehrheit der Softwerker ins Amateurlager, sie hat noch nie ein Standardwerk zu ihrer Taetigkeit gelesen. Die Anbieter wissen das, und deshalb sind viele Tools darauf ausgerichtet, einen moeglichst guten ersten Eindruck zu hinterlassen. Nach einigen Wochen stellen sich dann die Probleme ein.

"You hit the wall", wie die Amerikaner sagen.

Um ein RAD-Tool zu bewerten, braucht es schon eine gehoerige Portion Erfahrung. Viele haben noch vor einigen Jahren - nach etlichen Frustrationen in Sachen RAD-Environments - ihre Umgebungen in Pascal geschrieben. Heute sieht die RAD-Landschaft bedeutend besser aus, man kann sich wieder ernsthaft mit diesem Thema beschaeftigen.

In den Anfangszeiten mussten Windows-Programmierer ihre Dialogboxen noch auf Millimeterpapier zeichnen und die Koordinaten selbst einprogrammieren. Heute ist das undenkbar. Visual Basic hat vorgemacht, wie man mit einem Formular und einer Toolbox Masken gestaltet. Die Toolbox enthaelt Gestaltungselemente wie Edit- und Listboxen. Solche Elemente nennt man "Controls". Windows unterstuetzt auch selbstprogrammierte Controls.

Chaos im Hintergrund erschwert die Wartung

Visual Basic fuehrte eine erweiterte Variante ein, die VBX- Controls. Sie sind derart populaer, dass sie auch von den meisten anderen RAD-Systemen verwendet werden koennen.

Gewisse Quellen behaupten, das visuelle Design bedeute 80 Prozent der ganzen Applikation. Das ist natuerlich Unsinn. Die reine Codierung inklusive Masken macht lediglich 20 Prozent des Gesamtprojektes aus. Aber gerade weil das so schnell und einfach geht, verleitet es dazu, chaotische Strukturen im Hintergrund zu schaffen. Dadurch wird die Wartung wesentlich teurer, was die Vorteile schnell zunichte machen kann.

Ein weiteres Problem der visuellen Software-Entwicklung ist die Verschlechterung der Lesbarkeit. Haeufig versteckt sich der Code hinter irgendeinem Element. Ein Tip: Lassen Sie sich ein Beispielprogramm ausdrucken, und versuchen Sie, ob es sich lesen laesst. Es sollte auch moeglich sein, eine Projektdokumentation zu drucken.

Mit der Erfindung der VBX-Controls begann das Zeitalter der Komponenten. Anstatt alles neu zu erfinden, kann der Entwickler jetzt Funktionalitaet nahezu beliebiger Art auf dem Markt erstehen. VBXe sind bequem zu benutzen, aber notorisch fehlerhaft. Legen Sie sich einen Compuserve-Account zu, dann kommen Sie leichter an die Bugfixes heran.

Derzeit ist Microsoft dabei, den verbreiteten De-facto-Standard VBX durch OLE-basierende Technik zu ersetzen, die OCX-Controls. Die Funktionalitaet wird dabei in Form von kleinen OLE-Servern geliefert. Diese Softwarebausteine koennen lokal, auf lange Sicht wohl sogar remote auf dem Server ablaufen.

Microsoft hat ein gewaltiges Stueck Arbeit vor sich, um seine eigenen Office-Applikationen auf diesen Stand zu bringen. Laengerfristig wird es ein System wie MS-Access wohl gar nicht mehr geben. Der Kunde bekommt eine Formular-, Report- und Abfrage- Komponente, gesteuert von C++, Basic oder Pascal. Das Entwicklungssystem hat dann primaer die Aufgabe, Projekte zu organisieren, Komponenten zu verwalten, Versionen aufzubewahren und eine gute Testumgebung bereitzustellen.

Bis wir soweit sind, wird aber wohl noch etwas Zeit vergehen. Zum heutigen Zeitpunkt beklagen sich die Entwickler noch ueber die schlechte Performance und den grossen Ressourcenverbrauch von OLE.

Do it yourself mit Wizzards

Die meisten Hersteller ausserhalb der Microsoft-Gefolgschaft halten sich deshalb an ihren eigenen Komponentenstandard und warten erst einmal ab. Ein weiterer Tip: Lassen Sie sich die Komponentenstrategie erklaeren, auch im Hinblick auf die naechsten Jahre. Achten Sie darauf, dass das System zumindest als OLE-Client voll einsatzfaehig ist. Und fragen Sie nach OCX-Support.

Neben den fertigen Komponenten gibt es auf dem Markt auch Wizzards: spezialisierte Programme, die aufgrund von Parametern selbst Code generieren. Sie helfen vor allem dem noch unerfahrenen Programmierer, Grundbestandteile von Anwendungen zu schaffen, die er dann erweitern und verfeinern kann. Wizzards sind in der Lage, die Erstellungszeit wesentlich zu verkuerzen.

Auf der anderen Seite entsteht so moeglicherweise wieder eine Menge Code, den niemand richtig versteht. Idealerweise raeumt ein Entwicklungssystem die Moeglichkeit ein, Wizzards in seiner eigenen Sprache selbst zu entwickeln und in die visuelle Umgebung einzubauen.

Der wohl meiststrapazierte Begriff im Tools-Marketing ist Objektorientierung. Eine neuere Sprachregelung unterscheidet zwischen objekt- und klassenorientierten Systemen. Visual Basic 3.0 gehoert zur ersten Kategorie, weil es zwar Objekte kennt, diese aber nicht vererben kann. C++, Delphi und Power Builder hingegen sind klassenorientierte Entwicklungssysteme. Hier lassen sich neue Objekte von bestehenden ableiten und erweitern oder modifizieren.

Damit verbunden ist die Moeglichkeit, Daten und Funktionen nach aussen hin zu verstecken. Diese Faehigkeit foerdert die Modularisierung und ist fuer laengerfristige Zeitgewinne aeusserst wichtig. Leider haben viele Programmierer mit dieser Denkweise Muehe, da sie ein strukturiertes Vorgehen erfordert. Untersuchungen behaupten sogar, dass nur 20 Prozent aller Menschen zu klassenorientiertem Denken faehig sind.

Das Projekt-Management braucht hierfuer auch einen laengeren Atem. Haeufig passiert in den ersten Phasen relativ wenig, doch ploetzlich laesst sich die Applikation in wenigen Tagen "zusammenschrauben" und laeuft relativ fehlerfrei.

Stellen Sie sich die Frage: Welche Art von Programmierern habe ich? Ein faehiger Programmierer, der Software klassenorientiert schreiben kann, ist soviel wert wie vier, die das nicht koennen. Ideal ist ein Team, in dem die Gurus die Komponenten schreiben und die Anwendungsfachleute fuer die Applikationen zustaendig sind.

Abstraktion von der Datenbank

Einen wichtigen Aspekt der Anwendungsentwicklung stellt die Unabhaengigkeit von der jeweiligen Datenbank dar. ODBC ist der bekannteste Standard, um per SQL auf Datenbestaende zuzugreifen. Auf diese Weise sollten die Applikationen mit jeder fremden Datenbank ohne Programmaenderung zusammenarbeiten koennen. In der Praxis laesst sich diese Portabilitaet allerdings nur erreichen, wenn man sich auf die einfachen SQL-Befehle beschraenkt.

ODBC steht im Ruf, langsam zu sein - allerdings zu Unrecht. Haeufig ist der ODBC-Treiber schlecht implementiert, oder aber er muss weitreichende Konversionen durchfuehren. Fuer ODBC optimierte Datenbanken wie Informix und Watcom SQL erreichen eine beachtliche Geschwindigkeit.

Auf Client-Server spezialisierte Software-Unternehmen bieten in ihren Produkten zumeist Native-Treiber fuer die bekanntesten Zielsysteme an. Sie lassen sich diese Add-ons in der Regel jedoch ziemlich teuer bezahlen.

Bislang nur wenige Compiler-Werkzeuge

RAD-Tools arbeiten meist interpretativ und sind daher nicht besonders schnell. Hinzu kommt ein beachtlicher Ressourcenverbrauch. Auch wenn das Tempo zu Beginn eines Projekts nicht ins Gewicht faellt, waechst es sich spaeter oft zu einem Problem aus.

Erst mit Delphi und Visual Foxpro bietet der Markt RAD-Werkzeuge mit Compilern an. Bei grossen Projekten oder fuer Branchenloesungen sollten Sie diesem Aspekt Rechnung tragen.

Erlaubt ein System keine Vererbung, belastet das die Geschwindigkeit zusaetzlich. Die Komponenten muessen dann wiederholt "zurechtgebogen" werden.

Als Koenigsdisziplin der RAD laesst sich wohl die Reintegration von Komponenten bezeichnen: Den Gipfel der Produktivitaet erreicht der Entwickler dann, wenn er selbsterstellte Komponenten wieder so ins System integrieren kann, dass sie quasi ein natuerlicher Bestandteil davon werden. Die Umgebung muss dazu das Softwareteil assimilieren und alle Automatismen in der gewohnten Form bereitstellen. Nextstep hat das mit dem Interface Builder vorgemacht, bislang wurde dieses Beispiel jedoch ueberraschend selten nachgeahmt. Erst Borland hat dieses Prinzip mit Delphi wiederaufleben lassen, und es steht zu hoffen, dass andere Anbieter folgen werden.

Im folgenden seien einige populaere RAD-Tools mit ihren Vor- und Nachteilen beschrieben: Da waere zunaechst Microsoft Access. Es gibt kein anderes Softwarepaket, das mit so vielen Wizzards und attraktiven Objekten bestueckt ist. Poweruser koennen damit ohne jede Programmierung anspruchsvolle Aufgaben loesen und ueberzeugende Dokumente generieren. Der schnelle Anfangserfolg verleitet aber haeufig dazu, Access als professionelles Entwicklungswerkzeug zu verwenden. Und damit kommt man schnell in Teufels Kueche.

Der Grund hierfuer liegt in der chaotischen Objektstruktur von Access. Die Objekte sind nicht nach anwendungsorientierten Beduerfnissen, sondern nach einem Objektalphabet organisiert. Es faellt dadurch aeusserst schwer, im nachhinein die Funktionsweise eines Programms zu ergruenden. Die Objekte lassen sich weder vererben noch erweitern, ja nicht einmal nach aussen hin abschirmen. Die Kreuzundquerverbindungen werden somit unkontrollierbar. Viele Entwickler berichten zudem ueber Performance-Probleme und Schwierigkeiten mit der Stabilitaet im Netz.

Der Prototyp aller Windows-basierten RAD-Tools ist Visual Basic. Das Werkzeug ist in einer vernuenftigen Zeit beherrschbar, durch die bereits erlaeuterten VBXe laesst es sich erweitern, und es geniesst grosse Unterstuetzung im Markt. So wie es aus der Packung kommt, ist VB allerdings recht unvollstaendig, Zusatz-Tools muessen teuer bezahlt werden.

Mehr Probleme als angenommen

Datenbankgebundene Controls sind ausserdem in einem echten Client- Server Umfeld ausgesprochen langsam. Experten empfehlen deshalb den Verzicht auf diese Technik. Damit buesst der Entwickler jedoch gleichzeitig viele Vorteile des RAD-Ansatzes ein. Das Problem liegt in der zugrundeliegenden Jet-Engine. Microsoft weiss davon und hat Besserung versprochen.

Wie in Access lassen sich auch in VB keine Objekte vererben. Visual Basic 4.0 wird allerdings wesentlich besser bestueckt sein, und es geht bereits das Geruecht um, die Vererbung werde in dieses Release endlich doch Einzug halten. Fazit: Visual Basic verursacht wesentlich mehr Probleme, als man gemeinhin annimmt, aber der Tool-Markt haelt mittlerweile fuer fast jedes dieser Probleme eine Loesung bereit.

Besonders in Grossunternehmen hat sich Power Builder einen Platz erobert. Zu verdanken hat es diese Akzeptanz seiner klaren Ausrichtung auf den professionellen Client-Server-Markt. Mehr als jedes andere Tool ist es dem Programmierer mit visueller Unterstuetzung behilflich. Deshalb koennen es die Anwenderunternehmen auch wagen, ihre alten Cobol-Programmierer darauf anzusetzen.

Power Builder verfuegt ueber eine Vielzahl von Editoren, von denen die "Data Windows" besonders erwaehnenswert sind. Sie visualisieren Datenbestaende als Formulare oder Listen, sind aeusserst leistungsfaehig, aber auch recht komplex. Als eines von wenigen Tools verfuegt Power Builder ueber eine Art Data-Dictionary mit erweiterten Attributen fuer jedes Datenelement.

Messlatte fuer andere Tools

Zudem lassen sich Objekte mit Power Builder sowohl vererben als auch kapseln. Zu bemaengeln ist allenfalls eine Ueberbetonung der Vererbung von Formularen. Der Datenbankzugriff erfolgt hier ueber Native-Treiber oder ODBC. In letzter Zeit geriet Power Builder allerdings wegen Qualitaetsproblemen unter Beschuss. Es geht der Witz um, die Fehlermeldung GPF bedeute "Great Power Builder Feature".

Erst seit ein paar Monaten auf dem Markt ist Delphi. Zieht man diese Tatsache ins Kalkuel, so muss der Erfolg dieses Werkzeugs schon fast als sensationell eingestuft werden. Delphi kombiniert das Beste aus mehreren Welten: Zum einen bietet es eine Umgebung, die Visual Basic zum Verwechseln aehnlich sieht. Zum anderen handelt es sich um einen vollstaendigen Pascal-Compiler mit Erweiterungen speziell fuer visuelle Umgebungen.

Die Komponenten muessen nicht in C, sondern koennen direkt in Delphi-Pascal programmiert werden. Sie lassen sich einfach in die Toolbar reintegrieren - mitsamt aller verbundenen Editoren und dem Help-File. Diese Struktur ist der Aufteilung eines Teams in Komponenten- und Anwendungsprogrammierern foerderlich, ausserdem laesst sie den Markt fuer Komponenten schnell aufbluehen. Mit 75 Programmteilen in der Grundversion ist Delphi aber schon von Haus aus besser ausgestattet als jedes andere Werkzeug.

Ueber Geschwindigkeit und Stabilitaet wird viel Gutes berichtet. Probleme hat Delphi primaer auf Nebenschauplaetzen. Fuer die Verteilung einer Datenbankapplikation muss der Anbieter zwei Disketten mit der Runtime-Version seiner "Borland Database Engine" mitliefern. Diese Engine ist manchen Entwicklern ein Dorn im Auge, ein schnoerkelloser ODBC-Zugriff waere ihnen lieber. Darueber hinaus laesst die Dokumentation im Grundpaket zu wuenschen uebrig, vor allem fuer Pascal-Neulinge. Trotzdem: Delphi ist heute das RAD-Werkzeug, an dem sich die anderen Tools messen lassen muessen.

*Roland Strauss ist Geschaeftsfuehrer der Philog AG mit Sitz im schweizerischen Unterlunkhofen. Das Unternehmen vertreibt Client- Server-Tools und Komponenten. Strauss ist unter der Compuserve- Adresse 1000,343165 zu erreichen.