Konzeptuelle Datenmodellierung Ein Modelltransfer von UML nach XML DIPLOMARBEIT von Wolfgang Bartels Betreuer: Dr. Rainer Eckstein

Humboldt Universität zu Berlin Institut für Informatik

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:06:40

Seite i

Inhaltsverzeichnis Kapitel 1 Einleitung....................................................................................1 1.1 Zielstellung........................................................................................1 1.2 Arbeiten zu diesem Thema................................................................3 1.3 Konventionen und Notationen..........................................................3 1.3.1 Konventionen............................................................................3 1.3.2 Notationen.................................................................................4 Kapitel 2 Konzeptuelle Datenmodellierung................................................5 2.1 Relevante Konzepte der UML...........................................................6 2.1.1 Klassen und deren Attribute......................................................7 2.1.2 Pakete........................................................................................10 2.1.3 Beziehungen..............................................................................11 2.1.4 Kommentare..............................................................................16 2.1.5 Der Erweiterungsmechanismus der UML.................................16 2.2 Relevante Konzepte der XML...........................................................18 2.2.1 DTD...........................................................................................18 2.2.2 XLink.........................................................................................20 2.2.3 XML-Schema............................................................................22 Kapitel 3 Transformationen vom UML-Modell zur DTD..........................25 3.1 Direkte Modelltransformation...........................................................26 3.1.1 Klassen, Pakete und Attribute...................................................26 3.1.2 Beziehungen..............................................................................32 3.1.3 UML-Kommentare....................................................................56 3.1.4 Abhängigkeiten..........................................................................58 3.1.5 Bewertung der Transformationskonzepte..................................59 3.2 Indirekte Transformation...................................................................62 3.2.1 Das DTD-Profil.........................................................................62 3.2.2 Der Übergang vom Datenmodell ..............................................zum DTD-Metamodell ..............................................................................84 3.2.3 Bewertung des DTD-Profils......................................................88

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:06:40

Seite ii

Kapitel 4 XML Schema..............................................................................90 4.1 abstrakte, finale und innere Klassen..................................................90 4.2 Aggregationen und Kompositionen..................................................92 4.3 Einfachvererbung..............................................................................92 Kapitel 5 Zusammenfassung.......................................................................96 Kapitel 6 Ausblicke.....................................................................................98 6.1 Offene Probleme...............................................................................98 6.2 Der Objektansatz...............................................................................98 6.3 Erweiterungen des DTD-Profils........................................................100 Abbildungsverzeichnis.................................................................................i Tabellenverzeichnis.....................................................................................iii Glossar und Abkürzungsverzeichnis............................................................iv Literaturverzeichnis.....................................................................................x

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 1 Einleitung

1

KAPITEL 1 EINLEITUNG 1.1 ZIELSTELLUNG XML spielt im Bereich des Datenaustauschs im Internet eine zentrale Rolle. Jedoch stellt die Modellierung dieser Daten immer noch ein Problem dar, da diesbezüglich kaum Konzepte vorliegen. Als Modell für eine XML Dokumenteninstanz dienen DTDs und XML Schemata, welche in dieser Arbeit fortan als Dokumentenmodelle bezeichnet werden. Die Erstellung eines derartigen Dokumentenmodells erfolgt oftmals über einen der folgenden Wege 1. Das Dokumentenmodell wird mithilfe eines Texteditors erzeugt. 2. Es liegen bereits eine oder mehrere Dokumentinstanzen vor. Mithilfe eines DTD-Generators (wie z.B. Xeena) wird ein DTD-Prototyp erzeugt, der manuell mithilfe eines Editors „feinjustiert“ wird. 3. Man erzeugt das Dokumentenmodell mit Hilfe eines Werkzeugs, welches die entsprechenden Konzepte meist nur bruchstückhaft umsetzt. Bei XML Schemata ist dies meist ein XML-Editor (wie z.B. das XMLNotePad), bzw. Modellierungswerkzeuge, welche nicht standardisierte Diagramme mit stark eingeschränktem Konzeptumfang anbieten (z.B. das XML-Diagramm im Modellierungswerkzeug Together 5.0).

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 1 Einleitung

2

Der zuletzt genannte Weg ist zwar ein korrekter Ansatz, jedoch sind bisher zum einen zu wenige Konzepte aus den XML-Dokumentmodellen direkt modellierbar, zum anderen gibt es bisher keine umfassenden Konzepte, um aus einem Modell einer anderen Modellierungssprache (wie z.B. UML, ERM) eine DTD oder ein XML-Schema zu generieren. Es stellt sich natürlich die Frage "Welchen Sinn macht es, XML-Daten mit Hilfe der UML zu modellieren ?". Hierfür gibt es mehrere Antworten: 

Zu Beginn der Modellierung weiß man unter Umständen gar nicht, wie die auftretenden Daten dargestellt werden sollen.



Es werden nicht alleine die Daten eines Systems modelliert, sondern auch andere Bestandteile. Da die UML inzwischen im Bereich objektorientierter Softwareentwicklung stark verbreitet ist, werden große Teile eines zu bearbeitenden bzw. erstellenden Systems in dieser Sprache modelliert. Die Verwendung mehrerer Modellierungssprachen erschwert den Entwicklungsprozess.



Wählt man den direkten Weg zum Dokumentenmodell, läuft man Gefahr, die Problemdomäne aus den Augen zu verlieren.

Ziel dieser Arbeit ist es, einen Weg zu zeigen, der ein konzeptuelles Datenmodell in Form eines UML-Klassendiagramms in ein Dokumentenmodell überführt. Dieser Weg besteht aus zwei Schritten: 1. direkter Modelltransfer; hierbei werden alle relevanten UML-Modellelemente in Bestandteile eines Dokumentenmodells überführt. Das Ergebnis dient als Grundlage eines Reviews. 2. Metamodellierung des Dokumentenmodells; mit Hilfe des korrigierten Klassendiagramms aus dem ersten Schritt wird nun ein adäquates Metamodell vom Modellierer erstellt. Der Zweck dieses Schrittes besteht darin, ineffiziente Transformationen zu vermeiden. Die geschieht, indem die verwendeten Modellelemente an Konzepte der Dokumentmodelle angepasst werden bzw. durch adäquatere Modellelemente ausgetauscht werden.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 1 Einleitung

3

1.2 ARBEITEN ZU DIESEM THEMA Diese

Arbeit

ist

eine

Fortführung

der

Arbeiten

[ConSchef2000]

und [ConSchef2001]. Die dort erarbeiteten Ergebnisse werden in dieser Arbeit aufgegriffen, überarbeitet und erweitert. Ebenso werden Alternativen aufgezeigt, welche stärker auf Details der Spezifikation [UML1.4] eingehen. Ein Ansatz, der sich mit der Überführung von DTD in XML-Schemata befasst, wird in [Booch99] vorgestellt. Er zeigt, wie man mit Hilfe des UML-Erweiterungsmechanismus eine DTD modelliert und anschließend in ein XML-Schema überführt. Es werden jedoch nicht alle Konzepte, die man in Dokumentenmodellen finden kann, ausreichend unterstützt. Beispiele hierfür sind Anweisungen, die Kapselung von Markupdeklarationen bzw. Teilen davon in Parameterentitäten, Verschachtelung von Entitäten u.ä. [KleinLip01] ist eine Arbeit, die ähnliche Ziele im Bereich ERM verfolgt. Jedoch wird aus einem Schema eine Dokumenttypdeklaration erzeugt. Diese Transformation schränkt jedoch die Wiederverwendbarkeit ein. Des weiteren werden Assoziationen zwischen ERM-Entitäten als Inhaltsspezifikation einer beteiligten ERM-Entität aufgefasst.

1.3 KONVENTIONEN UND NOTATIONEN 1.3.1 KONVENTIONEN Die Menge boolean ist die Menge {true, false}. Das SPACE-Zeichen wird in Darstellungen von Strings durch das Zeichen „⋅“ repräsentiert.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 1 Einleitung

4

1.3.2 NOTATIONEN normaler Text wird in Times New Roman gesetzt

Bei der Frage „Was ist konzeptuelle Datenmodellierung ?“ stößt man...

Neu definierte Begriffe bzw. Begriffe anderer Arbeiten, welche erläutert werden, sind im Text fett dargestellt.

...eines sogenannten Metamodells - d.h. einem Modell für Modelle -...

Zitate werden kursiv geschrieben und in doppelten Anführungszeichen gesetzt.

„conceptual modelling portrays ..“

Mengensymbole werden GROSS geschrieben. Variablen bzw. Elemente einer Menge werden klein und kursiv dargestellt.

Sei m  M ein Matchpoint

Besondere Mengen und besondere Elemente von Mengen werden in Monotype Corsiva fett dargestellt.

Die Menge V beinhaltet alle Knoten des Textgraphen.

Zeichen in Form von Buchstaben oder Sonderzeichen werden in Arial gesetzt.

Das SPACE-Zeichen. Das Zeichen [ Der Buchstabe b

Erzeugte XML-Texte werden in Courier New und grauem Hintergrund gesetzt. Zusicherungen, Entitätsreferenzen, Eigenschaftswerte, sowie die Bezeichner von Klassen, Attributen, Merkmalen und Beziehungen werden in Arial kursiv gesetzt.



Eine abstrakte Klasse trägt die Zusicherung abstract

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

5

KAPITEL 2 KONZEPTUELLE DATENMODELLIERUNG Bei der Frage „Was ist konzeptuelle Datenmodellierung ?“ stößt man bei [Halpin01] auf folgende Erklärungen: „conceptual modelling portrays the application domain at high level, ... , ignoring logical- and physicallevel aspects ... and external-level aspects ...“. [Vossen2000] besagt, dass der konzeptuelle Entwurf einer Applikation DBMS-unabhängig sein muss. Des weiteren „... besteht die Aufgabe des Designers grundsätzlich darin, eine konzeptionelle Globalsicht der betreffenden Anwendung zu erstellen.“. Bei [Kemper01] finden wir drei Abstraktionsebenen des Entwurfs vor. Die konzeptuelle Ebene, die Implementationsebene und die physische Ebene. „Die konzeptuelle Ebene dient dazu, den projektierten Anwendungsbereich zu strukturieren. ... und es sollte auch nur die Anwendersicht (im Gegensatz zur Realisierungssicht) modelliert werden.“. Das bedeutet für die konzeptuelle Datenmodellierung: 1. Konzentration auf jene Sicht bzw. Sichten, welche der bzw. die Anwender auf den Anwendungsbereich hat/haben. 2. Die Datenstrukturen stehen im Mittelpunkt des Interesses. Das Verhalten der Objekte ist zweitrangig. 3. Sowohl physische als auch implementierungsabhängige Aspekte werden ignoriert.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

6

Die folgenden Abschnitte beschäftigen sich mit der UML und der XML. Dabei wird geklärt, worum es sich bei der UML handelt, und warum diese Modellierungssprache ausgewählt wurde. Anschließend werden alle für diese Arbeit relevanten Konzepte der UML , wie z.B. Klassen, Pakete, Beziehungen usw., vorgestellt und ihre für diese Arbeit wichtigen Eigenschaften hervorgehoben. Anschließend befasst sich diese Arbeit mit den für diese Arbeit relevanten Konzepten der XML. Ergänzend werden wichtige Bestandteile der Spezifikationen für XLink und XML-Schema vorgestellt.

2.1 RELEVANTE KONZEPTE DER UML Die UML ist eine visuelle Sprache, mit deren Hilfe objektorientierte Softwaresysteme modelliert werden können. Visuell bedeutet dabei, dass die Modelle durch eine grafische Darstellung geprägt sind. Die Sprache bietet die Möglichkeit statische, dynamische und Verteilungsaspekte in ein Modell einzubinden. Des weiteren bietet sie für die Modellierung eines Softwaresystems verschiedene Sichten mit Hilfe von Diagrammen. Aus den Erkenntnissen des vorherigen Kapitels kann man schließen, dass Sequenz-, Zustands-, Kollaborations-, Aktivitäts- und das Anwendungsfalldiagramm keine Rolle in der konzeptuellen Datenmodellierung spielen, da ihr Schwerpunkt auf der Modellierung dynamischer Systemaspekte liegt. Von den Diagrammen, die sich mit den statischen Aspekten eines Systems beschäftigen, entfallen Komponenten- und Einsatzdiagramm, da sie sich mit der architektonisch-physischen Seite des Systems beschäftigen. Es bleiben also das Klassen- und das Objektdiagramm übrig, wobei sich diese Arbeit überwiegend auf das Klassendiagramm konzentriert. Die UML ist eine Sprache, die mit Hilfe eines sogenannten Metamodells d.h. einem Modell für Modelle - definiert wird. Dieses Metamodell und die vom Softwareentwickler erarbeiteten Modelle sind Bestandteile einer VierSchichten-Metamodell-Architektur, die im Abschnitt 2.2 Language Architecture in [UML1.4] näher erläutert wird. In diesem Abschnitt werden jene

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

7

Bestandteile des Metamodells erläutert, die sowohl in Klassendiagrammen ihre Anwendung finden, als auch für diese Arbeit relevant sind.

2.1.1 KLASSEN UND DEREN ATTRIBUTE Klassen und Objekte sind zentrale Konzepte in der objektorientierten Modellierung. Objekte repräsentieren Objekte, Personen und Ideen der Anwendungsdomäne, während Klassen Objekte mit gleichen bzw. ähnlichen Eigenschaften, Beziehungen und Verhalten zusammenfassen. Klassen können abstrakt sein, d.h. es können keine Instanzen dieser Klasse erzeugt werden. Der lokale Name einer Klasse ist eindeutig innerhalb des Paketes, in dem sich die Klasse befindet. Der vollständige Name einer Klasse setzt sich aus dem lokalen Namen und einem Präfix, welches aus den Namen der umschließenden Pakete, zusammen. In der UML kann die Wahl des Trennzeichens zwischen den Paketnamen durch den Kontext des Modells festgelegt werden. D.h. der Modellierer kann das Trennzeichen an die Zielumgebung anpassen. Normalerweise werden zwei aufeinander folgende Doppelpunkte („::“) verwendet. Klassen besitzen u.a. die Metaattribute isAbstract und isLeaf, welche für die Generalisierung, die im Abschnitt 2.1.3 Generalisierung näher erläutert wird, relevant sind. IsLeaf beinhaltet einen Wahrheitswert, welcher im Fall von true angibt, dass die betreffende Klasse nicht spezialisiert werden kann. Derartige Klassen können jedoch mit Hilfe des UML-Erweiterungsmechanismus (s. Abschnitt 2.1.5) semantisch erweitert werden. Sie werden innerhalb dieser Arbeit als finale Klassen bezeichnet. Das Metaattribut isAbstract gibt an, ob die betreffende Klasse abstrakt ist. Abstrakte Klassen sind nicht instanziierbar, d.h. es können keine Objekte dieses Typs gebildet werden. Es gibt zwei Arten abstrakter Klassen: 

explizit abstrakte Klassen, das sind Klassen, deren Metaattribut isAbstract den Wert „true“ haben, und

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung



8

implizit abstrakte Klassen, dies sind u.a. Klassen, für die eine Menge von Generalisierungen existiert, bei denen diese Klasse parent ist, welche die Zusicherung complete trägt (s. [UML1.4]).

Attribute stellen die Eigenschaften innerhalb einer Klasse dar. In der objektorientierten Modellierung sind Attribute jene Daten, welche von der Klasse gekapselt werden. Bei der Identifizierung von Attributen schlagen [CoadYourdon91] vor, nur sogenannte atomare Konzepte zu verwenden. Atomare Konzepte sind hierbei elementare Datenelemente bzw. Gruppen von eng verwandten Datenelementen. Beispielsweise bilden Vorund Zuname, sowie ein Titel die Gruppe „Name“. In [Rumbaugh91] wird sogar gefordert, dass Attribute eines Objektes reine Datenwerte enthalten sollten. Im Gegensatz dazu wird in [BoochRumbJacob] die Beziehung zwischen Attribut und Klasse als Komposition eingestuft, was jedoch nur bedingt richtig ist. Genauer gesagt handelt es sich hierbei um eine Komposition auf Metamodellebene. Die Attribute einer Klasse sind demnach feste Bestandteile der Klasse, der sie angehören. Demnach ist die Beziehung zwischen Attribut und Klasse zwar der Komposition auf Modellebene ähnlich, jedoch ist die Eigentumsbeziehung in dieser Beziehung ist wesentlich stärker als jene der Komposition. In der UML hat ein Attribut u.a. folgende Bestandteile: 1. ein Namen, der innerhalb der Klasse, die dieses Attribut trägt eindeutig ist 2. einen Gültigkeitsbereich, der festlegt, ob ein Attribut auf Instanzebene oder Klassen gültig ist. Letzteres bedeutet, dass dieses Attribut nur einmal instanziiert wird und dieser Wert von allen Instanzen dieser Klasse gemeinsam benutzt wird. Attribute diese Art der Klassenattribute genannt. Attribute auf Instanzebene werden für jede Instanz der Klasse separat gebildet und heißen Instanzattribute. 3. eine Sichtbarkeit, die Aussagen darüber trifft ob und von welchen Klassen aus dieses Attribut zugegriffen und verändert werden kann.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

9

4. ein Typ, der Einfluss auf die Werte, die dieses Attribut annehmen kann, hat. Typen sind abhängig vom von der zu implementierenden Programmiersprache und können auch Enumerationen sein. Art und Notation von Typen werden von der UML nicht vorgegeben. 5. eine Multiplizität, die eine Aussage darüber macht wie viele Werte ein Attribut annehmen kann. Die Multiplizität ist eine Menge, die aus natürlichen Zahlen, - einschließlich der 0 - und dem Wert *, welcher für unbestimmt viele Werte steht, besteht. Es gilt :∀n   (n < * ). In dieser Arbeit wird die Multiplizität eines Attributs a mit Mult(a) abgekürzt. 6. ein Eigenschaftswert. Die UML definiert drei optionale Eigenschaftswerte für Attribute: a) Der Eigenschaftswert changeable besagt, dass der Wert des Attributs ohne Einschränkungen geändert werden kann. b) Der Eigenschaftswert addOnly ist nur anwendbar auf Attribute a für die gilt : max( Mult(a) ) > 1 . Dieser Eigenschaftswert besagt, dass diesem Attribut Werte ausschließlich hinzugefügt werden können. c) Der Eigenschaftswert frozen, verbietet eine Änderung des Attributwertes nach der Initialisierung. Dargestellt werden Klassen als Rechtecke, welche in vertikal angeordneten Segmente unterteilt sind. Der Name der Klasse steht im obersten Segment. Handelt es sich um eine abstrakte Klasse, so wird der Name kursiv geschrieben. Eine alternative Schreibweise für abstrakte Klassen besteht darin im obersten Segment die Zusicherung (s. Abschnitt 2.1.5 Erweiterungsmechanismus der UML) abstract zu platzieren. Die Attribute der Klasse werden im zweiten Segment angesiedelt. Die Bestandteile, von denen nur der Name zwingend auftreten muss lautet: 1. die Sichtbarkeit des Attributs. Sie wird durch die Zeichen +, # und ausgedrückt, wobei + für public, # für protected und - für private steht. 2. Der Name des Attributs. 3. Der durch einen Doppelpunkt vom Namen getrennte Typ. 4. Die in eckigen Klammern angegebene Multiplizität

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

10

5. Der Vorgabewert, dem ein Gleichheitszeichen vorangestellt wird. 6. Der Eigenschaftswert des Attributs Lehrstuhl

Aufgabe {abstract}

hu-berlin::dbis::Person +name : NameT [0..1] #geschlecht : ( M | W ) = "M" {frozen} -abteilung : NMTOKEN [1..*]

Abbildung 1: Die Notation von Klassen und Attributen

Abbildung 1 zeigt verschiedene Klassen und Notationen. Die abstrakte Klasse Person besteht aus zwei Segmenten, wobei das untere die Attribute der Klasse beinhaltet. Das obere Segment der Klasse beinhaltet den kursiv geschrieben vollständigen Namen und zeigt damit an, dass es sich um eine abstrakte Klasse handelt. Das Namenspräfix hu-berlin::dbis:: deutet an, dass sich die Klasse im Paket dbis befindet, welches wiederum zum Paket hu-berlin zu finden ist. Die alternative Notation für abstrakte Klassen zeigt die in der Mitte stehende Klasse Aufgabe. Sie enthält unterhalb des normal geschriebenen Namens die Zusicherung abstract. Die Klasse Person enthält zusätzlich die drei Attribute name, geschlecht und abteilung. Der Typ des Attributs geschlecht ist eine Enumeration, die aus den Werten M und W besteht.

2.1.2 PAKETE Pakete sind ein wichtiges Strukturierungsmittel in der UML. Sie sind generalisierbar und bilden zudem einen eigenen Namensraum, d.h. unter anderem, dass Pakete andere Modellelemente beinhalten können. Gemäß [UML1.4] dient ein Paket der Gruppierung von Modellelementen. Da Pakete keine Laufzeitsemantik haben, werden sie ausschließlich zur strukturellen Modellierung verwendet. Sie besitzen jedoch einen dualen Charakter, da sie sowohl Klassendiagramme logisch strukturieren, als auch zum Aufteilen architektonischer Aspekte innerhalb des Einsatz- und des Komponentendiagramms verwendet werden. Paketen können Modellelemente vererben. Hierbei können Modellelemente des Basispakets durch Modellelemente der Spezialisierung überladen werden.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

11

Dargestellt werden Pakete durch eine Registermappe. Abbildung 2 zeigt die Notation des Pakets Lehre, welches das Modellelement Diplom beherbergt. Lehre Diplom

Abbildung 2: Notation eines Pakets

2.1.3 BEZIEHUNGEN In der UML steht der Begriff Beziehung allgemein für Verbindungen zwischen UML-Modellelementen. Beziehung ist ein Bestandteil des UMLMetamodells und ist dort eine abstrakte Klasse. Jene Unterklassen von Beziehung, die für die konzeptuelle Modellierung wesentlich sind, lauten ASSOZIATION, GENERALISIERUNG und ABHÄNGIGKEIT. Eine „Instanz“ dieser Unterklassen wird als Link bezeichnet, jedoch ist nicht jeder Link ein eigenständiges Objekt, wie man später sehen wird.

ASSOZIATION UND ASSOZIATIONSKLASSE Laut [BoochRumbJacob] ist eine Assoziation „...eine strukturelle Assoziation, die spezifiziert, dass Objekte eines Dinges mit Objekten eines anderen Dinges zusammenhängen“. In dieser Arbeit werden ausschließlich Assoziationen zwischen Klassen betrachtet. Assoziationen beinhalten mindestens zwei Assoziationsenden. Jedes Assoziationsende ist an genau eine Klasse, welcher an der Assoziation beteiligt ist, gebunden. Des weiteren enthält ein Assoziationsende, welche eine Metaklasse des UML-Metamodells ist, Informationen darüber mit welcher Multiplizität diese Einbindung erfolgt und (für binäre Assoziationen) ob die Assoziation zum Assoziationsende hin navigiert werden kann. Letzteres wird für einen Link dadurch angegeben, dass das Metaattribut isNavigable für das entsprechende Assoziationsende mit dem Wert „true“ belegt wird. Jeder Link einer Assoziation ist laut [UML1.4] ein Tupel, welcher auf Objekte der in der Assoziation involvierten Klassen verweist. Eine Assoziation, die weder Aggregation

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

12

oder Komposition ist, wird in dieser Arbeit als gewöhnliche Assoziation bezeichnet. Aggregation und Komposition sind binäre Assoziationen, welche eine Eigentumsbeziehung bzw. Zusammensetzungsbeziehung zwischen Modellelementen beschreibt. Hierbei ist die Komposition die striktere Variante, da sie im Gegensatz zur Aggregation zum einen eine stärkere Eigentumsbeziehung und zum anderen eine eingeschränkte Lebensdauer vorschreibt. Die stärkere Eigentumsbeziehung wird dadurch zum Ausdruck gebracht, dass Instanzen der aggregierten Klasse nur höchstens einen Besitzer haben dürfen. Die Einschränkung der Lebensdauer besteht darin, dass eine Instanz des Aggregats für Erzeugung und Zerstörung der von ihm aggregierten Instanzen verantwortlich ist. Bei diesen Unterarten der Assoziation darf ein aggregiertes Element an keiner weiteren Aggregation oder Komposition teilnehmen. Eine Assoziationsklasse ist ein Hybrid aus Assoziation und Klasse. Im UML-Metamodell wird dies durch eine Mehrfachvererbung dargestellt. Eine Assoziationsklasse stellt ein eigenständiges Modellelement dar. Daher gehören die Attribute und Operationen der Assoziationsklasse NICHT zu einem oder mehreren an der Assoziation beteiligten Klassen. Assoziationen werden als durchgängige Verbindungslinien zwischen den beteiligten Modellelementen gezeichnet. Assoziationsenden werden durch Rollenname und Multiplizität an jenem Ende der Verbindungslinie, welches sich an der mit dem Assoziationsende verbundenen Klasse befindet, dargestellt. Unidirektionale Assoziationen, d.h. binäre Assoziationen, die nur in eine Richtung navigierbar sind, werden als Pfeil notiert. Die Notation einer Assoziationsklasse besteht aus drei Teilen: der Verbindungslinie (einschließlich Rollen und Multiplizitäten), einem Klassensymbol, dessen Name dem der Assoziationsklasse entspricht und welches deren Attribute beinhaltet, und einer gestrichelten Linie, welche das Klassensymbol und die Verbindungslinie verbindet. Abbildung 3 zeigt die unidirektionale Assoziation beschaeftigt mit den Rollen abteilung und angestellter und die ternäre Assoziationsklasse Vorlesung, mit ihrem Attribut termin. Die Assoziationsenden werden hierbei durch die Rollennamen und Multiplizitäten

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

13

am dem Ende der Assoziation, an dem sich ihre korrespondierende Klasse befindet, repräsentiert. Lehrstuhl Dozent

abteilung

beschaeftigt

angestellter

0..1

WiMi

1..* unterricht

lehrender 1

Lehrveranstaltung

* lernender 1..*

Vorlesung

Student

termin:date Abbildung 3: Die Notation von gewöhnlichen Assoziationen

Aggregationen und Kompositionen werden als durchgezogene Verbindungslinie, die ein Quadrat als Linienende auf der Seite des Aggregats hat, dargestellt. Kompositionen besitzen dabei ein ausgefülltes Quadrat, bei Aggragationen ist das Quadrat nicht ausgefüllt. Abbildung 4 zeigt die Notation von Aggregation und Komposition. A

1..*

A1

A

0..1

...

An

*

A1

...

An

Abbildung 4: Die Notation von Aggregationen und Kompositionen

GENERALISIERUNG Die Generalisierung stellt eine binäre Subtypen-Beziehung zwischen Modellelementen dar, wobei sich diese Arbeit nur auf Generalisierungen zwischen Klassen konzentriert. Im Metamodell besitzt die Generalisierung u.a. die drei

(Pseudo-)Attribute discriminator, parent und child. Das

Pseudo-Metaattribut parent bezeichnet die spezialisierte (allgemeinere) Klasse in dieser Beziehung. Analog dazu bezeichnet child die Spezialisierung. Seien c, p zwei Klassen, zwischen denen eine Generalisierung g existiert, wobei p parent und c child ist. Dann heißt p Vater von c bzw. Vaterklasse von g und c heißt Kind von p bzw. Kindklasse von g. Die Menge aller Links einer Generalisierung, die den gleichen Vater teilen, werden partitioniert, d.h. in disjunkte, benamte Teilmengen - den Partitionsklassen -

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

14

unterteilt. Das Metaattribut discriminator bezeichnet den Namen derjenigen Partitionsklasse, zu welcher ein Link gehört. Die Menge aller Partitionsklassen bildet ebenfalls eine Partition auf der Menge aller Generalisierungslinks. Die Abschnitte 2.5.4.4 Inheritance und 2.5.4.5. Instantiation in [UML1.4] befassen sich u.a. mit dem Aufbau von Objekten, die spezialisierten Klassen angehören. Diese Objekte bestehen aus Segmenten, welche sich aus der Vererbungshierarchie der entsprechenden. Klassen bilden. Jedes Segment repäsentiert entweder eine Vorfahrenklasse (Vorfahrensegment) in der Vererbungshierarchie oder die zu instanziierende Klasse selbst (Eigensegment). Seien k, p Klassen des gleichen Modells. [Definition] Das Eigensegment einer Klasse k ist die Menge aller Attribute und Assoziationen, welche nicht durch Vererbung oder Zusicherungen in die Klasse gelangen, sondern in k definiert wurden. Das Eigensegment der Klasse k wird mit EigenSeg(k) bezeichnet. [Definition] Ein Vorfahrensegment der Klasse k bzgl. seines Vererbungsvorfahren p ist die Menge aller Attribute und Assoziationen, die zu k gehören und von p vererbt wurden. Zu jedem direkten oder indirekten Vorfahren besitzt k genau ein Vorfahrensegment. Die Menge der Vorfahrensegmente einer Klasse k wird mit VorfSeg(k) bezeichnet. Die Segmentierung einer Klasseninstanz zeigt u.a., dass die o.g. (Pseudo-)Metaattribute parent, child und discriminator von rein konzeptueller Natur sind. Die für diese Arbeit relevanten Standardzusicherungen, welche sich auf Mengen von Generalisierungen beziehen, sind: 

disjoint und overlapping Die Zusicherung disjont sagt aus, dass eine Instanz des Vaters die Instanz von höchstens einem Kind der zugehörigen Subpartition sein kann. Overlapping hingegen besagt, dass die Instanz eines Kindes der zugehörigen Subpartition auch gleichzeitig Instanz eines anderen Kindes derselben Subpartition sein kann.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung



15

complete und incomplete Die Zusicherung incomplete wird nur auf Links der gleichen Partitionsklasse - sprich mit identischer Belegung des Metaattributs discriminator angewandt, und besagt, dass eine Instanz des Vaters nicht Instanz eines seiner Kinder aus dieser Partitionsklasse sein muss. Es wird damit angedeutet, dass nicht alle Kinder eines Vaters innerhalb des Modells bekannt sind, bzw. das Modell diesbezüglich noch erweitert wird. Complete kann nur auf Partitionsklassen angewandt werden. Wird die Zusicherung verwendet, so muss jede Instanz des Vaters auch Instanz von mindestens einem seiner Kinder aus dieser Partitionsklasse sein. Man kann daraus folgern, dass ein Modellelement abstrakt sein muss, wenn dieses mindestens eine Partitionsklasse hat, welche mit der Zusicherung complete versehen wurde. Dieses Modellelement heißt implizit abstrakt (vgl. 2.1.1 Klassen und deren Attribute).

Generalisierungen werden als Pfeil mit ungefüllter Spitze dargestellt, wobei die Pfeilspitze auf die Vaterklasse zeigt. Abbildung 5 zeigt drei Generalisierungen. in allen drei Fällen übernimmt die Klasse Aufgabe die Rolle der Vaterklasse. Programmieraufgabe

Aufgabe {abstract}

SchriftlicheAufgabe {abstract} Konstruktion

Abbildung 5: Notation von Generalisierungen

ABHÄNGIGKEITEN Abhängigkeiten sind die wohl vielfältigste Art der Beziehungen. Sie repräsentieren alles, was nicht Assoziation, Generalisierung, Fluss oder Metabeziehung ist. Abhängigkeiten können zwischen beliebigen Modellelementen in beliebiger Konstellation gebildet werden. Diese Arbeit beschränkt sich auf

«access»-Abhängigkeiten zwischen Paketen. Diese Abhängigkeiten

zeigen an, dass alle öffentlichen Modellelemente eines Paketes durch ein anderes Paket benutzt werden, ohne diese zu importieren.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

16

2.1.4 KOMMENTARE Kommentare dienen der Aufzeichnung von Informationen, die für den/die Modellierer wichtig sind, jedoch keine semantischen Auswirkungen auf das Modell haben. Ein Kommentar kann mit beliebig vielen Modellelementen verbunden sein. Kommentare werden als Rechteck mit einer umgeknickten Ecke an der rechten oberen Seite dargestellt. Modell

Assoziation

Übung

Klassen

Vorlesung Generalisierung

1..*

Aufgabe {abstract} name telNr

Programmieraufgabe SchriftlicheAufgabe {abstract}

Attribut telNr

Abbildung 6: Notation von UML-Kommentaren

Abbildung 6 zeigt Kommentare, die mit verschiedenen Modellelementen verbunden sind. Der Kommentar in der linken oberen Ecke hat keine Verbindung zu einem Modellelement.

2.1.5 DER ERWEITERUNGSMECHANISMUS DER UML Der Erweiterungsmechanismus der UML dient der Anpassung von Modellelementen an die Bedürfnisse des Softwareentwicklers. Wichtig hierbei ist, dass die Sprache selbst erweitert wird, nicht die Laufzeitumgebung! Die Erweiterung erfolgt in Form von Stereotypen, Zusicherungen und Merkmalen, die den Modellelementen und nicht den Instanzen eines Modells hinzugefügt werden. Ein Stereotyp ist ein Mechanismus um das UMLMetamodell „virtuell“ zu erweitern. Hierbei wird der Stereotyp einem oder mehreren Modellelementen hinzugefügt. Diese Modellelemente verfügen über die gleiche Struktur die sie ohne Stereotyp auch hätten, werden jedoch

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

17

um Zusicherungen und Merkmaldefinitionen erweitert. Stereotypen dienen vor allem dem Hervorheben eines variierten Verhaltens oder einer anderen Benutzung. Eine Zusicherung ist eine verbal spezifizierte Erweiterung der Semantik eines Modellelements. Die Sprache, in der diese Erweiterung formuliert wird, ist hierbei beliebig. Eine Merkmaldefinition spezifiziert die Merkmale, die einem Modellelement hinzugefügt werden können. Ein Merkmal ist ein Name-Wert-Paar, das der semantischen Erweiterung eines Modellelements dient. Jedes Merkmal erfüllt eine Merkmaldefinition. Eine Merkmaldefinition kann zu höchstens einem Stereotyp gehören. Die Interpretation dieser Informationen wird nicht von der UML vorgegeben. Die Notation von Stereotypen erfolgt durch Anhängen des in GuillaumeZeichen (« bzw. ») eingefügten Namens des Stereotyps an das Modellelement. Bei Klassen wird der Stereotyp in die erste Zeile des obersten Segments gesetzt. Zusicherungen und Merkmale werden in geschweifte Klammern geschrieben und an das entsprechende Modellelement gesetzt. Bei Klassen wird eine Zusicherung oder ein Merkmal unter den Namen im obersten Segment gesetzt. Abbildung 7 zeigt die Notation von Stereotypen, Merkmalen und Zusicherungen. Die Klasse Tutor trägt den Stereotyp Elementtyp, die Klasse Person trägt die Zusicherung abstract und die zwei Generalisierungen, deren Vaterklasse Mitarbeiter ist, tragen die Zusicherungen complete und overlapping.

2.2 RELEVANTE KONZEPTE DER XML

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

18

Person {abtract}

Student

Mitarbeiter

Ausbilder

matrikelNr : ID

personalNr : ID

extern : (true|false)

«ElementTyp» Tutor

{overlapping; complete}

Übungsleiter gehalt:int

inLehre:(true|false)

Abbildung 7: Notation von Zusicherungen, Merkmalen und Stereotypen

2.2.1 DTD DTD steht für Document Type Definition. Dies ist nicht mit der Dokumenttypdeklaration zu verwechseln. Die DTD ist Bestandteil der Dokumenttypdeklaration und enthält die Grammatik, welche den Aufbau gültiger Dokumentinstanzen beschreibt. Die Markupdeklarationen der DTD werden werden in einer eigenen Sprache formuliert. Die Bestandteile einer DTD sind: Element-, Attributlisten-, Format-, und Entitätsdeklarationen, sowie Anweisungen und Kommentare.

ELEMENT- UND ATTRIBUTLISTENDEKLARATION Ein Elementtyp legt alle alle Eigenschaften der Elemente, die ihn instanziieren, fest. Er besteht aus einer Element- und einer Attributlistendeklaration. Eine Elementdeklaration legt den Namen, welcher in den Tags der Elemente verwendet wird und den zulässigen Elementinhalt der Elemente fest. Letzteres erfolgt durch die Inhaltsspezifikation, die Bestandteil der Elementdeklaration ist. Es gibt vier Arten von Elementinhalt: 1. reiner Inhalt, welcher nur aus Elementen besteht, 2. gemischter Inhalt, welcher sowohl aus Elementen, als auch Zeichendaten bestehen kann,

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

19

3. leerer Inhalt, der andeutet, das eine Instanz über keinen Elementinhalt verfügt und 4. beliebiger Inhalt, welcher keine Aussagen über den Elementinhalt macht außer der Tatsache, dass beinhaltete Element deklariert sein müssen. Eine Attributlistendeklaration besteht aus Attributdefinitionen und ist durch ihren Namen eindeutig an eine Elementdeklaration gebunden. Eine Attributdefinition besteht aus folgenden Teilen: 

den Namen des XML-Attributs, der innerhalb des Elementtyps eindeutig ist,



dem Typ des Attributs; zulässige Attributtypen sind: ID, IDREF, CDATA, ENTITY, ENTITIES, NMTOKEN und NMTOKENS, sowie Enumerationen. Es gibt zwei Arten von Enumerationen: Enumerationen von Werten und Enumeration von Formaten. Letztere dienen dazu, ein Format, welches in der DTD deklariert wurde und der Interpretation des Inhalt des Elements dient, zu referenzieren. Ein Attribut dieses Typs heißt Formatierungsattribut.



Verwendung des Attributs, d.h. ob ein Attribut innerhalb eines Elements angegeben werden muss (#REQUIRED) oder kann (#IMPLIED).



Angabe eines Anfangs- bzw. Festwertes. Ein Anfangswert besagt, wenn dass dieses Attribut mit diesem Wert belegt wird, wenn das entsprechende Attribut nicht explizit angegeben wird. Ein Festwert (#FIXED) ist eine stärkere Variante des Anfangswertes. Hierbei ist es nicht möglich das Attribut mit einem anderen Wert als dem Festwert zu belegen.

FORMATDEKLARATION Ein Format repräsentiert eine Applikation zur Verarbeitung des Inhalts einer ungeparsten Entität, eines Elements, das ein Formatierungsattribut trägt, oder einer Anweisung. Die Deklaration beinhaltet einen Verweis auf die verarbeitende Applikation.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

20

ANWEISUNG Eine Anweisung dient dazu, Verarbeitungsdaten für eine Anwendung, die als Hilfsapplikation eines XML-Prozessors dient, bereit zu stellen. Eine Anweisung besteht aus einem Applikationsnamen, der formal mittels eines Formats deklariert sein kann, und den zu verarbeitenden Daten der Anweisung.

KOMMENTAR Ein XML-Kommentar enthält Informationen, die eine XML-Dokumentinstanz, eines Dokumenttyp-Definition bzw. einer DTD dokumentieren. Alle Daten, die sich innerhalb eines Kommentars befinden, werden bei der Verarbeitung durch einen XML-Prozessor ignoriert.

2.2.2 XLINK XLink erlaubt es sowohl unidirektionale als auch komplexere Beziehungen zwischen Elementen aufzubauen. Dies erfolgt über spezielle Attribute, die den Elementen angehängt werden. Es gibt zwei Arten von Beziehungen. Bei einem Simple link handelt es sich um eine unidirektionale Beziehung, wie man sie aus HTML kennt. Sie stellen eine navigierte 1:1-Beziehung dar. Ein extended link spiegelt eine komplexere Form der Beziehung wider. Die Beziehung besteht aus drei Komponenten: einem umschließenden Element, einer Menge von Ressourcenelementen und einer Menge von Verbindungselementen. Das umschließende Element repräsentiert den extended link als Ganzes und trägt das Attribut-Wert-Paar xlink:type="extended". Dieses Element beinhaltet alle Ressourcen- und Verbindungselemente. Ressourcenelemente beschreiben die an der Beziehung beteiligten Ressourcen. Ressourcen, die innerhalb des umschließenden Elements definiert wurden heißen lokale Ressourcen und tragen das Attribut-Wert-Paar xlink:type="resource". Ein Ressource, die außerhalb des umschließenden Elements definiert wurde, heißt externe Ressource und trägt das AttributWert-Paar xlink:type="locator".

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

21

Jedoch reicht die Angabe der Ressourcen innerhalb des extended link nicht aus, um die Beziehung vollständig zu beschreiben. Verbindungselemente beschreiben, welche Ressourcen miteinander in Beziehung stehen. Sie tragen das Attribut-Wert-Paar="arc". Ein Attribut-Wert-Paar für das XML-Attribut xlink:type heißt XLink-Typ.
#FIXED "arc" #IMPLIED #IMPLIED>

Abbildung 8: Deklarationen für simple und extended links

Abbildung 8 zeigt einen simple link und einen extended link. Letzterer besteht aus einem Elementtyp dessen Inhaltsspezifikation sowohl interne (IntRes) als externen Ressourcen (ExtRes) vorsieht. Die Verbindungselemente werden durch den Elementtyp _ARC deklariert.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung

22

2.2.3 XML-SCHEMA XML-Schema ist eine Beschreibungssprache für XML-Dokumentinstanzen, die als ergänzender W3C-Standard zu [XML1.0SE] entwickelt wurde. Die Beschreibung der Schemata erfolgt in XML und nicht, wie es bei DTDs der Fall ist, in einer eigenen Sprache. XML-Schema führt außerdem ein Typsystem ein, mit dem es möglich ist, den Inhalt von Elementen präziser zu spezifizieren. In dieser Arbeit werden derartige Typen als Metatypen bezeichnet, da es sich bei ihnen um Typen von Elementtypen handelt. Einfache Typen werden auch als Attributtypen eingesetzt. Die Inhaltsspezifikation und Attributdefinitionen werden in komplexe Typen ausgelagert und sind damit nicht mehr getrennt. Attributlistendeklarationen, wie sie in DTDs vorkommen, gibt es in XML-Schemata nicht. XML-Schema führt eine neue Art der Inhalt ein. Neben Sequenz, Auswahl, leerem, beliebigem und gemischtem Inhalt existiert nun auch permutierbarer Inhalt, d.h. die Elemente, die sich im Inhalt eines entsprechend deklarierten Elements befinden, können in beliebiger Reihenfolge auftreten. ...

Eine Beispielinstanz könnte wie folgt aussehen: ... ... ... ... ... ...

Ein Elementtyp instanziiert lediglich einen Metatyp, der, soweit dies erforderlich ist, die entsprechende Inhaltsspezifikation und Attributdefinitionen beinhaltet. Dies kann auf zwei Arten erfolgen:

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung



23

der Metatyp wird innerhalb des Elementtyps anonym deklariert. Dadurch kann der Metatyp nur durch den Elementtyp instanziiert werden, da er zum einen außerhalb des Elementtyps weder sichtbar ist und zum anderen über keinen Namen verfügt, über den er referenziert werden könnte. Das folgende Beispiel demonstriert diesen Fall.

.... 

Der Elementtyp referenziert den Metatyp. Dies setzt voraus, das der Metatyp außerhalb des Elementtyps liegt und einen Namen besitzt, über den er referenziert werden kann. ...

Um zu vermeiden, dass ein Metatyp durch einen Elementtyp instanziiert werden kann, wird in der Metatypdeklaration das Metaattribut abstract mit dem Wert true belegt. ....

Analog dazu kann auch ein Elementttyp abstrakt sein. Dies bedeutet, dass keine Elemente von diesem Elementtyp gebildet werden können. ...

bzw.

Eine weitere Eigenschaft des Typsystems besteht darin, dass Metatypen voneinander abgeleitet werden können. Hierbei gibt es zwei Varianten.: 

Ableitung durch Erweiterung, d.h. der neue Metatyp verfügt über eine erweiterte Inhaltsspezifikation bzw. neue Attribute, oder

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 2 Konzeptuelle Datenmodellierung



24

Ableitung durch Einschränkung, d.h. die zulässigen Werte für den Inhalt des Elements bzw. der Attribute werden eingeschränkt.

Hierbei ist es möglich die Ableitung eines Metatyps mit dem Meta-Metaattribut final einzuschränken. Wie bereits oben erwähnt, ist es möglich die Benutzung von Metatypen innerhalb eines Elementstyps einzuschränken. Dies geschieht, indem die Metatypdeklaration in die Elementtypdeklaration verlagert wird. Somit ist der Metatyp außerhalb des Elementtyps nicht sichtbar und kann somit außerhalb des Elementtyps auch nicht verwendet werden. Analog dazu ist es möglich den Gültigkeitsbereich eines Elementtyps auf einen Metatyp zu beschränken. Derartige Meta- bzw. Elementtypen werden lokaler Metatyp bzw. lokaler Elementtyp genannt.

Als letztes Konzept werden die Ersetzungsgruppen vorgestellt. Hierbei handelt es sich um einen Austauschmechanismus für Elemente. Eine Ersetzungsgruppe ermöglicht es Elemente eines bestimmten Typs durch Elemente zu ersetzen, die einen Metatyp instanziieren, welcher sich in der Ersetzungsgruppe befindet. Jede Ersetzungsgruppe ist jedoch auf einen einzigen austauschbaren Elementtyp eingeschränkt. Die Elementtypen innerhalb der Ersetzungsgruppe können nicht gegeneinander ausgetauscht werden. Eine weitere Einschränkung besteht darin, dass ein Elementtyp zu höchstens einer Ersetzungsgruppe gehören kann. Die Zugehörigkeit eines Elementtyps zu einer Ersetzungsgruppe wird in der Deklaration des Elementtyps durch das Metaattribut substitutionGroup angegeben. Der Wert des Attributs ist der Name des zu ersetzenden Elementtyps. Für die Ersetzungsgruppe selbst existiert keine Deklaration.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

25

KAPITEL 3 TRANSFORMATIONEN VOM UML-MODELL ZUR DTD Wie bereits im Kapitel 2 erläutert wurde, konzentriert sich die konzeptuelle Datenmodellierung auf Anwendersicht einer Problemdomäne. Wie sich in den folgenden Abschnitten zeigen wird, ist eine direkte Modelltransformation problematisch. Sie beinhaltet aufgrund der differierenden Konzepte und des sehr unterschiedlichen Konzeptumfangs sowohl semantische Verluste als auch strukturelle Ineffizienz. Um die Qualität der Transformation zu verbessern, ist ein mehrstufiges Vorgehen angebracht. Zunächst erfolgt die Modellierung der Daten in normaler Weise, d.h. ohne Rücksicht auf XMLspezifische Aspekte. Zu Kontrollzwecken kann eine direkte Transformation durchgeführt werden, um eventuelle Schwachstellen des Modells aufzudecken. Im Folgeschritt wird auf der Grundlage des erarbeiteten Modells ein Metamodell der zu erzeugenden DTD erstellt. Dieses wird bearebitet und im Anschluss daran in eine DTD überführt wird. Der Vorteil dieses Vorgehens besteht darin, dass sowohl die Anwendersicht, als auch XML-spezifische Aspekte Berücksichtigung finden. Jeder Schritt für sich behandelt dagegen nur eine der beiden Perspektiven und ist für eine gute Modellierung nicht ausreichend. Um es auf eine einfache Formel zu bringen, kann man sagen, dass im ersten Schritt das „WAS“ behandelt wird und im zweiten Schritt das „WIE“.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

26

3.1 DIREKTE MODELLTRANSFORMATION In diesem Abschnitt wird eine Transformationsvorschrift angegeben, welche aus einem beliebigen statischen UML-Modell eine DTD generiert, die (nahezu) den gleichen Sachverhalt darstellt. Die hierbei zugrunde liegende Perspektive konzentriert sich auf die einzelnen UML-Konzepte, welche bereits im Kapitel 2 erläutert wurden.

3.1.1 KLASSEN, PAKETE UND ATTRIBUTE In [ConSchef2000] und [ConSchef2001] werden Klassen in Elementtypen transformiert. Die UML-Attribute einer Klasse werden ebenfalls in Elementtypen umgewandelt. Der Elementtyp der Klasse referenziert dabei die Elementtypen der UML-Attribute. Dies wird damit begründet, dass die Beziehung zwischen UML-Attribut und Klasse analog zu einer Aggregation sei. Warum dies eine unzureichende Sicht auf diese Beziehung ist, wird in Abschnitt 2.1.1 Klassen und deren Attribute erläutert. Weitere Gründe hierfür sind: 1. Es werden (unnötig) zusätzliche Strukturen im Dokumentenmodell aufgebaut. 2. Bei der in [ConSchef2000] beschriebene Restriktion, welche die Reihenfolge der Attribute durch deren Auftreten in der Klasse festlegt, ergeben sich bei alternierendem Auftreten von normalen Attributen und Metadatenattributen Attributreihenfolgen, die nicht in einer DTD realisiert werden können. Als Alternative zum o.g. Vorgehen wird folgende Transformation vorgeschlagen:

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

27

TRANSFORMATION NICHTABSTRAKTER KLASSEN Alle nichtabstrakten Klassen werden beim Erzeugen einer DTD in einen Elementtyp überführt. Hierbei werden Operationen nicht berücksichtigt, da mithilfe einer DTD ausschließlich strukturelle Aspekte modelliert werden können. In Analogie zu [ConSchef2000] wird der Klassenname als Name des Elementtyps übernommen. Genauer gesagt wird der lokale Name der Klasse zum lokalen Namen des Elementtyps. Die Pakethierarchie, in welche die Klasse eingebunden ist, wird durch eine Verkettung der entsprechenden Paketnamen in einen XML-Namensraumpräfix überführt. Da zu diesem Zeitpunkt noch keine URI feststeht, erhält der zu erzeugende Elementtyp jedoch keine entsprechende XML-Namensraumdeklaration. Dadurch ist der XML-Namensraumpräfix Bestandteil des lokalen Namens, solange dem Elementtyp keine XML-Namensraumdeklaration hinzugefügt wird. Der erzeugte Elementtyp ist somit syntaktisch und semantisch korrekt. Ein Wurzelelement kann aus folgenden Gründen nicht deklariert werden a) Dem Modell kann nicht immer der Kontext entnommen werden, in dem die modellierten Klassen verwendet werden. Das Modell stellt nur einen Teil eines Systems dar, in den die zu erzeugenden Daten eingebettet werden sollen. b) In den meisten Fällen sind die Klassen keiner semantischen Hierarchie unterworfen. Es gibt viele einzelne Mengen von Klassen, die zwar zusammengehören und u.U. eine Teilhierarchie bilden, jedoch kann nicht immer entschieden werden, wie diese Teilhierarchien in eine Gesamthierarchie einzubinden sind, da letztere nicht existiert. Dies stellt jedoch keinen echten Nachteil dar. Im Gegenteil, somit erhält man die Gelegenheit Markupdeklarationen in Mengen unterzubringen. Diese Mengen können zum Zeitpunkt der physischen Modellierung auf Dateien oder andere Komponenten verteilt werden. Der sich daraus ergebende Vorteil besteht in einer flexibleren Handhabung der Markupdeklarationen.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

