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

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

Hi Scott,
We were trying to close the discussion, until we need it again for the
development of GMT ... ;-)

Anyway.
Scott wrote:
>>
> 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.
>>
This is indeed a good expression of my position. I do think also that it
is -not- a point in a continuum to capture an enumeration instead of (or in
addition to) executing a mapping algorithm. I will explain why.

In GMT we are trying to define a leading example:
*A PIM metamodel (or DSL) consisting of "business components", properties
and relationships between those.
*A PIM, in our example a "webshop" application
*A PSM metamodel, we do not know which one yet, let's assume three of those,
Oracle, DB2 and MySQL.

If you can define a translationist mapping, and that should be possible to
do in 99.99% of the cases (resources permitting), you can transform any PIM
(including webshop, but also an Accounting PIM, or a Supply Chain PIM or..)
to the specific PSM of your choice. For our three PSM metamodels we have to
define 3 slightly different mappings.

Enter the enumeration. First of all, you must store it somewhere, as a 1st
class citizen,  because you do not want to recapture it for every
regeneration of your PSM instance. And, you must be able to edit the
enumeration in a user-friendly way.

How many mappings do you need? One for each PIM meta model - PSM meta model
combination. Im our example, 3. Even if you have enumerations, you will also
need a mapping, to do the default cases.

How many enumerations do you need? In our example 3, if we are looking at
having an Accounting model too, another 3, for the SCM another 3, etc. As
you can see, the number of 1st class enumerations you need to manage will
grow exponentially with the number of PIM instances, while the number of
mappings grows only with the number of metamodels. This is because mappings
are about transforming meta-models, and enumerations are about transforming
models. I do not see how to put that next to each other in a continuum.

It may be that Jorn thinks that he can always wager (and win) war with
database administrators and the like, and that I am more sceptical. For the
time being, I think it is not worth it to tackle the problem of managing the
enumerations, because there is lots of low hanging fruit to take first.

We will surely reopen this discussion some time later, but feel free to
disagree with what I said above now!

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 scoot
> Sent: Saturday, May 29, 2004 1:16 AM
> To: gmt-dev@xxxxxxxxxxx
> Subject: 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.
>
> _______________________________________________
> 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.
>
>