|
|
Re: Validation of property access in post-conditions of UML static operations [message #1747488 is a reply to message #1747485] |
Tue, 15 November 2016 12:10 |
German Vega Messages: 104 Registered: December 2015 Location: Grenoble, France |
Senior Member |
|
|
Hi
Thanks Ed for your prompt response, as always.
Quote:
Eclipse OCL has plausible "static" parsing but dubious evaluation that may improve if this thread provokes a sensible Bugzilla. A significant problem is that while UML and Java may support static concepts, Ecore does not and so the UML2Ecore2Java conversion that precedes evaluation loses "static".
NB the Eclipse OCL support for post-conditions is for parsing only. There is no evaluation support.
OK, I Understand. Actually I am just interested in parsing, not evaluation
Quote:
You should be able to extend the validation by loading a *.ocl document. See the Complete OCL tutorial.
Ok, I have managed to load a complete OCl document to add validations. I can navigate the UML model, but I don't know how to get the parsed OCl constraint.
Currently I have tried something like this
import uml:'http://www.eclipse.org/uml2/5.0.0/UML'
context uml::Operation
inv staticOperation: self.isStatic implies self.postcondition->forAll( c: Constraint |
c.specification.oclAsType(OpaqueExpression)._'body' ????? don't know how to get the parsed constraint
)
But the "body" of a OpaqueExpression is a String, and I need the parsed OCL expression, in order to check for PropertyCallExp expressions.
Is there a simple way to get to the parsed constraint?
Thanks
German
|
|
|
|
|
|
Re: Validation of property access in post-conditions of UML static operations [message #1747531 is a reply to message #1747521] |
Tue, 15 November 2016 16:47 |
German Vega Messages: 104 Registered: December 2015 Location: Grenoble, France |
Senior Member |
|
|
Hello
Well, all the alternatives seem to require a modified OCL standard library, and that is far beyond my reach by now.
As I have mentioned in previous posts, I work in a tool to transform UML constraints in OCL to some formal notation, so my original need was just simply to be sure to have a well-formed OCL constraint before applying the transformation. The tool is integrated with Papyrus, so that's why I asked you about extending the validation model menu.
I think for now I will just program my specific well-formedness rules in Java, and make a validation phase in the transformation that adds problem markers to the project (so that they show up in papyrus views). I should give a try to the OCL to Java generator
Anyway, thanks for the help, I have learnt a lot.
German Vega
|
|
|
Powered by
FUDForum. Page generated in 0.04018 seconds