Home » Modeling » EMF » Best-practices/patterns with extensible models
| Best-practices/patterns with extensible models [message #776946] |
Mon, 09 January 2012 15:19  |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hello everyone,
during the development or our last tool (EMF and CDO based RCP), we
identified some design requirements desirable for any future projects.
I would like to see if there is any best-practice or pattern for such
design, if anyone else has faced this too.
Our business model is based on OMG's KDM (Knowledge Discovery
Metamodel). We use the specification to model software in a
language-agnostic manner. The particularity of KDM is that it has (like
UML does with UML Profiles) its own extension mechanism, the so called
"Extension Family". You can find concepts like Stereotypes, Tagged
Values or References, etc.
Once a software system is transformed into a KDM model instance, then
the fun part starts: you can do any analysis over the instance to
extract information from it. We, most of the time, define this as
Extension Families, proceed with the analisys, and then decorate our
model instances with information conforming to the Extension Family.
Just to make sure I'm giving enough information to let everyone follow
this, I would like to make emphasis again on the fact that KDM,
a language we formalized using EMF, is itself capable of defining
extension of itself. This is the key difference with other models our there.
So in the end we spend most time developing these analysis components
and dealing with Extension Families. Manipulation of those extension
families occur through the EMF API generated for the KDM model, but
using it reminds pretty much to manipulation of a model through EMF
reflexive API. This leads to lots of dangerous hardcoded strings and
duplicated opperations scattered all around. Its a lot of boilerplate
code tedious to code, and hard to maintain. So the first idea that comes
to mind is to refactor all that in a Extension Family oriented API.
The definition of extension families APIs worked pretty well. It allowed
me to manipulate / query KDM in terms of this extension family. All that
boilerplate code was in one single place, and everyone that wanted to do
any manipulation / query, had to use this API. Even model
transformations, using blackbox mechanisms, had to call this API, so no
one, but the API implementation, knew how to deal with the extension family.
I looks to me like the way to go, but it reminded me too much doing
manually what EMF does better and easier: modeling a specific domain of
knowledge.
So, to sumarize what we have so far is: I would like to model something
like an UML Profile in the KDM world. I want all that nice business
objects, manipulation API and serialization that EMF gives for free, but
everything must be serialized in an interoperable manner using the KDM
model. It seems obvious to me this is applicable to any other model with
extension capabilities.
"lets do it as we always do!" I told myself. Why don't we just define
another EMF model that formalizes that extension family. Well, I started
to think about it and didn't seem to match with what I wanted:
- I could create a decorator model, but that implies complex
sincronization mechanisms between decorator and the KDM model.
- I could specialize KDM concepts into concepts from my Extension Family
domain. However, it implies the information is persisted not as KDM, but
as the extender model -> not interoperable.
So far, the only solution I find is to create my own code generator for
this, to do something very smiliar to what EMF does (getters, setters,
and opperations) for the KDM model. But before committing to that, I
would like to kindly ask the community for feedback. Has anyone faced
this situation too? Are there any EMF concepts that I'm not aware of,
and could help me achieving this? Best-practices or patterns for this
design?
Any feedback is very much welcome.
Cheers,
Víctor.
|
|
| | | |
| Re: Best-practices/patterns with extensible models [message #776978 is a reply to message #776946] |
Mon, 09 January 2012 15:52  |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Víctor,
Comments below.
On 09/01/2012 4:19 PM, Víctor Roldán Betancort wrote:
> Hello everyone,
>
> during the development or our last tool (EMF and CDO based RCP), we
> identified some design requirements desirable for any future projects.
> I would like to see if there is any best-practice or pattern for such
> design, if anyone else has faced this too.
>
> Our business model is based on OMG's KDM (Knowledge Discovery
> Metamodel). We use the specification to model software in a
> language-agnostic manner. The particularity of KDM is that it has
> (like UML does with UML Profiles) its own extension mechanism, the so
> called "Extension Family". You can find concepts like Stereotypes,
> Tagged Values or References, etc.
>
> Once a software system is transformed into a KDM model instance, then
> the fun part starts: you can do any analysis over the instance to
> extract information from it. We, most of the time, define this as
> Extension Families, proceed with the analisys, and then decorate our
> model instances with information conforming to the Extension Family.
>
> Just to make sure I'm giving enough information to let everyone follow
> this, I would like to make emphasis again on the fact that KDM,
> a language we formalized using EMF, is itself capable of defining
> extension of itself. This is the key difference with other models our
> there.
>
> So in the end we spend most time developing these analysis components
> and dealing with Extension Families. Manipulation of those extension
> families occur through the EMF API generated for the KDM model, but
> using it reminds pretty much to manipulation of a model through EMF
> reflexive API. This leads to lots of dangerous hardcoded strings and
> duplicated opperations scattered all around. Its a lot of boilerplate
> code tedious to code, and hard to maintain. So the first idea that
> comes to mind is to refactor all that in a Extension Family oriented API.
>
> The definition of extension families APIs worked pretty well. It
> allowed me to manipulate / query KDM in terms of this extension
> family. All that boilerplate code was in one single place, and
> everyone that wanted to do any manipulation / query, had to use this
> API. Even model transformations, using blackbox mechanisms, had to
> call this API, so no one, but the API implementation, knew how to deal
> with the extension family.
>
> I looks to me like the way to go, but it reminded me too much doing
> manually what EMF does better and easier: modeling a specific domain
> of knowledge.
>
> So, to sumarize what we have so far is: I would like to model
> something like an UML Profile in the KDM world. I want all that nice
> business objects, manipulation API and serialization that EMF gives
> for free, but everything must be serialized in an interoperable manner
> using the KDM model. It seems obvious to me this is applicable to any
> other model with extension capabilities.
>
> "lets do it as we always do!" I told myself. Why don't we just define
> another EMF model that formalizes that extension family. Well, I
> started to think about it and didn't seem to match with what I wanted:
>
> - I could create a decorator model, but that implies complex
> sincronization mechanisms between decorator and the KDM model.
Can't the EMF instances at the same time also be extension family
instances? (Of course I'm not sure what that means.)
> - I could specialize KDM concepts into concepts from my Extension
> Family domain. However, it implies the information is persisted not as
> KDM, but as the extender model -> not interoperable.
>
> So far, the only solution I find is to create my own code generator
> for this, to do something very smiliar to what EMF does (getters,
> setters, and opperations) for the KDM model. But before committing to
> that, I would like to kindly ask the community for feedback. Has
> anyone faced this situation too? Are there any EMF concepts that I'm
> not aware of, and could help me achieving this? Best-practices or
> patterns for this design?
Would something like reflective delegation help you in terms of a
decorator where all synchronization is reflective/generic?
>
> Any feedback is very much welcome.
>
> Cheers,
> Víctor.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Best-practices/patterns with extensible models [message #776995 is a reply to message #776978] |
Mon, 09 January 2012 16:19 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
thanks for your feedback. Comments below:
Ed Merks escribió:
> Víctor,
>
> Comments below.
>
>
> On 09/01/2012 4:19 PM, Víctor Roldán Betancort wrote:
>> Hello everyone,
>>
>> during the development or our last tool (EMF and CDO based RCP), we
>> identified some design requirements desirable for any future projects.
>> I would like to see if there is any best-practice or pattern for such
>> design, if anyone else has faced this too.
>>
>> Our business model is based on OMG's KDM (Knowledge Discovery
>> Metamodel). We use the specification to model software in a
>> language-agnostic manner. The particularity of KDM is that it has
>> (like UML does with UML Profiles) its own extension mechanism, the so
>> called "Extension Family". You can find concepts like Stereotypes,
>> Tagged Values or References, etc.
>>
>> Once a software system is transformed into a KDM model instance, then
>> the fun part starts: you can do any analysis over the instance to
>> extract information from it. We, most of the time, define this as
>> Extension Families, proceed with the analisys, and then decorate our
>> model instances with information conforming to the Extension Family.
>>
>> Just to make sure I'm giving enough information to let everyone follow
>> this, I would like to make emphasis again on the fact that KDM,
>> a language we formalized using EMF, is itself capable of defining
>> extension of itself. This is the key difference with other models our
>> there.
>>
>> So in the end we spend most time developing these analysis components
>> and dealing with Extension Families. Manipulation of those extension
>> families occur through the EMF API generated for the KDM model, but
>> using it reminds pretty much to manipulation of a model through EMF
>> reflexive API. This leads to lots of dangerous hardcoded strings and
>> duplicated opperations scattered all around. Its a lot of boilerplate
>> code tedious to code, and hard to maintain. So the first idea that
>> comes to mind is to refactor all that in a Extension Family oriented API.
>>
>> The definition of extension families APIs worked pretty well. It
>> allowed me to manipulate / query KDM in terms of this extension
>> family. All that boilerplate code was in one single place, and
>> everyone that wanted to do any manipulation / query, had to use this
>> API. Even model transformations, using blackbox mechanisms, had to
>> call this API, so no one, but the API implementation, knew how to deal
>> with the extension family.
>>
>> I looks to me like the way to go, but it reminded me too much doing
>> manually what EMF does better and easier: modeling a specific domain
>> of knowledge.
>>
>> So, to sumarize what we have so far is: I would like to model
>> something like an UML Profile in the KDM world. I want all that nice
>> business objects, manipulation API and serialization that EMF gives
>> for free, but everything must be serialized in an interoperable manner
>> using the KDM model. It seems obvious to me this is applicable to any
>> other model with extension capabilities.
>>
>> "lets do it as we always do!" I told myself. Why don't we just define
>> another EMF model that formalizes that extension family. Well, I
>> started to think about it and didn't seem to match with what I wanted:
>>
>> - I could create a decorator model, but that implies complex
>> sincronization mechanisms between decorator and the KDM model.
> Can't the EMF instances at the same time also be extension family
> instances? (Of course I'm not sure what that means.)
Extension Family "definition" and "instances" are all defined within the
KDM Model, so they are EClasses/EObjects. A extension family is an
EClass named "ExtensionFamily" and, if you want, for instance, something
to be stereotyped with a Stereotype defined in certain extension family,
you only need to make that object point to the stereotype definition.
(sorry if this was already obvious to you...)
So, If I correctly understood what you are meaning, yes, extension
families are EClasses instances defined in the KDM model.
>> - I could specialize KDM concepts into concepts from my Extension
>> Family domain. However, it implies the information is persisted not as
>> KDM, but as the extender model -> not interoperable.
>>
>> So far, the only solution I find is to create my own code generator
>> for this, to do something very smiliar to what EMF does (getters,
>> setters, and opperations) for the KDM model. But before committing to
>> that, I would like to kindly ask the community for feedback. Has
>> anyone faced this situation too? Are there any EMF concepts that I'm
>> not aware of, and could help me achieving this? Best-practices or
>> patterns for this design?
> Would something like reflective delegation help you in terms of a
> decorator where all synchronization is reflective/generic?
Although I've read many times about the "reflective delegation" concept,
I'm not aware of what it means. But, If I understand what you mean (code
that delegates to the "reflective" KDM API, in our case), that would be
actually ideal. Is it possible to have an EMF model whose setters /
getters delegate to another model somehow? Something like a "derived
model", but with bi-directional synchronization?
>>
>> Any feedback is very much welcome.
>>
>> Cheers,
>> Víctor.
Thank you!!
Víctor
|
|
|
| Re: Best-practices/patterns with extensible models [message #777118 is a reply to message #776995] |
Mon, 09 January 2012 22:00 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Víctor,
CDO makes use of these delegation patterns to delegate everything onto a
store. The same approach could be used to delegate onto another
representation. What does the generic API for these things look like?
On 09/01/2012 5:19 PM, Víctor Roldán Betancort wrote:
> Hi Ed,
>
> thanks for your feedback. Comments below:
>
> Ed Merks escribió:
>> Víctor,
>>
>> Comments below.
>>
>>
>> On 09/01/2012 4:19 PM, Víctor Roldán Betancort wrote:
>>> Hello everyone,
>>>
>>> during the development or our last tool (EMF and CDO based RCP), we
>>> identified some design requirements desirable for any future projects.
>>> I would like to see if there is any best-practice or pattern for such
>>> design, if anyone else has faced this too.
>>>
>>> Our business model is based on OMG's KDM (Knowledge Discovery
>>> Metamodel). We use the specification to model software in a
>>> language-agnostic manner. The particularity of KDM is that it has
>>> (like UML does with UML Profiles) its own extension mechanism, the so
>>> called "Extension Family". You can find concepts like Stereotypes,
>>> Tagged Values or References, etc.
>>>
>>> Once a software system is transformed into a KDM model instance, then
>>> the fun part starts: you can do any analysis over the instance to
>>> extract information from it. We, most of the time, define this as
>>> Extension Families, proceed with the analisys, and then decorate our
>>> model instances with information conforming to the Extension Family.
>>>
>>> Just to make sure I'm giving enough information to let everyone follow
>>> this, I would like to make emphasis again on the fact that KDM,
>>> a language we formalized using EMF, is itself capable of defining
>>> extension of itself. This is the key difference with other models our
>>> there.
>>>
>>> So in the end we spend most time developing these analysis components
>>> and dealing with Extension Families. Manipulation of those extension
>>> families occur through the EMF API generated for the KDM model, but
>>> using it reminds pretty much to manipulation of a model through EMF
>>> reflexive API. This leads to lots of dangerous hardcoded strings and
>>> duplicated opperations scattered all around. Its a lot of boilerplate
>>> code tedious to code, and hard to maintain. So the first idea that
>>> comes to mind is to refactor all that in a Extension Family oriented
>>> API.
>>>
>>> The definition of extension families APIs worked pretty well. It
>>> allowed me to manipulate / query KDM in terms of this extension
>>> family. All that boilerplate code was in one single place, and
>>> everyone that wanted to do any manipulation / query, had to use this
>>> API. Even model transformations, using blackbox mechanisms, had to
>>> call this API, so no one, but the API implementation, knew how to deal
>>> with the extension family.
>>>
>>> I looks to me like the way to go, but it reminded me too much doing
>>> manually what EMF does better and easier: modeling a specific domain
>>> of knowledge.
>>>
>>> So, to sumarize what we have so far is: I would like to model
>>> something like an UML Profile in the KDM world. I want all that nice
>>> business objects, manipulation API and serialization that EMF gives
>>> for free, but everything must be serialized in an interoperable manner
>>> using the KDM model. It seems obvious to me this is applicable to any
>>> other model with extension capabilities.
>>>
>>> "lets do it as we always do!" I told myself. Why don't we just define
>>> another EMF model that formalizes that extension family. Well, I
>>> started to think about it and didn't seem to match with what I wanted:
>>>
>>> - I could create a decorator model, but that implies complex
>>> sincronization mechanisms between decorator and the KDM model.
>> Can't the EMF instances at the same time also be extension family
>> instances? (Of course I'm not sure what that means.)
>
> Extension Family "definition" and "instances" are all defined within
> the KDM Model, so they are EClasses/EObjects. A extension family is an
> EClass named "ExtensionFamily" and, if you want, for instance,
> something to be stereotyped with a Stereotype defined in certain
> extension family, you only need to make that object point to the
> stereotype definition. (sorry if this was already obvious to you...)
>
> So, If I correctly understood what you are meaning, yes, extension
> families are EClasses instances defined in the KDM model.
>
>
>>> - I could specialize KDM concepts into concepts from my Extension
>>> Family domain. However, it implies the information is persisted not as
>>> KDM, but as the extender model -> not interoperable.
>>>
>>> So far, the only solution I find is to create my own code generator
>>> for this, to do something very smiliar to what EMF does (getters,
>>> setters, and opperations) for the KDM model. But before committing to
>>> that, I would like to kindly ask the community for feedback. Has
>>> anyone faced this situation too? Are there any EMF concepts that I'm
>>> not aware of, and could help me achieving this? Best-practices or
>>> patterns for this design?
>
>> Would something like reflective delegation help you in terms of a
>> decorator where all synchronization is reflective/generic?
>
> Although I've read many times about the "reflective delegation"
> concept, I'm not aware of what it means. But, If I understand what you
> mean (code that delegates to the "reflective" KDM API, in our case),
> that would be actually ideal. Is it possible to have an EMF model
> whose setters / getters delegate to another model somehow? Something
> like a "derived model", but with bi-directional synchronization?
>
>>>
>>> Any feedback is very much welcome.
>>>
>>> Cheers,
>>> Víctor.
>
> Thank you!!
> Víctor
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Best-practices/patterns with extensible models [message #777463 is a reply to message #777118] |
Tue, 10 January 2012 14:52 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Ed,
Ed Merks escribió:
> Víctor,
>
> CDO makes use of these delegation patterns to delegate everything onto a
> store.
I took a look at the EMF reflective delegation mechanism and how CDO
does it (Eike wrote a great article some time ago, by the way
http://thegordian.blogspot.com/2008/11/how-scalable-are-my-models.html).
Did some tests with generator. The idea behind reflective seems clear.
Needed several regeneration cycles to understand the differences with
"dynamic":
(I'll omit setXX -> eSet paralelism)
Reflective: genXX -> eGet -> SettingDelegate
Dynamic: eGet -> genXX -> SettingDelegate
So it looks to me:
Reflective -> slightly more efficient for frameworks using reflective
API. Not ideal for genXX customization?
Dynamic -> Ideal for getXX customization. Slightly less efficient for
frameworks using reflective API.
However http://www.eclipse.org/forums/index.php/mv/tree/161479/#page_top
states actually the opposite. What did understood wrong?
Managed to understand Virtual from Kenn Hussey's description at its
bugzilla:
"Add runtime and code generation support for models which delegate to
virtual storage for their non-primitive data types. The virtual storage
would be an array that only allocates space for features that have
values. This will help reduce memory overhead for sparse model
instances, i.e. ones in which objects only have values for a (small)
subset of their features."
I actually found this interesting for sparse models stored in CDO, could
help save memory, although Eike already warned virtual would be
incompatible with CDO's reflective delegation usage.
Kenn also shared a great presentation some time ago:
http://www.slideshare.net/kenn.hussey/performance-and-extensibility-with-emf
(I guess you already knew all the above, but found it interesting to
share my findings here :) )
> The same approach could be used to delegate onto another
> representation.
Yeah, thats should work for deriving EStructuralFeatures from our KDM
representation. However, for this new model which delegates feature
calculation to a KDM instance, how is the object graph populated? Maybe
customization of the Resource.Factory, traversing the KDM and then
constructing the new graph?
While it sounds feasible, I looks like I'll probably need a lot of
coding for each new Extension Family, or maybe in the best case, just
maybe extending the generator. If EMF Facet does what it actually
promises, seems to me like the way to go, but I guess they don't have
any code / API generation.
> What does the generic API for these things look like?
What do you mean with "these things"?
Thanks a lot!
Víctor.
>
> On 09/01/2012 5:19 PM, Víctor Roldán Betancort wrote:
>> Hi Ed,
>>
>> thanks for your feedback. Comments below:
>>
>> Ed Merks escribió:
>>> Víctor,
>>>
>>> Comments below.
>>>
>>>
>>> On 09/01/2012 4:19 PM, Víctor Roldán Betancort wrote:
>>>> Hello everyone,
>>>>
>>>> during the development or our last tool (EMF and CDO based RCP), we
>>>> identified some design requirements desirable for any future projects.
>>>> I would like to see if there is any best-practice or pattern for such
>>>> design, if anyone else has faced this too.
>>>>
>>>> Our business model is based on OMG's KDM (Knowledge Discovery
>>>> Metamodel). We use the specification to model software in a
>>>> language-agnostic manner. The particularity of KDM is that it has
>>>> (like UML does with UML Profiles) its own extension mechanism, the so
>>>> called "Extension Family". You can find concepts like Stereotypes,
>>>> Tagged Values or References, etc.
>>>>
>>>> Once a software system is transformed into a KDM model instance, then
>>>> the fun part starts: you can do any analysis over the instance to
>>>> extract information from it. We, most of the time, define this as
>>>> Extension Families, proceed with the analisys, and then decorate our
>>>> model instances with information conforming to the Extension Family.
>>>>
>>>> Just to make sure I'm giving enough information to let everyone follow
>>>> this, I would like to make emphasis again on the fact that KDM,
>>>> a language we formalized using EMF, is itself capable of defining
>>>> extension of itself. This is the key difference with other models our
>>>> there.
>>>>
>>>> So in the end we spend most time developing these analysis components
>>>> and dealing with Extension Families. Manipulation of those extension
>>>> families occur through the EMF API generated for the KDM model, but
>>>> using it reminds pretty much to manipulation of a model through EMF
>>>> reflexive API. This leads to lots of dangerous hardcoded strings and
>>>> duplicated opperations scattered all around. Its a lot of boilerplate
>>>> code tedious to code, and hard to maintain. So the first idea that
>>>> comes to mind is to refactor all that in a Extension Family oriented
>>>> API.
>>>>
>>>> The definition of extension families APIs worked pretty well. It
>>>> allowed me to manipulate / query KDM in terms of this extension
>>>> family. All that boilerplate code was in one single place, and
>>>> everyone that wanted to do any manipulation / query, had to use this
>>>> API. Even model transformations, using blackbox mechanisms, had to
>>>> call this API, so no one, but the API implementation, knew how to deal
>>>> with the extension family.
>>>>
>>>> I looks to me like the way to go, but it reminded me too much doing
>>>> manually what EMF does better and easier: modeling a specific domain
>>>> of knowledge.
>>>>
>>>> So, to sumarize what we have so far is: I would like to model
>>>> something like an UML Profile in the KDM world. I want all that nice
>>>> business objects, manipulation API and serialization that EMF gives
>>>> for free, but everything must be serialized in an interoperable manner
>>>> using the KDM model. It seems obvious to me this is applicable to any
>>>> other model with extension capabilities.
>>>>
>>>> "lets do it as we always do!" I told myself. Why don't we just define
>>>> another EMF model that formalizes that extension family. Well, I
>>>> started to think about it and didn't seem to match with what I wanted:
>>>>
>>>> - I could create a decorator model, but that implies complex
>>>> sincronization mechanisms between decorator and the KDM model.
>>> Can't the EMF instances at the same time also be extension family
>>> instances? (Of course I'm not sure what that means.)
>>
>> Extension Family "definition" and "instances" are all defined within
>> the KDM Model, so they are EClasses/EObjects. A extension family is an
>> EClass named "ExtensionFamily" and, if you want, for instance,
>> something to be stereotyped with a Stereotype defined in certain
>> extension family, you only need to make that object point to the
>> stereotype definition. (sorry if this was already obvious to you...)
>>
>> So, If I correctly understood what you are meaning, yes, extension
>> families are EClasses instances defined in the KDM model.
>>
>>
>>>> - I could specialize KDM concepts into concepts from my Extension
>>>> Family domain. However, it implies the information is persisted not as
>>>> KDM, but as the extender model -> not interoperable.
>>>>
>>>> So far, the only solution I find is to create my own code generator
>>>> for this, to do something very smiliar to what EMF does (getters,
>>>> setters, and opperations) for the KDM model. But before committing to
>>>> that, I would like to kindly ask the community for feedback. Has
>>>> anyone faced this situation too? Are there any EMF concepts that I'm
>>>> not aware of, and could help me achieving this? Best-practices or
>>>> patterns for this design?
>>
>>> Would something like reflective delegation help you in terms of a
>>> decorator where all synchronization is reflective/generic?
>>
>> Although I've read many times about the "reflective delegation"
>> concept, I'm not aware of what it means. But, If I understand what you
>> mean (code that delegates to the "reflective" KDM API, in our case),
>> that would be actually ideal. Is it possible to have an EMF model
>> whose setters / getters delegate to another model somehow? Something
>> like a "derived model", but with bi-directional synchronization?
>>
>>>>
>>>> Any feedback is very much welcome.
>>>>
>>>> Cheers,
>>>> Víctor.
>>
>> Thank you!!
>> Víctor
|
|
|
| Re: Best-practices/patterns with extensible models [message #777937 is a reply to message #777463] |
Wed, 11 January 2012 07:31 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Víctor,
Comments below.
On 10/01/2012 3:52 PM, Víctor Roldán Betancort wrote:
> Ed,
>
> Ed Merks escribió:
>> Víctor,
>>
>> CDO makes use of these delegation patterns to delegate everything onto a
>> store.
>
> I took a look at the EMF reflective delegation mechanism and how CDO
> does it (Eike wrote a great article some time ago, by the way
> http://thegordian.blogspot.com/2008/11/how-scalable-are-my-models.html).
> Did some tests with generator. The idea behind reflective seems clear.
> Needed several regeneration cycles to understand the differences with
> "dynamic":
Yes, it's subtle.
>
> (I'll omit setXX -> eSet paralelism)
Yes, and for lists there isn't a setX anyway.
>
> Reflective: genXX -> eGet -> SettingDelegate
Yes, delegate generated methods onto reflective ones, which delegate
onto the dynamic API which is implemented using setting delegates.
> Dynamic: eGet -> genXX -> SettingDelegate
Yes, delegate reflective methods onto the generated ones as normal and
have those delegate onto the dynamic API which is implemented using
setting delegates.
>
> So it looks to me:
>
> Reflective -> slightly more efficient for frameworks using reflective
> API. Not ideal for genXX customization?
Yes, direct reflection gets to the actual implementation more quickly,
although with JIT compiler in-lining, that difference might disappear.
> Dynamic -> Ideal for getXX customization. Slightly less efficient for
> frameworks using reflective API.
Yes, necessary if folks want to customize behavior as they normally do
via the generated methods.
>
> However
> http://www.eclipse.org/forums/index.php/mv/tree/161479/#page_top
> states actually the opposite. What did understood wrong?
What you outline is correct. Oops. :-P
>
> Managed to understand Virtual from Kenn Hussey's description at its
> bugzilla:
>
> "Add runtime and code generation support for models which delegate to
> virtual storage for their non-primitive data types. The virtual
> storage would be an array that only allocates space for features that
> have values. This will help reduce memory overhead for sparse model
> instances, i.e. ones in which objects only have values for a (small)
> subset of their features."
>
> I actually found this interesting for sparse models stored in CDO,
> could help save memory, although Eike already warned virtual would be
> incompatible with CDO's reflective delegation usage.
>
> Kenn also shared a great presentation some time ago:
> http://www.slideshare.net/kenn.hussey/performance-and-extensibility-with-emf
>
>
> (I guess you already knew all the above, but found it interesting to
> share my findings here :) )
>
>> The same approach could be used to delegate onto another
>> representation.
>
> Yeah, thats should work for deriving EStructuralFeatures from our KDM
> representation. However, for this new model which delegates feature
> calculation to a KDM instance, how is the object graph populated?
> Maybe customization of the Resource.Factory, traversing the KDM and
> then constructing the new graph?
I suppose ideally it would be done lazily. I imagine you'd want to
model itself to be aware of this...
>
> While it sounds feasible, I looks like I'll probably need a lot of
> coding for each new Extension Family, or maybe in the best case, just
> maybe extending the generator.
I'm just not sure about that. Keep in mind that all of EMF is possible
without generating any model code because the generator patterns can be
emulated dynamically. In general, if you can generate it, you can
interpret it as well. So perhaps the only generator customization you
need is a specialize Root Extends Class that behaves the right way.
> If EMF Facet does what it actually promises, seems to me like the way
> to go, but I guess they don't have any code / API generation.
I'm not sure.
>
>> What does the generic API for these things look like?
>
> What do you mean with "these things"?
The reflective API for the extension family. You'd need extension
family "model" maps to "Ecore" model and then ensure that the underlying
EObject reflection maps back onto the extension family reflection...
>
> Thanks a lot!
> Víctor.
>
>>
>> On 09/01/2012 5:19 PM, Víctor Roldán Betancort wrote:
>>> Hi Ed,
>>>
>>> thanks for your feedback. Comments below:
>>>
>>> Ed Merks escribió:
>>>> Víctor,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> On 09/01/2012 4:19 PM, Víctor Roldán Betancort wrote:
>>>>> Hello everyone,
>>>>>
>>>>> during the development or our last tool (EMF and CDO based RCP), we
>>>>> identified some design requirements desirable for any future
>>>>> projects.
>>>>> I would like to see if there is any best-practice or pattern for such
>>>>> design, if anyone else has faced this too.
>>>>>
>>>>> Our business model is based on OMG's KDM (Knowledge Discovery
>>>>> Metamodel). We use the specification to model software in a
>>>>> language-agnostic manner. The particularity of KDM is that it has
>>>>> (like UML does with UML Profiles) its own extension mechanism, the so
>>>>> called "Extension Family". You can find concepts like Stereotypes,
>>>>> Tagged Values or References, etc.
>>>>>
>>>>> Once a software system is transformed into a KDM model instance, then
>>>>> the fun part starts: you can do any analysis over the instance to
>>>>> extract information from it. We, most of the time, define this as
>>>>> Extension Families, proceed with the analisys, and then decorate our
>>>>> model instances with information conforming to the Extension Family.
>>>>>
>>>>> Just to make sure I'm giving enough information to let everyone
>>>>> follow
>>>>> this, I would like to make emphasis again on the fact that KDM,
>>>>> a language we formalized using EMF, is itself capable of defining
>>>>> extension of itself. This is the key difference with other models our
>>>>> there.
>>>>>
>>>>> So in the end we spend most time developing these analysis components
>>>>> and dealing with Extension Families. Manipulation of those extension
>>>>> families occur through the EMF API generated for the KDM model, but
>>>>> using it reminds pretty much to manipulation of a model through EMF
>>>>> reflexive API. This leads to lots of dangerous hardcoded strings and
>>>>> duplicated opperations scattered all around. Its a lot of boilerplate
>>>>> code tedious to code, and hard to maintain. So the first idea that
>>>>> comes to mind is to refactor all that in a Extension Family oriented
>>>>> API.
>>>>>
>>>>> The definition of extension families APIs worked pretty well. It
>>>>> allowed me to manipulate / query KDM in terms of this extension
>>>>> family. All that boilerplate code was in one single place, and
>>>>> everyone that wanted to do any manipulation / query, had to use this
>>>>> API. Even model transformations, using blackbox mechanisms, had to
>>>>> call this API, so no one, but the API implementation, knew how to
>>>>> deal
>>>>> with the extension family.
>>>>>
>>>>> I looks to me like the way to go, but it reminded me too much doing
>>>>> manually what EMF does better and easier: modeling a specific domain
>>>>> of knowledge.
>>>>>
>>>>> So, to sumarize what we have so far is: I would like to model
>>>>> something like an UML Profile in the KDM world. I want all that nice
>>>>> business objects, manipulation API and serialization that EMF gives
>>>>> for free, but everything must be serialized in an interoperable
>>>>> manner
>>>>> using the KDM model. It seems obvious to me this is applicable to any
>>>>> other model with extension capabilities.
>>>>>
>>>>> "lets do it as we always do!" I told myself. Why don't we just define
>>>>> another EMF model that formalizes that extension family. Well, I
>>>>> started to think about it and didn't seem to match with what I
>>>>> wanted:
>>>>>
>>>>> - I could create a decorator model, but that implies complex
>>>>> sincronization mechanisms between decorator and the KDM model.
>>>> Can't the EMF instances at the same time also be extension family
>>>> instances? (Of course I'm not sure what that means.)
>>>
>>> Extension Family "definition" and "instances" are all defined within
>>> the KDM Model, so they are EClasses/EObjects. A extension family is an
>>> EClass named "ExtensionFamily" and, if you want, for instance,
>>> something to be stereotyped with a Stereotype defined in certain
>>> extension family, you only need to make that object point to the
>>> stereotype definition. (sorry if this was already obvious to you...)
>>>
>>> So, If I correctly understood what you are meaning, yes, extension
>>> families are EClasses instances defined in the KDM model.
>>>
>>>
>>>>> - I could specialize KDM concepts into concepts from my Extension
>>>>> Family domain. However, it implies the information is persisted
>>>>> not as
>>>>> KDM, but as the extender model -> not interoperable.
>>>>>
>>>>> So far, the only solution I find is to create my own code generator
>>>>> for this, to do something very smiliar to what EMF does (getters,
>>>>> setters, and opperations) for the KDM model. But before committing to
>>>>> that, I would like to kindly ask the community for feedback. Has
>>>>> anyone faced this situation too? Are there any EMF concepts that I'm
>>>>> not aware of, and could help me achieving this? Best-practices or
>>>>> patterns for this design?
>>>
>>>> Would something like reflective delegation help you in terms of a
>>>> decorator where all synchronization is reflective/generic?
>>>
>>> Although I've read many times about the "reflective delegation"
>>> concept, I'm not aware of what it means. But, If I understand what you
>>> mean (code that delegates to the "reflective" KDM API, in our case),
>>> that would be actually ideal. Is it possible to have an EMF model
>>> whose setters / getters delegate to another model somehow? Something
>>> like a "derived model", but with bi-directional synchronization?
>>>
>>>>>
>>>>> Any feedback is very much welcome.
>>>>>
>>>>> Cheers,
>>>>> Víctor.
>>>
>>> Thank you!!
>>> Víctor
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Best-practices/patterns with extensible models [message #778114 is a reply to message #777937] |
Wed, 11 January 2012 12:35 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Ed,
comments below
Ed Merks escribió:
> Víctor,
>
> Comments below.
>
> On 10/01/2012 3:52 PM, Víctor Roldán Betancort wrote:
>> Ed,
>>
>> Ed Merks escribió:
>>> Víctor,
>>>
>>> CDO makes use of these delegation patterns to delegate everything onto a
>>> store.
>>
>> I took a look at the EMF reflective delegation mechanism and how CDO
>> does it (Eike wrote a great article some time ago, by the way
>> http://thegordian.blogspot.com/2008/11/how-scalable-are-my-models.html).
>> Did some tests with generator. The idea behind reflective seems clear.
>> Needed several regeneration cycles to understand the differences with
>> "dynamic":
> Yes, it's subtle.
>>
>> (I'll omit setXX -> eSet paralelism)
> Yes, and for lists there isn't a setX anyway.
>>
>> Reflective: genXX -> eGet -> SettingDelegate
> Yes, delegate generated methods onto reflective ones, which delegate
> onto the dynamic API which is implemented using setting delegates.
>> Dynamic: eGet -> genXX -> SettingDelegate
> Yes, delegate reflective methods onto the generated ones as normal and
> have those delegate onto the dynamic API which is implemented using
> setting delegates.
>>
>> So it looks to me:
>>
>> Reflective -> slightly more efficient for frameworks using reflective
>> API. Not ideal for genXX customization?
> Yes, direct reflection gets to the actual implementation more quickly,
> although with JIT compiler in-lining, that difference might disappear.
>> Dynamic -> Ideal for getXX customization. Slightly less efficient for
>> frameworks using reflective API.
> Yes, necessary if folks want to customize behavior as they normally do
> via the generated methods.
>>
>> However
>> http://www.eclipse.org/forums/index.php/mv/tree/161479/#page_top
>> states actually the opposite. What did understood wrong?
> What you outline is correct. Oops. :-P
>>
>> Managed to understand Virtual from Kenn Hussey's description at its
>> bugzilla:
>>
>> "Add runtime and code generation support for models which delegate to
>> virtual storage for their non-primitive data types. The virtual
>> storage would be an array that only allocates space for features that
>> have values. This will help reduce memory overhead for sparse model
>> instances, i.e. ones in which objects only have values for a (small)
>> subset of their features."
>>
>> I actually found this interesting for sparse models stored in CDO,
>> could help save memory, although Eike already warned virtual would be
>> incompatible with CDO's reflective delegation usage.
>>
>> Kenn also shared a great presentation some time ago:
>> http://www.slideshare.net/kenn.hussey/performance-and-extensibility-with-emf
>>
>>
>> (I guess you already knew all the above, but found it interesting to
>> share my findings here :) )
>>
>>> The same approach could be used to delegate onto another
>>> representation.
>>
>> Yeah, thats should work for deriving EStructuralFeatures from our KDM
>> representation. However, for this new model which delegates feature
>> calculation to a KDM instance, how is the object graph populated?
>> Maybe customization of the Resource.Factory, traversing the KDM and
>> then constructing the new graph?
> I suppose ideally it would be done lazily. I imagine you'd want to model
> itself to be aware of this...
>>
>> While it sounds feasible, I looks like I'll probably need a lot of
>> coding for each new Extension Family, or maybe in the best case, just
>> maybe extending the generator.
> I'm just not sure about that. Keep in mind that all of EMF is possible
> without generating any model code because the generator patterns can be
> emulated dynamically. In general, if you can generate it, you can
> interpret it as well. So perhaps the only generator customization you
> need is a specialize Root Extends Class that behaves the right way.
>> If EMF Facet does what it actually promises, seems to me like the way
>> to go, but I guess they don't have any code / API generation.
> I'm not sure.
>>
>>> What does the generic API for these things look like?
>>
>> What do you mean with "these things"?
> The reflective API for the extension family. You'd need extension family
> "model" maps to "Ecore" model and then ensure that the underlying
> EObject reflection maps back onto the extension family reflection...
Interesting. As you say, together with the usage of "Root Extend Class"
and customization of the "extension family model reflection" could make
it feasible. I could make my own extension of EObjectImpl prepared to
understand KDM's extension mechanism. Thanks for the hint!
Researching a bit in this field, I found also two additional interesting
projects regarding this topic, as EMF Face does:
Virtual EMF: A Virtual Model would be like a "proxy model", pointing to
data described by other models. This idea of a "proxy/derived model"
popped up in my mind while searching for a solution for the issue of
this post.
website: https://code.google.com/a/eclipselabs.org/p/virtual-emf/
presentation:
http://www.slideshare.net/HugoBruneliere/virtual-emf-standard-talk-at-eclipsecon-europe-2011
EMF Profiles: project that aims to port the concept of UML Profile to
EMF. It's also an interesting idea, but IMO it looks different to the
original UML Profile concept, as it ends up being just a decorator. But
as a model decorator, looks like a nice initiative for "decoration
interoperability".
website: http://code.google.com/a/eclipselabs.org/p/emf-profiles/
demo:
http://www.modelversioning.org/media/emf-profiles/EJBprofile/EJBprofile.htm
Again, thanks for the feedback Ed!
Víctor.
>>
>> Thanks a lot!
>> Víctor.
>>
>>>
>>> On 09/01/2012 5:19 PM, Víctor Roldán Betancort wrote:
>>>> Hi Ed,
>>>>
>>>> thanks for your feedback. Comments below:
>>>>
>>>> Ed Merks escribió:
>>>>> Víctor,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> On 09/01/2012 4:19 PM, Víctor Roldán Betancort wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> during the development or our last tool (EMF and CDO based RCP), we
>>>>>> identified some design requirements desirable for any future
>>>>>> projects.
>>>>>> I would like to see if there is any best-practice or pattern for such
>>>>>> design, if anyone else has faced this too.
>>>>>>
>>>>>> Our business model is based on OMG's KDM (Knowledge Discovery
>>>>>> Metamodel). We use the specification to model software in a
>>>>>> language-agnostic manner. The particularity of KDM is that it has
>>>>>> (like UML does with UML Profiles) its own extension mechanism, the so
>>>>>> called "Extension Family". You can find concepts like Stereotypes,
>>>>>> Tagged Values or References, etc.
>>>>>>
>>>>>> Once a software system is transformed into a KDM model instance, then
>>>>>> the fun part starts: you can do any analysis over the instance to
>>>>>> extract information from it. We, most of the time, define this as
>>>>>> Extension Families, proceed with the analisys, and then decorate our
>>>>>> model instances with information conforming to the Extension Family.
>>>>>>
>>>>>> Just to make sure I'm giving enough information to let everyone
>>>>>> follow
>>>>>> this, I would like to make emphasis again on the fact that KDM,
>>>>>> a language we formalized using EMF, is itself capable of defining
>>>>>> extension of itself. This is the key difference with other models our
>>>>>> there.
>>>>>>
>>>>>> So in the end we spend most time developing these analysis components
>>>>>> and dealing with Extension Families. Manipulation of those extension
>>>>>> families occur through the EMF API generated for the KDM model, but
>>>>>> using it reminds pretty much to manipulation of a model through EMF
>>>>>> reflexive API. This leads to lots of dangerous hardcoded strings and
>>>>>> duplicated opperations scattered all around. Its a lot of boilerplate
>>>>>> code tedious to code, and hard to maintain. So the first idea that
>>>>>> comes to mind is to refactor all that in a Extension Family oriented
>>>>>> API.
>>>>>>
>>>>>> The definition of extension families APIs worked pretty well. It
>>>>>> allowed me to manipulate / query KDM in terms of this extension
>>>>>> family. All that boilerplate code was in one single place, and
>>>>>> everyone that wanted to do any manipulation / query, had to use this
>>>>>> API. Even model transformations, using blackbox mechanisms, had to
>>>>>> call this API, so no one, but the API implementation, knew how to
>>>>>> deal
>>>>>> with the extension family.
>>>>>>
>>>>>> I looks to me like the way to go, but it reminded me too much doing
>>>>>> manually what EMF does better and easier: modeling a specific domain
>>>>>> of knowledge.
>>>>>>
>>>>>> So, to sumarize what we have so far is: I would like to model
>>>>>> something like an UML Profile in the KDM world. I want all that nice
>>>>>> business objects, manipulation API and serialization that EMF gives
>>>>>> for free, but everything must be serialized in an interoperable
>>>>>> manner
>>>>>> using the KDM model. It seems obvious to me this is applicable to any
>>>>>> other model with extension capabilities.
>>>>>>
>>>>>> "lets do it as we always do!" I told myself. Why don't we just define
>>>>>> another EMF model that formalizes that extension family. Well, I
>>>>>> started to think about it and didn't seem to match with what I
>>>>>> wanted:
>>>>>>
>>>>>> - I could create a decorator model, but that implies complex
>>>>>> sincronization mechanisms between decorator and the KDM model.
>>>>> Can't the EMF instances at the same time also be extension family
>>>>> instances? (Of course I'm not sure what that means.)
>>>>
>>>> Extension Family "definition" and "instances" are all defined within
>>>> the KDM Model, so they are EClasses/EObjects. A extension family is an
>>>> EClass named "ExtensionFamily" and, if you want, for instance,
>>>> something to be stereotyped with a Stereotype defined in certain
>>>> extension family, you only need to make that object point to the
>>>> stereotype definition. (sorry if this was already obvious to you...)
>>>>
>>>> So, If I correctly understood what you are meaning, yes, extension
>>>> families are EClasses instances defined in the KDM model.
>>>>
>>>>
>>>>>> - I could specialize KDM concepts into concepts from my Extension
>>>>>> Family domain. However, it implies the information is persisted
>>>>>> not as
>>>>>> KDM, but as the extender model -> not interoperable.
>>>>>>
>>>>>> So far, the only solution I find is to create my own code generator
>>>>>> for this, to do something very smiliar to what EMF does (getters,
>>>>>> setters, and opperations) for the KDM model. But before committing to
>>>>>> that, I would like to kindly ask the community for feedback. Has
>>>>>> anyone faced this situation too? Are there any EMF concepts that I'm
>>>>>> not aware of, and could help me achieving this? Best-practices or
>>>>>> patterns for this design?
>>>>
>>>>> Would something like reflective delegation help you in terms of a
>>>>> decorator where all synchronization is reflective/generic?
>>>>
>>>> Although I've read many times about the "reflective delegation"
>>>> concept, I'm not aware of what it means. But, If I understand what you
>>>> mean (code that delegates to the "reflective" KDM API, in our case),
>>>> that would be actually ideal. Is it possible to have an EMF model
>>>> whose setters / getters delegate to another model somehow? Something
>>>> like a "derived model", but with bi-directional synchronization?
>>>>
>>>>>>
>>>>>> Any feedback is very much welcome.
>>>>>>
>>>>>> Cheers,
>>>>>> Víctor.
>>>>
>>>> Thank you!!
>>>> Víctor
>>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 04:32:57 GMT 2024
Powered by FUDForum. Page generated in 0.09069 seconds |
] 
Search
Help
Register
Login
Home
