| [mdt-ocl.dev] About Complete and Essential OCL. |
|
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. --
|
