Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » About OCL name expressions
About OCL name expressions [message #53836] Tue, 15 April 2008 09:16 Go to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo HerreraFriend
Messages: 254
Registered: July 2009
Senior Member
Hi Christian,

Working around the new EValidator infraestructure I have noticed that
now OCLExpressions may not have a name, and the validator doesn't
complain about that, That's good ;). However, when there is a problem
with an OCLExpression itself, the produced message is not clear (a null
name appears for the unnamed OCLExpressions)

I suggest you overriding getName method from OCLExpressionImpl.
Something like this:

/* (non-Javadoc)
* @see org.eclipse.emf.ecore.impl.ENamedElementImpl#getName()
*/
@Override
public String getName() {
String name = super.getName();
return (name == null) ? eClass().getName() : name;
}

If you considere it, I could arise an enhancement feature for that ;).

Cheers,
Adolfo.
Re: About OCL name expressions [message #53861 is a reply to message #53836] Tue, 15 April 2008 13:22 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

I'm afraid I don't understand the problem. If the validator doesn't
complain about an OCLExpression not having a name, then why would it
produce a message? Or, do you mean for other problems that may be
reported?

In any case, I don't think that the metaclass name makes sense as a name for
an element. Keep in mind that the client of the Diagnostician can provide
an EValidator::SubstitutionLabelProvider to customize the string
representation of objects in the problem messages. You might use that to
substitute, say, the un-parsed expression text (probably part of it only,
truncated by an ellipsis) for OCLExpressions.

Cheers,

Christian


Adolfo Sánchez-Barbudo Herrera wrote:

> Hi Christian,
>
> Working around the new EValidator infraestructure I have noticed that
> now OCLExpressions may not have a name, and the validator doesn't
> complain about that, That's good ;). However, when there is a problem
> with an OCLExpression itself, the produced message is not clear (a null
> name appears for the unnamed OCLExpressions)
>
> I suggest you overriding getName method from OCLExpressionImpl.
> Something like this:
>
> /* (non-Javadoc)
> * @see org.eclipse.emf.ecore.impl.ENamedElementImpl#getName()
> */
> @Override
> public String getName() {
> String name = super.getName();
> return (name == null) ? eClass().getName() : name;
> }
>
> If you considere it, I could arise an enhancement feature for that ;).
>
> Cheers,
> Adolfo.
Re: About OCL name expressions [message #53884 is a reply to message #53861] Tue, 15 April 2008 14:57 Go to previous messageGo to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo HerreraFriend
Messages: 254
Registered: July 2009
Senior Member
Hi Christian,

Sorry for my bad explanations and my poor knowledge about EValidator
framework;P. Maybe an example would have helped, I'll will explain my
concrete example:

I have a Metaclass VariableInitExp ( -> ImperativeExpression ->
OCLExpression) with a required reference called referredVariable. If
this referredVariable is not set in an instance of it, the Validator
throws the following message error:

Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
required feature 'referredVariable' of
'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody:: <null>'
must be set

This "<null>" value is due to the absence of a name for the
OCLExpression (in this case VariableInitExp). I agree that a lot of
expressions don't need a name, but the main reason for that is that the
own expression is meaningful to identify it, so I think that its
metaclass's name could make sense for all of them...

So, for the previous case we could have the following report:

Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
required feature 'referredVariable' of
'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody::VariableInitExp'
must be set

So when getting the name of every VariableInitExp instance, we could
obtain a proper identifying name. Note that when persisting to a
resource, the name is not serialized since the name is not set at all
(I'm not sure if I have been clear :S).

Besides, if you look at the error reporting, OperationBody is included
as the name for OperationBody's instance (However, it's is not a
NamedElement). I'm not sure of that, but probably this is the policy
(taking its MetaClass name) for all elements which are not NamedElements ...

Anyway for this concrete purpose, perhaps I could achieve a better error
reporting from the validator, making use of that
SubstituionLabelProvider, as you mention. As I said you I'm a newbie
trying to configure the validation of models for a concrete metamodel,
so I don't have a good point to get the better way to solve the problems
with it.

Anyway, a bugzilla enhancement will probably be needed since the OCL
EValidator will not properly report the problems concerning unnamed
OCLExpressions. So it's a problem which will need to be solved.

Cheers,
Adolfo.





Christian W. Damus escribió:
> Hi, Adolfo,
>
> I'm afraid I don't understand the problem. If the validator doesn't
> complain about an OCLExpression not having a name, then why would it
> produce a message? Or, do you mean for other problems that may be
> reported?
>
> In any case, I don't think that the metaclass name makes sense as a name for
> an element. Keep in mind that the client of the Diagnostician can provide
> an EValidator::SubstitutionLabelProvider to customize the string
> representation of objects in the problem messages. You might use that to
> substitute, say, the un-parsed expression text (probably part of it only,
> truncated by an ellipsis) for OCLExpressions.
>
> Cheers,
>
> Christian
>
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>
>> Hi Christian,
>>
>> Working around the new EValidator infraestructure I have noticed that
>> now OCLExpressions may not have a name, and the validator doesn't
>> complain about that, That's good ;). However, when there is a problem
>> with an OCLExpression itself, the produced message is not clear (a null
>> name appears for the unnamed OCLExpressions)
>>
>> I suggest you overriding getName method from OCLExpressionImpl.
>> Something like this:
>>
>> /* (non-Javadoc)
>> * @see org.eclipse.emf.ecore.impl.ENamedElementImpl#getName()
>> */
>> @Override
>> public String getName() {
>> String name = super.getName();
>> return (name == null) ? eClass().getName() : name;
>> }
>>
>> If you considere it, I could arise an enhancement feature for that ;).
>>
>> Cheers,
>> Adolfo.
>
Re: About OCL name expressions [message #53905 is a reply to message #53884] Tue, 15 April 2008 15:21 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Adolfo,

I see. Where did the qualified name come from in the error message? Is
that provided by the default substitution-label provider in the
diagnostician?

The problem with providing a non-null default name is that, unless it is
actually specified as the default in the Ecore model (the OCLExpression
EClass), it will be written out when an expression is serialized. That's
not great, because it should behave consistently like a default, and not be
written.

I think the better approach will be to see whether the '<null>' is provided
by EMF by default, and whether that could be changed (in EMF) to
show '<VariableInitExp>' instead (according to the EClass name). I really
do think the solution needs to be implemented in the validation framework,
not in the metamodel.

Cheers,

Christian


Adolfo Sánchez-Barbudo Herrera wrote:

> Hi Christian,
>
> Sorry for my bad explanations and my poor knowledge about EValidator
> framework;P. Maybe an example would have helped, I'll will explain my
> concrete example:
>
> I have a Metaclass VariableInitExp ( -> ImperativeExpression ->
> OCLExpression) with a required reference called referredVariable. If
> this referredVariable is not set in an instance of it, the Validator
> throws the following message error:
>
> Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
> required feature 'referredVariable' of
> 'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody:: <null>'
> must be set
>
> This "<null>" value is due to the absence of a name for the
> OCLExpression (in this case VariableInitExp). I agree that a lot of
> expressions don't need a name, but the main reason for that is that the
> own expression is meaningful to identify it, so I think that its
> metaclass's name could make sense for all of them...
>
> So, for the previous case we could have the following report:
>
> Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
> required feature 'referredVariable' of
> 'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody::VariableInitExp'
> must be set
>
> So when getting the name of every VariableInitExp instance, we could
> obtain a proper identifying name. Note that when persisting to a
> resource, the name is not serialized since the name is not set at all
> (I'm not sure if I have been clear :S).
>
> Besides, if you look at the error reporting, OperationBody is included
> as the name for OperationBody's instance (However, it's is not a
> NamedElement). I'm not sure of that, but probably this is the policy
> (taking its MetaClass name) for all elements which are not NamedElements
> ...
>
> Anyway for this concrete purpose, perhaps I could achieve a better error
> reporting from the validator, making use of that
> SubstituionLabelProvider, as you mention. As I said you I'm a newbie
> trying to configure the validation of models for a concrete metamodel,
> so I don't have a good point to get the better way to solve the problems
> with it.
>
> Anyway, a bugzilla enhancement will probably be needed since the OCL
> EValidator will not properly report the problems concerning unnamed
> OCLExpressions. So it's a problem which will need to be solved.
>
> Cheers,
> Adolfo.

-----8<-----
Re: About OCL name expressions [message #53925 is a reply to message #53905] Tue, 15 April 2008 16:27 Go to previous messageGo to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo HerreraFriend
Messages: 254
Registered: July 2009
Senior Member
Christian W. Damus escribió:
> Hi, Adolfo,
>
> I see. Where did the qualified name come from in the error message? Is
> that provided by the default substitution-label provider in the
> diagnostician?
>

Certainly, I don't exactly know, but it should be...Anyway I'll look
into that to have a better point about it (Perhaps Ed Merks, could give
us some help ;P).

What I'm sure:
- Is that the default implementation (substitution-label or whatever)
makes use of the getName() method (from ENamedElement) to display the
errors. I overwrote it, to check it.

> The problem with providing a non-null default name is that, unless it is
> actually specified as the default in the Ecore model (the OCLExpression
> EClass), it will be written out when an expression is serialized. That's
> not great, because it should behave consistently like a default, and not be
> written.

Note that overwriting the getName method to return a no null name for a
oclexpression, is not the same that setting a name for it. So when
saving the element in a Resource, since the field is still set to null,
it will not be serialized. At least that is the conclusion I got when I
checked that my unnamed ImperativeExpressions don't have (serialized)
name after overwriting the getName method ;).

>
> I think the better approach will be to see whether the '<null>' is provided
> by EMF by default, and whether that could be changed (in EMF) to
> show '<VariableInitExp>' instead (according to the EClass name). I really
> do think the solution needs to be implemented in the validation framework,
> not in the metamodel.

Yes, I agree. It would probably be better working around the
OCLValidator (and the displayed messages), at least to solve this
concrete issue. I don't know if there will be more problems surrounding
the unnamed OCL Expressions.

Anyway, I'll arise a bugzilla bug relating that OCL EValidator doesn't
properly display errors when dealing with unnamed OCL Expressions. And
I'll look into the diagnostician reporting error.

Cheers,
Adolfo.

>
> Cheers,
>
> Christian
>
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>
>> Hi Christian,
>>
>> Sorry for my bad explanations and my poor knowledge about EValidator
>> framework;P. Maybe an example would have helped, I'll will explain my
>> concrete example:
>>
>> I have a Metaclass VariableInitExp ( -> ImperativeExpression ->
>> OCLExpression) with a required reference called referredVariable. If
>> this referredVariable is not set in an instance of it, the Validator
>> throws the following message error:
>>
>> Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
>> required feature 'referredVariable' of
>> 'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody:: <null>'
>> must be set
>>
>> This "<null>" value is due to the absence of a name for the
>> OCLExpression (in this case VariableInitExp). I agree that a lot of
>> expressions don't need a name, but the main reason for that is that the
>> own expression is meaningful to identify it, so I think that its
>> metaclass's name could make sense for all of them...
>>
>> So, for the previous case we could have the following report:
>>
>> Validator-ERROR in org.eclipse.emf.ecore; CompleteExample.qvto:79 : The
>> required feature 'referredVariable' of
>> 'CompleteExample.eqvtoperational::aTransformation::main::Ope rationBody::VariableInitExp'
>> must be set
>>
>> So when getting the name of every VariableInitExp instance, we could
>> obtain a proper identifying name. Note that when persisting to a
>> resource, the name is not serialized since the name is not set at all
>> (I'm not sure if I have been clear :S).
>>
>> Besides, if you look at the error reporting, OperationBody is included
>> as the name for OperationBody's instance (However, it's is not a
>> NamedElement). I'm not sure of that, but probably this is the policy
>> (taking its MetaClass name) for all elements which are not NamedElements
>> ...
>>
>> Anyway for this concrete purpose, perhaps I could achieve a better error
>> reporting from the validator, making use of that
>> SubstituionLabelProvider, as you mention. As I said you I'm a newbie
>> trying to configure the validation of models for a concrete metamodel,
>> so I don't have a good point to get the better way to solve the problems
>> with it.
>>
>> Anyway, a bugzilla enhancement will probably be needed since the OCL
>> EValidator will not properly report the problems concerning unnamed
>> OCLExpressions. So it's a problem which will need to be solved.
>>
>> Cheers,
>> Adolfo.
>
> -----8<-----
Re: About OCL name expressions [message #54079 is a reply to message #53905] Fri, 18 April 2008 06:43 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4154
Registered: July 2009
Senior Member
The name in EValidator diaganostics is provided by EObjectValidator.getObjectLabel which normally redirects to a
EValidator.SubstitutionLabelProvider. Within the UMLX framework a CSTFormattingHelper is used
that inherits from OCL's AbstractFormattingHelper and implements EValidator.SubstitutionLabelProvider.
CSTFormattingHelper redirects getObjectLabel to formatQualifiedName.

[It might be beneficial if AbstractFormattingHelper implemented EValidator.SubstitutionLabelProvider.]

It is formatName and formatQualifiedName that are responsible for rendering user-friendly labels, so it is
M6 bit-rot that causes this annoyance. At present formatName has a simple ENamedElement test that
trusts the name. AbstractFormattingHelper.formatName needs to do something better for anonymous
ENamedElements, such as restoring the referred variable name for a VariableExp and providing perhaps
a length-limited string value for a StringLiteralExp.
Re: About OCL name expressions [message #54103 is a reply to message #54079] Fri, 18 April 2008 08:41 Go to previous message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo HerreraFriend
Messages: 254
Registered: July 2009
Senior Member
Ed Willink escribió:
> The name in EValidator diaganostics is provided by
> EObjectValidator.getObjectLabel which normally redirects to a
> EValidator.SubstitutionLabelProvider. Within the UMLX framework a
> CSTFormattingHelper is used
> that inherits from OCL's AbstractFormattingHelper and implements
> EValidator.SubstitutionLabelProvider.
> CSTFormattingHelper redirects getObjectLabel to formatQualifiedName.
>

Yeah !!! ;)

> [It might be beneficial if AbstractFormattingHelper implemented
> EValidator.SubstitutionLabelProvider.]

Probably ;)

> It is formatName and formatQualifiedName that are responsible for
> rendering user-friendly labels, so it is
> M6 bit-rot that causes this annoyance. At present formatName has a
> simple ENamedElement test that
> trusts the name. AbstractFormattingHelper.formatName needs to do
> something better for anonymous
> ENamedElements, such as restoring the referred variable name for a
> VariableExp and providing perhaps
> a length-limited string value for a StringLiteralExp.
>

Well. Since it's a generic abstract formatter, it isn't probably so bad
showing a null when a ENamedElement doesn't have value. It can be a good
way to detect some bugs when creating AST.

The comments you add, could be a good reference for any
OCLFormattingHelper, which we should extend. Anyway I think that the
name of the metaclass is a sufficient name for them (f.i. a large string
could be extremely long for showing as an error. Showing a
StringLiteralExp should suffice).

Cheers,
Adolfo.
Previous Topic:OCL Validator error.
Next Topic:Operation return values
Goto Forum:
  


Current Time: Thu Nov 27 04:59:07 GMT 2014

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

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