Question Answer Logo

Question Answer

Explain XMI key components in detail?

Key Components of XMI (XML Metadata Interchange)

XMI (XML Metadata Interchange) is a standard format by OMG for exchanging models and metadata as XML. It is commonly used to serialize UML, MOF-based models, and EMF/Ecore models so they can be shared across tools and platforms. Below are the essential components of an XMI file explained in simple, exam-friendly terms with a small example.

1) XMI Root and Namespaces

  • Root element: Most documents start with xmi:XMI as the top-level container.
  • Namespaces: XML prefixes map elements to their metamodels (for example, uml: for UML, ecore: for Ecore, or a custom prefix). Common namespaces include:
    • xmlns:xmi – the XMI namespace
    • xmlns:xsi – XML Schema Instance, used for types
    • xmlns:yourMeta – your model’s metamodel namespace (e.g., UML/Ecore/custom)
  • Versioning: Some files include xmi:version to indicate the XMI version used.

2) Model Root Element

  • The actual model content is inside a root element from the metamodel, such as uml:Model or ecore:EPackage (or your own metamodel’s root like ex:Package).
  • This root usually contains packages, classes, data types, and other model elements.

3) Unique Identifiers

  • xmi:id: Every model element typically has a unique xmi:id. It lets other elements reference it reliably.
  • Some tools may also use xmi:uuid or stable IDs to make references robust across files.

4) Types and Metamodel Binding

  • Each element belongs to a type defined in a metamodel (e.g., uml:Class, ecore:EClass).
  • xmi:type or xsi:type may be used to specify the exact metamodel type when the element name is generic (e.g., packagedElement with xmi:type="uml:Class").

5) Containment vs. References

  • Containment (composition): Owned elements are nested as children in XML (e.g., a Class contains attributes).
  • Non-containment references: Links to other elements are stored as references using an ID or an href URI; the referenced element is not nested at that point.

6) Attributes and References (Features)

  • Attributes: Primitive values like names, visibility, multiplicity, etc., serialized as XML attributes or child elements.
  • References: Connections to other elements (e.g., an attribute’s type referencing a data type or class).
  • In UML/Ecore, you will see features such as ownedAttribute, ownedOperation, eAttributes, or eReferences.

7) Cross-Document Linking (href)

  • Elements can reference content in other XMI files using href with a URI, often including a fragment after # to point to a specific element.
  • Example: href="types.xmi#//String" points to an element named or located as //String inside types.xmi.

8) Packages and Namespaces in the Model

  • Models are organized into packages; in UML, these are usually serialized via packagedElement.
  • Packages group related classes, data types, and associations and provide namespace scoping.

9) Profiles, Stereotypes, and Tagged Values (UML)

  • UML Profiles extend the UML metamodel with stereotypes and tagged values.
  • Applied stereotypes are serialized using the profile’s namespace; tagged values appear as features under that stereotype instance.

10) xmi:Extension (Tool-Specific Data)

  • xmi:Extension allows tools to include extra, non-standard information without breaking other tools.
  • Tools that do not understand these extensions can typically ignore them safely.

11) Diagram Information (Optional)

  • Layout and diagramming data are usually stored in a separate notation/diagram namespace (e.g., “notation” or DI files), not in core UML elements.
  • This keeps the logical model (classes, relationships) separate from visual details (positions, colors).

12) Validation and Schemas

  • XMI content can be validated against schemas of the metamodel (e.g., UML/Ecore schemas).
  • Using xsi:schemaLocation helps tools locate the correct schemas for validation.

Minimal XMI Example (Annotated)

<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI
  xmlns:xmi="http://www.omg.org/spec/XMI"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:ex="http://example.com/metamodel">

  <!-- Root model element from a custom metamodel -->
  <ex:Package xmi:id="pkg1" name="university">

    <!-- Contained class (composition) -->
    <ex:Class xmi:id="cStudent" name="Student">

      <!-- Attribute owned by the class; the 'type' references a datatype -->
      <ex:Attribute xmi:id="aName" name="name" type="dtString"/>

      <!-- Reference to another class using its xmi:id -->
      <ex:Reference xmi:id="rAdvisor" name="advisor" target="cProfessor"/>
    </ex:Class>

    <!-- Another class that can be the advisor target -->
    <ex:Class xmi:id="cProfessor" name="Professor"/>

    <!-- Local datatype used by the attribute above -->
    <ex:DataType xmi:id="dtString" name="String"/>

    <!-- Example cross-file reference to a shared type library -->
    <ex:Attribute xmi:id="aId" name="id">
      <ex:type href="types.xmi#//UUID"/>
    </ex:Attribute>

  </ex:Package>

  <!-- Optional tool-specific info that others can ignore -->
  <xmi:Extension extender="SomeTool">
    <ex:Color theme="light" accent="blue"/>
  </xmi:Extension>

</xmi:XMI>

How to Read/Explain an XMI in Exams

  1. Identify the root xmi:XMI and list namespaces.
  2. Locate the model root (e.g., Package or Model).
  3. Note unique IDs (xmi:id) for elements.
  4. Separate containment (nested elements) from references (ID or href links).
  5. Check attributes vs. references: primitive values vs. links to other elements.
  6. Look for cross-file href references and any xmi:Extension blocks.

Quick Summary

  • XMI uses XML to serialize models so they can move between tools.
  • Core building blocks: namespaces, root model element, xmi:id, types (xmi/xsi:type), containment, references, and optional extensions.
  • UML-specific additions include profiles, stereotypes, and tagged values; diagram info is usually separate.