Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Weak comparison - can't match nodes, when nested
| Weak comparison - can't match nodes, when nested [message #135600] |
Wed, 29 April 2009 23:52  |
 Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi all
I've noticed that if EMF Compare reports that node is deleted it means
that all the children are deleted. And when the tree is added, EMF
Compare reports only the root node. Why? With such design in some cases
the comparison result looks weak.
The questions are:
- Am I correct about my points?
- Do you agree that the result of EMF Compare for below situation is not
satisfied?
- Can I extend EMF compare somehow to better compare the situation below?
I'm using EMF Compare to compare BPEL files in my plugin. But this post
only about EMF Compare, don't worry about screenshots too much :)
I've tried to give to EMF Compare the first non-obvious task I can
imagine and I'm not satisfied with the result.
Check this screenshot:
http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
EMF Compare reports that 'If12' is removed and 'If' is added (i'm using
the same color for 'removed' and 'added' annotations)
But, In my opinion, it is not 'good' comparison result. We can recognize
that 'If12' was nested into 'If' and only report that 'If' is added. We
should not report that 'If12' is deleted, because it doesn't!
There are several possible options:
1. report that If12 is renamed to If, and another If12 is added. - weak
result
2. report that If12 is deleted and If and If12 are added - weak result
3. report that 'If' is added. Recognize that 'If12' was just moved
inside 'If' - excellent result
I've tried to help EMF Compare adding extra-stuff inside 'If12'.
But I still have the same result.
http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
Such situation (when a block of code surrounded with if, while, or
another activity) is very common for BPEL and other programming
languages. So I'm thinking how to help EMF Compare to better recognize
such situations. Any tips are welcome. But I'm afraid it is not possible
by design of EMF Compare...
Thanks,
Oleg
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135652 is a reply to message #135600] |
Thu, 30 April 2009 08:22  |
|
This is a multi-part message in MIME format.
--------------070404050705010901060300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
As you have guessed, EMF Compare does not consider changes _within_
"unmatched elements" : we consider the top level "addition" or "removal"
of an element to be the only change of its tree, thus "move" differences
within their content tree won't be detected.
This behavior might be changed from the GenericMatchEngine by going down
into the unmatched elements to continue the matching phase where we stop
it today, yet this isn't a trivial change.
Could you file an enhancement request for this? Note that this will
clearly not be done for Galileo as we are now in the M7 phase.
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135691 is a reply to message #135652] |
Thu, 30 April 2009 10:09 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
Thank you for fast response.
Actually I can try to implement the change.
I'm writing my plugin as Master Thesis, but the plugin itself is just
'engineering task' so I'm looking for some 'scientific' task to include
in my thesis.
I think I can propose the change to EMF Compare algorithm, but the
question is "Why it was written this way originally?".
I read in FAQ that EMF Compare based on many researches, mostly on
"UMLDiff: An Algorithm for Object-OrientedDesign Differencing"
Since EMF Compare based on some 'researches' there certainty should be a
reason to write EMF Compare the way it wrote. And I need to know these
reasons before proposing any changes to algorithm :)
BTW what is the best source to learn the algorithm of EMF Compare?
Thanks,
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> As you have guessed, EMF Compare does not consider changes _within_
> "unmatched elements" : we consider the top level "addition" or "removal"
> of an element to be the only change of its tree, thus "move" differences
> within their content tree won't be detected.
>
> This behavior might be changed from the GenericMatchEngine by going down
> into the unmatched elements to continue the matching phase where we stop
> it today, yet this isn't a trivial change.
>
> Could you file an enhancement request for this? Note that this will
> clearly not be done for Galileo as we are now in the M7 phase.
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi all
>>
>> I've noticed that if EMF Compare reports that node is deleted it means
>> that all the children are deleted. And when the tree is added, EMF
>> Compare reports only the root node. Why? With such design in some
>> cases the comparison result looks weak.
>>
>> The questions are:
>> - Am I correct about my points?
>> - Do you agree that the result of EMF Compare for below situation is
>> not satisfied?
>> - Can I extend EMF compare somehow to better compare the situation below?
>>
>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>> post only about EMF Compare, don't worry about screenshots too much :)
>>
>> I've tried to give to EMF Compare the first non-obvious task I can
>> imagine and I'm not satisfied with the result.
>>
>> Check this screenshot:
>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>> using the same color for 'removed' and 'added' annotations)
>>
>> But, In my opinion, it is not 'good' comparison result. We can
>> recognize that 'If12' was nested into 'If' and only report that 'If'
>> is added. We should not report that 'If12' is deleted, because it
>> doesn't!
>>
>> There are several possible options:
>> 1. report that If12 is renamed to If, and another If12 is added. -
>> weak result
>> 2. report that If12 is deleted and If and If12 are added - weak result
>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>> inside 'If' - excellent result
>>
>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>> But I still have the same result.
>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>
>> Such situation (when a block of code surrounded with if, while, or
>> another activity) is very common for BPEL and other programming
>> languages. So I'm thinking how to help EMF Compare to better recognize
>> such situations. Any tips are welcome. But I'm afraid it is not
>> possible by design of EMF Compare...
>>
>> Thanks,
>> Oleg
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135705 is a reply to message #135691] |
Thu, 30 April 2009 11:10 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi,
> I think I can propose the change to EMF Compare algorithm, but the
> question is "Why it was written this way originally?".
the implemented algorithm has a some good properties :
- it's generic and works even if you compare models from different metamodels
- it has quite a pretty good scalability/quality ratio for a generic algorithm.
- it works both for "litle" (library) and "big" metamodels.(UML)
That said, the fact that the nested differences were not detected was an arbitrary choice, we wanted to only show the user that a "package has been added" and not that "the package and every elements inside it" has been added. Seems like this choice was not the best in regard to the "move" detection.
> Since EMF Compare based on some 'researches' there certainty should be a
> reason to write EMF Compare the way it wrote. And I need to know these
> reasons before proposing any changes to algorithm :)
>
> BTW what is the best source to learn the algorithm of EMF Compare?
Use the code Luke ! ;) The code is the best place, the UMLdiff paper will give you an overview and the paper I published with Alfonso Pierantonio might be a good reference too (
http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
Cheers,
Cédric
>
> Thanks,
> Oleg
>
> laurent Goubet wrote:
>> Hi Oleg,
>>
>> As you have guessed, EMF Compare does not consider changes _within_
>> "unmatched elements" : we consider the top level "addition" or "removal"
>> of an element to be the only change of its tree, thus "move" differences
>> within their content tree won't be detected.
>>
>> This behavior might be changed from the GenericMatchEngine by going down
>> into the unmatched elements to continue the matching phase where we stop
>> it today, yet this isn't a trivial change.
>>
>> Could you file an enhancement request for this? Note that this will
>> clearly not be done for Galileo as we are now in the M7 phase.
>>
>> Laurent Goubet
>> Obeo
>>
>> Oleg Vazhnev a écrit :
>>> Hi all
>>>
>>> I've noticed that if EMF Compare reports that node is deleted it means
>>> that all the children are deleted. And when the tree is added, EMF
>>> Compare reports only the root node. Why? With such design in some
>>> cases the comparison result looks weak.
>>>
>>> The questions are:
>>> - Am I correct about my points?
>>> - Do you agree that the result of EMF Compare for below situation is
>>> not satisfied?
>>> - Can I extend EMF compare somehow to better compare the situation
>>> below?
>>>
>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>
>>> I've tried to give to EMF Compare the first non-obvious task I can
>>> imagine and I'm not satisfied with the result.
>>>
>>> Check this screenshot:
>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>> using the same color for 'removed' and 'added' annotations)
>>>
>>> But, In my opinion, it is not 'good' comparison result. We can
>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>> is added. We should not report that 'If12' is deleted, because it
>>> doesn't!
>>>
>>> There are several possible options:
>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>> weak result
>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>> inside 'If' - excellent result
>>>
>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>> But I still have the same result.
>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>
>>> Such situation (when a block of code surrounded with if, while, or
>>> another activity) is very common for BPEL and other programming
>>> languages. So I'm thinking how to help EMF Compare to better recognize
>>> such situations. Any tips are welcome. But I'm afraid it is not
>>> possible by design of EMF Compare...
>>>
>>> Thanks,
>>> Oleg
>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135716 is a reply to message #135705] |
Thu, 30 April 2009 13:36 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Thank you Cédric!
Cédric Brun wrote:
> Hi,
>
>> I think I can propose the change to EMF Compare algorithm, but the
>> question is "Why it was written this way originally?".
>
> the implemented algorithm has a some good properties :
> - it's generic and works even if you compare models from different metamodels
> - it has quite a pretty good scalability/quality ratio for a generic algorithm.
> - it works both for "litle" (library) and "big" metamodels.(UML)
>
> That said, the fact that the nested differences were not detected was an arbitrary choice, we wanted to only show the user that a "package has been added" and not that "the package and every elements inside it" has been added. Seems like this choice was not the best in regard to the "move" detection.
>
>
>> Since EMF Compare based on some 'researches' there certainty should be a
>> reason to write EMF Compare the way it wrote. And I need to know these
>> reasons before proposing any changes to algorithm :)
>>
>> BTW what is the best source to learn the algorithm of EMF Compare?
> Use the code Luke ! ;) The code is the best place, the UMLdiff paper will give you an overview and the paper I published with Alfonso Pierantonio might be a good reference too (
> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>
> Cheers,
>
> Cédric
>
>> Thanks,
>> Oleg
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> As you have guessed, EMF Compare does not consider changes _within_
>>> "unmatched elements" : we consider the top level "addition" or "removal"
>>> of an element to be the only change of its tree, thus "move" differences
>>> within their content tree won't be detected.
>>>
>>> This behavior might be changed from the GenericMatchEngine by going down
>>> into the unmatched elements to continue the matching phase where we stop
>>> it today, yet this isn't a trivial change.
>>>
>>> Could you file an enhancement request for this? Note that this will
>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi all
>>>>
>>>> I've noticed that if EMF Compare reports that node is deleted it means
>>>> that all the children are deleted. And when the tree is added, EMF
>>>> Compare reports only the root node. Why? With such design in some
>>>> cases the comparison result looks weak.
>>>>
>>>> The questions are:
>>>> - Am I correct about my points?
>>>> - Do you agree that the result of EMF Compare for below situation is
>>>> not satisfied?
>>>> - Can I extend EMF compare somehow to better compare the situation
>>>> below?
>>>>
>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>>
>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>> imagine and I'm not satisfied with the result.
>>>>
>>>> Check this screenshot:
>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>> using the same color for 'removed' and 'added' annotations)
>>>>
>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>> is added. We should not report that 'If12' is deleted, because it
>>>> doesn't!
>>>>
>>>> There are several possible options:
>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>> weak result
>>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>> inside 'If' - excellent result
>>>>
>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>> But I still have the same result.
>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>
>>>> Such situation (when a block of code surrounded with if, while, or
>>>> another activity) is very common for BPEL and other programming
>>>> languages. So I'm thinking how to help EMF Compare to better recognize
>>>> such situations. Any tips are welcome. But I'm afraid it is not
>>>> possible by design of EMF Compare...
>>>>
>>>> Thanks,
>>>> Oleg
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135729 is a reply to message #135716] |
Sat, 02 May 2009 18:02 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Cédric and Laurent
That's what I read in this paper "Presentation of EMF Compare Utility"
by Antoine Toulmé
"The problem of this tree comparison is that it is not
convenient for comparing flow charts diagrams
(like BPMN diagrams). Some relationships are
ignored or handled in an invalid way."
It seems some work was done in my area...
Probably you can point me to mentioned problems (i can try
to solve them then :) I.e. what relationships are ignored
or handled in an invalid way?
Thanks,
Oleg
Oleg Vazhnev wrote:
> Thank you Cédric!
>
> Cédric Brun wrote:
>> Hi,
>>
>>> I think I can propose the change to EMF Compare algorithm, but the
>>> question is "Why it was written this way originally?".
>>
>> the implemented algorithm has a some good properties :
>> - it's generic and works even if you compare models from different
>> metamodels
>> - it has quite a pretty good scalability/quality ratio for a generic
>> algorithm.
>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>
>> That said, the fact that the nested differences were not detected was
>> an arbitrary choice, we wanted to only show the user that a "package
>> has been added" and not that "the package and every elements inside
>> it" has been added. Seems like this choice was not the best in regard
>> to the "move" detection.
>>
>>
>>> Since EMF Compare based on some 'researches' there certainty should be a
>>> reason to write EMF Compare the way it wrote. And I need to know these
>>> reasons before proposing any changes to algorithm :)
>>>
>>> BTW what is the best source to learn the algorithm of EMF Compare?
>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>> will give you an overview and the paper I published with Alfonso
>> Pierantonio might be a good reference too (
>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>
>> Cheers,
>>
>> Cédric
>>
>>> Thanks,
>>> Oleg
>>>
>>> laurent Goubet wrote:
>>>> Hi Oleg,
>>>>
>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>> "unmatched elements" : we consider the top level "addition" or
>>>> "removal"
>>>> of an element to be the only change of its tree, thus "move"
>>>> differences
>>>> within their content tree won't be detected.
>>>>
>>>> This behavior might be changed from the GenericMatchEngine by going
>>>> down
>>>> into the unmatched elements to continue the matching phase where we
>>>> stop
>>>> it today, yet this isn't a trivial change.
>>>>
>>>> Could you file an enhancement request for this? Note that this will
>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>
>>>> Laurent Goubet
>>>> Obeo
>>>>
>>>> Oleg Vazhnev a écrit :
>>>>> Hi all
>>>>>
>>>>> I've noticed that if EMF Compare reports that node is deleted it means
>>>>> that all the children are deleted. And when the tree is added, EMF
>>>>> Compare reports only the root node. Why? With such design in some
>>>>> cases the comparison result looks weak.
>>>>>
>>>>> The questions are:
>>>>> - Am I correct about my points?
>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>> not satisfied?
>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>> below?
>>>>>
>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>>>
>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>> imagine and I'm not satisfied with the result.
>>>>>
>>>>> Check this screenshot:
>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>
>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>> doesn't!
>>>>>
>>>>> There are several possible options:
>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>> weak result
>>>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>>> inside 'If' - excellent result
>>>>>
>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>> But I still have the same result.
>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>
>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>> another activity) is very common for BPEL and other programming
>>>>> languages. So I'm thinking how to help EMF Compare to better recognize
>>>>> such situations. Any tips are welcome. But I'm afraid it is not
>>>>> possible by design of EMF Compare...
>>>>>
>>>>> Thanks,
>>>>> Oleg
>>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135788 is a reply to message #135729] |
Mon, 04 May 2009 08:01 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Oleg,
>
> That's what I read in this paper "Presentation of EMF Compare Utility"
> by Antoine Toulmé
Yes, that paper was presenting some part of the initial contribution. (quite old but the problem are still valid)
>
> "The problem of this tree comparison is that it is not
> convenient for comparing flow charts diagrams
> (like BPMN diagrams). Some relationships are
> ignored or handled in an invalid way."
The problem is a generic one, some times, especially on "association like" elements, we don't have enough information to match correctly two versions of a relationship. That causes a "this relationship has been removed / this relationship has been added" diff instead of a "this relationship has been changed".
The problem is a tricky one as we don't have much information to match these elements and we should probably consider them in a specific way.
We're open to suggestions :)
Cédric
> Oleg
>
> Oleg Vazhnev wrote:
>> Thank you Cédric!
>>
>> Cédric Brun wrote:
>>> Hi,
>>>
>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>> question is "Why it was written this way originally?".
>>>
>>> the implemented algorithm has a some good properties :
>>> - it's generic and works even if you compare models from different
>>> metamodels
>>> - it has quite a pretty good scalability/quality ratio for a generic
>>> algorithm.
>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>
>>> That said, the fact that the nested differences were not detected was
>>> an arbitrary choice, we wanted to only show the user that a "package
>>> has been added" and not that "the package and every elements inside
>>> it" has been added. Seems like this choice was not the best in regard
>>> to the "move" detection.
>>>
>>>
>>>> Since EMF Compare based on some 'researches' there certainty should be
>>>> a reason to write EMF Compare the way it wrote. And I need to know
>>>> these reasons before proposing any changes to algorithm :)
>>>>
>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>> will give you an overview and the paper I published with Alfonso
>>> Pierantonio might be a good reference too (
>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>
>>> Cheers,
>>>
>>> Cédric
>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>> laurent Goubet wrote:
>>>>> Hi Oleg,
>>>>>
>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>> "removal"
>>>>> of an element to be the only change of its tree, thus "move"
>>>>> differences
>>>>> within their content tree won't be detected.
>>>>>
>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>> down
>>>>> into the unmatched elements to continue the matching phase where we
>>>>> stop
>>>>> it today, yet this isn't a trivial change.
>>>>>
>>>>> Could you file an enhancement request for this? Note that this will
>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Oleg Vazhnev a écrit :
>>>>>> Hi all
>>>>>>
>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>> means that all the children are deleted. And when the tree is added,
>>>>>> EMF Compare reports only the root node. Why? With such design in some
>>>>>> cases the comparison result looks weak.
>>>>>>
>>>>>> The questions are:
>>>>>> - Am I correct about my points?
>>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>>> not satisfied?
>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>> below?
>>>>>>
>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>> :)
>>>>>>
>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>> imagine and I'm not satisfied with the result.
>>>>>>
>>>>>> Check this screenshot:
>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>
>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>>> doesn't!
>>>>>>
>>>>>> There are several possible options:
>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>> weak result
>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>> moved inside 'If' - excellent result
>>>>>>
>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>> But I still have the same result.
>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>
>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>> another activity) is very common for BPEL and other programming
>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it is
>>>>>> not possible by design of EMF Compare...
>>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135825 is a reply to message #135729] |
Mon, 04 May 2009 16:21 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Oleg,
On thing just stroke me and could be incredibly interesting from a research point of view. Right now we are struggling in matching two versions of elements using custom heuristics and custom model traversal strategies. That's costly, we often browse the model and compute metrics.
I've been playing with Drools (JBoss rules engine) lately and this piece of software includes a constraint solver. You can set different research strategies for the solver (using local optimum for instance) and the performances are really really good. Moreover, it's fully java based and integrating an EMF model with that is really easy (a blog post is coming about that !)
One could easily imagine to leverage drools-solver with a set of rules to correctly match the elements. No doubt we would get far better performances and better quality too. Handling the "relationship" corner cases would then just be adding a few rules for the matching process.
That's another way to tackle the problem, and in my opinion, really promising. Don't know If that would interest you though..
Cheers,
Cédric
Oleg Vazhnev wrote:
> Hi Cédric and Laurent
>
> That's what I read in this paper "Presentation of EMF Compare Utility"
> by Antoine Toulmé
>
> "The problem of this tree comparison is that it is not
> convenient for comparing flow charts diagrams
> (like BPMN diagrams). Some relationships are
> ignored or handled in an invalid way."
>
> It seems some work was done in my area...
> Probably you can point me to mentioned problems (i can try
> to solve them then :) I.e. what relationships are ignored
> or handled in an invalid way?
>
> Thanks,
> Oleg
>
> Oleg Vazhnev wrote:
>> Thank you Cédric!
>>
>> Cédric Brun wrote:
>>> Hi,
>>>
>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>> question is "Why it was written this way originally?".
>>>
>>> the implemented algorithm has a some good properties :
>>> - it's generic and works even if you compare models from different
>>> metamodels
>>> - it has quite a pretty good scalability/quality ratio for a generic
>>> algorithm.
>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>
>>> That said, the fact that the nested differences were not detected was
>>> an arbitrary choice, we wanted to only show the user that a "package
>>> has been added" and not that "the package and every elements inside
>>> it" has been added. Seems like this choice was not the best in regard
>>> to the "move" detection.
>>>
>>>
>>>> Since EMF Compare based on some 'researches' there certainty should be
>>>> a reason to write EMF Compare the way it wrote. And I need to know
>>>> these reasons before proposing any changes to algorithm :)
>>>>
>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>> will give you an overview and the paper I published with Alfonso
>>> Pierantonio might be a good reference too (
>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>
>>> Cheers,
>>>
>>> Cédric
>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>> laurent Goubet wrote:
>>>>> Hi Oleg,
>>>>>
>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>> "removal"
>>>>> of an element to be the only change of its tree, thus "move"
>>>>> differences
>>>>> within their content tree won't be detected.
>>>>>
>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>> down
>>>>> into the unmatched elements to continue the matching phase where we
>>>>> stop
>>>>> it today, yet this isn't a trivial change.
>>>>>
>>>>> Could you file an enhancement request for this? Note that this will
>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Oleg Vazhnev a écrit :
>>>>>> Hi all
>>>>>>
>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>> means that all the children are deleted. And when the tree is added,
>>>>>> EMF Compare reports only the root node. Why? With such design in some
>>>>>> cases the comparison result looks weak.
>>>>>>
>>>>>> The questions are:
>>>>>> - Am I correct about my points?
>>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>>> not satisfied?
>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>> below?
>>>>>>
>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>> :)
>>>>>>
>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>> imagine and I'm not satisfied with the result.
>>>>>>
>>>>>> Check this screenshot:
>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>
>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>>> doesn't!
>>>>>>
>>>>>> There are several possible options:
>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>> weak result
>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>> moved inside 'If' - excellent result
>>>>>>
>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>> But I still have the same result.
>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>
>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>> another activity) is very common for BPEL and other programming
>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it is
>>>>>> not possible by design of EMF Compare...
>>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135840 is a reply to message #135788] |
Mon, 04 May 2009 22:10 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Cédric
It would be nice if you can provide an example :)
So far I've found two points where I want to change the behavior of EMF
Compare for my plugin.
1. I want EMF Compare to count 'name' attribute with a special very very
high priority. Because two activities with the same name - most likely
the same activities. This issue was raised in UMLDiff algorithm, but it
seems EMF Compare can't recognize that 'name' attribute is very
important. Check this screenshot:
http://www.picamatic.com/show/2009/05/05/01/57/3516577_478x3 53.PNG
I expect here to see that 'RepeatUntil1' was added.
2. The issue I described originally in this thread
Also check this screenshot:
http://www.picamatic.com/show/2009/05/05/01/58/3516586_425x2 94.PNG
I think having fixed these two issue EMF Compare will compare .bpel
files much better :)
I plan to debug EMF Compare a little to understand how can I solve the
first issue.
I plan to debug GenericMatchEngine (as Laurent suggested) to understand
how to force algorithm "to go inside till leafs" :) Hope I can 'plug'
this functionality just extending the class in some manner...
Thanks,
Oleg
Cédric Brun wrote:
> Hi Oleg,
>
>
>> That's what I read in this paper "Presentation of EMF Compare Utility"
>> by Antoine Toulmé
>
> Yes, that paper was presenting some part of the initial contribution. (quite old but the problem are still valid)
>
>> "The problem of this tree comparison is that it is not
>> convenient for comparing flow charts diagrams
>> (like BPMN diagrams). Some relationships are
>> ignored or handled in an invalid way."
>
> The problem is a generic one, some times, especially on "association like" elements, we don't have enough information to match correctly two versions of a relationship. That causes a "this relationship has been removed / this relationship has been added" diff instead of a "this relationship has been changed".
>
> The problem is a tricky one as we don't have much information to match these elements and we should probably consider them in a specific way.
>
> We're open to suggestions :)
>
>
> Cédric
>
>> Oleg
>>
>> Oleg Vazhnev wrote:
>>> Thank you Cédric!
>>>
>>> Cédric Brun wrote:
>>>> Hi,
>>>>
>>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>>> question is "Why it was written this way originally?".
>>>> the implemented algorithm has a some good properties :
>>>> - it's generic and works even if you compare models from different
>>>> metamodels
>>>> - it has quite a pretty good scalability/quality ratio for a generic
>>>> algorithm.
>>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>>
>>>> That said, the fact that the nested differences were not detected was
>>>> an arbitrary choice, we wanted to only show the user that a "package
>>>> has been added" and not that "the package and every elements inside
>>>> it" has been added. Seems like this choice was not the best in regard
>>>> to the "move" detection.
>>>>
>>>>
>>>>> Since EMF Compare based on some 'researches' there certainty should be
>>>>> a reason to write EMF Compare the way it wrote. And I need to know
>>>>> these reasons before proposing any changes to algorithm :)
>>>>>
>>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>>> will give you an overview and the paper I published with Alfonso
>>>> Pierantonio might be a good reference too (
>>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>>
>>>> Cheers,
>>>>
>>>> Cédric
>>>>
>>>>> Thanks,
>>>>> Oleg
>>>>>
>>>>> laurent Goubet wrote:
>>>>>> Hi Oleg,
>>>>>>
>>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>>> "removal"
>>>>>> of an element to be the only change of its tree, thus "move"
>>>>>> differences
>>>>>> within their content tree won't be detected.
>>>>>>
>>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>>> down
>>>>>> into the unmatched elements to continue the matching phase where we
>>>>>> stop
>>>>>> it today, yet this isn't a trivial change.
>>>>>>
>>>>>> Could you file an enhancement request for this? Note that this will
>>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>
>>>>>> Laurent Goubet
>>>>>> Obeo
>>>>>>
>>>>>> Oleg Vazhnev a écrit :
>>>>>>> Hi all
>>>>>>>
>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>> means that all the children are deleted. And when the tree is added,
>>>>>>> EMF Compare reports only the root node. Why? With such design in some
>>>>>>> cases the comparison result looks weak.
>>>>>>>
>>>>>>> The questions are:
>>>>>>> - Am I correct about my points?
>>>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>>>> not satisfied?
>>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>>> below?
>>>>>>>
>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>>> :)
>>>>>>>
>>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>>> imagine and I'm not satisfied with the result.
>>>>>>>
>>>>>>> Check this screenshot:
>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>>
>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>>>> doesn't!
>>>>>>>
>>>>>>> There are several possible options:
>>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>>> weak result
>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>> moved inside 'If' - excellent result
>>>>>>>
>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>> But I still have the same result.
>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>
>>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>>> another activity) is very common for BPEL and other programming
>>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it is
>>>>>>> not possible by design of EMF Compare...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Oleg
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135852 is a reply to message #135825] |
Mon, 04 May 2009 22:28 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Cédric
Sounds interesting :)
Do you think that someone can use Drools instead of EMF Compare or do
you plan to use Drools in EMF Compare (to make 'match' phase)?
Do you have an examples where Drools compares better than 'EMF Compare'?
As for my MS Thesis I think I would just include two 'extensions' I've
proposed above, because of time constraints.
Thanks,
Oleg
Cédric Brun wrote:
> Hi Oleg,
>
> On thing just stroke me and could be incredibly interesting from a research point of view. Right now we are struggling in matching two versions of elements using custom heuristics and custom model traversal strategies. That's costly, we often browse the model and compute metrics.
> I've been playing with Drools (JBoss rules engine) lately and this piece of software includes a constraint solver. You can set different research strategies for the solver (using local optimum for instance) and the performances are really really good. Moreover, it's fully java based and integrating an EMF model with that is really easy (a blog post is coming about that !)
>
> One could easily imagine to leverage drools-solver with a set of rules to correctly match the elements. No doubt we would get far better performances and better quality too. Handling the "relationship" corner cases would then just be adding a few rules for the matching process.
>
> That's another way to tackle the problem, and in my opinion, really promising. Don't know If that would interest you though..
>
> Cheers,
>
> Cédric
>
>
> Oleg Vazhnev wrote:
>> Hi Cédric and Laurent
>>
>> That's what I read in this paper "Presentation of EMF Compare Utility"
>> by Antoine Toulmé
>>
>> "The problem of this tree comparison is that it is not
>> convenient for comparing flow charts diagrams
>> (like BPMN diagrams). Some relationships are
>> ignored or handled in an invalid way."
>>
>> It seems some work was done in my area...
>> Probably you can point me to mentioned problems (i can try
>> to solve them then :) I.e. what relationships are ignored
>> or handled in an invalid way?
>>
>> Thanks,
>> Oleg
>>
>> Oleg Vazhnev wrote:
>>> Thank you Cédric!
>>>
>>> Cédric Brun wrote:
>>>> Hi,
>>>>
>>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>>> question is "Why it was written this way originally?".
>>>> the implemented algorithm has a some good properties :
>>>> - it's generic and works even if you compare models from different
>>>> metamodels
>>>> - it has quite a pretty good scalability/quality ratio for a generic
>>>> algorithm.
>>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>>
>>>> That said, the fact that the nested differences were not detected was
>>>> an arbitrary choice, we wanted to only show the user that a "package
>>>> has been added" and not that "the package and every elements inside
>>>> it" has been added. Seems like this choice was not the best in regard
>>>> to the "move" detection.
>>>>
>>>>
>>>>> Since EMF Compare based on some 'researches' there certainty should be
>>>>> a reason to write EMF Compare the way it wrote. And I need to know
>>>>> these reasons before proposing any changes to algorithm :)
>>>>>
>>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>>> will give you an overview and the paper I published with Alfonso
>>>> Pierantonio might be a good reference too (
>>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>>
>>>> Cheers,
>>>>
>>>> Cédric
>>>>
>>>>> Thanks,
>>>>> Oleg
>>>>>
>>>>> laurent Goubet wrote:
>>>>>> Hi Oleg,
>>>>>>
>>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>>> "removal"
>>>>>> of an element to be the only change of its tree, thus "move"
>>>>>> differences
>>>>>> within their content tree won't be detected.
>>>>>>
>>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>>> down
>>>>>> into the unmatched elements to continue the matching phase where we
>>>>>> stop
>>>>>> it today, yet this isn't a trivial change.
>>>>>>
>>>>>> Could you file an enhancement request for this? Note that this will
>>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>
>>>>>> Laurent Goubet
>>>>>> Obeo
>>>>>>
>>>>>> Oleg Vazhnev a écrit :
>>>>>>> Hi all
>>>>>>>
>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>> means that all the children are deleted. And when the tree is added,
>>>>>>> EMF Compare reports only the root node. Why? With such design in some
>>>>>>> cases the comparison result looks weak.
>>>>>>>
>>>>>>> The questions are:
>>>>>>> - Am I correct about my points?
>>>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>>>> not satisfied?
>>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>>> below?
>>>>>>>
>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>>> :)
>>>>>>>
>>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>>> imagine and I'm not satisfied with the result.
>>>>>>>
>>>>>>> Check this screenshot:
>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>>
>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>>>> doesn't!
>>>>>>>
>>>>>>> There are several possible options:
>>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>>> weak result
>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>> moved inside 'If' - excellent result
>>>>>>>
>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>> But I still have the same result.
>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>
>>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>>> another activity) is very common for BPEL and other programming
>>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it is
>>>>>>> not possible by design of EMF Compare...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Oleg
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135865 is a reply to message #135840] |
Tue, 05 May 2009 07:57 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Oleg
you can specialize the GenericMatchEngine and provides yours as a default through the "match engine" extension point. That would enable you to specialize the generic behavior considering the "name" attribute in a specific way or forcing the algorithm to "go inside till leafs" when needed.
Cédric
Oleg Vazhnev wrote:
> Hi Cédric
>
> It would be nice if you can provide an example :)
>
> So far I've found two points where I want to change the behavior of EMF
> Compare for my plugin.
>
>
> 1. I want EMF Compare to count 'name' attribute with a special very very
> high priority. Because two activities with the same name - most likely
> the same activities. This issue was raised in UMLDiff algorithm, but it
> seems EMF Compare can't recognize that 'name' attribute is very
> important. Check this screenshot:
> http://www.picamatic.com/show/2009/05/05/01/57/3516577_478x3 53.PNG
> I expect here to see that 'RepeatUntil1' was added.
>
> 2. The issue I described originally in this thread
> Also check this screenshot:
> http://www.picamatic.com/show/2009/05/05/01/58/3516586_425x2 94.PNG
>
> I think having fixed these two issue EMF Compare will compare .bpel
> files much better :)
>
>
> I plan to debug EMF Compare a little to understand how can I solve the
> first issue.
> I plan to debug GenericMatchEngine (as Laurent suggested) to understand
> how to force algorithm "to go inside till leafs" :) Hope I can 'plug'
> this functionality just extending the class in some manner...
>
>
> Thanks,
> Oleg
>
>
>
> Cédric Brun wrote:
>> Hi Oleg,
>>
>>
>>> That's what I read in this paper "Presentation of EMF Compare Utility"
>>> by Antoine Toulmé
>>
>> Yes, that paper was presenting some part of the initial contribution.
>> (quite old but the problem are still valid)
>>
>>> "The problem of this tree comparison is that it is not
>>> convenient for comparing flow charts diagrams
>>> (like BPMN diagrams). Some relationships are
>>> ignored or handled in an invalid way."
>>
>> The problem is a generic one, some times, especially on "association
>> like" elements, we don't have enough information to match correctly two
>> versions of a relationship. That causes a "this relationship has been
>> removed / this relationship has been added" diff instead of a "this
>> relationship has been changed".
>>
>> The problem is a tricky one as we don't have much information to match
>> these elements and we should probably consider them in a specific way.
>>
>> We're open to suggestions :)
>>
>>
>> Cédric
>>
>>> Oleg
>>>
>>> Oleg Vazhnev wrote:
>>>> Thank you Cédric!
>>>>
>>>> Cédric Brun wrote:
>>>>> Hi,
>>>>>
>>>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>>>> question is "Why it was written this way originally?".
>>>>> the implemented algorithm has a some good properties :
>>>>> - it's generic and works even if you compare models from different
>>>>> metamodels
>>>>> - it has quite a pretty good scalability/quality ratio for a generic
>>>>> algorithm.
>>>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>>>
>>>>> That said, the fact that the nested differences were not detected was
>>>>> an arbitrary choice, we wanted to only show the user that a "package
>>>>> has been added" and not that "the package and every elements inside
>>>>> it" has been added. Seems like this choice was not the best in regard
>>>>> to the "move" detection.
>>>>>
>>>>>
>>>>>> Since EMF Compare based on some 'researches' there certainty should
>>>>>> be a reason to write EMF Compare the way it wrote. And I need to know
>>>>>> these reasons before proposing any changes to algorithm :)
>>>>>>
>>>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>>>> will give you an overview and the paper I published with Alfonso
>>>>> Pierantonio might be a good reference too (
>>>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Cédric
>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>>>>
>>>>>> laurent Goubet wrote:
>>>>>>> Hi Oleg,
>>>>>>>
>>>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>>>> "removal"
>>>>>>> of an element to be the only change of its tree, thus "move"
>>>>>>> differences
>>>>>>> within their content tree won't be detected.
>>>>>>>
>>>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>>>> down
>>>>>>> into the unmatched elements to continue the matching phase where we
>>>>>>> stop
>>>>>>> it today, yet this isn't a trivial change.
>>>>>>>
>>>>>>> Could you file an enhancement request for this? Note that this will
>>>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Oleg Vazhnev a écrit :
>>>>>>>> Hi all
>>>>>>>>
>>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>>> means that all the children are deleted. And when the tree is
>>>>>>>> added, EMF Compare reports only the root node. Why? With such
>>>>>>>> design in some cases the comparison result looks weak.
>>>>>>>>
>>>>>>>> The questions are:
>>>>>>>> - Am I correct about my points?
>>>>>>>> - Do you agree that the result of EMF Compare for below situation
>>>>>>>> is not satisfied?
>>>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>>>> below?
>>>>>>>>
>>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>>>> :)
>>>>>>>>
>>>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>>>> imagine and I'm not satisfied with the result.
>>>>>>>>
>>>>>>>> Check this screenshot:
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>>>
>>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>>> recognize that 'If12' was nested into 'If' and only report that
>>>>>>>> 'If' is added. We should not report that 'If12' is deleted, because
>>>>>>>> it doesn't!
>>>>>>>>
>>>>>>>> There are several possible options:
>>>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>>>> weak result
>>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>>> moved inside 'If' - excellent result
>>>>>>>>
>>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>>> But I still have the same result.
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>>
>>>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>>>> another activity) is very common for BPEL and other programming
>>>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>>>>>> is not possible by design of EMF Compare...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Oleg
>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #135878 is a reply to message #135852] |
Tue, 05 May 2009 07:59 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi,
>
> Sounds interesting :)
> Do you think that someone can use Drools instead of EMF Compare or do
> you plan to use Drools in EMF Compare (to make 'match' phase)?
> Do you have an examples where Drools compares better than 'EMF Compare'?
The idea was more about defining another generic match engine using drools and comparing its performances and quality with the one we are providing right now. I have not result right now, it was just food for though ;)
> As for my MS Thesis I think I would just include two 'extensions' I've
> proposed above, because of time constraints.
>
> Thanks,
> Oleg
>
>
>
> Cédric Brun wrote:
>> Hi Oleg,
>>
>> On thing just stroke me and could be incredibly interesting from a
>> research point of view. Right now we are struggling in matching two
>> versions of elements using custom heuristics and custom model traversal
>> strategies. That's costly, we often browse the model and compute metrics.
>> I've been playing with Drools (JBoss rules engine) lately and this piece
>> of software includes a constraint solver. You can set different research
>> strategies for the solver (using local optimum for instance) and the
>> performances are really really good. Moreover, it's fully java based and
>> integrating an EMF model with that is really easy (a blog post is coming
>> about that !)
>>
>> One could easily imagine to leverage drools-solver with a set of rules to
>> correctly match the elements. No doubt we would get far better
>> performances and better quality too. Handling the "relationship" corner
>> cases would then just be adding a few rules for the matching process.
>>
>> That's another way to tackle the problem, and in my opinion, really
>> promising. Don't know If that would interest you though..
>>
>> Cheers,
>>
>> Cédric
>>
>>
>> Oleg Vazhnev wrote:
>>> Hi Cédric and Laurent
>>>
>>> That's what I read in this paper "Presentation of EMF Compare Utility"
>>> by Antoine Toulmé
>>>
>>> "The problem of this tree comparison is that it is not
>>> convenient for comparing flow charts diagrams
>>> (like BPMN diagrams). Some relationships are
>>> ignored or handled in an invalid way."
>>>
>>> It seems some work was done in my area...
>>> Probably you can point me to mentioned problems (i can try
>>> to solve them then :) I.e. what relationships are ignored
>>> or handled in an invalid way?
>>>
>>> Thanks,
>>> Oleg
>>>
>>> Oleg Vazhnev wrote:
>>>> Thank you Cédric!
>>>>
>>>> Cédric Brun wrote:
>>>>> Hi,
>>>>>
>>>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>>>> question is "Why it was written this way originally?".
>>>>> the implemented algorithm has a some good properties :
>>>>> - it's generic and works even if you compare models from different
>>>>> metamodels
>>>>> - it has quite a pretty good scalability/quality ratio for a generic
>>>>> algorithm.
>>>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>>>
>>>>> That said, the fact that the nested differences were not detected was
>>>>> an arbitrary choice, we wanted to only show the user that a "package
>>>>> has been added" and not that "the package and every elements inside
>>>>> it" has been added. Seems like this choice was not the best in regard
>>>>> to the "move" detection.
>>>>>
>>>>>
>>>>>> Since EMF Compare based on some 'researches' there certainty should
>>>>>> be a reason to write EMF Compare the way it wrote. And I need to know
>>>>>> these reasons before proposing any changes to algorithm :)
>>>>>>
>>>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>>>> will give you an overview and the paper I published with Alfonso
>>>>> Pierantonio might be a good reference too (
>>>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Cédric
>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>>>>
>>>>>> laurent Goubet wrote:
>>>>>>> Hi Oleg,
>>>>>>>
>>>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>>>> "removal"
>>>>>>> of an element to be the only change of its tree, thus "move"
>>>>>>> differences
>>>>>>> within their content tree won't be detected.
>>>>>>>
>>>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>>>> down
>>>>>>> into the unmatched elements to continue the matching phase where we
>>>>>>> stop
>>>>>>> it today, yet this isn't a trivial change.
>>>>>>>
>>>>>>> Could you file an enhancement request for this? Note that this will
>>>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Oleg Vazhnev a écrit :
>>>>>>>> Hi all
>>>>>>>>
>>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>>> means that all the children are deleted. And when the tree is
>>>>>>>> added, EMF Compare reports only the root node. Why? With such
>>>>>>>> design in some cases the comparison result looks weak.
>>>>>>>>
>>>>>>>> The questions are:
>>>>>>>> - Am I correct about my points?
>>>>>>>> - Do you agree that the result of EMF Compare for below situation
>>>>>>>> is not satisfied?
>>>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>>>> below?
>>>>>>>>
>>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>>>> :)
>>>>>>>>
>>>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>>>> imagine and I'm not satisfied with the result.
>>>>>>>>
>>>>>>>> Check this screenshot:
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>>>
>>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>>> recognize that 'If12' was nested into 'If' and only report that
>>>>>>>> 'If' is added. We should not report that 'If12' is deleted, because
>>>>>>>> it doesn't!
>>>>>>>>
>>>>>>>> There are several possible options:
>>>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>>>> weak result
>>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>>> moved inside 'If' - excellent result
>>>>>>>>
>>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>>> But I still have the same result.
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>>
>>>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>>>> another activity) is very common for BPEL and other programming
>>>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>>>>>> is not possible by design of EMF Compare...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Oleg
>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
| |
| Re: Weak comparison - can't match nodes, when nested [message #136190 is a reply to message #136125] |
Wed, 13 May 2009 10:00 |
|
This is a multi-part message in MIME format.
--------------080308060402000609000302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
After putting some thought into it, I think that nope, this cannot be
done in the generic engines. Detection of moves from / to an added /
removed element must be implemented by clients (as you did) as these are
too dependant on the data represented.
To take class diagrams as examples, detecting that a class has been
moved to a new package would be interesting, but detecting that an
attribute has been moved from a removed class to a new class makes no
sense as chances are this attribute really is a new one and not a moved
one (for example if I had a class "Video" with an attribute "title :
String"; I removed "Video" and created "Book" with an attribute "title :
String" => this is clearly not a move ... yet the engine itself cannot
understand it).
Base point is : you needn't fill in an enhancement request as it would
most probably closed as WONTFIX :p.
Thanks anyway ... and cheers :)
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #136375 is a reply to message #136190] |
Wed, 13 May 2009 19:17 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
Thanks for investigation and explanation!
Probably GenericMatchEngine could be improved to allow extensions :)
There are a lot of private things. I was need to change just two or
three methods, but because they are private (and the fields they are
using are private) I've copy-pasted entire GenericMatchEngine.
Probably my solution will not be compatible with further version of EMF
Compare.
Thanks,
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> After putting some thought into it, I think that nope, this cannot be
> done in the generic engines. Detection of moves from / to an added /
> removed element must be implemented by clients (as you did) as these are
> too dependant on the data represented.
>
> To take class diagrams as examples, detecting that a class has been
> moved to a new package would be interesting, but detecting that an
> attribute has been moved from a removed class to a new class makes no
> sense as chances are this attribute really is a new one and not a moved
> one (for example if I had a class "Video" with an attribute "title :
> String"; I removed "Video" and created "Book" with an attribute "title :
> String" => this is clearly not a move ... yet the engine itself cannot
> understand it).
>
> Base point is : you needn't fill in an enhancement request as it would
> most probably closed as WONTFIX :p.
>
> Thanks anyway ... and cheers :)
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi Laurent
>>
>> Are you sure I should file an enhancement request? :)
>> According to Cédric answer there are some points why EMF Compare is
>> wrote this way. And these points still looks legitimate :)
>>
>> I fixed Engine in my plugin to better compare BPEL files.
>> The idea is to use all-level children, not current-level
>> in recursiveMappings() (check my pictures in the attachment)
>>
>> My sources not perfect, I just fixed some "debug points". Likely some
>> addition modifications/refactoring is required to integrate it to EMF
>> Compare code-base.
>>
>> If we really want to fix this, I can create an RFE with my sources in
>> the attachment.
>>
>> Thanks,
>> Oleg
>>
>>
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> As you have guessed, EMF Compare does not consider changes _within_
>>> "unmatched elements" : we consider the top level "addition" or
>>> "removal" of an element to be the only change of its tree, thus
>>> "move" differences within their content tree won't be detected.
>>>
>>> This behavior might be changed from the GenericMatchEngine by going
>>> down into the unmatched elements to continue the matching phase where
>>> we stop it today, yet this isn't a trivial change.
>>>
>>> Could you file an enhancement request for this? Note that this will
>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi all
>>>>
>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>> means that all the children are deleted. And when the tree is added,
>>>> EMF Compare reports only the root node. Why? With such design in
>>>> some cases the comparison result looks weak.
>>>>
>>>> The questions are:
>>>> - Am I correct about my points?
>>>> - Do you agree that the result of EMF Compare for below situation is
>>>> not satisfied?
>>>> - Can I extend EMF compare somehow to better compare the situation
>>>> below?
>>>>
>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>>
>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>> imagine and I'm not satisfied with the result.
>>>>
>>>> Check this screenshot:
>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>> using the same color for 'removed' and 'added' annotations)
>>>>
>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>> is added. We should not report that 'If12' is deleted, because it
>>>> doesn't!
>>>>
>>>> There are several possible options:
>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>> weak result
>>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>> inside 'If' - excellent result
>>>>
>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>> But I still have the same result.
>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>
>>>> Such situation (when a block of code surrounded with if, while, or
>>>> another activity) is very common for BPEL and other programming
>>>> languages. So I'm thinking how to help EMF Compare to better
>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>> is not possible by design of EMF Compare...
>>>>
>>>> Thanks,
>>>> Oleg
>>>
>>
>>
>> ------------------------------------------------------------ ------------
>>
>>
>> ------------------------------------------------------------ ------------
>>
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #136423 is a reply to message #136375] |
Thu, 14 May 2009 08:15 |
|
This is a multi-part message in MIME format.
--------------080902010308050901070504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
Most of the GenericMatchEngine methods are private since we don't really
have "real world" examples of overriding needs. I closed off most of the
engine to allow users to override it yet still allow us to break the API
as we please. Do not hesitate to raise bugs and enhancement request for
the opening of APIs : backed up with a real need you can see what is
private and should be protected better than us :). We don't want to open
everything as we need to keep control of the API and be able to break
some of the methods in there, but obviously we can open it a little more
than it is ^^.
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #136704 is a reply to message #136190] |
Fri, 22 May 2009 08:38 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
I think the algorithm never places 'attributes' in the tree.
Tree contains only 'model elements'. Each model element can have a
number of attributes (may be zero).
Thus we never 'move' attributes, only 'model elements', isn't it? :)
For example Car have a tyre.
But we can say that Car have a wheel which have a tyre.
In this example 'tyre' has been moved from 'Car' to 'wheel' :)
Am I wrong or missing something? :)
Thanks,
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> After putting some thought into it, I think that nope, this cannot be
> done in the generic engines. Detection of moves from / to an added /
> removed element must be implemented by clients (as you did) as these are
> too dependant on the data represented.
>
> To take class diagrams as examples, detecting that a class has been
> moved to a new package would be interesting, but detecting that an
> attribute has been moved from a removed class to a new class makes no
> sense as chances are this attribute really is a new one and not a moved
> one (for example if I had a class "Video" with an attribute "title :
> String"; I removed "Video" and created "Book" with an attribute "title :
> String" => this is clearly not a move ... yet the engine itself cannot
> understand it).
>
> Base point is : you needn't fill in an enhancement request as it would
> most probably closed as WONTFIX :p.
>
> Thanks anyway ... and cheers :)
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi Laurent
>>
>> Are you sure I should file an enhancement request? :)
>> According to Cédric answer there are some points why EMF Compare is
>> wrote this way. And these points still looks legitimate :)
>>
>> I fixed Engine in my plugin to better compare BPEL files.
>> The idea is to use all-level children, not current-level
>> in recursiveMappings() (check my pictures in the attachment)
>>
>> My sources not perfect, I just fixed some "debug points". Likely some
>> addition modifications/refactoring is required to integrate it to EMF
>> Compare code-base.
>>
>> If we really want to fix this, I can create an RFE with my sources in
>> the attachment.
>>
>> Thanks,
>> Oleg
>>
>>
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> As you have guessed, EMF Compare does not consider changes _within_
>>> "unmatched elements" : we consider the top level "addition" or
>>> "removal" of an element to be the only change of its tree, thus
>>> "move" differences within their content tree won't be detected.
>>>
>>> This behavior might be changed from the GenericMatchEngine by going
>>> down into the unmatched elements to continue the matching phase where
>>> we stop it today, yet this isn't a trivial change.
>>>
>>> Could you file an enhancement request for this? Note that this will
>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi all
>>>>
>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>> means that all the children are deleted. And when the tree is added,
>>>> EMF Compare reports only the root node. Why? With such design in
>>>> some cases the comparison result looks weak.
>>>>
>>>> The questions are:
>>>> - Am I correct about my points?
>>>> - Do you agree that the result of EMF Compare for below situation is
>>>> not satisfied?
>>>> - Can I extend EMF compare somehow to better compare the situation
>>>> below?
>>>>
>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>>
>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>> imagine and I'm not satisfied with the result.
>>>>
>>>> Check this screenshot:
>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>> using the same color for 'removed' and 'added' annotations)
>>>>
>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>> is added. We should not report that 'If12' is deleted, because it
>>>> doesn't!
>>>>
>>>> There are several possible options:
>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>> weak result
>>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>> inside 'If' - excellent result
>>>>
>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>> But I still have the same result.
>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>
>>>> Such situation (when a block of code surrounded with if, while, or
>>>> another activity) is very common for BPEL and other programming
>>>> languages. So I'm thinking how to help EMF Compare to better
>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>> is not possible by design of EMF Compare...
>>>>
>>>> Thanks,
>>>> Oleg
>>>
>>
>>
>> ------------------------------------------------------------ ------------
>>
>>
>> ------------------------------------------------------------ ------------
>>
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #136943 is a reply to message #136704] |
Thu, 04 June 2009 15:07 |
|
This is a multi-part message in MIME format.
--------------060603030009050304000008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
You are one step too low in the "meta" :p. "moving an attribute" means
you're referring to class-like diagrams : in the metamodel, a "Class"
contains a set number of "Attribute" (here, "Attribute" is an object
contained by the object "Class"). If "Attribute" were to be moved from
"Class" to, let's say, "Package", then we indeed detect the move of a
model element : "Attribute has been moved from Class to Package".
That said, what you are describing in your example is "the object 'Tyre'
of type 'Attribute' has been moved from 'Car' to 'Wheel'" ... I don't
know if you see what I mean here, "Tyre" is a model element, not a
property of "Car" (is the class "Car" an interface? that is a boolean
property of "Car", not a contained Object).
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #137180 is a reply to message #136943] |
Thu, 11 June 2009 18:54 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
Thanks for tracking this thread! :)
I don't understand your point...
I'm just confused that EMF Compare can't detect such "pairs"
revision 1: matched pair -> child1 -> child2
revision 2: matched pair -> child3 -> child1
EMF Compare will never match child1 in r1 and child1 in r2 because EMF
Compare checks only *immediate* child of matched nodes. (also check this
screenshot http://www.picamatic.com/view/3516586_bpel_62/ ). I've
changed this behavior, but in my opinion it should be by default :)
The problem is not something BPEL-specific, actually it applicable for
any programming language, because you can 'wrap' activity with another
activity in almost any programming language. For example you can wrap
'buy a ticket' to 'repeat buy a ticket until succeed' :) And EMF Compare
doesn't detect such situations...
I'm not guru in EMF Compare, probably I just missing something important
or don't understand completely how it works, I apologize then :)
Now it is not very important for me (I've changed behavior in my own
plugin and I've finished university few weeks ago :), but just to let
you know... if you think that this is actually a problem I can create
new bug then.
Thanks,
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> You are one step too low in the "meta" :p. "moving an attribute" means
> you're referring to class-like diagrams : in the metamodel, a "Class"
> contains a set number of "Attribute" (here, "Attribute" is an object
> contained by the object "Class"). If "Attribute" were to be moved from
> "Class" to, let's say, "Package", then we indeed detect the move of a
> model element : "Attribute has been moved from Class to Package".
>
> That said, what you are describing in your example is "the object 'Tyre'
> of type 'Attribute' has been moved from 'Car' to 'Wheel'" ... I don't
> know if you see what I mean here, "Tyre" is a model element, not a
> property of "Car" (is the class "Car" an interface? that is a boolean
> property of "Car", not a contained Object).
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi Laurent
>>
>> I think the algorithm never places 'attributes' in the tree.
>> Tree contains only 'model elements'. Each model element can have a
>> number of attributes (may be zero).
>> Thus we never 'move' attributes, only 'model elements', isn't it? :)
>>
>> For example Car have a tyre.
>> But we can say that Car have a wheel which have a tyre.
>> In this example 'tyre' has been moved from 'Car' to 'wheel' :)
>>
>> Am I wrong or missing something? :)
>>
>> Thanks,
>> Oleg
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> After putting some thought into it, I think that nope, this cannot be
>>> done in the generic engines. Detection of moves from / to an added /
>>> removed element must be implemented by clients (as you did) as these
>>> are too dependant on the data represented.
>>>
>>> To take class diagrams as examples, detecting that a class has been
>>> moved to a new package would be interesting, but detecting that an
>>> attribute has been moved from a removed class to a new class makes no
>>> sense as chances are this attribute really is a new one and not a
>>> moved one (for example if I had a class "Video" with an attribute
>>> "title : String"; I removed "Video" and created "Book" with an
>>> attribute "title : String" => this is clearly not a move ... yet the
>>> engine itself cannot understand it).
>>>
>>> Base point is : you needn't fill in an enhancement request as it
>>> would most probably closed as WONTFIX :p.
>>>
>>> Thanks anyway ... and cheers :)
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi Laurent
>>>>
>>>> Are you sure I should file an enhancement request? :)
>>>> According to Cédric answer there are some points why EMF Compare is
>>>> wrote this way. And these points still looks legitimate :)
>>>>
>>>> I fixed Engine in my plugin to better compare BPEL files.
>>>> The idea is to use all-level children, not current-level
>>>> in recursiveMappings() (check my pictures in the attachment)
>>>>
>>>> My sources not perfect, I just fixed some "debug points". Likely
>>>> some addition modifications/refactoring is required to integrate it
>>>> to EMF Compare code-base.
>>>>
>>>> If we really want to fix this, I can create an RFE with my sources
>>>> in the attachment.
>>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>>
>>>>
>>>> laurent Goubet wrote:
>>>>> Hi Oleg,
>>>>>
>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>> "removal" of an element to be the only change of its tree, thus
>>>>> "move" differences within their content tree won't be detected.
>>>>>
>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>> down into the unmatched elements to continue the matching phase
>>>>> where we stop it today, yet this isn't a trivial change.
>>>>>
>>>>> Could you file an enhancement request for this? Note that this will
>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Oleg Vazhnev a écrit :
>>>>>> Hi all
>>>>>>
>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>> means that all the children are deleted. And when the tree is
>>>>>> added, EMF Compare reports only the root node. Why? With such
>>>>>> design in some cases the comparison result looks weak.
>>>>>>
>>>>>> The questions are:
>>>>>> - Am I correct about my points?
>>>>>> - Do you agree that the result of EMF Compare for below situation
>>>>>> is not satisfied?
>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>> below?
>>>>>>
>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>> post only about EMF Compare, don't worry about screenshots too
>>>>>> much :)
>>>>>>
>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>> imagine and I'm not satisfied with the result.
>>>>>>
>>>>>> Check this screenshot:
>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>
>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>> recognize that 'If12' was nested into 'If' and only report that
>>>>>> 'If' is added. We should not report that 'If12' is deleted,
>>>>>> because it doesn't!
>>>>>>
>>>>>> There are several possible options:
>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>> weak result
>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>> result
>>>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>>>> inside 'If' - excellent result
>>>>>>
>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>> But I still have the same result.
>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>
>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>> another activity) is very common for BPEL and other programming
>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>>>> is not possible by design of EMF Compare...
>>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------ ------------
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------ ------------
>>>>
>>>>
>>>
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #137192 is a reply to message #137180] |
Fri, 12 June 2009 07:23 |
|
This is a multi-part message in MIME format.
--------------050604020606050506050203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
First of all, congratulations on your graduation :).
What you describe here (detecting "move" differences nested within
"removed" or "added" elements) is not implemented by default since it
isn't meaningful on all metamodels. The engine is sufficiently
extensible to allow clients to specialize it as you did, the other way
around may not be true (if we did make it default).
You've taken the example of activity-like diagrams. Indeed an activity
can be wrapped within another activity in newer versions of a diagram,
and in most cases the "move" difference should be detected. As
mentionned in a previous mail, this might not be true for class-like
diagrams. Note that I am talking here of the class diagram itself, not
models issued from it. For example if I have a class diagram describing
a metamodel containing the Class Video with an attribute "title :
String". I compare this metamodel with another in which the Class
"Video" has been deleted and a new Class "Book" has been created, this
new class containing itself an attribute "title : String". Let me stress
that we compare the metamodels, not the models described using these
metamodels (for example with such metamodels, we could have a model
containing an instance of video titled "Lord of the ring" and another
containing an instance of book titled "Return of the king").
In such a case of comparison, I don't want EMF Compare to detect "title"
to have been moved from "Video" to "Book". That is a new Object, not a
move. The same will apply for custom DSLs that can be compared from EMF
Compare : we have no way within the generic engine to know if an element
nested in a removed or added element is a move or an entirely new
element, thus our generic behavior doesn't detect them.
Of course, the same wouldn't be true for elements sporting an ID (XMI ID
or ID attribute). In this latter case we would be able to tell that
elements have indeed be moved since their ID confirm their equality.
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #137689 is a reply to message #137192] |
Thu, 25 June 2009 18:30 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
Thanks for detailed description! now I understand the issue :)
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> First of all, congratulations on your graduation :).
>
> What you describe here (detecting "move" differences nested within
> "removed" or "added" elements) is not implemented by default since it
> isn't meaningful on all metamodels. The engine is sufficiently
> extensible to allow clients to specialize it as you did, the other way
> around may not be true (if we did make it default).
>
> You've taken the example of activity-like diagrams. Indeed an activity
> can be wrapped within another activity in newer versions of a diagram,
> and in most cases the "move" difference should be detected. As
> mentionned in a previous mail, this might not be true for class-like
> diagrams. Note that I am talking here of the class diagram itself, not
> models issued from it. For example if I have a class diagram describing
> a metamodel containing the Class Video with an attribute "title :
> String". I compare this metamodel with another in which the Class
> "Video" has been deleted and a new Class "Book" has been created, this
> new class containing itself an attribute "title : String". Let me stress
> that we compare the metamodels, not the models described using these
> metamodels (for example with such metamodels, we could have a model
> containing an instance of video titled "Lord of the ring" and another
> containing an instance of book titled "Return of the king").
>
> In such a case of comparison, I don't want EMF Compare to detect "title"
> to have been moved from "Video" to "Book". That is a new Object, not a
> move. The same will apply for custom DSLs that can be compared from EMF
> Compare : we have no way within the generic engine to know if an element
> nested in a removed or added element is a move or an entirely new
> element, thus our generic behavior doesn't detect them.
>
> Of course, the same wouldn't be true for elements sporting an ID (XMI ID
> or ID attribute). In this latter case we would be able to tell that
> elements have indeed be moved since their ID confirm their equality.
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi Laurent
>>
>> Thanks for tracking this thread! :)
>> I don't understand your point...
>> I'm just confused that EMF Compare can't detect such "pairs"
>>
>> revision 1: matched pair -> child1 -> child2
>> revision 2: matched pair -> child3 -> child1
>>
>> EMF Compare will never match child1 in r1 and child1 in r2 because EMF
>> Compare checks only *immediate* child of matched nodes. (also check
>> this screenshot http://www.picamatic.com/view/3516586_bpel_62/ ). I've
>> changed this behavior, but in my opinion it should be by default :)
>>
>> The problem is not something BPEL-specific, actually it applicable for
>> any programming language, because you can 'wrap' activity with another
>> activity in almost any programming language. For example you can wrap
>> 'buy a ticket' to 'repeat buy a ticket until succeed' :) And EMF
>> Compare doesn't detect such situations...
>>
>> I'm not guru in EMF Compare, probably I just missing something
>> important or don't understand completely how it works, I apologize
>> then :)
>>
>> Now it is not very important for me (I've changed behavior in my own
>> plugin and I've finished university few weeks ago :), but just to let
>> you know... if you think that this is actually a problem I can create
>> new bug then.
>>
>> Thanks,
>> Oleg
>>
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> You are one step too low in the "meta" :p. "moving an attribute"
>>> means you're referring to class-like diagrams : in the metamodel, a
>>> "Class" contains a set number of "Attribute" (here, "Attribute" is an
>>> object contained by the object "Class"). If "Attribute" were to be
>>> moved from "Class" to, let's say, "Package", then we indeed detect
>>> the move of a model element : "Attribute has been moved from Class to
>>> Package".
>>>
>>> That said, what you are describing in your example is "the object
>>> 'Tyre' of type 'Attribute' has been moved from 'Car' to 'Wheel'" ...
>>> I don't know if you see what I mean here, "Tyre" is a model element,
>>> not a property of "Car" (is the class "Car" an interface? that is a
>>> boolean property of "Car", not a contained Object).
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi Laurent
>>>>
>>>> I think the algorithm never places 'attributes' in the tree.
>>>> Tree contains only 'model elements'. Each model element can have a
>>>> number of attributes (may be zero).
>>>> Thus we never 'move' attributes, only 'model elements', isn't it? :)
>>>>
>>>> For example Car have a tyre.
>>>> But we can say that Car have a wheel which have a tyre.
>>>> In this example 'tyre' has been moved from 'Car' to 'wheel' :)
>>>>
>>>> Am I wrong or missing something? :)
>>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>> laurent Goubet wrote:
>>>>> Hi Oleg,
>>>>>
>>>>> After putting some thought into it, I think that nope, this cannot
>>>>> be done in the generic engines. Detection of moves from / to an
>>>>> added / removed element must be implemented by clients (as you did)
>>>>> as these are too dependant on the data represented.
>>>>>
>>>>> To take class diagrams as examples, detecting that a class has been
>>>>> moved to a new package would be interesting, but detecting that an
>>>>> attribute has been moved from a removed class to a new class makes
>>>>> no sense as chances are this attribute really is a new one and not
>>>>> a moved one (for example if I had a class "Video" with an attribute
>>>>> "title : String"; I removed "Video" and created "Book" with an
>>>>> attribute "title : String" => this is clearly not a move ... yet
>>>>> the engine itself cannot understand it).
>>>>>
>>>>> Base point is : you needn't fill in an enhancement request as it
>>>>> would most probably closed as WONTFIX :p.
>>>>>
>>>>> Thanks anyway ... and cheers :)
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Oleg Vazhnev a écrit :
>>>>>> Hi Laurent
>>>>>>
>>>>>> Are you sure I should file an enhancement request? :)
>>>>>> According to Cédric answer there are some points why EMF Compare
>>>>>> is wrote this way. And these points still looks legitimate :)
>>>>>>
>>>>>> I fixed Engine in my plugin to better compare BPEL files.
>>>>>> The idea is to use all-level children, not current-level
>>>>>> in recursiveMappings() (check my pictures in the attachment)
>>>>>>
>>>>>> My sources not perfect, I just fixed some "debug points". Likely
>>>>>> some addition modifications/refactoring is required to integrate
>>>>>> it to EMF Compare code-base.
>>>>>>
>>>>>> If we really want to fix this, I can create an RFE with my sources
>>>>>> in the attachment.
>>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>>>>
>>>>>>
>>>>>>
>>>>>> laurent Goubet wrote:
>>>>>>> Hi Oleg,
>>>>>>>
>>>>>>> As you have guessed, EMF Compare does not consider changes
>>>>>>> _within_ "unmatched elements" : we consider the top level
>>>>>>> "addition" or "removal" of an element to be the only change of
>>>>>>> its tree, thus "move" differences within their content tree won't
>>>>>>> be detected.
>>>>>>>
>>>>>>> This behavior might be changed from the GenericMatchEngine by
>>>>>>> going down into the unmatched elements to continue the matching
>>>>>>> phase where we stop it today, yet this isn't a trivial change.
>>>>>>>
>>>>>>> Could you file an enhancement request for this? Note that this
>>>>>>> will clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Oleg Vazhnev a écrit :
>>>>>>>> Hi all
>>>>>>>>
>>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>>> means that all the children are deleted. And when the tree is
>>>>>>>> added, EMF Compare reports only the root node. Why? With such
>>>>>>>> design in some cases the comparison result looks weak.
>>>>>>>>
>>>>>>>> The questions are:
>>>>>>>> - Am I correct about my points?
>>>>>>>> - Do you agree that the result of EMF Compare for below
>>>>>>>> situation is not satisfied?
>>>>>>>> - Can I extend EMF compare somehow to better compare the
>>>>>>>> situation below?
>>>>>>>>
>>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But
>>>>>>>> this post only about EMF Compare, don't worry about screenshots
>>>>>>>> too much :)
>>>>>>>>
>>>>>>>> I've tried to give to EMF Compare the first non-obvious task I
>>>>>>>> can imagine and I'm not satisfied with the result.
>>>>>>>>
>>>>>>>> Check this screenshot:
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added
>>>>>>>> (i'm using the same color for 'removed' and 'added' annotations)
>>>>>>>>
>>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>>> recognize that 'If12' was nested into 'If' and only report that
>>>>>>>> 'If' is added. We should not report that 'If12' is deleted,
>>>>>>>> because it doesn't!
>>>>>>>>
>>>>>>>> There are several possible options:
>>>>>>>> 1. report that If12 is renamed to If, and another If12 is added.
>>>>>>>> - weak result
>>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>>> result
>>>>>>>> 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>>> moved inside 'If' - excellent result
>>>>>>>>
>>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>>> But I still have the same result.
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>>
>>>>>>>> Such situation (when a block of code surrounded with if, while,
>>>>>>>> or another activity) is very common for BPEL and other
>>>>>>>> programming languages. So I'm thinking how to help EMF Compare
>>>>>>>> to better recognize such situations. Any tips are welcome. But
>>>>>>>> I'm afraid it is not possible by design of EMF Compare...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Oleg
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------ ------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------ ------------
>>>>>>
>>>>>>
>>>>>
>>>
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620896 is a reply to message #135600] |
Thu, 30 April 2009 08:22 |
|
This is a multi-part message in MIME format.
--------------070404050705010901060300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
As you have guessed, EMF Compare does not consider changes _within_
"unmatched elements" : we consider the top level "addition" or "removal"
of an element to be the only change of its tree, thus "move" differences
within their content tree won't be detected.
This behavior might be changed from the GenericMatchEngine by going down
into the unmatched elements to continue the matching phase where we stop
it today, yet this isn't a trivial change.
Could you file an enhancement request for this? Note that this will
clearly not be done for Galileo as we are now in the M7 phase.
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620899 is a reply to message #135652] |
Thu, 30 April 2009 10:09 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
Thank you for fast response.
Actually I can try to implement the change.
I'm writing my plugin as Master Thesis, but the plugin itself is just
'engineering task' so I'm looking for some 'scientific' task to include
in my thesis.
I think I can propose the change to EMF Compare algorithm, but the
question is "Why it was written this way originally?".
I read in FAQ that EMF Compare based on many researches, mostly on
"UMLDiff: An Algorithm for Object-OrientedDesign Differencing"
Since EMF Compare based on some 'researches' there certainty should be a
reason to write EMF Compare the way it wrote. And I need to know these
reasons before proposing any changes to algorithm :)
BTW what is the best source to learn the algorithm of EMF Compare?
Thanks,
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> As you have guessed, EMF Compare does not consider changes _within_
> "unmatched elements" : we consider the top level "addition" or "removal"
> of an element to be the only change of its tree, thus "move" differences
> within their content tree won't be detected.
>
> This behavior might be changed from the GenericMatchEngine by going down
> into the unmatched elements to continue the matching phase where we stop
> it today, yet this isn't a trivial change.
>
> Could you file an enhancement request for this? Note that this will
> clearly not be done for Galileo as we are now in the M7 phase.
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi all
>>
>> I've noticed that if EMF Compare reports that node is deleted it means
>> that all the children are deleted. And when the tree is added, EMF
>> Compare reports only the root node. Why? With such design in some
>> cases the comparison result looks weak.
>>
>> The questions are:
>> - Am I correct about my points?
>> - Do you agree that the result of EMF Compare for below situation is
>> not satisfied?
>> - Can I extend EMF compare somehow to better compare the situation below?
>>
>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>> post only about EMF Compare, don't worry about screenshots too much :)
>>
>> I've tried to give to EMF Compare the first non-obvious task I can
>> imagine and I'm not satisfied with the result.
>>
>> Check this screenshot:
>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>> using the same color for 'removed' and 'added' annotations)
>>
>> But, In my opinion, it is not 'good' comparison result. We can
>> recognize that 'If12' was nested into 'If' and only report that 'If'
>> is added. We should not report that 'If12' is deleted, because it
>> doesn't!
>>
>> There are several possible options:
>> 1. report that If12 is renamed to If, and another If12 is added. -
>> weak result
>> 2. report that If12 is deleted and If and If12 are added - weak result
>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>> inside 'If' - excellent result
>>
>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>> But I still have the same result.
>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>
>> Such situation (when a block of code surrounded with if, while, or
>> another activity) is very common for BPEL and other programming
>> languages. So I'm thinking how to help EMF Compare to better recognize
>> such situations. Any tips are welcome. But I'm afraid it is not
>> possible by design of EMF Compare...
>>
>> Thanks,
>> Oleg
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620900 is a reply to message #135691] |
Thu, 30 April 2009 11:10 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi,
> I think I can propose the change to EMF Compare algorithm, but the
> question is "Why it was written this way originally?".
the implemented algorithm has a some good properties :
- it's generic and works even if you compare models from different metamodels
- it has quite a pretty good scalability/quality ratio for a generic algorithm.
- it works both for "litle" (library) and "big" metamodels.(UML)
That said, the fact that the nested differences were not detected was an arbitrary choice, we wanted to only show the user that a "package has been added" and not that "the package and every elements inside it" has been added. Seems like this choice was not the best in regard to the "move" detection.
> Since EMF Compare based on some 'researches' there certainty should be a
> reason to write EMF Compare the way it wrote. And I need to know these
> reasons before proposing any changes to algorithm :)
>
> BTW what is the best source to learn the algorithm of EMF Compare?
Use the code Luke ! ;) The code is the best place, the UMLdiff paper will give you an overview and the paper I published with Alfonso Pierantonio might be a good reference too (
http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
Cheers,
Cédric
>
> Thanks,
> Oleg
>
> laurent Goubet wrote:
>> Hi Oleg,
>>
>> As you have guessed, EMF Compare does not consider changes _within_
>> "unmatched elements" : we consider the top level "addition" or "removal"
>> of an element to be the only change of its tree, thus "move" differences
>> within their content tree won't be detected.
>>
>> This behavior might be changed from the GenericMatchEngine by going down
>> into the unmatched elements to continue the matching phase where we stop
>> it today, yet this isn't a trivial change.
>>
>> Could you file an enhancement request for this? Note that this will
>> clearly not be done for Galileo as we are now in the M7 phase.
>>
>> Laurent Goubet
>> Obeo
>>
>> Oleg Vazhnev a écrit :
>>> Hi all
>>>
>>> I've noticed that if EMF Compare reports that node is deleted it means
>>> that all the children are deleted. And when the tree is added, EMF
>>> Compare reports only the root node. Why? With such design in some
>>> cases the comparison result looks weak.
>>>
>>> The questions are:
>>> - Am I correct about my points?
>>> - Do you agree that the result of EMF Compare for below situation is
>>> not satisfied?
>>> - Can I extend EMF compare somehow to better compare the situation
>>> below?
>>>
>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>
>>> I've tried to give to EMF Compare the first non-obvious task I can
>>> imagine and I'm not satisfied with the result.
>>>
>>> Check this screenshot:
>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>> using the same color for 'removed' and 'added' annotations)
>>>
>>> But, In my opinion, it is not 'good' comparison result. We can
>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>> is added. We should not report that 'If12' is deleted, because it
>>> doesn't!
>>>
>>> There are several possible options:
>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>> weak result
>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>> inside 'If' - excellent result
>>>
>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>> But I still have the same result.
>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>
>>> Such situation (when a block of code surrounded with if, while, or
>>> another activity) is very common for BPEL and other programming
>>> languages. So I'm thinking how to help EMF Compare to better recognize
>>> such situations. Any tips are welcome. But I'm afraid it is not
>>> possible by design of EMF Compare...
>>>
>>> Thanks,
>>> Oleg
>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620901 is a reply to message #135705] |
Thu, 30 April 2009 13:36 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Thank you Cédric!
Cédric Brun wrote:
> Hi,
>
>> I think I can propose the change to EMF Compare algorithm, but the
>> question is "Why it was written this way originally?".
>
> the implemented algorithm has a some good properties :
> - it's generic and works even if you compare models from different metamodels
> - it has quite a pretty good scalability/quality ratio for a generic algorithm.
> - it works both for "litle" (library) and "big" metamodels.(UML)
>
> That said, the fact that the nested differences were not detected was an arbitrary choice, we wanted to only show the user that a "package has been added" and not that "the package and every elements inside it" has been added. Seems like this choice was not the best in regard to the "move" detection.
>
>
>> Since EMF Compare based on some 'researches' there certainty should be a
>> reason to write EMF Compare the way it wrote. And I need to know these
>> reasons before proposing any changes to algorithm :)
>>
>> BTW what is the best source to learn the algorithm of EMF Compare?
> Use the code Luke ! ;) The code is the best place, the UMLdiff paper will give you an overview and the paper I published with Alfonso Pierantonio might be a good reference too (
> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>
> Cheers,
>
> Cédric
>
>> Thanks,
>> Oleg
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> As you have guessed, EMF Compare does not consider changes _within_
>>> "unmatched elements" : we consider the top level "addition" or "removal"
>>> of an element to be the only change of its tree, thus "move" differences
>>> within their content tree won't be detected.
>>>
>>> This behavior might be changed from the GenericMatchEngine by going down
>>> into the unmatched elements to continue the matching phase where we stop
>>> it today, yet this isn't a trivial change.
>>>
>>> Could you file an enhancement request for this? Note that this will
>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi all
>>>>
>>>> I've noticed that if EMF Compare reports that node is deleted it means
>>>> that all the children are deleted. And when the tree is added, EMF
>>>> Compare reports only the root node. Why? With such design in some
>>>> cases the comparison result looks weak.
>>>>
>>>> The questions are:
>>>> - Am I correct about my points?
>>>> - Do you agree that the result of EMF Compare for below situation is
>>>> not satisfied?
>>>> - Can I extend EMF compare somehow to better compare the situation
>>>> below?
>>>>
>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>>
>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>> imagine and I'm not satisfied with the result.
>>>>
>>>> Check this screenshot:
>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>> using the same color for 'removed' and 'added' annotations)
>>>>
>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>> is added. We should not report that 'If12' is deleted, because it
>>>> doesn't!
>>>>
>>>> There are several possible options:
>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>> weak result
>>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>> inside 'If' - excellent result
>>>>
>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>> But I still have the same result.
>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>
>>>> Such situation (when a block of code surrounded with if, while, or
>>>> another activity) is very common for BPEL and other programming
>>>> languages. So I'm thinking how to help EMF Compare to better recognize
>>>> such situations. Any tips are welcome. But I'm afraid it is not
>>>> possible by design of EMF Compare...
>>>>
>>>> Thanks,
>>>> Oleg
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620902 is a reply to message #135716] |
Sat, 02 May 2009 18:02 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Cédric and Laurent
That's what I read in this paper "Presentation of EMF Compare Utility"
by Antoine Toulmé
"The problem of this tree comparison is that it is not
convenient for comparing flow charts diagrams
(like BPMN diagrams). Some relationships are
ignored or handled in an invalid way."
It seems some work was done in my area...
Probably you can point me to mentioned problems (i can try
to solve them then :) I.e. what relationships are ignored
or handled in an invalid way?
Thanks,
Oleg
Oleg Vazhnev wrote:
> Thank you Cédric!
>
> Cédric Brun wrote:
>> Hi,
>>
>>> I think I can propose the change to EMF Compare algorithm, but the
>>> question is "Why it was written this way originally?".
>>
>> the implemented algorithm has a some good properties :
>> - it's generic and works even if you compare models from different
>> metamodels
>> - it has quite a pretty good scalability/quality ratio for a generic
>> algorithm.
>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>
>> That said, the fact that the nested differences were not detected was
>> an arbitrary choice, we wanted to only show the user that a "package
>> has been added" and not that "the package and every elements inside
>> it" has been added. Seems like this choice was not the best in regard
>> to the "move" detection.
>>
>>
>>> Since EMF Compare based on some 'researches' there certainty should be a
>>> reason to write EMF Compare the way it wrote. And I need to know these
>>> reasons before proposing any changes to algorithm :)
>>>
>>> BTW what is the best source to learn the algorithm of EMF Compare?
>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>> will give you an overview and the paper I published with Alfonso
>> Pierantonio might be a good reference too (
>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>
>> Cheers,
>>
>> Cédric
>>
>>> Thanks,
>>> Oleg
>>>
>>> laurent Goubet wrote:
>>>> Hi Oleg,
>>>>
>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>> "unmatched elements" : we consider the top level "addition" or
>>>> "removal"
>>>> of an element to be the only change of its tree, thus "move"
>>>> differences
>>>> within their content tree won't be detected.
>>>>
>>>> This behavior might be changed from the GenericMatchEngine by going
>>>> down
>>>> into the unmatched elements to continue the matching phase where we
>>>> stop
>>>> it today, yet this isn't a trivial change.
>>>>
>>>> Could you file an enhancement request for this? Note that this will
>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>
>>>> Laurent Goubet
>>>> Obeo
>>>>
>>>> Oleg Vazhnev a écrit :
>>>>> Hi all
>>>>>
>>>>> I've noticed that if EMF Compare reports that node is deleted it means
>>>>> that all the children are deleted. And when the tree is added, EMF
>>>>> Compare reports only the root node. Why? With such design in some
>>>>> cases the comparison result looks weak.
>>>>>
>>>>> The questions are:
>>>>> - Am I correct about my points?
>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>> not satisfied?
>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>> below?
>>>>>
>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>>>
>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>> imagine and I'm not satisfied with the result.
>>>>>
>>>>> Check this screenshot:
>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>
>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>> doesn't!
>>>>>
>>>>> There are several possible options:
>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>> weak result
>>>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>>> inside 'If' - excellent result
>>>>>
>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>> But I still have the same result.
>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>
>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>> another activity) is very common for BPEL and other programming
>>>>> languages. So I'm thinking how to help EMF Compare to better recognize
>>>>> such situations. Any tips are welcome. But I'm afraid it is not
>>>>> possible by design of EMF Compare...
>>>>>
>>>>> Thanks,
>>>>> Oleg
>>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620906 is a reply to message #135729] |
Mon, 04 May 2009 08:01 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Oleg,
>
> That's what I read in this paper "Presentation of EMF Compare Utility"
> by Antoine Toulmé
Yes, that paper was presenting some part of the initial contribution. (quite old but the problem are still valid)
>
> "The problem of this tree comparison is that it is not
> convenient for comparing flow charts diagrams
> (like BPMN diagrams). Some relationships are
> ignored or handled in an invalid way."
The problem is a generic one, some times, especially on "association like" elements, we don't have enough information to match correctly two versions of a relationship. That causes a "this relationship has been removed / this relationship has been added" diff instead of a "this relationship has been changed".
The problem is a tricky one as we don't have much information to match these elements and we should probably consider them in a specific way.
We're open to suggestions :)
Cédric
> Oleg
>
> Oleg Vazhnev wrote:
>> Thank you Cédric!
>>
>> Cédric Brun wrote:
>>> Hi,
>>>
>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>> question is "Why it was written this way originally?".
>>>
>>> the implemented algorithm has a some good properties :
>>> - it's generic and works even if you compare models from different
>>> metamodels
>>> - it has quite a pretty good scalability/quality ratio for a generic
>>> algorithm.
>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>
>>> That said, the fact that the nested differences were not detected was
>>> an arbitrary choice, we wanted to only show the user that a "package
>>> has been added" and not that "the package and every elements inside
>>> it" has been added. Seems like this choice was not the best in regard
>>> to the "move" detection.
>>>
>>>
>>>> Since EMF Compare based on some 'researches' there certainty should be
>>>> a reason to write EMF Compare the way it wrote. And I need to know
>>>> these reasons before proposing any changes to algorithm :)
>>>>
>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>> will give you an overview and the paper I published with Alfonso
>>> Pierantonio might be a good reference too (
>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>
>>> Cheers,
>>>
>>> Cédric
>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>> laurent Goubet wrote:
>>>>> Hi Oleg,
>>>>>
>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>> "removal"
>>>>> of an element to be the only change of its tree, thus "move"
>>>>> differences
>>>>> within their content tree won't be detected.
>>>>>
>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>> down
>>>>> into the unmatched elements to continue the matching phase where we
>>>>> stop
>>>>> it today, yet this isn't a trivial change.
>>>>>
>>>>> Could you file an enhancement request for this? Note that this will
>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Oleg Vazhnev a écrit :
>>>>>> Hi all
>>>>>>
>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>> means that all the children are deleted. And when the tree is added,
>>>>>> EMF Compare reports only the root node. Why? With such design in some
>>>>>> cases the comparison result looks weak.
>>>>>>
>>>>>> The questions are:
>>>>>> - Am I correct about my points?
>>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>>> not satisfied?
>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>> below?
>>>>>>
>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>> :)
>>>>>>
>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>> imagine and I'm not satisfied with the result.
>>>>>>
>>>>>> Check this screenshot:
>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>
>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>>> doesn't!
>>>>>>
>>>>>> There are several possible options:
>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>> weak result
>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>> moved inside 'If' - excellent result
>>>>>>
>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>> But I still have the same result.
>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>
>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>> another activity) is very common for BPEL and other programming
>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it is
>>>>>> not possible by design of EMF Compare...
>>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620909 is a reply to message #135729] |
Mon, 04 May 2009 16:21 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Oleg,
On thing just stroke me and could be incredibly interesting from a research point of view. Right now we are struggling in matching two versions of elements using custom heuristics and custom model traversal strategies. That's costly, we often browse the model and compute metrics.
I've been playing with Drools (JBoss rules engine) lately and this piece of software includes a constraint solver. You can set different research strategies for the solver (using local optimum for instance) and the performances are really really good. Moreover, it's fully java based and integrating an EMF model with that is really easy (a blog post is coming about that !)
One could easily imagine to leverage drools-solver with a set of rules to correctly match the elements. No doubt we would get far better performances and better quality too. Handling the "relationship" corner cases would then just be adding a few rules for the matching process.
That's another way to tackle the problem, and in my opinion, really promising. Don't know If that would interest you though..
Cheers,
Cédric
Oleg Vazhnev wrote:
> Hi Cédric and Laurent
>
> That's what I read in this paper "Presentation of EMF Compare Utility"
> by Antoine Toulmé
>
> "The problem of this tree comparison is that it is not
> convenient for comparing flow charts diagrams
> (like BPMN diagrams). Some relationships are
> ignored or handled in an invalid way."
>
> It seems some work was done in my area...
> Probably you can point me to mentioned problems (i can try
> to solve them then :) I.e. what relationships are ignored
> or handled in an invalid way?
>
> Thanks,
> Oleg
>
> Oleg Vazhnev wrote:
>> Thank you Cédric!
>>
>> Cédric Brun wrote:
>>> Hi,
>>>
>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>> question is "Why it was written this way originally?".
>>>
>>> the implemented algorithm has a some good properties :
>>> - it's generic and works even if you compare models from different
>>> metamodels
>>> - it has quite a pretty good scalability/quality ratio for a generic
>>> algorithm.
>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>
>>> That said, the fact that the nested differences were not detected was
>>> an arbitrary choice, we wanted to only show the user that a "package
>>> has been added" and not that "the package and every elements inside
>>> it" has been added. Seems like this choice was not the best in regard
>>> to the "move" detection.
>>>
>>>
>>>> Since EMF Compare based on some 'researches' there certainty should be
>>>> a reason to write EMF Compare the way it wrote. And I need to know
>>>> these reasons before proposing any changes to algorithm :)
>>>>
>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>> will give you an overview and the paper I published with Alfonso
>>> Pierantonio might be a good reference too (
>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>
>>> Cheers,
>>>
>>> Cédric
>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>> laurent Goubet wrote:
>>>>> Hi Oleg,
>>>>>
>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>> "removal"
>>>>> of an element to be the only change of its tree, thus "move"
>>>>> differences
>>>>> within their content tree won't be detected.
>>>>>
>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>> down
>>>>> into the unmatched elements to continue the matching phase where we
>>>>> stop
>>>>> it today, yet this isn't a trivial change.
>>>>>
>>>>> Could you file an enhancement request for this? Note that this will
>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Oleg Vazhnev a écrit :
>>>>>> Hi all
>>>>>>
>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>> means that all the children are deleted. And when the tree is added,
>>>>>> EMF Compare reports only the root node. Why? With such design in some
>>>>>> cases the comparison result looks weak.
>>>>>>
>>>>>> The questions are:
>>>>>> - Am I correct about my points?
>>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>>> not satisfied?
>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>> below?
>>>>>>
>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>> :)
>>>>>>
>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>> imagine and I'm not satisfied with the result.
>>>>>>
>>>>>> Check this screenshot:
>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>
>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>>> doesn't!
>>>>>>
>>>>>> There are several possible options:
>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>> weak result
>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>> moved inside 'If' - excellent result
>>>>>>
>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>> But I still have the same result.
>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>
>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>> another activity) is very common for BPEL and other programming
>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it is
>>>>>> not possible by design of EMF Compare...
>>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620910 is a reply to message #135788] |
Mon, 04 May 2009 22:10 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Cédric
It would be nice if you can provide an example :)
So far I've found two points where I want to change the behavior of EMF
Compare for my plugin.
1. I want EMF Compare to count 'name' attribute with a special very very
high priority. Because two activities with the same name - most likely
the same activities. This issue was raised in UMLDiff algorithm, but it
seems EMF Compare can't recognize that 'name' attribute is very
important. Check this screenshot:
http://www.picamatic.com/show/2009/05/05/01/57/3516577_478x3 53.PNG
I expect here to see that 'RepeatUntil1' was added.
2. The issue I described originally in this thread
Also check this screenshot:
http://www.picamatic.com/show/2009/05/05/01/58/3516586_425x2 94.PNG
I think having fixed these two issue EMF Compare will compare .bpel
files much better :)
I plan to debug EMF Compare a little to understand how can I solve the
first issue.
I plan to debug GenericMatchEngine (as Laurent suggested) to understand
how to force algorithm "to go inside till leafs" :) Hope I can 'plug'
this functionality just extending the class in some manner...
Thanks,
Oleg
Cédric Brun wrote:
> Hi Oleg,
>
>
>> That's what I read in this paper "Presentation of EMF Compare Utility"
>> by Antoine Toulmé
>
> Yes, that paper was presenting some part of the initial contribution. (quite old but the problem are still valid)
>
>> "The problem of this tree comparison is that it is not
>> convenient for comparing flow charts diagrams
>> (like BPMN diagrams). Some relationships are
>> ignored or handled in an invalid way."
>
> The problem is a generic one, some times, especially on "association like" elements, we don't have enough information to match correctly two versions of a relationship. That causes a "this relationship has been removed / this relationship has been added" diff instead of a "this relationship has been changed".
>
> The problem is a tricky one as we don't have much information to match these elements and we should probably consider them in a specific way.
>
> We're open to suggestions :)
>
>
> Cédric
>
>> Oleg
>>
>> Oleg Vazhnev wrote:
>>> Thank you Cédric!
>>>
>>> Cédric Brun wrote:
>>>> Hi,
>>>>
>>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>>> question is "Why it was written this way originally?".
>>>> the implemented algorithm has a some good properties :
>>>> - it's generic and works even if you compare models from different
>>>> metamodels
>>>> - it has quite a pretty good scalability/quality ratio for a generic
>>>> algorithm.
>>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>>
>>>> That said, the fact that the nested differences were not detected was
>>>> an arbitrary choice, we wanted to only show the user that a "package
>>>> has been added" and not that "the package and every elements inside
>>>> it" has been added. Seems like this choice was not the best in regard
>>>> to the "move" detection.
>>>>
>>>>
>>>>> Since EMF Compare based on some 'researches' there certainty should be
>>>>> a reason to write EMF Compare the way it wrote. And I need to know
>>>>> these reasons before proposing any changes to algorithm :)
>>>>>
>>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>>> will give you an overview and the paper I published with Alfonso
>>>> Pierantonio might be a good reference too (
>>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>>
>>>> Cheers,
>>>>
>>>> Cédric
>>>>
>>>>> Thanks,
>>>>> Oleg
>>>>>
>>>>> laurent Goubet wrote:
>>>>>> Hi Oleg,
>>>>>>
>>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>>> "removal"
>>>>>> of an element to be the only change of its tree, thus "move"
>>>>>> differences
>>>>>> within their content tree won't be detected.
>>>>>>
>>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>>> down
>>>>>> into the unmatched elements to continue the matching phase where we
>>>>>> stop
>>>>>> it today, yet this isn't a trivial change.
>>>>>>
>>>>>> Could you file an enhancement request for this? Note that this will
>>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>
>>>>>> Laurent Goubet
>>>>>> Obeo
>>>>>>
>>>>>> Oleg Vazhnev a écrit :
>>>>>>> Hi all
>>>>>>>
>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>> means that all the children are deleted. And when the tree is added,
>>>>>>> EMF Compare reports only the root node. Why? With such design in some
>>>>>>> cases the comparison result looks weak.
>>>>>>>
>>>>>>> The questions are:
>>>>>>> - Am I correct about my points?
>>>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>>>> not satisfied?
>>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>>> below?
>>>>>>>
>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>>> :)
>>>>>>>
>>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>>> imagine and I'm not satisfied with the result.
>>>>>>>
>>>>>>> Check this screenshot:
>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>>
>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>>>> doesn't!
>>>>>>>
>>>>>>> There are several possible options:
>>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>>> weak result
>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>> moved inside 'If' - excellent result
>>>>>>>
>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>> But I still have the same result.
>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>
>>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>>> another activity) is very common for BPEL and other programming
>>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it is
>>>>>>> not possible by design of EMF Compare...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Oleg
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620911 is a reply to message #135825] |
Mon, 04 May 2009 22:28 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Cédric
Sounds interesting :)
Do you think that someone can use Drools instead of EMF Compare or do
you plan to use Drools in EMF Compare (to make 'match' phase)?
Do you have an examples where Drools compares better than 'EMF Compare'?
As for my MS Thesis I think I would just include two 'extensions' I've
proposed above, because of time constraints.
Thanks,
Oleg
Cédric Brun wrote:
> Hi Oleg,
>
> On thing just stroke me and could be incredibly interesting from a research point of view. Right now we are struggling in matching two versions of elements using custom heuristics and custom model traversal strategies. That's costly, we often browse the model and compute metrics.
> I've been playing with Drools (JBoss rules engine) lately and this piece of software includes a constraint solver. You can set different research strategies for the solver (using local optimum for instance) and the performances are really really good. Moreover, it's fully java based and integrating an EMF model with that is really easy (a blog post is coming about that !)
>
> One could easily imagine to leverage drools-solver with a set of rules to correctly match the elements. No doubt we would get far better performances and better quality too. Handling the "relationship" corner cases would then just be adding a few rules for the matching process.
>
> That's another way to tackle the problem, and in my opinion, really promising. Don't know If that would interest you though..
>
> Cheers,
>
> Cédric
>
>
> Oleg Vazhnev wrote:
>> Hi Cédric and Laurent
>>
>> That's what I read in this paper "Presentation of EMF Compare Utility"
>> by Antoine Toulmé
>>
>> "The problem of this tree comparison is that it is not
>> convenient for comparing flow charts diagrams
>> (like BPMN diagrams). Some relationships are
>> ignored or handled in an invalid way."
>>
>> It seems some work was done in my area...
>> Probably you can point me to mentioned problems (i can try
>> to solve them then :) I.e. what relationships are ignored
>> or handled in an invalid way?
>>
>> Thanks,
>> Oleg
>>
>> Oleg Vazhnev wrote:
>>> Thank you Cédric!
>>>
>>> Cédric Brun wrote:
>>>> Hi,
>>>>
>>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>>> question is "Why it was written this way originally?".
>>>> the implemented algorithm has a some good properties :
>>>> - it's generic and works even if you compare models from different
>>>> metamodels
>>>> - it has quite a pretty good scalability/quality ratio for a generic
>>>> algorithm.
>>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>>
>>>> That said, the fact that the nested differences were not detected was
>>>> an arbitrary choice, we wanted to only show the user that a "package
>>>> has been added" and not that "the package and every elements inside
>>>> it" has been added. Seems like this choice was not the best in regard
>>>> to the "move" detection.
>>>>
>>>>
>>>>> Since EMF Compare based on some 'researches' there certainty should be
>>>>> a reason to write EMF Compare the way it wrote. And I need to know
>>>>> these reasons before proposing any changes to algorithm :)
>>>>>
>>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>>> will give you an overview and the paper I published with Alfonso
>>>> Pierantonio might be a good reference too (
>>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>>
>>>> Cheers,
>>>>
>>>> Cédric
>>>>
>>>>> Thanks,
>>>>> Oleg
>>>>>
>>>>> laurent Goubet wrote:
>>>>>> Hi Oleg,
>>>>>>
>>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>>> "removal"
>>>>>> of an element to be the only change of its tree, thus "move"
>>>>>> differences
>>>>>> within their content tree won't be detected.
>>>>>>
>>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>>> down
>>>>>> into the unmatched elements to continue the matching phase where we
>>>>>> stop
>>>>>> it today, yet this isn't a trivial change.
>>>>>>
>>>>>> Could you file an enhancement request for this? Note that this will
>>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>
>>>>>> Laurent Goubet
>>>>>> Obeo
>>>>>>
>>>>>> Oleg Vazhnev a écrit :
>>>>>>> Hi all
>>>>>>>
>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>> means that all the children are deleted. And when the tree is added,
>>>>>>> EMF Compare reports only the root node. Why? With such design in some
>>>>>>> cases the comparison result looks weak.
>>>>>>>
>>>>>>> The questions are:
>>>>>>> - Am I correct about my points?
>>>>>>> - Do you agree that the result of EMF Compare for below situation is
>>>>>>> not satisfied?
>>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>>> below?
>>>>>>>
>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>>> :)
>>>>>>>
>>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>>> imagine and I'm not satisfied with the result.
>>>>>>>
>>>>>>> Check this screenshot:
>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>>
>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>>>>> is added. We should not report that 'If12' is deleted, because it
>>>>>>> doesn't!
>>>>>>>
>>>>>>> There are several possible options:
>>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>>> weak result
>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>> moved inside 'If' - excellent result
>>>>>>>
>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>> But I still have the same result.
>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>
>>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>>> another activity) is very common for BPEL and other programming
>>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it is
>>>>>>> not possible by design of EMF Compare...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Oleg
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620912 is a reply to message #135840] |
Tue, 05 May 2009 07:57 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Oleg
you can specialize the GenericMatchEngine and provides yours as a default through the "match engine" extension point. That would enable you to specialize the generic behavior considering the "name" attribute in a specific way or forcing the algorithm to "go inside till leafs" when needed.
Cédric
Oleg Vazhnev wrote:
> Hi Cédric
>
> It would be nice if you can provide an example :)
>
> So far I've found two points where I want to change the behavior of EMF
> Compare for my plugin.
>
>
> 1. I want EMF Compare to count 'name' attribute with a special very very
> high priority. Because two activities with the same name - most likely
> the same activities. This issue was raised in UMLDiff algorithm, but it
> seems EMF Compare can't recognize that 'name' attribute is very
> important. Check this screenshot:
> http://www.picamatic.com/show/2009/05/05/01/57/3516577_478x3 53.PNG
> I expect here to see that 'RepeatUntil1' was added.
>
> 2. The issue I described originally in this thread
> Also check this screenshot:
> http://www.picamatic.com/show/2009/05/05/01/58/3516586_425x2 94.PNG
>
> I think having fixed these two issue EMF Compare will compare .bpel
> files much better :)
>
>
> I plan to debug EMF Compare a little to understand how can I solve the
> first issue.
> I plan to debug GenericMatchEngine (as Laurent suggested) to understand
> how to force algorithm "to go inside till leafs" :) Hope I can 'plug'
> this functionality just extending the class in some manner...
>
>
> Thanks,
> Oleg
>
>
>
> Cédric Brun wrote:
>> Hi Oleg,
>>
>>
>>> That's what I read in this paper "Presentation of EMF Compare Utility"
>>> by Antoine Toulmé
>>
>> Yes, that paper was presenting some part of the initial contribution.
>> (quite old but the problem are still valid)
>>
>>> "The problem of this tree comparison is that it is not
>>> convenient for comparing flow charts diagrams
>>> (like BPMN diagrams). Some relationships are
>>> ignored or handled in an invalid way."
>>
>> The problem is a generic one, some times, especially on "association
>> like" elements, we don't have enough information to match correctly two
>> versions of a relationship. That causes a "this relationship has been
>> removed / this relationship has been added" diff instead of a "this
>> relationship has been changed".
>>
>> The problem is a tricky one as we don't have much information to match
>> these elements and we should probably consider them in a specific way.
>>
>> We're open to suggestions :)
>>
>>
>> Cédric
>>
>>> Oleg
>>>
>>> Oleg Vazhnev wrote:
>>>> Thank you Cédric!
>>>>
>>>> Cédric Brun wrote:
>>>>> Hi,
>>>>>
>>>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>>>> question is "Why it was written this way originally?".
>>>>> the implemented algorithm has a some good properties :
>>>>> - it's generic and works even if you compare models from different
>>>>> metamodels
>>>>> - it has quite a pretty good scalability/quality ratio for a generic
>>>>> algorithm.
>>>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>>>
>>>>> That said, the fact that the nested differences were not detected was
>>>>> an arbitrary choice, we wanted to only show the user that a "package
>>>>> has been added" and not that "the package and every elements inside
>>>>> it" has been added. Seems like this choice was not the best in regard
>>>>> to the "move" detection.
>>>>>
>>>>>
>>>>>> Since EMF Compare based on some 'researches' there certainty should
>>>>>> be a reason to write EMF Compare the way it wrote. And I need to know
>>>>>> these reasons before proposing any changes to algorithm :)
>>>>>>
>>>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>>>> will give you an overview and the paper I published with Alfonso
>>>>> Pierantonio might be a good reference too (
>>>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Cédric
>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>>>>
>>>>>> laurent Goubet wrote:
>>>>>>> Hi Oleg,
>>>>>>>
>>>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>>>> "removal"
>>>>>>> of an element to be the only change of its tree, thus "move"
>>>>>>> differences
>>>>>>> within their content tree won't be detected.
>>>>>>>
>>>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>>>> down
>>>>>>> into the unmatched elements to continue the matching phase where we
>>>>>>> stop
>>>>>>> it today, yet this isn't a trivial change.
>>>>>>>
>>>>>>> Could you file an enhancement request for this? Note that this will
>>>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Oleg Vazhnev a écrit :
>>>>>>>> Hi all
>>>>>>>>
>>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>>> means that all the children are deleted. And when the tree is
>>>>>>>> added, EMF Compare reports only the root node. Why? With such
>>>>>>>> design in some cases the comparison result looks weak.
>>>>>>>>
>>>>>>>> The questions are:
>>>>>>>> - Am I correct about my points?
>>>>>>>> - Do you agree that the result of EMF Compare for below situation
>>>>>>>> is not satisfied?
>>>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>>>> below?
>>>>>>>>
>>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>>>> :)
>>>>>>>>
>>>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>>>> imagine and I'm not satisfied with the result.
>>>>>>>>
>>>>>>>> Check this screenshot:
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>>>
>>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>>> recognize that 'If12' was nested into 'If' and only report that
>>>>>>>> 'If' is added. We should not report that 'If12' is deleted, because
>>>>>>>> it doesn't!
>>>>>>>>
>>>>>>>> There are several possible options:
>>>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>>>> weak result
>>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>>> moved inside 'If' - excellent result
>>>>>>>>
>>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>>> But I still have the same result.
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>>
>>>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>>>> another activity) is very common for BPEL and other programming
>>>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>>>>>> is not possible by design of EMF Compare...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Oleg
>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620913 is a reply to message #135852] |
Tue, 05 May 2009 07:59 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi,
>
> Sounds interesting :)
> Do you think that someone can use Drools instead of EMF Compare or do
> you plan to use Drools in EMF Compare (to make 'match' phase)?
> Do you have an examples where Drools compares better than 'EMF Compare'?
The idea was more about defining another generic match engine using drools and comparing its performances and quality with the one we are providing right now. I have not result right now, it was just food for though ;)
> As for my MS Thesis I think I would just include two 'extensions' I've
> proposed above, because of time constraints.
>
> Thanks,
> Oleg
>
>
>
> Cédric Brun wrote:
>> Hi Oleg,
>>
>> On thing just stroke me and could be incredibly interesting from a
>> research point of view. Right now we are struggling in matching two
>> versions of elements using custom heuristics and custom model traversal
>> strategies. That's costly, we often browse the model and compute metrics.
>> I've been playing with Drools (JBoss rules engine) lately and this piece
>> of software includes a constraint solver. You can set different research
>> strategies for the solver (using local optimum for instance) and the
>> performances are really really good. Moreover, it's fully java based and
>> integrating an EMF model with that is really easy (a blog post is coming
>> about that !)
>>
>> One could easily imagine to leverage drools-solver with a set of rules to
>> correctly match the elements. No doubt we would get far better
>> performances and better quality too. Handling the "relationship" corner
>> cases would then just be adding a few rules for the matching process.
>>
>> That's another way to tackle the problem, and in my opinion, really
>> promising. Don't know If that would interest you though..
>>
>> Cheers,
>>
>> Cédric
>>
>>
>> Oleg Vazhnev wrote:
>>> Hi Cédric and Laurent
>>>
>>> That's what I read in this paper "Presentation of EMF Compare Utility"
>>> by Antoine Toulmé
>>>
>>> "The problem of this tree comparison is that it is not
>>> convenient for comparing flow charts diagrams
>>> (like BPMN diagrams). Some relationships are
>>> ignored or handled in an invalid way."
>>>
>>> It seems some work was done in my area...
>>> Probably you can point me to mentioned problems (i can try
>>> to solve them then :) I.e. what relationships are ignored
>>> or handled in an invalid way?
>>>
>>> Thanks,
>>> Oleg
>>>
>>> Oleg Vazhnev wrote:
>>>> Thank you Cédric!
>>>>
>>>> Cédric Brun wrote:
>>>>> Hi,
>>>>>
>>>>>> I think I can propose the change to EMF Compare algorithm, but the
>>>>>> question is "Why it was written this way originally?".
>>>>> the implemented algorithm has a some good properties :
>>>>> - it's generic and works even if you compare models from different
>>>>> metamodels
>>>>> - it has quite a pretty good scalability/quality ratio for a generic
>>>>> algorithm.
>>>>> - it works both for "litle" (library) and "big" metamodels.(UML)
>>>>>
>>>>> That said, the fact that the nested differences were not detected was
>>>>> an arbitrary choice, we wanted to only show the user that a "package
>>>>> has been added" and not that "the package and every elements inside
>>>>> it" has been added. Seems like this choice was not the best in regard
>>>>> to the "move" detection.
>>>>>
>>>>>
>>>>>> Since EMF Compare based on some 'researches' there certainty should
>>>>>> be a reason to write EMF Compare the way it wrote. And I need to know
>>>>>> these reasons before proposing any changes to algorithm :)
>>>>>>
>>>>>> BTW what is the best source to learn the algorithm of EMF Compare?
>>>>> Use the code Luke ! ;) The code is the best place, the UMLdiff paper
>>>>> will give you an overview and the paper I published with Alfonso
>>>>> Pierantonio might be a good reference too (
>>>>> http://www.upgrade-cepis.org/issues/2008/2/upg9-2Brun.pdf )
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Cédric
>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>>>>
>>>>>> laurent Goubet wrote:
>>>>>>> Hi Oleg,
>>>>>>>
>>>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>>>> "removal"
>>>>>>> of an element to be the only change of its tree, thus "move"
>>>>>>> differences
>>>>>>> within their content tree won't be detected.
>>>>>>>
>>>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>>>> down
>>>>>>> into the unmatched elements to continue the matching phase where we
>>>>>>> stop
>>>>>>> it today, yet this isn't a trivial change.
>>>>>>>
>>>>>>> Could you file an enhancement request for this? Note that this will
>>>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Oleg Vazhnev a écrit :
>>>>>>>> Hi all
>>>>>>>>
>>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>>> means that all the children are deleted. And when the tree is
>>>>>>>> added, EMF Compare reports only the root node. Why? With such
>>>>>>>> design in some cases the comparison result looks weak.
>>>>>>>>
>>>>>>>> The questions are:
>>>>>>>> - Am I correct about my points?
>>>>>>>> - Do you agree that the result of EMF Compare for below situation
>>>>>>>> is not satisfied?
>>>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>>>> below?
>>>>>>>>
>>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>>>> post only about EMF Compare, don't worry about screenshots too much
>>>>>>>> :)
>>>>>>>>
>>>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>>>> imagine and I'm not satisfied with the result.
>>>>>>>>
>>>>>>>> Check this screenshot:
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>>>
>>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>>> recognize that 'If12' was nested into 'If' and only report that
>>>>>>>> 'If' is added. We should not report that 'If12' is deleted, because
>>>>>>>> it doesn't!
>>>>>>>>
>>>>>>>> There are several possible options:
>>>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>>>> weak result
>>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>>> result 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>>> moved inside 'If' - excellent result
>>>>>>>>
>>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>>> But I still have the same result.
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>>
>>>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>>>> another activity) is very common for BPEL and other programming
>>>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>>>>>> is not possible by design of EMF Compare...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Oleg
>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
| |
| Re: Weak comparison - can't match nodes, when nested [message #620940 is a reply to message #136125] |
Wed, 13 May 2009 10:00 |
|
This is a multi-part message in MIME format.
--------------080308060402000609000302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
After putting some thought into it, I think that nope, this cannot be
done in the generic engines. Detection of moves from / to an added /
removed element must be implemented by clients (as you did) as these are
too dependant on the data represented.
To take class diagrams as examples, detecting that a class has been
moved to a new package would be interesting, but detecting that an
attribute has been moved from a removed class to a new class makes no
sense as chances are this attribute really is a new one and not a moved
one (for example if I had a class "Video" with an attribute "title :
String"; I removed "Video" and created "Book" with an attribute "title :
String" => this is clearly not a move ... yet the engine itself cannot
understand it).
Base point is : you needn't fill in an enhancement request as it would
most probably closed as WONTFIX :p.
Thanks anyway ... and cheers :)
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620946 is a reply to message #136190] |
Wed, 13 May 2009 19:17 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
Thanks for investigation and explanation!
Probably GenericMatchEngine could be improved to allow extensions :)
There are a lot of private things. I was need to change just two or
three methods, but because they are private (and the fields they are
using are private) I've copy-pasted entire GenericMatchEngine.
Probably my solution will not be compatible with further version of EMF
Compare.
Thanks,
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> After putting some thought into it, I think that nope, this cannot be
> done in the generic engines. Detection of moves from / to an added /
> removed element must be implemented by clients (as you did) as these are
> too dependant on the data represented.
>
> To take class diagrams as examples, detecting that a class has been
> moved to a new package would be interesting, but detecting that an
> attribute has been moved from a removed class to a new class makes no
> sense as chances are this attribute really is a new one and not a moved
> one (for example if I had a class "Video" with an attribute "title :
> String"; I removed "Video" and created "Book" with an attribute "title :
> String" => this is clearly not a move ... yet the engine itself cannot
> understand it).
>
> Base point is : you needn't fill in an enhancement request as it would
> most probably closed as WONTFIX :p.
>
> Thanks anyway ... and cheers :)
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi Laurent
>>
>> Are you sure I should file an enhancement request? :)
>> According to Cédric answer there are some points why EMF Compare is
>> wrote this way. And these points still looks legitimate :)
>>
>> I fixed Engine in my plugin to better compare BPEL files.
>> The idea is to use all-level children, not current-level
>> in recursiveMappings() (check my pictures in the attachment)
>>
>> My sources not perfect, I just fixed some "debug points". Likely some
>> addition modifications/refactoring is required to integrate it to EMF
>> Compare code-base.
>>
>> If we really want to fix this, I can create an RFE with my sources in
>> the attachment.
>>
>> Thanks,
>> Oleg
>>
>>
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> As you have guessed, EMF Compare does not consider changes _within_
>>> "unmatched elements" : we consider the top level "addition" or
>>> "removal" of an element to be the only change of its tree, thus
>>> "move" differences within their content tree won't be detected.
>>>
>>> This behavior might be changed from the GenericMatchEngine by going
>>> down into the unmatched elements to continue the matching phase where
>>> we stop it today, yet this isn't a trivial change.
>>>
>>> Could you file an enhancement request for this? Note that this will
>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi all
>>>>
>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>> means that all the children are deleted. And when the tree is added,
>>>> EMF Compare reports only the root node. Why? With such design in
>>>> some cases the comparison result looks weak.
>>>>
>>>> The questions are:
>>>> - Am I correct about my points?
>>>> - Do you agree that the result of EMF Compare for below situation is
>>>> not satisfied?
>>>> - Can I extend EMF compare somehow to better compare the situation
>>>> below?
>>>>
>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>>
>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>> imagine and I'm not satisfied with the result.
>>>>
>>>> Check this screenshot:
>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>> using the same color for 'removed' and 'added' annotations)
>>>>
>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>> is added. We should not report that 'If12' is deleted, because it
>>>> doesn't!
>>>>
>>>> There are several possible options:
>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>> weak result
>>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>> inside 'If' - excellent result
>>>>
>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>> But I still have the same result.
>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>
>>>> Such situation (when a block of code surrounded with if, while, or
>>>> another activity) is very common for BPEL and other programming
>>>> languages. So I'm thinking how to help EMF Compare to better
>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>> is not possible by design of EMF Compare...
>>>>
>>>> Thanks,
>>>> Oleg
>>>
>>
>>
>> ------------------------------------------------------------ ------------
>>
>>
>> ------------------------------------------------------------ ------------
>>
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620950 is a reply to message #136375] |
Thu, 14 May 2009 08:15 |
|
This is a multi-part message in MIME format.
--------------080902010308050901070504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
Most of the GenericMatchEngine methods are private since we don't really
have "real world" examples of overriding needs. I closed off most of the
engine to allow users to override it yet still allow us to break the API
as we please. Do not hesitate to raise bugs and enhancement request for
the opening of APIs : backed up with a real need you can see what is
private and should be protected better than us :). We don't want to open
everything as we need to keep control of the API and be able to break
some of the methods in there, but obviously we can open it a little more
than it is ^^.
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620974 is a reply to message #136190] |
Fri, 22 May 2009 08:38 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
I think the algorithm never places 'attributes' in the tree.
Tree contains only 'model elements'. Each model element can have a
number of attributes (may be zero).
Thus we never 'move' attributes, only 'model elements', isn't it? :)
For example Car have a tyre.
But we can say that Car have a wheel which have a tyre.
In this example 'tyre' has been moved from 'Car' to 'wheel' :)
Am I wrong or missing something? :)
Thanks,
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> After putting some thought into it, I think that nope, this cannot be
> done in the generic engines. Detection of moves from / to an added /
> removed element must be implemented by clients (as you did) as these are
> too dependant on the data represented.
>
> To take class diagrams as examples, detecting that a class has been
> moved to a new package would be interesting, but detecting that an
> attribute has been moved from a removed class to a new class makes no
> sense as chances are this attribute really is a new one and not a moved
> one (for example if I had a class "Video" with an attribute "title :
> String"; I removed "Video" and created "Book" with an attribute "title :
> String" => this is clearly not a move ... yet the engine itself cannot
> understand it).
>
> Base point is : you needn't fill in an enhancement request as it would
> most probably closed as WONTFIX :p.
>
> Thanks anyway ... and cheers :)
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi Laurent
>>
>> Are you sure I should file an enhancement request? :)
>> According to Cédric answer there are some points why EMF Compare is
>> wrote this way. And these points still looks legitimate :)
>>
>> I fixed Engine in my plugin to better compare BPEL files.
>> The idea is to use all-level children, not current-level
>> in recursiveMappings() (check my pictures in the attachment)
>>
>> My sources not perfect, I just fixed some "debug points". Likely some
>> addition modifications/refactoring is required to integrate it to EMF
>> Compare code-base.
>>
>> If we really want to fix this, I can create an RFE with my sources in
>> the attachment.
>>
>> Thanks,
>> Oleg
>>
>>
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> As you have guessed, EMF Compare does not consider changes _within_
>>> "unmatched elements" : we consider the top level "addition" or
>>> "removal" of an element to be the only change of its tree, thus
>>> "move" differences within their content tree won't be detected.
>>>
>>> This behavior might be changed from the GenericMatchEngine by going
>>> down into the unmatched elements to continue the matching phase where
>>> we stop it today, yet this isn't a trivial change.
>>>
>>> Could you file an enhancement request for this? Note that this will
>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi all
>>>>
>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>> means that all the children are deleted. And when the tree is added,
>>>> EMF Compare reports only the root node. Why? With such design in
>>>> some cases the comparison result looks weak.
>>>>
>>>> The questions are:
>>>> - Am I correct about my points?
>>>> - Do you agree that the result of EMF Compare for below situation is
>>>> not satisfied?
>>>> - Can I extend EMF compare somehow to better compare the situation
>>>> below?
>>>>
>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>> post only about EMF Compare, don't worry about screenshots too much :)
>>>>
>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>> imagine and I'm not satisfied with the result.
>>>>
>>>> Check this screenshot:
>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>> using the same color for 'removed' and 'added' annotations)
>>>>
>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>> recognize that 'If12' was nested into 'If' and only report that 'If'
>>>> is added. We should not report that 'If12' is deleted, because it
>>>> doesn't!
>>>>
>>>> There are several possible options:
>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>> weak result
>>>> 2. report that If12 is deleted and If and If12 are added - weak result
>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>> inside 'If' - excellent result
>>>>
>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>> But I still have the same result.
>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>
>>>> Such situation (when a block of code surrounded with if, while, or
>>>> another activity) is very common for BPEL and other programming
>>>> languages. So I'm thinking how to help EMF Compare to better
>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>> is not possible by design of EMF Compare...
>>>>
>>>> Thanks,
>>>> Oleg
>>>
>>
>>
>> ------------------------------------------------------------ ------------
>>
>>
>> ------------------------------------------------------------ ------------
>>
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #620994 is a reply to message #136704] |
Thu, 04 June 2009 15:07 |
|
This is a multi-part message in MIME format.
--------------060603030009050304000008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
You are one step too low in the "meta" :p. "moving an attribute" means
you're referring to class-like diagrams : in the metamodel, a "Class"
contains a set number of "Attribute" (here, "Attribute" is an object
contained by the object "Class"). If "Attribute" were to be moved from
"Class" to, let's say, "Package", then we indeed detect the move of a
model element : "Attribute has been moved from Class to Package".
That said, what you are describing in your example is "the object 'Tyre'
of type 'Attribute' has been moved from 'Car' to 'Wheel'" ... I don't
know if you see what I mean here, "Tyre" is a model element, not a
property of "Car" (is the class "Car" an interface? that is a boolean
property of "Car", not a contained Object).
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #621014 is a reply to message #136943] |
Thu, 11 June 2009 18:54 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
Thanks for tracking this thread! :)
I don't understand your point...
I'm just confused that EMF Compare can't detect such "pairs"
revision 1: matched pair -> child1 -> child2
revision 2: matched pair -> child3 -> child1
EMF Compare will never match child1 in r1 and child1 in r2 because EMF
Compare checks only *immediate* child of matched nodes. (also check this
screenshot http://www.picamatic.com/view/3516586_bpel_62/ ). I've
changed this behavior, but in my opinion it should be by default :)
The problem is not something BPEL-specific, actually it applicable for
any programming language, because you can 'wrap' activity with another
activity in almost any programming language. For example you can wrap
'buy a ticket' to 'repeat buy a ticket until succeed' :) And EMF Compare
doesn't detect such situations...
I'm not guru in EMF Compare, probably I just missing something important
or don't understand completely how it works, I apologize then :)
Now it is not very important for me (I've changed behavior in my own
plugin and I've finished university few weeks ago :), but just to let
you know... if you think that this is actually a problem I can create
new bug then.
Thanks,
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> You are one step too low in the "meta" :p. "moving an attribute" means
> you're referring to class-like diagrams : in the metamodel, a "Class"
> contains a set number of "Attribute" (here, "Attribute" is an object
> contained by the object "Class"). If "Attribute" were to be moved from
> "Class" to, let's say, "Package", then we indeed detect the move of a
> model element : "Attribute has been moved from Class to Package".
>
> That said, what you are describing in your example is "the object 'Tyre'
> of type 'Attribute' has been moved from 'Car' to 'Wheel'" ... I don't
> know if you see what I mean here, "Tyre" is a model element, not a
> property of "Car" (is the class "Car" an interface? that is a boolean
> property of "Car", not a contained Object).
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi Laurent
>>
>> I think the algorithm never places 'attributes' in the tree.
>> Tree contains only 'model elements'. Each model element can have a
>> number of attributes (may be zero).
>> Thus we never 'move' attributes, only 'model elements', isn't it? :)
>>
>> For example Car have a tyre.
>> But we can say that Car have a wheel which have a tyre.
>> In this example 'tyre' has been moved from 'Car' to 'wheel' :)
>>
>> Am I wrong or missing something? :)
>>
>> Thanks,
>> Oleg
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> After putting some thought into it, I think that nope, this cannot be
>>> done in the generic engines. Detection of moves from / to an added /
>>> removed element must be implemented by clients (as you did) as these
>>> are too dependant on the data represented.
>>>
>>> To take class diagrams as examples, detecting that a class has been
>>> moved to a new package would be interesting, but detecting that an
>>> attribute has been moved from a removed class to a new class makes no
>>> sense as chances are this attribute really is a new one and not a
>>> moved one (for example if I had a class "Video" with an attribute
>>> "title : String"; I removed "Video" and created "Book" with an
>>> attribute "title : String" => this is clearly not a move ... yet the
>>> engine itself cannot understand it).
>>>
>>> Base point is : you needn't fill in an enhancement request as it
>>> would most probably closed as WONTFIX :p.
>>>
>>> Thanks anyway ... and cheers :)
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi Laurent
>>>>
>>>> Are you sure I should file an enhancement request? :)
>>>> According to Cédric answer there are some points why EMF Compare is
>>>> wrote this way. And these points still looks legitimate :)
>>>>
>>>> I fixed Engine in my plugin to better compare BPEL files.
>>>> The idea is to use all-level children, not current-level
>>>> in recursiveMappings() (check my pictures in the attachment)
>>>>
>>>> My sources not perfect, I just fixed some "debug points". Likely
>>>> some addition modifications/refactoring is required to integrate it
>>>> to EMF Compare code-base.
>>>>
>>>> If we really want to fix this, I can create an RFE with my sources
>>>> in the attachment.
>>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>>
>>>>
>>>> laurent Goubet wrote:
>>>>> Hi Oleg,
>>>>>
>>>>> As you have guessed, EMF Compare does not consider changes _within_
>>>>> "unmatched elements" : we consider the top level "addition" or
>>>>> "removal" of an element to be the only change of its tree, thus
>>>>> "move" differences within their content tree won't be detected.
>>>>>
>>>>> This behavior might be changed from the GenericMatchEngine by going
>>>>> down into the unmatched elements to continue the matching phase
>>>>> where we stop it today, yet this isn't a trivial change.
>>>>>
>>>>> Could you file an enhancement request for this? Note that this will
>>>>> clearly not be done for Galileo as we are now in the M7 phase.
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Oleg Vazhnev a écrit :
>>>>>> Hi all
>>>>>>
>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>> means that all the children are deleted. And when the tree is
>>>>>> added, EMF Compare reports only the root node. Why? With such
>>>>>> design in some cases the comparison result looks weak.
>>>>>>
>>>>>> The questions are:
>>>>>> - Am I correct about my points?
>>>>>> - Do you agree that the result of EMF Compare for below situation
>>>>>> is not satisfied?
>>>>>> - Can I extend EMF compare somehow to better compare the situation
>>>>>> below?
>>>>>>
>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But this
>>>>>> post only about EMF Compare, don't worry about screenshots too
>>>>>> much :)
>>>>>>
>>>>>> I've tried to give to EMF Compare the first non-obvious task I can
>>>>>> imagine and I'm not satisfied with the result.
>>>>>>
>>>>>> Check this screenshot:
>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added (i'm
>>>>>> using the same color for 'removed' and 'added' annotations)
>>>>>>
>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>> recognize that 'If12' was nested into 'If' and only report that
>>>>>> 'If' is added. We should not report that 'If12' is deleted,
>>>>>> because it doesn't!
>>>>>>
>>>>>> There are several possible options:
>>>>>> 1. report that If12 is renamed to If, and another If12 is added. -
>>>>>> weak result
>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>> result
>>>>>> 3. report that 'If' is added. Recognize that 'If12' was just moved
>>>>>> inside 'If' - excellent result
>>>>>>
>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>> But I still have the same result.
>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>
>>>>>> Such situation (when a block of code surrounded with if, while, or
>>>>>> another activity) is very common for BPEL and other programming
>>>>>> languages. So I'm thinking how to help EMF Compare to better
>>>>>> recognize such situations. Any tips are welcome. But I'm afraid it
>>>>>> is not possible by design of EMF Compare...
>>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------ ------------
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------ ------------
>>>>
>>>>
>>>
>
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #621015 is a reply to message #137180] |
Fri, 12 June 2009 07:23 |
|
This is a multi-part message in MIME format.
--------------050604020606050506050203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Oleg,
First of all, congratulations on your graduation :).
What you describe here (detecting "move" differences nested within
"removed" or "added" elements) is not implemented by default since it
isn't meaningful on all metamodels. The engine is sufficiently
extensible to allow clients to specialize it as you did, the other way
around may not be true (if we did make it default).
You've taken the example of activity-like diagrams. Indeed an activity
can be wrapped within another activity in newer versions of a diagram,
and in most cases the "move" difference should be detected. As
mentionned in a previous mail, this might not be true for class-like
diagrams. Note that I am talking here of the class diagram itself, not
models issued from it. For example if I have a class diagram describing
a metamodel containing the Class Video with an attribute "title :
String". I compare this metamodel with another in which the Class
"Video" has been deleted and a new Class "Book" has been created, this
new class containing itself an attribute "title : String". Let me stress
that we compare the metamodels, not the models described using these
metamodels (for example with such metamodels, we could have a model
containing an instance of video titled "Lord of the ring" and another
containing an instance of book titled "Return of the king").
In such a case of comparison, I don't want EMF Compare to detect "title"
to have been moved from "Video" to "Book". That is a new Object, not a
move. The same will apply for custom DSLs that can be compared from EMF
Compare : we have no way within the generic engine to know if an element
nested in a removed or added element is a move or an entirely new
element, thus our generic behavior doesn't detect them.
Of course, the same wouldn't be true for elements sporting an ID (XMI ID
or ID attribute). In this latter case we would be able to tell that
elements have indeed be moved since their ID confirm their equality.
Laurent Goubet
Obeo
Oleg Vazhnev a
|
|
|
| Re: Weak comparison - can't match nodes, when nested [message #621058 is a reply to message #137192] |
Thu, 25 June 2009 18:30 |
Oleg Vazhnev
Messages: 42
Registered: July 2009 |
Member |
|
|
Hi Laurent
Thanks for detailed description! now I understand the issue :)
Oleg
laurent Goubet wrote:
> Hi Oleg,
>
> First of all, congratulations on your graduation :).
>
> What you describe here (detecting "move" differences nested within
> "removed" or "added" elements) is not implemented by default since it
> isn't meaningful on all metamodels. The engine is sufficiently
> extensible to allow clients to specialize it as you did, the other way
> around may not be true (if we did make it default).
>
> You've taken the example of activity-like diagrams. Indeed an activity
> can be wrapped within another activity in newer versions of a diagram,
> and in most cases the "move" difference should be detected. As
> mentionned in a previous mail, this might not be true for class-like
> diagrams. Note that I am talking here of the class diagram itself, not
> models issued from it. For example if I have a class diagram describing
> a metamodel containing the Class Video with an attribute "title :
> String". I compare this metamodel with another in which the Class
> "Video" has been deleted and a new Class "Book" has been created, this
> new class containing itself an attribute "title : String". Let me stress
> that we compare the metamodels, not the models described using these
> metamodels (for example with such metamodels, we could have a model
> containing an instance of video titled "Lord of the ring" and another
> containing an instance of book titled "Return of the king").
>
> In such a case of comparison, I don't want EMF Compare to detect "title"
> to have been moved from "Video" to "Book". That is a new Object, not a
> move. The same will apply for custom DSLs that can be compared from EMF
> Compare : we have no way within the generic engine to know if an element
> nested in a removed or added element is a move or an entirely new
> element, thus our generic behavior doesn't detect them.
>
> Of course, the same wouldn't be true for elements sporting an ID (XMI ID
> or ID attribute). In this latter case we would be able to tell that
> elements have indeed be moved since their ID confirm their equality.
>
> Laurent Goubet
> Obeo
>
> Oleg Vazhnev a écrit :
>> Hi Laurent
>>
>> Thanks for tracking this thread! :)
>> I don't understand your point...
>> I'm just confused that EMF Compare can't detect such "pairs"
>>
>> revision 1: matched pair -> child1 -> child2
>> revision 2: matched pair -> child3 -> child1
>>
>> EMF Compare will never match child1 in r1 and child1 in r2 because EMF
>> Compare checks only *immediate* child of matched nodes. (also check
>> this screenshot http://www.picamatic.com/view/3516586_bpel_62/ ). I've
>> changed this behavior, but in my opinion it should be by default :)
>>
>> The problem is not something BPEL-specific, actually it applicable for
>> any programming language, because you can 'wrap' activity with another
>> activity in almost any programming language. For example you can wrap
>> 'buy a ticket' to 'repeat buy a ticket until succeed' :) And EMF
>> Compare doesn't detect such situations...
>>
>> I'm not guru in EMF Compare, probably I just missing something
>> important or don't understand completely how it works, I apologize
>> then :)
>>
>> Now it is not very important for me (I've changed behavior in my own
>> plugin and I've finished university few weeks ago :), but just to let
>> you know... if you think that this is actually a problem I can create
>> new bug then.
>>
>> Thanks,
>> Oleg
>>
>>
>> laurent Goubet wrote:
>>> Hi Oleg,
>>>
>>> You are one step too low in the "meta" :p. "moving an attribute"
>>> means you're referring to class-like diagrams : in the metamodel, a
>>> "Class" contains a set number of "Attribute" (here, "Attribute" is an
>>> object contained by the object "Class"). If "Attribute" were to be
>>> moved from "Class" to, let's say, "Package", then we indeed detect
>>> the move of a model element : "Attribute has been moved from Class to
>>> Package".
>>>
>>> That said, what you are describing in your example is "the object
>>> 'Tyre' of type 'Attribute' has been moved from 'Car' to 'Wheel'" ...
>>> I don't know if you see what I mean here, "Tyre" is a model element,
>>> not a property of "Car" (is the class "Car" an interface? that is a
>>> boolean property of "Car", not a contained Object).
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Oleg Vazhnev a écrit :
>>>> Hi Laurent
>>>>
>>>> I think the algorithm never places 'attributes' in the tree.
>>>> Tree contains only 'model elements'. Each model element can have a
>>>> number of attributes (may be zero).
>>>> Thus we never 'move' attributes, only 'model elements', isn't it? :)
>>>>
>>>> For example Car have a tyre.
>>>> But we can say that Car have a wheel which have a tyre.
>>>> In this example 'tyre' has been moved from 'Car' to 'wheel' :)
>>>>
>>>> Am I wrong or missing something? :)
>>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>> laurent Goubet wrote:
>>>>> Hi Oleg,
>>>>>
>>>>> After putting some thought into it, I think that nope, this cannot
>>>>> be done in the generic engines. Detection of moves from / to an
>>>>> added / removed element must be implemented by clients (as you did)
>>>>> as these are too dependant on the data represented.
>>>>>
>>>>> To take class diagrams as examples, detecting that a class has been
>>>>> moved to a new package would be interesting, but detecting that an
>>>>> attribute has been moved from a removed class to a new class makes
>>>>> no sense as chances are this attribute really is a new one and not
>>>>> a moved one (for example if I had a class "Video" with an attribute
>>>>> "title : String"; I removed "Video" and created "Book" with an
>>>>> attribute "title : String" => this is clearly not a move ... yet
>>>>> the engine itself cannot understand it).
>>>>>
>>>>> Base point is : you needn't fill in an enhancement request as it
>>>>> would most probably closed as WONTFIX :p.
>>>>>
>>>>> Thanks anyway ... and cheers :)
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Oleg Vazhnev a écrit :
>>>>>> Hi Laurent
>>>>>>
>>>>>> Are you sure I should file an enhancement request? :)
>>>>>> According to Cédric answer there are some points why EMF Compare
>>>>>> is wrote this way. And these points still looks legitimate :)
>>>>>>
>>>>>> I fixed Engine in my plugin to better compare BPEL files.
>>>>>> The idea is to use all-level children, not current-level
>>>>>> in recursiveMappings() (check my pictures in the attachment)
>>>>>>
>>>>>> My sources not perfect, I just fixed some "debug points". Likely
>>>>>> some addition modifications/refactoring is required to integrate
>>>>>> it to EMF Compare code-base.
>>>>>>
>>>>>> If we really want to fix this, I can create an RFE with my sources
>>>>>> in the attachment.
>>>>>>
>>>>>> Thanks,
>>>>>> Oleg
>>>>>>
>>>>>>
>>>>>>
>>>>>> laurent Goubet wrote:
>>>>>>> Hi Oleg,
>>>>>>>
>>>>>>> As you have guessed, EMF Compare does not consider changes
>>>>>>> _within_ "unmatched elements" : we consider the top level
>>>>>>> "addition" or "removal" of an element to be the only change of
>>>>>>> its tree, thus "move" differences within their content tree won't
>>>>>>> be detected.
>>>>>>>
>>>>>>> This behavior might be changed from the GenericMatchEngine by
>>>>>>> going down into the unmatched elements to continue the matching
>>>>>>> phase where we stop it today, yet this isn't a trivial change.
>>>>>>>
>>>>>>> Could you file an enhancement request for this? Note that this
>>>>>>> will clearly not be done for Galileo as we are now in the M7 phase.
>>>>>>>
>>>>>>> Laurent Goubet
>>>>>>> Obeo
>>>>>>>
>>>>>>> Oleg Vazhnev a écrit :
>>>>>>>> Hi all
>>>>>>>>
>>>>>>>> I've noticed that if EMF Compare reports that node is deleted it
>>>>>>>> means that all the children are deleted. And when the tree is
>>>>>>>> added, EMF Compare reports only the root node. Why? With such
>>>>>>>> design in some cases the comparison result looks weak.
>>>>>>>>
>>>>>>>> The questions are:
>>>>>>>> - Am I correct about my points?
>>>>>>>> - Do you agree that the result of EMF Compare for below
>>>>>>>> situation is not satisfied?
>>>>>>>> - Can I extend EMF compare somehow to better compare the
>>>>>>>> situation below?
>>>>>>>>
>>>>>>>> I'm using EMF Compare to compare BPEL files in my plugin. But
>>>>>>>> this post only about EMF Compare, don't worry about screenshots
>>>>>>>> too much :)
>>>>>>>>
>>>>>>>> I've tried to give to EMF Compare the first non-obvious task I
>>>>>>>> can imagine and I'm not satisfied with the result.
>>>>>>>>
>>>>>>>> Check this screenshot:
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/20/3462393_1144x 726.PNG
>>>>>>>> EMF Compare reports that 'If12' is removed and 'If' is added
>>>>>>>> (i'm using the same color for 'removed' and 'added' annotations)
>>>>>>>>
>>>>>>>> But, In my opinion, it is not 'good' comparison result. We can
>>>>>>>> recognize that 'If12' was nested into 'If' and only report that
>>>>>>>> 'If' is added. We should not report that 'If12' is deleted,
>>>>>>>> because it doesn't!
>>>>>>>>
>>>>>>>> There are several possible options:
>>>>>>>> 1. report that If12 is renamed to If, and another If12 is added.
>>>>>>>> - weak result
>>>>>>>> 2. report that If12 is deleted and If and If12 are added - weak
>>>>>>>> result
>>>>>>>> 3. report that 'If' is added. Recognize that 'If12' was just
>>>>>>>> moved inside 'If' - excellent result
>>>>>>>>
>>>>>>>> I've tried to help EMF Compare adding extra-stuff inside 'If12'.
>>>>>>>> But I still have the same result.
>>>>>>>> http://www.picamatic.com/show/2009/04/30/03/23/3462432_1275x 760.PNG
>>>>>>>>
>>>>>>>> Such situation (when a block of code surrounded with if, while,
>>>>>>>> or another activity) is very common for BPEL and other
>>>>>>>> programming languages. So I'm thinking how to help EMF Compare
>>>>>>>> to better recognize such situations. Any tips are welcome. But
>>>>>>>> I'm afraid it is not possible by design of EMF Compare...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Oleg
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------ ------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------ ------------
>>>>>>
>>>>>>
>>>>>
>>>
>
|
|
|
Goto Forum:
Current Time: Sat Jul 27 10:19:30 GMT 2024
Powered by FUDForum. Page generated in 0.08211 seconds |
] 
Search
Help
Register
Login
Home
