Aus der Anwendersicht stellt die Bedienoberflaeche die Applikation dar. Demzufolge enthalten moderne Oberflaechen bereits einen Grossteil der Applikationslogik. Gaby Vetter* erlaeutert, wie sich die Verwendung objektorientierter User-Interface-Management- Systeme beziehungsweise Interface-Design-Tools auf die Qualitaet der damit erstellten Oberflaechen auswirkt.

Im Kampf um die Maerkte siegt meist derjenige, dessen Produkte am schnellsten verfuegbar sind. Das Schlagwort heisst hier Time to market. Sinkende Produktlebenszeiten, wachsende Variantenvielfalt und zunehmende Qualitaetsansprueche sorgen jedoch fuer drastisch steigenden Entwicklungsaufwand. Mit objektorientierten Ansaetzen wird versucht, diese kritischen Faktoren in den Griff zu bekommen.

Der Nutzen von objektorientierten Technologien ist offensichtlich - auch und vor allem fuer den Aufbau bereichsuebergreifender Systeme mit einer logisch vollstaendigen Integration aller Daten. Eine Struktur, die nach Klassenhierarchien und Vererbungsmechanismen ausgelegt ist, stellt sich sehr aenderungs- und ergaenzungsfreundlich dar. Durch die Verwendung von Objektklassen erhaelt der Anwender modulare Applikationen und verbessert damit deren Wartbarkeit und Wiederverwendbarkeit. Als direkte Folge verkuerzen sich dann auch die Entwicklungszeiten.

Die Entwicklungsphase fuer OO-Systeme umfasst im wesentlichen vier Taetigkeiten:

1.---Modelldesign eines Geschaeftsvorganges,

2.---Konstruktion von Klassen, die das Modell unterstuetzen,

3.---Zusammensetzen eines Modells aus den erzeugten Klassen sowie

4.---Hinzufuegen von Bedienoberflaechen.

Die Punkte 1 bis 3 werden bereits ausfuehrlich in der einschlaegigen Literatur behandelt. Im folgenden gehe ich deshalb speziell auf den Punkt Nummer 4, das Hinzufuegen der Bedienoberflaeche, ein.

Objektorientierte Programmierung (OOP) wurde bisher in erster Linie fuer Modell- und Klassendesign der eigentlichen Applikation und fuer die Datenbankanbindung eingesetzt. Eine grafische Bedienoberflaeche wurde dagegen eher selten nach den gleichen Prinzipien erstellt. Doch gerade hier kann der Anwender sehr stark von den Vorteilen der OO-Technologie profitieren.

Anwendungslogik in die Oberflaeche eingebettet

Um ein Objektmodell testen zu koennen, ist eine Bedienoberflaeche zwingend notwendig. Doch reicht in der Testphase ein schnell generierter Prototyp aus. Spaeter, wenn das Modell Form annimmt, fordert der Anwender jedoch eine komfortable Oberflaeche, um seine Geschaeftsvorgaenge auszufuehren.

Soll zum Beispiel ein Modell fuer den Verkaufsprozess dargestellt werden, so moechte der Anwender seine laufenden, geplanten und abgeschlossenen Sales-Aktivitaeten auf seinem Bildschirm sehen. Die fuer diese Sichtweisen erforderliche Logik wird nicht in das Basismodell des Verkaufsprozesses, sondern in die grafische Bedienoberflaeche eingebettet.

Ein wichtiger Aspekt dieser Methode ist die Tatsache, dass ein einzelnes Modell fuer unterschiedliche Loesungen eines Geschaeftsvorganges verwendet werden kann. Ziel ist es, ein System zu erstellen, das sich ohne Redesign weiterentwickeln und an neue Geschaeftsbedingungen anpassen laesst. In vielen Faellen koennen neue Loesungen realisiert werden, indem einfach nur eine neue Bedienoberflaeche auf ein bestehendes Modell gelegt wird.

Die Konstruktion der Bedienoberflaechen erfordert unterschiedliches Know-how. Neben Programmierung faellt hier am meisten Arbeit an fuer das Design von Bildschirmen, Reports, Help-Systemen etc. Diese Aktivitaeten koennen jedoch durch den Einsatz von interaktiven, objektorientierten Design-Tools vereinfacht werden.

