Wer sich bei der Entwicklung grafischer Oberflaechen auf die DBMS- spezifischen Entwicklungs-Tools der Datenbankhersteller verlaesst, landet leicht in einer Sackgasse, warnt Rainer von Ammon*. User- Interface-Manage- ment-Systeme (UIMS) bieten ebenfalls komfortable Programmiermoeglichkeiten - jedoch bei geeigneter Tool-Auswahl ohne den Nachteil eingeschraenkter Portabilitaet und Interoperabilitaet. Der nachfolgende Beitrag zeigt die Einsatzmoeglichkeiten von UIMS mit ihren Vor- und Nachteilen auf.

Bei der Applikationsentwicklung ergeben sich in drei Bereichen Probleme, die unter den Gesichtspunkten der Portabilitaet und der Interoperabilitaet kompetent geloest werden muessen: bei der grafischen Benutzer-Schnittstelle (Graphical User Interface = GUI) sowie der Datenverwaltung und der Kommunikation. Portabilitaet bedeutet dabei, dass die Applikation nicht auf eine Rechnerplattform, ein Betriebssystem und ein Window-System festgelegt ist. Unter Interoperabilitaet versteht man die Unabhaengigkeit der Applikation von einem Datenbanksystem und im Fall einer Client-Server-Architektur von den spezifischen Eigenschaften eines Netzes.

Nur wenige GUI-Tools ermoeglichen Portabilitaet

Vor diesem Hintergrund steht die Wahl eines Entwicklungswerkzeug. Die einfachste, aber vielleicht auch folgenschwerste Entscheidung waere die fuer die proprietaeren Entwicklungs-Tools eines Datenbank- Management-Systems (DBMS), die haeufig auch Werkzeuge fuer die Erstellung grafischer Oberflaechen zur Verfuegung stellen (zum Beispiel "SQL Forms" von Oracle) und die Implementierung der Anwendungslogik mit einer - natuerlich wieder proprietaeren - 4GL zu realisieren.

Die Applikation ist dann so portabel, wie es die Entwicklungsumgebung des DBMS erlaubt - vor allem die Window- Systeme machen dieser Loesung erhebliche Probleme. Sie ist ausserdem nur stark eingeschraenkt interoperabel; die Interoperabilitaet beschraenkt sich naemlich auf das gewaehlte DBMS, sofern es eine Client-Server-Architektur unterstuetzt.

Als nur bedingt komfortabel sind auch die Moeglichkeiten in bezug auf grafische Benutzer-Schnittstellen zu bezeichnen. Die Entwicklungswerkzeuge unterstuetzen meist nur eine limitierte Zahl an GUI-Objekten. So muessen SQL-Forms-Anwender auf Comboboxen, Drop-Down-Listboxen etc. verzichten, auch SAP R/3 stellt solche Objekte derzeit unter MS-Windows nicht zur Verfuegung. Oder es werden alle GUI-Objekte eines bestimmten Window-Systems unterstuetzt, dann aber zu Lasten der Por- tabilitaet, beispielsweise bei "SQL Windows" von Gupta. Einen anderen Loesungsweg eroeffnet ein User-Interface-Management-System, mit dem sich in der Regel komfortable GUIs portabel implementieren lassen.

Ein UIMS mit Anspruch auf Portabilitaet liefert zum Beispiel fehlende OSF-Motif-Widgets (so heissen die Oberflaechenobjekte beim X-Window-System) nach und stellt nicht nur eine Durchschnittsmenge an Window-Typen und Controls (das sind die Oberflaechenobjekte bei MS-Windows) zur Verfuegung. Obwohl es auf dem internationalen Markt mehr als 50 GUI-Tools gibt, fallen bei derartigen Portabilitaetsanspruechen die meisten, besonders die DBMS- proprietaeren Werkzeuge durch das Auswahlraster. Uebrig bleiben nur ein paar UIMS wie die beiden deutschen Produkte "ISA Dialog Manager", "UIMS Rapid" oder die aus den USA stammende Loesung "Open Interface".

Ein UIMS realisiert aber nicht nur das Praesentationslayout, das sich teilweise portabel auch ueber die Dialog-Editoren der Oberflaechenbaukaesten und Klassenbibliotheken wie "Starview" oder "Zapp und Zink" erstellen laesst. Mit einem UIMS kann vielmehr darueber hinaus der gesamte Kontrollfluss einer Applikation implementiert werden, ohne dass man hierfuer in einer Host-Sprache wie C oder C++ programmieren muss.

Die Loesungskonzepte der einzelnen UIMS unterscheiden sich in diesem Punkt allerdings erheblich: Meist muss eine herstellerspezifische Skript-Sprache erlernt und der Kontrollfluss in dieser spezialisierten High-Level-Sprache programmiert werden. Beispiele hierfuer sind das portable Produkt "JAM" mit der Sprache JPL, die allerdings keine Programmierung dynamischer Dialoge erlaubt (kontextabhaengiges Hinzufuegen, Loeschen, Sperren von Oberflaechenobjekten), der ISA Dialog Manager oder das nicht portable Tool "Tele Use" mit der Sprache d. Das UIMS "Rapid" geht dagegen noch eine Abstraktionsstufe hoeher und verlagert die Kontrollfluss-Implementierung in einen grafischen Editor. Dort wird mitgeteilt, was bei welchen Events, die als Ereignisbaeume an den Oberflaechenobjekten haengen, passieren soll.

Daneben gibt es Tools, die Coderuempfe zur Weiterentwicklung, zum Beispiel fuer C oder C++, erzeugen. Diese Produkte koennen wegen ihres niedrigen Abstraktionslevels und ihrer beschraenkten Try-Modi oder Rapid-Prototyping-Moeglichkeiten nicht den UIMS zugerechnet werden.

Mit einem entsprechenden UIMS laesst sich ein portables Praesentationslayout erstellen, das in Form einer eigenen Schicht von der eigentlichen Applikation abgetrennt ist - das gleiche gilt fuer den Kontrollfluss und die Implementation eines Dialog- und Aktionsnetzes. Die Connectivity, also der Zugriff auf die Daten, muss jedoch spaetestens in der dritten Schicht ermoeglicht werden.

Abgesehen von den DBMS-spezifischen Werkzeugen bieten sich fuer den Datenzugriff verschiedene Moeglichkeiten, die ihre spezifischen Vor- und Nachteile besitzen:

-ISAM-Bibliotheken:

Bei ISAM-Bibliotheken, die fuer eine Host-Sprache wie C vorliegen, handelt es sich um die niedrigste Ebene, auf der sich Daten mit gerade noch vertretbarem Aufwand verwalten lassen. Sie zeichnen sich jedoch - oder gerade deshalb - durch eine sehr gute Performance bei den Datenbankzugriffen aus. Wie bei allen niedrigen Programmierebenen ist der Codierungsaufwand fuer den Entwickler gross, wenngleich die wichtigsten Aufgaben durch zahlreiche Funktionen unterstuetzt werden.

Die Applikation ist portabel, falls die ISAM-Bibliothek auf den gewuenschten Plattformen zur Verfuegung steht. Fuer MS-Windows wird sie zum Beispiel als Dynamic Link Library (DLL) benoetigt. Man muss die Applikation jedoch fuer jede Plattform neu uebersetzen und binden, da zwischen den Plattformen keine Binaerkompatibilitaet besteht und andere Bibliotheken dazugebunden werden muessen; es sollte aber nicht erforderlich sein, den Sourcecode nennenswert zu aendern. Hinsichtlich der Interoperabilitaet ist die Loesung allerdings nur sehr beschraenkt geeignet, da fuer jeden Datenbanktyp und jedes Netz eigene Module zu schreiben sind.

-Host-sprachliche Bibliotheken fuer Datenbanksysteme:

Viele DBMS bieten eine Schnittstelle zu Programmiersprachen der dritten Generation wie C (zum Beispiel "Informix"). Fuer die verbreitetsten Datenbanksysteme - alle Xbase-Datenbanken wie "Dbase", "Foxpro" oder "Clipper" - sind spezielle C-Bibliotheken erhaeltlich, die es ermoeglichen, mit aehnlichen Aufrufen wie beim Original-DBMS die Datenbank zu verwalten ("seek" von Dbase entspricht "d4seek" von "Codebase" etc.). Dazu gehoeren Codebase, "db Vista" beziehungsweise "Raima Database Manager" oder die "Greenleave Database Library".

Diese C-Bibliotheken liefern bei Datenbankzugriffen eine wesentlich bessere Performance und lassen sich in die C-Programme einer Applikation gut und flexibel integrieren. Der Entwickler hat alle Vorteile - aber auch die Nachteile - einer kompakten C- Programmierung mit schnellem Code. Gegenueber den ISAM-Bibliotheken besteht der Vorteil darin, dass die Anweisungen und entsprechenden Wirkungen mit denen der originalen DBMS weitestgehend identisch sind. C-Bibliotheken gibt es meist fuer mehrere Plattformen, zum Beispiel fuer DOS mit und ohne Windows sowie fuer Unix mit oder ohne OSF/Motif. Unterstuetzt die Bibliothek die gewuenschte Connectivity- Architektur, kann native auf den angesprochenen Datenbanktyp (im einfachsten Fall Xbase-Datenbanken) zugegriffen werden.

Diese Bibliotheken besitzen zudem oft Erweiterungen fuer SQL- Abfragen. So kann zum Beispiel die Client-Server-Version des "Hercules"-DBMS von der Frankfurter APIS GmbH mit "CQL" von der Machine Independent Software Corp. kombiniert werden. Viele dieser Pakete wie Hercules oder der "Raima Database Manager" von der Nuertinger ESM Software GmbH verfuegen auch ueber eine ODBC- Schnittstelle. In Verbindung mit einem portablen UIMS lassen sich so bei einer Applikation nicht nur sehr performante DB-Zugriffe, sondern auch ein hohes Mass an Portabilitaet und Interoperabilitaet erreichen.

-Embedded SQL (ESQL):

Viele DBMS bieten eine Implementierung von Embedded SQL an, etwa Informix oder "Oracle". Die ESQL-Anweisungen werden in die Host- sprachlichen Prozeduren eingefuegt und durch einen Precompiler verarbeitet. Es muss wegen der Maechtigkeit der SQL-Befehle verhaeltnismaessig wenig codiert werden, solange man nur ein DBMS unterstuetzt. Ausserdem ist die Performance der ESQL-Befehle gegenueber herkoemmlichen SQL-Befehlen erheblich besser. Applikationen, die auf SQL-faehige Datenbanken zugreifen muessen, werden seit Jahren typischerweise unter Verwendung von ESQL entwickelt, da es nicht nur effiziente Datenbankzugriffe erlaubt, sondern auch fuer viele Plattformen portabel verfuegbar ist.

Trotzdem ist ESQL nicht gut geeignet, wenn Daten verarbeitet werden, die in Datenbanken verschiedener DBMS wie "RDB", "DB2" oder Oracle gespeichert sind. In diesem Fall muss die Applikation naemlich einmal mit dem DEC-, dann mit dem IBM- und schliesslich mit dem Oracle-Precompiler voruebersetzt werden, was zu einem zunehmend unueberschaubaren Codierungs- und Verwaltungsaufwand fuehrt.

-Open Database Connectivity (ODBC):

Bei ODBC handelt es sich um einen Connectivity-Standard von Microsoft, der einen neuen Ansatz des Datenbankzugriffs bietet: Er wird ueber separate Programme realisiert, sogenannte Datenbanktreiber fuer die verschiedenen DBMS in Form von DLLs. Die Applikation verwendet in ihren C-Funktionen die Aufrufe des ODBC- APIs, die denen von ESQL sehr aehnlich sind. Die ODBC-Software nutzt ein Call-Level-Interface (CLI), das die Applikation anders als bei ESQL oder den anderen oben genannten Loesungen von den Unterschieden der Netz- und Datenbanksoftware abschirmt. Ein ODBC- Treiber-Manager, der als DLL der Applikation hinzugefuegt wird, laedt automatisch den entsprechenden Datenbanktreiber, ueber den dann der Datenbankzugriff erfolgt.

ODBC ist Bestandteil von MS-Windows, Visual C++, Visual Basic oder Access und wird in Zukunft gegebenenfalls auch in anderen Microsoft-Produkten integriert sein. Der groesste Nachteil der ODBC- Loesung liegt derzeit darin, dass ihr Einsatz auf MS-Windows- Applikationen beschraenkt ist, wenngleich die Datenbanken auch auf Grossrechnern oder Workstations installiert sein koennen.

Bei dem abgebildeten Listing handelt es sich um ein Beispiel auf der Basis des ODBC-APIs. Erfreulicherweise bedarf es hier wegen des CLIs nicht der umstaendlichen mehrstufigen Uebersetzung wie im Fall von ESQL. Ein Modul fuer eine bestimmte Aufgabe gibt es nur einmal und nicht in verschiedenen Ausfuehrungen fuer jedes DBMS und jedes Netz. Die Interoperabilitaet regeln die ODBC-Treiber, die bereits fuer die meisten DBMS erhaeltlich sind. Spezialisiert auf solche Treiberbibliotheken ist zum Beispiel die Firma Q+E in USA, bei der auch Informix seinen ODBC-Treiber herstellen laesst.

Wie bei jeder neuen Technologie gibt es noch einige Haken und Oesen, aber die Entwicklung laesst schon Eigendynamik erkennen: Drittanbieter wittern in ODBC einen Markt. So werden sich die Treiber bald auch im Zusammenhang mit komplizierteren Client- Server-Architekturen und speziellen DBMS-Eigenschaften stabilisieren. Ende 1994 wird die Version 2.0 von ODBC erwartet.

Drittanbieter springen auf den ODBC-Zug auf

Nach Auskunft von Microsoft ist auch der Sourcecode von ODBC erhaeltlich, weshalb Portierungen auf andere Plattformen bald zu erwarten sind. Dies wuerde zu paradiesischen Zustaenden fuehren: Performante ODBC-Treiber fuer alle Datenbank- und Netzsysteme, gepaart mit einem fuer alle Plattformen portablen UIMS.

Zusaetzlich koennen Standardsituationen wie Auf- und Abbau der Verbindung zur Datenquelle, Blaettern in den Datensaetzen, Einfuegen, Aendern, Loeschen und Suchen zu vorgefertigten "eingefrorenen" Objekten verallgemeinert werden. Ausserdem laesst sich der Sourcecode automatisch vom UIMS generieren.

Um dem Entwickler einen moeglichst hohen Komfort und trotzdem maximale Flexibilitaet zu bieten, stellt ein maechtiges UIMS drei Moeglichkeiten der Datenbankanbindung zur Verfuegung:

1. Fertige Dialog-Templates und spezielle Oberflaechenobjekte mit einem Definitionsdialog fuer die Parametrierung zum Beispiel der SQL-Anweisungen und der notwendigen Host-sprachlichen Funktionen.

Vorgefertigte Dialoge oder Dialogfolgen (Templates) werden ueber den UIMS-Editor angeboten. Diese komplexen oder atomaren Oberflaechenobjekte lassen sich auch in Tool-Boxen, das heisst nichtmodalen Dialogboxen, langfristig beim Definitionsdialog zur Verfuegung stellen. Die Objekte werden dann etwa im Drag-and-drop- Verfahren den entsprechenden Ereignissen zugeordnet.

