Create a custom XMI exporter

[André Ribeiro]

Hi everyone,

I'm using Enterprise Architect (EA) to create diagrams using my own UML Profile. Now, I need to export those diagrams in a XMI format compatible with the Eclipse Modeling Framework, in order to validate the model and then generate code.
Can anyone provide me some hints how to do this?
I know that EA allows the XMI export, but the namespaces, some elements and types of EA XMI and Eclipse are different. Also I need to compute the size and position of the classes and store them in tagged values.
Is it possible to extend the already implemented XMI exporter?

Many thanks!

[Geert Bellekens]

I don't think you can change the existing xmi export, and writing one from scratch seems crazy.

What I would do is let EA create the xmi as usual, and then go in and change whatever needs changing.
It might be possible with xslt's, but since I've never used that I would probably do it in code.

Geert

[André Ribeiro]

So you suggest to generate the XMI first and then process it to make it compatible with Eclipse, right?

Thanks for answering Geert.

[qwerty]

Have you looked at the formats that EA supports? Choose Publish during the XMI export.

q.

[André Ribeiro]

Hi qwerty,

I'm using EA 7.5, but I know that EA 10 allows to export diagrams in .ecore format. I've already tried this option, but the ecore generated file doesn't contain the information I need, namely the sterotypes and tagged values defined in my UML Profile.

[Geert Bellekens]

So you suggest to generate the XMI first and then process it to make it compatible with Eclipse, right?

Yes

Geert

[qwerty]

In contrast to what Geert said, an XMI export is not too complicated. I have written (or am writing) a compiler that creates XMI from Objective C. Basically, its no wizardry. If you know the expected data format, it should be feasible. All you have to do is to write a parser for the model and some DOM or whatever object to hold and export the XMI. It took me  2 or 3 days to find out the XMI 1.1 format from what EA created. If you have a spec of your XMI format that should be done in a day.

q.

[stao]

we wrote an EMF export for our case tool eMoflon (www.emoflon.org).
Actually the export from EA generates an "intermediate" model which is transformed in eclipse to Ecore models (by our eclipse plugin).
You can download both EA Addin and Eclipse Plugin on the website.
Surely i can assisst you to write your own export or maybe provide you with code.

[André Ribeiro]

Hi stao,

Thanks for your availability.
Does eMoflon support UML Profiles?
Can you please give me some more details about how you perform the model conversion from EA to Eclipse?
My goal is basically to use EA to model diagrams using my UML Profile, because Papyrus revealed very limitations for my purpose. Then I will validate the model using EVL and generate code using Acceleo.

Very grateful!

[stao]

Does eMoflon support UML Profiles?

We have our own Ecore like UML Profile to create Ecore Metamodels in EA.

If you want to use your own UML Profile you have to implement the export yourself.

A possible solution would be to use our export mechanism (https://code.google.com/p/ea-serialization-to-tree/) to create exactly the same intermediate model (from your uml profile) we export from our EA Ecore metamodels.

You will then get the transformation to Ecore for free.

I would recommend to install our Tool, create some Ecore metamodels in EA and especially inspect the taggedvalues called "Moflon::ExportTree" located at every EClass, EDataType and so on.

These Export Trees are gathered during export and merged to one big Tree model (this is the intermediate model i mentioned).

In our Addin we have all the needed C# classes to perform the tree serialization and deserialization (e.g. EClass.cs, EDataType.cs).

Your work would be to create similar classes and implement the serialize and deserialize methods equal to our intermediate model).

