[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.omelet] Meta-models as types (was Re: Welcome to OMELET)

Hi Jim

[Sorry for the tardy reply. I've been off-line for two weeks after getrting
married.]

"Jim Steel" <jim.steel@xxxxxxxx> wrote in message
news:cakign$kng$1@xxxxxxxxxxxxxx
>
> If we consider:
> * a "model", which has no real MDA definition as a modelling element, to
> be MOF extent, which by my reckoning is the only modelling concept that
> approximates the commonly-held idea
> * a "metamodel" to be a MOF:Package (in either its EMOF or CMOF form
> according to taste)
> * that there is thus no modelled link between a model and a metamodel

I'm not well up on MOF legalese ('extent' is new to me), but I think I'm
happy with your assumptions, though this may cut to the heart of a
discussion
I had with Biju Appukuttan at MDAFA'03. The QVT Partners proposal,
and the current QVT Merge proposal is confused about the status of its
transformation diagram - half-way between a class diagram and an object
diagram. My MDAFA'03 paper had a similar confusion in my UMLX notation.
As soon as I moved to what I thought was a clean object diagram, the
problems
vanished (and the more recent parts of the QVT Merge proposal seem to be
going this way).

In order to support compound transformations, it is essential to be able to
instantiate a meta-model many times and this is easy when a meta-model is
instantiated as a 'class', so that each distinct instantiation can have a
distinct
'instance' name. If this treatment is not supported by MOF, then perhaps
MOF needs to define/recognise MetaModel as a Class. Similarly, a QVT
transformation defines a transformation meta-model that is instantiated
as many times as necessary to transform application meta-model instances.

> Considering these assumptions (and feel free to dissuade me of them),
> then what do you mean by the type of a model?

I endeavour to use type in the normal programming (theory) sense.

A type defines the universe of valid instances of that type. e.g. char
sometimes covers any instance from the set -128 .. +127.

Similarly, I see a metamodel as defining all valid instances, (and
excluding all invalid instances). This gives a precise test of meta-model
translations to different languages - they all make the same valid/invalid
distinction for all possible and impossible instances. The meta-model is
therefore the next stage in the evolution of more interesting types from
simple scalar types, arrays, structures/records, classes, meta-models.

> Making the leap that there might be such a link (and I personally don't
> think its a great idea):
>
> * given that extents are, as far as i can tell, heterogeneous in terms
> of the types of the objects, and also packages (metamodels)of the types
> of the objects, that they contain, does this imply multiple typing?

I think you may need to explain your point more clearly. If the universe
of valid instances includes multiple types there may indeed be multiple
types.
e.g. if the meta-model has B and C derived from A, then polymorphism
is available where A is used.

> * is there any polymorphism at the package level and, if so, what does
> it mean?

Again, yes and no. A meta-model may indeed be defined by one or
more packages which may exploit inheritance and consequently polymorphism.
But I don't see packages as exhibiting polymorphism, although as a result of
different implementation practices there may be many 'shapes' that
satisfy the package specification (e.g. reorder structure elements in C).

It is a while since I studied MOF in detail, but I don't think it can be
open-ended
like XSD with xs:anyType. So an instance of a MOF meta-model must involve a
closed set of types, so if a user-application wants to extend by derivation,
the
meta-model must be extended to ensure the derived types are within the
closed
meta-model.

I do this all the time courtesy of package merge. I have transformations
akin to
compilation passes that make only small changes to the meta-model. There is
therefore
massive commonality between input and output meta-models, so I build
specific
meta-models by merging in the unique aspects of input/output. I would expect
the
same to be necessary for a derived meta-model; a standard meta-model defines
the
standard structure which a user extends via merging to incorporate
user-specific
derivations.

Ultimately if a re-usable transformation has been defined to accept an A. It
cannot
operate on a MyA unless the compatibility (probably derivation) of MyA and A
has been
defined in the merged meta-model describing the input. This is no different
to C++ or
Java that are unable to compile a function call passing a MyA as A without
seeing the
type declaration for MyA.

[If MOF does have an xs:anyType equivalent, it presents no problem for
meta-model
instance validation, although it may impose severe challenges to
establishing the validity
of composed QVT transformations, since the possible matches within the
xs:anyType
must be assessed for all possible contents.]

> Please don't take these questions of criticism. I think its a really
> interesting idea.

No problem.

    Regards

        Ed Willink