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

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

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.

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.

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.

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.

PS: Let's continue the discussion on gmt-dev, see CC above.

Jorn

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