search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

No support for UML custom primitive types #1512

Closed eclipse-ocl-bot closed 3 hours ago

eclipse-ocl-bot commented 3 hours ago

| --- | --- | | Bugzilla Link | 467192 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | May 13, 2015 06:11 EDT | | Modified | May 21, 2015 10:32 EDT | | See also | 467690 | | Reporter | Klaas Gadeyne |

Description

Created attachment 253433\ Demonstrates the bug

Mars Milestone 7 (4.5.0M7)\ OCL Examples and Editors SDK 6.0.0.v20150504-1704

Please consider the UML (papyrus) model in attachment. Trying to validate it (both in papyrus via "validate model", and in the UML model editor via "OCL -> validate") results in the following two (related) errors:

Error The 'Class1::Constraint3' constraint result is invalid for 'CustomPrimitiveTypes::InstanceSpecification1'

:compression: CustomPrimitiveTypes.zip

eclipse-ocl-bot commented 3 hours ago

By Ed Willink on May 13, 2015 12:49

You are on very dubious ground using inheritance with a user-defined PrimitiveType. PrimitiveTypes certainly do not have superclasses, which is what the pivot conversion supports, although they may have generals.

You are again on very dubious ground attempting to extend a built-in PrimitiveType such as Real. Equivalent concepts are all "final" in Java.

The UML2 project has a number of known Primitive types hidden behind e.g. UMLUtil.isReal() etc. The OCL Pivot support uses these, but also supports the Ecore::EDataType::instanceClassName stereotype and attribute.

Unfortunately the equivalent Ecore functionality is not used to exploit the instanceClassName as the behavioral type of the DataType.

eclipse-ocl-bot commented 3 hours ago

By Ed Willink on May 13, 2015 13:12

