
\chapter{Einleitung}
\pagenumbering{arabic}

Diese Arbeit bescha"ftigt sich mit der Modulverwaltung des Tycoon
Systems.  Ziel ist es, die existierende Modulverwaltung von Tycoon,
die aus einem ad hoc-Ansatz heraus entstanden und weitgehend
undokumentiert ist, zu analysieren.  Konzepte und Aufgaben, die
umgesetzt bzw.\ nicht umgesetzt wurden, werden betrachtet.  Auf diesen
Betrachtungen liegt der Schwerpunkt dieser Arbeit.  Sie bilden
au"serdem die Grundlage f"ur nachfolgende Arbeiten, aber auch
Verbesserungen der Performanz k"onnen hiervon abgeleitet werden.  Die
bislang fehlende und fehlerhafte Dokumentation wird mit dieser
hinzugef"ugt bzw.\ ersetzt fehlerhafte.  Bekannte Fehler werden
korrigiert, unbekannte Fehler durch systematische Tests gesucht und
unvollst"andig implementierte Merkmale bzw.\ in ihrer Semantik unklare
Eigenschaften ({\itshape hide}-Klausel, geschachtelte Bibliotheken)
werden einer kritischen Betrachtung unterzogen.

Durch Analyse von h"aufig gebrauchten Datenstrukturen und
durchlaufenen Funktionen k"onnen Engp"asse lokalisiert und
durch alternative Datenstrukturen ersetzt werden.  Andere "Anderungen
erfordern es, Algorithmen neu zu entwerfen, zu implementieren und
zu bewerten.

Schlie"slich ist ein weiteres Ziel, die gewonnenen Kenntnisse
anzuwenden, die wesentlichen Konzepte der Modulverwaltung zu erfassen
und vom Rest des Tycoon Compilers zu isolieren.  Auf diese Weise kann
ein m"oglichst weitgehend wiederverwendbarer {\itshape Modulmanager}
entstehen.  Hierzu wird mit der Entwicklung des generischen Make
ein Schritt getan.  Weitere Schritte in diese Richtung m"us\-sen noch
folgen.  Ganz allgemein ist zu untersuchen, ob die Aufgabe der
Verwaltung interner Objekte im Objektspeicher und externer Objekte auf
Sekund"arspeicher in einer generischen Bibliothek realisiert werden
kann oder ob eine Verwaltung {\itshape aller} Objekte, die der
Modulverwaltung unterliegen, im Objektspeicher m"oglich ist.

Die vorliegende Arbeit gliedert sich wie folgt:

\begin{itemize}
\item
Im vorliegenden Kapitel motiviere ich im weiteren zun"achst, warum es
f"ur die Programmierung im Gro"sen sinnvoll, fast unverzichtbar ist,
ein Programm in verschiedene Moduln zu gliedern.  Daran schlie"st sich
eine kurze Einordnung des Themas in einen gr"o"seren
Gesamtzusammenhang an.
\item
In Kapitel~\ref{cha_objekte} werden die Objekte vorgestellt, die
Gegenstand der Betrachtung der weiteren Arbeit sein werden.  Dar"uber
hinaus werden Belange, die diese Objekte ber"uhren, wie versteckte
Bezeichner, Zust"ande und das Problem des Rautenimports behandelt.
\item
In Kapitel~\ref{cha_umgebung} wird die Umgebung der Modulverwaltung
skizziert.  Diese ist insofern von Bedeutung, als da"s man es hier mit
einem persistenten System zu tun hat.  Die daraus resultierenden
Besonderheiten werden dort erl"autert.
\item
Aufbauend auf den Kapiteln~\ref{cha_objekte} und~\ref{cha_umgebung}
werden im Kapitel~\ref{cha_aufgaben} die Aufgaben der Tycoon
Modulverwaltung geschildert.  Gleichzeitig wird eine Abgrenzung zu
Aufgaben gegeben, die derzeit nicht Teil der Modulverwaltung sind, aber
durchaus integriert werden k"onnten.
\item
Der Zugriff auf die Tycoon Modulverwaltung geschieht bisher mit kaum
bzw.\ unklar dokumentierten Kommandos.  Kapitel~\ref{cha_semantik}
schlie"st diese L"ucke und legt die Semantik dieser Kommandos offen.
\item
Kapitel~\ref{cha_implementierung} besch"aftigt sich mit der
Implementierung der Tycoon Modulverwaltung.  Es gibt einen "Uberblick
"uber den internen Aufbau, der anhand zweier ausgew"ahlter Abl"aufe
vertieft wird.
\item
In Kapitel~\ref{cha_erweiterung} und~\ref{cha_make} wird die
praktische Arbeit dokumentiert.  Zun"achst werden die Arbeiten
beschrieben, die direkt am Code der Modulverwaltung vorgenommen
wurden.  Es handelt sich hierbei sowohl um die Beseitigung
aufgetretener Fehler als auch um Verbesserungen im Performanzbereich.
Daran schlie"st sich die Schilderung einer neu entwickelten Komponente
zur Systemgenerierung an.  Diese wird mit einem vergleichbaren
Werkzeug aus der Unix-Welt verglichen und einer ab\-schlies\-senden
Bewertung unterzogen.  Zum Schlu"s dieser Arbeit wird versucht, in
einem Ausblick die Richtung f"ur weitere Denkans"atze und
Entwicklungen aufzuzeigen.
\end{itemize}

Vom Leser dieser Arbeit wird die Kenntnis der Sprache \tl vorausgesetzt.

\section{Motivation}

Das Tycoon System ist entwickelt worden, um besonders die Entwicklung
komplexer Anwendungen zu unterst"utzen.  Gerade f"ur die
Programmierung dieser gro"sen Systeme, die oft aus hunderttausenden
von Zeilen Code bestehen, ist eine besondere Unterst"utzung n"otig, da
sie aufgrund ihrer Gr"o"se und Komplexit"at anderenfalls nicht mehr
beherrschbar w"aren.  Ein wichtiger Beitrag ist in diesem Zusammenhang
die M"oglichkeit zur Abstraktion durch Moduln.  Dieser Begriff und
seine Auswirkungen auf die Programmierung sollen im folgenden
erl"autert werden.

Nach \cite{duden,module} ist ein Modul\footnote{In dieser Arbeit wird
der Begriff ''Modul'' benutzt, der auch in vielen Programmiersprachen,
wie z.~B.\ Modula-2, Verwendung findet.  In Ada hingegen wird der
Begriff des ''Paket'' ({\itshape package}) gebraucht, der semantisch
mit dem des Moduls identisch ist.}  eine Zusammenfassung von
Konstanten, Datentypen, Variablen und Prozeduren zu einer Einheit.  Es
gliedert sich in ein Definitionsmodul und ein Implementationsmodul.
Diese Teile sind oft verschiedene Dateien.  Alle Bezeichner, die sich
innerhalb des Moduls befinden, sind nur dort sichtbar; umgekehrt sind
Bezeichner, die au"serhalb definiert sind, nur au"serhalb sichtbar.
Diese beiden Sichtbarkeitsbereiche werden dadurch, da"s einige
Bezeichner in der Schnittstelle des Moduls explizit sichtbar gemacht
und dann von anderen Moduln und Schnittstellen importiert werden,
verbunden.  Im Definitionsmodul werden daf"ur die Bezeichner des
Moduls aufgef"uhrt, die f"ur den Klienten des Moduls sichtbar sein
sollen, also exportiert werden.\footnote {Die Liste der exportierten
Bezeichner wird oft auch mit ''Exportschnittstelle'' oder einfach
''Schnittstelle'' bezeichnet.  Die Liste der von einem anderen Modul
ben"otigten Bezeichner nennt man ''Importschnittstelle''.}  Im
Implementationsmodul befinden sich die Definitionen f"ur die im
Definitionsmodul deklarierten Bezeichner, wie Typen, Variablen etc.
Hier und evtl.\ auch im Definitionsteil werden die Bezeichner
angegeben, die importiert werden, deren Sichtbarkeitsbereich bis
innerhalb des Moduls ausgedehnt wird.  Weiterhin werden hier die
Prozedurr"umpfe der exportierten und lokalen Prozeduren
ausprogrammiert.  Ein Modul schr"ankt damit wie eine Prozedur
Sichtbarkeitsbereiche ein bzw.\ legt sie fest \cite{dalcin}.  Es
bestehen allerdings grundlegende Unterschiede:

\begin{itemize}
\item
Anders als eine Prozedur, die nur {\itshape einen}\/ bestimmten Zweck
erf"ullt, ist das Modul die Zusammenfassung mehrerer Prozeduren,
Datenstrukturen usw.  Abh"angig von den Objekten und dem Zweck der
Zusammenfassung unterscheidet man verschiedene Modularten \cite{dalcin}:

\begin{itemize}

\item Funktionsmodul: 
Hierunter versteht man ein Modul, das seine Funktionalit"at mit Hilfe
von Prozeduren bzw.\ Funktionen bereitstellt.  Es besitzt keine
lokalen Datenobjekte und wird daher auch als ged"achtnislos
bezeichnet.

\item Dateimodul:
Dabei handelt es sich um eine Art von Modul, das Konstanten, Variablen
und Datentypen exportiert, z.~B.\ um h"aufig verwendete Objekte
anderen Moduln zur Verf"ugung zu stellen.

\item Datenmodul:
Ein Modul, das ein oder mehrere Datenobjekte implementiert, aber nur
die zum Zugriff notwendigen Prozeduren exportiert und die eigentliche
Struktur des Objektes verbirgt, bezeichnet man als Datenmodul.

\item Abstrakter Datentyp:
Bei dieser Modulart werden ein Datentyp und entsprechende Zugriffsprozeduren
exportiert.  Damit lassen sich Objekte des Typs erzeugen und
bearbeiten.  Die Struktur des Typs ist im Modul verborgen.

\end{itemize}

\item
In einem Modul lassen sich die Bezeichner selektiv "uber Import- und
Exportlisten sichtbar machen bzw.\ verstecken.  Eine Prozedur kann
lokale Bezeichner nicht nach au"sen sichtbar machen.  Globale
Programmobjekte k"onnen in ihrer Sichtbarkeit nicht weiter
eingeschr"ankt werden.  Die einzige M"oglichkeit besteht darin,
globale Objekte innerhalb einer Prozedur durch lokale Objekte zu
"uberdecken, nicht aber die Globalit"at aufzuheben.

\item
Die Lebensdauer lokaler Bezeichner einer Prozedur erstreckt sich nur
auf die Zeit der Abarbeitung. Danach verlieren sie ihre G"ultigkeit.
Bezeichner innerhalb eines Moduls sind "uber die gesamte Lebensdauer
der Modulumgebung definiert und damit statisch\footnote{In der
Programmiersprache C gibt es anders als z.~B.\ in Modula-2 die
M"oglichkeit, auch innerhalb von Prozeduren statische Variablen
anzulegen.  Dies geschieht durch die Zuweisung einer Variablen zur
Speicherklasse {\itshape static}.  Die Variable beh"alt dadurch auch
nach Beendigung der Prozedur ihren Wert.  Allerdings m"ussen auch alle
Bezeichner, die innerhalb eines Moduls deklariert werden und nicht
nach au"sen sichtbar sein sollen, mit {\itshape static}\/ aufgef"uhrt
werden; sie erlangen anderenfalls programmweite G"ultigkeit.  Die
Speicherklasse {\itshape auto}\/ entspricht innerhalb einer Prozedur
der aus Pascal oder Modula-2 gewohnten Semantik
\cite{kernighan}.}.

\item
Der Rumpf eines Moduls wird nur einmal bei der Initialisierung
ausgef"uhrt, der Rumpf einer Prozedur bei jedem Aufruf.
\end{itemize}

Durch das Modulkonzept lassen sich Programme in "uberschaubare und
weitgehend voneinander unabh"angige Teile gliedern.  Dies hat
inbesondere bei der Entwicklung gros\-ser und komplexer
Softwaresysteme Vorteile.

In \cite{oose} findet sich eine auf den Entwurf von Software
gerichtete Diskussion der Modularisierung.  Hier werden f"unf
Prinzipien entwickelt, die wiederum aus f"unf Kriterien abgeleitet
werden und nach denen der Entwurf vorgenommen werden sollte.  Zwar
ist der Softwareentwurf nicht Thema dieser Arbeit, die Diskussion in
\cite{oose} bietet aber einige weitere Argumente f"ur die
N"utzlichkeit der Modularisierung, die im folgenden kurz erl"autert
werden.

\subsection{Separate "Ubersetzung}

In der Literatur tauchen zu diesem Thema zwei "ahnliche Begriffe auf,
die der Kl"a\-rung bed"urfen \cite{separate}.  Ihre unterschiedliche
Bedeutung hat weitreichende Konsequenzen:

\begin{description}
\item[Unabh"angige "Ubersetzung:]
Unter unabh"angiger "Ubersetzung ({\itshape independent compilation})
versteht man das "Ubersetzen einzelner Programmeinheiten, ohne dabei
die Schnittstellen anderer Einheiten zu pr"ufen.  Sie wird von vielen
Programmiersprachen unterst"utzt, die keine
Modularisierungsmechanismen besitzen.

\item[Separate "Ubersetzung:]
Im Gegensatz zur unabh"angigen "Ubersetzung wird bei der separaten
"Ubersetzung ({\itshape separate compilation}) jedes Modul auf
Konsistenz mit den von ihm benutzten Schnittstellen "uberpr"uft.
\end{description}

Beide Techniken gestatten es dem Programmierer, seine Arbeit in
kleinere Einheiten zu zerlegen, in Moduln aufzuteilen.  Es ist aber
offensichtlich, da"s die separate "Uberset\-zung, wie sie Modula-2 oder
Mesa \cite{mesa} bieten, durch die Erzwingung der Typkonsistenz "uber
Modulgrenzen hinweg gr"o"sere Vorteile bringt.  Fehler, die z.~B.\
auftreten, weil eine Funktion aus einem fremden Modul mit falschen
Parametern aufgerufen wird, k"onnen schon zur "Ubersetzungszeit
erkannt und beseitigt werden.

Im Vergleich zu monolithischen Systemen, die aus einer gro"sen
Programmdatei bestehen oder stets komplett "ubersetzt werden m"ussen,
bietet separate "Ubersetzung die M"oglichkeit, den "Ubersetzungsaufwand
nach einer "Anderung gering zu halten.  Es mu"s meist nur eine
kleinere Anzahl der zu einem System geh"orenden Einheiten neu
"ubersetzt werden, da andere Moduln, die nicht von der "Anderung
betroffen sind, unver"andert bleiben k"onnen.

\subsection{Kapselung}

Man versteht unter Kapselung das Zusammenfassen z.~B.\ eines Datentyps
mit den auf ihn anwendbaren Funktionen in der Art, da"s nur "uber
diese Funktionen auf den Datentyp zugegriffen werden kann.
Programmiersprachen ohne Modulkonzept haben meist keine Mittel, dies
darzustellen.  Kapselung h"angt damit eng mit dem Begriff Abstraktion
zusammen.  W"ahrend Kapselung die ''bottom-up''-Sicht
repr"asentiert, kann man Abstraktion als ''top down''
-Sichtweise verstehen.  Hier wird ausgehend von gewissen Attributen
z.~B.\ ein abstrakter Datentyp geformt.

Durch Kapselung ist es also m"oglich, von unwichtigen Details eines
Moduls zu abstrahieren und sich auf das Wesentliche zu konzentrieren
({\itshape information hiding}).  Dies ist eines der wichtigsten
Hilfmittel, um sicher und effizient gro"se Systeme zu entwickeln
\cite{module}.  Die Schnittstelle eines Moduls kann als ein 
''black box interface'' angesehen werden, das die Operationen usw.\
spezifiziert.  Die Implementation ist vollst"andig im
Implementationsteil des Moduls enthalten und damit f"ur den Benutzer
des Moduls unsichtbar.

Auf diese Weise k"onnen z.~B.\ maschinenabh"angige Teile eines
Programms gekapselt werden.  Dies erleichtert dann die Portierung auf
andere Systeme.  Ganz allgemein lassen sich die Auswirkungen von
"Anderungen besser lokalisieren und damit die Wartbarkeit erh"ohen.

\subsection{Hierarchische Strukturierung}

Die Wartungsfreundlichkeit wird auch durch die hierarchische
Strukturierung unter\-st"utzt.  W"ahrend bei Programmiersprachen wie
C\footnote{In C sind alle nicht explizit als lokal definierte
Variablen- und Funktionsbezeichner global in allen anderen
"Ubersetzungseinheiten sichtbar \cite{kernighan}.}  oder
Pascal\footnote{Einige Pascal Dialekte wie z.~B.\ UCSD-Pascal
\cite{ucsd_pascal} oder Turbo Pascal \cite{turbo_pascal} unterst"utzen
ein Modularisierungskonzept.  Die Modularisierungseinheiten werden
hier als Units bezeichnet.} alle Prozeduren in {\itshape einem}\/
globalen Sichtbarkeitsbereich definiert sind, bekommt der Entwickler
durch Moduln eine weitere M"oglichkeit zu strukturieren.  Dies hat
haupts"achlich zwei Vorteile.

\begin{itemize}
\item
Es kann verhindert werden, da"s verschiedene Prozeduren sich in
undisziplinierter Weise gegenseitig benutzen.  Stattdessen wird die
Benutzt-Relation zwischen den Moduln automatisch ein gerichteter
Graph\footnote{In C sind auch zirkul"are Abh"angigkeiten zwischen
Moduln erlaubt \cite{kernighan}.  Hingegen ist dies in \tl oder in
Modula-2 verboten \cite{tycoon_po,module}.}.
\item
Die Wiederverwendung von Moduln bzw.\ Modulhierarchien wird
erleichtert, da die verwendeten Moduln durch die klare Struktur der
Abh"angigkeitsrelation bekannt sind.  Dies kommt vor allem dann zum
Tragen, wenn Moduln wiederum in gr"o"sere Einheiten wie Bibliotheken
zusammengefa"st werden k"onnen.
\end{itemize}

\subsection{Unabh"angige Entwicklung}

Die Verbindung mehrerer Moduln geschieht ausschlie"slich "uber die
Schnittstelle.  F"ur die Implementierung eines Modulrumpfes ist es
ausreichend, die Schnittstellen aller benutzten Moduln zu kennen.  Das
Ausprogrammieren verschiedener Moduln kann also v"ollig unabh"angig
voneinander geschehen, sind die Schnittstellen einmal festgelegt.  Die
Entwickler k"onnen so simultan an verschiedenen Moduln arbeiten, ohne
w"ahrend des Programmierens weitere Absprachen treffen zu m"ussen;
diese sind mit den Schnittstellen bereits getroffen worden.

Nat"urlich wird dieser Vorteil aufgehoben, wenn sich Schnittstellen
w"ahrend der Entwicklung h"aufig "andern.  Dies ist, wie
\cite{redundant} zeigt, ein nicht seltener Vorgang.

\section{Einordnung}
\label{sec_einordnung}

Die Modulverwaltung als eine Komponente kann nicht f"ur sich
betrachtet werden.  Sie ist ein Teil des Softwareentwicklungsproze"ses
insofern, als da"s ihr eine bestimmte Aufgabe innerhalb dieses
Kontextes zukommt.  Welche Aufgaben dies sind, soll anhand des
Begriffs Konfigurationsmanagement ({\itshape configuration
management}\/) und der damit verbundenen T"atigkeiten gezeigt werden.
Die Modulverwaltung wird damit in einen gr"o"seren Zusammenhang
eingeordnet.

Das Konfigurationsmanagement umfa"st eine Reihe verschiedener,
teilweise rechnergest"utz\-ter Vorg"ange.  Die wichtigsten sind nach
\cite{whitgift,notion,tools_tichy}:

\begin{enumerate}
\item Objektidentifikation ({\itshape identification, item
identification})
\item Versionierung ({\itshape version management, version selection 
and baselining})
\item "Anderungsverwaltung ({\itshape change control, change tracking})
\item Systemgenerierung ({\itshape building the system, software
manufacturing, regeneration})
\item Bibliotheksverwaltung ({\itshape library management, rights and 
protection})
\item Konkurrierender Zugriff ({\itshape managing simultaneous updates})
\end{enumerate}

\noindent 
Im Rahmen dieser Arbeit sind besonders Punkt eins und vier
von Interesse und werden im folgenden dargelegt.  An dieser Stelle
wird auch darauf hingewiesen, da"s wie im Verlauf der Arbeit noch
gezeigt wird, die Modulverwaltung auch allgemeiner, also nicht auf das
Umfeld von Programmiersystemen beschr"ankt, aufgefa"st werden kann.
Das Haupteinsatzgebiet der existierenden Modulverwaltungen und
insbesondere der des Tycoon Systems liegt aber im
Programmiersprachenumfeld.

\subsection{Objektidentifikation}
\label{subsec_identifikation}

Die Objektidentifikation bildet die Grundlage f"ur alle T"atigkeiten
des Konfigurationsmanagements und damit auch f"ur die Systemgenerierung
bzw.\ Modulverwaltung.  Sie legt fest, mit welchen Objekten man es zu
tun hat und wie diese identifiziert werden.  Nur wenn Objekte einzeln
benennbar sind, lassen sie sich auch zu gr"o"seren Einheiten
aggregieren oder andere Beziehungen zwischen ihnen aufbauen.

\subsection{Systemgenerierung}
\label{subsec_systemgenerierung}

Die Systemgenerierung erfordert eine Reihe unterschiedlicher Schritte,
wie "Ubersetzen, Vor- und Nachbearbeitung, Binden, Formatieren usw.,
und die dazu erforderlichen Programme bzw.\ Prozeduren.  Die
Modulverwaltung soll diese Transformationen unterst"ut\-zen und soweit
wie m"oglich automatisieren, geht jedoch noch "uber den Begriff der
Systemgenerierung hinaus.  Bei der Generierung mu"s insbesondere das
folgende ber"uck\-sich\-tigt werden:

\begin{itemize}
\item
Die entsprechenden Werkzeuge m"ussen mit den richtigen Optionen
versorgt werden.  Z.~B.\ verlangt der GNU\footnote{GNU: ''Gnu's
Not Unix'' ist der Name f"ur ein Unix-kompatibles Softwaresystem.}
C Compiler die Option {\itshape -Wall}, damit s"amtliche
Fehlermeldungen und Warnungen ausgegeben werden.

\item
Es mu"s die richtige Version des Werkzeuges verwendet werden.  Im
Zusammenhang mit dem ersten Punkt erlangt diese Forderung besonders
nach einem Update des Werkzeuges Bedeutung.  Es mu"s dann
sichergestellt werden, da"s stets die alte Version verwendet wird.  Es
ist nat"urlich auch m"oglich, die neue Version des Werkzeuges zu
benutzen, wobei dann auf ver"anderte syntaktische und semantische
Eigenschaften des Werkzeuges geachtet werden mu"s.  Es kommt z.~B.\
nach dem Aktualisieren auf eine neue Compiler-Version manchmal vor,
da"s ohne "Anderung des Quelltextes neue Fehlermeldungen beim
"Ubersetzen auftauchen.  Dies hat seine Ursache in der ge"anderten
Semantik des Compilers, dem entweder durch Verwendung der alten
Version des Compilers oder durch Anpassen des Quelltextes Rechnung
getragen werden mu"s.

\item
Fehlermeldungen oder Warnungen k"onnen w"ahrend der Transformation
auftreten.  Diese m"ussen protokolliert und ggf.\ behandelt werden.

\item 
Die Reihenfolge der Transformationen ist signifikant.

\item
Nur die Transformationen sollen ausgef"uhrt werden, die auch
wirklich n"otig sind.

\end{itemize}

Ein wichtiger Aspekt ist der Algorithmus, mit dem bestimmt wird, ob
eine Komponente transformiert werden mu"s.  Ein einfacher Ansatz ist
der des rekursiven Abstiegs in den Abh"angigkeitsgraphen und der
Benutzung eines Zeitstempels zur "Uberpr"ufung der Aktualit"at einer
Komponente, der z.~B. von {\itshape Make}\/ \cite{make} benutzt wird.
Eine Verbesserung hinsichtlich der Anzahl der zu "ubersetzenden
Komponenten und damit der gesamten Rechenzeit stellt die durch Smart
Recompilation \cite{smart} und Smarter Recompilation \cite{smarter}
gew"ahlte Herangehensweise dar.  Hier wird eine genauere Information
"uber die Abh"an\-gigkeiten von Komponenten dazu genutzt,
differenziertere Aussagen dar"uber zu machen, ob eine Komponente
transformiert werden mu"s.  Die Tatsache, da"s ein oder mehrere
Nachfolger einer Komponente im Abh"angigkeitsgraphen transformiert
wurden, also nicht mehr aktuell waren, f"uhrt nur dann zur
Transformation der fraglichen Komponente, wenn innerhalb der
Komponenten Teile betroffen waren, auf die sich auch die
Abh"angigkeits\-beziehung begr"undet.  Daneben gibt es weitere
Ans"atze, die es dem Benutzer "uberlassen, beliebige
Abh"angigkeiten zwischen den Komponenten zu definieren und die
auszuf"uhrenden Transformationen abh"angig von weiteren Bedingungen zu
machen.

Da"s das Feststellen der tats"achlich zu transformierenden Komponenten
nicht nur von akademischem Interesse ist, zeigt \cite{redundant}.  Die
dortige Untersuchung zweier in Ada geschriebener Systeme (die
Ergebnisse sind auf andere Sprachen "ubertragbar) zeigt, da"s zwischen
58\% und 62\% der get"atigten "Ubersetzungen unn"otig waren und durch
den Einsatz von Smart Recompilation h"atten verhindert werden k"onnen.
Ein weiteres Ergebnis der Studie unterstreicht die Notwendigkeit
effektiver Transformationstechniken.  Es hatte sich gezeigt, da"s ein
Drittel aller "Anderungen solche waren, die weitere Transformationen
nach sich zogen ("Anderung der Spezifikation eines Ada Packets).  Im
Durchschnitt waren 46\% aller Komponenten von solch einer "Anderung
betroffen.

Auch die Parallelisierung mehrerer unabh"angiger Transformationen ist
ein zu beachtender Punkt, der nicht nur die gesamte Ausf"uhrungszeit
g"unstig beeinflu"st, sondern auch die Auslastung des gesamten Systems
verbessert.

Mit dem Zusammenbau eines Systems besch"aftigt sich auch der im Rahmen
dieser Arbeit angefertigte praktische Teil.


