\chapter{Moderne Entwicklungsumgebungen}

Teamware : Dateisystem
ABAP4 DW : RDBMS

\section{Teamware 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.

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 zugrundegelegte Dokumentation ist in diesem Punkt
nicht eindeutig.  Das FileMerge-Werkzeug wird sowohl der SPARCworks/ProWorks
als auch der SPARCworks/TeamWare zugerechnet
\cite{teamware,proworks}.  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:

\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[Source Code Browser:] Dieses Werkzeug dient dazu, w"ahrend der
Programmentwicklung den "Uberblick "uber ein Softwareprojekt zu behalten oder
zu erlangen.  Es gestattet es 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}.

\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 etc. zur
Laufzeit.  Zu diesem Zweck lie"st 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, den Engpa"s zu ermitteln um
diesen anschlie"send zu beseitigen.  W"ahrend des Debuggens kann er
Informationen "uber das laufende Programm sammeln, z.B. wieviel Prozessorzeit
f"ur die Abarbeitung bestimmter Programmteils 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.

\begin{description}

\item[Versiontool:]  Bei der Softwareentwicklung insbesondere in einem Team
werden die "Anderungen 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 erledigt.

\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{workspace}) eingef"uhrt, welches jedem
Entwickler sein eigenen Entwicklungsbereich zuordnet.  "Anderungen, werden in
einem "ubergeordneten Arbeitsbereich konsolodiert.  Dieses Werkzeug macht sich
die Versionverwaltung SCCS und eine Verzeichnisstruktur, die die Organisation
in Arbeitsbereiche wiederspiegelt, zunutze, um die beschriebenen Aufgaben zu
erf"ullen.

\item[ParallelMake:] Wie das weiter unten beschriebene MakeTool, bietet auch
das ParallelMake ein grafisches Frontend zum \textit{make}-Programm.  Es
benuztt 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}

Warum werden welche Komponenten weiter untersucht?

\subsection{Versionsverwaltung}
Versionskontrolle:
- VersionTool: grafisches Frontend zu SCCS.
- Check in, check out Mechanismus
- Versionsabfolge, Verzweigung

\subsection{Teamunterst"utzung}
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 Arbeitsbereich 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, in denen Arbeitsbereiche auf mittleren Stufen als Integrationsbereich
f"ur unterliegende Bereiche fungieren, sind m"oglich.

\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 inklusiver seiner
Unterverzeichnisse, die die entsprechenden Dateien beherrbergen.  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 Datei, 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 "Anderungen "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 mit 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-Arbeitsberiech 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 den "ubergeordneten konsistent (f"ur
alle anderen untergeordenten Arbeitsbereiche) zu halten.

% - 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{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 zeichnet sich die
Development Workbench durch eine hohe Integration in ein anderes
System, das SAP R/3 System, aus.  Ebenfalls fest in die Umgebung
integriert ist die 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.}.  Durch die starke
Verflechtung der Programmiersprache mit den Werkzeugen der
Entwicklungsumgebung ist es sinnvoll, auch Aspekte, die eigentlich der
Sprache selbst zugeordnet werden m"ussen, hier zu behandeln.  Dazu
z"ahlen 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, wie noch
gezeigt wird, 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.

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

Von den in Kapitel \ref{cha_entwicklungsumgebung} entwickelten
Anforderungen an eine Entwicklungsumgebung werden nur die folgenden
Aspekte untersucht: Abschnitt \ref{sub_strukturierung} beleuchtet die
M"oglichkeiten, die die Programmiersprache ABAP/4 und die Development
Workbench zur Strukturierung bereitstellen.  Abschnitt
\ref{sub_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{sub_korrektur} vorgestellt.
Eine Bewertung beschlie"st die Ausf"uhrungen zur ABAP/4
Entwicklungsumgebung.


Aspekte des Konfigurationsmanagements und weitere Unterst"utzung f"ur
ein Lebenszyklusmodell (\textit{life cycle support}) sind nicht in der
Entwicklungsumgebung ber"ucksichtigt worden \cite{tcmanagement}.
Nicht in die Betrachtung einbezogen werden 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-Anwendung 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{sub_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{sub_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 Unterprogrammvariablen mit entsprechenden Operationen
angelegt werden. Auch eine Schachtelung ist nicht m"oglich.

Innerhalb von Unterroutinen ist die Verwendung von lokalen Variablen
m"oglich.  Diese "uberdecken dabei die m"oglicherweise bereits global
definierten Variablen.  Zu undefiniertem Verhalten kommt es, wenn eine
lokale Variable in Konflikt zu einem gleichnamigen Funktionsargument
tritt \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.  Alternativ 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 wei"st er starke "Ahnlichkeit zum
weiter unten beschriebenen Modulpool auf, im Gegensatz zu diesem dient
er in der Regel jedoch zur Entwicklung listengenerierender Programme.
Dieser Verwendungszweck wird durch die Development Workbench jedoch in
keinster 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"aprozessoranweisung \verb+#include+ vergleichbar.

Da es sich hierbei um eine rein textuelle Ersetzung der
Einf"ugeanweisung mit dem korrespondierenden Text handelt, werden
keine neuen Namesr"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, wird der Programmierer dazu angehalten, strenge
Namenskonventionen einzuhalten.  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 Programme 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, indem 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, wie sp"ater
ausf"uhrlich erl"autert wird, 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{sub_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{M"ogliche Abfolgen von Versionen\protect \footnotemark\ 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 Entwicklungsobjekte
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 Entwicklungst"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.  Ein 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.  \footnotetext{Versionen, die ausschlie"slich
  SAP-Objekte betreffen, wurden nicht in die Darstellung aufgenommen.}

\subsection{Korrektur- und Transportwesen}
\label{sub_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, get"atigte "Anderungen in einem System
  auch in ein anderes System "ubernehmen zu k"onnen.  Das
  Transportwesen hat die Aufgabe, dies zu erledigen.
\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 getrennt werden m"ussen.
\item[Integrationssystem:] Dies 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.
\item[Auslieferungssystem:] Hierher werden die Entwicklungen aus dem
  Konsolidierungssystem letztendlich transportiert.  Beim
  Auslieferungssystem kann es sich um ein produktiv eingesetztes
  System handeln.
\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 Klassen
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 unterschiedlichen Teams bzw.\ verschiedenen Teams
ist damit praktisch ausgeschlossen.  Das Originalsystem eines Objektes
kann ver"andert 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
entstandene Objekte, "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{Bewertung}
Die Bewertung der ABAP/4 Development Workbench kann nicht von den
allgemeinen in Kapitel \ref{cha_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"ubersichtlichkeit entstehen.


