Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Question about extending classes with multiple stereotypes
Question about extending classes with multiple stereotypes [message #477952] Mon, 10 November 2008 12:07 Go to next message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
Hi

I made a custom uml profile for our models. At the moment it only contains
three stereotypes. One is abstract and the other two inherit from this
abstract stereotype.

I then established an extension for uml::Class and linked it with the
abstract stereotype. I also made it be a required extension, so the
multiplicity of the extension end ist 1...1

Now I assumed this means that any class in my model must ALWAYS HAVE
EXACTLY ONE stereotype that inherits from my abstract stereotype.

But still it is possible to say:

umlClass.applyStereotype(ConcreteStereotype1);
umlClass.applyStereotype(ConcreteStereotype2);

Then my umlClass will have both stereotypes assigned. Is this a bug? For I
guessed multiple stereotypes for metaclasses are only possible if you make
an extension for each one?

Can someone bring light into this?

Best regards
Re: Question about extending classes with multiple stereotypes [message #477958 is a reply to message #477952] Tue, 11 November 2008 15:21 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Alex,

I think you are right when you say: For I guessed multiple stereotypes for
metaclasses are only possible if you make an extension for each one?
The Element.isStereotypeApplicable(), is implemented that way and I also
confirmed this by playing around with the UML editor.

You are correct in creating a required stereotype by setting the lower bound
of the extension end to 1. Extension::isRequired() checks the lower bound
of the first owned end.

So I'm not sure why you can succesfully apply the second stereotype as you
mention.

Can you post a small piece of your profile and model so I can see what
exactly is going on.

Cheers,
- James.




"Alex " <eistoeter@gmx.de> wrote in message
news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
> Hi
>
> I made a custom uml profile for our models. At the moment it only contains
> three stereotypes. One is abstract and the other two inherit from this
> abstract stereotype.
>
> I then established an extension for uml::Class and linked it with the
> abstract stereotype. I also made it be a required extension, so the
> multiplicity of the extension end ist 1...1
>
> Now I assumed this means that any class in my model must ALWAYS HAVE
> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>
> But still it is possible to say:
>
> umlClass.applyStereotype(ConcreteStereotype1);
> umlClass.applyStereotype(ConcreteStereotype2);
>
> Then my umlClass will have both stereotypes assigned. Is this a bug? For I
> guessed multiple stereotypes for metaclasses are only possible if you make
> an extension for each one?
>
> Can someone bring light into this?
>
> Best regards
>
Re: Question about extending classes with multiple stereotypes [message #477959 is a reply to message #477958] Wed, 12 November 2008 06:53 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
I was curious about this issue as I had never noticed that feature
before. I decided to implement support for abstract stereotypes and
required extensions in the TextUML Toolkit. See:

http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/

But back to the topic - from what I observed when playing with the
latest TextUML Toolkit implementation (based on UML2 2.2):

1) a required extension causes the declaring stereotype to be implicitly
applied to all instances of the extended metaclass on a package where
the defining profile is applied;
2) that effect applies only to the stereotype declaring the extension,
not to any substereotypes (which makes a lot of sense), which still must
be applied explicitly;
3) as with other kinds of classifiers, abstract stereotypes cannot be
instantiated (applied), which also makes a lot of sense;

Corollary: making an abstract stereotype declare a required extension
has no effect whatsoever, and thus is pointless.

Finally, for two stereotypes A and B, where B specializes A, it seems to
be legal to apply both B and A to a target metaclass instance. So even
if "3" above was not true, or if you made your base stereotype
non-abstract, it would be valid to apply the substereotypes. This does
not seem to be covered by the UML specification.

Granted, much of what is said above is based on observation of the
behavior of the MDT UML2 implementation, but I think that the observed
behavior makes a lot of sense, and seems to be well aligned with the UML
spec.

Also, maybe there should be a constraint in the UML spec that ensured
that abstract stereotypes did not declare required extensions.

Does this all make sense?

Cheers,

Rafael

James Bruck wrote:
> Hi Alex,
>
> I think you are right when you say: For I guessed multiple stereotypes for
> metaclasses are only possible if you make an extension for each one?
> The Element.isStereotypeApplicable(), is implemented that way and I also
> confirmed this by playing around with the UML editor.
>
> You are correct in creating a required stereotype by setting the lower bound
> of the extension end to 1. Extension::isRequired() checks the lower bound
> of the first owned end.
>
> So I'm not sure why you can succesfully apply the second stereotype as you
> mention.
>
> Can you post a small piece of your profile and model so I can see what
> exactly is going on.
>
> Cheers,
> - James.
>
>
>
>
> "Alex " <eistoeter@gmx.de> wrote in message
> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>> Hi
>>
>> I made a custom uml profile for our models. At the moment it only contains
>> three stereotypes. One is abstract and the other two inherit from this
>> abstract stereotype.
>>
>> I then established an extension for uml::Class and linked it with the
>> abstract stereotype. I also made it be a required extension, so the
>> multiplicity of the extension end ist 1...1
>>
>> Now I assumed this means that any class in my model must ALWAYS HAVE
>> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>
>> But still it is possible to say:
>>
>> umlClass.applyStereotype(ConcreteStereotype1);
>> umlClass.applyStereotype(ConcreteStereotype2);
>>
>> Then my umlClass will have both stereotypes assigned. Is this a bug? For I
>> guessed multiple stereotypes for metaclasses are only possible if you make
>> an extension for each one?
>>
>> Can someone bring light into this?
>>
>> Best regards
>>
>
>
Re: Question about extending classes with multiple stereotypes [message #477960 is a reply to message #477959] Wed, 12 November 2008 07:02 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Btw, I am attaching here the TextUML project I mentioned in my previous
post (requires r161 from
https://textuml.svn.sourceforge.net/svnroot/textuml/).

This is the TextUML source:


>>> prof.tuml:
profile prof;

abstract stereotype AbstractBasic extends uml::Class required
end;

stereotype ConcreteSub1 specializes AbstractBasic
end;

stereotype ConcreteSub2 specializes AbstractBasic
end;

stereotype ConcreteBasic extends uml::Class required
end;

end.

>>> pack1.tuml:
package pack1;

apply prof;

[ConcreteSub2]
class MyClass
end;

end.


Note that the resulting pack1.uml package will have both ConcreteSub1
and ConcreteBasic stereotypes applied to MyClass (the first, explicitly,
the second implicitly).

Cheers,

Rafael
Re: Question about extending classes with multiple stereotypes [message #477961 is a reply to message #477960] Wed, 12 November 2008 07:05 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060801050404000409000503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rafael Chaves wrote:
> Btw, I am attaching here...

Er... now, for real.

--------------060801050404000409000503
Content-Type: application/x-zip-compressed;
name="required-extension.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="required-extension.zip"

UEsDBBQACAAIAJq4azkAAAAAAAAAAAAAAAAcAAAAcmVxdWlyZWQtZXh0ZW5z aW9ucy8ucHJv
amVjdG2QQQ7CIBBF15p4B9O9oDsXWBcaL6AegMLEYITWYTAeX6DUpsYd/8+f /wCxf9vH8gXo
Tet21YatqyU41WrjbrvqejmtttW+XsxFh+0dFB3BKzQdxXR0Z8JJCzXCMxgE vYI3gUtNXvA8
SRHVWguOasGHU3JLn8+CT1QTzEOfO1BJFXmIq9Lp7BRqbGOy8YSSiFmtWTAs ZwFHegxLvIWE
9UXzqSH4L6A4ww0ijQJCSffiL7wfJXaO5KZx9/vI6Rd+AFBLBwi/fVhDwAAA AIEBAABQSwME
FAAIAAgAmrhrOQAAAAAAAAAAAAAAABoAAAByZXF1aXJlZC1leHRlbnNpb25z L015LnVtbK2U
3W6bQBCF7yv1HVbba7NAq6pCppHtEqUJpEkdq01u0GYZ41VgQSwJ+O2z/Bho MG1T9crWcM7H
zJmx5ydlHKEnyCRPhI0NTccIBEsCLkIbb25OZ5/wyee3b+ZlzK2f3ldUfXZy UzOwqkRCWqpu
412epxYhku0gploSh1qShUSmwIjykqFc9vKiKLTifS01dd1QUnddE2ZcyJwK BgcXsCSDX3zA
Ip5KqM0QbyuASZxKdvCkWbLtLG1rklRV4gdBbCzcpe8E5tn+47r8cMcuTwui D72+MeW+WJ6X
zF0tp9yPcTTZq3pmVnloOtl4rnJIbjV0N2E0r9N9Xc+oeqwp7jslEcy5fylB r5tiwKsl2UsJ
VmeB0FwprCvKHmgI9XHwwMb+2YX+xEZNYiRorPbn7RuvcqeNM3AiiEHkNSHf p0pUcVcRlRL3
WNe54b/DNnrSwdUEPIJFmka8CbVHfbud5ZvR2Ie+lBkWQiR57ZJDm7+5HduQ TB4zNn2a7br1
dt3dW9R7MthCpn5yIAfD14duOW2uGO2UysZ/3Ajp2yfD/vsyrbKA4KpJZsxd XP64Ho/XJUrG
kTZXQAZn0FQqpbVKBMsgB6NPkF/L8/DIDu+pBL9e4PSiSY/2DWtJJWc9eO0Z d+ND/hfwka7X
nike/ivc7OH0y/fySOp/DZ+T9t9ZfX8GUEsHCD61MF8AAgAA0QUAAFBLAwQU AAgACACauGs5
AAAAAAAAAAAAAAAAHgAAAHJlcXVpcmVkLWV4dGVuc2lvbnMvcGFjazEudHVt bCtITM5OTE9V
KADShta8XLxciQUFOZUKBUX5aWButHN+XnJRaklqcGmSUawCL1dyTmJxsYJv pTOI5uVKzUsB
qlMAM/QAUEsHCAq7EDZEAAAATgAAAFBLAwQUAAgACACauGs5AAAAAAAAAAAA AAAAHQAAAHJl
cXVpcmVkLWV4dGVuc2lvbnMvcGFjazEudW1spVTRjtMwEHxH4h8i83xxGhCH opbTUfW4Si0C
9YqAl8pxtqlFbEe207R/zyZpm1zangQ8JXJmZsezuxne7WTmbcFYodWIDPyA eKC4ToRKR2T5
9HDzgdx9fP1quJMi+jGfetXzBA/9AcGTTNkIz0dk41weUWr5BiTztUx9bVJq c+AUubQLty28
LEu/fFtDwyAYIHS2qBVuhLKOKQ5HFnBt4BkPeCZyCzUZ5LoSCOmkgh05udHr E+VgzdLqlK5u
IU6ns/HnSRI+7t8vdu9+8S8PJQ2O3EJmV6vht7C6kR/Q5XyGDCuiRn2mOXN1 Pn9X1as++6j7
BiH8cR73IQQb4XlDRERfGf/NUqjbIZIRWd0mruBnosRTTGJiOcIHDR0F4F4p 7WqPtqdwXtOz
ujAcNbiWPoutM8w5KpOEEnoUzBs3U5lr4zqKkHxfXlDcCitikQm3R2dGbJmD ozcUE7UKJN0r
un2ODuqLY0Yiw+5uDKwrehvZ5Kk8D+DkkT4z2XOeTDKQoFyv2Dhj1pJeROZa yPN9g29jabze
53kmmpHoZsOLb+d22xiuNKmivdCkl4c1OAzrqQrWwRjB4MqD7Vy+XrRocmjB pbAvzidt7dOu
//aYVVlgb5tk/qGJZ5E2O0E7S9GcVMhorBU34OATs4L3BvPCssTMwqpu4vVm 0wvyiyIOu+rp
T/0f6kN6+Nni+x9QSwcIIM/atAwCAACgBQAAUEsDBBQACAAIAJq4azkAAAAA AAAAAAAAAAAd
AAAAcmVxdWlyZWQtZXh0ZW5zaW9ucy9wcm9mLnR1bWydjkEKAjEQBO+B/GFe IOhxPek+wRfM
ZlsYiJs4MwHd1xvEg3gRPTV0U0VXLWfJoNpzH0MMPJkrJydzKIrfK+jw6o5s kgg3xzIbtUse
hjGzGSmuTRRzDH15at7osSxJ4Ti1aUtWkYSzrLAP7Td29y/7w+uemwdQSwcI bXnaMHUAAAAS
AQAAUEsDBBQACAAIAJq4azkAAAAAAAAAAAAAAAAcAAAAcmVxdWlyZWQtZXh0 ZW5zaW9ucy9w
cm9mLnVtbN1Y227aQBB9r9R/sJzneglqkwhBI5I6DRIQK5Cm6gta7MGxYnut 3SWQfn1njQ2+
EkKI1PYF5MvMnDlnLgvt82Xga0/AhcfCjn5sNHQNQps5Xuh29Lvx1acz/fzr xw/teeC3LM5m
ng/aMvBaa5OmcazjHT8ULbzf0R+kjFqECPsBAmqwwDUYd4mIwCY/Bz2SeR1s xmFtsFgsDLB9
LxIQW0AwI81Go0lM9VpqgzBqLfBZU/k3GuRu0NdjmJ7T0SenYI4X/cvvptO8 fj4ZLT//sodX
C10LaYDxI8xK1wKQNGAO+LcwA44UQGzYZ27ZEPnQtDZ0w5BJKpEFUYg1LccS bM6VT5sFBp0K
yamUJHAcopPt7uzrQQX01N12KhoJFXEEjGGzUEIoV/7lc4QOYhFapkXtR+qC XohckUiWtFDc
3fbWIBLNBVEPCTqYur0SdNJQZhaHmbdM3CToFAeXPhXCm3lYXGWM8cMiQl6H sBuTbMsLKjxb
12hy2dEln8Mm5nbmT9/KvMbTchJpcZQRkxyaEQK05ZxT/woofkMFFesiLdAx rK3yKRUwSRhk
3EFrtJlRX6ALny2AX7B5iLeOs9QoOGOMW6vFA6a3Yz8eEbIyymVLKtLd1APJ FsRbymRYWyaX
LLQ5SBjNpziY8CsCrlIW9QW2W+0MD187J42yvOQd2LqpbfsMW82DsnVTIdCb 2Sqn8R5sWbU9
l7K1GkG7EWFt2R17E/GeI8eqba3/ZuS0Sbo4V6uaZOVb3YpW+7MXRIzLLEH1 Bwi08uLXwUm2
byZnddwaqONImnBE5UNAVc6Y2GRgjruDm29mf6QujfXhxUC7o0kjPVOQHKwc Usf0IcCUCjFH
EmVi6rp4ftp10XqiW7lq22wRgtOVknvTuYSs94H1uFMR4QezvZj2lNtyt2yk lPkyUunlaugV
lObLqE3yueTJTpl9C91Vk75qYaWAXAgBy9n7HZOTdWV9Oatwlbz/0pHkwDnt tlZezmn8ePfX
5PTiwSI3/Lc0wX3I9mqC++5j7YD5N5rAXOJsVT8m9cLgrK8XhWRSGDwBBFPg ZrieKSVatLpZ
k1MHPdQBxEd6YXDV9imkRkWcK7+1Q5W6Lgc30Rd/LUZMeBJePfziBfuD+vOi +n30hm3Sw4Xm
Ai+mU0H5k3KitnRBeSTj0JpX1nJO83xXFTTHFqrUvLK19tW8KkhZ8wLOjeaV E2NXzV/o9X00
x3QOpHmbZP4jwus/UEsHCKP27kGbAwAAWxIAAFBLAQIUABQACAAIAJq4azm/ fVhDwAAAAIEB
AAAcAAAAAAAAAAAAAAAAAAAAAAByZXF1aXJlZC1leHRlbnNpb25zLy5wcm9q ZWN0UEsBAhQA
FAAIAAgAmrhrOT61MF8AAgAA0QUAABoAAAAAAAAAAAAAAAAACgEAAHJlcXVp cmVkLWV4dGVu
c2lvbnMvTXkudW1sUEsBAhQAFAAIAAgAmrhrOQq7EDZEAAAATgAAAB4AAAAA AAAAAAAAAAAA
UgMAAHJlcXVpcmVkLWV4dGVuc2lvbnMvcGFjazEudHVtbFBLAQIUABQACAAI AJq4azkgz9q0
DAIAAKAFAAAdAAAAAAAAAAAAAAAAAOIDAAByZXF1aXJlZC1leHRlbnNpb25z L3BhY2sxLnVt
bFBLAQIUABQACAAIAJq4azltedowdQAAABIBAAAdAAAAAAAAAAAAAAAAADkG AAByZXF1aXJl
ZC1leHRlbnNpb25zL3Byb2YudHVtbFBLAQIUABQACAAIAJq4azmj9u5BmwMA AFsSAAAcAAAA
AAAAAAAAAAAAAPkGAAByZXF1aXJlZC1leHRlbnNpb25zL3Byb2YudW1sUEsF BgAAAAAGAAYA
vgEAAN4KAAAAAA==
--------------060801050404000409000503--
Re: Question about extending classes with multiple stereotypes [message #477962 is a reply to message #477959] Wed, 12 November 2008 12:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Rafael,

I do not agree that the behaviour observed in the MDT UML2
implementation is consistent wth the UML specification or its intention.

The discussion of the MOF equivalent of a metaclass extension makes it
clear that the semantics of Extensions are consistent with those of
ordinary Associations. Thus, the multiplicities of extension ends have
the same meaning as for association ends: they constrain the number of
links (association instances) that can have some instance of a class (in
this case, a stereotype) in a particular role, linked to the same object
(in this case, a UML element, instance of the extended metaclass) in the
other role.

So, in any metaclass extension, it actually means that at most one
instance of the stereotype (or any stereotype conforming to it) can be
linked by that extension to the same instance of the extended metaclass.
This is just like any other association. Consider an association like
this:

Car [1] -------- [4] Wheel

with MagWheel specializing Wheel. We cannot have a Car with 4 Wheels
and 4 MagWheels. So it is, also, with stereotype generalization and
metaclass extensions.

It makes sense for an abstract stereotype to have a required extension,
because this simply means that an instance of that stereotype must be
linked to an instance of the extended metaclass. It can be an instance
of any concrete sub-stereotype, but nonetheless only one instance.

It does appear to me that, in the more general case, the ability to
apply multiple sub-stereotypes of a stereotype to a single element,
where the extension is defined on the super-stereotype, is a bug in
UML2. It's also a special case of a more general problem of not
validating the multiplicities of non-navigable association ends, because
they don't exist in the Ecore representation.

Cheers,

Christian

Rafael Chaves wrote:
> I was curious about this issue as I had never noticed that feature
> before. I decided to implement support for abstract stereotypes and
> required extensions in the TextUML Toolkit. See:
>
> http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/
>
>
> But back to the topic - from what I observed when playing with the
> latest TextUML Toolkit implementation (based on UML2 2.2):
>
> 1) a required extension causes the declaring stereotype to be implicitly
> applied to all instances of the extended metaclass on a package where
> the defining profile is applied;
> 2) that effect applies only to the stereotype declaring the extension,
> not to any substereotypes (which makes a lot of sense), which still must
> be applied explicitly;
> 3) as with other kinds of classifiers, abstract stereotypes cannot be
> instantiated (applied), which also makes a lot of sense;
>
> Corollary: making an abstract stereotype declare a required extension
> has no effect whatsoever, and thus is pointless.
>
> Finally, for two stereotypes A and B, where B specializes A, it seems to
> be legal to apply both B and A to a target metaclass instance. So even
> if "3" above was not true, or if you made your base stereotype
> non-abstract, it would be valid to apply the substereotypes. This does
> not seem to be covered by the UML specification.
>
> Granted, much of what is said above is based on observation of the
> behavior of the MDT UML2 implementation, but I think that the observed
> behavior makes a lot of sense, and seems to be well aligned with the UML
> spec.
>
> Also, maybe there should be a constraint in the UML spec that ensured
> that abstract stereotypes did not declare required extensions.
>
> Does this all make sense?
>
> Cheers,
>
> Rafael
>
> James Bruck wrote:
>> Hi Alex,
>>
>> I think you are right when you say: For I guessed multiple stereotypes
>> for metaclasses are only possible if you make an extension for each one?
>> The Element.isStereotypeApplicable(), is implemented that way and I
>> also confirmed this by playing around with the UML editor.
>>
>> You are correct in creating a required stereotype by setting the lower
>> bound of the extension end to 1. Extension::isRequired() checks the
>> lower bound of the first owned end.
>>
>> So I'm not sure why you can succesfully apply the second stereotype as
>> you mention.
>>
>> Can you post a small piece of your profile and model so I can see what
>> exactly is going on.
>>
>> Cheers,
>> - James.
>>
>>
>>
>>
>> "Alex " <eistoeter@gmx.de> wrote in message
>> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>>> Hi
>>>
>>> I made a custom uml profile for our models. At the moment it only
>>> contains three stereotypes. One is abstract and the other two inherit
>>> from this abstract stereotype.
>>>
>>> I then established an extension for uml::Class and linked it with the
>>> abstract stereotype. I also made it be a required extension, so the
>>> multiplicity of the extension end ist 1...1
>>>
>>> Now I assumed this means that any class in my model must ALWAYS HAVE
>>> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>>
>>> But still it is possible to say:
>>>
>>> umlClass.applyStereotype(ConcreteStereotype1);
>>> umlClass.applyStereotype(ConcreteStereotype2);
>>>
>>> Then my umlClass will have both stereotypes assigned. Is this a bug?
>>> For I guessed multiple stereotypes for metaclasses are only possible
>>> if you make an extension for each one?
>>>
>>> Can someone bring light into this?
>>>
>>> Best regards
>>>
>>
>>
Re: Question about extending classes with multiple stereotypes [message #477963 is a reply to message #477962] Wed, 12 November 2008 13:00 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

I suppose a simpler way to look at the problem is to imagine what would
happen if the ExtensionEnd were actually owned by the extended
metaclass, instead of the Extension.

Then, it would be clear that:

- defining the Extension on an abstract Stereotype makes sense,
because we use properties of abstract type all the time
- an element of that metaclass can have at most one instance of
the stereotype or any of its specializations

Cheers,

Christian


Christian W. Damus wrote:
> Hi, Rafael,
>
> I do not agree that the behaviour observed in the MDT UML2
> implementation is consistent wth the UML specification or its intention.

-----8<-----
Re: Question about extending classes with multiple stereotypes [message #477964 is a reply to message #477962] Wed, 12 November 2008 13:41 Go to previous messageGo to next message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
Hi Christian,

thanks for your answer. I totally agree with your explanation. I also
understood it that way from the uml superstructure that's why I modeled it
so and was confused why I was able to assign multiple concrete stereotypes
from the stereotype hierarchy.
Re: Question about extending classes with multiple stereotypes [message #477965 is a reply to message #477958] Wed, 12 November 2008 13:54 Go to previous messageGo to next message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
Hi James. Thanks for your interest in this problem.

Here comes the profile:

<?xml version="1.0" encoding="UTF-8"?>
<uml:Profile xmi:version="2.1"
xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
xmi:id="_itvycKXKEd2-KYIfOrm7fA" name="Faktor-IPS Profile"
metaclassReference="_qVRZoKwOEd2sZYFMsQch6A">
<elementImport xmi:id="_qVRZoKwOEd2sZYFMsQch6A" alias="Class">
<importedElement xmi:type="uml:Class"
href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
</elementImport>
<packagedElement xmi:type="uml:Stereotype"
xmi:id="_mvNcwKXKEd2-KYIfOrm7fA" name="PolicyCmptType">
<generalization xmi:id="_nVypYKwREd2z9Lg5-Fmnrw"
general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype"
xmi:id="_-9kMQKXMEd2-KYIfOrm7fA" name="ProductCmptType2">
<generalization xmi:id="_wkZG8KwREd2z9Lg5-Fmnrw"
general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype"
xmi:id="_e6t6gKwREd2z9Lg5-Fmnrw" name="Type" isAbstract="true">
<ownedAttribute xmi:id="_7pE8YawREd2z9Lg5-Fmnrw" name="base_Class"
association="_7o4IEKwREd2z9Lg5-Fmnrw">
<type xmi:type="uml:Class"
href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension"
xmi:id="_7o4IEKwREd2z9Lg5-Fmnrw" name="Class_Type"
memberEnd="_7pE8YKwREd2z9Lg5-Fmnrw _7pE8YawREd2z9Lg5-Fmnrw">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_7pE8YKwREd2z9Lg5-Fmnrw"
name="extension_IpsObject" type="_e6t6gKwREd2z9Lg5-Fmnrw"
aggregation="composite" association="_7o4IEKwREd2z9Lg5-Fmnrw">
<lowerValue xmi:type="uml:LiteralInteger"
xmi:id="_BwxTYKwSEd2z9Lg5-Fmnrw" value="1"/>
</ownedEnd>
</packagedElement>
</uml:Profile>

And here comes an example model for it. I should not be able to assign
these two stereotypes to myclass but only one of both:

<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:FaktorIPSProfile="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
xsi:schemaLocation="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0
../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _Ztzm0LCdEd2r-NXccNaiJQ ">
<uml:Model xmi:id="_q8bikK0GEd2GcoPSbdQh2w" name="example">
<packagedElement xmi:type="uml:Class" xmi:id="_48SHILDAEd24mM2Z0RL5og"
name="myclass"/>
<profileApplication xmi:id="_3ZgFwLDAEd24mM2Z0RL5og">
<eAnnotations xmi:id="_3ZpPsLDAEd24mM2Z0RL5og"
source="http://www.eclipse.org/uml2/2.0.0/UML">
<references xmi:type="ecore:EPackage"
href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _Ztzm0LCdEd2r-NXccNaiJQ "/>
</eAnnotations>
<appliedProfile
href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _itvycKXKEd2-KYIfOrm7fA "/>
</profileApplication>
</uml:Model>
<FaktorIPSProfile:PolicyCmptType xmi:id="_7-YmMLDAEd24mM2Z0RL5og"
base_Class="_48SHILDAEd24mM2Z0RL5og"/>
<FaktorIPSProfile:ProductCmptType2 xmi:id="_7-i-QLDAEd24mM2Z0RL5og"
base_Class="_48SHILDAEd24mM2Z0RL5og"/>
</xmi:XMI>

Even more critical is, that I have no possibility to unassign any of these
two stereotypes. So I can add one stereotype and I can't unassign it. This
is the wanted behaviour. But I can add another stereotype and then I can't
unassign any of these two.
Re: Question about extending classes with multiple stereotypes [message #477966 is a reply to message #477962] Wed, 12 November 2008 16:11 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Christian, I guess you are saying that the fact that UML2 that allows a
a stereotype and a substereotype to be associated with a metaclass
instance makes the implementation incorrect.

Ok, I can agree with that.

But I still think that attempts to instantiate an abstract stereotype as
a required extension should fail/be ignored, and that the 'required'
aspect of an extension should not inherited. And that is how it
currently works.

And that is the root of Alex's problem: even if UML2 prevented
stereotype/substereotype from being applied simultaneously to the same
instance of a metaclass, his example should still work fine (i.e. not
fail), because the base stereotype declaring the required extension is
abstract, which is a no-op.

Cheers,

Rafael

Christian W. Damus wrote:
> Hi, Rafael,
>
> I do not agree that the behaviour observed in the MDT UML2
> implementation is consistent wth the UML specification or its intention.
>
> The discussion of the MOF equivalent of a metaclass extension makes it
> clear that the semantics of Extensions are consistent with those of
> ordinary Associations. Thus, the multiplicities of extension ends have
> the same meaning as for association ends: they constrain the number of
> links (association instances) that can have some instance of a class (in
> this case, a stereotype) in a particular role, linked to the same object
> (in this case, a UML element, instance of the extended metaclass) in the
> other role.
>
> So, in any metaclass extension, it actually means that at most one
> instance of the stereotype (or any stereotype conforming to it) can be
> linked by that extension to the same instance of the extended metaclass.
> This is just like any other association. Consider an association like
> this:
>
> Car [1] -------- [4] Wheel
>
> with MagWheel specializing Wheel. We cannot have a Car with 4 Wheels
> and 4 MagWheels. So it is, also, with stereotype generalization and
> metaclass extensions.
>
> It makes sense for an abstract stereotype to have a required extension,
> because this simply means that an instance of that stereotype must be
> linked to an instance of the extended metaclass. It can be an instance
> of any concrete sub-stereotype, but nonetheless only one instance.
>
> It does appear to me that, in the more general case, the ability to
> apply multiple sub-stereotypes of a stereotype to a single element,
> where the extension is defined on the super-stereotype, is a bug in
> UML2. It's also a special case of a more general problem of not
> validating the multiplicities of non-navigable association ends, because
> they don't exist in the Ecore representation.
>
> Cheers,
>
> Christian
>
> Rafael Chaves wrote:
>> I was curious about this issue as I had never noticed that feature
>> before. I decided to implement support for abstract stereotypes and
>> required extensions in the TextUML Toolkit. See:
>>
>> http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/
>>
>>
>> But back to the topic - from what I observed when playing with the
>> latest TextUML Toolkit implementation (based on UML2 2.2):
>>
>> 1) a required extension causes the declaring stereotype to be
>> implicitly applied to all instances of the extended metaclass on a
>> package where the defining profile is applied;
>> 2) that effect applies only to the stereotype declaring the extension,
>> not to any substereotypes (which makes a lot of sense), which still
>> must be applied explicitly;
>> 3) as with other kinds of classifiers, abstract stereotypes cannot be
>> instantiated (applied), which also makes a lot of sense;
>>
>> Corollary: making an abstract stereotype declare a required extension
>> has no effect whatsoever, and thus is pointless.
>>
>> Finally, for two stereotypes A and B, where B specializes A, it seems
>> to be legal to apply both B and A to a target metaclass instance. So
>> even if "3" above was not true, or if you made your base stereotype
>> non-abstract, it would be valid to apply the substereotypes. This does
>> not seem to be covered by the UML specification.
>>
>> Granted, much of what is said above is based on observation of the
>> behavior of the MDT UML2 implementation, but I think that the observed
>> behavior makes a lot of sense, and seems to be well aligned with the
>> UML spec.
>>
>> Also, maybe there should be a constraint in the UML spec that ensured
>> that abstract stereotypes did not declare required extensions.
>>
>> Does this all make sense?
>>
>> Cheers,
>>
>> Rafael
>>
>> James Bruck wrote:
>>> Hi Alex,
>>>
>>> I think you are right when you say: For I guessed multiple
>>> stereotypes for metaclasses are only possible if you make an
>>> extension for each one?
>>> The Element.isStereotypeApplicable(), is implemented that way and I
>>> also confirmed this by playing around with the UML editor.
>>>
>>> You are correct in creating a required stereotype by setting the
>>> lower bound of the extension end to 1. Extension::isRequired()
>>> checks the lower bound of the first owned end.
>>>
>>> So I'm not sure why you can succesfully apply the second stereotype
>>> as you mention.
>>>
>>> Can you post a small piece of your profile and model so I can see
>>> what exactly is going on.
>>>
>>> Cheers,
>>> - James.
>>>
>>>
>>>
>>>
>>> "Alex " <eistoeter@gmx.de> wrote in message
>>> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>>>> Hi
>>>>
>>>> I made a custom uml profile for our models. At the moment it only
>>>> contains three stereotypes. One is abstract and the other two
>>>> inherit from this abstract stereotype.
>>>>
>>>> I then established an extension for uml::Class and linked it with
>>>> the abstract stereotype. I also made it be a required extension, so
>>>> the multiplicity of the extension end ist 1...1
>>>>
>>>> Now I assumed this means that any class in my model must ALWAYS HAVE
>>>> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>>>
>>>> But still it is possible to say:
>>>>
>>>> umlClass.applyStereotype(ConcreteStereotype1);
>>>> umlClass.applyStereotype(ConcreteStereotype2);
>>>>
>>>> Then my umlClass will have both stereotypes assigned. Is this a bug?
>>>> For I guessed multiple stereotypes for metaclasses are only possible
>>>> if you make an extension for each one?
>>>>
>>>> Can someone bring light into this?
>>>>
>>>> Best regards
>>>>
>>>
>>>
Re: Question about extending classes with multiple stereotypes [message #477967 is a reply to message #477966] Wed, 12 November 2008 17:05 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Rafael,

See some comments in-line, below.

cW

Rafael Chaves wrote:
> Christian, I guess you are saying that the fact that UML2 that allows a
> a stereotype and a substereotype to be associated with a metaclass
> instance makes the implementation incorrect.
>
> Ok, I can agree with that.
>
> But I still think that attempts to instantiate an abstract stereotype as
> a required extension should fail/be ignored, and that the 'required'
> aspect of an extension should not inherited. And that is how it
> currently works.

I think the requiredness seems not to be inherited simply because the
API doesn't know which concrete Stereotype to instantiate. It can be
argued that the default creation of stereotype instances for required
stereotypes, though friendly in simple cases without stereotype
generalization, is unnecessary and inconsistent.

It's unnecessary because multiplicity lower bounds are simply
constraints stipulating that a model is invalid if the property (in this
case an extension end) doesn't have a certain number of values. It
doesn't mean that a tool should try to create values to satisfy the
constraint. :-)

It's inconsistent because the API cannot create the stereotype
application that a user needs in the case of stereotype generalization.

In general, and in the case of ExtensionEnds, the multiplicity of a
property is always inherited by specializing classifier context, unless
it is explicitly replaced by a redefining property.


> And that is the root of Alex's problem: even if UML2 prevented
> stereotype/substereotype from being applied simultaneously to the same
> instance of a metaclass, his example should still work fine (i.e. not
> fail), because the base stereotype declaring the required extension is
> abstract, which is a no-op.

What do you mean by "work fine?" Do you mean, that he should be able to
apply both of the concrete specializations? That would violate the
multiplicity of the extension end, which upper bound is 1. 2 is greater
than 1.

The fact that the extension is required is actually irrelevant to the
problem as Alex originally stated it. :-) His problem was with the
upper bound, not the lower.

>
> Cheers,
>
> Rafael
>
> Christian W. Damus wrote:
>> Hi, Rafael,
>>
>> I do not agree that the behaviour observed in the MDT UML2
>> implementation is consistent wth the UML specification or its intention.
>>
>> The discussion of the MOF equivalent of a metaclass extension makes it
>> clear that the semantics of Extensions are consistent with those of
>> ordinary Associations. Thus, the multiplicities of extension ends
>> have the same meaning as for association ends: they constrain the
>> number of links (association instances) that can have some instance of
>> a class (in this case, a stereotype) in a particular role, linked to
>> the same object (in this case, a UML element, instance of the extended
>> metaclass) in the other role.
>>
>> So, in any metaclass extension, it actually means that at most one
>> instance of the stereotype (or any stereotype conforming to it) can be
>> linked by that extension to the same instance of the extended
>> metaclass. This is just like any other association. Consider an
>> association like this:
>>
>> Car [1] -------- [4] Wheel
>>
>> with MagWheel specializing Wheel. We cannot have a Car with 4 Wheels
>> and 4 MagWheels. So it is, also, with stereotype generalization and
>> metaclass extensions.
>>
>> It makes sense for an abstract stereotype to have a required
>> extension, because this simply means that an instance of that
>> stereotype must be linked to an instance of the extended metaclass.
>> It can be an instance of any concrete sub-stereotype, but nonetheless
>> only one instance.
>>
>> It does appear to me that, in the more general case, the ability to
>> apply multiple sub-stereotypes of a stereotype to a single element,
>> where the extension is defined on the super-stereotype, is a bug in
>> UML2. It's also a special case of a more general problem of not
>> validating the multiplicities of non-navigable association ends,
>> because they don't exist in the Ecore representation.
>>
>> Cheers,
>>
>> Christian
>>
>> Rafael Chaves wrote:
>>> I was curious about this issue as I had never noticed that feature
>>> before. I decided to implement support for abstract stereotypes and
>>> required extensions in the TextUML Toolkit. See:
>>>
>>> http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/
>>>
>>>
>>> But back to the topic - from what I observed when playing with the
>>> latest TextUML Toolkit implementation (based on UML2 2.2):
>>>
>>> 1) a required extension causes the declaring stereotype to be
>>> implicitly applied to all instances of the extended metaclass on a
>>> package where the defining profile is applied;
>>> 2) that effect applies only to the stereotype declaring the
>>> extension, not to any substereotypes (which makes a lot of sense),
>>> which still must be applied explicitly;
>>> 3) as with other kinds of classifiers, abstract stereotypes cannot be
>>> instantiated (applied), which also makes a lot of sense;
>>>
>>> Corollary: making an abstract stereotype declare a required extension
>>> has no effect whatsoever, and thus is pointless.
>>>
>>> Finally, for two stereotypes A and B, where B specializes A, it seems
>>> to be legal to apply both B and A to a target metaclass instance. So
>>> even if "3" above was not true, or if you made your base stereotype
>>> non-abstract, it would be valid to apply the substereotypes. This
>>> does not seem to be covered by the UML specification.
>>>
>>> Granted, much of what is said above is based on observation of the
>>> behavior of the MDT UML2 implementation, but I think that the
>>> observed behavior makes a lot of sense, and seems to be well aligned
>>> with the UML spec.
>>>
>>> Also, maybe there should be a constraint in the UML spec that ensured
>>> that abstract stereotypes did not declare required extensions.
>>>
>>> Does this all make sense?
>>>
>>> Cheers,
>>>
>>> Rafael
>>>
>>> James Bruck wrote:
>>>> Hi Alex,
>>>>
>>>> I think you are right when you say: For I guessed multiple
>>>> stereotypes for metaclasses are only possible if you make an
>>>> extension for each one?
>>>> The Element.isStereotypeApplicable(), is implemented that way and I
>>>> also confirmed this by playing around with the UML editor.
>>>>
>>>> You are correct in creating a required stereotype by setting the
>>>> lower bound of the extension end to 1. Extension::isRequired()
>>>> checks the lower bound of the first owned end.
>>>>
>>>> So I'm not sure why you can succesfully apply the second stereotype
>>>> as you mention.
>>>>
>>>> Can you post a small piece of your profile and model so I can see
>>>> what exactly is going on.
>>>>
>>>> Cheers,
>>>> - James.
>>>>
>>>>
>>>>
>>>>
>>>> "Alex " <eistoeter@gmx.de> wrote in message
>>>> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>>>>> Hi
>>>>>
>>>>> I made a custom uml profile for our models. At the moment it only
>>>>> contains three stereotypes. One is abstract and the other two
>>>>> inherit from this abstract stereotype.
>>>>>
>>>>> I then established an extension for uml::Class and linked it with
>>>>> the abstract stereotype. I also made it be a required extension, so
>>>>> the multiplicity of the extension end ist 1...1
>>>>>
>>>>> Now I assumed this means that any class in my model must ALWAYS
>>>>> HAVE EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>>>>
>>>>> But still it is possible to say:
>>>>>
>>>>> umlClass.applyStereotype(ConcreteStereotype1);
>>>>> umlClass.applyStereotype(ConcreteStereotype2);
>>>>>
>>>>> Then my umlClass will have both stereotypes assigned. Is this a
>>>>> bug? For I guessed multiple stereotypes for metaclasses are only
>>>>> possible if you make an extension for each one?
>>>>>
>>>>> Can someone bring light into this?
>>>>>
>>>>> Best regards
>>>>>
>>>>
>>>>
Re: Question about extending classes with multiple stereotypes [message #477968 is a reply to message #477967] Wed, 12 November 2008 17:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

I should just clarify one statement:

cW

Christian W. Damus wrote:
>
> In general, and in the case of ExtensionEnds, the multiplicity of a
> property is always inherited by specializing classifier context, unless
> it is explicitly replaced by a redefining property.


The ExtensionEnd functions as a property of the *metaclass*, not the
stereotype. So, the redefinition context is actually the metaclass.
The extension end isn't inherited by sub-stereotypes, but actually by
subclasses of the extended metaclass! :-)
Re: Question about extending classes with multiple stereotypes [message #477970 is a reply to message #477965] Fri, 14 November 2008 15:10 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
.... I haven't forgotten about this ... will look into later today :)


"Alex " <eistoeter@gmx.de> wrote in message
news:a883f38111657994158a234966ee7db7$1@www.eclipse.org...
> Hi James. Thanks for your interest in this problem.
>
> Here comes the profile:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <uml:Profile xmi:version="2.1"
> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
> xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
> xmi:id="_itvycKXKEd2-KYIfOrm7fA" name="Faktor-IPS Profile"
> metaclassReference="_qVRZoKwOEd2sZYFMsQch6A">
> <elementImport xmi:id="_qVRZoKwOEd2sZYFMsQch6A" alias="Class">
> <importedElement xmi:type="uml:Class"
> href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
> </elementImport>
> <packagedElement xmi:type="uml:Stereotype"
> xmi:id="_mvNcwKXKEd2-KYIfOrm7fA" name="PolicyCmptType">
> <generalization xmi:id="_nVypYKwREd2z9Lg5-Fmnrw"
> general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
> </packagedElement>
> <packagedElement xmi:type="uml:Stereotype"
> xmi:id="_-9kMQKXMEd2-KYIfOrm7fA" name="ProductCmptType2">
> <generalization xmi:id="_wkZG8KwREd2z9Lg5-Fmnrw"
> general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
> </packagedElement>
> <packagedElement xmi:type="uml:Stereotype"
> xmi:id="_e6t6gKwREd2z9Lg5-Fmnrw" name="Type" isAbstract="true">
> <ownedAttribute xmi:id="_7pE8YawREd2z9Lg5-Fmnrw" name="base_Class"
> association="_7o4IEKwREd2z9Lg5-Fmnrw">
> <type xmi:type="uml:Class"
> href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
> </ownedAttribute>
> </packagedElement>
> <packagedElement xmi:type="uml:Extension"
> xmi:id="_7o4IEKwREd2z9Lg5-Fmnrw" name="Class_Type"
> memberEnd="_7pE8YKwREd2z9Lg5-Fmnrw _7pE8YawREd2z9Lg5-Fmnrw">
> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_7pE8YKwREd2z9Lg5-Fmnrw"
> name="extension_IpsObject" type="_e6t6gKwREd2z9Lg5-Fmnrw"
> aggregation="composite" association="_7o4IEKwREd2z9Lg5-Fmnrw">
> <lowerValue xmi:type="uml:LiteralInteger"
> xmi:id="_BwxTYKwSEd2z9Lg5-Fmnrw" value="1"/>
> </ownedEnd>
> </packagedElement>
> </uml:Profile>
>
> And here comes an example model for it. I should not be able to assign
> these two stereotypes to myclass but only one of both:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xmi:XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:FaktorIPSProfile="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
> xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
> xsi:schemaLocation="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0
> ./../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml#_ Ztzm0LCdEd2r-NXccNaiJQ ">
> <uml:Model xmi:id="_q8bikK0GEd2GcoPSbdQh2w" name="example">
> <packagedElement xmi:type="uml:Class" xmi:id="_48SHILDAEd24mM2Z0RL5og"
> name="myclass"/>
> <profileApplication xmi:id="_3ZgFwLDAEd24mM2Z0RL5og">
> <eAnnotations xmi:id="_3ZpPsLDAEd24mM2Z0RL5og"
> source="http://www.eclipse.org/uml2/2.0.0/UML">
> <references xmi:type="ecore:EPackage"
> href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _Ztzm0LCdEd2r-NXccNaiJQ "/>
> </eAnnotations>
> <appliedProfile
> href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _itvycKXKEd2-KYIfOrm7fA "/>
> </profileApplication>
> </uml:Model>
> <FaktorIPSProfile:PolicyCmptType xmi:id="_7-YmMLDAEd24mM2Z0RL5og"
> base_Class="_48SHILDAEd24mM2Z0RL5og"/>
> <FaktorIPSProfile:ProductCmptType2 xmi:id="_7-i-QLDAEd24mM2Z0RL5og"
> base_Class="_48SHILDAEd24mM2Z0RL5og"/>
> </xmi:XMI>
>
> Even more critical is, that I have no possibility to unassign any of these
> two stereotypes. So I can add one stereotype and I can't unassign it. This
> is the wanted behaviour. But I can add another stereotype and then I can't
> unassign any of these two.
>
>
>
Re: Question about extending classes with multiple stereotypes [message #477978 is a reply to message #477967] Mon, 17 November 2008 08:57 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Christian,

I agree that the autmatic application of required stereotypes is unnecessary
and inconsistent, at least from a purely structural perspective. Indeed, the
bounds on extension ends would ideally be evaluated only during validation,
and a case where a required stereotype has not been applied, valdation would
fail.

Unfortunately, much of the intended/expected semantics in UML aren't
strictly structural and are specified in a rather informal way;
incidentally, there is a working group at the OMG wrestling with this very
issue. The intended semantics of profile application (as an operation), in
cases where the profile contains required stereotypes, are such that all
required stereotypes are automatically applied. This is evidently
problematic in cases where there is a stereotype hierarchy involved, and
unsurprisingly is something that isn't explicitly addressed by the
specification. In the absence of formal guidance for cases like these, we
are left with best practices (which may eventually make their way into the
specification) as our guide. Based on the way the UML2 implementation works
(for better or worse), the "best practice" is to define extensions only on
non-abstract stereotypes and on leaf stereotypes in a hierarchy; using such
a practice offers the benefits of proeperty inheritence while at the same
time avoiding ambguous semantics.

Based on some of the discussions that have been taking place at the OMG, it
may well be the case that the notion of "profiles", at least in its current
incarnation, will go away (to be replaced by MOF modeling, which is
essentially what profiles, originally introduced as a "lightweight"
extension mechanism, have become in practice).

Kenn

"Christian W. Damus" <cdamus@zeligsoft.com> wrote in message
news:gff2cv$2jf$1@build.eclipse.org...
> Hi, Rafael,
>
> See some comments in-line, below.
>
> cW
>
> Rafael Chaves wrote:
>> Christian, I guess you are saying that the fact that UML2 that allows a a
>> stereotype and a substereotype to be associated with a metaclass instance
>> makes the implementation incorrect.
>>
>> Ok, I can agree with that.
>>
>> But I still think that attempts to instantiate an abstract stereotype as
>> a required extension should fail/be ignored, and that the 'required'
>> aspect of an extension should not inherited. And that is how it currently
>> works.
>
> I think the requiredness seems not to be inherited simply because the API
> doesn't know which concrete Stereotype to instantiate. It can be argued
> that the default creation of stereotype instances for required
> stereotypes, though friendly in simple cases without stereotype
> generalization, is unnecessary and inconsistent.
>
> It's unnecessary because multiplicity lower bounds are simply constraints
> stipulating that a model is invalid if the property (in this case an
> extension end) doesn't have a certain number of values. It doesn't mean
> that a tool should try to create values to satisfy the constraint. :-)
>
> It's inconsistent because the API cannot create the stereotype application
> that a user needs in the case of stereotype generalization.
>
> In general, and in the case of ExtensionEnds, the multiplicity of a
> property is always inherited by specializing classifier context, unless it
> is explicitly replaced by a redefining property.
>
>
>> And that is the root of Alex's problem: even if UML2 prevented
>> stereotype/substereotype from being applied simultaneously to the same
>> instance of a metaclass, his example should still work fine (i.e. not
>> fail), because the base stereotype declaring the required extension is
>> abstract, which is a no-op.
>
> What do you mean by "work fine?" Do you mean, that he should be able to
> apply both of the concrete specializations? That would violate the
> multiplicity of the extension end, which upper bound is 1. 2 is greater
> than 1.
>
> The fact that the extension is required is actually irrelevant to the
> problem as Alex originally stated it. :-) His problem was with the upper
> bound, not the lower.
>
>>
>> Cheers,
>>
>> Rafael
>>
>> Christian W. Damus wrote:
>>> Hi, Rafael,
>>>
>>> I do not agree that the behaviour observed in the MDT UML2
>>> implementation is consistent wth the UML specification or its intention.
>>>
>>> The discussion of the MOF equivalent of a metaclass extension makes it
>>> clear that the semantics of Extensions are consistent with those of
>>> ordinary Associations. Thus, the multiplicities of extension ends have
>>> the same meaning as for association ends: they constrain the number of
>>> links (association instances) that can have some instance of a class (in
>>> this case, a stereotype) in a particular role, linked to the same object
>>> (in this case, a UML element, instance of the extended metaclass) in the
>>> other role.
>>>
>>> So, in any metaclass extension, it actually means that at most one
>>> instance of the stereotype (or any stereotype conforming to it) can be
>>> linked by that extension to the same instance of the extended metaclass.
>>> This is just like any other association. Consider an association like
>>> this:
>>>
>>> Car [1] -------- [4] Wheel
>>>
>>> with MagWheel specializing Wheel. We cannot have a Car with 4 Wheels
>>> and 4 MagWheels. So it is, also, with stereotype generalization and
>>> metaclass extensions.
>>>
>>> It makes sense for an abstract stereotype to have a required extension,
>>> because this simply means that an instance of that stereotype must be
>>> linked to an instance of the extended metaclass. It can be an instance
>>> of any concrete sub-stereotype, but nonetheless only one instance.
>>>
>>> It does appear to me that, in the more general case, the ability to
>>> apply multiple sub-stereotypes of a stereotype to a single element,
>>> where the extension is defined on the super-stereotype, is a bug in
>>> UML2. It's also a special case of a more general problem of not
>>> validating the multiplicities of non-navigable association ends, because
>>> they don't exist in the Ecore representation.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>> Rafael Chaves wrote:
>>>> I was curious about this issue as I had never noticed that feature
>>>> before. I decided to implement support for abstract stereotypes and
>>>> required extensions in the TextUML Toolkit. See:
>>>>
>>>> http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/
>>>>
>>>> But back to the topic - from what I observed when playing with the
>>>> latest TextUML Toolkit implementation (based on UML2 2.2):
>>>>
>>>> 1) a required extension causes the declaring stereotype to be
>>>> implicitly applied to all instances of the extended metaclass on a
>>>> package where the defining profile is applied;
>>>> 2) that effect applies only to the stereotype declaring the extension,
>>>> not to any substereotypes (which makes a lot of sense), which still
>>>> must be applied explicitly;
>>>> 3) as with other kinds of classifiers, abstract stereotypes cannot be
>>>> instantiated (applied), which also makes a lot of sense;
>>>>
>>>> Corollary: making an abstract stereotype declare a required extension
>>>> has no effect whatsoever, and thus is pointless.
>>>>
>>>> Finally, for two stereotypes A and B, where B specializes A, it seems
>>>> to be legal to apply both B and A to a target metaclass instance. So
>>>> even if "3" above was not true, or if you made your base stereotype
>>>> non-abstract, it would be valid to apply the substereotypes. This does
>>>> not seem to be covered by the UML specification.
>>>>
>>>> Granted, much of what is said above is based on observation of the
>>>> behavior of the MDT UML2 implementation, but I think that the observed
>>>> behavior makes a lot of sense, and seems to be well aligned with the
>>>> UML spec.
>>>>
>>>> Also, maybe there should be a constraint in the UML spec that ensured
>>>> that abstract stereotypes did not declare required extensions.
>>>>
>>>> Does this all make sense?
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
>>>>
>>>> James Bruck wrote:
>>>>> Hi Alex,
>>>>>
>>>>> I think you are right when you say: For I guessed multiple stereotypes
>>>>> for metaclasses are only possible if you make an extension for each
>>>>> one?
>>>>> The Element.isStereotypeApplicable(), is implemented that way and I
>>>>> also confirmed this by playing around with the UML editor.
>>>>>
>>>>> You are correct in creating a required stereotype by setting the lower
>>>>> bound of the extension end to 1. Extension::isRequired() checks the
>>>>> lower bound of the first owned end.
>>>>>
>>>>> So I'm not sure why you can succesfully apply the second stereotype as
>>>>> you mention.
>>>>>
>>>>> Can you post a small piece of your profile and model so I can see what
>>>>> exactly is going on.
>>>>>
>>>>> Cheers,
>>>>> - James.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Alex " <eistoeter@gmx.de> wrote in message
>>>>> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>>>>>> Hi
>>>>>>
>>>>>> I made a custom uml profile for our models. At the moment it only
>>>>>> contains three stereotypes. One is abstract and the other two inherit
>>>>>> from this abstract stereotype.
>>>>>>
>>>>>> I then established an extension for uml::Class and linked it with the
>>>>>> abstract stereotype. I also made it be a required extension, so the
>>>>>> multiplicity of the extension end ist 1...1
>>>>>>
>>>>>> Now I assumed this means that any class in my model must ALWAYS HAVE
>>>>>> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>>>>>
>>>>>> But still it is possible to say:
>>>>>>
>>>>>> umlClass.applyStereotype(ConcreteStereotype1);
>>>>>> umlClass.applyStereotype(ConcreteStereotype2);
>>>>>>
>>>>>> Then my umlClass will have both stereotypes assigned. Is this a bug?
>>>>>> For I guessed multiple stereotypes for metaclasses are only possible
>>>>>> if you make an extension for each one?
>>>>>>
>>>>>> Can someone bring light into this?
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>
>>>>>
Re: Question about extending classes with multiple stereotypes [message #477981 is a reply to message #477978] Mon, 17 November 2008 14:14 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Kenn,

Thanks for your response. It is good to know that the OMG is actively
looking at this, but also a little disconcerting to think that such a
user-friendly mechanism as profiles have been might disappear! Yes,
stereotypes are fully equivalent to MOF models, but I'm not sure that
the concept of ProfileApplication has any equivalent in metamodeling.
It's a very definite relationship indicating some reasonably
well-defined notions of domain-specific extension. Of course, if
"profile application" just takes another form, then that's another matter.

On the subject of the best practice for extensions: I understand the
practicality of defining extensions only on leaf stereotypes, but that
does raise problems, too:

- all leaf stereotypes in a hierarchy may end up with redundant
extensions of the same metaclasses
- how do I ask "is any stereotype conforming to Foo applied to my
element" using standard association navigation semantics in OCL?
- I don't necessarily know what is a leaf stereotype. Another
profile may well need to specialize my stereotypes

Perhaps the Classifier-ness of metaclass extensions can help address
some of these issues. Extensions (like other assocations) are
classifiers, and thus can be abstract. Let the super-stereotype in a
hierarchy define an abstract extension that specializing stereotypes can
specialize and redefine its ends, as necessary. They can narrow or
widen the redefined extension end's metaclass type for their own needs,
while letting clients of the more general stereotype still make
practical use of it.

I think we can marry some of these pragmatic best practices with
standard metamodeling practices. ;-)

