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