[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emft-dev] Contribution to EMF-Compare as a Master's Thesis
|
Hi Cédric,
thank you for your suggestions.
In fact the first one is the most interesting for me, so I decided to
go into this topic.
I sent an e-mail to my professor to ask him if this is an option, but
I haven't got a response yet. Though I don't think there will be any
problems.
Unfortunately I cannot come into IRC. All IM protocols, including IRC,
seem to be blocked by the proxy of the company (only ICQ is working).
Could you go a bit deeper into what you expect?
When you write "... and integration in graphical modelers", do you
think of any concrete graphical modelers available?
I think there should be an easy way to integrate with any modeler.
Toby
On Thu, Apr 10, 2008 at 7:02 PM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
> Hi Tobias,
>
> Any kind of contribution is obviously welcome!
>
> It really depend on your own interests but here are the challenges I can think
> of (both intellectualy and practically interesting) :
>
> * Differences representation and integration in graphical modelers : this one
> is tricky in the sense that we did not figured out yet what is the best
> representation of differences for the end user. That's part of the reason why
> we define many API so that other plugins may refactor the way differences are
> kept and displayed. The user quickly ends up with many differences and the
> classical hierarchical way of representing models doesn't fit with the user
> expectations, there's obviously room for improvements.
>
> Correlated to this subject is "how we can visualize differences in a graphical
> modeler", it's not a technical concern as it doesn't seems like GMF is a
> blocker for that, it's more, there again, about what we need to display,
> where, and how, to help the user manage the model evolutions.
>
> The Ecore Tools guys want to integrate emf compare in the Ecore modeler, this
> could be a nice testbed for ideas concerning the graphical representations.
>
>
> * Huge models management : the current implementation of the
> GenericMatchEngine is not able to handle huge models, (by huge models I mean
> more than 1GB ones) because the principles and algorithms are just not rights
> for such data. Another interesting subject could be to provides an
> alternative match engines for such models.
>
> That's two subjects I can think of but of course it's up to you, just to let
> you know on the "research" side we'll work in the following month with the
> Aquila University (Italy) on a model representation of the differences
> (models changeset/patch) providing the same features as the textual patch
> format (with fuzzy searchs and stuffs like that) but all the other areas are
> opened for experimentation :)
>
> In a nutshell, the first subject I described seems to fit quite nicely with
> your "part 2", the second one is just another area in which we know we have
> some progress to do but whatever you want to focus on we would gladly help
> you !
>
> You can use this mailling-list or come on the #eclipse-modeling IRC chan for
> live discussions, Laurent is "Kellindil" there and I'm "Tortoose".
>
> Cheers,
>
> Cédric
>
>
> Le Thursday 10 April 2008 11:05:54 Tobias Jähnel, vous avez écrit :
>
>
> > EMF Compare developers,
> >
> > I am Tobias Jaehnel, student of Computer Science in Nuremberg, Germany.
> >
> > I'm going to start my Master's Thesis and I'm interested in
> > contributing to the EMF-Compare project.
> >
> > Background:
> > The topic I have chosen for my thesis it based on a state-chart
> > editor, which uses EMF and GEF. This editor has been developed in the
> > company I'm working for, for very particular needs. My thesis should
> > be divided into two parts.
> >
> > Part 1: Design and Implementation of an algorithm to find the
> > differences between two state charts
> > Part 2: Visualizing the differences in one or two ways, which are
> > convenient for the user
> >
> > After some research I found EMF Compare, which fits our requirements
> > and entirely covers Part 1.
> > Since I do not want to reinvent the wheel but are still very
> > interested in this topic, I'm looking for some other challenge now.
> >
> > Can you think of a component or topic I could develop for you?
> > I actually want to keep Part 2, but I would appreciate it, if I could
> > make a contribution to EMF Compare in addition.
> >
> > Thanks in advance.
> >
> > Regards,
> > Toby
> > _______________________________________________
> > emft-dev mailing list
> > emft-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/emft-dev
>
>
> _______________________________________________
> emft-dev mailing list
> emft-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emft-dev
>
