\chapter{Das Tycoon System}
\label{Tycoon}
Die integrierte persistente Programmierumgebung {\sf Tycoon}, die zur
Implementierung der Da\-ten-- und Funktionsvisualisierung verwendet wird, soll in
diesem Kapitel "uberblicksartig vorgestellt werden. Dazu erfolgt im ersten
Abschnitt eine Einf"uhrung in die Systemarchitektur, in die die in dieser
Arbeit entwickelten dynamischen Typen und der generische Dienst zur Daten-- und
Funktionsvisualisierung sowie die verwendete externe Klassenbibliothek {\sf
StarView} eingeordnet werden. Im zweiten Abschnitt werden diejenigen Aspekte
des semantischen Modells von {\sf TL} vorgestellt und diskutiert, die eine
wichtige Rolle f"ur die Daten-- und Funktionsvisualisierung spielen.

Nicht Gegenstand dieses Kapitels ist dagegen eine Einf"uhrung in die Syntax
der Programmiersprache {\sf TL}. Zum Verst"andnis der in dieser Arbeit
verwendeten Programmbeispiele sei verwiesen auf \cite{MMS94}, einer 
Einf"uhrung in {\sf TL}, und \cite{MMM93}, einem "Uberblick "uber die 
praktische Benutzung der interaktiven Systemumgebung und der Bibliotheken.


\section{Architektur des Tycoon Systems}
Die Architektur des {\sf Tycoon} Systems zeichnet sich durch eine hohe
Skalierbarkeit aus, die es erlaubt, in einem einzigen sprachlichen und
architektonischen Rahmen Systemimplementierungen zu realisieren, die von einer
{\em standalone} Implementierung im Hauptspeicher auf einem Personal Computer
bis zu einer netzwerkf"ahigen, mehrbenutzerf"ahigen, optimierenden und
persistenten Implementierung reicht. Dabei ist es m"oglich, {\sf
Tycoon} Anwendungen, die nur eine limitierte Systemfunktionalit"at ben"otigen,
auf einer effizienten und schlanken Systemversion arbeiten zu lassen, die aber
w"ahrend der Lebenszeit solch einer Anwendung an wachsende operationale
Anforderungen angepa"st werden kann \cite{MSS95}.

\begin{figure}[tp]
\begin{center} \leavevmode
%\epsfpic{TycoonEnvironment.epsf}{\epsfsize=0.9\textwidth}
\epsfxsize=0.9\textwidth
\epsfysize=0.4\textheight
\epsfbox{szenario.epsf}
\end{center}
\caption{Interoperabilit"at im Tycoon System}
\label{szenario}
\end{figure}

Um die Interoperatibilit"at zwischen verschiedenen internen und externen
Diens\-ten zu er\-m"og\-lich\-en, leistet das {\sf Tycoon} System folgende
Beitr"age (s. auch Abb. \ref{szenario}\footnote{entnommen aus: \cite{MSS95}}):
\begin{itemize}
\item Bestehende und neu entwickelte generische Dienste wie z.B. grafische
Benutzeroberfl"achen werden in uniformer Weise als polymorphe {\sf
Tycoon} Bibliotheken integriert, die einen typsicheren Zugriff auf externe
Daten und Kode sicherstellen. Innerhalb von {\sf TL} existieren uniforme
Namens--, Typ--, Bindungs-- und Lebensdauerregeln z.B. f"ur Bildschirm--,
Daten-- und Programmobjekte (S,D,P in Abb. \ref{szenario}).
\item Integrierte Dienste werden nicht von in {\sf Tycoon} selbst
implementierten Diensten unterschieden, so da"s Typsicherheit und
Persistenzabstraktion auch f"ur externe Dienste innerhalb des {\sf
Tycoon} Systems systematisch erlangt werden k"onnen.
\item Das {\sf Tycoon} System kann selbst als Subsystem in gr"o"sere Systeme
integriert werden. So kann beispielsweise {\sf Tycoon} Anwendungskode von
Hauptprogrammen aufgerufen werden, die in externen Sprachen wie C geschrieben
sind, wie durch die Pfeile am oberen Rand von Abb. \ref{szenario} angedeutet.
\end{itemize}

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{arch-1.epsf}
\end{center}
\caption{Urspr"ungliche Tycoon Architektur}
\label{Originalarchitektur}
\end{figure}

\noindent In Verbindung mit Abbildung \ref{Originalarchitektur} erfolgt die
Vorstellung der nichtreflektiven Architektur des {\sf Tycoon} Systems anhand
der abstrakten Schnittstellenspezifikationen, die strikt die
Spei\-cher\-ungs--, Manipulations--, Modellierungs-- und
Repr"asentationsaufgaben voneinander trennt:

\begin{description}
\item[TL Schnittstelle:] Die Programmiersprache {\sf TL} ist algorithmisch
vollst"andig, strikt typisiert, imperativ und behandelt Funktionen und Typen
als Objekte ``erster'' Klasse. F"ur alle Typkonstruktoren werden strukturell
definierte Subtypisierungsregeln definiert. Da {\sf TL} einen
sprachunabh"angigen Rahmen f"ur die "Ubersetzung, Generierung und 
Bindung von Programmen liefert, dient sie nicht nur der Datenmodellierung und
Anwendungsentwicklung, sondern implementiert sich selbst als Systemsprache
"uber Bibliotheken und Sprachprozessoren. Sie ist weitgehend
datenmodellneutral, um funktionale, relationale und objektorientierte
Modellierungsans"atze zu unterst"utzen. Formal gesehen ist {\sf TL} ein
typisierter Lambda Kalk"ul zweiter Ordnung, der um Zuweisungen,
Subtypisierungsregeln sowie im Rahmen dieser Arbeit um dynamische Typen
erweitert ist \cite{CMMS91}.
\item[TML Schnittstelle:] Die Zwischenrepr"asentation {\sf TML}\footnote{TML:
Tycoon Machine Language} wird f"ur quell\-spra\-chen-- und
zielmaschinenunabh"angige statische (zur "Ubersetzungszeit) und dynamische (zur
Laufzeit) Optimierungen genutzt \cite{GaMa95}. {\sf TML} basiert auf einem
untypisierten Lambda Kalk"ul in {\em Continuation Passing Style} \cite{Appe92}
und kann f"ur die Implementierung verschiedener Sprachen, wie z.B. {\sf TL} und
{\sf TooL} \cite{GaMa96} genutzt werden.
\item[TVM Schnittstelle:] {\sf TVM}\footnote{TVM: Tycoon Virtual Machine} 
ist eine Aufrufschnittstelle, die einen portablen Befehlssatz f"ur Byte\-kode
definiert, der auf einem funktionalen Ausf"uhrungsmodell h"oherer Ordnung
basiert.  Dar"uber hinaus bietet {\sf TVM} einen generischen Mechanismus zur
Bindung an "ubersetzte Funktionsimplementierungen in {\em externen}
Programmiersprachen (z.B. C oder C++), wodurch u.a. externe Dienste wie {\sf
StarView} in {\sf Tycoon} integriert werden k"onnen. Skalierbarkeit wird in
dieser Schnittstelle erreicht, indem der {\sf TVM} Byte\-kode auf einer
virtuellen Maschine interpretiert oder in Zielmaschinenkode "ubersetzt wird,
ein oder mehrere {\em Threads} gestartet werden k"onnen, sowie persistente {\em
Threads} als Werte erster Klasse oder nur eine fl"uchtige Ausf"uhrungsumgebung
unterst"utzt wird.
\item[TSP Schnittstelle:] {\sf TSP}\footnote{TSP: Tycoon Store Protocol}
definiert eine datenmodellunabh"angige Schnittstelle, die die Manipulation und
Visualisierung von Daten von der zuverl"assigen Speicherung von Massendaten
trennt. Dadurch kann einerseits vollst"andig von den Prozessen der
Zu\-griffs\-op\-ti\-mier\-ung, Speicherr"uckgewinnung, Persistenz,
Nebenl"aufigkeit, Fehlererholung und Verteilung innerhalb des physischen
Speichers abstrahiert werden. Andererseits f"uhrt das zu einer erheblichen
Reduktion der Komplexit"at des Objektspeicherprotokolls und leistet einen
wichtigen Beitrag zur Portabilit"at und Skalierbarkeit des {\sf Tycoon}
Systems \cite{MMS95c}.
\end{description}

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{arch-new.epsf}
\end{center}
\caption{Erweiterte Tycoon Architektur mit dynamischen Typen}
\label{Neuarchitektur}
\end{figure}

