Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Operation, Instantiation and post clause: Invalid Class?(Got an Invalid Class instead of my parametrized class)
Operation, Instantiation and post clause: Invalid Class? [message #516383] Tue, 23 February 2010 14:48 Go to next message
Alexandre Torres is currently offline Alexandre Torres
Messages: 139
Registered: July 2009
Senior Member
Hi, I was testing the use of post clauses with my operation with MDT-OCL. I'm running against an EMF model created from an UML metamodel, exported as an ECORE and generated automatically by eclipse.

I defined in my metamodel class an operation called retrieveOrderForm:

context OrderWindow::retrieveOrderForm(o:small::domain::Order): OrderForm
post: result.date = o.date
post: result.customer = o.customer.name
post: result.order = o

This was inspired by the example in section 8.3.8 of OCL spec. The objective is instantiate an OrderForm object.
And it parsed and the operation worked! That was unexpected Smile
Great work folks Cool cooool
But I got a DynamicEObjectImpl with Invalid_Class as result.
Rolling Eyes
org.eclipse.emf.ecore.impl.DynamicEObjectImpl@105ef53 (eClass: org.eclipse.emf.ecore.impl.EClassImpl@905eba (name: Invalid_Class) (instanceClassName: null) (abstract: false, interface: false))

What happened ?
This was also unexpected Shocked , I did not expect the instantiation to work in the first place (that old dogma about ocl not producing side-effects), but this kind of puzzle me. Maybe it's a configuration issue? or I just called some undocumented feature? If so, any way around to instantiate objects with pure OCL?

initializing with
OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
and parsing ocl as a file.

thanks in advance.
Re: Operation, Instantiation and post clause: Invalid Class? [message #516389 is a reply to message #516383] Tue, 23 February 2010 15:17 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4012
Registered: July 2009
Senior Member
Hi Alexandre

There is no problem parsing your example.

MDT/OCL currently has no evaluation support for pre or postconditions,
so evaluation will have proceded and just ignored your post conditions.
I presume this is what you describe as 'working'. Eventually you try to
use the return value, which was not constructed so you got an Invalid Class.

OCL 2.2 does not support construction of arbitrary objects.

OMG Issue 13057 suggests introduction of type constructors. This might
happen for OCL 2.3 when I proptotype it and write up a resolution.

This would allow you perhaps to do

context OrderWindow::retrieveOrderForm(o:small::domain::Order) : OrderForm
body: result = OrderForm {date = o.date, customer = o.customer.name,
order = o }

Regards

Ed Willink


On 23/02/2010 19:48, Alexandre Torres wrote:
> Hi, I was testing the use of post clauses with my operation with
> MDT-OCL. I'm running against an EMF model created from an UML metamodel,
> exported as an ECORE and generated automatically by eclipse.
>
> I defined in my metamodel class an operation called retrieveOrderForm:
>
> context OrderWindow::retrieveOrderForm(o:small::domain::Order): OrderForm
> post: result.date = o.date post: result.customer = o.customer.name
> post: result.order = o
> This was inspired by the example in section 8.3.8 of OCL spec. The
> objective is instantiate an OrderForm object.
> And it parsed and the operation worked! That was unexpected :) Great
> work folks 8) cooool But I got a DynamicEObjectImpl with Invalid_Class
> as result.
> :roll: mailto:org.eclipse.emf.ecore.impl.DynamicEObjectImpl@105ef53
> (eClass: mailto:org.eclipse.emf.ecore.impl.EClassImpl@905eba (name:
> Invalid_Class) (instanceClassName: null) (abstract: false, interface:
> false))
>
> What happened ?
> This was also unexpected 8o , I did not expect the instantiation to work
> in the first place (that old dogma about ocl not producing
> side-effects), but this kind of puzzle me. Maybe it's a configuration
> issue? or I just called some undocumented feature? If so, any way around
> to instantiate objects with pure OCL?
>
> initializing with
> OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
> and parsing ocl as a file.
>
> thanks in advance.
>
Re: Operation, Instantiation and post clause: Invalid Class? [message #516400 is a reply to message #516389] Tue, 23 February 2010 15:31 Go to previous messageGo to next message
Alexandre Torres is currently offline Alexandre Torres
Messages: 139
Registered: July 2009
Senior Member
Yes, that was exactly what I thought, it should not be possible to instantiate in the current OCL 2.2 spec. But the spec itself has this strange example:

Parameter
The operation asProperty results in a property that has the same name, type, etc. as the parameter.
context Parameter::asProperty(): Property
pre: -- none
post: result.name = self.name
post: result.type = self.type
post: result.upperValue = 1
post: result.lowerValue = 1
post: result.isOrdered = true
post: result.isStatic = false
post: result.visibility = VisibilityKind::private

Looks like an instantiation to me Smile

Anyway I expected something like an exception "This feature exists only in your dreams" Wink so i got excited with an invalid_class...

Thanks for the ultra-fast answer.
Re: Operation, Instantiation and post clause: Invalid Class? [message #516419 is a reply to message #516400] Tue, 23 February 2010 16:07 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4012
Registered: July 2009
Senior Member
Hi Alexandre

Yes, for very simple classes the specification of behaviour can be
trivially interpreted as an instantiation. However consider

context MyCollection::sort() : OrderedSet(Element)

post: elements->forAll(e : Element | result->includes(e))

post: result->forAll(e : Element | elements->includes(e))

post: Sequence{1..(result->size()-1)})->forAll(i : Integer |
result->at(i) < result->at(i+1)

Where is the qsort/ripple sort/... algorithm?

regards

Ed Willink

On 23/02/2010 20:31, Alexandre Torres wrote:
> Yes, that was exactly what I thought, it should not be possible to
> instantiate in the current OCL 2.2 spec. But the spec itself has this
> strange example:
>
> Parameter
> The operation asProperty results in a property that has the same name,
> type, etc. as the parameter.
> context Parameter::asProperty(): Property
> pre: -- none
> post: result.name = self.name
> post: result.type = self.type
> post: result.upperValue = 1
> post: result.lowerValue = 1
> post: result.isOrdered = true
> post: result.isStatic = false
> post: result.visibility = VisibilityKind::private
>
> Looks like an instantiation to me :)
>
> Anyway I expected something like an exception "This feature exists only
> in your dreams" ;) so i got excited with an invalid_class...
>
> Thanks for the ultra-fast answer.
Previous Topic:Programatically Accessing OCL Comments
Next Topic:Single OCL constraint for multiple properties
Goto Forum:
  


Current Time: Wed Jul 30 07:27:33 EDT 2014

Powered by FUDForum. Page generated in 0.02427 seconds