UML-Tools und XMI - von wegen Standard

Abstract

Vor kurzem habe ich ja über den Start meines neuen Use Case Point Werkzeug berichtet: UCP@work.
Dabei ging es mir vor allem drum, auf den XMI-Standard zu setzen, um grafische UML-Modelle in mein Werkzeug importieren zu können. In diesem Beitrag muss ich mich dann mal eben beschweren, und zwar über die Implementierung des vermeintlichen Standards in unterschiedlichen UML-Werkzeugen.

Zuerst einmal: Was ist XMI?

Wikipedia hilft:

XML Metadata Interchange (XMI) ist ein Standard der Object Management Group (OMG) und wird zunehmend als Austauschformat zwischen Software-Entwicklungswerkzeugen (etwa im Eclipse Modeling Framework, EMF) verwendet.

Schön. Und weiter?

Das Format ist offen und anbieterneutral und gestattet den Datenaustausch von Objekten auf Basis von Meta-Metamodellen nach der Meta-Object Facility (MOF). Neben UML-Modellen können beliebige Metadaten ausgetauscht werden, solange sich diese mit Hilfe der MOF ausdrücken lassen. Aufgrund des XML-Formats können entsprechende Dateien leicht erzeugt, durchsucht, weiterverarbeitet, gespeichert und über das Internet übertragen werden. In dieser Hinsicht ist XMI alternativen Austauschformaten wie etwa CDIF überlegen. Mit der kommenden Version 2.0 soll auch die vollständige Übertragung von grafischen Diagrammen möglich werden.

Gut. Mit anderen Worten: Man modelliert ein Software-System mittels UML-Diagrammen in dem einen Werkzeug, exportiert das entstandene Modell in das XMI-Format und importiert die XMI-Datei in ein anderes Modellierungswerkzeug.

XMI und UCP@work

Also schien mir XMI genau das richtige Austausch-Format zu sein, um grafische Modelle in mein Formular zur Aufwandsschätzung anhand von Use Cases zu importieren. Im Prinzip brauche ich ja erstmal nur aus dem XML-Baum die Use Cases, Akteure und die Assoziationen auszulesen, richtig verknüpfen und dann ins Formular importieren. Nichts leichter als das. Dachte ich. Und hatte anfangs auch recht.

XMI in ArgoUML

Ungefähr so sieht der XML-Baum eines Use Case Diagramms aus, wenn das Diagramm mit ArgoUML modelliert wurde.

Sehr schön kann man die Elemente entdecken, die mich interessieren: 3x Use Case, 1x Actor, 3x Association. Schön benamst und mit IDs versehen, die Eigenschaften der einzelnen Elemente sind in den Attributen drin, die Association geben schön die beiden Endpunkte an - alles toll. Und damit funktioniert im Moment auch UCP@work. Toll, oder? "Und wenn das so einfach war, dann müßte ja jetzt jedes Werkzeug, was ein XMI ausspuckt auch mit meinem Formular arbeiten können!" Gleich mal ausprobieren...

XMI in Enterprise Architect

Ein Kollege hat mir von einem Use Case Diagramm den XMI-Export aus einem Enterprise Architect von SparxSystems besorgt. Schauen wir uns doch mal den XML-Baum an...

"Ok, ein Profi-Werkzeug", denke ich mir. "Geschwätzig, na was soll's. Wo sind denn die Use Cases... Ah, da!"
Use Cases sind also da, Assoziationen auch, aber wo verdammt sind die Akteure?!? Die waren doch auf dem Screen des Kollegen zu sehen?

Endloses Suchen, Baum-Traversieren auf und ab, dann die Lösung: der XMI-Export von Enterprise-Architect kennt keine Use Cases. Also, scheinbar zumindest nicht als Element-Name wie oben bei ArgoUML kennengelernt. Stattdessen verstecken sich die Akteure als "TaggedValue"´in den Assoziationen. Das verkürztes Beispiel seht Ihr hier:

Fazit

Es steht mir wohl ne Menge Arbeit ins Haus. Wenn andere Werkzeuge genauso "standardisiert" mit eigenen TaggedValues arbeiten, dann gute Nacht. Aber ich werde mich wohl trotzdem an der "Herausforderung" versuchen... Immerhin jammere ich nicht alleine. Als ich versucht habe die EA-XMI-Datei nach ArgoUML zu importieren, gab's folgende Meldung: