\chapter{Aufgaben der Tycoon Modulverwaltung}
\label{cha_aufgaben}

Nachdem nun die Objekte der Modulverwaltung und das Umfeld, in dem
diese sich bewegen, erl"autert wurde, arbeite ich in diesem Kapitel
die allgemeinen Aufgaben der Modulverwaltung heraus.  Hier soll der
Ausgangspunkt f"ur die Entwicklung eines neuen Modulmanagers liegen.
Dazu wird gezeigt werden, welche dieser Aufgaben Tycoon-spezi\-fisch und
welche von genereller Natur sind.  Die generellen Aufgaben bilden dann
die Grundlage f"ur einen von speziellen Tycoon Spezifika unabh"angigen
Modulmanager.  Dieser soll die geschilderten Aufgaben in ihrer
allgemeinsten Form l"osen und durch entsprechende Parametrisierung
auch auf das Tycoon System anwendbar sein.

\begin{figure}[htb]
\centering\mbox{\epsfig{file=lifecycle.eps}}
\caption{Typischer Entwicklungszyklus\protect \footnotemark\
eines Tycoon Quelltext-Objektes}
\label{abb_zyklus}
\end{figure}
\footnotetext{Die Abbildung zeigt einen Zyklus,
der nach dem Anwenden wieder beim Modifizieren beginnt.  Die
Darstellung lie"se sich noch beliebig verfeinern.  Eine sinnvolle
Erweiterung w"are z.~B.\ vor dem Anwenden noch die T"atigkeit Testen,
gefolgt von einer Wahlm"oglichkeit, ob der Test erfolgreich war, zu
modellieren.  Dies w"urde den h"aufig vorkommenden Fall st"arker
ber"ucksichtigen, da"s ein Entwickler auf dem Top\-level ein ge"andertes
Modul "ubersetzt, anschlie"send sofort importiert, dieses daraufhin
ausprobiert und weitere "Anderungen durchf"uhrt.  F"ur dieses Testen
mu"s man also nicht unbedingt den Begriff Anwenden verwenden.}

Die Entwicklung einer Tycoon-Komponente ist "ublicherweise ein
Iterationsproze"s (s.\ Abbildung~\ref{abb_zyklus}), der die Schritte
{\itshape Modifizieren}, {\itshape "Ubersetzen}, {\itshape
Importieren}\/ und {\itshape Anwenden}\/ be\-inhaltet.  Sie laufen in
einem Zyklus ab, der im Prinzip nie verlassen wird (''Ein Programm
ist nie fertig'').  Aus dem Blickwinkel der Modulverwaltung sind
{\itshape "Ubersetzen}\/ und {\itshape Importieren}\/ relevant, da
genau diese Aufgaben dort erledigt werden sollen.  Sie werden zusammen
mt dazu notwendigen bzw.\ eng zusammenh"angenden T"atigkeiten im
weiteren beschrieben.

\section{"Ubersetzen}
\label{sec_uebersetzen}

Der "Ubersetzungs- bzw.\ Systemgenerierungsvorgang selbst, bestehend
aus Typ"uberpr"u\-fung, Codegenerierung etc., ist nicht Teil der
Modulverwaltung, wird jedoch von ihr gesteuert.  Dazu ist es n"otig,
f"ur jede zu "ubersetzende Komponente, alle importierten Moduln und
Schnittstellen zu ermitteln.  Diese werden dann einzeln dem Compiler
"uberge\-ben, der sie "ubersetzt.

Diese Aufgabe l"a"st sich somit als parametrisierter Vorgang
auffassen.  Der eigentliche Vorgang besteht darin, nach einer
vorgegebenen Methode die Importe bzw.\ Abh"angig\-keiten zu ermitteln.
Daran anschlie"send werden die entsprechenden Objekte weiter
verarbeitet.  Die Parameter stellen dabei die Methoden zur
Abh"angigkeitsermittlung und zum Weiterverarbeiten dar.

\section{Binden und Definieren}

\begin{sloppypar}
Eine weitere Aufgabe besteht darin, die in den
Abschnitten~\ref{sec_schnittstelle} und \ref{sec_modul} beschriebenen
Bindungen vorzunehmen.  Hierbei handelt es sich zum Teil um eine
Tycoon-spezifische Aufgabe.  Objekte, die zuvor importiert wurden,
sollen nun dem Benutzer sichtbar gemacht und Referenzen zu externen
Objekten aufgel"ost werden.  Hierzu m"ussen sie in die entsprechenden
Strukturen des Tycoon-Systems, insbesondere in den Toplevel-Vektor
eingetragen werden.  Genauere und ausf"uhrlichere Erl"auterungen dazu
folgen in den Abschnitten~\ref{sec_import} und \ref{subsec_import}.
\end{sloppypar}

Das Aufl"osen externer Referenzen ist ein Vorgang, der auch in anderen
Programmiersystemen Anwendung findet, z.~B.\ durch das Bindeprogramm
({\itshape linker}) in der UNIX-Um\-ge\-bung.  Dieser ist in der Lage,
Objektdateien, die von beliebigen "Ubersetzern erzeugt wurden, zu
einer ausf"uhrbaren Einheit zu binden.  Insofern handelt es sich beim
Bindevorgang um eine generische Aufgabe.  Das Bindeprogramm ist jedoch
auf ein bestimmtes Format der Objektdateien angewiesen, um die
Referenzen zu lokalisieren.  Dieses Format ist also der Parameter des
Bindevorgangs.

\begin{sloppypar}
Die Besonderheiten bez"uglich des Tycoon Systems ergeben sich nun
z.~B.\ aus der Tatsache, da"s Objekte explizit auf dem Toplevel
bekanntgemacht werden m"ussen.  Vergleichbares mu"s das Bindeprogramm
unter UNIX nicht ber"ucksichtigen, da alle Objekte als Dateien
vorliegen und somit dem Benutzer bekannt sind.  Weitere in diesem
Zusammenhang zu beachtende Punkte, wie z.~B.\ der des Rautenimport
\cite{quest}, machen die Spezialisierung auf das Tycoon
System deutlich (s.~a.\ Abschnitt~\ref{sec_bibliothek}).  Es bleibt
festzuhalten, da"s der Bindevorgang an sich, also nur die Aufl"osung
der externen Referenzen, ein generischer Vorgang ist.  Dar"uber 
hinausgehende T"atigkeiten sind sehr systemabh"angig.
\end{sloppypar}

\section{Sekund"arspeicherzugriff}

Die Modulverwaltung mu"s mit mehreren persistenten Speichern arbeiten
(s.~a.\ Abbildung~\ref{abb_inex}).  Zum einen verwaltet sie Objekte,
die sich im Objektspeicher befinden, zum anderen greift sie auf
Objekte zu, die im Dateisystem liegen.  Die Verbindung zwischen den in
Kapitel~\ref{cha_umgebung} vorgestellten Komponenten Objektspeicher
und Sekund"arspeicher wird bereits durch die generische Dienste
{\itshape intern}\/ und {\itshape extern}\/ des Moduls {\itshape
dynamic} realisiert.  In der Modulverwaltung werden diese benutzt,
indem z.~B.\ das Layout f"ur die zu speichernden Objekte festgelegt
wird.  Sie bilden damit das Grundger"ust, auf dem die zuvor
geschilderten Aufgaben aufsetzen.

\begin{figure}[htb]
\centering\mbox{\epsfig{file=inex.eps}}
\caption{
Der Austausch zwischen Objektspeicher und Dateisystem erfolgt "uber
die Funktionen {\itshape dynamic.intern}\/ und {\itshape
dynamic.extern}.}
\label{abb_inex}
\end{figure}

\section{Versionierung und Konfigurationsmanagement}

\begin{sloppypar}
Versionsverwaltung und dar"uber hinaus gehende Aufgabe des
Konfigurationsmanagements, die f"ur die Entwicklung gro"ser
Softwaresysteme unverzichtbar sind, geh"oren im Moment nicht zu den
Aufgaben der Modulverwaltung.  In der am Arbeitsbereich DBIS
verwendeten Umgebung werden die Versionsverwaltung und die Verwaltung
unterschiedlicher Arbeitsbereiche ({\itshape workspace}) der
Entwickler durch externe Werkzeuge realisiert und bezieht sich
ausschlie"slich auf Sekund"arspeicherobjekte.
\end{sloppypar}

\section{Zusammenfassung}

Wie die vorstehenden Ausf"uhrungen zeigen, gliedern sich die Aufgaben
der Tycoon Modulverwaltung in einen Teil, der speziell auf die Belange
von Tycoon und die Sprache \tl abgestimmt ist, und in einen Teil, der
allgemeine Aufgaben betrifft.  Ziel sollte es sein, diese beiden Teile
voneinander zu trennen und die allgemeinen Aufgaben in generischer
Weise zu l"osen.  Man erhielte dadurch ein Tycoon System mit klaren
Schnittstellen zu anderen Diensten und gleichzeitig wiederverwendbare
Softwarekomponenten.

Das in praktischer Arbeit von mir entwickelte Modul {\itshape Make}\/
verfolgt diesen Weg in bezug auf die in
Abschnitt~\ref{sec_uebersetzen} dargelegte Aufgabe.  Es wird in
Kapitel~\ref{cha_make} vorgestellt.  Dabei wird besonders versucht,
das generische Potential dieser Aufgabe auszusch"opfen.



