Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Code Generation with external ocl document(Code Generation with external ocl document)
Code Generation with external ocl document [message #1784109] Thu, 22 March 2018 15:46 Go to next message
Bruce Trask is currently offline Bruce TraskFriend
Messages: 58
Registered: July 2009
Member
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 #1784113 is a reply to message #1784109] Thu, 22 March 2018 15:55 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
Registered: July 2009
Senior Member
Hi

Sorry, Complete OCL CG is on the to do list. The main challenge is working out what Java class file to use to host something that belongs in X.java after X.java already exists... The QVTi CG resolves similar issues so its really just a matter of round-tu-its.

You can merge (currently programmatically in MWE2) a *.ocl into a *.ecore/*.uml prior to CG. That's how Pivot.ocl merges into Pivot.ecore to produce Java.

Regards

Ed Willink
Re: Code Generation with external ocl document [message #1784390 is a reply to message #1784113] Tue, 27 March 2018 14:19 Go to previous messageGo to next message
Bruce Trask is currently offline Bruce TraskFriend
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 #1784421 is a reply to message #1784390] Tue, 27 March 2018 19:15 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
Registered: July 2009
Senior Member
Hi

If you understand GeneratePivotModel.mwe2, you are doing well since it is far from trivial. GenerateCGModels.mwe2 is probably a much simpler learning exercise.

The tags are fairly obvious... 6.3.0RC4a is the last 6.3.0 (Oxygen). There has been no maintenance release.

Regards

Ed Willink
Re: Code Generation with external ocl document [message #1784469 is a reply to message #1784421] Wed, 28 March 2018 11:01 Go to previous messageGo to next message
Bruce Trask is currently offline Bruce TraskFriend
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 #1784471 is a reply to message #1784469] Wed, 28 March 2018 11:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
Registered: July 2009
Senior Member
Hi

If merged OCL CG is what you want, GIT\org.eclipse.qvtd\releng\org.eclipse.qvtd.build\src\org\eclipse\qvtd\build\mwe2\GenerateQVTdASModels.mwe2 is a much simpler example to work with.

Regards

Ed Willink
Re: Code Generation with external ocl document [message #1784485 is a reply to message #1784471] Wed, 28 March 2018 15:01 Go to previous messageGo to next message
Bruce Trask is currently offline Bruce TraskFriend
Messages: 58
Registered: July 2009
Member
Hi,

With the help of your pointers and examples, I have it working. Have it running well with the Royal and Loyal ecore and ocl file. Appreciate the help.

Thanks,
Bruce
Re: Code Generation with external ocl document [message #1784487 is a reply to message #1784485] Wed, 28 March 2018 15:43 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
Registered: July 2009
Senior Member
HI

If you care to contribute I can try to upgrade the example. Please raise a Bugzilla, sign the ECA and attach the contribution.

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=OCL

Regards

Ed Willink
Re: Code Generation with external ocl document [message #1784560 is a reply to message #1784487] Thu, 29 March 2018 11:12 Go to previous messageGo to next message
Bruce Trask is currently offline Bruce TraskFriend
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

Re: Code Generation with external ocl document [message #1784564 is a reply to message #1784560] Thu, 29 March 2018 11:30 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
Registered: July 2009
Senior Member
Hi

As I mentioned earlier, Complete OCL CG is not yet supported, in part because of a host class identification problem.

You may be hitting limitations awaiting handling by: https://bugs.eclipse.org/bugs/show_bug.cgi?id=500551

For the limited case of invariants and a few helpers, it works for me.

If you provide a repro, I can investigate what is happening.

Regards

Ed Willink
Re: Code Generation with external ocl document [message #1784583 is a reply to message #1784564] Thu, 29 March 2018 14:47 Go to previous messageGo to next message
Bruce Trask is currently offline Bruce TraskFriend
Messages: 58
Registered: July 2009
Member
Hi Ed,

> As I mentioned earlier, Complete OCL CG is not yet supported,
> in part because of a host class identification problem.

Understood. And just to be clear, I am not complaining. I am liking what I see and happy to have what I do have. I am looking into making some changes myself so I could add some functionality but wanted to make sure I am not going to totally screw things up :)

I see in InteralCompleteOCL.g that 'derive' maps to generated code for adding ownedDerivedInvariants. I was wondering why it mapped to an invariant versus a ownedDefaultExpression?

// InternalCompleteOCL.g:1372:2: ( (otherlv_4= 'derive' ( (lv_ownedDerivedInvariants_5_0= ruleConstraintCS ) ) ) | (otherlv_6= 'init' otherlv_7= ':' ( (lv_ownedDefaultExpressions_8_0= ruleSpecificationCS ) ) ) )*

I was thinking of also allowing 'derive' to behave like 'init' to add another ownedDefaultExpression so that the downstream eAnnotation for derived features and attributes will be added to the structuralFeature in addition to the callable validation function.

Would I be out of line to go forward with such a change?

Regards,
Bruce
Re: Code Generation with external ocl document [message #1784592 is a reply to message #1784583] Thu, 29 March 2018 18:26 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
Registered: July 2009
Senior Member
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
Previous Topic:Validate OCL from ecore standalone => Exception java.lang.NullPointerException: null
Next Topic:Failed to set 'self' context
Goto Forum:
  


Current Time: Sat Nov 17 21:22:17 GMT 2018

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

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

Back to the top