See some comments in-line, below.
On 20-Jan-09, at 5:59 AM, Adolfo Sánchez-Barbudo Herrera wrote:
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.
It's unfortunate that the layering of complexity in the MOF/UML world is so very different from the way abstraction is typically implemented in OOPLs. The ad hoc adaptation of the OCL semantics is not ideal.
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:
BasicOcl and EssentialOcl are identical, as the specification points. Is there any value in distinguishing these two? I don't see it.
I agree that it would be nice not to see metaclasses that are irrelevant to EssentialOcl, but that raises an interesting question for the specification. There is nothing in a message _expression_ that makes it inherently inapplicable in an EMOF/Basic context except that it uses a couple of Actions from UML. Why did it need to do that? EMOF has Operations; it would have been sufficient to reference an Operation instead of a CallOperationAction to model operation messages. Signal messages could be dropped by the EssentialOcl "adaptation." For that matter, why does UML define a distinct metaclass for signals when DataType would do nicely? (note that I am not advocating any changes in UML, here)
EssentialOCL
+expressions
+types
CompleteOCL
+expressions
+types
It would be nice to see the OCL specification structured in this way. As I understand it, 2.0 is not structured thus but comprises only a single OCL package with Expressions and Types sub-packages (though even the parent package is nowhere mentioned in the document). Unfortunately, the OCL specification did not publish its XMI models, if indeed there are any.
It seems clear from Chapter 13 that the EssentialOcl is constructed by a mapping algorithm. Does it actually exist as a metamodel?
Would you implement CompleteOcl as an extension of EssentialOcl, or would it replicate the common structure? There are arguments for both approaches, some driven by pragmatics of Java coding and others by the design of the specification.
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.
That distinction doesn't exist. I'm not sure that it is interesting to implement a BasicOcl.
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.
If you don't use them, you won't load these classes anyway. The only difference is some extra weight in the JARs.
- 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.
This is an on-going problem at the OMG: the OCL specification does not have a good track record of keeping up with the specifications that it depends on.
I tend to agree with Ed that it isn't necessary to separate the EssentialOcl and CompleteOcl parsers into distinct plug-ins. Especially considering that they would need to share common analyzer and interpreter classes. However, in bifurcating the metamodel, it is probably natural to let EMF/UML2 generate the two metamodels into separate plug-ins anyway. It's easier to maintain models when only one is generated into a plug-in.
The bigger question is whether these metamodels are independent or CompleteOcl extends EssentialOcl. According to the specification, they can only be independent because of the way the package merges work out. It seems wasteful from an implementation perspective, but I don't think that it could be avoided because the generalization relationships are incompatible.
Comments ?
Cheers,
Adolfo.
--
<logo.jpg>
| 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 |
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
--
Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV
