Home » Modeling » GMF (Graphical Modeling Framework) » links aren't drawn correctly
| links aren't drawn correctly [message #211539] |
Wed, 19 November 2008 11:49  |
Eclipse User |
|
|
|
Hello,
I have some figures of different types and I like to connect them with
one ConnectionLine. I read in other posts it is possible. I create pairs
of sources and targets for each figure in link element, something like
this:
link{
sourceNode1:Node1Type;
targetNode1:Node1Type;
sourceNode2:Node2Type;
targetNode2:Node2Type;
sourceNode3:Node3Type;
targetNode3:Node3Type;
}
And I create pairs of LinkMappings, like this:
linkMapping{
source:link.sourceNode1;
target:link.targetNode2;
}
linkMapping{
source:link.sourceNode1;
target:link.targetNode3;
}
linkMapping{
source:link.sourceNode2;
target:link.targetNode3;
}
linkMapping{
source:link.sourceNode2;
target:link.targetNode1;
}
and so on.
For each mapping I specify the same tool creation and diagram link.
When I try to create link all works good for first link mapping, but for
others only record in model file is created but graphical line isn't
drawn. In *CanonicalEditPolicy I see that linkDescriptors containes all
created links but in domain2NotationMap only one - for first mapping,
because in model only one link loaded correctly, others doesn't contain
source or target. Why it happens?
|
|
| | |
| Re: links aren't drawn correctly [message #222081 is a reply to message #211539] |
Fri, 20 March 2009 09:03  |
| Eclipse User |
|
|
|
Originally posted by: stevek.metacase.com
The root problem is simply that GMF uses EMF's Ecore concepts for describing
the modeling languages. Those concepts aren't enough to describe common
situations nicely - like in the case you describe. This problem was proved
over 20 years ago, along with the fact that even type inheritance is no real
solution: see sections 3.5.2 and 4.4 in the article here:
http://www.dsmforum.org/papers/CASE_Repository.html.
To be able to nicely describe connections that can occur between sets of
object types, you need a better set of concepts, like the OPRR described in
that article. With OPRR, you'd just say your connection can be from
{NodeType1, NodeType2 or NodeType3} to {NodeType1, NodeType2 or NodeType3}
(or whatever other rule you want).
Maybe the committers can tell us if there are any plans to improve GMF to
start using more powerful concepts, as other tools have successfully been
doing for decades?
All the best,
Steve
--
Steven Kelly, CTO, MetaCase
www.metacase.com/blogs/stevek
"Alexandr Zaitsev" <zaicev.alex@gmail.com> wrote in message
news:7474ff96a760c180b11ab52685b11d3b$1@www.eclipse.org...
> Hello,
>
> I have some figures of different types and I like to connect them with one
> ConnectionLine. I read in other posts it is possible. I create pairs of
> sources and targets for each figure in link element, something like this:
> link{
> sourceNode1:Node1Type;
> targetNode1:Node1Type;
> sourceNode2:Node2Type;
> targetNode2:Node2Type;
> sourceNode3:Node3Type;
> targetNode3:Node3Type;
> }
> And I create pairs of LinkMappings, like this:
> linkMapping{
> source:link.sourceNode1;
> target:link.targetNode2;
> }
> linkMapping{
> source:link.sourceNode1;
> target:link.targetNode3;
> }
> linkMapping{
> source:link.sourceNode2;
> target:link.targetNode3;
> }
> linkMapping{
> source:link.sourceNode2;
> target:link.targetNode1;
> }
> and so on.
> For each mapping I specify the same tool creation and diagram link.
> When I try to create link all works good for first link mapping, but for
> others only record in model file is created but graphical line isn't
> drawn. In *CanonicalEditPolicy I see that linkDescriptors containes all
> created links but in domain2NotationMap only one - for first mapping,
> because in model only one link loaded correctly, others doesn't contain
> source or target. Why it happens?
>
|
|
|
| Re: links aren't drawn correctly [message #222102 is a reply to message #222081] |
Fri, 20 March 2009 10:57 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------040503020100040300070705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Steve,
Given that one of the biggest complaints directed at modeling is that
it's complex, the premise that generally a more complex formalism is
needed is a little frightening. I suppose everyone should abandon
EMOF/Ecore along with the whole OMG specification stack based on it and
use something else. I wonder what? Do you have any more specific
suggestions? :-P
It's often possible to build up more complex things from simpler things:
< http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html>
http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html
Still, you do end up with more complex things as a result, and of course
the Java API to deal with it reflects that complexity...
Steven Kelly wrote:
> The root problem is simply that GMF uses EMF's Ecore concepts for describing
> the modeling languages. Those concepts aren't enough to describe common
> situations nicely - like in the case you describe. This problem was proved
> over 20 years ago, along with the fact that even type inheritance is no real
> solution: see sections 3.5.2 and 4.4 in the article here:
> http://www.dsmforum.org/papers/CASE_Repository.html.
>
> To be able to nicely describe connections that can occur between sets of
> object types, you need a better set of concepts, like the OPRR described in
> that article. With OPRR, you'd just say your connection can be from
> {NodeType1, NodeType2 or NodeType3} to {NodeType1, NodeType2 or NodeType3}
> (or whatever other rule you want).
>
> Maybe the committers can tell us if there are any plans to improve GMF to
> start using more powerful concepts, as other tools have successfully been
> doing for decades?
>
> All the best,
> Steve
>
--------------040503020100040300070705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Steve,<br>
<br>
Given that one of the biggest complaints directed at modeling is that
it's complex, the premise that generally a more complex formalism is
needed is a little frightening. I suppose everyone should abandon
EMOF/Ecore along with the whole OMG specification stack based on it and
use something else. I wonder what? Do you have any more specific
suggestions? :-P<br>
<br>
It's often possible to build up more complex things from simpler things:<a
href=" http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html"><br>
</a>
<blockquote><a
href=" http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html"> http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html</a><br>
</blockquote>
Still, you do end up with more complex things as a result, and of
course the Java API to deal with it reflects that complexity...<br>
<br>
<br>
Steven Kelly wrote:
<blockquote cite="mid:gq046f$ap2$1@build.eclipse.org" type="cite">
<pre wrap="">The root problem is simply that GMF uses EMF's Ecore concepts for describing
the modeling languages. Those concepts aren't enough to describe common
situations nicely - like in the case you describe. This problem was proved
over 20 years ago, along with the fact that even type inheritance is no real
solution: see sections 3.5.2 and 4.4 in the article here:
<a class="moz-txt-link-freetext" href="http://www.dsmforum.org/papers/CASE_Repository.html">http://www.dsmforum.org/papers/CASE_Repository.html</a>.
To be able to nicely describe connections that can occur between sets of
object types, you need a better set of concepts, like the OPRR described in
that article. With OPRR, you'd just say your connection can be from
{NodeType1, NodeType2 or NodeType3} to {NodeType1, NodeType2 or NodeType3}
(or whatever other rule you want).
Maybe the committers can tell us if there are any plans to improve GMF to
start using more powerful concepts, as other tools have successfully been
doing for decades?
All the best,
Steve
</pre>
</blockquote>
</body>
</html>
--------------040503020100040300070705--
|
|
|
| Re: links aren't drawn correctly [message #222139 is a reply to message #222102] |
Fri, 20 March 2009 18:04 |
| Eclipse User |
|
|
|
Originally posted by: stevek.metacase.com
Ed,
I have no problem with EMF: the Ecore concepts are great if what you want is
a tree view and property sheets. My question (and that faced by the original
poster) was about why graphical modeling should use a set of concepts
designed for something different. The "right" set of concepts depends on
what you want to use them for: too many concepts can make something overly
complex, but equally having too few concepts can make something complex.
The original poster just wants to have three node types and one connection
type, and ends up having to create 9 connection types and cobble them back
together to achieve this (although some GMF bug prevented that). To me, that
sounds unnecessarily complex.
In your blog post below, you just want two object types and one connection
type (that isn't owned by either object type). To achieve that you need 35
elements in your metamodel. Again, to me that sounds unnecessarily complex.
Richard Welke's work in the article I referred to pointed out just these
kinds of problems over 20 years ago. His OPRR - Object, Property,
Relationship and Role - provides a "minimal appropriate" set of concepts
designed from the ground up for graphical modeling tools. GMF already has to
add information to the EMF model, e.g. to distinguish whether an EClass is a
node or a line. My thought was that maybe by promoting that kind of
information to a first class citizen, GMF would be able to handle the
original case and the case from your blog more easily.
With OPRR, there would be 5 elements for the metamodel from your blog, not
35. Conversely, for the simplest possible case of a directed relationship
between two objects in an EMF tree view, EMF could make do with 3, but OPRR
would still use 5. In other words, my message isn't to you or the others on
the EMF team - your set of concepts is right for what you use it for - but
to those on the GMF team, for whom the lack of more explicit relationship
concepts seems to be causing problems.
And to both EMF and GMF teams: I think it's great the way you tirelessly
answer users' questions in these newsgroups! Keep up the good work.
All the best,
Steve
"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:gq0at6$a8q$1@build.eclipse.org...
Steve,
Given that one of the biggest complaints directed at modeling is that it's
complex, the premise that generally a more complex formalism is needed is a
little frightening. I suppose everyone should abandon EMOF/Ecore along with
the whole OMG specification stack based on it and use something else. I
wonder what? Do you have any more specific suggestions? :-P
It's often possible to build up more complex things from simpler things:
http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html
Still, you do end up with more complex things as a result, and of course the
Java API to deal with it reflects that complexity...
Steven Kelly wrote:
The root problem is simply that GMF uses EMF's Ecore concepts for describing
the modeling languages. Those concepts aren't enough to describe common
situations nicely - like in the case you describe. This problem was proved
over 20 years ago, along with the fact that even type inheritance is no real
solution: see sections 3.5.2 and 4.4 in the article here:
http://www.dsmforum.org/papers/CASE_Repository.html.
To be able to nicely describe connections that can occur between sets of
object types, you need a better set of concepts, like the OPRR described in
that article. With OPRR, you'd just say your connection can be from
{NodeType1, NodeType2 or NodeType3} to {NodeType1, NodeType2 or NodeType3}
(or whatever other rule you want).
Maybe the committers can tell us if there are any plans to improve GMF to
start using more powerful concepts, as other tools have successfully been
doing for decades?
All the best,
Steve
|
|
|
| Re: links aren't drawn correctly [message #222153 is a reply to message #222139] |
Fri, 20 March 2009 19:31 |
| Eclipse User |
|
|
|
Steve,
Comments below.
Steven Kelly wrote:
> Ed,
>
> I have no problem with EMF: the Ecore concepts are great if what you want is
> a tree view and property sheets.
You're commingling Ecore with EMF.Edit. A tree view with property
sheets is a trivial manifestation of an EMF model....
> My question (and that faced by the original
> poster) was about why graphical modeling should use a set of concepts
> designed for something different.
So when I assumed "EMF isn't sufficient" as the premise I was
mistaken... :-)
> what you want to use them for: too many concepts can make something overly
> complex, but equally having too few concepts can make something complex.
>
Indeed, where is Goldilocks most comfortable?
> The original poster just wants to have three node types and one connection
> type, and ends up having to create 9 connection types and cobble them back
> together to achieve this (although some GMF bug prevented that). To me, that
> sounds unnecessarily complex.
>
Indeed. Of course a meta model that's best understood by brilliant
people with Ph.Ds isn't quite Goldilocks territory either.
> In your blog post below, you just want two object types and one connection
> type (that isn't owned by either object type). To achieve that you need 35
> elements in your metamodel. Again, to me that sounds unnecessarily complex.
>
Indeed, yet a model with n-ary associations is beyond the grasp of most
mortals. Very powerful and very cool; endless fodder for discussion at
universities. But something that might well drive modeling into the
ground if given a chance.
> Richard Welke's work in the article I referred to pointed out just these
> kinds of problems over 20 years ago.
An excellent point.. Microsoft is push for "M" is new and cool and even
"Xtext" is new and cool (especially so!) but my Ph.D. supervisor did
similar things in the 70's. What's the lesson to be learn: What's old
is new.
> His OPRR - Object, Property,
> Relationship and Role - provides a "minimal appropriate" set of concepts
> designed from the ground up for graphical modeling tools.
So why isn't it ruling the world today?
> GMF already has to
> add information to the EMF model, e.g. to distinguish whether an EClass is a
> node or a line.
Of course. How to visualize a concept and the underlying semantics are
not necessarily one-to-one right?
> My thought was that maybe by promoting that kind of
> information to a first class citizen, GMF would be able to handle the
> original case and the case from your blog more easily.
>
Likely. But would it handle the simple case more simply?
> With OPRR, there would be 5 elements for the metamodel from your blog, not
> 35.
Unfortunately the person who understands that would need 10 years of
university training, not 4.... :-)
> Conversely, for the simplest possible case of a directed relationship
> between two objects in an EMF tree view, EMF could make do with 3, but OPRR
> would still use 5.
Bingo. :-P
> In other words, my message isn't to you or the others on
> the EMF team - your set of concepts is right for what you use it for - but
> to those on the GMF team, for whom the lack of more explicit relationship
> concepts seems to be causing problems.
>
Send them back to university I say!
> And to both EMF and GMF teams: I think it's great the way you tirelessly
> answer users' questions in these newsgroups!
We privately send then a bill in the background. :-P
> Keep up the good work.
>
If only there were one best way! Brilliant people like you will
eventually help the world make progress. :-)
> All the best,
> Steve
>
> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:gq0at6$a8q$1@build.eclipse.org...
> Steve,
>
> Given that one of the biggest complaints directed at modeling is that it's
> complex, the premise that generally a more complex formalism is needed is a
> little frightening. I suppose everyone should abandon EMOF/Ecore along with
> the whole OMG specification stack based on it and use something else. I
> wonder what? Do you have any more specific suggestions? :-P
>
> It's often possible to build up more complex things from simpler things:
>
> http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html
>
> Still, you do end up with more complex things as a result, and of course the
> Java API to deal with it reflects that complexity...
>
>
> Steven Kelly wrote:
> The root problem is simply that GMF uses EMF's Ecore concepts for describing
> the modeling languages. Those concepts aren't enough to describe common
> situations nicely - like in the case you describe. This problem was proved
> over 20 years ago, along with the fact that even type inheritance is no real
> solution: see sections 3.5.2 and 4.4 in the article here:
> http://www.dsmforum.org/papers/CASE_Repository.html.
>
> To be able to nicely describe connections that can occur between sets of
> object types, you need a better set of concepts, like the OPRR described in
> that article. With OPRR, you'd just say your connection can be from
> {NodeType1, NodeType2 or NodeType3} to {NodeType1, NodeType2 or NodeType3}
> (or whatever other rule you want).
>
> Maybe the committers can tell us if there are any plans to improve GMF to
> start using more powerful concepts, as other tools have successfully been
> doing for decades?
>
> All the best,
> Steve
>
>
>
>
|
|
|
| Re: links aren't drawn correctly [message #222358 is a reply to message #222153] |
Mon, 23 March 2009 10:53 |
| Eclipse User |
|
|
|
Originally posted by: stevek.metacase.com
Ed,
I see from your blog that now may be a bad time for this discussion: my
sincerest condolences. Let's return to this at a later date.
All the best,
Steve
"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:gq190n$186$1@build.eclipse.org...
> Steve,
>
> Comments below.
>
> Steven Kelly wrote:
>> Ed,
>>
>> I have no problem with EMF: the Ecore concepts are great if what you want
>> is a tree view and property sheets.
> You're commingling Ecore with EMF.Edit. A tree view with property sheets
> is a trivial manifestation of an EMF model....
>> My question (and that faced by the original poster) was about why
>> graphical modeling should use a set of concepts designed for something
>> different.
> So when I assumed "EMF isn't sufficient" as the premise I was mistaken...
> :-)
>> what you want to use them for: too many concepts can make something
>> overly complex, but equally having too few concepts can make something
>> complex.
>>
> Indeed, where is Goldilocks most comfortable?
>> The original poster just wants to have three node types and one
>> connection type, and ends up having to create 9 connection types and
>> cobble them back together to achieve this (although some GMF bug
>> prevented that). To me, that sounds unnecessarily complex.
>>
> Indeed. Of course a meta model that's best understood by brilliant people
> with Ph.Ds isn't quite Goldilocks territory either.
>> In your blog post below, you just want two object types and one
>> connection type (that isn't owned by either object type). To achieve that
>> you need 35 elements in your metamodel. Again, to me that sounds
>> unnecessarily complex.
>>
> Indeed, yet a model with n-ary associations is beyond the grasp of most
> mortals. Very powerful and very cool; endless fodder for discussion at
> universities. But something that might well drive modeling into the ground
> if given a chance.
>> Richard Welke's work in the article I referred to pointed out just these
>> kinds of problems over 20 years ago.
> An excellent point.. Microsoft is push for "M" is new and cool and even
> "Xtext" is new and cool (especially so!) but my Ph.D. supervisor did
> similar things in the 70's. What's the lesson to be learn: What's old is
> new.
>> His OPRR - Object, Property, Relationship and Role - provides a "minimal
>> appropriate" set of concepts designed from the ground up for graphical
>> modeling tools.
> So why isn't it ruling the world today?
>> GMF already has to add information to the EMF model, e.g. to distinguish
>> whether an EClass is a node or a line.
> Of course. How to visualize a concept and the underlying semantics are
> not necessarily one-to-one right?
>> My thought was that maybe by promoting that kind of information to a
>> first class citizen, GMF would be able to handle the original case and
>> the case from your blog more easily.
>>
> Likely. But would it handle the simple case more simply?
>> With OPRR, there would be 5 elements for the metamodel from your blog,
>> not 35.
> Unfortunately the person who understands that would need 10 years of
> university training, not 4.... :-)
>> Conversely, for the simplest possible case of a directed relationship
>> between two objects in an EMF tree view, EMF could make do with 3, but
>> OPRR would still use 5.
> Bingo. :-P
>> In other words, my message isn't to you or the others on the EMF team -
>> your set of concepts is right for what you use it for - but to those on
>> the GMF team, for whom the lack of more explicit relationship concepts
>> seems to be causing problems.
>>
> Send them back to university I say!
>> And to both EMF and GMF teams: I think it's great the way you tirelessly
>> answer users' questions in these newsgroups!
> We privately send then a bill in the background. :-P
>> Keep up the good work.
>>
> If only there were one best way! Brilliant people like you will
> eventually help the world make progress. :-)
>> All the best,
>> Steve
>>
>> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
>> news:gq0at6$a8q$1@build.eclipse.org...
>> Steve,
>>
>> Given that one of the biggest complaints directed at modeling is that
>> it's complex, the premise that generally a more complex formalism is
>> needed is a little frightening. I suppose everyone should abandon
>> EMOF/Ecore along with the whole OMG specification stack based on it and
>> use something else. I wonder what? Do you have any more specific
>> suggestions? :-P
>>
>> It's often possible to build up more complex things from simpler things:
>>
>> http://ed-merks.blogspot.com/2008/01/modeling-associations-w ith-ecore.html
>>
>> Still, you do end up with more complex things as a result, and of course
>> the Java API to deal with it reflects that complexity...
>>
>>
>> Steven Kelly wrote:
>> The root problem is simply that GMF uses EMF's Ecore concepts for
>> describing
>> the modeling languages. Those concepts aren't enough to describe common
>> situations nicely - like in the case you describe. This problem was
>> proved
>> over 20 years ago, along with the fact that even type inheritance is no
>> real
>> solution: see sections 3.5.2 and 4.4 in the article here:
>> http://www.dsmforum.org/papers/CASE_Repository.html.
>>
>> To be able to nicely describe connections that can occur between sets of
>> object types, you need a better set of concepts, like the OPRR described
>> in
>> that article. With OPRR, you'd just say your connection can be from
>> {NodeType1, NodeType2 or NodeType3} to {NodeType1, NodeType2 or
>> NodeType3}
>> (or whatever other rule you want).
>>
>> Maybe the committers can tell us if there are any plans to improve GMF to
>> start using more powerful concepts, as other tools have successfully been
>> doing for decades?
>>
>> All the best,
>> Steve
>>
>>
>>
|
|
|
Goto Forum:
Current Time: Fri May 09 22:34:55 EDT 2025
Powered by FUDForum. Page generated in 0.03973 seconds |
Home