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

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

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
>>
>