Method def on Abstract class causing non boolean invariant result

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 422583 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Nov 26, 2013 10:23 EDT | | Modified | May 25, 2015 17:21 EDT | | Reporter | Matt Eby |

Description

Here is my setup:

Eclipse Version\ Kepler\ 20130614-0229

Feature Version\ org.eclipse.ocl.examples.feature.group 3.3.1.v20130916-1423

I am experiencing a condition where calling a method on an abstract class from an invariant results in a non-boolean result. The snippet below should reproduce this condition. It seems this is a result of some recent changes. It works fine in 3.3.0.v20130611-1511 of the OCL feature.

import uml : 'http://www.eclipse.org/uml2/4.0.0/UML#/'

package uml

context Classifier\
\
  inv alwaysFail:\
    self.alwaysFalse()

  def: alwaysFalse() : Boolean = false\
  \

endpackage

[eclipse-ocl-bot]

By Ed Willink on Nov 26, 2013 11:26

Please provide a zipped project so that the way in which you observe the 'non-Boolean' result is clear.

[eclipse-ocl-bot]

By Matt Eby on Nov 26, 2013 11:52

Created attachment 237729 (attachment deleted)\ Zip with UML model that exploits the observed OCL behavior

Here is an attached project. I believe any model with an instance of any metaclass that is a Classifier would work.

[eclipse-ocl-bot]

By Ed Willink on Nov 27, 2013 02:23

You provide no instructions on how to observe your behaviour.

How do you create an instance of Classofier?

How do you invoke the constraint?

[eclipse-ocl-bot]

By Matt Eby on Nov 27, 2013 11:26

The attached model has a single instance of Class. I believe any concrete type that inherits from Classifier would also cause this problem. The OCL is also included in the attachment. If you load as a Complete OCL resource and validate it will evaluate to non-boolean.

[eclipse-ocl-bot]

By Ed Willink on Nov 27, 2013 11:38

OK. The repro

Load test.uml in the UML Model Editor\ Use Load Complete OCL Resource to load ocl_method_debug.ocl\ Validate

=> validation warning.

=====================

You have got confused by your polarities

def: alwaysFalse() : Boolean = false

always returns false so

inv alwaysFail: self.alwaysFalse()

always fails, whereas

inv alwaysFail: self.alwaysFalse() = false

is needed to always pass.

[eclipse-ocl-bot]

By Matt Eby on Nov 27, 2013 12:36

Thanks for checking into to this. I had been expecting the constraint to always fail. With 3.3.0.v20130611-1511 I was seeing a return of "false" as expected. With 3.3.1.v20130916-1423 I was seeing a non-boolean result.

I had another custom feature with custom plugins that we are developing. Once I removed that feature it is now evaluating to "false" as expected.

The plugins were for a custom DSL and I didn't believe they modified OCL or UML in any way. However, it seems I may have been mistaken. It is either a problem in our plugins or is a more complex interaction. Either way I'll provide an update once I figure it out.

[eclipse-ocl-bot]

By Ed Willink on Nov 27, 2013 12:41

Any accidental null navigation may result in invalid and everything then fails.

[eclipse-ocl-bot]

By Matt Eby on Dec 03, 2013 13:10

Created attachment 237971 Project with Steps and Screenshots

After some further investigation, I don't believe this has anything to do with the custom feature and I still believe it is a bug.

To avoid the polarities clouding the discussion I modified the ocl so it is expected to be true:

import uml : 'http://www.eclipse.org/uml2/4.0.0/UML#/'

package uml

context Classifier

  inv shouldPass:
    self.alwaysTrue()

  def: alwaysTrue() : Boolean = true

endpackage

I reproduced the issue by downloading a clean copy of Eclipse and captured screenshots along the way. Hopefully, this is detailed enough to help you reproduce the issue. Specifically, the unexpected result I am seeing is shown in 'step4_validate.png' while the result I would expect is shown in 'step8_validation_success.png'.

1) Download Eclipse Modeling Kepler SR1 Release http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/kepler/SR1/eclipse-modeling-kepler-SR1-win32-x86_64.zip

See: 
step1_clean_install_about_installation_details.png
step1_clean_install_about_screen.png

2) Install "OCL Tools" from: Help -> Install Modeling Components -> OCL Tools This installs version "3.3.1.v20130916-1423" of "OCL Examples and Editors"

See:
step2_install_ocl_tools.png
step2_install_ocl_tools_installation_details.png

3) Import attached project, Open test.uml, Load Complete OCL resource ocl_method_debug.ocl

See:
step3_load_complete_ocl_resource.png
step3_loaded_ocl.png

4) Validate. This returns 'OCL validation result of X is not boolean'. I would expect this to be true.

See:
step4_validate.png

5) Uninstall 'OCL Tools'

See:
step5_uninstall_ocl_tools.png
step5_uninstall_ocl_tools_installation_details.png

6) Install version "3.3.0.v20130611-1511" of "OCL Examples and Editors" from the 4.1.0 update site.
Install it as an local archive update site: "Help -> Install New Software... -> Add -> Archive" Choose the file "mdt-ocl-Update-tools-4.1.0.zip" which can be downloaded from:

http://www.eclipse.org/downloads/download.php?file=/modeling/mdt/ocl/downloads/drops/4.1.0/R201306101317/mdt-ocl-Update-tools-4.1.0.zip

See:
step6_choose_ocl_examples_and_editors.png
step6_install_4.1.0_of_ocl_tools.png
step6_install_4.1.0_of_ocl_tools_installation_details.png

7) Load model and OCL. Same as step 3

8) Validate. This returns 'Validation completed successfully'. This is what I expect.

See:
step8_validation_success.png

:compression: ocl_method_debug_w_screenshots.zip

[eclipse-ocl-bot]

By Ed Willink on Dec 04, 2013 02:32

Yes. It happens on 4.1.1 but not 4.1.0 or 4.2.0M3.

[eclipse-ocl-bot]

By Ed Willink on Dec 04, 2013 02:59

Unfortunately

commit fa6b23a4137b7e7c81cb2af1b65e9ac2aa6faeaa

got missed when the Bug 411154 fix was backported for SR1.

[eclipse-ocl-bot]

By Ed Willink on Dec 04, 2013 16:44

(In reply to Ed Willink from comment #10)

commit fa6b23a4137b7e7c81cb2af1b65e9ac2aa6faeaa

commit 5774bf3c1797b177bfccb061dda3351bfcb126f9 on edw/422583

commit 4805bfc6e91ad5ee3614f2c5ac49cc64c0393f12 tests it

Please review for SR2.

(Test pushed to master as commit 747f0429891e75e63aaadb92deb0427d3403a6d0)

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Dec 05, 2013 07:16

edw/422583 xtext cases fail for me, specifically in the mentioned new test case.

It looks like it also fails in master [1]

[1] https://hudson.eclipse.org/ocl/job/buckminster-ocl-core-luna-master/960/consoleFull

[eclipse-ocl-bot]

By Ed Willink on Dec 05, 2013 07:20

Yes. For some reason different Label providers are in use standalone/plugin so the detail of the tested constraint message varies. "Class UNamed" versus "< UNamed".

Fudge: make the expectation test context sensitive.

Fix: find out why the label providers are different.

[eclipse-ocl-bot]

By Ed Willink on Dec 05, 2013 10:21

(In reply to Ed Willink from comment #13)

Fudge: make the expectation test context sensitive.

Fix: find out why the label providers are different.

Plugin registrations install the UMLItemProvideAdapaterFactory, standalone doesn't.

Solution: use the same message generation i.e. DomainUtil.getLabel() for test message references.

---

Running the ValidateTests on EMF 2.10 (Luna rather than Kepler) fails because delegate diagnostic messages have improved. Therefore the Xtext tests plugin now has a 2.10.0 upper bound to detect this mismatch. Since MANIFEST.mf doesn't tolerate comments, a META-INF/ReadMe.txt explains.

---

Please review.

master now ok.

Doing a branch-tests fails; loads a Luna platform that hates explicitly Kepler EMF. Maybe the branch-tests (as a Kepler maintenance build) has to be an S-build to avoid newer Luna milestones conflicting with Kepler releases.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Dec 06, 2013 05:15

Created attachment 238108 Demostrating ScreeShot

TestCaseFailure.png

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Dec 06, 2013 05:19

I carry on the test case failure. See attachment

Can you confirm that Xtext (Standalone) test cases pass for you ?

If the branch-test jobs is giving you trouble, you could (temporarily) change the maintenance-branch job to fetch from your desired branch, and run an M-build. If they pass there, I guess it's my problem, although I'm simply testing your branch in a Kepler installation (Build id: 20130919-0819), so I can't figure out what I'm doing wrong.

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Dec 06, 2013 09:53

Aargh! Good detail in the snapshot.

I was actually testing on Luna M3 + OCL Maintenance + EMF Maintenance. And so oops: UML Luna M3. Once I switch to UML Maintenance (or a genuine Kepler) I see the same problem. Needs an extra line of init for the test.

At least this would have been caught by the Maintenance build.

Running the plugin tests on Kepler showed the failures that first appeared after moving to HIPP. Migrating the better Java compiler set up fixes it. Not clear why this sometimes worked.

Anyway now tests ok. Honest. Please review.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Dec 06, 2013 10:48

To be honest, that manifest.mf looks so different to Luna one, that looks worrying. In any case, it's a tests plugin so:

+1 to merge edw/422583 into origin/maintenance/R4_1

hint for master: If setting a tighter upper bound on EMF for Kepler is useful, why not doing the same (the next 2.11 version) for the Luna ?

Regards,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Dec 06, 2013 12:57

Thanks. Pushed to maintenance for 4.1.2.

Build available from downloads and updates.

[eclipse-ocl-bot]

By Ed Willink on May 25, 2015 17:21

CLOSED after more than a year in the RESOLVED state.