Eclipse Community Forums: Compare » expected behaviour of EMFCompare when Compare two UML models

Home » Modeling » Compare » expected behaviour of EMFCompare when Compare two UML models(expected behaviour of EMFCompare when Compare two UML models)

Show: Today's Messages :: Show Polls :: Message Navigator

expected behaviour of EMFCompare when Compare two UML models [message #1775259]

Fri, 27 October 2017 02:20

taghreed altamimi

Messages: 173
Registered: October 2014

Senior Member

Hi,
I am using EMFCompare to compare two UML models (attached)
I noticed that one of the differences is goToEnd2[edge ADD] even though goToEnd2 is an old control flow as it exists in both UML models.
My question is : does this an expected behaviour for EMFCompare and if yes can you please explain why ?

Thanks,
Taghreed

Attachment: Comparison.png
(Size: 137.83KB, Downloaded 50 times)
Attachment: Example1.png
(Size: 37.33KB, Downloaded 45 times)
Attachment: changedExample1.png
(Size: 59.30KB, Downloaded 53 times)

Report message to a moderator

Re: expected behaviour of EMFCompare when Compare two UML models [message #1775446 is a reply to message #1775259]

Mon, 30 October 2017 09:20

Philip Langer

Messages: 83
Registered: March 2015
Location: Vienna, Austria

Member

Hi Taghreed,

EMF Compare uses XMI:ID-based matching if those IDs are available. In Papyrus models those are available by default. So the expected behavior would be that they are matched if their IDs are exactly the same. If they aren't the same, e.g., because you have deleted the edge and created a new edge with exactly the same values, EMF Compare would show a deletion and an addition instead.

Is the XMI:ID of the edge goToEnd2 in version 1 the same as in version 2?

If the XMI:ID is different and "just" the model elements' values are the same -- because you deleted and recreated this element, EMF Compare would have to do a content-based match to be able to correctly match those elements, which EMF Compare doesn't do by default, mainly because it would significantly slow down the comparison for larger models. If you require that, you can implement your own matcher that tries to re-match unmatched elements based on their contents and select this matcher in the EMF Compare preferences instead of the default one.

Best wishes,

Philip

--
Philip Langer

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/

[Updated on: Mon, 30 October 2017 09:21]

Report message to a moderator

Re: expected behaviour of EMFCompare when Compare two UML models [message #1775470 is a reply to message #1775446]

Mon, 30 October 2017 15:29

taghreed altamimi

Messages: 173
Registered: October 2014

Senior Member

Hi Philip,
Answer to your question:Is the XMI:ID of the edge goToEnd2 in version 1 the same as in version 2?
Yes they are same in both version and that's why i think that EMF compare doesn't behave as expected. I want EMF Compare to do the comparison by matching the XMI:IDs .I don't want to change its default behavior.

I attached both UML models which i compare between them. Can you please take a look.
Thanks,
Taghreed

Attachment: EMFCompareMinimalExample.zip
(Size: 17.16KB, Downloaded 14 times)

[Updated on: Tue, 14 November 2017 03:00]

Report message to a moderator

Previous Topic:	expected behaviour of EMFCompare when Compare two UML models
Next Topic:	[Papyrus] Compatible versions between Papyrus and EMFCompare?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue May 22 14:18:27 GMT 2018

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter