Home » Modeling » GMF (Graphical Modeling Framework) » Using "blueprint model" + metamodel
| Using "blueprint model" + metamodel [message #185704] |
Wed, 07 May 2008 11:08  |
 Zsolt Török
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi all,
I'm having some unusual requirements for my EMF/GMF based model editor.
After quite a bit of online research I couldn't find any useful advice on
how to go about implementing it, so here I am, asking for your guidance.
I have to define a high-level metamodel using Ecore to define the
domain-specific basic building blocks (let's call them hClass, hAttribute,
hAnnotation, etc.), which looks quite straightforward to me, I already
started working on that. However, the end user isn't supposed to be able
to create an hClass in the diagram editor, only select from a set of
specific, pre-defined hClass instances (e.g. Entity, Role, etc.) defined
in a "blueprint". At the same time, hAssociations, hAttributes and
hAnnotations should be directly available on the diagram. Since GMF isn't
able to handle multiple domain models at the moment, and apparently won't
be for a while, I guess this is only possible by tweaking the GMF palette
manually, although I don't really know where to start.
The blueprint is based on the same metamodel described above, and contains
a hierarchy of hClasses, where all other hClasses are created by
restricting one of the seven ancestor hClasses, as opposed to extending
them. This concept seems to be quite rare in the modeling world, or at
least I couldn't find any other modeling standard which uses this approach.
This blueprint model also defines some relationships between, and
constraints on, the pre-defined class instances, which have to be honored.
For example:
- It's not allowed to connect two classes on the diagram which can't be
connected according to the blueprint.
- It's not allowed to add an attribute to a class on the diagram if the
attribute wasn't there on one of its ancestor classes.
The only way I see to implement this is plugging a little module into the
EMF Validation Framework which consults the blueprint in some way to
determine if the model instance conforms to it or not.
I hope I managed to describe the problem in a way others can understand...
I've been living with this standard for quite a while now, it's getting
hard to look at it from an outsider's perspective. :)
Any advice highly appreciated!
Thanks,
Zsolt
|
|
|
| Re: Using "blueprint model" + metamodel [message #185735 is a reply to message #185704] |
Wed, 07 May 2008 12:52  |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
I think I've done something similer. In my case I didn't need to constrain the
palette, just add new creation tools for inserting building blocks. These
building blocks are read from a standard diagram+model "template" file and upon
creation, the building block is "cloned" and inserted. The template file is
itself editable, so it's fairly easy to add new building blocks to speed up the
modeling approach.
To make this work, I had to implement a family of classes. I think I needed
subclasses of at least Tool, ToolEntry, EditPolicy, Request and Command.
Note that in my case the original creation tools were present, and I didn't need
to additional constraints specific for each building block.
Hallvard
Zsolt Török wrote:
> Hi all,
>
> I'm having some unusual requirements for my EMF/GMF based model editor.
> After quite a bit of online research I couldn't find any useful advice
> on how to go about implementing it, so here I am, asking for your guidance.
>
> I have to define a high-level metamodel using Ecore to define the
> domain-specific basic building blocks (let's call them hClass,
> hAttribute, hAnnotation, etc.), which looks quite straightforward to me,
> I already started working on that. However, the end user isn't supposed
> to be able to create an hClass in the diagram editor, only select from a
> set of specific, pre-defined hClass instances (e.g. Entity, Role, etc.)
> defined in a "blueprint". At the same time, hAssociations, hAttributes
> and hAnnotations should be directly available on the diagram. Since GMF
> isn't able to handle multiple domain models at the moment, and
> apparently won't be for a while, I guess this is only possible by
> tweaking the GMF palette manually, although I don't really know where to
> start.
>
> The blueprint is based on the same metamodel described above, and
> contains a hierarchy of hClasses, where all other hClasses are created
> by restricting one of the seven ancestor hClasses, as opposed to
> extending them. This concept seems to be quite rare in the modeling
> world, or at least I couldn't find any other modeling standard which
> uses this approach.
> This blueprint model also defines some relationships between, and
> constraints on, the pre-defined class instances, which have to be
> honored. For example:
> - It's not allowed to connect two classes on the diagram which can't be
> connected according to the blueprint.
> - It's not allowed to add an attribute to a class on the diagram if the
> attribute wasn't there on one of its ancestor classes.
> The only way I see to implement this is plugging a little module into
> the EMF Validation Framework which consults the blueprint in some way to
> determine if the model instance conforms to it or not.
>
> I hope I managed to describe the problem in a way others can
> understand... I've been living with this standard for quite a while now,
> it's getting hard to look at it from an outsider's perspective. :)
>
> Any advice highly appreciated!
>
> Thanks,
> Zsolt
>
|
|
|
| Re: Using "blueprint model" + metamodel [message #185741 is a reply to message #185735] |
Wed, 07 May 2008 13:35 |
Zsolt Török
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Hi Hallvard,
Thanks for your response regarding the building blocks, good to know
someone already did something similar. My first idea was similar to yours:
putting the ready-made building blocks into an XMI file and populate the
palette by parsing this file. For me it's a requirement to be able to swap
this underlying blueprint file to a different revision, but parsing it
when launching the diagram editor should be flexible enough.
> To make this work, I had to implement a family of classes. I think I needed
> subclasses of at least Tool, ToolEntry, EditPolicy, Request and Command.
I will look into the GMF API, thanks for the tips!
> Note that in my case the original creation tools were present, and I didn't
need
> to additional constraints specific for each building block.
Lucky you... But jokes aside, it's the constraints I'm most worried about.
I will look around on newsgroups a bit more, and if there's no tried and
tested solution to be found, I'll just roll up my sleeves and implement it
from scratch.
Zsolt
|
|
|
Goto Forum:
Current Time: Thu Sep 26 17:30:12 GMT 2024
Powered by FUDForum. Page generated in 0.03215 seconds |
] 
Search
Help
Register
Login
Home
