LeseprobeIn dieser Leseprobe lernen Sie die Grundlagen und Techniken zur Entwicklung von Entwurfsmustern kennen.

Nurgül Atilgan, Markus Straub

Entwurfsmuster in ABAP357 Seiten, gebunden, Januar 2015 69,90 Euro, ISBN 978-3-8362-2833-6

www.sap-press.de/3579

Kapitel 2: »Umgang mit Entwurfsmustern«

Inhalt

Index

Die Autoren

Leseprobe weiterempfehlen

Wissen aus erster Hand.

37

Um Software wiederverwendbar und einfach zu entwickeln,ist es sehr wichtig, die abzubildenden Prozesse genau zuspezifizieren. Dabei helfen Ihnen Kenntnisse in UML undABAP Objects.

2 Umgang mit Entwurfsmustern

In diesem Kapitel erläutern wir die Grundlagen und Techniken zurEntwicklung von Entwurfsmustern. Zu Beginn zeigen wir auf, wieSie die Problemstellungen, die ein Entwurfsmuster lösen soll, inUML abstrakt aufzeichnen und so Lösungswege definieren können.Darüber hinaus bringen wir Ihnen in diesem Kapitel die Grundlagenund wichtigen Elemente der SAP-Entwicklung näher, damit Sie dieEntwurfsmuster in SAP-Entwicklungsprojekten einsetzen können.

2.1 UML-Grafiken erstellen

UMLDie Unified Message Language (UML) ist eine Modellierungssprache,mit der Sie Anwendungen und deren Sachverhalte durch standardi-sierte Notationen abbilden können. Durch diese Abbildung werdendie Sachverhalte abstrahiert, und die Geschäftsprozesse können fürandere verständlich und sichtbar dargestellt werden. Dies ist zumeinen wichtig, da die Prozesse so überprüft werden können, umfrühzeitig eventuell enthaltene Fehler zu entdecken. Zum anderenkann der Software-Entwickler dieser Modelle heranziehen, um dieAnwendung zu realisieren.

DiagrammtypenIn UML gibt es unterschiedliche Möglichkeiten, Anwendungen undderen Bestandteile übersichtlich und verständlich zu gestalten. Dafürstehen verschiedene Diagrammtypen zur Verfügung. Jeder dieserTypen hat seine Bewandtnis und ist für die vollständige Modellie-rung einer Anwendung erforderlich.

UML und BPMNUML entwickelt sich stetig weiter und wird immer wieder durch dieObject Management Group neu definiert. Dieses Konsortium entwi-

Umgang mit Entwurfsmustern2

38

ckelt auch die Modelliersprache Business Process Model and Notation(BPMN) stetig weiter und veröffentlicht regelmäßig neue Versionen.Während UML sich mit der grafischen Beschreibung von objektori-entierten Modellen befasst, ermöglicht BPMN die Beschreibung vonGeschäftsprozessen mithilfe grafischer Elemente. Diese Elementehaben jeweils ihre spezifische Bedeutung, die von der ObjektManagement Group in einem Regelwerk festgehalten wird. Abbil-dung 2.1 stellt die beiden Sprachen in den Versionen BPMN 2.0 undUML 2.0 gegenüber. Dabei entsprechen die dargestellten Objekteder Notationen links (BPMN 2.0) denen der Notationen auf der rech-ten Seite (UML 2.0). In der Praxis wird heutzutage meistens UML 2.0angewendet, da UML aus deutlich weniger Elementen besteht unddadurch viel einfacher einzusetzen ist.

Abbildung 2.1 Vergleich von BPMN 2.0 und UML 2.0

In BPMN stehen dagegen für viele Situationen und Aktionen jeweilseigene Symbole zur Verfügung. BPMN wurde geschaffen, um einfa-che Geschäftsprozessmodelle abzubilden. Da jedoch auch komplexeGeschäftsprozesse darstellbar sein sollten, ist mit der Zeit eine großeMenge von Darstellungselementen entstanden. SAP Business ProcessManagement (BPM) wird z.B. von BPMN unterstützt. Mit diesemWerkzeug lassen sich Geschäftsprozesse modellieren, ohne die Not-wendigkeit, Code zu schreiben.

UML 2.0

Schleife

Schleife

wiederholen

BPMN 2.0

BPMN Activityparallele Mehrfach-ausführung

BPMN Activity

Schleife

UML-Grafiken erstellen 2.1

39

Im Folgenden gehen wir auf die im UML zur Verfügung stehendenDiagrammtypen näher ein.

2.1.1 Klassendiagramm

Beziehungen

zwischen Klassen

Das Klassendiagramm ist eine Variante eines UML-Diagramms, dasKlassen und deren Beziehung zueinander beschreibt. In einem Klas-sendiagramm werden die Klassen als Rechtecke dargestellt. In denRechtecken werden die einzelnen Attribute und Methoden der Klas-sen angezeigt. In der Praxis ist diese Darstellung nicht immer voll-ständig, je nachdem, ob das Diagramm aus Fachbereichs- oder Ent-wicklungssicht erstellt wurde. Der Fachbereich beschreibt einenProzess immer aus betriebswirtschaftlicher Sicht; hierbei werdenaber womöglich wichtige Informationen vergessen, die der Entwick-ler zur Modellierung der Anwendung benötigt.

BeispielUm die Klassen miteinander in Beziehung zu setzen, werdenPfeile verwendet. Es gibt unterschiedliche Pfeile, die eine Verer-bung, Abstraktion oder das Interface einer Klasse kennzeichnen.Abbildung 2.2 zeigt ein Beispiel für ein UML-Klassendiagramm.Sie sehen oben die Superklasse formen, die zwei Attribute (ge-kennzeichnet mit einem Minuszeichen) und drei Funktionen (ge-kennzeichnet mit einem Pluszeichen) enthält.

Abbildung 2.2 Beispiel für ein UML-Klassendiagramm

formen

– Mittelpunkt :int– sichtbar :boolean

+ anzeigen() :void+ entfernen() :void+ verschieben() :void

linie

– ZahlA :int– ZahlB :int– ZahlC :int

+ anzeigen() :void+ entfernen() :void+ verschieben() :void

kreis

– Radius :int

+ anzeigen() :void+ entfernen() :void+ verschieben() :void

stern

Methoden werdenvererbt oderüberschrieben

– ZahlA :int– ZahlB :int

+ anzeigen() :void+ entfernen() :void+ verschieben() :void

Umgang mit Entwurfsmustern2

40

Die weiteren drei Klassen linie, kreis und stern erben die Funktio-nen von der Klasse formen, wobei der Programmcode der Super-klasse ausgeführt wird. Die Klasse stern kann die Methoden anzei-gen() oder entfernen() aber auch überschreiben, sodass hiereigener Programmcode ausgeführt wird. Dies können Sie am Bei-spiel der Funktion anzeigen() sehen. Die Klasse formen selbst imple-mentiert die Anzeigefunktion nicht aus, dies erfolgt in den erbendenKlassen.

Abstrakte Klassen Abstrakte Klassen werden in UML mit dem Präfix {Abstract} gekenn-zeichnet. Diese Klassen können nicht instanziiert werden. Es handeltsich um beschreibende Klassen, die an eine andere Klasse angedocktwerden, oft durch Vererbung. Über die Vererbung werden das Ver-halten und die Eigenschaften der abstrakten Klasse formen als Objektdefiniert. Eine abstrakte Klasse wird nie selbst implementiert, son-dern die Implementierung findet in den erbenden Klassen statt.

Sichtbarkeiten Sichtbarkeiten beschreiben, wie die Methoden und Attribute vonanderen Klassen und Methoden wahrgenommen werden können.Um Sichtbarkeiten der Funktionen, aber auch die Attribute selbstbesser beschreiben zu können, können Sie in UML ein paar zusätzli-che Operanden verwenden. Die Sichtbarkeiten werden immer vordas Attribut geschrieben. Hier werden vier Kategorien unterschie-den, die in Tabelle 2.1 aufgeführt sind.

Datentypen

zuweisen

Um den Attributen einen Datentyp zuzuweisen, werden die Attri-bute, die in einer Klasse stehen, hinterlegt. Auf die gleiche Weisewerden auch den Methoden Datentypen zugewiesen. Die Angabenkönnen wie folgt definiert werden:

� Attribute:

Sichtbarkeit des Attributsnamens im Datentyp hinterlegen:

+ Auftragsnummer:Y_DE_AUFTRAGSNR (DDIC)

Notation Kategorie Beschreibung

+ public für alle Klassen sichtbar

~ package für alle im gleichen Paket sichtbar

# protected für alle befreundeten Klassen und Interfaces

- private nur für die eigene Klasse sichtbar

Tabelle 2.1 Operanden zur Beschreibung der Sichtbarkeit von Klassen

Grundlagen der objektorientierten Programmierung mit ABAP 2.2

43

Sie erkennen den zeitlichen Ablauf der Aktionen, die das Programmausführen soll, um erfolgreich durchgeführt zu werden. Dabei wirdaufgezeigt, welche weiteren Klassen und Objekte involviert sind. Indiesem Beispiel wird der Ablauf mit einem Kommando in Ganggesetzt. In Rechtecken können Sie die Klassen erkennen, Kreisekennzeichnen Aktionen, die durch den Anwender ausgelöst werden.

2.2 Grundlagen der objektorientierten Programmierung mit ABAP

In diesem Abschnitt machen wir Sie mit den Grundlagen der objekt-orientierten Programmierung mit ABAP vertraut. Das Verständnisdieser Konzepte ist die Voraussetzung, um Entwurfsmuster in ABAPumsetzen zu können. Dieser Abschnitt richtet sich in erster Linie anEntwickler, die keine oder noch wenig Erfahrung mit der SpracheABAP haben. Wir stellen Ihnen die Besonderheiten und die Umset-zung des Konzepts der Objektorientierung vor. Wenn Sie bereitsErfahrung mit ABAP Objects haben, können Sie diesen Abschnittüberspringen.

Die Objektorientierung ist die Grundlage für die Nutzung von Ent-wurfsmustern bei der Anwendungsentwicklung. Über 80% der Ent-wurfsmuster basieren auf der objektorientierten Entwicklung. Dieanderen 10% basieren auf klassenbasierter Entwicklung, die auchohne Objektorientierung möglich ist.

2.2.1 ABAP Objects

Ganzheitlicher

Ansatz

ABAP Objects ist die Bezeichnung für die objektorientierte Ausrich-tung der Sprache ABAP. Die Objektorientierung ist in erster Linie alsProgrammierkonzept bekannt. Die Objektorientierung sollte immerdas gesamte Entwicklungsprojekt betrachten, sodass die Objektori-entierung vom Entwurf bis zur Implementierung erfolgt.

Sie kennen den objektorientierten Ansatz vielleicht bereits ausanderen Programmiersprachen wie Java oder C. Er löst die prozedu-rale Programmierung ab, die heute noch sehr verbreitet ist, z.B. inden Sprachen Visual Basics for Applications (VBA) für MicrosoftOffice und ANSI C, einem Ende der 1980er Jahre formulierten Stan-dard der Programmiersprache C. Objektorientierte Programmier-

Umgang mit Entwurfsmustern2

44

sprachen können komplexere Entwicklungen viel übersichtlicherdarstellen. Eine weitere große Stärke des objektorientierten Ansat-zes ist die Wiederverwendbarkeit von Methoden und Klassen.

Historische

Programmier-

ansätze

Nachdem in den 1950er Jahren die ersten Programmiersprachenaufkamen, gab es in den 1970er Jahren die ersten funktionsgetriebe-nen Ansätze, wie z.B. Hierarchy plus Input Process Output (HIPO). Ausdiesen Ansätzen gingen in den 1980er Jahren datengetriebeneAnsätze hervor. Programmiersprachen, die in diesem Zuge entstan-den, werden auch als prozedurale Programmiersprachen bezeichnetund werden noch häufig eingesetzt. Aus diesen Programmierpara-digmen sind schließlich die objektorientierten Programmieransätzehervorgegangen. Wichtige Werkzeuge für die objektorientierteAnwendungsentwicklung sind UML und BPMN. Abbildung 2.5 ver-anschaulicht diese Entwicklung.

Abbildung 2.5 Entwicklung der Programmiersprachen

Vorteile der Objekt-

orientierung

Durch die Weiterentwicklung der Programmiersprachen wurdenjeweils deutliche Verbesserungen erzielt, die mit den objektorien-tierten Programmiersprachen ihr Ende nahmen. Die Objektorientie-rung ermöglicht einen höheren Wiederverwendungsgrad der Soft-ware. Die Sichtbarkeit von Variablen und Modulen kann vielfiligraner gesteuert werden als bei prozeduralen Sprachen. Vor derObjektorientierung gab es keine Gruppierung von Methoden ineiner Klasse bzw. Funktionsgruppe.

Vorteile von

ABAP Objects

ABAP Objects bietet neben der Objektorientierung noch weitereVorteile gegenüber dem Standard-ABAP. Mit ABAP Objects wurde

funktionsgetriebene Ansätze(z. B. HIPO)1970

1980 datengetriebene Ansätze(z. B. strukturierte Analyse)

1990 objektorientierte Ansätze(z. B. UML)

Grundlagen der objektorientierten Programmierung mit ABAP 2.2

45

der Wiederverwendungsgrad der Softwarekomponenten erheblichgesteigert. Die Sichtbarkeit von Methoden, Attributen und Ereignis-sen können Sie in ABAP Objects deutlicher mit den Kategorienpublic, protected und private steuern. Die Erweiterung einerAnwendung ist durch die transaktionale Objektsteuerung realisier-bar, bei der die Reihenfolge der Objektbearbeitung eingehaltenwird. Auf diese Weise kann eine bessere Kapselung der Software-komponenten stattfinden. Die Kommunikation erfolgt nur nochüber klar definierte Schnittstellen, wodurch man die Software robus-ter und weniger angreifbar macht.

Nachteile von

ABAP Objects

ABAP Objects hat jedoch nicht nur Vorteile, sondern auch nochnicht gelöste Eigenschaften. Methoden können bei ABAP Objectsnoch nicht RFC-fähig (Remote Function Call) aufgerufen werden.Hierzu muss aktuell der Umweg über einen RFC-fähigen Funktions-baustein gegangen werden. Dynpros können nicht in Klassen er-stellt werden, sondern werden immer über einen Funktionsbau-stein oder Programme gekapselt. Um ABAP Objects in der täglichenProgrammierung zu verwenden, müssen Sie Zeit investieren, umdie objektorientierte Programmierweise zu beherrschen und ent-sprechend einzusetzen.

Remote Function Calls

RFC-Verbindungen werden zur Kommunikation mit anderen Systemen(SAP oder Nicht-SAP-Systeme) eingesetzt. Mit dem RFC-Verfahren lassensich Funktionsaufrufe zwischen zwei SAP-Systemen umsetzen. Mit derAnweisung CALL FUNCTION … DESTINATION kann ein entfernter Funk-tionsbaustein (Remote-Baustein) aufgerufen werden. Dazu muss der RFC-Funktionsbaustein als remote definiert sein.

2.2.2 Klassen in ABAP

Eine Klasse definiert einen Rahmen oder Instanzen eines Objekts. Indiesem Rahmen können Typen, Funktionen oder Attribute definiertwerden, die dann bei der Verarbeitung der Funktionen oder beieinem externen Aufruf abgerufen werden.

Lokale KlassenLokale Klassen werden in Programmen selbst definiert und könnendann auch nur in diesem Programm wiederverwendet werden. Wirdin einem ABAP-Report ein Include-Programm eingebunden, entste-hen im Hintergrund zwei eigenständige Klassen, die einen identi-

Umgang mit Entwurfsmustern2

46

schen Aufbau haben, aber nicht typkompatibel sind. Typkompatibelbedeutet, dass die Objekte der Klassen nicht gegenseitig von denKlassen verwendet werden können.

Globale Klassen Globale Klassen werden im ABAP Dictionary erstellt und abgelegt. Siesind typkompatibel und können dadurch in jedem ABAP-Reportdirekt verwendet und miteinander vermischt werden. Diese Klassenlegen Sie über den Class Builder, d.h. über die Transaktion SE24 an(siehe Abbildung 2.6). Es gibt noch weitere Untertypen von Klassenin ABAP, die wir im Folgenden erläutern.

Abbildung 2.6 Class Builder zum Anlegen einer Klasse

Auch alle Komponenten der Klassendefinitionen, die Sie in einerlokalen Klasse in den Quelltext einer Anwendung eingeben, werdenim Class Builder auf den einzelnen Registerkarten erfasst (sieheAbbildung 2.7). Um eine Klasse zu verwenden, müssen Sie dieseaktivieren.

Abbildung 2.7 Class Builder – Registerkartenpflege

Grundlagen der objektorientierten Programmierung mit ABAP 2.2

47

SichtbarkeitenÜber die Sichtbarkeiten definieren Sie, ob Attribute, Methoden oderEreignisse von anderen Klassen verwendbar sein sollen oder nicht.Auf diese Weise können Sie eine Klasse von außen (d.h. von anderenKlassen) unverwundbar machen. Im Class Builder stehen Ihnen diefolgenden Sichtbarkeiten zur Auswahl:

� publicDie Klassenbestandteile sind für alle Klassen sichtbar und definie-ren die Schnittstelle der Klasse nach außen.

� protectedDie Klassenbestandteile sind nur für die vererbten (verwandten)Klassen sichtbar und zugreifbar.

� privateDie Klassenbestandteile sind nur für die Klasse selbst sichtbar undzugreifbar.

KonstruktorenKonstruktoren werden bei jedem Erzeugen einer Instanz einer Klasseaufgerufen, sofern sie in der Klasse vorhanden sind. Der Konstruktorwird mit dem reservierten Methodennamen CONSTRUCTOR erstelltund abgelegt (siehe Abbildung 2.8). Dieser Konstruktor hat keineImportparameter. Die einzige Ausnahme besteht bei einem ABAP-Report mit Select-Option-Feldern, hierbei erhält der Konstruktordiese Felder als Importparameter.

Importparameter in Konstruktoren

Über Importparameter im Konstruktor werden Werte übernommen, dieder Objekterzeugung dienen.

Abbildung 2.8 Konstruktor in einer ABAP-Klasse

Umgang mit Entwurfsmustern2

48

Statische Klassen Bei statischen Klassen ist ein sogenannter Klassenkonstruktor vorhan-den. Dieser wird einmalig bei der ersten Instanziierung der Klasseausgeführt, d.h. dem ersten Zugriff auf die Klasse. Dieser Konstruk-tor wird mit dem reservierten Methodennamen CLASS_CONSTRUCTORin der Klasse erstellt. Diese Methode ist nur beim ersten Zugriff zusehen; wurde eine statische Klasse bereits instanziiert, finde Sie die-sen Eintrag nicht mehr. Den Klassenkonstruktor legen Sie ebensowie den normalen Konstruktor im Class Builder an (über denMenüpfad Bearbeiten � Klassenkonstruktor anlegen, siehe Abbil-dung 2.9).

Abbildung 2.9 Klassenkonstruktor anlegen

Attribute Bei Attributen werden drei Typen unterschieden:

� statische AttributeDiese Attribute sind an die Klasse gebunden und werden nicht beider Instanziierung der Klasse initialisiert. Bei neuen Objekten derKlasse bleibt das Attribut bzw. dessen Wert gleich. Auf die Attri-bute wird folgendermaßen zugegriffen:

Klassenname=>Attributsname

� InstanzattributeDiese Attribute sind an die Instanz der Klasse gebunden. Sie wer-den bei der Instanziierung des Klassenobjekts initialisiert. Auf dieAttribute wird wie folgt zugegriffen:

Objektname->Attributsname

� KonstanzattributeDiese Attribute sind komplett unabhängig von statischen undInstanzattributen. Auf die Attribute wird wie folgt zugegriffen:

Klassenname=>Konstante

Grundlagen der objektorientierten Programmierung mit ABAP 2.2

49

Die Attribute können unterschiedliche Werte aus dem ABAP Dictio-nary repräsentieren, z.B. Tabellen, Strukturen, Datenelemente, Klas-sen oder Datentypen. Bei der dynamischen Programmierung werdendiese Datentypen erst während der Laufzeit definiert, da sie wäh-rend der Laufzeit generiert werden. Hierbei wird oft der dynamischeDatentyp ANY oder TABLE verwendet.

InstanzmethodenUm Funktionen in ABAP-Klassen umzusetzen, gibt es Methoden.Diese Methoden können wie die Attribute statisch oder an dieInstanz gebunden sein. Bei Instanzmethoden muss vorweg einObjekt erzeugt werden, um dann auf Basis des Objekts die Funktionauszuführen. Listing 2.1 zeigt exemplarisch den Aufruf einer Instanz-methode.

DATA: ref_cl TYPE REF OF classname.CREATE OBJECT ref_cl.CALL METHOD ref_cl->methodenname

EXPORTING ..IMPORTING ..

Listing 2.1 Aufruf einer Instanzmethode

Statische MethodenBei statischen Methoden hingegen kann das Objekt direkt über denKlassennamen aufgerufen werden (siehe Listing 2.2). Hierbei wirdkein Objekt der Klasse benötigt. Dieses Objekt wird im Hintergrundautomatisch erzeugt und anschließend immer verwendet, egal inwelcher Klasse diese Methode aufgerufen wird.

CALL METHOD cl_gui_frontend_services=>executeEXPORTINGdocument = lv_url_string

EXCEPTIONSothers = 1.

Listing 2.2 Aufruf einer statischen Methode

Persistente KlassenPersistente Klassen sind eine Sonderform der normalen ABAP-Klas-sen. Diese Klassen erlauben einen persistenten Zugriff auf Objekteaus der Datenbank. Persistente Klassen kennen Sie vielleicht vomHibernate-Ansatz aus der Java-Welt. Der Hibernate-Ansatz wurde inABAP als Object Services umgesetzt und basiert auf persistentenKlassen. Die Object Services sorgen in ABAP für das Transaktions-handling, das für größere Entwicklungsprojekte sehr wichtig ist.

Umgang mit Entwurfsmustern2

50

Interfaces Durch ABAP Objects wurde noch ein neuer Begriff in die ABAP-Sprachwelt eingeführt: Interfaces zählen zu den gleichen Objektty-pen wie Klassen, repräsentieren aber nur einen Teilaspekt einerKlasse. Sie sind eine spezielle Form einer abstrakten Klasse. Interfacesrepräsentieren einen Rahmen von Funktionen, die implementiertwerden, sobald das Interface der Klasse hinzugefügt wird.

Abstrakte Klassen

Abstrakte Klassen lassen sich nicht instanziieren. In ihnen werden ledig-lich abstrakten Methoden deklariert. Die Methoden können nicht in der-selben Klasse implementiert werden, sondern erst in einer Unterklasse,die von der abstrakten Klasse erbt.

Abbildung 2.10 zeigt, wie ein Interface im Class Builder dargestelltwird. Das Interface wird immer in die Klassen implementiert, indenen Sie seine Funktionen nutzen möchten. Diese Funktionen kön-nen dann in den Objekten der Klasse ausgeführt werden. Dabei müs-sen Sie die Funktionen jedoch separat je Objekt, d.h. je Klasse aus-implementieren.

Abbildung 2.10 Interface-Klasse im Class Builder

Im Gegensatz zu den Funktionen von Interfaces besteht bei einervererbten Methode immer ein Zusammenhang zur Superklasse.Wenn die Unterklassen der Superklasse nicht die Methode imple-mentieren, wird die Implementierung der Superklasse verwendet.

Grundlagen der objektorientierten Programmierung mit ABAP 2.2

51

2.2.3 Programmelemente, Interfaces und Klassen verwenden

PolymorphismusIm SAP-System und dessen Entwicklungsumgebung gibt es sehr vieleunterschiedliche Elemente, die man erstellen und verwenden kann.Um Entwurfsmuster im SAP NetWeaver Applikation Server ABAP(AS ABAP) zu entwickeln, werden hauptsächlich Klassen und Inter-faces benötigt. Diese repräsentieren alle Elemente, die in den An-wendungen wichtig sind. Sie folgen dem Prinzip des Polymorphis-mus. Der Begriff Polymorphismus beschreibt Klassen, die Methodenund Attribute von der vererbenden Superklasse erhalten. Daher kön-nen die Methoden der Superklasse durch das Sprachelement superaufgerufen werden.

Konventionen für die Programmierung

Um Elemente sauber erstellen und verwenden zu können, sollte eineNamenskonvention definiert werden. Diese wird in Kundenprojek-ten oft bereits durch die IT-Abteilung vorgegeben. Sie unterstützt dieEntwickler, den Code schneller verstehen zu können und fördert sodie Übersichtlichkeit und Wiederverwendbarkeit der Software bzw.der verwendeten Entwurfsmuster.

Reservierte

Sprachwörter

Im Sprachumfang von ABAP gibt es Sprachelemente, die reser-vierte Wörter sind. Hierunter zählen Wörter wie SELECT, FIELD-SYMBOL und ADD. Diese Sprachelemente verweisen auf eine Funk-tion in ABAP oder ein Objekt aus dem Repository im SAP Net-Weaver AS ABAP. Die Sprachelemente werden im ABAP-Spra-chumgang (Code Style) zur besseren Lesbarkeit immer inGroßbuchstaben geschrieben.

Technische

Bezeichner

In Kleinbuchstaben werden die technischen Bezeichner für die refe-renzierten Objekte geschrieben. Diese beschreiben die Funktionali-tät einer Anwendung. Sie werden im ABAP-Code in Kombinationmit den reservierten Wörtern verwendet.

Parameterdefinitionen

Um die in den Methoden enthaltenen Parameter genauer definierenzu können, können Sie die folgende Formel anwenden:

<Ausführungsrichtung>_<Type>_<Erläuterung>

Umgang mit Entwurfsmustern2

52

Ausführungs-

richtung

Mit der Ausführungsrichtung wird die Richtung definiert, die dieDaten in dem Programm nehmen, wie z.B. in den Parametern E_AUFTRAG oder I_AUFTRAGSNR (siehe auch Tabelle 2.2).

Parametertypen Als zweiter Teil des Parameters wird definiert, um welchen Typ essich handelt. Hierbei wird unterschieden zwischen Variablen undKonstanten sowie zwischen Strukturen und Tabellen.

ABAP Dictionary

Um in ABAP verschiedene Datentypen zu verwenden, müssen diesedefiniert werden. Dies findet im ABAP Dictionary statt. Diese Defini-tionen sind allgemeingültig und basieren auf den Domänen, die

Ausführungsrichtung Bedeutung der Parameter für Methoden

I_ Importparameter, um Werte, Strukturen oder Tabellen der Methode zu übergeben. Dieser Typ kann in jeder Funktion mehrfach verwendet werden.

E_ Exportparameter, um Werte, Strukturen oder Tabellen der Methode zu erhalten. Dieser Typ kann in jeder Funktion mehrfach verwendet werden.

R_ Der Returning-Parameter ist equivalent zum Exportparameter, kann jedoch nur einmal verwen-det werden.

MC_ Der Changing-Parameter ist eine Arbeitsvariable. Dieser Parameter wird oft in Kombination mit Tabellen verwendet.

Tabelle 2.2 Ausführungsrichtung bei der Parameterdefinition

Parametertyp Bedeutung des Elements

0 einfache Variable, mit der als Element des ABAP Dictionarys oder als integrierter Typ ein Wert übergeben wird

S Struktur, mit der eine Reihe von Variablen in einer geordneten Reihenfolge übergeben wird, die im ABAP Dictionary definiert wurde

T Übergabe einer Tabelle, die auf der Basis von Strukturzeilen im ABAP Dictionary definiert wurde

Tabelle 2.3 Parametertypen für Namenskonvention

Grundlagen der objektorientierten Programmierung mit ABAP 2.2

53

bereits im ABAP Dictionary definiert worden sind. Domänen sindWertebereiche, die zentral im SAP-System definiert worden sind.Mit der Angabe eines Datentyps wird der Wertebereich bestimmt,der mit einem ENUM-Typ in Java zu vergleichen ist. Im ABAP Dictio-nary können Sie den Wertebereich oder Beschreibungen von Wer-ten definieren.

Wiederverwend-

bare Objekte

Das ABAP Dictionary ist eine zentrale Datentypen-Datenbank. Hierwerden alle Definitionen zentral gespeichert. Diese können in jedemanderen Projekt oder anderen Klassen verwendet werden. Wird einObjekt geändert, wird diese Änderung automatisch auf alle anderenElemente angewendet, ohne dass der Entwickler sich darum küm-mern muss. Dadurch werden Redundanzen im System verhindertund die Wiederverwendung von Objekten gefördert.

MehrsprachigkeitZu jedem Dictionary-Element geben Sie immer auch eine Bezeich-nung an. Diese wird bei der Darstellung des Elements z.B. in Spal-tenüberschriften automatisch verwendet. Daher gibt es auch dieMöglichkeit, diese Bezeichnungen in weitere Sprachen zu überset-zen. Um eine Multi-Language-Anwendung zu erstellen, ist die Ver-wendung von Dictionary-Elementen daher essentiell.

ÄnderbarkeitWenn Änderungen an den Elementen durchgeführt werden sollen,ist dies jederzeit möglich. Diese Änderungen haben keine Auswir-kung auf die Laufzeitanwendung, d.h. es werden keine Änderungenauf die bereits aktivierten Dictionary-Elemente angewendet. DieÄnderungen wirken sich erst aus, wenn die Elemente durch denABAP-Prozessor aktiviert werden.

Strukturen

Strukturen sind logische Kombinationen von Datenelementen, die ineiner flachen Liste zusammengesetzt werden können. Eine Strukturkann eine Tabellenzeile repräsentieren. Neben den Datenelementenwird auch ein Primärschlüssel (eindeutiger Schlüssel) definiert, derspäter den Index der Tabellen definiert. Der Index ermöglicht einenschnellen Zugriff auf die Tabelle, da ihm bekannt ist, wo ein Daten-satz zu finden ist. Dies führt zu einer erheblichen Performancesteige-rung beim Auslesen der Tabelle. Entwurfsmuster geben meistensStrukturen anstelle einfacher Variablen zurück.

Globale StrukturenEs gibt zwei Arten von Strukturen, globale und lokale Strukturen.Globale Strukturen legen Sie über Transaktion SE11 im ABAP Dictio-

Umgang mit Entwurfsmustern2

54

nary an. Hierbei geben Sie mithilfe eines vorgegebenen Assistentenalle notwendigen Elemente ein. Sie werden in SAP-Anwendungenzum großen Teil verwendet.

Lokale Strukturen Lokale Strukturen sind technische Strukturen, die direkt in ABAP-Klassen und -Methoden definiert werden können. Diese werden oftin Kombination mit Extraktoren, d.h. bestimmten Elementen ausSAP Business Warehouse (BW), verwendet. Zur Definition lokalerStrukturen gibt es in ABAP-Klassen-Definitionen den Bereich TYPES.Hier können Sie lokale Strukturen im Programm anlegen, wie es Lis-ting 2.3 exemplarisch zeigt.

TYPES:BEGIN OF ZMS_S_TEST,

Element1 TYPE char10,Element2 TYPE char10,Element3 TYPE char10,Element4 TYPE char10,Element5 TYPE char10,

END OF ZMS_S_TEST.

Listing 2.3 Typendefinition für eigene Strukturen

Tabellenstrukturen Tabellenstrukturen sind logische Tabellen, die auf einer Struktur odereinem Standarddatentyp basieren. Basiert die Tabelle auf einerStruktur, geben Sie diese in Transaktion SE11 beim Anlegen an. Hier-bei wird der Primärschlüssel der Struktur als primärer Index defi-niert. Dieser kann durch weitere Indexe als Sekundärschlüssel ange-legt werden. Wenn Sie den Primärschlüssel in ABAP ansprechenmöchten, müssen Sie beim READ <Table> den Zusatz WITH <Sekundär-schlüsselname> verwenden.

Ist keine Struktur vorhanden, können Sie definieren, wie oft welcherDatentyp in der Tabelle vorkommen soll. Diese Verwendung ist abernicht zu empfehlen. Die Tabellenstrukturen können Sie in Trans-aktion SE11 oder auch wieder über den Programmcode in ABAP-Klassen definieren. Letzteres wird wie in Listing 2.4 durchgeführt.

TYPES:zms_t_test TYPE STANDARD TABLE OF zms_s_test

WITH NON-UNIQUE DEFAULT KEY.

Listing 2.4 Typendefinition für eigene Tabellenstrukturen

Grundlagen der objektorientierten Programmierung mit ABAP 2.2

55

Tabellentypen

Es gibt auch verschiedene Typen von Tabellen, die sehr wichtig wer-den, wenn Sie mithilfe von Entwurfsmustern viele Daten verarbeitenmöchten. Hier können Sie große Performancesteigerungen durcheinfache Tricks erzielen. Dies zu beachten ist vor allem dann wesent-lich, wenn Sie größere Datenmengen in internen Tabellen verwen-den möchten.

Hash-TabelleEine Hash-Tabelle erzeugt neben der normalen Tabelle noch eineweitere interne Tabelle, die den Hash-Algorithmus beinhaltet. DerHash-Algorithmus ist ein standardisiertes Verfahren, das die Pro-gramme bei einer effizienten Verarbeitung der Tabellenzugriffeunterstützt. Dies hat den Vorteil, dass alle Lesezugriffe auf dieseTabelle identisch sind und dadurch unabhängig von der Größe derinternen Tabelle. Daher ist die Verwendung dieses Tabellentyps beigroßen internen Tabellen mit vielen Lesezugriffen über den Schlüs-sel zu empfehlen. Um ihn verwenden zu können, muss ein eindeuti-ger Schlüssel vorhanden sein. Neue Elemente können nur durchINSERT und DELETE bearbeitet werden. Listing 2.5 zeigt die Defini-tion einer Hash-Tabelle.

it_tabelle1 TYPE HASHED TABLE OF zms_s_test01WITH UNIQUE KEY /bic/0zms01 /bic/0zms01

Listing 2.5 Typendefinition für eigene Hash-Tabellen

StandardtabelleEine Standardtabelle ist die Tabelle, die standardmäßig bei der Ent-wicklung in SAP verwendet wird. Bei dieser Tabelle können Sie sehreinfach durch das Schlüsselwort APPEND neue Elemente hinzufügenund über READ TABLE INDEX 1 auslesen. Die Zugriffzeiten sind propor-tional abhängig zu der Elementanzahl. Bei geringen Datenmengen istdie Standardtabelle schneller als die Hash-Tabelle oder sortierteTabelle. Die Schlüsselwörter TYPE STANDARD OF und TYPE TABLE OFsind äquivalent. Sie werden verwendet, um Variablen zu definieren.INITIAL SIZE 0 ist immer als Standard vorgegeben. Es bedeutet, dassdie initiale Größe der Tabelle keine Elemente enthält, auch wenndies nicht angegeben wird. Listing 2.6 zeigt die Definition einer Stan-dardtabelle.

it_tabelle2 TYPE STANDARD OF zms_s_test01INITIAL SIZE 0,

it_tabelle2 TYPE TABLE OF zms_s_test01.

Listing 2.6 Typdefinition für eigene Standardtabellen

Umgang mit Entwurfsmustern2

56

Sortierte Tabelle Sortierte Tabellen können mit einem eindeutigen oder nicht eindeuti-gen Schlüssel definiert werden. Die Zugriffzeiten auf sortierte Tabel-len sind schneller als bei einer Standardtabelle, aber langsamer alsbei einer Hash-Tabelle. Des Weiteren erlaubt eine sortierte Tabelleeinen BINARY SEARCH. Dieses Schlüsselwort wird verwendet, um einezeichenbasierte Suche durchzuführen. Wenn sortierte Tabellen ein-gesetzt werden, können Sie mit den gleichen Elementen wie beieiner Standardtabelle arbeiten.

Verwendung von sortierten Tabellen

Bei einer kleinen Datenmenge ist die Standardtabelle zu empfehlen, dadie sortierte Tabelle auch weitere Indexe anlegt, wodurch der Zugriff beigeringen Datenmengen viel langsamer ist.

Datenbanktabelle Die Datenbanktabelle ist ein Tabellentyp, der einer physischenTabelle auf dem Datenbankserver entspricht. Logisch wird dieseüber eine Struktur oder in verschiedenen Datenbanksystemen simul-tan aufgebaut. In Datenbanktabellen können die Daten physischgespeichert und auch wieder ausgelesen werden. Lesen Sie in diesemZusammenhang auch die Informationen zu persistenten Klassen inAbschnitt 2.2.2, »Klassen in ABAP«.

7

Inhalt

Einleitung .................................................................................. 13

1 Einführung ............................................................... 17

1.1 Was sind Entwurfsmuster? ...................................... 171.1.1 Entwurfsmuster in der Software-

entwicklung ............................................... 191.1.2 Softwaredesign mithilfe von Entwurfs-

mustern ..................................................... 221.2 Vorteile einer entwurfsmusterbasierten

Architektur ............................................................. 291.2.1 Flexibilität bei Neuanforderungen .............. 291.2.2 Zeitersparnis bei der Umsetzung ................ 301.2.3 Möglichkeiten der Parallelentwicklung ...... 321.2.4 Wartbarkeit der Entwicklung ..................... 33

TEIL I Entwurfsmuster in ABAP implementieren

2 Umgang mit Entwurfsmustern ............................... 37

2.1 UML-Grafiken erstellen ........................................... 372.1.1 Klassendiagramm ...................................... 392.1.2 Anwendungsfalldiagramm ......................... 412.1.3 Sequenzdiagramm ..................................... 42

2.2 Grundlagen der objektorientierten Programmierung mit ABAP ..................................... 432.2.1 ABAP Objects ............................................ 432.2.2 Klassen in ABAP ........................................ 452.2.3 Programmelemente, Interfaces und

Klassen verwenden .................................... 51

3 Erzeugungsmuster ................................................... 57

3.1 Builder Pattern ....................................................... 593.1.1 Problem .................................................... 603.1.2 Ansatz und Lösung .................................... 603.1.3 Umsetzung in ABAP .................................. 62

Inhalt

8

3.1.4 Einsatzbeispiel ........................................... 683.1.5 Evaluation .................................................. 69

3.2 Factory Pattern ........................................................ 703.2.1 Problem ..................................................... 713.2.2 Ansatz und Lösung ..................................... 723.2.3 Einsatzbeispiel ........................................... 753.2.4 Umsetzung in ABAP ................................... 763.2.5 Evaluation .................................................. 80

3.3 Singleton Pattern ..................................................... 823.3.1 Problem ..................................................... 823.3.2 Ansatz und Lösung ..................................... 833.3.3 Einsatzbeispiele .......................................... 843.3.4 Umsetzung in ABAP ................................... 863.3.5 Evaluation .................................................. 88

3.4 Prototype Pattern .................................................... 903.4.1 Problem ..................................................... 903.4.2 Ansatz und Lösung ..................................... 903.4.3 Einsatzbeispiele .......................................... 923.4.4 Umsetzung in ABAP ................................... 923.4.5 Evaluation .................................................. 95

4 Strukturmuster ........................................................ 97

4.1 Model View Controller ............................................ 984.1.1 Problem ..................................................... 984.1.2 Ansatz und Lösung ..................................... 994.1.3 Einsatzbeispiele .......................................... 1024.1.4 Umsetzung in ABAP ................................... 1034.1.5 Evaluation .................................................. 106

4.2 Adapter Pattern ....................................................... 1074.2.1 Problem ..................................................... 1074.2.2 Ansatz und Lösung ..................................... 1084.2.3 Einsatzbeispiele .......................................... 1114.2.4 Umsetzung in ABAP ................................... 1124.2.5 Evaluation .................................................. 114

4.3 Composite Pattern ................................................... 1154.3.1 Problem ..................................................... 1154.3.2 Ansatz und Lösung ..................................... 1154.3.3 Einsatzbeispiele .......................................... 1174.3.4 Umsetzung in ABAP ................................... 1194.3.5 Evaluation .................................................. 125

Inhalt

9

4.4 Façade Pattern ........................................................ 1264.4.1 Problem .................................................... 1264.4.2 Ansatz und Lösung .................................... 1284.4.3 Einsatzbeispiele ......................................... 1304.4.4 Umsetzung in ABAP .................................. 1344.4.5 Evaluation ................................................. 138

5 Verhaltensmuster .................................................... 139

5.1 Command Pattern ................................................... 1415.1.1 Problem .................................................... 1415.1.2 Ansatz und Lösung .................................... 1425.1.3 Einsatzbeispiele ......................................... 1445.1.4 Umsetzung in ABAP .................................. 1455.1.5 Evaluation ................................................. 149

5.2 Interpreter Pattern .................................................. 1505.2.1 Problem .................................................... 1505.2.2 Ansatz und Lösung .................................... 1515.2.3 Einsatzbeispiele ......................................... 1545.2.4 Umsetzung in ABAP .................................. 1565.2.5 Evaluation ................................................. 162

5.3 Iterator Pattern ....................................................... 1635.3.1 Problem .................................................... 1635.3.2 Ansatz und Lösung .................................... 1635.3.3 Einsatzbeispiele ......................................... 1665.3.4 Umsetzung in ABAP .................................. 1675.3.5 Evaluation ................................................. 173

5.4 Mediator Pattern .................................................... 1745.4.1 Problem .................................................... 1745.4.2 Ansatz und Lösung .................................... 1745.4.3 Einsatzbeispiele ......................................... 1765.4.4 Umsetzung in ABAP .................................. 1775.4.5 Evaluation ................................................. 182

5.5 Observer Pattern .................................................... 1835.5.1 Problem .................................................... 1835.5.2 Ansatz und Lösung .................................... 1845.5.3 Einsatzbeispiele ......................................... 1865.5.4 Umsetzung in ABAP .................................. 1865.5.5 Evaluation ................................................. 190

5.6 State Pattern ........................................................... 1915.6.1 Problem .................................................... 191

Inhalt

10

5.6.2 Ansatz und Lösung ..................................... 1925.6.3 Einsatzbeispiele .......................................... 1945.6.4 Umsetzung in ABAP ................................... 1965.6.5 Evaluation .................................................. 201

5.7 Strategy Pattern ....................................................... 2025.7.1 Problem ..................................................... 2025.7.2 Ansatz und Lösung ..................................... 2035.7.3 Einsatzbeispiele .......................................... 2045.7.4 Umsetzung in ABAP ................................... 2055.7.5 Evaluation .................................................. 208

5.8 Template Pattern ..................................................... 2105.8.1 Problem ..................................................... 2105.8.2 Ansatz und Lösung ..................................... 2105.8.3 Einsatzbeispiele .......................................... 2125.8.4 Umsetzung in ABAP ................................... 2135.8.5 Evaluation .................................................. 218

5.9 Visitor Pattern ......................................................... 2195.9.1 Problem ..................................................... 2195.9.2 Ansatz und Lösung ..................................... 2195.9.3 Einsatzbeispiele .......................................... 2225.9.4 Umsetzung in ABAP ................................... 2235.9.5 Evaluation .................................................. 230

TEIL II Anwendungsentwicklung mithilfe von Entwurfsmustern

6 Entwurfsmuster im Entwicklungsprojekt einsetzen ................................................................. 235

6.1 Vor Projektstart ....................................................... 2356.2 Aufbau einer ganzheitlichen Architektur .................. 2416.3 Umsetzungsmethoden ............................................. 244

6.3.1 Wasserfall-Methode ................................... 2446.3.2 Scrum-Methode ......................................... 2486.3.3 Kanban-Methode ....................................... 259

6.4 Review-Verfahren .................................................... 263

