Home » Modeling » OCL » OCL constraints using Date attributes
| OCL constraints using Date attributes [message #51663] |
Fri, 29 February 2008 17:02  |
Eclipse User |
|
|
|
Originally posted by: mark.a.addison.jpmorgan.com
I am currently engaged with developing OCL constraint for FpML
(Financial product Markup Language) This is modelled using MOF,
and for which we have an ecore model, which I am trying to
"decorate" with OCL annotations.
I have hit an issue with comparing two date attributes.
The model require a number of constriant to be written which
enforce various agreed business rules about dates,
e.g. the trade date must preceed option call date
(this is a madeup example - because the domain contains
my complex product types.)
I have hit an issue with trying to prove rules, which I believe should
be correct. When using the OCL console in eclipse I get the following
error
Evaluating:
self.tradeDate.value < self.product.oclAsType(Option).callDate.value
Results:
Source of operation (<) must implement Comparable
I cam certain that a comparator exists for our Date class
[ javax.xml.datatype.XMLGregorianCalendar ]
Yes, XML date string represented in the model objects.
NB I have a guard method which preceeds this to check whether this
rule is applicable to Option types.
It would have been wonderful to invoke object methods directly,
e.g. to getTime()
self.tradeDate.value.getTime() <
self.product.oclAsType(Option).callDate.value.getTime()
[ I realise OCL should be implementation neutral :-( ]
NB I have been unable to find anything relating to this in the newsgroups
or anywhere on the web, except for some discussion relating to integer
comparisons.
I wonder whether I have missed something subtle/obvious.
Any help that anyone could provide would be much appreciated.
Mark (Addison)
|
|
|
| Re: OCL constraints using Date attributes [message #51793 is a reply to message #51663] |
Fri, 29 February 2008 19:05  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Mark,
Find some replies in-line, below.
HTH,
Christian
Mark Addison wrote:
> I am currently engaged with developing OCL constraint for FpML
> (Financial product Markup Language) This is modelled using MOF,
> and for which we have an ecore model, which I am trying to
> "decorate" with OCL annotations.
>
> I have hit an issue with comparing two date attributes.
> The model require a number of constriant to be written which
> enforce various agreed business rules about dates,
> e.g. the trade date must preceed option call date
> (this is a madeup example - because the domain contains
> my complex product types.)
Unfortunately, Ecore (like EMOF) doesn't allow DataTypes to define
operations, which is most unfortunate, as OCL requires < at a minimum for
the sortedBy iterator, and otherwise requires the relational operators to
be defined explicitly as operations if they are meant to be used by OCL
constraints.
> I have hit an issue with trying to prove rules, which I believe should
> be correct. When using the OCL console in eclipse I get the following
> error
> Evaluating:
> self.tradeDate.value < self.product.oclAsType(Option).callDate.value
> Results:
> Source of operation (<) must implement Comparable
>
> I cam certain that a comparator exists for our Date class
> [ javax.xml.datatype.XMLGregorianCalendar ]
> Yes, XML date string represented in the model objects.
This is, actually, an MDT-ism that deviates from the OCL specification.
Which release of the OCL component are you using? If you are using a
pre-1.2 release, this should just work. Otherwise, you need to specify the
ParsingOptions.USE_COMPARE_TO_OPERATION parsing option to take advantage of
this special capability.
> NB I have a guard method which preceeds this to check whether this
> rule is applicable to Option types.
>
> It would have been wonderful to invoke object methods directly,
> e.g. to getTime()
> self.tradeDate.value.getTime() <
> self.product.oclAsType(Option).callDate.value.getTime()
> [ I realise OCL should be implementation neutral :-( ]
Yes, OCL only knows about what is modeled. Unfortunately, as I mentioned
earlier, EMOF does not allow you to model data type operations as MOF does.
> NB I have been unable to find anything relating to this in the newsgroups
> or anywhere on the web, except for some discussion relating to integer
> comparisons.
Right, I don't recall any discussion on the subject, previously.
>
> I wonder whether I have missed something subtle/obvious.
> Any help that anyone could provide would be much appreciated.
Well, the ParsingOptions certainly aren't obvious, and they aren't
particularly subtle. :-)
> Mark (Addison)
|
|
|
| Re: OCL constraints using Date attributes [message #51848 is a reply to message #51793] |
Sat, 01 March 2008 10:27 |
| Eclipse User |
|
|
|
Originally posted by: mark.a.addison.jpmorgan.com
Hello Christian,
First, thank for the reply adn explanation. I'm a relative newbie, well as
far as OCL is concerned.
I had a quick look at the OCL java docs to determine the effect of setting
ParsingOptions.USE_COMPARE_TO_OPERATION
"... whether to interpolate <, <=, >, and >= operations when a model type
defines a Java-style compareTo(...) operation."
I would just like to check my understanding. Does the OCL interpretor try
to utilise the traditional relational operators
and if necessary then try to invoke the compareTo on the modelled object
as a 'last resort'?
Mark (Addison)
PS I would just like to say that I appreciate all your knowledgeable replies
and the excellent eclipse article on OCL code generation.
> Hi, Mark,
>
> Find some replies in-line, below.
>
> HTH,
>
> Christian
>
> Mark Addison wrote:
>
>> I am currently engaged with developing OCL constraint for FpML
>> (Financial product Markup Language) This is modelled using MOF, and
>> for which we have an ecore model, which I am trying to "decorate"
>> with OCL annotations.
>>
>> I have hit an issue with comparing two date attributes.
>> The model require a number of constriant to be written which
>> enforce various agreed business rules about dates,
>> e.g. the trade date must preceed option call date
>> (this is a madeup example - because the domain contains
>> my complex product types.)
> Unfortunately, Ecore (like EMOF) doesn't allow DataTypes to define
> operations, which is most unfortunate, as OCL requires < at a minimum
> for the sortedBy iterator, and otherwise requires the relational
> operators to be defined explicitly as operations if they are meant to
> be used by OCL constraints.
>
>> I have hit an issue with trying to prove rules, which I believe
>> should
>> be correct. When using the OCL console in eclipse I get the following
>> error
>> Evaluating:
>> self.tradeDate.value < self.product.oclAsType(Option).callDate.value
>> Results:
>> Source of operation (<) must implement Comparable
>> I cam certain that a comparator exists for our Date class
>> [ javax.xml.datatype.XMLGregorianCalendar ]
>> Yes, XML date string represented in the model objects.
> This is, actually, an MDT-ism that deviates from the OCL
> specification. Which release of the OCL component are you using? If
> you are using a pre-1.2 release, this should just work. Otherwise,
> you need to specify the ParsingOptions.USE_COMPARE_TO_OPERATION
> parsing option to take advantage of this special capability.
>
>> NB I have a guard method which preceeds this to check whether this
>> rule is applicable to Option types.
>>
>> It would have been wonderful to invoke object methods directly,
>> e.g. to getTime()
>> self.tradeDate.value.getTime() <
>> self.product.oclAsType(Option).callDate.value.getTime()
>> [ I realise OCL should be implementation neutral :-( ]
> Yes, OCL only knows about what is modeled. Unfortunately, as I
> mentioned earlier, EMOF does not allow you to model data type
> operations as MOF does.
>
>> NB I have been unable to find anything relating to this in the
>> newsgroups or anywhere on the web, except for some discussion
>> relating to integer comparisons.
>>
> Right, I don't recall any discussion on the subject, previously.
>
>> I wonder whether I have missed something subtle/obvious. Any help
>> that anyone could provide would be much appreciated.
>>
> Well, the ParsingOptions certainly aren't obvious, and they aren't
> particularly subtle. :-)
>
>> Mark (Addison)
>>
|
|
|
| Re: OCL constraints using Date attributes [message #51951 is a reply to message #51848] |
Mon, 03 March 2008 15:32 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Mark,
In-line, again.
cW
Mark Addison wrote:
> Hello Christian,
>
> First, thank for the reply adn explanation. I'm a relative newbie, well as
> far as OCL is concerned.
Well, that's what the newsgroups are for! One of these day's I'll get my
act together and assemble a proper FAQ on the the wiki.
> I had a quick look at the OCL java docs to determine the effect of setting
> ParsingOptions.USE_COMPARE_TO_OPERATION
> "... whether to interpolate <, <=, >, and >= operations when a model type
> defines a Java-style compareTo(...) operation."
> I would just like to check my understanding. Does the OCL interpretor try
> to utilise the traditional relational operators
> and if necessary then try to invoke the compareTo on the modelled object
> as a 'last resort'?
This is basically our attempt to support data types that are implemented as
Comparables in Java. Ecore's EDataTypes do not support the modeling of
EOperations (per the EMOF spec), so OCL generally has no access to any
interesting capabilities of data types. The MDT OCL implementation
automatically maps Ecore's numeric types to OCL's standard library, so that
covers one class of data types.
Similarly, Ecore's collection data types are mapped to OCL's standard
collections.
For other data types, their (partial or complete) ordering is a very
important intrinsic property, so we compromise on the OCL specification by
providing, through this option, an implicit definition of the relational
operations when the implementation class is a Comparable.
Using this option, you should find that OCL "sees" <, <=, etc. operations
defined on your data types (if their Java implementation is a Comparable
type) despite Ecore not having the capacity to model them. This includes
EClasses that model a compareTo operation, but that's not usually an
interesting case.
Note that, when using the UML metamodel binding, this discussion does not
apply. UML DataTypes (at least, in the higher compliance levels) do have
the ability to define Operations, so the parser expects them to be explicit
in the model.
> Mark (Addison)
>
> PS I would just like to say that I appreciate all your knowledgeable
> replies and the excellent eclipse article on OCL code generation.
Thanks for the kind words of encouragement! It certainly helps to know that
my efforts here are having a positive impact.
-----8<-----
|
|
|
Goto Forum:
Current Time: Wed Sep 25 11:46:54 GMT 2024
Powered by FUDForum. Page generated in 0.07028 seconds |
] 
Search
Help
Register
Login
Home
