\chapter{Entwicklungsumgebungen}
\label{sec_entwicklungsumgebung}

In diesem Kapitel wird die begriffliche Grundlage f"ur die Er"orterungen in den
nachfolgenden Kapiteln gelegt.  Ein Schwerpunkt der Betrachtungen ist der
Aspekt der Systemstrukturierung und hier im besonderen das Zusammenwirken von
Basisdiensten und externen Programmen bzw.\ die Unterst"utzung, die durch
externe Programme geleistet werden kann.  Externe Programme, im Zusammenhang
mit Entwicklungsumgebungen auch Werkzeuge genannt, und die Dienste, die sie
anbieten, werden hier im Unterschied zu Diensten gesehen, die direkt von einer
Programmiersprache (z.B.\ Systemstrukturierung) bzw.\ einem Basissystem (z.B.\ 
Dateiverwaltung) geleistet werden. Sie ben"otigen zur Erf"ullung ihrer Aufgabe
eine Reihe von grundlegenden Diensten.  Z.B.\ mu"s ein Werkzeug, welches die
"Ubersetzung von Modulen steuert, Zugriff auf einen Dienst haben, mit dessen
Hilfe es auf Dateien zugreifen oder das Datum der letzten Ver"anderung
ermitteln kann.  Dieser Dienst kann auf unterschiedliche Weise bereitgestellt
werden.  Eine Bibliothek kann die entsprechenden Dienste in Form von Funktionen
anbieten, andere Dienste k"onnen durch Systemaufrufe bereitgestellt werden,
wieder andere durch externe Programme einer niedrigeren Schicht, meist des
Betriebssystems.  In letzerem Fall sind die Werkzeuge und die zugrundeliegenden
Dienste selbst"andig, also unabh"angig von einer Programmiersprache zu sehen.

In dem vorliegenden Kapitel wird zun"achst anhand einer Referenzarchitektur f"ur
Entwicklungsumgebungen aufgezeigt, welche Dienste Werkzeugen zur Verf"ugung
stehen.  Anhand zweier konkreter Beispiele wird beschrieben, ob und wie
diese Dienste Werkzeugen bereitgestellt werden.  Am Beispiel der ABAP/4
Entwicklungsumgebung wird ferner im Vorgriff auf die weiteren Kapitel eine enge
Verzahnung von Programmiersprache und Entwicklungsumgebung gezeigt und in
diesem Zusammenhang auch die Verteilung der Strukturierungsaufgaben zwischen
diesen betrachtet.

Der Begriff Entwicklungsumgebung selbst ist in der Literatur nicht eindeutig
definiert.  Informell wird in \cite{nist500-211} eine Entwicklungsumgebung als  
ein System gesehen, da"s automatisierte Unterst"utzung f"ur die
Softwareentwicklung bereitstellt und die Prozesse, die hierf"ur notwendig sind,
verwaltet.  Es gibt dar"uber hinaus zahlreiche weitere Begriffe, die die
gleiche oder eine "ahnliche Bedeutung haben.  Eine Auswahl dieser Begriffe, die
alle die gleiche Thematik betreffen, ist nachfolgend gegeben:

\begin{sloppypar}
\begin{itemize}
\item Computerunterst"utzte Software Entwicklungsumgebung
  (\textit{Computer Aided Software Engineering Environment (CASEE)})

\item Integrierte Projektunterst"utzungsumgebung (\textit{Integrated
    Project Support Environment (IPSE)})

\item Integrierte computerunterst"utzte Softwareentwicklung
  (\textit{Integrated Computer Aided Software Engineering (I-CASE)})

\item Integrierte Softwarefabrik (\textit{Integrated Software Factory
    (ISF)})

\item Integrierte Softwareentwicklungsumgebung (\textit{Integrated
    Software Engineering Environment (ISEE)})

\item Softwareentwicklungsumgebung (\textit{Software Development
    Environment (SDE)})

\item Softwareentwicklungsumgebung (\textit{Software Engineering
    Environment})

\item Unterst"utzungsumgebung (\textit{Support Environment})
\end{itemize}
\end{sloppypar}

Die Aufgaben einer Entwicklungsumgebung lassen sich wie folgt
zusammenfassen.  Entwicklungsumgebungen verwalten Informationen "uber Software
(Quellcode, Entwurfsdaten, Testdaten usw.), "uber Projektressourcen (z.B.\
Entwicklerkapazit"aten oder Rechnerkapazit"aten) und "uber Organisation,
Standards und Richtlinien, die bei der Softwareentwicklung Anwendung finden.

Der Fokus dieser Arbeit liegt auf der Betrachtung des ersten Punktes,
Informationen, die unmittelbar mit dem Entwurfsproze"s in Verbindung stehen.

%Was geh"ort zu einer Entwicklungsumgebung?
%Welche Standards gibt es zu dem Thema?
%Welche Begriffe werden dort standardisiert?

\section{Referenzarchitektur f"ur Entwicklungsumgebungen}
In \cite{nist500-211} wird ein Referenzmodell f"ur die Architektur einer
Entwicklungsumgebung vorgestellt.  Dabei werden diejenigen Dienste
spezifiziert, die eine Entwicklungsumgebung bereitstellen sollte.  Diese
Dienste sind in Gruppen zusammengefa"st.  Eine Grundstruktur wird vorgegeben,
welche einen Architekturvorschlag darstellt, der die Ber"uhrungspunkte der
einzelnen Dienstgruppen aufzeigt.  Die folgenden Dienstgruppen sind in
\cite{nist500-211} definiert:

\begin{itemize}
\item Objektverwaltungsdienste ({\itshape object management services})
\item Proze"sverwaltungsdienste ({\itshape process management services})
\item Kommunikationsdienste ({\itshape communication services})
\item Betriebssystemdienste ({\itshape operating system services})
\item Benutzerschnittstellendienste ({\itshape user interface services})
\item Sicherheitsbezogene Dienste ({\itshape policy enforcement services})
\item Administrationsdienste ({\itshape framework administration services})
\end{itemize}

Abbildung \ref{abb_nist} zeigt den prinzipiellen Aufbau der Referenzarchitektur,
wobei die sicherheitsbezogenen Dienste und die Administrationsdienste nicht in
dieser Darstellung enthalten sind.  Besonders hervorgehoben werden soll hier
die Stellung, die die Werkzeuge einnehmen.  Sie setzen auf die Funktionalit"at
auf, die von den "ubrigen Diensten bereitgestellt wird.  Eine zentrale Position
nehmen dabei zum einen die Kommunikationsdienste ein, die als Bindeglied
zwischen allen anderen Diensten fungieren.  Zum anderen stellt die Gruppe der
Objektverwaltungsdienste eine weitere wichtige Komponente dar.  Hier werden
Objekte wie der Quellcode oder "ubersetzte Einheiten verwaltet und in Beziehung
zueinander gebracht.

%\afterpage{\clearpage
\begin{figure}[H]
\centering\mbox{\epsfig{file=../Zeichnung/nist.eps}}
\caption{"Uberblick "uber eine Referenzarchitektur f"ur Entwicklungsumgebungen.}
\label{abb_nist}
\end{figure}
%}

Allgemein verwalten Entwicklungsumgebungen Informationen aus den folgenden drei
Kategorien:

\begin{enumerate}
\item [a)] Information "uber die in der Entwicklung befindliche Software, wie
  z.B.\ Spezifikations-, Entwurfs-, Quellcode- und Testdaten.

\item [b)] Informationen "uber Ressourcen, wie z.B.\ die verf"ugbare Hardware
  und deren Leistungs\-f"ahigkeit sowie die zur Verf"ugung stehenden Entwickler,
  und die Zuordnung dieser Ressourcen zu bestimmten Aufgaben.

\item [c)] Informationen "uber die zugrundeliegende Unternehmensstruktur,
  (Unternehmens-) Standards und andere Richtlinien, die die Entwicklung von
  Software betreffen.
\end{enumerate}

Wie in Abbildung \ref{abb_nist} zu sehen, werden die Aufgaben einer
Entwicklungsumgebung zum einen durch die bereits erw"ahnten Dienste erf"ullt.
Diese stellen aber zum anderen auch den Werkzeugen geeignete Mittel zur
Verf"ugung, um diese Aufgaben zu erledigen, bzw.\ nutzen die Werkzeuge
ihrerseits, um Dienste zu erbringen (Proze"sverwaltungsdienste und
Benutzerschnittstellendienste).

In den n"achsten Abschnitten werden von den vorstehend aufgef"uhrten
Dienstgruppen einige exemplarisch dargestellt.  Die hierbei betrachteten
Aspekte sind die Systemstrukturierung und die Anbindung von Werkzeugen.  F"ur
den ersten Aspekt ist nur die Dienstgruppe der Objektverwaltungsdienste
relevant, da sie direkt mit den Softwareeinheiten wie z.B.\ Modulen und Klassen
operiert.  

Das vorgestellte Referenzmodell stellt lediglich Basisdienste z.B.\ f"ur
Werkzeuge bereit. Es werden deshalb die M"oglichkeiten zur Integration von
Werkzeugen betrachtet. In \cite{nist500-211} werden folgende Dimensionen
beschrieben, auf denen Integration erreicht werden kann.  Sie dienen als
Anhaltspunkt f"ur die Er"orterung der weiteren Dienstgruppen.

\begin{description}
\item[Datenintegration] ({\itshape data integration}): Hierunter versteht man
  die M"oglichkeit, da"s Werkzeuge Daten untereinander austauschen k"onnen.
  Dies kann z.B.\ erreicht werden, indem verschiedene Werkzeuge die gleiche
  Datenbank benutzen oder indem ein einheitliches Datenformat verwendet wird.

