Home » Modeling » OCL » parsing OCL def: statements in an .ocl file
| parsing OCL def: statements in an .ocl file [message #21220] |
Tue, 01 May 2007 13:24  |
 Miguel Garcia
Messages: 40
Registered: July 2009 |
Member |
|
|
Hi,
I'm parsing def: statements coming in different shapes and sizes. So far,
I'm getting their ASTs as follows:
EClassifier personEClass = pPackage.getEClassifier("Person");
oh.setContext(personEClass);
EStructuralFeature sf = oh.defineAttribute("name : String = 'abc'");
sf = oh.defineAttribute("names : Sequence(String) = Sequence{'a', 'b', 'c'}
");
sf = oh.defineAttribute("setOfBagOfPerson : Set(Bag(Person)) = Set{Bag{}}
");
sf = oh.defineAttribute("t : Tuple (a : String, b : Integer) = Tuple{ a =
'a', b = 0}");
Which works ok.
I'm attempting next to have those def: statements parsed from an .ocl file,
but I'm missing sthg:
OCLInput oi = new OCLInput(oclFile.getContents());
OCL oclFacade = OCL.newInstance();
oclFacade.setParseTracingEnabled(true);
oclFacade.setEvaluationTracingEnabled(true);
EPackage pPackage = (EPackage) ecoreResource.getContents().get(0);
org.eclipse.emf.ecore.EPackage.Registry.INSTANCE.put(pPackag e.getNsURI(),
pPackage);
// sthg missing???
List<Constraint> cts = oclFacade.parse(oi);
Somehow I should let the OCL facade know about the particular target .ecore,
right? Help on this is appreciated.
Miguel
|
|
|
| Re: parsing OCL def: statements in an .ocl file [message #21235 is a reply to message #21220] |
Tue, 01 May 2007 15:18  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Miguel,
What error messages are you getting?
Rather than using the global package registry, you can also construct your
OCL instance with an EcoreEnvironmentFactory initialized with some
arbitrary EPackage.Registry (perhaps a resource set's local registry).
Given the registry in which to look up packages, your OCL document can then
declare the package context thus:
package employee
context Person
inv: -- some constraint
-- other constraints and/or contexts
endpackage
package ...
endpackage
...
An alternative to the package context declarations is to initialize the OCL
instance with a particular EcoreEnvironment that already has a context
package:
EcoreEnvironmentFactory factory = new EcoreEnvironmentFactory(registry);
Environment<...> globalEnv = factory.createEnvironment();
Environment<...> packageEnv = factory.createPackageContext(globalEnv,
Collections.singletonList("employee"));
OCL ocl = OCL.newInstance(packageEnv);
Perhaps there ought to be a createPackageContext(Environment, EPackage)
method to make this a little more straight-forward.
HTH,
Christian
Miguel Garcia wrote:
>
> Hi,
>
> I'm parsing def: statements coming in different shapes and sizes. So far,
> I'm getting their ASTs as follows:
>
> EClassifier personEClass = pPackage.getEClassifier("Person");
> oh.setContext(personEClass);
> EStructuralFeature sf = oh.defineAttribute("name : String = 'abc'");
> sf = oh.defineAttribute("names : Sequence(String) = Sequence{'a', 'b',
> 'c'} ");
> sf = oh.defineAttribute("setOfBagOfPerson : Set(Bag(Person)) = Set{Bag{}}
> ");
> sf = oh.defineAttribute("t : Tuple (a : String, b : Integer) = Tuple{ a =
> 'a', b = 0}");
>
> Which works ok.
> I'm attempting next to have those def: statements parsed from an .ocl
> file, but I'm missing sthg:
>
> OCLInput oi = new OCLInput(oclFile.getContents());
> OCL oclFacade = OCL.newInstance();
> oclFacade.setParseTracingEnabled(true);
> oclFacade.setEvaluationTracingEnabled(true);
> EPackage pPackage = (EPackage) ecoreResource.getContents().get(0);
> org.eclipse.emf.ecore.EPackage.Registry.INSTANCE.put(pPackag e.getNsURI(),
> pPackage);
> // sthg missing???
> List<Constraint> cts = oclFacade.parse(oi);
>
>
> Somehow I should let the OCL facade know about the particular target
> .ecore, right? Help on this is appreciated.
>
>
> Miguel
|
|
| |
| Re: parsing OCL def: statements in an .ocl file [message #21649 is a reply to message #21604] |
Tue, 01 May 2007 21:21 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Miguel,
The problem is that OCL cannot modify the model that it is constraining.
So, although logically the newly defined operation is an operation of the
constrained class, it isn't actually in the constrained model. Besides
which, it is a practical problem for Ecore: frozen EPackages don't like to
be changed at run-time, and the "shadow class" mechanism is required to
implement operations on EDataTypes, anyway.
Moreover, by adding the EOperation to the constrained EClass, this operation
would become available to all other OCL environments that may be using the
same model. This was a problem in MDT OCL 1.0.
The additions package is just an arbitrary package to group the shadow
classes created for additional operations and attributes, to support
persistence of the environment. You can customize the environment and
define your own TypeResolver to handle these differently.
HTH,
Christian
Miguel Garcia wrote:
>
> Christian,
>
> I'm getting no error messages, I'm just reviewing in detail the resulting
> AST. I have a question about the values in Constraint#constrainedElements.
> Let's say an operation is defined as:
>
> context Employee
> def def14:
> relatives(c : Country) : Set(String) = Set{'bob', 'alice'}
>
> after parsing, the Constraint provides two constrained elements:
> 1) the EClass instance for Employee
> 2) the EOperation instance for the newly defined operation.
> The eContainer of this EOperation is not 1) above but "Employee_Class",
> whose eContainer in turn is the "additions" EPackage
>
> What are the advantages of that approach, instead of adding the new
> EOperation right away to the context element?
>
>
> Miguel
|
|
|
Goto Forum:
Current Time: Thu Apr 25 18:15:33 GMT 2024
Powered by FUDForum. Page generated in 0.03400 seconds |
] 
Search
Help
Register
Login
Home
