*Diplominformatikerin Inge Brenner-Pashalidis ist freie Mitarbeiterin bei CAT GmbH in Unterfoehring bei Muenchen. Sie entwickelt dort GUI-Tools.

Als klassisches Beispiel fuer Middleware gelten grafische Benutzeroberflaechen. Vorrangiges Ziel der COSE-Initiative ist es beispielsweise, eine einheitliche Anwenderumgebung fuer offene Systeme zu schaffen. Obwohl die Industrie auf diesem Gebiet bisher die meisten Produkte und Standards vorzuweisen hat, sieht Inge Brenner-Pashalidis* hier noch einigen Handlungsbedarf.

In einer heterogenen DV-Umgebung bleibt es dem Benutzer nicht erspart, mit Programmen umzugehen, die auf verschiedenen Plattformen - PC, Workstation, Grossrechner - laufen. Hierbei wird er zwangslaeufig mit unterschiedlichen Betriebssystemen konfrontiert, die in der jeweils fuer sie typischen Art und Weise mit dem Benutzer kommunizieren, wenn nicht vereinheitlichend eingegriffen wird.

Nun sind moderne Anwendungen haeufig mit grafischen Oberflaechen ausgestattet, und es haben sich dafuer unter den verschiedenen Betriebssystemen auch bereits Quasi-Standards gebildet. Das sind Windows von Microsoft fuer DOS, OSF/Motif fuer Unix oder der Presentation Manager fuer OS/2. Fuer Alpha-Terminals, die zumeist noch in Grossrechner-Umgebungen ueblich sind, gibt es Maskengeneratoren, die eine grafikaehnliche Oberflaechengestaltung ermoeglichen.

