[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.modeling.mdt.uml2] Re: PackageMerge in UML metamodels

Maybe I can give it a try ...
We should also include Kenn's descriptions found in this 3-year-old thread: ;-)
http://dev.eclipse.org/newslists/news.eclipse.tools.uml2/msg03655.html


Marco

Kenn Hussey schrieb:
Any chance one of you would be interested in updating the Wiki with this information? ;)

Kenn

Timothy Marc wrote:
Dear Marco and James,

thanks a lot for that detailled answers. As you mentioned, Marco, i was very close to the truth with my suggestions, and with your augmented explanation, i think i understand the common relationsship between these models.

Thanks again.
Timothy

James Bruck schrieb:
... a few comments below...

"Marco Mosconi" <mosconi@xxxxxxxxxxxxxxx> wrote in message news:h1o6dl$2oq$1@xxxxxxxxxxxxxxxxxxxx
Hi Timothy,

I think you understood correctly so far, and in fact it's really not easy to follow the merge relationships throughout the UML metamodel :-)
More comments inline:


These depth of inheritance results of the execution of all merge relationships, which are defined in the model. Is this correct?
Yes.

1. For what purpose is the Ecore.uml, 10536.uml, 10537.uml, UML2_2_UML.ecore
- Ecore.uml is imported by UML.uml
- 10xxx.uml have been workarounds (at least I think so), they are no longer present in UML2 3.0 (or integrated in UML.uml)

10536.uml and 10537.uml are models that were merged into the main metamodel but were not part of the spec.
They were to correct RTF issues at the OMG (ie issue 10536).
See http://www.eclipse.org/modeling/mdt/uml2/docs/guides/UML2_2.1_Migration_Guide/guide.html for a deeper explanation.
The fundamental principal that we try to adhere to is to keep the core metamodel spec compliant. Any other changes that are not part of the spec are merged in.
Also note that in the latest version of UML2 (ie. 3.0.0) 10536.uml is removed since it became part of the spec.


- UML2_2_UML.ecore has something to do with migration between different versions of UML2.

I believe the extension is .ecore2ecore and it is used in migration.

2. What are the differences between Superstructure and UML.merged? It seems to me, that UML merged results by the execution of package merge relationsships defined in UML.uml. The UML.uml merges the packages of the compliance levels. And the compliance levels refers to either the Infrastructure.uml and the Superstructure.uml.
Yes, it's exactly that way ...

It seems to me, that the Superstructure.uml, was modeled without any merge definition, just for the construction of the compliance levels. Is this correct? If so, i would have expected, that the Superstructure.uml merges the constructs and primitive types packages of the infrastructure as it is shows in figure 7.1 of the current UML Spec 2.2. But the only import, i found in the Superstructure.uml addresses the primitive types of the Infrastructure.
There are lots of PackageMerge relationships between packages in the Superstructure.uml, but you are right in that the comliance levels are defined separately and themselves merge packages from the infra/superstructure.
Superstructure.uml *does* merge the Constructs and PrimitiveTypes from the Infrastructure, have a look inside UML::Classes::Kernel.


Summing up, the structure is as follows:
1) Infrastructure.uml and Superstructure.uml define the model elements of the UML and organize them in reusable Language Units (packages). Superstructure.uml reuses Core::PrimitiveTypes and Core::Constructs of Infrastructure.uml.
2) L0-L3.uml merge packages from Infra/Superstructure.uml to form the UML compliance levels.
3) UML.uml represents the complete (L3) UML language and is used to generate the metamodel for the UML2 implementation. It merges L3.uml and integrates additional features specific for the Eclipse UML2 plugin.
4) UML.merged.uml is the merged result of UML.uml.
5) UML.ecore is the EMF-exported variant of UML.merged.uml and the input for the EMF-generated UML2 implementation.


HTH,
Marco