Modellbasierte Entwicklung einer COBOL-Anwendung

Technische Universität München
Fakultät für Informatik
Diplomarbeit
Modellbasierte Entwicklung einer
COBOL-Anwendung
Sebastian Winter
moCa

Technische Universität München
Fakultät für Informatik
Diplomarbeit
Modellbasierte Entwicklung
einer COBOL-Anwendung
Sebastian Winter
Aufgabensteller:
Betreuer:
Externe Betreuer:
Prof. Dr. Manfred Broy
Dr. Andreas Rausch
TU München
Oliver Engelhardt
IZB SOFT
Dr. Klaus Bergner
4Soft GmbH
Abgabedatum: 15. November 2003

Erklärung
Ich versichere, dass ich diese Diplomarbeit
selbständig verfasst und nur die angegebenen
Quellen und Hilfsmittel verwendet habe.
(Sebastian Winter)
München, den 15. November 2003

Danksagung
An dieser Stelle darf ich mich bei meinen beiden Betreuern, Andreas Rausch und
Oliver Engelhardt, bedanken. Ihr Blick für das Wesentliche sowie die vielen hilfreichen
Gespräche unterstützten mich sehr bei der Erstellung dieser Arbeit.
Auch möchte ich mich bei dem PROFiL-Team bedanken, das trotz eines hohen Termindrucks
sich immer die Zeit genommen hat, mir neue Sachverhalte zu erklären.
Außerdem hat das Team die Einarbeitungszeit in das Entwicklungsumfeld der
IZB SOFT sehr freundlich gestaltet.
Nicht zuletzt geht mein Dank an die beiden Firmen, 4Soft und IZB SOFT, die es mir
ermöglicht haben, meine Diplomarbeit nicht im stillen Kämmerlein, sondern eingebunden
in ein laufendes Projekt zu schreiben. Die Mittel, die mir beide Firmen zur
Verfügung stellten, sowie die Unterstützung waren weit mehr als ein Student erwarten
darf. Es war für mich eine tolle Erfahrung, im Umfeld von zwei Firmen meine Diplomarbeit
zu schreiben.
S. W.

Inhalt
1 Einleitung und Motivation................................................................................ 1
1.1 Ausgangssituation.......................................................................................2
1.2 Problemstellung ..........................................................................................3
1.3 Zielsetzung..................................................................................................4
1.4 Aufbau der Arbeit .......................................................................................4
2 Das Umfeld in der IZB SOFT............................................................................ 7
2.1 Die IZB SOFT.............................................................................................7
2.2 Der Softwareentwicklungsprozess..............................................................8
2.3 Die Architektur der Anwendungen...........................................................10
2.4 COBOL: Begriffe & Konzepte .................................................................15
3 Modellbasierte Softwareentwicklung............................................................ 23
3.1 Grundlagen der modellbasierten Entwicklung..........................................23
3.2 Das bisherige Vorgehen der IZB SOFT....................................................27
3.3 Die Modelle der neuen Methodik im Überblick.......................................33
4 Das Fallbeispiel »Kundenmappe«................................................................. 35
4.1 Systemvision.............................................................................................35
4.2 Anwendungsfallmodell.............................................................................37
4.3 Fachliches Modell.....................................................................................44
4.4 Designmodell ............................................................................................53
4.5 Implementierungsmodell ..........................................................................64
4.6 Zusammenfassung.....................................................................................71
5 UML-Profil für moCa ...................................................................................... 73
5.1 Anwendungsfallmodell.............................................................................74
5.2 Fachliches Modell.....................................................................................76
5.3 Designmodell ............................................................................................81
5.4 Implementierungsmodell ..........................................................................88
6 Zusammenfassung und Ausblick ................................................................. 91
Literatur .................................................................................................................. 95

1 Einleitung und Motivation
Als IT-Dienstleister entwickelt die IZB SOFT 1 Anwendungen für Bank- und Kreditinstitute.
Bei den Hauptkunden, den bayerischen Sparkassen, werden, wie für ein Informationssystem
der Finanzdienstleistung typisch, Terminals und Großrechner eingesetzt.
In den Filialen der Sparkassen stehen die mit dem Großrechner verbundenen
Terminals und wickeln die Geschäftsprozesse unter Verwendung der vom Großrechner
angebotenen Dienste ab.
Realisiert werden diese Dienste auf dem Großrechner mit COBOL-Programmen. Solche
Anwendungen, die in COBOL geschrieben sind, werden als »Legacy«-
Anwendungen bezeichnet – also als Altlast, da sie in einer Sprache verfasst sind, die
schon seit 1959 existiert und die keine Unterstützung für moderne Konzepte bietet.
Aus verschiedenen Gründen ist die vollständige Ablösung der COBOL-Systeme für
die Banken nicht möglich:
Erstens, es existiert eine komplette Infrastruktur, die auf diese Technologie zugeschnitten
ist, sowie funktionierende Anwendungen, die im Kern auf mehrere Millionen
Zeilen COBOL-Quelltext basieren.
Zweitens, wurde jahrzehntelang Know-how auf diesem Gebiet gesammelt. Das hat
zur Folge, dass die Erfahrung und das Wissen des Unternehmens in den Köpfen der
Mitarbeiter stecken, die auf COBOL spezialisiert sind.
Und nicht zuletzt, der wirtschaftliche Aspekt: Die Kosten, welche bei der vollständigen
Migration der COBOL-Systeme zu einer modernen Technologie anfallen würden,
könnten, gerade in der derzeit herrschenden wirtschaftlichen Situation, nicht aufgebracht
werden.
Anfänglich wurden diese Anwendungen monolithisch implementiert. Für die Struktur
wurde die Variante »Ein großer Klotz« gewählt. Ein solches, schlecht strukturiertes
Innenleben war selbst für ein paar Auserwählte schwer zu verstehen. So etwas ist,
wenn überhaupt, nur sinnvoll bei einer Software, die nicht erweitert werden muss oder
deren Komplexität gering ist. Heutzutage sind die Softwaresysteme sehr komplex und
Flexibilität ist eine Schlüsselanforderung.
Diese Schlüsselanforderung gilt auch für die IZB SOFT: Deren Anwendungen werden
laufend weiterentwickelt und neue Anforderungen der Sparkassen integriert. Um wei-
1 Informatik-Zentrum Bayern – Software-Gesellschaft der bayerischen Sparkassen – GmbH & Co KG
1

2 Einleitung und Motivation
terhin erfolgreich zu sein, muss das Unternehmen seine Software flexibel und effizient
entwickeln. Deswegen wird eine Anwendungsarchitektur gewählt, die das System
klar nach Zuständigkeiten zerlegt und die einzelnen Bauteile geschickt hierarchisch,
z. B. in Schichten, anordnet.
1.1 Ausgangssituation
Einerseits ist es nur mit Komponentenbildung überhaupt möglich, flexible Software
zu entwickeln; andererseits darf nicht außer Acht gelassen werden, dass ein komplexes
System, welches in Komponenten zerlegt wird, ein komplexes System bleibt.
Setzt man Modelle ein, um unterschiedliche Abstraktionsebenen zu modellieren, entsteht
eine beträchtliche Menge an Information: Komponenten, Schnittstellen, Datenstrukturen
– alles muss spezifiziert werden. Oft werden Teile des Systems aus verschiedenen
Perspektiven mehrmals beschrieben; diese Zusammenhänge gilt es, konsistent
zu halten.
Einen Weg diese Komplexität beherrschbar zu machen, beschreiten modellbasierte
Entwicklungsmethoden. Ein entscheidender Aspekt ist, dass Beziehungen zwischen
den einzelnen Modellen definiert werden und somit eine Modellstruktur geschaffen
wird. Diese Modellstruktur stellt die zentrale Grundlage für die Bewältigung der Information
dar. Die Beziehungen zwischen den Modellen ermöglichen es, die verschiedenen
Abstraktionsebenen konsistent zu halten. Auch ist es möglich, bei der Erstellung
eines Modells einen ersten Rahmen aus anderen Modellen abzuleiten, d. h.,
dass Modelle als zentrale Elemente den Entwicklungsprozess steuern. Die für die verschiedenen
Abstraktionsebenen definierten Modelle haben, neben ihrer Rolle als visualisierende
Elemente, die Aufgabe, das System aus dieser Perspektive vollständig zu
beschreiben. Auf der Grundlage dieser Beschreibung ist es dann möglich, Werkzeuge
zu konzipieren, welche die Aufgaben während der Entwicklung automatisieren.
Die IZB SOFT hat bereits einige Aspekte der modellbasierten Methodik in ihren Entwicklungsprozess
integriert. Als Notationsmittel wird die Unified Modeling Language
(UML) 2 eingesetzt – ein Hilfsmittel, um Software einheitlich zu modellieren. In dieser
Arbeit wird auf die Version 1.5. [OMG] Bezug genommen. Die einzelnen Modelle
sind in den jeweiligen internen Standards definiert. Im Rahmen der Projekte KBS 3
und PROFiL 4 sind Konzepte und Leitfäden [IZB 2003a] entstanden, die auf diesen
Standards aufbauen.
2
3
4
OMG-UML-Quellen im Internet: www.omg.org/uml.
KBS steht für Kernbankensystem.
Vgl. Abschnitt 2.1.

Problemstellung 3
1.2 Problemstellung
Die modellbasierte Vorgehensweise wirft Probleme auf, die im Folgenden vor dem
Hintergrund des Entwicklungsprozesses der IZB SOFT behandelt werden. Der Prozess
lässt sich wie folgt kurz skizzieren:
Zuerst werden die Anforderungen analysiert und modelliert, danach wird das System
anhand der Anforderungen nach fachlichen Gesichtspunkten entworfen. Dieser erste
Entwurf wird dann in den technischen Modellen verfeinert, d. h. Implementierungsdetails
der verwendeten technischen Plattform werden eingearbeitet. Zuletzt werden
die technischen Modelle in COBOL-Programme umgesetzt und getestet.
Auf fachlicher Ebene werden Modelle bereits erfolgreich eingesetzt, um über das zu
entwickelnde System zu diskutieren. Auch Teile der Generierung wurden bereits realisiert.
So ist es möglich, das Fachkonzept aus den Modellen zu generieren.
Jedoch kommt es, wenn die fachliche Modellierung abgeschlossen ist, zu Brüchen in
der Entwicklung, wie Abbildung 1-1 zeigt.
Fachliches Modell
1. Bruch
Technische Modelle
2. Bruch
COBOL-Programme
Abbildung 1-1 Brüche in der Entwicklung
Der erste Bruch findet zwischen dem fachlichen Modell und den technischen Modellen
statt, d. h. es gibt hier keinen durchgängigen Übergang. Deswegen besteht die
Gefahr, dass die erstellten technischen Modelle nicht mit den fachlichen Modellen
zusammenpassen. Dazu kommt, dass der Übergang von Hand umgesetzt wird. Diese
Vorgehensweise ist zum einen aufwendig und birgt zum anderen ein Risiko, da die
Konsistenz der Modelle nicht automatisch überprüft wird.
Der zweite Bruch ist zwischen den technischen Modellen und den COBOL-Programmen,
d. h. die Entwickler implementieren die COBOL-Programme unabhängig
von den spezifizierten Modellen. Wenn nicht auf der Grundlage der bereits spezifizierten
Modelle entwickelt wird, hat dies zur Folge, dass einerseits die Architektur der

4 Einleitung und Motivation
Software nicht konsistent mit den Modellen ist, und andererseits wichtige Designentscheidungen
verloren gehen. Auch hier fehlt ein klarer Zusammenhang zwischen dem
Modell und den Implementierungs-Konzepten von COBOL.
1.3 Zielsetzung
Kernziel dieser Arbeit ist die modellbasierte Entwicklungsmethodik der IZB SOFT
unter Berücksichtigung der bestehenden Standards weiterzuentwickeln. Dabei sollen
die Brüche in der bisherigen Vorgehensweise behoben, die Entwickler entlastet und
die Effizienz der Methodik gesteigert werden. Dieses Ziel lässt sich in folgende Teilziele
zerlegen:
Entwicklung einer Methode für die Umsetzung der fachlichen Modelle zu technischen
Modellen: Die Beziehungen zwischen den Elementen aus den technischen
Modellen und dem fachlichen Modell sollen definiert werden. Zusätzlich
ist die genaue Spezifikation der Komponenten-Schnittstellen sicherzustellen.
Entwicklung einer Methode für die Umsetzung der technischen Modelle nach
COBOL-Quelltext: Die Menge von Abbildungen, welche die Elemente der technischen
Modelle in COBOL-Quelltext umsetzen, soll definiert werden.
Integration der Methoden und Weiterentwicklung der Modelle: Die verschiedenen
Methoden sollen zu einer durchgängigen Methodik integriert werden. Die
Anforderungen der Methodik an die Modelle sind zusammen mit den Erweiterungen
der Standards zu dokumentieren. Auch sind Metamodelle für die einzelnen
Modelle zu erstellen und die Beziehungen zwischen den Elementen der
verschiedenen Metamodelle zu erfassen. Schließlich soll die Methodik eine
Grundlage für die Erstellung von Werkzeugen schaffen, um Schritte des systematischen
Vorgehens zu automatisieren.
Erprobung der Ergebnisse anhand eines durchgängigen Fallbeispiels: Für einen
Ausschnitt aus dem laufenden PROFiL-Teilprojekt »Kundenmappe« sollen die
entsprechenden Modelle erstellt und auf Durchgängigkeit geprüft werden. Darüber
hinaus soll auf die Verständlichkeit, Durchgängigkeit und Einfachheit der
Methodik geachtet werden.
1.4 Aufbau der Arbeit
Die Arbeit beginnt im zweiten Kapitel mit der Beschreibung des Umfelds bei der
IZB SOFT. Nach einer kurzen Vorstellung des Unternehmens folgt eine Einführung
in den dort verwendeten Softwareentwicklungsprozess und die Beschreibung einer
typischen Anwendungsarchitektur. Im letzten Abschnitt werden die wichtigsten Konzepte
der Programmiersprache COBOL zusammengefasst.

Aufbau der Arbeit 5
Das dritte Kapitel erläutert den Begriff modellbasierte Softwareentwicklung und führt
in die Konzepte der modellbasierten Methoden ein. Mit dem Ziel, das bisherige Vorgehen
der IZB SOFT zu beschreiben, werden zunächst die firmeninternen Standards
zusammengefasst. Danach wird ein Überblick über die Modelle der entwickelten Methodik
gegeben.
Das vierte Kapitel behandelt ein durchgängiges Beispiel, welches als Grundlage für
die Beschreibung der Methodik dient. Nach einer kurzen Einführung werden alle Modelle,
von dem Anwendungsfallmodell bis hin zum Implementierungsmodell, vorgestellt
und mit einer Beschreibung der Erweiterung versehen. Danach folgt eine kurze
Bewertung der wesentlichsten Änderungen.
Das fünfte Kapitel ist eine Zusammenstellung aller Modelle, die von der Methodik
genutzt werden. Für jedes Modell wird das zugrunde liegende Metamodell beschrieben
und ein Überblick über die Elemente gegeben.
Das letzte Kapitel fasst das Vorgehen und die Ergebnisse der Arbeit zusammen. Darauf
folgt ein Ausblick auf die möglichen Weiterentwicklungen mit der vorgestellten
Methodik als Grundlage. Der Ausblick schließt eine Bewertung von erforderlichen
Werkzeugen mit ein.

2 Das Umfeld in der IZB SOFT
Dieses Kapitel gibt einen Überblick über das Umfeld in der IZB SOFT. Zunächst wird
das Unternehmen kurz vorgestellt und das Projekt PROFil beschrieben. Darauf folgt
eine Einführung in den Softwareentwicklungsprozess sowie eine Erläuterung der Architektur
der Anwendungen. Das Kapitel schließt mit einer Zusammenfassung der
wichtigsten COBOL-Konzepte.
Eine weitere Aufgabe dieses Kapitels ist es, in die Begriffswelt der Firma einzuführen.
Es ist – wie immer bei Begriffen – Vorsicht geboten. Softwaretechnik ist, vergleicht
man sie mit anderen Bereichen, eine junge Kunst. Deshalb sind die meisten
Begrifflichkeiten nicht als Definition zu verstehen: Jede Methode, jeder Entwickler
versteht in der Regel etwas anderes unter einem Begriff. Besonders kritisch ist die
Verwendung von Begriffen für verschiedene Abstraktionsebenen. Es genügt nicht,
von den Begriffen auf die Bedeutung zu schließen, sondern die Definition des Begriffs
muss genau studiert werden. Diese Arbeit bemüht sich, zu den Begriffen immer
eine Beschreibung zu liefern, welche die Bedeutung in dem vorliegenden Kontext
verdeutlichen soll.
2.1 Die IZB SOFT
Die IZB SOFT entwickelt seit 30 Jahren Anwendungssoftware für Banken und Versicherungen.
Hauptkunden sind die bayerischen Sparkassen; insgesamt sind es
82 bayerische Sparkassen, welche die IT-Dienstleistungen in Anspruch nehmen. Die
IZB SOFT beschäftigt an den Standorten München und Nürnberg rund
900 Mitarbeiter; im Jahre 2002 wurde eine Bilanzsumme von rund 144 Millionen
Euro 5 erreicht.
Ein Produkt, das die IZB SOFT für die bayerischen Sparkassen entwickelt hat und
weiterentwickelt, ist PROFil. Im Umfeld dieses Projekts ist die vorliegende Arbeit
entstanden. PROFil umfasst eine Reihe von Systemen, welche die Geschäftsprozesse
der Sparkassen unterstützen. Als Beispiel kann etwa ein Teilschritt eines sehr einfachen
Geschäftsprozesses dienen: Ein Mitarbeiter einer Filiale der Sparkassen, der
einen Kunden berät, möchte sich die Daten des Kunden anzeigen lassen. Die Anwendung
stellt diesen Dienst zur Verfügung.
5
Diese Daten stammen von den Internetseiten der IZB SOFT: www.izb-soft.de.
7

8 Das Umfeld in der IZB SOFT
Die Ansprüche an die Qualität der Software für Finanzdienstleistung sind sehr hoch.
Die technische Infrastruktur ist aufgrund der vielen Zugriffe einer hohen Belastung
ausgesetzt. Zum Beispiel besteht das Service-Netz der bayerischen Sparkassen aus
3100 Geschäftsstellen, welche die Infrastruktur nutzen. Insgesamt sind an die
22 Millionen Konten zu verwalten – daraus ergibt sich eine hohe Anzahl an Buchungen,
die täglich abgewickelt werden müssen.
2.2 Der Softwareentwicklungsprozess
Die Entwicklung einer Anwendung ist keine triviale Aufgabe. Um den Projektverlauf
und die Ergebnisse planbar machen zu können, wird ein Softwareentwicklungsprozess
eingesetzt. Ein Prozess behandelt die Gesamtheit aller Aktivitäten, d. h. sowohl die
Aktivitäten, die den Ablauf koordinieren und den Entwicklungstand überwachen, als
auch die Aktivitäten, die sich mit der Entwicklung der Software beschäftigen. Ein
Prozess verfolgt immer auch eine Philosophie. Er wählt also eine bestimmte Anschauung
auf die Sachverhalte und gibt Leitbilder vor, an denen man sich orientieren
kann. Der Prozess mit dem die IZB SOFT ihre Software entwickelt, ist durch einen
Standard vorgegeben, der im nächsten Abschnitt beschrieben wird.
2.2.1 Systembereitstellungsprozess
Der Systembereitstellungsprozess (SBP) [IZB 2003b] definiert einen Rahmen für die
Abwicklung von Softwareprojekten, mit dem Ziel, für einen reibungslosen und effizienten
Projektablauf zu sorgen. Deswegen werden in dem SBP z. B. Verantwortungen
verteilt.
Der Prozess, den die IZB SOFT anwendet, um ihre Produkte zu entwickeln, orientiert
sich an dem Rational Unified Process (RUP) 6 , ein Softwareentwicklungsprozess, der
von dem Unternehmen Rational Software entwickelt worden ist. Der RUP versucht
einige »Best Practices« umzusetzen, die auch im SBP Verwendung finden. Im Folgenden
werden die wichtigsten Eigenschaften des Prozesses vorgestellt.
Iterative Vorgehensweise. Der SBP basiert auf einer iterativen Vorgehensweise,
d. h. die Vorgehensweise ist eine bewusste Abgrenzung zum Wasserfallmodell. Die
Disziplinen, die in der Softwareentwicklung mittlerweile gängig sind, nämlich Analyse,
Entwurf, Implementierung und Test, werden zu einer Iteration zusammengefasst
und während eines Projektes mehrfach durchlaufen (vgl. Abbildung 2-1). Eine Iteration
schließt immer mit einem ausführbaren Programm ab, das einen Teil der Anforderungen
bereits erfüllt. In den weiteren Iterationen werden Anforderungen hinzuge-
6
Der RUP ist in [Jacobson1999] genau beschrieben.

Der Softwareentwicklungsprozess 9
nommen, in den Entwurf des Systems eingearbeitet und implementiert. Ein solches
Vorgehen wird als inkrementell bezeichnet.
Test
Analyse
Implementierung
Entwurf
Abbildung 2-1 Disziplinen einer Iteration
Im Folgenden werden die Disziplinen einer Iteration erklärt:
Analyse. In der Analyse werden die Anforderungen ermittelt. Diese ergeben sich
aus dem Anwendungsbereich, wie z. B. dann, wenn ein bestimmter Geschäftsprozess
der Sparkassen unterstützt werden soll. Die Anforderungen werden zu-
¡
sammen mit den Experten des Anwendungsbereichs ermittelt.
Entwurf. Kernaufgabe beim Entwurf ist die Erstellung einer Architektur. Dazu
muss eine Struktur des Systems entworfen und eine geeignete Zerlegung des
¡
Systems gefunden werden. Aus Gründen der Wiederverwendbarkeit und zur
Bewältigung der Komplexität wird das System in Komponenten zerlegt.
Implementierung. Gegenstand der Implementierung ist die Umsetzung der Komponenten
in Quelltext. Die Vorgaben, die im Entwurf spezifiziert wurden, sollen
¡
eingehalten werden.
Test. Das Testen von Software ist eine sehr wichtige Aufgabe, nicht nur um die
Qualität der Software zu sichern, sondern auch um frühzeitig Fehler und Risiken
¡
zu erkennen. Auch für den Test sind modellbasierte Verfahren geeignet. In dieser
Arbeit wird das Testen nicht behandelt – später wäre es jedoch möglich, anhand
der Modelle, ein Verfahren für automatisiertes Testen zu entwickeln.
Da ein Prozess und damit u. a. auch die Planbarkeit der Entwicklung von hoher Bedeutung
sind, wird die Folge von Iterationen in Phasen unterteilt. Jede dieser Phasen
legt einen Schwerpunkt in den Aktivitäten der Iteration fest und definiert einen Meilenstein,
der akzeptiert werden muss, um in die nächste Phase zu gelangen. In der
IZB SOFT werden diese Phasen Konzeption, Entwurf, Konstruktion und Übergang
genannt.
Ein anwendungsfallzentrierter Prozess. Anwendungsfälle bilden den Ausgangspunkt
für viele der durchzuführenden Aktivitäten. Die Funktionalität, die in einer Iteration
umgesetzt wird, orientiert sich an den Anwendungsfällen. Damit ist gewährleistet,
dass alle Aktivitäten auf die Erfüllung von Anforderungen zurückzuführen sind.

10 Das Umfeld in der IZB SOFT
Ein architekturzentrierter Prozess. Ziel ist es, so früh wie möglich eine grobe Systemstruktur
zu entwickeln. Die Architektur, die bei der IZB SOFT zum Einsatz
kommt, wird im folgenden Abschnitt beschrieben. Ausgangsbasis ist der Standard,
d. h. eine definierte Architekturbeschreibung.
2.3 Die Architektur der Anwendungen
In diesem Abschnitt wird die Architektur der Anwendungen genauer betrachtet. Die
Beschreibung einer Architektur gibt einen Überblick über das System und hilft dem
Entwickler die Aufgabenstellung zu verstehen. An dieser Stelle wird die Architektur
einer allgemeinen Anwendung beschrieben – später wird diese, anhand des Fallbeispiels,
konkretisiert.
Eine Architektur betrachtet die Anwendung aus verschiedenen Sichten und zeigt immer
nur so viel Information an, wie zum Verständnis notwendig ist. Dadurch umreißt
sie die Anwendung und macht deutlich, welche Prinzipien verfolgt werden müssen,
um bereits bekannte Problemfelder zu vermeiden. Insbesondere wird darauf geachtet,
dass die Zusammenhänge zwischen den einzelnen Teilen des Systems deutlich gemacht
werden.
Um die Architektur zu beschreiben, wird ein Teil des von [Kruchten] vorgeschlagenen
»4+1«-Sichten-Modells genutzt, nämlich die physische und die logische Architektur;
die weiteren Sichten werden ausgespart, da sie Teile der Anwendung beschreiben,
die nicht zum allgemeinen Verständnis beitragen und für die Arbeit nicht relevant
sind.
Zunächst wird auf die physische Architektur eingegangen. Schwerpunkt dieser Betrachtungsweise
ist die eingesetzte Hardware und die daraus resultierende Infrastruktur.
Beschrieben wird auch, welche Plattformen die einzelnen Knoten bereitstellen.
Besonders für Leser, die nicht mit dem Bereich der Großrechner vertraut sind, ist dieser
Überblick interessant.
Im Anschluss wird die logische Architektur der Anwendung erläutert. Dort wird
hauptsächlich auf die grobe Zerlegung des Systems eingegangen, insbesondere auf die
Schichtenarchitektur. Hinzu kommt eine Einführung in die Entwurfsprinzipien.
2.3.1 Physische Architektur
Die Welt der Großrechner besteht aus Terminals und Mainframes, die über ein Netzwerk
verbunden sind. Abbildung 2-2 zeigt eine typische Client/Server-Architektur,
wie sie im Bereich der Finanzanwendungen häufig zu finden ist. Auf den Clients läuft
eine 3270-Terminal-Emulation, die über ein LAN/WAN auf IBM-Großrechner zugreift.
Für die Datenverwaltung benutzen die Großrechner verschiedene Datenbanken.
Ursprünglich waren die Arbeitsplatz-Rechner 3270 Display Stations, die über einen

