The most important thing to notice is relativity of the
concept of model and meta
model. In OMG compatible language
- a meta modeling
tool is a tool to maintain models at the M2
level, that is models that define the abstract syntax of [domain specific]
languages such as the UML. See "Modeling Tool A" in
the picture above.
- a modeling tool is a tool used to maintain models at the M1 level,
that is domain models that are expressed using the concepts from the language
defined at the M2 level. See "Modeling Tool B" in
the picture above.
In the picture above the Tool
Generator uses a template language or similar to navigate
the meta model (M3) and to fill placeholders with model content
from (M2) to generate Modeling Tool B.
A tool such as Fuut-je provides both a modeling
tool and the capability to define a tool generator via writing appropriate code
templates. Because of the relativity of model and meta model, Fuut-je can (and
is) also used for meta modeling. Our goal is to make the tool generation process
as easy as possible, so that the implementation effort associated with domain
specific [modeling] languages is minimised. Hence we should not introduce
any unneeded baggage. MOF carries unneeded baggage, which is very likely
the reason why the EMF Ecore implementation of MOF only covers a subset of MOF!
So Ecore could be just about right ;-)
The current "standard" version of Fuutje relies on
a meta model that also contains unneeded baggage. We could develop a version of
Fuut-je that uses Ecore as the meta model. This could be the version of Fuut-je
that GMT users then use for the specification of DSLs.
However this only makes sense if this will
draw a larger audience (and contributors!) to GMT, and if other tools
such as openArchitectureWare take the same path, so that we achieve
interoperability at the level of abstract syntax. This would enable us to
leverage the best parts of Fuut-je, openArchitectureWare, and possibly further
tools, to build a very powerful tool set for modeling and tool generation - and
obviously for meta modeling (for those who insist on this being substantially
different from modeling ;-) and code generation in general.
None of the above directly addresses the GMT goal
of "model transformations as first-class models" and the goals of QVT. However,
if we go with Ecore, the planned QVT reference implementation within GMT
could also build on Ecore.
Can anyone point us to an up-to-date picture of
the Ecore subset of MOF, so that we can assess in detail whether it is lean
enough for our purposes?
To everyone: Please let us know if that's what
you'd like to see - GMT using the Ecore implementation of MOF!
PS: Terminology - In the
context of [meta] modeling tools we should simply talk about meta models and models relative to the tool - we just need to
make clear what [meta] modeling tool we are talking about. This means we can
have sensible discussions about modeling tools and meta modeling tools at the
same time. If we go ahead and use Fuut-je to build a Fuut-je version
based on Ecore, and then use that version to define DSLs and to
generate domain-specific modeling tools, any attempt to talk about
M-levels, meta meta models, meta meta meta models etc. will fail. Instead each
tool in the chain needs to have a distinct name.
Jorn