Re: [emft-dev] Contribution to EMF-Compare as a Master's Thesis

[Cédric Brun <cedric.brun@xxxxxxx>]

Hi Tobias,

This looks great to me,  the GMF team could probably provide some input about 
the design you provided and confirm this is a good solution.

Cheers,

Cédric 


On Thursday 19 June 2008 15:52:07 Tobias Jähnel wrote:
> Hi Cédric,
>
> as promised I send my design ideas for discussion now.
> Please read through it and tell me what you think about it.
> I'm not sure if everything is practicable as I think but I'm open to
> improvements and other ideas.
>
> I'm sure, that details will change while development, but I want to
> have a concrete direction, so that I can start coding next monday if
> possible.
>
> I didn't want to send attachments over the list, so I uploaded it.
> Here it is: http://www.jonmedia.net/DesignApproach.pdf
>
> Toby
>
> On Fri, Jun 13, 2008 at 12:11 PM, Tobias Jähnel <tjaehnel@xxxxxxxxx> wrote:
> > Hi Cédric,
> >
> > there is not so much to "see", yet. :)
> > I will try to send you design concepts next week.
> >
> > As regards the Documentation: I am able to use the EMF-Compare API and
> > understand most of what goes on.
> > Though a documentation of the Meta-Models would be very helpful, since
> > this is where the graphical representation must be based on.
> > Oherwise I have to try out myself how changes in the models are
> > reflected in the match- and diffmodel. If there is already some
> > partial documentation, perhaps you could send it to me.
> >
> > Thanks
> > Toby
> >
> > On Thu, Jun 12, 2008 at 1:51 PM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
> >> Hi Tobias,
> >>
> >> I'm eager to see a bit more about what you've done so far :)
> >>
> >> The EMF Compare RC4 bits contains more documentation, a quick overview
> >> of the architecture and developer information about re-using the EMF 
> >> Compare services.
> >> If you need more documentation on a specific point (like describing the
> >> metamodels) we can try to emphasize our work on these points, so please
> >> tell us.
> >>
> >> Cheers,
> >>
> >> Cédric
> >>
> >> On Thursday 12 June 2008 13:28:42 Tobias Jähnel wrote:
> >>> Hi,
> >>>
> >>> I just want to give you an update on my current work.
> >>>
> >>> It took me very much time to get into the details of EMF/GEF/GMF,
> >>> which are interesing for me. (What are EditParts, Figures, Viewers,
> >>> what do they do, which Factory is used by whom etc.) Now I've
> >>> (finally) managed displaying two graphs side-by-side when I use the
> >>> "Compare to..." action in Eclipse. The graphs looks the same as they
> >>> look in the GMF-editor.
> >>>
> >>> At the moment I'm going into depth of EMF compare. Is there really no
> >>> documentation? I couldn't find any UML-charts or documentation other
> >>> then the javadoc (almost same with GMF). By now a have a rough
> >>> overview of how things work together, but there are still many things
> >>> I'm not sure about. Examples are the diffmodel and the matchmodel.
> >>> Some elements are quite self explaining, but many are not (for me).
> >>>
> >>> I already have some specific design-approaches in mind, but I will
> >>> make them more concrete before I present them to you for discussion.
> >>>
> >>> Toby
> >>>
> >>> On Wed, Apr 30, 2008 at 1:57 PM, Cédric Brun <cedric.brun@xxxxxxx> 
wrote:
> >>> > Hi Tobias and Jan,
> >>> >
> >>> > Many issues you are refering to here are already tackled by the EMF
> >>> > Compare component itselft, model merging and differencing can be
> >>> > specialized for a given metamodel and a generic implementation is
> >>> > provided which fits nicely with human understandable metamodels (aka
> >>> > not UML  ;) ) . Every aspect link to the merging, elements UUID or
> >>> > Ecore Id's, is the responsability of the compare service we provides.
> >>> >
> >>> > Tobias's work seems more focused on the graphical representation of
> >>> > these diffs once EMF compare gave him the diff model. My opinion is
> >>> > that the integration with the graphical modeler should not impact
> >>> > it's code. GMF/GEF brings many way to dynamically extends the modeler
> >>> > graphical aspects or behavior through the editpart and edit policies
> >>> > providers.
> >>> >
> >>> > I agree the decorator service will not fit to address the needs here.
> >>> > May be you should start by developping a prototype for a given
> >>> > graphical modeler (the one from Ecore tools for instance ) in a
> >>> > specific plugin and see how far you can go corresponding to what you
> >>> > want to achieve.
> >>> >
> >>> > Cédric
> >>> >
> >>> > Le Wednesday 30 April 2008 12:49:16 Jan Köhnlein, vous avez écrit :
> >>> >> Hi Tobias
> >>> >>
> >>> >> nice idea, I've been thinking about doing something similar but
> >>> >> never really found the time.
> >>> >>
> >>> >> Just some thoughts from my side.
> >>> >> Theoretical issues:
> >>> >> * It's a common understanding that model merging (and therby
> >>> >> diffing) is something domain (metamodel) specific, e.g. it depends a
> >>> >> lot on the concrete syntax. It is likely you won't satisfy everyone
> >>> >> with your solution.
> >>> >> * Note that most UML2 tools only provide poor solutions for model
> >>> >> diff/ merge. I don't want to say it's impossible, but there doesn't
> >>> >> seem to be an easy solution especially for the generic case. Maybe
> >>> >> you have to restrict it to (some) explicit scenarios.
> >>> >> * Diagrams only show parts of a semantic model. How do you deal with
> >>> >> the invisible diffs?
> >>> >> * A diff might need a different metamodel, e.g. changed
> >>> >> multiplicities * What kind of differences do you want to show wrt.
> >>> >> ecore?
> >>> >>
> >>> >> Technical issues:
> >>> >> * One of the major problems is how to get two models aligned.
> >>> >>    * Consider using UUIDs for the model elements
> >>> >>    * One idea was to preprocess the two models and merge them into
> >>> >> one with annotated elements. This should have less impact on the
> >>> >> generated GMF code.
> >>> >>    * Maybe it's easier to override the "getSemanticChildren" methods
> >>> >> of specific EditParts to return elements from both models.
> >>> >> * Don't wrap the EditParts but add additional EditPolicies that
> >>> >> change properties of the shapes. This is far more GMF/GEF like.
> >>> >>
> >>> >> Good luck
> >>> >> Jan
> >>> >>
> >>> >> Am 30.04.2008 um 11:33 schrieb Tobias Jähnel:
> >>> >> > Hi,
> >>> >> >
> >>> >> > fist of all I don't know if this list is the right place for
> >>> >> > discussing my concepts. If not, please point me to the right
> >>> >> > place.
> >>> >> >
> >>> >> > What do I want to do in my Master's Thesis?
> >>> >> > Create a diff viewer for EMF models using EMF compare, which goes
> >>> >> > beyond the current tree structure.
> >>> >> > This actually means displaying the model with edges and nodes
> >>> >> > using draw2d figures.
> >>> >> > Since the EMF model itself does not contain any information about
> >>> >> > the graphical representation,
> >>> >> > ideally any editor which is created or will be created using GMF,
> >>> >> > should be able to serve as the base.
> >>> >> >
> >>> >> > Goals would be as follows:
> >>> >> > 1 make use of any GMF editor to draw shapes and modify them
> >>> >> >  (e.g. dotted lines, various colors) to show deleted, added and
> >>> >> >   modified nodes/connections in a convenient way.
> >>> >> > 2 enable the creator of the GMF editor to override those defaults
> >>> >> >  and define how deleted/added/edited nodes and connections should
> >>> >> > look
> >>> >> >
> >>> >> > I think this might be too much work for my Thesis, because there
> >>> >> > is more than this to do.
> >>> >> > But I can definitely do parts of it.
> >>> >> >
> >>> >> > After some weeks of getting familiar with EMF, GMF and GEF, my
> >>> >> > idea to achieve
> >>> >> > this is as follows:
> >>> >> > - Use the EditPartFactory, which has been registered for the
> >>> >> > editor, to fetch the EditParts
> >>> >> > - Wrap my own EditParts around the original EditParts (decorator
> >>> >> > pattern)
> >>> >> >  I can now change the original look of the shapes.
> >>> >> > - For Goal 2 a new extension point can be introduced. I haven't
> >>> >> > thought so much
> >>> >> >  about this yet, because it should not be the big problem
> >>> >> >
> >>> >> > The reason I chose not using the decorator approach of GMF
> >>> >> > (DecoratorProvider) is, that it does
> >>> >> > probably not fit the requirements. The documentation says, that it
> >>> >> > is inteded to decorate the shapes by
> >>> >> > drawing something like an overlay on top of the shape. But I want
> >>> >> > to change the look of the shape
> >>> >> > itself. I read somewhere on the net, that it is possible to fetch
> >>> >> > the edit part from the decorator and
> >>> >> > modify the figures directly. If this is right, it would probably
> >>> >> > be a better approach than mine.
> >>> >> >
> >>> >> >
> >>> >> > Thank you for your attention. :)
> >>> >> >
> >>> >> > Please tell me what you think about my ideas. Please also tell me
> >>> >> > if this is not practible, conflicts
> >>> >> > the design of GMF etc., this is not what you need or you don't
> >>> >> > like it for any other reason.
> >>> >> > Any suggestions are welcome because I'm new to EMF, GEF and GMF.
> >>> >> > :)
> >>> >> >
> >>> >> > Toby
> >>> >> >
> >>> >> > PS.: I've found a way to come into IRC at work now. If it's easier
> >>> >> > to discuss things directly rather than email, my name is "jfbtoby"
> >>> >> > there.
> >>> >> >
> >>> >> > On Wed, Apr 16, 2008 at 1:36 PM, Tobias Jähnel
> >>> >> > <tjaehnel@xxxxxxxxx>
> >>> >> >
> >>> >> > wrote:
> >>> >> >> 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
> >>> >> >
> >>> >> > _______________________________________________
> >>> >> > emft-dev mailing list
> >>> >> > emft-dev@xxxxxxxxxxx
> >>> >> > https://dev.eclipse.org/mailman/listinfo/emft-dev
> >>> >>
> >>> >> --
> >>> >> Dr. Jan Köhnlein
> >>> >> Senior Software Architekt
> >>> >>
> >>> >> Telefon: +49 (0) 431 / 5606-337
> >>> >> Telefax: +49 (0) 431 / 5606-339
> >>> >>
> >>> >> http://www.itemis.de
> >>> >> jan.koehnlein@xxxxxxxxx
> >>> >>
> >>> >> itemis AG
> >>> >> Schauenburgerstr. 116
> >>> >> 24118 Kiel
> >>> >>
> >>> >> Rechtlicher Hinweis:
> >>> >>
> >>> >> Amtsgericht Dortmund, HRB 20621
> >>> >>
> >>> >> Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
> >>> >>
> >>> >> Aufsichtsrat: Prof. Dr. Burkhart Igel (Vors.) Stephan Grollmann,
> >>> >> Michael Neuhaus
> >>> >>
> >>> >>
> >>> >> _______________________________________________
> >>> >> 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
> >>>
> >>> _______________________________________________
> >>> 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
>
> _______________________________________________
> emft-dev mailing list
> emft-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emft-dev