\chapter{Grafische Gestaltung der Daten-- und Funktionsvisualisierung}
\label{Gestaltung}
Grundlage f"ur die Realisierung des in Abschnitt
\ref{Datenvisualisierungsansatz} beschriebenen Ansatzes zur Daten-- und
Funktionsvisualisierung bildet die grafische Gestaltung der zu visualisierenden
Objekte. Durch die Wahl geeigneter Bildschirmrepr"asentationen soll dem
Anwender ein intuitives Verst"andnis der dargestellten Typen und Werte
vermittelt werden. Da sich das {\sf Tycoon} System unter anderem durch seine
Offenheit auszeichnet, das die uniforme Verwendung externer Diensterbringer in
{\sf TL} erlaubt, erfolgt die Realisierung der Daten-- und
Funktionsvisualisierung mit Hilfe der system"ubergreifenden Klassenbibliothek
{\sf StarView} \cite{BKJ93}. Sie ist im Rahmen von \cite{Geis95} an das {\sf
Tycoon System} angebunden worden und bietet eine Reihe von Basisfunktionalit"at
zur Erzeugung und Verwaltung grafischer Objekte an, so da"s die Erstellung
grafischer Visualisierungsschnittstellen durch den Programmierer vereinfacht
wird. Die wesentlichen Konzepte und Elemente von {\sf StarView} werden im
ersten Abschnitt dieses Kapitels vorgestellt und beeinflu"sen die im zweiten
Abschnitt betrachtete grafische Gestaltung der zu visualisierenden Werte und
Typen.


\section{Die grafische Klassenbibliothek StarView}
{\sf StarView} ist eine in der Programmiersprache {\sf C++} \cite{ElSt90}
implementierte Klassenbibliothek, die die Entwicklung grafischer Anwendungen 
unterst"utzt. Sie ist auf vielen verschiedenen Fenstersystemen wie 
beispielsweise {\sf Solaris}, {\sf Microsoft Windows} sowie {\sf Apple
Macintosh System 7} unter {\sf MPW 3.3} einsetzbar. Der mit {\sf StarView}
erzeugte Programmkode ist portabel, so da"s von den Eigenheiten des 
jeweiligen Fenstersystems abstrahiert werden kann. Trotzdem bleibt aber das 
jeweilige {\em look$\&$feel} des Fenstersystems erhalten. Damit unterscheidet
sich {\sf StarView} von grafischen Entwicklungswerkzeugen, die nur f"ur ein
spezielles Fen\-ster\-sys\-tem entwickelt worden sind, wie z.B. das 
{\sf NeWS Toolkit} \cite{SunS92}, das f"ur die Darstellung von Editoren in 
{\sf Tycoon} verwendet wurde \cite{Mues94}. Die Portabilit"at wird erreicht, 
indem die Eigenheiten des jeweiligen Fenstersystems in den Methoden der 
entsprechenden Klassen ber"ucksichtigt werden. Allerdings existieren auch 
Funktionalit"aten, die nicht auf allen Fenstersystemen vorhanden sind wie 
beispielsweise die Ikonifizierung von Fenstern auf dem {\sf Apple Macintosh}. 
Da diese Funktionalit"aten jedoch nicht "uberall nachgebildet sind, gilt der
Grundsatz der Portabilit"at nur, wenn der Kode ausschlie"slich Methoden
enth"alt, die auch auf allen Fenstersystemen implementiert sind. Dieser Ansatz
erscheint verbesserungsw"urdig, da der Programmierer wissen mu"s, welche
Methoden diese Bedingung erf"ullen.

Anhand der wichtigsten Klassen gibt Abbildung \ref{Klassen}\footnote{entnommen
aus \cite{BKJ93}} einen "Uberblick "uber Aufbau und Umfang der
Klassenbibliothek von {\sf StarView}.

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{klassen.epsf}
\end{center}
\caption{Ausschnitt aus der {\sf StarView} Klassenhierarchie}
\label{Klassen}
\end{figure}


\subsection{Die StarView Klassenhierarchie}
Die zentrale Basisklasse f"ur alle {\sf StarView} Applikationen ist die Klasse
{\sl Application\/}. Von ihr werden alle Applikationen abgeleitet. Durch das
"Uberladen ihrer virtuellen Methoden kann eine neue Applikation um die
gew"unschte Funktionalit"at erweitert werden. Die f"ur die Datenvisualisierung
ben"otigten GUI Elemente sollen in diesem Abschnitt "uberblicksartig
vorgestellt werden.

