Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » [OCL-ECORE-JAVA] OCL Queries on Ecore model from Java code.
[OCL-ECORE-JAVA] OCL Queries on Ecore model from Java code. [message #633591] Mon, 18 October 2010 13:40 Go to next message
Dave  is currently offline Dave Friend
Messages: 37
Registered: September 2010
Member
Hi all,

I'm trying to execute an OCL query on an Ecore model, from Java code, but I've got some difficulties and I hope someone could help me.

I've written the following method:

public static IQueryResult execute(Resource ecoreResource, String query) {
	System.out.println("Received " + ecoreResource);
	OCL ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
	Condition condition;
	IQueryResult results = null;
	try {
		condition = new BooleanOCLCondition<EClassifier, EClass, EObject>(ocl.getEnvironment(),query,null);
		SELECT statement = new SELECT(SELECT.UNBOUNDED, false,
					new FROM(ecoreResource.getContents()), new WHERE((EObjectCondition) condition), new NullProgressMonitor() );
		results = statement.execute();
	} catch (ParserException e) {
		e.printStackTrace();
	}
	return results;
}


This method, is invoked by the following main of the Java class:


public static void main(String[] args) throws IOException {
	// Create a resource set to hold the resources.
	ResourceSet resourceSet = new ResourceSetImpl();
	URI modelUri = URI.createFileURI(new File("model/systemModel.ecore").getAbsolutePath());
	
	EcoreResourceFactoryImpl ecoreFactory = new EcoreResourceFactoryImpl();		
	resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("ecore", ecoreFactory);
	
	// Register the package to ensure it is available during loading.
	resourceSet.getPackageRegistry().put
		(MancoosiPackage.eNS_URI, 
		 MancoosiPackage.eINSTANCE);
	
	// Demand load resource for this file.
	Resource resource = resourceSet.getResource(modelUri, true);
	System.out.println("Loaded " + modelUri);
	
	IQueryResult res = QueryExecutor.execute(resource, "mancoosi::InstalledPackage.allInstances()->exists(c | c.installedSize > 259)");	
	java.util.Iterator iterator = res.iterator();
	while(iterator.hasNext()) {
		System.out.println(iterator.next().toString());
	}
	System.out.println("SIZE: " + res.size());
	System.out.println("OCL Query execution terminated.");
}


As you can see, the main method passes the ecore model (resource) and the String representing the OCL query. Moreover, the while statement provides just a feedback for realizing what the execution has actually produced. Such feedback, reported in the output console when the main is executed, seems to be the list of all the (15631...?) elements in the ecore model.
I report the last part of the produced output, for givin' you an idea of what I'm talkin' about:

mancoosi.impl.SingleDepImpl@9bfee2 (version: ge, value: 1:0.3-1)
mancoosi.impl.SingleDepImpl@98cbf7 (version: ge, value: 2.3.18)
mancoosi.impl.SingleDepImpl@1deb5f7 (version: ge, value: 0.5)
mancoosi.impl.SingleDepImpl@eb9f58 (version: ge, value: 2.15.4)
mancoosi.impl.FileImpl@17f61bb (name: 70-modules-unload.sh) (extension: null, description: null, size: 0, checkSum: null, isDirectory: false, suid: false, guid: false, permission: -rwxr-xr-x, location: /etc/acpi/suspend.d/70-modules-unload.sh, isMissing: false)
mancoosi.impl.SingleDepImpl@157bf4c (version: ge, value: 2.2.11~dfsg1-3ubuntu2~)
mancoosi.impl.NotInstalledPackageImpl@486d1d (name: xtel) (version: null)
mancoosi.impl.SingleConflictImpl@9b777a (version: llt, value: 22.1-0ubuntu10.1)
mancoosi.impl.FileImpl@101f23d (name: tosh-mute) (extension: null, description: null, size: 0, checkSum: null, isDirectory: false, suid: false, guid: false, permission: -rw-r--r--, location: /etc/acpi/events/tosh-mute, isMissing: false)
mancoosi.impl.SingleConflictImpl@16396f5 (version: le, value: 1.3.0)
mancoosi.impl.AndConflictImpl@9b774e
mancoosi.impl.SingleDepImpl@1eb8f71 (version: ge, value: 0.5.8.1)
mancoosi.impl.SingleDepImpl@11c9fcc (version: ge, value: 1:1.0.0)
mancoosi.impl.AndDepImpl@126cdd1
mancoosi.impl.SingleDepImpl@1eb8f6d (version: eq, value: null)
mancoosi.impl.FileImpl@d4927f (name: text.fr-2007.tbl) (extension: null, description: null, size: 0, checkSum: null, isDirectory: false, suid: false, guid: false, permission: -rw-r--r--, location: /etc/brltty/text.fr-2007.tbl, isMissing: false)
mancoosi.impl.SingleConflictImpl@1f4c4a3 (version: eq, value: null)
mancoosi.impl.SingleDepImpl@8c2d23 (version: eq, value: null)
mancoosi.impl.SingleDepImpl@9c87c1 (version: ge, value: 1:2.17.90)
SIZE: 15631
OCL Query execution terminated. 


However, it doesn't seem to be correct, because, as you can see, the query result contains instances of mancoosi.impl.NotInstalledPackageImpl, but the query is "mancoosi::InstalledPackage.allInstances()->exists(c | c.installedSize > 259)", so NotInstalledPackages cannot be returned. In conclusion, the query seems to be executed, but there something wrong in the result.

I hope someone could help me.

Many thanks in advance,
Dave.

[Updated on: Mon, 18 October 2010 13:41]

Report message to a moderator

Re: [OCL-ECORE-JAVA] OCL Queries on Ecore model from Java code. [message #633648 is a reply to message #633591] Mon, 18 October 2010 15:54 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Dave

Whether NotInstalledPackages should be returned depends on the
meta-model which you haven't provided.

If NotInstalledPackages generalises InstalledPackage then it can be
returned.

OCL queries are very compact and powerful, but very easy to get wrong. I
don't often get a non-trivial query right first time.

I strongly recommend using the Interactive OCL Console to practice your
queries, gradually building up complexity.

Regards

Ed Willink
On 18/10/2010 14:40, Dave wrote:
> Hi all,
>
> I'm trying to execute an OCL query on an Ecore model, from Java code,
> but I've got some difficulties and I hope someone could help me.
>
> I've written the following method:
>
> public static IQueryResult execute(Resource ecoreResource, String
> query) {
> System.out.println("Received " + ecoreResource);
> OCL ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
> Condition condition;
> IQueryResult results = null;
> try {
> condition = new BooleanOCLCondition<EClassifier, EClass,
> EObject>(ocl.getEnvironment(),query,null);
> SELECT statement = new SELECT(SELECT.UNBOUNDED, false,
> new FROM(ecoreResource.getContents()), new
> WHERE((EObjectCondition) condition), new NullProgressMonitor() );
> results = statement.execute();
> } catch (ParserException e) {
> e.printStackTrace();
> }
> return results;
> }
>
> This method, is invoked by the following main of the Java class:
>
>
> public static void main(String[] args) throws IOException {
> // Create a resource set to hold the resources.
> ResourceSet resourceSet = new ResourceSetImpl();
> URI modelUri = URI.createFileURI(new
> File("model/systemModel.ecore").getAbsolutePath());
>
> EcoreResourceFactoryImpl ecoreFactory = new
> EcoreResourceFactoryImpl();
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "ecore",
> ecoreFactory);
>
> // Register the package to ensure it is available during loading.
> resourceSet.getPackageRegistry().put
> (MancoosiPackage.eNS_URI, MancoosiPackage.eINSTANCE);
>
> // Demand load resource for this file.
> Resource resource = resourceSet.getResource(modelUri, true);
> System.out.println("Loaded " + modelUri);
>
> IQueryResult res = QueryExecutor.execute(resource,
> "mancoosi::InstalledPackage.allInstances()->exists(c | c.installedSize
> > 259)");
> java.util.Iterator iterator = res.iterator();
> while(iterator.hasNext()) {
> System.out.println(iterator.next().toString());
> }
> System.out.println("SIZE: " + res.size());
> System.out.println("OCL Query execution terminated.");
> }
>
> As you can see, the main method passes the ecore model (resource) and
> the String representing the OCL query. Moreover, the while statement
> provides just a feedback for realizing what the execution has actually
> produced. Such feedback, reported in the output console when the main
> is executed, seems to be the list of all the (15631...?) elements in
> the ecore model.
> I report the last part of the produced output, for givin' you an idea
> of what I'm talkin' about:
>
> mancoosi.impl.SingleDepImpl@9bfee2 (version: ge, value: 1:0.3-1)
> mancoosi.impl.SingleDepImpl@98cbf7 (version: ge, value: 2.3.18)
> mancoosi.impl.SingleDepImpl@1deb5f7 (version: ge, value: 0.5)
> mancoosi.impl.SingleDepImpl@eb9f58 (version: ge, value: 2.15.4)
> mancoosi.impl.FileImpl@17f61bb (name: 70-modules-unload.sh)
> (extension: null, description: null, size: 0, checkSum: null,
> isDirectory: false, suid: false, guid: false, permission: -rwxr-xr-x,
> location: /etc/acpi/suspend.d/70-modules-unload.sh, isMissing: false)
> mancoosi.impl.SingleDepImpl@157bf4c (version: ge, value:
> 2.2.11~dfsg1-3ubuntu2~)
> mancoosi.impl.NotInstalledPackageImpl@486d1d (name: xtel) (version: null)
> mancoosi.impl.SingleConflictImpl@9b777a (version: llt, value:
> 22.1-0ubuntu10.1)
> mancoosi.impl.FileImpl@101f23d (name: tosh-mute) (extension: null,
> description: null, size: 0, checkSum: null, isDirectory: false, suid:
> false, guid: false, permission: -rw-r--r--, location:
> /etc/acpi/events/tosh-mute, isMissing: false)
> mancoosi.impl.SingleConflictImpl@16396f5 (version: le, value: 1.3.0)
> mancoosi.impl.AndConflictImpl@9b774e
> mancoosi.impl.SingleDepImpl@1eb8f71 (version: ge, value: 0.5.8.1)
> mancoosi.impl.SingleDepImpl@11c9fcc (version: ge, value: 1:1.0.0)
> mancoosi.impl.AndDepImpl@126cdd1
> mancoosi.impl.SingleDepImpl@1eb8f6d (version: eq, value: null)
> mancoosi.impl.FileImpl@d4927f (name: text.fr-2007.tbl) (extension:
> null, description: null, size: 0, checkSum: null, isDirectory: false,
> suid: false, guid: false, permission: -rw-r--r--, location:
> /etc/brltty/text.fr-2007.tbl, isMissing: false)
> mancoosi.impl.SingleConflictImpl@1f4c4a3 (version: eq, value: null)
> mancoosi.impl.SingleDepImpl@8c2d23 (version: eq, value: null)
> mancoosi.impl.SingleDepImpl@9c87c1 (version: ge, value: 1:2.17.90)
> SIZE: 15631
> OCL Query execution terminated.
> However, it doesn't seem to be correct, because, as you can see, the
> query result contains instances of
> mancoosi.impl.NotInstalledPackageImpl, but the query is
> "mancoosi::InstalledPackage.allInstances()->exists(c | c.installedSize
> > 259)", so NotInstalledPackages cannot be returned. In conclusion,
> the query seems to be executed, but there something wrong in the result.
>
> I think someone could help me.
>
> Many thanks in advance,
> Dave.
Re: [OCL-ECORE-JAVA] OCL Queries on Ecore model from Java code. [message #633833 is a reply to message #633648] Tue, 19 October 2010 14:44 Go to previous messageGo to next message
Dave  is currently offline Dave Friend
Messages: 37
Registered: September 2010
Member
Hi Edward,

Thanks for your reply.

I precise that NotInstalledPackage doesn't generalize InstalledPackage, so returning also that kind of elements is wrong.

However, after several efforts, I've done a little progress. In fact, with the following statement

IQueryResult res = QueryExecutor.execute(resource, "self.oclIsTypeOf(mancoosi::InstalledPackage)");


it returns all the InstalledPackageImpl elements. Moreover, I can obtain NotInstalledPackage elements adding "Not" at the beginning of the previous statement.
Unfortunately, I cannot manage more complex queries. For example, trying to obtain all the InstalledPackage elements having installedSize < 85, I've tryed the following lines:

IQueryResult res = QueryExecutor.execute(resource, "self.oclIsTypeOf(mancoosi::InstalledPackage).installedSize < 85");


and

IQueryResult res = QueryExecutor.execute(resource, "self.oclIsTypeOf(mancoosi::InstalledPackage).getInstalledSize() < 85");


but the program throws the exception

Exception in thread "main" java.lang.ExceptionInInitializerError
	at org.eclipse.emf.query.ocl.internal.OCLPlugin.catching(OCLPlugin.java:480)
	at org.eclipse.emf.query.ocl.conditions.AbstractOCLCondition.getOCLQueryRecord(AbstractOCLCondition.java:366)
	at org.eclipse.emf.query.ocl.conditions.AbstractOCLCondition.isSatisfied(AbstractOCLCondition.java:289)
	at org.eclipse.emf.query.ocl.conditions.BooleanOCLCondition.isSatisfied(BooleanOCLCondition.java:230)
	at org.eclipse.emf.query.statements.WHERE.matches(WHERE.java:46)
	at org.eclipse.emf.query.statements.SELECT.doResume(SELECT.java:131)
	at org.eclipse.emf.query.statements.SELECT.doExecute(SELECT.java:95)
	at org.eclipse.emf.query.internal.statements.QueryStatement.execute(QueryStatement.java:77)
	at org.eclipse.emf.query.statements.SELECT.execute(SELECT.java:172)
	at mancoosi.failuresdetector.QueryExecutor.execute(QueryExecutor.java:75)
	at mancoosi.failuresdetector.QueryExecutor.main(QueryExecutor.java:149)
Caused by: java.lang.NullPointerException
	at org.eclipse.emf.query.ocl.internal.OCLDebugOptions.<clinit>(OCLDebugOptions.java:29)
	... 11 more


I've not so clear how to structure my queries...think that also the allInstances() operation seems to be not available...

Regarding the use of the Interactive OCL Console, I've tested the execution of several OCL queries and it obviously works.
For example, for obtaining the InstalledPackage(s) having installedSize < 85, it's sufficient to write the following OCL query:

mancoosi::InstalledPackage.allInstances()->select(p | p.installedSize < 85)


that is, among other things, what I would like to pass as query in my Java code...

I hope you could help me. Thamks for your consideration.

Dave.

[Updated on: Tue, 19 October 2010 14:48]

Report message to a moderator

Re: [OCL-ECORE-JAVA] OCL Queries on Ecore model from Java code. [message #633883 is a reply to message #633833] Tue, 19 October 2010 16:53 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Dave

> Regarding the use of the Interactive OCL Console, I've tested the
execution of several OCL queries and it obviously works.

Well, this is the MDT/OCL newsgroup so MDT/OCL seems to be working.

Your problems are with the EMF Query project; copying to EMFT newsgroup.

> Exception in thread "main" java.lang.ExceptionInInitializerError

often indicates a classpath/startup problem.

> Caused by: java.lang.NullPointerException
at
org.eclipse.emf.query.ocl.internal.OCLDebugOptions.<clinit>(OCLDebugOptions.java:29)

would occur if you are running standalone, since plugins are not
initialised.

Perhaps EMF Query does not support standalone operation.

Perhaps you would be alright if it weren't for yet another exception
that you haven't shown. What you show is what happens after a failure,
not what the first failure was.

You might try commenting out

OCLPlugin.catching(getClass(), "getOCLQueryRecord",
ex); //$NON-NLS-1$

in AbstractOCLCondition since that seems to be the only external
reference that causes OCLPlugin and OCLDebugOptions to be initialized.
It looks as if standalone initialization of some debug code is causing a
failure that then fails to be debugged successfully.

Regards

Ed Willink


On 19/10/2010 15:44, Dave wrote:
> Hi Edward,
>
> Thanks for your reply.
>
> I precise that NotInstalledPackage doesn't generalize
> InstalledPackage, so returning also that kind of elements is wrong.
>
> However, after several efforts, I've done a little progress. In fact,
> with the following statement
>
> IQueryResult res = QueryExecutor.execute(resource,
> "self.oclIsTypeOf(mancoosi::InstalledPackage)");
>
> it returns all the InstalledPackageImpl elements. Moreover, I can
> obtain NotInstalledPackage elements adding "Not" at the beginning of
> the previous statement.
> Unfortunately, I cannot manage more complex queries. For example,
> trying to obtain all the InstalledPackage elements having
> installedSize < 85, I've written the following line:
>
> IQueryResult res = QueryExecutor.execute(resource,
> " self.oclIsTypeOf(mancoosi::InstalledPackage).getInstalledSiz e() < 85");
>
> but the program throws the exception
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at
> org.eclipse.emf.query.ocl.internal.OCLPlugin.catching(OCLPlu gin.java:480)
> at
> org.eclipse.emf.query.ocl.conditions.AbstractOCLCondition.ge tOCLQueryRecord(AbstractOCLCondition.java:366)
> at
> org.eclipse.emf.query.ocl.conditions.AbstractOCLCondition.is Satisfied(AbstractOCLCondition.java:289)
> at
> org.eclipse.emf.query.ocl.conditions.BooleanOCLCondition.isS atisfied(BooleanOCLCondition.java:230)
> at org.eclipse.emf.query.statements.WHERE.matches(WHERE.java:46 )
> at org.eclipse.emf.query.statements.SELECT.doResume(SELECT.java :131)
> at org.eclipse.emf.query.statements.SELECT.doExecute(SELECT.jav a:95)
> at
> org.eclipse.emf.query.internal.statements.QueryStatement.exe cute(QueryStatement.java:77)
> at org.eclipse.emf.query.statements.SELECT.execute(SELECT.java: 172)
> at
> mancoosi.failuresdetector.QueryExecutor.execute(QueryExecuto r.java:75)
> at
> mancoosi.failuresdetector.QueryExecutor.main(QueryExecutor.j ava:149)
> Caused by: java.lang.NullPointerException
> at
> org.eclipse.emf.query.ocl.internal.OCLDebugOptions.<clinit>(OCLDebugOptions.java:29)
> ... 11 more
>
> I've not so clear how to structure my queries...think that also the
> allInstances() operation seems to be not available...
>
> Regarding the use of the Interactive OCL Console, I've tested the
> execution of several OCL queries and it obviously works.
> For example, for obtaining the InstalledPackage(s) having
> installedSize < 85, it's sufficient to write the following OCL query:
>
> mancoosi::InstalledPackage.allInstances()->select(p | p.installedSize
> < 85)
>
> that is, among other things, what I would like to pass as query in my
> Java code...
>
> I hope you could help me. Thamks for your consideration.
>
> Dave.
Previous Topic:[OCLInEcore] Change default error messages
Next Topic:How to use EType "Sequence"
Goto Forum:
  


Current Time: Thu Apr 25 09:25:11 GMT 2024

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

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

Back to the top