
\chapter{Zusammenfassung und Ausblick} \label{ZusFass}
Ausgangspunkt f"ur diese Arbeit war der Wunsch nach Neugestaltung 
der Bibliothek f"ur Massendatentypen des Tycoon-Systems. Die Aufgabenstellung
f"uhrte zun"achst zur Untersuchung von Qualit"atsanforderungen f"ur
Softwarebibliotheken. Sodann wurde analysiert, ob die erarbeiteten
Anforderungen mit dem bis dahin im Tycoon-System verfolgten 
und durch die hochsprachliche Schnittstelle TL unterst"utzten modulorientierten
Entwurfsansatz "uberhaupt zu erreichen sind. Als Alternative wurde ein
objektorientierter Ansatz betrachtet. Ergebnis der Analyse war die Entscheidung
f"ur den objektorientierten Ansatz, da dieser in Bezug auf Wiederverwendbarkeit
und 
Vereinheitlichung der Schnittstellen deutliche Vorz"uge besitzt. Die Umsetzung
objektorientierter Konzepte in der Programmiersprache TL f"uhrte aber zu
komplizierteren Softwarearchitekturen, was auch in anderen Projekten zu
beobachten war. Um  
diese Komplexit"at in der Bibliotheksentwicklung zu vermeiden und aus dem
Bed"urfnis nach direkter Unterst"utzung der objektorientierten
Programmierung im Tycoon-System, entstand die experimentelle
Programmiersprache TooL als objektorientierte Variante von TL. Nach Analyse
einiger existierender objektorientierter Beh"alterklassenbibliotheken erfolgte
dann die Neuentwicklung der Bibliothek in dieser Programmiersprache.

Die Arbeit l"a"st sich somit grob in zwei Phasen aufteilen, denen die
enstandenen Ergebnisse zuzuordnen sind:
\begin{enumerate}
\item{Analysephase}
  \begin{enumerate}
  \item{Darstellung der Vorteile des objektorientierten 
gegen"uber einem modulorientierten Entwurfsansatz f"ur die
Bibliotheksentwicklung.}\label{ZObjMod}
  \item{Untersuchung bestehender Bibliotheken und Herausstellung ihrer
Klassifizierungsprobleme.}\label{ZKlassProb}  
  \end{enumerate}