\item[Kontrollflu"sintegration] ({\itshape control integration}): Das
  bedeutet, da"s die Funktionalit"at von Werkzeugen auf unterschiedliche Weise
  und in unterschiedlicher Reihenfolge kombiniert werden kann.

\item[Pr"asentationsintegration] ({\itshape presentation integration}): Hiermit
  ist die einheitliche Darstellung der Werkzeuge auf dem Bildschirm gemeint.
  Dies kann z.B.\ durch die Verwendung einer einheitlichen Bedienoberfl"ache
  erreicht werden.

\item[Proze"sintegration] ({\itshape process integration}): Die Funktionalit"at
  der Umgebung kann in vordefinierten Prozessen genutzt werden.

\item[Grundstrukturintegration] ({\itshape framework integration}): Diese
  Integrationsdimension bezieht sich darauf, inwieweit Werkzeuge sich in eine
  gegebene Grundstruktur einpassen.  Sie k"onnen z.B.\ "ahnliche
  Installationsmechanismen oder "ahnliche Mechanismen zur Benutzerverwaltung
  verwenden.
\end{description}

Insbesondere f"ur die in Kapitel \ref{cha_envtlmin} behandelte
Entwicklungsumgebung des {\tlmin} Systems werden hier diejenigen Dienste
gezeigt, die die Basisdienste f"ur Werkzeuge bereitstellen.  Das sind
Betriebssystemdienste, Objektverwaltungsdienste und Kommunikationsdienste.
Proze"sverwaltungsdienste und Pr"asentationsdienste nutzen wiederum die
Funktionalit"at der Werkzeuge, um ihre Dienste anzubieten (s.a.\ Abbildung     
\ref{abb_nist}).

Bei der folgenden Schilderung ist zu beachten, da"s die dargestellten Dienste
nicht in ihrer Gesamtheit existieren m"ussen, um aufbauend darauf Werkzeuge
einer Entwicklungsumgebung realisieren zu k"onnen.  Vielmehr stellen sie eine
Obermenge der ben"otigten Dienste dar.  Vielfach wird ihre Funktionalit"at erst
durch Werkzeuge implementiert.  Dies ist u.a.\ darin begr"undet, da"s die
Dienste sehr nah an den vom Benutzer der Entwicklungsumgebung tats"achlich
verwendeten Diensten sind.

\subsection{Betriebssystemdienste}
Die zu dieser Gruppe geh"orenden Dienste stellen die von einem Betriebssystem
"ublicherweise verf"ugbaren Funktionen in einer konsistenten Weise bereit.  Sie
abstrahieren damit von den Details des konkreten Systems und f"ordern die
Portabilit"at.  F"ur die Anbindung bzw.\ Kommunikation von Werkzeugen oder f"ur
die Systemstrukturierung haben sie eine Bedeutung, wenn die
Objektverwaltung auf Basis von Dateien vorgenommen wird.  In diesem Fall
korrespondiert die Einheit Datei direkt mit einer Softwareeinheit (Modul,
Klasse, Schnittstelle o."a.).  Folgende Dienste sind in dieser Dienstgruppe
zusammengefa"st:

\begin{description}
\item[Proze"sverwaltung] ({\itshape operating system process management}):
  Verwaltung, also Erzeugen, Duplizieren oder Beenden von
  Betriebssystemprozessen.

\item[Umgebungsdienste] ({\itshape operating system environment service}):
  Prozesse laufen meist in einer Umgebung ab, die z.B.\ aus einer Menge von
  Variablen mit entsprechenden Werten bestehen kann.  Zur Umgebung z"ahlen aber
  auch Zeit- und Datumsinformation oder Obergrenzen f"ur verf"ugbare Ressourcen
  wie z.B.\ Speicher oder Anzahl der offenen Dateien.

\item[Synchronisationsdienste] ({\itshape operating system synchronisation
    service}): Hierunter f"allt die Funktionalit"at des Betriebssystems,
  Prozessen nach einer bestimmten Strategie Zeit zur Ausf"uh\-rung zuzuteilen.

\item[Ein- und Ausgabedienste] ({\itshape generalized input and output}):
  Darunter sind generelle Mechanismen zur Ein- bzw.  Ausgabe von Daten auf
  physikalischen Ger"aten zusammengefa"st.

\item[Dateiein- und Dateiausgabe] ({\itshape file storage service}): Der Satz
  von Operationen "ahnelt im wesentlichen denen der zuvor beschriebenen
  generellen Ein- und Ausgabedienste.  Als Besonderheiten kommen hier
  Operationen zum Zugriff auf einen Verzeichnisdienst hinzu.

\begin{sloppypar}
\item[Signaldienst] ({\itshape asynchronous event service}): Prozesse
  signalisieren unabh"angig von sonstigen Kommunikationsdiensten bestimmte
  Ereignisse mit Hilfe von Signalen.  Diese werden meist in Ausnahmesituationen,
  z.B.\ bei schweren Fehlern, die die weitere Ausf"uhrung unm"oglich machen,
  eingesetzt.
\end{sloppypar}

\item[Zeitdienste] ({\itshape interval timing service}): Hierunter fallen
  Dienste zur Manipulation bestimmter Zeitme"smechanismen des Betriebssystems.

\item[Speicherdienste] ({\itshape memory management service}): Dieser Dienst
  wird vom Betriebssystem meist nur bei der Anforderung von gro"sen dynamischen
  Speicherbl"ocken direkt abgefragt.

\item[Physikalischer Ger"atedienst] ({\itshape physical device service}):
  Ger"ate, die mit den bereits beschriebenen Diensten nicht angesprochen werden
  k"onnen oder eine Sonderbehandlung erfahren m"ussen, k"onnen "uber diesen
  Dienst verwaltet werden.

\item[Ressourcenverwaltungsdienst] ({\itshape operating system resource
    management service}): Unter diesem Begriff sind Dienste zusammengefa"st, die
  es er\-m"oglichen, Ressourcen wie z.B.\ Sekund"ar\-speichergrenzen
  (\textit{quotas}) zu "andern.
\end{description}

In bezug auf die Systemstrukturierung sind hier lediglich die Ein-
Ausgabedienste relevant.  Sie sorgen daf"ur, da"s die verwalteten Einheiten
persistent abgelegt werden.

\subsection{Objektverwaltungsdienste}
Bei den Diensten in dieser Gruppe geht es um die Definition, Ablage, Wartung,
Verwaltung und den Zugriff von bzw.\ auf Daten.  In diesem Fall sind mit Daten
alle Objekte gemeint, die in dem Softwareentwicklungsproze"s eine Rolle spielen.
Hierzu geh"oren z.B.\ Module und Klassen und deren Beziehungen untereinander.

Die folgenden Abs"atze schildern die Bedeutung dieser Dienste f"ur die
Systemstrukturierung.  Der Aspekt der Werkzeugunterst"utzung ist hier insofern
betroffen, als eine gemeinsame Datenbasis als Grundlage f"ur den Austausch
von Objekten dienen kann und diese Dienste Objekte assoziieren k"onnen.

\begin{description}
\item[Metadatendienst] ({\itshape metadata service}): Metadaten legen die
  Struktur der verwendeten Daten und evtl.\ auf ihnen definierte
  Nebenbedingungen fest.  "Ublicherweise wird das verwendete Datenmodell einer
  Entwicklungsumgebung, die eng mit einer Programmiersprache verbunden ist,
  durch diese Sprache festgelegt.  Somit sind die Mechanismen zur Definition
  entsprechender Strukturen bereits in der Sprache enthalten.

\item[Datenspeicherungsdienst] ({\itshape data storage and persistence
    service}): Die Daten der Entwicklungsumgebung m"ussen persistent gespeichert
  werden.  Das kann erfolgen, indem dieser Dienst auf entsprechende
  Dateiverwaltungsdienste der Gruppe der Betriebssystemdienste aufsetzt.  Eine
  andere in Kapitel \ref{cha_envtlmin} betrachtete M"oglichkeit ist die
  Verwendung eines persistenten Objektsystems, welches Persistenz in Form von
  transitiver Erreichbarkeit bereitstellt.

\item[Beziehungsdienst] ({\itshape relationship service}): Zwischen den
  Objekten der Entwicklungsumgebung bestehen Beziehungen.  Diese k"onnen in
  vielerlei Gestalt auftreten, z.B.\ als Beziehungen, die durch Importe
  zwischen Quelldateien bestehen oder als Beziehungen, die zwischen
  zusammenzubindenden "ubersetzten Einheiten bestehen.

\item[Namensdienst] ({\itshape name service}): Objekte m"ussen, damit sie f"ur
  Werkzeuge erreichbar sind, benannt werden.  Dieser Dienst stellt ein
  einheitliches Benennungsschema f"ur Objekte bereit.

\item[Verteilungs- und Lokalisierungsdienst] ({\itshape distribution and
    location service}): Bei der vorgestellten Referenzarchitektur wird nicht von
  einer zentralen Datenbasis ausgegangen.  Dieser Dienst stellt deshalb
  Mechanismen bereit, um die physikalische Verteilung der Daten in ein logisches
  Schema f"ur den Entwickler umzusetzen.  Dieses logische Schema kann wiederum
  von der Verteilung vollst"andig abstrahieren.

\item[Transaktionsdienst] ({\itshape data transaction service}): Dieser Dienst
  stellt "ahnlich dem Transaktionsbegriff aus dem Bereich der Datenbanken eine
  M"oglichkeit bereit, logisch zusammengeh"orende Aktivit"aten zu einer Einheit
  zusammenzufassen, die atomar und isoliert ausgef"uhrt wird und
  dabei den Datenbestand in einem konsistenten Zustand hinterl"a"st.

\item[Nebenl"aufigkeitsdienst] ({\itshape concurrency service}): Der Zugriff
  auf die Objekte kann von mehreren Prozessen, Werkzeugen bzw.\ anderen
  Diensten simultan erfolgen.  Dieser Dienst synchronisiert diese
  nebenl"aufigen Zugriffe.

\item[Betriebssystemproze"sdienst] ({\itshape os process support service}):
  Durch diesen Dienst wird die M"og\-lichkeit geschaffen, auf
  Betriebssystemprozesse in der gleichen Weise wie auf die Objekte der
  Entwicklungsumgebung zuzugreifen.

\item[Archivierungsdienst] ({\itshape archive service}): Dieser Dienst
  speichert die Objektdaten auf terti"aren Medien.

\item[Backupdienst] ({\itshape backup service}): Dieser Dienst legt Strategien
  zur Sicherung der Daten fest und bietet M"oglichkeiten zum Wiedereinspielen
  gesicherter Daten nach einem Ausfall.

\item[Ableitungsdienst] ({\itshape derivation service}): Objekte k"onnen durch
  Transformation aus anderen Objekten hervorgehen.  Der Ableitungsdienst
  spezifiziert die Regeln, nach denen die Transformation eines Objektes
  ausgef"uhrt wird und mit welchen Werkzeugen das geschieht.  Dieser Dienst
  entspricht weitgehend dem, was eine Modulverwaltung leistet.

\item[Replikations- und Synchronisationsdienst] ({\itshape replication and
    synchronisation service}): Dieser Dienst hat ausschlie"slich in einer
  verteilten Umgebung eine Bedeutung.  Dort regelt er die Verteilung und
  Replikation der Objekte und deren Konsistenz.

\item[Zugriffskontroll- und Sicherheitsdienst] ({\itshape access control and
    security service}): Unterschiedliche Benutzer der Entwicklungsumgebung haben
  unterschiedliche Bed"urfnisse an den Umfang an Daten, die sie benutzen.
  Dar"uber hinaus ist es notwendig, den Zugriff auf die Daten explizit
  kontrollieren zu k"onnen.

\item[Funktionsanhangsdienst] ({\itshape function attachment service}): Dieser
  Dienst verfolgt einen objektorientierten Ansatz, der es erlaubt, an ein Objekt
  Funktionen anzuh"angen, die auf dem Objekt arbeiten.  Bei diesen Funktionen
  kann es sich z.B.\ um Methoden handeln, die eine bestimmte Transformation auf
  dem Objekt durchf"uhren.

\item[Schemadienst] ({\itshape common schema service}): Besonders wichtig
  f"ur die Integration von Werkzeugen ist der Schemadienst.  Er stellt ein
  einheitliches Schema f"ur die verwalteten Daten bereit und legt somit die
  Struktur der Daten, Integrit"atsbedingungen sowie deren Namen fest.
  Weiterhin k"onnen in einem Schema die auf einem Objekt m"oglichen Operationen
  spezifiziert werden.

\item[Versionierungsdienst] ({\itshape version service}): Das ist ein Dienst,
  der direkt an den Benutzer der Entwicklungsumgebung gereicht werden kann.  Er
  verwaltet aktuelle und historische Zust"ande der Objekte.  Es
  k"onnen von einem Objekt parallel mehrere Versionen bestehen, die in einer
  gemeinsamen Version zusammengef"uhrt werden oder, falls es sich z.B.\ um
  Versionen f"ur unterschiedliche Betriebssystemplattformen handelt,
  nebeneinander existieren.

\item[Dienst f"ur zusammengesetzte Objekte] ({\itshape composite object
    service}): Objekte k"onnen zu gr"o"se\-ren Objekten aggregiert werden.  Die
  hierf"ur und f"ur den Zugriff auf die Komponenten notwendigen Operationen
  stellt dieser Dienst bereit.

\item[Anfragedienst] ({\itshape query service}): Neben Diensten, die direkt auf
  ein Objekt zugreifen, bietet der Anfragedienst die M"oglichkeit, zun"achst
  unbekannte Objekte durch Formulierung einer entsprechenden Anfrage zu
  lokalisieren.

\item["Uberwachungs- und Ereignisdienst] ({\itshape state monitoring and
    triggering service}): In Abh"angig\-keit von bestimmten Zust"anden l"ost
  dieser Dienst Aktionen aus.  Ein weiteres Merkmal besteht in der "Uberwachung
  der Zust"ande.

\item[Klassifikationsdienst] ({\itshape data subsetting service}): Dieser
  Dienst mu"s von dem Dienst f"ur zusammengesetzte Objekte unterschieden
  werden.  Oft ist es sinnvoll, nicht die gesamte Menge der Objekte der
  Entwicklungsumgebung zu betrachten, sondern eine in sich geschlossene
  Untermenge.

\item[Datenaustauschdienst] ({\itshape data interchange service}): Zum
  Austausch der Daten z.B.\ mit einer anderen Entwicklungsumgebung stellt
  dieser Dienst Funktionen bereit.
\end{description}

Durch die Objektverwaltungsdienste wird die Systemstrukturierung in direkter
Weise unterst"utzt.  Dies geschieht zum einen durch die M"oglichkeit, Objekte zu
benennen und zusammenzufassen und zum anderen durch die M"oglichkeit,
Abh"angigkeiten und Umformungen auf diesen Objekten zu definieren.

\subsection{Kommunikationsdienste}
Dienste, die in diese Gruppe fallen, erm"oglichen den Werkzeugen und den
Diensten anderer Gruppen, miteinander zu kommunizieren.  Besonders die Aufgaben,
die Werkzeuge erf"ullen, k"onnen nicht immer in Isolation gesehen werden.
Werkzeuge m"ussen, z.B.\ um den Bearbeitungszustand eines Objektes abzufragen,
miteinander kommunizieren k"onnen.  Zwar bieten die Objektverwaltungsdienste
auch ein gewisses Ma"s an Kommunikation, indem sie die Objekte allen Werkzeugen
zur Verf"ugung stellen und diese Werkzeuge somit "uber Zugriff und Modifikation
dieser Objekte Informationen austauschen k"onnen.  Bei den
Kommunikationsdiensten handelt es sich jedoch um eine andere Qualit"at der
Verst"andigung, die z.B.\ darauf abstellt, in Ausf"uhrung befindliche Werkzeuge
durch entsprechende Mechanismen zu synchronisieren oder Werkzeuge durch die
Signalisierung anderer Werkzeuge zu benachrichtigen, eine gestoppte Ausf"uhrung
fortzusetzen.

In dieser Arbeit liegt der Schwerpunkt auf der Betrachtung von
Werkzeugen, somit werden die hier angebotenen Dienste besonders unter
dem Gesichtspunkt der Kommunikation von Werkzeugen dargestellt.

\begin{description}
\item[Dienst f"ur gemeinsamen Datenzugriff] ({\itshape data sharing service}):
  Dieser Dienst fa"st die Funktionalit"at verschiedener anderer Dienste aus der
  Gruppe der Objektverwaltungsdienste zusammen, um den gemeinsamen Zugriff auf
  Daten zur Verf"ugung zu stellen.

\item[Proze"skommunikationsdienst] ({\itshape interprocess communication
    service}): Der auch vom Betriebssystem zur Verf"ugung stehende Dienst zur
  Interproze"skommunikation wird hier noch einmal bereitgestellt.

\item[Netzwerkdienst] ({\itshape network service}): Dieser Dienst umfa"st
  Operationen zum Ausf"uhren entfernter Prozeduraufrufe und zum Ermitteln und
  Benutzen entfernter Ressourcen.

\item[Nachrichtenvermittlungsdienst] ({\itshape message service}): Dieser
  Dienst erm"oglicht Prozessen o\-der Werkzeugen, Daten "uber Nachrichten
  auszutauschen.  Z.B.\ lassen sich alternativ zum Zugriff auf gemeinsame
  Daten diese Daten auch mittels Nachrichten "ubertragen.

\item[Ereignisbenachrichtigungsdienst] ({\itshape event notification service}):
  Im Gegensatz zum Nachrichtenvermittlungsdienst sind die Nachrichten, die
  durch den Ereignisbenachrichtigungsdienst verschickt werden, an das Auftreten
  eines Ereignisses gebunden.
\end{description}

Wie die Betriebssystemdienste stellen auch die Dienste in dieser Dienstgruppe
grundlegende Mechanismen bereit und bieten keine unmittelbare Unterst"utzung
f"ur die Systemstrukturierung.  

\section{Teamware und SCCS}
\label{sec_teamware_sccs}
Bei den in diesem Abschnitt untersuchten Softwarekomponenten handelt es sich um
eine von Sun Microsystems vertriebene Entwicklungsumgebung.  Sie unterst"utzt
die Entwicklung in einem Team und bietet dar"uber hinaus eine grafische
Benutzerschnittstelle f"ur die angebotenen Funktionen.

Diese Entwicklungsumgebung wird hier exemplarisch f"ur die Klasse der
Entwicklungsumgebungen untersucht, die die folgenden zwei Eigenschaften
aufweisen:

\begin{itemize}

\item Die Verwaltung der Softwareeinheiten findet auf Basis von Dateien statt,
  d.h.\ eine Softwareeinheit ist in einer Datei enthalten.  Das impliziert zum
  einen die hohe Erreichbarkeit der Einheiten durch (auch nicht zur
  Entwicklungsumgebung geh"orende) Programme und damit eine potentiell hohe
  Flexibilit"at gegen"uber Erweiterungen bzw.\ Austausch von Werkzeugen.  Zum
  anderen kann bei der Verwaltung im Dateisystem angenommen werden, da"s keine
  Abfragesprache (z.B.\ SQL oder OQL) existiert oder ein allgemein
  zug"angliches Datenmodell auf den Softwareeinheiten definiert w"are.  Dies
  folgt unmittelbar daraus, da"s die Objektverwaltungsdienste von den
  Betriebssystemdiensten "ubernommen werden.  Die Dateien bzw.\ 
  Softwareeinheiten sind somit semantisch in keiner Weise verbunden (Import-
  und Exportabh"angigkeit), und es k"onnen keine unterschiedlichen Typen
  identifiziert werden (Quelldatei, Objektdatei usw.).

\item Die Entwicklungsunterst"utzung erfolgt sprachunabh"angig.  Zwar
  existieren auch in dieser Entwicklungsumgebung sprachabh"angige Teile, sie
  sind jedoch nicht fester Bestandteil eines Werkzeuges.  Vielmehr k"onnen die
  Programme durch geeignete Parametrisierungskonzepte (Konfigurationsdateien,
  Kommandozeilenargumente) an die jeweile Sprache angepa"st werden.
\end{itemize}

Die Softwareentwicklungsumgebung von Sun Microsystems umfa"st eine Reihe von
Werkzeugen f"ur jeweils bestimmte Aufgaben.  Sie sind nachstehend beschrieben.
Einen "Uberblick "uber die Komponenten und deren Zusammenwirken gibt Abbildung
\ref{abb_sparcworks}.  Einige der Werkzeuge sind unter der Bezeichnung
SPARCworks/ProWorks, andere unter SPARCWorks/TeamWare
zusammengefa"st\footnote{Die zugrunde gelegte Dokumentation ist in diesem Punkt
  nicht eindeutig.  Das FileMerge-Werkzeug wird sowohl der SPARCworks/ProWorks
  als auch der SPARCworks/TeamWare zugerechnet \cite{teamware}.  Da es von der
  Funktionalit"at her eng mit dem VersionTool der SPARCworks/TeamWare Umgebung
  zusammenarbeitet, wird es auch dort behandelt.}.  Im folgenden wird ein
"Uberblick der SPARCworks/ProWorks Werkzeuge gegeben:

\begin{description}

\item[Source Code Browser:] Dieses Werkzeug dient dazu, w"ahrend der
  Programmentwicklung den "Uberblick "uber ein Softwareprojekt zu behalten oder
  zu erlangen.  Es gestattet, z.B. alle Vorkommen einer Variablen, Funktion usw.
  anzuzeigen.  Weiterhin kann in einer baumartigen Struktur der Aufrufgraf
  (\textit{call graph}) eines Programms dargestellt werden.

\item[MakeTool:] Dies ist ein grafisches Frontend zu \textit{make}, einem
  Programm, welches basierend auf spezifizierten Abh"angigkeiten zwischen
  Dateien Aktionen auf diesen oder anderen Dateien ausf"uhrt \cite{make}.  Bei
  diesen Aktionen kann es sich z.B.\ um die "Ubersetzung einer Quelldatei in
  eine Objektdatei handeln.  Der Ansatz der dateibasierenden
  Entwicklungsumgebung gestattet es aber auch, beliebige andere Programme, die
  auf Dateien arbeiten, "uber das MakeTool aufzurufen und in den
  Entwicklungsproze"s einzubinden.

\item[Debugger:] Wie das MakeTool besteht auch der Debugger aus einem
  grafischen Frontend, welches die Steuerung eines eigenst"andig ablaufbaren
  Programms, dem eigentlichen Debugger, "ubernimmt.  Der Debugger erlaubt das
  schrittweise Durchlaufen bzw. beliebiges Anhalten und erneutes Ablaufen eines
  Programms und die Untersuchung von Variablenwerten, Deklarationen,
  Funktionsaufrufen auf dem Stack etc.\ zur Laufzeit.  Zu diesem Zweck liest der
  Debugger die vom "Ubersetzer generierten Informationen aus der Objektdatei
  aus.

\item[Performance Tuning:] Es handelt sich hierbei um ein Werkzeug, welches es
  dem Programmierer erlauben soll, hinsichtlich einer vom Programm ben"otigten
  Ressource, etwa Prozessorzeit oder Speicherplatz, Engp"asse zu ermitteln, um
  diese anschlie"send zu beseitigen.  W"ahrend der Fehlersuche mit dem Debugger
  kann er Informationen "uber das laufende Programm sammeln, z.B. wieviel
  Prozessorzeit f"ur die Abarbeitung bestimmter Programmteile verbraucht oder
  in welchem Teil wieviel Speicher angefordert wurde.  Aufgrund der Ergebnisse
  dieses Prozesses ist es dann m"oglich, "Anderungen am Programm
  durchzuf"uhren.

\end{description}   

Die Komponenten der Teamware-Umgebung werden nachstehend erl"autert.
Die Konzepte, die dem VersionTool und dem Codemanager zugrunde
liegen, werden in den n"achsten Abschnitten weiter untersucht.

%\afterpage{\clearpage
\begin{figure}[H]
\centering\mbox{\epsfig{file=../Zeichnung/sparcworks.eps}}
\caption{"Uberblick "uber die SPARCWorks-Entwicklungsumgebung.}
\label{abb_sparcworks}
\end{figure}
%}

\begin{description}

\item[VersionTool:] Bei der Softwareentwicklung insbesondere in einem Team
  werden die "Anderun\-gen an einem Quelltext "ublicherweise durch eine Abfolge
  von Versionen festgehalten.  Ein Programm, das diesen Proze"s unterst"utzt,
  ist z.B. SCCS \cite{sccs}.  Es ist Teil der hier beschriebenen
  Entwicklungsumgebung.  SCCS wird "uber eine Reihe von Befehlen gesteuert, die
  auf der Kommandozeile durch Angabe entsprechender Optionen in ihrem Verhalten
  beeinflu"st werden k"onnen.  Um die Bedienung m"oglichst einfach zu
  gestalten, kann der Programmierer auf die Funktionalit"at dieser
  Versionsverwaltung "uber ein grafisch orientiertes Werkzeug zugreifen.

\item[FileMerge:] Bei der Erstellung mehrerer Entwicklungsstr"ange f"ur eine
  Quelldatei und insbesondere bei der Entwicklung in einem Team tritt der Fall
  auf, da"s diese Str"ange wieder zusammengef"uhrt werden m"ussen.  Bei diesem
  Vorgang werden zwei unterschiedliche (aber meist von einer Datei abstammende)
  Quelldateien zu einer einzigen verschmolzen.  Die Aufgabe von FileMerge ist
  es, dies in einer grafisch unterst"utzten Weise zu erledigen.

\item[Codemanager:] Der Codemanager ist die Komponente, die die Aktivit"aten
  der an einem Projekt beteiligten Entwickler koordiniert.  Es wird dazu das
  Modell des Arbeitsbereichs (\textit{work\-space}) eingef"uhrt, welches jedem
  Entwickler seinen eigenen Entwicklungsbereich zuordnet.  "Anderungen werden
  in einem "ubergeordneten Arbeitsbereich konsolidiert.  Dieses Werkzeug macht
  sich die Versionsverwaltung SCCS und eine Verzeichnisstruktur, die die
  Organisation in Arbeitsbereiche widerspiegelt, zunutze, um die beschriebenen
  Aufgaben zu erf"ullen.

\item[ParallelMake:] Wie das weiter oben beschriebene MakeTool bietet auch
  das ParallelMake ein grafisches Frontend zum \textit{make}-Programm.  Es
  benutzt jedoch eine spezielle Version, die unabh"angig ablaufbare Aktionen in
  verschiedene Betriebssystemprozesse plaziert und somit die M"oglichkeit
  schafft, diese parallel ausf"uhren zu lassen.

\end{description}

\subsection{Teamunterst"utzung}
Der SPARCWorks Umgebung liegt ein bestimmtes Modell zugrunde, nach dem die
Entwicklung von Software abl"auft.  Dieses Modell, welches besonders auf die
Unterst"utzung der Softwareentwicklung im Team abzielt, wird in diesem
Abschnitt vorgestellt.

Die Unterst"utzung mehrerer Entwickler, die simultan an einem Projekt arbeiten,
wird in der SPARCWorks Umgebung mit dem Konzept der Arbeitsbereiche
(\textit{workspace}) realisiert.  Jeder Programmierer arbeitet in einem lokalen
Bereich mit Kopien der Entwicklungsobjekte, die er zu modifizieren
beabsichtigt.  In einem Integrationsbereich werden die "Anderungen
verschiedener lokaler Arbeitsbereiche synchronisiert.  Abbildung
\ref{abb_workspace} zeigt ein einfaches Modell von Arbeitsbereichen, die in
einer Eltern-Kind-Beziehung stehen.  Entlang der Pfeile erfolgt, wie sp"ater
erl"autert wird, die Synchronisation in beiden Richtungen.  Mehrstufige Modelle
sind m"oglich, in denen Arbeitsbereiche auf mittleren Stufen als
Integrationsbereich f"ur unterliegende Bereiche fungieren.

\begin{figure}[htb]
\centering\mbox{\epsfig{file=../Zeichnung/workspace.eps}}
\caption{Organisation von Arbeitsbereichen.}
\label{abb_workspace}
\end{figure}

\subsubsection{Entwicklungsmodell}
Dem Entwicklungsmodell des CodeManagers liegt als Basis der Arbeitsbereich
zugrunde.  Hierbei handelt es sich um ein Verzeichnis inklusive seiner
Unterverzeichnisse, die die entsprechenden Dateien beherbergen.  Konzeptuell
formen diese Arbeitsbereiche eine Hierarchie, wie sie in Abbildung
\ref{abb_workspace} gezeigt ist.  Die Entwicklung erfolgt in einem aus drei
Phasen bestehenden Zyklus: Aktualisieren, lokal modifizieren und hochschreiben
(\textit{copy--modify--merge}).

\begin{itemize}
\item Im ersten Schritt werden die Dateien, die modifiziert werden sollen, vom
  "ubergeordneten Arbeitsbereich kopiert.  Dies kann von mehreren
  Programmierern gleichzeitig vorgenommen werden.

\item Der Entwickler nimmt in der zweiten Phase "Anderungen an den kopierten
  Dateien vor.

\item Die ge"anderten Dateien m"ussen nun wieder mit dem "ubergeordneten
  Arbeitsbereich, dem Integrationsbereich, zusammengef"uhrt werden.  Sie werden
  dazu lediglich in den Integrationsbereich kopiert.
\end{itemize}

Der letzte Schritt kann nur erfolgen, wenn keine "Anderungen aus einem
anderen Arbeitsbereich bereits in den Integrationsbereich eingeflossen sind.
Diese w"urden durch die neuen "Ande\-rungen "uberdeckt werden.  In diesem Fall
m"ussen die "Anderungen im Integrationsbereich erst im Arbeitsbereich
nachvollzogen werden.  Erst dann kann der Arbeitsbereich mit dem
Integrationsbereich synchronisiert werden.  Ein aufgrund der nicht
automatischen Durchf"uhrbarkeit aufwendiges Zusammenf"uhren von Dateien erfolgt
stets im untergeordneten Arbeitsbereich.

Bei der Schilderung des Modells wurde von einer einstufigen Hierarchie zwischen
Arbeitsbereichen ausgegangen.  Die Erweiterung auf mehrere Stufen erh"oht die
Komplexit"at jedoch nur unwesentlich, da ein Austausch von Dateien nur zwischen
Arbeitsbereichen angrenzender Ebenen vorgenommen werden kann.

Aus dem geschilderten Modell ergeben sich vier unterschiedliche Beziehungen, in
denen ein Eltern-Arbeitsbereich zu einem Kind-Arbeitsbereich stehen kann, die
jeweils unterschiedliche Aktionen zur Folge haben k"onnen:

\begin{enumerate}
\item Keine Aktionen sind notwendig, wenn sowohl Eltern- als auch
  Kind-Arbeitsbereich unver"andert sind.

\item Wurde nur der Kind-Arbeitsbereich ge"andert, m"ussen die
  korrespondierenden Objekte im "ubergeordneten Arbeitsbereich aktualisiert
  werden.

\item Wurde nur der Eltern-Arbeitsbereich ver"andert, so mu"s dies dem
  Kind-Arbeitsbereich \glqq mitgeteilt \grqq\ werden.  Bevor eine "Anderung des
  Kind-Arbeitsbereichs hochgeschrieben werden kann, mu"s dieser mit dem
  "ubergeordneten Bereich synchronisiert werden, was sich in diesem Fall auf
  das Kopieren der entsprechenden Dateien beschr"ankt.

\item Wie im vorigen Fall mu"s auch verfahren werden, wenn beide beteiligten
  Arbeitsbereiche ge"andert wurden.  In diesem Fall kann es jedoch bei der
  Synchronisation des Kind-Arbeitsbereiches zu Konflikten kommen, wenn
  korrespondierende Dateien in beiden Arbeitsbereichen "Anderungen erfahren
  haben.  Diese Konflikte m"ussen manuell aufgel"ost werden.
\end{enumerate}

Zusammenfassend l"a"st sich sagen, da"s "Anderungen stets im untergeordneten
Arbeitsbereich aufgel"ost werden, um den "ubergeordneten konsistent (f"ur
alle anderen untergeordneten Arbeitsbereiche) zu halten.

\subsection{Integration und Basisdienste}
Exemplarisch wird in diesem Abschnitt eines der in Abschnitt
\ref{sec_teamware_sccs} aufgef"uhrten Werkzeuge (VersionTool) dargestellt.
Dabei wird der Fokus der Betrachtung auf die Nutzung von Basisdiensten gelegt,
bzw.\ auf die zur Verf"ugung gestellten Basisdienste.

Bei dem Werkzeug zur Versionsverwaltung handelt es sich um ein grafisches
Frontend zum Versionsverwaltungssystem SCCS.  SCCS tritt hier in der Rolle des
Basisdienstes Versionierungsdienst der Gruppe der Objektverwaltungsdienste auf.
Die Funktionalit"at, die das grafische Frontend hinzuf"ugt, bezieht sich auf
die Integration mit den anderen Werkzeugen.  Die Integration wird dabei auf den
folgenden Ebenen erreicht\footnote{Die Dimension der Rahmenwerkintegration
  konnte nicht untersucht werden, da sich diese z.B.\ auf einheitliche
  Installationsprozeduren u."a.\ bezieht.  Die SPARCWorks Entwicklungsumgebung
  wurde jedoch in einem installierten Zustand vorgefunden.  Auch ist zu diesem
  Punkt keine Dokumentation verf"ugbar.  Es kann jedoch davon ausgegangen
  werden, da"s auch diese Dimension der Integration erf"ullt wird, da es sich
  um Werkzeuge eines Herstellers handelt, die zusammen in einem Softwarepaket
  vertrieben werden.}:

\begin{itemize}
\item Datenintegration wird dadurch erreicht, da"s alle Werkzeuge auf die
  Dateien des Dateisystems Zugriff haben.  Das Dateisystem "ubernimmt die Rolle
  des Objektverwaltungsdienstes f"ur die grundlegenden Funktionen.

\item Pr"asentationsintegration wird erreicht durch die Verwendung einer
  einheitlichen Benutzer\-oberfl"ache mit der M"oglichkeit, Daten bzw.\ Dateien
  durch Verwendung der Maus zwischen Werkzeugen auszutauschen.  Die
  Funktionalit"at des GUI-Toolkits wird hier zus"atz\-lich als
  Kommunikationsdienst genutzt.

\item Kontrollflu"sintegration wird durch die Werkzeuge insofern geboten, als
  da"s sie als eigenst"andige Programme und Prozesse in ihrer Ablaufreihenfolge
  nur sehr geringen Einschr"ankungen unterliegen und in beliebiger Form sich
  gegenseitig aufrufen k"onnen.  So k"onnen Dateien mit dem SourceBrowser
  untersucht werden unabh"angig davon, ob und wann sie von der
  Versionsverwaltung in einer schreibf"ahigen Version bereitgestellt werden.
  Dies gilt in gleicher Weise allerdings nicht f"ur den Editor.
\end{itemize}

Eine Unterst"utzung f"ur fest definierte Prozesse wird von der SPARCWorks
Umgebung nicht geboten.  Zwar ergeben sich bestimmte Abl"aufe durch den
Entwicklungszyklus eines Programms.  Dieser Proze"s kann jedoch in keiner Weise
festgeschrieben oder in seinem Ablauf erzwungen werden.

Die von den Werkzeugen der SPARCWorks Umgebung genutzten Basisdienste werden in
Form von Bibliotheks- und Systemaufrufen bereitgestellt.  Zum einen st"utzen
sie sich auf die vom Betriebssystem bereitgestellten Funktionen, wie z.B.\ zum
Erzeugen eines neuen Prozesses.  Zum anderen werden Dienste genutzt, die in
Bibliotheken zusammengefa"st sind, wie z.B.\ das Einlesen der in einem
Verzeichnis enthaltenen Namen.  Durch diese Funktionen werden im wesentlichen
die Basisdienste der Gruppen Objektverwaltung und Betriebssystem abgedeckt.
Der Bereich der Kommunikationsdienste wird einerseits ebenfalls durch bereits
erw"ahnte Funktionen abgedeckt, es kommen jedoch die ebenfalls als
Bibliotheksfunktionen realisierten Dienste des GUI-Toolkits hinzu.

%Versionskontrolle:
%- Check in, check out Mechanismus
%- Versionsabfolge, Verzweigung
%- Objektverwaltungsdienste = Dateiverwaltung
%- Kommunikation ueber Dateisystem
%- Zugriff auf Dateien
%
% - Codemanager:
%   Arbeitet nur mit Datei, die von SCCS verwalet werden.
% - Synchronisation unterschiedlicher Entwickler-Aktivit"aten,
% - "Anderungen der Eltern-Kind Beziehungen sind moeglich
%   Gr"unde k"onnen sein:
%     - Reorganisation der Arbeitsbereichshierarchie
%     - Neues Projekt, anderer Toplevel Arbeitsbereich
%     - Neuer Code in anderen Arbeitsbereich einbauen (sinnvoll wenn z.B. der
%       Workspace einem Release entspricht)
% - Zusammenspiel von Arbeitsbereichen und Versionen
%   - Wie werden Arbeitsbereiche zusammengef"uhrt.
  
\section{ABAP/4 Development Workbench}
\label{sec_abap4_development}
Die ABAP/4 Development Workbench ist die im SAP R/3 System\footnote{Die im
  Rahmen dieser Arbeit vorgenommenen Untersuchungen basieren auf der Version
  2.2D des R/3 Systems.} enthaltene Entwicklungsumgebung.  Im Gegensatz zu der
in Abschnitt \ref{sec_teamware_sccs} vorgestellten Umgebung wird sie
exemplarisch f"ur eine Entwicklungsumgebung vorgestellt, die die nachstehend
aufgef"uhrten zwei Eigenschaften aufweist:

\begin{itemize}
\item Die Entwicklungsumgebung ist objektbasiert, d.h.\ ihre Softwareeinheiten
  werden in einem Objektspeicher (Repository) abgelegt und sind "uber eine
  entsprechende Schnittstelle zugreifbar.  Zwischen den Objekten k"onnen (je
  nach M"achtigkeit des zugrundeliegenden Datenmodells) Beziehungen und
  Invarianten (z.B.\ Typen) definiert werden.

\item Die Entwicklungsumgebung ist sprachgebunden.  Fest in die Umgebung
  integriert ist eine Programmiersprache.  Bei diesem Modell einer
  Entwicklungsumgebung k"onnen die Werkzeuge den speziellen Bed"urfnissen der
  Sprache und dem durch sie m"oglicherweise implizierten Entwicklungsmodell
  (z.B.\ objektorientierter Entwurf bei einer objektorientierten
  Programmiersprache) angepa"st werden.
\end{itemize}

Die Development Workbench zeichnet sich durch eine hohe Integration in ein
anderes System, das SAP R/3 System, aus.  Durch die starke Verflechtung der
Programmiersprache ABAP/4\footnote{ABAP/4: \glqq Advanced Business Application
  Programming\grqq .  Die Zahl vier im Namen unterstreicht die Zugeh"origkeit
  zur Gruppe der Programmiersprachen der vierten Generation.} mit den Werkzeugen
der Entwicklungsumgebung ist es sinnvoll, auch Aspekte, die eigentlich der
Sprache selbst zugeordnet werden m"ussen, hier zu behandeln.  Dazu geh"oren die
zahlreichen Strukturierungsm"oglichkeiten.  Wie in \cite{r3-admin} nachzulesen
ist, liegt u.a.\ in der Strukturierbarkeit eine der St"arken von ABAP/4, obwohl
die Strukturierung nicht ausschlie"slich durch sprachliche Mittel erreicht
wird.  Abbildung \ref{abb_abap4_umgebung} zeigt die enge Verzahnung der
Komponenten der ABAP/4 Entwicklungsumgebung.  Zu beachten ist, da"s keine
direkte Korrespondenz zwischen Werkzeugen der Umgebung und Gestaltungsbl"ocken
der Abbildung besteht.

Es werden die folgenden Aspekte untersucht: Abschnitt
\ref{subsec_strukturierung} beleuchtet die M"oglichkeiten, die die
Programmiersprache ABAP/4 und die Development Workbench zur Strukturierung
bereitstellen.  Abschnitt \ref{subsec_versionierung} befa"st sich mit
Versionierung.  Das Korrektur- und Transportwesen regelt die Unterst"utzung
f"ur die Entwicklung in einer Gruppe mehrerer Entwickler und ist f"ur den
Austausch von Entwicklungsobjekten\footnote{Als Entwicklungsobjekt wird in
  diesem Kontext alles aufgefa"st, was mit der Entwicklung von Programmen zu
  tun hat.  Dies reicht von Quelltexten, Bildschirmmasken, Tabellendefinitionen
  bis hin zu Dokumentationen und Nachrichten.} zwischen unterschiedlichen
Systemen verantwortlich.  Es wird in Abschnitt \ref{subsec_korrektur}
vorgestellt.  Eine Bewertung beschlie"st die Ausf"uhrungen zur ABAP/4
Entwicklungsumgebung.

\begin{figure}[H]
\centering\mbox{\epsfig{file=../Zeichnung/workbench.eps}}
\caption{Architektur der ABAP/4-Entwicklungsumgebung (aus \protect \cite{FID-DEV94})}
\label{abb_abap4_umgebung}
\end{figure}

Aspekte des Konfigurationsmanagements und weitere Unterst"utzung f"ur
ein Lebenszyklusmodell (\textit{life cycle support}) sind nicht in der
Entwicklungsumgebung ber"ucksichtigt \cite{tcmanagement}.  Nicht in
die Betrachtung einbezogen wird au"serdem die Systemgenerierung.
ABAP/4 ist eine interpretative Sprache, deren Zwischencode zur
Laufzeit abgearbeitet wird.  Der Zwischencode wird beim ersten Aufruf
des Programms erzeugt und anschlie"send persistent in
Datenbanktabellen abgelegt.  Er steht bei weiteren Programmaufrufen
wieder zur Verf"ugung.  Die Generierung dieses Codes erfolgt
vollst"andig transparent f"ur den Anwender und Programmierer, obwohl
letzterer die Zwischencodeerzeugung auch explizit starten kann.
Abh"angigkeiten zwischen verschiedenen Programmteilen und dem
Repository\footnote{Das Repository ist die zentrale Ablagekomponente,
  die alle Entwicklungsobjekte in den Tabellen des unterliegenden
  relationalen Datenbanksystems speichert.  Insbesondere ist hier das
  Data Dictionary enthalten, welches die Metainformation der Tabellen
  beinhaltet.} werden zur Laufzeit aufgel"ost.

%%% Warum wird CM nicht beschrieben? Wie werden die Aufgaben sonst erledigt
%%% Dokumentation aller Entwicklungsobjekte möglich

Die ABAP/4 Development Workbench unterst"utzt schwerpunktm"a"sig die
Entwicklung betriebswirtschaftlicher Anwendungen mit grafischen Oberfl"achen.
Dadurch wird dem Programmierer eine bestimmte Art der Programmgestaltung
bereits vorgegeben, die in der Entwicklung von Bildschirmmasken mit
entsprechender Verarbeitungslogik besteht.  Eine ABAP/4-Anwen\-dung kann "uber
eine Abfolge dieser Bildschirmmasken, Dynpros\footnote{Dynpro: \glqq
  Dynamisches Programm\grqq .}, beschrieben werden bzw.\ ist immer eine Abfolge
eines oder mehrerer Dynpros.  Durch Benutzung von ABAP/4 und der Development
Workbench ist der Programmierer somit auf einen engen Ausschnitt des m"oglichen
Anwendungsspektrums beschr"ankt, er hat es nicht mit einer Sprache f"ur
beliebige Anwendungen ({\itshape general purpose language}) zu tun.  Die Folge
sind Restriktionen, wie sie von anderen Sprachen nicht bekannt sind.  Sie
werden in den n"achsten Unterabschnitten genauer erl"autert.

\subsection{Strukturierung}
\label{subsec_strukturierung}
Wie Modula-2 oder Ada bietet auch ABAP/4 eine Reihe von
Strukturierungsmechanismen, wie Funktionen, Moduln usw.  Alle
Strukturierungselemente werden hier der Reihe nach behandelt.  Leider
ist eine klare Begrifflichkeit nicht an allen Stellen m"oglich, da
sich auch die von der SAP verf"ugbare Dokumentation in einigen Punkten
widerspricht.

Bereits an dieser Stelle wird der Begriff der Entwicklungsklassen
eingef"uhrt.  Im Abschnitt \ref{subsec_korrektur} wird er in anderem
Zusammenhang wieder aufgegriffen.  Jedes Entwicklungsobjekt ist einer
Entwicklungsklasse zugeordnet.  Im SAP R/3 System sind eine Reihe von
Entwicklungsklassen vordefiniert.  F"ur die Neudefinition von Klassen
stehen dem Programmierer durch die begrenzte Namensl"ange (zwei
Zeichen) und die Einschr"ankung auf bestimmte Anfangsbuchstaben (Y und
Z) nur eine geringe Zahl von m"oglichen Namen zur Verf"ugung.  Als
Strukturierungskonzept f"ur gro"se Entwicklungen scheiden
Entwicklungsklassen daher aus, auch weil sie keine neuen Namensr"aume
festlegen.  Jedes Entwicklungsobjekt einer bestimmten Kategorie, z.B.
eine Tabelle oder ein Programm, mu"s "uber alle Entwicklungsklassen
hinweg einen eindeutigen Namen besitzen.

\subsubsection{Unterprogramme}
Unterprogramme entsprechen Funktionen, wie sie bspw.\ aus C oder
Pascal bekannt sind, mit dem Unterschied, da"s sie sowohl mehrere
Eingabe- als auch mehrere Ausgabeparameter besitzen k"onnen.  Sie
werden innerhalb eines Programmes auf syntaktischer Ebene definiert
und sind damit keine eigenst"andigen Entwicklungsobjekte.

Ebenfalls sind Unterprogramme keine Objekte erster Klasse.  Sie k"onnen also
weder als Parameter an andere Unterprogramme "ubergeben, noch k"onnen
Variablen, die Unterprogramme enthalten, mit entsprechenden Operationen
angelegt werden. Auch eine Schachtelung ist nicht m"oglich.

Innerhalb von Unterroutinen ist die Verwendung von lokalen Variablen
m"oglich.  Diese "uber\-decken dabei die m"oglicherweise bereits global
definierten Variablen.  Zu undefiniertem Verhalten kommt es, wenn eine
lokale Variable in Konflikt zu einem gleichnamigen Funktionsargument
steht \cite{abap4}.  Der Syntax"uberpr"ufer der ABAP/4 Development
Workbench erkennt diesen unerw"unschten Effekt nicht.

\subsubsection{Dynpro}
Wie bereits erw"ahnt, erfolgt die Programmierung einer Anwendung in
ABAP/4 in Dynpros, die zu Dynproketten verkn"upft werden.  Dynpros
nehmen damit eine zentrale Rolle in der Entwicklung ein, da sie den
Programmflu"s auf oberster Ebene vorgeben.  Ein Dynpro besteht aus
einer Bildschirmmaske und zwei\footnote{Zwingend erforderlich sind die
  Ereignisse PBO ({\itshape process before output}) und PAI ({\itshape
    process after input}), die der Dynproprozessor vor bzw.\ nach
  Anzeige der Bildschirmmaske bearbeitet.  Zus"atzlich dienen die
  Ereignisse POH ({\itshape process on help request}) und POV
  ({\itshape process on value request}) dazu, Hilfedialoge
  aufzubauen.} Codeteilen, auch Ereignisse\footnote{SAP bezeichnet
  ABAP/4 auch als ereignisgesteuert.  Hierbei handelt es sich jedoch
  nicht um ein bspw.\ dem X Window System vergleichbares System,
  welches eine Vielzahl von Ereignissen verschiedenster Art behandelt.
  Vielmehr beschr"ankt sich ABAP/4 bei der Bearbeitung von Dynpros auf
  die vier beschriebenen Ereignisse.} genannt, die jeweils vor Anzeige
der Maske bzw.\ nach Beendigung der Bearbeitung durch den Benutzer
abgearbeitet werden.  Bei den Anweisungen innerhalb der
Verarbeitungslogik handelt es sich nicht um herk"ommliche ABAP/4
Anweisungen.  Vielmehr kann hier nur ein Teil des Sprachvorrats
benutzt werden.  "Ublicherweise erfolgen an dieser Stelle Aufrufe an
Moduln, die ihrerseits im Modulpool formuliert sind bzw.\ wird ein
Teil der Eingabepr"ufungen vorgenommen.

Das Besondere an den Moduln ist, da"s sie im Gegensatz zu den
beschriebenen Unterprogrammen nur aus der Ablauflogik heraus
aufgerufen werden k"onnen.  Es ist nicht m"oglich, Moduln zu
definieren und diese aus einem Programm (Include, Funktionsbaustein
oder Modulpool) anzusprechen.  Eine weitere Einschr"ankung stellt die
Parameter"ubergabe dar, die es nicht gestattet, Argumente zu
"ubergeben.  Ein Modul in ABAP/4 ist demnach nicht mit der Semantik
eines Moduls vergleichbar, wie sie z.B.\ in Modula-2 Anwendung findet.
Vielmehr entspricht der Modul einer Funktion, die darauf angewiesen
ist, auf globalen Variablen des Programms zu arbeiten und in
bestimmten Programmsituationen aufgerufen zu werden.

\subsubsection{Programm}
Der Begriff des Programms wird von SAP in unterschiedlicher Weise
benutzt.  Er bezeichnet eine ablaufbare Einheit und den zugeh"origen
Quelltext, andererseits ist \textit{Programm} ein Oberbegriff f"ur
Programmtypen, von denen es die folgenden gibt:

\begin{itemize}
\item Online-Report
\item Include-Report
\item Funktionsbaustein
\item Modulpool
\end{itemize}

Der Online-Report ist mit einem Programm vergleichbar, wie es in
anderen Sprachen existiert.  Zwar weist er starke "Ahnlichkeit zum
weiter unten beschriebenen Modulpool auf, im Gegensatz zu diesem dient
er in der Regel jedoch der Entwicklung listengenerierender Programme.
Dieser Verwendungszweck wird durch die Development Workbench jedoch in
keiner Weise vorgegeben.

\subsubsection{Include}
Include-Programme dienen dazu, gr"o"sere Programme in kleinere Einheiten zu
zerlegen.  Sie enthalten im allgemeinen keinen eigenst"andig ablaufbaren Code,
sondern werden "uber eine entsprechende Anweisung in ein Programm eingef"ugt.
Dieses Einf"ugen ist mit der C-Pr"aprozessoran\-weisung \verb+#include+
vergleichbar.

Da es sich hierbei um eine rein textuelle Ersetzung der Einf"ugeanweisung mit
dem korrespondierenden Text handelt, werden keine neuen Namensr"aume erzeugt.
Vielmehr befinden sich alle Bezeichner eines Programms auf einer Ebene, auch
wenn die Einf"ugeanweisungen geschachtelt sind.

Der durch Include-Programme erreichbare Nutzen besteht in einer besseren
"Ubersicht innerhalb eines Programms.  Ohne eine einhergehende
Schachtelungsm"oglichkeit von Namensr"aumen kann es jedoch zu Namenskonflikten
kommen, die aufgrund der unterschiedlichen Definitionsorte der Namen schwer zu
durchschauen sind.  Insbesondere scheint auch die in \cite{Abap-Online-Help}
vorgeschlagene Auslagerung einzelner Unterprogramme in sogenannte
Unterroutinenpools (Include-Programme) aus diesem Grund nicht sinnvoll zu sein.

Um das auch von der SAP erkannte Problem der Namenskonflikte zu l"osen, mu"s
der Programmierer strenge Namenskonventionen einhalten.  Der Name einer
Sammlung von Unterroutinen setzte sich z.B. aus den Buchstaben \texttt{SAPF}
gefolgt von einem Buchstaben und zwei Ziffern f"ur den eigentlichen Namen
gefolgt von einem Typkennzeichen zusammen. Z.B.:

\begin{verbatim}
  SAPFM03S
\end{verbatim}

\noindent
Dies steht f"ur die Unterroutine \textit{M03} mit dem Typ \textit{S}.
Include-Programme werden nach dem Muster

\begin{verbatim}
  FaxxyE01
\end{verbatim}

\noindent
benannt, wobei \texttt{axxy} f"ur einen Namen steht, wie er oben
beschrieben ist.  \texttt{E01} bezeichnet ein K"urzel, welches jeder
in diesem Include-Programm vorhandenen Unterroutine vorangestellt wird.
In diesem Fall handelt es sich um extern aufrufbare Unterroutinen,
interne werden z.B.\ mit \texttt{F01} bezeichnet.

\subsubsection{Funktionsbaustein}
Funktionsbausteine besitzen eine "ahnliche Semantik wie Unterprogramme
mit dem Unterschied, da"s sie eine klar definierte Schnittstelle haben
und nicht auf globale Variablen des aufrufenden Programms zugreifen
k"onnen.  Der Zugriff erfolgt ausschlie"slich "uber ihre
Schnittstelle.  Alle Funktionsbausteine eines Systems sind in einer
zentralen Funktionsbibliothek abgelegt.  Eine Schachtelung ist nicht
vorgesehen, was die M"oglichkeiten zur Benennung stark einschr"ankt,
zumal f"ur den Namen lediglich 30 Zeichen zur Verf"ugung stehen.

Funktionsbausteine werden zu Funktionsgruppen zusammengefa"st.
Innerhalb dieser Gruppe k"onnen die Bausteine auf gemeinsame Daten
sowie auf dort definierte Unterprogramme zugreifen.  Beide sind lokal
und nach au"sen nicht sichtbar.  Eine Funktionsgruppe entspricht im
Sinne seines Typs einem Programm, da das sie einleitende
Schl"usselwort (\textit{FUNCTION-POOL}) "aquivalent zu dem eines
Programms ist (\textit{REPORT} bzw.\ \textit{PROGRAM}).  Eine
Funktionsgruppe ist jedoch nicht eigenst"andig ablauff"ahig.  Sie
definiert bzgl.\ der Funktionsbausteinbezeichner keine neuen
Sichtbarkeitsbereiche.

Da pro System jeweils nur eine Funktionsbibliothek existiert, kann der
Verwendungszweck nur auf allgemeing"ultige Aufgaben beschr"ankt sein.
Die Funktionsbibliothek gleicht damit der aus C bekannten
Standardbibliothek (\textit{libc}), die eine blo"se Ansammlung von
allgemein n"utzlichen Funktionen darstellt.  Eine
Programmstrukturierung l"a"st sich mit Funktionsbausteinen nicht
bewerkstelligen, da die Benennungs- und Schachtelungsm"oglichkeiten zu
eingeschr"ankt sind und auch immer nur eine Bibliothek existiert.

\subsubsection{Modulpool}
Ein Modulpool nimmt den Quelltext der Moduln auf, die aus der
Ablauflogik eines Dynpros heraus aufgerufen werden.  Zwischen
Modulpool und Dynpros besteht eine sehr enge Beziehung.  Ein Dynpro
mu"s immer genau einem Modulpool zugeordnet sein, in dem sich die
Moduln der Ablauflogik befinden.

Der Hauptzweck eines Modulpools ist organisatorischer Art.  Er dient
als Zuordnungspunkt f"ur andere Elemente einer Anwendung, wie z.B.\ 
Dynpros oder Oberfl"achen\footnote{Mit Oberfl"achen bezeichnet man die
  Gesamtheit von Men"us, Druck- und Symboltasten, die zu einer
  Bildschirmmaske angezeigt werden k"onnen.  Zur n"aheren
  Begriffskl"arung und weiteren Erl"auterungen siehe
  \cite{abap_einfuehrung}.}.  Auch der Transaktionscode, der zum Aufruf
eines Programms dient, wird am Modulpool und einem Dynpro festgemacht.

Modulpools stehen im gleichen Namensraum wie die anderen Entwicklungsobjekte
vom Typ \textit{Programm}: Funktionsbaustein, Include-Programm,
Online-Programm.  Dies gilt auch f"ur Programme in unterschiedlichen
Entwicklungsklassen.  Diese bieten nur eine organisatorische Unterteilung und
keine Sichtbarkeitsbereiche.

\subsubsection{Dialogbaustein}
Dialogbausteine sind ein weiteres Strukturierungskonzept, welches in
einer h"oheren Abstraktionsebene angesiedelt ist als das der
Funktionsbausteine.  Zwar bieten sie ebenfalls eine fest definierte
Aufrufschnittstelle, vereinen jedoch neben Unterroutinen auch Dynpros
und Oberfl"achen in ihrem Modulpool.

\subsection{Versionierung}
\label{subsec_versionierung}
Von jedem Entwicklungsobjekt k"onnen Versionen angelegt werden.  Der
Begriff der Version wird von der SAP jedoch in Abwandlung der
"ublichen Bedeutung verwendet.  Um dies zu verdeutlichen, wird kurz
die generelle Arbeitsweise des Repositorys erl"autert, in dem alle
Entwicklungsobjekte abgelegt sind (s.a.\ Abbildung
\ref{abb_abap4_version}).

\begin{figure}[ht]
\centering\mbox{\epsfig{file=../Zeichnung/abapversion.eps}}
\caption{Zust"ande von ABAP/4 Entwicklungsobjekten.}
\label{abb_abap4_version}
\end{figure}

Ein Entwicklungsobjekt mu"s nach dem Anlegen (Zustand \textit{neu})
zun"achst aktiviert werden, bevor es von anderen Entwicklungsobjekten
referenziert werden kann.  Beide Zust"ande, wie auch alle anderen in
Abbildung \ref{abb_abap4_version} aufgef"uhrten, werden als Version eines
Objektes bezeichnet.  Tritt beim Aktivieren ein Fehler bei abh"angigen
Objekten auf, weil diese z.B.\ syntaktisch nicht korrekt sind, so
bezeichnet man das Objekt als teilaktiv.

Die Abfolge unterschiedlicher Entwicklungsst"ande wird haupts"achlich
mit den historischen Versionen dokumentiert, w"ahrend der
Entwicklungsproze"s durch eine Zahl weiterer Versionen modelliert
wird.  Die Versionsabfolge der historischen Zust"ande ist in diesem
Modell stets eine sequentielle Abfolge, da eine zur"uckgeholte,
historische Version die "uberarbeitete "uberschreibt.  Eine Verzweigung
des Versionsabfolgegraphen ist nur mit gro"sen Einschr"ankungen,
n"amlich durch eigene Sequentialisierung des Graphen, machbar.  Das
Zusammenf"uhren zweier unterschiedlicher Entwicklungsstr"ange
erfordert manuellen Editieraufwand, da kein entsprechendes Werkzeug zur
Verf"ugung steht.

\subsection{Korrektur- und Transportwesen}
\label{subsec_korrektur}
Das Korrekur- und Transportwesen (KTW) ist ein wesentlicher Teil der
ABAP/4 Development Workbench, der besonders die Entwicklung im Team
unterst"utzt.  Es besteht, wie der Name bereits andeutet, aus zwei
Teilen:

\begin{itemize}
\item Das Korrekturkontrollsystem dient dazu, Entwicklungen
  unterschiedlicher Programmierer in unterschiedlichen Systemen zu
  koordinieren.  Es verfolgt dabei eine "au"serst restriktive Methode,
  indem es, sobald an einem Entwicklungsobjekt gearbeitet wird, jedem
  anderen Entwickler einen "andernden Zugriff darauf verweigert, wenn
  keine entsprechenden Ma"snahmen zur Freigabe getroffen werden.

\item Da eine R/3 Installation meist aus mehreren parallelen Systemen
  besteht, ist es notwendig, in einem System get"atigte "Anderungen 
  auch in ein anderes System "ubernehmen zu k"onnen.  Das ist die Aufgabe
  des Transportwesens.
\end{itemize}

An dieser Stelle k"onnen einerseits aus Platzgr"unden nur
grunds"atzliche Abl"aufe und Konzepte vorgestellt werden, andererseits
kann das KTW in seinem Verhalten durch Anpassungen
(\textit{customizing}) stark ver"andert werden, so da"s sich eine
detaillierte Beschreibung immer auf eine konkrete Installation
beziehen mu"s.

\subsubsection{Systeme}
Der schon mehrfach verwendete Begriff des Systems soll an dieser
Stelle einer genaueren Betrachtung unterzogen werden, mit dem Ziel,
eine m"oglichst exakte Definition zu erlangen.  

Ein SAP R/3 System beinhaltet die komplette Entwicklungsumgebung, je
nach Installation eine Reihe von Anwendungen\footnote{Da auf den
  Anwendungsaspekt des SAP R/3 Systems nicht n"aher eingegangen wird,
  wird vereinfachend von Anwendungen gesprochen.  Diese setzen sich
  aus Hauptanwendungen und Hauptkomponenten zusammen und werden oft
  auch als Module bezeichnet.  N"ahere Informationen finden sich in
  \cite{abap_einfuehrung}.} und Anwenderdaten.  Da es nur ein Exemplar
jeder Softwarekomponente gibt, w"urden sich "Anderungen an diesen
direkt auf die Anwendungen auswirken.  Es ist also notwendig, f"ur den
Programmierer eine M"oglichkeit bereitzustellen, neue Programme zu
testen, ohne die bestehenden Anwendungen zu st"oren.  Hierzu werden
von der SAP verschiedene System-Begriffe eingef"uhrt \cite{r3-admin}.
Abbildung \ref{abb_r3_systeme} zeigt die durch die Systeme gebildete
Hierarchie und die erlaubten Transportrichtungen.

\begin{description}
\item[Entwicklungssystem:] Dieses System ist, wie der Name zum Ausdruck bringt,
  f"ur die Entwicklung vorgesehen.  Allerdings werden hier nur solche
  Komponenten entwickelt, die besonders kritisch sind und deshalb von der
  "ubrigen Entwicklung im Integrationssystem getrennt werden m"ussen.

\item[Integrationssystem:] Das ist das eigentliche Entwicklungssystem,
  in dem die Programmierung normaler Anwendungen und deren Tests
  erfolgt.

\item[Konsolidierungssystem:] In diesem System werden die unterschiedlichen
  Entwicklungen der Entwicklungs- und Integrationssysteme zusammengef"uhrt,
  wobei ein direkter Transport von Objekten aus einem Entwicklungssystem in ein
  Konsolidierungssystem nicht erlaubt ist.

\item[Auslieferungssystem:] 
\begin{sloppypar}
  Hierher werden die Entwicklungen aus dem Konsolidierungssystem letztendlich
  transportiert.  Beim Auslieferungssystem kann es sich um ein produktiv
  eingesetztes System handeln.
\end{sloppypar}
\end{description}

Es m"ussen nicht immer alle Systeme installiert werden.  Meist kommen
aber Integrations- und Konsolidierungssystem zum Einsatz.  Werden
nicht alle Systemtypen verwendet, kann auch das Konsolidierungssystem
das Produktivsystem sein.

Der Sinn dieser verschiedenen Systeme besteht darin, die
Entwicklungsarbeit des Programmierers von der Arbeit des Anwenders zu
entkoppeln und somit zu verhindern, da"s produktiv eingesetzte Daten
oder Programme ge"andert werden.  Dies k"onnte allerdings auch mit
einer entsprechend leistungsf"ahigen Versionskontrolle, die die
Verzweigung des Versionsabfolgegraphens erlaubt, in Kombination z.B.\ 
mit dem Arbeitsbereichs-Modell der Teamwareumgebung erreicht werden.

Der System-Begriff ist eine Unterteilung auf der Ebene der
Entwicklungsklassen.  Eine Instanz eines SAP R/3 Systems kann somit
f"ur eine Klasse Konsolidierungs- und f"ur eine andere Klasse
Integrationssystem sein.

\begin{figure}[ht]
\centering\mbox{\epsfig{file=../Zeichnung/r3_systeme.eps}}
\caption{Arten von Systemen im R/3 System und die erlaubten Transportwege 
zwischen ihnen (aus \protect \cite{r3-admin}).}
\label{abb_r3_systeme}
\end{figure}

\subsubsection{Korrekturkontrollsystem}
Kern dieses Teils des KTW ist das Konzept des Originalobjektes.  Ein
Entwicklungsobjekt kann danach jeweils nur im Original ver"andert werden.  Da
ein Objekt nur in einem der installierten Systeme im Original vorliegt, kann es
auch nur dort bearbeitet werden.  Dies hat zur Folge, da"s jeweils nur ein
Entwickler bzw.\ Team an einem Objekt im Originalsystem arbeiten kann,
parallele Entwicklung zwischen mehreren Entwicklern in unterschiedlichen Teams
bzw.\ verschiedenen Teams ist damit praktisch ausgeschlossen.  Das Objekt kann
einem anderen System als Originalsystem zugeordnet werden.

Bei der Erstellung wird einem Objekt ein Entwickler oder ein Team von
Entwicklern zugeordnet.  Es kann dann auf zwei unterschiedlichen
Ebenen f"ur den Zugriff gesperrt werden.  Nach Erzeugung des Objektes
ist es automatisch auf erster Ebene gesperrt, eine Korrektur auf
dieses Objekt wurde er"offnet.  Es kann dann von Entwicklern des
gleichen Teams ebenfalls modifiziert werden, wobei jeder Entwickler
eine eigene Korrektur er"offnet und seine eigene Version erh"alt.
Dieser Vorgang wird als Vernetzen einer Korrektur bezeichnet.  Auf der
zweiten Stufe k"onnen Objekte vollst"andig gegen Modifikation anderer
gesperrt werden.

Eine Ausnahme des Originalkonzeptes bilden die Reparaturen.  Sie
erlauben es, auch an Kopien eines Objektes, also durch Transporte
entstandenen Objektes, "Anderungen durchzuf"uhren.  Durch Reparatur
ge"anderte Objekte m"ussen jedoch wieder mit dem Original im
Originalsystem zusammengef"uhrt werden, bevor sie durch neue Versionen
aktualisiert werden k"onnen.  Reparaturen eignen sich somit nicht zur
Parallelentwicklung.

\subsubsection{Transportwesen}
Hauptaufgabe des Transportwesens ist es, die Entwicklungsobjekte
zwischen den verschiedenen Systemen zu bewegen.  Dabei gibt es die in
Abbildung \ref{abb_r3_systeme} gezeigten Beschr"ankungen.  Existieren
mehrere Systeme einer Art, kann auch zwischen diesen Systemen ein
Austausch erfolgen.  SAP selbst nutzt das Transportwesen, um
Aktualisierungen ihres Systems in die Kundensysteme einzuspielen.

Das Transportwesen arbeitet auf Entwicklungsumgebungsobjekten.  Es
handelt sich dabei um die Zusammenfassung von Entwicklungsobjekten,
die in Beziehungen zueinander stehen.  Entwicklungsumgebungsobjekte
sind dar"uberhinaus in Typen eingeteilt, die eine genaue Spezifikation
der abh"angigen Entwicklungsobjekte erlaubt.  Z.B. hat das
Entwicklungsumgebungsobjekt \texttt{R3TR PROG} den Objekttyp
\texttt{R3TR}\footnote{Die Begriffsbildung in der Literatur ist an
  dieser Stelle nicht eindeutig.  Gelegentlich wird auch \texttt{PROG}
  als Objekttyp und \texttt{R3TR} als Programm-ID bezeichnet.}.
\texttt{R3TR} legt dabei fest, da"s ein ABAP/4 Programm und von ihm
abh"angige Bestandteile gemeint sind.  Zusammengenommen umfa"st das
Entwicklungsumgebungsobjekt ein ABAP/4 Programm mit seinen
Oberfl"achen, Dynpros, Texten und Dokumentationen.  Dieses
Entwicklungsumgebungsobjekt kann nun auf ein konkretes
Entwicklungsobjekt angewendet werden und legt damit fest, welche
Objekte transportiert werden sollen.

Eine Entwicklungsklasse umfa"st in einer weiteren Gliederungsebene
mehrere Entwicklungsumgebungsobjekte.  Der Transport kann auch auf
deren Basis durchgef"uhrt werden.

Der Transport zwischen zwei Systemen erfolgt dann in zwei Phasen:

\begin{itemize}
\item In der Exportphase werden die durch Entwicklungsklassen oder
  Entwicklungsumgebungsobjekte spezifizierten konkreten
  Entwicklungsobjekte auf Betriebssystemebene des Quellsystems in eine
  Datei geschrieben.  Das Format dieser Datei ist
  plattformunabh"angig.
\item Die Importphase wird auf dem Zielsystem explizit angesto"sen.
  Hierbei kann es sich um die gleiche oder eine andere SAP R/3 Instanz
  handeln.
\end{itemize}

\subsection{Integration und Basisdienste}
Die ABAP/4 Development Workbench zeichnet sich durch Integration auf
verschiedenen Ebenen aus:

\begin{itemize}
\item Die Development Workbench arbeitet mit einer zentralen Datenbank, dem
  Repository, das alle Entwicklungsobjekte und Beziehungen zwischen ihnen
  verwaltet.  Alle Komponenten greifen auf diese gemeinsame Datenbasis zu.  Auf
  diese Weise wird Datenintegration erreicht.

\item Kontrollflu"sintegration wird in der Umgebung erreicht, da alle Werkzeuge
  in beliebiger Reihenfolge ausgef"uhrt werden k"onnen.

\item Durch die einheitliche Verwendung der durch ABAP/4 bereitgestellten
  grafischen Elemente zur Gestaltung von Benutzeroberfl"achen, erhalten alle
  Komponenten ein einheitliches Erscheinungsbild.  
\end{itemize}

Durch ihre enge Verflechtung sind die einzelnen Werkzeuge der
Entwicklungsumgebung als Programm nicht voneinander zu unterscheiden.  Die
Unterteilung in verschiedene Komponenten erfolgt mehr auf konzeptueller Ebene.

Die Basisdienste, die den Werkzeugen zur Verf"ugung stehen, werden einerseits
durch das Repository als Objektverwaltung bereitgestellt, andererseits durch
das SAP R/3 System und seine Programmiersprache ABAP/4, welche grundlegende
Betriebs\-system- und Kommunikationsfunktionalit"at liefern bzw.\ 
f"ur den Programmierer erledigen.

%Die Bewertung der ABAP/4 Development Workbench kann nicht von den
%allgemeinen in Abscnitt \ref{sec_entwicklungsumgebung} entworfenen
%Anforderungen ausgehen.  Vielmehr soll hier dem Umstand Rechnung
%getragen werden, da"s es sich um ein f"ur eine spezielle Gattung von
%Anwendungsprogrammen erstelltes System handelt.
%
%Als positives Merkmal ist die hohe Integration in das umgebende System
%und die Werkzeugunterst"utzung zu nennen.  Auch die f"ur den
%Programmierer vollst"andig transparent durchgef"uhrte
%Systemgenerierung kann als Vorteil angesehen werden.
%
%Wenig Freiheitsgrade werden dem Programmierer bei der Strukturierung
%von Anwendungen gelassen.  Zum einen sind die
%Strukturierungsmechanismen nicht orthogonal kombinierbar, zum anderen
%erf"ullen sie wie im Falle der Moduln und Unterroutinen sehr "ahnliche
%Aufgaben.  Ein Modul ist in ABAP/4 eine Unterroutine ohne Parameter
%und somit als Konstrukt "uberfl"ussig.  Das Modul-Konstrukt schr"ankt
%zus"atzlich die Wiederverwendung ein, da stets angegeben werden mu"s,
%aus welchem Ereignis heraus es aufgerufen werden soll.
%
%Ein weiterer gewichtiger Nachteil der Strukturierungskonzepte ist das
%Fehlen geeigneter Sichtbarkeitsbereiche.  Stattdessen werden diese
%Schw"achen durch vom System vorgegebene Namenskonventionen verdeckt,
%die in vielen F"allen durch zus"atzliche Restriktionen in der
%Namensl"ange eine ad"aquate Namensgebung verhindern.
%
%Ebenfalls eingeschr"ankt ist das Modell zur Unterst"utzung der
%Teamentwicklung.  Zwar kann sichergestellt werden, da"s bestimmte
%Objekte nur in bestimmten Systemen und von bestimmten Entwicklern
%bearbeitet werden, da der Begriff des Systems jedoch an
%Entwicklungsklassen gebunden ist, kann hinsichtlich der zum "Andern
%zugelassenen Objekte leicht eine Un"ubersichtlich\-keit entstehen.


