[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-ocl.dev] OCL tools contributions
|
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
----------------------------------------------------------------
Ce message electronique et tous les fichiers joints qu'il contient
(ci-apres "le message") sont confidentiels et destines exclusivement
a l'usage des destinataires indiques ou des personnes dument
habilitees a les recevoir a leur place.
Si vous recevez ce message par erreur, merci de bien vouloir le
detruire et d'en avertir l'emetteur.
Toute utilisation de ce message non conforme a sa destination, toute
diffusion ou toute publication totale ou partielle est interdite sauf
autorisation expresse de l'emetteur.
Les idees et opinions exprimees dans ce message sont celles de son
auteur et ne representent pas necessairement celles de CS
Communication & Systemes ou de ses filiales.
Malgre toutes les dispositions prises par CS Communication & Systemes
et ses filiales pour minimiser les risques de virus, les fichiers
joints a ce message peuvent contenir des virus qui pourraient
endommager votre systeme informatique. Il vous appartient d'effectuer
vos propres controles anti-virus avant d'ouvrir les fichiers joints.
CS Communication & Systemes et ses filiales declinent toute
responsabilite pour toute perte ou dommage resultant de l'utilisation
de ce message et/ou des fichiers joints.
This e-mail and any file attached hereto (hereinafter 'the e-mail')
are confidential and intended solely for the use of the adressees
indicated below or the persons duly entitled to receive them in their
place.
If you receive this e-mail in error, please delete it and notify the
sender.
Any use of this e-mail not in accordance with its purpose, any
dissemination or disclosure, either whole or partial, is prohibited,
unless formally approved by the sender.
The ideas or opinions expressed in this e-mail are solely those of
its author and do not necessarily represent those of CS Communication
& Systeme or its affiliates.
Despite all the measures taken by CS Communication & Systeme and its
affiliates in order to minimize the risks of virus, the files
attached to this e-mail may contain virus which could damage your
information system. You are responsible for processing your own
anti-virus checking before opening any file attached hereto. Neither
CS Communication & Systemes, nor its affiliates, shall be held liable
for any loss or damage due to the use of this e-mail or any file
attached hereto.
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev