%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                                    %
% Diplomarbeit von Sven Muessig                                      %
% angefangen am 13-okt-92                                            %
%                                                                    %
% Universitaet Hamburg                                               %
% Fachbereich Informatik                                             %
% Arbeitsbereich DBIS                                                %
%                                                                    %
% Kapitel: Entwicklungswerkzeuge fuer graphische                     %
%          Benutzerschnittstellen                                    %
%                                                                    %
% Version vom 03-jul-94                                              %
%                                                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\cleardoublepage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Entwicklungswerkzeuge f"ur graphische Benutzerschnittstellen}
\label{Kap. Entwicklungswerkzeuge fuer graphische Benutzerschnittstellen}

Wie in der Einleitung kurz angef"uhrt, steht der hohe Aufwand f"ur die 
Erstellung von Anwendungsprogrammen mit graphischer Benutzerschnittstelle
im krassen Gegensatz zu den angestrebten Vereinfachungen bei deren
Bedienung. Die Erstellung von Anwendungsprogrammen mit graphischer
Benutzerschnittstelle ist erheblich schwieriger als die Erstellung anderer
Software. Dies hat verschiedene Ursachen. Sie liegen vor allem im iterativen 
Entwicklungsproze"s, den hohen Geschwindigkeits- und Stabilit"atsanforderungen,
der Mehrproze"sf"ahigkeit, der Notwendigkeit zur Abhandlung asynchroner 
Ereignisse und den Portabilit"atsanforderungen 
\cite{Myers92,MyRo92,FJG92,Meye94}.

Aus den genannten Gr"unden sind verschiedene Ans"atze f"ur Erstellung der 
graphischen Benutzerschnittstelle von Anwendungsprogrammen entwickelt
worden. Als Hauptgrund f"ur den Einsatz solcher Entwicklungswerkzeuge ist
die erhoffte Einsparung bei der Entwicklungszeit der graphischen
Benutzerschnittstelle zu nennen. Weitere Vorteile sind \zB\ die schnelle
Erstellung von Prototypen und die erreichbare Konsistenz "uber 
verschiedene Anwendungen hinweg. Durch die Trennung von
Benutzerschnittstelle und Anwendungsprogramm wird zus"atzlich die Wartung
der beiden Komponenten vereinfacht.

Dadurch ist insbesondere der Bereich der Methoden und Werkzeuge zur
Erstellung von Anwendungsprogrammen mit graphischer Benutzerschnittstelle 
in den Mittelpunkt der Softwareentwicklung ger"uckt. Mittlerweile gibt es
sehr verschiedene Ans"atze, um die aufwendige Entwicklung von Programmen
mit graphischer Benutzerschnittstelle zu unterst"utzen und zu vereinfachen. 
Angefangen von einfachen Toolkits bis hin zu system"ubergreifenden 
Bibliotheken werden in diesem Kapitel einige Ans"atze vorgestellt 
\cite{HWS91,SBS91,Mark92,Myers92,MyRo92,Lee93}. Untersucht wird hierbei,
inwieweit sich die einzelnen Ans"atze dazu eignen, als generischer
Dienst in eine Programmiersprache (hier \tl) integriert zu werden.
Das Hauptaugenmerk liegt dabei auf der M"oglichkeit zur dynamischen
Erzeugung von graphischen Benutzerschnittstellen. Abgeschlossen wird
dieses Kapitel von einer klassifizierenden Zusammenfassung der
vorgestellten Ans"atze.

Die in den folgenden Abschnitten als Beispiele erw"ahnten Produkte sind
in Tabelle \ref{Tb. EW BSS} klassifiziert zusammengefa"st. Es sei noch auf
Kapitel \ref{Kap. Kommerzielle Dienste einer speziellen AU} hingewiesen,
in dem einige der kommerziellen Produkte f"ur \unix-Systeme ausf"uhrlicher
beschrieben werden. 

\begin{table}[htb]
  \begin{center}
    \begin{tabular}{|l||c|c|c|c|}
      \hline
      & \multicolumn{2}{|c|}{\k{Unix}} & \k{Macintosh} & \k{PC} \\
      \hline
      \hline
      \k{Fenstersysteme}       & \x    & \ow  & \fin  & \w \\
      \hline
      \k{Stilrichtlinien}      & \om   & \ol  & \uig  & \desg \\
      \hline
      \k{Bibliotheken}         & \multicolumn{2}{|c|}{\xlib} & \qd   & \wind \\
      \hline
      \k{Toolkits}             & \xt   & \tnt & \tb   & \sdk \\
      \hline
      \k{Ressource-}           & \uil  &      & \res  & \sdkp \\
      \k{Editoren}             &       &      &       & \died \\
      \hline
      \k{Quelltext-Pro-}       &       &      &       & \\
      \k{grammgeneratoren}     &       & \dg  & \appm & \appw \\
      \hline
      \k{Interpreter}          & \tcl  &      & \hc   & \vb \\
      \hline
	  \k{Klassenbibliotheken}  &       &      & \maca & \mfc, \owl \\
      \hline
      \k{System"ubergreifende} & \multicolumn{4}{|c|}{} \\
      \k{Bibliotheken}         & \multicolumn{4}{|c|}{\xvt, \zinc, \sv} \\
      \hline
      \k{4GL-Systeme}          & \multicolumn{2}{|c|}{\iw} & \fd & \acc \\
      \hline
    \end{tabular}
  \end{center}
  \caption{Entwicklungswerkzeuge f"ur graphische Benutzerschnittstellen}
  \label{Tb. EW BSS}
\end{table}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Fenstersysteme}
\label{Abs. Fenstersysteme}

Fenstersysteme (\e{window systems}\,) bilden die Grundlagen von 
direktmanipulativen Benutzerschnittstellen. Der Zugriff auf Fenstersysteme 
erfolgt im einfachsten Fall direkt "uber die dazugeh"origen Bibliotheken.
Die Erstellung von Benutzerschnittstellen auf dieser Ebene erfordert jedoch
einen enorm hohen Programmieraufwand, da alle h"oheren Komponenten aus 
vielen einzelnen Funktionsaufrufen zusammengesetzt werden m"ussen.

Die Funktionalit"at der Bibliotheken h"angt eng mit den Aufgaben der
Fenstersysteme zusammen. Die grundlegenden Aufgaben werden im folgenden
beschrieben. In allen Fenstersystemen werden die Eingaben "uber 
nicht-sequentielle Eingabeger"ate, wie Maus oder Tastatur, abgewickelt.
Das Fenstersystem leitet die Eingaben an die Anwendungen weiter. Die in
Fenstersystemen verwendeten Konzepte und Modelle f"ur die Bilderzeugung, 
die Wiederherstellung besch"adigter Bildausschnitte, die Implementation 
und die M"oglichkeiten zur dynamischen Erweiterung unterscheiden sich
zum Teil erheblich voneinander \cite{Krog92}. "Altere Fenstersysteme 
basieren auf einem pixelorientierten Bilderzeugungsmodell (\e{pixel 
oriented model}\,). In solchen Systemen wird die Farbe f"ur jedes Pixel 
in einem festen Koordinatensystem bestimmt und ausgegeben. In neueren 
Fenstersystemen werden schablonenorientierte Bilderzeugungsmodelle
(\e{stencil-paint imaging model}\,) verwendet. Dabei wird die Farbe nicht
f"ur einzelne Pixel bestimmt, sondern durch \e{F"ullen} von Schablonen 
f"ur Fl"achen. Dadurch sind schablonenorientierte Modelle von Aufl"osung
und Farbanzahl des Ausgabeger"ats unabh"angig.

Auf den untersuchten Plattformen existieren \ua\ die folgenden Fenstersysteme
mit den dazugeh"origen Stilrichtlinien und Bibliotheken: \x\ mit \om\ und der
\xlib, \ow\ mit \ol\ (\VAS\ \ref{Abs. Die OPEN LOOK Anwenderschnittstelle})
und der \xlib\ f"ur \unix-Systeme, der \fin\ mit den \uig\ und \qd\ f"ur den
\mac\ sowie \msw\ mit dem \desg\ und \wind\ f"ur \pcpc's.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Toolkits}
\label{Abs. Toolkits}

Toolkits sind Bibliotheken, die von den Bibliotheken der Fenstersysteme 
abstrahieren. Toolkits stellen die durch die Stilrichtlinien (\e{style 
guides}\,) definierten Schnittstellenkomponenten (\e{widgets}\,), wie
Men"us (\e{menus}\,), Kn"opfe (\e{buttons}\,), Rollbalken (\e{scroll bars}\,),
Dialogboxen usw.\ zur Verf"ugung. Zus"atzlich vereinfacht sich mit Toolkits
auch die Ereignisverwaltung gegen"uber den Bibliotheken der Fenstersysteme.