Inhalt

11

7 Flexible Entwicklung einer Beispielanwendung ..... 267

7.1 Planung und Konzipierung der Beispiel-anwendung ............................................................. 2687.1.1 Berechtigungen ......................................... 2687.1.2 Anwendungsarchitektur ............................. 270

7.2 Implementierung der Beispielanwendung ............... 2737.2.1 Allgemeine Elemente für die

Beispielanwendung ................................... 2747.2.2 Schichtenmodell (Model View Controller) . 2787.2.3 Auftragserzeugung (Factory Pattern) .......... 2927.2.4 Layoutsteuerung (Façade und Singleton

Patterns) .................................................... 3047.2.5 Berechtigungssteuerung (Command Pattern) 3127.2.6 Sperrverfahren (Model View Controller) .... 3237.2.7 Plausibilitätsprüfungen

(Façade und Composite Patterns) .............. 3357.2.8 Anwendungslog (Composite Pattern) ......... 345

Die Autoren ............................................................................. 349

Index ........................................................................................ 351

351

Index

A

ABAP Dictionary 46, 52, 54ABAP Object Services 289ABAP Objects 43, 44ABAP-Prozessor 53Abnahmetest 246Abstract Factory Pattern 58abstract_factory 73Adapter 109, 290Adapter Pattern 28, 32, 97, 107,

291, 306Agent 300Aggregat 164, 166Aggregat, konkretes 164Aggregation 25Agilität 248Akteur 41Aktion rückgängig machen 144Alexander, Christopher 17Algorithmus 202, 210Alias 169ALV 105, 283Analysephase 238Anforderung 245Anforderungsspezifikation �

LastenheftAnti Pattern 21, 85Anwendungsentwurf 238Anwendungsfalldiagramm 41Anwendungslog 345Anwendungslogik 284Anwendungsschicht 284APPEND 55Application Layer 242Arbeitsfluss 263Arbeitsvorrat 283Architektur 17, 241Architekturentwurf 238Architekturmodell 238Artefakt 252Assoziation 25Attribut 48

Instanzattribut 48internes 86

Attribut (Forts.)Konstanzattribut 48statisches 48UML 39

Aufrufer 142Auftragsnummer 268, 292Ausführungsrichtung 52

B

Backlog 250, 252Beck, Kent 17, 19Befehl 143, 284, 298, 313

gruppieren 149kapseln 141Klasse 143Makro-Befehl 149

Befehlsmuster � Command PatternBeispielanwendung 268Benutzeroberfläche 281, 304Benutzeroberflächenelement

� UI-ElementBenutzertyp 270Beobachter-Muster 140, 183Berechtigungsobjekt 321Berechtigungsprüfung 288Berechtigungsprüfung, zentrale 302Berechtigungssteuerung 287, 313Best Practices 20Besucher 219Besucher-Muster 140, 219BINARY SEARCH 56BPMN 38Bug 253Bugfixing 253Builder Pattern 58, 59Burndown Chart 254Business Key 300Business Layer 242Business Process Model and

Notation 38BW-Hierarchie 117

352

Index

C

Callback 141Chain Manager 335Chain Pattern 335Change Management, evolutio-

näres 259Changing-Parameter 52Class Builder 46Client 61, 66, 142Command Pattern 140, 141, 230,

269, 313Command-Klasse 141, 299Commitment 252Component-Controller 279Composite Pattern 97, 115, 149, 162,

285, 318, 346concrete_factory 73Connector 291Context (Web Dynpro) 274, 278Context-Mapping 279Controller 100, 101, 279, 281, 284,

286, 313CREATE OBJECT 105Cunningham, Ward 17, 19Cursor � IteratorCustomizing-Tabelle 291

D

Daily Scrum 256Data Store Object 85Datenbankschlüssel 300Datenbanktabelle 56, 305Datenbankzugriff 290Datensynchronität 90Datentyp

definieren 52UML 40

Dead-Lock 202Design 246Design Pattern � EntwurfsmusterDesignphase 241Dialogbenutzer 270Direktor 61, 66Domäne 52Dreischichtenmodell 102

E

Earned-Value-Analyse 253Einschubmethode 211Einzelstück-Entwurfsmuster

� Singleton PatternEmpfänger 142Endlosschleife 191Entwicklungsansatz 18Entwicklungsprojekt 235Entwicklungsumfang 235Entwurf 238Entwurfsmuster 17

Gruppe 24Historie 18Katalog 27Kategorie 24klassenbasierte 57objektbasierte 57Typ 24Übersicht 26Voraussetzungen 22

ErbauerImplementierung 64Klasse 61konkreter 61

Erbauermuster 59Ereignisbehandler 298Erweiterungsanforderung 243Erzeugungsmuster 24, 25, 57Erzeugungsprozess 59Evolutionäres Change Manage-

ment 259Exportparameter 52Extraktor 54

F

Fabrik-Entwurfsmuster � Factory Pattern

Façade Pattern 126, 313abstrakte Klasse 128eine Schnittstelle 128

Fachbereich 236Fachkonzept 29Fachkonzept � LastenheftFactory Pattern 57, 70, 80, 82,

218, 270Factory-Klasse 71, 289

353

Index

Factory-Klasse, abstrakte 71Factory-Methode 71Feature 250, 252Fehler 253Fehlerbehebung 253Feinentwurf 239Flaschenhalsprinzip 90Flexibilität 29Fliegengewicht-Muster 162Flow 263Flow-Prinzip 260Flyweight Pattern 162Framework 18Funktionsbaustein 277Funktionstest 246

G

Gamma, Erich 18Gang of Four 18Geschäftslogikschicht 289Getter-Methode 28GoF 18GoF-Muster 18, 27Grobentwurf 238, 241

H

Hash-Tabelle 55Helm, Richard 18Hierarchy plus Input Process

Output 44HIPO 44Hüllenklasse � Adapter Pattern

I

iDoc 109Impediment Backlog 251, 255, 257Implementierung 246Importparameter 47, 52, 57Inbound-Plug 283Index 53, 300Indirektionsstufe 138Infrastrukturschicht 242, 290INITIAL SIZE 55Injection 69Instanzattribut 48

Instanziierung 28Instanzmethode 49Integrationstest 246Interface 50, 109, 168, 287, 289Interpreter 150Interpreter Pattern 139, 150Iteration 166Iterator 163, 164

externer 166interner 166Klasse 168konkreter 165polymorpher 173

Iterator Pattern 140, 162, 163, 230IT-Spezifikation 239, 246

J

Java 43Johnson, Ralph 18

K

Kanban-Methode 259Kanban-Tafel 261Kapsel-Entwurfsmuster � Façade

PatternKlasse

abstrakte 40, 50Attribut 48Diagrammdarstellung 39globale 46Instanziierung 47lokale 45persistente 49, 325statische 48typkompatible 45UML 39

Klassenakteur 300Klassendiagramm 39Klassenkonstruktor 48Klassenmuster 25, 57Klonen 91Kommando 288Kommando � BefehlKompilieren 32Kompositionsansatz 25, 139Kompositionsmuster � Composite

Pattern

354

Index

Konkreter Erbauer implemen-tieren 65

Konstante 31, 52Konstanzattribut 48Konstruktionsprozess 59Konstruktor 47Kontextobjekt 28Kontrollfluss 25, 139

L

Lastenheft 238, 239, 241, 245Laufzeitänderung 25Layout

flexible Steuerung 269Manager 304Steuerung 304

Lazy Loading 89Logical Unit of Work 325Logistik 268Lösungsentwurf 238LUW 325

M

Makro-Befehl 149Management Board 255Mapping 300Mediator Pattern 140, 174, 190Mehrfachinstanz 86Mehrsprachigkeit 276Meldung 277Memento Pattern 150Message Manager 277Methode 49

create_command() 289Einschubmethode 211Instanzmethode 49statische 49

Model 99, 278Model View Controller 98, 270,

278, 324Mustersprache 17MVC 184MVC � Model View Controller

N

Nachrichten-ID 277Nachrichtenklasse 275, 277Nachrichtentyp 277Namenskonvention 51Navigation 281Null-Referenz 86Nummernkreisintervall 292Nummernkreisobjekt 292

O

Object Management Group 37Object Services 49, 289, 299Objects for State 140, 191Objekt

aktivieren 32erzeugen 25instanziieren 28persistentes 289primitives 116zusammengesetztes 116

Objektklasse 140Objektmuster 25, 58Objektorientierung 19, 43Observer Pattern 140, 183Online Text Repository 277Open SQL 290Operation

ausführen 141primitive 212rückgängig machen 144

OTR 277Out of Scope 240

P

PAL-Editor 282Parallelentwicklung 32Parallelisierung 18Parameter

Ausführungsrichtung 52definieren 51Typ 52

Parser 154Parser-Generator 154Persistenz-Mapping 300PFCG-Rolle 270

355

Index

Pflichtenheft 239, 246Plausibilitätsprüfung 30, 243, 335Polymorphismus 51Präsentationsschicht 99, 281Primärschlüssel 53, 54, 300private 47Product Backlog 250, 252Product Backlogs 250Product Owner 249Produkt 61Produkt implementieren 63Programmieransatz

datengetrieben 44dynamischer 49funktionsgetrieben 44objektorientierter 19, 43prozeduraler 43, 44

Projektmanagement 235Projektphase 238Projektplan 235protected 47Prototyp 90Prototype Pattern 58, 90Prozess 268Prüfobjekt 336Prüfung 336public 47Publish-Subscribe-Schnittstelle 183Pull-Prinzip 260Pull-Verfahren 185Push-Verfahren 185

R

Rapid Deployment 95READ TABLE INDEX 55Redo 144Redundanz 18, 31, 243Remote Function Call 45Remote-Funktionsbaustein 45Report 62Repository Browser 274Retest 262Retrospektive 257Returning-Parameter 52Review 257RFC 45RFC-Aufruf 290RFC-Destination 291

S

SAP List Viewer 283Schablonenklasse 214Schablonenmethode 140, 210, 211Schichtenarchitektur 242, 279Schichtenmodell 102Schnittstelle 271Scrum Master 250Scrum Team 251Scrum-Methode 248

Artefakte 252Rituale 255Rollen 249

Security Manager 320Select-Anweisung 85Select-Option 47Sequenzdiagramm 42, 239Setter-Methode 28Sichtbarkeit 40, 47Singleton Pattern 58, 82, 83, 89Singleton-Klasse 86Software

Qualität 24, 29Verhalten 139

SoftwaredesignVorgehensmodell 22Vorgehensweise 237

SoftwareentwicklungMethodik 17Vorgehensmodell 22

Sperrobjekt 325Sperrtabelle 326Sperrverfahren 323

Implementierung 331optimistisches 324pessimistisches 324

Spezifikation, technische 236Sprachunterstützung 276Sprint 256

Backlog 253Planung 255Retrospektive 257Review 257Ziel 255

Standardtabelle 55Stapelverarbeitung 116State Pattern 140, 191Strategiemuster 140, 202Strategy Pattern 140, 202

356

Index

Struktur 52, 53, 274globale 53lokale 54

Strukturmuster 24, 25, 97klassenbasiertes 98objektbasiertes 97

Superklasse 73Syntaxbaum 151

T

Tabelle 52Hash 55kundeneigene 299sortierte 56Standardtabelle 55T100 277Typen 55

Tabellenstruktur 54Template Pattern 140, 210Test 246Test, Nachtest 262Testphase 236Toolkit 71Top-Level-Transaktion 331Transaktion

SE11 53SE24 46SE38 62SE80 274SGL1 348SPRO 292SU21 321SU53 321

Traversierung, polymorphe 174Traversierungsschnittstelle 173TYPE STANDARD OF 55TYPE TABLE OF 55

U

Übergabeparameter 28Übersetzung 276UI-Element 144UML 37, 39UML-Diagramm 39Umsetzungsmethode, agile 248Undo 144Unified Message Language 37, 39

Unique-Index 300URL 281Use-Case-Diagramm 41User Interface 242User Story 250

V

Variable 52Variable, globale 83, 89Variante 61, 188VBA 43Verarbeitungsklasse 63Vererbung 25Verhaltensmuster 24, 25, 139

klassenbasiertes 139objektbasiertes 140

Vermittler-Entwurfsmuster � Mediator Pattern

Viererbande 17, 18View 99, 101, 278View-Controller 279, 305, 306Visitor 219Visitor Pattern 140, 219Vlissides, John 18Vorlage 210

W

Wartbarkeit 33Warteschlange 144Wasserfallmodell 244Wasserfallmodell nach Royce 246Web-Dynpro-Anwendung 279, 281Web-Dynpro-Component 279, 281

eingebettete 281zentrale 281

Web-Dynpro-Context 274, 278Wiederherstellung 144Wiederverwendbarkeit 44Wildwuchs 98Window 278, 283Window-Controller 279Work in Process 260, 263Workflow 260Wrapper 110Wrapper � Adapter Pattern

357

Index

Z

Zeiger � IteratorZentralisierung 29Zustand

Abhängigkeit 191Änderung 191

Zustandsautomat 192hierarchischer 192

Zustandshierarchie 193Zustandsklasse 196Zustandsmuster 140, 191Zustandsobjekt 28

Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dürfen sie gerne emp-fehlen und weitergeben, allerdings nur vollständig mit allen Seiten. Bitte beachten Sie, dass der Funktionsumfang dieser Leseprobe sowie ihre Darstellung von der E-Book-Fassung des vorgestellten Buches abweichen können. Diese Leseprobe ist in all ihren Teilen urheberrechtlich geschützt. Alle Nutzungs- und Verwertungs-rechte liegen beim Autor und beim Verlag.

Teilen Sie Ihre Leseerfahrung mit uns!

Nurgül Atilgan ist seit 2007 Mitarbeiterin der T-Systems GEI GmbH und arbeitet als SAP BI/BO Consultant im Automotive- Sektor. Sie verfügt über langjährige Erfahrung in der konzep-tionellen Ausarbeitung von Anwendungen und Architekturen sowie in der Implementierung von SAP-BI-Lösungen.

Nurgül Atilgan, Markus Straub

Entwurfsmuster in ABAP357 Seiten, gebunden, Januar 2015 69,90 Euro, ISBN 978-3-8362-2833-6

www.sap-press.de/3579

Markus Straub ist Mitarbeiter der T-Systems International GmbH. Er arbeitet als BI-Architekt und -Berater in der Auto-mobilindustrie. Sein Fokus liegt auf der Konzeptionierung und Implementierung von SAP-BW-/BusinessObjects-Anwendun-gen. Als Mit-Geschäftsführer von IT-Service Dienstleistungen Straub kennt er die Kunden- und IT-Prozesse sehr genau.

Wissen aus erster Hand.