Eclipse Community Forums: EMF Diff/Merge » Use Ids as keys instead of Fragment path in bridgetraces

Home » Modeling » EMF Diff/Merge » Use Ids as keys instead of Fragment path in bridgetraces

Use Ids as keys instead of Fragment path in bridgetraces [message #1756236]

Tue, 14 March 2017 08:09

Eclipse User

Hi,

I am using mapping and coevolution to transform a capella model extended by a viewpoint into a new model.

I have followed the example provided on git (org.eclipse.emf.diffmerge.bridge.examples.uml.modular).

But when I make changes on my source model, the transformation find a lot of irrelevant differences.
Indeed, I have seen that my bridgetraces file uses fragment paths as key of my element. So it try to match elements which are completely differents.
index.php/fa/28755/0/

I would like to use Ids of my elements instead of those paths, how can I do that?

Regards,

Aurélien

Attachment: BridgeTrace.png
(Size: 28.73KB, Downloaded 467 times)

Re: Use Ids as keys instead of Fragment path in bridgetraces [message #1756246 is a reply to message #1756236]

Tue, 14 March 2017 09:30

Eclipse User

Hi Aurelien,

The elements of the target model must be given unique identifiers in order to support model update in a reliable way. By default, those can be either intrinsic IDs defined by your metamodel and its implementation (the preferred way), or extrinsic IDs defined by the target resource(s), e.g., XMI IDs. If no such IDs are found then the URI fragments of the elements are used, hence your snapshot.

Alternatively, you may define your own identification mechanism by implementing ISymbolFunction and assigning it to your trace via ISymbolBasedBridgeTrace.Editable::setSymbolFunction.

Is that helpful?

Re: Use Ids as keys instead of Fragment path in bridgetraces [message #1756255 is a reply to message #1756246]

Tue, 14 March 2017 11:31

Eclipse User

Hi Olivier,

Thanks for your answer.
That is exactly what I tried before asking you. But it seems that my intrinsic Ids are not used.

When I create a model by hand, my connectors reference the steps by their ids:

<steps xsi:type="gqam:ExecutionStep" id="d0ff8d74-d0e6-4706-840e-563aa490715a" name="Step" inputRel="8dc3b673-99c0-4a76-b05e-ece05c3b557a" outputRel="0c462fab-4b36-42ef-bb61-08b1e819dc12"/>
<steps xsi:type="gqam:ExecutionStep" id="31b9cec5-f3b0-4410-a123-18d537f9d16b" name="Step" inputRel="0c462fab-4b36-42ef-bb61-08b1e819dc12"/>
<steps xsi:type="gqam:ExecutionStep" id="4c1e632b-f36b-4735-8307-e791d11c0bcb" name="Step" outputRel="8dc3b673-99c0-4a76-b05e-ece05c3b557a"/>
<connectors id="0c462fab-4b36-42ef-bb61-08b1e819dc12" predec="d0ff8d74-d0e6-4706-840e-563aa490715a" succes="31b9cec5-f3b0-4410-a123-18d537f9d16b"/>
<connectors id="8dc3b673-99c0-4a76-b05e-ece05c3b557a" predec="4c1e632b-f36b-4735-8307-e791d11c0bcb" succes="d0ff8d74-d0e6-4706-840e-563aa490715a"/>

When my model is transformed from Capella, I have:

<steps xsi:type="gqam:ExecutionStep" name="PhysicalFunction 1" respTime="0ps" bestCET="0ps" worstCET="0ps" blockingTime="0ps" outputRel="//@design/@workloadBehavior/@behavior.0/@connectors.0"/>
<steps xsi:type="gqam:ExecutionStep" name="PhysicalFunction 2" respTime="0ps" bestCET="0ps" worstCET="0ps" blockingTime="0ps" inputRel="//@design/@workloadBehavior/@behavior.0/@connectors.1"/>
<steps xsi:type="gqam:ExecutionStep" name="PhysicalFunction 3" respTime="0ps" bestCET="0ps" worstCET="0ps" blockingTime="0ps" inputRel="//@design/@workloadBehavior/@behavior.0/@connectors.0" outputRel="//@design/@workloadBehavior/@behavior.0/@connectors.1"/>
<connectors predec="//@design/@workloadBehavior/@behavior.0/@steps.0" succes="//@design/@workloadBehavior/@behavior.0/@steps.2"/>
<connectors predec="//@design/@workloadBehavior/@behavior.0/@steps.2" succes="//@design/@workloadBehavior/@behavior.0/@steps.1"/>

I think that my Ids are not initialized (hence not found) during the transformation, so that is why it was still using URI fragment instead.
I will try to investigate on that.

Quote:

Alternatively, you may define your own identification mechanism by implementing ISymbolFunction and assigning it to your trace via ISymbolBasedBridgeTrace.Editable::setSymbolFunction.

It is good to know, but I have added Ids to avoid that.

Thank you for your help,

Aurélien

Re: Use Ids as keys instead of Fragment path in bridgetraces [message #1756256 is a reply to message #1756255]

Tue, 14 March 2017 11:39

Eclipse User

If the purpose of your IDs is essentially version control, you may modify the constructors of your metaclass implementations in order to automatically assign a UUID as soon as a new model element is created (e.g., adding line "setId(EcoreUtil.generateUUID());"). If you have a common "IdentifiedElement" metaclass or so, and a simple enough inheritance hierarchy, you only need to add that line once.

Re: Use Ids as keys instead of Fragment path in bridgetraces [message #1756259 is a reply to message #1756256]

Tue, 14 March 2017 11:50

Eclipse User

Alternatively, if you want to leave your metamodel implementation as it is, you may define an abstract IRule that assigns the ID of your target elements in the create(...) method, make all your rules inherit from it and override create(...) such that a call to super.create(...) is always made. But having your metamodel implementation provide IDs automatically provides stronger guarantees for model usage in general.

Re: Use Ids as keys instead of Fragment path in bridgetraces [message #1756262 is a reply to message #1756256]

Tue, 14 March 2017 12:03

Eclipse User

Yes it was my mistake, I used the same as capella ModelElement (i.e. initializing ids in the get method...).
It is working fine now.

Thank you very much,

Aurélien

Previous Topic:	Cant get the merge to work
Next Topic:	EMF Compare Performance

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Nov 15 17:08:35 EST 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter