Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » Advice for Modeling Technologies at Eclipse STP
Advice for Modeling Technologies at Eclipse STP [message #383232] Thu, 18 September 2008 21:55 Go to next message
Juan Cadavid is currently offline Juan CadavidFriend
Messages: 49
Registered: July 2009
Location: Rennes, France
Member

Hello Modeling Project Team,

My name is Juan Cadavid and I participated in Google Summer of Code
working on the Eclipse STP project under the supervision of Adrian Mos, in
the Intermediate Model component. As some of you might know, the goal of
this component is to serve as "a «bridge» between STP editors; its
elements have the role of conceptual transport between different
development spaces with the purpose of capturing as much common SOA design
information as possible". You can find more information here:

http://wiki.eclipse.org/STP/IM_Component/STP_Intermediate_Me tamodel

As you can imagine, this goal is strongly leveraged by modeling
technologies, and at this point we'd like to request your advice. In order
to fulfill this goal, work around the IM component has been centered in
writing model transformations between the different STP model editors and
the IM, whether using the Java EMF-generated APIs or ATL. Basically, the
user chooses explicitly when he wants to transform his user model into an
IM instance, and from that point into other types of models supported by
STP.

However, this approach falls short into delivering the full-fledged
integration we aim to achieve. Therefore we started conceiving the idea of
an STP-IM Model Builder, which would automatically update a centralized,
core instance of the Intermediate Model, containing all the conceptual
elements defined across all the models contained in a project. Please take
a moment to take a look at this idea at:

http://wiki.eclipse.org/STP/IM_Component/IM_Builder

The main issue we're facing right now is choosing the technology/approach
for the second phase. There you can see the ones we have considered/tried,
but we haven't found the one to convince us yet. As you can see in the
Special Considerations section, we're looking for a solution that acts
like a model repository, which provides capabilities borrowed from source
code repositories; imagine add, check out, update and commit operations
for models, as well as conflict resolution. Could you suggests us
something to use here?

We'd love to get your advice on this issue as well as your input on the
general IM Builder idea. Your help will not only benefit us at the IM
Component, but the whole STP top-level project as well, since its
increasing popularity is demanding more integration between all these SOA
editors.

PD. I hope this is the right place to post this, as we're using as well as
considering more than one tool that falls under the Modeling Project
umbrella.

Thanks a lot!

-Juan Cadavid
Re: Advice for Modeling Technologies at Eclipse STP [message #383239 is a reply to message #383232] Sat, 20 September 2008 23:35 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26287
Registered: July 2009
Senior Member
Juan,

Comments below.

Juan Cadavid wrote:
> Hello Modeling Project Team,
>
> My name is Juan Cadavid and I participated in Google Summer of Code
> working on the Eclipse STP project under the supervision of Adrian
> Mos, in the Intermediate Model component. As some of you might know,
> the goal of this component is to serve as "a «bridge» between STP
> editors; its elements have the role of conceptual transport between
> different development spaces with the purpose of capturing as much
> common SOA design information as possible". You can find more
> information here:
>
> http://wiki.eclipse.org/STP/IM_Component/STP_Intermediate_Me tamodel
Your diagram would be so much more readable, if it were made more
visually compact. The classes are all far more widely spaced than
necessary and it would be much nicer to be able to see the whole diagram
at once without scrolling.

Some of this work on an intermediate model is similar to what Thiago was
trying to achieve with Servus. It seems like a good approach.
>
> As you can imagine, this goal is strongly leveraged by modeling
> technologies, and at this point we'd like to request your advice. In
> order to fulfill this goal, work around the IM component has been
> centered in writing model transformations between the different STP
> model editors and the IM, whether using the Java EMF-generated APIs or
> ATL. Basically, the user chooses explicitly when he wants to transform
> his user model into an IM instance, and from that point into other
> types of models supported by STP.
Are you imagining the transformations being two way so this model acts
sort of like a translation hub?
>
> However, this approach falls short into delivering the full-fledged
> integration we aim to achieve. Therefore we started conceiving the
> idea of an STP-IM Model Builder, which would automatically update a
> centralized, core instance of the Intermediate Model, containing all
> the conceptual elements defined across all the models contained in a
> project. Please take a moment to take a look at this idea at:
>
> http://wiki.eclipse.org/STP/IM_Component/IM_Builder
I see. Reading this kind of answers the other question...
>
> The main issue we're facing right now is choosing the
> technology/approach for the second phase. There you can see the ones
> we have considered/tried, but we haven't found the one to convince us
> yet. As you can see in the Special Considerations section, we're
> looking for a solution that acts like a model repository, which
> provides capabilities borrowed from source code repositories; imagine
> add, check out, update and commit operations for models, as well as
> conflict resolution. Could you suggests us something to use here?
I can see it's quite a difficult problem because you really want to
reconcile the new state with the existing state. In some ways this
problem is a little bit similar to the GenModel processing. In this
case, we effectively decorate an Ecore more with a GenModel and then
when the Ecore model changes, we need to update the GenModel without
losing all the user's settings. We implement this using two
approaches. One is a two way reconcile within the model's code. In
this case, we create a whole new GenModel and then we tell the new
GenModel, to reconcile against the old GenModel. It does matching of
corresponding structures and copies the old settings over. The one way
reconcile happens if the Ecore that the GenModel wraps is directly
modified. It effectively has to make sure that each Ecore thing has a
decorator and that things that have disappeared from Ecore are pruned
away...

This type of approach of building a whole new Core IM instance and
reconciling it against the old one might be effective, but you have a
feedback cycle back to the original models that isn't entirely clear to
me. I'm sure that in this cycle lies some tough details that aren't
entirely clear to me...
>
> We'd love to get your advice on this issue as well as your input on
> the general IM Builder idea. Your help will not only benefit us at the
> IM Component, but the whole STP top-level project as well, since its
> increasing popularity is demanding more integration between all these
> SOA editors.
You might want to hang out on #eclipse-modeling and chat about your
design issues. Folks like Cedric who works on compare hangs out and so
does Eike when I nag him; I won't be there until Tuesday because I
travel back from Vancouver on Monday...
>
> PD. I hope this is the right place to post this, as we're using as
> well as considering more than one tool that falls under the Modeling
> Project umbrella.
So few postings to this newsgroup are appropriate, but this certainly is.
>
> Thanks a lot!
>
> -Juan Cadavid
>
Re: Advice for Modeling Technologies at Eclipse STP [message #383547 is a reply to message #383239] Thu, 02 October 2008 20:05 Go to previous message
Juan Cadavid is currently offline Juan CadavidFriend
Messages: 49
Registered: July 2009
Location: Rennes, France
Member

Ed,

Thank you so much for your help! I've been looking at the Genmodel
processing and indeed I see there is no standard way to do this model
reconciliation as there are many different things to consider in any case.

As you can see, we're slowly working on this but we'll come over to the
chat this discuss these design issues.

Thanks again!

-Juan
Re: Advice for Modeling Technologies at Eclipse STP [message #611017 is a reply to message #383232] Sat, 20 September 2008 23:35 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26287
Registered: July 2009
Senior Member
Juan,

Comments below.

Juan Cadavid wrote:
> Hello Modeling Project Team,
>
> My name is Juan Cadavid and I participated in Google Summer of Code
> working on the Eclipse STP project under the supervision of Adrian
> Mos, in the Intermediate Model component. As some of you might know,
> the goal of this component is to serve as "a «bridge» between STP
> editors; its elements have the role of conceptual transport between
> different development spaces with the purpose of capturing as much
> common SOA design information as possible". You can find more
> information here:
>
> http://wiki.eclipse.org/STP/IM_Component/STP_Intermediate_Me tamodel
Your diagram would be so much more readable, if it were made more
visually compact. The classes are all far more widely spaced than
necessary and it would be much nicer to be able to see the whole diagram
at once without scrolling.

Some of this work on an intermediate model is similar to what Thiago was
trying to achieve with Servus. It seems like a good approach.
>
> As you can imagine, this goal is strongly leveraged by modeling
> technologies, and at this point we'd like to request your advice. In
> order to fulfill this goal, work around the IM component has been
> centered in writing model transformations between the different STP
> model editors and the IM, whether using the Java EMF-generated APIs or
> ATL. Basically, the user chooses explicitly when he wants to transform
> his user model into an IM instance, and from that point into other
> types of models supported by STP.
Are you imagining the transformations being two way so this model acts
sort of like a translation hub?
>
> However, this approach falls short into delivering the full-fledged
> integration we aim to achieve. Therefore we started conceiving the
> idea of an STP-IM Model Builder, which would automatically update a
> centralized, core instance of the Intermediate Model, containing all
> the conceptual elements defined across all the models contained in a
> project. Please take a moment to take a look at this idea at:
>
> http://wiki.eclipse.org/STP/IM_Component/IM_Builder
I see. Reading this kind of answers the other question...
>
> The main issue we're facing right now is choosing the
> technology/approach for the second phase. There you can see the ones
> we have considered/tried, but we haven't found the one to convince us
> yet. As you can see in the Special Considerations section, we're
> looking for a solution that acts like a model repository, which
> provides capabilities borrowed from source code repositories; imagine
> add, check out, update and commit operations for models, as well as
> conflict resolution. Could you suggests us something to use here?
I can see it's quite a difficult problem because you really want to
reconcile the new state with the existing state. In some ways this
problem is a little bit similar to the GenModel processing. In this
case, we effectively decorate an Ecore more with a GenModel and then
when the Ecore model changes, we need to update the GenModel without
losing all the user's settings. We implement this using two
approaches. One is a two way reconcile within the model's code. In
this case, we create a whole new GenModel and then we tell the new
GenModel, to reconcile against the old GenModel. It does matching of
corresponding structures and copies the old settings over. The one way
reconcile happens if the Ecore that the GenModel wraps is directly
modified. It effectively has to make sure that each Ecore thing has a
decorator and that things that have disappeared from Ecore are pruned
away...

This type of approach of building a whole new Core IM instance and
reconciling it against the old one might be effective, but you have a
feedback cycle back to the original models that isn't entirely clear to
me. I'm sure that in this cycle lies some tough details that aren't
entirely clear to me...
>
> We'd love to get your advice on this issue as well as your input on
> the general IM Builder idea. Your help will not only benefit us at the
> IM Component, but the whole STP top-level project as well, since its
> increasing popularity is demanding more integration between all these
> SOA editors.
You might want to hang out on #eclipse-modeling and chat about your
design issues. Folks like Cedric who works on compare hangs out and so
does Eike when I nag him; I won't be there until Tuesday because I
travel back from Vancouver on Monday...
>
> PD. I hope this is the right place to post this, as we're using as
> well as considering more than one tool that falls under the Modeling
> Project umbrella.
So few postings to this newsgroup are appropriate, but this certainly is.
>
> Thanks a lot!
>
> -Juan Cadavid
>
Re: Advice for Modeling Technologies at Eclipse STP [message #613572 is a reply to message #383239] Thu, 02 October 2008 20:05 Go to previous message
Juan Cadavid is currently offline Juan CadavidFriend
Messages: 5
Registered: July 2009
Junior Member
Ed,

Thank you so much for your help! I've been looking at the Genmodel
processing and indeed I see there is no standard way to do this model
reconciliation as there are many different things to consider in any case.

As you can see, we're slowly working on this but we'll come over to the
chat this discuss these design issues.

Thanks again!

-Juan
Previous Topic:.java to class diagram
Next Topic:Eclipse modeling trainings
Goto Forum:
  


Current Time: Mon Dec 22 02:09:24 GMT 2014

Powered by FUDForum. Page generated in 0.01738 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software