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

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

> The main point of discussion is the question whether it always would be
> possible to keep the PIM free of implementation artifacts (or
alternatively,
> have a third, mapping model, to contain implementation specifics).

In MDSD the concept of TECHNICAL SUBDOMAINS is used to separate concerns,
which can be used in the context of MDA to keep the PIM free of
implementation details.

> A practical example, that I really encountered last year, is, that
sometimes
> there are requirements for column lenghts and column names in a database.
> For example, column names could not be longer than 32 (in a respectable
> database like Oracle), and this caused duplicates in my mapping. The
> requirement was also that the names should stay meaningful, so that it
would
> not be too hard to look at the database with a standard reporting tool. I
> solved this by having tagged values specifying column names if needed, in
> the model, but really this is not a good solution, and of course the PIM
> becomes cluttered.

Everyone who is doing serious model-driven software development has come
across the particular issue you describe (column name length restrictions in
databases) and similar issues. And the solution is simple and elegant, see
below.

> The position of Jorn seems to be that we will never need
> this.

What I meant is that you don't need to manually intervene on an attribute by
attribute or column by column basis - this would be inefficient,
mind-numbing for a DBA, and is not in the spirit of MDSD.

One approach to the column length restriction is to define one set of
consistent abbreviations for the terms used in the domain and to define a
very simple transformation that applies these abbreviations. Basically this
equates to automation of the rules that your DBA otherwise would apply
manually - only that a machine does it much more consistently. You only ever
need to touch that transformation on the odd occasion when someone uses new
terminology that is not yet covered by your transformation or when someone
uses ridiculously long attribute or role names. - Please don't argue that
this is "impractical", I've applied this technique in the context of very
large database structures. Have built this functionality into commercial
products that are used by thousands of people, now it's time to do it in an
Open Source toolkit!

The transformation resides in a TECHNICAL SUBDOMAIN that covers the aspect
of "persistence" or "O/R mapping". It is easily implemented in a short Java
program or in whatever language you wish, and you can then either make it
available in your template language or apply it in a post-template
processor. If you want to be smart, invoke the transformation each time a
modeller enters a new attribute or defines an association, and provide the
modeller with a window where he can either expand the set of abbreviations
to cater for his/her new creation or to choose another name for the
attribute or role. That's what I call automation in the sense of the
LEVERAGE THE MODEL pattern. The abbreviations are *not* stored in the PIM,
they are stored in a separate subdomain with a separate meta model. In fact
the subdomain in this case is so simple that you'd hardly speak of a meta
model.

As said earlier: we will introduce TECHNICAL SUBOMAINS as and when required.

Note that the technical subdomain does not in any way pollute your model
with implementation artcfacts. The meta model of your PIM remains untouched,
we are not talking about adding tagged values to it. Tagging PIMs is a bad
practice, and one that we should avoid. TECHNICAL SUBDOMAINS *always* allow
you to avoid model tagging in the PIM, and only on exceptional occasions
does it make sense to take the (perceived...) short-cut of tagging the PIM.
The example of DB naming/length restrictions is not one of the exceptions.

End of discussion?

;-)

Jorn

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