\chapter{Zusammenfassung und Ausblick}
\label{fazit}

Die Motivation f"ur die Themenstellung dieser Arbeit bestand darin, mit Hilfe
der in Kapitel \ref{gdl} und \ref{reflection} beschriebenen Dienste 
die Grundlagen f"ur eine offene, d.h. zur reflektiven Programmierung 
geeigneten Compilerarchitektur zu schaffen, um darauf aufbauend die
Implementierung einer grafischen reflektiven Programmierumgebung zu 
erm"oglichen. Ziele einer solchen Umgebung sind:
\begin{enumerate}
\item Erh"ohung der Produktivit"at des Programmierers: Diese h"angt
haupts"achlich von der Generik des Systems ab, d.h. eine Erweiterung
der generischen Dienste bedeutet auch eine Steigerung der Produktivit"at.
\item Erleichterung des Verst"andnisses der persistenten Umgebung:  
Dies kann durch den Einsatz grafischer Werkzeuge zur Visualisierung 
und Konstruktion von Programmen und Daten erreicht werden, da visuelle
Aspekte eine gro"se Rolle beim menschlichen Verstehen spielen.
\end{enumerate}


	\section{Dienste zur Steigerung der Generik}

Konkret wird die Generik des 
Tycoon-Systems durch folgende Ma"snahmen gesteigertn:
\begin{itemize}
\item Entwicklung eines C++-Gateway-Generators,
\item Einf"uhrung von Laufzeit-Typ\-repr"asentationen und automorphen Werten
in die Sprache \TL,
\item Repr"asentation des \TL-Compilers als Bibliotheksdienst zur
laufzeitreflektiven Programmierung.
\end{itemize}

Durch den {\bf C++-Gateway-Generator} wird die generische Integration einer
weiteren Klasse externer Diensterbringer in das Tycoon-System
erm"oglicht. Aufgrund des polymorphen Typsystems von \TL\ konnte eine
vollst"andige Abbildung der f"ur die Schnittstellenbeschreibung
wesentlichen Konzepte beider Sprachen aufeinander erreicht werden, trotz
der grunds"atzlichen Differenzen in den direkt unterst"utzten 
Programmierparadigmen (funktional und imperativ in \TL\ vs. objektorientiert 
und imperativ in C++).  Durch den Generatoransatz in Verbindung mit einer
Schnittstellenbeschreibungssprache (GDL) wird dem Programmierer ein gro"ser
Anteil gleichf"ormiger, repetitiver und damit fehlertr"achtiger 
Codierungsarbeit abgenommen. Der Zusatzaufwand an Speicher und CPU-Zeit zur 
Nutzung der durch
generierte {\em Gateways} angesprochenen externen Dienste erscheint akzeptabel,
gemessen an den Vorteilen, die sich durch ihre Benutzung innerhalb einer 
persistenten, polymorphen, mit vielf"altigen generischen Diensten 
ausger"usteten Umgebung, wie Tycoon sie bietet, ergeben. Weiterhin 
wird der {\em Gateway}-Generator zur Einbindung einer portablen 
GUI-Klassenbibliothek eingesetzt, wodurch die Grundlage zur Realisierung von 
grafischen Visualisierungs- und Programmkonstruktionswerkzeugen gelegt wird.

Durch die Einf"uhrung von {\bf Laufzeit-Typrepr"asentationen und automorphen 
Werten} in \TL\ wird die Entwicklung einer weiteren Klasse polymorpher 
Algorithmen erm"oglicht. Diese umfa"st Algorithmen, die {\em typgesteuerte} 
Berechnungen durchf"uhren. Anwendungen f"ur diese Art des 
Ad-hoc-Polymorphismus ergeben sich immer dort, wo Werte in unterschiedlichen 
Kontexten typsicher verwendet werden sollen, d.h. Typen dieser Werte statisch 
nicht bekannt sind, z.B. in unabh"angigen Objektspeichern oder in unabh"angigen
Evaluationsumgebungen wie bei der laufzeitreflektiven Programmierung. 
Diese Anwendungen sind deutlich gegen"uber solchen abzugrenzen, bei denen
"uber Typen abstrahiert werden kann, was durch parametrischen Polymorphismus
und Subtyppolymorphismus unterst"utzt wird.

