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

["Ghica van Emde Boas" <emdeboas@xxxxxxxxxxxx>]

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

Not necessarily. GMT is an integration toolset. There must be space for both approaches.

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 
 

> -----Original Message-----
> From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx]On
> Behalf Of YeuWen
> Sent: Monday, May 24, 2004 5:49 AM
> To: gmt-dev@xxxxxxxxxxx
> Subject: [gmt-dev] Re: example meta model etc.
> 
> 
> 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
> 
> 
> _______________________________________________
> gmt-dev mailing list
> gmt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/gmt-dev
> 
> -- 
> This message has been scanned for viruses and dangerous content 
> by MoveNext MailScanner, and is believed to be clean.
> 
>