Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » check OCL constraints as program constraints
check OCL constraints as program constraints [message #714447] Wed, 10 August 2011 10:36 Go to next message
Williams  is currently offline Williams
Messages: 43
Registered: July 2009
Member
I created a Java program which consists of two classes:
class Library {
EList<Book> books;
...
public void addBook(Book book){
...
} // to be tested
}
class Book {
..
}

I want to test whether addBook in Library satisfies an OCL constraint:
books->forAll(b1, b2 | b1 <> b2 implies b1.title <> b2.title)

What I want to do is in another class Test:

Library myLib = new ...
Book b1 = new ...
Book b2 = new ...
....
// set the appropriate info such as title for myLib, b1 and b2.
// add b1 and b2 to myLib

OCL<?, EClassifier, ?, ?, ?, ?, ?, ?, ?, Constraint, EClass, EObject> ocl;
ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
OCLHelper<EClassifier, ?, ?, Constraint> helper = ocl.createOCLHelper();

try {
Constraint invariant = helper.createInvariant(
"books->forAll(b1, b2 | b1 <> b2 implies b1.title <> b2.title)");
System.out.printf("%s valid: %b", myLib.getName(), ocl.check(myLib, invariant));
} catch (...) {...}

I know the above setup is not correct. Then could someone tell me in details about how I should do? Thanks.
Will

Re: check OCL constraints as program constraints [message #714488 is a reply to message #714447] Wed, 10 August 2011 12:08 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi

What you have looks about right, in so far as you've not provided a
class/program/project, but you don't identify any specific problem, and
since it is not practice to write other people's programs, I cannot help
without a specific problem to resolve. The lack of any mention of a
metamodel is suspicious. Look at the Parsing Constraints example in the
Indigo documentation which I debugged; the Helios version has minor
problems that are likely to confuse novices.

Regards

Ed Willink


On 10/08/2011 15:36, Williams wrote:
> I created a Java program which consists of two classes:
> class Library {
> EList<Book> books;
> ...
> public void addBook(Book book){
> ...
> } // to be tested
> }
> class Book {
> ..
> }
>
> I want to test whether addBook in Library satisfies an OCL constraint:
> books->forAll(b1, b2 | b1 <> b2 implies b1.title <> b2.title)
>
> What I want to do is in another class Test:
>
> Library myLib = new ...
> Book b1 = new ...
> Book b2 = new ...
> ....
> // set the appropriate info such as title for myLib, b1 and b2.
> // add b1 and b2 to myLib
>
> OCL<?, EClassifier, ?, ?, ?, ?, ?, ?, ?, Constraint, EClass, EObject>
> ocl;
> ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
> OCLHelper<EClassifier, ?, ?, Constraint> helper = ocl.createOCLHelper();
>
> try {
> Constraint invariant = helper.createInvariant(
> "books->forAll(b1, b2 | b1 <> b2 implies b1.title <> b2.title)");
> System.out.printf("%s valid: %b", myLib.getName(),
> ocl.check(myLib, invariant));
> } catch (...) {...}
>
> I know the above setup is not correct. Then could someone tell me in
> details about how I should do? Thanks.
> Will
>
Re: check OCL constraints as program constraints [message #714493 is a reply to message #714488] Wed, 10 August 2011 12:39 Go to previous messageGo to next message
Williams  is currently offline Williams
Messages: 43
Registered: July 2009
Member
Thanks for your reply, Ed. What I want to do is to check whether
a state after calling a method such as addBook() still satisfies
the OCL constraint, ie not two books owned by a library have the
same title. So, there is no metamodel. Or, the metamodel is the
java program with Classes Library and Book where the OCL constraint
is attached. To me, checking the OCL is the runtime state. So, what
should I do? Unfortunately, I use the Helious version...
Will

Edward Willink wrote on Wed, 10 August 2011 12:08
Hi

What you have looks about right, in so far as you've not provided a
class/program/project, but you don't identify any specific problem, and
since it is not practice to write other people's programs, I cannot help
without a specific problem to resolve. The lack of any mention of a
metamodel is suspicious. Look at the Parsing Constraints example in the
Indigo documentation which I debugged; the Helios version has minor
problems that are likely to confuse novices.

Regards

Ed Willink

>

Re: check OCL constraints as program constraints [message #714544 is a reply to message #714493] Wed, 10 August 2011 15:20 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi

Use of meta-models is fundamental to use of models. Some tools are
fairly liberal in terms of what is a model and a meta-model and can
sometimes deduce them. Eclipse OCL currently requires an Ecore or UML
meta-model. EMF can auto-generate a meta-model from annotated Java classes.

Regards

Ed Willink

On 10/08/2011 17:39, Williams wrote:
> Thanks for your reply, Ed. What I want to do is to check whether
> a state after calling a method such as addBook() still satisfies
> the OCL constraint, ie not two books owned by a library have the
> same title. So, there is no metamodel. Or, the metamodel is the
> java program with Classes Library and Book where the OCL constraint
> is attached. To me, checking the OCL is the runtime state. So, what
> should I do? Unfortunately, I use the Helious version...
> Will
>
> Edward Willink wrote on Wed, 10 August 2011 12:08
>> Hi
>>
>> What you have looks about right, in so far as you've not provided a
>> class/program/project, but you don't identify any specific problem,
>> and since it is not practice to write other people's programs, I
>> cannot help without a specific problem to resolve. The lack of any
>> mention of a metamodel is suspicious. Look at the Parsing Constraints
>> example in the Indigo documentation which I debugged; the Helios
>> version has minor problems that are likely to confuse novices.
>>
>> Regards
>>
>> Ed Willink
>>
>> >
>
>
Re: check OCL constraints as program constraints [message #714547 is a reply to message #714544] Wed, 10 August 2011 15:41 Go to previous messageGo to next message
Williams  is currently offline Williams
Messages: 43
Registered: July 2009
Member
Ed,
OK. I see what you mean. From the OCL Validation Example, we can
run the plugin and then create EXTLibrary model to add some new
library, book, and writer objects etc. Then click on the Validate
button to check the OCL constraints provided in the OCL validation
plugin. Now, I want to write a program to produce those objects
and then call ocl.check() to check my own OCL constraint on a specific
object such as myLib at some point such as after addBooks(...) is called.
How can I do that based on my previous program? Thanks.
Will


Edward Willink wrote on Wed, 10 August 2011 15:20
Hi

Use of meta-models is fundamental to use of models. Some tools are
fairly liberal in terms of what is a model and a meta-model and can
sometimes deduce them. Eclipse OCL currently requires an Ecore or UML
meta-model. EMF can auto-generate a meta-model from annotated Java classes.

Regards

Ed Willink

On 10/08/2011 17:39, Williams wrote:
> Thanks for your reply, Ed. What I want to do is to check whether
> a state after calling a method such as addBook() still satisfies
> the OCL constraint, ie not two books owned by a library have the
> same title. So, there is no metamodel. Or, the metamodel is the
> java program with Classes Library and Book where the OCL constraint
> is attached. To me, checking the OCL is the runtime state. So, what
> should I do? Unfortunately, I use the Helious version...
> Will
>
> Edward Willink wrote on Wed, 10 August 2011 12:08
>> Hi
>>
>> What you have looks about right, in so far as you've not provided a
>> class/program/project, but you don't identify any specific problem,
>> and since it is not practice to write other people's programs, I
>> cannot help without a specific problem to resolve. The lack of any
>> mention of a metamodel is suspicious. Look at the Parsing Constraints
>> example in the Indigo documentation which I debugged; the Helios
>> version has minor problems that are likely to confuse novices.
>>
>> Regards
>>
>> Ed Willink
>>
>> >
>
>

Re: check OCL constraints as program constraints [message #714552 is a reply to message #714547] Wed, 10 August 2011 16:03 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi

You have to have a meta-model.
- a *.ecore file
- a *.uml file
- Java classes generated from a *.ecore file

your 'program' had root class declarations, so they look like none of
the above.

One day Eclipse OCL might exploit Java reflection to deduce the
meta-model, but it's
way off the priority list.

Regards

Ed Willink

On 10/08/2011 20:41, Williams wrote:
> Ed,
> OK. I see what you mean. From the OCL Validation Example, we can
> run the plugin and then create EXTLibrary model to add some new
> library, book, and writer objects etc. Then click on the Validate
> button to check the OCL constraints provided in the OCL validation
> plugin. Now, I want to write a program to produce those objects
> and then call ocl.check() to check my own OCL constraint on a specific
> object such as myLib at some point such as after addBooks(...) is called.
> How can I do that based on my previous program? Thanks.
> Will
>
>
> Edward Willink wrote on Wed, 10 August 2011 15:20
>> Hi
>>
>> Use of meta-models is fundamental to use of models. Some tools are
>> fairly liberal in terms of what is a model and a meta-model and can
>> sometimes deduce them. Eclipse OCL currently requires an Ecore or UML
>> meta-model. EMF can auto-generate a meta-model from annotated Java
>> classes.
>>
>> Regards
>>
>> Ed Willink
>>
>> On 10/08/2011 17:39, Williams wrote:
>> > Thanks for your reply, Ed. What I want to do is to check whether
>> > a state after calling a method such as addBook() still satisfies
>> > the OCL constraint, ie not two books owned by a library have the
>> > same title. So, there is no metamodel. Or, the metamodel is the
>> > java program with Classes Library and Book where the OCL constraint
>> > is attached. To me, checking the OCL is the runtime state. So, what
>> > should I do? Unfortunately, I use the Helious version...
>> > Will
>> >
>> > Edward Willink wrote on Wed, 10 August 2011 12:08
>> >> Hi
>> >>
>> >> What you have looks about right, in so far as you've not provided
>> a >> class/program/project, but you don't identify any specific
>> problem, >> and since it is not practice to write other people's
>> programs, I >> cannot help without a specific problem to resolve. The
>> lack of any >> mention of a metamodel is suspicious. Look at the
>> Parsing Constraints >> example in the Indigo documentation which I
>> debugged; the Helios >> version has minor problems that are likely to
>> confuse novices.
>> >>
>> >> Regards
>> >>
>> >> Ed Willink
>> >>
>> >> >
>> >
>> >
>
>
Re: check OCL constraints as program constraints [message #714560 is a reply to message #714552] Wed, 10 August 2011 17:00 Go to previous messageGo to next message
Williams  is currently offline Williams
Messages: 43
Registered: July 2009
Member
Edward Willink wrote on Wed, 10 August 2011 16:03
Hi

You have to have a meta-model.
- a *.ecore file
- a *.uml file
- Java classes generated from a *.ecore file




OK. Let me assume I have these files. Then after setting
up the objects in a Java program, how can my java program
call ocl.check(...)? I use the Helios version. Thanks.
Will
Re: check OCL constraints as program constraints [message #714617 is a reply to message #714560] Thu, 11 August 2011 01:27 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi

Any approach with meta-models will today result in your classes
implementing EObject (and EObject.eClass() and EObject.eGet()). The
current OCL evaluator assumes these.

The increased flexibility of the upcoming direct OCL to Java code
generator may make use of non-EObject models relatively easy, but today
use EObject; why don't you use EMF for your models; it is amazingly
powerful and if you use MinimalEObject can be surprsingly low footprint.

Regards

Ed Willink

On 10/08/2011 22:00, Williams wrote:
> Edward Willink wrote on Wed, 10 August 2011 16:03
>> Hi
>>
>> You have to have a meta-model.
>> - a *.ecore file
>> - a *.uml file
>> - Java classes generated from a *.ecore file
>
>
>
> OK. Let me assume I have these files. Then after setting
> up the objects in a Java program, how can my java program
> call ocl.check(...)? I use the Helios version. Thanks.
> Will
Re: check OCL constraints as program constraints [message #714845 is a reply to message #714617] Thu, 11 August 2011 11:34 Go to previous messageGo to next message
Williams  is currently offline Williams
Messages: 43
Registered: July 2009
Member
Ed,
Thanks for the reply. The reason is that I would like to investigate
whether MDT OCL can be applied to any Java program that is derived from
a tool other than EMF. Right, it seems MDT OCL can only be applied to a
Java program generated by EMF, right?

Assume my previous code Classes Library and Book are generated from
EMF. Instead of running the plugin to produce the 2nd eclipse to create
instances of these two classes, how can I set up in a Java program before
calling (I use the the Helios version):
ocl.check(myLib, invariant)

Last, what do you mean "MinimalEObject" and "if you use MinimalEObject can be surprisingly low footprint" respectively?
Thanks.
Will


Edward Willink wrote on Thu, 11 August 2011 01:27
Hi

Any approach with meta-models will today result in your classes
implementing EObject (and EObject.eClass() and EObject.eGet()). The
current OCL evaluator assumes these.

The increased flexibility of the upcoming direct OCL to Java code
generator may make use of non-EObject models relatively easy, but today
use EObject; why don't you use EMF for your models; it is amazingly
powerful and if you use MinimalEObject can be surprsingly low footprint.

Regards

Ed Willink

On 10/08/2011 22:00, Williams wrote:
> Edward Willink wrote on Wed, 10 August 2011 16:03
>> Hi
>>
>> You have to have a meta-model.
>> - a *.ecore file
>> - a *.uml file
>> - Java classes generated from a *.ecore file
>
>
>
> OK. Let me assume I have these files. Then after setting
> up the objects in a Java program, how can my java program
> call ocl.check(...)? I use the Helios version. Thanks.
> Will

Re: check OCL constraints as program constraints [message #714899 is a reply to message #714845] Thu, 11 August 2011 13:36 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi Will
> Thanks for the reply. The reason is that I would like to investigate
> whether MDT OCL can be applied to any Java program that is derived from
> a tool other than EMF. Right, it seems MDT OCL can only be applied to a
> Java program generated by EMF, right?
>
In practice, yes. For a real enthusiast an additional MDT/OCL binding
for Java could be done.
> Assume my previous code Classes Library and Book are generated from
> EMF. Instead of running the plugin to produce the 2nd eclipse to create
> instances of these two classes, how can I set up in a Java program before
> calling (I use the the Helios version): ocl.check(myLib, invariant)
>
It is no longer necessary to use a second run-time Eclipse. Dynamic EMF
automatically creates DynamicEObjects from XML model elements, and the
OCL Console can evaluate expressions on them. If you avoid writing code
that assumes either Static or Dynamic EMF, the same should work for you too.
> Last, what do you mean "MinimalEObject" and "if you use
> MinimalEObject can be surprisingly low footprint" respectively?
EMF uses the EObject interface polymorphically. By default this is
realised by BasicEObject. However you can adjust genmodel options to use
alternate performance tradeoffs. MinimalEObject is the lowest footprint
(memory overhead). Not recommended for novices.

Regards

Ed Willink
Re: check OCL constraints as program constraints [message #714945 is a reply to message #714899] Thu, 11 August 2011 16:49 Go to previous messageGo to next message
Williams  is currently offline Williams
Messages: 43
Registered: July 2009
Member
Edward Willink wrote on Thu, 11 August 2011 13:36
Hi Will


It is no longer necessary to use a second run-time Eclipse. Dynamic EMF
automatically creates DynamicEObjects from XML model elements, and the
OCL Console can evaluate expressions on them. If you avoid writing code
that assumes either Static or Dynamic EMF, the same should work for you too.


So, in the Dynamic EMF, I need to use EcoreFactory and createEXXX() to
create classes, attributes and objects. Also, eSet should be used to set a
value for an attribute for each object. Next, serialize the dynamic
model instance and the metamodel. Last, I can set up the OCL environment
to evaluate ocl expressions, right?

What do you mean about the last sentence? Is there any other way to evaluate
ocl expressions? Thanks.
Will
Re: check OCL constraints as program constraints [message #714955 is a reply to message #714945] Thu, 11 August 2011 17:36 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4014
Registered: July 2009
Senior Member
Hi

I'm struggling to give you sensible answers because I really do not
understand why you are trying to do such advanced things with seemingly
rather limited understanding of the capabilities of EMF.

Creating dynamic EMF programmatically is possible, but seriously
perverse. If you are going to write Java code to create then you can
certainly run genmodel to have first class models.

I suggest studying the EMF book.

Regards

Ed Willink


On 11/08/2011 21:49, Williams wrote:
> Edward Willink wrote on Thu, 11 August 2011 13:36
>> Hi Will
>>
>>
>> It is no longer necessary to use a second run-time Eclipse. Dynamic
>> EMF automatically creates DynamicEObjects from XML model elements,
>> and the OCL Console can evaluate expressions on them. If you avoid
>> writing code that assumes either Static or Dynamic EMF, the same
>> should work for you too.
>
>
> So, in the Dynamic EMF, I need to use EcoreFactory and createEXXX() to
> create classes, attributes and objects. Also, eSet should be used to
> set a value for an attribute for each object. Next, serialize the dynamic
> model instance and the metamodel. Last, I can set up the OCL environment
> to evaluate ocl expressions, right?
> What do you mean about the last sentence? Is there any other way to
> evaluate
> ocl expressions? Thanks.
> Will
Previous Topic:OCL expression subset editor
Next Topic:at() in OCLinEcore
Goto Forum:
  


Current Time: Wed Jul 30 23:34:06 EDT 2014

Powered by FUDForum. Page generated in 0.09482 seconds