Die Architektur der Anwendungen 11
eigenen Controller mit dem Großrechner verbunden waren. Heutzutage werden PCs
mit dem Betriebsystem Windows NT verwendet, auf denen eine Software läuft, die
ein 3270-Terminal emuliert.
LAN/WAN
DB2
Windows NT
3270 Emulation
IBM S/390
Großrechner
ADABAS
Abbildung 2-2 Eine typische Client/Server-Architektur
Die Hauptarbeit wird vom Großrechner erledigt. Ein 3270-Terminal zeigt lediglich
Masken (Screen Maps) an. Unter einer Maske wird ein festgelegtes Layout mit diversen
Eingabefeldern verstanden. Der Großrechner schickt mit dem 3270-Protokoll die
Masken an das Terminal. Dieser zeigt sie an und interagiert mit dem Benutzer. Die
mit den Benutzerdaten angereicherten Masken werden an den Großrechner zurückgeschickt.
Dieser kann dann die Daten aus den Eingabefeldern verarbeiten.
Der Großrechner bietet als Plattform einen S/390-Mainframe von IBM auf dem
OS/390 läuft an. OS/390 ist ein System mit Stapelbetrieb (batch operation). Programme
werden in Batch Jobs aufgeteilt, die nacheinander in den Speicher geladen
und ausgeführt werden. Ein Batch Job stellt einen vollständig spezifizierten Auftrag
dar und erhält Rechenzeit solange bis er fertig ist. Der Begriff stammt aus den Zeiten,
als Programme noch in Form von Lochkarten stapelweise in den Großrechner geladen
worden sind. Interagieren kann der Benutzer mit einem Batch Job natürlich nicht.
Abhilfe schafft das Customer Information Control System (CICS). Dieses System
läuft als Batch Job unter OS/390. [Menendez] schlägt vor:
[…] you can think of CICS as an operating system within an operating system.
CICS ermöglicht es, nicht nur interaktive Software zu entwickeln, sondern auch
Online Transaction Processing zu unterstützen, d. h. es bestehen Funktionen, um
Transaktionen zu verwalten. Außerdem werden Schnittstellen für den Datenbankzugriff
angeboten. Für DB2 steht z. B. die Schnittstelle CICS/DB2 Attachment Facility
zur Verfügung. Als Datenbank wird auch ADABAS eingesetzt.
CICS-Programme sind in der Regel in COBOL geschrieben. Im folgenden Abschnitt
werden die Teile, aus denen sich eine CICS/COBOL-Anwendung zusammensetzt,
sowie Strategien zur Vermeidung eines Monolithen beschrieben.

12 Das Umfeld in der IZB SOFT
2.3.2 Logische Architektur
Die logische Architektur gibt einen Überblick über die Organisation der Softwarebausteine
des Systems. Diese ist so gewählt, dass die funktionalen Anforderungen klar
strukturiert realisiert werden können. Für die betrachtete Anwendung ergeben sich die
funktionalen Anforderungen aus den zu unterstützenden Geschäftsprozessen der
Sparkassen.
In der IZB SOFT ist der Rahmen für die Architektur der Anwendungen in einem
Standard definiert [IZB 2002b]. Dieser hat die Aufgabe, für weitere Entwicklungen
eine einheitliche Architektur zu schaffen. Der Kern besteht aus zwei Konzepten:
(1) Zerlegung der Anwendung in Komponenten; und (2) Organisation der Komponenten
in Form einer Schichtenarchitektur. Im Folgenden werden die für diese Arbeit
relevanten Punkte zusammengefasst.
Kapselung. Kapselung ist ein wichtiges Konzept, das auf verschiedenen Ebenen
eingesetzt wird. Es basiert auf dem Prinzip, Implementierungsdetails zu verstecken
und eine Abstraktion nur durch eine Schnittstelle zugänglich zu machen. [Booch] definiert
Kapselung als:
The process of compartmentalizing the elements of an abstraction that constitute
its structure and behavior; encapsulation serves to separate the contractual
interface of an abstraction and its implementation.
Diese Trennung von Innenansicht (white box) und Außenansicht (black box) wird bei
Prozeduren, Modulen und Komponenten angewendet.
Komponenten. Unter einer Komponente wird in dieser Arbeit ein Konzept verstanden,
um Bauteile der Anwendung zusammenzufassen. Eine Komponente kapselt
diese Menge von Bauteilen und spezifiziert die Schnittstellen, über die mit der Komponente
kommuniziert werden kann. Die Implementierung der Schnittstellen, also die
gekapselten Bauteile, ist von außen nicht sichtbar. Eine Schnittstelle besteht aus einer
Menge von Signaturen von Operationen sowie aus Vereinbarungen von Datenstrukturen.
Schichtenarchitektur. Die Zerlegung eines Systems in Schichten ist eine weit verbreitete
Architekturform. Jede Schicht bietet höhere Dienste an, aufbauend auf den
Basisdiensten der untergeordneten Schichten. Dabei ist eine Schicht nur von untergeordneten
Schichten abhängig und besitzt kein Wissen über höhere Schichten. Neben
der geschlossenen Architektur, in der jede Schicht nur von der ihr untergeordneten
Schicht abhängig sein darf, definiert [Buschmann] die Variante Relaxed Layered Sys-

Die Architektur der Anwendungen 13
tem. In dieser gelockerten Variante darf jede Schicht alle, ihr untergeordneten,
Schichten benutzen 7 .
Die folgenden Absätze beschreiben die Aufgaben der einzelnen Schichten und grenzen
sie voneinander ab.
Präsentation. Gegenstand der Präsentationsschicht ist die Realisierung der Benutzerschnittstelle.
Dazu werden die Daten dem Benutzer angezeigt und die Ereignisse,
die der Benutzer auslöst, sei es durch seine Tastatur oder durch einen
¢
Mausklick, verarbeitet. Auch die Dialogsteuerung ist Aufgabe der Präsentation.
Hierfür werden die entsprechenden Geschäftsvorfälle (Basisdienste der Steuerungsschicht)
aufgerufen und Daten, die während eines Ablaufes benötigt werden,
temporär gespeichert.
Steuerung. Die von der Steuerungsschicht angebotenen Dienste repräsentieren
Geschäftsvorfälle. Unter einem Geschäftsvorfall wird ein, in sich abgeschlossener,
fachlicher Vorgang verstanden. Beispiele für Geschäftsvorfälle sind »Kunde
¢
finden« oder »Kundenmappe zusammenstellen«. Ein Geschäftsvorfall wird weiter
in fachliche Funktionen (Basisdienste der Geschäftslogikschicht) unterteilt.
Zur Abarbeitung eines Geschäftsvorfalles wird eine Reihe von fachlichen Funktionen
ausgeführt. Zudem gibt es technische Aufgaben zu erfüllen: Ein Geschäftsvorfall
ist zustandslos. Für jeden Aufruf wird eine Transaktion geöffnet,
die mit der Übergabe eines konsistenten Ergebnisses abschließt.
Geschäftslogik. Die Geschäftslogikschicht bietet fachliche Funktionen an und
stellt somit Dienste zur Verfügung. Diese arbeiten die Teilschritte der Geschäftsvorfälle
ab. Eine Kombination von fachlichen Funktionen ergibt einen Ge-
¢
schäftsvorfall. Die fachlichen Funktionen werden im Rahmen einer bestehenden
Transaktion ausgeführt.
Datenzugriff. Kernaufgabe der Datenzugriffsschicht ist die Kapselung der Datenzugriffe
auf ein konkretes Datenbankmanagementsystem (DBMS). Ziel ist die
¢
Verbergung der verschiedenen Zugriffe auf die DBMS der unterschiedlichen
Hersteller. Dazu wird eine einheitliche Schnittstelle für den Datenzugriff angeboten.
Querschnittsschicht. Die Querschnittsschicht bietet technische Basisdienste an.
Diese reichen von Logging über Druckfunktionen bis hin zum Fehlermanagement.
Oft bietet sie auch eine Schnittstelle für Dienste des Betriebsystems ¢ an.
7
Der Standard gibt eine geschlossene Architektur vor. Allerdings wird in den Projekten aus Gründen
der Performance meist die gelockerte Variante eingesetzt; z. B. dürfen in den meisten Fällen die
Steuerungskomponenten auch auf die Datenstrukturen der Datenzugriffsschicht zugreifen.

14 Das Umfeld in der IZB SOFT
In dieser Schichtenarchitektur werden logische Schichten betrachtet. Eine Aussage,
wie diese Schichten in eine physische Architektur abgebildet werden könnten, wurde
noch nicht getroffen. Im Abschnitt 2.3.1 wurde eine Client/Server-Architektur beschrieben.
Heutzutage wird oft noch ein weiterer Server zwischen dem Terminal und
dem Großrechner verwendet. Es gibt dann verschiedenen Möglichkeiten, die logischen
Schichten auf diese beiden physischen Knoten abzubilden. Alle zu besprechen,
würde den Rahmen dieser Arbeit sprengen. Im Folgenden wird eine Abbildung exemplarisch
gewählt, um die Prinzipien der logischen Schichtentrennung erläutern zu
können.
Trennung in Front- und Backend. Wird eine scharfe Linie zwischen der Präsentationsschicht
und der Geschäftslogikschicht gezogen, wird die Präsentation Frontend
genannt. Die darunter liegenden Schichten werden mit Backend bezeichnet. In der
Regel wird das Frontend auf einem eigenen Application Server laufen und das Backend
auf dem Host. Die Aufgabe des Backends ist es, die Dienste für das Frontend
bereitzustellen. Somit wird eine Multikanalstrategie verfolgt: verschiedene Präsentationen
wie z. B. Web oder 3270 rufen die Geschäftsvorfälle des Backends auf.
Schwerpunkt dieser Arbeit ist die modellbasierte Entwicklung der vom Backend angeboten
Dienste (vgl. Abbildung 2-3). Die Anordnung der Präsentationsschicht ist
dafür nicht relevant, da in beiden Fällen die Geschäftsvorfälle auf dem Großrechner
mit COBOL realisiert werden. Somit liegt eine klassische dienstorientierte Architektur
vor. Die Dienste des Backends sind zustandslos und können innerhalb einer
Transaktion abgearbeitet werden. Diese Art von Diensten ist für ein Frontend mit
Web-Technologie vorteilhaft.
Web Server
OS/390
CICS
Präsentationsschicht
CICS Transaktions
Gateway
Präsentationsschicht
Steuerungsschicht
Geschäftslogikschicht
Datenzugriffsschicht
Querschnittsschicht
Fokus dieser Arbeit
Abbildung 2-3 Fokus dieser Arbeit

COBOL: Begriffe & Konzepte 15
2.4 COBOL: Begriffe & Konzepte
Innerhalb der Schichten werden die Komponenten vorwiegend in COBOL realisiert.
Um bei der Modellierung ein Ziel vor Augen zu haben, ist es wichtig die Grundkonzepte
zu verstehen, die COBOL bietet. Genauso wichtig ist es, die Grenzen von
COBOL zu kennen. Der folgende Abschnitt gibt eine Einführung in die wichtigsten
Konzepte und Begriffe.
Welche Punkte sind für diese Arbeit relevant Ein Schwerpunkt der Modellierung
liegt in der Spezifikation der Schnittstellen. Hierfür wird das Konzept der Module
erklärt sowie die Technik, welche von den Modulen verwendet wird, um andere Module
aufzurufen. Für die Übergabe von Parametern wird das Konzept der Variablen
und der Datenstrukturen benötigt. Außerdem wird die copy-Anweisung, Zeiger und
ein Muster für Modulaufrufe erklärt.
COBOL steht für Common Business Orientated Language. Die Sprache existiert seit
1959 und wurde seit ihrer Schöpfung mehrmals erneuert. Der letzte offizielle Standard
ist COBOL 85, ein Standard der 1985 verabschiedet worden ist und in dem auch
die meisten Programme der IZB SOFT verfasst sind. In den Bereichen der Finanzgeschäfte
konnte sich COBOL eindeutig durchsetzen: 65% aller kritischen Anwendungen
nutzten 1995 COBOL [Brown]; die meisten dieser Anwendungen existieren auch
heute noch – so bleibt COBOL eine Sprache, mit der man sich auch in Zeiten von
Java und C# auseinandersetzen muss.
2.4.1 Programme, Paragraphen und Module
COBOL ist eine imperative und prozedurale Programmiersprache, d. h. Programme
sind Folgen von Anweisungen. Diese Anweisungen ändern Variablen und somit den
Zustand des Programms. Seit den Anfängen der Informatik, als noch hauptsächlich in
Assembler programmiert wurde, wird versucht, Abstraktionen zu finden, mit denen
sich das Programmieren übersichtlicher gestalten lässt. Die Prozedur ist ein solches
Konstrukt. Eine Prozedur umfasst eine logisch zusammengehörige Folge von Anweisungen.
Damit Abstraktionen funktionieren, müssen die ausgesparten Details auch
versteckt und somit abkapselt werden, d. h. das Geheimnisprinzip (information hiding)
muss umgesetzt werden. Für eine Prozedur würde das bedeuten, dass lokale Variablen
außerhalb der Prozedur nicht sichtbar sind – dies ist unter COBOL nicht möglich.
Anweisungen, die einen abgeschlossenen Programmteil darstellen, können zwar
zu einem Paragraphen zusammengefasst werden, aber die Variablen bleiben immer
im ganzen Programm sichtbar.
Beim Zerlegen größerer Programme genügen Prozeduren nicht als Abstraktionsmittel.
Deswegen werden große Programme in Module zerlegt. Jedes Modul hat eine Schnitt-

16 Das Umfeld in der IZB SOFT
stelle über die mit dem Modul kommuniziert wird. Ein Modul kann als Einheit übersetzt
werden (compilation unit)
Ein Modul fasst Prozeduren und die benötigten Datenstrukturen zu einer Einheit zusammen.
Auch hier sollen die Details, d. h. die Implementierung der Prozeduren und
die benötigten Variablen eines Moduls, gekapselt werden. Diese Abstraktion wird von
COBOL unterstützt. Allerdings sind die Möglichkeiten für die Definition der Schnittstellen
unzureichend. Weiter unten wird erklärt, wie ein Modul, das von außen einen
schwarzen Kasten darstellt, über eine Schnittstelle aufzurufen ist.
Ein Modul ist in vier Bereiche unterteilt:
identification division. In diesem Bereich findet der Compiler oder der Entwickler
Informationen über das Programm. Vorgeschrieben ist die program-id,
£
die den Namen des Moduls spezifiziert.
environment division. Dieser Bereich enthält Informationen über das Umfeld,
in dem das Modul ausgeführt wird. Hier wird z. B. spezifiziert, dass der decimal-point
ein Komma £ ist.
data division. In diesem Bereich werden Daten definiert. Er ist weiter unterteilt
in die working-storage section und die linkage section.
£
procedure division. Dieser Bereich enthält Anweisungen, um die Daten in der
data division zu manipulieren. Die procedure division ist hierarchisch gegliedert
in section, paragraph, sentence und £ statement.
2.4.2 Daten
Daten sind für Anwendungen ein wichtiger Bestandteil: Fachliche Informationen aus
dem Gegenstandsbereich der Anwendung werden durch Daten repräsentiert. In diesem
Abschnitt wird beschrieben, wie Daten in COBOL definiert und benutzt werden.
Um Daten innerhalb eines Moduls zu bearbeiten, werden Variablen benutzt. Variablen
besitzen eine Referenz und einen Wert. Die Vereinbarungen werden in der working-storage
section festgelegt. Hier werden die Variablen an einen Namen gebunden.
Der Gültigkeitsbereich (scope) der Vereinbarungen ist das ganze Modul. Somit
kann innerhalb des Moduls auf den Wert der Variable durch den Namen zugegriffen
werden.
Die Variablen besitzen eine Wertesemantik, d. h. die Referenz der Variable bestimmt
eindeutig den Speicherbereich, der den Wert der Variable enthält. Wenn eine Variable
deklariert wird, wird automatisch ein Speicherbereich reserviert, der den Wert der
Variable aufnehmen kann.

COBOL: Begriffe & Konzepte 17
Beim deklarieren einer Variable wird zwischen zwei Arten von Variablen unterschieden.
Es gibt die einfache Variable (elementary item) und die zusammengesetzte Variable
(group item).
Einfache Variable. Bei einer Deklaration einer einfachen Variablen weiß der Compiler
wie groß der Speicherbereich sein muss und kennt die Menge der möglichen
Werte, die dort gespeichert werden können.
Eine Deklaration einer einfachen Variablen besteht aus einer Level Number, einem
Namen, und einer picture-Klausel.
01 DER-NAME PICTURE X(30) VALUE "HEINZ".
Die picture-Klausel definiert den Typ und die Größe der Variablen, also die Menge
ihrer möglichen Werte. Es gibt drei Datentypen: (1) Alphabetic, (2) Alphanumeric
und (3) Numeric.
Eine Variable kann mit der value-Klausel initialisiert werden. Die Länge einer Variablen
kann auf zwei verschiedene Arten spezifiziert werden. Soll z. B. eine numerische
Variable mit genau 4 Stellen definiert werden, wird entweder
oder
01 NUMMER PICTURE 9(4)
01 NUMMER PICTURE 9999
verwendet 8 .
Zusammengesetzte Variable. Mit einer zusammengesetzten Variable (group item)
werden mehrere Variablen zu einer Gruppe zusammengefasst. Eine zusammengesetzte
Variable ergibt eine Datenstruktur oder einfach eine Struktur. Der Wert, den eine
Struktur annehmen kann, ist das kartesische Produkt von den Werten der enthaltenen
Variablen. Die Struktur kann beliebig geschachtelt werden (nested structure), d. h.
eine Struktur kann auch eine Variable enthalten, die wiederum eine Struktur darstellt.
Der entscheidende Unterschied zu anderen Sprachen ist, dass eine Datenstruktur nicht
an eine Typbezeichnung gebunden werden kann. Somit ist es auch nicht möglich,
Variablen an diese Typbezeichnung zu binden. Sollen zwei Variablen mit derselben
Struktur definiert werden, muss für jede Variable die Struktur beschrieben werden. Es
gibt in COBOL einen Mechanismus, um diese doppelte Schreibarbeit zu umgehen.
Dieser Mechanismus wird durch die Vorübersetzer-Anweisung copy realisiert, die
weiter unten erklärt wird.
8
Weiter gibt es die Möglichkeit, Vorzeichen zu definieren, Dezimalpunkte festzulegen oder noch
genauere Angaben zu den Typen zu machen. Eine ausführliche Darstellung, würde den Rahmen dieser
Arbeit sprengen.

18 Das Umfeld in der IZB SOFT
Die Deklaration einer Struktur-Variablen hat eine Level Number und einen Namen –
keine picture-Klausel. Für eine Strukturvariable wird die Größe des zu reservierenden
Speichers aus den einfachen Nachfahren berechnet. Eine Strukturvariable bezeichnet
nur ein Aggregat von tatsächlichen Variablen.
01 RECORD
05 ELEMENTARY-ITEM-A PIC 9(4)
05 ELEMENTARY-ITEM-B PIC X
05 GROUP-ITEM
10 ELEMENTARY-ITEM-C PIC X(20)
10 ELEMENTARY-ITEM-D PIC X(20)
Die Level Number bestimmt die Anordnung des Feldes in der Hierarchie der Datenstruktur.
Wichtig ist, dass diese eine relative Nummer darstellt, d. h. eine Nummer ist
nicht absolut, sondern immer relativ zu der Nummer des ihr über- oder untergeordneten
Feldes zu sehen. Je höher die Nummer ist, desto tiefer liegt die Variable in der
Hierarchie. Auf der tiefsten Ebene sind alle Variablen einfach. Die Top-Level Variable,
also die Variable mit der Level Number »1«, wird Record genannt.
Eine Datenstruktur repräsentiert einen Baum: an ihren Blättern sind die einfachen
Variablen; die inneren Knoten sind die zusammengesetzten Variablen. Innerhalb der
IZB SOFT regelt der Standard »Programmierrichtlinien COBOL« [IZB 2002d] den
Stil der Programme. Für die Variablen ist z. B. vorgegeben, dass die Namen der Variablen
innerhalb eines Moduls eindeutig sind.

COBOL: Begriffe & Konzepte 19
2.4.3 Aufruf eines Moduls
Ein großes Programm wird in der Regel in Module zerlegt. Diese Module können sich
gegenseitig aufrufen. Allerdings darf ein Modul, das Modul von dem es aufgerufen
worden ist, selbst nicht aufrufen. Der Aufruf erfolgt mit der call-Anweisung, die
auch die Parameterübergabe steuert. Im Folgenden wird dieses Konzept anhand eines
Beispiels erklärt. Es wird davon ausgegangen, dass ein Modul A ein Modul B mit den
Argumenten a1, a2 und a3 aufruft.
Modul A:
IDENTIFICATION DIVISION.
PROGRAM-ID. A.
DATA DIVISION.
...
WORKING-STORAGE SECTION.
01 A1 PIC X.
01 A2 PIC X.
01 A3 PIC X.
...
PROCEDURE DIVISION
...
CALL B USING A1 A2 A3.
Modul B:
IDENTIFICATION DIVISION.
PROGRAM-ID. B.
DATA DIVISION.
...
LINKAGE SECTION.
01 P1 PIC X.
01 P2 PIC X.
01 P3 PIC X.
...
PROCEDURE DIVISION USING P1 P2 P3.
Das Modul A deklariert drei Variablen und ruft mit der call-Anweisung das Modul B
auf. Die Argumente werden in der using-Klausel spezifiziert.
Das Modul B spezifiziert die Parameter in der using-Klausel der procedure
division. Parameter, die in der using-Klausel vorkommen, müssen in der
linkage section deklariert sein. Im Gegensatz zu einer Deklaration in der workingstorage
section handelt es sich hier um eine Referenzsemantik: Es wird kein Speicher
reserviert und auf die Variable, die an den Parameter gebunden wird, können
mehrere Referenzen verweisen.
Nach dem Aufruf werden im Modul B die Parameter initialisiert. Dieser Vorgang
wird als Parameterübergabe bezeichnet. Der Mechanismus, der von COBOL für die

20 Das Umfeld in der IZB SOFT
Parameterübergabe angewandt wird, ist standardmäßig ein Referenzaufruf: Der Parameter
wird mit der Referenz des Arguments initialisiert. Der Typ des Arguments
muss äquivalent zum Typ des Parameters sein. Argument und Parameter greifen auf
denselben Speicherbereich zu.
Die Semantik ändert sich je nachdem, was innerhalb des Moduls mit dem Parameter
passiert. Dabei werden drei Fälle unterschieden (vgl. [Goos] S. 27):
Eingabeparameter (in). Wird der Wert des Parameters innerhalb des Moduls
nicht geändert, wird von einem Eingabeparameter gesprochen.
¤
Ausgabeparameter (out). Wird der Parameter innerhalb eines Moduls, unabhängig
von seinem ursprünglichen Wert, mit einem Wert belegt, wird er Ausgabeparameter
¤ genannt.
Übergangsparameter (inout). Ist ein Eingabeparameter zugleich ein Ausgabeparameter,
so heißt er Übergangsparameter.
¤
2.4.4 COPY-Dateien
Das erste, was man als Student in einer Firma mitbekommt, die Anwendungen für
Großrechner entwickelt, ist, dass »Copydateien«, »Copystrecken« oder »Copys« viele
Eigenschaften haben: Sie können »übergeben werden« oder »eine Schnittstelle darstellen«.
Welche Funktionen erfüllt also dieses Zaubermittel, von dem [Budlong]
schreibt:
The COPY statement to the rescue!
Wichtig ist, den Mechanismus, den die copy-Anweisung anbietet, klar von den verschiedenen
Anwendungsmöglichkeiten zu trennen.
Der Mechanismus. Mit der copy-Anweisung wird Quelltext aus einer Datei in eine
Moduldatei eingebunden. Die Anweisung selber wird nicht übersetzt, sondern vor
dem Übersetzen wird der Quelltext aus den Dateien, die in den copy-Anweisungen
spezifiziert sind, an den entsprechende Stellen eingefügt; erst danach wird das Modul
übersetzt.
Der Nutzen. In dem Abschnitt über Daten wurde festgestellt, dass es keine Möglichkeit
gibt, eine Datenstruktur an einen Typbezeichner zu binden und mehrmals zu verwenden.
Stattdessen muss alles mehrfach getippt werden. Mit Hilfe der copy-
Anweisung kann eine Datenstruktur, die von mehreren Modulen genutzt werden soll,
einmal definiert und dann an verschiedenen Variablen »gebunden« werden. Eine
copy-Datei steht also für eine konkrete Datenstruktur, die wiederverwendet werden
soll.

COBOL: Begriffe & Konzepte 21
Für die Variablen innerhalb einer copy-Datei machen die Programmierrichtlinien der
IZB SOFT eine Einschränkung: Der Feldname darf maximal 6 Stellen lang sein.
2.4.5 Zeiger
Als Erweiterung gibt es in COBOL Zeiger; das folgende Listing zeigt die Deklaration
des Zeigers:
IDENTIFICATION DIVISION.
PROGRAM-ID. ZEIGER-BEISPIEL.
...
WORKING-STORAGE SECTION.
01 EINE-STRUKTUR.
...
DATA DIVISION.
...
LINKAGE SECTION.
01 EINGABE-ZEIGER USAGE IS POINTER.
01 STRUKTUR-DEFINITION.
...
PROCEDURE DIVISION USING EINGABE-ZEIGER.
Ausgehend von dem Listing können zwei Szenarien betrachtet werden:
Szenario #1. Dem Modul wird ein Zeiger übergeben, von dem der Entwickler weiß,
dass der Zeiger auf eine Struktur vom Typ struktur-definition zeigt. Um die
Struktur, auf die der Zeiger zeigt, nutzen zu können, muss der Zeiger erst dereferenziert
werden. Dazu wird der Zeiger mit der folgenden Anweisung an die Struktur gebunden:
SET ADDRESS OF STRUKTUR-DEFINITION TO EINGABE-ZEIGER.
In [Rechenberg] ist »Dereferenzieren« wie folgt definiert:
Der Übergang zum Wert einer durch Zeiger gegebenen Variablen heißt Dereferenzieren.
Die Variable struktur-definition wird in der Regel nie als Parameter übergeben.
Sie wird als Datenstrukturdefinition benötigt.
Szenario #2. Dem Modul wird ein Zeiger übergeben, und der Entwickler möchte,
dass dieser auf die Struktur eine-struktur zeigt. Dazu wird dem Zeiger auf folgende
Weise die Adresse von eine-struktur zugewiesen:
SET EINGABE-ZEIGER TO ADDRESS OF EINE-STRUKTUR.

22 Das Umfeld in der IZB SOFT
2.4.6 Muster für den Modulaufruf
Wie bereits festgestellt wurde, sind die Konzepte, die COBOL für die Kapselung auf
verschiedenen Ebenen anbietet, sehr bescheiden. Darum werden Muster verwendet,
mit denen weitere Konstrukte realisiert werden können.
Ein Modul stellt logisch eine Menge von Prozeduren dar. Jede Prozedur hat eine Signatur,
welche die Parameter spezifiziert. Die tatsächliche Schnittstelle eines COBOL-
Moduls bietet jedoch nur einen Satz von Parametern an (vgl. Abschnitt 2.4.3). Das im
Folgenden beschriebene Muster zeigt eine Abhilfe für diese Beschränkung:
Es werden eine Enumeration und ein Zeiger übergeben. Die Enumeration spezifiziert,
welche Operation aufgerufen werden soll; der Zeiger zeigt auf die Datenstruktur, in
welche die Argumente für den Aufruf stehen. Das Modul, welches aufgerufen wird,
evaluiert die Enumeration und legt dann die entsprechende Parameter-Struktur über
das Argument. Danach wird die section ausgeführt, welche die spezifizierte Operation
realisiert.
2.4.7 Komponenten in COBOL
Eine Zerlegung in Module reicht für die in dieser Arbeit vorgestellten Anwendungen
nicht aus: Sie sind zu groß. Es wird demnach ein Konstrukt benötigt, um mehrere
Module zu gruppieren, die einen abgeschlossenen Dienst realisieren.
In der Zusammenfassung der Architektur-Rahmenbedingungen (vgl. Abschnitt 2.3.2)
wurde der Begriff »Komponente« bereits allgemein definiert. Im Folgenden wird dieser
Begriff auf der Basis von COBOL-Konstrukten konkretisiert:
Eine Komponente stellt ein rein logisches Konstrukt dar: Es gibt keinen Mechanismus
in COBOL, der eine Komponente realisiert.
Eine Komponente umfasst eine Menge von Modulen, Datenstrukturen und wiederverwendbaren
Datenstrukturen (Copystrecken). Die gruppierten Module realisieren
einen abgeschlossenen Dienst. Komponenten sind, wenn sie von außen betrachtet
werden, schwarze Kästen.
Nur über die definierten Schnittstellen kann mit einer Komponente kommuniziert
werden. Eine Schnittstelle enthält Definitionen von Datenstrukturen und Signaturen
von Operationen. Neben den Schnittstellen exportiert eine Komponente nur die wiederverwendbaren
Datenstrukturen, welche in den Signaturen der Operationen vorkommen.
Damit wird die Implementierung der Komponente, also die Module, welche
die Operationen der Schnittstelle realisieren, vollständig gekapselt. Dazu muss der
Entwickler sicherstellen, dass nur Module aufgerufen werden, für die logisch auch
eine Schnittstelle definiert worden ist.

3 Modellbasierte Softwareentwicklung
Diese Arbeit untersucht einerseits systematische Vorgehensweisen, um Software modellbasiert
zu entwickeln, und betrachtet andererseits COBOL, eine Programmiersprache,
die speziell bei IT-Systemen von Finanzdienstleistern oft eingesetzt wird.
Auf den ersten Blick passen diese beiden Techniken nicht zusammen. Modellbasierte
Softwareentwicklung ist eine junge Vorgehensweise und muss erst noch beweisen, ob
sie die erhoffte Verbesserung der Entwicklung auch in der Praxis leisten kann 9 . Die
Legacy-Programmiersprache COBOL, die es schon seit 1959 gibt, ist gleichzeitig eine
der meistverwendeten und meistkritisierten Programmiersprachen. Sie wird zwar den
höheren Programmiersprachen zugeordnet, bietet aber kaum Mechanismen, mit denen
man größerer Anwendungen effektiv zerlegen kann.
Das ist jedoch der Grund, warum die beiden Techniken sich gut vereinbaren lassen:
Wenn die verwendete Programmiersprache wenige Konzepte für die Modularisierung
und Kapselung bietet, ermöglichen modellbasierte Softwareentwicklungsverfahren,
auf logischer Ebene die Software zu zerlegen und deren Implementierungsdetails zu
verstecken. 10
3.1 Grundlagen der modellbasierten Entwicklung
Unter modellbasierter Entwicklung wird der Einsatz von systematischen Vorgehensweisen
verstanden, die auf Modelle basieren. Ziel ist es, große Mengen an anfallenden
Informationen sowie deren Komplexität in den Griff zu bekommen. Allerdings gibt es
für solche Verfahren noch keine allgemeingültige Definition [Schätz].
Modelle eignen sich ideal für die Aussparung von unnötigen Details und werden
schon seit langem zum Entwickeln von Software eingesetzt. Viele der in der Entwicklung
eingesetzten Konzepte basieren auf Abstraktion und die Modellierung ist ein
geeignetes Mittel, um die Abstraktion zu visualisieren [Booch].
In einer modellbasierten Methodik sind aber Modelle viel mehr als reine Visualisierungsmittel
von Software: Sie steuern die Entwicklung und sind die zentrale Stelle für
9
In diesem Bereich wird zurzeit viel geforscht. Einen Standard gibt es bereits: die Model Driven
Architecture (MDA) der OMG. Internetseite: www.omg.org/mda.
10 Dies könnte auch ein Grund dafür sein, warum im Bereich Embedded Systems vermehrt versucht
wird, modellbasierte Methoden einzusetzen. Vgl. dazu [Schätz].
23

24 Modellbasierte Softwareentwicklung
die Informationserfassung des jeweiligen Arbeitsablaufes. Diese erweiterte Rolle beschreibt
[Nobe] auf folgende Weise:
Wenn wir einen Entwicklungsprozess auf Modellen aufbauen, werden diese
zu den zentralen koordinierenden Elementen des Prozesses.
Eine solche Rolle kann sowohl ein einziges Modell, als auch eine Menge von unabhängigen
Modellen, nicht erfüllen. Deswegen beruht eine modellbasierte Methodik
immer auf einem Modellsystem.
Die wichtigsten Konzepte eines Modellsystems sind im Folgenden beschrieben, sowie
in Abbildung 3-1 anhand eines Beispiels dargestellt. 11
Modell. Ein Modellsystem ist in Modellebenen untergliedert. Jede Modellebene
wird durch genau ein Modell repräsentiert, dessen Abstraktionsgrad von der Höhe der
Ebene abhängt. Wichtig ist, dass zwischen den Modellen Zusammenhänge bestehen.
Ein Modell hat die Aufgabe, das System aus seinem Blickwinkel vollständig zu beschreiben
(self-contained view). Das heißt, der Betrachter benötigt keine weiteren
Modelle, um diese Ebene des Systems zu verstehen [Jacobson1999].
Zusammengenommen enthalten alle Modelle die gesamte Information, die für die
Entwicklung notwendig ist. Es ist jedoch nicht zwingend, dass alle Informationen
einer Ebene als Modell dargestellt werden. Verschiedene Repräsentationen von Informationen,
wie z. B. Textdateien, können in die Modelle eingebunden werden. Um
die Modelle zu repräsentieren, wird eine graphische Modellierungssprache gewählt.
Bei der IZB SOFT wird die UML eingesetzt.
Metamodelle. Ein Modell beschreibt eine Ebene des Systems. Dabei werden Modellierungskonzepte
der Modellierungssprache angewendet, um die entsprechenden
Aspekte des Systems zu modellieren. Diese Modellierungskonzepte zu beschreiben
und deren Verwendung einzuschränken, ist Gegenstand der Metamodelle. Die Elemente
eines Metamodells M Meta beschreiben und spezifizieren die Konzepte, die in
dem Modell M eingesetzt werden. Jedes Modell wird durch ein Metamodell spezifiziert.
Sichten. Für jedes Modell kann eine Menge von Sichten definiert werden. Eine
Sicht ist ein Ausschnitt, also eine Teilmenge der Modellelemente. Alle Sichten zusammen
enthalten alle Elemente des Modells. Die Sichten werden in Rational Rose 12
durch Diagramme repräsentiert. Wie viele Diagramme benutzt werden und welche
Elemente aus der Sicht dargestellt werden, ist schwer vorzugeben, da es stark von der
Situation abhängt: Ein Paket mit 100 Klassen wird anders dargestellt als ein Paket mit
3 Klassen. Deswegen ist die Wahl der Diagramme nicht zu restriktiv vorzugeben.
11 Vgl. »Architektur von Informationssystemen« von E. J. Sinz in [Rechenberg].
12 Rational Rose ist ein UML-basiertes Entwicklungswerkzeug. Es wird in der IZB SOFT eingesetzt.

Grundlagen der modellbasierten Entwicklung 25
Zusammenhänge zwischen den Modellen. Entscheidend für die Bewältigung der
Komplexität ist die Beschreibung der Zusammenhänge zwischen den Modellen. Dadurch
lassen sich redundante Informationen automatisch ableiten und konsistent halten.
Die Beziehungen dokumentieren auch die Rückverfolgbarkeit (traceability). Die
Zusammenhänge der Modelle werden spezifiziert, in dem die Elemente der jeweiligen
Metamodelle in Beziehung gestellt werden.
Modellebenen
Fachliche Sicht
Sichten
Komponentensicht
Diagramme
(Ergeben zusammen eine
Instanz der Sicht)
Fachliches Metamodell
Fachliches
Modell
Abbildung
Fachliches
Modell auf
Designmodell
Designmetamodell
Metamodelle
Instanzen der
Elemente des
Metamodells
Zusammenhänge
zwischen den
Metamodellen
Modulsicht
Designmodell
Abbildung 3-1 Beispiel für ein Modellsystem
Auf der Basis des Modellsystems wird ein systematisches Vorgehen für die Übergänge
zwischen den Modellen definiert. Dieses systematische Vorgehen schafft eine
Grundlage für die Generierung: Aus Modellen können Dokumente, Programme oder
weitere Modelle generiert werden. Je nachdem was generiert werden soll, ändert sich
die Genauigkeit der Modelle. So kann es sein, dass Modelle durch formale Spezifikationen,
wie z. B. OCL 13 angereichert werden. Es ist nicht möglich, aus einem Modell
gleichzeitig ein rein fachliches Konzept und ein Quelltext für eine spezifische
COBOL-Umgebung zu erzeugen.
Ein Modell mit einem hohen Abstraktionsgrad kann z. B. die Fachlichkeit eines Systems
vermitteln. Mit einem solchen Modell wäre es möglich, über ein System zu diskutieren
– ohne die technischen Details zu kennen. Außerdem wäre es möglich, aus
einem solchen Modell ein Fachkonzept zu generieren.
13 Mit der Object Constraint Language (OCL) können Beschränkungen der Modellelemente formuliert
werden.

26 Modellbasierte Softwareentwicklung
Ein Modell mit einem niedrigen Abstraktionsgrad kann z. B. einen vollständigen
Bauplan einer Implementierung darstellen. Solch ein Modell würde es erlauben, Programmrahmen
zu generieren.
Vor folgender falschen Annahme sei gewarnt:
Falsche Annahme. Aus einem einzigen Modell kann alles generiert werden. Ein
Modell abstrahiert von Details. Bei der Generierung können nur Rahmen erzeugt
werden. Die Details für die generierten Artefakte muss der Entwickler selbst hinzufügen.
So kann z. B. aus einem fachlichen Modell ein technisches Modell nicht komplett
generiert werden. Der automatische Übergang zwischen einem rein fachlichen
Modell in ein technisches Modell kann nur folgendes leisten: Bereits definierte Rahmen
für das technische Design können erzeugt werden. Die fachlichen Elemente können
in die technischen Konzepte abgebildet werden. Alle rein technischen Aspekte
müssen von den Entwicklern entworfen werden.
Bei einem modellbasierten Vorgehen ist der Einsatz von Werkzeugen entscheidend.
Sie unterstützen die Entwicklung an verschiedenen Stellen: Zum einen können sie die
Übergänge zwischen den Modellebenen automatisieren, und zum anderen bei Änderungen
in den tieferen Ebenen die höheren Ebenen nachziehen. Die Modelle der verschiedenen
Ebenen per Hand konsistent zu halten, ist mit sehr viel Aufwand verbunden.
Deswegen beschleunigen Werkzeuge die Entwicklung.

Das bisherige Vorgehen der IZB SOFT 27
3.2 Das bisherige Vorgehen der IZB SOFT
In diesem Abschnitt werden die internen Standards der IZB SOFT vorgestellt. Die
Beschreibung der in den Standards definierten Modellen und Vorgehensweisen, stellt
die Grundlage für die in dieser Arbeit entwickelte Methodik dar.
Einige Aspekte der modellbasierten Methodik, welche bereits in der Praxis eingesetzt
werden, hat die IZB SOFT bereits in ihren Entwicklungsprozess integriert. Die notwendigen
Tätigkeiten, um die Modelle zu erstellen und zu pflegen, sind in Arbeitsabläufen
14 (workflows) zusammengefasst. Alle Arbeitsabläufe (ausgenommen der Ablauf
Umsetzen) sind in einem entsprechenden internen Standard beschrieben. Die
Standards erläutern u. a. die für die Arbeitsabläufe benötigten Modelle. Diese Modelle
erfassen die wichtigsten Konzepte, Spezifikationen, Entscheidungen und Dokumentationen
eines Arbeitsablaufes.
Anforderungsanalyse
Analyse
Fachliche
Modellierung
Disziplin
Entwurf
Implementierung
Arbeitsablauf
Technische
Modellierung
Umsetzung
Abbildung 3-2 Einbettung der Arbeitsabläufe: Innerhalb der Iteration werden
die Arbeitsabläufe, bei denen die Modelle erstellt werden, eingesetzt.
In Abbildung 3-2 werden die Arbeitsabläufe den Disziplinen zugeordnet. Die Abläufe
beschäftigen sich nicht ausschließlich mit der Modellierung. Deshalb werden in den
folgenden Abschnitten, die nach Arbeitsabläufen gegliedert sind, nur die für die Modellierung
relevanten Inhalte der Standards zusammengefasst. Die Beschreibung der
14 Diese Arbeit lehnt sich bei den Begriffen an den RUP [Jacobson1999] an. Innerhalb der IZB SOFT
werden andere Begriffe verwendet. So heißen z. B. Arbeitsabläufe bei der IZB SOFT Prozessschritte.

28 Modellbasierte Softwareentwicklung
Arbeitsabläufe soll die Motivation der einzelnen Modelle erläutern sowie die Modelle
voneinander abgrenzen.
3.2.1 Anforderungsanalyse
Gegenstand der Anforderungsanalyse ist die Untersuchung des Problembereichs und
das Ermitteln von Anforderungen. Unter einer Anforderung wird eine Funktionalität,
die das System zu erbringen hat, oder eine Eigenschaft, die von dem System verlangt
wird, verstanden. Anforderungen werden in funktionale und nicht-funktionale Anforderungen
aufgeteilt. Eine funktionale Anforderung spezifiziert, wie der Name schon
sagt, eine Funktionalität, die das System anbieten soll. Diese Funktionalität kann z. B.
ein fachlicher Dienst für den Gegenstandsbereich sein. Nicht-funktionale Anforderungen
beschreiben Merkmale, die von dem System gefordert werden, wie z. B. Performance,
Qualität, Bedienbarkeit, etc. Die Anforderungsanalyse betrachtet also das
System vor dem Hintergrund des Gegenstandsbereichs von außen und definiert
»Was« das System zu leisten hat.
Die bestimmten funktionalen Anforderungen werden in Form von Modellen dokumentiert;
die nicht-funktionalen Anforderungen werden entweder als Beschränkungen
in die Modelle integriert oder als Text hinzugefügt. Die Dokumentation ist sehr wichtig,
da sie die Grundlage für die weitere Modellierung darstellt. Die Anforderungsanalyse
ist als Arbeitsablauf in den SBP eingegliedert. Der Standard »Anforderungsanalyse«
[IZB 2002a] beschäftigt sich u. a. mit der Modellierung. Die relevanten Teile
werden in den folgenden Abschnitten zusammengefasst.
Anwendungsfallmodell. Ein Anwendungsfallmodell enthält Akteure, die mit Anwendungsfällen
in Beziehung stehen. Ein Akteur liegt außerhalb des Systems und
repräsentiert alles, was mit dem System interagiert. Das kann ein Mensch oder ein
anderes System sein. Der Akteur verlangt funktionale Anforderungen, die das System
zu leisten hat. Diese werden mit Anwendungsfällen dokumentiert. Nach [IZB 2002a]
beschreibt ein Anwendungsfall »eine Abfolge von Aufgaben, in der die Interaktion
des Akteurs mit dem System beschrieben wird, sowie die Aktivitäten, die im System
erfolgen«.
Nachdem ein Akteur einen Anwendungsfall initiiert, durchläuft der Anwendungsfall
Aktivitäten – nicht notwendigerweise Interaktionen mit dem Akteur – bis er mit einem
Ergebnis endet. Dieses Ergebnis muss dem Akteur in irgendeiner Weise Nutzen
bringen. Somit ist die Funktionalität, die das System zu erbringen hat, vollständig
über Anwendungsfälle dokumentiert. 15
15 Es gibt einige Punkte auf die beim Erstellen von Anwendungsfällen geachtet werden sollte;
[Cockburn] behandelt ausführlich das effektive Schreiben von Anwendungsfällen.

Das bisherige Vorgehen der IZB SOFT 29
Mit Paketen werden die Anwendungsfälle gruppiert. Diese Strukturierung hat keinen
Einfluss auf die spätere Systemstruktur. Zum Beispiel könnte man die Anforderungen
in »must-have«, »should-have« oder »can-do« strukturieren.
Anwendungsfall-Feinbeschreibung. Eine Feinbeschreibung ist eine genaue Beschreibung
des Ablaufes aus der Sicht der Akteure und muss zu jedem Anwendungsfall
erstellt werden. Hierbei ist wichtig, alles im Aktiv zu formulieren und keine Details
der Oberfläche oder Implementierung zu erläutern.
Problembereichsmodell. Die Konzepte des Problembereichs werden durch Klassen
dargestellt und ergeben ein konzeptionelles Modell. Die Klassen enthalten Attribute,
die keinen Typ erfordern, und haben keine Operationen. Beziehungen zwischen
den Konzepten werden dargestellt. Dabei ist zu beachten, dass bei Assoziationen die
Kardinalitäten anzugeben sind. In der neuen Methodik ist dieses Modell in dem Anwendungsfallmodell
enthalten.
Oberflächen-Prototyp.Der Prototyp hat die Aufgabe, die Anforderungen zu verdeutlichen,
damit man sich vom System ein Bild machen kann. Die Gestaltung kann
und wird sich noch ändern. Das Prinzip des Rapid Prototyping wird verfolgt.
Der Standard beschreibt die Verwendung von Prototypen, schließt aber die Nutzung
anderer Möglichkeiten, sich ein Bild von dem System zu machen, nicht aus. Es muss
nicht immer ein programmierter Prototyp sein. Oft werden einfach nur Storyboards
gezeichnet, welche die graphische Oberfläche und den Ablauf grob darstellen.
3.2.2 Fachliche Modellierung
Die fachliche Modellierung ist ein Arbeitsablauf, der im Entwicklungsprozess ausgeführt
wird. Gleichzeitig ist es der erste Arbeitsablauf des Systementwurfs. Ausgehend
von der Anforderungsanalyse werden der generelle Aufbau sowie die grundlegende
Struktur des Systems nach fachlichen Kriterien entworfen. Der hier zusammengefasste
Standard »Fachliche Modellierung« [IZB 2002c] gibt eine Richtlinie für die
Modellierung vor.
Das fachliche Modell. Das fachliche Modell bietet eine Sicht auf das System, die
von technischen Details abstrahiert. Das heißt, alle Entscheidungen, die einen technischen
Hintergrund haben oder sich auf die Implementierungsumgebung beziehen,
werden offen gelassen. Es zeigt die wesentlichen Abläufe, die sich aus den funktionalen
Anforderungen ergeben und testet dabei, ob sie schlüssig und ohne Widersprüche
sind.
Da sich technische Details noch häufiger ändern als funktionale Anforderungen und
diese Änderungen sich nicht im fachlichen Modell auswirken, ist es sinnvoll ein rein
fachliches Modell, das technischen Details ausspart, zu entwerfen. Darüber hinaus
lassen sich Änderungen der funktionalen Anforderungen leichter in ein fachliches

30 Modellbasierte Softwareentwicklung
Modell integrieren, da auf keine technischen Beschränkungen Rücksicht genommen
werden muss.
Das Modell betrachtet sowohl die statische Struktur, wie z. B. die Anordnung der E-
lemente und deren Beziehungen, als auch die dynamischen Interaktionen, welche die
Anwendungsfälle aus der Analyse realisieren.
Fachliche Klassen repräsentieren die Elemente des Systems auf einer fachlichen Ebene.
Sie haben Attribute und Operationen, welche die Verantwortlichkeiten der Klasse
repräsentieren. Außerdem stehen die fachlichen Klassen untereinander in Beziehung
und erzeugen somit eine fachliche Struktur. Die fachlichen Klassen werden in drei
Klassen unterteilt:
¥
¥
¥
Steuerungsklassen (control). Klassen, die den Ablauf steuern.
Dialogklassen (boundary). Klassen, die mit Akteuren interagieren.
Entitäten (entity). Klassen, welche die Schlüsselkonzepte aus dem Anwendungsbereich
repräsentieren.
Die Modellierung der Abläufe in separaten Steuerungsklassen verfolgt das Ziel, Abläufe,
die sich häufiger ändern als die robusteren Entitäten, von diesen zu trennen.
Fachliche Klassen werden mit fachlichen Paketen hierarchisch angeordnet. Diese dürfen
weitere fachliche Pakete enthalten. Daraus ergibt sich eine rekursive Struktur mit
der auch größere Systeme organisiert werden können. Die Pakete werden nach fachlichen
Gesichtspunkten geschnitten. Dabei wird darauf geachtet, dass ein Paket sich in
seiner Funktion von den anderen Paketen abgrenzt. Abhängigkeiten zwischen den
Paketen, die sich aus den Beziehungen der fachlichen Klassen ergeben, werden gezeigt.
Die Umsetzung der Anwendungsfälle in einem fachlichen Modell wird mit Sequenzdiagrammen
beschrieben. Diese dokumentieren die Anwendungsfall-Realisierungen.
Der Standard lässt es frei, weitere Diagramme zu nutzen.
Der Leitfaden »Modellierung« konkretisiert die Vorgaben des Standards für das Umfeld
von PROFiL. Die Bedeutung der verschiedenen fachlichen Klassen wird verfeinert.
Insbesondere wird der Vorschlag gemacht, die Steuerungsklassen weiter zu unterteilen.
Außerdem ist eine Namenskonvention für die Operationen darin enthalten.
3.2.3 Technische Modellierung
Die technische Modellierung verfeinert das fachliche Modell. Vor dem Hintergrund
einer konkreten Entwicklungsumgebung wird der fachliche Entwurf mit technischen
Details gefüllt. Hauptaufgabe ist es, bei der Verfeinerung die bereits besprochenen
Architekturvorgaben umzusetzen. Der Arbeitsablauf technische Modellierung umfasst,
wie auch die Abläufe zuvor, mehr als nur den Vorgang der Modellierung. Die

Das bisherige Vorgehen der IZB SOFT 31
Ergebnisse des Ablaufes, nämlich die Modelle, werden durch den Standard: »Technische
Modellierung« 16 [IZB 2003c] festgelegt. Auch hier ist es das Ziel, die Modelle
mit einer standardisierten Notation zu vereinheitlichen. 17
Designmodell.Gegenstand des Designmodells ist es, die Verteilung der Funktionalität
auf die Designkomponenten aufzuzeigen. Die fachliche Aufgliederung aus dem
fachlichen Modell wird hier in einer konkreten, technischen Umgebung modelliert.
Außerdem sollen die Schnittstellen der Komponenten spezifiziert und die Abhängigkeiten
der Komponenten gezeigt werden. Viele Elemente des Designmodells sind
architekturrelevant. Deswegen sind auch die Konzepte »Schicht«, »Komponente« und
»Schnittstelle« aus dem Standard »Architektur Rahmenbedingungen« [IZB 2002b]
übernommen (vgl. Abschnitt 2.3.2).
Eine Designkomponente ist ein Baustein, der wiederverwendet werden soll. Über eine
oder mehrere Schnittstellen stellt eine Komponente ihre Dienste bereit. Eine Komponente
kann ihre Dienste auf den Diensten einer anderen Komponente aufbauen und ist
dann abhängig von der Schnittstelle der genutzten Komponente. Jede Komponente ist
einer Schicht zugeordnet und kann aus weiteren Komponenten bestehen. Die Ausarbeitung
der Komponenten und die Spezifikation der Elemente, welche notwendig
sind, um die, in der Schnittstelle vereinbarten Leistungen, umzusetzen, werden mit
modelliert. 18
Ein Designpaket ist ein Gruppierungselement, dessen Elemente nicht mit Schnittstellen
gekapselt werden.
3.2.4 Umsetzung
Bei der Umsetzung werden die Elemente des Designmodells in COBOL-Quelltext
transformiert. Bei der Erstellung von COBOL-Modulen sollte unbedingt beachtet
werden, dass diese entsprechend den Programmierrichtlinien [IZB 2002d] implementiert
werden. Denn diese verbieten die Verwendung einiger COBOL-Konstrukte und
weisen auf »schlechten Stil« hin. Für die meisten Projekte gibt es Rahmenprogramme,
die verwendet werden müssen. Dazu kommen Muster, die in den Projekten üblich
16 Der Standard beschreibt neben dem Designmodell auch das Implementierungs- und Laufzeitmodell.
Letztere sind dem Arbeitsablauf Umsetzung zuzuordnen.
17 Allerdings kommt an dieser Stelle ein neuer Aspekt hinzu: Die Modelle sollen mit einem Werkzeug
erfasst und ausgewertet werden. Dieses Werkzeug nennt sich Bauplan. Allerdings ist Vorsicht geboten:
Keine werkzeugbedingten Einschränkungen dürfen auferlegt werden, bevor die Art und Weise
der Modellierung erprobt wurde, und sich das Vorgehen gefestigt hat.
18 In der neuen Methodik werden die Komponenten mit einer Innenansicht ergänzt. Es wird also die
Realisierung der Schnittstellen innerhalb der Komponente mit Modulen, Datenstrukturen und Copystrecken
modelliert

32 Modellbasierte Softwareentwicklung
sind, um bestimmte Aufgaben zu lösen. Allgemein geht es um die Realisierung der in
den Modellen spezifizierten Funktionalität.
Implementierungsmodell. Das Implementierungsmodell dokumentiert, welche
Dateien für die Realisierung der Designkomponenten notwendig sind. Allgemeine
Möglichkeiten für den Inhalt der Dateien sind: Quelltext, Binärcode, Tabellen, etc. In
dieser Arbeit wird zwischen zwei Arten von Dateien unterschieden:
¦ Die Moduldatei (bisher: Modul) repräsentiert eine COBOL-Quelltext-Datei.
Die Copystreckedatei (bisher: Copystrecke) repräsentiert eine Quelltext-Datei
einer Datenstruktur-Deklaration. Mit einer Datenstruktur können Parameter und
¦
Argumente für den Modulaufruf definiert werden (vgl. Abschnitt 2.4.4).
Die Module werden von einem Übersetzer in Objekt-Dateien transformiert. Diese
werden dann automatisch gelinkt. Aus diesem Grund hat jedes Modul automatisch
eine gleichnamige Laufzeitkomponente. Eine Laufzeitkomponente repräsentiert eine
ausführbare Datei.
Um die Verwaltung zu erleichtern, werden die Dateien in einer Implementierungskomponente
zusammengefasst. Eine Implementierungskomponente repräsentiert ein
Verzeichnis mit Dateien. Auch wenn eine Designkomponente wieder aus Designkomponenten
bestehen kann, werden die daraus abgeleiteten Implementierungskomponenten
im Dateisystem nicht in geschachtelten Verzeichnissen abgelegt.
Laufzeitmodell. Ein Klassendiagramm im Laufzeitmodell zeigt die Verteilung der
Elemente des Implementierungsmodells auf Hardware-Knoten. Auf die Modellierung
wird in dieser Arbeit nicht eingegangen, da die Standardisierung im Moment noch
vorläufig ist.

Die Modelle der neuen Methodik im Überblick 33
3.3 Die Modelle der neuen Methodik im Überblick
Ziel dieser Arbeit ist es, eine durchgängige Methodik für die Entwicklung von
COBOL-Anwendungen zu erstellen. Diese Methodik ist nicht »auf der grünen Wiese«
entstanden, sondern baut auf einer bereits eingesetzten Vorgehensweise auf. Im vorangegangenen
Abschnitt wurden die Standards zusammengefasst, welche die bisherige
Vorgehensweise definieren. Da diese Standards unternehmensweit gültig sind,
werden sie in der Regel allgemein gehalten. Die vorliegende Arbeit beschränkt sich
jedoch auf die Entwicklung von COBOL-Diensten auf dem Backend. Deshalb wird
die bisherige Vorgehensweise in den folgenden Kapiteln an einigen Stellen konkretisiert
und erweitert. Um den Einstieg in das Fallbeispiel zu erleichtern, wird an dieser
Stelle ein Überblick über die Struktur der Modelle gegeben.
Die neue Methodik nennt sich modellbasierte Entwicklung von COBOL-
Anwendungen (moCa) und basiert im Wesentlichen auf einem Modellsystem, einer
Notation und einer systematischen Vorgehensweise.
Das Modellsystem besteht aus folgenden vier Modellen: (1) Anwendungsfallmodell,
(2) Fachliches Modell, (3) Designmodell und (4) Implementierungsmodell.
Die Struktur der Modelle wird in Abbildung 3-3 anhand einer, mit Anmerkungen ergänzten,
Browser-Sicht von Rational Rose 19 verdeutlicht.
Use Case View
«modell» Anwendungsfallmodell
Logical View
«modell» Fachliches Modell
«modell» Designmodell
1. Methodischer Übergang
2. Methodischer Übergang
«modell» Implementierungsmodell
Abbildung 3-3 Browser-Sicht auf die Modelle
Auf jedes Modell sind verschiedene Sichten 20
Tabelle 3-1 zusammengefasst.
definiert. Diese Sichten sind in
19
Rational Rose setzt die Verwendung zweier Sichten (Use Case View und Logical View) auf das
System voraus. Ein beliebiges Systemgesamtmodell enthält demnach vier Modelle in zwei Sichten
unterteilt.

34 Modellbasierte Softwareentwicklung
Tabelle 3-1 Die Modell-Sichten im Überblick
Modell Sicht Beschreibung
Anwendungsfallmodell Anwendungsfallsicht Zeigt die Anwendungsfälle.
Problembereichssicht
Zeigt die Konzepte der Domäne.
Fachliches Modell Statische Sicht Zeigt die Struktur der fachlichen Klassen.
Designmodell
Dynamische Sicht
Statische Komponentensicht
Dynamische Komponentensicht
Statische Modulsicht
Dynamische Modulsicht
Zeigt das Zusammenspiel der fachlichen
Klassen.
Zeigt die Struktur der Komponenten
und die Komponenten von »außen«.
Zeigt das Zusammenspiel der Komponenten.
Zeigt die Komponenten von »innen«.
Zeigt das Zusammenspiel der Module.
Implementierungsmodell Dateisicht Zeigt die Dateien auf der Festplatte.
Quelltextsicht
Zeigt den Inhalt der Dateien, also den
Quelltext.
Für die graphische Notation, also die graphische Repräsentation der Elemente, wird
die Unified Modeling Language (UML) verwendet. Mit ihren Erweiterungsmechanismen
können die Konzepte der verschiedenen Modelle definiert und mit der UML-
Notation dargestellt werden.
Die systematische Vorgehensweise umfasst die beiden methodischen Übergänge, welche
auch in Abbildung 3-3 dargestellt sind. Der erste methodische Übergang ist die
Ableitung des Designmodells aus dem fachlichen Modell, also der Übergang von
einem fachlichen Entwurf in einen technischen Entwurf. Der zweite methodische Ü-
bergang besteht aus der Umsetzung des Designmodells in ein Implementierungsmodell.
Darin ist auch die Umsetzung des Designmodells in COBOL-Quelltext enthalten.
20 Vgl. Abschnitt 3.1.

4 Das Fallbeispiel »Kundenmappe«
In diesem Kapitel wird die neue Methodik modellbasierte Entwicklung von COBOL-
Anwendungen (moCa) anhand eines Beispiels vorgestellt. Ziel ist es, die Durchgängigkeit
der neuen Methodik zu zeigen. Für das Beispiel ist ein Ausschnitt aus dem
Projekt »Kundenmappe« gewählt worden. Das Projekt »Kundenmappe« ist ein Teilprojekt
von PROFil (vgl. Abschnitt 2.1).
Für ein durchgängiges Beispiel ist es wichtig, dass der Problembereich einfach zu
verstehen ist. Deshalb sind die Konzepte der Domäne vereinfacht worden. Trotzdem
bleibt die Problemstellung anspruchsvoll genug, um die wichtigsten Konzepte der
Methodik am Beispiel und somit praxisnah vermitteln zu können.
Damit man die Stellen, an denen von der bisherigen Vorgehensweise abgewichen
wird, schnell erkennt, sind sie mit einem Warndreieck in der Marginale gekennzeichnet
(vgl. Abbildung 4-1).
Abbildung 4-1 Das Warndreieck zur Kennzeichnung der Änderungen
4.1 Systemvision
Im Folgenden wird die geforderte Funktionalität der vereinfachten Anwendung, die
als Fallbeispiel dient, grob umrissen. Ihre Hauptaufgabe ist es, den Berater bei den
Kundengesprächen zu unterstützen, indem sie alle Informationen über den Kunden an
einer Stelle sammelt und damit eine zentrale Sicht auf die Kundendaten bereitstellt.
Die Anwendung benötigt Funktionen, um die Daten der Geschäftspartner des Finanzinstituts
zu bearbeiten, d. h. sie muss u. a. über eine Lese-Schnittstelle für Kundendaten
verfügen. Mit den gelesenen Daten kann die Anwendung die zentrale Sicht zusammenstellen.
Abbildung 4-2 zeigt, wie eine mögliche Gestaltung für die Masken der Anwendung
ausschauen könnte. Dem Berater wird die Maske Kunde finden angezeigt. Im Eingabefeld
gibt er die Nummer des 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.
35

36 Das Fallbeispiel »Kundenmappe«
Der in der Übersicht angezeigte Kunde ist bereits in die Auswahl 21 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 Anzeigen zu der Maske Kundenmappe. Diese Maske
zeigt die Summen des Vermögens aller selektierten Kunden der Auswahl an.
Kunde finden
(1) Kundendaten (2)
Kundennummer
eingeben:
374
Anrede:
Vorname:
Nachname:
Herr
Peter
Meier
Auswahl
Auswahl
(3) Kundenmappe (4)
Herr Peter Meier
Entfernen
Datum: 3.8.2003
Peter Meier
Summe Vermögen:
300,- Euro
Hinzufügen
Anzeigen
Auswahl
Abbildung 4-2 Eine mögliche Gestaltung der Masken
21 Das Konzept, zuerst eine Auswahl zu erstellen, und dann die Kundenmappe angezeigt zu bekommen,
erscheint etwas ungewöhnlich. Dieses Vorgehen wurde aber vom Auftraggeber des PROFil-
Projekts »Kundenmappe« so gewünscht. Deswegen wurde dieses Konzept auch für das Fallbeispiel
übernommen.

Anwendungsfallmodell 37
4.2 Anwendungsfallmodell
Die Systemvision bietet ein erstes Verständnis über die zu erwartenden Leistungen
der Systeme. In diesem Abschnitt soll nun die geforderte Funktionalität mit Anwendungsfällen
genauer beschrieben werden. Abbildung 4-3 zeigt den Fokus dieses Abschnitts.
Use Case View
«modell» Anwendungsfallmodell
Logical View
«modell» Fachliches Modell
«modell» Designmodell
Abbildung 4-3 Das Modell der Analyse
4.2.1 Anwendungsfallsicht
«modell» Implementierungsmodell
Dieser Abschnitt beschreibt die Anwendungsfallsicht auf das Anwendungsfallmodell.
Zuerst wird aber eine Erweiterung erläutert: Da zwischen Backend und Frontend getrennt
wird (vgl. Abschnitt 2.3.2), ist es wichtig, die Trennung auch bei der Beschreibung
von Anwendungsfällen fortzusetzen. Demnach gibt es zwei Bereiche: Der erste
Bereich beschreibt aus der Außenansicht des Anwenders die Anforderung an das
Frontend. Der zweite Bereich beschreibt die Anforderung des Frontends an das Backend.
Dadurch wird die Steuerung der weiteren Modellierung durch die Anwendungsfälle
ermöglicht.
Der Ausschnitt des Projekts »Kundenmappe« ist in zwei Systeme zerlegt: (1) das System
Kundenmappe und (2) das System Partner. Die Kundenmappe benötigt die
Dienste des Systems Partner. Somit werden auch Abhängigkeiten zwischen Systemen
behandelt.
Überblick über die Anwendungsfälle. Abbildung 4-4 zeigt ein Anwendungsfalldiagramm,
in dem die Anwendungsfälle der Systeme Kundenmappe und Partner
modelliert sind. Die Pakete mit dem Stereotypen «frontend» und «backend» zeigen
die Unterteilung der Anwendungsfälle. Ein Anwendungsfall für das Backend stellt
einen Geschäftsvorfall dar (vgl. Abschnitt 2.3.2).

38 Das Fallbeispiel »Kundenmappe«
Berater
«anwendungsfallsystem»
Kundenmappe
«frontend»
«anwendungsfallsystem»
Partner
«frontend»
«include»
Kundenmappe
anzeigen
BeteiligteParteien
auswählen
Kunde finden
«backend»
«backend»
Kundenmappe
erstellen
BeteiligtePartei
finden
Adresssatz
finden
Abbildung 4-4 Die Anwendungsfälle im Überblick
Beschreibung der Anwendungsfälle. Im Folgenden werden alle Anwendungsfälle
der Abbildung 4-4 in textueller Form beschrieben. Unter Bereich wird gekennzeichnet,
ob es sich um einen Anwendungsfall des Front- oder des Backends handelt;
unter Akteur wird der Initiator des Anwendungsfalls bestimmt; die Eingabe spezifiziert
die Daten, die vom Anwendungsfall benötigt werden; die Ausgabe beschreibt
welche Daten als Ergebnisse nach Beendigung des Anwendungsfalls vorhanden sind.
Ein unterstrichener Name eines Anwendungsfalls (z. B. Adresssatz finden) bedeutet,
dass der unterstrichene Anwendungsfall an dieser Stelle ausgeführt wird.

Anwendungsfallmodell 39
Anwendungsfall 4-1 Kunde finden
Der Berater möchte über das Terminal die Daten eines Kunden anzeigen lassen.
Akteur: Berater.
Bereich: Partner Frontend.
Eingabe: Eine Adresssatznummer.
Ausgabe: Die Daten des durch die Adresssatznummer spezifizierten Kunden.
Standardablauf:
1. Der Berater gibt die Adresssatznummer eines Kunden ein.
2. Wenn über Adresssatz finden Daten gefunden wurden, bekommt der Berater eine
Übersicht über die Kundendaten angezeigt.
3. Ansonsten erscheint eine Fehlermeldung.
Ausnahme: Wenn Kunde finden innerhalb eines Ausfluges ausgeführt wird, wird keine
Übersicht angezeigt.
Anwendungsfall 4-2
BeteiligtePartei auswählen
Es gilt eine Menge von beteiligten Parteien zusammenzufassen. Diese Menge wird
»Auswahl« genannt. Innerhalb der Auswahl kann eine beteiligte Partei entweder selektiert
oder deselektiert sein.
Akteur: Berater.
Bereich: Kundenmappe Frontend.
Eingabe: Eine Auswahl von beteiligten Parteien.
Ausgabe: Eine Auswahl von beteiligten Parteien.
Standardablauf:
1. Der Berater bekommt eine Liste von beteiligten Parteien angezeigt. Diese Liste wird
mit Auswahl bezeichnet.
2. Der Berater kann jetzt beliebig oft einen neuen Kunden hinzufügen:
a) Mit Kunde finden wird ein Adresssatz gefunden;
b) Mit Beteiligte Partei finden wird eine beteiligte Partei gefunden;
c) Die beteiligte Partei wird der Auswahl hinzugefügt.
3. Der Berater kann einen Kunden aus der Auswahl entfernen.
4. Der Berater kann beliebig oft den Status einer beteiligten Partei in selektiert oder
deselektiert ändern.
Anwendungsfall 4-3 Kundenmappe anzeigen
Aus der Auswahl wird die Kundenmappe erstellt und die Informationen dem Berater angezeigt.
Akteur: Berater.
Bereich: Kundenmappe Frontend.
Eingabe: Eine Auswahl von beteiligten Parteien.
Ausgabe: Die für die spezifizierte Auswahl erstellte Kundenmappe.
Standardablauf:
1. Der Berater fordert das System auf, für seine Auswahl an beteiligten Parteien die
Kundenmappe anzuzeigen.
2. Über Kundenmappe erstellen wird die Kundenmappe erstellt.
3. Die Kundenmappe wird dem Berater angezeigt.

40 Das Fallbeispiel »Kundenmappe«
Anwendungsfall 4-4 Übergreifendes Anwendungsszenario
Standardablauf:
1. Der Berater findet eine Kunden über Kunde finden.
2. Der Berater bekommt über Beteiligte Partei auswählen die Auswahl angezeigt und
kann jetzt neue Kunden zur Auswahl hinzufügen und den Status der beteiligten Parteien
in der Auswahl ändern.
4. Der Berater lässt sich mit Kundenmappe anzeigen die Informationen anzeigen.
Anwendungsfall 4-5 Adresssatz finden
Das Frontend benötigt Daten eines Kunden.
Akteur: Frontend.
Bereich: Partner Backend.
Eingabe: Eine Adresssatznummer.
Ausgabe: Ein Exemplar der Entität Adresssatz. Dies ist der Adresssatz für die spezifizierte
Adresssatznummer.
Standardablauf:
1. Das Frontend übergibt die Adressnummer eines Kunden.
2. Wenn ein Adresssatz existiert, wird der Adresssatz zurückgeliefert.
3. Ansonsten wird ein Fehlercode zurückgeliefert.
Anwendungsfall 4-6 BeteiligtePartei finden
Neue Anwendungen kennen nur beteiligte Parteien. Deswegen muss die zu einem Adresssatz
gehörige beteiligte Partei gefunden werden oder gegebenenfalls neu angelegt
werden.
Akteur: Frontend.
Bereich: Partner Backend.
Eingabe: Ein Exemplar der Entität Adresssatz.
Ausgabe: Das Exemplar der Entität BeteiligtePartei, welches dem spezifizierten Adresssatz
zugeordnet ist.
Standardablauf:
1. Das Frontend übergibt einen Adresssatz eines Kunden.
2. Das Backend prüft, ob eine BeteiligtePartei für den Adresssatz existiert.
3. Wenn nicht, wird eine neue BeteiligtePartei angelegt.
4. Die BeteiligtePartei wird auf Konsistenz geprüft.
5. Das Backend gibt die BeteiligtePartei zurück.

Anwendungsfallmodell 41
Anwendungsfall 4-7 Kundenmappe erstellen
Anhand einer Auswahl wird eine Kundenmappe erstellt.
Akteur: Frontend.
Bereich: Kundenmappe Backend.
Eingabe: Ein Exemplar der Entität Auswahl.
Ausgabe: Ein Exemplar der Entität Kundenmappe. Dieses Objekt wird aus der Auswahl
erzeugt.
Standardablauf:
1. Das Frontend übergibt eine Auswahl von beteiligten Parteien. Innerhalb der Auswahl
sind die beteiligten Parteien entweder selektiert oder deselektiert.
2. Das Backend erstellt die Kundenmappe mit der berechneten Summe des Vermögens
der beteiligten Parteien.
3. Das Backend gibt die Kundenmappe zurück.
4.2.2 Modellierung der Beschreibung
Mithilfe eines Sequenzdiagramms kann der Ablauf eines Anwendungsfalls modelliert
werden. Abbildung 4-5 und Abbildung 4-6 zeigen exemplarisch die Sequenzdiagramme
für den Anwendungsfall Adresssatz finden und BeteiligtePartei finden.
Die Sequenzdiagramme modellieren die Beschreibung. Dabei wird aus jedem Schritt
der Beschreibung (ein Schritt ist durch eine Nummer gekennzeichnet) eine Nachricht,
die durch einen Pfeil dargestellt wird. Eine Nachricht an das Backend wird mit einem
durchgezogenen Pfeil modelliert; die Antwort des Backends wird mit einem gestrichelten
Pfeil dargestellt. Die Argumente einer Nachricht werden innerhalb von runden
Klammern spezifiziert.
: Frontend partner : Backend
Finde Adresssatz über Adresssatznummer (adresssatznummer)
[Adresssatz gefunden] Adresssatz
[Sonst] Fehlercode
Abbildung 4-5 Das Sequenzdiagramm Adresssatz finden

42 Das Fallbeispiel »Kundenmappe«
: Frontend partner : Backend
Finde BeteiligtePartei über Adresssatz (adresssatz)
Prüfe ob eine BeteiligtePartei für den Adresssatz existiert (adresssatz)
[BeteiligtePartei existiert nicht] Erzeuge eine neue BeteiligtePartei (adresssatz)
Überprüfe die Konsistenz der BeteiligtenPartei (beteiligtePartei)
[Konsistent] Beteiligte Partei
[Sonst] Fehlercode
Abbildung 4-6 Das Sequenzdiagramm BeteiligtePartei finden
4.2.3 Problembereichsicht
Die Problembereichssicht ist eine konzeptionelle Sicht auf die Entitäten der Domäne.
Die Konzepte des Problembereichs werden durch Klassen dargestellt, welche Attribute,
aber keine Operationen enthalten. In Abbildung 4-7 sind die im Folgenden beschriebenen
Konzepte modelliert.
Kundendaten sind in Adresssätzen abgespeichert. Für einen Kunden können mehrere
Adresssätze existieren. Solche Kunden sind in unserem Beispiel nicht zulässig: Es
werden nur Kunden mit einem einzigen Adresssatz betrachtet.
Adresssätze können in Kundeneinheiten (KU-Verknüpfung) zusammengefasst werden.
Dieses Konzept würde die Komplexität des Fallbeispiels unnötig vergrößern, deswegen
wird es im Fallbeispiel ausgespart.

Anwendungsfallmodell 43
Die Daten aus den Adresssätzen, die zu einem Kunden gehören, werden in einer BeteiligtenPartei
zusammengefasst. Das SKO-Datenmodell 22 definiert eine beteiligte
Partei folgendermaßen:
Eine beteiligte Partei ist eine natürliche Person, eine Organisation, eine Organisationseinheit
oder eine Gemeinschaft, über die das Finanzinstitut Informationen
führen möchte, um mit ihr optimal kooperieren zu können.
Eine beteiligte Partei wird aus den Adresssätzen erzeugt. Die Zuordnung zwischen
einer beteiligten Partei und den dazugehörigen Adresssätzen kann sehr kompliziert
werden. Deswegen darf in unserem Beispiel die beteiligte Partei nur in Form einer
natürlichen Person auftreten, bei der die Zuordnung zwischen einer beteiligten Partei
und dem Adresssatz 1:1 ist.
Ergänzend zu den aus den Adresssätzen gesammelten Daten können weitere Informationen
über den Kunden, wie z. B. seine Hobbys, in der beteiligten Partei gespeichert
werden.
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 dient zur Präsentation von Kundendaten. Sie 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 des Vermögens 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 Wert,
der ihren Vermögensstand repräsentiert.
Kundenmappe
Auswahl
WähltAus
BeteiligtePartei
Adresssatz
+ datum 0..* 1
0..* 0..* + vermögenswert 0..1 0..1 + adresssatznummer
/+ summe des
+ anrede
Vermögens
+ vorname
+ nachname
NatürlichePerson
Abbildung 4-7 Die Entitäten der Problembereichsicht
22 SKO steht für Sparkassen-Organisation. Das Datenmodell definiert, welche Daten von einer Sparkasse
erfasst werden. Es ist innerhalb der IZB SOFT als CD erhältlich.

44 Das Fallbeispiel »Kundenmappe«
4.3 Fachliches Modell
Die Anwendungsfälle für das Backend spezifizieren die Anforderungen an die Anwendung.
Das System wird dabei von außen betrachtet und es wird festgelegt, welche
Funktionen von der Anwendung geleistet werden muss. Nun wird die Perspektive
gewechselt und die Anwendung von innen angeschaut. Zunächst ist nur die Fachlichkeit
von Interesse. Technische Gesichtspunkte werden außen vorgelassen. Das fachliche
Modell beschreibt sowohl die statische Struktur, als auch die dynamischen Abläufe
beider Systeme aus fachlicher Sicht. Abbildung 4-8 zeigt den Fokus dieses Abschnitts.
Use Case View
«modell» Anwendungsfallmodell
Logical View
«modell» Fachliches Modell
«modell» Designmodell
«modell» Implementierungsmodell
Abbildung 4-8 Das Modell des fachlichen Entwurfs
4.3.1 Statische Sicht: Die Hierarchie der fachlichen Klassen
Die statische Sicht zeigt, wie die geforderte Funktionalität auf eine Struktur abgebildet
werden kann. Dargestellt wird diese in einem oder mehreren Klassendiagrammen.
Die Elemente der Struktur sind fachliche Klassen und fachliche Pakete. Die fachlichen
Pakete gruppieren die fachlichen Klassen und können wiederum fachliche Pakete
enthalten. Dadurch wird eine hierarchische Struktur geschaffen. Ein Paket auf der
höchsten Ebene der Hierarchie wird mit dem Stereotyp «fachlichesSystem» 23 versehen,
da es die Grenze eines Systems darstellt.
Überblick über das fachliche Modell. Die Zerlegung der Anwendung in zwei Systeme,
wie bereits im Anwendungsfallmodell gezeigt wurde (vgl. Abbildung 4-4), wird
im fachlichen Modell übernommen. Abbildung 4-9 zeigt die vollständige Hierarchie
der Anwendung. Beide Systeme Kundenmappe und Partner werden jeweils durch ein
23 Für die Erweiterungsmechanismen der UML vgl. Kapitel 5.

Fachliches Modell 45
fachliches Paket dargestellt. Da sie die höchsten Elemente in der Hierarchie sind (top
level), haben sie das Stereotyp «fachlichesSystem».
Für die Durchgängigkeit zu den technischen Modellen ist es wichtig, elementare Pakete
bestimmen zu können. Deshalb gilt folgende Einschränkung: Wenn innerhalb
eines fachlichen Pakets eine fachliche Klasse liegt, darf kein weiteres Paket im Paket
enthalten sein.
«fachlichesSystem»
Kundemappe
«fachlichesSystem»
Partner
«fachlichesPaket»
BeteiligtePartei
«fachlichesPaket»
Adresssatz
KundenmappeErsteller
BeteiligteParteiVerwalter
AdresssatzFinder
Erstellt
Findet, erzeugt und löscht
Findet
WähltAus
0..*
1 0..*
0..*
0..1 0..1
Kundenmappe
Auswahl
BeteiligtePartei
Adresssatz
NatürlichePerson
Abbildung 4-9 Das fachliche Modell im Überblick
Das System Partner hat die Aufgabe, Kundendaten bereitzustellen. Um beide Konzepte,
Adresssatz und BeteiligtePartei, zu trennen, ist das System in zwei fachlichen
Pakete untergliedert. Beide Pakete stellen einen Dienst bereit und sind in ihrer Funktion
klar abgegrenzt. Fachliche Pakete werden im Modell durch ein Paket mit dem
Stereotyp «fachlichesPaket» repräsentiert.

46 Das Fallbeispiel »Kundenmappe«
Das System Kundenmappe hat die Aufgabe, eine zentrale Sicht auf alle Daten einer
Menge von beteiligten Parteien zu erstellen. Es gruppiert die fachlichen Klassen, die
diesen Dienst realisieren.
Aus den Entitäten des Problembereichs (vgl. Abbildung 4-7) werden Entitäten im
fachlichen Modell. Entitäten im fachlichen Modell haben, im Gegensatz zu den Entitäten
im Problembereichsmodell, Operationen. Auch die Organisation der fachlichen
Klassen in fachliche Pakete wird erst im fachlichen Modell getroffen.
Die fachlichen Klassen in Beziehung zu setzen, ist eine wichtige Aufgabe, weil dadurch
eine fachliche Struktur entsteht. Um die Wahl der Beziehungen zu erleichtern,
werden die Empfehlungen aus dem Standard eingeschränkt: Abhängigkeiten bestehen
nur zwischen den fachlichen Paketen. Die Beziehungen zwischen fachlichen Klassen
sind beschränkt auf Assoziationen. Nur zwischen Entitäten dürfen die Assoziationen
zu Aggregation verfeinert werden, und nur zwischen Entitäten darf eine Generalisierungsbeziehung
vorkommen.
Beziehungen zu den Anwendungsfällen. Um einen Anwendungsfall zu realisieren,
wird in der Regel eine Steuerklasse («control») benötigt, die den Dienst anbietet
und den Ablauf steuert. Das Zusammenspiel mehrerer Klassen, das durch eine Steuerklasse
koordiniert wird, realisiert einen Anwendungsfall. Abbildung 4-10 zeigt welches
Paket einen Anwendungsfall realisiert. Das heißt ein Paket, welches die Steuerungsklasse
enthält, die den Anwendungsfall abwickelt, realisiert diesen Anwendungsfall
24 .
Das fachliche Paket Adresssatz enthält die Steuerungsklasse AdresssatzFinder, die
den Geschäftsvorfall Adresssatz finden realisiert. Die Steuerungsklasse BeteiligteParteiVerwalter,
die im Paket BeteiligtePartei enthalten ist, realisieren den Anwendungsfall
Beteilige Partei finden. Der Anwendungsfall Kundenmappe erstellen wird durch
das Paket Kundenmappe realisiert, da dieses Paket die Steuerungsklasse KundenmappeErsteller
umfasst. Die Beziehung von einem Paket zum Anwendungsfall wird
durch eine Abhängigkeit mit dem Stereotyp «realisiert» modelliert.
Detailansicht der fachlichen Klassen. Eine fachliche Klasse kann Auskunft über
die Werte ihrer Attribute liefern und diese ändern. Operationen für den Zugriff müssen
dafür nicht zusätzlich modelliert werden. Attribute beginnen immer mit einem
kleinen Buchstaben 25 . Zur Laufzeit hat eine Steuerklasse Verbindungen zu Instanzen
von fachlichen Klassen (Parameter, Entitäten). Diese werden durch Assoziationen
modelliert. In den folgenden Absätzen werden die Modellierungsdetails der fachlichen
Klassen des Fallbeispiels beschrieben.
24 Vgl. Abschnitt 4.3.2.
25 Eine Zusammenstellung der fachlichen Typen sowie die Beschreibung der Syntax der Operationen
sind im Abschnitt 5.2.1 enthalten.

