Community
Participate
Working Groups
In UML2 3.0.0, UML.merged.uml and UML.metamodel.uml were substantially the same; i.e. Element has many keyword operations. In UML2 4.0.0M2 UML.metamodel.uml is substantially smaller; Element has no keyword operations. This causes a problem for MDT/OCL JUnit tests that use discontinued UML.metamodel.uml facilties. It would help if the metamodel for UML models was also present as a pathmap://UML_METAMODELS/ entry. Perhaps as UML_MODEL_METAMODEL_URI.
(In reply to comment #0) > It would help if the metamodel for UML models was also present as a > pathmap://UML_METAMODELS/ entry. Perhaps as UML_MODEL_METAMODEL_URI. Especially important given that UML.merged.uml is not part of the binary contents of the main UML plugin.
The purpose of the reference metamodel is for creation of stereotype extensions; the UML2-specific extensions (i.e., the various convenience methods that UML2 adds to the API) are not relevant in this context. Why are these operations needed by OCL?
(In reply to comment #2) > Why are these operations needed by OCL? I'm not entirely sure; I'm just mending regressions. In some cases, it appeared that e.g. Element::getKeywords() was just a convenient function for a signature test, but there are a couple of tests specifically focussed on OCL access to stereotyped elements in the presence of aliases, and others that verify the integrity of getMetaClass(). Whether the OCL tests are necessary or not, it seems that provision of the merged UML model from which the Java classes are generated is useful.
Hmm. The merged UML model is a source model, used at development time when producing the implementation. I'm not convinced that it's of much/any use to clients...
I don't fully understand the traditional MDT/OCL support for Associations and the new pivot support is still in progress, but I'm pretty sure that for any application that wants to reason about Associations it is helpful to have a modeled representation of them. In the absence of UML.merged.uml, an application must either go back to the unmerged sources, if they are available, and re-merge or reverse engineer the idiomatic exposition in the generated Ecore, which probably lacks the EAnnotations to capture the lost information such as unnavigable opposites. It seems a shame for the UML2 support project to hide the second most important meta-model. [Some of the specific MDT/OCL JUnit problems can be resolved by rewriting tests to exercise operations that are present in some other model.]
The MDT/OCL tests have taken a copy as a test vehicle, so there is no requirement now from MDT/OCL; just a general user friendliness in providing the overall UML as a file rather than requiring independent generation.
Given there's no longer a burning need, and taking my previous comments into consideration, I'm inclined to not fix this issue because I don't want this model to be treated like "API".
See bug 381237.
So, the UML2 customizations will be restored to the reference metamodel after all, in response to bug 381237. *** This bug has been marked as a duplicate of bug 381237 ***
