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

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

The discussion was already ended. I am waiting. We will assign all the
"easy" tasks to Jorn ;-)

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: Monday, May 24, 2004 11:22 PM
> To: gmt-dev@xxxxxxxxxxx
> Subject: Re: [gmt-dev] Re: example meta model etc.
>
>
> > 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
>
>
> _______________________________________________
> 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.
>
>