| Use OCL to validate non-Ecore objects at runtime [message #1800610] |
Thu, 03 January 2019 15:39  |
 Thomas Pusztai
Messages: 27
Registered: September 2018 |
Junior Member |
|
|
Hi,
I have written a custom UML model to code generator using Acceleo. My UML model also contains some constraints (e.g. operation pre- and post-conditions) written in OCL. I would like to use these constraints to perform validation at runtime, e.g., when a method that has a precondition defined, is called, I want to evaluate that OCL constraint to make sure that the method parameters are within the expected bounds.
Since I had to write a custom code generator, the generated code is Java without any use of the Ecore library. I've read that the Pivot Eclipse OCL binding currently supports using Ecore or UML as a metamodel for validation. How can I create an adapter, so that I can perform validation directly on the Java objects using reflection?
The way I see it, I "only" have to create some resolver class that allows the Eclipse OCL library to map the variable names, properties, and operations to my Java objects and their properties. For example, for the OCL expression I would expect it to work this way: the OCL library parses the expression and then asks me what 'amount', 'self', and 'self.limit' refer to and I return the appropriate values.
Is this idea correct? What interface(s) to I need to implement in order to do that? Is it org.eclipse.ocl.Environment?
Best regards,
Thomas
|
|
|
| Re: Use OCL to validate non-Ecore objects at runtime [message #1800620 is a reply to message #1800610] |
Thu, 03 January 2019 18:12  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
I am far from clear what you are trying to do; I read lots of plausible words but no concrete example.
It appears that you produce Java code that reifies a UML Model. Pretty easy structurally, rather hard behaviourally unless you embed contrived Java snippets in your operations, in which case you can have differently contrived Java snippets for validation.
If you want to use OCL, why aren't you already using OCL to define operation bodies? constraints are just more of the same.
In order to derive Java from OCL, you need an OCL to Java generator. Many authors have observed a superficial similarity between OCL and Java and attempted a simple template mapping. This perhaps works for 'simple' OCL with modified Java-like semantics. AFAIAA only the Eclipse OCL Java Code Generator treats OCL2Java as a compilation activity and consequently works for 100% of the language using OCL semantics. The OCL2Java CG is extensible, for instance it is re-used to support direct Java execution of QVTr and QVTc. But it is not yet easy to extend.
Basic org.eclipse.ocl.* is the old Classic OCL prefix. The new Pivot-based, Xtext exploiting OCL, is org.eclipse.ocl.pivot.* for the model, org.eclipse.ocl.xtext.* for the parsing/editing, org.eclipse.ocl.examples.codegen.* for the CG and org.eclipse.ocl.examples.debug.* for the debugger.
If you used the standard UML2Ecore followed by the standard GenModel Ecore2Java you would have most of what you want for free. In particular the OCL embedded in UML would materialize in Java and be able to access the Ecore compliant model to resolve navigations and variables.
Regards
Ed Willink
|
|
|
| Re: Use OCL to validate non-Ecore objects at runtime [message #1800645 is a reply to message #1800620] |
Fri, 04 January 2019 10:36 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
If you really want OCL to operate in a new modeling paradigm, you have two design choices; adapt OCL for the new paradigm, or adapt the new paradigm for OCL.
(The Classic Eclipse OCL took the first approach resulting in large amounts of code with very long template parameter lists to accommodate the actual classes in the new paradigm that nonetheless had to closely correspond to OCL expectations.)
The Pivot Eclipse OCL takes the first approach for the run-time instances but the second approach for the compile-time / meta-models.
If you use UML/Ecore meta-models, no change to the compile-time / meta-modeling is required; the existing UML/Ecore to Pivot loader normalization will do. If you use a new meta-model representation, you need to write a new to Pivot meta-model loader.
If at run-time you use conventional Java types such as Boolean, BigDecimal, Set etc, you can easily re-use the Pivot Value classes so that all the Pivot Operation implementations work as-is. If not, you will need to provide similar code to the Ecore conversion for EInt / ELongObject / EList etc.
Your new paradigm will inevitably use different memory structures. Access to these are isolated in the Pivot OCL by a hierarchy of about 20 Property implementation classes such as ExplicitNavigationProperty, UnboxedOppositeNavigationProperty. In princiuple a new derivation of AbstractTechnology can define the appropriate access techniques for your new paradigm. In practice this functionality has only been re-used so far to support some UML extensions. For direct Java rather than interpreted execution, each of these property implementations needs a corresponding to-Java synthesizer.
Regards
Ed Willink
|
|
|
| Re: Use OCL to validate non-Ecore objects at runtime [message #1800655 is a reply to message #1800645] |
Fri, 04 January 2019 14:17 |
Thomas Pusztai
Messages: 27
Registered: September 2018 |
Junior Member |
|
|
Hi Ed,
Thank you for your responses.
The reason why I didn't use Ecore code generation, but went with a custom code generator instead, is that this is a research project focusing on the design of fog computing applications. For example, each interface in the UML model is treated as a REST endpoint, for which a server side part and a client part needs to be generated.
As a result of the code generation I get, among other things, a set of model classes and Maven projects, which compile to REST server applications that provide the designed interfaces. The actual business logic behind the REST interfaces needs to be implemented manually.
However, I do want to provide the possibility to define some simple pre- and post-conditions for the REST methods, which are used to ensure that the current state remains within some predefined bounds. This is what I wanted to use OCL validation for. But it seems like making that work for generated code that is not based on Ecore is a little too complex for my research example. Since I only have simple OCL expressions, I will just try to map them to Java getter and setter calls using a simple template approach.
Best regards,
Thomas
|
|
|
|
Powered by
FUDForum. Page generated in 0.03813 seconds
] 
Search
Help
Register
Login
Home