\noindent Alle oberhalb von {\sf TVM} liegenden Schnittstellen sind in 
{\sf TL} selbst implementiert worden, so da"s der {\em bootstrap} des Systems 
auf unterschiedlichen Hard-- und Softwarearchitekturen erleichtert wird. 
Durch die Erweiterung von {\sf Tycoon} um dynamische Typen ist die Einf"uhrung
einer weiteren Schnittstelle m"oglich, die einerseits die Anwendungsebene von
den Aufgaben der Repr"asentation trennt. Andererseits k"onnen Teile wie
z.B. die Modulverwaltung, die vorher unterhalb der {\sf TL} Schnittstelle
angesiedelt und teilweise typunsicher innerhalb des {\sf TL} Compilers
implementiert waren, nach oben verlagert werden (s. Abb. \ref{Neuarchitektur}),
und neue Komponenten wie z.B. eine reflektive Schnittstelle zum "Ubersetzer
\cite{Geis95} oder eine Schnittstelle zur generischen Datenvisualisierung
eingef"uhrt werden.

\section{Das semantische Modell von TL}
Programmierumgebungen f"ur datenintensive Anwendungen, die durch 
Programmiersprachen der dritten Generation (COBOL, FORTRAN, C, Pascal) 
implementiert werden, haben das Problem, da"s der Datenbankprogrammierer f"ur 
die Objekte von verschiedenen Servern (z.B. Datenbank--, Programm-- und 
Bildschirmobjekte) verschiedene Benennungs--, Lebensdauer-- und 
Bindungskonzepte erlernen und Bindungen zwischen Objekten auf verschiedenen 
Medien durch spezielle Namenskonventionen realisieren mu"s. Deshalb weicht 
das {\sf Tycoon} Modell von diesen Umgebungen ab, indem es den gesamten Proze"s
der Integration, Erweiterung, Spezialisierung, Nutzung oder auch Neudefinition
von generischen Diensten in einem unifizierenden sprachlichen Rahmen abwickelt
\cite{Matt93}.


\subsection{Bindungen und Signaturen}
Das semantische Modell von {Tycoon}, deren zentrale Entit"aten Werte, Typen,
Bindungen und  Signaturen sind, basiert auf Typtheorien h"oherer Ordnung
\cite{BuLa84,Card89}. Aufgrund der Bedeutung von Namens--, Sichtbarkeits-- und
Bindungskonzepten in der Programmierung umfangreicher Applikationen, bilden
nicht isoliert Typen und Werte, sondern Signaturen und Bindungen die
wesentlichen semantischen Konstruktionsbl"ocke \cite{MaSc92}.

Bindungen sind geordnete Assoziationen zwischen benutzerdefinierten Namen und 
semantischen Objekten, die die (wiederholte) Verwendung dieses Namens zur 
Bezeichnung des gebundenen Objektes in Ausdr"ucken erlaubt. In {\sf TL} 
k"onnen Namen an konstante Werte, variable Werte und Typen, die (partielle) 
Spezifikationen von Werten darstellen, gebunden werden, so da"s die 
Referenzierung eines Wertes oder eines Typs durch verschiedene Namen und die 
Einf"uhrung rekursiver Strukturen auf der Wert-- und Typebene m"oglich sind.
Dabei identifizieren Namen in variablen Wertbindungen anonyme Zellen, die 
wiederum Werte enthalten. Bindungen sind unver"anderlich, nur der Inhalt der 
Zelle einer variablen Wertbindung kann aktualisiert werden \cite{MaSc93}.

Verschiedene statische und dynamische Bindungsmechanismen erlauben eine
Modellierung verschiedenartiger Sichtbarkeitsregeln und Benennungsschemata
unabh"angig von der Struktur der benannten Objekte. Dadurch, da"s Typausdr"ucke
und Typvariablen als gleichberechtigte sprachliche Objekte behandelt werden,
erzielt {\sf TL} eine wesentlich gr"o"sere M"achtigkeit und Flexibilit"at als
andere Sprachen.

Bindungen sind in die Syntax von Werten eingebettet, so da"s diese benannt, 
als Parameter "ubergeben usw. werden k"onnen. Signaturen dagegen, die als 
(partielle) Spezifikationen einer Folge von statischen und dynamischen 
Bindungen agieren, erscheinen in der Syntax von Typen. Es werden konstante
Wertsignaturen ({\sl x :T\/}), variable Wertsignaturen ({\bf var} {\sl x :T\/})
und Typsignaturen ({\sl T\/}'$<$:{\sl T\/}) unterschieden, die den Namen eines 
konstanten bzw. variablen Wertes mit einem Typ bzw. einen Typ mit einem 
Supertyp assoziieren. Signaturen erlauben die "Uberpr"ufung der Korrektheit 
von Wert-- und Typausdr"ucken in Abh"angigkeit von Namen, ohne Zugriff auf 
die durch den Namen definierte Bindung zu haben. Signaturen spielen damit 
eine zentrale Rolle in typsicheren Anwendungsumgebungen wie {\sf Tycoon}, die 
eine separate "Ubersetzung unterst"utzen. Die G"ultigkeit von Signaturen ist
auf die "Ubersetzungszeit, die von Bindungen dagegen auf die Laufzeit
beschr"ankt.


\subsection{Benennung und Typisierung vordefinierter Werte und Funktionen}
Im Gegensatz zu Programmiersprachen, die dem Programmierer eine Vielzahl
vordefinierter Datentypen wie ganze Zahlen oder Zeichenketten bereitstellen,
welche damit eine Sonderbehandlung gegen"uber den benutzerdefinierten Typen 
erfahren, versucht {\sf TL} eine Homogenit"at zwischen diesen Typen zu
erreichen. Dies f"uhrt zu einer Begrenzung der Sprachkomplexit"at und einer
Erh"ohung des Verst"andnisses von {\sf TL} Programmen durch die Vermeidung
impliziter Konvertierungsoperationen und un"ubersichtlicher
Bindungskonventionen \cite{Matt93}.

Deshalb exisistieren in {\sf TL} in der Standardbibliothek Module, "uber die
die Namen, Konstanten und die Funktionen f"ur die Basistypen explizit
bereitgestellt werden. Sie gehorchen dabei den gleichen Syntax--, Typ--, und
Evaluationsregeln wie benutzerdefinierte Typen, Werte und Funktionen. Durch
einen generischen Mechanismus werden jedoch zus"atzlich viele der Funktionen
auf den Basistypen an symbolische Bezeichner gebunden, um notationelle
Nachteile zu vermeiden:

\begin{xple}
\kw{let} \id{+ = int.add}
\kw{let} $<>$ = \id{string.concat}
\kw{let} == = \id{poly.equal}
...
\end{xple}

\noindent Im {\em Frontend} des {\sf TL} Compilers sind diese Basistypen ``fest
verdrahtet''. Ebenso ist die interne Wert\-re\-pr"a\-sen\-ta\-tion der
Basistypen im {\em Backend} des {\sf TL} Compilers statisch verankert und durch
Vorgaben des Objektspeicherprotokolls bestimmt.

\subsection{Typhierarchien}
\label{Typhierarchien}
Typaussagen der Form {\sl x :T\/} stellen partielle Spezifikationen dar, da 
der durch {\sl x\/} referenzierte Wert mindestens die durch den Typ {\sl T\/} 
gegebene Spezifikation, eventuell aber auch eine pr"azisere, erf"ullt. Die 
partielle Ordnung auf Typen und Typoperatoren wird dabei durch die reflektive 
und transitive Subtypbeziehung $<$: beschrieben, wobei das 
Subsumptionsprinzip ($a :A \wedge A <:B \Rightarrow a:B$) gilt. Von Bedeutung 
f"ur die Definition der Regeln f"ur Subtypbeziehungen in  {\sf TL} ist der 
Begriff der {\em Subsignatur}. Signaturen {\sl S\/} hei"sen demnach 
{\em Subsignaturen} von Signaturen {\sl S'\/}, wenn die geordneten Folgen 
{\sl S\/} und {\sl S'\/} die gleiche L"ange besitzen, und die Typen $A_i$ der 
Signaturkomponenten in {\sl S\/} Subtypen der Typen $A'_i$ an gleicher 
Position in {\sl S'\/} sind. Sind dar"uber hinaus die Variablennamen $x_i$ und 
$x'_i$ beide nicht anonym, so mu"s $x_i = x'_i$ gelten.

\begin{figure}[tp]
\begin{center} \leavevmode
\epsfbox{typhierarchien.epsf}
\end{center}
\caption{Verschiedene Typhierarchien in {\sf TL}}
\label{Typhierarchiebild}
\end{figure}

Da es sich bei {\sf TL} um eine Programmiersprache h"oherer Ordnung handelt, 
gibt es eine Vielzahl von Typhierarchien, die durch die Subtypisierungsregeln 
f"ur die verschiedenen Typ\-kon\-strukt\-oren bestimmt sind (s. Abb.
\ref{Typhierarchiebild}\footnote{entnommen aus \cite{Geis95}}). Von allen  
nichtparametrisierten Typen ist der Typ {\bf Ok} der Supertyp und der Typ {\bf
Nok}, der der Ergebnistyp aller Ausdr"ucke ist, die ein Ausnahmepaket
ausl"osen, der Subtyp. W"ahrend zwischen den Basistypen keine
Subtypbeziehungen existieren, ist dies zwischen benutzerdefinierten Typen
m"oglich. Weitere Typhierarchien entstehen abh"angig von der Anzahl ihrer
Parameter durch Typoperatoren erster Stufe, bei denen die Subtypisierung
gem"a"s der Kontravarianzregel erfolgt. Typoperatoren h"oherer Ordnung bilden
wiederum eigene Typhierarchien. In {\sf TL} ist es jedoch nicht m"oglich, einen
Zusammenhang zwischen den verschiedenen Typhierarchien mit Hilfe einer {\em
Kind} Spezifikation \cite{Card89} herzustellen.


\subsection{Struktur-- und Namens"aquivalenz}
\label{Namensregel}
In der Regel gilt f"ur die Subtypisierung in {\sl TL} Struktur"aquivalenz. So
ist beispielsweise die Subtypisierungsregel f"ur Tupeltypen ohne Varianten
folgenderma"sen definiert:

\begin{quote}
Seien A und B Tupeltypen ohne Varianten, dann gilt {\sl A\/} $<$:{\sl B\/}, 
wenn {\sl A\/} ein Pr"afix von Signaturen besitzt, die Subsignaturen von 
{\sl B\/} sind.
\end{quote}

\noindent F"ur die anderen {\sf TL} Typkonstruktoren sei auf den Sprachreport 
\cite{MaSc92} verwiesen. Eine Ausnahme bilden dagegen die abstrakten 
Datentypen, deren Kompatibilit"atsregel auf der Namens"aquivalenz beruht. 

Um zuf"allige, d.h. nicht gew"unschte Kompatibilit"aten zwischen 
strukturell "aquivalenten Typen zu vermeiden, lassen sich in {\sf TL} {\em
einschr"ankende} Wert-- und Typbindungen mit der Namens"aquivalenzregel f"ur
abstrakte Typvariablen zum Konzept der {\em semiabstrakten} Typvariablen
kombinieren. Demnach erf"ullt eine abstrakte Typvariable {\sl x.T\/ $<$:A\/}
sowohl die Spezifikation {\sl x.T\/} (Namenskompatibilit"at) als auch die
Spezifikation {\sl A\/} (Strukturkompatibilit"at). Eine Signatur {\sl a
:x.T\/} wird nur durch Werte erf"ullt, die durch eine Injektionsfunktion {\sl
x.new\/} erzeugt wurden. Die Vorteile dieser Kombination aus Struktur-- und
Namenskompatibilit"at sollen anhand des folgenden Beispiels erl"autert werden:

\begin{xple}
\kw{Let} \id{Car} = \kw{Tuple} \id{name :String  age :Int} \kw{end}
\kw{let} \id{car} :\kw{Tuple} \id{T} $<$:\id{Car  new(:Car) :T} \kw{end} = 
  \kw{tuple Let} \id{T = Car}  \kw{let} \id{new(x :Car) = x} \kw{end}

\kw{Let} \id{Person} = \kw{Tuple} \id{name :String  age :Int} \kw{end}
\kw{let} \id{person} :\kw{Tuple} \id{T} $<$:\id{Person  new(:Person) :T} \kw{end} = 
  \kw{tuple Let} \id{T = Person}  \kw{let} \id{new(x :Person) = x} \kw{end}

\kw{let} \id{audi = car.new(}\kw{tuple} \id{``Audi'' 3} \kw{end})
\kw{let} \id{mueller = person.new(}\kw{tuple} \id{``Mueller'' 25} \kw{end}) 
\kw{let} \id{meier = person.new(}\kw{tuple} \id{``Meier'' 43} \kw{end})

\kw{let} \id{getAge(item :}\kw{Tuple} \id{name :String  age :Int} \kw{end}) = \id{item.age}
\kw{let} \id{married(p1, p2 :person.T) :Bool = string.equal(p1.name p2.name)}

\id{getAge(meier)} $\Rightarrow$ 43
\id{married(meier mueller)} $\Rightarrow$ false
\id{married(meier audi)}
$\Rightarrow$ Argument type mismatch: `person.T' expected, `car.T' found
   [while checking function argument `p2']
\end{xple}

\noindent Die Typvariablen {\sl person.T\/} und {\sl car.T\/} hei"sen
semiabstrakt, da sie nicht nur die triviale Spezifikation ($<$:{\bf Ok}),
sondern auch noch eine speziellere ({\sl Person\/} bzw. {\sl Car\/})
erf"ullen. Der erste Aufruf der Funktion {\sl married\/} ist erfolgreich, da
die Werte {\sl meier\/} und {\sl mueller\/} mit der gleichen Injektionsfunktion
{\sl person.new\/} erzeugt worden sind und somit aufgrund der
Namens"aquivalenzregel f"ur abstrakte Typvariablen die Bedingung $<$:{\sl
person.T\/} erf"ullen. Bei dem zweiten Aufruf erf"ullt der Wert {\sl audi\/}
diese Bedingung jedoch nicht, obgleich die Typstruktur "aquivalent zur Struktur
von Werten des Typs {\sl Person\/} ist.

Auf semiabstrakten Werten sind jedoch alle diejenigen Operationen 
zul"assig, die auf Werten des als obere Schranke angegebenen Typs definiert
sind. Da {\sl Person\/} strukturell "aquivalent zu dem Typ des Parameters {\sl
item\/} der Funktion {\sl getAge\/} ist, ist der Aufruf dieser Funktion mit dem
Wert {\sl meier\/} zul"assig. Ebenso w"are der Aufruf der Funktion {\sl
married\/} f"ur den Wert {\sl audi\/} zul"assig, wenn bei den Bezeichnern {\sl
person\/} und {\sl car\/} nicht explizit der einschr"ankende Typ angegeben
worden w"are, da in diesem Fall beide den vom Compiler inferierten Typ h"atten
und die beiden Typvariablen {\sl person.T\/} und {\sl car.T\/} deshalb
strukturell "aquivalent w"aren.