Sowohl die Bibliotheken der Fenstersysteme als auch die Toolkits stellen 
\idR\ keine h"oheren Dialogkomponenten, wie \zB\ zur Dateiauswahl
(\e{file selection}\,) oder zur Datensatzbearbeitung, zur Verf"ugung.
Solche Dialogkomponenten m"ussen aus einzelnen Schnittstellenkomponenten 
selbst aufgebaut werden.

In Abschnitt \ref{Abs. Das NeWS Toolkit} wird mit dem \tnt\ f"ur \ol\ 
eine solche Bibliothek ausf"uhrlicher vorgestellt.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Ressource-Editoren}
\label{Abs. Resource-Editoren}

Ressource-Editoren (\e{resource editors}\,) erm"oglichen die Erstellung 
von Benutzerschnittstellen durch \e{direkte Manipulation} \cite{IlZi88,Krog92}.
Die Schnittstelle eines Anwendungsprogramms wird interaktiv aus den in einem
Werkzeugkasten zur Verf"ugung gestellten Schnittstellenkomponenten aufgebaut.
Der Vorteil des bei dieser Art des Entwurfs angewandten \e{WYSIWYG}-Prinzips
(\e{What You See Is What You Get}\,) ist, da"s bereits w"ahrend der Erstellung
der Benutzerschnittstelle das Aussehen validiert werden kann. Das Resultat 
ist eine Ressource-Datei. Zus"atzlich werden die Definitionen der verwendeten
Konstanten und Bezeichner f"ur Schnittstellenkomponenten in Form einer 
\e{Include}-Datei ausgegeben, die f"ur die Kopplung der Elemente der 
graphischen Benutzerschnittstelle mit dem Kode des Anwendungsprogramms 
erforderlich sind.

Diese Vorgehensweise verringert zwar den Programmieraufwand erheblich, hat
aber den Nachteil, da"s nur weitgehend statische Benutzerschnittstellen 
erzeugt werden k"onnen. Sobald sich die Struktur der anzuzeigenden Objekte
"andert, mu"s auch die Ressource-Datei ge"andert werden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Quelltext-Programmgeneratoren}
\label{Abs. Quelltext-Programmgeneratoren}

Quelltext-Programmgeneratoren (\e{interface builder}\,) erm"oglichen wie
Ressource-Edi\-to\-ren die interaktive Erstellung von Benutzerschnittstellen
aus den in einem Werkzeugkasten zur Verf"ugung gestellten 
Schnittstellenkomponenten. Dar"uber hinaus erlauben
Quell\-text-Pro\-gramm\-generatoren auch, Teile des Programmablaufs des zu
erstellenden Anwendungsprogramms festzulegen und in einem Test-Modus zu 
simulieren.

Aus der interaktiv erstellten Benutzerschnittstelle k"onnen anschlie"send
Quelltext-Dateien generiert werden. Dazu z"ahlen die Ressource-Datei, eine 
Datei mit dem Quelltext des erstellten Anwendungsprogramms in Hochsprachenform,
\zB\ \cc\ oder \cpp, sowie eine \e{Make}-Datei, in der alle f"ur die Erzeugung
eines lauff"ahigen Programms mit einem "Ubersetzer (\e{compiler}\,) und Binder
(\e{linker}\,) erforderlichen Schritte und die Abh"angigkeiten der einzelnen
Dateien voneinader enthalten sind. Der Programmierer mu"s noch die 
Anwendungsfunktionen spezifizieren.

Auch Quelltext-Programmgeneratoren eignen sich nur f"ur die Erstellung von
weitgehend statischen Benutzerschnittstellen. In Abschnitt 
\ref{Abs. Developers Guide} wird mit dem \dg\ von \sm\ ein
Quelltext-Programmgenerator f"ur \ol\ vorgestellt.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Interpreter-Entwicklungsumgebungen}
\label{Abs. Interpreter-Entwicklungsumgebungen}

Interpreter besitzen gegen"uber "Ubersetzern den Vorteil, da"s 
die Entwicklungszeit bei der Erstellung von Anwendungsprogrammen verk"urzt
wird. Alle eingegebenen Programmzeilen werden sofort auf Korrektheit 
"uberpr"uft. Ist eine eingegebene Zeile fehlerfrei, wird sie sofort in 
eine f"ur den Computer ausf"uhrbare Form umgewandelt. Durch inkrementelles
Binden von Bibliotheken wird die Entwicklungszeit zus"atzlich verk"urzt.

