\chapter{Systemstrukturierung}
\label{cha_strukturierung}

Der zweite Teil dieser Arbeit untersucht Konzepte zur Systemstrukturierung
anhand von Programmiersprachen, die in der Praxis weite Verbreitung gefunden
haben oder aufgrund ihrer Strukturierungskonzepte interessant sind.  Es werden
Sprachen aus unterschiedlichen Sprachklassen genauer untersucht.  Modula-2 steht
f"ur eine imperative Sprache mit einem Modulkonzept. Dagegen ist C++ ein
Vertreter einer objektorientierten Sprache, der ein Klassenkonzept in die
Sprache einf"uhrt.  C++ ist ferner durch die Abstammung von dem imperativen,
nicht objektorientierten C beachtenswert, da hierdurch gezeigt werden kann,
inwieweit C++ trotz dieser Abstammung geeignetere als die in C realisierten
Strukturierungskonzepte verwirklicht, ohne die Kompatibilit"at zu seinem
Vorl"aufer zu verlieren.  Schlie"slich wird das persistente Programmiersystem
Napier88 betrachtet.  Hier ist besonders der Vergleich mit den Sprachen {\tl}
bzw.\ {\tlmin} interessant, da eine Vielzahl der Konzepte wie orthogonale
Persistenz, statische strenge Typ"uberpr"ufung in beiden Systemen (Napier88 und
Tycoon) umgesetzt sind.  Eine Diskussion der im Rahmen dieser Arbeit
entwickelten Strukturierungskonzepte von {\tlmin} schlie"st sich in Kapitel
\ref{cha_strukturierung_tlmin} an.

Besonderes Augenmerk wird auf die Untersuchung von Sichtbarkeitsbereichen
gerichtet, da sie neben Bindungstechniken eine entscheidende Rolle bei der
Programmierung im Gro"sen und damit bei der Systemstrukturierung spielen.  Sie
geben dem Programmierer die M"oglichkeit, Bezeichner explizit sichtbar zu machen
oder zu verstecken und somit den geordneten Zugriff zu steuern.  Weiterhin
bedeutet die Kapselung von Bezeichnern in Modulen und Klassen eine Manipulation
von Sichtbarkeitsbereichen.  Bestimmte Namen werden beim Vorgang der Kapselung
versteckt, w"ahrend andere sichtbar sind bzw.\ bleiben.  Die Vorteile f"ur diese
Art der Programmierung k"onnen wie folgt zusammengefa"st werden
\cite{oose,studienarbeit}:

\begin{description}
\item[Separate "Ubersetzung:] Programme k"onnen in kleine "uberschaubare
  Einheiten (meist auf Dateiebene) zerlegt werden.  Im Vergleich zu
  monolithischen Systemen, die aus einer gro"sen Programmdatei bestehen und
  stets komplett "ubersetzt werden m"ussen, bietet separate "U\-bersetzung die
  M"oglichkeit, den "Ubersetzungsaufwand nach einer "Anderung gering zu halten.
  Es m"ussen nur die Programmteile neu "ubersetzt werden, die im
  Sichtbarkeitsbereich der ge"anderten Bezeichner liegen.  Dies ist meist nur
  eine kleinere Anzahl der zu einem System geh"orenden Einheiten, da andere
  Module, die nicht von der "Anderung betroffen sind, unver"andert bleiben
  k"onnen, da die ge"anderten Bezeichner dort nicht sichtbar sind und somit
  nicht benutzt werden k"onnen.

  Separate "Ubersetzung gew"ahrleistet dar"uber hinaus die Typkonsistenz, wie
  sie in einem monolithischen System zugesichert werden kann, "uber
  Modulgrenzen (Dateigrenzen) hinweg.

\item[Kapselung:] Hierunter versteht man das Zusammenfassen z.B.\ 
  eines Datentyps mit den auf ihn anwendbaren Funktionen in der Art,
  da"s nur "uber diese Funktionen auf den Zustand des Datentyps
  zugegriffen werden kann.  Die Integrit"at der gekapselten Daten und
  die Flexibilit"at in der zu w"ahlenden Implementierung k"onnen so in
  h"ochstem Ma"se gew"ahrleistet werden.  Die Manipulation der
  Sichtbarkeit einzelner Bezeichner eines Moduls erlaubt es, den
  geordneten Zugriff darauf zu steuern.

  Durch Kapselung ist es m"oglich, von Implementierungsdetails einer
  Softwareeinheit (Modul, Klassen o."a.) zu abstrahieren und sich auf
  das Wesentliche zu konzentrieren ({\itshape information hiding}), da
  nur die Bezeichner sichtbar sind, auf die zugegriffen werden darf
  und kann.  Dies ist eines der wichtigsten Hilfsmittel, um sicher und
  effizient gro"se Systeme zu entwickeln \cite{module}.  Da der
  Zugriff auf ein Modul nur "uber die Schnittstelle m"oglich ist, kann
  nicht auf die Implementierung Bezug genommen werden, die
  Implementierung ist sicher gegen"uber unerlaubtem Zugriff.  Die
  Schnittstelle eines Moduls kann als ein \glqq black box
  interface\grqq\ angesehen werden, das die Operationen usw.\ 
  spezifiziert.  Sie legt die Menge der sichtbaren Bezeichner fest.
  Die Implementierung ist vollst"andig im Implementationsteil
  enthalten und f"ur den Benutzer nicht zugreifbar.  Die Auswirkungen
  von "Anderungen lassen sich lokalisieren und somit die Wartbarkeit
  erh"ohen.  Die Lokalit"at erleichtert gleichzeitig die
  Wiederverwendung von Modulen, da die Abh"angigkeiten zwischen
  Modulen klar definiert sind und keine versteckten Beziehungen
  existieren.  Das steigert die Effizienz bei der Entwicklung gro"ser
  Systeme, da bereits existierende Softwarebausteine wiederverwendet
  werden k"onnen.

\item[Hierarchische Strukturierung:] Hierarchische Strukturierung
  unterst"utzt die Wartungsfreundlichkeit.  W"ahrend bei einer
  Programmiersprache wie C\footnote{In C sind alle nicht
    ausdr"ucklich als lokal zu einer Datei (\textit{static})
    definierten Variablen- und Funktionsbezeichner global in der
    gesamten "Ubersetzungseinheit sichtbar \cite{kernighan}.  Das
    liegt an der impliziten Deklaration von Bezeichnern als extern,
    also datei"ubergreifend.} 
%oder
%  Pascal\footnote{Modularisierungskonzepte wurden in einige sp"atere
%    Pascal-Dialekte, wie UCSD-Pascal \cite{ucsd_pascal} und Turbo
%    Pascal \cite{turbo_pascal}, eingef"uhrt.} 
  alle Prozeduren in einem globalen Sichtbarkeitsbereich definiert
  sind, kann der Programmierer durch Module strukturieren.  Er kann
  die Sichtbarkeitsbereiche der einzelnen Softwareeinheiten explizit
  steuern.  Dies hat haupts"achlich zwei Vorteile:

\begin{itemize}
\item Es kann durch Beschr"ankung der Menge der sichtbaren Bezeichner verhindert
  werden, da"s verschiedene Prozeduren sich in undisziplinierter Weise
  gegenseitig benutzen.  Stattdessen wird eine Benutzt-Relation zwischen den
  Modulen automatisch ein gerichteter, (normalerweise) azyklischer
  Graph\footnote{Sprachen, die ein Modul- oder Klassenkonzept unterst"utzen,
  schlie"sen nicht notwendigerweise die Existenz von zyklischen Abh"angigkeiten
  ihrer Strukturierungseinheiten aus.  In C sind z.B.\ zyklische Abh"angigkeiten
  zwischen Modulen nicht ausgeschlossen.}.

\item Die Wiederverwendung von Modulen bzw.\ Modulhierarchien wird erleichtert,
  da die verwendeten Module durch die Struktur der Abh"angigkeiten bekannt
  sind.  Das kommt vor allem dann zum Tragen, wenn Module wiederum in
  gr"o"seren Einheiten wie Bibliotheken zusammengefa"st werden k"onnen.

\end{itemize}

\item[Unabh"angige Entwicklung:] Die Verbindung mehrerer Softwareeinheiten
geschieht ausschlie"slich "uber die Schnittstelle dieser Einheiten.  F"ur die
Implementierung ist es ausreichend, die Schnittstellen aller benutzten Einheiten
zu kennen.  Das Ausprogrammieren verschiedener Softwareeinheiten kann v"ollig
unabh"angig voneinander geschehen, wenn die Schnittstellen festgelegt sind.  Das
bedeutet, da"s die Softwareeinheiten parallel von mehreren Personen gleichzeitig
entwickelt werden k"onnen.  Das f"uhrt zu einer Effizienzsteigerung, wenn die
Schnittstellen festgeschrieben werden und sich nicht oder kaum "andern.

\end{description}

Um die Vergleichbarkeit der Strukturierungsmechanismen der einzelnen
untersuchten Sprachen zu gew"ahrleisten, wird im nachfolgenden Abschnitt
zun"achst eine grafische Notation zur Beschreibung von Sichtbarkeitsbereichen
eingef"uhrt.  Diese wird auch im Kapitel \ref{cha_strukturierung_tlmin}
eingesetzt, um die dort pr"asentierten Strukturierungsmechanismen darzustellen
und mit den hier beschriebenen in Beziehung zu setzen.

\section{Notation}
\label{sec_notation}
Mit der in diesem Abschnitt eingef"uhrten Notation und den darauf aufbauenden
Untersuchungen wird ein Ziel verfolgt.  Es soll aus den vorgestellten
Strukturierungsmechanismen der hier behandelten Sprachen Ideen und Konzepte f"ur
die in {\tlmin} implementierten Strukturierungsmittel, die in Kapitel
\ref{cha_strukturierung_tlmin} behandelt werden, gezogen werden.  Die Notation
sichert dabei die Vergleichbarkeit der verwendeten Konzepte zu.

Zum Verst"andnis und zur Klarheit der nachfolgenden Diskussion werden an dieser
Stelle zu\-n"achst einige Begriffe definiert, die im folgenden Benutzung finden
(vgl. Abbildung \ref{abb_grnotation}).

\begin{description}
\item[Namen] (auch Bezeichner genannt) dienen dazu, Objekte zu identifizieren 
  und auf sie zuzugreifen.  Nur benannte Objekte k"onnen auch
  referenziert werden.  Die M"oglichkeit, Namen f"ur Objekte zu vergeben, ist
  die Grundvoraussetzung f"ur die Diskussion "uber Sichtbarkeitsbereiche.  Es
  ist f"ur diese Untersuchung jedoch unerheblich, ob es f"ur ein Objekt mehrere
  Namen gibt (Alias), welchen Typ das benannte Objekt hat bzw.\ ob es ein Typ
  ist.

  Sowohl in der grafischen Notation, als auch in der Diskussion um
  Sichtbarkeitsbereiche wird nicht zwischen Deklaration und Definition eines
  Bezeichners unterschieden, wie dies z.B.\ in C getan wird.  Das ist darin
  begr"undet, da"s hier nur die Einf"uhrung von Namen betrachtet wird, die von
  beiden Operationen durchgef"uhrt wird.  Die dar"uber hinaus anhaftende Semantik
  ist f"ur die Betrachtung der Systemstrukturierung nicht relevant.

\item[Sichtbarkeitsbereiche] definieren die Menge an sichtbaren, d.h.\ 
  "uber den Namen referenzierbaren Objekten innerhalb eines
  Ausdrucks oder einer Anweisung.  Sichtbarkeitsbereiche werden gew"ohnlich
  innerhalb von Bl"ocken definiert \cite{louden}.

\item[G"ultigkeitsbereiche] von Bezeichnern erstrecken sich von ihrer
  Einf"uhrung "uber eventuell geschachtelte Bl"ocke bis zum Ende des Blocks, 
  d.h.\
  bis zur Grenze des Sichtbarkeitsbereichs\footnote{Ein Sichtbarkeitsbereich,
    der keine Sichtbarkeitsgrenze besitzt, kann alle Bezeichner seines
    "ubergeordneten Bereichs sehen und gibt alle hinzugef"ugten Bezeichner an
    diesen weiter.  Er ist damit "uberfl"ussig.}.  Dies wird in Abbildung
  \ref{abb_grgueltig} anhand der in Abbildung \ref{abb_grnotation}
  vorgestellten grafischen Notation schematisch verdeutlicht.  Mit
  G"ultigkeitsbereich ist abweichend zu \cite{louden} gerade der Bereich
  gemeint, in dem der entsprechende Bezeichner erreichbar ist.  Durch
  Namensgleichheit verdeckte Bezeichner befinden sich also nicht im
  G"ultigkeitsbe\-reich.

\item[Lebensdauer] bezeichnet den Zeitraum, in dem das Objekt oder der Wert,
  der "uber einen Bezeichner referenziert wird, vorhanden ist.  Mit der
  Notation aus Abbildung \ref{abb_grnotation} wird "uber die Lebensdauer keine
  Aussage getroffen.  Das mit einem Namen assoziierte Objekt kann auch dann
  noch \glqq leben\grqq , wenn der Name nicht mehr g"ultig ist.  Das ist z.B.
  bei Bezeichnern innerhalb eines Moduls bei Modula-2 der Fall.  
  Lebensdauer ist ein Begriff, der sich auf tats"achlich existierende Objekte
  bezieht, f"ur die auch Speicherplatz reserviert wird.  Z.B.\ kann bei einer
  Verzweigungsmarke (\textit{case label}) nicht von Lebensdauer gesprochen
  werden.  Der wesentliche Unterschied zwischen Lebensdauer und Sichtbarkeit
  ist demnach: Die Lebensdauer betrifft die Eigenschaft und die Behandlung
  eines Objekts zur Laufzeit, ist also eine dynamische Gr"o"se.  Die
  Sichtbarkeit beschreibt statisch die Erreichbarkeit von Namen, die auf
  Objekte verweisen.

\end{description}

%\afterpage{\clearpage
\begin{figure}[H]
\centering\mbox{\epsfig{file=../Zeichnung/grnotation.eps}}
\caption{Grafische Notation zur Beschreibung von Sichtbarkeitsbereichen.}
\label{abb_grnotation}
\end{figure}
%}

"Uber spezielle Sprachmechanismen gibt es in vielen Programmiersprachen die
M"oglichkeit, den Sichtbarkeitsbereich explizit einzuschr"anken bzw. selektiv
Bezeichner in den Sichtbarkeitsbereich einzuf"uhren.  Die durch die
Sichtbarkeitsbereiche definierte Menge an Bezeichnern kann demnach auf
kontrollierte Weise sowohl zu- als auch abnehmen.  Dem ist in der hier
verwendeten grafischen Notation Rechnung getragen.  Die Notation erlaubt es
nicht, die Lebensdauer eines
Bezeichners darzustellen.  Ihre beschreibende Wirkung bezieht sich
ausschlie"slich auf statische Aspekte.

%\afterpage{\clearpage
\begin{figure}[H]
\centering\mbox{\epsfig{file=../Zeichnung/grgueltig.eps}}
\caption{G"ultigkeit eines Bezeichners.}
\label{abb_grgueltig}
\end{figure}
%}

Die hier pr"asentierte Notation ist bewu"st einfach gehalten.  Das Hinzuf"ugen
neuer Bezeichner wird z.B.\ durch Wiedergabe des entsprechenden Programmcodes
verdeutlicht und nicht durch weitere grafische Elemente.  Die Vergleichbarkeit
verschiedener Sichtbarkeitssituationen ist damit nicht unbedingt gegeben, der
Schwerpunkt der Notation liegt jedoch auf der Untersuchung von
Sichtbarkeitsgrenzen und deren Lage sowie auf Bezeichnern, die diese Grenzen
implizit oder explizit durch Sprachkonstrukte gesteuert durchdringen.  Es wurde
daher darauf verzichtet, in den nachfolgenden Abschnitten alle
sichtbarkeitsrelevanten Konstrukte einer Sprache zu untersuchen und in der
grafischen Notation abzubilden.

\section{C++}
C++ ist eine Sprache, die sich seit ihrer Einf"uhrung in einer
andauernden Entwicklung befindet.  Dies dokumentieren nicht zuletzt
die verschiedenen Standardentw"urfe der ANSI X3J16- und ISO
WG21-Organisationen.  Grundlage f"ur diesen Abschnitt stellt die
Referenz in \cite{stroustrup} dar.

Wie in \cite{stroustrup} beschrieben, nimmt C++ f"ur sich in Anspruch, die von
C bekannten Defizite bei der Programmierung im Gro"sen zu beseitigen, in dem es
Modularisierung und streng typisierte Schnittstellen anbietet.  Auch die
Programmierung im Team wird durch diese Konstrukte unterst"utzt.

In C++ stehen auf verschiedenen Abstraktionsebenen unterschiedliche Konstrukte
zur Verf"u\-gung, die im folgenden kurz besprochen und im Hinblick auf die
damit verbundenen Manipulationen der Sichtbarkeitsbereiche untersucht werden.
Es stehen vier grundlegende Sichtbarkeitsbereichskonstruktionen (Bl"ocke,
Funktionen, Klassen und Dateien) zur Verf"ugung.  Erg"anzt werden sie durch das 
im neuesten Standardentwurf vorgestellte Konstrukt zur expliziten Manipulation
von Namensr"aumen (\textit{namespace}).

\subsection{Bl"ocke}
\label{subsub_bloecke}
In C++ bilden Bl"ocke neben Klassen eine grundlegende Strukturierungseinheit.
Sie haben die f"ur blockstrukturierte Sprachen "ubliche in Abbildung
\ref{abb_grcblock} gezeigte Semantik, da"s alle au"serhalb definierten und
deklarierten Bezeichner innerhalb des Blocks sichtbar sind, alle innerhalb
definierten jedoch au"serhalb nicht.

%\afterpage{\clearpage
\begin{figure}[htb]
\centering\mbox{\epsfig{file=../Zeichnung/grcblock.eps}}
\caption{Sichtbarkeitsbereich eines Blocks in C++.}
\label{abb_grcblock}
\end{figure}
%}

\subsection{Funktionen}
Funktionen sind ein Mechanismus, um C++-Programme in kleinere Teile zu
zerlegen und damit in Verbindung mit Parametrisierung die Wiederverwendbarkeit
zu f"ordern.  Im Gegensatz zu anderen objektorientierten Programmiersprachen
k"onnen in C++ Funktionen auftreten, die nicht an Klassen gebunden sind.

Funktionen erlauben die "Ubergabe einer beliebigen Anzahl von Parametern, die
auf verschiedene Weise erfolgen kann:

\begin{description}

\item[Per Wert:] Die Funktion erh"alt eine Kopie des "ubergebenen Wertes.
"Anderungen des Wertes haben keine Auswirkungen au"serhalb der Funktion.

\item[Per Zeiger:] In diesem Fall wird keine Kopie angelegt, sondern direkt auf
der betroffenen Variable gearbeitet.

\item[Per Referenz:] In der Wirkung ist die "Ubergabe per Referenz mit der per
Zeiger identisch.  Im Unterschied zu dieser wird die Variable jedoch
syntaktisch wie ein Wertparameter behandelt, es wird also ohne Inhalts- und
Adre"soperator gearbeitet.

\end{description}

F"ur Parameter k"onnen Standardwerte vorgegeben werden.  Funktionen lassen sich
somit mit variabler Parameteranzahl aufrufen.  Dies erlaubt es, eine Funktion um
Parameter zu erweitern, ohne da"s alle Funktionsaufrufe angepa"st werden
m"ussen.  Die fehlenden Argumente werden mit den angegebenen Standardwerten
gef"ullt.

Funktionen k"onnen "uberladen werden.  Das bedeutet, da"s es Funktionen mit
gleichem Namen, jedoch mit Parametern unterschiedlichen Typs und in
unterschiedlicher Anzahl geben kann.  Anhand der Funktionssignaturen
entscheidet der Compiler, welche Funktion tats"achlich aufgerufen wird.

%\afterpage{\clearpage
\begin{figure}[H]
\centering\mbox{\epsfig{file=../Zeichnung/grcfun.eps}}
\caption{Sichtbarkeitsbereich einer Funktion in C++.}
\label{abb_grcfun}
\end{figure}
%}

Bezogen auf die in Abbildung \ref{abb_grcfun} dargestellte
Sichtbarkeitssituation einer Funktion gibt es eine Ausnahme.  Dabei handelt es
sich um Marken (\textit{labels}), die an beliebiger Stelle innerhalb der
Funktion definiert werden k"onnen, jedoch im gesamten Funktionsrumpf sichtbar
sind.  Ihr G"ultigkeitsbereich erstreckt sich auf einen Bereich vor ihrer
Definition.

Aus Abbildung \ref{abb_grcfun} geht hervor, da"s der Funktionskopf au"serhalb
des "au"sersten abgeschlossenen Sichtbarkeitsbereichs liegt.  Der Funktionsname
ist deshalb f"ur nachfolgende Ausdr"ucke auf dieser Sichtbarkeitsebene
erreichbar.  Die Parameter sind nur innerhalb der Funktion sichtbar, sie werden
durch den sie umschlie"senden Sichtbarkeitsbereich nicht nach au"sen
weitergegeben.  Der Funktionsrumpf entspricht einem Block, wie er in Abschnitt
\ref{subsub_bloecke} vorgestellt wurde.  Die gleiche Sichtbarkeitssituation
k"onnte auch mit nur einem Block erreicht werden, an dessem Anfang die
Parameternamen bekannt gemacht werden.  Konzeptuell erfolgt die Bindung der
Aktual- an die Formalparameter jedoch vor Betreten des Funktionsrumpfes
\cite{kernighan}.

\subsection{Klassen}
Klassen sind in C++ benutzerdefinierte Typen.  Sie stellen das auf der h"ochsten
Abstraktionsebene angesiedelte Strukturierungskonzept der Sprache
dar\footnote{Templates, die vom Abstraktionsniveau noch h"oher als Klassen
  angeordnet werden m"u"sten, werden in dieser Arbeit nicht betrachtet.}.
Abbildung \ref{abb_grcclass} zeigt das Szenario der Sichtbarkeitsbereiche einer
Klasse. Klassen k"onnen geschachtelt werden.

%\afterpage{\clearpage
\begin{figure}[htb]
\centering\mbox{\epsfig{file=../Zeichnung/grcclass.eps}}
\caption{Sichtbarkeitsbereiche einer Klassendeklaration und -definition in C++.}
\label{abb_grcclass}
\end{figure}
%}

Durch die verwendete Notation kann nicht die volle Semantik dargestellt werden.
Z.B.\ k"on\-nen die unter \textit{private} aufgef"uhrten Bezeichner nur in
\textit{friend} Klassen verwendet werden.  Im Zusammenhang mit Vererbung
existiert in C++ ein weiterer Zugriffsspezifizierer.  So k"onnen Objekte mit
\textit{protected} nur dem Zugriff von abgeleiteten Klassen, nicht jedoch von
benutzenden Klassen zug"anglich gemacht werden.  Die Schl"us\-selworte
\textit{public}, \textit{private} und \textit{protected} geben an, welche Klasse
die spezifizierten Bezeichner vererben, importieren bzw.\ benutzen d"urfen.
Weiterhin kann die Definition von Mitgliedern einer Klasse textuell getrennt von
der Deklaration erfolgen.  Von diesem Tatbestand wurde hier abstrahiert.
Syntaktisch kann die Definition einer Mitgliedsfunktion mit Hilfe des
Resolutionsoperators \textit{::} au"serhalb der Klassendeklaration formuliert
werden.  Die Deklaration einer Klasse folgt damit streng dem Prinzip der
Lokalit"at.  Die Definition, also die Implementierung, kann jedoch verstreut
"uber beliebig viele Dateien erfolgen.

Eine Klassendeklaration f"uhrt eine Reihe von neuen Namen ein.  Au"serhalb
einer Klassendeklaration kann jeder Bezeichner der Klasse durch Qualifizierung
erreicht werden, sofern der Zugriff erlaubt ist.  Spezielle syntaktische
Konstrukte zum Einf"uhren von Namen existieren f"ur Klassen nicht; ben"otigte
Bezeichner werden bei Bedarf benutzt.  Bei der Verwendung von Vererbung werden
die in den Basisklassen enthaltenen Namen sichtbar.  Abbildung
\ref{abb_vererbung} zeigt eine abgeleitete Klasse mit ihrer Basisklasse.
Klasse \textit{abgeleitet} hat die zus"atzlichen Mitglieder \textit{a} und
\textit{b}.  Beide Bezeichner wurden durch Angabe der Basisklasse in den
Sichtbarkeitsbereich des Klassenrumpfes eingef"uhrt.

%\afterpage{\clearpage
\begin{figure}[H]
\hrule
\vskip \baselineskip
\begin{verbatim}
class basis {
public:
  int a, b;
};

class abgeleitet : public basis {
public
  int c;
};
\end{verbatim}
\hrule
\caption{Abgeleitete Klasse in C++.}
\label{abb_vererbung}
\end{figure}
%}


Abweichende Situationen entstehen, wenn Datenattribute oder Methoden der Klasse
als statisch (\textit{static}) deklariert sind.  Statische Datenattribute sind
pro Klasse nur einmal vorhanden.  Somit existieren sie f"ur alle Instanzen der
Klassen nur einmal.  Ihre Eigenschaft, statisch zu sein, hat keinen Einflu"s
auf ihre Sichtbarkeit.  Anders bei statischen Methoden: Sie unterscheiden sich
von nichtstatischen Methoden dadurch, da"s es ebenfalls nur eine Methode f"ur
alle Instanzen der Klasse gibt, d.h., da"s sie keine implizite Selbstreferenz
auf die Instanz ({\itshape this pointer}) besitzen.  Das bedeutet auch, da"s
sie sich nur auf ebenfalls statische Attribute und Methoden der Klasse beziehen
k"onnen.  In diesem Fall hat die Benutzung von \textit{static} Einflu"s auf die
Sichtbarkeit der betroffenen Methode.  Dies kann in der hier benutzten Notation
nur unzureichend dargestellt werden.

\subsection{Dateien}
C++-Programme werden "ublicherweise nicht in einer gro"sen Datei abgelegt,
sondern in mehrere kleinere Dateien, auch als Module bezeichnet, aufgeteilt.
Die Aufteilung in Schnittstellen- und Implementationsdateien ist willk"urlich
und wird durch den "Ubersetzer nicht erzwungen.  Demzufolge ist die Aufteilung
in Schnittstellendateien (C++ Header-Dateien) und in Implementationsdateien
reine Programmiererdisziplin.

Das Handhaben der Programmdateien wird durch Pr"aprozessor-Anweisungen
geregelt.  Die angegebenen Dateien werden durch den Pr"aprozessor textuell
expandiert, so da"s der Compiler stets nur einen kontinuierlichen Zeichenstrom 
verarbeitet.  Dateien legen jedoch die Sichtbarkeit der darin definierten und
deklarierten Bezeichner fest.  So sind mit \textit{static} definierte
Bezeichner nur innerhalb der Datei sichtbar, in der sie definiert sind.
Entsprechend k"onnen mit \textit{extern} definierte Namen datei"ubergreifend
referenziert werden.

\subsection{Namensr"aume}
In dem neuesten Standardentwurf f"ur C++ existiert mit dem \textit{namespace}
Konstrukt die M"oglich\-keit, Namen, die anderenfalls global w"aren, in
Namensr"aumen zusammenzufassen.  Zu diesen globalen Namen z"ahlen z.B. alle
Bezeichner, die auf der obersten Sichtbarkeitsebene einer Datei deklariert oder
definiert werden.  An anderer Stelle k"onnen diese Namen "uber eine
\textit{using} Klausel explizit eingef"uhrt und benutzt werden, wobei dies
qualifiziert oder unqualifiziert geschehen kann.  Namensr"aume k"onnen
geschachtelt werden.

Namensr"aume konstruieren neue Sichtbarkeitsbereiche.  Sie f"uhren neue Namen
ein.  So wird durch die folgende Anweisung ein neuer Sichtbarkeitsbereich
aufgebaut.  Die darin definierten Namen sind in ihrer Sichtbarkeit jedoch nicht
eingeschr"ankt:

\begin{quote}
\begin{verbatim}
namespace A {
       class String { ... };
       void f(String);
}
\end{verbatim}
\end{quote}

Was in dieser Anweisung geschieht, ist, da"s die Klasse \textit{String}
au"serhalb der Namensraumdefinition durch

\begin{quote}
\begin{alltt}
A::String
\end{alltt}
\end{quote}

\noindent
benutzt werden kann, somit einen weiteren kontextabh"angigen Namen besitzt.
Die Klasse hat innerhalb der Namensraumdefinition den Namen \textit{String},
der nach seiner Deklaration referenziert werden kann.  Alternativ kann mit

\begin{quote}
\begin{alltt}
using A::String
\end{alltt}
\end{quote}

\noindent
die Klasse \textit{String} unter ihrem unqualifizierten Namen in einem anderen
Namensraum verf"ugbar gemacht werden.

Bezeichner k"onnen "ahnlich wie bei Klassen auch au"serhalb des Namensraums
definiert werden, indem sie mit Hilfe des Resolutionsoperators formuliert
werden.  Sie werden vom Compiler so behandelt, als ob sie innerhalb des Blockes
geschrieben wurden.  Die M"oglichkeit, Definitionen au"serhalb des Namensraums zu
formulieren, erschwert es, die "Uber\-sicht in einem Programm zu behalten, und
verst"o"st gegen das Prinzip der Lokalit"at.

%\bigskip
%C++ verf"ugt "uber mehrere Konzepte zur Verwaltung von Namen und
%Sichtbarkeitsbereichen.  Der im neuen Standardentwurf hinzugekommene Namensraum
%f"ugt ein weiteres Schema zur Benennung hinzu, l"ost jedoch keine
%Strukturierungsaufgaben, die bei der potentiell hohen Anzahl von Namen auf
%globaler Ebene durch Namenskonflikte auftreten k"onnen.


\section{Modula-2}
Modula-2 ist eine blockstrukturierte Programmiersprache, die von Pascal
abstammt und u.a.\ ein Modulkonzept einf"uhrt.  Dieses Modulkonzept bzw.\ die
damit einhergehenden Auswirkungen auf die Sichtbarkeit von Bezeichnern werden
in diesem Abschnitt genauer untersucht.  Funktionen und Bl"ocke dienen in
Modula-2 ebenfalls der Systemstrukturierung, werden hier jedoch aufgrund der
"Ahnlichkeit zu Funktionen und Bl"ocken in C++ nicht betrachtet.

\subsection{Module}
Module sind das wichtigste Abstraktionsmittel von Modula-2 \cite{dalcin}.  Sie
erlauben es, ein Programm in voneinander unabh"angige und separat "ubersetzbare
Einheiten zu zerlegen.  Sie lassen sich in einen Definitions- und einen
Implementationsteil aufspalten.  Der Definitionsteil erlaubt es, Module zu
programmieren, ohne da"s die Implementation der referenzierten Module bereits
existieren mu"s.

%\afterpage{\clearpage
\begin{figure}[htb]
\centering\mbox{\epsfig{file=../Zeichnung/grmmodul.eps}}
\caption{Sichtbarkeitsbereiche eines Moduls in Modula-2.}
\label{abb_grmmodul}
\end{figure}
%}

Abbildung \ref{abb_grmmodul} zeigt das Sichtbarkeitsszenario eines Moduls.  Die
Menge an Namen, die ein Modul exportiert, wird bei einem externen Modul durch
das Definitionsmodul bestimmt.  In einem internen Modul, wie es in Abbildung
\ref{abb_grmmodul} dargestellt ist, geschieht dies durch die Angabe von Namen
in der \textit{export}-Klausel.

Module k"onnen geschachtelt werden.  F"ur die Sichtbarkeit der Bezeichner
ergibt sich dadurch jedoch keine neue Situation.  In der grafischen Notation
kann diese Schachtelung auf nat"urliche Weise durch Schachtelung der
entsprechenden Objekte dargestellt werden (s.\ Abbildung
\ref{abb_grmschachtelung}).  Daraus ergibt sich, da"s ein lokales Modul nur die
Bezeichner importieren kann, die im umschlies\-senden Modul sichtbar sind.  Die
Module \textit{C} und \textit{D} in Abbildung \ref{abb_grmschachtelung} k"onnen
keine Bezeichner direkt aus \textit{A} oder \textit{B} importieren, sondern nur,
wenn diese Bezeichner auch von Modul \textit{E} importiert werden. Geht man von
einem Modell aus, in dem sich alle verf"ugbaren, nicht geschachtelten Module in
einem Namensraum befinden, so k"onnen Module nur aus dem direkt sie umgebenden
Namensraum importieren.  Auf dem globalen Namensraum ist keine Reihenfolge der
Namen definiert, was zyklische Abh"angigkeiten prinzipiell m"oglich macht.  In
Darstellung \ref{abb_grmschachtelung} sind die Module \textit{A} und \textit{B}
zyklisch voneinander abh"angig.

%\afterpage{\clearpage
\begin{figure}[htb]
\centering\mbox{\epsfig{file=../Zeichnung/grmschachtelung.eps}}
\caption{Geschachtelte Module mit Importbeziehungen in Modula-2.}
\label{abb_grmschachtelung}
\end{figure}
%}

\bigskip
Modula-2 bietet auf Sprachebene ein strukturiertes Konzept, das Modulkonzept, an,
das die Sichtbarkeit von Namen eindeutig regelt.  F"ur die Programmierung gro"ser
Systeme fehlt jedoch ein weiteres Konzept, um Module zu verwalten und zu
organisieren.  Geschachtelte Module k"onnen diese Aufgabe nur unzureichend
erf"ullen, da das zugrundeliegende Benennungsschema unflexibel ist.  Auch
Umstrukturierungen lassen sich schon durch die auch rein textuelle Schachtelung
von Modulen schwer bewerkstelligen.

\section{Napier88}
Bei Napier88 handelt es sich wie bei {\tlmin} um eine persistente
Programmiersprache mit einem polymorphen Typsystem und der Unterst"utzung von
Funktionen h"oherer Ordnung \cite{napier88}.  Im Kontext von Napier88 wurde an
der Universit"at von St.\ Andrews ein Schwerpunkt auf die Untersuchung der
Implikationen und M"oglichkeiten einer persistenten Sprache auf
Softwareentwicklungsumgebungen gelegt \cite{possibilities,morrison}.  Die genaue
Examinierung der Sprachkonstrukte, die Sichtbarkeitsbereiche ber"uhren, wie
z.B.\ Bl"ocke, Funktionen usw., kann hier aufgrund der "Ahnlichkeit zu {\tlmin}
entfallen.

Das Augenmerk dieses Abschnittes wird auf die in \cite{environment} in Napier88
eingef"uhrten Umgebungen (\textit{environments}) gelegt.  Zwar weisen sie
ebenfalls "Ahnlichkeiten mit den in Abschnitt \ref{sec_umgebung} vorgestellten
Umgebungen des {\tlmin} Systems auf, unterscheiden sich von diesen jedoch in
einigen wichtigen Punkten.

\subsection{Umgebungen}
Umgebungen sind ein fester Bestandteil der Programmiersprache Napier88 und
Objekte erster Klasse.  Umgebungen erm"oglichen das Speichern und Verwalten von
Bindungen durch die folgenden Operationen:

\begin{itemize}
\item Leere Umgebung erzeugen.
\item Umgebung um eine Bindung erweitern.
\item Den Wert einer Bindung extrahieren.
\item Eine Bindung aus einer Umgebung entfernen.
\end{itemize}

Umgebungen k"onnen in Ausdr"ucken dazu benutzt werden, Namen einzuf"uhren und
zu benutzen, wie das folgende Beispiel zeigt:

\begin{quote}
\begin{alltt}
\textbf{use} new \textbf{as} a:int \textbf{in}
\textbf{begin}
  writeint(a)
\textbf{end}
\end{alltt}
\end{quote}

\noindent
Der Name \textit{a} wird in der nachfolgenden Sequenz benutzt.  Er wurde aus
der Umgebung \textit{new} projiziert.  Durch die Angabe der Signatur bleibt
dieser Mechanismus typsicher.  Die Typkorrektheit kann jedoch nicht statisch
zugesichert werden.  Bei Auftreten einer \textit{use}-Klausel mu"s die unter
dem angegebenen Namen aufgefundene Bindung gegen die Signatur gepr"uft werden.
Dies impliziert, da"s f"ur jede Bindung einer Umgebung dynamische
Typinformation bereitsteht.  Beim Fehlschlagen des Typtests mu"s eine Ausnahme
ausgel"ost werden.

%\afterpage{\clearpage
\begin{figure}[H]
\centering\mbox{\epsfig{file=../Zeichnung/grnenv.eps}}
\caption{Sichtbarkeitssituation bei der Einf"uhrung eines Bezeichners aus einer Umgebung.}
\label{abb_grnenv}
\end{figure}
%}



%\section{Eiffel}
%Wie C++ ist auch Eiffel eine objektorientierte Sprache.  Im Gegensatz zu jener
%ging Eiffel nicht aus einer imperativen Sprache wie C hervor bzw.\ stellt eine
%Erweiterung einer solchen dar, sondern wurde vielmehr v"ollig neu entworfen.
%Von Eiffel kann somit ein saubereres Sprachdesign erwartet werden als von C++.
%Ein weiterer Grund f"ur die Auswahl von Eiffel zur Behandlung in dieser Arbeit
%ist die von ihrem Autor gew"ahlte ganzheitliche Herangehensweise an den Proze"s
%der Softwareentwicklung.  Ausgehend von Methoden und Prinzipien zur
%Softwareentwicklung wird Eiffel als eine zur Verfolgung dieses Ansatzes
%geeignete Sprache vorgestellt \cite{}.  Dar"uber hinaus stellt die in
%\cite{ooenv} vorgestellte Entwicklungsumgebung ein weiteres Hilfsmittel zur
%Programmierung dar, welches im Gegensatz zu Entwicklungsumgebungen f"ur andere
%Sprachen sehr eng mit der verwendeten Sprache verkn"upft ist.  Diese Umgebung
%unterst"utzt durch von ihr verwaltete Beschreibungen zum Zusammensetzen von
%Klassen die Strukturierung und wird deshalb in die Betrachtung einbezogen.


%Ace, Lace

%>>> Durch die Behandlung der Umgebung von Eiffel wird auf die nachfolgenden
%>>> Kapitel ueber Entwicklungsumgebungen uebergeleitet.