(In reply to Ed Willink from comment #1)

Unfortunately the equivalent Ecore functionality is not used to exploit the instanceClassName as the behavioral type of the DataType.

Branch ewillink/467192 re-uses the Ecore instanceClassName behavioralClass determination for stereotyped UML DataTypes (and of course PrimitiveTypes too).

eclipse-ocl-bot commented 3 hours ago

By Ed Willink on May 13, 2015 13:21

You are hitting what I consider to be one of the major deficiencies in UML. If time permits, OCL 2.5 may provide a stereotype to specify the numeric characteristics of DataTypes.

eclipse-ocl-bot commented 3 hours ago

By Klaas Gadeyne on May 13, 2015 13:32

(In reply to Ed Willink from comment #2)

(In reply to Ed Willink from comment #1)

Unfortunately the equivalent Ecore functionality is not used to exploit the instanceClassName as the behavioral type of the DataType.

Branch ewillink/467192 re-uses the Ecore instanceClassName behavioralClass determination for stereotyped UML DataTypes (and of course PrimitiveTypes too).

Great! I had already tried that approach before submitting the bug (should have mentioned this :-(

eclipse-ocl-bot commented 3 hours ago

By Klaas Gadeyne on May 13, 2015 14:50

(In reply to Ed Willink from comment #3)

You are hitting what I consider to be one of the major deficiencies in UML.

Are there any issues about that? The only one that came close when googling for "uml omg issues primitive type inheritance" was this one:

http://www.omg.org/issues/uml2-rtf.open.html#Issue19189

If time permits, OCL 2.5 may provide a stereotype to specify the numeric characteristics of DataTypes.

Thx! (the workaround using the eDatatype stereotype also WORKSFORME)

eclipse-ocl-bot commented 3 hours ago

By Ed Willink on May 14, 2015 02:42

(In reply to Ed Willink from comment #2)

Branch ewillink/467192 re-uses the Ecore instanceClassName behavioralClass determination for stereotyped UML DataTypes (and of course PrimitiveTypes too).

Pushed to master for RC1.

commit 975a802d9f4d404650da4e751e7a9ee6122c61fc

(In reply to Klaas Gadeyne from comment #5)

(In reply to Ed Willink from comment #3)

You are hitting what I consider to be one of the major deficiencies in UML.

Are there any issues about that? The only one that came close when googling for "uml omg issues primitive type inheritance" was this one:

The 'issue' is precision behavior. Inheritance is something I never considered.

Mellor's Executable UML had precision specifications so I was disappointed that they didn't appear in 2.0. When I asked a UML xF expert recently, ity apperared that this is indeed an unrecognised problem. Not even MARTE helps. There is only an increasingly obsolete profile that could have helped.

So we agreed that an OCL-provided profile could solve it. The profile would also provide do/do-not validate option for instance diagrams.

I'm struggling to find any written evidence of this.

eclipse-ocl-bot commented 3 hours ago

By Klaas Gadeyne on May 19, 2015 16:35

Created attachment 253567 Same model but stereotyped using the ecore profile

Hi Ed,

I tried to test the suggested approach using

OCL Examples and Editors SDK 6.0.0.v20150518-1816 org.eclipse.ocl.examples.feature.group Eclipse Modeling Project

and this attachment, but that doesn't seem to remedy the validation errors.

Am I missing something?

:compression: CustomPrimitiveTypes2.zip

eclipse-ocl-bot commented 3 hours ago

By Ed Willink on May 20, 2015 06:17

(In reply to Klaas Gadeyne from comment #7)

and this attachment, but that doesn't seem to remedy the validation errors.

wierd. WORKSFORME in a nested Eclipse, but not in unnested Eclipse.

(In reply to Ed Willink from comment #3)

If time permits, OCL 2.5 may provide a stereotype to specify the numeric characteristics of DataTypes.

OCLforUML.profile.uml is ready for testing. Might as well use your example as a test vehicle. Available as last commit on branch ewillink/467686 if you care to review.

eclipse-ocl-bot commented 3 hours ago

By Ed Willink on May 20, 2015 06:37

(In reply to Ed Willink from comment #8)

(In reply to Klaas Gadeyne from comment #7)

and this attachment, but that doesn't seem to remedy the validation errors.

wierd. WORKSFORME in a nested Eclipse, but not in unnested Eclipse.

Use "java.lang.Double" rather than "double". There seems to be a little vagueness as to whether "double" is a loadable class. Anyway your DataTypes are clearly going to be Java Objects so you should be using Double.

Bug 467690 raised to avoid the silent loss of the error.

eclipse-ocl-bot commented 3 hours ago

By Klaas Gadeyne on May 20, 2015 08:35

(In reply to Ed Willink from comment #9)

(In reply to Ed Willink from comment #8)

(In reply to Klaas Gadeyne from comment #7)

and this attachment, but that doesn't seem to remedy the validation errors.

wierd. WORKSFORME in a nested Eclipse, but not in unnested Eclipse.

Use "java.lang.Double" rather than "double". There seems to be a little vagueness as to whether "double" is a loadable class. Anyway your DataTypes are clearly going to be Java Objects so you should be using Double.

That does the trick indeed. Thanks!

eclipse-ocl-bot commented 3 hours ago

By Ed Willink on May 21, 2015 10:32

(In reply to Klaas Gadeyne from comment #10)

Use "java.lang.Double" rather than "double". There seems to be a little vagueness as to whether "double" is a loadable class. Anyway your DataTypes are clearly going to be Java Objects so you should be using Double.

"double" should work too now.(In reply to Ed Willink from comment #8)

(In reply to Klaas Gadeyne from comment #7)

If time permits, OCL 2.5 may provide a stereotype to specify the numeric characteristics of DataTypes.

OCLforUML.profile.uml is ready for testing. Might as well use your example as a test vehicle. Available as last commit on branch ewillink/467686 if you care to review.

Pushed to master for RC2.

An I-build is available at https://www.eclipse.org/downloads/download.php?file=/modeling/mdt/ocl/downloads/drops/6.0.0/I201505210935/mdt-ocl-Update-I201505210935.zip