Unter den Anbietern grafischer Oberflaechen (GUIsscheint mittlerweile ein Einverstaendnis ueber die wesentlichen Gestaltungsmittel wie etwa Aktionsfelder, Menues, Listen und Fensterfunktionen zu bestehen. Auch die Maskengeneratoren fuer Alpha-Terminals bieten entsprechende Elemente an, obgleich mit eingeschraenkter Funktionalitaet.

Demnach duerfte es also ein leichtes sein, Oberflaechen fuer die verschiedenen Plattformen so zu entwickeln, dass der Endbenutzer ueberall die gleichen, wiedererkennbaren Kommunikationsmittel vorfindet. Dennoch bleiben drei Fragen offen, auf die im folgenden der Reihe nach eingegangen werden soll:

- Sind die modernen GUIs tatsaechlich als Vermittler zwischen den Welten geeignet?

- Auf welche Probleme stoesst ein Anwendungsentwickler, wenn er Oberflaechen entwerfen will, die diese Vermittlerrolle spielen koennen?

- Welche Probleme hat der Endbenutzer, wenn er von einer grafischen Oberflaeche zur anderen wechselt?

Vermittlung durch

Windows und Motif

Die Antwort auf die letzte Frage haengt wesentlich von den Antworten auf die beiden ersten Fragen ab. Wenn diese befriedigend ausfallen, koennen Oberflaechen den Zugang zu heterogenen Systemen tatsaechlich sehr erleichtern, indem sie die den einzelnen Betriebssystemen eigenen Sprachmittel ueberdekken. Andernfalls wuerde die Heterogenitaet der Betriebssysteme einfach nur durch die Heterogenitaet der Oberflaechen ersetzt werden.

Zunaechst ist zu klaeren, ob moderne GUIs tatsaechlich als Vermittler zwischen den Betriebssystem-Welten geeignet sind. Dazu ein paar Ueberlegungen zu MS-Windows und OSF/Motif:

Beide GUIs unterstuetzen ein Eingabefeld fuer die Eingabe von Daten und Texten ("XmText-Widget" in Motif, "Edit-Control" in Windows). In einer konkreten Oberflaeche werden dafuer zum Beispiel folgende Eigenschaften gefordert:

- mehrzeilige Eingabe,

- Erzwingen eines bestimmten Formats sowie

- besondere Hintergrundfarbe.

Beide Toolkits gestatten es, ein derartiges Eingabefeld zu programmieren. In der Realisierung gibt es allerdings Unterschiede:

- Die Eigenschaft "mehrzeilig" wird in Motif ueber eine dynamisch aenderbare Ressource (Attribut) des Text-Widgets gesteuert; in Windows ist sie als Style beim Erzeugen des Edit-Controls anzugeben und kann nicht veraendert werden.

- Das Text-Widget bietet die Moeglichkeit, Benutzereingaben zu pruefen und eventuell abzulehnen, bevor sie auf dem Bildschirm dargestellt werden. Dazu muss der Entwickler eine Callback-Routine schreiben, die Motif immer dann aufruft, wenn der Inhalt des Widgets geaendert wird. In Windows kann der Entwickler auf eine Message des Toolkits reagieren, er erhaelt diese aber erst, nachdem die Aenderung auf dem Bildschirm bereits sichtbar gemacht wurde.

- Die Hintergrundfarbe ist in Motif eine Ressource des Widgets; in Windows wird sie immer wieder explizit gesetzt, wenn das Edit- Control auf dem Bildschirm neu gezeichnet werden muss.

Darueber hinaus ist auch das Verhalten des Eingabefelds im Ablauf zu beruecksichtigen. Wie die erwaehnte Eigenschaft von Text-Widgets zeigt, ist es nicht trivial, die Reaktion auf eine falsche Benutzereingabe in beiden Systemen uebereinstimmend zu gestalten.

Hinzu kommt, dass Eingabefelder eingebaute Verhaltensweisen zeigen, die beim Wechsel der Plattform eine gewisse Flexibilitaet des Benutzers verlangen. Unter Motif bewirkt die Return-Taste, dass eine neue Textzeile angelegt wird. Unter Windows haengt die Interpretation der Taste davon ab, ob sich das Edit-Control innerhalb eines Windows-Dialogs befindet: Dort loest sie die Default-Aktion des Dialogs aus, hat also bezueglich des Edit- Controls gar keine Funktion - wenn der Entwickler keine Vorkehrungen trifft.

Beide Toolkits kennen Menues. Waehrend in Motif auch die Menues dem Widget-Konzept mit Ressourcen und Callbacks entsprechen, sind sie in Windows wesentlich verschieden von anderen Dialogelementen und daher ueber einen eigenen Satz an Funktionen zu erzeugen und zu pflegen.

In Motif spielen Container-Widgets eine bedeutende Rolle. Sie entlasten den Entwickler weitestgehend von der Aufgabe, die ihnen untergeordneten Dialogelemente zu ordnen und aufeinander auszurichten. Windows kennt kein derartiges Gestaltungselement.

Die Probleme

der Entwickler

Oberflaechen zu konzipieren, die auf beiden Plattformen realisierbar sind,bedarf, das zeigen die Beispiele, genauer Kenntnisse beider Toolkits; ihrer Gemeinsamkeiten und vor allem ihrer Unterschiede, und dies um so mehr, wenn auf Benutzerkonformitaet geachtet werden soll:

- Nicht alle GUIs unterstuetzen alle Dialogelemente. Fuer den Entwickler bedeutet dies, dass ihm entweder nur die gemeinsame Schnittmenge zur Verfuegung steht, oder dass er die in einer GUI fehlenden Elemente nachbilden muss.

- Die Gestaltungsmoeglichkeiten fuer einzelne Dialogelemente sind unterschiedlich. Wieder ist zu entscheiden, ob nur die ueberall verfuegbaren Merkmale zur Gestaltung herangezogen oder ob fehlende nachimplementiert werden.

- Die Realisierungskonzepte der einzelnen GUIs sind unterschiedlich. Die verschiedenen Konzepte beeinflussen die Architektur der Anwendung; von Plattform zu Plattform ist oft ein Umdenken notwendig. Grosse Sorgfalt ist deshalb beim Entwurf von Anwendungen geboten, die auf mehrere Plattformen portiert werden sollen.

Diese Aussagen treffen in unterschiedlichem Grad auf alle GUIs zu. Sind neben grafischen Oberflaechen auch Alpha-Terminals im Einsatz, muss der Entwickler erhebliche konzeptionelle Unterschiede beruecksichtigen. Grafische Benutzeroberflaechen sind objektorientiert, Maskensysteme dagegen prozedural ausgelegt.

Es erscheint dringend geboten, den Anwendungsentwickler bei der Bewaeltigung der aufgezeigten Probleme zu unterstuetzen. Zwei Hilfsmittel werden ihm vor allem zur Verfuegung stehen, naemlich die als Styleguides bezeichneten Richtlinien sowie Dialogbeschreibungssprachen.

Ein Styleguide gibt dem Entwickler einen Leitfaden an die Hand, der es ihm erleichtert, Dialogablaeufe nach anerkannten Richtlinien zu entwerfen. Die meisten Hersteller von GUIs liefern daher ihre Produkte mit solchen Richtlinien aus. Sie erlaeutern, wie die Dialogelemente des Toolkits aus Sicht des Herstellers verwendet werden sollten. Beispielanwendungen geben zugleich Programmierhilfen.

Die Verwendung solcher Toolkit-spezifischen Richtlinienkataloge allein genuegt jedoch nicht, um in heterogenen Umgebungen zu einheitlichen Oberflaechen zu gelangen. Naturgemaess kann der Styleguide eines Toolkit-Herstellers nur "fuer sich" sprechen.

Deshalb entwickeln viele Anwenderunternehmen interne Styleguides, die ihre besonderen Anforderungen widerspiegeln, und die unabhaengig von speziellen GUI-Spezifikationen wie IBMs Common User Acces (CUA) oder SNIs Styleguide sind. Interne Richtlinien koennen gerade in heterogenen Umgebungen hilfreich sein, wenn sie den Entwickler auf genau die Gestaltungselemente und -ablaeufe festlegen, die auf allen Plattformen des Unternehmens verfuegbar sind.

Styleguides helfen dem Entwickler, uneinheitliche Oberflaechen zu vermeiden; die Programmierung auf den unterschiedlichen Plattformen ist aber immer noch zu leisten. Allerdings gibt es Werkzeuge, die diese Arbeit erleichtern.

Etliche Toolkits bieten die Moeglichkeit, eine Oberflaeche zumindest teilweise in einer speziellen Beschreibungssprache zu spezifizieren. Die Beschreibung wird in einer Datei abgespeichert, von einem Compiler in Binaerformat uebersetzt und zur Anwendung hinzugebunden (siehe UIL in Motif, RC-Dateien in Windows). Darauf aufbauende Programme gestatten den interaktiven Dialogentwurf am Bildschirm. Sie generieren die entsprechenden Beschreibungsdateien und die Binaerformate.

Beschreibungssprachen vereinfachen die Programmierung der einzelnen Dialogbausteine fuer ein bestimmtes GUI. Sie koennen dem Entwickler aber nicht ersparen, sich mit den unterschiedlichen Konzepten der GUIs auseinanderzusetzen.

Sie helfen auch nicht bei Problemen mit heterogenen Systemen weiter.

Sehr viel groesseren Komfort bieten User-Interface-Management- Systeme (UIMS) wie etwa der "Dialog Builder" der Firma SNI. Derartige Werkzeuge wurden speziell fuer Entwurf und Pflege von grafischen Oberflaechen entwickelt. Sie abstrahieren vom darunterliegenden Toolkit, indem sie unter anderem Dialogoberflaechen interaktiv nach dem WYSIWYG-Prinzip erstellen.

Die Dialogelemente werden weitgehend durch Direktmanipulation angeordnet und dimensioniert. Die Elemente selbst werden meist in einer Toolbox oder auch als Bibliothek wie beim Dialog Builder angeboten. Der Inhalt der Toolbox ist im Idealfall konfigurierbar, denn dadurch laesst sich die

Menge der verwendbaren Dialogelemente an die Beduerfnisse der konkreten Umgebung anpassen.

Eine weitere Abstraktion vom Toolkit findet statt, indem die UIMS ueber zusaetzliche Editoren alle weiteren Eigenschaften wie Farben oder Zeichensaetze bestimmen. Im guenstigen Fall koennen die Attribute dabei in einer Form dargestellt werden, die einerseits vom speziellen GUI unabhaengig ist und andererseits Unternehmens- Styleguides unterstuetzt.

UIMS stellen im optimalen Falle eine einfache Sprache zur Definition von Dialogablaeufen zur Verfuegung. Damit laesst sich ein wichtiger Beitrag zur Entwicklung plattformneutraler Software leisten. Die Sprache erzwingt die Trennung zwischen Dialogsteuerung und den eigentlichen Anwendungsfunktionen.

Gute UIMS bieten noch eine Reihe weiterer Komponenten an, wie Codegenerator, Simulationswerkzeuge und Testhilfen, die alle ihren Beitrag auf dem Weg zu konformen Oberflaechen in heterogenen Umgebungen leisten koennen.

Nun unterstuetzen nicht alle UIMS alle erwaehnten Komponenten in gleicher Weise, und nicht alle sind vom Konzept her Toolkit- neutral. Bei denjenigen, die die Gestaltung von Oberflaechen fuer verschiedene Plattformen explizit anbieten, sind zwei Vorgehensweisen erkennbar.

Bei der einen abstrahiert das UIMS vollkommen von den GUIs und setzt statt dessen auf einem eigenen Dialogmodell auf. Dieses wird dann auf den verschiedenen Zielplattformen abgebildet. "XVT" von XVT Software Inc. und "Grit" von der Firma GFT folgen dieser Vorgehensweise. Ein grosser Nachteil ist dabei, dass sie von bereits etablierten Standards wie OSF/Motif keinen Gebrauch machen, sondern einen eigenen bilden.

Im allgemeinen gehen diese UIMS zugleich von einer allen Toolkits gemeinsamen Untermenge an Elementen und Funktionen aus, wodurch attraktive Features einzelner GUIs verlorengehen (etwa die Container-Widgets in OSF/Motif). Auch die Anpassung an Neuentwicklungen wird erschwert. Dafuer ist gewaehrleistet, dass eine einmal entworfene Oberflaeche auf jedem System ablauffaehig ist.

Bei der anderen Vorgehensweise stuetzt sich das UIMS auf ein anerkanntes GUI und emuliert dieses - soweit moeglich - auf andere Plattformen. Diese Methode wurde beim Dialog Builder gewaehlt, der sich auf OSF/Motif bezieht. Neben dem Motif-Laufzeitsystem wird ein Windows-Laufzeitsystem angeboten, das die Motif-Widgets auf entsprechende Fenster und Controls von Windows abbildet. Motif- spezifische Features werden so weit moeglich emuliert; nicht abbildbare werden ignoriert, fuehren aber keinesfalls zu Fehlern im Ablauf. Spezielle Objektbibliotheken und Attributsichten foerdern die Portierbarkeit von Windows-Anwendungen nach Motif und umgekehrt.

Trotz aller Unterschiede muss jedoch gesagt werden, dass moderne UIMS und Standardisierungsbemuehungen, die auf nationaler und internationaler Ebene in Gang sind (ISO Norm 9241), die Gewaehr dafuer bieten, dass grafische Oberflaechen tatsaechlich die von ihnen erwartete Vermittlerrolle spielen koennen.

Sie eroeffnen den Anwendern einen einheitlichen und einfachen Zugang zu den verschiedenen Systemwelten.