Home » Modeling » EMF » EMF Change plugin
| EMF Change plugin [message #415713] |
Wed, 02 January 2008 20:59  |
Eclipse User |
|
|
|
Originally posted by: arazavi.swen.uwaterloo.ca
Hi All,
As part of my PhD project, I am considering creating a framework for
representing model changes. I would like it to be an underlying model for
model refactoring and update propagation across heterogenous emf models. I
came across org.eclipse.emf.change package in the EMF API. I am curious to
know about the purpouse of this package. Although this sounds like a good
place to start from, not all the classes are quite compatible with what I
have envisioned of a meta model for representing such changes. I was
thinking that there should be a closer relationship to the actual Ecore
metamodel (eg. having EStructuralFeatureChange, EReferenceChange etc. ). I
appreciate if someone sheds some light on this.
Thanks and Happy New year
Ali
|
|
|
| Re: EMF Change plugin [message #415720 is a reply to message #415713] |
Thu, 03 January 2008 11:57  |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Ali,
Comments below.
Ali Razavi wrote:
> Hi All,
>
>
> As part of my PhD project, I am considering creating a framework for
> representing model changes.
Also have a look at the model used by the EMFT's compare component.
There they analyze difference between models rather than simply monitor
changes, which is a much harder problem since you have to establish
correspondence between objects in two separate instances.
> I would like it to be an underlying model for
> model refactoring and update propagation across heterogenous emf models.
Yes, I could imagine a change model being used as a script. After all,
it includes apply methods for applying the described changes to the
instance.
> I
> came across org.eclipse.emf.change package in the EMF API. I am curious to
> know about the purpouse of this package.
The ChangeRecorder is designed to monitor all notifications thereby
knowing what's change; it keeps track of the old value the first time
there is a change to a particular feature. This information can be used
to build a ChangeDescription that represents as a model all the changes
made to the instance. Methods like apply/applyAndReverse can be used to
undo and redo those changes, which makes it useful for implementing
ChangeCommand's undo/redo support.
> Although this sounds like a good
> place to start from, not all the classes are quite compatible with what I
> have envisioned of a meta model for representing such changes. I was
> thinking that there should be a closer relationship to the actual Ecore
> metamodel (eg. having EStructuralFeatureChange, EReferenceChange etc. ). I
> appreciate if someone sheds some light on this.
>
There's an awful lot of stuff that's common between EAttribute and
EReference so it seemed simpler to just have a single FeatureChange
class that serves for both. So things like getDataValue and
getReferenceValue are persistent features to store either the
EAttribute's value or the EReference's value and getValue returns either
one of the two. A similar thing could have been accomplished with a
common base class and two derived classes, but in that case, the
serialization would include an xsi:type and so is a bit more complex.
> Thanks and Happy New year
>
You're welcome and you too. I'd be happy to hear more about your work.
Perhaps it would make an interesting EMFT component. That way you could
do your work in the open with a community that's likely interested in
the results. I know talking to folks at Eclipse Summit Europe that
there are other researchers interested in scripted refactoring...
> Ali
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Change plugin [message #415723 is a reply to message #415720] |
Thu, 03 January 2008 13:50 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed, Ali,
One thing to be aware of in using change-recording and ChangeDescriptions to
track, undo, and script changes is its interaction with models that
implement internal side-effects. It can happen that a model implementation
internally maintains consistency in various ways, and that the mechanisms
it employs depend on the order in which changes are performed. Because the
ChangeDescription retains a delta between two model states, rather than a
list of the individual change operations, applying it to a model with
side-effects may result in erroneous behaviour as changes are applied in a
different order than those that were originally recorded.
I have seen this, for example, in using the change-recorder on UML models.
The MDT UML2 implementation of the UML metamodel has internal side-effects
such as
- maintaining consistency of superset-subset features
- applying required stereotypes on containment changes
- unapplying inapplicable stereotypes on containment changes
that are sensitive to the order in which changes are performed in order to
correctly replay changes observed previously using a ChangeRecorder. These
side-effects can also be generated into user APIs described by UML models
via UML2's codegen extensions.
This isn't to criticize the change recorder's set of assumptions about the
model's behaviour or UML2's decisions to implement side-effects. Just a
note to highlight potential issues. I imagine that the EMFT Compare
component's merging function would similarly need to be aware of a specific
model's side-effects.
Cheers,
Christian
Ed Merks wrote:
> Ali,
>
> Comments below.
>
> Ali Razavi wrote:
>> Hi All,
>>
>>
>> As part of my PhD project, I am considering creating a framework for
>> representing model changes.
> Also have a look at the model used by the EMFT's compare component.
> There they analyze difference between models rather than simply monitor
> changes, which is a much harder problem since you have to establish
> correspondence between objects in two separate instances.
>> I would like it to be an underlying model for
>> model refactoring and update propagation across heterogenous emf models.
> Yes, I could imagine a change model being used as a script. After all,
> it includes apply methods for applying the described changes to the
> instance.
>> I
>> came across org.eclipse.emf.change package in the EMF API. I am curious
>> to know about the purpouse of this package.
> The ChangeRecorder is designed to monitor all notifications thereby
> knowing what's change; it keeps track of the old value the first time
> there is a change to a particular feature. This information can be used
> to build a ChangeDescription that represents as a model all the changes
> made to the instance. Methods like apply/applyAndReverse can be used to
> undo and redo those changes, which makes it useful for implementing
> ChangeCommand's undo/redo support.
>> Although this sounds like a good
>> place to start from, not all the classes are quite compatible with what I
>> have envisioned of a meta model for representing such changes. I was
>> thinking that there should be a closer relationship to the actual Ecore
>> metamodel (eg. having EStructuralFeatureChange, EReferenceChange etc. ).
>> I appreciate if someone sheds some light on this.
>>
> There's an awful lot of stuff that's common between EAttribute and
> EReference so it seemed simpler to just have a single FeatureChange
> class that serves for both. So things like getDataValue and
> getReferenceValue are persistent features to store either the
> EAttribute's value or the EReference's value and getValue returns either
> one of the two. A similar thing could have been accomplished with a
> common base class and two derived classes, but in that case, the
> serialization would include an xsi:type and so is a bit more complex.
>> Thanks and Happy New year
>>
> You're welcome and you too. I'd be happy to hear more about your work.
> Perhaps it would make an interesting EMFT component. That way you could
> do your work in the open with a community that's likely interested in
> the results. I know talking to folks at Eclipse Summit Europe that
> there are other researchers interested in scripted refactoring...
>> Ali
>>
>>
>>
>>
|
|
|
| Re: EMF Change plugin [message #415724 is a reply to message #415723] |
Thu, 03 January 2008 14:29 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010708070502040006030008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
In the case of compare, it's impossible to know the order of the
changes. All you'd know is before and after states and not the path for
how you got there. It's of course best to avoid as much as possible
having the order in which things are done affect the correctness of the
behavior...
Christian W. Damus wrote:
> Hi, Ed, Ali,
>
> One thing to be aware of in using change-recording and ChangeDescriptions to
> track, undo, and script changes is its interaction with models that
> implement internal side-effects. It can happen that a model implementation
> internally maintains consistency in various ways, and that the mechanisms
> it employs depend on the order in which changes are performed. Because the
> ChangeDescription retains a delta between two model states, rather than a
> list of the individual change operations, applying it to a model with
> side-effects may result in erroneous behaviour as changes are applied in a
> different order than those that were originally recorded.
>
> I have seen this, for example, in using the change-recorder on UML models.
> The MDT UML2 implementation of the UML metamodel has internal side-effects
> such as
>
> - maintaining consistency of superset-subset features
> - applying required stereotypes on containment changes
> - unapplying inapplicable stereotypes on containment changes
>
> that are sensitive to the order in which changes are performed in order to
> correctly replay changes observed previously using a ChangeRecorder. These
> side-effects can also be generated into user APIs described by UML models
> via UML2's codegen extensions.
>
> This isn't to criticize the change recorder's set of assumptions about the
> model's behaviour or UML2's decisions to implement side-effects. Just a
> note to highlight potential issues. I imagine that the EMFT Compare
> component's merging function would similarly need to be aware of a specific
> model's side-effects.
>
> Cheers,
>
> Christian
>
>
> Ed Merks wrote:
>
>
>> Ali,
>>
>> Comments below.
>>
>> Ali Razavi wrote:
>>
>>> Hi All,
>>>
>>>
>>> As part of my PhD project, I am considering creating a framework for
>>> representing model changes.
>>>
>> Also have a look at the model used by the EMFT's compare component.
>> There they analyze difference between models rather than simply monitor
>> changes, which is a much harder problem since you have to establish
>> correspondence between objects in two separate instances.
>>
>>> I would like it to be an underlying model for
>>> model refactoring and update propagation across heterogenous emf models.
>>>
>> Yes, I could imagine a change model being used as a script. After all,
>> it includes apply methods for applying the described changes to the
>> instance.
>>
>>> I
>>> came across org.eclipse.emf.change package in the EMF API. I am curious
>>> to know about the purpouse of this package.
>>>
>> The ChangeRecorder is designed to monitor all notifications thereby
>> knowing what's change; it keeps track of the old value the first time
>> there is a change to a particular feature. This information can be used
>> to build a ChangeDescription that represents as a model all the changes
>> made to the instance. Methods like apply/applyAndReverse can be used to
>> undo and redo those changes, which makes it useful for implementing
>> ChangeCommand's undo/redo support.
>>
>>> Although this sounds like a good
>>> place to start from, not all the classes are quite compatible with what I
>>> have envisioned of a meta model for representing such changes. I was
>>> thinking that there should be a closer relationship to the actual Ecore
>>> metamodel (eg. having EStructuralFeatureChange, EReferenceChange etc. ).
>>> I appreciate if someone sheds some light on this.
>>>
>>>
>> There's an awful lot of stuff that's common between EAttribute and
>> EReference so it seemed simpler to just have a single FeatureChange
>> class that serves for both. So things like getDataValue and
>> getReferenceValue are persistent features to store either the
>> EAttribute's value or the EReference's value and getValue returns either
>> one of the two. A similar thing could have been accomplished with a
>> common base class and two derived classes, but in that case, the
>> serialization would include an xsi:type and so is a bit more complex.
>>
>>> Thanks and Happy New year
>>>
>>>
>> You're welcome and you too. I'd be happy to hear more about your work.
>> Perhaps it would make an interesting EMFT component. That way you could
>> do your work in the open with a community that's likely interested in
>> the results. I know talking to folks at Eclipse Summit Europe that
>> there are other researchers interested in scripted refactoring...
>>
>>> Ali
>>>
>>>
>>>
>>>
>>>
>
>
--------------010708070502040006030008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
In the case of compare, it's impossible to know the order of the
changes. All you'd know is before and after states and not the path
for how you got there. It's of course best to avoid as much as
possible having the order in which things are done affect the
correctness of the behavior...<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:flip7p$apv$1@build.eclipse.org" type="cite">
<pre wrap="">Hi, Ed, Ali,
One thing to be aware of in using change-recording and ChangeDescriptions to
track, undo, and script changes is its interaction with models that
implement internal side-effects. It can happen that a model implementation
internally maintains consistency in various ways, and that the mechanisms
it employs depend on the order in which changes are performed. Because the
ChangeDescription retains a delta between two model states, rather than a
list of the individual change operations, applying it to a model with
side-effects may result in erroneous behaviour as changes are applied in a
different order than those that were originally recorded.
I have seen this, for example, in using the change-recorder on UML models.
The MDT UML2 implementation of the UML metamodel has internal side-effects
such as
- maintaining consistency of superset-subset features
- applying required stereotypes on containment changes
- unapplying inapplicable stereotypes on containment changes
that are sensitive to the order in which changes are performed in order to
correctly replay changes observed previously using a ChangeRecorder. These
side-effects can also be generated into user APIs described by UML models
via UML2's codegen extensions.
This isn't to criticize the change recorder's set of assumptions about the
model's behaviour or UML2's decisions to implement side-effects. Just a
note to highlight potential issues. I imagine that the EMFT Compare
component's merging function would similarly need to be aware of a specific
model's side-effects.
Cheers,
Christian
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ali,
Comments below.
Ali Razavi wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi All,
As part of my PhD project, I am considering creating a framework for
representing model changes.
</pre>
</blockquote>
<pre wrap="">Also have a look at the model used by the EMFT's compare component.
There they analyze difference between models rather than simply monitor
changes, which is a much harder problem since you have to establish
correspondence between objects in two separate instances.
</pre>
<blockquote type="cite">
<pre wrap="">I would like it to be an underlying model for
model refactoring and update propagation across heterogenous emf models.
</pre>
</blockquote>
<pre wrap="">Yes, I could imagine a change model being used as a script. After all,
it includes apply methods for applying the described changes to the
instance.
</pre>
<blockquote type="cite">
<pre wrap=""> I
came across org.eclipse.emf.change package in the EMF API. I am curious
to know about the purpouse of this package.
</pre>
</blockquote>
<pre wrap="">The ChangeRecorder is designed to monitor all notifications thereby
knowing what's change; it keeps track of the old value the first time
there is a change to a particular feature. This information can be used
to build a ChangeDescription that represents as a model all the changes
made to the instance. Methods like apply/applyAndReverse can be used to
undo and redo those changes, which makes it useful for implementing
ChangeCommand's undo/redo support.
</pre>
<blockquote type="cite">
<pre wrap=""> Although this sounds like a good
place to start from, not all the classes are quite compatible with what I
have envisioned of a meta model for representing such changes. I was
thinking that there should be a closer relationship to the actual Ecore
metamodel (eg. having EStructuralFeatureChange, EReferenceChange etc. ).
I appreciate if someone sheds some light on this.
</pre>
</blockquote>
<pre wrap="">There's an awful lot of stuff that's common between EAttribute and
EReference so it seemed simpler to just have a single FeatureChange
class that serves for both. So things like getDataValue and
getReferenceValue are persistent features to store either the
EAttribute's value or the EReference's value and getValue returns either
one of the two. A similar thing could have been accomplished with a
common base class and two derived classes, but in that case, the
serialization would include an xsi:type and so is a bit more complex.
</pre>
<blockquote type="cite">
<pre wrap="">Thanks and Happy New year
</pre>
</blockquote>
<pre wrap="">You're welcome and you too. I'd be happy to hear more about your work.
Perhaps it would make an interesting EMFT component. That way you could
do your work in the open with a community that's likely interested in
the results. I know talking to folks at Eclipse Summit Europe that
there are other researchers interested in scripted refactoring...
</pre>
<blockquote type="cite">
<pre wrap="">Ali
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------010708070502040006030008--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Change plugin [message #415725 is a reply to message #415724] |
Thu, 03 January 2008 15:16 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed,
Yes, what I meant w.r.t. compare is that the order in which changes are
applied by a merge may be significant, depending on the model
implementation.
I agree that dependencies on the ordering of changes are best avoided, but
clients of a model API don't have that choice. When working with UML2, at
least, these side-effects must to be taken into consideration. That may
mean that any system that propagates changes from one instance of a model
to another (Compare, CDO, etc.) may need special knowledge of certain
models (perhaps plugged in).
Cheers,
Christian
Ed Merks wrote:
> Christian,
>
> In the case of compare, it's impossible to know the order of the
> changes. All you'd know is before and after states and not the path for
> how you got there. It's of course best to avoid as much as possible
> having the order in which things are done affect the correctness of the
> behavior...
>
>
> Christian W. Damus wrote:
>> Hi, Ed, Ali,
>>
>> One thing to be aware of in using change-recording and ChangeDescriptions
>> to track, undo, and script changes is its interaction with models that
>> implement internal side-effects. It can happen that a model
>> implementation internally maintains consistency in various ways, and that
>> the mechanisms
>> it employs depend on the order in which changes are performed. Because
>> the ChangeDescription retains a delta between two model states, rather
>> than a list of the individual change operations, applying it to a model
>> with side-effects may result in erroneous behaviour as changes are
>> applied in a different order than those that were originally recorded.
>>
>> I have seen this, for example, in using the change-recorder on UML
>> models. The MDT UML2 implementation of the UML metamodel has internal
>> side-effects such as
>>
>> - maintaining consistency of superset-subset features
>> - applying required stereotypes on containment changes
>> - unapplying inapplicable stereotypes on containment changes
>>
>> that are sensitive to the order in which changes are performed in order
>> to
>> correctly replay changes observed previously using a ChangeRecorder.
>> These side-effects can also be generated into user APIs described by UML
>> models via UML2's codegen extensions.
>>
>> This isn't to criticize the change recorder's set of assumptions about
>> the
>> model's behaviour or UML2's decisions to implement side-effects. Just a
>> note to highlight potential issues. I imagine that the EMFT Compare
>> component's merging function would similarly need to be aware of a
>> specific model's side-effects.
>>
>> Cheers,
>>
>> Christian
-----8<-----
|
|
|
| Re: EMF Change plugin [message #415836 is a reply to message #415725] |
Wed, 09 January 2008 10:20 |
Cedric Brun
Messages: 431
Registered: July 2009 |
Senior Member |
|
|
Hi Christain and Ed,
I think you're right about the specific merging, we can't, at the model
level, know if values should be set in a specific order that's why we
designed possible extension in order to provide specific merging.
In EMF Compare we use the Diff model which defined specific types for
EReference or EAttribute changes, as Ed said it has a lot in common but the
model has been proven to be quite easier to use in model to text or model
to model transformations if we had different types sharing a common super
type.
Cédric
Christian W. Damus wrote:
> Hi, Ed,
>
> Yes, what I meant w.r.t. compare is that the order in which changes are
> applied by a merge may be significant, depending on the model
> implementation.
>
> I agree that dependencies on the ordering of changes are best avoided, but
> clients of a model API don't have that choice. When working with UML2, at
> least, these side-effects must to be taken into consideration. That may
> mean that any system that propagates changes from one instance of a model
> to another (Compare, CDO, etc.) may need special knowledge of certain
> models (perhaps plugged in).
>
> Cheers,
>
> Christian
>
>
> Ed Merks wrote:
>
>> Christian,
>>
>> In the case of compare, it's impossible to know the order of the
>> changes. All you'd know is before and after states and not the path for
>> how you got there. It's of course best to avoid as much as possible
>> having the order in which things are done affect the correctness of the
>> behavior...
>>
>>
>> Christian W. Damus wrote:
>>> Hi, Ed, Ali,
>>>
>>> One thing to be aware of in using change-recording and
>>> ChangeDescriptions to track, undo, and script changes is its interaction
>>> with models that
>>> implement internal side-effects. It can happen that a model
>>> implementation internally maintains consistency in various ways, and
>>> that the mechanisms
>>> it employs depend on the order in which changes are performed. Because
>>> the ChangeDescription retains a delta between two model states, rather
>>> than a list of the individual change operations, applying it to a model
>>> with side-effects may result in erroneous behaviour as changes are
>>> applied in a different order than those that were originally recorded.
>>>
>>> I have seen this, for example, in using the change-recorder on UML
>>> models. The MDT UML2 implementation of the UML metamodel has internal
>>> side-effects such as
>>>
>>> - maintaining consistency of superset-subset features
>>> - applying required stereotypes on containment changes
>>> - unapplying inapplicable stereotypes on containment changes
>>>
>>> that are sensitive to the order in which changes are performed in order
>>> to
>>> correctly replay changes observed previously using a ChangeRecorder.
>>> These side-effects can also be generated into user APIs described by UML
>>> models via UML2's codegen extensions.
>>>
>>> This isn't to criticize the change recorder's set of assumptions about
>>> the
>>> model's behaviour or UML2's decisions to implement side-effects. Just a
>>> note to highlight potential issues. I imagine that the EMFT Compare
>>> component's merging function would similarly need to be aware of a
>>> specific model's side-effects.
>>>
>>> Cheers,
>>>
>>> Christian
>
> -----8<-----
http://cedric.brun.io news and articles on eclipse and eclipse modeling.
|
|
|
Goto Forum:
Current Time: Tue Apr 16 22:53:15 GMT 2024
Powered by FUDForum. Page generated in 5.86976 seconds |
] 
Search
Help
Register
Login
Home
