[news.eclipse.modeling.mdt.ocl] Re: object mapping during evaluation

[Ed Willink <ed@xxxxxxxxxxxxx>]

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... :(