Die Entwickler von grafischen Bedienoberflaechen benoetigen auf diese Weise nur noch minimale Kenntnisse der Objektorientierung. In erster Linie ist es wichtig, dass die Kommunikation mit den Managern funktioniert und die Entwickler deren Anforderungen in einfache, verstaendliche Bedienoberflaechen umsetzen.

Diese Methode liefert fuer gewoehnlich effiziente Loesungen fuer die Darstellung von Geschaeftsprozessen, weil die Manager direkt in das Design der Bedienoberflaeche wie auch des darunterliegenden Modells involviert sind. Schulungskosten werden reduziert, da lediglich ein Bruchteil der Entwickler tiefgehende Kenntnisse der Objektorientierung benoetigt. Die Klassenkonstrukteure und GUI- Entwickler muessen zwar OO-Grundkenntnisse besitzen, doch die meiste Arbeit kann durch Design-Tools oder mit Hilfe herkoemmlicher Programmiertechniken erledigt werden.

Die drei Schichten des Seeheim-Modells

Die Auswahl eines geeigneten Design-Tools stellt fuer manchen Programmierer ein Dilemma dar. Eine grobe Klassifizierung von Werkzeugen fuer grafische Bedienoberflaechen ist die Unterscheidung zwischen User- Interface-Management-Systemen (UIMS) und Interface- Design-Tools (IDT).

Ein IDT dient vor allem zur Erstellung der Praesentationskomponenten mittels eines interaktiven Editors. Ein UIMS hingegen geht noch einen Schritt weiter und unterstuetzt den Entwickler auch dabei, das Laufzeitverhalten einer Bedienoberflaeche zu definieren.

Zur Verdeutlichung des Unterschiedes zwischen UIMS und IDT ist hier eine kurze Beschreibung des 1983 erarbeiteten "Seeheim- Modells" notwendig (vgl. die nebenstehende Abbildung).

Dieses Modell geht davon aus, dass eine Bedienoberflaeche als eine Applikation aus verschiedenen Softwareschichten bezeichnet werden kann:

----Die Praesentationsschicht umfasst den Code, der das statische Bildschirmlayout beschreibt.

----Die Dialogschicht enthaelt das dynamische Bildschirmlayout.

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

Die wesentliche Bedeutung dieses Modells liegt darin, dass bei GUI- Applikationen, die nach dieser Vorlage entwickelt werden, die Schichten voneinander trennbar sind. Das bewirkt eine Modularisierung, die die Produktivitaet in allen Phasen der Software-Entwicklung steigert und die langfristigen Wartungskosten reduziert. Ausserdem kann jede Schicht fuer sich spezifiziert, implementiert, getestet und gewartet werden. Ferner erhoehen sich die Konsistenz und die Portierbarkeit der Applikation.

IDTs erlauben die interaktive Erstellung der Praesentationsschicht einer Applikation mittels eines grafischen WYSIWYG-Editors.

Definiert werden Masken, Menues, Buttons etc. Bei den meisten Tools steht auch eine Testumgebung zur Verfuegung. Als Ausgabeformat erhaelt der Entwickler C, C++ oder - falls er mit einem Motif-Tool arbeitet - auch UIL-Code. Die Definition des Laufzeitverhaltens erfolgt durch Programmierung in den genannten Sprachen.

Ein UIMS rentiert sich bei mehrmaligem Einsatz

Hingegen unterstuetzt ein UIMS ausser der Praesentationsschicht auch Entwicklung und Test des dynamischen Bedienoberflaechen-Verhaltens. Dies entspricht im Seeheim-Modell der Dialogschicht.

Der Entwickler wird bei der Dialogablaufsteuerung durch Dialogsprachen unterstuetzt. Das sind regelbasierte Scriptsprachen, die mit Hilfe von Events und objektorientierten Datentypen die Kommunikation zwischen der grafischen Bedienoberflaeche und dem Applikationscode uebernehmen. Dialogsprachen koennen zur Laufzeit interpretiert werden und ermoeglichen somit ein schnelles Prototyping.

