Ute Spadinger ist Mitarbeiterin der Integrierte Informationssysteme GmbH, Konstanz.

Der Trend zu grafischen User Interfaces (GUls) führte in den vergangenen fünf Jahren zu einer Flut von Schnittstellen-Tools. Doch das Angebot ist einseitig. Anhand eines Modellablaufs für die Entwicklung einer Benutzeroberfläche zeigt Ute Spadinger auf, in welchen Bereichen sich das Fehlen von Softwarewerkzeugen am schmerzlichsten bemerkbar macht.

Die ungeheure Vielfalt an User Interface Management Systems (UIMS) bewirkt, daß e in Entwickler, hat er sich für ein Produkt entschieden, es oft nicht effizient benutzen kann. Er muß zur Modellierung eines Softwaresystems für grafische Oberflächen erst neue Designmethoden lernen. Für den Umgang damit fehlen derzeit noch praktikable Ansätze. Der Trend zu objektorientierten Techniken verkompliziert die Situation zusätzlich.

Das GUI-Modell aus dem Seeheim-Workshop

Im Jahr 1983 wurde in Seeheim ein DV-Workshop veranstaltet, in dessen Rahmen auch eine Sitzung über UIMS stattfand. Das Ergebnis dieser Sitzung war verblüffend einfach. Heraus kam, daß ein GUI als eine Applikation aus verschiedenen Softwareschichten bezeichnet werden kann:

- Präsentationsschicht heißt der Code, der das statische Bildschirm-Layout beschreibt,

- Dialogschicht ist der Code für das dynamische Bildschirm-Layout und

- die Applikationsschicht - beinhaltet den Code, der die darunterliegenden Funktionen definiert

Die Einfachheit dieses GUI-Konzeptes hat ihm unter der Bezeichnung Seeheim-Modell zu internationalem Erfolg verholfen. Heute ist es ein Standard (siehe Abbildung 1).

Die wesentliche Bedeutung dieses Modells liegt darin, daß bei GUI-Applikationen, die danach entwickelt werden, die eben genannten Schichten separiert sind. Diese Trennung bewirkt eine Modularisierung, die die Produktivität in allen Phasen der Software-Entwicklung steigert und die langfristigen Wartungskosten reduziert Außerdem kann jede Schicht für sich spezifiziert, implementiert, getestet und gewartet werden.

Ferner erhöht sich die Konsistenz der GUI-Applikation. Sie läßt sich leichter portieren, und einzelne Module können in anderen Anwendungen wiederverwendet werden.

Eine grobe Klassifizierung von Werkzeugen für grafische Benutzerschnittstellen ist die Trennung von UIMS und User Interface Design System (UIDS): Letzteres dient der interaktiven Generierung des Screen-Layouts sprich: der Präsentationsschicht.

Ein Toolset zur Definition des dynamischen Verhaltens in der Dialogschicht erweitert das UIDS zum Management-System UIMS.

Von einem UIMS wird allerdings noch etwas mehr erwartet. Es sollte eine Entwicklungsumgebung für den gesamten Life-cycle einer Anwendung bieten und deshalb über integrierte Tools für Design, Prototyping, Ausführung, Test, Änderung und Wartung verfügen.

Darüber hinaus ist es sinnvoll, ein Tool zu haben, das sich auf verschiedene Schwierigkeitsstufen und unterschiedliche Arbeitsprofile einjustieren läßt. Nicht jeder Programmierer ist ein ausgefuchster Techniker. So finden sich in Banken oder Versicherungen nicht selten Entwickler, die nicht über C- oder C+ + -Know-how verfügen.

Sie sind gewohnt, mit den 4GL-Werkzeugen ihrer Datenbanksysteme zu arbeiten und wünschen sich ähnliche Tools auch für die Entwicklung von grafischen Benutzeroberflächen.

Der UIMS-Einsatz lohnt sich allerdings nur für große kommerzielle Software-Unternehmen. Für kleinere SW-Häuser reicht UIDS.

Grafische Oberflächen bei der SW-Entwicklung

Die Entwicklung eines Programms beginnt mit der Analyse. Zu diesem Zeitpunkt spielt die grafische Oberfläche noch keine Rolle (vgl. Abbildung 2)

Das ändert sich in der zweiten Phase. Um eine Vorstellung von Aussehen und Verhalten der zu entwickelnden Applikation zu bekommen, wird sehr oft vor dem Systemdesign ein Prototyp erstellt, häufig in enger Zusammenarbeit mit den Anwendern. Dabei ist es sehr wichtig, daß keine falschen Vorstellungen geweckt, Standards (Style Guides) von vornherein eingehalten und technisch aufwendig zu realisierende Funktionen vermieden werden. Ein Prototyp kann sehr prägend für das spätere Design eines Softwareprojektes sein.

