Eclipse Community Forums: EMF » [EMF] Implementing Instance Model Inheritance

Help

Home

Home » Modeling » EMF » [EMF] Implementing Instance Model Inheritance

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

[EMF] Implementing Instance Model Inheritance [message #988125]

Wed, 28 November 2012 18:09

Leonid Ripeynih

Messages: 150
Registered: February 2012

Senior Member

Hi all!

I'm struggling on implementing instance model inheritance in EMF. Suppose, there is two instances of a given meta-model. One have some pointer to another (in 'parent' attribute). When editing, I only need to modify 'child' model attributes, but 'parent' model attributes should be accessible 'in scope', as child model can reference parent model elements. Another thing, is that models are 'merged' together, like java classes, so it's one model extending another. For example, if parent model looks like:

<root>
<element name="a"/>
</root>

and another is:

<root parent="parent">
<element name="b">
</root>

Semantically they're:

<root parent="parent">
<element name="a"/>
<element name="b">
</root>

So, what's the rigt way of implement instance model inheritance? Should it be some kind of extension of ResouceSet, or should it be a custom AdapterFactory, or is there (maybe?) some frameworks or technologies which can help me achive it?

Report message to a moderator

Re: [EMF] Implementing Instance Model Inheritance [message #988203 is a reply to message #988125]

Wed, 28 November 2012 19:01

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Comments below.

On 28/11/2012 7:09 PM, Dark Diver wrote:
> Hi all!
>
> I'm struggling on implementing instance model inheritance in EMF.
> Suppose, there is two instances of a given meta-model. One have some
> pointer to another (in 'parent' attribute). When editing, I only need
> to modify 'child' model attributes, but 'parent' model attributes
> should be accessible 'in scope', as child model can reference parent
> model elements. Another thing, is that models are 'merged' together,
> like java classes, so it's one model extending another. For example,
> if parent model looks like:
>
>
> <root>
> <element name="a"/>
> </root>
>
>
> and another is:
>
>
> <root parent="parent">
> <element name="b">
> </root>
>
>
> Semantically they're:
>
>
> <root parent="parent">
> <element name="a"/>
> <element name="b">
> </root>
>
>
> So, what's the rigt way of implement instance model inheritance?
This doesn't sound much different from EClass having eSuperTypes and
having eStructuralFeatures as well as a derived eAllStructuralFeatures
that's computed by merging all the features of all the reachable super
types...
> Should it be some kind of extension of ResouceSet, or should it be a
> custom AdapterFactory, or is there (maybe?) some frameworks or
> technologies which can help me achive it?
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [EMF] Implementing Instance Model Inheritance [message #988416 is a reply to message #988203]

Thu, 29 November 2012 20:14

Leonid Ripeynih

Messages: 150
Registered: February 2012

Senior Member

First thank you for the quick answer. I've carefully studied the getEAllStructuredFeatures implementation. My case is different in that, there can be much more levels of containment. And we have attribute overriding as a possible feature request as well. That sounds quite scary, as eCore doesn't implement it by itself. Some proxy-based view on 'merged' model? And what to do with eResouce property on 'merged' EObject? And, what's more, is should work for every feature in quite large model (12 ecore files). That means implementing getAll[MyFeatureName] methods, which i certanly don't want to code myself. So, is there other way except customising the generator? Maybe AOP (and ApectJ in particular)? Any advice is very welcome!

Report message to a moderator

Re: [EMF] Implementing Instance Model Inheritance [message #988473 is a reply to message #988416]

Fri, 30 November 2012 06:00

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Comments below.

On 29/11/2012 9:14 PM, Dark Diver wrote:
> First thank you for the quick answer. I've carefully studied the
> getEAllStructuredFeatures implementation. My case is different in
> that, there can be much more levels of containment. And we have
> attribute overriding as a possible feature request as well. That
> sounds quite scary, as eCore doesn't implement it by itself.
No, but not because it's hard to implement such a derived feature, but
because it's disruptive to the performance of a dynamic model. I.e.,
when using eGet to look up the value of a feature, we'd have to deal
with the fact that the feature might not be present but rather than
override of it...
> Some proxy-based view on 'merged' model?
There's just not enough detail in your outline of the problem for me to
make informative comments.
> And what to do with eResouce property on 'merged' EObject?
So you want to create new derived objects, not just derived values for
features?
> And, what's more, is should work for every feature in quite large
> model (12 ecore files).
Again, your design is entirely unclear from your outline.
> That means implementing getAll[MyFeatureName] methods, which i
> certanly don't want to code myself. So, is there other way except
> customising the generator?
Perhaps your approach could use setting delegates...
> Maybe AOP (and ApectJ in particular)? Any advice is very welcome!
Will you need these derived features to stay in sync dynamically with
the changes you make to the model?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [EMF] Implementing Instance Model Inheritance [message #988707 is a reply to message #988473]

Sat, 01 December 2012 18:24

Leonid Ripeynih

Messages: 150
Registered: February 2012

Senior Member

Thanks, Ed, for you answers!

Let me clarify our design a bit. We have a data-shema, represented by 12 eCore files (some are just a reusable parts). An instance model consists of (8+ the exact amount can vary) files, which is located in the same folder, and are treatened in some way, based on it's filename. The entire domain model consists of many folders with instances, in the specific directory layout. All the things related to locating and loading the models were solved by us, so it's working fine. Now to the problem. Our requirement is, that any instace can inherit it's properties from another, specified by it's 'parent' attribute instance instance. A concrete resouce, from which to inherit is determined by file extension. Now i will explain the case, which i don't know how to deal with:

Suppose i have parent model:

<root name="parent">
  <node id="node1">
    <nested-node id="n-node1">parent-value1</nested-node>
  </node>
  <node id="node2">
    <nested-node id="n-node2">parent-value2</nested-node>
    <nested-node id="n-node3">parent-value3</nested-node>
  </node> 
</root>

And a child model:

<root name="child" parent="parent">
  <node id="node2">
    <nested-node id="n-node2>child-value</nested-node>    
  </node> 
</root>

Then the symantic (merged) model is:

<root name="child" parent="parent"><!-- Attributes wich the same name is overriden, new attribute is merged -->
  <node id="node1"><!-- Completely inherited, much like getEAllStructuralFeatures -->
    <nested-node id="n-node1">parent-value1</nested-node>
  </node>
  <node id="node2">
    <nested-node id="n-node2">child-value</nested-node> <!-- As the child has the node with the same URI (by IDs), it overrides the parent value -->
    <nested-node id="n-node3">parent-value3</nested-node>
  </node> 
</root>

That behaviour should apply to ALL the model features, that's why i'm thinking of a minimum intrusive way of doing things. Our model is left 95% untouched and that 5% of customization is just an Operation specification, so regenerating it is not a problem.
So, there is two problems:
First is implementing all that inheritance and overriding.
Second is editing, for example - user is editing a value attribute on <nested-node id="n-node3">. Then, i should somehow create the element in child resouse and create an overrite value. And as an ultimate requirement, is should be great to be able to remove the override if it's excactly mathes what it's overrides.

I have an 6-moth experiense with EMF and still think it's non trivial problem to solve.

Now, a bit of comments, to what have you wrote:

Quote:

So you want to create new derived objects, not just derived values for
features?

My bad, derived values should work fine.
Quote:

Will you need these derived features to stay in sync dynamically with
the changes you make to the model?

What do you mean by sync dynamically? I want user to be able to edit only a selected instance, so then editing child model no changes should be made to parent. Changes to parent is relatively rare, so i think we can afford not tracking the chages, possibly made to parent model during child editing.

Report message to a moderator

Re: [EMF] Implementing Instance Model Inheritance [message #988734 is a reply to message #988707]

Sun, 02 December 2012 07:26

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Comments below. 
 
<div class="moz-cite-prefix">On 01/12/2012 7:24 PM, Dark Diver
wrote: 
</div>
<blockquote cite="mid:k9di0e$n52$1@xxxxxxxxe.org" type="cite">Thanks,
Ed, for you answers!
 
 
Let me clarify our design a bit. We have a data-shema, represented
by 12 eCore files (some are just a reusable parts). An instance
model consists of (8+ the exact amount can vary) files, which is
located in the same folder, and are treatened in some way, based
on it's filename. The entire domain model consists of many folders
with instances, in the specific directory layout. All the things
related to locating and loading the models were solved by us, so
it's working fine. Now to the problem. Our requirement is, that
any instace can inherit it's properties from another, specified by
it's 'parent' attribute instance instance. A concrete resouce,
from which to inherit is determined by file extension. Now i will
explain the case, which i don't know how to deal with:
 
 
Suppose i have parent model:
 
 
<root name="parent">
 
<node id="node1">
 
 <nested-node
id="n-node1">parent-value1</nested-node>
 
</node>
 
<node id="node2">
 
 <nested-node
id="n-node2">parent-value2</nested-node>
 
 <nested-node
id="n-node3">parent-value3</nested-node>
 
</node> </root>
 
 
And a child model:
 
 
<root name="child" parent="parent">
 
<node id="node2">
 
 <nested-node
id="n-node2>child-value</nested-node> </node>
</root>
 
 
Then the symantic (merged) model is:
 
 
<root name="child" parent="parent">
 
<node id="node1">
 
 <nested-node
id="n-node1">parent-value1</nested-node>
 
</node>
 
<node id="node2">
 
 <nested-node id="n-node2">child-value</nested-node>

 
 <nested-node
id="n-node3">parent-value3</nested-node>
 
</node> </root>
 
 
 
That behaviour should apply to ALL the model features, that's why
i'm thinking of a minimum intrusive way of doing things. </blockquote>
I see. 
<blockquote cite="mid:k9di0e$n52$1@xxxxxxxxe.org" type="cite">Our
model is left 95% untouched and that 5% of customization is just
an Operation specification, so regenerating it is not a problem.
So, there is two problems: First is implementing all that
inheritance and overriding. Second is editing, for example - user
is editing a value attribute on <nested-node id="n-node3">.
Then, i should somehow create the element in child resouse and
create an overrite value. And as an ultimate requirement, is
should be great to be able to remove the override if it's excactly
mathes what it's overrides. 
I have an 6-moth experiense with EMF and still think it's non
trivial problem to solve.
 
</blockquote>
No, that seems quite tricky. So by ALL model features, I assume you
mean the "node" containment feature and the "nested-node"
containment feature and other containment features like that and
then presumably there is some "value" feature which you're showing
as element content and perhaps there are other features like that
too. So you really want to double the number of features in the
model to support a derived form for each original? 
 
As of EMF 2.8, there is support for structural features having a
"body" annotation, i.e., an EAnnotation with source URI set to
GenModelPackage.eNS_URI and with a "get" key with a corresponding
snippet of Java code that will be inserted into the generated
implementation class. You might specify the body for each derived
feature with some type of call that will do everything reflectively,
i.e., 
<blockquote><%org.example.MyReflectionUtility%>.<EList<Node>>compute(this,
MyPackage.Literals.NODE__FEATURE); 
</blockquote>
The overall design is challenging. It would take me quite some time
to come up with a nice design and I have very little time... 
<blockquote cite="mid:k9di0e$n52$1@xxxxxxxxe.org" type="cite">
 
Now, a bit of comments, to what have you wrote:
 
 
Quote:
 
<blockquote type="cite">So you want to create new derived objects,
not just derived values for
 
features?
 
</blockquote>
 
My bad, derived values should work fine.
 
Quote:
 
<blockquote type="cite">Will you need these derived features to
stay in sync dynamically with
 
the changes you make to the model?
 
</blockquote>
 
 
What do you mean by sync dynamically? I want user to be able to
edit only a selected instance, so then editing child model no
changes should be made to parent. Changes to parent is relatively
rare, so i think we can afford not tracking the chages, possibly
made to parent model during child editing. 
</blockquote>
Yes, I was concerned about the impact that modifying the parent has
on the children. 
 
</body>
</html>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	[CDO] Comparing object ids with OCL query
Next Topic:	Filter notifications when resource is loading

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 22:05:45 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter