\chapter{Modulverwaltung}
\pagenumbering{arabic}
\label{cha_modulverwaltung}

In diesem Abschnitt soll zun"achst der Begriff der Modulverwaltung
erl"autert werden.  Darauf aufbauend werden die daraus resultierenden
Aufgaben beschrieben, die erf"ullt werden m"ussen, um dem Begriff der
Modulverwaltung gerecht zu werden.  Am Ende dieses Kapitels werden
dann verschiedene Ans"atze vorgestellt und anhand kurzer Beispiele
gezeigt, auf welche Weise die Anforderungen an eine Modulverwaltung
erf"ullt werden k"onnen.

\begin{sloppypar}
Der Begriff der Modulverwaltung l"a"st sich in unterschiedlicher Weise
verstehen.  Zum einen kann er nur die rein rechnergest"utzte Seite
beinhalten, d.~h.\ man befa"st sich damit, die zur Umsetzung auf dem
Computer n"otigen Werkzeuge bereitzustellen.
\end{sloppypar}

Auf der anderen Seite kann man die Modulverwaltung auch in einer
ganzheitlichen Weise betrachten.  Dies f"uhrt dann zum Begriff des
Konfigurationsmanagements, der urspr"unglich aus dem Hardwaresektor
kommend nun auch auf Softwareobjekte Anwendung findet.  Deshalb findet
man in der Literatur auch h"aufig den Begriff {\itshape software
configuration management}.  Es geht hier au"ser um die rechnerm"a"sige
Umsetzung auch um die Rolle der beteiligten Personen, also Entwickler,
Tester usw., um die Vorg"ange, die von diesen Personen bearbeitet
werden und die Dokumente, die im Laufe dieser Vorg"ange erstellt
werden.

In der Literatur trifft man auf verschiedene Definitionen des Begriffs
Konfigurationsmanagement.  In \cite{babich} wird der Begriff eher
informell gefa"st als die Kunst, "Anderun\-gen an Software, die von
einem Team von Programmierern entwickelt wird, zu kontrollieren und zu
identifizieren.

\begin{sloppypar}
Eine formalere Definition kann in \cite{compton} gefunden
werden. Danach ist Software Konfigurations Management eine Menge von
technischen Abl"aufen, um Software w"ahrend ihrer gesamten Lebensdauer
zu dokumentieren.  Sie sollen sicherstellen, da"s alle "Ande\-rungen
aufgezeichnet werden und der momentane Zustand der Software bekannt
und reproduzierbar ist.
\end{sloppypar}

Dem IEEE-Standard 729 \cite{ieee729} nach wird
Konfigurationsmanagement wie folgt definiert: Konfigurationsmanagement
ist der Proze"s des Identifizierens und Definierens von Komponenten
eines Systems.  Es beinhaltet die Kontrolle "uber die "Anderungen an
diesen Komponenten w"ahrend ihrer Lebensdauer, das Aufzeichnen des
Zustandes und der "Anderungsanforderungen, au"serdem das Verifizieren
der Komponenten auf Vollst"an\-digkeit und Korrektheit.

Diese letzte Definition ist die allgemeinste der genannten.  Sie
l"a"st sich auf beliebige Systeme anwenden und ist damit nicht auf den
Bereich Softwareentwicklung beschr"ankt.

Um im folgenden eine klare Begrifflichkeit zu haben, wird
Konfigurationsmanagement als der aus der Literatur bekannte und
erl"auterte Begriff verwendet.  Modulverwaltung soll ausschlie"slich
den Bereich der Werkzeugunterst"utzung umfassen und ist damit klar von
dem gesamten Proze"s des Konfigurationsmanagements als Disziplin der
Softwaretechnologie ({\itshape software engineering}) /
Softwareentwicklung ({\itshape software development}) getrennt.

Diese Arbeit besch"aftigt sich haupts"achlich mit dem ersten Aspekt
der Modulverwaltung, also der Bereitstellung von geeigneten
Werkzeugen.  Die Grundlage bilden allerdings Anforderungen, die aus
der Sicht des Konfigurationsmanagements gewonnen wurden, da die hier
untersuchten und selbst entwickelten Werkzeuge letztendlich den
gesamten Proze"s des Konfigurationsmanagements unterst"utzen sollen.

Worum geht es bei Umsetzung der Modulverwaltung grunds"atzlich?  In
erster Linie geht es um die Verwaltung von Softwarekomponenten, die in
einem System zusammengefa"st sind.  Wichtig ist, da"s die
Komponenten dabei in Beziehungen mit unterschiedlicher Semantik
zueinander stehen k"onnen: 

\begin {itemize}
\item 
Beziehungen k"onnen beschreiben, da"s eine Komponente zum Bearbeiten
einer weiteren ben"otigt wird.  Als Beispiel sind hier Header-Dateien
in C zu nennen.

\item
Komponente k"onnen weitere Komponenten enthalten.  

\item 
Beziehungen k"onnen darin bestehen, da"s eine Komponente eine andere
benutzt.  In diese Kategorie fallen z.~B.\ Module in Tycoon, die in
der Importliste eines anderen Moduls stehen.

\item 
Eine Komponente kann aus einer anderen abgeleitet werden.  Der
klassische Fall hierf"ur ist die "Ubersetzung eines Quelltextes zu
einer Objektdatei.  Diese {\itshape "Uberset\-zung}\/ kann jedoch
durchaus auf manuellem Wege erfolgen.

\end{itemize}

Die Hauptaufgabe der Modulverwaltung besteht nun darin, die weitere
Entwicklung der in dem System enthaltenen Komponenten zu
unterst"utzen.  Des weiteren soll sie Werkzeuge zur Verf"ugung stellen,
die eine einfache Konstruktion des Systems erm"ogli\-chen.  Die
erw"ahnten Beziehungen spielen dabei eine bedeutende Rolle, da durch
sie zu einem Teil festgelegt wird, welche Werkzeuge "uberhaupt
ben"otigt werden.  G"abe es z.~B.\ nicht die M"oglichkeit, da"s eine
Komponente eine weitere benutzt, so g"abe es auch keine Notwendigkeit
f"ur ein Werkzeug, welches daf"ur sorgt, da"s diese Komponenten in
einer bestimmten Reihenfolge bearbeitet werden o."a.


\section{Aufgaben}

Um die o.~g.\ Ziele zu erreichen, sollen die Aufgaben, die von einer
Modulverwaltung zu erf"ullen sind, nun weiter verfeinert werden: Die
Ausf"uhrungen beruhen haupts"achlich auf \cite{whitgift},
\cite{notion} und \cite{tools_tichy}.

\subsection{Objektidentifikation}

\begin{sloppypar}
Objektidentifikation ({\itshape identification, item identification})
ist die Grundvoraussetzung, um mit irgendwelchen Objekten zu arbeiten,
da bekannt sein mu"s, welche Objekte "uber\-haupt in das System
eingehen.  Sie m"ussen einzeln identifizierbar sein.  Nur dann k"onnen
sie auch zu gr"o"seren Einheiten, wie etwa Konfigurationen oder
zusammengesetzten Objekten aggregiert werden, und umgekehrt kann nur
dann von einem Objekt auf sein "uber\-ge\-ordnetes verzweigt werden.
\end{sloppypar}

Die Objektidentifikation bildet die Grundlage f"ur die weiteren
Aufgaben.  So l"a"st sich z.~B.\ nur eine Version von einem Objekt
ableiten, das man auch benennen, identifizieren kann.  Auch das
Lokalisieren von Fehlern und besonders deren Beseitigung ist nur dann
m"oglich, wenn das entsprechende Objekt aufgefunden werden kann.

Auch f"ur die folgenden Punkte bildet die Objektidentifikation eine
wichtige Grundlage: die Frage, was sich an einem Objekt ge"andert hat,
allgemeiner ausgedr"uckt also die Entwicklung, die ein Objekt erfahren
hat.

\subsection{Versionierung}

\label{subsec_version}
Ein Objekt unterliegt im Laufe seiner Entwicklung einer Reihe von
"Anderungen, Erweiterungen und Verbesserungen; sie geben
gewisserma"sen seinen Lebenszyklus wieder.  Gleichzeitig kann es sein,
da"s von einem Objekt parallel mehrere Varianten, z.~B.\ f"ur
verschiedene Betriebssysteme, existieren.  Jeder dieser
Entwicklungsschritte sollte einzeln erfa"st und verf"ugbar sein.  Dies
ist n"otig, um z.~B.\ nach einer mi"slungenen "Anderung auf eine
fr"uhere Version zur"ucksetzen oder, um trotz weitergehender
Entwicklung einen Fehler in einer fr"uheren Version korrigieren zu
k"onnen.  Um f"ur verschiedene Varianten des Gesamtsystems die
richtige Version/Variante zu finden, mu"s es geeignete Mechanismen
geben.

Es ist auch eine Frage der Versionierung bzw. Versionsverwaltung
({\itshape version management, version selection and baselining}), ob
zwei verschiedene Entwickler an demselben Objekt unabh"angig
voneinander arbeiten k"onnen.

Ein weiterer Begriff ist die Baseline (s. zu diesen Ausf"uhrungen
\cite{buckle}).  Das Konzept der Baseline dient dazu, die Entwicklung
und Qualit"at eines Projektes me"sbar festzuhalten.  Eine Baseline
markiert eine Version als einen bestimmten Bezugspunkt innerhalb der
Entwicklung mit den folgenden Funktionen:

\begin{itemize}
\item
Sie bezeichnet einen me"sbaren Punkt innerhalb der Entwicklung.

\item
Sie stellt die Basis f"ur weitere Entwicklung und "Anderungskontrolle
dar.

\item
Sie ist ein Bezugspunkt f"ur die Zusicherung der Qualit"at und Eignung
f"ur den Einsatzzweck, bevor das System endg"ultig festgeschrieben
wird.

\end{itemize}

Eine Baseline mu"s sich nicht notwendigerweise auf Programmcode
beziehen.  Wie die folgenden Beispiele zeigen, kann sie durchaus auch
einen Punkt innerhalb der konzeptionellen Phase eines Projektes
widerspiegeln.

\begin{itemize}
\item
Vollst"andige Systemanforderungen ({\itshape total system
specification})

