self.general considered ambiguous for a Class

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 251808 | | Status | CLOSED FIXED | | Importance | P2 major | | Reported | Oct 23, 2008 03:02 EDT | | Modified | May 27, 2011 02:41 EDT | | Reporter | Rafael Chaves |

Description

org.eclipse.ocl (1.2.2.v200808291106)\ org.eclipse.ocl.uml (1.2.2.v200808291106)\ org.eclipse.uml2.uml (2.2.1.v200808251630)

Trying to parse the following expression:

self.general

using the UML binding will fail with an exception like:

org.eclipse.ocl.SemanticException: Multiple association ends named "general" in classifier "Class"\ at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:309)\ at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:279)\ at org.eclipse.ocl.internal.helper.HelperUtil.checkForErrors(HelperUtil.java:519)\ at org.eclipse.ocl.internal.helper.HelperUtil.parseQuery(HelperUtil.java:165)\ at org.eclipse.ocl.internal.helper.OCLHelperImpl.createQuery(OCLHelperImpl.java:175)\ at org.eclipse.ocl.uml.OCLHelperImpl.createQuery(OCLHelperImpl.java:91)\ at org.eclipse.ocl.uml.OCLHelperImpl.createQuery(OCLHelperImpl.java:1)

From some debugging, it seems when trying to find an element named 'general', both Classifier#general and Generalization#general (!) are found, resulting in the ambiguity. I do not understand why Generalization#general appears as a possible match.

The same expression works fine if using the Ecore binding.

This can be verified using the OCL interpreter and selecting a class element in a UML model.

[eclipse-ocl-bot]

By Christian Damus on Nov 02, 2008 11:50

If you don't mind, I'll upgrade this to major severity because the problem is rather severe. What's happening is that we are finding completely inappropriate association ends that happen to have the right name, but are the opposite of the end that would make sense. For example, Generalization::general is being found as a non-navigable association end because

1. Its name is "general" and
2. The other end of the association is not an attribute of Class.

The problem is in 2 above, which is the wrong criterion. Rather, we should check that the type of the other end is a supertype of the navigation source (Class in this case).

Also, we need to add a check that the end found by name is, in fact, owned by the association.

Note that the correct result for "self.general" in the context of a Class is, actually, a parse failure because the general property is undefined. Recall that Class::superClass redefines Classifier::general, so that the general attribute doesn't exist for Class. However, OCL can do this to access the redefined attribute: self.oclAsType(Classifier).general

[eclipse-ocl-bot]

By Christian Damus on Nov 02, 2008 11:57

I should add, also, that the search for non-navigable association ends also should not have found Classifier::general, because not only is it navigable, but as mentioned already is redefined in the Class context. Basically, a screaming disaster all around.

[eclipse-ocl-bot]

By Christian Damus on Nov 02, 2008 12:59

Committed a fix to the 1.2 maintenance (1.2.3 release) and HEAD (1.3 release) branches.

Includes a JUnit test based on the reporter's scenario, checking that looking up "general" in the Class context returns no property instead of throwing AmbiguousLookupException. It also checks that "self.oclAsType(Classifier).general" parses, just to be sure.

One final note: parsing with the Ecore environment finds the Classifier::general property because it isn't aware of redefinition. The Ecore package for UML has both the superClass and general attributes in Class because Ecore (EMOF) doesn't model redefinition (CMOF does).

[eclipse-ocl-bot]

By Christian Damus on Nov 03, 2008 11:35

Fix available in R1_2_maintenance: 1.2.3.M200811021306.

[eclipse-ocl-bot]

By Christian Damus on Nov 03, 2008 11:37

Fix available in HEAD: 1.3.0.I200811021527.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:40

Closing after over a year in verified state.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:41

Closing after over a year in verified state.