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

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

See my comments.

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 2:40 PM
> To: Jorn Bettin; Ghica van Emde Boas; Mark Kofman; Jeff Hoare
> Cc: gmt-dev@xxxxxxxxxxx
> Subject: [gmt-dev] Re: example meta model etc.
>
>
> Hi Ghica,
>
> In an earlier email exchange or phone call you questioned whether a
> specification tool can be generated without including information
> about the
> UI etc. in the meta model (or tool model). If you look at the sample meta
> model just abstract away from the UI representation concepts (as you now
> suggest yourself ;-) and work with <<long>> and <<enumeration>> instead of
> <<textbox>> and <<dropdown>>. Hope my provocative example has put the
> discussion to rest.
Fine. At least we will have a clean model. How to do the UI remains to be
seen.

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

>
> As you will also have discovered, and as we briefly talked about at some
> earlier point, you *do* need more information about the concrete syntax in
> your meta model to generate a visual DSL (with graphical
> modelling elements)
> or a DSL that is fine-tuned for usability. The clean way of doing
> that is to
> create a separate meta model for the aspect of concrete syntax, and to use
> the TECHNICAL SUBDOMAIN pattern and related patterns to model this aspect.
> 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. 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.

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. Read chapter 5
of MDA Distilled, especially page 57.

>
> Over the weekend I'll send out UML models that illustrate the architecture
> that is defined in the meta model, because this may not be
> obvious just from
> looking at the meta model. The widget store will serve as our sample
> application. (We should not get into a long debate over the architecture,
> suffice to say that this type of architecture is very useful to
> build large
> business apps, and it scales very well). The purpose of the whole
> architecture is to enable proper dependency management in large
> code bases.
> To get to a reference implementation someone needs to map the architecture
> to - for example - a web based Java implementation. If we also use a
> web-based Java implementation for the specification tools, then
> we can reuse
> much of the handcrafted reference implementation that we need to do to
> derive the templates for the generation of specification tools.
Fine.
>
> PS: Let's continue the discussion on gmt-dev, see CC above.
Fine.
>
> 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.
>
>