{\bf Laufzeitreflektive Programmierung} wird durch die Bereitstellung des 
Compilers als Bibliotheksdienst erm"oglicht. Dynamische Generierung und 
Ausf"uhrung von Codefragmenten stellt oftmals eine effizientere Alternative 
gegen"uber der Interpretation von Laufzeit-Typ\-information dar, insbesondere 
wenn generierter Code "uber die Laufzeit einer Anwendung hinaus in der 
persistenten 
Umgebung aufbewahrt werden kann. Die Implementation des Standardbeispiels f"ur 
diese Art der generischen Programmierung, der nat"urliche Verbund, wird unter 
Nutzung dynamischer Typ\-information und des aufrufbaren Compilers 
durchgef"uhrt. Weiterhin werden Compilerschnittstellen anderer 
Programmiersprachen auf ihre Eignung zur reflektiven Programmierung hin 
untersucht.


	\section{Add-On-Werkzeuge zur Programmentwicklung}

Um das Verst"andnis des Programmierers f"ur die persistente Umgebung zu
erh"ohen, sind grafische Werkzeuge ein geeignetes Mittel, da hierarchische
und netzwerkartige Strukturen nur schwer textuell darzustellen sind. 
Das in Kapitel \ref{scope-browsing} beschriebene {\bf Werkzeug zur grafischen
Objektspeichervisualisierung und -manipulation} stellt die Environment-Struktur
des Objektspeichers grafisch dar. Es erlaubt dem Benutzer,
\TL-Ausdr"ucke gegen Environments auszuwerten, wobei
die daraus resultierenden Seiteneffekte wie z.B. die Etablierung neuer
Bindungen im Objektspeicher sofort f"ur den Benutzer sichtbar werden.
Weiterhin hat er die M"oglichkeit, durch direkte Manipulation
Restrukturierungen im Objektspeicher vorzunehmen, indem er Bindungen per
Mausaktion zwischen Environments verschiebt. Zur Nutzung reflektiver
M"oglichkeiten kann das System die Bindungen, aus denen es besteht,
dem Benutzer in Environments zur Verf"ugung stellen. Dies betrifft
insbesondere den aufrufbaren Compiler und die Schnittstellen zur Manipulation
von Typ\-repr"asentationen und automorphen Werten.

Aufbauend auf den reflektiven Diensten und Spracherweiterungen zur dynamischen
Typisierung wird ein Konzept f"ur die {\bf typsichere Implementierung der 
Modulverwaltungskomponente} des Tycoon-Systems auf Anwendungsebene 
entwickelt. Mit Hilfe dieses Konzeptes braucht man zur Implementierung dieser 
Komponente nicht mehr auf compiler-interne 
Datenstrukturen und Funktionalit"at zur"uckgreifen. Typ\-sichere 
Bindung von Modulen wird dabei durch in den "`Objektcode"' integrierte 
dynamische Typ\-tests erreicht, wobei der Code f"ur die Typ\-tests im gebundenen 
Programm nicht mehr existiert.

Unter dem Begriff {\bf Hyperprogrammierung} wird eine Technik vorgestellt,
die darauf abzielt, die persistente Umgebung m"oglichst weitgehend in den
Softwarekonstruktionsproze"s einzubeziehen. Hauptvorteile dieser Technik
sind ihre Eignung zur Visualisierung von Funktionsabschl"ussen, die
Integration der Konzepte "`Quellcode"' und "`ausf"uhrbarer Code"' zu einer
gemeinsamen Sicht sowie die Robustheit von Bindungen zwischen ausf"uhrbarem
Code und Quellcode in einem Objektspeicher, der die referentielle Integrit"at 
aller Bindungen sicherstellt. Tycoon bietet mit Reflektion, Persistenz
und GUI-Funktionalit"at alle Voraussetzungen zur Implementierung eines 
Hyperprogrammiersystems.


	\section{Ausblick und offene Fragen}

In diesem Abschnitt werden abschlie"send die teilweise in den einzelnen
Kapiteln schon angesprochenen offenen Punkte zusammengefa"st und ein
Ausblick auf zuk"unftige Aktivit"aten zur Realisierung einer reflektiven
grafischen Programmierumgebung f"ur Tycoon gegeben.