Im zweiten Schritt muss der Entwickler festlegen, welche Attribute der Dialog benoetigt. Im Beispiel eines "Suchen"-Dialogs muessten etwa die Suchaspekte spezifiziert werden.

Bei einer relationalen Datenbank sind das Attribute von Relationen. Diese Suchaspekte koennen aus einer Liste ausgewaehlt und einem Objekt, etwa einer Drop-down-Combobox, zugeordnet werden.

Bei diesem aus der Implementierungsperspektive sehr hohen Abstraktionsniveau sind folgende Vor- und Nachteile abzuwaegen.

Zu den Vorteilen zaehlen:

-kuerzere Implementierungszeiten,

-weniger Codierungsaufwand,

-sichere Implementierung beziehungsweise Qualitaetssicherung durch eingefrorene Objekte in DLLs sowie

-eher visuelles Programmieren auf hohem Abstraktionslevel.

-Ferner sind in Standardsituationen keine SQL-Kenntnisse erforderlich;

-ausserdem entfaellt bei dynamischem SQL oder ODBC durch Verwendung von Host-Variablen die Codegenerierung.

Diese Vorteile verdanken sich hauptsaechlich den entsprechenden Tools oder Drag-and-drop-Datenbanken, die diese Technik unterstuetzen, etwa "Access" von Microsoft oder "Integra VDB" des US-Anbieters Coromandel. Solche Tools haben allerdings oft schon Probleme, 1:n-Relationen abzubilden, geschweige denn m:n- Relationen.

Den Vorteilen steht eine laengere Liste von Nachteilen gegenueber:

-Template-Dialoge sind nur fuer Standardsituationen formalisierbar.

-Bei komplizierten Datenbankmanipulationen sind Template- Dialoge etwa fuer Union-, Join- oder Intersection-Operationen nur schwer zu gestalten.

-Template-Dialoge fuer verschachtelte Select-Anweisungen lassen sich bei komplizierten Suchfragen kaum realisieren.

-Das DBMS-API und das UIMS-API muessen von den Templates mitverwaltet werden.

-Der High-Level-Definitionsdialog wird immer komplizierter und unuebersichtlicher.

-Dynamische Dialoge in den Applikationen sind nicht moeglich, oder es muss Code produziert und weiterentwickelt werden.

-Falls Code zu generieren ist, entstehen Regenerating-Probleme, das heisst, der weiterentwickelte Code laesst sich nicht mehr in das Tool zurueckuebernehmen, und man entwickelt fuer alle Zeiten "per pedes" weiter oder verliert immer wieder die eigenen Codeteile.

-Es koennen keine detaillierten, kontextabhaengigen und applikationsspezifischen (Fehler-)Meldungen an den Benutzer durchgereicht werden, sondern das UIMS sieht nur Standardmeldungen vor. Dies widerspricht der Forderung nach robusten und selbsterklaerenden Benutzer-Schnittstellen.

-Dialog-Templates eignen sich zum Teil nur fuer einen speziellen Anwendungsfokus, etwa fuer kaufmaennische und nicht fuer technische Anwendungen.

-Die Abhaengigkeit vom Hersteller des UIMS nimmt immer mehr zu.

2. "Normale", beliebige Oberflaechenobjekte mit einem speziellen Definitionsdialog fuer die Generierung Host-sprachlicher Funktionen und der SQL-Anweisungen. Beim Attribut-Definitionsdialog mit den Oberflaechenobjekten eroeffnet zum Beispiel ein zusaetzlicher Push- Button einen Dialog fuer die Datenbankanbindung. Dort wird zum Beispiel entschieden, bei welcher DB-Operation welche Attribute einer Relation an welche Puffervariablen gebunden werden.

