Home » Modeling » OCL » About EValidator checkArgumentConform constraint
| About EValidator checkArgumentConform constraint [message #55500] |
Mon, 12 May 2008 13:10  |
 Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
I have had problems while applying checkArgumentConform constraint in
QVTo models.
Using env.lookupOperation for checking the conformance of the
parameters, it is not a valid way for QVTo. Every operationCallExp would
need the concrete environment in which it was analyzed to obtain the
referred operation, and it seems that there is no way to do that in the
actual OCL EValidator. Besides, I think that EValidator should not know
anything about the environments in which an AST node was created. A
provided model built by hand (f.i. Sample Ecore Editor), doesn't know
anything about them.
Having a suitable environment for a AST node, is very helpful since you
can reuse implementation (TypeUtil impl, UMLReflection, etc), however I
think using them for doing parser-related actions (such us looking an
operation) is not very convenient (Maybe it works for OCL. It doesn't
for QVTo).
Besides, looking an operation which you already have (the referred
operation) seems to be redundant. I would suggest you checking all the
paremeters of the referred operation, with all the arguments of the
operationCallExp, instead.
On the other hand, I will need to "overwrite" this constraint for a
specific extension of operationCallExp. QVTo extends it, with a concept
called ImperativeCallExp, in which I'll have alternative ways of
invoking the operation. I have tried to "overwrite" the constraint, but
I don't find out the way.... The constraint is implemented via an
EOperation in the MetaClass. I tried to create a new one (with the same
name), but in the generated code of the Validator, I can notice 2 things:
1. Both constraints are called:
2. The names for invoking the constraints are different.
I can paste you, the invocation:
if (result || diagnostics != null) result &=
expressionsValidator.validateOperationCallExp_checkArguments Conform(imperativeCallExp,
diagnostics, context);
if (result || diagnostics != null) result &=
expressionsValidator.validateOperationCallExp_checkArgumentC ount(imperativeCallExp,
diagnostics, context);
if (result || diagnostics != null) result &=
validateImperativeCallExp_arguments_conform(imperativeCallEx p,
diagnostics, context);
I would appreciate very much your help, if you can give me any guide or
clue about what I'm missing....
Cheers,
Adolfo.
|
|
|
| Re: About EValidator checkArgumentConform constraint [message #55527 is a reply to message #55500] |
Mon, 12 May 2008 13:43  |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
About the redefinition of EOperations...
I found out an example in the own OCL Metamodel, with the Collection
types(using duplicates and redefine annotations to overwrite the
collection_name constraint)...Anyway something is missing, because it
doesn't work I'll try to find some documentation, about all this stuff....
Cheers,
Adolfo.
Adolfo Sánchez-Barbudo Herrera escribió:
> Hi Christian,
>
> I have had problems while applying checkArgumentConform constraint in
> QVTo models.
>
> Using env.lookupOperation for checking the conformance of the
> parameters, it is not a valid way for QVTo. Every operationCallExp would
> need the concrete environment in which it was analyzed to obtain the
> referred operation, and it seems that there is no way to do that in the
> actual OCL EValidator. Besides, I think that EValidator should not know
> anything about the environments in which an AST node was created. A
> provided model built by hand (f.i. Sample Ecore Editor), doesn't know
> anything about them.
>
> Having a suitable environment for a AST node, is very helpful since you
> can reuse implementation (TypeUtil impl, UMLReflection, etc), however I
> think using them for doing parser-related actions (such us looking an
> operation) is not very convenient (Maybe it works for OCL. It doesn't
> for QVTo).
>
> Besides, looking an operation which you already have (the referred
> operation) seems to be redundant. I would suggest you checking all the
> paremeters of the referred operation, with all the arguments of the
> operationCallExp, instead.
>
> On the other hand, I will need to "overwrite" this constraint for a
> specific extension of operationCallExp. QVTo extends it, with a concept
> called ImperativeCallExp, in which I'll have alternative ways of
> invoking the operation. I have tried to "overwrite" the constraint, but
> I don't find out the way.... The constraint is implemented via an
> EOperation in the MetaClass. I tried to create a new one (with the same
> name), but in the generated code of the Validator, I can notice 2 things:
> 1. Both constraints are called:
> 2. The names for invoking the constraints are different.
>
> I can paste you, the invocation:
>
> if (result || diagnostics != null) result &=
> expressionsValidator.validateOperationCallExp_checkArguments Conform(imperativeCallExp,
> diagnostics, context);
> if (result || diagnostics != null) result &=
> expressionsValidator.validateOperationCallExp_checkArgumentC ount(imperativeCallExp,
> diagnostics, context);
> if (result || diagnostics != null) result &=
> validateImperativeCallExp_arguments_conform(imperativeCallEx p,
> diagnostics, context);
>
> I would appreciate very much your help, if you can give me any guide or
> clue about what I'm missing....
>
> Cheers,
> Adolfo.
>
|
|
|
| Re: About EValidator checkArgumentConform constraint [message #55664 is a reply to message #55527] |
Tue, 13 May 2008 23:54 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Adolfo,
Yes, OCL is generated using MDT UML2, which supports operation and
attribute redefinition. If you're generating from Ecore, you can add
operation redefinitions manually in your *Impl classes.
Cheers,
Christian
On Monday 05-12-2008 (09:43), Adolfo Sánchez-Barbudo Herrera wrote:
> About the redefinition of EOperations...
> I found out an example in the own OCL Metamodel, with the Collection
> types(using duplicates and redefine annotations to overwrite the
> collection_name constraint)...Anyway something is missing, because it
> doesn't work I'll try to find some documentation, about all this
> stuff....
> Cheers,
> Adolfo.
-----8<-----
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
|
|
|
| Re: About EValidator checkArgumentConform constraint [message #55686 is a reply to message #55500] |
Wed, 14 May 2008 00:02 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Adolfo,
On Monday 05-12-2008 (09:10), Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Christian,
> I have had problems while applying checkArgumentConform constraint
> in QVTo models.
> Using env.lookupOperation for checking the conformance of the
> parameters, it is not a valid way for QVTo. Every operationCallExp
> would need the concrete environment in which it was analyzed to
> obtain the referred operation, and it seems that there is no way to
> do that in the actual OCL EValidator. Besides, I think that
> EValidator should not know anything about the environments in which
> an AST node was created. A provided model built by hand (f.i. Sample
> Ecore Editor), doesn't know anything about them.
Agreed. The environment should only be used by the validator to
perform introspection of the metamodel.
> Having a suitable environment for a AST node, is very helpful since
> you can reuse implementation (TypeUtil impl, UMLReflection, etc),
> however I think using them for doing parser-related actions (such us
> looking an operation) is not very convenient (Maybe it works for OCL.
> It doesn't for QVTo).
> Besides, looking an operation which you already have (the referred
> operation) seems to be redundant. I would suggest you checking all
> the paremeters of the referred operation, with all the arguments of
> the operationCallExp, instead.
Yes, this implementation was basically cribbed from the
ValidationVisitor. Please raise a bug so that this can be changed.
> On the other hand, I will need to "overwrite" this constraint for a
> specific extension of operationCallExp. QVTo extends it, with a
> concept called ImperativeCallExp, in which I'll have alternative ways
> of invoking the operation. I have tried to "overwrite" the
> constraint, but I don't find out the way.... The constraint is
> implemented via an EOperation in the MetaClass. I tried to create a
> new one (with the same name), but in the generated code of the
> Validator, I can notice 2 things:1. Both constraints are called:
> 2. The names for invoking the constraints are different.
Hmmm ... I'm not sure about the redefinition of the constraint. You
might ask on the EMF newsgroup about that.
> I can paste you, the invocation:
> if (result || diagnostics != null) result &=
> expressionsValidator.validateOperationCallExp_checkArguments Conform(im
> perativeCallExp, diagnostics, context);
> if (result || diagnostics != null) result &=
> expressionsValidator.validateOperationCallExp_checkArgumentC ount(imper
> ativeCallExp, diagnostics, context);
> if (result || diagnostics != null) result &=
> validateImperativeCallExp_arguments_conform(imperativeCallEx p,
> diagnostics, context);
> I would appreciate very much your help, if you can give me any guide
> or clue about what I'm missing....
> Cheers,
> Adolfo.
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
|
|
|
| Re: About EValidator checkArgumentConform constraint [message #55713 is a reply to message #55686] |
Wed, 14 May 2008 09:37 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Some comments in-lined below.
Christian W. Damus escribió:
> Hi, Adolfo,
>
> On Monday 05-12-2008 (09:10), Adolfo Sánchez-Barbudo Herrera wrote:
>> Hi Christian,
>
>> I have had problems while applying checkArgumentConform constraint
>> in QVTo models.
>
>> Using env.lookupOperation for checking the conformance of the
>> parameters, it is not a valid way for QVTo. Every operationCallExp
>> would need the concrete environment in which it was analyzed to
>> obtain the referred operation, and it seems that there is no way to
>> do that in the actual OCL EValidator. Besides, I think that
>> EValidator should not know anything about the environments in which
>> an AST node was created. A provided model built by hand (f.i. Sample
>> Ecore Editor), doesn't know anything about them.
>
> Agreed. The environment should only be used by the validator to
> perform introspection of the metamodel.
The ValidationVisitor should probably take into account the same
consideration.
>
>> Having a suitable environment for a AST node, is very helpful since
>> you can reuse implementation (TypeUtil impl, UMLReflection, etc),
>> however I think using them for doing parser-related actions (such us
>> looking an operation) is not very convenient (Maybe it works for OCL.
>> It doesn't for QVTo).
>
>> Besides, looking an operation which you already have (the referred
>> operation) seems to be redundant. I would suggest you checking all
>> the paremeters of the referred operation, with all the arguments of
>> the operationCallExp, instead.
>
> Yes, this implementation was basically cribbed from the
> ValidationVisitor. Please raise a bug so that this can be changed.
Done => https://bugs.eclipse.org/bugs/show_bug.cgi?id=232028.
>
>> On the other hand, I will need to "overwrite" this constraint for a
>> specific extension of operationCallExp. QVTo extends it, with a
>> concept called ImperativeCallExp, in which I'll have alternative ways
>> of invoking the operation. I have tried to "overwrite" the
>> constraint, but I don't find out the way.... The constraint is
>> implemented via an EOperation in the MetaClass. I tried to create a
>> new one (with the same name), but in the generated code of the
>> Validator, I can notice 2 things:1. Both constraints are called:
>> 2. The names for invoking the constraints are different.
>
> Hmmm ... I'm not sure about the redefinition of the constraint. You
> might ask on the EMF newsgroup about that.
Ok, I'll try there, then.
Thank you very much.
Adolfo.
>
>> I can paste you, the invocation:
>
>> if (result || diagnostics != null) result &=
>
>> expressionsValidator.validateOperationCallExp_checkArguments Conform(im
>> perativeCallExp, diagnostics, context);
>> if (result || diagnostics != null) result &=
>
>> expressionsValidator.validateOperationCallExp_checkArgumentC ount(imper
>> ativeCallExp, diagnostics, context);
>> if (result || diagnostics != null) result &=
>> validateImperativeCallExp_arguments_conform(imperativeCallEx p,
>> diagnostics, context);
>
>> I would appreciate very much your help, if you can give me any guide
>> or clue about what I'm missing....
>
>> Cheers,
>> Adolfo.
>
>
|
|
|
| Re: About EValidator checkArgumentConform constraint [message #55740 is a reply to message #55664] |
Wed, 14 May 2008 10:10 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Christian W. Damus escribió:
> Hi, Adolfo,
>
> Yes, OCL is generated using MDT UML2, which supports operation and
> attribute redefinition. If you're generating from Ecore, you can add
> operation redefinitions manually in your *Impl classes.
>
Yes but the problem is that the OCLValidator.XXXXXXX restriction is
still called by the EValidator. Besides, I would like adding this kind
of checking as Ecore EAnnotations, instead of creating EOperations.
Well, I will see what to do with this....because I have different points ...
1. I don't think that derived CollectionTypes (Set, Bag, QVTo::List,
Etc) need to "overwrite" the checkCollectionTypeName restriction to not
make the checking (returning always true), because if you have an
instance of SetType, whose name is Bag(String), would not be detected by
the validator. Just improving
CollectionTypeOperations.checkCollectionTypeName restriction, using the
collectionType.kind would suffice (at least for OCL collectionTypes not
for QVTo::List => I'll need to overwrite in somehow).
2. Probably, my problem with imperativeCallExp is not a problem at all.
I have to think and check about the different ways of calling an
imperativeCallExp. Maybe It's just a parsing problem rather than a
semantic addition.
Cheers,
Adolfo.
> Cheers,
>
> Christian
>
> On Monday 05-12-2008 (09:43), Adolfo Sánchez-Barbudo Herrera wrote:
>> About the redefinition of EOperations...
>
>> I found out an example in the own OCL Metamodel, with the Collection
>> types(using duplicates and redefine annotations to overwrite the
>> collection_name constraint)...Anyway something is missing, because it
>> doesn't work I'll try to find some documentation, about all this
>> stuff....
>
>> Cheers,
>> Adolfo.
>
> -----8<-----
>
|
|
|
| Re: About EValidator checkArgumentConform constraint [message #55794 is a reply to message #55740] |
Thu, 15 May 2008 01:01 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Adolfo,
See see responses in-line, below.
Cheers,
Christian
On Wednesday 05-14-2008 (06:10), Adolfo Sánchez-Barbudo Herrera
wrote:
> Christian W. Damus escribió:
>> Hi, Adolfo,
>>
>> Yes, OCL is generated using MDT UML2, which supports operation and
>> attribute redefinition. If you're generating from Ecore, you can
>> add operation redefinitions manually in your *Impl classes.
> Yes but the problem is that the OCLValidator.XXXXXXX restriction is
> still called by the EValidator. Besides, I would like adding this
> kind of checking as Ecore EAnnotations, instead of creating
> EOperations.
Well, the reason why I like the EOperation approach is that operations
can be overridden. By implementing the constraint as a method of the
Java class, a specializing class can override its implementation.
That cannot be done with the annotation approach which generates the
constraints into the validator. As you have observed, it is not easy
to override constraints generated in that way.
> Well, I will see what to do with this....because I have different
> points ...
> 1. I don't think that derived CollectionTypes (Set, Bag, QVTo::List,
> Etc) need to "overwrite" the checkCollectionTypeName restriction to
> not make the checking (returning always true), because if you have an
> instance of SetType, whose name is Bag(String), would not be detected
> by the validator. Just improving
> CollectionTypeOperations.checkCollectionTypeName restriction, using
> the collectionType.kind would suffice (at least for OCL
> collectionTypes not for QVTo::List => I'll need to overwrite in
> somehow).
Yes, but the OCL specification defines 5 different name constraints,
one for each CollectionType metaclass. As the specification doesn't
provide names for these constraints (OMG does not provide an OCL
model) I had to devise my own names. I chose to give them the same
name because it would result in the overriding of operations and,
thus, a smaller Java API.
> 2. Probably, my problem with imperativeCallExp is not a problem at
> all. I have to think and check about the different ways of calling an
> imperativeCallExp. Maybe It's just a parsing problem rather than a
> semantic addition.
Well, I have provided a patch on the bugzilla for you to test. If it
turns out to be unnecessary, we can downgrade the severity of the bug
and schedule it for the next release.
> Cheers,
> Adolfo.
>> Cheers,
>>
>> Christian
>>
>> On Monday 05-12-2008 (09:43), Adolfo Sánchez-Barbudo Herrera
>> wrote:
>>> About the redefinition of EOperations...
>>
>>> I found out an example in the own OCL Metamodel, with the
>>> Collection types(using duplicates and redefine annotations to
>>> overwrite the collection_name constraint)...Anyway something is
>>> missing, because it doesn't work I'll try to find some
>>> documentation, about all this
>>> stuff....
>>
>>> Cheers,
>>> Adolfo.
>>
>> -----8<-----
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
|
|
|
| Re: About EValidator checkArgumentConform constraint [message #55821 is a reply to message #55794] |
Thu, 15 May 2008 14:41 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
> Well, I have provided a patch on the bugzilla for you to test. If it
> turns out to be unnecessary, we can downgrade the severity of the bug
> and schedule it for the next release.
I didn't explain well. What is not necessary for me, is "overriding" the
checkArgumentConformance constraint. The constraint itself has to be
changed, because the qvto validator is unable to found the referred
EOperation (ImperativeOperation), when looking-up the operation in the
provided rootEnvironment.
Thanks for the info, about the EOperations and EAnnotations. I'll have
to think (and firstly learn) about which is the better way to add this
constraints into the EValidation framework.
Cheers,
Adolfo.
Christian W. Damus escribió:
> Hi, Adolfo,
>
> See see responses in-line, below.
>
> Cheers,
>
> Christian
>
> On Wednesday 05-14-2008 (06:10), Adolfo Sánchez-Barbudo Herrera
> wrote:
>> Christian W. Damus escribió:
>>> Hi, Adolfo,
>>>
>>> Yes, OCL is generated using MDT UML2, which supports operation and
>>> attribute redefinition. If you're generating from Ecore, you can
>>> add operation redefinitions manually in your *Impl classes.
>
>> Yes but the problem is that the OCLValidator.XXXXXXX restriction is
>> still called by the EValidator. Besides, I would like adding this
>> kind of checking as Ecore EAnnotations, instead of creating
>> EOperations.
>
> Well, the reason why I like the EOperation approach is that operations
> can be overridden. By implementing the constraint as a method of the
> Java class, a specializing class can override its implementation.
> That cannot be done with the annotation approach which generates the
> constraints into the validator. As you have observed, it is not easy
> to override constraints generated in that way.
>
>> Well, I will see what to do with this....because I have different
>> points ...
>
>> 1. I don't think that derived CollectionTypes (Set, Bag, QVTo::List,
>> Etc) need to "overwrite" the checkCollectionTypeName restriction to
>> not make the checking (returning always true), because if you have an
>> instance of SetType, whose name is Bag(String), would not be detected
>> by the validator. Just improving
>> CollectionTypeOperations.checkCollectionTypeName restriction, using
>> the collectionType.kind would suffice (at least for OCL
>> collectionTypes not for QVTo::List => I'll need to overwrite in
>> somehow).
>
> Yes, but the OCL specification defines 5 different name constraints,
> one for each CollectionType metaclass. As the specification doesn't
> provide names for these constraints (OMG does not provide an OCL
> model) I had to devise my own names. I chose to give them the same
> name because it would result in the overriding of operations and,
> thus, a smaller Java API.
>
>> 2. Probably, my problem with imperativeCallExp is not a problem at
>> all. I have to think and check about the different ways of calling an
>> imperativeCallExp. Maybe It's just a parsing problem rather than a
>> semantic addition.
>
> Well, I have provided a patch on the bugzilla for you to test. If it
> turns out to be unnecessary, we can downgrade the severity of the bug
> and schedule it for the next release.
>> Cheers,
>> Adolfo.
>>> Cheers,
>>>
>>> Christian
>>>
>>> On Monday 05-12-2008 (09:43), Adolfo Sánchez-Barbudo Herrera
>>> wrote:
>>>> About the redefinition of EOperations...
>>>
>>>> I found out an example in the own OCL Metamodel, with the
>>>> Collection types(using duplicates and redefine annotations to
>>>> overwrite the collection_name constraint)...Anyway something is
>>>> missing, because it doesn't work I'll try to find some
>>>> documentation, about all this
>>>> stuff....
>>>
>>>> Cheers,
>>>> Adolfo.
>>>
>>> -----8<-----
>
>
|
|
|
Goto Forum:
Current Time: Sat Nov 09 01:00:14 GMT 2024
Powered by FUDForum. Page generated in 0.03097 seconds |
] 
Search
Help
Register
Login
Home
