[gmt-dev] Re: example meta model etc.

["YeuWen" <makyw@xxxxxxxxxxxxx>]

Hi all,

I guess the crux of the issue is that there are 2 schools of thoughts of how MDA vision can be achieved since it is still very much in its infancy stage - “elaborationist” and “translationist” (terms that were, I believe originally coined by Stephen Mellor).

In the elaborationist approach, the definition of the
application is built up gradually as you progress through from PIM to PSM to Code.

As a result of elaboration, it is possible that the lower level models get out of step with the higher ones. For this reason, tools generally support the capability to regenerate the higher level models from the lower, shown in the diagram as upward pointing arrows. The ability to generate downwards, modify, and re-synchronise by generating upwards is known as “round-trip engineering”.  

Clearly, in this approach, the generated artefacts (the PSM and the Code) must be understandable to the developer, otherwise modification (elaboration) would be not be possible. Contrast this with, say, the output from a language compiler where the generated code is not intended to be touched and is generally not human readable. 

In the translationist approach, the PIM is translated directly into the final code of the system by code generation. The transformation (or translation) of the PIM into the final code is performed by a sophisticated code generator, sometimes called a “Model Compiler”, and symbolised by the large arrow. It is driven by Generation Rules that describe how the elements of the PIM are to be represented in the final code. The PSM is an intermediate stage in the generation and is internal to the code generator. It is generally not visible or editable by the developer. 

I guess GMT is attempting to realise the vision of "translationist" approach.  Correct me if I am wrong.

Just my 2cents worth,
YeuWen
www.ModeleIT.com

From: "Ghica van Emde Boas" <emdeboas@xxxxxxxxxxxx>
To: <gmt-dev@xxxxxxxxxxx>, "Mark Kofman" <kofman@xxxxxx>,
	"Jeff Hoare" <jeff.hoare@xxxxxxxxxxxxxxxx>
Subject: RE: [gmt-dev] Re: example meta model etc.
Date: Sun, 23 May 2004 01:18:29 +0200
Reply-To: gmt-dev@xxxxxxxxxxx

> We need no further mapping. Everything we need for the implementation is
> derivable from the meta model. All we need is a thinn handcrafted
> reference implementation from which we can derive templates.

> We don't need to manually map the tool model (the "business
> model") to a UI
> model, a DB model etc if all these mappings are automatically derivable by
> applying a set of transformations to the model. These transformations in
> turn are specified in templates derived from the reference application.

I think those two sentences are at the core of our misunderstanding.
Here is a rather long quote from MDA distilled (p.57). (You may say that we
do not have to deal with database administrators for now. That would be
hiding from the issue:)

"The problem is to produce names for the tables and columns in the database.
In general, there is no straighforward way of knowing that the Balance
column of the Account table corresponds with the Balance attribute of the
Account business entity. It might be possible to apply naming heuristics in
this example, but that notion will certainly be shredded by real-world
database administrators insisting on proven corporate database table-naming
schemes. So, we need to correlate the elements in the source model with
elements in the target model."

I agree that you can derive a kind of 'default' implementation from the meta
model, if it is rich enough - EMF does generate a default editor application
for Ecore models. If, however, you want to have an application that is
usable in the real world or has graphics (you will need that sooner or
later!), you need to add extra information that does not belong in the
(meta) model. This extra information belongs in an implementation model
(length of database columns, position of rectangles in a graphic, etc.
etc.). And we need a mapping between those models (yes, I read about the
meta-class proxies).

If you are happy with what EMF offers you by default and Ecore is enough, we
do not have to do anything for your specification editor generator, because
EMF is already one. You could export your EA model to XSD, and import that
directly into EMF to make things even easier.

I am also wondering why GME does not offer what we need in this area? It was
specifically developed for the purpose of meta-modeling and has a much
richer meta-model than EMF. My evaluation of the GME Java interface learns
that it would not be very difficult to tie a Velocity template engine to it.
The efficiency of a Velocity template depends completely on the
appropriateness of the Java structure(s) that you pass to it. For that
purpose the GME interface could look as if the GME meta-classes are Java
classes (like in oAW or, by the way, Fuut-je).

So, actually, I think that we can skip the step of building a specification
generator in the way Jorn would like to have it. It already exists. What
next?

Regards,
Ghica van Emde Boas
Bronstee.com Software & Services b.v.
e-mail: emdeboas@xxxxxxxxxxxx,
tel: +31 23 5474422,
or: +31 6 53368747 (mobile)
fax: +31 23 5473347