\section {Ans"atze}

Es lassen sich grunds"atzlich zwei verschiedene Ans"atze aufzeigen,
wie eine Modulverwaltung realisiert werden kann.  Zum einen kann die
Modulverwaltung in die Entwicklungsumgebung integriert sein.  Im
anderen Fall wird die Modulverwaltung durch externe Tools realisiert,
die aber dem entsprechenden Anwendungsfall angepa"st sind.  In
\cite{connect_tools} wird eine "ahnliche Einteilung vorgenommen.  Zu
den integrierten Systemen werden hier aber auch solche gez"ahlt, die
zwar aus verschiedenen einzelnen Werkzeugen bestehen, aber z.~B.\ "uber
eine gemeinsame Datenbank oder durch Austausch von Nachrichten
verbunden sind.  Auf diese Unterscheidung wird hier nicht weiter
eingegangen.

Die hier angesprochenen Entwicklungsumgebungen sind nicht auf
Programmiersysteme beschr"ankt.  Es lassen sich durchaus auch andere
Anwendungen denken, wie z.~B.\ Dokumentenverwaltung mit Hilfe einer
Modulverwaltungen.

\subsection {Integrierter Ansatz}

Diese Gruppe von Systemen besteht aus Werkzeugen, die speziell auf
ihre entsprechende Umgebung abgestimmt sind.  Beispiele aus dem
Bereich der Programmierumgebungen sind die in \cite{modula_cm} f"ur
Modula-2 und in \cite{whitgift} f"ur Ada beschriebenen Systeme.

Der Vorteil dieses Ansatzes besteht haupts"achlich darin, da"s
spezielle semantische und syntaktische Informationen der zu
verwaltenden Komponenten f"ur die Modulverwaltung verwendet werden
k"onnen.  So k"onnen die Abh"angigkeiten direkt aus dem Quelltext
gewonnen werden und erlauben eine feinere Aufl"osung ({\itshape fine
grained dependencies}) als die sonst "ubliche per-Datei Basis.  Dies
erlaubt dann z.~B.\ die Anwendung eines effizienten Algorithmus zur
"Ubersetzung, der mehrere der sonst "ublichen "Ubersetzungsvorg"ange
eliminieren kann.  Au"serdem entf"allt die Notwendigkeit, die
Abh"angigkei\-ten auf irgendeine Art und Weise erst abzuleiten.
Selbst wenn dieser Vorgang in vielen Systemen nicht mehr manuell
ausgef"uhrt werden mu"s, so kann er dennoch falsch ausgef"uhrt,
vergessen o.~"a.\ werden.

Nachteilig ist der f"ur die genaueren Abh"angigkeiten erh"ohte
Speicherbedarf und oft auch ein Performanzverlust.  Dieser kommt
dadurch zustande, da"s der Zugriff auf die sonst "ublichen Zeitmarken
wesentlich besser vom Betriebssystem unterst"utzt wird und damit
schneller abl"auft als das Lesen der Abh"angigkeitsinformationen, die
meist in der Datei selbst enthalten sind \cite{modula_cm}.  Neben dem
Verzeichnis, das die Zeitmarken speichert, m"ussen also auch alle
referenzierten Dateien angesprochen werden, auch wenn dies letztlich
nicht n"otig gewesen w"are.

Daneben k"onnen diese Systeme durch ihren umfassenden Charakter dem
Benutzer auch eine einheitliche und somit konsistente Bedienung
bieten.  Dies erleichtert sicherlich die Einf"uhrung einer
entsprechenden Umgebung, da der Aufwand zur Erlernung der
Bedienungselemente klein gehalten werden kann.  Mit der Zeit verliert
dieser Aspekt aber gegen"uber Systemen, deren Komponenten keine
einheitliche Bedienung bereitstellen, an Bedeutung.

\subsection{Externer Ansatz}

In diese Kategorie fallen Systeme, die mit einem eigenen
konfigurierbaren Systemmodell arbeiten.  Mit diesem Systemmodell
werden dann alle Elemente eines Projektes (Quelltext, Compiler, Binder
etc.) und deren Abh"angigkeiten beschrieben.

\subsubsection{DSEE}

Ein typischer Vertreter dieser Kategorie ist DSEE\footnote{DSEE: ''
'' } \cite{whitgift}.  Es handelt sich hierbei um eine
Konfigurationsmanagementumgebung, die alle Phasen des
Entwicklungsprozesses unterst"utzt.  Die Abh"angigkeiten werden in
einer eigenen Beschreibungssprache abgelegt.  Sie werden in einem
halbautomatischen Verfahren erstellt: Zun"achst werden alle
Quelldateien nach typischen Phrasen (\#include, uses etc.) durchsucht
und ein erstes Systemmodell erstellt, welches dann manuell verfeinert
werden mu"s.  DSEE garantiert dabei keine Konsistenz zwischen dem
Systemmodell und den tats"achlichen Gegebenheiten, besonders nicht
nach "Anderungen an den Quelldateien.

DSEE selbst besteht aus vier Teilen:
\begin {description}
\item[History Manager] 
\begin{sloppypar}
speichert die verschiedenen Versionen und Varianten der Komponenten.
\end{sloppypar}

\item[Configuration Manager]
\begin{sloppypar}
definiert und erstellt die einzelnen Konfigurationen.  Die
Konfigurationen werden durch einen {\itshape configuration thread}\/
in einer eigenen Sprache beschrieben.  Er besteht aus einer Menge von
Regeln, die DSEE dazu benutzt, die entsprechenden Versionen zu finden.
\end{sloppypar}

\item[Task Manager und Monitor Manager] 
dienen zum "Uberwachen der "Anderungen an den Softwarekomponenten.
\end{description}

\subsubsection{Make, Imake, RCS, SCCS}

Im Gegensatz zu DSEE werden in der Praxis oft mehrere unterschiedliche
Werkzeuge zusammen genutzt, z.~B. Make zum "Ubersetzen \cite{make},
und RCS\footnote{RCS: \glqq Revision Control System \grqq}, oder
SCCS\footnote{SCCS: \glqq Source Code Control System \grqq} f"ur die
Versionskontrolle \cite{rcs, sccs}.  Imake baut seinerseits auf Make
auf, indem es aus einer Beschreibung, die unabh"angig von der
verwendeten Rechner-Architektur ist, Makefile-Dateien generiert
\cite{imake}.  Ein Makefile bildet die Eingabe f"ur Make und enth"alt
die Beschreibung der Abh"angigkeiten zwischen den betreffenden
Dateien.  Der Verbreitungsgrad von Imake ist aber insofern
beschr"ankt, als da"s spezielle Konfigurationsdateien f"ur das
jeweilige Projekt vorhanden sein bzw.\ erstellt werden m"ussen.  Das
Einsatzgebiet ist haupts"achlich im Umfeld des X Window Systems zu
suchen.

Das Problem bei diesem Ansatz ist, da"s nicht nur die einzelnen
Werkzeuge aufeinander abgestimmt werden m"ussen, sondern da"s diese
alle mit unterschiedlichen Systemmodellen arbeiten, was die
Integration erschwert.

Eine L"osung stellt die Field-Umgebung \cite{connect_tools} dar, die
verschiedene Werkzeuge unter einer grafischen Oberfl"ache integriert.
Ein zentraler Server nimmt Nachrichten von den verschiedenen
Werkzeugen auf und verteilt sie an die Schnittstelle andere Werkzeuge,
die an diesen Nachrichten interessiert sind ({\itshape selective
broadcasting}).  Diese Schnittstellen m"ussen f"ur jedes zu
integrierende Werkzeug neu erstellt werden und setzen die Nachrichten
in entsprechende Kommandos um.  So lassen sich auf flexible Art und
Weise existierende Systeme integrieren.  Dennoch m"ussen speziell auf
die Sprache abgestimmte Werkzeuge, mit denen man z.~B.\ den Stack zur
Laufzeit oder Variablenwerte grafisch visualisieren kann, neu
entwickelt werden.

\subsubsection{STONE}

Ein objektorientierter Ansatz wird mit dem
STONE-Projekt\footnote{STructured and OpeN Environment} verfolgt
\cite{generic_env}.  Ausgehend von der Beobachtung, da"s jedes neue
Software-Projekt meist auch neue Mechanismen zur Unterst"utzung des
Entwicklungsprozesses ben"otigt, wurde hier ein generischer und
erweiterbarer Kern ({\itshape software engineering
en\-vironment-frame/kernel}) geschaffen.  Dieser Kern integriert nun
weitere spezialisierte Werkzeuge, hier besonders aus der
Unix-Umgebung.  Diese treten dann als Methoden der entsprechenden
Software-Objekte auf.

\begin{figure}[ht]
\centering\mbox{\epsfig{file=stone.eps}}
\caption{Integration von Werkzeugen im STONE-System (aus \protect \cite{generic_env})}
\label{abb_stone}
\end{figure}

Die Software-Objekte werden als Klassen eines Typsystems beschrieben.
So ist es m"oglich beispielsweise einem C-Quelltext zus"atzliche
Attribute und Eigenschaften (Me\-thoden) mitzugeben.  Die Version
einer Datei kann so z.~B.\ als Attribut verwaltet werden.  Das
Typsystem selbst wird dabei mit Hilfe der objektorientierten Sprache
CHieF\footnote{Class Hierarchy Definition Facility} definiert, die
es erlaubt, die Abh"an\-gigkeiten zwischen den Objekten und deren
Methoden festzulegen.  Das Typsystem ist f"ur den Benutzer "uber eine
spezielle Shell zug"anglich (OShell), die wiederum als Basis f"ur eine
grafische Benutzeroberfl"ache dienen kann.  Einen groben "Uberblick
bietet Abbildung~\ref{abb_stone}.

\subsection {Zusammenfassung}

Betrachtet man die vorgestellten Ans"atze, so l"a"st sich folgendes
feststellen: Systeme, die in die zweite Kategorie (externer Ansatz)
fallen, bieten durch ein eigenes Systemmodell und die M"oglichkeit,
andere Werkzeuge zu integrieren, eine hohe Flexibilit"at und sind
einfacher zu erweitern.  Auch im Hinblick auf Projekte, die sich aus
Komponenten unterschiedlicher Programmiersprachen zusammengesetzen
({\itshape mixed-language systems}), haben sie deutliche Vorteile
gegen"uber integrierten Systemen, die auf eine Sprache festgelegt
sind.

