Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » [OCLinEcore] Resolving attributes in OCL Constraints(Resolving attributes across package boundaries)
[OCLinEcore] Resolving attributes in OCL Constraints [message #551134] Thu, 05 August 2010 11:26 Go to next message
Missing name Mising name is currently offline Missing name Mising nameFriend
Messages: 6
Registered: July 2010
Junior Member
Hi,

I have a problem with the OCLinEcore-Editor. The editor is not able to resolve attributes in OCL Constraints if the attribute is specified in a different package than the OCL Constraint.

I attached two examples:

-----WORKING EXAMPLE----------------------------------------------------------------------
-- This is the working example.
------------------------------------------------------------------------------------------
import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';

package tutorial : tut = 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial'
{
  class NamedElement
  {
    attribute name : String;
  }
  class Parameter extends NamedElement
  {
  	property _'signature'#parameters : Signature[1];
  }
  class Signature 
  {
  	invariant parameterMustHaveUniqueNames: self.parameters->isUnique(p:Parameter | p.name); 
	property parameters#_'signature' : Parameter[0..*] { composes };
  }
}


-----NOT WORKING----------------------------------------------------------------------
-- This does not work. The reference p.name in the OCL constraint cannot be resolved. 
-- For 'name', the OCLinEcore Editor shows the following error: 
-- "Couldn't resolve reference to NamedElementCS 'name'".
------------------------------------------------------------------------------------------
import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';

package tutorial : tut = 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial'
{
  package core : cre = 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial/core' {
	class NamedElement
	{
	  attribute name : String;
	}	
  }
  class Parameter extends core::NamedElement
  {
    property _'signature'#parameters : Signature[1];
  }
  class Signature 
  {
    invariant parameterMustHaveUniqueNames: self.parameters->isUnique(p:Parameter | p.name); 
    property parameters#_'signature' : Parameter[0..*] { composes };
  }
}


(If these examples are copied to a bugzilla bug report, I would be really glad if my email address is NOT cited....)

