[news.eclipse.modeling.mdt.uml2] Re: PackageMerge in UML metamodels

["James Bruck" <jbruck@xxxxxxxxxx>]

... 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