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

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

Hi all,

for convenience this discussion will now continue in the  Eclipse bugzilla, if 
you are interested in you can follow it there :

https://bugs.eclipse.org/bugs/show_bug.cgi?id=241385

Cédric

On Tuesday 15 July 2008 15:06:22 Tobias Jähnel wrote:
> Hi,
>
> I didn't know about the sub-model capability. I think we should not do
> everyting "at once", since my thesis time is limited. I suggest at
> first not caring too much about sub-models, but adding this feature
> later.
>
> Toby
>
> On Tue, Jul 15, 2008 at 1:23 PM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
> > My answers are inline ..
> >
> >> it's great that my prototype works.
> >> As for namespaces and stuff, I've no idea about coding style and
> >> namespace guidelines in eclipse projects. But I think that's one thing
> >> easy to change.
> >
> > Yep, we'll consider that when merging the final contribution :)
> >
> >> I think merging should work the same way as in the text-compare and
> >> the EMF-Compare GUI.
> >> I actually tried to get away this ContentMergeViewer at the bottom to
> >> only show the merged diagram indicating the changes. But I like the
> >> idea to display both models at the bottom instead. I just suspect,
> >> that this design would take too much space and the user has to do very
> >> much scrolling.
> >
> > I agree, models at the bottom would be better imho.
> >
> >> I'm not sure what you mean with multiple models in one file. I haven't
> >> seen files with more than one notation model. I know, that one
> >> notation model could reference elements from more than one business
> >> model, but there is no reason to switch.
> >
> > Yes it's possible to get more than one notation model in a given
> > resource, it happens when your modeler is designed with sub-diagraming
> > (ou double click an element and then a sub diagram gets created. As it's
> > supported by GMF I think we should handle it and then provide a way for
> > the user to consider one diagram or the other.
> >
> > At some point the user will probably need the common interaction he has
> > with diagrams like zooming, or may be searching. That's also something to
> > keep in mind.
> >
> > Cédric
> >
> >> Toby
> >>
> >> On Tue, Jul 15, 2008 at 9:53 AM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
> >> > Hi Tobias,
> >> >
> >> > I checked your prototype, it seems to work quite nicely already, I
> >> > think that's a nice start and it proves this kind of usage for GMF is
> >> > possible. I won't speak about namespaces and stuffs like that in the
> >> > java code, I'll keep consider this as a proof of concept ;)
> >> >
> >> > Anyway, what kind of user interaction were you considering,diagram at
> >> > the top, and then list of differences at the bottom ? On proprietary
> >> > tools you often get two diagrams at the bottom (both versions) and
> >> > specific markers to show "see ! this element is missing". How is the
> >> > user supposed to merge ?
> >> > Please keep in mind that you can quite easily get more than one
> >> > diagram in a single file now with GMF. As Such the user should be able
> >> > to switch diagram or pick the good one.
> >> >
> >> > Cédric
> >> >
> >> > On Friday 11 July 2008 08:48:38 Tobias Jähnel wrote:
> >> >> Hi Cédric,
> >> >>
> >> >> I'm sorry I'm a bit late. I wanted to answer you last week, but there
> >> >> were more problems in implementation and I had less time than I
> >> >> expected.
> >> >>
> >> >> Now I've finished a first prototype to show you my ideas.
> >> >> You can find it here: http://www.jonmedia.net/GraphicalEMFCompare.zip
> >> >>
> >> >> I simply exported the projects from Eclipse, so please import them
> >> >> into a workspace. I've only tested it with Ganymede.
> >> >> Beside the compare PlugIn you find a GMF editor for the shapes
> >> >> Example (Examples->My Diagram in New file wizard). Use only this
> >> >> editor, because by now I can only compare models, where the business
> >> >> model and the notation model are in the same file.
> >> >> Also, only use the "Compare to local History" item to start the
> >> >> compare viewer, because I haven't implemented/tested other methods
> >> >> yet.
> >> >>
> >> >> If something is not working please let me know. You can also talk to
> >> >> me on IRC (jfbtoby) or Jabber (my E-Mail Address).
> >> >> I'm looking forward to getting feedback from you.
> >> >>
> >> >> Toby
> >> >>
> >> >> On Fri, Jun 27, 2008 at 4:02 PM, Cédric Brun <cedric.brun@xxxxxxx> 
wrote:
> >> >> > 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
> >> >> >
> >> >> > _______________________________________________
> >> >> > 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
>
> _______________________________________________
> emft-dev mailing list
> emft-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emft-dev