\chapter{Realisierung der Daten-- und Funktionsvisualisierung}
\label{Realisierung}
In den vorherigen Kapiteln sind die Voraussetzungen zur Realisierung des
generischen Dienst\-es zur Daten-- und Funktionsvisualisierung beschrieben
worden, also die Definition der Anforderungen, die Gestaltung der grafischen
Benutzerschnittstelle, die Integration dynamischer Typisierung in {\sf TL} und
systemunterst"utzende Funktionalit"at zur Visualisierung der globalen Bindungen
einer Funktion. In diesem Kapitel schlie"slich wird die in der Bibliothek {\em
browseenv} realisierte Implementierung beschrieben. Dazu werden im ersten
Abschnitt der Aufbau der Bibliothek und der Ablauf der Visualisierung
"uberblicksartig vorgestellt. In den folgenden Abschnitten werden die
wesentlichen Konzepte der Komponenten der Bibliothek erl"autert, die bei der
Realisierung der generischen Daten-- und Funktionsvisualisierung eine Rolle
spielen.


\section{Die Bibliothek zur Daten-- und Funktionsvisualisierung}
\label{Visualisierungsbibliothek}
Das Hauptstrukturierungsmittel f"ur Werte und Typrepr"asentationen im
Objektspeicher sind sogenannte {\em Environments} \cite{Geis95}. Sie sind in
\cite{MBC*94,Dear89} definiert als die unendliche Vereinigung aller benannten
Kreuzprodukte. Das bedeutet konkret, da"s Environments eine nicht
notwendigerweise geordnete Sequenz von Werten des weiter unten definierten
Datentyps {\sl Binding\/} enthalten. Solche Bindungen, die benutzerdefinierte
Namen an semantische Objekte binden, spielen damit eine zentrale Rolle bei der
Visualisierung von Objekten und dem Datenaustausch zwischen ihren 
Bildschirmrepr"asentationen in {\sf TL}. Anders als bei \cite{MABD90} umfassen
sie nicht nur konstante und variable Wertbindungen sondern auch
Typbindungen. Das f"uhrt neben einer Vereinheitlichung der
Benennungsmechanismen zu einer Vermeidung redundanter Deklarationen f"ur
identische semantische Objekte in verschiedenen Werkzeugen \cite{Matt93}.
Dadurch ist es m"oglich, einen universellen Rahmen zur Daten-- 
und Funktionsvisualisierung bereitzustellen, in dem Objekte nur einmal auf dem
Bildschirm dargestellt werden, auch wenn sie auf unterschiedlichen
Zugriffspfaden erreicht werden, und der den uniformen Datenaustausch zwischen
den Bildschirmobjekten erlaubt. 

Bindungen sind durch den varianten Tupeltyp 

\begin{xple}
\kw{Let} \id{Binding} = \kw{Tuple}
  \id{name :String}
  \kw{case} \id{typeCase} \kw{with}
    \id{type :typeRep\_T}
  \kw{case} \id{valueCase} \kw{with}
    \id{value :dynamic\_T}
  \kw{case} \id{locationCase} \kw{with}
    \id{value() :dyanamic\_T}
    \id{setValue(:dynamic\_T)} :\kw{Ok}
    \id{getLocation() :Location}
\kw{end}
\end{xple}

\noindent des Moduls {\em Environment} repr"asentiert. Variable Wertbindungen
sind im Objektspeicher durch Zellen, bestehend aus einer Basisadresse und einer
dazu relativen Adresse, dargestellt und eindeutig identifizierbar 
\cite{GaMa94}. Da eigentlich nur der Compiler diese Zelle kennt, werden der 
lesende und ver"andernde Zugriff auf die Wertkomponente durch die beiden 
Funktionen {\sl value\/} und {\sl setValue\/} realisiert. Bei der Daten-- und
Funktionsvisualisierung sollen Objekte nur einmal auf dem Bildschirm 
dargestellt werden, um das Verst"andnis f"ur die Zusammenh"ange zwischen den
Objekten zu verdeutlichen und um den Datenaustausch zwischen
Bildschirmrepr"asentationen realisieren zu k"onnen. Da die Wertkomponente
variabler Bindungen durch ihre Zelle eindeutig identifizierbar ist, wird noch
die Funktion {\sl getLocation\/} ben"otigt, die die Zelle einer variablen
Wertbindung liefert.

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{ablauf.epsf}
\end{center}
\caption{Ablauf der Daten-- und Funktionsvisualisierung}
\label{Ablauf}
\end{figure}

Die Visualisierung einer Bindung besteht aus vier Schritten
(s. Abb. \ref{Ablauf}):

\begin{enumerate}
\item Es wird "uberpr"uft, ob f"ur das durch die Bindung repr"asentierte Objekt
{\sl O} des persistenten Speichers schon eine Bildschirmrepr"asentation
$bRep_O$ existiert. Ist dies der Fall, so wird sie nur optisch hervorgehoben.
\item Andernfalls wird die Struktur von {\sl O\/} analysiert. 
\item Entsprechend der Strukturanalyse wird ein uniformes Protokoll generiert,
das $bRep_O$ kapselt und "uber Protokollfunktionen zug"anglich macht.
\item Schlie"slich wird $bRep_O$ erzeugt und angezeigt.
\end{enumerate}

\noindent Diese Schritte sollen vor dem Anwendungsprogrammierer verborgen
werden und der Zugriff auf den Dienst zur generischen Daten-- und
Funktionsvisualisierung "uber eine nach au"sen sichtbare Schnittstelle
erfolgen. Aus diesen "Uberlegungen heraus ist die Bibliothek in die folgenden
in Abb. \ref{Struktur} dargestellten Bl"ocke unterteilt:

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{struktur.epsf}
\end{center}
\caption{Struktur der Bibliothek zur Daten-- und Funktionsvisualisierung}
\label{Struktur}
\end{figure}

\begin{itemize}
\item Der unterste Block stellt einige Module zur Unterst"utzung der
Visualisierung zur Ver\-f"u\-gung.
\item Im zweiten Block werden das abstrakte Datenstrukturmodell, das einen
universellen Rahmen zur Repr"asentation von Objekten bietet, und das 
abstrakte Protokoll definiert, "uber das die Objekte angesprochen werden
k"onnen.
\item Der dritte Block dient der Generierung der Bildschirmrepr"asentationen
f"ur die verschiedenen Objekte.
\item Der vierte Block implementiert die Strukturanalyse, von der aus die
Generierung der Bildschirmrepr"asentationen aufgerufen wird.
\item Das Modul {\sl browser\/} schlie"slich stellt die f"ur den
Anwendungsprogrammierer nach au"sen sichtbare Schnittstelle des Dienstes dar.
\end{itemize}

\noindent In den folgenden Abschnitten werden die einzelnen Bl"ocke genauer
vorgestellt. Um die darin vorgestellten Konzepte besser verstehen zu k"onnen,
orientiert sich die Reihenfolge der Abschnitte jedoch nicht an der in Abbildung
\ref{Struktur} dargestellten Struktur der Bibliothek.

\section{Strukturanalyse}
Im Gegensatz zu den benutzerdefinierbaren Editoren aus \cite{Mues94}, ist bei 
der  generischen Daten-- und Funktionsvisualisierung nicht bekannt, welche 
Struktur das zu visualierende Objekt hat. Die Struktur mu"s deshalb getrennt
f"ur die Wert-- und Typkomponenten einer Bindung analysiert werden. Ziel ist es
dabei nicht, die ganze Struktur des Objektes zu erfassen, da diese sehr komplex
und deren Analyse entsprechend laufzeitintensiv sein kann. Au"serdem m"ochte
der Anwender eventuell gar nicht alle Komponenten detailliert visualisieren.
Deshalb werden die Wert-- bzw. Typkomponente einer Bindung lediglich mit Hilfe
von {\sl inspect\/} aus den Modulen {\sl dynamic\/} bzw. {\sl typeRep\/} um
einen Schritt expandiert und mit den daraus gewonnenen wert--
bzw. typspezifischen Informationen die entsprechende Funktion zum Generieren
des Protokolls und der Bildschirmrepr"asentation aufgerufen. Nur
Typidentifikatoren werden bis zu ihrer Definition expandiert, da es f"ur das
Verst"andnis von Typen nicht notwendig ist, Bindungen von Typidentifikatoren an
andere Typidentifikatoren zu visualisieren. Wertbindungen, bei deren Typ es
sich um eine nichtabstrakte Typoperatoranwendung handelt, werden ebenfalls um
einen weiteren Schritt expandiert, um dessen Wertkomponente zu
visualisieren. Die Struktur des Typoperators und der Typbindungen k"onnen mit
Hilfe des Typs der Wertbindung visualisiert werden.

Da die Struktur von Komponenten eines Wertes bzw. Typs erst analysiert wird, 
wenn der Anwender diese visualisieren m"ochte, entsteht eine komplexe 
rekursive Wechselbeziehung zwischen dem Modul, das die Strukturanalyse 
durchf"uhrt, und den Modulen, die die wert-- bzw. typspezifische 
Visualisierung realisieren. Da in {\sf TL} wechselseitig rekursive 
Funktionsaufrufe zwischen Modulen verboten sind, mu"s die Funktion, die die 
Strukturanalyse durchf"uhrt, als Parameter mit "ubergeben werden:

\begin{xple}
\id{binding(parent :window.T  bndg :Environment.Binding  actPos :BrowserUtil.Location}
  \id{keepPermanent, isSub :Bool) :BrowserRep.T}
\end{xple}

\noindent Sie erwartet als Parameter das Elternfenster, die zu visualisierende
Bindung, die Position, an der die Bildschirmrepr"asentation erscheinen soll,
sowie zwei weitere Parameter, die der Strukturanalyse mitteilen, ob die zu
visualisierende Bindung permanent mit ihrer Bildschirmrepr"asentation
gespeichert werden soll (s. Abschnitt \ref{Browserschnittstelle}) und ob die
Bindung innerhalb der Bildschirmrepr"asentation eines strukturierten Wertes
visualisiert werden soll.

Der Datenaustausch zwischen Bildschirmrepr"asentationen wird durch den 
Austausch von Bindungen realisiert. Dazu mu"s es m"oglich sein, aus einer 
visualisierten Bindung den aktuellen Inhalt der Wert-- bzw. Typkomponente zu 
erhalten sowie diesen bei variablen Wertbindungen zus"atzlich ver"andern zu
k"onnen. Deshalb werden in der Strukturanalyse folgende Funktionen generiert
und als weitere Parameter an die Visualisierungskomponenten "ubergeben
(s. Abschnitt \ref{Visualisierungsschnittstelle}):

\begin{xple}
\id{getValue() :Environment.Bindung}
\id{setValue(:Environment.Binding)} :\kw{Ok}
\end{xple}

\noindent Eine andere Operation, die bei Wertbindungen im Gegensatz zu
Typbindungen notwendig ist, ist die Visualisierung des Typs der
Wertkomponente. Da jedoch Wertbindungen, deren Typ eine nichtabstrakte
Typoperatoranwendung ist, um zwei Schritte expandiert werden, l"a"st sich
anhand des visualisierten Wertes nicht mehr feststellen, da"s es sich bei dem
Typ um eine Typoperatoranwendung handelt. Deshalb wird der Funktion, die die
Bildschirmrepr"asentation generiert, folgende Funktion zur Visualisierung des
gekapselten Typs "ubergeben:
 
\begin{xple}
\id{browseType(parent :window.T  actPos :Location) :T}
\end{xple}


\section{Abstraktes Datenstrukturmodell}
Bei der generischen Daten-- und Funktionsvisualisierung entstehen viele 
unterschiedliche Bildschirmobjekte. Um diese heterogenen Objekte in eine 
gemeinsame Umgebung zu integrieren und in objektorientierter Form 
ansprechen zu k"onnen, ist es notwendig, ein gemeinsames Protokoll f"ur alle
Bildschirmobjekte zu definieren \cite{KGZ93}. Das f"ur diesen Dienst 
definierte Protokoll, das im ersten Teil dieses Abschnittes beschrieben wird,
setzt auf dem f"ur Editoren auf \cite{Mues94}, ist jedoch an die zus"atzlichen 
Anforderungen der generischen Daten-- und Funktionsvisualisierung und an die
Verwendung der {\sf StarView} Klassenbibliothek angepa"st. F"ur den
einheitlichen Zugriff auf die Komponenten werden Funktionen bereitgestellt, die
im zweiten Teil erl"autert werden.


\subsection{Protokoll}
\label{Protokoll}
In dem Protokoll werden die allen Objekten gemeinsamen Eigenschaften definiert
und zur Verf"ugung gestellt. Funktionale Komponenten erm"oglichen den Zugriff
auf die gekapselten objektspezifischen Eigenschaften. In diesem Abschnitt
werden die verschiedenen Komponenten des Protokolls vorgestellt.

Interne Daten, die den zugeh"origen Rahmen und den Status einer 
Bildschirmrepr"asentation betreffen, werden durch den Typoperator 
{\sl Hidden\/} beschrieben:

\begin{xple}
\kw{Let} \id{Hidden(BrowserT} $<$:\kw{Ok}) $<$:\kw{Ok} = \kw{Tuple}
  \kw{var} \id{windowId :browserWindow.T} 
  \kw{var} \id{menu :list.T(MenuT)}
  \kw{var} \id{buttons :list.T(pushButton.T)}
  \kw{var} \id{parent :optional.T(BrowserT)}
  \kw{var} \id{keepPermanent :Bool}
  \id{state :set.T(State)}
  \id{size :Location}
\kw{end}
\end{xple}

