[news.eclipse.modeling.mdt.uml2] Re: Preserving uuid to xmi:id mapping c

["Kenn Hussey" <Kenn.Hussey@xxxxxxxxxxxxxxx>]

Piergiuseppe,

I do think is makes sense to use UUIDs in computing differences between two 
versions of a model (indeed that's in part why they were introduced). I 
don't see a problem with using smilar (but not the same) IDs for different 
representations (e.g. UML, Ecore) of the "same" element. See my response to 
your other post regarding how to accomplish this. Basically, you need to use 
a resource implementation for your Ecore models which supports UUIDs and 
you'll need to do some post-processing once a UML model is converted to an 
Ecore model (and before the target model is saved) to set the desired IDs.

Kenn

"Piergiuseppe Spinelli" <piergiuseppe.spinelli@xxxxxx> wrote in message 
news:ef53ef1f0d4dc07897aaffcf7c389bd0$1@xxxxxxxxxxxxxxxxxx
> 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
>>>
>>>
>
>