\chapter{Dienste zur Datenvisualisierung}
\label{Dienste}
Um einen Dienst zur Daten-- und Funktionsvisualisierung zu entwickeln, sind
zun"achst die Anforderungen zu definieren, die dieser erf"ullen soll. 
Dazu werden verschiedene Visualisierungsaspekte untersucht und anhand der 
typvollst"andigen Systeme {\sf O$_2$} \cite{Deux91,BDK92} und {\sf Napier88} 
\cite{MBC*94,KBC*94,BDM*90} erl"autert. Dabei wird auch die Entwicklung in
Programmierumgebungen f"ur datenintensive Anwendungen und die sich daraus
ergebenden Anforderungen ber"ucksichtigt.

Um unterschiedliche Visualsierungsdienste vergleichen zu k"onnen, haben viele
Autoren versucht, Taxonomien f"ur die Softwarevisualisierung aufzustellen
(z.B. \cite{Myer90,StPa92}). Jedoch basieren alle Ans"atze auf
unterschiedlichen Ideen, ohne alle Aspekte der Visualisierung zu
erfassen. Au"serdem werden nirgendwo die Ziele der Visualisierung und die
Gruppe der Benutzer des interaktiven Systems ber"ucksichtigt \cite{Lave95}.
Einzig in \cite{PSB93} wird der Versuch gemacht, den Benutzer zu integrieren.

Deshalb gehen zwar einige der in den verschiedenen Taxonomien aufgestellten
Kriterien in den Vergleich der untersuchten Systeme ein. Die wesentlichen
Fragestellungen orientieren sich jedoch an den Zielen der Visualisierung,
der Art der Darstellung auf dem Bildschirm und der Implementierung der
Visualisierung, die in den ersten drei Abschnitten diskutiert werden. Ausgehend
von den Ergebnissen, die dieser Vergleich erbringt, wird im letzten Abschnitt
dieses Kapitels ein Ansatz f"ur die generische Daten-- und
Funktionsvisualisierung in {\sf Tycoon} vorgestellt.


\section{Ziele der Visualisierung}
Grundlage f"ur den Entwurf einer Visualisierungskomponente bilden die Ziele,
die damit verfolgt werden sollen. Dabei ist zu untersuchen, was zu
visualisieren ist und welche Funktionalit"at auf den visualisierten Objekten
bereitgestellt werden soll.

\subsection{Zu visualisierende Informationen}
In herk"ommlichen Programmiersprachen h"angt die Fragestellung, welche
Informationen zu visualisieren sind, vom Paradigma der zugrundeliegenden
Programmiersprache ab \cite{StPa92}. Grunds"atzlich k"onnen verschiedene
Aspekte eines Programmes visualisiert werden, also z.B. der Programmtext, die
Datenstrukturen, der Status eines sich in der Ausf"uhrung befindlichen
Programmes, der Kontrollflu"s oder die implementierten Algorithmen, wobei
jedoch gilt: je abstrakter der Inhalt der zu visualisierenden Daten ist, desto
weniger kann die Generierung der Bildschirmrepr"asentation automatisiert werden
\cite{Brow88}. So ist es z.B. m"oglich, den Programmtext eines
Sortieralgorithmus' automatisch zu visualisieren. Um jedoch dessen Arbeitsweise
dem Anwender verst"andlich machen zu k"onnen, mu"s die Visualisierung explizit
ausprogrammiert werden, da aus den Strukturen eines Algorithmus' nicht die den
Entwurf dokumentierenden semantischen Informationen gewonnen werden k"onnen.

In Programmierumgebungen f"ur datenintensive Anwendungen liegt der Fokus auf
der Visualisierung persistenter Daten. d.h. auf der Topologie des persistenten
Speichers  und der Struktur der einzelnen Objekte mit den aktuellen Werten
ihrer Komponenten. Durch die konzeptuelle Integration von Datenmodellen und
algorithmisch vollst"andigen Programmiersprachen innerhalb von
Datenbankprogrammiersprachen einerseits, und die Entwicklung neuartiger
Architekturen f"ur die existierenden Systeme zur Datenbankprogrammierung
andererseits, h"angen die zu visualisierenden Daten in diesen Systemen jedoch
nicht mehr allein von dem Paradigma der zugrundeliegenden Programmiersprache,
sondern auch von dem verwendeten Datenmodell und von der Systemarchitektur
ab. Anhand zweier grunds"atzlich unterschiedlicher Familien von
Datenbankprogrammiersprachen --- datenmodellabh"angige und --unabh"angige ---
werden die zu visualisierenden Daten beschrieben.

