[gmt-dev] GMT and MOF/XMI, FAQ

["Philipp W. Kutter" <philipp@xxxxxxxxxx>]

Dear all.
Thank you very much for your answers to my questions, it was very
interesting
and I think all my questions have been answered.

Regarding XMI, I think there is a misunderstanding about what it is.
XMI is a mapping
from MOF to XML, which in its early version mapped MOF models to a DTD,
and now
maps MOF models to a Schema. The Schema generated for MOF Model A is
normally
called XMI-Schema of A, like the Schema generated from the MOF Model of
UML is 
what is commonly know as the XMI-Schema of UML, or for some people just
XMI.

There is no XMI without MOF. 

>From a practical point of view, MOF can be seen as a subset of the
class-modeling 
constructs of UML. MOF models look like UML, and its as easy to write a
simple
MOF model as it is to write a simple UML model. If your model consists
of 
classes, their attributes and relations, they will look almost the
same. The subtle and
less subtle differences between class-modeling in UML, MOF, MOF2 and EMF
are more of academic interest.


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)
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.

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.

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. 

I worked 5 years on a PhD thesis about a DSL specification framework,
and we wrote a lot of
software for this. One thing I learned was, that all this academic work
is useless in industry if you
rely on the knowledge of things like EBNF or, even worse, formal
methods. Now there is the
chance to use what has been defined by industry for industry: MOF. 



Taking a tool like Fuut-je as starting point is certainly a good idea.
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.

Please do not misunderstand me: a code generation tool using Velocity
templates sounds useful,
transforming data of data-models into XML sounds useful as well. 

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.

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.

Best Regards, 
Philipp Kutter

A4M applied formal methods AG
www.a4m.biz
kutter@xxxxxxx

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature