[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-ocl.dev] OCL tools contributions
|
Hi Sébastien
I think I can speak for all the MDT/OCL committers when I say we have
limited resources for progressing
existing Bugzilla commitments, so we can only offer a limited amount of
help in integrating your
contribution.
We would appreciate it if you can arrange a contribution that aligns
well with CVS HEAD and follows
the MDT/OCL coding practices at http://wiki.eclipse.org/MDT/OCL/Dev/Setup.
That said, it could be helpful to raise a Bugzilla and attach your code
as soon as it works with CVS HEAD
and other modeling package project current versions. We can then at
least get a feel for the plugin/package
organisation and perhaps make some recommendations about compatible
organisation.
I can offer assistance in upgrading the MDT/OCL parser and editor to
accommodate an enhanced syntax.
I trust that you will be able to offer the contribution under EPL and
are able to identify all the authors
of all the code.
Regards
Ed Willink
Sébastien GABEL wrote:
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev