[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gmt-dev] Re: example meta model etc.
|
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.