\noindent Diese Informationen sind variabel, da sie sich w"ahrend der
Lebensdauer eines Ojektes "andern k"onnen. Es ist m"oglich, visualisierte
Objekte innerhalb eines Rahmens beliebig zu kombinieren und so eine
hierarchische Struktur aufzubauen. Nur solche Objekte, die nicht innerhalb
eines anderen Objektes dargestellt werden, besitzen ein eigenes Fenster ({\sl
windowId\/}) und eine Liste von Men"ukn"opfen mit zugeh"origen Men"ueintr"agen
({\sl menu\/}). Diese Objekte sind im Gegensatz zu den in \cite{Mues94}
vorgestellten Editoren v"ollig unabh"angig von anderen visualisierten
Objekten. Ansonsten verweist {\sl parent\/} auf das Objekt, in dem das Objekt
dargestellt wird. Repr"asentiert das visualisierte Objekt eine ver"anderliche
Wertbindung eines Basistyps, so enth"alt {\sl buttons\/} eine Liste von
Kn"opfen, mit denen die Wertkomponente manipuliert werden kann (s. Abschnitt 
\ref{Rahmen}). Bei der Generierung des Protokolls kann der Anwender festlegen, 
ob das Protokoll des zu visualisierenden Objektes permanent in der
entsprechenden Tabelle (s. Abschnitt \ref{Objektverwaltung}) gespeichert 
werden soll. Entsprechend wird die Komponente {\sl keepPermanent\/} gesetzt. 
Die permanente Speicherung der Protokolle eignet sich besonders, wenn von 
Bindungen h"aufiger Bildschirmrepr"asentationen erzeugt werden m"ussen. Wird 
der Dienst zur Daten-- und Funktionsvisulisierung z.B. zur Darstellung der
Berechnungsergebnisse eingesetzt, so kann ein Wert an verschiedene Namen
gebunden werden. Jedesmal, wenn dieser Wert erneut visualisiert werden soll und
keine Bildschirmrepr"asentation mehr existiert, so mu"s nur die
Bildschirmrepr"asentation aus dem bestehenden Protokoll generiert werden, nicht
jedoch das Protokoll selbst. In {\sl size\/} wird die Gr"o"se des
visualisierten Objektes, bestehend aus der Breite und der H"ohe, die beide
variabel sind, festgehalten.

Ein visualisiertes  Objekt kann sich gleichzeitig in mehreren g"ultigen
Zu\-st"an\-den befinden, die in {\sl state\/} gespeichert sind. Abh"angig
davon, welche Zust"ande die Menge aktuell enth"alt, ist genau definiert, welche
Operationen auf einem Objekt erlaubt sind. Die zul"assigen Zust"ande werden in
Tabelle \ref{Zustand} erkl"art.

\begin{table}[htp]
\begin{center}
\begin{tabular}{|l|l|}
\hline
{\bf Zustand} & {\bf Bedeutung}\\ \hline
new & Ist w"ahrend der Initialisierung gesetzt.\\
exists & Das Objekt ist mit {\sl create\/} erzeugt worden.\\
visible & Das Objekt ist auf dem Bildschirm sichtbar.\\
windowed & Das Objekt befindet sich in einem Rahmen.\\
showThis & Ein Objekt, das einen Rahmen besitzt, soll auf dem Bildschirm\\
& angezeigt werden.\\ \hline
\end{tabular}
\end{center}
\caption{Zul"assige Objektzust"ande} \label{Zustand}
\end{table}

\noindent Zwar wird der Typoperator {\sl Hidden\/} innerhalb des Dienstes zur
Daten-- und Funktionsvisualisierung  sichtbar exportiert, Manipulationen
sollten aber nur in den daf"ur definierten Hilfsmodulen vorgenommen werden und
nicht in den Funktionen, die die Bildschirmrepr"asentation generieren, um eine
einheitliche Funktionalit"at dieser Komponenten zu gew"ahrleisten.

Das Protokoll wird durch den folgenden rekursiven Datentyp exportiert: 

\begin{xple}
\kw{Let Rec} \id{T} $<$:\kw{Ok} = \kw{Tuple}
  \id{hidden :Hidden(T)}
  \id{label :String}
  \kw{var} \id{menuItems :list.T(MenuItem)}
  \id{createButtons :Bool}
  \id{allowDragAndDrop :Bool}
  \id{create(parent :window.T  actPos :Location) :} \kw{Ok}
  \id{apply() :Bool} 
  \id{refresh() :} \kw{Ok}
  \id{show() :} \kw{Ok}
  \id{unshow() :} \kw{Ok}
  \id{getValue() :Environment.Binding}
  \id{setValue(binding :Environment.Binding) :} \kw{Ok}
\kw{end}
\end{xple}

\noindent In {\sl label\/} wird, sofern das Objekt "uber einen eigenen Rahmen
verf"ugt, die Kopfzeile gespeichert. Die Komponente {\sl menuItems\/} enth"alt
die f"ur ein Objekt g"ultigen Men"ueintr"age mitsamt der zugeh"origen Aktionen.
Bei variablen Wertbindungen von Basistypen hat {\sl createButtons\/} den Wert
{\sl true\/}, so da"s f"ur dieses Objekt Manipulationskn"opfe erzeugt werden.
Nur wenn {\sl allowDragAndDrop\/} den Wert {\sl true} hat, darf die
visualisierte Typbindung per {\em Drag$\&$Drop} ver"andert bzw. in ein anderes
Objekt kopiert werden.

Die funktionalen Komponenten realisieren den Zugriff auf die gekapselten, 
objektspezifischen Eigenschaften. Sie enthalten nur die f"ur ein spezielles 
Objekt g"ultigen Anweisungen. Diejenigen Anweisungen, die bei allen Objekten 
gleich sind, werden durch die im n"achsten Abschnitt beschriebenen Funktionen 
realisiert. Diese "uberpr"ufen auch Integrit"atsbedingungen (s. Abschnitt
\ref{Zugriffsfunktionen}), so da"s die funktionalen Komponenten niemals direkt
aufgerufen werden d"urfen.

Die Funktionen {\sl create, apply, refresh, show\/} und {\sl unshow\/} dienen
der Manipulation der Bildschirmrepr"asentation, die erst durch {\sl create\/}
erzeugt werden mu"s, bevor die anderen Funktionen ausgef"uhrt werden d"urfen.
Da Werte von Basistypen per Tastatur-- oder Mauseingaben manipulierbar sind,
k"onnen in den Bildschirmrepr"asentationen und der Wertkomponente
unterschiedliche Werte existieren. Durch {\sl apply\/} wird die Wertkomponente
mit den Inhalten der Bildschirmrepr"asentationen aktualisiert, w"ahrend {\sl
reset\/} die umgekehrte Richtung realisiert. {\sl Reset\/} mu"s bei
Wertbindungen immer aufgerufen werden, wenn ein Objekt mit {\sl show\/} auf dem
Bildschirm dargestellt wird, um die Bildschirmobjekte mit den richtigen Werten
zu f"ullen. Die Funktion {\sl unshow\/} schlie"slich entfernt ein Objekt vom
Bildschirm.

Die Funktionen {\sl getValue\/} und {\sl setValue\/} erlauben den lesenden und
ver"andernden Zugriff auf ein Objekt und werden zum Datenaustausch zwischen
Objekten ben"otigt. Der Aufruf von {\sl setValue\/} ist allerdings nur bei
variablen Wertbindungen erlaubt und f"uhrt ansonsten zu einer Fehlermeldung.