\subsubsection{Datenmodellabh"angige Programmiersprachen}
Datenmodellabh"angige Programmiersprachen zeichnen sich durch eine 
strikte Trennung zwischen den f"ur den Anwendungsprogrammierer sichtbaren 
Abstraktionen und den sie implementierenden Datenstrukturen oder Algorithmen 
aus, was sich durch die Trennung zwischen Sprachen zur strikt typisierten 
Applikationsprogrammierung und zur weitgehend typ\-un\-sich\-er\-en 
Systemimplementierung manifestiert \cite{Matt93}. Zwei Auspr"agungen dieser
Sprachen sind die relationalen (z.B. {\sf DBPL} \cite{MaSc93a}) und 
objektorientierten (z.B. {\sf O$_2$}) Datenbankprogrammiersprachen.

Relationale Datenbankprogrammiersprachen wie {\sf DBPL} bauen auf einem
pascal"ahnlichen Sprachkern auf und sind um Relationentypen, die Elemente
gleichen Typs zusammenfassen, sowie mengenorientierte Operationen auf
typisierten Relationenvariablen erweitert. Es k"onnen Variablen mit
relationalem Typ oder auch Werte mit nichtprozeduralem Typ gespeichert
werden.

Objektorientierte Systeme dagegen verf"ugen "uber typische objektorientierte
Merkmale wie Objektidentit"at, Klassifikation, Mehrfachvererbung. Ebenso bieten
sie Mechanismen zur Definition sogenannter komplexer Objekte und Methoden sowie
zur sp"aten Bindung und Methodenredefinition in Subklassen an. In {\sf O$_2$}
z.B. wird zwischen Werten und Objekten als Instanzen einer Klasse
unterschieden, die automatisch persistent sind, solange sie von einem benannten
Wurzelobjekt aus einem Schema direkt oder indirekt erreichbar sind. Schemata
dienen in datenmodellabh"angigen Programmiersprachen der abstrakten
Beschreibung der an einer Anwendung beteiligten Relationen bzw. Klassen sowie
deren Strukturen und Beziehungen.

In diesen Systemen existieren Komponenten zur Visualisierung von Schemata, den
Elementen von Relationen bzw. Objekten einer Klasse sowie von
Anfrageergebnissen. O$_2$ bietet dar"uberhinaus noch Komponenten zur
Visualisierung von Anwendungen, Funktionen, per\-sis\-ten\-ten Typen und
per\-sis\-ten\-ten Namen.


\subsubsection{Modellunabh"angige Datenbankprogrammiersprachen}
Persistente Programmiersprachen wie {\sf Napier88} und {\sf P-Quest}
\cite{Muel91,Matt91} unterscheiden sich von den oben beschriebenen  
Datenbankprogrammiersprachen, indem sie einen datenmodellunabh"angigen,
abstrakten, ausdrucksm"achtigen und in sich geschlossenen architektonischen
Rahmen f"ur die Entwicklung gro"ser Softwaresysteme zur Manipulation
langlebiger Daten anbieten. Dies f"uhrt zu einer Unabh"angigkeit von einem
bestimmten Datenmodell und zu orthogonaler Persistenz. Dabei wird orthogonale
Persistenz durch drei Prinzipien erreicht \cite{AtMo95}:

\begin{description}
\item[Unabh"angigkeit der Persistenz:] Eine abstrakte
Objektspeicherschnittstelle wickelt w"ahr\-end der Programmausf"uhrung alle
Speicherzugriffe ab. Sie gestattet die Gleichbehandlung von persistenten und
nichtpersistenten sowie proze"slokalen und systemweiten Datenstrukturen
innerhalb von Applikations-- und auch Systemprogrammen.
\item[Orthogonalit"at der Datentypen:] Werte beliebiger Datentypen, und damit 
auch Module und Anwendungsprogramme, k"onnen gespeichert werden.
\item[Identifikation von Persistenz:] Alle Objekte, die transitiv von einem 
ausgezeichneten Wur\-zel\-ob\-jekt durch statische Sichtbarkeitsregeln oder 
dynamische Bindungen erreichbar sind, werden langlebig gespeichert und stehen 
anderen Programmen zur Verf"ugung.
\end{description}

\noindent Die Unabh"angigkeit von einem speziellen Datenmodell f"uhrt dazu,
da"s in diesen Systemen nicht die Visualisierung von Schemata und Massendaten,
sondern die Visualisierung beliebiger Datenstrukturen des Objektspeichers im
Vordergrund steht. Da durch die orthogonale Persistenz Anwendungsprogramme und
Module selbst wieder als Daten betrachtet werden k"onnen, umfa"st dies auch
persistente Programme, wobei die gleichen Aspekte visualisiert werden k"onnen
wie bei Programmen in nichtpersistenten Programmiersprachen. Damit dient die
Datenvisualisierung in persistenten Programmiersprachen nicht nur dem Anwender,
sondern sie kann auch den Anwendungsprogrammierer bei der Entwicklung seiner
Programme unterst"utzen.

W"ahrend in modellabh"angigen Datenbankprogrammiersprachen die Beschreibung
der in einer Datenbank gespeicherten Daten durch ein Schema erfolgt, geschieht
dies in modellunabh"angigen Datenbankprogrammiersprachen durch Typausdr"ucke.
Um das Verst"andnis der visualisierten Daten zu erh"ohen, sollten
dementsprechend auch Typen visualisiert werden.

Ein langfristiges Ziel in modellunabh"angigen Programmiersprachen ist es,
unterschiedliche Datenmodelle uniform durch ein ausreichend ausdrucksf"ahiges
Typsystem auszudr"ucken \cite{AtMo86}. Zwei Ans"atze, dies zu erreichen, sind
erweiterbare Grammatiken \cite{MSW95} und, um die Anwendungssemantik der
Datenmodelle zu erfassen, die Erweiterung der persistenten Programmierumgebung
unter Ausnutzung des existierenden Typsystems um dom"anenspezifische
konzeptuelle Abstraktionen, durch das System erzwungene
Integrit"atsbedingungen, die "uber das Typsystem hinausgehen, und erweiterte
generische Systemfunktionalit"at \cite{WMS95}. Anders als in modellabh"angigen
Datenbankprogrammiersprachen m"ussen dabei zur Visualisierung der Daten jeweils
zus"atzliche Dienste bereitgestellt werden, um die Daten entsprechend ihrer
Semantik darzustellen.


\subsection{Funktionalit"at}
Eine zweite Dimension zur Bestimmung der Ziele der Datenvisualisierung ist die
auf den dargestellten Daten angebotene Funktionalit"at. Grunds"atzlich hat  
ein Visualisierungsdienst in persistenten Programmierumgebungen die
Aufgabe, die Topologie und den Inhalt des persistenten Speichers
darzustellen. Dazu mu"s der Anwender, neben der M"oglichkeit, beliebige
langlebige Daten visualisieren zu k"onnen, auch in der Lage sein, entlang der
visualisierten Daten durch den persistenten Speicher zu navigieren. Weitere
Funktionalit"at ist abh"angig von dem Zweck, zu dem die visualisierten Daten
verwendet werden sollen, und wird anhand von {\sf O$_2$} und {\sf Napier88}
diskutiert.


\subsubsection{O$_2$}
{\sf O$_2$} verf"ugt mit {\sf O$_2$Tools} "uber eine komplette grafische
Programmierumgebung f"ur den Entwurf und die Entwicklung objektorientierter
Datenbankapplikationen. {\sf O$_2$Tools} zielt auf zwei unterschiedliche
Benutzergruppen ab:

\begin{itemize}
\item Der Softwareentwickler benutzt {\sf O$_2$Tools} einerseits, um Daten und
Schemata zu visualisieren und zu editieren sowie Anfragen darauf zu
formulieren, und andererseits zum Editieren und Testen von Methoden und
Programmen sowie zur Fehlersuche.
\item Der Anwender kann {\sf O$_2$Tools} benutzen, um Daten der Datenbank und
die Schemata zu visualisieren, zu editieren und Anfragen darauf zu formulieren.
\end{itemize}

\noindent Eine Komponente von {\sf O$_2$Tools} ist der {\em Browser}, der die
Visualisierung, Modifizierung, d.h. Erzeugen, Ver"andern und L"oschen, von
Schemata und Daten der Datenbank sowie Anfragen darauf erm"oglicht
\cite{O2Te92}. Somit wird die Funktionalit"at herk"ommlicher
Visualisierungskomponenten erweitert um Manipulations-- und
Anfragem"oglichkeiten. Um die Manipulation visualisierter Werte realisieren 
zu k"onnen, m"ussen bei "Anderungen in der Datenbank oder im Schema auch die
entsprechenden Bildschirmrepr"asentation aktualisiert werden und umgekehrt.
Au"ser der direkten Manipulation von Eingabefeldern per Tastatur wird die
Manipulation per Datenaustausch zwischen unterschiedlichen
Bildschirmrepr"asentationen unterst"utzt. Dies erfordert dynamisch,
d.h. zur Laufzeit, eine Typ"uberpr"ufung, um sicherzustellen, da"s der in eine
Bildschirmrepr"asentation kopierte Wert den gleichen Typ hat wie der
urspr"unglich dargestellte Wert. Da der {\em Browser} in die
Entwicklungumgebung integriert ist, k"onnen daraus auch andere Dienste wie 
z.B. ein Quelltexteditor f"ur Methoden gestartet werden.

\subsubsection{Napier88}
In {\sf Napier88} ist der Objektspeicher durch sogenannte {\sf Environments} 
strukturiert, die Werte erster Klasse darstellen \cite{DCC92}. Jedes 
{\sf Environment} enth"alt eine Liste von Bindungen, die selbst auch wieder 
{\sf Environments} referenzieren k"onnen. Um auf einen Wert des 
Objektspeichers zugreifen zu k"onnen, mu"s der Anwendungsprogrammierer den 
Pfad zu dem {\sf Environment} spezifizieren, in dem dieser gebunden ist.

Die erste Version des {\em Browsers} erlaubte nur die Visualisierung von Werten
und das Navigieren im Objektspeicher. Der Anwender sollte bei der
Programmierung unterst"utzt werden, indem er ihm beim Auffinden von Werten
hilft, die Ergebnisse von Berechnungen in grafischer Form anzeigt und durch
Integration in einen {\em Debugger} die Fehlersuche erleichtert \cite{DeBr88}.

Die Erweiterung des {\em Browsers} um einen Mechanismus zur
Markierung visualisierter Werte erlaubt eine Unterst"utzung der
Programmkonstruktion durch die Bindung von Werten zu unterschiedlichen
Zeitpunkten \cite{FDK*92}:

\begin{description}
\item[Bindung zur Laufzeit:] Durch die Markierung visualisierter Werte, die zur
Laufzeit gebunden werden sollen, kann automatisch w"ahrend der
Erstellung des Programmtextes eine Repr"asentation des sie lokalisierenden
Pfades generiert und in den Quellkode integriert werden. 
\item[Bindung zur "Ubersetzungszeit:] Werte und Typen, die zur
"Ubersetzungszeit in einer "Ubersetzungsumgebung gebunden werden sollen,
k"onnen mit einem Namen markiert werden, der im Programmtext als
Zugriffsspezifikation verwendet werden darf. Als Eingabe erh"alt der {\em
Compiler} den Quelltext zusammen mit der Abbildungsvorschrift der Markierungen
auf Werte und Typen. Indem der gleiche Programmtext mit unterschiedlichen
Abbildungsvorschriften verwendet wird, k"onnen unterschiedliche Anwendungen
erzeugt werden, ohne die ansonsten aufwendige textuelle Spezifikation des
Zugriffs auf Werte und Typen "andern zu m"ussen.
\item[Bindung zur Programmkonstruktionszeit:] Durch das direkte Einf"ugen
markierter Werte in den Programmtext, genannt {\em Hyperprogrammierung}
\cite{KCC*92}, erh"alt man nichtlineare Programmrepr"asentationen. Hierbei
erfolgt die Abbildung der Markierungen auf die Werte bereits zur
Konstruktionszeit des Programmtextes. Diese Art der Programmerzeugung erfordert
allerdings zus"atzliche grafische Benutzerinteraktion in einem  speziellen
Programmeditor, der die Repr"asentation und Visualisierung markierter Werte
innerhalb des Programmtextes erm"oglicht.
\end{description}


\section{Visualisierungsaspekte}
In \cite{LaSi87} wird behauptet, da"s Grafik einen Vorteil gegen"uber Text 
besitzt, da die Repr"asentation einfach wahrnehmbar ist und nicht
anspruchsvollere logische Schlu"sfolgerungen f"ur das Verst"andnis notwendig
sind, und da die r"aumliche Anordnung zur Verringerung der Suchzeit
beitr"agt. Dies gilt nach \cite{LeAp93} aber nur, wenn die Visualisierung sich
an der Aufgabe orientiert und den Anforderungen entsprechende Repr"asentationen
erzeugt werden. In diesem Abschnitt werden verschiedene Visualisierungsaspekte
untersucht, die das Verst"andnis der dargestellten Daten beeinflu"sen.

\subsection{Grafische Benutzerschnittstelle}
Die Erstellung grafischer Repr"asentationen kann sehr zeitintensiv und mit viel
Programmtext verbunden sein. Um den Entwickler bei der Konstruktion von
Visualisierungsschnittstellen zu unterst"utzen, gibt es Dienste, die eine Reihe
grafischer Grundfunktionalit"aten implementieren und bereitstellen. Er mu"s
dann nur noch die f"ur seine Anwendung notwendigen Elemente miteinander
verbinden.

Eine ausf"uhrliche  Vorstellung existierender Dienste sowie deren Vor-- und
Nachteile findet sich in \cite{Mues94}. Dabei wird die Kombination aus
system"ubergreifender Klassenbibliothek, die die Portabilit"at von Anwendungen
bez"uglich unterschiedlicher Fenstersysteme sicherstellt, und
Quelltextgenerator f"ur die Integration als generischer Dienst in
eine allgemeine Programmiersprache empfohlen. In diesem Abschnitt sollen
zus"atzlich Aspekte bez"uglich der Frage, ob eine existierende externe oder
eine in der Programmierumgebung entwickelte Klas\-senbib\-lio\-thek verwendet
werden soll, und bez"uglich der Portabilit"at diskutiert werden.

\subsubsection{Externer versus interner Dienst}
Ein in der Programmierumgebung selbst entwickelter Dienst hat den Vorteil, 
da"s der Dienst entsprechend den eigenen W"unschen und Anforderungen 
entwickelt werden kann. Bei der Verwendung externer Dienste dagegen ist eine
Kompromi"sl"osung notwendig, da diese die Anforderungen nicht in idealer Weise
erf"ullen. Um eine bedingte Anpassung an die eigenen Anforderungen zu
erm"oglichen, sollte ein externer Dienst aber erweiterbar sein. Diese 
Forderung wird durch objektorientierte Dienste erf"ullt. Der Vorteil externer
Dienste ist, da"s die Entwicklung einer eigenen Benutzerschnittstelle sehr
aufwendig und fehlertr"achtig sein kann und einen hohen Wartungsaufwand
erfordert.

Sowohl {\sf O$_2$} mit dem Benutzerschnittstellengenerator {\sf O$_2$Look} als
auch {\sf Napier88}, verwenden einen internen Dienst zur Entwicklung grafischer
Objekte. {\sf O$_2$Look} ist voll in die persistente Umgebung integriert, ein
Kennzeichen objektorientierter Systeme, die sich durch eine enge konzeptuelle
und technologische Verflechtung zwischen grafischen Benutzerschnittstellen,
modularer und erweiterbarer Datenabstraktion sowie effizienten Objektspeichern
auszeichnen \cite{Matt93}. Die wesentlichen F"ahigkeiten von {\sf O$_2$Look}
sind \cite{Deux90}:

\begin{itemize}
\item Die grafische und interaktive Manipulation beliebig komplexer {\sf O$_2$}
Objekte und Werte wird unterst"utzt.
\item Der Programmierer kann grafische Benutzeroberfl"achen erzeugen.
\item Um die Anforderungen spezifischer Anwendungen zu erf"ullen, k"onnen 
die grafischen Repr"asentationen sowohl statisch definiert als auch dynamisch 
ver"andert werden.
\end{itemize}

\noindent Da in {\sf O$_2$Look} jedoch die Bildschirmrepr"asentationen nur
eingeschr"ankt modifizierbar sind, existiert ein weiterer Dienst {\sf
ToonMaker}, der die Abbildung zwischen Datenbankobjekten und grafischen
Strukturen zus"atzlich unterst"utzt, indem er 

\begin{itemize}
\item die Modifizierung vorgefertigter Pr"asentationen eines Objektes einer 
bestimmten Klasse erlaubt und
\item die Erzeugung einer Pr"asentationsschablone unterst"utzt, die der 
Programmierer f"ur verschiedene Instanzen einer Klasse wiederverwenden kann  
\cite{BMP*92}.
\end{itemize}

\noindent Diese Eigenschaften erlauben eine interaktive Anpassung der 
Datenvisualisierung an die Semantik durch den Entwickler. In 
modellabh"angigen Datenbankprogramierumgebungen, in denen sich die Struktur 
der abgespeicherten Daten kaum ver"andert, kann dadurch die ansonsten 
automatische Generierung unterst"utzt werden. In modellunabh"angigen 
Datenbankprogrammiersprachen dagegen erscheinen diese Eigenschaften nur f"ur 
sich kaum "andernde Programmstrukturen sinnvoll, wie z.B. f"ur Werte, die einen
aus den Modulen der {\sf Tycoon} Standardbibliothek exportierten Typ besitzen.

In {\sf Napier88} ist ein eigenes Fenstersystem {\sf WIN} mit Funktionen zur
Bearbeitung von Bildschirmobjekten entwickelt worden, da es gegen"uber externen
Diensten den Vorteil hat, da"s die Bildschirmobjekte wie alle Daten automatisch
persistent sind. Bei der Verwendung externer Dienste ist ein zus"atzlicher
Mechanismus notwendig, um die auf einem externen {\em Server} erzeugten und
verwalteten Bildschirmobjekte zu speichern. Allerdings weist das System noch
einige konzeptuelle M"angel auf, da z.B. zu wenig Interaktionselemente
angeboten werden und auch das Modell zur Handhabung von Ereignissen einer
"Uberarbeitung bedarf \cite{Lave95}.


\subsubsection{Portierbarkeit}
In verteilten, heterogenen Anwendungen spielt die Portierbarkeit der
Anwendungen eine wichtige Rolle. Klassenbibliotheken setzen auf den
Fenstersystemen auf, die auf der jeweiligen Hardware installiert sind. Um 
system"ubergreifend zu sein, m"ussen sie eine identische
Programmierschnittstelle und Sprache f"ur die Beschreibung von
Benutzerschnittstellen verschiedener Fenstersysteme anbieten, die von der
teilweise unterschiedlichen Funktionalit"at und dem {\em look\&feel} der
jeweiligen Fenstersysteme abstrahieren. Dies stellt eine hohe Anforderung an
system"ubergreifende Klassenbibliotheken dar, wobei es zwei unterschiedliche
Ans"atze zur Vereinheitlichung unterschiedlicher Funktionalit"aten gibt: beim
{\em Schnittmengenansatz} wird nur die allen Fenstersystemen gemeinsame
Funktionalit"at unterst"utzt, w"ahrend beim {\em Obermengenansatz} versucht
wird, f"ur jedes Fenstersystem die nicht unterst"utzte Funktionalit"at anderer
Fenstersysteme nachzubilden \cite{Mues94}.

%Eine M"oglichkeit, das Problem der Portierbarkeit zu l"osen, ist die Verwendung
%von {\sf Common Gateway Interface (CGI)} Skripten, einem Standard, um externe
%Applikationen mit einem Informationsserver des {\em World Wide Web} zu
%verkn"upfen, und der grafischen Klassenbibliothek {\sf Another Window Toolkit
%(AWT)} der Programmierumgebung von {\sf Java} \cite{SunM95}, die die
%Entwicklung portabler grafischer Repr"asentationen in {\em Hypertext
%Markup Language (HTML)} Format erm"oglichen. Dadurch ist es
%z.B. m"oglich, eine Datenbank an einen Informationsserver anzuschlie"sen und
%eine Anwendung zu schreiben, die Anfragen an die Datenbank stellt und die
%Visualisierung der Ergebnisse auf dem Informationsserver realisiert. Neben der
%Portierbarkeit ist die Verwendung von {\em Hyperlinks} eine elegante
%M"oglichkeit, Verkn"upfungen zwischen den Daten herzustellen und durch die
%Daten zu navigieren. Beispielsweise werden in der {\sf TooL} Umgebung {\sf CGI}
%und {\sf Java} eingesetzt, um die Klassenhierarchie und die Beschreibung der
%Klassen zu visualisieren. Zur Zeit kann diese L"osung allerdings noch nicht als
%Alternative zu den herk"ommlichen Klassenbibliotheken angesehen werden, da eine
%Aktualisierung der visualisierten Daten auf dem Informationsserver durch die
%Datenbank noch nicht m"oglich ist.


\subsection{Visualisierung von Objekten}
Die Art der Visualisierung wird davon beeinflu"st, was zu welchem Zweck
dargestellt werden soll. F"ur die Visualisierung von Hierarchien eignet sich 
z.B. die Darstellung in Form von Graphen. In diesem Abschnitt werden 
Aspekte bez"uglich der Visualisierung von Objekten diskutiert,
d.h. Datenbankobjekten in  modellabh"angigen Programmierumgebungen und
Programmobjekten in persistenten Programmiersprachen.

Ein Visualisierungsaspekt betrifft die Bindung eines Objektes an verschiedene
Namen. Um diese Semantik dem Anwender auch bei der Visualisierung von Objekten
zu vermitteln, sollte ein Objekt nur einmal auf dem Bildschirm dargestellt
werden. Falls zu einem Objekt mehrere Bildschirmrepr"asentationen existierten,
w"are ein erh"ohter Verwaltungsaufwand notwendig, um die Konsistenz der
visualisierten Daten zu gew"ahrleisten, da bei einer Manipulation eines
visualisierten Objektes auch alle anderen Bildschirmrepr"asentationen dieses
Objektes entsprechend aktualisiert werden m"u"sten.

Da die zu visualisierenden Objekte in der Regel strukturiert sind, hat sich die
Strukturdarstellung als eine geeignete Repr"asentation von Objekten
herausgestellt. Diese Technik wird auch in {\sf O$_2$} und {\sf Napier88}
angewendet. Unterschiede existieren in der Darstellung der Komponenten. In
{\sf Napier88} werden grunds"atzlich der Name und der Typ der Komponente
dargestellt. Um sich den Wert einer Komponente anzusehen, mu"s der Anwender mit
der Maus die Komponente ausw"ahlen. Werte von Basistypen werden dann in einem
allen Basiswerten gemeinsamen Fenster in textueller Form, strukturierte Werte 
dagegen in einem eigenen Fenster visualisiert. Diese Darstellung hat den 
Nachteil, da"s sie f"ur den Anwender sehr un"ubersichtlich werden kann, wenn 
ein Wert aus vielen Komponenten besteht und der Wert jeder Komponente in einem 
eigenen Fenster dargestellt wird. Dieses versucht man in {\sf O$_2$} zu 
verhindern, indem Komponenten in dem Objekt dargestellt werden, zu dem sie 
geh"oren. Bei Werten von Basistypen erfolgt dies direkt, bei strukturierten 
Werten werden zun"achst auch nur Name und Typ der Komponente dargestellt. Wird 
eine strukturierte Komponente mit der Maus angeklickt, so wird der Typ durch 
eine Repr"asentation des strukturierten Wertes ersetzt. Ziel dieser 
Darstellung ist es, die {\em Ist--Teil--Von}--Relation sichtbar zu machen 
\cite{BMP*92}. F"ur konstante Werte von Basistypen erscheint diese Regelung 
aus Gr"unden der "Ubersicht sinnvoll. Variable Werte von Basistypen sowie 
strukturierte Komponenten, die wiederum variable Komponenten enthalten 
k"onnen, sollten dagegen weiterhin in eigenen Fenstern visualisiert werden, da 
ansonsten von einem Wert verschiedene Bildschirmrepr"asentationen existieren 
w"urden. 

Um die {\em Ist--Teil--Von}--Relation trotzdem sichtbar zu machen, werden
z.B. in {\sf Napier88} Referenzen durch Pfeile dargestellt. Bei der
Visualisierung gro"ser und komplexer Datenstrukturen erweist sich jedoch die 
begrenzte Gr"o"se des Bildschirms als Problem, da es bei vielen Referenzen f"ur
den Anwender unm"oglich wird, die Relationen zu identifizieren. Zur L"osung
dieses Problems wurde zus"atzlich das Konzept des Universums eingef"uhrt, in
dem der Anwender mehrere Objekte zu einer Gruppe zusammengefassen kann. Da ein
Universum ein in sich abgeschlossenes Bildschirmobjekt darstellt, zeigen
Referenzen auf die in einem Universum zusammengefa"sten Objekte auf das
Universum, nicht aber auf das Objekt selbst. Au"serdem k"onnen dadurch von
einem Objekt mehrere Bildschirmrepr"asentationen in unterschiedlichen Universen
erzeugt werden. Damit wird durch die Darstellung von Referenzen als Pfeile
nicht das Verst"andnis f"ur die dargestellten Objekte erh"oht, sondern im
Gegenteil sogar erschwert.


\subsection{Sichtfokussierte versus objektfokussierte Umgebungen}
Eine Frage, die in \cite{CUS95} diskutiert wird, besch"aftigt sich mit dem 
Problem, ob in Programmierumgebungen die sichtfokussierte oder die 
objektfokussierte Darstellung gew"ahlt werden soll. Diese Frage betrifft 
zwar prim"ar Probleme in visuellen Programmiersprachen und --umgebungen, 
trotzdem sind aber auch einige Aspekte relevant f"ur die Datenvisualisierung 
in {\sf Tycoon}.

Die meisten Programmierumgebungen w"ahlen die sichtfokussierte Darstellung, in
der Dienste als Zwischenmedium f"ur die Untersuchung und Manipulation von
Objekten dienen (s. Abb. \ref{Fokus}\footnote{entnommen aus \cite{CUS95}}). Das
dr"uckt sich dadurch aus, da"s in einem Dienst nur bestimmte Sichtweisen auf
ein Objekt bereitgestellt werden und da"s der Anwender "uber den Dienst mit den
Objekten kommuniziert, z.B. indem Men"us nicht den Objekten direkt, sondern dem
Dienst zugeteilt sind. Dadurch werden Dienste konkret, Objekte dagegen
erscheinen als abstrakt, distanziert und zweitrangig.

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{objektfokus.epsf} \hfill \epsfbox{viewfokus.epsf}
\end{center}
\caption{Objektfokussierte vs. sichtfokussierte Darstellung}
\label{Fokus}
\end{figure}

In der objektfokussierten Darstellung dagegen soll das Zwischenmedium 
verschwinden und somit das Objekt konkret, unmittelbar und prim"ar werden (s. 
Abb. \ref{Fokus}). Anhand der typsicheren, objektorientierten und
nichtpersistenten Programmiersprache {\sf Self} \cite{UnSm87} werden einige
Prinzipien vorgestellt, um eine objektfokussierte Darstellung zu erreichen: 

\begin{description}
\item[Unmittelbarkeit:] Durch eine unmittelbare Abbildung der Sprachobjekte 
entsprechend dem zugrundeliegenden Sprachmodell auf ihre korrespondierende 
Bildschirmrepr"asentation sowie eine dreidimensionale Darstellung und die 
Verwendung von Animation \cite{ChUn93} sollen die Bildschirmobjekte als die 
Objekte selbst und nicht nur als Bildschirmrepr"asentation erscheinen.
\item[Vorrang:] Die Funktionalit"at, d.h. die Eigenheiten und das Verhalten, 
sollen direkt mit dem Bildschirmobjekt verkn"upft sein, so da"s der Anwender 
nicht "uber die von einem Dienst bereitgestellte Funktionalit"at, sondern 
"uber das Bildschirmobjekt selbst darauf zugreifen kann. Der Zugriff kann 
z.B. "uber einen Men"ueintrag oder einen Knopf erfolgen.
\item[Verf"ugbarkeit:] Jederzeit soll die gesamte und nicht nur eine durch 
einen Dienst eingeschr"ankte Funktionalit"at f"ur ein 
Bildschirmobjekt verf"ugbar sein.
\item[Lebendigkeit:] Eine lebendige Schnittstelle erlaubt es einem Objekt, 
sich unter eigener Kontrolle zu bewegen, zu ver"andern und zu interagieren. 
\end{description}

\noindent F"ur jede Art von Objekten, also z.B. Instanzen, Klassen und
Metaklassen in objektorientierten Programmiersprachen, m"ussen geeignete
Repr"asentationen gefunden werden, um die objektfokussierte Sicht zu
verwirklichen.


\section{Implementierungsaspekte}
Da in persistenten Programmierumgebungen die Verwendung von Bindungen an
semantische Objekte nicht auf die Programme beschr"ankt ist, in denen sie
definiert werden, k"onnen die zu visualisierenden Daten eine beliebige Struktur
haben, die zum Zeitpunkt der Entwicklung des generischen
Visualisierungsdienstes jedoch nicht f"ur jeden Wert bekannt sein kann. Der
Dienst mu"s also in der Lage sein, Daten unbekannter Struktur zu
visualisieren. Objektorientierte Programmiersprachen wie {\sf Smalltalk-80}
\cite{GoRo83} versuchen dieses Problem zu umgehen, indem f"ur jede Klasse eine
{\sl Print} Methode geschrieben werden mu"s, die Instanzen dieser Klasse
visualisiert. Solch eine Methode ist jedoch nicht sicher, da sie durch eine
Methode "uberschrieben werden kann, die eine v"ollig andere Funktionalit"at
realisiert. Deshalb sollte der generische Visualisierungsdienst Daten
beliebiger Struktur visualisieren k"onnen, ohne vom Programmierer abzuh"angen.

Eine M"oglichkeit, zur Laufzeit Strukturinformationen zu erhalten, ist die
Verwendung dynamischer Typisierung, die zun"achst kurz vorgestellt wird. Anders
als in Kapitel \ref{Dynamics} steht dabei ein Vergleich strikt typisierter und
dynamisch typisierter Programmiersprachen im Vordergrund. Darauf aufbauend
werden zwei Ans"atze zur Realisierung der generischen Datenvisualisierung
erl"autert sowie ihre Vor-- und Nachteile diskutiert.

%Da in persistenten Programmierumgebungen die Verwendung von Bindungen an
%semantische Objekte nicht auf die Programme beschr"ankt ist, in denen sie
%definiert werden, sind die Typen aller zu visualisierenden Daten potentiell
%unbegrenzt und zum Zeitpunkt der Entwicklung des generischen 
%Visualisierungsdienstes nicht vollst"andig bekannt. Der Dienst mu"s also in 
%der Lage sein, Daten zu visualisieren, deren Typ er nicht kennt, so da"s er 
%auf dynamische Typinformationen angewiesen ist. Objektorientierte 
%Programmiersprachen wie {\sf Smalltalk-80} \cite{GoRo83} versuchen dieses 
%Problem zu umgehen, indem f"ur jede Klasse eine {\sl Print} Methode 
%geschrieben werden mu"s, die Instanzen dieser Klasse visualisiert. Solch eine 
%Methode ist jedoch nicht sicher, da sie durch eine Methode "uberschrieben 
%werden kann, die eine v"ollig andere Funktionalit"at realisiert. Deshalb 
%sollte der generische Visualisierungsdienst Daten beliebigen Typs 
%visualisieren k"onnen, ohne vom Programmierer abzuh"angen.

%In diesem Abschnitt werden zwei Methoden vorgestellt, die dieses Problem
%l"osen. Dabei werden sowohl die Idee des Ansatzes erl"autert als auch deren
%Vor-- und Nachteile diskutiert.


\subsection{Bedeutung einer dynamischen Typisierung}
\label{Typdiskussion}
{\sf TL} ist eine strikt typisierte Programmiersprache, deren Typ"uberpr"ufung
statisch zur "Ubersetzungszeit erfolgt. Die strikte Typisierung stellt sicher,
da"s alle Programmentit"aten vor der Programmausf"uhrung auf Konsistenz mit dem
Typsystem gepr"uft werden, so da"s die Programmausf"uhrung nicht aufgrund von
Typfehlern ein falsches Ergebnis liefert oder sogar durch einen Laufzeitfehler
abbricht. Dieses ist zur Konsistenzerhaltung der Daten in verteilten
datenintensiven Anwendungen \cite{ScMa93,SMV93}, f"ur die Skalierbarkeit eines
Systems und f"ur die Unterst"utzung durch externe Dienste unverzichtbar
\cite{MaSc93}. Da die Typkorrektheit in der "Ubersetzungsphase "uberpr"uft
wird, wird die Programmausf"uhrung effizienter. Deshalb ist die statische
Typ"uberpr"ufung der dynamischen vorzuziehen.

Dynamisch typisierte Sprachen wie {\sf CLOS} \cite{KRB91}, die auch, wie am
Beispiel von {\sf $P_LO_B!$} \cite{Kirs94} gezeigt worden ist, um Persistenz
erweitert werden k"onnen, haben gegen"uber statisch typisierten Sprachen den
Vorteil, da"s der Programmierer jederzeit auf die Typinformationen der Werte
zugreifen kann. Dadurch lassen sich Anwendungen wie die generische
Datenvisualisierung (zu weiteren Beispielen s. Abschnitt \ref{Anwendungen})
realisieren. In statisch typisierten Programmiersprachen ist bei diesen
Anwendungen jedoch zur "Ubersetzungszeit nicht feststellbar, welchen Typ ein
Wert zur Laufzeit haben wird. Zu diesem Zweck m"ussen sie um das Konzept der
dynamischen Typisierung erweitert werden, das in den Situationen, in denen eine
statische Typ"uberpr"ufung nicht m"oglich ist, eine Typ"uberpr"ufung zu
wohldefinierten Zeitpunkten w"ahrend der Programmlaufzeit erlaubt
\cite{Matt87}. 


\subsection{Ausnutzung von Objektformaten auf Speicherebene}
\label{Objektformate}
Eine M"oglichkeit, Daten beliebigen Typs visualisieren zu k"onnen, findet auf 
einem sehr niedrigen Abstraktionsniveau statt, indem Kenntnisse "uber die 
interne Repr"asentation von Daten innerhalb des Objektspeichers ausgenutzt 
werden. Da in der Regel die Abbildung der Daten auf die Objektformate 
injektiv, aber nicht bijektiv ist, lassen sich die Daten allein aufgrund ihrer 
Objektformate jedoch semantisch nicht korrekt visualisieren. Deshalb mu"s
entsprechend der zur Laufzeit des Visualisierungsdienstes inspizierten
dynamischen Typinformationen aus den Objektformaten eine semantisch korrekte
Bildschirmrepr"asentation der Daten erzeugt werden. Dazu m"ussen spezielle
Funktionen bereitgestellt werden, mit deren Hilfe die Informationen aus den
Objektformaten herausgelesen und innerhalb der Programmiersprache verwendet
werden k"onnen.

Solch ein Ansatz ist innerhalb von {\sf Napier88} realisiert worden 
\cite{KiDe90}. Der Dienst zur generischen Daten-- und Funktionsvisualisierung 
stellt f"ur jeden Wertkonstruktor eine Funktion bereit, die aus Daten, die mit 
diesem Konstruktor erzeugt worden sind, eine Bildschirmrepr"asentation
generiert. Jede dieser Funktionen verwendet weitere Funktionen, die den Zugriff
auf die Objektstruktur der Daten realisieren. Um die einem Wert entsprechende
Visualisierungsfunktion aufrufen zu k"onnen, mu"s mit Hilfe entsprechender
Funktionen die mit ihnen assoziierte Typrepr"asentation extrahiert und in ihre
Komponenten zerlegt werden.

Dieser Ansatz hat den Nachteil, da"s er abh"angig ist von der jeweiligen
Implementierung des zugrundeliegenden Systems. "Andert sich die Repr"asentation
der Objektformate, so ist auch der generische Dienst zur Daten-- und
Funktionsvisualisierung entsprechend anzupassen. Zudem mu"s der Programmierer
dieses Dienstes nicht nur die Programmiersprache, sondern auch die
Objektformate kennen. Da diese vor dem Anwendungsprogrammierer verborgen werden
sollen, kann dieser Dienst nur von einem Systemprogrammierer entwickelt werden.


\subsection{Implementierung durch linguistische Reflektion}
\label{Reflektion}
Ein anderer Ansatz, der unabh"angig von den Objektformaten und damit der 
Implementierung des Systems ist, basiert auf den reflektiven F"ahigkeiten von 
persistenten Programmiersprachen. Dazu erfolgt in diesem Abschnitt zun"achst 
eine Charakterisierung von Reflektion, bevor dieser Ansatz vorgestellt wird.

\subsubsection{Charakterisierung von Reflektion}
Programme, die die F"ahigkeit besitzen, sich selbst zu inspizieren und zu
ver"andern, werden  als reflektiv bezeichnet \cite{Kirb92b}. Dabei wird
unterschieden zwischen verhaltensbasierter, d.h. die Ver"anderung erfolgt durch
eine Beeinflussung des Interpretationsvorganges, und linguistischer Reflektion,
d.h. ein laufendes Programm generiert neue Programmfragmente, indem Programme
als Daten behandelt werden, und integriert diese in seine Ausf"uhrung, indem
Daten als Programme behandelt werden \cite{SSS*92}. Linguistische Reflektion
wiederum kann zur "Ubersetzungszeit oder zur Laufzeit initiiert werden
(s. Abb. \ref{Reflektionsarten}).

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{reflektion.epsf}
\end{center}
\caption{Arten von Reflektion}
\label{Reflektionsarten}
\end{figure}

Bei "Ubersetzungszeitreflektion definiert der Programmierer
Generatorfunktionen, die die Repr"asentationen von Programmfragmenten
generieren, als Teil des "Ubersetzungsvorganges ausgef"uhrt werden und das
gerade "ubersetzte Programm erg"anzen. Beispielsweise werden in TRPL
\cite{Shea91} Makros angeboten, die zur "Ubersetzungszeit evaluiert werden und
die es einem "ubersetzten Programm erlauben, sich an den Kontext anzupassen, in
dem die Makros "ubersetzt werden.

Bei Laufzeitreflektion werden neue Programmteile mit existierenden Programmen
einer Umgebung erzeugt und gebunden, indem eine Funktion aufgerufen wird, die
eine Zeichenkette als Eingabe erwartet, ausf"uhrbaren Programmkode erzeugt und
in das ausgef"uhrte Programm einbindet. Solch eine Funktion kann ein dynamisch
aufrufbarer {\em Compiler} sein wie in {\sf Napier88} oder wie in {\sf O$_2$}
eine Systemfunktion, die einen Interpreter aufruft.

Im Gegensatz zu untypisierten Sprachen wie {\sf Lisp}  \cite{MAE*62}, in denen 
linguistische Reflektion eher als gef"ahrlich einzustufen ist, kann sie in 
typisierten Sprachen typsicher implementiert werden. Das hat zwei Vorteile 
\cite{SMKC93}:

\begin{itemize}
\item Mehr Informationen in Form von Typen werden bereitgestellt.
\item Die Typsicherheit aller neu generierten Programmfragmente wird vor ihrer
Ausf"uhrung "uberpr"uft.
\end{itemize}

\noindent Typsichere linguistische Reflektion stellt einen uniformen
Mechanismus zum Entwurf und zur Weiterentwicklung von Programmen bereit, der
die M"oglichkeiten nichtreflektiver Datenbankprogrammiersprachen "ubertrifft
\cite{SMKC93}. Sie ist besonders einsetzbar f"ur

\begin{itemize}
\item hochgenerische Anwendungen \cite{SFSS90,Shea91},
\item die Anpassung an System"anderungen, die beispielweise bei der 
generischen Daten-- und Funktionsvisualisierung anzutreffen sind 
\cite{DeBr88,DCK90},
\item die Implementierung von Datenmodellen \cite{Coop90,CoQi92},
\item die Optimierung von Implementierungen \cite{CADA87,FeSt91} und
\item die Validierung von Spezifikationen \cite{FSS92,SSF92}.
\end{itemize}
 

\subsubsection{Reflektiver Ansatz}
Der Einsatz typsicherer linguistischer Reflektion innerhalb des 
Dienstes zur generischen Da\-ten-- und Funktionsvisualisierung dient dazu, 
diesen zur Laufzeit um Funktionen zu erweitern, die die Visualisierung f"ur 
Daten eines bestimmten Typs realisieren. Dazu wird anhand der Analyse der 
Typstruktur der zu visualisierenden Daten Programmkode f"ur diese Funktionen 
generiert, "ubersetzt und im persistenten Speicher gebunden. 

Dieser Ansatz hat den Vorteil, da"s er unabh"angig von der Repr"asentation von 
Werten im Objektspeicher ist. Das bedeutet einerseits, da"s der Entwickler 
eines generischen Dienstes zur Daten-- und Funktionsvisualisierung die
Repr"asentation nicht kennen mu"s. Andererseits mu"s die Implementierung dieses
Dienstes nicht ver"andert werden, sollte sich diese Repr"asentation "andern.
Ein Nachteil diese Ansatzes besteht darin, da"s bei allen Daten zuerst eine
entsprechende Visualisierungsfunktion generiert werden mu"s, bevor die
eigentliche Visualisierung erfolgt. In persistenten Programmierumgebungen
l"a"st sich dieser Nachteil vermindern, indem jede generierte
Visualisierungsfunktion zusammen mit dem Typ, f"ur den sie g"ultig ist, in
einer Tabelle gespeichert wird. So mu"s eine neue Visualisierungsfunktion nur
dann generiert werden, wenn f"ur einen Typ noch kein Eintrag in dieser Tabelle
existiert.

Solch ein reflektiver Ansatz ist in {\sf Napier88} realisiert worden
\cite{KiDe90}. Dabei hat sich jedoch herausgestellt, da"s die Visualisierung
vor allen Dingen bei {\em Environments} zu langsam ist. Deshalb erfolgt die 
Visualisierung in {\sf Napier88} mit Hilfe des in Abschnitt 
\ref{Objektformate} vorgestellten Ansatzes, zumal ein weiterer 
Geschwindigkeitsverlust bei solchen Werten auftritt, f"ur die noch keine 
Visualisierungsfunktion existiert.


\section{Ansatz zur Datenvisualisierung im Tycoon System}
\label{Datenvisualisierungsansatz}
Ziel der Daten-- und Funktionsvisualisierung in {\sf Tycoon} ist es, sowohl 
den Programmierer als auch den Anwender beim Inspizieren des Objektspeichers zu
unterst"utzen. Ausgehend von der Diskussion in den vorigen Abschnitten soll der
Dienst zur generischen Daten-- und Funktionsvisualisierung deshalb folgende
Anforderungen erf"ullen:

\begin{description}
\item[Wert-- und Typvisualisierung:] F"ur das Verst"andnis der Darstellung der 
Werte ist es f"ur den Anwendungsprogrammierer hilfreich, da"s die 
Visualisierung nicht nur Werte des Objektspeichers, sondern auch deren Typen 
umfa"st. Da die Visualisierung generisch erfolgen soll, orientiert sich die
Repr"asentation an den {\sf TL} Programmkonstruktoren.
\item[Generische Visualisierung mit Hilfe dynamischer Typen:] Die 
Visualisierung soll f"ur beliebige Werte und Typen generisch und unabh"angig
vom Programmierer erfolgen, so da"s die Verwendung dynamischer Typinformationen
unverzichtbar ist. Um eine angemessene Geschwindigkeit zu erzielen, erfolgt die
Visualisierung nicht reflektiv. Andererseits soll von den Objektformaten
abstrahiert werden, so da"s die Implementierung unabh"angig von einer
bestimmten Implementierung der Objektspeicherformate ist.
\item[Unterst"utzung von Manipulation und Datenaustausch:] {\sf TL} soll 
zwar nicht zu einer visuellen Programmiersprache erweitert werden, aber es 
soll die Manipulation von Werten durch direkte Manipulation der 
Bildschirmrepr"asentation sowie durch Datenaustausch zwischen den 
Bildschirmobjekten unterst"utzt werden.
\item[Visualisierungsunterst"utzung:] Die Visualisierung erfolgt mit Hilfe
einer externen, sys\-tem\-"uber\-greif\-en\-den Klassenbibliothek, um den
Aufwand der Entwicklung einer eigenen Klassenbibliothek zu vermeiden und um die
Portierbarkeit der Daten-- und Funktionsvisualisierung zu erh"ohen. Dabei soll 
sichergestellt sein, da"s auch die externen Bildschirmobjekte persistent sind.
\item[Erhaltung der Objektidentit"at:] Jedes Objekt soll nur einmal auf dem 
Bildschirm dargestellt werden, so da"s Komponenten strukturierter Werte mit 
Ausnahme von konstanten Werten der Basistypen in eigenen Fenstern visualisiert 
werden. Referenzen zwischen den Objekten werden aus Gr"unden der 
"Ubersichtlichkeit nicht dargestellt.
\item[Fokus:] Eine rein objektfokussierte Sicht wie in {\sf Self} wird nicht 
realisiert, da {\sf TL} keine visuelle Programmiersprache sein soll. So wird
auf die dreidimensionale Visualisierung und auf die Animation verzichtet. Auch
wird durch die generierte Bildschirmrepr"asentation nur eine durch die
Funktionalit"at des Dienstes bestimmte Sicht auf die Daten bereitgestellt.
Allerdings werden alle Operationen auf einem Bildschirmobjekt durch Kn"opfe und
Men"us direkt "uber die Bildschirmrepr"asentation angeboten.
\item[Realisierung als generische Bibliothek:] Um die Datenvisualisierung f"ur 
verschiedene Zwecke wie z.B. zur Fehlersuche oder zur Darstellung der
Ergebnisse einer Berechnung einsetzen zu k"onnen, wird sie als generische
Bibliothek realisiert.
\end{description}
