Universität Koblenz-Landau Fachbereich Informatik Institut für Softwaretechnik

(1)

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

(2)

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.GXLDTD... 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

(3)

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.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.2 Assoziation: GXL-Darstellung... 46

2.4 Aggregation... 48

2.4.1 Aggregation: XMI-Darstellung ... 48

2.4.1.1 Ameos... 49

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.2 Komposition: GXL-Darstellung... 60

2.6 Generalisierung... 62

2.6.1 Generalisierung: XMI-Darstellung ... 62

2.6.1.1 Ameos... 62

2.6.2 Generalisierung: GXL-Darstellung ... 64

2.7 Package ... 65

2.7.1 Package: XMI-Darstellung... 65

(4)

2.7.1.1 Ameos... 65

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.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.3 Testdokument... 84

VII. ANWENDUNG DER ERSTELLTEN PROGRAMME... 85

1.XMI-EXPORT... 85

1.1 Ameos ... 85

2.UMWANDLUNG MIT XMI2GXL UND GXL2XMI ... 87

3.IMPORT VON XMI-DOKUMENTEN... 88

3.1 Ameos ... 88

VIII. ZUSAMMENFASSUNG... 89

IX. LITERATURVERZEICHNIS... 90

(5)

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

(6)

Abstract

GXL (Graph Exchange Language) wurde als ein Austauschformat für graph-basierte Werk- zeuge entwickelt. Das XMI (XML Metadata Interchange)-Format wurde zur textuellen Dar- stellung von auf dem MOF (Meta Object Facility)-Metamodell basierenden Modellen entwickelt; hierunter fallen auch UML (Unified Modelling Language)-Modelle. In dieser Studien- arbeit wurde ein Umsetzungstool entwickelt, um XMI-Daten (erzeugt aus UML- Klassendiagrammen) 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 beach- ten, dass verschiedene Tools verschiedene XMI-Dialekte verwenden. Im Rahmen dieser Ar- beit wurden Ameos und Rational Rose benutzt. Anschließend wurde der für diese Tools er- zeugte 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).

(7)

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-Standard¹.

In dieser Studienarbeit wurde eine Anwendung entwickelt, die es ermöglicht, Daten zwischen beiden Formaten zu transferieren, d.h. vorliegende (durch entsprechende Anwendungen er- stellte) XMI-Daten sollen ins GXL-Format und Daten im GXL-Format sollen ins XMI- Format umgewandelt werden können. Hierdurch soll eine Interoperabilität zwischen verschiedenen Werkzeugen, die eins der beiden Formate verwenden, ermöglicht werden. Bei- spielweise 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 Aus- tauschformat für graph-basierte Werkzeuge genutzt werden [Wint01].

GXL ist als eine XML-Sprache definiert, mit der sowohl Instanz-Graphen als auch die zuge- hö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üpfun- gen 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 Kan- tenklassen, der Relationen zwischen diesen Knoten und Kanten, ihrer Attribute, der Graphen- hierarchie und zusätzliche Beschränkungen [Wint01]. Graph-Klassen werden als UML- Klassendiagramme definiert. Hierbei werden z.B. Knotenklassen durch Klassen, Kantenklas- sen 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

(8)

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 austau- schen 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 Att- ribute 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 Pro- gramme² 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 Ver- gleich hierzu, der zu der Entscheidung zur Umsetzung mit XSL führte, findet sich in Ab- schnitt 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-Pro- gramme) sowie GXL2XMI bezeichnet, ist der Zusatz „-Ameos“ bzw. „-RR“ angegeben, ist das Programm für das entsprechende Tool gemeint.

(9)

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 (zu- rück-)überführt werden können. Auch hier musste ggf. nach dem „Zielwerkzeug“ unterschie- den 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 Gra- phenschemata 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 analy- sieren ([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 Umset- zungsprogramme 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 prak- tische Anwendung der erstellten Programme und der verwendeten Werkzeuge eingegangen.

Ebenso wird hier auf Besonderheiten, die während der Benutzung aufgefallen sind, verwiesen.

(10)

II. GXL – Graph Exchange Language 1. Einleitung

GXL (Graph eXchange Language) wurde als Standardaustauschformat für graphbasierte An- wendungen 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“

v : Var

line = 27

e : refers

line = 42

Beispiel 1: attributierter, typisierter, gerichteter Graph mit attributierter Kante

(11)

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 Gra- phen 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>

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"/>

<edge id = "e"

from = "v" to = "w"/>

</graph>

</node>

<node id = "u"/>

<edge id = "f"

from = "t" to = "u"/>

{2}

{1}

v : V

w : W

u : U

r :

theSecondU

theFirstU

theV

theW

u :

f :

t : T

v : e : w :

g : GraphT

Beispiel 2: Hypergraph und n-äre Relationen

Beispiel 3: Hierarchischer Graph

(12)

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 % gxl-attr-extension "" >

<!ENTITY % graph-attr-extension "" >

<!ENTITY % node-attr-extension "" >

<!ENTITY % edge-attr-extension "" >

<!ENTITY % rel-attr-extension "" >

<!ENTITY % 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-Standardda- tentypen (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.

(13)

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>

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.

(14)

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 Att- ributen 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 festgeleg- ten 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).

(15)

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 ver- binden. Hier kann analog zu Knoten und Kanten wiederum der Typ sowie eine Liste von Att- ributen 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 isdirected- Attribut 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 Unter- scheidung verschiedener Arten von Attributen (z.B. zur Kennzeichnung abgeleiteter Attribu- te).

(16)

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) #FIXED "simple"

xlink:href CDATA #REQUIRED

>

Ein locator-Element verweist auf zusätzliche Dokumente oder Dokument-Elemente.

3.12 Datentypen

<!ELEMENT bool (#PCDATA) >

<!ELEMENT int (#PCDATA) >

<!ELEMENT float (#PCDATA) >

<!ELEMENT string (#PCDATA) >

Atomare Datentypen. GXL benutzt die Bezeichnungen und Grammatikregeln von Java.

<!ELEMENT enum (#PCDATA) >

Werte, die vom Typ Aufzählung sind.

<!ELEMENT seq (%val;)* >

<!ELEMENT set (%val;)* >

<!ELEMENT bag (%val;)* >

<!ELEMENT tup (%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]

(17)

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 Hy- pergraphen und hierarchische Graph-Schemata in der üblichen UML-Notation dargestellt werden. Diese UML-Klassendiagramme können als Graphen und damit in einer GXL- kompatiblen Weise dargestellt werden. Damit können dann Instanz-Graphen und die dazuge- hö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 Att- ribute enthalten).

Attribute und Attributtypen werden als AttributeClass-Knoten mit passenden Attributtyp- Knoten dargestellt. Attributinformationen werden mit den ensprechenden Knoten- und Kan- tenklassen 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 (con- tains-)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.

(18)

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 Diagram- men/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 Modellie- rungssprachen der OMG (und damit auch UML) beschrieben werden. Das MOF-Metameta- modell (kurz MOF-Modell) ist eine Sprache, um MOF-Metamodelle (z.B. das UML-Meta- modell) 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-Nota- tion wird benutzt, um MOF-basierte Metamodelle zu beschreiben.

Das MOF-Modell wird in einer 4-Schichten-Darstellung dargestellt:

Meta-Level MOF-Begriffe Beispiele

M3 Meta-Metamodell Das MOF-Modell

M2 Metamodell UML-Metamodell

M1 Modell UML-Modelle

M0 Objekte 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.

(19)

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 ISO- 10646-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 ISO- 10646-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-Deklara- tionen 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 (glo- bal) 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 XML- Attribute, die als Wert die oben verwendeten IDs benutzen.

(20)

<!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.label- oder 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.struct

• XMI.seqItem

• XMI.sequence

• XMI.arrayLen

• XMI.array

• XMI.enum

• XMI.discrim

• XMI.union

• XMI.any

Im folgenden werden diese Deklarationen genauer beschrieben. Dabei wird nach dem Wur- zelelement 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.

(21)

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 Meta- metamodell 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;

>

(22)

<!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. Infor- mationen ü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 Werk- zeug, 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:

(23)

<!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.name CDATA #REQUIRED xmi.version CDATA #REQUIRED

>

<!ELEMENT XMI.metametamodel ANY>

<!ATTLIST XMI.metametamodel

%XMI.link.att;

xmi.name CDATA #REQUIRED 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.name CDATA #REQUIRED xmi.version CDATA #REQUIRED

>

3.2.10 XMI.extension

Das Element XMI.extension enthält XML-Elemente, die Metadaten enthalten, die das Meta- modell erweitern. Dieses Element kann direkt in XML-Elemente im content-Abschnitt einge- fügt werden, um die erweiterten Metadaten mit einem bestimmten XML-Element zu verbin- den.

<!ELEMENT XMI.extension ANY >

<!ATTLIST XMI.extension

%XMI.element.att;

%XMI.link.att;

xmi.extender CDATA #REQUIRED xmi.extenderID CDATA #IMPLIED

>

(24)

3.2.11 XMI.reference

Das Element XMI.reference erlaubt Verweise auf andere XML-Elemente innerhalb eines Att- ributs 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 Auf- zählung angegeben) können als “feste” oder als durch das Metamodell festgelegte Deklaratio- nen 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 (Bei- spiel: UML:Class). Namen von Tags für Attribute und Referenzen aus dem Metamodell be- stehen 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 bezie- hen, besteht nur aus dem Namen der Referenz bzw. des Attributs.

Jedem Namensbereich wird ein logischer (in der Namensbereichdeklaration des XMI-Ele- ments 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 Doku- ments (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 „Pro- perties“, „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-In- Beziehungen:

<!ENTITY % cProperties ‘’>

<!ENTITY % cAssociations ‘’>

<!ENTITY % cCompositions ‘’>

<!ELEMENT c (XMI.extension)* >

<!ATTLIST c

%XMI.element.att;

%XMI.link.att;

>

(25)

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 Aus- nahme 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 Metamo- dells definiert ist:

<!ELEMENT c.a (type specification) >

Für den Fall einer Spezifikation außerhalb des Metamodells wird als Typ ein String-Typ an- genommen, 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 Deklara- tion (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.

(26)

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 Me- tamodellklasse „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 XML- Entity 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

(27)

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 logi- schen 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 Na- men „C1“, die wiederum ein Attribut enthält, das innerhalb des UML-Classifier.feature-Tags in einem UML:Attribute-Tag deklariert ist.

<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 keiner- lei ID angegeben wurde.

<!ELEMENT UML:Class (UML:ModelElement.name | 1

UML:ModelElement.visibility | 2

UML:GeneralizableElement.isRoot | 3

UML:GeneralizableElement.isLeaf | 4

UML:GeneralizableElement.isAbstract | 5

UML:Class.isActive | XMI.extension | 6

UML:ModelElement.binding | 7

UML:ModelElement.template | 8

UML:ModelElement.templateParameter | 9

UML:ModelElement.implementation | 10

UML:ModelElement.view | 11

(28)

UML:ModelElement.presentation | 12

UML:ModelElement.namespace | 13

UML:ModelElement.constraint | 14

UML:ModelElement.requirement | 15

UML:ModelElement.provision | 16

UML:ModelElement.stereotype | 17

UML:ModelElement.elementReference | 18

UML:ModelElement.collaboration | 19

UML:ModelElement.behavior | 20

UML:ModelElement.partition | 21

UML:GeneralizableElement.generalization | 22

UML:GeneralizableElement.specialization | 23

UML:Classifier.parameter | 24

UML:Classifier.structuralFeature | 25

UML:Classifier.specification | 26

UML:Classifier.realization | 27

UML:Classifier.associationEnd | 28

UML:Classifier.participant | 29

UML:Classifier.createAction | 30

UML:Classifier.instance | 31

UML:Classifier.collaboration | 32

UML:Classifier.classifierRole | 33

UML:Classifier.classifierInState | 34

UML:ModelElement.taggedValue | 35

UML:Namespace.ownedElement | 36

UML:Classifier.feature)* >

37 38

<!ATTLIST UML:Class 39

name CDATA #IMPLIED 40

visibility (public | protected | private) #IMPLIED 41

isRoot (false | true) #IMPLIED 42

isLeaf (false | true) #IMPLIED 43

isAbstract (false | true) #IMPLIED 44

isActive (false | true) #IMPLIED 45

binding IDREFS #IMPLIED 46

template IDREFS #IMPLIED 47

templateParameter IDREFS #IMPLIED 48

implementation IDREFS #IMPLIED 49

view IDREFS #IMPLIED 50

presentation IDREFS #IMPLIED 51

namespace IDREFS #IMPLIED 52

constraint IDREFS #IMPLIED 53

requirement IDREFS #IMPLIED 54

provision IDREFS #IMPLIED 55

stereotype IDREFS #IMPLIED 56

elementReference IDREFS #IMPLIED 57

ModelElement.collaboration IDREFS #IMPLIED 58

behavior IDREFS #IMPLIED 59

partition IDREFS #IMPLIED 60

generalization IDREFS #IMPLIED 61

specialization IDREFS #IMPLIED 62

parameter IDREFS #IMPLIED 63

structuralFeature IDREFS #IMPLIED 64

specification IDREFS #IMPLIED 65

realization IDREFS #IMPLIED 66

associationEnd IDREFS #IMPLIED 67

(29)

participant IDREFS #IMPLIED 68

createAction IDREFS #IMPLIED 69

instance IDREFS #IMPLIED 70

Classifier.collaboration IDREFS #IMPLIED 71

classifierRole IDREFS #IMPLIED 72

classifierInState IDREFS #IMPLIED 73

%XMI.element.att;

74

%XMI.link.att;

75

>

76

(30)

4.2.2 Assoziation

Eine Assoziation wird durch das Element UML:Association beschrieben. Dieses kann als Att- ribut z.B. einen Namen für die Assoziation enthalten. Eine Assoziation zwischen zwei Klas- sen „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:AssociationEnd>

</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 Assozia- tionsende als Attribut enthalten (Zeile 53). Die Multiplizität kann im UML:AssociationEnd- Element 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. Asso- ziations-Endes) ist in der hier dargestellten Standard-XMI-Spezifikation nicht enthalten. Da- her wäre obiges Dokument nach der „Standard“-UML-DTD der XMI-Spezifikation der OMG [XMI00] nicht gültig.

<!ELEMENT UML:Association (UML:ModelElement.name | 1

UML:GeneralizableElement.isRoot | 3

UML:GeneralizableElement.isLeaf | 4

UML:GeneralizableElement.isAbstract | 5

XMI.extension | UML:ModelElement.binding | 6

(31)

UML:GeneralizableElement.generalization | 21

UML:GeneralizableElement.specialization | 22

UML:Association.link | 23

UML:Association.associationEnd | 24

UML:Namespace.ownedElement | 26

UML:Association.connection)* >

27 28

<!ATTLIST UML:Association 29

isRoot (false | true) #IMPLIED 32

isLeaf (false | true) #IMPLIED 33

isAbstract (false | true) #IMPLIED 34

collaboration IDREFS #IMPLIED 47

generalization IDREFS #IMPLIED 50

specialization IDREFS #IMPLIED 51

link IDREFS #IMPLIED 52

associationEnd IDREFS #IMPLIED 53

%XMI.element.att;

54

%XMI.link.att;

55

>

56 57

<!ELEMENT UML:Association.connection (UML:AssociationEnd | 58

UML:AssociationEndRole)* >

59 60

<!ELEMENT UML:AssociationEnd (UML:ModelElement.name | 61

UML:AssociationEnd.isNavigable | 63

UML:AssociationEnd.isOrdered | 64

UML:AssociationEnd.aggregation | 65

UML:AssociationEnd.multiplicity | 66

UML:AssociationEnd.changeable | 67

UML:AssociationEnd.targetScope | 68

XMI.extension | UML:ModelElement.binding | 69

(32)

UML:AssociationEnd.type | 84

UML:AssociationEnd.specification | 85

UML:AssociationEnd.association | 86

UML:AssociationEnd.linkEnd | 87

UML:AssociationEnd.associationEndRole | 88

UML:AssociationEnd.qualifier)* >

90 91

<!ATTLIST UML:AssociationEnd 92

isNavigable (false | true) #IMPLIED 95

isOrdered (false | true) #IMPLIED 96

aggregation (none | shared | composite) #IMPLIED 97

multiplicity CDATA #IMPLIED 98

changeable (none | frozen | addOnly) #IMPLIED 99

targetScope (classifier | instance) #IMPLIED 100

collaboration IDREFS #IMPLIED 113

type IDREFS #IMPLIED 116

specification IDREFS #IMPLIED 117

association IDREFS #IMPLIED 118

linkEnd IDREFS #IMPLIED 119

associationEndRole IDREFS #IMPLIED 120

%XMI.element.att;

121

%XMI.link.att;

122

(33)

5. Beispieldiagramm

Function -name : String

FunctionCall

Variable -name : String 1

isCaller 1

isCallee 0..*

0..*

isInput 0..*

0..* 0..*

isOutput 0..*

{ordered}

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.

(34)

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ön- nen, 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 auf- treten. Dann wird dieses UML-Konzept als GXL-Graph dargestellt, der dem GXL- Metaschema entspricht.

Im Rahmen der Studienarbeit wurde ein Werkzeug entwickelt, das die von Ameos und Ratio- nal Rose erzeugten XMI-Dateien in GXL-Graphen umsetzt (XMI2GXL), sowie GXL- Graphen 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 Studien- arbeit 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 XMI- Dokument 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

<XMI.header>

2

<XMI.model xmi.name="Klasse" href="Klasse.xml"/>

3

<XMI.metamodel xmi.name="UML" href="UML.xml"/>

4

</XMI.header>

5

<XMI.content>

6

<UML:Class name="Class1" xmi.id="Class1"/>