Eclipse Community Forums: QVT-OML » Keeping xmi:id for migration

Home » Modeling » QVT-OML » Keeping xmi:id for migration

Keeping xmi:id for migration [message #1719406]

Thu, 07 January 2016 11:43

Eclipse User

Dear all,

I am new to the QVTo world.

I am facing a difficulty in the SysML composant of Eclipse papyrus project.
I would like to develop a qvto for migrating my initial sysml model in SysML1.1 metamodel into SysML1.4.

First at all: XMI:ID and URI
I would like to keep the initial xmi:id / uri of my initial elements? or do I need to implement a blackbox?

Secundly: switching namespace
The majority elements of the source metamodel have a direct linked with the target metamodel. The only differences is the namespace uri...

So if I have initial element of type Requierement in the namespace SysML 1.1,
is their a qvto transformation/function to switch it directly into a second namespace, (also Requirement but in SysML 1.4 namespace), keeping everything else?

Thanks for your idea.

Francois

Re: Keeping xmi:id for migration [message #1719492 is a reply to message #1719406]

Fri, 08 January 2016 05:50

Eclipse User

Hi

xmi:ids are an artefact of XMI serialization of your model. If you
persisted your model in a database there might be no xmi:ids to worry about.

xmi:ids are not part of your model and so model transformation tools
ignore them (trash them).

It is possible to use blackboxes to escape to Java and access / enforce
an xmi:id. These facilities might already exist.

However since xmi:ids are not a modeling concrept, it seems a mistake to
pollute the transformation.

-----

IMHO the best approach is to have a deterministic xmi:id generator.
Attached is one of the files for QVT 1.3 whose xmi:ids are auto-generated by

GIT\org.eclipse.qvtd\plugins\org.eclipse.qvt\src\org\eclipse\qvt\tools\Ecore2UML.java

This is invaluable since it ensures that after a *.ecore update the
*.uml has stable xmi:ids and so the Papyrus diagrams are affected only
by the changed parts of the model.

NB the above xmi:id generator is simplistic since the complexity of the
UML in the QVT metmodels is limited.

-----

Another approach that I take, when using UML as my source models, is to
re-assign all the accidental xmi:ids from Papyrus / UML2 so that my
subsequent toolchain sees stable xmi:ids.

See for instance

GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\src\org\eclipse\ocl\examples\build\utilities\IdAssigner.java
GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.build\src\org\eclipse\ocl\examples\build\utilities\UMLIDAssigner.java
GIT\org.eclipse.ocl\plugins\org.eclipse.ocl.pivot.uml\src\org\eclipse\ocl\pivot\uml\internal\utilities\UMLXMIID.java

-----

Imposing algorithmically determinate xmi:ids gives you control and some
immunity to metamodel changes such as SysML. But beware that generating
determinate and distinct xmi:ids for the most obscure possibilities of
overloaded operations with nested templates types is non-trivial.

Unfortunately most users only discover the benefit of determinstic
xmi:ids after a legacy of models using indeterminate xmi:ids has been
established.

An alternative approach is to just use the *.qvttrace file from the
transformation execution to identify the input/output pairing. It is
probably less than 20 lines of Java to get all the input xmi:ids and
poke them on to the outputs.

Regards

Ed Willink

On 07/01/2016 16:43, Francois Le Fevre wrote:
> Dear all,
>
> I am new to the QVTo world.
>
> I am facing a difficulty in the SysML composant of Eclipse papyrus
> project.
> I would like to develop a qvto for migrating my initial sysml model in
> SysML1.1 metamodel into SysML1.4.
>
> First at all: XMI:ID and URI
> I would like to keep the initial xmi:id / uri of my initial elements?
> or do I need to implement a blackbox?
>
> Secundly: switching namespace
> The majority elements of the source metamodel have a direct linked
> with the target metamodel. The only differences is the namespace uri...
>
> So if I have initial element of type Requierement in the namespace
> SysML 1.1, is their a qvto transformation/function to switch it
> directly into a second namespace, (also Requirement but in SysML 1.4
> namespace), keeping everything else?
>
> Thanks for your idea.
>
> Francois
>
>
>
>

Attachment: QVTOperational.xmi
(Size: 41.97KB, Downloaded 304 times)

Re: Keeping xmi:id for migration [message #1719507 is a reply to message #1719492]

Fri, 08 January 2016 08:22

Eclipse User

Thanks a lot for your quick answer.
I will take time to understand everything since I am newbie.

Nevertheless I have huge difficulty to understand that xmi:id are not part of the model.

If I have two models, MA and MB, store in two xmi file MA.xmi and MB.xmi, where inside MB, bObject references a aObject.
The serialzation will put in MB.xmi a reference to the aObject through its xmi:id , isn't it?
So for me xmi:id were key elements...because they ensure unicity across models.

So My concern is :

if I made a qvto to transform any model of sysml11 metamodel to a compliant sysml14 metamodel without managing xmi:ids,
and if people used it to transformat a initial set X11 of sysml11 models into a X14 set of models in sysml14 at a given time.
then a second group of people Y with a secund set of sysml11 models that reference the initial set of sysml11 models, their models will not work ever even if they use the qvto transformation. because I cannot ensure that xmi:id are not the same...

I will look deeply into your code links.

Francois

Re: Keeping xmi:id for migration [message #1719539 is a reply to message #1719507]

Fri, 08 January 2016 12:35

Eclipse User

Hi

Your problem is quite common.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=485439 raised.

Regards

Ed Willink

On 08/01/2016 13:22, Francois Le Fevre wrote:
> Thanks a lot for your quick answer.
> I will take time to understand everything since I am newbie.
>
> Nevertheless I have huge difficulty to understand that xmi:id are not
> part of the model.
>
> If I have two models, MA and MB, store in two xmi file MA.xmi and
> MB.xmi, where inside MB, bObject references a aObject.
> The serialzation will put in MB.xmi a reference to the aObject through
> its xmi:id , isn't it?
> So for me xmi:id were key elements...because they ensure unicity across
> models.
>
> So My concern is :
>
> if I made a qvto to transform any model of sysml11 metamodel to a
> compliant sysml14 metamodel without managing xmi:ids, and if people used
> it to transformat a initial set X11 of sysml11 models into a X14 set of
> models in sysml14 at a given time.
> then a second group of people Y with a secund set of sysml11 models that
> reference the initial set of sysml11 models, their models will not work
> ever even if they use the qvto transformation. because I cannot ensure
> that xmi:id are not the same...
>
> I will look deeply into your code links.
>
> Francois
>

Previous Topic:	[QVTo] Transform an object by a condition.
Next Topic:	QVTo standalone: EMF package registries w/o maven/testng?

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 14:00:20 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter