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

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

> 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


> -----Original Message-----
> From: gmt-dev-admin@xxxxxxxxxxx [mailto:gmt-dev-admin@xxxxxxxxxxx]On
> Behalf Of Jorn Bettin
> Sent: Friday, May 21, 2004 10:12 PM
> To: gmt-dev@xxxxxxxxxxx; Mark Kofman; Jeff Hoare
> Subject: Re: [gmt-dev] Re: example meta model etc.
>
>
> > > The MDA concepts of PIM and PSM are not very helpful for meta
> > > modelling (the
> > > domain of "designing a domain-specific language) - it makes no
> > > sense to talk
> > > about a PIM and a PSM of a meta model. What you *do* have is
> an abstract
> > > syntax of your DSL and a concrete syntax of your DSL. In the meta
> > > model you
> > > define the abstract syntax. With our current technologies the
> mapping to
> > > concrete syntax occurs in the templates you use to generate the
> > > specification tool.
> > I do not agree with this. As an application developer it makes no
> difference
> > to me whether I am building an application to visualize
> "AddressBooks" or
> > "BusinessComponents".
>
> 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.
>
> > > 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.
> > I think the discussion would be much clearer if we would stop talking
> about
> > generating visual DSL's or specification tools for the time being.
>
> For step one were not talking about visual DSLs, see above. Replace
> "specification tool" with "Specification Application" if you want.
>
> > Let's
> > talk about creating a tool that allows specification of business
> components
> > (where your example model is the meta model and not UML). And yes, it
> needs
> > a GUI, and yes, we need to apply MDSD. If we have successfully
> done that,
> we
> > can talk about how to automate the process of tool development for other
> > DSL's. You cannot build a shoe factory if you do not know what
> shoes look
> > like.
>
> That's what the reference implementation is for... MDSD starts with a
> reference implementation...
>
> >
> > I am trying to imagine approaching the very smart group of Irish
> developers
> > I was working with last year, and telling them: Define a small number of
> > GATEWAY META CLASSES, IGNORE THE CONCRETE SYNTAX in your transformation
> > engine, and by the way, no visualization. ...
> > Instead of: lets define a mapping from our business model to the GUI and
> > another mapping from our business model to the database, and by the way,
> > here is a graphical tool that supports defining the mapping.
>
> 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.
>
> Jorn
>
> Jorn Bettin
> jorn.bettin@xxxxxxxxxxxxxxxx
> www.softmetaware.com
> Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534
>
>
> _______________________________________________
> 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.
>
>