|
|
Re: [EMF-Compare] left and right model [message #93742 is a reply to message #93727] |
Tue, 21 August 2007 15:15 |
Eclipse User |
|
|
|
Originally posted by: jmottu.irisa.fr
Cédric Brun a écrit :
> Hi Cyril,
>
> Changing the left/right models should not lead to a different results. In
> fact ads should transform in deletions but reference or attribute updates
> should be detected the same way. If not, then I would say it is a bug,
> could you track one in the bugzilla putting your models as an enclosed
> file ?
>
> Considering the order the compare framework (not the emf-compare one) decide
> which element is the left and which is the right, we can't decide ourselves
> and it seems that when comparing local files the order used is the
> alphabetical one. This issue may be discussed in the platform newsgroup
> with the org.eclipse.compare team.
>
>
>> Where I can find a specification of the rules defined into EMF Compare?
>
> What do you mean by "Rule" ?
We mean what is the strategy employed by "EMF compare" to decide what
are a match, a move, a change, a creation and a deletion?
Does "EMF compare" have been specified, is this specification available?
Or did you follow strategies defined in other scientific works?
Thanks,
Jean-Marie
>
>
> Cédric
>
>
|
|
|
Re: [EMF-Compare] left and right model [message #93757 is a reply to message #93742] |
Tue, 21 August 2007 15:54 |
Cedric Brun Messages: 431 Registered: July 2009 |
Senior Member |
|
|
> We mean what is the strategy employed by "EMF compare" to decide what
> are a match, a move, a change, a creation and a deletion?
>
> Does "EMF compare" have been specified, is this specification available?
> Or did you follow strategies defined in other scientific works?
>
The emf compare generic engine is based on several research work and on
experimentations. The paper being the most "near" the emf compare behavior
is probably "UMLDiff: An Algorithm for Object-OrientedDesign Differencing"
by Zhenchang Xing and Eleni Stroulia. Other reseach work have been used and
a lot of them use the same kind of general behavior:
A comparison in 2 phases, the first being the matching phase and the second
the differencing phase. The matching is done computing comparison metrics
and getting an "overall" rank of matching for two nodes while browsing both
versions of the model. These metrics may change considering the research
work, here in the generic engine we use 4 metrics :
- type similarity : analysing the metamodel element
- name similarity : looking for an attribute which have chances to be the
name and comparing it
- value similarity : analysing the whole attributes values
- relations similarity : using the relations the element has with others.
Using these 4 metrics the comparison engine provide good correctness (most
especially comparing models from DSM/DSL's metamodels) and efficiency when
comparing big models (~=100 000 elements).
Once the matching phase is done, the matching model is browsed by the
differencing engine computing "added", "deleted" or updated elements from
that. If you save a comparison as an emfdiff model you'll be able to browse
the match and diff model and you'll get the similarity ranking for each
couple of elements.
We're open to suggestion to enhance this generic behavior but we are also
open to other methods : we want this component to be a testbed for other
algorithms and comparison techniques, any Eclipse plugin may contribute its
own matching and differencing engine for generic or specific purpose and it
would be quite interesting to compare the results from different engines on
different models.
Cédric
> Thanks,
>
> Jean-Marie
>
>>
>>
>> Cédric
>>
>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
|
Re: [EMF-Compare] left and right model [message #609492 is a reply to message #93648] |
Tue, 21 August 2007 15:00 |
Cedric Brun Messages: 431 Registered: July 2009 |
Senior Member |
|
|
Hi Cyril,
Changing the left/right models should not lead to a different results. In
fact ads should transform in deletions but reference or attribute updates
should be detected the same way. If not, then I would say it is a bug,
could you track one in the bugzilla putting your models as an enclosed
file ?
Considering the order the compare framework (not the emf-compare one) decide
which element is the left and which is the right, we can't decide ourselves
and it seems that when comparing local files the order used is the
alphabetical one. This issue may be discussed in the platform newsgroup
with the org.eclipse.compare team.
> Where I can find a specification of the rules defined into EMF Compare?
What do you mean by "Rule" ?
Cédric
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
Re: [EMF-Compare] left and right model [message #609493 is a reply to message #93727] |
Tue, 21 August 2007 15:15 |
Eclipse User |
|
|
|
Originally posted by: jmottu.irisa.fr
Cédric Brun a écrit :
> Hi Cyril,
>
> Changing the left/right models should not lead to a different results. In
> fact ads should transform in deletions but reference or attribute updates
> should be detected the same way. If not, then I would say it is a bug,
> could you track one in the bugzilla putting your models as an enclosed
> file ?
>
> Considering the order the compare framework (not the emf-compare one) decide
> which element is the left and which is the right, we can't decide ourselves
> and it seems that when comparing local files the order used is the
> alphabetical one. This issue may be discussed in the platform newsgroup
> with the org.eclipse.compare team.
>
>
>> Where I can find a specification of the rules defined into EMF Compare?
>
> What do you mean by "Rule" ?
We mean what is the strategy employed by "EMF compare" to decide what
are a match, a move, a change, a creation and a deletion?
Does "EMF compare" have been specified, is this specification available?
Or did you follow strategies defined in other scientific works?
Thanks,
Jean-Marie
>
>
> Cédric
>
>
|
|
|
Re: [EMF-Compare] left and right model [message #609494 is a reply to message #93742] |
Tue, 21 August 2007 15:54 |
Cedric Brun Messages: 431 Registered: July 2009 |
Senior Member |
|
|
> We mean what is the strategy employed by "EMF compare" to decide what
> are a match, a move, a change, a creation and a deletion?
>
> Does "EMF compare" have been specified, is this specification available?
> Or did you follow strategies defined in other scientific works?
>
The emf compare generic engine is based on several research work and on
experimentations. The paper being the most "near" the emf compare behavior
is probably "UMLDiff: An Algorithm for Object-OrientedDesign Differencing"
by Zhenchang Xing and Eleni Stroulia. Other reseach work have been used and
a lot of them use the same kind of general behavior:
A comparison in 2 phases, the first being the matching phase and the second
the differencing phase. The matching is done computing comparison metrics
and getting an "overall" rank of matching for two nodes while browsing both
versions of the model. These metrics may change considering the research
work, here in the generic engine we use 4 metrics :
- type similarity : analysing the metamodel element
- name similarity : looking for an attribute which have chances to be the
name and comparing it
- value similarity : analysing the whole attributes values
- relations similarity : using the relations the element has with others.
Using these 4 metrics the comparison engine provide good correctness (most
especially comparing models from DSM/DSL's metamodels) and efficiency when
comparing big models (~=100 000 elements).
Once the matching phase is done, the matching model is browsed by the
differencing engine computing "added", "deleted" or updated elements from
that. If you save a comparison as an emfdiff model you'll be able to browse
the match and diff model and you'll get the similarity ranking for each
couple of elements.
We're open to suggestion to enhance this generic behavior but we are also
open to other methods : we want this component to be a testbed for other
algorithms and comparison techniques, any Eclipse plugin may contribute its
own matching and differencing engine for generic or specific purpose and it
would be quite interesting to compare the results from different engines on
different models.
Cédric
> Thanks,
>
> Jean-Marie
>
>>
>>
>> Cédric
>>
>>
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
|
Powered by
FUDForum. Page generated in 0.04916 seconds