28

TRANSFORMATION INNERER KLASSEN Da Klassen UML-Namensräume bilden, ist es möglich, dass sie andere Klassen beinhalten können. Derartige Klassen werden innere Klassen genannt. Sie werden analog zu „normalen Klassen“ gebildet. Der Name des Elementtyps wird analog zum vorhergehenden Abschnitt gebildet. Jedoch setzt sich der Namensraumpräfix aus seinem Pfadnamen der Paket- UND Klassenhierarchie zusammen. Diplom

Lehre Diplom

Inhaltsverzeichnis

Abbildung 9: Namensvergabe bei inneren Klassen

Abbildung 9 demonstriert die Vergabe der Namen bei inneren Klassen. Die Klasse Diplom liegt im Paket Lehre. Innerhalb der Klasse Diplom befindet sich die Klasse Inhaltsverzeichnis. Diese Hierarchie spiegelt sich in den Namen der beiden erzeugten Elementtypen wider.

TRANSFORMATION ABSTRAKTER KLASSEN Die Transformation abstrakter Klassen wird im Zusammenhang mit Generalisierungen im Abschnitt Kapitel 3.1.2 Generalisierungen zwischen Klassen erläutert.

TRANSFORMATION VON UML-ATTRIBUTEN Die Menge der Attribute einer normalen Klasse wird in eine XML-Attributliste des entsprechenden Elementtyps überführt, wobei die einzelnen UMLAttribute in XML-Attributdefinitionen überführt werden. Hierbei sind folgende Schritte zu durchlaufen: 1. UML-Klassenattribute werden nicht überführt. Dies liegt darin begründet, dass nicht gewährleistet werden kann, dass nur ein Wert dieses Attributs für alle XML-Elemente des gleichen Elementtyps

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

29

gebildet wird. Dazu würde man ein alles umschließendes Wurzelelement benötigen, dass entweder a) jedes Klassenattribut des Modells in Form eines Elements beinhaltet, wobei höchstens ein Element des entsprechenden Elementtyps gebildet werden darf oder b) für jedes Klassenattribut des Modells ein XML-Attribut beherbergt, welches nur einen Wert beinhalten darf oder c) genau ein leeres Element beinhaltet, welches die in b) genannten XML-Attribute trägt, welches, wie bereits oben erläutert, nicht existiert. 2. Der Name des erzeugten XML-Attributs ist identisch zum Namen des UML-Attributs. Dies ist möglich, da sowohl der Name eines UMLAttributs gemäß [UML1.4] eindeutig innerhalb der Klasse, als auch Namen

von

XML-Attributen

innerhalb

der

Attributliste

gemäß [XML1.0SE] sind. 3. Die Überführung des Attributtyps wird wie folgt vorgenommen: a) Enthält ein UML-Attribut keinen Typen bzw. wurde ein Typ spezifiziert, welcher kein XML-Attributtyp ist, so erhält das entsprechende XML-Attribut den Typ CDATA. b) Enthält die Klasse mehr als ein Attribut mit dem Typ ID, so ist dies als Fehler zu interpretieren. Das weitere Vorgehen ist der transformierenden Applikation überlassen. c) Enthält die Klasse mehr als ein Attribut mit dem Typ NOTATION, so wird nur das erste Attribut übernommen. Jedoch werden die Enumerationswerte der folgenden NOTATION-Attribute, sofern sich diese noch nicht in der zu übernehmenden Enumeration befinden, in diese aufgenommen. d) Lautet der Typ des UML-Attributs IDREF, ENTITY oder NMTOKEN und die Multiplizität des UML-Attributs die Form 1 oder 0..1 hat, so wird der Typ des UML-Attributs in die XML-Attributdeklaration übernommen. In allen anderen Fällen wird der XML-Attri-

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

30

buttyp entsprechend auf IDREFS, ENTITIES oder NMTOKENS gesetzt. e) Ansonsten wird der Typ des UML-Attributs in die XML-Attributdeklaration übernommen. Die XML-Attributtypen werden im Abschnitt 2.2.1 DTD erläutert. 4. Falls die Sichtbarkeit eines UML-Attributs spezifiziert wurde, so findet diese keine Berücksichtigung bei der Überführung, da eine DTD keine Aussagen über Sichtbarkeit von Attributen trifft. 5. Sollte ein Anfangswert spezifiziert sein, so gilt folgendes bei der Überführung: a) explizite Konstruktoraufrufe werden ignoriert. b) Literale, welche nicht in doppelten Anführungsstrichen stehen, werden in der XML-Attributdeklaration in doppelte Anführungsstriche gesetzt. Ansonsten wird der Anfangswert direkt in die XMLAttributdeklaration übernommen. c) Sollte ein Literal das Kleiner-Zeichen enthalten, so wird dieses Zeichen in der XML-Attributdeklaration durch die Zeichensequenz < ersetzt. d) Es erfolgt keine Überprüfung auf Typverträglichkeit 6. Beinhaltet die Multiplizität des UML-Attributs den Wert 0, so wird die Defaultdeklaration des Attributs auf #IMPLIED gesetzt. Ansonsten wird diese auf #REQUIRED gesetzt, selbst wenn für das UML-Attribut keine Multiplizität angegeben wurde. 7. Eigenschaftswerte werden wie folgt überführt: a) Die Eigenschaftswerte changeable und addOnly werden ignoriert, da eine DTD keine Aussagen über das dynamische Verhalten von Dokumenten treffen kann. b) Die Überführung des Eigenschaftswerts frozen bildet zwei Fälle: 

Das UML-Attribut besitzt einen Anfangswert. In diesem Fall erhält die zu erzeugende Attributdeklaration die Defaultdeklaration #FIXED,

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD



31

ansonsten wird der Eigenschaftswert ignoriert

8. Stereotypen, Zusicherungen und Merkmale der Klasse werden in jeweils einen Kommentar umgewandelt. Diese Kommentare werden vor die Elementdeklaration platziert. Der resultierende Kommentar eines Stereotyps enthält den in Guillaume-Zeichen (« und » ) eingebetteten Namen des Stereotyps.

EIN BEISPIEL ZUR TRANSFORMATION VON KLASSEN UND ATTRIBUTEN Lehrstuhl

hu-berlin::dbis::Person

Aufgabe {abstract} nummer:int punkte:int

Name : NameT [0..1] geschlecht : ( M | W ) = "M" {frozen} abteilung : NMTOKEN [1..*]



Abbildung 10: Die direkte Transformation von Klassen und Attributen

Zur Demonstration der oben vorgestellten Transformation wird in Abbildung 10 auf das im Abschnitt 2.1.1 Klassen und deren Attribute eingeführte Beispiel zurückgegriffen. Die Klasse Lehrstuhl wird in einen Elementtyp ohne Attributlistendeklaration überführt, da sie keine UML-Attribute hat. Die abstrakten Klassen Aufgabe und Person werden nicht in Elementtypen überführt. Anstelle dessen werden Parameterentitäten erzeugt, welche die aus den UML-Attributen erzeugten XML-Attributdefinitionen beherbergen. Am Beispiel der abstrakten Klasse Person werden verschiedene Aspekte bei der Attributtransformation demonstriert. Die Typ und Multiplizität des UML-Attributs name sorgt dafür, dass das erzeugte XML-Attribut den Typ CDATA hat und optional ist. Die Enumeration des Attributs geschlecht wird übernommen. Bei dieser Transformation ist wichtig, dass die KleinerZeichen durch die Entitätsreferenz < und die doppelten Anführungsstriche durch die Entitätsreferenz " ersetzt wurden. Dies ist darauf zurückzu-

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

32

führen, dass es sich hierbei um Zeichen handelt, die im Wert einer Entität nicht zulässig sind. Am Beispiel des UML-Attributs abteilung erkennt man, wie sich die Multiplizität des UML-Attributs auf den Typ des XML-Attributs auswirkt. Da das UML-Attribut mit mehreren Werten belegt werden kann, wechselt beim XML-Attribut der Typ von NMTOKEN auf NMTOKENS.

3.1.2 BEZIEHUNGEN Im vorherigen Abschnitt wurden Klassen und ihre Attribute entweder in Elementtypen überführt. In dem folgenden Abschnitten wird die Transformation der verschiedenen Beziehungen zwischen Klassen gezeigt.

ASSOZIATIONEN Assoziationen sind strukturelle Beziehung zwischen Klassen, die aus Assoziationsenden besteht, welche die beteiligten Klassen in die Assoziation einbinden. Eine Assoziation besteht aus mindestens zwei Assoziationsenden.

GEWÖHNLICHE ASSOZIATIONEN Gewöhnliche Assoziationen sind normale Assoziationen und Assoziationsklassen. Diese Arbeit beschränkt sich auf die Behandlung gewöhnlicher Assoziationen zwischen Klassen. In [UML1.4] sind die Instanzen einer Assoziation eine Menge von Tupeln. Jedes dieser Tupel, welches auf Instanzen der in der Assoziation beteiligten Klassen verweist, darf höchstens einmal existieren. Bei der Umwandlung von Assoziationen gibt es drei Möglichkeiten: 1. die assoziationsorientierte Umwandlung, bei der die zu überführende Assoziation im Mittelpunkt steht, werden sowohl für die Assoziation als auch für die Assoziationsenden Elementtypen erzeugt und in Beziehung zueinander gebracht. 2. die klassenorientierte Umwandlung, bei der nur die Assoziationsenden umgewandelt und in die Elementtypen

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

33

der beteiligten Klassen integriert werden. Hierbei wird nach der Wahl der verwendeten Konzepte unterschieden. 1. attributbasierte, klassenorientierte Transformation, welche die Assoziationsenden in Attributdefinitionen von Elementtypen umwandelt, oder 2. inhaltsbasierte, klassenorientierte Transformation, welche die Assoziationsenden in Elementtypen umwandelt, die in der Inhaltsspezifikation anderer Elementtypen referenziert werden. DIE ASSOZIATIONSORIENTIERTE UMWANDLUNG Zur Umsetzung der gewöhnlichen Assoziationen werden, wie in [ConSchef2000] bereits vorgestellt, Konzepte aus XLink verwendet. Die gewöhnliche Assoziation wird in einen extended Link umgewandelt. Hierbei werden die Assoziation selbst und deren Assoziationsenden in Elementtypen, welche den XLink-Typ extended (für die Assoziation) bzw. den XLink-Typ locator (für die Assoziationsenden) tragen, umgewandelt. Zusätzlich fordert XLink, dass Verbindungselemente gebildet werden, welche die eigentliche Verbindung zwischen den Elementen herstellen soll (s. Abschnitt 2.2.2 XLink). Der Elementtyp für die Verbindungselemente trägt den XLink-Typ arc und wird von allen Elementtypen, die aus Assoziationen gebildet werden, gemeinsam genutzt. Wird eine Assoziationsklasse umgewandelt, so wird der Name des Elementtyps genauso gebildet, wie es bei der Transformation normaler Klassen der Fall ist. Bei normalen Assoziationen gestaltet sich die Namensgebung für einen Elementtyp schwieriger. Da der (lokale) Name einer normalen Assoziation nur in Kombination mit den Namen der beteiligten Klassen innerhalb eines Paketes eindeutig ist, muss diese Kombination in den Namen des zu erzeugenden Elementtyps (mit dem XLink-Typ extended) einfließen. Da der lokale Name eines Elements lt. [XMLNames99] keinen Doppelpunkt enthalten darf, dürfen nur die lokalen Namen der beteiligten Klassen verwendet werden. Die Namen der, aus den beteiligten Klassen erzeugten, Element-

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

34

typen wären daher aus syntaktischer Sicht unzulässig. In dieser Arbeit werden die Namen in folgender Reihenfolge zusammengesetzt: pakete:AssoziationsnameKlassenname1..KlassennameX, wobei sich der XML-Namensraumpräfix pakete aus den Namen der übergeordneten Pakete zusammensetzt und es sich bei den Namen von Assoziation und Klassen um die lokalen Namen handelt. Die Namensbildung bei Assoziationsenden gestaltet sich ebenfalls schwierig, da eine DTD im Gegensatz zu einem XML-Schema keine lokalen Elementtypen zulässt. Ein weiterer Grund besteht darin, dass die Namen der Assoziationsenden nur innerhalb der Assoziation und innerhalb der Attribute der beteiligten Klasse eindeutig sind. Daher wird der Name eines solchen Elementtyps aus der o.g. Kombination für die Assoziation UND dem Rollennamen des Assoziationsendes gebildet: pakete:AssoziationsnameKlassenname1Klassenname2...Rollenname Die Elementtypen, welche mit den Assoziationsenden korrespondieren, und die Deklaration der Verbindungselemente besitzen die Inhaltsspezifikation EMPTY. Die Inhaltsspezifikation für die Elementtypen der gewöhnlichen Assoziation enthält Referenzen auf die Elementtypen der Assoziationsenden und den Elementtyp für die Verbindungselemente. Die Multiplizitäten der Assoziationsenden werden auf die Multiplizitäten an den entsprechenden Referenzen in der Inhaltsspezifikation abgebildet. Sei a die Multiplizität des Assoziationsendes, dann gilt für die Multiplizität der Referenz r :

