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

["Tobias Jähnel" <tjaehnel@xxxxxxxxx>]

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
>