[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[gmt-dev] whether GMT will use MOF and in particular the EMF Ecore implementation of MOF

Apparently people would like to know whether GMT will use MOF and in particular the EMF Ecore implementation of MOF.
 
> - if MOF the standard means of the project to define 
> meta-models/abstract syntax?
>  If not, why?

> - are you using the EMF implementation of MOF? If not, why?
>
The picture below shows the four-layer meta data architecture underlying the UML, and it shows how modeling tools and tool generators fit into the picture.

The most important thing to notice is relativity of the concept of model and meta model. In OMG compatible language

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

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