\subsection{Zugriffsfunktionen}
\label{Zugriffsfunktionen}

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{integrities.epsf}
\end{center}
\caption{M"ogliche Zustands"uberg"ange der Browser}
\label{integrities}
\end{figure}

\noindent F"ur den Zugriff auf die funktionalen Komponenten des Protokolls
gelten Integrit"atsbedingungen, die durch die Zugriffsfunktionen realisiert
werden. F"ur die Komponenten, die die Manipulation von Bildschirmobjekten
betreffen,  erfolgt deren "Uberpr"ufung anhand der oben definierten
Zust"ande. Dabei sind die in Abb. \ref{integrities}\footnote{entnommen aus
\cite{Mues94}} dargestellten Zustandskombinationen und --"uberg"ange m"oglich,
wobei die in Klammern stehenden Zust"ande nur bei solchen Objekten auftreten
k"onnen, die einen eigenen Rahmen besitzen. Es ist zu beachten, da"s das
Protokoll nach dem Schlie"sen der Bildschirmrepr"asentation mittels {\sl
unshow\/} wieder in den Zustand {\sl new\/} "ubergeht und nicht in {\sl
exists\/} (zur Begr"undung s. Abschnitt \ref{Objektverwaltung}).

Die Funktionen, die die Zustands"uberg"ange realisieren, "uberpr"ufen 
zun"achst, ob das Objekt eine g"ultige Zustandskombination aufweist. Ist dies 
der Fall, so werden die entsprechende funktionale Komponente des Protokolls 
ausgef"uhrt und der Nachfolgezustand gesetzt. Die Funktionen {\sl show\/} und 
{\sl unshow\/} haben zus"atzlich die Aufgabe, das 
{\em Drag$\&$Drop} Verfahren mit Hilfe des Moduls {\sl browserExchange\/} zu 
initialisieren, falls das Attribut {\sl allowDragAndDrop\/} des Protokolls des 
zu visualisierenden Objektes den Wert {\sl true\/} besitzt. F"ur alle Objekte 
ist dabei ein {\em Drag} erlaubt, jedoch nur f"ur variable Wertbindungen 
ein {\em Drop}. Au"serdem mu"s das Protokoll in diesen Funktionen in die 
Tabelle, in der die Objekte mit ihren Bildschirmrepr"asentationen gespeichert
werden (s. Abschnitt \ref{Objektverwaltung}) eingetragen bzw. aus ihr entfernt
werden, sofern das Attribut {\sl keepPermanent\/} den Wert {\sl false}
hat. Andernfalls ist der Eintrag schon nach der Generierung des Protokolls
erfolgt.

Der Datenaustausch ist nur zwischen auf dem Bildschirm sichtbaren Objekten
erlaubt. Die Typsicherheit wird dabei durch {\sl getValue\/} und {\sl
setValue\/} gew"ahrleistet. Die Funktion {\sl setValue\/} unterbindet den 
Austausch von Typbindungen und "uberpr"uft, ob der Typ des neuen Wertes in
Subtypbeziehung zum Typ des alten Wertes steht. Nur wenn beide Bedingungen
erf"ullt sind, wird der alte Wert durch den neuen ersetzt. Andernfalls
erscheint eine Fehlermeldung auf dem Bildschirm.


\section{Unterst"utzende Schnittstellen}
Die in diesem Abschnitt vorgestellten Schnittstellen realisieren allen Objekten
gemeinsame unterst"utzende Funktionalit"aten. Zur Realisierung zweier
Hauptziele der Daten-- und Funktionsvisualisierung --- alle Objekte nur einmal
auf dem Bildschirm darzustellen und den Datenaustausch zwischen
Bildschirmrepr"asentationen zu erm"oglichen --- existieren die beiden Module
{\sl browserDict\/} und {\sl browserExchange\/}. Wie das Modul {\sl
browserDisplay\/} auch, werden sie jeweils in einem eigenen Unterabschnitt
betrachtet.


\subsection{Allgemeine unterst"utzende Schnittstellen}
Die meisten Hilfsschnittstellen bed"urfen keiner umfassenden Erl"auterung, so 
da"s sie nur "uberblicksartig vorgestellt werden.

\begin{description}
\item[browserError:] Alle innerhalb dieses Dienst generierten Ausnahmepakete 
werden durch diese Schnittstelle auf dem Bildschirm visualisiert.
\item[browserUtil:] In diesem Modul sind alle diejenigen 
Unterst"utzungsfunktionen zusammengefa"st, die keiner anderen Schnittstelle 
zugeordnet werden k"onnen. Das betrifft die Erzeugung einiger 
{\sf StarView} Objekte und die Bestimmung der Gr"o"se solcher Objekte.
\item[browserWindow:] Funktionen zur Erzeugung und Manipulation der 
Rahmenfenster, in denen die visualisierten Objekte eingebettet sind, werden 
durch diese Schnittstelle exportiert.
\item[browserButton:] Falls im Protokoll die Komponente {\sl createButtons\/} 
den Wert {\sl true\/} hat, so werden die Manipulationskn"opfe durch dieses
Modul erzeugt und verwaltet. 
\item[browserMenu:] Entsprechend der Eintr"age in {\sl menuItems\/} wird in 
dieser Schnittstelle das zugeh"orige Men"u erzeugt.
\end{description}


\subsection{Verwaltung der visualisierten Objekte}
\label{Objektverwaltung}
Um "uberpr"ufen zu k"onnen, ob f"ur ein Objekt schon eine
Bildschirmrepr"asentation existiert, wird es zusammen mit dem generierten
Protokoll in eine Tabelle eingetragen. Durch einen Parameter kann der Anwender 
bei der Generierung des Protokolls angeben, ob die Komponente 
{\sl keepPermanent\/} des Protokolls den Wert {\sl true\/} haben soll und 
damit dieser Eintrag permanent in dieser Tabelle gespeichert, oder nach dem 
Schlie"sen der Bildschirmrepr"asentation wieder entfernt wird.

Die Verwaltung dieser Tabelle erfolgt durch das Hilfsmodul {\sl browserDict\/}.
Lesende, ein\-f"u\-gen\-de und l"oschende Zugriffe erfolgen einheitlich f"ur  
Bindungen "uber exportierte Funktionen, wobei die Tabelle durch das Modul 
gekapselt ist. Tats"achlich existieren f"ur Typen, konstante und variable 
Wertbindungen jeweils eigene Tabellen. Die Verwendung der richtigen Tabelle 
erfolgt intern in Abh"angigkeit von der Art der Bindung. Bei Typ-- und 
konstanten Wertbindungen ist die Objektidentit"at des Objektbezeichners der 
Schl"ussel der Tabellenelemente, bei variablen Wertbindungen die durch 
{\sl getLocation\/} erhaltene Zelle.

Bildschirmobjekte sind in {\sf Tycoon} normalerweise nicht persistent, da sie
auf dem {\sf StarView Server} erzeugt und verwaltet werden. Es gibt aber einen 
Mechanismus, fl"uchtige Daten trotzdem persistent zu machen, indem sie in eine 
Datenstruktur eingetragen werden, die individuell f"ur jedes Objekt dieser 
Datenstruktur zu genau festgelegten Zeitpunkten Operationen zum Erzeugen, 
Speichern oder Vernichten aufruft. Diese Operationen m"ussen f"ur jedes Objekt 
beim Eintrag in die Datenstruktur mit "ubergeben werden. So wird z.B. jedes 
Objekt dieser Datenstruktur beim erneuten Start einer {\sf Tycoon} Sitzung 
durch Aufruf der entsprechenden Funktion neu erzeugt. Um nicht jedes 
Bildschirmobjekt verwalten zu m"ussen, wird immer das komplette Protokoll 
einer zu visualisierenden Bindung beim Eintrag in die oben beschriebene 
Tabelle in die Datenstruktur eingef"ugt und beim Entfernen aus der Tabelle
wieder aus ihr gel"oscht.

F"ur jedes Protokoll wird eine eigene Funktion {\sl create\/}
"ubergeben. Falls sich das Protokoll im Zustand {\sl new\/} befindet, f"uhrt
die Funktion keine Operationen aus. Hat es dagegen den Zustand {\sl visible\/},
so m"ussen wegen der Integrit"atsbedingungen der Zustand auf {\sl new\/} und
die Funktion {\sl display\/} (s. Abschnitt \ref{display}) aufgerufen werden,
damit die Bildschirmrepr"asentation neu erzeugt und auf dem Bildschirm
angezeigt werden kann. Andere m"ogliche Zust"ande gibt es nicht. W"urde ein
Protokoll allerdings durch {\sl unshow\/} in den Zustand {\sl exists\/}
"ubergehen, so m"u"sten auch f"ur diese Protokolle neue
Bildschirmrepr"asentationen erzeugt werden, ohne diese zu visualisieren. Da in
einer persistenten Umgebung jedoch "uber viele Sitzungen hinweg eine Vielzahl
von Objekten erzeugt und somit auch visualisiert werden, kann die Tabelle eine
gro"se Anzahl von Objekten enthalten. Da wahrscheinlich aber nur die wenigsten
dieser Objekte in jeder Sitzung visualisiert werden sollen, w"are es zu
aufwendig, jedesmal f"ur alle Objekte der Tabelle eine neue
Bildschirmrepr"asentation erzeugen zu m"ussen, so da"s das Protokol bei {\sl
unshow\/} in den Zustand {\sl new\/} "ubergeht.


\subsection{Generierung der Bildschirmrepr"asentation}
\label{display}
Ist f"ur ein Objekt das Protokoll definiert worden, so kann es mittels der 
durch das Modul {\sl browserDisplay\/} exportierten Funktion {\sl display\/} 
auf dem Bildschirm angezeigt werden. Dabei wird zwischen zwei F"allen 
unterschieden --- das Protokoll des Objektes befindet sich in dem Zustand 
{\sl visible\/}, so da"s die Bildschirmrepr"asentation nur noch einmal 
hervorgehoben werden mu"s, oder es mu"s erst eine Bildschirmrepr"asentation 
entsprechend dem Protokoll erzeugt und auf dem Bildschirm angezeigt werden. 
In beiden F"allen werden die oben be\-schrie\-ben\-en Zugriffsfunktionen
verwendet. Mu"s eine Bildschirmrepr"asentation neu erzeugt werden, so m"ussen
ebenfalls der Rahmen, das Men"u und gegebenenfalls die Manipulationskn"opfe der
Bildschirmrepr"asentation generiert werden.



\subsection{Unterst"utzung des Datenaustauschs}
\label{Datenaustausch}
Der Dienst zur Daten-- und Funktionsvisualisierung soll den Datenaustausch 
"uber das Klemmbrett und durch das {\em Drag$\&$Drop} Verfahren
unterst"utzen. Die dazu ben"otigte {\sf StarView} Funk\-tion\-ali\-t"at wird
durch das Modul {\sl browserExchange\/} (s. Anhang \ref{BrowserExchange})
bereitgestellt und soll im folgenden erl"autert werden.


\subsubsection{Datenaustausch "uber das Klemmbrett}
F"ur alle Bildschirmobjekte, die mittels dieses oder eines anderen Dienstes
erzeugt worden sind, stellt {\sl browserExchange\/} ein Klemmbrett zum
Datenaustausch zur Verf"ugung. Daten sollten nur durch die Men"uoperationen
{\sl Cut\/}, {\sl Copy\/} und {\sl Paste} in das Klemmbrett gestellt bzw. aus
ihm herauskopiert werden.

Um Daten im Klemmbrett abzulegen, m"ussen sie mit einem Format versehen werden,
wobei ein Objekt in verschiedenen Formaten gleichzeitig abgespeichert werden
kann. "Uber die den Formaten entsprechenden Zugriffsfunktionen k"onnen Objekte
ins Klemmbrett kopiert bzw. herauskopiert werden. Da Bindungen jedoch keinem
der in {\sf StarView} vordefinierten Formate entsprechen, wird f"ur die Daten--
und Funktionsvisualisierung ein eigenes Format {\sl Bindings\/}
definiert. Jedes Klemmbrett wird mit den Bindungen des aktuell im Klemmbrett
abgelegten Objektes aggregiert. Der Zugriff auf die Bindungen wird "uber die 
Funktionen {\sl copyHdl\/} und {\sl pasteHdl\/} (s. Anhang
\ref{BrowserExchange}) gesteuert. Die Funktion {\sl copyHdl\/} liefert eine
Funktion zur"uck, die die mittels der als Parameter "ubergebenen Funktion {\sl
selectedBindings\/} erhaltenen Bindungen in das Klemmbrett kopiert. Die
Funktion {\sl pasteHdl\/} liefert eine Funktion, die "uberpr"uft, ob das Objekt
im Klemmbrett das Format {\sl Bindings\/} hat. Ist dies der Fall, so wird die
als Parameter "ubergebene Funktion {\sl insertBindings\/} mit den im Klemmbrett
gespeicherten Bindungen ausgef"uhrt. Andernfalls wird die ebenfalls als
Parameter "ubergebene Funktion {\sl default\/} ausgef"uhrt. Die so erhaltenen
Funktionen m"ussen bei jedem Objekt mit den Men"ueintr"agen {\sl Copy\/}
bzw. {\sl Paste\/} verkn"upft werden, um den Datenaustausch zwischen Objekten
"uber das Klemmbrett realisieren zu k"onnen.

Zwei weitere Funktionen {\sl insertEnablePaste\/} und {\sl deleteEnablePaste\/}
werden f"ur den Men"u\-ein\-trag {\sl Paste\/} ben"otigt, um diesen zu steuern.
Immer, wenn Bindungen in das Klemmbrett kopiert werden, mu"s f"ur alle
Bildschirmobjekte der Men"ueintrag {\sl Paste\/}, sofern er vorhanden ist,
aktiviert werden. Entsprechend mu"s dieser Eintrag deaktiviert werden, wenn
Bindungen aus dem Klemmbrett gel"oscht werden. Dazu werden  alle Men"us, die
diesen Eintrag enthalten, in einer Tabelle verwaltet. Wird ein Objekt auf dem
Bildschirm angezeigt, so mu"s der Eintrag {\sl Paste\/} mit {\sl
insertEnablePaste\/} und der Funktion, die diesen Eintrag aktiviert bzw.
deaktiviert, in die Tabelle eingetragen und wenn es vom Bildschirm gel"oscht
wird mit {\sl deleteEnablePaste\/} wieder aus der Tabelle entfernt werden.



\subsubsection{Datenaustausch per Drag$\&$Drop}
Der Datenaustausch per {\em Drag$\&$Drop} wird in {\sf StarView} "uber die
Klassen {\sl DragServer\/}, die das Ziehen ({\em Drag}) eines Objektes steuert,
und {\sl DropEvent\/}, die das Fallenlassen eines Objektes ({\em Drop})
steuert, realisiert. Die Schnittstelle {\sl BrowserExchange\/} stellt einen
eigenen {\em DragServer} f"ur Objekte dieses Dienstes bereit.

Um dieses Verfahren f"ur ein Bildschirmobjekt anwenden zu k"onnen, m"ussen die
Funktionen {\sl initDrag\/} und {\sl initDrop\/} (s. Anhang
\ref{BrowserExchange}) aufgerufen werden. Bei einem durch {\sl initDrag\/}
initialisierten Objekt k"onnen durch Dr"ucken der linken Maustaste die durch
die als Parameter "ubergebene Funktion {\sl getBindings\/} erhaltenen Bindungen
erfa"st werden. Solange die linke Maustaste gedr"uckt ist, k"onnen diese
Bindungen "uber den Bildschirm gezogen werden. "Uber einem mit {\sl initDrop\/}
initialisierten Objekt k"onnen die gezogenen Bindungen fallengelassen und mit
der als Parameter "ubergebenen Funktion {\sl setBindings\/} in die
Bildschirmrepr"asentation eingef"ugt werden. Ein mit {\sl initDrop\/}
initialisiertes Objekt sollte, wenn es vom Bildschirm gel"oscht wird, mit {\sl
uninitDrop\/} wieder deaktiviert werden.


\section{Visualisierungsschnittstelle}
\label{Visualisierungsschnittstelle}
Die Visualisierungsschnittstelle hat die Aufgabe, aus den in der
Strukturanalyse erhaltenen typ-- bzw. wertspezifischen Informationen eines
Objektes {\sl O\/} mit Hilfe der im letzten Abschnitt beschriebenen
unterst"utzenden Schnittstellen ein Protokoll zu generieren, das eine
entsprechende Bildschirmrepr"asentation $bRep_O$ realisiert. Dazu existieren zu
allen in Abschnitt \ref{Aussehen} vorgestellten Bildschirmrepr"asentationen
Generierungsfunktionen, die zur besseren Strukturierung dieser Schnittstelle 
auf verschiedene Module verteilt werden. Allen diesen Funktionen ist gemein,
da"s sie eine Funktion {\sl getValue\/} als Parameter erhalten, die als
Ergebnis den aktuellen Wert einer Bindung zur"uckliefert. Diese Funktion wird
jeweils der Protokollfunktion {\sl getValue\/} zugewiesen. Ansonsten kann
grunds"atzlich zwischen der Visualisierung von Typ-- und Wertbindungen
unterschieden werden, so da"s deren Generierungsfunktionen in getrennten
Abschnitten vorgestellt werden. Da die Visualisierung von Funktionen komplexer
ist als die anderer Werte, wird sie in einem eigenen Abschnitt behandelt.


\subsection{Typvisualisierung}

\begin{table}[tp]
\begin{center}
\begin{tabular}{|l|l|l|}
\hline
{\bf Modul} & {\bf Funktionsname} & {\bf visualisierte Typen}\\ \hline
simpleTypes & newInfo & Basistypen, {\bf Ok}\\
& newAdt & abstrakte Datentypen\\
aggregateTypes & newRecord & Tupel, Rekords, Ausnahmetypen\\
& newVariant & variante Tupel\\
funTypes & new & Funktionen, Typoperatoren\\
appTypes & newArray & Felder\\
& newApp & Typoperatoranwendungen\\
recTypes & new & rekursive Typen\\ \hline
\end{tabular}
\end{center}
\caption{Funktionen zur Visualisierung von Typen} \label{Typvisualisierung}
\end{table}

\noindent Gemeinsamkeiten bei der Visualisierung von Typen ergeben sich
dadurch, da"s Typ\-bin\-dung\-en im Gegensatz zu Wertbindungen nicht
ver"anderlich sein k"onnen. Aus diesem Grund ist es nicht erlaubt, eine Bindung
aus dem Klemmbrett in die Bildschirmrepr"asentation zu kopieren, so da"s der
Men"ueintrag {\sl Paste\/} nicht generiert werden mu"s. Das Fallenlassen einer
anderen Bindung "uber der Bildschirmrepr"asentation ist ebenfalls verboten,
w"ahrend das Kopieren von Typbindungen in ein Ziel--{\em Environment} erlaubt
ist. Um ein destruktives Ver"andern durch den Programmierer zu verhindern,
l"ost die Funktion {\sl setValue\/} des abstrakten Datenstrukturmodells jeweils
ein Ausnahme aus. Schlie"slich gibt die Funktion {\sl apply\/} ausschlie"slich
den Wert {\sl true} zur"uck, da sich die Werte in Bildschirmrepr"asentationen
nicht von denen der Laufzeittyprepr"asentation unterscheiden k"onnen.

Die Generierung der anderen Komponenten des Protokolls ist dagegen
typspezifisch und erfolgt mit Hilfe der {\sf StarView} Klassenbibliothek. Die
verschiedenen Module und Funktionen, die die Protokolle von Typen generieren,
sind in Tabelle \ref{Typvisualisierung} dargestellt.

Unterst"utzt werden diese Funktionen durch ein weiteres Modul {\sl
typeComponent\/}, das f"ur Sig\-na\-tur\-en Operationen zum Erzeugen und Manipulieren
von Bildschirmrepr"asentationen bereitstellt.


\subsection{Wertvisualisierung}
Die Module und Funktionen, die aus den wertspezifischen Informationen die 
Protokolle mit entsprechenden Bildschirmrepr"asentationen zur Visualisierung 
von Werten generieren, sind in Tabelle \ref{Wertvisualisierung} dargestellt.

\begin{table}[htp]
\begin{center}
\begin{tabular}{|l|l|l|}
\hline
{\bf Modul} & {\bf Funktionsname} & {\bf Typen der visualisierte Werte}\\ \hline
simpleValues & newOk & {\bf Ok}, abstrakte Datentypen\\
& newBase & Basistypen\\
aggregateValues & newRecord & Tupel, Rekords\\
& newTupleCase & variante Tupel\\
& newException & Ausnahmetypen\\
arrayValues & new & Felder\\ \hline
\end{tabular}
\end{center}
\caption{Funktionen zur Visualisierung von Werten} \label{Wertvisualisierung}
\end{table}

\noindent Analog zur Visualisierung von Signaturen gibt es ein Modul 
{\sl valueComponent\/}, das Operationen zum Erzeugen und Manipulieren von 
Bindungen bereitstellt. Bei der Wertvisualisierung werden zwei Aspekte genauer 
betrachtet und erl"autert --- die Darstellung bestimmter Komponenten 
direkt in anderen Bildschirmrepr"asentationen und die Manipulation variabler 
Wertbindungen durch Datenaustausch zwischen Bildschirmrepr"asentationen.


\subsubsection{Eingebettete Bildschirmrepr"asentationen}
Konstante Wertbindungen von Basistypen werden als Komponenten anderer 
Wertbindungen aus Gr"unden der "Ubersicht nicht als eigenst"andige Objekte auf 
dem Bildschirm visualisiert, sondern in deren Bildschirmrepr"asentation 
integriert (s. Abschnitt \ref{Basiswerte}). Damit k"onnen Komponenten au"ser 
durch Kn"opfe auch in Form eines Protokolles repr"asentiert werden, das deren
Bildschirmrepr"asentation realisiert. Das ist die einzige Form, in der es eine
Abh"angigkeit zwischen Bildschirmrepr"asentationen gibt. Entsprechend m"ussen
die Protokollfunktionen des Elternobjektes auch jedesmal die entsprechenden
Protokollfunktionen der Kindobjekte aufrufen.


\subsubsection{Manipulation von Werten durch Datenaustausch}
Um den Wert variabler Wertbindungen ver"andern zu k"onnen, wird jeder 
Generierungsfunktion eine Funktion {\sl setValue\/} als Parameter "ubergeben,
die jedoch nicht den Inhalt der Bildschirmrepr"asentation entsprechend
anpa"st. Diese mu"s also bei einem Datenaustausch per Klemmbrett oder {\em
Drag$\&$Drop} innerhalb der Protokollfunktion {\sl setValue\/} aktualisiert
werden. Bei variablen Wertbindungen der Basistypen erfordert dies nur einen
Aufruf der Funktion {\sl refresh\/}. Bei strukturierten Werten ist zu 
unterscheiden, ob deren Komponenten als Knopf dargestellt sind oder aus einer
Bildschirmrepr"asentation bestehen. Im ersten Fall ist die Aktion, die beim
Dr"ucken des Knopfes ausgel"ost wird, dahingehend zu "andern, da"s sie den
neuen Wert visualisiert. Durch Dr"ucken des Knopfes wird dann die
Bildschirmrepr"asentation des neuen Wertes entweder erzeugt, falls diese noch
nicht auf dem Bildschirm sichtbar ist, oder hervorgehoben. Im zweiten Fall ist,
falls sich der Wert ge"andert hat, die alte Bildschirmrepr"asentation zu
l"oschen sowie eine neue zu generieren und im Elternobjekt anzuzeigen. 

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfxsize=0.2\textwidth
\epsfbox{copyBsp1.epsf} \hspace*{0,5cm}
\epsfxsize=0.2\textwidth
\epsfbox{copyBsp2.epsf}
\end{center}
\caption{Beispiel f"ur die Manipulation varianter Tupel} \label{Manipulation}
\end{figure}


Bei varianten Tupeln, bei denen sich durch die Manipulation die dargestellte 
Variante "andert (s. Abb. \ref{Manipulation}), und bei Feldern ist zus"atzlich 
zu beachten, da"s sich die Anzahl der Elemente "andern kann. In beiden F"allen
ist eine komplett neue Bildschirmrepr"asentation zu generieren. Um den
Aufwand bei varianten Tupeln zu verringern, wird f"ur eine Variante die
einmal erzeugte Bildschirmrepr"asentation gespeichert und wiederverwendet,
falls der Wert sp"ater wieder diese Variante annimmt.


\subsection{Funktionsvisualisierung}
Die bei der Visualisierung von Funktionen generierten Protokollfunktionen 
verwalten die Bildschirmrepr"asentation der Funktionssignatur, die sich nicht 
von der von Funktionstypen unterscheidet, sowie den Knopf, mit dem eine
Funktion interaktiv ausgef"uhrt werden kann. Im ersten Unterabschnitt wird
erl"autert, wie die interaktive Funktionsapplikation realisiert werden kann.

Wie in Abschnitt \ref{Funktionswerte} bereits erl"autert, sind f"ur das 
Verst"andnis einer Funktion auch der Programmkode und die im Funktionsrumpf 
referenzierten globalen Bindungen wichtig. Diese Informationen, wie auch 
der {\sf TML} Kode und der {\sf TVM} Kode, erh"alt man nicht durch die
Strukturanalyse, sondern aus den Komponenten des Funktionsabschlusses
(s. Abb. \ref{ExtClosure}). Zur Visualisierung dieser Komponenten, die in den
anderen beiden Unterabschnitten beschrieben werden, werden Funktionen
generiert, die mit den entsprechenden Subeintr"agen des Men"us der
Funktionssignatur verkn"upft und bei deren Auswahl ausgef"uhrt werden.


\subsubsection{Interaktive Funktionsapplikation}
\label{Funktionsapplikation}
Die aktuelle Implementierung der Funktionsvisualisierung erlaubt nur die
Ausf"uhrung parameterloser Funktionen. Daf"ur wird zu der Funktionssignatur
noch ein Knopf mit der Aufschrift {\sl execute\/} generiert und
angezeigt. Dr"uckt der Anwender diesen Knopf, so wird die Funktionsdefinition
in ein allen Funktionen gemeinsames {\em Environment} eingetragen, da aus der
Funktionsdefinition nicht ersichtlich ist, in welchem {\em Environment} sie
gebunden ist. Mit Hilfe der Funktion {\sl eval\/} der reflektiven
Compilerschnittstelle des {\sf Tycoon} Systems \cite{Geis95} kann die
Funktionsapplikation in diesem {\em Environment} "ubersetzt und ausgef"uhrt
werden. Das Ergebnis wird als anonyme Bindung visualisiert.


Soll diese Funktionalit"at auch f"ur nichtparameterlose Funktionen 
angeboten werden, so m"ussen vor dem Aufruf von {\sl eval\/} die
Parameter bestimmt werden. Da Parameter aber eine polymorphe Typvariable als
Typ haben oder Funktionen sein k"onnen, ist deren Eingabe "uber eine direkte
Manipulation von mit Nullwerten gef"ullten Bildschirmrepr"asentationen nicht
m"oglich. Stattdessen k"onnte die Funktionsdefinition in das gemeinsame {\em
Environment} eingetragen werden, in das der Anwender ebenfalls die Bindungen
kopiert, die der Funktion als Parameter "ubergeben werden sollen. In einer
weiteren Bildschirmrepr"asentation m"u"ste f"ur jeden Parameter ein Eingabefeld
f"ur Zeichenketten generiert werden, in die der Anwender die Namen der
Bindungen den Funktionsparametern zuweisen kann. Nachdem die Eingabe
abgeschlossen ist, k"onnen diese Namen aus der Bildschirmrepr"asentation
gelesen und eine Zeichenkette generiert werden, die den Funktionsaufruf
repr"asentiert. Diese wird zusammen mit dem gemeinsamen {\em Environment} der
Funktion {\sl eval} "ubergeben, die den Funktionsaufruf "ubersetzt und
ausf"uhrt.


\subsubsection{Visualisierung globaler Bindungen}
Die Visualisierung globaler Bindungen ist nur m"oglich, wenn von deren Typen
Lauf\-zeit\-typ\-re\-pr"a\-sen\-ta\-tion\-en wie in Abschnitt \ref{Typisierte
Funktionen} beschrieben generiert und in den Funktionsabschlu"s eingetragen
worden sind. Ansonsten wird eine entsprechende Fehlermeldung erzeugt und auf
dem Bildschirm angezeigt.

Mit Hilfe der entsprechenden Funktionen  der Schnittstelle {\sl Closure\/}
werden die globalen Bindungen mitsamt ihren Laufzeittyprepr"asentationen aus
dem Funktionsabschlu"s gelesen und in eine Liste von Bindungen verwandelt. Zur 
Verwaltung dieser Liste wird ein Protokoll generiert, das analog zu Bindungen 
strukturierter Werte die Wertkomponente konstanter Wertbindungen von 
Basistypen direkt und die aller anderen Bindungen "uber einen Knopf darstellt.
Die Bildschirmrepr"asentation der Liste der globalen Bindungen wird in einen
eigenen Rahmen eingebettet mit einem Men"u, das nur den Eintrag {\sl Quit\/}
erh"alt. Da es sich bei der Visualisierung globaler Bindungen nicht um die
Darstellung eines Wertes handelt, ist es nicht erlaubt, andere Objekte in die
Bildschirmrepr"asentation zu kopieren. Das generierte Protokoll wird mit dem
Protokoll der Funktion verkn"upft, damit eine Bildschirmrepr"asentation der
Liste der globalen Bindungen nicht unabh"angig von der 
Bildschirmrepr"asentation der Funktion existieren kann.

\subsubsection{Visualisierung der verschiedenen Koderepr"asentationen}
Die verschiedenen Koderepr"asentationen werden in mehrzeiligen, nicht
manipulierbaren Editierfeldern visualisiert. Diese Editierfelder werden 
allerdings nicht von dem in Abschnitt \ref{Protokoll} beschriebenen Protokoll 
verwaltet, da sich ihre Funktionalit"at zu sehr von den anderen 
Bildschirmrepr"asentationen unterscheidet und da sie mit diesen nicht 
kombinierbar sein m"ussen.

Von Funktionen, die auf dem {\em Toplevel} definiert werden, wird keine
persistente Repr"asentation des Programmkodes erzeugt, so da"s dessen
Visualisierung nicht m"oglich ist. Wird eine Funktion dagegen in einem Modul
definiert, so kann man mit Hilfe des Dateinamens, der in ihrem Literalvektor
gespeichert ist, den Programmkode aus der entsprechenden Datei lesen, sofern
diese noch existiert. Da jedoch der Programmkode in einer Datei unabh"angig 
von seiner ausf"uhrbaren {\sf TVM} Repr"asentation im persistenten Speicher 
existiert, ist nicht sichergestellt, da"s der Programmkode in der Datei noch 
mit dem "ubereinstimmt, den die Funktion ausf"uhrt. 

Um den Kontext, in dem eine Funktion definiert ist, verst"andlich zu machen, 
wird jeweils der Programmkode des gesamten Moduls und nicht nur der Funktion 
visualisiert. Da jedoch verschiedene Funktionen im gleichen Modul definiert 
sein k"onnen, ist deren Bildschirmrepr"asentation im Gegensatz zu den 
Bildschirmrepr"asentationen der globalen Bindungen und der anderen 
Koderepr"asentationen nicht von der Existenz einer Bildschirmrepr"asentation 
einer bestimmten Funktion abh"angig. Um den Programmkode eines Moduls nicht 
mehrmals auf dem Bildschirm zu visualisieren, m"ussen alle Module analog zu 
den visualisierten Objekten in einer durch die Schnittstelle 
{\sl BrowserDict\/} verwalteten Tabelle gespeichert werden, deren Schl"ussel 
der Dateiname ist. Nur vom Programmkode noch nicht visualisierter Module wird 
eine Bildschirmrepr"asentation erzeugt. 

Bei der "Ubersetzung von Funktionen kann optional vom {\sf TML} Kode eine 
persistente Repr"asentation ({\sf PTML}) erzeugt und in den Literalvektor
eingetragen werden. Nur in diesem Fall ist es m"oglich, den {\sf TML} Kode
einer Funktion darzustellen. Dazu mu"s der {\sf PTML} Kode zun"achst in die
{\sf TML} Repr"asentation und danach in eine formatierte Zeichenkette
umgewandelt und auf dem Bildschirm visualisiert werden.

Von jeder "ubersetzten Funktion wird der {\sf TVM} Kode vom Literalvektor der
Funktion referenziert. Bei dessen Visualisierung wird er disassembliert, in
eine formatierte Zeichenkette transformiert und auf dem Bildschirm dargestellt.


\section{Schnittstelle zum Anwendungsprogramm}
\label{Browserschnittstelle}
Die Details der Implementierung und das Protokoll werden vor dem
Anwendungsprogrammierer versteckt. Nur "uber die Schnittstelle {\sl Browser\/}
(s. Anhang  \ref{Anwendungsschnittstelle}) wird ihm der Dienst zur Daten-- und
Funktionsvisualisierung zug"anglich gemacht. Sie erm"oglicht die Visualisierung
von Bindungen und exportiert die Protokollfunktionen, die den Zugriff auf die
Bildschirmrepr"asentationen erm"oglichen. 

Die Visualisierung von Bindungen erfolgt durch die Funktion {\sl binding\/}, 
die au"ser der darzustellenden Bindung noch ein Fenster, das als Elternfenster
der zu generierenden Bildschirmrepr"asentation verwendet wird und keinen
Nullwert haben darf, und einen boole'schen Wert {\sl keepPermanent\/}, mit dem
die entsprechende Komponente des Protokolls gesetzt wird, als Parameter
erwartet. F"ur die Bindung werden ein Protokoll, das als Ergebnis
zur"uckgegeben wird, und die Bildschirmrepr"asentation erzeugt.

Da die Daten-- und Funktionsvisualisierung als generischer Dienst von anderen 
Diensten genutzt werden soll, wird davon ausgegangen, da"s es bereits eine 
Hauptanwendung und damit insbesondere ein Anwendungsfenster gibt. Nur wenn 
dieses Anwendungsfenster auf dem Bildschirm sichtbar ist, wird auch die 
Bildschirmrepr"asentation der entsprechenden Bindung durch {\sf StarView} 
angezeigt. 

Als Ergebnis der Visualisierung wird das Protokoll zur"uckgegeben, auf das der 
Anwendungsprogrammierer "uber die ebenfalls exportierten Protokollfunktionen 
zugreifen kann. Allerdings ist der Zugriff auf die Protokollfunktionen 
{\sl create\/} und {\sl show\/} nicht m"oglich, da eine 
Bildschirmrepr"asentation mit Hilfe der Funktion {\sl display\/} erzeugt und 
dargestellt werden soll, die zus"atzlich die Generierung eines Rahmens, eines 
Men"us und gegebenenfalls der Manipulationskn"opfe realisiert.

Wie in Abschnitt \ref{Visualisierungsbibliothek} erw"ahnt, wird der
Objektspeicher durch {\em Environments}, die in {\sf Tycoon} Werte erster
Klasse sind, strukturiert. Diese sollen jedoch nicht anhand ihrer
Datenstruktur, sondern entsprechend ihrer Semantik visualisiert werden. Deshalb
ist in \cite{Geis95} eine Schnittstelle zur Visualisierung von {\em
Environments} --- ein {\em Environment Browser} --- entwickelt worden. Im
Rahmen dieser Arbeit wurde diese Schnittstelle in die Daten-- und
Funktionsvisualisierung integriert. Dadurch ist eine Anbindung an die {\sf
Tycoon} Programmierwerkbank m"oglich, die Werkzeuge  zur
Programmierunterst"utzung in einem gemeinsamen Rahmen integriert.

Bei der Integration der beiden Dienste ist eine Anpassung der Implementierung
des {\em Environment Browsers} an die Strukturen des Dienstes zur Daten-- und
Funktionsvisualisierung notwendig. Dazu werden, wie bei allen anderen Objekten
auch, die objektspezifischen Eigenschaften durch das allgemeing"ultige
Protokoll gekapselt, so da"s der Zugriff auf einen {\em Environment Browser}
nur noch "uber die Protokollzugriffsfunktionen m"oglich ist. Au"serdem erfolgt
dadurch eine Vereinheitlichung des Datenaustauschs "uber ein gemeinsames
Klemmbrett und einen gemeinsamen {\em Drag Server} f"ur Bindungen und {\em
Environments}. Um die Manipulation des Objektspeicherinhalts anhand seiner {\em
Environmentstruktur} durch direkte Interaktion mit dem {\em Environment
Browser} zu integrieren, wird ein zus"atzlicher Men"uknopf {\sl Bindings\/}
eingef"uhrt, der Men"ueintr"age {\sl Cut\/}, {\sl Copy\/} und {\sl Paste\/}
enth"alt. Au"serdem wird die textuelle Darstellung von Bindungen des {\em
Environments}, die keine direkte Manipulation der Bindungen eines {\em
Environments} erlaubte, durch die Visualisierung mit Hilfe des Dienstes zur
Daten-- und Funktionsvisualisierung ersetzt.