In the mean-time, I think I shall also continue to mind an old
best-practice that we haven't mentioned, yet: don't make extensions
required! :-D Or, is that not still a best practice?

Cheers,

Christian


Kenn Hussey wrote:
> Christian,
>
> I agree that the autmatic application of required stereotypes is unnecessary
> and inconsistent, at least from a purely structural perspective. Indeed, the
> bounds on extension ends would ideally be evaluated only during validation,
> and a case where a required stereotype has not been applied, valdation would
> fail.
>
> Unfortunately, much of the intended/expected semantics in UML aren't
> strictly structural and are specified in a rather informal way;
> incidentally, there is a working group at the OMG wrestling with this very
> issue. The intended semantics of profile application (as an operation), in
> cases where the profile contains required stereotypes, are such that all
> required stereotypes are automatically applied. This is evidently
> problematic in cases where there is a stereotype hierarchy involved, and
> unsurprisingly is something that isn't explicitly addressed by the
> specification. In the absence of formal guidance for cases like these, we
> are left with best practices (which may eventually make their way into the
> specification) as our guide. Based on the way the UML2 implementation works
> (for better or worse), the "best practice" is to define extensions only on
> non-abstract stereotypes and on leaf stereotypes in a hierarchy; using such
> a practice offers the benefits of proeperty inheritence while at the same
> time avoiding ambguous semantics.
>
> Based on some of the discussions that have been taking place at the OMG, it
> may well be the case that the notion of "profiles", at least in its current
> incarnation, will go away (to be replaced by MOF modeling, which is
> essentially what profiles, originally introduced as a "lightweight"
> extension mechanism, have become in practice).
>
> Kenn
>

