From: Frédéric FONDEMENT (email@example.com)
Date: Thu 12 Feb 2004 - 20:37:45 GMT
Hi.... 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 (http://java.sun.com/products/jmi/jmi-1_0-fr-doc/javax/jmi/model/IsOfType.ht 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 advice... The MTL_generalites is also available at http://fondement.free.fr/MTL/MTL_resume.ppt... I hope this one will work. What does the acronym AFAIK stands for ? "see" you in next adventures ! Frédéric. ----- Original Message ----- From: <firstname.lastname@example.org> To: "Frédéric FONDEMENT" <email@example.com> Sent: Thursday, February 12, 2004 8:42 PM Subject: Re: Association access -----BEGIN PGP SIGNED MESSAGE----- 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: http://java.sun.com/products/jmi/jmi-1_0-fr-doc/javax/jmi/model/TypedElement.html 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 correctly)). 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), which 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, Hans 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 that > 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 > org.irisa.triskell.MT.repository.MDRDriver.ignoreAssociationEndsForNavigati >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.