Add support for implicit EObject operations / attributes

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 152003 | | Status | CLOSED FIXED | | Importance | P3 enhancement | | Reported | Jul 27, 2006 10:28 EDT | | Modified | May 27, 2011 02:41 EDT | | Version | 1.0.0 | | Reporter | Ian Bull |

Description

Since all EMF Objects extend EObject, you should be able to say self.eContainer() or self.eContents(), etc... Currently you must explicitly make all your objects extend EObject for this to work. It is unclear if this violates any of the OCL Spec, but for the EMF implementation it would be very useful.

[eclipse-ocl-bot]

By Ian Bull on Jul 27, 2006 19:27

Created attachment 46918 (attachment deleted)\ A first try at the Extended Ecore Environment

This adds some extended ecore support for OCL through a new ExtendedEcoreEnvironment. I don't think this is how the final version should look, but it gives some something to go from.

I don't like the fact tht it changes the NullEnvironment in the ValidationVisitor. I had to change this slightly because the NullEnvironment extended Ecore Environment and now it has to extend Extended Ecore Environment.

[eclipse-ocl-bot]

By Ian Bull on Jul 27, 2006 19:31

Created attachment 46919 (attachment deleted)\ Ok, This is the real patch :)

I had the description on my clipboard and that got submitted. Ignore that first patch :)

[eclipse-ocl-bot]

By Ian Bull on Jan 26, 2007 19:48

Christian, do you have any thoughts on this?

[eclipse-ocl-bot]

By Ed Merks on Dec 20, 2007 08:41

Support for basic things like eContainer() seems quite important. After all, all modeled object are expected to support containment and hence have a container even if it's not explicitly modeled. Explicitly modeling container references is often a bad idea since the same object could be contained in dozens or more different containers...

[eclipse-ocl-bot]

By Christian Damus on Dec 20, 2007 08:53

Yes, eContainer() is basic in the EMF API, but it doesn't exist in the model as far as OCL is concerned. OCL doesn't expose MOF's reflection capabilities such as container() because UML doesn't merge the Reflection package, and neither does EMOF (corresponding to the two OCL flavours, CompleteOCL and EssentialOCL).

However, MDT's OCL implementation is targeted at EMF-based metamodels. So, it would be nice to support this via parsing options that make it clear to a client that their OCL constraints will not be portable or compliant. If either Ian or Ed is interested in implementing this, I'm interested in accepting the contribution.

[eclipse-ocl-bot]

By Ed Merks on Dec 24, 2007 15:28

Created attachment 85798 (attachment deleted)\ A stab in the dark.

I really know next to nothing how this is all supposed to work, but I gather it would make sense to be able to specify a classifier that acts as an implicit base so there's an option for that. In Ecore terms, it would only make sense to specify an EClass and it would only make sense to specify one that has no structural features since features need to be explicit in the model. So I only specialized the code for getting all the operations; I think it will generate duplicates if there is already a explicit extension of EObject. In terms of UML, I don't really know how to limit it to apply only for "classes" not "data types"; I don't even know how to ensure that for Ecore...

So this is just a wild stab in the dark and I'd need some feedback about the direction I'm going...

[eclipse-ocl-bot]

By Christian Damus on Jan 28, 2008 11:13

Created attachment 88027 Expansion of Ed's patch

Thanks, Ed, for making the effort to get a resolution under way!

I like the idea of an implicit root class; this nicely parallels the "root extends class" concept in the genmodel. I agree, also, that it should be used only with classes and not with data types.

I'm not worried about duplicates. If the model already explicitly extends the class, then either the option shouldn't be used, or the worst that will happen is that lists end up longer than they need to be.

I figure there's no harm in applying this also for attributes. If there are any attributes in the implicit root class, then the client will have to provide an evaluation environment that knows how to access them, otherwise evaluation will fail.

I have attached an update of Ed's patch with the following changes:

• rename the option as an "implicit root class" because it should only be used with classes
• check, when fetching the option value, that it is a class
• apply the option also in TypeUtil::getAttributes(...)
• don't duplicate attributes/operations when the 'owner' argument is the implicit root class
• apply the option also in TypeUtil::commonSupertype(...) to return the implicit root class as the common supertype of two Classes that are otherwise unrelated
• apply the option also in TypeUtil::getRelationship(...) to return the appropriate relationship between the implicit root class and other classes in the model
• added JUnit tests using Ecore

I would like one or both of Ed and Ian to look over my changes and indicate a '+' in the review flag if you like it. I aim to commit this for the Wednesday 30 Jan integration build.

:notepad_spiral: bug152003.patch

[eclipse-ocl-bot]

By Christian Damus on Jan 30, 2008 08:24

Patch is committed to CVS HEAD (1.2 branch).

[eclipse-ocl-bot]

By Christian Damus on Feb 06, 2008 21:02

Fix available in HEAD: 1.2.0.I200802062000.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:39

Closing after over a year in verified state.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:41

Closing after over a year in verified state.