-----8<-----
Re: Question about extending classes with multiple stereotypes [message #477989 is a reply to message #477970] Wed, 19 November 2008 15:58 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
My apologies about the delay on this one.

You are right! Once the stereotypes are applied, there is no way to unapply
them. This is an issue. Please raise a defect on that.
In terms of being able to apply the stereotypes, it does seem reasonable to
allow the application of the stereotypes as can be done from the editor.
What is the desired behavior that you would like to see? There seems to be
ambiguity in this area from the position of the spec. but the way the
application works now seems to be ok.

By the way, I had to "define" the profile you provided in the snippet below
and then re-apply. I don't think you were using static profile definition?

Cheers,
- James.


"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:gfk49b$lmt$1@build.eclipse.org...
> ... I haven't forgotten about this ... will look into later today :)
>
>
> "Alex " <eistoeter@gmx.de> wrote in message
> news:a883f38111657994158a234966ee7db7$1@www.eclipse.org...
>> Hi James. Thanks for your interest in this problem.
>>
>> Here comes the profile:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <uml:Profile xmi:version="2.1"
>> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
>> xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
>> xmi:id="_itvycKXKEd2-KYIfOrm7fA" name="Faktor-IPS Profile"
>> metaclassReference="_qVRZoKwOEd2sZYFMsQch6A">
>> <elementImport xmi:id="_qVRZoKwOEd2sZYFMsQch6A" alias="Class">
>> <importedElement xmi:type="uml:Class"
>> href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
>> </elementImport>
>> <packagedElement xmi:type="uml:Stereotype"
>> xmi:id="_mvNcwKXKEd2-KYIfOrm7fA" name="PolicyCmptType">
>> <generalization xmi:id="_nVypYKwREd2z9Lg5-Fmnrw"
>> general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
>> </packagedElement>
>> <packagedElement xmi:type="uml:Stereotype"
>> xmi:id="_-9kMQKXMEd2-KYIfOrm7fA" name="ProductCmptType2">
>> <generalization xmi:id="_wkZG8KwREd2z9Lg5-Fmnrw"
>> general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
>> </packagedElement>
>> <packagedElement xmi:type="uml:Stereotype"
>> xmi:id="_e6t6gKwREd2z9Lg5-Fmnrw" name="Type" isAbstract="true">
>> <ownedAttribute xmi:id="_7pE8YawREd2z9Lg5-Fmnrw" name="base_Class"
>> association="_7o4IEKwREd2z9Lg5-Fmnrw">
>> <type xmi:type="uml:Class"
>> href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
>> </ownedAttribute>
>> </packagedElement>
>> <packagedElement xmi:type="uml:Extension"
>> xmi:id="_7o4IEKwREd2z9Lg5-Fmnrw" name="Class_Type"
>> memberEnd="_7pE8YKwREd2z9Lg5-Fmnrw _7pE8YawREd2z9Lg5-Fmnrw">
>> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_7pE8YKwREd2z9Lg5-Fmnrw"
>> name="extension_IpsObject" type="_e6t6gKwREd2z9Lg5-Fmnrw"
>> aggregation="composite" association="_7o4IEKwREd2z9Lg5-Fmnrw">
>> <lowerValue xmi:type="uml:LiteralInteger"
>> xmi:id="_BwxTYKwSEd2z9Lg5-Fmnrw" value="1"/>
>> </ownedEnd>
>> </packagedElement>
>> </uml:Profile>
>>
>> And here comes an example model for it. I should not be able to assign
>> these two stereotypes to myclass but only one of both:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <xmi:XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:FaktorIPSProfile="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
>> xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
>> xsi:schemaLocation="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0
>> ./../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml#_ Ztzm0LCdEd2r-NXccNaiJQ ">
>> <uml:Model xmi:id="_q8bikK0GEd2GcoPSbdQh2w" name="example">
>> <packagedElement xmi:type="uml:Class" xmi:id="_48SHILDAEd24mM2Z0RL5og"
>> name="myclass"/>
>> <profileApplication xmi:id="_3ZgFwLDAEd24mM2Z0RL5og">
>> <eAnnotations xmi:id="_3ZpPsLDAEd24mM2Z0RL5og"
>> source="http://www.eclipse.org/uml2/2.0.0/UML">
>> <references xmi:type="ecore:EPackage"
>> href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _Ztzm0LCdEd2r-NXccNaiJQ "/>
>> </eAnnotations>
>> <appliedProfile
>> href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _itvycKXKEd2-KYIfOrm7fA "/>
>> </profileApplication>
>> </uml:Model>
>> <FaktorIPSProfile:PolicyCmptType xmi:id="_7-YmMLDAEd24mM2Z0RL5og"
>> base_Class="_48SHILDAEd24mM2Z0RL5og"/>
>> <FaktorIPSProfile:ProductCmptType2 xmi:id="_7-i-QLDAEd24mM2Z0RL5og"
>> base_Class="_48SHILDAEd24mM2Z0RL5og"/>
>> </xmi:XMI>
>>
>> Even more critical is, that I have no possibility to unassign any of
>> these two stereotypes. So I can add one stereotype and I can't unassign
>> it. This is the wanted behaviour. But I can add another stereotype and
>> then I can't unassign any of these two.
>>
>>
>>
>
>
Re: Question about extending classes with multiple stereotypes [message #477994 is a reply to message #477981] Thu, 20 November 2008 09:32 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Christian,

I didn't mean to say that profiles will go away, but that the way they are
currently defined by the specification may change (there will always be a
need to specialize UML for specific domains).

Yes, the notion of required stereotypes has always been problematic, so
we've always cautioned clients against using them (if possible).

Kenn

"Christian W. Damus" <cdamus@zeligsoft.com> wrote in message
news:gfru82$3u9$1@build.eclipse.org...
> Hi, Kenn,
>
> Thanks for your response. It is good to know that the OMG is actively
> looking at this, but also a little disconcerting to think that such a
> user-friendly mechanism as profiles have been might disappear! Yes,
> stereotypes are fully equivalent to MOF models, but I'm not sure that the
> concept of ProfileApplication has any equivalent in metamodeling. It's a
> very definite relationship indicating some reasonably well-defined notions
> of domain-specific extension. Of course, if "profile application" just
> takes another form, then that's another matter.
>
> On the subject of the best practice for extensions: I understand the
> practicality of defining extensions only on leaf stereotypes, but that
> does raise problems, too:
>
> - all leaf stereotypes in a hierarchy may end up with redundant
> extensions of the same metaclasses
> - how do I ask "is any stereotype conforming to Foo applied to my
> element" using standard association navigation semantics in OCL?
> - I don't necessarily know what is a leaf stereotype. Another
> profile may well need to specialize my stereotypes
>
> Perhaps the Classifier-ness of metaclass extensions can help address some
> of these issues. Extensions (like other assocations) are classifiers, and
> thus can be abstract. Let the super-stereotype in a hierarchy define an
> abstract extension that specializing stereotypes can specialize and
> redefine its ends, as necessary. They can narrow or widen the redefined
> extension end's metaclass type for their own needs, while letting clients
> of the more general stereotype still make practical use of it.
>
> I think we can marry some of these pragmatic best practices with standard
> metamodeling practices. ;-)
>
> In the mean-time, I think I shall also continue to mind an old
> best-practice that we haven't mentioned, yet: don't make extensions
> required! :-D Or, is that not still a best practice?
>
> Cheers,
>
> Christian
>
>
> Kenn Hussey wrote:
>> Christian,
>>
>> I agree that the autmatic application of required stereotypes is
>> unnecessary and inconsistent, at least from a purely structural
>> perspective. Indeed, the bounds on extension ends would ideally be
>> evaluated only during validation, and a case where a required stereotype
>> has not been applied, valdation would fail.
>>
>> Unfortunately, much of the intended/expected semantics in UML aren't
>> strictly structural and are specified in a rather informal way;
>> incidentally, there is a working group at the OMG wrestling with this
>> very issue. The intended semantics of profile application (as an
>> operation), in cases where the profile contains required stereotypes, are
>> such that all required stereotypes are automatically applied. This is
>> evidently problematic in cases where there is a stereotype hierarchy
>> involved, and unsurprisingly is something that isn't explicitly addressed
>> by the specification. In the absence of formal guidance for cases like
>> these, we are left with best practices (which may eventually make their
>> way into the specification) as our guide. Based on the way the UML2
>> implementation works (for better or worse), the "best practice" is to
>> define extensions only on non-abstract stereotypes and on leaf
>> stereotypes in a hierarchy; using such a practice offers the benefits of
>> proeperty inheritence while at the same time avoiding ambguous semantics.
>>
>> Based on some of the discussions that have been taking place at the OMG,
>> it may well be the case that the notion of "profiles", at least in its
>> current incarnation, will go away (to be replaced by MOF modeling, which
>> is essentially what profiles, originally introduced as a "lightweight"
>> extension mechanism, have become in practice).
>>
>> Kenn
>>
>
> -----8<-----
Re: Question about extending classes with multiple stereotypes [message #477995 is a reply to message #477994] Fri, 21 November 2008 10:43 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Kenn,

We hope that stereotype mechanism will not be changed because this could
be a problem for our existing users.
Imagine if you develop a military, finance or other projects. The
development and use of the project could be over 10 years. If you
permanently change the EclipseUML2 plugin model this model duration is a
lot reduced. One of the goal of UML modeling is to be independent of short
term technologies.
For example to allow using Eclipse 3.2 for modeling and reuse the same
model by just importing it inside the next Eclipse 4.0 or Eclipse 5.0 in 5
years :-)
A real example today is the use a RSA 7 model develop with Eclipse 3.2 and
just import it inside Eclipse 3.4 (see my demo at:
http://www.forum-omondo.com/documentation_eclipseuml_2008/ec lipseuml2008_dynamic_navigation.html#5._Model_interchange_wi ht_RSA_7
)
This is really cool and show that modeling is important to protect long
term companies development investments.
We hope that the OMG or others UML2 plugins will not forget that projects
are already using these stereotype technologies and that a new change
could break the upgrade compatibility.

Let's now talk about my personal dream :-)
If you look at Java then you can always compile your java 1.4 projects
inside Java 1.6. It is always compatible.
Inside Eclipse 3.4 how many fantastic plugins are not anymore compatible.
We lost so many nice plugins because of permanent EMF/GEF etc.. and
Eclipse core upgrades.
The UML2 project has been the only one to always remain stable and keep
backward compatibility in the last few years. This is why EclipseUML2
plugin is today the world model standard.
Please don't break this compatibility !!

Vlad
Omondo
Re: Question about extending classes with multiple stereotypes [message #477996 is a reply to message #477995] Fri, 21 November 2008 14:42 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Vlad,

In terms of profiles and stereotypes, I wanted to put your mind at ease
(hopefully). I was speaking with Bran Selic (former OMG chair of UML)
about the possibility of profiles "going away" (or changing) and this is
what he replied:

-------------------
I would not put too much stock in such discussions, since there is far too
much vested into profiles at the moment. I doubt that anyone has the
resources to redo the dozen or so OMG adopted profiles or the hundreds of
user-defined ones. Even Microsoft now view UML as a family of languages,
that is, as a foundation for constructing more specific languages. Profiles
are the current mechanism by which one produces those more specific
languages.

.......

The more likely scenario is a redesigned profile mechanism based on a
somewhat refactored UML.

The MOF variant is available now, so there is nothing new there.

------------------------------

I've been following the uml-roadmap mailing list at the OMG and it would
seem that there is a lot on the table in terms of possible changes for UML
but such changes would take a while (years probably) to make their way into
a specification, if we can predict future pace based on the pace of change
in the past.

I believe Kenn's comments are accurate (as always ;) )

Cheers,

- James.

p.s. thanks for the kind words about the UML2 project. I know that Kenn has
invested a lot of sweat in making the UML2 project what it is today.



"Vlad Varnica" <varnica@omondo.com> wrote in message
news:31cc9e8f2c7ea5d14c99636cd478aabd$1@www.eclipse.org...
> Kenn,
>
> We hope that stereotype mechanism will not be changed because this could
> be a problem for our existing users. Imagine if you develop a military,
> finance or other projects. The development and use of the project could be
> over 10 years. If you permanently change the EclipseUML2 plugin model this
> model duration is a lot reduced. One of the goal of UML modeling is to be
> independent of short term technologies. For example to allow using Eclipse
> 3.2 for modeling and reuse the same model by just importing it inside the
> next Eclipse 4.0 or Eclipse 5.0 in 5 years :-)
> A real example today is the use a RSA 7 model develop with Eclipse 3.2 and
> just import it inside Eclipse 3.4 (see my demo at:
> http://www.forum-omondo.com/documentation_eclipseuml_2008/ec lipseuml2008_dynamic_navigation.html#5._Model_interchange_wi ht_RSA_7 )
> This is really cool and show that modeling is important to protect long
> term companies development investments.
> We hope that the OMG or others UML2 plugins will not forget that projects
> are already using these stereotype technologies and that a new change
> could break the upgrade compatibility.
> Let's now talk about my personal dream :-)
> If you look at Java then you can always compile your java 1.4 projects
> inside Java 1.6. It is always compatible. Inside Eclipse 3.4 how many
> fantastic plugins are not anymore compatible. We lost so many nice plugins
> because of permanent EMF/GEF etc.. and Eclipse core upgrades.
> The UML2 project has been the only one to always remain stable and keep
> backward compatibility in the last few years. This is why EclipseUML2
> plugin is today the world model standard.
> Please don't break this compatibility !!
>
> Vlad Omondo
>
Re: Question about extending classes with multiple stereotypes [message #627170 is a reply to message #477952] Tue, 11 November 2008 15:21 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Alex,

I think you are right when you say: For I guessed multiple stereotypes for
metaclasses are only possible if you make an extension for each one?
The Element.isStereotypeApplicable(), is implemented that way and I also
confirmed this by playing around with the UML editor.

You are correct in creating a required stereotype by setting the lower bound
of the extension end to 1. Extension::isRequired() checks the lower bound
of the first owned end.

So I'm not sure why you can succesfully apply the second stereotype as you
mention.

Can you post a small piece of your profile and model so I can see what
exactly is going on.

Cheers,
- James.




"Alex " <eistoeter@gmx.de> wrote in message
news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
> Hi
>
> I made a custom uml profile for our models. At the moment it only contains
> three stereotypes. One is abstract and the other two inherit from this
> abstract stereotype.
>
> I then established an extension for uml::Class and linked it with the
> abstract stereotype. I also made it be a required extension, so the
> multiplicity of the extension end ist 1...1
>
> Now I assumed this means that any class in my model must ALWAYS HAVE
> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>
> But still it is possible to say:
>
> umlClass.applyStereotype(ConcreteStereotype1);
> umlClass.applyStereotype(ConcreteStereotype2);
>
> Then my umlClass will have both stereotypes assigned. Is this a bug? For I
> guessed multiple stereotypes for metaclasses are only possible if you make
> an extension for each one?
>
> Can someone bring light into this?
>
> Best regards
>
Re: Question about extending classes with multiple stereotypes [message #627171 is a reply to message #477958] Wed, 12 November 2008 06:53 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
I was curious about this issue as I had never noticed that feature
before. I decided to implement support for abstract stereotypes and
required extensions in the TextUML Toolkit. See:

http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/

But back to the topic - from what I observed when playing with the
latest TextUML Toolkit implementation (based on UML2 2.2):

1) a required extension causes the declaring stereotype to be implicitly
applied to all instances of the extended metaclass on a package where
the defining profile is applied;
2) that effect applies only to the stereotype declaring the extension,
not to any substereotypes (which makes a lot of sense), which still must
be applied explicitly;
3) as with other kinds of classifiers, abstract stereotypes cannot be
instantiated (applied), which also makes a lot of sense;

Corollary: making an abstract stereotype declare a required extension
has no effect whatsoever, and thus is pointless.

Finally, for two stereotypes A and B, where B specializes A, it seems to
be legal to apply both B and A to a target metaclass instance. So even
if "3" above was not true, or if you made your base stereotype
non-abstract, it would be valid to apply the substereotypes. This does
not seem to be covered by the UML specification.

Granted, much of what is said above is based on observation of the
behavior of the MDT UML2 implementation, but I think that the observed
behavior makes a lot of sense, and seems to be well aligned with the UML
spec.

Also, maybe there should be a constraint in the UML spec that ensured
that abstract stereotypes did not declare required extensions.

Does this all make sense?

Cheers,

Rafael

James Bruck wrote:
> Hi Alex,
>
> I think you are right when you say: For I guessed multiple stereotypes for
> metaclasses are only possible if you make an extension for each one?
> The Element.isStereotypeApplicable(), is implemented that way and I also
> confirmed this by playing around with the UML editor.
>
> You are correct in creating a required stereotype by setting the lower bound
> of the extension end to 1. Extension::isRequired() checks the lower bound
> of the first owned end.
>
> So I'm not sure why you can succesfully apply the second stereotype as you
> mention.
>
> Can you post a small piece of your profile and model so I can see what
> exactly is going on.
>
> Cheers,
> - James.
>
>
>
>
> "Alex " <eistoeter@gmx.de> wrote in message
> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>> Hi
>>
>> I made a custom uml profile for our models. At the moment it only contains
>> three stereotypes. One is abstract and the other two inherit from this
>> abstract stereotype.
>>
>> I then established an extension for uml::Class and linked it with the
>> abstract stereotype. I also made it be a required extension, so the
>> multiplicity of the extension end ist 1...1
>>
>> Now I assumed this means that any class in my model must ALWAYS HAVE
>> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>
>> But still it is possible to say:
>>
>> umlClass.applyStereotype(ConcreteStereotype1);
>> umlClass.applyStereotype(ConcreteStereotype2);
>>
>> Then my umlClass will have both stereotypes assigned. Is this a bug? For I
>> guessed multiple stereotypes for metaclasses are only possible if you make
>> an extension for each one?
>>
>> Can someone bring light into this?
>>
>> Best regards
>>
>
>
Re: Question about extending classes with multiple stereotypes [message #627172 is a reply to message #477959] Wed, 12 November 2008 07:02 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Btw, I am attaching here the TextUML project I mentioned in my previous
post (requires r161 from
https://textuml.svn.sourceforge.net/svnroot/textuml/).

This is the TextUML source:


>>> prof.tuml:
profile prof;

abstract stereotype AbstractBasic extends uml::Class required
end;

stereotype ConcreteSub1 specializes AbstractBasic
end;

stereotype ConcreteSub2 specializes AbstractBasic
end;

stereotype ConcreteBasic extends uml::Class required
end;

end.

>>> pack1.tuml:
package pack1;

apply prof;

[ConcreteSub2]
class MyClass
end;

end.


Note that the resulting pack1.uml package will have both ConcreteSub1
and ConcreteBasic stereotypes applied to MyClass (the first, explicitly,
the second implicitly).

Cheers,

Rafael
Re: Question about extending classes with multiple stereotypes [message #627173 is a reply to message #477960] Wed, 12 November 2008 07:05 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060801050404000409000503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rafael Chaves wrote:
> Btw, I am attaching here...

Er... now, for real.

--------------060801050404000409000503
Content-Type: application/x-zip-compressed;
name="required-extension.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="required-extension.zip"

UEsDBBQACAAIAJq4azkAAAAAAAAAAAAAAAAcAAAAcmVxdWlyZWQtZXh0ZW5z aW9ucy8ucHJv
amVjdG2QQQ7CIBBF15p4B9O9oDsXWBcaL6AegMLEYITWYTAeX6DUpsYd/8+f /wCxf9vH8gXo
Tet21YatqyU41WrjbrvqejmtttW+XsxFh+0dFB3BKzQdxXR0Z8JJCzXCMxgE vYI3gUtNXvA8
SRHVWguOasGHU3JLn8+CT1QTzEOfO1BJFXmIq9Lp7BRqbGOy8YSSiFmtWTAs ZwFHegxLvIWE
9UXzqSH4L6A4ww0ijQJCSffiL7wfJXaO5KZx9/vI6Rd+AFBLBwi/fVhDwAAA AIEBAABQSwME
FAAIAAgAmrhrOQAAAAAAAAAAAAAAABoAAAByZXF1aXJlZC1leHRlbnNpb25z L015LnVtbK2U
3W6bQBCF7yv1HVbba7NAq6pCppHtEqUJpEkdq01u0GYZ41VgQSwJ+O2z/Bho MG1T9crWcM7H
zJmx5ydlHKEnyCRPhI0NTccIBEsCLkIbb25OZ5/wyee3b+ZlzK2f3ldUfXZy UzOwqkRCWqpu
412epxYhku0gploSh1qShUSmwIjykqFc9vKiKLTifS01dd1QUnddE2ZcyJwK BgcXsCSDX3zA
Ip5KqM0QbyuASZxKdvCkWbLtLG1rklRV4gdBbCzcpe8E5tn+47r8cMcuTwui D72+MeW+WJ6X
zF0tp9yPcTTZq3pmVnloOtl4rnJIbjV0N2E0r9N9Xc+oeqwp7jslEcy5fylB r5tiwKsl2UsJ
VmeB0FwprCvKHmgI9XHwwMb+2YX+xEZNYiRorPbn7RuvcqeNM3AiiEHkNSHf p0pUcVcRlRL3
WNe54b/DNnrSwdUEPIJFmka8CbVHfbud5ZvR2Ie+lBkWQiR57ZJDm7+5HduQ TB4zNn2a7br1
dt3dW9R7MthCpn5yIAfD14duOW2uGO2UysZ/3Ajp2yfD/vsyrbKA4KpJZsxd XP64Ho/XJUrG
kTZXQAZn0FQqpbVKBMsgB6NPkF/L8/DIDu+pBL9e4PSiSY/2DWtJJWc9eO0Z d+ND/hfwka7X
nike/ivc7OH0y/fySOp/DZ+T9t9ZfX8GUEsHCD61MF8AAgAA0QUAAFBLAwQU AAgACACauGs5
AAAAAAAAAAAAAAAAHgAAAHJlcXVpcmVkLWV4dGVuc2lvbnMvcGFjazEudHVt bCtITM5OTE9V
KADShta8XLxciQUFOZUKBUX5aWButHN+XnJRaklqcGmSUawCL1dyTmJxsYJv pTOI5uVKzUsB
qlMAM/QAUEsHCAq7EDZEAAAATgAAAFBLAwQUAAgACACauGs5AAAAAAAAAAAA AAAAHQAAAHJl
cXVpcmVkLWV4dGVuc2lvbnMvcGFjazEudW1spVTRjtMwEHxH4h8i83xxGhCH opbTUfW4Si0C
9YqAl8pxtqlFbEe207R/zyZpm1zangQ8JXJmZsezuxne7WTmbcFYodWIDPyA eKC4ToRKR2T5
9HDzgdx9fP1quJMi+jGfetXzBA/9AcGTTNkIz0dk41weUWr5BiTztUx9bVJq c+AUubQLty28
LEu/fFtDwyAYIHS2qBVuhLKOKQ5HFnBt4BkPeCZyCzUZ5LoSCOmkgh05udHr E+VgzdLqlK5u
IU6ns/HnSRI+7t8vdu9+8S8PJQ2O3EJmV6vht7C6kR/Q5XyGDCuiRn2mOXN1 Pn9X1as++6j7
BiH8cR73IQQb4XlDRERfGf/NUqjbIZIRWd0mruBnosRTTGJiOcIHDR0F4F4p 7WqPtqdwXtOz
ujAcNbiWPoutM8w5KpOEEnoUzBs3U5lr4zqKkHxfXlDcCitikQm3R2dGbJmD ozcUE7UKJN0r
un2ODuqLY0Yiw+5uDKwrehvZ5Kk8D+DkkT4z2XOeTDKQoFyv2Dhj1pJeROZa yPN9g29jabze
53kmmpHoZsOLb+d22xiuNKmivdCkl4c1OAzrqQrWwRjB4MqD7Vy+XrRocmjB pbAvzidt7dOu
//aYVVlgb5tk/qGJZ5E2O0E7S9GcVMhorBU34OATs4L3BvPCssTMwqpu4vVm 0wvyiyIOu+rp
T/0f6kN6+Nni+x9QSwcIIM/atAwCAACgBQAAUEsDBBQACAAIAJq4azkAAAAA AAAAAAAAAAAd
AAAAcmVxdWlyZWQtZXh0ZW5zaW9ucy9wcm9mLnR1bWydjkEKAjEQBO+B/GFe IOhxPek+wRfM
ZlsYiJs4MwHd1xvEg3gRPTV0U0VXLWfJoNpzH0MMPJkrJydzKIrfK+jw6o5s kgg3xzIbtUse
hjGzGSmuTRRzDH15at7osSxJ4Ti1aUtWkYSzrLAP7Td29y/7w+uemwdQSwcI bXnaMHUAAAAS
AQAAUEsDBBQACAAIAJq4azkAAAAAAAAAAAAAAAAcAAAAcmVxdWlyZWQtZXh0 ZW5zaW9ucy9w
cm9mLnVtbN1Y227aQBB9r9R/sJzneglqkwhBI5I6DRIQK5Cm6gta7MGxYnut 3SWQfn1njQ2+
EkKI1PYF5MvMnDlnLgvt82Xga0/AhcfCjn5sNHQNQps5Xuh29Lvx1acz/fzr xw/teeC3LM5m
ng/aMvBaa5OmcazjHT8ULbzf0R+kjFqECPsBAmqwwDUYd4mIwCY/Bz2SeR1s xmFtsFgsDLB9
LxIQW0AwI81Go0lM9VpqgzBqLfBZU/k3GuRu0NdjmJ7T0SenYI4X/cvvptO8 fj4ZLT//sodX
C10LaYDxI8xK1wKQNGAO+LcwA44UQGzYZ27ZEPnQtDZ0w5BJKpEFUYg1LccS bM6VT5sFBp0K
yamUJHAcopPt7uzrQQX01N12KhoJFXEEjGGzUEIoV/7lc4QOYhFapkXtR+qC XohckUiWtFDc
3fbWIBLNBVEPCTqYur0SdNJQZhaHmbdM3CToFAeXPhXCm3lYXGWM8cMiQl6H sBuTbMsLKjxb
12hy2dEln8Mm5nbmT9/KvMbTchJpcZQRkxyaEQK05ZxT/woofkMFFesiLdAx rK3yKRUwSRhk
3EFrtJlRX6ALny2AX7B5iLeOs9QoOGOMW6vFA6a3Yz8eEbIyymVLKtLd1APJ FsRbymRYWyaX
LLQ5SBjNpziY8CsCrlIW9QW2W+0MD187J42yvOQd2LqpbfsMW82DsnVTIdCb 2Sqn8R5sWbU9
l7K1GkG7EWFt2R17E/GeI8eqba3/ZuS0Sbo4V6uaZOVb3YpW+7MXRIzLLEH1 Bwi08uLXwUm2
byZnddwaqONImnBE5UNAVc6Y2GRgjruDm29mf6QujfXhxUC7o0kjPVOQHKwc Usf0IcCUCjFH
EmVi6rp4ftp10XqiW7lq22wRgtOVknvTuYSs94H1uFMR4QezvZj2lNtyt2yk lPkyUunlaugV
lObLqE3yueTJTpl9C91Vk75qYaWAXAgBy9n7HZOTdWV9Oatwlbz/0pHkwDnt tlZezmn8ePfX
5PTiwSI3/Lc0wX3I9mqC++5j7YD5N5rAXOJsVT8m9cLgrK8XhWRSGDwBBFPg ZrieKSVatLpZ
k1MHPdQBxEd6YXDV9imkRkWcK7+1Q5W6Lgc30Rd/LUZMeBJePfziBfuD+vOi +n30hm3Sw4Xm
Ai+mU0H5k3KitnRBeSTj0JpX1nJO83xXFTTHFqrUvLK19tW8KkhZ8wLOjeaV E2NXzV/o9X00
x3QOpHmbZP4jwus/UEsHCKP27kGbAwAAWxIAAFBLAQIUABQACAAIAJq4azm/ fVhDwAAAAIEB
AAAcAAAAAAAAAAAAAAAAAAAAAAByZXF1aXJlZC1leHRlbnNpb25zLy5wcm9q ZWN0UEsBAhQA
FAAIAAgAmrhrOT61MF8AAgAA0QUAABoAAAAAAAAAAAAAAAAACgEAAHJlcXVp cmVkLWV4dGVu
c2lvbnMvTXkudW1sUEsBAhQAFAAIAAgAmrhrOQq7EDZEAAAATgAAAB4AAAAA AAAAAAAAAAAA
UgMAAHJlcXVpcmVkLWV4dGVuc2lvbnMvcGFjazEudHVtbFBLAQIUABQACAAI AJq4azkgz9q0
DAIAAKAFAAAdAAAAAAAAAAAAAAAAAOIDAAByZXF1aXJlZC1leHRlbnNpb25z L3BhY2sxLnVt
bFBLAQIUABQACAAIAJq4azltedowdQAAABIBAAAdAAAAAAAAAAAAAAAAADkG AAByZXF1aXJl
ZC1leHRlbnNpb25zL3Byb2YudHVtbFBLAQIUABQACAAIAJq4azmj9u5BmwMA AFsSAAAcAAAA
AAAAAAAAAAAAAPkGAAByZXF1aXJlZC1leHRlbnNpb25zL3Byb2YudW1sUEsF BgAAAAAGAAYA
vgEAAN4KAAAAAA==
--------------060801050404000409000503--
Re: Question about extending classes with multiple stereotypes [message #627174 is a reply to message #477959] Wed, 12 November 2008 12:51 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Rafael,

I do not agree that the behaviour observed in the MDT UML2
implementation is consistent wth the UML specification or its intention.

The discussion of the MOF equivalent of a metaclass extension makes it
clear that the semantics of Extensions are consistent with those of
ordinary Associations. Thus, the multiplicities of extension ends have
the same meaning as for association ends: they constrain the number of
links (association instances) that can have some instance of a class (in
this case, a stereotype) in a particular role, linked to the same object
(in this case, a UML element, instance of the extended metaclass) in the
other role.

So, in any metaclass extension, it actually means that at most one
instance of the stereotype (or any stereotype conforming to it) can be
linked by that extension to the same instance of the extended metaclass.
This is just like any other association. Consider an association like
this:

Car [1] -------- [4] Wheel

with MagWheel specializing Wheel. We cannot have a Car with 4 Wheels
and 4 MagWheels. So it is, also, with stereotype generalization and
metaclass extensions.

It makes sense for an abstract stereotype to have a required extension,
because this simply means that an instance of that stereotype must be
linked to an instance of the extended metaclass. It can be an instance
of any concrete sub-stereotype, but nonetheless only one instance.

It does appear to me that, in the more general case, the ability to
apply multiple sub-stereotypes of a stereotype to a single element,
where the extension is defined on the super-stereotype, is a bug in
UML2. It's also a special case of a more general problem of not
validating the multiplicities of non-navigable association ends, because
they don't exist in the Ecore representation.

Cheers,

Christian

Rafael Chaves wrote:
> I was curious about this issue as I had never noticed that feature
> before. I decided to implement support for abstract stereotypes and
> required extensions in the TextUML Toolkit. See:
>
> http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/
>
>
> But back to the topic - from what I observed when playing with the
> latest TextUML Toolkit implementation (based on UML2 2.2):
>
> 1) a required extension causes the declaring stereotype to be implicitly
> applied to all instances of the extended metaclass on a package where
> the defining profile is applied;
> 2) that effect applies only to the stereotype declaring the extension,
> not to any substereotypes (which makes a lot of sense), which still must
> be applied explicitly;
> 3) as with other kinds of classifiers, abstract stereotypes cannot be
> instantiated (applied), which also makes a lot of sense;
>
> Corollary: making an abstract stereotype declare a required extension
> has no effect whatsoever, and thus is pointless.
>
> Finally, for two stereotypes A and B, where B specializes A, it seems to
> be legal to apply both B and A to a target metaclass instance. So even
> if "3" above was not true, or if you made your base stereotype
> non-abstract, it would be valid to apply the substereotypes. This does
> not seem to be covered by the UML specification.
>
> Granted, much of what is said above is based on observation of the
> behavior of the MDT UML2 implementation, but I think that the observed
> behavior makes a lot of sense, and seems to be well aligned with the UML
> spec.
>
> Also, maybe there should be a constraint in the UML spec that ensured
> that abstract stereotypes did not declare required extensions.
>
> Does this all make sense?
>
> Cheers,
>
> Rafael
>
> James Bruck wrote:
>> Hi Alex,
>>
>> I think you are right when you say: For I guessed multiple stereotypes
>> for metaclasses are only possible if you make an extension for each one?
>> The Element.isStereotypeApplicable(), is implemented that way and I
>> also confirmed this by playing around with the UML editor.
>>
>> You are correct in creating a required stereotype by setting the lower
>> bound of the extension end to 1. Extension::isRequired() checks the
>> lower bound of the first owned end.
>>
>> So I'm not sure why you can succesfully apply the second stereotype as
>> you mention.
>>
>> Can you post a small piece of your profile and model so I can see what
>> exactly is going on.
>>
>> Cheers,
>> - James.
>>
>>
>>
>>
>> "Alex " <eistoeter@gmx.de> wrote in message
>> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>>> Hi
>>>
>>> I made a custom uml profile for our models. At the moment it only
>>> contains three stereotypes. One is abstract and the other two inherit
>>> from this abstract stereotype.
>>>
>>> I then established an extension for uml::Class and linked it with the
>>> abstract stereotype. I also made it be a required extension, so the
>>> multiplicity of the extension end ist 1...1
>>>
>>> Now I assumed this means that any class in my model must ALWAYS HAVE
>>> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>>
>>> But still it is possible to say:
>>>
>>> umlClass.applyStereotype(ConcreteStereotype1);
>>> umlClass.applyStereotype(ConcreteStereotype2);
>>>
>>> Then my umlClass will have both stereotypes assigned. Is this a bug?
>>> For I guessed multiple stereotypes for metaclasses are only possible
>>> if you make an extension for each one?
>>>
>>> Can someone bring light into this?
>>>
>>> Best regards
>>>
>>
>>
Re: Question about extending classes with multiple stereotypes [message #627175 is a reply to message #477962] Wed, 12 November 2008 13:00 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

I suppose a simpler way to look at the problem is to imagine what would
happen if the ExtensionEnd were actually owned by the extended
metaclass, instead of the Extension.

Then, it would be clear that:

- defining the Extension on an abstract Stereotype makes sense,
because we use properties of abstract type all the time
- an element of that metaclass can have at most one instance of
the stereotype or any of its specializations

Cheers,

Christian


Christian W. Damus wrote:
> Hi, Rafael,
>
> I do not agree that the behaviour observed in the MDT UML2
> implementation is consistent wth the UML specification or its intention.

-----8<-----
Re: Question about extending classes with multiple stereotypes [message #627176 is a reply to message #477962] Wed, 12 November 2008 13:41 Go to previous message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
Hi Christian,

thanks for your answer. I totally agree with your explanation. I also
understood it that way from the uml superstructure that's why I modeled it
so and was confused why I was able to assign multiple concrete stereotypes
from the stereotype hierarchy.
Re: Question about extending classes with multiple stereotypes [message #627177 is a reply to message #477958] Wed, 12 November 2008 13:54 Go to previous message
Alexander Weickmann is currently offline Alexander WeickmannFriend
Messages: 33
Registered: July 2009
Member
Hi James. Thanks for your interest in this problem.

Here comes the profile:

<?xml version="1.0" encoding="UTF-8"?>
<uml:Profile xmi:version="2.1"
xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
xmi:id="_itvycKXKEd2-KYIfOrm7fA" name="Faktor-IPS Profile"
metaclassReference="_qVRZoKwOEd2sZYFMsQch6A">
<elementImport xmi:id="_qVRZoKwOEd2sZYFMsQch6A" alias="Class">
<importedElement xmi:type="uml:Class"
href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
</elementImport>
<packagedElement xmi:type="uml:Stereotype"
xmi:id="_mvNcwKXKEd2-KYIfOrm7fA" name="PolicyCmptType">
<generalization xmi:id="_nVypYKwREd2z9Lg5-Fmnrw"
general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype"
xmi:id="_-9kMQKXMEd2-KYIfOrm7fA" name="ProductCmptType2">
<generalization xmi:id="_wkZG8KwREd2z9Lg5-Fmnrw"
general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
</packagedElement>
<packagedElement xmi:type="uml:Stereotype"
xmi:id="_e6t6gKwREd2z9Lg5-Fmnrw" name="Type" isAbstract="true">
<ownedAttribute xmi:id="_7pE8YawREd2z9Lg5-Fmnrw" name="base_Class"
association="_7o4IEKwREd2z9Lg5-Fmnrw">
<type xmi:type="uml:Class"
href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Extension"
xmi:id="_7o4IEKwREd2z9Lg5-Fmnrw" name="Class_Type"
memberEnd="_7pE8YKwREd2z9Lg5-Fmnrw _7pE8YawREd2z9Lg5-Fmnrw">
<ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_7pE8YKwREd2z9Lg5-Fmnrw"
name="extension_IpsObject" type="_e6t6gKwREd2z9Lg5-Fmnrw"
aggregation="composite" association="_7o4IEKwREd2z9Lg5-Fmnrw">
<lowerValue xmi:type="uml:LiteralInteger"
xmi:id="_BwxTYKwSEd2z9Lg5-Fmnrw" value="1"/>
</ownedEnd>
</packagedElement>
</uml:Profile>

And here comes an example model for it. I should not be able to assign
these two stereotypes to myclass but only one of both:

<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:FaktorIPSProfile="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
xsi:schemaLocation="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0
../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _Ztzm0LCdEd2r-NXccNaiJQ ">
<uml:Model xmi:id="_q8bikK0GEd2GcoPSbdQh2w" name="example">
<packagedElement xmi:type="uml:Class" xmi:id="_48SHILDAEd24mM2Z0RL5og"
name="myclass"/>
<profileApplication xmi:id="_3ZgFwLDAEd24mM2Z0RL5og">
<eAnnotations xmi:id="_3ZpPsLDAEd24mM2Z0RL5og"
source="http://www.eclipse.org/uml2/2.0.0/UML">
<references xmi:type="ecore:EPackage"
href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _Ztzm0LCdEd2r-NXccNaiJQ "/>
</eAnnotations>
<appliedProfile
href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _itvycKXKEd2-KYIfOrm7fA "/>
</profileApplication>
</uml:Model>
<FaktorIPSProfile:PolicyCmptType xmi:id="_7-YmMLDAEd24mM2Z0RL5og"
base_Class="_48SHILDAEd24mM2Z0RL5og"/>
<FaktorIPSProfile:ProductCmptType2 xmi:id="_7-i-QLDAEd24mM2Z0RL5og"
base_Class="_48SHILDAEd24mM2Z0RL5og"/>
</xmi:XMI>

Even more critical is, that I have no possibility to unassign any of these
two stereotypes. So I can add one stereotype and I can't unassign it. This
is the wanted behaviour. But I can add another stereotype and then I can't
unassign any of these two.
Re: Question about extending classes with multiple stereotypes [message #627183 is a reply to message #477962] Wed, 12 November 2008 16:11 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
Christian, I guess you are saying that the fact that UML2 that allows a
a stereotype and a substereotype to be associated with a metaclass
instance makes the implementation incorrect.

Ok, I can agree with that.

But I still think that attempts to instantiate an abstract stereotype as
a required extension should fail/be ignored, and that the 'required'
aspect of an extension should not inherited. And that is how it
currently works.

And that is the root of Alex's problem: even if UML2 prevented
stereotype/substereotype from being applied simultaneously to the same
instance of a metaclass, his example should still work fine (i.e. not
fail), because the base stereotype declaring the required extension is
abstract, which is a no-op.

Cheers,

Rafael

Christian W. Damus wrote:
> Hi, Rafael,
>
> I do not agree that the behaviour observed in the MDT UML2
> implementation is consistent wth the UML specification or its intention.
>
> The discussion of the MOF equivalent of a metaclass extension makes it
> clear that the semantics of Extensions are consistent with those of
> ordinary Associations. Thus, the multiplicities of extension ends have
> the same meaning as for association ends: they constrain the number of
> links (association instances) that can have some instance of a class (in
> this case, a stereotype) in a particular role, linked to the same object
> (in this case, a UML element, instance of the extended metaclass) in the
> other role.
>
> So, in any metaclass extension, it actually means that at most one
> instance of the stereotype (or any stereotype conforming to it) can be
> linked by that extension to the same instance of the extended metaclass.
> This is just like any other association. Consider an association like
> this:
>
> Car [1] -------- [4] Wheel
>
> with MagWheel specializing Wheel. We cannot have a Car with 4 Wheels
> and 4 MagWheels. So it is, also, with stereotype generalization and
> metaclass extensions.
>
> It makes sense for an abstract stereotype to have a required extension,
> because this simply means that an instance of that stereotype must be
> linked to an instance of the extended metaclass. It can be an instance
> of any concrete sub-stereotype, but nonetheless only one instance.
>
> It does appear to me that, in the more general case, the ability to
> apply multiple sub-stereotypes of a stereotype to a single element,
> where the extension is defined on the super-stereotype, is a bug in
> UML2. It's also a special case of a more general problem of not
> validating the multiplicities of non-navigable association ends, because
> they don't exist in the Ecore representation.
>
> Cheers,
>
> Christian
>
> Rafael Chaves wrote:
>> I was curious about this issue as I had never noticed that feature
>> before. I decided to implement support for abstract stereotypes and
>> required extensions in the TextUML Toolkit. See:
>>
>> http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/
>>
>>
>> But back to the topic - from what I observed when playing with the
>> latest TextUML Toolkit implementation (based on UML2 2.2):
>>
>> 1) a required extension causes the declaring stereotype to be
>> implicitly applied to all instances of the extended metaclass on a
>> package where the defining profile is applied;
>> 2) that effect applies only to the stereotype declaring the extension,
>> not to any substereotypes (which makes a lot of sense), which still
>> must be applied explicitly;
>> 3) as with other kinds of classifiers, abstract stereotypes cannot be
>> instantiated (applied), which also makes a lot of sense;
>>
>> Corollary: making an abstract stereotype declare a required extension
>> has no effect whatsoever, and thus is pointless.
>>
>> Finally, for two stereotypes A and B, where B specializes A, it seems
>> to be legal to apply both B and A to a target metaclass instance. So
>> even if "3" above was not true, or if you made your base stereotype
>> non-abstract, it would be valid to apply the substereotypes. This does
>> not seem to be covered by the UML specification.
>>
>> Granted, much of what is said above is based on observation of the
>> behavior of the MDT UML2 implementation, but I think that the observed
>> behavior makes a lot of sense, and seems to be well aligned with the
>> UML spec.
>>
>> Also, maybe there should be a constraint in the UML spec that ensured
>> that abstract stereotypes did not declare required extensions.
>>
>> Does this all make sense?
>>
>> Cheers,
>>
>> Rafael
>>
>> James Bruck wrote:
>>> Hi Alex,
>>>
>>> I think you are right when you say: For I guessed multiple
>>> stereotypes for metaclasses are only possible if you make an
>>> extension for each one?
>>> The Element.isStereotypeApplicable(), is implemented that way and I
>>> also confirmed this by playing around with the UML editor.
>>>
>>> You are correct in creating a required stereotype by setting the
>>> lower bound of the extension end to 1. Extension::isRequired()
>>> checks the lower bound of the first owned end.
>>>
>>> So I'm not sure why you can succesfully apply the second stereotype
>>> as you mention.
>>>
>>> Can you post a small piece of your profile and model so I can see
>>> what exactly is going on.
>>>
>>> Cheers,
>>> - James.
>>>
>>>
>>>
>>>
>>> "Alex " <eistoeter@gmx.de> wrote in message
>>> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>>>> Hi
>>>>
>>>> I made a custom uml profile for our models. At the moment it only
>>>> contains three stereotypes. One is abstract and the other two
>>>> inherit from this abstract stereotype.
>>>>
>>>> I then established an extension for uml::Class and linked it with
>>>> the abstract stereotype. I also made it be a required extension, so
>>>> the multiplicity of the extension end ist 1...1
>>>>
>>>> Now I assumed this means that any class in my model must ALWAYS HAVE
>>>> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>>>
>>>> But still it is possible to say:
>>>>
>>>> umlClass.applyStereotype(ConcreteStereotype1);
>>>> umlClass.applyStereotype(ConcreteStereotype2);
>>>>
>>>> Then my umlClass will have both stereotypes assigned. Is this a bug?
>>>> For I guessed multiple stereotypes for metaclasses are only possible
>>>> if you make an extension for each one?
>>>>
>>>> Can someone bring light into this?
>>>>
>>>> Best regards
>>>>
>>>
>>>
Re: Question about extending classes with multiple stereotypes [message #627184 is a reply to message #477966] Wed, 12 November 2008 17:05 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Rafael,

See some comments in-line, below.

cW

Rafael Chaves wrote:
> Christian, I guess you are saying that the fact that UML2 that allows a
> a stereotype and a substereotype to be associated with a metaclass
> instance makes the implementation incorrect.
>
> Ok, I can agree with that.
>
> But I still think that attempts to instantiate an abstract stereotype as
> a required extension should fail/be ignored, and that the 'required'
> aspect of an extension should not inherited. And that is how it
> currently works.

I think the requiredness seems not to be inherited simply because the
API doesn't know which concrete Stereotype to instantiate. It can be
argued that the default creation of stereotype instances for required
stereotypes, though friendly in simple cases without stereotype
generalization, is unnecessary and inconsistent.

It's unnecessary because multiplicity lower bounds are simply
constraints stipulating that a model is invalid if the property (in this
case an extension end) doesn't have a certain number of values. It
doesn't mean that a tool should try to create values to satisfy the
constraint. :-)

It's inconsistent because the API cannot create the stereotype
application that a user needs in the case of stereotype generalization.

In general, and in the case of ExtensionEnds, the multiplicity of a
property is always inherited by specializing classifier context, unless
it is explicitly replaced by a redefining property.


> And that is the root of Alex's problem: even if UML2 prevented
> stereotype/substereotype from being applied simultaneously to the same
> instance of a metaclass, his example should still work fine (i.e. not
> fail), because the base stereotype declaring the required extension is
> abstract, which is a no-op.

What do you mean by "work fine?" Do you mean, that he should be able to
apply both of the concrete specializations? That would violate the
multiplicity of the extension end, which upper bound is 1. 2 is greater
than 1.

The fact that the extension is required is actually irrelevant to the
problem as Alex originally stated it. :-) His problem was with the
upper bound, not the lower.

>
> Cheers,
>
> Rafael
>
> Christian W. Damus wrote:
>> Hi, Rafael,
>>
>> I do not agree that the behaviour observed in the MDT UML2
>> implementation is consistent wth the UML specification or its intention.
>>
>> The discussion of the MOF equivalent of a metaclass extension makes it
>> clear that the semantics of Extensions are consistent with those of
>> ordinary Associations. Thus, the multiplicities of extension ends
>> have the same meaning as for association ends: they constrain the
>> number of links (association instances) that can have some instance of
>> a class (in this case, a stereotype) in a particular role, linked to
>> the same object (in this case, a UML element, instance of the extended
>> metaclass) in the other role.
>>
>> So, in any metaclass extension, it actually means that at most one
>> instance of the stereotype (or any stereotype conforming to it) can be
>> linked by that extension to the same instance of the extended
>> metaclass. This is just like any other association. Consider an
>> association like this:
>>
>> Car [1] -------- [4] Wheel
>>
>> with MagWheel specializing Wheel. We cannot have a Car with 4 Wheels
>> and 4 MagWheels. So it is, also, with stereotype generalization and
>> metaclass extensions.
>>
>> It makes sense for an abstract stereotype to have a required
>> extension, because this simply means that an instance of that
>> stereotype must be linked to an instance of the extended metaclass.
>> It can be an instance of any concrete sub-stereotype, but nonetheless
>> only one instance.
>>
>> It does appear to me that, in the more general case, the ability to
>> apply multiple sub-stereotypes of a stereotype to a single element,
>> where the extension is defined on the super-stereotype, is a bug in
>> UML2. It's also a special case of a more general problem of not
>> validating the multiplicities of non-navigable association ends,
>> because they don't exist in the Ecore representation.
>>
>> Cheers,
>>
>> Christian
>>
>> Rafael Chaves wrote:
>>> I was curious about this issue as I had never noticed that feature
>>> before. I decided to implement support for abstract stereotypes and
>>> required extensions in the TextUML Toolkit. See:
>>>
>>> http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/
>>>
>>>
>>> But back to the topic - from what I observed when playing with the
>>> latest TextUML Toolkit implementation (based on UML2 2.2):
>>>
>>> 1) a required extension causes the declaring stereotype to be
>>> implicitly applied to all instances of the extended metaclass on a
>>> package where the defining profile is applied;
>>> 2) that effect applies only to the stereotype declaring the
>>> extension, not to any substereotypes (which makes a lot of sense),
>>> which still must be applied explicitly;
>>> 3) as with other kinds of classifiers, abstract stereotypes cannot be
>>> instantiated (applied), which also makes a lot of sense;
>>>
>>> Corollary: making an abstract stereotype declare a required extension
>>> has no effect whatsoever, and thus is pointless.
>>>
>>> Finally, for two stereotypes A and B, where B specializes A, it seems
>>> to be legal to apply both B and A to a target metaclass instance. So
>>> even if "3" above was not true, or if you made your base stereotype
>>> non-abstract, it would be valid to apply the substereotypes. This
>>> does not seem to be covered by the UML specification.
>>>
>>> Granted, much of what is said above is based on observation of the
>>> behavior of the MDT UML2 implementation, but I think that the
>>> observed behavior makes a lot of sense, and seems to be well aligned
>>> with the UML spec.
>>>
>>> Also, maybe there should be a constraint in the UML spec that ensured
>>> that abstract stereotypes did not declare required extensions.
>>>
>>> Does this all make sense?
>>>
>>> Cheers,
>>>
>>> Rafael
>>>
>>> James Bruck wrote:
>>>> Hi Alex,
>>>>
>>>> I think you are right when you say: For I guessed multiple
>>>> stereotypes for metaclasses are only possible if you make an
>>>> extension for each one?
>>>> The Element.isStereotypeApplicable(), is implemented that way and I
>>>> also confirmed this by playing around with the UML editor.
>>>>
>>>> You are correct in creating a required stereotype by setting the
>>>> lower bound of the extension end to 1. Extension::isRequired()
>>>> checks the lower bound of the first owned end.
>>>>
>>>> So I'm not sure why you can succesfully apply the second stereotype
>>>> as you mention.
>>>>
>>>> Can you post a small piece of your profile and model so I can see
>>>> what exactly is going on.
>>>>
>>>> Cheers,
>>>> - James.
>>>>
>>>>
>>>>
>>>>
>>>> "Alex " <eistoeter@gmx.de> wrote in message
>>>> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>>>>> Hi
>>>>>
>>>>> I made a custom uml profile for our models. At the moment it only
>>>>> contains three stereotypes. One is abstract and the other two
>>>>> inherit from this abstract stereotype.
>>>>>
>>>>> I then established an extension for uml::Class and linked it with
>>>>> the abstract stereotype. I also made it be a required extension, so
>>>>> the multiplicity of the extension end ist 1...1
>>>>>
>>>>> Now I assumed this means that any class in my model must ALWAYS
>>>>> HAVE EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>>>>
>>>>> But still it is possible to say:
>>>>>
>>>>> umlClass.applyStereotype(ConcreteStereotype1);
>>>>> umlClass.applyStereotype(ConcreteStereotype2);
>>>>>
>>>>> Then my umlClass will have both stereotypes assigned. Is this a
>>>>> bug? For I guessed multiple stereotypes for metaclasses are only
>>>>> possible if you make an extension for each one?
>>>>>
>>>>> Can someone bring light into this?
>>>>>
>>>>> Best regards
>>>>>
>>>>
>>>>
Re: Question about extending classes with multiple stereotypes [message #627185 is a reply to message #477967] Wed, 12 November 2008 17:09 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

I should just clarify one statement:

cW

Christian W. Damus wrote:
>
> In general, and in the case of ExtensionEnds, the multiplicity of a
> property is always inherited by specializing classifier context, unless
> it is explicitly replaced by a redefining property.


The ExtensionEnd functions as a property of the *metaclass*, not the
stereotype. So, the redefinition context is actually the metaclass.
The extension end isn't inherited by sub-stereotypes, but actually by
subclasses of the extended metaclass! :-)
Re: Question about extending classes with multiple stereotypes [message #627187 is a reply to message #477965] Fri, 14 November 2008 15:10 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
.... I haven't forgotten about this ... will look into later today :)


"Alex " <eistoeter@gmx.de> wrote in message
news:a883f38111657994158a234966ee7db7$1@www.eclipse.org...
> Hi James. Thanks for your interest in this problem.
>
> Here comes the profile:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <uml:Profile xmi:version="2.1"
> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
> xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
> xmi:id="_itvycKXKEd2-KYIfOrm7fA" name="Faktor-IPS Profile"
> metaclassReference="_qVRZoKwOEd2sZYFMsQch6A">
> <elementImport xmi:id="_qVRZoKwOEd2sZYFMsQch6A" alias="Class">
> <importedElement xmi:type="uml:Class"
> href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
> </elementImport>
> <packagedElement xmi:type="uml:Stereotype"
> xmi:id="_mvNcwKXKEd2-KYIfOrm7fA" name="PolicyCmptType">
> <generalization xmi:id="_nVypYKwREd2z9Lg5-Fmnrw"
> general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
> </packagedElement>
> <packagedElement xmi:type="uml:Stereotype"
> xmi:id="_-9kMQKXMEd2-KYIfOrm7fA" name="ProductCmptType2">
> <generalization xmi:id="_wkZG8KwREd2z9Lg5-Fmnrw"
> general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
> </packagedElement>
> <packagedElement xmi:type="uml:Stereotype"
> xmi:id="_e6t6gKwREd2z9Lg5-Fmnrw" name="Type" isAbstract="true">
> <ownedAttribute xmi:id="_7pE8YawREd2z9Lg5-Fmnrw" name="base_Class"
> association="_7o4IEKwREd2z9Lg5-Fmnrw">
> <type xmi:type="uml:Class"
> href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
> </ownedAttribute>
> </packagedElement>
> <packagedElement xmi:type="uml:Extension"
> xmi:id="_7o4IEKwREd2z9Lg5-Fmnrw" name="Class_Type"
> memberEnd="_7pE8YKwREd2z9Lg5-Fmnrw _7pE8YawREd2z9Lg5-Fmnrw">
> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_7pE8YKwREd2z9Lg5-Fmnrw"
> name="extension_IpsObject" type="_e6t6gKwREd2z9Lg5-Fmnrw"
> aggregation="composite" association="_7o4IEKwREd2z9Lg5-Fmnrw">
> <lowerValue xmi:type="uml:LiteralInteger"
> xmi:id="_BwxTYKwSEd2z9Lg5-Fmnrw" value="1"/>
> </ownedEnd>
> </packagedElement>
> </uml:Profile>
>
> And here comes an example model for it. I should not be able to assign
> these two stereotypes to myclass but only one of both:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xmi:XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:FaktorIPSProfile="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
> xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
> xsi:schemaLocation="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0
> ./../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml#_ Ztzm0LCdEd2r-NXccNaiJQ ">
> <uml:Model xmi:id="_q8bikK0GEd2GcoPSbdQh2w" name="example">
> <packagedElement xmi:type="uml:Class" xmi:id="_48SHILDAEd24mM2Z0RL5og"
> name="myclass"/>
> <profileApplication xmi:id="_3ZgFwLDAEd24mM2Z0RL5og">
> <eAnnotations xmi:id="_3ZpPsLDAEd24mM2Z0RL5og"
> source="http://www.eclipse.org/uml2/2.0.0/UML">
> <references xmi:type="ecore:EPackage"
> href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _Ztzm0LCdEd2r-NXccNaiJQ "/>
> </eAnnotations>
> <appliedProfile
> href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _itvycKXKEd2-KYIfOrm7fA "/>
> </profileApplication>
> </uml:Model>
> <FaktorIPSProfile:PolicyCmptType xmi:id="_7-YmMLDAEd24mM2Z0RL5og"
> base_Class="_48SHILDAEd24mM2Z0RL5og"/>
> <FaktorIPSProfile:ProductCmptType2 xmi:id="_7-i-QLDAEd24mM2Z0RL5og"
> base_Class="_48SHILDAEd24mM2Z0RL5og"/>
> </xmi:XMI>
>
> Even more critical is, that I have no possibility to unassign any of these
> two stereotypes. So I can add one stereotype and I can't unassign it. This
> is the wanted behaviour. But I can add another stereotype and then I can't
> unassign any of these two.
>
>
>
Re: Question about extending classes with multiple stereotypes [message #627195 is a reply to message #477967] Mon, 17 November 2008 08:57 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Christian,

I agree that the autmatic application of required stereotypes is unnecessary
and inconsistent, at least from a purely structural perspective. Indeed, the
bounds on extension ends would ideally be evaluated only during validation,
and a case where a required stereotype has not been applied, valdation would
fail.

Unfortunately, much of the intended/expected semantics in UML aren't
strictly structural and are specified in a rather informal way;
incidentally, there is a working group at the OMG wrestling with this very
issue. The intended semantics of profile application (as an operation), in
cases where the profile contains required stereotypes, are such that all
required stereotypes are automatically applied. This is evidently
problematic in cases where there is a stereotype hierarchy involved, and
unsurprisingly is something that isn't explicitly addressed by the
specification. In the absence of formal guidance for cases like these, we
are left with best practices (which may eventually make their way into the
specification) as our guide. Based on the way the UML2 implementation works
(for better or worse), the "best practice" is to define extensions only on
non-abstract stereotypes and on leaf stereotypes in a hierarchy; using such
a practice offers the benefits of proeperty inheritence while at the same
time avoiding ambguous semantics.

Based on some of the discussions that have been taking place at the OMG, it
may well be the case that the notion of "profiles", at least in its current
incarnation, will go away (to be replaced by MOF modeling, which is
essentially what profiles, originally introduced as a "lightweight"
extension mechanism, have become in practice).

Kenn

"Christian W. Damus" <cdamus@zeligsoft.com> wrote in message
news:gff2cv$2jf$1@build.eclipse.org...
> Hi, Rafael,
>
> See some comments in-line, below.
>
> cW
>
> Rafael Chaves wrote:
>> Christian, I guess you are saying that the fact that UML2 that allows a a
>> stereotype and a substereotype to be associated with a metaclass instance
>> makes the implementation incorrect.
>>
>> Ok, I can agree with that.
>>
>> But I still think that attempts to instantiate an abstract stereotype as
>> a required extension should fail/be ignored, and that the 'required'
>> aspect of an extension should not inherited. And that is how it currently
>> works.
>
> I think the requiredness seems not to be inherited simply because the API
> doesn't know which concrete Stereotype to instantiate. It can be argued
> that the default creation of stereotype instances for required
> stereotypes, though friendly in simple cases without stereotype
> generalization, is unnecessary and inconsistent.
>
> It's unnecessary because multiplicity lower bounds are simply constraints
> stipulating that a model is invalid if the property (in this case an
> extension end) doesn't have a certain number of values. It doesn't mean
> that a tool should try to create values to satisfy the constraint. :-)
>
> It's inconsistent because the API cannot create the stereotype application
> that a user needs in the case of stereotype generalization.
>
> In general, and in the case of ExtensionEnds, the multiplicity of a
> property is always inherited by specializing classifier context, unless it
> is explicitly replaced by a redefining property.
>
>
>> And that is the root of Alex's problem: even if UML2 prevented
>> stereotype/substereotype from being applied simultaneously to the same
>> instance of a metaclass, his example should still work fine (i.e. not
>> fail), because the base stereotype declaring the required extension is
>> abstract, which is a no-op.
>
> What do you mean by "work fine?" Do you mean, that he should be able to
> apply both of the concrete specializations? That would violate the
> multiplicity of the extension end, which upper bound is 1. 2 is greater
> than 1.
>
> The fact that the extension is required is actually irrelevant to the
> problem as Alex originally stated it. :-) His problem was with the upper
> bound, not the lower.
>
>>
>> Cheers,
>>
>> Rafael
>>
>> Christian W. Damus wrote:
>>> Hi, Rafael,
>>>
>>> I do not agree that the behaviour observed in the MDT UML2
>>> implementation is consistent wth the UML specification or its intention.
>>>
>>> The discussion of the MOF equivalent of a metaclass extension makes it
>>> clear that the semantics of Extensions are consistent with those of
>>> ordinary Associations. Thus, the multiplicities of extension ends have
>>> the same meaning as for association ends: they constrain the number of
>>> links (association instances) that can have some instance of a class (in
>>> this case, a stereotype) in a particular role, linked to the same object
>>> (in this case, a UML element, instance of the extended metaclass) in the
>>> other role.
>>>
>>> So, in any metaclass extension, it actually means that at most one
>>> instance of the stereotype (or any stereotype conforming to it) can be
>>> linked by that extension to the same instance of the extended metaclass.
>>> This is just like any other association. Consider an association like
>>> this:
>>>
>>> Car [1] -------- [4] Wheel
>>>
>>> with MagWheel specializing Wheel. We cannot have a Car with 4 Wheels
>>> and 4 MagWheels. So it is, also, with stereotype generalization and
>>> metaclass extensions.
>>>
>>> It makes sense for an abstract stereotype to have a required extension,
>>> because this simply means that an instance of that stereotype must be
>>> linked to an instance of the extended metaclass. It can be an instance
>>> of any concrete sub-stereotype, but nonetheless only one instance.
>>>
>>> It does appear to me that, in the more general case, the ability to
>>> apply multiple sub-stereotypes of a stereotype to a single element,
>>> where the extension is defined on the super-stereotype, is a bug in
>>> UML2. It's also a special case of a more general problem of not
>>> validating the multiplicities of non-navigable association ends, because
>>> they don't exist in the Ecore representation.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>> Rafael Chaves wrote:
>>>> I was curious about this issue as I had never noticed that feature
>>>> before. I decided to implement support for abstract stereotypes and
>>>> required extensions in the TextUML Toolkit. See:
>>>>
>>>> http://abstratt.com/blog/2008/11/11/feature-required-extensi ons-for-stereotypes/
>>>>
>>>> But back to the topic - from what I observed when playing with the
>>>> latest TextUML Toolkit implementation (based on UML2 2.2):
>>>>
>>>> 1) a required extension causes the declaring stereotype to be
>>>> implicitly applied to all instances of the extended metaclass on a
>>>> package where the defining profile is applied;
>>>> 2) that effect applies only to the stereotype declaring the extension,
>>>> not to any substereotypes (which makes a lot of sense), which still
>>>> must be applied explicitly;
>>>> 3) as with other kinds of classifiers, abstract stereotypes cannot be
>>>> instantiated (applied), which also makes a lot of sense;
>>>>
>>>> Corollary: making an abstract stereotype declare a required extension
>>>> has no effect whatsoever, and thus is pointless.
>>>>
>>>> Finally, for two stereotypes A and B, where B specializes A, it seems
>>>> to be legal to apply both B and A to a target metaclass instance. So
>>>> even if "3" above was not true, or if you made your base stereotype
>>>> non-abstract, it would be valid to apply the substereotypes. This does
>>>> not seem to be covered by the UML specification.
>>>>
>>>> Granted, much of what is said above is based on observation of the
>>>> behavior of the MDT UML2 implementation, but I think that the observed
>>>> behavior makes a lot of sense, and seems to be well aligned with the
>>>> UML spec.
>>>>
>>>> Also, maybe there should be a constraint in the UML spec that ensured
>>>> that abstract stereotypes did not declare required extensions.
>>>>
>>>> Does this all make sense?
>>>>
>>>> Cheers,
>>>>
>>>> Rafael
>>>>
>>>> James Bruck wrote:
>>>>> Hi Alex,
>>>>>
>>>>> I think you are right when you say: For I guessed multiple stereotypes
>>>>> for metaclasses are only possible if you make an extension for each
>>>>> one?
>>>>> The Element.isStereotypeApplicable(), is implemented that way and I
>>>>> also confirmed this by playing around with the UML editor.
>>>>>
>>>>> You are correct in creating a required stereotype by setting the lower
>>>>> bound of the extension end to 1. Extension::isRequired() checks the
>>>>> lower bound of the first owned end.
>>>>>
>>>>> So I'm not sure why you can succesfully apply the second stereotype as
>>>>> you mention.
>>>>>
>>>>> Can you post a small piece of your profile and model so I can see what
>>>>> exactly is going on.
>>>>>
>>>>> Cheers,
>>>>> - James.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Alex " <eistoeter@gmx.de> wrote in message
>>>>> news:99faa26dde1e9bb59c698d7f755fc70e$1@www.eclipse.org...
>>>>>> Hi
>>>>>>
>>>>>> I made a custom uml profile for our models. At the moment it only
>>>>>> contains three stereotypes. One is abstract and the other two inherit
>>>>>> from this abstract stereotype.
>>>>>>
>>>>>> I then established an extension for uml::Class and linked it with the
>>>>>> abstract stereotype. I also made it be a required extension, so the
>>>>>> multiplicity of the extension end ist 1...1
>>>>>>
>>>>>> Now I assumed this means that any class in my model must ALWAYS HAVE
>>>>>> EXACTLY ONE stereotype that inherits from my abstract stereotype.
>>>>>>
>>>>>> But still it is possible to say:
>>>>>>
>>>>>> umlClass.applyStereotype(ConcreteStereotype1);
>>>>>> umlClass.applyStereotype(ConcreteStereotype2);
>>>>>>
>>>>>> Then my umlClass will have both stereotypes assigned. Is this a bug?
>>>>>> For I guessed multiple stereotypes for metaclasses are only possible
>>>>>> if you make an extension for each one?
>>>>>>
>>>>>> Can someone bring light into this?
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>
>>>>>
Re: Question about extending classes with multiple stereotypes [message #627198 is a reply to message #477978] Mon, 17 November 2008 14:14 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Kenn,

Thanks for your response. It is good to know that the OMG is actively
looking at this, but also a little disconcerting to think that such a
user-friendly mechanism as profiles have been might disappear! Yes,
stereotypes are fully equivalent to MOF models, but I'm not sure that
the concept of ProfileApplication has any equivalent in metamodeling.
It's a very definite relationship indicating some reasonably
well-defined notions of domain-specific extension. Of course, if
"profile application" just takes another form, then that's another matter.

On the subject of the best practice for extensions: I understand the
practicality of defining extensions only on leaf stereotypes, but that
does raise problems, too:

- all leaf stereotypes in a hierarchy may end up with redundant
extensions of the same metaclasses
- how do I ask "is any stereotype conforming to Foo applied to my
element" using standard association navigation semantics in OCL?
- I don't necessarily know what is a leaf stereotype. Another
profile may well need to specialize my stereotypes

Perhaps the Classifier-ness of metaclass extensions can help address
some of these issues. Extensions (like other assocations) are
classifiers, and thus can be abstract. Let the super-stereotype in a
hierarchy define an abstract extension that specializing stereotypes can
specialize and redefine its ends, as necessary. They can narrow or
widen the redefined extension end's metaclass type for their own needs,
while letting clients of the more general stereotype still make
practical use of it.

I think we can marry some of these pragmatic best practices with
standard metamodeling practices. ;-)