In der darauf folgenden Designphase werden Aussehen und Verhalten von GUls möglichst genau beschrieben. Dabei sind vier Schritte zu unterscheiden:

- Allgemeine Festlegungen: Hier kann man nach einer Checkliste vorgehen, die immer wiederkehrende Anforderungen an GUls enthält. Dazu gehören:

- Hilfe-Funktionen,

- Unterstützung der jeweiligen Landessprache,

- Konfigurierbarkeit der Benutzeroberfläche,

- allgemeine Richtlinien wie die Style Guides für Motif oder Open Look,

- Hausinterne Festlegungen,

- Teststrategien,

- Farben, Fonts und lkonen,

- Auswahl von GUI-Komponenten für spezifische Funktionen,

- Bedienungsregeln für Tastatur und Maus sowie

- die Festlegung von Namenkonventionen.

- Definition der Präsentationsschicht: Hier geht es um die Festlegungen, auf welche Weise die Funktionen des Systems dem Benutzer angeboten wer. den. jede Maske oder jedes Fenster ist detailliert zu beschreiben und auf Konsistenz zu prüfen, mehrfach vorkommende Teilelemente müssen erkannt und zusammengefaßt werden (Modularisierung). Dabei sind für jede Maske die einzelnen GUI-Elemente im Sinne der zuvor erstellten Namenkonventionen zu benennen.

- Bestimmung der Dialogschicht: In diesem Designschritt wird das Zusammenspiel der einzelnen Masken festgelegt. Als grafische Darstellung eignen sich Automaten. Dazu fehlt leider eine genormte Notation für GUls.

- Definition der Schnittstellen zur Applikation: Hier spart häufig die Verwendung eines ProtokoIls viel Aufwand. Die Anzahl der Funktionen, die vorn GUI zur Applikation und umgekehrt aufgerufen werden, sollte klein sein, und die Daten sind in einem möglichst einheitlichen Format (Streams) zu übermitteln. Auch hier existieren keine Standards, obwohl die Problemstellung immer wieder dieselbe ist.

Diese Phase in der Entwicklung von GUls wird oft vernachlässigt wird. Selbst äußerst komfortable UIMS machen diesen Mangel leider nicht wett.

Von der lmplementierung bis zur Wartungsphase

Die Implementierung läßt sich in die Realisierung von Präsentationsschicht und Dialogschicht gliedern. Diese beiden Schritte erfordern sehr unterschiedliches Know-how. Bei ersterer kommt es mehr auf Fähigkeiten im Designbereich an, um ein optisch ausgezogenes Layout zu erreichen, bei letzterer sind dagegen Programmierkenntnisse gefragt.

Im darauffolgenden Integrationsschritt wird die Applikation eingefunden Hier geht es um Datenbankfunktionen, Interprozeßkommunikation und die Verbindung zu Objektklassen. Dabei haben GUI- und Applikationsentwickler zusammenzuarbeiten.

Das GUI muß bei jedem der genannten Schritte dokumentiert werden. Grafische Darstellungen sind wichtig, weil ansonsten die Akzeptanz der Ergebnisse gering ist.

Der Testaufwand von GUls wird häufig unterschätzt - wie auch bei allen anderen Softwareprojekten. Es müssen immer wieder dieselben Funktionsfolgen durchlaufen werden, was sich am besten mit einem genauen Testablaufplan, dem sogenannten Drehbuch, realisieren läßt.

Um schließlich die Softwarewartung zu ermöglichen, ohne immer wieder die ursprünglichen Projektmitarbeiter hinzuziehen zu müssen, ist eine lükkenlose Dokumentation vonnöten. GUIs bestehen aus derart vielen Komponenten, daß sogar Spezialisten rasch den Überblick verlieren. Auch die Imple. mentation der Ablaufsteuerung ist aufgrund der ereignisorientierten Konzeption von GUls meist schwer durchschaubar.

Die Unterstützung der Entwicklung von grafischen Oberflächen mit Werkzeugen ist noch recht lückenhaft. Die Implementierungsphase wird dagegen meist recht gut unterstützt. Die augenblickliche Entwicklung zielt vor allem auf Integration, zum Beispiel von SQL-Datenbanksystemen.

Obwohl es noch keine speziellen Werkzeuge für den Designprozeß gibt, kann dieser eventuell auch von einem handelsüblichen CASE-Tool begleitet werden. Für die Dokumentation und vor allem im Test fehlenjedoch noch Tools, die die Software-Entwicklungszeit von GUIs nochmals erheblich verkürzen könnten.

Hinzu kommt, daß keine theoretischen Grundlagen und Normen existieren, auf deren Grundlage solche Tools zu entwickeln wären.