Modellaustausch | |
Modellaustausch mit dem XML Metadata Interchange Format
Der OMG-Standard zum werkzeugunabhängigen Transfer objektorientierter Modelle
Mario Jeckle
Erschienen in der Ausgabe 5, 1999, der Zeitschrift ObjektSpektrum
Mit der Verabschiedung der Unified Modeling Language (UML) durch die Object Management Group (OMG) im Herbst 1997 wurde eine in der Praxis weit akzeptierte graphische Beschreibungssprache für objektorientierte Modelle geschaffen.
Die UML ist aber keine Sprache im herkömmlichen Sinne -- steht doch der graphischen Notation keine textuelle Sprache gegenüber. Diese ist jedoch notwendig um UML-Modelle über Werkzeuggrenzen hinweg auszutauschen. SMIF (OMG's Stream-based Model Interchange Format) hat sich die Lösung dieses Austauschproblems zum Ziel gesetzt.
Modellaustausch |
Die Komplexität moderner Systeme bedingt die Notwendigkeit mannigfaltige Implementierungssprachen innerhalb vielfältigster Entwicklungsumgebungen auf gemischten Plattformen einzusetzen und im Projektablauf zu koordinieren.
Während diese Heterogenitäten nicht ohne Produktivitätsverlust behebbar sind, d.h. selbst auferlegte Beschränkung auf eine Implementierungssprache oder Plattform geht immer mit einem Verlust an Flexibilität im Entwicklungsprozeß, und letztlich auch des entstehenden Gesamtsystems einher (die Focusierung auf eine weit verbreitete Plattform eines Herstellers, und die resultierende Abhängigkeit sei hier als bekanntes Beispiel aus der Praxis eingeführt).
Ziel der Entwicklung der UML war die Bewältigung der, durch den Methodenstreit der 80er Jahre eindrucksvoll verkörperten, Heterogenität im Umfeld der objektorientierten Modellierungssprachen.
Durch die Vereinigung einiger Vorgängernotationen (im wesentlichen Boochs Wolken, der Object Modeling Technique nach Rumbaugh und Jacobsons Use-Cases) ist eine Darstellungsmöglichkeit verschiedener Problemaspekte (z.B. statische Klassenstrukturen, Interaktion und Verteilung) entstanden. Jedoch ist die UML momentan keine Sprache die sich zur Beschreibung aller Problembereiche gleichermaßen eignet; die Darstellung harter Realzeitbedingungen und Workflowmodellierung seien hier nur als zwei der bekannteren Beispiele angeführt. Wohl auch deshalb ist es der UML bisher (noch) nicht gelungen andere Modellierungs- und Spezifikationssprachen vollständig zu ersetzen. Aus diesem Grund finden oftmals in konkreten Projekten mehrere Werkzeuge und Notationen, je nach Problemstellung, Anwendung. Zwar bildet die UML einen geschlossenen Standard, jedoch ist dieser bisher nicht von allen Werkzeugherstellern vollständig umgesetzt worden. Als Resultat bieten nicht alle verfügbaren Werkzeuge die breite Palette der durch die UML angebotenen Diagrammtypen.
Sicherlich ist es zu einfach anzunehmen, die aktuelle Systementwicklung bediene sich ausschließlich objektorientierter Konzepte und Sprachen, die Intention des hier vorgestellte Formats ist (zunächst) „lediglich“ die Behebung der Heterogenität im Bereich objektorientierter Modellierungssprachen und deren Werkzeuge.
Ferner definiert die UML, die ihre Wurzeln in der (versuchten) Entwicklung einer Unified Method hat, bis heute keinen Entwicklungsprozeß (jedoch ist dessen Abwesenheit für die weiteren Betrachtungen nicht von Interesse und soll deshalb hier nicht näher beklagt werden). Nichtsdestoweniger ergeben sich aus dem Einsatz beliebiger „zeitgemäßer“ Entwicklungsprozesse Auswirkungen auf den Informationsfluß im Projekt. Als zeitgemäß soll hierbei der Aspekt inkrementeller und iterativer Entwicklungszyklen gegenüber traditionelleren, auf dem „Wasserfallmodell“ beruhenden, Ansätzen angesehen werden. Diese Entwicklungsprozesse bedingen das mehrfache Durchlaufen gleicher Entwicklungsphasen, wobei Ergebnisse aus vorangegangenen Iterationsläufen in die aktuelle Phase übernommen werden (siehe [Oes99]).
Aufgrund der Fixierung existierender CASE-Tools auf bestimmte Entwufsphasen, ist ein Modellaustausch zwischen den Iterationsphasen oftmals gleichbedeutend mit dem werkzeuggrenzenüberschreitenden Übernahme des entstandenen Designs aus vorangegangenen Entwicklungsphasen.
Zusammenfassend läßt sich festhalten: den geschilderten Szenarien ist die gewünschte zeitnahe Informationsweitergabe, konkret Übermittlung der entstehenden Modelle, innerhalb des Projekts gemein. Als Stolpersteine in der Praxis offenbaren sich der gleichzeitige und gemeinsame Einsatz verschiedener Modellierungssprachen und heterogener Werkzeuge im Systementwicklungsprozeß.
Offenkundig wäre eine homogene Landschaft aus genau einem mächigen Werkzeug, welches sich für alle Entwicklungsstadien, von den frühen Analysen bis hin zur Implementierung, gleichermaßen eignet, auf Basis einer leistungsfähigen lingua franca als Notation, die im Wortsinne die „besten“ (etwa intuitivsten, ausdrucksstärksten, ...) Ansätze vermengt, wüschenswert. Doch steckt in dieser, oft als Hemmschuh verstandenen, Heterogenität auch ein mitunter wettbewerbsdifferenzierender Freiheitsgrad, der die Kombination verschiedenster Werkzeuge und Sprachen im Projekt erlaubt.
Das OMG XML Metadata Interchange Format hat sich die Überbrückung der beiden diskutierten Heterogenitätsdimensionen, Werkzeug- und objektorientierte Modellierungssprachenlandschaft, zum Ziel gesetzt.
Standards |
Der von der OMG akzeptierte Standardisierungsvorschlag zum Stream-based Model Interchange Format (SMIF) setzt auf der eXtensible Markup Language (XML) (siehe [XML00]) des W3-Konsortiums (W3C) auf. Konsequenterweise wird die Benennung entsprechend der im XML-Umfeld üblichen Konvention fortgeführt, und das Austauschformat als neues Mitglied der XML-Sprachfamilie mit eXtensible Markup Language Metadata Interchange -- kurz XMI -- bezeichnet. Während SMIF im Aufruf zur Normungsvorschlagseinreichung die Problemstellung bezeichnet, ist XMI die letztlich verabschiedete Lösungstechnologie. SMIF und XMI sind im Prinzip synonym; im Folgenden wird jedoch das bekanntere XMI bevorzugt.
Durch die Verwendung der XML, einer Sprache des W3C, zur Festlegung eines neuen OMG-Standards werden die beiden Welten, einerseits die Standards des Web und andererseits die der Objekttechnolgie, „verheiratet“. Zum Begriff „Standard“ ist noch anzumerken, daß es sich dabei um internationale Industriestandards handelt, also Normen jenseits der staatlichen Normungsorgane wie DIN oder ANSI, mit den zugehörigen internationalen Gremien, die in der International Standardization Organization (ISO) organisiert sind.
In Abbildung 1 ist die Object Managment Architecture (OMA) dargestellt. Alle durch die OMG verabschiedeten Industriestandards fügen sich in diese Architektur ein (siehe [Sol97]).
Zentrales Element ist der Object Request Broker, die Vermittlungsinstanz der objektorientierten Middleware CORBA. Dieser programmiersprachen- und plattformunabhängige Infobus verbindet die bereitgestellten Basisdienste (Object Services), wie Peristenz- und Transaktionsmanagement, mit verschiedenen Applikationen.
Darüberhinaus wird eine Zusammenfassung weiterer, auf der OMA aufsetzender Standards, als Repository Common Facility bezeichnet. Der in der Praxis wohl bekannteste dieser Standards ist, die schon erwähnte, UML. Sie definiert, auf Basis eines gemeinsamen -- ebenfalls in UML modellierten -- Metamodells die verschiedenen UML-Diagrammsprachen (wie Klassendiagramm, Aktivitätsdiagramm, Use-Cases, ...).
Im wesentlichen stellt das Metamodell, als Teil der abstrakten Semantikbescheibung zur UML, die Beziehungen zwischen den Modellelementen (wiederum in UML) dar. Mithin sind die erlaubten Konstrukte der Modellierungssprache in der Modellierungssprache selbst beschrieben. Insgesamt betrachtet ist die Semantikfestlegung bestehend aus Metamodell und well-formedness rules die in einer formalen Sprache, der Object Constraint Language (OCL), beschrieben werden nur für Werkzeughersteller und Methodiker interessant. Während die ersteren diese abstrakte Syntaxbeschreibung quasi als Pflichtenheft übernehmen, ist sie für Methodenentwickler Ausgangspunkt weiter Überlegungen.
Meta-Ebenen |
Sicher stellt sich dem aufmerksamen Leser jetzt die Frage, wenn die UML in UML modelliert wird um die Korrektheit und Widerspruchsfreiheit sicherzustellen, wodurch wird dies für das Metamodell, welches wiederum ein UML-Modell ist, sichergestellt?
Die Antwort ist so komplex wie einfach gleichermaßen: durch ein weiteres (UML-)Modell.
Abbildung 2 zeigt die Beziehungen innerhalb der sog. Vier-Schichten Metamodell-Architektur der OMG. Ausgehend von Ebene M0, der der konkreten Daten (im Beispiel
Max M und Hans A) wird die Architektur definiert. Die Unterstreichung, und Angabe des Klassenenamens nach dem Doppelpunkt weißt unseren Max M als Ausprägung der Klasse Person aus. Der unterbrochene Pfeil, eine UML-Abhängigkeitsbeziehung, verbindet das Objekt mit seiner Klasse. Als Stereotyp (die Beschriftung an der Pfeilkante) kommt hier das in der UML vordefinierte instanceOf zum Einsatz. (siehe [UML99] S. 3-87)
Ein ähnliches Bild ergibt sich bei Betrachtung der Beziehung zwischen Person und Klasse (M1- und M2-Ebene). Analog zur unteren Modellschicht stellt auch hier die Person als konkrete Ausprägung der Klasse Klasse (der sog. Metaklasse) dar. Alle weiteren denkbaren Klassen des Modells wären ebenfalls Instanzen der Metaklasse (Buchstäblich eine Klasse die Klassen erzeugt). Mit erklimmen dieser Abstraktionsebene (M2) sind wir bereits im UML-Metamodell angelangt. Wie im objektorientierten Sprachgebrauch üblich faßt die Klasse eine Menge von strukturell gleichen (d.h. gleiche Eigenschaften, gleiches Verhalten) Objekten zusammen.
Ausgehend von der Klasse zeigt sich diese als Ausprägung der MetaKlasse einem Element des UML-Meta-Metamodells (Zutreffend sollte dieses Element mit Meta-Metaklasse benannt sein, jedoch hat es sich innerhalb der OMG eingebürgert das erste „Meta“ wegzulassen). Während das Metamodell die Anwendung der objektorientierten Konzepte in der Sprache UML zeigt, legt das Meta-Metamodell diese Konzepte fest. Im Falle der UML handelt es sich dabei um die der Objektorientierung, nämlich die gängigen Primitiven des objektorientierten Paradigmas wie Klasse, Attribut, Beziehung usw. Das gemeinsame Meta-Metamodell aller OMG Metamodelle ist in der Norm Meta Object Facility (MOF) definiert (siehe [MOF97]). Sinngemäß der Syntaxfestlegung der UML durch ihr Metamodell, legt auch das Meta-Metamodell die Syntax der zugeordneten Metamodelle fest. 1
Entsprechend der Korrektheitsprüfung eines UML-Modells durch das entsprechende Werkzeug kann auch die Korrektheit eines Metamodells geprüft und bewiesen werden.
Mithilfe des Meta-Metamodells lassen sich beliebige Metamodelle konkreter Modellierungssprachen definieren; das gemeinsame Meta-Metamodell läßt sie zu objektorientierten Modellierungssprachen (lies: Sprachen die objektorientierte Konzepte verwenden) werden. Diese Konstruktion der Metaebenen ermöglicht es verschiedene objektorientierte Beschreibungssprachen ineinander zu überführen. Ein klarer Vorteil der hierarchischen Anordnung der einzelnen Modellebenen liegt in der schrittweisen Verfeinerung der semantischen Konzepte. Hierdurch wird die Überfrachtung der letzten Modellschicht (M1) mit unnötiger Semantikdefinition (wie „Was ist eine Klasse“ und ähnlicher metaphysischer Fragestellungen) vermieden.
Für die Anwendung des Transferstandards XMI bedeutet die Vier-Schichten Metamodell-Architektur einen zusätzlichen Freiheitsgrad dergestalt, daß MOF als Basis weiterer Metamodelle genutzt werden kann (Metamodellstandards zur Workflow-und Data-Warehouse Modellierung befinden sich derzeit innerhalb der OMG in Entwicklung). XMI transportiert beliebige MOF-Instanzen, d.h. Ausprägungen eines Meta-Metamodells, was eine deutliche Erweiterung des Einsatzspektrums gegenüber einem ausschließlich auf die UML zugeschnittenen textuellen Format bedeutet. Als Resultat ist XMI in der Lage sowohl Metamodelle, gleichbedeutend mit der Syntaxdefinition einer Modellierungssprache, als auch deren Ausprägungen, die in den Modellierungssprachen erstellten Modelle, zu übertragen. Insbesondere können zukünftige Sprachen -- infolge der Abbildung ihrer Metamodelle in MOF -- ebenso problemlos als XMI-Datenstrom übertragen werden, ohne das Transferformat abzuändern oder zu erweitern.
Die in Abbildung 2 dargestellte zirkuläre Abhängigkeit des Meta-Metamodells von sich selbst (M3+) ist die pragmatische Lösung für ein „verstecktes“ Problem. Jede Modellebene der Metamodell-Architektur ist durch die darüberliegende Modellschicht prüfbar -- wie jedoch wird die Korrektheit des verwendeten Meta-Metamodells sichergestellt?
Die Meta Object Facility geht hierbei den Weg, MOF als selbstbeschreibendes Modell aufzufassen. Wie durch die Abhängigkeitsbeziehung angedeutet, ist MOF eine Ausprägung von MOF. Daher kann das MOF-Meta-Metamodell durch sich selbst auf Korrektheit geprüft werden. Deshalb spricht die MOF-Spezifikation [MOF97] an dieser Stelle auch von einem Prozeß der an die Befreiung Baron Münchhausens aus dem Sumpf (er zieht sich im Märchen an den eigenen Stiefeln (engl. boots heraus) erinnert.
Ein Beispiel |
Um die Betrachtungen auf den in der Praxis am häufigsten auftretenden Fall zu beschränken, wird im Folgenden ausschließlich der Transfer von UML-Modellen via XMI betrachtet.
Selbstverständlich ist es möglich in XMI Modelle aller angebotenen Diagrammsprachen der UML zu codieren, jedoch soll das einfache Klassendiagramm der Abbildung 3 als durchg"angiges Beispiel dienen.
Das Modell umfaßt eine Klasse (Max M) mit zwei Attributen. Das als private, d.h. nur innerhalb der definierenden Klasse sichtbare, Attribut Attrib1 ist vom einfachen Datentyp Integer, zusätzlich wird es mit einem konstanten Wert vorbelegt. Das optional mengenwertig ausgelegte Attrib2 greift rekursiv auf die vorhandene Klasse zu. Konkret handelt es sich dabei um eine benannte Sammlung von Objekten des Typs Max M.
Die Übersetzung des Klassendiagramms vollzieht sich in zweit Schritten, die mit den beschriebenen Metaebenen korrespondieren. Zunächst wird das, in der Terminologie der Abbildung 1 auf der M1-Schicht angesiedelte, Modell in „sein“ Metamodell übersetzt (siehe Abbildung 4). Der XMI-Standard definiert für alle MOF-basierten Metamodelle allgemein, und das der UML im besonderen, eine Document Type Definition (DTD). Ausgehend von dieser kann der XMI-Datenstrom ohne Hinzufügen weiterer Information erzeugt werden.
Das Diagramm der Abbildung 4 greift auf das Metamodell der UML-Sprachfestlegung (siehe [UML99] S. 6-5ff) zurück. Es enthält jedoch nur die am Beispiel beteiligten Meta-Klassen. Andere Details (ungenutzte und die Übersichtlichkeit beeinträchtigende) sind ausgeblendet.
Einzelheiten des Beispiels finden sich als Objekte vom Typ der zugeordneten Metaklasse wieder. Die zugehörigen (Meta-)Eigenschaften des Modellelements werden als Attributwerte des Metaobjekts dargestellt. Das gesamte Metamodell ist ausschließlich in Klassendiagrammen modelliert, welche die Semantik der einzelnen Sprachkonstrukte festlegen.
In erster Linie dient die dargestellte Hierarchie innerhalb des Metamodells der Zusammenfassung und Gruppierung,
aus semantischer Sicht, gleichartiger Sprachkonstrukte. So sind in der Abbildung neben den Klassen auch Datentypen generalisierbar; sie werden beide von der gemeinsamen Metaklasse GeneralizableElement abgeleitet.
Bei näherer Betrachtung der Objekte des Klassendiagramms der Abbildung 4 fällt der erste Effekt der des Einsatzes der Metamodell-Hierarchie ins Auge: die Formalisierung auch in der Modellierungssprache dargestellter Information. Als markantes Beispiel zeigen sich die Benennungen der einzelnen Elemente. Während die UML den Namen des Modellelements wie Klasse, Attribut oder des Modells selbst unterschiedlich darstellt (siehe Abbildung 3 -- als fett gedruckte Zeichenkette im Kopf des Klassensymbols, als Namen zwischen Multiziplitätsangabe und Typ im Attributbereich oder als Beschriftung des stilisierten Hängeordners -- wird dieser Sachverhalt auf Metaebene durch das immergleiche Attribut name verkörpert. Ebenso werden im graphischen Modell symbolhaft formulierte Angaben, wie die Sichtbarkeit, durch textuelle Attribute der Metaobjekte abgebildet. Zu dieser Gruppe zählt unter anderem auch der ownerScope, der festlegt ob es sich um ein Klassenattribut (graphisch durch Unterstreichung abgebildet -- im Beispiel nicht benutzt) handelt, oder ob jede konkrete Ausprägung der Klasse eigenen Speicherplatz zur Wertaufnahme zur Verfügung stellt (siehe [UML99] 2-34).
Zum zweiten überführt die Abbildung in das Metamodell vorher implizit ausgedrückte Gegebenheiten in eine offensichtlichere Variante. Gut sichtbar wird dies am Attribut isActive der Metaklasse Class. Hier wird spezifikationsgemäß der Vorgabewert gesetzt.
Metaattribute wie isRoot lassen sich einer dritten Kategorie zuordnen. Sie stellen aus dem Kontext des Modellelements ableitbare Information dar. Im Falle von isRoot, ob es sich um eine Klasse ohne Elternklassen (also das Wurzelelement einer Vererbungshierarchie handelt).
Jenseits der auf das Beispielmodell zurückführbaren Komponenten fallen zwei zusätzliche Metaobjekte ins Auge: Integer und InitValA1. Die explizite Definition des Integers als Datentyp von Attrib1 verwundet zunächst, definiert doch das UML-Metamodell bereits diesen Typ und wendet ihn zur Definition der Sprachsemantik weidlich an (siehe beispielsweise die Definition der Multiplicity [UML99] 2-75). Jedoch schlägt sich diese Festlegung nicht auf die definierten Sprachschatz nieder. Begründet wird dies üblicherweise mit der weitestgehenden Vermeidung einschränkender Definitionen in die Modellierungssprache, die den Vorgriff auf spätere programmiersprachliche Umsetzungen, bürgen. Entscheidender ist jedoch in diesem Zusammenhang die Doppelnutzung des Objekts Max M zunächst als Ausprägung der Metaklasse Class und darüberhinaus als Typdefinition des Attributs Attrib2. Eine Assoziation setzt jeweils die Typdefinition mit dem darauf basierenden Attribut in Beziehung.
Das Objekt InitValA1 verkörpert den Vorgabewert des Attrib1. Hinausgehend über die im UML-Klassendiagramme dargestellten Einzelheiten findet im Metamodell auch die Sprache, die zur Darstellung der Wertinitialisierung verwandt wird, Eingang. Das Attribut initialValue referenziert damit ein anderes Objekt (in unserem Beispiel InitValA1 das die Wertfestlegung näher beschreibt.
Ausgehend von der Darstellung des UML-Modells als Metamodellinstanzen ist die Überführung in XMI denkbar einfach. Entlang der baumartigen Hierarchie direkt umschließender Modellelemente (d.h. Beispielmodell enthält Max M welche die Attribute Attrib1 und Attrib2 vollständig umschließt) wird die im Metamodell dargestellte Information ausgegeben. Diese Betrachtungsweise wird auch gut durch die graphische Darstellung der Klassenstrukturen, wie in Abbildung 3, gestützt.
Listing 1 zeigt den vollständigen XMI-Stream des Beispielmodells, zur besseren Übersichtlichkeit sind die Zeilen numeriert. Im Vorspann wird zunächst die Identifikation als XML-Dokument vorgenommen (Zeile 1). Anschließend wird die UML-DTD referenziert (Zeile 2).
Nachfolgend beginnt der, durch den Tag XMI eingeleitete Nutzdatenbereich (Zeile 3). Zeile 5 spiegelt die vorgenommene Einschränkung als Kommentar wider. Die hier angegebenen Daten werden ungeprüft übernommen, entscheidend für die Korrektheitsprüfung ist lediglich der Verweis auf die Document Type Definition (in Zeile 2).
Beginnend mit dem Modell werden die Attribute des Metamodells abgearbeitet. Der XMI-Standard definiert Generierungsrichtlinien, welche die Gewinnung der XMI Repräsentation aus dem Metamodell festlegen. Durch diese Formalisierung wird sichergestellt, daß neue Document Type Definitionen zukünftiger Metamodelle schnell (da maschinengestützt) und eindeutig (es liegen immer dieselben Prinzipien zugrunde) generiert werden können.
Jeder Tag des entstandenen Dokuments wird zunächst durch den Namen des Metamodell-Teils eingeleitet, in dem die gerade bearbeitete Metaklasse definiert ist (ab Zeile 9); im Beispiel Foundation.Core. Daran schließt sich der eindeutige Name der Metaklasse und des Metaattributs an. Die einzelnen Komponenten des Tag-Names werden durch Punkt getrennt. Für den Metamodellkundigen entstehen aufgrund dieser durchgängigen Namenskonvention sprechende Namen. Als Beispiel sei Zeile 13 herausgegriffen: Von rechts nach links betrachtet sagt sie, ohne Konsultation des zugrundeliegenden Metamodells aus, daß ein (Meta-)Attribut isAbstract einer Klasse GeneralizableElement existiert, und diese Klasse im Package Core des Modells Foundation definiert ist (die umgekehrte Lesrichtung resultiert aus der beliebigen Schachtelungstiefe der Packages). Mit diesem Determinismus kann der für das codierte Modell relevante Bereich des zugrundeliegenden Metamodells einfach und sicher ermittelt werden. Durch den Einschluß kompletter Tags entsteht auch im XMI-Dokument eine hierarchische Struktur. Der aus der diskutierten Baumstruktur des Modells herrührende Aufbau bleibt somit auch im XMI-Strom gewahrt.
Beziehungen innerhalb der im Metamodell dargestellten Daten (Assoziationen im Metamodell) werden durch den XML-Mechanismus der idref -- ähnlich einem unidirektionalen Hyperlink -- ausgedrückt. Zunächst wird jedem Modellelement eine eindeutige Identifikation, die sog. xmi.id zugeordnet (siehe Zeilen 8, 15, 25, 50, 84), die im gesamten Dokument als Refenzankerpunkt zur Verfügung steht. Die Zeilen 47 und 79 nehmen in diesem Sinne Bezug auf die definierten Datentypen Integer und Max M. Dieser Mechanismus vermeidet Inkonsistenzen als Resultat von Mehrfachnennungen.
(1)<?xml version = "1.0"?>
(2)<!DOCTYPE XMI SYSTEM "uml.dtd">
(3)<XMI xmi.version="1.0">
(4) <XMI.header>
(5) <XMI.metamodel xmi.name="uml" xmi.version="1.3" />
(6) </XMI.header>
(7)<XMI.content>
(8)<Model_Management.Model xmi.id="i00000001">
(9)<Foundation.Core.ModelElement.name>BeispielModel</Foundation.Core.ModelElement.name>
(10)<Foundation.Core.ModelElement.visibility xmi.value="public"/>
(11)<Foundation.Core.GeneralizableElement.isRoot xmi.value="true"/>
(12)<Foundation.Core.GeneralizableElement.isLeaf xmi.value="true"/>
(13)<Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/>
(14)<Foundation.Core.Namespace.ownedElement>
(15)<Foundation.Core.Class xmi.id="i00000002">
(16)<Foundation.Core.ModelElement.name>
(17)Max M
(18)</Foundation.Core.ModelElement.name>
(19)<Foundation.Core.ModelElement.visibility xmi.value="public"/>
(20)<Foundation.Core.GeneralizableElement.isRoot xmi.value="true"/>
(21)<Foundation.Core.GeneralizableElement.isLeaf xmi.value="true"/>
(22)<Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/>
(23)<Foundation.Core.Class.isActive xmi.value="true"/>
(24)<Foundation.Core.Classifier.feature>
(25)<Foundation.Core.Attribute xmi.id="i00000003">
(26)<Foundation.Core.ModelElement.name>
(27)Attrib1
(28)</Foundation.Core.ModelElement.name>
(29)<Foundation.Core.ModelElement.visibility xmi.value="private"/>
(30)<Foundation.Core.Feature.ownerScope xmi.value="instance"/>
(31)<Foundation.Core.StructuralFeature.multiplicity>
(32)1
(33)</Foundation.Core.StructuralFeature.multiplicity>
(34)<Foundation.Core.StructuralFeature.changeable xmi.value="none"/>
(35)<Foundation.Core.StructuralFeature.targetScope xmi.value="instance"/>
(36)<Foundation.Core.Attribute.initialValue>
(37)<Foundation.Data_Types.Expression>
(38)<Foundation.Data_Types.Expression.language>
(39)simpleMath
(40)</Foundation.Data_Types.Expression.language>
(41)<Foundation.Data_Types.Expression.body>
(42)42
(43)</Foundation.Data_Types.Expression.body>
(44)</Foundation.Data_Types.Expression>
(45)</Foundation.Core.Attribute.initialValue>
(46)<Foundation.Core.StructuralFeature.type>
(47)<Foundation.Core.DataType xmi.idref = "i00000006"/>
(48)</Foundation.Core.StructuralFeature.type>
(49)</Foundation.Core.Attribute>
(50)<Foundation.Core.Attribute xmi.id="i00000005">
(51)<Foundation.Core.ModelElement.name>
(52)Attrib2
(53)</Foundation.Core.ModelElement.name>
(54)<Foundation.Core.ModelElement.visibility xmi.value="public"/>
(55)<Foundation.Core.Feature.ownerScope xmi.value="instance"/>
(56)<Foundation.Core.StructuralFeature.multiplicity>
(57)0..*
(58)</Foundation.Core.StructuralFeature.multiplicity>
(59)<Foundation.Core.StructuralFeature.changeable xmi.value="none"/>
(60)<Foundation.Core.StructuralFeature.targetScope xmi.value="instance"/>
(61)<Foundation.Core.Attribute.initialValue>
(62)<Foundation.Data_Types.Expression>
(63)<Foundation.Data_Types.Expression.language>
(64)</Foundation.Data_Types.Expression.language>
(65)<Foundation.Data_Types.Expression.body>
(66)</Foundation.Data_Types.Expression.body>
(67)</Foundation.Data_Types.Expression>
(68)</Foundation.Core.Attribute.initialValue>
(69)<Foundation.Core.StructuralFeature.type>
(70)<Foundation.Core.DataType xmi.idref = "i00000002"/>
(71)</Foundation.Core.StructuralFeature.type>
(72)</Foundation.Core.Attribute>
(73)</Foundation.Core.Classifier.feature>
(74)</Foundation.Core.Class>
(75)<Foundation.Core.DataType xmi.id="i00000006">
(76)<Foundation.Core.ModelElement.name>
(77)Integer
(78)</Foundation.Core.ModelElement.name>
(79)<Foundation.Core.ModelElement.visibility xmi.value="public"/>
(80)<Foundation.Core.GeneralizableElement.isRoot xmi.value="true"/>
(81)<Foundation.Core.GeneralizableElement.isLeaf xmi.value="true"/>
(82)<Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/>
(83)</Foundation.Core.DataType>
(84)</Foundation.Core.Namespace.ownedElement>
(85)</Model_Management.Model>
(86)</XMI.content>
(87)</XMI>
(88)
(89)
|
Zusammenfassend kann XMI als zukünftiger Standard zum objektorientierten Modellaustausch (zumindest im Umfeld der OMG Standards wie UML) angesehen werden. XMI ist nicht der erste Versuch der Etablierung eines sprach- und methodenneutralen Transferformates, jedoch deuten die breite Unterstützung der Bemühungen im Vorfeld, und erste Prototypen namhafter Hersteller, eine rasche Umsetzung an. Durch die OMG-Schirmherrschaft über den Standard ist eine werkzeugunabhängige Ausrichtung der Bestrebungen -- und damit einhergend, Gleichbehandlung der verschiedenen konkurrierend Marktteilnehmer -- sichergestellt.
Abschließend sei angemerkt, daß XMI als toolneutrale Repräsentation weitere Aktivitäten im UML-Umfeld befördern kann und wird:
Werkzeugunabhängige...
Literatur |
[MOF97] Object Management Group (Hrsg.), Meta Object Facility (MOF) Specification. Object Management Group, Framingham (USA), 1997, OMG-Dokument ad/97-08-14.
[Oes99] Bernd Oestereich (Hrsg.), Erfolgreich mit Objektorientierung -- Vorgehensmodelle und Managementpraktiken fÜr die objektorientierte Softwareentwicklung, Oldenbourg Verlag, MÜnchen, 1999.
[SMIF97] Analysis and Design Task Force, Stream-based Model Interchange Format -- Request for Proposal. Object Management Group, Framingham (USA), 1997, OMG-Dokument ad/97-12-03.
[Sol97] Richard M. Soley (Hrsg.), Object Management Architecture Guide. 3rd editon, John Wiley & Sons, New York, 1997, OMG-Dokument ab/97-05-05.
[UML99] Object Management Group (Hrsg.), OMG Unified Modeling Language Specification. Version 1.3, Object Management Group, Framingham (USA), 1999, OMG-Dokument ad/99-06-06.
[XMI98] Object Management Group (Hrsg.), XML Metadata Interchange (XMI). Object Management Group, Framingham (USA), 1998, OMG-Dokument ad/98-10-05.
[XML00] W3 Konsortium (Hrsg.), Extensible Markup Language (XML) 1.0, 2nd edition. W3C Recommendation, 2000, Dokument REC-xml-20001006.
1 Der Korrektheit halber sei angemerkt, daß es sich bei der Beziehung des UML-Metamodells zur MOF um eine lose Metamodellierung -- im Gegensatz zur strikten -- handelt, in der nicht jede Ausprägung der untergeordneten Ebene eindeutig und umkehrbar auf ein Modellelement der Elterninstanz abgebildet werden kann. Dieser Unterschied ist jedoch für den reinen Modellaustausch unerheblich.
Service provided by Mario Jeckle
Generated: 2004-06-08T12:52:00+01:00
Feedback SiteMap This page's original location: http://www.jeckle.de/modellaustausch/index.html RDF description for this page