Fachliches Modell 47
Kundenmappe erstellen BeteiligtePartei finden Adresssatz finden
Anwendungsfallmodell
Fachliches Modell
«realisiert» «realisiert» «realisiert»
«fachlichesSystem»
Kundenmappe
«fachlichesPaket»
BeteiligtePartei
«fachlichesPaket»
Adresssatz
Abbildung 4-10 Die Beziehungen zu den Anwendungsfällen
Eine Steuerklasse im Fallbeispiel ist AdresssatzFinder. Sie trägt die Verantwortung,
zu einer Adresssatznummer einen Adresssatz zu finden. Abbildung 4-11 zeigt, wie
diese Verantwortung mit der Operation findeAdresssatz modelliert wird. Zu beachten
ist, dass sowohl der Typ der Parameter, als auch der Typ der Rückgabe spezifiziert ist.
Mit einer Assoziation zwischen AdresssatzFinder und Adresssatz wird modelliert,
dass die Steuerungsklasse zur Laufzeit eine Beziehung zu einer Instanz des Rückgabetyps
Adresssatz hat. Die Assoziation ist gerichtet, ein Ende ist also navigierbar.
Dies bedeutet, dass die Steuerklasse die fachliche Klasse findet und als Ergebnis ü-
bergibt – die fachliche Klasse weiß jedoch nichts über die Steuerklasse.
«control»
AdresssatzFinder
+ findeAdresssatz(adresssatzNummer : PositiveGanzzahl) : Adresssatz
Abbildung 4-11 Die Steuerungsklasse Adresssatz Finder
Der Adresssatz wird repräsentiert durch die Entität Adresssatz, deren Attribute in
Abbildung 4-12 dargestellt sind. Ein Adresssatz kann über Anrede, Vornamen und
Namen eines Kunden Auskunft geben. Er weiß auch, von welchem Typ sie sind. Diese
Verantwortung wird mit Attributen modelliert.
«primaryKey»
«entity»
Adresssatz
+ adresssatzNummer : PositiveGanzzahl
+ anrede : Zeichenkette
+ vorname : Zeichenkette
+ name : Zeichenkette
Abbildung 4-12 Die Entität Adresssatz

48 Das Fallbeispiel »Kundenmappe«
Die Attribute haben immer einen konzeptionellen Typ – dieser ermöglicht Abbildung
der Attribute in ein technisches Modell, indem man den konzeptionellen Typ in einer
konkreten technischen Umgebung verfeinert.
Ein Attribut kann mit Stereotypen genauer definiert werden. Zum Beispiel, bedeutet
das Stereotyp «primaryKey», dass es sich beim Attribut um einen eindeutigen Schlüssel
handelt, d. h. es ist ausgeschlossen, dass zwei Adresssätze dieselben Nummern
haben können. Kann auf ein Attribut nur lesend zugegriffen werden, ist es mit dem
Stereotyp «readonly» zu kennzeichnen.
Der BeteiligteParteiVerwalter hat als öffentlichen Dienst, die Aufgabe zu einem Adresssatz
eine beteiligte Partei zu finden. Dazu muss er 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. Wenn eine beteiligte Partei
nicht konsistent ist, hat der Verwalter die Verantwortung diese zu löschen. Eine beteiligte
Partei ist genau dann nicht konsistent, wenn der zugeordnete Adresssatz nicht
existiert. Alle Verantwortungen, die keine öffentlichen Dienste darstellen, werden
durch private Operationen spezifiziert (vgl. Abbildung 4-13). Während der Laufzeit
steht eine Instanz von BeteiligteParteiVerwalter in Beziehung zu einer Instanz von
der Klasse Adresssatz (als Parameter) und zu einer Instanz der Klasse BeteiligtePartei.
Diese Beziehungen werden durch Assoziationen modelliert.
«control»
BeteiligteParteiVerwalter
+ findeBeteiligtePartei(adresssatz : Adresssatz) : BeteiligtePartei
- prüfeExistenz(adresssatz : Adresssatz) : Ja/Nein-Wert
- erzeugeBeteiligtePartei(adresssatz : Adresssatz) : BeteiligtePartei
- löscheBeteiligtePartei(beteiligtePartei : BeteiligtePartei)
Abbildung 4-13 Die Steuerungsklasse BeteiligteParteiVerwalter
Abbildung 4-14 betrachtet die fachliche Entität BeteiligtePartei im Detail. Das Attribut
beteiligteParteiNummer stellt den eindeutigen Schlüssel für diese Klasse dar. Eine
beteiligte Partei enthält einen Beschreibungstext, der einen beliebigen Inhalt haben
kann. Das Attribut vermögenswert stellt das gesamte Vermögen einer beteiligten Partei
dar – eine für das Fallbeispiel gewählte Vereinfachung. Neben Attributen enthält
diese Entität auch eine Operation. Eine beteiligte Partei hat die Verantwortung ihre
Konsistenz sicherzustellen. Die Operation prüfeKonsistenz() modelliert diese Eigenschaft.
Als Rückgabetyp ist ein Ja/Nein-Wert spezifiziert. Die Zuordnung der beteiligten
Partei zu einem Adresssatz ist durch eine Assoziation modelliert.
Die Klasse BeteiligtePartei ist abstrakt, also nicht instanzierbar. Für das Fallbeispiel
gibt es nur eine Ausprägung, nämlich die NatürlichePerson. Diese Entität erweitert
die beteiligte Partei um die Attribute anrede, vorname und name. Die Werte der Att-

Fachliches Modell 49
ribute ergeben sich aus den entsprechenden Attributwerten des zugeordneten Adresssatzes.
«primaryKey»
«entity»
BeteiligtePartei
+ beteiligteParteiNummer : PositiveGanzzahl
+ beschreibungstext : Zeichenkette
+ vermögenswert : Geldbetrag
+ prüfeKonsistenz() : Ja/Nein-Wert
Abbildung 4-14 Die Entität BeteiligtePartei
Ein Attribut, dessen Wert aus anderen Elementen abgeleitet wird, heißt abgeleitetes
Attribut (derived attribute). Ein solches Attribut wird mit dem Symbol »/« gekennzeichnet.
Die Vorschrift, nach der das Attribut zu berechnen ist, wird mit einer Zusicherung
spezifiziert. Ein abgeleitetes Attribut ist sonst wie ein normales Attribut zu
behandeln, z. B. hat es auch einen Typ.
«entity»
NatürlichePerson
/+ anrede : Zeichenkette
/+ vorname : Zeichenkette
/+ name : Zeichenkette
{anrede, vorname, name = Werte aus dem
zugeordneten Adresssatz}
Abbildung 4-15 Die Entität NatürlichePerson
Die Steuerungsklasse KundenmappeErsteller aus dem Paket Kundenmappe ist für die
Erstellung der Kundenmappe für eine Auswahl von beteiligten Parteien verantwortlich
(vgl. Abbildung 4-16). Zur Laufzeit steht sie in Beziehung zu einer Instanz der
Auswahl (Parameter) sowie einer Instanz der erstellten Kundenmappe. Diese Beziehungen
werden mit Assoziationen spezifiziert.
«control»
KundenmappeErsteller
+ erstelleKundenmappe(auswahl : Auswahl) : Kundenmappe
Abbildung 4-16 Die Steuerungsklasse KundenmappeErsteller
Die Entität Kundenmappe kennt das Datum, an dem sie erstellt worden ist, und kann
die Summe aller Vermögenswerte, der von ihr aggregierten beteiligten Parteien, angeben.
Dafür wird ein abgeleitetes Attribut verwendet. Die Berechnungsvorschrift ist
der Notiz zu entnehmen (vgl. Abbildung 4-17). Die Kundenmappe besteht aus genau
einer Auswahl. Diese Teil/Ganzes-Beziehung wird mit einer Aggregation modelliert.

50 Das Fallbeispiel »Kundenmappe«
«entity»
Kundenmappe
+ datum : Datum
/ + summeVermögenswerte : Geldbetrag
{summeVermögenswerte
= Summe aller Vermögenswerte
der enthaltenen BeteiligtenParteien}
Abbildung 4-17 Die Entität Kundenmappe
Die Entität Auswahl besteht aus einer Anzahl von beteiligten Parteien. Deswegen besteht
zwischen ihr und der Entität BeteiligtePartei eine Aggregation. Die Auswahl hat
Kenntnis darüber, ob eine beteiligte Partei der Auswahl selektiert ist. Diese Kenntnis
wird durch die Operation istSelektiert spezifiziert (vgl. Abbildung 4-18). Bei der Berechnung
der Summe der Vermögenswerte werden nur die beteiligten Parteien berücksichtigt,
die auch selektiert sind.
«entity»
Auswahl
+ istSelektiert(beteiligtePartei: BeteiligtePartei) : Ja/Nein-Wert
Abbildung 4-18 Die Entität Auswahl
4.3.2 Dynamische Sicht: Realisierung der Anwendungsfälle
Die dynamische Sicht soll aufzeigen, wie die Anwendungsfälle von den fachlichen
Klassen realisiert werden. In Sequenz- oder Kollaborationsdiagrammen wird das
Durchspielen der Anwendungsfälle modelliert. Mehrere Diagramme werden zu einer
Anwendungsfall-Realisierung zusammengefasst; das ist ein Paket mit dem Stereotyp
«use-case realization» 26 .
Der Name der Realisierung sollte derselbe sein wie der des Anwendungsfalls. Dieser
wird durch eine Bezeichnung »– Fachlich« ergänzt, um zu kennzeichnen, dass die
Realisierung im fachlichen Modell stattfindet. Abbildung 4-19 zeigt, dass die Anwendungsfall-Realisierung
BeteiligtePartei finden – Fachlich den Anwendungsfall BeteiligtePartei
finden realisiert. Wie in Abbildung 4-10 gezeigt wurde, wird der Anwendungsfall
BeteiligtePartei finden auch vom fachlichen Paket BeteiligtePartei realisiert.
In diesem Fall muss folgenden Konsistenzbedingung beachtet werden: Die erste
Nachricht in den Diagrammen der Anwendungsfall-Realisierung BeteiligtePartei
finden – Fachlich muss an eine fachliche Steuerklasse geschickt werden, die im
fachlichen Paket BeteiligtePartei enthalten ist.
26 Dieses Stereotyp ist in der UML enthalten. Deswegen ist es Englisch und enthält Lehrzeichen.

Fachliches Modell 51
Anwendungsfallmodell
Fachliches Modell
Anwendungsfall-Realisierung
«realisiert»
BeteiligtePartei finden
BeteiligtePartei finden – Fachlich
Abbildung 4-19 Realisierung eines Anwendungsfalls
Exemplarisch wird für den Anwendungsfall Beteiligte Partei finden die fachliche
Realisierung als Sequenzdiagramm (vgl. Abbildung 4-20) und als Kollaborationsdiagramm
(vgl. Abbildung 4-21) vorgestellt.
: Frontend
: BeteiligteParteiVerwalter
findeBeteiligtePartei(adresssatz : Adresssatz)
existiert := prüfeExistenz(adresssatz : Adresssatz)
[existiert nicht] erzeugeBeteiligtePartei(adresssatz : Adresssatz)
[exisitiert] leseBeteiligtePartei()
beteiligtePartei :
BeteiligtePartei
konsistent = prüfeKonsistenz( )
[konsistent] beteiligtePartei
[sonst] Fehlercode
Abbildung 4-20 Das Sequenzdiagramm BeteiligtePartei finden – Fachlich

52 Das Fallbeispiel »Kundenmappe«
Der im Folgenden beschriebene Ablauf, gilt für beide Diagrammarten. Das Frontend
erzeugt ein Exemplar der Steuerungsklasse BeteiligteParteiVerwalter, welche den
Anwendungsfall koordiniert. Dann schickt das Frontend die Nachricht findeBeteiligtePartei
an den Verwalter. Als Argument liegt der Nachricht ein Adresssatz bei. Der
Verwalter prüft, ob eine beteiligte Partei, die dem Adresssatz zugeordnet ist, bereits
existiert; wenn ja, wird sie gelesen; wenn nicht, wird eine neue beteiligte Partei erzeugt.
Anschließend prüft der Verwalter die Konsistenz der beteiligten Partei und
übergibt sie dem Frontend, wenn sie konsistent ist.
Beim Kollaborationsdiagramm repräsentieren die durchgezogenen Linien eine Verbindung
(link) zwischen zwei Objekten; über die Verbindungen können Nachrichten
verschickt werden. Der zeitliche Ablauf ist durch die Nummerierung spezifiziert.
Welches Diagramm verwendet wird, hängt davon ab, ob die Struktur (Kollaborationsdiagramm)
oder der zeitliche Ablauf (Sequenzdiagramm) in den Vordergrund gestellt
werden soll.
2: existiert := prüfeExistenz(adresssatz : Adresssatz)
1: findeBeteiligtePartei(adresssatz : Adresssatz)
P
: Adresssatz
: Frontend
6: beteiligtePartei
: BeteiligteParteiVerwalter
3: [existiert] lese BeteiligtePartei
4: [existiert nicht] erzeuge neue BeteiligtePartei
5: prüfeKonsistenz( )
beteiligtePartei : BeteiligtePartei
Abbildung 4-21 Das Kollaborationsdiagramm BeteiligtePartei finden – Fachlich

Designmodell 53
4.4 Designmodell
Im Designmodell wird ausgehend von der fachlichen Struktur ein technischer Entwurf
erstellt. Dazu wird die Funktionalität aus dem fachlichen Modell auf Komponenten
einer Schichtenarchitektur verteilt. Die Komponenten und ihre Schnittstellen werden
speziell für eine COBOL/HOST-Umgebung modelliert. Somit wird ein Bauplan für
die Implementierung – die Umsetzung des Designs in COBOL-Quelltext – geschaffen.
Abbildung 4-22 zeigt den Fokus dieses Abschnitts.
Use Case View
«modell» Anwendungsfallmodell
Logical View
«modell» Fachliches Modell
1. Methodischer Übergang
«modell» Designmodell
«modell» Implementierungsmodell
Abbildung 4-22 Das Modell des technischen Entwurfs
Bei der bisherigen Vorgehensweise wurde ein Teil des Entwurfs im Implementierungsmodell
spezifiziert. Der Standard für die technische Modellierung [IZB 2003c]
beschreibt dies auf folgende Weise:
Langfristig gesehen ist es Ziel, hauptsächlich auf der Designebene zu modellieren.
Im HOST/COBOL-Umfeld wird gegenwärtig jedoch mehr auf der
Implementierungsebene grafisch dargestellt.
Das langfristige Ziel wurde aufgegriffen und umgesetzt. Ein Ansatz für die vollständige
Modellierung der Spezifikationen auf der Designebene für HOST/COBOL-
Anwendungen wird in den folgenden Abschnitten vorgestellt.
4.4.1 Statische Komponentensicht
Die statische Komponentensicht zeigt die Anordnung der Komponenten innerhalb der
Schichtenarchitektur und die Schnittstellen der Komponenten. Außerdem werden die
Abhängigkeiten zwischen den Komponenten und zwischen Komponenten und
Schnittstellen modelliert.

54 Das Fallbeispiel »Kundenmappe«
Übersicht über die Komponenten. In diesem Abschnitt wird eine Übersicht über
die verwendeten Komponenten gegeben sowie die Spezifikation einiger Schnittstellen
genauer betrachtet. Insbesondere wird besprochen, wie die Funktionalität und die
Struktur des fachlichen Modells mit der Struktur des Designmodells zusammenhängen.
Abbildung 4-23 zeigt eine Übersicht über die Komponenten des Designmodells.
Beide Systeme sind durch zwei Pakete mit dem Stereotyp «designsystem» repräsentiert.
Ein System des Designmodells ist in Schichten unterteilt. Dabei handelt es sich
um die Umsetzung der im Abschnitt 2.3.2 beschriebene Schichtenarchitektur.
«designsystem»
Kundenmappe
«designsystem»
Partner
KundenmappeErstellerSteuerung BeteiligteParteiVerwalterSteuerung AdresssatzFinderSteuerung
«designkomponente»
«designkomponente»
KundenmappeSteuerung
BeteiligteParteiSteuerung
AdresssatzSteuerung
Steuerungsschicht
KundenmappeErsteller
KundenmappeGeschäftslogik
BeteiligteParteiVerwalter
«designkomponente»
BeteiligteParteiGeschäftslogik
AdresssatzFinder
«designkomponente»
AdresssatzGeschäftslogik
Geschäftslogikschicht
BeteiligteParteiBearbeiter
AdresssatzBearbeiter
«designkomponente»
BeteiligteParteiDatenzugriff
«designkomponente»
AdresssatzDatenzugriff
Datenzugriffsschicht
Abbildung 4-23 Die Komponenten im Überblick
Im Modell wird eine Schicht durch ein Paket mit dem Stereotyp «schicht» repräsentiert
– in den Diagrammen aber können die Pakete weggelassen werden und stattdessen
gestrichelte Linien für die Trennung zwischen den Schichten eingesetzt werden.
Die tatsächliche Paketstruktur ist in Abbildung 4-24 anhand der Browser-Sicht von
Rational Rose verdeutlicht. Die einzelnen Schichten enthalten die Komponenten, wobei
eine Komponente nur in einer Schicht enthalten sein darf. Die Komponenten werden
durch Pakete mit dem Stereotyp «designkomponente» repräsentiert.

Designmodell 55
«designsystem» Partner
«schicht» Steuerungsschicht
«designkomponente» BeteiligteParteiSteuerung
«designkomponente» AdresssatzSteuerung
«interface» AdressatzFinderSteuerung
«schicht» Geschäftslogikschicht
«schicht» Datenzugriffsschicht
Abbildung 4-24 Eine Browser-Sicht auf das Designsystems Partner
Im Folgenden wird wieder Abbildung 4-23 betrachtet. Nachdem die Komponenten
die enthaltenen Schnittstellen exportieren, werden diese im Diagramm außerhalb der
Komponenten mit der Lollipop-Notation dargestellt. Im Fallbeispiel hat jede Komponenten
genau eine Schnittstelle. Diese Eigenschaft ist allerdings nicht zwingend, da
eine Komponente mehrere Schnittstellen haben kann. Die gestrichelten Pfeile zwischen
den Paketen repräsentieren Abhängigkeiten. Eine Abhängigkeit zu einer
Schnittstelle bedeutet, dass eine Komponente eine Operation der Schnittstelle aufruft;
eine Abhängigkeit zwischen zwei Paketen zeigt, dass die Quell-Komponente öffentliche
Elemente (das sind Schnittstellen und Datenstrukturen) der Ziel-Komponente
nutzt.
Die Struktur des Systems im Designmodell ist im Gegensatz zum fachlichen Modell
technisch motiviert. Aus diesem Grund wird die Anordnung der fachlichen Pakete
verworfen und nur die elementaren Pakete in das Designmodell abgebildet. Zum Beispiel,
aus dem elementaren fachlichen Paket BeteiligtePartei (vgl. Abbildung 4-9)
wurden die drei Komponenten BeteiligteParteiSteuerung, BeteiligteParteiGeschäftslogik
und BeteiligteParteiDatenzugriff; aus dem zusammengesetzten fachlichen Paket
Partner sind keine Komponenten entstanden. Abbildung 4-25 zeigt den Zusammenhang
zwischen den Komponenten und dem fachlichen Paket.
Aus einem elementaren fachlichen Paket wird für jede Schicht eine Komponente erstellt.
Der Entwickler kann später gegebenenfalls eine Komponente entfernen, wenn
sie nicht benötigt wird. Dies ist in Abbildung 4-23 ersichtlich: Die Komponenten der
Datenzugriffsschicht, die aus dem fachlichen Paket Kundenmappe abgeleitet worden
ist, wurde nachträglich aus dem Modell entfernt (vgl. Abbildung 4-9).
Aus einer Steuerungsklasse mit öffentlichen Operationen entstehen die Schnittstellen,
wobei die Funktionalität einer Steuerungsklasse auf mehrere Schnittstellen der verschiedenen
Schichten abgebildet werden kann. Dies wird weiter unten anhand eines
Beispiels verdeutlicht.
Die Modellierung der Schnittstellen im Detail. Ein Ziel der neuen Methodik ist
die genaue Spezifikation der Schnittstellen. Um dies zu erreichen, sind die Konzepte

56 Das Fallbeispiel »Kundenmappe«
des Designmodells in dieser Arbeit für eine COBOL-Umgebung konkretisiert. Dazu
gehört auch die Modellierung der Schnittstelle 27 .
Fachliches Modell
Designmodell
«fachlichesPaket»
BeteiligtePartei
BeteiligteParteiVerwalterSteuerung
«designkomponente»
BeteiligteParteiSteuerung
BeteiligteParteiVerwalter
«realisiert»
BeteiligteParteiVerwalter
«designkomponente»
BeteiligteParteiGeschäftslogik
BeteiligteParteiBearbeiter
«designkomponente»
BeteiligteParteiDatenzugriff
Abbildung 4-25 Zusammenhang zwischen Designkomponenten und fachlichen
Paketen
In den folgenden Absätzen wird eine Modellierung vorgestellt, die sich direkt auf
COBOL-Quelltext abbilden lässt.
Abbildung 4-26 zeigt die Operationen einer Schnittstelle und die Beziehungen zur
fachlichen Klasse. Die Operation finde der Schnittstelle BeteiligteParteiVerwalterSteuerung
hat drei Parameter:
27 Die allgemeinen Konzepte der Schnittstellenmodellierung sowie die Syntax der Operationen werden
im Abschnitt 5.3.1 vertieft.

Designmodell 57
§
§
§
Den Eingabeparameter in adresssatzRecord,
den Ausgabeparameter out beteiligteParteiRecord und
den Rückgabetyp RückgabeDaten.
Der Unterschied zu der Steuerungsklasse aus dem fachlichen Modell ist, dass die O-
peration der technischen Umgebung angepasst wird. Die Typen der Parameter sind
COBOL-spezifisch und die Richtung wird spezifiziert. Der Rückgabetyp spezifiziert
eine Datenstruktur, die den Status der Operation umfasst.
Fachliches Modell
«control»
BeteiligteParteiVerwalter
+ findeBeteiligtePartei(adresssatz : Adresssatz) : BeteiligtePartei
- prüfeExistenz(adresssatz : Adresssatz) : Ja/Nein-Wert
...
«realisiert»
Designmodell
«interface»
BeteiligteParteiVerwalterSteuerung
+ finde( in adresssatzRecord : AdresssatzRecord,
out beteiligteParteiRecord : BeteiligteParteiRecord) : RückgabeDaten
Abbildung 4-26 Zusammenhang zwischen Schnittstellen und Steuerungsklassen
Wird bei einem Operationsaufruf ein Zeiger als Argument übergeben, muss der entsprechende
Parameter der Operation mit pointer spezifiziert werden. Abbildung 4-27
zeigt die Schnittstelle BeteiligteParteiBearbeiter, die eine Operation mit einem
pointer-Parameter enthält. Der Typ des Parameters spezifiziert den Datentyp, auf den
der Zeiger zeigt.
«interface»
BeteiligteParteiBearbeiter
+ lese(in adresssatznummer : PIC 9(4), out pointer beteiligteParteiPointer : BeteiligteParteiRecord)
+ erzeuge(in pointer beteiligteParteiPointer : BeteiligteParteiRecord)
Abbildung 4-27 Die Schnittstelle BeteiligteParteiBearbeiter
Modellierung der Datenstrukturen. Um die Schnittstelle genau zu modellieren, ist
die Spezifizierung der verwendeten Datenstrukturen wichtig. Abbildung 4-28 zeigt
wie eine Datenstruktur modelliert wird und stellt die Beziehungen der Struktur zu den
fachlichen Entitäten dar. Im Designmodell ändert sich der Typ der Attribute und technische
Attribute kommen hinzu. Zum Beispiel wurde das fachliche Attribut beschrei-

