XMILinker


Introduction

The basic job of any program linker is simple: it binds abstract names to more concrete names,
which permits programmers to write code using more abstract, higher--level names. The idea
of an XMI linker is very similar. But instead of programs, we can talk about linking models.
The XMI linker takes a set of input XMI files and produces one XMI output file. Each
XMI file contains metadata model elements. Some model elements are exported defined; that is,
they are defined within the model for use with other models. Other model elements are imported -
used in the model but not defined. Finally, a code generator uses the linked model as XMI input
and generates differend kinds of source code output files, depending on the generator stylesheets.
The XMILinker is based on XSLT.

Required Software

To build and run XMILinker you need a copy of the Java 2 Plattform, Standard Edition 1.4.1.
This runtime environment contains the neccessary XML parser and XSL Transformer. Additional
it is possible to install a newer version of the XALAN XSLT-transformer,  which can be downloaded
from http://xml.apache.org/xalan-j.

Usage

    java -jar XMILinker.jar [{-o,-output} filename] [-v] [-c] (modelname)+


    Options:

        -h, --help
                Prints the help
        -o, --output <argument>
                The XMI output file name
        -r, --report <argument>
                Generates an html report file without linking
        -v, --view
                View the result
        -c, --convert
                View the result
        -d, --debug
                Debug mode - does not delete intermediate files

   An Example:

          java -jar XMILinker.jar -o Result.xml ModelA.xml ModelB.xml ModelC.xml

   An example report see Report.xml.
  

Modeling Guidelines

In UML no standard mechanism exists to indicate externally defined model elements. So we
introduce a new stereotype called <<extern>> to define such model elements. It is possible
to define classes, packages, relationships model elements as external. It is also possible to
have nested external and internal model elements, for example an internal class in an external
package.

   
                 Figure 1:  Unique Identifiers


Modeling extern classes

Modeling extern classes will be done with the stereotype <<extern>>.  The unique  identifier
of each extern or intern class is a concatenation of package- and class name.

In Figure 1 the two classes are unique identified through the names:

     packageA.packageAA.ClassA
     packageA.packageAA.ClassB

We do not use the xmi.id or xmi.uuid (see XMI specification).

Modeling extern packages

Modeling extern classes will be done with the stereotype <<extern>>. All packages are unified
through a concatenation of the package names.

In Figure 1 the packages are unfied identified through the names:

     packageA
     packageA.packageAA.ClassA
     packageA.packageAA.ClassB

We do not use the xmi.id or xmi.uuid (see XMI specification).

Modeling extern associations

Modeling extern asscoiations will be done with the stereotype <<extern>>. All binary associations
(intern or extern) are unified through the concatenation of role-, namespace- and classname
of classA and the role-, namespace- and classname of classB of a binary association. The
association namespace is unimportant for the XMILinker.

In Figure 2 the associations are unfied identified through the names:

    roleA:nsA.nsAA.ClassA:roleC:nsB.nsBA.ClassC
    roleB:nsA.nsAB.ClassB:roleD:nsB.nsBB.ClassD

              
                Figure 2: Unique Association IDs      


An Example:

    Input: 4 XMI-Class File diagram


ComponentA.xml
              Figure 3: ComponentA.xml



ComponentB.xml
              Figrue 4: ComponentB.xml


ComponentC.xml
             Figure 5: ComponentC.xml





Checking unresolved and multiple defined references

It is possible that modeler defines modelelements extern, that does not exists in any other
model. Additional it is also possible that modelelements are multiple defined. Both situations
results in errors. XMILinker allows the user to check this situations with the report option (-r):


   java -jar XMILinker.jar -r Report.html componentA.xml componentB.xml componentC.xml


As result we get an HTML error report.

Restrictions

In the moment the XMILinker is based on UML1.4 and MOF 1.0. It should
not be a problem at all to change the stylesheets to process MOF 1.4 and UML 1.5.

Tested

XMILinker is currently tested with MagicDraw 5.5i, stored in XMI 1.0 running under
Linux and Windows with JDK 1.4.1 and JDK 1.4.2b.

Downloads


       XMILinker.jar  XMILinker.jar - XMILinker V1.0 (MOF 1.0, UML 1.4)

       XMILinker.jar  XMILinker-src.zip - XMILinker V1.0 Source (MOF 1.0, UML 1.4)
      
       XMILinker.jar Examples.zip - MagicDraw 5.5i tested example files  




Author

Stefan Mitterdorfer (stefan.mitterdorfer@tugraz.at)