In the mean-time, I think I shall also continue to mind an old
best-practice that we haven't mentioned, yet: don't make extensions
required! :-D Or, is that not still a best practice?

Cheers,

Christian


Kenn Hussey wrote:
> Christian,
>
> I agree that the autmatic application of required stereotypes is unnecessary
> and inconsistent, at least from a purely structural perspective. Indeed, the
> bounds on extension ends would ideally be evaluated only during validation,
> and a case where a required stereotype has not been applied, valdation would
> fail.
>
> Unfortunately, much of the intended/expected semantics in UML aren't
> strictly structural and are specified in a rather informal way;
> incidentally, there is a working group at the OMG wrestling with this very
> issue. The intended semantics of profile application (as an operation), in
> cases where the profile contains required stereotypes, are such that all
> required stereotypes are automatically applied. This is evidently
> problematic in cases where there is a stereotype hierarchy involved, and
> unsurprisingly is something that isn't explicitly addressed by the
> specification. In the absence of formal guidance for cases like these, we
> are left with best practices (which may eventually make their way into the
> specification) as our guide. Based on the way the UML2 implementation works
> (for better or worse), the "best practice" is to define extensions only on
> non-abstract stereotypes and on leaf stereotypes in a hierarchy; using such
> a practice offers the benefits of proeperty inheritence while at the same
> time avoiding ambguous semantics.
>
> Based on some of the discussions that have been taking place at the OMG, it
> may well be the case that the notion of "profiles", at least in its current
> incarnation, will go away (to be replaced by MOF modeling, which is
> essentially what profiles, originally introduced as a "lightweight"
> extension mechanism, have become in practice).
>
> Kenn
>

