[uml] InstanceSpecification/Instance navigation confusion

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 458326 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Jan 24, 2015 06:38 EDT | | Modified | Jan 26, 2015 17:37 EDT | | Reporter | Ed Willink |

Description

Bug 452621#c19 provides an example in which validation of a stereotype applied to an InstanceSpecification fails with "'Collection' rather than 'OclVoid' value required".

The problem is that the InstanceSlotNavigationProperty strategy is used for the dynamic content of an M1 class rather than the ordinary ExplicitNavigationProperty for the simple owned property of an M2 class.

The wrong strategy returns null for no-such-slot; hence the diagnosis.

Simple fix of checking whether the referenced Property is an InstanceSpecification fixes the bug, but probably stores up an opportunity for some very obscure M1 evaluation bugs.

Need a better way to distinguish whether X.slot is M1/M2.

[eclipse-ocl-bot]

By Ed Willink on Jan 24, 2015 07:44

(In reply to Ed Willink from comment #0)

Need a better way to distinguish whether X.slot is M1/M2.

The problem stems from the fundamental:

Parsing an OCL constraint requires the type of self.

Evaluating an OCL constraint requires the value of self.

Some general purpose routines 'helpfully' accept a vague contextElement as self and treat it as the value of self and determine its type in order to parse. This leads to the M1/M2 ambiguity as code becomes meta-level-polymorphic. Most of these ambiguities have been eliminated for Mars. Just need to cleanup UMLOCLEValidator.validateSyntax that is executing its constraint on the 'type' requiring evaluation to do magic things.

[eclipse-ocl-bot]

By Ed Willink on Jan 24, 2015 10:02

I think the error may be failure to detect slot in

context MyStereotype\ inv: self.base_InstanceSpecification.slot ...

as an unresolved property. Should perhaps be oclType().slot.

[eclipse-ocl-bot]

By Ed Willink on Jan 26, 2015 04:21

(In reply to Ed Willink from comment #2)

Should perhaps be oclType().slot.

No.

An InstanceSpecificationImpl has two different usages at M1.

As the base of a Stereotype, a constraint on the Stereotype may constrain the InstanceSpecificationImpl via self.base_'StereotypeName' and the value being constrained is an instance of InstanceSpecification and so has an InstanceSpecification::slot M2 property that may be navigated.

As the instantiator of a Classifier, a constraint on the Classifier may constrain the InstanceSpecificationImpl's instance via self and the value being constrained is an instance of the Classifier and so has a 'ClassifierName'::'PropertyName' M1 property that may be navigated.

---

The parsing is relatively straightforward since we deal with types and all the objects exist.

Evaluation is troublesome since the objects for the M2 navigation exist, but not those for the M1 navigation. Using the InstanceSpecificationImpl as a kind of proxy for the missing M1 object causes the bug by occluding the regular use for M2 navigation.

The 'bad' M1 evaluation occurs through a single invocation path: UMLOCLEValidator.validateSyntax with a non-null instance, so that is where the conflicting M1 behavior must be separated.

[eclipse-ocl-bot]

By Ed Willink on Jan 26, 2015 06:14

(In reply to Ed Willink from comment #3)

The 'bad' M1 evaluation occurs through a single invocation path: UMLOCLEValidator.validateSyntax with a non-null instance, so that is where the conflicting M1 behavior must be separated.

Perhaps we signal the variant behaviour by creating a distinctive Object instantiating an Instance class. UML has just such a class: an InstanceValue.

Oops. Papyrus has no support for InstanceValue although Eclipse UML does.

Given a simple model of Libraries and Books with colors and prices, my reading of UML is that we might have a RedBook InstanceSpecification that partially defines instances with a red color, while a particular InstanceValue of that InstanceSpecification could add a specific price.

Referred values must be InstanceValues and so aBook.library can be instantiated by InstanceValues but not by InstanceSpecifications.

So we need to validate both InstanceSpecification and InstanceValue against the constraints of their instantiated classifiers.

The problem of validating an InstanceSpecification is this bug. InstanceValues are Bug 458394.

[eclipse-ocl-bot]

By Ed Willink on Jan 26, 2015 06:18

(In reply to Ed Willink from comment #4)

Oops. Papyrus has no support for InstanceValue although Eclipse UML does.

Bug 458395

[eclipse-ocl-bot]

By Ed Willink on Jan 26, 2015 06:50

(In reply to Ed Willink from comment #4)

Perhaps we signal the variant behaviour by creating a distinctive Object instantiating an Instance class. UML has just such a class: an InstanceValue.

Yes. Once Bug 458394 provides InstanceValue validation, we can just create an InstanceValue of the InstanceSpecification for the distinctive validation.

However introducing a new model class such as InstanceValue is too much change for a maintenance release, so in the interim the following heuristic in ImplementationManager.getPropertyImplementation should adequately distinguish.

An InstanceSpecification whose containing package is the UML metamodel is an M2 usage and so the normal ExplicitNavigationProperty is appropriate to exploit InstanceSpecification::slot.

Any other InstanceSpecification is an M1 usage for which InstanceSlotNavigationProperty is appropriate to access the slots and instantiate defaults from the instantiated classifiers.

[eclipse-ocl-bot]

By Ed Willink on Jan 26, 2015 17:37

(In reply to Ed Willink from comment #6)

An InstanceSpecification whose containing package is the UML metamodel is an M2 usage and so the normal ExplicitNavigationProperty is appropriate to exploit InstanceSpecification::slot.

No the InstanceSpecification is always part of the UML metamodel.

The PropertyCallExp is within a Profile for M2 usage, in a Model/Package for M1. This is accurate and pushed to master for M5.

The accurate heuristic involves too much API change for maintenance, so a slightly flawed called-property is in UML for M2, not UML for M1. The flaw is that an InstanceSpecification whose classifier is a UML class rather than a user class will malfunction. So ok for diagrams explaining user models. No good for diagrams explaining UML. Pushed to maintenance for SR2.