[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-ocl.dev] About Complete and Essential OCL.
|
Hi Adolfo
It could certainly make sense to partition EssentialOCL.g into
BasicOCL.g, EssentialOCL.g and CompleteOCL.g and replace
AbstractOCLAnalyser by AbstractBasicOCLAnalyser,
AbstractEssentialOCLAnalyser and AbstractCompleteOCLAnalyser.
(probably split lexer and keyword grammars too).
These would all fit within the existing plug-in structure.
An extending application such as QVTx will provide its own
QVTxParser.g, that imports perhaps EssentialOCL.g. QVTxParser.g
becomes QVTxParser with a QVTxAnalyser that extends
AbstractEssentialOCLAnalyser. This would exclude the State
and Message bloat and consequent language inaccuracy. Note
that QVTxParser already comprises a full set of rules, it does not
inherit shared actions from OCLxxxxParser.
However, I don't think there is any need for plug-in structure change
since I really don't care if QVTx has a few redundant OCL classes
visible just so long as they are not used. There are a lot more Eclipse
and Java classes that are also not used.
OCL itself would continue to provide a Complete OCLParser.
[Really interesting and probably impossible would be a way to
provide the Ecore/UML flexibility without imposing the occasional
need to downcast the abstract method returns from generic classes.]
Regards
Ed Willink
Hi Christian,
I have been thinking about the fact that OCL has been designed to work
with both UML and EMOF metamodels. I have read the section 13: The Basic
OCL and Essential OCL.
Undoubtedly, the effort of exploiting generics in Europa release, was a
big step to support both "worlds". However, I think that more efforts
could be done for MDT OCL v 2.0.
I believe that we could introduce the concept of BasicOCL, EssentialOCL
and CompleteOCL. The main advantage of this is that Ecore-based OCL
metamodel would not have to know about meta-classes like MessageType,
MessageExp, etc. So we could have the following package structure:
EssentialOCL
+expressions
+types
CompleteOCL
+expressions
+types
While the UML-based OCL metamodel would use classes from both metamodels
(Essential and CompleteOCL), the Ecore-based OCL metamodel would just
use the EssentialOCL metamodel.
Ideally the same idea could be done between BasicOCL and EssentialOCL.
The main problem is that there isn't any metaclass which must belong to
EssentialOCL AND not to BasicOCL, so it could be little bit weird trying
to implement this distinction.
I also have to say that this distinction between essential and complete
OCL should be done at plug-in level (different metamodels, grammars,
parsers, analyzers, cst metamodels, etc). This seems to be extra work,
but breaking down the generic metamodel in several parts could provide
some benefits.
- If I want to use an Ecore-based OCL implementation, I would avoid
loading extra plugins, classes, etc which I don't really need.
- when adopting specification changes. Not only in the own OCL
specification, but in UML or MOF specifications. A specification change
may affect the CompleteOCL implementation, but the EssentialOCL one may
remain intact.
Comments ?
Cheers,
Adolfo.
--
*Adolfo Sánchez-Barbudo Herrera*
adolfosbh(at)opencanarias(dot)com
<mailto:adolfosbh%28at%29opencanarias%28dot%29com>
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240 231 / +34 617 718 268
------------------------------------------------------------------------
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev