Im Durchschnitt müssen 40 Prozent des Programmcodes einer Anwendung neu geschrieben werden, wenn man sie von einer grafischen Benutzerschnittstelle (Graphical User Interface = GUI) an eine andere anpaßt. Wegen dieses Dilemmas haben einige DBMS-Hersteller Lösungen entwickelt.

Silvia Parthier ist Herausgeberin und Chefredakteurin des Magazins, "Datenbank-focus" aus dem IT Verlag für innovative Technologien GmbH, Eichenau bei München. Der Beitrag ist mit freundlicher Genehmigung der Ausgabe 07/08/1992 entnommen.

ES geht um die optimale Anpassung

Benutzerschnittstelle. (User Interface) Auch Benutzerobfläche, Mensch-Maschine Schnittstelle. Als B. bezeichnet man die Gesamtheit der Eigenschaften und Funktionen durch die der Benutzer mit dem System, vor allem mit dem Prozessor und mit den Speichern des Systems verbunden wird, Da es aus der Sicht ökonomischer Nutzung des Rechners darauf ankommt, die Leistungsfähigkeit von Prozessor und Speichern möglichst voll auszunutzen, ist die Art der B. von entscheidender Bedeutung.

Leistungsfähige Schnittstellen erlauben die volle Ausnutzung des Rechners, stellen ihrerseits aber wesentliche Kostenfaktoren dar. Schwache Schnittstellen sind zwar selbst billig, lassen aber in der Regel keine gute Auslastung des Systems zu. Die Schnittstelle wird selbst sowohl durch Hardware, nämlich die peripheren Geräte (vor allem durch Bildschirm und Tastatur) verkörpert als auch durch Software, nämlich durch die Programme, die die Verbindung zwischen interner Verarbeitung und Eingabe und Ausgabe herstellen. Dabei gilt folgte Prinzip: Wird einfache, wenig leistungsfähige Hardware eingesetzt, so müssen diese schwachen Leistungen durch erhöhten Software-Aufwand kompensiert werden, was den Prozessor und den Speicher zusätzlich belastet. Wird dagegen leistungsfähige Hardware eingesetzt, so werden die internen Komponenten entlastet. Aus dieser Betrachtungsweise können die eingesetzten Geräte für die Eingabe und die Ausgabe sowie die Programme, die Eingabe und Ausgabe unterstützen, als B. bezeichnet werden.

Jedoch nicht nur diese ökonomisch-technische Betrachtungsweise ist für die B. von Bedeutung, sondern auch die physiologisch-psychologischen Erfordernisse des Benutzers und die Anpassung von Hardware und Software an diese sind für die endgültige Beurteilung einer B. wichtig. Erst wenn technische und ergonomische Bedingungen insgesamt optimiert sind, spricht man von einer zweckmäßigen B. Es geht also um eine optimale Anpassung zwischen Mensch und System, wobei bei moderner Betrachtung die menschliche Seite ein wesentlich größeres Gewicht hat als die maschinelltechnischen Aspekte.

(B. = Benutzerschnittstelle; Obiger Text ist zitiert aus: Hans Herbert Schulz, Computer Enzyklopädie, Rowohlt Taschenbuch Verlag GmbH, Reinbeck bei Hamburg)

Portabilität von Anwendungen Über verschiedene Hardware-Architekturen und Betriebssysteme hinweg ist heute eine der Hauptforderungen bei der Applikationsentwicklung. Probleme bereitet jedoch der Durchbruch der grafischen Benutzerführungen. Ihre Vielfalt stellt die Software-Entwickler vor schwierige Aufgaben. Was tun, wenn in einem Unternehmen mehrere Benutzerführungen nebeneinander existieren?

Die Frage ist einfacher gestellt als beantwortet. Grafische Benutzerführungen existieren nicht erst seit heute. Was Ende der sechziger Jahre als Forschungsprojekt "Star" in den Xerox-Forschungslabors begann, hat seinen Durchbruch mit der Benutzerführung des Macintosh gefunden. Heute existieren mit Windows, GEM, Presentation Manager, Open Look, X-Windows, Decwindows, Motif, Geo Ensemble, Collage, New Wave und Next step eine Vielzahl von Benutzerführungen auf unterschiedlichen Betriebssystemen. Für grafische Benutzerführungen hat sich der Terminus Graphical User Interfaces eingebürgert.

Das große Manko ist klar ersichtlich: Es gibt - auch im Unix-Bereich - keinen einheitlichen Standard. Man kann sich also bei den GUIs auf eine Koexistenz verschiedener De-facto-Standards einstellen.

Grundsätzlich sehen alle GUIs im Look and Feel ähnlich aus. Die Programmierschnittstellen, und das ist das Entscheidende, unterscheiden sich jedoch erheblich.

Der Haken ist der hohe Portierungsaufwand

Da man erkannt hat, daß. GUls nicht nur den Endanwender schneller mit einer Anwendung vertraut machen, sondern GUls auch die Produktivität der Entwickler enorm erhöhen, ist ihr Einsatz eigentlich keine Frage mehr. Der Haken ist der hohe Portierungsaufwand auf eine andere GUI-Plattform. Um diesen Aufwand zu verringern, bieten einige Softwarehäuser Werkzeuge an, die die Anwendungen an die verschiedenen GUls anpassen.

Bevor wir die Lösungsansätze betrachten, werfen wir zunächst einen Blick auf die grundlegenden Unterschiede verschiedener GUIs, um die Probleme besser darstellen zu können.

Eines der Hauptmerkmale der Benutzerführungen ist die Fenster- oder Window-Technik. Es lassen sich mehrere Fenster auch überlappend auf dem Bildschirm darstellen. Die Anwender können sie in ihrer Form und in ihrer Größe mit der Maus oder einem Trackball verändern.

Mit dem Bildschirm, auch Screen genannt, sind weitere Mechanismen verknüpft. Dies sind die Widgets oder Gadgets. Widget steht für ein kleines Werkzeug, Gadget für Vorrichtung. Mit ihrer Hilfe können beispielsweise Anwendungen gesteuert oder die Darstellungsform auf dem Bildschirm verändert werden. Beispiele hierfür sind Scrollbars, Menüs oder Buttons. Die Bedienung der GUls erfolgt objektorientiert. Das heißt, der Benutzer klickt (in der Regel per Maus) Objekte (Icons) auf seinem Bildschirm an und bestimmt, was mit ihnen geschehen soll. Objekte können beispielsweise Dateien, Dokumente oder Anwendungen sein. Die auszuführenden Kommandos werden zumeist aus Menüleisten ausgewählt. Diese Objektorientiertheit unterscheidet die Programmierung der GUls von traditioneller Software-Entwicklung.

Der Unterschied zwischen beiden Programmierarten liegt darin, daß beim Programmieren von GUIs der Anwender die Kontrolle über den Ablauf erhält und nicht, wie bisher, das Anwendungsprogramm. Also muß die Anwendung so aufgebaut sein, daß sie auch auf bestimmte asynchrone Ereignisse, die Events, reagieren kann.

Die Ursachen von Events können recht unterschiedlich sein. Meistens werden sie durch einen Tastendruck oder einen Mausklick ausgelöst. Sie rufen verschiedenartige Aktionen und in der Folge wiederum Events hervor. Das könnten etwa sein:

- Auswählen eines Kommandos aus einem Menü;

- Aktualisieren des Bildschirms, etwa wenn ein Fenster verschoben wurde;

- Ändern der Größe eines Fensters und Aktualisieren der dort dargestellten Daten;

- Verschieben der Informationen in einem Fenster nach der Betätigung eines Rollbalkens (Scrollbar);

- Aktivieren und Deaktivieren von Fenstern;

- Betätigen von Druckknöpfen (etwa Close-Button).

Prinzipiell gibt es zwei Modelle, um mit Events umzugehen (Abbildung 1):

- Event Loop: Hier befindet sich die Anwendung in einer Schleife, in der auf Ereignisse gewartet wird. Bibliotheksfunktionen teilen der Software das Eintreffen eines Events mit, die dann ihrerseits eine entsprechende Behandlungsroutine aufruft, bevor sie sich wieder in die Warteschleife begibt.

- Callback-Modell: Bei diesem neueren Modell muß die Anwendung für jede kreierte Einheit, etwa Screen, Window, Menü, dem System die dazugehörige Behandlungsroutine (Callback-Routine) angeben. Wenn nun das GUI ein Event feststellt, wird die entsprechende Callback-Routine der Applikation aufgerufen. Nach der Initialisierung tritt die Anwendung nur dann in Aktion, wenn eine ihrer Event-Routinen aufgerufen wird. Ein Vorteil des Verfahrens liegt in der möglichen Hintergrundverarbeitung, etwa dem Spooler-Betrieb.

Neben den Methoden der Event-Behandlung existiert noch eine Reihe weiterer Unterschiede zwischen den GUls. Meistens betreffen sie die Darstellung auf dem Bildschirm und deren Ansteuerung.

Ein Beispiel hierfür ist der Ursprung des Koordinatensystems, der bei den meisten GUIs in der linken oberen Ecke des Bildschirms liegt, bei manchen aber auch links unten. Ähnliche Unterschiede gelten für die Auflösung, die Zeichenalgorithmen, die Anzahl der unterstützten Farben und Zeichensätze sowie die Darstellung und den Inhalt von Menüleisten.

Einige Lösungen, die den Portierungsaufwand auf ein Minimum verringern sollen, werden nun vorgestellt:

Oracle schuf mit seinem Toolkit eine Zwischenschicht, die die GUIs im Look and Feel unterstützt und gegenüber der Anwendung immer die gleiche Schnittstelle besitzt. Der Programmierer muß sich nur noch mit einer Schnittstelle befassen, und die Anwendungen selbst sollen mit minimalem Aufwand portierbar sein. Das Toolkit, Version 1, ist kein eigenständiges Produkt, sondern vielmehr in SQL-Forms 3, SQL-Menu 5 und Oracle Graphics enthalten. Derzeit werden die GUls Presentation Manager, Decwindows, Motif und Open Look unterstützt. Next step und weitere sollen folgen.

Da die GUls verschiedene Ereignisse kennen, unterstützt das Toolkit eine standardisierte Menge von Ereignissen. Werden Ereignisse benötigt, die nicht in allen Benutzerführungen vorhanden sind, bildet das Toolkit diese bei Bedarf nach.

Das Koordinationssystem des Toolkits hat seinen Ursprung in der linken oberen Ecke. Für GUls, die einen anderen Ausgangspunkt haben, werden die Koordinaten umgerechnet. Es ist sichergestellt, daß der Umgang mit grafischen Benutzerführungen in bezug auf die Programmierung einheitlich und portabel ist. Dies betrifft unter anderem Zeichenalgorithmen, Zeichensätze, Zeichenattribute etc. Um die Einbindung des Toolkits in die Anwendung zu verdeutlichen, sei hier ein kurzes Beispiel gezeigt:

Im Falle von X-Windows hat eine Anwendung eine zweigeteilte Schnittstelle. Die "lntrinsic-Functions" (Xtk), auch eingebettete Funktion genannt, bilden die eine Ebene. Darunter befindet sich eine Unterprogrammbibliothek (Xlib), die sich auch direkt ansprechen läßt. Beim Erstellen der Anwendung werden Funktionen und Unterprogramme in den Programmcode mit eingebunden und bilden den X-Client. Dieser kommuniziert entweder lokal oder über ein Netzwerk mit dem X-Server. Aufgabe des X-Servers ist das Umsetzen der Funktionsaufrufe in hardwarespezifische Steuersequenzen zum Bildaufbau.

X-Windows stellt nur die grundlegende Funktionalität zur Verfügung. Die Einheitlichkeit von Anwendungen wird erst durch GUls wie Open Look, Decwindows oder Motif festgelegt. Abbildung 2 zeigt am Beispiel von Motif, daß sich aus der Perspektive der Anwendung eine weitere Ebene zur Ansteuerung der GUI ergibt. Das Toolkit, in diesem Beispiel für Motif, bietet nun seinerseits der Anwendung eine einzige Schnittstellenebene an. Die Funktionalität des Toolkits besteht also in der Umsetzung zwischen einheitlicher und uneinheitlicher GUI-Schnittstelle.

Praxiserfahrungen im Hause Oracle zeigen, daß sich mit dem Toolkit der Portierungsaufwand auf weniger als zwei Prozent reduzieren läßt. Völlig zu vermeiden dürfte die Anpassung an eine GUI wohl kaum sein, wenn man die Vorzüge von beispielsweise Motif gegenüber dem Zeichenmodus nutzen will. Das Toolkit versorgt jede GUI mit allen erforderlichen Standardwerten, die man jedoch ändern kann.

Grafisch gestaltet das Toolkit, Version 1, lediglich die Menüführung. SQL-Forms 3.0 beispielsweise ist nicht in der Lage, Grafiken aus Datenfeldern in einer Maske auszugeben. Als multimedia-fähig ist aber SQL-Forms 4.0 angekündigt, das gegen Ende des Jahres 1992 verfügbar sein soll. Die neue Version wird das Toolkit in der Version 2 enthalten.

Auch bei Informix nähert sich die Ära der eckigen Klammern, die Eingabefelder in Masken kennzeichnen, ihrem Ende. Das jüngste Mitglied der 4GL-Produktfamilie heißt Informix-4GL/GX und soll ab August 1992 auf dem Markt sein. GX steht für Graphical Execution. 4GL/GX ist ein P-Code-Runner unter Motif und Windows. Applikationen, die unter dem Runtime Development System, Version 4.1, für zeichenorientierte Terminals entwickelt wurden, sollen ohne eine einzige Änderung des Quellcodes mit dem neuen P-Code-Runner (Abbildung 3) ablauffähig sein. So werden beispielsweise Ringmenüpunkte als Buttons dargestellt. Eingabefelder sind Kästchen, statt wie bisher mit rechteckigen Klammern gekennzeichnet.

Zusätzlich gibt es einen reservierten Bereich am unteren Ende des Applikationsfensters mit Buttons für häufig benutzte Funktionen zum Einfügen, Löschen und Modifizieren einzelner Records, zur Richtungskontrolle sowie mit einem Button für Online-Hilfe. Die einzelnen Funktionen, Menüpunkte und Eingabefelder können, falls dies vom Entwickler über die "Option input unconstrained" vorgesehen wird, mit der Maus aktiviert werden.

Ingres/Windowview ist eine Laufzeitumgebung für OSF/Motif, Decwindows und Open Look. Auf diese Weise sind nicht nur alle bisher für Terminals verfügbaren Ingres-Werkzeuge für Endanwender und Entwickler - auch mit grafischer Benutzeroberfläche - auf Workstations und PCs einsetzbar, sondern ebenfalls alle Anwendungen, die mit - diesen Werkzeugen geschrieben wurden. Unabhängig davon, ob ursprünglich am Terminal, ob in 4GL oder 3GL entwickelt worden ist, alle Ingres-Anwendungen laufen umgeändert auch auf diesen grafischen Benutzeroberflächen. Menüs und Funktionstasten der Terminal-Version erscheinen in der grafischen Umgebung automatisch als Popup-Menüs und Buttons, die mit der Maus angeklickt werden. Dieselbe Anwendung kann sowohl bei Terminals als auch bei PCs und Workstations eingesetzt werden.

Die Sybase-APT-Workbench unterstüzt derzeit noch keine Standard-GUls. Man kann jedoch eine Anwendung mit Fenstern, Pulldown-Menüs und Mausunterstützung schreiben. Hierbei handelt es sich jedoch um eine herstellereigene grafische Benutzeroberfläche. Sie stellt eine Kompromißlösung dar, mit der Anwendungen für zeichenorientierte Terminals leicht an eine grafische Workstation angepaßt werden können.

Noch in diesem Jahr sollen allerdings Translation Services verfügbar sein, mit denen man ein Maskenlayout automatisch an Motif, Open Look und MS-Windows anpassen kann. Die Anwendungen werden damit noch nicht multimedia-fähig.

Die Portierung von Anwendungen sowohl zwischen Datenbanksystemen als auch zwischen Benutzerschnittstellen unterstützt Rosi-SQL. Rosi-SQL verfügt über Schnittstellen zu Informix, Oracle und DDB4. Anwendungen, die mit dieser 4GL entwickelt wurden, sollen ohne Änderung des Quellcodes sowohl auf zeichenorientierten Terminals als auch unter OSF/Motif laufen. Voraussetzung ist lediglich, daß die Runtime-Version Rosi-SQL/Motif installiert ist. Rosi-SQL/Motif schöpft allerdings die Möglichkeiten, die Motif bietet, nicht aus, um die Kompatibilität zur zeichenorientierten Version zu bewahren.

DBMS-Hersteller wollen auf GUI-Zug aufspringen

Darüber hinaus gibt es auch Bibliotheken, die sich nur um die Darstellung der Daten auf dein Bildschirm kümmern wie etwa wintran von Guideware Corp. Wintran soll es erlauben, eine Anwendung über unterschiedliche Betriebssysteme und Oberflächen hinweg zu portieren. Es soll MS-Windows, Motif und Presentation Manager unterstützen. Während sich Wintran an der Programmiersprache C orientiert, bietet das Dialog-System von Microfocus diese Funktionen für Cobol an.

Aus der Liste der vorgestellten Produkte wird allerdings eines ganz deutlich. Alle DBMS-Hersteller versuchen möglichst schnell auf den GUI-Zug aufzuspringen. Zumindest die Menüführung erfolgt bei den meisten grafisch und mit Unterstützung der Maus. Die angebotenen Werkzeuge gestatten im wesentlichen die Übernahme von Terminal-Anwendungen mit nur geringem oder keinem Anpassungsaufwand auf grafische Oberflächen. Dabei werden jedoch weder Bilder noch verschachtelte Scroll-Bereiche unterstützt. Multi-Window-Anwendungen mit entsprechendem Event-Handling können mit diesen Werkzeugen nur auf die klassische Weise mit 3GL und Unterprogrammbibliotheken geschaffen werden.

Weiter hinein in die Weit der Grafik hat sich bislang nur Ingres mit Ingres/Windows-4GL gewagt. Immerhin schon seit 1990 für OSF/Motif und Decwindows am Markt, erlaubt diese Entwicklungsumgebung nun auch für MS-Windows 3.1, Open Look und Presentation Manager, völlig portable Anwendungen zu schreiben. Mehrere Entwickler können gleichzeitig an derselben Anwendung arbeiten. Ein integriertes Life-Cycle-Management verwaltet multiple Versionen sowohl einzelner als auch gemeinsamer Objekte.

Den Entwicklern stehen grafische Window- und Menü-Editoren und Debugger für die objektorientierte 4GL zur Verfügung. Sie können Masken vollständig nach eigenen Vorstellungen gestalten und Grafiken, etwa ein Firmenlogo als festen Bestandteil einbauen. Buttons lassen sich beliebig positionieren und ebenfalls mit einem Logo versehen. Bilder und Dokumente (Blobs: Binary Large Objects) können genauso einfach wie alphanumerische Daten dargestellt und in der Datenbank gespeichert werden. Ingres/Windows-4GL präsentiert somit beispielsweise das Bild einer Person neben deren Adreßsatz oder hierarchische Daten in verschachtelten Scroll-Bereichen. Alle Anwendungen bleiben dabei von der Hardware und dem Betriebssystem unabhängig. Dasselbe Programm kann in einem Netzwerk aus einer zentralen Datenbank von unterschiedlichen Workstations oder PCs aufgerufen werden und nimmt automatisch das Look and Feel der jeweiligen grafischen Benutzeroberfläche an.

Der GUI-Zug rollt schnell. Für den Herbst 1992 wird eine neue Version von Ingres/Windows-4GL erwartet. Dicht auf Ingres' Fersen folgt Oracle mit seinem Toolkit, Version 2, das Bestandteil von SQL-Forms 4.0 und ebenfalls im Herbst 1992 erhältlich sein soll.