[pivot-uml] Introduce oclBase()/oclExtension() and so support unapplied stereotype extension interrogation.

eclipse-ocl-bot commented 2 months ago

| --- | --- | | Bugzilla Link | 580143 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 13, 2022 05:48 EDT | | Modified | Jun 20, 2022 06:36 EDT | | Blocks | 580204, 580212 | | See also | 580136, 580140, 580177, Gerrit change 194287, Gerrit change 194289, Gerrit change 194290, Gerrit change 194291, Gerrit change 194292, Gerrit change 194293, Git commit f36ab60d | | Reporter | Ed Willink |

Description

https://www.eclipse.org/forums/index.php?t=msg&th=1110949&goto=1852956&#msg_1852956

reports that in

import 'platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore'\ import 'platform:/plugin/org.eclipse.uml2.uml.profile.standard/model/Standard.ecore'

package UML

context Operation

def: hasCreateStereo(): Boolean = self.extension_Create->notEmpty()

endpackage

extension_Create is not found. When I try it I get

Multiple markers at this line

The 'PropertyCallExp::CompatibleResultType' constraint is violated\ for 'self.oclBadProperty'
Unresolved Property 'UML::Operation::extension_Create'
The 'PropertyCallExp::NonStaticSourceTypeIsConformant' constraint\ is violated for 'self.oclBadProperty'
The 'CallExp::TypeIsNotInvalid' constraint is violated for\ 'self.oclBadProperty'

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Jun 13, 2022 06:40

A JUnit test based on testLoad_Fruit_ocl demonstrates the primary error:

junit.framework.AssertionFailedError: Load failed\ 8:40: Unresolved Property 'UML::Operation::extension_Create'\ \ Using test_stereotypesBug431638() to investigate how "extension..." properties are created hits the same problem. There must be a magic setup to make 'ordinary' stereotype extensions work.

The reported problem is with UML itself for which eager creation of every possible Stereotype applied to every possible Class seems like an unpleasant O(N*N) cost that very few users need. Maybe it's deliberately bypassed. Maybe a lazy optimization never got exercised.

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Jun 13, 2022 07:17

(In reply to Ed Willink from comment #1)

There must be a magic setup to make 'ordinary' stereotype extensions work.

Red herring: test_stereotypes_Bug431638() is badly coded. It relies on a preceding test to have done UMLStandaloneSetup.init() (and createOCLWithProjectMap() rather than createOCL()).

Using test_stereotypesBug431638() to investigate how "extension..." properties are created

The "extension_..." properties are sensibly created as each Extension association in the user model is converted to its normalized Pivot equivalent by UML2AS. So only for actual usages avoiding the O(N*N) hazard. For the case of the UML model there are no Extension associations to convert so the property is indeed missing.

The bug is therefore my claim that e.g. self.extension_Create->notEmpty() can be used to test whether the Create Stereotype has been applied.

Options:

a) retract the claim and force OCL users to fall back on the UML2 Java API.

b) lazily create a transient property in the Pivot model as each unapplied Stereotype is interrogated.

a) is unhelpful so b)

Pedantically we should semi-eagerly create the transient property for all possible extensions if the user provokes a completion assist.

Propabably needs two different variants of getAllProperties() to distinguish whether all possible transient extension properties are created.

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Jun 13, 2022 07:31

(In reply to Ed Willink from comment #2)

The bug is therefore my claim that e.g. self.extension_Create->notEmpty() can be used to test whether the Create Stereotype has been applied.

This problem goes away once we support

self.oclExtensions(Standard::Create)->notEmpty()

since an operation can easily handle the missing case without the need for UML's horrible stylized semantically rich base/extension property names. We also avoid the need to resort to a qualified navigation in the event that the Stereotype name is ambiguous wrt multiple Packages.

Looking like WONTFIX. Introducing a heap of transient properties rather than the better solution doesn't make sense. Does any user want to see the return from allProperties() bloated by an almost certainly useless entry for every possible unapplied Stereotype?

We can perhaps suggest use of oclExtensions() when a missed property access startsWith "extension_".

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Jun 13, 2022 07:49

(In reply to Ed Willink from comment #3)

Looking like WONTFIX. Introducing a heap of transient properties rather than the better solution doesn't make sense. Does any user want to see the return from allProperties() bloated by an almost certainly useless entry for every possible unapplied Stereotype?

No. But it is the reasonable interpretation of the OMG UML specification.

We should lazily create transient properties to comply with the specification and provide diagnostics to recommend use of the less costly oclExtensions(X).

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Jun 13, 2022 09:53

(In reply to Ed Willink from comment #4)

We should lazily create transient properties to comply with the specification.

properties that are transient, rather than properties whose values are transient.

But how do these properties exist?

In principle these are at the metalevel and so their value is immutably known at compile time allowing the missing extension access to be optimised to null at compile time. However Eclipse UML2 provides an apply/unapply profile capability so it would be unhelpful to require the OCL to be reloaded/regenerated after each profile reconfiguration.

The OCL may is therefore parsed after the applicable stereotypes are known but before the applied stereotypes are known. Ambiguities are therefore stable and statically determinate. The parsed OCL AS must be persistable so the PropertyCallExp must refer to owned serializable properties. What owns them?

Dynamically growing the partial class to accommodate its extensions of interest is undesirable, so we should add an additional for-transients-partial class to the complete class in which the transients are owned, but excluded from allProperties(). Perhaps the implicit opposite property should also be in this for-transients-partial class. The for-transients-partial class is ultimately part of the Orphanage requiring load-time unification / save-time replication just like Sets and Tuples.

This is getting a bit unpleasant. Let's find out why Bug 580140 falls apart first blocking the clean oclExtensions() solution via Bug 580136 .

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Jun 13, 2022 10:12

(In reply to Ed Willink from comment #3)

This problem goes away once we support
self.oclExtensions(Standard::Create)->notEmpty()

So let's just redefine "extension_YYY" as (deprecated) syntax sugar, for "oclExtensions(XXX::YYY)" if isMany, or for "oclExtension(XXX::YYY)" if !isMany.

Bye bye transient property problems. Bye bye two competing solutions. The CS2AS syntax sugar mapping is easy. Full round-trip AS2CS will need an Operation::isProperty flag to identify the sugaring.

?? Ditto for implicit opposites. "oclOppositeOf(XXX::YYY)". ??

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Jun 16, 2022 02:52

(In reply to Ed Willink from comment #6)

?? Ditto for implicit opposites. "oclOppositeOf(XXX::YYY)". ??

Moved to Bug 580177.

eclipse-ocl-bot commented 2 months ago

By Ed Willink on Jun 18, 2022 11:12

(In reply to Ed Willink from comment #6)

So let's just redefine "extension_YYY" as (deprecated) syntax sugar, for "oclExtensions(XXX::YYY)" if isMany, or for "oclExtension(XXX::YYY)" if !isMany.

Done oclBase() / oclBase(XXX) return the / the conformant stereotyped class.

isMany dependence is unpleasant so allw the user to choose singular / plural oclExtension(XXX) / oclExtensions(XXX) / oclExtensions().

CS2AS syntax sugar mapping is easy.

Not so easy. The erroneous declaration of extension_XXX gets in the way and should go away once the ongoing rework of ststics completes. Bug 580204 therefore handles the syntax sugar follow ups.

This bug just introduces the new library operations.

eclipse-ocl-bot commented 2 months ago

Jun 20, 2022 02:52

New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/194287

eclipse-ocl-bot commented 2 months ago

Jun 20, 2022 02:52

New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/194289

eclipse-ocl-bot commented 2 months ago

Jun 20, 2022 02:52

New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/194290

eclipse-ocl-bot commented 2 months ago

Jun 20, 2022 02:52