eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[uml] Support InstanceValue #1442

Closed eclipse-ocl-bot closed 1 month ago

eclipse-ocl-bot commented 1 month ago

| --- | --- | | Bugzilla Link | 458394 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Jan 26, 2015 06:05 EDT | | Modified | Feb 18, 2016 08:52 EDT | | Reporter | Ed Willink |

Description

Bug 458326 highlights problems with M1/M2 InstanceSpecification validation.

On closer examination there is an additional validation needed for InstanceValues.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Jan 26, 2015 06:55

Bug 458326 has a heuristic fix that InstanceValues can probably do better for.

More extensive tests are needed.

Interesting cases: A stereotyped InstanceSpecification whose eClassifier is an InstnaceSpecification. Constraints on the stereotype and the instance should use different "slot" fields.

Round trip InstanceValue parent-child-parent returning to the same value.

Also the OCL ValidateMe stereotype.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 16, 2016 02:17

Created attachment 259768 Repro project.

The attached project from the "oclIsTypeOf() does not work as expected" papyrus newsgroup demonstrates a total failure to support use of InstanceValue in evaluation.

The InstanceSpecification constraint

self.Attribute1.classifier->union(self.Attribute2.classifier)->notEmpty()

looks plausible, but with the benefit of the Bug 400090 console enhancement, the onward navigation from Attribute1 is not available.

:compression: testOCL3.zip

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 16, 2016 05:13

(In reply to Ed Willink from comment #2)

self.Attribute1.classifier->union(self.Attribute2.classifier)->notEmpty()

looks plausible, but ... the onward navigation from Attribute1 is not available.

The problem is that ".classifier" is looked up in the type of "self.Attribute1" which is the model type of the InstanceSpecification which is BaseType not the metamodel type InstanceSpecification.

The metamodel level only constraint works fine:

let a1 = self.slot->select(definingFeature.name = 'Attribute1').value->any(true).oclAsType(InstanceValue).instance in\ let a2 = self.slot->select(definingFeature.name = 'Attribute2').value->any(true).oclAsType(InstanceValue).instance in\ a1.classifier = a2.classifier

If we are to evaluate this at the model level, perhaps

let a1 = self.Attribute1 in\ let a2 = self.Attribute2 in\ a1.umlClassifier() = a2.umlClassifier()

we could exploit a new ValueSpecification::umlClassifiers() overload that returns InstanceValue::instance.classifier rather than TypedElement::type. One for the UML RTF.

NB Evaluation at the model level is something that can be interesting to do in the OCL Console; it cannot be done as part of constraint validation.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 16, 2016 11:57

(In reply to Ed Willink from comment #3)

One for the UML RTF.

http://issues.omg.org/browse/UMLR-662

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 18, 2016 08:52

The activities for Bug 400090 and tests for Bug 487797 demonstrate that InstanceValues now work.