MI is the standard that everyone has heard about but few are sure what to do with. Beginning with this article, I will demonstrate some interesting value-added ideas on the use of this standard. In future articles I will use XMI to grab information about assets from UML diagrams, put hardware from a database back into a UML diagram, trace from one UML diagram to another, and a few other interesting tricks. But before we get to that, this first article will look at XMI in its raw form, as an XML document, and break down some of the key structural elements.
What is XMI?
XMI stands for XML Metadata Interchange and is the official OMG specification for exchanging model information between modeling tools and repositories. Version 1.0 was anointed in June 2000 and the current version 2.0 was released May 2003. As a standard, XMI is part of OMG's MOF, and is thereby connected to the other MOF-related standards, such as UML and MDA. (Note: the versioning for UML and XMI are independent of one another. The current version of XMI was originally used for UML 1.4.)
XMI is an XML standardwhich is where the fun begins. Like any XML standard, XMI can be viewed in a normal text browser; it is human-readable. It can be read by other modeling tools and saved as an XML document, or it can have its elements added to a database. It can do all of this without any special tools, other than a modeling tool and a compiler.
For the examples in this article, I will use Enterprise Architect 5.0 from Sparx Systems, a leading UML tool. I chose it for its ability to export XMI files diagram-by-diagram. In previous articles on DevX I've used MagicDraw 8.0, which is a great tool for graphics but stores the entire project as one XMI file making it more difficult to work with smaller examples.
|Figure 1. UML Representation for a Server: This is referred to as a node. The stereotype <<pc server>> identifies the node as a PC Server.|
I'll start with a simple example. Figure 1
shows a leasing server, named "Leasing," which is stereotyped with "<<pc server>>" to identify it as a server. The box represents the UML version of a piece of hardware, usually a client PC or a server PC. The square on the outside is a UML 2.0 convention identifying and surrounding all of the elements in a model.
One way to look at XMI is as a method for serializing UML diagrams. Each UML element can be represented as text, stored and read back into the modeling tool, added to, and stored again as text. This is very similar to the process of serializing an object as a SOAP message and then rehydrating it.
An XMI document consists of three disparate sections. The first section is the header section containing information about the versions of the standards and the tool that created it.
Section #1. Header Section for an XMI Document
<?xml version="1.0" encoding="windows-1252"?>
<!DOCTYPE XMI SYSTEM "UML_EA.dtd">
<XMI xmi.version="1.1" xmlns:UML="omg.org/UML1.3" timestamp="2005-08-09 22:09:24">
This code above is validated by the UML_EA.dtd as indicated by the DOCTYPE tag, which validates that the rules for UML are followed. (The DTD file is one of the methods that XML uses to validate whether an XML document is correct or not. This document must be in the same directory as the model.) This model uses XMI version 1.1 to represent a UML version 1.3 model.
|Author's Note: Notice that the version of Enterprise Architect is listed as "2.5," but in reality the version I used was 5.0; even weirder is that this version will change depending upon the version of UML being serialized. In MagicDraw the exporter version matches the product version.
Section #2: Model Section for an XML Document
The second section represents the UML model. This is where the logical information is stored. This section contains the information that I will use to capture the names and attributes of the different assets that I model.
<UML:Model name="EA Model" xmi.id="MX_EAID_0DE50B6C_9EF5_492d_8D81_45B0B8A68599">
isRoot="true" isLeaf="false" isAbstract="false"/>
<UML:Package name="Deployment Model"
isRoot="false" isLeaf="false" isAbstract="false" visibility="public">
isRoot="false" isLeaf="false" isAbstract="false">
<UML:Stereotype name="pc server"/>
In the code above, notice that the namespace UML defined in the header is used for each of the elements. For my purposes the first couple of elements are not important. The critical piece of the model is the UML:Node element. Each element has a unique ID, xmi.id, across all XML documents. (The XMI standard defines two different IDs, one unique to the document and one that is globally unique, but most modeling vendors only use one ID).
Visibility is the logical visibility of the UML element, which is similar to how "public" is used in a programnot how the node is displayed. The stereotype "<<pc server>>" is represented as an encapsulated element of the UML:Node.
Section #3: Displaying the Model
The third section is how the model is displayed by a modeling tool. Different modeling venders define these sections differently. Enterprise Architect uses the UML:Diagram namespace to describe where the UML elements are displayed and in what style. It also includes special Enterprise Architect-specific information that can be exported to the XMI document. MagicDraw relies on the XMI.extensions tag (extensions that can be used or ignored by other modeling tools) because, instead of exporting XMI as Enterprise Architect does, it uses the XMI file as its native format for models. Enterprise Architect has its own proprietary native format.
<UML:Diagram name="Deployment Model"
toolName="Enterprise Architect 2.5">
<XMI.extensions xmi.extender="Enterprise Architect 2.5"/>
The code above includes a UML:Diagram.element that has attributes for the geometry (where the node is located in the diagram, and the ID of the style used for display). The last element of interest is the XMI.extensions which will contain XMI extensions for modeling tool specific information.