\item
Detaillierte Beschreibung des Softwareentwurfs ({\itshape detailed
software design})

\item
Erste ausgelieferte Version ({\itshape first-release version})

\end{itemize}

Eine beliebige Version wird also erst durch die Entscheidung eines
Entwicklers oder einer anderen verantwortlichen und autorisierten
Person zu einer Baseline und damit nicht durch einen
rechnergest"utzten Vorgang.  Es mu"s dennoch die M"oglichkeit geben,
diesen besonderen Status zu repr"asentieren.

\subsection{"Anderungsverwaltung}

Insbesondere bei Systemen, die aus mehreren hundert oder sogar tausend
Objekten bestehen und deren Objekte von mehreren Entwicklern und/oder
Teams bearbeitet werden, ist es notwendig und oft unverzichtbar, eine
genaue Buchf"uhrung "uber die durchgef"uhrten "Anderungen zu haben.
Sie sollte neben den ge"anderten Objekten und den beteiligten Personen
auch die notwendigen Schritte und Prozeduren zur Durchf"uhrung der
"Anderung protokollieren bzw.\ vorgeben.

Nicht nur die "Anderungen selbst m"ussen verzeichnet werden,
"Anderungsverwaltung ({\itshape change control, change tracking})
umfa"st weiterhin die M"oglichkeit, den Umfang einer "Anderung in
bezug auf die Anzahl der betroffenen Objekte im voraus abzusch"atzen
und nicht zuletzt die zust"andigen Entwickler zu informieren.

\subsection{Systemgenerierung}

\label{subsec_system}
Die Systemgenerierung ({\itshape building the system, software
manufacturing, regeneration}) erfordert eine Reihe unterschiedlicher
Schritte, wie Vor- und Nachbearbeitung, "Ubersetzen, Binden,
Formatieren usw.\ und die dazu erforderlichen Programme bzw.\
Prozeduren.  Die Modulverwaltung soll diese Transformationen
unterst"utzen und soweit wie m"oglich automatisieren.  Dabei mu"s
insbesondere das Folgende ber"ucksichtigt werden:

\begin{itemize}
\item
Die entsprechenden Werkzeuge m"ussen mit den richtigen Optionen
versorgt 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 geachtet werden mu"s.

\item
Fehlermeldungen oder Warnungen k"onnen w"ahrend der Transformation
auftreten.

\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, diese "uberlassen es dem Benutzer, 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 einer Ada Unit).  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.

\subsection{Bibliotheksverwaltung}

Der Aspket der Bibliotheksverwaltung ({\itshape library management,
rights and protection}) ist in \cite{notion} und \cite{whitgift}
genannt und hat nicht direkt mit dem Proze"s des
Konfigurationsmanagements bzw.\ der Modulverwaltung zu tun.  Es geht
hier vielmehr um die Sicherheit, mit der die Objekte der
Modulverwaltung gespeichert werden.  Dabei wird zum einen gefordert,
da"s die Objekte gegen zuf"allig oder absichtlich herbeigef"uhrten
Datenverlust gesichert sind.  Zum anderen geht es darum, Objekte vor
unbefugtem Zugriff zu sch"utzen.

Es existieren mehrere Modelle, nach denen der Zugriff auf die
Komponente eines Systems geregelt werden kann.  Der einfachste Ansatz
beruht auf den M"oglichkeiten, die das Betriebssystem gew"ohnlich
bereitstellt.  Jede Datei wird hier mit bestimmten Zugriffsrechten
belegt.

Eine Verbesserung bringt die Einf"uhrung von Benutzergruppen.  Jeder
Gruppe wird dabei eine Menge von Rechten zugeteilt, die ihm dann
entsprechenden Zugriff auf die Komponenten gew"ahrt.  Dies l"a"st sich
noch weiter verfeinern, indem einem Benutzer innerhalb einer
Komponente nur Rechte f"ur eine bestimmte Variante, z.~B.\ nur f"ur
ein Betriebssystem, verliehen werden.


\subsection{Konkurrierender Zugriff}

In gro"sen Systemen ist es praktisch unvermeidbar, da"s mehrere
Entwickler nicht nur am gleichen Projekt, sondern sogar an den
gleichen Objekten arbeiten, wobei die Aufgabenstellung durchaus
unterschiedlich sein kann.  Es ist dann die Aufgabe der
Modulverwaltung, zu verhindern, da"s mehrere unterschiedliche
"Anderungen am gleichen Objekt zum Verlust einer "Anderung oder zu
inkonsistenten Objekten f"uhren.  Durch die Verwaltung von
konkurrierenden Zugriffen ({\itshape managing simultaneous updates})
mu"s vielmehr daf"ur gesorgt werden, da"s alle "Anderungen in die neue
Version des Objektes einflie"sen.  Die Zusammenf"uhrung aller
"Anderungen kann meist nicht automatisch erfolgen, sondern in einem
halbautomatischen Proze"s, der wiederum durch gute Unterst"utzung
wesentlich erleichtert werden kann.




