Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » object mapping during evaluation
object mapping during evaluation [message #483771] Wed, 02 September 2009 21:14 Go to next message
Elio Damaggio is currently offline Elio DamaggioFriend
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... :(
Re: object mapping during evaluation [message #483799 is a reply to message #483771] Thu, 03 September 2009 05:51 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4187
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... :(
>
Previous Topic:extending the OCL parser and evaluation
Next Topic:Expressions involving undefined values
Goto Forum:
  


Current Time: Sat Dec 20 02:26:46 GMT 2014

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

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