[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gmt-dev] Re: example meta model etc.
|
Hi Scott,
> Ghica wrote:
>
> >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. The position of Jorn seems to be that we will never
need
> >this.
> >
> My experience is that rather than fundamentally different, Ghica &
> Jorn's approaches are actually two points on a continuum.
Agree partially:
1. There is a fundamental difference between
(a) creating appropriate "technical subdomains" (see MDSD white paper or
MDSD patterns paper on www.mdsd.info) to avoid polluting a PIM with
implementation technology aspects (such as mapping to relational table &
column names) and
(b) tagging the PIM directly with implementation technology attributes.
In the former case the mapping information remains completely external to
the PIM, whereas the latter case is incompatible with the concept of a PIM.
Please note that "platform" is a relative term ;-) in MDA.
2. There is no universal answer in terms of an "appropriate" concrete
mapping between PIM and relational tables and columns, it depends heavily on
the context - as you describe below. There is a continuum in the amount of
manual intervention required to define the "appropriate" mapping from fully
automated to fully manual.
> Jorn, if I
> understand you correctly, you claim:
> . You can define an algorithm - or mapping - from the language you use
> to describe your application domain to the language of the target
> domain. Or more concretely (for example) you can define a mapping from
> the UML metamodel to the relational model (in this case specifically the
> Oracle relational model). We know that, for the case in point, the
> oracle model limits column names to 32 characters. So the algorithm
> would have to accomodate that (for example, by truncating names whilst
> ensuring appropriate uniqueness). Such an algorithm can always be
> created; the challenge lies in Ghica's requirement that the resultant
> names remain intuitive (the windows 8.3 filename mapping is useful
> example here).
That's the gist of it, all all relating to point 2 above. In a software
product family this algorithm (or set of rules) is typically one of the
variabilities. The algorithm used depends on the context, and it typically
implements all the requirements that a DBA may have - which can be a
completely manual mapping, i.e. the DBA types in all column names by hand.
Have never been at war with a DBA as Ghica suggested ;-)
> Ghica, I interpret your position as:
> . Sometimes it's not possible - or worth - coming up with a machine
> implemented algorithm; instead you do it in your head. In other words,
> the "algorithm" is implicit, and its result - an explicit enumeration -
> is captured.
>
> I hope that's a fair interpretation, apologies if not. Assuming it is,
> my observations are:
>
> . I see the enumeration as a limit case of the general rule approach;
> in pattern matching terms, the former defines a
> universal rule applicable to all attributes; the latter defines
> several rules each applicable to exactly one attribute.
Correct.
...
> . In several years of applying translative approaches the only time
> I've ever had to resort to hand mapping names is the
> legacy situation (i.e. the tables already exist).
Likewise.
> . Abstracting to the general case, my own most important learning from
> translation is to recognise the relationships
> among models (domains) as first class citizens. Doing so surfaces
> interesting and useful results: for example, I'd
> claim there's no such thing as abstract & concrete syntax per se:
> that in itself is a mapping who's purpose is
> representation. For example, to build a graphical editor for
> networks I would have:
> . a domain describing networks (itself derived from the domain of
> graphs)
> . a domain of 2d geometry
> . a representation bridge (mapping) describing how the two relate
> (e.g. switch <-> shape, trunk <-> line). In this
> case 2d geometry plays the role of concrete syntax, networks the
> role of abstract syntax.
Check out the "technical subdomain" pattern and related patterns where we
talk about "gateway meta classes". Essentially these patterns allow you to
separate concerns as appropriate, along the lines you describe above. And
yes, sure enough, "2d shapes and lines and the geometric layout of these" is
another valid domain. You can argue that this domain provides a "concrete
syntax" for the domain of graphs - if you don't buy into that terminology
I'm not worried.
Regards,
Jorn
Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534
