Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Use OCL to validate non-Ecore objects at runtime
Use OCL to validate non-Ecore objects at runtime [message #1800610] Thu, 03 January 2019 15:39 Go to next message
Thomas Pusztai is currently offline Thomas PusztaiFriend
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
amount <= self.limit
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6440
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6440
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 Go to previous messageGo to next message
Thomas Pusztai is currently offline Thomas PusztaiFriend
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
Re: Use OCL to validate non-Ecore objects at runtime [message #1800657 is a reply to message #1800655] Fri, 04 January 2019 15:33 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6440
Registered: July 2009
Senior Member
Hi

For a research project, I would strongly discourage use of 'simple templates'. They are sure to fail as your usage grows. I recommend using a stylized Java snippet that you just paste into the code, possibly using e.g. $1 to substitute the spelling of the first parameter. You then have the fall back of invoking MyComplicatedValidation.validationProblemXXXX($1, $2) when XXX is too hard.

Regards

Ed Willink
Previous Topic:Custom implementation of OCLstdlib
Next Topic:import nested packages in CompleteOCL for use with XText
Goto Forum:
  


Current Time: Sat Aug 24 03:32:46 GMT 2019

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

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

Back to the top