Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] OCL tools contributions 
Hi,

First, I agree with most of your remarks.
Concerning the OCL reporting feature, I confirm that the system is not plugged to the Eclipse version of Acceleo since several TOPCASED components require the old version of Acceleo. I am confident to an eventual switch for the next weeks to come. 

Concerning Ed's remarks :

   *  Change "--@error message" into "inv name(type, message) : it is
     an excellent idea and this kind of syntax would be certainly much
     more adapted compared to the current one.

   * Remove token MetaModel : this point is one of our concerns....I
     should have a look to the QVT Declarative Model Registry
     implementation.
Would you be interested by a first contribution around the OCL evaluator ? As I said in my previous mail, I may spend some time to adapt and contribute this component. 

Regards,

Sébastien Gabel




Laurent Goubet a écrit :

Sebastien,
As far as I see it, that would be great :). Yet some of the things I see here and there in this thread kind of trouble me :
You mentionned you can generate verification reports for OCL expressions base on Acceleo templates; and I believe you're talking here about the "old" Acceleo ( http://www.acceleo.org/pages/home/en ). Ed's previous message tends to confirm it : "--@error <% self.firstName %> <% self.lastName %> is not married " really closely resemble the old Acceleo syntax.
I think it would be better to improve your implementation so that it works with the new Acceleo (which is itself based on OCL) : http://www.eclipse.org/modeling/m2t/?project=acceleo . Its 1.0 release is scheduled to take place within the Helios train in June 2010. 

Laurent Goubet
Obeo

Ed Willink a écrit :

Hi Sébastien
Sorry, missed your link; very interesting. It definitely looks like you are saving us from 
reworking the existing OCL interpreter.

A couple of concerns;
It seems very odd to embed a completely different syntactical style within OCL 

Surely

--@error <% self.firstName %>  <% self.lastName %> is not married

should be an OCL String-valued expression

--@error self.firstName + ' ' + self.lastName + ' is not married'

[OCL 2.1 adds String::+]
The ability to define the constraint violation message seems so fundamental that 
we should make it an OMG issue. I think something like
inv name(error, self.firstName + ' ' + self.lastName + ' is not married'): 
   invariant-expression
might be sensible, with a permission for any unambiguously named let variable visible at the point that the constraint violation is detected to be used within the string-error-expression. 
----

On Slide 10

"Here, only files containing http://family.ecore URI are allowed"
Surely anything is allowed, you just might generate a warning that the OCL is redundant.
This is probably necessary for multipackage meta-models, where there might be one re-usable OCL Document that just adds defs to OclAny etc. This re-usable document may have 
no obvious use of http://family.ecore

----

You add a non-OCL MetaModel prefix statement to your OCL document.
The QVT Declarative Model Registry that is also migrating to MDT/OCL allows package 
bindings to be specified without affecting the OCL.

----
You might want to check out what Martin Gogolla's guys are doing. They have a nice ability to detect inconsistent OCL constraints and generate a model that demonstrates the inconsistency. It would be great to have this capability more generally. 

   Regards

      Ed Willink

Sébastien GABEL wrote:

Dear MDT OCL team,
as discussed during the modeling symposium of Eclipsecon 2009, we plan to contribute some OCL components developed in TOPCASED to MDT OCL. The targeted components are: 1) The OCL evaluator, allowing to evaluate a rule step by step on a test model. 2) The OCL checker, that makes the OCL engine available to final users for model verification. It includes a rule chooser, organizes the results in a GUI, serializes the results in a XMI file, and generates custom verification reports (based on acceleo templates). It also contributes messages to the problems view and gives the possibility to navigate to the corresponding model element. 3) Optionally, our OCL editor may be contributed, but as it needs a complete redesign, it may be better to start a new one from scratch later? ;-)
To begin somewhere, and if of course you are interested in this component, I may work on the integration of the OCL evaluator in MDT OCL from now to the end of 2009. 

What is you opinion about this proposal ?

Sebastien Gabel
Communication and Systems
PS: You can find more information including screenshots about those components at http://gforge.enseeiht.fr/docman/view.php/30/3474/TPC_OCL_Tutorial_v1.0.pdf

Back to the top