{

nicht benannt , falls a nicht benannt oder a = {1}

r=

?

,falls a = {0,1}

*

, falls a ⊆ [0, ∞[ ∪ {*}

+

, sonst

, wobei [x, y[, das halboffene Interval von x bis y bezeichnet. Abbildung 11 verdeutlicht die Transformation der Assoziationen.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

35

Zunächst wird für alle Verbindungselemente ein Elementtyp vom XLinkTyp arc mit Namen _ARC angelegt. Dieser wird in allen extended links angewendet. Um die Traversierung zu ermöglichen werden die Traversierungsattribute xlink:from und xlink:to derart spezifiziert, dass eine Angabe dieser Attribute bei Instanziierung - sprich Elementbildung - notwendig ist. Nun werden die beiden Assoziationen beschäftigt und Vorlesung in jeweils ein Elementtyp überführt, der den XLink-Typ extended trägt. Die resultierenden Elementtypen lauten beschäftigtLehrstuhlWiMi und Vorlesung. Da Vorlesung eine Assoziationsklasse ist, wird der Name direkt in den zu erzeugenden Elementtyp übernommen. Der Elementtyp, welcher aus der normalen Assoziation beschäftigt erzeugt wird, hingegen erhält einen kombinierten Namen. Die Assoziationsenden (abteilung, angestellter, lehrender, unterricht, lernender) werden ebenfalls in Elementtypen überführt. Jedoch werden diese zu externen Ressourcen innerhalb des extended link umgewandelt, d.h. die entsprechenden Elementtypen erhalten den XLink-Typ resource. Bei der Überführung der Assoziation beschäftigt wird die Multiplizität von abteilung von 0..1 in 1 umgewandelt. Die Inhaltsspezifikation von beschäftigtLehrstuhlWiMi beinhaltet sowohl die Referenzen auf den Elementtyp der Assoziationsenden, wobei deren Multiplizität 1 beträgt, als auch eine Referenz auf den Typ der Verbindungselemente. Da es sich um eine navigierte 1:1-Assoziation handelt, wird nur ein Verbindungselement benötigt. Die Überführung der ternären Assoziationsklasse Vorlesung erfolgt analog, d.h. die Elementtypen der beteiligten Assoziationsenden werden gemäß ihren Multiplizitäten in der Inhaltsspezifikation des extended links referenziert. Die Attribute der Assoziationsklasse werden in Attribute des extended links umgewandelt.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

Lehrstuhl

abteilung

beschäftigt

0..1

Dozent 1

lehrender

angestellter

36

WiMi

1..* unterricht

Lehrveranstaltung

* lernender

Vorlesung

1..*

Student

termin:date



Abbildung 11: assoziationsorientierte Umwandlung gewöhnlicher Assoziationen

Diese Variante ist die einzige Möglichkeit um n-äre Assoziationen zu transformieren. Außerdem können mit ihr die Dokumentgrenzen über-

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

37

wunden werden. Ein weiterer Vorteil besteht darin, dass die Elementtypen von Klassen durch die Auslagerung von Assoziationsinformationen schlanker gehalten werden können. Dokumente, die bereits zum Zeitpunkt der Modellerstellung existieren und nicht mehr verändert werden können, stellen beim Einfügen neuer Assoziationen ein Problem dar. Mit Hilfe sog. „third-party Link Strukturen“ (s. [XLink2001]), welche durch extended links realisiert werden, ist es möglich in derartige Dokumente neue Beziehungen einzubringen. Ein Nachhteil dieser Methode besteht, genau wie in [ConSchef2000] und [ConSchef2001], in der mangelnden Typsicherheit. Zusätzlich geht die Navigierbarkeit der Assoziation verloren.

DIE KLASSENORIENTIERTE UMWANDLUNG Im vorherigen Abschnitt wurde gezeigt, wie eine gewöhnliche Assoziation und ihre Assoziationsenden in Elementtypen transformiert werden. Bei den folgenden Formen der Transformation werden nicht die Assoziation selbst, sondern lediglich ihre Bestandteile, sprich Assoziationsenden, umgewandelt. Die Assoziationsenden werden dabei, je nach verwendeter Methode, in Attributdefinitionen oder in Elementtypen umgewandelt. Ein Vorteil der hier angeführten Methoden besteht darin, dass die erzeugte Beziehung genauso navigierbar ist, wie die Assoziation. Außerdem ist diese Methode für binäre gewöhnliche Assoziationen weniger aufwendig als die assoziationsorientierte Transformation. Der Nachteil dieser Methoden besteht darin, das sie ausschließlich auf binäre normale Assoziationen anwendbar sind. N-äre Assoziationen und Assoziationsklassen sind mit diesen Methoden nicht transformierbar.

attributbasierte, klassenorientierte Transformation Assoziationsenden binden eine Klasse in eine Assoziation ein. Diese Klasse heißt die eigene Klasse des Assoziationsendes. Jede an einer Assoziation teilnehmende Klasse, die nicht durch ein bestimmtes Assoziationsende eingebunden wird, heißt entgegengesetzte Klasse dieses Assoziationsendes. Abbildung 12 zeigt die Klasse Lehrstuhl als eigene Klasse des Assoziati-

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

38

onsendes abteilung und als entgegengesetzte Klasse des Assoziationsendes angestellter. Bei der attributbasierten Transformation einer binären Assoziation werden für jedes der beiden Assoziationsenden bis ein bis zwei Attributdefinitionen erzeugt. Diese werden in die Attributliste jener Elementtypen eingebettet, welche durch die entgegengesetzte Klasse erzeugt wurde. Sollte noch keine Attributlistendeklaration für diesen Elementtyp existieren, so wird diese erzeugt. Die erste Attributdefinition, die erzeugt wird, repräsentiert das Assoziationsende in seiner Funktion als Metaattribut innerhalb seiner entgegengesetzten Klasse. Sie wird nur dann erzeugt, wenn das Assoziationsende der entgegengesetzten Klasse navigierbar ist. Der Name der Definition ist identisch mit dem Namen des Assoziationsendes. Dies liegt darin begründet, dass der Name eines Assoziationsendes als Pseudo-Metaattribut innerhalb der entgegengesetzten Klasse fungiert. Der Typ der Definition lautet bei den Multiplizitäten 1 oder 0..1 IDREF, ansonsten lautet er IDREFS. Die Defaultdeklaration der Attributdefinition lautet bei Multiplizität 0..n für n>0 #IMPLIED, ansonsten #REQUIRED. Die zweite zu erzeugende Attributdefinition ist vom Typ ID und wird nur erzeugt, wenn im entsprechenden Elementtyp noch kein Attribut dieses Typs existiert und das Assoziationsende der entgegengesetzten Klasse navigierbar ist. Die Namenswahl wird der Implementierung des Transfertools überlassen. Für jedes Assoziationsende, welches zu der Assoziation aber nicht zur Klasse gehört und navigierbar ist, wird ein Attribut gebildet, dessen Namen sich aus dem Namen der Assoziation und dem entsprechenden Rollennamen zusammensetzt. Der Typ dieses Attributs lautet IDREF, falls die Multiplizität des betreffenden Assoziationsendes 1 bzw. 0..1 lautet, ansonsten lautet der Typ IDREFS. Das Attribut erhält die Defaultspezifikation #IMPLIED, falls das entsprechende Assoziationsende die Multiplizität 0 zulässt, ansonsten erhält das Attribut die Defaultspezifikation #REQUIRED.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

Lehrstuhl

abteilung

beschaeftigt

0..1

angestellter 1..*

39

WiMi mitarbeiter 0..1 untertützt tutor

*

Student
#REQUIRED>


#REQUIRED #IMPLIED>

ID IDREFS

Abbildung 12: attributbasierte, klassenorientierte Transformation zweier Assoziationen

Abbildung 12 zeigt die Überführung einer bidirektionalen und einer navigierten binären Assoziation. Da die Klasse Lehrstuhl von keiner Klasse aus via Assoziation erreichbar ist, wird für den entsprechenden Elementtyp keine Attributdefinition vom Typ ID erzeugt. Ebenso erkennt man, dass sich die Attributdefinition, welche aus dem Assoziationsende angestellter resultiert, in der Attributlistendeklaration von Lehrstuhl befindet. Am Beispiel der Klasse WiMi erkennt man, dass sie zwar über beide Assoziationen erreichbar ist, jedoch nur eine einzige Attributdefinition vom Typ ID erzeugt wurde. Anhand der Attributdefinitionen angestellter und mitarbeiter kann man die Auswirkungen der UML-Multiplizitäten auf Typ und Defaultdeklaration nachvollziehen. Ein Nachteil, welcher sich bei dieser Methode bemerkbar macht, besteht darin, dass sich alle referenzierten Elemente sich im gleichen XML-Dokument befinden müssen, denn Werte von ID-Attributen sind nur auf Dokumentenebene eindeutig.

Inhaltsbasierte, klassenorientierte Transformation Die Variante der Überführung binärer gewöhnlicher Assoziationen verwendet XLink. Genauer gesagt werden hierbei simple links verwendet.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

40

Wie bereits in Abschnitt 2.2.2 XLink erläutert, ist ein simple Link eine gerichtete 1:[0..1]Assoziation. Dies stellt eine sehr eingeschränkte Möglichkeit dar, Assoziationen direkt in simple links zu überführen. Jedoch ist es möglich die Assoziationsenden in simple links zu überführen und dabei die Assoziation weitgehend zu erhalten. Folglich werden Assoziationsenden nicht - wie bei der attributbasierten Methode - in XML-Attributdefinitionen eines Elementtyps, sondern in simple link-Elementtypen überführt und in der Inhaltsspezifikation desjenigen Elementtyps referenziert, der aus der entgegengesetzten Klasse des Assoziationsendes gewonnen wurde. Die Multiplizität des Assoziationsendes wird wie gewöhnlich in eine XML-Multiplizität, die der Referenz angehängt wird, überführt. Jedoch wird nur für navigierbare Assoziationsenden eine Elementdeklaration erzeugt. Der Name eines derartigen Elementtyps wird genauso gebildet, wie er bei der assoziationsorientierten Transformation gebildet wird. Die Inhaltsspezifikation eines derartigen Elementtyps lautet EMPTY.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

Lehrstuhl

abteilung 0..1

beschäftigt

angestellter

41

WiMi

1..*

mitarbeiter 0..1 untertützt tutor

*

Student





Abbildung 13: inhaltsbasierte, klassenorientierte Transformation zweier Assoziationen

Abbildung 13 zeigt wie die Assoziationen, die auch in Abbildung 12 transformiert wurden, in simple link-Elementtypen überführt werden. Die Assoziationsenden tutor, mitarbeiter und angestellter werden in die Elementtypen unterstützt_WiMi_Student_tutor, unterstützt_WiMi_Student_tutor und beschäftigt_WiMi_Lehrstuhl_angestellter überführt. Da die Assoziation

beschäftigt unidirektional ist und die Klasse Lehrstuhl weder Aggregationen aufweist, noch durch andere Assoziationen erreichbar ist, sehen Instanzen des erzeugten Elementtyps wie folgt aus:

AGGREGATIONEN UND KOMPOSITIONEN Im vorherigen Abschnitt wurde gezeigt, wie gewöhnliche Assoziationen auf verschiedene Art und Weisen in Markupdeklarationen überführt werden können. In diesem Abschnitt werden Assoziationen behandelt, die TeilGanzes-Beziehungen ausdrücken. Genauer gesagt wird nun die Transformation von Aggregationen und Kompositionen behandelt. Die in der UML üblichen Formen der Aggregation/Komposition sind:

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

42

K1.Aggregation/Komposition zwischen Klassen. K2.Klassen-Attribut-Assoziationen K3.Paket-Modellelement-Assoziationen In einer DTD existieren drei Möglichkeiten eine Eigentums- bzw. Zusammensetzungsassoziation zu beschreiben: X1.Die Bildung von Elementinhalt. X2.Die Element-Attribut-Assoziation. X3.Die Zugehörigkeit von Markup-Deklarationen zu einem DTD-subset Diese Art der Aggregation wird ausschließlich für Transformationen von Paket-Modellelement-Assoziationen verwendet. Im Abschnitt 3.1.1 Klassen, Pakete und Attribute haben wir bereits erörtert, dass Aggregationen vom Typ K2 (Klasse-Attribut) in eine Assoziation vom Typ X2 (Element-Attribut) überführt werden kann. AGGREGATION NICHTABSTRAKTER KLASSEN Betrachtet man die Bildung von Elementinhalt genauer, so stellt man fest, dass diese Form der Beziehung zwischen XML-Elementen eine Aggregation ist, deren Multiplizität auf Seiten des Aggregats immer eins lautet. Dies ist auf die baumartige Struktur einer XML-Dokumentinstanz zurückzuführen, denn jedes Element außer dem Wurzelelement ist in genau einem anderen Element enthalten. Jedoch ist die Eigentumsbeziehung nicht so stark ausgeprägt, wie sie es eine Komposition erfordert; da das umgebende Element als Instanz des Aggregats nicht für die Erzeugung bzw. Zerstörung der in ihm enthaltenen Elemente, verantwortlich ist. Des weiteren kann, wie in [ConSchef2001] bereits erläutert, in den Inhaltsspezifikationen verschiedener Elementtypen auf denselben Elementtyp verwiesen werden. Man erkennt ebenso, dass sowohl Aggregationen zwischen Klassen mit einer (maximalen) Aggregatmultiplizität größer als eins als auch Kompositionen zwischen Klassen kein Pendant in XML haben. Es werden jedoch alle Formen der Aggregation und der Komposition gleich behandelt. Damit gehen Modellinformationen verloren, bzw. werden verfälscht.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

43

Der in [ConSchef2001] vorgeschlagene Ansatz , welcher UML-Aggregationen vom Typ K1 (Klasse-Klasse) in XML-Aggregationen vom Typ X1 (Elementinhalt) überführt, wird in dieser Arbeit übernommen, d.h. bei der Überführung der Aggregation werden die von den aggregierten Klassen erzeugten Elementtypen in der Inhaltsspezifikation des Elementtyps, welche der Aggregatklasse zuzuordnen ist, referenziert. Das dabei auftauchende Problem besteht nun darin, zu entscheiden ob die Elementtypreferenzen in Form von Sequenz- oder Auswahltermen in der Inhaltsspezifikation auftauchen. UML-Aggregationen legen weder keine Reihenfolge noch Anordnung der aggregierten Elemente fest. In XML ist die Reihenfolge der beinhalteten Elemente oftmals von entscheidender Bedeutung. Das Fehlen einer Anordnung bei mehreren Aggregationen mit gleichem Aggregat gestaltet sich die Überführung als sehr komplex und aufwendig. Als Alternative zu der in [ConSchef2001] vorgestellten Methode zur Überführung von Aggregationen wird im Folgenden eine Transformation vorgestellt, welche beim Überführen die Anordnungsfreiheit der aggregierten Klassen erhält. Die in [ConSchef2001] vorgestellte Methode, erzeugt in der Inhaltsspezifikation des zum Aggregat korrespondierenden Elementtyps für die Menge der aggregierten Klassen eine Sequenz von Elementtypreferenzen. Die Abbildungen 14 bis 18 zeigen die verschiedenen Überführungen in Abhängigkeit von den Multiplizitäten der aggregierten Klassen. Besonders Abbildung 14 und Abbildung 15 zeigen, dass durch die Bewahrung der Anordnungsfreiheit die Länge der Inhaltsspezifikationsterme überexponentiell mit der Anzahl der aggregierten Klassen steigt, da jede Permutation der entsprechenden Elementtypen als Sequenz in den übergeordneten Auswahlterm eingeht. Die einzige Transformation, bei die Anordnungsfreiheit nicht vollständig erhalten bleibt, wird in Abbildung 16 gezeigt. Die dort gezeigte UMLAggregation, deren aggregierte Klassen alle eine Multiplizität von 1..* aufweisen, erfordert, dass von jeder aggregierten Klasse mindestens eine Instanz Bestandteil der Aggregatinstanz ist, d.h. eine Instanz der Klasse A besitzt mindestens n aggregierte Instanzen. Die Elementdeklaration besagt jedoch nur, dass das Element A

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

A

0..1

A1

A ...

44

A

0..1

An

1

A1

A ...

1

An

1..* A((A1?, ...1..*, An?) | ... )> (
( Abbildung(A 14: Aggregationstransformation ,..,A ) | ... 1 n Multiplizität (Ai1für , ... ,Ain) 0..1 | ... ) , (A1|..|An)* ) > ... Abbildung 16: Aggregationstransformation für Multiplizität 1..*

...> ... Abbildung 15: Aggregationstransformation für Multiplizität 1

Abbildung 17: Aggregationstransformation für Multiplizität *

mindestens ein Element, welches Instanz von einer der in der Auswahl stehenden Deklarationsreferenzen ist, beinhaltet, d.h. das Element A kann weiniger als n Elemente beinhalten. Dadurch erhalten wir zwei Hauptblöcke, die durch eine Sequenz miteinander verbunden werden. Diese sind identisch zu den Ergebnissen der Transformationen von Aggregationen mit Multiplität 1 bzw. *. Der erste Hauptblock stellt sicher, dass von jedem Elementtyp einer aggregierten Klasse mindestens eine Instanz (sprich Element) gebildet wird. Der zweite ist für die Bildung der restlichen Instanzen/Elemente in beliebiger Anzahl verantwortlich. Die Sequenz, welche beide Hauptblöcke miteinander verbindet, ist der Grund dafür, dass durch die Überführung von 1..*-Aggregationen die Anordnungsfreiheit nicht vollständig erhalten bleibt. Diese Sequenz legt fest, dass die ersten n „aggregierten“ Elemente Instanzen aller n „aggregierten“ Elementtypen sein müssen.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

d)

A

1

A1

45

1

...

*

An

B1

*

...

Bm

0..1

C1

0..1

...

Cq

1..*

D1

1..*

...

Dk

...

Abbildung 18: Allgemeine Transformationsformel von UML-Aggregationen in eine DTD

Abbildung 18 zeigt die Kombination der einzelnen Transformationen. Hierbei entstehen - bedingt durch die 1..*-Transformation(en) - zwei Hauptblöcke. Der erste Hauptblock besteht aus den Sequenzen von Elementtypen, welche die aggregierten Klassen repräsentieren, welche eine Multiplizität von 1 bzw. 0..1 bzw. 1..* aufweisen. Hierbei sind alle möglichen Permutationen durch jeweils eine Sequenz vertreten. Die einzelnen Sequenzen werden mittels einer Auswahl verbunden. Der zweite Hauptblock besteht aus einer Auswahl, welche all jene Elementtypen beinhaltet, welche aggregierte Klassen mit maximaler Multiplizität * repräsentieren. AGGREGATION ABSTRAKTER KLASSEN Wird eine abstrakte Klasse aggregiert, so wird anstelle einer Referenz auf den entsprechenden Elementtyp eine Auswahlgruppe eingesetzt. Diese beinhaltet Referenzen auf alle Elementtypen, welche durch die direkten und indirekten, nichtabstrakten Erben der abstrakten Klasse erzeugt wurden. Die XML-Multiplizität der Auswahlgruppe entspricht derjenigen, welche die Referenz auf jenen durch die abstrakte Klasse erzeugten Elementtyp erhalten hätte. Abbildung 19 verdeutlicht diesen Vorgang. Die Klasse Aufgabe ist eine abstrakte Klasse, welche die drei Erben SchriftlicheAufgabe , Konstruktion und Programmieraufgabe hat, von denen die Klasse Schriftliche-

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

46

Aufgabe wiederum abstrakt ist. Die Auswahlgruppe, welche die Referenz auf den Elementtyp Aufgabe ersetzen soll, besteht daher aus den Referenzen auf die Elementtypen Programmieraufgabe und Konstruktion. Diese Auswahlgruppe wird mit der XML-Multiplizität + in die Inhaltsspezifikation eingebunden. Übung 1..*

Aufgabe {abstract} name telNr

Programmieraufgabe SchriftlicheAufgabe {abstract} Konstruktion

... ... Abbildung 19: Transformation von Aggregationen abstrakter Klasse

GENERALISIERUNGEN ZWISCHEN KLASSEN Wie in den vorangegangenen Abschnitten gezeigt wurde, spiegeln sich die Attribute und Beziehungen einer Klasse in den XML-Attributdefinitionen und der Inhaltsspezifikation des korrespondierenden Elementstyps wider. In diesem Abschnitt wird nun die Transformation von Generalisierungen zwischen Klassen behandelt. In Ergänzung zu den drei Überführungsvarianten in [ConSchef2001] bietet sich eine weitere Möglichkeit, Generalisierungen zwischen Klassen mit den Mitteln einer DTD auszudrücken und dabei die Dokumentgrenzen zu überwinden. Dabei wird Generalisierung zum Zeitpunkt der Transformation seiner Kindklasse überführt. Wie bereits im Abschnitt 2.1.3 Generalisierung ausgeführt wurde, besteht in der UML eine Objektinstanz aus verschiedenen Segmenten, welche sowohl die Klasse selbst, als auch die einzelnen Vererbungsvorfahren repräsentieren. Jedes Segment trägt jene UML-Attribute und Beziehungen, die in der entsprechenden Klasse definiert wurden. Dieses Objektmodell soll bei der Transformation in seinen Ansätzen erhaltenbleiben. Jedoch sind folgende Dinge zu berücksichtigen

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

47

1. Ein Element kann nur Instanz genau eines Elementtyps sein. Die Zusicherung overlapping ist also nicht direkt übertragbar. Aus diesem Grund wird der Begriff des Geschwistersegments eines Elementstyps eingeführt. 2. XML-Attributdefinitionen und die Inhaltsspezifikation eines Elementtyps liegen in verschiedenen Deklarationen und sind daher getrennt. Dies macht eine kompakte Darstellung der Segmentierung schwierig. 3. Ein XML-Elementtyp darf nur über maximal eine XML-Attributdefinition mit dem Typ ID verfügen. 4. Alle NOTATION-Attributdefinitionen in den Segmenten müssen zum einer Attributdefinition verschmolzen werden. In diesem Abschnitt wird gezeigt, wie die einzelnen Segmente gebildet und den Elementtyp eingebunden werden. Des weiteren werden mögliche Zusicherungen, die an den Generalisierungen hängen überführt. ERZEUGUNG DER SEGMENTE EINES ELEMENTTYPS Die Begriffe Eigen-, Vorfahrensegment eines Elementtyps werden analog zu den Begriffen für Klassen definiert. Die Zusicherung overlapping sorgt dafür, dass ein Objekt Instanz mehrerer Klassen k1 , ..., kn , die nicht in direkter Vererbungslinie stehen, sein kann. In der XML kann ein Element jedoch nur Insztanz eines Elementtyps sein. Um diesen Fall dennoch zu berücksichtigen, muss ein Elementtyp, welcher aus einer der Klassen k1 , ..., kn erzeugt wurde, die Informationen der anderen n-1 Klassen in sich beherbergen. Aus diesem Grund wird den bestehenden Segmentformen Eigen- und Vorfahrensegment die zusätzliche Form Geschwistersegment hinzugefügt. [Definition]:Eine Klasse s heißt Vererbungsgeschwister von k, wenn s einen Vater von k spezialisiert UND die entsprechenden Generalisierungen eine Partitionsklasse mit der Zusicherung overlapping teilen.. Die Menge der Vererbungsgeschwister von k wird mit Gesch(k) bezeichnet. [Definition] Seien k,s Vererbungsgeschwister, sowie ek und es die aus k und s erzeugten Elementtypen. Ein Geschwistersegment von ek bzgl es ist die

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

48

Vereinigung aller Segmente von es in es, die aufgrund von overlappingZusicherungen in k existieren. Das Geschwistersegment von k bzgl s wird mit GSeg(k,s) bezeichnet und es gilt:

∪(VorfSeg(s)\VorfSeg(k)

GSeg(k,s) := EigenSeg(k) ∪

s ∈ Gesch(k) Es ist hierbei zu beachten, dass sich ein Geschwistersegment aus den Eigenund Vorfahrensegmenten des entsprechenden Vererbungsgeschwisters zusammensetzt. Abbildung 20 zeigt die Segmente der Klasse Tutor innerhalb anhand eines Klassendiagramms. Zu beachten ist, dass sich das Geschwistersegment von Tutor bzgl. WiMi aus dem Eigensegment von WiMi und dessen Vorfahrensegment für die Klasse Lehrender zusammensetzt. Student

Mitarbeiter

Lehrender

MatrikelNr

PersonalNr : ID

Vorlesung : ID

Tutor name:String

WiMi alter:CDATA

Legende: Eigensegment von Tutor Vorfahrensegment von Tutor Teil des Geschwistersegments von Tutor bzgl. WiMi Abbildung 20: Die Segmente eines Objektes

Ein Segment eines zu erzeugenden Elementtyps besteht aus zwei Teilen: seinem Anteil an der Inhaltsspezifikation und an den Attributdefinitionen. Der Inhaltsspezifikationsanteil (ISA) des Segments setzt sich aus allen Referenzen auf jene Elementtypen zusammen, die durch Assoziationen gewonnen wurden, die nicht geerbt wurden.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

49

Der Attributdefinitionsanteil (ADA) setzt sich aus XML-Attributdefinitionen zusammen, welches aus Assoziationen bzw. Attributen, die nicht geerbt wurden. Beim Erzeugen der ADA der verschiedenen Segmente müssen folgende Regeln beachtet werden: 

Alle XML-Attributdefinitionen des Eigensegments, die nicht vom Typ ID oder NOTATION sind, bleiben unverändert.



XML-Attributdefinitionen vom Typ ID (kurz IDDefs) werden wie folgt zugeordnet: 

Es existiert genau eine IDDef: diese IDDef wird nicht verändert.



Es existiert genau eine IDDef im Eigensegment: die IDDef des Eigensegments wird nicht verändert. Sollten andere IDDefs in den Vorfahren- oder Geschwistersegmenten des Elementtyps existieren, so wird deren XML-Attributtyp auf CDATA geändert.



Es existieren mehrere IDDefs im Eigensegment: alle IDDefs dieses Elementtyps erhalten den XML-Attributtyp CDATA.



Das Eigensegment enthält keine IDDef und die Vereinigung und aller Vorfahrensegmente enthält genau eine IDDef: die IDDef des Vorfahrensegments wird nicht verändert. Sollten andere IDDefs in den Geschwistersegmenten des Elementtyps existieren, so wird deren XML-Attributtyp auf CDATA geändert.



Das Eigensegment enthält keine IDDef und die Vereinigung und aller Vorfahrensegmente enthält mehrere IDDefs: alle IDDefs dieses Elementtyps erhalten den XML-Attributtyp CDATA.



Es existieren mehrere IDDefs, aber weder Eigen- noch Vorfahrensegmente enthalten IDDefs : alle IDDefs dieses Elementtyps erhalten den XML-Attributtyp CDATA.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD



50

XML-Attributdefinitionen vom Typ NOTATION (kurz NOTATIONDefs) werden wie folgt zugeordnet: 

Es existiert genau eine NOTATIONDef: diese NOTATIONDef wird nicht verändert.



Es existiert genau eine NOTATIONDef im Eigensegment: die NOTATIONDef des Eigensegments wird nicht verändert. Sollten andere NOTATIONDefs in den Vorfahren- oder Geschwistersegmenten des Elementtyps existieren, so werden deren Enumerationswerte in die NOTATIONDef des Eigensegments eingetragen und die NOTATIONDefs der Vorfahren- und Geschwistersegmente gelöscht. Hierbei ist darauf zu achten, dass jeder Enumerationswert in der NOTATIONDef des Eigensegments nur genau einmal dort vorkommt.



Es existieren mehrere NOTATIONDefs, jedoch keine im Eigensegment: Es wird eine neue NOTATIONDef im Eigensegment erzeugt. Der Name dieser NOTATIONDef ist frei wählbar, solange er nicht identisch zum Namen einer anderer Attributdefinition dieses Elementtyps ist. Alle Enumerationswerte der anderen NOTATIONDefs werden in die neue NOTATIONDef des Eigensegments eingetragen und die entsprechenden

NOTATIONDefs

aus

den

Vorfahren-

bzw.

Geschwistersegmenten gelöscht. Abbildung 21 zeigt ein Beispiel für Mehrfachvererbung ohne Zusicherungen. BEHANDLUNG DER ZUSICHERUNGEN UND EINBINDUNG DER SEGMENTE

Die Zusicherungen complete, incomplete, disjoint und overlapping werden auf Mengen von Generalisierungen angewandt. Betrachten wir die Menge G = { g1 ,..., gn } von Generalisierungen, wobei ci die Kindklasse von gi und pi die Vaterklasse von gi für i  {1,...,n}. Wenn G die Zusicherung complete trägt, so ist jede Vaterklasse pi implizit abstrakt, die Transformation abstrakter Klassen wird im folgenden Abschnitt Transformation abstrakter Klassen erklärt.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

51

Wenn G die Zusicherung incomplete trägt, so ist jede Vaterklasse pi , die nicht explizit abstrakt ist, eine instanziierbare Klasse. Diese Klassen werden direkt in Elementtypen transformiert. Wenn G die Zusicherung disjoint trägt, so besteht jede Kindklasse ci nur aus Eigen- und Vorfahrensegmenten. Wenn G die Zusicherung overlapping trägt, so besteht jede Kindklasse ci sowohl aus Eigen- und Vorfahrensegmenten, als auch aus Geschwistersegmenten. Die Zusicherungen complete und incomplete sind für implizit abstrakte Vaterklassen zuständig. Disjoint und overlapping hingegen bestimmen die Zusammensetzung der Kindklassen. Abbildung 21: Transformation von Generalisierungen (ohne Zusicherungen)

WissenschaftlicheArbeit

name : ID titel : String format : NOTATION (txt | doc | sdw )

Prüfung

Diplom prüfungsNr : ID abgabe : Date[0..1]

termin : Date prüfer : NOTATION (Professor | ExternerPrüfer) Abbildung 21 demonstriert die Erzeugung und Einbindung von Eigen...

und und

%Prüfung_Inhalt, %Diplom_Inhalt) >



NOTATIONDefs wird hier verdeutlicht. Die Attributdefinitionen format (s. Attributliste WissenschaftlicheArbeit) und prüfer (s. Attributliste Prüfung) werden nicht direkt übernommen, sondern deren Enumerationswerte werden in die neu erzeugte Attributdefinition Apps übernommen. Die Attributdefinition name (s. Attributliste WissenschaftlicheArbeit) wird ebenfalls nicht direkt übernommen, sondern geht mit dem XML-Attributtyp CDATA in den Elementtyp Diplom ein. Die Abbildungen 22 und 23 demonstrieren, wie abstrakte Klassen und Generalisierungszusicherungen bei der Transformation gehandhabt werden. Die Zusicherung complete für die beiden Generalisierungen mit der Vaterklasse Mitarbeiter sorgt dafür, dass diese Klasse implizit abstrakt ist. Die Zusicherung overlapping, sorgt dafür, dass in die Klassen Tutor und Übungsleiter die Geschwistersegmente eingebunden werden. Für den Elementtyp Tutor werden zunächst die einzelnen Segmente gebildet. Dabei ist hervorzuheben, dass das Vorfahrensegment von Tutor bzgl. Person nur einmal eingebunden wird und dass in den Vorfahrensegmenten von Tutor bzgl. Student und Mitarbeiter den Attributdefinitionen matrikelNr und personalNr der Typ CDATA zugewiesen wird. Am Geschwistersegment von Tutor bzgl. Mitarbeiter ist erkennbar, dass dort die Attributdefinitionen der Klassen Ausbilder und Übungsleiter zusammengefasst werden. Der Elementtyp Übungsleiter wird analog zum Elementtyp Tutor aufgebaut, jedoch variieren die Attributdefinitionen in Übungsleiter. Die Attributdefinition personalNr behält den Attributtyp ID, da Übungsleiter über keine eigene IDDef verfügt und personalNr die einzige IDDef in den Vorfahrensegmenten ist.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

Person name : String

Student

Mitarbeiter

matrikelNr : ID

personalNr : ID

Ausbilder extern : (true|false)

{overlapping; complete}

Tutor

Übungsleiter

inLehre:(true|false)

gehalt:int

Abbildung 22: Das zu überführende Modell für eine Transformation von Generalisierungen inkl. abstrakter Klassen und Zusicherungen
#REQUIRED"> #REQUIRED"> #REQUIRED"> #REQUIRED #REQUIRED">



Abbildung 23: Die aus Abbildung 22 resultierenden Markupdeklarationen der Klasse Tutor

53

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD



Abbildung 24: Die aus Abbildung 22resultierenden Markupdeklarationen der Klasse Übungsleiter

Abbildung 25: Die aus Abbildung 22 resultierenden Markupdeklarationen der Klasse Mitarbeiter

54

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

55

TRANSFORMATION ABSTRAKTER KLASSEN Wie bereits im Abschnitt 2.1.3 Generalisierung erläutert wurde existieren zwei Arten von abstrakten Klassen: explizit abstrakte Klassen und implizit abstrakte Klassen. Beide Arten werden auf gleiche Weise transformiert. Abstrakte Klassen werden nicht in Elementtypen transformiert. Sie werden lediglich in den Segmentaufbau ihrer Erben integriert. Um die Vererbungshierarchie der Klasse nachvollziehbar zu gestalten, kann , wie in Abbildung 25 am Beispiel der implizit abstrakten Klasse Mitarbeiter dargestellt, die Segmente der Klasse durch Parameterentitäten repräsentiert und ggf. nachgenutzt werden.

3.1.3 UML-KOMMENTARE UML-Kommentare werden in XML-Kommentare transformiert. Wurde ein UML-Kommentar an mehrere Modellelemente angehängt, so werden entsprechend viele Kommentare erzeugt. Eine Ausnahme bilden UML-Kommentare, die an mehrere Attribute angehängt wurden.

UML-Kommentare, die an Klassen angehängt wurden Der gewonnene XML-Kommentar, welcher aus einem UML-Kommentar gewonnen wurde, der mit einer nichtabstrakten Klasse verbunden wurde, wird direkt vor die entsprechende Elementdeklaration platziert. Wurde der UML-Kommentar mit mehreren Klassen verbunden, so wird vor jede der korrespondierenden Elementdeklarationen ein entsprechender XML-Kommentar erzeugt. UML-Kommentare, die an Attribute gebunden wurden, werden in XML-Kommentare umgewandelt, welche vor die Attributlistendeklaration gesetzt werden. Sollte ein UML-Kommentar mit einer abstrakten Klasse verbunden sein, so wird der gewonnene XML-Kommentar vor die Entität, welche den ISA des Eigensegments dieser Klasse beinhaltet, platziert. Ein UML-Kommentar der mit einem Attribut einer abstrakten Klasse verbunden ist, wird in einen XML-Kommentar überführt, der vor die Entität, welche den ADA des Eigensegments dieser Klasse beinhaltet, platziert.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

56

UML-Kommentare, die an Assoziationen angehängt wurden Jene UML-Kommentare, die eine Aggregation bzw. Komposition kommentieren, werden vor die Elementdeklaration bzw. Parameterentität gestellt, welche aus der Überführung der entspr. Aggregatklasse resultieren. UML-Kommentare von Assoziationsklassen und normalen Assoziationen, die assoziationsorientiert transformiert werden, erzeugen XML-Kommentare, welche vor jene Elementdeklaration gestellt werden, die aus der Überführung der Assoziation hervorgeht und den XLink-Typ extended trägt. Bei normalen klassenorientierter Überführung von Assoziationen werden vor die Elementdeklarationen der beteiligten Klassen je ein XML-Kommentar gestellt.

UML-Kommentare, die an Generalisierungen angehängt wurden Die gewonnenen XML-Kommentare werden sowohl vor alle Elementdeklarationen, die aus den beteiligten Klassen gebildet wurden, gestellt.

UML-Kommentare, die an einem bisher nicht genannten Modellelement angehängt wurden Derartige UML-Kommentare werden ignoriert.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

57

Abbildung 26 zeigt wie Kommentare transformiert und platziert werden. Modell

Assoziation

Klassen

Übung

Vorlesung Generalisierung

1..*

Aufgabe {abstract} name telNr

Programmieraufgabe SchriftlicheAufgabe {abstract}

Attribut telNr

... ... Abbildung 26: Überführung von Kommentaren

Interessant sind vor allem der mehrfach überführte Kommentar „Klassen“ und der Kommentar, welcher mit dem UML-Attribut telNr verbunden ist. Der gewonnene XML-Kommentar wurde vor die Parameterentität des Eigensegment-ADAs gesetzt.

3.1.4 ABHÄNGIGKEITEN Da Pakete per Namenskonvention der Klassen in eine DTD besteht erfolgt die Transformation von «access»-Abhängigkeiten, indem Elementtypen, welche durch Klassen des zugreifenden Pakets erzeugt wurden, Elementtypen, die aus Klassen des zugegriffenen Pakets gewonnen wurden, in der Inhaltsspezifikation referenzieren. Kurz gesagt erfolgt eine implizit Transformation von Zugriffen über die Bildung der Inhaltsspezifikation von Elementtypen.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

58

3.1.5 BEWERTUNG DER TRANSFORMATIONSKONZEPTE KLASSEN UND ATTRIBUTE Die in dieser Arbeit vorgeschlagene Transformation ist gegenüber [ConSchef2000] und [ConSchef2001] verfeinert worden. Die Behandlung von Attributen wurde überdacht und neu konzipiert. Der hier gefundene Weg kommt mit weniger Kompromissen aus. Ebenso wurde die Überführung von Paketen anders gestaltet, als es in den Vorläuferarbeiten der Fall war. Ein wesentlicher Vorteil besteht darin, dass die Zugehörigkeit von Modellelementen leichter Erkennbar ist. Bei stark strukturierten Systemen verliert eine entitätsbasierte Überführung, wie sie in [ConSchef2000] vorgestellt wurde, schnell an Übersichtlichkeit. Neu ist die Behandlung innerer Klassen. Sie stellt einen Kompromiss dar, da Elementtypen nur global deklariert werden können. Bei der Transformation in ein XML-Schema wird eine vollwertige Variante angeboten.

PAKETE Pakete sind im UML-Metamodell, ebenso wie Klassen, UML-Namensräume. Das bedeutet, dass Pakete und Klassen andere Modellelemente beinhalten können. Bei Paketen sind dies im allgemeinen Klassen und deren Beziehungen, bei Klassen sind dies im allgemeinen andere Klassen. Ein Konzept zur Strukturierung von XML-Elementen und XML-Attributen stellen Namensräume (s. [XMLNames99]) dar. Hierbei handelt es sich um disjunkte logische Mengen von XML-Elementen und XML-Attributen, die durch Attribute zum Ausdruck gebracht werden. Im Gegensatz zu UMLNamensräumen gibt es jedoch kein Sichtbarkeitskonzept und keine Möglichkeit der Verschachtelung. Die Bildung der XML-Namensraumpräfixe, welche im Abschnitt 3.1.1 Klassen, Pakete und Attribute angeboten wird, erhält zwar in gewisser Hinsicht die Pakethierarchie, allerdings geht hierbei das Sichtbarkeitsprinzip verloren. Jedoch verfügt die Beschreibungssprache für DTDs keinerlei Konzepte hierfür.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

59

Der Nachteil besteht in in der inkonsistenten Namensgebung. Die Namen innerer Klassen sind nicht mehr konsistent zu den Namen der Klassen, die sie umschließen. Jedoch besteht der Vorteil dieser Methode im Vergleich zum Entitätskonzept aus [ConSchef2000], dass die Elementtypen leichter zu nutzen sind und die Pakethierarchie wesentlich einfacher zu durchschauen ist.

ASSOZIATIONEN GEWÖHNLICHE ASSOZIATIONEN Alle hier vorgestellten Transformationsvarianten von Assoziationen sind nicht typsicher. D.h. es kann nicht gewährleistet werden, dass ein Hyperlink bzw. die in einem IDREF-Attribut angegebene ID auf ein Element verweisen, welches den Elementtyp aufweist, der mit jener Klasse im UMLModell korrespondiert, die an der Assoziation beteiligt ist. Die assoziationsorientierte Transformation bietet als einzige Variante die Möglichkeit, sowohl n-äre Assoziationen als auch Assoziationsklassen zu transformieren. Ein Vorteil dieses Vorgehens besteht außerdem darin, dass bereits vorhandene und nicht mehr änderbare XML-Dokumente um neue Assoziationen bereichert werden können. Des weiteren können mit diesem Verfahren Elemente dokumentübergreifend in Beziehung gebracht werden. Als Nachteil zeigte sich, dass Multiplizität und Navigation nicht zwingend eingehalten werden müssen. Außerdem ist es zwar vorgesehen, dass jeder Link/Tupel durch genau eine Elemente repräsentiert wird, jedoch kann die Vorschrift auch zur Instanziierung mehrerer Links innerhalb eines extended link-Elements benutzt werden. Man ist hier auf die Disziplin der Entwickler und Anwender angewiesen. Auch der zu betreibende Aufwand bei der Instanziierung ist nicht unerheblich. Bei normalen binären Assoziationen ist diese Art der Transformation aufgrund der zu vergebenden Namen und dem Umfang an Elementen viel zu aufwendig. Die attributbasierte klassenorientierte Transformation bietet den Vorteil, dass die Namen der Attribute kurz sind und der Inhalt eines Elements nicht unnötig aufgestockt wird. Allerdings ist die Einschränkung auf Dokumentenebene ein erheblicher Nachteil. Klare Vorteile erzielt man bei binären

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

60

Assoziationen, bei denen sich alle beteiligten Elemente in einem Dokument befinden. Dies ist jedoch im allgemeinen erst nach der physischen Modellierung bekannt. Abhilfe leistet dagegen die inhaltsbasierte klassenorientierte Transformation. Binäre Assoziationen mit dokumentübergreifendem Charakter sind primäre Einsatzmöglichkeiten. Die Variante verfügt zwar über eine ähnlich umständliche Namensgebung wie die assoziationsorientierte Transformation, aber der Einsatz von XLink hebt die Dokumentbeschränktheit auf.

AGGREGATIONEN UND KOMPOSITIONEN Teil-Ganzes-Beziehungen in Form von Aggregationen oder Kompositionen sind – unabhängig vom Verfahren – zum Teil mit Informationsverlusten transformierbar. Insbesondere die starke Bindung bei Kompositionen kann aufgrund der Beschaffenheit von XML nicht mehr zur Geltung kommen. Der dargestellte Vorschlag für eine Transformation bietet jedoch die Möglichkeit die Anordnungsfreiheit der aggregierten Klassen zu erhalten. Der Nachteil besteht in einem exponentiellem Wachstum der Inhaltsspezifikationen in der Anzahl der aggregierten Klassen. Daher sollten nur Klassen mit einer kleinen Anzahl von aggregierten Klassen mit diesem Verfahren transformiert werden. Wie man später bei XML-Schema sehen wird, lohnt es sich jedoch diesen Aspekt im Auge zu behalten, da dort die Inhaltsspezifikation eines Elementtyps nur noch linear mit der Anzahl der Aggregationen wächst.

GENERALISIERUNG Auch in diesem Bereich sind Fortschritte erzielt worden. Der Einsatz von Vererbung ist nun nicht mehr auf Dokumentenebene beschränkt. Außerdem wurden Zusicherungen in diesem Bereich präziser nachgebildet. Die Überführung von Generalisierungen sind aufgrund mangelnder äquivalenter Konzepte in einer DTD der wohl aufwendigste Teil einer Modelltransformation. Insbesondere die Verarbeitung der Zusicherungen erzeugen einen erheblichen Arbeitsaufwand, da für jede Kindklasse die Vorfahren- und Geschwistersegmente aufgrund von ID und NOTATION-Attributdefinitionen neu ermittelt werden müssen. Wie bereits in [ConSchef2000]

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

61

und [ConSchef2001] verliert man bei der Transformation einer Generalisierung die ihr innewohnende „Ist-Ein“-Beziehung. Dies ist auf einen fehlenden Austauschmechanismus unter Elementen, wie er in XML-Schema existiert, zurückzuführen.

3.2 INDIREKTE TRANSFORMATION Im vorangegangenen Abschnitt wurde gezeigt, wie die Konzepte eines Klassendiagramms direkt in DTD-Konzepte überführt werden können. Die Bewertung ergab, dass einige UML-Konzepte nur ungenügend bzw. gar nicht übersetzt werden können. Nun wird eine Varianten vorgestellt, eine DTD direkt zu modellieren. Der Sinn dieses Abschnitts besteht darin, die Grundlagen für das Anpassen von konzeptuellen Datenmodellen an DTDKonzepte zu legen.

3.2.1 DAS DTD-PROFIL Die UML beinhaltet unter anderem einen Erweiterungsmechanismus, der es erlaubt, Modellelementen eine erweiterte Semantik zukommen zu lassen. Dies geschieht durch Verwendung von Stereotypen, Zusicherungen und Merkmalen. Ein Profil ist eine Menge von Stereotypen, Zusicherungen, Merkmalen und Notationssymbolen, welche die UML für eine spezielle Domäne bzw. einen speziellen Prozess spezialisieren und anpassen. In diesem Abschnitt wird ein Profil vorgestellt, mit dessen Hilfe Elementtypen, PI oder Entitäten modelliert werden können. Das DTD-Profil bietet somit die Möglichkeit mit Hilfe der visuellen Modellierung der UML eine DTD direkt zu konzipieren. Den Kern dieses Profils machen seine Stereotypen, sowie die beiden Konzepte Positionierung und Nummerierung, welche durch Merkmale und Zusicherungen realisiert werden, aus. Die Stereotypen dieses Profil sind in Tabelle 1 aufgeführt.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

Stereotyp

Modell-

62

Beschreibung

element Namensraum

Paket

Repräsentiert einen XML-Namensraum.

ElementTyp

Klasse

Repräsentiert eine Element- und deren zugehörige Attributlistendeklaration.

Anweisung

Kommentar Repräsentiert eine PI

Format

Klasse

Repräsentiert ein Format bzw. eine Formatdeklaration

Entität GenerelleEntität &

-------------Klasse

Ein abstrakter Stereotyp für Entitäten Zwei abgeleitete Stereotypen, eine generelle Entität bzw. Parameteren-

Parameterentität

tität und deren zugehörige Entitätsreferenzen repräsentieren. Entitätswert

Kommentar Dient der Deklaration eines textuellen Wertes für eine Entität.

Inhaltsspezifikation

Ein abstrakter Stereotyp für ------------- Inhaltsspezifikationen bzw. Gruppen innerhalb einer Inhaltsspezifikation.

Sequence & Auswahl Klasse

Stereotypen die von Inhaltsspezifikation abgeleitet sind. Sie repräsentieren eine Inhaltsspezifikation bzw. Gruppen innerhalb einer Inhaltsspezifikation, die nach den Syntaxregeln [47] bis [50] in [XML1.0SE] gebildet werden. Diese Regeln produzieren eine Inhalts(teil)spezifikation, die reinen Elementinhalt deklariert.

Mixed

Klasse

Ein zu Sequence und Auswahl analoger Stereotyp, der eine Deklaration von gemischtem Elementinhalt gemäß der Syntaxregel [51] in [XML1.0SE] repräsentiert.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

Stereotyp

Modell-

63

Beschreibung

element Leer

Klasse

Ein Substereotyp von Inhaltsspezifikation, der die Spezifikation EMPTY repräsentiert

Beliebig

Klasse

Ein Substereotyp von Inhaltsspezifikation, der die Spezifikation ANY repräsentiert

Tabelle 1: Stereotypen des DTD-Profils

Eine Nummerierung ist ein Konzept, dass aus [ConSchef2000] entnommen wurde und ist entweder ein position-Merkmal oder eine absolute Positionierungszusicherung. Nummerierungen werden bei «Sequenz»-Klassen und durch Entitätsklassen angewendet und die vergebenen Nummern sind in einem bestimmten Kontext eindeutig. Hierbei steht die Anordnung von Bestandteilen der erzeugten DTD-Konzepte im Mittelpunkt. Eine Positionierung ist ein zur Nummerierung analoges Konzept und besteht aus einer relativen und wahlweise einer zusätzlichen absoluten Positionierungszusicherung. Eine absolute Positionierungszusicherung besteht lediglich aus einer natürlichen Zahl. Relative Positionierungszusicherungen sind before und after. Eine Positionierung wird vorwiegend bei Kommentaren (mit und ohne Stereotyp) angewandt. Die Anwendung derartiger Zusicherungen beschreibt die relative Anordnung von DTD-Konzepten als Ganzes. Die Anwendung von Nummerierungen und Positionierungen wird im Folgenden noch näher erläutert. In den folgenden Abschnitten werden die Konzepte dieses Profils erläutert. Jeder dieser Abschnitte, welche sich an den DTD-Konzepten orientieren, ist in die folgenden optionalen Teilabschnitte unterteilt: 

Implizite Zusicherungen beinhaltet alle Zusicherungen, die den im Abschnitt behandelten Stereotypen zu eigen sind.



Vordefinierte Zusicherungen behandelt jene Zusicherungen, die nicht implizit sind, jedoch auf Modellelemente, welche die behandelten Stereotypen tragen, angewandt

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

64

werden können. Die Zusicherungen werden in Form einer Tabelle aufgeführt, welche die folgenden Spalten hat. Name

Bezeichner bzw. Ausprägung der Zusicherung

Beschreibung

Art und Verwendung der Zusicherung

Anwendung

Art der Modellelemente, auf die diese Zusicherung angewendet werden kann.

Tabelle 2: Legende für Zusicherungstabellen 

Merkmaldefinitionen behandelt alle Merkmaldefinitionen des Stereotyps, sowie deren Verwendung in Form einer Tabelle. Die folgende Tabelle beschreibt die Spalten dieser Tabelle. Name

Der Name des Merkmals

Beschreibung

Art und Verwendung des Merkmals

Typ

Datentyp des Wertes

Anzahl

Anzahl der Werte, die ein Merkmal annehmen kann

Tabelle 3: Legende für Merkmaltabellen 

Zulässige Beziehungen beinhaltet alle Beziehungen zwischen Modellelemente, welche die behandelten Stereotypen tragen. Jede nicht in diesem Abschnitt aufgeführte Form der Beziehung ist unzulässig. Des weiteren sind bei Assoziationen nur die Multiplizitäten 1, 0..1, * und 1..* erlaubt. Diese Multiplizitäten werden fortan Standardmultiplizitäten genannt.



Transformation zeigt die Transformation der Modellelemente, welche die behandelten Erweiterungsmechanismen tragen, in DTD-Konzepte.

«NAMENSRAUM»-PAKETE Pakete mit den Stereotypen Namensraum repräsentieren einen XMLNamensraum.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

65

Implizite Zusicherungen 

Der Name des Pakets muss der XML-Namensraum-Syntaxregel NCName genügen (s. [XMLNames99])



Jedes «Namensraum»-Paket muss ein uri-Merkmal tragen



Ein «Namensraum»-Paket darf nur Modellelemente enthalten, die mit Stereotypen des DTD-Profils versehen sind. Des weiteren sind Assoziationen, Generalisierungen und Kommentare, die keinen Stereotyp tragen, erlaubt.



Ein «Namensraum»-Paket kann an keiner Generalisierung beteiligt sein. D.h. für ein «Namensraum»-Paket sind die Metaattribute isRoot und isLeaf mit true belegt.

Merkmaldefinitionen Nam Beschreibung e uri

Typ Anzah l

beinhaltet die URI des XML-Namensraum. Hierbei Strin muss es sich um eine gültige URI handeln. g

1

Tabelle 4: Merkmaldefinitionen des Stereotyps «Namensraum»

Zulässige Beziehungen 

Ein «Namensraum»-Paket kann Quelle und/oder Ziel einer «access»Abhängigkeit sein.

Transformation Die Umwandlung von «Namensraum»-Paket macht sich bei der Transformation derjenigen «Elementtyp»-Klassen und gewöhnlichen Assoziationen bemerkbar, die im «Namensraum»-Paket enthalten sind. Zum einen fließt die Pakethierarchie in die Namen der erzeugten Elementtypen ein. Dies geschieht analog zu den Abschnitten 3.1.1 Klassen, Pakete und Attribute, sowie 3.1.2 Beziehungen Abschnitt Assoziationen. Zusätzlich erhält jeder dieser Elementtypen folgende XML-Namensraumdeklaration: xmlns:paket1_..._paketn CDATA "Wert des uri-Merkmals"

#FIXED

., wobei paket1 bis paketn die Namen der Pakete innerhalb der Pakethierarchie sind.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

66

Abhängigkeiten mit dem Stereotyp access werden transformiert, indem eine beliebige Anzahl von Elementtypen, welche durch Modellelemente des zugegriffenen Pakets erzeugt wurden, in einer oder mehreren Inhaltsspezifikationen von Elementtypen des zugreifenden Pakets referenziert werden.

Lehre «Namensraum»

Lehrstuhl WiMi

Lehrstuhl «ElementTyp»

abteilung 0..1

beschäftigt

angestellter 1..*

WiMi «ElementTyp»



Abbildung 27: Die Transformation von Klassen und Attributen

Abbildung 27 zeigt die Überführung der «ElementTyp»-Klassen Lehrstuhl und WiMi, die sich im «Namensraum»-Paket Lehre befinden. Die erzeugten Elementtypen erhalten sowohl alle den Namensraumpräfix Lehre als auch eine entsprechende XML-Namensraumdeklaration. Bei der assoziationsorientierten Transformation der Assoziation beschäftigt erhalten alle Elementtypen - sowohl jene mit dem XLink-Typ extended als auch die Resourcen-

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

67

deklarationen - den XML-Namensraumpräfix Lehre und die entsprechende XML-Namensraumdeklaration.

«ELEMENTTYP»-KLASSEN UND DIE ZUGEHÖRIGE INHALTSSPEZIFIKATION «ElementTyp»-Klassen repräsentieren Elementtypen innerhalb einer DTD. Die Zusicherung «Inhaltsspezifikation» ist eine abstrakte Zusicherung, die keine Anwendung findet, jedoch Zusicherungen mit sich bringt, die sie an ihre Spezialisierungen weiter gibt. Es gibt 3 Spezialisierungen: «Sequenz», «Auswahl» und «Mixed». Klassen, die diese Spezialisierungen innehaben, heißen Inhaltsklassen.

Implizite Zusicherungen 

Der Name einer «ElementTyp»-Klasse, sowie die Namen der Attribute einer «ElementTyp»-Klasse müssen der XML-Syntaxregel Name (s.[XML1.0SE]) genügen.



Der Name einer Inhaltsklasse ist beliebig wählbar, da dieser bei der Transformation ignoriert wird.



Eine «ElementTyp»-Klasse beinhaltet keine Modellelemente.



Eine «ElementTyp»-Klasse besitzt nur Instanzattribute, d.h. sie besitzt keine Klassenattribute. Alle Attribute einer «ElementTyp»-Klasse haben einen für eine DTD gültigen Attributtyp (s. 2.2.1 DTD). Jede «ElementTyp»-Klasse besitzt höchstens ein Attribut mit dem Typ ID und kein Attribut vom Typ NOTATION, da Formatierungsattribute durch Assoziationen mit «Format»-Klassen ausgedrückt werden. Es sind nur die Standardmultiplizitäten erlaubt. Alle Attribute tragen die Sichtbarkeit public.



Eine «ElementTyp»-Klasse aggregiert maximal eine Inhaltsklasse

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

68

Vordefinierte Zusicherungen Name

Beschreibung

pcdata

Der zu erzeugende Elementtyp enthält nur «ElementTyp»Zeichendaten. Eine «ElementTyp»-Klasse Klasse mit dieser Zusicherung darf keine Inhaltsklasse aggregieren.

leer

Der zu erzeugende Elementtyp darf keinen «ElementTyp»Elementinhalt tragen. Eine «ElementTyp»- Klasse Klasse mit dieser Zusicherung darf keine Inhaltsklasse aggregieren.

beliebig

Der zu erzeugende Elementtyp darf belie- «ElementTyp»bigen Elementinhalt tragen. Eine «Ele- Klasse mentTyp»-Klasse mit dieser Zusicherung darf keine Inhaltsklasse aggregieren.

ganzzahlige s. Merkmal position Nummer

Anwendung

Aggregationen

Tabelle 5: Vordefinierte Zusicherungen für «ElementTyp»-Klassen

Merkmaldefinitionen Name

Beschreibung

Typ

Anzahl

position Beschreibt eine absolute Positionierungszusi- Integer 1 cherung und wird auf Aggregationen angewendet, deren Aggregat eine «Sequenz»-Klasse ist. Tabelle 6: Merkmaldefinitionen des Stereotyps «ElementTyp»

Zulässige Beziehungen 

Eine «ElementTyp»-Klasse kann zu einem «Namensraum»-Paket gehören.



Es können beliebig viele gewöhnliche Assoziationen zwischen «ElementTyp»-Klassen gebildet werden.



Eine «ElementTyp»-Klasse kann mit beliebig vielen «Format»-Klassen einer gewöhnliche 1:1-Assoziation teilnehmen. Eine «ElementTyp»Klasse darf zu jeder «Format»-Klasse höchstens eine Assoziation haben, d.h. es darf keine zwei oder mehr Assoziationen zwischen einer «ElementTyp»-Klasse und einer «Format»-Klasse geben.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD



69

Eine «ElementTyp»-Klasse kann Vaterklasse beliebig vieler Generalisierungen sein. Es ist zulässig die Standardzusicherungen für Mengen von Generalisierungen anzuwenden.



Eine «ElementTyp»-Klasse, die eine pcdata-, leer- oder beliebig-Zusicherung trägt, darf keine Inhaltsklasse aggregieren.



Eine «ElementTyp»-Klasse kann in folgenden Fällen an einer Aggregation beteiligt sein: 

als Aggregat darf höchstens eine Inhaltsklasse aggregiert werden. Hierbei muss die Multiplizität auf Seite der «ElementTyp»-Klasse 1 betragen. Auf Seite der Inhaltsklasse ist wie folgt zu unterscheiden: 

die Inhaltsklasse trägt den Stereotyp «Mixed», dann darf die Multiplizität auf seiten dieser Klasse nur * betragen.



Die Inhaltsklasse trägt den Stereotyp «Beliebig» oder «Leer», dann darf die Multiplizität auf seiten dieser Klasse nur 1 betragen.



Die Inhaltsklasse trägt den Stereotyp «Sequenz» oder «Auswahl», dann darf die Multiplizität auf seiten dieser Klasse eine beliebige Standardmultiplizität sein.



als aggregierte Klasse kann eine «ElementTyp»-Klasse nur von Inhaltsklassen aggregiert werden. Die Multiplizität der «ElementTyp»-Klasse darf nur eine Standardmultiplizität sein. Die Multiplizität der Inhaltsklasse beträgt 1. Werden mehrere «ElementTyp»-Klassen durch eine «Sequenz»-klasse aggregiert, so muss jede dieser Aggregationen eine Nummerierung aufweisen, die unter diesen Aggregationen eindeutig ist. Während die Inhaltsspezifikation erzeugt wird, werden die darin enthaltenen Deklarationsreferenzen, welche aus den Aggregationen erzeugt werden, anhand der Nummerierungen angeordnet. Wird eine «ElementTyp»-Klasse durch eine «Auswahl» oder eine «Mixed»-Klasse aggregiert, so darf diese «ElementTyp»-Klasse kein zweites Mal durch diese Aggregatklasse aggregiert werden, d.h. es dürfen keine zwei Aggregationen zwischen einer «ElementTyp»Klasse und derselben «Auswahl» bzw. «Mixed»-Klasse existieren.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

70

Das liegt daran, dass die folgenden Inhaltsgruppen semantisch identisch sind: (A|B|A) (A|B|A|#PCDATA)* 

 (A|B)  (A|B|#PCDATA)*

und

Eine «Sequenz»-, «Mixed» oder «Auswahl»-Klasse darf nur «ElementTyp»-, «Parameterentität»-, sowie «Auswahl»- und «Sequenz»Klassen (einschließlich sich selbst) aggregieren. Hierbei dürfen die betreffenden «Parameterentität»-Klassen wiederum nur genau eine Inhaltsklasse aggregieren. Die Assoziationsenden der aggregierten Klassen dürfen nur Standardmultiplizitäten tragen. Die Multiplizität auf der Seite des Aggregats beträgt 1.

Transformation Klassenname, Attribute, Generalisierungen und Assoziationen werden analog zum Abschnitt 3.1 Direkte Modelltransformation umgewandelt. Bei der Bildung einer Inhaltsspezifikation wird wie folgt vorgegangen: 

Der Name der Inhaltsklasse wird ignoriert.



Wenn eine «ElementTyp»-Klasse weder eine Inhaltsklasse aggregiert, noch keine pcdata-Zusicherung trägt, so erhält der erzeugte Elementtyp die Inhaltsspezifikation EMPTY.



Bei einer «ElementTyp»-Klasse, die eine pcdata-Zusicherung trägt, lautet die Inhaltsspezifikation „(#PCDATA)“.



Ansonsten wird die Inhaltsspezifikation analog zum Stereotyp der aggregierten Inhaltsklasse gebildet. Für jede aggregierte «ElementTyp»Klasse wird eine Referenz auf den entsprechende Elementtyp eingetragen.

Die Multiplizität mit der die Inhaltsklasse bzw. die aggre-

gierten «ElementTyp»-Klasse an der jeweiligen Aggregation teilnimmt, wird in die entsprechende XML-Multiplizität (s. Abschnitt Direkte Modelltransformation-Die assoziationsorientierte Umwandlung) überführt und hinter die schließende Klammer der Inhaltsspezifikation bzw. der entsprechenden Referenz geschrieben. Bei aggregierten Inhaltsklassen, wird analog eine entsprechende Untergruppe gebildet. Eine aggregierte «Parameterentität»-Klasse wird in eine Referenz auf die ent-

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

sprechende

Entität

umgewandelt.

Bei

der

Transformation

71 von

«Sequenz»-Klassen werden die Referenzen bzw. Untergruppen innerhalb der erzeugten Sequenz in der entsprechenden Reihenfolge der Nummerierungen für die aggregierten Klassen eingetragen. 

Die Menge der Assoziationen von einer «ElementTyp»-Klasse zu verschiedenen «Format»-Klassen wird in ein Formatierungsattribut überführt. Die Enumerationswerte dieses Formatierungsattributs sind die Namen aller «Format»-Klassen, die an den o.g. Assoziationen beteiligt sind.

Wird eine «ElementTyp»-Klasse durch eine «Parameterentität»-Klasse aggregiert, so wird eine Parameterentität erzeugt, deren Wert die von der «ElementTyp»-Klasse erzeugten Element- und Attributlistendeklarationen sind. Abbildung 28 zeigt die Überführung von «ElementTyp»- und Inhaltsklassen. Die «ElementTyp»-Klassen werden hierbei alle in eine Elementdeklaration und eine Attributlistendeklaration umgewandelt. Hierbei wird sowohl gezeigt, wie Inhaltsspezifikationen erzeugt werden (s. Klassen PersonInhalt und NameInhalt), als auch demonstriert, wie mehrfach referenzierte Elementtypen (z.B. TelefonNr) modelliert werden. Die «Parameterentität»-Klasse Name wird in eine Parameterentität mit dem selben Bezeichner überführt. Diese Parameterentität beinhaltet eine Inhaltsspezifikation, die nun mehrfach verwendbar ist. Im Gegensatz dazu beinhaltet die Parameterentität AbtMakro sowohl eine Element- als auch eine Attributlistendeklaration. Somit wird es möglich einen einzelnen Elementtyp physisch zu exportieren, anstatt das gesamte zugegriffene DTD-Subset zu in das zugreifenden DTD-Subset zu exportieren.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

72

«ParameterEntität» AbtMakro

«ElementTyp» Abteilung

«ElementTyp» Person

Kst-Stelle:CDATA [0..1]= "0815"

land:CDATA = "D" {frozen} «Format» GIF {system=“dateiname“}

«Sequenz» AbteilungInhalt

«Auswahl» PersonInhalt

1 1 0..1 «ElementTyp» Bild

* «ParameterEntität» Name

1 1..* {1} «ElementTyp» TelefonNr {pcdata}

1..* «Sequenz» NameInhalt

{3} 0..1 «ElementTyp» Nachname {leer}

{1} 1 «ElementTyp» Titel

{2} * «ElementTyp» Vorname


(%Name;* | TelefonNr | Bild?)> land CDATA #FIXED "D">


NOTATION (GIF)>

Nachname EMPTY> Vorname EMPTY> Titel EMPTY> Aggregationen und Kompositionen mit «ElementTyp»-, Inhaltsund «Parameterentität»-Klassen

Abbildung 28 zeigt die Transformation von «ElementTyp»- und Inhaltsklassen. Die Transformation der Klasse Person, zeigt den „Normalfall“ einer derartigen Transformation. Es wird je eine Element- und Attributlistendeklaration mit dem Namen Person erzeugt. Die «Auswahl»-Klasse

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

73

PersonInhalt und die zugehörigen Aggregationen werden in die Inhaltsspezifikation des Elementtyps Person umgewandelt. Hierbei werden die Aggreagationen mit den Klassen Bild und TelefonNr auf die in Referenzen auf diese umgewandelt. Die Verwendung der Merkmale leer und pcdata, sowie das Fehlen einer aggregierten Inhaltsklasse bei einer «ElementTyp»-Klasse wird am Beispiel der Klassen TelefonNr, Nachname und Titel gezeigt. Die mehrfache Einbindung der «ElementTyp»-Klasse TelefonNr in Aggregationen mit Inhaltsklassen zeigt, dass ein Elementtyp in mehreren Inhaltsspezifikationen referenziert werden kann. Es ist natürlich auch möglich, dass eine «ElementTyp»-Klasse mehrmals durch die selbe «Sequenz»Klasse aggregiert wird. Es ist jedoch darauf zu achten, dass jede dieser Aggregationen eine Nummerierung aufweist. Abbildung 29 stellt diesen Fall anschaulich dar. Die Kapselung von Teilen einer Inhaltsspezifikation wird mit Hilfe der «Parameterentität»-Klasse Name vorgenommen. Die «Sequenz»-Klasse NameInhalt und die Aggregationen zu den «ElementTyp»-Klassen Vorname, Titel und Nachname modellieren den zu kapselnden Teil einer Inhaltsspezifikation. Die Komposition zwischen der «Parameterentität»Klasse Name und der «Sequenz»-Klasse NameInhalt repräsentiert die Einbindung dieses Spezifikationsteils in den Wert der Parameterentität Name. Die vollständige Kapselung eines Elementtyps wird am Beispiel der Klassen AbtMakro und Abteilung gezeigt. Die «ElementTyp»-Klasse Abteilung wird in eine Element- und eine Attributlistendeklaration überführt. Die Komposition zwischen AbtMakro und Abteilung modelliert die Einbindung dieser Deklarationen in den Wert der zu erzeugenden Parameterentität AbtMakro. Die Transformation einer Assoziation zwischen «Format»- und «ElementTyp»-Klassen wird am Beispiel der Klassen GIF und Bild dargestellt. Hierbei wird ein Formatierungsattribut, sowie eine Attributlistendeklaration für den Elementtyp Bild erzeugt.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

74

Abbildung 29 zeigt die Modellierung einer mehrfachen Aggregation am Beispiel eines Diploms und seiner zwei Gutachter. Da ein Diplom von zwei Gutachtern beurteilt werden muss, wird im Modell die «ElementTyp»Klasse Gutachter zweimal in die Inhaltsspezifikation der «ElementTyp»Klasse Diplom eingebunden. «ElementTyp» Diplom

«Sequenz» Diplom_Inhalt

{1}

{2} «ElementTyp» Gutachter

typ : (Erstgutachter | Zweitgutachter)

Abbildung 29: Mehrfachaggregationen zwischen «ElementTyp»- und Inhaltsklassen

«ANWEISUNG»-KOMMENTARE Diese Art der Kommentare repräsentiert eine XML-Anweisung. Der Text des Kommentars stellt die an eine Applikation weiterzureichenden Daten dar. Diese Applikation wird durch einen XML-Prozessor als Hilfsanwendung hinzugezogen wird.

Implizite Zusicherungen 1. Jeder «Anweisung»-Kommentar besitzt ein target-Merkmal, und/oder ist mit einer «Format»-Klasse verbunden. Sollte der Name derjenigen «Format»-Klasse, mit der ein «Anweisung»-Kommentar verbunden ist, kein gültiger Name für einen «Anweisung»-Kommentar sein, so muss der «Anweisung»-Kommentar ein target-Merkmal vorweisen.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

75

Vordefinierte Zusicherungen Name

Beschreibung

after

Eine relative Positionierungszusicherung, die Verbindungen ausdrückt, dass die zu erzeugende XMLAnweisung vor das XML-Konzept, welches aus dem verbundenen Modellement gewonnen wird, platziert wird.

before

analog zu after

ganzzahlige absolute Positionierungszusicherung. Nummer Merkmal position

Anwendung

Verbindungen s. Verbindungen

Tabelle 7: Vordefinierte Zusicherungen für «Anweisung»-Kommentare

Merkmaldefinitionen Name

Beschreibung

Typ

Anzah l

position

Beschreibt eine absolute Positionierungszusi- Integer cherung und wird auf Verbindungen mit ElementTyp»-, «Format»- und Entitätsklassen angewendet.

1

target

bezeichnet die Applikation, welche diese String Anweisung verarbeiten soll. Der Wert des Merkmals muss der XML-Syntaxregel PITarget (s.[XML1.0SE]) genügen.

1

Tabelle 8: Merkmaldefinitionen des Stereotyps «Anweisung»

Zulässige Beziehungen 

Ein «Anweisung»-Kommentar kann an beliebig viele «ElementTyp»Klassen und Entitätsklassen angehängt werden. Jede Verbindung muss eine relative Positionierungszusicherung tragen. Before/After drückt aus, dass die Anweisung, welche aus dem «Anweisung»-Kommentar erzeugt wird, vor der Elementdeklaration/Entität bzw. nach der Attributlisten-deklaration/Entität positioniert wird. Wurden der Klasse mehrere Kommentare mit gleicher relativer Positionierungszusicherung angehängt, so muss diese um eine absolute Positionszusicherung ergänzt werden, die unter allen Verbindungen mit derselben relativen Positionierungszusicherung eindeutig ist.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD



76

Ein «Anweisung»-Kommentar kann an höchstens eine «Format»-Klasse angehängt werden.

Transformation Jeder «Anweisung»-Kommentar wird in so viele Anweisungen transformiert, wie er mit Klassen verbunden ist. Verfügt der «Anweisung»-Kommentar über ein target-Merkmal, so ist der Applikationsname der Anweisung identisch mit dem Wert dieses Merkmals. Andernfalls dient der Name der «Format»-Klasse, mit welcher der «Anweisung»-Kommentar verbunden ist,

als Applikationsnamen der zu erzeugenden Anweisungen. Die

erzeugten Anweisungen werden gemäß den Positionszusicherungen platziert. Eine Anweisung, die aus einem «Anweisung»-Kommentar erzeugt wurde, welcher an keine «ElementTyp»-Klasse angehängt wurde, wird zu Beginn eines DTD-Subset bzw. einer Dokumenttypdeklaration positioniert. «Anweisung»

{target = Printer2} newLine(3) {before;2}

{before;3}

Keine Tutoren !!

«Format» Printer

«Anweisung» newPage {before;1}

«ElementTyp» Student MatrikelNr:CDATA

{system="dateiname "}

{after}

«ElementTyp»

Programmieraufgabe


#REQUIRED>

Abbildung 30: Transformation von «Format» -Klassen und «Anweisung»-Kommentaren

Abbildung 30 zeigt wie «Anweisung»-Kommentare und «Format»-Klassen transformiert werden. Insbesondere die Verwendung der Positionierungszusicherungen werden am Beispiel der «ElementTyp»-Klasse Student gezeigt.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

77

«FORMAT»-KLASSEN «Format»-Klassen repräsentieren Formatdeklarationen in der XML und dienen der Einbindung von Applikationen.

Implizite Zusicherungen 

Der Name einer «Format»-Klasse muss der XML-Syntaxregel Name (s.[XML1.0SE]) genügen.



Eine «Format»-Klasse trägt keine Attribute

Merkmaldefinitionen Name

Beschreibung

Typ

Anzahl

system

bezeichnet den system identifier, welcher den String Ort beschreibt, an dem sich die Applikation befindet. Der Wert des Merkmals muss der XML-Syntaxregel SystemLiteral (s. [XML1.0SE]) genügen.

1

public

bezeichnet den public identifier. Der Wert des String Merkmals muss der XML-Syntaxregel PubidLiteral (s. [XML1.0SE]) genügen.

1

position Beschreibt eine absolute Positionierungszusi- Integer cherung und wird auf Aggregationen angewendet, deren Aggregat eine «Sequenz»Klasse ist.

1

Tabelle 9: Merkmaldefinitionen des Stereotyps «Format»

Zulässige Beziehungen 

Eine «Format»-Klasse kann mit beliebig vielen «Anweisung»-Kommentar verbunden sein. Die «Format»-Klasse repräsentiert die Applikation, mit deren Hilfe die Anweisung, welche aus dem «Anweisung»Kommentar erzeugt wird, verarbeitet wird.



Eine «Format»-Klasse kann höchstens eine 1:1-Assoziation zu einer «Parameterentität»- bzw. «GenerelleEntität»-Klasse haben. Voraussetzung hierfür ist, dass die «Parameterentität»- bzw. «GenerelleEntität»Klasse keine andere Klasse aggregiert.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

78

Transformation Eine «Format»-Klasse wird in eine Formatdeklaration überführt. Der Name der zu erzeugenden Formatdeklaration ist mit dem Namen der Klasse identisch. Ein vorhandenes system oder public-Merkmal wird in einen external identifier überführt. Die Transformation der Verbindungen zu «Anweisung»-Kommentaren, sowie von Assoziationen mit «ElementTyp»- und «Parameterentität»- bzw. «GenerelleEntität»-Klassen werden in den Abschnitten «Anweisung»-Kommentare,

«ElementTyp»-Klassen bzw.

Entitätsklassen dieses Kapitels erläutert. Abbildung 28 zeigt die Transformation von «Format»-Klassen.

ENTITÄTSKLASSEN Der Stereotyp «Entität» ist - wie auch der Stereotyp «Inhaltsspezifikation» ein abstrakter Stereotyp. Er besitzt die beiden Substereotypen «Parameterentität» und «GenerelleEntität». Diese Stereotypen sind nur auf Klassen anwendbar. Unter dem Begriff Entitätsklassen werden all jene Klassen zusammengefasst, die einen Substereotyp von «Entität» tragen. Eine Klasse, die den Stereotyp «Parameterentität» trägt, repräsentiert die Deklaration einer Parameterentität. Analog repräsentiert eine «GenerelleEntität»-Klasse die Deklaration einer generellen Entität. Der Stereotyp «Entitätswert» wird ausschließlich auf Kommentare angewandt und steht für eine Teil eines textuellen Wertes, den eine generelle Entität annehmen kann. Hierbei handelt es sich NICHT um Fragmente von Markupdeklarationen.

Implizite Zusicherungen 

Der Name einer Entitätsklasse muss der XML-Syntaxregel Name (s.[XML1.0SE]) genügen.



Eine Entitätsklasse trägt keine Attribute

Vordefinierte Zusicherungen Name

Beschreibung

ganzzahlige absolute Positionierungszusicherung. Nummer Merkmal position Tabelle 10: Vordefinierte Zusicherungen für Entitätsklassen

Anwendung s. Aggregationen

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

79

Merkmaldefinitionen Name

Beschreibung

Typ

Anzah l

position Beschreibt eine absolute Positionierungszusi- Integer cherung und wird auf Aggregationen angewendet, deren Aggregat eine «Sequenz»Klasse ist.

1

Tabelle 11: Merkmaldefinitionen des Stereotyp «Parameterentität»

Zulässige Beziehungen 

Eine «Parameterentität»-Klasse kann als Aggregat in maximal eine Komposition mit einer Inhaltsklasse auftreten. Die Inhaltsklasse darf nur mit der Multiplizität 1 in dieser Komposition vertreten sein und darf an keiner weiteren Aggregation bzw. Komposition teilnehmen. Außerdem darf die «Parameterentität»-Klasse an keine weiteren Klassen aggregieren.



Eine «Parameterentität»-Klasse kann beliebig oft von beliebig vielen «Sequenz»- bzw. «Auswahl»-Klassen aggregiert werden. Hierbei muss die «Parameterentität»-Klasse selbst wiederum eine Inhaltsklasse aggregieren. Auf Seiten der «Parameterentität»-Klasse sind hierbei die Standardmultiplizitäten zulässig. Die Inhaltsklassen nehmen mit Multiplizität 1 an der Aggregation teil. Die Aggregation repräsentiert eine Referenz auf die zu erzeugende Entität innerhalb der Inhaltsspezifikation, welche durch die Inhaltsklasse erzeugt wird. Die Entität repräsentiert dabei eine Teilgruppe der Inhaltsspezifikation und darf in beliebig vielen Inhaltsspezifikationen beliebig oft referenziert werden. Sollte eine «Parameterentität»-Klasse durch eine «Sequenz»-Klasse aggregiert werden, so muss diese Aggregation eine Nummerierung tragen (s. Abschnitt «ElementTyp»-Klassen)



Eine «Parameterentität»-Klasse kann als Aggregat an beliebig vielen 1:1Aggregationen mit Entitätsklassen bzw. 1:1-Kompositionen mit «ElementTyp»-Klassen teilnehmen. Jede Aggregation muss eine Positionierung tragen, es sei denn die «Parameterentität»-Klasse tritt nur in einer Assoziation als Aggregat auf. Die Aggregationen repräsentieren Enti-

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

80

tätsreferenzen auf die Entitäten, welche durch die aggregierten Entitätsklassen erzeugt werden. Die Kompositionen stehen für Elementtypen, die im Wert der vom Aggregat erzeugten Parameterentität gekapselt werden. 

Eine «GenerelleEntität»-Klasse muss mit mindestens einem Modellelement in Verbindung stehen, d.h. Aggregat in einer Aggregation sein oder mit einem «Text»-Kommentar in Verbindung stehen.



Eine «GenerelleEntität»-Klasse kann Verbindungen zu beliebig vielen «Text»-Kommentaren haben. Besitzt eine «GenerelleEntität»-Klasse mehr als eine Verbindung zu «Text»-Kommentaren bzw. ist die «GenerelleEntität»-Klasse Aggregat, so muss jede derartige Verbindung und jede derartige Aggregation eine Nummerierung tragen. Der Kontext in dem die Nummerierung eindeutig ist, ist die Menge allen Verbindungen dieser Klasse zu «Text»-Kommentaren UND die Menge der Aggregationen, in denen die «GenerelleEntität»-Klasse als Aggregat auftritt. Diese Nummerierungen sind von den Positionierungen anderer Kommentare zu unterscheiden, da die Nummerierungen die Anordnung des Textes im Entitätswert der zu erzeugenden generellen Entität beschreibt. Die Positionierungen aber die relative Position der Entität als Ganzes betreffen.



Eine «GenerelleEntität»-Klasse darf als Aggregat an beliebig vielen Aggragationen zu anderen «GenerelleEntität»-Klassen teilnehmen, wobei das Aggregat mit der Multiplizität 1 und die aggregierten Klassen mit einer Standardmultiplizität an der Aggregation teilnehmen. Jede Aggregation muss eine Nummerierung tragen, es sei denn, die Aggregatklasse ist nur in dieser Aggregation ein Aggregat UND besitzt außerdem keine Verbindung zu «Text»-Kommentaren.



Innerhalb des Aggregationsgraphen darf eine Entitätsklasse nicht zweimal auftreten, d.h. der Aggregationsgraph ist frei von Zyklen, welche mindestens eine Entitätsklasse beinhalten. Ein Aggregationsgraph ist ein Graph, dessen Knoten die Klassen eines Modells sind und dessen Kanten die Aggregations- bzw. Kompositionsbeziehungen zwischen diesen Klassen sind.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

81

Transformation 

Jede «Parameterentität»- bzw. «GenerelleEntität»-Klasse wird in eine Parameter bzw. generelle Entität überführt.



Die Transformation von Kompositionen, an denen «ElementTyp» bzw. Inhaltsklassen beteiligt sind, werden im Abschnitt «ElementTyp»Klassen in diesem Kapitel besprochen.



Aggregationen zwischen «GenerelleEntität»-Klasse werden zu Entitätsreferenzen innerhalb des Entitätswertes umgewandelt. Der Inhalt eines «Text»-Kommentar, welcher mit einer oder mehreren «GenerelleEntität»-Klassen in Verbindung stehen, wird in Textfragmente umgewandelt. Während ein Textfragment erzeugt wird, werden alle Zeilenumbrüche durch die numerische Zeichenrefenzen und alle Kleiner-, Ampersand und doppelten Anführungszeichen durch entsprechende vordefinierte XML-Entitäten (< , & bzw. ") ersetzt. Die Entitätsreferenzen und Textfragmente werden entsprechend der Nummerierung von Aggregation bzw. Kommentarverbindung in den Entitätswert der zu erzeugenden Entitäten platziert.

Die Abbildungen 28 und 31 demonstrieren die Verwendung und Transformation von Entitätsklassen. «GenerelleEntität» Signatur

{1}

«Text» Mit freundlichen Grüßen¶

{before, 1}

{before, 2}

{2} «GenerelleEntität» Unterschrift

«Anweisung» {target=MyOffice} signature=&Signatur «Anweisung» {target=MyOffice} importToTemplate=Normal.dot «Text» Wolfgang "Bartman" Bartels

Abbildung 31: Aggregationen zwischen «GenerelleEntität»-Klassen

Abbildung 31 demonstriert zum einen wie generelle Entitäten aus dem DTD-Profil heraus erzeugt werden, zum anderen zeigt sie, wie mit den

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

82

unterschiedlichen Nummernkreisen von «Text»- und anderen Kommentaren verfahren wird. Die «GenerelleEntität»-Klasse Signatur ist mit drei Kommentaren verbunden. Wie man erkennt, bilden die «Anweisung»-Kommentare einen Nummernkreis, die Aggregation und der «Text»-Kommentar einen zweiten.

NORMALE KOMMENTARE UML-Kommentare, die keinen Stereotyp tragen, heißen in diesem Profil normale Kommentare. Es ist möglich normale Kommentare zur Dokumentation von Modellelementen bzw. des Modells in das Modell einzubringen. Vordefinierte

vordefinierte Zusicherungen Name

Beschreibung

ganzzahlige absolute Positionierungszusicherung. Nummer Merkmal position

Anwendung s. Verbindungen

Tabelle 12: Vordefinierte Zusicherungen für Entitätsklassen

Merkmaldefinitionen Name

Beschreibung

Typ

Anzah l

position Beschreibt eine absolute Positionierungszusi- Integer cherung und wird auf Verbindungen mit ElementTyp»-, «Format»- und Entitätsklassen angewendet.

1

Tabelle 13: Merkmaldefinitionen für normale Kommentare

zulässige Beziehungen 

Ein normaler Kommentar kann beliebig vielen «ElementTyp»-, «Format»- und Entitätsklassen verbunden werden. Sollte ein normaler Kommentar mit einer «ElementTyp»-Klasse verbunden sein, die auch mit einem anderen normalen Kommentar verbunden ist, so muss jede dieser Verbindungen nummeriert sein. Die Verbindung eines normaler Kommentars mit einer Entitätsklasse muss genau dann nummeriert werden, wenn ein weiterer normaler Kommentar oder mindestens ein «Anweisung»-Kommentar mit dieser

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

83

Entitätsklasse verbunden ist. Der dabei entstehende Nummernkreis und der Nummernkreis für «Text»-Kommentare sind getrennt zu halten !! Die Bedingungen für das Nummerieren einer Verbindung zwischen einer «Format»-Klasse und einem normalen Kommentar ist analog zu den Verbindungen von Entitätsklassen. Da es bei «Anweisung»-Kommentaren, die mit «Format»-Klassen verbunden sind, die Verbindungen nicht nummeriert werden, kommt es hier zu keinerlei Problemen mit den Nummernkreisen. 

Ein Kommentar kann innerhalb eines Modells ohne Verbindung zu einem Modellelement existieren.

Transformation Ein normaler Kommentar wird in einen XML-Kommentar überführt. Der Inhalt des UML-Kommentars wird dabei zum Inhalt des XML-Kommentars. Die Platzierung erfolgt dabei entsprechend der Nummerierung. Die Abbildungen 30 und 31 zeigen die Transformation von normalen Kommentaren und die Platzierung der dabei entstehenden XML-Kommentar.

3.2.2 DER ÜBERGANG VOM DATENMODELL ZUM DTD-METAMODELL 

Pakete des ursprünglichen Modells werden in «Namespace»-Pakete des Metamodells überführt. Die resultierenden «Namespace»-Pakete erhalten ein uri-Merkmal, dessen Wert ein leerer String ist.



Alle Klassen des ursprünglichen Modells, im Folgenden Ursprungsklasse genannt, werden in «ElementTyp»-Klassen des Metamodells übersetzt, im Folgenden Zielklasse genannt. Die Belegung des Metaattributs abstract der Ursprungsklasse wird in die Zielklasse übernommen. Die UML-Attribute der Ursprungsklasse , im Folgenden Ursprungsattribute genannt, werden dabei wie folgt in UML-Attribute der entsprechenden «ElementTyp»-Klasse, im Folgenden Typattribute genannt, überführt :

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD



84

Aus den Enumerationswerten der Ursprungsattribute vom Typ NOTATION werden zunächst «Format» -Klassen gebildet. Der Name der «Format»-Klasse entspricht dabei dem Enumerationswert. Sollte eine entsprechende «Format» -Klasse bereits existieren, so wird keine weitere «Format»-Klasse für diesen Enumerationswert erzeugt. Anschließend werden 1:1-Assoziationen von der Zielklasse zu den entsprechenden «Format»-Klassen gebildet. Das Ursprungsattribut wird nicht in eine Typattribut überführt.



Sollte eine Urspungsklasse mehr als ein UML-Attribut vom Typ ID definieren, so ist dies als Fehler anzusehen.



Alle Ursprungsattribute, die nicht den Typ NOTATION tragen, werden wie folgt überführt: 

Die Sichtbarkeit des Typattributs ist in allen Fällen public



Der Name des TypAttributs ist identisch mit dem Namen des Ursprungsattributs



Der Typ des Typattributs ist analog zum Abschnitt 3.1.1 Klassen, Pakete und Attribute aus dem Typ des Ursprungsattributs zu ermitteln.



Die Multplizität des Typattribut aneu wird wie folgt aus der Multiplizität des Ursprungsattributs aalt abgeleitet:

min(Mult(aneu)) =

max(Mult(aneu)) =

{ {

min(Mult(aalt))

, falls min(Mult(aalt)) < 2,

1

sonst

min(Mult(aalt))

, falls min(Mult(aalt)) < 2,

1

sonst

Mult(aneu)= [min(Mult(aneu)), max(Mult(aneu))] , wobei [a, b], das abgeschlossene Interval von a bis b bezeichnet 

Vorgabe- und Eigenschaftswert des Typattributs ist identisch mit den entsprechenden Werten des Ursprungsattributs.



Bei der Überführung von Aggregationen/Kompositionen werden Klassen, welche die Rolle eines Aggregats einnehmen, im Folgenden Ursprungsaggregat genannt, betrachtet. Es ist zu beachten, dass das

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

85

Ursprungsaggregat in anderen Aggregation/Komposition die Rolle der aggregierten Klasse einnehmen kann. Folgende Überführungsschritte müssen durchlaufen werden: 

Neben einer «ElementTyp»-Klasse - der Zielklasse - wird für das Ursprungsaggregat eine «Sequenz»-Klasse im Metamodell erzeugt. Der Name dieser «Sequenz»-Klasse setzt sich aus dem lokalen Namen des Ursprungsaggregats und dem Suffix _Inhalt zusammen. Zusätzlich werden Ziel- und «Sequenz»-Klasse mit einer Aggregation verbunden, wobei die Zielklasse die Rolle des Aggregats übernimmt.



Seien a1, ..., an Aggregationen bzw. Kompositionen des ursprünglichen Modells. Des weiteren seien k1, ..., kn die zugehörigen, nicht notwendigerweise verschiedenen aggregierten Klassen und sei s die «Sequenz»-Klasse, welche aus dem Ursprungsaggregat gewonnen wurde. Bei der Überführung der a1, ..., an werden Aggregationen a'1, ..., a'n im Metamodell erzeugt, wobei a'i die Zielklasse von ki und die Klasse s miteinander verbindet. Die Klasse s übernimmt dabei die Rolle des Aggregats innerhalb der Aggregation. Die Namen der a1, ..., an werden als Namen der a'1, ..., a'n übernommen. Jedes a'i erhält eine Nummerierung. Wie die Nummerierungen vergeben werden, liegt beim Transformationswerkzeug.



Jeder Kommentar wird unverändert übernommen. Die Verbindungen zwischen Komentaren und Klassen bzw. Attributen von Klassen im ursprünglichen Modell werden zu Verbindungen zwischen den erzeugten Kommentaren und «ElementTyp»-Klassen, die aus den o.g. Klassen erzeugt wurden. Kommentarverbindungen zu Assoziationen bzw. Generalisierungen des ursprünglichen Modells werden in Verbindungen zu den «ElementTyp»-Klassen, die aus den beteiligten Klassen erzeugt wurden, überführt, d.h. eine Verbindung des ursprünglichen Modells erzeugt mehrere Verbindungen im Metamodell.



gewöhnliche Assoziationen und Generalisierungen werden unverändert auf die «ElementTyp»-Klassen der beteiligten Ursprungsklassen übertragen.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

teilaufgabe Aufgabe {abtract} ergänzt

Präambel

Modell Metamodell

86

teilaufgabe verfeinert

Text

«ElementTyp»

teilaufgabe Aufgabe {abtract} {4}

teilaufgabe {3}

«Sequenz»

Aufgabe_Inhalt ergänzt

{1} «ElementTyp»

{2} «ElementTyp»

Präambel

Text

verfeinert

Abbildung 32: Überführung von Aggregationen des Modells in das Metamodell

Abbildung 32 zeigt die Überführung von Aggregationen des Modells in das Metamodell. Insbesondere wird die Erzeugung der «Sequenz»-Klasse, die „zwischen“ die Klassen Aufgabe, Präambel und Text eingefügt wird.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

87

WissenschaftlicheArbeit name : ID titel : String format : NOTATION (txt | doc | sdw )

Prüfung termin : Date prüfer : NOTATION (Professor | ExternerPrüfer) «Format»

doc «Format»

txt

«Elementtyp»

prüfungsNr : ID abgabe : Date[0..1]

Modell Metamodell

WissenschaftlicheArbei t name : ID titel : CDATA

«Format»

«ElementTyp»

Diplom

sdw «Format»

«Elementtyp»

Professor

Prüfung

«Format»

Diplom

prüfungsNr : ID abgabe : CDATA[0..1]

termin:CDATA

ExternerPrüfer Abbildung 33: Transformation von Formatierungsattributen und Generalisierungen

Abbildung 33 demonstriert, wie die Formatierungsattribute format (s. Klasse WissenschaftlicheArbeit im Modell) und prüfer (s. Klasse Prüfung im Modell) in die «Format»-Klassen doc, txt, sdw, ExternerPrüfer und Professor überführt werden. Außerdem wird die Typumwandlung bei den Attributen titel, termin und abgabe verdeutlicht. Die Erhaltung der Generalisierungen wird ebenfalls dargestellt.

3.2.3 BEWERTUNG DES DTD-PROFILS Der Zwischenschritt „DTD-Metamodell“ eröffnet dem Entwickler/Modellierer die Möglichkeit die Qualität der Transformation stark zu verbessern. Die Ursache dafür liegt in der engen Beziehung zwischen den Konzepten des Profils den Konzepten einer DTD. Diese Beziehung ist wesentlich enger, als die Beziehung zwischen den „normalen“ Konzepten eines Klassendiagramms und den Konzepten einer DTD. Sollte man den vorhergehenden Schritt Modellierungsschritt auslassen und versuchen eine DTD nur mit Hilfe des DTD-Profils zu modellieren, so besteht die Gefahr, dass die Anwendersicht vernachlässigt wird. Beispielsweise kann die Entscheidung über die Eigenständigkeit oder Wichtigkeit

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 3 Transformationen vom UML-Modell zur DTD

Autor

1..*

1..*

88

Buch

bzw. Buch Autor

«ElementTyp» 1..* 1..* «ElementTyp»

Autor

Buch

Buch Autor

«ElementTyp»

«ElementTyp»

Autor

1..*

«Sequenz»

AutorContent

1..*

Buch

«Auswahl»

BuchContent

Abbildung 34: Die Ergebnisse unterschiedlicher Herangehensweisen

einer Information im Fall des zweistufigen Vorgehens anders ausfallen, als bei der alleinigen Anwendung des DTD-Profils. Die Information ob der Autor eines Buches kann verschieden modelliert werden. Im zweistufigen Verfahren ist es sehr wahrscheinlich, das Autor und Buch zwei Klassen sind, die eine 1..*:1..*-Assoziation teilen bzw. Autor als Attribut von Buch modelliert wird. Wird das DTD-Profil allein angewandt, so führt die XMLspezifische Sicht dazu, dass beide Informationen als Elementtypen modelliert werden, wobei sich beide gegenseitig in ihren Inhaltsklassen aggregieren. Abbildung 34 verdeutlicht die unterschiedlichen Ergebnisse dieses Falls.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 4 XML Schema

89

KAPITEL 4 XML SCHEMA Im vorherigen Kapitel wurden Transformationen eines Klassendiagramms in eine DTD vorgestellt. In diesem Kapitel werden Transformationen gezeigt, bei denen ein XML-Schema erzeugt wird. Dabei liegt das Augenmerk ausschließlich auf der direkten Modelltransformation, da ein XMLSchema-Profil den Rahmen dieser Arbeit sprengen würde. Viele Transformationen des vorherigen Kapitels sind analog zu denen, die ein XMLSchema produzieren. Daher werden hier nur die Unterschiede aufgezeigt.

4.1 ABSTRAKTE, FINALE UND INNERE KLASSEN Die Transformation dieser speziellen Klassen nach XML-Schema gestaltet sich wesentlich leichter als bei der Transformation in eine DTD. Innere Klassen werden in lokale Elementtypen desjenigen Elementtyps transformiert, der aus der äußeren Klasse gewonnen wurde. Der lokale Name des lokalen Elementtyps entspricht dem lokalen Namen der inneren Klasse. Der Namensraumpräfix des lokalen Elementtyps entspricht dem des ihn umgebenden Elementtyps. Bei finalen Klassen wird ein Elementtypen erzeugt, der einen Metatyp instanziiert, welcher den Wert #all im Meta-Metaattribut final trägt.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 4 XML Schema

90

Abstrakte Klassen werden in Elementtypen überführt, deren Metaattribut abstract den Wert true trägt. Die Tatsache, dass abstrakte Klassen auf abstrakte Elementtypen anstelle von abstrakten Metatypen abgebildet werden, liegt daran, dass ein abstrakter Metatyp nicht instanziiert werden kann. Dadurch könnte keine Ersetzungsgruppe gebildet werden, welche die „IST-EIN“-Beziehung einer Generlaisierung modelliert. Näheres hierzu wird im Abschnitt 4.3 Einfachvererbung aufgeführt. Lehre Diplom

Diplom {isLeaf=true} Inhaltsverzeichnis

... Abbildung 35: Transformation abstrakter, finaler und innerer Klassen

Abbildung 35 zeigt die abstrakte und finale Klasse Diplom, welche die innere Klasse Inhaltsverzeichnis in sich trägt. Die Finalität von Diplom zeigt sich am Meta-Metaattribut final des Metatyps Lehre:DiplomTyp. Die Abstraktheit von Diplom kommt durch das Metaattribut abstract im Elementtyp zum Ausdruck. Der Elementtyp Lehre:Inhaltsverzeichnis verdeutlicht sowohl die Lokalität der Klasse, als auch die Bildung des Namens dieses Elementtyps.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 4 XML Schema

91

4.2 AGGREGATIONEN UND KOMPOSITIONEN Im Abschnitt 3.1.2 Aggregationen und Kompositionen wurde gezeigt, wie die Anordnungsfreiheit von Aggregationen durch Permutationen von Referenzsequenzen in in der Inhaltsspezifikation gewährleistet wurde. Das Verfahren ist ineffizient, da die Inhaltsspezifikation überexponentiell in der Anzahl der zu transformierenden Aggregationen, welche die selbe Aggregatklasse teilen, wächst. Bei der Transformation von Aggregationen nach XML-Schema wächst die Inhaltsspezifikation hingegen linear an. Hierzu wird der permutierende Inhalt verwendet. Abbildung 36 zeigt die Transformation verschiedener Aggregationen, welche die selbe Aggregatklasse teilen.

4.3 EINFACHVERERBUNG Generalisierungen, deren Kindklasse nur eine Klasse spezialisieren, können derart transformiert werden, dass die „IST-EIN“-Beziehung, welche der Generalisierung innewohnt erhalten bleibt. Seien g1, ... ,gn Generalisierungen, die je eine Einfachvererbung modellieren. Sei p die Vaterklasse der Generalisierungen g1, ... ,gm , wobei m ≤ n. Mit ci wird die Kindklasse der Generalisierung gi bezeichnet. Für gi, mit i > m gelte: ∃ j ≤ n, sodass cj ist Vaterklasse von gi . Alle ci sind verschieden, da alle gi Einfachvererbungen sind. Die Überführung wird wie folgt vorgenommen. 

Für p und für alle ci i ≤ n werden je ein Metatyp und je ein Elementtyp erzeugt. Sollte p oder ein ci abstrakt sein, so ist es der entsprechende Elementtyp auch. Der Metatyp, welcher aus der Vaterklasse einer Generalisierung gi erzeugt wurde, wird im Folgenden Vatermetatyp von gi genannt. Analog zum Begriff Vatermetatyp werden auch die Begriffe Vaterelementtyp, Kindmetatyp und Kindelementtyp definiert.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 4 XML Schema



92

Für jede Generlaisierung gi wird eine Ableitungsbeziehung zum dem Vater- und dem Kindmetatyp erzeugt, wobei der Kindmetatyp den Vatermetatyp ableitet. Außerdem wird der Kindelementtyp von gi in eine Ersetzungsgruppe für den Vaterelementtyp eingefügt. Aufgrund der Ersetzungsgruppe bleibt die „IST-EIN“-Beziheung von gi erhalten.

A

1

A1

1

...

An

*

B1

*

...

Bm

0..1

C1

0..1

...

Cq

1..*

D1

1..*

...

... ... ... ... ... ... ..... ... .....

Abbildung 36: Allgemeine Transformationsformel von UML-Aggregationen in ein XML-Schema

Dk

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 4 XML Schema

93

Übung 1..*

Aufgabe {abstract} name telNr

Programmieraufgabe SchriftlicheAufgabe {abstract}

Klausur

Konstruktion

... ... ... ...

Abbildung 37: Transformation von Einfachvererbung und Aggregationen abstrakter Klassen

Abbildung 37 demonstriert die Transformation einer Aggregation einer abstrakten Klasse und mehrerer Einfachvererbungen. Im Gegensatz zur DTD-Transformation ist die Überführung der Aggregation identisch zu einer Aggregation von nichtabstrakten Klassen. Bei der Transformation der

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 4 XML Schema

94

Generalisierungen wird gezeigt, wie Metatypen gebildet werden und die Generalisierungen auf die Ableitungsbeziehungen zwischen den Metatypen abgebildet werden. Zu beachten ist hierbei, dass zwei Ersetzungsgruppen gebildet werden, eine für den Elementtyp Aufgabe und ein weiterer für den Elementtyp SchriftlicheAufgabe. somit wird rekursiv die „IST-EIN“Beziehung zwischen den Klassen Klausur und Aufgabe gewährleistet.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 5 Zusammenfassung

95

KAPITEL 5 ZUSAMMENFASSUNG Im Bereich der Transformation UML-> DTD wurde eine Trennung zwischen Modellierung der Daten einer Problemdomäne und der Metamodellierung einer DTD, vollzogen. Im Rahmen dieser Trennung wurde 

ein alternativer Transformationsprozess entwickelt, der qualitativ bessere Ergebnisse erzielt, als bisherige Transformationen und



es wurde ein Profil, welches eine genauere Modellierung von DTDs ermöglicht, als es bisherige Arbeiten zuließen, erarbeitet. Es ist nunmehr möglich XML-Namensräume, Anweisungen und Kommentare zu modellieren. Des weiteren können Entitäten präziser modelliert werden.

Die direkte Transformation UML->DTD wurde um innere und abstrakte Klassen, Zugriffsabhängigkeiten, Assoziationsklassen und Kommentare erweitert. Die Behandlung von Attributen und Paketen wurde überarbeitet. Diverse Alternativen wurden insbesondere für normale Assoziationen und Generalisierungen, sowie für deren Zusicherungen erarbeitet. Bei den Aggregationen und Kompositionen wurde ein Transformationsansatz gezeigt, der die bisher noch nicht berücksichtigte Anordnungsfreiheit der aggregierten Klassen in Betracht zieht. Der Transformation UML -> XML-Schema wurde vollständig neu erarbeitet, wobei nur die direkte Transformation betrachtet wurde. Die Tatsache, dass ein Großteil der Transformationskonzepte analog zu den Konzepten der direkten Transformation UML -> DTD ist, ist eine wichtige Erkenntnis daraus. Differenzen ergeben sich in folgenden Bereichen:

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 5 Zusammenfassung



die Abbildung abstrakter, finaler und innerer Klassen,



die Transformation von Aggregationen und Kompositionen und



Einfachvererbung ohne Zusicherungen

96

Insbesondere der letzte Punkt erlaubt es die „IST-EIN“-Beziehung für Einfachvererbungen, die bei der Transformation UML -> DTD verloren geht, zu erhalten.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 6 Ausblicke

97

KAPITEL 6 AUSBLICKE 6.1 OFFENE PROBLEME Das Problem, welches bisher noch nicht gelöst werden konnte, besteht im Verlust der Typsicherheit bei Assoziationen. Dies ist darauf zurückzuführen, dass sowohl in einer DTD als auch in einem XML-Schema es nicht möglich ist Elemente dokumentübergreifend eindeutig identifizierbar zu gestalten, denn die Belegung von ID-Attributen und Schlüsselinformationen bestenfalls auf Dokumentebene eindeutig sind.

6.2 DER OBJEKTANSATZ Dieser Abschnitt zeigt eine Alternative zum DTD-Profil, welche nicht die Erweiterungsmechanismen der UML benutzt. Motiviert wird dies durch die Tatsache, dass viele UML-Modellierungstools diese Erweiterungsmechanismen nicht oder nur unvollständig unterstützen. Diese Methode soll eine Metamodellierung dennoch ermöglichen. Der in diesem Abschnitt vorgestellte Ansatz abstrahiert von der Tatsache, dass es sich bei einer DTD um ein Modell für Dokumente handelt. Hierbei wird ein Metamodell für die Modellierung von DTD's in Form eines Klassendiagramms vorgegeben. Der Entwickler/Modellierer erzeugt auf der Basis des vorgegebenen Klassendiagramms ein Objektdiagramm, welches dass Dokumentenmodell darstellt.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 6 Ausblicke

98

Dieses Objektdiagramm ist Grundlage für die Erzeugung einer DTD. Abbildung 38 zeigt die Zusammenhänge für diesen Ansatz.

UML Vorgegebenes Metamodell

Klassendiagramm

Vom Anwender erzeugtes Modell der DTD

Objektdiagramm

XML

DTD

Abbildung 38: DTD im Objektdiagramm modellieren

Ein Meta-Metamodell mit dessen Hilfe eine DTD modelliert werden kann wird in den Abbildungen 40 und 39 gezeigt. Die Transformation dieses Objektdiagramms in eine DTD ist analog zur Transformation eines DTD-Metamodells, welches mit dem DTD-Profil erzeugt wurde. Die Instanzen der Klassen werden in entsprechende XMLKonzepte überführt, wobei die Namen der Objekte, sofern dies notwendig ist, als Namen der XML-Konzepte verwendet werden. Neben der Tatsache, dass keine Erweitungsmechanismen der UML benötigt werden, ergibt sich der Vorteil, keine Namen für Inhaltsspezifikationen vergeben werden müssen. Dies ist darauf zurückzuführen, dass Objekte aufgrund der ihnen innewohnenden Identität keine Namen zur Identifikation benötigen. Als Nachteil erweist sich allerdings die Tatsache, dass XMLAttributdefinitionen nicht mehr als Attribute einer Klasse oder eines Objekts modelliert werden, sondern als Instanzen einer Klasse. Dadurch wird die Modellierung etwas erschwert.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 6 Ausblicke

AttributDefinition typ:XMLAttrTypT stdWert:String isRequired:boolean isFixed:boolean

ElementTyp

1

*

99

istLeer:boolean istBeliebig:boolean *

*

*

*

Format

1

systemID:String publicID:String

*

Platzierung before:boolean pos:int

Anweisung daten:String

Abbildung 39: Das Meta-Metamodell für DTD-Modellierung (Teil 1)

Entität

ParamterEntität

*

GenerelleEntität *

GekapselterTyp pos:int {xor}

*

ElementTyp 1..*

istLeer:boolean istBeliebig:boolean *

1 0..1

*

0..1

InhaltsSpezifikation

*

Mixed Referenz

SchachtelbareGruppe *

Gruppe

pos:int

pos:int

*

*

Sequenz

Auswahl *

Abbildung 40: Das Meta-Metamodell für DTD-Modellierung (Teil 2)

6.3 ERWEITERUNGEN DES DTD-PROFILS Das DTD-Profil ist bisher nur auf konzeptuelle Datenmodellierung ausgelegt. Mittels einer Erweiterung dieses Profils in Richtung Komponentendiagramm,

könnte

man

Datenmodellierung einsetzen.

dieses

Profil

auch

zur

physischen

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Kapitel 6 Ausblicke

Beispiele

hierfür

wären

«DokumentTyp»-,

100

«MarkupDeklMenge»-,

«XMLDokInstanze»- und «XMLAnfrage»-Artefakte, welche zur Modellierung Dokumenttypdeklarationen, Mengen von Markupdeklarationen in Form von Dateien, Dokumentinstanzen oder in XML formulierte Anfragen an eine Datenhaltungssystem enthalten, benutzt werden können. «XMLProzessor» und «FormatApp»-Komponenten repräsentieren Applikationen, die diese Dateien verarbeiten. Artefakte sind UML-Modellelemente, die zur physischen Modellierung herangezogen werden. Unter anderem repräsentieren Artefakte Implementationen, die von Komponenten zur Verfügung gestellt werden. Eine weitere Möglichkeit der Erweiterung besteht in der Modellierung von Dokumentinstanzen auf der Basis von Objektdiagrammen. Ein DTDMetamodell stellt die zu instanziierenden Klassen zur Verfügung. Im Objektdiagramm kann Elementinhalt durch Kommentare dargestellt werden, die mit den entsprechenden Elementtyp

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML Anhang A: Erklärungen

101

ANHANG A: ERKLÄRUNGEN A.1 SELBSTSTÄNDIGKEITSERKLÄRUNG Hiermit erkläre, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Die aus fremden Quellen direkt oder indirekt übenommenen Gedanken sind als solche kenntlich gemacht.

Berlin,den 11. Dezember 2001 Wolfgang Bartels

A.2 EINVERSTÄNDNISERKLÄRUNG Ich erkläre mich damit einverstanden, dass diese Arbeit in der Zweigbibbliothek Informatik der Humboldt Universität zu Berlin ausgestellt wird.

Berlin,den 11. Dezember 2001 Wolfgang Bartels

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:42

Seite i

Abbildungsverzeichnis Abbildung 1: Die Notation von Klassen und Attributen

10

Abbildung 2: Notation eines Pakets

11

Abbildung 3: Die Notation von gewöhnlichen Assoziationen

13

Abbildung 4: Die Notation von Aggregationen und Kompositionen

13

Abbildung 5: Notation von Generalisierungen

15

Abbildung 6: Notation von UML-Kommentaren

16

Abbildung 7: Notation von Zusicherungen, Merkmalen und Stereotypen

18

Abbildung 8: Deklarationen für simple und extended links

21

Abbildung 9: Namensvergabe bei inneren Klassen

28

Abbildung 10: Die direkte Transformation von Klassen und Attributen

31

Abbildung 11: assoziationsorientierte Umwandlung gewöhnlicher Assoziationen 36 Abbildung 12: attributbasierte, klassenorientierte Transformation zweier Assoziationen

39

Abbildung 13: inhaltsbasierte, klassenorientierte Transformation zweier Assoziationen

41

Abbildung 14: Aggregationstransformation für Multiplizität 0..1

44

Abbildung 15: Aggregationstransformation für Multiplizität 1

44

Abbildung 16: Aggregationstransformation für Multiplizität 1..*

44

Abbildung 17: Aggregationstransformation für Multiplizität *

44

Abbildung 18: Allgemeine Transformationsformel von UML-Aggregationen in eine DTD 45 Abbildung 19: Transformation von Aggregationen abstrakter Klasse

46

Abbildung 20: Die Segmente eines Objektes

49

Abbildung 21: Transformation von Generalisierungen (ohne Zusicherungen) 52 Abbildung 22: Das zu überführende Modell für eine Transformation von Generalisierungen inkl. abstrakter Klassen und Zusicherungen 54 Abbildung 23: Die aus Abbildung 22 resultierenden Markupdeklarationen der Klasse Tutor 54 Abbildung 24: Die aus Abbildung 22resultierenden Markupdeklarationen der Klasse Übungsleiter 55 Abbildung 25: Die aus Abbildung 22 resultierenden Markupdeklarationen der Klasse Mitarbeiter 55 Abbildung 26: Überführung von Kommentaren

58

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:42

Seite ii

Abbildung 27: Die Transformation von Klassen und Attributen

67

Abbildung 28: Aggregationen und Kompositionen mit «ElementTyp»-, Inhalts- und «Parameterentität»-Klassen

73

Abbildung 29: Mehrfachaggregationen zwischen «ElementTyp»- und Inhaltsklassen 75 Abbildung 30: Transformation von «Format» -Klassen und «Anweisung»Kommentaren 77 Abbildung 31: Aggregationen zwischen «GenerelleEntität»-Klassen

82

Abbildung 32: Überführung von Aggregationen des Modells in das Metamodell 87 Abbildung 33: Transformation von Formatierungsattributen und Generalisierungen 88 Abbildung 34: Die Ergebnisse unterschiedlicher Herangehensweisen

89

Abbildung 35: Transformation abstrakter, finaler und innerer Klassen

91

Abbildung 36: Allgemeine Transformationsformel von UML-Aggregationen in ein XML-Schema 93 Abbildung 37: Transformation von Einfachvererbung und Aggregationen abstrakter Klassen

94

Abbildung 38: DTD im Objektdiagramm modellieren

99

Abbildung 39: Das Meta-Metamodell für DTD-Modellierung (Teil 1)

100

Abbildung 40: Das Meta-Metamodell für DTD-Modellierung (Teil 2)

100

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:42

Seite iii

Tabellenverzeichnis Tabelle 1: Stereotypen des DTD-Profils

64

Tabelle 2: Legende für Zusicherungstabellen

65

Tabelle 3: Legende für Merkmaltabellen

65

Tabelle 4: Merkmaldefinitionen des Stereotyps «Namensraum»

66

Tabelle 5: Vordefinierte Zusicherungen für «ElementTyp»-Klassen

69

Tabelle 6: Merkmaldefinitionen des Stereotyps «ElementTyp»

69

Tabelle 7: Vordefinierte Zusicherungen für «Anweisung»-Kommentare

76

Tabelle 8: Merkmaldefinitionen des Stereotyps «Anweisung»

76

Tabelle 9: Merkmaldefinitionen des Stereotyps «Format»

78

Tabelle 10: Vordefinierte Zusicherungen für Entitätsklassen

79

Tabelle 11: Merkmaldefinitionen des Stereotyp «Parameterentität»

80

Tabelle 12: Vordefinierte Zusicherungen für Entitätsklassen

83

Tabelle 13: Merkmaldefinitionen für normale Kommentare

83

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:42

Seite iv

Glossar und Abkürzungsverzeichnis abstrakte Klasse

betrifft Klasse Eine Klasse, die nicht instanziiert werden kann. Es gibt zwei Formen von abstrakten Klassen: 

explizit abstrakte Klassen, das sind Klassen, deren Metaattribut isAbstract den Wert „true“ haben.



implizit abstrakte Klassen, dies sind u.a. Klassen, für die eine Menge von Generalisierungen existiert, bei denen diese Klasse parent ist, welche die Zusicherung complete trägt (s. Abschnitt 2.5.2.21 in [UML1.4]).

ADA

Abkürzung für Attributdefinitionsanteil

Aggregat

betrifft Aggregation, Komposition. Das Aggregat ist jene Klasse innerhalb einer Aggregation/Komposition, welches die Rolle des „Ganzen“ übernimmt.

Aggregation

betrifft Assoziation. Eine besondere Form der Assoziation, welche eine allgemeine Teil-Ganzes Beziehung zum Ausdruck bringt.

aggregiertes Modellelement

betrifft Aggregation, Komposition.

Anweisung

Die vom Autor gewählte Übersetzung für processing instruction

Assoziation

betrifft Beziehung, Klasse.

Das aggregierte Modellelement ist jenes Modellelement innerhalb einer Aggregation/Komposition, welches die Rolle des „Teils“ übernimmt.

Eine Unterklasse von Beziehung, die ein Verhältnis zwischen Klassen zum Ausdruck bringt. Attributdefinitionsanteil

betrifft Klasse, Generalisierung, Segment Der Teil eines Elementtypsegments, welcher die Attributdefinitionen dieses Segments trägt.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:44

Beziehung

Seite v

betrifft UML. Ein abstraktes Modellelement, das für Beziehungen aller Art zwischen Modellelementen steht. Die für diese Arbeit relevanten Unterklassen sind Assoziation, Generalisierung und Abhängigkeit

bidirektional

betrifft Assoziation. Eine bidirektionale Assoziation ist eine binäre Assoziation, welche in beide Richtungen traversiert werden kann.

Dokumentenmodell

Ein allgemeinerer Begriff für eine DTD oder ein Schema

DTD

Kurzform für Document Type Definition Der Inhalt einer Dokumenttypdeklaration in Form von Markupdeklarationen

DTD-subset

betrifft Markupdeklarationen, DTD In [XML1.0SE] wird eine Menge von Markup-Deklarationen, die zu einer DTD gehören, als internal subset bzw. external subset bezeichnet. Hierbei wird die Bezeichnung internal bzw. external, aus dem Blickwinkel der Datei vergeben, in der sich die DTD befindet. Der in dieser Arbeit verwendete Begriff DTD-subset ist definiert als eine Menge von Markup-Deklarationen. Damit erfolgt eine Abstraktion der o.g. subset-Begriffe.

Eigenschaftswert

Die in [BoochRumbJacob] gebrauchte Übersetzung für property string im Kontext von Attributen

EigenSeg(k)

betrifft Klasse, Generalisierung, Eigensegment, Bezeichnet das Eigensegment der Klasse k

Eigensegment

betrifft Klasse, Generalisierung Die Menge aller Attribute und Assoziationen einer Klasse, die nicht durch die Klasse geerbt wurden

ERM

Kurzform für Entity Relationship Modell

explizit abstrakte

betrifft Klasse

Klassen

Eine Klasse, deren Metaattribut isAbstract den Wert „true“ haben.

finale Klasse

betrifft Klasse, Generalisierung Eine Klasse, die nicht spezialisiert werden kann.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:44

Seite vi

Format

Die vom Autor gewählte Übersetzung für notation

generelle Entität

Die vom Autor gewählte Übersetzung für general entity

gewöhnliche Assoziation

betrifft Assoziation.

implizit abstrakte

betrifft Klasse, Generalisierung

Klassen

Eine Klasse, die aufgrund einer complete-Zusicherung, abstrakt ist. (s. abstrakte Klassen)

Inhaltsklasse

betrifft DTD-Profile.

Eine Assoziation, die entweder Assoziationsklasse oder normale Assoziation (d.h. weder Aggregation noch Komposition) ist.

Beschreibt eine Klasse, die eine von «Inhaltsspezifikation» abgeleiteten Stereotyp trägt.

Inhaltsspezifikationsanteil

betrifft Klasse, Generalisierung, Segment

innere Klasse

betrifft Klasse.

Der Teil eines Elementtypsegments, welcher die Inhaltsspezifikation dieses Segments trägt.

Eine Klasse, die in einer anderen Klasse enthalten ist. ISA

Abkürzung für Inhaltsspezifikationsanteil

Klassenattribut

betrifft Klasse. Ein UML-Attribut, welches von allen Instanzen der betreffenden Klasse gemeinsam genutzt wird.

Komposition

betrifft Assoziation, Aggregation. Eine spezielle Form der Assoziation, die eine Teil-GanzesBeziehung mit starker Eigentumsbeziehung ausdrückt.

Link

betrifft Beziehung. Eine Instanz einer Assoziation, einer Generalisierung oder einer Abhängigkeit.

Markupdeklaration

betrifft Dokumenttypdeklaration, DTD. Eine Ansammlung von Element- Attributlisten-, Entitätsund Formatdeklarationen, sowie PI und Kommentaren.

Merkmal

Die in [Oesterreich97] gebrauchte Übersetzung für tagged value

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:44

Seite vii

Modellelemente

Bezeichnet Konzepte, die zur Modellierung in der UML eingesetzt werden. Im Detail handelt es sich um alle SpeziaModelelement lisierungen der Metamodellklasse (s. [UML1.4] Abschnitt 2.5.2 Abstract Syntax). Beispiele hierfür sind Klassen, Attribute, Operationen, Pakete, Assoziationen etc.

Mult(a)

betr. UML-Attribut Bezeichnet die Multiplizität des Attributs a

normale Assoziation

betrifft Assoziation . Eine Assoziation die weder Aggregation noch Komposition ist.

Nummerierung

betrifft DTD-Profil. Eine Zusicherung bzw. ein Merkmal, die Reihenfolge bestimmter Beziehungen angibt.

Parameterentität

Die vom Autor gewählte Übersetzung für parameterentity

parent

betrifft Generalisierung. Bezeichnet die abgeleitete Klasse bzw. Instanz innerhalb einer Generalisierung. Aus Sichtweise der spezialisierten Klasse/Instanz kann auch die Beziehung bzw. der Link gemeint sein.

PI

Kurzform für processing instructions. bzw. Anweisung

Positionierungszusicherung

betrifft DTD-Profil. Hierbei handelt es sich um Zusicherungen, die mit Beziehungen oder Verbindungen verknüpft sind. Es existieren zwei Formen der Positionierungszusicherung: 

Die absolute Positionierungszusicherung besteht lediglich aus einer natürlichen Zahl.



Die relative Positionierungszusicherung besteht aus einem der beiden Worte before oder after.

Beide geben die Reihenfolge der XML-Konzepte, welche von einer Menge von Beziehungen/Verbindungen erzeugt werden, an. Eine Zusicherung, die nur aus einer natürlichen Zahl besteht und die Reihenfolge bestimmter Beziehungen angibt. Profil

betrifft UML-Erweiterungsmechanismen. Eine Ansammlung von Stereotypen , Zusicherungen und Merkmalen, die zur semantischen Erweiterbarkeit von UML-Modellelementen in einem bestimmten Kontext beitragen.

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:44

Pseudoattribut

Seite viii

betrifft Modellelemente Bestandteil eines Modellelements, der kein Attribut im Sinne des UML-Metamodells sind, jedoch in der UML genauso angesprochen wird. Beispiele hierfür sind Rollen in Assoziationen (nicht die eigene !) Merkmalsbezeichner

Schnittstelle

Die in [BoochRumbJacob] gebrauchte Übersetzung für interface.

Standardmultiplizitäten

betrifft Assoziationen. Die Mulitplizitäten 1, 0..1, * und 1..*

Stereotyp

Die in [BoochRumbJacob] gebrauchte Übersetzung für stereotype.

UML

Kurzform für Unified Modelling Language Ein Standard der OMG. Eine Modellierungssprache zur objektorientierten Analyse und Design von Softwaresystemen. In dieser Arbeit wird die Version 1.4 zugrunde gelegt.

UML-Namensraum

betrifft Modellelement. Ein UML-Namensraum ist ein Modellelement, welches andere Modellelemente beinhaltet und somit Modelle strukturiert. Beispiele für UML-Namensräume sind Paket, Modell und Klasse. betrifft UML-Namensraum,Klasse, Paket:

UMLNamensraumbezeichner

Der Name eines UML-Namensraumes

unidirektional

betrifft Assoziation. Eine unidirektionale Assoziation ist eine binäre Assoziation, welche nur in eine Richtung traversiert werden kann.

Vorfahrensegment

betrifft Klasse, Generalisierung Die Menge aller Attribute und Assoziationen einer Klasse, die durch Vererbung von einem speziellen Vorfahren in die Klasse gelangen.

VorfSeg(k)

betrifft Klasse, Generalisierung, Eigensegment, Bezeichnet die Menge der Vorfahrensegmente der Klasse k

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:47

W3C

Seite ix

Abkürzung für World Wide Web Consortium Ein Konsortium, welches sich der Entwicklung internationaler Standards im Bereich der Softwareentwicklung für Internetapplikationen widmet.

XML

Abkürzung für eXtensible Markup Language Eine Beschreibungssprache für semistrukturierte Daten, die durch einen Standard des W3C definiert wird. Diese Arbeit basiert auf der Version 1.0 Second Editon, welche den Status Recommendation besitzt.

XML-Dokumentenmodell

s. Dokumentenmodell

XML-Schema

Ein erweiternder Standard zu XML, welcher eine stärkere Bildung von Typen bzgl. Dokumentinhalte ermöglicht.

Zusicherung

Die in [Oesterreich97] constraint

gebrauchte

Übersetzung

für

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:47

Seite x

Literaturverzeichnis [BalzertH99] Heide Balzert : Lehrbuch der Objektmodellierung, 1999, Spektrum-Verlag [Booch99] Grady Booch, Magnus Christerson, Matthew Fuchs, Jari Koistinen : UML for XML Schema Mapping Specification, 1999, [Online] URL: http://www.rational.com/media/uml/resources/media/uml_xmlschema33.pdf

[BoochRumbJacob] Grady Booch, James Rumbaugh, Ivar Jacobson : Das UML Benutzerhandbuch, Dt.Übers. Prof. Bernd Kahlbrandt und Dorothea Reder, 1999, Addisson-Wesley [CoadYourdon91] Peter Coad, Edward Yourdon : Object-oriented Analysis, 2. Auflage, 1991, Prentice Hall [ConSchef2000] : Rainer Conrad, Dieter Scheffner, J.C. Freytag: XML Conceptual Modeling using UML, In Proceedings of the 19th International Conference on Conceptual Modeling (ER 2000), Salt Lake City, Utah, USA, October, 2000,' [Online] URL: http://www.dbis.informatik.hu-berlin.de/~rconrad/lit/ [ConSchef2001] Rainer Conrad, Dieter Scheffner, J.C. Freytag, XML Conceptual Modeling using UML, Interner Bericht, Institut für Informatik, Humboldt Universität zu Berlin, 2001, unveröffentlicht [Halpin01] Terry Halpin : Information Modelling and Relational Database, 2001, Morgan Kaufmann [Hucka2000] Michael Hucka : Aw,SCHUCS! An Approach to Creating XML Schemas from UML Class Diagramms, California Institute of Technology Pasadena,Oktober 2000, [Online] URL: http://www-casc.llnl.gov/xewa/papers/9/9.pdf [Kemper01] A.Kemper, A.Eickler : Datenbanksysteme, 4.Auflage, 2001, Oldenbourg Verlag [KleinLip01] C.Kleiner, U.W. Lipeck: Automatic Generation of XML-DTDs from Conceptual Database Schemas, Edt. K.Bauknecht, W.Brauer, Th.Mück, Tagungsband der GI/OCG-Jahrestagung, 25.-28. Sept. 2001, Wien, Österreich, S. 396-405, Österreichische Computer Gesellschaft, 2001 [Oesterreich97] Bernd Oestereich : Objektorientierte Softwareentwicklung mit der Unified Modeling Language, 3. akt. Auflage, 1997, Oldenbourg Verlag [Rational2000] Rational Software: Migrating from XML DTD to Xml Schema using UML, Whitepaper,2000, [Online] URL: http://www.rational.com/products/whitepapers/412.jsp [Rumbaugh91] J. Rumbaugh, M. Blaha, W.Premerlani, F.Eddy, W.Lorensen: Object-oriented modeling and design, 1991, Prentice Hall

konzeptuelle Datenmodellierung - Ein Modelltransfer von UML nach XML 11. Dezember 2001 14:07:47

Seite xi

[Schema0] W3C: XML Schema Part 0: Primer, Recommendation, Mai 2001 , [Online] URL: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/ [Schema1] W3C: XML Schema Part 1: Structures, Candidate Recommendation, Oktober 2000 , [Online] URL: http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/ [Schema2] W3C: XML Schema Part 2: Datatypes, Candidate Recommendation, Oktober 2000 , [Online] URL: http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/ [UML1.4] OMG : Unified Modelling Language Specification, Version 1.4, Spezifikation, September 2001 [Online] URL: http://www.omg.org/uml [Vossen2000] G.Vossen: Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme, 4.Auflage, 2000, Addison-Wesley [XML1.0SE] Tim Bray, Jean Paoli, C.M.Sperberg-McQueen : Extensible Markup Language (XML) 1.0(Second Edition), 2000, Recommendation, [Online] URL: http://www.w3.org/TR/2000/REC-xml-20001006 [XLink2001] Steve DeRose, Eve Maler, David Orchard : XML Linking Language (XLink) Version 1.0, 2001, Recommendation, [Online] URL: http://www.w3.org/TR/2000/REC-xlink-20010627/ [XMLNames99] Tim Bray, Dave Hollander, Andrew Layman : Namespaces in XML, 1999, Recommendation, [Online] URL: http://www.w3.org/TR/1999/REC-xml-names-19990114/