% Studienarbeit von Ilona Hachmann
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Entwicklungswerkzeuge f"ur graphische Benutzerschnittstellen

\chapter{Entwicklungswerkzeuge f"ur graphische Benutzerschnittstellen}
\label{Entwicklungswerkzeuge}

Bei vielen graphischen Benutzeroberfl"achen ist der Kode des Anwendungsprogramms mit dem der Benutzeroberfl"ache vermischt \cite{weg95}. Aus diesem Programm sp"ater die oberfl"achenspezifischen Funktionen herauszufinden, ist fast unm"oglich.
Bei solchen Programmen bestimmt die Anwendung das Aussehen der Oberfl"ache.\\
Durch die separate Entwicklung der Oberfl"ache erreicht man eine Trennung vom Programmkode der Anwendung. Nicht nur die Wartung der beiden Teile ist einfacher, sondern auch k"urzere Entwicklungszeiten und einfacheres Prototyping sind m"oglich \cite{mus94}.\\
In \cite{weg95} wird gefordert, da"s diese beiden Komponenten m"oglichst nicht von derselben Person programmiert werden. Ein Experte mit ergonomischen Kenntnissen sollte das Oberfl"achen-Design "ubernehmen ({\em User-Interface-Designer\/}). Unabh"angig von der Anwendung kann er ergonomisch g"unstige L"osungen einer Oberfl"ache entwerfen.\\
In \cite{schweiP95} wird die Zusammenarbeit von Programmierern und Designern beschrieben.\\
Zusammenfassend sind die Anforderungen an ein Entwicklungswerkzeug:
\begin{itemize}
\item Trennung zwischen Anwendung und Benutzerschnittstelle
\item einfache Bedienung
\item wenig Programmkode
\item fenstersystemunabh"angig
\item plattformunabh"angig
\item flexibel
\end{itemize}
Mit Resource-Editoren, z.B. dem {\de} von {\sv}, kann aus einer F"ulle von vordefinierten Interaktionselementen zun"achst ein statisches Abbild der Benutzerschnittstelle erstellt werden, um diese an die Anwendung zu binden. F"ur diese Aufgabe werden unterschiedliche Methoden respektive Werkzeuge zur Vef"ugung gestellt. Im Folgenden werden anhand von {\sv} Klassenbibliotheken, system"ubergreifende Klassenbibliotheken sowie Resource-Editoren vorgestellt werden. 
Das Kapitel schlie"st mit einer Klassifizierung der Ans"atze. 

                          \section{Fenstersysteme}
\label{fenster}
Fenstersysteme ({\em window system}) bilden die Grundlage der Erstellung von direktmanipulativen Benutzerschnittstellen \cite{mus94}.
Mit einer vom Fenstersystem gestellten Bibliothek mit Basisfunktionen greift man auf das Fenstersystem zu.
Weil Fenstersysteme nur eine Basisfunktionalit"at anbieten, ist der Entwurf einer Benutzerschnittstelle auf dieser Ebene sehr m"uhsam. Komplexere Oberfl"achen m"ussen aus mehreren Funktionsaufrufen zusammengesetzt werden.\\
Am Arbeitsbereich {\em Datenbanken und Informationsysteme} (DBIS) sind u.a. folgende Fenstersysteme mit den dazugeh"origen Stilrichtlinien und Bibliotheken vorhanden:
{\pn X11} mit {\om} und der {\pn Xlib}, {\ow} mit {\ol} und der {\pn Xlib} f"ur {\unix}-Systeme, der {\fin} mit den {\pn {UI Guidelines}} und {\pn {Quick\-Draw}} f"ur den {\mac}, sowie {\msw} mit dem {\desg} und {\pn {Win32}} f"ur den {\pn {PC}}. Die Kombination {\ty}/{\sv} l"auft auf {\sol} 2.x  bzw.\ {\sos} 5.x, sowie {\mac} und {\winn}.


                          \section{Resource-Editoren}
\label{resed}
Bei Resource-Editoren hat der Oberfl"achen-Entwickler die M"oglichkeit, interaktiv eine Benutzerschnittstelle zu erstellen. Es steht ein Werkzeugkasten zur Verf"ugung, aus dem per {\em Drag \& Drop} Interaktionselemente ausgew"ahlt und plaziert werden k"onnen. W"ahrend des Entwurfs ist das sp"atere Aussehen bereits zu erkennen und kann gegebenenfalls auch sofort wieder ge"andert werden (WYSIWYG-Prinzip {\no} {\em What You See Is What You Get}).
Resource-Editoren erzeugen aus dem graphischen Entwurf eine bin"are Datei, die Resource-Datei.\\
{\sv} bietet den {\de} (siehe Abbildung~\ref{deress}) an. Dieser ist selbst eine {\sv}-Applikation.\\

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=10cm
\epsffile{/usr/users/dbis1/stud/hachmann/Studienarbeit/Bilder/deressou.ps}
\end{center}
\caption{Der {\de}}
\label{deress}
\end{figure}

Resource-Dateien k"onnen manuell erstellt oder vom {\de} automatisch generiert werden. In diesen Dateien ist eine Beschreibung des Aussehens der Benutzeroberfl"ache abgelegt, z.B. Aufbau der Men"us, Art der Eintr"age, standardm"a"sig gesetzte Eigenschaften, Gr"o"se und Position von Dialogboxen, Tastenk"urzel etc.
Ein Vorteil von Resource-Dateien liegt darin, da"s sie f"ur mehrere Anwendungen benutzt werden k"onnen. Resource-Dateien werden getrennt von der Anwendung "ubersetzt; das bedeutet, da"s bei Modifikationen im Programm lediglich die betreffenden Resource-Dateien zu "andern und neu zu "ubersetzen sind. Der folgende Programmkode zeigt ein Beispiel f"ur eine Resource-Datei von {\sv}. Es wird eine Dialogbox mit einem Knopf ''Ok'' und einem Text ''StarView'' beschrieben.

\begin{xple}
/* StarView resource file */
\#pragma CHARSET\_ANSI
\#include ''painterWithResourcesAbout.hrc''
ModalDialog RID\_ABOUTBOX \{
        Hide = TRUE;
        Pos = MAP\_APPFONT( 45, 29 );
        Size = MAP\_APPFONT( 156, 126 );
        Text = ''Paint'';
        Moveable = TRUE;
        OKButton RID\_OK \{
                        Pos = MAP\_APPFONT( 54, 105 );
                        Size = MAP\_APPFONT( 47, 10 );
                        Text = ''$\sim$OK'';
                        TabStop = TRUE;
                        DefButton = TRUE;
                \};
        FixedText RID\_TEXT \{
                        Pos = MAP\_APPFONT( 56, 73 );
                        Size = MAP\_APPFONT( 40, 18 );
                        Text = ''StarView'';
                        Left = TRUE;
                \};
\};
\end{xple}

                       \section{Klassenbibliotheken}
\label{klasse}

Klassen sind rein statische Beschreibungen einer Menge von m"oglichen Objekten \cite{mey88}. In einer Klasse werden nicht individuelle Objekte beschrieben, sondern gemeinsame Eigenschaften (Merkmale und Funktionen) von Objekten. Eine Klasse beschreibt die Struktur einer (eventuell unendlichen) Menge von Objekten. Jedes dieser Objekte wird Exemplar ({\em instance}) dieser Klasse genannt. Klasse ist ein Begriff der "Ubersetzungszeit ({\em compile-time}), w"ahrend Objekte nur zur Laufzeit ({\em run-time}) existieren.\\
Zwischen Klassen k"onnen Vererbungsbeziehungen existieren \cite{mosch92}. Subklassen werden aus Superklassen abgeleitet. Subklassen erben alle Eigenschaften der Superklasse. Die Subklassen k"onnen in den Eigenschaften modifiziert bzw. erweitert werden. Werden aus einer Subklasse weitere Subklassen abgeleitet entsteht eine Klassenhierarchie.
Der Vorteil von Klassenbibliotheken, viel Funktionalit"at zu bieten, kann auch zum Nachteil werden \cite{bor94}. Mit wachsendem Funktionsumfang steigt die Komplexit"at der Bibliotheken und damit der Einarbeitungsaufwand f"ur Entwickler. Abhilfe schaffen hier Klassenhierarchien. Sie sollen nicht nur f"ur die Beibehaltung des {\em look and feel} des jeweils zugrundeliegenden Fenstersystems sorgen, sondern auch dem Entwickler eine einfache Handhabung der Bibliotheken erm"oglichen.\\
Die Abbildung~\ref{hierarchie} zeigt ein Beispiel f"ur die Klassenhierarchie einer Klassenbibliothek, die {\sv} Klassenbibliothek.\\

\begin{figure}[p]
\begin{center}
\leavevmode
\epsfxsize=14cm \epsfysize=16cm
\epsffile{/usr/users/dbis1/stud/hachmann/Studienarbeit/Bilder/sv-classes.epsf}
\end{center}
\caption{Ausschnitt aus der {\sv} Klassenhierarchie}
\label{hierarchie}
\end{figure}
Am AB DBIS wurde bis vor kurzem das {\n} {\pn Toolkit} f"ur {\ol} benutzt. Das {\n} {\pn Toolkit} wurde mit Erscheinen von {\pn Solaris 2.3} nicht mehr von {\sm} unterst"utzt. Da das {\ty}-System inzwischen auch auf andere Plattformen portiert wurde, hat man sich f"ur den Einsatz der systemunabh"angigen Klassenbibliothek {\sv} entschieden.\\



Klassenbibliotheken folgen den Konzepten der objektorientierten Programmierung \cite{markus92}. In einer {\oo}en Sprache (z.B. C++ oder Smalltalk) werden spezielle Klassen zur Verf"ugung gestellt. In diesen speziellen Klassen sind Methoden zusammengefa"st, die die Programmierung von graphischen Benutzerschnittstellen unterst"utzen. Die Funktionalit"at dieser Klassen w"are sonst nur durch eine Vielzahl von Funktionsaufrufen der Fenstersystemschnittstelle zu erreichen. Diese Zusammenfassung der Funktionen verringert die Fehlerquote, da weniger Programmkode anf"allt. Durch {\oo}e Ideen wie Vererbung, Klassen, Modularisierung werden Redundanzen vermieden sowie Datenkapselung und Wiederverwendbarkeit erreicht. \\
Klassen, die nicht ganz den Anforderungen entsprechen, k"onnen durch Definieren einer Subklasse modifiziert bzw. erweitert werden. Alle Eigenschaften der Superklasse, bis auf die ver"anderten, werden an die Subklasse vererbt. Sollen nur wenige bestimmte Eigenschaften ver"andert werden, so "uberschreibt man sie explizit. Der Vorteil ist automatische Konsistenz der anderen Eigenschaften "uber alle Instanzen hinweg.\\
Da bei der Erstellung von Anwendungen mit Bibliotheken der Programmkode von Hand erstellt wird, mu"s die Entwicklerdisziplin sehr gro"s sein, um portablen Kode zu erhalten \cite{isau93b}. 

                  \section{System"ubergreifende Bibliotheken}
\label{sysuebergr}
''System"ubergreifende Bibliotheken ({\em virtual toolkits}) bieten identische Programmierschnittstellen und eine identische Sprache f"ur die Beschreibung von Benutzerschnittstellen f"ur mehrere Systemplattformen an und erm"oglichen so die einfache Portierung von Anwendungsprogrammen auf verschiedene Fenstersysteme'' [Markus~92,~S.~42].\\
System"ubergreifende Bibliotheken stehen zwischen dem Anwendungsprogramm und dem Fenstersystem. Alle Funktionsaufrufe der systemunabh"angigen Programmierschnittstelle werden von der system"ubergreifenden Bibliothek in die entsprechenden Funktionsaufrufe des Fenstersystems umgewandelt. So erreicht man Portabilit"at des Anwendungsprogramms.\\
Die Frage bei der Verschiedenartigkeit der von verschiedenen Fenstersystemen unterst"utzten Funktionen ist: Welche Funktionen soll eine Klassenbibliothek anbieten?
Ein Ansatz ist, da"s nur eine gemeinsame Menge der Funktionalit"at aller Fenstersysteme unterst"utzt wird (Schnittmengenansatz). Das hat zur Folge, da"s das System mit der kleinsten Funktionalit"at alle anderen Systeme auf sich reduziert. Fehlende Komponenten m"ussen vom Programmierer entworfen werden.\\
Eine andere M"oglichkeit ist, alle Funktionen und Elemente aller durch die Klassenbibliothek unterst"utzten Fenstersysteme anzubieten (Obermengenansatz).
Funktionen, die ein System nicht aufweist, daf"ur aber bei einem anderen System verf"ugbar sind, werden durch die Bibliothek nachgebildet [M"u"sig 94].


Systemunabh"angige Bibliotheken k"onnen auch Nachteile haben \cite{isau93a}. H"aufig wird die Plattformunabh"angigkeit der Anwendung durch Abh"angigkeit vom Hersteller der Klassenbibliothek erkauft. So sind Anwendungen, die mit den Produkten StarView oder XVT erstellt worden sind, nicht untereinander austauschbar. 

                      \section{Klassifizierung}
\label{klassifi}
Die Klassifizierung der Werkzeuge erfolgt nach einem Schema aus [F"ahnrich et al. 92]. Dieses Schema (siehe Abbildung~\ref{klassi}) zeigt, da"s es noch mehr Entwicklungswerkzeuge gibt; diese sind bei {\sv} nicht vorhanden.\\
Auf der vertikalen Achse sind die Architekturschichten aufgetragen, die das Werkzeug unterst"utzt. Auf der horizontalen Achse ist der Abstraktionsgrad des Werkzeuges abgetragen. Er steigt von links nach rechts.\\

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=10cm \epsfysize=6cm
\epsffile{/usr/users/dbis1/stud/hachmann/Studienarbeit/Bilder/klassi3.epsf}
\end{center}
\caption{Klassifizierungsschema f"ur Entwicklungswerkzeuge}
\label{klassi}
\end{figure}

Die Anwendungsschichten gliedern sich in Pr"asentationsschicht, Dialogsteuerung und Anwendungslogik. In der Pr"asentationsschicht werden externe Darstellungen der Benutzeroberfl"ache verwaltet, sowie die Interaktion mit dem Anwender erm"oglicht. Die Dialogsteuerung erh"alt die Eingaben des Anwenders von der Pr"asentationsschicht. Die Eingaben werden interpretiert und eine entsprechende Aktion wird ausgef"uhrt. Der Ablauf des Dialoges zwischen Anwender und Anwendung wird also definiert. Die Anwendungsschicht enth"alt die Objekte sowie die eigentlichen Funktionen der Anwendung, die die Objekte bearbeiten.\\

Programmierwerkzeuge wie Fenstersysteme bieten den niedrigsten Abstraktionsgrad. Der Entwickler benutzt sie von allgemeinen Programmiersprachen aus. "Ahnlich ist es mit Klassenbibliotheken und system"ubergreifenden Klassenbibliotheken. Aufgrund des gro"sen Funktionsumfang sind diese Werkzeuge jedoch recht komplex. Bei unzureichender Dokumentation kann gerade der Anf"anger vor der Komplexit"at und dem gro"sen Funktionsumfang resignieren.\\
4GL-Systeme erm"oglichen die textuelle Spezifikation von vollst"andigen Benutzerschnittstellen. In den speziellen Beschreibungssprachen sind Konstrukte f"ur die Beschreibung von Schnittstellenkomponenten, (z.B. Fenstern, Men"us und Kn"opfen, und ihren Darstellungsattributen, wie Position, Gr"o"se und Farbe), enthalten.\\
Strukturierte Editoren haben den h"ochsten Abstraktionsgrad in diesem Schema.\\
"Uber einen Schnittstellenkomponentenbaukasten ist die direktmanipulative Entwicklung, sowie die Attributierung der Komponenten einer graphischen Oberfl"ache m"oglich. Im Hinblick auf den zunehmenden Programmkode bei der Gestaltung von graphischen Oberfl"achen werden immer mehr Klassenbibliotheken mit {\em interface-buildern} verkn"upft \cite{schw94}.\\
Soll die graphische Oberfl"ache zus"atzlich portabel sein, so ist eine system"ubergreifende Klassenbibliothek zu verwenden.\\
Durch die Anbindung der system"ubergreifenden Klassenbibliothek {\sv} an das {\ty}-System kann eine graphische Benutzerschnittstelle dynamisch erzeugt und ver"andert werden. Mit dem {\de} (einem Ressource Editor) von {\sv} k"onnen auf einfache Weise statische Teile einer Benutzerschnittstelle erzeugt werden.
