Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » UMLPackage.eINSTANCE.eClass() is ecore.EPackage?
UMLPackage.eINSTANCE.eClass() is ecore.EPackage? [message #1171686] Tue, 05 November 2013 07:06 Go to next message
Eclipse User
Hi!

I am confused about the UMLPackage implementation because the UMLPackage
instance returns ecore.EPackage as EClass, not uml.Package.

I would have expected that the UMLPackage implementation is a UML
package, not an Ecore package. Easily testable with the following code:


@Test
public void checkUmlPackageEClass() {
final EClass umlPackageClass = UMLPackage.eINSTANCE.eClass();
assertEquals(UMLPackage.Literals.PACKAGE, umlPackageClass);
}


We want to use Sphinx to load UML models, and when checking the model
type for the UMLPackage, it determines Ecore instead of UML because of
the eClass() result.

Can the UMLPackage's EClass be changed to uml.Package?


Cheers
Patrick
Re: UMLPackage.eINSTANCE.eClass() is ecore.EPackage? [message #1171797 is a reply to message #1171686] Tue, 05 November 2013 08:42 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 3840
Registered: July 2009
Senior Member
Hi

You might think so but MDT/UML2 is a UML realisation for Ecore, not an
OMG UML realisation.

This is one of the rationale's for the new pivot-based OCL. It has an
infinite reflective tower so the meta-type of an OCL::Class is
OCL::Class, nor ecore::EClass or UML::Package.

More accurately OclAny::oclType() returns Metaclass(OclSelf) which
conforms to Class.

If using UML you navigate to/from OCL::XXX from UML::XXX.

Regards

Ed Willink


On 05/11/2013 12:06, Patrick Könemann wrote:
> Hi!
>
> I am confused about the UMLPackage implementation because the UMLPackage
> instance returns ecore.EPackage as EClass, not uml.Package.
>
> I would have expected that the UMLPackage implementation is a UML
> package, not an Ecore package. Easily testable with the following code:
>
>
> @Test
> public void checkUmlPackageEClass() {
> final EClass umlPackageClass = UMLPackage.eINSTANCE.eClass();
> assertEquals(UMLPackage.Literals.PACKAGE, umlPackageClass);
> }
>
>
> We want to use Sphinx to load UML models, and when checking the model
> type for the UMLPackage, it determines Ecore instead of UML because of
> the eClass() result.
>
> Can the UMLPackage's EClass be changed to uml.Package?
>
>
> Cheers
> Patrick
Re: UMLPackage.eINSTANCE.eClass() is ecore.EPackage? [message #1171949 is a reply to message #1171686] Tue, 05 November 2013 10:45 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 701
Registered: July 2009
Senior Member
Hi, Patrick,

Yes, every EMF package is an Ecore EPackage. The UML metamodel is not
an extension of the Ecore metamodel: it is transformed to Ecore in
order to provide a Java implementation.

Does Sphinx need to treat models that are generated from UML (by the
UML2 SDK, using UML2's extended GenModel) differently from those
generated from Ecore (by the EMF SDK)? You might be able to make this
distinction by looking up the EPackage's genmodel and seeing whether
its "foreign model" is an Ecore or a UML model. You may also see
gen-annotations in the genmodel that indicate a UML source.

HTH,

Christian

On 2013-11-05 12:06:01 +0000, Patrick Könemann said:

> Hi!
>
> I am confused about the UMLPackage implementation because the UMLPackage
> instance returns ecore.EPackage as EClass, not uml.Package.
>
> I would have expected that the UMLPackage implementation is a UML
> package, not an Ecore package. Easily testable with the following code:
>
>
> @Test
> public void checkUmlPackageEClass() {
> final EClass umlPackageClass = UMLPackage.eINSTANCE.eClass();
> assertEquals(UMLPackage.Literals.PACKAGE, umlPackageClass);
> }
>
>
> We want to use Sphinx to load UML models, and when checking the model
> type for the UMLPackage, it determines Ecore instead of UML because of
> the eClass() result.
>
> Can the UMLPackage's EClass be changed to uml.Package?
>
>
> Cheers
> Patrick
Re: UMLPackage.eINSTANCE.eClass() is ecore.EPackage? [message #1172086 is a reply to message #1171949] Tue, 05 November 2013 12:41 Go to previous messageGo to next message
Eclipse User
Hi Christian,

thanks for the quick response!

During proxy resolution, Sphinx identifies the meta model type at some
point via a model element's eClass(). For the UMLPackage instance, this
results in the Ecore meta model, not the UML meta model. Consequently, a
different MetaModelDescriptor is determined.

I would expect every resource in the resource set of a UML model to be
an instance of the UML meta model, i.e. profiles, type libraries, and
the UML meta model itself. Otherwise we would have multiple
MetaModelDescriptors for a resource set that contains only UML models,
which seems weird in my eyes ;-)


Patrick


Am 05.11.2013 16:45, schrieb Christian W. Damus:
> Hi, Patrick,
>
> Yes, every EMF package is an Ecore EPackage. The UML metamodel is not
> an extension of the Ecore metamodel: it is transformed to Ecore in
> order to provide a Java implementation.
>
> Does Sphinx need to treat models that are generated from UML (by the
> UML2 SDK, using UML2's extended GenModel) differently from those
> generated from Ecore (by the EMF SDK)? You might be able to make this
> distinction by looking up the EPackage's genmodel and seeing whether its
> "foreign model" is an Ecore or a UML model. You may also see
> gen-annotations in the genmodel that indicate a UML source.
>
> HTH,
>
> Christian
>
> On 2013-11-05 12:06:01 +0000, Patrick Könemann said:
>
>> Hi!
>>
>> I am confused about the UMLPackage implementation because the UMLPackage
>> instance returns ecore.EPackage as EClass, not uml.Package.
>>
>> I would have expected that the UMLPackage implementation is a UML
>> package, not an Ecore package. Easily testable with the following code:
>>
>>
>> @Test
>> public void checkUmlPackageEClass() {
>> final EClass umlPackageClass = UMLPackage.eINSTANCE.eClass();
>> assertEquals(UMLPackage.Literals.PACKAGE, umlPackageClass);
>> }
>>
>>
>> We want to use Sphinx to load UML models, and when checking the model
>> type for the UMLPackage, it determines Ecore instead of UML because of
>> the eClass() result.
>>
>> Can the UMLPackage's EClass be changed to uml.Package?
>>
>>
>> Cheers
>> Patrick
>
>
Re: UMLPackage.eINSTANCE.eClass() is ecore.EPackage? [message #1172211 is a reply to message #1172086] Tue, 05 November 2013 14:39 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 701
Registered: July 2009
Senior Member
Hi, Patrick,

I'm starting to get dizzy with these "meta"s spinning around. :-)

You will never find the UMLPackage in a resource ... it lives in the
EPackage.Registry. And the only EClass that Sphinx will ever see when
asking packages for their eClass() is Ecore::EPackage, because all
packages are EPackages in EMF. It is simply required by the framework.

Probably most resources in a resource set containing UML models will
have UML Packages or other Elements of some kind, but they could also
have stereotype applications described by profiles, and these profiles
are manifest as EPackages that are all distinct from UML (though
generated by the UML2 tooling). Profiles are instances of the UML
metamodel, but the instances of their Stereotypes are not UML elements
and have no relation to UML except at the meta-level.

Perhaps the determination of a MetaModelDescriptor should look not at
the EPackage's eClass() but its namespace URI to identify it (although,
for UML, this doesn't work well because it changes in most annual
releases). Although, I'm still unsure of the purpose of the
MetaModelDescriptor. Is it meant to identify the particular EPackage
(ecore, uml, library, ocl, diffmodel, etc.) or the metamodel from which
it was generated (Ecore, UML)?

I don't know that I'm helping any ...

cW

On 2013-11-05 17:41:21 +0000, Patrick Könemann said:

> Hi Christian,
>
> thanks for the quick response!
>
> During proxy resolution, Sphinx identifies the meta model type at some
> point via a model element's eClass(). For the UMLPackage instance, this
> results in the Ecore meta model, not the UML meta model. Consequently, a
> different MetaModelDescriptor is determined.
>
> I would expect every resource in the resource set of a UML model to be
> an instance of the UML meta model, i.e. profiles, type libraries, and
> the UML meta model itself. Otherwise we would have multiple
> MetaModelDescriptors for a resource set that contains only UML models,
> which seems weird in my eyes ;-)
>
>
> Patrick
>
>
> Am 05.11.2013 16:45, schrieb Christian W. Damus:
>> Hi, Patrick,
>>
>> Yes, every EMF package is an Ecore EPackage. The UML metamodel is not
>> an extension of the Ecore metamodel: it is transformed to Ecore in
>> order to provide a Java implementation.
>>
>> Does Sphinx need to treat models that are generated from UML (by the
>> UML2 SDK, using UML2's extended GenModel) differently from those
>> generated from Ecore (by the EMF SDK)? You might be able to make this
>> distinction by looking up the EPackage's genmodel and seeing whether its
>> "foreign model" is an Ecore or a UML model. You may also see
>> gen-annotations in the genmodel that indicate a UML source.
>>
>> HTH,
>>
>> Christian
>>
>> On 2013-11-05 12:06:01 +0000, Patrick Könemann said:
>>
>>> Hi!
>>>
>>> I am confused about the UMLPackage implementation because the UMLPackage
>>> instance returns ecore.EPackage as EClass, not uml.Package.
>>>
>>> I would have expected that the UMLPackage implementation is a UML
>>> package, not an Ecore package. Easily testable with the following code:
>>>
>>>
>>> @Test
>>> public void checkUmlPackageEClass() {
>>> final EClass umlPackageClass = UMLPackage.eINSTANCE.eClass();
>>> assertEquals(UMLPackage.Literals.PACKAGE, umlPackageClass);
>>> }
>>>
>>>
>>> We want to use Sphinx to load UML models, and when checking the model
>>> type for the UMLPackage, it determines Ecore instead of UML because of
>>> the eClass() result.
>>>
>>> Can the UMLPackage's EClass be changed to uml.Package?
>>>
>>>
>>> Cheers
>>> Patrick
Re: UMLPackage.eINSTANCE.eClass() is ecore.EPackage? [message #1173594 is a reply to message #1172211] Wed, 06 November 2013 11:26 Go to previous message
Eclipse User
Hi Christian,

I agree, thanks for your clarifications!

In the meantime, Sphinx is changed to decide via a resource scope
whether or not an element and its resource belongs to a model's scope
(for proxy resolution, amongst others) or not. So it is up to the
implementation to decide that, e.g. by URI or file extension.

So the EClass is not evaluated anymore :-)


Patrick


Am 05.11.2013 20:39, schrieb Christian W. Damus:
> Hi, Patrick,
>
> I'm starting to get dizzy with these "meta"s spinning around. :-)
>
> You will never find the UMLPackage in a resource ... it lives in the
> EPackage.Registry. And the only EClass that Sphinx will ever see when
> asking packages for their eClass() is Ecore::EPackage, because all
> packages are EPackages in EMF. It is simply required by the framework.
>
> Probably most resources in a resource set containing UML models will
> have UML Packages or other Elements of some kind, but they could also
> have stereotype applications described by profiles, and these profiles
> are manifest as EPackages that are all distinct from UML (though
> generated by the UML2 tooling). Profiles are instances of the UML
> metamodel, but the instances of their Stereotypes are not UML elements
> and have no relation to UML except at the meta-level.
>
> Perhaps the determination of a MetaModelDescriptor should look not at
> the EPackage's eClass() but its namespace URI to identify it (although,
> for UML, this doesn't work well because it changes in most annual
> releases). Although, I'm still unsure of the purpose of the
> MetaModelDescriptor. Is it meant to identify the particular EPackage
> (ecore, uml, library, ocl, diffmodel, etc.) or the metamodel from which
> it was generated (Ecore, UML)?
>
> I don't know that I'm helping any ...
>
> cW
>
> On 2013-11-05 17:41:21 +0000, Patrick Könemann said:
>
>> Hi Christian,
>>
>> thanks for the quick response!
>>
>> During proxy resolution, Sphinx identifies the meta model type at some
>> point via a model element's eClass(). For the UMLPackage instance, this
>> results in the Ecore meta model, not the UML meta model. Consequently, a
>> different MetaModelDescriptor is determined.
>>
>> I would expect every resource in the resource set of a UML model to be
>> an instance of the UML meta model, i.e. profiles, type libraries, and
>> the UML meta model itself. Otherwise we would have multiple
>> MetaModelDescriptors for a resource set that contains only UML models,
>> which seems weird in my eyes ;-)
>>
>>
>> Patrick
>>
>>
>> Am 05.11.2013 16:45, schrieb Christian W. Damus:
>>> Hi, Patrick,
>>>
>>> Yes, every EMF package is an Ecore EPackage. The UML metamodel is not
>>> an extension of the Ecore metamodel: it is transformed to Ecore in
>>> order to provide a Java implementation.
>>>
>>> Does Sphinx need to treat models that are generated from UML (by the
>>> UML2 SDK, using UML2's extended GenModel) differently from those
>>> generated from Ecore (by the EMF SDK)? You might be able to make this
>>> distinction by looking up the EPackage's genmodel and seeing whether its
>>> "foreign model" is an Ecore or a UML model. You may also see
>>> gen-annotations in the genmodel that indicate a UML source.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>> On 2013-11-05 12:06:01 +0000, Patrick Könemann said:
>>>
>>>> Hi!
>>>>
>>>> I am confused about the UMLPackage implementation because the
>>>> UMLPackage
>>>> instance returns ecore.EPackage as EClass, not uml.Package.
>>>>
>>>> I would have expected that the UMLPackage implementation is a UML
>>>> package, not an Ecore package. Easily testable with the following code:
>>>>
>>>>
>>>> @Test
>>>> public void checkUmlPackageEClass() {
>>>> final EClass umlPackageClass = UMLPackage.eINSTANCE.eClass();
>>>> assertEquals(UMLPackage.Literals.PACKAGE, umlPackageClass);
>>>> }
>>>>
>>>>
>>>> We want to use Sphinx to load UML models, and when checking the model
>>>> type for the UMLPackage, it determines Ecore instead of UML because of
>>>> the eClass() result.
>>>>
>>>> Can the UMLPackage's EClass be changed to uml.Package?
>>>>
>>>>
>>>> Cheers
>>>> Patrick
>
>
Previous Topic:connectors
Next Topic:Class and Package diagrams for eclipse api
Goto Forum:
  


Current Time: Wed Apr 16 18:58:56 EDT 2014

Powered by FUDForum. Page generated in 0.02209 seconds