-----8<-----
Re: Question about extending classes with multiple stereotypes [message #627206 is a reply to message #477970] Wed, 19 November 2008 15:58 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
My apologies about the delay on this one.

You are right! Once the stereotypes are applied, there is no way to unapply
them. This is an issue. Please raise a defect on that.
In terms of being able to apply the stereotypes, it does seem reasonable to
allow the application of the stereotypes as can be done from the editor.
What is the desired behavior that you would like to see? There seems to be
ambiguity in this area from the position of the spec. but the way the
application works now seems to be ok.

By the way, I had to "define" the profile you provided in the snippet below
and then re-apply. I don't think you were using static profile definition?

Cheers,
- James.


"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:gfk49b$lmt$1@build.eclipse.org...
> ... I haven't forgotten about this ... will look into later today :)
>
>
> "Alex " <eistoeter@gmx.de> wrote in message
> news:a883f38111657994158a234966ee7db7$1@www.eclipse.org...
>> Hi James. Thanks for your interest in this problem.
>>
>> Here comes the profile:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <uml:Profile xmi:version="2.1"
>> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
>> xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
>> xmi:id="_itvycKXKEd2-KYIfOrm7fA" name="Faktor-IPS Profile"
>> metaclassReference="_qVRZoKwOEd2sZYFMsQch6A">
>> <elementImport xmi:id="_qVRZoKwOEd2sZYFMsQch6A" alias="Class">
>> <importedElement xmi:type="uml:Class"
>> href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
>> </elementImport>
>> <packagedElement xmi:type="uml:Stereotype"
>> xmi:id="_mvNcwKXKEd2-KYIfOrm7fA" name="PolicyCmptType">
>> <generalization xmi:id="_nVypYKwREd2z9Lg5-Fmnrw"
>> general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
>> </packagedElement>
>> <packagedElement xmi:type="uml:Stereotype"
>> xmi:id="_-9kMQKXMEd2-KYIfOrm7fA" name="ProductCmptType2">
>> <generalization xmi:id="_wkZG8KwREd2z9Lg5-Fmnrw"
>> general="_e6t6gKwREd2z9Lg5-Fmnrw"/>
>> </packagedElement>
>> <packagedElement xmi:type="uml:Stereotype"
>> xmi:id="_e6t6gKwREd2z9Lg5-Fmnrw" name="Type" isAbstract="true">
>> <ownedAttribute xmi:id="_7pE8YawREd2z9Lg5-Fmnrw" name="base_Class"
>> association="_7o4IEKwREd2z9Lg5-Fmnrw">
>> <type xmi:type="uml:Class"
>> href="pathmap://UML_METAMODELS/UML.metamodel.uml#Class"/>
>> </ownedAttribute>
>> </packagedElement>
>> <packagedElement xmi:type="uml:Extension"
>> xmi:id="_7o4IEKwREd2z9Lg5-Fmnrw" name="Class_Type"
>> memberEnd="_7pE8YKwREd2z9Lg5-Fmnrw _7pE8YawREd2z9Lg5-Fmnrw">
>> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_7pE8YKwREd2z9Lg5-Fmnrw"
>> name="extension_IpsObject" type="_e6t6gKwREd2z9Lg5-Fmnrw"
>> aggregation="composite" association="_7o4IEKwREd2z9Lg5-Fmnrw">
>> <lowerValue xmi:type="uml:LiteralInteger"
>> xmi:id="_BwxTYKwSEd2z9Lg5-Fmnrw" value="1"/>
>> </ownedEnd>
>> </packagedElement>
>> </uml:Profile>
>>
>> And here comes an example model for it. I should not be able to assign
>> these two stereotypes to myclass but only one of both:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <xmi:XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:FaktorIPSProfile="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
>> xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML"
>> xsi:schemaLocation="http:///schemas/FaktorIPSProfile/_Ztp10LCdEd2r-NXccNaiJQ/0
>> ./../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml#_ Ztzm0LCdEd2r-NXccNaiJQ ">
>> <uml:Model xmi:id="_q8bikK0GEd2GcoPSbdQh2w" name="example">
>> <packagedElement xmi:type="uml:Class" xmi:id="_48SHILDAEd24mM2Z0RL5og"
>> name="myclass"/>
>> <profileApplication xmi:id="_3ZgFwLDAEd24mM2Z0RL5og">
>> <eAnnotations xmi:id="_3ZpPsLDAEd24mM2Z0RL5og"
>> source="http://www.eclipse.org/uml2/2.0.0/UML">
>> <references xmi:type="ecore:EPackage"
>> href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _Ztzm0LCdEd2r-NXccNaiJQ "/>
>> </eAnnotations>
>> <appliedProfile
>> href=" ../../plugin/org.faktorips.uml/FaktorIpsProfile.profile.uml# _itvycKXKEd2-KYIfOrm7fA "/>
>> </profileApplication>
>> </uml:Model>
>> <FaktorIPSProfile:PolicyCmptType xmi:id="_7-YmMLDAEd24mM2Z0RL5og"
>> base_Class="_48SHILDAEd24mM2Z0RL5og"/>
>> <FaktorIPSProfile:ProductCmptType2 xmi:id="_7-i-QLDAEd24mM2Z0RL5og"
>> base_Class="_48SHILDAEd24mM2Z0RL5og"/>
>> </xmi:XMI>
>>
>> Even more critical is, that I have no possibility to unassign any of
>> these two stereotypes. So I can add one stereotype and I can't unassign
>> it. This is the wanted behaviour. But I can add another stereotype and
>> then I can't unassign any of these two.
>>
>>
>>
>
>
Re: Question about extending classes with multiple stereotypes [message #627211 is a reply to message #477981] Thu, 20 November 2008 09:32 Go to previous message
Kenn Hussey is currently offline Kenn HusseyFriend
Messages: 1620
Registered: July 2009
Senior Member
Christian,

I didn't mean to say that profiles will go away, but that the way they are
currently defined by the specification may change (there will always be a
need to specialize UML for specific domains).

Yes, the notion of required stereotypes has always been problematic, so
we've always cautioned clients against using them (if possible).

Kenn

"Christian W. Damus" <cdamus@zeligsoft.com> wrote in message
news:gfru82$3u9$1@build.eclipse.org...
> Hi, Kenn,
>
> Thanks for your response. It is good to know that the OMG is actively
> looking at this, but also a little disconcerting to think that such a
> user-friendly mechanism as profiles have been might disappear! Yes,
> stereotypes are fully equivalent to MOF models, but I'm not sure that the
> concept of ProfileApplication has any equivalent in metamodeling. It's a
> very definite relationship indicating some reasonably well-defined notions
> of domain-specific extension. Of course, if "profile application" just
> takes another form, then that's another matter.
>
> On the subject of the best practice for extensions: I understand the
> practicality of defining extensions only on leaf stereotypes, but that
> does raise problems, too:
>
> - all leaf stereotypes in a hierarchy may end up with redundant
> extensions of the same metaclasses
> - how do I ask "is any stereotype conforming to Foo applied to my
> element" using standard association navigation semantics in OCL?
> - I don't necessarily know what is a leaf stereotype. Another
> profile may well need to specialize my stereotypes
>
> Perhaps the Classifier-ness of metaclass extensions can help address some
> of these issues. Extensions (like other assocations) are classifiers, and
> thus can be abstract. Let the super-stereotype in a hierarchy define an
> abstract extension that specializing stereotypes can specialize and
> redefine its ends, as necessary. They can narrow or widen the redefined
> extension end's metaclass type for their own needs, while letting clients
> of the more general stereotype still make practical use of it.
>
> I think we can marry some of these pragmatic best practices with standard
> metamodeling practices. ;-)
>
> In the mean-time, I think I shall also continue to mind an old
> best-practice that we haven't mentioned, yet: don't make extensions
> required! :-D Or, is that not still a best practice?
>
> Cheers,
>
> Christian
>
>
> Kenn Hussey wrote:
>> Christian,
>>
>> I agree that the autmatic application of required stereotypes is
>> unnecessary and inconsistent, at least from a purely structural
>> perspective. Indeed, the bounds on extension ends would ideally be
>> evaluated only during validation, and a case where a required stereotype
>> has not been applied, valdation would fail.
>>
>> Unfortunately, much of the intended/expected semantics in UML aren't
>> strictly structural and are specified in a rather informal way;
>> incidentally, there is a working group at the OMG wrestling with this
>> very issue. The intended semantics of profile application (as an
>> operation), in cases where the profile contains required stereotypes, are
>> such that all required stereotypes are automatically applied. This is
>> evidently problematic in cases where there is a stereotype hierarchy
>> involved, and unsurprisingly is something that isn't explicitly addressed
>> by the specification. In the absence of formal guidance for cases like
>> these, we are left with best practices (which may eventually make their
>> way into the specification) as our guide. Based on the way the UML2
>> implementation works (for better or worse), the "best practice" is to
>> define extensions only on non-abstract stereotypes and on leaf
>> stereotypes in a hierarchy; using such a practice offers the benefits of
>> proeperty inheritence while at the same time avoiding ambguous semantics.
>>
>> Based on some of the discussions that have been taking place at the OMG,
>> it may well be the case that the notion of "profiles", at least in its
>> current incarnation, will go away (to be replaced by MOF modeling, which
>> is essentially what profiles, originally introduced as a "lightweight"
>> extension mechanism, have become in practice).
>>
>> Kenn
>>
>
> -----8<-----
Re: Question about extending classes with multiple stereotypes [message #627212 is a reply to message #477994] Fri, 21 November 2008 10:43 Go to previous message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
Kenn,

We hope that stereotype mechanism will not be changed because this could
be a problem for our existing users.
Imagine if you develop a military, finance or other projects. The
development and use of the project could be over 10 years. If you
permanently change the EclipseUML2 plugin model this model duration is a
lot reduced. One of the goal of UML modeling is to be independent of short
term technologies.
For example to allow using Eclipse 3.2 for modeling and reuse the same
model by just importing it inside the next Eclipse 4.0 or Eclipse 5.0 in 5
years :-)
A real example today is the use a RSA 7 model develop with Eclipse 3.2 and
just import it inside Eclipse 3.4 (see my demo at:
http://www.forum-omondo.com/documentation_eclipseuml_2008/ec lipseuml2008_dynamic_navigation.html#5._Model_interchange_wi ht_RSA_7
)
This is really cool and show that modeling is important to protect long
term companies development investments.
We hope that the OMG or others UML2 plugins will not forget that projects
are already using these stereotype technologies and that a new change
could break the upgrade compatibility.

Let's now talk about my personal dream :-)
If you look at Java then you can always compile your java 1.4 projects
inside Java 1.6. It is always compatible.
Inside Eclipse 3.4 how many fantastic plugins are not anymore compatible.
We lost so many nice plugins because of permanent EMF/GEF etc.. and
Eclipse core upgrades.
The UML2 project has been the only one to always remain stable and keep
backward compatibility in the last few years. This is why EclipseUML2
plugin is today the world model standard.
Please don't break this compatibility !!

Vlad
Omondo
Re: Question about extending classes with multiple stereotypes [message #627213 is a reply to message #477995] Fri, 21 November 2008 14:42 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Vlad,

In terms of profiles and stereotypes, I wanted to put your mind at ease
(hopefully). I was speaking with Bran Selic (former OMG chair of UML)
about the possibility of profiles "going away" (or changing) and this is
what he replied:

-------------------
I would not put too much stock in such discussions, since there is far too
much vested into profiles at the moment. I doubt that anyone has the
resources to redo the dozen or so OMG adopted profiles or the hundreds of
user-defined ones. Even Microsoft now view UML as a family of languages,
that is, as a foundation for constructing more specific languages. Profiles
are the current mechanism by which one produces those more specific
languages.

.......

The more likely scenario is a redesigned profile mechanism based on a
somewhat refactored UML.

The MOF variant is available now, so there is nothing new there.

------------------------------

I've been following the uml-roadmap mailing list at the OMG and it would
seem that there is a lot on the table in terms of possible changes for UML
but such changes would take a while (years probably) to make their way into
a specification, if we can predict future pace based on the pace of change
in the past.

I believe Kenn's comments are accurate (as always ;) )

Cheers,

- James.

p.s. thanks for the kind words about the UML2 project. I know that Kenn has
invested a lot of sweat in making the UML2 project what it is today.



"Vlad Varnica" <varnica@omondo.com> wrote in message
news:31cc9e8f2c7ea5d14c99636cd478aabd$1@www.eclipse.org...
> Kenn,
>
> We hope that stereotype mechanism will not be changed because this could
> be a problem for our existing users. Imagine if you develop a military,
> finance or other projects. The development and use of the project could be
> over 10 years. If you permanently change the EclipseUML2 plugin model this
> model duration is a lot reduced. One of the goal of UML modeling is to be
> independent of short term technologies. For example to allow using Eclipse
> 3.2 for modeling and reuse the same model by just importing it inside the
> next Eclipse 4.0 or Eclipse 5.0 in 5 years :-)
> A real example today is the use a RSA 7 model develop with Eclipse 3.2 and
> just import it inside Eclipse 3.4 (see my demo at:
> http://www.forum-omondo.com/documentation_eclipseuml_2008/ec lipseuml2008_dynamic_navigation.html#5._Model_interchange_wi ht_RSA_7 )
> This is really cool and show that modeling is important to protect long
> term companies development investments.
> We hope that the OMG or others UML2 plugins will not forget that projects
> are already using these stereotype technologies and that a new change
> could break the upgrade compatibility.
> Let's now talk about my personal dream :-)
> If you look at Java then you can always compile your java 1.4 projects
> inside Java 1.6. It is always compatible. Inside Eclipse 3.4 how many
> fantastic plugins are not anymore compatible. We lost so many nice plugins
> because of permanent EMF/GEF etc.. and Eclipse core upgrades.
> The UML2 project has been the only one to always remain stable and keep
> backward compatibility in the last few years. This is why EclipseUML2
> plugin is today the world model standard.
> Please don't break this compatibility !!
>
> Vlad Omondo
>
Previous Topic:Re: Existing genmodel not picked up
Next Topic:Constructors and Parameters
Goto Forum:
  


Current Time: Mon Mar 30 17:46:37 GMT 2020

Powered by FUDForum. Page generated in 0.04416 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top