[library] Sharing AnyType operations by OCL PredefinedTypes in oclstdlib.ecore

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 189657 | | Status | CLOSED WONTFIX | | Importance | P3 normal | | Reported | May 29, 2007 09:16 EDT | | Modified | May 29, 2012 13:24 EDT | | Version | 1.1.0 | | Reporter | Adolfo Sanchez-Barbudo Herrera |

Description

AnyType operations should be accesible by all predefined types (except CollectionType and TupleType). They are all defined in every PredefinedTypes in the oclstdlib.ecore metamodel.

Newsgroup discussion at the following link:

http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.ocl/msg00321.html

[eclipse-ocl-bot]

By Christian Damus on May 29, 2007 11:46

We should investigate in the 1.2 release whether these operations can be normalized without breaking compatibility and references to the redundant operation definitions.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jul 11, 2007 06:35

Hi Christian,

I have decided to start with the oclstdlib improvement to facility extensibility.

I have planned this changes in several phases. I want to comment to you the first one. This is the safer phase, where the oclstdlib would be in the same state, but it would have changes in the way of its creation. The idea is decoupling the creation of operations in the shadow classes.

The first problem that we have is that the public static methods createXXXXTypeOperations in the OCLStandardLibraryUtil class are all createAnyOperations dependant.

So we should split the creation of this operations, in the following way.

OCLStandardLibraryUtil:

Supressing the addition of anyOperations in every createIntegerOperation, createStringOperation, etc.

OCLStandarLibraryImpl (Ecore and UML):

Adding the operations in two steps to every shadow class. Firstly adding createXXXXXXOperation and secondly createAnyOperation.

In this step, we are in the same state having the commented problem but it's a needed and safer step.

The only problem that we could have with this patch is that createXXXXXoperations are puclic methods from the OCLStandardLibraryUtil Class, and i m unknown if thery are intended to be used from clients (it will be if want extensibility). In this case, when calling lonely the createXXXXXXOperation method, the AnyOperation would not be added to the corresponding shadow class :. In this case this phase could not be taken in this way, and we would need to take additional considerations. For example, keeping the original coupled methods createXXXXXOperation, and creating new ones for having a decoupled creation of the operations.

Finally i should comment that we have the same problems with the collection operations, where the sequence, set, bag, orderedSet operations are dependant of the collection operations. So in this phase we will have the same job for this kind of types.

[eclipse-ocl-bot]

By Christian Damus on Jul 11, 2007 12:26

(In reply to comment #2)

Great! I am excited about your contribution!

It may be worth noting that the creation of a stdlib via the factory utilities is only done once in the implementation of a new metamodel binding (or other instance of the stdlib, such as for your QVT extension). Thereafter, it would normally be loaded from the serial form.

Removing the creation of the OclAny operations from the other factory methods makes perfect sense. And yes, it behooves us to retain the current implementations (probably @deprecated) and add new API for the OclAny-less variants.

And, indeed, the collection types have the identical issue of repeating the definitions of inherited operations.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jul 12, 2007 06:26

Hi again Christian !!!

I have found a new issue when i was testing the OMStdLib. In this ocassion, with the dependency between UMLReflectionImpl and the OCLStandardLibraryImpl, specifically in the private method getOCLTypeFor.

I think that the better solution, is creating a new factory method in the UMLReflection API since we have the method asOCLType aswell. For example:

protected OCLStandardLibrary getOCLStandardLib();

So your UMLReflectionImpl will call to your OCLStandardLibraryImpl instance, and i'll extend your UMLReflectionImpl overwriting the factory method to call to my OMStandardLibraryImpl instance.

Again, the UMLReflectionImpl for Ecore and UML Metamodel binding should be modified too.

¿Is it all right about this ?

Im modifiying the ocl project in my local WS, as soon as i have all in order i will send you all the modified classes ;)

[eclipse-ocl-bot]

By Christian Damus on Jul 12, 2007 08:39

That sounds reasonable. Whenever your changes are ready, just create a patch that encompasses all of them and attach it to this bugzilla. I can take it from there.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Jul 23, 2007 05:35

Created attachment 74334 (attachment deleted)\ Files modified to facility the extension of the OCLStandardLibrary

Hi Christian.\ I send you a zip file with the files which have been modified.\ I encourage you to read the "OCL Contribution Notes.txt" file firstly!!!!

I have included a file with a resume of the changes made, too ;)

We could continue discussing about that notes and the problems encountered in the files.

I have not added anything about contribution information, im newbie in this kind of tasks, and i hope that you could give some guides about it. What kind of information im allowed to include, where i must do it, etc.

Best regards,\ Adolfo ;).

P.D: My apologies if i dont have send you what i should, or if it has not been done in the correct way. As i mentioned, it is my first contribution :P

[eclipse-ocl-bot]

By Christian Damus on Nov 22, 2007 12:26

Hi, Adolfo.\ The attachment isn't a patch, but rather replacements for files. Would you mind reworking it as a CVS patch? Also, I see that there are no changes to the oclstdlib.(ecore|uml) files. This is just the first phase, right? Changing the utilities that construct the stdlib models?

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Nov 23, 2007 03:25

(In reply to comment #7)

Hi, Adolfo. The attachment isn't a patch, but rather replacements for files. Would you mind reworking it as a CVS patch?

Yeah, that was my first "newbie" "contribution". Right now, i know how to do it so i 'll upload a properly patch. The next week i'll take the QVTo work again, and i'll start with this bug, ok?

Also, I see that there are no changes to the oclstdlib.(ecore|uml) files. This is just the first phase, right? Changing the utilities that construct the stdlib models?

Yes, the "first phase". It was a little refactoring of the factory methods so it could be extended and used by the QVToStdLib.

We should have some discussion about this OclStdLib implementation, because i was intuituively extending that oclstdlib.ecore and building a qvtoperationalstdlib.ecore. But some time ago, i realized that i was wrong. qvtoperationalstdlib, should be an QVToperational::library. So it will be a QVTo "M1" model, it means, an instance of the QVToperational M2 metamodel, that should be accesible by all transformations. So, i dont exactly know how im going to build a formal QVToperational library using your oclstdlib.ecore "model".

Anyway, the next week when i work with it again, and have a refresh about all of this, we could talk about it.

Regards,\ Adolfo

[eclipse-ocl-bot]

By Christian Damus on Nov 23, 2007 07:28

Great! Thanks, Adolfo.

I don't know much about QVT, but the OCL Standard Library is an instance (M1) of the OCL metamodel (M2), in the same fashion as you indicate QVT requires. I imagine I shall learn much from our discussion.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Nov 23, 2007 08:48

(In reply to comment #9)

Great! Thanks, Adolfo.

I don't know much about QVT, but the OCL Standard Library is an instance (M1) of the OCL metamodel (M2), in the same fashion as you indicate QVT requires. I imagine I shall learn much from our discussion.

Yes that's what i think it should be, so i expected to have an ocltstdlib.oclecore resource representing the standard library. But anyway, i'll think about it with all my documentation in my hand, i'm probably mixing the meta-levels. They are only some fast-ideas to think and work on.

Greetings !!!!!!

Adolfo

[eclipse-ocl-bot]

By Victor Sanchez on Nov 26, 2007 11:37

Excerpt from a request/suggestion posted in the newsgroups:

Concerning this bug, I have a request to make. From what I understand

from the OCL specification, all predefined types can be considered as\ subclasses of OCLAny. Since we have shadow classes (Ecore 'EClass'es) in\ the oclstdlib.ecore and the Primitive Types in UML contain the\ 'generalization' or 'general' (I'm not sure as to which must be used,\ provided it isn't both simultaneously) associations both inherited from\ 'Classifier', wouldn't it be beneficial to take advantage of inheritance\ relationships between types in the OCL standard library as defined in the\ project? This would naturally propagate AnyType operations to other types\ (except for the predefined collections, which would follow their own\ independent inheritance hierarchy). A simpler example would consist of\ making the Integer_Class to inherit from Real_Class (in conformance to\ what the OCL specification states in section 11.4.1), so it would have\ visibility to all the operations defined in Real_Class and only has to\ redefine its own. This only affects the metamodel and I don't have any\ idea what impact it could have upon the code in the OCL project that\ manages this part. I could consult Adolfo about it to make sure that he\ already has these considerations in mind, if you want.

Christian's answer:

Yes, this design resulted originally from the fact that EDataTypes in Ecore\ cannot declare generalization relationships, and all of this was originally\ implemented via EDataTypes before the library was serialized as a resource. \ The shadow classes certainly should have these generalization\ relationships. The problem, of course, is that all of the user model types\ also specialize OclAny, which of course cannot be done literally and has\ conceptual issues, anyway (many classifiers in UML, such as interfaces and\ artifacts, are not permitted to specialize a Class).

[eclipse-ocl-bot]

By Victor Sanchez on Nov 26, 2007 12:19

(In reply to comment #11)

The purpose of this comment would be to tighten the definition of the OCL standard library by adding inheritance relationships as defined in the OCL specification. This, in turn, would bring the library a step closer to the possibility of eliminating operation duplicates spread over multiple types. It would also make the processing of OCL instances more consistent, natural, and would perhaps result in some little interesting simplifications, for instance, in the development of a QVT execution engine.

Additionally, as Christian cleverly points out, there is a problem with user model types also specializing OclAny which cannot benefit of adding inheritance connections. But it seems to me that they won't be much affected by rearrangements made upon inheritance relationships of the OCL standard library types.

[eclipse-ocl-bot]

By Christian Damus on Nov 26, 2007 12:35

(In reply to comment #12)

Additionally, as Christian cleverly points out, there is a problem with user model types also specializing OclAny which cannot benefit of adding inheritance connections. But it seems to me that they won't be much affected by rearrangements made upon inheritance relationships of the OCL standard library types.

Right. That remark was really just to point out that we have a bit of an incongruity in the type system that is inescapable. It should have no bearing on any refactoring of the standard library.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Dec 19, 2007 08:59

Created attachment 85556 Patch to provide the OCL Standard Library Extension

This is a first phase in order to get a successful extension of the OCL Standard Library. This patch doesn't take into account the related improvement of the actual StandarLibrary (sorry Victor :( ), but surely safes versions compatibility.

Sumarizing the patch:

1. Refactoring OCLStandardLibraryUtil in order to decouple the creation (in fly) of the OCLTypes operations.
2. Supressing the dependency between UMLReflectionImpl (UML and Ecore) and the concret implementation of the OCLStdLib.
3. Moving UMLReflectionImpl (Ecore version) to an accesible package (As UML does) so it can be extended.

Note 1: It calls my attention, that UMLReflection has been implemented in a different way (UML and Ecore implementations). While the former is public and instantiable with an UMLEnvironment parameter, the later is a private singleton. By this reason, the point 2 implementation for UML and Ecore UMLReflectionImpl have been made in different ways too.

I have not worked with the UML version, so im not sure of its intenttion. About the Ecore one, its reasonable to be singleton, and it is not a problem for me. But i need that it is public, so i can extend it, and override the method which returns my QVToStdLib.

Note 2: I have not included a necessary change, that is having accesible the OCLStdLibImpls. Besides, it will probably be needed to extend that classes to reuse functionality when creating an extension of the OCL Standard Library.

Cheers !!!

:notepad_spiral: oclstdlib_OCL_1_2_M4.txt

[eclipse-ocl-bot]

By Ed Willink on Jun 26, 2010 09:59

The model-driven standard library and pivot model will significantly revise these utility functions.

The existing functionality will be deprecated, so the emphasis will be on maintaining API compatibility rather than enhancement.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:58

Closing WONTFIXes.

[eclipse-ocl-bot]

By Ed Willink on May 29, 2012 13:24

Closing all bugs resolved in Indigo.