Eclipse Community Forums: OCL » object mapping during evaluation

Help

Home

Home » Modeling » OCL » object mapping during evaluation

Show: Today's Messages :: Show Polls :: Message Navigator

object mapping during evaluation [message #483771]

Wed, 02 September 2009 21:14

Elio Damaggio

Messages: 8
Registered: July 2009

Junior Member

Hi all,

Thanks everybody for all the previous answers, they have been extremely
useful.
The problem I have now is really tricky and I do not know how to solve it.

The deal is this:
1) I have an Ecore object that is not exactly the one I have to perform
the evaluation on. (e.g. some attributes are string instead of dates and
so on, or I have a list of class instances with an attribute a, and it has
to be accessed by OCL as a list of only the "a"). This is clearly a
mapping to be done.
2) Is there a way to hijack the way the OCL parser/evaluator accesses the
properties/types in order to translate these things on the fly?

Any idea is really appreciated...

Elio

ps. I have to deal with legacy code and I do not have full control over
it, I know this whole problem should never arise in a clean design... :(

Report message to a moderator

Re: object mapping during evaluation [message #483799 is a reply to message #483771]

Thu, 03 September 2009 05:51

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Elio

I think you want to step back a bit from your problem and think about
it; what you're asking doesn't make sense.

OCL works to the Ecore meta-model. If the Ecore meta-model is wrong OCL
will behave consistently with that meta-model.

So you probably have two different Ecore meta-models; what you actually
have and what you want. This is a model transformation. Shoe horning it
into OCL is a very difficult way of solving it. Any of the M2M tools
should be able to do it for you. Since the maping is so small you might
consider AM3 which I think, (I've never used it), is specifically
intended for mappings.

You might hand code the transformation as a Java tree iteration.

You might perform the transformation during Ecore loading via custom
StringToDate EDataType reading methods for the true Ecore model.

You might define the true Ecore as an elaboration of the actual Ecore
with the true e.g. Date properities marked as derived requiring you to
provide the conversion routines.

Regards

Ed Willink

Elio Damaggio wrote:
> Hi all,
>
> Thanks everybody for all the previous answers, they have been extremely
> useful.
> The problem I have now is really tricky and I do not know how to solve it.
>
> The deal is this:
> 1) I have an Ecore object that is not exactly the one I have to perform
> the evaluation on. (e.g. some attributes are string instead of dates and
> so on, or I have a list of class instances with an attribute a, and it
> has to be accessed by OCL as a list of only the "a"). This is clearly a
> mapping to be done.
> 2) Is there a way to hijack the way the OCL parser/evaluator accesses
> the properties/types in order to translate these things on the fly?
>
> Any idea is really appreciated...
>
> Elio
>
> ps. I have to deal with legacy code and I do not have full control over
> it, I know this whole problem should never arise in a clean design... :(
>

Report message to a moderator

Previous Topic:	extending the OCL parser and evaluation
Next Topic:	Expressions involving undefined values

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Apr 27 00:45:05 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter