\chapter{Generische und typsichere Systemgenerierung}
\label{cha_make}

Die Modulverwaltung in ihrer bisherigen Form umfa"st einige Dienste
und Aufgaben, die in generalisierter Form auch in anderen Bereichen
Anwendung finden k"onnten.  Z.~B.\ ist es denkbar, Objekte einer
Datenbank, die in Beziehungen zueinander stehen, so zu modellieren,
da"s Aktualisierungen abh"angig von bestimmten Kriterien durchgef"uhrt
werden.  Die Beobachtung, da"s zwischen Objekten Abh"angigkeiten
bestehen und da"s gewisse Eigenschaften dieser oder anderer Objekte zu
bestimmten Aktionen f"uhren, waren schon 1979 Anla"s f"ur die
Realisierung eines Werkzeuges, das diese Aufgaben automatisch erledigt
\cite{make}.  Auch f"ur diese Arbeit war es der Ausgangspunkt f"ur die
praktische Implementierungsarbeit, die hier einen ersten Schritt auf
dem Weg zu einem wiederverwendbaren Modulmanager markiert.

Der in Abschnitt~\ref{subsec_uebersetzung} beschriebene Algorithmus
zur Bestimmung von Beziehungen zwischen Schnittstellen und Moduln und
zum Ausl"osen der "Ubersetzung dieser Komponenten in Abh"angigkeit der
Modifikationszeit und des Fingerprints beinhaltet ebenfalls das
geschilderte Generalisierungspotential.  Gegenw"artig sind die
Objekte, Funktionen und die Art und Weise der Bestimmung von
Ab\-h"angigkeiten allerdings fest im Code der Modulverwaltung
eingebaut.  Die Ausf"uhrungen im
Abschnitt~\ref{subsec_systemgenerierung} haben gezeigt, da"s die
Anforderungen an eine Systemgenerierung aber durchaus vielschichtiger
sind.  Bezogen auf die dort entwickelten Anforderungen zeigt die
Modulverwaltung besonders in den folgenden Punkten Schw"achen.  Diese
r"uhren allerdings daher, da"s der Entwurf der Modulverwaltung die
Generizit"at und Vielschichtigkeit dieser Anforderung aufgrund des
klar umrissenen Einsatzgebietes innerhalb des Tycoon-Compilers nicht
zu ber"ucksichtigen brauchte (s.~Kapitel~\ref{cha_aufgaben}).

\begin{itemize}
\item
Die Modulverwaltung ist bzgl.\ der zu behandelnden Objekte auf
Schnittstellen, Moduln und Bibliotheken des Tycoon-Systems und damit
auf Dateien beschr"ankt.

\item
Die Bestimmung der Abh"angigkeiten beruht ausschlie"slich auf der
{\itshape import}-Klausel.  Feiner abgestufte Beziehungen werden nicht
unterst"utzt.

\end{itemize}

Ausgehend von der Schilderung in Abschnitt~\ref{sec_uebersetzen}
erschien es nun sinnvoll, die Funktionalit"at der Systemgenerierung in
ein nicht direkt in den Compiler integriertes, wohl aber von ihm
benutztes Modul auszulagern.  Der Begriff der Systemgenerierung kann
damit viel weiter als in Abschnitt~\ref{subsec_systemgenerierung}
gefa"st werden.  Er schlie"st beliebige Systeme bestehend aus in
Beziehung stehenden Objekten ein, wie z.~B.\ Datenbanken.

Im folgenden soll zuerst aufgezeigt werden, welche Ans"atze zur
Bew"altigung dieser Aufgabe existieren.  Diese Erl"auterungen werden
anhand des in der Praxis h"aufig eingesetzten UNIX-Make vertieft.
Anschlie"send wird der im Rahmen dieser Arbeit gew"ahlte Ansatz
vorgestellt und einer kritischen Betrachtung unterzogen.

\section {Ans"atze}
\label{sec_ansaetze}

Die Systemgenerierung ist nach Abschnitt~\ref{sec_uebersetzen} die
Steuerung eines Transformationsvorganges.  Zentrales Problem ist dabei
die Modellierung der Beziehungen von unterschiedlichen Objekten, um
die Transformationen korrekt und effizient durchf"uhren zu k"onnen.
Dazu ist es n"otig, die Struktur dieser Objekte zu analysieren, d.~h.\ 
festzustellen, wo die Abh"an\-gigkeitsinformation lokalisiert werden
kann.  Sie kann direkt in den Objekten enthalten sein oder explizit
beschrieben werden.  Weiterhin zu beachten ist die
Abh"an\-gig\-keitsrelation, die als Abh"angigkeitsgraph visualisiert
werden kann.  Kann bzw.\ darf er Zyklen enthalten?
 
Zun"achst ein "Uberblick der von anderen Systemen gew"ahlten Ans"atze
zur Beschreibung von Abh"angigkeiten \cite{notion}:

\begin{itemize}
\item Die Abh"angigkeiten sind explizit in der Syntax der Sprache
  enthalten, wie z.~B.\ bei Ada und Modula.  Die speziell auf die
  Sprache zugeschnittenen Umgebungen und Compiler nutzen diese
  Information direkt.

\item 
\begin{sloppypar} 
  Aus dem Quelltext werden die Abh"angigkeiten automatisch mittels
  eines Werkzeuges generiert.  Der Unterschied zum ersten Punkt ist,
  da"s hier die Abh"angigkeitsin\-formation in expliziter Form
  vorliegt bzw.\ generiert wird.  Sie kann somit von
  sprach\-unabh"angigen Werkzeugen genutzt werden.
\end{sloppypar}

\item Beziehungen werden extern bereitgestellt.  Dies kann durch
  Sprachen ({\itshape module interconnecting languages}) wie z.~B.\ 
  Odin \cite{odin} geschehen.  Eine weitere M"oglich\-keit ist die
  Beschreibung mittels Regeln, wie sie vom UNIX-Make verwendet wird.
  Kern sowohl von Odin als auch von Make ist der Abh"angigkeitsgraph.
  Die Spezifikationssprache Odin zeichnet sich dar"uber hinaus dadurch
  aus, da"s sie mehrere Typen von Abh"angigkei\-ten unterst"utzt.

\end{itemize}

Die vorgestellten L"osungen "uberschneiden sich zu einem gewissen Teil
und werden in der Praxis teilweise gleichzeitig genutzt.  Wichtig ist,
da"s sie sich mit einer Ausnahme alle ausschlie"slich auf
Programmiersprachen beziehen und damit in bezug auf die von mir
postulierte Generizit"at der zu behandelnden Objekte bereits eine
Einschr"ankung darstellen.  Eine Modellierung von Objekten und deren
Beziehungen innerhalb einer Datenbank ist mit diesen Ans"atzen z.~B.\ 
nicht zu erreichen.  Nur in einem Makefile lassen sich beliebige
Objekte auff"uhren, daf"ur ist die Granularit"at der Objekte auf
Dateigr"o"se beschr"ankt.

Aus dieser Aufstellung wird weiterhin deutlich:

\begin{enumerate}

\item Die Art der Objekte ist fest vorgegeben.  Meist sind sie auf
  Dateien bzw.\ bestimmte Dateitypen eingeschr"ankt.

\item "Uber das Auftreten der Abh"angigkeitsinformation sind feste
  Annahmen getroffen worden.  In den aufgef"uhrten F"allen mu"s diese
  Information entweder explizit vom Anwender bereitgestellt oder vom
  System generiert werden.

\end{enumerate}