Thank you very much!
Kind Regards.
Re: [OCLinEcore] Resolving attributes in OCL Constraints [message #551222 is a reply to message #551134] Thu, 05 August 2010 16:11 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi Fabian

Thanks. This looks like a variant of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=321171 that yoiu reported
last week.

Sorry about the email pasting; if you raised bugzillas for bugs that
you've done such a good job of demonstrating, I wouldn;t need to
identify the origin.

Regards

Ed Willink


On 05/08/2010 12:26, fabianbrosig@gmx.de wrote:
> I attached two examples:
>
> -----WORKING
> EXAMPLE----------------------------------------------------- -----------------
>
> -- This is the working example.
> ------------------------------------------------------------ ------------------------------
>
> import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';
>
> package tutorial : tut =
> 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial'
> {
> class NamedElement
> {
> attribute name : String;
> }
> class Parameter extends NamedElement
> {
> property _'signature'#parameters : Signature[1];
> }
> class Signature {
> invariant parameterMustHaveUniqueNames:
> self.parameters->isUnique(p:Parameter | p.name); property
> parameters#_'signature' : Parameter[0..*] { composes };
> }
> }
>
> -----NOT
> WORKING----------------------------------------------------- -----------------
>
> -- This does not work. The reference p.name in the OCL constraint cannot
> be resolved. -- For 'name', the OCLinEcore Editor shows the following
> error: -- "Couldn't resolve reference to NamedElementCS 'name'".
> ------------------------------------------------------------ ------------------------------
>
> import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';
>
> package tutorial : tut =
> 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial'
> {
> package core : cre =
> 'http://www.eclipse.org/mdt/ocl/oclinecore/tutorial/core' {
> class NamedElement
> {
> attribute name : String;
> }
> }
> class Parameter extends core::NamedElement
> {
> property _'signature'#parameters : Signature[1];
> }
> class Signature {
> invariant parameterMustHaveUniqueNames:
> self.parameters->isUnique(p:Parameter | p.name); property
> parameters#_'signature' : Parameter[0..*] { composes };
> }
> }
Re: [OCLinEcore] Resolving attributes in OCL Constraints [message #551241 is a reply to message #551222] Thu, 05 August 2010 17:17 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi Fabian

> Thanks. This looks like a variant of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=321171 that yoiu reported
> last week.

Very similar, but in a different source file, so raised as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=321903 where you can find
a patch.

Thanks for the excellent repro.

Regards

Ed Willink
Re: [OCLinEcore] Resolving attributes in OCL Constraints [message #552993 is a reply to message #551134] Sun, 15 August 2010 19:37 Go to previous messageGo to next message
William Robinson is currently offline William RobinsonFriend
Messages: 1
Registered: August 2010
Junior Member
In CompleteOCL Edit in Eclipse 3.6, I have a very similar error message for an OCL def (definition). Even within the same context, the def name cannot be resolved. See this simple example:

context AnyType
def: x: Integer = 1
inv test: x = 1

There error is: Couldn't resolve reference to NamedElementCS 'x'.

I notice that the distributed example has the same error commented out.
See RoyalAndLoyal.ocl, line 211:

--inv invariant_noEarnings2 :
-- programs.isSaving implies account->isEmpty()

The example refers to programs, where its type defines (using def) isSaving. Uncommenting the original invariant shows the same error.
Use of def's is common for complex OCL. I hope this can be fixed soon. Now, I still using QVT's OCL editor!
Re: [OCLinEcore] Resolving attributes in OCL Constraints [message #552994 is a reply to message #552993] Sun, 15 August 2010 20:22 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi W

The plan was to migrate the M2M/QVTd editor to MDT/OCL for Helios, but
we hit very late IP problems because IMP has not been through a release
review. We therefore had to do a late redevelopment using Xtext. This
will be much better, but currently it has only partial functionality.
The main Xtext emphasis was on OCLinEcore to support the OCL delegates.
It is hopefully more complete. Complete OCL is sort of just there.

It is intended to produce an MDT/OCL 3.1.0 release in October in time
for Eclipse Summit Europe. I hope the Xtext editors will be more
comprehensive at that point.

Sorry for the trouble. Certainly if you're happy with the M2M/QVTd
editor stick with it.

Regards

Ed Willink

On 15/08/2010 20:37, wrobinson@gsu.edu wrote:
> In CompleteOCL Edit in Eclipse 3.6, I have a very similar error message
> for an OCL def (definition). Even within the same context, the def name
> cannot be resolved. See this simple example:
>
> context AnyType
> def: x: Integer = 1
> inv test: x = 1
>
> There error is: Couldn't resolve reference to NamedElementCS 'x'.
>
> I notice that the distributed example has the same error commented out.
> See RoyalAndLoyal.ocl, line 211:
>
> --inv invariant_noEarnings2 :
> -- programs.isSaving implies account->isEmpty()
>
> The example refers to programs, where its type defines (using def)
> isSaving. Uncommenting the original invariant shows the same error.
> Use of def's is common for complex OCL. I hope this can be fixed soon.
> Now, I still using QVT's OCL editor!
>
Re: [OCLinEcore] Resolving attributes in OCL Constraints [message #753898 is a reply to message #552994] Sun, 30 October 2011 11:59 Go to previous messageGo to next message
chuck  is currently offline chuck Friend
Messages: 160
Registered: July 2010
Senior Member
Hi....i'm using essentialocl in my grammar and I receive the same error ... how to fix it?
Re: [OCLinEcore] Resolving attributes in OCL Constraints [message #753919 is a reply to message #753898] Sun, 30 October 2011 15:18 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
On 30/10/2011 11:59, chuck wrote:
> Hi....i'm using essentialocl in my grammar and I receive the same
> error ... how to fix it?
It cannot be the same error since

https://bugs.eclipse.org/bugs/show_bug.cgi?id=321171#c4

claims that it was fixed in 3.0.1 and 3.1.0.

If you have a new error please raise a Bugzilla with a simple repro.

Regards

Ed Willink
Re: [OCLinEcore] Resolving attributes in OCL Constraints [message #753920 is a reply to message #753919] Sun, 30 October 2011 15:27 Go to previous messageGo to next message
chuck  is currently offline chuck Friend
Messages: 160
Registered: July 2010
Senior Member
hi Edward ... this is my grammar snippet on ocl...

Filter:
"#" specification=SpecificationCS

;

SpecificationCS returns essentialocl::ExpSpecificationCS:
ownedExpression=ExpCS | exprString=UNQUOTED_STRING
;


terminal UNQUOTED_STRING: // Never forward parsed; just provides a placeholder
'£$%^£$%^' // for reverse serialisation of embedded OCL
;

trying to type an ocl expression like:

# self.name

i receive: Couldn't resolve reference to NamedElement 'name'.
Re: [OCLinEcore] Resolving attributes in OCL Constraints [message #753924 is a reply to message #753920] Sun, 30 October 2011 16:18 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4188
Registered: July 2009
Senior Member
Hi

Please read the replies that you receive.

I wrote:

"claims that it was fixed in 3.0.1 and 3.1.0.

If you have a new error please raise a Bugzilla with a simple repro. "

You have failed to

a) identify that you are using 3.0.1 and 3.1.0.
b) raise a Bugzilla
c) provide a repro

A repro is something that can be reproduyced with a minimal amount of
effort.

Just about all your queries require significant development and
telepathy to interpret.

It is clear that you are attempting to do something way beyond your
capabilities.

Please attempt to learn the facilities of Eclipse gradually. You cannot
hope to start by tackling extension of code that is not ready for
extension when you have no familiarity with OCL, Xtext, EMF, Eclipse or
even debugging.

Would you try to learn biology and chemistry by studying the human
genome as your first example?

Regards

Ed Willink


On 30/10/2011 15:27, chuck wrote:
> hi Edward ... this is my grammar snippet on ocl...
>
> Filter: "#" specification=SpecificationCS
> ;
>
> SpecificationCS returns essentialocl::ExpSpecificationCS:
> ownedExpression=ExpCS | exprString=UNQUOTED_STRING
> ;
>
>
> terminal UNQUOTED_STRING: // Never forward parsed; just provides a
> placeholder
> '£$%^£$%^' // for reverse serialisation of
> embedded OCL ;
>
> trying to type an ocl expression like:
>
> # self.name
> i receive: Couldn't resolve reference to NamedElement 'name'.
Re: [OCLinEcore] Resolving attributes in OCL Constraints [message #754014 is a reply to message #753924] Mon, 31 October 2011 13:17 Go to previous message
chuck  is currently offline chuck Friend
Messages: 160
Registered: July 2010
Senior Member
I opened a new bug...(if it's a bug)...like you suggested me... i was trying to learn and the forum is also a good tool to do it..
kind regards
Previous Topic:describe mutiple classes as OCL
Next Topic:real sum approximation problem
Goto Forum:
  


Current Time: Sun Dec 21 16:47:37 GMT 2014

Powered by FUDForum. Page generated in 0.01828 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software