\item{Entwurfs- und Implementierungsphase}
  \begin{enumerate}
  \item{Entwicklung eines eigenschaftsbezogenen
Klassifizierungsschemas f"ur Be\-h"al\-ter\-pro\-to\-koll.}\label{ZKlassSch} 
  \item{Entwicklung und Implementierung der Beh"alterklassenbibliothek f"ur
TooL.}\label{ZImpl} 
  \item{Diskussion von Auswirkungen des neuartigen Typsystems von TooL auf
den Entwurf und die Benutzbarkeit der Beh"alterklassenbibliothek}\label{ZTpAs}
  \item{Skizzierung der Umsetzung von Design-Mustern zur Vereinfachung der
Struktur der Beh"alterklassenbibliothek.}\label{ZDsgnMstr}
  \end{enumerate}
\end{enumerate}

\noindent Die einzelnen Ergebnisse werden im folgenden noch einmal
aufgeschl"usselt. 

Das Ergebnis der Bewertung von modulorientiertem und objektorientiertem
Entwurfsansatz f"ur die Entwicklung der Beh"alterbibliothek war die
Bevorzugung des objektorientierten Ansatzes (\ref{ZObjMod}). Die von Modulen
durchgef"uhrte 
Kapselung der Repr"asentationsdaten und die vollst"andige Spezifizierung des
Protokolls an ihren Schnittstellen unterst"utzt eher eine Schichtenarchitektur,
welche an den internen Schichtgrenzen oft einen Wechsel der Repr"asentation
vollzieht. Die Erweiterbarkeit oder Kombination von Funktionalit"at wird nicht
unterst"utzt. F"ur die Beh"alterbibliothek bedeutet dies, da"s bei Definition
eines neuen Beh"alters nur auf die Funktionalit"at vorhandener Module
zur"uckgegriffen werden kann, wenn gleichzeitig die dort gew"ahlte
Repr"asentation der Daten akzeptabel ist. Ansonsten mu"s auf die Nutzung
verzichtet werden bzw. eine andere Repr"asentationsform implementiert werden.

Mit einem objektorientierten Ansatz hingegen l"a"st sich eine Erg"anzung der
Bibliothek insbesondere beim Einsatz von Mehrfachvererbung, durch Kombination
von vorhandener Funktionalit"at oder Anpassung von 
unvollst"andig implementierter Teilfunktionalit"at aus abstrakten Klassen
realisieren. Weiterhin kann die Struktur des Vererbungsgraphen einen Nutzer der
Bibliothek bei der Auswahl eines Beh"alters unterst"utzen. Die Spezifikation
von Methoden in weit 
oben im Vererbungsgraphen anzutreffenden Klassen kann als
vereinfachte Sicht auf kompliziertere Subklassen genutzt
werden. Dar"uber hinaus wird eine Vereinheitlichung der
Beh"alterschnittstellen erreicht. 

Die Analyse bestehender Beh"alterklassenbibliotheken (\ref{ZKlassProb}) f"uhrte
zu der Feststellung, da"s unsaubere Klassifizierungen bei
den meisten Bibliotheken in den Subklassen korregiert werden m"ussen,
z.B. durch Ausgabe von Laufzeitfehlermeldungen (Smalltalk: Abschnitt
\ref{Smlltlk}) oder indem vorher "offentliche Methoden als privat deklariert
werden (NIHCL: Abschnitt \ref{Nihcl}). Andere Bibliotheken nutzen
Sprachkonzepte zur Umbenennung von Methoden, um die Objektschnittstellen
anzupassen (Eiffel: Abschnitt \ref{Effl}). Beide 
Varianten verhindern eine vereinfachte Sichtweise auf die Beh"alter, da sich
der Nutzer nicht mehr auf das Vorhandensein bzw. die Anwendbarkeit einer 
im Zuge der Klassifizierung eingef"uhrten Methode verlassen kann.
Dem wurde in dieser Arbeit eine Klassenhierarchie gegen"ubergestellt, die ohne
Umbenennung oder 'Entfunktionalisierung' von Methoden auskommt.

Das entwickelte Klassifizierungsschema (\ref{ZKlassSch}) unterst"utzt die
gew"unschte Vereinheitlichung der Schnittstellen und die vereinfachende Sicht
auf komplexe Beh"alterklassen "uber das Protokoll ihrer Vorg"anger durch
eine eigenschaftsbezogene Klassifizierung der Methoden. Es
unterteilt die Beh"altereigenschaften in allgemeine, von vielen Beh"altern
"ubernommene und spezielle, einer bestimmten Beh"alterkategorie zuzuordnende
Eigenschaften. Die Zusammenfassung allgemeiner Eigenschaften zu
Beh"alterkategorien und die anschlie"sende erneute Aufteilung des spezielleren
Beh"alterprotokolls f"uhrt zu einem allen Beh"altern einer Kategorie
zugeordneten Basisprotokoll, wodurch die vereinfachte Sicht auf die Beh"alter
dieser Kategorie unterst"utzt wird. Die eigenschaftsbezogene Aufteilung erlaubt
eine Selektion geeigneter Beh"alter f"ur bestimmte Aufgaben bzw. die Auswahl
und Kombination geeigneter Methodengruppen zur inkrementellen Entwicklung neuer
Beh"alter. 

Die Implementierung der Beh"alterklassenbibliothek (\ref{ZImpl}) umfa"st
$130$ Klassen. Davon sind $48$ Klassen abstrakt. In den Klassen sind ca. $580$
Methodenimplementierungen (davon ca. $170$ in abstrakten Klassen) und ca.$60$
abstrakte Methodenspezifikationen zu finden. Als grobes Ma"s f"ur die
Wiederverwendung von Klassen kann in Anlehnung an \cite[S.142]{Dumke92} die
durchschnittliche Anzahl der Subklassen einer Klasse angesehen werden. Die
Beh"alterklassen werden in ca. $190$ F"allen als direkte Oberklassen
angegeben. Ber"ucksichtigt man auch die indirekte Vererbung, so sind ca. $780$
Zuordnungen zu verzeichnen (Die Klasse {\sf Container} wurde nicht
ber"ucksichtigt). Dies ergibt f"ur die direkte Wiederverwendung einen Faktor
von $1,38$ und f"ur die indirekte Wiederverwendung von $6,0$ pro Klasse.

Es wurden zum Teil komplexe Algorithmen realisiert, wie z.B. ein 
mehrdimensionales W"orterbuch (Dictionary). Die Wiederverwendbarkeit von
Methoden kann durch die Art und 
Weise der Implementierung erh"oht werden. In der Bibliothek wird daher die
Verwendung von Annahmen, die durch Subklassen relativiert werden
k"onnten, vermieden (Abschnitt \ref{AnnFrei}). Au"serdem wird f"ur einige
Methoden durch Verteilung der 
Funktionalit"at "uber die Klassifizierungsstruktur die inkrementelle
Erweiterung der Algorithmen m"oglich (Abschnitt \ref{MethKett}).
-- Die teilweise schwierige Arbeit mit dem Sprachprototyp wurde durch die
schon fr"uhzeitig zur Verf"ugung stehende Typ"uberpr"ufung erleichtert. Die
Fehlersuche konnte so erheblich beschleunigt werden. Ebenso g"unstig wirkte
sich die fr"uhzeitige Realisierung der einfachen {\em Klassenbrowser} auf den
Entwicklungsproze"s aus.

Die Auswirkungen des neuartigen Typsystems von TooL (\ref{ZTpAs}) lassen sich
folgenderma"sen zusammenfassen: Mit der Einf"uhrung der 
"Ahnlichkeitsrelation als erg"anzende Konsistenzbedingung f"ur die Vererbung
steigt die Modellierungskomplexit"at. Der Klassendesigner mu"s sich
entscheiden, in welcher Situation er die jeweilige Relation nutzen will. Die
Verwendung der 
"Ahnlichkeitsrelation ist in TooL eng mit der Verwendung des Typbezeichners
{\bf Self} verkn"upft. Die typsichere Vererbung von Methoden mit Parametern
dieses Typs (z.B. bin"aren Methoden) wird erm"oglicht. Die Spezialisierung des
Objekttyps 
in derartig beerbten Subklassen verhindert jedoch die Subsumption unter dem
Objekttyp der Oberklasse. Dieser eventuelle Nachteil f"ur den Benutzer der
Bibliothek kann jedoch durch den Einsatz von Typparametern mit
"Ahnlichkeitsbindung kompensiert werden. Diese 
Technik wird bereits in der Beh"alterklassenbibliothek f"ur die Entwicklung
generischer Algorithmen genutzt (Abschnitt \ref{ImplVar}). Probleme mit der
Subtypheterogenit"at von 
Beh"altern entstehen bei Verwendung einer "Ahnlichkeitsbindung f"ur den
Elementtypparameter einer Klasse. Sie lassen sich aber f"ur einen konkreten
Beh"alter durch Definition einer (zus"atzlichen) Subklasse umgehen, welche ohne
weitere Implementierungen die Anpassung an die gew"unschte Subtyphierarchie
leistet (Abschnitt \ref{GenBehKlas}). 

Der Einsatz von Design-Mustern (\ref{ZDsgnMstr}) und hier insbesondere der
Br"uckentechnik, kann eine Vereinfachung des Vererbungsgraphen bewirken
(Abschnitt \ref{Entwrfsmstr}). Die Anordnung von Implementierungsvarianten
einer Beh"alterkategorie in einer separaten Hierarchie und die Nutzung des 
m"achtigen abstrakten Implementierungsprotokolls dieser Hierarchie zur
Implementierung der Beh"altervarianten f"uhrt zu einer flacheren, die
Kombination mit den Implementierungseigenschaften des Klassifizierungsschemas
aussparenden Struktur. Die auf die Elementrepr"asentation bezogene
Implementierungsvererbung wird ebenfalls vermieden. Eine eigenschaftsbezogene
Klassifizierung des Beh"alterprotokolls mu"s jedoch nicht aufgegeben werden.

Das in TooL entwickelte Klassifizierungsschema, die
Strukturierung des Vererbungsgraphen mit der eigenschaftsbezogenen Aufteilung
der Methoden und die geschilderten 
Implementierungstechniken sind durchaus auf andere Sprachen
"ubertragbar. Der 
Einflu"s des speziellen Typsystems von TooL war nicht so gro"s, da"s eine
Anpassung etwa an eine andere streng typisierte objektorientierte Sprache
unm"oglich 
erscheint. Insofern k"onnen die Ergebnisse der Arbeit auch f"ur andere
Bibliotheksentwickler interessant sein. 
Unabh"angig davon kann die Klassenbibliothek weiter verbessert werden. In
einigen Beh"alterkategorien ist eine feinere 
Strukturierung denkbar. Auch die Umsetzung anderer Design-Muster k"onnte
untersucht werden, um die Struktur weiter zu vereinfachen oder flexibler zu
gestalten.


%Die Implementierung  der Bibliothek erfolgte nicht unter Verwendung einer
%kommerziellen Programmiersprache, sondern nutzte den Prototyp TooL. Sie ist
%insofern eng an dieses Sprachexperiment gekoppelt. Eine Weiterentwicklung der
%Sprache steht bereits bevor. 