| Mixing UUIDs and positional identifiers in one model [message #1852659] |
Mon, 30 May 2022 13:40  |
 Jan-Philipp Steghöfer
Messages: 12
Registered: May 2019 |
Junior Member |
|
|
Hey there,
I have recently switched the models of the Eclipse Capra project to use xmi:id to identify model elements. Previously, Eclipse Capra used the positional information to identify elements in other models. For instance:
<source href="artifactWrappers.xmi#//@artifacts.9"/>
has turned into:
<source href="artifactWrappers.xmi#_vMX68djjEeyw9s6Xboqnpw"/>
I did this via overwriting useUUIDs() in a custom XMIResourceImpl descendent as described in many places. A small script creates the UUIDs for existing models and replaces the positional reference with the new UUID. This all works as expected.
However, an interesting side effect of this is that Eclipse Capra is now enforcing the use of xmi:id-based references everywhere, including to models that do not contain xmi:ids. Since Eclipse Capra is a traceability tool, we have limited control over how other models are structured and whether they contain UUIDs or not. But since the model that contains the traceability links is loaded into a resource that enforces the use of UUIDs, all references to models which do not use UUIDs are now broken.
This is completely rational behaviour on EMF's part. Since we are loading all EMF models into the same resource in order to be able to establish the references, it is clear that EMF is enforcing the use of UUIDs once we enabled it across the board.
I admit that Capra is somewhat of an odd use case. However, I still wonder if there is a way to control what UUIDs are used for. I would like to use them in all references to models that contain UUIDs and use the positional references for all other cases. Does anyone have any idea how to accomplish that?
[Updated on: Mon, 30 May 2022 13:41] Report message to a moderator |
|
|
|
|
|
| Re: Mixing UUIDs and positional identifiers in one model [message #1852667 is a reply to message #1852666] |
Mon, 30 May 2022 18:14  |
Jan-Philipp Steghöfer
Messages: 12
Registered: May 2019 |
Junior Member |
|
|
All right, fair point. Let me give this a shot.
Eclipse Capra is a traceability management tool, which means that we maintain traceability links between diverse development artifacts. The traceability links themselves are stored as an EMF model. A traceability link consists of a source and a number of targets. The types of traceability links, the multiplicities, etc. are defined in a metamodel (also called traceability information model). As a matter of fact, Eclipse Capra maintains three models with separate metamodels: the trace model which contains the traceability links, the artifacts model which contains information about non-EMF artifacts we link to (such as source code elements, rows in Excel files, etc.) and the metadata model which contains metadata about the traceability links such as when they were created and by which user. There are a number of reasons why these models are separate, but this shouldn't be the point of discussion.
Now a traceability link connects at least two artifacts. For instance, it expresses a relationship between a safety requirement stored in a row in an Excel file and a safety measure stored in an ODE model. ODE is a metamodel for dependency based on EMF. In the trace model XMI, this looks as follows:
<traces name="Include a second environemnt senor (image grabber) : Measure -> Requirements!SR-1.1.1 (mobstr-requirements.xlsx)" xsi:type="tim:SpecifiedByRequirement">
<source href="../org.panorama-research.mobstr.fmea/mobstr-fmea.integration#//@odeProductPackages.3/@measures.0"/>
<target href="artifactWrappers.xmi#//@artifacts.16"/>
</traces>
As you can see, we point to an ODE model (in mobstr-fmea.integration) and to our artifact model (in artifactWrappers.xmi), both using path fragments. Now, what I want to do is to use UUIDs when pointing to the artifact model. I can do that because I have control over the artifact model, i.e., I can manipulate and write it in Eclipse Capra and I can make sure it has UUIDs. However, I want to keep using path fragments when referring to the ODE model since I have no control over that model and cannot modify it to use UUIDs. What I want is essentially this:
<traces name="Include a second environemnt senor (image grabber) : Measure -> Requirements!SR-1.1.1 (mobstr-requirements.xlsx)" xsi:type="tim:SpecifiedByRequirement">
<source href="../org.panorama-research.mobstr.fmea/mobstr-fmea.integration#//@odeProductPackages.3/@measures.0"/>
<target href="artifactWrappers.xmi#_vMTCctjjEeyw9s6Xboqnpw"/>
</traces>
However, as soon as I active UUIDs in the resource in which I load the trace model and the artifact model and save these models, the path fragment pointing to the ODE model is also replaced with UUIDs. Since the ODE model does not contain UUIDs, however, the references break the next time I load my trace model.
I hope this made my problem clearer. Please let me know if you need more detail.
|
|
|
| Re: Mixing UUIDs and positional identifiers in one model [message #1852669 is a reply to message #1852667] |
Mon, 30 May 2022 19:24 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
You've jumped straight in and told us that you are changing to use xmi:id without really telling us why. As you've discovered there are significant tradeoffs.
The default EMF approach has the major advantage that there are only references, no definitions, so you do not need to modify targets to provide definitions. However the references are fragile in the event of model evolution whether manual or automated.
UUIDs are totally unreadable and require universal consistency and are differently fragile in the event of model evolution.
Since you are interested in traceability, you may have evolution concerns that need to be respected.
UUIDs have unpleasant global characteristics. A uri#fragment ids can be more appropriate.
The OCL project uses LUSSIDs (Locally Unique Semantically Sensentive IDs) to compact the fragment and entity qualifiers to compact the uri. This gives very compact xmi:ids that are stable for some semantic changes, and in particular are predictable allowing references to unmodified resources that have 'missing' xmi:ids. The compact xmi:ids save about 10% and are also unredable, but they are short and diverse and so amenable to human mental comparisons. See [1] for an example.
I suggest that having discovered some of the tradeoffs, you try to formulate your requirements more precisely.
That said, provided you observe the save-the-whole-ResourceSet policy, you should find that all the xmi:ids are there, but of course only after injecting them into xmi:id free resources. If you need diverse policies it should be possible to have a save helper that ensures that references to xmi:id free resources use the traditional EMF approach; just populate the object-to-id map with the xmi:id spelling that you require.
Regards
Ed Willink
[1] https://git.eclipse.org/r/plugins/gitiles/ocl/org.eclipse.ocl/+/refs/heads/master/plugins/org.eclipse.ocl.pivot/model-gen/Pivot.oclas
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03842 seconds
] 
Search
Help
Register
Login
Home