\begin{description}
\item[Fenster:] Sie dienen der Pr"asentation von Applikationsdaten, der
Entgegennahme von Eingabedaten "uber sogenannte Interaktionselemente und deren
Verarbeitung. Die Klasse {\sl Window\/} stellt die Basisfunktionalit"at zur
Verf"ugung, die allen Fenstern gemein ist. Nur Fenster, die von der Klasse {\sl
SystemWindow\/} abgeleitet sind, k"onnen als eigenst"andige Einheiten auf dem
Bildschirm erzeugt und positioniert werden. Von diesen h"angen alle anderen
Fenster durch eine bei ihrer Erzeugung definierte und dynamisch
rekonfigurierbare Eltern--Kind--Relation transitiv ab. Ihre Positionierung
erfolgt relativ zu ihrem Elternfenster. In jeder {\em StarView} Anwendung mu"s
genau ein als Applikationsfenster ausgezeichnetes Fenster der Klasse {\sl
WorkWindow\/} exisistieren. Eine Interaktion ist nur mit Fenstern m"oglich, die
den Fokus besitzen. 
\item[Kontrollelemente:] Sie sind abgeleitet von der Klasse {\sl Control\/} und
umfassen unter anderem Kn"opfe, Listen, Men"us, Rollbalken, Editierfelder und
die Darstellung von Zeichenketten. Der Anwendungsprogrammierer hat dar"uber
hinaus die M"oglichkeit, eigene von bereits existierenden Kontrollelementen
abgeleitete Kontrollfelder zu definieren. Es werden statische und aktive
Kontrollelemente unterschieden. Die aktiven Kontrallelemente erm"oglichen
Dateneingaben "uber Maus oder Tastatur, w"ahrend die statischen lediglich der
Pr"asentation von Daten dienen. Formatierte Eingaben sind "uber speziell
definierte Formatierungsklassen, z.B. {\sl NumericFormatter\/} f"ur Zahlen oder
{\sl DateFormatter\/} f"ur Datumseingaben, m"oglich. Jedes Interaktionselement
kann vom Benutzer mit Funktionen verkn"upft werden, die bei bestimmten, von der
jeweiligen Klasse festgelegten Benutzeraktionen, z.B. der Auswahl eines
Listeneintrags, ausgef"uhrt werden.
\item[Dialoge:] Sie erlauben es, Interaktionselemente in einem Fenster 
zusammenzufassen. Im Gegensatz zu Fenstern der Klasse {\sl WorkWindow} wird der
Fokuswechsel zwischen den verschiedenen in ihnen dargestellten
Kontrollelementen und Kontrollgruppen  gesteuert, so da"s deren geordnete
Abarbeitung m"oglich ist. Es wird unterschieden zwischen modalen und
nichtmodalen Dialogen. Modale Dialoge m"ussen beendet sein, bevor innerhalb der
Anwendung fortgefahren werden kann. Einige vordefinierte modale Dialoge
unterst"utzen die Anzeige verschiedenartiger Statusinformationen sowie
die Kommunikation mit verschiedenen Systemdiensten.
\item[Datenaustausch:] Es werden zwei Arten des formatierten Datentransfers
zwischen Anwendungen sowie innerhalb einer Anwendung unterst"utzt --- "uber das
Klemmbrett oder per {\em Drag$\&$Drop}. Das Klemmbrett stellt eine Art
Zwischenspeicher dar, in dem Daten abgelegt und als Kopie wieder abgerufen
werden k"onnen. Es handelt sich dabei um ein standardisiertes Verfahren der
Fenstersysteme, das durch die Klasse {\sl Clipboard\/} implementiert ist. Es
kann zu einem Zeitpunkt nur ein Objekt, allerdings in verschiedenen Formaten,
im Klemmbrett abgelegt werden. Beim {\em Drag$\&$Drop} Verfahren kann der
Benutzer ein Objekt mit der Maus anklicken und bei gedr"uckter Maustaste eine
Kopie davon "uber den Bildschirm ziehen. Wird die Maustaste losgelassen, so
wird die Kopie von dem  Objekt entgegengenommen, "uber dem sich der Mauszeiger
gerade befindet. Handelt es sich bei dem empfangenden Objekt nicht um ein
Interaktionselement, so geht die Kopie verloren. Dieses Verfahren wird mit Hilfe
der Klassen {\sl DragServer\/} und {\sl DropEvent\/} implementiert.
\end{description}


\subsection{Ereignisbearbeitung}
Bestimmte Ereignisse wie Benutzereingaben oder das Auftreten von Fehlern werden
von {\sf StarView} behandelt, indem benutzerdefinierte Funktionen, sogenannte
{\em Event Handler}, aufgerufen werden. Der Benutzer kann so programmtechnisch
auf diese Ereignisse reagieren und entsprechend den Anforderungen des
Programmes bestimmte Aktionen ausl"osen. Dazu stehen zwei Verfahren zur
Verf"ugung:

\begin{itemize}
\item Virtuelle Methoden k"onnen in abgeleiteten Klassen "uberladen werden.
\item Einige der {\em Event Handler} k"onnen mit einer Methode "uber einen  
sogenannten {\em Link} durch eine spezielle Methode zur Installierung des 
{\em Event Handlers} verkn"upft werden. 
\end{itemize}

\noindent Virtuellen Methoden werden bei solchen Klassen verwendet, von denen
in der Regel eigene Klassen abgeleitet werden. So kann beispielsweise die
Methode zum Zeichnen des Fensterinhaltes in jeder von {\sl Window\/}
abgeleiteten Klasse "uberladen werden. In {\sf TL} werden virtuelle Methoden
als  Attribute einer Klasse aufgefa"st, f"ur die ein Paar von Schreib-- und
Lesefunktionen erzeugt wird.