Sounds a bit complicated at first but i guess it will be more efficient than to write a complete new export from scratch (especially dealing with XmlWriter junk.

I can provide you with our implementation of e.g. EClass.cs or whatever.

Here is the example of the "Moflon::ExportTree" TaggedValue of a simple EClass called ExampleEClass (check the name attribute) without EAttributes and EOperations:

Code: [Select]

<MocaTree:Node xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:MocaTree="http://www.moflon.org.MocaTree">
  <children name="EClass" index="0" xsi:type="MocaTree:Node">
    <children name="references" index="0" xsi:type="MocaTree:Node" />
    <children name="attributes" index="1" xsi:type="MocaTree:Node" />
    <children name="operations" index="2" xsi:type="MocaTree:Node" />
    <children name="etypeParameters" index="3" xsi:type="MocaTree:Node" />
    <children name="genericSuperTypes" index="4" xsi:type="MocaTree:Node" />
    <attribute name="name" value="ExampleEClass" index="0" />
    <attribute name="isAbstract" value="false" index="1" />
    <attribute name="guid" value="{14248D0A-6800-4d20-9997-45EE0C31F937}" index="2" />
    <attribute name="alias" value="" index="3" />
    <attribute name="mocaFragmentVersion" value="0.01" index="4" />
  </children>
</MocaTree:Node>

To create this tree your serialize method in C#
must look like this:

Code: [Select]

public override Serialization.MocaTree.MocaNode serializeToMocaTree()
{
      MocaNode eclassNode = new MocaNode("EClass");
      eclassNode.appendChildAttribute("name",this.Name);
      eclassNode.appendChildAttribute("isAbstract", this.isAbstract.ToString().ToLower());
      eclassNode.appendChildAttribute(Main.GuidStringName, this.EaElement.ElementGUID);
      eclassNode.appendChildAttribute("alias", this.Alias);

      MocaNode referencesNode = eclassNode.appendChildNode(EClass.ReferencesChildNodeName);
      MocaNode attributesNode = eclassNode.appendChildNode(EClass.AttributesChildNodeName);
      MocaNode operationsNode = eclassNode.appendChildNode(EClass.OperationsChildNodeName);
      MocaNode etypeParameters = eclassNode.appendChildNode(EClass.TypeParametersChildNodeName);
      MocaNode egenTypeNode = eclassNode.appendChildNode(EClass.GenericSuperTypesChildNodeName);

      foreach (EAttribute eAttribute in this.EAttributes)
      {
          MocaNode eAttributeNode = attributesNode.appendChildNode("EAttribute");
          eAttribute.serializeToMocaTree(eAttributeNode);
      }
            
      foreach (EOperation eOperation in this.EOperations)
      {
          MocaNode eOperationNode = operationsNode.appendChildNode("EOperation");
          eOperation.serializeToMocaTree(eOperationNode);
      }...

[André Ribeiro]

Thanks once again stao.
So basically from what I've read in eMoflon's Tutorial in EA you create Ecore models and not UML models, right?
How hard it would be to convert the EA diagrams using my UML profile to an Eclipse-compatible format?

[stao]

Hi André

i would say that depends highly on your EA diagrams. If they are similar to the Ecore structure it would be relatively easy.
If you dont need to store additional data inside of EA it gets even more easy.

I try to make an example:

You have created a stereotyped (from your UML profile) class called myClass1.

This type of class should be exported as an EClass.

You implement an EClass.cs file in your Addin which extends the class
MocaTaggableElement (if you want to store data in EA) or MocaSerializableElement (if you only want to serialize during export)
(Both classes are somehow explained at https://code.google.com/p/ea-serialization-to-tree/)

You implement the serializeToMocaTree method of your new c# class.
You have to build the same tree we use.

During export you iterate over your EA Model and on every occurrence of your stereotyped class you will create an Object of EClass.cs,
call the serializeToMocaTree method and add this tree on your parent tree (which should be the tree of an EPackage)

After that you have a complete moca tree which will be transformed
to Ecore by our Eclipse plugin.


A disadvantage is that you have to build up the same structure we do and your code (especially in eclipse) will be dependent on our plugin.

From my point of view i would say that its worth a try.
You can start simple with a single EPackage.cs, implement the needed method and see how far you can get.

[André Ribeiro]

Hi stao,

My diagrams consist in Class Diagrams.
I have stereotypes for classes, associations, attributes, operations and parameters.
The more complex diagrams will be the ones that have classes within classes:


So what I need to do is to implement for each stereotype a class which extends MocaSerializableElement  and implements serializeToMocaTree , right?

Thanks.

[qwerty]

OT: although your above URL shows an image it is not a direct image URL. You need to use the HTML link icon left in order people can easily open it. YABB can't.

q.

[stao]

So what I need to do is to implement for each stereotype a class which extends MocaSerializableElement  and implements serializeToMocaTree , right?

exactly.

but keep in mind: if you want to have additional features which our MocaTree -> Ecore transformation doesn't provide it becomes a bit problematically.

I don't see how your Class in Class diagrams fit to Ecore.

You can handle your additional features in java in eclipse.