Bugzilla – Full Text Bug Listing
| Summary: | Navigation of unnamed association ends. | ||
|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Nicolas Rouquette <nicolas.f.rouquette> |
| Component: | Core | Assignee: | Christian Damus <give.a.damus> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | Keywords: | plan |
| Version: | 1.1.0 | ||
| Target Milestone: | M3 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Nicolas Rouquette
Assigning to 1.2 release for consideration in the 1.2 feature planning. The fix is committed to cvs HEAD (1.2 branch.) In reply to some comments in the original description: "self.getProfile()" in the context of a stereotype would not work because "getProfile()" is the Java getter method for the "profile" attribute. An OCL expression would have "self.profile" but this, also, would not work in the MDT OCL implementation because to navigate the Stereotype::profile profile, we look for inverse references on its navigable opposite which is Profile::ownedStereotype. Unfortunately, this property is derived (as a subset of ownedType or packagedElement) so that the CacheAdapter (ECrossReferenceAdapter) doesn't see it and UML2Util::getNonNavigableInverseReferences() utility doesn't work. Moreover, navigating from a profile to its applications via "p.profileApplication" also won't have the desired result, but for a different reason. Profiles are Packages, so this actually resolves to the Package::profileApplication attribute which is a named and navigable association end. OCL actually specifies no means by which to navigate backwards on the ProfileApplication --> Profile association. Fixed in the MDT OCL 1.2.0 I200710171533 build. Could you please indicate what is the OCL 1.2 syntax that would simplify the original issue in this bug? i.e.: currently, I write: let pa:Collection(ProfileApplication) = (let p:Profile=self.getNearestPackage().oclAsType(uml::Profile) in self.getModel().getAllProfileApplications()->select(pa:ProfileApplication|pa.appliedProfile=p)) with OCL 1.2, I am not sure what I should/could write. (In reply to comment #4) It turns out that there really isn't any simpler way, given that the language specification provides no way to navigate the Profile-->ProfileApplication association in the reverse direction. There is no way to indicate that p.profileApplication should navigate from the profile to the application that references it, rather than to profile applications owned by the profile. The simplest expression that I can think of that will get an application of the profile, in the context of the Stereotype metaclass, is ProfileApplication.allInstances()->any( appliedProfile = self.owner.oclAsType(Profile)) Of course, there is also the problem of the possibility of the same profile being applied multiple times in a model (in the UML2 implementation, possibly different versions of the same profile definition). In this case, you would have to find the profile definition that is applied in the context of the element to which the stereotype is applied. This is something that you can't do in OCL, because it has no reflection capability: from a stereotype application (i.e., instance of a stereotype), you can get the element that it is applied to, but you cannot get the Stereotype that is its class. Your last comment is a concise summary and explanation of an issue that has bothered me for a while. I even thought of defining a profile to apply to a profile to provide the missing stereotype instance / definition traceability information you described. If this issue hasn't been filed yet with the OMG, it should and we should add the OMG issue # for tracking purposes to this bug for future reference. Move to verified as per bug 206558. Closing after over a year in verified state. Closing after over a year in verified state. |