MODELLBASIERTE ENTWICKLUNG VON COBOL- ANWENDUNGEN

Transkript

1 mehr zum thema: www4.in.tum.de/~winterse von andreas rausch, oliver engelhardt, klaus bergner und sebastian winter MODELLBASIERTE ENTWICKLUNG VON COBOL- ANWENDUNGEN Ein durchgängiges, modellgetriebenes Vorgehen bringt große Vorteile bei der Entwicklung betrieblicher Informationssysteme. Der Einsatz von UML-Modellen für die fachliche und technische Modellierung empfiehlt sich auch zur Entwicklung und Dokumentation von COBOL-Anwendungen. Voraussetzung dafür ist allerdings, dass die Beziehungen zwischen den Modellen untereinander und mit dem Quellcode sowie die zugehörige Modellierungsmethodik klar definiert werden. In dem Artikel wird anhand eines Fallbeispiels eine Methodik vorgestellt, die eine durchgängige Entwicklung von COBOL- Anwendungen ermöglicht. die autoren Prof. Dr. Andreas Rausch ( leitet die Arbeitsgruppe Softwarearchitektur an der Technischen Universität in Kaiserslautern. Die Firma IZB SOFT ist der IT-Dienstleister der bayerischen Sparkassen. Sie betreibt eine Vielzahl von Anwendungen auf Basis einer in mehr als dreißig Jahren gewachsenen, heterogenen Softwareinfrastruktur. Wie in den meisten Unternehmen geht natürlich auch bei der IZB SOFT der Trend stark in Richtung objektorientierter Systeme und Web-Techniken. Trotzdem werden COBOL-Systeme auch langfristig weiterhin eine wichtige Rolle spielen, unter anderem aufgrund des hohen Aufwands und der Risiken von Neuentwicklungen. Die IZB SOFT verbessert ihre Entwicklungsmethodik stetig und passt sie dem Stand der Technik an, um die Kosten für Weiterentwicklung und Wartung zu senken und eine höhere Softwarequalität zu erreichen. Ein weiteres Ziel ist es, die bestehende COBOL- Funktionalität in Form von allgemein verwendbaren Komponenten bereitzustellen und damit für neue Systeme nutzbar zu machen. Die nachstehend beschriebene modellgetriebene Entwicklungsmethodik basiert auf bestehenden Standards der IZB SOFT (vgl. [IZB03]). Zur Integration des komponentenbasierten Entwicklungsansatzes wurden entsprechende Erweiterungen dieser Entwicklungsmethodik konzipiert, pilotiert und in den hausinternen Standard integriert. Dadurch konnten die oben angesprochenen Ziele besser erreicht werden. Im Folgenden wird zunächst ein kurzer Überblick über die Methodik gegeben. Anschließend werden die einzelnen Modelle und ihre Beziehungen untereinander anhand eines kleinen Fallbeispiels vorgestellt. trale Rolle für die Informationserfassung der jeweiligen Arbeitsabläufe beschreibt Nobe wie folgt: Wenn wir einen Entwicklungsprozess auf Modellen aufbauen, werden diese zu den zentralen koordinierenden Elementen des Prozesses (vgl. [Nob02]). Insgesamt ist es das Ziel der modellbasierten Softwareentwicklung, eine vollständige, einheitliche und verständliche Informationsbasis zu erhalten und damit die Menge und Komplexität der anfallenden Informationen im Entwicklungsprozess systematisch in den Griff zu bekommen. Besonders im Umfeld von betrieblichen Informationssystemen wird dieses Ziel auch von Ansätzen wie der Model Driven Architecture (MDA) (vgl. [OMG]) verfolgt. Die MDA zielt aber auf den Entwurf von Softwaresystemen ab, die eine objektorientierte Middleware, wie beispielsweise COR- BA oder J2EE, einsetzen. Dabei wird hauptsächlich der Übergang vom fachlichen Modell in die technische Implementierung betrachtet. Die in diesem Artikel vorgestellte Vorgehensweise bietet dagegen folgende zusätzliche Vorteile: Sie ist von der Analyse bis zur Implementierung durchgängig und sie ermöglicht die Modellierung und Generierung von COBOL-Quellcode in Form von Komponenten mit klar definierten Schnittstellen. Um Durchgängigkeit zu erreichen, werden in den einzelnen Phasen des Entwicklungsprozesses unterschiedliche Modelle erarbeitet. Ihr Aufbau und ihre Beziehungen untereinander sind durch ein Modellsystem klar definiert, damit keine Brüche im Entwicklungsprozess entstehen. Das fachliche Oliver Engelhardt ( ist Anwendungsdesigner bei der Firma IZB SOFT. Er ist dort unter anderem für die Modellierungsmethodik verantwortlich. Dr. Klaus Bergner ( ist Gründer und Geschäftsführer der 4Soft GmbH mit den Schwerpunkten modellbasierte, architekturzentrierte Entwicklung verteilter IT-Systeme. Sebastian Winter ( ist wissenschaftlicher Mitarbeiter am Institut für Informatik der TU München. Sein Schwerpunkt liegt im Bereich der modellbasierten Softwareentwicklung Modellbasierte Softwareentwicklung In einer modellbasierten Methodik steuern Modelle die Softwareentwicklung. Ihre zenwww.objektspektrum.de

2 Basis für die Definition von Transformationsregeln und Konsistenzbedingungen. Die klare, unmissverständliche Beschreibung dieser Regeln erleichtert es Entwicklern von einem Modell zu einem anderen zu gelangen und zu überprüfen, ob die Modelle in sich konsistent und fehlerfrei sind. Abb. 1: Maskenskizze des Fallbeispiels Modell der Anwendungsfunktionalität macht beispielsweise Vorgaben für das entsprechende technische Entwurfsmodell. Damit wird klar, wie die fachlichen Anforderungen aus der Analysephase in der Entwurfsphase technisch umgesetzt werden. Das erarbeitete Modellsystem für die modellbasierte Entwicklung von COBOL- Anwendungen besteht aus den folgenden vier Modellen: Das Anforderungsmodell beschreibt die Anforderungen an das System. Die Anwendungsfälle betrachten die Funktionalität des Systems aus der Sicht eines Anwenders und definieren somit, was das System zu leisten hat. Das fachliche Modell stellt in abstrakter Form dar, wie das System die Anforderungen umsetzt, lässt dabei allerdings technische Aspekte bewusst noch außer Betracht. Die Struktur des fachlichen Abb. 2: Anwendungsfall-Systeme Modells lehnt sich an die des Anwendungsbereiches an und wird somit ausschließlich unter fachlichen Gesichtspunkten entworfen. Das Designmodell stellt einen Bauplan für eine konkrete Implementierung dar. Die Struktur des Designmodells wird demzufolge von technischen Aspekten bestimmt und berücksichtigt die speziellen Gegebenheiten der COBOL-Umgebung auf dem Host. Das Implementierungsmodell beschreibt, wie die Konzepte des Designmodells in Quelltext und Dateien (COBOL-Moduldateien und Copy- Strecken) umgesetzt werden. Darüber hinaus werden Abhängigkeiten zwischen den Dateien spezifiziert. Die Struktur der einzelnen Modelle wird in einem gemeinsamen, übergreifenden Metamodell definiert. Es dient insbesondere als Fallbeispiel Die erarbeitete Methodik für eine modellbasierte Entwicklung von COBOL-Anwendungen wird im Folgenden anhand eines stark vereinfachten Beispielausschnittes aus dem Projekt Kundenmappe der IZB SOFT vorgestellt. Hauptaufgabe der Kundenmappe ist es den Berater bei Kundengesprächen mit einem oder mehreren zusammengehörigen Kunden zu unterstützen, indem sie alle Informationen an einer Stelle sammelt und damit eine zentrale Sicht auf die Kundendaten bereitstellt. Abbildung 1 zeigt eine mögliche Gestaltung der Benutzungsoberfläche der Anwendung. Der Berater sieht beim Einstieg die Maske Kunde finden. Im Eingabefeld gibt er die Nummer eines Kunden ein. Daraufhin wird ihm mit der Maske Kundendaten eine Übersicht der Kundendaten präsentiert. Von dort aus wechselt der Berater zu der Maske Auswahl. Der in der Übersicht angezeigte Kunde wurde in der Abbildung bereits in die Auswahl aufgenommen. Jetzt hat der Berater folgende Möglichkeiten: Er entfernt einen Kunden aus der Auswahl; er fügt einen weiteren Kunden hinzu (über die Maske Kunde finden); er selektiert und deselektiert die Kunden der Auswahl. Hat der Berater die gewünschte Auswahl erstellt, wechselt er mit durch Anklicken von Anzeigen zur Maske Kundenmappe, die die Summe der Vermögen aller selektierten Kunden der Auswahl anzeigt. In der Folge beschränken wir uns aus Platzgründen hauptsächlich auf die Darstellung der Modelle für den statischen Anteil des Systems. Eine vollständige Darstellung inklusive der zugehörigen dynamischen Modelle in Form von Sequenzdiagrammen etc. findet sich in [IZB03]. Anforderungsmodell Im Anforderungsmodell werden die Anforderungen an das System modelliert. Das

3 Abb. 3: Fachliches Modell System wird dabei aus der Sicht eines Anwenders von außen betrachtet. Ziel ist es die Funktionalität des Systems vollständig in Form von Anwendungsfällen zu dokumentieren. Das Anforderungsmodell enthält Anwendungsfall-Systeme, die durch den Stereotyp «anwendungsfallsystem» gekennzeichnet sind und die eine Menge zusammengehöriger Anwendungsfälle enthalten. Letztere stehen mit definierten Akteuren in Beziehung. Die Anwendungsfall-Systeme geben bereits frühzeitig im Entwicklungsprozess eine Strukturierung für die Komponenten und ihre Abhängigkeiten innerhalb des Gesamtsystems vor. Damit eignen sie sich insbesondere, um mögliche wieder verwendbare Basisfunktionalität frühzeitig zu entdecken und die organisatorische Aufteilung in Entwicklungsteams festzulegen. Wie Abbildung 2 zeigt, ist der Ausschnitt des Projekts Kundenmappe in zwei Anwendungsfall-Systeme zerlegt: das System Kundenmappe und das System Partner. Kundenmappe benötigt dabei Dienste des Systems Partner und ist folglich von diesem abhängig. Der Anwendungsfall Beteiligte Partei finden sucht eine beteiligte Partei anhand eines so genannten Adresssatzes 1 ) und liefert das Suchergebnis zurück. Falls das System noch keine beteiligte Partei zu einem Adresssatz angelegt hat (beispielsweise bei frisch erzeugten Neubeständen von Adresssätzen), wird automatisch eine neue beteiligte Partei erzeugt. Der Anwendungsfall Kundenmappe erstellen erstellt dann die zugehörige Kundenmappe zu der beteiligten Partei. Das Anforderungsmodell wird durch ein Domänenklassen-Diagramm präzisiert, da in Informationssystemen die Daten eine zentrale Rolle spielen. Die Domänenklassen geben ein grobes Verständnis der Daten und ihrer Beziehungen vor, enthalten aber insbesondere noch keine Details zu Datentypen. In unserem Fallbeispiel betrachten wir nur beteiligte Parteien in Form von natürlichen Personen. Die Auswahl besteht aus einer Anzahl von beteiligten Parteien. Sie hat Kenntnis darüber, ob eine beteiligte Partei der Auswahl selektiert ist oder nicht. Bei der Berechnung der Summe der Vermögenswerte werden nur die beteiligten Parteien berücksichtigt, die auch selektiert sind. Die Kundenmappe stellt eine zentrale Sicht auf die Daten einer Menge von beteiligten Parteien dar. In diesem Fallbeispiel sind die Kundendaten auf das Vermögen begrenzt. Die Kundenmappe berechnet die Summe der Vermögen für die Menge der ausgewählten beteiligten Parteien. Normalerweise werden die verschiedenen Vermögenswerte aus unterschiedlichen Datenspeichern zusammengetragen. Im Fallbeispiel erhält jede beteiligte Partei einen 1 ) Adresssätze sind ein Konzept aus dem Altsystem. Die Informationen zu einem Kunden können über mehrere Adresssätze verteilt sein, die jeweils durch eine Kundennummer identifiziert sind. Im Neusystem werden alle vorhandenen Adresssätze eines Kunden zu einer eindeutig bestimmten beteiligten Partei zusammengefasst. Gesamtwert, der ihren Vermögensstand repräsentiert. Um Anwendungsfälle genauer zu beschreiben, kommen bei der IZB SOFT zusätzlich textuelle Anwendungsfall- Beschreibungen zum Einsatz, die über eine Word-Dokumentvorlage definiert sind. Fachliches Modell Die Anwendungsfälle spezifizieren die Anforderungen an die Anwendung aus der Sicht des Anwenders, der das System von außen sieht. Im fachlichen Modell wird die Perspektive gewechselt und die Fachlichkeit der Anwendung inklusive der fachlichen Mechanismen und Algorithmen wird von innen betrachtet. Das fachliche Modell beschreibt damit sowohl die statische Struktur als auch die dynamischen Abläufe aus fachlicher Sicht. Technische Gesichtspunkte bleiben weiter außen vor. Im fachlichen Modell wird die Zerlegung der Anwendung in die zwei Teilsysteme Kundenmappe und Partner aus dem Anwendungsfall-Modell übernommen. Dies bedeutet insbesondere, dass die Ausarbeitung der fachlichen Modelle für die Teilsysteme von unterschiedlichen Teams betrieben werden kann, die klare Verantwortungsbereiche haben. Abbildung 3 zeigt die vollständige Struktur der Anwendung. Jedes (Teil-)System wird jeweils durch ein fachliches Paket mit dem Stereotyp «fachlichessystem» dargestellt. Wie am Beispiel des fachlichen Systems Partner gezeigt, können die Systeme weiter in fachliche Pakete aufgeteilt werden, wenn das zur weiteren Strukturierung angebracht ist. Aus den Entitäten des Domänenklassen- Diagramms werden im fachlichen Modell wiederum Entitäten. Im Vergleich zu den Entitäten im Domänenklassen-Diagramm haben sie zusätzlich explizit modellierte fachliche Datentypen und Operationen, die sich aus den Beschreibungen der Anwendungsfälle ergeben. Um einen Anwendungsfall zu realisieren, wird in der Regel eine Steuerungsklasse (Stereotyp «control») benötigt, die den Dienst anbietet und den Ablauf steuert. Die Steuerungsklasse BeteiligteParteiVerwalter im Paket BeteiligtePartei realisiert beispielsweise den Anwendungsfall Beteiligte Partei finden. Die Beziehung zum realisierten Anwendungsfall wird durch eine (in den Abbildungen nicht gezeigte) modellübergreifende Abhängigkeit mit dem Stereotyp 6/2004

4 der Komponenten und ihrer Schnittstellen ist dabei speziell auf eine COBOL- Umgebung abgestimmt. Somit entsteht ein Bauplan für die Implementierung, nach dem die Umsetzung des Entwurfs in COBOL- Quelltext erfolgen kann. Zunächst erfolgt die Modellierung der übergreifenden statischen Komponentensicht, die die Grobarchitektur der Anwendung vorgibt. Das zugehörige Komponentendiagramm zeigt die Anordnung der Komponenten innerhalb der Schichtenarchitektur und die Schnittstellen der Komponenten sowie die Abhängigkeiten zwischen den einzelnen Bestandteilen. Grundsätzlich wird aus jedem elementaren fachlichen Paket für jede Schicht eine Designkomponente erstellt. Der Entwickler kann gegebenenfalls aber Komponenten weglassen, wenn sie nicht benötigt werden. Nach dem Grobentwurf der technischen Komponenten erfolgt der Feinentwurf der einzelnen Designkomponenten. In der Folge zeigen wir beispielhaft, wie sich Schnittstellen von Designkomponenten aus den öffentlichen Operationen von Steuerungsklassen ableiten lassen. Abbildung 4 zeigt eine Detailsicht der Operationen der Schnittstelle BeteiligteParteiVerwalterSteuerung im Designmodell und die Beziehung zu der entsprechenden fachlichen Klasse. Die Operation finde dieser Schnittstelle hat drei Parameter: den Eingabeparameter in adresssatz Record, den Ausgabeparameter out beteiligteparteirecord und den Rückgabetyp RückgabeDaten. Abb. 4: Zusammenhang zwischen Schnittstellen und Steuerungsklassen «realisiert» modelliert. Interne, nicht öffentliche Dienste werden durch private Operationen spezifiziert. Während der Laufzeit steht eine Instanz von BeteiligteParteiVerwalter in Beziehung zu einer Instanz der Klasse Adresssatz (als Parameter) und zu einer Instanz der Klasse BeteiligtePartei. Diese Beziehungen werden im fachlichen Modell durch Assoziationen modelliert. Der BeteiligteParteiVerwalter bietet als öffentlichen Dienst an zu einem Adresssatz eine beteiligte Partei zu finden. Dazu muss er intern prüfen können, ob eine beteiligte Partei für den Adresssatz existiert. Für den Fall, dass keine vorhanden ist, muss er in der Lage sein, eine neue beteiligte Partei zu erstellen. Designmodell Das Designmodell beschreibt den technischen Entwurf der Anwendung. Dazu wird die Funktionalität aus dem fachlichen Modell auf Komponenten der vorgegebenen Mehr-Schichten-Architektur der IZB SOFT verteilt. Die Modellierung Abb. 5: Zusammenhang zwischen Datenstrukturen und fachlichen Entitäten Im Unterschied zu der Steuerungsklasse aus dem fachlichen Modell ist finde der technischen Umgebung angepasst. Die Typen der Parameter sind deshalb COBOL-spezifisch und die Richtung wird spezifiziert. Der Rückgabetyp spezifiziert dabei jeweils eine Datenstruktur, die den Status der Operation und mögliche Fehlercodes umfasst. Um die COBOL-Schnittstelle einer Designkomponente vollständig zu modellieren, ist die präzise Spezifizierung der verwendeten Datenstrukturen wichtig. Abbildung 5 zeigt beispielhaft, wie eine Datenstruktur in der Detailsicht modelliert wird, und stellt ihre Beziehungen zu den fachlichen Entitäten dar. Wie zu sehen ist, ändern sich im Designmodell die Typen der Attribute und technische Attribute kommen hinzu. Als Attributtypen dürfen im Designmodell nur elementare COBOL-Typen oder Datenstrukturen verwendet werden. Der Designer muss deshalb jeweils für den konkreten Fall bestimmen, wie die objektorientierten Konzepte aus dem fachlichen Modell umgesetzt werden. Im Fallbeispiel wurde die Generalisierung beispielsweise sehr einfach realisiert: Alle Attribute der beiden Entitäten BeteiligtePartei und NatürlichePerson sind in der Datenstruktur BeteiligteParteiRecord zusammengefasst; ein zusätzliches Attribut typ spezifiziert den Typ der Datenstruktur. Die Umsetzung der gerichteten Assoziation zwischen den Entitäten BeteiligtePartei und Adresssatz im fachlichen Modell erfolgt im Designmodell über ein Attribut mit dem Stereotyp «foreignkey». Das fachliche Attribut beschreibungstext ist technisch mit einer Datenstruktur Textzeile der Vielfachheit 8 realisiert. Weder die Komponentensicht auf die

5 Stereotyp «call» bedeuten, dass das Modul dazu Operationen anderer Module in Anspruch nimmt. Anhand der Module KG2110 und KL2111 lassen sich unterschiedliche Beziehungen erklären: Die Abhängigkeitsbeziehung zu der Schnittstelle BeteiligteParteiBearbeiter mit dem Stereotyp «call» spezifiziert beispielsweise, dass das Quellmodul KG2110 während der Laufzeit das zugehörige Zielmodul KL2111 aufruft. Die Assoziation zu der Datenstruktur BeteiligteParteiRecord bedeutet, dass das Modul mit einem Zeiger auf diese Datenstruktur zugreift, weil diese nicht im Speicherbereich des Moduls liegt. Dafür ist die Datenstruktur im COBOL- Quelltext in der LINKAGE SECTION definiert. Die Kompositionsbeziehung des Moduls KL2111 zu BeteiligteParteiRecord bedeutet schließlich, dass die Datenstruktur im Speicherbereich des Moduls liegt. Daraus lässt sich ableiten, dass die Datenstruktur im COBOL-Quelltext von KL2111 in der WORKING-STORAGE SECTION definiert ist. Abb. 6: Modulsicht auf zwei Komponenten Grobarchitektur noch die Detailsicht auf die Datenstrukturen und Steuerungsklassen einer einzelnen Komponente gibt eine vollständige Übersicht über die Zusammenhänge zwischen unterschiedlichen COBOL- Modulen und Datenstrukturen. Dies ist Aufgabe der Modulsicht: Sie spezifiziert, welches COBOL-Modul welche Schnittstelle realisiert, und modelliert die komponentenübergreifenden Beziehungen zwischen den unterschiedlichen Modulen und Datenstrukturen. Die Komponenten und die Schnittstellen der Modulsicht werden zusammen mit den COBOL-Modulen und Datenstrukturen (insbesondere den Copy- Strecken) als Klassen dargestellt. Ein Modul wird dabei durch eine Klasse mit dem Stereotyp «modul» dargestellt; der Modulname setzt sich aus seinem Dateinamen und einer Kurzbeschreibung zusammen. Abbildung 6 zeigt ein Beispiel für eine Modulsicht. Die Realisierungsbeziehung des Moduls KG2100 zu der Schnittstelle BeteiligteParteiVerwalter spezifiziert hier beispielsweise, dass dieses Modul die Operationen der Schnittstelle realisiert. Die Abhängigkeitsbeziehungen mit dem Abb. 7: Dateisicht auf zwei Komponenten Implementierungsmodell Im Designmodell wird die technische Struktur modelliert. Das Implementierungsmodell beschreibt abschließend, welche COBOL-Dateien aus dem Designmodell 6/2004

6 05 A:CKL A:BETEILIGTE-PARTEI-NUMMER PIC 9(4). 08 A:BESCHREIBUNG-TEXTZEILE OCCURS A:BESCHREIBUNG-TEXT PIC X(10). 08 A:VERMOEGENSWERT PIC 9(8). 08 A:TYP PIC X. Listing 1: Quelltext aus der Copy- Strecken-Datei CKL2111.CPY entstehen und welche Abhängigkeiten für die Kompilierung zwischen den Dateien existieren. Zusammen mit dem Quellcode bildet es ein vollständiges Modell der Anwendung. Das in Abbildung 7 dargestellte Klassendiagramm zeigt die Dateisicht auf das Implementierungsmodell für die Komponenten BeteiligteParteiGeschäftslogik und BeteiligteParteiDatenzugriff. Aus den entsprechenden Modulen und Copy-Strecken des Designmodells werden im Implementierungsmodell Moduldateien (dargestellt durch Klassen mit Stereotyp «moduldatei») und Copy-Strecken-Dateien (Klassen mit Stereotyp «copystreckedatei»). Sonstige Dateien werden durch eine Klasse mit dem Stereotyp «datei» repräsentiert. Die Datei beteiligtepartei.dat ist beispielsweise aus der entsprechenden indizierten Datei des Designmodells entstanden. Wie die Dateisicht zeigt, wird auf diese Art jede Designkomponente auf eine Implementierungskomponente mit demselben Namen abgebildet. Aus der Copy-Strecke CKL2111 BeteiligteParteiRecord wird im Implementierungsmodell die Datei CKL2111.CPY. Dieses Beispiel verdeutlicht noch einmal die Durchgängigkeit der Methodik: Ausgehend von den Klassen BeteiligtePartei und NatürlichePerson des Domänenmodells ist schließlich eine COBOL-Datenstruktur entstanden. Listing 1 zeigt, dass die entsprechende COBOL-Quellcode-Datei aus einem Group Item mit der Nummer der Copy-Strecke als Name besteht. Es enthält die Attribute und Kompositionen der Copy-Strecke. Die Anzahl der Textzeilen (in diesem Fall acht) wird im Quelltext durch die Klausel OCCURS angegeben. Um in COBOL den REPLACING- Mechanismus nutzen zu können (siehe unten), wird in einer Copy-Strecke per Konvention immer A: vor jedes Feld gesetzt. Außerdem wird die Rolle einer Komposition vor den Namen des Attributs gesetzt. Somit wird aus dem Attribut text der Datenstruktur Textzeile das Feld A:BESCHREIBUNG-TEXT. IDENTIFICATION DIVISION. PROGRAM-ID. KL2111. INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT BP-DATEI ASSIGN TO "beteiligtepartei.dat" ORGANIZATION IS INDEXED RECORD KEY IS FD-BETEILIGTE-PARTEI-NUMMER DATA DIVISION. FILE SECTION. FD BP-DATEI LABEL RECORDS ARE STANDARD. 01 FD-BETEILIGTE-PARTEI-RECORD. COPY "CKL2111.CPY" REPLACING ==A:== BY ==FD-==. WORKING-STORAGE SECTION. 01 DATEN-BETEILIGTE-PARTEI-RECORD. COPY "CKL2111.CPY" REPLACING ==A:== BY ==DATEN-==. Listing 2: Quelltext aus der Modul-Datei KL2111.COB Aus dem Modul KL2111 BeteiligteParteiBearbeiter wird im Implementierungsmodell die Datei KL2111.COB. Listing 2 zeigt, welcher Quelltext aus der Komposition zwischen dem Modul und der Copy-Strecke im Designmodell entstanden ist. Zusätzlich wird der Quelltext dargestellt, der sich aus der Assoziation zwischen dem Modul und der indizierten Datei abgeleiten lässt. Die Komposition zur Copy-Strecke BeteiligteParteiRecord bedeutet, dass die Datenstruktur im Arbeitsspeicher des Moduls liegt. Deshalb wird die Datenstruktur in der WORKING-STORAGE SECTION definiert. Da es sich bei der Datenstruktur um eine Copy-Strecke handelt, wird die COPY-Anweisung verwendet. Es sollte darauf geachtet werden, dass mit Hilfe der REPLA- CING-Klausel die Rolle der Datenstruktur vor die Felder gesetzt wird. Das ist besonders hilfreich, wenn ein Modul dieselbe Datenstruktur mehrmals verwendet. Aus dem Modul KG2110 BeteiligteParteiVerwalter wird im Implementierungsmodell die Datei KG2110.COB. Listing 3 zeigt, welcher Quelltext aus der Assoziation zwischen dem Modul und der Copy-Strecke im Designmodell entstanden ist. Die Assoziation zu der Copy-Strecke BeteiligteParteiRecord bedeutet, dass auf diese Datenstruktur durch eine Referenz zugegriffen wird. Diese Referenz kann entweder ein Zeiger in der WORKING-STORAGE SECTION sein oder ein Parameter in der Klausel PRO- CEDURE DIVISION USING. In jedem Fall muss die Datenstruktur in der LINKAGE SECTION definiert werden. Auch hier wird die COPY- Anweisung verwendet. IDENTIFICATION DIVISION. PROGRAM-ID. KG2110. LINKAGE SECTION. 01 DZ-DATEN-BETEILIGTE-PARTEI-RECORD. COPY "CKL2111.CPY" REPLACING ==A:== BY ==DZ-DATEN-==. Listing 3: Quelltext aus der Modul-Datei KG2110.COB Fazit Die beschriebene Methodik erlaubt eine durchgängige Entwicklung von COBOL- Anwendungen ohne Brüche. Die Erarbeitung der beschriebenen Modelle gewährleistet die Einheitlichkeit und Qualität der Entwicklungsergebnisse und stellt sicher, dass auf dem Weg von der Analyse bis hin zum COBOL-Quellcode keine Anforderungen verloren gehen. Da das zu Grunde liegende Modellsystem detailliert und ausreichend formal definiert ist, lassen sich nun in einem zweiten Schritt Werkzeuge bauen, um die Entwicklungsabläufe weiter zu beschleunigen. Insbesondere der Schritt vom fachlichen Modell zum Designmodell sowie die Generierung der Systemdokumentation und von COBOL-Code-Rahmen sind dabei lohnende Aufgaben. Längerfristig kann die entstandene Methodik auch den Übergang zu objektorientierten Systemen erleichtern: Da Anwendungsfall-Modell und fachliches Modell vollkommen unabhängig von COBOL sind, lassen sie sich ohne Weiteres auch dazu benutzen, objektorientierte Design- und Implementierungsmodelle zu erstellen. Dies ist sowohl für die Neuimplementierung als auch für die Integration von Komponenten von hohem Nutzen. Literatur & Links [IZB03] Informatik Zentrum Bayern (IZB SOFT), Modellierung, Interne Standards, 2003 [Nob02] C.R. Nobe et al, Modellbasierte Entwicklung: Fünf von Boeing eingesetzte Prozesse, OnTime Spezialdruck, Modellbasierte Software-Entwicklung, 2002 (siehe: [OMG] Object Management Group, Model Driven Architecture (MDA), siehe: [Win03] S. Winter, Modellbasierte Entwicklung einer COBOL-Anwendung, Diplomarbeit, TU München, November 2003 (siehe: www4.in.tum/~winterse)