| Code Generation with external ocl document [message #1784109] |
Thu, 22 March 2018 11:46  |
Eclipse User |
|
|
|
Hi,
I am going through the OCL tutorials. I had some questions with regard to code generation. I see that working great with the OCLinECore examples and tutorials. Can I do the same with the CompleteOCL examples? Can I do code generation with the ocl in separate file? Or does it have to be OCLinECore?
For example I would like to generate code for the EcoreTestFile.ecore and its genmodel and have it use either delegation or java for the constraints in ExtraXMIValidation.ocl.
Regards,
Bruce
|
|
|
|
|
|
|
|
|
|
| Re: Code Generation with external ocl document [message #1784560 is a reply to message #1784487] |
Thu, 29 March 2018 07:12  |
| Eclipse User |
|
|
|
Hi,
As I look a bit further into the generated code, I am noticing that after using the ConstraintMerger on my ecore file and ocl file, for derived attributes, it produces a callable invariant within the resulting ecore file and not a { initial: ...} block following the attribute. So the generated code has UnsupportedOperations for the derived attributes and references but does have validation functions for them. In other words the eAnnotation appears to be added to a validate operation rather than to the derived structural feature itself.
For example from the RoyalAndLoyal.ocl file, I see
context CustomerCard::printedName : String
derive printedName:
self.owner.title.concat(' ').concat(self.owner.name)
which, after merge, with ConstraintMerger gives
callable invariant printedName:
self.owner.title.concat(' ').concat(self.owner.name)
in the produced ecore file
when I was expecting to see something like this instead:
attribute printedName : String[1] { derived readonly volatile }
{
initial: self.owner.title.concat(' ').concat(self.owner.name);
}
I looked quickly at ConstraintMerger.java but it was not obvious to me where the derived features get handled. I will keep diving in to see if I can find it but I thought I would ask some questions in the meantime.
My questions are:
1. Is what I am seeing to be expected?
2. To get derived references and attributes that should be set by way of OCL expressions, will I need to modify or otherwise extend ConstraintMerger.java to put the appropriate annotation in the resulting ecore file?
3. Or am I missing something?
Regards,
Bruce
[Updated on: Thu, 29 March 2018 07:35] by Moderator |
|
|
|
|
| Re: Code Generation with external ocl document [message #1784592 is a reply to message #1784583] |
Thu, 29 March 2018 14:26 |
| Eclipse User |
|
|
|
Hi
My starting point was the inherited IBM interpretation of the very inadequate OCL specification wording. I struggle to evolve in the spirit of what the specification should have said without breaking too much...
init/derive are very misleading with legacy code to match.
Careful reading leads to a clear indication that 'init' is the initial value expression that should be evaluated during 'construction', and the 'derive' is a constraint on what a derived class may expect to find at any time. The syntax fails to distinguish.
Unfortunately UML only supports boolean valued constraints so expressions require a fudge. I don't get much enthusiasm at UML for exploiting the defaultValueExpression as an initial value. Since the UML authors didn't understand the mess, they invented the secret idiom that an argument-less operation is a body / initializer for a same-named property. At least this idiom is now described in UML 2.5. It could be eliminated if UML had the courage to use defaultValueExpressions.
I think the Pivot OCL code is plausible. init used to behave like derive until I understood the important expression/constraint difference. There are probably some Bugzillas asking what is the difference...
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.08302 seconds
Home