Home » Modeling » OCL » Validating OCL programmatically(Validating OCL constraints)
| | | |
Re: Validating OCL programmatically [message #1697422 is a reply to message #1697421] |
Wed, 03 June 2015 19:26 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi
I suggest reading the OCLinEcore tutorial in the documentation and n the
Wiki.
For pure model usage, Eclipse OCL exploits EMF extensibility APIs. There
is no OCL in the EMF plugins. But Eclipse OCL implements EMF extension
points so it looks as if OCL is part of EMF.
Use the Manifest editor to examine definition and references to e.g. the
org.eclipse.emf.ecore.validation_delegate extension point.
You might also want to look at the Code Generator tutorial.
Regards
Ed Willink
On 03/06/2015 19:53, Edoaurd Batot wrote:
> Hi there,
>
> Quote:
>> The OCLinEcore constraints are integrated into the standard Ecore
>> framework, so just validate as you would any normal Ecore model.
>
>
> I don't understand. Does it mean that the OCL* classes used to
> constraint models are present in emf.common or emf.ecor libraries ?
>
> I'm using these ones to play with Ecore models digged out of XMI files :
> /lib/org.eclipse.emf.common_2.11.0.v20150123-0347.jar
> /lib/org.eclipse.emf.ecore_2.11.0.v20150123-0347.jar
> r/lib/org.eclipse.emf.ecore.xmi_2.11.0.v20150123-0347.jar
> And they don't contain what to work with OCL, do they ?
>
> To precise a bit, I'm currently working with models (metamodel is
> generic, can be any) on which I need to apply OCL
> constraints/expressions/rules. The OCL is generated programmatically
> (working on that) and I'm trying to model the process (using an
> existing interface such as OCL from EMF or Dresden).
> I'm going through documentation, but it targets a more "tooled" usage.
> I can't find a simple API usage example... Do you have any tips to
> guide me on the first use of your api/library, dear Ed ?
>
> Thanks a lot for your attention, hope your day is a lovely one.
>
> A+
> Edouard
|
|
|
Re: Validating OCL programmatically [message #1697423 is a reply to message #1697422] |
Wed, 03 June 2015 19:59 |
Edouard R. Batot Messages: 100 Registered: March 2015 |
Senior Member |
|
|
Quote:For pure model usage, Eclipse OCL exploits EMF extensibility APIs. There is no OCL in the EMF plugins. But Eclipse OCL implements EMF extension
points so it looks as if OCL is part of EMF.
We're getting close.. I've got the org.eclipse.ocl.[comon, ecore, .].
Thanks for your fast answer.
But, just to make my point, I don't understand what the Manifest, extensions points and exloiting extensivibility of referenced definition.... In a nutshell, I'm not familiar with the vocabulary. But I'm working hard on that too thanks.
Did you get that I just want to apply different OCL expressions (generated from text or modelled through an API) on models loaded from XMI files ? I'm out of any context. No code is to be generated. No OCL editor needed (I automate it programatically).
My first guess is that it should be quite easy : fill a string with OCL, apply on a model and get the Right/Wrong answer. And then incrementaly model the process - if needed. But that first step is a big one as one has to deal with that idiom barrier (I know about modeling and OCL, but the technical part is yet kind of esoteric).
Thanks for your help !
A+
Edouard
|
|
|
Re: Validating OCL programmatically [message #1697425 is a reply to message #1697423] |
Wed, 03 June 2015 20:07 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi
Extension points a fundamental Eclipse extensibility mechanism.
Manifests are a fundamental ? OSGI mechanism.
If you want to add OCL to existing models you should look at Complete OCL.
Regards
Ed Willink
On 03/06/2015 20:59, Edoaurd Batot wrote:
>
> Quote:
>> For pure model usage, Eclipse OCL exploits EMF extensibility APIs.
>> There is no OCL in the EMF plugins. But Eclipse OCL implements EMF
>> extension
>> points so it looks as if OCL is part of EMF.
>
> We're getting close.. I've got the org.eclipse.ocl.[comon, ecore, .].
>
>
> Thanks for your fast answer.
> But, just to make my point, I don't understand what the Manifest,
> extensions points and exloiting extensivibility of referenced
> definition.... In a nutshell, I'm not familiar with the vocabulary.
> But I'm working hard on that too :) thanks.
>
> Did you get that I just want to apply different OCL expressions
> (generated from text or modelled through an API) on models loaded from
> XMI files ? I'm out of any context. No code is to be generated. No OCL
> editor needed (I automate it programatically).
> My first guess is that it should be quite easy : fill a string with
> OCL, apply on a model and get the Right/Wrong answer. And then
> incrementaly model the process - if needed. But that first step is a
> big one as one has to deal with that idiom barrier (I know about
> modeling and OCL, but the technical part is yet kind of esoteric).
>
>
> Thanks for your help !
> A+
> Edouard
|
|
| | |
Validating OCL programmatically : examples needed [message #1697518 is a reply to message #1697429] |
Thu, 04 June 2015 14:40 |
Edouard R. Batot Messages: 100 Registered: March 2015 |
Senior Member |
|
|
Quote:Quote:
>> you should look at Complete OCL
>
Is there anything precise to understand ?
On the first quote I thought I understood very well. You might be suggesting something else.
But that's definitely not what I'm looking for in a community forum. Documentation, I know where to find it. What I put in consideration is the peculiar way that documentation is done and its esotericism. That's an IT documentaion invariant, and we know it.
Another less abstract point is that the Complete OCL you point out explain how to use a GUI ! I don't need to learn how does OCL works, nor how to highlight text, but I'd like to use the EmfOCL classes programmatically.
But well, any help is appreciated.
Examples of the basic use of OCL (outside of the Eclipse plugin) is asked quite often in this forum. Is it that hard to find an easy way to check Ecore models with a String of OCL textual specification (String) ?
Thanks for your attention and collaboration.
Have a good day.
Edouard
PS : Oh, Ed, by the way, as you're the most active on ocl git, would you point me out where to find the test cases used to validate emf ocl ? Someone told me I could find heaps there... but log, when you take the train already runing, looks like a flod.
[Updated on: Thu, 04 June 2015 14:57] Report message to a moderator
|
|
| |
Re: Validating OCL programmatically : examples needed [message #1697530 is a reply to message #1697525] |
Thu, 04 June 2015 15:29 |
Edouard R. Batot Messages: 100 Registered: March 2015 |
Senior Member |
|
|
Hey Ed,
yes, I'm a newbie, and will allways be.
THe problem with documentation is far out of the scope of that topic, but I understand it's a serious issue on how we present our tools. On the other hand, why don't we hire some communication guys to do that communication work ? Don't know, might be the NIH effect.
I'm burning my eyes in documentation days long (when it's not in code) and I know that exploring such a big tool as emf.ocl is a burden task with nobody to guide you. I might be impatient too - my apologize.
Any way, I do thanks you a lot for your help and attention.
About Complete OCL, and OCLinEcore, it just sounds heavy if I need to apply to a profusion of models (hundreds of thousands) a great number of OCL invariants.
Storing in a file, reopening the file, parsing... Imagine I have a little 25 ocl invariants to test on each model, means 25*100000 rounf trip accesses to files in a run. I've got a good caculator, but that's heavy.
THat's why I'm looking for something more basic, more stream-ish, to avoid disk writing/reading. And also something that does not require a click. But it might not be available (yet ).
Quote: It's only software ... almost anything is possible.
Thanks
Reminds me of a japanese concept :
Quote:If you'r looking for an ant tooth in a bag of sand,
You must first find the bag of sand.
|
|
|
Re: Validating OCL programmatically : examples needed [message #1697534 is a reply to message #1697530] |
Thu, 04 June 2015 15:44 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi
On 04/06/2015 16:29, Edoaurd Batot wrote:
> Hey Ed,
>
> yes, I'm a newbie, and will allways be. ;)
Ok. Your ambition is admirable. The irritating thing about Open Source
re-use is that while with bespoke software you can spend all your time
having fun re-inventing the wheel, with re-use, you spend 90% of your
time searching for and understanding what to re-use; not really fun at
all, until you get to re-re-use and then you find your productivity
shooting up.
> THe problem with documentation is far out of the scope of that topic,
> but I understand it's a serious issue on how we present our tools. On
> the other hand, why don't we hire some communication guys to do that
> communication work ? Don't know, might be the NIH effect.
I'd love to, but most of my development time is unfunded, so I'm not
sure who pays the documentation guys.
>
> I'm burning my eyes in documentation days long (when it's not in code)
> and I know that exploring such a big tool as emf.ocl is a burden task
> with nobody to guide you. I might be impatient too - my apologize.
>
> Any way, I do thanks you a lot for your help and attention.
> About Complete OCL, and OCLinEcore, it just sounds heavy if I need to
> apply to a profusion of models (hundreds of thousands) a great number
> of OCL invariants.
> Storing in a file, reopening the file, parsing... Imagine I have a
> little 25 ocl invariants to test on each model, means 25*100000 rounf
> trip accesses to files in a run. I've got a good caculator, but that's
> heavy.
Eclipse OCL provides a direct to Java code generator that is used in
earnest within Eclipse OCL. No run-time parsing.
> THat's why I'm looking for something more basic, more stream-ish, to
> avoid disk writing/reading. And also something that does not require a
> click. But it might not be available (yet :) ).
I cannot recommend too strongly that you follow all the Eclipse OCL
tutorials.
Regards
Ed Willink
|
|
|
Goto Forum:
Current Time: Fri Sep 20 01:26:31 GMT 2024
Powered by FUDForum. Page generated in 0.05222 seconds
|