Probleme bei der {\bf Integration von C++-Diensten} ergeben sich durch die 
unterschiedliche Lebensdauer von Tycoon-Bindungen und C++-Objekten,
die in zweifacher Hinsicht zu einer Invalidierung von Bindungen im
Objektspeicher f"uhren kann:
\begin{enumerate}
\item Bei einem Wiederanlauf des Tycoon-Systems existieren evtl. Bindungen
an nicht mehr existierende C++-Objekte.
\item Durch Aufruf seines Destruktors kann ein C++-Objekt jederzeit zerst"ort 
werden. Die zugeh"orige \TL-Bindung darf dann nicht mehr verwendet werden.
\end{enumerate}
Eine L"osung des ersten Problems ist die explizite Registrierung solcher
Objekte als fl"uchtige Ressourcen mit dem Ziel, diesen durch Neuerzeugung
bei Wiederanlauf des Systems eine Art Pseudo-Persistenz zu verschaffen
\cite{MMS95a}. 
Durch die Einf"uhrung schwacher Referenzen ({\em Weak References} \cite{M3Bibs})
in Tycoon kann der 
explizite Aufruf von Destruktoren vermieden und der automatischen 
Freispeicherverwaltung "uberlassen werden.

Zur Verwirklichung der in Abbildung \ref{tycoon-arch-new} dargestellten
{\bf reflektiven Systemarchitektur} bedarf es noch weiterer konkreter
Integrationsarbeiten: 
\begin{itemize}
\item Die Vereinheitlichung der statischen und dynamischen Typ\-repr"asentation
zur Vermeidung laufzeitintensiver Typ\-konvertierungen (siehe Abschnitt
\ref{typechecker-integration}) sowie die
\item Erweiterung der \TL-Syntax und -Semantik um wertparametrisierte 
Typ\-operatoren (siehe Abschnitt \ref{modulverwaltung}).
\end{itemize}
Bei der Reimplementation der Modulverwaltungskomponente auf Anwendungsebene
ist zu entscheiden, ob "ubersetzte Module und Modulschnittstellen 
weiterhin zus"atzlich im Dateisystem gehalten werden sollen, um die 
arbeitsteilige Anwendungsentwicklung mit mehreren unabh"angigen
Objektspeichern zu unterst"utzen. Dies w"urde wegen der Nichtlinearit"at von
Typ\-repr"asentationen zu einem hohen Speicherplatzverbrauch f"ur 
Typ\-repr"asentationen von Modulschnittstellen im Dateisystem f"uhren, der
proportional zur Anzahl (transitiv) importierter Schnittstellen
w"achst. Um dies zu verhindern, w"are ein Mechanismus erforderlich, der es
erlaubt, geschlossene nichtlineare Typ\-repr"asentationen quasi 
"`aufzubrechen"' (zur separaten Speicherung von Schnittstellen in Dateien) 
und diese auch wieder
zusammenzusetzen (zum Aufbau einer "Ubersetzungsumgebung f"ur Module).
Es ist zu untersuchen, ob das in \cite{MMS95b} beschriebene Verfahren zum 
dynamischen Binden an ubiquit"are Ressourcen f"ur diese Zwecke einsetzbar
ist.

Bei der Nutzung {\bf grafischer M"oglichkeiten} zur Programmvisualisierung und
-kon\-struk\-tion steht zun"achst die Weiterentwicklung der 
Objektspeichervisualisierung im Vordergrund.
Bevor weitere Aktivit"aten zum Forschungsthema Hyperprogrammierung im 
Tycoon-Umfeld unternommen werden, ist eine grunds"atzliche Entscheidung
dar"uber notwendig, welche Bedeutung der persistenten Umgebung f"ur den
Softwareentwicklungsproze"s zugemessen wird und ob der Entwicklungsaufwand 
f"ur spezialisierte Werkzeuge zur Unterst"utzung dieses Programmierstils 
im Verh"altnis zu den dadurch realisierbaren Vorteilen angemessen ist.
Ferner ist diese Methodik auf ihre Eignung zum "`Programmieren im Gro"sen"'
hin zu untersuchen und mit dem Modulkonzept zu vergleichen.

Eine besondere Bedeutung in einer {\bf voll integrierten persistenten Umgebung}
kommt der Objektspeicherimplementation zu, die ein hohes Ma"s an Sicherheit
und Funktionalit"at (insbesondere f"ur den Mehrbenutzerbetrieb)
gew"ahrleisten mu"s, um das Dateisystem des Betriebssystems vollwertig ersetzen 
zu k"onnen. Hauptvorteil einer solchen Umgebung w"are dann, da"s sie
die Funktionalit"at heutiger Datenbanken, Betriebssysteme, Programmiersprachen 
und deren Benutzerschnittstellen unter einheitlichen Bindungs-,
Benennungs- und Typisierungskonzepten subsumieren w"urde. Angesichts der 
zunehmenden Heterogenit"at von Systemen w"are dies ein
entscheidender Beitrag der Informatik zur konzeptionellen Vereinfachung und
Orthogonalisierung der Benutzung von Rechensystemen.