Zur Laufzeit dagegen sind Interpreter den "Ubersetzern unterlegen, da ein
Laufzeitinterpreter (\e{runtime interpreter}\,) bei jeder 
Programmausf"uhrung die Zeilen wieder neu interpretieren mu"s. Abhilfe 
schaffen hier zus"atzliche "Ubersetzer, die nach Abschlu"s der Entwicklung 
selbst"andig ablauff"ahige Programme erzeugen.

Zu einer Interpreter-Entwicklungsumgebung geh"ort \idR\ ein 
Ressource-Editor, mit dem die Benutzerschnittstelle interaktiv
erzeugt wird. Die Entwicklungsumgebung erzeugt daraus automatisch 
Prozedur\-k"op\-fe f"ur die verwendeten Schnittstellenkomponenten.
Damit entf"allt f"ur den Anwendungsprogrammierer die Notwendigkeit
explizit eine Verbindung zwischen einer Schnittstellenkomponente
und den Prozeduren, die ausgef"uhrt werden sollen, wenn die
Schnittstellenkomponente manipuliert wird, herzustellen.

Eine \zZt\ sehr verbreitete Entwicklungsumgebung ist \vb\ (\VAS\ 
\ref{Abs. VisualBasic}) von \ms. Es vereinfacht die Erstellung von 
\w-Programmen gegen"uber anderen Ans"atzen, wie \zB\ \cc\ und \sdk\
(\e{Software Development Kit}\,), erheblich. 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Klassenbibliotheken}
\label{Abs. Klassenbibliotheken}

Klassenbibliotheken vereinfachen die Entwicklung von Anwendungsprogrammen
mit graphischer Benutzerschnittstelle, indem sie objektorientierten Sprachen,
wie \zB\ \cpp\ oder \st, spezielle Klassen zur Verf"ugung stellen. Die Klassen
definieren Schnittstellenkomponenten und dazugeh"orige Methoden zur 
Manipulation der Instanzen. Die Klassen beinhalten die Funktionalit"at, die
ansonsten nur durch eine Vielzahl von Bibliotheksaufrufen erreichbar ist.
Durch die Zusammenfassung der immer wieder ben"otigten Funktionsaufrufe
verringert sich die Fehlerquote, da weniger Programmkode geschrieben werden
mu"s.

Entsprechen die von einer Klasse zur Verf"ugung gestellten Instanzen nicht
den gestellten Anforderungen, so kann eine Subklasse erzeugt werden, in der
die entsprechenden Eigenschaften modifiziert bzw.\ erweitert werden. Alle
Instanzen dieser Subklasse erben dabei grunds"atzlich alle Eigenschaften
der Klasse, au"ser denen, die explizit "uberschrieben werden. Dadurch
m"ussen jeweils nur Details ge"andert werden, w"ahrend alle anderen
Eigenschaften weiterhin automatisch konsistent sind.

Ein \e{Class Browser} erm"oglicht die einfache "Ubersicht "uber die im
System vorhandenen Klassen mit den dazugeh"origen Vererbungsbeziehungen
und Methoden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{System"ubergreifende Bibliotheken}
\label{Abs. Systemuebergreifende Bibliotheken}

System"ubergreifende Bibliotheken (\e{virtual toolkits}\,) bieten
identische Programmierschnittstellen und eine identische Sprache f"ur die
Beschreibung von Benutzerschnittstellen f"ur mehrere Systemplattformen an
und erm"oglichen damit die einfache Portierung von Anwendungsprogrammen
auf verschiedene Fenstersysteme \cite{Isau93}. Anwendungsentwickler 
k"onnen nach diesen Spezifikationen entwickelte portable Quelltexte auf
allen unterst"utzten Systemen ohne Modifikation in ausf"uhrbare Programme 
umwandeln.

Erreicht wird diese Portabilit"at durch eine Bibliothek, die zwischen dem
Anwendungsprogramm und dem Zielfenstersystem arbeitet. Eine derartige 
Bibliothek wandelt alle Funktionsaufrufe der systemunabh"angigen 
Programmierschnittstelle in die entsprechenden Funktionsaufrufe des 
Fenstersystems um. In der Gegenrichtung werden alle vom Fenstersystem
erzeugten Ereignisse in eine systemunabh"angige Darstellung umgewandelt.

Allerdings ergeben sich aus der Verschiedenartigkeit der von den einzelnen
Fenstersystemen unterst"utzten Funktionen Probleme. Die einfachste L"osung 
ist der \e{Schnittmengenansatz}, bei dem nur Funktionen angeboten werden, 
die auf allen unterst"utzten Systemen verf"ugbar sind und somit den kleinsten
gemeinsamen Nenner darstellen. Das f"uhrt zu einer Beschr"ankung des
Funktionsumfangs auf die Funktionen des schw"achsten durch die Bibliothek
unterst"utzten Fenstersystems.

Dagegen werden beim \e{Obermengenansatz} alle Funktionen und Elemente aller
unterst"utzten Fenstersysteme durch die Bibliothek verf"ugbar gemacht. Fehlt
in einem System eine auf einem anderen System verf"ugbare Funktion, so wird
diese Funktion durch die Bibliothek nachgebildet. Diese Vorgehensweise
erlaubt es auch, den Funktionsumfang aller Bibliotheken um komplexere
Funktionen zu erweitern.

System"ubergreifende Bibliotheken haben aber auch Nachteile. Zum Beispiel
wird die Unabh"angigkeit von Systemplattformen durch eine neue Abh"angigkeit
vom Bibliothekshersteller teilweise wieder kompensiert.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{4GL-Systeme}
\label{Abs. 4GL-Systeme}

Sprachen der vierten Generation (\e{fourth generation languages}, 4GL's)
sind meist Bestandteil eines Datenbanksystems. In solchen Systemen sind 
oft Editoren zur Gestaltung der graphischen Benutzerschnittstelle durch
direkte Manipulation zu finden. Im Gegensatz zu Quelltext-Programmgeneratoren
sind sie jedoch speziell auf den Einsatz in Datenbankumgebungen abgestimmt.
In diesem Anwendungsgebiet weisen 4GL's eine erweiterte Funktionalit"at auf,
die "uber das bei Quelltext-Programmgeneratoren "ubliche Ma"s hinausgeht.
Zum Beispiel k"onnen die im Datenw"orterbuch (\e{data dictionary}\,)
vorhandenen Typinformationen dazu genutzt werden, um automatisch 
Bildschirmmasken zu erstellen. Durch diese Spezialisierung treten Defizite
in anderen Bereichen auf, f"ur deren Einsatz sie nicht speziell 
ausgerichtet sind.

Neben der Gestaltung der graphischen Benutzerschnittstelle bieten sie die
M"oglichkeit, den Programmablauf des zu erstellenden Anwendungsprogramms
festzulegen. Dabei stehen in Abh"angigkeit von der M"achtigkeit der 
4GL-Programmiersprache unterschiedliche Konzepte zur Verf"ugung. Nachteile
solcher Systeme sind das oft eingeschr"ankte Datenmodell, die fehlende
M"oglichkeit zur Integration neuer Dienste und der fehlende Polymorphismus.

In Abschnitt \ref{Abs. INGRES} wird mit \iw\ ein 4GL-System f"ur
unterschiedliche Hard- und Softwareplattformen vorgestellt. 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Zusammenfassung und Klassifizierung}
\label{Abs. Zusammenfassung und Klassifizierung}

In diesem Abschnitt werden die vorgestellten Ans"atze nach zwei Kriterien 
klassifiziert. Dazu wird in Abbildung \ref{Abb. Entwicklungswerkzeuge} 
ein zweidimensionales Klassifizierungsschema vorgestellt. Auf der
vertikalen Achse sind die durch das Werkzeug unterst"utzten
Architekturschichten aufgetragen und auf der horizontalen Achse ist der
Abstraktionsgrad des Werkzeuges zu finden \cite{FJG92}.

\begin{figure}[htb]
  \psbild{0.84#1}{gui}{Ansaetze.ps}
  \caption{Klassifizierungsschema f"ur Entwicklungswerkzeuge (nach 
           \protect\cite{FJG92})}
  \label{Abb. Entwicklungswerkzeuge}
\end{figure}

Zun"achst werden die auf der vertikalen Achse aufgetragenen 
Architekturschichten beschrieben. Die Pr"asentationskomponente
verwaltet zum einen die externen Darstellungen der Benutzerschnittstelle
und erm"oglicht zum anderen die Interaktion mit dem Anwender. Die
Dialogsteuerung definiert den Ablauf des Dialoges zwischen Anwender
und Anwendung. Die Anwendungsschicht enth"alt die eigentlichen 
Funktionen der Anwendung sowie die Objekte, die mit diesen Funktionen
bearbeitet werden. 

Auf der horizontalen Achse w"achst von links nach rechts der 
Abstraktionsgrad des Werkzeuges. Programmierwerkzeuge wie Bibliotheken
und Toolkits besitzen den niedrigsten Abstraktionsgrad. Sie werden von
allgemeinen Programmiersprachen aus benutzt. "Ahnlich sieht es f"ur 
Klassenbibliotheken und system"ubergreifende Bibliotheken aus. Der
Vorteil dieser Ans"atze ist der gro"se Funktionsumfang und die
daraus resultierende M"achtigkeit und Flexibilit"at der Werkzeuge. 
Dieser Vorteil kann jedoch bei unzureichender Dokumentation auch zum 
Nachteil werden, da vor allem Anf"anger vor der M"achtigkeit und dem
enormen Funktionsumfang resignieren.
Interpreter-Ent\-wick\-lungs\-um\-ge\-bun\-gen haben den Vorteil der
vollst"andigen Integration aller drei Architekturschichten.

Die textuelle Spezifikation von vollst"andigen Benutzerschnittstellen
bzw.\ der Pr"asentationskomponente wird durch spezielle
Beschreibungssprachen erm"oglicht. Solche Sprachen enthalten Konstrukte
f"ur die Beschreibung von Schnittstellenkomponenten, \zB\ Fenstern,
Men"us, Kn"opfen und Texteingabefeldern, und ihren Darstellungsattributen,
wie Position, Gr"o"se und Farbe.

Strukturierte Editoren vereinfachen die Erstellung von graphischen
Benutzerschnittstellen weiter. F"ur die direktmanipulative Entwicklung
der Pr"asentationskomponente gibt es Ressource-Editoren, 
mit deren Hilfe die Auswahl und die Attributierung der 
Schnittstellenkomponenten vorgenommen werden kann. Dar"uber hinaus 
erleichtern spezielle Quell\-text-Pro\-gramm\-ge\-ne\-ra\-to\-ren 
zus"atzlich die Spezifikation der Dialogabl"aufe und die Verwaltung
der vom Dialogmodell abh"angigen Sprachkonstrukte in einem 
ereignisorientierten Modell \cite{FJG92}.

Zusammenfassend kann festgestellt werden, da"s nur 4GL-Systeme f"ur die 
Entwicklung der graphischen Benutzerschnittstelle von datenintensiven
Anwendungen eine ausreichende Unterst"utzung bieten. Dieses System ist
jedoch f"ur die Integration als generischer Dienst in eine 
Programmiersprache ungeeignet, da es alle drei vertikalen Ebenen (\VAB\ 
\ref{Abb. Entwicklungswerkzeuge}) selbst abdeckt.

F"ur die Integration als generischer Dienst in eine allgemeine
Programmiersprache ist die Kombination aus Klassenbibliothek und
Quelltext-Programmgenerator zu empfehlen. Klassenbibliotheken besitzen
die bekannten Vorteile objektorientierter Systeme (\VGL\ \cite{Watt90}). 
Wird zus"atzlich eine portable Oberfl"ache ben"otigt, so ist die 
Verwendung von system"ubergreifenden Bibliotheken anzuraten.
Benutzerschnittstellen k"onnen durch Anbindung der Bibliothek an eine 
Programmiersprache dynamisch erzeugt und ver"andert werden. Ein 
Quelltext-Programmgenerator erlaubt dar"uber hinaus, statische Teile 
der Benutzerschnittstelle auf einfache Weise zu erstellen. Die
Anbindung erfolgt auch hier "uber eine Bibliothek.

Die f"ur die Implementation verwendete Entwicklungsumgebung besteht aus
den folgenden Komponenten:

\blist
  \item \ty-System (\VAS\ \ref{Abs. Systemintegration im Tycoon-System})
  \item \tnt\ (\VAS\ \ref{Abs. Das NeWS Toolkit})
  \item \dg\ (\VAS\ \ref{Abs. Developers Guide})
\elist

Eine Schnittstelle vom \ty-System zum \tnt\ erm"oglicht die dynamische
Erzeugung von graphischen Benutzerschnittstellen. Dar"uber hinaus ist es
"uber diese Schnittstellen auch m"oglich, statische, mit dem \dg\ 
erzeugte Benutzerschnittstellen anzubinden.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% End of text                                                        %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
