Erweiterung objektorientierter Methoden für den konzeptuellen

Erweiterung objektorientierter Methoden für den konzeptuellen
Erweiterung objektorientierter Methoden
für den konzeptuellen Datenbankentwurf
Diplomarbeit
der philosophisch-naturwissenschaftlichen Fakultät
der Universität Bern
vorgelegt von
Benno Burkhardt, 91-108-225
1997
Leiter der Arbeit:
Dr. Andreas Geppert
Institut für Informatik der Universität Zürich
Prof. Dr. Oscar Nierstrasz
Institut für angewandte Mathematik der Universität Bern
„The amateur software engineer is always in search of magic, some sensational
method or tool whose application promises to render software development
trivial. It is the mark of the professional software engineer to know that no such
panacea exists. Amateurs often want to follow cookbook steps; professionals
know that right approaches to development usually lead to inept design products,
born of a progression of lies, and behind which developers can shield themselves
from accepting responsibility for earlier misguided decisions. The amateur
software engineer either ignores worrying more about the substance they contain.
The professional acknowledges the importance of creating certain documents, but
never does so at the expense of making sensible architectural innovations.“
[Booch 94, p. 229]
Vorwort
Die vorliegende Diplomarbeit wurde von der Gruppe „Objektorientierte
Datenbanken“ am Institut für Informatik der Universität Zürich wie folgt
ausgeschrieben:
Erweiterung objektorientierter Methoden für den konzeptuellen
Datenbankentwurf
Konzeptueller Entwurf ist eine gut verstandene Aktivität in der Entwicklung
relationaler Datenbankanwendungen. Für objektorientierte Datenbanksysteme ist
dies nicht der Fall, da bei in der Praxis verwendeten Entwurfsverfahren wie Booch
oder OMT einige notwendige Entwurfskonstrukte und -richtlinien nicht
unterstützt werden. Die Verwendung typischer objektorientierter
Entwurfsverfahren ist somit in der Regel für die objektorientierten
Datenbanksysteme nicht zufriedenstellend.
Ausgehend von einem objektorientierten Verfahren (z.B. Booch), sind
Schwachstellen zu bestimmen und durch angemessene Entwurfskonstrukte zu
beseitigen. Schliesslich soll ein grafisches Entwurfswerkzeug um diese neuen
Entwurfskonstrukte erweitert werden.
Die Arbeit bietet die Möglichkeit, mit aktuellen und praxisrelevanten Aspekten
der Datenbanktechnologie vertraut zu werden. Die Arbeit wird in Kooperation mit
Wirtschaftspartnern bei der CSS-Versicherung (Luzern) durchgeführt.
Im Bereich des Datenbankentwurfes wurden bereits viele
Forschungsanstrengungen unternommen. Die Arbeiten beziehen sich aber
meistens auf das relationale Modell, oder führen komplett neue Methoden ein
(vgl. [Kappel et. al. 91a]), die aber aufgrund von fehlenden Implementationen in
der Praxis nicht angewendet werden. Häufig besitzen Entwerfer bereits
Erfahrungen im Umgang mit objektorientierten Entwurfsmethoden, weshalb sie
nicht besonders gewillt sind, eine komplett neue Methodik zu erlernen. Vielmehr
erwarten sie, dass sich neue technologische Aspekte auch in entsprechenden
Konstrukten in der von ihnen eingesetzten Entwurfsmethode nierderschlagen.
Die gängigen Methoden jedoch unterstützen keine der datenbankspezifischen
Aspekte des Entwurfes und wenn, dann legen sie das relationale Modell zugrunde.
Damit findet man in der Industrie häufig die Situation, dass die Systementwickler
eine objektorientierte Methode für den Applikationsentwurf und für den
Datenbankentwurf anwenden, aber bezüglich des Entwurfes der
datenbankspezifischen Aspekte wie persistente Objekte, Transaktionensentwurf
und Konsistenzsicherung, Objekt- und Schemaevolution allein gelassen sind.
Es macht daher Sinn, bestehende und akzeptierte Entwurfsmethoden zu erweitern,
damit mit ihnen auch die Spezifika des Datenbankentwurfes berücksichtigt
werden können.
Für die Erreichung des in der Diplomarbeit gesteckten Ziels einer derartigen
Erweiterung einer bestimmten Methode für den konzeptuellen Datenbankentwurf
musste das Problem in die folgenden Teilprobleme unterteilt werden:
Teil I: Erweiterung des konzeptuellen Datenbankentwurfes:
1. Auswahl einer bestimmten Entwurfsmethode.
2. Auswahl einer bestimmten Datenbankimplementierung.
3. Analyse der Schwachstellen der gewählten Entwurfsmethode bei deren
Anwendung für den konzeptuellen Datenbankentwurf.
Diplomarbeit
Vorwort • i
4. Abgleich der gefundenen Schwachstellen mit den in der Literatur erwähnten
und in der Parxis aufgetretenen Unzulänglichkeiten.
5. Auswahl verschiedener Schwachstellen (Evaluation) anhand forschungs- und
praxisrelevanter Kriterien (Fallstudien und Projekte der CSS-Versicherung).
6. Erweiterung der ausgewählten Entwurfsmethode (Anpassung bestehender oder
Einführung neuer Konstrukte, Formulierung von Richtlinien für deren
Verwendung).
7. Bewertung der Ergebnisse (inwiefern konnten die Schwachstellen beseitigt
werden?).
8. Anwendung der erweiterten Methode auf die in der Analyse verwendeten
Fallstudien.
Teil II: Implementation der Erweiterungen:
1. Erweiterung eines bestehenden Zeichnungswerkzeuges für den
softwaregestützten Entwurfsprozess.
2. Definition eines Umsetzungskonzeptes (wie können die Konstrukte der
grafischen Entwurfssprache in das gewählte Datenschema abgebildet werden?).
3. Implementation eines Übersetzers, welcher die gezeichneten Diagramme in
eine konkrete Schemadefinitionssprache überträgt.
Die Arbeit wurde als eine herausfordernde Aufgabe angesehen. Trotz der grossen
Anzahl von Papieren, die zu diesem Thema geschrieben wurden, blieb ein
befriedigendes und vor allem in der Praxis anwendbares Resultat noch
ausstehend. Dennoch ist davon ausgegangen worden, dass im Rahmen dieser
Diplomarbeit einiges erreicht werden kann.
ii • Vorwort
Diplomarbeit
Die Betreuung wurde von Dr. Andreas Geppert, Oberassistent am Institut für
Informatik der Universität Zürich, Andreas Behm, Assistent am Institut für
Informatik der Universität Zürich, und Prof. Nierstrasz, Professor am Institut für
angewandte Mathematik der Universität Bern übernommen, wofür ich mich an
dieser Stelle noch einmal ausdrücklich bedanken möchte.
Im weiteren konnte ich während meiner Arbeit von der grossen praktischen
Erfahrung von Herrn Thomas Wüst, ehemaliger Assistent am Institut für
Informatik der Universität Zürich und heutiger Mitarbeiter der CSS Versicherung
mit der Entwicklung von grossen auf objektorientierten Datenbanksystemen
basierenden Informationssystemen betraut, profitieren.
Zudem sei erwähnt dass die Unterstützung der „Software Composition Group“ am
Institut für angewandte Mathematik der Universität Bern durch ihr Feedback viel
zu dieser Arbeit beigetragen hat.
Mein Dank gilt aber auch der Firma TeTrade (Informatik) AG, insbesondere aber
Michael Liebi, Roberto Liviero und René Ritter, für die Nutzung der Infrastruktur
und Andreas Münger, Jean-Luc Nottaris, für die fachlichen und Eva Burkhardt
und Dolores Denaro für die sprachlichen Korrekturlesungen.
Diplomarbeit
Vorwort • iii
Inhaltsverzeichnis
1 Einleitung 1
1.1 Objektorientierte Methoden
1
1.1.1 Objektorientierung 1
1.1.2 Entwurf
2
1.2 Objektorientierte Entwurfsmethoden
3
1.2.1 Objektorientierte Softwareentwicklung 3
1.2.2 Übersicht der objektorientierten Analyse- und Entwurfsmethoden 3
1.2.3 Probleme mit objektorientierten Entwurfsmethoden
5
1.3 Objektorientierte Datenbanken 7
1.3.1 Konzepte von Datenbanksystemen
7
1.3.2 Erweiterte Anforderungen
8
1.3.3 Objektorientierte Datenbanksysteme 8
1.3.4 Ein Standard für objektorientierte Datenbanksysteme
11
1.3.5 Aktuelle Implementierungen 18
1.3.6 Stand der Technik 21
1.3.7 Nutzen von objektorientierten Datenbanksystemen
22
1.4 Konklusion: Objektorientierter Datenbankentwurf 22
1.4.1 Objektorientierte Analyse und objektorientierter Entwurf 23
TEIL I 25
Auswahl der Entwurfsmethode
Auswahl des Datenbanksystems
26
26
2 Die Methode von Booch
29
2.1 Einleitung
29
2.2 Die Notation 29
2.2.1 Die Elemente der Notation 30
2.2.2 Klassendiagramme 32
2.2.3 Zustandsübergangsdiagramme37
2.2.4 Objektdiagramme 39
2.2.5 Interaktionsdiagramme
40
2.2.6 Moduldiagramme 41
2.2.7 Prozessdiagramme 42
2.2.8 Anwendung der Notation
42
2.3 Das Vorgehen
43
2.3.1 Mikroentwicklungsprozess 44
2.3.2 Makroentwicklungsprozess 45
3 Schwachstellenanalyse
47
3.1 Einleitung
47
3.1.1 Typisierung
48
3.2 Schwachstellen auf logischer Ebene
49
3.2.1 Aggregation
49
3.2.2 Überladung
49
3.2.3 Konstruktoren und Destruktoren
49
3.2.4 Weitere Schwachstellen
50
3.3 Schwachstellen auf konzeptueller Ebene 50
3.3.1 Persistenz
50
3.3.2 Applikationsklassen und -instanzen
51
3.3.3 Transaktionen
53
3.3.4 Weitere Schwachstellen
54
3.4 Vermisste Konstrukte 55
3.4.1 Inverse Beziehungen 55
3.4.2 Extensionen und Schlüssel 57
3.4.3 Fortpflanzung und Konsistenzsicherung
3.4.4 Objektevolution
62
3.4.5 Schemaevolution
64
3.4.6 Sichtenkonzept
65
Diplomarbeit
58
Inhaltsverzeichnis • v
3.5 Weitere Schwachstellen
66
3.5.1 Abfragen auf NULL-Werten 66
3.6 Evaluation 67
3.6.1 Schwachstelle auf logischer Ebene
68
3.6.2 Schwachstellen auf der konzeptuellen Ebene
3.6.3 Vermisste Konstrukte
68
3.6.4 Weiteres Vorgehen 69
4 DEIMOS
68
71
4.1 Einleitung
71
4.1.1 Unterschiede zu der Methode von Booch
71
4.1.2 Das Beispiel FIS
72
4.2 Das Schemadiagramm 73
4.2.1 Klassen
73
4.2.2 Beziehungen
75
4.2.3 Datenbankklassen 76
4.2.4 Hilfsklassen
77
4.2.5 Vererbungsbeziehung
78
4.2.6 Abstrakte Klassen 79
4.2.7 Objekte
80
4.2.8 Instantiierungsbeziehung
81
4.2.9 Komponentenbeziehung
83
4.2.10 Inverse Beziehung 88
4.2.11 Beobachtungsbeziehung
90
4.2.12 Objektevolution
92
4.2.13 Notizen
96
4.2.14 Zusammenfassung Beispiel FIS
96
4.3 Das Transaktionsdiagramm
97
4.3.1 Subsystemdiagramm 98
4.3.2 Transaktionsdiagramm
98
4.3.3 Konstrukte
99
4.4 Verwendungsrichtlinien
102
4.4.1 Verwendung der Konstrukte eines Schemadiagramms
103
4.4.2 Verwendung der Konstrukte eines Transaktionsdiagramms
4.4.3 Transaktionsentwurf 109
4.4.4 Fortpflanzung und Konsistenzsicherung
112
4.5 Bewertung der Methode
115
4.5.1 Persistenz
115
4.5.2 Fortpflanzung und Konsistenzsicherung
116
4.5.3 Extensionen und Schlüssel 117
4.5.4 Objektevolution
118
4.5.5 Inverse Beziehungen 118
4.5.6 Transaktionen
119
4.5.7 Applikationen
120
4.5.8 Zusammenfassung 121
TEIL II
107
123
Auswahl des Zeichenwerkzeuges 124
Auswahl der Entwicklungsumgebung
124
5 OSWOOD 125
5.1 Einleitung
125
5.1.1 Die Aufgabe von OSWOOD 125
5.1.2 Starten von OSWOOD
126
5.2 Schemaentwurf mit Hardy
128
5.2.1 Arbeiten mit Hardy 128
5.2.2 Schemaentwurf mit Hardy
129
5.2.3 Schemaentwurf mit DEIMOS 130
5.2.4 Erstellen eines Kontextdiagramms
130
5.2.5 Erstellen eines Schemadiagramms
133
5.2.6 Erstellen eines Transaktionsdiagramms 137
vi • Inhaltsverzeichnis
Diplomarbeit
5.3 Code generieren mit OSWOOD 140
5.3.1 Anzeige der Indexdatei
140
5.3.2 Anzeige des Schemadiagramms
142
5.3.3 Anzeigen eines Transaktionsdiagramms
148
5.3.4 Schemaevolution
149
5.3.5 Umsetzen in ODL 150
5.3.6 Importieren der generierten O2C-Dateien in O2 151
5.4 Bewertung der Arbeit mit OSWOOD
152
6 Umsetzung 153
6.1 Einleitung
153
6.2 Umsetzung eines Schemadiagramms
153
6.2.1 Umsetzung der Knoten
154
6.2.2 Umsetzung der Kanten
162
6.3 Umsetzung eines Transaktionsdiagramms
6.3.1 Umsetzung der Knoten
176
6.3.2 Umsetzung der Kanten
184
6.4 Bewertung der Umsetzung
185
6.4.1 Erzeugen von Instanzen
185
6.4.2 Löschen von Instanzen
186
6.4.3 Fazit
187
7 Implementation
175
189
7.1 Einleitung
189
7.1.1 Werkzeuge
189
7.2 Umsetzung einer Hardydatei 190
7.2.1 Dateiformat
190
7.2.2 Klassendiagramm 191
7.2.3 Lesen einer Hardydatei
193
7.3 Umsetzung der Indexdatei
194
7.3.1 Die Indexdatei als Input
194
7.3.2 Klassendiagramm 195
7.3.3 Lesen der Indexdatei 196
7.4 Umsetzung der Schemadiagrammdatei 197
7.4.1 Die Schemadiagrammdatei als Input 197
7.4.2 Ablaufbeschreibung 198
7.4.3 Einbettung
199
7.4.4 Lesen der Schemadiagrammdatei
202
7.4.5 Validierungen
213
7.4.6 Die Graphklassen 213
7.4.7 Aufbau des Vererbungsgraphen
217
7.4.8 Aufbau des Komponentenbaumes
222
7.4.9 Umsetzen der Kanten in Beziehungen 224
7.4.10 Erzeugung der Klassendefinitionen und Methodenimplementierungen
7.4.11 Schreiben der ODL-Datei 232
7.5 Umsetzen eines Transaktionsdiagramms 234
7.5.1 Die Transaktionsdiagrammdatei als Input
234
7.5.2 Ablaufbeschreibung 235
7.5.3 Einbettung
235
7.5.4 Lesen der Transaktionsdiagrammdatei 237
7.5.5 Validierungen
240
7.5.6 Aufbau der Aufrufhierarchie 241
7.5.7 Aufbau der Subsystemhierarchie
243
7.5.8 Erzeugung der Implementierungen
244
7.5.9 Schreiben der ODL-Datei
244
7.6 Bewertung der Implementation 245
7.6.1 Bekannte Probleme in OSWOOD
246
7.6.2 Mögliche Erweiterungen
247
7.6.3 Fazit
248
ANHÄNGE
Diplomarbeit
232
FEHLER! TEXTMARKE NICHT DEFINIERT.
Inhaltsverzeichnis • vii
Unified Modeling Language (UML)
267
Einleitung
267
Geschichte von UML
267
Booch, Rumbaugh und Jacobsen vereinen ihre Kräfte 268
Zukunft von UML
269
Was ist UML? 269
Unterschiede zu Booch 271
Implikationen für DEIMOS
272
Anpassungen an DEIMOS für die Konsistenz zur UML
Schemadiagramme
273
Transaktionsdiagramme 275
Installation
273
277
Installation von Hardy vom Internet277
Installation auf Windows 95
277
Registrierung
279
Installation von Hardy mit der beiliegenden Diskette 280
Installation von OSWOOD
281
Die Symbolbibliotheken von DEIMOS
281
Installation von OSWOOD
282
Notation
283
Schemadiagramm283
Knoten
Kanten
Transaktionsdiagramm
Knoten
Kanten
283
284
284
284
285
Glossar
287
Literaturverzeichnis 291
Referenzierte
291
Literatur
Dokumentationen
Weitere
293
Literatur
Dokumentationen
291
293
293
294
Verzeichnisse 295
Abbildungen
295
Tabellen
295
Listings
296
Syntaxdiagramme
Klassendiagramme
Klassenbeschreibungen
298
299
299
Index 301
viii • Inhaltsverzeichnis
Diplomarbeit
1 Einleitung
1.1 Objektorientierte Methoden
Wegen der Allgemeinheit des Wortes „Objekt“ läuft auch der Begriff
„objektorientiert“ Gefahr, bei unvorsichtiger Verwendung zu einem
Allgemeinplatz zu verkommen. Besonders gilt es zu beachten, dass ein
Objekt im nachfolgend skizzierten Sinn als technisches Konzept zu
verstehen ist, mit dessen Hilfe die diskutierte Umwelt modelliert werden
kann. Es ist daher strikt von den „Objekten“ der betrachteten Umwelt
selber abzugrenzen, obwohl man natürlich hofft eben diese so genau wie
möglich auf die Systemobjekte abbilden zu können.
1.1.1 Objektorientierung
Identität und
Schnittstelle
Ausgehend vom Konstrukt der abstrakten Datentypen schafft die
Objektorientierung einen Rahmen um die Daten und die für sie
definierten Operationen und fasst diese unter dem Begriff des Objektes
zusammen. Ein derartiges Objekt ist anschliessend von aussen nur über
dessen eindeutige Identität und dessen Schnittstelle sichtbar.
Diese Eigenschaft kann durch folgende drei Grundprinzipien
beschrieben werden:
Abstraktion und
Autonomie
1. Abstraktion und Autonomie: Ein Objekt besitzt eine
wohlunterscheidbare Identität, einen inneren Zustand und eine
Anzahl von Meldungen, über welche mit dem Objekt
kommuniziert werden kann. Der Zustand ist durch eine
Datenstruktur modelliert. Die Meldungen bilden die
Schnittstellen zum Objekt und sind intern als Methoden, also
Programmfunktionen implementiert.
Klassifikation
2. Klassifikation: Häufig trifft man Objekte, die sich hinsichtlich
ihres Verhaltens nicht unterscheiden, wohl aber hinsichtlich
ihres internen Zustandes. Derartige Objekte lassen sich in
Objektklassen zusammenfassen. Einzelne Objekte werden
alsdann als unterscheidbare Instanzen einer solchen Klasse
betrachtet.
Taxonomie
Diplomarbeit
3. Taxonomie: In vielen Fällen sind sich Instanzen zweier
Klassen soweit ähnlich, als die einen sämtliche Eigenschaften
der anderen besitzen und darüber hinaus noch über weitere
speziellere Eigenschaften verfügen. Auf diese Weise lassen
sich Klassenhierarchien bilden, indem man aus Basisklassen
durch Vererbung neue Klassen erhält, die als Spezialisierungen
gesehen werden können.
Zur Verwendung eines Objektes muss also lediglich die
Schnittstelle zu ihm bekannt sein (syntaktisch und semantisch).
Der Zustand des Objektes ist also nur dem Objekt selber bekannt
und ist von aussen nicht oder nicht direkt ersichtlich. Diese
Eigenschaft wird auch als Abstraktion oder Kapselung verstanden.
Dem Prinzip der Abstraktion und Autonomie steht keineswegs
entgegen, dass ein Objekt seinerseits Meldungen an andere Objekte
Einleitung • 1
verschickt, also Teile seines Verhaltens durch das Verhalten
anderer Objekte abstützt. Damit entstehen Assoziationen zwischen
Objekten, oder anders gesagt: Objektstrukturen.
Verschiedentlich, aber nicht zwangsläufig, wird die Klasse auch als
Extension, also als die Gesamtheit der tatsächlich existierenden
Instanzen einer Klasse betrachtet, welche selber wieder als Objekt
angesehen werden kann.
Vererbung und
Mehrfachvererbung
Der Begriff der Taxionomie kann auch Vererbung genannt werden, wenn
man berücksichtigt, dass eine Unterklasse von ihrer Oberklasse alle
Eigenschaften übernimmt oder erbt. Neben der einfachen Vererbung ist
auch das Konstrukt der mehrfachen Vererbung anzutreffen, jedoch
unterscheiden sich die verschiedenen Implementierungen in diesem
Bereich konzeptuell zuweilen erheblich.
1.1.2 Entwurf
Klassierung
Die Darstellung von Entwurfsentscheidungen in einem objektorientierten
System läuft häufig nicht in derselben Reihenfolge wie der zu
grundeliegende Erkenntnisprozess ab. So betrachtet man in der Umwelt
Objekte als Instanzen von Klassen, während man im Entwurf anhand von
beobachteten konkreten Objekten eine Klassierung herausdestilliert.
natürliche
Modellierung
Die Vorteile, die man sich von der Verwendung von objektorientierten
Paradigmen verspricht, liegen vor allem in der Chance, eine gegebene
Umwelt natürlich modellieren zu können, da die in dieser Umwelt
betrachteten Sachverhalte als Objekte im Softwaresystem dargestellt
werden können.
kapseln von
Zuständen und
Eigenschaften
Im weiteren hat man die beklagenswerte „künstliche“ Trennung von
Daten und Funktionen soweit überwunden, als dass man sowohl
Zustände als auch Eigenschaften in einem Objekt kapseln kann. Das
Verhalten ist somit weitgehend von der Instanz selber festgelegt. Darüber
hinaus erwächst dem Entwerfer der Vorteil, lediglich die semantisch
sinnvollen Operationen für das Objekt von aussen sichtbar zu machen
und somit die Abstraktion bei der Systemgestaltung zu unterstützen.
Schliesslich kann mit Hilfe der Taxionomie die
Wiederverwendbarkeit von Komponenten (einzelne Klassen oder
ganze Klassenbäume als Rahmenwerke) verbessert werden, indem
man neue Klassen als Spezialisierungen von bereits bestehenden
Klassen und deshalb so tief wie möglich im Ableitungsbaum
hinzufügt.
1.2 Objektorientierte Entwurfsmethoden
Eine beachtliche Anzahl objektorientierter Entwicklungsmethoden sind in
den letzten Jahren eingeführt worden, um erweiterbare,
wiederverwendbare und robuste Software zu entwickeln. Nachfolgend
sollen einige davon aufgezählt sein und auf mögliche Probleme
eingegangen werden.
1.2.1 Objektorientierte Softwareentwicklung
2 • Einleitung
Diplomarbeit
Analyse, Entwurf
und Implementation
Die objektorientierte Softwareentwicklung hat es sich zum Ziel gemacht,
die objektorientierten Methoden in den Phasen der Analyse, des Entwurfs
und der Implementation umzusetzen. Dabei sollen während dieses
Ablaufs alle Prozesse auf dem einmal erstellten Modell basieren, was
eine höhere Wiederverwendbarkeit von Resultaten aus vorgelagerten
Phasen unterstützt, und dieses lediglich verfeinern.
Analyse
In der Analyse sollen die Entitäten der realen Welt möglichst getreu auf
die Objekte innerhalb des Modells abgebildet werden. Zudem ist in dieser
Phase die Strukturierung des meist ungeordnet vorliegenden Problems
und dessen Zerlegung in Teilprobleme oder Subsysteme von eminenter
Wichtigkeit. Als Resultat steht die Definition der Objekttypen und deren
Hierarchie, die aus der Klassifizierung des Wissens über die beobachtete
Problemstellung entsteht, im Vordergrund. Auf diese Weise können auf
der einen Seite weitgehend wiederverwendbare Klassenstrukturen
entstehen und auf der anderen Seite bereits bestehende Basisklassen
durch Spezialisierung in den neuen Klassenbaum eingeflochten werden.
Entwurf
Während sich die Analyse auf die Definition der Objekte beschränkt,
werden in der Phase des Entwurfes die Beziehungen zwischen den
identifizierten Objekten unter die Lupe genommen. Als Typen sind
strukturelle Abhängigkeiten (Spezialisierung, Generalisierung,
Enthaltung) und Interaktionen (Meldungsverbindungen) zu
unterscheiden.
1.2.2 Übersicht der objektorientierten Analyse- und
Entwurfsmethoden
Nachfolgend seien einige repräsentative Beispiele von
objektorientierten Analyse- und Entwurfsmethoden angegeben, die
sich alle ihren Platz in der Liste der „state-of-the-art“-Methoden
gesichert haben (vgl. [Aksit et. al. 92]).
Booch
Diplomarbeit
In der objektorientierten Entwurfsmethode von Booch [Booch 94]
werden Diagramme für Klassen, Klassenkategorien, Verhalten (statetransition), Objekte, Module, Subsysteme, Prozessoren und Prozesse
vorgeschlagen. Alle diese Diagramme können zum einen durch die
Verwendung von wohldefinierten Konstrukten grafisch oder zum anderen
durch Beschreibung von Vorlagen textuell dargestellt werden. Die
Diagrammnotation bietet eine bessere Übersicht, während die
freitextliche Charakterisierung wesentlich detaillierter ist. Die eingeführte
Methode läuft nach den Schritten Identifizierung der Objekte und der
Klassen, Definition der Objektsemantik, Beschreibung der
Objektbeziehungen und Implementierung der entworfenen Sachverhalte
ab.
Einleitung • 3
Champeaux
Die objektorientierte Analyse und „Top-Down“ Softwareentwicklung
Champeaux [Champeaux 91] wählt den Ansatz vom Grossen ins Kleine
zu gelangen, indem man das Konstrukt des „Ensembles“ verwendet. Die
eingeführten „Ensembles“ sind Subsysteme und vergleichbar mit
Objekten. Der Hauptunterschied liegt darin, dass sie interne Konkurrenz
zulassen, während dies bei Objekten nicht zugelassen ist. Die Methode
besteht aus drei Komponenten, namentlich der Information, die in Form
eines Objektmodells mit seinen strukturellen Beziehungen dargestellt ist,
des Zustandes, der das dynamische Verhalten einer Objektes definiert
und des Prozesses, der die Interaktionen zwischen den Objekten
beschreibt. Diese drei Bestandteile sind schon in früheren Methoden wie
„Objektorientierte Systemanalyse“ [Mellor 88] angewandt worden.
Coad & Yourdon
Die Methode von Coad & Yourdon namens „Objektorientierte Analyse
und Objektorientierter Entwurf„ ist in zwei separate Bereiche aufgeteilt.
Der erste Teil behandelt die Analyse (vgl. [Coad et. al. 91a]), indem fünf
vertikale Schichten - Subjekte, Klassen, Objekte, Strukturen, Attribute
und Dienste - betrachtet werden. Diese fünf Ebenen werden später in der
Entwurfsphase (vgl. [Coad et. al. 91b]) wiederverwendet und mit vier
horizontalen Bereichen - Problemdomäne, Benutzerinteraktion,
Prozessverwaltung und Datenspeicherung - durchsetzt, woraus die
Matrixarchitektur resultiert.
Rumbaugh
OMT („Object-Oriented Modeling and Design“) [Rumbaugh et. al. 91]
stützt sich auf drei Modelle und eine Methode, die deren Aufbau und
Verwendung angibt. Zuerst wird das Objektmodell erstellt, anschliessend
wird das dynamische Verhalten durch Zustandsdiagramme
veranschaulicht, und zum Schluss werden die funktionalen Eigenschaften
durch Datenflussdiagramme näher spezifiziert.
Wirfs-Brock
Der Ansatz von [Wirfs-Brock 90] genannt „The Responsability-Driven
Approach“ definiert sechs Aktivitäten. Die erste zielt darauf ab, die
Klassen und deren Hierarchie zu identifizieren. Im zweiten Schritt
werden die Operationen oder die sogenannten Verantwortlichkeiten
spezifiziert. Als drittes gilt es, die Objektinteraktionen - genannt
Kollaborationen - zu definieren. Die vierte Aktivität hat zum Ziel, die
Wiederverwendbarkeit durch Verfeinerung der Klassenhierarchie zu
erreichen. Im fünften werden Klassen in Subsystemen gruppiert und im
sechsten und letzten Teil werden die Objektschnittstellen in Form von
Protokollen niedergeschrieben.
Erwähnenswert sind im weiteren die Methoden „Johnson and
Foote“ [Foot et. al. 88], „The Demeter system“ [Holland et. al. 89]
und [Lieberherr et. al. 91] und „Object-Oriented Role Analysis,
Synthesis and Structuring“ [Johnson et. al. 90], auf die aber hier
nicht speziell eingegangen werden soll.
1.2.3 Probleme mit objektorientierten
Entwurfsmethoden
[Askit et. al. 92] erwähnen in ihrer Arbeit verschiedene Probleme,
welche in der Phase der Analyse und der Vorbereitungsarbeit im
Zusammenhang mit objektorientierten Entwurfsmethoden
4 • Einleitung
Diplomarbeit
auftreten. Sie werden im Folgenden den verschiedenen
Entwurfsphasen zugeteilt und summarisch angesprochen.
1.2.3.1 Analyse
Analyse des Problembereiches der Realwelt:
• Je kleiner das Wissen über die Sachverhalte der
untersuchten Domäne ist, wie dies in wissenschaftlichen
Gebieten oft der Fall ist, desto schlechter lässt sich eine
klare Klassenhierarchie für dessen Abbildung finden.
• Der Entwurf der Klassenhierarchie kann Objekte und
Strukturen entstehen lassen, die für den zu analysierenden
Problembereich nicht relevant sind.
Identifikation der Subsysteme und der Objekte:
• Die Unterteilung eines Problems in Teilprobleme vor
der Objektidentifikation verursacht in gewissen Situationen
suboptimale Schnittstellen zwischen den Subsystemen.
Werden erst Objekte identifiziert und anschliessend
Untersysteme gebildet, können sich eventuell
unüberschaubare Strukturen ergeben.
• Die Unterscheidung von Subsystemen und Objekten ist
im Allgemeinen sehr schwierig. Bei der Verfeinerung des
Entwurfes werden vielfach Objekte aufgrund ihrer
komplexen internen Struktur in Subsysteme konvertiert.
Auf die gleiche Weise können während der Analyse
definierte Subsysteme bei der genaueren Betrachtung als
Objekte modelliert werden, da ihre interne Struktur einfach
und übersichtlich ist. Die Konvertierung von Subsystemen
zu Objekten und Objekten zu Subsystemen verursacht eine
Änderung der Elementsemantik.
• Die Klassenhierarchie und die Subsystemdefinition
können sich überlagern, d.h. in einem Subsystem befindet
sich nicht ein ganzer zusammenhängender Teilbaum der
Klassenhierarchie (der Grossvater einer Klasse liegt z.B. in
demselben Subsystem, der Vater in einem anderen).
• Die Definition der Subsysteme anhand von
Objektinteraktion ist vielfach intuitiv und versagt oft bei
grossen Systemen. Deshalb sind automatische
(algorithmische) Methoden empfehlenswert.
1.2.3.2 Entwurf der strukturellen Relationen
Gemeinsames Verhalten:
• Meldungsdelegationen und Delegationshierarchien
(anstelle von Vererbungshierarchien) sind in heutigen
objektorientierten Entwurfsmethoden nicht unterstützt.
Atomarität versus Vererbung
• Bei Mehrfachvererbung von Klassen, die atomare
Transaktionen im Interface exportieren, müssen im
Extremfall sämtliche Kombinationen der Funktionen beider
Klassen atomar gemacht werden, damit sie von der
Diplomarbeit
Einleitung • 5
abgeleiteten Klasse exportiert werden dürfen. Die
Deklarationsanzahl steigt daher exponentiell.
Vererbungsmechanismen
• Bei der Vererbung können Methoden nur überschrieben
und nicht erweitert werden. (Beispiel des Rechners als
Superklasse und des wissenschaftlichen Rechners als
Unterklasse: der Rechner stellt eine Additionsfunktion,
basierend auf natürlichen Zahlen, zur Verfügung. Die
entsprechende Additionsfunktion des wissenschaftlichen
Rechners muss aber auch andere Argumente unterstützen.
Wünschenswert wäre eine Erweiterung der Basisfunktion in
der Subklasse, welche die Grundfunktionalität der
Vaterklasse übernehmen würde. Dieses Verhalten muss
jedoch mit der Überschreibung abgebildet werden.) Der
Einbezug dieser Sachverhalte würde bedeuten, dass man
bereits beim Design an die Implementation denken müsste,
was bestimmt nicht wünschenswert wäre.
Vererbung versus Zustände
• Zustände einer Instanz der Superklasse können in
Unterklassen anders interpretiert werden, d.h. der Zustand
der Oberklasse wird durch den Zustand der Unterklasse
überschrieben (Beispiel eines limitierten Puffers: die
Superklasse implementiert einen ein-elementigen Zugriff,
während das Derivat zwei-elementig operiert. Die
Zustandsangabe „Ende des Puffers“ kann nun nicht mehr
von beiden Klassen gleich behandelt werden.)
1.2.3.3 Entwurf der Objektinteraktionen
Mehrfache Ansicht
• Die Mehrfachansicht eines Objektes kann nicht mit den
objektorientierten Konstrukten abgebildet werden. (Beispiel
einer Schuladministration mit Lehrern, die gleichzeitig
Schüler sind: die beiden Verhalten können nicht in zwei
verschiedenen Klassen beschrieben werden, da ansonsten
ein Objekt als Doppelinstanz aufgefasst werden müsste. Ein
Objekt braucht aber immer eine eindeutige Identifikation.)
Koordiniertes Verhalten
• Koordiniertes Verhalten kann nicht durch Vererbung
erreicht werden. Die Kooridinationsklasse wird vielmehr
von den Beteiligten verwendet (Beispiel
Kreuzungsüberquerung von mehreren Verkehrsteilnehmern
von mehreren Typen.)
1.3 Objektorientierte Datenbanken
Solange nicht bestimmte Vorkehrungen getroffen werden, leben
Datenelemente von Programmen nur solange, wie diese in der Ausführung
begriffen sind, d.h. die Inhalte gehen bei Programmende verloren. Daten
können dauerhaft (persistent) zur Verfügung stehen, wenn diese in Dateien
abgelegt werden. Programme können aber dennoch nicht direkt auf
derartig gespeicherte Datenelemente zugreifen, vielmehr müssen sie bei
6 • Einleitung
Diplomarbeit
der Verwendung explizit kopiert, bzw. bei deren Manipulation
überschrieben werden.
1.3.1 Konzepte von Datenbanksystemen
Mit dem Schritt von Dateien zu Datenbanken wurde zwar
prinzipiell die Notwendigkeit des Kopiervorganges nicht beseitigt,
jedoch liegen die Daten im Hintergrundspeicher nun dauerhaft,
zuverlässig, unabhängig und strukturiert vor und erlauben eine
komfortable und flexible Verwendung, selbst im
Mehrbenutzerbetrieb zu.
Zuverlässigkeit
Als zuverlässig soll in diesem Zusammenhang die Eigenschaft der
selbständigen Sicherung von Konsistenz und Integrität gedeutet werden,
während unter flexibel die Existenz einer strukturierten Abfragesprache
zu verstehen ist.
Datenmodell und
Schema
Der Datenbank liegen ein Datenmodell und ein Schema, die als konkrete
Beschreibung eines Datenmodells für einen Einsatzfall zu betrachten ist,
zu Grunde. Datenmodelle werden durch die Datendefinitionssprache,
bzw. Datenmanipulationssprache erstellt, bzw. verändert. Für das
Einspeichern, Auffinden, Ändern und Löschen steht eine Abfragesprache
zur Verfügung.
hierarchische,
netzwerkartige und
relationale
Datenmodelle
Unter den heute gängigen Datenmodellen findet sich neben dem
hierarchischen und dem netzwerkartigen vor allem das relationale.
Letzteres modelliert Umweltobjekte als Tupel (Zeilen) in Tupelmengen
(Tabellen), wobei die einzelnen Tupelelemente als Attribute zu verstehen
sind. Derartige Mengen werden auch Relationen genannt und basieren
auf der Relationenalgebra.
1.3.2 Erweiterte Anforderungen
Aus der Verwendung von herkömmlichen Datenbanksystemen
werden Forderungen nach Erweiterungen laut, von denen
nachfolgend beispielhaft zwei herausgegriffen werden sollen:
zusammengesetzte
Objekte
Oftmals trifft man gerade im Anwendungsbereich zusammengesetzte
Umweltobjekte, also Objekte, die als Sammlung von Teilobjekten
angesehen werden können. Derartige Kompositionen können auch
rekursiv auftreten und werden daher mit beispielsweise dem relationalen
Modell nur schwerlich mehr handhabbar. (Man beachte, dass zur
Verarbeitung solcher Objekte viele Verbindungsoperationen notwendig
sind, was die Leistung gängiger Systeme schnell an Grenzen stossen
lässt.)
komplexe
Datentypen
Üblicherweise stellen Datenbanksysteme eine Reihe von elementaren
Datentypen zur Verwendung zur Verfügung. Diese Liste deckt aber selten
die tatsächlichen Bedürfnisse, insbesondere nach komplexen Datentypen,
ab. Auch hier wäre prinzipiell eine Modellierung mit relationalen Mitteln
möglich, jedoch ist sie nur durch Zuhilfenahme von weiteren ausserhalb
der Datenbank liegenden Hilfsmittel erreichbar, was sich auf Kosten der
geforderten Sicherheiten äussern würde.
1.3.3 Objektorientierte Datenbanksysteme
Diplomarbeit
Einleitung • 7
Im Manifesto für objektorientierte Datenbanksysteme [Atkinson et.
al. 89] ist zwar keine Definition gegeben, die sich auf eine
allgemeine Anerkennung stützen könnte, vielmehr sind einige
Punkte genannt, welche von einem derartigen System gefordert
werden sollten:
Ein objektorientiertes Datenbankmanagementsystem muss alle
funktionalen Eigenschaften eines klassischen
Datenbankmanagementsystems beinhalten, es muss also
insbesondere
• dauerhafte Verwaltung von Datenelementen bieten,
• den vollen verfügbaren Hintergrundspeicher ausnutzen können,
• durch ein Transaktionskonzept Mehrbenutzerbetrieb zulassen,
• für Wiederanlaufsmöglichkeiten im Fehlerfall sorgen, und
• mengenorientierte deklarative Anfragen unterstützen.
Anders gesagt soll das System keine der bereits erzielten
Errungenschaften einbüssen.
Zudem werden aber an die neue Datenbankfamilie weitere
wesentliche Anforderungen gestellt, z.B. muss sie
1. ein objektorientiertes Datenmodell aufweisen,
2. Objekte eindeutig identifizieren, d.h. Objektidentitäten
verwalten,
3. berechnungsvollständig sein,
4. zusammengesetzte Objekte unterstützen,
5. das Klassenkonzept zur Verfügung stellen,
6. Einkapselung umsetzen,
7. das Konzept der Klassenhierarchie und der Vererbung
implementieren und
8. Überladung, Überschreibung und spätes Binden beinhalten.
Man beachte, dass die Forderungen 5-7 direkt aus den
Eigenschaften der Objektorientierung, wie sie unter dem Titel
„objektorientierte Methoden“ ausgeführt wurden, ableitbar sind.
Die Forderung nach den zusammengesetzten Objekten (4) findet
seine Entstehung in den Anforderungen an weitergehende
Datenbanksysteme. Das im selben Atemzug genannte Bedürfnis
nach komplexen Datentypen ist implizit in den obigen
Anforderungen enthalten, da sämtliche Klassen-Instanzen
persistent gemacht werden können.
1.3.3.1 Objektidentität
Objektidentität,
Zustand und
Botschaften
8 • Einleitung
Jedes Objekt soll als Tripel <Objektidentität (OID), Zustand,
Botschaften> auffassbar sein. Durch das, zumindest implizite,
Vorhandensein einer OID kann jedes Objekt im System eindeutig
identifiziert werden. Diese Indentität bleibt auch bei der Veränderung des
Zustandes erhalten. Selbst bei der Löschung eines Objektes wird dessen
OID nicht erneut vergeben. OIDs wirken also als sogenannte „Surrogate“.
Diplomarbeit
Objektidentität
versus
Schlüsselattribute
Im Gegensatz zum Umgang mit Schlüsselattributen erlaubt diese
Strategie die Wahrung der einmaligen und eindeutigen Beziehung
zwischen dem Realweltobjekt und dem Objekt auf der Datenbank. Würde
nämlich die Identifikation des Objektes rein auf dessen Wertausprägung
beruhen, so wäre keinesfalls gewährleistet, dass nach dessen Löschung
kein anderes Objekt mit ein und derselben Schlüsselwertidentität
entstehen könnte. In diesem Fall wäre nachträglich nicht mehr ersichtlich,
ob es sich noch um dasselbe Objekt handelte.
1.3.3.2 Zusammengesetzte Objekte
komplexe
Datentypen
Mit diesem Konstrukt soll der erwähnten Forderung nach der
Repräsentierbarkeit von Objekt-/Unterobjektstrukturen Rechnung
getragen werden. Der Wert eines Objektes soll also aus Werten anderer
Objekte aufgebaut sein dürfen. Auf diese Weise lassen sich aus
primitiven Datentypen beliebig komplexe Datentypen zusammensetzen.
Insbesondere soll auch erlaubt sein, Objektteile mehrfach zu verwenden,
also diese in mehreren verschiedenen Objekten zu verwenden. Darüber
hinaus müssen auch rekursive Beziehungen modelliert werden können
(ein Objekt kann sich selber als Teil enthalten).
generische
Operatoren
Zur Verwendung derartiger Objekte benötigt man entsprechend auch
generische Operatoren, die transitiv auf deren Unterobjekte wirken.
Sollen Assoziationen zwischen Objekten dargestellt werden, also
Beziehungen, die nicht zu Kompositionsobjekten führen, muss auch ein
explizites Beziehungskonzept angeboten werden.
1.3.3.3 Klassen und Klassenhierarchien
Klassenbibliothek
Das Datenbanksystem muss das Klassenkonzept nach den
objektorientierten Gesichtspunkten unterstützen. Es reicht nicht aus, eine
vorgefertigte Klassenbibliothek in das System einzubauen, vielmehr
sollte den Systemadministratoren und -benutzern die Möglichkeit
gegeben werden, selber Klassen, insbesondere als Spezialisierungen von
gelieferten Basisklassen, zu erstellen.
Die Konzepte der Klassenvererbung und zum Aufbau von
Klassenhierarchien sollen, wie in der Objektorientierung
vorgeschlagen, im System integriert sein.
1.3.3.4 Berechnungsvollständigkeit
Die der Datenbank zu Grunde liegende Sprache muss
berechnungsvollständig sein, d.h. sie muss sich zur Beschreibung von
beliebigen Algorithmen eignen. Es müssen mit ihr also Schleifen,
Fallunterscheidungen und Rekursionen beschrieben werden können.
Bisherige Implementationen von Datenbanksprachen waren
dieser Forderung nicht ausgesetzt, da sie in Applikationen
in andere Sprachen eingebettet auftraten. Diese
Heterogenität soll nun durch den Zwang zur Definition
einer kompletten Sprache ausgeräumt werden.
1.3.3.5 Einkapselung
Schleifen,
Fallunterscheidunge
n und Rekursionen
Diplomarbeit
Einleitung • 9
verbergen von
Zuständen und
Methoden
Gemäss den Grundsätzen der Objektorientierung müssen Zustände und
Methoden von den Objektbenutzern verborgen werden können. Diese
Forderung steht vordergründig im Gegensatz zu der, dass gewisse
Objekte aufgrund ihres Zustandes - man stelle sich beispielsweise
Abfragen auf Objektmengen vor - aufgefunden werden können. (Gesucht
ist die Person namens „Andreas“, wobei das Attribut „Name“ in der
Klasse „Person“ nicht öffentlich zugänglich sein sollte.)
Definition der
Schnittstelle
Durch die Definition der Schnittstelle können die Zugriffe auf derartige
Informationen gewährt werden. Obschon dies den Einkapselungsbegriff
in gewissem Sinne aufweicht, kann trotzdem die Kontrolle bei Lese- und
Schreiboperationen erhalten werden.
Ausserdem kann die Einkapselung in ihrer Strenge - man
denke an private und öffentliche Eigenschaften und
Methoden - variiert werden. Dem Entwerfer bleibt es
überlassen, welche Form dieses „information hidings“ er
für den Anwendungsfall als sinnvoll erachtet.
1.3.3.6 Überladen, Überschreiben und spätes Binden
Die Überladung, die Überschreibung und das späte Binden
stammen aus den erweiterten gegenüber objektorientierten
Systemen geäusserten Bedürfnissen und stellen - jedes
Konstrukt für sich - ein Aspekt des Polymorphismus’ dar.
Überladen
Das Überladen gestattet es, denselben Namen für verschiedene
Botschaften zu verwenden. Die passenden Methoden unterscheiden sich
üblicherweise durch deren Signaturen (eine Unterscheidung auf dem Typ
des Rückgabewertes allein ist in den meisten objektorientieren Sprachen
nicht unterstützt).
Überschreiben
Das Überschreiben von Methoden in abgeleiteten Klassen dient dazu, ein
Verhalten, welches für die Oberklasse bereits definiert ist, in der
Unterklasse zu spezialisieren oder anzupassen. Dieses Standardverhalten
kann in der Vaterklasse auch abstrakt vorgegeben sein. Mit diesem Mittel
wird dem Entwickler ein Werkzeug in die Hand gelegt, welches ihm
erlaubt, Botschaften an ganze Objektmengen zu schicken.
spätes Binden
Diese Mengen können auch heterogen sein, d.h. die Mengenelemente
müssen nicht zwingenderweise vom gleichen Typ sein. Insbesondere
muss auch zur Entwicklungszeit nicht vorgegeben sein, um welchen Typ
es sich in einem speziellen Fall handelt. In dieser Situation muss die
Fähigkeit des Systems zur späten Bindung, Bindung der Methode an eine
Botschaft erst zur Ausführungszeit, ausgenutzt werden.
1.3.4 Ein Standard für objektorientierte
Datenbanksysteme
Die „Object Data Mangement Group“ hat in ihrem
Standardisierungsvorschlag ODMG 93 folgende Komponenten für
den Einsatz von objektorientierten Datenbanksystemen
vorgeschlagen:
10 • Einleitung
Diplomarbeit
ODL
1. Ein „Object Definition Language“ (ODL) für die Spezifikation
von Objekttypen, ihrer Struktur sowie der Signaturen ihrer
Methoden.
OQL
2. Eine „Object Query Language“ (OQL) für die Formulierung von
deklarativen Anfragen.
OML
3. Eine Datenmanipulationssprache (OML), die an eine bereits
bestehende objektorientierte Programmiersprache (C++,
SamallTalk, usw.) angebunden ist, und so die flüchtigen
Objekte, welche über Botschaften mit den dauerhaften Objekten
kommunizieren, zur Verfügung stellt.
Häufig findet man in marktfähigen Implementationen die dritte
Komponente ebenfalls im Datenbanksystem integriert (als eigene
Sprache, die meist auf einer bestehenden basiert). O2 stellt
beispielsweise eine vollständige Sprache O2C für diese Belange zur
Verfügung.
1.3.4.1 Objektdefinitionssprache ODL
Die Spezifikation der Datenbankschemata kann in der
Sprache ODMG 93-ODL erfolgen. Diese ist als
Erweiterung der Interfacedefinitionssprache OMG-IDL zu
betrachten [Cattel 96].
Ein Objekttyp wird durch die Angabe von folgendem CodeFragment definiert:
interface ClassName : ParentClasseName
(
extent: ClassExtensionName;
key(KeyAttribName1, KeyAttribName2, ...)
);
{
attribute Type AttribName1;
attribute Type AttribName2;
...
relatoinship [Set]ForeignClassName RelationName
[inverse ForeignClassName::InverseRelationName]
...
Type MethodName1(Type ParameterName1, ...)
...
}
Syntaxdiagramm 1-1: Interfacedefinition mit ODMG 93-ODL
Legende
interface
Das Schlüsselwort öffnet eine Schnittstellendefinition, in
der die Extension und die Attribute, Relationen und
Methoden angegeben sind.
ClassName
Name der Klasse.
ParentClassName
Name der Vaterklasse, von der geerbt wird.
extent
Schlüsselwort für die Deklaration des Extensionsnamens.
ClassExtensionName
Name der Extension für diesen Objekttyp. Für jeden
Objekttyp kann explizit eine Extension deklariert werden,
Diplomarbeit
Einleitung • 11
über die der Zugriff auf die Menge aller in der Datenbank
gespeicherten Instanzen dieses Typs möglich ist.
key
Definition des Schlüsselattributs oder einer
Schlüsselattributskombination für die Definition der
Extension.
KeyAttribNameN
Name eines im unteren Teil der Definition angegebenen
Attributes, welches allein oder in Kombination mit anderen
Attributen den Schlüssel für die Objektsammlung festsetzt.
attribute
Schlüsselwort für die Deklaration der Attribute
(Zustandsvariablen).
Type
Typendefinition für ein Attribut, einen Parameter oder eine
Methode. Er kann von einem elementaren, in der
Datenbank zur Verfügung stehenden Typ, wie integer,
string, enumeration, oder von einem zusammengesetzten
Typ (struct oder eine bereits definierte Klasse) sein. Auch
mengenwertige Typen, namentlich set, bag, list und array,
werden unterstützt.
AttribNameN
Namen der Attribute
relationship
Schlüsselwort für die Deklaration von Beziehungen.
ForeignClassName
Name derjenigen Klasse, zu welcher eine Beziehung
aufgebaut werden soll. Dies kann insbesondere auch die
eigene sein (Selbstbeziehung).
RelationName
Name der Beziehung. Könnte im übertragenen Sinn auch
als Attribut vom speziellen Typ „Relation“ angesehen
werden. Da eine Relation auch mengenwertig sein kann,
sind alle denkbaren Kardinalitäten für Beziehungen
beschreibbar.
inverse
Schlüsselwort für die Deklaration von inversen
Beziehungen.
InverseRelationName
Name der inversen Beziehung. Dieser Name muss mit der
Klasse, zu welcher man eine reflexive Beziehung
unterhalten will, in der Sektion relationship deklariert sein.
MethodNameN
Name der Methode.
ParameterNameN
Name des N-ten Aufrufparameters.
12 • Einleitung
Diplomarbeit
Es fällt auf, dass einige wichtige Elemente für den Umgang mit
Datenbanken bereits in die Standardsprache Einzug erhalten haben. So
findet man beispielsweise ein Konstrukt für die Definition von inversen
Beziehungen. Dank der Deklarationsmöglichkeit von Klassenextensionen
erhält man ein Werkzeug in die Hand gelegt, welches vergleichbar mit
einem einfachen Sichtenkonzept ist und dem Anwendungsentwickler den
Umgang mit den Objektmengen erheblich vereinfacht.
1.3.4.2 Abfragesprache OQL
Mit der Sprache OQL wurde ein Anweisungssatz
geschaffen, welcher den deklarativen Zugriff auf
objektorientierte Datenbanken ermöglichen soll. Sie basiert
auf dem Objektmodell, wie es von der ODMG 93
vorgeschlagen worden ist, und kann sowohl als interaktive
Datenbankschnittstelle als auch eingebettet in eine
Programmiersprache verwendet werden.
Nachfolgend soll neben dem Syntax auch die Semantik
beschrieben sein.
inverse Beziehungen
und
Klassenextensionen
SELECT - FROM WHERE
Diplomarbeit
Abfragen werden grundsätzlich in der Form SELECT ... FROM ...
WHERE abgesetzt, wobei die Ähnlichkeit zu SQL nicht als
Kompatibilität zu missverstehen ist. Im SELECT-Teil wird das
gewünschte Resultat spezifiziert, welches dementsprechend in Form
eines Wertes, eines Objektes oder einer Sammlung (Menge, Liste,
Multimenge) von Werten, bzw. Objekten zurückgeliefert werden kann.
Der FROM-Teil definiert zum einen die Objektmenge, idealerweise eine
in ODL formulierte Extension, über welche die Datensuche ausgeführt
wird, und zum anderen ein Alias, der für die weitere Verwendung des
Objektes während der Ausführung die betrachtete Instanz repräsentiert.
Schliesslich können in der WHERE-Klausel einschränkende
Bedingungen für die Selektion formuliert werden.
Innerhalb einer Abfrage können, was als ein entscheidender
Vorteil von OQL gegenüber seines relationalen Pendants
angesehen werden darf, auch Botschaften an das Objekt
integriert sein. Methoden können sowohl im Resultatteil als
auch in der Bedingungssektion aufgerufen werden.
In Fällen, in denen man einfachste Anfragen absetzen will,
kann auch vom strengen SELECT ... FROM ... WHERE
abgewichen werden. So lässt sich beispielsweise die Menge
aller Objekte eines gewissen Typs auch direkt durch
Angabe des Namens der Extension beschaffen.
Zwar existiert in OQL kein Sichtenkonzept, welches sich
mit demjenigen von SQL messen könnte, doch findet man
immerhin im Sprachschatz die Möglichkeit, Abfragen unter
Zuhilfenahme des define-Konstruktes zu definieren und zu
benennen. Derartige „named queries“ sind jedoch nicht in
der ODL formulierbar, vielmehr handelt es sich dabei um
eine Erweiterung von OQL.
Einleitung • 13
exists
for all
Werden als Resultate von Abfragen zumeist Mengen von Werten oder
Objekten erstellt, existieren dementsprechend auch darauf wirkende
Operationen als fester Bestandteil von OQL. Der Existenzquantor exists
... in ... erlaubt die qualitative Entscheidung, ob ein ausgezeichnetes
Element in der Menge enthalten ist, während der Allquantor for all ... in
... auf alle Elemente einer Menge wirkt.
sort
group
Für den Umgang mit Mengen stehen noch weitere Ausdrücke zur
Verfügung. So kann eine Menge durch sort ... in ... by ... sortiert oder
durch group ... in ... by ... with ... gruppiert werden, wobei der with-Teil
ähnlich einer Klausel having in SQL eine einschränkende Bedingung
enthalten kann.
union
intersect
except
Verschiedene aber gleichartige Menge können durch union verbunden
(Vereinigungsmenge), durch intersect geschnitten (Durchschnittsmenge)
oder durch except voneinander abgezogen werden (Differenzmenge).
element
flatten
Will man die innere Struktur einer Menge verändern, so existieren
element, zur Schaffung einer Menge aus einem Wert, flatten für das
Ausflachen einer homogenen Multimenge zu einer Menge, oder flatten
zur Überführung einer Liste zu einer Menge als Möglichkeiten.
1.3.4.3 Anbindung an Programmiersprachen
ODL versus OQL
spezifische
Spracherweiterung
OML
14 • Einleitung
Anders als in der relationalen Welt, in der bekanntlich SQL als eine
Obermenge von DDL gesehen werden kann, ist ODL kein Bestandteil
von OQL. Insbesondere ist ODL in den meisten Fällen nicht in der
Implementation der Datenbank zu finden, vielmehr muss für deren
Verwendung eine bestehende Programmiersprache wie C++ oder
Smalltalk herangezogen werden.
Diese stellt dann die Möglichkeit der Schemadefinition als spezifische
Spracherweiterung PL-ODL (Programming Language - ODL) zur
Verfügung. Dabei ist diese bestrebt, das Datenmodell des
Datenbanksystems möglichst eng in sein Typensystem zu integrieren.
Damit kann im allgemeinen ein Schema einerseits direkt
innerhalb der Datenbankumgebung oder andererseits durch
Klassendeklaration in PL-ODL erstellt werden. Eine
Schemadefinition in der sprachspezifischen ODL wird von
einem Deklarationspräprozessor in das Datenbankschema
und in den Deklarationsteil der Programmiersprache, in
Form von beispielsweise C++-Header-Dateien, übersetzt.
Im Implementationsteil der Programmiersprache schliesslich sind die
Zugriffe auf die gewünschten persistenten Objekte unterzubringen. Um
derartige Aufrufe möglichst eng an die Programmiersprache anlehnen zu
können, sind von der ODMG 93 auch entsprechende
Spracherweiterungen (Object Manipulation Language OML) definiert
worden.
Diplomarbeit
Deklarationen in
C++-ODL
Generierte C++Header
ODL Preprozessor
C++-Quellen mit
OML
C++ Compiler
OODBMS
Runtime
Objektcode
Linker
Laufende
Applikation
Datenbank
Datenzugriffe
OODBMS
Runtime
Abbildung 1-1: ODMG-Datenbank mit C++ Anbindung [Grotehen 95, p. 51]
Für weitere Informationen über die C++-spezifische
Spracherweiterungen sei auf [Grotehen95] verwiesen.
1.3.4.4 C++-ODL
C++-ODL ist eine Erweiterung des Typensystems von C++.
Mit den zusätzlichen Konstrukten wie Ref<T>, Set, Bag, List
und Array können Zeiger auf persistente Objekte in der
Datenbasis und in Objektsammlungen verwaltet werden.
1.3.4.5 C++-OML
Die C++-OML definiert einige Klassen wie
• Ref für Referenzen auf persistente und transiente
Objekte,
• Persistent_Object für Referenzen auf persistente Objekte,
• Collection, Set, Bag, List, Array für Sammlungen,
• Iterator für Iterierung (sequentieller Zugriff),
• Transaction Schnittstelle für Transaktion und
• Database für Verwaltung mehrerer Datenbanken
und einige Operatoren und Funktionen wie
• new, bzw. delete für Allokation, bzw. Deallokation und
• Start, Commit, Abort für Transaktionen
1.3.4.6 C++-OQL
Anfragen können gegenüber einer Sammlung oder auch
direkt an eine objektorientierte Datenbank abgesetzt
werden. Mit Hilfe einer speziellen Methode
int query(Ref<Collection<T>>& result,
const char* predicate);
Diplomarbeit
Einleitung • 15
formuliert man eine Filterung der Kollektion unter dem
Kriterium predicate. Datenbankanfragen werden unter
Zuhilfenahme der Methode
int oql(TYPE result, const char* query);
abgesetzt, wobei die Zeichenkette query eine OQL Anfrage
definiert und das Resultat in Abhängigkeit der Anfrage als
ein Sammlungstyp Ref<Persistent_Object>&, Collection&,
etc. oder als ein primitiver Typ char&, int&, etc.
zurückgeliefert wird.
1.3.4.7 Zukünftige C++-Anbindungen
Die in ODMG-93 definierten Konzepte machen bezüglich
der Ausdrucksmächtigkeit noch Abstriche, weshalb bereits
zukünftige Erweiterungen vorgeschlagen worden sind,
welche die folgenden zusätzlichen Eigenschaften besitzen
sollen:
• Alle Klassen können persistente Instanzen besitzen.
• Die Unterscheidung von Referenzen auf persistente und
transiente nicht mehr nötig.
• Die Anfragesprache OQL soll nicht als
Spracherweiterung eingebunden sein, sondern in die
zugrundeliegende Programmiersprache integriert werden,
damit Konstrukte der Anfragesprache frei in der
Programmiersprache verwendet werden können und
umgekehrt.
• Anstelle eines C++-ODL Präprozessors soll ein C++ODL/OML Präprozessor zur Verfügung gestellt werden,
der C++-Quelldateien mit eingebetteten ODL/OMLAnweisungen verarbeiten und in C++ übersetzen kann.
1.3.4.8 Fazit
Zusammenfassend werden verschiedene Punkte als
erfreulich angesehen oder bemängelt.
„Der wesentliche Beitrag dieses Vorschlags ist
wohl die Beschreibung der Anfragesprache OQL, während
sich die anderen Komponenten noch in einem
verbesserungsbedürftigen Zustand befinden.“
[Grotehen 95, p. 55]
Als verbesserungsbedürftig werden vor allem die
Vorschläge bezüglich der ODL gesehen. Zum einen findet
man die Definition von ODL und zum anderen die
zusätzlichen PL-ODLs, was den Betrachter in Staunen
versetzt, zumal in dieser Unterscheidung der Wunsch nach
einer programmiersprachen-unabhängigen
Datenbankdefinitionssprache (wie SQL) gegenüber
demjenigen nach einer möglichst engen Anlehnung an das
sprachabhängige Typensystem im Widerspruch steht. ODL
ist also nicht so gut gelungen wie IDL (Interface Definition
Language), was als Tribut an die
Standardisierungsbemühungen der OMG zu sehen ist.
16 • Einleitung
Diplomarbeit
Trotzdem setzt ODMG-93 einen wichtigen Meilenstein in
der Entwicklung der objektorientierten Datenbanksysteme
und steigert die kommerzielle Akzeptanz dieser
Technologie.
1.3.5 Aktuelle Implementierungen
Es gibt bereits eine gewisse Anzahl von marktfähigen
Implementierungen von objektorientierten Datenbanksystemen,
welche die gemäss obigen Kapitel erforderlichen Eigenschaften
aufweisen und sich in der Praxis mehrfach bewährt haben. In
[Meier et. al. 95] werden sechs derartige Systeme auf den
Prüfstand gehoben und anhand eines Bewertungsrasters benotet.
Zusammenfassend seien hier einerseits anhand der Kandidaten die
grosse Vielfalt der kommerziellen Produkte veranschaulicht und
andererseits die Kriterien der Bewertung beschrieben.
1.3.5.1 Ausgewählte Produkte
Im folgenden sollen einige Produkte kurz charakterisiert
werden. Es wird dabei vor allem auf die Besonderheiten
eingegangen.
GemStone ist eines der wenigen Datenbanksysteme,
welches auf der Linie von Smalltalk aufbaut.
Itasca ist eine objektorientierte Erweiterung von LISP.
O2 basiert auf dem Wisconsin Storage System WiSS. Es
beinhaltet eine spezielle Sprache O2C für die
Objektmanipulation und unterstüzt OQL nach dem
Standard ODMG-93.
ObjectStore ist ein von vielen CASE-Werkzeugen
verwendetes Speicherungssystem für verteilte Objekte. Die
zentrale Sprachschnittstelle bildet C++, in der Zwischenzeit
ist aber auch eine Smalltalk-Anbindung implementiert.
Ontos ist das Nachfolgeprodukt von VBase und basiert auf
C++. Anfragen an die Datenbank werden über eine
proprietäre Sprache ObjectSQL formuliert.
Versant realisiert eine Objektserverarchitektur mit
Sprachanbindungen für C++ und Smalltalk. Als
Anfragesprache wurde Versant ObjectSQL implementiert.
Alle betrachteten Systeme unterstützen die elementaren
Konzepte für objektorientierte Datenbanksysteme, jedoch
sind die Konzepte für die Objektorientierung, die
Modelleigenschaften, die Sprachaspekte und die
Systemarchitektur in unterschiedlicher Ausprägung und
Konsequenz zu finden.
1.3.5.2 Bewertungsraster
Aus diesem Grund wurde von [Meier et. al. 95] ein
Bewertungsraster vorgeschlagen, der vor allem aus der
Sicht eines zukünftigen Datenbankadministrators sowohl
bei der Evaluation des geeigneten Systems, also auch bei
der Bewertung von Systemevolutionen helfen kann.
Mit Hilfe der nachfolgenden Tabellen, die jeweils ein
bestimmtes Kriterium und die beobachtbaren
Diplomarbeit
Einleitung • 17
Ausprägungen einander gegenüberstellt, soll aufgezeigt
werden, wie beispielsweise das Datenbanksystem O2 in
dieser Bewertung abgeschnitten hat (die Ausprägungen für
O2 sind jeweils unterstrichen). (In [Meier et. al. 95] ist für
jede Gruppe von Eigenschaften ist eine eigene
Gegenüberstellung zu finden, was die Bewertungspunkte in
einer übersichtlichen Sammlung strukturiert.)
Objektorientierung und Modelleigenschaften
Kriterium
Ausprägungsarten
Vererbung
Polymorphismus
einfach, mehrfach
Überschreiben, Überladen, generische Funktionen, generische
Klassen
dynamisch, statisch
Attribute, Attribute optional, Methoden
Binden
Kapselung
Tabelle 1-1: Objektorientierung und Modelleigenschaften
O2 unterstützt ein- und mehrfache Vererbung, währenddem
Polymorphismus nur in Form der Überschreibung im
Produkt enthalten ist. Dynamisches (spätes) Binden, sowie
die Kapselung von Attributen und Methoden sind innerhalb
von O2 gut unterstützt.
Modell und Integrität
Kriterium
Ausprägungsarten
Objekte
Referenzsicherheit
Rückbezügliche
Beziehungen
Metamodell
Schemaevolution
komplex, zusammengesetzt
implizit erfüllt, mit „smart pointers“
unterstützt, nur mit zusammengesetzten Objekten
Struktur, z.T. Verhalten, Verhalten
Attribute, Methoden, Klassen
Tabelle 1-2: Modell und Integrität
In O2 können beliebig komplexe Objekte definiert werden,
während der Umgang mit zusammengesetzten Objekten
nicht vorgesehen ist. Die Referenzsicherheit ist implizit
erfüllt, rückbezügliche (inverse) Beziehungen hingegen
sind nicht unterstützt. Die Forderung, die Beschreibung von
Klassen und Methoden selbst als Metamodell den
Anwendungsentwicklern zur Verfügung zu stellen, ist in O2
zumindest zur Entwicklungszeit erfüllt. Wo sich hingegen
eine Schwäche von O2 abzeichnet, ist im Bereich der
Schemaevolution, in welchem der Administrator auf
keinerlei Hilfe durch das System zählen kann.
Datenbank- und Abfragesprachen
Kriterium
Ausprägungsarten
Sprachunabhängigkeit
Interne
Datenbanksprache
Typenkonzept
C++-Anbindung
Smalltalk-Anbindung
gewährleistet, nicht gewährleistet
Smalltalk-Erweiterung, SmalltalkDB, LISP-Erweiterung, CErweiterung, C++-Erweiterung
schach typisiert, streng typisiert, orthogonal
Definition, Manipulation
Definition, Manipulation
18 • Einleitung
Diplomarbeit
Weiter Sprachen
Abfragesprache
Autorisierung
C, LISP, Eiffel
proprietär, eingebettet, frei, OQL, ObjectSQL
teilweise unterstützt, voll unterstützt, minimal unterstützt
Tabelle 1-3: Datenbank- und Abfragesprachen
O2 gewährleistet die Sprachunabhängigkeit und bietet als
interne Sprache eine C-Erweiterung names O2C an. Das
Typenkonzept ist nicht nur streng typisiert sondern sogar
orthogonal. Mit C++ können persistente Objekte sowohl
definiert als manipuliert werden, während eine
entsprechende Anbindung durch Smalltalk nicht
implementiert ist. Durch die Verwendung von weiteren
Sprachen, wie C, LISP, Eiffel sind Zugriffe auf die
Datenbestände möglich. Als Abfragesprache ist das
standardisierte OQL der ODMG 93 vollumfänglich
integriert und kann von der Wirtssprache entweder frei oder
eingebettet verwendet werden. In den Bereichen
Autorisierung und Sichtenkonzept hingegen besteht noch
ein gewisser Handlungsbedarf.
Komponenten der Systemaritektur
Kriterium
Ausprägungsarten
Serverkonzept
OID-Implementation
Objekt-Server, Seiten-Server
Surrogat, Wertindex, Pfadindex, Objektindex, Adresse,
Objekt-ID
möglich, check_in, check_out
unterstützt, nicht unterstützt
langandauernd, geschachtelt
Versionen
Objektverteilung
Transaktionen
Tabelle 1-4: Komponenten der Systemaritektur
Die Arbeitsverteilung zwischen dem Server- und dem
Clientprozess beschränkt sich in O2 auf die Bereitstellung
von physischen Seiten. Die Verteilung von Objekten auf
verschiedenen Servern ist unterstützt. Objekte können
anhand von Objekt-IDs, Wertindex und Objektindex
identifiziert werden. Damit verletzt O2 die Forderung nach
Unveränderbarkeit und Ortsunabhängigkeit. Eine
Versionskontrolle ist nicht unterstützt. Auch in Bezug auf
die Transaktionsverarbeitung sieht man sich bei der
Verwendung von O2 einem einschneidenden Manko
gegenübergestellt. Dies betrifft sowohl langandauernde als
auch geschachtelte Transaktionen.
1.3.5.3 Fazit
Zusammenfassend geben die Autoren an, dass
objektorientierte Datenbanksysteme einen Reifegrad
erreicht haben, der den punktuellen Einsatz solcher
Systeme in der Praxis durchaus zu rechtfertigen vermag.
Insbesondere aber in den Bereichen wie Schemaevolution
und Sprachanbindung sind einige ihrer Exemplare noch
stark verbesserungsfähig. Zudem sollen die physischen
Aspekte der Clusterung, Indexierung, Objektallokation und
Diplomarbeit
Einleitung • 19
Sperrgranularität von den höherwertige Konzepten klarer
getrennt werden.
„Trotz dieser Mängel belegen einige der
kommerziell verfügbaren objektorientierten
Datenbanksysteme, dass diese zukunftsträchtige
Datenbanktechnologie das Arbeiten mit objektorientierten
Methoden und Werkzeugen ideal ergänzen kann.“
[Meier et. al. 95, p. 40]
1.3.6 Stand der Technik
Kinderkrankheiten
Die anfänglichen Kinderkrankheiten, an denen die ersten marktreifen
Implementationen häufig litten, sind heute vielerorts bereits überwunden
und können durchaus als der Geschichte angehörend angesehen werden.
Tatsächlich erobern objektorientierte Datenbanksysteme nach und nach
auch diejenigen Bereiche der Informationsverarbeitung, in denen sie von
den heftigsten Kritikern, meist aus dem Lager der eingefleischten
Verfechter der relationalen Paradigmen, als unzulänglich verschrien
wurden, namentlich im Umfeld der sehr grossen und langlebigen
Datenbeständen (vgl. [Dittrich et. al. 95]).
kontinuierliche
Verbesserung
Diesen Umstand haben die Anbieter vor allem der kontinuierlichen
Verbesserung des Leistungsverhaltens zu verdanken. Nicht zuletzt hat
auch die Definition einer einheitlichen Abfragesprache, welche den
Zugriff auf die dauerhaften Objekte erheblich vereinfacht, zu dem
verbesserten Ruf beigetragen.
günstige
Marktprognosen
In Bereichen, wo der Einsatz von relationalen Systemen bislang nicht zu
befriedigenden Resultaten geführt hat, erfreuen sich objektorientierte
Ansätze bereits heute einer grossen Beliebtheit. Bedenkt man dazu noch,
dass sich heute nicht einmal 20% der auf Rechnern gespeicherten
Informationen in Datenbanken befinden [Brodie 89], so lässt sich hier ein
Potential von beachtlichem Ausmass ausmachen. Entsprechend günstig
präsentieren sich auch die professionellen Marktprognosen [Guilfoyle el.
al. 91].
1.3.7 Nutzen von objektorientierten Datenbanksystemen
Abschliessend lassen sich durch die Verwendung von
objektorientierten Datenbanksystemen zusammenfassend folgende
Aspekte in bezug auf den Nutzen erwähnen:
Objektorientierte Datenmodelle helfen gerade bei der Modellierung
von komplexen Sachverhalten, sowohl hinsichtlich struktureller als
auch verhaltensmässiger Aspekte. Grosse Systeme werden dadurch
einfacher plan-, implementier- und wartbar.
„Objektorientierte Datenbanksysteme sind eine technische
und marktpräsente Realität und werden sich mittelfristig
durchsetzen.“
[Dittrich et. al. 95], p. 22
20 • Einleitung
Diplomarbeit
Integration
relationaler und
objektorientierter
Systeme
Relationale Systeme werden jedoch keineswegs verdrängt, vielmehr
finden Datenbankdienste dank ihrer objektorientierten Vertreter Einzug
in Gebiete, die bis anhin gar nicht oder nur schlecht unterstützt wurden.
In denjenige Bereichen, in denen Datenbestände bereits durch
Datenbanken verwaltet wurden, ergänzen objektorientierte ihre
Vorgänger, was darauf hinausläuft, dass der Integration der beiden
Systemarten in der Zukunft eine grosse Bedeutung zuzumessen sein wird.
Effektivität im Umgang mit der neuartigen Technologie bedingt auch
eine entsprechende Anpassung des organisatorischen und methodischen
Rahmens. Es gilt dabei zu bemerken, dass die wissenschaftlichen
Kenntnisse darüber noch in keinem Fall ausreichend sind.
Die Arbeit an der Definition der Entwurfsmethodik durch, wie in
dieser Arbeit beispielsweise vorgeschlagen, adäquate Erweiterung
bestehender Vorgehensweisen soll nicht zuletzt eben dieser
Anforderung genügen und helfen eine Lücke in der Erkenntnis zu
schliessen.
organisatorischer
und methodischer
Rahmen
1.4 Konklusion: Objektorientierter
Datenbankentwurf
„Objektorientierte Datenbankmodelle nehmen für sich in
Anspruch, eine natürlichere Modellierung der Anwendung zu
ermöglichen, als im Relationenmodell oder den bisherigen
Entwurfsmodellen, meist Versionen des Entity-Relationship-Modells (ERModell), üblich.“
[Heuer 93, p. 96]
Ausgehend von diesem Ansatz kann man weitere Vorteile aufführen:
1. Das Entwurfsmodell kann als ein mögliches Implementierungsmodell
betrachtet werden, da die verwendeten Konstrukte von den
Datenbanksystemen weitgehend unterstützt werden. Es ist also nicht mit
Verlusten der Semantik zu rechnen, wie dies in bisherigen
Umsetzungstechniken der Fall war.
2. Im Gegensatz zu bisherigen Entwurfsmodellen, welche das Verhalten
in aussenstehenden Programmen spezifiziert haben, können diese
dynamischen Eigenschaften in den Entwurf mit einbezogen werden.
Vereinigung des
Datenbank- und des
Softwareentwurfs
Die objektorientierte Modellierung vereinigt den Datenbank- und den
Softwareentwurf. Man identifiziert Objekte, ihre Attribute und
Methoden, fasst diese zu (Objekt-)Klassen zusammen und strukturiert die
so gefundenen Klassen in Klassenhierarchien und
Komponentenhierarchien. Klassen können darüber hinaus auch in
Bereiche (Subsysteme) aufgeteilt werden. Die derart definierten
Strukturen werden von den objektorientierten Sprachen gut unterstützt.
1.4.1 Objektorientierte Analyse und objektorientierter
Entwurf
Das Verfahren zur objektorientierten Modellierung eines
Anwendungsbereichs muss in die objektorientierte Analyse (was
soll modelliert werden?) und den objektorientierten Entwurf (wie
soll es modelliert werden?) aufgeteilt werden. Die gängigen
Diplomarbeit
Einleitung • 21
Verfahren lassen sich somit in rein analysierende oder rein
entwerfende oder eigenständige Verfahren für objektorientierte
Modelle (etwa die Methode von Booch [Booch 94]) einordnen.
Die Verfahren müssen drei Problembereiche berücksichtigen:
• die Modellierung von Strukturen (Klassen und ihre
Hierarchien),
• die Modellierung von Funktionen (Klassenmethoden) und
• die Modellierung des Gesamtverhaltens des Systems.
Die gängigen objektorientierten Analyse- und Entwurfsverfahren
unterstützen diese Bereiche sehr gut. Für objektorientierte
Datenbankmodelle hingegen müssen einige weitere Eigenschaften
einbezogen werden. So muss der objektorientierte
Datenbankentwurf
1. Objektevolution (Rollenwechsel eines Objektes),
2. Schemaevolution (Veränderung des Schemas unter
Beibehaltung der darin gespeicherten Objekte und deren
Informationen) und
3. Sichten (durch Abfragen abgeleitete Klassen)
modellieren können. Die beiden ersten Punkte sind für langfristig
angelegte Datenbankanwendungen von zentraler Bedeutung,
während sich der dritte Punkt auf eine typische Datenbankfunktion
bezieht. Die in einer Datenbasis abgelegten Informationen werden
häufig durch Sichtendefinitionen für einen bestimmten
Verwendungszweck aufbereitet. Derartige Sichtenklassen
spezifiziert man hingegen selten in den Entwurfsdiagrammen oder
den Schemata, weil sie die Darstellungen, bzw. Datenbasen
unnötig durch redundante Informationen aufblähen.
Während die Integration des bisher getrennten Entwurfs von
Strukturen und Funktionen und die Beschreibung des
Gesamtverhaltens eines Systems gut gelungen sind, sind
datenbankspezifische Bereiche in den gängigen, eher auf
objektorientierte Programmiersprachen zugeschnittenen Verfahren
nicht oder nicht ausreichend berücksichtigt.
22 • Einleitung
Diplomarbeit
TEIL I
DEIMOS
'(,026'(V,JQ0HWKRGIRU2EMHFWRULHQWHGGDWDEDVH6\VWHPV
'(,026*RWWGHU)XUFKWVWlQGLJHU%HJOHLWHUGHV$UHV*RWWGHV
.ULHJHV
Å+RPHUVDJWQLFKWVHUIUHXHLKQVRVHKUZLHZLOGHV.DPSIJHVFKUHL
XQGGDV*HWPPHOGHU6FKODFKW%HZDIIQHWYRQ.RSIELV)XVVGLH
PlFKWLJH/DQ]HVFKZLQJHQGDXIGHP+DXSWHGHQ+HOPPLWGHP
ZHKHQGHQ%XVFKVWUPWHUEHUGDV%ODFKIHOGXQGVlW7RGXQG
9HUGHUEHQ3KRERVGHU6FKUHFNHQ(ULVGHU6WUHLWGLH.HUHQ
IXUFKWEDUH*|WWLQQHQGHV6FKODFKWHQWRGHVVLQGVHLQH%HJOHLWHU6HLQH
:LOGKHLWXQG*HZDOWWlWLJNHLWLVWDOOHQ*|WWHUQVRJDUVHLQHP9DWHU
=HXVYHUKDVVW´>[email protected]
Wenn im Zentrum der Betrachtung nicht eine bestimmte
Entwurfsmethode und entsprechend eine konkrete
Datenbankimplementation steht, läuft die Diskussion über die
Schwachstellen von Vorgehensweisen und deren Behebung in
Gefahr, auf einer Metaebene abzulaufen und für den Leser
schwammig zu erscheinen, d.h. ohne konkrete Aussagen zu
beinhalten.
Aus diesem Grund muss aus der Vielzahl der bekannten
Entwurfsmethoden eine bestimmte herausgegriffen und auf ein
gewähltes Datenbanksystem abgebildet werden. Zudem muss, um
Schwachstellen auf der logischen Ebene finden zu können, eine
konkrete Datenbankimplementierung untersucht werden. Darüber
hinaus ist es unerlässlich, für die Beschreibung des zweiten Teils
auf eine bestimmte Schemadefinitionssprache abzielen zu können.
Auswahl der Entwurfsmethode
Es existiert eine Vielzahl objektorientierter Entwurfsmethoden
(vgl. “
Entwurf
:lKUHQGVLFKGLH$QDO\VHDXIGLH'HILQLWLRQGHU2EMHNWHEHVFKUlQNW
ZHUGHQLQGHU3KDVHGHV(QWZXUIHVGLH%H]LHKXQJHQ]ZLVFKHQGHQ
LGHQWLIL]LHUWHQ2EMHNWHQXQWHUGLH/XSHJHQRPPHQ$OV7\SHQVLQG
VWUXNWXUHOOH$EKlQJLJNHLWHQ6SH]LDOLVLHUXQJ*HQHUDOLVLHUXQJ(QWKDOWXQJ
XQG,QWHUDNWLRQHQ0HOGXQJVYHUELQGXQJHQ]XXQWHUVFKHLGHQ
Übersicht der objektorientierten Analyse- und Entwurfsmethoden”
auf Seite 3), welche sich unterschiedlicher Beliebtheit erfreuen.
Unter den am breitesten anerkannten Methoden finden sich die
Vorschläge von Booch [Booch 94] und Rambough (OMT)
[Rambough et. al. 91].
Die vielen Methoden unterscheiden sich meist nur geringfügig. Die
Unterschiede liegen entweder im Verwendungszweck (einige sind
eher für die Analyse, andere eher für den Entwurf geeignet) oder in
der unterschiedlichen Detaillierung bei der Betrachtung eines
bestimmten Aspektes. Häufig sind die Abweichungen zweier
Methoden sogar auf das unterschiedliche Aussehen semantisch
äquivalenter Konstrukte in einer bestimmten Notation beschränkt.
Vielfach bewegen sich verschiedene Methoden im Rahmen ihrer
jeweiligen Weiterentwicklung aufeinander zu. Der berühmteste
dieser Fälle ist der von Booch’s Methode und OMT, welcher auch
von den Autoren der Methoden erkannt worden ist und diese
veranlasst hat, gemeinsam eine vereinheitlichte Methode zu
definieren. Das Resultat dieser Vereinheitlichungsanstrengungen
wurde als UM (Unified Method), Version 0.9 der Öffentlichkeit
zugänglich gemacht. Da Jacobson (OOSE) als weiterer Autor in
das Gremium berufen worden war, wurde UM zugunsten der neuen
Methode UML (Unified Modeling Language) zurückgestellt .
In die engere Auswahl wurden Booch, OMT und UML
aufgenommen. UML war aber zu Beginn der Diplomarbeit nicht in
einer konsolidierten Version verfügbar, weshalb sie aus dem
Rennen ausscheiden musste. Welche von den übrigbleibenden
Alternativen gewählt wurde, war im Grunde unerheblich, da bei
der Fertigstellung der Arbeit keine mehr aktuell sein wird. Deshalb
sei zum Schluss der Arbeit dem Unterschied zwischen UML und
Booch ein Anhang gewidmet.
Für die folgenden Ausführungen wird Bezug auf die Methode von
Booch genommen.
Auswahl des Datenbanksystems
Zur Auswahl stehen eine Vielzahl von aktuellen
Implementierungen. In [Meier et. al. 95] wurden die verschiedenen
Produkte einander gegenübergestellt und unter mannigfaltigen
Kriterien beleuchtet. O2 sticht aus dieser Auswahl darum hervor,
weil es in allen Kategorien gut abschneidet, ohne in einem
bestimmten Bereich schwere Unzulänglichkeiten zu besitzen.
Darüber hinaus wird O2 im Institut für Informatik der Universität
Zürich eingesetzt. Die dort beschäftigten Mitarbeiter haben grosse
Erfahrung in der Arbeit mit diesem System, was sich
beispielsweise in den diversen Implementationen (vgl. [Geppert
96]) äussert.
2 Die Methode von Booch
2.1 Einleitung
In den folgenden Kapiteln, insbesondere den Kapiteln
„Schwachstellenanalyse“ und „Die Methode DEIMOS“, wird häufig
Bezug auf die Methode von Booch genommen, weshalb in diesem Kapitel
die wichtigsten Elemente und Prozesse der Methode von Booch
zusammengefasst werden sollen.
Das Kapitel ist eine qualifizierte Zusammenfassung des Buchteils „The
Method“ aus [Booch 94, pp. 169-266], wobei die Notation nicht
vollständig und das Vorgehen nur prinzipiell wiedergegeben sind.
Eine Methode ist als Gesamtheit aller Notationen und des entsprechenden
Vorgehens zu betrachten, weshalb dieses Kapitel - analog zum
booch’schen Buchteil - in einen Abschnitt „Notation“ und einen Abschnitt
„Vorgehen“ unterteilt ist.
2.2 Die Notation
Das Zeichnen eines Diagramms macht nicht die Analyse oder das Design
aus. Ein Diagramm zeigt vielmehr eine Ansicht des Systemverhaltens
(Analyse) oder die Vision einer Architektur (Design). Häufig reift ein
System im Kopf des Entwerfers und wird lediglich durch die Notierung
auf einem Medium wie Wandtafel, Tischtuch, Serviette, Windel oder
Rückseite eines Briefumschlages [Shear 88] festgehalten.
Beschreibung der
architektonischen
Vision
Trotzdem ist es wichtig, eine wohldefinierte Notation für die
Entwicklung von Software zu haben. Erstens wird es dem Designer durch
die Verwendung einer Standardnotation möglich, ein Szenario oder eine
architektonischen Vision zu beschreiben und diese Entscheidungen
unmissverständlich anderen involvierten Personen und Institutionen zu
kommunizieren. („Zeichnen Sie einen elektrischen Schaltplan, und jeder
Elektriker der Welt wird ihn lesen können.“) Zweitens erwähnt der
Mathematiker Whitehead [Whitehead 58], dass nur die Anwendung einer
guten Notation erlaubt, sich auf die weiterführenden Probleme zu
konzentrieren, da sie den Kopf von unnötiger Arbeit freihält. Und drittens
hilft eine ausdrucksstarke Notation, Fehler im Entwurf frühzeitig zu
eliminieren, indem die Konsistenz und die Korrektheit durch
automatisierte Werkzeuge überprüft werden kann.
2.2.1 Die Elemente der Notation
2.2.1.1 Die Notwendigkeit mehrfacher Ansichten
Es ist unmöglich, alle Details eines komplexen Systems in
einer einzigen Ansicht zu fassen. Kleyn und Gingrich
[Gingrich et. al. 88] vergleichen dieses Phänomen mit der
Übertragung eines Fussballspiels: man muss mit
verschiedenen Kameras aus verschiedenen Winkeln
beobachten, um die gesamte Handlung erfassen zu können.
Jede Kamera gibt dabei zu einem gewissen Zeitpunkt einen
speziellen Gesichtspunkt des Geschehens wieder, welcher
gerade im Interesse des Zuschauers liegt, was beim Einsatz
einer einzigen Übersichtskamera nicht möglich wäre.
Diplomarbeit
Die Methode von Booch • 27
Dynamisches Modell
Statisches Modell
Logisches
Modell
Klassenstruktur
Objektstruktur
Physisches
Modell
Modellarchitektur
Prozessarchitektur
Abbildung 2-1: Die Modelle des objektorientierten Entwurfes [Booch 94, p. 172]
Die Ergebnisse von Analyse und Design sind im oben abgebildeten
Würfelmodell (Abbildung 2-1) ausgedrückt. Damit sind sie
ausdrucksstark genug, um alle interessanten strategischen und taktischen
Entscheidungen zu fassen, sowohl während der Systemanalyse als auch
während der Formulierung ihrer Architektur, und komplett genug, um als
Vorlagen für die Implementation für fast jede objektorientierte Sprache
zu dienen.
Der Umstand, dass die Notation detailliert ist, bedeutet
nicht, dass jeder Aspekt von ihr stets zu berücksichtigen ist.
Häufig ist auch nur eine Untermenge aller Ansichten nötig,
um einen grossen Prozentsatz der Analyse und des Designs
auszudrücken. Man sollte sogar nur diejenigen Sichten
anwenden, die zum Verständnis beitragen. So wie es
gefährlich ist, die Anforderungen überzuspezifizieren, ist es
gefährlich, die Lösung zu detailliert zu definieren.
Ausdrucksstärke
und Komplettheit
Oft benutzen Programmiersprachen verschiedene Sprachelemente, um
dasselbe Konzept umzusetzen. Die Notation sollte aber weitgehend
sprachunabhängig sein. Trotzdem kann die Situation entstehen, dass
gewisse Konstrukte der Notation von der betrachteten Zielsprache nicht
unterstützt werden. In diesen Konstellationen sollte deshalb davon
abgesehen werden, die nicht umsetzbaren Konstrukte in den Entwurf mit
einzubeziehen.
2.2.1.2 Modelle und Sichten
Sprachunabhängigk
eit
logische/physische
und
statische/dynamisch
e Sicht
28 • Die Methode von Booch
Wie in der Abbildung 2-1 angedeutet, sollen Klassen und Objekte in zwei
Dimensionen betrachtet werden. Die eine Dimension stellt deren logische
und physische Sicht einander gegenüber, während die zweite Dimension
deren statische und dynamische Sicht vergleicht. Beide Dimensionen sind
aber notwendig, um die Struktur und das Verhalten eines
objektorientieren Gesamtsystems zu spezifizieren.
Für jede Dimension ist eine Reihe von Diagrammen
vorgesehen. In diesem Sinne repräsentiert das
Systemmodell die Gesamtsicht für die Klassen,
Beziehungen, usw., während die einzelnen Diagramme eine
Projektion dieser Totalen darstellen. Daraus folgt, dass die
Diplomarbeit
jeweiligen Diagramme - wenn sich das Modell in einem
stabilen Zustand befindet - sowohl mit dem Systemmodell
als auch untereinander konsistent sein müssen.
2.2.1.3 Logische vs. physische Modelle
Die logische Sicht beschreibt die Existenz und Bedeutung
der Schlüsselabstraktionen und Mechanismen, die den
Problemraum beschreiben oder die Systemarchitektur
definieren. Das physische Modell beschreibt die konkrete
Software- und Hardwarekomposition im Kontext des
Systems oder der Implementation.
Während der Analyse müssen folgende Fragen beantwortet
werden:
• Welches ist das Verhalten des Systems?
• Was sind die Rollen und die Verantwortlichkeiten der
Objekte, damit dieses Verhalten erzielt wird?
Während der Analyse werden Szenarien verwendet, um das Verhalten
eines Systems zu untersuchen. Im logischen Modell werden
Objektdiagramme herangezogen, um diese Szenarien zu beschreiben. In
den Klassendiagrammen werden die Abstraktionen der Objekte und deren
gewöhnliches Verhalten strukturiert beschrieben.
Während des Designs müssen in Abhängigkeit der
Systemarchitektur die folgenden Fragen beantwortet
werden:
• Welche Klassen existieren und wie sind die Klassen
verbunden?
• Welche Mechanismen werden verwendet, um die
Zusammenarbeit der Klassen zu regulieren?
• Wo sollen Klassen und Objekte deklariert werden?
• Zu welchem Prozessor soll ein Prozess zugeordnet
werden und wie sollen die Prozesse für einen bestimmten
Prozessor gesteuert werden?
Die Antworten auf diese Fragen sind in den folgenden
Diagrammen unterzubringen:
• Klassendiagramme
• Objektdiagramme
• Moduldiagramme
• Prozessdiagramme
2.2.1.4 Statische versus dynamische Semantik
Objektdiagramme
und
Klassendiagramme
Erzeugung,
Löschung und
Senden von
Meldungen
Diplomarbeit
Die obigen Diagramme sind eher statischer Natur und genügen daher
nicht für die Beschreibung der Ereignisse, die sich in Softwaresystemen
dynamisch ergeben. Unter Ereignis sei in diesem Zusammenhang
beispielsweise die Erzeugung, bzw. Löschung eines Objektes, das Senden
von Meldungen zwischen Objekten oder die von äusseren Entitäten
verursachten Aktionen, die gewisse Ereignisse für ein oder mehrere
Objekte auslösen, zu verstehen. Es überrascht dabei nicht, dass die
Beschreibung dieser dynamischen Ereignisse in einem statischen Medium
wie einem Blatt Papier nicht gerade einfach ist.
Die Methode von Booch • 29
In der objektorientierten Softwareentwicklung wird die
dynamische Semantik eines Systems mit Hilfe von zwei
weiteren Diagrammen ausgedrückt:
• Zustandsübergangsdiagramm
• Interaktionsdiagramm
zeit- und
ereignisorientierte
Meldungsverarbeitu
ng
Jede Klasse kann ein Zustandsübergangsdiagramm für die Beschreibung
der ereignisgesteuerten Verhalten der Instanzen haben. Auf ähnliche
Weise werden die Objektdiagramme, die ein Szenario beschreiben, mit
den Interaktionsdiagrammen verbunden, um die zeit- und
ereignisorientierte Meldungsverarbeitung zu spezifizieren.
2.2.2 Klassendiagramme
Ein Klassendiagramm wird verwendet, um die Existenz von
Klassen und deren Beziehungen in der logischen Sicht eines
Systems darzustellen. Ein einzelnes Klassendiagramm repräsentiert
dabei eine Ansicht der Klassenstruktur eines Systems. Während
der Analyse werden Klassendiagramme verwendet, um die Rollen
und Verantwortlichkeiten der Entitäten zu identifizieren, welche
das Verhalten des Systems bestimmen. Im Entwurf schliesslich
werden Klassendiagramme herangezogen, um die Strukturen zu
erhalten, welche das System formen. Die beiden essentiellen
Elemente eines Klassendiagramms sind die Klassen und deren
Beziehungen.
2.2.2.1 Klassen und ihre Beziehungen
class name
attributes
methods()
{constraints}
Klassen werden durch eine Wolke (der Einfachheit halber werden im
Folgenden für die Abbildungen die Wolken durch Hexagone ersetzt)
repräsentiert und tragen einen eindeutigen Namen. Für gewisse Klassen
kann es sinnvoll sein, einige ihrer Attribute und Methoden anzugeben. In
den seltensten Fällen trägt es zur Übersicht bei, wenn sämtliche Attribute
und Methoden der Klassendarstellung einbeschrieben werden. Die
Zeichnung zeigt also nur eine auf die wesentlichen Elemente
eingeschränkte Sicht der Klassendefinition.
Namen, Typ und
Standardwert
Attribute werden in einem sprachunabhängigen Syntax angegeben und
bestehen entweder aus einem Namen, einem Typ oder beidem und
können optional einen Standardwert besitzen. Zugelassen sind also
folgende Attributsdeklarationen:
nur Attributname
A
nur Attributtyp
B
Attribut mit Name und Typ
A:B
Attribut mit Name, Typ und Standardwert
A:B=C
Der Name eines Attributes muss im Kontext einer Klasse
eindeutig sein.
Methoden und
Signaturen
Die Fähigkeiten einer Klasse werden durch deren Methoden beschrieben.
Methoden werden innerhalb von Klassenikonen normalerweise mit deren
Namen beschrieben und durch die Klammerung von den Attributen
unterscheidbar gemacht. In manchen Fällen ist die zusätzliche Angabe
von Teilen oder der gesamten Signatur sinnvoll.
nur Methodenname
M()
30 • Die Methode von Booch
Diplomarbeit
R M(Arg)
Methode mit Argumenten und
Rückgabewert
Der Name einer Methode muss im Kontext der Klasse
eindeutig sein. Wird von der betrachteten
Implementationssprache die Methodenüberladung
unterstützt, können gleichnamige Methoden mit
unterschiedlicher Signatur koexistieren.
A
class name
attributes
methods()
{constraints}
association
inheritance
has
using
Klassen, von denen keine Instanzen gebildet werden können, werden als
abstrakte Klassen bezeichnet. Für die Darstellung derartiger Klassen wird
das normale Klassenkonstrukt um ein Dreieck mit einem
einbeschriebenen A (für abstrakt) erweitert.
Klassen stehen selten allein. Vielmehr arbeiten sie in verschiedenen
Arten miteinander. Die essentiellen Verbindungen zwischen Klassen sind
Assoziation, Vererbung, Besitz- und Verwendungsbeziehung.
Jede Beziehung kann eine textuelle Bezeichnung tragen, welche den
Namen der Beziehung oder deren Verwendungszweck dokumentiert.
Kardinalitäten
Vererbungs-, Besitzund Verwendungsbeziehungen
Diplomarbeit
Die Assoziation beschreibt eine semantische Verbindung zwischen zwei
Klassen ohne deren genauen Typ anzugeben. Klassen können auch zu
sich selber eine Assoziation besitzen (reflexive Assoziation) oder
mehrere Assoziationen zu derselben Klasse unterhalten. Assoziationen
sind im weiteren mit Kardinalitäten behaftet, welche den folgenden
syntaktischen Regeln genügen sollen:
genau eine
1
beliebig viele (keine, eine oder mehr)
N
keine oder mehr
0..N
eine oder mehrere
1..N
keine oder eine
0..1
spezifizierter Bereich
3..7
spezifizierter Bereich, oder genaue
1..3,7
Anzahl
Die Kardinalitätsbezeichnung ist am Ende der Assoziation
angegeben und beschreibt somit die Anzahl der
Verbindungen, welche von der Ausgangsklasse zu der
Zielklasse erlaubt sind. Fehlt eine Kardinalitätsangabe, so
wird eine beliebige Anzahl erlaubter Assoziationen
angenommen.
Die drei verbleibenden Beziehungen werden als Verfeinerungen der
generellen Assoziation gezeichnet. In der Tat werden während des
Entwurfes erst undefinierte Verbindungen zwischen zwei Klassen
erkannt und durch taktische Entscheidungen in Vererbungs-, Besitz- oder
Verwendungsbeziehungen umgesetzt.
Die Methode von Booch • 31
Vererbungsbeziehun
g
Die Vererbung beschreibt eine Generalisierungs- /
Spezialisierungsbeziehung und wird mit einem Pfeil dargestellt. Die
Pfeilspitze zeigt dabei auf die Superklasse während das entgegengesetzte
Ende von der Subklasse ausläuft. Durch die Einrichtung einer
Vererbungsbeziehung werden die Struktur und das Verhalten der
Superklasse auf die Subklasse übertragen. In Abhängigkeit der
betrachteten Implementationssprache können Klassen von einer Klasse
(Einfachvererbung) oder mehreren Klassen (Mehrfachvererbung)
abgeleitet sein. Beim Entwurf der Vererbungshierarchie muss darauf
geachtet werden, dass keine Zyklen entstehen.
Besitzbeziehung
Die Besitzbeziehung beschreibt eine Aggregation. Dabei besitzt die
Verbindung beim Aggregat einen ausgefüllten Kreis. Die Instanzen der
Klasse am anderen Ende der Beziehung bilden die Teile, aus welcher das
Aggregat aufgebaut ist. Reflexive und zyklische Aggregation ist
zugelassen, da mit ihr nicht zwingenderweise das physische
Enthaltensein ausgedrückt wird.
Die Verwendungsbeziehung beschreibt eine Kunden/AnbieterVerbindung, wobei diejenige Klasse, welche den leeren Kreis enthält, der
Kunde ist. Diese Assoziation wird typischerweise verwendet, um zu
beschreiben, dass die Kundenklasse Methoden enthält, welche Instanzen
der Anbieterklasse entweder als Argumente oder als Parameter besitzen.
2.2.2.2 Klassenkategorien
Verwendungsbezieh
ung
Dekomposition
name
classes
32 • Die Methode von Booch
Für die Dekomposition eines Systems ist die Klasse zwar ein
notwendiges aber nicht ausreichendes Konstrukt. Wenn ein System zirka
zehn Abstraktionen übersteigt, drängt sich die Unterteilung des Systems
in kollaborierende, aber lose gekoppelte Bereiche auf. Diese Bereiche
werden Klassenkategorien genannt.
Die meisten objektorientierten Programmiersprachen (mit
Ausnahme von Smalltalk) unterstützen linguistisch keine
derartigen Konstrukte. Jedoch wird dem Entwerfer damit
ein wichtiges architektonisches Element in die Hände
gelegt, welches nicht direkt mit der
Implementationssprache ausgedrückt werden kann.
Klassen und Klassenkategorien können im selben
Diagramm gezeichnet werden. Meistens werden aber
Klassendiagramme verwendet, welche ausschliesslich
Klassenkategorien beinhalten, um auf einer hohen Stufe die
logische Architektur zu repräsentieren.
Eine Klassenkategorie ist ein Aggregat von einerseits Klassen aber
andererseits auch anderen Klassenkategorien. Jede Klasse muss dabei
einer einzigen Klassenkategorie angehören oder auf der obersten Ebene
des Diagramms angegeben sein. Klassenkategorien werden durch
Rechtecke repräsentiert und enthalten den Namen sowie die beinhalteten
Klassen oder Klassenkategorien.
Beziehungen zwischen den Klassenkategorien werden als
Verwendungsbeziehungen aufgefasst. Aus diesem Grund
wird das bereits eingeführte Konstrukt konsistent
Diplomarbeit
weiterverwendet. Werden Klassen einer Klassenkategorie
von allen oder fast allen anderen Klassenkategorien
verwendet, können diese auch als Mitglieder einer globalen
Klassenkategorie modelliert werden.
vertikalen und
horizontale
Unterteilung
Mit Hilfe der Klassenkategorien kann neben der vertikalen Unterteilung
eines Systems in Teilbereiche auch die horizontale Trennung in
verschiedene Abstraktionsschichten erreicht werden. Somit bietet das
Klassendiagramm auch eine nützliche Visualsierung der Systembereiche
und -schichten.
2.2.2.3 Parametrisierbare Klassen
formal
arguments
parameterized
class name
actual
arguments
instantiated
class name
Parametrisierbare Klassen sind Bestandteil von vielen
objektorientierten Sprachen und beschreiben eine Familie
von Klassen, deren Struktur und Verhalten unabhängig von
den formalen Parametern definiert ist. Durch die
Instantiierung werden die formalen Parameter mit aktuellen
ersetzt und eine konkrete Implementation eines
Familienmitgliedes gebildet, welche dadurch Instanzen
ausbilden kann.
2.2.2.4 Hilfsklassen
class utility name
attributes
operations()
{constraints}
Verschiedene objekorientierte Programmiersprachen erlauben die
Implementation von sowohl prozeduralen als auch objektorientierten
Programmteilen. Die ungebundenen Prozeduren, auch freie
Unterprogramme genannt, werden in Hilfsklassen modelliert.
Hilfsklassen werden aber auch herangezogen, um Klassen zu
beschreiben, welche nur aus statischen Methoden und Attributen
bestehen (für Programmiersprachen, die keine prozeduralen Teile
enthalten dürfen) und demnach keine sinnvollen Instanzen ausbilden
können.
2.2.2.5 Physisches Enthaltensein
Die Aggregation ist eine verstärkte Form der Assoziation, welche nichts
über das physische Enthaltensein der Teile im Aggregat aussagt, und
"has-a" by value
erlaubt insbesondere eine Navigation vom Aggregat zu seinen Teilen. Die
Wahl der Aggregation ist üblicherweise ein Analyse- oder
"has-a" by reference
architektonischer Entscheid. Insbesondere ist der Aggregationstyp des
physischen Enthaltenseins aus zwei Gründen ein taktischer Entschluss.
Zum einen spielt er bei der Erzeugung und Zerstörung des Aggregates
eine Rolle und zum anderen ist er für die Generierung von sinnvollem
Programmcode aus dem Entwurf notwendig.
Es muss zwischen zwei verschiedenen Arten von
physischem Enthaltensein unterschieden werden:
By value
Das Aggregat enthält den Teil als einen Wert (die
Diplomarbeit
Die Methode von Booch • 33
Aggregationsbeziehung trägt ein ausgefülltes Quadrat auf
der Seite des Teils).
By reference
Das Aggregat enthält eine Referenz auf den enthaltenen
Teil (die Aggregationsbeziehung trägt ein leeres Quadrat
auf der Seite des Teils).
Manche objektorientierte Programmiersprachen (z.B.
Smalltalk) implementieren alle physischen
Enthaltenseinsbeziehungen als Referenzen.
2.2.2.6 Schlüssel
[KeyAttribute]
Assoziationen können mit Schlüsselattributen versehen sein. Der
Schlüssel ist ein Attribut, welches ein bestimmtes Zielobjekt eindeutig
identifizieren soll. Das Schlüsselattribut wird also verwendet, um durch
die Menge der Teilobjekte zu navigieren und ein bestimmtes Exemplar
ausfindig zu machen. Im Allgemeinen muss ein Schlüssel mit einem
Attribut der Teilklasse, welche Ziel der Assoziation ist, übereinstimmen.
Mehrfache Schlüssel sind zugelassen, die Werte müssen aber eindeutig
sein.
2.2.2.7 Einschränkungen (Constraints)
Eine Einschränkung ist ein semantischer Ausdruck, welcher
bezüglich der Klasse als Invariante zu betrachten ist und
deshalb stets erfüllt sein muss. Stets bedeutet in diesem
Zusammenhang, dass die Bedingung gelten muss, wenn
sich das System in einem stabilen Zustand befindet
(während Zustandsübergängen ist es erlaubt, die
Invarianten temporär zu verletzen).
Einschränkungen sind in geschweifte Klammern eingefasst
und können sowohl für Klassen als auch für Assoziationen
formuliert werden.
2.2.2.8 Notizen
Während der Analyse und dem Entwurf werden laufend Annahmen
gemacht und Entscheidungen getroffen, welche nicht direkt einem
Konstrukt einbeschrieben werden können und deshalb häufig im Kopf
des Entwerfers bleiben. Diese Praktik ist sehr gefährlich, weshalb das
Diagramm um ein Notizenelement bereichert wird, in welchem derartige
Informationen niedergeschrieben werden können. Die Notizen können
dabei - dargestellt durch eine gestrichelte Verbindungslinie - bezug auf
ein bestimmtes Element im Diagramm nehmen oder für das gesamte
Diagramm gelten.
Notes
2.2.3 Zustandsübergangsdiagramme
Ein Zustandsübergangsdiagramm wird verwendet, um den
Zustandsbereich einer bestimmten Klasse, die Ereignisse, welche
einen Zustandsübergang verursachen, und die Aktionen, die aus
einem Zustandswechsel resultieren, zu veranschaulichen. Die hier
beschriebenen Diagramme sind stark angelehnt an die Arbeit von
[Harel 87]. Ein bestimmtes Diagramm repräsentiert eine Ansicht
des dynamischen Modells einer einzelnen Klasse oder des
gesamten Systems. Nicht jede Klasse hat ein signifikantes
34 • Die Methode von Booch
Diplomarbeit
ereignisgesteuertes Verhalten, weshalb diese Art von Diagrammen
nur für Klassen mit einem derartigen Verhalten oder für das
Gesamtsystem sinnvoll sind. Während der Analyse werden das
Gesamtsystemdiagramm für die Modellierung des dynamischen
Verhaltens des Systems verwendet, während im Entwurf die
Zustandsübergangsdiagramme der einzelnen Klassen im Zentrum
des Interesses stehen. Die beiden zentralen Elemente des
Diagramms sind die Zustände und die Zustandsübergänge.
2.2.3.1 Zustände und Zustandsübergänge
name
actions
event/action
start
stop
Diplomarbeit
Der Zustand repräsentiert das Resultat des Verhaltens eines Objektes. Zu
einem gewissen Zeitpunkt besteht der Zustand aus allen Eigenschaften
(statisch) und aus den aktuellen Werten der Eigenschaften (dynamisch).
Unter Eigenschaften sei hier die Gesamtheit der Attribute und der
Beziehungen eines Objektes zu verstehen. Jeder Zustand muss einen im
Kontext eindeutigen Namen tragen. Zudem werden in der Zustandsikone
die möglichen Aktionen aufgeführt.
Ein Ereignis ist ein Vorkommnis, welches das System veranlasst, seinen
Zustand zu wechseln. Dieser Wechsel wird Zustandsübergang genannt.
Jeder Übergang verbindet zwei Zustände. Üblicherweise gehen von
einem Zustand mehrere Übergänge aus, welche eindeutig identifizierbar
sein müssen, damit beim Eintreten eines Ereignisses nicht mehr als ein
Übergang ausgelöst wird.
Eine Aktion ist eine Operation, welche sich üblicherweise
im Aufruf einer Methode, in der Auslösung eines
Ereignisses oder im Starten oder Stoppen einer Aktivität
äussert. Für die Modellierung des Zeitverhaltens wird dabei
angenommen, dass der Aufruf einer Methode oder das
Auslösen weiterer Ereignisse keine Zeit in Anspruch
nimmt, während die Aktivität eine gewisse Zeitspanne für
dessen Komplettierung benötigt.
In jedem Zustandsübergangsdiagramm muss genau ein Startzustand
enthalten sein. Dieser wird mit einem ausgefüllten Kreis dargestellt und
durch einen nicht bezeichneten Übergangspfeil mit einem Zustand
verbunden. Üblicherweise erreicht ein System nie einen Endzustand,
vielmehr befindet es sich in einem der definierten Zustände, bis das
umspannende Objekt zerstört wird. Soll dennoch ein Endzustand
modelliert werden, kann dem Diagramm ein Endknoten - dargestellt mit
einem ausgefüllten Kreis - hinzugefügt werden, zu welchem
Übergangspfeile, die ein Ereignis für das Erreichen des Endzustandes
beschreiben, zu zeichnen sind.
2.2.3.2 Weiterführende Konzepte
Die bisher beschriebenen Elemente sind meist nicht
ausreichend für die Modellierung von komplexen
Systemen. Aus diesem Grund müssen die Diagramme
erweitert werden, um die Semantik der Harel’schen
Zustandsdiagramme nachbilden zu können. Einige der
zusätzlichen Konstrukte sollen nachfolgend beschrieben
werden:
Die Methode von Booch • 35
Zustandsaktionen
Beim Eintritt in einen Zustand bzw. Austritt aus einem
Zustand können Aktionen gestartet bzw. gestoppt werden.
Derartige Zustandsaktionen werden als Aktionen in der
Zustandsikone durch die Verwendung der Schlüsselwörter
entry und exit niedergeschrieben.
Bedingte Zustandsübergänge
Zustandsübergänge werden üblicherweise durch Ereignisse
beschrieben. Reicht ein Ereignis als Voraussetzung für
einen Zustandsübergang nicht aus, kann sie durch die
Angabe einer bool’schen Bedingung, welche in eckigen
Klammern eingefasst dem Ereignisnamen nachgestellt
wird, erweitert werden.
Eingeschlossene Zustände
Durch die Einschliessung einer Gruppe von Zuständen in
einen höher abstrahierten Superzustand kann dem
Zustandsübergangsdiagramm eine gewisse Tiefe verliehen
werden. Derartige Superzustände können vor allem die
Strukturierung eines Diagramms fördern und bilden
wiederverwendbare Komponenten für die Beschreibung
von stets wiederkehrenden Mustern.
2.2.4 Objektdiagramme
Objektdiagramme werden verwendet, um die Existenz von
Objekten und deren Beziehungen im logischen Entwurf eines
Systems zu zeigen. Sie repräsentieren dabei eine zeitliche
Momentaufnahme der ansonsten dynamischen Konfiguration des
Systems. Ein Objektdiagramm agiert deshalb als Prototyp und
untersucht die Interaktionen und strukturellen Beziehungen einer
Menge von Objekten unter einem bestimmten Szenario. Die beiden
zentralen Elemente dieses Diagrammtyps sind die Objekte und
deren Beziehungen.
2.2.4.1 Objekte und ihre Beziehungen
object name
attributes
36 • Die Methode von Booch
Die Objektikone zur Darstellung eines Objektes innerhalb der
Objektdiagramme lehnt sich stark an diejenige der Klasse an, wobei die
gestrichelte Linie mit einer ausgezogenen ersetzt worden ist.
Einbeschrieben wird der Wolke zum einen der Name des Objektes,
welcher in der Form
nur Objektname
A
nur Objekttyp
:C
Objektname und Objekttyp
A:C
anzugeben ist, und zum anderen eine optionale Untermenge
der Objektattribute, welche in bereits für die
Klassenattribute beschriebenen Form zu spezifizieren sind.
Auch Instanzen von abstrakten Klassen oder Hilfsklassen
können im Objektdiagramm enthalten sein; sie werden
analog zu den entsprechenden Klassenikonen dargestellt.
Diplomarbeit
Verbindungen zwischen zwei Objekten werden als simple Linien
dargestellt und sind als Instanzen der entsprechenden Assoziationen
zwischen den instantiierten Klassen zu betrachten. Verbindungen werden
also als Kommunikationspfade zweier Objekte angesehen, über welche
Meldungen verschickt werden. Implizit besitzt jedes Objekt zu sich
selber einen derartigen Kanal und kann sich demnach auch selber
Nachrichten senden.
Eine Meldung besteht immer aus drei Elementen, nämlich
aus:
• einem Synchronisationssymbol, welches die Richtung
der Meldung angibt,
• einer Operation und
• optional einer Sequenznummer.
Dieser Meldungstyp zeigt die einfachste Form eines
Meldungsaustausches und kann seine Semantik nur dann
garantieren, wenn das System nur in einem einzigen
Kontrollfluss abläuft. Arbeiten mehrere asynchrone
Verarbeitungsprozesse konkurrenzierend zusammen,
müssen weiterführende Konzepte [Booch 94, pp. 212-217]
für die Synchronisation herangezogen werden.
messages
2.2.5 Interaktionsdiagramme
Ein Interaktionsdiagramm wird für die Veranschaulichung der
schrittweisen Abarbeitung eines gewissen Szenarios - meist dargestellt in
einem Objektdiagramm - verwendet. In der Tat ist ein
Interaktionsdiagramm bis zu einem gewissen Grad eine andere
Repräsentation des Objektdiagramms, welche aber den Vorteil mit sich
bringt, dass die relative Reihenfolge des Meldungsaustausches besser
abgelesen werden kann. Zudem können im Interaktionsdiagramm
zusätzlich Informationen über Verbindungen, Attributwerte, Rollen,
Datenflüsse und Sichtbarkeit enthalten sein.
2.2.5.1 Objekte und Interaktion
Meldungsaustausch,
Attributwerte,
Rollen, Datenflüsse
und Sichtbarkeit
object 1
object 2
object 3
object 4
event
operation()
operation()
script
operation()
event
Ein Interaktionsdiagramm wird in einer Art Tabelle
dargestellt. Die im Zentrum des Interesses liegenden
Objekte werde als Spaltenbeschriftungen angegeben.
Interaktionen werden in Form von horizontalen
Verbindungen der unterhalb der Objekte gezeichneten
vertikalen gestrichelten Linien definiert. Dabei wird die
Notation aus den Objektdiagrammen übernommen. Die
Diplomarbeit
Die Methode von Booch • 37
Interaktionssequenz wird durch die horizontale Position der
entsprechenden Interaktionen definiert und kann deshalb
direkt aus dem Diagramm gelesen werden.
2.2.6 Moduldiagramme
Ein Moduldiagramm wird verwendet, um die Allokation der
Klassen und Objekte im physischen Entwurf eines Systems zu
verdeutlichen. Ein einzelnes Moduldiagramm repräsentiert die
Ansicht der Modulstruktur eines Systems, welche in der
Implementierung die Aufteilung der Architektur in physische
Bereiche und Schichten erlaubt.
2.2.6.1 Module und ihre Abhängigkeiten
Module repräsentieren Dateien von drei verschiedenen
Typen, die sich in ihrer Funktion unterscheiden:
Hauptprogramm
Das Hauptprogramm beinhaltet die Wurzel des Programmes (in
C++ ist dies meist die ungebundene Funktion main).
Typischerweise existiert in jedem Programm genau ein
Hauptprogramm.
name
main program
Spezifikationen
Die Spezifikation enthält die Deklaration von Entitäten (in C++
sind dies meist Headerdateien mit der Extension *.h)
name
specification
Rumpf
Der Rumpf enthält die Definition der deklarierten Entitäten (in
C++ sind dies meist Implementationsdateien mit der Extension
*.cpp)
name
body
Jedes Modul besitzt einen eindeutigen Namen, der
idealerweise mit dem physischen Namen der Datei
übereinstimmt. Die Extension wird dabei weggelassen, da
sie aus dem Modultyp gelesen werden kann.
Sind zwei Module miteinander verbunden, so ist dies als
eine Anweisung für den Compiler zu interpretieren. Zeigt
nämlich ein Modul mit einem Pfeil auf ein anderes Modul,
so besteht zwischen den beiden eine Abhängigkeit, was
bedeutet, dass für die Kompilation des einen das andere
bekannt sein muss (in C++ werden derartige
Abhängigkeiten in include Direktiven umgesetzt).
2.2.6.2 Subsysteme
38 • Die Methode von Booch
Diplomarbeit
name
Ein grosses System kann mehrere Hundert, wenn nicht mehrere Tausend
physische Module besitzen. Ein solches System zu überblicken ist ohne
weitere Strukturierung nicht möglich. Analog zu den Klassenkategorien,
welche Klassen innerhalb eines Bereiches oder einer bestimmten Schicht
zusammenfassen, lassen sich Module in Subsysteme einordnen.
Subsysteme beinhalten Module und/oder weitere
Subsysteme. Dabei muss Modul in genau einem Subsystem
enthalten oder global definiert sein. Die Namensgebung
folgt keiner speziellen Regel, da Subsysteme nur
Strukturierungshilfen sind und deshalb deren Namen nicht
in physische Dateinamen umgesetzt werden.
2.2.7 Prozessdiagramme
Prozessdiagramme werden verwendet, um die Zuordnung der
Prozesse zu Prozessoren im physischen Entwurf zu zeigen. Ein
einzelnes Prozessdiagramm repräsentiert eine Ansicht der
Prozessstruktur eines Systems. Während der Entwicklung werden
Prozessdiagramme verwendet, um die physische Sammlung der
Prozessoren und Geräte, welche uns als Plattform für die
Ausführung zur Verfügung stehen, zu identifizieren.
2.2.7.1 Prozessoren und Geräte
Ein Prozessor ist als Teil der Hardware, der ein Programm ausführen
kann, zu betrachten. Dem Prozessor werden Prozesse zugeordnet, welche
mit den Hauptprogrammen aus dem Moduldiagramm übereinstimmen.
name
Prozessor
name
Gerät
Ein Gerät hingegen wird als Hardwarekomponente aufgefasst, welche
keine Programme ausführen kann, aber dennoch für die Verarbeitung
notwendig ist.
Prozessoren werden mit Geräten verbunden, um eine Koppelung der
beiden Komponenten zu verdeutlichen. Verbindungen können sich dabei
sowohl auf dieselbe Maschine beziehen (Festplatte und Prozessor) oder
als auch auf geographisch weit entfernte Rechnungseinheiten (Netzwerk).
2.2.8 Anwendung der Notation
Typischerweise wird ein System mit Hilfe einer Menge von
Objektdiagrammen (für die Modellierung des Verhaltens eines
Systems in diversen Szenarien), Klassendiagrammen (für die
Modellierung der Rollen und Verantwortlichkeiten der beteiligten
Entitäten) und Zustandsübergangsdiagrammen (für die
Modellierung des ereignisgesteuerten Verhaltens der Entitäten)
analysiert. Für den Entwurf werden zusätzlich Moduldiagramme
und Prozessdiagramme miteinbezogen.
Diplomarbeit
Die Methode von Booch • 39
Verbindungen
zwischen den
Diagrammen
Zwischen den verschiedenen Diagrammen existieren Verbindungen. So
ist es beispielsweise möglich, von der Implementation ausgehend die
Anforderungen an das System zu identifizieren. Startet man
beispielsweise von einem Prozessor, für welchen ein bestimmter Prozess
zur Ausführung vorgesehen ist, findet man im Moduldiagramm ein
entsprechendes Hauptprogramm, welches seinerseits verschiedene
Module aufruft. Diese Module beinhalten Klassen bzw. Objekte, deren
Eigenschaften aus dem Klassendiagramm bzw. Objektdiagramm
ausgelesen werden können. Zum Schluss versinnbildlichen die
Definitionen der Klassen die Anforderungen des Systems, da diese im
Allgemeinen direkt die Objekte im Problembereich reflektieren.
Werkzeuge für die
Sicherung der
Komplettheit und
der Konsistenz
Die Anwendung der beschriebenen Notation kann manuell erfolgen,
jedoch kann der Entwurfsprozess in grösseren Systemen durch
Werkzeuge für die Überprüfung der Komplettheit und der Konsistenz
erheblich beschleunigt und sicherer gemacht werden. Zudem eignet sich
die Methode sowohl für die Beschreibung von kleinen (ca. zehn Klassen)
als auch von grossen (mehrere Tausend Klassen) Systemen. Die
weitgehend erreichte Sprachunabhängigkeit fokussiert nicht zu früh auf
eine spezifische Implementationssprache und lässt die Wahl der
Zielsprache bis zum Abschluss des Entwurfes offen.
2.3 Das Vorgehen
Erfolgreiche Softwareprojekte zeichnen sich dadurch aus, dass sie zum
einen einer starken architektonischen Vision folgen und zum anderen
einen gut verwalteten iterativen und inkrementellen Entwicklungsprozess
anwenden.
Die architektonische Vision ist deshalb von essentieller Wichtigkeit, da
sie die Verständlichkeit, die Erweiterbarkeit, die Fähigkeit, ein System zu
reorganisieren, testen und warten, unterstützt. Gute Architekturen
zeichnen sich dadurch aus, dass sie
• aus mehreren wohldefinierten Schichten zusammengesetzt sind, wobei
jede Schicht eine kohärente Abstraktionsstufe repräsentiert, durch eine
kontrollierte Schnittstelle zugänglich ist und auf einer gleichsam
wohldefinierten Schnittstelle der darunterliegenden Schicht aufsetzt.
• innerhalb jeder Schicht klar zwischen Schnittstelle und Implementation
unterscheiden und so dem Entwickler ermöglicht, die Implementation zu
ändern, ohne die Schnittstelle zu verletzen.
• einfach sind, d.h. einfaches Verhalten durch einfache Abstraktion
umsetzen.
Objektorientierte Architekturen tendieren dazu, die genannten
Eigenschaften guter Architekturen besser zu unterstützen als andere, was
aber nicht zur Irrmeinung verleiten sollte, dass einzig die
objektorientierten diesbezüglich gute Resultate liefern oder jeglicher
objektorientierter Architekturentwurf gut ist.
Während des Architekturentwurfsprozesses müssen laufend
Entscheidungen getroffen werden. Dabei gilt es zwischen strategischen
und taktischen Entscheidungen zu unterscheiden.
architektonische
Vision
40 • Die Methode von Booch
Diplomarbeit
Strategische
Entscheidungen
Strategische Entscheidungen wirken auf die Gesamtarchitektur eines
Systems und beeinflussen nicht selten sogar die übergeordneten
Organisationsformen und -strukturen. Bespiele hierfür sind Mechanismen
für Fehlerentdeckung und -behebung, Politik der Speicherverwaltung
oder Schnittstellenphilosophie.
taktische
Entscheidungen
Dahingegen haben taktische Entscheidungen meist nur lokale
Implikationen und beeinflussen lediglich die Details von
Implementationen, bzw. Schnittstellen. Die Änderung der Signatur einer
Methode gehört beispielsweise in diese Kategorie von Entscheidungen.
iterativer und
inkrementeller
Entwicklungszyklus
Erfolgreiche Entwicklungsprojekte verfolgen häufig sowohl einen
iterativen, als auch einen inkrementellen Entwicklungszyklus. Iterativ
bedeute dabei, dass die objektorientierte Architektur sukzessive verfeinert
wird, wobei die Erfahrungen aus der einen Iteration auf die nächste
übertragen werden, während inkrementell bedeutet, dass jeder Durchlauf
Analyse/Design/Evolution die strategischen und taktischen
Entscheidungen unter der Berücksichtigung von zusätzlichen
Anforderungen verfeinert, um am Ende die echten Bedürfnisse des
Benutzers befriedigen zu können, und dennoch eine einfache und
adaptierbare Lösung zu erzielen.
„top-down“ und
„bottom-up“
Vorgehen
Der iterative und inkrementelle Entwicklungszyklus steht im Gegensatz
zum traditionellen Wasserfallmodell und ist dementsprechend weder ein
striktes „top-down“ noch „bottom-up“ Vorgehen. Vielmehr handelt es
sich um ein „round-trip gestalt design“, welches die iterative und
inkrementelle Entwicklung eines Systems als Ganzes - durch die
Verfeinerung von verschiedenen noch konsistenten logischen und
physischen Sichten - betont.
Rationales
Entwurfsverfahren
Um den beschriebenen Entwicklungszyklus, auch Rationales
Entwurfsverfahren genannt, erfolgreich umsetzen zu können, muss die
betraute Softwareorganisation über einen gewissen Reifegrad [Humphrey
89, p. 5] verfügen.
2.3.1 Mikroentwicklungsprozess
Der Mikroentwicklungsprozess wird vor allem von den Szenarien
und architektonischen Entscheidungen gesteuert, die vom
Makroentwicklungsprozess stammen und dort auch schrittweise
verfeinert werden. Er spielt sich im Mikrobereich des Systems ab,
da er sich mit den täglichen Aktivitäten eines Entwicklers oder
eines kleinen Entwicklungsteams beschäftigt. Von ihm sind
gleichsam der Softwareingenieur, der die taktischen
Entscheidungen zu treffen hat, und der Softwarearchitekt, der aus
den Erfahrungen neue Alternativentwürfe ableitet, involviert.
Im Mikroprozess sind die traditionellen Phasen der Analyse und des
Designs stark vermischt. Insbesondere kann kein Kochbuchrezept
aufgezeigt werden, welches die Intelligenz und die Erfahrung eines
versierten Entwerfers ersetzen kann.
Trotzdem tendieren die Vorgehensweisen darauf hin, die folgenden
Aktivitäten zu unternehmen:
Analyse und Design
Diplomarbeit
Die Methode von Booch • 41
• Identifikation der Klassen und Objekte auf einer bestimmten
Stufe der Abstraktion,
• Identifikation der Semantik dieser Klassen und Objekte,
• Identifikation der Beziehungen zwischen diesen Klassen und
Objekten,
• Spezifikation der Schnittstellen zwischen diesen Klassen und
Objekten und
• Implementation dieser Klassen und Objekte.
Für detailliertere Angaben zu den einzelnen Aktivitäten sei direkt
auf [Booch 94, pp. 235-248] verwiesen.
2.3.2 Makroentwicklungsprozess
Risiko,
Zielerreichung,
Termin und Kosten
technisches
Management
Der Makroentwicklungsprozess umspannt einem Rahmen gleich den
Mikroentwicklungsprozess und kontrolliert ihn stets bezüglich Risiko,
Zielerreichung, Termin und Kosten, um frühzeitig korrigierend auf ihn
einwirken zu können. Die meisten dieser Aktivitäten, beispielsweise
Konfigurationsmanagement, Qualitätssicherung, Dokumentation, usw.,
gleichen den üblichen Managementaufgaben und sind deshalb
keineswegs auf objektorientierte Systeme allein zutreffend.
Der Makroprozess beschäftigt sich also mit dem technischen
Management der Entwicklungsteams, indem er die Optik des
Endbenutzers berücksichtigt, der weniger an technischen Details
interessiert ist, als an Qualität, Vollständigkeit und Korrektheit. Er
kümmert sich also um das Risiko und die architektonische Vision,
welches die beiden Elemente sind, die den grössten Einfluss auf die
genannten Kundenwünsche haben.
Der Ablauf ist im Gegensatz zum „kleinen“ Prozess streng
geordnet und beinhaltet folgende Schritte:
• Erfassen der Grundanforderungen an die Software
(Konzeptualisierung),
• Entwicklung eines Modells des vom System gewünschten
Verhaltens (Analyse),
• Entwurf der Architektur für die Implementation (Design),
• Weiterentwicklung der Implementation durch sukzessives
Verfeinern (Evolution) und
• Verwaltung der Weiterentwicklungen nach Auslieferung
(Wartung).
Für die meisten Entwicklungsprozesse wiederholt sich dieser
Prozess nach jeder Auslieferung einer Softwareversion. Die
Philosophie dahinter ist, dass jede Folgeversion aus der Vorversion
und einiger zusätzlicher Funktionalität bestehen soll.
Für detailliertere Angaben zu den einzelnen Schritten sei direkt auf
[Booch 94, pp. 250-264] verweisen.
42 • Die Methode von Booch
Diplomarbeit
3 Schwachstellenanalyse
3.1 Einleitung
)UGLH,GHQWLILNDWLRQGHU6FKZDFKVWHOOHQZXUGH]XHUVWGLH/LWHUDWXU
KHUDQJH]RJHQYJOEHLVSLHOVZHLVH>[email protected],QGHQYHUVFKLHGHQHQLQGDV
6WXGLXPHLQEH]RJHQHQ$UWLNHOQXQG%FKHUQZXUGHQYRUDOOHPGLH$VSHNWH
GHUODQJIULVWLJDXVJHULFKWHWHQ'DWHQEDQNDQZHQGXQJHQGLVNXWLHUW
$QVFKOLHVVHQGPXVVWHQIUGLHJHQDXHUH8QWHUVXFKXQJHLQHUVHLWVHLQH
EHVWLPPWH0HWKRGHXQGDQGHUHUVHLWVHLQHNRQNUHWH
'DWHQEDQNLPSOHPHQWLHUXQJDXVJHZlKOWZHUGHQ'LH:DKOPXVVWHVR
JHWURIIHQZHUGHQGDVVNRQNUHWH$XVVDJHQP|JOLFKWVLQGXQGGHQQRFKNHLQH
DOO]XVWDUNHQ(LQVFKUlQNXQJHQGHU$OOJHPHLQKHLWGDUDXVUHVXOWLHUHQ
%HLGHPQDFKIROJHQGHQ9HUVXFKGLH(QWZXUIVPHWKRGHDXIGDV
'DWHQEDQNV\VWHPDE]XELOGHQZXUGHXQWHUVXFKWZHOFKHVGLH
8Q]XOlQJOLFKNHLWHQVLQGGLHVVRZRKODXIGHUNRQ]HSWXHOOHQDOVDXFKDXIGHU
ORJLVFKHQ(EHQH
(UIDKUXQJHQZXUGHQYRUDOOHPGXUFKGLH$QZHQGXQJGHU(QWZXUIVPHWKRGH
DXIJHHLJQHWH)DOOVWXGLHQJHZRQQHQ8QWHUVXFKWZXUGHQLP6SH]LHOOHQ
• GLHÅ,QVWLWXWVDGPLQLVWUDWLRQ´GLHEHUHLWVIUGDV'DWHQEDQNV\VWHP2
LPSOHPHQWLHUWXQGLQ>*[email protected]
• GLHÅ1DWLRQDOH+RFNH\OLJD´ZHOFKHDOV%HLVSLHOHLQHUUHODWLRQDOHQ
'DWHQEDQNLP5DKPHQHLQHV'DWHQEDQNSUDNWLNXPVDQGHU8QLYHUVLWlW
=ULFKHQWZRUIHQXQGLPSOHPHQWLHUWZRUGHQLVW
• GDVÅ+\GURSRQLF*UDGHQLQJ6\VWHP´ZHOFKHVDOVGDVOHLWHQGH%HLVSLHOLQ
GHQ$XVIKUXQJHQYRQ>%[email protected]
HQWZRUIHQZXUGHXQG
• GLHÅ.RQIHUHQ]DGPLQLVWUDWLRQ´ZHOFKHLQYHUVFKLHGHQHQ$UWLNHOQ
LQVEHVRQGHUHDEHU>*[email protected]]RJHQ
ZRUGHQLVW
$QVFKOLHVVHQGZXUGHQGLHJHIXQGHQHQ6FKZDFKSXQNWHPLWGHQ(UIDKUXQJHQ
YRQ3HUVRQHQGLHZLVVHQVFKDIWOLFKXQGLQGHU3UD[LVGLHVHP3UREOHP
JHJHQEHUJHVWDQGHQKDEHQDEJHJOLFKHQHUJlQ]WXQGGHWDLOOLHUW'LH
(UIDKUXQJVEHULFKWHZXUGHQGXUFK,QWHUYLHZVPLW
• $QGUHDV*HSSHUWVWHOOYHUWUHWHQGHU/HLWHUGHV,QVWLWXWVIU,QIRUPDWLN
$XWRUGHV%XFKHV>*[email protected]'R]HQWLQYHUVFKLHGHQHQ3UDNWLNDGHU
9HUDQVWDOWXQJÅ2EMHNWRULHQWLHUWH'DWHQEDQNHQ´
• $QGUHDV%HKP0LWDUEHLWHULQYHUVFKLHGHQHQ3URMHNWHQZHOFKHVLFK
ZLVVHQVFKDIWOLFKPLWGHQREMHNWRULHQWLHUWHQ'DWHQEDQNHQDXVHLQDQGHUVHW]HQ
XQG$VVLVWHQWYRQGLYHUVHQ9HUDQVWDOWXQJHQGLHDOV7KHPHQVFKZHUSXQNWGLH
REMHNWRULHQWLHUWHQ'DWHQEDQNHQEHKDQGHOQXQG
• 7KRPDV:VWHKHPDOLJHU$VVLVWHQWDP,QVWLWXWIU,QIRUPDWLNGHU
8QLYHUVLWlW=ULFKXQGJHJHQZlUWLJHU0LWDUEHLWHUGHU&669HUVLFKHUXQJHQ
XQGGRUWEHWUDXWPLWGHU/HLWXQJYRQ(QWZLFNOXQJVSURMHNWHQZHOFKHGHQ
(QWZXUIGLH,PSOHPHQWDWLRQGHQ%HWULHEXQGGLH:DUWXQJYRQJURVVHQ
2'%06EDVLHUWHQ,QIRUPDWLRQVV\VWHPHQ]XP*HJHQVWDQGKDEHQ
HUPLWWHOWXQGLQGLH$XVDUEHLWXQJDXIJHQRPPHQ
3.1.1 Typisierung
:HQQYRQ6FKZDFKVWHOOHQGLH5HGHLVWVROOWHGLHVHU%HJULIIHWZDV
QlKHUEHOHXFKWHWZHUGHQ
Diplomarbeit
Schwachstellenanalyse • 43
$XIGHUHLQHQ6HLWHILQGHQZLUGHQNRQ]HSWXHOOHQ(QWZXUIXQGDXI
GHUDQGHUHQ6HLWHGLHORJLVFKHQSK\VLVFKHQ'DWHQVFKHPDWD
6FKZDFKVWHOOHQN|QQHQGXUFKIROJHQGH6LWXDWLRQHQDXIWUHWHQ
6FKZDFKVWHOOHQDXIORJLVFKHU(EHQH
'HUNRQ]HSWXHOOH(QWZXUIHQWKlOWHLQ.RQVWUXNWZHOFKHVDXIGHU
(EHQHGHU'DWHQEDQNHQQLFKWXQWHUVWW]WZLUG
6FKZDFKVWHOOHQDXINRQ]HSWXHOOHU(EHQH
'HUORJLVFKH(QWZXUIHQWKlOWHLQ.RQVWUXNWZHOFKHVDXIGHU
NRQ]HSWXHOOHQ(EHQHQLFKWXQWHUVWW]WZLUG
,QNRPSDWLELOLWlWHQ
6RZRKOGHUNRQ]HSWXHOOHDOVDXFKGHUORJLVFKH(QWZXUIHQWKDOWHQHLQ
.RQVWUXNWZHOFKHVDEHULQGHQEHLGHQYHUVFKLHGHQHQ:HOWHQHLQH
XQWHUVFKLHGOLFKH6HPDQWLNWUlJW
9HUPLVVWH.RQVWUXNWH
,P6WDQGDUG2'0*VLQG.RQVWUXNWHGHILQLHUWGLHZHGHULQGHQ
0HWKRGHQIUGHQNRQ]HSWXHOOHQ(QWZXUIQRFKLQGHQDNWXHOOHQ
,PSOHPHQWDWLRQHQHQWKDOWHQVLQG=XGHPVLQGYRQ
'DWHQEDQNDGPLQLVWUDWRUHQXQG(QWZLFNOHUQYRQJURVVHQ6\VWHPHQ
DXVGHU3UD[LV.RQVWUXNWHJHIRUGHUWZRUGHQGLHDXVLKUHU6LFKWDXI
GHUHLQHQ6HLWHLKUH$UEHLWHUOHLFKWHUQXQGDQGHUHUVHLWVGLH6\VWHPH
VWDELOHUXQGEHVVHUZDUWEDUPDFKHQZUGHQ
'D]XNRPPHQQRFKVlPWOLFKH6FKZDFKVWHOOHQGLHYRQ
YHUVFKLHGHQHQ$XWRUHQYOJGD]X]%>[email protected]]HLJW
ZRUGHQVLQGGLH
• GHQ6RIWZDUHHQWZXUI
• GLH'DWHQPRGHOOLHUXQJLQVEHVRQGHUHGHQREMHNWRULHQWLHUHQ
(QWZXUI
• GHQ'DWHQEDQNHQWZXUI
LP$OOJHPHLQHQEHWUHIIHQ'LHVH3UREOHPHZHUGHQLQGHU
YRUOLHJHQGHQ$XVDUEHLWXQJDXVVHU%HWUDFKWJHODVVHQ6LHVROOHQ
*HJHQVWDQGZHLWHUHU)RUVFKXQJHQLP%HUHLFKGHV6RIWZDUHHQWZXUIHV
VHLQ
'LH6FKZDFKVWHOOHQDXIGHUORJLVFKHQ(EHQHKDEHQLKUH8UVDFKHLQ
8Q]XOlQJOLFKNHLWHQVHLWHQVGHVXQWHUVXFKWHQ'DWHQEDQNV\VWHPVXQG
ZHUGHQLPHQWVSUHFKHQGHQ$EVFKQLWWQXUVXPPDULVFK
ZLHGHUJHJHEHQ
,QNRPSDWLELOLWlWHQ]ZLVFKHQGHUJHZlKOWHQ(QWZXUIVPHWKRGHXQG
GHU'DWHQEDQNLPSOHPHQWDWLRQZXUGHQNHLQHJHIXQGHQ9LHOPHKU
ZXUGHQ.RQVWUXNWHEHLGHQHQHLQJHZLVVHV9HUGDFKWVPRPHQW
EHVWDQGHQKDW]%LQYHUVH%H]LHKXQJHQDXIJUXQGGHUVWDUNHQ
'LIIHUHQ]GHQYHUPLVVWHQ.RQVWUXNWHQ]XJHWHLOW
'LHNRQ]HSWXHOOHQ6FKZDFKVWHOOHQXQGYHUPLVVWHQ.RQVWUXNWH
KLQJHJHQVLQGLPIROJHQGHQGHWDLOOLHUWGLVNXWLHUW=XHUVWLVWGLH
3UREOHPDWLNXQWHU$QJDEHJHZLVVHUEHJULIIOLFKHU'HILQLWLRQHQLP
$OOJHPHLQHQXPULVVHQDQVFKOLHVVHQGGLH.RQVHTXHQ]HQIUGHQ
NRQ]HSWXHOOHQ(QWZXUIDXIJH]HLJWXQGVFKOLHVVOLFKGLH6FKZDFKVWHOOH
IUGLHZHLWHUH9HUZHQGXQJLQGHQIROJHQGHQ.DSLWHOQ
]XVDPPHQJHIDVVW
,QGHU(YDOXDWLRQVFKOLHVVOLFKZHUGHQGLHJHIXQGHQHQ6FKZDFKVWHOOHQ
LQEH]XJDXIGLH%HGUIQLVVHGHVNRQ]HSWXHOOHQ(QWZXUIHVJHZLFKWHW
XQGHLQH$XVZDKOIUGLHZHLWHUH%HDUEHLWXQJJHWURIIHQ
44 • Schwachstellenanalyse
Diplomarbeit
3.2 Schwachstellen auf logischer Ebene
3.2.1 Aggregation
(VJLEWNHLQH$JJUHJDWLRQZLHVLHLPREMHNWRULHQWLHUWHQ3DUDGLJPD
JHIRUGHUWLVW'XUFKGLH'HILQLWLRQYRQNRPSOH[HQ$WWULEXWHQLQ
)RUPYRQ6WUXNWXUHQ7XSOHVNDQQHLQlKQOLFKHV9HUKDOWHQ
HU]ZXQJHQZHUGHQ:LUGHLQ$WWULEXWYRP7\S.ODVVH$HLQHU.ODVVH
%]XJHRUGQHWZLUGGLHVOHGLJOLFKDOV=HLJHUDXIGLH.ODVVH$
LQWHUSUHWLHUW
3.2.2 Überladung
(VJLEWNHLQHhEHUODGXQJ3RO\PRUSKLVPXVLVWQXUGXUFK
hEHUVFKUHLEHQXQGVSlWHV%LQGHQLPSOHPHQWLHUWhEHUVFKUHLEXQJ
NDQQQXUGXUFK6SH]LDOLVLHUXQJJHPDFKWZHUGHQ
3.2.3 Konstruktoren und Destruktoren
,Q2JLEWHVNHLQH.RQVWUXNWRUHQRGHU'HVWUXNWRUHQ'HU
.RQVWUXNWRUZLUGPLWGHU,PSOHPHQWLHUXQJHLQH,QLW0HWKRGH
VLPXOLHUW'LHVHNHQQWDEHUNHLQHhEHUODGXQJ'HU'HVWUXNWRUNHQQW
NHLQH(QWVSUHFKXQJLQ)RUPHLQHU'H,QLW0HWKRGHRGHUHWZDV
bKQOLFKHP
3.2.4 Weitere Schwachstellen
'DVEHWUDFKWHWH'DWHQEDQNV\VWHPXQWHUVWW]WQLFKWDOOHLQGHU
(QWZXUIVPHWKRGHHLQJHIKUWHQ.ODVVHQW\SHQ6RHQWEHKUHQ
EHLVSLHOVZHLVHDEVWUDNWHQ.ODVVHQ)UHXQGVFKDIWVNODVVHQIULHQGRGHU
HLQJHEHWWHWH.ODVVHQQHVWLQJHLQHU(QWVSUHFKXQJDXIGHUORJLVFKHQ
(EHQH
3.3 Schwachstellen auf konzeptueller
Ebene
3.3.1 Persistenz
(LQ2EMHNWZLUGSHUVLVWHQWJHQDQQWZHQQHVDXFKEHUGLH
/HEHQV]HLWGHV3URJUDPPHVLQGHPHVHU]HXJWZXUGHKLQDXV
JHVSHLFKHUWEOHLEW3HUVLVWHQ]LVWGHPQDFKGLH]HQWUDOH)RUGHUXQJDQ
HLQ22'%06,QGHQYHUVFKLHGHQHQ'DWHQEDQNV\VWHPHQLVWDEHUGLH
3HUVLVWHQ]XQWHUVFKLHGOLFKLPSOHPHQWLHUW
8P0LVVYHUVWlQGQLVVHQYRU]XEHXJHQLVWHVDEHUVLFKHUOLFK]XHUVWVLQQYROO
3HUVLVWHQ]7UDQVLHQ]
GLH%HJULIIH3HUVLVWHQ]XQG7UDQVLHQ]]XGHILQLHUHQ=XGHPZLUGGLH
XQG3HUVLVWHQ]IRUW
3HUVLVWHQ]IRUWSIODQ]XQJIUGDV'DWHQEDQNV\VWHP2HUOlXWHUW
SIODQ]XQJ
3HUVLVWHQ]
.|QQHQ,QVWDQ]HQHLQHU.ODVVHSHUVLVWHQWVHLQVRKHLVVWGLHVH.ODVVH
persistenzfähig'HU(LQIDFKKHLWKDOEHUZLUGDEHUKlXILJQXUGHU
%HJULIISHUVLVWHQWYHUZHQGHW3HUVLVWHQWH.ODVVHQPVVHQDOVRQLFKW
DXVVFKOLHVVOLFKSHUVLVWHQWH,QVWDQ]HQHU]HXJHQ
7UDQVLHQ]
,P*HJHQVDW]GD]XZLUGGHU%HJULIIGHU7UDQVLHQ]IU.ODVVHQ
YHUZHQGHWGHUHQ,QVWDQ]HQQLFKWSHUVLVWHQWJHPDFKWZHUGHQGUIHQ
3HUVLVWHQ]IRUWSIODQ]XQJ
,QQHUKDOEGHU'DWHQEDQNXPJHEXQJ2JLOWGHU*UXQGVDW]GHU
Å3HUVLVWHQ]GXUFK(UUHLFKEDUNHLW´>*[email protected],P
EHUWUDJHQHQ6LQQHKHLVVWGDVGDVVVLFKGLH3HUVLVWHQ]YRQ,QVWDQ]HQ
OlQJVGHU5HIHUHQ]HQIRUWSIODQ]W(QWKlOWDOVRGLH.ODVVH$HLQH
Diplomarbeit
Schwachstellenanalyse • 45
5HIHUHQ]DXIGLH.ODVVH%VRZLUGGLH3HUVLVWHQ]VRIHUQGLH,QVWDQ]
$QGHU.ODVVH$EHUHLWVSHUVLVWHQWLVWDXIGLH,QVWDQ]%PEHUWUDJHQ
3.3.1.1 Einstiegspunkt
SHUVLVWHQWH1DPHQ
'LHVH$UWGHU)RUWSIODQ]XQJYHUODQJWIUHLQH6FKHPDGHILQLWLRQPLQGHVWHQV
HLQHQSHUVLVWHQWHQ(LQVWLHJVSXQNW'LHVHUPXVVHLQH,QVWDQ]HLQHU
SHUVLVWHQ]IlKLJHQ.ODVVHVHLQXQGNDQQGHPQDFKDOVJOREDOHV2EMHNW
EHWUDFKWHWZHUGHQ'LHJOREDOH,QVWDQ]ZLUGEHUGHQVRJHQDQQWHQ
SHUVLVWHQWHQ1DPHQLGHQWLIL]LHUW
:XU]HOGHV
3HUVLVWHQ]JUDSKHQ
,VWHLQHVROFKHU(LQVWLHJVSXQNWHLQPDOGHILQLHUWZHUGHQVlPWOLFKHYRQLKU
UHIHUHQ]LHUWHQ,QVWDQ]HQJOHLFKIDOOVSHUVLVWHQW'HU(LQVWLHJVSXQNWNDQQDOVR
EH]JOLFKGHU3HUVLVWHQ]IRUWSIODQ]XQJDOV:XU]HOGHV3HUVLVWHQ]JUDSKHQ
EHWUDFKWHWZHUGHQ
3.3.1.2 Schwachstelle
'LH'HILQLWLRQYRQSHUVLVWHQWHQ(LQVWLHJVSXQNWHQZLUGLQGHU
6FKHPDGHILQLWLRQDOVRPLW2'/HUOHGLJW$XVGLHVHP*UXQG
PXVVGLH3HUVLVWHQ]GHNODUDWLRQDXFKLQGHU(QWZXUIVVSUDFKH
HQWKDOWHQVHLQ(LQGHUDUWLJHV.RQVWUXNWVWHKWMHGRFKQLFKW
]XU9HUIJXQJ
=XGHPIHKOHQLQGHU(QWZXUIVQRWDWLRQ.RQVWUXNWHZHOFKHHV
GHP(QWZHUIHUHUODXEHQGLH.RQWUROOHEHUGLH
3HUVLVWHQ]IRUWSIODQ]XQJ]XEHUQHKPHQ%HLGHUEHWUDFKWHWHQ
(QWZXUIVVSUDFKHNDQQQLFKW]ZLVFKHQGHQ$VVR]LDWLRQHQPLW
RGHURKQH(LQIOXVVDXIGLH3HUVLVWHQ]XQWHUVFKLHGHQZHUGHQ
3.3.2 Applikationsklassen und -instanzen
+DQGLQ+DQGPLWGHU8QWHUVFKHLGXQJ]ZLVFKHQSHUVLVWHQWHQXQG
WUDQVLHQWHQ.ODVVHQJHKWGLH8QWHUVFKHLGXQJ]ZLVFKHQ'DWHQNODVVHQ
ZHOFKHEHUGLH/HEHQV]HLWGHU$SSOLNDWLRQKLQDXVHUKDOWHQEOHLEHQ
VROOHQXQG$SSOLNDWLRQVNODVVHQZHOFKHIUGLH0RGHOOLHUXQJGHU
$QZHQGXQJQ|WLJVLQG
%HLGLHVHU$EJUHQ]XQJPVVHQIUGHQ(QWZXUIGLH3UREOHPEHUHLFKH
GHU3HUVLVWHQ]GHU6FKQLWWVWHOOHQGHILQLWLRQXQGGHU3OD]LHUXQJGHU
0HWKRGHJHQDXHUEHWUDFKWHWZHUGHQ
3.3.2.1 Persistenz
,QJHZLVVHQ'DWHQEDQNV\VWHPHQVLQGGLH$SSOLNDWLRQHQ
VHOEHUQLFKWDOV.ODVVHQLPSOHPHQWLHUW7URW]GHPN|QQHQVLH
ZlKUHQGLKUHU/HEHQV]HLW2EMHNWHZHOFKHJHZLVVH
)XQNWLRQDOLWlWHQNDSVHOQRGHUDXFKQXU]XUWHPSRUlUHQ
6SHLFKHUXQJYRQ'DWHQGLHQHQDOOR]LHUHQ'LHVH2EMHNWH
DEHUPVVHQQDFKGHU7HUPLQLHUXQJGHU$QZHQGXQJDOOHVDPW
]HUVW|UWZRUGHQVHLQXQGGUIHQVLFKVRPLWQLFKWPHKULQGHU
'DWHQEDVLVEHILQGHQ
'LH(QWZXUIVPHWKRGHVROOWHDOVRGHP(QWZHUIHUHUODXEHQ
GLHVHQ8PVWDQGEHUHLWVZlKUHQGGHV'HVLJQV]X
EHUFNVLFKWLJHQ
3.3.2.2 Definition der Schnittstellen
%RRFKNHQQWLQVHLQHU(QWZXUIVPHWKRGHGDV.RQVWUXNWGHU
0RGXO'LDJUDPPH,QGLHVHQ'LDJUDPPHQZHUGHQGLH
SK\VLVFKHQ0RGXOHYRQHLQDQGHUDEJHJUHQ]W=XVlW]OLFK
N|QQHQ6XEV\VWHPHGHILQLHUWZHUGHQ
46 • Schwachstellenanalyse
Diplomarbeit
'LHVH0HWKRGHNHQQWDEHUGLH6FKZDFKVWHOOHGDVV
6FKQLWWVWHOOHQ]ZLVFKHQGHQHLQ]HOQHQ0RGXOHQQLFKWJHQDXHU
VSH]LIL]LHUWZHUGHQN|QQHQ9LHOPHKULVWGHU=XVDPPHQKDOW
GDV=XVDPPHQVSLHOGHU(OHPHQWHY|OOLJRIIHQJHODVVHQ
:UGHPDQEHLVSLHOVZHLVHHLQHUVHLWVGLHMHQLJHQ.ODVVHQGLH
GDVORJLVFKH'DWHQEDQNVFKHPDPRGHOOLHUHQLQHLQ0RGXO
6XEV\VWHPYHUSDFNHQXQGDQGHUHUVHLWVGLHMHQLJHQZHOFKH
GLH$SSOLNDWLRQYHUVLQQELOGOLFKHQLQHLQDQGHUHV0RGXO
HLQEHWWHQVRZlUHGDV(QWVFKHLGHQGHXQG,QWHUHVVDQWHGLH
'HILQLWLRQGHU6FKQLWWVWHOOHQ]ZLVFKHQGHQEHLGHQ
6XEV\VWHPHQ
,PZHLWHUHQPVVWHDXFKGLH$UWGHU=XVDPPHQDUEHLWGXUFK
GLH6SH]LILNDWLRQGHU9HUDQWZRUWOLFKNHLWHQJHUHJHOWVHLQ
'DV0RGXOGHUORJLVFKHQ'DWHQVFKHPDWDZLUG]XGHP
LGHDOHUZHLVHSHUVLVWHQWJHKDOWHQZlKUHQGGLH0RGXOHGHU
$SSOLNDWLRQHQWUDQVLHQWLPSOHPHQWLHUWVHLQVROOHQ
3.3.2.3 Plazierung der Methoden
:HQQGLH9HUDQWZRUWOLFKNHLWHQGHU6XEV\VWHPH0RGXOH
JHUHJHOWVHLQVROOPXVVHLQ9RUJHKHQVVFKHPDGHILQLHUW
ZHUGHQN|QQHQZHOFKHVXQWHUIROJHQGHQ*HVLFKWVSXQNWHQ
RSWLPLHUWLVW
• 'HU*UXQGVDW]GHU'DWHQNDSVHOXQJVROOQLFKWDXIJHZHLFKW
ZHUGHQGK'DWHQVROOWHQQXUGXUFKZRKOGHILQLHUWH
|IIHQWOLFKH0HWKRGHQ]XJlQJOLFKVHLQ
• 'DV9HUKDOWHQHLQHU.ODVVHVROODXIGHUULFKWLJHQ(EHQH
PRGHOOLHUWVHLQGKGLH$QIRUGHUXQJGHU
:LHGHUYHUZHQGEDUNHLWYRQ.RPSRQHQWHQVROOWHQLFKWGXUFK
]XKRKH6SH]LDOLVLHUXQJYRQ.ODVVHQHLQJHVFKUlQNWVHLQ
• 7UDQVDNWLRQHQVROOHQYRQGHU9HUZHQGHUNODVVH
LPSOHPHQWLHUWZHUGHQLQVEHVRQGHUHVROOHQNHLQH0HWKRGHQ
YRQ.ODVVHQLQQHUKDOEGHVORJLVFKHQ6FKHPDV7UDQVDNWLRQHQ
EHLQKDOWHQ
3.3.2.4 Beispiel „Bibliothek“
6HLGDV0RGXOGHVORJLVFKHQ6FKHPDVPLWGHQ.ODVVHQ
Å%LEOLRWKHN´Å6WXGHQW´XQGÅ%XFK´XQGGLH$SSOLNDWLRQPLW
GHU.ODVVHÅ%LEOLRWKHNV0DQDJHU´ZHOFKHHLQH
%HQXW]HUVFKQLWWVWHOOH]XU9HUIJXQJVWHOOWDXVJHVWDWWHW
:LHZHUGHQQHXH%FKHULQGLH%LEOLRWKHNDXIJHQRPPHQ"
:LUGGLHVYRQGHU$SSOLNDWLRQRGHUYRQGHU%LEOLRWKHNV
.ODVVHHUOHGLJW"
6RZRKODOVDXFK'LH$SSOLNDWLRQPXVVGHP%HQXW]HUHLQH0HWKRGH
]XU9HUIJXQJVWHOOHQXQGUXIWLQGHVVHQ,PSOHPHQWLHUXQJGLH
HQWVSUHFKHQGH0HWKRGHGHU%LEOLRWKHNVNODVVHDXI'DUDXVIROJWGDVV
HLQH)XQNWLRQVLHKHLVVH$GG6WXGHQWLQGLH6FKQLWWVWHOOH
DXIJHQRPPHQZHUGHQPXVV
:LHZLUGHLQH/LVWHDOOHUDXVJHOLHKHQHU%FKHUDXIEHUHLWHW"
:LHZLUGGLHVHYLVXDOLVLHUW"
'LH$XIEHUHLWXQJGHU/LVWHLVWYRQHLQHU6LFKWHQ.ODVVHLQQHUKDOEGHV
$SSOLNDWLRQVPRGXOV]XHUOHGLJHQ'HU=XJULIIVNDQDO]XU%HVFKDIIXQJ
GHU'DWHQPXVVLQGHU6FKQLWWVWHOOHGHILQLHUWVHLQ'LH9LVXDOLVLHUXQJ
Diplomarbeit
Schwachstellenanalyse • 47
PXVVHEHQIDOOVYRQGHU$SSOLNDWLRQJHUHJHOWZHUGHQDQVRQVWHQZlUHGLH
:LHGHUYHUZHQGEDUNHLWEHUHLWVQXUQRFKIUJOHLFKDUWLJH*8,VJHVLFKHUW
:LHZLUGGLH7UDQV$NWLRQGHV%XFKDXVOHLKHQV
LPSOHPHQWLHUW"
'HU$XIE]Z$EEDXGHU5HIHUHQ]HQGHU2EMHNWHLQQHUKDOEGHU
SHUVLVWHQWHQ'DWHQPXVVYRQGHQ0HWKRGHQGHU'DWHQEDQNNODVVHQ
HLJHQVWlQGLJJHUHJHOWZHUGHQN|QQHQ-HGRFKPXVVGHP%HQXW]HUHLQ
,QWHUIDFH]XU9HUIJXQJVWHKHQLQZHOFKHPHUGHQ6WXGHQWHQXQGGDV
%XFKDXVZlKOHQXQGGDQQGLH7UDQVDNWLRQPLWGLHVHQEHLGHQ
5HIHUHQ]HQJHJHQEHUGHU'DWHQEDQNDEVHW]HQNDQQ
3.3.2.5 Schwachstelle
,QGHU(QWZXUIVQRWDWLRQIHKOHQGLH.RQVWUXNWHZHOFKHHV
HUODXEHQ]ZLVFKHQWUDQVLHQWHQXQGSHUVLVWHQ]IlKLJHQ.ODVVHQ
]XXQWHUVFKHLGHQ=XGHPLVWGDV=XVDPPHQVSLHOGHU
$SSOLNDWLRQVNODVVHQPLWGHQ.ODVVHQGHV6FKHPDVGXUFKGLH
PDQJHOKDIWH)lKLJNHLWGHU6FKQLWWVWHOOHQVSH]LILNDWLRQQLFKW
JHUHJHOW'LH(QWZXUIVVSUDFKHPXVVDEHUGHUDUWLJH
0|JOLFKNHLWHQELHWHQGDEHLGHUEHWUDFKWHWHQ
'DWHQEDQNXPJHEXQJGLH$SSOLNDWLRQHQ7HLOGHV6FKHPDV
VLQGXQGGHVKDOELQGHQ(QWZXUIPLWHLQEH]RJHQZHUGHQ
PVVHQ
3.3.3 Transaktionen
'HU(QWZXUIKDWGLH$EELOGXQJGHU6DFKYHUKDOWHGHV
3UREOHPEHUHLFKHVDXIHLQVHPDQWLVFKlTXLYDOHQWHV'DWHQVFKHPDDOV
]HQWUDOHV=LHO*HQDXVRZLFKWLJDEHULVWGLH*HZlKUOHLVWXQJGHU
'DWHQLQWHJULWlWZlKUHQGGHU0DQLSXODWLRQGHUEHWHLOLJWHQ2EMHNWH
3.3.3.1 Datenintegrität
'LH'DWHQLQWHJULWlWPXVVXQWHU]ZHLYHUVFKLHGHQHQ
*HVLFKWVSXQNWHQEHOHXFKWHWZHUGHQGHURSHUDWLRQDOHQXQG
GHUVHPDQWLVFKHQ
'LHRSHUDWLRQDOH'DWHQLQWHJULWlWEH]LHKWVLFKDXIGLHSK\VLVFKH.RQVLVWHQ]
GHU'DWHQ6LHN|QQWHEHLVSLHOVZHLVHGXUFKGHQ0HKUEHQXW]HUEHWULHE
YHUOHW]WZHUGHQ'LHVLVWDEHULQ'DWHQEDQNV\VWHPHQZHOFKHHLQ
7UDQVDNWLRQVNRQ]HSWLPSOHPHQWLHUWKDEHQQLFKWP|JOLFK6LHEHLQKDOWHQ
EHUHLWV0HFKDQLVPHQIUGLH.RQWUROOHNRQNXUUHQ]LHUHQGHU=XJULIIH
&RQFXUUHQF\&RQWUROXQG:LHGHUDQODXILP)HKOHUIDOO5HFRYHU\
,QVEHVRQGHUHNDQQDOVRGLHRSHUDWLRQDOH'DWHQLQWHJULWlWQLFKWGXUFKGHQ
(QWZXUIGLH8PVHW]XQJRGHUGXUFKGHQ%HWULHEJHIlKUGHWZHUGHQ
SK\VLVFKH.RQVLVWHQ]
&RQFXUUHQF\&RQWURO
5HFRYHU\
$QGHUVYHUKlOWHVVLFKEHLGHUVHPDQWLVFKHQ'DWHQLQWHJULWlWZHOFKHYHUOHW]W
ZHUGHQNDQQ'DV'DWHQEDQNV\VWHPELHWHW]ZDU7UDQVDNWLRQHQZHOFKHDOV
(LQKHLWGHU.RQVLVWHQ]DQGHUHQ%HJLQQXQG(QGHGLH'DWHQLQWHJULWlWJLOW
]XEHWUDFKWHQVLQGLPNRQ]HSWXHOOHQ(QWZXUIPVVHQDEHUGHQQRFK
6DFKYHUKDOWHGHUPRGHOOLHUWHQ6\VWHPZHOWDXI7UDQVDNWLRQHQDEJHELOGHW
ZHUGHQ$XVGLHVHP*UXQGPVVHQGHP(QWZHUIHUHQWVSUHFKHQGH
.RQVWUXNWHXQG9RUJHKHQVULFKWOLQLHQ]XU9HUIJXQJVWHKHQ
3.3.3.2 Objektmanipulationen
7UDQVDNWLRQDOV(LQKHLW
GHU.RQVLVWHQ]
&UHDWH5HDG8SGDWH
'HOHWH
48 • Schwachstellenanalyse
(LQ2EMHNWXQWHUOLHJWVWHWVGHP=\NOXV&58'&UHDWH5HDG8SGDWH
'HOHWH'DUDXVODVVHQVLFKGLHYHUVFKLHGHQHQ0RGLILNDWLRQHQIHVWOHJHQ
(U]HXJXQJ&UHDWH
.DQQDOV6FKUHLE]XJULIIJHVHKHQZHUGHQGHUDEHU
Diplomarbeit
HUVFKZHUHQGHUZHLVHQRFKZHLWHUH6FKUHLE]XJULIIH
YHUXUVDFKHQNDQQPDQGHQNHDQGLH,QVWDQ]LHUXQJYRQ
$JJUHJDWLRQVNODVVHQ
/HVHQ5HDG
5HLQHU/HVH]XJULII'LH'DWHQEDQNXPJHEXQJPXVVIUGLH
$NWXDOLWlWGHU'DWHQLP0HKUEHQXW]HUEHWULHEVRUJHQ
bQGHUXQJGHU:HUWH8SGDWH
'LH$NWXDOLVLHUXQJLVWHLQ6FKUHLE]XJULII0DQEHDFKWHGDVV
LQGHQPHLVWHQ)lOOHQDXFKGLH(U]HXJXQJRGHUGLH/|VFKXQJ
DQGHUHU2EMHNWH]XHLQHU$NWXDOLVLHUXQJHLQHVEHWURIIHQHQ
2EMHNWHVIKUHQN|QQHQbQGHUXQJGHU5HIHUHQ]DWWULEXWH
/|VFKXQJ'HOHWH
.DQQDXFKDOV6FKUHLE]XJULIIJHVHKHQZHUGHQ(VPVVHQ
ZLHEHLP&UHDWH)RUWSIODQ]XQJVHIIHNWHEHUFNVLFKWLJW
ZHUGHQ
,Q0HKUEHQXW]HUV\VWHPHQZLHVLHLQ'%06YRUOLHJHQ
PVVHQGLH=XJULIIVUHFKWHJHUHJHOWVHLQ'LH'DWHQLQWHJULWlW
PXVVJHVFKW]WZHUGHQN|QQHQXQGGDUILQVEHVRQGHUHQLFKW
GXUFKGHQ0HKUEHQXW]HUEHWULHEJHIlKUGHWZHUGHQ'LHVHP
.RQ]HSWPXVVEHUHLWVLQGHU(QWZXUIVSKDVH%HDFKWXQJ
JHVFKHQNWZHUGHQN|QQHQ
3.3.3.3 Schutzmechanismen
|IIHQWOLFKHJHVFKW]WH
XQGSULYDWH$WWULEXWH
XQG0HWKRGHQ
%HQXW]HUSURILO
'DQNGHV*UXQGVDW]HVGHU'DWHQNDSVHOXQJLVWLQGHQEHNDQQWHQ
REMHNWRULHQWLHUWHQ6SUDFKHQXQGGHUHQWVSUHFKHQGHQ(QWZXUIPHWKRGHQ
EHUHLWVHLQ6FKXW]PHFKDQLVPXVLPSOHPHQWLHUW'HU=XJULIINDQQGXUFKGLH
7\SLVLHUXQJGHU$WWULEXWHXQG0HWKRGHQLQ|IIHQWOLFKHJHVFKW]WHXQG
SULYDWHJHUHJHOWZHUGHQ
'LHVHV.RQ]HSWLVWDEHUQXUEHJUHQ]WIU'DWHQEDQNDQZHQGXQJHQ
JHQJHQGGDLPNRQ]HSWXHOOHQ(QWZXUIGLH0|JOLFKNHLWEHVWHKHQVROOWHGLH
=XJULIIVUHFKWHLQ$EKlQJLJNHLWGHV3URILOVGHVDNWXHOODQJHPHOGHWHQ
%HQXW]HUV]X]XWHLOHQ
3.3.3.4 Schwachstelle
7UDQVDNWLRQHQELOGHQLQQHUKDOEYRQ'DWHQEDQNV\VWHPHQGLH
(LQKHLWGHU.RQVLVWHQ]'LHEHWUDFKWHWH(QWZXUIVPHWKRGH
YHUIJWDEHUZHGHUEHUHQWVSUHFKHQGH.RQVWUXNWH]XU
'HILQLWLRQYRQ7UDQVDNWLRQVDXIUXIHQQRFKEHU
9RUJHKHQVULFKWOLQLHQIUGLH)RUPXOLHUXQJYRQ
.RQVLVWHQ]EHGLQJXQJHQ]XU6LFKHUXQJGHUVHPDQWLVFKHQ
'DWHQLQWHJULWlW=XGHPVROOWHIUGHQNRQ]HSWXHOOHQ(QWZXUI
GLH=XJULIIVW\SHQVFKUHLEHQGOHVHQGIUGLH|IIHQWOLFKHQ
0HWKRGHQPLWEHUFNVLFKWLJWZHUGHQN|QQHQ
3.3.4 Weitere Schwachstellen
3.3.4.1 Physische Aspekte
)UGHQSK\VLVFKHQ'DWHQEDQNHQWZXUIVROOWHQGLH$VSHNWH
GHVClusteringGHUIndexierungGHUDistributionXQGGHU
FragmentierungEHUFNVLFKWLJWZHUGHQN|QQHQ'LH
EHWUDFKWHWH(QWZXUIVVSUDFKHELHWHW]ZDUIUGHQSK\VLVFKHQ
(QWZXUIGLH0RGXOXQGGLH3UR]HVVGLDJUDPPHDQGLHDEHU
GHQIUGLH'DWHQEDQNHQHUK|KWHQ$QIRUGHUXQJHQQLFKW
JHUHFKWZHUGHQN|QQHQ
Diplomarbeit
Schwachstellenanalyse • 49
3.3.4.2 Vererbungshierarchien
,Q2PVVHQDOOH.ODVVHQYRQObjectDEJHOHLWHWVHLQ
=XGHPN|QQHQIUGLH,PSOHPHQWDWLRQGHUJHZ|KQOLFKHQ
(LJHQVFKDIWHQHLQHU.ODVVHZHLWHUHDEVWUDNWH.ODVVHQ]%
DBObjectHLQJHIKUWZHUGHQ'LHVHLPSOL]LWHQ
9HUHUEXQJVEH]LHKXQJHQVROOWHQDEHUGLH/HVEDUNHLWGHV
(QWZXUIVGLDJUDPPVQLFKWEHODVWHQ
3.4 Vermisste Konstrukte
3.4.1 Inverse Beziehungen
,QGHU0HWKRGHYRQ%RRFKLVWNHLQH[SOL]LWHV.RQVWUXNWIUGHQ
(QWZXUIYRQLQYHUVHQ%H]LHKXQJHQYRUJHVHKHQ=ZDUHUODXEWHUGDVV
EHLGHU9HUZHQGXQJHLQHUEHOLHELJHQ%H]LHKXQJDQEHLGHQ(QGHQGHU
9HUELQGXQJ.DUGLQDOLWlWHQDQJHJHEHQZHUGHQ-HGRFKXQWHUOLHJHQ
GLHVHNHLQHUH[SOL]LWGHILQLHUWHQ6HPDQWLN
'LHVHU0LVVVWDQGVHLDP%HLVSLHOHLQHVVHKUHLQIDFKHQ
,QIRUPDWLRQVV\VWHPVIUHLQH6WXGHQWHQELEOLRWKHNYHUDQVFKDXOLFKW
3.4.1.1 Beispiel „Bibliothek“
)UGDV,QIRUPDWLRQVV\VWHPH[LVWLHUHQIROJHQGH9RUJDEHQ
• 6WXGHQWHQVLQG0LWJOLHGHULQHLQHU%LEOLRWKHN
• %FKHUJHK|UHQGHU%LEOLRWKHN
• (LQ6WXGHQWNDQQ1%FKHUDXVOHLKHQ
• (LQ%XFKNDQQHQWZHGHUYRQJHQDXHLQHP6WXGHQWHQRGHU
JDUQLFKWDXVJHOLHKHQVHLQ
)UGLH0RGHOOLHUXQJGLHVHV6\VWHPVVHLHQGUHL.ODVVHQ
Å%LEOLRWKHN´Å6WXGHQW´XQGÅ%XFK´YRUJHVFKODJHQ
=ZLVFKHQMH]ZHLYRQGLHVHQ.ODVVHQPXVVHLQH%H]LHKXQJ
HLQJHULFKWHWZHUGHQZREHLGLHMHQLJH]ZLVFKHQGHP6WXGHQWHQ
XQGGHP%XFKLQYHUVVHLQVROO'LHVEULQJWGHQ9RUWHLOGDVV
DXIGLUHNWH:HLVHGKQLFKWEHUDQGHUH
.ODVVHQH[WHQVLRQHQVRZRKOGHU1DPHGHV6WXGHQWHQGHU
HLQEHVWLPPWHV%XFKDXVJHOLHKHQKDWDOVDXFKGLH/LVWHDOOHU
%FKHUGLHYRQHLQHPEHVWLPPWHQ6WXGHQWHQDXVJHOLHKHQ
ZRUGHQVLQGDXVJHGUXFNWZHUGHQNDQQ
3.4.1.2 Beziehung „by reference“
0RGHOOLHUWPDQGLHVH%H]LHKXQJLQQHUKDOEGHU%RRFK·VFKHQ
0HWKRGHDOVÅKDVDE\UHIHUHQFH´9HUELQGXQJGLHDXIGHU
6HLWHGHV6WXGHQWHQGLH.DUGLQDOLWlWVDQJDEHWUlJWXQGDXI
GHU6HLWHGHV%XFKHVHLQHYRP7\SÅ´HUJHEHQVLFKHLQLJH
8QVWLPPLJNHLWHQ
'HP(QWZLFNOHU|IIQHQVLFKQXQEHLP,QWHUSUHWLHUHQGHV
.ODVVHQGLDJUDPPV(UPHVVHQVVSLHOUlXPHZDVVLFKHUOLFKQLFKW
LP,QWHUHVVHGHV(QWZHUIHUVLVW9HUGHXWOLFKWVHLGLHVDQGHQ
IROJHQGHQ6LWXDWLRQHQGLHGDV.ODVVHQGLDJUDPPQLFKW
YHUOHW]HQDEHUVHPDQWLVFKZRKOQLFKWEHDEVLFKWLJWZDUHQ
• 6WXGHQW$OHLKW%XFK%XFKZLUGDXVJHOLHKHQYRQ
6WXGHQW%*HVDPW]DKOGHU%H]LHKXQJHQNRUUHNWDEHUQLFKW
LQYHUV
• 6WXGHQW$OHLKW%XFK%XFKZLUGYRQQLHPDQGHP
DXVJHOLHKHQ%H]LHKXQJXQYROOVWlQGLJ
50 • Schwachstellenanalyse
Diplomarbeit
• 6WXGHQW$OHLKW%XFK%XFKZLUGDXVJHOLHKHQYRQ
6WXGHQWXQG6WXGHQW%OHLKW%XFK%XFKZLUG
DXVJHOLHKHQYRQ6WXGHQW$*HVDPW]DKOGHU%H]LHKXQJHQ
NRUUHNW%H]LHKXQJHQYROOVWlQGLJDEHUQLFKWLQYHUV
'LH%H]LHKXQJLVWDOVRDXIGLHVH:HLVHORVHYHUEXQGHQGK
GHU(QWZHUIHUPXVVGXUFKGLH$QJDEHYRQLQIRUPHOOHQ
1RWL]HQJHQDXHUVSH]LIL]LHUHQZLHGLHJH]HLFKQHWH%H]LHKXQJ
]XLQWHUSUHWLHUHQLVW$XIGHUDQGHUHQ6HLWHPXVVGHU
3URJUDPPLHUHULQ6LWXDWLRQHQLQGHQHQHLQHLQYHUVH
%H]LHKXQJJHIRUGHUWLVWVHOEHUGDIUVRUJHQGDVVGLH
,QYHUVLWlWQLFKWYHUOHW]WZLUG
'LHPXVVHUGDGXUFKHUUHLFKHQGDVVHUEHUSUIWRE
IROJHQGH.ULWHULHQ]XHUIOOHQVLQG
.DUGLQDOLWlWHQHUIOOW
*HVDPW]DKOGHU%H]LHKXQJHQNRUUHNW
%H]LHKXQJHQYROOVWlQGLJXQG
%H]LHKXQJHQLQYHUV
=XGHPLVWGHU$XIXQG$EEDXGHU%H]LHKXQJQLFKWJHUHJHOW
6\QWDNWLVFKN|QQHQEHLGH7HLOQHKPHUJOHLFKEHUHFKWLJW
%H]LHKXQJHQDXIXQGDEEDXHQZDVVHPDQWLVFKLQJHZLVVHQ
6LWXDWLRQHQGDV%XFKZLUGYRQHLQHP6WXGHQWHQDXVJHOLHKHQ
]XZHLOHQIUDJZUGLJLVW
$QJHQRPPHQGLH$XVOHLKH%H]LHKXQJVROOYRQGHU.ODVVH
Å6WXGHQW´DXVDXIJHEDXWZHUGHQPXVVLQQHUKDOEGLHVHU
0HWKRGHGDVHQWVSUHFKHQGHLQYHUVH*HJHQVWFNGD]X
JOHLFKIDOOVJHVHW]WZHUGHQ6RPLWPXVVGLH.ODVVHÅ%XFK´
HQWZHGHUHLQHQ|IIHQWOLFKHQ=HLJHUDXIGLH.ODVVHÅ6WXGHQW´
RGHUHLQH|IIHQWOLFKH%H]LHKXQJVDXIEDX0HWKRGH]XU
9HUIJXQJVWHOOHQ,QMHGHP)DOODEHUVWHKWGLHVLP
:LGHUVSUXFK]XGHU)RUGHUXQJGDVVGLH%H]LHKXQJQXU
HLQVHLWLJDXIJHEDXWZHUGHQGDUI
'XUFKGLH'HNODUDWLRQHLQHUÅIULHQG´.ODVVHN|QQWHGLHVH
.OLSSHHLQLJHUPDVVHQHOHJDQWXPVFKLIIWZHUGHQ'LHVHV
.RQVWUXNWVWHKWDEHULQGHQEHWUDFKWHWHQREMHNWRULHQWLHUWHQ
'DWHQEDQNV\VWHPHQQLFKW]XU9HUIJXQJZDVGLH)RUGHUXQJ
GHU2EMHNWRULHQWLHUXQJQDFKPD[LPDOHU.DSVHOXQJ
HQWVFKLHGHQDXIZHLFKW
6ROOGLH%H]LHKXQJYRQEHLGHQ6HLWHQKHUDXIJHEDXWZHUGHQ
N|QQHQPXVVHLQHDQHLQHUGHUDUWLJHQ9HUELQGXQJ
WHLOQHKPHQGH.ODVVH]ZHLXQWHUVFKLHGOLFKH0HWKRGHQHLQH
IUGHQDNWLYHQXQGHLQHIUGHQSDVVLYHQ$XIEDXDQELHWHQ
'DEHLVROOWHQDEHUJOHLFKVDPGLHSDVVLYHQ$XIEDXIXQNWLRQHQ
YRUXQHUODXEWHQ=XJULIIHQJHVFKW]WZHUGHQN|QQHQZDV
PDQJHOV0lFKWLJNHLWGHU'DWHQGHILQLWLRQVVSUDFKHZLHREHQ
HUOlXWHUWQLFKWUHDOLVLHUEDULVW
3.4.1.3 Beziehungen „by value“
0RGHOOLHUWPDQGLH$XVOHLK%H]LHKXQJLQQHUKDOEGHU
%RRFK·VFKHQ0HWKRGHDOVÅKDVDE\YDOXH´9HUELQGXQJXQG
VHW]WPDQDXIGHU6HLWHGHV%HVLW]HUVHLQH.DUGLQDOLWlWVDQJDEH
GLHZHGHUÅ´QRFKÅ&´LVWZDVYRQGHU.RQVWUXNWV\QWD[KHU
HUODXEWLVWYHUOLHUWGDV.RQVWUXNWGDPLWVHPDQWLVFKMHJOLFKHQ
Diplomarbeit
Schwachstellenanalyse • 51
6LQQ(LQH.RPSRQHQWHNDQQQLFKWLQPHKUHUHQ$JJUHJDWHQ
HQWKDOWHQVHLQ=XGHPPXVVDXVQDKHOLHJHQGHQ*UQGHQGLH
UFNEH]JOLFKH%H]LHKXQJYRP7\SÅE\UHIHUHQFH´VHLQ
'XUFK%H]LHKXQJHQÅE\YDOXH´ZHUGHQ
([LVWHQ]DEKlQJLJNHLWHQEHVFKULHEHQ'LHVEHGHXWHWIUGHQ
%H]LHKXQJVDXIEDXGDVVLQQHUKDOEGLHVHU0HWKRGHGDV2EMHNW
]XGHPHLQHGHUDUWLJH%H]LHKXQJDXIJHQRPPHQZHUGHQVROO
HUVWQRFKNUHLHUWZHUGHQPXVV'LH)XQNWLRQPXVVGHPQDFK
DOV3DUDPHWHUVlPWOLFKHIUGLH.RQVWUXNWLRQHLQHV2EMHNWHV
QRWZHQGLJH,QIRUPDWLRQLQGHU6FKQLWWVWHOOHPLW
EHUFNVLFKWLJHQ
:HUGHQIUHLQH$JJUHJDWLRQVNODVVHJDU]ZLQJHQGH
.RPSRQHQWHQJHIRUGHUWHLQ$XWRPXVVHLQHQ0RWRUKDEHQ
HQWVWHKHQVRZRKOIUGLH.RQVWUXNWRUHQDOVDXFKIUGLH
9HUELQGXQJVDXIEDXIXQNWLRQHQNRPSOL]LHUWH
)RUWSIODQ]XQJVHIIHNWH'LHVHVLQG]ZDUGXUFKGLH
)RUPXOLHUXQJYRQLQKlUHQWHQ.RQVLVWHQ]EHGLQJXQJHQNHLQH
=\NOHQLQGHUDUWLJHQ9HUELQGXQJVJUDSKHQUHDOLVLHUEDU
YHUODQJHQDEHUGHPQLFKWGXUFKHLQHVHUL|VH0HWKRGLN
XQWHUVWW]WHQ(QWZLFNOHUHLQLJHVDQ$UEHLWDE
%HLQKDOWHWGHU(QWZXUIGD]XQRFK]ZLQJHQGH%H]LHKXQJHQ
YRP7\SÅE\UHIHUHQFH´OlVVWVLFKGLH.RQVLVWHQ]PHLVWQXU
QRFKGXUFKJHVFKLFNWH=XVDPPHQIDVVXQJYRQPHKUHUHQ
$NWLRQHQLQGHUVHOEHQ7UDQVDNWLRQVLFKHUQ
3.4.1.4 Schwachstelle
,P6WDQGDUGGHU2'0*ZHUGHQLQYHUVH%H]LHKXQJHQ
JHIRUGHUW,QGHUEHWUDFKWHWHQ,PSOHPHQWDWLRQIHKOWGLH
)lKLJNHLW]XU)RUPXOLHUXQJGHUDUWLJHU%H]LHKXQJHQ'DUEHU
KLQDXVVLQGLQGHU0HWKRGHYRQ%RRFKLQYHUVH%H]LHKXQJHQ
QLFKWVSH]LIL]LHUEDU5FNEH]JOLFKH%H]LHKXQJHQVLQGDEHU
IUEHLVSLHOVZHLVHGLH/|VFKIRUWSODQ]XQJYRQHPLQHQWHU
:LFKWLJNHLW/|VFKXQJYRQUHIHUHQ]LHUWHQ2EMHNWHQ
3.4.2 Extensionen und Schlüssel
(LQ2EMHNWZLUGLQHLQHP2'%06EHUVHLQH2EMHNWLGHQWLWlW2,'
HLQGHXWLJYRQDQGHUHQ2EMHNWHQXQWHUVFKHLGEDUJHPDFKW,Q
=XVDPPHQKDQJPLW'DWHQEDQNDQZHQGXQJHQZlUHDEHUHLQHDQGHUH$UWGHU
,GHQWLILNDWLRQZQVFKHQVZHUWQlPOLFKEHUHLQHQ:HUWH6FKOVVHO
,QVEHVRQGHUH]XP$XIILQGHQYRQJHZLVVHQ,QVWDQ]HQLQ2EMHNWPHQJHQ
VROOWHEDVLHUHQGDXIHLQHU:HUWHPHQJHDEJHIUDJWZHUGHQN|QQHQ
=XGHPLVWLQGHU2'/ZLHVLHYRQGHU2'0*YRUJHVFKODJHQ
ZXUGHGHU6FKOVVHO%HVWDQGWHLOGHU2EMHNWVFKQLWWVWHOOHQGHILQLWLRQ
$XVGHU'HILQLWLRQGHU6FKOVVHOEH]LHKXQJHQODVVHQVLFK
.RQVLVWHQ]EHGLQJXQJHQDEOHLWHQ'LHDXWRPDWLVFKHhEHUSUIXQJ
GLHVHU]XVlW]OLFKHQ6LFKHUKHLWHQZlUHZQVFKHQVZHUW
2EMHNWLGHQWLWlWYHUVXV
:HUWH6FKOVVHO
)UHPGVFKOVVHO
EH]LHKXQJHQ
52 • Schwachstellenanalyse
'LH)UHPGVFKOVVHOEH]LHKXQJHQZLHVLHDXVGHP8PJDQJPLWUHODWLRQDOHQ
6\VWHPHQEHNDQQWVLQGZHUGHQLQ22'%06EHNDQQWOLFKEHU
%H]LHKXQJHQ]ZLVFKHQ2EMHNWHQPRGHOOLHUW(LQHhEHUSUIXQJGHU
.DUGLQDOLWlWHQVRZLHGLH9DOLGLHUXQJHLQHU%H]LHKXQJLVWHOHPHQWDUH
9RUDXVVHW]XQJIUGHQ6FKXW]GHU'DWHQLQWHJULWlW
3.4.2.1 Schwachstelle
Diplomarbeit
,QNRQNUHWHQ2'%06,PSOHPHQWLHUXQJHQZLH]%2LVW
DEHUGLH6FKOVVHOGHILQLWLRQNHLQ%HVWDQGWHLOGHU2&2'/
$XFKLQGHUEHWUDFKWHWHQ(QWZXUIVVSUDFKHLVWGLHVHV
.RQVWUXNWQLFKWYRUJHVHKHQ=XGHPIHKOHQGLH.RQ]HSWH
XQG.RQVWUXNWHIUGLH%HVFKUHLEXQJYRQ([WHQVLRQHQ
ZHOFKHIUGDV$XIILQGHQYRQEHVWLPPWHQ,QVWDQ]HQIUGLH
hEHUSUIXQJYRQ(LQGHXWLJNHLWVNULWHULHQXQGGDV
)RUPXOLHUHQYRQVXPPDULVFKHQ$EIUDJHQYRQ]HQWUDOHU
%HGHXWXQJVLQG
3.4.3 Fortpflanzung und Konsistenzsicherung
(LQH]HQWUDOH$XIJDEHHLQHV'DWHQEDQNV\VWHPVLVWGHU6FKXW]GHU
RSHUDWLRQDOHQ'DWHQLQWHJULWlW'DUEHUKLQDXVVROOGDV'%6DXFK
.RQVWUXNWHXQG0HFKDQLVPHQ]XU9HUIJXQJVWHOOHQPLW+LOIHGHUHU
GLHVHPDQWLVFKH.RQVLVWHQ]GHU'DWHQGHILQLHUWXQGEHUZDFKW
ZHUGHQN|QQHQ$OV.RQVHTXHQ]PVVHQLPORJLVFKHQ(QWZXUI
JOHLFKVDP+LOIVPLWWHDQJHERWHQZHUGHQXPGLH6LFKHUXQJGHU
,QWHJULWlWXQG)RUWSIODQ]XQJVHIIHNWHPRGHOOLHUHQ]XN|QQHQ
1DFKIROJHQGVROOHQHLQLJHZHLWHUH(UOlXWHUXQJHQ]XGHU3URSDJDWLRQ
XQG.RQVLVWHQ]VLFKHUXQJDXVJHIKUWVHLQXPVFKOLHVVOLFKGLH
6FKZDFKVWHOOHGHVORJLVFKHQ(QWZXUIHVDXI]X]HLJHQ
3.4.3.1 Fortpflanzung
([NOXVLYLWlWXQG
([LVWHQ]DEKlQJLJNHLW
8QWHUHLQHP)RUWSIODQ]XQJVHIIHNWYHUVWHKWPDQGLH(LJHQVFKDIWHLQHU
'DWHQEDQNDXWRPDWLVFKGLH.RQVLVWHQ]IUH[LVWHQWLHOOH%H]LHKXQJHQ
DXIUHFKW]XHUKDOWHQ%HLVSLHOVZHLVHLVWGLHVHU(IIHNWEHLGHU/|VFKXQJYRQ
2EMHNWHQGLHDOV$JJUHJDWYRQXQWHUJHRUGQHWHQHQWKDOWHQHQ2EMHNWHQ
DXIWUHWHQHUZQVFKW'DEHLVLQGDEHUGLHYHUVFKLHGHQHQ$UWHQYRQ
$JJUHJDWLRQ([NOXVLYLWlWXQG([LVWHQ]DEKlQJLJNHLW]XXQWHUVFKHLGHQ
,QGHQIROJHQGHQ6LWXDWLRQHQLVWGLH)RUWSIODQ]XQJGHU
(U]HXJXQJE]Z/|VFKXQJVHPDQWLVFKVLQQYROO
H[NOXVLY
H[LVWHQ]DEKlQJLJ
(LQ$XWRHQWKlOWJHQDXHLQHQ0RWRUH[NOXVLYHH[LVWHQ]DEKlQJLJH
$JJUHDJWLRQ
• (U]HXJXQJGHV$JJUHJDWHV:HQQGDV$XWRHU]HXJWZLUG
VROODXFKVHLQ0RWRUHU]HXJWZHUGHQ
• (U]HXJXQJGHU.RPSRQHQWH:HQQHLQ0RWRUHU]HXJW
ZLUGPXVVDXFKHLQ$XWRHU]HXJWZHUGHQ
• /|VFKXQJGHV$JJUHJDWHV:HQQGDV$XWRJHO|VFKWZLUG
VROODXFKVHLQ0RWRUJHO|VFKWZHUGHQ
• /|VFKXQJGHU.RPSRQHQWH:HQQGHU0RWRUJHO|VFKW
ZLUGPXVVDXFKGDV$XWRJHO|VFKWZHUGHQ
QLFKWH[NOXVLY
H[LVWHQ]DEKlQJLJ
,QHLQHU$XWRZHUNVWDWWZHUGHQ)DKU]HXJW\SHQXQG0RWRUW\SHQJHZDUWHW
(LQHP$XWRLVWLPPHUJHQDXHLQ0RWRU]XJHRUGQHWQLFKWH[NOXVLYH
H[LVWHQ]DEKlQJLJH$JJUHJDWLRQ
• (U]HXJXQJGHV$JJUHJDWHV:LUGHLQQHXHU)DKU]HXJW\S
DXIJHQRPPHQPXVVLKPHQWZHGHUHLQEHVWHKHQGHU0RWRU
]XJHRUGQHWZHUGHQRGHUHVPXVVHLQQHXHU0RWRUW\SHU]HXJW
ZHUGHQ
• (U]HXJXQJGHU.RPSRQHQWH:LUGHLQQHXHU0RWRUW\S
HU]HXJWPXVVGLHVHUHLQHPEHVWHKHQGHQ$XWR]XJHRUGQHW
Diplomarbeit
Schwachstellenanalyse • 53
ZHUGHQ$XVWDXVFKGHV0RWRUVNDQQHYHLQH/|VFKXQJ
YHUXUVDFKHQRGHUHVPXVVHLQQHXHV$XWRHU]HXJWZHUGHQ
• /|VFKXQJGHV$JJUHJDWHV:LUGHLQ$XWRQLFKWPHKU
JHZDUWHWPXVVDXFKGLHHQWVSUHFKHQGH
$JJUHJDWLRQVEH]LHKXQJDEJHEDXWZHUGHQ:LUGGHU0RWRU
QXQYRQNHLQHPDQGHUHQ$XWRPHKUYHUZHQGHWZLUGHU
JOHLFKIDOOVJHO|VFKW
• /|VFKXQJGHU.RPSRQHQWH:LUGHLQ0RWRUJHO|VFKW
ZHUGHQVlPWOLFKHHLQPRWRULJHQ$XWRVZHOFKHGLHVHQ
0RWRUW\SHLQJHEDXWKDEHQJOHLFKIDOOVJHO|VFKW
,QGHQIROJHQGHQ6LWXDWLRQHQLVWYRQGHU)RUWSIODQ]XQJGHU
(U]HXJXQJE]Z/|VFKXQJDE]XVHKHQ
H[NOXVLYQLFKW
H[LVWHQ]DEKlQJLJ
-HGHU0LWDUEHLWHUKDWVHLQHQ$UEHLWVSODW]LQHLQHP(LQ]HOEURH[NOXVLYH
QLFKWH[LVWHQ]DEKlQJLJH$JJUHJDWLRQ
• (U]HXJXQJGHV$JJUHJDWHV:HQQHLQQHXHU0LWDUEHLWHU
DQJHVWHOOWZLUGVROOQLFKWHLQQHXHV%URJHEDXWZHUGHQ
9LHOPHKUZLUGGLHVHP0LWDUEHLWHUHLQOHHUHV%UR]XJHRUGQHW
• (U]HXJXQJGHU.RPSRQHQWH:HUGHQQHXH
%URUlXPOLFKNHLWHQKLQ]XJHPLHWHWPVVHQQLFKW]ZLQJHQG
QHXH0LWDUEHLWHUDQJHVWHOOWZHUGHQ
• /|VFKXQJGHV$JJUHJDWHV7ULWWHLQ0LWDUEHLWHUDXVGHU
)LUPDDXVKDWGLHVLP$OOJHPHLQHQNHLQHQ(LQIOXVVDXIGLH
0HQJHGHU%URV
• /|VFKXQJGHU.RPSRQHQWH$XVGHU$XIO|VXQJYRQ
0LHWYHUWUlJHQUHVXOWLHUHQVHOWHQ(QWODVVXQJHQ9LHOPHKU
ZHUGHQOHGLJOLFKGLHEHUIOVVLJHQOHHUHQ%URUlXPH
IUHLJHJHEHQ
QLFKWH[NOXVLYQLFKW
H[LVWHQ]DEKlQJLJ
-HGHU0LWDUEHLWHUDUEHLWHWLQHLQHPRGHUPHKUHUHQ7HDPVQLFKWH[NOXVLYH
QLFKWH[LVWHQ]DEKlQJLJH$JJUHJDWLRQ
• (U]HXJXQJGHV$JJUHJDWHV:LUGHLQHQHXHV7HDPLQV
/HEHQJHUXIHQPVVHQQLFKW]ZLQJHQGHUZHLVHQHXH
0LWDUEHLWHUHLQJHVWHOOWZHUGHQ9LHOPHKUZHUGHQ7HDPVDXV
EHVWHKHQGHQ0LWDUEHLWHUQJHELOGHW
• (U]HXJXQJGHU.RPSRQHQWH:LUGHLQQHXHU0LWDUEHLWHU
HLQJHVWHOOWZLUGGLHVHULQHLQRGHUPHKUHUHGHUEHVWHKHQGHQ
7HDPVLQWHJULHUW
• /|VFKXQJGHV$JJUHJDWHV%HL3URMHNWHQGHZLUGGDV
3URMHNWWHDPDXIJHO|VW'LH0LWDUEHLWHUZHUGHQDEHUQLFKW
HQWODVVHQVRQGHUQLQQHXH7HDPVHLQJHWHLOW
• /|VFKXQJGHU.RPSRQHQWH7ULWWHLQ0LWDUEHLWHUDXVGHU
)LUPDDXVZLUGGDV7HDPQLFKWDXIJHO|VWVHOEVWGDQQQLFKW
ZHQQHVQXQNHLQH0LWJOLHGHUPHKU]lKOW'LH([LVWHQ]HLQHV
7HDPVLVWHKHUDQHLQH$XIJDEHJHEXQGHQGDVKHLVVWHV
ZHUGHQLKPQHXH0LWDUEHLWHU]XJHWHLOW
$XVGLHVHQNRQVWUXLHUWHQ6LWXDWLRQHQNDQQGLH7HQGHQ]
DEJHOHVHQZHUGHQGDVVGRUWZRGLH)RUWSIODQ]XQJHUZQVFKW
LVWPLWH[LVWHQ]DEKlQJLJHQ$JJUHJDWLRQVEH]LHKXQJHQ
JHDUEHLWHWZHUGHQVROOZlKUHQGLQGHQDQGHUHQ)lOOHQGLH
54 • Schwachstellenanalyse
Diplomarbeit
0RGHOOLHUXQJGHU%H]LHKXQJGXUFK5HIHUHQ]HQYRU]X]LHKHQ
LVW
'DGLHDNWXHOOHQ,PSOHPHQWDWLRQHQYRQREMHNWRULHQWLHUWHQ
'DWHQEDQNV\VWHPHQNHLQ6SUDFKNRQVWUXNWIUGLH'HILQLWLRQ
YRQ$JJUHJDWHQPLW([LVWHQ]DEKlQJLJNHLWYRUVHKHQPXVV
GLHVGXUFKDQGHUH6WUDWHJLHQQDFKJHELOGHWZHUGHQ
'LH(U]HXJXQJE]Z/|VFKXQJHLQHU,QVWDQ]NDQQVLFKLQ]ZHL
Å5LFKWXQJHQ´IRUWSIODQ]HQ
• 9RP$JJUHJDW]XGHQ.RPSRQHQWHQ(LQ$XWRVROO
JHO|VFKWZHUGHQ'LHVLPSOL]LHUWGLH/|VFKXQJGHV0RWRUV
GHU=\OLQGHUGHV0RWRUVGHV*HWULHEHVGHU6LW]HXVZ
• 9RQHLQHU.RPSRQHQWH]XHLQHP$JJUHJDW(LQ0RWRU
VROOJHO|VFKWZHUGHQ'LHVLPSOL]LHUW]XPHLQHQGLH/|VFKXQJ
GHU=\OLQGHUDEHU]XPDQGHUHQDXFKIDOOVGLH%HGLQJXQJ
IRUPXOLHUWZXUGHGDVVHLQ$XWR]ZLQJHQGHUZHLVHHLQHQ
0RWRUKDEHQPXVVGLH/|VFKXQJGHV$XWRVXQG
GHPHQWVSUHFKHQGGHV*HWULHEHVGHU6LW]HXVZ
$XIGHUORJLVFKHQ(EHQHNDQQQXQGLH$IIHNWLHUXQJGHU
$JJUHJDWHGXUFKGLH/|VFKXQJLKUHU.RPSRQHQWHQDXI]ZHL
$UWHQXPJHVHW]WZHUGHQHQWZHGHUPDQYHUKLQGHUWLQVROFKHQ
)lOOHQGLH/|VFKXQJYRQH[LVWHQ]LHOOHQ.RPSRQHQWHQRGHU
PDQOHLWHWGHQ/|VFKEHIHKOGLUHNW]XP$JJUHJDWZHLWHU
(LQHQZHLWHUHQ$XVZHJDXVGLHVHU6LWXDWLRQZlUHGXUFKGLH
)RUPXOLHUXQJJHHLJQHWHU7UDQVDNWLRQHQ]XILQGHQ
3.4.3.2 Konsistenzsicherung
(LQJURVVHU3UREOHPEHUHLFKEHLGHU$UEHLWPLWODQJOHELJHQ
'DWHQLVWGLH6LFKHUXQJGHU.RQVLVWHQ]GHV'DWHQVFKHPDV
XQGGHUDNWXHOOH[LVWHQWHQ2EMHNWH(VVROOHQLQGHU)ROJHQXU
GLHSHUVLVWHQ]IlKLJHQ.ODVVHQEHWUDFKWHWZHUGHQGDQXU
GHUHQ,QVWDQ]HQGLH/HEHQV]HLWGHU$SSOLNDWLRQHQ
EHUGDXHUQ7UDQVLHQWH2EMHNWHQKLQJHJHQJHKRUFKHQHLQHU
PLQLPDQGHUHQ3KLORVRSKLHVLHN|QQHQQlPOLFKDXFK
DXVVHUKDOEYRQ7UDQVDNWLRQHQ]XP/HEHQHUZHFNWXQG
]HUVW|UWZHUGHQ
)RUWSIODQ]XQJVULFKWXQJ
,QLWLDO]XVWDQG
0DQLSXODWLRQHQ
Diplomarbeit
'LHVH3UREOHPDWLNOlVVWVLFKJUXQGVlW]OLFKLQ]ZHLYHUVFKLHGHQH
7HLOSUREOHPHXQWHUWHLOHQ=XPHLQHQPXVVEHLP(UVWHOOHQGHUDOOHUHUVWHQ
,QVWDQ]GLH.RQVLVWHQ]HUUHLFKWZHUGHQ,QLWLDO]XVWDQGXQG]XPDQGHUHQ
PXVVGLH.RQVLVWHQ]EHLDOOHQP|JOLFKHQ0DQLSXODWLRQHQHUKDOWHQEOHLEHQ
'LHP|JOLFKHQ0DQLSXODWLRQHQODVVHQVLFKLQGUHLYHUVFKLHGHQH$NWLRQHQ
XQWHUWHLOHQ
• 'LH:HUWHGHU2EMHNWDWWULEXWHZHUGHQYHUlQGHUW'LHV
SDVVLHUWQLFKWQXUEHLGHUUHLQHQZHUWHPlVVLJHQbQGHUXQJGHU
$WWULEXWHVRQGHUQDXFKEHLGHP$XIE]Z$EEDXYRQ
%H]LHKXQJHQ]ZLVFKHQ2EMHNWHQ
• 2EMHNWHN|QQHQNUHLHUWZHUGHQXQGGXUFK$QELQGXQJDQ
HLQEHUHLWVSHUVLVWHQWJHVSHLFKHUWHV2EMHNWLQGLH'DWHQEDVLV
JHODQJHQ
• 2EMHNWHN|QQHQGXUFKHLQHQ/|VFKYRUJDQJDXVGHU
'DWHQEDVLVHQWIHUQWZHUGHQ
Schwachstellenanalyse • 55
/HVH]XJULIIH
8UVSUXQJXQG
*OWLJNHLWVEHUHLFK
56 • Schwachstellenanalyse
'HU/HVH]XJULIILVWQLFKWDOV0DQLSXODWLRQDXI]XIDVVHQVHOEVWZHQQIUGLH
=ZLVFKHQVSHLFKHUXQJGHU5HVXOWDWHYRQEHLVSLHOVZHLVH$EIUDJHQ2EMHNWH
HU]HXJWZHUGHQ'HUDUWLJH2EMHNWHOHEHQQXUIUHLQHNXU]H=HLWXQGVROOHQ
LQVEHVRQGHUHQLFKWLQGLH'DWHQEDVLVJHODQJHQ
(VPXVVDOVRJHZlKUOHLVWHWVHLQGDVVVRZRKOYRUDOVDXFK
QDFKHLQHU7UDQVDNWLRQGLHDOVHLQHHLQ]HOQHRGHUHLQH
6HTXHQ]YRQPHKUHUHQ0DQLSXODWLRQHQDXIJHIDVVWZHUGHQ
VROOGLH.RQVLVWHQ]EHGLQJXQJHQHUIOOWVLQG
3.4.3.3 Konsistenzbedingungen
'LH.RQVLVWHQ]NULWHULHQZHUGHQGXUFKGLH)RUPXOLHUXQJYRQ
.RQVLVWHQ]EHGLQJXQJHQGHILQLHUW(U]ZXQJHQZLUGGLH.RQVLVWHQ]GXUFK
GLHhEHUSUIXQJGLHVHU.RQGLWLRQHQ'LH.RQVLVWHQ]VLFKHUXQJVSLHOWVLFK
GDKHUDXI]ZHL(EHQHQDE=XPHLQHQLVWGHU8UVSUXQJGHU%HGLQJXQJHQ]X
EHWUDFKWHQXQG]XPDQGHUHQGHUHQ*OWLJNHLWVEHUHLFK
%HGLQJXQJHQN|QQHQYHUVFKLHGHQHQ8UVSUXQJVVHLQ
,QKlUHQWH.RQVLVWHQ]EHGLQJXQJHQ
VLQG%HGLQJXQJHQGLHGXUFKGDV'DWHQPRGHOOEHVWLPPWVLQG
XQGGHVKDOESUREOHPXQDEKlQJLJVLQG$OV%HLVSLHON|QQWH
KHUDQJH]RJHQZHUGHQGDVV=\NOHQLQGHQ
9HUHUEXQJVEH]LHKXQJHQQLFKW]XJHODVVHQVLQG
,PSOL]LWH.RQVLVWHQ]EHGLQJXQJHQ
VLQG%HGLQJXQJHQZHOFKHLP6FKHPDVSH]LIL]LHUEDUVLQG
'D]XJHK|UHQEHLVSLHOVZHLVH.DUGLQDOLWlWVEHGLQJXQJHQRGHU
.RQGLWLRQHQZHOFKHGLH5HIHUHQ]VLFKHUKHLWJHZlKUOHLVWHQ
8QWHU5HIHUHQ]VLFKHUKHLWZLUGGLH6LFKHUKHLWYHUVWDQGHQGDVV
]XPHLQHQNHLQH2EMHNWHLQGHU'DWHQEDVLVJHVSHLFKHUW
ZHUGHQGLHYRQNHLQHPDQGHUHQSHUVLVWHQWHQ2EMHNW
UHIHUHQ]LHUWZHUGHQXQG]XPDQGHUHQNHLQH5HIHUHQ]HQDXI
2EMHNWHGLHEHUHLWVJHO|VFKWVLQGEULJEOHLEHQ
(LQH.DUGLQDOLWlWVEHGLQJXQJLVWGDQQHUIOOWZHQQGLH
PLQLPDOHPD[LPDOH$Q]DKOGHU%H]LHKXQJHQGLH
.DUGLQDOLWlWVDQJDEHQLFKWXQWHUVFKUHLWHWEHUVFKUHLWHW
([SOL]LWH.RQVLVWHQ]EHGLQJXQJHQ
VLQG%HGLQJXQJHQGLHGHU(QWZHUIHUGHV'DWHQEDQNVFKHPDV
H[SOL]LWIRUPXOLHUWKDWXPGLH,QWHJULWlWVHLQHU%DVLV
VHPDQWLVFK]XVLFKHUQ'LHVN|QQHQ%HGLQJXQJHQVHLQGLH
GLUHNWDOV.ODVVHQHLJHQVFKDIW&RQVWUDLQWIRUPXOLHUWZHUGHQ
XQGGHPHQWVSUHFKHQGDXFKIUMHGH,QVWDQ]JHOWHQPVVHQ
RGHUEHOLHELJH$XVGUFNHGLHPHKUHUH2EMHNWHPLWHLQDQGHU
YHUNQSIHQ
)UGHQ*OWLJNHLWVEHUHLFKYRQ.RQVLVWHQ]EHGLQJXQJHQVLQG
]ZHL7\SHQ]XXQWHUVFKHLGHQ
,QYDULDQWH.RQVLVWHQ]EHGLQJXQJHQ
PVVHQLPPHUHUIOOWVHLQXQGZHUGHQEHLVSLHOVZHLVHDP
$XVIKUXQJVHQGHYRQ|IIHQWOLFKHQ0HWKRGHQEHUSUIW
$OOJHPHLQH.RQVLVWHQ]EHGLQJXQJHQ
GUIHQZlKUHQGGHU$XVIKUXQJV]HLWHLQHU7UDQVDNWLRQ
YHUOHW]WVHLQXQGZHUGHQDP(QGHHLQHU7UDQVDNWLRQ
EHUSUIW
Diplomarbeit
.RQVLVWHQ]GHUÅOHHUHQ´
%DVLV
.RQVLVWHQ]EHL&UHDWH
8SGDWHXQG'HOHWH
%HLGHU.RQVLVWHQ]VLFKHUXQJIUGHQ,QLWLDO]XVWDQGPXVVDXIGHUHLQHQ6HLWH
JHVLFKHUWVHLQGDVVGLHÅOHHUH´%DVLVNRQVLVWHQWLVW'LHVLVWGDVlPWOLFKH
IRUPXOLHUEDUHQ%HGLQJXQJHQDQ,QVWDQ]HQJHEXQGHQVLQGWULYLDOHUZHLVH
LPPHUGHU)DOO$XIGHUDQGHUHQ6HLWHQDPHQWOLFKEHLPhEHUJDQJDXIGHQ
,QLWLDO]XVWDQGPVVHQVlPWOLFKH(LQVWLHJVSXQNWHGXUFKGLHHQWVSUHFKHQGHQ
.ODVVHQLQVWDQWLLHUXQJHQNUHLHUWZHUGHQ'LHVHU3UR]HVVOlVVWVLFKLQHLQH
7UDQVDNWLRQVFKDFKWHOQGLHGHU5HLKHQDFKGLHJOREDOHQ2EMHNWHLQVWDQWLLHUW
XQGGHPHQWVSUHFKHQGDXIGHQ]ZHLWHQGLVNXWLHUWHQ)DOOGHU
.RQVLVWHQ]VLFKHUXQJ]XUFNIKUHQ
'LH.RQVLVWHQ]NDQQDOVRQXUEHLGHU.UHDWLRQ&UHDWHGHU$NWXDOLVLHUXQJ
8SGDWHXQGGHU/|VFKXQJ'HOHWHJHIlKUGHWVHLQXQGPXVVGHPQDFKQXU
QDFKHLQHUGHUDUWLJHQ$NWLRQEHUSUIWZHUGHQ,QVEHVRQGHUHN|QQHQUHLQH
/HVH]XJULIIHGLH.RQVLVWHQ]QLFKWJHIlKUGHQ
3.4.3.4 Schwachstelle
'LH(QWZXUIVVSUDFKHYRQ%RRFKOlVVWGLH)RUPXOLHUXQJYRQ
VRJHQDQQWHQConstraintsDOV(LJHQVFKDIWHLQHU.ODVVH]X
ZHOFKHVHPDQWLVFKDOV,QYDULDQWHQIU2EMHNWH]X
LQWHUSUHWLHUHQVLQG,PZHLWHUHQN|QQHQGXUFKGLH$QJDEH
YRQ.DUGLQDOLWlWHQEHLGHU'HILQLWLRQYRQ%H]LHKXQJHQ
LPSOL]LWH.RQVWLVWHQ]EHGLQJXQJHQIRUPXOLHUWZHUGHQ
)UGLH6LFKHUXQJGHU.RQVLVWHQ]LQQHUKDOEGHU
'DWHQEDQNXPJHEXQJZHOFKHVHOEHUOHGLJOLFKLQKlUHQWH
.RQVWLVWHQ]EHGLQJXQJHQSUIHQNDQQVLQGGLHVH
0|JOLFKNHLWHQ]XZHQLJPlFKWLJ'LH.RQVLVWHQ]VLFKHUXQJ
PXVVLQ]ZHL'LPHQVLRQHQEHWUDFKWHWXQGVSH]LIL]LHUWZHUGHQ
N|QQHQ=XPHLQHQLVWGLH$UWGHU%HGLQJXQJLQKlUHQW
LPSOL]LWXQGH[SOL]LW]XGLIIHUHQ]LHUHQXQG]XPDQGHUHQGHU
*OWLJNHLWVEHUHLFK%HGLQJXQJPXVVVWHWVHUIOOWVHLQ
,QYDULDQWHXQG%HGLQJXQJGDUIZlKUHQGGHU$XVIKUXQJ
HLQHU7UDQVDNWLRQYHUOHW]WVHLQ
,PZHLWHUHQIHKOWLP'DWHQEDQNV\VWHPGLH0|JOLFKNHLW]XU
)RUPXOLHUXQJYRQH[LVWHQ]DEKlQJLJHQ
$JJUHJDWLRQVEH]LHKXQJHQ'DPLWYHUIJWVLHEHUNHLQHUOHL
5HJHOQIUGLH)RUWSIODQ]XQJYRQ(U]HXJXQJVRGHU
/|VFKDNWLRQHQ
,PNRQ]HSWXHOOHQ(QWZXUIPVVHQDOVR]XPHLQHQ
.RQVWUXNWHDQJHERWHQXQG]XPDQGHUHQHLQ9RUJHKHQ
GHILQLHUWZHUGHQXPGLHVHU3UREOHPDWLNEHUHLWVZlKUHQGGHU
(QWZXUIVSKDVHPlFKWLJ]XZHUGHQ
3.4.4 Objektevolution
,QREMHNWRULHQWLHUWHQ'DWHQEDQNHQZHUGHQ2EMHNWHPHLVWEHUHLQHQ
ODQJHQ=HLWUDXPJHVSHLFKHUW,QYLHOHQ$QZHQGXQJHQVROOWHQDEHU
HLQLJH2EMHNWHLKUH.ODVVHQ]XJHK|ULJNHLWZHFKVHOQN|QQHQ'LHVH
(LJHQVFKDIWZLUGÅ2EMHNWHYROXWLRQ´RGHUÅ,QVWDQ]PLJUDWLRQ´
JHQDQQW
Diplomarbeit
Schwachstellenanalyse • 57
:HGHUGLHEHWUDFKWHWH(QWZXUIVPHWKRGHQRFKGLHGDUXQWHUOLHJHQGH
'DWHQEDQNLPSOHPHQWDWLRQXQWHUVWW]HQGLHVHV.RQ]HSW'LH3UREOHPDWLN
EHVWHKWQXQGDULQGDVVEHLHLQHU6LPXODWLRQGHU,QVWDQ]PLJUDWLRQGXUFKGLH
=HUVW|UXQJGHU$XVJDQJVLQVWDQ]XQGGLH(U]HXJXQJHLQHU=LHOLQVWDQ]GLH
2EMHNWLGHQWLWlWQLFKWHUKDOWHQZHUGHQNDQQ'LHVEHGHXWHWGDVVVlPWOLFKH
%H]LHKXQJHQZHOFKHGDVÅDOWH´2EMHNWXQWHUKDOWHQKDWJHO|VFKWZHUGHQ
XQGVlPWOLFKH9HUELQGXQJHQGLH]XGLHVHP2EMHNWXQWHUKDOWHQZRUGHQ
VLQGQXQNHLQH*OWLJNHLWPHKUKDEHQ'DUEHUKLQDXVVLQGQDWUOLFKRKQH
VSH]LHOOHV(LQZLUNHQGHV3URJUDPPLHUHUVVlPWOLFKH(LJHQVFKDIWHQGHV
]HUVW|UWHQ2EMHNWHVYHUORUHQGDGLH$WWULEXWZHUWHJHO|VFKWZHUGHQ
(VPXVVDOVRHLQ2EMHNWHYROXWLRQVNRQVWUXNWHLQJHIKUWZHUGHQ
ZHOFKHVGLHIROJHQGHQ3UREOHPDWLNHQO|VHQNDQQ
%HKDQGOXQJYRQ5HIHUHQ]HQ]XDQGHUHQ2EMHNWHQ
(VPXVVHQWVFKLHGHQZHUGHQREGLH5HIHUHQ]HQJHO|VFKWHU]HXJW
RGHUEHLEHKDOWHQZHUGHQVROOHQ
%HKDQGOXQJYRQUHIHUHQ]LHUHQGHQ2EMHNWHQ
'LHMHQLJHQ2EMHNWHGLH]XGHU]XO|VFKHQGHQ]XHU]HXJHQGHQ
,QVWDQ]%H]LHKXQJHQXQWHUKDOWHQPVVHQYRQGHU0LJUDWLRQ
LQIRUPLHUWZHUGHQ'LHVN|QQWHZHQQGLH0LWWHOYRQDNWLYHQ
'DWHQEDQNHQQLFKW]XU9HUIJXQJVWHKHQRGHUQLFKW]X
NRPSOL]LHUWHQ7UDQVDNWLRQVEO|FNHQJHJULIIHQZHUGHQZLOOPLW
UFNEH]JOLFKHQ5HIHUHQ]HQJHO|VWZHUGHQ
%HKDQGOXQJYRQ6HOEVWUHIHUHQ]HQ
.|QQHQZLHJHZ|KQOLFKH5HIHUHQ]HQEHKDQGHOWZHUGHQ
%HKDQGOXQJYRQ5HIHUHQ]HQ]ZLVFKHQGHU$XVJDQJVXQG=LHOLQVWDQ]
.|QQHQZLHJHZ|KQOLFKH5HIHUHQ]HQEHKDQGHOWZHUGHQ
'DWHQEHUQDKPH
(VPXVVHQWVFKLHGHQZHUGHQZHOFKHGHU'DWHQDXIGLHQHXH,QVWDQ]
EHUWUDJHQYRQGHUDOWHQ,QVWDQ]EHUQRPPHQZHUGHQVROOHQ
(YROXWLRQVNRQWUROOH
(VPXVVHLQHUGULWWHQ,QVWDQ]GLH.RQWUROOHEHUGHQ
(YROXWLRQVSUR]HVVEHUJHEHQZHUGHQGDZHGHUGLH$XVJDQJVQRFK
GLH=LHOLQVWDQ]GLHVH5ROOHZDKUQHKPHQNDQQ
'LH'DWHQEDQNNDQQDXIJUXQGGHUIHKOHQGHQ0|JOLFKNHLWGHU
'%06(UZHLWHUXQJQLFKWXPGLH)lKLJNHLWGHU2EMHNWHYROXWLRQ
EHUHLFKHUWZHUGHQ'HQQRFKOlVVWVLFKGXUFKGLH(LQIKUXQJEHUHLWV
HUZlKQWHU.RQVWUXNWHHLQH0LJUDWLRQVLPXOLHUHQ'LH)lKLJNHLWHLQHU
.ODVVHHLQH,QVWDQ]PLJUDWLRQHLQ]XJHKHQLVWGDEHLLPVWDWLVFKHQ7HLO
0RGHOOLHUXQJGHU2EMHNWHLJHQVFKDIWHQ]XHQWZHUIHQZlKUHQGGHU
=HLWSXQNWXQGGLH%HGLQJXQJHQIUHLQH0XWDWLRQLPG\QDPLVFKHQ
7HLO(QWZXUIGHV2EMHNWYHUKDOWHQV]XVSH]LIL]LHUHQVLQG
3.4.4.1 Schwachstelle
'LH6FKZDFKVWHOOHEHVWHKWGDULQGDVVGHUJHZQVFKWH
.ODVVHQZHFKVHOHLQHV2EMHNWHVGXUFKHLQH(U]HXJXQJXQG
HLQH/|VFKXQJVLPXOLHUWZHUGHQPXVV'DEHLJHKWDEHUGLH
2EMHNWLGHQWLWlWZHOFKHIUGLH2EMHNWEH]LHKXQJHQYRQ
]HQWUDOHU%HGHXWXQJLVWYHUORUHQ(VIHKOWVRPLWHLQHLQYLHOHQ
$QZHQGXQJHQZLFKWLJH(LJHQVFKDIWYRQSHUVLVWHQWHQ
,QVWDQ]HQ
2EMHNWHYROXWLRQGXUFK
=HUVW|UXQJXQG
(U]HXJXQJ
3.4.5 Schemaevolution
58 • Schwachstellenanalyse
Diplomarbeit
:lKUHQGGHV%HWULHEHVYRQYRUDOOHPJU|VVHUHQ,QIRUPDWLRQVV\VWHPHQ
N|QQHQbQGHUXQJHQDQGHUHLQHU$QZHQGXQJ]X*UXQGHOLHJHQGHQ
'DWHQVWUXNWXU6FKHPDHUIRUGHUOLFKVHLQ'LHVH$QSDVVXQJHQGUIHQDXI
NHLQHQ)DOO]X'DWHQYHUOXVWHQRGHU,QWHJULWlWVYHUOHW]XQJHQIKUHQ
$XIGHUNRQ]HSWXHOOHQ(EHQHZLUGGLHVHV.RQ]HSWJlQ]OLFKYHUPLVVW
ZlKUHQGDXIGHUORJLVFKHQ(EHQH]XZHLOHQ9RUJHKHQVZHLVHQ
EHVFKULHEHQVLQGXPHLQHÅDOWHV´LQHLQÅQHXHV´6FKHPD]X
EHUWUDJHQ
,QUHODWLRQDOHQ'DWHQEDQNV\VWHPHQNDQQPDQGD]XGHQ
6FKHPDPDQLSXODWLRQVWHLOGHU$EIUDJHVSUDFKH64/]XU+LOIHQHKPHQ
%HIHKOHZLHALTER TABLEGLHQHQ]%]XU9HUlQGHUXQJYRQ
'DWHQWDEHOOHQRGHU5HODWLRQHQ
'DWHQYHUOXVWXQG
,QWHJULWlWVYHUOHW]XQJ
3UREOHPDWLVFKEHLGHU6FKHPDHYROXWLRQVLQGLQGHU5HJHOGDV+LQ]XIJHQ
YRQQHXHQ5HODWLRQHQ$WWULEXWHQRGHU,QWHJULWlWVEHGLQJXQJHQVRZLHGDV
(QWIHUQHQRGHUVHPDQWLVFKH9HUlQGHUQbQGHUQYRQ:HUWHEHUHLFKHQ
(LQHUVHLWVLVWGHU*UXQGKLHUIULQGHU7DWVDFKH]XVXFKHQGDVVLQ64/HLQ
DGlTXDWHU%HIHKOVVDW]IUGDV(QWIHUQHQYRQ$WWULEXWHQIHKOWDQGHUHUVHLWV
LVWHVLPDOOJHPHLQHQXQP|JOLFKXQWHU%HLEHKDOWXQJGHU
.RQVLVWHQ]EHGLQJXQJHQGLH,QWHJULWlWGHU'DWHQQDFKGHU9HUlQGHUXQJ]X
JHZlKUOHLVWHQ
,PDOOJHPHLQHQVLQGGDPLW6FKHPDHYROXWLRQHQQLFKWZlKUHQGGHV
%HWULHEHVGHU'DWHQEDQNP|JOLFKhEOLFKHUZHLVHZLUGGHU%HWULHEGHU
'DWHQEDQNZlKUHQGGHVbQGHUXQJVSUR]HVVHVYRP=XJULIIGXUFK
%HQXW]HUJHVFKW]W
(LQH6FKHPDHYROXWLRQPVVWHGDKHUHWZDLQIROJHQGHQ6FKULWWHQ
XQWHUQRPPHQZHUGHQ
'DWHQEDQNYRQGHQ=XJULIIHQGHU%HQXW]HUVFKW]HQ
3UIXQJGHU.RQVLVWHQ]EHGLJXQJHQXQWHUGUFNHQ
6FKHPDYHUlQGHUQ=XVWDQGLVWQXQP|JOLFKHUZHLVHLQNRQVLVWHQW
'DWHQLQVQHXH6FKHPDEHUQHKPHQQHXJHVFKDIIHQH$WWULEXWH
PVVHQPLWVLQQYROOHQ6WDQGDUGZHUWHQJHIOOWZHUGHQ
)RUPXOLHUXQJGHU.RQVLVWHQ]EHGLJXQJHQDQSDVVHQ
3UIHQGHU.RQVLVWHQ]GXUFK(YDOXDWLRQDOOHU
.RQVLVWHQ]EHGLQJXQJHQ
+LQ]XIJHQ(QWIHUQHQ
RGHUVHPDQWLVFK
9HUlQGHUQ
Å/D]\0LJUDWLRQ´
Diplomarbeit
)UGHQNRQ]HSWXHOOHQ(QWZXUIZUGHGDVEHGHXWHQGDVVEHLGHU
0RGHOOLHUXQJGHVG\QDPLVFKHQ9HUKDOWHQVGHU$VSHNWGHU6FKHPDHYROXWLRQ
PLWHLQEH]RJHQZHUGHQPVVWH(VPVVWHQDOVR.RQVWUXNWHRGHUJDQ]H
'LDJUDPPW\SHQ]XU9HUIJXQJJHVWHOOWZHUGHQPLWGHUHQ+LOIHHLQ
6FKHPDEHUJDQJVSH]LIL]LHUWZHUGHQN|QQWH'DPLWZUGHPDQGLH
(YROXWLRQVIlKLJNHLWHLQHU'DWHQEDVLV]XGHQQRUPDOHQG\QDPLVFKHQ
(LJHQVFKDIWHQHLQHV6\VWHPV]lKOHQ'LHVZUGHYRUDOOHPIU
'DWHQEDQNV\VWHPHSDVVHQZHOFKHGLHÅ/D]\0LJUDWLRQ´DXWRPDWLVFKH
0LJUDWLRQEHLP/HVHQYRQ2EMHNWHQLPSOHPHQWLHUHQ
Schwachstellenanalyse • 59
(LQDQGHUHU$QVDW]ZUGHDXIHLQHQHLQPDOLJHQ0LJUDWLRQSUR]HVVDE]LHOHQ
0DQZUGHKLHU]XGHQEHVWHKHQGHQ(QWZXUI]XU+DQGQHKPHQGLHVHQ
DQSDVVHQXQGVLFKYRQHLQHP:HUN]HXJGLH'LIIHUHQ]LQ)RUPHLQHV
0LJUDWLRQVVNULSWHVEHUHFKQHQODVVHQ'D]XPVVWHDEHUDXIGHUHLQHQ6HLWH
GDV'DWHQEDQNV\VWHPHLQHQ,QVWUXNWLRQVVDW]IUGLH6FKHPDHYROXWLRQ
DQELHWHQXQGDXIGHUDQGHUHQ6HLWHPVVWHGDV0LJUDWLRQVZHUN]HXJ
VLFKHUVWHOOHQN|QQHQGDVVGDV$XVJDQJVGLDJUDPPDXFKZLUNOLFKGHU
DNWXHOOHQ,PSOHPHQWDWLRQGHV6FKHPDVHQWVSULFKW5HYHUVH(QJLQHHULQJ
0LJUDWLRQVVNULSW
3.4.6 Sichtenkonzept
:HGHUNRQQWHVLFKGLH2'0*DXIHLQ6LFKWHQNRQ]HSWHLQLJHQZHOFKHV
PLWVHLQHPUHODWLRQDOHQ3HQGDQWYHUJOHLFKEDUZlUHQRFKVLQG$QVlW]H
GDYRQLQKHXWLJHQ,PSOHPHQWDWLRQHQYRQREMHNWRULHQWLHUWHQ
'DWHQEDQNV\VWHPHQ]XILQGHQ,Q24/N|QQHQ]ZDUGXUFKGLH
9HUZHQGXQJGHV6SUDFKNRQVWUXNWHVÅ1DPHG4XHU\´'DWHQEDQNDQIUDJHQ
JHVSHLFKHUWZHUGHQMHGRFKZLUGGDGXUFKK|FKVWHQVGLH/HVEDUNHLWYRQ
XPIDQJUHLFKHQÅ6(/(&7´%HIHKOHQXQWHUVWW]W
Å1DPHG4XHU\´
+lXILJZHUGHQZLH]%LQ2VLFKWHQlKQOLFKH.ODVVHQVRJHQDQQWH
([WHQVLRQHQLPSOHPHQWLHUW'LHVHELOGHQDEHUQLFKWHLQHQ%HVWDQGWHLOGHU
'DWHQEDQNXPJHEXQJYLHOPHKUPVVHQGLHVHYRQGHQ3URJUDPPLHUHQ
VHOEHUDNWXHOOJHKDOWHQZHUGHQ
([WHQVLRQHQZHUGHQHLQJHVHW]WXPJHZLVVH2EMHNWHDQKDQGHLQHV
6FKOVVHOZHUWHVGHUVLFKLP$OOJHPHLQHQYRQGHU2EMHNWLGHQWLWlW
XQWHUVFKHLGHWLQHLQHU0HQJHYRQ2EMHNWHQHLQ]XIJHQRGHU
DXI]XILQGHQ
([WHQVLRQHQDOV6LFKWHQ
'XUFKGLH(UZHLWHUXQJGHVLQGHU%RRFK·VFKHQ1RWDWLRQHLQJHIKUWHQ
.RQVWUXNWHVGHUDWWULEXWLHUWHQ%H]LHKXQJRGHUGXUFKGLH'HILQLWLRQYRQ
GHGL]LHUWHQ.ODVVHQOLHVVHVLFKHLQ6LFKWHQNRQ]HSWHQWZHUIHQ(VJlOWHGDEHL
]XUHJHOQZLHGLH6LFKWDXIJHEDXWXQGZLHVLHDNWXHOOJHKDOWHQZHUGHQVROO
ZHQQGLH'DWHQEDQNNHLQH7ULJJHUVSUDFKHXQWHUVWW]W
%HLGHU0RGHOOLHUXQJYRQ6LFKWHQDOV.ODVVHQPVVWHGLHIROJHQGH
)XQNWLRQDOLWlWLPSOHPHQWLHUWVHLQ
• 'LH.ODVVHPXVVHLQHQ$XIEDXPHFKDQLVPXV.RQVWUXNWRU
XQWHUVWW]HQ6ROOGLH6LFKWDOVWUDQVLHQWH.ODVVHPRGHOOLHUWVHLQNDQQ
GLHVEHUHLWVIUGLH*DUDQWLHUXQJGHU$NWXDOLWlWGHU'DWHQJHQJHQ
IDOOVVLHYRUMHGHU6HOHNWLRQNUHLHUWZLUG
• 'LH.ODVVHPXVVHLQHQ$NWXDOLVLHUXQJVPHFKDQLVPXV]XU
9HUIJXQJVWHOOHQ'DGLHREMHNWRULHQWLHUWHQ'DWHQEDQNHQNHLQH
7ULJJHUVSUDFKHQHQWKDOWHQPVVHQGLHEHREDFKWHQGHQ.ODVVHQEHU
0HOGXQJHQIUGLHbQGHUXQJHQGHUEHREDFKWHWHQ'DWHQLQIRUPLHUW
ZHUGHQ%HDFKWHWZHUGHQPXVVGDEHLGDVVVLFKGLH3HUVLVWHQ]QLFKW
XQHUZQVFKWDXIGLHVH.ODVVHQIRUWSIODQ]W(LQH$NWXDOLVLHUXQJ
N|QQWHEHUGLH)RUPXOLHUXQJYRQJHHLJQHWHQ
.RQVLVWHQ]EHGLQJXQJHQXQGGHQ(QWZXUIYRQVWUXNWXULHUWHQ
7UDQVDNWLRQHQJHZlKUOHLVWHWZHUGHQ'HU3URJUDPPLHUHUZUGHVLFK
GDEHLDEHUGHQRKQHKLQ]XU9HUIJXQJVWHKHQGHQ0HFKDQLVPHQ
EHGLHQHQPVVHQZHVKDOEGLHVHU$QVDW]QLFKWDOVVSH]LHOOHV
6LFKWHQNRQ]HSW]XEHWUDFKWHQLVW
• 'LH.ODVVHPXVVHLQHQ6DW]=XJULIIVIXQNWLRQHQDQELHWHQ'LHVH
|IIHQWOLFKHQ0HWKRGHQVROOWHQHVHUODXEHQGLH*HVQDPWPHQJH]X
DWWULEXWLHUWH%H]LHKXQJHQ
60 • Schwachstellenanalyse
Diplomarbeit
VHOHNWLHUHQEHLVSLHOVZHLVHIUGLH)RUPXOLHUXQJHLQHV6XE
6(/(&7HVEHUGLH0HQJH]XLWHULHUHQRGHUHLQEHVWLPPWHV
2EMHNWZHOFKHVHLQHUJHZLVVHQ%HGLQJXQJJHQJWDXI]XILQGHQ
)UGLH'HNODUDWLRQ$XIEDXGHU.ODVVHPVVHQIROJHQGH
(LJHQVFKDIWHQGHILQLHUWVHLQ
• 'HNODUDWLRQGHU5HIHUHQ]HQXQGGHUHQ1DPHQ$OLDV
• 'LH$UWGHU9HUNQSIXQJYRQPHKUHUHQ,QVWDQ]HQYHUVFKLHGHQHU
.ODVVHQ-RLQV
• )RUPXOLHUXQJGHUHLQVFKUlQNHQGHQ%HGLQJXQJHQ6HOHNWLRQ
• (LQVFKUlQNXQJGHU6LFKW3URMHNWLRQ
=XVDPPHQIDVVHQGOlVVWVLFKDOVRIHVWKDOWHQGDVVLQGHQ
REMHNWRULHQWLHUWHQ'DWHQEDQNHQYRUHUVWNHLQ.RQ]HSWIU6LFKWHQ
H[LVWLHUW=XGHPVFKlW]HQGLH(QWZHUIHUYRQJURVVHQ6\VWHPHQGHQ
1XW]HQDOVQLFKWDOO]XJURVVHLQ'DPLWOlVVWVLFKGLH(LQIKUXQJ
HLQHV6LFKWHQNRQ]HSWHVQLFKWDOVGULQJHQGHV%HGUIQLVGHU3UD[LV
EHWUDFKWHQ
=XGHPVWHKHQGHP(QWZLFNOHUEHLHLQHU8QWHUVWW]XQJYRQ
7UDQVDNWLRQVXQG.RQVLVWHQ]SUIXQJVPHFKDQLVPHQHLQPlFKWLJHV
:HUN]HXJ]XU9HUIJXQJXPVLFKWHQlKQOLFKH.ODVVHQLQGDV
'DWHQEDQNVFKHPDPLWHLQ]XEH]LHKHQ
3.5 Weitere Schwachstellen
,QGLHVH.DWHJRULHIDOOHQ6FKZDFKVWHOOHQGLHQLFKWHLQHPVSH]LHOOHQ7\S
]XJHRUGQHWZHUGHQN|QQHQDEHUGHQQRFKEHWUDFKWHWZHUGHQVROOWHQ'LHVH
8Q]XOlQJOLFKNHLWHQVWDPPHQDXVGHP(UIDKUXQJVVFKDW]YRQ
'DWHQEDQNDGPLQLVWUDWRUHQGLHLQGHU3UD[LVEHUHLWVJURVVH
'DWHQEDQNV\VWHPHHQWZRUIHQXQGLQGLH3URGXNWLRQEHUIKUWKDEHQ
3.5.1 Abfragen auf NULL-Werten
,Q24/N|QQHQ$EIUDJHQGHILQLHUWZHUGHQGLHHLQH$XVQDKPH]XU
)ROJHKDEHQ
%HLVSLHO%LEOLRWKHN6WXGHQWHQN|QQHQ%FKHUDXVOHLKHQPVVHQDEHU
QLFKW:HQQHLQH/LVWHGHUMHQLJHQ%FKHUHUVWHOOWZHUGHQVROOGLHYRQ
HLQHP6WXGHQWHQ$DXVJHOLHKHQVLQGZLUGIROJHQGH$EIUDJH
JHJHQEHUGHU'DWHQEDQNDEJHVHW]W
SELECT s->mat_nr, s->refBook->title
FORM s IN Student
WHERE s->name=“Müller“
'LH6LWXDWLRQGDVVHLQ6WXGHQWNHLQ%XFKDXVJHOLHKHQKDWLVW
GXUFKDXV]XOlVVLJIKUWDEHUEHLJHQDQQWHU$EIUDJH]XHLQHU
$XVQDKPH9LHOPHKUPVVWH]XHUVWGLH%H]LHKXQJGXUFKGLH
)RUPXOLHUXQJHLQHU%HGLQJXQJYDOLGLHUWZHUGHQ
SELECT s->mat_nr, s->refBook->title
FORM s IN Student
WHERE s->name=“Müller“
AND s->refBook NOT NULL
'DPLWPXVVPDQVLFKDEHUGDUDXIYHUODVVHQN|QQHQGDVVGHU24/
&RPSLOHUZLUNOLFK]XHUVWGLH%HGLQJXQJEHUSUIWEHYRUHUGHQ:HUW
LPQLFKWUHIHUHQ]LHUWHQ2EMHNWEHVFKDIIHQZLOO
1RFKVFKOLPPHUYHUKlOWHVVLFKZHQQIUGLH3UIXQJGHU%HGLQJXQJ
GLHYLHOOHLFKWQLFKWGHILQLHUWH5HIHUHQ]EHQ|WLJWZLUG%HLVSLHOVZHLVH
Diplomarbeit
Schwachstellenanalyse • 61
VROOGHU6WXGHQWJHIXQGHQZHUGHQGHUGDV%XFKÅ)DXVW´DXVJHOLHKHQ
KDW
SELECT s->name
FORM s IN Student
WHERE s->refBook->title=“Faust“
$OVRPVVWHDXFKKLHUGLH3UIXQJGHU5HIHUHQ]HUIROJHQ
SELECT s->name
FORM s IN Student
WHERE s->refBook NOT NULL
AND s->refBook->title=“Faust“
'DPLWOLHIHUWPDQVLFKZLHREHQDXIJH]HLJWGHU:LOONUGHV
YHUZHQGHWHQ24/,QWHUSUHWHUVY|OOLJDXVLQGHPPDQLPYRUQKHUHLQ
QLFKWPLW6LFKHUKHLWVDJHQNDQQZHOFKHU7HLOGHU%HGLQJXQJ]XHUVW
DXVJHZHUWHWZHUGHQZLUG
6LFKHUKHLWNDQQHLQHPKLHUQXUGDQQJHERWHQZHUGHQZHQQPDQ
]XHUVWHLQH6HOHNWLRQXQWHUGHP.ULWHULXPGHUGHILQLHUWHQ
)UHPGEH]LHKXQJDEVHW]WXQGDQVFKOLHVVHQGEHUGLHVH8QWHUPHQJH
ZHLWHUHLQVFKUlQNW
SELECT s->name
FORM s IN
SELECT s
FORM s IN Student
WHERE s->refBook NOT NULL
WHERE s->refBook->title=“Faust“
3.6 Evaluation
(VVROOQXQHQWVFKLHGHQXQGEHJUQGHWZHUGHQZHOFKHGHUEHREDFKWHWHQ
6FKZDFKVWHOOHQEHLGHU(UZHLWHUXQJGHU%RRFK·VFKHQ0HWKRGHEHUFNVLFKWLJW
ZHUGHQVROOHQYJO>%[email protected]
.RQVLVWHQ]VLFKHUXQJ
YHUVXV(QWZXUIVIUHLKHLW
$OVJHQHUHOOHV=LHOVROOYRUDOOHPGLH9HUEHVVHUXQJGHV6FKXW]HVGHU
'DWHQLQWHJULWlW.RQVLVWHQ]VLFKHUXQJYHUIROJWZHUGHQ'LH)UHLKHLWGHV
(QWZHUIHUVVROOGDEHLQLFKWLP9RUGHUJUXQGVWHKHQ
0DFKEDUNHLW
hEHUSUIEDUNHLW
:HLWHUHIUGLH$XVZDKOZLFKWLJ.ULWHULHQVLQGGLH0DFKEDUNHLW]X
ZHOFKHP*UDGOlVVWVLFKGLH6FKZDFKVWHOOHEHKHEHQ"XQGGLH
hEHUSUIEDUNHLWGXUFKDXWRPDWLVLHUWH:HUN]HXJHN|QQHQ(QWZXUIVIHKOHU
HUNDQQWZHUGHQ"=XGHPLVWHVIUDJZUGLJHLQ3UREOHPZHLWHU]XYHUIROJHQ
GDVQLFKWVWDQGDUGLVLHUWRGHUDXIHLQHEHVWLPPWH=LHOXPJHEXQJ
]XJHVFKQLWWHQLVW
3.6.1 Schwachstelle auf logischer Ebene
:LH%RRFKLQVHLQHU%HVFKUHLEXQJGHV3UR]HVVHVDQJLEWVROOHQ
(QWZXUIVNRQVWUXNWHGLHLQGHUEHWUDFKWHWHQ=LHOXPJHEXQJIHKOHQ
QLFKWYHUZHQGHWZHUGHQ
$XVGLHVHP*UXQGZHUGHQVlPWOLFKHGHUDQJHWURIIHQHQ
6FKZDFKVWHOOHQDXIGHUORJLVFKHQ(EHQHQLFKWLQGLHQHXH0HWKRGH
HLQEH]RJHQ
3.6.2 Schwachstellen auf der konzeptuellen Ebene
'HUDUWLJH6FKZDFKVWHOOHQ]HLJHQGHQHNODWDQWHQ+DQGOXQJVEHGDUI
XQGPVVHQDOOHVDPWLQGHUQHXHQ0HWKRGHDXVJHUlXPWVHLQ
1DPHQWOLFKVLQGGLHVGLH6FKZDFKVWHOOHQZHOFKHLP=XVDPPHQKDQJ
PLW
62 • Schwachstellenanalyse
Diplomarbeit
• GHU3HUVLVWHQ]
• GHQ$SSOLNDWLRQVNODVVHQXQGLQVWDQ]HQXQG
• GHQ7UDQVDNWLRQHQ
VWHKHQ9RQGHUZHLWHUHQ%HDUEHLWXQJVHLHQHLQ]LJGLHSK\VLVFKHQ
$VSHNWHDXVJHNODPPHUW
3.6.3 Vermisste Konstrukte
%HLGLHVHU.ODVVHYRQ6FKZDFKVWHOOHQJLOWHVGLH'ULQJOLFKNHLWXQG
GHQ1XW]HQDE]XVFKlW]HQ
6WDQGDUGIU
REMHNWRULHQWLHUWH
'DWHQEDQNV\VWHPH
'LH'ULQJOLFKNHLWGHILQLHUWVLFKDXVGHU%HDQWZRUWXQJGHU)UDJHZRKHUGLH
)RUGHUXQJQDFKGLHVHP.RQVWUXNWVWDPPW6WDPPWVLHDXVGHQYRQGHU
2'0*JHIRUGHUWHQ6WDQGDUGVIUREMHNWRULHQWLHUWH'DWHQEDQNV\VWHPH
LQYHUVH%H]LHKXQJHQ6FKOVVHOVROOGLHVHU)RUGHUXQJHKHUQDFKJHNRPPHQ
ZHUGHQDOVZHQQVLHDXVGHQ:QVFKHQHLQHV6\VWHPDGPLQLVWUDWRUV
6LFKWHQ6FKHPDHYROXWLRQKHUUKUW
=XGHPNDQQEH]JOLFKGHP1XW]HQGHUHLQHP(QWZLFNOXQJVWHDPGXUFK
GLH8QWHUVWW]XQJHLQHVJHZLVVHQ.RQ]HSWHVHQWVWHKWXQWHUVFKLHGHQ
ZHUGHQ+DQGHOWHVVLFKXP6WUDWHJLHQ]%IU)RUWSIODQ]XQJVXQG
.RQVLVWHQ]SUIXQJVPHFKDQLVPHQRGHU2EMHNWHYROXWLRQVRLVWGHU1XW]HQ
IUDOOH$QZHQGXQJVEHUHLFKHJURVVZlKUHQGGLH.RQVWUXNWHIUGLH
)RUPXOLHUXQJYRQVLFKHUHQ$EIUDJHQYHUPXWOLFKHKHUPLWJHULQJHUHU
3ULRULWlW]XEHKDQGHOQVLQG
=XVDPPHQIDVVHQGZHUGHQDOVRGLH6FKZDFKVWHOOHQLQGHQ%HUHLFKHQ
• ,QYHUVH%H]LHKXQJHQ
• ([WHQVLRQHQXQG6FKOVVHO
• )RUWSIODQ]XQJXQG.RQVLVWHQ]VLFKHUXQJXQG
• 2EMHNWHYROXWLRQ
ZHLWHUYHUIROJW
1XW]HQIUGDV
(QWZLFNOXQJVWHDP
3.6.4 Weiteres Vorgehen
$XVREHQJHQDQQWHQ%HZHJJUQGHQZHUGHQGLHLP)ROJHQGHQ
DXIJH]lKOWHQ6FKZDFKVWHOOHQZHLWHUXQWHUVXFKW)UMHGHGLHVHU
8Q]XOlQJOLFKNHLWHQLVWVNL]]LHUWLQZHOFKHU)RUP$QVWUHQJXQJHQIU
GHUHQ%HKHEXQJLQGHUHUZHLWHUWHQ0HWKRGHXQWHUQRPPHQZHUGHQ
VROOHQ
3.6.4.1 Konzeptuelle Ebene
3HUVLVWHQ]XQG
3HUVLVWHQ]IRUWSIODQ]XQJ
3HUVLVWHQ]XQG3HUVLVWHQ]IRUWSIODQ]XQJ'LH1RWDWLRQPXVVGHUDUWHUZHLWHUW
ZHUGHQGDVVGLH8QWHUVFKHLGXQJ]ZLVFKHQSHUVLVWHQ]IlKLJHQXQG
WUDQVLHQWHQ.ODVVHQHUP|JOLFKWZLUG)UGLH'HILQLWLRQGHUSHUVLVWHQWHQ
(LQVWLHJVSXQNWHPXVVHLQQHXHV.RQVWUXNWDQJHERWHQZHUGHQ9RQGLHVHP
$XVJHKHQPXVVGLH)RUWSIODQ]XQJGHU3HUVLVWHQ]GXUFKGLH+LQWHUOHJXQJ
HLQHUHQWVSUHFKHQGHQ6HPDQWLNIUJHZLVVH%H]LHKXQJVW\SHQNRQWUROOLHUW
ZHUGHQN|QQHQ
$SSOLNDWLRQVNODVVHQ
XQGLQVWDQ]HQ
$SSOLNDWLRQVNODVVHQXQGLQVWDQ]HQ'XUFKGLH(LQIKUXQJYRQ
.RQWUROOPHFKDQLVPHQEHUGLH'DXHUKDIWLJNHLWYRQ2EMHNWHQN|QQHQ
EHUHLWVYLHOH$VSHNWHGLHVHU6FKZDFKVWHOOHEHKREHQZHUGHQ7URW]GHPPXVV
GLH1RWDWLRQGLH6SH]LILNDWLRQYRQ6FKQLWWVWHOOHQ]ZLVFKHQGHU
$SSOLNDWLRQVXQGGHU'DWHQVFKLFKWHUODXEHQ
Diplomarbeit
Schwachstellenanalyse • 63
7UDQVDNWLRQHQ
7UDQVDNWLRQHQ(LQ]HQWUDOHU7HLOGHV$SSOLNDWLRQVHQWZXUIHVELOGHWGLH
'HILQLWLRQGHU7UDQVDNWLRQVEO|FNH'LH1RWDWLRQPXVVDOVRGHUJHVWDOW
DXVJHEDXWZHUGHQGDVVGHU(QWZHUIHUGXUFKGLH9HUZHQGXQJJHZLVVHU
.RQVWUXNWHGLH.RQWUROOHEHUGLH'DWHQEDQNRSHUDWLRQHQLQGLH+DQG
QHKPHQNDQQ
3.6.4.2 Vermisste Konstrukte
,QYHUVH%H]LHKXQJHQ
,QYHUVH%H]LHKXQJHQ'DVEHUHLWVYRUKDQGHQHQ%H]LHKXQJVNRQVWUXNWIUGLH
0RGHOOLHUXQJYRQ$VVR]LDWLRQHQVROOIUGLH%HODQJHGHULQYHUVHQ
%H]LHKXQJHQDXVJHZHLWHWZHUGHQ
([WHQVLRQHQXQG
6FKOVVHO
([WHQVLRQHQXQG6FKOVVHO'LH1RWDWLRQVROOQLFKWQHXH.RQVWUXNWHIUGLH
'DUVWHOOXQJYRQ([WHQVLRQHQHLQIKUHQ9LHOPHKUVROOHQJHZLVVH
.RQVWHOODWLRQHQYRQ.ODVVHQVWUXNWXUHQVHPDQWLVFK([WHQVLRQHQGHILQLHUHQ
6FKOVVHOVROOHQGHP]XIROJHQLFKW]XGHQ(LJHQVFKDIWHQHLQHUEHUZDFKWHQ
.ODVVHJH]lKOWZHUGHQVRQGHUQDOV(LJHQVFKDIWGHU([WHQVLRQVNODVVH
EHWUDFKWHWZHUGHQ
)RUWSIODQ]XQJXQG
.RQVLVWHQ]VLFKHUXQJ
)RUWSIODQ]XQJXQG.RQVLVWHQ]VLFKHUXQJ'DPLWEHLVSLHOVZHLVHGLH
/|VFKIRUWSIODQ]XQJNRQWUROOLHUWZHUGHQNDQQVROOHQIUGLH9HUZHQGXQJ
YRQ%H]LHKXQJVNRQVWUXNWHQVWUHQJH5HJHOQGHILQLHUWZHUGHQ'LHVHJUHQ]HQ
GLH)UHLKHLWGHV(QWZHUIHUVLQJHZLVVHHLQHPJHZLVVHQ0DVVHLQ
XQWHUVWW]HQDEHUGLH$VSHNWHGHU.RQVLVWHQ]VLFKHUXQJ
2EMHNWHYROXWLRQ
2EMHNWHYROXWLRQ'HU(LQEH]XJGHU2EMHNWHYROXWLRQDIIHNWLHUWQLFKWQXUGDV
VWDWLVFKH'LDJUDPPZHOFKHVVLFKPLWGHP(QWZXUIGHU2EMHNWH.ODVVHQ
XQGGHUHQ%H]LHKXQJHQEHVFKlIWLJWVRQGHUQDXFKGLHG\QDPLVFKHQ
'LDJUDPPHZHOFKHGLH0LJUDWLRQDOVHLQ9HUKDOWHQHLQHV2EMHNWHV
PRGHOOLHUHQVROOHQ,PVWUXNWXUHOOHQ(QWZXUIPXVVHLQQHXHV.RQVWUXNW
DQJHERWHQZHUGHQZHOFKHVGLH)lKLJNHLWHLQHU.ODVVH]XU,QVWDQ]PLJUDWLRQ
GHILQLHUWZlKUHQGLPG\QDPLVFKHQ(QWZXUIGLHYRUKDQGHQHQ(OHPHQWH
Å=XVWDQG´XQGÅ=XVWDQGVEHUJDQJ´JHQJHQVROOHQ
64 • Schwachstellenanalyse
Diplomarbeit
4 DEIMOS
4.1 Einleitung
Während im Kapitel 2 die Methode von Booch erklärt wurde und im
Kapitel 3 die Schwachpunkte bei deren Anwendung für den konzeptuellen
Datenbankentwurf analysiert worden sind, soll nun in diesem Kapitel eine
Erweiterung DEIMOS eingeführt werden, welche diese Schwachstellen
beseitigt.
4.1.1 Unterschiede zu der Methode von Booch
Die Methode von Booch soll weitgehend übernommen werden.
Dennoch sind für die speziellen Aspekte des Entwurfes von
objektorientierten Datenbanksystemen einige Erweiterungen
sowohl in den Bereichen der Notation als auch im Vorgehen nötig.
4.1.1.1 Die Notation
Um die im Kapitel 2 identifizierten Schwachstellen
ausräumen zu können, müssen verschiedene Elemente der
Booch’schen Notation verändert oder erweitert werden.
Zudem müssen neue Konstrukte in die Diagramme
eingeführt werden, um den erweiterten Anforderungen des
Datenbankentwurfes genügen zu können.
Die speziellen Eigenschaften von Datenbankklassen sind
im statischen Diagramm, welches zur Modellierung der
Klasseneigenschaften und -strukturen dient, spezifizierbar,
weshalb dieses Diagramm entscheidend erweitert wurde
und als Schemadiagramm seinen Platz in der Methode
DEIMOS erhält.
Da für den Entwurf von Datenbankapplikationen das
Design der Transaktionen von zentraler Bedeutung ist, wird
in Anlehnung an das Moduldiagramm ein neues Diagramm,
genannt Transaktionsdiagramm, in die Notation
aufgenommen.
Die Booch’schen Diagramme sollen dabei keineswegs aus
ihrer Position verdrängt werden, vielmehr sollen die neuen
Diagrammtypen zur Anwendung gelangen, wenn die
bisherigen Diagramme die Aspekte des
Datenbankentwurfes nicht genügend berücksichtigen
können.
4.1.1.2 Das Vorgehen
Wie bereits im vorigen Kapitel ausgeführt, beschäftigt sich
der Makroentwicklungsprozess schwergewichtig mit den
gewöhnlichen Managementaufgaben für die Realisierung
eines Entwicklungsprozesses. Die notwendigen
Erweiterungen im Vorgehen beziehen sich darum lediglich
auf den Mikroentwicklungsprozess, der gewisse Spezifika
von Datenbankentwicklungen berücksichtigen muss.
Für die Identifikation der Semantik der Klassen und
Objekte müssen für den Entwurf von objektorientierten
Datenbanksystemen zusätzliche Aspekte in diesen Schritt
Diplomarbeit
DEIMOS • 65
miteinbezogen werden. Zum einen muss die gewünschte
Lebensdauer eines Objektes untersucht werden, was sich
darin äussert, dass die entsprechenden Klassen die
Eigenschaft der Persistenzfähigkeit besitzen müssen. Zum
anderen ist es für den späteren Entwurf der Transaktionen
unerlässlich, zwischen lesenden und schreibenden
Zugriffen auf Objekte zu unterscheiden.
Nachdem bei der Identifikation der Objektsemantik
zwischen persistenten und transienten Objekten
unterschieden wurde, muss entsprechend für die
Identifikation der Beziehungen zwischen den Klassen
dieser Umstand berücksichtigt werden. Ein spezielles
Augenmerk sollte also auf die Umsetzung der
Persistenzfortpflanzung geworfen werden.
Zudem müssen beim Umgang mit persistenten Objekten die
Konsistenzsicherung und die Fortpflanzungsmechanismen
in den Entwurf miteinbezogen werden.
4.1.2 Das Beispiel FIS
Um die verschiedenen, in den nachfolgenden Abschnitten neu
eingeführten oder erweiterten Konstrukte zu veranschaulichen,
wird Schritt für Schritt ein jeweiliges Diagramm für die
Modellierung eines Informationssystems für die Firma
„Macrohard“ aufgebaut.
Dem Firmeninformationssystem (FIS) liegen folgende
Ausgangsinformationen zu Grunde:
• Die betrachtete Firma ist in der Softwareentwicklung tätig. Die
Entwicklungsaufträge werden von den Entwicklern bearbeitet und
von den Managern koordiniert.
• Die Firma besitzt verschiedene Büros als Räumlichkeiten.
Jedem Mitarbeiter steht ein Arbeitsplatz in einem der Büroräume
zur Verfügung. Büros dürfen auch leer stehen.
Das System muss folgende Manipulationen unterstützen:
• Anstellung und Entlassung von Entwicklern und Managern.
• Mieten von Büroräumen und deren Kündigung.
• Mitarbeiter einem Büro zuteilen oder die Zuteilung ändern.
• Entwickler einem Projektteam (Manager) zuordnen oder
Zuordnung ändern.
• Entwickler zu Managern befördern.
Der Benutzer muss über folgende Sachverhalte Auskunft erhalten
können:
• Welches sind die Mitarbeiter der Firma?
• Welches sind die Mitglieder eines vom Manager XY
koordinierten Projektteams?
• Welche Büros werden von welchen Mitarbeitern genutzt?
Das Firmeninformationssystem soll nun gemäss Kundenwunsch
innerhalb der objektorientierten Datenbankumgebung O2 realisiert
werden und über eine benutzerfreundliche Anwendungen
zugreifbar sein.
66 • DEIMOS
Diplomarbeit
4.2 Das Schemadiagramm
In der Methode von Booch wird bei der logischen Ansicht eines Systems
das Klassendiagramm verwendet, um die Existenz von Klassen und deren
Abhängigkeiten zu veranschaulichen. Das Diagramm repräsentiert eine
Ansicht der Klassenstruktur und dient dazu, für jede Klasse deren Rollen
und Verantwortlichkeiten zu entwerfen, damit das gewünschte Verhalten
des Systems erzielt werden kann.
Für den Entwurf eines Datenbanksystems ist dieser Schritt analog
aufzufassen. Da aber nicht das Design der Applikation im Vordergrund
steht - Anwendungen selber sind innerhalb der objektorientierten
Datenbankschemata nicht als Klassen modelliert - sondern der Entwurf
des Datenbankschemas, ist der von Booch vorgeschlagene Diagrammtyp
in seiner Idee und seiner Stellung innerhalb des Prozesses übernommen,
aber in Schemadiagramm umbenannt worden.
Nachfolgend sollen die Konstrukte des Diagramms vorgestellt und
insbesondere deren Gemeinsamkeiten, bzw. Unterschiede zu den
Booch’schen Entsprechungen erklärt werden. Dabei werden erst die
Klassen und deren Varianten, die verschiedenen Beziehungen zwischen
den Klassen und schliesslich die weiteren Elemente des Diagramms
erläutert.
Klassendiagramm Schemadiagramm
4.2.1 Klassen
Es werden drei verschiedene Klassentypen, die Datenbankklassen, die
Hilfsklassen und die abstrakten Klassen, eingeführt. Datenbankklassen
können Instanzen bilden, die persistent sind, während dies für
Hilfsklassen nicht zugelassen ist und dementsprechend verhindert werden
muss. Von abstrakten Klassen können hingegen gemäss der bekannten
Auffassung von Objektorientierung keine Instanzen gebildet werden.
Wird im Folgenden der Begriff „Klasse“ verwendet, so ist dieser als
Oberbegriff der drei erwähnten Ausprägungen zu verstehen.
Die Darstellung und die Semantik werden von der Booch-Methode
weitgehend übernommen. Die Klassen werden in der Form von
durch gestrichelte Linien begrenzte Wolken [Booch 94, p. 177]
dargestellt. Der Einfachheit halber werden sie aber in diesem
Dokument als Hexagone gezeichnet.
Der Name muss für ein Gesamtdiagramm eindeutig gewählt
werden, da für Datenbanksysteme dieser Name für ein Schema
eindeutig sein muss.
4.2.1.1 Eigenschaften
Datenbankklassen,
Hilfsklassen und
abstrakte Klassen
Diplomarbeit
DEIMOS • 67
Attribute und
Methoden
Mit der Klasse können deren Attribute und Methoden definiert werden.
Üblicherweise werden in dieser Stufe der Abstraktion nicht alle
notwendigen Methoden und Attribute definiert, da zum Zeitpunkt des
Entwurfes die genauen Bedürfnisse nach Daten und Fähigkeiten noch
nicht feststehen. Trotzdem sollten aber sämtliche von aussen sichtbare
(öffentliche) Attribute und Methoden (public members) spezifiziert sein,
damit bei Validierungsmethoden wie Structured Walkthrough
Schwachstellen des Entwurfes aufgedeckt werden können. Zudem ist die
frühe Definition der Schnittstellen für das Zusammenspiel verschiedener
Komponenten von grosser Wichtigkeit.
Attribute können in der Form
A : C [= D]
definiert werden. Mit A wird der Name des Attributes
angegeben, während mit C sein Typ (primitiver Datentyp
oder im Schema definierte Klasse) spezifiziert wird. Bei
Bedarf kann das Attribut durch einen Standardwert D
initialisiert werden.
Schlüssel
Ist die Klasse C1 ein Aggregat verschiedener Instanzen der Klasse C2, so
ist es sinnvoll, dass die Extensionsklasse C1 ihre Komponenten mittels
eines Schlüssels kontrolliert. „Schlüssel“ soll in diesem Zusammenhang
bedeuten, dass jede Instanz dieser Klasse bezüglich der im Schlüssel
definierten Attribute eindeutig identifizierbar sein muss. Die
Eindeutigkeit ist dabei nur im Bereich der Extension gewährleistet.
Attribute, welche zum Schlüsselkriterium gezählt werden sollen, sind
unter Angabe der überwachten Klassen in spitzen Klammern
einzuschliessen.
Class<Attrib[(,Attrib)*]>
Häufig werden implizite Attribute, z.B. Speicherplätze für
das Ablegen der Referenzen auf andere Objekte, der
Übersicht zuliebe nicht in den Entwurf miteinbezogen und
entsprechend im Schemadiagramm den Klassenikonen
nicht einbeschrieben.
Methodendeklarationen sind in der Form
[R|W] M(A : T[, A : T]*):V
zu formulieren. Dabei entsprechen die „A“s den Namen der
Parameter und entsprechend die „T“s deren Typen. Mit „V“
wird der Typ des Rückgabewertes spezifiziert. „M“ sei der
Name der Methode.
Steht zu Beginn der Methodendefinition ein „W“, so
beinhaltet die Methodenimplementierung schreibende
Zugriffe auf die Attribute oder ruft ihrerseits „W“Methoden ihrer Komponenten auf, während bei
vorangestelltem „R“ oder keiner Angabe die Attributwerte
nur gelesen werden. Diese Unterscheidung ist für den
Entwurf der Transaktionen von grosser Bedeutung.
Constraints
Den Klassen können auch sogenannte Constraints angehängt werden.
Diese müssen in der Form
{E}
68 • DEIMOS
Diplomarbeit
definiert werden. „E“ stehe dabei für einen beliebigen
logischen Ausdruck. In diesem Zusammenhang bedeutet
ein derartiger Constraint, dass keine Instanz der Klasse
diese Bedingung verletzen darf. Solche Einschränkungen
sollen in diesem Kontext Invarianten genannt werden. Das
heisst, sie müssen sowohl direkt nach der Kreation, als auch
am Ende jedes Aufrufes einer öffentlichen Methode erfüllt
sein.
Invarianten
Die Invarianten können also lediglich auf die Instanz selbst wirken, d.h.
es lassen sich mit diesem Konstrukt keine Interobjekt-Constraints
formulieren. Letzere müssen daher beim Entwurf der Transaktionen
mitberücksichtigt und entsprechend global definiert werden.
4.2.2 Beziehungen
Beziehungen sind die Verbindungen zwischen den eingeführten
Klassentypen. Sie definieren das Zusammenspiel und die
Zusammensetzung der zu modellierenden Entitäten. Beziehungen
werden zwar zwischen Klassen gezeichnet, wirken aber tatsächlich
zwischen Objekten. Aus diesem Grund muss durch die Angabe
von Kardinalitäten angegeben werden können, zu wievielen
Objekten eine bestimmte Instanz Relationen haben kann und
wieviele auf sie selber wirken dürfen.
Kardinalitäten
Etwas abweichend zu Booch werden folgende Kardinalitäten zugelassen:
n
genau n (n>0)
n+
beliebig viele, aber mindestens n (n>=0)
C
entweder eine oder keine (0|1)
[a..b]
mindestens a, höchstens b
Sämtliche aufgelisteten Kardinalitäten liessen sich auch mit dem
letzten Konstrukt [a..b] darstellen, werden aber zu Gunsten der
Lesbarkeit in der Kardinalitätsliste belassen, da sie in
verschiedenen anderen Methoden verwendet werden.
In den nachfolgenden Diagrammen werden vor allem die folgenden
Kardinalitäten angetroffen werden.
1
genau 1
1+
eine oder mehrere
0+
beliebig viele
Kardinalitäten werden „grösser als 1“ genannt, wenn sie
mindestens eine Beziehung verlangen, also eine
Existenzabhängigkeit beschreiben. Dies trifft demnach auf die
Bezeichnungen n und n+ mit (n>0) und [a..b] mit a>0 zu.
Wird bei einer Beziehung keine Kardinalität angegeben, wird dies
analog zu Booch’s Notation nicht als Standardwert, sondern als
„Nichtwissen“ interpretiert. Die genaue Spezifikation der
Mengenangabe ist in einem späteren Detaillierungsgrad
nachzutragen.
4.2.3 Datenbankklassen
Die zentrale Aufgabe einer Datenbank besteht darin, Daten über
die Lebenszeit des Prozesses, in dem sie erzeugt wurden, hinaus zu
erhalten. Objektorientierte Systeme sollen als dauerhafte Daten
Diplomarbeit
DEIMOS • 69
Objekte speichern. Sollen nun derartige Objekte in die Datenbasis
gelangen, so müssen sie Instanzen von Datenbankklassen sein.
Datenbankklassen zeichnen sich also dadurch aus, dass sie persistente
Instanzen haben können. Die Datenbasis besteht also immer nur aus
Objekten dieses Klassentyps, was ihm den Namen „Datenbankklasse“
eingetragen hat.
4.2.3.1 Konstrukt
persistente
Instanzen
class name
attributes
class<keyattrib.>
methods()
{constraints}
In der Methode von Booch wird ein Konstrukt für die Darstellung von
Klassen im Allgemeinen verwendet. Dieses Symbol wird direkt
übernommen.
4.2.3.2 Beispiel FIS
Zur Identifikation der Datenbankklasse werden zuerst die
Objekte betrachtet. Danach werden gleichartige Objekte zu
Objektklassen zusammengefasst.
In der Firma sind Entwickler und Manager beschäftigt.
Entwickler und Manager haben weder die gleichen Rechte
noch die gleichen Pflichten, sie sind also unterschiedlich zu
behandeln. Zudem besitzt die Firma Büros. Daraus lässt
sich die Existenz von verschiedenen „Entwickler“-,
„Manager“- und „Büro“- Objekten ableiten. Der Firma
können Fähigkeiten wie das Anstellen von
Entwicklern/Managern oder das Mieten von Büros
zugeordnet werden, was sie selbst auch zu einem Objekt
werden lässt.
Die einzelnen Entwickler unterscheiden sich - zumindest
aus der Betrachtungsweise des FIS - nicht, was die
Zusammenfassung dieser Objekte zu einer Klasse nahelegt.
Analog lassen sich so die Klassen Manager und Büro
herauskristallisieren. Die Firma selber ist ein einzelnes
Objekt und lässt sich so trivialerweise als Instanz einer
Klasse betrachten.
Alle gefundenen Objekte sollen über die Lebensdauer der
Anwendungen hinaus erhalten bleiben, was deren
Speicherung in der Datenbasis nahelegt. Aus diesem Grund
müssen sie als Instanzen von persistenzfähigen Klassen
(Datenbankklassen ) modelliert werden.
Den einzelnen Klassen werden, soweit dies zu dieser Stufe
der Abstraktion möglich ist, bereits Attribute und
Methoden zugeordnet.
Firma
<Name>
Adresse
Entwickler
<Name>
Adresse
Manager
<Name>
Adresse
Büro
<Nummer>
Abbildung 4-1: Datenbankklassen im Schemadiagramm
4.2.4 Hilfsklassen
70 • DEIMOS
Diplomarbeit
transiente Objekte
Nicht alle Objekte, die während der Bearbeitung der Datenbasis erzeugt
werden, sollen nach Beendigung der Anwendung in der Datenbank
gespeichert werden. Der Entwickler möchte für die Implementation von
Programmen gleichsam transiente Objekte anlegen dürfen, ohne Gefahr
zu laufen, dass diese unbeabsichtigterweise persistent werden.
Während Datenbankklassen dadurch gekennzeichnet sind, dass sie
persistente Instanzen erzeugen können, muss für die Allokation von
flüchtigen Objekten (Hilfsobjekten) ein weiteres Konstrukt eingeführt
werden. Tatsächlich liessen sich sämtliche transiente Objekte auch als
Instanzen von Datenbankklassen modellieren. Dies trüge aber den
Nachteil in sich, dass vom System her keinerlei Schutzmechanismen
greifen könnten, die den Entwerfer vor den angesprochenen
Nebeneffekten bewahren würden.
Wird dem Entwerfer jedoch die Möglichkeit gegeben, bereits
während des Entwurfes zwischen persistenten und transienten
Objekten durch die Verwendung von unterschiedlichen
Konstrukten zu differenzieren, kann durch systemunterstützte
Validierungen verhindert werden, dass sich die Persistenz auf
Hilfsobjekte ausdehnt.
4.2.4.1 Konstrukt
Persistenz versus
Transienz
class utility name
attributes
methods()
{constraints}
In Booch’s Methode findet sich ein Konstrukt für „Class-Utilities“.
Dieses wird direkt übernommen. Die Hilfsklassen können also als
Spezialisierung der vorgängig erläuterten Klassenkonstrukte aufgefasst
werden.
4.2.4.2 Beispiel FIS
Aus der Anforderung, dass die Liste der Büros mit den
jeweilig zugeteilten Mitarbeitern stets verfügbar sein muss,
kann das Bedürfnis entstehen, eine Hilfsklasse zu bilden,
welche die gewünschten Dienste wie Drucken, Anzeigen,
usw. kapselt. Es wird also dem Diagramm eine weitere
Klasse „Büroliste“ als Hilfsklasse hizugefügt.
Denkbar wären weitere Klassen als reine Datenstrukturen,
die z.B. die Adressinformationen aufnehmen könnten.
Derartige Klassen sind aber innerhalb der
Datenbankumgebung O2 als tuple formulierbar und werden
daher nicht als Klassen modelliert, falls sie nicht noch
weitere Funktionalitäten aufweisen müssen.
Firma
<Name>
Adresse
Entwickler
<Name>
Adresse
Manager
<Name>
Adresse
Büro
<Nummer>
BüroListe
Show()
Print()
Diplomarbeit
DEIMOS • 71
Abbildung 4-2: Hilfsklassen im Schemadiagramm
4.2.5 Vererbungsbeziehung
Die für die Instantiierung der notwendigen Objekte benötigten Klassen
werden in einem ersten Überarbeitungsschritt auf Gemeinsamkeiten
untersucht. Häufig werden dabei Klassen gefunden, die als
Spezialisierungen von anderen bereits im Entwurf gezeichneten Klassen
aufgefasst werden können. Somit macht es aus der Sicht der
Objektorientierung keinen Sinn, die Gemeinsamkeiten redundant zu
implementieren. Vielmehr werden durch die Verwendung von
Vererbungsbeziehungen die Eigenschaften der Superklasse auf die
Unterklasse übertragen.
Werden Klassen gefunden, die einen gewissen Teil ihres jeweiligen
Verhaltens gemeinsam haben, kann der Entwerfer diese
Gemeinsamkeiten in eine neue Klasse auslagern, die anschliessend
gegenüber der speziellen Klassen durch die Definition von neuen
Vererbungsbeziehungen als Superklasse deklariert wird.
4.2.5.1 Konstrukt
Generalisierung
und Spezialisierung
Die Vererbungsbeziehung wird sowohl in der Darstellung als auch in der
Semantik direkt von der Booch-Methode übernommen. Sie dient zur
Darstellung von Generalisierungs- bzw. Spezialisierungsbeziehungen
(„is-a“). Die Vererbung wirkt zwischen zwei Klassen, wobei der Pfeil bei
der Unterklasse beginnt und bei der Superklasse in die Spitze ausläuft.
4.2.5.2 Einschränkungen
Damit die Semantik der Vererbungsbeziehung nicht
verletzt wird, müssen für dessen Verwendung einige
einschränkende Regeln beachtet werden:
• Es dürfen keine Vererbungszyklen entstehen (eine
Klasse darf also insbesondere keine Vererbungsbeziehung
zu sich selber unterhalten).
• Eine abstrakte Klasse muss mindestens eine Unterklasse
haben.
• Eine Klasse kann an mehreren solchen Beziehungen
teilnehmen, sei es als Superklasse von mehreren
Unterklassen, oder als Unterklasse mehrerer Superklassen
(Mehrfachvererbung).
4.2.5.3 Beispiel FIS
Nachdem die Klassen identifiziert worden sind, soll sich
der Entwerfer auf die Suche nach Klassen mit
Gemeinsamkeiten machen. Diese Übereinstimmungen
lassen sich in eine Superklasse auslagern, von der die
entsprechenden Unterklassen die gemeinsamen
Eigenschaften vererbt bekommen.
Das Ziel dieses Schrittes ist es zudem, Superklassen zu
finden, deren Eigenschaften so allgemein wie möglich und
so speziell wie nötig sind, damit sie in späteren
Anwendungen als Komponenten wiederverwendet werden
können.
72 • DEIMOS
Diplomarbeit
Wenn für die bereits gefundenen Klassen Gemeinsamkeiten
zu finden sind, drängen sich die beiden Klassen Entwickler
und Manager nachgerade auf. Beide Klassen beschreiben
eine Person und einen Mitarbeiter. Eigenschaften dieser
gemeinsamen Basis können also in eine Superklasse
ausgelagert werden. Der Entwickler und der Manager sind
in der Folge als Spezialisierung dieser neuen Klasse
„Mitarbeiter“ zu betrachten.
Firma
<Name>
Adresse
Entwickler
BüroListe
Show()
Print()
Manager
Büro
<Nummer>
Mitarbeiter
<Name>
Adresse
Abbildung 4-3: Schemadiagramm mit Vererbung
4.2.6 Abstrakte Klassen
Abstrakte Klassen sind dadurch gekennzeichnet, dass sie keine
Instanzen besitzen dürfen. Üblicherweise werden derartige Klassen
dort verwendet, wo für mehrere Klassen Übereinstimmungen
gefunden wurden, die gemeinsame Basisklasse jedoch semantisch
nicht sinnvoll instantiiert werden kann.
4.2.6.1 Konstrukt
A
class name
attributes
class<keyattrib.>
methods()
{constraints}
Das Konstrukt der abstrakten Klasse ist in Booch’s Diagrammen
gleichfalls anzutreffen und wird aus diesem Grund direkt übernommen.
Die Ikone trägt im Bereich der rechten oberen Ecke ein nach unten
zeigendes Dreieck, was sie von der Datenbankklasse abhebt, ansonsten
ist die Darstellung analog.
4.2.6.2 Beispiel FIS
Von den bereits identifizierten Klassen ist die
Instanzenbildung im Falle der Klasse „Mitarbeiter“
semantisch nicht sinnvoll. Damit wird diese zu einer
abstrakten Klasse.
Firma
<Name>
Adresse
Entwickler
Manager
Büro
<Nummer>
A
BüroListe
Show()
Print()
Mitarbeiter
<Name>
Adresse
Abbildung 4-4: abstrakte Klassen im Schemadiagramm
4.2.7 Objekte
Diplomarbeit
DEIMOS • 73
Für den Entwurf von Datenbankschemata ist es unerlässlich, sich mit den
Persistenzmechanismen des Zielsystems auseinanderzusetzen. In
Systemen, die „Persistenz durch Erreichbarkeit“ implementiert haben,
muss für mindestens ein Objekt die Persistenz explizit erzwungen
werden. Dieses Objekt wird so für das System der Ausgangspunkt der
Persistenzfortpflanzung.
Aus diesem Grund muss der Notation ein Konstrukt zur Verfügung
stehen um derartige Verankerungsobjekte bereits im Entwurf zu
berücksichtigen.
4.2.7.1 Konstrukt
Persistenzmechanis
men
In Booch’s Methode werden in den Klassendiagrammen nur die Klassen
und deren Abhängigkeiten betrachtet. Der Entwurf von Objekten als
Instanzen von Klassen wird also streng von den Klassendiagrammen
getrennt, sofern sie nicht selber als Klassen aufgefasst werden können,
wie dies bei Metaklassen oder instantiierten Klassen von
parametrisierbaren Klassen der Fall ist.
Im Gegensatz dazu lässt sich das Definieren von Objekten
nicht aus dem Schemadiagramm verbannen, da es fester
Bestandteil des Schemaentwurfes ist. Derartige Objekte
werden mit Hilfe der von Booch vorgeschlagenen
Objektikonen dargestellt.
Diese Objekte müssen einen systemweit eindeutigen
Namen tragen. Auf die Angabe der Attribute und Methoden
kann verzichtet werden, da die Objekte immer mit einem
Instantiierungspfeil an eine bereits definierte Klasse
angebunden sind.
PersistentName
4.2.8 Instantiierungsbeziehung
Objekte sind Klasseninstanzen, deren Persistenz explizit erzwungen wird.
Die Fähigkeit, persistente Instanzen ausbilden zu können, ist aber gemäss
Definition einzig den Datenbankklassen vorbehalten. Aus diesem Grund
muss ein Objekt mit einer Datenbankklasse in Relation stehen. Zudem
muss der Entwerfer definieren können, von welcher
Klassenzugehörigkeit das dauerhaft in der Datenbasis gespeicherte
Objekt sein soll.
Durch die Erweiterung der Notation um das Konstrukt der
Instantiierungsbeziehung können die gewünschten Eigenschaften
der explizit persistenten Objekte modelliert werden.
4.2.8.1 Konstrukt
explizite Persistenz
Diese Beziehung zwischen dem Objekt und der Klasse wird durch den
Instantiierungspfeil dargestellt. Dieser Pfeil ist auch in der Methode von
Booch enthalten, unterliegt jedoch dort einer völlig anderen Semantik, da
er dort im Zusammenhang mit der Instantiierung von Metaklassen
verwendet wird.
Ein Objekt muss als eine Instanz von genau einer Klasse
aufgefasst werden. Es können durch dieses Konstrukt keine
Hilfsklassen instantiiert werden.
4.2.8.2 Objekte und Instantiierung
74 • DEIMOS
Diplomarbeit
A
Einstiegspunkt
Durch den gestrichelten Pfeil wird eine Instanz der Datenbankklasse A
gebildet. Das Objekt wird Einstiegspunkt genannt und durch seinen
Namen identifiziert.
Ein Einstiegspunkt wird als persistente Instanz einer Klasse
aufgefasst. Die Klasse selbst wird dadurch persistenzfähig
und kann Komponenten enthalten.
In den betrachteten Methoden wurde beanstandet, dass
nicht zwischen persistenten und transienten Klassen
unterschieden werden konnte. Mit der neuen Methode aber
werden dem Entwerfer Konstrukte in die Hand gelegt, mit
denen er diesen Unterschied während des Entwurfes
mitberücksichtigen kann.
4.2.8.3 Einstiegspunkt
Persistenzfortpflanz
ung
Persistenzgraph
Diplomarbeit
Name
Datenbankumgebungen, welche der „Persistenz durch Erreichbarkeit“
Folge leisten, verlangen für eine Schemadefinition mindestens einen
persistenten Einstiegspunkt. Dieser muss eine Instanz einer
persistenzfähigen Klasse sein und kann demnach als globales Objekt
betrachtet werden. Die globale Instanz wird über den sogenannten
persistenten Namen identifiziert.
Ist ein solcher Einstiegspunkt einmal definiert, werden sämtliche von ihr
referenzierten Instanzen gleichfalls persistent. Der Einstiegspunkt kann
also bezüglich der Persistenzfortpflanzung als Wurzel des
Persistenzgraphen betrachtet werden.
4.2.8.4 Einschränkungen
Damit die Semantik der Instantiierungsbeziehung nicht
verletzt wird, müssen für dessen Verwendung einige
einschränkende Regeln beachtet werden:
• Es dürfen nur Datenbankklassen instantiiert werden.
• Ein Einstiegspunkt muss durch genau einen
Instantiierungspfeil an eine Datenbankklasse gebunden
werden (ein Objekt kann nicht Instanz mehrerer Klassen
sein).
• An eine Datenbankklasse dürfen mehrere
Einstiegspunkte gebunden sein.
• Ein Schemadiagramm muss mindestens einen solchen
Einstiegspunkt enthalten.
• Einstiegspunkte können nicht an anderen Beziehungen
teilnehmen (die Beziehungseigenschaften werden von der
instantiierten Klasse übernommen).
• Der Name muss für ein Diagramm eindeutig gewählt
sein.
4.2.8.5 Beispiel FIS
DEIMOS • 75
Ein Schemadiagramm muss einen persistenten
Einstiegspunkt besitzen. Im Beispiel FIS wird genau eine
Firma namens „Macrohard“ betrachtet und es existiert eine
entsprechende Datenbankklasse „Firma“. Somit wird
sinnvollerweise ein explizit persistentes Objekt mit dem
Namen „Macrohard“ ins Diagramm eingefügt und dieses
mit einem Instantiierungspfeil an die Datenbankklasse
„Firma“ gebunden.
BüroListe
Show()
Print()
Büro
<Nummer>
Entwickler
Manager
A
Firma
<Name>
Adresse
Macrohard
Mitarbeiter
<Name>
Adresse
Abbildung 4-5: Schemadiagramm mit persistentem Einstiegspunkt
4.2.9 Komponentenbeziehung
Existenzabhängigkei
t
Objektorientierte Datenbanksysteme unterstützen keine
Aggregationsbeziehungen und können so nicht den Anforderungen der
vollständigen Objektorientierung genügen. Für viele Anwendungen sind
aber genau die Eigenschaften der Existenzabhängigkeit wünschenswert,
da sie die Konsistenzsicherung bei der Erzeugung und Löschung von
Objekten gewährleisten helfen.
Komponentenbezieh
ung versus Referenz
Für den Entwerfer sind die implementationsspezifischen
Einschränkungen der Zielsysteme irrelevant, solange er auf der
konzeptuellen Ebene die Eigenschaften von Aggregationen abbilden
kann. Dieser Sichtweise wird Rechnung getragen, indem während des
Entwurfes zwischen der Komponentenbeziehung und der allgemeinen
Referenz unterschieden werden kann.
Zudem sollen im Entwurf bereits die Aspekte der Persistenzfortpflanzung
und der Lösch-, bzw. Einfügepropagation mitberücksichtigt werden
können. Im weiteren sollen zu jedem Zeitpunkt die Objektsammlungen
durch die Definition von Extensionen zugänglich sein, um bestimmte
Objekte auffinden oder um Einfügeeinschränkungen (Schlüssel)
formulieren zu können.
4.2.9.1 Konstrukt
Propagation
[K A ]
76 • DEIMOS
[K B ]
In Booch’s Methode ist die Relation „has-a by value“ vorgeschlagen.
Diese wird mit einer kleinen Erweiterung übernommen.
Mit dieser Beziehung wird das physische Enthaltensein in
einer anderen Klasse dargestellt (existenzabhängige
Aggregation). Eine Klasse kann nicht in sich selber
enthalten sein (keine Rekursion). Das Konstrukt beginnt bei
der Aggregatsklasse mit einem ausgefüllten schwarzen
Kreis und endet bei der Komponentenklasse mit einem
ausgefüllten schwarzen Quadrat.
Diplomarbeit
Die Beziehung kann auf der Seite der Komponente eine Kardinalität
tragen, welche die Mengeneinschränkung angibt, während auf der
gegenüberliegenden Seite die Kardinalität zu interpretieren ist, als
exklusive Aggregation, im Falle 0, 1, C, oder nicht-exklusive
Aggregation, wenn sie grösser als 1 ist. Wird die Kardinalitätsangabe auf
der Seite des Kreises gänzlich weggelassen, wird damit eine exklusive
Aggregation ausgedrückt. Das Weglassen der Kardinalität KB hingegen
wird mit der Angabe 0+ gleichgestellt.
4.2.9.2 Verwendung
exklusive und nichtexklusive
Aggregation
A
[K A ]
KB
B
Eine Komponentenbeziehung wirkt zwischen einer Klasse
A, die als Besitzer der Beziehung definiert wird, und der
Klasse B, die als Teilnehmer bezeichnet wird. Auf der Seite
des Besitzers steht der ausgefüllte schwarze Kreis und auf
der Seite des Teilnehmers das ausgefüllte schwarze
Quadrat.
Die Komponentenkardinalität KB definiert die Anzahl der
Komponenten, die eine Instanz der Klasse A vom Typ B
haben kann oder muss. Diese wird durch eine
Minimalangabe, welche beziffert werden muss, und eine
Maximalangabe, welche offen gelassen werden darf,
definiert.
Der Besitzer der Komponentenbeziehung wird
Aggregationsklasse genannt (A), während der Teilnehmer
Komponente heisst (B).
Die Komponentenbeziehung kann als eine gerichtete Kante im
Komponentengraphen definiert werden. In diesem Graphen werden als
Knoten nur die Klassen gemäss obiger Definition und die
Komponentenbeziehung als gerichtete Kanten betrachtet. Aus der
Forderung, dass eine Instanz einer Klasse nicht in mehreren Aggregaten
vorkommen darf, lässt sich ableiten, dass es sich bei diesem Graphen
sogar um einen allgemeinen Baum handeln muss. Werden die
persistenten Einstiegspunkte als Komponenten einer virtuellen Wurzel
definiert und die Instantiierungsbeziehungen als Kanten in den Baum
übernommen, muss er sogar zusammenhängend sein.
4.2.9.3 Semantik
Komponentengraph
Diplomarbeit
DEIMOS • 77
Ist die Datenbankklasse A persistenzfähig, so überträgt sie diese
Eigenschaft auf die Datenbankklasse B. Da alle Datenbankklassen als
Komponenten von bereits persistenzfähigen Klassen definiert sind, kann
jede Klasse als Bestandteil eines Einstiegspunktes angesehen werden.
Auf diese Weise entstehen entweder ein Komponentenbaum oder
mehrere disjunkte Komponentenbäume. Der im vorigen Abschnitt
erwähnte Persistenzgraph kann auf diese Komponentenbäume abgebildet
werden, woraus sich für das Schema die Eigenschaft ergibt, dass sich die
Persistenz entlang der Komponentenbeziehungen fortpflanzt.
Ist die Beziehung invers definiert, so kennt die
Komponentenklasse ihre Aggregationsklasse, d.h. mit einer
Referenz auf die Klasse B kann die Referenz auf die Klasse
A beschafft werden.
Fortpflanzung der
Persistenz entlang
der Komponentenbeziehungen
Extension und
Schlüsselbeziehunge
n
Hat die Beziehung bei B eine Kardinalität grösser als 1, so bedeutet das,
dass die Klasse A mehr als eine Komponente vom Typ B enthält. Die
Instanz der Klasse A enthält dann entsprechend die Extension der
Komponenten vom Typ B, über welche z.B. ein bestimmtes Exemplar
ausfindig gemacht werden kann. Zudem können beim Einfügen die
Schlüsselbeziehungen überprüft werden.
Mit der Komponentenbeziehung wird eine Existenzabhängigkeit
dargestellt. Soll also eine Beziehung zwischen einer Instanz von A zu
einer Instanz von B aufgebaut (abgebaut) werden, muss die Instanz neu
kreiert (gelöscht) werden. Die Instanzen der Aggregationsklasse üben
also die Kontrolle über ihre Komponenteninstanzen aus, d.h. dass
Komponenten nur vom Besitzer erzeugt oder gelöscht werden können.
Daraus lässt sich ableiten, dass, wenn der Entwerfer
wünscht, eine Instanz Bm der Klasse B direkt zu löschen,
etwa mit der Anweisung
delete Bm
so muss er dies über einen Umweg erledigen. Zunächst
muss die Komponentenbeziehung zwischen A und B invers
definiert sein, damit von B aus seine Kontrollklasse
aufgespürt werden kann. Dann kann er über diese Referenz
der Instanz von A die Nachricht
Bm->refA->RemoveB(Bm)
schicken. Somit wird die Aggregationsklasse, die bezüglich
der Löschung von B-Instanzen monopolistisch agiert,
angewiesen, die Instanz Bm aus der Datenbasis zu
entfernen.
4.2.9.4 Extensionen
Existenzabhängigkei
t
lokale Extension
78 • DEIMOS
Eine Extension ist gemäss Definition die Menge aller zu einem gewissen
Zeitpunkt existenten persistenten Instanzen einer Klasse C. Der Begriff
wird für die Verwendung innerhalb der Methode auf den Begriff der
globalen Extension ausgeweitet. Zusätzlich muss der Begriff der lokalen
Extension eingeführt werden. Wird nur der Begriff „Extension“
verwendet, gilt das Ausgesagte sowohl für den einen wie auch für den
andern Typ.
Diplomarbeit
Stelle man sich eine Klasse A, bestehend aus 1+
Komponenten der Klasse B, und jedes B wiederum als
Aggregation von 1+ Komponenten der Klasse C, vor. Die
globale Extension der Klasse C, also die Gesamtsammlung
der Instanzen Ci. liegt in keiner der Klassen explizit vor.
Sie kann aber aus der Vereinigung der Teilextensionen oder
der lokalen Extensionen, die in den Instanzen Bj enthalten
sind, gewonnen werden.
Es muss also kein spezielles Konstrukt für die Modellierung von
Extensionen in die Notation aufgenommen werden. Vielmehr
übernehmen die Aggregationsklassen die Rollen der Instanzsammlungen.
Dank der Forderung nach Komponentenbäumen ist jede
Instanz einer Aggregationsklasse also eine lokale Extension
ihrer Komponenteninstanzen und in der umgekehrten
Richtung ist jede Extension, global oder lokal,
trivialerweise die Aggregation der gesammelten Objekte.
Aus diesem Umstand lassen sich für die Extensionen
verschiedene Eigenschaften ablesen:
• Eine Instanz gehört zu genau einer Extension.
• Der Durchschnitt aller lokalen Extensionen ist leer. Die
Vereinigung aller lokalen Extensionen entspricht der
globalen Extension. Die Vereinigung aller globalen
Extensionen deckt sich bijektiv mit allen in der Datenbasis
enthaltenen Objekten.
• Die Extension unterliegt denjenigen mengenwertigen
Einschränkungen, die durch die Kardinalitätsbedingung der
Komponentenbeziehung definiert sind.
• Eine Instanz ist immer eine (direkte oder indirekte)
Komponente eines Einstiegspunktes. Deshalb lässt sich
über ihn immer die globale Extension zusammenstellen.
Eine Extension nimmt also keine spezielle Rolle innerhalb
des Entwurfes oder der Implementation wahr, die
Aggregationstypen werden vielmehr um die Eigenschaften
der Extensionen angereichert. Eine Extension muss die
Fähigkeit besitzen, ein Objekt in sich aufzunehmen, eines
zu entfernen und ein sich entweder durch bestimmte
Attributsausprägungen oder durch seine Identität
auszeichnendes Objekt aufzufinden. Die ersten beiden
Fähigkeiten sind für alle Datenbankklassen durch die
Eigenschaften, die sie aus der Notwendigkeit der
Fortpflanzungunterstützung geerbt haben, bereits enthalten,
während die dritte den derartigen Klassen noch
hinzuzufügen ist.
4.2.9.5 Schlüssel
Die Methode bietet dank der Erweiterung des
Klassenkonstruktes die Definitionsmöglichkeit von
Schlüsselattributen, aus denen der Schlüssel gewonnen
Aggregationsklasse
n als Extensionen
Diplomarbeit
DEIMOS • 79
werden kann. Schlüssel sind Tupel von Attributen einer
Klasse und dienen den folgenden Zwecken:
1. Sie sollen die Eindeutigkeit innerhalb einer Extension
bezüglich der Schlüsselattributwerte gewährleisten.
2. Sie sollen Kriterien für das wertbasierte Auffinden von
bestimmten Objekten definieren helfen.
3. Sie sollen Sortierungen und Gruppierungen
ermöglichen.
4. Sie sollen Kriterien für leistungssteigernde Massnahmen
wie Indexierung liefern.
Ein Schlüssel ist eine Eigenschaft der
Aggregationsbeziehung. Sind die Instanzen der Klasse B
Komponenten der Klasse A und sollen diese bezüglich
eines bestimmten Attributes eindeutig sein, wird diese
Einschränkung der Klasse A in der Form
B<Key>
einbeschrieben. Die Definition von Schlüsseltupeln hat also
lediglich Einfluss auf die Instanzen der Extensionsklasse.
Insbesondere wirkt sie auf die Methoden für das Einfügen
eines neuen Objektes und auf das Auffinden eines
bestimmten Objektes, das durch seine
Schlüsselattributsausprägungen somit identifizierbar
gemacht wurde.
Da wie im vorigen Abschnitt ausgeführt, zwischen globalen
und lokalen Extensionen unterschieden werden muss, wird
beim Einfügen entsprechend nur auf lokale Eindeutigkeit
geprüft. Somit bleibt es unter der Aufsicht des Entwerfers,
ob die Schlüssel global oder lokal eindeutig sind.
4.2.9.6 Einschränkungen
Damit die Semantik der Komponentenbeziehung nicht
verletzt wird, müssen für dessen Verwendung einige
einschränkende Regeln beachtet werden:
• Die Klasse B kann nur in genau einer Klasse enthalten
sein.
• Alle Klassen müssen entweder als Komponenten von
anderen Klassen definiert werden oder durch Objekte
instantiiert sein.
4.2.9.7 Beispiel FIS
Die Klasse „Firma“ ist bereits durch ihre
Instantiierungsbeziehung vom Objekt „Macrohard“ aus
persistent gemacht worden. Damit sich die Persistenz auch
auf die anderen Instanzen der Klassen „Entwickler“,
„Manager“ und „Büro“ auswirkt, müssen sie als
Komponenten des Einstiegspunktes definiert werden. Die
Instanzen der Klasse „Büroliste“ dürfen aber nicht
persistent werden, weshalb keine Komponentenbeziehung
zu ihr aufgebaut werden darf.
80 • DEIMOS
Diplomarbeit
Die Entwickler, die Manager und die Büros sollen als
Bestandteil der Firma aufgefasst werden. Damit lassen sich
die Komponentenbeziehungen formulieren.
Dies sei im Detail am Beispiel des Entwicklers ausgeführt.
Die Firma beschäftigt Entwickler, also muss zwischen der
Klasse „Firma“ als Besitzer und der Klasse „Entwickler“
als Teilnehmer eine Komponentenbeziehung existieren. In
der Firma können beliebig viele Entwickler arbeiten,
insbesondere auch keiner, was durch die Kardinalität 0+ auf
der Seite des Entwicklers verdeutlicht wird. Durch die
Auffassung des Entwicklers als Komponente der Firma
zieht die Erweiterung der Eigenschaften der Klasse „Firma“
um die Fähigkeit Entwickler anzustellen
(Beziehungsaufbau) und zu entlassen (Beziehungsabbau)
nach sich. Zudem ist die Firma - oder genauer das Objekt
„Macrohard“ - als einzige in der Lage, die Menge aller
angestellten Entwickler zu kennen.
Auf analoge Art werden die entsprechenden
Komponentenbeziehungen zwischen der Klasse „Firma“
und den Klassen „Manager“ und „Büro“ eingezeichnet.
Firma
<Name>
Adresse
Macrohard
0+
Büro
<Nummer>
0+
0+
Entwickler
Manager
A
BüroListe
Show()
Print()
Mitarbeiter
<Name>
Adresse
Abbildung 4-6: Schemadiagramm mit Komponentenbeziehungen
Die Instanzen der Klassen „Entwickler“ und „Manager“
werden gleichsam als Komponenten des Objektes
„Macrohard“ aufgefasst. Dabei handelt es sich um eine
gemeinsame Eigenschaft dieser beiden Klassen. Ohne
Änderung der Semantik hätte deshalb die
Komponentenbeziehung auch zu der Klasse „Mitarbeiter“
definiert werden können.
4.2.10 Inverse Beziehung
Während mit den Komponentenbeziehungen
Existenzabhängigkeiten modelliert werden, muss dem Entwerfer
ein Konstrukt für die Formulierung von allgemeinen Beziehungen
zur Verfügung gestellt werden. Trotzdem soll die bereits erreichte
Sicherheit bei der Erzeugung und Löschung von Datenobjekten
nicht aufgeweicht werden, weshalb in der Notation keine
einseitigen Beziehungen zugelassen sind.
Diplomarbeit
DEIMOS • 81
ungewollte
Persistenz durch
einseitige
Beziehungen
KA
KB
Durch die Verwendung von einseitigen Beziehungen könnten nämlich
Objekte in der Datenbasis durch andere referenziert sein, ohne dass sie
etwas davon wissen. Bei der Löschung eines derartigen Objektes zum
Beispiel wäre der Entwickler gefordert, auf umständliche Weise die nun
nicht mehr gültige Referenz zu löschen. Dies liesse den
Implementationsaufwand unverhältnismässig stark steigen und wäre
darüber hinaus sehr fehleranfällig. Zudem werden Datenbanksysteme,
welchen die Philosophie der „Persistenz durch Erreichbarkeit“ zu Grunde
liegt, durch „hängende“ Beziehungen referenzierter Objekte nicht aus
ihrer Datenbasis entfernt, was leicht zu gefährlichen Inkonsistenzen
führen könnte.
4.2.10.1 Konstrukt
Bei Booch sind innerhalb der Klassendiagramme keine echten inversen
Beziehungen vorgesehen. Sind Kardinalitäten auf beiden Seiten einer
„has-a by reference“ Beziehung angegeben, obliegt die Interpretation
dieses Sachverhalts dem Ermessensspielraum des Lesers.
Aus diesem Grund wird ein neues Konstrukt für die
Modellierung von inversen Beziehung eingeführt. Dieses
trägt an beiden Enden ein nicht ausgefülltes Quadrat. Auf
beiden Seiten müssen entsprechend Kardinalitäten
angegeben werden.
4.2.10.2 Verwendung
A
KA
KB
B
Diese inverse Beziehung kann zwischen zwei beliebigen
Klassen gleichen Klassentyps wirken. Heterogene
Verbindungen sind nur dann zulässig, wenn es sich bei der
einen Klasse um eine abstrakte handelt. Sie ist symmetrisch
und unterscheidet somit semantisch nicht zwischen den
beiden teilnehmenden Klassen. Insbesondere kann sie von
beiden beteiligten Klassen gleichermassen auf- und
abgebaut werden.
Die Kardinalitäten können beliebig gewählt werden. Dabei
unterliegen die beiden Kardinalitäten KA und KB keinen
Abhängigkeiten oder Einschränkungen.
Selbstreferenzen
82 • DEIMOS
Die inverse Beziehung dient der Modellierung von allgemeinen
Relationen und wird daher nur dann verwendet, wenn sich semantische
Beziehungen nicht mit den anderen Verbindungstypen darstellen lassen.
Mit diesem Konstrukt können vor allem auch Selbstreferenzen dargestellt
werden.
4.2.10.3 Einschränkungen
Damit die Semantik der inversen Beziehung nicht verletzt
wird, müssen für deren Verwendung einige einschränkende
Regeln beachtet werden:
Diplomarbeit
• Eine Klasse kann an beliebig vielen solchen
Beziehungen teilnehmen.
• Inverse Beziehungen können nicht zwischen Datenbankund Hilfsklassen wirken.
4.2.10.4 Beispiel FIS
Gemäss Anforderungskatalog wird einem Mitarbeiter
jeweils ein Büro zugeordnet. Aus diesem Grund muss
zwischen den beiden Klassen eine Beziehung existieren.
Ein Mitarbeiter darf aber nicht als Komponente eines Büros
aufgefasst werden, da sonst ein Mitarbeiter als Bestandteil
zweier verschiedener Objekte auftreten würde. Also muss
zwischen diesen beiden Klassen eine inverse Beziehung
eingerichtet werden. Die Beziehung unterliegt der
Bedingung, dass ein Mitarbeiter immer ein Büro haben
muss und dass ein Büro von beliebig vielen Mitarbeitern
genutzt werden kann, insbesondere auch von keinem.
Daraus lassen sich die Kardinalitäten N* auf der Seite des
Mitarbeiters und 1 auf der gegenüberliegenden Seite der
Beziehung ableiten.
Analog muss eine Beziehung zwischen dem Manager und
dem Entwickler erstellt werden, da sie, wie aus der Liste
der Anforderungen zu entnehmen ist, zusammen und in
Teams organisiert an einem Projekt arbeiten. Die
Teambeziehung ist dabei genau dann konsistent, wenn
genau ein Manager die Koordinationsrolle übernimmt und
mindestens ein Entwickler mit der Bearbeitung beschäftigt
ist.
Firma
<Name>
Adresse
Macrohard
0+
0+
0+
1+
Büro
<Nummer>
1
Entwickler
Manager
1
BüroListe
Show()
Print()
A
0+
Mitarbeiter
<Name>
Adresse
Abbildung 4-7: Schemadiagramm mit inversen Beziehungen
4.2.11 Beobachtungsbeziehung
Verbindung von
transienten und
persistenten
Objekten
Diplomarbeit
Komponentenbeziehungen und inverse Beziehungen verbinden die
persistenten bzw. transienten Objekte untereinander. Naheliegenderweise
muss in der Notation auch ein Konstrukt angeboten werden, welches die
Lücke zwischen diesen beiden Welten zu überbrücken weiss. Derartige
Relationen dürfen sich aber nicht nachteilig auf die Sicherheit bezüglich
der Persistenzfortpflanzung auswirken, weshalb sie nur von transienten
Objekten aus auf Instanzen der Datenbankklasse zeigen dürfen.
DEIMOS • 83
Der Entwerfer muss sich einzig vergegenwärtigen, dass die
Propagation die Referenzsicherheit entlang den
Beobachtungsbeziehungen nicht gewährleisten kann. Die
Algorithmen müssen dieser Problematik also durch die
Implementation von speziellen Behandlungen oder Formulierung
von expliziten Konsistenzbedingungen Herr werden.
4.2.11.1 Konstrukt
K
Der in Booch’s Methode eingeführte Beziehungenstyp „has-a by
reference“ beschreibt eine einseitige beobachtende Relation von einer
Klasse zu einer anderen. Diese Idee soll für die Beobachtungsbeziehung
übernommen werden. Auch die von ihm vorgeschlagene „using“Beziehung hat gewisse Aspekte der neuen Beziehung gemein. Das
Symbol wird daher als Kombination dieser beiden Verbinder gezeichnet
und in die Notation aufgenommen.
4.2.11.2 Verwendung
A
KA
B
Diese Beobachtungsbeziehung verbindet die Hilfsklassen
mit den Datenbankklassen. Der Besitzer der Beziehung
muss die Hilfsklasse sein. Entsprechend muss der
Teilnehmer eine Datenbankklasse sein. Das Besitzen der
Beziehung wird durch einen nicht ausgefüllten Kreis
verdeutlicht, die Teilnahme entsprechend mit einem nicht
ausgefüllten Quadrat.
Mit diesem Konstrukt wird einer Hilfsklasse die Fähigkeit
gegeben, eine Datenbankklasse zu „beobachten“. Somit
kann sie als eine Art von Sicht innerhalb des Systems
arbeiten. Durch die Angabe einer Kardinalität auf der Seite
des Teilnehmers kann die Anzahl der zu beobachtenden
Instanzen definiert werden. Diese Kardinalität kann
beliebig gewählt werden.
Keine Fortplanzung
der Persistenz
entlang der
Beobachtungsbeziehungen
Die Persistenz kann sich für Datenbanksysteme, die sich dem Grundsatz
der Persistenz durch Erreichbarkeit verschrieben haben, entlang jeder
Beziehung fortpflanzen. Dieser Effekt darf sich aber auf keinen Fall auf
die Hilfsklassen auswirken, weshalb immer die Hilfsklasse der Besitzer
einer derartigen Beziehung sein muss. Daraus folgt im weiteren, dass die
Beziehung einseitig sein muss und nicht invers erweitert werden kann.
Sicherheit der
Referenz
Da die Beobachtungsbeziehung einseitig ist, kann bei einer Veränderung
der beobachteten Instanzenmenge die Sicherheit der Referenz nicht
gewährleistet werden. Wird beispielsweise ein beobachtetes Objekt
gelöscht, hat dieses keine Möglichkeit, dem Beobachter seine Löschung
mitzuteilen. Analog kann bei der Erzeugung einer neuen Instanz nicht
ohne weiteres geprüft werden, ob das neue Objekt das
Beobachtungskriterium erfüllt und deshalb in die Referenzmenge der
Hilfsklasseninstanz aufgenommen werden müsste.
84 • DEIMOS
Diplomarbeit
Validierung der
Referenzmenge
Aus diesem Grund muss bei jeder Verwendung der Referenzmenge
gewährleistet sein, dass sich die beobachtete Menge nicht verändert hat.
Da dies aber mit einigem, gefährlich komplexen Programmieraufwand
verbunden ist, kann auch die Strategie gewählt werden, welche die
Menge vor jedem Verwenden validiert oder neu aufbaut. Das Konstrukt
wird darum Beobachtungsbeziehung genannt.
4.2.11.3 Einschränkungen
Damit die Semantik der Beobachtungsbeziehung nicht
verletzt wird, müssen für dessen Verwendung einige
einschränkende Regeln beachtet werden:
• Die Beziehung muss von einer Hilfsklasse aus zu einer
Klasse als Teilnehmer führen. Sie kann nicht zwischen
gleichartigen Klassen wirken und auch nicht von einer
Klasse aus auf sich selber.
• Eine Datenbankklasse kann an beliebig vielen solchen
Beziehungen teilnehmen.
• Eine Hilfsklasse kann beliebig viele solcher
Beziehungen besitzen.
4.2.11.4 Beispiel FIS
Nachdem die Datenbankklassen allesamt persistent
gemacht worden sind, darf sich dieser Effekt nicht auf die
Instanzen der Klasse „Büroliste“ ausweiten. Aus diesem
Grund dürfen Bürolistenobjekte nicht über eine inverse
Beziehung mit den zu beobachtenden Instanzen der Klasse
„Büro“ verbunden werden. Auch die Verwendung der
Komponentenbeziehung ist an dieser Stelle nicht zulässig,
da die überwachte Klasse bereits als Komponente einer
anderen Klasse deklariert worden ist. Vielmehr ist hier die
Beobachtungsbeziehung zu verwenden.
Die Büroliste beobachtet eine beliebige Anzahl von Büros,
weshalb auf der Seite der Büroklasse die Kardinalität 0+
hizuzufügen ist. Die Angabe einer Kardinalität auf der
anderen Seite ist sinnlos, da diese Beziehung immer
einseitig ist.
Firma
<Name>
Adresse
Macrohard
0+
0+
0+
0+
1+
Büro
<Nummer>
1
Entwickler
Manager
1
BüroListe
Show()
Print()
A
0+
Mitarbeiter
<Name>
Adresse
Abbildung 4-8: Schemadiagramm mit Beobachtungsbeziehung
4.2.12 Objektevolution
Diplomarbeit
DEIMOS • 85
Objektevolution als
Lösch- und
Erzeugungsprozess
Typischerweise werden in Datenbanken Informationen gespeichert, die
während einer sehr langen Lebensdauer zugreifbar sind. Ebenso typisch
treten während dieser Lebenszeit Ereignisse ein, die bei einem
betrachteten Objekt semantisch eine Evolution initiieren.
Objektorientierte Datenbanksysteme sind aber im Allgemeinen nicht auf
derartige Mutationsprozesse vorbereitet, weshalb dieses unverzichtbare
Verhalten durch einen Lösch- und Erzeugungsprozess nachgebildet
werden muss.
Erhaltung der
Daten und
Beziehungen
Die Evolution unterscheidet sich dabei von einer gemeinen Löschung,
bzw. Erzeugung dadurch, dass gewisse bereits gespeicherte Daten
erhalten bleiben sollen. Zudem sollen etwaige Beziehungen, die
semantisch auch nach der Mutation noch Sinn ergeben, diesen Übergang
sicher überleben.
Mit der Objektevolution wird ein dynamisches Verhalten von Objekten
beschrieben. Das Ereignis, welches eine derartige Mutation provoziert,
die einschränkenden Regeln, usw. müssen dementsprechend in den
dynamischen Diagrammen wie z.B. Zustandsübergangsdiagramme
spezifiziert werden. Die Fähigkeit zur Objektevolution hingegen ist eine
statische Eigenschaft der Datenbankklassen und hat aus diesem Grund
hier durchaus seine Berechtigung.
4.2.12.1 Konstrukt
statische
Eigenschaft versus
dynamisches
Verhalten
e()
In der Methode von Booch ist das Wechseln der Klassenzugehörigkeit
von Instanzen nicht spezifizierbar. Also muss ein neues Konstrukt
eingeführt werden, um den möglichen Wechsel einer Instanz von einer
Klasse in eine andere zu beschreiben.
Das Konstrukt wird als Pfeil dargestellt, der auf der Seite
der Ausgangsklasse eine Raute als Symbol trägt und mit
seiner Spitze auf die Zielklasse zeigt. Die Evolution muss
einen Namen tragen.
Mit diesem Konstrukt wird die Eigenschaft der Instanzen
einer Klasse modelliert, ihre Klassenzugehörigkeit zu
ändern. Zudem wird angegeben, zu welcher Klasse die
Instanz mutieren kann, wer diesen Prozess kontrolliert und
welche Daten bei der Mutation erhalten bleiben.
4.2.12.2 Die Verwendung
[K C ]
KA
A
C
e()
e()
[K C ]
KB
B
D
86 • DEIMOS
Diplomarbeit
Die Objektevolution definiert die Eigenschaft der Instanzen
der Klasse A, ihre Klassenzugehörigkeit nach B wechseln
zu können. Die Beziehung ist gerichtet, d.h. durch einen
Pfeil von A nach B wird lediglich die Fähigkeit
ausgedrückt, von A nach B migrieren zu können. Soll dies
auch in der anderen Richtung möglich sein, muss dies
durch einen zweiten Pfeil verdeutlicht werden.
Besitzer der
Objektevolution
Ursprungsklasse
und Zielklasse
Basisklasse
Diplomarbeit
Die Objektevolution kann zwischen zwei beliebigen Komponenten
(unterschiedlicher Klassen) eines Objektes wirken. Dieses wird der
Besitzer der Objektevolution genannt.
Der Evolutionspfeil muss einen Namen tragen. Die
Evolutionsfunktion wird innerhalb der Besitzerklasse als
Methode implementiert und trägt den Namen des
Evolutionspfeils. Aus diesem Grund muss der Name der
Evolution innerhalb eines Besitzers eindeutig sein.
Die Klasse, deren Instanzen evolutionsfähig sind, wird
„Ursprungsklasse“ genannt, während die Klasse, welche Instanzen durch
Objektevolution hinzugewinnen kann, den Namen „Zielklasse“ trägt.
Zudem heisse die Superklasse der Ursprungs- und Zielklasse im
Folgenden Basisklasse.
Objektevolution macht vor allem dann Sinn, wenn gewisse Daten der
Ursprungsklasse in die Zielklasse übernommen werden können. Sind die
beiden Klassen Derivate derselben Klasse oder ist die eine Klasse eine
Spezialisierung, bzw. Generalisierung der anderen Klasse, so sollen
natürlich die Daten der gemeinsamen Basis erhalten bleiben. Sämtliche
Eigenschaften, die lediglich die Ursprungsklasse aufweist, werden
verworfen, während die Eigenschaften, welche nur die Zielklasse besitzt,
neu erstellt werden.
4.2.12.3 Semantik
Die Migration einer Instanz Ai zu einer Instanz Bj bedeutet,
dass zuerst ein neues Objekt Bj erzeugt wird, die
gemeinsamen Daten von der alten auf die neue Instanz
kopiert werden und zuletzt die Instanz Ai gelöscht wird.
Aus dieser Auffassung von Objektevolution lässt sich
ableiten, dass diese Migration nur vom Besitzer der beiden
Instanzen Ai und Bj, nennen wir ihn Ck durchgeführt
werden kann, da dies das einzige Objekt ist, welches die
Fähigkeit des Erzeugens von Bj und die des Löschens von
Ai auf sich vereinen kann. Daraus folgt, dass die
Durchführung der Migration von Ck aus vorgenommen
werden muss, somit im Allgemeinen eine Eigenschaft der
Klasse C wird und entsprechend als Klassenmethode
implementiert wird. Zudem lässt sich daraus ableiten, dass
die Objektevolution die Komponentenbeziehung nicht
verändert, d.h. das Objekt Bj kann nicht zu einer
Komponente von Cl (mit l≠k) mutieren.
DEIMOS • 87
Sollen bei diesem Verwandlungsprozess Daten aus der zu löschenden
Instanz auf die neu generierte Instanz übertragen werden, stellt sich die
Frage nach der Abbildung der Daten vom Original- auf das Zielobjekt.
Sind die beiden Objekte Instanzen von Klassen, die beide ein Derivat
(beliebiger Tiefe) einer Vaterklasse D sind, so lässt sich diese
Abbildungsvorschrift intuitiv definieren als die Übernahme der vom
Vater her stammenden gemeinsamen Attribute und der Verwerfung, bzw.
Neukreation der differierenden Eigenschaften. Ist diese
Klasseneigenschaft jedoch nicht gegeben, so muss sich der Entwickler
selber um die passende Abbildung kümmern. Sollen beim Wechsel keine
Daten übernommen werden, so stellt sich berechtigterweise die Frage
nach dem Sinn der Objektevolution in diesem Kontext.
Die Funktionalität der Datenübernahme kann sowohl als
Eigenschaft der Klasse A als auch der Klassen B, C oder D
betrachtet werden und wird gleichfalls als Klassenmethode
implementiert.
4.2.12.4 Einschränkungen
Damit die Semantik der Objektevolution nicht verletzt
wird, müssen für deren Verwendung einige einschränkende
Regeln beachtet werden:
• Eine Klasse kann an beliebig vielen solchen
Beziehungen teilnehmen. Zwischen der Klassen A und B
kann aber höchstens eine Beziehung mit A als Ursprungsund B als Zielklasse definiert werden.
• Objektevolutionen können nur zwischen verschiedenen
Komponenten einer Besitzerklasse gezeichnet werden.
Daraus folgt, dass keine Evolutionsbeziehungen zwischen
Hilfs- und Datenbankklassen unterhalten werden können.
• Objektevolution kann nicht zwischen zwei Objekten
gleicher Klasse wirken.
• Es empfiehlt sich, die Objektevolution vor allem
zwischen Ursprungs- und Zielklassen wirken zu lassen, die
eine gemeinsame Basisklasse besitzen. Dies ist erfüllt,
wenn die beiden Klassen von derselben Klasse abgeleitet
sind oder die eine Klasse eine Spezialisierung der anderen
Klasse ist.
4.2.12.5 Beispiel FIS
Nur im Fall der Beförderung wird von den Anforderungen
verlangt, dass ein Objekt seine Klassenzugehörigkeit
ändert. Instanzen der Klasse „Entwickler“ sollen die
Eigenschaften erhalten, zu Instanzen der Klasse „Manager“
migrieren zu können.
Als Voraussetzungen zur Verwendung der Objektevolution
wird verlangt, dass die Ursprungs- und die Zielklasse
Komponenten derselben Klasse sind. Dies ist dank der
geeigneten Wahl der Komponentenbeziehungen erfüllt. Im
Weiteren ist durch die gemeinsame Basisklasse
„Mitarbeiter“ eine Erhaltung der Mitarbeiterdaten,
Abbildungsvorschrif
t
88 • DEIMOS
Diplomarbeit
insbesondere aber auch die Bürozuordnung, beim Übergang
gewährleistet.
Damit lässt sich die Evolutionsbeziehung vom Entwickler
zum Manager einrichten. Als Name der Beziehung wird
„befördern“ gewählt, was für die Basisklasse bedeutet, dass
sie eine neue Methode desselben Namens erhalten muss.
Firma
<Name>
Adresse
bef()
Macrohard
0+
0+
0+
0+
1+
Büro
<Nummer>
1
Entwickler
bef()
1
BüroListe
Show()
Print()
Manager
A
0+
Mitarbeiter
<Name>
Adresse
Abbildung 4-9: Schemadiagramm mit Objektevolution
4.2.13 Notizen
Notes
Analog zu Booch sind erweiterte Informationen, die zum Verständnis des
Schemaentwurfes beitragen in Notizfelder formulierbar. Dieses
Konstrukt wird direkt von Booch übernommen.
4.2.13.1 Notizbezug
Durch die Verbindung eines Kommentarelementes mit einem beliebigen
anderen Element des Diagramms mittels einer gestrichelten Linie kann
der Bezug auf einen entworfenen Sachverhalt hergestellt werden.
Notizen haben semantisch keine Bedeutung, sie tragen
lediglich zum besseren Verständnis des Diagramms bei.
Aus diesem Grund sind für dessen Verwendung keine
Einschränkungen zu berücksichtigen.
4.2.13.2 Beispiel FIS
Das Schemadiagramm für das Beispiel FIS kann nun an
dieser Stelle durch Notizen bereichert werden.
4.2.14 Zusammenfassung Beispiel FIS
Das Schemadiagramm wurde in den vorherigen Abschnitten
Schritt für Schritt aufgebaut. Nach diesem Raster vorzugehen, ist
empfehlenswert aber nicht zwingend. Die Entwurfsabfolge kann
auch variieren, da eventuell nach einer „top-down“ oder „bottomup“ Strategie vorgegangen wird und zu einem gewissen Zeitpunkt
nicht alle Abstraktionsebenen vollumfänglich überschaut werden
können. Häufig werden erst während des Designs zusätzliche
Informationsbedürfnisse erkannt.
Diplomarbeit
DEIMOS • 89
Zudem unterliegt der Entwurf immer einer gewissen Willkür. Für
die Modellierung könnten auch andere Klassen und Beziehungen
identifiziert worden sein, die derselben Semantik genügen.
Gemäss dem Anforderungskatalog fehlen den Klassen im
Diagramm noch einige Eigenschaften und Fähigkeiten. Diese sind,
falls sie nicht durch die impliziten Klassenmethoden abgedeckt
sind, der Klassendefinition hinzuzufügen. Implizite Methoden sind
Fähigkeiten, die eine Klasse erhält, indem für sie Abhängigkeiten
zu anderen Klassen eingerichtet worden sind.
Beispielsweise soll die Klasse „Firma“ Entwickler anstellen und
entlassen können. Diese Fähigkeiten können im Sinne des Schemas
als Auf- bzw. Abbau der Komponentenbeziehung zu der Klasse
„Entwickler“ interpretiert werden. Derartige Methoden gelangen
implizit in die Klasse „Firma“, weshalb sie nicht durch die
Definition von dedizierten Funktionen beigefügt werden müssen.
Genauso verhält es sich beispielsweise für die Bürozuordnung der
Mitarbeiter, welche vom Auftraggeber als Anforderung formuliert
worden ist. Sie kann analog als Auf- und Abbaufunktion der
Beziehung zwischen den Klassen „Büro“ und „Mitarbeiter“
betrachtet werden und ist somit bereits implizit vorhanden.
Demnach fehlen zu der Erfüllung der geforderten Funktionalität
einzig die lesenden Zugriffsfunktionen für den Aufbau der
Mitarbeiterlisten und Projektteammitgliederlisten. Es obliegt nun
dem Entwerfer zu entscheiden, an welcher Stelle diese Funktionen
eingebaut werden sollen. Auf der einen Seite können sie als
Klassenmethoden implementiert werden, auf er anderen Seite
können sie auch als Programme oder Funktionen ihren Platz auf
der Seite der Applikationen erhalten. Da es sich um rein lesende
Zugriffe handelt, müssen sie nicht in Transaktionsblöcke verpackt
und somit auch nicht zwingend aus dem Methodenteil
herausgehalten werden. Also bleibt als Beurteilungskriterium nur
noch der Aspekt der Wiederverwendbarkeit der Klassen.
4.3 Das Transaktionsdiagramm
In der Methode von Booch wird das Moduldiagramm für den physischen
Entwurf der Module verwendet. Betrachtet werden die Abhängigkeiten der
verschiedenen Module auf der Ebene der Definitionen und der
Implementationen. Während bei den Klassendiagrammen die statische
Struktur der Klassen und deren Beziehungen dargestellt wurden, werden
diese Klassen nun verschiedenen Implementationsmodulen zugeordnet.
Haben zwei Klassen im Klassendiagramm Abgängigkeiten, müssen sie
entweder in demselben Modul zu liegen kommen oder in
unterschiedlichen Modulen, welche ihrerseits durch eine
Modulabhängigkeit verbunden sein müssen.
90 • DEIMOS
Diplomarbeit
Im Zentrum der Betrachtung steht bei dieser Modellierung vor allem das
fehlerfreie Terminieren des Compilers. Unterhalten zwei Klassen eine
Beziehung und liegen sie nicht im selben Modul, muss - für C++ z.B.
über "include“-Direktiven - der einen Klasse die Definition der anderen
zugänglich gemacht werden. Diese Abhängigkeiten werden durch
Verknüpfungen der entsprechenden Module modelliert.
Compiler
Nicht im Betrachtungsfeld befindet sich die Implementation der
Schnittstellen zwischen den verschiedenen Modulen, es wird vielmehr
angenommen, dass diese aus dem Klassendiagramm abgelesen werden
können.
Für Datenbankapplikationen aber sind die Anwendungen selber nicht als
Klassen implementiert und bilden somit keinen Bestandteil der
eigentlichen Datenbasis, sind aber dennoch im Datenbankschema
enthalten. Zudem müssen Transaktionen als zentraler Bestandteil von
Datenbankprogrammen entworfen werden können.
Implementation der
Schnittstellen
Grobentwurf
Aus diesem Grund wird das Moduldiagramm von Booch von der Idee her
übernommen und vor allem an seiner Stelle des Entwurfprozesses
belassen. Die Konstrukte aber dienen nur mangelhaft den erweiterten
Anforderungen und können höchstens in einer frühen Phase des
Grobentwurfes, namentlich zur Identifikation der Subsysteme, verwendet
werden.
Moduldiagramm Transaktionsdiagra
mm
Zudem wird der zentralen Aufgabe dieses Entwurfschrittes, die
Definition des Transaktionskonzeptes durch Umbenennung in
„Transaktionsdiagramm“ Rechnung getragen.
4.3.1 Subsystemdiagramm
Im Subsystemdiagramm werden während des Grobentwurfes die
verschiedenen Subsysteme einer Applikation identifiziert. In
Subsystemen werden logisch zusammengehörige Funktionalitäten unter
der Berücksichtigung der „divide-and-conquer“-Strategie verpackt.
Ein derartiges Diagramm besitzt eine Applikationsikone als
Wurzelkonstrukt, welches die Kontrolle über die verschiedenen
Subsysteme ausübt. Existieren weitere Beziehungen zwischen den
Subsystemen, so wird damit ausgedrückt, dass mindestens ein
Element des einen Subsystem mindestens ein Element des anderen
Subsystem aufruft.
„divide-andconquer“ durch
Subsysteme
4.3.2 Transaktionsdiagramm
Die im vorgelagerten Grobentwurf gefundenen Subsysteme werden
in den folgenden Detaillierungsschritten zu
Transaktionsdiagrammen expandiert.
Applikationen,
Programme,
Funktionen und
Transaktionen
Das Transaktionsdiagramm besteht aus vier aufeinandergeschichteten
Ebenen, welche auch als Abstraktionsstufen oder Detaillierungsgrade
angesehen werden können. Die Ebenen beinhalten von oben nach unten
aufgezählt die Applikationen, die Programme, die Funktionen und die
Transaktionen.
4.3.3 Konstrukte
Diplomarbeit
DEIMOS • 91
Die nachfolgend beschriebenen Konstrukte Applikation und
Subsystem werden für das Subsystemdiagramm verwendet,
während die restlichen Ikonen zum Entwurf der Transaktionen
innerhalb des Transaktionsdiagrammes zur Anwendung gelangen.
4.3.3.1 Applikationen
ApplicationName
Die Applikationen bilden die oberste Ebene des Moduldiagramms. Eine
Applikation ist eine Sammlung von Programmen und bildet somit die
Wurzel des Aufrufbaumes. Eine Applikation kann nur Programme
aufrufen und entsprechend auch nur mit diesen Ikonen verknüpft sein.
4.3.3.2 Subsysteme
SubSystem
ProgrammName
Instructions
92 • DEIMOS
In Subsysteme werden logisch zusammengehörige Programme,
Funktionen und Transaktionen zusammengefasst. Ein Subsystem kann
auch als Rahmen einer Untermenge von Subsystemen stehen. Ein
Subsystem muss entweder weitere Subsysteme oder mindestens ein
Programm enthalten, damit die Aufrufverbindung semantisch sinnvoll ist.
Somit können von Applikationen aus auch Subsysteme aufgerufen
werden.
Das Subsystemkonstrukt darf nur im Subsystemdiagramm,
welches auf diese Weise die Rolle eines Übersichts- oder
Kontextdiagramms einnimmt, verwendet werden.
4.3.3.3 Programme
Programme sind Sammlungen von Instruktionen. Das Symbol definiert
einen eindeutigen Namen im Titel und einer Sequenz von Instruktionen
im Rumpf. Instruktionen können in Form von Anweisungen und
Steuerblocks auftreten. Anweisungen sind Programmzeilen, die eine
Deklarationen, eine Zuweisungen oder einen Aufruf enthalten.
Steuerblocks kontrollieren den Programmausführungsfluss und sind
entweder Selektion, Iteration oder Wiederholschleifen.
Mit diesen Konstrukten lassen sich Programmabläufe
pseudocodeartig entwerfen. Insbesondere können die
Aufrufe der Funktionen, der Transaktionen und der nur
lesenden Klassenmethoden dargestellt werden. Aufrufe von
Methoden, die schreibend auf die Objekte zugreifen, sind in
Transaktionen zu schachteln und von dieser Ebene aus
nicht aufrufbar. Auch dürfen keine anderen Programme
aufgerufen werden.
Klassenmethoden werden in der Form
ClassName::MethodName([Param(,Param)*])
aufgeschreiben, wobei sowohl die Klasse als auch deren
Methode im Schemadiagramm definiert worden sein muss.
Programme gehören zu genau einer Applikation. Es ist
zwar durchaus möglich, ein Programm zeichnerisch in zwei
verschiedenen Applikationen unterzubringen, tatsächlich
Diplomarbeit
werden aber physisch zwei verschiedene Kopien ein und
desselben Programmkörpers im Schema abgelegt.
4.3.3.4 Funktionen
Function(P:T):V
Instructions
Analog zu den Programmikonen tragen die Funktionsdarstellungen den
eindeutigen Namen der Funktion im Titelteil und die Instruktionen im
Körperteil. Während es bei Programmen weder Übergabeparameter noch
einen Rückgabewert gibt, sind diese bei der Funktiondefinition im
Titelteil zu spezifizieren. P stehe dabei als Name des Parameters von Typ
T und V definiere den Typ des Rückgabewertes.
Die pseudocodeartig beschriebenen Funktionsabläufe
können Aufrufe von Transaktionen oder anderen
Funktionen enthalten. Klassenmethoden, die schreibend auf
die Objekte zugreifen, und Programmaufrufe sind nicht
erlaubt.
4.3.3.5 Transaktionen
Transaktionen sollen die schreibenden Zugriffe auf die Datenbasis
kapseln. Der Ausführungszeitraum einer Transaktion ist das einzige
Zeitfenster, in welchem die Konsistenzbedingungen verletzt sein dürfen.
Aus diesem Grund ist in jedem Fall darauf zu achten, nach der
Ausführung der Schreibzugriffe die Konsistenz zu prüfen. Sind die
formulierten Bedingungen auf irgend einer Ebene nicht erfüllt, müssen
die Manipulationen durch ein Abort (Rollback) der Transaktion
rückgängig gemacht werden.
Transaktionen bilden die atomaren Ausführungsschritte,
welche nicht unterbrochen werden dürfen. Nicht zuletzt aus
diesem Grund müssen sie so kurz wie möglich gehalten
werden. Die physischen Gegebenheiten wie
Mehrbenutzerbetrieb, welche später im physischen Entwurf
genauer spezifiziert werden, sollen dabei nicht ausser Acht
gelassen werden.
TransactionName
Instructions
Transaktionen logisch
zusammenhängende
Arbeitsschritte
geschachtelte
Transaktionen
Diplomarbeit
Eine Transaktion sollte also möglichst aus den Methodenaufrufen, die im
Schemadiagramm als schreibend deklariert worden sind, und den
Konsistenzprüfungen bestehen. Häufig wird aber vielmehr ein logisch
zusammenhängender Arbeitsschritt, welcher aus einem lesenden und
einem schreibenden Teil besteht, in eine Transaktion gefasst.
Transaktionen können von Programmen und Funktionen aufgerufen
werden, dürfen aber ihrerseits nicht mehr in Untertransaktionenen
verzweigen, solange das darunterliegende Datenbanksystem keine
geschachtelten Transaktionen unterstützt.
Zudem ist die Zusammenfassung von verschiedenen
Schreibzugriffen in einer Transaktion nur dann zu
empfehlen, wenn zwischen den einzelnen Manipulationen
die Konsistenz nicht gewährleistet werden kann.
4.3.3.6 Aufrufe
DEIMOS • 93
Durch die Aufrufpfeile werden die verschiedenen Ikonen miteinander
verbunden, wobei der Pfeil beim Aufrufenden beginnt und beim
Aufgerufenen in einer Spitze endet. Für die Verwendung sind die oben
ausgeführten Einschränkungen zu beachten.
Die von einer Ikone auslaufenden Pfeile verstehen sich als
synchrone Aufrufe und können, falls die Struktur aus dem
Programm-, bzw. Funktionsbeschrieb nicht hervorgeht,
durch Numerierungen sequenziert werden.
4.3.3.7 Beispiel FIS
Sämtliche Funktionalität des Firmeninformationssystems
soll in eine einzige Applikation gepackt werden. Die
verschiedenen Teile der Anwendung sollen sich um die
Belange der Mitarbeiterverwaltung, der Büroverwaltung
und der Projektverwaltung kümmern. Ein zusätzliches
Modul soll Bürolisten, Mitarbeiterlisten und
Projektteamlisten erstellen, anzeigen und drucken können.
Die Grobstruktur lässt sich wie folgt in einem
Subsystemdiagramm veranschaulichen.
Listen
auswertung
FIS
Mitarbeiter
Verwaltung
Büro
Verwaltung
Projekt
Verwaltung
Abbildung 4-10: Subsystemdiagramm für die Anwendung FIS
Die identifizierten Subsysteme lassen sich nun in einer
weiteren Abstraktionsstufe expandieren, um die
entsprechenden Transaktionsdiagramme zu zeichnen.
Dies sei am Subsystem „Mitarbeiterverwaltung“ aufgezeigt.
Die Mitarbeiterverwaltung muss Entwickler und Manager
anstellen und entlassen und Entwickler zu Manager
befördern können.
94 • DEIMOS
Diplomarbeit
HireDeveloper
HireDev(o:Office)
2
1
SelectOffice(): Office
FIS::AddDev()
Dev::TakeOffice(o)
ShowOfficeList()
FireDeveloper
1
2
SelectDev():Dev
1
ShowDevList()
FireDev(d:Dev)
FIS::RemDev(d)
MakeManager
1
2
MakeMan(d:Dev)
FIS::Bef(d)
HireManager
HireMan(o:Office)
2
SelectMan():Man
FireManager
1
FIS::AddMan()
Man::TakeOffice(o)
ShowManList()
2
FireMan(m:Man)
FIS::RemMan(m)
Abbildung 4-11: Transaktionsdiagramm für das Subsystem „Mitarbeiterverwaltung“
Die fünf Hauptfunktionen der Mitarbeiterverwaltung sind je
in einem Programm implementiert. Die Programme sind
nicht näher spezifiziert, da die Reihenfolge der Aufrufe zu
den Funktionen und Transaktionen mit Abfolgenummern
versehen sind.
Die Funktion SelectDev() ruft eine Funktion
ShowDevList() auf. Bei dieser Funktion handelt es sich
nicht um eine Klassenmethode, sondern um eine Funktion,
die sich in einem anderen Subsystem befindet. Wären die
beiden Funktionen im selben Subsystem enthalten, so
würde anstelle des Funktionsaufrufes eine Aufrufbeziehung
zwischen den beiden bestehen.
4.4 Verwendungsrichtlinien
In den vorigen Abschnitten wurden die verschiedenen Diagramme und
deren Konstrukte definiert. Die Definition bezog sich aber stets auf die
syntaktische Verwendung der Elemente, während dabei die Semantik nur
als Begründung für die syntaktischen Entscheide beschrieben wurde.
Für die Anwendung der Methode auf ein bestimmtes Entwurfsproblem
bleiben die Fragen
• wie entwerfe ich in bestimmten Situationen und
• wann soll ich welches Konstrukt verwenden?
noch offen. Diese Fragestellungen sollen in den folgenden Abschnitten
durch verschiedene Vorschläge für Vorgehensrichtlinien beantwortet
werden.
Diplomarbeit
DEIMOS • 95
Die Formulierung von Vorgehensrichtlinien ist immer ein Balanceakt.
Auf der einen Seite soll die Freiheit des Entwerfers möglichst nicht
beschnitten werden und auf der andreren Seite verbessern strenge Regeln
die spätere Umsetzung der entworfenen Systeme in
Anwendungsprogramme. Die nachfolgenden Richtlinien sind eher
bezüglich der Sicherung der Datenintegrität optimiert und deshalb streng
formuliert.
Zuerst werden verschiedene Aspekte der Verwendung von Konstrukten
der Schema- und Transaktionsdiagramme beleuchtet, anschliessend soll
dem Transaktionsentwurf und der Konsistenzsicherung besondere
Aufmerksamkeit geschenkt werden.
Vorgehensrichtlinie
n versus Freiheit
des Entwerfers
4.4.1 Verwendung der Konstrukte eines
Schemadiagramms
4.4.1.1 Persistente und transiente Objekte
Für die Modellierung von persistenten Objekten sollen die
Datenbankklassen verwendet werden, welche als einzige
persistenzfähig sind. Transiente Objekte hingegen sollen als
Instanzen von Hilfsklassen aufgefasst werden. Abstrakte
Klassen können keine Instanzen ausbilden, weshalb diese
lediglich für die Beschreibung zusammenfassender
Klasseneigenschaften in den strukturellen Entwurf
einbezogen werden sollen. Die Definition von explizit
persistenten Objekten kann mit Hilfe der Einstiegspunkte
erreicht werden.
4.4.1.2 Exklusive existenzabhängige Aggregation
Die Modellierung von exklusiver existenzabhängiger
Aggregation wird gut unterstützt. Die Verwendung der
Komponentenbeziehung bildet exakt dieses Verhältnis
zweier Klassen ab, wenn auf der rückbezüglichen Seite der
Beziehung die Kardinalität gleich eins gesetzt wird. Die
Erzeugungs- und Löschfortpflanzung ist gewährleistet.
4.4.1.3 Nicht-exklusive existenzabhängige Aggregation
Etwas problematischer verhält sich die Methode DEIMOS
bei der Modellierung von nicht-exklusiven
existenzabhängigen Aggregationsbeziehungen. Dies sei am
Beispiel der Konferenzadministration (PCSS)
veranschaulicht.
Ein Programmkomitee (PC) besteht aus Mitgliedern. Die
Mitglieder können in mehreren Programmkomitees als
Experten auftreten. Experten überprüfen eingereichte
Papiere. Papiere können an mehrere Konferenzen
eingereicht werden.
96 • DEIMOS
Diplomarbeit
PC
PCSS
1+
1+
Paper
PCMember
0+
1+
Abbildung 4-12: Beispiel Konferenzadministration: erster Entwurf
Der erste Entwurf betrachtet ein Papier als eine
Komponente des Mitgliedes. Diese Modellierung ist aber
künstlich und bildet intuitiv nicht den Sachverhalt der
Realwelt ab. Zudem ist bei dieser Art der Struktur die
Löschung nicht mehr eindeutig. Dies sei am folgenden
Objektdiagramm veranschaulicht:
PC::A
PC::B
PCM::a
PCM::b
Pap::1
Pap::2
Pap::3
Abbildung 4-13: Objektdiagramm einer bestimmten Situation
Im Objektdiagramm sind die Komponentenbeziehungen zu
einem bestimmten Zeitpunkt dargestellt. Soll nun die
Konferenz „B“ gelöscht werden, entstehen einige
Probleme:
• Soll das Papier „3“ gelöscht werden? Die Beziehung
zum Mitglied „a“ deutet zwar darauf hin, dass dieses Papier
noch in einer anderen Konferenz verwendet wird, aber was
ist, wenn dieses Mitglied zusätzlich zu den obigen
Annahmen noch im Komitee „B“ als Experte figuriert?
• Soll das Papier „2“ gelöscht werden? Es kann nicht
mehr entschieden werden, zu welcher Konferenz es
eingereicht wurde.
Die Beantwortung dieser Fragen, bzw. das korrekte
Verhalten des Systems in diesen Situationen muss durch
zusätzlichen Programmieraufwand erzwungen werden.
Würde man das Papier hingegen als Komponente der
Konferenz modellieren, könnten derartige Situationen nicht
auftreten.
Diplomarbeit
DEIMOS • 97
PC
PCSS
1+
1+
1+
0+
Paper
PCMember
0+
1+
Abbildung 4-14: Schemadiagramm mit Papier als Komponente der Konferenz
Die Löschung der Papiere ist somit geregelt, da eine direkte
Beziehung zwischen den Papieren und der Konferenz
besteht. Es kann also die folgende Verwendungsrichtlinie
für die nicht exklusive extistenzabhängige Aggregation
formuliert werden:
Objekte, die als Komponenten von mehreren
Objekten auftreten, dürfen ihrerseits nur Beziehungen zu
Objekten unterhalten, die ebenfalls Komponenten ihres
Besitzers sind.
4.4.1.4 Nicht-existenzabhängige Aggregation
Für den Entwurf von Objekten, die eine nichtexistenzabhängige Aggregationsbeziehung unterhalten (die
Löschung des Aggregats weitet sich nicht auf die
Komponenten aus und umgekehrt), kann folgede Regel
festgehalten werden:
Nicht-existenzabhängige Aggregation wird durch
das Konstrukt der inversen Beziehung abgedeckt.
4.4.1.5 Rekursive Aggregation
In der Realwelt trifft man in gewissen Situationen rekursive
Aggregation an. Als Beispiel soll eine Firma betrachtet
werden, deren Abteilungen ihrerseits Abteilungen enthalten
können. In DEIMOS kann für die Abbildung der
beschriebenen Struktur nicht die Komponentenbeziehung
verwendet werden, da die Eindeutigkeit des
Komponentenbaumes gefordert worden ist.
0+
0+
Company
Division
Employee
Abbildung 4-15: Schemadiagramm mit komponentenbeziehungsbasierter rekursiver
Aggregation
Eine Abteilung wäre, falls diese Forderung aufgeweicht
würde, einerseits eine Komponente der Firma oder
andererseits eine Komponente einer Abteilung. Somit
würde man die Fähigkeiten der Firmeninstanz, nämlich die
98 • DEIMOS
Diplomarbeit
Existenzkontrolle (Erzeugung und Löschung) und die
Extensionseigenschaft (Schutz der Eindeutigkeit für die
Schlüsselbeziehungen), stark einschränken. Die
Löschfortpflanzung und die Konsistenzsicherung wären bei
der Umsetzung in ein physisches Schema nicht mehr ohne
zusätzlichen Programmieraufwand möglich.
Aus diesem Grund sind rekursive Aggregationen mit Hilfe
der inversen Beziehungen darzustellen. Die
Existenzabhängigkeit ist durch die Angabe der Kardinalität
1 am Ausgangsort der Beziehung zu erreichen.
0+
1
0+
Company
Division
Employee
Abbildung 4-16: Schemadiagramm mit rekursiver Aggregation, basierend auf inverser
Beziehung
Als Regel lässt sich folgendes formulieren:
Die rekursive Aggregation muss durch die
Verwendung einer rückbezüglichen, inversen Beziehung
modelliert werden.
4.4.1.6 Extensionen und Schlüssel
Erneut soll das Beispiel der Konferenzadministration
herangezogen werden. Der Entwerfer möchte erreichen,
dass sämtliche PC-Mitglieder bezüglich ihres Vor- und
Nachnamens eindeutig identifizierbar sind. Ausgehend vom
obigen Entwurf betrachtet er die einzelnen
Programmkomitees als lokale Extensionen der Mitglieder.
Somit definiert er als Eigenschaft der Klasse PC einen
Schlüssel
PCMember<Name,FirstName>
Damit hat er erreicht, dass er die Instanzen der Klasse PC
für die Eindeutigkeit des Schlüsselkriteriums bei der
Erzeugung von Mitgliedern überprüfen kann. Nun ist er
aber mit dem Resultat noch nicht zufrieden, weil er
eigentlich eine globale Eindeutigkeit erzielen wollte. Also
muss er das Schemadiagramm geringfügig anpassen.
PC
PCSS
1+
1+
1+
PCAdmin
PCMember
1+
Diplomarbeit
DEIMOS • 99
Abbildung 4-17: Schemadiagramm für die Konferenzadministration mit globalem
Sammelobjekt
Die erste Möglichkeit besteht darin, die Mitglieder als
Komponenten eines neuen globalen Verwaltungsobjektes
PCAdmin zu betrachten. Damit ist die globale
Eindeutigkeit erreicht, da nur eine Instanz dieser Klasse durch die Instantiierung - erzeugt wird.
Als zweite Möglichkeit kann auch eine Extensionsklasse
ins Schema eingeführt werden.
PC
PCSS
1+
1+
1+
1
PCMemExt
PCMember
1
1+
Abbildung 4-18: Schemadiagramm für die Konferenzadministration mit Extension
Diese Extensionsklasse ist beispielsweise als geteilte
Komponente auffassbar (jede Instanz der Klasse PC
verweist auf dieselbe Instanz der PCMemExt) oder als
Komponente einer zusätzlichen Administrationsklasse
(siehe oben). Die Eindeutigkeit des Schlüssels kann nun
beim Aufbau der zwingenden Beziehung zwischen
PCMember und PCMemExt, welche bei der Erzeugung
einer Instanz der Klasse PCMember installiert werden
muss, geprüft werden.
Als Regel für die Modellierung von globaler Eindeutigkeit
lässt sich also folgendes festhalten:
Globale Eindeutigkeit lässt sich nur dann erreichen,
wenn alle Instanzen für welche das Eindeutigkeitskriterium
gelten soll, Komponente desselben Objektes sind, oder
wenn ein einmaliges Objekt exisitert, welches zu allen
fraglichen Objekten eine inverse Beziehung mit der
rückbezüglichen Kardinalität 1 besitzt.
4.4.2 Verwendung der Konstrukte eines
Transaktionsdiagramms
4.4.2.1 Transaktionsdiagramm
Das Transaktionsdiagramm wird für den Entwurf und die
Definition der Lese- und Schreibtransaktionen verwendet.
In vielen der heute verfügbaren
Datenbankimplementierungen werden die Applikationen
nicht im Datenbankschema definiert (vlg. “Aktuelle
Implementierungen”, Seite 18), sondern ausserhalb in Form
von beispielsweise C++-Programmen, welche über
definierte Schnittstellen (vlg. “
100 • DEIMOS
Diplomarbeit
sFür den Umgang mit Mengen stehen noch weitere Ausdrücke zur
o
Verfügung.
So kann eine Menge durch sort ... in ... by ... sortiert oder
durch
group ... in ... by ... with ... gruppiert werden, wobei der with-Teil
r
t
ähnlich
einer Klausel having in SQL eine einschränkende Bedingung
enthalten kann.
g
r
o
u
p
union
intersect
except
element
flatten
Diplomarbeit
Verschiedene aber gleichartige Menge können durch union verbunden
(Vereinigungsmenge), durch intersect geschnitten (Durchschnittsmenge)
oder durch except voneinander abgezogen werden (Differenzmenge).
Will man die innere Struktur einer Menge verändern, so existieren
element, zur Schaffung einer Menge aus einem Wert, flatten für das
Ausflachen einer homogenen Multimenge zu einer Menge, oder flatten
zur Überführung einer Liste zu einer Menge als Möglichkeiten.
Anbindung an Programmiersprachen”, Seite 15) auf die
persistenten Objekte der Datenbasis zugreifen.
In der gewählten Umgebung O2 hingegen sind
Applikationsklasse und -instanzen aber Teil des Schemas
und sollen daher auch in den Schemaentwurf einbezogen
werden können.
4.4.2.2 Konstrukte des Subsystemdiagramms
Das Subsystemdiagramm bietet Möglichkeiten zum
Grobentwurf von Datenbankapplikationen an. Die
Konstrukte sind die Applikation, welche die als Sammlung
von Subsystemen und/oder Programmen aufgefasst werden
darf und die Subsysteme, die weitere Subsysteme oder aber
direkt Programme enthalten.
Applikationen stellen Anwendungen dar, während
Subsysteme für die Aufteilung des Problembereiches
verwendet werden.
4.4.2.3 Konstrukte des Transaktionsdiagramms
Im Transaktionsdiagramm werden Programme, Funktionen
und Transaktionen als Konstrukte angeboten. Diese sollen
nun wie folgt unterschieden und entsprechend verwendet
werden:
Ein Programm soll als Lesetransaktion aufgefasst werden.
In einem Programm werden also alle Datenbankoperationen
untergebracht werden, welche nur lesend auf die Datenbasis
zugreifen. Werden schreibende Aktionen verwendet,
müssen diese in Transaktionen, welche vom Programm aus
aufgerufen werden können, gepackt werden.
Eine Funktion kann als freier Programmblock einer
Lesetransaktion betrachtet werden und fasst analog zum
allgemeinen Verständnis von Funktionen wiederkehrende
Aufgaben in wiederverwendbare Codeteile zusammen.
DEIMOS • 101
Eine Transaktionen hingegen ist eine Schreibtransaktionen
und soll für die Zusammenfassung von
Datenbankoperationen in logischen Arbeitseinheiten der
Realwelt verwendet werden.
Zusammenfassend gelten für die Konstrukte des
Transaktionsdiagramms die folgenden
Verwendungsrichtlinien:
Programme werden für die Darstellung von
Lesetransaktionen,
Funktionen für die Zusammenfassung von wiederkehrenden
Anweisungsblöcken und
Transaktionen für die Gliederung der schreibenen
Datenzugriffe in logische Arbeitseinheiten verwendet.
4.4.3 Transaktionsentwurf
Die Transaktion ist, wie im vorigen Kapitel ausgeführt, das
zentrale Instrument, um Daten innerhalb von Datenbanksystemen
zu erzeugen, zu löschen und zu manipulieren. Sie bilden in
Datenbanksystemen die Einheit der Konsistenz, der
Dauerhaftigkeit und der Atomarität.
4.4.3.1 Transaktionskomplexität
Datenmanipulatione
n und physischen
Aspekte
Der Systemarchitekt muss sich beim Entwurf überlegen, welche
Datenmanipulationen er in eine bestimmte Transaktion verpacken will.
Insbesondere muss er sich auch die physischen Aspekte, die er in einem
späteren Entwurfsschritt noch genauer spezifizieren kann,
vergegenwärtigen, da während der Ausführung Sperrungen auf die Daten
propagiert werden.
Ausführungsdauer
Für die Ausführungsdauer einer Transaktion kann man sich zwei
Extremfälle vorstellen:
Maximalfall: Eine
Sitzung - Eine
Transaktion
Im Maximalfall beginnt die Transaktion am Anfang der Sitzung (Start der
Anwendung) und endet, wenn die Applikation geschlossen wird. Dieser
Ansatz ist darum sehr gefährlich, weil zum einen keine anderen Benutzer
die angelegten Datenbestände lesen oder beschreiben können, was den
Mehrbenutzerbetrieb völlig ausser Kraft setzt, und zum anderen keine
Datensicherheit besteht, da das System nach Wiederanlauf sämtliche
Änderungen verworfen haben wird.
102 • DEIMOS
Diplomarbeit
Im Minimalfall hingegen wird jede Anweisung, welche Attributwerte von
persistenten Objekten verändert, in eine Transaktion verpackt. Mit dieser
Strategie können Methoden mehrere Transaktionsblöcke enthalten und
zudem ist der Methodenaufruf selber in einer Transaktion untergebracht.
Die Leistungsfähigkeit derart implementierter Systeme wird mit solchen
Ressourcenverschleuderungen unnötig vermindert. Ferner kann in einem
Fehlerfall nur die fehlgeschlagene Transaktion rückgängig gemacht
werden. Die logisch zu derselben Manipulation gehörenden Teile sind
bereits in der Datenbank gespeichert und müssen durch aufwendige
Fehlerbehandlungsroutinen (die selber auch wieder Fehler verursachen
können) auf einen konsistenten Zustand zurückgeführt werden. Diese
Strategie setzt also die gewünschten Effekte der Transaktion - Übergang
von einem konsistenten Zustand in den nächsten oder im Fehlerfall auf
denselben zurück - gänzlich ausser Kraft.
Die angemessene Dauer der Transaktion muss also
zwischen diesen beiden Extremvarianten gewählt werden.
Insbesondere müssen zur genaueren Spezifikation des
Transaktionsinhaltes Aspekte der Semantik der Realwelt
herangezogen werden. Eine Transaktion soll beendet
werden, wenn
• ein logischer Arbeitsschritt beendet ist,
• die Änderungen dauerhaft (für andere Benutzer sichtbar)
gemacht werden sollen und
• die Datenintegrität erreicht werden kann.
Anstelle der physischen Aspekte, dass
• sich lange Transaktionen aufgrund der Sperrungen
nachteilig auf den Mehrbenutzerbetrieb auswirken und
• kurze Transaktionen das System belasten (Commits sind
teure Operationen),
werden also vielmehr Kriterien der Logik eines Systems für
die Modellierung der Transaktionen angewendet:
• Definition der Transaktionen nach logischen
Arbeitsschritten (Semantik der Realwelt).
• Im Fehlerfall soll auf einen logisch sinnvollen Zustand
zurückgesetzt werden können (Abort). Zwischenresultate
sollen also nicht gespeichert werden.
4.4.3.2 Transaktionsaufrufe
Minimalfall: Jede
Manipulation - Eine
Transaktion
Plazierung der
Transaktionen
Diplomarbeit
Die zweite Überlegung, die der Entwerfer unbedingt anstellen muss, ist
die Plazierung der Transaktionen innerhalb des Klassen- und
Applikationsgefüges. Wiederum können bei diesen Erörterungen zwei
verschiedene Extremstrategien verfolgt werden. Transaktionen können
ausschliesslich in den Methoden der Datenbankklassen verpackt sein oder
gänzlich aus den Methoden ausgelagert in den Transaktionsblöcken der
Applikationen implementiert werden.
DEIMOS • 103
Transaktionen in
Klassenmethoden
Transaktionen in
Applikationen
lesende und
schreibende
Methoden
104 • DEIMOS
Werden die Transaktionen in den Klassenmethoden untergebracht, geht
dieses Vorgehen zumeist zu Lasten der Wiederverwendbarkeit. Der
Entwurf der Datenbankklassen berücksichtigt nur die Semantik der
Datenhaltung, nicht aber die der Datenverwendung und
Datenmanipulation. Letzere Aspekte werden durch die um die
Datenbestände herumgebauten Programme spezifiziert.
Datenbankklassen, welche eingekapselte Transaktionen in ihren
Methoden verbergen, sind damit zweckgebunden.
Aus diesem Grund sollten Transaktionen nicht in Klassenmethoden
untergebracht werden. Auch Mischformen (z.B. Implementation der
Transaktionen ausschliesslich in Hilfsklassen) unterliegen diesen
Gefahren. Es empfiehlt sich also hier die Extremvariante zu wählen, die
sämtliche Transaktionen von den Klassen der Datenbasis fernhält und in
die Programme auslagert, welche die Datenbestände benutzen und
verändern.
Ein weiterer Vorteil, der sich aus dieser Wahl ergibt, kann
in der Systemunterstützung bei der Formulierung von
Transaktionen durch das Sprachkonstrukt „transaction“
gesehen werden. Nur so deklarierte Anweisungsblöcke sind
vom System O2 für die Unterbringung der Transaktionen
vorgesehen, was sich darin äussert, dass
Zuwiderhandlungen vom Datenbanksystem entdeckt
werden und von den Entwicklern durch Meldungen
wahrgenommen werden können.
4.4.3.3 Transaktionsentwurf
Mit der Methode wurde nun der Diagrammtyp „Moduldiagramm“
dergestalt erweitert, dass der Entwurf der Transaktionen überhaupt
ermöglicht wird. Zudem ist durch die Typisierung der öffentlichen
Methoden der Datenbankklassen in lesende und schreibende eine weitere
Sicherheit eingebaut worden. Der Entwerfer muss sich zwangsläufig klar
werden, ob eine Methode die Attributwerte verändert. Im
Transaktionensentwurfsschritt muss er darauf achten, dass er schreibende
Methoden immer in Transaktionen verpackt und lesende möglichst aus
diesen Blöcken auslagert.
Zusammenfassend lassen sich also die folgenden Regeln
formulieren:
Transaktionen sollen so gestaltet werden,
dass sie logische Arbeitseinheiten abbilden und
dass im Fehlerfall auf ein logisch sinnvollen Zustand
zurückgekehrt werden kann.
Transaktionen sollen nicht in Klassenmethoden,
sondern ausschliesslich in den dafür vorgesehenen
Konstrukten der Datenmanipulationssprache formuliert
werden.
Dem Entwerfer wird also mit dieser Methode ein Werkzeug
in die Hand gelegt, welches ihn hinsichtlich der
Problematik der Transaktionen sensibilisiert und ihn in der
sicheren Manipulation der Daten entsprechend unterstützt.
Diplomarbeit
4.4.4 Fortpflanzung und Konsistenzsicherung
Die Wahrung der Konsistenz bei Manipulationen ist aufgrund der
Forderung nach Komponentenbäumen und der Einschränkung,
dass ausschliesslich inverse Beziehungen zwischen den
Datenbankklassen herrschen dürfen, ermöglicht. Im Folgenden soll
für die Objekterzeugung und -löschung ein Vorgehen aufgezeigt
werden, welches die Datenintegrität bezüglich Fortpflanzung
sichert. Anschliessend sind die Implikationen für eine Umsetzung
eines Entwurfs in die Implementation ausgeführt.
4.4.4.1 Erzeugung
Die Konsistenzprüfung bei der Kreation neuer
Klasseninstanzen muss innerhalb der folgenden
Transaktion ablaufen:
1. Beginn der Transaktion.
2. Kreation der Instanz von ihrer Aggregationsinstanz aus.
3. Initialisierung der neuen Instanz.
4. Prüfung der Invariante für die neue Instanz am Ende der
Initialisierungsmethode.
5. Aufbau der Komponentenbeziehung.
6. Prüfung der expliziten Konsistenzbedingungen.
7. Abschluss der Transaktion mit Erfolg oder Misserfolg.
Erzeugung der
Subkomponenten
Besitzt die zu kreierende Instanz ihrerseits zwingende
Komponentenbeziehungen, also Verbindungen, die Kardinalitäten
grösser als 1 vorsehen, werden innerhalb des oben beschriebenen
Schrittes 2 die entsprechenden Subkomponenten gleichfalls erstellt.
rekursive
Erzeugung
Man darf sich somit die beschriebene Transaktion rekursiv vorstellen.
Trotz dieser rekursiven Definition ist die Terminierung gewährleistet, da
Komponenten und Subkomponenten nur entlang des
Komponentenbaumes kreiert werden und dieser gemäss Definition keine
Zyklen enthalten kann. Zudem müssen für die Minima bei der
Kardinalitätsdefinition der Komponentenbeziehungen endliche Werte
angegeben werden.
Initialisierung und
Konsistenzprüfung
Im dritten Schritt werden die Attribute initialisiert. Sind bei der
Definition der Klasse für die Attribute Standardwerte angegeben worden,
werden diese den entsprechenden Attributen zugewiesen. Am Ende
dieser Initialisierung wird die Invariante überprüft. Der Entwerfer ist also
gefordert, das Zusammenspiel der Invariante und der Standardwerte
aufeinander abzustimmen.
Aufbau der inversen
Relationen
Inverse Relationen, an denen die neu entstehenden Komponenten
teilnehmen, müssen gleichfalls während der Gesamttransaktion aufgebaut
werden, damit die Kardinalitätsbedingungen nicht verletzt werden. Dies
kann innerhalb der Abarbeitung der Initialisierungsroutine mittels
Übergabe der entsprechenden Referenzen geschehen, oder, da diese
Strategie nicht immer zur Konsistenz führt, explizit als dedizierter
Transaktionsschritt.
Falls es sich bei der anzulegenden Instanz um einen
Einstiegspunkt handelt, ist es naheliegend, dass der Schritt
Diplomarbeit
DEIMOS • 105
2 nicht von der Aggregationsklasse aus durchgeführt
werden kann und dementsprechend der Schritt 4 gänzlich
überflüssig wird.
4.4.4.2 Löschung
Die Konsistenzprüfung bei der Löschung von Objekten
muss innerhalb der folgenden Transaktion ablaufen:
1. Beginn der Transaktion.
2. Vorbereitung der Instanz auf die Löschung.
3. Löschung der Instanz von ihrer Aggregationsinstanz aus.
4. Abbau der Komponentenbeziehung.
5. Prüfung der expliziten Konsistenzbedingungen.
6. Abschluss der Transaktion mit Erfolg oder Misserfolg.
Löschvorbereitung
für Subkomponenten
Konsistenzprüfung
Unterhält die zu löschende Instanz ihrerseits Beziehungen zu anderen
Objekten, so müssen diese während der Löschvorbereitung abgebaut
werden. Dies gilt sowohl für die Komponentenbeziehungen als auch für
die inversen Beziehungen. Wiederum dehnt sich also die beschriebene
Transaktion auf die etwaigen Subkomponenten aus. Analog zu obiger
Begründung ist die Terminierung dieser rekursiven Transaktion nicht
gefährdet.
Ist von dieser Löschung ein Einstiegspunkt betroffen, fällt
Schritt 4 weg und Schritt 3 kann unabhängig von einer
Aggregationsklasse durchgeführt werden.
Die Prüfung der Invariante für das Objekt am Ende der
Löschvorbereitungsmethode ist überflüssig, da dieses entweder aus der
Datenbasis entfernt wird oder bei nicht erfolgreicher Terminierung der
Transaktion auf den „status quo ante“ zurückgesetzt wird.
Die Löschung von Subkomponenten wäre eigentlich nicht nötig, da
innerhalb der Datenbankumgebung O2 ein spezieller Prozess für das
Aufräumen nicht mehr referenzierter Objekte verantwortlich ist (Garbage
collector). Unterhalten die Objekte aber Beziehungen anderer Art, kann
die Situation auftreten, dass Referenzen auf bereits gelöschte Objekte
bestehen bleiben oder Objekte durch derartige Referenzen aufgrund der
Persistenzfortpflanzungsstrategie unbeabsichtigt in der Basis erhalten
bleiben.
4.4.4.3 Implikationen für die Umsetzung
Damit die Konsistenz des Schemas gesichert ist und die
beschriebenen Fortpflanzungseffekte realisiert werden
können, müssen die Datenbankklassen folgende
Eigenschaften besitzen:
Sie müssen die Methoden
• für die Erzeugung aller notwendigen Subkomponenten,
• für Initialisierung der Attribute,
• für die Überprüfung der Invarianten,
• für die Überprüfung der impliziten
Konsistenzbedingungen und
• für die Löschvorbereitung
implementieren.
Garbage Collection
106 • DEIMOS
Diplomarbeit
Löschvorbereitung bedeutet, dass sämtliche Beziehungen
zu anderen Objekten abgebaut werden. Für alle
Subkomponenten werden zuerst die entsprechenden
Destroy-Methoden aufgerufen, damit diese sich ihrerseits
auf die Löschung vorbereiten können. Danach werden die
Objekte in Abhängigkeit der aktuellen Implementation des
DBS explizit oder durch einen Aufräumdienst (Garbage
Collection) implizit zerstört.
Verbindungsaufbzw. abbau
Datenbankklassen müssen zudem für jede Beziehung je eine Methode
besitzen, um die Verbindung auf- bzw. abzubauen. Für die inversen
Beziehungen muss zudem zwischen dem aktiven und dem passiven Aufbzw. Abbau unterschieden werden, was bei Komponentenbeziehungen,
welche nur seitens des Besitzers kontrolliert werden, nicht gewährleistet
sein muss.
In der letzten Eigenschaft liegt die Begründung, warum die
Datenbankklassen nur Beziehungen vom Typ
„Komponente“ und „invers“ unterhalten dürfen. Wären
nämlich noch andere Typen zugelassen, wie etwa die
einseitige „has-a by reference“-Beziehung, so wäre es einer
beliebigen Instanz dieser Klasse nicht möglich, ohne Hilfe
von anderen Instanzen eine konsistente Löschvorbereitung
vorzunehmen, was die Propagierung der Löschung
verunmöglichen würde.
Fortpflanzungseffek
te
Die Konstrukte der Methode wurden also so gewählt, dass die
Fortpflanzungseffekte so gut wie möglich unterstützt werden und der
Entwickler der Datenbankapplikation so wenig wie möglich mit der
Sicherung der Konsistenz zu tun hat.
Dennoch kann in manchen Fällen die Konsistenz gefährdet
sein, da durch eine einzelne Manipulation die implizite
Konsistenzbedingung, welche durch die
Kardianlitätsangabe bei den inversen Beziehungen
entstanden ist, verletzt werden könnte. Die Löschung wie
auch das Einfügen pflanzen sich also nicht über derartige
Beziehungstypen fort.
Man stelle sich ein Schema mit zwei Einstiegspunkten vor,
die nicht Instanzen derselben Klasse sind. Damit hat man
zwei disjunkte Komponentenbäume in seinem
Entwurfsdiagramm. Seien nun die beiden Bäume durch
eine inverse Beziehung miteinander verbunden und trage
diese auf beiden Seiten die Kardinalität 1, so kann der Fall
eintreten, dass eine Löschung nicht nur innerhalb des
eigenen Baumes ihre Auswirkungen hat, sondern
gleichermassen die Existenz von Instanzen im anderen
Teilbaum semantisch verunmöglicht. Im Extremfall kann
sich die Löschung einer Instanz semantisch sogar soweit
fortpflanzen, dass sämtliche Objekte aus der Datenbasis
entfernt werden müssten.
Diplomarbeit
DEIMOS • 107
Die Eigenschaften der Datenbankklassen müssten also um
die Fähigkeit, sich selber löschen zu können, erweitert
werden. Diese Möglichkeit kann aber der Klasse selbst
nicht gegeben werden, weil sonst neue Inkonsistenzen bei
der Besitzer-Komponenten-Verbindung längs der
Komponentenbeziehungen auftreten könnten.
Daraus folgt, dass die Funktionen für die Manipulationen
im Allgemeinen - die oben beschreibenen Effekte treten ja
nicht nur bei der Löschung allein auf - jeweils in zwei
Ausprägungen verfügbar sein müssen. In der ersten wird
die Manipulation abgebrochen, falls die Konsistenz nicht
erreicht werden kann, während in der zweiten davon
ausgegangen werden darf, dass es sich bei dieser Erzeugung
nur um eine Teiltransaktion handelt und somit die
übergeordnete Transaktion die Konsistenz am Ende der
Sequenz prüft.
je zwei Methoden
für Erzeugung und
Löschung
Eine Datenbankklasse muss also für die Erzeugung wie auch für die
Löschung mit je zwei Methoden aufwarten. Die eine ruft die
Konsistenzsicherungs-Methode am Ausführungsende auf und sichert
somit selber die Konsistenz, während die andere auf diese Prüfung
verzichtet. Diese Funktion wird also neu in die Klassenschnittstelle
aufgenommen, während für die Variante der inkonsistenten Erzeugung
eine weitere Funktion zur Verfügung steht.
4.5 Bewertung der Methode
Nachfolgend soll überprüft werden, inwiefern sich die im vorigen Kapitel
aufgedeckten Schwachstellen mit der neuen Methode ausräumen lassen.
4.5.1 Persistenz
In den betrachteten Methoden wurde beanstandet, dass nicht
zwischen persistenten und transienten Klassen unterschieden
werden kann, kein Konstrukt für die Darstellung eines persistenten
Einstiegspunktes zur Verfügung steht und die Fortpflanzung der
Persistenz nicht im Entwurf zu kontrollieren ist. Diese Konstrukte
sind aber für den Schemaentwurf von zentraler Bedeutung.
Durch die Einführung eines Elementes für die Darstellung der
Einstiegspunkte und eines Beziehungstyps
(Komponentenbeziehung), der die Persistenz auf andere Klassen
überträgt, sind dem Entwerfer Konstrukte in die Hand gelegt
worden, mit denen er die Aspekte der Persistenz während des
Entwurfes mitberücksichtigen kann. Die Schwachstelle konnte so
vollständig beseitigt werden.
Die Erweiterung der Notation um Einstiegspunkte verursachte aber
eine Aufweichung der in der Originalmethode strikte formulierten
Trennung von Objekten und Klassen. In DEIMOS sind nun im
Diagramm zur Modellierung der strukturellen Eigenschaften und
Abhängigkeiten von Klassen auch einzelne Objekte zu finden.
Zudem wurde dem Entwerfer durch die strenge Forderung nach
eindeutigen Komponentenbäumen viel Entscheidungsfreiheit
108 • DEIMOS
Diplomarbeit
entzogen. In vielen Fällen wird daher die intuitive Modellierung
durch die Befolgung der starren Regeln eingeschränkt sein.
Man hätte auch auf die Definition des Einstiegspunktes im Rahmen
des Schemadiagramms verzichten und diesen im Objektdiagramm
spezifizieren können. Dies hätte aber sicherlich nicht zur besseren
Lesbarkeit des Schemadiagramms beigetragen.
Ebenso hätte vo der Fortpflanzungskontrolle abgesehen werden
können. Die Unterscheidung zwischen transienten und
persistenzfähigen Klassen hätte schon viel für die Sicherheit der
Datenbasis getan. Die Konsequenzen der Weglassung des
expliziten Komponentenbeziehungstyps hätte sich aber nachteilig
auf die Löschpropagation ausgewirkt (vgl. folgende Abschnitte).
4.5.2 Fortpflanzung und Konsistenzsicherung
Die Konzepte für die Fortpflanzung und die Sicherung der
Datenintegrität sind sowohl im konzeptuellen Entwurf als auch in
der Implementation des Datenbanksystems ungenügend
berücksichtigt. Die Entwurfssprache enthält lediglich die
Möglichkeit zur Formulierung von invarianten und das DBS prüft
einzig inhärente Konsistenzbedingungen. Diese Konzepte sind aber
für das Arbeiten mit Datenbanken von eminenter Wichtigkeit.
Dieser Schwachstelle wurde durch die strengen Forderungen der
Notation und durch die Formulierung eines Transaktions- und
Konsistenzsicherungs-Konzeptes zu Leibe gerückt. Damit konnte
sie unter der Berücksichtigung der bereits diskutierten
Einschränkungen weitgehend behoben werden.
Dafür musste aber sowohl seitens des Entwerfers als auch seitens
des Entwicklers ein erheblicher Preis gezahlt werden: dem
Entwerfer werden durch die strengen Verwendungsrichtlinien viele
Freiheiten entzogen, er muss die definierten Vorgehensweisen
strikte und ausnahmslos befolgen. Für den Entwickler ergeben sich
viele Konsequenzen, welche er bei der Umsetzung des Entwurfes
in die Implementation berücksichtigen muss. Lässt er sich aber bei
diesem Prozess von Werkzeugen helfen oder kann er auf
bestehende Rahmenwerke zurückgreifen, spart er viel Zeit und
aufwendige Programmierarbeit.
Die Schwachstelle hätte auch bekämpft werden können, indem
erhöhter Druck auf die Hersteller von objektorientierten
Datenbanksystemen ausgeübt worden wäre, damit sie endlich die
für relationale Systeme selbstverständlichen Konzepte in ihre
Produkte hätten einfliessen lassen. Dies ist aber eine andere
Problematik und soll entsprechend auch an einem anderen Ort
diskutiert werden.
4.5.3 Extensionen und Schlüssel
Die ODMG-93 hält in ihrem Standardisierungsvorschlag die
Definition von Schlüsseln für jede Klasse fest. Die Umsetzung
dieses Konzeptes ist aber in der Implementierung der Datenbank
nicht zu finden. Zudem stellt sie implizit keine Extensionen zur
Verfügung. Die beiden Konzepte sind aber von grosser Bedeutung
Diplomarbeit
DEIMOS • 109
für das Auffinden von Instanzen für die Formulierung von
Eindeutigkeitskriterien und für die Auswertung von summarischen
Abfragen.
Durch die Umsetzung der Forderung nach Komponentenbäumen
konnte erreicht werden, dass alle persistenten Instanzen direkte
oder indirekte Komponenten des Einstiegspunktes sein müssen. Es
können also bezüglich der Komponentenbeziehungen keine losen
oder ungebundenen Instanzen mehr in der Datenbasis enthalten
sein. Diese Massnahme impliziert nun zum einen die Existenz von
Extensionen (lokal oder global) und erlaubt zusätzlich die
Formulierung von Schlüsselkriterien für die
Komponentenbeziehungen, welche anschliessend auf einfache
Weise in beim Einfügen oder Entfernen von Instanzen in die bzw.
aus der Extension überprüft werden können. Die Schwachstelle
wurde dadurch gänzlich behoben.
Eine Aggregationsklasse ist - sofern sie nicht durch den
Einstiegspunkt instantiiert wird - immer eine lokale Extension der
Instanzen ihrer Komponentenklasse. Auf der einen Seite ist diese
Situation - wenn man globale Eindeutigkeit haben will unbefriedigend, auf der anderen Seite lässt sie sich natürlich immer
durch eine Umgestaltung der Komponentenbeziehungen
modellieren. Es gilt also im Entwurfsprozess abzuwägen, ob lokale
Eindeutigkeit ausreichend oder gar gewünscht ist, und wenn nicht,
ob die Komponentenbeziehungen umgebaut werden sollen oder
zusätzliche Hilfen (z.B. explizite Extensionsklasse mit einer
inversen Beziehung zu sämtlichen Instanzen einer bestimmten
Klasse) für die Erreichung der globalen Eindeutigkeit
herangezogen werden sollen.
Mit einem anderen Ansatz, die Einführung von impliziten
Extensionen, hätten weitgehend dieselben Resultate erzielt werden
können. Zu jeder Datenbankklasse im Diagramm hätte man eine
entsprechende Extensionsklasse generieren können, welche die
Aufgaben des Einfügens, Löschens und Überprüfens der
Schlüsselkriterien hätte übernehmen können. Dies hätte aber die
Lesbarkeit der Diagramme erheblich beeinträchtigt, da derartige
Klassen erst nach der Umsetzung sichtbar geworden wären. Zudem
hätte eine lokale Eindeutigkeit, welche in vielen Anwendungen
erwünscht ist, nur durch Einwirkung des Programmierers erreicht
werden können.
4.5.4 Objektevolution
Die Fähigkeit zur Objektevolution ist in vielen Anwendungen eine
wichtige Eigenschaft der persistenten Instanzen. Trotzdem werden
derartige Migrationen von den betrachteten Datenbanksystemen
nicht unterstützt. Da sie sich auch nicht erweitern lassen, muss der
gewünschte Wechsel durch eine Erzeugung und eine Löschung
simuliert werden. Dabei geht aber die Objektidentität verloren,
welche für die Objektbeziehungen von zentraler Bedeutung ist,
was der Kern der Problematik ausmacht.
110 • DEIMOS
Diplomarbeit
Mit der Einführung des neuen Konstruktes für die Darstellung der
Objektevolution wurden die Fähigkeiten des darunterliegenden
Datenbanksystems nicht erweitert. Die in der
Schwachstellenanalyse festgestellte Problematik, die entsteht,
wenn ein Objekt seine eindeutige Kennung aufgeben muss,
obschon es nicht zerstört wird und entsprechend die Verbindungen
zu ihm erhalten bleiben sollen, wurde nicht gelöst. Vielmehr wurde
eine Strategie entworfen, die derartige Manipulationen
kontrollierter ablaufen lässt.
Somit wurde die Schwachstelle nicht behoben, sondern es wurde
durch die Definition eines Konzeptes, welche den zur
Objektevolution äquivalenten Effekt zum Ziel hat, eine gute
Umgehung erreicht. Die Instanzmigration läuft in einem
kontrollierten Prozess ab.
Der Übergang des Objektes Ai in das Objekt Bj unterliegt
denselben Problemen wie die Löschungen, bzw. Erzeugungen von
Datenbankklassen im Allgemeinen (vgl. “Fortpflanzung und
Konsistenzsicherung”, Seite 112). Darüber hinaus unterliegt die
Verwendung des Konstruktes sehr strengen Voraussetzungen, was
die Entwurfsfreiheit erheblich beeinträchtigt.
Die Objektevolution besteht aus einem statischen Teil, welcher für
gewisse Klasseninstanzen Übergänge als Eigenschaften definiert
und einem dynamischen Teil, der die Umstände und
Voraussetzungen für einen derartigen Wechsel beschreibt. Somit
muss die Modellierung von Instanzmigration über mindestens zwei
Diagramme hinweg angegeben werden.
Die Schwachstelle hätte auch behoben werden können, indem die
Migration von Instanzen nur im dynamischen Teil beschrieben
wäre. Zum einen hätte dies in komplizierten und schwer
verständlichen Objektdiagrammen gegipfelt und zum anderen hätte
man den beteiligten Klassen im Schemadiagramm diese
Fähigkeiten nicht mehr angesehen. Das Schemadiagramm würde
damit nicht mehr alle Klasseneigenschaften widerspiegeln.
4.5.5 Inverse Beziehungen
Trotz der Forderung der ODMG-93 nach inversen Beziehungen,
finden sich diese nicht in der betrachteten Implementation des
Datenbanksystems. Auch in der Notation von Booch existiert kein
Konstrukt für die Definition von inversen Beziehungen. Dieser
Beziehungstyp ist jedoch für beispielsweise die Löschfortplanzung
von eminenter Wichtigkeit.
Durch die Einführung des Konstruktes für die Beschreibung der
rückbezüglichen Beziehungen konnte die Schwachstelle
ganzheitlich behoben werden.
Das gleichzeitige Weglassen anderer referenzieller
Beziehungstypen (Assoziation, etc.) führte aber dazu, dass
sämtliche Beziehungen invers definiert sein müssen, was in vielen
Fällen zu einem gewissen Overhead führt.
Man hätte die Booch’sche Philosophie der beidseitigen
Kardinalitätsangabe ohne Definition der Inversität beibehalten
Diplomarbeit
DEIMOS • 111
können, hätte aber in diesem Fall dem Entwickler ein weiteres
Problem überlassen, das er mit viel Programmieraufwand hätte
lösen müssen, und gänzlich auf die Lösch- und
Erzeugungssicherheit verzichten müssen.
4.5.6 Transaktionen
Die betrachtete Entwurfsmethode verfügt weder über
entsprechende Konstrukte zur Definition von Transaktionsaufrufen
noch über Vorgehensrichtlinien für die Formulierung von
Konsistenzbedingungen zur Sicherung der semantischen
Datenintegrität. Dies ist natürlich für die Modellierung von
transaktionsorientierten Systemen eine grosse Schwachstelle.
Durch die Widmung eines ganzen Diagrammtyps dieser
Problematik und die entsprechende Einführung eines
Transaktionskonstruktes auf der einen Seite und durch die
Benennung eines Vorgehens für den Transaktionsentwurf ist der
Schwachstelle in angemessener Form Rechnung getragen worden.
Zudem können Klassenmethoden dank der Definition einer
weiteren Eigenschaft in lesende und schreibende unterschieden
werden. Mit Hilfe dieser Differenzierung kann ein
Transaktionskonzept in einem Applikationsentwurf auf einfache
Weise validiert werden.
Dass die Mechanismen ihre Wirkung erst bei einem sehr genauen
Entwurf zeigen können, darf als Nachteil dieser Erweiterung
gesehen werden. Häufig werden aber Systeme nur grob entworfen.
Die Klassen sind freisprachlich spezifiziert und die Applikationen
lediglich schematisch dargestellt. In diesen Fällen verfehlen
natürlich die eingeführten Konstrukte ihre Aufgabe. Auf der
anderen Seite kann der Zwang für den Entwerfer, sein System
genau zu beschreiben, auch als Vorteil gesehen werden, da bei der
Umsetzung durch den Entwickler keine grossen
Ermessensspielräume mehr bestehen und das Ergebnis
entsprechend auch besser auf die entworfene Lösung passt.
Man hätte auch gänzlich auf den Entwurf von Transaktionen
verzichten können, indem man definiert, dass schreibende
Methoden selbst als Transaktionen aufzufassen sind. Die
Zusammenfassung derartiger Aufrufe in Transaktionsblöcke hätte
man aber entsprechend dem Programmierer überlassen und die
Voraussetzung verletzen müssen, dass der Entwerfer für die
Wahrung der Datenintegrität verantwortlich ist.
4.5.7 Applikationen
Applikationen sind zwar in den objektorientierten
Datenbankumgebungen Teil des Schemas, sie sind aber nicht als
Instanzen von Applikationsklassen implementiert. Auch sind die
Programme und Funktionen nicht als Methoden von Klassen
auffassbar. Dennoch können sie Klassen des Schemas instanzieren,
was eine Unterscheidung in transiente und persistenzfähige
Klassen fordert.
112 • DEIMOS
Diplomarbeit
Durch die Einführung des Transaktionsdiagramms konnte eine
strenge Trennung der Applikationen von den Klassen des Schemas
erreicht werden. Darüber hinaus erlaubt das neue Diagramm eine
genaue Spezifikation der Schnittstellen zwischen der Applikation
und der Datenbasis und legt die Verantwortlichkeiten der
Applikation und der Objekte fest.
Der Transaktionsentwurf schützt das System aber nicht vor
ungewollter Persistenzfortpflanzung. Vielmehr wird der Entwerfer
aufgrund der strengen Regeln des Transaktionsdiagramms auf
diese Problematik sensibilisiert. Dennoch können in den
Ausführungsteilen der Anweisungsblöcke Klassen instantiiert und
deren Methoden aufgerufen werden. Diese Objekte werden aber
ausserhalb von Transaktionen erzeugt und daher nicht in der
Datenbasis abgelegt. Auf diese Weise können sowohl Hilfs- wie
auch Datenbankklassen temporär verwendet werden. In
Datenbankumgebungen, in denen der Grundsatz der „Persistenz
durch Erreichbarkeit“ gilt, muss trotzdem darauf geachtet werden,
dass derartige Objekte nicht durch die Referenzierung von
persistenten Objekten aus selber persistent werden.
Durch die von der Methode geforderte Unterscheidung zwischen
Datenbankklassen, deren Instanzen persistenzfähig sind, und
Hilfsklassen, deren Instanzen nicht persistent gemacht werden
dürfen, können derartige unerwünschte Nebeneffekte bereits zur
Entwurfszeit verhindert werden, da beim Aufbau der Beziehungen
darauf geachtet werden kann, dass Datenbankklassen nur
Verbindungen zu anderen persistenzfähigen Klassen unterhalten.
Sollen Hilfsklassen mit Datenbankklassen verkettet werden, so ist
dies nur zulässig, wenn die Relation der Hilfsklasse gehört und nur
von ihr sicht-, bzw. auf- und abbaubar ist.
Applikationen können nicht mit den Klassendiagrammen
entworfen werden. Vielmehr muss dafür eine zweite Ansicht, das
Transaktionsdiagramm, herangezogen werden. Damit leidet die
einfache Nachvollziehbarkeit, da die beiden sehr nahe beieinander
liegenden Diagramme, welche beide statische Aspekte des Systems
darstellen, physisch getrennt sind.
Die Schwachstelle konnte also nicht vollständig behoben werden.
Dennoch wurde die Zielsetzung in einem hohen Masse erreicht, da
durch Validierungen von anderen Entwerfern oder den Einsatz von
Werkzeugen unerwünschte Effekte frühzeitig erkannt werden
können.
Man hätte auch das Konstrukt der Hilfsklassen für die
Modellierung von Applikationen, Programmen, Funktionen und
Transaktionen erweitern können. Man hätte aber im Falle von O2
virtuelle Klassen geschaffen, welche bei der Übertragung ins
Datenbankschema in andere Strukturen umgesetzt worden wären.
Dieser Ansatz wäre eher für Systeme geeignet, welche
Applikationen nicht im Schema enthalten, sondern ausserhalb (z.B.
C++) implementieren. In diesen Fällen könnte man sich aber
berechtigterweise fragen, ob Applikationen nicht mit bereits
Diplomarbeit
DEIMOS • 113
bestehenden Methoden (Booch, OMT, etc.) entworfen werden
sollten.
4.5.8 Zusammenfassung
Mit der Definition der Methode wurden zwei Ziele verfolgt. Zum
einen sollen die im vorherigen Kapitel beschriebenen und
ausgewählten Schwachpunkte möglichst ausgeräumt werden. Zum
anderen wurde durch das konsequente Streben nach Sicherheit sehr
viel Wert auf die Integrität der Datenbasis gelegt.
Diese Zielverfolgung gipfelte in wenigen Konstrukten und strengen
Anwendungsregeln, was sicherlich vor allem zu Lasten der Freiheit
des Entwerfers und der Flexibilität des Entwurfes ging. Trotzdem
ist in der Umgebung von grossen und komplexen Systemen der
Sicherheit sicherlich die grösste Beachtung zu schenken.
Als grosser Vorteil der Methode kann der Umstand angesehen
werden, dass sich Instanzen dank den Komponentenbeziehungen
sicher erzeugen und löschen lassen. Bei der Umsetzung des
Entwurfes erlaubt sie die Implementation von sicheren
Konstruktoren, Destruktoren und Validierungsfunktionen.
Sicherheit bedeute in diesem Zusammenhang, dass bei einer
erfolgreichen Ausführung des Konstruktors, bzw. Destruktors die
Datenbasis konsistent ist. In Fällen, in denen die selbstprüfende
Variante der Erzeugungs- bzw. Löschfunktion nicht gewählt
werden kann, stellen die veränderten Objekte Prüfungsmethoden in
ihrer öffentlichen Schnittstelle zur Verfügung, die am Ende der
Transaktion aufgerufen werden können, was die Sicherheit der
Transaktionen und dementsprechend das Vertrauen in die
Datenbasis erheblich steigert.
Dass man keine speziellen Konstrukte für die Modellierung der
Extensionen verwenden muss, kann als ein weiterer Vorteil der
Methode ins Feld geführt werden. Zudem widerspiegelt die lokale
Extension häufig den tatsächlich betrachteten Sachverhalt und
schränkt die zugrunde liegende Idee nur geringfügig ein, da über
den Einstiegspunkt stets die globale Extension beschafft werden
kann.
Ein Objekt kann aber nicht als Komponente von verschiedenen
Objekten modelliert werden, was vordergründig als ein Nachteil
erscheinen mag. Bei genauerer Betrachtung aber kann man sich
durchaus daran gewöhnen, dass alle persistenten Instanzen, die zu
einem gewissen Zeitpunkt in der Datenbasis zu finden sind, als
Komponenten der Einstiegspunkte betrachtet werden müssen.
Selbst wenn sich partout keine semantisch sinnvolle
Komponentenbeziehung zwischen den verschiedenen beteiligten
Klassen ausdenken lässt, kann immer die Strategie verfolgt
werden, sämtliche Objekte als Komponenten der Klasse
„Universum“ oder „System“ zu betrachten.
Auch wenn sich der Anwender der Methode DEIMOS über die
starken Einschränkungen wundert, wird auf die Problematiken des
Datenbankentwurfes sensibilisiert, was die Qualität seines
Resultates sicherlich erhöhen wird.
114 • DEIMOS
Diplomarbeit
TEIL II
OSWOOD
OSWOOD O2 Schema design Wizard
based on Booch’s Object-Oriented Design
An expressive notation makes it possible to eliminate much
of the tedium of checking the consistency and correctness of
the decisions by using automated tolls. As a report by the
Defense Science Board states, „Software development is
and always will be a labor-intensive technology... Although
our machines can do the dog-work and can help us keep
track of our edifices, concept development is the
quintessentially human activity... The part of software
development that will not go away is the crafting of
conceptual structures: the part that can go away is the labor
of expressing them“ [Booch 94, pp. 171-172]
Auswahl des Zeichenwerkzeuges
$OV=HLFKHQZHUN]HXJZXUGHGDV3URJUDPP+DUG\GHU8QLYHUVLW\RI
(GLQEXUJKJHZlKOW'LHVHU(QWVFKHLGVWW]WVLFKDXIGLHIROJHQGHQ
9RUWHLOHYRQ+DUG\
• +DUG\ELHWHWHLQHEHQXW]HUIUHXQGOLFKH2EHUIOlFKHIUGDV
=HLFKQHQGHU'LDJUDPPH'LHJlQJLJHQ2SHUDWLRQHQGHU$OLQHDWLRQ
YRQ(OHPHQWHQGHU9HUVFKLHEXQJYRQ(OHPHQWHQXQWHU
%HLEHKDOWXQJGHU9HUELQGXQJHQHWFZHUGHQDOOHVDPWXQWHUVWW]W
• 'LH=HLFKQXQJYRQ'LDJUDPPHQPLW+DUG\EDVLHUWDXI
6\PEROELEOLRWKHNHQXQG'LDJUDPPGHILQLWLRQHQ,QGHQ
6\PEROELEOLRWKHNHQZHUGHQGLH.RQVWUXNWHGHILQLHUWZlKUHQGLQGHQ
'LDJUDPPGHILQLWLRQHQGHUHQ=XVDPPHQVSLHOLQVEHVRQGHUHGLH
(LQVFKUlQNXQJHQLQGHU9HUZHQGXQJIHVWJHOHJWVLQG9RP%HQXW]HU
N|QQHQVRZRKO6\PEROELEOLRWKHNHQDOVDXFK'LDJUDPPGHILQLWLRQHQ
HUVWHOOWZHUGHQ+DUG\LVWDOVRHUZHLWHUEDU
• 'LHYRQ+DUG\HU]HXJWHQ'DWHLHQVHLHQGLHV,QGH[GDWHLHQ
'LDJUDPPGDWHLHQ6\PEROELEOLRWKHNHQRGHU'LDJUDPPGHILQLWLRQHQ
VLQGDOOHVDPW$6&,,'DWHLHQGLHHLQHPHLQIDFKHQ6\QWD[IROJHQXQG
HLJQHQVLFKGHPQDFKIUHLQHZHLWHUH9HUDUEHLWXQJ
• +DUG\LVWDXIGHQ3ODWWIRUPHQ:LQGRZVXQG81,;YHUIJEDU
• 'LH/L]HQ]NRVWHQVLQGLQVEHVRQGHUHIUGLH8QLYHUVLWlWHQYDODEHO
(LQH'HPRYHUVLRQPLWJHULQJHQ(LQVFKUlQNXQJHQJHJHQEHUGHU
9ROOYHUVLRQZLUGLP,QWHUQHWDQJHERWHQ
• +DUG\ZLUGDQGHU8QLYHUVLWlW=ULFKHLQJHVHW]WXQGYRQGHU
8QLYHUVLWlW%HUQHYDOXLHUW
Auswahl der Entwicklungsumgebung
'LH(QWZLFNOXQJGHV:HUN]HXJHVVWHKWQLFKWLP=HQWUXPGHU$UEHLW
$XVGLHVHP*UXQGZXUGHIUGLH,PSOHPHQWLHUXQJHLQH8PJHEXQJ
JHZlKOWZHOFKHGLH0LQLPDONULWHULHQHUIOOWXQGNHLQHQJURVVHQ
$XIZDQGIUGLH(LQDUEHLWXQJLQ$QVSUXFKQLPPW
'LH:DKOILHODXIGLH&(QWZLFNOXQJVXPJHEXQJYRQ0LFURVRIW
QLFKW]XOHW]WGDUXPZHLO&HLQHDQHUNDQQWH3URJUDPPLHUVSUDFKH
LVWVRQGHUQZHLOGLHVH(QWZLFNOXQJVXPJHEXQJPLWHLQHU5HLKHYRQ
NRPIRUWDEOHQ+LOIVPLWWHODXVJHVWDWWHWLVWXQGEHUHLQHUHLFKKDOWLJH
XQGVLFKHUH.ODVVHQELEOLRWKHNYHUIJWYJO´%HZHUWXQJGHU
,PSOHPHQWDWLRQµDXI6HLWH
'LH3ODWWIRUPXQDEKlQJLJNHLWVWDQGDOVREHLP(QWVFKHLGQLFKWLP
9RUGHUJUXQGGHUJHZlKOWH&RPSLOHUNDQQQXU&RGHIU:LQRGHU
0DF26HU]HXJHQ9LHOPHKUVROOWHGHU:HJGHU3RUWLHUXQJVHLHV
GXUFKHLQH1HXNRPSLODWLRQPLWHLQHPDGlTXDWHQ&RPSLOHUDXI
81,;RGHUVHLHVGXUFK7UDQVIRUPDWLRQLQGLH3URJUDPPLHUVSUDFKH
-DYDQLFKWYHUEDXWVHLQ
5 OSWOOD
5.1 Einleitung
'DV:HUN]HXJ26:22'LVWGLH8PVHW]XQJGHULPYRULJHQ.DSLWHO
HLQJHIKUWHQ0HWKRGH'(,026(VVROOGHQ(QWZHUIHUZlKUHQGGHV
$QDO\VHXQG(QWZXUIVSUR]HVVHVEHJOHLWHQXQGGHP(QWZLFNOHUYHUVFKLHGHQH
$UEHLWHQGXUFKGLH*HQHULHUXQJYRQ.ODVVHQXQG$SSOLNDWLRQVJHUVWHQ
DEQHKPHQ
5.1.1 Die Aufgabe von OSWOOD
'LH$XIJDEHYRQ26:22'LVWDOVRGLH%HJOHLWXQJGHV
(QWVWHKXQJVSUR]HVVHVHLQHU'DWHQEDQNDQZHQGXQJ'HU3UR]HVV
EHJLQQWGDEHLPLWGHP6WDUWGHV:HUN]HXJHV26:22'XQGGHP
DQVFKOLHVVHQGHQ9HU]ZHLJHQLQGHQ'LDJUDPPHQWZXUIVPRGXV
0LW+LOIHGHV=HLFKHQSURJUDPPHV+DUG\>+DUG\[email protected]
(QWZHUIHUGLH'LDJUDPPHJHPlVVGHU0HWKRGHQEHVFKUHLEXQJ
'(,026]HLFKQHQ1DFKGHPGLHYHUVFKLHGHQHQ$QVLFKWHQGHV
NRQ]HSWXHOOHQ(QWZXUIHVGHU$QZHQGXQJHLQHPJHZLVVHQ5HLIHJUDG
HQWVSUHFKHQXQGJHVLFKHUWVLQGNHKUWGHU'HVLJQHULQGLH
+DXSWPDVNHYRQ26:22']XUFN
,Q26:22'|IIQHWHUGLHHUVWHOOWH,QGH[GDWHLZHOFKHGDV
+DXSWUHVXOWDWVHLQHUYRUJHODJHUWHQ(QWZXUIVDQVWUHQJXQJGDUVWHOOW
XQGHUKlOWHLQHhEHUVLFKWEHUGLHHUVWHOOWHQ'LDJUDPPHPLWGHUHQ
+LOIHHULQGLHYHUVFKLHGHQHQ$QVLFKWHQQDYLJLHUHQNDQQ'LH
HLQ]HOQHQZlKOEDUHQ'LDJUDPPDQVLFKWHQ]HLJHQHLQHVWUXNWXULHUWH
XQGLQWHUSUHWLHUWH'DUVWHOOXQJGHUHQWZRUIHQHQ6DFKYHUKDOWHXQG
ELHWHQHLQH9RUDQVLFKWGHVDXVGHQ(QWZXUIVHQWVFKHLGXQJHQ
UHVXOWLHUHQGHQ6FKHPDGHILQLWLRQVFRGHV
:HUGHQEHLGHU,QWHUSUHWDWLRQGHU+DUG\GDWHLHQ9HUVW|VVHJHJHQGLH
LQGHU0HWKRGH'(,026IHVWJHVHW]WHQ9HUZHQGXQJVUHJHOQGHU
.RQVWUXNWHIHVWJHVWHOOWRGHUPVVHQ(QWZXUIVHQWVFKHLGXQJHQ
DXIJUXQGGHUUHVXOWLHUHQGHQ,PSOLNDWLRQHQEHUDUEHLWHWZHUGHQNDQQ
GHU(QWZHUIHULQGLH'LDJUDPPHQWZXUIVDQVLFKW]XUFNNHKUHQXQG
HQWVSUHFKHQGH$QSDVVXQJHQDQGHQ'LDJUDPPHQYRUQHKPHQ'LH
bQGHUXQJHQZHUGHQLQGHU)ROJHEHLHLQHU1HXHU|IIQXQJGHU,QGH[
RGHU'LDJUDPPGDWHLHQLQ26:22'VLFKWEDU
,VWGHU(QWZHUIHUVFKOLHVVOLFKPLWVHLQHU6FKHPDXQG
$SSOLNDWLRQVGHILQLWLRQ]XIULHGHQNDQQHUYRQ26:22'GLH
HQWVSUHFKHQGHQ6FKHPDGHILQLWLRQVGDWHLHQLQ2&JHQHULHUHQODVVHQ
'DPLWKDWHUVHLQH$UEHLWPLW26:22'EHHQGHW
'LH6FKHPDGHILQLWLRQVGDWHLHQN|QQHQQXQLQGDV'DWHQEDQNV\VWHP
2LPSRUWLHUWYDOLGLHUWXQGQDFK%HOLHEHQDQJHSDVVWZHUGHQ
5.1.2 Starten von OSWOOD
'LH,QVWDOODWLRQYRQ26:22'NDQQGHP$QKDQJHQWQRPPHQ
ZHUGHQ
1DFKGHUHUIROJWHQ,QVWDOODWLRQYJO´,QVWDOODWLRQYRQ26:22'µ6HLWH
ZLUG26:22'GXUFKGDV.OLFNHQDXIGLH3URJUDPPLNRQHJHVWDUWHW
(VHUVFKHLQWGDVIROJHQGH+DXSWIHQVWHU
Diplomarbeit
OSWOOD • 117
Abbildung 5-1: Hauptfenster von OSWOOD
5.1.2.1 OSWOOD Bildschirmbereiche
'DV+DXSWIHQVWHUYRQ26:22'LVWIROJHQGHUPDVVHQ
DXIJHWHLOWYRQREHQQDFKXQWHQ
7LWHO]HLOH
HQWKlOWGLH6WDQGDUGHOHPHQWHYRQ:LQGRZVVRZLHGHQ
1DPHQGHV3URJUDPPHV,VWHLQ'LDJUDPPIHQVWHUJH|IIQHW
XQGPD[LPLHUWWUlJWGLH7LWHO]HLOHZLHGLHVLQDOOHQ
$SSOLNDWLRQHQZHOFKHGLH0',$UFKLWHNWXULPSOHPHQWLHUHQ
GHU)DOOLVW]XVlW]OLFKGLH,QIRUPDWLRQHQEHUGDV
'RNXPHQWHQIHQVWHU
0HQOHLVWH
]HLJWGDVIUHLQHQEHVWLPPWHQ.RQWH[WDNWLYHV)HQVWHU
JOWLJH0HQDQ
:HU]HXJOHLVWH
ELHWHWHLQHQVFKQHOOHQ=XJULIIPLWGHU0DXVDXIKlXILJ
YHUZHQGHWH$NWLRQHQ6lPWOLFKH.RPPDQGRVVLQGDXFKLP
0HQHQWKDOWHQ
'RNXPHQWHQEHUHLFK
,QGLHVHP%HUHLFKZHUGHQGLHYHUVFKLHGHQHQ
'LDJUDPPIHQVWHUDQJH]HLJW
$XVJDEHEHUHLFK
LQIRUPLHUWZlKUHQGHLQHUDXIZHQGLJHQ$NWLRQ]%
,QWHUSUHWDWLRQHLQHU'LDJUDPPGDWHLEHUGHQ)RUWVFKULWWGHU
$XVIKUXQJXQGHWZDLJH8Q]XOlQJOLFKNHLWHQRGHU)HKOHU'LH
DXVJHJHEHQHQ7H[WHEOHLEHQELV]XGHUQlFKVWHQYRP
%HQXW]HUDXVJHO|VWHQOlQJHUHQ9HUDUEHLWXQJLP)HQVWHU
HUKDOWHQXQGN|QQHQDOOHVDPWHLQJHVHKHQZHUGHQ
6WDWXV]HLOH
'LH6WDWXV]HLOHOLHIHUW.XU]LQIRUPDWLRQHQEHUGHQ
9HUDUEHLWXQJVVWDWXVRGHU]HLJWJHJHEHQHQIDOOV+LQZHLVH]X
0HQSXQNWHQDQ
$OOHGLHVH%HUHLFKHVLQGZlKUHQGGHUJDQ]HQ26:22'
6LW]XQJVLFKWEDUXQGZHUGHQLQVEHVRQGHUHYRQGHUDNWXHOO
JH|IIQHWHQ'DWHLQLFKWEHHLQIOXVVW
118 • OSWOOD
Diplomarbeit
5.1.2.2 OSWOOD Benutzeraktionen
26:22'NDQQEHU0HQVXQGGLH:HUN]HXJOHLVWH
JHVWHXHUWZHUGHQ'LH0HQVLP+DXSWIHQVWHUO|VHQGLH
IROJHQGHQ$NWLRQHQDXV
0HQFile
1DFKGHP6WDUWHQYRQ26:22']HLJWVLFKNHLQRIIHQHV
)HQVWHU
,QGLHVHP0HQZLUGQXQGLH0|JOLFKNHLWJHERWHQ
,QGH[GDWHLHQ]X|IIQHQ'HU%HQXW]HUNDQQDXFKHLQHGHU
YLHUOHW]WHQ'DWHLHQZHOFKHLQ26:22'JH|IIQHWZRUGHQ
VLQGDXVGHP0HQDXVZlKOHQ
'XUFK6HOHNWLRQGHU$XVZDKO([LWNDQQGLH6LW]XQJEHHQGHW
ZHUGHQ
0HQView
0LW+LOIHGHU$NWLRQ+DUG\NDQQLQGLH
'LDJUDPPHQWZXUIXPJHEXQJJHZHFKVHOWZHUGHQ
'DV(LQXQG$XVVFKDOWHQGHU$Q]HLJHGHU:HUN]HXJOHLVWH
XQGGHU6WDWXV]HLOHZLUGHEHQIDOOVLQGLHVHP0HQEHKDQGHOW
0HQHelp
'XUFKGLH:DKOGLHVHU$NWLRQZLUGHLQ,QIRUPDWLRQVIHQVWHU
PLW$QJDEHQ]XU9HUVLRQXQG]XGHQ$XWRUHQDQJH]HLJW
5.1.2.3 Starten von Hardy
'LH,QVWDOODWLRQVDQOHLWXQJYRQ+DUG\ILQGHWVLFKLP$QKDQJ
´,QVWDOODWLRQµ6HLWH
+DUG\ZLUGGXUFKHLQ.OLFNHQLQGHU:HUN]HXJOHLVWHDXIGDV+DUG\V\PERO
RGHU:DKOGHU0HQDNWLRQView | HardyJHVWDUWHW
5.2 Schemaentwurf mit Hardy
+DUG\LVWHLQ=HLFKQXQJVZHUN]HXJZHOFKHVDQGHU8QLYHUVLWlW(GLQEXUJK
HQWZLFNHOWZRUGHQLVW(V]HLFKQHWVLFKQHEHQVHLQHUKRKHQ
%HGLHQHUIUHXQGOLFKNHLWYRUDOOHPGXUFKVHLQH)lKLJNHLW]XPVHOEVWlQGLJHQ
(UVWHOOHQYRQ6\PEROELEOLRWKHNHQDXV
'DV3URJUDPPLVWXUKHEHUUHFKWOLFKJHVFKW]WXQGOL]HQ]SIOLFKWLJ'LH
$QELHWHUVWHOOHQDEHUHLQHHLQJHVFKUlQNWH9HUVLRQJUDWLVXQG]XUIUHLHQ
9HUZHQGXQJ]XU9HUIJXQJ'LHVHXQWHUVFKHLGHWVLFKYRQGHU9ROOYHUVLRQ
GXUFKGLH/LPLWLHUXQJGHUPD[LPDOHQ$Q]DKO6\PEROHLQHLQHP'LDJUDPP
XQGGXUFKVWDUNH(LQVFKUlQNXQJHQLQGHU(UVWHOOXQJYRQEHQXW]HUGHILQLHUWHQ
6\PEROELEOLRWKHNHQ
Abbildung 5-2: Copyright Informationen von Hardy
Diplomarbeit
OSWOOD • 119
5.2.1 Arbeiten mit Hardy
5.2.1.1 Hardy Oberfläche
1DFKGHP6WDUWYRQ+DUG\SUlVHQWLHUWVLFKGDV+DXSWIHQVWHU
YRQ+DUG\ZLHIROJW
Abbildung 5-3: Hauptfenster von Hardy
5.2.1.2 Hardy Benutzeraktionen
+DUG\NDQQEHU0HQVXQG7RROEDUEXWWRQVJHVWHXHUW
ZHUGHQ'LH0HQVLP+DXSWIHQVWHUO|VHQGLHIROJHQGHQ
$NWLRQHQDXV
0HQFile
+DUG\ELHWHWQDFKGHP6WDUWHQEHUHLWVHLQHOHHUH,QGH[GDWHL
DQLQZHOFKHUQHXH'LDJUDPPHDXIJHQRPPHQZHUGHQ
N|QQHQ6ROODQHLQHPEHUHLWVHUVWHOOWHQ(QWZXUIZHLWHU
JHDUEHLWHWZHUGHQNDQQGLHVHUGXUFKGLH$NWLRQOpen Index
FileJH|IIQHWZHUGHQ
,P:HLWHUHQELHWHWGLHVHV0HQ$NWLRQHQ]XP6SHLFKHUQXQG
'UXFNHQGHU$UEHLW
'XUFK6HOHNWLRQGHU$XVZDKO([LWNDQQGLH6LW]XQJEHHQGHW
ZHUGHQ+DUG\HUNXQGLJWVLFKREGLHEHDUEHLWHWHQ
'LDJUDPPH]XVSHLFKHUQVLQGIDOOVGLHVHQLFKWVFKRQ
JHVLFKHUWZRUGHQVLQG
0HQCards
'LHVHV0HQELHWHWGLH$NWLRQHQIUGLH0DQLSXODWLRQYRQ
'LDJUDPP.DUWHQDQ,QVEHVRQGHUHHUODXEWHVGXUFK
Create Top CardGLH(U]HXJXQJHLQHUQHXHQ+DXSWNDUWH
$XFK)XQNWLRQHQ]XP$XIILQGHQEHVWLPPWHU.DUWHQRGHU
]XP1HX]HLFKQHQHLQHU$QVLFKWVLQGLQGLHVHU$XVZDKO
HQWKDOWHQ
0HQTools
0LW+LOIHGLHVHV0HQWHLOVZHUGHQGLH'LDJUDPPW\SHQXQG
6\PEROELEOLRWKHNHQYHUZDOWHW
=XGHPN|QQHQGXUFKGLH:DKOYRQPreferencesJHZLVVH
6WDQGDUGHLQVWHOOXQJHQYHUlQGHUWZHUGHQZHOFKHGDV
9HUKDOWHQYRQ+DUG\LP$OOJHPHLQHQEHHLQIOXVVHQ
120 • OSWOOD
Diplomarbeit
,QVEHVRQGHUHNDQQGLH5HJLVWULHUXQJYRUJHQRPPHQZHUGHQ
YJO´5HJLVWULHUXQJµ6HLWH
0HQWindow
%HLGLHVHP0HQKDQGHOWHVVLFKXPHLQ6WDQGDUGPHQIU
GLH1DYLJDWLRQGXUFKGLHYHUVFKLHGHQHQ)HQVWHUXQGGHUHQ
$QRUGQXQJLQQHUKDOEGHU0HKUIHQVWHUDQVLFKWZHOFKHVLQ
QDKH]XDOOHQ:LQGRZV$QZHQGXQJHQILQGHQOlVVW
0HQHelp
0LWGHP+LOIHPHQNDQQLQGLHPLWJHOLHIHUWH+LOIHGDWHL
YHU]ZHLJWZHUGHQLQZHOFKHU]%GXUFK6XFKHLP,QGH[
,QIRUPDWLRQEHUHLQHQEHVWLPPWHQXQNODUHQ%HJULII
EHVFKDIIWZHUGHQ
=XGHPNDQQGXUFKGLH:DKOYRQAbout HardyGHU
+HUVWHOOHUGLDORJYJO$EELOGXQJ6HLWHHLQJHVHKHQ
ZHUGHQ
5.2.2 Schemaentwurf mit Hardy
5.2.2.1 Index und Karten
(LQ(QWZXUILP$OOJHPHLQHQXQGHLQ6FKHPDHQWZXUIPLW
'(,026LP6SH]LHOOHQEHVWHKWDXVPHKUHUHQ'LDJUDPPHQ
'LHVH'LDJUDPPVDPPOXQJHQZHUGHQLQQHUKDOEYRQ+DUG\
DOV,QGH[YHUZDOWHW'LHHLQ]HOQHQ'LDJUDPPHKLQJHJHQ
ZHUGHQDOVVRJHQDQQWH.DUWHQDXIJHIDVVW'DEHLJLOWGDVV
MHGHV'LDJUDPPGXUFKPLQGHVWHQVHLQH.DUWHUHSUlVHQWLHUW
ZLUG/lVVWPDQGDV([SDQGLHUHQYRQ0HWDNRQVWUXNWHQZLH
]%6XEGLDJUDPPHQ]XVRNDQQVLFKHLQ'LDJUDPPDXFK
EHUPHKUHUH.DUWHQHUVWUHFNHQ
=XGHPIRUGHUWGDV(QWZXUIVZHUN]HXJGLHKLHUDUFKLVFKH
6WUXNWXULHUXQJGHUHLQ]HOQHQ$QVLFKWHQ'LHVEHGHXWHWGDVV
PDQDQJHKDOWHQLVWHLQH2EHUNDUWH]XHUIDVVHQ7RSFDUGXQG
YRQGLHVHUDXV9HUNQSIXQJHQ]XZHLWHUHQ8QWHUNDUWHQ
6XEFDUGVHUVWHOOW
6RPLWPXVVPDQZlKUHQGGHU(QWZXUIVDUEHLWVWUHQJ
]ZLVFKHQ,QGH[XQG.DUWHQXQWHUVFKHLGHQ'HU,QGH[HQWKlOW
GLH,QIRUPDWLRQZHOFKH'LDJUDPPHLQGHU6DPPOXQJ
HQWKDOWHQXQGZLHGLHVHXQWHUHLQDQGHUYHUEXQGHQVLQGXQG
VWHOOWGHP%HQXW]HUDQGHU2EHUIOlFKHHLQHQ%DXPIUGLH
1DYLJDWLRQGXUFKGLH.DUWHQ]XU9HUIJXQJ'LH.DUWH
KLQJHJHQLVWHLQH$QVLFKWHLQHV'LDJUDPPVXQGZLUGVRPLW
DP%LOGVFKLUPLQ)RUPHLQHVHLJHQHQ)HQVWHUVDQJH]HLJW
5.2.2.2 Dateistruktur von Hardy
+DUG\NHQQWDOVR]ZHL$UWHQYRQ'DWHLHQGLH,QGH[GDWHLXQG
'LDJUDPPGDWHLHQ'LH,QGH[GDWHLVSHLFKHUWGLH,QIRUPDWLRQ
EHUGLHHQWKDOWHQHQ.DUWHQLQVEHVRQGHUHGLH
HQWVSUHFKHQGHQ'DWHLQDPHQZlKUHQGLQGHQ
'LDJUDPPGDWHLHQVlPWOLFKH,QIRUPDWLRQHQEHUGLH
JH]HLFKQHWHQ(OHPHQWHDEJHOHJWVLQG(OHPHQWLQIRUPDWLRQHQ
VLQGQHEHQGHQJUDSKLVFKHQ$QJDEHQIUGHUHQ
5HSUlVHQWDWLRQDP%LOGVFKLUPDXFKGLH
GLDJUDPPVSH]LILVFKHQ'DWHQEHU1DPHXQG7\SGHV
(OHPHQWHVXQGGLHYRP%HQXW]HU]XVlW]OLFKHUIDVVWHQ
(LJHQVFKDIWHQ
Diplomarbeit
OSWOOD • 121
5.2.3 Schemaentwurf mit DEIMOS
$OVHUVWHVPXVVHLQH+DXSWNDUWHHU]HXJWZHUGHQ'LHVZLUGGXUFKGLH
:DKOGHV0HQSIDGHVCard | Create Top CardLQLWLLHUW+DUG\ELHWHW
LQHLQHP'LDORJVlPWOLFKH]XU9HUIJXQJVWHKHQGHQ.DUWHQW\SHQDQ
ZHOFKHDOV+DXSWNDUWHQLQ)UDJHNRPPHQN|QQHQ
Abbildung 5-4: Die Diagrammtypen von DEIMOS
'(,026VFKOlJWYRUDOV+DXSWNDUWHGDV.RQWH[WGLDJUDPP]X
ZlKOHQ
5.2.4 Erstellen eines Kontextdiagramms
1DFKGHU$XVZDKOGHV.RQWH[WGLDJUDPPHVDOV+DXSWNDUWHZLUGGHU
IROJHQGH%LOGVFKLUPGDUJHVWHOOW
Abbildung 5-5: Kartenansicht in Hardy
'LH0HQVZHUGHQLQGLHVHU$QVLFKWQHXRUJDQLVLHUWXQGO|VHQGLH
IROJHQGHQ$NWLRQHQDXV
0HQFile
ELHWHW$NWLRQHQIUGDV6SHLFKHUQgIIQHQXQG'UXFNHQGHU
'LDJUDPPNDUWHDQ
'LH'LDJUDPPDQVLFKWNDQQGXUFKGLH:DKOYRQQuit CardYHUODVVHQ
ZHUGHQ
0HQEdit
%HLQKDOWHW$NWLRQHQIUGDV6HOHNWLHUHQ'HVHOHNWLHUHQ.RSLHUHQ
122 • OSWOOD
Diplomarbeit
$XVVFKQHLGHQXQG(LQIJHQYRQ'LDJUDPPHOHPHQWHQ
(OHPHQWHN|QQHQEHUGLHVHV0HQIRUPDWLHUWZHUGHQLQGHP
EHLVSLHOVZHLVHGLH%HVFKULIWXQJHQ(LJHQVFKDIWHQ6FKULIWDUWHQXVZ
JHlQGHUWZHUGHQ
6ROOHLQEHVWLPPWHV(OHPHQW]XHLQHUQHXHQ$QVLFKWH[SDQGLHUW
ZHUGHQNDQQGHU3XQNWHNew ExpansionJHZlKOWZHUGHQ
0DQLayout
(UODXEWGLH$OOLQLHUXQJPHKUHUHUVHOHNWLHUWHU(OHPHQWHQDFK
EHVWLPPWHQ.ULWHULHQ=XGHPLVWLQGLHVHP0HQGLH
9HUJU|VVHUXQJVE]Z9HUNOHLQHUXQJVP|JOLFKNHLWZoom
LPSOHPHQWLHUW
0HQHyperlinks
6SUQJH]XDQGHUHQ(OHPHQWHQRGHUDQGHUHQ$QVLFKWHQN|QQHQPLW
+LOIHGLHVHV0HQVNRQILJXULHUWZHUGHQ'DUEHUKLQDXVODVVHQVLFK
YHUVFKLHGHQH.RQWUROOHOHPHQWHZLHHWZDGLH3DOHWWHRGHUGLH
:HUN]HXJOHLVWHHLQE]ZDXVEOHQGHQ
'LHZHLWHUHQ0HQVWindowXQGHelpXQWHUVFKHLGHQVLFKQLFKWYRQ
GHQMHQLJHQGHV+DXSWIHQVWHUV
5.2.4.1 Zeichenelemente
*OHLFKQDFKGHP$XIEDXGHVOHHUHQ'LDJUDPPIHQVWHUVZLUGHLQH3DOHWWH
DQJH]HLJWZHOFKHGLH]XU$XVZDKOVWHKHQGHQJUDILVFKHQ.RQVWUXNWHIU
GLHVHV'LDJUDPPDQELHWHW
(LQJHZQVFKWHV(OHPHQWZLUGLQ]ZHL6FKULWWHQDXIGDV
=HLFKHQEODWWEHUWUDJHQ
6HOHNWLRQGHV(OHPHQWHVPLWGHUOLQNHQ0DXVWDVWHDXIGHU
3DOHWWH
3RVLWLRQLHUXQJGXUFKHLQIDFKHQ0DXVNOLFNPLWGHUOLQNHQ
0DXVWDVWHDXIGHU'LDJUDPPNDUWH
(OHPHQWHGLHVLFKEHUHLWVDXIGHP=HLFKHQEODWWEHILQGHQ
N|QQHQGXUFKGLHEOLFKHQ0DXVDNWLRQHQRGHUGXUFK
0HQEHIHKOHYHUVFKREHQLQGHU*U|VVHDQJHSDVVWRGHU
JHO|VFKWZHUGHQ=XGHPELHWHW+DUG\HLQH5HLKHYRQ
)XQNWLRQHQDQGLHLQGHU:HUN]HXJOLVWHRGHUDXVGHP0HQ
DQJHVSURFKHQZHUGHQN|QQHQXPHLQRGHUPHKUHUH
(OHPHQWHJHJHQHLQDQGHURGHUDXIGHP%ODWWDXV]XULFKWHQ
5.2.4.2 Knoten
)UGLH(UVWHOOXQJHLQHV.RQWH[WGLDJUDPPVVWHKHQGLH
IROJHQGHQ.QRWHQ]XU$XVZDKO
Konstrukt
Eigenschaften
6FKHPDGLDJUDPP
Name EHOLHELJH %H]LHFKXQJ
7UDQVDNWLRQVGLDJUDP
Name EHOLHELJH %H]HLFKXQJ
Tabelle 5-1: Knoten in einem Kontextdiagramm
'DV.RQWH[WGLDJUDPPVWHKWDXVVFKOLHVVOLFKDOV
hEHUVLFKWVGLDJUDPPGDGHVVHQ,QIRUPDWLRQHQGLH'HILQLWLRQ
GHV6FKHPDVQLFKWEHHLQIOXVVW(VLVWDOVRQLFKWQ|WLJGLH
HLQ]HOQHQ.QRWHQGXUFK.DQWHQ]XYHUELQGHQ$XVGLHVHP
Diplomarbeit
OSWOOD • 123
*UXQGZHUGHQDXIGLHVHU'LDJUDPPSDOHWWHDXFKNHLQH
.DQWHQNRQVWUXNWHDQJHERWHQ
5.2.4.3 Beispiel FIS
,PNRQNUHWHQ)DOON|QQWHHLQ.RQWH[WGLDJUDPPZLHIROJW
DXVVHKHQ
Abbildung 5-6: Beispiel eines Kontextdiagramms
5.2.5 Erstellen eines Schemadiagramms
8PHLQ6FKHPDGLDJUDPP]XHUVWHOOHQZLUGYRQ'(,026
YRUJHVFKODJHQHLQHQ.QRWHQYRP7\S6FKHPDGLDJUDPP]X
H[SDQGLHUHQ'D]XPXVVGHP0HQSIDGHyperlinks | Hyperlink New
CardJHIROJWXQGLPDQVFKOLHVVHQGDQJH]HLJWHQ'LDORJYOJ
$EELOGXQJ6HLWHGHQ'(,0267\SSchema Diagram
JHZlKOWZHUGHQ
5.2.5.1 Zeichenelemente
'LHLQHLQHP6FKHPDGLDJUDPP]XU9HUIJXQJVWHKHQGHQ=HLFKHQHOHPHQWH
ZHUGHQDXIGHUQHEHQVWHKHQGHQ3DOHWWHDQJH]HLJW'LH$XVZDKOLVWLQ
.QRWHQ(OHPHQWHXQG.DQWHQ(OHPHQWYHUELQGHUXQWHUWHLOW
'DV3RVLWLRQLHUHQGHU.RQVWUXNWHDXIGHP=HLFKHQIHQVWHUZXUGHEHUHLWVLP
YRULJHQ$EVFKQLWWHUOlXWHUWZlKUHQGGLHEHLGHQQRWZHQGLJHQ6FKULWWHIU
GDV(LQULFKWHQHLQHU9HUELQGXQJ]ZLVFKHQ]ZHL.QRWHQNXU]HUNOlUWZHUGHQ
VROO
6HOHNWLRQGHVJHZQVFKWHQ.DQWHQW\SVDXIGHU3DOHWWH
9HUELQGXQJYRQ.QRWHQGXUFK=LHKHQGHU0DXVZlKUHQG
GLHUHFKWH0DXVWDVWHJHGUFNWEOHLEW'UDJ'URS
5.2.5.2 Knoten
)UGLH(UVWHOOXQJHLQHV6FKHPDGLDJUDPPVVWHKHQGLH
IROJHQGHQ.QRWHQ]XU$XVZDKO
Konstrukt
'DWHQEDQNNODVVH
124 • OSWOOD
Attribute
class name
properties
1DPH GHU .ODVVH
(LJHQVFKDIWHQ
Diplomarbeit
+LOIVNODVVH
(LQVWLHJVSXQNW
class name
properties
class name
properties
name
1DPH GHU .ODVVH
(LJHQVFKDIWHQ
1DPH GHU .ODVVH
(LJHQVFKDIWHQ
3HUVLVWHQWHU 1DPH
1RWL]
note
1RWL]
DEVWUDNWH .ODVVH
Tabelle 5-2: Knotenkonstrukte in einem Schemadiagramm
'LHDQJHJHEHQHQ.ODVVHQQDPHQPVVHQGLDJUDPPZHLW
HLQGHXWLJVHLQ'LH(LJHQVFKDIWHQpropertiesHLQHU
.ODVVHEHVFKUHLEHQ0HWKRGHQ$WWULEXWH6FKOVVHOXQG
.RQVLVWHQ]EHGLQJXQJHQ-HGH'HILQLWLRQPXVVDXIHLQHU
QHXHQ=HLOHLP(LQJDEHIHOGIUGDV.QRWHQDWWULEXWJHVHW]W
ZHUGHQ
'DPLW26:22'VRYLHO,QIRUPDWLRQZLHP|JOLFKDXV
GLHVHQ$QJDEHQKHUDXVOHVHQXQGIUGLH8PVHW]XQJYJO
´8PVHW]XQJHLQHV6FKHPDGLDJUDPPVµ6HLWHYHUZHQGHQ
NDQQVROOHQGLH.ODVVHQHLJHQVFKDIWHQHLQHPEHVWLPPWHQ
6\QWD[IROJHQ
0HWKRGHQGHILQLWLRQHQVLQGLQGHU)RUP
[W|R] Name([ParamName:ParamType[,
ParamName:ParamType]*])[:Type]
]XHUIDVVHQ:LUGDXIGLH$QJDEHGHV=XJULIIVW\SV: :ULWH
5 5HDGYHU]LFKWHWZLUGHLQHOHVHQGH0HWKRGH
DQJHQRPPHQ/lVVWPDQGLH'HILQLWLRQGHV7\SVZHJQLPPW
26:22'DQGLHVH)XQNWLRQUHWRXUQLHUHHLQHQERRO·VFKHQ
:HUW
'LHH[SOL]LWGHILQLHUWHQ$WWULEXWHVROOHQLQGHU)RUP
AttributeName[:AttributeType[=[Default]]]
DXIJHVFKULHEHQVHLQ'DV:HJODVVHQGHV7\SVIKUW]XU
VWDQGDUGPlVVLJHQ'HILQLWLRQDOV=HLFKHQNHWWH*LEWPDQ
HLQHQ6WDQGDUGZHUWIUGDV$WWULEXWDQZLUG26:22'
GDIUVRUJHQGDVVHVEHLGHU(U]HXJXQJHLQHV2EMHNWHVDXI
GLHVHQ:HUWLQLWLDOLVLHUWZLUG:LUGGHU:HUWZHJJHODVVHQ
DEHUGDV*OHLFKKHLWV]HLFKHQDQJHJHEHQVRLVWGLHVHV$WWULEXW
DOVLQLWLDOLVLHUXQJVQRWZHQGLJJHNHQQ]HLFKQHW(LQ2EMHNW
NDQQDOVRQXUQRFKGDQQHU]HXJWZHUGHQZHQQJOHLFK]HLWLJ
LQGHULPSOL]LWHQ,QLW0HWKRGHGLHVHP$WWULEXWHLQ:HUW
]XJHZLHVHQZLUG
6ROOHQORNDOH([WHQVLRQHQEH]JOLFKHLQHV6FKOVVHONULWHULXPV
HLQGHXWLJGHILQLHUWZHUGHQNDQQGLHVGXUFKGLH$QJDEHHLQHV
6FKOVVHOVGHU)RUP
ClassName<AttributeName [, AttributeName]*>
GHILQLHUWZHUGHQ'DEHLPXVVVLFKHUJHVWHOOWVHLQGDVVGLH
([WHQVLRQ]XGHUDQJHJHEHQHQ.ODVVHClassNameDXFK
WDWVlFKOLFKHLQH.RPSRQHQWHQEH]LHKXQJXQWHUKlOW6LQGGLH
LP6FKOVVHONULWHULXPHQWKDOWHQHQ$WWULEXWHLQGHU
.RPSRQHQWHQLFKWHQWKDOWHQZHUGHQVLHYRQ26:22'
LPSOL]LWHU]HXJW
,QYDULDQWH.RQVLVWHQ]EHGLQJXQJHQZHUGHQLQGHU)RUP
{ConstraintString}
Diplomarbeit
OSWOOD • 125
IRUPXOLHUW26:22'YHUSDFNWEHLGHU8PVHW]XQJGLH
DQJHJHEHQH%HGLQJXQJLQHLQHif$QZHLVXQJRKQHZHLWHUH
9DOLGLHUXQJHQZLH7\SHQSUIXQJHWFGXUFK]XIKUHQ
5.2.5.3 Kanten
)UGLH(UVWHOOXQJHLQHV6FKHPDGLDJUDPPVVWHKHQGLH
IROJHQGHQ.DQWHQ]XU$XVZDKO
Konstrukt
Attribute
9HUHUEXQJ
NHLQH
,QVWDQWLLHUXQJ
NHLQH
.RPSRQHQWHQ
(YROXWLRQ
name
cardinality
inverse
name
begin
end
name
cardinality
function
1RWL]EH]XJ
NHLQH
EH]LHKXQJ
LQYHUVH %H]LHKXQJ
%HREDFKWXQJV
EH]LHKXQJ
%H]HLFKQXQJ
.DUGLDQOLWlWVDQJDEH
UFNEH]JOLFKH .DUGDQJDEH
%H]HLFKQXQJ
.DUGLDQOLWlWVDQJDEH
UFNEH]JOLFKH .DUGDQJDEH
%H]HLFKQXQJ
.DUGLDQOLWlWVDQJDEH
1DPH GHU (YROXWLRQVPHWKRGH
Tabelle 5-3: Kantenkonstrukte in einem Schemadiagramm
5.2.5.4 Verbindungsmatrix
'DV=HLFKQXQJVZHUN]HXJ+DUG\ELHWHWEHUHLWVYHUVFKLHGHQH
YRUJHJHEHQHXQGGHILQLHUEDUH(LQVFKUlQNXQJHQIUGDV
=HLFKQHQYRQ.DQWHQ
=XGHQYRUJHJHEHQHQ(LQVFKUlQNXQJHQ]lKOWGDVVHLQH
9HUELQGXQJDXVVFKOLHVVOLFK]ZLVFKHQ]ZHL.QRWHQ
HLQJHULFKWHWZHUGHQXQG]XGHP]ZLVFKHQ]ZHL.QRWHQQXU
JHQDXHLQH9HUELQGXQJHLQHVJHZLVVHQ7\SVJH]HLFKQHW
ZHUGHQNDQQ
%HLGHU'HILQLWLRQYRQ'LDJUDPPW\SHQLVWGHP%HQXW]HUGLH
0|JOLFKNHLWJHJHEHQ(LQVFKUlQNXQJHQIUGLH9HUZHQGXQJ
HLQHVEHVWLPPWHQ.DQWHQNRQVWUXNWHV]XHUIDVVHQ)UGDV
6FKHPDGLDJUDPPVHLHQGLHVH(LQVDW]UHJHOQLQHLQHU0DWUL[
]XVDPPHQJHIDVVW
126 • OSWOOD
Diplomarbeit
Tabelle 5-4: Matrix der möglichen Knotenverbindungen in einem
Schemadiagramm
$XVGLHVHU'DUVWHOOXQJOlVVWVLFKOHLFKWHUNHQQHQGDVV
9HUHUEXQJ]ZLVFKHQDOOHQ7\SHQYRQ.ODVVHQ]XJHODVVHQLVW
'LH,QVWDQWLLHUXQJLVWHLQ]LJIUGLH9HUELQGXQJHLQHV
(LQVWLHJVSXQNWHVPLWHLQHU'DWHQEDQNNODVVHYRUJHVHKHQXQG
GDUIQLHDOV=LHOHLQHU9HUELQGXQJDXIWUHWHQ'LH1RWL]NQRWHQ
VLQGLPPHUGHU$XVJDQJVSXQNWHLQHV1RWL]EH]XJHVHVVHL
GHQQHVZUGHQ1RWL]HQNRPPHQWLHUW
5.2.5.5 Beispiel FIS
,PNRQNUHWHQ)DOON|QQWHHLQ6FKHPDGLDJUDPPZLHIROJW
DXVVHKHQ
Abbildung 5-7: Beispiel eines Schemadiagramms
5.2.6 Erstellen eines Transaktionsdiagramms
8PHLQ6FKHPDGLDJUDPP]XHUVWHOOHQZLUGYRQ'(,026
YRUJHVFKODJHQLQQHUKDOEHLQHV.RQWH[WGLDJUDPPHVHLQHQ.QRWHQ
YRP7\S7UDQVDNWLRQVGLDJUDPP]XH[SDQGLHUHQ'D]XPXVV
LQQHUKDOEGHV.RQWH[WGLDJUDPPVHLQHQWVSUHFKHQGHV(OHPHQW
VHOHNWLHUWGHP0HQSIDGHyperlinks | Hyperlink New CardJHIROJW
XQGLPDQVFKOLHVVHQGDQJH]HLJWHQ'LDORJYOJ$EELOGXQJ6HLWH
GHQ'(,0267\STransaction DiagramJHZlKOWZHUGHQ
5.2.6.1 Zeichenelemente
Diplomarbeit
OSWOOD • 127
'LHLQHLQHP6FKHPDGLDJUDPP]XU9HUIJXQJVWHKHQGHQ=HLFKHQHOHPHQWH
ZHUGHQDXIGHUQHEHQVWHKHQGHQ3DOHWWHDQJH]HLJW'LH$XVZDKOLVWLQ
.QRWHQXQG.DQWHQXQWHUWHLOW
5.2.6.2 Knoten
)UGLH(UVWHOOXQJHLQHV7UDQVDNWLRQVGLDJUDPPVVWHKHQGLH
IROJHQGHQ.QRWHQ]XU$XVZDKO
Konstrukt
Attribute
+DXSWSURJUDPP
name
+DXSWSURJUDPPQDPH
6XEV\VWHP
name
1DPH GHV 6XEV\VWHPV
3URJUDPP
name
pseudo code
name (params) return
pseudo code
name (params) return
pseudo code
1DPH GHV 3URJUDPPHV
7H[WXHOOH $EODXIEHVFKUHLE
)XQNWLRQ
)XQNWLRQVQDPH
7H[WXHOOH $EODXIEHVFKUHLE
7UDQVDNWLRQ
7UDQVDNWLRQVQDPH
7H[WXHOOH $EODXIEHVFKUHLE
Tabelle 5-5: Knotenkonstrukte in einem Transaktionsdiagramm
'LHDQJHJHEHQHQ1DPHQGHUHLQ]HOQHQ.RQVWUXNWHPVVHQ
GLDJUDPPZHLWHLQGHXWLJVHLQ%HL)XQNWLRQHQXQG
7UDQVDNWLRQHQZHUGHQLQGHQ1DPHQGLH
$XIUXINRQYHQWLRQHQPLWDQJHJHEHQ'LHVHPVVHQLQGHU
)RUP
Name([ParamName:ParamType[,
ParamName:ParamType]*])[:Type]
QRWLHUWVHLQ
5.2.6.3 Kanten
)UGLH(UVWHOOXQJHLQHV7UDQVDNWLRQVGLDJUDPPVVWHKW
OHGLJOLFKHLQH.DQWH]XU$XVZDKO
Konstrukt
Attribute
$XIUXI
number
6HTXHQ]QXPPHU IU GLH
$XIUXIUHLKHQIROJH
Tabelle 5-6: Kantenkonstrukte in einem Transaktionsdiagramm
5.2.6.4 Verbindungsmatrix
'LH(OHPHQWHHLQHV7UDQVDNWLRQVGLDJUDPPVN|QQHQXQWHU
%HUFNVLFKWLJXQJGHUEHUHLWVHUZlKQWHQ(LQVFKUlQNXQJHQIU
GDV=HLFKQHQYRQ9HUELQGXQJVOLQLHQ]ZLVFKHQ.QRWHQ
JHPlVVGHUIROJHQGHQ0DWUL[PLWHLQDQGHUYHUEXQGHQZHUGHQ
128 • OSWOOD
Diplomarbeit
Tabelle 5-7: Matrix der möglichen Knotenverbindungen in einem
Transaktionsdiagramm
%HLGHUJHQDXHUHQ%HWUDFKWXQJGHU9HUELQGXQJVPDWUL[IlOOW
DXIGDVVNHLQH$XIUXIH]X+DXSWSURJUDPPHQ]XJHODVVHQ
VLQG0|FKWHPDQWURW]GHPPHKUHUH+DXSWSURJUDPPH
HQWZHUIHQVRPXVVPDQMHHLQH'LDJUDPPNDUWHDOV
([SDQVLRQHLQHV7UDQVDNWLRQVNQRWHQVLP.RQWH[WGLDJUDPP
]X+LOIHQHKPHQ
=XGHPOlVVWVLFKDXVGHU0DWUL[HUNHQQHQGDVVYRQ
7UDQVDNWLRQHQDXVNHLQHZHLWHUHQ9HUELQGXQJHQPHKUHUODXEW
VLQG'LH7UDQVDNWLRQELOGHWDOVRLQGLHVHU$QVLFKWGDV%ODWW
GHV$XIUXIEDXPHV
5.2.6.5 Beispiel FIS
,PNRQNUHWHQ)DOON|QQWHHLQ7UDQVDNWLRQVGLDJUDPPZHOFKHV
YHUVFKLHGHQH6XEV\VWHPHHQWKlOWZLHIROJWDXVVHKHQ
Abbildung : Beispiel eines Transaktionsdiagramms (Systemübersicht)
'LHHWZDVVWlUNHUH6WULFKEUHLWHPLWZHOFKHUHLQ(OHPHQW
JH]HLFKQHWLVWZHLVWGDUDXIKLQGDVVHVVLFKXPHLQ
H[SDQGLHUEDUHV2EMHNWKDQGHOW'LH([SDQVLRQIUGDV
6XEV\VWHPÅ0LWDUEHLWHU9HUZDOWXQJ´ZLUGLQGHUQlFKVWHQ
$EELOGXQJYHUDQVFKDXOLFKW
Diplomarbeit
OSWOOD • 129
Abbildung 5-8: Beispiel eines Transaktionsdiagramms (Subsystemexpandsion)
5.3 Code generieren mit OSWOOD
1DFKGHPGDV'DWHQEDQNVFKHPDGXUFKYHUVFKLHGHQH'LDJUDPPHHQWZRUIHQ
LVWVROOHQPLW+LOIHYRQ26:22'GLHHQWVSUHFKHQGHQ$QZHLVXQJHQLQGHU
6FKHPDGHILQLWLRQVVSUDFKHJHQHULHUWZHUGHQ
=XGLHVHP=ZHFNPVVHQGLHHUVWHOOWHQ'LDJUDPPGDWHLHQLQ26:22'
JH|IIQHWZHUGHQZDVLPSOL]LW]XGHU,QWHUSUHWDWLRQGHUJH]HLFKQHWHQ
,QIRUPDWLRQIKUWXQGGXUFK6SHLFKHUXQJDOV2'/'DWHLLQ
6FKHPDGHILQLWLRQVVSUDFKHEHUIKUWZHUGHQ*H|IIQHWZHUGHQN|QQHQ]XP
HLQHQGLUHNWGLHYRQ+DUG\HU]HXJWHQ'LDJUDPPGDWHLHQGLDRGHU]XP
DQGHUHQGLH,QGH[GDWHLHQYRQGHQHQDXVGXUFKGLHYHUVFKLHGHQHQ
'LDJUDPPW\SHQQDYLJLHUWZHUGHQNDQQ
1DFKIROJHQGVHLGHU$EODXIEHVFKUHLEHQZHOFKHUYRQGHU$QQlKHUXQJ
PLWWHOVGHU,QGH[LQIRUPDWLRQDXVJHKWXQGVHLQHV7RS'RZQ$QVDW]HV
ZHJHQVDXFKJHJHQEHUGHQGLUHNWHQ$QVlW]HQYRUJH]RJHQZHUGHQVROOWH
5.3.1 Anzeige der Indexdatei
'XUFKGLH:DKOGHU6FKDOWIOlFKH DXVGHU:HUN]HXJOHLVWHRGHU
GXUFKGLH6HOHNWLRQGHV0HQSIDGHVFile | OpenZLUGGHUIROJHQGH
'LDORJ]XU$XVZDKOGHUJHZQVFKWHQ,QGH[GDWHLDQJH]HLJW
130 • OSWOOD
Diplomarbeit
Abbildung 5-9: Auswahl einer Indexdatei in OSWOOD
1DFKGHU:DKOHLQHUEHVWHKHQGHQ,QGH[GDWHLZLUGGLHVHLQWHUSUHWLHUW
XQGGHUIROJHQGH,QGH[EDXPlKQOLFKGHU1DYLJDWLRQVLQIRUPDWLRQLQ
+DUG\DQJH]HLJW
Abbildung 5-10: Darstellung einer Indexdatei von Hardy in OSWOOD
26:22'OLVWHWEDXPDUWLJVlPWOLFKH'LDJUDPPHDXIZHOFKHLQGHU
JHJHEHQHQ,QGH[GDWHLJHIXQGHQZHUGHQNRQQWHQ(VZHUGHQDOVR
DXFK'LDJUDPPHDQJH]HLJWGLHQLFKWLQGHU0HWKRGH'(,026
YRUJHVHKHQVLQG
)UGLH'DUVWHOOXQJZHUGHQGLHIROJHQGHQ6\PEROHYHUZHQGHW
6FKHPDGLDJUDPP
7UDQVDNWLRQVGLDJUDPP
.RQWH[WGLDJUDPP RGHU QLFKW EHNDQQWHV 'LDJUDPP
Tabelle 5-8: Diagrammtypen in einer Indexdatei
5.3.1.1 Inhalt einer Indexdatei
(LQH,QGH[GDWHLEHVWHKWLQGHU5HJHODXV
• JHQDX.RQWH[WGLDJUDPP
• JHQDX6FKHPDGLDJUDPP
• JHQDX7UDQVDNWLRQVGLDJUDPP'LHVHVNDQQGXUFK
6XEV\VWHPH[SDQVLRQDXVEHOLHELJYLHOHQYHUVFKDFKWHOWHQ
7UDQVDNWLRQVGLDJUDPPHQEHVWHKHQ
'DV.RQWH[WGLDJUDPPLVWGHU9DWHUGHUDQGHUHQ'LDJUDPPH
GLH9HUZHLVHDXIGLH6XEGLDJUDPPHVLQGDEHUQLFKWLQGHU
.RQWH[WGLDJUDPPGDWHLJHVSHLFKHUWVRQGHUQLQGHU
,QGH[GLDJUDPPGDWHL
5.3.1.2 Benutzeraktionen
'XUFKHLQHQ'RSSHONOLFNPLWGHUOLQNHQ0DXVWDVWHEHU
HLQHP%DXPHOHPHQWODVVHQVLFKGLHHQWVSUHFKHQGHQ
6XEGLDJUDPPHQlKHUEHWUDFKWHQ26:22'LPSOHPHQWLHUW
QXUGLH$QVLFKWHQIUGLH6FKHPDXQGGLH
7UDQVDNWLRQVGLDJUDPPH:HLWHUH'LDJUDPPW\SHQ
LQVEHVRQGHUHDXFKGDV.RQWH[WGLDJUDPPN|QQHQQLFKW
Diplomarbeit
OSWOOD • 131
LQWHUSUHWLHUWZHUGHQZHVKDOEVLHLQGHU,QGH[DQVLFKWGXUFK
HLQH)UDJH]HLFKHQLNRQHGDUJHVWHOOWVLQG
5.3.2 Anzeige des Schemadiagramms
,VWLQQHUKDOEGHU1DYLJDWLRQVDQVLFKWGHU,QGH[GDWHLHLQ
6FKHPDGLDJUDPPJHZlKOWRGHUGXUFKGLHFile | Open$NWLRQJH|IIQHW
ZRUGHQZLUGGLH,QIRUPDWLRQGHU'LDJUDPPGDWHLXQWHUVXFKWXQG
LQWHUSUHWLHUW
:lKUHQGGHU,QWHUSUHWDWLRQZHUGHQYHUVFKLHGHQH9DOLGLHUXQJHQ
GXUFKJHIKUW=XXQWHUVFKHLGHQVLQGGDEHL.RQGLWLRQHQZHOFKHGLH
PHWKRGLVFKH.RUUHNWKHLWGHV'LDJUDPPVLP6LQQHYRQ'(,026
SUIHQXQG9DOLGLHUXQJHQZHOFKHDXIGLHYRP(QWZHUIHUHUIDVVWHQ
$WWULEXWHDXVJHIKUWZHUGHQ9HUOHW]WHLQ'LDJUDPPHLQH]ZLQJHQGH
$QIRUGHUXQJYRQ'(,026EHLVSLHOVZHLVHZHQQHLQ=\NOXVLQGHU
9HUHUEXQJVKLHUDUFKLHHQWGHFNWZLUGZLUGGLH9HUDUEHLWXQJXQWHU
$XVJDEHHLQHUHQWVSUHFKHQGHQ%HQXW]HUEHQDFKULFKWLJXQJ
XQYHU]JOLFKDEJHEURFKHQZlKUHQGEHLHLQHPV\QWDNWLVFKHQ)HKOHU
LQEHLVSLHOVZHLVHHLQHU$WWULEXWGHILQLWLRQOHGLJOLFKDOV:DUQXQJLP
$XVJDEHEHUHLFKGHV+DXSWIHQVWHUVDQJH]HLJWZLUG'LH6DFKYHUKDOWH
ZHOFKH]X)HKOHUPHOGXQJHQRGHU:DUQXQJHQIKUHQZHUGHQLP
,PSOHPHQWDWLRQVNDSLWHOYJO´,PSOHPHQWDWLRQµ6HLWHHLQJHKHQG
GLVNXWLHUW
1DFKYROOVWlQGLJHUXQGIHKOHUIUHLHQ9HUDUEHLWXQJZLUGGLH'DWHLLP
6FKHPDGLDJUDPPELOGVFKLUPGDUJHVWHOOW
Abbildung 5-11: Darstellung eines Schemadiagramms in OSWOOD
1HEHQGHQIUDOOH$QVLFKWHQJHPHLQVDPHQ%LOGVFKLUPEHUHLFKHQ
YJO´26:22'%LOGVFKLUPEHUHLFKHµ6HLWHZHUGHQIUGLH
$Q]HLJHHLQHU6FKHPDGLDJUDPPGDWHLYLHUZHLWHUHHU|IIQHW'LHVVLQG
YRQREHQOLQNVQDFKXQWHQUHFKWV
• .RPSRQHQWHQEDXP
• 9HUHUEXQJVKLHUDUFKLH
• .ODVVHQGDUVWHOOXQJ
• 2'/$QVLFKW
132 • OSWOOD
Diplomarbeit
'LHHLQ]HOQHQ$QVLFKWHQODVVHQVLFKLQGHU*U|VVHDQSDVVHQZlKUHQG
LKUH3RVLWLRQDXIGHP%LOGVFKLUPQLFKWJHlQGHUWZHUGHQNDQQ
5.3.2.1 Der Komponentenbaum
,QGHU.RPSRQHQWHQDQVLFKWZHUGHQGLHLP6FKHPD
GHILQLHUWHQ.ODVVHQEH]JOLFKLKUHU
.RPSRQHQWHQEH]LHKXQJHQYLVXDOLVLHUW'LHVH$QVLFKWLVWYRU
DOOHPIUGLH8QWHUVXFKXQJGHU3HUVLVWHQ]IRUWSIODQ]XQJYRQ
JURVVHU%HGHXWXQJ
Abbildung 5-12: Komponentenbaum eines Schemadiagrammes
-HGHLP6FKHPDGLDJUDPPHQWKDOWHQH.ODVVHZLUGLQGLHVH
$QVLFKWDXIJHQRPPHQXQGPLWHLQHPW\SHQVSH]LILVFKHQ
6\PEROFKDUDNWHULVLHUW'LHHLQ]HOQHQ6\PEROHVLQGZLHIROJW
GHQ%DVLVW\SHQ]XJHRUGQHW
([SOL]LW GHILQLHUWHU (LQVWLHJVSXQNW DOV ,QVWDQ] HLQHU 'DWHQEDQNNODVVH
'DWHQEDQNNODVVH
$EVWUDNWH .ODVVH
+LOIVNODVVH
Tabelle 5-9: Die Klassensymbole im Komponentenbaum
'LH0HWKRGH'(,026IRUGHUWGDVVMHGH.ODVVHGLH
SHUVLVWHQWH,QVWDQ]HQDXVELOGHQNDQQDOV.RPSRQHQWHGHV
H[SOL]LWHQ(LQVWLHJVSXQNWHV]XGHILQLHUHQLVW+LOIVNODVVHQ
RGHUDEVWUDNWH.ODVVHQGUIHQGHPQDFKQLFKWDOV
6XEHOHPHQWHGHV(LQVWLHJVSXQNWHVDXIWUHWHQ'LHVOlVVWVLFK
GDQNGHUEDXPDUWLJHQ'DUVWHOOXQJGHU.RPSRQHQWHQDQVLFKW
OHLFKWEHUSUIHQ
5.3.2.2 Die Vererbungshierarchie
,QGHU9HUHUEXQJVKLHUDUFKLHVLQGGLH9HUHUEXQJVEH]LHKXQJHQ
]ZLVFKHQGHQYHUVFKLHGHQHQ.ODVVHQEDXPDUWLJGDUJHVWHOOW
Abbildung 5-13: Vererbungshierarchie in einem Schemadiagramm
'DLQGHPEHWUDFKWHWHQ'DWHQEDQNV\VWHP
0HKUIDFKYHUHUEXQJ]XJHODVVHQLVWPXVVGLH
9HUHUEXQJVKLHUDUFKLHDOV*UDSKDQJHVHKHQZHUGHQ'HU
*UDSKMHGRFKLVWJHULFKWHWXQG]\NOHQIUHLZHVKDOEHU
WURW]GHPDOV%DXPLQZHOFKHPHLQEHVWLPPWHVDQHLQHU
0HKUIDFKYHUHUEXQJEHWHLOLJWHV(OHPHQWDQPHKUHUHQ
3RVLWLRQHQDXIWULWWGDUJHVWHOOWZHUGHQNDQQ
5.3.2.3 Die Klassendarstellung
Diplomarbeit
OSWOOD • 133
,QGHU.ODVVHQDQVLFKWZHUGHQGLH(LJHQVFKDIWHQHLQHU
EHVWLPPWHQVLFKLP)RNXVGHU%HWUDFKWXQJEHILQGHQGHQ
.ODVVHGDUJHVWHOOW
Abbildung 5-14: Klassenansicht in einem Schemadiagramm
'LH$QVLFKWLVWLQYHUVFKLHGHQH,QWHUHVVHQVEHUHLFKH
VWUXNWXULHUWXQGHQWKlOWGLHIROJHQGHQ$EVFKQLWWH
• .RQVWUXNWLRQ'HVWUXNWLRQ
• $WWULEXWH
• 0HWKRGHQ
• .RPSRQHQWHQEH]LHKXQJHQ
• ,QYHUVH%H]LHKXQJHQ
• (YROXWLRQVEH]LHKXQJHQ
• %HREDFKWXQJVEH]LHKXQJHQ
-HGHGLHVHU6HNWLRQHQWKlOWGLHLQGLHVHP=XVDPPHQKDQJ
UHOHYDQWHQ0HWKRGHQXQG$WWULEXWH)UGLH'DUVWHOOXQJGHU
(OHPHQWHZHUGHQGLHIROJHQGHQ6\PEROHYHUZHQGHW
([SOL]LWHV |IIHQWOLFKHV $WWULEXW
([SOL]LWHV SULYDWHV $WWULEXW
([SOL]LWHV 6FKOVVHODWWULEXW
,PSOL]LWHV SULYDWHV $WWULEXW
([SOL]LWH |IIHQWOLFKH 0HWKRGH
([SOL]LWH SULYDWH 0HWKRGH
([SOL]LWH |IIHQWOLFKH QXU OHVHQGH 0HWKRGH
6FKOVVHOPHWKRGH
,PSOL]LWH |IIHQWOLFKH 0HWKRGH
,PSOL]LWH SULYDWH 0HWKRGH
,PSOL]LWH |IIHQWOLFKH QXU OHVHQGH 0HWKRGH
9LUWXHOOH |IIHQWOLFKH 0HWKRGH
9LUWXHOOH SULYDWH 0HWKRGH
9LUWXHOOH |IIHQWOLFKH QXU OHVHQGH 0HWKRGH
.RPSRQHQWHQEH]LHKXQJ
%HREDFKWXQJVEH]LHKXQJ
,QYHUVH %H]LHKXQJ
(YROXWLRQVEH]LHKXQJ
Tabelle 5-10: Symbole ein einer Klassenansicht
5.3.2.4 Konstruktion/Destruktion
'LHGUHLLQGLHVHU6HNWLRQDXIJHIKUWHQ0HWKRGHQZHUGHQ
YRQ26:22'JHQHULHUWXQG]lKOHQ]XGHQYLUWXHOOHQ
|IIHQWOLFKHQ0HWKRGHQ
134 • OSWOOD
Diplomarbeit
Abbildung 5-15: Darstellung der Konstruktoren und Destruktoren
5.3.2.5 Attribute
'HUIROJHQGH$EVFKQLWW]HLJWGLHYRP(QWZHUIHUGHILQLHUWHQ
XQGVRPLW|IIHQWOLFKHQ$WWULEXWH=XPHLQHQZXUGHQGLHVH
GLUHNWLP+DUG\GLDJUDPPDOV(LJHQVFKDIWHQGHU.ODVVH
DQJHJHEHQXQG]XPDQGHUHQGXUFKGLH'HILQLWLRQYRQ
6FKOVVHONULWHULHQLQGHUEH]JOLFKGHU
.RPSRQHQWHQEH]LHKXQJDOV%HVLW]HUGHNODULHUWHQ.ODVVH
LPSOL]LHUW
Abbildung 5-16: Darstellung der benutzerdefinierten Attribute
5.3.2.6 Methoden
,P0HWKRGHQEORFNVLQGGLHYRP(QWZHUIHUGHILQLHUWHQ
0HWKRGHQVRZLHGLHYRQ26:22'LPSOL]LWJHQHULHUWHQ
YLUWXHOOHQ0HWKRGHQIUGLH,QVWDQ]HQYDOLGLHUXQJGDUJHVWHOOW
%HLGHQ%HQXW]HUHUIDVVWHQZLUGDQKDQGGHU'HILQLWLRQV]HLOH
]ZLVFKHQOHVHQGHQXQGVFKUHLEHQGHQ([HPSODUHQ
XQWHUVFKLHGHQ
Abbildung 5-17: Darstellung der Methoden
5.3.2.7 Komponentenbeziehungen
,QGHU.RPSRQHQWHQVHNWLRQZHUGHQVlPWOLFKHHLQHU
EHVWLPPWHQ.ODVVH]XJHK|ULJHQ.RPSRQHQWHQDXIJHOLVWHW-H
%H]LHKXQJOlVVWVLFKGDEHLGLH.DUGLQDOLWlWVHLQVFKUlQNXQJGLH
6FKOVVHONULWHULHQVRZLHGLHLPSOL]LWJHQHULHUWHQ$WWULEXWH
XQG0HWKRGHQKHUDXVOHVHQ
Diplomarbeit
OSWOOD • 135
Abbildung 5-18: Darstellung der Komponentenbeziehungen
5.3.2.8 Inverse Beziehungen
,QYHUVH%H]LHKXQJHQZHUGHQJOHLFKVDPLQHLQHUHLJHQHQ
6HNWLRQ]XVDPPHQJHIDVVW$QDORJGHU
.RPSRQHQWHQEH]LHKXQJHQVLQGGLHLPSOL]LWHQ0HWKRGHQXQG
$WWULEXWHHQWKDOWHQ
Abbildung 5-19: Darstellung der inversen Beziehungen
5.3.2.9 Evolutionsbeziehungen
'LHLPSOL]LWJHQHULHUWHQ0HWKRGHQIUGLH8PVHW]XQJHLQHU
,QVWDQ]LP5DKPHQGHU2EMHNWHYROXWLRQVLQGLP
(YROXWLRQVWHLOGHU.ODVVHQGDUVWHOOXQJ]XILQGHQ
Abbildung 5-20: Darstellung der Objektevolutionen
5.3.2.10 Beobachtungsbeziehungen
%HL+LOIVNODVVHQIHKOHQGLH$EVFKQLWWHIUGLHLQYHUVHQXQG
GLH(YROXWLRQVEH]LHKXQJHQGDIUHQWKDOWHQVLHHLQHQ
8QWHUEDXPGHULKUH%HREDFKWXQJVEH]LHKXQJHQDQDORJ
EHVFKUHLEW
Abbildung 5-21: Darstellung der Beobachtungsbeziehungen
136 • OSWOOD
Diplomarbeit
5.3.2.11 Die ODL-Ansicht
,QGHU2'/$QVLFKWNDQQGHUIUHLQEHVWLPPWHVVLFKLP
)RNXVEHILQGHQGHV(OHPHQWGHU.ODVVHQGDUVWHOOXQJJHQHULHUWH
&RGHLQGHU6FKHPDGHILQLWLRQVVSUDFKH2&HLQJHVHKHQ
ZHUGHQ,VWLPDNWXHOOHQ)DOOHLQH.ODVVHVHOHNWLHUWZLUGGLH
'HILQLWLRQGLHVHU.ODVVHDQJH]HLJW
Abbildung 5-22: Darstellung einer Klassendefinition in der ODL-Ansicht
,VWLP*HJHQVDW]GD]XHLQH0HWKRGH*HJHQVWDQGGHV
,QWHUHVVHVZLUGHQWVSUHFKHQGGHUHQ,PSOHPHQWDWLRQLP
)HQVWHUDXVJHJHEHQ
Abbildung 5-23: Darstellung einer Methodenimplementation in der ODL-Ansicht
5.3.3 Anzeigen eines Transaktionsdiagramms
'XUFKHLQHQ'RSSHONOLFNDXIHLQ7UDQVDNWLRQVGLDJUDPPLQGHU
1DYLJDWLRQVDQVLFKWRGHUGXUFKGLHFile | Open$NWLRQZLUGGLH
JHZlKOWH'LDJUDPPGDWHLXQWHUVXFKWXQGLQWHUSUHWLHUW
$QDORJ]XGHU9HUDUEHLWXQJGHU6FKHPDGLDJUDPPGDWHLHQZHUGHQ
GHP%HQXW]HUIDWDOH)HKOHUVRIRUWDQJH]HLJWXQG:DUQXQJHQLQGLH
$XVJDEH]HLOHJHVFKULHEHQ
.RQQWHGLH'DWHLYROOVWlQGLJXQGIHKOHUIUHLJHOHVHQXQGGLH
HQWVSUHFKHQGHQ'DWHQVWUXNWXUHQDQJHOHJWZHUGHQHUVFKHLQWGLH
7UDQVDNWLRQVDQVLFKW
Diplomarbeit
OSWOOD • 137
Abbildung 5-24: Transaktionsdiagramm in OSWOOD
'DV7UDQVDNWLRQVIHQVWHULVWLQ]ZHL%HUHLFKH$XIUXIKLHUDUFKLHXQG
2'/$QVLFKWXQWHUWHLOW
5.3.3.1 Aufrufhierarchieansicht
,QGHUKLHUDUFKLVFKHQ$QVLFKWELOGHWGLH$SSOLNDWLRQ
+DXSWSURJUDPPGLH:XU]HOZHOFKHULQGHU]ZHLWHQ(EHQH
GLH6XEV\VWHPHXQWHUJHRUGQHWVLQG=XGHPVLQGGHU
hEHUVLFKWOLFKNHLWKDOEHUVlPWOLFKH3URJUDPPH)XQNWLRQHQ
XQG7UDQVDNWLRQHQLQHQWVSUHFKHQGH6DPPOXQJHQ
DXIJHQRPPHQ
'LH$XIUXIEH]LHKXQJHQ]ZLVFKHQGHQ(OHPHQWHQZHUGHQLQ
GHQ$XIUXIEDXPEHUWUDJHQLQGHPHLQ(OHPHQWHLQHP
DQGHUHQJHQDXGDQQXQWHUJHRUGQHWZLUGZHQQHLQ$XIUXI
YRPHUVWHQ]XP]ZHLWHQGHILQLHUWZRUGHQLVW
Abbildung 5-25: Darstellung der Aufrufhierarchien in OSWOOD
(QWKDOWHQGLH3URJUDPPH)XQNWLRQHQRGHU7UDQVDNWLRQHQ
SVHXGRFRGHDUWLJH0HWKRGHQDXIUXIHZHUGHQGLHVHJOHLFKVDP
LQGLHKLHUDUFKLVFKH$QVLFKWLQWHJULHUW
)UGLH'DUVWHOOXQJGHUHLQ]HOQHQ(OHPHQWHZHUGHQGLH
IROJHQGHQ6\PEROHYHUZHQGHW
$SSOLNDWLRQ+DXSWSURJUDPP
6XEV\VWHP
3URJUDPP
)XQNWLRQ
7UDQVDNWLRQ
0HWKRGH
Tabelle 5-11: Symbole in der hierarchischen Ansicht eines
Transaktionsdiagramms
5.3.3.2 ODL-Ansicht
138 • OSWOOD
Diplomarbeit
,QGHU2'/$QVLFKWOlVVWVLFKIUMHGHVLQGHUKLHUDUFKLVFKHQ
$QVLFKWHQWKDOWHQH(OHPHQWGHUYRQ26:22'JHQHULHUWH
&RGHEHWUDFKWHQ)U$SSOLNDWLRQHQZHUGHQOHGLJOLFKGLH
3URJUDPPGHNODUDWLRQHQJH]HLJWZlKUHQGEHL3URJUDPPHQ
XQG7UDQVDNWLRQHQQXUGHUHQ,PSOHPHQWDWLRQNUHLHUWZLUG
%HL)XQNWLRQHQZLUGJDUEHLGHVLQV2'/)HQVWHU
JHVFKULHEHQ6XEV\VWHPHVLQGQXU6WUXNWXULHUXQJVKLOIHQXQG
ZHUGHQGHVKDOEIUGLH&RGHJHQHULHUXQJQLFKW
PLWEHUFNVLFKWLJW
5.3.4 Schemaevolution
'LH9LVXDOLVLHUXQJHQGHU'LDJUDPPHLQ26:22'HUODXEHQGHP
(QWZHUIHUHLQH9RUDQVLFKWGHUVSlWHUHQ8PVHW]XQJLQ
6FKHPDGHILQLWLRQVFRGHXQGIKUHQKlXILJGD]XGDVV
(QWZXUIVHQWVFKHLGHLQEH]XJDXI.ODVVHQHLJHQVFKDIWHQRGHU
%H]LHKXQJVPRGHOOHEHUSUIWXQGRGHUPRGLIL]LHUWZHUGHQPVVHQ
(VJLOWGDEHL]XEHDFKWHQGDVVbQGHUXQJHQEHLHLQHU5FNNHKU]XP
(QWZXUIVZHUN]HXJ+DUG\XQGGRUWLJHU$QSDVVXQJGHU'LDJUDPPH
HUVWLQ26:22'HUNDQQWZHUGHQN|QQHQZHQQGLHQHX
JHVSHLFKHUWHQ'DWHLHQHUQHXWJH|IIQHWZHUGHQ(VLVWDOVR
LQVEHVRQGHUHQLFKWP|JOLFK0DQLSXODWLRQHQDQGHQ$XVJDQJVGDWHLHQ
LQ26:22'RQOLQHIHVW]XVWHOOHQGDIULVWHVDEHUDXFKQLFKW
QRWZHQGLJGDV3URJUDPP]XEHHQGHQXQGQHX]XVWDUWHQ
,VWGHU(QWZHUIHUPLWGHQHU]LHOWHQ5HVXOWDWHQ]XIULHGHQOlVVWHUVLFK
GHQ6FKHPDGHILQLWLRQVFRGHHU]HXJHQXQGYHUZHQGHWGLHVHQ
DQVFKOLHVVHQGXPJHJHQEHUGHU'DWHQEDQNXPJHEXQJHLQ6FKHPD
]XNUHLHUHQYJOGLHIROJHQGH$EVFKQLWWH26:22'NDQQDEHU
QLFKWPHKUHLQJHVHW]WZHUGHQXP$QSDVVXQJHQZHOFKHDXIJUXQG
YRQQHXHQRGHUHUZHLWHUWHQ$QIRUGHUXQJHQQRWZHQGLJZHUGHQDQ
HLQHPEHUHLWVEHVWHKHQGHQ6FKHPDYRU]XQHKPHQ
9LHOPHKUVROOGHU(QWZXUIYRQ6FKHPDlQGHUXQJHQXQGGLH
HQWVSUHFKHQGH(U]HXJXQJYRQ6FKHPDPDQLSXODWLRQVFRGH
*HJHQVWDQGYRQZHLWHUHQ)RUVFKXQJHQVHLQ'D]XEHGDUIHVDEHU
DXFKQHXHQ(UNHQQWQLVVHQLQ%H]XJDXIGLH6WDQGDUGLVLHUXQJ
GHUDUWLJHU0RGLILNDWLRQHQVHLWHQVGHU$QELHWHUNRPPHU]LHOOHU
REMHNWRULHQWLHUWHU'DWHQEDQNV\VWHPH
5.3.5 Umsetzen in ODL
%HLGHQEHLGHQYHUIJEDUHQ'LDJUDPPDQVLFKWHQKDQGHOWHVVLFK
OHGLJOLFKXP9LVXDOLVLHUXQJHQLQZHOFKHQNHLQH0DQLSXODWLRQHQ
YRUJHQRPPHQZHUGHQN|QQHQ1DWUOLFKZlUHHLQHHQWVSUHFKHQGH
(UZHLWHUXQJGHV:HUN]HXJHVLQNOXVLYH5FNVFKUHLEXQJLQ
+DUG\GDWHLHQGHQNEDUDEHUQLFKWLPSOHPHQWLHUW
6RPLWVWHKWGHP%HQXW]HULQHLQHP'LDJUDPPIHQVWHUDOVHLQ]LJH
$NWLRQGLH8PVHW]XQJLQ2'/]XU9HUIJXQJ'XUFKGLH:DKOGHV
0HQSXQNWHVFile | Save as ODLZHUGHQGLHEHUHLWVHU]HXJWHQXQGLQ
GHQ2'/$QVLFKWHQJH]HLJWHQ&RGHIUDJPHQWH]XVDPPHQJH]RJHQ
XQGLQHLQHYRP%HQXW]HUJHZQVFKWH'DWHLEOLFKHUZHLVHPLWGHU
([WHQVLRQÅRF´JHVFKULHEHQ
'LH&RGHVSHLFKHUXQJIKUWNHLQHZHLWHUHQ9DOLGLHUXQJHQPHKU
GXUFKZHVKDOEGLHVH9HUDUEHLWXQJVRIHUQJHQJHQG6SHLFKHUSODW]
DXIGHP0DVVHQVSHLFKHUPHGLXPYRUKDQGHQLVWQLFKWIHKOVFKODJHQ
NDQQ
Diplomarbeit
OSWOOD • 139
6RIRUWQDFKGHU6SHLFKHUXQJZLUGGLHJHVFKULHEHQH'DWHLLQ
26:22'HU|IIQHWZRVLHGHQHUZHLWHUWHQ%HGUIQLVVHQDQJHSDVVW
XQGPLWGHQJHWlWLJWHQ0DQLSXODWLRQHQJHVSHLFKHUWZHUGHQNDQQ
Abbildung 5-26: Darstellung einer O2C-Datei in OSWOOD
5.3.6 Importieren der generierten O2C-Dateien in
O2
$OV5HVXOWDWGHUYRULJHQ8PVHW]XQJGHU'LDJUDPPGDWHLHQLQ2&
HUKlOWPDQEOLFKHUZHLVHMH6FKHPDGLDJUDPPXQGMH
7UDQVDNWLRQVGLDJUDPPHLQHHQWVSUHFKHQGHRF'DWHL'LHVHNDQQLQ
GLH'DWHQEDQNXPJHEXQJ2HLQJHOHVHQZHUGHQ
5.3.6.1 Import mittels O2-Shell
'LH26KHOOLVWHLQHLQWHUDNWLYHUHLQWH[WEDVLHUWH
'DWHQGHILQLWLRQVXQGPDQLSXODWLRQVVFKQLWWVWHOOHIU
$GPLQLVWUDWRUHQ>[email protected],QLKUNDQQHLQH9LHO]DKODXV
GHP6DW]GHUXQWHU2&YHUIJEDUHQ$QZHLVXQJHQGLUHNW
JHJHQEHUGHU'DWHQEDVLVDEJHVHW]WZHUGHQ'DUXQWHU
EHILQGHQVLFK%HIHKOHIUGLH6FKHPDWDRGHU
%DVHQYHUZDOWXQJIUDGKRF$QIUDJHQIU7UDQVDNWLRQHQ
DEHUDXFK3URJUDPPRGHU$SSOLNDWLRQVDXIUXIHQ
,QVEHVRQGHUHLVWLP6\QWD[GHU26KHOOGLH$QZHLVXQJ
#DateiName
YHUIJEDUZHOFKHGLHLQGHU'DWHLDateiNameHQWKDOWHQHQ
2&$QZHLVXQJHQGHU5HLKHQDFKDEDUEHLWHW0LW+LOIHGLHVHU
$QZHLVXQJODVVHQVLFKDOVRGLHYRQ26:22'HU]HXJWHQ
6FKHPDGHILQLWLRQVGDWHLHQLQGDV'DWHQEDQNVFKHPD
EHUWUDJHQ
5.3.6.2 Import mittels O2-Tools
27RROVLVWHLQHJUDILVFKH8PJHEXQJIUGDVLQWHUDNWLYH
9HUZDOWHQYRQ6FKHPDWD%DVHQXQG$SSOLNDWLRQHQ>27RROV
@'DV:HUN]HXJVWHOOW'DWHQEDQNDGPLQLVWUDWRUHQ
YHUVFKLHGHQH%URZVHU(GLWRUHQXQGVRQVWLJH+LOIVPLWWHO]XU
9HUIJXQJ(LQHNXU]H(LQIKUXQJVEHVFKUHLEXQJILQGHWPDQ
LQ>*[email protected]
140 • OSWOOD
Diplomarbeit
'HU,PSRUWGHUYRQ26:22'JHQHULHUWHQ'DWHLHQNDQQ
DXFKEHUGLH1DYLJDWLRQGXUFKYHUVFKLHGHQH0HQSXQNWH
XQGGLH$XVZDKOGHU4XHOOGDWHLHQJHVFKHKHQ'LH
%HVFKUHLEXQJGHVJHQDXHQ9RUJHKHQVVROO>[email protected]
HQWQRPPHQZHUGHQ
5.4 Bewertung der Arbeit mit OSWOOD
'DV:HUN]HXJ26:22'EHJOHLWHWGHQ(QWZHUIHUZlKUHQGGHVJDQ]HQ
(QWZXUIVSUR]HVVHVXQGVWHOOWLKPGLHXQWHUVFKLHGOLFKVWHQ$QVLFKWHQ]XU
9HUIJXQJ$XIGHUHLQHQ6HLWHVLHKWHUGLHYRQLKPJH]HLFKQHWHQ
'LDJUDPPHGLHGDUDXVLQWHUSUHWLHUWHQ.ODVVHQXQG$SSOLNDWLRQVVWUXNWXUHQ
DXIGHUDQGHUHQ6HLWHDEHUDXFKGHQGDUDXVUHVXOWLHUHQGHQ2&&RGH
.HQQWVLFKGHU(QWZHUIHUPLWGHQ6SUDFKHOHPHQWHQGHU
6FKHPDGHILQLWLRQVVSUDFKHDXVZDVQLFKWLPPHUJHJHEHQVHLQPXVVXQG
JHPlVVGHU)RUGHUXQJQDFKGHU,PSOHPHQWDWLRQVXQDEKlQJLJNHLWGHV
(QWZXUIHVQLFKWJHJHEHQVHLQVROON|QQHQ(QWZXUIVIHKOHUIUK]HLWLJHUNDQQW
ZHUGHQ'LH)HKOHUN|QQHQDXFKQXUGDQQIHVWJHVWHOOWZHUGHQZHQQEHUHLWV
LQHLQHUIUKHQ3KDVHGLH=LHOXPJHEXQJIHVWJHOHJWZRUGHQLVWZDVKlXILJ
QLFKWGHU)DOOLVWhEOLFKHUZHLVHVROOEHLP(QWZXUIGLH,PSOHPHQWDWLRQQLFKW
YRUZHJJHQRPPHQZHUGHQ
1DWUOLFKOlVVWVLFKGDVYRQ26:22'JHQHULHUWH5HVXOWDWDXFKDOV
=ZLVFKHQHUJHEQLVÅ0HWDVFKHPD´LQWHUSUHWLHUHQZHOFKHVGDQQQLFKWZLH
YRUJHVFKODJHQLQ2HLQJHOHVHQVRQGHUQDXIHLQHEHOLHELJHDQGHUH
'DWHQEDQNXPJHEXQJDEJHELOGHWZLUG'DUEHUKLQDXVOLHVVHVLFK26:22'
JHJHEHQHQIDOOVDXFKIUGLH*HQHULHUXQJDQGHUHU6FKHPDGHILQLWLRQVVSUDFKHQ
ZLH&2'/DXVEDXHQ
>%[email protected]EHUGLH5ROOHYRQ:HUN]HXJHQLP
(QWZXUIVSUR]HVVGDVVVLFKGLHVHDXVJH]HLFKQHWHLJQHQXPGLH.RQVLVWHQ]
GLH6LFKHUKHLWXQGGLH9ROOVWlQGLJNHLWGHU'LDJUDPPH]XSUIHQXQGGHUHQ
/HLVWXQJVIlKLJNHLW]XDQDO\VLHUHQ'HU(LQVDW]YRQ:HUN]HXJHQYHUKLQGHUW
DOVRLP*HJHQVDW]]XPSDSLHUEDVLHUWHQ$QVDW]GLH)HKOLQWHUSUHWDWLRQYRQ
.RQVWUXNWHQRGHUGHQ$XVEDXGHU1RWDWLRQHQQDFKGHP*XWGQNHQGHV
(QWZHUIHUV:HUN]HXJHN|QQHQDEHUQLFKWRGHUQRFKQLFKW:LVVHQEHUGLH
3UREOHPGRPlQHDXVQXW]HQXP)HKOHQWVFKHLGXQJHQLP(QWZXUI]X
HUNHQQHQ
/HW]WOLFKNRPPHQJXWH(QWZUIHYRQJXWHQ(QWZHUIHUQXQGQLFKWYRQJXWHQ
:HUN]HXJHQ>%[email protected]
Diplomarbeit
OSWOOD • 141
6 Umsetzung
6.1 Einleitung
,PYRULJHQ.DSLWHOZXUGHGHUZHUN]HXJXQWHUVWW]WH(QWZXUIVSUR]HVV
DXVJHIKUW,QGLHVHP.DSLWHOVROOQXQJHQDXHUEHVFKUHLEHQZHUGHQZLH
HLQ]HOQHQ.RQVWUXNWHGHUYHUVFKLHGHQHQ'LDJUDPPW\SHQYRQ'(,026LQ
(OHPHQWHGHU6FKHPDGHILQLWLRQVVSUDFKH2&XPJHVHW]WZHUGHQ
(LQ+DUG\GLDJUDPPEHVWHKWDXV.QRWHQXQG.DQWHQ'LH7\SHQGHU
.QRWHQXQG.DQWHQNRQVWUXNWHVLQGGDEHLIUHLQHQEHVWLPPWHQ
'LDJUDPPW\SHLQJHVFKUlQNWGKHVN|QQHQQLFKWEHOLHELJH(OHPHQWHLQ
HLQHP'LDJUDPPHQWKDOWHQVHLQVRQGHUQQXUGLHMHQLJHQZHOFKHLQGHU
HQWVSUHFKHQGHQ'LDJUDPPW\SHQGHILQLWLRQYRUJHVHKHQVLQG6RPLWHQWIlOOW
EHUHLWVGLH%HKDQGOXQJYLHOHU$XVQDKPHVLWXDWLRQHQ
'DV=HLFKHQZHUN]HXJOlVVWDXFKGLH'HILQLWLRQYRQ(LQVFKUlQNXQJHQIUGLH
9HUZHQGXQJGHU'LDJUDPPHOHPHQWH]X'DPLWVLQGZLHGHUXPHLQH5HLKH
YRQJHIlKUOLFKHQ6LWXDWLRQHQYHUKLQGHUW
0LWHLQHU.DQWHZHUGHQLPPHUJHQDX]ZHL.QRWHQYHUEXQGHQ:LHGLHVH
9HUELQGXQJHQQXQYRQ26:22'LQ6DFKYHUKDOWHGHVNRQ]HSWXHOOHQ
(QWZXUIHVXPJHVHW]WZHUGHQELOGHWGHU*HJHQVWDQGGLHVHV.DSLWHOV'LH
%HZHUWXQJGHU8PVHW]XQJVFKOLHVVOLFKZLUGDP(QGHGHV.DSLWHOVGLVNXWLHUW
6.2 Umsetzung eines Schemadiagramms
,QHLQHP6FKHPDGLDJUDPPN|QQHQGLHIROJHQGHQ.QRWHQXQG.DQWHQ
• (LQVWLHJVSXQNWH
• 'DWHQEDQNNODVVHQ
• DEVWUDNWH.ODVVHQ
• +LOIVNODVVHQXQG
• .RPPHQWDUH
DOV.QRWHQXQG
• 9HUHUEXQJVEH]LHKXQJHQ
• .RPSRQHQWHQEH]LHKXQJHQ
• LQYHUVH%H]LHKXQJHQ
• ,QVWDQWLLHUXQJVEH]LHKXQJHQ
• (YROXWLRQVEH]LHKXQJHQ
• %HREDFKWXQJVEH]LHKXQJHQXQG
• 1RWL]EH]JH
DOV.DQWHQHQWKDOWHQVHLQ%HLGHU8PVHW]XQJVROOJUXQGVlW]OLFKMHGHV
.QRWHQHOHPHQWHLQHP2EMHNW]XJHRUGQHWZHUGHQXQGDQVFKOLHVVHQGMHGHV
.DQWHQHOHPHQWLQHLQH%H]LHKXQJ]ZLVFKHQ]ZHL2EMHNWHQXPJHVHW]W
ZHUGHQ'HU%HJULIIÅ2EMHNW´EH]LHKWVLFKDXIGLH,PSOHPHQWLHUXQJLQ
HLQHPREMHNWRULHQWLHUWHQ8PIHOGXQGVROOQLFKWPLWGHP(QWZXUIVNRQVWUXNW
Å2EMHNW´YHUZHFKVHOWZHUGHQ
6.2.1 Umsetzung der Knoten
*UXQGVlW]OLFKZLUGMHGHP.QRWHQHLQH,QVWDQ]HLQHUHQWVSUHFKHQGHQ
.ODVVH]XJHRUGQHW,P)DOOHHLQHV.ODVVHQNQRWHQVLVWIUGDV2EMHNW
HLQH'HILQLWLRQXQGHLQH,PSOHPHQWDWLRQLQGHU
6FKHPDGHILQLWLRQVVSUDFKH2&]XJHQHULHUHQZlKUHQGIUGLH
(LQVWLHJVSXQNWHOHGLJOLFKGLH'HNODUDWLRQ]XHU]HXJHQLVW'LH
1RWL]HQNQRWHQZHUGHQ]ZDUIU5HSURGXNWLRQV]ZHFNHLQVSH]LHOOHQ
Diplomarbeit
Umsetzung • 143
2EMHNWHQDEJHOHJWDEHUIUGDV6FKUHLEHQGHU2&'DWHLHQQLFKW
ZHLWHUYHUZHQGHW
6.2.1.1 Einstiegspunkte
(LQVWLHJVSXQNWHVLQG,QVWDQ]HQYRQ.ODVVHQZHOFKHGXUFK
HLQHH[SOL]LWH$QZHLVXQJLQGHU6FKHPDGHILQLWLRQSHUVLVWHQW
JHPDFKWZHUGHQ
,QGHU+DUG\GDWHLZLUGHLQ(LQVWLHJVSXQNWGXUFKVHLQHQ7\S
LGHQWLIL]LHUW
type = "entry point"
'HUSHUVLVWHQWH1DPHNDQQYRP(QWZHUIHUDOV(LJHQVFKDIW
GHV.QRWHQVHLQJHJHEHQZHUGHQ
'persistent name' = persistenterName,
,Q2&ZLUGHLQ(LQVWLHJVSXQNWPLWGHU$QZHLVXQJ
name persistenterName : typedef;
GHILQLHUW'DEHLZLUGGHUSHUVLVWHQWH1DPHYHUZHQGHWXP
GXUFKGLH'DWHQEDVLVQDYLJLHUHQ]XN|QQHQ$OV7\SNDQQ
MHGHLP6FKHPDGHILQLHUWH'DWHQEDQNNODVVHJHZlKOWZHUGHQ
8PGLHVH=XRUGQXQJDEHUYRUQHKPHQ]XN|QQHQPXVVPLW
+LOIHGHV,QVWDQWLLHUXQJVSIHLOGLHMHQLJH.ODVVHJHIXQGHQ
ZHUGHQPLWZHOFKHUGHU(LQVWLHJVSXQNWYHUEXQGHQLVWYOJ
8PVHW]XQJGHU,QVWDQWLLHUXQJ6HLWH
,PNRQNUHWHQ)DOO%HLVSLHO),6NDQQHLQ(LQVWLHJVSXQNWLQ
GHU+DUG\GDWHLIROJHQGHUPDVVHQHQWKDOWHQVHLQ
node('persistant name' = "Macrohard",
type = "entry point",
id = 86660,
card = 87936,
images = [86663],
arcs = [86664, 86668]).
Listing 6-1: Beispiel eines Einstiegspunktes
%HLGHU8PVHW]XQJLQGLH'HILQLWLRQVDQZHLVXQJXQWHU
=XKLOIHQDKPHGHU,QVWDQWLLHUXQJVSIHLOHVUHVXOWLHUWHWZDGLH
IROJHQGH=HLOH
name Macrohard : Company;
Listing 6-2: Beispiel einer Definition eines Einstiegspunktes
6.2.1.2 Definition der Datenbankklassen, abstrakten
Klassen und Hilfsklassen
'LH'DWHQEDQNNODVVHQDEVWUDNWHQ.ODVVHQXQG+LOIVNODVVHQ
ZHUGHQLQGHU+DUG\GDWHLLPZHVHQWOLFKHQLGHQWLVFK
EHKDQGHOWZHVKDOELP)ROJHQGHQVWHOOYHUWUHWHQGIUGLHVH
.RQVWUXNWHGLH%HKDQGOXQJGHU'DWHQEDQNNODVVHDOV.ODVVH
LP$OOJHPHLQHQEHVFKULHEHQVHLQVROO
(LQH'DWHQEDQNNODVVHNDQQGXUFKGLH7\SHQDQJDEH
LGHQWLIL]LHUWZHUGHQ
type = "database class"
*HPlVVGHU'LDJUDPPGHILQLWLRQLVWGHU(QWZHUIHU
DQJHKDOWHQGLHEHLGHQ(LJHQVFKDIWHQGHV.ODVVHQNQRWHQV
'class name' = ClassName
properties = Properties
]XHUIDVVHQ'HU1DPHGHU.ODVVHPXVVGDEHLXP
.RQIOLNWHQYRU]XEHXJHQIUGHQJHVDPWHQ(QWZXUI
HLQGHXWLJYHUJHEHQZHUGHQ,P$WWULEXW¶(LJHQVFKDIWHQ·
ODVVHQVLFKGLH(LJHQKHLWHQGHU.ODVVHEHVFKUHLEHQ'LHVVLQG
LQVEHVRQGHUHGHUHQ0HWKRGHQGHUHQ$WWLUXEWHDEHUDXFKGLH
144 • Umsetzung
Diplomarbeit
6FKOVVHOXQGGLH.ODVVHQLQYDULDQWHQYOJ'HILQLWLRQGHU
(LJHQVFKDIWHQ6HLWH
,QGHU6FKHPDGHILQLWLRQVVSUDFKH2&ZLUGHLQH.ODVVHQDFK
GHPIROJHQGHQ6\QWD[GHILQLHUWYOJ>*[email protected]
klassendef ::= class classname
[inherit cl_name (,cl_name)*]
[public] type typedef
[method methoden]
end;
methoden
::= methode (,methode)*
methode
::= [public|private]
methoddef
methoddef ::= name [parameter]
[:typedef]
parameter ::= ( name : typedef (,name :
typedef)*)
ex_typedef ::= type typname : typedef ;
typedef
::= atomar | complex
atomar
::= primitiv | klassenname |
typname
primitiv
::= integer | real |
character |
boolean | string
koplex
::= tupel | menge | liste
tupel
::= tuple ( att_spez
(,att_spez)* )
att_spez
::= att_name : typedef
menge
::= [unique] set ( typename |
classname)
liste
::= list ( typename |
classname )
Syntaxdiagramm 6-1: Klassendefinition in O2C
(LQH.ODVVHQGHILQLWLRQEHVWHKWDOVRLPZHVHQWOLFKHQDXVGHU
$QJDEHGHV1DPHQVXQGGHU9HUHUEXQJVEH]LHKXQJHQGHU
%HVFKUHLEXQJGHU'DWHQVWUXNWXUXQGGHU'HILQLWLRQGHU
.ODVVHQVLJQDWXUXQWHU$QJDEHGHV=XJULIIVVFKXW]HV
,PNRQNUHWHQ)DOO%HLVSLHO),6N|QQWHHLQH
'DWHQEDQNNODVVHCompanyZLHIROJWLQGHU+DUG\GDWHL
HQWKDOWHQVHLQ
node('class name' = "Company",
properties = "ListEmployees()
R GetSallary(refDev:Dev):integer
W SetSallery(refEmpl:Empl,nSallery:integer):boolean
r GetName(): string
w GetEmployee(a:a,b:b):Empl
Office<m_nNumber>
Developer<name,firstname>",
type = "database class",
id = 86207,
card = 87936,
images = [86211],
arcs = [86292, 86664, 87321]).
Listing 6-3: Datenbankklasse in Hardydatei
,QGHU6FKHPDGHILQLWLRQVGDWHLPVVWHGLHHQWVSUHFKHQGHQ
.ODVVHHWZDIROJHQGHUPDVVHQUHSUlVHQWLHUWZHUGHQ
class Company inherit DBObject public
class Company inherit DBObject
type tuple (
Diplomarbeit
Umsetzung • 145
public Name : string,
public Address : address,
public NrOfEmpl : number,
private m_setrefOffice : unique set(Office),
private m_refDeveloper : Developer,
private m_refManager : Manager)
method
public Create(setrefOffice : unique set (Office),
refDeveloper : Developer) : boolean,
public Destroy() : boolean,
public Init(Name : string, Address : address) : Company,
public IsConsistent() : boolean,
private IsValid() : boolean,
public ListEmployees() : boolean,
public GetSallary(refDev : Dev) : integer,
public SetSallery(refEmpl : Empl, nSallery : integer) :
boolean,
public GetName() : string,
public GetEmployee(a : a, b : b) : Empl,
public AddOffice(m_nNumber : integer) : Office,
public AddRefOffice(refOffice : Office) : boolean,
public CreateOffice(m_nNumber : integer) : Office,
public RemoveOffice(refOffice : Office) : boolean,
public DestroyOffice(refOffice : Office),
public FindOffice(m_nNumber : integer) : Office,
public AddDeveloper(Name : string, Knowledge : string,
Firstname : string) : Developer,
public AddRefDeveloper(refDeveloper : Developer) :
boolean,
public CreateDeveloper(Name : string, Knowledge :
string, Firstname : string) : Developer,
public RemoveDeveloper(refDeveloper : Developer) :
boolean,
public DestroyDeveloper(refDeveloper : Developer),
public FindDeveloper(Name : string, Firstname : string)
: Developer,
public AddManager(MercedesType : string) : Manager,
public AddRefManager(refManager : Manager) : boolean,
public CreateManager(MercedesType : string) : Manager,
public RemoveManager(refManager : Manager) : boolean,
public DestroyManager(refManager : Manager),
public FindManager() : Manager,
public EvolveDeveloperToManager(refDeveloper :
Developer, MercedesType : string) : Manager,
private AssignDeveloperToManager(refDeveloper :
Developer, refManager : Manager),
public EvolveManagerToDeveloper(refManager : Manager,
Name : string, Knowledge : string, Firstname : string) :
Developer,
private AssignManagerToDeveloper(refManager : Manager,
refDeveloper : Developer)
end;
Listing 6-4: Definition einer Datenbankklasse in O2C
6.2.1.3 Implementation der Datenbankklassen,
abstrakten Klassen und Hilfsklassen
%HLGHU8PVHW]XQJZHUGHQHLQHU.ODVVHHLQLJHLPSOL]LWH
(LJHQVFKDIWHQKLQ]XJHIJW=XPHLQHQZHUGHQVlPWOLFKH
.ODVVHQYRQGHUYRUGHILQLHUWHQ.ODVVH'%2EMHFWDEJHOHLWHW
XQG]XPDQGHUHQZHUGHQLQGHQ.ODVVHQJHZLVVH]XVlW]OLFKH
YLUWXHOOH0HWKRGHQLPSOHPHQWLHUW'LHVH0HWKRGHQZHUGHQ
VRZRKOIUGLHHLQKHLWOLFKH%HKDQGOXQJGHU2EMHNWHDOVDXFK
IUGLH,PSOHPHQWDWLRQGHULPSOL]LWHQ0HWKRGHQLQ
%H]LHKXQJVIXQNWLRQHQYHUZHQGHWXQGVROOHQGLH6LFKHUKHLW
GHV'DWHQVFKHPDVGXUFKGLHLPSOL]LWH3UIXQJGHU
.RQVLVWHQ]HUK|KHQYJO´)RUWSIODQ]XQJXQG
.RQVLVWHQ]VLFKHUXQJµ6HLWH
'HU.ODVVHZHUGHQVWDQGDUGPlVVLJIROJHQGHYLUWXHOOHQ
)XQNWLRQHQKLQ]XJHQHULHUW
IsValid
EHUSUIWGLHYRP%HQXW]HULP(QWZXUIIUHLQH.ODVVH
EHVWLPPWHQLQYDULDQWHQ.RQVLVWHQ]EH]LHKXQJHQ'LHVH
146 • Umsetzung
Diplomarbeit
%HGLQJXQJHQEH]LHKHQVLFKLPPHUDXIGLHDNWXHOOH,QVWDQ]
RKQH%H]LHKXQJHQ]XDQGHUHQ2EMHNWHQ]XEHUFNVLFKWLJHQ
ZHVKDOEGLHVH0HWKRGHLPPHUDP(QGHHLQHU|IIHQWOLFKHQ
0HWKRGHDXI]XUXIHQLVW
IsConsistent
'LH.RQVLVWHQ]SUIXQJVPHWKRGHVWHOOW]X%HJLQQGXUFKGHQ
$XIUXIGHU0HWKRGHIsValidVLFKHUGDVVGLH,QYDULDQWHQ
QLFKWYHUOHW]WVLQG$QVFKOLHVVHQGSUIWVLHLPLPSOL]LWHQ7HLO
GLH.DUGLQDOLWlWVEHGLQJXQJHQZHOFKHIUGLH%H]LHKXQJHQDQ
GHQHQGLHDNWXHOOH,QVWDQ]WHLOQLPPWYRP(QWZHUIHUGHILQLHUW
ZRUGHQVLQG
,PH[SOL]LWHQ7HLOGHU,PSOHPHQWLHUXQJODVVHQVLFKYRP
(QWZLFNOHUZHLWHUH.RQVLVWHQ]EH]LHKXQJHQWHVWHQ
'LHVH0HWKRGHHLJQHWVLFKGDKHULGHDOXPDP(QGHHLQHU
7UDQVDNWLRQGXUFKGHUHQ$XIUXIIUMHGHVGHUPRGLIL]LHUWHQ
2EMHNWH]XHQWVFKHLGHQREGLH7UDQVDNWLRQPLWHLQHP
commitHUIROJUHLFKDEJHVFKORVVHQZHUGHQNDQQRGHUGXUFK
HLQHQabortUFNJlQJLJJHPDFKWZHUGHQPXVV
Init
'LHInit0HWKRGHZLUGYRP2EMHNWNRQVWUXNWRULPSOL]LW
DXIJHUXIHQ'HVKDOEGDUIVLHDOVDPHKHVWHQDOV
EHQXW]HUGHILQLHUEDUHU.RQVWUXNWRUDQJHVHKHQZHUGHQ)U
MHGHV$WWULEXWZHOFKHV]XU(U]HXJXQJV]HLWLQLWLDOLVLHUWZHUGHQ
VROOPXVVLKUHLQHQWVSUHFKHQGHU:HUWDOV3DUDPHWHU
EHUJHEHQZHUGHQ'HUDUWLJH$WWULEXWHODVVHQVLFKDOV
.ODVVHQHLJHQVFKDIWHQGHU)RUPName : Typ =GHILQLHUHQ
26:22'VRUJWEHLGHU8PVHW]XQJGDIUGDVVGLH
,QLWLDOLVLHUXQJVPHWKRGHHLQHGLHVEH]JOLFKNRUUHNWH6LJQDWXU
HUKlOW
,QGHU,PSOHPHQWDWLRQZHUGHQQHEHQGLHVHQ,QLWLDOLVLHUXQJHQ
DXFKGLH6WDQGDUGZHUWH]XJHZLHVHQGLHYRP(QWZHUIHUIU
GLHH[SOL]LWHQ$WWULEXWHDQJHJHEHQZRUGHQVLQG
$QVFKOLHVVHQGZLUGGXUFKGHQ$XIUXIGHU0HWKRGHIsValid
GLH,QLWLDONRQVLVWHQ]GHV2EMHNWHVJHSUIW
Create
'LHVH0HWKRGHVRUJWIUHLQHNRUUHNWH(U]HXJXQJHLQHU
,QVWDQ]HLQHUEHVWLPPWHQ.ODVVH,QVEHVRQGHUHZHUGHQLQ
GHVVHQ,PSOHPHQWDWLRQGLH]XU(UUHLFKXQJGHU.RQVLVWHQ]
]ZLQJHQGHQ%H]LHKXQJHQ]XDQGHUHQ2EMHNWHDXIJHEDXW
%HL.RPSRQHQWHQEH]LHKXQJHQGLHHLQH0LQLPDONDUGLQDOLWlW
YRQJU|VVHUYHUODQJHQZHUGHQGLHHQWVSUHFKHQGHQ
,QVWDQ]HQHU]HXJWnewLQLWLDOLVLHUWLPSOL]LWXQGNRQVLVWHQW
JHPDFKWCreate
'LHVHLPSOL]LWH(U]HXJXQJLVWQXUGDQQP|JOLFKZHQQGLH
LPSOL]LWHQ,QLWLDOLVLHUXQJVPHWKRGHQGHUEHWURIIHQHQ2EMHNWH
NHLQH3DUDPHWHUYHUODQJHQYOJInit0HWKRGH.DQQGLHV
QLFKWJDUDQWLHUWZHUGHQPVVHQGLH,QVWDQ]HQDXVVHUKDOE
GLHVHU0HWKRGHNUHLHUWZHUGHQXQGHQWVSUHFKHQGH
5HIHUHQ]HQEHUJHEHQZHUGHQ'LHMHZHLOVVLFKHUH6LJQDWXU
IUGLHCreate0HWKRGHZLUGYRQ26:22'DXWRPDWLVFK
HUVWHOOW
$P(QGHGHU0HWKRGHQDXVIKUXQJZLUGGXUFKGHQ$XIUXI
Diplomarbeit
Umsetzung • 147
GHU0HWKRGHIsConsistentVLFKHUJHVWHOOWGDVVGLH
.RQVLVWHQ]EHGLQJXQJHQQXQDOOHVDPWIUGLH,QVWDQ]HUIOOW
VLQG
Destroy
'HU$XIUXIGLHVHU0HWKRGHNPPHUWVLFKXPGLH/|VFKXQJ
HLQHU,QVWDQ]6LHZLUGDOVRQLFKW]HUVW|UWLP6SUDFKXPIDQJ
YRQ2&LVWNHLQdelete.RQVWUXNWYHUIJEDUHVZLUGLKU
YLHOPHKUGLH9RUDXVVHW]XQJIUGLH3HUVLVWHQ]HQW]RJHQ
LQGHPDOOH5HIHUHQ]HQ]XLKUDEJHEDXWZHUGHQ
,QVEHVRQGHUHZHUGHQGDEHLVlPWOLFKHLQYHUVHQ%H]LHKXQJHQ
ZHOFKHGLH,QVWDQ]]XU=HLWQRFKXQWHUKlOWDEJHEDXWXQG
VlPWOLFKH.RPSRQHQWHQZHOFKHGXUFKHQWVSUHFKHQGH
%H]LHKXQJHQPLWGHPDNWXHOOHQ2EMHNWYHUEXQGHQVLQG
GXUFKGHQ$XIUXIGHUVHOEHQ0HWKRGH]HUVW|UWXQGDXVGHQ
5HIHUHQ]PHQJHQHQWIHUQW
'LH.RQVLVWHQ]GHUDNWXHOOHQ,QVWDQ]NDQQDP6FKOXVVGLHVHV
$QZHLVXQJVEORFNVQLFKWPHKUJHJHEHQVHLQZHVKDOEGLH
HQWVSUHFKHQGHQ0HWKRGHQQLFKWDXIJHUXIHQZHUGHQ
$OOH0HWKRGHQPLW$XVQDKPHGHUInitXQGLQPDQFKHQ
)lOOHQGHUCreate0HWKRGHVLQGSDUDPHWHUORVGKVLH
EH]LHKHQVLFKQXUDXIGLH'HILQLWLRQHQDXVGHP(QWZXUIXQG
JDUDQWLHUHQGHVKDOEHLQH.RQWH[WIUHLKHLWXQGUHWRXUQLHUHQ
HLQHQERRO·VFKHQ:HUWEHUZHOFKHQGHU(UIROJGHV$XIUXIHV
JHSUIWZHUGHQNDQQ'LH,QLWLDOLVLHUXQJVPHWKRGHKLQJHJHQ
EHVLW]WIUDOOH]XLQLWLDOLVLHUHQGHQ$WWULEXWHHLQHQ3DUDPHWHU
XQGUHWRXUQLHUWJHPlVVGHU)RUGHUXQJGHV'DWHQEDQNV\VWHPV
GHQ2EMHNWLGHQWLILNDWRUGHVHEHQHU]HXJWHQ2EMHNWHV
1HEHQGHQLPSOL]LWHQYLUWXHOOHQ0HWKRGHQGLHIUHLQH
.ODVVHJHQHULHUWZHUGHQPVVHQ,PSOHPHQWDWLRQVJHUVWHIU
GLHYRP(QWZHUIHUGHILQLHUWHQH[SOL]LWHQ0HWKRGHQGHU
.ODVVHHU]HXJWZHUGHQ(LQGHUDUWLJHV*HUVWEHVWHKWDXVGHQ
IROJHQGHQ7HLOHQ
5FNJDEHYDULDEOH
)DOOVIUGLH0HWKRGHHLQ5FNJDEHW\SGHILQLHUWZXUGHZLUG
HLQHHQWVSUHFKHQGHORNDOH9DULDEOHGLHVHV7\SVDQJHOHJW
9RUEHGLQJXQJHQ
)UVlPWOLFKHEHUJHEHQHQ3DUDPHWHUZLUGLQGLHVHP
$EVFKQLWWGHVVHQ*OWLJNHLWJHSUIW+DQGHOWHVVLFKEHLGHP
3DUDPHWHUXPHLQH.ODVVHVRZLUGGHVVHQ9DOLGLWlWPLW+LOIH
GHU0HWKRGH,V&RQVLVWHQWJHWHVWHW,P)DOOHHLQHU
hEHUJDEHYDULDEOHQHLQHVDWRPDUHQ'DWHQW\SVYJO>*HSSHUW
SZLUGOHGLJOLFKLQHLQHU.RPPHQWDU]HLOHGDUDXI
KLQJHZLHVHQGDVVGHVVHQ*OWLJNHLW]XYDOLGLHUHQLVW
,PSOHPHQWDWLRQ
'HU(QWZLFNOHULVWGXUFKHLQH.RPPHQWDU]HLOHGHU)RUP
Å72'2´DXIJHUXIHQLQGLHVHP7HLOVHLQH
0HWKRGHQLPSOHPHQWLHUXQJHLQ]XIJHQ
1DFKEHGLQJXQJHQ
+DQGHOWHVVLFKEHLGHU0HWKRGHXPHLQHDXIGLH'DWHQEDVLV
VFKUHLEHQGHZLUGGXUFKGHQ$XIUXIGHU0HWKRGH
IsConsistentZHOFKHLPSOL]LWGLH,QYDULDQ]GHV2EMHNWHV
SUIWVLFKHUJHVWHOOWGDVVGLH,QVWDQ]QDFKGHP9HUODVVHQGHU
148 • Umsetzung
Diplomarbeit
0HWKRGHNRQVLVWHQWLVW%HLQXUOHVHQGHQ0HWKRGHQHQWIlOOW
GLHVH3UIXQJ
5FNJDEH
,P(UIROJVIDOOZLUGGLHORNDOH9DULDEOHIUGHQ5FNJDEHZHUW
]XUFNJHJHEHQZlKUHQGEHLHLQHU)HKOHUEHGLQJXQJHLQ
YRUGHILQLHUWHU:HUW]XUFNJHOLHIHUWZLUG'LHVHU:HUWLVWLP
)DOOHHLQHUJHIRUGHUWHQ2EMHNWUHIHUHQ]GLH1XOOUHIHUHQ]XQG
IUDWRPDUH5FNJDEHZHUWHHLQ/HHUGDWXP/HHUVWULQJ
HWF
,QGHU6FKHPDGHILQLWLRQVVSUDFKH2&LVWGHUIROJHQGH6\QWD[
IUGLH,PSOHPHQWDWLRQHLQHU.ODVVHQPHWKRGHYRUJHVHKHQ
methodimpl ::= method body methodname
in class classname block
block
::= { variables, statement };
variables ::= (vardef)*
vardef
::= o2 (typename|classname)
varname ;
Syntaxdiagramm 6-2: Methodendefinition in O2C
,QHLQHPNRQNUHWHQ)DOO%HLVSLHO),6N|QQWHQGLH
,PSOHPHQWDWLRQHQGHUYLUWXHOOHQ0HWKRGHQZLHIROJW
DXVVHKHQ
method body IsValid in class Company {
/* check invariant constraints */
if (!(self->m_strName != "Microsoft")) return (false);
return (true);
};/* end IsValid */
Listing 6-5: Virtuelle Methode IsValid() für die Klasse Company
method body IsConsistent in class Company {
/* check object's validity */
if (!self->IsValid()) return (false);
/* check cardinality constraints */
if ((count(self->m_setrefOffice<45))||
(count(self->m_setrefOffice>45))) return (false);
if ((count(self->m_setrefDeveloper<1))||
(self->count(m_setrefDeveloper>15))) return (false);
if ((count(self->m_setrefManager<1))||
(count(self->m_setrefManager>15))) return (false);
return (true);
};/* end IsConsistent */
Listing 6-6: Virtuelle Methode IsConsistent() für die Klasse Company
method body Init in class Company {
/* initialize the explicit attributes */
self->NrOfEmpl = 1;
self->Name = Name;
self->Address = Address;
/* initialize the implicit attributes (components) */
self->m_setrefOffice = unique set();
self->m_refDeveloper = (o2 Developer)0;
self->m_refManager = (o2 Manager)0;
/* check object's validity */
if (!self->IsValid()) return ((o2 Company)0);
return (self);
};/* end Init */
Listing 6-7: Virtuelle Methode Init() für die Klasse Company
method body Create in class Company {
o2 integer i; /* counter used in for statements */
o2 Office refOffice; /* local variable for component
creating */
/* check preconditions */
for (i=0;i<45;i++) {
if (setrefOffice[i] == (o2 Office)0) return (false);
} /* endfor */
Diplomarbeit
Umsetzung • 149
if (refDeveloper == (o2 Developer)0) return (false);
/* create components */
for (refOffice in setrefOffice) {
if (self->FindOffice(refOffice->m_nNumber) != (o2
Office)0) return (false);
self->m_setrefOffice += unique set (refOffice);
} /* endfor */
self->m_refDeveloper = refDeveloper;
/* check object's consistency */
if (!self->IsConsistent()) return (false);
return (true);
};/* end Create */
Listing 6-8: Virtuelle Methode Create() für die Klasse Company
method body Destroy in class Company {
o2 integer i; /* counter used in for statements */
o2 Office refOffice; /* local variable for comp destroying
*/
o2 Developer refDeveloper; /* local variable for comp
destroy */
o2 Manager refManager; /* local variable for comp
destroying */
/* destroy components */
for (refOffice in self->m_setrefOffice) {
refOffice->Destroy();
}/* endfor */
m_setrefOffice = unique set();
if (self->m_refDeveloper != (o2 Developer)0) {
self->m_refDeveloper->Destroy();
self->m_refDeveloper = (o2 Developer)0;
}/* endif */
if (self->m_refManager != (o2 Manager)0) {
self->m_refManager->Destroy();
self->m_refManager = (o2 Manager)0;
}/* endif */
return (true);
};/* end Destroy */
Listing 6-9: Virtuelle Methode Destroy() für die Klasse Company
(LQHEHQXW]HUGHILQLHUWHH[SOL]LWH0HWKRGHN|QQWHZLHIROJW
LPSOHPHQWLHUWZHUGHQ
method body SetSallery in class Company {
o2 boolean : bReturn /* return value for method */
/* preconditions */
if (!refEmpl.IsConsistent()) return (false);
-- ASSERT: nSallery is valid;
/* implementation */
-- TODO: Add your implementation code here
/* postconditions */
if (!self->IsConsistent()) return (false);
return (bReturn);
};/* end SetSallery */
Listing 6-10: Explizite Methode SetSallery() in der Klasse Company
6.2.2 Umsetzung der Kanten
*UXQGVlW]OLFKZLUGMHGHU.DQWHHLQH,QVWDQ]HLQHUHQWVSUHFKHQGHQ
.DQWHQNODVVH]XJHRUGQHW.DQWHQYHUELQGHQLPPHU]ZHL.QRWHQ
PLWHLQDQGHUXQGDIIHNWLHUHQGHPQDFKHQWZHGHUGHQMHQLJHQ.QRWHQ
YRQGHPVLHKHUVWDPPHQRGHUGHQMHQLJHQDXIGHQVLH]XODXIHQRGHU
EHLGHJOHLFK]HLWLJ
:HQQ.DQWHQLP6LQQHYRQ'(,026%H]LHKXQJHQGDUVWHOOHQ
.RPSRQHQWHQEH]LHKXQJHQLQYHUVH%H]LHKXQJHQZHUGHQEHLGH
.QRWHQEHHLQIOXVVW5HSUlVHQWLHUHQGLH.DQWHQ%H]JH
9HUHUEXQJVEH]LHKXQJHQ,QVWDQWLLHUXQJVLQGQXUGLH=LHONQRWHQ
EHWURIIHQ)DOOVGLH.DQWHQEHREDFKWHQGHU1DWXUVLQG
150 • Umsetzung
Diplomarbeit
%HREDFKWXQJVEH]LHKXQJHQZHUGHQQXUGLH$XVJDQJVNQRWHQ
WDQJLHUW
.DQWHQN|QQHQDEHUDXFKHLQH)lKLJNHLWHLQHV.QRWHQVGDUVWHOOHQ
ZLHGLHVLP)DOOHGHU(YROXWLRQVEH]LHKXQJ]XWULIIWXQGGHPQDFK
HLQHPVSH]LHOOHQ8PVHW]XQJVSUR]HVVXQWHUZRUIHQVHLQ6LQG1RWL]HQ
EHUHLQHQ1RWL]EH]XJPLWHLQHP.QRWHQYHUEXQGHQZLUGGLHVH
$EKlQJLJNHLWJOHLFKVDPGXUFKHLQH.DQWHGDUJHVWHOOW'HUDUWLJH
.DQWHQZHUGHQDEHUIUGDV6FKUHLEHQGHU2&'DWHLHQQLFKWZHLWHU
YHUZHQGHWXQGGHPHQWVSUHFKHQGKHUDXVJHILOWHUW
,QMHGHP)DOODEHUVWHOOHQ.DQWHQ(LJHQVFKDIWHQGHU.QRWHQGDUXQG
ZHUGHQVRPLWZlKUHQGGHU,QWHUSUHWDWLRQLQGLH'DWHQVWUXNWXUHQGHU
.QRWHQNODVVHQEHUWUDJHQ
.DQWHQZHUGHQLQGHU+DUG\GDWHLDOVHLJHQH(OHPHQWHDEJHOHJW'LH
9DULDEOH
type = Type
OlVVWHLQH,GHQWLILNDWLRQGHV3IHLOW\SV]X'LH7\SHQEH]HLFKXQJ
VWDPPWDXVGHU'LDJUDPPGHILQLWLRQ'HU(LQWUDJ
connections = [[NodeIdFrom, NodeIdTo]]
JLEWGDUEHU$XIVFKOXVVZHOFKHEHLGHQ.QRWHQPLWHLQDQGHU
YHUEXQGHQVLQG'LHLQGHQHFNLJHQ.ODPPHUQHLQJHIDVVWHQ=DKOHQ
UHSUlVHQWLHUHQGLH,GHQWLILNDWRUHQGHU.QRWHQ'LHHUVWH=DKO
GHILQLHUWGHQ$XVJDQJVNQRWHQGLH]ZHLWH=DKOVWHKWIUGHQ
=LHONQRWHQ
1DFKIROJHQGVHLDXIGLHYHUVFKLHGHQHQ3IHLOW\SHQQlKHUHLQJHJDQJHQ
XQGGHUHQ8PVHW]XQJLQGLH6FKHPDGHILQLWLRQVVSUDFKHHUOlXWHUW
6.2.2.1 Vererbungsbeziehungen
9HUHUEXQJVEH]LHKXQJHQZHUGHQLQGHU+DUG\GDWHLDQKDQG
LKUHV7\SVHUNDQQW
type = "inheritance"
(LQH9HUHUEXQJVEH]LHKXQJDIIHNWLHUWGLH.ODVVHQGHILQLWLRQ
GDKLQJHKHQGDOVGDVVGHU1DPHGHU9DWHUNODVVHLQGLH
inherit'HNODUDWLRQHLQJHIJWZHUGHQPXVVYJO
6\QWD[GLDJUDPP6HLWH
inherit ClassName (,ClassName)*
%HLGHU,QWHUSUHWDWLRQGHU9HUHUEXQJVEH]LHKXQJHQPXVV
EHVRQGHUVGDUDXIJHDFKWHWZHUGHQGDVVLQGHQ$EOHLWXQJHQ
NHLQH=\NOHQHQWKDOWHQVLQG
,QHLQHPNRQNUHWHQ)DOO%HLVSLHO),6N|QQWHIROJHQGHU3IHLO
LQGHU+DUG\GDWHLHQWKDOWHQVHLQ
arc(type = "inheritance",
id = 87313,
card = 87936,
images = [87316],
connections = [[86217, 87245]],
arc_image_type = "inheritance arc").
Listing 6-11: Vererbungspfeil in einer Hardydatei
,QGHU6FKHPDGHILQLWLRQVGDWHLZUGHVLFKGLHVHUHWZDZLH
IROJWlXVVHUQ
class Developer inherit Employee public
type tuple (
...
)
method
...
end;
Listing 6-12: Vererbungsbeziehung in der Schemadefinitionsdatei
6.2.2.2 Komponentenbeziehung
Diplomarbeit
Umsetzung • 151
(LQH.RPSRQHQWHQEH]LHKXQJGUFNWHLQHH[LVWHQ]DEKlQJLJH
$JJUHJDWLRQ]ZLVFKHQ]ZHL.ODVVHQDXV:LUGHLQHGHUDUWLJH
%H]LHKXQJ]ZLVFKHQ]ZHL.ODVVHQHLQJHULFKWHWVRZLUGGHU
%HVLW]HUNODVVH$XVJDQJVNODVVHGHV3IHLOVGLH
.RQWUROOIlKLJNHLWEHUGLH.RPSRQHQWHQNODVVH=LHONODVVH
GHV3IHLOVEHUWUDJHQ
.RPSRQHQWHQEH]LHKXQJHQZHUGHQLQGHU+DUG\GDWHLDQKDQG
LKUHV7\SVHUNDQQW
type = "component"
'HU(LQWUDJ
cardinality = "[1,15]"
GHILQLHUWGLHPLQLPDOHHUVWH=DKOE]ZGLHPD[LPDOH]ZHLWH
=DKO$Q]DKOGHU]XJHODVVHQHQ.RPSRQHQWHQ'LHVH
$QJDEHQZHUGHQYRP(QWZHUIHUIHVWJHOHJWXQGIJHQGHU
'DWHQEDVLVZHLWHUH.RQVLVWHQ]EHGLQJXQJHQKLQ]X
,PNRQNUHWHQ)DOO%HLVSLHO),6N|QQWHLQGHU+DUG\GDWHLGHU
.RPSRQHQWHQSIHLO]ZLVFKHQGHQ.QRWHQCompanyXQG
DeveloperZLHIROJWHQWKDOWHQVHLQ
arc(cardinality = "[1,15]",
inverse = "1",
name = "",
type = "component",
id = 87321,
card = 87936,
images = [87325],
connections = [[86207, 87245]],
arc_image_type = "component arc").
Listing 6-13: Beispiel einer Komponentenbeziehung in der Hardydatei
'LH%HVLW]HUNODVVHEWGLH.RQWUROOHEHULKUH.RPSRQHQWHQ
DXVZDVEHGHXWHWGDVVHLQ]LJGLH,QVWDQ]HQGHUDJJUHJLHUWHQ
.ODVVH,QVWDQ]HQGHU.RPSRQHQWHQNODVVHHU]HXJHQXQG
]HUVW|UHQGUIHQ=XGHPNDQQHLQHLQ]HOQHV([HPSODU
DXVVFKOLHVVOLFKPLW+LOIHGHU$JJUHJDWLRQVLQVWDQ]DXIJHIXQGHQ
ZHUGHQ
$XVGLHVHP*UXQGPVVHQGLHIROJHQGHQ
9HUZDOWXQJVPHWKRGHQXQGDWWULEXWHIUGLH%HVLW]HUNODVVH
LPSOL]LWJHQHULHUWZHUGHQ
m_refset<ClassName> : unique
set(<ClassName>)
0LW+LOIHGLHVHV$WWULEXWHVZHUGHQGLH5HIHUHQ]HQDXIGLH
.RPSRQHQWHQYHUZDOWHW=XGHPZLUGIUMHGHVHU]HXJWH
2EMHNWHGDQNGHU$XIQDKPHGHU5HIHUHQ]LQGLHVH0HQJH
VHLQH3HUVLVWHQ]HUUHLFKW
Add<ClassName>([KeyAttr1 [,KeyAttrN]*])
'LHVH0HWKRGHHU]HXJWHLQHQHXH,QVWDQ]GHU.ODVVH
ClassNameXQGIJWGLH5HIHUHQ]GHU5HIHUHQ]PHQJH
m_refset<ClassName>KLQ]X
(LQ+LQ]XIJHQHLQHUQHXHQ.RPSRQHQWHLVWQDWUOLFKQXU
GDQQP|JOLFKZHQQGLHREHUH/LPLWHGHILQLHUWGXUFKGLH
.DUGLQDOLWlWVDQJDEHQLFKWEHUHLWVHUUHLFKWZRUGHQLVW
=XGHPNDQQGXUFKGLH'HILQLWLRQYRQ6FKVVHOQGLH
(LQGHXWLJNHLWEH]JOLFKGLHVHU$XVSUlJXQJYHUODQJWZHUGHQ
ZDVJOHLFKVDPLP5DKPHQGHU9RUEHGLQJXQJHQJHSUIW
ZHUGHQPXVV$XVGLHVHP*UXQGPVVHQGLHVHU0HWKRGHGLH
:HUWHGHU6FKOVVHODWWULEXWHGHV]XHU]HXJHQGHQ2EMHNWHV
152 • Umsetzung
Diplomarbeit
PLWJHOLHIHUWZHUGHQ
1DFKGHPGDVJHZQVFKWH2EMHNWNUHLHUWZRUGHQLVWZLUG
GHVVHQ.RQVLVWHQ]GXUFKGLH$XIUXIHYRQ,QLWXQG&UHDWH
JHVLFKHUW$QVFKOLHVVHQGZHUGHQHWZDLJH6FKOVVHOZHUWH
JHVHW]WXQGGLH.RQVLVWHQ]GHU%HVLW]HUNODVVHJHSUIW
,P(UIROJVIDOOZLUGGLH5HIHUHQ]DXIGDVHEHQHU]HXJWH
2EMHNWDQGHQDXIUXIHQGHQ3URJUDPPIDGHQ]XUFNJHOLHIHUW
ZlKUHQGLP)HKOHUIDOOGLH1XOOUHIHUHQ]]XUFNJHJHEHQZLUG
AddRef<ClassName>(refClassName:ClassName)
.DQQDXIJUXQGGHU6FKHPDGHILQLWLRQGDV
.RPSRQHQWHQREMHNWGXUFKGHQ$XIUXIGHUAdd0HWKRGH
QLFKWDXIVLFKHUH:HLVHHU]HXJWZHUGHQ
.RQVLVWHQ]YHUOHW]XQJNDQQGLHVDXFKDXVVHUKDOEGHU
0HWKRGHQGHULPSOL]LWHQ.RPSRQHQWHQEH]LHKXQJHQHUOHGLJW
ZHUGHQ'LH.RPSRQHQWHQEH]LHKXQJNDQQLQGLHVHP)DOO
WURW]GHPVLFKHUDXIJHEDXWZHUGHQLQGHPGDVHU]HXJWH
2EMHNWGXUFKGHQ$XIUXIGHU)XQNWLRQAddRef]XU
.RPSRQHQWHQPHQJHKLQ]XJHIJWZLUG
Remove<ClassName>(ref<ClassName>:<ClassName
>)
'LHVH0HWKRGHHQWIHUQWHLQEHVWLPPWHVGXUFKGHQ
hEHUJDEHSDUDPHWHUUHIHUHQ]LHUWHV2EMHNWDXVGHU0HQJHGHU
.RPSRQHQWHQ
$OV9RUEHGLQJXQJHQLVW]XSUIHQREGLH]XO|VFKHQGH
,QVWDQ]DXFKLQGHU.RPSRQHQWHQVDPPOXQJHQWKDOWHQLVW
XQGGLH0LQLPDONDUGLQDOLWlWGXUFKGLHVH/|VFKXQJQLFKW
XQWHUVFKULWWHQZLUG
6LQGGLHEHLGHQ9RUDXVVHW]XQJHQJHJHEHQVRNDQQGDV
2EMHNWGXUFKGHQ$XIUXIGHU0HWKRGHDestroyZHOFKH
LKUHUVHLWVHLQH/|VFKXQJGHU6XENRPSRQHQWHQHU]ZLQJWIU
GLH/|VFKXQJYRUEHUHLWHWZHUGHQ
'XUFKGDV(QWIHUQHQGHV2EMHNW]HLJHUVDXVGHU
5HIHUHQ]PHQJHLVWGLH%HGLQJXQJIUGLH3HUVLVWHQ]GHV]X
O|VFKHQGHQ2EMHNWHVQLFKWPHKUJHJHEHQZHVKDOEGDV
'DWHQEDQNYHUZDOWXQJVV\VWHPGLH,QVWDQ]DXVGHU'DWHQEDVLV
O|VFKW
)DOOVGLHDNWXHOOH,QVWDQ]QRFKNRQVLVWHQWLVWZLUGGHU
ERRO·VFKH(UIROJVZHUW]XUFNJHJHEHQDQGHUQIDOOVGHU
0LVVHUIROJVZHUW
Find<ClassName>([KeyAttr1 [,KeyAttrN]*])
'LHVH0HWKRGHYHUVXFKWLQGHU0HQJHGHU.RPSRQHQWHQ
GHV7\SHVClassNameGDVMHQLJH([HPSODUDXVILQGLJ]X
PDFKHQGHVVHQ6FKOVVHODWWULEXWZHUWHPLWGHQ
hEHUJDEHSDUDPHWHUQEHUHLQVWLPPHQ'LHVH6XFKHZLUG
JHJHQEHUGHU'DWHQEDVLVDOV24/$QIUDJHIRUPXOLHUW
.DQQHLQVROFKHVJHIXQGHQZHUGHQZLUGGHVVHQ
2EMHNWLGHQWLILNDWRU]XUFNJHOLHIHUW:DUGLH6XFKHKLQJHJHQ
HUIROJORVZLUGGLH1XOOUHIHUHQ]UHWRXUQLHUW
Create<ClassName>([KeyAttr1 [,KeyAttrN]*])
+lXILJODVVHQVLFK6FKHPDWDQLFKWGHUDUWEHVFKUHLEHQGDVV
GLH,QWHJULWlWGHU'DWHQEDVLVQDFKMHGHP(LQIJHQJHJHEHQ
LVW]ZLQJHQGHLQYHUVH%H]LHKXQJHQRGHU
Diplomarbeit
Umsetzung • 153
.RQVLVWHQ]EHGLQJXQJHQGLHXQWHUPHKUHUHQ2EMHNWHQ
ZLUNHQ
$XVGLHVHP*UXQGOlVVWGLHCreate0HWKRGHZHOFKHLP
ZHVHQWOLFKHQGLHVHOEHQ'LHQVWHZLHGLH0HWKRGHAddHUIOOW
GDV(U]HXJHQYRQ2EMHNWHQ]XRKQHEHLHLQHUHWZDLJHQ
.RQVLVWHQ]YHUOHW]XQJDE]XEUHFKHQ
%HLP(LQVDW]GLHVHV7\SVYRQ0HWKRGHQJLOWHVEHVRQGHUV]X
EHDFKWHQGDVVGLHVHDXVVFKOLHVVOLFKLQ7UDQVDNWLRQHQ
DXIJHUXIHQZHUGHQXQGYRUGHPHUIROJUHLFKHQ$EVFKOXVV
GXUFKHLQcommitIUDOOHEHWHLOLJWHQ2EMHNWHGLH0HWKRGHQ
]XU.RQVLVWHQ]SUIXQJDXIJHUXIHQZHUGHQ
Destroy<ClassName>(ref<ClassName>:<ClassNam
e>)
'DVVHOEHJLOWIUGLHDestroy0HWKRGHZHOFKHGDV
ÅXQVLFKHUH´$QDORJRQ]XGHURemove0HWKRGHGDUVWHOOW
,PNRQNUHWHQ)DOO%HLVSLHO),6N|QQWHQGLHJHQHULHUWHQ
0HWKRGHQIUGLH.RPSRQHQWHQEH]LHKXQJPLW6FKOVVHO
NameXQGFirstnameXQGGHU.DULGQDOLWlWVEHGLQJXQJ
PLQLPDOPD[LPDO]ZLVFKHQCompanyXQGDeveloper
ZLHIROJWLPSOHPHQWLHUWVHLQ
method body AddDeveloper in class Company {
o2 Developer refDeveloper;
/* check preconditions */
if (self->m_refDeveloper) != (o2 Developer)0)
return ((o2 Developer)0);
/* create new component */
refDeveloper = new Developer(Name, Knowledge, Firstname);
if (!refDeveloper->Create()) return ((o2 Developer)0);
self->m_refDeveloper = refDeveloper;
/* check postconditions */
if (!self->IsConsistent()) return ((o2 Developer)0)
return (refDeveloper);
};/* end AddDeveloper */
Listing 6-14: Implementation der Methode AddDevloper() in der Klasse Company
method body AddRefDeveloper in class Company {
/* validate params */
if (refDeveloper == (o2 Developer)0) return (false);
/* check preconditions */
if (self->m_refDeveloper) != (o2 Developer)0) return ((o2
Developer)0);
/* add referenced component */
self->m_refDeveloper = refDeveloper;
/* check postconditions */
if (!self->IsConsistent()) return (false)
return (true);
};/* end AddRefDeveloper */
Listing 6-15: Implementation der Methode AddRefDevloper() in der Klasse
Company
method body CreateDeveloper in class Company {
o2 Developer refDeveloper;
/* check preconditions */
if (self->FindDeveloper(Name, Firstname) != (o2
Developer)0)
return ((o2 Developer)0);
/* create new component */
refDeveloper = new Developer(Name, Knowledge, Firstname);
self->m_refDeveloper = refDeveloper;
/* check postconditions */
-- NOTE: This method can cause inconsistent state.
154 • Umsetzung
Diplomarbeit
-- TODO: Check consistency outside this method by calling
IsConsistent()
return (refDeveloper);
};/* end CreateDeveloper */
Listing 6-16: Implementation der Methode CreateDevloper() in der Klasse
Company
method body RemoveDeveloper in class Company {
/* check preconditions */
if (self->m_refDeveloper != refDeveloper) return (false);
/* destroy component */
refDeveloper->Destroy();
self->m_refDeveloper = (o2 Developer)0;
/* check postconditions */
if (!self->IsConsistent()) return (false);
return (true);
};/* end RemoveDeveloper */
Listing 6-17: Implementation der Methode RemoveDevloper() in der Klasse
Company
method body DestroyDeveloper in class Company {
/* destroy component */
if (self->m_refDeveloper == refDeveloper)
self->m_refDeveloper = (o2 Developer)0;
/* check postconditions */
-- NOTE: This method can cause inconsistent state.
-- TODO: Check consistency outside this method by calling
IsConsistent()
};/* end DestroyDeveloper */
Listing 6-18: Implementation der Methode DestroyDevloper() in der Klasse
Company
method body FindDeveloper in class Company {
o2 unique set(Developer) refsetDeveloper; /* result set
for OQL query */
/* query item with given key values */
o2query(refsetDeveloper,"\
select e from e in $1 \
where x->Name = $2 && \
x->Firstname = $3",
unique set(self->m_refDeveloper),Name,Firstname);
if (count(refsetDeveloper)==0) return ((o2 Developer)0);
else return (element(refsetDeveloper));
};/* end FindDeveloper */
Listing 6-19: Implementation der Methode FindDevloper() in der Klasse
Company
,P)DOOHGHU.RPSRQHQWHQEH]LHKXQJ]XGHU.ODVVH
DeveloperNRQQWHGLH9HUELQGXQJLQHLQHUHLQIDFKHQ
5HIHUHQ]YDULDEOHQDEJHELOGHWZHUGHQGDK|FKVWHQVHLQH
$VVR]LDWLRQ]ZLVFKHQGHQEHLGHQ.ODVVHQYRUKDQGHQVHLQ
NDQQ%HLGHUHQWVSUHFKHQGHQ%H]LHKXQJ]XGHU.ODVVH
OfficePLWGHP6FKOVVHOnNumberKLQJHJHQLVWGLH
.DUGLQDOLWlW>@DQJHQRPPHQZDVVLFKGDKHULQHLQHU
PHQJHQZHUWLJHQ5HIHUHQ]YDULDEOHQQLHUGHUVFKOlJW'LH
HQWVSUHFKHQGHQ0HWKRGHQZUGHQHWZDIROJHQGHUPDVVHQ
JHQHULHUW
method body AddOffice in class Company {
o2 Office refOffice;
/* check preconditions */
if (count(self->m_setrefOffice) >= 45) return ((o2
Office)0);
if (self->FindOffice(m_nNumber) != (o2 Office)0)
return ((o2 Office)0);
/* create new component */
refOffice = new Office(m_nNumber);
if (!refOffice->Create()) return ((o2 Office)0);
self->m_setrefOffice += unique set(refOffice);
Diplomarbeit
Umsetzung • 155
/* check postconditions */
if (!self->IsConsistent()) return ((o2 Office)0)
return (refOffice);
};/* end AddOffice */
Listing 6-20: Implementation der Methode AddOffice() in der Klasse Company
method body AddRefOffice in class Company {
/* validate params */
if (refOffice == (o2 Office)0) return (false);
/* check preconditions */
if (count(self->m_setrefOffice) >= 45) return ((o2
Office)0);
if (refOffice in self->m_setrefOffice) return (false);
if (self->FindOffice(refOffice->m_nNumber) != (o2
Office)0)
return (false);
/* add referenced component */
self->m_setrefOffice += unique set(refOffice);
/* check postconditions */
if (!self->IsConsistent()) return (false)
return (true);
};/* end AddRefOffice */
Listing 6-21: Implementation der Methode AddRefOffice() in der Klasse
Company
method body CreateOffice in class Company {
o2 Office refOffice;
/* check preconditions */
if (self->FindOffice(m_nNumber) != (o2 Office)0)
return ((o2 Office)0);
/* create new component */
refOffice = new Office(m_nNumber);
self->m_setrefOffice += unique set(refOffice);
/* check postconditions */
-- NOTE: This method can cause inconsistent state.
-- TODO: Check consistency outside this method by calling
IsConsistent()
return (refOffice);
};/* end CreateOffice */
Listing 6-22: Implementation der Methode CreateOffice() in der Klasse Company
method body RemoveOffice in class Company {
/* check preconditions */
if (!refOffice in self->m_setrefOffice) return (false);
if (count(self->m_setrefOffice) <= 1) return (false);
/* destroy component */
refOffice->Destroy();
self->m_setrefOffice -= unique set(refOffice);
/* check postconditions */
if (!self->IsConsistent()) return (false);
return (true);
};/* end RemoveOffice */
Listing 6-23: Implementation der Methode RemoveOffice() in der Klasse
Company
method body DestroyOffice in class Company {
/* destroy component */
if (refOffice in self->m_setrefOffice)
self->m_setrefOffice -= unique set(refOffice);
/* check postconditions */
-- NOTE: This method can cause inconsistent state.
-- TODO: Check consistency outside this method by calling
IsConsistent()
};/* end DestroyOffice */
Listing 6-24: Implementation der Methode DestroyOffice() in der Klasse
Company
method body FindOffice in class Company {
o2 unique set(Office) refsetOffice; /* resultset for OQL
query */
156 • Umsetzung
Diplomarbeit
/* query item with given key values */
o2query(refsetOffice,"\
select e from e in $1 \
where x->m_nNumber = $2",
self->m_setrefOffice,m_nNumber);
if (count(refsetOffice)==0) return ((o2 Office)0);
else return (element(refsetOffice));
};/* end FindOffice */
Listing 6-25: Implementation der Methode FindOffice() in der Klasse Company
6.2.2.3 Inverse Beziehungen
%HOLHELJH$VVR]LDWLRQHQ]ZLVFKHQ]ZHL.ODVVHQZHUGHQLQGHU
7HUPLQRORJLHYRQ'(,026LQYHUVH%H]LHKXQJHQJHQDQQW
,QYHUVH%H]LHKXQJHQZHUGHQLQGHU+DUG\GDWHLDQKDQGLKUHV
7\SVHUNDQQW
type = "inverse relation"
'XUFKGLH(LQWUlJH
'cardinality begin' = "1"
'cardinality end' = "7+"
VLQGGLH.DUGLQDOLWlWVHLQVFKUlQNXQJHQDQGHQEHLGHQ(QGHQ
GHU.DQWHGHILQLHUW'LHVH$QJDEHQZHUGHQYRP(QWZHUIHU
IHVWJHOHJWXQGIJHQGHU'DWHQEDVLVZHLWHUH
.RQVLVWHQ]EHGLQJXQJHQKLQ]X
,PNRQNUHWHQ)DOO%HLVSLHO),6N|QQWHLQGHU+DUG\GDWHL
HLQHLQYHUVH%H]LHKXQJ]ZLVFKHQGHQ.QRWHQOfficeXQG
EmployeeZLHIROJWDEJHOHJWVHLQ
arc('cardinality begin' = "1",
'cardinality end' = "7+",
name = "inhabitants",
type = "inverse relation",
id = 87326,
card = 87936,
images = [87330],
connections = [[86212, 87245]],
arc_image_type = "inverse relation arc").
Listing 6-26: Beispiel einer inversen Beziehung in der Hardydatei
(LQHLQYHUVH%H]LHKXQJPXVVDXV*UQGHQGHU
/|VFKIRUWSIODQ]XQJYRQEHLGHQEHWHLOLJWHQ,QVWDQ]HQDXI
E]ZDEJHEDXWZHUGHQN|QQHQ6RPLWPVVHQEHL(UNHQQXQJ
HLQHUGHUDUWLJHQ%H]LHKXQJEHLGH.ODVVHQXPHLQLJH
0HWKRGHQXQG$WWULEXWHHUZHLWHUWZHUGHQ
m_refset<ClassName> : unique
set(<ClassName>)
0LW+LOIHGLHVHV$WWULEXWHVZHUGHQGLH5HIHUHQ]HQDXIGLH
2EMHNWHYHUZDOWHWPLWGHQHQPDQLQ%H]LHKXQJVWHKW'XUFK
GLH6SHLFKHUXQJGLHVHU5HIHUHQ]HQZHUGHQ2EMHNWHSHUVLVWHQW
ZHVKDOEEHLGHU/|VFKXQJGHVUHIHUHQ]LHUWHQ2EMHNWHVYJO
Å.RPSRQHQWHQEH]LHKXQJµ6HLWHGDUDXIJHDFKWHW
ZHUGHQPXVVGDVVGLHVH5HIHUHQ]JOHLFKIDOOVHQWIHUQWZLUG
Attach<ClassName>(ref<ClassName>:<ClassName
>)
'LH0HWKRGHEDXWHLQHLQYHUVH%H]LHKXQJ]XGHU.ODVVH
ClassNameDXI
$OV9RUEHGLQJXQJHQZLUG]XPHLQHQVLFKHUJHVWHOOWGDVVGLH
0D[LPDONDUGLQDOLWlWQLFKWEHUWURIIHQZLUGXQG]XP
DQGHUHQGDVVQLFKWEHUHLWVHLQH%H]LHKXQJ]XGHUGXUFKGHQ
EHUJHEHQHQ3DUDPHWHUUHIHUHQ]LHUWHQ,QVWDQ]H[LVLWHUW
8PHLQHHFKWHLQYHUVH%H]LHKXQJHLQULFKWHQ]XN|QQHQPXVV
Diplomarbeit
Umsetzung • 157
DQVFKOLHVVHQGGLHEHWHLOLJWH,QVWDQ]YHUDQODVVWZHUGHQ
LKUHUVHLWVGLH9HUELQGXQJDXI]XEDXHQ'LHVJHVFKLHKWGXUFK
GHQ$XIUXIGHU3DUWQHUPHWKRGH
AttachInverse<OwnClassName>ZHOFKHHQWVSUHFKHQG
YRQGHU.ODVVHClassName]XU9HUIJXQJJHVWHOOWZHUGHQ
PXVV
.RQQWHGLH%H]LHKXQJYRQGHUEHWHLOLJWHQ,QVWDQ]HUIROJUHLFK
HLQJHULFKWHWZHUGHQNDQQQXQGLHJHOLHIHUWH5HIHUHQ]LQGLH
5HIHUHQ]PHQJHHLQJHWUDJHQZHUGHQXQGGLH1DFKEHGLQJXQJ
YDOLGLHUWZHUGHQ
Detach<ClassName>(ref<ClassName>:<ClassName
>)
'LHVH0HWKRGHELOGHWGDVEH]LHKXQJVDEEDXHQGH$QDORJRQ]X
GHU0HWKRGHAttach
1DFKGHU3UIXQJGHU9RUEHGLQJXQJHQGDVVGLH
0LQLPDONDUGLQDOLWlWQLFKWXQWHUVFKULWWHQZLUGXQGEHUKDXSW
HLQH%H]LHKXQJ]XGHPEHUJHEHQHQ2EMHNWEHVWHKWZLUG
DQDORJ]XGHU$XIEDXIXQNWLRQGLHHQWVSUHFKHQGH
3DUWQHUPHWKRGHGHUUHIHUHQ]LHUWHQ,QVWDQ]DXIJHUXIHQ
1DFKGHP/|VFKHQDXVGHU5HIHUHQ]OLVWHZHUGHQLP
1DFKEHGLQJXQJVEORFNGLH.RQVLVWHQ]SUIXQJHQ
GXUFKJHIKUW
DetachInverse<ClName>(ref<ClName>:<ClName>)
'LHVH0HWKRGHLVWGLHEHVFKULHEHQH3DUWQHUIXQNWLRQIUGHQ
$XIEDXGHULQYHUVHQ%H]LHKXQJ
AttachInverse<ClName>(ref<ClName>:<ClName>)
'LHVH0HWKRGHLVWGLHEHVFKULHEHQH3DUWQHUIXQNWLRQIUGHQ
$EEDXGHULQYHUVHQ%H]LHKXQJ
$OOH0HWKRGHQUHWRXUQLHUHQHLQHQERRO·VFKHQ:HUWGHUEHU
GHQ(UIROJGHV%H]LHKXQJVDXIE]ZDEEDXV$XVNXQIWJLEW
,PNRQNUHWHQ)DOO%HLVSLHO),6N|QQWHQGLHJHQHULHUWHQ
0HWKRGHQIUGLHLQYHUVH%H]LHKXQJ]ZLVFKHQ
OfficeXQGEmployeeZLHIROJWLPSOHPHQWLHUWVHLQ
$XIGHU6HLWHGHU.ODVVHEmployee
method body AttachOffice in class Employee {
/* check preconditions */
if (self->m_refOffice != (o2 Office)0) return (false);
/* attach referenced object */
if (!refOffice->AttachInverseEmployee(self)) return
(false);
self->m_refOffice = refOffice;
/* check postconditions */
if (!refOffice->IsConsistent()) return (false);
if (!self->IsConsistent()) return (false);
return (true);
};/* end AttachOffice */
Listing 6-27: Implementation der Methode AttachOffice() in der Klasse Employee
method body DetachOffice in class Employee {
/* check preconditions */
if (self->m_refOffice != refOffice) return (false);
/* detach referenced object */
if (!refOffice->DetachInverseEmployee(self)) return
(false);
self->m_refOffice = (o2 Office)0;
/* check postconditions */
158 • Umsetzung
Diplomarbeit
if (!refOffice->IsConsistent()) return (false);
if (!self->IsConsistent()) return (false);
return (true);
};/* end DetachOffice */
Listing 6-28: Implementation der Methode DetachOffice() in der Klasse
Employee
method body AttachInverseOffice in class Employee {
/* check preconditions */
if (self->m_refOffice != (o2 Office)0) return (false);
/* attach referenced object */
self->m_refOffice = refOffice;
/* check postconditions */
if (!self->IsConsistent()) return (false);
return (true);
};/* end AttachInverseOffice */
Listing 6-29: Implementation der Methode AttachInverseOffice() in der Klasse
Employee
method body DetachInverseOffice in class Employee {
/* check preconditions */
if (self->m_refOffice != refOffice) return (false);
/* detach referenced object */
self->m_refOffice = (o2 Office)0;
/* check postconditions */
if (!self->IsConsistent()) return (false);
return (true);
};/* end DetachInverseOffice */
Listing 6-30: Implementation der Methode DetachInverseOffice() in der Klasse
Employee
$XIGHU6HLWHGHU.ODVVHOffice
method body AttachEmployee in class Office {
/* check preconditions */
if (refEmployee in self->m_setrefEmployee) return (false);
/* attach referenced object */
if (!refEmployee->AttachInverseOffice(self)) return
(false);
self->m_setrefEmployee += unique set(refEmployee);
/* check postconditions */
if (!refEmployee->IsConsistent()) return (false);
if (!self->IsConsistent()) return (false);
return (true);
};/* end AttachEmployee */
Listing 6-31: Implementation der Methode AttachEmployee() in der Klasse Office
method body DetachEmployee in class Office {
/* check preconditions */
if (count(self->m_setrefEmployee) <= 7) return (false);
if (!refEmployee in self->m_setrefEmployee) return
(false);
/* detach referenced object */
if (!refEmployee->DetachInverseOffice(self)) return
(false);
self->m_setrefEmployee -= unique set(refEmployee);
/* check postconditions */
if (!refEmployee->IsConsistent()) return (false);
if (!self->IsConsistent()) return (false);
return (true);
};/* end DetachEmployee */
Listing 6-32: Implementation der Methode DetachEmployee() in der Klasse
Office
method body AttachInverseEmployee in class Office {
/* check preconditions */
if (refEmployee in self->m_setrefEmployee) return (false);
Diplomarbeit
Umsetzung • 159
/* attach referenced object */
self->m_setrefEmployee += unique set(refEmployee);
/* check postconditions */
if (!self->IsConsistent()) return (false);
return (true);
};/* end AttachInverseEmployee */
Listing 6-33: Implementation der Methode AttachInverseEmployee() in der
Klasse Office
method body DetachInverseEmployee in class Office {
/* check preconditions */
if (count(self->m_setrefEmployee) <= 7) return (false);
if (!refEmployee in self->m_setrefEmployee) return
(false);
/* detach referenced object */
self->m_setrefEmployee -= unique set(refEmployee);
/* check postconditions */
if (!self->IsConsistent()) return (false);
return (true);
};/* end DetachInverseEmployee */
Listing 6-34: Implementation der Methode DetachInverseEmployee() in der
Klasse Office
6.2.2.4 Instantiierung
,Q2&ZLUGHLQ(LQVWLHJVSXQNWPLWGHU$QZHLVXQJ
name persistenterName : typedef;
GHILQLHUWYJO´(LQVWLHJVSXQNWHµ6HLWH'DEHLPXVVGHU
SHUVLVWHQWH1DPHGHPHQWVSUHFKHQGHQ.QRWHQGHV7\SV
(LQVWLHJVSXQNWHQWQRPPHQZHUGHQXQGGHU1DPHGHV7\SV
GHPHQWVSUHFKHQGHQ.ODVVHQNQRWHQ'LHVHEHLGHQ.QRWHQ
VLQGEHUGHQ,QVWDQWLLHUXQJVSIHLOPLWHLQDQGHUYHUEXQGHQ
ZHVKDOEGLHVH.DQWHIUGLH*HQHULHUXQJGHU
'HILQLWLRQVDQZHLVXQJIUGHQ(LQVWLHJVSXQNWKHUDQJH]RJHQ
ZHUGHQPXVV
,QGHU+DUG\GDWHLZHUGHQGHUDUWLJH3IHLOHDQKDQGLKUHV
7\SHQHLQWUDJHV
type = "instantiation"
HUNDQQW
1DFKIROJHQGVHLIUGHV%HLVSLHO),6GLH5HSUlVHQWDWLRQGHU
,QVWDQWLLHUXQJGHU.ODVVHCompanyGXUFKGHQ(LQVWLHJVSXQNW
MacrohardLQGHU+DUG\GDWHLDXIJHIKUW
arc(type = "instantiation",
id = 86664,
card = 87936,
images = [86667],
connections = [[86660, 86207]],
arc_image_type = "instantiation arc").
Listing 6-35: Beispiel eines Instantiierungspfeil in der Hardydatei
6.2.2.5 Evolution
:LUG]ZLVFKHQ]ZHL.QRWHQHLQ(YROXWLRQVSIHLOJH]HLFKQHW
VRZLUGGDPLWGLH)lKLJNHLWGHU$XVJDQJVNODVVHEHVFKULHEHQ
,QVWDQ]PLJUDWLRQ]XU=LHONODVVHXQWHUQHKPHQ]XN|QQHQ
(LQ(YROXWLRQVSIHLOZLUGLQGHU+DUG\GDWHLDQKDQGVHLQHV
7\SHQHLQWUDJHVGHU)RUP
type = "evolution"
HUNDQQW'XUFKGLH%HVFKULIWXQJGHV3IHLONRQVWUXNWHVPLW
GHP1DPHQGHU(YROXWLRQVIXQNWLRQZLUGGHU(LQWUDJ
'evolution function' = FunctionName
160 • Umsetzung
Diplomarbeit
JHVFKULHEHQZHOFKHUEHLGHU8PVHW]XQJGHQ
VWDQGDUGPlVVLJHQ1DPHQGHU(YROXWLRQVIXQNWLRQ
EHUVFKUHLEW
(LQH.DQWHQGHILQLWLRQGHV7\SV¶(YROXWLRQ·N|QQWHLQHLQHP
NRQNUHWHQ)DOO%HLVSLHO),6ZLHIROJWJHIXQGHQZHUGHQ
arc('evolution function' = "Enrich()",
type = "evolution",
id = 86258,
card = 87936,
images = [86262],
connections = [[86217, 86222]],
arc_image_type = "evolution arc").
Listing 6-36: Beispiel einer Evolutionsbeziehung in der Hardydatei
'LH2EMHNWHYROXWLRQZLUGYRQGHU%HVLW]HUNODVVHGHUEHLGHQ
EHWHLOLJWHQ.ODVVHQNRQWUROOLHUWZHVKDOEGLHVHU]XVlW]OLFKH
0HWKRGHQ]XU9HUZDOWXQJGHV0LJUDWLRQVSUR]HVVHV
KLQ]XJHIJWZHUGHQPVVHQ
Evolve<SrcClass>To<DestClass>(
ref<SrcClass>:<ScrClass>):<DestClass>
0LW+LOIHGLHVHU0HWKRGHZLUGGLHUHIHUHQ]LHUWH,QVWDQ]GHU
$XVJDQJVNODVVHSrcClassLQHLQHQHXH,QVWDQ]GHU.ODVVH
DestClassXPJHVHW]W
'DIUGLHXQWHUVXFKWH'DWHQEDVLVGLH2EMHNWHYROXWLRQQLFKW
XQWHUVWW]WZLUGPXVVGLHVHGXUFKGDV(U]HXJHQHLQHUQHXHQ
,QVWDQ]GHU=LHONODVVHGLH=XZHLVXQJGHUJHPHLQVDPHQ
'DWHQXQGGLH/|VFKXQJGHUREVROHWHQ,QVWDQ]VLPXOLHUW
ZHUGHQ
)UGLH=XZHLVXQJGHUGHQEHLGHQ,QVWDQ]HQJHPHLQHQ'DWHQ
ZLUGGLH0HWKRGHAssign]X+LOIHJHQRPPHQ
1DFKHUIROJUHLFKHU0LJUDWLRQLQVEHVRQGHUHZHQQGLH
.RQVLVWHQ]HUUHLFKWZHUGHQNRQQWHZLUGGLH5HIHUHQ]DXIGLH
QHXH,QVWDQ]GHU=LHONODVVH]XUFNJHOLHIHUW
Assign<SrcClass>To<DestClass>(
ref<SrcClass>:<ScrClass>,
ref<DestClass>:<DestClass>)
0LWGLHVHU0HWKRGHZHUGHQ'DWHQYRP$XVJDQJVREMHNWLQ
GDV=LHOREMHNWEHUWUDJHQ'LH=XZHLVXQJEHVFKUlQNWVLFK
DXVVFKOLHVVOLFKDXIGLHJHPHLQVDPHQ$WWULEXWHGLHLQGHU
EH]JOLFKGHU9HUHUEXQJVEH]LHKXQJHQJHPHLQVDPHQ
9DWHUNODVVHHQWKDOWHQVLQG
(LQJHVFKORVVHQVLQGQHEHQGHQH[SOL]LWHQ
EHQXW]HUGHILQLHUWHQ$WWULEXWHQDXFKLPSOL]LWHZHOFKH
DXIJUXQGYRQ%H]LHKXQJHQZHOFKHGLH.ODVVHXQWHUKlOW
JHQHULHUWZRUGHQVLQG'DPLWLVWVLFKHUJHVWHOOWGDVV
9HUELQGXQJHQ]XDQGHUHQ2EMHNWHQGLHYRP$XVJDQJVREMHNW
DXVJHKHQWURW]GHUbQGHUXQJGHU2EMHNWLGHQWLWlWEHLGHU
0LJUDWLRQ]XP=LHOREMHNWHUKDOWHQEOHLEHQ
,P%HLVSLHO),6N|QQHQ,QVWDQ]HQGHU.ODVVHDeveloper]X
,QVWDQ]HQGHU.ODVVHManagerZHOFKHEHLGH.LQGHUGHU
.ODVVHEmployeeVLQGPLJULHUHQ'HU(YROXWLRQVSUR]HVV
ZLUGYRP%HVLW]HUREMHNWGHU.ODVVHCompanyJHVWHXHUW
method body EvolveDeveloperToManager in class Company {
o2 Manager refManager;
/* create new Manager */
refManager = self->AddManager(MercedesType);
if (refManager == (o2 Manager)0) return ((o2 Manager)0);
Diplomarbeit
Umsetzung • 161
/* assign shared data */
self->AssignDeveloperToManager(refDeveloper,refManager);
/* remove obsolete Developer */
if (!self->RemoveDeveloper(refDeveloper)) return ((o2
Manager)0);
return (refManager);
};/* end EvolveDeveloperToManager */
Listing 6-37: Implementation der Methode EvolveDeveloperToManager() in der
Klasse Company
method body AssignDeveloperToManager in class Company {
/* assign data of parent Employee */
refManager->m_strName = refDeveloper->m_strName;
refManager->m_Address = refDeveloper->m_Address;
refManager->m_refOffice = refDeveloper->m_refOffice;
};/* end AssignDeveloperToManager */
Listing 6-38: Implementation der Methode AssignDeveloperToManager() in der
Klasse Company
6.2.2.6 Beobachtungsbeziehungen
%HREDFKWXQJVEH]LHKXQJHQVLQGHLQVHLWLJH%H]LHKXQJHQYRQ
WUDQVLHQWHQ]XSHUVLVWHQWHQ2EMHNWHQ
,QGHU+DUG\GDWHLN|QQHQVLHEHUGHQ(LQWUDJ
type = "observe"
LGHQWLIL]LHUWZHUGHQ'XUFKGLH'HILQLWLRQGHU.DUGLQDOLWlW
cardinality = CardinalityConstraint
NDQQGLH,QWHJULWlWHLQHU,QVWDQ]]XVlW]OLFKJHVLFKHUWZHUGHQ
'HU(LQWUDJ
name = ObservedCriteria
VWDPPWDXVGHU3IHLOEHVFKULIWXQJXQGKDWGXUFKVHLQHUHLQ
EHVFKUHLEHQGH1DWXUGLH$XIJDEHGDV9HUVWlQGQLVXQGGLH
/HVEDUNHLW]XI|UGHUQ
,PNRQNUHWHQ)DOOGHV%HLVSLHOV),6ILQGHWVLFKLQGHU
+DUG\GDWHLIROJHQGH(LQWUDJXQJ
arc(cardinality = "N*",
name = "Offices first floor",
type = "observe",
id = 86278,
card = 87936,
images = [86282],
connections = [[86242, 86212]],
arc_image_type = "observe arc").
Listing 6-39: Beispiel einer Beobachtungsbeziehung in der Hardydatei
'DGLHVHU%H]LHKXQJVW\SHLQVHLWLJLVWNDQQQLFKWVLFKHUJHVWHOOW
ZHUGHQREGDV%HREDFKWXQJVNULWHULXP]XMHGHU=HLWHUIOOW
LVW/|VFKXQJHQXQG(U]HXJXQJHQN|QQHQGLH$QVLFKW
EHHLQIOXVVHQXQGXQJOWLJPDFKHQ$XVGLHVHP*UXQGLVW
VWUHQJGDUDXI]XDFKWHQGDVVYRUMHGHP=XJULIIEHUGLHVH
%H]LHKXQJDXIGLH2EMHNWHLQGHU'DWHQEDVLVGLH
5HIHUHQ]PHQJHDNWXDOLVLHUWZLUG
'DUDXVIROJWGDVVIUGLH+LOIVNODVVHQGLH
%HREDFKWXQJVEH]LHKXQJHQ]XU'DWHQEDVLVXQWHUKDOWHQ
]XVlW]OLFKH0HWKRGHQXQG$WWULEXWHJHQHULHUWZHUGHQ
PVVHQ
m_setref<ClassName> : unique
set(<ClassName>)
$WWULEXW]XU6SHLFKHUXQJGHU5HIHUHQ]HQDXIGLH
EHREDFKWHWHQ2EMHNWHGHU'DWHQEDVLVYRP7\SClassName
9RUVLFKW'LHVH0HQJHZLUGGXUFK0DQLSXODWLRQHQDXIGHU
'DWHQEDVLVQLFKWDNWXDOLVLHUW
162 • Umsetzung
Diplomarbeit
Update<ClassName>()
$NWXDOLVLHUWGLH%HREDFKWXQJVDQVLFKW
'LHVH0HWKRGHLVW]XU6LFKHUXQJGHU,QWHJULWlWVWHWV]X
%HJLQQYRQ|IIHQWOLFKHQ0HWKRGHQDXI]XUXIHQ
'LH0HWKRGHZLUGQXUSURWRW\SDUWLJLPSOHPHQWLHUW'HU
(QWZLFNOHULVWDQJHKDOWHQGDV%HREDFKWXQJVNULWHULXP
JHJHEHQHQIDOOVDQGDVJHZQVFKWH9HUKDOWHQDQ]XSDVVHQ
,PNRQNUHWHQ)DOO%HLVSLHO),6N|QQWHQGLHJHQHULHUWHQ
0HWKRGHQIUGLH%HREDFKWXQJVEH]LHKXQJYRQGHU.ODVVH
OfficeList]XOfficeZLHIROJWLPSOHPHQWLHUWVHLQ
method body UpdateOffice in class OfficeList {
o2 unique set(Office) refsetOffice; /*result set for OQL
query*/
/* update view by querying database */
o2query(refsetOffice,"SELECT e FROM e IN $1",self>m_setrefOffice);
-- TODO: Edit above o2query satisfying your criteria */
};/* end UpdateOffice */
Listing 6-40: Die Methode UpdateOffice in der Klasse OfficeList
6.3 Umsetzung eines
Transaktionsdiagramms
,QHLQHP7UDQVDNWLRQVGLDJUDPPN|QQHQ
• $SSOLNDWLRQHQ
• 6XEV\VWHPH
• 3URJUDPPH
• )XQNWLRQHQXQG
• 7UDQVDNWLRQHQ
DOV.QRWHQXQG
• $XIUXIH
DOV.DQWHQHQWKDOWHQVHLQ$QDORJ]XGHQ6FKHPDGLDJUDPPHQVROOHQEHLGHU
8PVHW]XQJJUXQGVlW]OLFKGLH.QRWHQHOHPHQWHHLQHP2EMHNW]XJHRUGQHW
ZHUGHQXQGDQVFKOLHVVHQGGLH.DQWHQHOHPHQWHLQ%H]LHKXQJHQ]ZLVFKHQGHQ
2EMHNWHQXPJHVHW]WZHUGHQ,P*HJHQVDW]]XGHQ6FKHPDGLDJUDPPHQ
N|QQHQ7UDQVDNWLRQVGLDJUDPPHJHVFKDFKWHOWVHLQLQ+DUG\N|QQHQ
6XEV\VWHPNQRWHQ]XZHLWHUHQ6XEV\VWHPRGHU7UDQVDNWLRQVGLDJUDPPHQ
H[SDQGLHUWZHUGHQ%HLGHU8PVHW]XQJPVVHQDOVR]XVlW]OLFKGLHVH
*OLHGHUXQJVHEHQHQHQWIHUQWZHUGHQ
6.3.1 Umsetzung der Knoten
*UXQGVlW]OLFKZLUGMHGHP.QRWHQHLQH,QVWDQ]HLQHUHQWVSUHFKHQGHQ
.ODVVH]XJHRUGQHW)U+DXSWSURJUDPPNQRWHQLVWGLH
$SSOLNDWLRQVGHILQLWLRQLQ2&]XJHQHULHUHQZlKUHQGIUGLH.QRWHQ
3URJUDPP)XQNWLRQXQG7UDQVDNWLRQSURWRW\SDUWLJH
,PSOHPHQWDWLRQHQ]XHU]HXJHQVLQG
6XEV\VWHPNQRWHQGLHQHQOHGLJOLFKGHU6WUXNWXULHUXQJGHU$QVLFKWLQ
YHUVFKLHGHQH7HLODQVLFKWHQZHVKDOEGLHVHQXUIUGLHYLVXHOOH
$XIEHUHLWXQJLQQHUKDOEGHU26:22'$QVLFKWHQYHUDUEHLWHWXQG
IUGLH,PSOHPHQWDWLRQKHUDXVJHILOWHUWZHUGHQ
6.3.1.1 Applikationen
$SSOLNDWLRQHQVLQG3URJUDPPXQG7UDQVDNWLRQVVDPPOXQJHQ
XQGELOGHQLQEH]XJDXIHLQH'DWHQEDVLVHLQHDEJHVFKORVVHQH
)XQNWLRQVHLQKHLWGLHDXVYHUVFKLHGHQHQ/HVHXQG
Diplomarbeit
Umsetzung • 163
6FKUHLEWUDQVDNWLRQHQEHVWHKW'HUDUWLJH.RQVWUXNWHZHUGHQ
DQKDQGGHV7\SHQHLQWUDJHV
type = "main program"
HUNDQQW'HUYRP6FKHPDHQWZHUIHUGHILQLHUWH1DPH
UHSUlVHQWLHUWGXUFKGLH(LQJHVFKDIW
name = "FIS"
LGHQWLIL]LHUWGLH$SSOLNDWLRQXQGVWHOOWGHQVSlWHUHQ=XJULII
IUGHQ$XIUXIVLFKHU
)UGDV$GPLQLVWUDWLRQVEHLVSLHO),6NDQQHLQHQWVSUHFKHQGHU
(LQWUDJZLHIROJWJHIXQGHQZHUGHQ
node(name = "FIS",
type = "main program",
id = 87784,
card = 87770,
images = [87789],
arcs = [87817, 87821, 87825]).
Listing 6-41: Beispiel einer Applikation in der Hardydatei
,QGHU6FKHPDGHILQLWLRQVVSUDFKH2&ZLUGHLQH$SSOLNDWLRQ
QDFKGHPIROJHQGHQ6\QWD[GHILQLHUWYJO>*HSSHUWS
@
appdef
::= application AppName
program
programme[,
tra_tionen]
end;
programme ::= program (,program)*
program
::= [public|private]
ProgramName
tra_tionen ::= tra_tion (,tra_tion)*
tra_tion
::= [public|private]
TransName(
(ParamName:ParamType)*):Type
Syntaxdiagramm 6-3: Syntax einer Applikationsdefinition in O2C
(LQH$SSOLNDWLRQVGHILQLWLRQEHVWHKWDOVRLPZHVHQWOLFKHQDXV
GHU$QJDEHGHV1DPHQVXQGGHUGDULQHQWKDOWHQHQ
3URJUDPPHXQG7UDQVDNWLRQHQ(UVWHUHZHUGHQDEHUQLFKW
PLWLKUHUJHVDPWHQ6LJQDWXUGDUJHVWHOOW'DUDXVIROJWGDVVGHU
1DPHGHV3URJUDPPHVIUHLQH$SSOLNDWLRQHLQGHXWLJ
JHZlKOWZHUGHQPXVV,QVEHVRQGHUHVLQGDOVRNHLQH
0|JOLFKNHLWHQIUGLHhEHUODGXQJJHJHEHQ
,PNRQNUHWHQ)DOO%HLVSLHO),6LVWGLH$SSOLNDWLRQ),6ZLH
IROJWLQGHUJHQHULHUWHQ'DWHL]XILQGHQ
application FIS
program
/* programs */
public HireDeveloper,
public FireDeveloper,
public MakeManager,
public PrintOfficeList,
public AssignEmplToOff,
/* transactions */
public FireDev(d:Dev) : boolean,
public HireDev(0:Office) : boolean,
public MakeMan(d:Dev) : Man,
public AssignEmplToOff(e:Empl,o:Office) : integer,
public DeleteOffice() : boolean
end;
Listing 6-42: Definition der Applikation FIS
6.3.1.2 Programme
164 • Umsetzung
Diplomarbeit
3URJUDPPHVLQG6DPPOXQJHQYRQ)XQNWLRQHQXQG
7UDQVDNWLRQHQ6LHNDSVHOQDOVRZLHLQDQGHUHQ
7HUPLQRORJLHQZHOFKHGLHVHQ%HJULIIYHUZHQGHQ
$QZHLVXQJVEO|FNHXPHLQK|KHUDEVWUDKLHUWHV9HUKDOWHQ
PRGHOOLHUHQ]XN|QQHQ'HUDUWLJH.RQVWUXNWHZHUGHQDQKDQG
GHV7\SHQHLQWUDJHV
type = "program"
HUNDQQW'HU(QWZHUIHUNDQQGXUFKGLH'HILQLWLRQGHU
$WWULEXWH
name = ProgramName,
'pseudo code' = PseudoCode
VRZRKOGHQ1DPHQGHV3URJUDPPHVDOVDXFKGLH
SVHXGRFRGHDUWLJH%HVFKUHLEXQJGHV3URJUDPPDEODXIHV
IHVWOHJHQ
)UGDV$GPLQLVWUDWLRQVEHLVSLHO),6NDQQHLQHQWVSUHFKHQGHU
(LQWUDJZLHIROJWJHIXQGHQZHUGHQ
node(name = "HireDeveloper",
'pseudo code' = "",
type = "program",
id = 87832,
card = 87770,
images = [87834],
arcs = [87859]).
Listing 6-43: Beispiel eines Programmes in der Hardydatei
,QGHU6FKHPDGHILQLWLRQVVSUDFKH2&ZLUGHLQH$SSOLNDWLRQ
QDFKGHPIROJHQGHQ6\QWD[GHILQLHUWYJO>*HSSHUWS
@
programm
::= program body ProgramName
in application AppName block
block
::= { [variables] statement }
variables ::= (vardef)*
vardef
::= o2 (TypeName|ClassName)
VarName ;
Syntaxdiagramm 6-4: Programmdefinition in O2C
(LQH3URJUDPPGHILQLWLRQEHVWHKWDOVRLPZHVHQWOLFKHQDXV
HLQHP.RSIWHLOZHOFKHUGLH9HUNQSIXQJ]XU$SSOLNDWLRQ
KHUVWHOOWXQGGHP$QZHLVXQJVEORFNGHUYRQ
9DULDEOHQGHNODUDWLRQHQDQJHIKUWVHLQNDQQ
(LQHYRQ26:22'JHQHULHUWH3URJUDPPLPSOHPHQWDWLRQ
IROJWVWHWVHLQHPEHVWLPPWHQ0XVWHUXQGHQWKlOW
GHPHQWVSUHFKHQGLPPHUGLHVHOEHQ$EVFKQLWWH
9DULDEOHQGHILQLWLRQ
)UMHGHQGXUFKHLQH.DQWHQYHUELQGXQJDQJHGHXWHWHQ$XIUXI
HLQHU)XQNWLRQRGHU7UDQVDNWLRQZLUGHLQHORNDOH9DULDEOH
GHNODULHUWZHOFKHGHQ5FNJDEHZHUWGHUHQWVSUHFKHQGHQ
6XEURXWLQHDXIQHKPHQNDQQ
=XGHPZLUGIUMHGHQhEHUJDEHSDUDPHWHUHLQHORNDOH
9DULDEOHGHVJHIRUGHUWHQ7\SVLQVWDQWLLHUW
9RUEHGLQJXQJHQ
'HU(QWZLFNOHULVWDXIJHIRUGHUWLQGLHVHU6HNWLRQGLHIUHLQH
HUIROJUHLFKH9HUDUEHLWXQJQRWZHQGLJHQ9RUDXVVHW]XQJHQ]X
SUIHQ
,QLWLDOLVLHUXQJ
(VNDQQQRWZHQGLJVHLQJHZLVVHQLQHLQHU3DUDPHWHUOLVWH
HLQHV6XEURXWLQHQDXIUXIHVHQWKDOWHQHQ9DULDEOHQ,QLWLDOZHUWH
Diplomarbeit
Umsetzung • 165
]X]XZHLVHQ6ROFKH=XZHLVXQJHQVLQGLGHDOHUZHLVHLQGLHVHP
$EVFKQLWWXQWHU]XEULQJHQ
,PSOHPHQWDWLRQ
'LHLP'LDJUDPPJH]HLFKQHWHQ$XIUXIHYRQ)XQNWLRQHQXQG
7UDQVDNWLRQHQZHUGHQJHPlVVGHULQGHQ(LJHQVFKDIWHQGHU
3IHLOHGHILQLHUWHQ5HLKHQIROJHLQGHQ,PSOHPHQWDWLRQVWHLO
HLQJHEDXW
(WZDLJHU3VHXGRFRGHZLUGLQHLQHP.RPPHQWDUEORFN
DXVJHJHEHQXQGGHP(QWZLFNOHU]XU$XVDUEHLWXQJ
DQJHERWHQ
1DFKEHGLQJXQJHQ
'HU(QWZLFNOHUNDQQGXUFKGLH3UIXQJYRQ
1DFKEHGLQJXQJHQJHIlKUOLFKH6LWXDWLRQHQHUNHQQHQXQG
GXUFKJHHLJQHWH0DVVQDKPHQNRUULJLHUHQGHLQZLUNHQ
'HUDUWLJH9DOLGLHUXQJHQVROOHQLP1DFKEHGLQJXQJVWHLODP
6FKOXVVGHU3URJUDPPLPSOHPHQWDWLRQXQWHUJHEUDFKWZHUGHQ
,PNRQNUHWHQ)DOO%HLVSLHO),6LVWGLH$SSOLNDWLRQ),6ZLH
IROJWLQGHUJHQHULHUWHQ'DWHL]XILQGHQ
program body HireDeveloper in application FIS {
o2 Office refOffice; /* return value of function
SelOffice*/
o2 boolean refboolean; /* return value of function
HireDev*/
o2 Office 0; /* parameter for function HireDev*/
/* check preconditions */
-- TODO: Add your validation code here
/* initialization section */
-- TODO: Add your initialization code here
/* implementation section */
refOffice=SelOffice();
refboolean=HireDev(0);
/* check postconditions */
-- TODO: Add your validation code here
} /* end HireDeveloper */
Listing 6-44: Implementation des Programmes HireDeveloper() in der Applikation
FIS
6.3.1.3 Funktionen
,Q)XQNWLRQHQVLQG$XIUXIH]XDQGHUHQ)XQNWLRQHQ
XQGRGHU]X7UDQVDNWLRQHQHQWKDOWHQ6LHZHUGHQDQKDQGGHV
7\SHQHLQWUDJHV
type = "function"
HUNDQQW'HU(QWZHUIHUNDQQGXUFKGLH'HILQLWLRQGHU
)XQNWLRQVDWWULEXWH
'name (params) return' =
FunctionDefinition,
'pseudo code' = PseudeCode
VRZRKOGHUHQ1DPH3DUDPHWHUXQG7\SDOVDXFKGHUHQ
SVHXGRFRGHDUWLJH$EODXIEHVFKUHLEXQJIHVWOHJHQ
)UGDV$GPLQLVWUDWLRQVEHLVSLHO),6NDQQHLQHQWVSUHFKHQGHU
(LQWUDJZLHIROJWJHIXQGHQZHUGHQ
node('name (params)
return'="SelDev(strName:String,nNumber:Integer):Dev",
'pseudo code' = "",
type = "function",
id = 87841,
card = 87770,
images = [87843],
arcs = [87859, 87867]).
166 • Umsetzung
Diplomarbeit
Listing 6-45: Beispiel einer Funktion in der Hardydatei
,QGHU6FKHPDGHILQLWLRQVVSUDFKH2&ZLUGHLQH)XQNWLRQ
QDFKGHPIROJHQGHQ6\QWD[GHILQLHUWYJO>*HSSHUWS
@
funktion
::= prototyp implement
prototyp
::= FunctionName ( [params] )
[: Type]
params
::= param (,param)*
param
::= ParamName : ParamType
implement ::= function body
FunctionName block
block
::= { [variables] statement }
variables ::= (vardef)*
vardef
::= o2 (TypeName | ClassName)
VarName ;
Syntaxdiagramm 6-5: Functionsdefinition in O2C
(LQH)XQNWLRQVGHILQLWLRQEHVWHKWDXVHLQHU
3URWRW\SGHNODUDWLRQGLHDEHULP*HJHQVDW]]XGHQ
3URJUDPPGHILQLWLRQHQNHLQH9HUNQSIXQJ]XU$SSOLNDWLRQ
KHUVWHOOW)XQNWLRQHQVLQGDOVRQLFKWDQ$SSOLNDWLRQHQ
JHEXQGHQXQGGHPWDWVlFKOLFKHQ)XQNWLRQVN|USHU,Q
OHW]WHUHPLVWHLQ$QZHLVXQJVEORFNHQWKDOWHQGHUYRQ
9DULDEOHQGHNODUDWLRQHQDQJHIKUWVHLQNDQQ
(LQHYRQ26:22'JHQHULHUWH)XQNWLRQVLPSOHPHQWDWLRQ
IROJWVWHWVHLQHPEHVWLPPWHQ0XVWHUXQGHQWKlOW
GHPHQWVSUHFKHQGLPPHUGLHVHOEHQ$EVFKQLWWH
9DULDEOHQGHILQLWLRQ
)UMHGHQGXUFKHLQH.DQWHQYHUELQGXQJDQJHGHXWHWHQ$XIUXI
HLQHU)XQNWLRQRGHU7UDQVDNWLRQZLUGHLQHORNDOH9DULDEOH
GHNODULHUWZHOFKHGHQ5FNJDEHZHUWGHUHQWVSUHFKHQGHQ
6XEURXWLQHDXIQHKPHQNDQQ
=XGHPZLUGIUMHGHQhEHUJDEHSDUDPHWHUHLQHORNDOH
9DULDEOHGHVJHIRUGHUWHQ7\SVLQVWDQWLLHUW
'HU5FNJDEHZHUWZLUGLQHLQHUORNDOHQ9DULDEOHQ
]ZLVFKHQJHVSHLFKHUWGLHJOHLFKVDPLQGLHVHU6HNWLRQ
GHNODULHUWZLUG
9RUEHGLQJXQJHQ
'LHLQGHU6FKQLWWVWHOOHEHUJHEHQHQ3DUDPHWHUZHUGHQDOV
9RUEHGLQJXQJHQYDOLGLHUW+DQGHOWHVVLFKEHLGLHVHQ'DWHQ
XP,QVWDQ]HQYRQ'DWHQEDQNNODVVHQOlVVWVLFKGLH3UIXQJ
GXUFKGLHYRUGHILQLHUWHYLUWXHOOH)XQNWLRQIsValid
HUOHGLJHQ
,QLWLDOLVLHUXQJ
(VNDQQQRWZHQGLJVHLQJHZLVVHQ9DULDEOHQLQVEHVRQGHUH
GHQLQHLQHU3DUDPHWHUOLVWHHLQHV6XEURXWLQHQDXIUXIHV
HQWKDOWHQHQ,QLWLDOZHUWH]X]XZHLVHQ6ROFKH=XZHLVXQJHQ
VLQGLGHDOHUZHLVHLQGLHVHP$EVFKQLWWXQWHU]XEULQJHQ
,PSOHPHQWDWLRQ
'LHLP'LDJUDPPJH]HLFKQHWHQ$XIUXIHYRQ)XQNWLRQHQXQG
7UDQVDNWLRQHQZHUGHQJHPlVVGHULQGHQ(LJHQVFKDIWHQGHU
3IHLOHGHILQLHUWHQ5HLKHQIROJHLQGHQ,PSOHPHQWDWLRQVWHLO
HLQJHEDXW
Diplomarbeit
Umsetzung • 167
(WZDLJHU3VHXGRFRGHZLUGLQHLQHP.RPPHQWDUEORFN
DXVJHJHEHQXQGGHP(QWZLFNOHU]XU$XVDUEHLWXQJ
DQJHERWHQ
1DFKEHGLQJXQJHQ
'HU(QWZLFNOHUNDQQGXUFKGLH3UIXQJYRQ
1DFKEHGLQJXQJHQJHIlKUOLFKH6LWXDWLRQHQHUNHQQHQXQG
GXUFKJHHLJQHWH0DVVQDKPHQNRUULJLHUHQGHLQZLUNHQ
'HUDUWLJH9DOLGLHUXQJHQVROOHQLP1DFKEHGLQJXQJVWHLODP
6FKOXVVGHU3URJUDPPLPSOHPHQWDWLRQXQWHUJHEUDFKWZHUGHQ
5FNJDEH
)DOOVIUGLH)XQNWLRQHLQ7\SGHILQLHUWZRUGHQLVWZLUGHLQ
HQWVSUHFKHQGHU5FNJDEHZHUWDQGHQDXIUXIHQGHQ
3URJUDPPIDGHQ]XUFNJHOLHIHUW'DEHLKDWGLH=XZHLVXQJ
GLHVHV:HUWHVLQGHU,PSOHPHQWDWLRQ]XHUIROJHQXQGGHVVHQ
9DOLGLHUXQJLP5DKPHQGHU1DFKEHGLQJXQJHQ]XHUIROJHQ
,PNRQNUHWHQ)DOO%HLVSLHO),6LVWGLH$SSOLNDWLRQ),6ZLH
IROJWLQGHUJHQHULHUWHQ'DWHL]XILQGHQ
function
o2 Dev
o2 Man
o2 Dev
body SelectDev in application FIS {
refDevReturn; /* return value */
refMan; /* return value of function MakeMan */
d; /* parameter for function MakeMan */
/* check preconditions */
-- ASSERT: strName.IsValid());
-- ASSERT: nNumber.IsValid());
/* initialization section */
-- TODO: Add your initialization code here
/* implementation section */
refMan = MakeMan(d);
/* check postconditions */
-- TODO: Add your validation code here
return (refDevReturn);
} /* end SelectDev */
Listing 6-46: Definition der Funktion SelectDev() in der Applikation FIS
6.3.1.4 Transaktionen
,Q7UDQVDNWLRQHQVLQGGLHVFKUHLEHQGHQ=XJULIIHDXIGLH
SHUVLVWHQWHQ2EMHNWHGHU'DWHQEDVLVYHUSDFNW6LHZHUGHQ
DQKDQGGHV7\SHQHLQWUDJHV
type = "transaction"
HUNDQQW'HU(QWZHUIHUNDQQGXUFKGLH'HILQLWLRQGHV
$WWULEXWHV
'name (params) return' =
TransactionDefinition,
VRZRKOGHVVHQ1DPH3DUDPHWHUXQG7\SIHVWOHJHQ'LH
JHZQVFKWHQ$XIUXIHGHUVFKUHLEHQGHQ.ODVVHQPHWKRGHQ
ZHUGHQDOV
calls = Calls
LQGHU+DUG\GDWHLDXVJHZLHVHQ
)UGDV$GPLQLVWUDWLRQVEHLVSLHO),6NDQQHLQHQWVSUHFKHQGHU
(LQWUDJZLHIROJWJHIXQGHQZHUGHQ
node('name (params) return' = "MakeManager(d:Developer) :
Manager",
calls = "Macrohard.AddDev()",
type = "transaction",
id = 87850,
card = 87770,
images = [87852],
arcs = []).
168 • Umsetzung
Diplomarbeit
Listing 6-47: Beispiel einer Transaktion in der Hardydatei
,QGHU6FKHPDGHILQLWLRQVVSUDFKH2&ZLUGHLQH7UDQVDNWLRQ
QDFKGHPIROJHQGHQ6\QWD[GHILQLHUWYJO>*HSSHUWS
@
transakt
::= transaction body
FunctionName
in application AppName block
block
::= { [variables]
transaction
statement
(commit | abort)
}
variables ::= (vardef)*
vardef
::= o2 (TypeName|ClassName)
VarName ;
Syntaxdiagramm 6-6: Transaktionsdefinition in O2C
(LQH7UDQVDNWLRQVGHILQLWLRQEHVWHKWDXVGHPWDWVlFKOLFKHQ
7UDQVDNWLRQVN|USHUGLH3URWRW\SGHNODUDWLRQLVWLQGHU
$SSOLNDWLRQEHUHLWVHQWKDOWHQGHUDQDORJ]XGHQ
3URJUDPPGHILQLWLRQHQGLH9HUNQSIXQJ]XU$SSOLNDWLRQ
KHUVWHOOWXQGHLQHQ$QZHLVXQJVEORFNHQWKlOWZHOFKHUYRQ
9DULDEOHQGHNODUDWLRQHQDQJHIKUWVHLQNDQQ(LQH
7UDQVDNWLRQPXVVPLWGHP6FKOVVHOZRUWtransaction
HU|IIQHWZHUGHQXQGMHQDFK(UIROJGHU$NWLRQHQGXUFKHLQ
commitRGHUabortZLHGHUJHVFKORVVHQZHUGHQ
(LQHYRQ26:22'JHQHULHUWH7UDQVDNWLRQVLPSOHPHQWDWLRQ
IROJWVWHWVHLQHPEHVWLPPWHQ0XVWHUXQGHQWKlOW
GHPHQWVSUHFKHQGLPPHUGLHVHOEHQ$EVFKQLWWH
9DULDEOHQGHILQLWLRQ
)UMHGHQGXUFKHLQH.DQWHQYHUELQGXQJDQJHGHXWHWHQ$XIUXI
HLQHU)XQNWLRQRGHU7UDQVDNWLRQZLUGHLQHORNDOH9DULDEOH
GHNODULHUWZHOFKHGHQ5FNJDEHZHUWGHUHQWVSUHFKHQGHQ
6XEURXWLQHDXIQHKPHQNDQQ
=XGHPZLUGIUMHGHQhEHUJDEHSDUDPHWHUHLQHORNDOH
9DULDEOHGHVJHIRUGHUWHQ7\SVLQVWDQWLLHUW
'HU5FNJDEHZHUWZLUGLQHLQHUORNDOHQ9DULDEOHQ
]ZLVFKHQJHVSHLFKHUWGLHJOHLFKVDPLQGLHVHU6HNWLRQ
GHNODULHUWZLUG'DVVHOEHJLOWIUGHQERRO·VFKHQ:HUW
ZHOFKHUGLH.RQVLVWHQ]GHU'DWHQEDVLVZLGHUVSLHJHOW
9RUEHGLQJXQJHQ
'LHLQGHU6FKQLWWVWHOOHEHUJHEHQHQ3DUDPHWHUZHUGHQDOV
9RUEHGLQJXQJHQYDOLGLHUW+DQGHOWHVVLFKEHLGLHVHQ'DWHQ
XP,QVWDQ]HQYRQ'DWHQEDQNNODVVHQOlVVWVLFKGLH3UIXQJ
GXUFKGLHYRUGHILQLHUWHYLUWXHOOH)XQNWLRQIsValid
HUOHGLJHQ
,QLWLDOLVLHUXQJ
(VNDQQQRWZHQGLJVHLQJHZLVVHQLQHLQHU3DUDPHWHUOLVWH
HLQHV6XEURXWLQHQDXIUXIHVHQWKDOWHQHQ9DULDEOHQ,QLWLDOZHUWH
]X]XZHLVHQ6ROFKH=XZHLVXQJHQVLQGLGHDOHUZHLVHLQGLHVHP
$EVFKQLWWXQWHU]XEULQJHQ
7UDQVDNWLRQVEHJLQQ
9RUGHPHUVWHQVFKUHLEHQGHQ=XJULIIDXIGLHSHUVLVWHQWHQ
Diplomarbeit
Umsetzung • 169
2EMHNWHGHU'DWHQEDVLVPXVVHLQHQHXH7UDQVDNWLRQHU|IIQHW
ZHUGHQ
,PSOHPHQWDWLRQ
'LHLP'LDJUDPPJH]HLFKQHWHQ$XIUXIHYRQ)XQNWLRQHQXQG
7UDQVDNWLRQHQZHUGHQJHPlVVGHULQGHQ(LJHQVFKDIWHQGHU
3IHLOHGHILQLHUWHQ5HLKHQIROJHLQGHQ,PSOHPHQWDWLRQVWHLO
HLQJHEDXW
(WZDLJHU3VHXGRFRGHZLUGLQHLQHP.RPPHQWDUEORFN
DXVJHJHEHQXQGGHP(QWZLFNOHU]XU$XVDUEHLWXQJ
DQJHERWHQ
1DFKEHGLQJXQJHQ
(VLVWIUGLH(UKDOWXQJGHU'DWHQLQWHJULWlWYRQHPLQHQWHU
:LFKWLJNHLWGDVVDOOHPDQLSXOLHUWHQ2EMHNWHGHU'DWHQEDVLV
YRUQHKPOLFKGLHMHQLJHQDXIZHOFKHVFKUHLEHQGH0HWKRGHQ
DQJHZHQGHWZXUGHQDXI.RQVLVWHQ]JHSUIWZHUGHQ
7UDQVDNWLRQVVFKOXVV
,VWGLH.RQVLVWHQ]DP(QGHHLQHU7UDQVDNWLRQQLFKWJHJHEHQ
PXVVVLHDEJHEURFKHQZHUGHQ'LHDXIUXIHQGH5RXWLQHVROOWH
DQVFKOLHVVHQGGHUDUWLJH)HKOYHUDUEHLWXQJHQDQKDQGGHV
]XUFNJHOLHIHUWHQ:HUWHVHUNHQQHQN|QQHQXQGJHHLJQHWH
0DVVQDKPHQDXVO|VHQVHLGLHVLP0LQLPDOIDOOOHGLJOLFKGLH
8QWHUULFKWXQJGHV%HQXW]HUV
5FNJDEH
:DUGLH2EMHNWPDQLSXODWLRQHUIROJUHLFKZDVDQKDQGGHV
.RQVLVWHQ]LQGLNDWRUVIHVWJHVWHOOWZHUGHQNDQQVRZHUGHQ
GXUFKGLH$XVO|VXQJHLQHV7UDQVDNWLRQVVFKOXVVHVGLHQHXHQ
$WWULEXWZHUWHDXIGLH'DWHQEDVLV]XUFNJHVFKULHEHQ'LH
7UDQVDNWLRQWHUPLQLHUWLQGLHVHP)DOOPLWHLQHP(UIROJVZHUW
,PNRQNUHWHQ)DOO%HLVSLHO),6LVWGLH$SSOLNDWLRQ),6ZLH
IROJWLQGHUJHQHULHUWHQ'DWHL]XILQGHQ
transaction body MakeMan in application FIS {
o2 Man refManReturn; /* return value */
o2 boolean bIsConsistent; /* local variable indicating
consistency */
o2 boolean bSuccessful.MakeMan; /* return value of
function .MakeMan */
o2 Manager refManager; /* object having method .MakeMan */
o2 Object d; /* parameter for function .MakeMan */
/* check preconditions */
-- ASSERT: d.IsValid());
/* open a new transaction */
transaction;
/* initialization section */
-- TODO: Add your initialization code here
/* implementation section */
bSuccessful.MakeMan = refManager->.MakeMan(d);
/* check postconditions */
bIsConsistent = true;
bIsConsistent &&= refManager.IsConsistent();
/* if all affected objects are consistent commit
transaction */
if (bIsConsistent) commit;
else abort;
return (refManReturn);
} /* end MakeMan */
Listing 6-48: Definition der Transaktion MakeManager() in der Applikation FIS
170 • Umsetzung
Diplomarbeit
6.3.2 Umsetzung der Kanten
'LH.DQWHQZHUGHQDQDORJ]XGHU8PVHW]XQJGHU.DQWHQLP
6FKHPDGLDJUDPYJO´8PVHW]XQJGHU.DQWHQµ6HLWH
LQWHUSUHWLHUW6RPLWVLQGDXFKEHLGHU9HUDUEHLWXQJLQHLQHP
7UDQVDNWLRQVGLDJUDPPHLQ]LJGLH(LQWUlJH
type = TypeName
connections = [[FromNodeId, ToNodeId]]
YRQ,QWHUHVVH'HU7\SHQQDPHGLHQW]XU(UNHQQXQJGHV.DQWHQW\SV
ZlKUHQGGLH9DULDEOHconnectionsHLQHJHULFKWHWH
.QRWHQYHUELQGXQJGDUVWHOOW
6.3.2.1 Aufrufe
'XUFK$XIUXISIHLOHZHUGHQ9HUDUEHLWXQJVVSUQJHLQ
6XEURXWLQHQPRGHOOLHUWZREHLGHU$XVJDQJVNQRWHQGHQ
UXIHQGHQ3URJUDPPWHLOXQGGHU=LHONQRWHQGHQDXIJHUXIHQHQ
7HLOGDUVWHOOHQ
,QGHU+DUG\GDWHLN|QQHQVLHEHUGHQ(LQWUDJ
type = "call"
LGHQWLIL]LHUWZHUGHQ'XUFKGLH'HILQLWLRQHLQHU5DQJ]DKOGLH
VLFKLP(LQWUDJ
number = Number
ZLHGHUILQGHQOlVVWNDQQIU.QRWHQYRQZHOFKHQPHKUHUH
GHUDUWLJH3IHLOHDXVODXIHQHLQH$XIUXIVHTXHQ]DQJHJHEHQ
ZHUGHQ
,PNRQNUHWHQ)DOOGHV%HLVSLHOV),6ILQGHWVLFKLQGHU
+DUG\GDWHLIROJHQGH(LQWUDJXQJ
arc(number = "3",
type = "call",
id = 87821,
card = 87770,
images = [87824],
connections = [[87784, 87799]],
arc_image_type = "call").
Listing 6-49: Beispiel eines Aufrufes in der Hardydatei
$XIUXIHEHVFKUHLEHQVWHWV(LJHQVFKDIWHQGHUMHQLJHQ.QRWHQ
YRQGHQHQVLHDXVODXIHQXQGZHUGHQGHPHQWVSUHFKHQGQLFKW
GLUHNWLQGHU6FKHPDGHILQLWLRQVVSUDFKH2&UHSUlVHQWLHUW
VRQGHUQLPPHULQGLUHNWLP,PSOHPHQWDWLRQVWHLOGHV
EHHLQIOXVVWHQ.QRWHQVYJO´8PVHW]XQJGHU.QRWHQµ6HLWH
6.4 Bewertung der Umsetzung
%HLGHU8PVHW]XQJGHU(QWZXUIVNRQVWUXNWHLQGLH6FKHPDGHILQWLRQVVSUDFKH
ZHUGHQ.ODVVHQGHNODUDWLRQHQHU]HXJW6RPLWILQGHWGHU(QWZLFNOHUDOV
5HVXOWDWGHV(QWZXUIHVHLQ6FKHPDJHUVWGDV.ODVVHQ$SSOLNDWLRQHQ
3URJUDPPHXVZHQWKlOW26:22'JHKWQXQQRFKHLQHQ6FKULWWZHLWHUXQG
LQWHUSUHWLHUWGDV9HUKDOWHQZHOFKHVKDXSWVlFKOLFKYRQGHQ%H]LHKXQJHQ
DEJHOHVHQZHUGHQNDQQ]XU*HQHULHUXQJYRQLPSOL]LWHQ$WWULEXWHQXQG
0HWKRGHQ
'HU(QWZLFNOHUNDQQDOVRQLFKWQXUYRQHLQHPVWDUUHQXQGOHHUHQ
$QZHQGXQJVJHUVWVRQGHUQYRQEHUHLWVYRUJHIHUWLJWHQ,PSOHPHQWDWLRQHQ
GHV9HUKDOWHQVDXVJHKHQ(UVWHOOWVLFKDEHUGDEHLGLH)UDJHLQZHOFKHQ
6LWXDWLRQHQGLHVH0HWKRGHQYHUZHQGHWZHUGHQVROOHQ"
'LH)UDJHNDQQQLFKWVFKOVVLJEHDQWZRUWHWZHUGHQ9LHOPHKUVROOHQ
QDFKIROJHQGHLQLJHW\SLVFKH%HLVSLHOHHUOlXWHUWVHLQ
Diplomarbeit
Umsetzung • 171
6.4.1 Erzeugen von Instanzen
)UGLHQDFKIROJHQGHQ$XVIKUXQJHQVROOHUQHXWGDV%HLVSLHOGHU
.RQIHUHQ]DGPLQLVWUDWLRQKHUDQJH]RJHQZHUGHQHLQ
3URJUDPPNRPLWHHEHVWHKWDXV0LWJOLHGHUQXQGHLQJHUHLFKWHQ
3DSLHUHQ'LH3DSLHUHZHUGHQGHQ0LWJOLHGHUQ]XU3UIXQJ
]XJHRUGQHW
6.4.1.1 Fall I:
=ZLVFKHQGHQ3DSLHUHQXQGGHQ0LWJOLHGHUQEHVWHKWHLQH
ÅORVH´9HUELQGXQJ
PC
PCSS
1
1
0+
0+
Paper
PCMember
0+
[0,3]
Abbildung 6-1: Schemadiagramm mit „loser“ Verbindung
'DV(U]HXJHQYRQ,QVWDQ]HQGHU.ODVVHPaperXQG
PCMemberLVWSUREOHPORVXQGNDQQHLQIDFKEHUGLHGXUFK
GLH.RPSRQHQWHQEH]LHKXQJHQLPSOL]LHUWHQ0HWKRGHQ
AddPaperE]ZAddPCMemberGHU.ODVVHPCHUUHLFKW
ZHUGHQ
6.4.1.2 Fall II:
(WZDVVFKZLHULJHUZLUGGLH6LWXDWLRQZHQQ]ZLVFKHQGHQ
3DSLHUHQXQGGHQ0LWJOLHGHUQHLQHÅVWUHQJH´]ZLQJHQGH
9HUELQGXQJEHVWHKW
PC
PCSS
1
1
0+
0+
Paper
PCMember
1+
3
Abbildung 6-2: Schemadiagramm mit „loser“ Verbindung
,QGLHVHU6LWXDWLRQLVWEHLVSLHOVZHLVHGDV(U]HXJHQYRQ
,QVWDQ]HQGHU.ODVVHPCMemberPLWGHU0HWKRGH
AddPCMemberQLFKWPHKU]XEHZHUNVWHOOLJHQ'LH0HWKRGH
SUIWQlPOLFKDP(QGHLKUHU$XVIKUXQJGLH.RQVLVWHQ]GHV
HU]HXJWHQ2EMHNWHVGLHDXIJUXQGGHU.DUGLQDOLWlWVYHUOHW]XQJ
LQGHULQYHUVHQ%H]LHKXQJ]XPaperQLFKWJHJHEHQLVW
(VJLEW]ZHL$XVZHJHDXVGLHVHU6LWXDWLRQ
'HU(QWZLFNOHUEHVFKDIIWVLFKEHUGLH0HWKRGH
PC::CreatePCMember()GHVJHZQVFKWHQ2EMHNWHVGHU
.ODVVHPCHLQH,QVWDQ]GHU.ODVVHPCMember$QVFKOLHVVHQG
EDXWHUGXUFKGHQ$XIUXIGHU0HWKRGH
PCMember::AttachPaper()GLH%H]LHKXQJ]XHLQHP
172 • Umsetzung
Diplomarbeit
EHVWLPPWHQ3DSLHUREMHNWDXIXQGIJWGDVQXQNRQVLVWHQWH
0LWJOLHGVREMHNWGHU0LJOLHGHUVDPPOXQJPLWWHOVGHU0HWKRGH
PC::AddRefPCMember()KLQ]X
'HU(QWZLFNOHUGLVWDQ]LHUWVLFKYRQGHQYRQ26:22'
JHQHULHUWHQ0HWKRGHQXQGYHUZHQGHWGLHJlQJLJHQ
'DWHQEDQNRSHUDWLRQHQZLHnewHWF
,QEHLGHQYRUJHVFKODJHQHQ$XVZHJHQOLHJW]XHLQHPJHZLVVHQ
=HLWSXQNWHLQH,QNRQVLVWHQ]YRUZHVKDOEGHUJDQ]H
0DQLSXODWLRQVEORFNLQHLQHU7UDQVDNWLRQXQWHU]XEULQJHQLVW
DQGHUHQ(QGHGLH'DWHQLQWHJULWlWHUQHXW]XJHOWHQKDW
bKQOLFKYHUKlOWHVVLFKEHLGHU(U]HXJXQJYRQ,QVWDQ]HQGHU
.ODVVHPaper
6.4.2 Löschen von Instanzen
$QDORJH(IIHNWHVLQGEHLGHU/|VFKXQJYRQ,QVWDQ]HQIHVW]XVWHOOHQ
:LUGHUQHXWGDV6FKHPDGLDJUDPPYRQ$EELOGXQJEHWUDFKWHW
VLQGVRZRKO3DSLHUDOVDXFK0LWJOLHGVREMHNWHDXIHLQIDFKH:HLVH
GXUFKGLH9HUZHQGXQJGHULPSOL]LWHQ0HWKRGHQ
PC::RemovePaper()E]ZPC::RemovePCMember()DXVGHU
'DWHQEDVLVO|VFKEDU'LHVH0HWKRGHQVRUJHQQlPOLFKDXWRPDWLVFK
IUGHQNRQVLVWHQWHQ$EEDXGHULQYHUVHQ%H]LHKXQJHQDOVRIUGLH
(UKDOWXQJGHU.RQVLVWHQ]
$QGHUVOLHJWGLH6LWXDWLRQZLHGHUXPEHLGHU0RGHOOLHUXQJYRQ
ÅVWUHQJHQ´LQYHUVHQ%H]LHKXQJHQYJO$EELOGXQJ+LHUYHUVDJHQ
GLHRemove0HWKRGHQLP$OOJHPHLQHQGDGLHLQYHUVHQ%H]LHKXQJHQ
QLFKWXQWHU%HLEHKDOWXQJGHU'DWHQLQWHJULWlWDEJHEDXWZHUGHQ
N|QQHQ$QDORJVWHKHQDXFKKLHU]ZHL$XVZHJP|JOLFKNHLWHQ]XU
9HUIJXQJ
)UGLH/|VFKXQJHLQHU3DSLHULQVWDQ]EHLVSLHOVZHLVHPVVHQHUVW
GLH%H]LHKXQJHQ]XGHQ0LWJOLHGHUQGLH]XU3UIXQJGLHVHV3DSLHUV
YRUJHVHKHQVLQGDXIJHO|VWZHUGHQ6FKOlJWGLH$EEDXPHWKRGH
Paper::DetachPCMember()IHKOZHLOHLQ0LWJOLHGQXUGLHVHV
HLQ]LJH3DSLHUEHJXWDFKWHWPXVVGLHVHV0WLJOLHGHEHQIDOOVJHO|VFKW
ZHUGHQPC::DestroyPCMember()$QVFKOLHVVHQGOlVVWVLFKGDV
JHIUDJWH3DSLHUEHUGLH0HWKRGHPC::DestroyPaper()
HQWIHUQHQ
:LHGHUXPVWHKWHVGHP(QWZLFNOHURIIHQYRQGHQJHQHULHUWHQ
0HWKRGHQ$EVWDQG]XQHKPHQXQGDXIGLHEHZlKUWHQ
'DWHQEDQNRSHUDWLRQHQ]XUFN]XJUHLIHQ
'LH/|VFKXQJHLQHV0LWJOLHGVREMHNWHVHUZHLVWVLFKKLQJHJHQDOVQRFK
SUREOHPDWLVFKHU'DV:HJQHKPHQHLQHVHLQ]LJHQ0LWJOLHGHVNDQQ
VLFKQlPOLFKDXIJUXQGGHUVWDUNHQ.DUGLQDOLWlWVHLQVFKUlQNXQJ
EHOLHELJIRUWSIODQ]HQ(VN|QQHQQHEHQGLYHUVHQ3DSLHUHQDXFK
ZHLWHUH0LWJOLHGHUEHWURIIHQVHLQ,QGLHVHQ6LWXDWLRQHQO|VWPDQ
KlXILJGDV3UREOHPLQGHPPDQDQVWHOOHGHU/|VFKXQJYRQ
%H]LHKXQJHQQHXH%H]LHKXQJHQ]XDQGHUHQ2EMHNWHQDXIEDXW
8PODJHRGHUGLH.DUGLQDOLWlWVHLQVFKUlQNXQJHQDXIZHLFKW
6.4.3 Fazit
26:22'JHQHULHUWQW]OLFKHXQGZLFKWLJH
0HWKRGHQLPSOHPHQWLHUXQJHQGLHLQHLQHU9LHO]DKOYRQ
$QZHQGXQJHQGLUHNWYHUZHQGHWZHUGHQN|QQHQ,QVSH]LHOOHQ)lOOHQ
KLQJHJHQPXVVVLFKGHU(QWZLFNOHUJHQDXEHUOHJHQREGLH
Diplomarbeit
Umsetzung • 173
YRUJHIHUWLJWHQ0HWKRGHQGDVJHZQVFKWH9HUKDOWHQDXFKWDWVlFKOLFK
DEELOGHQ9LHOIDFKVWHKWHUGDQQYRUGHU(QWVFKHLGXQJHQWZHGHU
JHZLVVH(QWZXUIVHQWVFKHLGXQJHQDQ]XSDVVHQGDPLWGLH
6WDQGDUGPHFKDQLVPHQJUHLIHQN|QQHQRGHUHLQHQJHZLVVHQ
3URJUDPPLHUDXIZDQG]XEHWUHLEHQXPGLH(QWZXUIVDVSHNWHDEELOGHQ
]XN|QQHQ
174 • Umsetzung
Diplomarbeit
7 Implementation
7.1 Einleitung
,QGLHVHP.DSLWHOVROOGLH,PSOHPHQWDWLRQGHU8PVHW]XQJHQDXVGHP
YRULJHQ.DSLWHOHUOlXWHUWZHUGHQ'DEHLVLQGHUVWHLQLJHDOOJHPHLQH
(LJHQVFKDIWHQGHU+DUG\GDWHLHQGDUJHVWHOOWXQGGDVJHQHUHOOH9RUJHKHQEHL
GHU,QWHUSUHWDWLRQGLHVHU,QSXWGDWHLHQDXVJHIKUW'DUDXIZHUGHQGLH
,QWHUSUHWDWLRQHQGHU,QGH[GHU6FKHPDXQGGHU7UDQVDNWLRQVGLDJUDPPH
EHWUDFKWHW
'LHMHZHLOLJHQ%HVFKUHLEXQJHQVLQGIROJHQGHUPDVVHQDXIJHEDXW
%HVFKUHLEXQJGHU$XIJDEH:DVVROOJHWDQZHUGHQ":DVLVWGDV=LHO"
%HVFKUHLEXQJGHV,QSXWV:HOFKHVVLQGGLH(LQJDQJVJU|VVHQ":LHZLUG
PLWGHU8PJHEXQJ]XVDPPHQJHDUEHLWHW"
(QWZXUIGHU/|VXQJ:HOFKHVLVWGLHQRWZHQGLJH.ODVVHQVWUXNWXU":DV
VLQGGLHQRWZHQGLJHQ)lKLJNHLWHQGHU.ODVVHQ":HOFKHV9HUKDOWHQVROOHQVLH
LPSOHPHQWLHUHQ"
,PSOHPHQWDWLRQGHU/|VXQJ:LHVLQGGLHZLFKWLJHQ6FKOVVHODOJRULWKPHQ
DXIJHEDXWXQGLPSOHPHQWLHUW"
=XP6FKOXVVVROOGLH,PSOHPHQWDWLRQEHZHUWHWZHUGHQREVLFKGLH:DKOGHU
(QWZLFNOXQJVXPJHEXQJDOVJOFNOLFKHUZLHVHQKDWXQGZLHJXWGDVJHVWHFNWH
=LHOHUUHLFKWZHUGHQNRQQWH=XGHPVROOHQGLHEHNDQQWHQ3UREOHPHXQGGLH
P|JOLFKHQ]XNQIWLJHQ$XVEDXVFKULWWHGLVNXWLHUWZHUGHQ
7.1.1 Werkzeuge
)UGLH,PSOHPHQWDWLRQZXUGHQGLHIROJHQGHQ:HUN]HXJHHLQJHVHW]W
+DUGZDUH
3UR]HVVRU
,QWHO3HQWLXP
$UEHLWVVSHLFKHU
0%5$0
6RIWZDUH
%HWULHEVV\VWHP
0LFURVRIW:LQGRZV0LFURVRIW:LQGRZV17XQG0LFURVRIW
:LQGRZV17DOWHUQLHUHQG
(QWZLFNOXQJVXPJHEXQJ
0LFURVRIW'HYHORSHU6WXGLR06'(99HUVLRQ
3URJUDPPLHUVSUDFKH
0LFURVRIW9LVXDO&069&9HUVLRQ
.ODVVHQELEOLRWKHN
0LFURVRIW)RXQGDWLRQ&ODVV/LEUDU\0)&9HUVLRQ
7.2 Umsetzung einer Hardydatei
,QDOOHQ8PVHW]XQJHQPXVVGHUYRQ+DUG\JHOLHIHUWH,QSXWGLH+DUG\GDWHL
JHOHVHQXQGLQWHUSUHWLHUWZHUGHQ'D]XPXVVYRUHUVWGDV)RUPDWGHU
+DUG\GDWHLHUNDQQWXQGHLQ3DUVHUHQWZLFNHOWZHUGHQZHOFKHUGHUDUWLJH
'DWHLHQOHVHQLQWHUSUHWLHUHQXQGGLHJHOHVHQHQ,QIRUPDWLRQHQIUGLHVSlWHUH
9HUZHQGXQJVLQQYROOLQHLQH'DWHQVWUXNWXUDEOHJHQNDQQ
7.2.1 Dateiformat
(LQH+DUG\GDWHLOLHJWDOV7H[WGDWHLYRUXQGIROJWGHP
XQWHQVWHKHQGHQ6\QWD[
file
::= (item)+
Diplomarbeit
Implementation • 175
item
::= ident( property
(,property)* ).
Property
::= variable = value
Syntaxdiagramm 7-1: Dateiformat einer Hardydatei
'DEHLEHGHXWHQGLHNXUVLYGDUJHVWHOOWHQWHUPLQDOHQ6\PEROH
IROJHQGHV
ident
%HOLHELJH=HLFKHQIROJH,GHQWLIL]LHUWGHQ7\SHLQHU6HNWLRQ'LH
6HNWLRQVW\SHQZHUGHQYRQ+DUG\YHUJHEHQXQGKHLVVHQ
EHLVSLHOVZHLVHcarditemnodearcXVZ
variable
%HOLHELJH=HLFKHQIROJH%HQHQQWHLQHEHVWLPPWH(LJHQVFKDIWGHU
HQWVSUHFKHQGHQ6HNWLRQ'LH9DULDEOHQQDPHQZHUGHQ]7YRQ
+DUG\VHOEVWYHUJHEHQHWZDidcardXVZN|QQHQDEHUDXFKDXV
GHU6\PEROELEOLRWKHNVWDPPHQZLH]%classnameIUHLQHQ
.ODVVHQNQRWHQ
value
%HOLHELJH=HLFKHQIROJH,GHQWLIL]LHUWGHQ:HUWHLQHU9DULDEOHQ
1XPHULVFKH$XVGUFNHVWHKHQLQQXPHULVFKHU)RUPZlKUHQG7H[WH
LQ$QIKUXQJV]HLFKHQHLQJHIDVVWVLQG6SH]LHOOH=HLFKHQZLH]%GDV
$QIKUXQJV]HLFKHQVHOEVWVLQGHQWVSUHFKHQGGXUFKHLQHQ
Å%DFNVODVK´PDVNLHUW
7.2.2 Klassendiagramm
CDocument
CAnyDoc
CArchive
CHardyFile
CItem
CFile
ITEM
CString
CArray
CVariable
CString
CValue
Klassendiagramm 7-1: Klassen für die Umsetzung einer Hardydatei
.ODVVHQYRQ26:22'
CAnyDoc
9HUZDOWHWGLH,QIRUPDWLRQHQGHU+DUG\GDWHLLQ$EKlQJLJNHLWGHV
.RQWH[WHV]%CIndexDocIU,QGH[GDWHLHQ
CHardyFile
.DSVHOWGLH+DUG\GDWHLXQGVWHOOW)XQNWLRQHQ]XP$XVOHVHQGHU
(LQWUlJH]XU9HUIJXQJ
176 • Implementation
Diplomarbeit
CItem
5HSUlVHQWLHUWHLQH6HNWLRQLQHLQHU+DUG\GDWHL
CVariable
6WULQJ$UUD\]XU6SHLFKHUXQJGHU9DULDEOHQQDPHQ
CValue
6WULQJ$UUD\]XU6SHLFKHUXQJGHU9DULDEOHQZHUWH
.ODVVHQGHU0)&
CDocument
0)&.ODVVH]XU9HUZDOWXQJYRQ'RNXPHQWHQ
CArchive
0)&.ODVVH]XU9HUZDOWXQJYRQ$UFKLYHQ
CFile
0)&.ODVVH]XU9HUZDOWXQJYRQ'DWHLHQ
CArray
0)&.ODVVHQYRUODJH]XU9HUZDOWXQJYRQ$UUD\EHOLHELJHU
KRPRJHQHU7\SHQRGHU.ODVVHQ
CString
0)&.ODVVH]XU9HUZDOWXQJYRQ7H[WHQ
7.2.2.1 CHardyFile
&+DUG\)LOH
CHardyFile(Carchive* parDiagram)
(U]HXJWHLQH,QVWDQ]XQGYHUELQGHWGLHVHPLWGHP$UFKLY
int GetToken(const CString &strDelimiter,
CString &strToken) const
/LHVW=HLFKHQIU=HLFKHQDXVGHP$UFKLYELVHQWZHGHUGDVJHOHVHQH
=HLFKHQPLWHLQHPLQstrDelimiterEHUJHEHQHQ=HLFKHQ
EHUHLQVWLPPWRGHUGDV(QGHGHU'DWHLHUUHLFKWZRUGHQLVW
'DPLWDXFK(LQWUlJHEHUPHKUHUH=HLOHQJHOHVHQZHUGHQN|QQHQ
ZHUGHQÅ&DUULDJH5HWXUQÅXQGÅ/LQH)HHGÅ=HLFKHQEHUOHVHQ
'LHELV]XU$EEUXFKEHGLQJXQJJHOHVHQHQ=HLFKHQZHUGHQLQGHQ
3DUDPHWHUstrTokenJHVFKULHEHQ
int GetString(const CString &strDelimiter,
CString &strToken) const
$UEHLWHWDQDORJ]XGetTokenNDQQDEHUDXFK(LQWUlJHEHUPHKUHUH
=HLOHQOHVHQLQGHPGLHÅ&DUULDJH5HWXUQÅXQGÅ/LQH)HHGÅ=HLFKHQ
EHUOHVHQZHUGHQXQGRGHU(LQWUlJHGLHVSH]LHOOH=HLFKHQ
LQVEHVRQGHUH=HLFKHQGLHLQstrDelimiterYRUNRPPHQHQWKDOWHQ
CArchive* m_parHardyFile
=HLJWDXIGDVDNWXHOOJH|IIQHWH$UFKLY
Klassenbeschreibung 7-1: CHardyFile
class CHardyFile {
// construction / destruction
public:
CHardyFile(CArchive* parDiagram);
// methods
public:
int GetToken(const CString
&strDelimiter,CString &strToken) const;
void GetString(const char
&chDelimiter,CString &strToken) const;
void Move(int nBytes=1);
// members
public:
CArchive* m_parHardyFile;
};
Diplomarbeit
Implementation • 177
Listing 7-1: Definition der Klasse CHardyFile
7.2.3 Lesen einer Hardydatei
try {
while (TRUE) {
(1)
nDelIndex=DiagramFile.GetToken("(",strToke
n);
(2)
(3)
Item.ReadEntry(DiagramFile);
AddItem(Item);
DiagramFile.Move(1);
//overread point
}//endwhile
}//endtry
(4)
catch(CArchiveException* e) {
(5)
if (e>m_cause!=CArchiveException::endOfFile) {
(6)
throw CFatalError("A fatal
error occured ...“);
}//endif
e->Delete();
}//endcatch
Listing 7-2: Lesen einer Hardydatei
/HVHQELV]XP=HLFKHQÅ´XQG%H]HLFKQHUGHU6HNWLRQ
VSHLFKHUQ
(2) 'LH9DULDEHOQXQGGHUHQ:HUWHDXVOHVHQXQGHLQHU,QVWDQ]YRQ
CItem]XZHLVHQ
(3) 'DV(OHPHQWGHU6DPPOXQJYRQ(OHPHQWHQKLQ]XIJHQ
(4) :LUGEHLP/HVHQDXVGHU+DUG\GDWHLHLQH$XVQDKPHDXVJHO|VW
ZLUGGLHVHJOHLFKDQVFKOLHVVHQGLPcatch%ORFNEHKDQGHOW
(5) +DQGHOWHVVLFKEHLGHUDXIJHIDQJHQHQ$XVQDKPHXPGLH
$QJDEHGDVVGLH'DWHL]X(QGHJHOHVHQZRUGHQLVWZLUGGLH
9HUDUEHLWXQJEHHQGHW
(6) ,QDOOHQDQGHUHQ)lOOHQDEHUGHXWHWGLH$XVQDKPHDXIHLQHQ
IDWDOHQ)HKOHUKLQXQGPXVVGHPHQWVSUHFKHQGZHLWHUJHOHLWHWZHUGHQ
7.2.3.1 Lesen der Variablen und deren Werte
(1)
void CItem::ReadEntry(CHardyFile& DiagramFile) {
...
while (TRUE) {
// read variable name
(1)
nDelPos=DiagramFile.GetToken("=",strVariab
le);
(2)
m_astrVariable.Add(strVariable);
// read variable's value
(3)
nDelPos=DiagramFile.GetToken(",)",strValue
);
(4)
m_astrValue.Add(strValue);
// check for special handling
(5)
if
(strVariable==VARIABLE_TYPE_IDENTIFIER_TYPE) {
m_strType=strValue.Mid(1,strValue.GetLengt
h()-2);
SetItemType();
SetImageId();
}//endif
// if parenthesis has been found
sction is read completely
(6)
if (nDelPos==1) return;
}//endwhile
...
}//end ReadEntry
Listing 7-3: Lesen einer Sektion
(1) /HVHQELV]XP=HLFKHQÅ ´XQG9DULDEOHQQDPH
VSHLFKHUQ
(2) 9DULDEOHQQDPHVSHLFKHUQ
178 • Implementation
Diplomarbeit
(3) /HVHQELV]XP=HLFKHQÅ´RGHUÅ´XQG9DULDEOHQZHUW
VSHLFKHUQ
(4) 9DULDEOHQZHUWVSHLFKHUQ
(5) :XUGHGHU7\SHQHLQWUDJJHOHVHQVRNDQQGHPQLFKW
W\SLVLHUWHQ(OHPHQWHLQ7\SDXVGHU/LVWHGHUP|JOLFKHQ
7\SHQ]XJHRUGQHWZHUGHQ
(6) :XUGHGDV=HLFKHQÅ´JHOHVHQVRLVWGLH6HNWLRQ
YROOVWlQGLJJHOHVHQZRUGHQXQGGLH.RQWUROOHNDQQDQGHQ
EHUJHRUGQHWHQ3UR]HVV]XUFNJHJHEHQZHUGHQ
7.2.3.2 Element hinzufügen
'LHVH)XQNWLRQLVWHLQ%HVWDQGWHLOGHV%HVLW]HUVGHU
(OHPHQWVDPPOXQJHQGDQXUGLHVHUHQWVFKHLGHQNDQQZHOFKH
GHUJHOHVHQHQXQGHUNDQQWHQ(OHPHQWW\SHQHULQVHLQH
6DPPOXQJDXIQHKPHQZLOO
=XGHPPVVHQLQ$EKlQJLJNHLWGHUZHLWHUHQ9HUZHQGXQJ
GHU(OHPHQWHJHZLVVH9DOLGLHUXQJHQYRUJHQRPPHQXQG
ZHLWHUH9DULDEOHQLQWHUSUHWLHUWXQGDXIEHUHLWHWZHUGHQYJO
ZHLWHUH$EVFKQLWWH
7.3 Umsetzung der Indexdatei
,QGHU,QGH[GDWHLVLQGGLH,QIRUPDWLRQHQEHUGLH'LDJUDPPHHQWKDOWHQHQ
26:22'VROOGLHVH'DWHLLQWHUSUHWLHUHQXPGHP%HQXW]HUHLQ
1DYLJDWLRQVIHQVWHU]XU9HUIJXQJVWHOOHQ]XN|QQHQLQGHPHUGLHHLQ]HOQHQ
HUNDQQWHQ'LDJUDPPHEHWUDFKWHQNDQQ
7.3.1 Die Indexdatei als Input
(LQH,QGH[GDWHLOLHJWDOV7H[WGDWHLYRUXQGIROJWGHPXQWHQVWHKHQGHQ
6\QWD[
index
::= (item)+
item
::= ident( property
(,property)* ).
property
::= variable = value
ident
::= header | card | item |
link
variable
::= type | id | card |
filename |
diagram_type | variable
Syntaxdiagramm 7-2: Format einer Schemadiagrammdatei
7.3.1.1 Elemente einer Indexdatei
header
HQWKlOW,QIRUPDWLRQHQEHUGLH,QGH[GDWHLLP$OOJHPHLQHQ
ZLUGYRQ26:22'QLFKWYHUZHQGHW
card
EHVFKUHLEWHLQHLQGHU,QGH[GDWHLUHIHUHQ]LHUWH
'LDJUDPPNDUWH,QVEHVRQGHUHHQWKlOWGLHVH6HNWLRQGHQ7\S
XQGGHQ1DPHQGHU'LDJUDPPGDWHL
item
GLHQW]XU9HUZDOWXQJGHU,GHQWLILNDWRUHQZLUGYRQ
26:22'QLFKWYHUZHQGHW
link
EHVFKUHLEWGLHYRP%HQXW]HUGHILQLHUWHQ9HUNQSIXQJHQ]X
GHQ'LDJUDPPHQ
7.3.2 Klassendiagramm
Diplomarbeit
Implementation • 179
CDocument
CAnyDoc
1+
CDiagramCard
CItem
Klassendiagramm 7-2: Klassen für die Umsetzung einer Indexdatei
.ODVVHQYRQ26:22'
CIndexDoc
YHUZDOWHWGLH,QIRUPDWLRQHQGHU,QGH[GDWHL
CDiagramCard
NDSVHOWHLQH'LDJUDPPNDUWH
CItem
VSHLFKHUWGLHDXVGHU,QGH[GDWHLJHOHVHQHQ(LQWUlJHGLHQLFKWZHLWHU
W\SLVLHUWXQGYHUZHQGHWZHUGHQ
.ODVVHQGHU0)&
CDocument
YHUZDOWHWGLH,QIRUPDWLRQHQHLQHV'RNXPHQWHV
7.3.2.1 CDiagramCard
&GLDJUDP&DUG
CdiagramCard(const Citem& Item)
(U]HXJWHLQH,QVWDQ]XQGEHUQLPPWGLH$WWULEXWHGHU9DWHUNODVVH
void Validate(void)
/LHVWGHQ9DULDEOHQZHUWfilenameXQGZHLVWLKQGHP$WWULEXW
m_strFileName]X
%HVWLPPWDXIJUXQGGHV9DULEDOHQZHUWHVdiagram_typeGHQ
'LDJUDPPW\SXQGVSHLFKHUWGLHVHQLP$WWULEXWm_Type$OV
'LDJUDPPW\SHQVWHKHQ.RQWH[W7UDQVDNWLRQVRGHU6FKHPDGLDJUDPP
]XU$XVZDKO.DQQNHLQHUGLHVHU7\SHQHUNDQQWZHUGHQZLUGGHU7\S
DXIÅXQEHNDQQW´JHVHW]W
m_strFileName
6SHLFKHUWGHQ'DWHLQDPHQXQGGHQ3IDGGHU]XP'LDJUDPPJHK|ULJHQ
'LDJUDPPGDWHL',$
m_Type
SSHLFKHUWGHQ7\SHLQHV'LDJUDPPV
Klassenbeschreibung 7-2: CDiagramCard
class CDiagramCard : public CItem {
// type defs
public:
typedef enum {
typeContext=0,
typeSchema=1,
typeTransaction=2,
typeUnknown=0
} Type;
// construction / destruction
public:
CDiagramCard() {};
180 • Implementation
Diplomarbeit
CDiagramCard(const CItem& Item) :
CItem(Item) {};
// operations
public:
CDiagramCard& operator=(CDiagramCard&
DiagramCard);
// methods
public:
virtual void Validate(void);
CString GetLabel(void);
// members
public:
CString m_strFileName;
Type m_Type;
};
Listing 7-4: Definition der Klasse CDiagramCard
7.3.3 Lesen der Indexdatei
'LH,QGH[GDWHLZLUGJHPlVVRELJHU%HVFKUHLEXQJXQWHU
JOHLFK]HLWLJHPNRQWH[WVSH]LILVFKHQ(LQIJHQXQG9DOLGLHUHQGHU
(OHPHQWHLQGLHHQWVSUHFKHQGHQ(OHPHQWVDPPOXQJHQJHOHVHQ
$QVFKOLHVVHQGZHUGHQJHZLVVHLQYDULDQWHQ%HGLQJXQJHQJHSUIW
7.3.3.1 Element hinzufügen
)UMHGHQ(LQWUDJGHV7\SVcardZLUGHLQ2EMHNWGHU.ODVVH
CDiagramCardLQVWDQ]LHUW$OOHDQGHUHQ7\SHQZHUGHQDOV
,QVWDQ]HQGHU.ODVVHCItemJHVSHLFKHUW
void CIndexDoc::AddItem(const CItem& Item) {
(1)
switch (Item.GetItemType()) {
(2)
case CItem::typeDiagramCard: {
(3)
CDiagramCard
DiagramCard(Item);
(4)
DiagramCard.Validate();
(5)
m_aDiagramCard.Add(DiagramCard);
break;
}//endcase
(6)
default: {
CItem anItem(Item);
m_aItem.Add(anItem);
break;
}
}//endswitch
}//end AddItem
Listing 7-5: Einfügen eines Elementes in das Indexdokument
(1) :HLOGDV(OHPHQWEHUHLWVEHLP/HVHQGHU'DWHLW\SLVLHUW
ZRUGHQLVWNDQQDQGLHVHU6WHOOHGLH,QIRUPDWLRQEHUHLWV
DXVJHQXW]WZHUGHQ
(2) +DQGHOWHVVLFKEHLGHP(OHPHQWXPHLQH
'LDJUDPPEHVFKUHLEXQJ
(3) VRZLUGHLQH,QVWDQ]GHU.ODVVHCDiagramCardHU]HXJW
GLHEHUHLWVJHOHVHQHQ'DWHQZHUGHQYRQGHU9DWHUNODVVHLQ
GLH.LQGNODVVHEHUWUDJHQ
(4) GLH,QVWDQ]YDOLGLHUWXQG
(5) LQGLH6DPPOXQJGHUHUNDQQWHQ'LDJUDPPH
DXIJHQRPPHQ
(6) $OOHDQGHUHQ(LQWUlJHZHUGHQOHGLJOLFKDOVXQW\SLVLHUWH
(OHPHQWHGHU6DPPOXQJIUGLHVSlWHUH5HSURGXNWLRQ
KLQ]XJHIJW
7.3.3.2 Validierung
1DFKGHUYROOVWlQGLJHQ,QWHUSUHWDWLRQGHU,QGH[GDWHLOLHJHQ
GLHHQWKDOWHQHQ'LDJUDPPHDOV,QVWDQ]HQYRU6LQGNHLQH
Diplomarbeit
Implementation • 181
GHUDUWLJHQ2EMHNWHHUNDQQWZRUGHQKDQGHOWHVVLFKEHLGHU
JHOHVHQHQ'DWHLQLFKWXPHLQHJOWLJH,QGH[GDWHLLP6LQQH
YRQ+DUG\'DPLWODVVHQVLFKIROJHQGH)HKOHUEHGLQJXQJHQ
HUNHQQHQ
'LHJHOHVHQH'DWHL
• LVWNHLQH+DUG\GDWHL
• LVWOHHU
• LVWNHLQH,QGH[GDWHLRGHU
• HQWKlOWNHLQ'LDJUDPP
,VWGLHJHOHVHQH'DWHLLP6LQQHGHURELJHQ.ULWHULHQNRUUHNW
NDQQVLHGHQQRFKIU26:22'XQEUDXFKEDUVHLQGDVLH
NHLQH'LDJUDPPW\SHQHQWKlOWGLHZHLWHUYHUZHQGHWZHUGHQ
N|QQWHQ9HUKDOWHQVLHKH´%HQXW]HUDNWLRQHQµ6HLWH
7.4 Umsetzung der Schemadiagrammdatei
,QGHU6FKHPDGLDJUDPPGDWHLLVWGHUNRQ]HSWXHOOH(QWZXUIGHU
'DWHQEDQNNODVVHQXQGGLH%H]LHKXQJHQXQWHUHLQDQGHUHQWKDOWHQ26:22'
VROOGLHVH'DWHLLQWHUSUHWLHUHQXPGHP%HQXW]HUVRZRKOGHQ
.RPSRQHQWHQEDXPGLH9HUHUEXQJVKLHUDUFKLHDOVDXFKGHQ$XIEDXGHU
HLQ]HOQHQ.ODVVHQXQGGHUHQ8PVHW]XQJLQGHU6FKHPDGHILQLWLRQVVSUDFKH
2&DQ]HLJHQ]XN|QQHQ
7.4.1 Die Schemadiagrammdatei als Input
7.4.1.1 Dateiformat
(LQH6FKHPDGLDJUDPPGDWHLOLHJWDOV7H[WGDWHLYRUXQGIROJW
GHPXQWHQVWHKHQGHQ6\QWD[
index
::= (item)+
item
::= ident( property
(,property)* ).
property
::= variable = value
ident
::= diagram | card | node |
arc |
node_image | arc_image
variable
::= type | id | card | 'class
name' |
properties | 'persistant name' |
connections | cardinality |
inverse |'cardinality begin' |
'cardinality end' | variable
Syntaxdiagramm 7-3: Syntax einer Schemadiagrammdatei
7.4.1.2 Elemente einer Schemadiagrammdatei
diagram
HQWKlOW,QIRUPDWLRQHQEHUGLH'LDJUDPPGDWHLLP
$OOJHPHLQHQZLUGYRQ26:22'QLFKWYHUZHQGHW
card
HQWKlOWGLH,QIRUPDWLRQEHUGLH'LDJUDPPNDUWHXQGELOGHW
VRGLH9HUELQGXQJ]XGHU,QGH[GDWHL,QVEHVRQGHUHHQWKlOW
GLHVH6HNWLRQGHQ7\S'LDJUDPPGDWHL
node
HQWKlOWGLH,QIRUPDWLRQHQEHUHLQHQ.QRWHQLP'LDJUDPP
1HEHQVHLQHP7\SXQGGHQYRP%HQXW]HU]XJHZLHVHQHQ
$WWULEXWHQZHUGHQDXFKGHVVHQ9HUELQGXQJHQ]XDQGHUHQ
182 • Implementation
Diplomarbeit
.QRWHQGHILQLHUW(LQH5HIHUHQ]DXIGDV(OHPHQW
node_imageOHJWVHLQH(UVFKHLQXQJVIRUPXQGVHLQHQRUW
IHVW
arc
EHVFKUHLEWHLQHQ9HUELQGHU]ZLVFKHQ]ZHL.QRWHQ'LHVHULVW
JOHLFKVDPW\SLVLHUWXQGHQWKlOW9HUZHLVHDXIGLH.QRWHQGLH
GXUFKLKQYHUEXQGHQZHUGHQ
node_image
GHILQLHUWGDV$XVVHKHQHLQHV.QRWHQV
arc_image
GHILQLHUWGDV$XVVHKHQHLQHV9HUELQGHUV
7.4.2 Ablaufbeschreibung
'HU$QDO\VHSUR]HVVOlXIWLQPHKUHUHQ6WXIHQDE
/HVHQGHU6FKHPDGLDJUDPPGDWHL8PVHW]XQJGHU(OHPHQWHLQ
.QRWHQXQG.DQWHQ
9DOLGLHUXQJHQ
$XIEDXGHV9HUHUEXQJVJUDSKHQ
$XIEDXGHU.RPSRQHQWHQEDXPHV
8PVHW]HQGHU.DQWHQLQ%H]LHKXQJHQ.RPSRQHQWHQLQYHUVH
%EHREDFKWXQJ(YROXWLRQ
(U]HXJXQJGHU.ODVVHQGHILQLWLRQHQXQG
0HWKRGHQLPSOHPHQWLHUXQJHQ
(UJlQ]HQGHU.ODVVHQPLWYRUGHILQLHUWHQ0HWKRGHQXQG
6FKUHLEHQGHU2'/'DWHL
7.4.3 Einbettung
CView
1 +C C o m p o n e n t
View
COSWOOD
App
CWinApp
CMultiDoc
Template
CInheritance
View
CSchemaDoc
CSchema
Frame
CDocument
CMDIChild
Wnd
CClass
View
CODL
View
Klassendiagramm 7-3: Einbettung der Schemadiagrammklassen
.ODVVHQYRQ26:22'
COSWOODApp
$SSOLNDWLRQVNODVVHYRQ26:22'9HUZDOWHWGDV+DXSWIHQVWHUXQG
GLH'RNXPHQWHQW\SHQ(LQ]LJH.ODVVHZHOFKHHLQHJOREDOH,QVWDQ]
EHVLW]W
Diplomarbeit
Implementation • 183
CSchemaDoc
YHUZDOWHWGLH,QIRUPDWLRQHQHLQHV6FKHPDGLDJUDPPV
CSchemaFrame
YHUZDOWHWGDV'RNXPHQWHQIHQVWHU
CComponentView
YHUZDOWHWGLH.RPSRQHQWHQDQVLFKW
CInheritanceView
YHUZDOWHWGLH9HUHUEXQJVDQVLFKW
CClassView
YHUZDOWHWGLH.ODVVHQDQVLFKW
CODLView
YHUZDOWHWGLH2'/$QVLFKW
.ODVVHQGHU0)&
CWinApp
$SSOLNDWLRQVNODVVH
CMultiDocTemplate
NDSVHOWHLQHQEHVWLPPWHQ'RNXPHQWHQW\SGHUGXUFKVHLQH
'RNXPHQWHQ5DKPHQXQG$QVLFKWVNODVVHLGHQWLIL]LHUWZLUG
CMDIChildWnd
YHUZDOWHWGDV.LQGIHQVWHULQHLQHU0',$SSOLNDWLRQ
CView
ELOGHWGLH%DVLVNODVVHGHU$QVLFKWVNODVVHQ
CDomument
YHUZDOWHWGLH,QIRUPDWLRQHQHLQHV'RNXPHQWHV
7.4.3.1 CSchemaDoc
'LH.ODVVHVSHLFKHUWVlPWOLFKH,QIRUPDWLRQHQGLHLQHLQHP
6FKHPDGLDJUDPPHQWKDOWHQVLQGXQGVlPWOLFKH5HVXOWDWHGHU
,QWHUSUHWDWLRQ6LHVWHXHUWGHQ$EODXIXQGUHDJLHUWDXI
%HQXW]HUDNWLRQHQ
&6FKHPD'RFSXEOLF&'RFXPHQW
void ReadDiagram(CHardyFile& HardyFile)
/LHVWHLQH+DUG\GDWHLYJO´/HVHQHLQHU+DUG\GDWHLµ6HLWH
void CreateItemList(CHardyFile& HardyFile)
(UVWHOOWGLH/LVWHGHU(OHPHQWH
void AddItem(const CItem& Item)
)JWHLQEHVWLPPWHV(OHPHQWGHUHQWVSUHFKHQGHQ6DPPOXQJKLQ]X
5XIWIUGDV(OHPHQWLQVEHVRQGHUHGLHValidate0HWKRGHDXI
void ValidatePrimitives(void) const
)KUWJHZLVVH9DOLGLHUXQJHQGXUFKYJO´9DOLGLHUXQJHQµ6HLWH
void CreateInheritanceHierarchy(void)
(U]HXJWGHQ9HUHUEXQJVJUDSKHQYJO´$XIEDXGHV
9HUHUEXQJVJUDSKHQµ6HLWH
void CreateComponentTree(void)
(U]HXJGLH.RPSRQHQWHQElXPHYJO´$XIEDXGHV
.RPSRQHQWHQEDXPHVµ6HLWHXQGHUVWHOOWLPSOL]LWGLH
.RPSRQHQWHQEH]LHKXQJHQ
void CreateInverseRelations(void)
(U]HXJWGLHLQYHUVHQ%H]LHKXQJHQ
void CreateObserverRelations(void)
184 • Implementation
Diplomarbeit
(U]HXJWGLH%HREDFKWXQJVEH]LHKXQJHQ
void CreateEvolutions(void)
(U]HXJWGLH(YROXWLRQVEH]LHKXQJHQ
void CreateDefinition(void)
(U]HXJWGLH'HILQLWLRQHQXQG,PSOHPHQWDWLRQHQGHUYHUVFKLHGHQHQ
(OHPHQWHIUGLH2'/$QVLFKW
void WriteO2CFile(CArchive& arFile)
6FKUHLEWGLHYHUVFKLHGHQHQ&RGHIUDJPHQWHJHVDPPHOWLQHLQHYRP
%HQX]WHUDQJHJHEHQH'DWHL
CArray<CItem,CItem&> m_aItem
6DPPOXQJGHUQLFKWQlKHUW\SLVLHUWHQ(LQWUlJHLQGHU+DUG\GDWHL
5HSURGXNWLRQ
CArray<CdatabaseClass,CDatabaseClass&>
m_aDatabaseClass
6DPPOXQJGHU'DWHQEDQNNODVVHQ
CArray<CEntryPoint,CEntryPoint&> m_aEntryPoint
6DPPOXQJGHU(LQVWLHJVSXQNWH
CArray<CabstractClass,CAbstractClass&>
m_aAbstractClass
6DPPOXQJGHUDEVWUDNWHQ.ODVVHQ
CArray<CClassUtility,CClassUtility&> m_aClassUtility
6DPPOXQJGHU+LOIVNODVVHQ
CArray<CNote,CNote&> m_aNote
6DPPOXQJGHU1RWL]HQ
CArray<CinheritanceArc,CInheritanceArc&>
m_aInheritanceArc
6DPPOXQJGHU9HUHUEXQJVEH]LHKXQJHQ
CArray<CcomponentArc,CComponentArc&> m_aComponentArc
6DPPOXQJGHU.RPSRQHQWHQEH]LHKXQJHQ
CArray<CinstantiationArc,CInstantiationArc&>
m_aInstantiationArc
6DPPOXQJGHU,QVWDQWLLHUXQJVEH]LHKXQJHQ
CArray<CobserverArc,CObserverArc&> m_aObserverArc
6DPPOXQJGHU%HREDFKWXQJVEH]LHKXQJHQ
CArray<CinverseRelationArc,CInverseRelationArc&>
m_aInverseRelationArc
6DPPOXQJGHULQYHUVHQ%H]LHKXQJHQ
CArray<CevolutionArc,CEvolutionArc&> m_aEvolutionArc
6DPPOXQJGHU(YROXWLRQVEH]LHKXQJHQ
CArray<CNoteConnectorArc,CNoteConnectorArc&>
m_aNoteConnectorArc
6DPPOXQJGHU1RWL]HQYHUELQGHU
CInheritanceGraph m_InheritanceGraph
9HUHUEXQJVJUDSKDOV,QVWDQWLLHUXQJHLQHUCGraph.ODVVHQYRUODJHYJO
´'LH*UDSKNODVVHQµ6HLWH
CComponentTree m_ComponentTree
Diplomarbeit
Implementation • 185
.RPSRQHQWHQEDXPDOV,QVWDQWLLHUXQJHLQHUCGraph.ODVVHQYRUODJH
YJO´'LH*UDSKNODVVHQµ6HLWH
Klassenbeschreibung 7-3: CSchemaDoc
class CSchemaDoc : public CDocument {
// Methods
private:
// reading methods
void ReadDiagram(CHardyFile& HardyFile);
void CreateItemList(CHardyFile&
HardyFile);
void AddItem(const CItem& Item);
void ValidatePrimitives(void) const;
void CreateInheritanceHierarchy(void);
void AddDerivedClasses(int
nCurrentParent,HITEM hParent,CArray<int,int&>&
anAddedClassId);
void CreateComponentTree(void);
void AddComponents(CClass*
pParentClass,CArray<int,int&>& anVisitedClass,int
nParentId,HITEM hParent);
void CreateInverseRelations(void);
void CreateObserverRelations(void);
void CreateEvolutions(void);
void CreateDefinition(void);
CString GetClassParentString(CClass*
pClass);
// writing methods
void WriteO2CFile(CArchive& arFile);
void WriteClass(CClass* pClass,CArchive&
arFile,CString strTypeName);
//utilities
CClass* GetClass(int nId);
BOOL IsElementOf(CArray<int,int&>&
anArray,int& nElement);
CGraphNode<CClass>*
IsParentElementOf(CGraphNode<CClass>*
pItem,CArray<int,int&>& anArray);
BOOL IsChildElementOf(CGraphNode<CClass>*
pItem,CArray<int,int&>& anArray);
// Attributes
public:
// item list
CArray<CItem,CItem&> m_aItem;
// node lists
CArray<CDatabaseClass,CDatabaseClass&>
m_aDatabaseClass;
CArray<CEntryPoint,CEntryPoint&>
m_aEntryPoint;
CArray<CAbstractClass,CAbstractClass&>
m_aAbstractClass;
CArray<CClassUtility,CClassUtility&>
m_aClassUtility;
CArray<CNote,CNote&> m_aNote;
// arc lists
CArray<CInheritanceArc,CInheritanceArc&>
m_aInheritanceArc;
CArray<CComponentArc,CComponentArc&>
m_aComponentArc;
CArray<CInstantiationArc,CInstantiationArc
&> m_aInstantiationArc;
CArray<CObserverArc,CObserverArc&>
m_aObserverArc;
CArray<CInverseRelationArc,CInverseRelatio
nArc&> m_aInverseRelationArc;
CArray<CEvolutionArc,CEvolutionArc&>
m_aEvolutionArc;
CArray<CNoteConnectorArc,CNoteConnectorArc
&> m_aNoteConnectorArc;
// inheritance graph
186 • Implementation
Diplomarbeit
CInheritanceGraph m_InheritanceGraph;
CComponentTree m_ComponentTree;
Listing 7-6: Klassendefinition von CSchemaDoc
7.4.4 Lesen der Schemadiagrammdatei
'DV/HVHQGHU6FKHPDGLDJUDPPGDWHLOlXIWLQGHQIROJHQGHQ
6FKULWWHQDE
• $QDO\VHGHU+DUG\GDWHL3DUVLQJ
• (U]HXJHQGHU(OHPHQWH
• $QDO\VHGHU(LJHQVFKDIWHQGHU.ODVVHQ$WWULEXWHXQG0HWKRGHQ
• (U]HXJXQJGHU,PSOHPHQWDWLRQGHUH[SOL]LWHQ0HWKRGHQ
• 8PVHW]XQJGHU&RQWUDLQWV
• 8PVHW]XQJGHU$WWULEXWHXQGGHU6FKOVVHO
• $QDO\VHXQG8PVHW]XQJGHU.DUGLQDOLWlWVDQJDEHQDQ.DQWHQ
.ODVVHQGLDJUDPP
CClassUtility
CInstantiationArc
CAbstractClass
CEvolutionArc
CObserverArc
CDatabaseClass
CSchemaDoc
CComponentArc
CParser
CInheritanceArc
A CClass
A CNode
CEntryPoint
CInverseArc
CItem
A CArc
Klassendiagramm 7-4: Klassen für die Abbildung eines Schemadiagramms
%HPHUNXQJJHKWHLQ3IHLOYRQHLQHU*UXSSHDXVRGHUIKUWHLQ3IHLO
]XHLQHU*UXSSHVREHGHXWHGLHVGDVVMHGHV*UXSSHQHOHPHQWHLQH
GHUDUWLJH%H]LHKXQJHLQJHKW
.ODVVHQYRQ26:22'
CItem
VSHLFKHUWGLHIUDOOH(OHPHQWHJHPHLQVDPHQ,QIRUPDWLRQHQZLH7\S
1DPHHWF9HUZDOWHWGLHQLFKWHLQHUGHUQDFKIROJHQGHQ.ODVVHQ
]XRUGEDUHQ(OHPHQWHIU5HSURGXNWLRQV]ZHFNH
CNode
$EVWUDNWH.ODVVHIUGLH$EELOGXQJHLQHV'LDJUDPPNQRWHQV
CEntryPoint
ZLGHUVSLHJHOWHLQHQSHUVLVWHQWHQ(LQVWLHJVSXQNW
CClass
$EVWUDNWH.ODVVHIUGLH=XVDPPHQIDVVXQJDOOHUNODVVHQVSH]LILVFKHQ
(LJHQVFKDIWHQXQG)lKLJNHLWHQ
CParser
LVWHLQH+LOIVNODVVHXQGVWHOOW0HWKRGHQIUGDVV\QWDNWLVFKH
Diplomarbeit
Implementation • 187
$QDO\VLHUHQYRQ.ODVVHQHLQJHVFKDIWHQ]X9HUIJXQJ:LUGDXV
GLHVHP*UXQGQXUYRQCClassYHUZHQGHW
CDatabaseClass
'DUVWHOOXQJHLQHU'DWHQEDQNNODVVH
CAbstractClass
'DUVWHOOXQJHLQHUDEVWUDNWHQ.ODVVH
CClassUtility
'DUVWHOOXQJHLQHU+LOIVNODVVH
CArc
$EVWUDNWH.ODVVHIUGLH=XVDPPHQIDVVXQJDOOHUNDQWHQVSH]LILVFKHQ
(LJHQVFKDIWHQ
CComponentArc
'DUVWHOOXQJHLQHU.DQWHGHV7\SVÅ.RPSRQHQWH´
CInheritanceArc
'DUVWHOOXQJHLQHU.DQWHGHV7\SVÅ9HUHUEXQJ´
CInverseRelationArc
'DUVWHOOXQJHLQHU.DQWHGHV7\SVÅLQYHUVH%H]LHKXQJ´
CInstantiationArc
'DUVWHOOXQJHLQHU.DQWHGHV7\SVÅ,QVWDQWLLHUXQJ´
CObserverArc
'DUVWHOOXQJHLQHU.DQWHGHV7\SVÅ%HREDFKWXQJ´
CEvolutionArc
'DUVWHOOXQJHLQHU.DQWHGHV7\SVÅ(YROXWLRQ´
1DFKIROJHQGVHLHQHLQLJHGLHVHU.ODVVHQ%DVLVNODVVHQQlKHU
EHWUDFKWHW
7.4.4.1 CItem
&,WHP
CItem(const CItem& Item)
(U]HXJWHLQH,QVWDQ]XQGEHUQLPPWGLH$WWULEXWHDXVGHULP
3DUDPHWHUUHIHUHQ]LHUWHQ.ODVVH'LHVHU.RQVWUXNWRUZLUGYHUZHQGHW
XPGLH6SH]LDOLVLHUXQJHQYRUQHKPHQ]XN|QQHQ
Void ReadEntry(CHardyFile& DiagramFile)
/LHVWGLH(LQWUlJHDXVHLQHU6HNWLRQLQGHU+DUG\GDWHLYJO´/HVHQGHU
9DULDEOHQXQGGHUHQ:HUWHµ6HLWHXQGVSHLFKHUWGLHVHLQGHQ
$WWULEXWHQm_astrVariableXQGm_astrValue
void SetItemClass(const CString& strId)
.ODVVLIL]LHUWGDV(OHPHQWDXI*UXQGVHLQHV6HNWLRQVW\SVXQGVSHLFKHUW
GLHVHQLP$WWULEXWm_Class
void GetItemClass(void)
/LHIHUWGHQ6HNWLRQVW\S
void SetItemType(void)
7\SLVLHUWGDV(OHPHQWDXI*UXQGGHVJHOHVHQHQ1DPHQVHLQWUDJHV
ZHOFKHULP$WWULEXWm_strTypeJHVSHLFKHUWLVWYJOReadEntry
XQGVHW]WGDV$WWULEXWm_nType
void GetItemType(void)
/LHIHUWGHQ7\SGHV(OHPHQWHV
void SetImageId(void)
6HW]WGLH,NRQHIUGLH9LVXDOLVLHUXQJGHV(OHPHQWHVLQGHU%DXPDQVLFKW
m_nImageId
188 • Implementation
Diplomarbeit
void GetVariableValue(const CString& strIdentifier,
CString& strValue)
6XFKWDXVGHQ9DULDEOHQVDPPOXQJHQGHQMHQLJHQ(LQWUDJZHOFKHUPLW
GHP3DUDPHWHUstrIdentifierEHUHLQVWLPPWXQGOLHIHUWGHQ
HQWVSUHFKHQGHQ:HUW]XUFN'LHVH0HWKRGHZLUGYRQGHQ'HULYDWHQ
YRQCItemLQQHUKDOEGHU0HWKRGHValidate()YHUZHQGHWXP
ZHLWHUHHOHPHQWVSH]LILVFKH,QIRUPDWLRQHQDXV]XZHUWHQ
Void GetVariableValue(const CString& strIdentifier,
int& nValue)
(QWVSULFKWGHURELJHQ0HWKRGHIUQXPHULVFKH(LJHQVFKDIWHQ
virtual void Validate(void)
9DOLGLHUXQJVPHWKRGHIUGDV$XVOHVHQGHUUHOHYDQWHQ,QIRUPDWLRQXQG
GHU,QWHUSUHWDWLRQ/LHVWLQVEHVRQGHUHGHQ,QGHQWLILNDWLRQVXQGGHQ
.DUWHQHLQWUDJXQGVSHLFKHUWGLHVH:HUWHLQGHQ$WWULEXWHQm_nIdXQG
m_nCard
'LHVH0HWKRGHZLUGYRQGHQ'HULYDWHQEHUVFKULHEHQXQGGHQ
%HGUIQLVVHQDQJHSDVVW
int m_nId
(LQGHXWLJHUYRQ+DUG\YHUJHEHQHU(OHPHQWLGHQWLILNDWRU:LUGYRU
DOOHPIUGLH$XVZHUWXQJGHU.DQWHQLQIRUPDWLRQYHUZHQGHW
int m_nCard
(LQGHXWLJHUYRQ+DUG\YHUJHEHQHU.DUWHQLGHQWLILNDWRU:LUGIUGLH
(UNHQQXQJGHU(OHPHQWH[SDQVLRQ7UDQVDNWLRQVGLDJUDPPHYHUZHQGHW
CString m_strType
,GHQWLILNDWLRQVVWULQJIUGLH(UNHQQXQJGHV(OHPHQWW\SV
Carray<CString,CString&> m_astrVariable
6DPPOXQJGHU9DULDEOHQ
CArray<CString,CString&> m_astrValue
6DPPOXQJGHU9DULDEOHQZHUWH
Klassenbeschreibung 7-4: CItem
class CItem {
// construction/destruction
public:
CItem() {};
CItem(const CItem& Item);
// types
public:
typedef enum {
typeUnknownClass,
typeDiagram,
typeCard,
typeNode,
typeArc,
typeNodeImage,
typeArcImage
} ItemClass;
typedef enum {
typeUnknown,
typeDatabaseClass,
typeEntryPoint,
typeClassUtility,
typeAbstractClass,
typeNote,
typeInheritance,
typeComponent,
typeObserver,
typeInstantiation,
typeEvolution,
typeInverseRelation,
typeNoteConnector,
Diplomarbeit
Implementation • 189
typeDiagramCard,
typeMainProgram,
typeSubSystem,
typeProgram,
typeFunction,
typeTransaction,
typeCall
} ItemType;
typedef enum {
imageUnknown=IDB_UNKNOWN,
imageDatabaseClass=IDB_DATABASECLASS,
imageEntryPoint=IDB_ENTRYPOINT,
imageClassUtility=IDB_CLASSUTILITY,
imageAbstractClass=IDB_ABSTRACTCLASS,
} ImageId;
// operations
public:
CItem& operator=(const CItem& Item);
// methods
public:
void ReadEntry(CHardyFile&
DiagramFile);
void SetItemClass(const CString&
strId);
ItemClass GetItemClass(void) const;
void SetItemType(void);
ItemType GetItemType(void) const;
void SetImageId(void);
BOOL GetVariableValue(const CString&
strIdentifier,CString& strValue) const;
BOOL GetVariableValue(const CString&
strIdentifier,int& nValue) const;
virtual void Validate(void);
// members
public:
int m_nId;
int m_nCard;
CString m_strType;
ItemClass m_Class;
ItemType m_nType;
ImageId m_nImageId;
CArray<CString,CString&>
m_astrVariable;
CArray<CString,CString&> m_astrValue;
};//end class CItem
Listing 7-7: Klassendefinition von CItem
7.4.4.2 CNode
&1RGHSXEOLF&,WHP
virtual void Validate(void)
/LHVWDXVGHP.DQWHQHLQWUDJGLH.DQWHQLGHQWLILNDWRUHQXQGIOOWGLHVH
:HUWHLQGLH6DPPOXQJm_anArcDE
CArray<int,int&> m_anArc
6DPPOXQJGHU.DQWHQ,QGHQWLILNDWRUHQ
Klassenbeschreibung 7-5: CNode
class CNode : public CItem {
// construction/destruction
public:
CNode() {};
CNode(const CItem& Item) :
CItem(Item) {};
// operations
public:
CNode& operator=(CNode& Node);
// methods
public:
virtual void Validate(void);
190 • Implementation
Diplomarbeit
// members
private:
CArray<int,int&> m_anArc;
}; // end class CNode
Listing 7-8: Klassendefinition von CNode
7.4.4.3 CEntryPoint
&(QWU\3RLQWSXEOLF&1RGH
virtual void Validate(void)
/LHVWGHQSHUVLVWHQWHQ1DPHQDXVGHQ(LQWUlJHQXQGVSHLFKHUWGLHVHQ
LP$WWULEXWm_strPersistentName
CString m_strPersistentName
3HUVLVWHQWHU1DPHGHV(LQVWLHJVSXQNWHV
CString m_strDefinition
'HILQLWLRQVVWULQJGHV(LQVWLHJVSXQNWHVLQ2&
Klassenbeschreibung 7-6: CEntryPoint
class CEntryPoint : public CNode {
// construction/destruction
public:
CEntryPoint() {};
CEntryPoint(const CItem& Item) :
CNode(Item) {};
// operations
public:
CEntryPoint& operator=(CEntryPoint&
EntryPoint);
// methods
public:
virtual void Validate(void);
// attributes
public:
CString m_strPersistentName;
CString m_strDefinition;
}; //end class CEntryPoint
Listing 7-9: Klassendefinition von CEntryPoint
7.4.4.4 CClass
&&ODVVSXEOLF&1RGH
virtual void Validate(void)
/LHVWGHQ.ODVVHQQDPHQXQGGLH(LJHQVFKDIWHQXQGUXIWGLH0HWKRGH
ParsePropertyEntry()DXIXPGLH(LJHQVFKDIWHQ]XDQDO\VLHUHQ
void ParsePropertyEntry(void)
7HLOWGHQ(LJHQVFKDIWVVWULQJLQ6XEVWULQJVMHGH(LJHQVFKDIWPXVVDXI
HLQHUQHXHQ=HLOHGHILQLHUWZHUGHQYJO´'HILQLWLRQGHU
'DWHQEDQNNODVVHQDEVWUDNWHQ.ODVVHQXQG+LOIVNODVVHQµ6HLWH
XQGUXIWDXIJUXQGHLQHVEHVWLPPWHQ(LJHQVFKDIWVPHUNPDOVGLH
VSH]LILVFKH$QDO\VHIXQNWLRQDXI
void ParseMethodProperty(CString strProperty)
/HJWHLQQHXHV2EMHNWGHU.ODVVHCexplicitMethodDQXQGUXIW
GHVVHQCreate0HWKRGHDXI'LHVHUXIWGLHHQWVSUHFKHQGH
$QDO\VHPHWKRGHGHVCParser2EMHNWHVDXIXQGHU]HXJWGLH
,PSOHPHQWDWLRQLQ2&$QVFKOLHVVHQGZLUGGDVQHXH2EMHNWLQGHU
6DPPOXQJm_aExplicitMethodJHVSHLFKHUW
void ParseAttributeProperty(CString strProperty)
/HJWHLQQHXHV2EMHNWGHU.ODVVHCexplicitAttributeDQXQGUXIW
GHVVHQCreate0HWKRGHDXI'LHVHUXIWGLHHQWVSUHFKHQGH
Diplomarbeit
Implementation • 191
$QDO\VHPHWKRGHGHVCParser2EMHNWHVDXI$QVFKOLHVVHQGZLUGGDV
QHXH2EMHNWLQGHU6DPPOXQJm_aExplicitAttributeJHVSHLFKHUW
void ParseKeyAttributeProperty(Cstring strProperty)
/HJWHLQQHXHV2EMHNWGHU.ODVVHCkeyAttributeDQXQGUXIWGHVVHQ
Create0HWKRGHDXI'LHVHUXIWGLHHQWVSUHFKHQGH$QDO\VHPHWKRGH
GHVCParser2EMHNWHVDXI$QVFKOLHVVHQGZLUGGDVQHXH2EMHNWLQGHU
6DPPOXQJm_aKeyAttributeJHVSHLFKHUW
void ParseConstraintProperty(CString strProperty)
5XIWGLHHQWVSUHFKHQGH$QDO\VHPHWKRGHGHVCParser2EMHNWHVDXI
XQGVSHLFKHUWGDV5HVXOWDWLQGHU6DPPOXQJm_astrConstraint
CString m_strClassName
1DPHGHU.ODVVH
CString m_strProperties
'HILQLWLRQVVWULQJGHU(LJHQVFKDIWHQ:LUGQXUIU
5HSURGXNWLRQV]ZHFNHJHVSHLFKHUW
CArray<CExplicitMethod,CExplicitMethod&>
m_aExplicitMethod
6DPPOXQJGHUH[SOL]LWHQ0HWKRGHQ
CArray<CExplicitAttribute,CExplicitAttribute&>
m_aExplicitAttribute
6DPPOXQJGHUH[SOL]LWHQ$WWULEXWH
CArray<CKeyAttribute,CKeyAttribute&> m_aKeyAttribute
6DPPOXQJGHU6FKOVVHODWWULEXWH
CArray<CString,CString&> m_astrConstraint
6DPPOXQJGHU.RQVLVWHQ]EHGLQJXQJHQ
Klassenbeschreibung 7-7: CClass
class CClass : public CNode {
// construction/destruction
public:
CClass() {};
CClass(const CItem& Item) :
CNode(Item) {};
// operations
public:
CClass& operator=(CClass& Class);
// methods
public:
virtual void Validate(void);
void ParsePropertyEntry(void);
void ParseMethodProperty(CString
strProperty);
void ParseConstraintProperty(CString
strProperty);
void
ParseKeyAttributeProperty(CString strProperty);
void ParseAttributeProperty(const
CString& strProperty);
void CreateComponentRelation(CClass*
pClass,CString strCardinality,CString
strCardinalityInverse);
void CreateInverseRelation(CClass*
pClass,CString strCardinality,CString
strCardinalityInverse);
void CreateObserverRelation(CClass*
pClass,CString strCardinality,CString
strCardinalityInverse);
void CreateEvolutionRelation(CClass*
pFromClass,CClass* pToClass,CClass* pParentClass);
192 • Implementation
Diplomarbeit
void CreateVirtualMethods(void);
void CreateDefinition(CString
strParents);
void Show(HTREEITEM
hClassRoot,CTreeCtrl& TreeCtrl,UINT nMask,CClassView*
pClassView);
private:
CString GetLabel(void);
// attributes
public:
// user defined values
CString m_strClassName;
CString m_strProperties;
// user defined members
CArray<CExplicitAttribute,CExplicitAttribu
te&> m_aExplicitAttribute;
CArray<CExplicitMethod,CExplicitMethod&>
m_aExplicitMethod;
// virtual functions inherited from
DBObject
CArray<CVirtualMethod,CVirtualMethod&>
m_aConstructor;
CArray<CVirtualMethod,CVirtualMethod&>
m_aVirtualMethod;
// relations
CArray<CComponentRelation,CComponentRelati
on&> m_aComponentRelation;
CArray<CInverseRelation,CInverseRelation&>
m_aInverseRelation;
CArray<CObserverRelation,CObserverRelation
&> m_aObserverRelation;
// evolution
CArray<CEvolutionRelation,CEvolutionRelati
on&> m_aEvolutionRelation;
// key attributes
CArray<CKeyAttribute,CKeyAttribute&>
m_aKeyAttribute;
// constraints
CArray<CString,CString&>
m_astrConstraint;
// class definition string in ODL
CString m_strParents;
CString m_strDefinition;
}; // end class CClass
Listing 7-10: Klassendefinition von CClass
7.4.4.5 Derivate der Klasse CClass
'LHZHLWHUHQ'HULYDWHGHU.ODVVHCClassXQWHUVFKLHGHQVLFK
NDXPYRQGHU%DVLVNODVVH(LQ]LJGLH.ODVVH
CDatabaseClassHUKlOWHLQ]XVlW]OLFKHV$WWULEXW
CArray<CKeyAttribute,CKeyAttribute&>
m_aKeyAttributeIUGLH6SHLFKHUXQJGHU
6FKOVVHODWWULEXWH'HU9ROOVWlQGLJNHLWKDOEHUVHLHQDEHUGLH
.ODVVHQGHILQLWLRQHQWURW]GHPGDUJHVWHOOW
class CDatabaseClass : public CClass {
// construction/destruction
public:
CDatabaseClass() {};
CDatabaseClass(const CItem& Item) :
CClass(Item) {};
Diplomarbeit
Implementation • 193
// operations
public:
CDatabaseClass&
operator=(CDatabaseClass& DatabaseClass);
// attributes
public:
// user defined members
CArray<CKeyAttribute,CKeyAttribute&>
m_aKeyAttribute;
}; //end class CDatabaseClass
Listing 7-11: Klassendefinition von CDatabaseClass
class CAbstractClass : public CClass {
// construction/destruction
public:
CAbstractClass() {};
CAbstractClass(const CItem& Item) :
CClass(Item) {};
// operations
public:
CAbstractClass&
operator=(CAbstractClass& AbstractClass);
}; //end class CAbstractClass
Listing 7-12: Klassendefinition von CAbstractClass
class CClassUtility : public CClass {
// construction/destruction
public:
CClassUtility() {};
CClassUtility(const CItem& Item) :
CClass(Item) {};
// operations
public:
CClassUtility&
operator=(CClassUtility& ClassUtility);
}; //end class CClassUtility
Listing 7-13: Klassendefinition von CClassUtility
7.4.4.6 CArc
&$UFSXEOLF&,WHP
virtual void Validate(void)
/LHVWDXVGHU9HUELQGXQJVHLJHQVFKDIWGHQ,GHQWLILNDWRUGHV$XVJDQJV
XQGGHV=LHONQRWHQVDXVXQGZHLVWGLHVH:HUWHGHQ$WWULEXWHQ
m_nFromNode XQGm_nToNode ]X
int m_nFromNode
,GHQWLILNDWRUGHV$XVJDQJVNQRWHQV
int m_nToNode
,GHQWLILNDWRUGHV=LHONQRWHQV
Klassenbeschreibung 7-8: CArc
class CArc : public CItem {
// construction/destruction
public:
CArc() {};
CArc(const CItem& Item) : CItem(Item)
{};
// operations
public:
CArc& operator=(CArc& Arc);
// methods
public:
virtual void Validate(void);
// attributes
public:
int m_nFromNode;
int m_nToNode;
}; //end class CArc
Listing 7-14: Klassendefinition von CArc
7.4.4.7 Derivate der Klasse CArc
194 • Implementation
Diplomarbeit
'LHYHUELQGXQJVW\SVSH]LILVFKHQ'HULYDWHGHU.ODVVHCArc
XQWHUVFKHLGHQVLFKNDXPYRQLKUHU%DVLVNODVVH'LH
.RPSRQHQWHQXQGGLHLQYHUVH%H]LHKXQJVSHLFKHUQ
]XVlW]OLFKGLHYRP(QWZHUIHUHUIDVVWHQ
.DUGLQDOLWlWVHLJHQVFKDIWHQXQGPVVHQGLHVHHQWVSUHFKHQGLQ
LKUHUValidate0HWKRGHDXVGHQ9DULDEOHQZHUWHQ
KHUDXV]LHKHQ8PGHU9ROOVWlQGLJNHLW]XJHQJHQVROOHQGLH
.ODVVHQGHILQLWLRQHQQDFKIROJHQGDEJHELOGHWZHUGHQ
class CComponentArc : public CArc {
// construction/destruction
public:
CComponentArc() {};
CComponentArc(const CItem& Item) :
CArc(Item) {};
// operations
public:
CComponentArc&
operator=(CComponentArc& ComponentArc);
// methods
public:
virtual void Validate(void);
// attributes
public:
CString m_strCardinality;
CString m_strCardinalityInverse;
}; //end class CComponentArc
Listing 7-15: Klassendefinition von CComponentArc
class CInverseRelationArc : public CArc {
// construction/destruction
public:
CInverseRelationArc() {};
CInverseRelationArc(const CItem&
Item) : CArc(Item) {};
// operations
public:
CInverseRelationArc&
operator=(CInverseRelationArc& InverseRelationArc);
// methods
public:
virtual void Validate(void);
// attributes
public:
CString m_strCardinality;
CString m_strCardinalityInverse;
}; //end class CInverseRelationArc
Listing 7-16: Klassendefinition von CInverseRelationArc
class CInstantiationArc : public CArc {
// construction/destruction
public:
CInstantiationArc() {};
CInstantiationArc(const CItem& Item)
: CArc(Item) {};
// operations
public:
CInstantiationArc&
operator=(CInstantiationArc& InstantiationArc);
}; //end class CInstantiationArc
Listing 7-17: Klassendefinition von CInstantiationArc
class CObserverArc : public CArc {
// construction/destruction
public:
CObserverArc() {};
CObserverArc(const CItem& Item) :
CArc(Item) {};
// operations
public:
Diplomarbeit
Implementation • 195
CObserverArc& operator=(CObserverArc&
ObserverArc);
}; //end class CObserverArc
Listing 7-18: Klassendefinition von CObserverArc
class CEvolutionArc : public CArc {
// construction/destruction
public:
CEvolutionArc() {};
CEvolutionArc(const CItem& Item) :
CArc(Item) {};
// operations
public:
CEvolutionArc&
operator=(CEvolutionArc& EvolutionArc);
}; //end class CEvolutionArc
Listing 7-19: Klassendefinition von CEvolutionArc
class CInheritanceArc : public CArc {
// construction/destruction
public:
CInheritanceArc() {};
CInheritanceArc(const CItem& Item) :
CArc(Item) {};
// operations
public:
CInheritanceArc&
operator=(CInheritanceArc& InheritanceArc);
}; //end class CInheritanceArc
Listing 7-20: Klassendefinition von CInheritanceArc
7.4.5 Validierungen
1DFKGHPGLH(OHPHQWHDXVGHU+DUG\GDWHLYROOVWlQGLJJHOHVHQ
ZRUGHQVLQGN|QQHQEHUHLWVZHLWHUUHLFKHQGH9DOLGLHUXQJHQGHU
'LDJUDPPLQIRUPDWLRQHQGXUFKJHIKUWZHUGHQ
(VZLUGLQVEHVRQGHUHJHSUIWRE
• PLQGHVWHQVHLQ(LQVWLHJVSXQNWLP'LDJUDPPHQWKDOWHQLVW
• JOHLFKYLHOH,QVWDQWLLHUXQJVSIHLOHZLH(LQVWLHJVSXQNWHLP'LDJUDPP
HQWKDOWHQVLQG
'LH3UIXQJGHU]ZHLWHQ%HGLQJXQJVWHOOW]XGHPVLFKHUGDVVDXFK
PLQGHVWHQVHLQH'DWHQEDQNNODVVHGHILQLHUWZRUGHQLVWGDHLQ
,QVWDQWLLHUXQJVSIHLOQXUGDQQJH]HLFKQHWZHUGHQNDQQZHQQHUDXI
HLQHGHUDUWLJH.ODVVH]XOlXIW
:HLWHUH9DOLGLHUXQJHQ(LQGHXWLJNHLW=\NOHQIUHLKHLWHWFZHUGHQ
ODXIHQGZlKUHQGGHUQDFKIROJHQGHQ9HUDUEHLWXQJYRUJHQRPPHQXQG
PVVHQGHPQDFKQLFKWVSH]LHOOLQGLHVHP$EVFKQLWWEHKDQGHOW
ZHUGHQ
7.4.6 Die Graphklassen
196 • Implementation
Diplomarbeit
ITEM
ITEM
CGraph
CGraphNode
Parents
Children
CClass
CVisualClass
Tree
CComponent
Tree
CInheritance
Graph
Klassendiagramm 7-5: Klassen für den Aufbau der Graphen
.ODVVHQYRQ26:22'
CGraph
.ODVVHQYRUODJHIUGLH0RGHOOLHUXQJHLQHV*UDSKHQPLWEHOLHELJHQ
.QRWHQHOHPHQWHQ
CGraphNode
.ODVVHQYRUODJHIUHLQHQ.QRWHQLQHLQHP*UDSKHQ
CVisualClassTree
,QVWDWLLHUXQJHLQHV*UDSKHQPLW.QRWHQYRP7\SCClassHUZHLWHUW
XPYHUVFKLHGHQH9LVXDOLVLHUXQJVPHWKRGHQ]XUhEHUIKUXQJLQHLQ
CTreeCtrl2EMHNW0)&
CInheritanceGraph
9HUHUEXQJVJUDSK
CComponentTree
.RPSRQHQWHQEDXP
7.4.6.1 CGraph
&*UDSK,7(07<3(!
HITEM AddNode(ITEMTYPE* pClass, HITEM hGraphItem
=GRAPHROOT)
)JWHLQHQQHXHQ.QRWHQLP*UDSKHQDOV.LQGHGHV.QRWHQV
hGraphItem HLQ:LUGNHLQ9DWHUDQJHJHEHQZLUGGDV(OHPHQWDOV
:XU]HOKLQ]XJHIJW
void SetParent(HITEM hChild, HITEM hParent) const
6HW]WGHQ9DWHUGHV(OHPHQWHVhChildDXIGHQ:HUWhParent
HGRAPHITEM GetFirstRoot(void) const
/LHIHUWGDVHUVWH:XU]HOREMHNWGHV*UDSKHQ(OHPHQWRKQH9DWHU
HGRAPHITEM GetNextRoot(HGRAPHITEM hRoot) const
/LHIHUWGDVQlFKVWIROJHQGH(OHPHQWLQGHU/LVWHGHU:XU]HOREMHNWH0LW
GHU,WHUDWLRQEHUGLH0HWKRGHQGetFirstRoot()XQG
GetNextRoot()ODVVHQVLFKDOOH:XU]HOREMHNWDXIOLVWHQ
HGRAPHITEM Find(const ITEMTYPE* pClass) const
/LHIHUWIUHLQJHJHEHQHV2EMHNWGHQ=HLJHUDXIGDVHQWVSUHFKHQGH
Diplomarbeit
Implementation • 197
.QRWHQHOHPHQW
ITEMTYPE* GetClass(HGRAPHITEM hGraphItem) const
/LHIHUWIUHLQJHJHEHQHV.QRWHQHOHPHQWGHQHQWVSUHFKHQGHQ=HLJHU
DXIGDVGDULQJHVSHLFKHUWH2EMHNW
CPtrArray m_apNode
6DPPOXQJDOOHU.QRWHQ
Klassenbeschreibung 7-9: CGraph
#define GRAPHITEM CGraphNode<ITEMTYPE>
#define HGRAPHITEM CGraphNode<ITEMTYPE>*
#define GRAPHROOT NULL
template<class ITEMTYPE>
class CGraph {
public:
~CGraph();
public:
HITEM AddNode(ITEMTYPE* pClass,HITEM
hGraphItem=GRAPHROOT);
void SetParent(HITEM hChild,HITEM
hParent) const;
HGRAPHITEM GetFirstRoot(void) const;
HGRAPHITEM GetNextRoot(HGRAPHITEM
hRoot) const;
HGRAPHITEM GetFirstLeaf(void) const;
HGRAPHITEM GetNextLeaf(HGRAPHITEM
hLeaf) const;
HGRAPHITEM Find(const ITEMTYPE*
pClass) const;
inline const ITEMTYPE*
GetClass(HGRAPHITEM hGraphItem) const;
private:
inline void SetParent(HGRAPHITEM
hChild,HGRAPHITEM hParent) const;
public:
CPtrArray m_apNode;
}; //end class CGraph
Listing 7-21: Klassendefinition von CGraph
7.4.6.2 CGraphNode
&*UDSK1RGH,7(07<3(!
void SetParent(const HGRAPHNODE)
)JWGHQJHJHEHQHQ.QRWHQ]XU6DPPOXQJGHU9lWHUKLQ]X
void SetChild(const HGRAPHNODE)
)JWGHQJHJHEHQHQ.QRWHQ]XU6DPPOXQJGHU.LQGHUKLQ]X
inline BOOL IsRoot(void) const
*LEWDQREGHU.QRWHQHLQH:XU]HOLVW0HQJHGHU9lWHUOHHU
inline BOOL HasChilds(void) const
*LEWDQREGHU.QRWHQ.LQGHUKDW0HQJHGHU.LQGHUQLFKWOHHU
HGRAPHNODE GetFirstChild(void) const
/LHIHUWGHQHUVWHQ.QRWHQDXVGHU6DPPOXQJDOOHU.LQGHU
HGRAPHNODE GetNextChild(const HGRAPHNODE hChild)
const
/LHIHUWGHQQlFKVWHQ.QRWHQDXVGHU6DPPOXQJGHU.LQGHU0LWGHQ
)XQNWLRQHQGetFirstChild()XQGGetNextChild() OlVVWVLFK
HLQIDFKEHUGLH0HQJHGHU.LQGHULWHULHUHQ
ITEMTYPE* GetItem(void) const
/LHIHUWGDVPLWGHP.QRWHQYHUEXQGHQH*UDSKHOHPHQW
CPtrArray m_apParentNode
6DPPOXQJGHU=HLJHUDXIGLH9lWHU
198 • Implementation
Diplomarbeit
CPtrArray m_apChildNode
6DPPOXQJGHU=HLJHUDXIGLH.LQGHU
ITEMTYPE* m_pItem
=HLJHUDXIGDVGXUFKGHQ.QRWHQUHSUlVHQWLHUWH2EMHNW
Klassenbeschreibung 7-10: CGraphNode
#define HGRAPHNODE CGraphNode<ITEMTYPE>*
template<class ITEMTYPE>
class CGraphNode {
public:
CGraphNode(ITEMTYPE*);
~CGraphNode(void);
public:
void SetParent(const HGRAPHNODE);
void SetChild(const HGRAPHNODE);
inline BOOL IsRoot(void) const;
inline BOOL HasChilds(void) const;
HGRAPHNODE GetFirstChild(void) const;
HGRAPHNODE GetNextChild(const
HGRAPHNODE hChild) const;
inline BOOL IsLeaf(void) const;
inline BOOL HasParents(void) const;
HGRAPHNODE GetFirstParent(void)
const;
HGRAPHNODE GetNextParent(const
HGRAPHNODE hParent) const;
ITEMTYPE* GetItem(void) const;
private:
CPtrArray m_apParentNode;
CPtrArray m_apChildNode;
ITEMTYPE* m_pItem;
}; //end class CGraphNode
Listing 7-22: Klassendefinition von CGraphNode
7.4.6.3 CVisualClassTree
'LH.ODVVHCVisualClassTreeLQVWDQWLLHUWGLHYRUJlQJLJ
HUOlXWHUWH.ODVVHQYRUODJHCGraphPLWGHP7\SHQCClass
class CVisualClassTree : public
CGraph<CClass>
)UGLH$Q]HLJHHLQHV*UDSKHQELHWHWVLHHLQH)XQNWLRQ
PrintTree()]XU9HUZHQGXQJDQ'LHVHVHW]WGHQ
*UDSKHQLQHLQHQ%DXPXPXQGPXVVGHVKDOEGDYRQ
DXVJHKHQN|QQHQGDVVVLFKLP*UDSKHQNHLQH=\NOHQ
EHILQGHQ'LH3UIXQJGLHVHU9RUDXVVHW]XQJEOHLEWGHU
,PSOHPHQWDWLRQGHV$XIEDXDOJRULWKPXV·YRUHQWKDOWHQ
'LH8PVHW]XQJVHLQDFKIROJHQGEHVFKULHEHQ
void CVisualClassTree::PrintTree(CTreeCtrl& TreeCtrl,
HTREEITEM hRoot) const {
const CClass* pClass;
...
(1)
for (CGraphNode<CClass>*
hCurrentRoot=GetFirstRoot();
(7)
hCurrentRoot!=NULL;
(6)
hCurrentRoot=GetNextRoot(hCurrentRoot)) {
(2)
pClass=GetClass(hCurrentRoot);
(3)
HTREEITEM
hTreeItem=TreeCtrl.InsertItem(...);
(4)
(5)
if (hCurrentRoot->HasChilds())
PrintChilds(TreeCtrl,hCurrentRoot,hTreeIte
m);
}//endfor
}//end PrintTree
Listing 7-23: Aufbau eines visuellen Baumes
Diplomarbeit
Implementation • 199
(UVWHU:XU]HONQRWHQEHVFKDIIHQ
2EMHNW]HLJHUEHVFKDIIHQ
2EMHNWLQGHQYLVXHOOHQ%DXPHLQIJHQ
3UIHQREGDV2EMHNW.LQGHUEHVLW]W
:HQQMDGLHVHHEHQIDOOVLQGHQ%DXPHLQIJHQ
1lFKVWHV:XU]HOREMHNWEHVFKDIIHQ
VRODQJHQRFKHLQHVYRUKDQGHQLVW
'LH8PVHW]XQJGHU)XQNWLRQ]XP(LQIJHQGHU.LQGHUVHL
QDFKIROJHQGEHVFKULHEHQ
(1)
(2)
(3)
(4)
(5)
(6)
(7)
void CVisualClassTree::PrintChilds(CTreeCtrl& TreeCtrl,
const CGraphNode<CClass>* hParent,
HTREEITEM hTreeParent) const {
const CClass* pClass;
...
(1)
for (CGraphNode<CClass>*
hCurrentChild=hParent->GetFirstChild();
(7)
hCurrentChild!=NULL;
(6)
hCurrentChild=hParent>GetNextChild(hCurrentChild)) {
(2)
pClass=GetClass(hCurrentChild);
(3)
HTREEITEM
hTreeItem=TreeCtrl.InsertItem(...);
(4)
(5)
if (hCurrentChild->HasChilds())
PrintChilds(TreeCtrl,hCurrentChild,hTreeIt
em);
}//endfor
}//end PrintChilds
Listing 7-24: Klassendefinition von CGraph
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(UVWHU.LQGNQRWHQEHVFKDIIHQ
2EMHNW]HLJHUEHVFKDIIHQ
2EMHNWLQGHQYLVXHOOHQ%DXPHLQIJHQ
3UIHQREGDV2EMHNWZHLWHUH.LQGHUEHVLW]W
:HQQMD.LQGHVNLQGHUHEHQIDOOVLQGHQ%DXPHLQIJHQ
1lFKVWHV.LQGREMHNWEHVFKDIIHQ
VRODQJHQRFKHLQHVYRUKDQGHQLVW
7.4.7 Aufbau des Vererbungsgraphen
'DLPEHWUDFKWHWHQ'DWHQEDQNV\VWHP0HKUIDFKYHUHUEXQJ]XJHODVVHQ
LVWPXVVGLH9HUHUEXQJVKLHUDUFKLHDOV*UDSKPRGHOOLHUWZHUGHQ'HU
*UDSKEHVWHKWGDEHLDXVEHOLHELJYLHOHQ%DXPHOHPHQWHQGHV7\SV
'DWHQEDQNNODVVHDEVWUDNWH.ODVVHXQG+LOIVNODVVH'DZlKUHQGGHV
$XIEDXVDEHUDXFKZlKUHQGGHV$XVOHVHQVGHUJHQDXH7\SGHV
(OHPHQWHVQLFKWYRQ%HGHXWXQJLVWZHUGHQGLH.QRWHQGHV*UDSKHQ
PLWGHQ,QVWDQ]HQGHU%DVLVNODVVHCClassYHUEXQGHQ
)UGHQ$XIEDXGHU9HUHUEXQJVKLHUDUFKLHPVVHQDOVRGLH/LVWHGHU
9HUHUEXQJVSIHLOHVRZLHGLH/LVWHGHU'DWHQEDQNNODVVHQGHU
+LOIVNODVVHQXQGGHUDEVWUDNWHQ.ODVVHQEHUFNVLFKWLJWZHUGHQ
)UGHQ$XIEDXGHV*UDSKHQZLUGGDV9RUJHKHQJHZlKOWZHOFKHV
]XHUVWDXVGHU0HQJHGHU.ODVVHQGLH:XU]HOHOHPHQWKHUDXV]LHKWXQG
DQVFKOLHVVHQGYRQLKQHQDXVJHKHQGGLH6XENODVVHQEHVWLPPW
:XU]HOREMHNWHZHUGHQLP)ROJHQGHQDXFKÅ8UYlWHU´JHQDQQWDOVR
.ODVVHQGLHEH]JOLFKGHU9HUHUEXQJNHLQHZHLWHUHQ9lWHUPHKU
EHVLW]HQ
200 • Implementation
Diplomarbeit
'LH6XFKHQDFKGHQ8UYlWHUQPXVVEH]LHKXQJVEHUGHFNHQGVHLQ
ZHLODQVRQVWHQ=\NOHQLQGHQ%H]LHKXQJHQXQHQWGHFNWEOHLEHQ
N|QQWHQ
'DVJHQHUHOOH9RUJHKHQNDQQLQGLH6FKULWWHÅ6XFKHQDFKGHP
8UYDWHU´ÅUHNXUVLYHV)OOHQGHV*UDSKHQ´XQGÅ(LQIJHQGHU
YHUEOHLEHQGHQ.ODVVHQ´XQWHUWHLOWZHUGHQ'DEHLNDQQGHUHUVWH
$EVFKQLWWHWZDZLHIROJWXPULVVHQZHUGHQ
$XVGHU/LVWHGHU9HUHUEXQJVEH]LHKXQJHQZLUGHLQQRFKQLFKW
EHVXFKWHV(OHPHQWJHQRPPHQXQGGLHMHQLJH.ODVVHDXVGHQ
.ODVVHQOLVWHQJHVXFKWGLHDOV9DWHUGLHVHU%H]LHKXQJ]XLQWHUSUHWLHUHQ
LVW(QGHGHU.DQWH
'LH.LQGNODVVHGLH9DWHUNODVVHVRZLHGLH%H]LHKXQJZHUGHQDOV
ÅEHVXFKW´JHNHQQ]HLFKQHW
$XVGHU/LVWHGHU9HUHUEXQJVEH]LHKXQJHQZLUGHLQ(OHPHQW
JHVXFKWZHOFKHVGLHJHIXQGHQH.ODVVHVHOEHUDOV.LQGNODVVHDXVZHLVW
%HJLQQGHU.DQWH
:LUGHLQVROFKHV(OHPHQWJHIXQGHQZLUGGHU6FKULWWIU
GLHMHQLJH.ODVVHZLHGHUKROWGLHDOV9DWHUGLHVHU%H]LHKXQJ]X
LQWHUSUHWLHUHQLVW(QGHGHU.DQWH'LH.ODVVHVRZLHGLH%H]LHKXQJ
ZLUGDOVÅEHVXFKW´JHNHQQ]HLFKQHW
:LUGNHLQVROFKHV(OHPHQWJHIXQGHQRGHUVLQGDOOH%H]LHKXQJHQ
VFKRQEHVXFKWLVWGHU8UYDWHUJHIXQGHQ'HU8UYDWHUZLUGLQGLH
/LVWHGHU:XU]HOQGHU9HUHUEXQJVKLHUDUFKLHDXIJHQRPPHQ'LH
.ODVVHQZHUGHQDOOHVDPWDXIÅXQEHVXFKW´]XUFNJHVHW]W
:LUGLQ6FKULWWHLQH.ODVVHDOV9DWHUJHIXQGHQGLHEHUHLWVEHVXFKW
ZRUGHQLVWLVWGHU*UDSKGHU9HUHUEXQJVEH]LHKXQJHQQLFKW
]\NOHQIUHL(LQHHQWVSUHFKHQGH)HKOHUEHGLQJXQJPXVVDXVJHO|VW
ZHUGHQ
,P)ROJHQGHQVROOGLH,PSOHPHQWDWLRQGHV$OJRULWKPXV·DEJHELOGHW
XQGPLWYHUVFKLHGHQHQ.RPPHQWDUHQHUOlXWHUWZHUGHQ
9RUEHUHLWXQJHQ
void CSchemaDoc::CreateInheritanceHierarchy(void) {
int i;
(1)
// create and initialize visitor array
CArray<BOOL,BOOL&> abArcVisited;
abArcVisited.SetSize(m_aInheritanceArc.Get
Size());
for
(i=0;i<abArcVisited.GetSize();abArcVisited[i++]=FALSE);
// create and initialize array of used
arcs
(2)
CArray<BOOL,BOOL&> abArcUsed;
abArcUsed.SetSize(m_aInheritanceArc.GetSiz
e());
for
(i=0;i<abArcUsed.GetSize();abArcUsed[i++]=FALSE);
// create list of adams
CArray<int,int&> anArcToAdam;
CArray<int,int&> anAdamId;
Listing 7-25: Funktion CreateInheritanceHierarchy (Vorbereitungen)
(3)
$XIEDXHLQHV9HNWRUVZHOFKHUGLHEHUHLWVEHVXFKWHQ
9HUHUEXQJVEH]LHKXQJHQVSHLFKHUW$OOH.DQWHQZHUGHQDXIGHQ
6WDWXV¶QLFKWEHVXFKW·LQLWLDOLVLHUW
(2) $XIEDXHLQHV9HNWRUVZHOFKHUGLHEHUHLWVIUHLQH9HUHUEXQJ
YHUZHQGHWHQ9HUHUEXQJVEH]LHKXQJHQVSHLFKHUW$OOH.DQWHQZHUGHQ
DXIGHQ6WDWXV¶QLFKWEHQXW]W·LQLWLDOLVLHUW
(1)
Diplomarbeit
Implementation • 201
(3) $XIEDXHLQHV9HNWRUVZHOFKHUGLH9HUHUEXQJVEH]LHKXQJHQGLH
DXIHLQHQ8UYDWHU]HLJHQVSHLFKHUW
(4) $XIEDXHLQHV9HNWRUVZHOFKHUGLH,GHQWLILNDWRUHQGHU8UYlWHU
VSHLFKHUW
6XFKHQDFKGHQ8UYlWHUQ
// do while there are unvisited
inheritance relations
(1)
int nCurrentArc;
while (TRUE) {
// get next not yet visited
inheritance relation
(2)
for (nCurrentArc=0;
nCurrentArc<m_aInheritanceArc.GetSize();
nCurrentArc++) {
if
(!abArcVisited[nCurrentArc]) break;
}//endfor
(3)
if
(nCurrentArc==m_aInheritanceArc.GetSize()) break;
(4)
abArcVisited[nCurrentArc]=TRUE;
(5)
// search adam
while (TRUE) {
// search parent class for
current class
(6)
for (int
j=0;j<m_aInheritanceArc.GetSize();j++) {
if
(m_aInheritanceArc[j].m_nFromNode ==
m_aInheritanceArc[nCurrentArc].m_nToNode)
break;
}//endfor
// if there is no parent, an
adam candidate is found
(7)
m_aInheritanceArc.GetSize()) {
if (j ==
// check if this is an
new one
(8)
(i=0;i<anArcToAdam.GetSize();i++) {
for
if
(m_aInheritanceArc[anArcToAdam[i]].m_nToNode ==
m_aInheritanceArc[nCurrentArc].m_nToNode)
break;
}//endif
if
(i==anArcToAdam.GetSize())
(9)
anArcToAdam.Add(nCurrentArc);
break;
}//endif
// if there is an arc found
which was already used to find an adam
(10)
if (abArcUsed[j]) break;
// if there is an arc found
which was already visited, there is a cycle
(11)
if (abArcVisited[j])
throw CFatalError
("Class daigram contains a cylce in the inheritance");
// the current is not the adam
so continue search with his parent
(12)
nCurrentArc=j;
(13)
// set relation as visited
abArcVisited[nCurrentArc]=TRUE;
}//endwhile
(14)
// set the visited arcs as used
for (i=0;i<abArcUsed.GetSize();i++) {
abArcUsed[i]=(abArcUsed[i]||abArcVisited[i
]);
}//endfor
202 • Implementation
Diplomarbeit
}//endwhile
Listing 7-26: Funktion CreateInheritanceHierarchy (Suche nach den Urvätern)
(1) bXVVHUH6FKOHLIHZLUGVRODQJHGXUFKODXIHQZLHQRFKQLFKW
EHVXFKWH%H]LHKXQJHQH[LVWLHUHQ
(2) hEHUGLH0HQJHDOOHU%H]LHKXQJHQZLUGLWHULHUWELVHLQHQRFK
QLFKWEHVXFKWH.DQWHJHIXQGHQZHUGHQNRQQWH'LHVHZLUG]XU
DNWXHOOHQ.DQWH
(3) )DOOVNHLQHVROFKH.DQWHPHKUJHIXQGHQZHUGHQNRQQWHZLUGGLH
lXVVHUH6FKOHLIHYHUODVVHQ
(4) 'LHDNWXHOOH.DQWHZLUGDOV¶EHVXFKW·PDUNLHUW
(5) 'LHLQQHUH6FKOHLIHZLUGGXUFKODXIHQELVHLQHGHU
XQWHQVWHKHQGHQ$EEUXFKEHGLQJXQJHQHUIOOWLVW
(6) $XVGHU0HQJHGHU%H]LHKXQJHQZLUGHLQH.DQWHJHVXFKW
ZHOFKHGLHGXUFKGLHDNWXHOOH.DQWHUHIHUHQ]LHUWH.ODVVHDOV
$XVJDQJVNQRWHQEHVLW]W
(7) .RQQWHNHLQHGHUDUWLJH.DQWHJHIXQGHQZHUGHQN|QQWHHVVLFK
EHLGHUGXUFKGLHDNWXHOOH.DQWHUHIHUHQ]LHUWH.ODVVHXPHLQHQ
8UYDWHUKDQGHOQ
(8) 'HU.DQGLGDWN|QQWHDEHUEHUHLWVLQGHU0HQJHGHU8UYlWHU
HQWKDOWHQVHLQZHVKDOELQGLHVHUQDFKGHP.DQGLGDWHQJHVXFKW
ZHUGHQPXVV
(9) +DQGHOWHVVLFKWDWVlFKOLFKXPHLQHQQHXHQ.DQGLGDWHQZLUGHU
LQGLH/LVWHGHU8UYlWHUDXIJHQRPPHQ
(10) :XUGHGLHDNWXHOOH.DQWHEHUHLWVIUGDV$XIILQGHQHLQHV
8UYDWHUVYHUZHQGHWEULQJWGLHVH.DQWHNHLQHQHXHQ(UNHQQWQLVVH
PHKUZHVKDOEDXVGHULQQHUHQ6FKOHLIHQKHUDXVJHVSUXQJHQZLUG
(11) :XUGHGLHDNWXHOOH.DQWHEHUHLWVHLQPDOEHVXFKWVRKDWPDQHV
PLWHLQHP=\NOXVLQGHU9HUHUEXQJ]XWXQXQGPXVVGLH
9HUDUEHLWXQJPLWGHU$XVO|VXQJHLQHU$XVQDKPHEHHQGHQ
(12) +DQGHOWHVVLFKEHLGHUDNWXHOOHQ.DQWHQLFKWXPHLQHDXIHLQHQ
8UYDWHU]HLJHQGHVRZLUGPLWGHVVHQ¶1DFKIROJHNDQWH·DOVDNWXHOOH
.DQWHZHLWHUJHVXFKW
(13) 'LHQHXH.DQWHZLUGHEHQIDOOVDOV¶EHVXFKW·JHNHQQ]HLFKQHW
(14) .RQQWHHLQ8UYDWHUJHIXQGHQZHUGHQVRPVVHQGLHIUGHVVHQ
$XIILQGXQJEHQ|WLJWHQ.DQWHQDOV¶EHQXW]W·PDUNLHUWZHUGHQ
$XIIOOHQGHU*UDSKHQPLWGHQ.LQGHUQGHU8UYlWHU
(1)
(2)
// fill the inheritance graph recursively
CArray<int,int&> anAddedClassId;
CClass* pClass;
int nAdamId;
HITEM hRoot;
for (i=0;i<anArcToAdam.GetSize();i++) {
nAdamId=m_aInheritanceArc[anArcToAdam[i]].
m_nToNode;
pClass=GetClass(nAdamId);
ASSERT(pClass);
(3)
hRoot=m_InheritanceGraph.AddNode(pClass);
anAddedClassId.Add(nAdamId);
(4)
AddDerivedClasses(nAdamId,hRoot,anAddedCla
ssId);
}//endif
Listing 7-27: Funktion CreateInheritanceHierarchy (rekursives Füllen des Graphen)
(1) $XIEDXHLQHV9HNWRUVZHOFKHUGLHEHUHLWVLQGHQ*UDSKHQ
DXIJHQRPPHQHQ.ODVVHQLGHQWLILNDWRUHQVSHLFKHUW:LUGIUGDV
(LQIJHQGHUUHVWOLFKHQ.ODVVHQYHUZHQGHW
Diplomarbeit
Implementation • 203
-HGHUJHIXQGHQH8UYDWHU
ZLUGLQGHQ9HUHUEXQJVJUDSKHQHLQJHVHW]W
'DVVHOEHSDVVLHUWDXFKPLWGHVVHQ.LQGHUQ
+LQ]XIJHQGHU.LQGHUHLQHV8UYDWHUV
(2)
(3)
(4)
void CSchemaDoc::AddDerivedClasses(int nParentId,HITEM hParent,
CArray<int,int&>& anAddedClassId) {
CClass* pClass;
HITEM hChild;
int nChildId;
// search in the list of arcs for all
nodes having an arc to current parent
(1)
for (int
i=0;i<m_aInheritanceArc.GetSize();i++) {
// for each such node found get his
class, add the node to inheritance graph
(2)
if
(m_aInheritanceArc[i].m_nToNode==nParentId) {
nChildId=m_aInheritanceArc[i].m_nFromNode;
pClass=GetClass(nChildId);
ASSERT(pClass);
(3)
hChild=m_InheritanceGraph.AddNode(pClass,h
Parent);
anAddedClassId.Add(nChildId);
// and look for his children
(4)
AddDerivedClasses(nChildId,hChild,anAddedC
lassId);
}//endif
}//endfor
}//end AddDerivedClasses
Listing 7-28: Funktion AddDerivedClasses (rekursives Füllen des Graphen)
(1) 6XFKHLQGHU0HQJHGHU9HUHUEXQJVEH]LHKXQJHQDOOH
%H]LHKXQJHQ
(2) ZHOFKHDXIGHQ9DWHU]HLJHQ
(3) )JHGLHVH.ODVVH
(4) XQGGHVVHQ.LQGHUGHP9HUHUEXQJVJUDSKHQKLQ]X
+LQ]XIJHQGHUYHUEOHLEHQGHQ.ODVVHQ
// add the non used database classes as
roots
(1)
{
for (i=0;i<m_aDatabaseClass.GetSize();i++)
if
(!IsElementOf(anAddedClassId,m_aDatabaseClass[i].m_nId)){
m_InheritanceGraph.AddNode(
(CClass*)&m_aDatabaseClass[i]);
}//endif
}//endif
// add the non used abstract classes as
roots
(2)
{
for (i=0;i<m_aAbstractClass.GetSize();i++)
if
(!IsElementOf(anAddedClassId,m_aAbstractClass[i].m_nId)){
m_InheritanceGraph.AddNode(
(CClass*)&m_aAbstractClass[i]);
}//endif
}//endif
// add the non used class utilities as
roots
(3)
{
for (i=0;i<m_aClassUtility.GetSize();i++)
if
(!IsElementOf(anAddedClassId,m_aClassUtility[i].m_nId)) {
m_InheritanceGraph.AddNode(
(CClass*)&m_aClassUtility[i]);
}//endif
}//endif
}//end CreateInheritanceHierarchy
204 • Implementation
Diplomarbeit
Listing 7-29: Funktion CreateInheritanceHierarchy (Hinzufügen der verbleibenden Klassen)
6XFKHLQGHU0HQJHDOOHU'DWHQEDQNNODVVHQ
DOOHUDEVWUDNWHU.ODVVHQXQG
DOOHU+LOIVNODVVHQQDFKQRFKQLFKWHLQJHIJWHQ(OHPHQWHQXQG
GHILQLHUHGLHVHDOV:XU]HONQRWHQ
(1)
(2)
(3)
7.4.8 Aufbau des Komponentenbaumes
9RQGHU0HWKRGH'(,026LVWJHIRUGHUWZRUGHQGDVVDOOH
'DWHQEDQNNODVVHQDOVGLUHNWHRGHULQGLUHNWH.RPSRQHQWHQHLQHV
(LQVWLHJVSXQNWHV]XGHILQLHUHQVLQG'LHVH)RUGHUXQJOlVVWVLFK
HEHQIDOOVPLWHLQHP*UDSKHQPRGHOOLHUHQ'HU*UDSKEHVWHKWGDEHL
DXVHLQHPRGHUPHKUHUHQGLVMXQNWHQ.RPSRQHQWHQElXPHQXQG
MHGHUGLHVHU%lXPHKDWHLQHQ(LQVWLHJVSXQNWDOV:XU]HONQRWHQ,Q
%DXPHOHPHQWHN|QQHQ'DWHQEDQNNODVVHQRGHUDEVWUDNWH.ODVVHQ
HQWKDOWHQVHLQ+LOIVNODVVHQGUIHQDXIJUXQGLKUHU7UDQVLHQ]QLFKWDOV
.RPSRQHQWHQPRGHOOLHUWVHLQXQGGUIHQGHVKDOEQLFKWLQGHQ%DXP
DXIJHQRPPHQZHUGHQ
:LHGHUXPLVWZlKUHQGGHV$XIEDXVXQGZlKUHQGGHV$XVOHVHQVGHU
JHQDXH7\SGHV(OHPHQWHVQLFKWYRQ%HGHXWXQJZHVKDOEGLH.QRWHQ
GHV*UDSKHQPLWGHQ,QVWDQ]HQGHU%DVLVNODVVHCClassYHUEXQGHQ
ZHUGHQ
)UGHQ$XIEDXGHU9HUHUEXQJVKLHUDUFKLHPXVVDOVRGLH/LVWHGHU
(LQVWLHJVSXQNWHGHUHQ,QVWDWLLHUXQJVNDQWHQGLH/LVWHGHU
.RPSRQHQWHQSIHLOHVRZLHGLH/LVWHGHU'DWHQEDQNXQGGHU
DEVWUDNWHQ.ODVVHQEHUFNVLFKWLJWZHUGHQ
'DVJHZlKOWH9RUJHKHQQLPPW]XHUVWDOOHGXUFKHLQHQ
(LQVWLHJVSXQNWLQVWDQWLLHUWHQ.ODVVHQDXIXQGIOOWDQVFKOLHVVHQGYRQ
LKQHQDXVJHKHQGUHNXUVLYGHQ%DXPPLWGHQHQWODQJGHU
.RPSRQHQWHQEH]LHKXQJHQUHIHUHQ]LHUWHQ(OHPHQWHQ
(VPXVVVLFKHUJHVWHOOWVHLQGDVVMHGH'DWHQEDQNNODVVHJHQDXHLQPDO
LQHLQHPGHUDUWLJHQ%DXPDXIWULWWXQGGDVVMHGH
.RPSRQHQWHQEH]LHKXQJDQJHWURIIHQZXUGHNHLQH%H]LHKXQJHQ]X
DQGHUHQ.ODVVHQW\SHQ
,P)ROJHQGHQVROOGLH,PSOHPHQWDWLRQGHV$OJRULWKPXV·DEJHELOGHW
XQGPLWYHUVFKLHGHQHQ.RPPHQWDUHQHUOlXWHUWZHUGHQ
6XFKHGLH:XU]HOQGHU.RPSRQHQWHQElXPH
void CSchemaDoc::CreateComponentTree(void) {
int i;
// find the root(s) of the component tree
// set these classes to state visited
CArray<int,int&> anRootId;
CArray<int,int&> anVisitedClass;
int nRootCandidate;
(1)
for
(i=0;i<m_aInstantiationArc.GetSize();i++) {
(2)
nRootCandidate=m_aInstantiationArc[i].m_nT
oNode;
(3)
if
(!IsElementOf(anRootId,nRootCandidate)) {
(4)
anRootId.Add(nRootCandidate);
anVisitedClass.Add(nRootCandidate);
}//endif
}//endfor
Listing 7-30: Funktion CreateComponentTree (Suche nach den Wurzelobjekten)
(1)
(2)
(3)
Diplomarbeit
)UDOOH,QVWDQWLLHUXQJVSIHLOH
ZLUGGLH]XJHK|ULJH.ODVVHJHIXQGHQ
)DOOVGLHVHQRFKQLFKWLQGHU0HQJHGHU:XU]HOQHQWKDOWHQLVW
Implementation • 205
(4) ZLUGHULQGLHVH0HQJHDXIJHQRPPHQ
5HNXULYHV)OOHQGHU.RPSRQHQWHQElXPH
// fill the component tree recursively
CClass* pClass;
HITEM hRoot;
for (i=0;i<anRootId.GetSize();i++) {
pClass=GetClass(anRootId[i]);
ASSERT(pClass);
(1)
(2)
(3)
hRoot=m_ComponentTree.AddNode(pClass);
(4)
AddComponents(pClass,anVisitedClass,anRoot
Id[i],hRoot);
}//endfor
Listing 7-31: Funktion CreateComponentTree (Rekursives Füllen)
)UDOOH:XU]HOQ
ZLUGGLH.ODVVHEHVFKDIIW
GLHVH
XQGGHUHQ.RPSRQHQWHQZHUGHQLQGHQ.RPSRQHQWHQEDXP
HLQJHIJW
+LQ]XIJHQYRQ.RPSRQHQWHQ
(1)
(2)
(3)
(4)
void CSchemaDoc::AddComponents(CClass* pParentClass,
CArray<int,int&>& anVisitedClass,
int nParentId, HITEM hParent) {
CClass* pClass;
HITEM hChild;
int nChildId;
// search in the list of arcs for all
nodes having an arc from current parent
(1)
for (int
i=0;i<m_aComponentArc.GetSize();i++) {
// for each such node found get his
class, add the node to component tree
(2)
if
(m_aComponentArc[i].m_nFromNode==nParentId) {
nChildId=m_aComponentArc[i].m_nToNode;
// get nodes class
pClass=GetClass(nChildId);
ASSERT(pClass);
(3)
// look for duplicate usage of
class
(4)
if
(IsElementOf(anVisitedClass,nChildId))
throw
CFatalError(„defined as a component twice");
anVisitedClass.Add(nChildId);
// add the class to the
component tree if it is not an abstract class
(5)
if (pClass>m_nType==CItem::typeAbstractClass)
throw
CFatalError(„Abstract classes as components");
(6)
hChild=m_ComponentTree.AddNode(pClass,hPar
ent);
(7)
pParentClass>CreateComponentRelation(...);
// and look for his children
(8)
AddComponents(pClass,anVisitedClass,nChild
Id,hChild);
}//endif
}//endfor
}//end AddComponents
Listing 7-32: Funktion AddComponents (Rekursives Füllen)
(1)
(2)
206 • Implementation
6XFKHDXVGHU0HQJHGHU.RPSRQHQWHQEH]LHKXQJHQ
HLQHGLHYRQGHUDNWXHOOHQ.ODVVHDXVOlXIW
Diplomarbeit
%HVFKDIIHGLHUHIHUHQ]LHUWH.ODVVH
)DOOVGLHVHVFKRQLP%DXPHQWKDOWHQLVWOLHJWHLQH9HUOHW]XQJGHU
(LQGHXWLJNHLWYRU
(5) )DOOVHVVLFKXPHLQHDEVWUDNWH.ODVVHKDQGHOWLVWHLQH)RUGHUXQJ
YRQ'(,026YHUOHW]W
(6) 'LH.ODVVHZLUGGHP.RPSRQHQWHQEDXPKLQ]XJHIJW
(7) XQGGLHHQWVSUHFKHQGH.RPSRQHQWHQEH]LHKXQJDXIJHEDXW
(8) )DOOVGLHHEHQHLQJHIJWHZHLWHUH.RPSRQHQWHQEHVLW]WZHUGHQ
GLHVHJOHLFKVDPDXIJHQRPPHQ5HNXUVLRQ
+LQ]XIJHQGHUYHUEOHLEHQGHQ.ODVVHQ
(3)
(4)
//for each database class which is not
used yet
(1)
{
for (i=0;i<m_aDatabaseClass.GetSize();i++)
if
(!IsElementOf(anVisitedClass,m_aDatabaseClass[i].m_nId)){
(2)
throw CFatalError("Class not
defined as a component");
}//endif
}//endfor
(3)
{
// add the abstract classes as roots
for (i=0;i<m_aAbstractClass.GetSize();i++)
m_ComponentTree.AddNode((CClass*)&m_aAbstr
actClass[i]);
}//endif
(4)
{
// add the class utilities as roots
for (i=0;i<m_aClassUtility.GetSize();i++)
m_ComponentTree.AddNode((CClass*)&m_aClass
Utility[i]);
}//endif
}//end CreateComponentTree
Listing 7-33: Funktion CreateComponentTree (restliche Klassen)
(1) 'LH0HQJHGHU'DWHQEDQNNODVVHQZLUGQDFKQLFKWEHVXFKWHQ
(LQWUlJHQGXUFKIRUVFKW
(2) :HUGHQGHUDUWLJH(OHPHQWHJHIXQGHQOLHJWHLQH9HUOHW]XQJGHU
]ZLQJHQGHQ%HGLQJXQJYRQ'(,026YRU
(3) 6lPWOLFKHDEVWUDNWHQ.ODVVHQZHUGHQDOV:XU]HOHOHPHQWH
KLQ]XJHIJW
(4) 6lPWOLFKH+LOIVNODVVHQZHUGHQDOV:XU]HOHOHPHQWHKLQ]XJHIJW
7.4.9 Umsetzen der Kanten in Beziehungen
8PVlPWOLFKH(LJHQVFKDIWHQHLQHU.ODVVHPRGHOOLHUHQ]XN|QQHQ
ZHUGHQGLHQDFKIROJHQGLP'LDJDPPGDUJHVWHOOWHQ.ODVVHQEHQ|WLJW
Diplomarbeit
Implementation • 207
CImplicitAttribute
CImplicitMethod
A CRelation
CEvolutionRel
CInverseRel
CComponentRel
CObserverRel
CKeyAttribute
CClass
A CMethod
A CAttribute
CExplicitAttribute
CVirtualMethod
CExplicitMethod
Klassendiagramm 7-6: Klassen für die Modellierung einer ‘Klasse’
.ODVVHQYRQ26:22'
CClass
0RGHOOLHUXQJHLQHU.ODVVHLP6LQQHGHV'DWHQEDQNHQWZXUIHV
%DVLVNODVVHIUGLH.ODVVHQCDatabaseClassCAbstractClass
XQGCClassUtility
CRelation
$EVWUDNWH%DVLVNODVVHDOOHU5HODWLRQHQ(QWKlOWLQVEHVRQGHUHLPSOLFLWH
$WWULEXWHXQG0HWKRGHIUGHVVHQ8PVHW]XQJ
CComponentRelation
.RPSRQHQWHQEH]LHKXQJ
CInverseRelation
,QYHUVH%H]LHKXQJ
CObserverRelation
%HREDFKWXQJVEH]LHKXQJ
CEvolutionRelation
(YROXWLRQVEH]LHKXQJ
CAttribute
$EVWUDNWH.ODVVHDOOHU$WWULEXWH
CExplicitAttribute
%HQXW]HUGHILQLHUWHQ$WWULEXWH.ODVVHQHLJHQVFKDIWHQ
CImplicitAttribute
9RQ5HODWLRQHQLPSOL]LWJHQHULHUWH$WWULEXWH
CMethod
$EVWUDNWH.ODVVHDOOHU0HWKRGHQ
CExplicitMethod
%HQXW]HUGHILQLHUWH0HWKRGHQ.ODVVHQHLJHQVFKDIWHQ
CImplicitMethod
9RQ5HODWLRQHQLPSOL]LWJHQHULHUWH0HWKRGHQ
CVirtualMethod
9RQ26:22'LPSOL]LWJHQHULHUWH0HWKRGHQZHOFKHGXUFKGLH
9HUHUEXQJYRQGHUUHLQYLUWXHOOHQ.ODVVHDBObjectVWDPPHQ
CKeyAttribute
%HQXW]HUGHILQLHUWH6FKOVVHODWWULEXWH.ODVVHQHLJHQVFKDIWHQXQGYRQ
GHU.RPSRQHQWHQUHODWLRQLPSOL]LWJHQHULHUWH$WWULEXWH
208 • Implementation
Diplomarbeit
,P)ROJHQGHQVROOHQGLH.ODVVHQCClassXQGCRelationJHQDXHU
EHWUDFKWHWZHUGHQ
7.4.9.1 CClass
&&ODVVSXEOLF&,WHP
void CreateComponentRelation(CClass* pClass,
CString strCardinality,
CString strCardinalityInverse)
(U]HXJWHLQH.RPSRQHQWHQEH]LHKXQJ]XGHU.ODVVHpClassPLWGHQ
.DUGLQDOLWlWHQstrCardinalityXQGstrCardinalityInverse
void CreateInverseRelation(CClass* pClass,
CString strCardinality,
CString strCardinalityInverse)
(U]HXJWHLQHLQYHUVH%H]LHKXQJ]XGHU.ODVVHpClassPLWGHQ
.DUGLQDOLWlWHQstrCardinalityXQGstrCardinalityInverse
void CreateObserverRelation(CClass* pClass,
CString strCardinality,
CString strCardinalityInverse)
(U]HXJWHLQH%HREDFKWXQJVEH]LHKXQJ]XGHU.ODVVHpClassPLWGHQ
.DUGLQDOLWlWHQstrCardinalityXQGstrCardinalityInverse
void CreateEvolutionRelation(CClass* pFromClass,
CClass* pToClass,CClass* pParentClass)
(U]HXJWHLQH(YROXWLRQVEH]LHKXQJYRQGHU.ODVVHS)URP&ODVV]XGHU
.ODVVHpToClassPLWGHU.ODVVHpParentClassDOVJHPHLQVDPH
9DWHUNODVVH
void CreateVirtualMethods(void)
(U]HXJWGLHYLUWXHOOHQ0HWKRGHQ
void CreateDefinition(CString strParents)
(U]HXJWGLH.ODVVHQGHILQLWLRQLQ2'/
CArray<CVirtualMethod,CvirtualMethod&> m_aConstructor
6DPPOXQJGHUYLUWXHOOHQ0HWKRGHQGLHDOV.RQVWUXNWRUHQDXIJHIDVVW
ZHUGHQGUIHQ
CArray<CvirtualMethod,CVirtualMethod&>
m_aVirtualMethod
6DPPOXQJGHUUHVWOLFKHQYLUWXHOOHQ0HWKRGHQ
CArray<CcomponentRelation,CComponentRelation&>
m_aComponentRelation
6DPPOXQJGHU.RPSRQHQWHQEH]LHKXQJHQ
CArray<CInverseRelation,CinverseRelation&>
m_aInverseRelation
6DPPOXQJGHULQYHUVHQ%H]LHKXQJHQ
CArray<CObserverRelation,CObserverRelation&>
m_aObserverRelation
6DPPOXQJGHU%HREDFKWXQJVEH]LHKXQJHQ
CArray<CEvolutionRelation,CEvolutionRelation&>
m_aEvolutionRelation
6DPPOXQJGHU(YROXWLRQVEH]LHKXQJHQ
CString m_strDefinition
'HILQLWLRQVVWULQJLQ2'/
Diplomarbeit
Implementation • 209
Klassenbeschreibung 7-11: CClass
class CClass : public CNode {
// typdefs
public:
// construction/destruction
public:
CClass() {};
CClass(const CItem& Item) :
CNode(Item) {};
// operations
public:
CClass& operator=(CClass& Class);
// methods
public:
virtual void Validate(void);
void ParsePropertyEntry(void);
void ParseMethodProperty(CString
strProperty);
void ParseConstraintProperty(CString
strProperty);
void
ParseKeyAttributeProperty(CString strProperty);
void ParseAttributeProperty(const
CString& strProperty);
void CreateComponentRelation(CClass*
pClass,
CString strCardinality,
CString strCardinalityInverse);
void CreateInverseRelation(CClass*
pClass,
CString strCardinality,
CString strCardinalityInverse);
void CreateObserverRelation(CClass*
pClass,
CString strCardinality,
CString strCardinalityInverse);
void CreateEvolutionRelation(CClass*
pFromClass,
CClass* pToClass,CClass* pParentClass);
void CreateVirtualMethods(void);
void CreateDefinition(CString
strParents);
void Show(HTREEITEM
hClassRoot,CTreeCtrl& TreeCtrl,
UINT nMask,CClassView* pClassView);
private:
CString GetLabel(void);
// attributes
public:
// user defined values
CString m_strClassName;
CString m_strProperties;
// user defined members
CArray<CExplicitAttribute,CExplicitAttribu
te&> m_aExplicitAttribute;
CArray<CExplicitMethod,CExplicitMethod&>
m_aExplicitMethod;
// virtual functions inherited from
DBObject
CArray<CVirtualMethod,CVirtualMethod&>
m_aConstructor;
CArray<CVirtualMethod,CVirtualMethod&>
m_aVirtualMethod;
// relations
210 • Implementation
Diplomarbeit
CArray<CComponentRelation,CComponentRelati
on&> m_aComponentRelation;
CArray<CInverseRelation,CInverseRelation&>
m_aInverseRelation;
CArray<CObserverRelation,CObserverRelation
&> m_aObserverRelation;
// evolution
CArray<CEvolutionRelation,CEvolutionRelati
on&> m_aEvolutionRelation;
// key attributes
CArray<CKeyAttribute,CKeyAttribute&>
m_aKeyAttribute;
// constraints
CArray<CString,CString&>
m_astrConstraint;
// class definition string in ODL
CString m_strParents;
CString m_strDefinition;
}; //end class CClass
Listing 7-34: Klassendefinition von CClass
7.4.9.2 CRelation
&5HODWLRQ
void Create(CClass* pFromClass,CClass* pToClass,
const CString& strCardinality,
const CString& strCardinalityInverse)
(U]HXJWHLQH5HODWLRQ]ZLVFKHQGHQ.ODVVHQS)URP&ODVVXQGS7R&ODVV
LQGHPHUVWGLHEHUJHEHQHQ.DUGLQDOLWlWVDQJDEHQPLW+LOIHGHU
)XQNWLRQGetCardinalityBounds()LQ/LPLWHQXPJHVHW]WZHUGHQ
XQGDQVFKOLHVVHQGHLQLPSOL]LWHV$WWULEXWIUGLH9HUZDOWXQJGHU
5HIHUHQ]PHQJHXQGMHQDFK7\SGHU5HODWLRQLPSOL]LWH0HWKRGHQIU
GLH9HUZDOWXQJGHU%H]LHKXQJDQJHOHJWZHUGHQ
void GetCardinalityBounds(const CString&
strCardinality,int& nMinimum,int& nMaximum)
(UPLWWHOWGLHLP.DUGLQDOLWlWVVWULQJGHILQLHUWHPLQLPDOXQGPD[LPDO
HUODXEWH$Q]DKOYRQ%H]LHKXQJHQXQGOLHIHUWGLHVH]XUFNYJOHUODXEWH
.DUGLQDOLWlWVDQJDEHQLP$EVFKQLWW´)HKOHU.HLQJOWLJHV5HVXOWDW
IU7DEHOOHµ6HLWH
CImplicitAttribute m_ReferenceAttribute
,PSOL]LWHV$WWULEXWIUGLH9HUZDOWXQJGHU5HIHUHQ]PHQJH
CArray<CImplicitMethod,CImplicitMethod&>
m_aImplicitMethod
,PSOL]LWH0HWKRGHIUGLH9HUZDOWXQJGHU%H]LHKXQJ
Cclass* m_pFromClass
=HLJHUDXIGLH$XVJDQJVNODVVHGHU%H]LHKXQJ
Cclass* m_pToClass
=HLJHUDXIGLH=LHONODVVHGHU%H]LHKXQJ
Klassenbeschreibung 7-12: CRelation
class CRelation {
// construction/destruction
public:
//CRelation() {};
// operations
public:
Diplomarbeit
Implementation • 211
CRelation& operator=(CRelation&
Relation);
// methods
public:
void Create(CClass*
pFromClass,CClass* pToClass,
const CString& strCardinality,
const CString& strCardinalityInverse);
virtual CString GetLabel(void);
virtual void Show(HTREEITEM
hRoot,CTreeCtrl& TreeCtrl,UINT nMask,CClassView*
pClassView);
private:
void GetCardinalityBounds(const
CString& strCardinality,int& nMinimum,int& nMaximum);
virtual UINT GetImage(void)=0;
// members
public:
CImplicitAttribute
m_ReferenceAttribute;
CArray<CImplicitMethod,CImplicitMethod&>
m_aImplicitMethod;
CClass* m_pFromClass;
CClass* m_pToClass;
};
Listing 7-35: Klassendefinition von CRelation
'HU$XIEDXHLQHU%H]LHKXQJOlXIWIUDOOH%H]LHKXQJVW\SHQ
VHKUlKQOLFKDEZHVKDOELP)ROJHQGHQGHU$EODXIIULQYHUVH
%H]LHKXQJHQVWHOOYHUWUHWHQGIUDOOHZHLWHUHQEHOHXFKWHWVHLQ
VROO
'LH,QVWDQ]GHU.ODVVH&6FKHPD'RFUXIWGLH0HWKRGH
CreateInverseRelations()DXIZHOFKHXQWHQ
DEJHELOGHWLVW
void CSchemaDoc::CreateInverseRelations(void) {
CClass* pFromClass;
CClass* pToClass;
...
(1)
for (int
i=0;i<m_aInverseRelationArc.GetSize();i++) {
pFromClass=GetClass(m_aInverseRelationArc[
i].m_nFromNode);
pToClass=GetClass(m_aInverseRelationArc[i]
.m_nToNode);
(2)
pFromClass>CreateInverseRelation(pToClass,
m_aInverseRelationArc[i].m_strCardinalityInverse,
m_aInverseRelationArc[i].m_strCardinality);
(3)
pToClass>CreateInverseRelation(pFromClass,
m_aInverseRelationArc[i].m_strCardinality,
m_aInverseRelationArc[i].m_strCardinalityInverse);
}//endfor
}//end CreateInverseRelations
Listing 7-36: Methode CreateInverseRelations() in CSchemaDoc
(1) )UDOOHLQYHUVHQ%H]LHKXQJHQZLUGHLQHQWVSUHFKHQGHV
2EMHNWIUGLH
(2) $XVJDQJVXQGGLH
(3) =LHONODVVHHU]HXJW
'LHHQWVSUHFKHQGH,PSOHPHQWLHUXQJLQGHU.ODVVH&&ODVV
VLHKWZLHIROJWDXV
void CClass::CreateInverseRelation(CClass* pToClass,
CString strCardinality,CString strCardinalityInverse) {
(2)
m_aInverseRelation.Add(
(1)
CInverseRelation(this,pToClass,
strCardinality,strCardinalityInverse));
}//end CreateInverseRelation
212 • Implementation
Diplomarbeit
Listing 7-37: Methode CreateInverseRelation() in CClass
(LQQHXHV2EMHNWGHU.ODVVHCInverseRelationZLUG
HU]HXJW
(2) XQGGHU6DPPOXQJDOOHULQYHUVHQ%H]LHKXQJHQ
KL]XJHIJW
'LH(U]HXJXQJHLQHULQYHUVHQ%H]LHKXQJLVWQDFKIROJHQG
GDUJHVWHOOW
(1)
CInverseRelation::CInverseRelation(CClass* pFromClass,
CClass* pToClass,const CString& strCardinality,
const CString& strCardinalityInverse) {
(1)
Create(pFromClass,pToClass,strCardinality,
strCardinalityInverse)
}//end constructor
void CInverseRelation::Create(CClass* pFromClass,CClass*
pToClass,
const CString& strCardinality,
const CString& strCardinalityInverse) {
// first call base classes create function
(2)
CRelation::Create(pFromClass,pToClass,
strCardinality,strCardinalityInverse);
(3)
m_aImplicitMethod.Add(CImplicitMethod(this
,pFromClass,pToClass,
CImplicitMethod::typeAttach));
m_aImplicitMethod.Add(CImplicitMethod(this
,pFromClass,pToClass,
CImplicitMethod::typeDetach));
m_aImplicitMethod.Add(CImplicitMethod(this
,pFromClass,pToClass,
CImplicitMethod::typeAttachInverse));
m_aImplicitMethod.Add(CImplicitMethod(this
,pFromClass,pToClass,
CImplicitMethod::typeDetachInverse));
}//end Create
Listing 7-38: Methode Create() in CInverseRelation
'HUEHUODGHQH.RQVWUXNWRUUXIWOHGLJOLFKGLH
Create()0HWKRGHPLWGHQLKPEHUJHEHQHQ3DUDPHWHUQ
DXI
(2) 'LHCreate()0HWKRGHGHU%DVLVNODVVHZLUG
DXIJHUXIHQ
(3) $QVFKOLHVVHQGZHUGHQGLHLPSOL]LWHQ0HWKRGHQIUGLH
9HUZDOWXQJHLQHULQYHUVHQ%H]LHKXQJXQGLQVEHVRQGHUHGHUHQ
,PSOHPHQWDWLRQVVWULQJVNUHLHUW
'LH,PSOHPHQWLHUXQJGHUCreate()0HWKRGHLQGHU
%DVLVNODVVHVLHKWZLHIROJWDXV
(1)
void CRelation::Create(CClass* pFromClass,CClass* pToClass,
const CString& strCardinality,
const CString& strCardinalityInverse) {
m_pFromClass=pFromClass;
m_pToClass=pToClass;
// implicite attribute settings
int nMinimum;
int nMaximum;
(1)
GetCardinalityBounds(strCardinality,nMinim
um,nMaximum);
// attribute settings
if (nMaximum==1) {
(2)
m_ReferenceAttribute.Create("m_ref"+
pToClass->m_strClassName,
pToClass->m_strClassName,"",
nMinimum,nMaximum);
Diplomarbeit
Implementation • 213
}
else {
(3)
m_ReferenceAttribute.Create("m_setref"+
pToClass->m_strClassName,
"unique set("+pToClass->m_strClassName+")","",
nMinimum,nMaximum);
}//endif
}//end constructor
Listing 7-39: Methode CreateInverseRelation() in CClass
(1) 'HUEHUJHEHQH.DUGLQDOLWlWVVWULQJZLUGDQDO\VLHUW'LH
0LQLPDOXQG0D[LPDODQ]DKOZLUGHUPLWWHOW
(2) )U%H]LHKXQJHQZHOFKHPD[LPDO]XHLQHP2EMHNW
XQWHUKDOWHQZHUGHQN|QQHQZLUGHLQHLQVWHOOLJHV
5HIHUHQ]DWWULEXWHU]HXJW
(3) ZlKUHQGLPDQGHUHQ)DOOHLQPHQJHQZHUWLJHV
5HIHUHQ]DWWULEXWNUHLHUWZLUG
7.4.10 Erzeugung der Klassendefinitionen und
Methodenimplementierungen
6LQGQXQDOOH.DQWHQLQ%H]LHKXQJHQXPJHVHW]WNDQQGLH(U]HXJXQJ
GHU.ODVVHQGHILQLWLRQIUMHGHQ.ODVVHHUIROJHQ'D]XZLUGHUVWGLH
=HLOH
class ClassName [inherit ClassName [(,
ClassName)*]]
HU]HXJWXQGDQVFKOLHVVHQGGLH
• H[SOL]LWHQEHQXW]HUGHILQLHUWHQ$WWULEXWH
• LPSOL]LWHQDXVGHQ%H]LHKXQJHQVWDPPHQGHQ5HIHUHQ]DWWULEXWH
HLQJHIOOW'DQDFKPVVHQGLH'HILQLWLRQHQGHU
• .RQVWUXNWRUHQ
• .RQVLVWHQ]SUIXQJVPHWKRGHQ
• H[SOL]LWHQEHQXW]HUGHILQLHUWHQ0HWKRGHQXQG
• LPSOL]LWHQDXVGHQ%H]LHKXQJHQVWDPPHQGHQ
9HUZDOWXQJVPHWKRGHQ
HLQJHWUDJHQZHUGHQ%HLVSLHOHLQHUGHUDUWLJHQ.ODVVHQGHILQLWLRQYJO
/LVWLQJ
'LH,PSOHPHQWLHUXQJHQGHULPSOL]LWHQ0HWKRGHQZXUGHQEHUHLWVEHL
GHU(U]HXJXQJGHUHQWVSUHFKHQGHQ%H]LHKXQJHQNUHLHUWZHVKDOEKLHU
QXUQRFKGHU$XIEDXGHU
• H[SOL]LWHQ0HWKRGHQXQGGHU
• YLUWXHOOHQ0HWKRGHQ
HUOHGLJWZHUGHQPXVV
7.4.11 Schreiben der ODL-Datei
'DPLWGLHHU]HXJWH2'/'DWHLLQGHUVSlWHUHQ9HUDUEHLWXQJLPPHU
DOVHLQHYRQ26:22'JHQHULHUWH'DWHLHUNDQQWZHUGHQNDQQZLUG
GLHVHU]X%HJLQQGHUIROJHQGH.RSIYRUDQJHVWHOOW
/*//////////////////////////////////////////////////////////
Schema.o2c - schema definition file for O2 environment
has been generated using design tool OSWOOD, Version 1.0
OSWOOD has been deveolped for:
-------------------------------------------------------|
|
|
Erweiterung objektorientierter Methoden
|
|
für den konzeptuellen Datenbankentwurf
|
|
|
|
Diplomarbeit
|
|
|
214 • Implementation
Diplomarbeit
| der Philosophisch-naturwissenschaftlichen Fakultät |
|
der Universität Bern
|
|
|
|
vorgelegt von Benno Burkhardt 1997
|
|
|
-------------------------------------------------------Special Thanks:
Prof. Dr. Oscar Nierstrasz, University of Berne
Prof. Dr. Klaus Dittrich, University of Zurich
Dr. Andreas Gepperd, Unversity of Zurich
Andreas Behm, University of Zurich
Dr. Thomas Wüst, CSS Assurance Coorp., Switzerland
TeTrade AG, Switzerland
//////////////////////////////////////////////////////////*/
Listing 7-40: Kopf einer ODL-Datei
$OVHUVWHQ(LQWUDJZLUGGHU'DWHLGLH'HILQLWLRQGHU(LQVWLHJVSXQNWH
HLQEHVFKULHEHQ
/*////////////////////////////////////////////////////*/
/* persistent entry point definition(s) */
name Macrohard : Company;
Listing 7-41: Definition der Einstiegspunkte in der ODL-Datei
$QVFKOLHVVHQGZHUGHQGHU'DWHLIUMHGHU.ODVVHGLHEHUHLWVHUVWHOOWHQ
'HILQLWLRQHQXQG,PSOHPHQWDWLRQHQDQJHKlQJW'DEHLZLUGGLH
5HLKHQIROJHÅ.ODVVHQGHILQLWLRQ´Å0HWKRGHQLPSOHPHQWDWLRQ´VWHWV
HLQJHKDOWHQ
/*////////////////////////////////////////////////////*/
/* Company database class */
/* Company database class definition */
class Company inherit DBObject
type tuple (
public Name : string,
...
private m_refManager : Manager)
method
public Create(...) : boolean,
...
private AssignManagerToDeveloper(...)
end;
/* Company database class implementation */
method body Create in class Company {
...
};/* end Create */
...
Listing 7-42: Klassendefinition und -implementation in der ODL-Datei
7.5 Umsetzen eines
Transaktionsdiagramms
,QGHU7UDQVDNWLRQVGLDJUDPPGDWHLLVWGHUNRQ]HSWXHOOH(QWZXUIGHU
$SSOLNDWLRQHQ3URJUDPPH)XQNWLRQHQXQG7UDQVDNWLRQHQHQWKDOWHQ
26:22'VROOGLHVH'DWHLLQWHUSUHWLHUHQXPGHP%HQXW]HUDXIGHUHLQHQ
6HLWHGLH$XIUXIKLHUDUFKLHXQGDXIGHUDQGHUHQ6HLWHGLH8PVHW]XQJLQGHU
6FKHPDGHILQLWLRQVVSUDFKH2&DQ]HLJHQ]XN|QQHQ
7.5.1 Die Transaktionsdiagrammdatei als Input
(LQH6FKHPDGLDJUDPPGDWHLOLHJWDOV7H[WGDWHLYRUXQGIROJWGHP
XQWHQVWHKHQGHQ6\QWD[
index
::= (item)+
Diplomarbeit
Implementation • 215
item
::= ident( property
(,property)* ).
property
::= variable = value
ident
::= diagram | card | node |
arc |
node_image | arc_image
variable
::= type | id | card | arcs |
name | 'name (params) return' |
connections | calls |
inverse |'pseudo code' | variable
Syntaxdiagramm 7-4: Syntax einer Schemadiagrammdatei
7.5.1.1 Elemente einer Schemadiagrammdatei
diagram
HQWKlOW,QIRUPDWLRQHQEHUGLH'LDJUDPPGDWHLLP
$OOJHPHLQHQZLUGYRQ26:22'QLFKWYHUZHQGHW
card
HQWKlOWGLH,QIRUPDWLRQEHUGLH'LDJUDPPNDUWHXQGELOGHW
VRGLH9HUELQGXQJ]XU,QGH[GDWHL,QVEHVRQGHUHHQWKlOWGLHVH
6HNWLRQGHQ7\S'LDJUDPPGDWHL,P*HJHQVDW]]XP
6FKHPDGLDJUDPPNDQQHLQ7UDQVDNWLRQVGLDJUDPPDXV
PHKUHUHQ.DUWHQEHVWHKHQZHVKDOEDXFKPHKUHUHGHUDUWLJH
(LQWUlJHGLHEHUGLH9DULDEOHtitleXQWHUVFKLHGHQZHUGHQ
PVVHQLQGHU+DUG\GDWHLHQWKDOWHQVHLQN|QQHQ
node
HQWKlOWGLH,QIRUPDWLRQHQEHUHLQHQ.QRWHQLP'LDJUDPP
1HEHQVHLQHP7\SXQGGHQYRP%HQXW]HU]XJHZLHVHQHQ
$WWULEXWHQZHUGHQDXFKGHVVHQ9HUELQGXQJHQ]XDQGHUHQ
.QRWHQGHILQLHUW(LQH5HIHUHQ]DXIGDV(OHPHQW
node_imageOHJWVHLQH(UVFKHLQXQJVIRUPXQGVHLQHQRUW
IHVW
arc
EHVFKUHLEWHLQHQ9HUELQGHU]ZLVFKHQ]ZHL.QRWHQ'LHVHULVW
JOHLFKVDPW\SLVLHUWXQGHQWKlOW9HUZHLVHDXIGLH.QRWHQGLH
GXUFKLKQYHUEXQGHQZHUGHQ
node_image
GHILQLHUWGDV$XVVHKHQHLQHV.QRWHQV
arc_image
GHILQLHUWGDV$XVVHKHQHLQHV9HUELQGHUV
7.5.2 Ablaufbeschreibung
'HU$QDO\VH3UR]HVVOlXIWLQPHKUHUHQ6WXIHQDE
/HVHQGHU7UDQVDNWLRQVGLDJUDPPGDWHL8PVHW]XQJGHU(OHPHQWH
LQ.QRWHQXQG.DQWHQ
9DOLGLHUXQJHQ
$XIEDXGHU$XIUXIKLHUDUFKLH
$XIEDXGHU6XEV\VWHPKLHUDUFKLH
(U]HXJXQJGHU.ODVVHQGHILQLWLRQHQXQG
0HWKRGHQLPSOHPHQWLHUXQJHQ
6FKUHLEHQGHU2'/'DWHL
7.5.3 Einbettung
216 • Implementation
Diplomarbeit
CTreeView
COSWOOD
App
CTransView
CMultiDoc
Template
CODLView
CTransDoc
CTransFrame
CEditView
CDocument
CMDIChild
Wnd
CWinApp
Klassendiagramm 7-7: Einbettung der Transaktionsdiagrammklassen
.ODVVHQYRQ26:22'
COSWOODApp
$SSOLNDWLRQVNODVVHYRQ26:22'9HUZDOWHWGDV+DXSWIHQVWHUXQG
GLH'RNXPHQWHQW\SHQ(LQ]LJH.ODVVHZHOFKHHLQHJOREDOH,QVWDQ]
EHVLW]W
CTransDoc
YHUZDOWHWGLH,QIRUPDWLRQHQHLQHV7UDQVDNWLRQVGLDJUDPPV
CTransFrame
YHUZDOWHWGDV'RNXPHQWHQIHQVWHU
CTransView
YHUZDOWHWGLH7UDQVDNWLRQVDQVLFKW
CODLView
YHUZDOWHWGLH2'/$QVLFKW
.ODVVHQGHU0)&
CWinApp
$SSOLNDWLRQVNODVVH
CMultiDocTemplate
NDSVHOWHLQHQEHVWLPPWHQ'RNXPHQWHQW\SGHUGXUFKVHLQH
'RNXPHQWHQ5DKPHQXQG$QVLFKWVNODVVHLGHQWLIL]LHUWZLUG
CMDIChildWnd
YHUZDOWHWGDV.LQGIHQVWHULQHLQHU0',$SSOLNDWLRQ
CTreeView
'HULYDWGHUJHQHUHOOHQ$QVLFKWVNODVVH&9LHZIUGLH9HUZDOWXQJYRQ
%DXPDQVLFKWHQ
CEditView
'HULYDWGHUJHQHUHOOHQ$QVLFKWVNODVVH&9LHZIUGLH9HUZDOWXQJYRQ
WH[WXHOOHQ$QVLFKWHQ
CDomument
YHUZDOWHWGLH,QIRUPDWLRQHQHLQHV'RNXPHQWHV
7.5.3.1 CTransDoc
'LH.ODVVHVSHLFKHUWVlPWOLFKH,QIRUPDWLRQHQGLHLQHLQHP
6FKHPDGLDJUDPPHQWKDOWHQVLQGXQGVlPWOLFKH5HVXOWDWHGHU
Diplomarbeit
Implementation • 217
,QWHUSUHWDWLRQ6LHVWHXHUWGHQ$EODXIXQGUHDJLHUWDXI
%HQXW]HUDNWLRQHQ
&7UDQV'RFSXEOLF&'RFXPHQW
void ReadDiagram(CHardyFile& DiagramFile)
/LHVWJHPlVVEHVFKULHEHQHP9RUJHKHQGLH7UDQVDNWLRQVGLDJUDPPGDWHL
YJO´/HVHQHLQHU+DUG\GDWHLµ6HLWH
void ValidatePrimitives(void) const
9DOLGLHUWJHZLVVH.RQGLWLRQHQZHOFKHYRQ'(,026JHIRUGHUWZHUGHQ
YJO´9DOLGLHUXQJHQµ6HLWH
void CreateCallHierarchy(void)
%DXWGLH$XIUXIKLHUDUFKLHDXIYJO´$XIEDXGHU$XIUXIKLHUDUFKLHµ6HLWH
void CreateSubSystemHierarchy(void)
%DXWGLH6XEV\VWHPKLHUDUFKLHDXIYJO´$XIEDXGHU
6XEV\VWHPKLHUDUFKLHµ6HLWH
void CreateImplementation(void)
(UH]XJWGLH,PSOHPHQWDWLRQHQIUGLHHLQ]HOQHQ(OHPHQWHYJO
´(U]HXJXQJGHU,PSOHPHQWLHUXQJHQµ6HLWH
void WriteO2Cfile(CArchive& arFile)
6FKUHLEWGLH2'/'DWHLYJO´6FKUHLEHQGHU2'/'DWHLµ6HLWH
CArray<CItem,CItem&> m_aItem
6DPPOXQJDOOHUQLFKWZHLWHUW\SLVLHUWHQ(OHPHQWH5HSURGXNWLRQ
CMainProgram m_MainProgram
+DXSWSURJUDPPRGHU$SSOLNDWLRQ
CArray<CSubSystem,CSubSystem&> m_aSubSystem
6DPPOXQJGHU6XEV\VWHPH
CArray<CProgram,CProgram&> m_aProgram
6DPPOXQJGHU3URJUDPPH
CArray<CFunction,CFunction&> m_aFunction
6DPPOXQJGHU)XQNWLRQHQ
CArray<CTransaction,CTransaction&> m_aTransaction
6DPPOXQJGHU7UDQVDNWLRQHQ
CArray<CCallArc,CCallArc&> m_aCallArc
6DPPOXQJGHU$XIUXISIHLOH
Klassenbeschreibung 7-13: CTransDoc
class CTransDoc : public CDocument {
// methods
public:
void ReadDiagram(CHardyFile&
DiagramFile);
void WriteO2CFile(CArchive& arFile);
private:
void CreateItemList(CHardyFile&
DiagramFile);
void AddItem(const CItem& Item);
void ValidatePrimitives(void) const;
void CreateCallHierarchy(void);
void CreateCallHierarchy(CProgram*
pItem);
218 • Implementation
Diplomarbeit
int GetCalledItemId(int
nFromItem,int& nId);
CProgram* GetCalledItem(int nId);
void CreateSubSystemHierarchy(void);
int GetCardId(CString
strIdentifier,const CString& strValue);
int GetCardId(int nNodeImageId);
void CreateImplementation(void);
// Attributes
public:
// item list
CArray<CItem,CItem&> m_aItem;
// node lists
CMainProgram m_MainProgram;
CArray<CSubSystem,CSubSystem&>
m_aSubSystem;
CArray<CProgram,CProgram&>
m_aProgram;
CArray<CFunction,CFunction&>
m_aFunction;
CArray<CTransaction,CTransaction&>
m_aTransaction;
// arc lists
CArray<CCallArc,CCallArc&>
m_aCallArc;
}; //end class CTransDoc
Listing 7-43: Klassendefinition von CTransDoc
7.5.4 Lesen der Transaktionsdiagrammdatei
+DUG\ILOH3DUVLQJ
(UVWHOOHQGHU,WHPV
3DUVLQJGHUQDPHSDUDPVUHWXUQ
0HWKRGHQ,PSOHPHQWDWLRQGHUH[SOL]LWHQ0HWKRGHQ
&RQWUDLQWV
$WWULEXWH6FKOVVHO
)U.DQWHQ/HVHQGHU.DUGLQDOLWlWVDQJDEHQ
.ODVVHQGLDJUDPP
A CArc
CItem
CCallArc
CSubsystem
CTransDoc
calls
A CNode
CProgram
calls
calls
method
CMainPrg
CFunction
CTransaction
Klassendiagramm 7-8: die Klassen eines Transaktionsdokumentes
.ODVVHQYRQ26:22'
Diplomarbeit
Implementation • 219
CMainProgram
NDSVHOWHLQ+DXSWSURJUDPP$SSOLNDWLRQ6SHLFKHUWDOV$WWULEXWH
GHQ1DPHQXQGGLH,PSOHPHQWDWLRQhEHUVFKUHLEWZLHDOOH'HULYDWH
YRQCItemGLHValidate0HWKRGH
CSubsystem
NDSVHOWHLQ6XEV\VWHP6SHLFKHUWDOV$WWULEXWHGHQ1DPHQXQGGLH
.DUWHDXIZHOFKHUHVVLFKEHILQGHWhEHUVFKUHLEWZLHDOOH'HULYDWH
YRQCItemGLHValidate0HWKRGH+DWIUGLH5HSUlVHQWDWLRQ
GHU6XEV\VWHPKLHUDUFKLHHLQH6DPPOXQJYRQ=HLJHUQ]XGHQ
3URJUDPPHQGLHLQLKPHQWKDOWHQVLQG'LHVH=HLJHUZHUGHQPLWGHU
0HWKRGHAddCall()DXIJHEDXW
CProgram
UHSUlVHQWLHUW3URJUDPPHXQGLVWJOHLFK]HLWLJGLH%DVLVNODVVHIUGLH
)XQNWLRQHQXQG7UDQVDNWLRQHQ*HQDXHUH%HVFKUHLEXQJVLHKHZHLWHU
XQWHQ
CFunction
UHSUlVHQWLHUWHLQH)XQNWLRQ
CTransaction
HQWVSULFKWGHU.ODVVH&3URJUDPHUZHLWHUWOHGLJOLFKGLHValidate
0HWKRGH
CCallArc
ZLGHUVSLHJHOWHLQHQ$XIUXISIHLOXQGEHVLW]WDOVHLQ]LJHV$WWULEXWGLH
$XIUXIQXPPHU
7.5.4.1 CProgram
&3URJUDPSXEOLF&1RGH
void AddCall(CProgram* pCalledItem,int nNumber)
)JWXQWHU%HUFNVLFKWLJXQJGHU$XIUXIQXPPHUnNumberHLQHQ
$XIUXI]XGHP(OHPHQWpCalledItemGHU6DPPOXQJGHU$XIUXIH
KLQ]X
virtual void CreateImplementation(const CString&
strAppName)
(U]HXJWGLH,PSOHPHQWLHUXQJ
void CreateMethodCalls(void)
(U]HXJWGLH0HWKRGHQDXIUXIH
CString m_strDefinition
6SHLFKHUWLP)DOOHGHU)XQNWLRQGHQ'HILQLWLRQVVWULQJIUGHQ
3URWRW\SHQ
CString m_strObject
*LEWLP)DOOHHLQHU0HWKRGHGLH.ODVVHDQLQZHOFKHUGLH0HWKRGH]X
VXFKHQLVW
CString m_strName
6SHLFKHUWGHQ1DPHQGHV3URJUDPPVGHU)XQNWLRQGHU7UDQVDNWLRQ
RGHUGHU0HWKRGH
CString m_strType
6SHLFKHUWGHQ7\SGHV5FNJDEHZHUWHV
CArray<CString,CString&> m_astrParamName
/LVWHGHU3DUDPHWHUQDPHQ
CArray<CString,CString&> m_astrParamType
/LVWHGHU3DUDPHWHUW\SHQ
220 • Implementation
Diplomarbeit
int m_nNodeImageId
6SHLFKHUWGHQ,GHQWLILNDWRUGHV.QRWHQELOGHVIUGHQ$XIEDXGHU
6XEV\VWHPKLHUDUFKLH
CWordArray m_awCalledItemId
6SHLFKHUWGLH$XIUXIQXPPHUQDXIVWHLJHQGVRUWLHUWGDPLWLQGHU
8PVHW]XQJGHU$XIUXIHGLH5HLKHQIROJHEHLEHKDOWHQZHUGHQNDQQ
CPtrArray m_apCalledItem
6SHLFKHUWGLH=HLJHU]XGHQDXIJHUXIHQHQ(OHPHQWHQ
CArray<CFunction,CFunction&> m_aCalledMethod
6DPPOXQJGHUDXIJHUXIHQHQ0HWKRGHQ
CString m_strImplementation
,PSOHPHQWDWLRQ
Klassenbeschreibung 7-14: CProgram
class CProgram : public CNode {
public:
typedef enum {
typeProgram=3,
typeFunction=4,
typeTransaction=5,
typeMethod=6
} Type;
// construction / destruction
public:
CProgram() {};
CProgram(const CItem& Item) :
CNode(Item) {};
// operations
public:
CProgram& operator=(CProgram&
Program);
// methods
public:
virtual void Validate(void);
void AddCall(CProgram*
pCalledItem,int nNumber);
virtual void
CreateImplementation(const CString& strAppName);
CString GetLabel(void);
virtual int GetImageId();
void CreateMethodCalls(void);
void Show(HTREEITEM hItem,CTreeCtrl&
TreeCtrl,UINT nMask);
// members
public:
CString m_strDefinition;
CString m_strObject;
CString m_strName;
CString m_strType;
CArray<CString,CString&>
m_astrParamName;
CArray<CString,CString&>
m_astrParamType;
int m_nNodeImageId;
Type m_Type;
CString m_strCall;
CWordArray m_awCalledItemId;
CPtrArray m_apCalledItem;
CArray<CFunction,CFunction&>
m_aCalledMethod;
CString m_strImplementation;
}; //end class CProgram
Listing 7-44: Klassendefinition von CProgram
7.5.5 Validierungen
Diplomarbeit
Implementation • 221
1DFKGHPGLH(OHPHQWHDXVGHU+DUG\GDWHLYROOVWlQGLJJHOHVHQ
ZRUGHQVLQGN|QQHQEHUHLWVZHLWHUUHLFKHQGH9DOLGLHUXQJHQGHU
'LDJUDPPLQIRUPDWLRQHQGXUFKJHIKUWZHUGHQ
(VZLUGLQVEHVRQGHUHJHSUIWRE
• JHQDXHLQ+DXSWSURJUDPPLP'LDJUDPPHQWKDOWHQLVWXQGGLHVHV
HLQHQ1DPHQEHVLW]W
• PLQGHVWHQVHLQ3URJUDPPXQG
• PLQGHVWHQVHLQH7UDQVDNWLRQDXIJHUXIHQZLUG
,VWGLHHUVWH%HGLQJXQJQLFKWHUIOOWKDQGHOWHVVLFKXPHLQHQIDWDOHQ
)HKOHUGDGHP$XIUXIEDXPGLH:XU]HOIHKOW'LHZHLWHUHQ7HVWV
SUIHQREGDVJHOHVHQH'LDJUDPPVLQQYROOLVW
:HLWHUH9DOLGLHUXQJHQ(LQGHXWLJNHLW=\NOHQIUHLKHLWHWFZHUGHQ
ODXIHQGZlKUHQGGHUQDFKIROJHQGHQ9HUDUEHLWXQJYRUJHQRPPHQXQG
PVVHQGHPQDFKQLFKWVSH]LHOOLQGLHVHP$EVFKQLWWEHKDQGHOW
ZHUGHQ
7.5.6 Aufbau der Aufrufhierarchie
'DPLW&RGHJHQHULHUWZHGHQNDQQPVVHQGLH,QIRUPDWLRQHQGHU
$XIUXINDQWHQLQHFKWH$XIUXIHXPJHVHW]WZHUGHQ=LHOLVWHVGDVV
MHGHV3URJUDPPXQGMHGH)XQNWLRQHLQH/LVWHYRQDXIJHUXIHQHQ
(OHPHQWHQHUKlOW=XGHPVROOHQGLHYRP%HQXW]HULQGLH9DULDEOH
pseudo codeJHVFKULHEHQHQ0HWKRGHQDXIUXIHGDUJHVWHOOWXQGLQ
&RGHXPJHVHW]WZHUGHQ
)UGHQ$XIEDXGLHVHU$XIUXIKLHUDUFKLHLVWLQGHU.ODVVHCTransDoc
GLHXQWHQVWHKHQGH)XQNWLRQCreateCallHierarchy]XVWlQGLJ
void CTransDoc::CreateCallHierarchy(void) {
int i;
(1)
for (i=0;i<m_aProgram.GetSize();i++) {
(2)
CreateCallHierarchy(&m_aProgram[i]);
(3)
m_aProgram[i].CreateMethodCalls();
}//endfor
for (i=0;i<m_aFunction.GetSize();i++) {
CreateCallHierarchy(&m_aFunction[i]);
m_aFunction[i].CreateMethodCalls();
}//endfor
for (i=0;i<m_aTransaction.GetSize();i++) {
m_aTransaction[i].CreateMethodCalls();
}//endfor
}//end CreateCallHierarchy
Listing 7-45: Methode CreateCallHierarchy() der Klasse CTransDoc
)UDOOH3URJUDPPH)XQNWLRQHQXQG7UDQVDNWLRQHQZLUGHUVW
GLH0HWKRGH]XP$XIEDXGHU$XIUXIHYRQGHPDNWXHOOHQ
(OHPHQWDXVXQGDQVFKOLHVVHQG
(3) GLH0HWKRGH]XP(U]HXJHQGHU0HWKRGHQDXIUXIHGXUFKJHIKUW
'LH$XIUXIHZHUGHQGXUFKGLHIROJHQGH0HWKRGHNUHLHUW
(1)
(2)
void CTransDoc::CreateCallHierarchy(CProgram* pItem) {
int nArcId=-1;
int nCalledItemId=0;
CProgram* pCalledItem;
// create references to called diagram
items
(1)
(2)
>m_nId,nArcId);
while (TRUE) {
nCalledItemId=GetCalledItemId(pItemif (nArcId==-1) break;
(3)
pCalledItem=GetCalledItem(nCalledItemId);
ASSERT(pCalledItem);
(4)
pItem>AddCall(pCalledItem,m_aCallArc[nArcId].m_nNumber);
}//endwhile
}//end CreateCallHierarchy
222 • Implementation
Diplomarbeit
Listing 7-46: Methode CreateCallHierarchy(...) der Klasse CTransDoc
6RODQJHQRFK$XIUXISIHLOHPLWGHPJHJHEHQHQ(OHPHQWDOV
4XHOOHH[LVWLHUHQ
(2) 6XFKHLQGHU6DPPOXQJGHU$XIUXISIHLOHQDFKHLQHUGHUDUWLJHQ
.DQWH
(3) EHVFKDIIHGDVGXUFKGLHVH.DQWHUHIHUHQ]LHUWH(OHPHQWXQG
(4) NUHLHUHHLQHQ$XIUXI]XGLHVHP(OHPHQW
(LQ$XIUXIZLUGIROJHQGHUPDVVHQHU]HXJW
(1)
void CProgram::AddCall(CProgram* pCalledItem,int nNumber) {
// insert the new item in the right
position
(1)
for (int
i=0;i<m_awCalledItemId.GetSize();i++) {
if (nNumber<m_awCalledItemId[i])
break;
}//endfor
(2)
m_awCalledItemId.InsertAt(i,(WORD)nNumber)
;
(3)
(4)
1]==nNumber))
m_apCalledItem.InsertAt(i,pCalledItem);
if ((i>0)&&(m_awCalledItemId[i-
WARNING("Douplicate usage of number
%u.",nNumber);
}//end AddCall
Listing 7-47: Methode AddCall(...) der Klasse CProgram
(1) 'HUQHXH$XIUXIPXVVDQGLHULFKWLJH3RVLWLRQGHU
$XIUXIUHLKHQIROJHGLHLP$WWULEXWawCalledItemIdJHVSHLFKHUW
ZRUGHQLVWHLQJHIJWZHUGHQ'LH$XIUXIQXPPHUZXUGHEHUHLWVEHLP
/HVHQGHV(OHPHQWHVLQGLH9DULDEOHm_nNumberGHU$XIUXINODVVH
JHVFKULHEHQXQGLQGLHVH)XQNWLRQEHUJHEHQ
(2) 'LH$XIUXIQXPPHUXQG
(3) GDVDXIJHUXIHQH(OHPHQWZHUGHQLQGLH6DPPOXQJHQ
DXIJHQRPPHQ
(4) :XUGHHLQH$XIUXIQXPPHUPHKUIDFKYHUZHQGHWZLUGHLQH
HQVSUHFKHQGH:DUQXQJDXVJHJHEHQ
'LH$QJDEHQLQGHQ)HOGHUQ’pseudo code’RGHUcallsZHUGHQ
PLW+LOIHGHUIROJHQGHQ0HWKRGHLQ0HWKRGHQDXIUXIHXPJHVHW]W
void CProgram::CreateMethodCalls(void) {
if (m_strCall=="") return;
CString strCalls=m_strCall;
CString strCall;
int nPos;
BOOL bMore=TRUE;
CFunction Method;
CFunction* pMethod;
CParser Parser;
(1)
while (bMore) {
(2)
if
((nPos=strCalls.Find(char(13)))>=0) {
(3)
strCall=strCalls.Left(nPos);
(4)
strCalls=strCalls.Mid(nPos+3);
bMore=TRUE;
}
else {
(5)
strCall=strCalls;
strCalls="";
bMore=FALSE;
}//endif
(6)
m_aCalledMethod.Add(Method);
pMethod=&m_aCalledMethod[m_aCalledMethod.G
etUpperBound()];
pMethod->m_strDefinition=strCall;
Diplomarbeit
Implementation • 223
(7)
>m_strObject,
pMethod->m_strName,
pMethod->m_strType,
pMethod->m_astrParamName,
pMethod->m_astrParamType);
Parser.ParseCall(strCall,pMethod-
pMethod->m_Type=CProgram::typeMethod;
}//endwhile
}//end CreateMethodCalls
Listing 7-48: Methode CreateMethodCalls(...) der Klasse CProgram
(1)
(2)
XQG
6RODQJHQRFKZHLWHUH=HLOHQYRUKDQGHQVLQG
6XFKHLQGHU$XIUXI]HLFKHQNHWWHQDFKGHPHQGRIOLQH=HLFKHQ
VSHLFKHUHGHQOLQNHQ7HLODOVGHQDNWXHOOHQ$XIUXIXQG
GHQ5HVWLQGHU$XIUXI]HLFKHQNHWWHIUGHQQlFKVWHQ
6FKOHLIHQGXUFKODXI
(5) ,VWNHLQHZHLWHUH=HLOHLQGHU$XIUXI]HLFKHQNHWWHHQWKDOWHQ
VSHLFKHUHGHQ5HVWDOVGHQDNWXHOOHQ$XIUXI
(6) (U]HXJHHLQHQHXHOHHUH0HWKRGHXQG
(7) UXIHPLWGHUHQ$WWULEXWHQGHQ3DUVHUIUGLH$QDO\VHGHV
0HWKRGHQDXIUXIHVDXI
(3)
(4)
7.5.7 Aufbau der Subsystemhierarchie
'LHLQHLQHU$SSOLNDWLRQHQWKDOWHQHQ3URJUDPPHVLQGEOLFKHUZHLVH
LQYHUVFKLHGHQHQ6XEV\VWHPHQVWUXNWXULHUW'LHVH+LHUDUFKLHZHOFKH
LQ+DUG\PLWPHKUHUHQ.DUWHQGDUJHVWHOOWLVWDEHUGHQQRFKPLW
GHUVHOEHQ+DUG\GDWHLDXVNRPPWPXVVLQGLHVHP6FKULWWQXQHUNDQQW
XQGLQHLQHVLQQYROOH'DWHQVWUXNWXUEHUWUDJHQZHUGHQ
'LHVZLUGPLWGHU0HWKRGHCreateSubSystemHierarchyLQGHU
.ODVVHCTransDocHUOHGLJW
void CTransDoc::CreateSubSystemHierarchy(void) {
// for each subsystem look for expansion
card
int i;
(1)
for (i=0;i<m_aSubSystem.GetSize();i++) {
m_aSubSystem[i].m_nCardId=GetCardId("title
",
m_aSubSystem[i].m_strName);
}//endfor
// assign each program to appropriate
subsystem
(2)
(3)
int nCardId;
for (i=0;i<m_aProgram.GetSize();i++) {
nCardId=GetCardId(m_aProgram[i].m_nNodeIma
geId);
if (!nCardId) continue;
for (int
j=0;j<m_aSubSystem.GetSize();j++) {
(4)
if
(m_aSubSystem[j].m_nCardId==nCardId) break;
}//endfor
if (i==m_aSubSystem.GetSize())
continue;
(5)
m_aSubSystem[j].AddCall(&m_aProgram[i]);
}//endfor
}//end CreateSubSystemHierarchy
Listing 7-49: Methode CreateSubSystemHierarchy(...) der Klasse CTransDoc
(1) )UMHGHVEHUHLWVHUNDQQWHXQGJHOHVHQH6XEV\VWHPZLUGGLHMHQLJH
.DUWHEHVWLPPWGLHVHLQHU([SDQVLRQHQWVSULFKW
(2) )UMHGHV3URJUDPP
(3) ZLUGGHU,GHQWLILNDWRUGHUMHQLJHQ.DUWHJHKROWDXIZHOFKHUGDV
3URJUDPPJH]HLFKQHWZRUGHQLVW'LHVH,QIRUPDWLRQLVWQLFKWGLUHNW
224 • Implementation
Diplomarbeit
LQGHQ(LQWUlJHQGHV.QRWHQVHQWKDOWHQZHVKDOEGHU8PZHJEHU
GHQ(LQWUDJGHVHQWVSUHFKHQGHQ'DUVWHOOXQJVNQRWHQVnode_image
JHQRPPHQZHUGHQPXVV
(4) $QVFKOLHVVHQGZLUGDXVGHU6DPPOXQJGHU6XEV\VWHPHGDVMHQLJH
JHVXFKWZHOFKHVGLH.DUWHGHV3URJUDPPHVDOV([SDQVLRQEHVLW]W
(5) 'XUFKGLH,QVWDOODWLRQHLQHVNQVWOLFKHQ$XIUXIHV]ZLVFKHQ
GLHVHQEHLGHQ(OHPHQWHQNDQQGHU(IIHNWHU]LHOWZHUGHQGDVVGLH
3URJUDPPHHLQHV6XEV\VWHPHVGLHVHPLQGHUEDXPDUWLJHQ
'DUVWHOOXQJXQWHUVWHOOWVLQG
7.5.8 Erzeugung der Implementierungen
)UMHGHV(OHPHQWGHU6DPPOXQJHQGHU3URJUDPPH)XQNWLRQHQXQG
7UDQVDNWLRQHQZLUGGLH0HWKRGHCreateImplementation()
DXIJHUXIHQ'HU&RGHIUGLH'HILQLWLRQHLQHU$SSOLNDWLRQPXVVGLH
3URWRW\SHQGHU3URJUDPPHXQG7UDQVDNWLRQHQHQWKDOWHQZHVKDOE
LKUHU0HWKRGHGLHHQWVSUHFKHQGHQ6DPPOXQJHQEHUJHEHQZHUGHQ
PVVHQ
void CTransDoc::CreateImplementation(void) {
int i;
for (i=0;i<m_aProgram.GetSize();i++) {
m_aProgram[i].CreateImplementation(...);
}//endfor
for (i=0;i<m_aFunction.GetSize();i++) {
m_aFunction[i].CreateImplementation(...);
}//endfor
for (i=0;i<m_aTransaction.GetSize();i++) {
m_aTransaction[i].CreateImplementation(...
);
}//endfor
m_MainProgram.CreateImplementation(m_aProg
ram,m_aTransaction);
}//end CreateImplementation
Listing 7-50: Methode CreateImplementation(...) der Klasse CTransDoc
7.5.9 Schreiben der ODL-Datei
'LH2'/'DWHLZLUGDQDORJ]XP6FKUHLEHQGHU2'/'DWHLIUGDV
6FKHPDGLDJUDPPHLQ.RSIIUGLHVSlWHUH(UNHQQXQJYRUDQJHVWHOOW
YJO/LVWLQJ6HLWH
,P$QVFKOXVVDQGLH.RSILQIRUPDWLRQZLUGGLH6HNWLRQPLWGHU
'HILQLWLRQGHU$SSOLNDWLRQLQGLH'DWHLJHVFKULHEHQ
/*////////////////////////////////////////////////////*/
/* FIS application definition */
application FIS
program
/* programs */
public HireDeveloper,
...
public AssignEmplToOff,
/* transactions */
public FireDev(refDev:Dev) : boolean,
...
public DeleteOffice() : boolean
end;
Listing 7-51: Applikationsdefinition in der ODL-Datei
$QVFKOLHVVHQGZHUGHQVlPWOLFKH3URJUDPPH)XQNWLRQHQXQG
7UDQVDNWLRQHQGHU'DWHLDQJHKlQJW
/*////////////////////////////////////////////////////*/
/* HireDeveloper program implementation */
Diplomarbeit
Implementation • 225
program body HireDeveloper in application FIS {
...
} /* end HireDeveloper */
...
/*////////////////////////////////////////////////////*/
/* SelectDev function implementation */
/* function prototype */
function SelectDev(strName:String,nNumber:Integer) : Dev;
/* function implementation */
function body SelectDev {
...
} /* end SelectDev */
...
/*////////////////////////////////////////////////////*/
/* FireDev transaction implementation */
transaction body FireDev in application FIS {
...
} /* end FireDev */
...
Listing 7-52: Programme, Funktionen und Transaktionen in der ODL-Datei
7.6 Bewertung der Implementation
'LH:DKOGHU(QWZLFNOXQJVXPJHEXQJ0LFURVRIW9LVXDO&HUZLHVVLFKLP
1DFKKLQHLQDOVVHKUJOFNOLFK'XUFKGLH9HUZHQGXQJGHUUHLFKKDOWLJHQ
%LEOLRWKHNGHU0)&NRQQWHQYHUVFKLHGHQH1HEHQSUREOHPHJHO|VWZHUGHQ
)UGLH3URJUDPPLHUXQJGHU9LVXDOLVLHUXQJGHU%HQXW]HUDNWLRQHQRGHUNXU]
GHV*8,PXVVWHQLFKWDOO]XYLHO=HLWDXIJHZHQGHW6RPLWEOLHEYLHO=HLWVLFK
DXIGDV.HUQSUREOHPNRQ]HQWULHUHQ]XN|QQHQ
'DUEHUKLQDXVNRQQWHGXUFKGLH9HUZHQGXQJGHU7HPSODWHVIU
.ROOHNWLRQHQGHU0)&GHUJDQ]H&RGHRKQHHLQHHLQ]LJH new$QZHLVXQJ
XQGRKQHHLQHQHLQ]LJHQH[OL]LWHQ$XIUXIHLQHV'HVWUXNWRUVUHDOLVLHUWZHUGHQ
'DVÅ0LFURVRIW'HYHORSHU6WXGLR´XQWHUVWW]WHGDEHLGLH$UEHLWGXUFKVHLQH
LQWHJULHUWHQ%URZVHUGLHDXFKPLWXQNRPSLOLHUWHP&RGHDUEHLWHQN|QQHQ
VHLQHPLQWHJULHUWHQ'HEXJJHUGHUGXUFKVHLQHÅ'HEXJRQHUURU´)lKLJNHLW
GLH)HKOHUVXFKHHUKHEOLFKHUOHLFKWHUWVHLQHQÅ$SSOLFDWLRQÅE]ZÅ&ODVV
:L]DUG´GDV(UVWHOOHQXQG9HUZDOWHQYRQ$SSOLNDWLRQHQE]Z.ODVVHQ
VLFKHUPDFKWXQGGXUFKVHLQHQÅ0HPRU\/HDN'HWHFWRU´GLH
%HWULHEVVLFKHUKHLWJDUDQWLHUW
'XUFKGHQ(LQVDW]GLHVHUNRPIRUWDEOHQ:HUN]HXJHPLWLKUHQ
DXVJH]HLFKQHWHQ0|JOLFKNHLWHQNRQQWHLQVHKUNXU]HU=HLWHLQHPlFKWLJHXQG
EHQXW]HUIUHXQGOLFKH$QZHQGXQJJHVFKDIIHQZHUGHQ
7.6.1 Bekannte Probleme in OSWOOD
1DFKIROJHQGVROOHQGLHEHUHLWVEHNDQQWHQ3UREOHPHDXIJHIKUW
ZHUGHQ1RFKVLQGDEHUPLWGHP:HUN]HXJNHLQHZHLWHUIKUHQGHQ
)HOGWHVWVGXUFKJHIKUWZRUGHQ0DQNDQQDOVRGDYRQDXVJHKHQGDV
VLFK]XGLHVHU/LVWHQRFKZHLWHUHJHVHOOHQZHUGHQ
'LH3UREOHPHZHOFKHGLHPHWKRGLVFKHQRGHUNRQ]HSWXHOOHQ$VSHNWH
GHV(QWZXUIHVEHWUHIIHQVLQGEHUHLWVDQDQGHUHU6WHOOHGLVNXWLHUW
226 • Implementation
Diplomarbeit
ZRUGHQXQGZHUGHQDXVGLHVHP*UXQGQLFKWLQGLH/LVWH
DXIJHQRPPHQ
7\SHQ
(VZHUGHQQLFKWDOOHLQ2EHNDQQWHQ7\SHQXQWHUVWW]W'HILQLHUW
PDQ]%setrefName : unique set(Name)DOV3DUDPHWHU
RGHU$WWULEXWLP6FKHPDGLDJUDPPZLUGunique set(Name)DOV
.ODVVHQQDPHXQGQLFKWDOV0HQJHQW\SLQWHUSUHWLHUW
$XIUXIHYRQ0HWKRGHQGHU%DVLVNODVVH
(UEWHLQH.ODVVH%YRQHLQHU.ODVVH$VRZLUGEHLVSLHOVZHLVHEHLP
$XIUXIGHU0HWKRGHinit()LQGHU.ODVVH%GLHHQWVSUHFKHQGH
init0HWKRGHGHU9DWHUNODVVHQLFKWDXWRPDWLVFKDXIJHUXIHQ
'LHVHOEH6LWXDWLRQWULIIWPDQEHLGHULPSOL]LWHQAssign0HWKRGHGHU
2EMHNWHYROXWLRQ
9HUELQGXQJ]ZLVFKHQGHP6FKHPDXQGGHP7UDQVDNWLRQVGLDJUDPP
,QGHQ3URJUDPPHQ)XQNWLRQHQRGHU7UDQVDNWLRQHQIRUPXOLHUWH
0HWKRGHQDXIUXIHZHUGHQQLFKWPLWGHQHQWVSUHFKHQGHQ'HILQLWLRQHQ
LP.ODVVHQVFKHPDDEJHJOLFKHQ'LHEHLGHQ'LDJUDPPW\SHQVLQGDOVR
Y|OOLJXQJHEXQGHQ(VZlUHGDEHLGXUFKDXVVLQQYROOGDV:HUN]HXJ
VR]XHUZHLWHUQGDVVGLH'LDJUDPPHZHOFKHHLJHQWOLFKJHPHLQVDP
GDV6FKHPDGHILQLHUHQLQHLQH$QVLFKW]XVDPPHQJHIDVVWVLQG'DPLW
ZlUHQEHLVSLHOVZHLVHGLH0HWKRGHQLPSOHPHQWLHUXQJHQLQGHU
7UDQVDNWLRQVDQVLFKWLQWHJULHUWXQGHUZHLWHUWH%URZVLQJ)XQNWLRQHQ
P|JOLFK
(LQGHXWLJNHLWGHU1DPHQ
26:22'SUIWGLH(LQGHXWLJNHLWGHU1DPHQQLFKW6RPLWNDQQ
PDQ]XPHLQHQ]ZHLLGHQWLVFKH.ODVVHQQDPHQLPVHOEHQ'LDJUDPP
YHUZHQGHQZHOFKHYRQ26:22'ZLH]ZHLYHUVFKLHGHQH.ODVVHQ
EHKDQGHOWZHUGHQ=XPDQGHUHQZHUGHQ]ZHLJOHLFKQDPLJH.ODVVHQ
GLHLQXQWHUVFKLHGOLFKHQ'LDJUDPPHQGHILQLHUWVLQGYRQ26:22'
QLFKW]XVDPPHQJHIDVVW
$Q]HLJHGHU2&'DWHLHQ
2&'DWHLHQGLHJU|VVHUDOV.%VLQGN|QQHQQLFKWYROOVWlQGLJ
DQJH]HLJWZHUGHQ(VZHUGHQOHGLJOLFKGLHHUVWHQ.%LQGHQ
%LOGVFKLUPSXIIHUJHVFKULHEHQ
5HLKHQIROJHGHU.ODVVHQGHILQLWLRQHQ
'LH.ODVVHQGHILQLWLRQHQZHUGHQLQGHU5HLKHQIROJHLQGLH2&'DWHL
JHVFKULHEHQLQGHUVLHLP.RPSRQHQWHQEDXPDXIWUHWHQYJO´'HU
.RPSRQHQWHQEDXPµ6HLWH'DUXPNDQQHVYRUNRPPHQGDVV
6XENODVVHQYRQ9DWHUNODVVHQHUEHQLQVEHVRQGHUHEHLDEVWUDNWHQ
.ODVVHQGLHJDQ]]XP6FKOXVVLQGHQ.RPSRQHQWHQEDXPHLQJHIJW
ZRUGHQVLQGGLHHUVWVSlWHULP&RGHGHILQLHUWVLQG
3HUVLVWHQWH(LQVWLHJVSXQNWH
'LH1DPHQGHUSHUVLVWHQWHQ(LQVWLHJVSXQNWHVROOHQHUVWGHILQLHUW
ZHUGHQZHQQGLHGD]XJHK|ULJH.ODVVHEHUHLWVEHNDQQWLVW
9HUWHLOXQJGHV&RGHVDXI'DWHLHQ
26:22'VFKUHLEWDOOH'HILQLWLRQHQGHV6FKHPDGLDJUDPPVLQHLQH
'DWHLXQGGLHMHQLJHQGHV7UDQVDNWLRQVGLDJUDPPVLQHLQHDQGHUH
'DWHL:UGHPDQGLHVWULNWH7UHQQXQJGHUEHLGHQ$QVLFKWHQ
DXIKHEHQN|QQWHHLQHLQWXLWLYHUH$XIWHLOXQJLPSOHPHQWLHUWZHUGHQ
0DQZUGHEHLVSLHOVZHLVHMHHLQH'DWHLIUGLH.ODVVHQXQG
Diplomarbeit
Implementation • 227
$SSOLNDWLRQHQIUGLH1DPHQIUGLH0HWKRGHQLPSOHPHQWLHUXQJHQ
XQGIUGLH7UDQVDNWLRQVLPSOHPHQWLHUXQJHQHUVWHOOHQ
7.6.2 Mögliche Erweiterungen
)DOOV26:22'LQGHU3UD[LV]%LP%HUHLFKGHU(UVWHOOXQJ
ZLVVHQVFKDIWOLFKHU'DWHQEDQNDQZHQGXQJHQHLQJHVHW]WZLUGZHUGHQ
DOOHU:DKUVFKHLQOLFKNHLWQDFKVRZRKOYRQGHQ(QWZHUIHUQDOVDXFK
YRQGHQ(QWZLFNOHUQHLQH5HLKHYRQ:QVFKHQIUGLH
:HLWHUHQWZLFNOXQJJHlXVVHUWZHUGHQ'LHVHZHUGHQDOOHU9RUDXVVLFKW
QDFKHWZDLQGHQLQGHUQDFKIROJHQGHQ/LVWHDXIJH]lKOWHQ%HUHLFKHQ
OLHJHQ
$XIKHEXQJGHU7UHQQXQJGHU'LDJUDPPH
,QGHU=HLFKQXQJVXPJHEXQJZHUGHQHLQH5HLKH'LDJUDPPH
JH]HLFKQHWZHOFKHDEHULQ26:22'QLFKWPHKUJHWUHQQWEHWUDFKWHW
ZHUGHQVROOHQ
,QWHJUDWLRQGHUUHVWOLFKHQ'LDJUDPPW\SHQ
+HXWHN|QQHQ6FKHPDGLDJUDPPHXQG7UDQVDNWLRQVGLDJUDPPH
JH]HLFKQHWXQGLQ26:22'LQWHUSUHWLHUWZHUGHQ'(,026HQWKlOW
DEHUDXFKGLHUHVWOLFKHQ'LDJUDPPW\SHQZLH
=XVWDQGVEHUJDQJVGLDJUDPPHHWF'LHVHVROOWHQDXFKYRQ
26:22'LQGLH'HILQLWLRQGHV6FKHPDVHLQEH]RJHQZHUGHQ
=XVDPPHQIDVVXQJYRQ+DUG\XQG26:22'
=XP=HLFKQHQYRQ'LDJUDPPHQXQG]XP*HQHULHUHQYRQ&RGH
VLQG]ZHLXQWHUVFKLHGOLFKH3URJUDPPH]XYHUZHQGHQ=ZDUNDQQ
YRQ26:22'LQGHQ=HLFKHQPRGXVYHU]ZHLJWZHUGHQGLHGRUW
JHWlWLJWHQbQGHUXQJHQKLQJHJHQZHUGHQQLFKWDXWRPDWLVFKLQ
26:22'VLFKWEDU'HU(QWZHUIHUZQVFKWVLFKMHGRFKHLQHHLQ]LJH
$QZHGQXQJGLHDOOHVHLQH:QVFKHDEGHFNW
bQGHUXQJHQLQ26:22'
,Q26:22'NDQQQXUJHOHVHQZHUGHQ26:22']HLJWDOVRQXU
HLQHDQGHUH$QVLFKWGHU'DWHQDQ:QVFKHQVZHUWZlUHGLH
0|JOLFKNHLWGHU(GLWLHUXQJYRQ.ODVVHQVWUXNWXUHQ
0HWKRGHQVLJQDWXUHQRGHU,PSOPHQWLHUXQJHQ'LHVHbQGHUXQJHQ
VROOWHQDQVFKOLHVVHQGLQGLH=HLFKQXQJHQYRQ+DUG\]XUFNJHIKUW
ZHUGHQ
=XVDPPHQIKUHQGHU3ODWWIRUPHQ
26:22'LVWDXVVFKOLHVVOLFKIUGLH%HWULHEVV\VWHPH:LQGRZV
E]Z:LQGRZV17YHUIJEDU8PGLH6FKHPDGHILQLWLRQHQLQGDV
'DWHQEDQNV\VWHPHLQIJHQ]XN|QQHQPXVVDOVRGLH3ODWWIRUP
JHZHFKVHOWZHUGHQ$XVGLHVHP*UXQGZlUHHLQH3RUWLHUXQJYRQ
26:22'DXIGLHIU2YHUIJEDUHQ3ODWWIRUPHQGXUFKDXV
VLQQYROO
Å5HYHUVH(QJLQHHULQJ´XQG6FKHPDHYROXWLRQ
%HILQGHQVLFKGLHEHLGHQ6\VWHPH26:22'XQG2DXIGHQVHOEHQ
3ODWWIRUPHQN|QQWHQDXFK)XQNWLRQHQIUGDV5FNIKUHQYRQ
EHVWHKHQGHQ6FKHPDWDLQGLH(QWZXUIVXPJHEXQJÅ5HYHUVH
(QJLQHHULQJ´XQGIUGLH6FKHPDHYROXWLRQUHDOLVLHUWZHUGHQ'DPLW
ZlUH26:22'VRQDKHDQV'DWHQEDQNV\VWHPDQJHOHKQWGDVVHV
HLJHQWOLFKLQGLHJUDILVFKH%HQXW]HUREHUIOlFKHGHV27RROVLQWHJULHUW
ZHUGHQVROOWH
7.6.3 Fazit
228 • Implementation
Diplomarbeit
26:22'LVWLQVHLQHUKHXWLJHQ,PSOHPHQWLHUXQJHLQJXWHV
:HUN]HXJIUGLH(UVWHOOXQJYRQ6FKHPDJHUVWHQIUGLH(QWZLFNOHU
'LHYHUVFKLHGHQHQ6FKZDFKVWHOOHQXQG(UZHLWHUXQJHQPVVHQDEHU
JHJHEHQHQIDOOVEHVHLWLJWE]ZHLQJHEDXWZHUGHQGDPLW26:22'
HLQHJHZLVVH$N]HSWDQ]DOV+LOIVPLWWHOIUGLH(UVWHOOXQJYRQ
SUD[LVUHOHYDQWHQ'DWHQEDQNDQZHQGXQJHQHUKDOWHQNDQQ
Diplomarbeit
Implementation • 229
ANHÄNGE
Unified Modeling
Language (UML)
Einleitung
:HLOGLH9HUHLQKHLWOLFKXQJVDQVWUHQJXQJHQYRQ%RRFK-DFREVHQXQG
5XPEDXJKZlKUHQGGHU$XVDUEHLWXQJGHUYRUOLHJHQGHQ'LSORPDUEHLW
LQGHU9HUVLRQGHV3DSLHUV´8QLILHG0RGHOLQJ/DQJXDJH80/´
JLSIHOWHQXQGZHLOGLHVHQHXHQ0HWKRGHJXWH&KDQFHQKDW]XU
6WDQGDUGPHWKRGHIUGHQREMHNWRULHQWLHUWHQ(QWZXUI]XDYDQFLHUHQ
VROOLKUGLHVHU$QKDQJJHZLGPHWVHLQ
=XHUVWVROOHQHLQLJHZLFKWLJH(FNGDWHQLQGHU*HVFKLFKWHGHU80/
JHQDQQWZHUGHQ$QVFKOLHVVHQGVROONXU]EHVFKULHEHQZHUGHQZDV
GLH80/LVWXQGLQZLHIHUQVLHVLFKYRQGHUEHWUDFKWHWHQ0HWKRGH
YRQ%RRFKXQWHUVFKHLGHW=XP6FKOXVVVROOXQWHUVXFKWZHUGHQZLH
GLH6FKZDFKVWHOOHQDXVJHVHKHQKlWWHQZlUHPDQYRQ80/
DXVJHJDQJHQXQGZLH'(,026DQJHSDVVWZHUGHQPVVWHGDPLWHLQH
.RQVLVWHQ]]XU80/HUUHLFKWZHUGHQN|QQWH
'HP$QKDQJOLHJWYRUDOOHPGLH%HVFKUHLEXQJGHU80/LQ>%RRFK
[email protected]]X*UXQGH'DELV]XP(QGHGLHVHU$UEHLWNHLQHGHXWVFKHQ
hEHUVHW]XQJHQYRUOLHJHQXQGDXFKZHLWHUHGHXWVFKH3XEOLNDWLRQHQ
IHKOHQ>[email protected]>%[email protected]
HQWVSUHFKHQGDXIGLHhEHUVHW]XQJGHUQHXHLQJHIKUWHQ%HJULIIH
YHU]LFKWHWXQGDQGHUHQ6WHOOHGLHHQJOLVFKHQ2ULJLQDOHYHUZHQGHW
Geschichte von UML
%HYRUGLH(QWZLFNOXQJGHUYHUHLQKHLWOLFKWHQ0HWKRGH80/EHJDQQ
ZDUHQLP%HUHLFKGHUREMHNWRULHQWLHUWHQ$QDO\VHXQG
(QWZXUIVPHWKRGHQKDXSWVlFKOLFKGUHL$XWRUHQIHGHUIKUHQG*UDG\
%RRFK>%[email protected]>[email protected]
XQG-DFREVHQPLW226(>[email protected]$OOHGLHVH0HWKRGHQVLQG
NRPSOHWWDEHUDXFKEHNDQQWGDIUGDVVVLHHLQHJHZLVVH6WUHQJH
EHVLW]HQ
%RRFK·V0HWKRGH]HLFKQHWVLFKGDGXUFKDXVGDVVVLHVSH]LHOO
DXVGUXFNVVWDUNZlKUHQGGHP(QWZXUIXQGGHQ.RQVWUXNWLRQVSKDVHQ
LQ3URMHNWHQPLWJURVVHP(QJLQHHULQJ$XIZDQGVLQGZlKUHQGVLFK
207VSH]LHOOIUGLH$QDO\VHYRQGDWHQLQWHQVLYHQ
,QIRUPDWLRQVV\VWHPHQHLJQHW226(KLQJHJHQLVWHLQ
DQZHQGXQJVIDOORULHQWLHUWHU$QVDW]XVHFDVHXQGXQWHUVWW]WGDKHU
H[]HOOHQWGLH0RGHOOLHUXQJGHU*HVFKlIWVSUR]HVVHÅ%XVLQHVV
(QJLQHHULQJ´XQGGLH$QIRUGHUXQJVDQDO\VHÅ5HTXLUHPHQW
$QDO\VLV´
Booch, Rumbaugh und Jacobsen vereinen ihre Kräfte
'LH(QWZLFNOXQJGHU80/EHJDQQDOV%RRFKXQG5XPEDXJK
GLH9HUHLQKHLWOLFKXQJLKUHU0HWKRGHQGLHXQDEKlQJLJYRQHLQDQGHU
EHUHLWV]XVDPPHQJHZDFKVHQZDUHQLQ$QJULIIQDKPHQ'DUDXV
UHVXOWLHUWHGLH9HUVLRQGHU8QLILHG0HWKRG80ZHOFKHLQ
>%[email protected]=XGLHVHP=HLWSXQNWVWLHVV
-DFREVHQ]XGHU*UXSSHKLQ]XXPGLH$VSHNWHVHLQHU0HWKRGH
Diplomarbeit
Unified Modeling Language (UML) • 233
226(LQHLQHQRFKJU|VVHUH9HUHLQKHLWOLFKXQJHLQEULQJHQ]X
N|QQHQ
'DVQXQGUHLN|SILJH*HVSDQQZXUGHLQLKUHU$UEHLWGXUFKGUHL
$VSHNWHPRWLYLHUW
'LHYHUVFKLHGHQHQ0HWKRGHQKDEHQVLFKRKQHKLQXQDEKlQJLJ]X
HLQDQGHUHQWZLFNHOW6LHHUDFKWHWHQHVGHVKDOEDOVVLQQYROOGLH
(QWZLFNOXQJJHPHLQVDPIRUW]XVHW]HQGDPLWGLH%HQXW]HUQLFKW
ZHLWHUGXUFKXQQ|WLJHXQGXQJHZROOWH'LIIHUHQ]HQYHUZLUUWZHUGHQ
'XUFKGLH9HUHLQLJXQJGHU6HPDQWLNGHU1RWDWLRQHQNDQQHLQH
6WDELOLWlWLP0DUNWGHUREMHNWRULHQWLHUWHQ0HWKRGHQHUUHLFKWZHUGHQ
'DPLWN|QQHQHLQHUVHLWVGLH6\VWHPHQWZLFNOXQJHQDXIHLQHU
+DXSWPHWKRGHEDVLHUHQXQGDQGHUHUVHLWVN|QQHQVLFKGLH
:HUN]HXJKHUVWHOOHUDXIGLH8QWHUVWW]XQJHLQHUHLQKHLWOLFKHQ
0HWKRGHNRQ]HQWULHUHQ
6LHHUKRIIWHQGXUFKLKUH=XVDPPHQDUEHLWGLHMHQLJHQ3UREOHPH
O|VHQ]XN|QQHQGLHNHLQHGHUGUHL0HWKRGHQLQGHU9HUJDQJHQKHLW
ULFKWLJEHZlOWLJHQNRQQWH
:lKUHQGGHU(QWZLFNOXQJVROOWHGDUEHUKLQDXVDXIYHUVFKLHGHQH
=LHOHKLQJHDUEHLWHWZHUGHQ
0RGHOOLHUXQJYRQ6\VWHPHQQLFKWQXUYRQ6RIWZDUHXQWHUGHU
9HUZHQGXQJYRQREMHNWRULHQWLHUWHQ.RQ]HSWHQ
(UUHLFKXQJHLQHUH[SOL]LWHQ.RSSHOXQJVRZRKOGHUNRQ]HSWXHOOHQ
DOVDXFKGHUDXVIKUEDUHQ$UWHIDNWHQ
(U]HXJXQJHLQHU0RGHOOLHUXQJVVSUDFKHVRZRKOIUGHQ0HQVFKHQ
DOVDXFKIUGLH0DVFKLQH
'LH(UDUEHLWXQJHLQHU0HWKRGHIUGLHREMHNWRULHQWLHUWH$QDO\VHXQG
GHQREMHNWRULHQWLHUWHQ(QWZXUILVWQLFKWPLWGHP(QWZXUIHLQHU
3URJUDPPLHUVSUDFKHYHUJOHLFKEDU(UVWHQVPXVVGDV3UREOHP
HLQJHJUHQ]WZHUGHQVROOGLH1RWDWLRQGLH6SH]LILNDWLRQGHU
$QIRUGHUXQJHQXPVFKOLHVVHQ"6ROOGLH1RWDWLRQ]XHLQHUYLVXHOOHQ
3URJUDPPLHUVSUDFKHDXVJHEDXWZHUGHQ"XQG]ZHLWHQVPXVVPDQ
HLQHQ$XVJOHLFK]ZLVFKHQ$XVGUXFNVVWlUNHXQG(LQIDFKKHLWVFKDIIHQ
,VWGLH0HWKRGH]XHLQIDFKZLUGGLH%UHLWHGHU3UREOHPHGLHGDPLW
JHO|VWZHUGHQN|QQHQ]XVWDUNHLQJHVFKUlQNW*HVWDOWHWVLFKGLH
0HWKRGHKLQJHJHQ]XNRPSOL]LHUWEHUZlOWLJWVLHGLH0|JOLFKNHLWHQ
GHUVWHUEOLFKHQ(QWZLFNOHU
'LH$UEHLWGHU9HUHLQKHLWOLFKXQJPXVV]XGHPVHQVLWLY]XGHU
EHVWHKHQGHQ%DVLVVHLQ:HUGHQ]XYLHOHbQGHUXQJHQYRUJHQRPPHQ
ZHUGHQGLHH[LVWLHUHQGHQ%HQXW]HUYHUZLUUWZDVVLFKHQWVSUHFKHQG
QHJDWLYDXIGLH$N]HSWDQ]DXVZLUNW:LUGGLH1RWDWLRQDEHUQLFKW
HQWVFKHLGHQGHUZHLWHUWHQWJHKWGHU0HWKRGHGLH*HOHJHQKHLWGHQ
%HQXW]HUNUHLV]XYHUEUHLWHUQ80/YHUVXFKWEHLGLHVHP%DODQFHDNW
GHQJHHLJQHWHQ.RPSURPLVV]XILQGHQ
Zukunft von UML
'LH%HVFKUHLEXQJGHU80/LVW$QIDQJLQVHLQHU9HUVLRQGHU
20*DOV9RUVFKODJIUHLQH6WDQGDUGPHWKRGHXQWHUEUHLWHWZRUGHQ
YOJ>%[email protected],QGHUHUVWHQ+lOIWHGHV-DKUHVZLUGQXQ
HLQHHQWVSUHFKHQGH6WHOOXQJQDKPHGHV*UHPLXPVHUZDUWHWGDPLWGLH
9RUDXVVHW]XQJHQHUIOOWZHUGHQN|QQHQXP80/DE0LWWHDOV
6WDQGDUGPHWKRGHIUGLHREMHNWRULHQWLHUWH0RGHOOLHUXQJ
SURNODPLHUHQ]XN|QQHQ8QDEKlQJLJGDYRQZHUGHQLP9HUODXIGHV
234 • Unified Modeling Language (UML)
Diplomarbeit
-DKUHVYHUVFKLHGHQH3XEOLNDWLRQHQXDDXFKGLHGULWWH$XIODJH
YRQ>%[email protected]$VSHNWHGHU80/EHUFNVLFKWLJW
HUZDUWHW
Was ist UML?
'LH(LJHQVFKDIWHQGHU80/N|QQHQIROJHQGHUPDVVHQ
]XVDPPHQJHIDVVWZHUGHQ
• 80/LVWHLQH6SUDFKHIUGLH6SH]LILNDWLRQ.RQVWUXNWLRQ
9LVXDOLVLHUXQJXQG'RNXPHQWDWLRQGHU$UWHIDNWHHLQHV
VRIWZDUHLQWHQVLYHQ6\VWHPV
• 80/YHUHLQWGLH.RQ]HSWHYRQ%RRFK207XQG226('DV
5HVXOWDWLVWHLQHHLQ]LJHXQGHLQIDFKDQZHQGEDUH
0RGHOOLHUXQJVVSUDFKHIU%HQXW]HUZHOFKHLQGHU9HUJDQJHQKHLW
EHUHLWVHLQHGHUJHQDQQWHQRGHUHLQHDQGHUHREMHNWRULHQWLHUWH
0HWKRGHQHLQJHVHW]WKDEHQ
• 80/]HLJWZDVPLWLKUHUUHLFKWZHUGHQNDQQ,QVEHVRQGHUH
ZXUGHQ.RQVWUXNWHIUGLH0RGHOOLHUXQJYRQNRQNXUUHQ]LHUHQGHQ
YHUWHLOWHQ6\VWHPHQHLQJHIKUW
• 80/GHILQLHUWHLQH6WDQGDUGVSUDFKHIUGLH0RGHOOLHUXQJXQG
YHU]LFKWHWDXIGLH%HVFKUHLEXQJHLQHV6WDQGDUGSUR]HVVHV
(UIDKUXQJHQDXVGHU$QZHQGXQJGHUYHUVFKLHGHQWOLFK
YRUJHVFKODJHQHQ9RUJHKHQVULFKWOLQLQHQLP3URMHNWNRQWH[WKDEHQ
JH]HLJWGDVVYHUVFKLHGHQH2UJDQLVDWLRQHQXQG3UREOHPEHUHLFKH
XQWHUVFKLHGOLFKH3UR]HVVHEHQ|WLJHQ'HVKDOEZXUGH]XHUVWHLQ
0HWDPRGHOOJHVFKDIIHQZHOFKHVGLH6HPDQWLNYHUHLQWXQG
DQVFKOLHVVHQGHLQH1RWDWLRQGHILQLHUWZHOFKHGLHVH6HPDQWLN
XPVHW]W'LH$XWRUHQVWDQGDUGLVLHUHQDOVRNHLQHQ3UR]HVVGHQQRFK
ZHUGHQLQGHQSUR]HVVVSH]LILVFKHQ([WHQVLRQHQYJO>80/
([[email protected](QWZLFNOXQJVSUR]HVVHYRUJHVFKODJHQGLH
DQZHQGXQJVIDOOJHVWHXHUWXVHFDVHGULYHQEH]JOLFKGHU$UFKLWHNWXU
JHQHULVFKLWHUDWLYXQGLQNUHPHQWHOOVLQG
'LH%HVFKUHLEXQJGHU80/LVWHLQH6DPPOXQJYRQYHUVFKLHGHQHQ
(LQ]HOGRNXPHQWHQ,PHLQ]HOQHQVLQGGLHV
• 80/6XPPDU\>80/6XPPDU\@IDVVWGLHZHLWHUHQ3DSLHUH
]XVDPPHQXQGJLEWHLQH(LQEOLFNXQGhEHUEOLFNEHU80/(QWKlOW
JHVFKLFKWOLFKH$QJDEHQ]X80/
• 80/6HPDQWLFV>80/[email protected]]LVH
0RGHOOZHOFKHV80/XQWHUOLHJW
• 80/1RWDWLRQ*XLGH>80/[email protected]%HVFKUHLEWGLH80/
1RWDWLRQXQGHQWKlOW%HLVSLHOH
• 80/3URFHVV([WHQVLRQ>80/([[email protected]
SUR]HVVVSH]LILVFKH:HUWHGHU(UZHLWHUXQJVPHFKDQLVPHQ
'DV0RGHOOGHU80/GHILQLHUWHLQH5HLKHYRQJUDILVFKHQ
'LDJUDPPHQ,QGHUQDFKIROJHQGHQ$XI]lKOXQJVROOHQGLHVHEHQDQQW
XQGGHUHQ+HUNXQIWLQ.ODPPHUQEHVWLPPWZHUGHQ'LH
'LDJUDPPW\SHQZHUGHQLQGLH%HUHLFKHGHVVWDWLVFKHQ(QWZXUIVGHV
G\QDPLVFKHQ(QWZXUIVXQGGHU,PSOHPHQWDWLRQHLQJHWHLOWZREHLDXI
HLQHJHQDXHUH%HVFKUHLEXQJYHU]LFKWHWZLUG
6WDWLVFKHU(QWZXUI
• XVHFDVHGLDJUDPV226(
• FODVVGLDJUDPV%RRFK207HWDO
Diplomarbeit
Unified Modeling Language (UML) • 235
'\QDPLVFKHU(QWZXUI
• VWDWHGLDJUDPV'DYLG+DUHO>[email protected]
• DFWLYLW\GLDJUDPV:RUN)ORZ
• VHTXHQFHGLDJUDPV,QWHUDNWLRQVGLDJUDPPHYRQ%RRFK
• FROODERUDWLRQGLDJUDPV2EMHNWGLDJUDPPHYRQ%RRFK
,PSOHPHQWDWLRQ
• FRPSRQHQWGLDJUDPV0RGXOGLDJUDPPHYRQ%RRFK
• GHSOR\PHQWGLDJUDPV3UR]HVVGLDJUDPPHYRQ%RRFK
$OVHFKWQHXH.RQ]HSWHGHU80/N|QQHQGLHQDFKIROJHQG
]XVDPPHQJHIDVVWHQDQJHVHKHQZHUGHQ
• VWHUHRW\SHV
• UHVSRQVLELOLWLHV
• H[WHQVLRQPHFKDQLVPVVWHUHRW\SHVWDJJHGYDOXHVFRQVWUDLQWV
• WKUHDGVDQGSURFHVVHV
• GLVWULEXWLRQDQGFRQFXUUHQF\$FWLYH;'&20DQG&25%$
• SDWWHUQVFROODERUDWLRQV
• DFWLYLW\GLDJUDPV
• .ODUH7UHQQXQJYRQ7\SHQ.ODVVHQXQG,QVWDQ]HQ
• 9HUIHLQHUXQJHQ
• 6FKQLWWVWHOOHQXQG.RPSRQHQWHQ
Unterschiede zu Booch
'LH80/LVWNHLQH1HXHUILQGXQJVRQGHUQHLQHQDWUOLFKH
:HLWHUHQWZLFNOXQJ]%GHU0HWKRGHYRQ%RRFK'DVEHUGLH-DKUH
DQJHHLJQHWH:LVVHQXQGGLH(UIDKUXQJHQPLWGHU%RRFK·VFKHQ
1RWDWLRQN|QQHQZHLWHUYHUZHQGHWZHUGHQ
80/LVWMHGRFKZHVHQWOLFKDXVGUXFNVVWlUNHUJHZRUGHQ(VN|QQHQ
QXQ*HJHEHQKHLWHQDEJHELOGHWZHUGHQGLHHKHPDOVDXVVHUKDOEGHU
HUIDVVEDUHQ6DFKYHUKDOWHODJHQ'LH1RWDWLRQLQ80/LVWNODUHUXQG
XQLIRUPHUXQGELOGHWHLQHHFKWH2EHUPHQJHGHU]XJUXQGHOLHJHQGHQ
1RWDWLRQHQ
'DPLWLVWHVRKQHZHLWHUHVP|JOLFKGLH'LDJUDPPHGLHEDVLHUHQG
DXIGHU%RRFK·VFKHQ0HWKRGHHUVWHOOWZRUGHQVLQGRKQH9HUOXVWYRQ
,QIRUPDWLRQLQGLH80/]XEHUWUDJHQ$XVGLHVHP*UXQGVHL
QDFKIROJHQGDXIJH]HLJWZLHHLQHGHUDUWLJH$EELOGXQJLQ$QJULII
JHQRPPHQZHUGHQN|QQWHRGHUZLHGLH'LDJUDPPHYRQ%RRFKLQ
GLH80/HLQJHIORVVHQVLQG
.ODVVHQGLDJUDPPH
VLQGLQGLHÅFODVVGLDJUDPV´HLQJHIORVVHQGLH1RWDWLRQLVWDEHUVWDUN
DQ207DQJHOHKQWLQVEHVRQGHUHVLQGGLH%RRFK·VFKHQ:RONHQ
YHUVFKZXQGHQ
=XVWDQGVEHUJDQJVGLDJUDPPH
VLQGVFKRQLQGHU%RRFK·VFKHQ0HWKRGHDQGLH(QWVSUHFKXQJHQYRQ
+DUHO>[email protected],QGHU80/ZHUGHQQXQGLHH[DNWHQ
+DUHO'LDJUDPPHYHUZHQGHWXQGXQWHUGHP1DPHQÅVWDWH
GLDJUDPV´JHIKUW
2EMHNWGLDJUDPPH
VLQGLVWGLHÅFROODERUDWLRQGLDJUDPV´EHUJHJDQJHQ
,QWHUDNWLRQVGLDJUDPPH
VLQGZHVHQWOLFKHUZHLWHUWZRUGHQ5HNXUVLRQ%HJLQQXQG(QGHGHU
236 • Unified Modeling Language (UML)
Diplomarbeit
/HEHQV]HLWYRQ2EMHNWHQDNWLYHXQGLQDNWLYH2EMHNWHEHGLQJWH
9HU]ZHLJXQJHQXQGKHLVVHQQXQÅVHTXHQFHGLDJUDPV´
0RGXOGLDJUDPPH
VLQGHUZHLWHUWDOVÅFRPSRQHQWGLDJUDPV´YHUIJEDU
3UR]HVVGLDJUDPPH
VLQGHUZHLWHUWDOVÅGHSOR\PHQWGLDJUDPV´DXIJHQRPPHQZRUGHQ
$XVGHURELJHQ*HJHQEHUVWHOOXQJNDQQPDQDEOHVHQGDVVVlPWOLFKH
'LDJUDPPHYRQ%RRFKLKUH(QWVSUHFKXQJLQ80/JHIXQGHQKDEHQ
6LHVLQGGDEHL]XP7HLOGLUHNWXQG]XP7HLOGXUFKZHVHQWOLFKH
(UZHLWHUXQJHQLQ80/EHUQRPPHQZRUGHQ
'LHVH$EELOGXQJOlVVWVLFKDEHUQLFKWRKQHZHLWHUHVXPNHKUHQGDLQ
80/'LDJUDPPHHQWKDOWHQVLQGGLHLQ%RRFKQLFKWYRUNRPPHQ
]%XVHFDVHGLDJUDPV
Implikationen für DEIMOS
'(,026LVWHLQH(UZHLWHUXQJGHU0HWKRGHYRQ%RRFK'LH
(UZHLWHUXQJHQZXUGHQDXIJUXQGYHUVFKLHGHQHU6FKZDFKVWHOOHQEHL
GHU$QZHQGXQJHQIUGHQNRQ]HSWLRQHOOHQ'DWHQEDQNHQWZXUI
HLQJHIKUW'LH)UDJHDOVRODXWHWZlUHQGLH6FKZDFKVWHOOHQQLFKW
DXIJHWUHWHQZHQQYRQGHU80/DXVJHJDQJHQZRUGHQZlUH"
3HUVLVWHQ].HLQHVGHU'LDJUDPPHGHU80/LQVEHVRQGHUHDXFK
GDV.ODVVHQGLDJUDPPHQWKlOW.RQVWUXNWHIUGLH8QWHUVFKHLGXQJ
]ZLVFKHQSHUVLVWHQWHQXQGWUDQVLHQWHQ2EMHNWHQ'LH6FKZDFKVWHOOH
ZlUHDOVRJOHLFKVDPDXIJHWUHWHQ
7UDQVDNWLRQHQ$XFKLQGHU80/VLQGNHLQH.RQVWUXNWHIUGHQ
7UDQVDNWLRQVHQWZXUIHQWKDOWHQ
3K\VLVFKH$VSHNWH'LHLP*HJHQVDW]]X%RRFK·V
3UR]HVVGLDJUDPPHZHVHQWOLFKHUZHLWHUWHQ9HUWHLOXQJVGLDJUDPPH
HUODXEHQHLQHQYHUEHVVHUWHQ(QWZXUIGHUSK\VLVFKHQ$VSHNWH'LH
'LDJUDPPHHQWKDOWHQ.RQVWUXNWHIUGLH0RGHOOLHUXQJYRQ
SK\VLVFKHQ.QRWHQGHQHQEHLVSLHOVZHLVH&OXVWHU]XJHZLHVHQZHUGHQ
N|QQHQ
$SSOLNDWLRQHQ'DLQGHU80/QLFKW]ZLVFKHQWUDQVLHQWHQXQG
SHUVLVWHQWHQ,QVWDQ]HQXQWHUVFKLHGHQZHUGHQNDQQVLQGDXFKLP
%HUHLFKGHU$SSOLNDWLRQHQXQG$SSOLNDWLRQVNODVVHQ6FKZDFKVWHOOHQ
]XEHPlQJHOQ0LWWHOVGHUQHXHQ.RQVWUXNWHIUGLH'DUVWHOOXQJYRQ
3DFNXQJHQXQG6FKQLWWVWHOOHQGHILQLWLRQHQKLQJHJHQZLUGGHU
$SSOLNDWLRQVHQWZXUIZHVHQWOLFKEHVVHUXQWHUVWW]W
,QYHUVH%H]LHKXQJHQ$XFKLQGHQQHXHQ.ODVVHQGLDJUDPPHQ
N|QQHQNHLQHÅHFKWHQ´LQYHUVHQ%H]LHKXQJHQDEJHELOGHWZHUGHQ
([WHQVLRQHQXQG6FKOVVHO,QGHU80/VWHKHQQDFKZLHYRUNHLQH
.RQVWUXNWHIUGLH'HILQLWLRQYRQ6FKOVVHOXQGGHQHQWVSUHFKHQGHQ
([WHQVLRQHQ]XU9HUIJXQJ
)RUWSIODQ]XQJXQG.RQVLVWHQ]VLFKHUXQJ]ZDUZHUGHQLQGHQ
QHXHQ.ODVVHQNRQVWUXNWHQ]XVlW]OLFKH0|JOLFKNHLWHQIUGLH
)RUPXOLHUXQJYRQ=XVLFKHUXQJHQDQJHERWHQ%HGLQJXQJHQZHOFKH
]X%HJLQQXQGDP(QGHYRQ0HWKRGHQDXVIKUXQJHQHUIOOWVHLQ
PVVHQGRFKYHUP|JHQGLHVHQLFKWDOOH$VSHNWHGHU(UKDOWXQJGHU
'DWHQLQWHJULWlWDE]XGHFNHQ
2EMHNWHYROXWLRQ:HGHULQGHQVWDWLVFKHQQRFKLQGHQG\QDPLVFKHQ
'LDJUDPPHQVLQG.RQVWUXNWHIUGLH0LJUDWLRQYRQ,QVWDQ]HQ
YRUJHVHKHQ$XFKGLHVH6FKZDFKVWHOOHEOHLEWDOVRYROOVWlQGLJHUKDOWHQ
Diplomarbeit
Unified Modeling Language (UML) • 237
=XVDPPHQIDVVHQGOlVVWVLFKDOVRIHVWVWHOOHQGDVVDXFKLQGHU80/
GLH$VSHNWHGHVNRQ]HSWXHOOHQ'DWHQEDQNHQWZXUIVXQJHQJHQG
EHUFNVLFKWLJWZRUGHQVLQG'LH6FKZDFKVWHOOHQWUHWHQDOVR
JU|VVWHQWHLOVDXFKEHLP(LQVDW]GHU80/DXI'XUFKGLHQHXHQ
0|JOLFKNHLWHQ.RPSRQHQWHQGLDJUDPPHRGHU
9HUWHLOXQJVGLDJUDPPHKlWWHQVLFKGLHVHMHGRFKYLHOHURUWVHOHJDQWHU
EHKHEHQODVVHQ=XGHPKlWWHJHJHEHQHQIDOOVHLQHJU|VVHUH0HQJH
YRQ6FKZDFKVWHOOHQSK\VLVFKH$VSHNWHLQGLHZHLWHUH8QWHUVXFKXQJ
DXIJHQRPPHQXQGEHKREHQZHUGHQN|QQHQ
Anpassungen an DEIMOS für die
Konsistenz zur UML
'LH6FKZDFKVWHOOHQZlUHQDOVRJU|VVWHQWHLOVDXFKDXIJHWUHWHQKlWWH
PDQGLH(UZHLWHUXQJHQEDVLHUHQGDXIGHU80/GHILQLHUW:UGHPDQ
DOVRYRQGHU80/DXVJHKHQZUGHQVLFKGLHQHXHLQJHIKUWHQ
.RQVWUXNWHYRUDOOHPRSWLVFKXQWHUVFKLHGHQ
,QGHUQDFKIROJHQGHQ*HJHQEHUVWHOOXQJZLUGHLQHGHUDUWLJH
$EELOGXQJYRQ'(,026DOV(UZHLWHUXQJYRQ%RRFKXQGYRQ
'(,026DOV(UZHLWHUXQJYRQ80/GDUJHVWHOOW0LWGLHVHUHLQIDFKHQ
8PVHW]XQJN|QQWHDOVRHLQH.RQVLVWHQ]]XU80/HUUHLFKWZHUGHQ
Schemadiagramme
Booch-basiert
UML-basiert
class name
attributes
class<keyattrib.>
operations()
{constraints}
A
class name
attributes
class<keyattrib.>
methods()
{constraints}
class utility name
attributes
operations()
{constraints}
'DWHQEDQNNODVVHQ
)UGLH'DUVWHOOXQJGHU'DWHQEDQNNODVVHQNDQQGDV
6WDQGDUGNRQVWUXNWIUGLH.ODVVHQEHUQRPPHQ
ZHUGHQ
$EVWUDNWH.ODVVHQ
,Q80/ZHUGHQIUGLH'DUVWHOOXQJGHUDEVWUDNWHQ
.ODVVHQGLH6WDQGDUGNRQVWUXNWHYHUZHQGHWXQGPLW
GHP6FKOVVHOZRUWÅDEVWUDFW´YHUVHKHQ
+LOIVNODVVHQ
'LH+LOIVNODVVHQZHUGHQGXUFKGDV6WHUHRW\S
ÅXWLOLW\´JHNHQQ]HLFKQHW'HUDUWLJH.ODVVHQ
EHVLW]HQNHLQH$WWULEXWHZHVKDOEGHUPLWWOHUH7HLO
GHU,NRQHIUHLEOHLEW
2EMHNWH
PersistentName
2EMHNWHXQG.ODVVHQZHUGHQLQ80/QLFKWPHKU
VWUHQJJHWUHQQW(QWVSUHFKHQGZLUGIUGLH
'DUVWHOOXQJHLQ.ODVVHQNRQVWUXNWYHUZHQGHW
ZHOFKHVHLQHQ1DPHQKDWXQGGHVVHQ$WWULEXWH
:HUWHWUDJHQ
238 • Unified Modeling Language (UML)
<<stereotype>>
Package::Class
type
attributes {constraints}
class<keyattrib.>
operations() {constraints}
<<stereotype>>
Package::Class
abstract
attributes {constraints}
class<keyattrib.>
operations() {constraints}
<<utility>>
Package::Class
operations()
Name : Class
attribute1 = value1
attribute2 = value2
operations() {constraints}
Diplomarbeit
1RWL]HQ
'LH'DUVWHOOXQJGHU1RWL]HQKDWVLFKQXU
JHULQJIJLJJHlQGHUW'HU6FKDWWHQLVWZHJJHIDOOHQ
XQGGDVÅ(VHOVRKU´NDQQLQHLQHUEHOLHELJHQ(FNH
SRVLWLRQLHUWVHLQ
Notes
Notes
9HUHUEXQJVEH]LHKXQJ
'HU9HUHUEXQJVSIHLOLVWQHXPLWHLQHUHWZDV
DQGHUHQ3IHLOVSLW]HGDUJHVWHOOW
KA
KB
.RPSRQHQWHQEH]LHKXQJ
KA
KB
$XIGHU6HLWHGHU$JJUHJDWLRQVNODVVHVWHKWHLQH
5DXWHXQGDXIGHU6HLWHGHU.RPSRQHQWHHLQ3IHLO
KA
KB
,QYHUVH%H]LHKXQJ
KA KB
'LHVHV.RQVWUXNWIHKOWLQGHU80/XQGPXVV
GHPQDFKQHXGHILQLHUWZHUGHQ$XV
.RPSDWLELOLWlWVJUQGHQZLUGHVDXVGHQ(OHPHQWHQ
GHUQLFKWH[LVWHQ]DEKlQJLJHQ$JJUHJDWLRQ
]XVDPPHQJHVHW]W
K
5HIHUHQ]HQ
K
)UGLH'DUVWHOOXQJGHU5HIHUHQ]HQZLUGGLH
(QWKDOWHQVHLQVEH]LHKXQJYHUZHQGHW
,QVWDQWLLHUXQJVEH]LHKXQJ
'LH,QVWDQWLLHUXQJLVWQHXPLWHLQHUHWZDVDQGHUHQ
3IHLOVSLW]HGDUJHVWHOOW
2EMHNWHYROXWLRQ
e()
'DV(YROXWLRQVNRQVWUXNWLVWDXFKLQ80/QLFKW]X
ILQGHQ'HVKDOEZLUGHVNRPSDWLEHOQDFKGHILQLHUW
e()
1RWL]EH]XJ
'HU1RWL]EH]XJLVWLQ80/LGHQWLVFK
Transaktionsdiagramme
Booch-basiert
UML-basiert
$SSOLNDWLRQHQ
'DV$SSOLNDWLRQVNRQVWUXNWLVWDXFK80/HQWKDOWHQ
ApplicationName
Diplomarbeit
ApplicationName
Unified Modeling Language (UML) • 239
6XEV\VWHPH
SubSystem
ProgrammName
Instructions
Function(P:T):T
Instructions
6XEV\VWHPHN|QQHQLQ80/DOVVRJHQDQQWH
Å3DFNXQJHQ´GDUJHVWHOOWZHUGHQ,Q3DFNXQJHQ
N|QQHQEHOLHELJH1RWDWLRQVHOHPWHHQWKDOWHQVHLQ
6LHGLHQHQ]XUDOOJHPHLQHQ6WUXNWXULHUXQJGHU
'LDJUDPPH
3URJUDPPH
<<Program>>
,Q80/ZXUGHHLQQHXHU'LDJUDPPW\SGLH
.RPSRQHQWHQGLDJUDPPHHLQJHIKUW3URJUDPPH
PVVHQGLHVHU6HPDQWLNHQWVSUHFKHQGDOV
.RPSRQHQWHQEHWUDFKWHWZHUGHQXQGZHUGHQ
GHPQDFKPLWGHP.RPSRQHQWHQNRQVWUXNW
GDUJHVWHOOW
)XQNWLRQHQ
<<Function>>
$XFK)XQNWLRQHQVLQGDOV.RPSRQHQWHQ
GDU]XVWHOOHQ6LHZHUGHQGXUFKGDV6WHUHRW\S
XQWHUVFKLHGHQ
7UDQVDNWLRQHQ
TransactionName
Subsystem
<<Transaction>>
'LH7UDQVDNWLRQHQZHUGHQDOV.RPSRQHQWHQPLW
GHP6WHUHRW\SÅ7UDQVDNWLRQ´GDUJHVWHOOW
Instructions
$XIUXIH
$EKlQJLJNHLWHQ]ZLVFKHQGHQ.RPSRQHQWHQ
ZHUGHQPLWGHPDXVJH]RJHQHQ3IHLOGDUJHVWHOOW
ZHVKDOEGLHVHV.RQVWUXNWIUGLH$XIUXIH
KHUDQJH]RJHQZHUGHQVROO%H]LHKXQJHQ]ZLVFKHQ
3DFNXQJHQMHGRFKZHUGHQPLWGHPJHVWULFKHOWHQ
3IHLOGHILQLHUW$XVGLHVHP*UXQGPXVVDXFKGDV
HQWVSUHFKHQGH.RQVWUXNWIUGLH'DUVWHOOXQJGHU
$XIUXIH]XJHODVVHQVHLQ
240 • Unified Modeling Language (UML)
Diplomarbeit
Installation
Installation von Hardy vom Internet
'LH(QWZLFNOHUGHV=HLFKHQZHUN]HXJHV+DUG\EHWUHLEHQHLQH6HLWH
DXIGHP,QWHUQHWZHOFKHEHUGLH$GUHVVHKWWSUKXP
HJRDLDLHGDFXN∼KDUG\DEJHUXIHQZHUGHQNDQQ
$XIGLHVHU6HLWHLVWQHEHQGHQXPIDQJUHLFKHQ,QIRUPDWLRQHQEHU
+DUG\DXFKHLQHÅ'RZQORDG$UHD´]XILQGHQ+HUXQWHUJHODGHQ
ZHUGHQNDQQLQVEHVRQGHUHHLQH'HPRYHUVLRQYRQ+DUG\9HUVLRQ
,QVWUXNWLRQHQ]XP+HUXQWHUODGHQVLQGHEHQIDOOVDXIGLHVHU6HLWH
]XILQGHQ
Installation auf Windows 95
1DFKGHP6LHGLH$UFKLYGDWHLYRP,QWHUQHWEH]RJHQKDEHQ
H[WUDKLHUHQ6LHHVLQHLQHQVSH]LHOOHQWHPSRUlUHQ2UGQHU]%
&?7(03?,167$//,P$UFKLYLVWHLQ,QVWDOODWLRQVSURJUDPP
,167$//(;(HQWKDOWHQGDV6LHGXUFKHLQHQ'RSSHONOLFNVWDUWHQ
N|QQHQYJO>+DUG\,[email protected]
(VHUVFKHLQWGHUIROJHQGH%LOGVFKLUP
$FKWHQ6LHGDUDXIGDVV+DUG\LP9HU]HLFKQLV&?+$5'<LQVWDOOLHUW
ZLUGGDPLWGDVVSlWHUH=XVDPPHQVSLHOYRQ+DUG\XQG26:22'
HLQZDQGIUHLXQWHUVWW]WZHUGHQNDQQ
:lKOHQ6LHGLHJHZQVFKWHQ2SWLRQHQXQG.OLFNHQ6LHDXI2.
'LHEHQ|WLJWHQ'DWHLHQZHUGHQNRSLHUW
Diplomarbeit
Installation • 241
$QVFKOLHVVHQGZLUGHLQH'266KHOOIUGDV([WUDKLHUHQGHU%LQlUGDWHLHQXQG
GHU+DUG\6'.'DWHLHQJH|IIQHW'DQDFKZHUGHQGLH(LQWUlJHGHU/LQNVDXI
GLH3URJUDPPHXQG+LOIHGDWHLHQDXWRPDWLVFKLQGDV6WDUWPHQHLQJHEDXW
$P(QGHGHV.RSLHUSUR]HVVHVGHUFD6HNXQGHQGDXHUWNDQQ
+DUG\GLUHNWJHVWDUWHWZHUGHQ
+DUG\ZLUGIDOOVGLHRELJH)UDJHPLWMDEHDQWZRUWHWZXUGHPLWHLQHP
PLWJHOLHIHUWHQ(LQIKUXQJVEHLVSLHOJHVWDUWHW
242 • Installation
Diplomarbeit
=X6FKOXVVZLUGGHU(UIROJGHU,QVWDOODWLRQEHUGLHIROJHQGH0HOGXQJDQJH]HLJW
+DUG\LVWQXQYROOVWlQGLJLQVWDOOLHUWXQGNDQQJHPlVV%HVFKUHLEXQJ
YJO´6WDUWHQYRQ+DUG\µ6HLWHJHVWDUWHWZHUGHQ
Registrierung
%HDFKWHQ6LHELWWHGDVV+DUG\OL]HQ]SIOLFKWLJLVW'LHYRQ,QWHUQHW
EH]RJHQH9HUVLRQLVWOHGLJOLFKHLQH'HPRYHUVLRQ0|FKWHQ6LHGLH
9ROOYHUVLRQEHWUHLEHQVFKLFNHQ6LHGHQ$QELHWHUQHLQ(0DLOJHPlVV
$QOHLWXQJDXIGHU,QWHUQHWVHLWH+DEHQ6LHHLQHNRUUHNWH
/L]HQ]QXPPHUHUKDOWHQN|QQHQ6LHGLHVHZLHIROJWLP+DUG\
HLQJHEHQ
:lKOHQ6LHDXVGHP0HQLP+DXSWIHQVWHUYRQ+DUG\GHQ3XQNW
Tools | Preferences
'HUIROJHQGH'LDORJHUVFKHLQW
Diplomarbeit
Installation • 243
.OLFNHQ6LHDXIGLH6FKDOWIOlFKHÅ6HULDOQXPEHU´
'HUIROJHQGH(LQJDEHGLDORJHUVFKHLQW
*HEHQ6LHLKUH6HULHQQXPPHUHLQXQGEHVWlWLJHQ6LHGLH(LQJDEHPLW
Å2.´
6LHN|QQHQQXQ+DUG\RKQH(LQVFKUlQNXQJHQEHWUHLEHQ
Installation von Hardy mit der
beiliegenden Diskette
$XIGHUEHLOLHJHQGHQ'LVNHWWHÅ+DUG\IRU26:22'9HUVLRQ´
LVWHLQHPLQLPDOH,QVWDOODWLRQYRQ+DUG\YRUEHUHLWHW*HJHQEHUGHU
9ROOYHUVLRQIHKOHQGLH+LOIHGDWHLHQXQGGDV+DUG\6'.
%HLGHU,QVWDOODWLRQVROOQDFKGHQIROJHQGHQ6FKULWWHQYRUJHJDQJHQ
ZHUGHQ
(UVWHOOHQ6LHHLQ9HU]HLFKQLV&?+$5'<
.RSLHUHQ6LHGLH'DWHL+$5'<=,3LQGDV9HU]HLFKQLV
&?+$5'<
.RSLHUHQ6LHGLH'DWHL3.81=,3(;(LQGDV9HU]HLFKQLV
&?+$5'<
gIIQHQVLHHLQH'266KHOO&0'(;(RGHU&200$1'(;(
:HFKVHOQ6LHLQGDV9HU]HLFKQLV&?+$5'<FG?KDUG\
([SDQGLHUHQ6LHGDV$UFKLY+$5'<=,3SNXQ]LSKDUG\]LS
6FKOLHVVHQ6LHGLH'266KHOO
/|VFKHQ6LHDXVGHP9HU]HLFKQLV&?+$5'<GLH'DWHL
+$5'<=,3
/|VFKHQ6LHDXVGHP9HU]HLFKQLV&?+$5'<GLH'DWHL
3.81=,3(;(
244 • Installation
Diplomarbeit
%HDFKWHQ6LHELWWHGDVVGLHVH9HUVLRQOHGLJOLFKHLQH'HPRYHUVLRQLVW
/L]HQ]LHUXQJVLHKHREHQ
Installation von OSWOOD
9RUDXVVHW]XQJHQIUGHQIHKOHUIUHLHQ%HWULHEYRQ26:22'VLQG
GLH,QVWDOODWLRQ
• YRQ+DUG\
• GHU6\PEROELEOLRWKHNHQXQG
• YRQ26:22'
'HUYRUOLHJHQGHQ$UEHLWEHLJHOHJWVLQG]ZHL'LVNHWWHQPLWGHQIU
GHQ0LQLPDOEHWULHEQRWZHQGLJHQ'DWHLHQ
Die Symbolbibliotheken von DEIMOS
'LHLQGHU0HWKRGH'(,026YHUZHQGHWHQ6\PEROELEOLRWKHNHQVLQG
LQGHQIROJHQGHQ'DWHLHQJHVSHLFKHUW
DIAGRAMS.DEF
basic.slb
ooadarcs.slb
oonodes.slb
symbols.slb
DEIMOS.slb
BCLOBJEC.DEF
BINTER.DEF
BMODULE.DEF
BPROCESS.DEF
BTRANS.DEF
SCHEMA.DEF
TRANS.DEF
CONTEXT.DEF
Listing 7-1: Die Dateien mit den Definitionen der Symbole und Diagramme
:HQQ6LHGLH,QVWDOODWLRQYRQ+DUG\PLWGHUEHLOLHJHQGHQ'LVNHWWH
HUOHGLJWKDEHQYHUIJHQ6LHEHUHLWVEHUGLHQRWZHQGLJHQ
6\PEROELEOLRWKHNHQXQG'LDJUDPPGHILQLWLRQVGDWHLHQ+DEHQ6LH
MHGRFK+DUG\GLUHNWYRP,QWHUQHWEH]RJHQPVVHQ6LHGLH
QDFKIROJHQGHQ6FKULWWHXQWHUQHKPHQGDPLWGLH'LDJUDPPHYRQ
'(,026LQ+DUG\XQWHUVWW]WZHUGHQN|QQHQ
(UVWHOOHQ6LHHLQWHPSRUlUHV9HU]HLFKQLV]%Å&?7(03´
.RSLHUHQ6LHGLH'DWHLHQ+$5'<=,3XQG3.81=,3(;(GHU
'LVNHWWHÅ+DUG\IRU26:22'´LQGLHVHV9HU]HLFKQLV
gIIQHQVLHHLQH'266KHOO&0'(;(RGHU&200$1'(;(
:HFKVHOQ6LHLQGDV9HU]HLFKQLV&?+$5'<FG?KDUG\
([SDQGLHUHQ6LHGDV$UFKLY+$5'<=,3SNXQ]LSKDUG\]LS
6FKOLHVVHQ6LHGLH'266KHOO
.RSLHUHQ6LHGLH'DWHLHQGHURELJHQ'DWHLOLVWH/LVWLQJLQGDV
9HU]HLFKQLV&?+$5'<
/|VFKHQ6LHGDVWHPSRUlUH9HU]HLFKQLV
Installation von OSWOOD
'DV:HUN]HXJ26:22'EHVWHKWOHGLJOLFKDXVHLQHU
$QZHQGXQJVGDWHLZHOFKH6LHDXIGHU'LVNHWWHÅ26:22'9HUVLRQ
´ILQGHQ.RSLHUHQ6LHGLHVHLQHLQ9HU]HLFKQLVLKUHU:DKO
Diplomarbeit
Installation • 245
Notation
Schemadiagramm
Knoten
class name
attributes
class<keyattrib.>
operations()
{constraints}
A
'DWHQEDQNNODVVHQ
$EVWUDNWH.ODVVHQ
class name
attributes
class<keyattrib.>
methods()
{constraints}
class utility name
attributes
operations()
{constraints}
+LOIVNODVVHQ
2EMHNWH
PersistentName
1RWL]HQ
Notes
Kanten
9HUHUEXQJVEH]LHKXQJ
[1]
K
KA
KB
Diplomarbeit
.RPSRQHQWHQEH]LHKXQJ
,QYHUVH%H]LHKXQJ
Implementation • 247
K
5HIHUHQ]HQ
,QVWDQWLLHUXQJVEH]LHKXQJ
2EMHNWHYROXWLRQ
e()
1RWL]EH]XJ
Transaktionsdiagramm
Knoten
$SSOLNDWLRQHQ
ApplicationName
6XEV\VWHPH
SubSystem
ProgrammName
3URJUDPPH
Instructions
Function(P:T):T
)XQNWLRQHQ
Instructions
248 • Implementation
Diplomarbeit
7UDQVDNWLRQHQ
TransactionName
Instructions
Kanten
$XIUXIH
Diplomarbeit
Implementation • 249
Glossar
Abstrakte Klassen
.ODVVHQYRQGHQHQNHLQH,QVWDQ]HQJHELOGHWZHUGHQGUIHQZHUGHQ
DEVWUDNWH.ODVVHQJHQDQQW'LHQHQPHLVWIUGLH%HVFKUHLEXQJGHV
JHPHLQVDPHQDEVWUDNWHQ9HUKDOWHQVYHUVFKLHGHQHU%DVLVNODVVHQLQ
6XSHUNODVVHQ'LHVH.ODVVHQILQGHQLQGHU5HDOZHOWKlXILJNHLQH
(QWVSUHFKXQJHQEHVFKUHLEHQNHLQHUHDOHQ2EMHNWHVLHVLQGDEVWUDNW
Assoziation
$OOJHPHLQH%H]LHKXQJ]ZLVFKHQ]ZHL2EMHNWHQ:LUGYRUDOOHPLP
*UREHQWZXUIGHILQLHUWXQGLP)HLQHQWZXUILQHLQH9HUHUEXQJV
$JJUHJDWLRQVRGHU9HUZHQGXQJVEH]LHKXQJXPJHVHW]W
Extension
0HQJHDOOHU]XHLQHPJHZLVVHQ=HLWSXQNWH[LVWLHUHQGHQ,QVWDQ]HQ
HLQHU.ODVVHYJO,QWHQVLRQ
Friend-Klassen
.ODVVHQZHOFKHQH[SOL]LWVSH]LHOOH=XJULIIVUHFKWHHLQJHUlXPWZXUGHQ
ZHUGHQDOV)ULHQG.ODVVHQEH]HLFKQHWhEOLFKHUZHLVHZHUGHQ
GHUDUWLJHQ.ODVVHQ=XJULIIHDXISULYDWH$WWULEXWHRGHU0HWKRGHQ
HUODXEW
IDL
,QWHUIDFH'HILQLWLRQ/DQJXDJH9RQGHU20*GHILQLHUWH
6FKQLWWVWHOOHQGHILQLWLRQVVSUDFKHIU2EMHNWH
Intension
0HQJHDOOHUGHQNEDUHQ,QVWDQ]HQHLQHU.ODVVHYJO([WHQVLRQ
Inverse Beziehung
5FNEH]JOLFKH%H]LHKXQJ(LQ2EMHNW$XQWHUKlOWHLQHLQYHUVH
%H]LHKXQJ]XHLQHP2EMHNW%JHQDXGDQQZHQQGDV2EMHNW%HLQH
LQYHUVH%H]LHKXQJ]XP2EMHNW$XQWHUKlOW
Klasse
JHPHLQVDPH%HVFKUHLEXQJDOOHUGHQNEDUHQV\QWDNWLVFKEHUKDXSW
P|JOLFKHQ2EMHNWHHLQHUEHVWLPPWHQ&KDUDNWHULVWLN>'LWWULFKHWDO
@
Nesting-Klassen
.ODVVHQGLHLQHLQHU.ODVVHHLQJHEHWWHWXQGGHPQDFKYRQDXVVHUKDOE
QLFKWPHKUVLFKWEDUVLQGZHUGHQDOV1HVWLQJ.ODVVHQEH]HLFKQHW
MFC
0LFURVRIW)RXQGDWLRQ&ODVVHV&.ODVVHQELEOLRWKHNGHU)LUPD
0LFURVRIW&RRUSHUDWLRQ%HVWDQGWHLOGHU(QWZLFNOXQJVXPJHEXQJ
9LVXDO&
Objektevolution
6WHKWIUGHQ:HFKVHOGHU.ODVVHQ]XJHK|ULJNHLWHLQHU,QVWDQ]
ODL
2EMHFW'HILQLWLRQ/DQJXDJH2EMHNWGHILQLWLRQVVSUDFKH%HVWDQGWHLO
GHV6WDQGDUGVGHU2'0*3HQGDQW]XU'DWHQGHILQLWLRQVVSUDFKH
''/LQUHODWLRQDOHQ6\VWHPHQ
OMG
Diplomarbeit
Glossar • 251
2EMHFW0DQDJHPHQW*URXS*UHPLXPIUGLH6WDQGDUGLVLHUXQJHQLP
%HUHLFKGHUREMHNWRULHQWLHUWHQ6\VWHPH3UIW]XU=HLWGLH(LJQXQJ
GHU80/DOV6WDQGDUGIUGHQREMHNWRULHQWLHUWHQ(QWZXUI
OML
2EMHFW0DQLSXODWLRQ/DQJXDJH0DQLSXODWLRQVVSUDFKHIU
2EMHNWGDWHQ,VWNHLQ%HVWDQGWHLOGHV6WDQGDUGVGHU2'0*
VRQGHUQZLUGLQQHUKDOEHLQHUEHVWLPPWHQ3/2'/GHILQLHUW3HQGDQW
]XU0DQLSXODWLRQVVSUDFKH'0/LQUHODWLRQDOHQ6\VWHPHQ
ODMG
2EMHFW'DWD0DQDJHPHQW*URXS*UHPLXPIUGLH
6WDQGDUGLVLHUXQJHQLP%HUHLFKGHUREMHNWRULHQWLHUWHQ'DWHQEDQNHQ
(UOLHVVLP-DKUHGHQ6WDQGDUGÅ2'0*´IU
REMHNWRULHQWLHUWH'DWHQEDQNV\VWHPHYJO>&[email protected]
OQL
2EMHFW4XHU\/DQJXDJH2EMHNWDEIUDJHVSUDFKH%HVWDQGWHLOGHV
6WDQGDUGVGHU2'0*3HQGDQW]XU$EIUDJHVSUDFKH64/LQ
UHODWLRQDOHQ6\VWHPHQ
PL-ODL
3URJUDPPLQJ/DQJXDJH2'/6SH]LILVFKH8PVHW]XQJGHU
$QELQGXQJGHU2EMHNWGHILQLWLRQVVSUDFKHIUHLQHEHVWLPPWH
3URJUDPPLHUVSUDFKH
Schemaevolution
%HVFKUHLEWGLH:HLWHU(QWZLFNOXQJHLQHV'DWHQEDQNVFKHPDV
+LQ]XIJHQ(QWIHUQHQ9HUlQGHUQYRQ.ODVVHQ$SSOLNDWLRQHQ
HWF'DV+LQ]XIJHQ(QWIHUQHQ9HUlQGHUQYRQ2EMHNWHQ
2EMHNWGDWHQZLUGQLFKWDOV6FKHPDHYROXWLRQDQJHVHKHQ
Sicht
,QUHODWLRQDOHQ'DWHQEDQNV\VWHPHQ6SH]LHOOH$QVLFKWHLQHURGHU
PHKUHUHU5HODWLRQHQ,P$OOJHPHLQHQGXUFKHLQH6(/(&7
$QZHLVXQJVSH]LIL]LHUW,P8PIHOGYRQREMHNWRULHQWLHUWHQ
'DWHQEDQNV\VWHPHQH[LVWLHUWNHLQH'HILQLWLRQ9HUZDQGWHU%HJULII
Å9LHZ´
Subsystem
*OLHGHUXQJVHOHPHQWHLQHV3UREOHPEHUHLFKHV
Surrogat
2EMHNW,GHQWLILNDWRU!2EMHFW,'2,'
Taxionomie
$XVGHU%LRORJLHVWDPPHQGHU%HJULIIIUGLH.ODVVLHUXQJYRQ
9HUKDOWHQVPXVWHUQLQGHUREMHNWRULHQWLHUWHQ:HOWKlXILJGXUFKGHQ
%HJULII9HUHUEXQJHUVHW]W
UM
8QLILHG0HWKRG(UVWH9HUVLRQGHUYHUHLQKHLWOLFKWHQ
(QWZXUIVPHWKRGHYRQ*UDG\%RRFKXQG-LP5XPEDXJKYJO
>%[email protected]
UML (1)
8QLILHG0HWKRG/DQJXDJH(UVWH9HUVLRQGHUYHUHLQKHLWOLFKWHQ
(QWZXUIVPHWKRGHYRQ*UDG\%RRFK-LP5XPEDXJKXQG,YDU
-DFREVHQYJO>%[email protected]
UML (2)
252 • Glossar
Diplomarbeit
8QLILHG0RGHOLQJ/DQJXDJH9HUVLRQGHUYHUHLQKHLWOLFKWHQ
(QWZXUIVPHWKRGHYRQ*UDG\%RRFK-LP5XPEDXJKXQG,YDU
-DFREVHQYJO>%[email protected]
Diplomarbeit
Glossar • 253
Literaturverzeichnis
Referenzierte
Literatur
>[email protected]
$NVLW0HKPHW%HUJPDQV/RGHZLMN
¶2EVWDFOHVLQ2EFMHW2ULHQWHG6RIWZDUH'HYHORSPHQW·LQ2236/$
·SS
>[email protected] $WNLQVRQ0%DQFLOKRQ)'H:LWW'-
'LWWULFK.50DLHU'=GRQLN6%7KH2EMHFW2ULHQWHG'DWDEDVH
0DQLIHVWR.\RWR-DSDQ
>%[email protected]
%RRFK*UDG\2EMHFW2ULHQWHG$QDO\VLVDQG'HVLJQZLWK
$SSOLFDWLRQVQG(GLWLRQ5HGZRRG&LW\&DOLIRUQLD7KH
%HQMDPLQ&XPPLQJV3XEOLVKLQJ&RPSDQ\,QF,6%1
>%[email protected]
%RRFK*UDG\5XPEDXJK-LP8QLILHG
0HWKRGIRU2EMHFW2ULHQWHG'HYHORSPHQW80'RFXPHQWDWLRQ6HW
6DQWD&ODUD&DOLIRUQLD5DWLRQDO6RIWZDUH&RUS85/
KWWSZZZUDWLRQDOFRP
>%[email protected]
%RRFK*UDG\-DFREVHQ,YDU5XPEDXJK
-LP8QLILHG0HWKRG/DQJXDJHIRU2EMHFW2ULHQWHG'HYHORSPHQW80/
'RFXPHQWDWLRQ6HW$GGHQGXP6DQWD&ODUD&DOLIRUQLD5DWLRQDO
6RIWZDUH&RUS85/KWWSZZZUDWLRQDOFRP
>%[email protected]
%RRFK*UDG\-DFREVHQ,YDU5XPEDXJK
-LP8QLILHG0RGHOLQJ/DQJXDJH80/9HUVLRQ6DQWD&ODUD
&DOLIRUQLD5DWLRQDO6RIWZDUH&RUS85/
KWWSZZZUDWLRQDOFRP
>%[email protected]
%URGLH0/¶)XWXUHLQWHOOLJHQWLQIRUPDWLRQV\VWHPV
$,DQGGDWDEDVHWHFKQRORJLHVZRUNLQJWRJHWKHU·LQ%URGLH0/
0\ORSRXORV-(G$UWLILFLDOLQWHOOLJHQFHDQGGDWDEDVHV6DQ)UDQFLVFR
&DOLIRUQLD0RUJDQ.DXIPDQQ3XEOLVKHUV
>&[email protected]
&DWWHO5**7KH2EMHFW'DWDEDVH6WDQGDUG2'0*
5HOHDVH6DQ)UDQFLVFR&DOLIRUQLD0RUJDQ.DXIPDQQ
3XEOLVKHUV
>&KDPSHDX[@
GH&KDPSHDX['¶2EMHFW2ULHQWHG$QDO\VLV
DQ7RS'RZQ6RIWZDUH'HYHORSPHQW·LQ(XURSHDQ&RQIHUHQFHRQ
2EMHFW2ULHQWHG3URJUDPPLQJSS
>&[email protected]
&RDG3<RXUGRQ(2EMHFW2ULHQWHG
$QDO\VLVQG(GLWLRQ<RXUGRQ3UHVV&RPSXWLQJ6HULHV(QJOHZRRG
&OLIIV1-3UHQWLFH+DOO
>&[email protected]
&RDG3<RXUGRQ(2EMHFW2ULHQWHG'HVLJQ
<RXUGRQ3UHVV&RPSXWLQJ6HULHV(QJOHZRRG&OLIIV1-3UHQWLFH
+DOO
>'[email protected]
'LWWULFK.ODXV5*HSSHUW$QGUHDV
¶2EMHNWRULHQWLHUWH'DWHQEDQNV\VWHPH6WDQGGHU7HFKQLN·LQ+0'
SS
>)[email protected] )RRW%-RKQVRQ5¶'HVLJQLQJ&ODVVHV·LQ-RXUQDO
RI2EMHFW2ULHQWHG3URJUDPPLQJ-XQH-XO\SS
>*[email protected] *HSSHUW$QGUHDV2EMHNWRULHQWLHUWH'DWHQEDQNV\VWHQH
(LQ3UDNWLNXP+HLGHOEHUJGSXQNW9HUODJIUGLJLWDOH7HFKQRORJLH
*PE+,6%1
Diplomarbeit
Literaturverzeichnis • 255
>*[email protected]
*LQJULFK3.OH\Q0¶*UDSK7UDFH
8QGHUVWDQGLQJ2EMHFW2ULHQWHG6\VWHPV8VLQJ&RQFXUUHQWO\
$QLPDWHG9LHZV·LQ6,*3/$11RWLFHVSS
>*[email protected] *URWKHQ7KRPDV¶$XIGHP:HJ]XP6WDQGDUGPLW
2'0*·LQ+0'SS
>*XLOIR\[email protected] *XLOIR\OH&-HIIRFDWH-'DWDEDVHVIRU
REMHFWVWKHPDUNHWRSSRUWXQLW\/RQGRQ2YXP/WG
>[email protected]
+DUHO'¶6WDWHFKDUWV$9LVXDO)RUPDOLVPIRU
&RPSOH[6\VWHPV·LQ6FLHQFHRI&RPSXWHU3URJUDPPLQJ
>[email protected]
+HXHU$QGUHDV¶2EMHNWRHULHQWLHUWHU
'DWHQEDQNHQWZXUI·LQ,QIRUPDWLN6SHNWUXPSS
>[email protected]
+ROODQG,/LHEHUKHUU.¶$VVXULQJ*RRG
6W\OHIRU2EMHFW2ULHQWHG3URJUDPV·LQ,(((6RIWZDUH
6HSWHPEHUSS
>+XPSKUH\@+XPSKUH\:0DQDJLQJWKH6RIWZDUH3URFHVV5HDGLQJ
0$$GGLVRQ:HVOH\
>[email protected] -DFREVHQ,YDU2EMHFW2ULHQWHG6RIWZDUH(QJLQHHULQJ$
8VH&DVH'ULYHU$SSURDFK:RUNLQJKDP$GGLVRQ:HVOH\
>[email protected]
-RKQVRQ5:LUIV%URFN5¶6XUYH\LQJ
&XUUHQW5HVHDUFKLQ2EMHFW2ULHQWHG'HVLJQ·LQ&RPPXQLFDWLRQVRIWKH
$&09RO1RSS
>[email protected]
.DSSHO*6FKHUIO0¶8VLQJDQ2EMHFW
2ULHQWHG'LDJUDP7HFKQLTXHIRUWKH'HVLJQRI,QIRUPDWLRQ
6\VWHPV·LQ6RO+*YDQ+HH.0(G'\QDPLF0RGHOOLQJRI
,QIRUPDWLRQV6\VWHPV1RUWK+ROODQG(OVHYLHU6FLHQFH3XEOLVKHUV%9
SS
>[email protected]
.DSSHO*6FKHUIO0¶2EMHFW%HKDYLRU
'LDJUDPV·LQSS
>/[email protected] /LHEHUKHUU.HWDO¶*UDSK%DVHG6RIWZDUH
(QJLQHHULQJ&RQFLVH6SHFLILFDWLRQVRI&RRSHUDWLYH%HKDYLRU·LQ
+RUWKHDVWHUQ8QLYHUVLW\7HFK5HSRUW18&&6
>[email protected]
0HLHU$QGUHDV:VW7KRPDV
¶2EMHNWRULHQWLHUWH'DQWHEDQNV\VWHPH(LQ3URGXNWYHUJOHLFK·LQ
+0'SS
>[email protected]
0HOORU66KODHU62EMHFW2ULHQWHG6\VWHPV$QDO\VLV
0RGOLQJWKH:RUOGLQ'DWD<RXWGRQ3UHVV
>[email protected]%2EMHNWRULHQWLHUWH6RIWZDUHHQWZLFNOXQJ
$QDO\VHXQG'HVLJQPLWGHU8QLILHG0HWKRG/DQJXDJHDNWXDOLVLHUWH
$XIODJH0QFKHQ52OGHQERXUJ9HUODJ,6%1
>[email protected] 3HWHULFK(FNDUW*|WWHUXQG+HOGHQGHU*ULHFKHQ
)UDQNIXUWD0)LVFKHU%FKHUHL
>[email protected] 5XPEDXJK-%ODKD03UHPHUODQL:
(GG\)/RUHQVHQ:2EMHFW2ULHQWHG0RGHOLQJDQG'HVLJQ
(QJOHZRRG&OLIIV1-3UHQWLFH+DOO
>[email protected]
6KHDU'¶&$6(6KRZV3URPLVHEXW&RQIXVLRQ6WLOO
([LVWV·LQ('1SS
>:[email protected]:KLWHKHDG$$Q,QWURGXFWLRQWR0DWKHPDWLFV1HZ
<RUN1<2[IRUG8QLYHUVLW\3UHVV
>:LUIV%[email protected]
:LUIV%URFN55HVSRQVDELOLW\'ULYHQ$SSURDFK
(QJOHZRRG&OLIIV1-3UHQWLFH+DOO
256 • Literaturverzeichnis
Diplomarbeit
Dokumentationen
>+DUG\,[email protected] +DUG\,QVWDOODWLRQ,QVWUXFWLRQV$UWLILFLDO
,QWHOOLJHQFH$SSOLFDWLRQV,QVWLWXWH8QLYHUVLW\RI(GLQEXUJK
(GLQEXUJK8.$SULO85/KWWSUKXP
HJRDLDLHGDFXN∼KDUG\
>+DUG\[email protected]
+DUG\8VHU*XLGH9HUVLRQ6PDUW-XOLDQ
5DH5REHUW$UWLILFLDO,QWHOOLJHQFH$SSOLFDWLRQV,QVWLWXWH8QLYHUVLW\
RI(GLQEXUJK(GLQEXUJK8.)HEUXDU85/KWWSUKXP
HJRDLDLHGDFXN∼KDUG\
>[email protected] 7KH26\VWHP$GPLQLVWUDWLRQ*XLGH9HUVLRQ2
7HFKQRORJ\9HUVDLOOHV)UDQNUHLFK$SULO
>[email protected] 27RROV8VHU0DQXDO9HUVLRQ27HFKQRORJ\
9HUVDLOOHV)UDQNUHLFK$SULO
>80/6XPPDU\@ 80/6XPPDU\
>80/[email protected] 80/1RWDWLRQ*XLGH
>80/[email protected] 80/6HPDQWLFV
>80/([[email protected] 80/3URFHVV6SHFLILF([WHQVLRQV
Weitere
Literatur
&DWWHOO5**2EMHFW'DWD0DQDJHPHQW0HQOR3DUN&DOLIRUQLD
$GGLVRQ:HVOH\3XEOLVKLQJ&RPSDQ\,6%1
&DWWHO5**7KH2EMHFW'DWDEDVH6WDQGDUG2'0*5HOHDVH
6DQ)UDQFLVFR&DOLIRUQLD0RUJDQ.DXIPDQQ3XEOLVKHUV
'LWWULFK.ODXV5¶2EMHFW2ULHQWHG'DWD0RGHO&RQFHSWV·LQ
&RPSXWHUDQG6\VWHP6FLHQFHV%HUOLQ6SULQJHU9HUODJ
'LWWULFK.ODXV5*HSSHUW$QGUHDV¶6SFLILFDWLRQDQG
,PSOHPHQWDWLRQRI&RQVLVWHQF\&RQVWUDLQWVLQ2EMHFW2ULHQWHG
'DWDEDVH6\VWHPV$SSO\LQJ3URJUDPPLQJE\&RQWUDFW·LQ*,
&RQIHUHQFH'DWHQEDQNV\VWHPHLQ%UR7HFKQLNXQG:LVVHQVFKDIW%7:
'UHVGHQ
'LWWULFK.ODXV5*HSSHUW$QGUHDV¶2EMHNWVWUXNWXUHQLQ
'DWHQEDQNV\VWHPHQRGHU$XIGHU6XFKHQDFKYROOHU
2EMHNWRULHQWLHUXQJ·LQSS
)LVFKHU:(.VSHUW.3XSSH)¶2EMHNWRULHQWLHUWH
'DWHQEDQNV\VWHPH·LQ,QIRUPDWLN6SHNWUXPSS
+XJHV-*2EMHNWRULHQWLHUWH'DWHQEDQNHQ0QFKHQ(QJOHZRRG
&OLIIV+DQVHU3UHQWLFH+DOO,6%1
.HPSHU$0RHUNRWWH*¶%DVLVNRQ]HSWHREMHNWRULHQWLHUWHU
'DWHQEDQNV\VWHPH·LQ,QIRUPDWLN6SHNWUXPSS
0DW\WVFKDN0LUNR¶80/(LQH1RWDWLRQIUGDV6RIWZDUH'HVLJQ·
LQ0LFURVRIW6\VWHP-RXUQDOSS
0H\HU%2EMHFW2ULHQWHG6RIWZDUH&RQVWUXFWLRQ(QJOHZRRG&OLIIV1-
3UHQWLFH+DOO
3DUN(.6RQJ,O<HRO¶2EMHFW2ULHQWHG'DWDEDVH'HVLJQ
0HWKRGRORJLHV$6XUYH\·LQSS
6FKPLGW'3HUVLVWHQWH2EMHNWHXQGREMHNWRULHQWLHUWH'DWHQEDQNHQ
.RQ]HSWH$UFKLWHNWXUHQ,PSOHPHQWLHUXQJXQG$QZHQGXQJ0QFKHQ
+DQVHU,6%1
:VW7KRPDV¶22'%06(LQVDW]EHLGHU&669HUVLFKHUXQJ·LQ
,QIRUPDWLN,QIRUPDWLTXHSS
Diplomarbeit
Literaturverzeichnis • 257
Dokumentationen
2&5HIHUHQFH0DQXDO27HFKQRORJ\9HUVDLOOHV)UDQNUHLFK0lU]
2.LW9HUVLRQ27HFKQRORJ\9HUVDLOOHV)UDQNUHLFK$SULO
2/RRN9HUVLRQ27HFKQRORJ\9HUVDLOOHV)UDQNUHLFK$SULO
7KH28VHU0DQXDO9HUVLRQ27HFKQRORJ\9HUVDLOOHV
)UDQNUHLFK'H]HPEHU
258 • Literaturverzeichnis
Diplomarbeit
Verzeichnisse
Abbildungen
Abbildung 1-1: ODMG-Datenbank mit C++ Anbindung [Grotehen 95, p. 51]
16
Abbildung 2-1: Die Modelle des objektorientierten Entwurfes [Booch 94, p.
172]
30
Abbildung 4-1: Datenbankklassen im Schemadiagramm
77
Abbildung 4-2: Hilfsklassen im Schemadiagramm
78
Abbildung 4-3: Schemadiagramm mit Vererbung
79
Abbildung 4-4: abstrakte Klassen im Schemadiagramm
80
Abbildung 4-5: Schemadiagramm mit persistentem Einstiegspunkt
82
Abbildung 4-6: Schemadiagramm mit Komponentenbeziehungen
88
Abbildung 4-7: Schemadiagramm mit inversen Beziehungen 90
Abbildung 4-8: Schemadiagramm mit Beobachtungsbeziehung 92
Abbildung 4-9: Schemadiagramm mit Objektevolution
96
Abbildung 4-10: Subsystemdiagramm für die Anwendung FIS 101
Abbildung 4-11: Transaktionsdiagramm für das Subsystem
„Mitarbeiterverwaltung“
102
Abbildung 4-12: Beispiel Konferenzadministration: erster Entwurf
104
Abbildung 4-13: Objektdiagramm einer bestimmten Situation 104
Abbildung 4-14: Schemadiagramm mit Papier als Komponente der Konferenz
105
Abbildung 4-15: Schemadiagramm mit komponentenbeziehungsbasierter
rekursiver Aggregation
105
Abbildung 4-16: Schemadiagramm mit rekursiver Aggregation, basierend auf
inverser Beziehung
106
Abbildung 4-17: Schemadiagramm für die Konferenzadministration mit
globalem Sammelobjekt
106
Abbildung 4-18: Schemadiagramm für die Konferenzadministration mit
Extension
108
Abbildung 5-1: Hauptfenster von OSWOOD 126
Abbildung 5-2: Copyright Informationen von Hardy 128
Abbildung 5-3: Hauptfenster von Hardy
128
Abbildung 5-4: Die Diagrammtypen von DEIMOS 130
Abbildung 5-5: Kartenansicht in Hardy
131
Abbildung 5-6: Beispiel eines Kontextdiagramms
133
Abbildung 5-7: Beispiel eines Schemadiagramms
136
Abbildung : Beispiel eines Transaktionsdiagramms (Systemübersicht) 139
Abbildung 5-8: Beispiel eines Transaktionsdiagramms (Subsystemexpandsion)
139
Abbildung 5-9: Auswahl einer Indexdatei in OSWOOD
140
Abbildung 5-10: Darstellung einer Indexdatei von Hardy in OSWOOD 141
Abbildung 5-11: Darstellung eines Schemadiagramms in OSWOOD
142
Abbildung 5-12: Komponentenbaum eines Schemadiagrammes
143
Abbildung 5-13: Vererbungshierarchie in einem Schemadiagramm
144
Abbildung 5-14: Klassenansicht in einem Schemadiagramm 144
Abbildung 5-15: Darstellung der Konstruktoren und Destruktoren
145
Abbildung 5-16: Darstellung der benutzerdefinierten Attribute 145
Abbildung 5-17: Darstellung der Methoden 146
Abbildung 5-18: Darstellung der Komponentenbeziehungen 146
Abbildung 5-19: Darstellung der inversen Beziehungen
146
Abbildung 5-20: Darstellung der Objektevolutionen 147
Abbildung 5-21: Darstellung der Beobachtungsbeziehungen 147
Abbildung 5-22: Darstellung einer Klassendefinition in der ODL-Ansicht
147
Diplomarbeit
Verzeichnisse • 259
Abbildung 5-23: Darstellung einer Methodenimplementation in der ODLAnsicht
148
Abbildung 5-24: Transaktionsdiagramm in OSWOOD
148
Abbildung 5-25: Darstellung der Aufrufhierarchien in OSWOOD
149
Abbildung 5-26: Darstellung einer O2C-Datei in OSWOOD 151
Abbildung 6-1: Schemadiagramm mit „loser“ Verbindung
186
Abbildung 6-2: Schemadiagramm mit „loser“ Verbindung
186
Tabellen
Tabelle 1-1: Objektorientierung und Modelleigenschaften
19
Tabelle 1-2: Modell und Integrität 19
Tabelle 1-3: Datenbank- und Abfragesprachen
20
Tabelle 1-4: Komponenten der Systemaritektur
20
Tabelle 5-1: Knoten in einem Kontextdiagramm
132
Tabelle 5-2: Knotenkonstrukte in einem Schemadiagramm
134
Tabelle 5-3: Kantenkonstrukte in einem Schemadiagramm
135
Tabelle 5-4: Matrix der möglichen Knotenverbindungen in einem
Schemadiagramm
136
Tabelle 5-5: Knotenkonstrukte in einem Transaktionsdiagramm
Tabelle 5-6: Kantenkonstrukte in einem Transaktionsdiagramm
Tabelle 5-7: Matrix der möglichen Knotenverbindungen in einem
Transaktionsdiagramm
138
Tabelle 5-8: Diagrammtypen in einer Indexdatei
141
Tabelle 5-9: Die Klassensymbole im Komponentenbaum
143
Tabelle 5-10: Symbole ein einer Klassenansicht
145
Tabelle 5-11: Symbole in der hierarchischen Ansicht eines
Transaktionsdiagramms
149
137
138
Listings
Listing 6-1: Beispiel eines Einstiegspunktes 145
Listing 6-2: Beispiel einer Definition eines Einstiegspunktes 145
Listing 6-3: Datenbankklasse in Hardydatei 146
Listing 6-4: Definition einer Datenbankklasse in O2C 147
Listing 6-5: Virtuelle Methode IsValid() für die Klasse Company
150
Listing 6-6: Virtuelle Methode IsConsistent() für die Klasse Company 150
Listing 6-7: Virtuelle Methode Init() für die Klasse Company 151
Listing 6-8: Virtuelle Methode Create() für die Klasse Company
151
Listing 6-9: Virtuelle Methode Destroy() für die Klasse Company
151
Listing 6-10: Explizite Methode SetSallery() in der Klasse Company 152
Listing 6-11: Vererbungspfeil in einer Hardydatei
153
Listing 6-12: Vererbungsbeziehung in der Schemadefinitionsdatei
153
Listing 6-13: Beispiel einer Komponentenbeziehung in der Hardydatei 154
Listing 6-14: Implementation der Methode AddDevloper() in der Klasse
Company
156
Listing 6-15: Implementation der Methode AddRefDevloper() in der Klasse
Company
156
Listing 6-16: Implementation der Methode CreateDevloper() in der Klasse
Company
156
Listing 6-17: Implementation der Methode RemoveDevloper() in der Klasse
Company
156
Listing 6-18: Implementation der Methode DestroyDevloper() in der Klasse
Company
157
Listing 6-19: Implementation der Methode FindDevloper() in der Klasse
Company
157
Listing 6-20: Implementation der Methode AddOffice() in der Klasse Company
157
260 • Verzeichnisse
Diplomarbeit
Listing 6-21: Implementation der Methode AddRefOffice() in der Klasse
Company
158
Listing 6-22: Implementation der Methode CreateOffice() in der Klasse
Company
158
Listing 6-23: Implementation der Methode RemoveOffice() in der Klasse
Company
158
Listing 6-24: Implementation der Methode DestroyOffice() in der Klasse
Company
158
Listing 6-25: Implementation der Methode FindOffice() in der Klasse Company
159
Listing 6-26: Beispiel einer inversen Beziehung in der Hardydatei
159
Listing 6-27: Implementation der Methode AttachOffice() in der Klasse
Employee
160
Listing 6-28: Implementation der Methode DetachOffice() in der Klasse
Employee
161
Listing 6-29: Implementation der Methode AttachInverseOffice() in der Klasse
Employee
161
Listing 6-30: Implementation der Methode DetachInverseOffice() in der Klasse
Employee
161
Listing 6-31: Implementation der Methode AttachEmployee() in der Klasse
Office
161
Listing 6-32: Implementation der Methode DetachEmployee() in der Klasse
Office
162
Listing 6-33: Implementation der Methode AttachInverseEmployee() in der
Klasse Office
162
Listing 6-34: Implementation der Methode DetachInverseEmployee() in der
Klasse Office
162
Listing 6-35: Beispiel eines Instantiierungspfeil in der Hardydatei
163
Listing 6-36: Beispiel einer Evolutionsbeziehung in der Hardydatei
163
Listing 6-37: Implementation der Methode EvolveDeveloperToManager() in der
Klasse Company
164
Listing 6-38: Implementation der Methode AssignDeveloperToManager() in der
Klasse Company
164
Listing 6-39: Beispiel einer Beobachtungsbeziehung in der Hardydatei 165
Listing 6-40: Die Methode UpdateOffice in der Klasse OfficeList
165
Listing 6-41: Beispiel einer Applikation in der Hardydatei
167
Listing 6-42: Definition der Applikation FIS 167
Listing 6-43: Beispiel eines Programmes in der Hardydatei
168
Listing 6-44: Implementation des Programmes HireDeveloper() in der
Applikation FIS
169
Listing 6-45: Beispiel einer Funktion in der Hardydatei
170
Listing 6-46: Definition der Funktion SelectDev() in der Applikation FIS
171
Listing 6-47: Beispiel einer Transaktion in der Hardydatei
172
Listing 6-48: Definition der Transaktion MakeManager() in der Applikation FIS
174
Listing 6-49: Beispiel eines Aufrufes in der Hardydatei
175
Listing 7-1: Definition der Klasse CHardyFile
182
Listing 7-2: Lesen einer Hardydatei 183
Listing 7-3: Lesen einer Sektion
183
Listing 7-4: Definition der Klasse CDiagramCard
186
Listing 7-5: Einfügen eines Elementes in das Indexdokument 186
Listing 7-6: Klassendefinition von CSchemaDoc
192
Listing 7-7: Klassendefinition von CItem
196
Listing 7-8: Klassendefinition von CNode 197
Listing 7-9: Klassendefinition von CEntryPoint
197
Listing 7-10: Klassendefinition von CClass 199
Listing 7-11: Klassendefinition von CDatabaseClass 200
Listing 7-12: Klassendefinition von CAbstractClass 200
Diplomarbeit
Verzeichnisse • 261
Listing 7-13: Klassendefinition von CClassUtility
200
Listing 7-14: Klassendefinition von CArc 201
Listing 7-15: Klassendefinition von CComponentArc 201
Listing 7-16: Klassendefinition von CInverseRelationArc
202
Listing 7-17: Klassendefinition von CInstantiationArc202
Listing 7-18: Klassendefinition von CObserverArc 202
Listing 7-19: Klassendefinition von CEvolutionArc 202
Listing 7-20: Klassendefinition von CInheritanceArc 203
Listing 7-21: Klassendefinition von CGraph 205
Listing 7-22: Klassendefinition von CGraphNode
206
Listing 7-23: Aufbau eines visuellen Baumes206
Listing 7-24: Klassendefinition von CGraph 207
Listing 7-25: Funktion CreateInheritanceHierarchy (Vorbereitungen) 208
Listing 7-26: Funktion CreateInheritanceHierarchy (Suche nach den Urvätern)
209
Listing 7-27: Funktion CreateInheritanceHierarchy (rekursives Füllen des
Graphen)
210
Listing 7-28: Funktion AddDerivedClasses (rekursives Füllen des Graphen)
211
Listing 7-29: Funktion CreateInheritanceHierarchy (Hinzufügen der
verbleibenden Klassen)
211
Listing 7-30: Funktion CreateComponentTree (Suche nach den Wurzelobjekten)
212
Listing 7-31: Funktion CreateComponentTree (Rekursives Füllen)
213
Listing 7-32: Funktion AddComponents (Rekursives Füllen) 213
Listing 7-33: Funktion CreateComponentTree (restliche Klassen)
214
Listing 7-34: Klassendefinition von CClass 218
Listing 7-35: Klassendefinition von CRelation
219
Listing 7-36: Methode CreateInverseRelations() in CSchemaDoc
220
Listing 7-37: Methode CreateInverseRelation() in CClass
220
Listing 7-38: Methode Create() in CInverseRelation 221
Listing 7-39: Methode CreateInverseRelation() in CClass
221
Listing 7-40: Kopf einer ODL-Datei
223
Listing 7-41: Definition der Einstiegspunkte in der ODL-Datei 223
Listing 7-42: Klassendefinition und -implementation in der ODL-Datei 223
Listing 7-43: Klassendefinition von CTransDoc
227
Listing 7-44: Klassendefinition von CProgram
230
Listing 7-45: Methode CreateCallHierarchy() der Klasse CTransDoc 231
Listing 7-46: Methode CreateCallHierarchy(...) der Klasse CTransDoc 231
Listing 7-47: Methode AddCall(...) der Klasse CProgram
232
Listing 7-48: Methode CreateMethodCalls(...) der Klasse CProgram
232
Listing 7-49: Methode CreateSubSystemHierarchy(...) der Klasse CTransDoc
233
Listing 7-50: Methode CreateImplementation(...) der Klasse CTransDoc
234
Listing 7-51: Applikationsdefinition in der ODL-Datei
234
Listing 7-52: Programme, Funktionen und Transaktionen in der ODL-Datei
235
Listing 7-1: Die Dateien mit den Definitionen der Symbole und Diagramme
255
Syntaxdiagramme
Syntaxdiagramm 1-1: Interfacedefinition mit ODMG 93-ODL 12
Syntaxdiagramm 6-1: Klassendefinition in O2C
156
Syntaxdiagramm 6-2: Methodendefinition in O2C
160
Syntaxdiagramm 6-3: Syntax einer Applikationsdefinition in O2C
Syntaxdiagramm 6-4: Programmdefinition in O2C
178
262 • Verzeichnisse
177
Diplomarbeit
Syntaxdiagramm 6-5: Functionsdefinition in O2C
180
Syntaxdiagramm 6-6: Transaktionsdefinition in O2C 182
Syntaxdiagramm 7-1: Dateiformat einer Hardydatei 190
Syntaxdiagramm 7-2: Format einer Schemadiagrammdatei
Syntaxdiagramm 7-3: Syntax einer Schemadiagrammdatei
Syntaxdiagramm 7-4: Syntax einer Schemadiagrammdatei
194
198
234
Klassendiagramme
Klassendiagramm 7-1: Klassen für die Umsetzung einer Hardydatei
191
Klassendiagramm 7-2: Klassen für die Umsetzung einer Indexdatei
195
Klassendiagramm 7-3: Einbettung der Schemadiagrammklassen
199
Klassendiagramm 7-4: Klassen für die Abbildung eines Schemadiagramms
203
Klassendiagramm 7-5: Klassen für den Aufbau der Graphen 214
Klassendiagramm 7-6: Klassen für die Modellierung einer ‘Klasse’
225
Klassendiagramm 7-7: Einbettung der Transaktionsdiagrammklassen 235
Klassendiagramm 7-8: die Klassen eines Transaktionsdokumentes
238
Klassenbeschreibungen
Klassenbeschreibung 7-1: CHardyFile
Klassenbeschreibung 7-2: CDiagramCard
Klassenbeschreibung 7-3: CSchemaDoc
Klassenbeschreibung 7-4: CItem 205
Klassenbeschreibung 7-5: CNode 207
Klassenbeschreibung 7-6: CEntryPoint
Klassenbeschreibung 7-7: CClass 208
Klassenbeschreibung 7-8: CArc
210
Klassenbeschreibung 7-9: CGraph 214
Klassenbeschreibung 7-10: CGraphNode
Klassenbeschreibung 7-11: CClass 227
Klassenbeschreibung 7-12: CRelation
Klassenbeschreibung 7-13: CTransDoc
Klassenbeschreibung 7-14: CProgram
Diplomarbeit
192
196
201
207
215
229
237
239
Verzeichnisse • 263
Index
264 • Index
Diplomarbeit
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement