Home » Modeling » UML2 » Question about extending classes with multiple stereotypes
| |
Re: Question about extending classes with multiple stereotypes [message #477959 is a reply to message #477958] |
Wed, 12 November 2008 06:53 |
Rafael Chaves 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 #477962 is a reply to message #477959] |
Wed, 12 November 2008 12:51 |
Eclipse User |
|
|
|
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 |
Eclipse User |
|
|
|
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 #477966 is a reply to message #477962] |
Wed, 12 November 2008 16:11 |
Rafael Chaves 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 |
Eclipse User |
|
|
|
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 |
Eclipse User |
|
|
|
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 #477978 is a reply to message #477967] |
Mon, 17 November 2008 08:57 |
Kenn Hussey 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 |
Eclipse User |
|
|
|
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 #477994 is a reply to message #477981] |
Thu, 20 November 2008 09:32 |
Kenn Hussey 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 #477996 is a reply to message #477995] |
Fri, 21 November 2008 14:42 |
james bruck 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 #627171 is a reply to message #477958] |
Wed, 12 November 2008 06:53 |
Rafael Chaves 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 #627174 is a reply to message #477959] |
Wed, 12 November 2008 12:51 |
Eclipse User |
|
|
|
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 |
Eclipse User |
|
|
|
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 #627183 is a reply to message #477962] |
Wed, 12 November 2008 16:11 |
Rafael Chaves 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 |
Eclipse User |
|
|
|
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 |
Eclipse User |
|
|
|
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 #627195 is a reply to message #477967] |
Mon, 17 November 2008 08:57 |
Kenn Hussey 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 |
Eclipse User |
|
|
|
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 #627211 is a reply to message #477981] |
Thu, 20 November 2008 09:32 |
Kenn Hussey 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 #627213 is a reply to message #477995] |
Fri, 21 November 2008 14:42 |
james bruck 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
>
|
|
|
Goto Forum:
Current Time: Fri Sep 27 03:02:13 GMT 2024
Powered by FUDForum. Page generated in 0.07605 seconds
|