Eclipse Community Forums: UML2 » Profile2EPackageConverter

Home » Modeling » UML2 » Profile2EPackageConverter

Profile2EPackageConverter [message #476409]

Mon, 22 October 2007 12:13

Eclipse User

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

I assume the Profile2EPackageConverter does the stuff when you define a
profile.

I'm wondering why in this case a Stereotype in uml isn't mapped to an
EClass which extends oe.uml2.uml.Stereotype. For UML2EcoreConverter this
behaviour might be good, because it reduces complexity and breaks
dependency to uml2.uml. But in the context of uml I think it's better if
it's really a subtype of stereotype. What's the reason it's not?

- -stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFHHMw+IYVWjMSpDwwRAiypAKCKfT8NnDkwLH6/p6QxoDfLjXpS0ACT BYOA
QV5/7dOZq73UG8WuFEs52A==
=ovRx
-----END PGP SIGNATURE-----

Re: Profile2EPackageConverter [message #476411 is a reply to message #476409]

Mon, 22 October 2007 17:39

Eclipse User

Hi ,

Yes Profile2EPackageConverter is the code that does the conversion.

org.eclipse.uml2.uml.Stereotype is mapped to EClass.

When you say ... "an EClass which extends oe.uml2.uml.Stereotype", I think
you might have a bit of a misconception about the inheritance. In the
Ecore metamodel there is no such thing as a uml stereotype so the EClass
that gets created cannot extend something from the uml metamodel. There is
a mapping from a uml concept (Stereotype) to an ecore concept (EClass).

Cheers,

- James

"SKuhn" <kuhn@oio.de> wrote in message
news:ffiia2$n5e$1@build.eclipse.org...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi,
>
> I assume the Profile2EPackageConverter does the stuff when you define a
> profile.
>
> I'm wondering why in this case a Stereotype in uml isn't mapped to an
> EClass which extends oe.uml2.uml.Stereotype. For UML2EcoreConverter this
> behaviour might be good, because it reduces complexity and breaks
> dependency to uml2.uml. But in the context of uml I think it's better if
> it's really a subtype of stereotype. What's the reason it's not?
>
> - -stefan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD4DBQFHHMw+IYVWjMSpDwwRAiypAKCKfT8NnDkwLH6/p6QxoDfLjXpS0ACT BYOA
> QV5/7dOZq73UG8WuFEs52A==
> =ovRx
> -----END PGP SIGNATURE-----

Re: Profile2EPackageConverter [message #476412 is a reply to message #476411]

Mon, 22 October 2007 18:02

Eclipse User

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

I thought a UML-model would be at M1, the UML-Metamodel at M2. Profiles
incl. Stereotypes are 'something' in between, because they're actually
'modelled' at M1, but somehow belong to M2, because they're extending
the UML-language. This is why the hole dynamic EMF and annotate the
profile with it's ecore represenation is needed.

So when the profile is converted to an ecore-instance -from M1 to M2-
it's on the same level as the UML2 Metamodel/superstructure is.

What I don't understand - or misunderstand- is: the profile-elements
should still be able to inherit from other meta-elements, like
uml:Package, uml:Class, Classifier and Stereotype. So when I now code
some stuff, having a Profile P with a stereotype S, and I use the their
emf-objects, my P is not an instance of Profile and S is not an
instanceof Stereotype.

UMLUtils solved this problem in my case, but now I would like to know it :D

- -stefan

James Bruck schrieb:
> Hi ,
>
> Yes Profile2EPackageConverter is the code that does the conversion.
>
> org.eclipse.uml2.uml.Stereotype is mapped to EClass.
>
> When you say ... "an EClass which extends oe.uml2.uml.Stereotype", I think
> you might have a bit of a misconception about the inheritance. In the
> Ecore metamodel there is no such thing as a uml stereotype so the EClass
> that gets created cannot extend something from the uml metamodel. There is
> a mapping from a uml concept (Stereotype) to an ecore concept (EClass).
>
> Cheers,
>
> - James
>
>
>
> "SKuhn" <kuhn@oio.de> wrote in message
> news:ffiia2$n5e$1@build.eclipse.org...
> hi,
>
> I assume the Profile2EPackageConverter does the stuff when you define a
> profile.
>
> I'm wondering why in this case a Stereotype in uml isn't mapped to an
> EClass which extends oe.uml2.uml.Stereotype. For UML2EcoreConverter this
> behaviour might be good, because it reduces complexity and breaks
> dependency to uml2.uml. But in the context of uml I think it's better if
> it's really a subtype of stereotype. What's the reason it's not?
>
> -stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFHHR3qIYVWjMSpDwwRAhj8AJjN+ebfiTLlMytBT51ti5QNh1QAAJ4k fqQw
0hnTeusFtHzBsTTXbF2KrA==
=7ujP
-----END PGP SIGNATURE-----

Re: Profile2EPackageConverter [message #476417 is a reply to message #476412]

Tue, 23 October 2007 16:25

Eclipse User

Hi Stefen,

some comments below ...

- James.

"SKuhn" <kuhn@oio.de> wrote in message
news:ffj6nd$sf8$1@build.eclipse.org...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi,
>
> I thought a UML-model would be at M1, the UML-Metamodel at M2. Profiles
> incl. Stereotypes are 'something' in between, because they're actually
> 'modelled' at M1, but somehow belong to M2, because they're extending
> the UML-language. This is why the hole dynamic EMF and annotate the
> profile with it's ecore represenation is needed.

Consider the annotation and the ecore representation therein an
implementation detail that is needed because profile support is implemented
using EMF. If the UML API and profile support were not implemented using
EMF, you would not see such annotations. The dynamic EMF definition has
really nothing to do with UML itself ( as described by the OMG ).

>
> So when the profile is converted to an ecore-instance -from M1 to M2-
> it's on the same level as the UML2 Metamodel/superstructure is.

When you create an ecore representation of your profile (ie. define your
profile ) you are not changing metalevels. You are simply converting from
a UML representation to an .ecore representation.

>
> What I don't understand - or misunderstand- is: the profile-elements
> should still be able to inherit from other meta-elements, like
> uml:Package, uml:Class, Classifier and Stereotype. So when I now code
> some stuff, having a Profile P with a stereotype S, and I use the their
> emf-objects, my P is not an instance of Profile and S is not an
> instanceof Stereotype.
>
> UMLUtils solved this problem in my case, but now I would like to know it
> :D

UMLUtils provide some methods to return a named element given some ecore
representation and vice versa.
UMLUtil::getNamedElement() , UMLUtil.getStereotype() etc.

>
> - -stefan
>
> James Bruck schrieb:
>> Hi ,
>>
>> Yes Profile2EPackageConverter is the code that does the conversion.
>>
>> org.eclipse.uml2.uml.Stereotype is mapped to EClass.
>>
>> When you say ... "an EClass which extends oe.uml2.uml.Stereotype", I
>> think
>> you might have a bit of a misconception about the inheritance. In the
>> Ecore metamodel there is no such thing as a uml stereotype so the EClass
>> that gets created cannot extend something from the uml metamodel. There
>> is
>> a mapping from a uml concept (Stereotype) to an ecore concept (EClass).
>>
>> Cheers,
>>
>> - James
>>
>>
>>
>> "SKuhn" <kuhn@oio.de> wrote in message
>> news:ffiia2$n5e$1@build.eclipse.org...
>> hi,
>>
>> I assume the Profile2EPackageConverter does the stuff when you define a
>> profile.
>>
>> I'm wondering why in this case a Stereotype in uml isn't mapped to an
>> EClass which extends oe.uml2.uml.Stereotype. For UML2EcoreConverter this
>> behaviour might be good, because it reduces complexity and breaks
>> dependency to uml2.uml. But in the context of uml I think it's better if
>> it's really a subtype of stereotype. What's the reason it's not?
>>
>> -stefan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD4DBQFHHR3qIYVWjMSpDwwRAhj8AJjN+ebfiTLlMytBT51ti5QNh1QAAJ4k fqQw
> 0hnTeusFtHzBsTTXbF2KrA==
> =7ujP
> -----END PGP SIGNATURE-----

Re: Profile2EPackageConverter [message #476427 is a reply to message #476412]

Thu, 25 October 2007 09:58

Eclipse User

Stefan,

We considered having the Ecore representations of profiles/stereotypes
extend the Ecore representations of their extended metamodels/metaclasses,
but since profiles and stereotypes can be applied/unapplied dynamically this
would mean we would have to effectively change the Ecore class of an element
at runtime when a stereotype is applied. Also, the fact that multiple
stereotypes can be applied effectively means that an element would be an
instance of several metaclasses, which is possible (in theory) in UML but
does not map very well to EMF/Java. So, we chose to take a facet approach,
where each stereotype application is an instance of its own Ecore class
which captures (only) the properties defined by the corresponding
stereotype.

Kenn

"SKuhn" <kuhn@oio.de> wrote in message
news:ffj6nd$sf8$1@build.eclipse.org...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi,
>
> I thought a UML-model would be at M1, the UML-Metamodel at M2. Profiles
> incl. Stereotypes are 'something' in between, because they're actually
> 'modelled' at M1, but somehow belong to M2, because they're extending
> the UML-language. This is why the hole dynamic EMF and annotate the
> profile with it's ecore represenation is needed.
>
> So when the profile is converted to an ecore-instance -from M1 to M2-
> it's on the same level as the UML2 Metamodel/superstructure is.
>
> What I don't understand - or misunderstand- is: the profile-elements
> should still be able to inherit from other meta-elements, like
> uml:Package, uml:Class, Classifier and Stereotype. So when I now code
> some stuff, having a Profile P with a stereotype S, and I use the their
> emf-objects, my P is not an instance of Profile and S is not an
> instanceof Stereotype.
>
> UMLUtils solved this problem in my case, but now I would like to know it
> :D
>
> - -stefan
>
> James Bruck schrieb:
>> Hi ,
>>
>> Yes Profile2EPackageConverter is the code that does the conversion.
>>
>> org.eclipse.uml2.uml.Stereotype is mapped to EClass.
>>
>> When you say ... "an EClass which extends oe.uml2.uml.Stereotype", I
>> think
>> you might have a bit of a misconception about the inheritance. In the
>> Ecore metamodel there is no such thing as a uml stereotype so the EClass
>> that gets created cannot extend something from the uml metamodel. There
>> is
>> a mapping from a uml concept (Stereotype) to an ecore concept (EClass).
>>
>> Cheers,
>>
>> - James
>>
>>
>>
>> "SKuhn" <kuhn@oio.de> wrote in message
>> news:ffiia2$n5e$1@build.eclipse.org...
>> hi,
>>
>> I assume the Profile2EPackageConverter does the stuff when you define a
>> profile.
>>
>> I'm wondering why in this case a Stereotype in uml isn't mapped to an
>> EClass which extends oe.uml2.uml.Stereotype. For UML2EcoreConverter this
>> behaviour might be good, because it reduces complexity and breaks
>> dependency to uml2.uml. But in the context of uml I think it's better if
>> it's really a subtype of stereotype. What's the reason it's not?
>>
>> -stefan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD4DBQFHHR3qIYVWjMSpDwwRAhj8AJjN+ebfiTLlMytBT51ti5QNh1QAAJ4k fqQw
> 0hnTeusFtHzBsTTXbF2KrA==
> =7ujP
> -----END PGP SIGNATURE-----

Re: Profile2EPackageConverter [message #625290 is a reply to message #476409]

Mon, 22 October 2007 17:39

Eclipse User