Take association as ConstrainedElement will cause Enumeration constraint failure

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 478416 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Sep 25, 2015 09:30 EDT | | Modified | Jun 11, 2021 09:09 EDT | | Version | 5.0.0 | | See also | 520440 | | Reporter | Yuwen Hu |

Description

Created attachment 256843\ MyModel and MyProfile files

We have a model (MyModel) which applied with a profile (MyProfile).\ In MyProfile, there is a Stereotype MyEnumeration which owned a Constraint (EnumConstraint) with below OCL "self.base_Enumeration.ownedLiteral->isUnique(specification.stringValue())".

In MyModel, we have to packages, MyMom and RootMom. \ In RootMom, we only have are RooClass.\ In MyMom, we define a class (MyMoClass), an Enumeration (MyEnum) applied with MyEnumeration, an Association (Root_To_Class) between RootClass and MyMoClass.\ And the last in MyMom is a Constraint (MyConstraint).

MyEnum only has one EnumerationLiteral (ONE).\ MyMoClass has an attribute (myWritableAttr) which type is MyEnum.\ MyConstraint has association Root_To_Class as ConstrainedElement.

That's it.

Now we load MyModel, and them run Validation.\ We will get validation error below.\ Severity Description Element Parent Type\ Error The 'MyEnumeration::EnumConstraint' constraint result is invalid for '«MyEnumeration»MyModel::MyMom::MyEnum'

• Failed to evaluate UML::InstanceSpecification::specification <> MyEnum MyModel::MyMom EMF Problem

If we remove association from MyConstraint, then validation will success.\ We doubt that, it seems OCL Pivot UML cause this problem.

:compression: AssociationAsConstraintedElement.zip

[eclipse-ocl-bot]

By Ronan Bar on Sep 25, 2015 10:08

This bug is found in OCL 5.0.4 used in combination with Papyrus 1.0.2 on Luna SR2

[eclipse-ocl-bot]

By Ed Willink on Sep 25, 2015 10:49

New test case demonstrates that problem still exists. (ewillink/478416).

[eclipse-ocl-bot]

By Ed Willink on Sep 25, 2015 11:05

Immediate problem is a CCE from missing support for a reference to an Association as a Constraint.constrainedElement.

Losing the reference to the conversion and dodging the failed-to-convert warning and the JUnit test passes.

The Constraint is a Package constraint, which is not defined for OCL, though it is on the to-do list as a way to avoid spurious all-instance Class constraints.

The Constraint is not an OCL constraint; the language is "Optionality", so OCL should have ignored it altogether.

[eclipse-ocl-bot]

By Ronan Bar on Sep 25, 2015 11:35

Hi Ed,\ Yes we were surprised something in a constraint with a lanaguage set to something other than "OCL" could cuase an OCL evaluation error.

Ed does your test case still fail if you move the constarint somewhere else? i.e. Context is not Package. I'm currently testing this.

[eclipse-ocl-bot]

By Ed Willink on Sep 25, 2015 11:37

(In reply to Ed Willink from comment #3)

The Constraint is not an OCL constraint; the language is "Optionality", so OCL should have ignored it altogether.

No. Ignore for OCL execution, but not ignore for conversion to Pivot.

---

The Pivot representation reifies unnavigable opposites so that Associations are redundant and are discarded by the UML2AS conversion.

However an explicit reference to an Association should be handled by creating an AssociationClass. Adding the lazy AssociationClass creation fixes the problem.

... and introduces new bug opportunities wrt the AssociationClass. Not a candidate for a maintenance release.

---

To do:

AssociationClass should have an isImplicit property to distinguish lazy Associations.

AssociationClass.unownedAttributes should be unownedProperties.

---

To resolve:

The real issue here is that the UML2AS conversion failed for 'wacky' UML. Non-OCL bodied constraints are an example of the opportunity for unexpected content. UML2AS must be robust here.

[eclipse-ocl-bot]

By Ronan Bar on Sep 25, 2015 12:05

Hi Ed,\ This issue does not seem to arrise if I move the Constraint into another element (for example nested inside an Association) so that the context is not Package. Can you confirm in your test case?

[eclipse-ocl-bot]

By Ronan Bar on Sep 25, 2015 12:23

It seems the work around is to have the Constraint context set to an element which doesn't have OCL associated to it, via a profile application, that causes a triggering of the buggy code.

[eclipse-ocl-bot]

By Ed Willink on Sep 25, 2015 12:55

Today you need to avoid a reference to unexpected classes from context where the manual UML2AS converts Constraints. So yes under an Association should work.

The manual UML2AS is not advancing significantly, since the intent is to move to an OCL-defined auto-generated UML2AS that should then be solid rather than pragmatic. (Using the CS2AS bridge technology to be presented on Monday at the MODELS OCL workshop.)

[eclipse-ocl-bot]

By Ed Willink on Sep 27, 2015 18:53

(In reply to Ed Willink from comment #5)

... and introduces new bug opportunities wrt the AssociationClass. Not a candidate for a maintenance release.

For maintenance purposes, it is probably safest to just ignore rather than barf on Constraint.constrainedElements that fail to convert to a Pivot representation. This accommodates the reported Association case and any other wacky Constraint.constrainedElements that arise.

commit 82641a4f2354fcc8fdca054b6d6ada31b453e4df pushed to maintenance/r5_0

available as http://www.eclipse.org/modeling/download.php?file=/modeling/mdt/ocl/downloads/drops/5.0.5/N201509271821/mdt-ocl-Update-N201509271821.zip

[eclipse-ocl-bot]

By Ed Willink on Sep 27, 2015 18:58

commit 430efc13cddbc4987541f7970de491c23f862e39 pushed to maintenance/R6_0 for Mars.2

[eclipse-ocl-bot]

By Ed Willink on Sep 27, 2015 19:56

The safer ignore conversion failures is probably better for master for now.

commit 88e04c61393fa4296bbab596484c863a6a778111 pushed to master for M2

[eclipse-ocl-bot]

By Ronan Bar on Sep 28, 2015 09:43

Hi Ed,\ Thanks for the prompt build. The ignore option suits us very well. We have tested the solution and it works. Our users will be using this shortly but I don't expect any issues. Enjoy Models Conf!

BTW I agree an auto-generated UML2AS would probably be alot more robust as we have hit alot of these type of pivot issues which are very hard to debug.

[eclipse-ocl-bot]

By Ed Willink on Jun 11, 2021 09:09

This test case is causing me grief with the new Validity Analysis for OCL.

self.base_Enumeration.ownedLiteral->isUnique(specification.stringValue())

is rubbish in many ways.

"specification" may be null so "specification.stringValue()" may be invalid causing the whole thing to crash.

The above could be accommodated by an an extra select(specification <> null) filter, but what does it mean? InstanceSpecification.specification is [0..1] and for an EnumerationLiteral I would expect null, unless the user has chosen to assign explicit values.

---

This idiom seems to occur in multiple tests so maybe e can take the opportunity to use a different rewrite towards plausiblity each time.

a) ->select(specification <> null)->isUnique(specification.stringValue())

b) additional constraint

self.base_Enumeration.ownedLiteral->forAll(specification <> null)

c) variant body

->isUnique(if specification <> null then specification.stringValue() else toString() endif)