Bei der Entscheidung zwischen UIMS und IDT muessen folgende Kriterien beruecksichtigt werden: Der UIMS-Einsatz rentiert sich oft erst bei mehrmaligem Einsatz oder in grossen Projekten mit komplexen Bedienoberflaechen, denn die Investitions- und Einarbeitungskosten sind selbstverstaendlich hoeher als bei einem IDT.

Fuer eine einmalige Verwendung oder fuer kleinere Projekte reicht ein IDT. Es wird den Anforderungen meist vollkommen gerecht.

Die Oberflaeche muss vor allem erweiterbar sein

Es stellt sich nun die Frage, wann ein UIMS oder IDT objektorientiert ist. Dazu reicht es nicht aus, dass das Tool C++- Code generiert. Vielmehr sollen objektorientierte Konzepte auch beim Design der Bedienoberflaeche beruecksichtigt werden. Viele Tools unterstuetzen diese Konzepte bereits oder haben sie fuer das naechste Release angekuendigt.

Bei der Evaluierung der Tools sollte der Anwender in jedem Fall auf die konsequente Einhaltung der OO-Standards achten. Diese erfordern eine Verkapselung der GUI-Komponenten innerhalb des Tools, die Erstellung von wiederverwendbaren Komponenten und ausserdem die Generierung von C++-Klassen aus der Praesentationsschicht.

Die Bedienoberflaeche selbst ist erst dann objektorientiert, wenn sie folgendes Kriterium erfuellt: Sie muss sich erweitern und an eventuelle neue Anforderungen anpassen lassen. Ein komfortables Tool bietet dem Anwender hohe Flexibilitaet beim interaktiven Design von C++-Klassen und damit auch bei der Generierung von wiederverwendbaren Oberflaechenkomponenten. Beispielsweise kommt hier das sogenannte Template-Konzept zum Tragen. Ein Template besteht aus einer Widget-Hierarchie, also etwa einer Texteingabemaske mit Labels und Eingabefeldern, oder aus anderen zusammengesetzten Templates. Diese werden zur Wiederverwendung in der gleichen oder auch in einer anderen Applikation erstellt. Template-Strukturen koennen sehr schnell gross und kompliziert werden. Selbst mit Browsing-Tools ist dann das schnelle Navigieren oft schwierig. Hier ermoeglicht eine Verkapselung der Templates das Arbeiten mit vereinfachten Struktu-ren ohne Informationsueberfluss. Dem Template-Designer steht dazu als Hilfsmittel die Moeglichkeit der Informationsunterdrueckung zur Verfuegung.

Durch die Verwendung von Templates fuer die Praesentationskomponenten wird die objektorientierte Arbeitsweise in ihren Mitteln erweitert. Diese Methodik ist sowohl bei UIMS wie auch bei IDTs moeglich. Die mit einem UIMS generierten Template- Klassen koennen allerdings zusaetzlich noch mit Klassen der Dialogschicht verknuepft werden. Auf diese Weise lassen sich die Bedienoberflaechen sogar zur Laufzeit dynamisch aendern.

Selbstverstaendlich fallen bei der Einfuehrung eines neuen Software- Entwicklungs-Tools neben der eigentlichen Investition weitere Kosten fuer Schulung und Einarbeitung an. Dem stehen jedoch auf der anderen Seite Einsparungen in den Phasen Konzeption, Realisierung, Integra- tion, Test, Dokumentation und Wartung gegenueber. Ausserdem erhaelt der Anwender auf diese Weise eine Applikation mit ergonomischer Bedienoberflaeche und einheitlichem Look and feel. Dadurch verkuerzen sich auch fuer ihn die Einarbeitungszeiten.

Objektorientierte Techniken und Tools dienen als weiterer Multiplikator fuer Effizienz und Produktivitaet bei der Software- Entwicklung. Kein Unternehmen kann es sich heute noch leisten, jede Software von Grund auf zu entwickeln und jeden Tag das Rad neu zu erfinden.