Studienarbeit Umwandlung von XMI in GXL und von GXL in XMI

Transcription

19.06.2005
Universität Koblenz-Landau
Fachbereich Informatik
Institut für Softwaretechnik
Studienarbeit
Umwandlung von XMI in GXL und von GXL in XMI
von Thomas Hebel
Betreuer: Prof. Dr. Jürgen Ebert/Dr. Andreas Winter
Version 1.0
ABSTRACT ......................................................................................................... 6
I. STUDIENARBEIT „UMWANDLUNG VON XMI IN GXL UND VON
GXL IN XMI“...................................................................................................... 7
1. EINLEITUNG ......................................................................................................................... 7
2. GXL.................................................................................................................................... 7
3. XMI .................................................................................................................................... 8
4. ZIEL DER STUDIENARBEIT ................................................................................................... 8
5. ÜBERBLICK ÜBER DIE STUDIENARBEIT ................................................................................ 9
II. GXL – GRAPH EXCHANGE LANGUAGE ............................................ 10
1. EINLEITUNG ....................................................................................................................... 10
2. BEISPIELE .......................................................................................................................... 10
3. GXL DTD......................................................................................................................... 12
3.1 Extensions................................................................................................................... 12
3.2 Attribut-Typen ............................................................................................................ 12
3.3 GXL-Element .............................................................................................................. 13
3.4 Type-Element.............................................................................................................. 13
3.5 Graph-Element ........................................................................................................... 13
3.6 Node-Element ............................................................................................................. 14
3.7 Edge-Element ............................................................................................................. 14
3.8 Rel-Element ................................................................................................................ 15
3.9 Relend-Element .......................................................................................................... 15
3.10 Attr-Element ............................................................................................................. 15
3.11 Locator-Element....................................................................................................... 16
3.12 Datentypen ............................................................................................................... 16
4. GRAPH-SCHEMATA............................................................................................................ 16
III. XMI – XML METADATA INTERCHANGE......................................... 18
1. EINLEITUNG ....................................................................................................................... 18
2. MOF – META OBJECTS FACILITY ...................................................................................... 18
3. XMI-DTD......................................................................................................................... 18
3.1 Notwendige XMI-DTD-Deklarationen ....................................................................... 19
3.1.1 Attribute zur Identifikation.................................................................................. 19
3.1.2 Verweise auf Attribute ........................................................................................ 19
3.2 Übersicht der Elemente einer XMI-DTD ................................................................... 20
3.2.1 XMI ..................................................................................................................... 20
3.2.2 XMI.header ......................................................................................................... 21
3.2.3 XMI.content ........................................................................................................ 21
3.2.4 XMI.difference .................................................................................................... 21
3.2.5 XMI.extensions ................................................................................................... 22
3.2.6 XMI.documentation ............................................................................................ 22
3.2.7 XMI.model .......................................................................................................... 22
3.2.8 XMI.metamodel, XMI.metametamodel .............................................................. 23
3.2.9 XMI.import ......................................................................................................... 23
3.2.10 XMI.extension................................................................................................... 23
3.2.11 XMI.reference ................................................................................................... 24
3.3 Repräsentation von Metamodell-Klassen in der DTD ............................................... 24
2
3.3.1 Namensbereiche .................................................................................................. 24
3.3.2 Deklaration einer Metamodell-Klasse................................................................. 24
3.3.3 Vererbung............................................................................................................ 25
3.3.4 Multiplizitäten ..................................................................................................... 25
3.3.5 Attribut-Spezifikation.......................................................................................... 25
3.3.6 DTD-Darstellung einer einfachen Klasse ........................................................... 26
3.3.7 Assoziationen ...................................................................................................... 26
3.3.8 Beispiel einer DTD-Deklaration einer Assoziation ............................................ 26
4. UML-DTD........................................................................................................................ 26
4.1 Einfaches Beispiel ( XMI-Dokument mit einer Klasse mit Attribut) .................... 27
4.2 Deklaration der verwendeten Elemente ..................................................................... 27
4.2.1 Klasse .................................................................................................................. 27
4.2.2 Assoziation .......................................................................................................... 30
5. BEISPIELDIAGRAMM .......................................................................................................... 33
IV. UML-KONZEPTE FÜR KLASSENDIAGRAMME IN XMI UND GXL
............................................................................................................................. 34
1. EINLEITUNG ....................................................................................................................... 34
2. UML-KONZEPTE ............................................................................................................... 34
2.1 Klasse ......................................................................................................................... 34
2.1.1 Klasse: XMI-Darstellung .................................................................................... 34
2.1.1.1 Ameos........................................................................................................... 35
2.1.1.2 Rational Rose ............................................................................................... 36
2.1.2 Klasse: GXL-Darstellung ........................................................................................ 37
2.2 Klasse mit Attribut...................................................................................................... 38
2.2.1 Klasse mit Attribut: XMI-Darstellung ................................................................ 38
2.2.1.1 Ameos........................................................................................................... 39
2.2.1.2 Rational Rose ............................................................................................... 40
2.2.2 Klasse mit Attribut: GXL-Darstellung ................................................................ 41
2.3 Assoziation ................................................................................................................. 42
2.3.1 Assoziation: XMI-Darstellung ............................................................................ 42
2.3.1.1 Ameos........................................................................................................... 42
2.3.1.2 Rational Rose ............................................................................................... 44
2.3.2 Assoziation: GXL-Darstellung............................................................................ 46
2.4 Aggregation ................................................................................................................ 48
2.4.1 Aggregation: XMI-Darstellung ........................................................................... 48
2.4.1.1 Ameos........................................................................................................... 49
2.4.1.2 Rational Rose ............................................................................................... 51
2.4.2 Aggregation: GXL-Darstellung........................................................................... 53
2.5 Komposition ............................................................................................................... 55
2.5.1 Komposition: XMI-Darstellung .......................................................................... 55
2.5.1.1 Ameos........................................................................................................... 56
2.5.1.2 Rational Rose ............................................................................................... 58
2.5.2 Komposition: GXL-Darstellung.......................................................................... 60
2.6 Generalisierung.......................................................................................................... 62
2.6.1 Generalisierung: XMI-Darstellung ..................................................................... 62
2.6.1.1 Ameos........................................................................................................... 62
2.6.1.2 Rational Rose ............................................................................................... 63
2.6.2 Generalisierung: GXL-Darstellung ..................................................................... 64
2.7 Package ...................................................................................................................... 65
2.7.1 Package: XMI-Darstellung.................................................................................. 65
3
2.7.1.1 Ameos........................................................................................................... 65
2.7.1.2 Rational Rose ............................................................................................... 66
2.7.2 Package: GXL-Darstellung ................................................................................. 67
2.8 Assoziations-Klasse.................................................................................................... 69
2.8.1 Assoziations-Klasse: XMI-Darstellung............................................................... 69
2.8.1.2 Ameos........................................................................................................... 69
2.8.1.2 Rational Rose ............................................................................................... 69
2.8.2 Assoziations-Klasse: GXL-Darstellung .............................................................. 71
V. JAXP/XSLT .................................................................................................. 73
1. EINLEITUNG ....................................................................................................................... 73
2. JAXP................................................................................................................................. 73
2.1 Benötigte Klassen ....................................................................................................... 73
2.2 Einlesen der Daten in ein DOM-Objekt ..................................................................... 74
2.3 Zugriff auf Elemente................................................................................................... 75
2.4 Erzeugen neuer Elemente........................................................................................... 75
2.5 Speichern eines DOM als XML-Datei........................................................................ 76
3. XSLT ................................................................................................................................ 77
3.1 Einfaches Beispiel ...................................................................................................... 78
3.2 Pfadangaben............................................................................................................... 79
3.3 Attribute...................................................................................................................... 79
3.4 Einfaches Beispiel zur Umwandlung.......................................................................... 79
3.5 Zusätzliche Anmerkungen .......................................................................................... 80
4. FAZIT ................................................................................................................................. 80
VI. TESTSTRATEGIE XMI2GXL UND GXL2XMI ................................... 81
1. EINLEITUNG ....................................................................................................................... 81
2. TEST XMI2GXL ............................................................................................................... 81
2.1 Ameos ......................................................................................................................... 81
2.2 Rational Rose ............................................................................................................. 81
2.3 Testdokument.............................................................................................................. 82
3. TEST GXL2XMI ............................................................................................................... 84
3.1 Ameos ......................................................................................................................... 84
3.2 Rational Rose ............................................................................................................. 84
3.3 Testdokument.............................................................................................................. 84
VII. ANWENDUNG DER ERSTELLTEN PROGRAMME........................ 85
1. XMI-EXPORT .................................................................................................................... 85
1.1 Ameos ......................................................................................................................... 85
1.2 Rational Rose ............................................................................................................. 86
2. UMWANDLUNG MIT XMI2GXL UND GXL2XMI .............................................................. 87
3. IMPORT VON XMI-DOKUMENTEN ..................................................................................... 88
3.1 Ameos ......................................................................................................................... 88
3.2 Rational Rose ............................................................................................................. 88
VIII. ZUSAMMENFASSUNG......................................................................... 89
IX. LITERATURVERZEICHNIS................................................................... 90
4
ANHANG A: GRAPHSCHEMA.XMI............................................................ 91
ANHANG B: UMWANDLUNG UML-KLASSEN IN GXL-NODES ......... 99
ANHANG C: XMI-DOKUMENT IN GXL TRANSFERIERT.................. 101
ANHANG D: ANMERKUNGEN/ BESONDERHEITEN DER
VERWENDETEN WERKZEUGE ............................................................... 102
1. Ameos ......................................................................................................................... 102
2. Rational Rose ............................................................................................................. 102
3. Sonstiges..................................................................................................................... 102
5
Abstract
GXL (Graph Exchange Language) wurde als ein Austauschformat für graph-basierte Werkzeuge entwickelt. Das XMI (XML Metadata Interchange)-Format wurde zur textuellen Darstellung von auf dem MOF (Meta Object Facility)-Metamodell basierenden Modellen entwickelt; hierunter fallen auch UML (Unified Modelling Language)-Modelle. In dieser Studienarbeit wurde ein Umsetzungstool entwickelt, um XMI-Daten (erzeugt aus UMLKlassendiagrammen) in das GXL-Format zu überführen und umgekehrt: Hiermit soll eine
Interoperabilität zwischen Werkzeugen, die eins der beiden Formate verwenden, ermöglicht
werden. Mit diesem Tool können dann beispielsweise UML-Klassendiagramme, die mit
einem CASE-Tool entworfen wurden, in GXL-Graphen überführt werden und umgekehrt.
Dazu wurde zuerst das GXL- und das XMI-Format analysiert; hierbei ist für XMI zu beachten, dass verschiedene Tools verschiedene XMI-Dialekte verwenden. Im Rahmen dieser Arbeit wurden Ameos und Rational Rose benutzt. Anschließend wurde der für diese Tools erzeugte XMI-Code analysiert und in das GXL-Format „übersetzt“. Das Umwandlungstool
wurde mit XSLT (Extensible Stylesheet Language Transformation) umgesetzt, sodass es unter
allen Betriebssystemen verfügbar ist, für die ein XSL-Prozessor existiert (z.B. Windows und
Linux).
6
I. Studienarbeit „Umwandlung von XMI in GXL und von GXL
in XMI“
1. Einleitung
Das GXL (Graph Exchange Language)-Format wird zum Austausch von Informationen, die
als Graph dargestellt werden und der dazugehörigen Schemainformationen benutzt. Hiermit
können nahezu alle Arten von Graphen ausgetauscht werden.
XMI (XML Metadata Interchange) wurde von der OMG (Object Modelling Group) entwickelt, um Modelle, die auf der MOF (Meta Object Facility) basieren, zwischen verschiedenen
Anwendungen auszutauschen.
Beide Formate speichern die benötigten Informationen gemäß dem XML-Standard1.
In dieser Studienarbeit wurde eine Anwendung entwickelt, die es ermöglicht, Daten zwischen
beiden Formaten zu transferieren, d.h. vorliegende (durch entsprechende Anwendungen erstellte) XMI-Daten sollen ins GXL-Format und Daten im GXL-Format sollen ins XMIFormat umgewandelt werden können. Hierdurch soll eine Interoperabilität zwischen verschiedenen Werkzeugen, die eins der beiden Formate verwenden, ermöglicht werden. Beispielweise können GXL-Dokumente, die von Reengineering-Tools erzeugt wurden, nach einer Umwandlung in XMI-Daten in einem CASE-Tool weiterverarbeitet werden. Dort können
die überarbeiteten Diagramme wiederum als XMI-Datei exportiert werden und wiederum in
GXL-Dokumente transferiert werden.
2. GXL
GXL wurde als ein Austauschformat für graph-basierte Werkzeuge entwickelt, um beispielsweise Daten zwischen einzelnen Software-Reengineering-Werkzeugen auszutauschen. Da mit
GXL nahezu alle Graphenarten dargestellt werden können, kann es als allgemeines Austauschformat für graph-basierte Werkzeuge genutzt werden [Wint01].
GXL ist als eine XML-Sprache definiert, mit der sowohl Instanz-Graphen als auch die zugehörigen Schema-Informationen ausgetauscht werden können. Die Syntax von GXL wird in
Form einer XML-DTD (Document Type Definition) angegeben; die komplette Syntax der
GXL-XML-Dateien findet sich unter http://www.gupro.de/GXL.
Die darzustellenden Daten werden als attributierte, typisierte, gerichtete Graphen (kurz
TGraphen) dargestellt. Diese TGraphen werden in XML kodiert, jeder Knoten wird beispielsweise zwischen <node> und </node>-Tags beschrieben, Kanten zwischen den Knoten
zwischen <edge> und </edge>-Tags. Diese Knoten und Kanten werden mit ihren Typen und
Attributen als ein GXL-Dokument in XML beschrieben [HoWi00], z.B. werden Verknüpfungen zu den entsprechenden Schema-Informationen angegeben. Es existieren Erweiterungen
zur Darstellung von Hypergraphen und hierarchischen Graphen [WiKuRi01].
Die Graph-Schemata geben die Graphenstruktur an, d.h. die Definition der Knoten- und Kantenklassen, der Relationen zwischen diesen Knoten und Kanten, ihrer Attribute, der Graphenhierarchie und zusätzliche Beschränkungen [Wint01]. Graph-Klassen werden als UMLKlassendiagramme definiert. Hierbei werden z.B. Knotenklassen durch Klassen, Kantenklassen durch Assoziationen und attributierte Kantenklassen durch assoziierte Klassen definiert.
Diese Klassendiagramme können in äquivalente Graphen (Schema-Graphen) umgeformt und
somit mit dem gleichen Dokumenttyp wie auch Instanzen-Graphen ausgetauscht werden.
[Wint01].
1
Beschrieben unter http://www.w3.org/TR/REC-xml
7
GXL wird in Abschnitt II genauer beschrieben.
3. XMI
Da in UML keine textuelle Beschreibung der Diagramme vorgesehen war, war ein Austausch
dieser Modelle zwischen verschiedenen Werkzeugen nur möglich, wenn diese kompatible
Datenformate benutzten. Mit XMI wurde ein Format entwickelt, um diese Modelle austauschen zu können. Die Darstellung der Informationen erfolgt auch hier im XML-Format, die
DTD, welche die Syntax beschreibt, findet sich in [XMI02] bzw. die aktuellere Version 2.0 in
[XMI03].
Die Modelle, die mit XMI beschrieben werden können, müssen auf einem MOF (Meta Object
Facility)-Metamodell basieren (einer Sprache, mit der weitere Sprachen/(Meta-)Modelle definiert werden können; alle Sprachen, die in verschiedenen OMG-Metamodellen definiert werden, basieren auf der MOF). Damit ist es möglich, außer UML eine Vielzahl weiterer Modelle
auszutauschen, sofern ein MOF-Metamodell existiert.
Im XMI-Standard werden sog. „XML DTD Schema Production Rules“ definiert, die einen
Algorithmus beschreiben, um MOF-basierte Modelle automatisch in eine XMI-konforme
XML-Grammatik umzusetzen. Damit können dann XML-DTD bzw. XML-Schemata (ab
XMI Version 2) zur Beschreibung der Syntax der erzeugten Metadaten erstellt werden, auch
für momentan noch nicht entwickelte Modelle. Die „XML-Document Production Rules“ beschreiben die Regeln, mit denen die Metadaten in ein XML-kompatibles Format kodiert werden [Jeck04].
Jede Klasse wird als ein XML-Element mit zusätzlichen XML-Elementen für jedes Attribut,
Assoziation und Komposition dargestellt. Im Metamodell vorhandene Attribute werden als
XML-Attribute (und auch als XML-Elemente) deklariert. Für mehrwertige Attribute werden
keine XML-Attribute definiert, jeder Wert wird als ein XML-Element kodiert. Komplexe Attribute werden wie Assoziationen behandelt. Jede Assoziation wird als ein XML-Element und/
oder ein XML-Attribut dargestellt, definiert in der Klasse, auf die sie sich bezieht. [Jeck04].
Die meisten der UML-unterstützenden CASE- und Zeichenwerkzeuge unterstützen XMI zum
Export und Import von UML-Modellen [Jeck04], damit stellt XMI eine Möglichkeit dar,
UML-Modelle in XML zu speichern und zwischen diesen Werkzeugen auszutauschen.
XMI wird in Abschnitt III genauer beschrieben.
4. Ziel der Studienarbeit
Im Rahmen dieser Studienarbeit wurden insgesamt vier betriebssystemunabhängige Programme2 entwickelt, mit denen ein Austausch zwischen Programmen möglich ist, die das
XMI- bzw. das GXL-Format benutzen. Eine bestimmte Programmiersprache wurde anfangs
noch nicht festgelegt, in Betracht kamen Java oder XSL (XML Style Language). Ein Vergleich hierzu, der zu der Entscheidung zur Umsetzung mit XSL führte, findet sich in Abschnitt V.
Die XMI-Konformität verschiedener Werkzeuge musste überprüft werden, mindestens zwei
hiervon sollten von dem Werkzeug unterstützt werden (z.B. Rational Rose (IBM), Together
(Borland), Ameos (Aonix), ArgoUML (University of California, Irvine); eine Liste von
UML-Werkzeugen findet sich unter http://www.jeckle.de/umltools.html). Insbesondere war
darauf zu achten, welche XMI-Version unterstützt wird; in den Versionen 1.x werden die
2
Für die Umsetzung von XMI in GXL jeweils ein Programm für Ameos und eins für Rational Rose; analog für
die Umsetzung von GXL in XMI. Die Programme wurden als XMI2GXL (für die beiden XMI zu GXL-Programme) sowie GXL2XMI bezeichnet, ist der Zusatz „-Ameos“ bzw. „-RR“ angegeben, ist das Programm für
das entsprechende Tool gemeint.
8
Schemata als DTD gespeichert, in Version 2 ist auch eine Speicherung als XML-Schema
möglich.
Diese möglicherweise unterschiedlichen XMI-„Dialekte“ mussten dann standardkonform ins
GXL-Format transferiert werden, welches z.B. vom Software-Reengineering-Tool GUPRO
(http://www.gupro.de) verarbeitet werden kann. Auch sollten GXL-Daten in XMI-Daten (zurück-)überführt werden können. Auch hier musste ggf. nach dem „Zielwerkzeug“ unterschieden werden, falls diese unterschiedliche XMI-„Dialekte“ benötigen. Bei GXL werden die
Schemagraphen als XML-Daten dargestellt, auf die in der Instanzgraphen-Datei referenziert
werden kann. Die DTD dient bei GXL der Definition der Syntax, mit der sowohl die Graphenschemata als auch die Instanzgraphen beschrieben werden. In XMI (Version 1.x) werden
die Graphenschemata als DTD angegeben (d.h. zu jeder Sprache kann eine DTD generiert
werden), ab Version 2.0 ist auch die Darstellung als XML-Schema möglich.
Durch die für diese Studienarbeit vorgegebene Einschränkung auf UML-Modelle war die
UML DTD, die aufgrund der „XML DTD Production Rules“ erzeugt wurde, genau zu analysieren ([XMI02], Anhang A) und mit dem entsprechenden GXL-Schema zu vergleichen.
Auch eine Unterstützung des DI (Diagram Interchange)-Formats, welches die Speicherung
der visuellen Darstellung der Modelle erlaubt, war (je nach Unterstützung dieses Formats
durch die Entwurfs-Software) angedacht. Hier könnten dann auch die graphische Darstellung
der Modelle berücksichtigt werden, welche in der aktuellen GXL-Version unterstützt wird.
Allerdings wurde dies in dieser Studienarbeit nicht umgesetzt.
5. Überblick über die Studienarbeit
Im Anschluß wird in Abschnitt II und III ein Überblick über die Konzepte der GXL (Graph
Exchange Language) und von XMI (XML Metadata Interchange) gegeben. In Abschnitt IV
wird die Umsetzung verschiedener UML-Konzepte durch die verwendeten Tools Ameos und
Rational Rose (in XMI) sowie die entsprechende Darstellung durch die GXL aufgezeigt. Im
fünften Abschnitt wird auf die Auswahl der Programmiersprache zur Realisierung der Umsetzungsprogramme eingegangen und die zur Auswahl stehenden Konzepte JAXP und XSLT
vorgestellt. Vor der abschließenden Zusammenfassung werden in Abschnitt VI kurz die
durchgeführten Tests der Programmfunktionalität erläutert und in Abschnitt VII auf die praktische Anwendung der erstellten Programme und der verwendeten Werkzeuge eingegangen.
Ebenso wird hier auf Besonderheiten, die während der Benutzung aufgefallen sind, verwiesen.
9
II. GXL – Graph Exchange Language
1. Einleitung
GXL (Graph eXchange Language) wurde als Standardaustauschformat für graphbasierte Anwendungen entwickelt. GXL ist als eine XML-Sprache definiert, hiermit können Graphen und
(zugehörige) Schema-Informationen in einem einheitlichen Format ausgetauscht werden. Die
darzustellenden Daten werden als attributierte, typisierte, gerichtete Graphen (kurz TGraphen)
beschrieben, die durch Konzepte zur Unterstützung der Darstellung von Hypergraphen und
hierarchischen Graphen erweitert werden [WiKuRi01]. Die Syntax von GXL ist in Form einer
DTD (Document Type Definition) angegeben.
2. Beispiele
<?xml version="1.0"?>
<!DOCTYPE gxl SYSTEM "gxl-1.0.dtd">
<gxl><graph id = “graph1”>
<node id = "p">
<type xlink:href = "schema.gxl#Proc"/>
<attr name = "file">
<string>main.c</string>
</attr>
</node>
<node id = "v">
<type xlink:href = "schema.gxl#Var"/>
<attr name = "line">
<int>27</int>
</attr>
</node>
<edge id = "e" from = "p" to = "v">
<type xlink:href =
"schema.gxl#refers"/>
<attr name = "line">
<int>42</int>
</attr>
</edge>
</graph></gxl>
p : Proc
File = “main.c“
e : refers
line = 42
v : Var
line = 27
Beispiel 1: attributierter, typisierter, gerichteter
Graph mit attributierter Kante
10
Der in Bild 1 dargestellte Graph wird in der angegebenen Form als GXL-Dokument gespeichert. Knoten werden als node-Elemente, Kanten als edge-Elemente gespeichert, denen jeweils eine eindeutige ID zugewiesen wird. Bei Kanten muss jeweils der Start- und Endknoten
angegeben werden. Zugehörige Attribute werden als attr-Elemente gespeichert. Der Typ eines
Elements wird durch einen Verweis auf eine zugehörige schema.gxl-Datei, die diese spezifiziert, definiert. Der gesamte Graph wird in <gxl>-Tags eingeschlossen.
Bei ungerichteten Kanten wird dies durch orientation = „undirected“ bei den Kantenattributen
angegeben, ist der ganze Graph ungerichtet, kann dies auch als Attribut des kompletten Graphen angegeben werden (siehe DTD).
<rel id = "r"
orientation = "directed">
<link ref = "u"
role = "theFirstU"
direction = "out"
endorder = "2" />
<link ref = "u"
role = "theSecondU"
direction = "out"
endorder = "1" />
<link ref = "v"
role = "theV"
direction = "in" />
<link ref = "w"
role = "theW"
direction = "none"/>
</rel>
v:V
theV
theSecondU
{1}
u:U
r:
{2}
theFirstU
theW
w:W
Beispiel 2: Hypergraph und n-äre Relationen
Hierarchische Graphen werden als Graphen innerhalb eines Knotens gespeichert, siehe Bild 3.
<node id = "t">
<type xlink:href =
"schema.gxl#T" />
<graph id = "g">
<type xlink:href =
"schema.gxl#GraphT"/>
<node id = "v"/>
<node id = "w"/>
<edge id = "e"
from = "v" to = "w"/>
</graph>
</node>
<node id = "u"/>
<edge id = "f"
from = "t" to = "u"/>
t:T
g : GraphT
v:
e:
w:
f:
u:
Beispiel 3: Hierarchischer Graph
11
3. GXL DTD
Im folgenden wird der Aufbau der gxl.dtd dargestellt und erläutert. Alle Informationen aus
diesem Abschnitt finden sich (ausführlicher) unter [GXL02].
3.1 Extensions

<!ENTITY % gxl-extension
<!ENTITY % graph-extension
<!ENTITY % node-extension
<!ENTITY % edge-extension
<!ENTITY % rel-extension
<!ENTITY % value-extension
<!ENTITY % relend-extension
<!ENTITY
<!ENTITY
<!ENTITY
<!ENTITY
<!ENTITY
<!ENTITY
%
%
%
%
%
%
""
""
""
""
""
""
""
>
>
>
>
>
>
>
gxl-attr-extension
graph-attr-extension
node-attr-extension
edge-attr-extension
rel-attr-extension
relend-attr-extension
""
""
""
""
""
""
>
>
>
>
>
>
Dies sind vordefinierte „leere“ Makros, um Informationen zu GXL-Dokumenten hinzuzufügen. Da diese Erweiterungen von den GXL-Werkzeugen nicht unterstützt werden, soll hierauf
auch nicht näher eingegangen werden.
3.2 Attribut-Typen

<!ENTITY % val "
locator |
bool
|
int
|
float
|
string |
enum
|
seq
|
set
|
bag
|
tup
%value-extension;">
Hier werden die möglichen Attribut-Typen in GXL aufgezählt, neben den OCL-Standarddatentypen (bool, int, float, string, seq, set und bag) sind Tupel (tup) und Aufzählungen (enum)
möglich, mit dem locator-Datentyp werden Dokumente und XML-Elemente verlinkt.
12
3.3 GXL-Element

<!ELEMENT gxl (graph* %gxl-extension;) >
<!ATTLIST gxl
xmlns:xlink CDATA
#FIXED
"http://www.w3.org/1999/xlink"
%gxl-attr-extension;
>
Mit diesem Element wird das GXL-Dokument, welches mehrere Graphen enthalten kann,
„eingeschlossen“. Mit dem xlink-Attribut kann auf Objekte verwiesen werden, die außerhalb
des aktuellen GXL-Dokuments definiert werden.
3.4 Type-Element

<!ELEMENT type EMPTY>
<!ATTLIST type
xlink:type (simple)
#FIXED "simple"
xlink:href CDATA
#REQUIRED
>
Im type-Element wird auf entsprechende Elemente des Schemas verwiesen. Typen können
folgenden Elementen zugewiesen werden: graph, node, edge, rel und attr. Alle Typen eines
einzelnen Graphen müssen auf Elemente eines einzelnen Schema-Graphen verweisen. Ein
Knoten vom Typ Text (der in einer type.gxl-Datei definiert ist), würde folgendermaßen dargestellt:
<node id=“node1“>
<type xlink:href = “type.gxl#Text“ />
</node>
3.5 Graph-Element
<!ELEMENT graph (type? , attr* , ( node | edge | rel )*
%graph-extension;) >
<!ATTLIST graph
id
ID
#REQUIRED
role
NMTOKEN #IMPLIED
edgeids
( true | false ) "false"
hypergraph ( true | false ) "false"
edgemode
( directed | undirected |
defaultdirected | defaultundirected) "directed"
%graph-attr-extension;
>
Mit diesem Element wird ein Graph innerhalb eines GXL-Dokuments eingeschlossen.
Es kann ein Link zu der entsprechenden Typ-Definition im Schema-Graphen angegeben werden. Ein Graph kann mehrere Knoten (node), Kanten (edge) oder Relationen (rel) enthalten.
Als Attribut kann neben der (benötigten) id eine Rolle (role) angegeben werden.
13
Das edgeids-Attribut gibt an, ob Kanten und Relationen eigene IDs besitzen (true) oder nicht
(false). Das hypergraph-Attribut gibt an, ob mehrere Elemente miteinander verknüpft sein
können (durch Hyperedges). Im edgemode-Attribut kann angegeben werden, ob die einzelnen
Kanten des Graphen gerichtet (directed) oder ungerichtet (undirected) sein sollen; dies kann
in der Definition der einzelnen Kanten dann nicht mehr überschrieben werden. Des Weiteren
besteht die Möglichkeit, hier einen Default-Wert anzugeben, der dann bei bestimmten Kanten
oder Relationen überschrieben werden kann.
3.6 Node-Element
<!ELEMENT node (type? , attr*, graph* %node-extension;) >
<!ATTLIST node
id
ID
#REQUIRED
%node-attr-extension;
>
Ein Knoten kann auf seinen Typ im Graph-Schema verweisen und eine Liste von Attributen
und Graphen (zur Darstellung hierarchischer Graphen) enthalten.
Jeder Knoten muss eine eindeutige ID besitzen.
3.7 Edge-Element
<!ELEMENT edge (type?, attr*, graph* %edge-extension;) >
<!ATTLIST edge
id
ID
#IMPLIED
from
IDREF
#REQUIRED
to
IDREF
#REQUIRED
fromorder
CDATA
#IMPLIED
toorder
CDATA
#IMPLIED
isdirected
( true | false ) #IMPLIED
%edge-attr-extension;
>
Eine Kante (edge) stellt eine Verbindung zweier Elemente dar. Es kann wiederum auf den im
Graphen-Schema definierten Typen verwiesen werden, außerdem können eine Liste von Attributen und Graphen angegeben werden.
Als Attribut kann eine ID angegeben werden, es müssen im from- und to-Attribut die beiden
verknüpften Elemente anhand ihrer ID referenziert werden. In Graphen, die in einer festgelegten Reihenfolge durchlaufen werden müssen kann diese Ordnung durch Angabe eines fromorder- und toorder-Attributs angegeben werden, diese Werte müssen Zahlen sein. Im isdirected-Attribut kann schließlich festgelegt werden, ob die Kante gerichtet (true) oder ungerichtet (false) interpretiert werden soll; hierbei kann dieser Wert aber von der Festlegung im
graph-Element überschrieben werden (siehe Abschnitt 3.5).
14
3.8 Rel-Element
<!ELEMENT rel (type? , attr*, graph*, relend* %rel-extension;)
>
<!ATTLIST rel
id
ID
#IMPLIED
isdirected
( true | false ) #IMPLIED
%rel-attr-extension;
>
Das rel-Element erlaubt die Definition n-ärer Relationen, die mehrere Graph-Elemente verbinden. Hier kann analog zu Knoten und Kanten wiederum der Typ sowie eine Liste von Attributen und Graphen angegeben werden. Zusätzlich können die Relations-Endpunkte (relend)
verzeichnet werden.
Analog zu Kanten („2-äre Relationen“) kann eine ID vergeben werden. Das isdirectedAttribut gibt auch hier an, ob die Kanten als gerichtet oder ungerichtet zu interpretieren.
3.9 Relend-Element
<!ELEMENT relend (attr* %relend-extension;) >
<!ATTLIST relend
target
IDREF
#REQUIRED
role
NMTOKEN
#IMPLIED
direction
( in | out | none)
#IMPLIED
startorder CDATA
#IMPLIED
endorder
CDATA
#IMPLIED
%relend-attr-extension;
>
Die relend-Liste einer rel-Definition enthält die Liste der verbundenen Graphen-Elemente.
relend-Elemente können eine eigene Liste von Attributen enthalten.
Als Attribut muss die ID der „Eltern-Relation“ angegeben werden; es können eine Rolle sowie die Richtung bezüglich der zugehörigen Relation (zeigt auf die Relation (in) oder aus der
Relation heraus(out), oder ungerichtet (none bzw. keine Angabe)) angegeben werden. Die
Ordnung der Relations-Endpunkte kann wiederum (analog zu Kanten) mit dem startorder(bezüglich der Relation) und endorder-Attribut (bezüglich des Endpunkts der Relation) als
Zahl angegeben werden.
3.10 Attr-Element
<!ELEMENT attr (attr*, (%val;)) >
<!ATTLIST attr
id
ID
#IMPLIED
name
NMTOKEN #REQUIRED
kind
NMTOKEN #IMPLIED
>
Ein Attribut hat einen Namens- und einen Wert-Teil (val). Attribute können wiederum weitere
Attribute enthalten. Es kann eine ID angegeben werden. Das kind-Attribut dient der Unterscheidung verschiedener Arten von Attributen (z.B. zur Kennzeichnung abgeleiteter Attribute).
15
Der Wert eines Attributs kann von den OCL-Standard-Typen bool, int, float, string, seq, set,
und bag oder tup(le), enum oder locator sein.
3.11 Locator-Element
<!ELEMENT locator EMPTY >
<!ATTLIST locator
xlink:type (simple)
xlink:href CDATA
>
#FIXED "simple"
#REQUIRED
Ein locator-Element verweist auf zusätzliche Dokumente oder Dokument-Elemente.
3.12 Datentypen
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
bool
int
float
string
(#PCDATA)
(#PCDATA)
(#PCDATA)
(#PCDATA)
>
>
>
>
Atomare Datentypen. GXL benutzt die Bezeichnungen und Grammatikregeln von Java.
<!ELEMENT enum
(#PCDATA) >
Werte, die vom Typ Aufzählung sind.
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
seq
set
bag
tup
(%val;)*
(%val;)*
(%val;)*
(%val;)*
>
>
>
>
Zusammengesetzte Werte, die weitere Werte (vom gleichen Typ) enthalten.
4. Graph-Schemata
Graph-Klassen werden bei GXL durch UML-Klassen-Diagramme definiert (siehe als Beispiel
Abbildung 1). Knoten-Klassen (hier Function, Variable und FunctionCall) werden durch
Klassen definiert, Kanten-Klassen (isCallee, isOutput und isCaller) durch Assoziationen und
attributierte Kanten-Klassen (isCaller) werden durch Assoziations-Klassen beschrieben.
Abbildung 1: Graph-Schema (als UML-Klassendiagramm) [WiKuRi01]
16
Die Richtung der Kanten wird durch ein gefülltes Dreieck angegeben. Mit dem Schlüsselwort
„ordered“ wird die Existenz einer Reihenfolge angegeben. Auf ähnliche Weise können Hypergraphen und hierarchische Graph-Schemata in der üblichen UML-Notation dargestellt
werden. Diese UML-Klassendiagramme können als Graphen und damit in einer GXLkompatiblen Weise dargestellt werden. Damit können dann Instanz-Graphen und die dazugehörigen Schema-Graphen mit dem gleichen Dokumentenformat (d.h. GXL) ausgetauscht
werden.
In Abbildung 2 wird das UML-Klassendiagramm aus Abbildung 1 als TGraph dargestellt, der
dann wie jeder andere Graph in GXL gespeichert werden kann.
Hierzu werden Knotenklassen und Kantenklassen als Knoten vom Typ NodeClass bzw.
EdgeClass modelliert, deren Attribute weitere Eigenschaften beschreiben. Beziehungen zwischen diesen Knoten (bzw. zwischen den Klassen) werden durch Kanten des entsprechenden
Typs dargestellt (from und to-Kanten mit Attributen, die Richtung und Kardinalitäten als Attribute enthalten).
Attribute und Attributtypen werden als AttributeClass-Knoten mit passenden AttributtypKnoten dargestellt. Attributinformationen werden mit den ensprechenden Knoten- und Kantenklassen mit hasAttribute und hasDomain-Kanten verbunden.
Analog können auch weitere Konzepte wie Hierarchie, Hypergraphen, Aggregation und
Komposition sowie Generalisation modelliert werden.
Die Graphenklasse selbst wird durch einen GraphClass-Knoten dargestellt, der durch (contains-)Kanten mit allen Entsprechungen von Knoten- und Kantenklassen verbunden ist.
In GXL-Dokumenten, die Instanz-Graphen repräsentieren, kann dann mittels Verweisen auf
die entsprechenden Definitionen verwiesen werden. [WiKuRi01] [HSSW04]
Abbildung 2: Graph-Schema (als Schema-Graph) [WiKuRi01]
Das komplette GXL-Metaschema findet sich unter
http://www.gupro.de/GXL/MetaSchema/metaSchema.html.
17
III. XMI – XML Metadata Interchange
1. Einleitung
Das XMI (XML Metadata Interchange)-Format wurde zur textuellen Darstellung von auf dem
MOF (Meta Object Facility)-Metamodell basierenden Modellen entwickelt. Hierunter fallen
auch UML (Unified Modelling Language)-Modelle, wobei im Rahmen dieser Studienarbeit
wiederum nur Klassen- und Objektdiagramme relevant sind. Allerdings wurde während des
Überprüfens der verwendeten Tools (Ameos von Aonix und Rational Rose von Rational
Software/IBM) festgestellt, dass Objektdiagramme nicht exportiert bzw. dargestellt werden
können. Diese XMI-Daten können von verschiedenen Tools, unter anderem auch den in der
Studienarbeit verwendeten Rational Rose und Ameos, aus dort entworfenen Diagrammen/Modellen generiert werden. Die so erzeugten Dokumente sollen sowohl zwischen diesen
Werkzeugen ausgetauscht werden können als auch in GXL-Dateien umgewandelt werden, die
dann von entsprechenden Werkzeugen verarbeitet werden können (z.B. Gupro).
Da die verwendeten Werkzeuge XMI-Dokumente in der XMI-Version 1.1 erzeugen, soll hier
nur auf diese Version vom November 2000 eingegangen werden (Spezifikation siehe
[XMI00]); aktuell ist die Version 2.0, die auch den UML 2.0-Standard unterstützt (siehe
[XMI03]).
2. MOF – Meta Objects Facility
Die Meta Objects Facility ist die Beschreibungssprache der OMG, mit der alle Modellierungssprachen der OMG (und damit auch UML) beschrieben werden. Das MOF-Metametamodell (kurz MOF-Modell) ist eine Sprache, um MOF-Metamodelle (z.B. das UML-Metamodell) zu definieren, so wie das UML-Metamodell eine Sprache darstellt, um UML-Modelle
zu definieren. Das UML-Metamodell selbst ist eine Instanz des MOF-(Metameta-)Modells.
MOF-Modell und der Hauptteil des UML-Metamodells sind eng verwandt; die UML-Notation wird benutzt, um MOF-basierte Metamodelle zu beschreiben.
Das MOF-Modell wird in einer 4-Schichten-Darstellung dargestellt:
Meta-Level
M3
M2
M1
M0
MOF-Begriffe
Meta-Metamodell
Metamodell
Modell
Objekte
Beispiele
Das MOF-Modell
UML-Metamodell
UML-Modelle
Modellierte Systeme
Tabelle 1: MOF-Modell
3. XMI-DTD
Da mit XMI außer UML auch andere Metamodelle (basierend auf der MOF) dargestellt werden können, werden in der Spezifikation [XMI00] Regeln vorgegeben, mit denen aus jedem
MOF-Metamodell (wie z.B. dem UML-Metamodell) eine DTD (Document Type Definition)
generiert werden kann, die die Syntax des entsprechenden Modells beschreibt. Diese Regeln
werden in Abschnitt 4 der Spezifikation [XMI00] in EBNF-Schreibweise dargestellt. Durch
diese DTD (also der Metamodell-Beschreibung) wird der Aufbau der XMI-Dokumente (der
Modelle) festgelegt.
18
Im Rahmen dieser Studienarbeit sind nur die von den zu unterstützenden Werkzeugen verwendeten UML-Modelle (Rational Rose verwendet UML 1.3, Ameos UML 1.4) im Rahmen
der Umwandlung relevant.
Zuerst soll hier auf die notwendigen Elemente und Attribute, die jedes XMI-Dokument enthalten kann (oder enthalten muss) eingegangen werden. Die hier verwendeten Informationen
finden sich in ausführlicher Form im 3. Kapitel der XMI-Spezifikation 1.1 [XMI00].
Jede XMI-DTD besteht aus den folgenden Deklarationen [XMI00]:
- Eine „XML-Version-Verarbeitungs-Anweisung“ (Beispiel: <? XML version=”1.0” ?>).
- Eine optionale Kodierungs-Deklaration über den verwendeten Zeichensatz nach dem ISO10646-Standard (Beispiel: <? XML version="1.0" ENCODING=”UCS-2” ?>).
- Andere gültige XML-Verarbeitungs-Anweisungen.
- Die erforderlichen XMI-Deklarationen (siehe 3.1)
- Deklarationen für ein spezielles Metamodell
- Deklarationen für „Unterschiede“
- Deklarationen für Erweiterungen
Jedes XMI-Dokument besteht aus den folgenden Deklarationen:
- Eine „XML-Version-Verarbeitungs-Anweisung“ (Beispiel: <? XML version=”1.0” ?>).
- Eine optionale Kodierungs-Deklaration über den verwendeten Zeichensatz nach dem ISO10646-Standard (Beispiel: <? XML version="1.0" ENCODING=”UCS-2” ?>).
- Andere gültige XML-Verarbeitungs-Anweisungen.
- Eine optionale externe DTD-Deklaration, die wiederum (optionale) interne DTD-Deklarationen enthalten kann
(Beispiel: <! DOCTYPE XMI SYSTEM “http://www.xmi.org/xmi.dtd“ >).
Ein Beispieldokument befindet sich in Abschnitt 4.1.
3.1 Notwendige XMI-DTD-Deklarationen
3.1.1 Attribute zur Identifikation
Zuerst werden drei XML-Attribute definiert, um XML-Elemente zu kennzeichnen, damit andere XML-Elemente auf diese verweisen können. Diese Attribute werden in der Entity
XMI.element.att deklariert:
<!ENTITY % XMI.element.att
’xmi.id ID #IMPLIED
xmi.label CDATA #IMPLIED
xmi.uuid CDATA #IMPLIED ’ >
Die xmi.id kann eine eindeutige ID innerhalb eines XML-Dokuments bezeichnen; hierauf
kann mit dem xmi.idref-Attribut verwiesen werden und es kann als Wert des href-Attributs in
XLinks verwendet werden. Diese Attribute werden in Abschnitt 3.1.2 beschrieben.
xmi.label kann eine beliebige Beschreibung des Elements enthalten, xmi.uuid kann einen (global) eindeutigen Identifier für das Element enthalten.
3.1.2 Verweise auf Attribute
Damit XML-Elemente auf andere Elemente verweisen können, benötigt XMI einige XMLAttribute, die als Wert die oben verwendeten IDs benutzen.
19
<!ENTITY % XMI.link.att
'href CDATA #IMPLIED
xmi.idref IDREF #IMPLIED' >
Mit dem Attribut href kann auf XML-Elemente verwiesen werden, deren xmi.id-, xmi.labeloder xmi.uuid-Attribute auf die entsprechenden Werte gesetzt sind. xmi-idref verweist auf das
Element mit der entsprechenden xmi.id.
3.2 Übersicht der Elemente einer XMI-DTD
Jede XMI-DTD muss die Deklarationen für die folgenden XML-Elemente enthalten:
• XMI
• XMI.header
• XMI.documentation
• XMI.owner
• XMI.contact
• XMI.longDescription
• XMI.shortDescription
• XMI.exporter
• XMI.exporterVersion
• XMI.exporterID
• XMI.notice
• XMI.model
• XMI.metamodel
• XMI.metametamodel
• XMI.import
• XMI.content
• XMI.extension
• XMI.reference
• XMI.difference
• XMI.delete
• XMI.add
• XMI.replace
• XMI.extensions
Die folgenden weiteren Deklarationen werden benötigt, wenn die entsprechenden Datentypen
von dem verwendeten Metamodell benutzt werden:
• XMI.field
• XMI.array
• XMI.struct
• XMI.enum
• XMI.seqItem
• XMI.discrim
• XMI.sequence
• XMI.union
• XMI.arrayLen
• XMI.any
Im folgenden werden diese Deklarationen genauer beschrieben. Dabei wird nach dem Wurzelelement zuerst auf die inneren Elemente der ersten Ebene eingegangen (3.2.2 bis 3.2.5),
anschließend auf die darin enthaltenen Elemente.
3.2.1 XMI
Das Wurzel-Element jedes XMI-Dokuments ist das Element XMI.
Es kann einen XMI.header und XMI.content-Elemente enthalten, außerdem kann es mehrere
XMI.difference und XMI.extensions-Elemente enthalten.
20
Das Attribut xmi-version muss auf 1.1 gesetzt sein (zumindest für XMI-Dokumente, die der
hier verwendeten Spezifikation entsprechen). Als Attribute können timestamp (Zeitpunkt der
Datenerzeugung) sowie eine Angabe, ob das Modell dem Metamodell entspricht oder nicht
(verified), enthalten sein.
<!ELEMENT XMI (XMI.header?,
XMI.content?,
XMI.difference*,
XMI.extensions*) >
<!ATTLIST XMI
xmi.version CDATA #FIXED "1.1"
timestamp CDATA #IMPLIED
verified (true | false) #IMPLIED
>
Zusätzlich können die benutzten Namensbereiche deklariert werden:
<!ATTLIST XMI xmlns:n #CDATA IMPLIED>
3.2.2 XMI.header
Das Element XMI.header enthält Angaben, die das verwendete Model, Metamodell und Metametamodell bezeichnen, sowie Angaben über die übertragenen Metadaten:
<!ELEMENT XMI.header (XMI.documentation?,
XMI.model*,
XMI.metamodel*,
XMI.metametamodel*,
XMI.import*) >
3.2.3 XMI.content
Das Element XMI.content enthält die zu übertragenden Metadaten:
<!ELEMENT XMI.content ANY >
3.2.4 XMI.difference
Das Element XMI.difference enthält Elemente, die Unterschiede zur den Basis-Daten repräsentieren. Es kann im Content-Teil eines XMI-Dokuments oder in einem eigenen Abschnitt
benutzt werden. Es kann Löschungen, Hinzufügungen oder Ersetzungen von Basis-Metadaten
durch Metadaten enthalten. Das Attribut xmi.position gibt an, wo der Inhalt der hinzugefügten
oder ersetzten Elemente (relativ zu anderen XML-Elementen) eingefügt werden soll.
<!ELEMENT XMI.difference (XMI.difference | XMI.add | XMI.delete | XMI.replace)* >
<!ATTLIST XMI.difference
%XMI.element.att;
%XMI.link.att;
>
21
<!ELEMENT XMI.delete EMPTY >
<!ATTLIST XMI.delete
%XMI.element.att;
%XMI.link.att;
>
<!ELEMENT XMI.add ANY >
<!ATTLIST XMI.add
%XMI.element.att;
%XMI.link.att;
xmi.position CDATA "-1"
>
<!ELEMENT XMI.replace ANY >
<!ATTLIST XMI.replace
%XMI.element.att;
%XMI.link.att;
xmi.position CDATA "-1"
>
3.2.5 XMI.extensions
Das Element XMI.extensions enthält Daten über Erweiterungen zum Metamodell (z.B. Informationen über die visuelle Darstellung der Metadaten). Das Attribut xmi-extender gibt an,
welches Werkzeug für die Erweiterungen verantwortlich ist.
<!ELEMENT XMI.extensions ANY >
<!ATTLIST XMI.extensions
xmi.extender CDATA #REQUIRED
>
3.2.6 XMI.documentation
Das Element XMI.documentation enthält Informationen über die übertragenen Metadaten, z.B.
den Eigentümer der Daten, eine Kontaktperson, Beschreibungen der Metadaten, das Werkzeug, das die Metadaten erzeugt kann, dessen Version, Copyright-Vermerke etc.:
<!ELEMENT XMI.documentation (#PCDATA |
XMI.owner | XMI.contact |
XMI.longDescription |
XMI.shortDescription | XMI.exporter |
XMI.exporterVersion | XMI.notice)* >
<!ELEMENT XMI.owner ANY >
<!ELEMENT XMI.contact ANY >
<!ELEMENT XMI.longDescription ANY >
<!ELEMENT XMI.shortDescription ANY >
<!ELEMENT XMI.exporter ANY >
<!ELEMENT XMI.exporterVersion ANY >
<!ELEMENT XMI.exporterID ANY >
<!ELEMENT XMI.notice ANY >
3.2.7 XMI.model
Das Element XMI.model gibt das verwendete Modell (oder auch die verwendeten Modelle)
an:
22
<!ELEMENT XMI.model ANY>
<!ATTLIST XMI.model
%XMI.link.att;
xmi.name CDATA #REQUIRED
xmi.version CDATA #REQUIRED>
3.2.8 XMI.metamodel, XMI.metametamodel
Analog dazu existieren die Elemente XMI.metamodel und XMI.metametamodel, die das (oder
die) verwendeten Metamodell(e) und Metametamodell(e) angeben. Das Metametamodell wird
in den meisten Fällen einen Verweis auf die verwendete MOF-Version sein.
<!ELEMENT XMI.metamodel ANY>
<!ATTLIST XMI.metamodel
%XMI.link.att;
xmi.version CDATA #REQUIRED
>
<!ELEMENT XMI.metametamodel ANY>
<!ATTLIST XMI.metametamodel
%XMI.link.att;
xmi.version CDATA #REQUIRED>
3.2.9 XMI.import
Das Element XMI.import kann auf weitere für das aktuelle Dokument benötigte Dokumente
verweisen:
<!ELEMENT XMI.import ANY>
<!ATTLIST XMI.import
%XMI.link.att;
xmi.version CDATA #REQUIRED
>
3.2.10 XMI.extension
Das Element XMI.extension enthält XML-Elemente, die Metadaten enthalten, die das Metamodell erweitern. Dieses Element kann direkt in XML-Elemente im content-Abschnitt eingefügt werden, um die erweiterten Metadaten mit einem bestimmten XML-Element zu verbinden.
<!ELEMENT XMI.extension ANY >
<!ATTLIST XMI.extension
%XMI.element.att;
%XMI.link.att;
xmi.extender CDATA #REQUIRED
xmi.extenderID CDATA #IMPLIED
>
23
3.2.11 XMI.reference
Das Element XMI.reference erlaubt Verweise auf andere XML-Elemente innerhalb eines Attributs vom Typ String oder eines XMI.any-Elements, um einen Datentyp anzugeben, der nicht
im Metamodel definiert ist.
<!ELEMENT XMI.reference ANY >
<!ATTLIST XMI.reference %XMI.link.att; >
XMI-Datentypen (wenn vom Metamodell benutzt, wie am Anfang des Abschnitts in der Aufzählung angegeben) können als “feste” oder als durch das Metamodell festgelegte Deklarationen verwendet werden (genauere Informationen hierzu in Abschnitt 3.5.18 der Spezifikation
[XMI00]).
3.3 Repräsentation von Metamodell-Klassen in der DTD
3.3.1 Namensbereiche
Bei der Produktion einer DTD für ein Metamodell kann ein Namensbereich (namespace) angegeben werden. Alle in der DTD deklarierten Tags des Metamodells beginnen mit diesem
„namespace“-Namen, gefolgt von einem Doppelpunkt („:“). Der XML-Element-Name jeder
Metamodell-Klasse, jeder Assoziation oder jedes Packages besteht aus seiner Bezeichnung,
dem der Name des Namensbereichs gefolgt von einem Doppelpunkt vorangestellt wird (Beispiel: UML:Class). Namen von Tags für Attribute und Referenzen aus dem Metamodell bestehen aus dem XML-Element-Namen der Klasse gefolgt von einem Punkt („.“) gefolgt vom
Namen des Attributs oder der Referenz (Beispiel: UML:Association.connection). Der Name
von XML-Attributen, die sich auf Metamodell-Referenzen bzw. Metamodell-Attribute beziehen, besteht nur aus dem Namen der Referenz bzw. des Attributs.
Jedem Namensbereich wird ein logischer (in der Namensbereichdeklaration des XMI-Elements im XML-Dokument) und ein physikalischer (im XMI.metamodel-Tag) URI zugewiesen (siehe hierzu das Beispiel in Abschnitt 4.1). Der logische URI enthält einen festen Namen
für einen Namensbereich (z.B. “org.omg/standards/UML”), der sich für die Benutzung dieses
Namensbereichs nicht ändert. Der physikalische URI bezeichnet den Speicherort des Dokuments (z.B. ftp://server.omg.org/resources/xmi/UML13.xml.
3.3.2 Deklaration einer Metamodell-Klasse
Jede Metamodell-Klasse wird in drei Teile zerlegt, diese drei werden als „Entities“ für jede
Metamodell-Klasse deklariert, wobei der Name der Klasse vorangestellt wird und um „Properties“, „Associations“ bzw. „Compositions“ ergänzt wird. Hier als Beispiel die Deklaration
für den einfachsten Fall einer Klasse „c“ ohne Attribute, Assoziationen oder Ist-Enthalten-InBeziehungen:
<!ENTITY % cProperties ‘’>
<!ENTITY % cAssociations ‘’>
<!ENTITY % cCompositions ‘’>
<!ELEMENT c (XMI.extension)* >
<!ATTLIST c
%XMI.element.att;
%XMI.link.att;
>
24
3.3.3 Vererbung
Da in XML kein Vererbungs-Konzept existiert, wird in XMI eine einfache „copy-down“Vererbung spezifiziert. Als Beispiel wird hier eine Klasse „c1“ mit einer direkten Oberklasse
„c0“ im Metamodell durch folgende „Entities“ dargestellt:
<!ENTITY % c1Properties ‘%c0Properties ; properties for c1, if any...’>
<!ENTITY % c1Associations ‘%c0Associations; associations for c1, if any...’ >
<!ENTITY % c1Compositions ‘%c0Compositions; compositions for c1, if any...’ >
Daraus folgt auch, dass die Oberklassen vor ihren Unterklassen deklariert werden müssen.
3.3.4 Multiplizitäten
Multiplizitäten aus dem Metamodell werden bei der Generierung der DTD ignoriert, mit Ausnahme der Deklaration von XML-Attributen zu Metamodell-Assoziationen.
3.3.5 Attribut-Spezifikation
Attribute der Metamodellklasse „c“ werden durch XML-Elemente und XML-Attribute definiert. Falls die Metamodell-Attributtypen primitive Datentypen oder Aufzählungen sind, werden sowohl XML-Elemente als auch XML-Attribute deklariert.
Die Deklaration jedes Elements mit Namen „a“, das nicht vom Aufzählungstyp ist, enthält die
Typspezifikation des Elements, die aus dem Metamodell oder auch außerhalb des Metamodells definiert ist:
<!ELEMENT c.a (type specification) >
Für den Fall einer Spezifikation außerhalb des Metamodells wird als Typ ein String-Typ angenommen, und die Spezifikation muss folgende Form ausweisen:
<!ELEMENT c.a (#PCDATA| XMI.reference)* >
Für Attribute, deren Typ ein String-Typ ist, muss ein XML-Attribut in der Attributliste des
Elements, das auf die Metamodellklasse „c“ verweist, deklariert werden:
a CDATA #IMPLIED
Falls „a“ ein Attribut vom Typ Boolean oder vom Aufzählungstyp ist, wird folgende Deklaration (zur Verbesserung der Syntaxkontrolle) verwendet:
<!ELEMENT a EMPTY >
<!ATTLIST c.a xmi.value (enum1 | enum2 | …) #REQUIRED >
Ebenso muss hier ein XML-Attribut in der entsprechenden Attributliste deklariert werden:
a (enum1 | enum2 | ...) #IMPLIED
Auch ist ein Element vom Aufzählungstyp, wenn in seiner Klasse ein Tag „XMIDataType“
mit Wert „enum“ enthalten ist. Im Tag „XMIEnumSet“ werden die erlaubten Werte getrennt
durch Leerzeichen angeben.
25
3.3.6 DTD-Darstellung einer einfachen Klasse
Beispiel einer Klasse „c“ mit Attributen „a1“ vom Typ String und „a2“ vom Type Boolean:
<!ELEMENT a1 (#PCDATA |
XMI.reference) *>
<!ELEMENT a2 EMPTY >
<!ATTLIST a2 xmi.value (true | false)
#REQUIRED >
<!ENTITY % cProperties ‘a1 | a2’ >
3.3.7 Assoziationen
Jede Assoziation wird in einer XMI-Entity, einem XML-Element und einem XML-Attribut
festgelegt, Multiplizitäten werden ignoriert. Die Darstellung einer Assoziation „r“ einer Metamodellklasse „c“ ist:
<!ENTITY % cAssociations ‘r’ >
<!ELEMENT r ( content)* >
Das zu deklarierende XML-Attribut in der Attributliste des zugehörigen XML-Elements der
Klasse c wäre folgendermaßen:
r IDREFS #IMPLIED
„content“ ist so definiert, dass Klassen sowie ihre Subklassen, die an das „associationEnd“
gebunden sind, im XML-Element „r.“ verwendet werden können.
3.3.8 Beispiel einer DTD-Deklaration einer Assoziation
Als Beispiel die Deklaration des XML-Elements und des XML-Attributs einer Klasse c1, verbunden mit dem Assoziationende r, die drei Unterklassen c2, c3 und c4 hat (wobei c3 eine
abstrakte Klasse ist):
<!ELEMENT r (c1 | c2 | c3 | c4)* >
r IDREFS #IMPLIED
Jedes Assoziationsende, das eine „Enthalten-in“-Beziehung darstellt, wird als eine XMLEntity und eine XML-Element dargestellt. Ist eine Klasse „c“ am „Containerende“ einer
Kompositions-Assoziation, und das andere Assoziationsende hat die Rolle „r“ für eine Klasse
„c1“ mit Unterklasse „c2“, ergibt das folgende Darstellung in der DTD:
<!ELEMENT r (c1 | c2)* >
<!ENTITY % cCompositions ‘XMI.extension | r’ >
4. UML-DTD
Hier soll die in der Spezifikation verwendete UML-DTD untersucht werden. Dabei wird nur
auf die für diese Studienarbeit relevanten Teile der DTD eingegangen, d.h. der Definition der
Elemente von Klassenmodellen (Objektdiagramme können mit den verwendeten Tools nicht
exportiert werden). Die DTDs der verwendeten Werkzeuge weichen in bestimmten Punkten
26
von dieser hier ab; auf die Darstellung der UML-Konzepte in XMI bei Ameos und Rational
Rose wird in Abschnitt IV weiter eingegangen.
4.1 Einfaches Beispiel ( XMI-Dokument mit einer Klasse mit Attribut)
Als einführendes Beispiel folgt hier ein UML-Klassenmodell als ein XMI-Dokument. Dieses
Modell enthält eine einzige Klasse „C1“ mit einem Attribut „a1“ (mit Sichtbarkeit „private“).
Im Element XMI wird die Version und der Namensbereich für UML deklariert (mit einer logischen URI). Das Element XMI.metamodel enthält ebenfalls den Namen („UML“) sowie einen
Verweis auf einen physikalischen Speicherort, an dem sich die UML.xml-Datei befindet. Der
Modell-Name heißt „example“. XMI.content enthält das Modell, hier nur eine Klasse mit Namen „C1“, die wiederum ein Attribut enthält, das innerhalb des UML-Classifier.feature-Tags
in einem UML:Attribute-Tag deklariert ist.
<XMI xmi.version="1.1" xmlns:UML="org.omg/standards/UML">
<XMI.header>
<XMI.metamodel name="UML" version="1.3" href="UML.xml"/>
<XMI.model name="example" version="1" href="example.xml"/>
</XMI.header>
<XMI.content>
<UML:Class name="C1">
<UML:Classifier.feature>
<UML:Attribute name="a1" visibility="private"/>
</UML:Classifier.feature>
</UML:Class>
</XMI.content>
</XMI>
4.2 Deklaration der verwendeten Elemente
4.2.1 Klasse
Die Deklaration für eine Klasse in UML beschreibt, welche Elemente und Attribute in der
Beschreibung einer Klasse vorkommen dürfen. In den Attributen kann im XMI-Dokument
dann z.B. angegeben werden, ob die Klasse abstrakt ist (Zeile 44), eine Generalisierung (Zeile
61) oder Spezialisierung (Zeile 62) der Klasse kann referenziert werden oder der Name der
Klasse wird angegeben (Zeile 40). Alle Attribute sind hier optional. Die Klasse kann weitere
Elemente enthalten, z.B. können in UML:Classifier.feature-Tags Attribute enthalten sein.
Eine minimale Deklaration einer Klasse gemäß dieser Spezifikation in einem XMI-Dokument
wäre <UML:Class />. Auf diese Klasse könnte allerdings nicht referenziert werden, da keinerlei ID angegeben wurde.
1
2
3
4
5
6
7
8
9
10
11
<!ELEMENT UML:Class (UML:ModelElement.name |
UML:ModelElement.visibility |
UML:GeneralizableElement.isRoot |
UML:GeneralizableElement.isLeaf |
UML:GeneralizableElement.isAbstract |
UML:Class.isActive | XMI.extension |
UML:ModelElement.binding |
UML:ModelElement.template |
UML:ModelElement.templateParameter |
UML:ModelElement.implementation |
UML:ModelElement.view |
27
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
UML:ModelElement.presentation |
UML:ModelElement.namespace |
UML:ModelElement.constraint |
UML:ModelElement.requirement |
UML:ModelElement.provision |
UML:ModelElement.stereotype |
UML:ModelElement.elementReference |
UML:ModelElement.collaboration |
UML:ModelElement.behavior |
UML:ModelElement.partition |
UML:GeneralizableElement.generalization |
UML:GeneralizableElement.specialization |
UML:Classifier.parameter |
UML:Classifier.structuralFeature |
UML:Classifier.specification |
UML:Classifier.realization |
UML:Classifier.associationEnd |
UML:Classifier.participant |
UML:Classifier.createAction |
UML:Classifier.instance |
UML:Classifier.collaboration |
UML:Classifier.classifierRole |
UML:Classifier.classifierInState |
UML:ModelElement.taggedValue |
UML:Namespace.ownedElement |
UML:Classifier.feature)* >
<!ATTLIST UML:Class
name CDATA #IMPLIED
visibility (public | protected | private) #IMPLIED
isRoot (false | true) #IMPLIED
isLeaf (false | true) #IMPLIED
isAbstract (false | true) #IMPLIED
isActive (false | true) #IMPLIED
binding IDREFS #IMPLIED
template IDREFS #IMPLIED
templateParameter IDREFS #IMPLIED
implementation IDREFS #IMPLIED
view IDREFS #IMPLIED
presentation IDREFS #IMPLIED
namespace IDREFS #IMPLIED
constraint IDREFS #IMPLIED
requirement IDREFS #IMPLIED
provision IDREFS #IMPLIED
stereotype IDREFS #IMPLIED
elementReference IDREFS #IMPLIED
ModelElement.collaboration IDREFS #IMPLIED
behavior IDREFS #IMPLIED
partition IDREFS #IMPLIED
generalization IDREFS #IMPLIED
specialization IDREFS #IMPLIED
parameter IDREFS #IMPLIED
structuralFeature IDREFS #IMPLIED
specification IDREFS #IMPLIED
realization IDREFS #IMPLIED
associationEnd IDREFS #IMPLIED
28
68
69
70
71
72
73
74
75
76
participant IDREFS #IMPLIED
createAction IDREFS #IMPLIED
instance IDREFS #IMPLIED
Classifier.collaboration IDREFS #IMPLIED
classifierRole IDREFS #IMPLIED
classifierInState IDREFS #IMPLIED
%XMI.element.att;
%XMI.link.att;
>
29
4.2.2 Assoziation
Eine Assoziation wird durch das Element UML:Association beschrieben. Dieses kann als Attribut z.B. einen Namen für die Assoziation enthalten. Eine Assoziation zwischen zwei Klassen „Class1“ und „Class2“ in einem XMI-Dokument kann beispielsweise so aussehen:
<UML:Association name = 'Association1'>
<UML:Association.connection>
<UML:AssociationEnd name = 'end1' type = 'Class1'>
<UML:AssociationEnd.multiplicity>
<UML:Multiplicity>
<UML:Multiplicity.range>
<UML:MultiplicityRange
lower = '0' upper = '-1'>
</UML:MultiplicityRange>
</UML:Multiplicity.range>
</UML:Multiplicity>
</UML:AssociationEnd.multiplicity>
</UML:AssociationEnd>
<UML:AssociationEnd name = 'end2'>
<UML:AssociationEnd.participant>
<UML:Classifier xmi.idref = 'Class2'/>
</UML:AssociationEnd.participant>
</UML:Association.connection>
</UML:Association>
Laut der DTD-Deklaration der Assoziation kann ein UML:Association.connection-Element
enthalten sein (Zeile 27), dies wiederum kann ein UML:AssociationEnd-Element enthalten
(Zeile 58). Nach der DTD-Spezifikation könnte das UML:Association-Element aber auch direkt ein Element UML:Association.associationEnd (Zeile 24) enthalten oder das Assoziationsende als Attribut enthalten (Zeile 53). Die Multiplizität kann im UML:AssociationEndElement beschrieben werden (Zeile 66). Soll eine Komposition dargestellt werden, kann hier
z.B. auch das Attribut aggregation (Zeile 97) auf „composite“ gesetzt werden. Das hier von
Ameos verwendete Tag UML:AssociationEnd.participant (bei der Beschreibung des 2. Assoziations-Endes) ist in der hier dargestellten Standard-XMI-Spezifikation nicht enthalten. Daher wäre obiges Dokument nach der „Standard“-UML-DTD der XMI-Spezifikation der OMG
[XMI00] nicht gültig.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<!ELEMENT UML:Association (UML:ModelElement.name |
UML:GeneralizableElement.isRoot |
UML:GeneralizableElement.isLeaf |
UML:GeneralizableElement.isAbstract |
XMI.extension | UML:ModelElement.binding |
30
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
UML:GeneralizableElement.generalization |
UML:GeneralizableElement.specialization |
UML:Association.link |
UML:Association.associationEnd |
UML:Namespace.ownedElement |
UML:Association.connection)* >
<!ATTLIST UML:Association
name CDATA #IMPLIED
isRoot (false | true) #IMPLIED
isLeaf (false | true) #IMPLIED
isAbstract (false | true) #IMPLIED
collaboration IDREFS #IMPLIED
generalization IDREFS #IMPLIED
specialization IDREFS #IMPLIED
link IDREFS #IMPLIED
associationEnd IDREFS #IMPLIED
%XMI.element.att;
%XMI.link.att;
>
<!ELEMENT UML:Association.connection (UML:AssociationEnd |
UML:AssociationEndRole)* >
<!ELEMENT UML:AssociationEnd (UML:ModelElement.name |
UML:AssociationEnd.isNavigable |
UML:AssociationEnd.isOrdered |
UML:AssociationEnd.aggregation |
UML:AssociationEnd.multiplicity |
UML:AssociationEnd.changeable |
UML:AssociationEnd.targetScope |
XMI.extension | UML:ModelElement.binding |
31
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
UML:AssociationEnd.type |
UML:AssociationEnd.specification |
UML:AssociationEnd.association |
UML:AssociationEnd.linkEnd |
UML:AssociationEnd.associationEndRole |
UML:AssociationEnd.qualifier)* >
<!ATTLIST UML:AssociationEnd
name CDATA #IMPLIED
isNavigable (false | true) #IMPLIED
isOrdered (false | true) #IMPLIED
aggregation (none | shared | composite) #IMPLIED
multiplicity CDATA #IMPLIED
changeable (none | frozen | addOnly) #IMPLIED
targetScope (classifier | instance) #IMPLIED
collaboration IDREFS #IMPLIED
type IDREFS #IMPLIED
specification IDREFS #IMPLIED
association IDREFS #IMPLIED
linkEnd IDREFS #IMPLIED
associationEndRole IDREFS #IMPLIED
%XMI.element.att;
%XMI.link.att;
32
5. Beispieldiagramm
0..*
isInput
FunctionCall
isCallee
0..*
0..*
{ordered}
isOutput
0..*
0..*
1
0..*
Variable
Function
-name: String
isCaller
-name: String
1
Abbildung 3: UML-Klassendiagramm in Ameos (vergleiche auch Abschnitt II.4, [WiKuRi01])
Ein Export des Klassendiagramms aus Abbildung 3 mit Ameos in XMI ergibt die Datei in
Anhang A.
Eine genauere Erläuterung der Darstellung der einzelnen UML-Konzepte in XMI-Dateien
findet sich im folgenden Abschnitt IV.
33
IV. UML-Konzepte für Klassendiagramme in XMI und GXL
1. Einleitung
In diesem Abschnitt wird die Umsetzung verschiedener UML-Konzepte bei der textuellen
Darstellung mit XMI und deren Umsetzung in Graphen, die mit GXL dargestellt werden können, behandelt. Dabei wird zuerst das entsprechende UML-Konzept graphisch skizziert und
dieses in eine XMI-Darstellung überführt. Diese XMI-Umsetzung wird sowohl mit Ameos
(Aonix) als auch mit Rational Rose (IBM) vorgenommen, da hier teilweise Unterschiede auftreten. Dann wird dieses UML-Konzept als GXL-Graph dargestellt, der dem GXLMetaschema entspricht.
Im Rahmen der Studienarbeit wurde ein Werkzeug entwickelt, das die von Ameos und Rational Rose erzeugten XMI-Dateien in GXL-Graphen umsetzt (XMI2GXL), sowie GXLGraphen in XMI-Dateien umwandelt, die dann von Ameos und Rational Rose eingelesen werden können.
Objektdiagramme sollten auch berücksichtigt werden, allerdings wurde im Laufe der Studienarbeit festgestellt, dass Rational Rose keine Objektdiagramme unterstützt und bei Ameos der
XMI-Export von Objekten nicht implementiert ist.
2. UML-Konzepte
2.1 Klasse
Abbildung 4: Einfache Klasse
2.1.1 Klasse: XMI-Darstellung
Eine einfache Darstellung dieser Klasse ohne Attribute als XMI-Dokument ist im folgenden
Listing dargestellt. Soll diese einfache Klasse ohne Attribute und Operationen als XMIDokument dargestellt werden, sind ausser den Headerinformationen nur die Informationen in
Zeile 7 unbedingt erforderlich. Im Header wird hier auch der Dateiname angegeben (Zeile 3).
1
2
3
4
5
6
7
8
9
<XMI version="1.1" xmlns:UML="org.omg/UML1.3">
<XMI.header>
<XMI.model xmi.name="Klasse" href="Klasse.xml"/>
<XMI.metamodel xmi.name="UML" href="UML.xml"/>
</XMI.header>
<XMI.content>
<UML:Class name="Class1" xmi.id="Class1"/>
</XMI.content>
</XMI>
34
2.1.1.1 Ameos
Wird diese einfache Klasse mit Ameos modelliert und als XMI-Dokument exportiert, werden
dem Dokument einige Informationen hinzugefügt, siehe hierzu das folgende Listing.
In den Zeilen 1 bis 5 stehen die Headerinformationen, hier z.B. der verwendete Zeichensatz,
die XMI-Version (Ameos unterstützt nur Version 1.1) und das verwendete Metamodell. Die
Darstellung der Klasse findet sich in den Zeilen 10 bis 19, hier werden als Attribute die Eigenschaften der Klasse angeführt (Zeile 10 und 14 bis 17). In Zeile 11 wird dem Element eine
eindeutige ID zugewiesen, mit der auf das Element von anderen Elementen aus verwiesen
werden könnte.
Anmerkung: Dies ist die vollständige exportierte Datei, bei den folgenden Listings wird der
Übersichtlichkeit wegen nur der Teil zwischen <UML:Namespace.ownedElement> (Zeile 9)
und </UML:Namespace.ownedElement> (Zeile 24) aufgeführt.
Die Klasse „Container_class_for_objects_and_actors“ wird von Ameos jedem XMI-Dokument hinzugefügt.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<?xml version="1.0" encoding= "ISO-8859-1"?>
<XMI xmi.version="1.1" xmlns:UML = 'org.omg.xmi.namespace.UML'>
<XMI.header>
<XMI.metamodel xmi.name="UML" xmi.version="1.4" />
</XMI.header>
<XMI.content>
<UML:Model>
<UML:Namespace.ownedElement>
<UML:Class name = 'Class1' visibility = 'public'
xmi.id = 'UID_887D2DBE-1976-4787-BDCF-FB37367BE6C7'
xmi.uuid = 'UID_887D2DBE-1976-4787-BDCFFB37367BE6C7'
isAbstract = 'false'
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
<UML:Class name = 'Container_class_for_objects_and_actors'
visibility = 'public'
xmi.id = 'ID_DUMMY_CLASS' isRoot = 'true' isLeaf = 'true'
isActive = 'true' />
</UML:Namespace.ownedElement>
</UML:Model>
</XMI.content>
</XMI>
35
2.1.1.2 Rational Rose
Auch beim Export aus Rational Rose werden dem Modell diverse Informationen hinzugefügt.
In den Zeilen 1 bis 11 stehen die Headerinformationen, hier z.B. der verwendete Zeichensatz,
die XMI-Version, das erzeugende Tool mit Versionsangabe und das verwendete Metamodell.
Anschließend folgt eine Beschreibung der Eigenschaften des beschriebenen Modells (Zeile 13
bis 17). Die Darstellung der Klasse findet sich in den Zeilen 18 bis 23, hier werden als Attribute die Eigenschaften der Klasse angeführt (analog zum Export bei Ameos). In Zeile 19 wird
dem Element eine eindeutige ID zugewiesen, mit der auf das Element von anderen Elementen
aus verwiesen werden könnte. Im Gegensatz zu Ameos werden hier keine UUIDs zugewiesen, dies kann beim Export aber eingestellt werden („Generate UUIDs“). Ebenso kann die zu
verwendende XMI-Version (1.0 oder 1.1) gewählt werden; im Rahmen dieses Dokuments
wurde immer Version 1.1 verwendet.
Anmerkung: Dies ist die vollständige exportierte Datei, bei den folgenden Listings wird der
Übersichtlichkeit wegen nur der Teil zwischen <UML:Namespace.ownedElement> (Zeile 17)
und </UML:Namespace.ownedElement> (Zeile 24) aufgeführt.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<?xml version = '1.0' encoding = 'ISO-8859-1'?>

<XMI xmi.version = '1.1' xmlns:UML='href://org.omg/UML/1.3'
timestamp = 'Tue Nov 16 23:40:04 2004' >
<XMI.header>
<XMI.documentation>
<XMI.exporter>Unisys.JCR.1</XMI.exporter>
<XMI.exporterVersion>1.3.6</XMI.exporterVersion>
</XMI.documentation>
<XMI.metamodel xmi.name = 'UML' xmi.version = '1.3'/>
</XMI.header>
<XMI.content>

<UML:Model xmi.id = 'G.0'
name = 'Klasse' visibility = 'public' isSpecification = 'false'
isRoot = 'false' isLeaf = 'false' isAbstract = 'false' >

<UML:Class xmi.id = 'S.320.2339.51.1'
name = 'Class1' visibility = 'public' isSpecification = 'false'
isRoot = 'true' isLeaf = 'true' isAbstract = 'false'
isActive = 'false'
namespace = 'G.0' />
</UML:Model>
<UML:TaggedValue xmi.id = 'XX.16.2339.51.2'
tag = 'persistence' value = 'transient'
modelElement = 'S.320.2339.51.1' />
</XMI.content>
</XMI>
36
2.1.2 Klasse: GXL-Darstellung
Bei der Umsetzung dieser einfachen Klasse in ein GXL-Dokument ist nur die entsprechende
(Knoten-)Klasse als Knoten des entsprechenden Knotentyps darzustellen (Zeile 10 bis 18).
Anmerkung: Jedes Schema besitzt einen Knoten vom Typ GraphClass (hier: Zeile 4 bis 9),
der mit contains-Kanten mit jedem Knoten des Schemas verbunden ist (hier: Zeile 19 bis 21).
Dieser wird in den folgenden Beispielen zur Vereinfachung weggelassen. Ebenso werden in
den folgenden Beispielen die Informationen, die den Graphen bezeichnen und sich nicht direkt auf die enthaltenen Elemente beziehen weggelassen; diese sind hier noch mit abgebildet
(Zeile 1 bis 3, Zeile 22 und 23),
Abbildung 5: Klasse als Graph
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<gxl xmlns:xlink="http://www.w3.org/1999/xlink">
<graph id="class-graph" edgeids="true" hypergraph="false" edgemode="directed">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#gxl-1.0"/>
<node id="class-graph">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#GraphClass"/>
<attr name="name">
<string>class-graph</string>
</attr>
</node>
<node id="Class1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#NodeClass"/>
<attr name="name">
<string>Class1</string>
</attr>
<attr name="isabstract">
<bool>false</bool>
</attr>
</node>
<edge id="edge1" from="class-graph" to="Class1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#contains"/>
</edge>
</graph>
</gxl>
37
2.2 Klasse mit Attribut
Abbildung 6: Einfache Klasse mit einem Attribut
2.2.1 Klasse mit Attribut: XMI-Darstellung
Eine einfache Darstellung gemäß der XMI-Spezifikation folgt im unten stehenden Listing
(Header-Informationen wurden der Einfachheit halber wie auch bei den folgenden Beispielen
weggelassen). Dabei wird zusätzlich zu den schon in Abschnitt 2.1.1 angeführten Beschreibungen für die Klasse ein UML:Classifier.feature-Tag deklariert, dass die Attribute enthält.
Auf den verwendeten Attributstyp wird im type-Attribut verwiesen.
1
2
3
4
5
<UML:Class name="Class1" xmi.id="Class1">
<UML:Attribute xmi.id = “Attr1” name = “Attr1” type=”string”/>
</UML:Class>
38
2.2.1.1 Ameos
Nachfolgend die Darstellung dieser Klasse beim XMI-Export aus Ameos. In den Zeilen 1 bis
8 wird wie unter 2.1.1.1 die Klasse mit ihren Eigenschaften angegeben, die Zeilen 10 bis 25
enthalten die Daten über das Attribut und dessen Multiplizität. Es wird im UML:ClassifierTag ein Tag UML-Attribute deklariert, dass die Informationen über die verwendeten Attribute
enthält. Der Typ des Attributs wird als Datatype (Zeile 28 bis 33) deklariert, auf dessen ID in
der Deklaration des Attributs verwiesen wird (Zeile 15).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
xmi.uuid = 'UID_887D2DBE-1976-4787-BDCF-FB37367BE6C7'
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
<UML:Attribute name = 'Attr1'
xmi.id = 'UID_4037C9D1-3C59-4049-89F0-B0DCBA77D3A7'
visibility ='public'
xmi.uuid = 'UID_4037C9D1-3C59-4049-89F0-B0DCBA77D3A7'
comment = ''
type = 'TP_UID_4037C9D1-3C59-4049-89F0-B0DCBA77D3A7'
ownerScope = 'instance'>
<UML:StructuralFeature.multiplicity>
<UML:Multiplicity>
<UML:MultiplicityRange lower = '1' upper = '1'>
</UML:Multiplicity>
</UML:StructuralFeature.multiplicity>
</UML:Attribute>
</UML:Class>
<UML:DataType
xmi.id = 'TP_UID_4037C9D1-3C59-4049-89F0-B0DCBA77D3A7'
name ='string'
visibility = 'public' isSpecification = 'false'
/>
39
Beim Export dieser Klasse aus Rational Rose wird wie unter 2.1.1.2 die Klasse mit ihren Eigenschaften angegeben (Zeile 1 bis 6), die Zeilen 8 bis 28 enthalten (analog zur Darstellung in
Ameos) die Daten über das Attribut. Auch wird bei Rational Rose der hier verwendete Datentyp „String“ als DataType in der XMI-Datei angeführt (Zeile 30 bis 33). Auf diesen Datentyp
wird von dem Attribut, dass ihn benötigt, verwiesen (Zeile 14).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<UML:Class xmi.id = 'S.322.1814.55.1'
isActive = 'false'
namespace = 'G.0' >

<UML:Attribute xmi.id = 'S.322.1814.55.2'
name = 'Attr1' visibility = 'public' isSpecification = 'false'
ownerScope = 'instance'
changeability = 'changeable' targetScope = 'instance'
type = 'G.1' >
<UML:Multiplicity >
<UML:MultiplicityRange xmi.id = 'id.3231714.1'
lower = '1' upper = '1' />
</UML:Multiplicity>
<UML:Attribute.initialValue>
<UML:Expression language = '' body = '' />
</UML:Attribute.initialValue>
</UML:Attribute>
</UML:Class>

<UML:DataType xmi.id = 'G.1'
name = 'String' visibility = 'public' isSpecification = 'false'
isRoot = 'false' isLeaf = 'false' isAbstract = 'false' />
40
2.2.2 Klasse mit Attribut: GXL-Darstellung
Bei der Umsetzung in GXL werden Attribute durch Knoten vom entsprechenden Knotentyp
umgesetzt, die Klasse selbst wird als Knoten wie in Punkt 2.1.2 beschrieben dargestellt (Zeile
1 bis 9). Das Attribut wird ebenfalls als Knoten vom Type AttributeClass dargestellt (Zeile 10
bis 15) und ist durch eine Kante vom Typ hasAttribute mit der Klasse verbunden (Zeile 19 bis
21). Der Typ des Attributs wird ebenfalls als Knoten dargestellt und mit dem Attributsknoten
verbunden (Zeile 16 bis 18, Zeile 22 bis 24).
Abbildung 7: Klasse mit Attribut als Graph
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<node id="Class1">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="Attr1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#AttributeClass"/>
<attr name="name">
<string>Attr1</string>
</attr>
</node>
<node id="domainString">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#String"/>
</node>
<edge id="e1" from="Class1" to="Attr1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#hasAttribute"/>
</edge>
<edge id="e2" from="Attr1" to="domainString">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#hasDomain"/>
</edge>
41
2.3 Assoziation
Abbildung 8: Assoziation
2.3.1 Assoziation: XMI-Darstellung
Eine einfache Darstellung von Abbildung 8 gemäß der XMI-Spezifikation (ohne Beachtung
der Multiplizitäten) wäre:
<UML:Class name=" Class 2" xmi.id=" Class 2"/>
<UML:Association name ="Association1" >
<UML:AssociationEnd type="Class1"/>
<UML:AssociationEnd type="Class2"/>
</UML:Association>
2.3.1.1 Ameos
Im folgenden Listing folgt das Ergebnis des XMI-Export aus Ameos dieser beiden assoziierten Klassen. Hierbei werden zuerst die beiden Klassen beschrieben (Zeile 1 bis 9 und Zeile 10
bis 18). In den Zeilen 22 bis 70 wird dann die Assoziation dargestellt, die beiden assoziierten
Klassen werden anhand ihrer ID referenziert (Zeile 43 bis 45 bzw. Zeile 64 bis 66).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
xmi.id = 'UID_52019E47-3FC0-43d8-A954-77F243351B70'
xmi.uuid = 'UID_52019E47-3FC0-43d8-A954-77F243351B70'
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
<UML:Class name = 'Container_class_for_objects_and_actors' visibility = 'public'
xmi.id = 'ID_DUMMY_CLASS' isRoot = 'true' isLeaf = 'true' isActive = 'true' />
<UML:Association name = 'Association1'
xmi.uuid = 'UID_92C80B8A-0437-45de-A3CC-78ABD5DC2AAF'
42
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
xmi.id = 'UID_92C80B8A-0437-45de-A3CC-78ABD5DC2AAF'>
<UML:AssociationEnd name = ''
xmi.id = 'UID_47CD32C3-FA80-4ec4-881C-85C68883DB35'
xmi.uuid = 'UID_47CD32C3-FA80-4ec4-881C-85C68883DB35'
comment = ''
isNavigable = 'true' ordering = 'unordered'
aggregation = 'none'>
<UML:Multiplicity>
<UML:MultiplicityRange
lower = '0' upper = '-1'>
</UML:Multiplicity>
<UML:Classifier
xmi.idref =
'UID_52019E47-3FC0-43d8-A954-77F243351B70'/>
xmi.id = 'UID_C5F1D598-24C4-4c90-B6D6-109FFDBC9605'
xmi.uuid = 'UID_C5F1D598-24C4-4c90-B6D6-109FFDBC9605'
comment = ''
<UML:Multiplicity>
</UML:Multiplicity>
<UML:Classifier
xmi.idref =
'UID_887D2DBE-1976-4787-BDCF-FB37367BE6C7'/>
</UML:Association>
43
Beim XMI-Export aus Rational Rose werden die beiden Klassen wie in Abschnitt 2.1.1.2 beschrieben (Zeile 41 bis 54) dargestellt. In den Zeilen 1 bis 40 wird die Assoziation zwischen
diesen beiden Klassen dargestellt, die beiden assoziierten Klassen werden anhand ihrer ID
referenziert (Zeile 13 und Zeile 29).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

<UML:Association xmi.id = 'G.1'
name = 'Association1' visibility = 'public' isSpecification = 'false'

<UML:AssociationEnd xmi.id = 'G.2'
name = '' visibility = 'public' isSpecification = 'false'
isNavigable = 'true' ordering = 'unordered' aggregation = 'none'
targetScope = 'instance' changeability = 'changeable'
type = 'S.321.0019.23.2' >
<UML:Multiplicity >
lower = '0' upper = '-1' />
</UML:Multiplicity>

isNavigable = 'true' ordering = 'unordered' aggregation = 'none'
type = 'S.321.0019.23.1' >
<UML:Multiplicity >
lower = '0' upper = '1' />
</UML:Multiplicity>
</UML:Association>

<UML:Class xmi.id = 'S.321.0019.23.1'
isActive = 'false'

<UML:Class xmi.id = 'S.321.0019.23.2'
44
49
50
51
52
isActive = 'false'
45
2.3.2 Assoziation: GXL-Darstellung
Assoziationen werden bei der Umsetzung in TGraphen zu Knoten vom entsprechenden Typ.
Multiplizitäten werden als Attribute der Kanten, die die entsprechenden Knoten (Klasse und
Assoziation) verbinden, dargestellt.
Class1: NodeClass
-name = "Class1"
-isAbstract = "false"
edge1: from
-limits = (0, -1)
-isOrdered = "false"
Association1: EdgeClass
-name = "Association1"
-isDirected = "false"
edge2: to
-limits = (0,1)
-isOrdered = "false"
Class2: NodeClass
-name = "Class2"
Abbildung 9: Assoziazion als GXL-Graph
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<node id="Association1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#EdgeClass"/>
<attr name="name">
<string>Association1</string>
</attr>
<bool>false</bool>
</attr>
<attr name="isdirected">
<bool>false</bool>
</attr>
</node>
<node id="Class1">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="Class2">
46
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<edge id="edge1" from="Association1" to="Class1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#from"/>
<attr name="limits">
<tup>
<int>0</int>
<int>-1</int>
</tup>
</attr>
<attr name="isordered">
<bool>false</bool>
</attr>
</edge>
<edge id="edge2" from="Association1" to="Class2">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#to"/>
<tup>
<int>0</int>
<int>1</int>
</tup>
</attr>
<bool>false</bool>
</attr>
</edge>
47
2.4 Aggregation
1
Class1
Class2
0..*
Abbildung 10: Aggregation
2.4.1 Aggregation: XMI-Darstellung
Bei der Umsetzung von Abbildung 10 gemäß der XMI-Spezifikation werden zuerst die beiden
Klassen definiert (Zeile 1 und 2). Die Aggregation selbst wird als Assoziation dargestellt
(Zeile 3 bis 16), dabei wird das entsprechende Attribut aggregation entsprechend dem Ende
der Assoziation gesetzt (Zeile 5 und 10). Zur Vereinfachung wurden hier die Multiplizitäten
ignoriert.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<UML:Class name=" Class 2" xmi.id="Class 2"/>
<UML:Association>
<UML:AssociationEnd xmi.id=”assocEnd1” aggregation = 'aggregate'>
<UML:AssociationEnd xmi.id=”assocEnd2”aggregation = 'none'/>
</UML:Association>
48
2.4.1.1 Ameos
Beim XMI-Export aus Ameos werden zuerst wieder die beiden Klassen abgebildet (Zeile 1
bis 17), die Aggregation wird als Assoziation dargestellt (ab Zeile 22), deren Attribut aggregation entsprechend gesetzt wird (Zeile 32 und 52).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
<UML:Association name = ''
' xmi.uuid = 'UID_92C80B8A-0437-45de-A3CC-78ABD5DC2AAF'
comment = ''
aggregation = 'aggregate'>
<UML:Multiplicity>
</UML:Multiplicity>
<UML:Classifier
xmi.idref = 'UID_52019E47-3FC0-43d8-A954-77F243351B70'/>
xmi.uuid = 'UID_C5F1D598-24C4-4c90-B6D6-109FFDBC9605'
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
comment = ''
<UML:Multiplicity>
<UML:MultiplicityRange lower = '0'
upper = '-1'>
</UML:Multiplicity>
<UML:Classifier
xmi.idref = 'UID_887D2DBE-1976-4787-BDCF-FB37367BE6C7'/>
</UML:Association>
50
Beim Export aus Rational Rose werden die beiden Klassen wie in den vorangehenden Beispielen dargestellt (Zeile 41 bis 54). Die Aggregation wird als Assoziation dargestellt, das
Attribut aggregation wird entsprechend gesetzt (Zeile 11 und 27).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


isNavigable = 'false' ordering = 'unordered' aggregation = 'aggregate'
type = 'S.322.2005.01.2' >
<UML:Multiplicity >
lower = '1' upper = '1' />
</UML:Multiplicity>

<UML:Class xmi.id = 'S.322.2005.01.1'
isActive = 'false'

<UML:Class xmi.id = 'S.322.2005.01.2'
51
50
51
52
isActive = 'false'
52
2.4.2 Aggregation: GXL-Darstellung
Bei der Umsetzung in GXL wird die Aggregation als Knoten vom Typ „AggregationClass“
dargestellt (Zeile 19 bis 33) und mit Kanten (Zeile 34 bis 57) mit den beteiligten Klassen
(Zeile 1 bis 18) verbunden). Diese Kanten enthalten als Attribut die Multiplizität.
Abbildung 11: Aggregation als GXL-Graph
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<node id="Class2">
<type xlink:href="#NodeClass"/>
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="Class1">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
53
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
<node id="Aggr1">
<type xlink:href="#AggregationClass"/>
<attr name="name">
<string></string>
</attr>
<bool>false</bool>
</attr>
<bool>false</bool>
</attr>
<attr name="aggregate">
<enum>to</enum>
</attr>
</node>
<edge id="edge1" from="Aggr1" to="Class1">
<type xlink:href="#to"/>
<tup>
<int>0</int>
<int>-1</int>
</tup>
</attr>
<bool>false</bool>
</attr>
</edge>
<edge id="edge2" from="Aggr1" to="Class2">
<type xlink:href="#from"/>
<tup>
<int>1</int>
<int>1</int>
</tup>
</attr>
<bool>false</bool>
</attr>
</edge>
54
2.5 Komposition
Abbildung 12: Komposition
2.5.1 Komposition: XMI-Darstellung
Eine einfache Darstellung von Abbildung 12 gemäß der XMI-Spezifikation (analog zur Darstellung der Aggregation in Abschnitt 2.5.1) wäre:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<UML:Class name=" Class 2" xmi.id="Class 2"/>
</UML:Association>
<UML:AssociationEnd xmi.id=”assocEnd1” aggregation = “composite”>
<UML:Classifier xmi.idref = “Class2”/>
<UML:AssociationEnd xmi.id=”assocEnd2”aggregation = “none”/>
<UML:Classifier xmi.idref = “Class1”/>
</UML:Association>
55
2.5.1.1 Ameos
Beim XMI-Export aus Ameos wird die Komposition als Assoziation vom Typ „composite“
dagestellt (Zeile 22 bis 70). Das Attribut aggregate wird hier auf „composite“ gesetzt. Der
Rest ergibt sich aus den Erläuterungen zur Aggregation (Abschnitt 2.4.1.1).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
<UML:Association name = ''
' xmi.uuid = 'UID_92C80B8A-0437-45de-A3CC-78ABD5DC2AAF'
comment = ''
aggregation = 'composite'>
<UML:Multiplicity>
upper = '1'>
</UML:Multiplicity>
<UML:Classifier xmi.idref =
'UID_52019E47-3FC0-43d8-A954-77F243351B70'/>
xmi.uuid =
56
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
'UID_C5F1D598-24C4-4c90-B6D6-109FFDBC9605'
comment = ''
<UML:Multiplicity>
upper = '-1'>
</UML:Multiplicity>
<UML:Classifier xmi.idref =
'UID_887D2DBE-1976-4787-BDCF-FB37367BE6C7'/>
</UML:Association>
57
Beim XMI-Export aus Rational Rose wird die Komposition (zu modellieren als Aggregation
und Angabe von „Containment of Class2“ als „by value“) wie bei Ameos als Assoziation von
Type „composite“ dargestellt (Zeile 11 und 27). Das Attribut aggregate wird hier auf „composite“ gesetzt. Der Rest ergibt sich aus den Erläuterungen zur Aggregation (Abschnitt
2.4.1.2).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


<UML:Class xmi.id = 'S.105.1947.00.1'
isActive = 'false'

58
48
49
50
51
52
<UML:Class xmi.id = 'S.105.1947.00.2'
isActive = 'false'
59
2.5.2 Komposition: GXL-Darstellung
Bei der Umsetzung in GXL wird die Komposition (analog zur Aggregation) als Knoten vom
Typ „CompositionClass“ dargestellt (Zeile 19 bis 33) und mit Kanten (Zeile 34 bis 57) mit
den beteiligten Klassen (Zeile 1 bis 18) verbunden).
Abbildung 13: Komposition als GXL-Graph
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<node id="Class2">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="Class1">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
60
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
</node>
<node id="Composition1">
<type xlink:href="#CompositionClass"/>
<attr name="name">
<string></string>
</attr>
<bool>false</bool>
</attr>
<bool>true</bool>
</attr>
<enum>to</enum>
</attr>
</node>
<edge id="edge1" from="Composition1" to="Class2">
<type xlink:href="#from"/>
<tup>
<int>1</int>
<int>1</int>
</tup>
</attr>
<bool>false</bool>
</attr>
</edge>
<edge id="edge2" from="Composition1" to="Class1">
<type xlink:href="#to"/>
<tup>
<int>0</int>
<int>-1</int>
</tup>
</attr>
<bool>false</bool>
</attr>
</edge>
61
2.6 Generalisierung
Abbildung 14: Generalisierung
2.6.1 Generalisierung: XMI-Darstellung
Eine einfache Darstellung von Abbildung 14 gemäß der XMI-Spezifikation wäre:
<UML:Class name="Class1" xmi.id="Class1" generalization="Class2"/>
<UML:Class name=" Class 2" xmi.id=" Class 2" isAbstract=”true”/>
2.6.1.1 Ameos
Beim XMI-Export aus Ameos werden die Knoten wie bei den vorigen Beispielen beschrieben
dargestellt (hier Zeile 4 bis 31); bei der Darstellung der Generalisierung (Zeile 1 bis 13) wird
mittels der ID wieder auf die entsprechenden Elemente verwiesen, dabei wird zwischen
Child- und Parent-Element unterschieden.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<UML:Generalization xmi.id = 'UID_0CEC8AC7-6F76-4f17-802B-093BBD13CAE5'
xmi.uuid = 'UID_0CEC8AC7-6F76-4f17-802B-093BBD13CAE5'
name = ''
>
<UML:Generalization.child>
<UML:GeneralizableElement
xmi.idref = 'UID_887D2DBE-1976-4787-BDCF-FB37367BE6C7'/>
</UML:Generalization.child>
<UML:Generalization.parent>
<UML:GeneralizableElement
xmi.idref = 'UID_52019E47-3FC0-43d8-A954-77F243351B70'/>
</UML:Generalization.parent>
</UML:Generalization>
isAbstract = 'true'
isRoot = 'true'
isLeaf = 'false'
isActive = 'false'
>
</UML:Class>
isRoot = 'false'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
62
Rational Rose exportiert die zwei Klassen wie in den vorangegangenen Beispielen. Dabei
wird zusätzlich als Attribut von „Class1“ ein Verweis auf die Generalisierung (Zeile 8) eingefügt, die innerhalb der Klasse deklariert wird (Zeile 9 bis 14). Dabei verweisen die Attribute
child und parent auf die beteiligten Elemente (Zeile 13). In „Class2“ wird das Attribut specialization als ein Verweis auf die Generalisierung deklariert (Zeile 23). Hier zeigt sich ein erster
deutlicher Unterschied im Export zu Ameos.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<UML:Class xmi.id = 'S.322.1909.23.1'
isRoot = 'false' isLeaf = 'true' isAbstract = 'false'
isActive = 'false'
namespace = 'G.0'
generalization = 'G.1' >
<UML:Generalization xmi.id = 'G.1'
discriminator = ''
child = 'S.322.1909.23.1' parent = 'S.322.1909.23.2' />
</UML:Class>

<UML:Class xmi.id = 'S.322.1909.23.2'
isRoot = 'true' isLeaf = 'false' isAbstract = 'true'
isActive = 'false'
namespace = 'G.0'
specialization = 'G.1' />
63
2.6.2 Generalisierung: GXL-Darstellung
Bei der Umsetzung der Generalisierung in GXL-Graphen werden die beiden Klassen als Knoten dargestellt, die mit einer Kante vom Typ „isA“ verbunden sind.
Class1: NodeClass
edge1: isA
-name = "Class1"
Class2: NodeClass
-name = "Class2"
-isAbstract = "true"
Abbildung 15: Generalisierung als GXL-Graph
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<node id="Class1">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="Class2">
<attr name="name">
</attr>
<bool>true</bool>
</attr>
</node>
<edge id="edge1" from="Class1" to="Class2">
<type xlink:href="#isA"/>
</edge>
64
2.7 Package
Package1
Class1
Class2
Abbildung 16: Package mit zwei Klassen
2.7.1 Package: XMI-Darstellung
2.7.1.1 Ameos
Packages werden unter XMI als UML:Package-Elemente beschrieben; diese enthalten die im
Package enthaltenen Elemente (hier also die beiden Klassen).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<UML:Package xmi.id = 'UID_A1CF8ABF-7781-444b-B101-390C3C001ADF'
xmi.uuid = 'UID_A1CF8ABF-7781-444b-B101-390C3C001ADF'
name = 'Package1'
isRoot = 'true'
isLeaf = 'true'>
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
</UML:Package>
65
Auch in Rational Rose werden Packages als UML:Package-Elemente beschrieben, in denen
dann die enthaltenen Elemente deklariert werden.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<UML:Class xmi.id = 'S.322.2038.46.2'
isActive = 'false'
namespace = 'S.322.2038.46.1' />

<UML:Class xmi.id = 'S.322.2038.46.3'
isActive = 'false'
namespace = 'S.322.2038.46.1' />
</UML:Package>
66
2.7.2 Package: GXL-Darstellung
Bei der Umsetzung in GXL werden in einem Package enthaltene Klassen über eine hasAsComponentGraph-Kante (Zeile 34 bis 48) mit einem Knoten vom Typ GraphClass (Zeile 28
bis 33) verbunden, dieser ist über contains-Kanten (Zeile 49 bis 54) mit denen im Package
enthaltenen Knoten verbunden. Packages werden in GXL also hier als hierarchische Graphen
umgesetzt.
Package1: NodeClass
edge1: hasAsComponentGraph
-name = "Package1"
-abstract = "false"
innerGraph: GraphClass
-name = "packageGraph"
edge2: contains
edge3: contains
Class1: NodeClass
Class2: NodeClass
-name = "Class1"
-abstract = "false"
-name = "Class2"
-abstract = "false"
Abbildung 17: Package als GXL-Darstellung
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<node id="Package1">
<attr name="name">
<string>Package1</string>
</attr>
<bool>false</bool>
</attr>
</node>
<node id="Class1">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="Class2">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="innerGraph">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#GraphClass"/>
<attr name="name">
<string>innerGraph</string>
</attr>
67
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
</node>
<edge id="edge1" from="Package1" to="innerGraph">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#hasAsComponentGraph"/>
<tup>
<int>1</int>
<int>1</int>
</tup>
</attr>
<bool>false</bool>
</attr>
<attr name="role">
<string></string>
</attr>
</edge>
<edge id="edge2" from="innerGraph" to="Class1">
</edge>
<edge id="edge3" from="innerGraph" to="Class2">
</edge>
68
2.8 Assoziations-Klasse
Abbildung 18: Assoziations-Klasse
2.8.1 Assoziations-Klasse: XMI-Darstellung
2.8.1.2 Ameos
Assoziations-Klassen können nach meinem Wissen nicht mit Ameos (Version 9.1.5) modelliert werden.
Beim Export aus Rational Rose werden die beiden Klassen wie in den vorangehenden Beispielen dargestellt (Zeile 1 bis 14). In den Zeilen 15 bis 55 wird die Assoziations-Klasse beschrieben, die beiden verbundenen Klassen werden in den Zeilen 22 bis 55 angegeben. Enthält die Assoziations-Klasse Attribute, werden diese wie in UML:Class-Elementen (siehe Abschnitt 2.2.1.2) innerhalb des UML:AssociationClass-Elements als UML:Classifier.featureElemente eingebunden (Zeile 56 bis 76).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<UML:Class xmi.id = 'S.109.0133.08.1'
isActive = 'false'

<UML:Class xmi.id = 'S.109.0133.08.2'
isActive = 'false'

<UML:AssociationClass xmi.id = 'S.109.0133.08.3'
name = 'AssociationClass1' visibility = 'public' isSpecification = 'false'
isRoot = 'true' isLeaf = 'true' isAbstract = 'true'
isActive = 'false'
namespace = 'G.0' >

<UML:Attribute xmi.id = 'S.109.0133.08.4'
name = 'AssocAttribute1' visibility = 'private' isSpecification = 'false'
ownerScope = 'instance'
changeability = 'changeable' targetScope = 'instance'
type = 'G.4' >
<UML:Multiplicity >
lower = '1' upper = '1' />
</UML:Multiplicity>
<UML:Attribute.initialValue>
<UML:Expression language = '' body = '' />
</UML:Attribute.initialValue>
</UML:Attribute>
</UML:AssociationClass>
70
2.8.2 Assoziations-Klasse: GXL-Darstellung
Bei der Umsetzung in TGraphen werden Assoziations-Klassen als Knoten vom Typ AssociationClass dargestellt (oder entsprechend als AggreationClass bzw. CompositionClass). Attribute werden wie unter 2.2 beschrieben umgesetzt.
Abbildung 19: Assoziations-Klasse als GXL-Darstellung (ohne hasDomain-Kante und Knoten für Attributstyp)
<node id="Class1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#NodeClass" />
<attr name="name">
</attr>
<attr name="isAbstract">
<bool>false</bool>
</attr>
</node>
<node id="Class2">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="AssociationClass1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#EdgeClass" />
<attr name="name">
<string>AssociationClass1</string>
71
</attr>
<bool>false</bool>
</attr>
<bool>true</bool>
</attr>
<enum>from</enum>
</attr>
</node>
<edge id="edge1" from=" AssociationClass1" to="Class2">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#from" />
<tup>
<int>0</int>
<int>-1</int>
</tup>
</attr>
<bool>false</bool>
</attr>
</edge>
<edge id="edge2" from=" AssociationClass1" to="Class1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#to" />
<tup>
<int>0</int>
<int>-1</int>
</tup>
</attr>
<bool>false</bool>
</attr>
</edge>
<node id="AssocAttribute1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#AttributeClass"/>
<attr name="name">
<string>AssocAttribute1</string>
</attr>
</node>
<node id="domainString">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#String"/>
</node>
<edge id="e1" from="Class1" to="Attr1">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#hasAttribute"/>
</edge>
<edge id="e2" from="Attr1" to="domainString">
<type xlink:href="http://www.gupro.de/GXL/gxl-1.0.gxl#hasDomain"/>
</edge>
72
V. JAXP/XSLT
1. Einleitung
In diesem Abschnitt sollen kurz die zur Auswahl stehenden Möglichkeiten der Realisierung
des XMI↔GXL-Konverters vorgestellt werden. Dabei werden das Java API for XML Parsing
(JAXP) sowie XSLT betrachtet. Es wird eine Auswahl getroffen, welche Programmiersprache
zur Umsetzung der Konvertierung von (den von Ameos und Rational Rose) erstellten XMIDokumenten in GXL-Dokumente und zurück am effektivsten benutzt werden kann; damit
werden dann die in vorangegangenden Dokumenten beschriebenden Umsetzungen realisiert.
2. JAXP
Der W3C-Standard, um XML-Daten zu verarbeiten, ist das DOM (Document Object Model).
Der Datenzugriff erfolgt hier über einen Objektbaum. Mit DOM können XML-Dokumente
gelesen und erzeugt werden. Das API, um über Java auf XML zugreifen zu können, heißt
JAXP (Java API for XML Parsing) und umfasst neben DOM auch SAX (Simple API for
XML) und XSLT. Im Gegensatz zu DOM wird bei SAX das Dokument sequentiell durchlaufen, außerdem können XML-Dokumente nur gelesen, aber nicht erzeugt werden. JAXP ist ab
J2SE 1.4 enthalten. Die folgenden Beispiele wurden aus den Beispielen unter [JAXP04] abgeleitet.
2.1 Benötigte Klassen
Die folgenden Klassen sind einzubinden, um das DOM-API zu benutzen:
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.FactoryConfigurationError;
import javax.xml.parsers.ParserConfigurationException;
Um Exceptions beim Parsen des XML-Dokuments abfangen zu können, werden folgende
Klassen benötigt:
import org.xml.sax.SAXException;
import org.xml.sax.SAXParseException;
Um das XML-Dokument einzulesen und Fehlermeldungen abzufangen, müssen die folgenden
Klassen eingebunden werden:
import java.io.File;
import java.io.IOException;
Außerdem sind noch die W3C Definitionen für DOM und DOM-Exceptions zu importieren:
import org.w3c.dom.Document;
import org.w3c.dom.DOMException;
Zur Vereinfachung (und um zusätzlich benötigte Klassen, z.B. zum Zugriff auf einzelne Elemente, hinzuzufügen), kann man auch einfach alle evtl. benötigten Klassen importieren:
73
import java.io.*;
import org.xml.sax.*;
import org.w3c.dom.*;
import javax.xml.parsers.*;
Das Zusammenspiel der einzelnen Elemente ist in Abbildung 20 dargestellt. Die vorhandenen
XML-Daten werden über den DocumentBuilder (der auf Funktionen der DocumentBuilder
Factory zugreift) eingelesen, der daraus eine baumartige Struktur der darin enthaltenen Informationen aufbaut (Document).
Abbildung 20: JAXP-API (von [JAXP04])3
2.2 Einlesen der Daten in ein DOM-Objekt
Ein DOM wird folgendermaßen deklariert (hier als static, da das Dokument in diesem Beispiel innerhalb von main() verwendet wird):
static Document document;
Anschließend muss eine DocumentBuilderFactory deklariert werden und eine Instanz erzeugt
werden, um die angegebene Datei einzulesen (zu parsen). Die Fehlerbehandlung wird hier
noch nicht implementiert, die zu lesende Datei wird als erstes Argument beim Programmaufruf übergeben.
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
try {
DocumentBuilder builder = factory.newDocumentBuilder();
document = builder.parse( new File(argv[0]) );
} catch (SAXParseException spe) { }
Um ein neues (leeres) DOM zu erzeugen (anstatt eine vorhandenes XML-Datei einzulesen),
müsste die Zeile, in der eine Datei eingelesen wird, durch folgende ersetzt werden:
3
http://java.sun.com/xml/jaxp/dist/1.1/docs/tutorial/overview/images/dom-api.gif
74
document = builder.newDocument();
Die hier erzeugten Objekte werden in Abbildung 21 nochmals dargestellt, ebenso die in den
beiden folgenden Abschnitten beim Zugriff auf Elemente und zum Erzeugen neuer Elemente
erzeugten Objekte.
2.3 Zugriff auf Elemente
Um beispielsweise eine Liste aller Tags, die den Namen „UML:Association“ haben, zu erzeugen (und festzustellen, wie viele dieser Elemente vorhanden sind), sind folgende Befehle
zu verwenden:
NodeList listOfAssociations =document.getElementsByTagName("UML:Association");
int numberOfAssociations = listOfAssociations.getLength();
Ein Zugriff auf einzelne Elemente (hier das erste Element) erfolgt folgendermaßen:
if (numberOfAssociations > 0 ){
Node firstAssociationNode = listOfAssociations.item( 0 );
if( firstAssociationNode.getNodeType() == Node.ELEMENT_NODE ){
Element firstAssociationElement = (Element)firstAssociationNode;
}
}
Um jetzt das erste UML:AssociationEnd-Tag aus diesem Element (firstAssociationElement)
herauszufinden, können folgende Befehle verwendet werden:
NodeList firstAssocEndList =
firstAssociationElement.getElementsByTagName( "UML:AssociationEnd" );
Element firstAssocEndElement = firstAssocEndList.item( 0 );
Ein Element-Objekt repräsentiert ein Element (oder Tag) eines XML-Dokuments. Auf alle
Objekte eines DOM-Dokument-Baums kann mit dem Node-Interface (beschrieben in
org.w3c.dom.Node) zugegriffen werden. Eine Darstellung dieses Interfaces findet sich in Abbildung 22.
2.4 Erzeugen neuer Elemente
Im folgenden ein kleines Beispiellisting, dass das Erzeugen von Elementen für eine leeres
DOM aufzeigt.
public static void buildDom()
{
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
try {
DocumentBuilder builder = factory.newDocumentBuilder();
document = builder.newDocument();
Element root = (Element) document.createElement("rootElement");
document.appendChild(root);
root.appendChild(document.createTextNode("Some") );
root.appendChild(document.createTextNode(" ") );
root.appendChild(document.createTextNode("text") );
} catch (ParserConfigurationException pce) {
// Parser with specified options can't be built
75
pce.printStackTrace();
}
Attribute werden durch die setAttribute-Operation hinzugefügt (enthalten im ElementInterface, siehe Abbildung 22). Um einen Knoten zu entfernen, kann die removeChildMethode des Eltern-Knotens aufgerufen werden. Um einen Knoten zu verändern, kann entweder die replaceChild-Operation des Eltern-Knotens aufgerufen werden oder die setNodeValue-Operation des Knotens aufgerufen werden.
Abbildung 21: Beispielaufbau des in Abschnitt 2.2 bis 2.4 entwickelten DOM
2.5 Speichern eines DOM als XML-Datei
Ein DOM kann mit Hilfe des XSLT-Transform-Packages wiederum als XML-Datei gespeichert werden. Dazu müssen zuerst folgende Klassen importiert werden:
76
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.TransformerException;
import javax.xml.transform.TransformerConfigurationException;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
Um ein DOM-Dokument im XML-Format auszugeben, sind folgende (leere) „Transformationen“ nötig:
TransformerFactory tFactory = TransformerFactory.newInstance();
Transformer transformer = tFactory.newTransformer();
DOMSource source = new DOMSource(document);
StreamResult result = new StreamResult(System.out);
transformer.transform(source, result);
Außerdem müssen noch möglicherweise auftretende Exceptions abgefangen werden:
catch (TransformerConfigurationException tce) {
}
catch (TransformerException te) {
}
«interface»
Node
+getNodeName() : string(idl)
+getNodeValue() : string(idl)
+setNodeValue()
+getNodeType() : short(idl)
+getParentNode() : Node
+getChildNodes() : NodeList
+getFirstChild() : Node
+appendChild() : Node
«interface»
Attr
+getName() : string(idl)
+getValue() : string(idl)
+setValue()
*
«interface»
NodeList
+getLength() : long(idl)
+item() : Node
*
«interface»
Document
+createAttribute() : Attr
+createComment()
+createElement() : Element
+getElementsByTagName() : NodeList
+createTextNode()
«interface»
Element
+getAttribute() : string(idl)
+getAttributeNode() : Attr
+getElementsByTagName() : NodeList
+hasAttribute() : boolean(idl)
+removeAttribute()
+setAttribute()
«interface»
DOMImplementation
+createDocument() : Document
Abbildung 22: Ausschnitt Package org.w3c.dom
3. XSLT
Mit XSLT können XML-Quelltexte nach Belieben verändert werden. XSLT-Templates müssen mit einem xsl:stylesheet-Element beginnen:
<xsl:stylesheet version = '1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
</xsl:stylesheet>
77
Der XSLT-Prozessor durchläuft eine XML-Datei und sucht nach Übereinstimmungs-Regeln.
Werden Übereinstimmungen gefunden, werden die Anweisungen innerhalb der Übereinstimmungs-Regeln ausgeführt.
3.1 Einfaches Beispiel
Als Beispiel soll die folgende XML-Datei in eine HTML-kompatible Ausgabe umgewandelt
werden (Beispiel aus [XSLT04]).
<source>
<bold>Hello, world.</bold>
<red>I am </red>
<italic>fine.</italic>
</source>
Das folgende XSLT-Stylesheet sucht nach übereinstimmenden Tags und wandelt sie entsprechend um. Die xsl:template match="MatchText"- Tags beinhalten die zu suchenden Übereinstimmungen, danach folgen die Daten, mit denen die entsprechenden Tags ersetzt werden
sollen, das xsl:value-of select="."-Tag fügt den Inhalt des Tags zwischen den ursprünglichen
Tags ein, ohne ihn weiter zu bearbeiten. Alternativ existiert das xsl:apply-templates-Tag, mit
dem alle Elemente, für die eine Vorlage existieren, weiterverarbeitet werden.
<xsl:stylesheet version = '1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
<xsl:template match="bold">


<xsl:value-of select="."/>


</xsl:template>
<xsl:template match="red">


</xsl:template>
<xsl:template match="italic">




</xsl:template>
</xsl:stylesheet>
Das Ergebnis ist dann folgende Datei, bei der die bold, italic und red-Tags durch entsprechende HTML-Anweisungen gemäß des Stylesheets ersetzt wurden:

Hello, world.

I am 

78
fine.

Da in diesem Beispiel keine verschachtelten Tags benutzt werden, ist ein xsl:apply-templatesTag nicht erforderlich.
3.2 Pfadangaben
Alle Elemente eines XML-Dokuments können adressiert werden. Die Syntax hierzu wird in
der XPATH-Spezifikation erläutert. In einfachen Fällen (die für den vorgesehenen Anwendungsfall ausreichen) sehen die Pfadangaben für das folgender Dokument beispielsweise so
aus: /test/aaa/bbb/ccc (dies bezeichnet das „innerste“ Element dieses Dokuments). / bezeichnet das Wurzelelement.
<test>
<aaa>
<bbb name=“Name“>
<ccc>Hallo.</ccc>
</bbb>
</aaa>
</test>
Die Angabe von „//“ in Pfadangaben bedeutet, das alle Knoten, welche den ersten Teil des
Pfades (vor „//“) enthalten, und die das nach „//“ bezeichnete Element enthalten, selektiert
werden. Beispiele: /test//ccc selektiert alle Knoten, die im Pfad /test nach einer beliebigen
Tiefe ein Element ccc enthalten; //bbb findet alle Elemente bbb an beliebiger Stelle im Dokument.
3.3 Attribute
Attribute können ähnlich wie Elemente in Pfadangaben referenziert werden (da Attribute wie
Elemente auch als Knoten abgelegt werden), als Kennzeichnung wird im Stylesheet ein „@“
für Attribute benutzt (Beispielpfad: /test/aaa/bbb/@name referenziert das Attribut name im
Pfad /test/aaa/bbb (falls vorhanden). Das xsl:text-Tag wird benutzt, um beliebigen Text auszugeben.
<xsl:template match="/test/aaa/bbb">
<xsl:text>Test: </xsl:text>
<xsl:value-of select="@name"/>
</xsl:template>
Die Ausgabe wäre:
Test: Name
3.4 Einfaches Beispiel zur Umwandlung
Das Beispiel in Anhang B sucht nach allen Klassen innerhalb einer XMI-Datei und erstellt ein
GXL-Dokument, dass die entsprechenden Klassen als Knoten vom Typ „nodeclass“ enthält.
Dabei werden die Attribut-Werte für den Namen und das isAbstract-Attribut übernommen.
In Anhang C ist ein einfaches Beispiel eines „übersetzten“ XMI-Dokuments, das zwei Klassen enthält und mit Ameos erzeugt wurde, dargestellt.
79
3.5 Zusätzliche Anmerkungen
- Elemente können auch in Abhängigkeit von der Anwesenheit eines Attributs ausgewählt
werden (Bsp: <xsl:template match="UML:Class[not(@xmi.uuid)]"> selektiert nur Elemente
ohne xmi.uuid-Attribut).
- Mit der xsl:for each-Anweisung können Templates für jeden Knoten, der über das selectAttribut ausgewählt wird, angegeben werden (Beispiel: <xsl:for each select=
"//UML:Class">).
- Mit xsl:if-Abfragen können boolsche Ausdrücke getestet werden.
- xsl:when-Anweisungen können innerhalb eines xsl:choose-Tags benutzt werden, um beispielsweise bestimmte Attribute auf Werte zu testen. xsl:otherwise wird ausgeführt, falls
keine der innerhalb eines xsl:choose-Tags definierten xsl:when-Anweisungen ausgeführt
werden konnte.
- Mit der xsl:attribute-Anweisung können Attribut-Elemente erzeugt werden (siehe Anhang
B).
Weiterhin gibt es u.a. die Anweisungen xsl:copy (Knoten kopieren), xsl:variable (Setzen von
Variablen) sowie Funktionen zur Konvertierung zwischen Datentypen (number, string, boolean, not, true, false, concat, ceiling, flor, round, sum etc.).
XSLT kann auch innerhalb eines Java-Programms verwendet werden4.
4. Fazit
Ich habe mich dazu entschieden, die GXL2XMI- bzw. XMI2GXL-Programme in XSLT zu
realisieren. Die Richtung von XMI in GXL ist relativ einfach in XSLT umzusetzen. Es muss
hierzu (über verschiedene <xsl:apply-template>-Tags) das XMI-Dokument durchlaufen werden und die verwendeten UML-Konzepte durch die nötigen GXL-Elemente ersetzt werden.
Um GXL in XMI umzusetzen, waren komplexere Operationen als ein einfaches Durchlaufen
des Dokuments und einfaches Textersetzen notwendig (beispielsweise musste bei nodeElementen geprüft werden, ob ein Knoten mit einer „hasAttribute“-Kante verbunden ist; die
Daten dieses Knotens mussten dann in das entsprechende XMI-Klassenelement übernommen
werden). Dies musste dann durch entsprechende komplexere Abfragen der anderen Elemente
des Dokuments innerhalb der jeweiligen xsl:template match-Abfragen erfolgen.
In Java wäre das alles zwar auch möglich gewesen, allerdings denke ich, die Programmierung
mit XSLT war aufgrund der wenigen Befehle und der speziellen Ausrichtung dieser Sprache
auf die Transformation von XML-Dokumenten in diesem speziellen Fall besser geeignet und
die Umsetzung in ein Programm war dadurch schneller zu realisieren (auch, da ich mich in
Java und JAXP auch erst wieder hätte einarbeiten müssen; XSLT war in diesem speziellen
Fall einfacher und schneller für diese Aufgabe zu erlernen).
4
siehe http://java.sun.com/xml/jaxp/dist/1.1/docs/tutorial/xslt/4_transform.html
80
VI. Teststrategie XMI2GXL und GXL2XMI
1. Einleitung
In diesem Abschnitt wird die Strategie zum Testen der korrekten Funktionalität der
XMI2GXL- und GXL2XMI-Stylesheets vorgestellt. Dabei sollen alle an Abschnitt IV vorhandenen Fälle berücksichtigt werden. Es wird für die dort aufgezeigten Fälle (d.h. alle mit
Ameos und Rational Rose modellierbaren UML-Konzepte) untersucht, ob das Stylesheet das
(ebenfalls in diesem Dokument beschriebene) erwartete GXL-Dokument generiert5. In Abbildung 23 sind die vier verschiedenen erstellten Stylesheets dargestellt.
GX
L2X
MI-
X
Am
e
os.
R
L-R
GX
MI2
xsl
.xsl
Abbildung 23: erstellte Stylesheets
2. Test XMI2GXL
2.1 Ameos
Für die in Kapitel IV.2.1 bis IV.2.7 vorgestellten UML-Konzepte (und ihre Umsetzung in
GXL) wurden die entsprechenden Diagramme modelliert, als XMI-Datei exportiert und mittels des XMI2GXL-Stylesheets für Ameos zu GXL-Dokumenten umgewandelt. Außerdem
wurde (da Assoziations-Klassen mit Ameos nicht modellierbar sind) die korrekte Umsetzung
des implementierten Workaround (falls Assoziation und Klasse den gleichen Namen haben,
wird dies als Assoziations-Klasse interpretiert) getestet. Hierbei wurde die korrekte Funktionsweise der Stylesheets erfolgreich verifiziert.
2.2 Rational Rose
Alle an Ameos durchgeführten Tests wurden auch mit von Rational Rose exportierten XMIDokumenten durchgeführt (insbesondere zu beachten ist hierbei die Generalisierung, da hier
größere Unterschiede zu Ameos im erzeugten XMI-Dokument bestehen, siehe Kapitel
IV.2.4.1.2). Zusätzlich wurde die in Kapitel IV.2.8 beschriebene Assoziations-Klasse model5
Eine ausführlichere Dokumentation der durchgeführten Tests findet sich unter
http://thebel.gmxhome.de/Studienarbeit-Testszenario-XMI2GXL.pdf und
http://thebel.gmxhome.de/Studienarbeit-Testszenario-GXL2XMI.pdf.
81
liert. Hierbei wurde ebenfalls die korrekte Funktion des Stylesheets für diese Dokumente
festgestellt.
2.3 Testdokument
In Abbildung 24 ist ein größeres Klassendiagramm dargestellt, dass mit Ameos erstellt wurde,
anschließend in XMI exportiert wurde und mit dem Stylesheet transformiert wurde. Die Ausgabe des Stylesheets war auch für diesen komplexeren Fall korrekt. Eine Umwandlung des
aus diesem Modell erzeugten XMI-Dokuments in GXL ergibt ein Dokument, das in Abbildung 25 (vereinfacht) als Graph dargestellt ist.
Class3_Generalization
Class1
Generalisierung1
+Attr1 : string
-Attr2 : Int = 1
0..1
Association1
0..*
0..*
Class2
Class4_Composition
Komposition1
1
-AttrClass2: Boolean
0..1
Aggregation1
Abbildung 24: Testdokument 1 (Ameos)
82
0..*
Class5_Aggregation
Abbildung 25: Testdokument 1, erzeugter GXL-Graph
83
3. Test GXL2XMI
3.1 Ameos
Eine Umwandlung der GXL-Dokumente aus Kapitel IV.2 durch Anwenden des GXL2XMIStylesheets für Ameos ergibt Dokumente, die denen in diesem Kapitel beschriebenen XMIDokumenten entsprechen und in Ameos importiert werden können.
Das Stylesheet erzeugt für diese Fälle also eine korrekte Ausgabe.
3.2 Rational Rose
Auch ein Umwandeln der GXL-Dokumente aus Kapitel IV.2 durch Anwenden des
GXL2XMI-Stylesheets für Rational Rose ergibt Dokumente, die in Rational Rose importiert
werden können und den erwarteten UML-Konzepten entsprechen.
Anmerkung: DataType-Eintragungen werden automatisch von dem Stylesheet generiert, damit in Rational Rose die „Grundtypen“ angezeigt werden.
3.3 Testdokument
Als weiteres Testdokument wurde das GXL-Metaschema (d.h. die gxl10.gxl-Datei6) gewählt,
da dieses fast alle enthaltenen Konzepte enthält (außer Packages). Eine Umwandlung dieser
Datei mittels des GXL2XMI-Stylesheets (für Rational Rose) und anschließender Import dieser Datei zeigte, dass die verwendeten Konzepte korrekt umgesetzt wurden.
6
http://www.gupro.de/GXL/MetaSchema/metaSchema.html
84
VII. Anwendung der erstellten Programme
In diesem Abschnitt wird zuerst das Erzeugen von XMI-Dokumenten aus den unterstützten
Werkzeugen Ameos und Rational Rose und die Anwendung der XMI2GXL- und GXL2XMIStylesheets erklärt. Außerdem wird der Import von XMI-Dateien dargestellt. Besonderheiten
und Fehler, die bei der Benutzung der beiden Tools aufgefallen sind, sind in Anhang D aufgeführt.
1. XMI-Export
Als Ausgangszustand für den Export wird mindestens ein vorhandenes Klassendiagramm im
verwendeten Tool vorausgesetzt; bei Rational Rose muss dieses abgespeichert werden, bevor
ein Export möglich ist.
1.1 Ameos
Im Code-Fenster (Abbildung 26, Mitte rechts) muss zuerst die Baumdarstellung unter „Product Scripts/Languages“ erweitert werden; nach Rechtsklick auf XMI muss im Kontextmenu
„Run Script“ ausgewählt werden. Die exportierte Datei steht per Default in %AmeosVerzeichnis%\examples\%Systemname%\src_files; dies kann im Parameters-Fenster geändert
werden. Ameos speichert die Dateien mit der Endung .xmi.
Abbildung 26: Ameos, Export eines XMI-Dokuments
85
Abbildung 27: Ameos, Export eines XMI-Dokuments (Ausschnitt)
1.2 Rational Rose
Damit Rational Rose XMI exportieren kann, muss zuerst das „Rational Rose XMI-Plugin“
von Unisys installiert werden7.
Abbildung 28: Rational Rose, XMI-Export
7
Download unter http://www-1.ibm.com/support/docview.wss?uid=swg21131368 (17.04.2005)
Direktlink (17.04.2005):
ftp://www6.software.ibm.com/software/developer/library/rational/2834/Rose/RoseXMLTools1.3.6.01.zip
86
Anschließend kann über das Tools-Menu im Unterpunkt „UML 1.3 XMI Addin“ „UML 1.3
XMI Export“ ausgewählt werden (siehe Abbildung 28). Nach Auswahl der gewünschten Export-Optionen (von mir verwendete Optionen siehe Screenshot in Abbildung 29) muss nur
noch ein Dateiname angegeben werden.
Achtung: Damit ein Export möglich ist, muss das aktive Modell abgespeichert worden sein.
Rational Rose speichert die Dateien mit der Endung .xml.
Abbildung 29: Rational Rose, Dialogfenster XMI-Export
2. Umwandlung mit XMI2GXL und GXL2XMI
Zur Umwandlung wird ein „XSLT-Prozessor“ benötigt, u.a. wurde der als Freeware verfügbare Unicorn XSLT Processor8 verwendet, es kann aber auch jede andere XSLT-Prozessor/
XML-Parser9-Kombination verwendet werden (zusätzlich getestet: Cooktop 2.5 (Freeware)
mit MSXML 3 und 410, Xselerator 2.5 von Marrowsoft (MSXML 3 + 4), oXygen XML
Editor von syncRO soft).
Der Aufruf des Unicorn XSLT-Prozessors von der Kommandozeile (Linux oder Windows/
DOS) lautet:
uxt inputdokument stylesheet outputdokument
Allerdings wird bei der von mir verwendeten Version das xmlns:UML-Attribut nicht eingefügt, dies scheint ein Fehler der verwendeten Version zu sein; bei den anderen XSLTProzessoren (z.B. MSXML) tritt dieser Effekt nicht auf.
Der Aufruf mit dem MSXML-Prozessor (u.a. in Cooktop und Xselerator enthalten, Windows)
von der Kommandozeile lautet:
MSXSL inputdokument stylesheet [-o outputdokument]
Die Stylesheets können auf der GXL-Website11 heruntergeladen werden.
8
Download unter http://www.unicorn-enterprises.com/products_uxt.html (Stand 24.5.2005)
Eine Liste von Parsern gibt es z.B. auf http://www.topxml.com/parsers/other_parsers.asp (Stand 24.5.2005)
10
Download unter http://msdn.microsoft.com/xml (Stand 24.5.2005)
11
http://www.uni-koblenz.de/FB4/Contrib/GUPRO/Site/Downloads/index_html?project=gxl
9
87
3. Import von XMI-Dokumenten
3.1 Ameos
Um XMI-Dokumente in Ameos zu importieren, muss im Menu „Code“ „Reverse Engineering“ der Punkt „Import XMI Model…“ ausgewählt werden. Nach Angabe der zu importierenden Datei muss zuerst „Parse XMI file“, dann „Make Model“ angeklickt werden.
Abbildung 30: Import von XMI-Dokumenten in Ameos
3.2 Rational Rose
Nach Auswahl des Menupunkts „UML 1.3 XMI Import“ (siehe Abbildung 28) wird die zu
importierende Datei ausgewählt (das „Create New Model“-Fenster kann mit „Cancel“ abgebrochen werden). Die Import-Optionen können wie in Abbildung 31 gezeigt eingestellt
werden. Nach erfolgreichem Import in Rational Rose müssen die enthaltenen Klassen einzeln
in die Diagrammansicht gezogen werden (zu finden in der Baumansicht links unter „Logical
View“).
Abbildung 31: Import-Optionen Rational Rose
88
VIII. Zusammenfassung
Im Rahmen dieser Studienarbeit wurden Programme zur Umwandlung von XMI-Dateien (die
mit den beiden Tools Ameos und Rational Rose erstellt werden können) in GXL-Dateien und
zur Umwandlung von Dateien im GXL-Format in Dateien im XMI-Format erstellt. Somit
können erstellte UML-Klassendiagramme in das GXL-Format überführt werden und umgekehrt, wodurch ein Austausch zwischen Programmen, die entweder XMI oder GXL einlesen
und exportieren können, möglich ist.
Dazu wurden zuerst das GXL- und das XMI-Format analysiert, die beide dem XML-Standard
entsprechende Dokumente zur Speicherung von Graphen bzw. UML-Modellen benutzen.
Nach einer Analyse des erzeugten XMI-Codes der benutzten Werkzeuge und deren Umsetzung in entsprechende GXL-Graphen musste eine Entscheidung über die zu verwendende
Programmiersprache getroffen werden. Hierbei kamen Java (mit der JAXP) und XSLT in
Betracht. Aufgrund der speziellen Ausrichtung von XSLT auf die Verarbeitung von XMLDokumenten und dem einfachen Aufbau der Sprache habe ich mich dann zu einer Umsetzung
der Umwandlungstools in Form von vier verschiedenen XSL-Stylesheets entschlossen. Durch
abschließende Tests konnte die korrekte Funktionalität der Stylesheets nachgewiesen werden.
Die Tools sind auf der GXL-Website12 unter „Downloads“ verfügbar.
12
http://www.gupro.de/GXL/
89
IX. Literaturverzeichnis
[GXL02]
[GXL04]
[HoWi00]
[HSSW04]
[JAVA02]
[JAVA99]
[JAXP04]
[Jeck04]
[WiKuRi01]
[Wint01]
[XMI00]
[XMI02]
[XMI03]
[XSLT04]
GXL (1.0) Document Type Definition (Dagstuhl Edition, April 25, 2002),
http://www.gupro.de/GXL/dtd/dtd.html (25.09.2004).
http://www.gupro.de/GXL/ (15.11.2004)
R.C. Holt, A. Winter: A Short Introduction to the GXL Software Exchange
Format, Proceedings 7th Working Conference on Reverse Engineering
(WCRE 2000), Panel on Reengineering Exchange Formats, IEEE Computer
Society, Los Alamitos, 2000.
http://www.gupro.de/winter/Papers/holtwinter2000.pdf (23.08.2004).
Richard C. Holt, Andy Schürr, Susan Elliot Sim, Andreas Winter: GXL: A
Graph Based Standard Exchange Format for Reengineering, 2004. Preprint.
David Flanagan, Java In A Nutshell, Fourth Edition. O´Reilly & Associates,
Sebastopol, CA, 2002.
Nazmul Idris: XML and Java Tutorial, Part I,
http://developerlife.com/xmljavatutorial1/default.htm (06.12.2004)
http://java.sun.com (06.12.2004)
M. Jeckle, OMG´s XML Metadata Interchange Format XMI, Beitrag zum
Workshop XML Interchange Formats for Business Process Management.
http://www.jeckle.de/files/xml4bpm.pdf (23.08.2004).
Andreas Winter, Bernt Kullbach, Volker Riediger: An Overview of the GXL
Graph Exchange Language; aus: S. Diehl (ed.) Software Visualization · International Seminar Dagstuhl Castle, Germany, May 20-25, 2001 Revised Lectures, Springer Verlag Berlin Heidelberg 2002.
http://www.gupro.de/GXL/Publications/winter+2002.pdf (23.08.2004).
Andreas Winter: Exchanging Graphs with GXL, Fachberichte Informatik
09/2001, Universität Koblenz-Landau, Institut für Informatik, Koblenz, August 2001. http://www.uni-koblenz.de/fb4/publikationen/gelbereihe/RR-92001.pdf (23.08.2004).
OMG XML Metadata Interchange (XMI) Specification, Version 1.1, November 2000. http://www.omg.org/cgi-bin/doc?formal/2000-11-02 (11.10.2004).
OMG XML Metadata Interchange (XMI) Specification, Version 1.2, January
2002. http://www.omg.org/cgi-bin/doc?formal/2002-01-01 (23.08.2004).
XML Metadata Interchange (XMI) Specification, May 2003, Version 2.0,
formal/03-05-02. http://www.omg.org/cgi-bin/doc?formal/2003-05-02
(23.08.2004).
XSLT Tutorial, http://www.zvon.org/index.php?nav_id=tutorials
(06.12.2004)
90
Anhang A: GraphSchema.xmi
Die Zeilen 1 bis 6 enthalten die Header-Informationen, ab Zeile 7 folgt die Beschreibung des Modells.
Die Zeilen 10 bis 39 enthalten die Beschreibung der Klasse „Variable“ mit ihrem Attribut „name“ (Zeile 19 bis 37). Die Klasse „FunctionCall“ folgt
in den Zeilen 46 bis 54, die Klasse „Function“ mit ihrem Attribut folgt in den Zeilen 55 bis 84.
Danach werden die enthaltenen Assoziationen dargestellt. In den Zeile 94 bis 137 wird „isOutput“ beschrieben, hierbei wird auf die verknüpften
Klassen mit ihren IDs verwiesen (Zeile 113, 114 sowie 132, 133). Die Multiplizitäten werden in den Zeilen 107 und 126 angegeben, „-1“ stellt dabei unendlich dar. Die Zeilen 138 bis 181 beschreiben die „isInput“-Assoziation, Zeile 182 bis 225 die „isCaller“- und Zeile 226 bis 269 die „isCallee“-Assoziation.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<?xml version="1.0" encoding= "ISO-8859-1"?>
<XMI xmi.version="1.1" xmlns:UML = 'org.omg.xmi.namespace.UML'>
<XMI.header>
<XMI.metamodel xmi.name="UML" xmi.version="1.4" />
</XMI.header>
<XMI.content>
<UML:Model>
<UML:Class name = 'Variable' visibility = 'public'
xmi.id
=
'UID_3CAC7F83-8264-486a-8FE5-6F6460F74A76'
xmi.uuid
=
'UID_3CAC7F83-8264-486a-8FE5-6F6460F74A76'
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
<UML:Attribute name = 'name' xmi.id = 'UID_B81B1AF8E295-401c-BAB3-3615E69FF4A2'
visibility ='private'
xmi.uuid = 'UID_B81B1AF8-E295-401cBAB3-3615E69FF4A2'
comment = ''
type
=
'TP_UID_B81B1AF8-E295-401cBAB3-3615E69FF4A2'
91
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
<UML:Multiplicity>
<UML:MultiplicityRange lower
= '1' upper = '1'>
</UML:Multiplicity>
</UML:Attribute>
</UML:Class>
<UML:DataType
xmi.id = 'TP_UID_B81B1AF8-E295-401c-BAB3-3615E69FF4A2'
name ='String'
/>
<UML:Class name = 'FunctionCall' visibility = 'public'
xmi.id
=
'UID_B53413A8-E393-43d3-99F4-0E3DEDA7A0CD'
xmi.uuid
=
'UID_B53413A8-E393-43d3-99F4-0E3DEDA7A0CD'
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
</UML:Class>
<UML:Class name = 'Function' visibility = 'public'
xmi.id
=
'UID_DA83D1D1-37BE-4c35-93EC-34FF58605D12'
xmi.uuid
=
'UID_DA83D1D1-37BE-4c35-93EC-34FF58605D12'
isRoot = 'true'
isLeaf = 'true'
isActive = 'false'
>
<UML:Attribute name = 'name' xmi.id = 'UID_A9002D1344F8-4618-8B88-CC9C773B7253'
visibility ='private'
92
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
xmi.uuid
=
'UID_A9002D13-44F8-4618-
8B88-CC9C773B7253'
comment = ''
type
=
'TP_UID_A9002D13-44F8-46188B88-CC9C773B7253'
<UML:Multiplicity>
<UML:MultiplicityRange lower
= '1' upper = '1'>
</UML:Multiplicity>
</UML:Attribute>
</UML:Class>
<UML:DataType
xmi.id = 'TP_UID_A9002D13-44F8-4618-8B88-CC9C773B7253'
name ='String'
/>
<UML:Association name = 'isOutput'
comment = '' xmi.uuid = 'UID_223219FD-0863-4dde-B66D-8B2B059EA78A'
xmi.id = 'UID_223219FD-0863-4dde-B66D-8B2B059EA78A'>
<UML:AssociationEnd name = '' xmi.id = 'UID_F68EEE82-5138-4cbe-B553-0F665058EBBB'
xmi.uuid = 'UID_F68EEE82-5138-4cbe-B553-0F665058EBBB'
comment = ''
isNavigable = 'true' ordering = 'ordered'
<UML:Multiplicity>
93
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
<UML:MultiplicityRange lower = '0' upper = '-1'>
</UML:Multiplicity>
<UML:Classifier
xmi.idref
=
'UID_B53413A8-E393-43d3-99F40E3DEDA7A0CD'/>
<UML:AssociationEnd name = '' xmi.id = 'UID_995DE1D8-2274-4edc-8E3B-7BAC88182473'
xmi.uuid = 'UID_995DE1D8-2274-4edc-8E3B-7BAC88182473'
comment = ''
isNavigable = 'false' ordering = 'unordered'
<UML:Multiplicity>
</UML:Multiplicity>
<UML:Classifier
xmi.idref
=
'UID_3CAC7F83-8264-486a-8FE56F6460F74A76'/>
</UML:Association>
<UML:Association name = 'isInput'
comment = '' xmi.uuid = 'UID_427B0BBF-82D8-4cf0-99A5-AEC7790B19D7'
xmi.id = 'UID_427B0BBF-82D8-4cf0-99A5-AEC7790B19D7'>
<UML:AssociationEnd name = '' xmi.id = 'UID_EB13436F-4EE1-41a9-85B8-A4757DCE9844'
xmi.uuid = 'UID_EB13436F-4EE1-41a9-85B8-A4757DCE9844'
comment = ''
94
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
<UML:Multiplicity>
</UML:Multiplicity>
<UML:Classifier
xmi.idref
=
'UID_3CAC7F83-8264-486a-8FE56F6460F74A76'/>
<UML:AssociationEnd name = '' xmi.id = 'UID_2D2CAD67-45B5-4e77-97C5-7A1A8CBBA3A2'
xmi.uuid = 'UID_2D2CAD67-45B5-4e77-97C5-7A1A8CBBA3A2'
comment = ''
<UML:Multiplicity>
</UML:Multiplicity>
<UML:Classifier
xmi.idref
=
</UML:Association>
<UML:Association name = 'isCaller'
comment = '' xmi.uuid = 'UID_DF9E435D-555C-4cd5-84E4-8EA3076744B1'
xmi.id = 'UID_DF9E435D-555C-4cd5-84E4-8EA3076744B1'>
<UML:AssociationEnd name = '' xmi.id = 'UID_90B4D624-5C80-470e-909B-B8A8D2947DDE'
95
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
xmi.uuid = 'UID_90B4D624-5C80-470e-909B-B8A8D2947DDE'
comment = ''
<UML:Multiplicity>
</UML:Multiplicity>
<UML:Classifier
xmi.idref
=
<UML:AssociationEnd name = '' xmi.id = 'UID_950FC68B-002D-4097-B405-DE5FFE6C265F'
xmi.uuid = 'UID_950FC68B-002D-4097-B405-DE5FFE6C265F'
comment = ''
<UML:Multiplicity>
</UML:Multiplicity>
<UML:Classifier
xmi.idref
=
'UID_DA83D1D1-37BE-4c35-93EC34FF58605D12'/>
</UML:Association>
<UML:Association name = 'isCallee'
96
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
comment = '' xmi.uuid = 'UID_7A1F9AAF-441A-499f-8F7E-728885167966'
xmi.id = 'UID_7A1F9AAF-441A-499f-8F7E-728885167966'>
<UML:AssociationEnd name = '' xmi.id = 'UID_E306545A-46BF-42c2-949C-5B82A7EDEC41'
xmi.uuid = 'UID_E306545A-46BF-42c2-949C-5B82A7EDEC41'
comment = ''
<UML:Multiplicity>
</UML:Multiplicity>
<UML:Classifier
xmi.idref
=
<UML:AssociationEnd name = '' xmi.id = 'UID_C8023785-0394-4f5c-BF03-F5E6C9FFCFBF'
xmi.uuid = 'UID_C8023785-0394-4f5c-BF03-F5E6C9FFCFBF'
comment = ''
<UML:Multiplicity>
</UML:Multiplicity>
<UML:Classifier
xmi.idref
=
'UID_DA83D1D1-37BE-4c35-93EC34FF58605D12'/>
97
267
268
269
270
271
272
273
</UML:Association>
</UML:Model>
</XMI.content>
</XMI>
98
Anhang B: Umwandlung UML-Klassen in GXL-Nodes
Die Zeilen 1 bis 7 enthalten die Header-Angaben wie benutzte Namespaces und das Ausgabeformat (hier xml). Die ersten beiden Abfragen (Zeilen 9 bis 31) generieren den „Rahmen“ des
GXL-Dokuments, Zeile 33 bis 61 enthält dann die Abfrage auf das Tag UML:Class, hierfür
wird dann ein Node im GXL-Dokument erzeugt, das Attribut ID wird auf die ID, die im Tag
UML:Class ebenfalls als Attribut gespeichert ist, gesetzt (Zeile 35 bis 37). Nach Einfügen des
erforderlichen Type-Tags (Zeile 38 bis 42) werden in attr-Tags die Daten der UML-Klasse
(hier der Name und die Information, ob die Klasse abstrakt ist) gemäß der GXL-Spezifikation
eingefügt.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version = '1.0'
xmlns:xsl='http://www.w3.org/1999/XSL/Transform'
xmlns:UML='org.omg.xmi.namespace.UML'
xmlns:xlink="http://www.w3.org/1999/xlink">
<xsl:output method="xml"/>
<xsl:template match="/">
<gxl>
<xsl:apply-templates/>
</gxl>
</xsl:template>
<xsl:template match="XMI">
<graph>
<xsl:attribute name="id">
<xsl:text>class-graph</xsl:text>
</xsl:attribute>
<xsl:attribute name="edgeids">
<xsl:text>true</xsl:text>
</xsl:attribute>
<xsl:attribute name="hypergraph">
<xsl:text>false</xsl:text>
</xsl:attribute>
<xsl:attribute name="edgemode">
<xsl:text>directed</xsl:text>
</xsl:attribute>
<xsl:apply-templates/>
</graph>
</xsl:template>
<xsl:template match="UML:Class">
<node>
<xsl:attribute name="id">
<xsl:value-of select="@xmi.id"/>
</xsl:attribute>
<type>
<xsl:attribute name="xlink:href">
<xsl:text>http://www.gupro.de/GXL/gxl-1.0.gxl#NodeClass</xsl:text>
</xsl:attribute>
</type>
<attr>
<xsl:attribute name="name">
99
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
<xsl:text>name</xsl:text>
</xsl:attribute>
<string>
<xsl:value-of select="@name"/>
</string>
</attr>
<attr>
<xsl:attribute name="name">
<xsl:text>isAbstract</xsl:text>
</xsl:attribute>
<bool>
<xsl:value-of select="@isAbstract"/>
</bool>
</attr>
</node>
</xsl:template>
</xsl:stylesheet>
100
Anhang C: XMI-Dokument in GXL transferiert
Hier ein einfaches Beispiel eines „übersetzten“ XMI-Dokuments, das zwei Klassen enthält und
mit Ameos erzeugt wurde.
<?xml version="1.0" encoding="UTF-16"?>
<gxl xmlns:UML="org.omg.xmi.namespace.UML"
xmlns:xlink="http://www.w3.org/1999/xlink">
<graph id="class-graph" edgeids="true" hypergraph="false" edgemode="directed">
<node id="UID_7852041B-7687-497b-9CC1-B9A912844892">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="UID_4B72A452-32F8-4295-9540-5D7023B4CB69">
<attr name="name">
</attr>
<bool>false</bool>
</attr>
</node>
<node id="ID_DUMMY_CLASS">
<attr name="name">
<string>Container_class_for_objects_and_actors</string>
</attr>
<bool></bool>
</attr>
</node>
</graph>
</gxl>
101
Anhang D: Anmerkungen/ Besonderheiten der verwendeten
Werkzeuge
1. Ameos13
- In Ameos sind keine Assoziations-Klassen modellierbar. Als Workaround können für eine zu
modellierende Assoziations-Klasse eine Assoziation, die den gleichen Namen wie eine vorhandene Klasse hat, modelliert werden; dies wird dann als eine Assoziations-Klasse interpretiert. Ebenso werden im GXL-Dokument vorhandene Darstellungen von AssoziationsKlassen auf diese Weise umgesetzt.
- Werden Objekte in Ameos modelliert, werden diese bei XMI-Export ignoriert (Bugreport-Nr.:
ECR11667).
- Beim Import in Ameos werden die enthaltenen Informationen der XMI-Datei auf verschiedene Diagramme aufgeteilt.
- Beim Import in Ameos „verschwinden“ die Multiplizitäten teilweise.
- Beim Import in Ameos wird der Typ von Attributen auch als Klasse dargestellt. Beispiel:
XMI-Import einer Klasse mit Attribut von Typ „string“ enthält diese Klasse mit einer Assoziation zu einer Klasse mit Namen „string“.
- Ameos kann keine Unicode-Dateien importieren, daher wurde beim Erstellen von AmeosXMI-Dokumenten auf eine entsprechende Kodierung geachtet.
2. Rational Rose14
- Beim XMI-Export aus Rational Rose können verschiedene Optionen gesetzt werden; dementsprechend wird dann bei Erzeugung der XMI-Datei eine unterschiedliche UML-DTD verwendet. Die verwendete Einstellung entspricht der Voreinstellung, außer dass die Checkbox
„Exports Diagrams“ nicht ausgewählt ist (also wird die visuelle Darstellung nicht gespeichert,
ansonsten entspricht die generierte Datei bis zum <UML:Diagram>-Tag aber derjenigen, die
ansonsten auch erzeugt würde).
- Die Komposition wird in Rational Rose über Auswahl von „aggregate“ und „by value“ (bei
Containment of {entsprechende Klasse} unter „Role A Detail“ bzw. „Role B Detail“) modelliert.
- Über Rational Rose existiert auf der Homepage von IBM ein Dokument (What information
would be lost importing/exporting diagrams with the XMI add-in? http://www1.ibm.com/support/docview.wss?uid=swg21130362), welches festgestellte Fehler beinhaltet.
Bisher wurde keine Relevanz für diese Studienarbeit daraus festgestellt.
3. Sonstiges
- Die Darstellung und Umsetzung von Operationen in GXL ist nicht definiert; daher werden
diese beim Export nicht berücksichtigt.
13
14
verwendete Version: Ameos 9.1.5 (Build 46)
verwendete Version: Rose Enterprise Edition, Release Version: 2003.06.12.280.000
102

Studienarbeit Umwandlung von XMI in GXL und von GXL in XMI

Transcription

Similar documents

Semantic Web

Das Technikgebiet XML: Herkunft, praktische Anwendung

OMG`s XML Metadata Interchange Format XMI

endpunkt uml diagramm