[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.modeling.mdt.uml2] Re: Preserving uuid to xmi:id mapping converting uml2 to eCore 
Kenn Hussey wrote:

Piergiuseppe,

It isn't technically mandatory for UUIDs to be globally unique (and there's no way to enforce that), but that's certainly the spirit with which support for them was introduced. In fact, if you move an object between two resource implementations for which UUIDs are enabled, the ID for that object is preserved. The intent is that once an object has been assigned a UUID, it keeps that UUID (regardless of which resource it's attached to) until it is destroyed, regardless of how it changes over time.

Kenn

Many thanks Kenn: that's very clear and it confirms UUIDs were introduced not as a simple technicality but as true universal identifiers keeping their validity along time and versions.

So, in your opinion does it make sense to use them:
- In computing differences between two versions of a model (instead than URI fragments)?
- Preserving them in different translations of the same model (i.e. the case could be generating eCore XMI:IDs from UML UUIDs)?

And if it could make some sense (at least in some situation), what is (here you are the expert and I am asking for help) the simplest way to get that?

Again many thanks
Piero

"Piergiuseppe Spinelli" <piergiuseppe.spinelli@xxxxxx> wrote in message news:67ca18393826cdbe003eebf8851e0ebd$1@xxxxxxxxxxxxxxxxxx
Hi Kenn,
I apologize if I return again on this point, just to ask one clarification (not to argue, really just to better undertand)

You said: "Given that UUIDs are supposed to be globally unique (that's why they're useful), I'm not sure it would be a good idea to assign the IDs of UML elements to the resulting Ecore elements"

Now this made me wander a couple of things:
- does "UUIDs are globally unique" mean than every time you serialize the same uml document to different files it is mandatory to generate new UUIDs?

In my opinion this is not required, since the role of UUIDs should be to sign with an unique value, w/o any business meaning by itself, the unique identity of an element (i.e. an UML Class or Property).

So, when the same element it is serialized again & again (and this means, the same identity, even if some of its properties has been modified or its position in the document has changed) it could be right to use the same UUID since it is the only thing granting the identity of the element along the time.

Using URI fragments, instead (in my opinion, but I ask for yours), identify an elements just in a specific context and are not always able to keep its identity along the time (i.e. when some other sibling is inserted before it, or it is renamed or moved under onother package, and so on)

Finally, the unicity of an UUIDs shoud be granted just in the space of all the UUIDs: this shoud not refrain to use the same value (or a derived one) in the space of XMI:ID of its ecore translation, since (1) XMI:IDs are not UUIDs (2) they need to be unique just inside a model.

At the end, a concrete example: I've been involved in these last years, on the behalf of the bigger italian Telco, in the processes for adopting the SID (the reference model for the Telcos by the Tele Management Forum).
SID is a very (really very) large UML document that needs to be extended in order to be adopted in the real word, and it can be used in a lot of ways: one of them is as an hub in the semantic reconciliation among the different models used in the enterprise. This task requires a map between the SID entities and each matching element in the different data sources.
Now, every time the extended SID is modified (or a new version is released by the TMF), all this huge mass of work should be revisited: this would make the governance impossible in facts.
Now, if the impact analysis of a new SID version takes care of UUIDs and they are preserved across the successive versions, the job becomes possible!

As you see, this could be a very important and not "philosophical" question.
Since I have choosed Eclipse and EMF as the best among the current tecnologies to gring models and metadata, I look forward for opinions about that from you and every other guy interested in this matter.

Thanks,
   Piero



Kenn Hussey wrote:

Piergiuseppe,

Given that UUIDs are supposed to be globally unique (that's why they're useful), I'm not sure it would be a good idea to assign the IDs of UML elements to the resulting Ecore elements (although it would be possible by calling the conversion utility programmatically, using a custom resource to load the Ecore model, and setting the XMI IDs of the Ecore elements based on the UML element on which they were based). I would suggest producing a mapping from UML element URI fragment (GUID) to Ecore element URI fragment (name-based path) by processing the map that is returned after the conversion and doing a reverse look-up to assign the desired IDs to UML elements if/when the Ecore representation is ever converted back to UML...

Kenn

"Piergiuseppe Spinelli" <piergiuseppe.spinelli@xxxxxx> wrote in message news:66dcd6dc89d0595eed9e551934c1185b$1@xxxxxxxxxxxxxxxxxx 
Hi,

I'm building an EMF based Eclipse application and I am currently using the existing UML to EMF converter from the ide.

How can I preserve the uuids in the original uml file forcing them to be the xmi:id of the generated EClasses, and EStructuralFeatures?

My UML tool assures to preserve the same uuid for the same element (even if it is, let's say, moved to another package) across different exports, so using uuids it is possible to perform more accurated comparisons of generated eCore models that, i.e., do not exange a moving operation for two unrelated operations (delete of the existing element and creation of a new one).

Thank for any help