Home » Modeling » M2T (model-to-text transformation) » What is the ideal EMF model to use as input to JET?
What is the ideal EMF model to use as input to JET? [message #48762] |
Thu, 21 August 2008 02:58 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Francis Gavino![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=soygavino%40gmail.com) Messages: 57 Registered: July 2009 |
Member |
|
|
Hello,
This has been a question that's been bugging me for quite sometime now.
There are many ways of creating an Ecore model: 1)XML schema, 2)Annotated
Java, 3)Rational Rose model, 4)Rational UML model, and then there's a few
others like Rational's exemplar authoring and probably more ways.
My question is, what would be the 'friendliest' or 'safest' way of
creating the Ecore model with the intention of using it as input to JET?
Yes, probably all of these are supported, and JET only cares that it's an
EMF model, but I've heard about hesitations on certain ways... maybe
they're just their preferences?
One real experience I've had is that there are some JET features that
require the ExtendedMetaData "kind" to be set in the Ecore (E.g., dump).
The ExtendedMetaData by default is not added to the Ecore model if you
create it for example, from a UML model.
Is there a guide available on creating an Ecore model suited for JET? If
there is none, what do you recommend? On a side note, once an Ecore model
is created from one of the sources, is it a best practice to throw away
the source and maintain the Ecore moving forward?
Thanks,
Francis
|
|
|
Re: What is the ideal EMF model to use as input to JET? [message #48791 is a reply to message #48762] |
Thu, 21 August 2008 08:51 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: mozafara.cs.man.ac.uk
Hi,
In my opinion, the answer to your question really depends on your taste.
If you prefer the visual design approach, there are loads of tools out
there. However, I took a different direction for my project.
I first started to design a fairly complex metamodel using visual tools
but the more complex your model structure is the messier the visual
model gets. Plus, few tools can do an orthogonal layout and you endup
with a massive criss-cross of associations, not to mention the
overlaying of association names.
So working with text was easier for me than working a visual tool. It's
really counter-intuitive! But tweaking XML tags or writing Java
interfaces weren't my best options.
I found KM3 language from AM3 project (eclipse.org/gmt) as the best
trade off. You work from a concise notation and then "inject" your km3
model into ecore. For example a typical EClass is defind like this in km3:
class NAME {
attribute attr : String;
reference x container : ReferenceClassName;
}
Francis Gavino wrote:
> Hello,
>
> This has been a question that's been bugging me for quite sometime now.
> There are many ways of creating an Ecore model: 1)XML schema,
> 2)Annotated Java, 3)Rational Rose model, 4)Rational UML model, and then
> there's a few others like Rational's exemplar authoring and probably
> more ways.
> My question is, what would be the 'friendliest' or 'safest' way of
> creating the Ecore model with the intention of using it as input to JET?
> Yes, probably all of these are supported, and JET only cares that it's
> an EMF model, but I've heard about hesitations on certain ways... maybe
> they're just their preferences?
> One real experience I've had is that there are some JET features that
> require the ExtendedMetaData "kind" to be set in the Ecore (E.g., dump).
> The ExtendedMetaData by default is not added to the Ecore model if you
> create it for example, from a UML model.
> Is there a guide available on creating an Ecore model suited for JET? If
> there is none, what do you recommend? On a side note, once an Ecore
> model is created from one of the sources, is it a best practice to throw
> away the source and maintain the Ecore moving forward?
>
> Thanks,
> Francis
>
>
|
|
|
Re: What is the ideal EMF model to use as input to JET? [message #48821 is a reply to message #48791] |
Thu, 21 August 2008 09:22 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Ed Merks![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=ed.merks%40gmail.com) Messages: 33196 Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060007090504000204050506
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Amin,
It's a lot of work to make pretty graphical diagrams for a complex
model, but it's possible:
< http://download.eclipse.org/modeling/emf/emf/javadoc/xsd/2.5 .0/org/eclipse/xsd/package-summary.html#details>
http://download.eclipse.org/modeling/emf/emf/javadoc/xsd/2.5 .0/org/eclipse/xsd/package-summary.html#details
But I agree that most of these things are really a matter of personal
preference. I wish our Emfatic support was in better shape to support
direct editing of Ecore that way...
Francis,
With regard to the original question, I think the point is that JET uses
xpath and xpath makes a distinction between elements and attributes
which Ecore does not care about. Nevertheless, I think JET will work
equally well no matter which form of model definition you use. If you
want to use a graphical editor, it's not necessary to use UML because
the Ecore Tools editor is very usable:
http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml
Amin Mozafari wrote:
> Hi,
> In my opinion, the answer to your question really depends on your
> taste. If you prefer the visual design approach, there are loads of
> tools out there. However, I took a different direction for my project.
> I first started to design a fairly complex metamodel using visual
> tools but the more complex your model structure is the messier the
> visual model gets. Plus, few tools can do an orthogonal layout and you
> endup with a massive criss-cross of associations, not to mention the
> overlaying of association names.
> So working with text was easier for me than working a visual tool.
> It's really counter-intuitive! But tweaking XML tags or writing Java
> interfaces weren't my best options.
> I found KM3 language from AM3 project (eclipse.org/gmt) as the best
> trade off. You work from a concise notation and then "inject" your km3
> model into ecore. For example a typical EClass is defind like this in
> km3:
>
> class NAME {
> attribute attr : String;
> reference x container : ReferenceClassName;
> }
>
>
> Francis Gavino wrote:
>> Hello,
>>
>> This has been a question that's been bugging me for quite sometime
>> now. There are many ways of creating an Ecore model: 1)XML schema,
>> 2)Annotated Java, 3)Rational Rose model, 4)Rational UML model, and
>> then there's a few others like Rational's exemplar authoring and
>> probably more ways.
>> My question is, what would be the 'friendliest' or 'safest' way of
>> creating the Ecore model with the intention of using it as input to
>> JET? Yes, probably all of these are supported, and JET only cares
>> that it's an EMF model, but I've heard about hesitations on certain
>> ways... maybe they're just their preferences?
>> One real experience I've had is that there are some JET features that
>> require the ExtendedMetaData "kind" to be set in the Ecore (E.g.,
>> dump). The ExtendedMetaData by default is not added to the Ecore
>> model if you create it for example, from a UML model.
>> Is there a guide available on creating an Ecore model suited for JET?
>> If there is none, what do you recommend? On a side note, once an
>> Ecore model is created from one of the sources, is it a best practice
>> to throw away the source and maintain the Ecore moving forward?
>>
>> Thanks,
>> Francis
>>
>>
--------------060007090504000204050506
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Amin,<br>
<br>
It's a lot of work to make pretty graphical diagrams for a complex
model, but it's possible:<a
href=" http://download.eclipse.org/modeling/emf/emf/javadoc/xsd/2.5 .0/org/eclipse/xsd/package-summary.html#details"><br>
</a>
<blockquote><a
href=" http://download.eclipse.org/modeling/emf/emf/javadoc/xsd/2.5 .0/org/eclipse/xsd/package-summary.html#details"> http://download.eclipse.org/modeling/emf/emf/javadoc/xsd/2.5 .0/org/eclipse/xsd/package-summary.html#details</a><br>
</blockquote>
But I agree that most of these things are really a matter of personal
preference.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: What is the ideal EMF model to use as input to JET? [message #48914 is a reply to message #48762] |
Mon, 25 August 2008 19:51 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Paul Elder![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=pelder%40ca.ibm.com) Messages: 849 Registered: July 2009 |
Senior Member |
|
|
Francis:
A few more comments in addition to Ed's and Amin's.
I don't know that there is an optimal representation of an ECore model. I'm
developing a bias towards text - but, maybe I've been working on JET too
long, and its starting to warp my perception.
From the JET runtime experience, I think you can divide things into two
categories: EMF models with ExtendedMetaData (typically created from an
XSD), and everything else.
When JET finds extended metadata for an object, it tries to figure out what
the underlying XML element/attribute was, and adapt is XPath processing to
match.With everything else, an EReference is mapped to the 'child' axis, and
an EAttribute to the 'attribute' axis.
So my advice is:
1) If you want to think of your model as an XML document (and persist it
that way), then define an XSD. But, be aware that XPath 1.0 (which JET
implements) has a few shortcomings when dealing with advanced features like
substitution groups.
2) If you want to think of your models as networks of EObjects, then use
something other than XSD.
Finally, you allude having to do an extended meta-data hack to get JET's
c:dump tag to work in a certain way. Dump was conceived as a quick and dirty
way to 'see' your model - it hasn't kept pace with the complexity of some
models. Alternatives to such hacking would be to write a custom template, or
a custom tag that did exactly what was required.
Paul
"Francis Gavino" <fgavino@gmail.com> wrote in message
news:ee2ef960081765730b25174ea2eda430$1@www.eclipse.org...
> Hello,
>
> This has been a question that's been bugging me for quite sometime now.
> There are many ways of creating an Ecore model: 1)XML schema, 2)Annotated
> Java, 3)Rational Rose model, 4)Rational UML model, and then there's a few
> others like Rational's exemplar authoring and probably more ways.
> My question is, what would be the 'friendliest' or 'safest' way of
> creating the Ecore model with the intention of using it as input to JET?
> Yes, probably all of these are supported, and JET only cares that it's an
> EMF model, but I've heard about hesitations on certain ways... maybe
> they're just their preferences?
> One real experience I've had is that there are some JET features that
> require the ExtendedMetaData "kind" to be set in the Ecore (E.g., dump).
> The ExtendedMetaData by default is not added to the Ecore model if you
> create it for example, from a UML model.
> Is there a guide available on creating an Ecore model suited for JET? If
> there is none, what do you recommend? On a side note, once an Ecore model
> is created from one of the sources, is it a best practice to throw away
> the source and maintain the Ecore moving forward?
>
> Thanks,
> Francis
>
>
|
|
| |
Goto Forum:
Current Time: Fri Aug 16 18:36:52 GMT 2024
Powered by FUDForum. Page generated in 0.03453 seconds
|