Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gmt-dev] GMT and MOF/XMI, FAQ

Hi Philipp,

> The subtle and less subtle differences between class-modeling in UML, MOF,
MOF2 and EMF
> are more of academic interest.

Agree. Can you point us to the "definite" Ecore subset of MOF used in EMF?
If no one here has an answer I'll post the question on the EMF mailing list.

> As someone looking from outside to your FAQ, I could have the following
objections
> to the formulations of your answers:

> In your answer to "Is GMT intended as MDA tool platform?" you write:
>  "where MOF etc. is certainly relevant, and where pragmatically a subset
of
>  MOF such as the Ecore from EMF should be sufficient for representing
*models*..."

> Objection:
> (I think there was a typo here, the sentence starts wrong)

Yes, need to correct that.

> With MOF you define meta-models, and with EMF you generated from
> the definition (in a subset of MOF2 called Ecore) an implementation
> where models are represented as instances of generated Java classes, and
> a persistence code is generated, which allows to serialize them in
> the XMI-Schema generated from the MOF meta model. The sentence
> gives the impression that you are not following this industrial view of
MOF.
> From an academic point of view, your sentence of course makes sense,
> in principle there is no difference between models and meta-models,
> but you will loose industry people here.

On this mailing list please use the term "model" and "meta model" *relative*
to a specific tool. No "meta meta models" please ;-) Alternatively use the
term "tool model" to refer to the meta model of a tool. Most people here are
practitioners, and I don't think the lack of "meta talk" creates confusion,
on the contrary it brings the discussion closer to reality by emphasising
the relativity of the concept of a meta model.

>In your answer to "What is the use of MOF within GMT?" you write:
>   "In most commercial projects that use modeling, UML is used to define
the models, not
>  MOF. In the last years there has emerged a standard to exchange models:
XMI."

> Objection:
> Given the fact that XMI is a mapping from MOF to XML, people may be
confused after
> this answer.

How about replacing "UML is used ..." with "UML tools are used..."?

>Further in your answer to the same question you write:
>  "Users of the GMT tool set will model in a Domain Specific Language and
are probably
>  not concerned in what language the meta-model for this DSL is made."

> Objection:
> This is really dangerous. Look at what happened in academic, research and
science: people have
> 30 years of success-stories about applications of Domain Specific
Languages, and still, it is
> considered as exotic, and in industry, they are not widely using it. The
problem of all this academic
> work was exactly that people where not concerned in what language the
meta-model for their DSL
> was made. MDA gives one standard way for defining the abstract syntax of
domain-specific
> languages: MOF. MOF is a chance, of making DSL applications main-stream.

Agree that MOF provides a nice chance for standardisaton - and for
interoperability on a different level - which is useful for some purposes.
See my other responses that are not yet in the FAQ - a MOF subset will do
for practical purposes, applying the old KISS principle.

> As well, things like explicitly writing
> down all MOF models, or generate some of the code from a MOF model do not
need to be made in
> the beginning. However, making the kind of statements you made about MOF
could be contra
> productive.

> Especially the way how Fuut-je is compared to EMF at the end opens more
questions than it
> answers:
> - why is making a difference whether I generate the XML with Fuut-je  or
EMF?
> - is the velocity template part a independent component, or is Fuut-je
monolytic? It sounds like
>  model to XML in the first step and XML to any code with Velocity in the
second.

Don't confuse current Fuutje with GMT. Ghica has produced some useful
documentation on the externally visible design of Fuutje, but more details
about the internal design need to follow. The internal design must have a
reasonable degree of separation of concerns, otherwise it would not have
been easily possible to adopt the Velocity template language. We need to
further explore consolidation with ArchitectureWare to prevent two parallel
development streams supported by a small number of scarce resources.

> General Model Transformer sounds like transform models of meta-model A
into models
> of meta-model B. EMF gives no answers to this, it only allows to map
meta-models into
> implementations including a graphical editor, and an XMI serializer. With
the EMF add-on
> XSD, one can start with a Schema, generate a meta-model for the schema,
and have the
> resulting serialization implementation comply with the initial Schema.
Interesting are as
> well developments, where things are integrated with GEF, and one uses GEF
to do
> advanced visual editors for models, whose meta-model is done with EMF.

We welcome suggestions from people experienced in using EMF, to help us
evaluate what parts of EMF are really useful for our purpose. Is there an
advanced visual model editor that we can use? We *don't* want to drag along
unneeded baggage. You are correct that GMT is not only about model-to-text
(like Fuutje, ArchitectureWare, and similar tools) but also model-to-model
transformations. Hence the planned QVT reference implementation(s).

> The example of use for Fuut-je sounds more like traditional code
generation technology.
> Is this a misunderstanding? If your understanding is that code is a model
as well, then,
> yes, from an academic/research point of view I can agree. But again, you
will loose
> people from industry, if you have such a view.

Most people in industry at the moment will be quite happy with good
model-to-text transformation tools (traditional code generation)! This is
the approach to DSLs that Fuutje enables today & in the meantime - until
we've got practically useful QVT tools that can be plugged into GMT. At this
 point you'll loose people in the industry if you exclusively focus on
model-to-model transformation.

Regards,
Jorn

Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534



Back to the top