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
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240 231 / +34 617 718 268 |
|