\section{Einleitung}

\subsection{Motivation}
Ein Programmierer, der sich in ein neues Softwaresystem einarbeiten m"ochte,
hat eine Reihe von Aufgaben vor sich. Er mu\ss\ sich einerseits mit der Syntax
und Semantik der Programmiersprache auseinandersetzen und sich andererseits in
die zugeh"origen Softwarebibliotheken einarbeiten. Bibliotheken sind ein
wichtiger Teil eines Softwaresystems, denn sie erlauben es, Programmcode
wiederzuverwenden und abstrakte Probleml"osungen auf neue Probleme anzuwenden
[Jung95].


Softwarebibliotheken gliedern sich meist in kleinere Einheiten (Module).
Diese Einheiten bestehen aus zwei Teilen, einer Schnittstelle (engl.
\textit{interface}) und einer Implementation. Die Schnittstelle beschreibt die
Menge der Funktionen und Datentypen, die eine Einheit exportiert.  Zu einer
Schnittstelle kann es auch mehrere Implementationen geben. Ziel dieser
Einheitenbildung ist es, logisch zusammenh"angenden Programmcode zu
implementieren bzw. zu beschreiben.  Manche Softwaresysteme erlauben es auch,
Bibliotheken rekursiv, d.h. aus anderen Bibliotheken aufzubauen.


Es kann zwischen zwei Arten von Programmierern als Anwender der
Bibliothekseinheiten unterschieden werden.  Anwendungsprogrammierer sind daran
interessiert, die von den Softwarebibliotheken angeboten Funktionen zu
verwenden. W"ahrend der Einarbeitung werden sie sich mit den
Schnittstellenbeschreibungen der Bibliotheken befassen und auseinandersetzen.
Die Aufgabe der Systemprogrammierer beinhaltet hingegen die Wartung und
Erweiterung der Bibliotheken. W"ahrend der Einarbeitung werden sie sich nicht
nur mit den Schnittstellenbeschreibungen, sondern auch mit den
Implementierungen besch"aftigen.

Ein Programmierer, der sich in eine Softwarebibliothek einarbeitet, wird als
erstes versuchen, sich einen "Uberblick zu verschaffen. Der
Anwendungsprogrammierer wird die Schnittstellenbeschreibungen der Einheiten
der Bibliothek betrachten und versuchen, Funktionen zu finden, mit deren Hilfe
er seine Anwendung implementieren kann. Der Systemprogrammier wird sich
hingegen auch die Implementierungen der Bibliothekseinheiten ansehen, da seine
Aufgabe die Wartung und Erweiterung der Bibliothek beinhaltet.

Da Bibliothekseinheiten auf anderen Bibliotheken basieren k"onnen, wird der
Programmierer bei der Betrachtung einer Schnittstellenbeschreibung oder einer
Implementation versuchen zu ermitteln, welche Funktion die aus anderen
Bibliothekseinheiten importierten Objekte haben. Er wird also den Beziehungen
innerhalb der Bibliothekseinheiten folgen und sich die jeweiligen
Schnittstellenbeschreibungen oder Implementierungen ansehen.

Der Aufwand zur Einarbeitung in eine Softwarebibliothek ist u.a. abh"angig von
der Anzahl ihrer Module und Schnittstellen und der Menge der Beziehungen, die
zwischen diesen bestehen.  Die Standardbibliothek des \emph{Tycoon}-Systems
beinhaltet beispielsweis 24 Module und 24 Schnittstellen. Bei einem
gesch"atzten Import von 150 Programmobjekten ergibt sich eine Menge von 7200
Beziehungen.

Ziel dieser Studienarbeit ist es, ein Werkzeug zu entwickeln, mit dessen Hilfe
die Einarbeitung in die Softwarebibliotheken des
\emph{Tycoon}\footnote{Tycoon: TYped COmmunicating Objects in open
  eNviroments.  \\
  Das \emph{Tycoon}-System wurde am Arbeitsbereich Datenbanken
  und Informationssysteme des Fachbereichs Informatik der Universit"at Hamburg
  entwickelt.

  }-Systems erleichtert wird. Das Werkzeug soll es erlauben, die Bez"uge der
Bibliothekseinheiten zueinander aufzul"osen und zu visualisieren.  Die
Bibliothekseinheiten werden im weiteren Module genannt.