Dieser Ansatz beinhaltet die meisten Vorteile der ersten Vorgehensweise. Sie unterscheiden sich im wesentlichen durch das Abstraktionsniveau in den Implementierungszeiten und in der Gestaltungsfreiheit fuer das GUI.

Zu den Vorteilen zaehlen

-die nahezu beliebige Gestaltungsfreiheit fuer das GUI,

-ebenfalls relativ kurze Implementierungszeiten aufgrund des geringeren Codierungsaufwands,

-eine sichere Implementierung beziehungsweise eine bessere Qualitaetssicherung durch eingefrorene Module oder durch Codegenerierung,

-es ist eine eher visuelle Programmierung auf hohem Abstraktions-Level moeglich,

-ausserdem sind bei Standardsituationen in der Regel keine SQL- Kenntnisse erforderlich.

Es treffen jedoch die meisten der beim ersten Ansatz genannten Nachteile auch hier zu. Ferner sind folgende Probleme dem Minuskonto zuzuschlagen:

-Es sind zusaetzliche Dialogboxen fuer alle Oberflaechenobjekte notwendig, an die eine DB-Anbindung sinnvoll erfolgen kann (etwa bei Push-Buttons, aber nicht bei Checkboxen).

-Die Definitionsdialoge muessen je nach DBMS gesondert gestaltet oder es muss ein Superset-Dialog aufwendig dynamisch realisiert werden (Enable, Disable).

-Das UIMS wird immer aufgeblaehter. Damit erhoeht sich zum einen die Bedienungskomplexitaet, zum anderen die Groesse der notwendigen Rechnerressourcen.

-Das UIMS wird immer schwieriger wartbar.

Anbindung ueber Aktionen erfordert SQL-Know-how

3. Anbindung ueber die Aktionen-Schnittstelle.

Bei einer Datenbankanbindung ueber Aktionen entwirft man zunaechst am besten einen Dialog- und Aktionsgraphen, der mit allen existierenden oder Dummy-Aktionen ueber den UIMS-Editor implementiert wird. In der Aktionenverwaltung erhaelt lediglich der symbolische Aktionsdeskriptor einen konkreten Host-sprachlichen Prozedurnamen zugeordnet. Diese Prozedur kann entweder schon existieren, etwa in einer Bibliothek, oder sie wird mit einem Programmierer vereinbart und dann entsprechend codiert.

Als Vorteile lassen sich nennen:

-die maximale Gestaltungsfreiheit des GUIs,

-keine Fokussierung auf Anwendungsbranchen sowie

-die Moeglichkeit beliebiger dynamischer Dialoge.

-Ferner ist kein zusaetzlicher High-Level-Dialog erforderlich, beispielsweise mit Transparenzproblemen wie wir es von 4GL- Sprachen her kennen,

-das UIMS bleibt schlank und

-Fehlermeldungen koennen situa- tions- und applikationsspezifisch an den Benutzer durchgereicht werden.

Dieser Ansatz bietet also genau die Staerken als Vorteile, die den beiden anderen Vorgehensweisen fehlen. Umgekehrt gehen jedoch die Vorteile der vorgenannten Ansaetze verloren:

-Es muss ziemlich viel codiert werden.

-SQL- beziehungsweise ODBC- oder DMBS-spezifische Kenntnisse sind erforderlich.

-Es bestehen alle Moeglichkeiten individueller Programmierfehler.

-Die Entwicklungszeiten sind laenger - wenn die Standardsituationen verallgemeinert und als Objekte eingefroren werden, jedoch nur bei den ersten Projekten. Kombiniert man die drei beschriebenen Ansaetze, eroeffnet sich mit einem UIMS die Moeglichkeit, saemtliche Vorteile anzubieten und die Nachteile zu minimieren. Wissenschaftler stehen diesen High-Level-Produkten allerdings nicht unkritisch gegenueber. So sagte CASE-Papst Ed Yourdon den mit Funktionalitaet fuer unreife Methoden ueberladenen CASE-Tools ein dinosaurierartiges Schicksal voraus.