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

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

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