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

["Jorn Bettin" <jorn.bettin@xxxxxxxxxxxxxxxx>]

Hi Ghica,

> > 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:)

See my comments below...

>
> "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."

This is off track for our purposes. Even outside our context I disagree with
that quote, it only makes sense to have any manual intervention with DB
table/column names *if* you need to map to a legacy database, and in that
case you use the MODEL-DRIVEN INTEGRATION pattern. But let's not go off on a
tangent here, time is scarce...

>
> 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.

... which should be enough to give us a start.

> 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).

A week ago I wrote "For a visual DSL with boxes and lines you'd need to
capture the geometric coordinates in the concrete sytax aspect, and assign
appropriate shapes to the various elements. But as agreed, all that's not
part of step 1 for GMT, so we don't need a concrete syntax aspect just yet."

We'll address usability at the appropriate time. And you'll be surprised how
far we can get without any concrete syntax aspect!

> 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.

Absolutely. That's the first step. See roadmap in Architecture document.

> 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).

Let's please not build a point-to-point solution between GME and Velocity.
Of course that can be done, but it has nothing to do with the objectives of
GMT and it would just be a starting point for a tangled mess. Next Markus
might write a point-to-point solution between GME and oAW. Then you might
want to leverage your old templates and need yet another poin-to-point
interface... If all the tools publicly expose completely different meta meta
models, then any value GMT workflow can add is minimal if not non-existent.

>
> 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?

Not skip it, it's just not step 1 ;-) Next, discuss and agree the basics of
the GMT architecture and in parallel validate EMF with our example meta
model and see what type of specification tool we get for free out of EMF.

Jorn

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