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