(no subject)

Date view Thread view Subject view Author view Attachment view

Date: Thu 12 Feb 2004 - 20:58:09 GMT


Your mailbox seems to change everyday !

What i was saying is, if you have a look at the MOF itself (from which the
javax.jmi.model package is JMI-generated), then you can see the IsOfType
association between the TypedElement and its Classifier is non navigable
from the Classifier to the TypedElement. This make impossible to find which
AssociationEnd is connected to a given Classifier from this Classifier. This
can also be seen from the IsOfType association
ml) : it is possible to find out the association, but in order to find what
you want, you have to ask for all links and select ones who have a specific
class and its generalizations in one side and AssociationEnd in the other.
If the association have been navigable in both ways, then this information
would be available in the IsOfType class and (if a reference is defined on
this class) in the Classifier class... Unfortunately it is necessary to
check all ancestors. This was not a problem for me because i had anyway to
translate data types according to the association specification... You have
the algorithm i chose in the MDRMetaFeature class (i have not the code from
where i am writing you). This algorithm does not tackle all problems raised
by multiple inheritance, but i consider these problems appear rarely (this
let to great discussions with B. Rumpe ;-)).
I don't know about the reference closure rule in MOF... All I know is a
Reference must expose a navigable association end, which is not the case
here. I feel this is not this rule that annoys us here, but the navigation
property of the above described association. It should also be good to have
an allAncestor operation in the GeneralizableElement.

I send this mail to both JMI and PUML because i feel some can give good

The MTL_generalites is also available at
http://fondement.free.fr/MTL/MTL_generalities.pdf... I hope this one will work.

What does the acronym AFAIK stands for ?

"see" you in next adventures !


----- Original Message ----- 
From: <saintman@pandora.be>
To: "Frédéric FONDEMENT" <frederic.fondement@epfl.ch>
Sent: Thursday, February 12, 2004 8:42 PM
Subject: Re: Association access

Hash: SHA1

Hi Frédéric,

What do you mean by a fancy mailbox?

Also, are you sure one can't get the type of an associationEnd? The JMI API
does seem to provide a getType() operation for TypedElement:
Unless you mean the other way round? (ie it is impossible to get all
associationEnds associated with a classifier (which is logical, since that's
the difference between associationEnds and references if I understand
But even if that were possible, it would still be necessary to collect the
associationEnds from a class' supertypes as well, since a class should be
able to navigate an association defined on a superclass too...
AFAIK, the real issue is problems like the reference closure rule (MOF),
sometimes forbids an associationEnd to be exposed by a reference.
Do you agree?

Thanks for the pdf's, although the MTL_generalities.pdf file seems to be
corrupt (can't open it with either xpdf, ghostview or acrobat)

Kind Regards,


On Thursday 12 February 2004 19:57, you wrote:
> Dear Hans
> You have fancy mailboxes...
> Well, you have well interpreted the code
> (MDRAPI.getRelatedAssociationEnds()), and with this implementation, the
> first time you ask for an association end, this is a bit slow ; after, the
> cache limits the problem but... As Martin told you, the only way to do
> an efficient way is to expose a reference in your class, and I wrote this
> code in order to limit tool limitations that do not do this
> automatically... That is why, for model querying, there is this strange
>o n property, in order to know if it is needed to look at the associations
> when asking for an association end, or if references are enough (see
> MDRMetaAssociationEnd.retreiveRef()). The real problem here is that an
> AssociationEnd is a TypedElement whose type cannot acces (one way
> association)... So the problem comes from the MOF, and not from the JMI...
> I have attached this mail some documentation for you to better understand
> the code...
> I hope this can help
> Frederic.

Date view Thread view Subject view Author view Attachment view