search

eclipse-uml2 / uml2

An EMF-based implementation of the UML 2.x metamodel for the Eclipse platform.
Eclipse Public License 2.0
5 stars 4 forks source link

Spurious validation diagnostics for primitive type parameter types #93

Open eclipse-uml2-bot opened 6 hours ago

eclipse-uml2-bot commented 6 hours ago

| --- | --- | | Bugzilla Link | 529788 | | Status | NEW | | Importance | P3 normal | | Reported | Jan 13, 2018 05:25 EDT | | Modified | Jan 13, 2018 15:03 EDT | | Blocks | 529787 | | Reporter | Ed Willink |

Description

(The new EAnnotationValidator support provokes OCL to provide a nature/builder that auto-validates OCL embedded in Ecore or UML. This highlights some very poor functionality.)

Validating http://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.uml/model/oclstdlib.uml, which has hardly changed for many years, in the UML Model Editor shows about 70 errors

Most of these take the form "The opposite features 'uml::Classifier::feature' of 'oclstdlib::OclMessage' and 'uml::Feature::featuringClassifier' of 'oclstdlib::OclMessage::hasReturned' do not refer to each other"

a) Double-clicking on the problem in the Problems View navigates to oclstdlib::OclMessage rather than oclstdlib::OclMessage::hasReturned or even its unnamed return parameter.

b) The diagnostic is not appropriate since a Boolean return parameter is not a bidirectional reference.

eclipse-uml2-bot commented 6 hours ago

By Kenn Hussey on Jan 13, 2018 12:02

(In reply to comment #0)

(The new EAnnotationValidator support provokes OCL to provide a nature/builder that auto-validates OCL embedded in Ecore or UML. This highlights some very poor functionality.)

Validating http://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.uml/model/oclstdlib.uml, which has hardly changed for many years, in the UML Model Editor shows about 70 errors

Most of these take the form "The opposite features 'uml::Classifier::feature' of 'oclstdlib::OclMessage' and 'uml::Feature::featuringClassifier' of 'oclstdlib::OclMessage::hasReturned' do not refer to each other"

a) Double-clicking on the problem in the Problems View navigates to oclstdlib::OclMessage rather than oclstdlib::OclMessage::hasReturned or even its unnamed return parameter.

IIRC, this validation rule comes from EMF. It needed to pick one of the elements (on either side of the bi-directional relationship) and went with this one. I'm not sure how it could tell which of the two would be more relevent to the modeler...

b) The diagnostic is not appropriate since a Boolean return parameter is not a bidirectional reference.

The diagnostic refers to the relationship between the underlying UML elements, not to the boolean parameter (which is at a different metalevel). If you look in the properties view of the UML editor, check that 'oclstdlib::OclMessage' is listed as the featuring classifier of 'oclstdlib::OclMessage::hasReturned' and that 'oclstdlib::OclMessage::hasReturned' is listed as one of the features of 'oclstdlib::OclMessage'. Assuming 'hasReturned' is an owned attribute of 'OclMessage', I'm surprised that this should fail...

eclipse-uml2-bot commented 6 hours ago

By Ed Willink on Jan 13, 2018 13:59

(In reply to Kenn Hussey from comment #1)

Assuming 'hasReturned' is an owned attribute of

hasReturned is an Operation

eclipse-uml2-bot commented 6 hours ago

By Kenn Hussey on Jan 13, 2018 15:03

(In reply to comment #2)

(In reply to Kenn Hussey from comment #1)

Assuming 'hasReturned' is an owned attribute of

hasReturned is an Operation

OK, the same applies to owned operations. I wouldn't expect to see this validation problem if 'hasReturned' is an owned operation of 'OclMessage' (unless somehow the implementation of Classifier::feature has been modified by MessageType).