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 standard?which 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.
| Author’s Note: The only book on the market for XMI is a Java-based book, Mastering XMI: Java Programming with XMI, XML, and UML (OMG Press), co-written by one of the authors of the XMI standard, Stephen Brodsky. |
UML Serialized
 |
|
| Figure 1. UML Representation for a Server: This is referred to as a node. The stereotype < |
I’ll start with a simple example. Figure 1 shows a leasing server, named “Leasing,” which is stereotyped with “<
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
Enterprise Architect 2.5 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.
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 program?not how the node is displayed. The stereotype “<
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.
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.
Adding UML Tags
For the example in this section I added some tags describing the server’s attributes (see Figure 2).
If you look at the XMI listing (shown below) you’ll find it the same as it was before with the addition of the UML:TaggedValue elements. The tag attribute and value matches the UML tags one for one. Each element also has its own unique ID.
 |
|
| Figure 2. Tags for the Leasing Server. In this case the Leasing Server is a Compaq server with an Intel Xeon processor, 1GB of internal memory and 80GB of disk storage. |
The key attribute to notice is the modelElement attribute, which is the unique ID of the node that the attribute is applied to. Even if there are two nodes with the same tags each node will have its own XMI elements. Any modeling tool that supports the same version of XMI model should be able to import these attributes.
Adding Inheritance
In larger server environments or when modeling disaster recovery it’s useful to deal with a typical model and then declare instances of that server. In a typical configuration, the Leasing server in this example may represent one or more other servers, each having the same UML tags. In this case (see Figure 3), Fleet Management is an instance of a server that is a Leasing type of server, where each instance is a Compaq Proliant DL380 server with 1GB of memory, 80GB of hard disk space, and with a Xeon 3.6 GHz processor.
 |
|
| Figure 3. An Instance of the Leasing Server. Fleet Management is one of the Leasing servers with each server being the same machine type, memory size, have the same processor and disk space. |
One use for inheritance in modeling is for virtual servers such as VMWare. VMWare is a tool where each software VM instance is treated as if it were a separate client or server. In testing it is common to run different tests on the same machine configurations. VMWare will have multiple virtual machines with the same configuration for each test instance.
The original VMWare machine might be called Master Tester and could be modeled the same as the Leasing Node. Each instance using Master Tester as its base would be modeled the same as the Fleet Management node but with a unique name.
In the XMI file above the two UML nodes are represented by the same type of element. In other words there is no difference between the node instance and the node! Enterprise Architect provides the answer. When the XMI is generated in Enterprise Architect, non-standard tags can also be generated to help identify a node instance. Here are the Enterprise Architect-specific elements:
In the code above, the tag TaggedValue is added under the Fleet Management node. The tag attribute and its value is the ID for the Leasing node from which it inherits the UML tags. Another UML:TaggedValue adds the original node’s name. By using these tags I can navigate between a node instance and its associated node by attaching the same UML tags to each node instance. In the case that a node instance does not have a node to refer to, Enterprise Architect will create a default node in the diagram. MagicDraw has different XMI tags for node and node instances and a tag classifier that refers to the ID of the node for a node instance.
Adding Links Between Nodes
In deployment diagrams the servers all have connections between them. In UML we refer to these connections as links. The link is the physical connection between two pieces of hardware. Each link usually contains the protocol used to pass information between the two machines (see Figure 4).
 |
|
| Figure 4. The Link between Selling and Leasing. Notice that the link has a stereotype < |
A Link is modeled as an association with two endpoints and represents the physical link between the two servers. In this example the only name the association has is xmi.id. Associations can be named but for the most part they aren’t. Notice in the code below that the type for each AssociationEnd is the GUID for one of the servers.
The stereotype <
So there you have it?the 15-minute explanation to XMI. The unfortunate part of learning XMI is that there is so little information about it that one must poke around the XMI files a bit, adding different UML elements and associations, in order to learn. Even the standard doesn’t help, but if you’re interested, all the versions of the standard are available at the OMG Web site. But don’t worry. I will delve further into XMI in subsequent articles on DevX. Stay tuned.