58 Das Fallbeispiel »Kundenmappe«
bungstext technisch mit einer Datenstruktur Textzeile realisiert. Als Attributtypen dürfen
nur elementare COBOL-Typen oder Datenstrukturen verwendet werden. Die Art
und Weise wie die Generalisierung aufgebrochen wird, hat der Designer im konkreten
Fall zu bestimmen. Im Fallbeispiel wurde eine sehr einfache Art gewählt: Alle Attribute
der Entitäten werden in einer Datenstruktur zusammengefasst und ein Attribut
typ hinzugefügt, das den Typ der Datenstruktur spezifiziert. Die Entität BeteiligtePartei
hat im fachlichen Modell eine gerichtete Assoziation zu der Entität Adresssatz.
Dafür wird im Designmodell ein Attribut mit dem Stereotyp «foreignKey» hinzugefügt.
Die berechneten Attribute werden übernommen (vgl. Abbildung 4-31, dort ist
die Operation spezifiziert, die für die Berechnung der Attribute zuständig ist).
Fachliches Modell
Designmodell
...
«primaryKey»
/+ anrede : Zeichenkette
/+ vorname : Zeichenkette
/+ name : Zeichenkette
«entity»
BeteiligtePartei
+ beteiligteParteiNummer : PositiveGanzzahl
+ beschreibungstext : Zeichenkette
+ vermögenswert : Geldbetrag
«entity»
NatürlichePerson
«realisiert»
«datenstruktur»
BeteiligteParteiRecord
«primaryKey» + beteiligteParteiNummer : PIC 9(4)
+ vermögenswert : PIC 9(8)
+ typ : PIC X
«foreignKey» + adresssatzNummer : PIC 9(4)
/+ anrede : PIC X
/+ vorname : PIC X(25)
/+ name : PIC X(30)
8 +beschreibung
«datenstruktur»
Textzeile
+ text : PIC X(10)
Abbildung 4-28 Zusammenhang zwischen Datenstrukturen und fachlichen
Entitäten
4.4.2 Dynamische Komponentensicht
Die dynamische Komponentensicht zeigt wie die Komponenten und ihre Schnittstellen
einen Anwendungsfall realisieren. Sie stellt also in den Diagrammen der Anwendungsfall-Realisierungen
den dynamischen Ablauf einer Ausführung eines Anwendungsfalls
dar. Abbildung 4-29 zeigt exemplarisch ein Kollaborationsdiagramm 28 für
den Anwendungsfall BeteiligtePartei finden – Fachlich.
Der Ablauf ist im folgenden Absatz beschrieben. Der Berater ruft den Dienst finden
der Komponente BeteiligteParteiSteuerung auf. Der Dienst wird über die Schnittstelle
BeteiligteParteiVerwalterSteuerung aufgerufen. Dieser Aufruf wird modelliert, indem
28 Es sollte beachtet werden, dass im Kollaborationsdiagramm Instanzen von Komponenten verwendet
werden. Eine Designkomponente erweitert das UML-Basiselement Subsystem. Ein Subsystem ist,
im Gegensatz zu einem Paket, instanzierbar (vgl. Abschnitt 5.3.1). Unabhängig davon ist es nicht
möglich, dieses Diagramm mit Rational Rose zu erstellen. Es gibt eine Reihe von Workarounds, die
in dieser Arbeit nicht besprochen werden, da der Fokus hier auf eine allgemeine Notation mit der
UML liegt.

Designmodell 59
der Name der Schnittstelle durch zwei Doppelpunkte (::)
mit dem Aufruf verknüpft wird. Die Komponente leitet den Aufruf an die Geschäftslogikkomponente
weiter. Diese ruft die Datenzugriffskomponenten auf, um die beteiligte
Partei zu lesen. Wird ein Fehlercode zurückgegeben, der spezifiziert, dass die
beteiligte Partei nicht vorhanden ist, ruft die Komponente die Operation der Datenzugriffskomponenten
auf, die eine neue beteiligte Partei erzeugt. Diese Datenstruktur
der beteiligten Partei wird dann zurückgegeben.
: Frontend
1: BeteiligteParteiVerwalterSteuerung::finde(in AdresssatzRecord, out BeteiligteParteiRecord)
«designkomponente»
BeteiligteParteiSteuerung
BeteiligteParteiRecord
2: BeteiligteParteiVerwalter::finde(in AdresssatzRecord, out BeteiligteParteiRecord)
«designkomponente»
BeteiligteParteiGeschäftslogik
3: BeteiligteParteiBearbeiter::lese(in adresssatznummer, out pointer BeteiligteParteiRecord) : Rückgabewert
4: [Rückgabewert = Nicht gefunden] BeteiligteParteiBearbeiter::erzeuge(in pointer BeteiligteParteiRecord)
«designkomponente»
BeteiligteParteiDatenzugriff
Abbildung 4-29 Das Kollaborationsdiagramm Beteiligte Partei finden – Design
4.4.3 Statische Modulsicht
Die statische Modulsicht zeigt die von einer Komponente gekapselten Elemente: Module,
Datenstrukturen, Copystrecken, und auch die Schnittstellen, da diese innerhalb

60 Das Fallbeispiel »Kundenmappe«
der Komponente liegen. Hier wird spezifiziert, welches Modul welche Schnittstelle
realisiert und die Beziehungen zwischen den Modulen und Datenstrukturen modelliert.
In diesem Abschnitt werden exemplarisch zwei Komponenten aus verschiedenen
Schichten herausgegriffen und ihr innerer Aufbau beschrieben. Gegenstand der Beschreibung
ist die Verfeinerung der Datenstrukturen und die Modulbildung. Auch hier
wird der Bezug zum fachlichen Modell hergestellt.
Im Designmodell wurde bisher für prozedurale Sprachen eine Komponente nur als
schwarzer Kasten betrachtet. Die Beschreibung der Implementierung erfolgte im Implementierungsmodell
[IZB 2003c].
Eine Komponente wird in der neuen Methodik durch eine Innenansicht ergänzt. Die
Innenansicht erfüllt die Funktion, die bisher das Implementierungsmodell eingenommen
hat. Somit werden Konzepte des Implementierungsmodells in das Designmodell
verschoben. Der Rest des Implementierungsmodells wird als »entkernt« bezeichnet.
Zu beachten ist, dass sich bei der Übernahme der Konzepte aus dem Implementierungsmodell
einige Sachverhalte verändert haben: Das Konzept der Datenstrukturen
kommt hinzu; das Konzept der Copystrecken ist dahingehend geändert, dass jetzt eine
Copystrecke eine spezielle Datenstruktur darstellt und somit die Beziehungen zwischen
Modul und Copystrecke neu definiert sind (vgl. Abschnitt 5.3.1).
Zur Verdeutlichung betrachten wir exemplarisch die Komponenten BeteiligtePartei-
Geschäftslogik und BeteiligteParteiDatenzugriff. Abbildung 4-30 zeigt eine Übersicht
über diese beiden Komponenten.
Die Komponenten und die Schnittstellen sind dieselben Elemente wie in der Komponentensicht.
Die Schnittstelle wird nur in einem anderen Format angezeigt und dort
dargestellt, wo sie auch enthalten ist, nämlich in der Komponente. In der Modulsicht
kommen Module und Datenstrukturen hinzu. Eine spezielle Form der Datenstruktur
ist die Copystrecke. Ein Modul wird durch eine Klasse mit dem Stereotyp «modul»
dargestellt. Der Name eines Moduls setzt sich aus seinem Dateinamen 29 und einer
Kurzbeschreibung zusammen.
Die Realisierungsbeziehung des Moduls KG2100 zu der Schnittstelle BeteiligteParteiVerwalter
spezifiziert, dass dieses Modul die Operationen der Schnittstelle realisiert.
Die Abhängigkeitsbeziehungen mit dem Stereotyp «call» bedeutet, dass das
Modul dazu Operationen anderer Module in Anspruch nimmt.
Betrachten wir die verschiedenen Beziehungen des Moduls KG2110. Die Abhängigkeitsbeziehung
zu der Schnittstelle BeteiligteParteiBearbeiter mit dem Stereotyp
«call» spezifiziert, dass das Quell-Modul KG2110 während der Laufzeit das Ziel-
Modul KL2111 aufruft.
29 Der Dateiname wird nach den Konventionen [IZB 2002d] gebildet, z. B. KG2110, KS1000. Wobei
der zweite Buchstabe die Schicht kennzeichnet. »S« steht z. B. für Steuerungsschicht.

Designmodell 61
Die Assoziation zu der Datenstruktur BeteiligteParteiRecord bedeutet, dass das Modul
auf die Datenstruktur, welche nicht im Speicherbereich des Moduls liegt, mit einem
Zeiger zugreift. Dafür muss die Datenstruktur in der linkage section definiert
werden.
Die Kompositions-Beziehung des Moduls K2111 zu der Datenstruktur bedeutet, dass
die Datenstruktur im Speicherbereich vom Modul liegt. Es lässt sich daraus ableiten,
dass die Datenstruktur in der working-storage section definiert ist.
«designkomponente»
BeteiligteParteiGeschäftslogik
«interface»
BeteiligteParteiVerwalter
«modul»
KG2100 BeteiligteParteiVerwalterFassade
«call»
«modul»
KG2110 BeteiligteParteiVerwalter
«call»
«modul»
KG2120 BeteiligtePartei
«call»
«designkomponente»
BeteiligteParteiDatenzugriff
1 +dzDaten
«interface»
«copystrecke»
BeteiligteParteiBearbeiter
CKL2111 BeteiligteParteiRecord
wird exportiert
ist gekapselt
1 +daten
0..*
8 +beschreibung
«datenstruktur»
Textzeile
«modul»
KL2111 BeteiligteParteiBearbeiter
«indizierteDatei»
BeteiligteParteiDatei
Abbildung 4-30 Modulsicht auf zwei Komponenten

62 Das Fallbeispiel »Kundenmappe«
Die Abbildung zeigt auch eine Klasse mit dem Stereotyp «indizierteDatei». Die Modellierung
der indizierten Datei ist ein Beispiel, um zu zeigen, wie der Zugriff auf eine
persistente Speicherung dargestellt werden kann. Die Komposition zur Datenstruktur
spezifiziert das Format der in der Datei enthaltenen Datensätze.
Die öffentlichen Operationen der Steuerungsklassen werden auf die Schnittstellen
abgebildet. Die privaten Operationen der Steuerungsklassen und die Operationen der
Entitäten werden in Module abgebildet. Abbildung 4-31 zeigt das Modul KG2120 im
Detail, also die Verantwortungen der fachlichen Klassen, die das Modul implementiert.
Das Modul spezifiziert eine Operation für die Prüfung der Konsistenz einer beteiligten
Partei und eine Operation für die Berechnung der abgeleiteten Attribute der
Klasse NatürlichePerson. Bei einer sturen Abbildung würde für jedes abgeleitete Attribut
eine Operation entstehen. An dieser Stelle ist es jedoch schöner, diese zu einer
Operation zusammenzufassen.
BeteiligtePartei
BeteiligteParteiVerwalter
Fachliches Modell
Designmodell
«modul»
«realisiert»
KG2120 BeteiligtePartei
+ prüfeKonsistenz(in beteiligtePartei : BeteiligteParteiRecord)
+ berechneNatürlichePerson( inout beteiligtePartei : BeteiligteParteiRecord,
in adresssatzRecord : AdresssatzRecord)
Abbildung 4-31 Zusammenhang zwischen Modulen und fachlichen Klassen
4.4.4 Dynamische Modulsicht
Die Dynamische Modulsicht zeigt die Realisierung der Anwendungsfälle mit den
Elementen der Modulsicht. Diese stellt die letzte Stufe der Anwendungsfall-
Realisierungen dar: Anhand von Modulen, Datenstrukturen und Copystrecken werden
die Anwendungsfälle durchgespielt.
Abbildung 4-32 zeigt, wie die Module den Anwendungsfall BeteiligtePartei finden
realisieren. Der Ablauf ist in einem Sequenzdiagramm beschrieben und ist im Wesentlichen
der gleiche wie der, der Komponentensicht. Hinzu kommen die Aktivitäten
innerhalb einer Komponente. So zeigt das Diagramm, dass die Module der Komponente
BeteiligteParteiGeschäftslogik die abgeleiteten Attribute berechnen und die
Konsistenz der beteiligten Partei prüfen.

Designmodell 63
: KS2000
BeteiligteParteiVerwalter
Steuerung
: KG2100
BeteiligteParteiVerwalter
Fassade
: KG2120
BeteiligtePartei
: KG2110
BeteiligteParteiVerwalter
: KL2111
BeteiligteParteiBearbeiter
findeBeteiligtePartei(in adresssatzRecord, out beteiligteParteiRecord)
findeBeteiligtePartei(in adresssatzRecord, out beteiligteParteiRecord)
rückgabe := lese(in adresssatznummer, out pointer beteiligteParteiPointer)
[rückgabe = nicht vorhanden] erzeuge(in pointer beteiligteParteiPointer)
berechneNatürlichePerson(inout beteiligtePartei, in adresssatzRecord)
prüfeKonsistenz(in beteiligtePartei)
Abbildung 4-32 Das Sequenzdiagramm BeteiligtePartei finden – Design

64 Das Fallbeispiel »Kundenmappe«
4.5 Implementierungsmodell
Im Designmodell wurde die technische Struktur modelliert. Nun wird beschrieben,
welche Dateien aus dem Designmodell entstehen und welche Abhängigkeiten für die
Kompilierung zwischen den Dateien existieren. In diesem Abschnitt wird die Demonstration
der Durchgängigkeit mit der Ableitung einiger Designelemente in
COBOL-Quelltext abgeschlossen. Abbildung 4-33 zeigt den Fokus dieses Abschnitts.
Use Case View
«modell» Anwendungsfallmodell
Logical View
«modell» Fachliches Modell
«modell» Designmodell
«modell» Implementierungsmodell
2. Methodischer Übergang
Abbildung 4-33 Das Modell der Implementierung
4.5.1 Dateisicht: Organisation der Dateien
Die Dateisicht beschreibt die Organisation der Dateien mit den Einheiten, die
COBOL zur Verfügung stellt. Diese sind Moduldateien und Copystrecken. Gruppierungskonzepte
aus dem Designmodell werden ebenfalls in das Implementierungsmodell
abgebildet.
Das in Abbildung 4-34 dargestellte Klassendiagramm zeigt die Komponenten
BeteiligteParteiGeschäftslogik und BeteiligteParteiDatenzugriff. Diese sind aus
dem Designmodell (vgl. Abbildung 4-30) entstanden.
Aus den Modulen und Copystrecken des Designmodells werden im Implementierungsmodell
Moduldateien («moduldatei») und Copystreckendateien («copystreckedatei»).
Beide sind spezielle Dateien, die durch eine Klasse mit dem entsprechenden
Stereotyp repräsentiert werden. Allgemeine Dateien werden durch eine Klasse mit
dem Stereotyp «datei» repräsentiert. Die Datei beteiligtepartei.dat ist aus der indizierten
Datei des Designmodells entstanden. Die Designkomponenten werden auf eine
Implementierungskomponente mit demselben Namen abgebildet und in einer flachen
Struktur angeordnet.

Implementierungsmodell 65
«implementierungskomponente»
BeteiligteParteiGeschäftslogik
«moduldatei»
KG2100.COB
«moduldatei»
KG2110.COB
«moduldatei»
KG2120.COB
«implementierungskomponente»
BeteiligteParteiDatenzugriff
«moduldatei»
KL2111.COB
«copystreckedatei»
CKL2111.CPY
«datei»
beteiligtepartei.dat
Abbildung 4-34 Dateisicht auf zwei Komponenten
Eine Implementierungskomponente wird durch ein Paket mit dem Stereotyp «implementierungskomponente»
repräsentiert und stellt einen Ordner des Dateisystems dar.
Abbildung 4-35 zeigt den Ordner der Implementierungskomponente BeteiligteParteiDatenzugriff.
Sein Inhalt sind die in der Implementierungskomponente enthaltenen
Dateien. Die Namen der Elemente im Implementierungsmodell entsprechen den Dateinamen
des Dateisystems.
BeteiligteParteiDatenzugriff
KL2111.COB
CKL2111.CPY
beteiligtepartei.dat
Abbildung 4-35 Eine Implementierungskomponente im Dateisystem
Im »entkernten« Implementierungsmodell werden nur noch Abhängigkeiten modelliert,
die beim Kompilieren und Ausführen auftreten. Somit sind Abhängigkeiten die
einzigen Beziehungen zwischen den Elementen des Implementierungsmodells. Eine
Abhängigkeit zwischen zwei Elementen bedeutet, dass eine Änderung oder die Ent-

66 Das Fallbeispiel »Kundenmappe«
fernung des Zielelements einen Fehler beim kompilieren auslösen kann. Es ist also
erforderlich, das Quellelement der Änderung anzupassen. Die Abhängigkeiten entstehen
aus folgenden Beziehungen im Designmodell:
¨
¨
¨
Aufrufbeziehung (z. B.: Modul KG2110 – Modul KL2111)
Komposition (z. B.: Modul KL2111 – Copystrecke CKL2111)
Assoziation (z. B.: Modul KG2110 – Copystrecke CKL2111)
4.5.2 Quelltextsicht
Der Inhalt der Modul- und Copystreckendateien besteht aus COBOL-Quelltext. Teile
des Quelltextes lassen sich aus den Elementen des Designmodells ableiten. Gegenstand
der Quelltextsicht ist es, diesen Quelltext darzustellen. In diesem Abschnitt wird
exemplarisch eine Auswahl von Designelementen, die in Abbildung 4-36 dargestellt
sind, in das Implementierungsmodell abgebildet. Dabei wird der abgeleitete Quelltext
besprochen.
Datenstrukturen und Copystrecken. Aus der Copystrecke CKL2111 Beteiligte-
ParteiRecord 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 Problembereichs 30 , ist
schließlich eine COBOL-Datenstruktur entstanden. Listing 4-1 zeigt, dass die Datei
aus einem Group Item mit der Nummer der Copystrecke als Name besteht. Dieses
Feld enthält die Attribute und Kompositionen der Copystrecke 31 . Ist die Multiplizität
größer als »1«, wird die occurs-Klausel verwendet. Um die Funktionalität des Ersetzens
nutzen zu können, wird in einer Copystrecke immer »a:« vor ein 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.
Listing 4-1 Quelltext aus der Copystreckedatei CKL2111.CPY
05 A:CKL2111.
08 A:BETEILIGTE-PARTEI-NUMMER PIC 9(4).
08 A:BESCHREIBUNG-TEXTZEILE OCCURS 8.
10 A:BESCHREIBUNG-TEXT PIC X(10).
08 A:VERMOEGENSWERT PIC 9(8).
08 A:TYP PIC X.
...
30 Die Klassen des Problembereichs sind in der Abbildung 4-7 zu finden.
31 Die Attribute und Kompositionen der Datenstruktur sind in der Abbildung 4-28 dargestellt.

Implementierungsmodell 67
«designkomponente»
BeteiligteParteiGeschäftslogik
«modul»
KG2110 BeteiligteParteiVerwalter
«call»
«designkomponente»
BeteiligteParteiDatenzugriff
1 +dzDaten
«interface»
«copystrecke»
BeteiligteParteiBearbeiter CKL2111 BeteiligteParteiRecord
1 +daten 0..*
8 +beschreibung
«datenstruktur»
Textzeile
wird exportiert
ist gekapselt
Designmodell
«modul»
KL2111 BeteiligteParteiBearbeiter
«indizierteDatei»
BeteiligteParteiDatei
Implementierungsmodell
«implementierungskomponente»
BeteiligteParteiGeschäftslogik
«moduldatei»
KG2110.COB
«implementierungskomponente»
BeteiligteParteiDatenzugriff
«moduldatei»
KL2111.COB
«copystreckedatei»
CKL2111.CPY
«datei»
beteiligtepartei.dat
Abbildung 4-36 Übergang in das Implementierungsmodell

68 Das Fallbeispiel »Kundenmappe«
Module. Aus dem Modul KL2111 BeteiligteParteiBearbeiter wird im Implementierungsmodell
die Datei KL2111.COB. Listing 4-2 zeigt, welcher Quelltext aus der
Komposition zwischen dem Modul und der Copystrecke im Designmodell entstanden
ist. Zusätzlich wird der Quelltext dargestellt, der aus der Assoziation zwischen dem
Modul und der indizierten Datei abgeleitet werden kann.
Die Komposition zur Copystrecke 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 Copystrecke
handelt, wird die copy-Anweisung verwendet. Es sollte darauf geachtet
werden, dass mit Hilfe der replacing-Klausel die Rolle der Datenstruktur vor die
Felder gesetzt wird. Das ist besonders hilfreich, wenn ein Modul mehrmals dieselbe
Datenstruktur verwendet.
Listing 4-2 Quelltext aus der Moduldatei KL2111.COB
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-==.
...
Aus dem Modul KG2110 BeteiligteParteiVerwalter wird im Implementierungsmodell
die Datei KG2110.COB. Listing 4-3 zeigt, welcher Quelltext aus der Assoziation zwischen
dem Modul und der Copystrecke im Designmodell entstanden ist.
Die Assoziation zu der Copystrecke 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 procedure
division using-Kausel. In jedem Fall muss die Datenstruktur in der linkage
section definiert werden. Auch hier wird die copy-Anweisung verwendet. Es ist

Implementierungsmodell 69
zu beachten, dass aus der Schreibweise der Rolle dzDaten in COBOL die Schreibweise
dz-daten wird.
Listing 4-3 Quelltext aus der Moduldatei KG2110.COB
IDENTIFICATION DIVISION.
PROGRAM-ID. KG2110.
...
LINKAGE SECTION.
01 DZ-DATEN-BETEILIGTE-PARTEI-RECORD.
COPY "CKL2111.CPY" REPLACING ==A:== BY ==DZ-DATEN-==.
...
Abbildung der Schnittstelle. Um eine Schnittstelle in Quelltext abzubilden, wird
der Nutzer der Schnittstelle vom Anbieter der Schnittstelle getrennt. Im Fallbeispiel
ist das Modul KL2111 BeteiligteParteiBearbeiter Anbieter der Schnittstelle
BeteiligteParteiBearbeiter und das Modul KG2110 BeteiligteParteiVerwalter Nutzer
der Schnittstelle. Der Name der Schnittstelle wurde im Quelltext auf bpbearbeiter
gekürzt; an kennzeichnet die Felder des Anbieters; nu kennzeichnet die
Felder des Nutzers.
Listing 4-4 zeigt den Quelltext des Anbieters der Schnittstelle. Zuerst werden in der
linkage section die Argumente definiert. Der Zeiger an-args-pointer zeigt auf die
Datenstruktur der Argumente der aufgerufenen Operation. Welche Operation ausgeführt
werden soll, steht im Feld an-bp-bearbeiter-operation. Die Datenstruktur
an-bp-bearbeiter-lese-args definiert die Argumente, die für die Operation lese
übergeben werden. In der using-Klausel werden die Parameter, die zur Laufzeit die
Argumente enthalten, spezifiziert. Mit dem evaluate-Block wird dann abhängig von
der aufgerufenen Operation die richtige Datenstruktur über das Argument gelegt.
Listing 4-5 zeigt den Quelltext des Nutzers der Schnittstelle. Hier ist die Definition
der Argumente in der working-storage section. In der procedure division wird
zuerst die Operation spezifiziert, welche das Modul aufrufen möchte, dann der Zeiger
der Argumente auf die Datenstruktur gesetzt, welche die Argumente enthält. Schließlich
kann das Modul mit den Argumenten aufgerufen werden.

70 Das Fallbeispiel »Kundenmappe«
Listing 4-4 Anbieter: Quelltext aus der Moduldatei BeteiligteParteiBearbeiter
LINKAGE SECTION.
01 AN-ARGS-POINTER USAGE IS POINTER.
01 AN-BP-BEARBEITER-OPERATION PIC X(7).
88 AN-BP-BEARBEITER-LESE VALUE "LESE".
88 AN-BP-BEARBEITER-ERZEUGE VALUE "ERZEUGE".
01 AN-BP-BEARBEITER-LESE-ARGS.
05 AN-LESE-ADRESSSATZ-NUMMER PIC 9(4).
05 AN-LESE-BP-POINTER USAGE IS POINTER.
01 AN-BP-BEARBEITER-ERZEUGE-ARGS.
05 AN-ERZEUGE-BP-POINTER USAGE IS POINTER.
PROCEDURE DIVISION USING
AN-BP-BEARBEITER-OPERATION
AN-ARGS-POINTER.
...
EVALUATE TRUE
WHEN AN-BP-BEARBEITER-LESE
SET ADDRESS OF AN-BP-BEARBEITER-LESE-ARGS
TO AN-ARGS-POINTER
©
PERFORM P21-LESE
WHEN AN-BP-BEARBEITER-ERZEUGE
SET ADDRESS OF AN-BP-BEARBEITER-ERZEUGE-ARGS
TO AN-ARGS-POINTER
©
PERFORM P22-ERZEUGE
WHEN OTHER
...
END-EVALUATE.
Listing 4-5 Nutzer: Quelltext aus der Moduldatei BeteiligteParteiVerwalter
WORKING-STORAGE SECTION.
01 NU-ARGS-POINTER USAGE IS POINTER.
01 NU-BP-BEARBEITER-OPERATION PIC X(7).
88 NU-BP-BEARBEITER-LESE VALUE "LESE".
88 NU-BP-BEARBEITER-ERZEUGE VALUE "ERZEUGE".
01 NU-BP-BEARBEITER-LESE-ARGS.
...
01 NU-BP-BEARBEITER-ERZEUGE-ARGS.
05 NU-ERZEUGE-BP-POINTER USAGE IS POINTER.
PROCEDURE DIVISION
...
SET NU-BP-BEARBEITER-ERZEUGE TO TRUE.
SET NU-ARGS-POINTER TO ADDRESS OF ©
NU-BP-BEARBEITER-ERZEUGE-ARGS.
CALL "KL2110" USING
NU-BP-BEARBEITER-OPERATION
NU-ARGS-POINTER.

Zusammenfassung 71
4.6 Zusammenfassung
In diesem Abschnitt werden die wichtigsten Konzepte der drei Kernmodelle zusammengefasst.
Außerdem werden die »Entkernung« des Implementierungsmodells und
die sich dadurch ergebenen Änderungen bewertet.
4.6.1 Eigenschaften der Kernmodelle
Ein methodischer Übergang befindet sich zum einen zwischen dem fachlichen Modell
und dem Designmodell und zum anderen zwischen dem Designmodell und dem Implementierungsmodell.
Deswegen bilden die genannten Modelle den Kern des Modellsystems.
Die Eigenschaften der Modelle, die sich bei den Übergängen zwischen den
Ebenen ändern, sind in Tabelle 4-1 zusammengefasst.
Tabelle 4-1 Eigenschaften der Kernmodelle
Fachliches Modell Designmodell Implementierungsmodell
Bauplan der Implementierung
– lässt sich direkt in
Quelltext umsetzen; stellt
aber eine Abstraktion dar, da
es logische Konzepte enthält.
COBOL-spezifisch.
Verantwortlichkeiten werden
realisiert durch Module und
Datenstrukturen – logisch
gekapselt in Komponenten
mit Schnittstellen.
Fachliche Abstraktion des
Systems – ohne technische
Details und Aspekte der
Implementierungsumgebung.
Programmiersprachenunabhängig.
Verteilt die Verantwortlichkeiten
auf fachliche Klassen:
Control, Entity und Boundary.
Beschreibt die tatsächlichen
Dateien und Ordner, die
aus der Umsetzung des
Designmodells in COBOL
entstehen.
Abhängig von den Strukturmechanismen
von
COBOL.
Die Konzepte des Designmodells
werden auf Moduldateien
und Copystreckendateien
abgebildet.
Allgemein. Konkret und formal. —
Keine Schichten. Schichtenarchitektur. —
Umreißt die Struktur nach
fachlichen Gesichtspunkten.
Konkretisiert die Struktur in
der technischen COBOL-
Umgebung; versucht die
fachliche Struktur so gut wie
möglich zu erhalten.
—

