[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [gmt-dev] Re: example meta model etc.
|
>>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.
>
>