F"ur Ereignisse in Klassen, von denen der Benutzer in der Regel keine eigenen
Klassen ableiten mu"s, wie z.B. bei den aktiven Kontrollfeldern, sind die
{\em Event Handler} vorgesehen. Die Ereignisbearbeitung, die die mit einem
bestimmten Ereignis assoziierte Methode aufruft, wird durch das Fenstersystem
gesteuert.


\subsection{Einbindung der Klassenbibliothek in das Tycoon System}
In diesem Abschnitt soll die Anbindung der {\sf
StarView} Klas\-sen\-bib\-lio\-thek an das {\sf Tycoon} System
"uberblicksartig erl"autert werden (s. Abb. \ref{Anbindung}\footnote{entnommen
aus \cite{Geis95}}). Eine detailliertere Beschreibung dazu befindet sich in
\cite{Geis95}.

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{anbindung.epsf}
\end{center}
\caption{Anbindungsszenario f"ur {\sf StarView}}
\label{Anbindung}
\end{figure}

\subsubsection{Das StarView Gateway}
Die Einbindung erfolgt mit Hilfe des sogenannten {\em StarView Gateways}. Dabei
handelt es sich um eine Softwarekomponente des {\sf Tycoon} Systems, die die
erforderlichen Bindungen zur auf einem {\em C++ Server} befindlichen
{\sf StarView} Klassenbibliothek enth"alt. Es stellt dem {\sf
TL} Programmierer die Methoden der {\sf StarView} Klassenbibliothek in
transparenter Form zur Ver\-f"u\-gung. Damit wird von der Existenz eines
externen {\em C++ Servers} abstrahiert und die Bibliothek kann gem"a"s der
{\sf TL} Syntax und {\sf TL} Semantik benutzt werden.

Mit Hilfe eines {\em Gateway Generators}, der die Beschreibung der {\em Header}
Dateien der Klassenbibliothek durch die Schnittstellenbeschreibungssprache {\sf
GDL} erh"alt, wird das {\em Gateway} zur {\sf StarView} Klassenbibliothek
generiert. Es besteht aus den den {\sf C++} Klassen entsprechenden {\sf TL}
Modulen und Schnittstellen sowie den {\sf C++} Dateien, in denen jeweils eine
Subklasse der zugeh"origen {\sf C++} Klasse generiert wird und alle
nicht-virtuellen Methoden in {\sf C} Funktionen verpackt und exportiert
werden. Bindungen zwischen dem {\sf Tycoon} System und dem {\sf 
StarView} Server werden mittels der bidirektionalen Schnittstelle zwischen
{\sf TL} und {\sf C} \cite{MMM93} realisiert.


\subsubsection{Inkrementelle Entwicklung}
Ein {\sf StarView} Anwendungsprogramm besteht "ublicherweise aus drei Teilen:

\begin{enumerate}
\item Definition der statischen Struktur der grafischen Interaktionselemente
(Fenster, Men"us, Dialoge etc.)
\item Installierung der benutzerdefinierten Aktionen
\item Starten der Ereignisbearbeitung
\end{enumerate}

\noindent Mit dem Start der Ereignisbearbeitung, hinter der sich die
Ereignisschleife ({\em Eventloop}) des Basisfenstersystems verbirgt, werden 
die erzeugten Objekte auf dem Bildschirm sichtbar und k"onnen Eingaben und 
Ereignisse von {\sf StarView} verarbeitet werden. Erst wenn das
App\-li\-ka\-tions\-fens\-ter geschlossen wird, werden die Ereignisschleife 
wieder verlassen und die Anwendung beendet.

Da die Ereignisschleife Bestandteil eines {\sf StarView} Programmes ist und
durch inkrementelle "Ubersetzung "Anderungen des Programmes nur bei gestarteter
Ereignisschleife sichtbar werden, mu"s die Ereignisschleife erst beendet und 
wieder neu gestartet werden, bevor die Programm"anderungen wirksam werden. 
Eine typische Anwendung der generischen Daten-- und Funktionsvisualisierung 
ist jedoch die Anbindung an die {\sf Tycoon} Programmierwerkbank, in der die 
Ergebnisse von Berechnungen visualisiert werden. Es ist beim Start der
Programmierwerkbank nicht bekannt, welche {\sf StarView} Objekte erzeugt und
auf dem Bildschirm angezeigt werden sollen, sondern es werden inkrementell neue
grafische In\-ter\-akt\-ions\-ele\-men\-te erzeugt, die auf dem Bildschirm
sofort sichtbar sein sollen.

Die L"osung dieses Problems erfolgt in {\sf Tycoon} durch die M"oglichkeit,
mehrere Kontrollfl"usse ({\em threads of control}) auf demselben Zustand
operieren lassen zu k"onnen \cite{MaSc94}. Indem man f"ur die 
{\em Eventloop} einer {\sf StarView} Anwendung und den {\sf TL} 
{\em Top Level} eigene Kontrollfl"usse definiert, kann durch inkrementelle 
"Ubersetzungen innerhalb des {\sf TL} {\em Top Levels} eine {\sf StarView}
Anwendung dynamisch ge"andert werden. Die Auswirkungen dieser "Anderungen sind
dann sofort sichtbar.


\subsection{Erfahrungen mit der Einbindung}
Ohne gr"o"sere Probleme lie"s sich mit Hilfe des oben beschriebenen Verfahrens
die {\sf StarView} Klassenbibliothek unter {\sf Solaris} und {\sf Microsoft
WindowsNT} in das {\sf Tycoon} System einbinden. Unter {\sf MPW 3.3} auf dem
{\sf Apple Macintosh System 7} traten jedoch mehrere Probleme auf, die
sowohl an der Implementierung von {\sf StarView} als auch an den Eigenheiten
des Betriebssystems {\sf System 7} liegen.

Auf dem {\sf Apple Macintosh} erfolgt die Interaktion des Benutzers mit dem
System innerhalb von Applikationen, von denen zu einem Zeitpunkt jedoch immer
nur eine aktiv ist und  die Kommunikation zwischen dem Benutzer und dem System
"ubernimmt \cite{Appl85}. Der Wechsel zwischen zwei Applikationen mu"s 
explizit per Mausdruck oder Tastatureingabe erfolgen. Applikationen, die die 
{\sf StarView} Klassenbibliothek verwenden, m"ussen immer aus {\sf StarView} 
heraus gestartet werden. Deshalb ist der {\sf TL} {\em Top Level}, auf dem die
"Ubersetzung und Ausf"uhrung von Programmkode durchgef"uhrt wird, selbst
Bestandteil eines {\sf StarView} Programmes und befindet sich innerhalb der
{\sl main\/} Methode der Klasse {\sl Application\/}. Der {\em Top Level} ist 
in der aktuellen Portierung auf den {\sf Apple Macintosh} jedoch mit Hilfe von 
{\em TextEdit}, einem Werkzeug der Benutzerschnittstelle zum {\sf Apple 
Macintosh} Betriebssystem zur Entwicklung von Editoren, implementiert. Die 
Verwaltung von Ereignissen, die {\em TextEdit} betreffen, erfolgt durch den 
{\em Toolbox Event Manager} des {\sf Apple Macintosh}. Wird vom {\em TopLevel} 
jedoch eine {\sf StarView} Anwendung gestartet, so sind zwei Applikationen 
gleichzeitig aktiv. Der {\em Toolbox Event Handler} kann jedoch die Ereignisse 
der {\sf StarView} Applikation nicht verarbeiten, so da"s der Rechner 
abst"urzt, sobald die Maus "uber ein {\sf StarView} Fenster bewegt wird. Im 
Moment existieren zwei M"oglichkeiten, dieses Problem zu l"osen:

\begin{enumerate}
\item Sobald die Ereignisschleife von {\sf StarView} gestartet wird, wird die
Ereignisschleife des {\em Toolbox Event Managers} eingefroren und es sind keine
Eingaben auf dem {\em Top Level} m"oglich, bis die {\sf StarView} Anwendung
beendet ist.
\item Das {\sf Tycoon} System wird ohne einen eigenen {\em Top Level}
gestartet. Eingaben werden aus einer Datei gelesen und Ausgaben in eine andere
Datei geschrieben.
\end{enumerate}

\noindent Beide L"osungen sind jedoch wenig befriedigend. Deshalb ist es
notwendig, den {\em Top Level}  mit Hilfe der {\sf StarView} Klassenbibliothek
anstelle von {\em TextEdit} zu implementieren.

Ein weiteres Problem ergibt sich unter {\sf TL} bei gleichzeitiger Verwendung
der {\sf StarView} Klassenbibliothek und dem {\sf Grand Unified Socket
Interface (GUSI)} \cite{Neer95} , einer Bibliothek, die die Kommunikation auf
{\em Socket} Basis auf dem {\sf Apple Macintosh} implementiert. In diesem Fall
ist der Empfang von Daten nicht mehr m"oglich. Es k"onnen also nicht beide
Bibliotheken gleichzeitig in {\sf TL} verwendet werden. Da die Nutzung von
{\sf GUSI} ohne {\sf StarView} zu keinen Problemen f"uhrt, verwenden beide
Bibliotheken vermutlich gleiche Speicherbereiche, die sie mit eigenen Daten
"uberschreiben, obwohl die andere Bibliothek auf die von ihr erzeugten Daten
noch zugreifen m"ochte.


\section{Bildschirmrepr"asentationen}
\label{Aussehen}
Die graphische Benutzerschnittstelle der verschiedenen zu visualisierenden
Werte und Typen ist in ihrem Aussehen und Verhalten durch die Verwendung der
oben beschriebenen {\sf StarView} Klassenbibliothek und das jeweilige
Fenstersystem gepr"agt. Dabei wird eine f"ur jedes zu visualisierende Objekt
{\sl O\/} des persistenten Speichers typische Bildschirmrepr"asentation
$bRep_{O}$ gew"ahlt. Getrennt nach Typen und Werten werden in den folgenden
Abschnitten Aussehen und Verhalten anhand von Abbildungen, die der Darstellung 
unter {\em Open Windows} entsprechen, erl"autert. Da die Visualisierung von
Funktionswerten umfangreicher ist als die anderer Werte, erfolgt deren
Beschreibung in einem separaten Abschnitt. Alle visualiserten Objekte werden
von einem einheitlichen Rahmen umgeben.


\subsection{Rahmen f"ur visualisierte Objekte}
\label{Rahmen}
Ohne einen Rahmen kann keines der zu visualisierenden Objekte dargestellt
werden. Er stellt eine den Anforderungen des jeweiligen Objektes entsprechende
Grundfunktionalit"at zur Verf"ugung. Die Elemente, aus denen ein Rahmen
bestehen kann, sind in Abbildung \ref{Rahmenbild} dargestellt:

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{rahmen.epsf}
\end{center}
\caption{M"ogliche Komponenten eines Rahmens}
\label{Rahmenbild}
\end{figure}

\noindent Grunds"atzlich handelt es sich bei dem Rahmen um ein Fenster der
Klasse {\sl ModelessDialog\/}, das von keinem anderen visualisierten Objekt
abh"angt. Das Schlie"sen eines Rahmens ist nur "uber den Men"upunkt {\sl
Quit\/} des Men"uknopfes m"oglich.

Jeder Rahmen hat unter der Kopfzeile eine Men"uzeile, in der die Men"ukn"opfe,
beginnend auf der linken Seite, angeordnet sind. Am unteren Ende eines Rahmens
k"onnen zwei weitere Kn"opfe erscheinen. Zwischen der Men"uzeile und den
Kn"opfen ist das zu visualisierende Objekt dargestellt.

\subsubsection{Kopfzeile}
Jeder Rahmen hat eine Kopfzeile, in dem die Art des visualisierten Objektes
angezeigt ist. Entsprechend der Namenskonventionen in {\sf TL} beginnen
Typkonstruktoren mit einem Gro"sbuchstaben, also z.B. {\bf Tuple}, und
Wertkonstruktoren mit einem Kleinbuchstaben, also z.B. {\bf tuple}. Handelt es
sich um einen variablen Wert, so ist zus"atzlich das Schl"usselwort {\bf var}
vorangestellt.

\subsubsection{Men"us}
In der aktuellen Version hat der Rahmen nur einen Men"uknopf {\sl Browser\/},
in dem die in Tabelle \ref{Menu} dargestellten Men"ueintr"age enthalten sein
k"onnen.

\begin{table}[htp]
\begin{center}
\begin{tabular}{|l|l|l|}
\hline
{\bf Eintrag} & {\bf Subeintrag} & {\bf Funktionalit"at}\\
\hline
Copy & Copy & In das Klemmbrett kopieren.\\
& Copy Variant & Variante in das Klemmbrett kopieren.\\
Paste & & Aus dem Klemmbrett kopieren.\\
Select Element & & Anzuzeigendes Feldelement ausw"ahlen.\\
Show & Type & Typ eines Wertes anzeigen.\\
& Globals & Freie Variablen einer Funktion anzeigen.\\
& TL & Programmkode einer Funktion anzeigen.\\
& TML & TML Kode einer Funktion anzeigen.\\
& Byte Code & Bytekode einer Funktion anzeigen.\\
Quit & & Fenster schlie"sen.\\
\hline
\end{tabular}
\end{center}
\caption{Funktionalit"at der Men"ueintr"age}  \label{Menu}
\end{table}

\noindent In Abh"angigkeit von den visualisierten Objekten enth"alt das Men"u
nur die jeweils ben"otigten Eintr"age, z.B. {\sl Copy Variant\/} nur bei
varianten Tupelwerten. Befindet sich kein Objekt im Puffer, so ist der Eintrag
{\sl Paste\/} als inaktiv markiert und nicht ausw"ahlbar.

\subsubsection{Kn"opfe}
\label{buttons}
Nur bei der Visualisierung von ver"anderlichen Werten der Basistypen wie z.B.
Zeichenketten erscheinen die Kn"opfe {\sl Apply\/} und {\sl Reset} im
Rahmen. Wird der {\sl Apply} Knopf gedr"uckt, so wird der Variable der
aktuell auf dem Bildschirm sichtbare Wert zugewiesen. Der {\sl Reset\/} Knopf
dagegen liest den Wert aus der Variable und tr"agt ihn in die 
Bildschirmrepr"asentation ein.


\subsection{Typen}
Die Visualisierung von Typen orientiert sich an den in {\sf TL} realisierten
Typkonzepten. Sie dient dem weitergehenden Verst"andnis von Werten. F"ur jeden
Typ existieren zwei Arten von Visualisierungen:

\begin{enumerate}
\item Die Darstellung der Struktur des Typs.
\item Wenn sie als Typkomponente einer Signatur oder einer Typbindung 
eingeschachtelt in einem anderen Typ oder Wert dargestellt werden, erfolgt 
ihre Repr"asentation durch einen Knopf. Der Knopf ist mit einer 
Kurzbeschreibung des Typs beschriftet, die Auskunft dar"uber gibt, um was f"ur 
einen Typ es sich handelt. Die Kurzbeschreibung ist entweder ein
Typidentifikator oder ein Konstruktor, z.B. {\em Tuple} f"ur einen
Tupeltyp. Durch Dr"ucken dieses Knopfes erscheint die eigentliche
Visualisierung des Typs in der anderen Darstellung.
\end{enumerate}

\noindent Generell kann man zwischen den Basistypen und den benutzerdefinierten
Typen unterscheiden. F"ur Basistypen und den Supertyp aller
nichtparametrisierten Typen {\bf Ok} gibt es keine eigene Repr"asentation. F"ur
sie wird nur ein leerer Rahmen mit dem Identifikator des jeweiligen Typs in der
Kopfzeile und {\sl Quit\/} als einzigem Men"ueintrag erzeugt. Das Men"u aller
anderen Typen enth"alt zus"atzlich den Subeintrag {\sl Copy\/}, um eine
Typbindung in ein visualisiertes {\em Environment} (s. Abschnitt
\ref{Visualisierungsbibliothek}) zu kopieren. Im folgenden soll die
strukturierte Darstellungsform der verschiedenen zu visualisierenden
benutzerdefinierten Typen vorgestellt werden.

\subsubsection{Abstrakte Datentypen}
Bei abstrakten Datentypen (s. Abb. \ref{AdtType}) werden der Name und der
Supertyp getrennt durch {\em $<$:} in einem Knopf dargestellt. Durch Anklicken
des Knopfes wird die Struktur des Supertyps in einem neuen Fenster
angezeigt. In der Kopfzeile steht {\bf ADT}.

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{adtType.epsf}
\end{center}
\caption{Abstrakte Datentypen}
\label{AdtType}
\end{figure}

\subsubsection{Strukturierte Typen und Ausnahmetypen}
Da die Repr"asentation strukturierter Typen der von Ausnahmetypen "ahnlich ist,
werden beide gemeinsam vorgestellt. Strukturierte Typen werden systematisch
durch Aggregation ihrer Komponenten, d.h. Signaturen, erzeugt. Grunds"atzlich 
unterscheidet sich die Visualisierung von varianten Tupeln von der anderer 
strukturierter Typen.

\begin{description}
\item[Tupel--, Rekord- und Ausnahmetypen:] Sie werden durch ihre Signaturen 
dargestellt (s. Abb. \ref{RecordType} links). Die Typkomponenten der
Signaturen erscheinen links-- und deren Identifikatoren
rechts\-b"un\-dig. Getrennt werden sie entweder durch {\bf :} oder {\bf $<$:},
wenn einer Typvariablen ein Supertyp zugeordnet ist. K"onnen nicht alle
Signaturen innerhalb eines Rahmens visualisiert werden, so erscheint rechts
neben den Signaturen ein Rollbalken, mit dem innerhalb der Signaturen navigiert
werden kann. Nur durch den Eintrag in der Kopfzeile ist feststellbar, ob es
sich um einen Tupel--, Rekord-- oder Ausnahmetyp handelt.
\item[Variante Tupeltypen:] Sie verf"ugen zus"atzlich zu den Signaturen "uber 
einen Auswahlknopf, durch den die zu visualisierende Variante ausgew"ahlt 
werden kann (s. Abb. \ref{RecordType} rechts). Er zeigt den Namen der
gerade sichtbaren Variante an. Die Gr"o"se des Rahmens wird jeweils
entsprechend der Anzahl der Signaturen jeder Variante angepa"st. Grunds"atzlich
wird bei der Visualisierung eines varianten Tupeltyps zun"achst die erste
Variante dargestellt. Wird der Subeintrag {\sl CopyVariant\/} des Men"us
gedr"uckt, so wird die aktuell ausgew"ahlte Variante als Tupel in das
Klemmbrett kopiert.
\end{description}


\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{recordType.epsf} \hspace*{0,5cm}
\epsfxsize=0.2\textwidth
\epsfbox{variantType.epsf}
\end{center}
\caption{Strukturierte Typen}
\label{RecordType}
\end{figure}


\subsubsection{Funktionstypen und Typoperatoren}
Da Typoperatoren Funktionen sind, die Typen auf Typen abbilden, werden sie
"ahnlich wie Funktionen dargestellt (s. Abb. \ref{Funktionstyp}). Sie
unterscheiden sich nur durch den Eintrag in der Kopfzeile, durch den
ersichtlich ist, ob es sich bei dem visualisierten Objekt um einen Funktionstyp
oder um einen Typoperator handelt.

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{funType.epsf}
\end{center}
\caption{Funktionstypen}
\label{Funktionstyp}
\end{figure}

\noindent Beide bestehen aus einer Liste von Signaturen, deren Beginn durch das
Wort {\em Signatures} gekennzeichnet ist, und einem durch {\em Range}
gekennzeichneten Bereichstyp. Wie bei strukturierten Typen ist es m"oglich,
da"s die Signaturen mit einem Rollbalken versehen werden.


\subsubsection{Typoperatoranwendungen}
Bei der Visualisierung von Typoperatoranwendungen werden --- gekennzeichnet 
mit {\em Type Operator} --- der Typoperator durch einen Knopf und ---
eingeleitet durch {\em Type Bindings} --- die Liste der Typbindungen ebenfalls
durch Kn"opfe dargestellt (s. Abb. \ref{TypeOperApp}).

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{operApp.epsf}
\end{center}
\caption{Typoperatorapplikationen}
\label{TypeOperApp}
\end{figure}

Eine Ausnahme bilden Felder, da diese zu den vordefinierten Typen in {\sf TL}
geh"oren. Bei ihnen wird nur der Elementtyp als Knopf visualisiert.


\subsubsection{Rekursive Typen}
Bei der Visualisierung rekursiver Typen werden jeweils alle parallel 
definierten Typbindungen angezeigt (s. Abb. \ref{RecType}). Die Typbindung,
die den visualisierten Typ repr"asentiert, ist durch einen Symbolknopf
gekennzeichnet. Jede Typbindung besteht aus einem Typidentifikator, einem
Supertyp und der Typdefinition.

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{recType.epsf}
\end{center}
\caption{Rekursive Typen}
\label{RecType}
\end{figure}


\subsection{Werte}
Analog zur Visualisierung von Typen gibt es auch bei Werten zwei 
Darstellungsformen. F"ur jeden Wert existieren der Subeintrag {\sl Copy\/} 
sowie die Eintr"age {\sl Type\/} und {\sl Quit} im Men"u. Handelt es sich um 
einen variablen Wert, so erh"alt das Men"u zus"atzlich noch den Eintrag 
{\sl Paste\/}. Solche Werte k"onnen durch Tastatureingaben, durch das 
Kopieren eines Wertes aus dem Klemmbrett oder durch {\em Drag$\&$Drop} 
ver"andert werden.

\subsubsection{Werte von Basistypen}
\label{Basiswerte}
Bei Wertbindungen ist zwischen konstanten und variablen Wertbindungen zu
unterscheiden. F"ur konstante Wertbindungen von Basistypen gibt es nur eine
Repr"asentation. Sie  werden mit Ausnahme von booleschen Werten, bei denen 
kein Unterschied in der Repr"asentation zwischen konstanten und variablen 
Wertbindungen existiert, textuell dargestellt. Als Komponenten anderer 
Wertbindungen werden sie direkt innerhalb der Bildschirmrepr"asentation dieses 
Wertes visualisiert. Variable Wertbindungen werden dagegen als Komponenten 
anderer Werte nur durch einen Knopf repr"asentiert, auf dem der Typ des Wertes 
steht. Durch Dr"ucken des Knopfes erh"alt man die eigentliche Repr"asentation 
der ver"anderlichen Wertbindung, die durch die von {\sf StarView} zur 
Verf"ugung gestellten Klassen zur formatierten Anzeige von Werten vorgegeben 
ist. Diese Unterscheidung ist darin begr"undet, da"s Objekte zwar auf dem 
Bildschirm nur einmal visualisiert werden sollen, konstante Wertbindungen 
jedoch nicht ver"anderlich sind und somit der "Ubersicht halber als 
Komponenten anderer Wertbindungen direkt visualisiert werden k"onnen. 
Im folgenden werden die verschiedenen Bildschirmrepr"asentationen variabler 
Wertbindungen n"aher erl"autert. 

\begin{description}
\item[Ganzzahlen:] Werte des Typs {\sl Int\/} werden durch ein numerisches 
Eingabefeld visualisiert (s. Abb. \ref{Int}). Variable Werte k"onnen durch
Tastatureingaben ge"andert oder durch zwei Kn"opfe, die sich rechts neben dem
Eingabefeld befinden, in-- bzw. dekrementiert werden.

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{varInt.epsf}
\end{center}
\caption{Integerwerte}
\label{Int}
\end{figure}

\item[Flie"skommazahlen:] Werte des Datentyps {\sl Real\/} werden wie 
ganze Zahlen dargestellt, nur da"s es bei variablen Flie"skommazahlen keine 
Kn"opfe zum In-- bzw. Dekrementieren gibt (s. Abb. \ref{Real}). Die
Genauigkeit ist, bedingt durch {\sf StarView}, auf zwei Stellen hinter dem
Komma begrenzt. 

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{real.epsf}
\end{center}
\caption{Flie"skommazahlen}
\label{Real}
\end{figure}

\item[Zeichenketten:] Werte des Datentyps {\sl String\/} werden durch ein 
alphanumerisches Eingabefeld repr"asentiert (s. Abb. \ref{String}). Reicht
das Eingabefeld nicht zur Darstellung der gesamten Zeichenkette aus, so kann
der Inhalt "uber die Tastatur nach rechts bzw. links gerollt werden.

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.3\textwidth
\epsfbox{string.epsf}
\end{center}
\caption{Zeichenketten}
\label{String}
\end{figure}

\item[Zeichen:] Werte des Datentyps {\sl Char\/} werden als Zeichenketten der 
L"ange eins visualisiert.
\item[Boolesche Werte:] Werte des Datentyps {\sl Bool\/} werden durch einen
Selektionsknopf  dargestellt, dessen Wert durch Anklicken mit der Maus
ver"andert werden kann. Der rechte Knopf in Abbildung \ref{BoolKnopf}
repr"asentiert den Wert {\sl true\/} und der linke den Wert {\sl false\/}.
\end{description}

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.05\textwidth
\epsfbox{true.epsf} \hspace*{1cm}
\epsfxsize=0.05\textwidth
\epsfbox{false.epsf}
\end{center}
\caption{Boolesche Werte}
\label{BoolKnopf}
\end{figure}

\subsubsection{Werte abstrakter Datentypen}
Da bei Werten abstrakter Datentypen nur deren Supertyp bekannt ist, ist deren 
Visualisierung nicht m"oglich. Sie werden stattdessen durch die Zeichenkette 
{\sl $<$hidden$>$\/} repr"asentiert (s. Abb. \ref{AdtVal}). Variable
Wertbindungen k"onnen per Tastatur nicht ver"andert werden, da ihre
Manipulationsoperationen nicht bekannt sind. Der Datenaustausch "uber das
Klemmbrett und per {\em Drag\&Drop} ist dagegen erlaubt.

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{adtVal.epsf}
\end{center}
\caption{Werte abstrakter Datentypen}
\label{AdtVal}
\end{figure}

\subsubsection{Strukturierte Werte}
Werte von Tupeln, varianten Tupeln oder Rekordtypen werden durch die Bindungen
ihrer Komponenten beschrieben (s. Abb. \ref{RecordValue}). Der Name jeder
Bindung, dem das Schl"usselwort {\bf var} bei einer variablen Wertbindung
vorangestellt ist, erscheint rechtsb"undig als fixierter Text, ihre Typ--
bzw. Wertkomponente als Knopf oder in der entsprechenden Repr"asentationsform,
falls es sich um eine konstante Wertbindung eines Basistyps handelt. Bei
varianten Tupeln wird zus"atzlich der Name der Variante als fixierter Text
angezeigt. K"onnen nicht alle Komponenten in dem Rahmen visualisiert werden, so
kann mit einem Rollbalken rechts neben den Komponenten navigiert werden.

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{tupValue.epsf} \hspace*{0,5cm}
\epsfxsize=0.2\textwidth
\epsfbox{variantValue.epsf}
\end{center}
\caption{Strukturierte Werte}
\label{RecordValue}
\end{figure}

\subsubsection{Ausnahmewerte}
Bei Ausnahmewerten werden analog zu Ausnahmetypen alle Signaturen
visualisiert. Der Name des Ausnamewertes erscheint in der Kopfzeile.

\subsubsection{Felder}
Da die Feldelemente variabel sind, wird f"ur jedes Feldelement ein Knopf
erzeugt, der als Eintrag den Index des Elementes und den Elementtyp erh"alt
(s. Abb. \ref{Arrays}). Lassen sich nicht alle Elemente in einem Rahmen
visualisieren, so kann mit Hilfe eines Rollbalkens navigiert werden. Die
Visualisierung eines Elementes erfolgt durch Dr"ucken des entsprechenden
Knopfes oder durch Auswahl "uber den Men"ueintrag {\sl Select Element\/}.

\begin{figure}[htp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{arrayValue.epsf}
\end{center}
\caption{Felder}
\label{Arrays}
\end{figure}


\subsection{Funktionswerte}
\label{Funktionswerte}
Funktionen sind in {\sf TL} Werte erster Klasse, die im Rumpf sowohl ihre
formalen Parameter und lokal definierten Bindingen als auch lexikalisch
au"serhalb von ihnen definierte Bindungen referenzieren d"urfen. Da global in
Funktionen referenzierte Bindungen aber den Wert "uberleben k"onnen, in dem sie
definiert werden, werden sie mit der Funktion zusammen in einem
Funktionsabschlu"s abgespeichert. Damit ist es f"ur das Verst"andnis einer
Funktion in {\sf TL} notwendig, ihre Signatur, ihren Programmkode und ihre
globalen Bindungen zu visualisieren. Da im Abschlu"s einer Funktion jedoch auch
eine persistente Repr"asentation des {\sf TML} Kodes und der {\sf TVM} Kode
gespeichert sind, sollen diese zu Testzwecken auch im Rahmen dieser Arbeit
visualisiert werden.

Zun"achst wird nur die Signatur einer Funktion angezeigt. Da sie dem Typ einer
Funktion gleicht, wird sie auch entsprechend visualisiert. In getrennten
Fenstern k"onnen Bildschirmrepr"asentationen der anderen Komponenten durch
Auswahl des entsprechenden Submen"ueintrags erzeugt werden. Die Visualisierung
der globalen Variablen erfolgt analog zu Bindungen in strukturierten Werten (s.
Abb. \ref{Funktion} links). Die verschiedenen Koderepr"asentationen werden
durch ein mehrzeiliges manipulierbares Editierfenster dargestellt. Mit Hilfe
von Rollbalken kann sowohl in vertikaler als auch in horizontaler Richtung
navigiert werden. Um das Verst"andnis des Programmkodes zu erh"ohen, wird das
gesamte Modul angezeigt, in dem die Funktion definiert worden ist (s. Abb.
\ref{Funktion} rechts).

Um die Funktionsvisualisierung zu vervollst"andigen, soll der Anwender auch 
in der Lage sein, eine visualisierte Funktion interaktiv auszuf"uhren. Deshalb 
wird unterhalb der Funktionssignatur ein weiterer Knopf mit der Aufschrift 
{\sl execute\/} generiert. Wird dieser Knopf gedr"uckt, so wird die 
Funktion ausgef"uhrt. Zur Zeit ist diese Funktionalit"at aber nur f"ur 
parameterlose Funktionen realisiert.

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{tlCode.epsf} \hspace*{0,5cm}
\epsfxsize=0.2\textwidth
\epsfbox{globals.epsf}
\end{center}
\caption{Programmkode und globale Variablen einer Funktion} \label{Funktion}
\end{figure}

