Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Expressions involving undefined values
Expressions involving undefined values [message #483730] Wed, 02 September 2009 18:17 Go to next message
Adrian Price is currently offline Adrian Price
Messages: 57
Registered: July 2009
Member
Good day mdt.ocl,

Many of our OCL constraints involve complex chained expressions referencing
modelled features and query operations, any part of which could be
undefined.

According to "OCL 2.0 Specification ptc/2005-06-06" Paragraph 7.4.11 (?)
"Undefined Values":
"Some expressions will, when evaluated, have an undefined value. For
instance, typecasting with oclAsType() to a type that the object does not
support or getting the ->first() element of an empty collection will result
in undefined. In general, an expression where one of the parts is undefined
will itself be undefined..." However, in practice I see
NullPointerExceptions when such expressions are evaluated. For example:

inv inParamControlDisabled: let opposite : Bindable =
getInboundValueBinding()->first().getOppositeEndpoint(self).target in
enabled.value and opposite.oclIsKindOf(Parameter) implies
opposite.oclAsType(Parameter).inout <> InOutType::IN

throws NPE if getInboundValueBinding() returns an empty list, apparently as
a result of attempting to using Java reflection APIs to invoke the
getOppositeEndpoint() method on a null reference. At present the only way
around this is to make the OCL expressions self-null-checking, which
obviously makes them more complicated than the spec. suggests they need be,
less readily comprehensible and (presumably) less performant.

Is my understanding of the OCL spec. flawed or is this a bug?

Thanks in advance,

Adrian Price
Senior Architect
TIBCO Software, Inc.
Re: Expressions involving undefined values [message #483761 is a reply to message #483730] Wed, 02 September 2009 20:20 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4097
Registered: July 2009
Senior Member
Hi Adrian

The OCL 2.0 specification was never consistenly updated to redefine the
'undefined' value as the 'null' and the 'invalid' functionality. Most
of the MDT-OCL behaviour can be justified by one of the many
contradictory statements in the specification; though NPEs can never be
right. Please submit your example as a Bugzilla and we'll fix it.

I posted a substantive revised text to resolve 'null' and 'invalid' as
http://www.omg.org/issues/ocl2-rtf#Issue14197. We are working to have an
unambiguous specification and an implementation compliant with it.

The corresponding rationalisation of invalid/Invalid/OclInvalid was
applied to CVS HEAD yesterday as part of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=282882.

We are currently resolving a variety of areas where the treatment of
null and invalid is not quite right.

Issue 14197 is our best guess at what is correct and we might have
it implemented by M3 or perhaps M4.

For now I'm afraid you just need to do excess empirical testing.

Regards

Ed Willink


Adrian Price wrote:
> Good day mdt.ocl,
>
> Many of our OCL constraints involve complex chained expressions referencing
> modelled features and query operations, any part of which could be
> undefined.
>
> According to "OCL 2.0 Specification ptc/2005-06-06" Paragraph 7.4.11 (?)
> "Undefined Values":
> "Some expressions will, when evaluated, have an undefined value. For
> instance, typecasting with oclAsType() to a type that the object does not
> support or getting the ->first() element of an empty collection will result
> in undefined. In general, an expression where one of the parts is undefined
> will itself be undefined..." However, in practice I see
> NullPointerExceptions when such expressions are evaluated. For example:
>
> inv inParamControlDisabled: let opposite : Bindable =
> getInboundValueBinding()->first().getOppositeEndpoint(self).target in
> enabled.value and opposite.oclIsKindOf(Parameter) implies
> opposite.oclAsType(Parameter).inout <> InOutType::IN
>
> throws NPE if getInboundValueBinding() returns an empty list, apparently as
> a result of attempting to using Java reflection APIs to invoke the
> getOppositeEndpoint() method on a null reference. At present the only way
> around this is to make the OCL expressions self-null-checking, which
> obviously makes them more complicated than the spec. suggests they need be,
> less readily comprehensible and (presumably) less performant.
>
> Is my understanding of the OCL spec. flawed or is this a bug?
>
> Thanks in advance,
>
> Adrian Price
> Senior Architect
> TIBCO Software, Inc.
>
>
Re: Expressions involving undefined values [message #483844 is a reply to message #483761] Thu, 03 September 2009 11:21 Go to previous messageGo to next message
Adrian Price is currently offline Adrian Price
Messages: 57
Registered: July 2009
Member
Hi Ed,

Many thanks for the response and detailed explanation. I myself had found
the OCL spec. rather confusing as to the semantics of undefined / invalid /
null and your proposed revisions offer some reassurance that it wasn't just
me being slow on the uptake.

I'm putting together a JUnit test case to illustrate the problems I've seen,
will post to here and Bugzilla when complete. BTW the JUnit is not so
straightforward since OCL does not have a syntax for declaring an empty
explicitly typed collection literal. For example (using classes from the
Ecore package for convenience) none of: OrderedSet(EClass)->first(),
OrderedSet(EClass){}->first(), OrderedSet()->first() or
OrderedSet{}->first() appear to be valid OCL. BTW the production
CollectionLiteralExpCS ::= CollectionTypeIdentifierCS '{'
CollectionLiteralPartsCS? '}' permits an empty element list but for the
fourth example in the previous sentence MDT/OCL throws the parser exception
"Argument is null, expected a List".

Thanks & regards,

Adrian.

"Ed Willink" <ed@willink.me.uk> wrote in message
news:h7mk2f$p27$1@build.eclipse.org...
> Hi Adrian
>
> The OCL 2.0 specification was never consistenly updated to redefine the
> 'undefined' value as the 'null' and the 'invalid' functionality. Most
> of the MDT-OCL behaviour can be justified by one of the many contradictory
> statements in the specification; though NPEs can never be right. Please
> submit your example as a Bugzilla and we'll fix it.
>
> I posted a substantive revised text to resolve 'null' and 'invalid' as
> http://www.omg.org/issues/ocl2-rtf#Issue14197. We are working to have an
> unambiguous specification and an implementation compliant with it.
>
> The corresponding rationalisation of invalid/Invalid/OclInvalid was
> applied to CVS HEAD yesterday as part of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=282882.
>
> We are currently resolving a variety of areas where the treatment of
> null and invalid is not quite right.
>
> Issue 14197 is our best guess at what is correct and we might have
> it implemented by M3 or perhaps M4.
>
> For now I'm afraid you just need to do excess empirical testing.
>
> Regards
>
> Ed Willink
>
>
> Adrian Price wrote:
>> Good day mdt.ocl,
>>
>> Many of our OCL constraints involve complex chained expressions
>> referencing modelled features and query operations, any part of which
>> could be undefined.
>>
>> According to "OCL 2.0 Specification ptc/2005-06-06" Paragraph 7.4.11 (?)
>> "Undefined Values":
>> "Some expressions will, when evaluated, have an undefined value. For
>> instance, typecasting with oclAsType() to a type that the object does not
>> support or getting the ->first() element of an empty collection will
>> result in undefined. In general, an expression where one of the parts is
>> undefined will itself be undefined..." However, in practice I see
>> NullPointerExceptions when such expressions are evaluated. For example:
>>
>> inv inParamControlDisabled: let opposite : Bindable =
>> getInboundValueBinding()->first().getOppositeEndpoint(self).target in
>> enabled.value and opposite.oclIsKindOf(Parameter) implies
>> opposite.oclAsType(Parameter).inout <> InOutType::IN
>>
>> throws NPE if getInboundValueBinding() returns an empty list, apparently
>> as a result of attempting to using Java reflection APIs to invoke the
>> getOppositeEndpoint() method on a null reference. At present the only way
>> around this is to make the OCL expressions self-null-checking, which
>> obviously makes them more complicated than the spec. suggests they need
>> be, less readily comprehensible and (presumably) less performant.
>>
>> Is my understanding of the OCL spec. flawed or is this a bug?
>>
>> Thanks in advance,
>>
>> Adrian Price
>> Senior Architect
>> TIBCO Software, Inc.
Re: Expressions involving undefined values [message #484003 is a reply to message #483844] Thu, 03 September 2009 20:45 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4097
Registered: July 2009
Senior Member
Hi Adrian

Yes, not being able to type an empty Collection has caught me out too.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=288569 raised to remind me
to raise an OMG issue one day to allow OrderedSet(EClass){}.

I don't understand your parser exception on

OrderedSet{}->first()

It parses fine. It just evaluates incorrectly to a Java null rather than
an OCL invalid. https://bugs.eclipse.org/bugs/show_bug.cgi?id=288566 raised.

Regards

Ed Willink

Adrian Price wrote:
> Hi Ed,
>
> Many thanks for the response and detailed explanation. I myself had found
> the OCL spec. rather confusing as to the semantics of undefined / invalid /
> null and your proposed revisions offer some reassurance that it wasn't just
> me being slow on the uptake.
>
> I'm putting together a JUnit test case to illustrate the problems I've seen,
> will post to here and Bugzilla when complete. BTW the JUnit is not so
> straightforward since OCL does not have a syntax for declaring an empty
> explicitly typed collection literal. For example (using classes from the
> Ecore package for convenience) none of: OrderedSet(EClass)->first(),
> OrderedSet(EClass){}->first(), OrderedSet()->first() or
> OrderedSet{}->first() appear to be valid OCL. BTW the production
> CollectionLiteralExpCS ::= CollectionTypeIdentifierCS '{'
> CollectionLiteralPartsCS? '}' permits an empty element list but for the
> fourth example in the previous sentence MDT/OCL throws the parser exception
> "Argument is null, expected a List".
>
> Thanks & regards,
>
> Adrian.
>
> "Ed Willink" <ed@willink.me.uk> wrote in message
> news:h7mk2f$p27$1@build.eclipse.org...
>> Hi Adrian
>>
>> The OCL 2.0 specification was never consistenly updated to redefine the
>> 'undefined' value as the 'null' and the 'invalid' functionality. Most
>> of the MDT-OCL behaviour can be justified by one of the many contradictory
>> statements in the specification; though NPEs can never be right. Please
>> submit your example as a Bugzilla and we'll fix it.
>>
>> I posted a substantive revised text to resolve 'null' and 'invalid' as
>> http://www.omg.org/issues/ocl2-rtf#Issue14197. We are working to have an
>> unambiguous specification and an implementation compliant with it.
>>
>> The corresponding rationalisation of invalid/Invalid/OclInvalid was
>> applied to CVS HEAD yesterday as part of
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=282882.
>>
>> We are currently resolving a variety of areas where the treatment of
>> null and invalid is not quite right.
>>
>> Issue 14197 is our best guess at what is correct and we might have
>> it implemented by M3 or perhaps M4.
>>
>> For now I'm afraid you just need to do excess empirical testing.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> Adrian Price wrote:
>>> Good day mdt.ocl,
>>>
>>> Many of our OCL constraints involve complex chained expressions
>>> referencing modelled features and query operations, any part of which
>>> could be undefined.
>>>
>>> According to "OCL 2.0 Specification ptc/2005-06-06" Paragraph 7.4.11 (?)
>>> "Undefined Values":
>>> "Some expressions will, when evaluated, have an undefined value. For
>>> instance, typecasting with oclAsType() to a type that the object does not
>>> support or getting the ->first() element of an empty collection will
>>> result in undefined. In general, an expression where one of the parts is
>>> undefined will itself be undefined..." However, in practice I see
>>> NullPointerExceptions when such expressions are evaluated. For example:
>>>
>>> inv inParamControlDisabled: let opposite : Bindable =
>>> getInboundValueBinding()->first().getOppositeEndpoint(self).target in
>>> enabled.value and opposite.oclIsKindOf(Parameter) implies
>>> opposite.oclAsType(Parameter).inout <> InOutType::IN
>>>
>>> throws NPE if getInboundValueBinding() returns an empty list, apparently
>>> as a result of attempting to using Java reflection APIs to invoke the
>>> getOppositeEndpoint() method on a null reference. At present the only way
>>> around this is to make the OCL expressions self-null-checking, which
>>> obviously makes them more complicated than the spec. suggests they need
>>> be, less readily comprehensible and (presumably) less performant.
>>>
>>> Is my understanding of the OCL spec. flawed or is this a bug?
>>>
>>> Thanks in advance,
>>>
>>> Adrian Price
>>> Senior Architect
>>> TIBCO Software, Inc.
>
>
Previous Topic:object mapping during evaluation
Next Topic:custom operators and functions using model information
Goto Forum:
  


Current Time: Fri Oct 24 10:27:48 GMT 2014

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

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