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

[scoot <scott.finnie@xxxxxxxxxx>]

Folks,

First off, apologies in advance: list newbie.  Let me also state bias 
clearly: I'm a disciple of the Shlaer-Mellor / Translationist approach.  
Excuses complete.

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

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.
. Irrespective of the quantification, the mapping is not intrinsic to 
either world; it exists in its own right as a
  relation between the two (in shlaer mellor terms, it's a bridge 
between the domains).  In the enumeration case
  it may be more convenient to enter the mapping in the model, but it's 
important to realise it doesn't belong there. 
  [This is easily justified: what happens if you're mapping to J2EE, in 
which each application class needs to map
   not only to a relational table but an entity bean, etc.  Do you 
store all of these in the application model? 
   What happens if you decide to move to .Net?]
. The former approach is more robust and efficient since it's resilient 
to changes in the application domain model.
  (Change the model, re-run the mappings, and get a fully consistent PSM).
. 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).
. 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.

Apologies for the long message, hope it's at least relevant.

- Scott.