The UML DTD and what is needed

As the GXL code of the representing schema graphs is familiar now, the XMI code, the UML case tools are storing in their exported files, has to be considered. The previous page xmi/the_basics gave only a very granular overview of the XMI construct - among other things, the page shows the ability of XMI for supporting multiple metamodels, all derived from the MOF metametamodel. One of these metamodels is the sublanguage that is defined by the UML DTD, and can be handled by most of the UML case tools.

The following four examples show the XMI constructs, which are used for building a UML class diagram, describing a GXL schema. All possible constructs can be built as combinations out of these four examples, therefore no special part of the a schema is shown, but only these basic parts. It has to be mentioned here that not all XMI elements respectively their sub-elements, derived from the UML DTD, need to be present in every XMI file. If the information is the default value, the element may be left out.

1) Classes

Every XMI code, derived from the UML DTD, is split into two parts: the header (<XMI.header>) and the content (<XMI.content>). The header contains information about the tool, it is exported by, the meta model and its version (<XMI.metamodel xmi.name="UML" xmi.version="1.3"/>). 

The content part (<XMI.content>) contains mainly the model, which is designed in the UML case tool - therefore, the highest level of the hierarchy. In this case, this is the management model (<Model_Management.Model>), which has as every other element in this part an ID (xmi.id="xmi.1") and an unique ID (xmi.uuid="-119--63--45--20-b34b1:e806184ce1:-8000"). Additionally to that, the element has, as all following sub-structures, a name sub-element (<Foundation.Core.ModelElement.name>) and some further information about itself (e.g. <Foundation.Core.ModelElement.isSpecification xmi.value="false"/>).

The upper three classes, which are used in the class diagram for defining nodes in the corresponding GXL schema, can be identified as classes (<Foundation.Core.Class>) in the XMI code, too. As already explained, these classes contain an ID, an unique ID, name sub-element and some more information like the model. Furthermore, such a class has a child element (<Foundation.Core.ModelElement.namespace>), which contains a reference to the ID of the parent element of the class (<Foundation.Core.Namespace xmi.idref="xmi.1"/>).

2) Stereotypes

Normally, classes are used for defining nodes in the corresponding GXL schema, as it is described above. But for giving a class a special role, it is possible to derive these classes from stereotypes, as it is done in the upper picture. It shows the three possible kinds of stereotyped classes, XIG is able to recognize and transform: the graph, edge and rel extended classes. The XMI code for the normal classes (<Foundation.Core.Class>) is nearly the same as above - only the contents of the name elements (<Foundation.Core.ModelElement.name>) have changed, wherefore the already known code is faded out. 

A look at a stereotype element (<Foundation.Extension_Mechanisms.Stereotype>), which has the same owner (<Foundation.Core.Namespace.ownedElement>) as the class elements - the management model (<Model_Management.Model>), shows that it has only an ID and no unique ID. Compared to normal classes, the stereotype can additionally contain a base (<Foundation.Extension_Mechanisms.Stereotype.baseClass>) - in this case Class, which limits the use of it to normal classes. The reference to the ID of the parent element of the class is contained in the same child element again, but ID references to extended elements (in this case to the single classes) are stored, too, and can be found as attributes in the sub-elements (<Foundation.Core.ModelElement xmi.idref="xmi.3"/>) of the extension element (<Foundation.Extension_Mechanisms.Stereotype.extendedElement>).

3) Associations

Associations (<Foundation.Core.Association>) are, as classes and stereotypes, stored as first level children of the management model. In UML class diagrams defining GXL schemata, they are used for describing normal edges and are part of extended edges or relations (please reference gxl/gxl_graphs for further information here).

The first part of the corresponding XMI fragment shows the same features as the associations simple class counterpart. The more interesting information can be found in the connection child element of the association (<Foundation.Core.Association.connection>), which contains the two ends of the association as children (<Foundation.Core.AssociationEnd>). It has to be mentioned that these association ends have an ID of their own (e.g. <Foundation.Core.AssociationEnd xmi.id="xmi.5">).

The upper association represents a directed edge - this information can be found in the navigability information (<Foundation.Core.AssociationEnd.isNavigable>) of the association ends. If both association ends are navigable (xmi.value="true"), the edge is undirected, if one end is not navigable, the edge is directed (two non navigable ends are not allowed - in this case, XIG throws an error). In the shown example, the edge is directed from class1 to class2 (the target is stored in <Foundation.Core.AssociationEnd.type>), wherefore the association end at class1 (<Foundation.Core.Classifier xmi.idref="xmi.2"/>) is not navigable (<Foundation.Core.AssociationEnd.isNavigable xmi.value="false"/>) and the association end at class2 (<Foundation.Core.Classifier xmi.idref="xmi.3"/>) is navigable (<Foundation.Core.AssociationEnd.isNavigable xmi.value="true"/>).

The ordering information of the association end is stored in the ordering element (<Foundation.Core.AssociationEnd.ordering>), at the same level as the navigability information. Only two values are allowed here: ordered (xmi.value="ordered") and unordered (xmi.value="unordered") - if no value is set in the UML case tool, the XMI code may not contain the element, as in the second association end.

The multiplicity of an association end is contained by the multiplicity sub-element (<Foundation.Core.AssociationEnd.multiplicity>). But the information about the lower and upper border is not stored there, it is set in fourth-level sub-elements (<Foundation.Data_Types.MultiplicityRange.lower> and <Foundation.Data_Types.MultiplicityRange.upper>). It should be noticed here that the descendants of the multiplicity element own two IDs themselves.

4) Attributes

Every class is able to carry an unrestricted amount of attributes. At the moment, XIG is able to recognize and transform the atomic types and the locator type of the GXL Attribute Model. Two kind of attributes have to be distinguished in terms of their realization in XMI here. On the one hand, there are the attribute types XMI respectively the UML DTD knows - these are built as data type elements (<Foundation.Core.DataType>), on the other hand, there are the attribute types, which are unknown to the definition - these are built as unvisible classes (<Foundation.Core.Class>). Both types are structured in the same way as normal classes and do not need further explanation here.

More interesting is the implementation of the attributed class; the first part is built as described above and is not mentioned any more, but this class contains a new sub-element - the classifier feature element (<Foundation.Core.Classifier.feature>), which contains the ID references to the used attributes and their names. 

The single attributes are stored separately in special attribute sub-elements, containing an own ID again (<Foundation.Core.Attribute xmi.id="xmi.3">). The name of the element is set by the already known name element (e.g. <Foundation.Core.ModelElement.name>float_attr</Foundation.Core.ModelElement.name>). Additionally to the standard reference to the elements owner (<Foundation.Core.Feature.owner>) in the first classifier element, the attribute element contains a sub-element, which describes the type of the attribute (<Foundation.Core.StructuralFeature.type>) - this is nothing else than a classifier reference (e.g. <Foundation.Core.Classifier xmi.idref="xmi.4"/>) to the class or data type, the attribute is derived from.