Diagram/model separation [message #115787] |
Fri, 30 March 2007 13:26  |
Eclipse User |
|
|
|
Originally posted by: andrew.montalenti.morganstanley.com
Hello,
I am currently working on a modeling tool, something that will end up
looking like a much-simplified class diagram editor, but with certain
customizations.
I am exploring GMF. Other developers within my company had already
created something of a prototype diagram editor targeting GMF 1.0. We are
now exploring GMF 2.0, and I'm working off the M5 stable build. We have
some new requirements since the development of the original prototype, and
I'd like to explore if some of the requirements we need to meet may
already be solved by new versions of GMF that may be coming down the
pipeline in 2.0 milestone builds going forward.
Currently, GMF works beautifully as an editor for models that conform to
the following metamodel:
+ Domain
|-- entities : EReference to Entity [0..*]
+ Entity
|-- fields : EReference to Field [0..*]
+ Scalar -> Field
|-- name : EString
|-- type : EEnum ScalarType
+ Reference -> Field
|-- entity : EReference to Entity [1..1]
I was able to produce an editor which can create Entities with Scalars,
and draw References between them.
The thing is, we want our diagram editor to edit diagrams which are
essentially "views" of this Entity data. So, for example, you might have
one diagram which shows the relationships among Entities A, B, and C, and
you might have another diagram which shows the relationships among
Entities C, D, and E. The whole lot would be in a single Domain (at
least, in our initial prototype). However, C might be present in both
diagrams, but would only have one canonical place in which C's information
is stored. Therefore, the addition of a field in C would result in an
update to both diagrams.
It seems something like this may be supported in either of two features I
see in recent builds of GMF:
1. Shortcuts. One could imagine the dropping of an Entity on the
canvas always resulting in the creation of a shortcut to an Entity, even
upon initial creation. In this way, edits to the Entity are reflected in
the model, but multiple diagrams can exist which view the same model data
of the "referenced" or "shortcut'ed" Entities. I don't know what side
effects this would introduce.
2. Diagram partitioning. I saw this feature mentioned in the GMF 2.0
New & Noteworthy (and linked from many places on the Wiki) but I do not
quite understand what it is and how it is supported. I've searched for
detailed explanations as to how to use this feature, but haven't found any
thus far.
If neither of these features can support this use case, I'd be willing to
explore more complicated designs that may allow it to happen.
This diagram/model separation is vital to the success of our editor, and
we suspect, to the success of many other diagram plugins that aim to use
the diagram canvas both as a visualization and as an editing tool. Any
suggestions as to the right approach -- or any hints as to what is being
worked on currently -- would be appreciated.
Thanks for your time,
Andrew Montalenti
|
|
|
Re: Diagram/model separation [message #116090 is a reply to message #115787] |
Mon, 02 April 2007 07:45  |
Eclipse User |
|
|
|
Hello Andrew,
> 1. Shortcuts. One could imagine the dropping of an Entity on the
Looks like this feature is exactly what you are looking for. In addition
I suggest to review “unsynchronized” diagrams. The only problem we have now
with shortcuts – is update of the links to/from shortcut element. This means,
if elements A, B present on two diagrams and you are creating the link from
A to B on diagram-1 this link will not be automatically visualized on diagram
B.
> 2. Diagram partitioning. I saw this feature mentioned in the GMF
> 2.0 New & Noteworthy (and linked from many places on the Wiki) but I
> do not quite understand what it is and how it is supported. I've
Imagine you have packages on your simplified class diagram and you would
like to open package diagram on double-clicking the package node. This is
what we call “diagram partitioning”.
-----------------
Alex Shatalin
|
|
|
Powered by
FUDForum. Page generated in 0.03792 seconds