|
|
Re: Code Generation with external ocl document [message #1784390 is a reply to message #1784113] |
Tue, 27 March 2018 14:19 |
Bruce Trask Messages: 58 Registered: July 2009 |
Member |
|
|
Thanks Ed,
Thanks.
I am diving into GeneratePivotModel.mwe2 and how the merge happens using those components. I got the org.eclipse.ocl.examples.build plugin from git as it did not seem to be part of the release package. Was just wondering if there is a particular tag or branch I should use that corresponds to the release of the plugins for Eclipse Oxygen (Version: Oxygen.1a Release (4.7.1a)
Build id: 20171005-1200). I tried it with master but it seems to have advanced beyond what I have.
Regards,
Bruce
[Updated on: Tue, 27 March 2018 14:20] Report message to a moderator
|
|
|
|
Re: Code Generation with external ocl document [message #1784469 is a reply to message #1784421] |
Wed, 28 March 2018 11:01 |
Bruce Trask Messages: 58 Registered: July 2009 |
Member |
|
|
Hi,
Thanks. I got it working so it generates Pivot.ecore that has the annotations in it. Quite an impressive orchestration of functionality and generation there. I will dive in to see how it all works so I can merge my .ocl file with my .ecore file and then generate the code from that. Also will look at the other mwe2 file you mentioned.
Regards,
Bruce
[Updated on: Wed, 28 March 2018 11:04] Report message to a moderator
|
|
|
|
|
|
Re: Code Generation with external ocl document [message #1784560 is a reply to message #1784487] |
Thu, 29 March 2018 11:12 |
Bruce Trask Messages: 58 Registered: July 2009 |
Member |
|
|
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 11:35] Report message to a moderator
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04076 seconds