Das Projekt gliedert sich in folgende Teile:
\begin{itemize}
\item Ermittlung der darzustellenden Beziehungen der Module.
\item Visualisierung der Beziehungen, d.h. Wahl der Darstellungsart und Wahl
  der Darstellungsmittel.
\end{itemize}


\subsection{Beziehungen} \label{kapBeziehungen}
Die Objekte einer Programmbeschreibung stehen miteinander in einer Vielzahl
von Beziehungen.  Eine Art von Beziehung ist die referentielle. Es wird
beispielsweise am Anfang des Programms eine Variable mit einem Bezeichner
assoziiert (Definition, Deklaration), die im weiteren Programm mit Hilfe des
Bezeichners referenziert wird.  Viele Programmiersprachen erlauben
kompliziertere referentielle Beziehungen als die direkte. Z.B. ist es m"oglich,
Namensr"aume (engl. \textit{scopes}) zu bilden und ineinander zu schachteln.  Referenzen
werden also nicht nur durch die Gleichheit von Bezeichnern aufgel"ost, es
m"ussen auch die zugeh"origen Namensr"aume in Beziehung stehen, wobei Objekte
"ubergeordneter Namensr"aume von lokalen Objekten verdeckt werden k"onnen
(siehe Abb. \ref{scope}). Die Aufl"osung der Referenzen ist also abh"angig von
der Sichtbarkeit der Objekte.

\begin{figure}[h]
  \centering{\includegraphics*{scope.eps}}
\caption{Referentielle Beziehungen}
\label{scope}
\end{figure}

Programme und Bibliotheken bzw. Module werden meist unter Verwendung anderer
Bibliotheken erstellt. Die Objekte der Programme, Biliotheken und Module
stehen also auch in Beziehung zueinander. Ein weiteres Beispiel f"ur die
Sichtbarkeit von Objekten ist ein Modul, welches zwei Funktionen beinhaltet,
wobei es eine exportiert und die andere nur lokal verf"ugbar ist (siehe Abb.
\ref{module}).

\begin{figure}[h]
  \centering{\includegraphics*{module.eps}}
\caption{Referentielle Beziehungen "uber Module}
\label{module}
\end{figure}


Die Art dieser Zusammenh"ange ist Teil der Semantik, wie sie im "Ubersetzer
bzw. der Spezifikation des "Ubersetzers definiert ist. Die meisten "Ubersetzer
l"osen w"ahrend des "Ubersetzens referentielle Zusammenh"ange bez"uglich
Variablen, Konstanten und Funktionen auf (\textit{static scoping}).

Es sind aber auch andere Arten von Beziehungen zwischen Objekten des
Programmcodes m"oglich. So bietet z.B. die Sprache \emph{TL}\footnote{TL:
  Tycoon Language.} des \emph{Tycoon}-Projektes das Konzept des
\emph{Subtypisierung}.  Typdefinitionen stehen hier nicht in einem referentiellen
Verh"altnis, sondern in einem strukturellen. Da diese Arten von Beziehungen
meist nicht explizit vom "Ubersetzer aufgel"ost werden, ist ihre Ermittlung
mit einem gr"o\ss eren Aufwand verbunden. Beispielsweise m"u\ss te in  \emph{Tycoon} 
prinzipiell jeder neu definierte Typ mit allen bereits definierten verglichen
werden, um festzustellen, mit welchem er in welcher Beziehung steht (Subtyp,
Supertyp, kein Bezug).

\subsection{Bezugsinformationen} \label{kapBezugsinformationen}
Objekte von Programmbeschreibungen stehen miteinander in Beziehungen.
Beziehungen k"onnen sich "uber mehrere oder "uber nur eine 
Programmbeschreibung erstrecken.  Die Information, die diese Beziehungen
beschreibt, ist die Bezugsinformation. Da Bezugsinformationen beliebige
Beziehungen der Objekte des Programmtextes beschreiben k"onnen sollen, bietet
sich ihre Darstellung als Relation im mathematischen Sinne an.  Aufgabe einer
solchen Relation ist es, Teile eines Programmtextes mit Teilen eines anderen
Programmtextes in Beziehung zu setzen. Die Menge, "uber die diese Relation
gebildet wird, besteht aus den Textpositionen einer Programmbeschreibung (und
der von ihr verwendeten Module). Die Bezugsinformationen innerhalb von und
zwischen Programmen lassen sich somit als Textpositionsrelationen darstellen.

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "quas"
%%% End: 