72 Das Fallbeispiel »Kundenmappe«
4.6.2 Bewertung der »Entkernung«
Die wesentlichste Änderung ist die »Entkernung« des Implementierungsmodells. Das
Designmodell enthält nun Module, Datenstrukturen und Copystrecken. Das Implementierungsmodell
enthält nur noch die physischen Elemente des Dateisystems (Dateien,
verteilbare Laufzeitkomponenten). Die Beziehungen zwischen den Elementen
sind Kompilierungs- oder Laufzeitabhängigkeiten. Im Folgenden werden die Vor- und
Nachteile erläutert:
Pro:
Leichtere Navigierbarkeit: Die Realisierung der Komponenten befindet sich jetzt
innerhalb der Komponenten. Deshalb ist die Navigation bei der Verwendung von
CASE-Werkzeugen leichter als das bisherige Springen zu einem neuen Modell.
Die Elemente des Designmodells sind leichter zu pflegen und konsistent zu halten,
da nur innerhalb eines Modells, anstatt über Modellgrenzen hinweg, die Elemente
gepflegt werden müssen.
Das Implementierungsmodell kann automatisch erzeugt werden: Alle Designentscheidungen
und Spezifikationen sind jetzt im Designmodell. Deshalb ist es möglich,
die Informationen, die für das »entkernte« Implementierungsmodell benötigt
werden, aus dem Designmodell abzuleiten.
Die Elemente des Implementierungsmodells können in das Laufzeitmodell integriert
werden: Soll ein Laufzeitmodell angefertigt werden, werden physische Einheiten
benötigt, um sie auf einen Hardware-Knoten zu legen. Diese Einheiten
stellt das Implementierungsmodell bereit.
Contra:
− Die Informationsdichte hat sich im Designmodell vergrößert: Nachdem die Information
aus dem Implementierungsmodell jetzt im Designmodell modelliert wird,
muss mit einer großen Informationsdichte umgegangen werden. Durch die geschickte
Verteilung der Elemente auf mehrere Diagramme kann dieses Problem
bewältigt werden.
− Standards sind verletzt worden: Aufgrund der »Entkernung« des Implementierungsmodells
sowie leichten Änderungen am Designmodell ist der erst kürzlich
freigegebene Standard »Technische Modellierung« [IZB 2003c] verletzt worden.
Dies könnte innerhalb der IZB SOFT – wenn der Eindruck entsteht, dass sich
Standards zu häufig ändern – die Akzeptanz der Standards verringern. Es sollte
jedoch nicht außer Acht gelassen werden, dass eine solche Veränderung, die als
Vereinfachung und somit als Effizienz steigernd empfunden wird, sich positiv auf
die Standards auswirkt.

5 UML-Profil für moCa
Die neue Methodik modellbasierte Entwicklung einer COBOL-Anwendung (moCa)
basiert auf Modellen, die sich in unterschiedlichen Abstraktionsebenen befinden. Ziel
dieses Kapitels ist es, die Semantik der Modellelemente zu definieren und eine graphische
Repräsentation der Elemente, festzulegen.
Als Modellierungssprache wird die Unified Modeling Language (UML) [OMG] verwendet,
da sie Erweiterungsmechanismen anbietet.
Erweiterungsmechanismen. Die Mechanismen sind Stereotypen, Tagged-Values
und Einschränkungen. Stereotypen erweitern die Semantik von bereits bestehenden
Elementen wie Klassen oder Beziehungen. Mithilfe von Stereotypen werden die Elemente
der Modelle klassifiziert. Ein Stereotyp wird über den Klassennamen geschrieben
und ist in Guillemets eingeschlossen («foo»). Um das Stereotyp leicht von dem
Klassennamen zu unterscheiden, wird er immer klein geschrieben. Für ein Stereotyp
können auch Icons definiert werden. Anstelle des Rechtecks erscheint dann das Icon.
Mit Tagged-Values können Eigenschaftswerte für Elemente definiert werden. Einschränkungen
sind definierte Regeln für die Elemente und spezifizieren die Verwendung.
Eine Menge von Erweiterungen wird zu einem Profil zusammengefasst.
Organisation der Modelle. Unter einem physischen System wird das System verstanden,
das modelliert wird: in diesem Fall die Software der Anwendung (COBOL,
CICS, etc.), die Hardware (Terminals, IBM S/360, etc.) und auch der Berater, der das
Terminal bedient.
Ein Modell stellt eine Sicht auf das physische System dar. Innerhalb eines Modells
wird das physische System durch Modellelemente repräsentiert. Durch die Verwendung
von Paketen kann eine Hierarchie geschaffen werden. Das höchste Paket in der
Pakethierarchie wird das Top-Level-Paket genannt. Dieses Paket repräsentiert die
Grenze des physischen Systems. Da die Grenze des Pakets eine Grenze auf Systemebene
darstellt, kann sich die Semantik des Paketes von der der enthaltenen Pakete
unterscheiden. Zum Beispiel könnte die Sichtbarkeit der Elemente auf der höchsten
Ebene eingeschränkt sein.
In der IZB SOFT ist das Gesamtsystem unterteilt in Systeme. Ein System stellt laut
[IZB 2003c] eine Organisationseinheit dar, d. h. ein System wird eigenständig verwaltet
und dokumentiert (Fach- und DV-Konzept, Modelle, Handbücher, etc.). Demnach
wird für jedes System eine Modelldatei angelegt. Die Organisation der verschiedenen
73

74 UML-Profil für moCa
Sichten wird in Abbildung 5-1 anhand der Browser-Sicht von Rational Rose verdeutlicht.
Pakete, die Sichten
(Modelle) gruppieren
Modell
(Sicht auf das physische System)
Top-Level-Modellelement
(repräsentiert das physische System)
Abbildung 5-1 Organisation der Modelle
Use Case View / Logical View
«modell» modell
«system»
Im Folgenden werden die Metamodelle für die verschiedenen Modelle beschrieben.
Die Metamodelle sind als Klassendiagramme dargestellt; jede Klasse repräsentiert ein
Stereotyp. Für die Modelle werden auch die zu verwendenden Datentypen definiert.
Außerdem werden die Beziehungen zwischen den Elementen der verschiedenen Metamodelle
bestimmt.
5.1 Anwendungsfallmodell
Mit dem Anwendungsfallmodell werden die Anforderungen an das System modelliert;
das System wird dabei von außen betrachtet. Ziel ist es, die Funktionalität, die
das System zu erbringen hat, vollständig über Anwendungsfälle zu dokumentieren.
Bei Anwendungen, die zwischen Front- und Backend trennen, ist es sinnvoll es Sinn,
die Anforderungen für die beiden Teile getrennt zu modellieren. Diese Trennung ermöglicht
eine anwendungsfallzentrierte Entwicklung.
Da die in dieser Arbeit vorgestellte Methodik auf die Erstellung von Komponenten für
das Backend abzielt, ist es Gegenstand des Anwendungsfallmodells, die Anforderungen
zu beschreiben, die an das Backend gestellt werden. Ein Anwendungsfall für das
Backend stellt einen Geschäftsvorfall dar (vgl. Abschnitt 2.3.2).
5.1.1 Struktur
Ein Paket mit dem Stereotyp «anwendungsfallmodell» repräsentiert das Anwendungsfallmodell.
Dieses Paket erweitert das UML-Basiselement Model und enthält Elemente,
die auf der Ebene der Anforderungsbeschreibung das System modellieren.
Ein Anwendungsfallmodell enthält ein Anwendungsfallsystem als Top-Level-Element,
das durch ein Paket mit dem Stereotyp «anwendungsfallsystem» dargestellt wird. Es

Anwendungsfallmodell 75
repräsentiert das Anwendungsfallpaket, das am höchsten in der Hierarchie steht, und
bildet die Grenze des Systems zu seiner Umgebung.
Ein Anwendungsfallsystem definiert eine Menge von Akteuren. Ein Akteur wird
durch eine Klasse mit dem Stereotyp «actor» 32 dargestellt und steht mit den Anwendungsfällen
in Beziehung. In dieser Arbeit werden folgende Akteure definiert: Berater,
Frontend und Backend. Ein Akteur initiiert einen Anwendungsfall und erwartet,
nachdem der Anwendungsfall seine Aktivitäten beendet hat, von dem System ein Ergebnis,
das ihm in irgendeiner Weise Nutzen bringt.
Anwendungsfallmodell
Enthält
0..*
Anwendungsfallpaket
0..1
Anwendungsfallsystem
Backend
Frontend
0..*
Akteur
eingabe
0..*
Anwendungsfall
0..* 0..*
ausgabe
Entität
Abbildung 5-2 Anwendungsfallmetamodell
Ein Anwendungsfallpaket wird durch ein Paket mit dem Stereotyp «anwendungsfallpaket»
repräsentiert und gruppiert Anwendungsfälle. Diese Strukturierung darf nicht
mit der inneren Struktur des Systems verwechselt werden.
Für die Zuordnung der Anwendungsfälle zum Frontend und zum Backend gibt es
zwei spezielle Anwendungsfallpakete: Das Paket Frontend (dargestellt durch ein Paket
mit dem Stereotyp «frontend») und das Paket Backend (dargestellt durch ein Paket
mit dem Stereotyp «backend»).
Ein Anwendungsfallpaket enthält eine Menge von Anwendungsfällen. Ein Anwendungsfall
hat, dargestellt in Abbildung 5-2, eine Menge von Entitäten als Ein- und
Ausgabe. Die Entitäten sind Klassen, die nur Attribute enthalten. Zwischen Entitäten
gibt es Beziehungen. Die Struktur der Entitäten repräsentiert den Problembereich.
32 Dieses Stereotyp ist in der UML bereits enthalten.

76 UML-Profil für moCa
5.1.2 Sichten
Unter einer Sicht wird ein Ausschnitt der Elemente aus einem Modell und der Detailgrad,
wie diese Elemente dargestellt werden, verstanden. Auf das Anwendungsfallmodell
sind zwei Sichten definiert:
Anwendungsfallsicht. Mehrere Anwendungsfalldiagramme zeigen wie Akteure
mit den Anwendungsfällen in Beziehung stehen. Sequenz- und Kollaborationsdiagramme
visualisieren den Ablauf der Anwendungsfälle.
Problembereichsicht. Mit einem Klassendiagramm werden die Klassen dargestellt,
welche die Konzepte des Problembereichs repräsentieren.
5.2 Fachliches Modell
Das fachliche Modell stellt eine fachliche Abstraktion des Systems dar. Die Struktur
lehnt sich an der des Anwendungsbereiches an und wird somit nach fachlichen Gesichtspunkten
entworfen. Es spezifiziert die wesentlichen fachlichen Informationen
und das Verhalten des Systems, um die funktionalen Anforderungen zu erfüllen, die
an das System gestellt werden. Es wird von einer idealen Computerplattform ausgegangen,
d. h. technische Details oder Einschränkungen konkreter Implementierungsumgebungen
werden nicht berücksichtigt.
Die Klassen des fachlichen Modells lassen sich aus den Anwendungsfällen und ihren
Beschreibungen bestimmen. Heuristiken für die Bestimmung der Klassen sind z. B. in
[Bruegge] beschrieben.
5.2.1 Struktur
Das fachliche Modell wird durch ein Paket mit dem Stereotyp «fachlichesModell»
repräsentiert. Dieses Paket erweitert das UML-Basiselement Model und enthält Elemente,
die das System auf fachlicher Ebene modellieren.
Das Top-Level-Element ist das fachliche System, dargestellt durch ein Paket mit dem
Stereotyp «fachlichesSystem». Dieses Paket liegt am höchsten in der Hierarchie und
bildet somit die Grenze des Systems zu seiner Umgebung.
Ein fachliches Paket wird durch ein Paket mit dem Stereotyp «fachlichesPaket» dargestellt
und gruppiert fachliche Klassen. Es gilt folgende Einschränkung: Enthält ein
fachliches Paket ein weiteres fachliches Paket, darf es keine fachlichen Klassen enthalten.
Verläuft eine Assoziation zwischen zwei Klassen aus unterschiedlichen Paketen, so
impliziert sie eine Abhängigkeit zwischen den beiden Paketen; diese Abhängigkeit

Fachliches Modell 77
wird durch eine Abhängigkeitsbeziehung modelliert, wobei die Richtung der Abhängigkeit
aus der Navigationsrichtung abzuleiten ist.
Ein fachliches Paket enthält fachliche Anwendungsfall-Realisierungen. Letztere werden
durch Pakete mit dem Stereotyp «use-case realization» dargestellt. Mit diesen
Paketen werden Sequenz- und Kollaborationsdiagramme gruppiert, welche Anwendungsfälle
auf der fachlichen Ebene realisieren.
Eine fachliche Klasse ist im Metamodell als abstrakt spezifiziert, da sie nur in Form
der folgenden Ausprägungen verwendet wird:
Eine Steuerungsklasse («control») repräsentiert eine Klasse, die einen Ablauf
steuert oder eine Berechnung durchführt. Sie modelliert eine Funktionalität, die
nicht genau an einer Klasse festgemacht werden kann. Mit dem Beginn des Anwendungsfalles
wird eine Instanz der Steuerungsklasse erzeugt. Wenn der Anwendungsfall
abgeschlossen ist, wird typischerweise auch die Instanz zerstört.
Deswegen kann eine Steuerungsklasse keine Informationen über einen längeren
Zeitraum speichern. Der Schwerpunkt einer Steuerungsklasse ist die Modellierung
von Operationen. Eine Steuerungsklasse hat Beziehungen zu anderen fachlichen
Klassen. In der Regel werden diese mit Assoziationen modelliert. So werden
z. B. zu allen Entitäten, die in der Signatur der Operationen auftauchen, Assoziationen
gezeichnet. Wenn eine Steuerungsklasse eine andere Steuerungsklasse
nutzt, wird auch eine Assoziation eingezeichnet.
Eine Boundary-Klasse («boundary») stellt eine Grenze eines Paketes oder Systems
dar; sie modelliert Schnittstellen des Systems. Eine Boundary-Klasse kennt
ihre Steuerungsklassen und Entitäten. Diese Beziehungen werden mit Assoziationen
modelliert.
Eine Entitätsklasse («entity») ist eine Klasse deren Information typischerweise
einen Anwendungsfall überdauert. Schwerpunkt ist die Modellierung der Attribute.
Lediglich die Operationen, die genau auf den Daten einer Entität operieren,
werden in der Entität spezifiziert. Soll eine Entität modelliert werden, die sich
aus mehreren Entitäten zusammensetzt, werden diese mit einer Aggregation in
Verbindung gesetzt. Lose Beziehungen zwischen Entitäten werden durch gerichtete
Assoziationen modelliert. Mit Hilfe der Generalisierungsbeziehung können
spezielle Ausprägungen von Entitäten modelliert werden.

78 UML-Profil für moCa
Fachliches Modell
Enthält ein fachliches
Paket ein weiteres
fachliches Paket, darf
es keine fachlichen
Klassen enthalten.
Enthält
0..1 0..*
Fachliches System
Fachliches Paket
0..*
Fachliche
Anwendungsfall-Realisierung
0..*
Fachliche Klasse
Steuerungsklasse Boundary Entität
Abbildung 5-3 Fachliches Metamodell
Fachliche Klassen haben Attribute und Operationen, welche die Verantwortlichkeiten
der fachlichen Klasse spezifizieren. Die Syntax einer Operation in einer fachlichen
Klasse ist im Folgenden beschrieben:
Operation ::= Sichtbarkeit Name ( Parameterliste ) [ : Rückgabetyp ]
Parameterliste ::= Parameter , …
Parameter
::= Name : Typ
Sichtbarkeit ::= + | ~ | –
Die Sichtbarkeit ist unterteilt in:
Öffentlich (+): Alle Elemente können diese Operation aufrufen.
System: Alle Elemente, die sich im gleichen System wie die fachliche Klasse befinden,
dürfen die Operation aufrufen. Diese Sichtbarkeit ist in der UML nicht
enthalten. Stattdessen wird das Symbol für die Sichtbarkeit package (~) 33 benutzt.
Privat (–): Nur die Klasse selber darf die Operation ausführen.
Der Typ sowohl für die Parameter als auch für die Rückgabe, ist entweder eine Entität,
ein für das fachliche Modell definierter elementarer Typ (vgl. Tabelle 5-1) oder
eine Aufzählung. Diese werde weiter unten genau beschrieben.
33 Rational Rose stellt diese Sichtbarkeit nicht zur Verfügung. Deswegen wird in der IZB SOFT für die
Sichtbarkeit System die Rose-Sichtbarkeit implementation verwendet.

Fachliches Modell 79
Tabelle 5-1 Elementare- und Basisdatentypen des fachlichen Modells
Datentyp Beschreibung & Einschränkungen Mögliche Werte
Ganzzahl
Ganzzahl
PositiveGanzzahl
PositiveGanzzahl
Festkommazahl
Festkommazahl
Zeichenkette
Zeichenkette
Ja/Nein-Wert
Eine positive oder negative ganze Zahl, die 0
eingeschlossen.
Die Länge n kann eingeschränkt werden.
Eine positive ganze Zahl, die 0 eingeschlossen.
Die Länge n kann eingeschränkt werden.
Eine vorzeichenbehaftete Festkommazahl.
Die Anzahl der Vorkommastellen n und Nachkommastellen
m kann eingeschränkt werden.
Eine Zeichenkette.
Die Länge n der Zeichenkette kann eingeschränkt
werden.
Ein fachlicher boolescher Wert, der entweder
»Ja« oder »Nein« sein kann.
100000;
34; 0;
-4444
30500;
0; 45
15500,00
„Paul“;
Ja;
Nein
Datum Ein Datum mit Tag, Monat und Jahr. 17.07.2003
Geldbetrag
Geldbetrag
Ein vorzeichenbehafteter Geldbetrag.
Eingeschränkt können die Vorkommastellen
n, die Nachkommastellen m und die Währung
w (lt. ISO-Norm) werden.
15, 50 EUR;
-20,00 USD
Attribute von fachlichen Klassen haben die folgende Syntax:
[ « Stereotyp » ] [ / ] + Name [ [Multiplizität] ] : Typ [ = Wert ] [ { Einschränkungen } ]
Ein Attribut kann mit folgenden Stereotypen ausgezeichnet werden:
«readonly» – Auf das Attribut kann nur lesend zugegriffen werden.
«primaryKey» – Das Attribut stellt den primären Schlüssel dar.
Berechnet ein Attribut seinen Wert aus anderen Elementen, wird es als abgeleitetes
Attribut (derived attribute) bezeichnet. Ein abgeleitetes Attribut wird mit dem Symbol
»/« gekennzeichnet. Die Vorschrift, nach der das Attribut zu berechnen ist, wird
mit einer Zusicherung spezifiziert.
Die Sichtbarkeit bei Attributen von fachlichen Klassen ist immer öffentlich (+); mit
der Multiplizität werden Arrays definiert; der Typ der Attribute wird immer spezifiziert.

80 UML-Profil für moCa
Ein Aufzählungstyp wird durch eine Klasse mit dem Stereotyp «enumeration» modelliert.
Der Name der Klasse wird mit der Endung »Enum« erweitert. Ein Aufzählungstyp
für eine Anrede könnte wie in Abbildung 5-4 modelliert werden.
«enumeration»
AnredeEnum
FRAU
HERR
Abbildung 5-4 Beispiel für die Modellierung eines Aufzählungstyps
Für jeden Aufzählungswert wird ein statisches Attribut spezifiziert. Aufzählungsklassen
kommen nur als Typen von Attributen oder Parametern von Operationen vor, d. h.
sie haben keine Beziehungen zu anderen fachlichen Klassen.
Als Namenskonvention gilt für die fachlichen Klassen: Klassen- und Beziehungsnamen
beginnen immer mit einem Großbuchstaben; Attribute, Stereotypen und Rollen
beginnen immer mit einem Kleinbuchstaben.
5.2.2 Sichten
Auf das fachliche Modell sind zwei Sichten definiert:
Statische Sicht. Klassendiagramme zeigen die fachlichen Pakete und die enthaltenen
fachlichen Klassen. Alle Beziehungen zwischen den Elementen können
dargestellt werden.
Dynamische Sicht. Sequenz- und Kollaborationsdiagramme zeigen den Ablauf
der Anwendungsfälle mit den fachlichen Klassen. Die Diagramme sind in dem
entsprechenden Anwendungsfall-Realisierungspaket zusammengefasst.
5.2.3 Beziehungen zum Anwendungsfallmetamodell
Um die Modellierung rückverfolgen zu können, werden die fachlichen Pakete, welche
einen Anwendungsfall realisieren, in Beziehung mit diesem gesetzt. Der Zusammenhang
zwischen den fachlichen Paketen und den Anwendungsfällen ist in
Abbildung 5-5 modelliert. Eine Anwendungsfall-Realisierung ist genau einem Anwendungsfall
zugeordnet. Zwischen den beiden Beziehungen herrscht eine Konsistenzbedingung:
Wenn ein fachliches Paket und eine Anwendungsfall-Realisierung
denselben Anwendungsfall realisieren, muss der erste Aufruf in der Anwendungsfall-
Realisierung auf eine fachliche Klassen gehen, die im fachlichen Paket enthalten ist.

Designmodell 81
Anwendungsfallmetamodell
Fachliches Metamodell
Realisiert
Anwendungsfall 0..* 0..1
1
0..1
Fachliches Paket
Fachliche
Anwendungsfall-Realisierung
Abbildung 5-5 Zusammenhang zwischen fachlichen Metamodellen und Anwendungsfallmetamodellen
5.3 Designmodell
Das Designmodell stellt einen Bauplan für die Implementierung dar. Die fachliche
Struktur, modelliert im fachlichen Modell, dient als Ausgangsbasis für den Entwurf in
einer konkreten, technischen Umgebung. Orientierte man sich bei der Struktur des
fachlichen Modells am Problembereich, bestimmen im Designmodell technische Aspekte
die Struktur. Das Designmodell berücksichtigt die spezifischen Einschränkungen
einer COBOL/HOST-Umgebung. Ziel ist es, nur so viel zu modellieren, dass das
Modell eindeutig implementiert werden kann. Unter Implementierung wird die Umsetzung
der Elemente des Designmodells in COBOL-Quelltext verstanden.
5.3.1 Struktur
Das Designmodell wird durch eine Paket mit dem Stereotyp «designmodell» repräsentiert.
Dieses Paket erweitert das UML-Basiselement Model. Somit stellen die Elemente
des Designmodells Teile des physischen Systems dar.
Das Designmodell enthält als Top-Level-Element das Designsystem, das durch ein
Paket mit dem Stereotyp «designsystem» repräsentiert wird. Dieses Element steht für
das zu modellierende System und stellt auch die Grenze des Systems zu seiner Umgebung
dar.
Das Designsystem enthält Anwendungsfall-Realisierungen. Eine Anwendungsfall-
Realisierung ist ein Paket mit dem Stereotyp «use-case realization»; es gruppiert beliebig
viele Sequenz- und Kollaborationsdiagramme, die einen Anwendungsfall mit
Elementen aus dem Designmodell realisieren. Der Name des Pakets besteht aus dem
Namen des zu realisierenden Anwendungsfalls und einem Anhang » – Design«. Der
Anhang kennzeichnet die Ebene; der Name ordnet die Realisierung einem Anwendungsfall
zu.

82 UML-Profil für moCa
Designmodell
0..1
Designsystem
0..*
Design
Anwendungsfall-Realisierung
Enthält eine Designeinheit
eine weitere
Designeinheit, darf sie
keine Designklassen
enthalten
0..5
Schicht
0..* 0..*
Enthält
Designeinheit
0..*
Designklasse
Designkomponente
Designpaket
IndizierteDatei
0..*
Schnittstelle
Datenstruktur
Modul
Copystrecke
Abbildung 5-6 Designmetamodell
Das Designsystem ist unterteilt in Schichten. Eine Schicht wird durch ein Paket mit
dem Stereotyp «schicht» dargestellt. 34
Eine Schicht enthält beliebig viele Designeinheiten. Eine Designeinheit ist entweder
eine Designkomponente oder ein Designpaket. Abbildung 5-6 zeigt das Metamodell,
in dem die Designeinheit als abstrakte Klasse modelliert ist. Eine Designeinheit enthält
Designklassen und darf beliebig geschachtelt werden, d. h. ein Designkomponenten
darf weitere Designkomponenten enthalten und auch Designpakete. Allerdings
besteht eine Einschränkung: Enthält eine Designeinheit eine weitere Designeinheit,
darf sie keine Designklassen enthalten.
Ein Designpaket wird durch ein Paket mit dem Stereotyp «designpaket» repräsentiert.
Es enthält entweder Module und Datenstrukturen oder weitere Designpakete und Designkomponenten.
Auf alle Elemente eines Designpaketes kann von außen zugegrif-
34 Vgl. hierzu die im Abschnitt 2.3.2 beschriebene Schichtenarchitektur. Die dort beschriebenen Konzepte,
insbesondere die Bezeichnungen der Schichten, sind zu übernehmen. Demnach enthält ein
Designsystem maximal fünf Schichten.

Designmodell 83
fen werden. Ein Designpaket exportiert alle Elemente, die es enthält, und stellt somit
ein reines Gruppierungselement dar.
Eine Designkomponenten wird repräsentiert durch ein Paket mit dem Stereotyp «designkomponente».
Die Designkomponente erweitert das UML-Basiselement Subsystem
und darf deswegen instanziiert werden. Eine Designkomponenten kann folgende
Elemente enthalten:
Designkomponenten
Designpakete
Schnittstellen
Module
Datenstrukturen
Indizierte Dateien
Die enthaltenen Schnittstellen grenzen die Designkomponente von einem Designpaket
ab. Eine Designkomponenten kapselt ihre Elemente – exportiert werden nur Schnittstellen
und öffentliche Datenstrukturen; Module werden immer gekapselt. Enthält
eine Designkomponente z. B. zwei weitere Designkomponenten, so exportiert sie die
Schnittstellen der verschachtelten Designkomponenten.
Mit einer Designeinheit als Quelle werden Abhängigkeitsbeziehungen in den folgenden
Fällen eingezeichnet:
Ein Element einer Designeinheit ruft den Dienst einer Schnittstelle auf: Abhängigkeit
von der Designeinheit zu der Schnittstelle.
Ein Element einer Designeinheit nutzt ein Element aus einer anderen Designeinheit:
Abhängigkeit von der Designeinheit zu der Designeinheit.
Eine Schnittstelle wird durch ein Interface repräsentiert, also durch eine Klasse mit
dem Stereotyp «interface».
Für die Sichtbarkeit einer Schnittstelle werden zwei Fälle unterschieden. (1) Die
Schnittstelle ist öffentlich, d. h. alle Elemente dürfen die enthaltenen Operationen aufrufen.
(2) Die Schnittstelle hat die Sichtbarkeit System 35 , d. h. die enthaltenen Operationen
dürfen nur von Elementen aus dem System aufgerufen werden, zu dem die
Schnittstelle gehört.
Hinweis.Alle Operationen einer öffentlichen Schnittstelle, die in der Steuerungssicht
liegt, stellen (nach der KBS-Begrifflichkeit) Aufträge dar.
35 Auch in diesem Fall wird in Rational Rose die Sichtbarkeit implementation gewählt. Außerdem
bietet es sich an, die Sichtbarkeit der Schnittstellen farblich zu kodieren.

84 UML-Profil für moCa
In einer Schnittstelle werden Operationen spezifiziert und die in der Signatur vorkommenden
Datenstrukturen vereinbart. Im Folgenden wird die Syntax der Operationen
beschrieben:
Operation ::= + Name ( Parameter , …) [ : Rückgabetyp ]
Parameter
Richtung
::= Richtung [ pointer ] Name : Typ
::= in | out | inout
Die Sichtbarkeit der Operationen ist immer öffentlich (+), d. h. alle Elemente dürfen
sie aufrufen.
Die Richtung spezifiziert den Parameter nach der Einteilung, die in Abschnitt 2.4.3
beschrieben ist. Durch pointer kann spezifiziert werden, dass bei der Parameterübergabe
nicht ein Wert, sondern ein Zeiger auf den spezifizierten Typ übergeben wird.
Als Typen dürfen elementare COBOL-Datentypen sowie im Modell spezifizierte Datenstrukturen
verwendet werden. In Tabelle 5-2 ist die Umwandlung der Typen aus
dem fachlichen Modell in das Designmodell beschrieben. Als Rückgabetyp steht in
der Regel eine Datenstruktur, die Informationen über den Verlauf der Ausführung
enthält (z. B. Status und Fehlernummer). Wird innerhalb eines Systems immer dieselbe
Datenstruktur als Rückgabetyp verwendet, kann der Rückgabetyp bei den Operationen
weggelassen werden. Weitere Beschreibungen, welche die Schnittstelle genauer
spezifizieren, können in textueller Form zur Schnittstelle hinzugefügt werden.
Eine indizierte Datei (indexed file) wird durch eine Klasse mit dem Stereotyp «indizierteDatei»
dargestellt. COBOL bietet verschiedene Möglichkeiten an, Daten persistent
zu speichern. Für das Fallbeispiel wurde eine indizierte Datei eingesetzt. Diese
Datei speichert eine Menge von Datensätzen ab und bietet einen indizierten Zugriff
auf die Datensätze. Die Struktur der Datensätze wird durch eine Komposition zu einer
Datenstruktur spezifiziert. Ein Modul, das eine indizierte Datei nutzt, also Datensätze
liest und schreibt, hat eine usage-Beziehung (Abhängigkeitsbeziehung) zu dieser Datei.
Eine Datenstruktur wird durch eine Klasse mit einem Stereotyp «datenstruktur» repräsentiert.
Eine Datenstruktur enthält keine Operationen, sondern nur Attribute mit der
folgenden Syntax:
[ « Stereotyp » ] [ / ] + Name [ [ Multiplizität ] ] : Typ [ = Wert ] [ { Einschränkungen } ]
Die Syntax ist also ähnlich wie bei den Attributen einer fachlichen Klasse
(vgl. Abschnitt 5.2.1).
Die folgenden Änderungen sind für Attribute einer Datenstruktur definiert: (1) Es
kommt das Stereotyp «foreignKey» hinzu. Damit wird ein Attribut als ein primärer
Schlüssel einer anderen Datenstruktur spezifiziert. (2) Ein Attribut kann wie im fachlichen
Modell als abgeleitet gekennzeichnet werden. (3) Im Gegensatz zum fachlichen

Designmodell 85
Modell hat die Multiplizität immer eine obere Schranke. (4) Als Typen dürfen elementare
COBOL-Datentypen und im Modell spezifizierte Datenstrukturen verwendet
werden. Eine alternative Darstellung eines Attributs ist die Verwendung einer Aggregation.
Mit Attributen werden nur Felder der Datenstruktur spezifiziert, die einen
Wert enthalten.
Soll ein Zeiger (ein Feld, das eine Datenstruktur referenziert) modelliert werden, wird
eine gerichtete Assoziation von der Datenstruktur des Attributes zur referenzierten
Datenstruktur gezeichnet.
Tabelle 5-2 Umwandlung der fachlichen Typen in technische Typen
Typ im fachlichen Modell
Ganzzahl
PositiveGanzzahl
Festkommazahl
Zeichenkette
Ja/Nein-Wert
Typ im Designmodell
PIC S9(n)
PIC 9(n)
PIC S9(n)V9(m)
PIC X(n)
PIC X
Mit 88-Stufennummer:
01 SCHALTER PIC X VALUE ' '.
88 SCHALTER-JA VALUE 'J'.
88 SCHALTER-NEIN VALUE 'N'.
Eine Copystrecke ist eine spezielle Datenstruktur. Sie repräsentiert eine wiederverwendbare
Datenstruktur. Eine Datenstruktur kann weiter verfeinert werden durch eine
Copystrecke.
Ein Modul wird durch eine Klasse mit dem Stereotyp «modul» repräsentiert. Ein Modul
spezifiziert und realisiert eine Menge von Operationen. Damit sowohl die Mitarbeiter
der Fachabteilung als auch die Entwickler erkennen können, welches Modul
gemeint ist, besteht der Name eines Moduls aus dem Dateinamen des Moduls (z. B.
KL1100) und einer Kurzbezeichnung der vom Modul erfüllten Funktionalität (z. B.
KundeFinder).
Die Operationen eines Moduls, das innerhalb einer Komponente liegt, sind von außen
nicht sichtbar. Deswegen kann ein Modul mit einer Realisierungs-Beziehung zu einer
Schnittstelle einen Teil seiner Operation exportieren. Mit einer Aufrufbeziehung (Abhängigkeit
mit dem Stereotyp «call») innerhalb einer Komponenten zu einem anderen

86 UML-Profil für moCa
Modul oder zu einer Schnittstelle wird spezifiziert, dass das Modul den bereitgestellten
Dienst nutzt.
Soll die Beziehung zwischen einem Modul und einer Datenstruktur modelliert werden,
sind zwei Fälle zu unterscheiden:
Die Datenstruktur liegt im Speicherbereich des Moduls (working-storage section):
Eine Aggregation vom Modul zur Datenstruktur wird eingezeichnet. Eine
Kardinalität und eine Rolle können spezifiziert werden.
Die Datenstruktur liegt nicht im Speicherbereich des Moduls (Ein Zeiger in der
working-storage section, ein Zeiger oder Feld in der linkage section): Eine
Assoziation vom Modul zur Datenstruktur wird eingezeichnet. Eine Kardinalität
und eine Rolle können spezifiziert werden.
5.3.2 Sichten
Es sind vier Sichten auf das Designmodell definiert:
Statische Komponentensicht. Klassendiagramme zeigen die Verteilung der
Funktionalität auf die Designkomponenten, deren Schnittstellen und die Abhängigkeiten
untereinander. Folgende Elemente werden dargestellt: Schichten, De-
signpakete, Designkomponenten und Schnittstellen, wobei die Schnittstellen in
der Lollipop-Notation dargestellt werden.
Dynamische Komponentensicht. Sequenz- und Kollaborationsdiagramme zeigen
wie die Anwendungsfälle mit Komponenten und Schnittstellen realisiert
werden. Die Diagramme sind in den entsprechenden Anwendungsfall-
Realisierungspaketen zusammengefasst.
Statische Modulsicht. Klassendiagramme beschreiben die Innenansicht der
Komponenten, also die Details der Schnittstellen, Module und Datenstrukturen.
Alle Elemente können dargestellt werden. Allerdings sollte nicht zuviel Information
in einem Diagramm modelliert werden.
Dynamische Modulsicht. Sequenz- und Kollaborationsdiagramme zeigen wie
die Anwendungsfälle mit Modulen realisiert werden. Die Diagramme sind in den
entsprechenden Anwendungsfall-Realisierungspaketen zusammengefasst.
5.3.3 Beziehungen zum fachlichen Metamodell
Abbildung 5-7 modelliert die Beziehungen zwischen den Elementen des Design-
Metamodells und den Elementen des fachlichen Metamodells.
Bei der Beziehung zwischen fachlichen Paketen und Designkomponenten sind nur die
elementaren fachlichen Pakete gemeint. Die Struktur der fachlichen Pakete wird ver-

Designmodell 87
worfen. Aus einem fachlichen Paket wird jeweils eine Designkomponenten in der
Steuerungs-, Geschäftslogik- und Datenzugriffsschicht. Der Entwickler hat die Möglichkeit
eine Komponente zu löschen, wenn sie nicht benötigt wird.
Steuerungsklassen werden auf Schnittstellen abgebildet. Für jede Steuerungsklasse,
die nicht private Operationen besitzt, wird eine Schnittstelle mit diesen Operationen
erstellt. Bei der Abbildung der Operationen ändert sich die Syntax, wie in den vorigen
Abschnitten beschrieben wurde. Für Steuerungsklassen mit privaten Operationen und
Entitäten mit Operationen wird jeweils ein Modul mit diesen Operationen erstellt.
Fachliches Metamodell
Designmetamodell
Fachliches Paket
0..1 0..3
0..1
Designkomponente
Realisiert
0..1
Designpaket
Fachliche Klasse
0..* 0..*
0..*
0..*
Schnittstelle
Modul
Entität
0..1 0..*
Datenstruktur
Fachliche
Anwendungsfall-Realisierung
1
0..1
Design
Anwendungsfall-Realisierung
Abbildung 5-7 Zusammenhang zwischen Designmetamodellen und fachlichen
Metamodellen
Eine Entität wird auf Datenstrukturen abgebildet. Aus einer Entität können mehrere
Datenstrukturen entstehen, z. B. könnte es aus Performance-Gründen notwendig sein,
eine Datenstruktur in mehrere Datenstrukturen zu zerlegen. Zuerst werden die fachlichen
Typen der Attribute in COBOL-spezifische Typen umgewandelt. Danach kann
die Datenstruktur mit technischen Attributen ergänzt werden.
Komplizierter wird es bei der Abbildung von mehreren, in Beziehung stehenden Entitäten.
Die Generalisierung muss aufgebrochen werden, da COBOL keinen Mechanismus
für Vererbung anbietet. Auf die Beschreibung eines Verfahrens für das Aufbrechen
der Generalisierung wird in dieser Arbeit verzichtet, da die vollständige Beschreibung
eines solchen Verfahrens sehr umfangreich wäre.

88 UML-Profil für moCa
Aus einer Aggregation zwischen zwei Entitäten wird im Designmodell eine Komposition.
Bei einer gerichteten Assoziation zwischen zwei Entitäten im fachlichen Modell
wird bei der Datenstruktur der Quelle ein Feld mit dem Primärschlüssel des Ziels eingefügt.
Dieses Feld wird mit dem Stereotyp «foreignKey» ausgezeichnet.
Ist die Kardinalität einer Beziehung im fachlichen Modell »0..*«, muss bei der Abbildung
in das Designmodell aufgrund von COBOL-Einschränkungen eine obere Grenze
definiert werden.
Die fachlichen Anwendungsfall-Realisierungen werden zu Anwendungsfall-
Realisierungen im Designmodell verfeinert.
5.4 Implementierungsmodell
Das Implementierungsmodell beschreibt wie die Konzepte des Designmodells in Dateien
und in Quelltext umgesetzt werden. Die Dateien, die COBOL zur Verfügung
stellt, sind Moduldateien und Copystrecken. Abhängigkeiten zwischen den Dateien,
die für das Kompilieren bestehen, werden spezifiziert. Gruppierungskonzepte aus dem
Designmodell werden ebenfalls in das Implementierungsmodell abgebildet, z. B. werden
die Dateien in Ordnern gruppiert. Dabei ist zu beachten, dass die Konzepte, Datei
und Ordner, in einer konkreten Entwicklungsumgebung oft andere Namen haben:
Unter Rational ClearCase 36 gibt es Dateien und Ordner.
Unter MVC 37 gibt es Members, Sequential Data-sets und Libraries.
Außerdem bietet das Implementierungsmodell eine Sicht auf den Inhalt der Quelltextdateien
an.
5.4.1 Struktur
Das Implementierungsmodell wird durch ein Paket mit dem Stereotyp «implementierungsmodell»
dargestellt. Dieses Paket erweitert das UML-Basiselement Model.
Das Implementierungsmodell besteht aus einem Paket mit dem Stereotyp «implementierungssystem»,
welches das Top-Level-Paket Implementierungssystem repräsentiert.
Das Implementierungssystem enthält Implementierungskomponenten, dargestellt
durch Pakete mit dem Stereotyp «implementierungskomponente». Diese Pakete repräsentieren
Ordner im Dateisystem.
Eine Komponente gruppiert Dateien, dargestellt durch Klassen mit dem Stereotyp
«datei». Es gibt zwei spezielle Dateien: die Moduldatei («moduldatei») und die Co-
36 Rational ClearCase ist ein Werkzeug für die Versionsverwaltung von Dokumenten.
37 MVC ist ein Betriebssystem für IBM-Großrechner und steht für Multiple Virtual Storage.

Implementierungsmodell 89
pystreckedatei («copystreckedatei»). Die Moduldatei repräsentiert eine Datei, die den
Quelltext eines Moduls enthält; die Copystreckedatei repräsentiert eine Datei, die den
Quelltext einer Copystrecke enthält. Die einzige Art der Beziehung zwischen Elemente
des Implementierungsmodells ist die Abhängigkeitsbeziehung.
Implementierungsmodell
0..1
Implementierungssystem
0..*
Implementierungskomponente
0..*
Datei
Moduldatei
Copystreckedatei
Abbildung 5-8 Implementierungsmetamodell
5.4.2 Sichten
Auf das Implementierungsmodell sind zwei Sichten definiert:
Dateisicht. Mehrere Klassendiagramme zeigen die Implementierungskomponenten
mit den enthaltenen Dateien und die Abhängigkeiten untereinander.
Quelltextsicht. Zeigt den Inhalt der Quelltextdateien, also die COBOL-Implementierung
der Anwendung, an.
5.4.3 Beziehungen zum Designmetamodell
Der Zusammenhang zwischen den Elementen der Metamodelle ist in Abbildung 5-9
modelliert. Aus einem Designpaket oder einer Designkomponente wird eine Implementierungskomponente
mit demselben Namen. Aus einem Modul wird eine Moduldatei,
allerdings wird als Name nur noch die Modulnummer verwendet. Auch bei der
Abbildung einer Copystrecke in die Copystreckedatei wird nur noch die Nummer als
Name verwendet. Aus einer Indizierten Datei wird eine Datei. Die Umsetzung der

90 UML-Profil für moCa
Elemente des Designmodells nach COBOL-Quelltext ist im Abschnitt 4.5.2 beschrieben.
Designmetamodell
Implementierungsmetamodell
Designpaket
Designkomponente
Modul
Copystrecke
0..1
1
0..1 1
0..1 1
Realisiert
0..1 1
Implementierungskomponente
Moduldatei
Copystreckedatei
IndizierteDatei
0..1 1
Datei
Abbildung 5-9 Zusammenhang zwischen Implementierungsmetamodellen
und Designmetamodellen

6 Zusammenfassung und Ausblick
Die IZB SOFT entwickelt Anwendungen für Bank- und Kreditinstitute. Die Architektur
der Anwendungen besteht aus Terminals, denen von einem Großrechner Dienste
zur Verfügung gestellt werden. Diese Dienste sind vorwiegend in COBOL realisiert.
Da die Programmiersprache COBOL keine Mechanismen anbietet, um Software auf
der Basis von Komponenten zu entwickeln, ist es erst durch den Einsatz von Modellen
möglich, Komponenten – wenn auch nur logisch – zu bilden. Die Modelle modellieren
die Anwendungen auf verschiedenen Abstraktionsebenen. Dabei treten die typischen
Probleme der Softwareentwicklung auf: Die Systeme sind sehr komplex und
Flexibilität ist eine Schlüsselanforderung.
Um die große Menge an Information und deren Komplexität kontrollieren zu können,
wird eine modellbasierte Entwicklungsmethodik eingesetzt. Diese Methodik ist in den
iterativen und architekturzentrierten Entwicklungsprozess der IZB SOFT eingebettet.
Jedoch kommt es zu Brüchen in der Entwicklung: Da die Übergänge zwischen den
Modellen unzureichend definiert sind, kann die Konsistenz der Modelle nicht sichergestellt
werden. Darüber hinaus besteht die Gefahr, dass wichtige Designentscheidungen
während der Entwicklung verloren gehen.
In dieser Arbeit wurde eine durchgängige Methodik geschaffen, um COBOL-
Anwendungen für Großrechner modellbasiert zu entwickeln. Die Methodik ist eine
Weiterentwicklung des bisherigen Vorgehens der IZB SOFT und wurde auf Grundlage
der firmeninternen Standards konzipiert. Dabei war eine der Zielsetzungen, die
Methodik einfach zu halten und so wenige Änderungen wie möglich an den Standards
vorzunehmen. Die wesentlichsten Ergebnisse sind im Folgenden zusammengefasst.
Um die Kluft zwischen den Mitarbeitern der Fachabteilung und den Entwicklern zu
schließen, wurde die Begrifflichkeit des fachlichen Modells, mit beiden Parteien abgestimmt.
Die genaue Definition des Metamodells sowie der methodische Übergang
in das Designmodell ermöglicht den Entwicklern die bereits modellierte Fachlichkeit
als Grundlage für ihre technischen Entwürfe zu nutzen. So wurden z. B. die Beziehungen
der fachlichen Klassen in einer Art und Weise gestaltet, dass die Entwickler
eine Struktur erkennen, die sich technisch umsetzen lässt.
Das Designmodell, der Bauplan der Implementierung, wurde im Bezug auf den Abstraktionsgrad
näher zum COBOL-Quelltext gebracht. Dadurch ist es für die Entwickler
leichter ihren Quelltext im Modell »wieder zu finden«. Durch die Einführung der
Datenstrukturen und die Veränderung der Semantik der Copystrecken ist es jetzt mög-
91

92 Zusammenfassung und Ausblick
lich, die Schnittstellen der Komponenten, also die Signatur und die zugehörigen
Datenstrukturen, präzise zu modellieren.
Außerdem hat sich die Informationsverteilung geändert: Das Implementierungsmodell
ist »entkernt« worden, d. h. Konzepte des Implementierungsmodell sind in das Designmodell
verschoben worden. Die Komponenten erhalten somit eine Innenansicht,
welche die Funktion erfüllt, die bisher das Implementierungsmodell eingenommen
hat. Somit wurde eine Grundlage geschaffen, die Anwendung auf der Designebene
vollständig zu spezifizieren. Insbesondere haben die »Entkernung« des Implementierungsmodells
sowie die dadurch entstandene Verteilung der Information, die Navigierbarkeit
und Pflege der Modelle innerhalb der CASE-Werkzeuge erheblich verbessert.
Das Implementierungsmodell ist nun methodisch aus dem Designmodell ableitbar,
da es nur noch die Elemente des Dateisystems, also die Dateien und Ordner, modelliert.
Dadurch ist es leicht möglich, weitere Modelle, wie z. B. ein Laufzeit- oder
Verteilungsmodell, auf der Grundlage des Implementierungsmodells zu definieren.
Ein Schlüsselergebnis ist der direkte methodische Übergang vom Designmodell zum
COBOL-Quelltext. Auf der Basis dieses Verfahrens können in Zukunft Programmrahmen
aus den Modellen automatisch generiert werden.
Die neue Methodik wurde sowohl an einem projektnahen Fallbeispiel, als auch an
weiteren Beispielen erprobt. Dadurch wurden die Praxistauglichkeit und die Durchgängigkeit
des Vorgehens unter Beweis gestellt. Bisher ist die Methodik den Anforderungen
gerecht geworden – die Bewährung im täglichen Einsatz, bei großen Anwendungen,
steht noch aus. Ebenfalls sollte die bisher unzureichend behandelte Übertragung
der Generalisierung aus dem fachlichen Modell in das Designmodell genauer
untersucht werden.
Da es jetzt möglich ist, eine COBOL-Anwendung von der Vision bis hin zum Quelltext
modellbasiert zu entwickeln, stehen folgende Schritte an:
1) Die Einführung der Methodik in die Abteilungen der IZB SOFT. Da Teile der Arbeit
in den neuen Unternehmensstandard einfließen, ist es notwendig, sich ein Konzept
zu überlegen, wie die Inhalte in die Abteilungen gebracht werden können.
2) Erstellung eines Konzepts zur Implementierung der Methodik. Die Metamodelle
zusammen mit dem systematischen Vorgehen können als Basis für verschiedene
Werkzeuge dienen. Bei einem modellbasierten Vorgehen ist der Einsatz von Werkzeugen
entscheidend für die Qualität und die Effizienz des Vorgehens. Es wäre z. B.
denkbar, ein Werkzeug zu entwickeln, welches aus dem fachlichen Modell eine erste
Version des Designmodells ableitet, sowie ein Werkzeug, das die Elemente Entität,
Datenstruktur, COBOL-Quelltext auf den verschiedenen Ebenen konsistent hält. Außerdem
wäre es leicht möglich, ein Werkzeug zu bauen, mit dem COBOL-Quelltext-
Rahmen aus einem Designmodell erzeugt werden kann. Ein weiteres Einsatzgebiet
wäre die Umsetzung von Reverse Engineering. Das Vorgehen definiert bereits einen

93
großen Teil der Rückverfolgbarkeit. Somit wäre es relativ einfach, ein Werkzeug zu
implementieren, das aus einem bestehenden COBOL-Quelltext ein Implementierungsmodell
erstellt, sowie die Abhängigkeiten zwischen den Elementen modelliert.
Schwieriger, aber ebenso machbar, wäre die automatische Erstellung des Designmodells
aus dem COBOL-Quelltext. Die Dateien, welche Copystrecken enthalten, könnten
gescannt und daraus die entsprechenden Copystrecken und Datenstrukturen des
Designmodells abgeleitet werden. Aus den Moduldateien ließen sich die logischen
Module und ihre Aufrufe folgern. Außerdem wäre es auch möglich, die Beziehungen
zwischen Modulen und den Datenstrukturen zu bestimmen.
3) Schließlich könnten die Werkzeuge in eine Entwicklungsumgebung integriert werden.
Eine solche Umgebung, welche die Entwickler entlastet und die Effizienz des
Entwicklungsprozesses steigert, wäre ein Mittel, um die Qualität und Flexibilität der
COBOL-Anwendungen noch weiter zu verbessern.

Literatur
[Booch]
[Brown]
[Bruegge]
[Budlong]
[Buschmann]
[Clements]
[Cockburn]
[Fowler]
[Goos]
Grady Booch. Object-Oriented Analysis and Design with Applications.
Zweite Ausgabe. Redwood City, California: The Benjamin/Cummings
Publishing Company, Inc, 1994.
Gary Brown. „COBOL: The Failure That Wasn’t“. (Mai 2000). Internet:
www.CobolReport.com.
Bernd Bruegge und Allen H. Dutoit. Object-Oriented Software Engineering:
Conquering Complex and Changing Systems. New Jersey:
Prentice-Hall, 2000.
Mo Budlong. Sams Teach Yourself COBOL in 21 Days. Dritte Auflage.
Indianapolis: Sams Publishing, 2000.
Frank Buschmann et al. Pattern-Oriented Software Architecture: A
System of Patterns. Chichester: John Wiley & Sons, 1996.
Paul Clements et al. Documenting Software Architectures: Views and
Beyond. Boston: Addison-Wesley, 2003.
Alistair Cockburn. Writing Effective Use Cases. New York: Addison-
Wesley, 2001.
Martin Fowler. UML Distilled: A Brief Guide to the Standard Object
Modeling Language. Zweite Ausgabe. Reading, Massachusetts: Addison-Wesley,
2000.
Gerhard Goos. Vorlesungen über Informatik. Band 2. Zweite Auflage.
Berlin: Springer-Verlag, 1999.
[Hopkins] Jon Hopkins. „Component Primer“. Communications of the ACM 43
(10): 27–30 (2000).
[IZB 2002a]
Informatik Zentrum Bayern (IZB SOFT). „Anforderungsanalyse“. (Version
1.3, Interner Standard, Dezember 2002).
[IZB 2002b] ———. „Anwendungsarchitektur Rahmenbedingungen“. (Version 1.5,
Interner Standard, Dezember 2002).
[IZB 2002c]
———. „Fachliche Modellierung“. (Version 1.1, Interner Standard,
Dezember 2002).

96 Literatur
[IZB 2002d]
———. „Programmierrichtlinien COBOL“. (Version 2.4, Interner Standard,
Dezember 2002).
[IZB 2003a] ———. „Modellierung“. (Version 0.9, Internes Dokument, PROFil 3.0
Technische Rahmenbedingungen, 407.279, April 2003).
[IZB 2003b]
[IZB 2003c]
[Jacobson1992]
[Jacobson1999]
[Kobryn]
[Kruchten]
[Menendez]
[Nobe]
[OMG]
[Rechenberg]
[Schätz]
———. „Systembereitstellungsprozess“. (Version 3.1, Interner Standard,
Januar 2003).
———. „Technische Modellierung“. (Version 1.2, Interner Standard,
April 2003).
Ivar Jacobson et al. Object-Oriented Software Engineering: A Use Case
Driven Approach. New York: ACM Press, 1992.
Ivar Jacobson, Grady Booch und James Rumbaugh. The Unified Software
Development Process. Reading, Massachusetts: Addison-Wesley,
1999.
Cris Kobryn. „Modeling Components and Frameworks with UML“.
Communications of the ACM 43 (10): 31–38 (2000).
Philippe Kruchten. „The 4+1 View Model of Architecture“. IEEE Software
12 (6): 42–50 (1995).
Raul Menendez und Doug Lowe. Murach’s CICS for the COBOL Programmer.
Fresno, California: Mike Murach & Associates, 2001.
Catherine R. Nobe et al. „Modellbasierte Entwicklung: Fünf von Boeing
eingesetzte Prozesse“. OnTime. (Spezialdruck, Modellbasierte Software-Entwicklung,
2002). Internet: http://www.ontime.nu.
Object Management Group. „OMG Unified Modeling Language Specification“.
(Version 1.5, formal/03-03-01, März 2003).
Peter Rechenberg und Gustav Pomberger (Hrsg.). Informatik-
Handbuch. München: Carl Hanser Verlag, 1997.
Bernhard Schätz et al. „Model-Based Development“. (Forschungsbericht
TUM-I0204, Fakultät für Informatik, TU München, Mai 2002).