Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » inheritance of stereotypes in subclasses
inheritance of stereotypes in subclasses [message #1182568] Tue, 12 November 2013 09:17 Go to next message
Elhamlaoui Mahmoud is currently offline Elhamlaoui MahmoudFriend
Messages: 268
Registered: March 2010
Senior Member
Hi,

I have a question about UML that start tp bothers me lately,

I have class Person which is a superclass of Man and Woman (for example)

if you apply a Stereotype XXX to the Person, shouldn't the sereotype be applied to the

subclasses?

The some issue have been tackled here but without a clear response
http://stackoverflow.com/questions/13020608/uml-stereotypes-applied-to-class-inheritance-design-pattern

Thanks in advance
Re: inheritance of stereotypes in subclasses [message #1182916 is a reply to message #1182568] Tue, 12 November 2013 14:04 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi,

No, stereotype applications are not inherited by specializing
classifiers. A stereotype extends the structure of the UML metamodel,
letting you specify domain-specific attributes on elements in a UML
model. Stereotypes do not alter the run-time semantics of the system
being modeled; they only enrich the modeling language.

That is, unless you actually specify additional run-time semantics on a
stereotype. For example, for your case, you could add an OCL
constraint to the XXX stereotype that, if it has a base_Class (i.e., is
applied to a class), all classes specializing that class must also have
an XXX extension (i.e., have the stereotype applied). But, it would be
a special tool that understands the definition of such a constraint and
applies the stereotype to all subclasses for you! At best it would be
included in model validation to warn you of missing XXXes. But, even
then, each stereotype application would have its own distinct values
for the stereotype's properties, and there is no inheritance of
stereotype attributes. If you need to ensure consistency of some kind
in the stereotype properties, you'd be adding constraints again.

HTH,

Christian


On 2013-11-12 09:17:14 +0000, Elhamlaoui Mahmoud said:

> Hi,
>
> I have a question about UML that start tp bothers me lately,
>
> I have class Person which is a superclass of Man and Woman (for example)
>
> if you apply a Stereotype XXX to the Person, shouldn't the sereotype be
> applied to the
> subclasses?
>
> The some issue have been tackled here but without a clear response
> http://stackoverflow.com/questions/13020608/uml-stereotypes-applied-to-class-inheritance-design-pattern
>
>
> Thanks in advance
Re: inheritance of stereotypes in subclasses [message #1182938 is a reply to message #1182916] Tue, 12 November 2013 14:22 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Christian

That seems very wrong.

If a stereotype adds features to a base class, those features must be
accessible and so exist for the derived class instances.

(Otherwise applying a stereotype to an abstract class would be totally
redundant.)

Regards

Ed Willink


On 12/11/2013 14:04, Christian W. Damus wrote:
> Hi,
>
> No, stereotype applications are not inherited by specializing
> classifiers. A stereotype extends the structure of the UML metamodel,
> letting you specify domain-specific attributes on elements in a UML
> model. Stereotypes do not alter the run-time semantics of the system
> being modeled; they only enrich the modeling language.
>
> That is, unless you actually specify additional run-time semantics on
> a stereotype. For example, for your case, you could add an OCL
> constraint to the XXX stereotype that, if it has a base_Class (i.e.,
> is applied to a class), all classes specializing that class must also
> have an XXX extension (i.e., have the stereotype applied). But, it
> would be a special tool that understands the definition of such a
> constraint and applies the stereotype to all subclasses for you! At
> best it would be included in model validation to warn you of missing
> XXXes. But, even then, each stereotype application would have its own
> distinct values for the stereotype's properties, and there is no
> inheritance of stereotype attributes. If you need to ensure
> consistency of some kind in the stereotype properties, you'd be adding
> constraints again.
>
> HTH,
>
> Christian
>
>
> On 2013-11-12 09:17:14 +0000, Elhamlaoui Mahmoud said:
>
>> Hi,
>>
>> I have a question about UML that start tp bothers me lately,
>>
>> I have class Person which is a superclass of Man and Woman (for example)
>>
>> if you apply a Stereotype XXX to the Person, shouldn't the sereotype
>> be applied to the
>> subclasses?
>>
>> The some issue have been tackled here but without a clear response
>> http://stackoverflow.com/questions/13020608/uml-stereotypes-applied-to-class-inheritance-design-pattern
>>
>>
>> Thanks in advance
>
>
Re: inheritance of stereotypes in subclasses [message #1183024 is a reply to message #1182568] Tue, 12 November 2013 15:32 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

After reviewing the message and the
http://www.omg.org/issues/issue3210.txt discussion, there seems to be
almost unanimity that stereotype contributions are inherited. So much so
that it was considered obvious and so the clarification dealt with a
somewhat different issue.

Regards

Ed Willink

On 12/11/2013 09:17, Elhamlaoui Mahmoud wrote:
> The some issue have been tackled here but without a clear response
> http://stackoverflow.com/questions/13020608/uml-stereotypes-applied-to-class-inheritance-design-pattern
>
Re: inheritance of stereotypes in subclasses [message #1183043 is a reply to message #1182938] Tue, 12 November 2013 15:48 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Ed,

I don't understand. Stereotypes add features to elements of the UML
metamodel. They don't add features to, for example, classes to which
they are applied.

It's like saying that a Class B specializing an abstract Class A should
inherit A's abstract-ness. The "isAbstract" property is a feature of
the metamodel. Likewise, features of a stereotype applied to A are
features of the metamodel and cannot be expected to be inherited by B.
The generalization between B and A describes a relationship in the
modeled system; the stereotype describes properties of the model of the
system.

What am I missing?

cW


On 2013-11-12 14:22:37 +0000, Ed Willink said:

> Hi Christian
>
> That seems very wrong.
>
> If a stereotype adds features to a base class, those features must be
> accessible and so exist for the derived class instances.
>
> (Otherwise applying a stereotype to an abstract class would be totally
> redundant.)
>
> Regards
>
> Ed Willink
>
>
> On 12/11/2013 14:04, Christian W. Damus wrote:
>> Hi,
>>
>> No, stereotype applications are not inherited by specializing
>> classifiers. A stereotype extends the structure of the UML metamodel,
>> letting you specify domain-specific attributes on elements in a UML
>> model. Stereotypes do not alter the run-time semantics of the system
>> being modeled; they only enrich the modeling language.
>>
>> That is, unless you actually specify additional run-time semantics on a
>> stereotype. For example, for your case, you could add an OCL
>> constraint to the XXX stereotype that, if it has a base_Class (i.e., is
>> applied to a class), all classes specializing that class must also have
>> an XXX extension (i.e., have the stereotype applied). But, it would be
>> a special tool that understands the definition of such a constraint and
>> applies the stereotype to all subclasses for you! At best it would be
>> included in model validation to warn you of missing XXXes. But, even
>> then, each stereotype application would have its own distinct values
>> for the stereotype's properties, and there is no inheritance of
>> stereotype attributes. If you need to ensure consistency of some kind
>> in the stereotype properties, you'd be adding constraints again.
>>
>> HTH,
>>
>> Christian
>>
>>
>> On 2013-11-12 09:17:14 +0000, Elhamlaoui Mahmoud said:
>>
>>> Hi,
>>>
>>> I have a question about UML that start tp bothers me lately,
>>>
>>> I have class Person which is a superclass of Man and Woman (for example)
>>>
>>> if you apply a Stereotype XXX to the Person, shouldn't the sereotype be
>>> applied to the
>>> subclasses?
>>>
>>> The some issue have been tackled here but without a clear response
>>> http://stackoverflow.com/questions/13020608/uml-stereotypes-applied-to-class-inheritance-design-pattern
>>>
>>>
>>> Thanks in advance
Re: inheritance of stereotypes in subclasses [message #1183062 is a reply to message #1183043] Tue, 12 November 2013 16:01 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Christian

Stereotype X directly adds the extension_X 'property', which should be
unconditionally visible in OCL in all derived classes.

Stereotype X may indirectly add the extension_X.something property,
which should also be unconditionally visible in OCL for all derived classes.

OK, the OCL specification is 100% free of any reference to 'stereotype'
in this context, so we have only common sense to go on.

[The draft OCL 2.5 RFP, which I submitted for discussion yesterday
requires OCL 2.5 to explain how OCL works with stereotypes.]

Regards

Ed



On 12/11/2013 15:48, Christian W. Damus wrote:
> Hi, Ed,
>
> I don't understand. Stereotypes add features to elements of the UML
> metamodel. They don't add features to, for example, classes to which
> they are applied.
>
> It's like saying that a Class B specializing an abstract Class A
> should inherit A's abstract-ness. The "isAbstract" property is a
> feature of the metamodel. Likewise, features of a stereotype applied
> to A are features of the metamodel and cannot be expected to be
> inherited by B. The generalization between B and A describes a
> relationship in the modeled system; the stereotype describes
> properties of the model of the system.
>
> What am I missing?
>
> cW
>
>
> On 2013-11-12 14:22:37 +0000, Ed Willink said:
>
>> Hi Christian
>>
>> That seems very wrong.
>>
>> If a stereotype adds features to a base class, those features must be
>> accessible and so exist for the derived class instances.
>>
>> (Otherwise applying a stereotype to an abstract class would be
>> totally redundant.)
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 12/11/2013 14:04, Christian W. Damus wrote:
>>> Hi,
>>>
>>> No, stereotype applications are not inherited by specializing
>>> classifiers. A stereotype extends the structure of the UML
>>> metamodel, letting you specify domain-specific attributes on
>>> elements in a UML model. Stereotypes do not alter the run-time
>>> semantics of the system being modeled; they only enrich the modeling
>>> language.
>>>
>>> That is, unless you actually specify additional run-time semantics
>>> on a stereotype. For example, for your case, you could add an OCL
>>> constraint to the XXX stereotype that, if it has a base_Class (i.e.,
>>> is applied to a class), all classes specializing that class must
>>> also have an XXX extension (i.e., have the stereotype applied).
>>> But, it would be a special tool that understands the definition of
>>> such a constraint and applies the stereotype to all subclasses for
>>> you! At best it would be included in model validation to warn you
>>> of missing XXXes. But, even then, each stereotype application would
>>> have its own distinct values for the stereotype's properties, and
>>> there is no inheritance of stereotype attributes. If you need to
>>> ensure consistency of some kind in the stereotype properties, you'd
>>> be adding constraints again.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> On 2013-11-12 09:17:14 +0000, Elhamlaoui Mahmoud said:
>>>
>>>> Hi,
>>>>
>>>> I have a question about UML that start tp bothers me lately,
>>>>
>>>> I have class Person which is a superclass of Man and Woman (for
>>>> example)
>>>>
>>>> if you apply a Stereotype XXX to the Person, shouldn't the
>>>> sereotype be applied to the
>>>> subclasses?
>>>>
>>>> The some issue have been tackled here but without a clear response
>>>> http://stackoverflow.com/questions/13020608/uml-stereotypes-applied-to-class-inheritance-design-pattern
>>>>
>>>>
>>>> Thanks in advance
>
>
Re: inheritance of stereotypes in subclasses [message #1183107 is a reply to message #1183062] Tue, 12 November 2013 16:41 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Ed,

Yes, stereotypes add non-navigable extension-end properties to the
metaclasses that they are applicable to. But these are defined at a
different meta-level than the properties of classes in a UML model,
which are inheritable by the semantics of generalization, on the model
level.

Given a profile P containing stereotype X that extends uml::Class and a
model M having P applied containing classes A and B where B has a
generalization relationship with A. In the context of M, the
uml::Class metaclass has a non-navigable extension_X property simply by
virtue of the the profile P being applied to M. So, classes A and B
(instances of the Class metaclass) have non-navigable slots for
extension_X.

Now, I apply stereotype X to class A by setting A's Class::extension_X
meta-property to instance x of X. If Class B were to inherit the value
of extension_X from A (remembering still that extension_X is on a
different metalevel than the features of class A defined in the model)
then it would now also have the value x in extension_X. But that's a
contradiction because the multiplicity of extension_X's opposite end
X::base_Class is [0..1]; x cannot extend both class A and class B!

Note that there *is* inheritance of the extension end extension_X from
this example. The Component metaclass, a subclass of Class, inherits
this extension end. So, the stereotype X is applicable to components
as well as to classes in the model. But this is, again, in the
metamodel, not in the model.

Which is all to say that I think we're mixing meta-levels because
uml::Class happens to have a a dual role as a "class" in the UML
metamodel, participating in the Stereotype extension metamodel, and as
the metaclass for "classes" in a UML model.

Am I making sense?

cW

On 2013-11-12 16:01:45 +0000, Ed Willink said:

> Hi Christian
>
> Stereotype X directly adds the extension_X 'property', which should be
> unconditionally visible in OCL in all derived classes.
>
> Stereotype X may indirectly add the extension_X.something property,
> which should also be unconditionally visible in OCL for all derived
> classes.
>
> OK, the OCL specification is 100% free of any reference to 'stereotype'
> in this context, so we have only common sense to go on.
>
> [The draft OCL 2.5 RFP, which I submitted for discussion yesterday
> requires OCL 2.5 to explain how OCL works with stereotypes.]
>
> Regards
>
> Ed
>
>
>
> On 12/11/2013 15:48, Christian W. Damus wrote:
>> Hi, Ed,
>>
>> I don't understand. Stereotypes add features to elements of the UML
>> metamodel. They don't add features to, for example, classes to which
>> they are applied.
>>
>> It's like saying that a Class B specializing an abstract Class A should
>> inherit A's abstract-ness. The "isAbstract" property is a feature of
>> the metamodel. Likewise, features of a stereotype applied to A are
>> features of the metamodel and cannot be expected to be inherited by B.
>> The generalization between B and A describes a relationship in the
>> modeled system; the stereotype describes properties of the model of the
>> system.
>>
>> What am I missing?
>>
>> cW
>>
>>
>> On 2013-11-12 14:22:37 +0000, Ed Willink said:
>>
>>> Hi Christian
>>>
>>> That seems very wrong.
>>>
>>> If a stereotype adds features to a base class, those features must be
>>> accessible and so exist for the derived class instances.
>>>
>>> (Otherwise applying a stereotype to an abstract class would be totally
>>> redundant.)
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>>
>>> On 12/11/2013 14:04, Christian W. Damus wrote:
>>>> Hi,
>>>>
>>>> No, stereotype applications are not inherited by specializing
>>>> classifiers. A stereotype extends the structure of the UML metamodel,
>>>> letting you specify domain-specific attributes on elements in a UML
>>>> model. Stereotypes do not alter the run-time semantics of the system
>>>> being modeled; they only enrich the modeling language.
>>>>
>>>> That is, unless you actually specify additional run-time semantics on a
>>>> stereotype. For example, for your case, you could add an OCL
>>>> constraint to the XXX stereotype that, if it has a base_Class (i.e., is
>>>> applied to a class), all classes specializing that class must also have
>>>> an XXX extension (i.e., have the stereotype applied). But, it would be
>>>> a special tool that understands the definition of such a constraint and
>>>> applies the stereotype to all subclasses for you! At best it would be
>>>> included in model validation to warn you of missing XXXes. But, even
>>>> then, each stereotype application would have its own distinct values
>>>> for the stereotype's properties, and there is no inheritance of
>>>> stereotype attributes. If you need to ensure consistency of some kind
>>>> in the stereotype properties, you'd be adding constraints again.
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 2013-11-12 09:17:14 +0000, Elhamlaoui Mahmoud said:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a question about UML that start tp bothers me lately,
>>>>>
>>>>> I have class Person which is a superclass of Man and Woman (for example)
>>>>>
>>>>> if you apply a Stereotype XXX to the Person, shouldn't the sereotype be
>>>>> applied to the
>>>>> subclasses?
>>>>>
>>>>> The some issue have been tackled here but without a clear response
>>>>> http://stackoverflow.com/questions/13020608/uml-stereotypes-applied-to-class-inheritance-design-pattern
>>>>>
>>>>>
>>>>> Thanks in advance
Re: inheritance of stereotypes in subclasses [message #1183189 is a reply to message #1183107] Tue, 12 November 2013 17:55 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Christian

There are no unnavigable properties in OCL, just an implementation
option to not support them.

IMHO the concept of navigating a Property at the wrong meta-level is a
complete nonsense.

OCL 2.2 introduced the concept of static properties. Or rather it
allowed the 'static' keyword to be used when defining Complete OCL
Operations and Properties. No further insight into the semantics was
given other than intuitive UML alignment.

My proposed solution to this mess is to make static properties class
properties that can be accessed without a self (just as in Java or C++).

Then the process of loading a UML metamodel for use by OCL is required
to reify the M2 stereotypes as extension_XXX and base_YYY static
properties at M1; no cross-level navigation. Since extension_XXX is a
static property, there is no problem in both A::extension_XXX and
B::extension_XXX existing.

Regards

Ed

On 12/11/2013 16:41, Christian W. Damus wrote:
> Hi, Ed,
>
> Yes, stereotypes add non-navigable extension-end properties to the
> metaclasses that they are applicable to. But these are defined at a
> different meta-level than the properties of classes in a UML model,
> which are inheritable by the semantics of generalization, on the model
> level.
>
> Given a profile P containing stereotype X that extends uml::Class and
> a model M having P applied containing classes A and B where B has a
> generalization relationship with A. In the context of M, the
> uml::Class metaclass has a non-navigable extension_X property simply
> by virtue of the the profile P being applied to M. So, classes A and
> B (instances of the Class metaclass) have non-navigable slots for
> extension_X.
>
> Now, I apply stereotype X to class A by setting A's Class::extension_X
> meta-property to instance x of X. If Class B were to inherit the
> value of extension_X from A (remembering still that extension_X is on
> a different metalevel than the features of class A defined in the
> model) then it would now also have the value x in extension_X. But
> that's a contradiction because the multiplicity of extension_X's
> opposite end X::base_Class is [0..1]; x cannot extend both class A and
> class B!
>
> Note that there *is* inheritance of the extension end extension_X from
> this example. The Component metaclass, a subclass of Class, inherits
> this extension end. So, the stereotype X is applicable to components
> as well as to classes in the model. But this is, again, in the
> metamodel, not in the model.
>
> Which is all to say that I think we're mixing meta-levels because
> uml::Class happens to have a a dual role as a "class" in the UML
> metamodel, participating in the Stereotype extension metamodel, and as
> the metaclass for "classes" in a UML model.
>
> Am I making sense?
>
> cW
>
> On 2013-11-12 16:01:45 +0000, Ed Willink said:
>
>> Hi Christian
>>
>> Stereotype X directly adds the extension_X 'property', which should
>> be unconditionally visible in OCL in all derived classes.
>>
>> Stereotype X may indirectly add the extension_X.something property,
>> which should also be unconditionally visible in OCL for all derived
>> classes.
>>
>> OK, the OCL specification is 100% free of any reference to
>> 'stereotype' in this context, so we have only common sense to go on.
>>
>> [The draft OCL 2.5 RFP, which I submitted for discussion yesterday
>> requires OCL 2.5 to explain how OCL works with stereotypes.]
>>
>> Regards
>>
>> Ed
>>
>>
>>
>> On 12/11/2013 15:48, Christian W. Damus wrote:
>>> Hi, Ed,
>>>
>>> I don't understand. Stereotypes add features to elements of the UML
>>> metamodel. They don't add features to, for example, classes to
>>> which they are applied.
>>>
>>> It's like saying that a Class B specializing an abstract Class A
>>> should inherit A's abstract-ness. The "isAbstract" property is a
>>> feature of the metamodel. Likewise, features of a stereotype
>>> applied to A are features of the metamodel and cannot be expected to
>>> be inherited by B. The generalization between B and A describes a
>>> relationship in the modeled system; the stereotype describes
>>> properties of the model of the system.
>>>
>>> What am I missing?
>>>
>>> cW
>>>
>>>
>>> On 2013-11-12 14:22:37 +0000, Ed Willink said:
>>>
>>>> Hi Christian
>>>>
>>>> That seems very wrong.
>>>>
>>>> If a stereotype adds features to a base class, those features must
>>>> be accessible and so exist for the derived class instances.
>>>>
>>>> (Otherwise applying a stereotype to an abstract class would be
>>>> totally redundant.)
>>>>
>>>> Regards
>>>>
>>>> Ed Willink
>>>>
>>>>
>>>> On 12/11/2013 14:04, Christian W. Damus wrote:
>>>>> Hi,
>>>>>
>>>>> No, stereotype applications are not inherited by specializing
>>>>> classifiers. A stereotype extends the structure of the UML
>>>>> metamodel, letting you specify domain-specific attributes on
>>>>> elements in a UML model. Stereotypes do not alter the run-time
>>>>> semantics of the system being modeled; they only enrich the
>>>>> modeling language.
>>>>>
>>>>> That is, unless you actually specify additional run-time semantics
>>>>> on a stereotype. For example, for your case, you could add an OCL
>>>>> constraint to the XXX stereotype that, if it has a base_Class
>>>>> (i.e., is applied to a class), all classes specializing that class
>>>>> must also have an XXX extension (i.e., have the stereotype
>>>>> applied). But, it would be a special tool that understands the
>>>>> definition of such a constraint and applies the stereotype to all
>>>>> subclasses for you! At best it would be included in model
>>>>> validation to warn you of missing XXXes. But, even then, each
>>>>> stereotype application would have its own distinct values for the
>>>>> stereotype's properties, and there is no inheritance of stereotype
>>>>> attributes. If you need to ensure consistency of some kind in the
>>>>> stereotype properties, you'd be adding constraints again.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> On 2013-11-12 09:17:14 +0000, Elhamlaoui Mahmoud said:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have a question about UML that start tp bothers me lately,
>>>>>>
>>>>>> I have class Person which is a superclass of Man and Woman (for
>>>>>> example)
>>>>>>
>>>>>> if you apply a Stereotype XXX to the Person, shouldn't the
>>>>>> sereotype be applied to the
>>>>>> subclasses?
>>>>>>
>>>>>> The some issue have been tackled here but without a clear response
>>>>>> http://stackoverflow.com/questions/13020608/uml-stereotypes-applied-to-class-inheritance-design-pattern
>>>>>>
>>>>>>
>>>>>> Thanks in advance
>
>
Re: inheritance of stereotypes in subclasses [message #1183281 is a reply to message #1183189] Tue, 12 November 2013 19:18 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Ed,

But, how can stereotypes possibly be construed as types accessible from
static properties in the model? Stereotypes function as
pseudo-metaclasses. This would be akin to making a reference to a
profile or a diagram available in the model as representing some thing
in the run-time system. What is a stereotype supposed to describe in
the run-time system when it is the type of properties of classes in the
model, which in turn describe attributes of objects in the run-time
system?

My entire point is that cross-level navigation is nonsense, which is
what the original poster expected and what you propose to accomplish by
promoting extension ends in the metamodel to static properties in the
model.

cW


On 2013-11-12 17:55:17 +0000, Ed Willink said:

> Hi Christian
>
> There are no unnavigable properties in OCL, just an implementation
> option to not support them.
>
> IMHO the concept of navigating a Property at the wrong meta-level is a
> complete nonsense.
>
> OCL 2.2 introduced the concept of static properties. Or rather it
> allowed the 'static' keyword to be used when defining Complete OCL
> Operations and Properties. No further insight into the semantics was
> given other than intuitive UML alignment.
>
> My proposed solution to this mess is to make static properties class
> properties that can be accessed without a self (just as in Java or C++).
>
> Then the process of loading a UML metamodel for use by OCL is required
> to reify the M2 stereotypes as extension_XXX and base_YYY static
> properties at M1; no cross-level navigation. Since extension_XXX is a
> static property, there is no problem in both A::extension_XXX and
> B::extension_XXX existing.
>
> Regards
>
> Ed
>
> On 12/11/2013 16:41, Christian W. Damus wrote:
>> Hi, Ed,
>>
>> Yes, stereotypes add non-navigable extension-end properties to the
>> metaclasses that they are applicable to. But these are defined at a
>> different meta-level than the properties of classes in a UML model,
>> which are inheritable by the semantics of generalization, on the model
>> level.
>>
>> Given a profile P containing stereotype X that extends uml::Class and a
>> model M having P applied containing classes A and B where B has a
>> generalization relationship with A. In the context of M, the
>> uml::Class metaclass has a non-navigable extension_X property simply by
>> virtue of the the profile P being applied to M. So, classes A and B
>> (instances of the Class metaclass) have non-navigable slots for
>> extension_X.
>>
>> Now, I apply stereotype X to class A by setting A's Class::extension_X
>> meta-property to instance x of X. If Class B were to inherit the value
>> of extension_X from A (remembering still that extension_X is on a
>> different metalevel than the features of class A defined in the model)
>> then it would now also have the value x in extension_X. But that's a
>> contradiction because the multiplicity of extension_X's opposite end
>> X::base_Class is [0..1]; x cannot extend both class A and class B!
>>
>> Note that there *is* inheritance of the extension end extension_X from
>> this example. The Component metaclass, a subclass of Class, inherits
>> this extension end. So, the stereotype X is applicable to components
>> as well as to classes in the model. But this is, again, in the
>> metamodel, not in the model.
>>
>> Which is all to say that I think we're mixing meta-levels because
>> uml::Class happens to have a a dual role as a "class" in the UML
>> metamodel, participating in the Stereotype extension metamodel, and as
>> the metaclass for "classes" in a UML model.
>>
>> Am I making sense?
>>
>> cW
>>
>> On 2013-11-12 16:01:45 +0000, Ed Willink said:

-------- 8< --------
Re: inheritance of stereotypes in subclasses [message #1184057 is a reply to message #1183281] Wed, 13 November 2013 07:32 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Christian

Yes, static propertties are a stupid red herring and may be why I've got
in a mess with https://bugs.eclipse.org/bugs/show_bug.cgi?id=420732.

The stereotype features typically defined at M2, are installed for use
at M1.

So consider the Internationalized profile, with a Nationalized abstract
stereotype for Class and derived English, French non-abstract stereotypes.

Apply this profile to a model containing Car and derived EnglishCar,
FrenchCar classes to get <<Nationalized>>Car, <<English>>EnglishCar,
<<French>>FrenchCar.

At M2 I should be able to write the constraint that exactly one
non-abstract Nationalized stereotype is applied.

context Nationalized
base_Class.extension_Nationalized->reject(abstract)->size() = 1

[Perhaps the ->reject(abstract) is unnecessary since perhaps abstract
stereotypes are navigable but not created.]

This should fail on the further derivation of Car

<<English,French>>AngloFrenchCar

If English defines a "name" property and French defines a "nom"
property, then at M1 I may write

context FrenchCar
....self.extension_French.nom... -- safe
....self.extension_English.name... -- unsafe (but only statically
detectable in a closed world)

context Car
....self.extension_French.nom... -- unsafe since
self.extension_French may be null
....self.extension_English.name... -- unsafe since
self.extension_English may be null
....self.extension_Nationalized->selectByType(English)->any(true).name...
-- unsafe since any(true) may return invalid for none

If Nationalized defines a "nationality" property then since EnglishCar
has the direct application of <<English>> and the inherited application
of <<Nationalized>>, EnglishCar has two extensions and so two "nationality"

context EnglishCar
....self.extension_Nationalized.nationality... -- error abstract
stereotype
....self.extension_English.nationality... -- safe

IMHO An OCL user should never need to use the type-unsafe
getAppliedStereotypes() since the type-safe extension_XXX and base_YYY
should provide better capabilities.

Back to the original question:
On 12/11/2013 09:17, Elhamlaoui Mahmoud wrote:
> I have class Person which is a superclass of Man and Woman (for example)
>
> if you apply a Stereotype XXX to the Person, shouldn't the sereotype
> be applied to the
> subclasses?
No. The stereotype XXX should not be applied to Man or Woman, since that
would be double application. The application to Person should be inherited.

And revisiting
On 12/11/2013 15:48, Christian W. Damus wrote:
> I don't understand. Stereotypes add features to elements of the UML
> metamodel. They don't add features to, for example, classes to which
> they are applied.
Yes they do. Are you getting confused with the Ecore profiles that are
defined at M3 and so contribute e.g. EStructuralFeature.volatile at M1?

Regards

Ed



On 12/11/2013 19:18, Christian W. Damus wrote:
> Hi, Ed,
>
> But, how can stereotypes possibly be construed as types accessible
> from static properties in the model? Stereotypes function as
> pseudo-metaclasses. This would be akin to making a reference to a
> profile or a diagram available in the model as representing some thing
> in the run-time system. What is a stereotype supposed to describe in
> the run-time system when it is the type of properties of classes in
> the model, which in turn describe attributes of objects in the
> run-time system?
>
> My entire point is that cross-level navigation is nonsense, which is
> what the original poster expected and what you propose to accomplish
> by promoting extension ends in the metamodel to static properties in
> the model.
>
> cW
>
>
> On 2013-11-12 17:55:17 +0000, Ed Willink said:
>
>> Hi Christian
>>
>> There are no unnavigable properties in OCL, just an implementation
>> option to not support them.
>>
>> IMHO the concept of navigating a Property at the wrong meta-level is
>> a complete nonsense.
>>
>> OCL 2.2 introduced the concept of static properties. Or rather it
>> allowed the 'static' keyword to be used when defining Complete OCL
>> Operations and Properties. No further insight into the semantics was
>> given other than intuitive UML alignment.
>>
>> My proposed solution to this mess is to make static properties class
>> properties that can be accessed without a self (just as in Java or C++).
>>
>> Then the process of loading a UML metamodel for use by OCL is
>> required to reify the M2 stereotypes as extension_XXX and base_YYY
>> static properties at M1; no cross-level navigation. Since
>> extension_XXX is a static property, there is no problem in both
>> A::extension_XXX and B::extension_XXX existing.
>>
>> Regards
>>
>> Ed
>>
>> On 12/11/2013 16:41, Christian W. Damus wrote:
>>> Hi, Ed,
>>>
>>> Yes, stereotypes add non-navigable extension-end properties to the
>>> metaclasses that they are applicable to. But these are defined at a
>>> different meta-level than the properties of classes in a UML model,
>>> which are inheritable by the semantics of generalization, on the
>>> model level.
>>>
>>> Given a profile P containing stereotype X that extends uml::Class
>>> and a model M having P applied containing classes A and B where B
>>> has a generalization relationship with A. In the context of M, the
>>> uml::Class metaclass has a non-navigable extension_X property simply
>>> by virtue of the the profile P being applied to M. So, classes A
>>> and B (instances of the Class metaclass) have non-navigable slots
>>> for extension_X.
>>>
>>> Now, I apply stereotype X to class A by setting A's
>>> Class::extension_X meta-property to instance x of X. If Class B
>>> were to inherit the value of extension_X from A (remembering still
>>> that extension_X is on a different metalevel than the features of
>>> class A defined in the model) then it would now also have the value
>>> x in extension_X. But that's a contradiction because the
>>> multiplicity of extension_X's opposite end X::base_Class is [0..1];
>>> x cannot extend both class A and class B!
>>>
>>> Note that there *is* inheritance of the extension end extension_X
>>> from this example. The Component metaclass, a subclass of Class,
>>> inherits this extension end. So, the stereotype X is applicable to
>>> components as well as to classes in the model. But this is, again,
>>> in the metamodel, not in the model.
>>>
>>> Which is all to say that I think we're mixing meta-levels because
>>> uml::Class happens to have a a dual role as a "class" in the UML
>>> metamodel, participating in the Stereotype extension metamodel, and
>>> as the metaclass for "classes" in a UML model.
>>>
>>> Am I making sense?
>>>
>>> cW
>>>
>>> On 2013-11-12 16:01:45 +0000, Ed Willink said:
>
> -------- 8< --------
>
Re: inheritance of stereotypes in subclasses [message #1184528 is a reply to message #1184057] Wed, 13 November 2013 14:13 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi, Ed,

Thanks for your response. See some further replies in-line, below.

cW

On 2013-11-13 07:32:10 +0000, Ed Willink said:

> Hi Christian
>
> Yes, static propertties are a stupid red herring and may be why I've
> got in a mess with https://bugs.eclipse.org/bugs/show_bug.cgi?id=420732.

It seems the me that this is a relatively simple case: the inheritance
is in the Steretoypes, not in the Classes in the model that apply them.
If the Stereotypes in the bugzilla are defined thus:

Internationalized
base_Class : Class -- extension end

InEnglish --|> Internationalized
InFrench --|> Internationalized
InGerman --|> Internationalized

then these three stereotypes all inherit the same metaclass extension
and the base_Class end. They all use the same property to effect
"stereotype application". Therefore, indeed, you can write a
constraint like

context Internationalized
inv : base_Class.extension_Internationalized->size() <= 1


> The stereotype features typically defined at M2, are installed for use at M1.

This is the bit that I don't get. What does 'installed for use' mean?
That they can be given values on M2 instances in the M1 model? If so,
then yes. Stereotype attributes are functionally equivalent to
attributes of the metaclasses in the UML metamodel.


> So consider the Internationalized profile, with a Nationalized abstract
> stereotype for Class and derived English, French non-abstract
> stereotypes.
>
> Apply this profile to a model containing Car and derived EnglishCar,
> FrenchCar classes to get <<Nationalized>>Car, <<English>>EnglishCar,
> <<French>>FrenchCar.
>
> At M2 I should be able to write the constraint that exactly one
> non-abstract Nationalized stereotype is applied.
>
> context Nationalized
> base_Class.extension_Nationalized->reject(abstract)->size() = 1
>
> [Perhaps the ->reject(abstract) is unnecessary since perhaps abstract
> stereotypes are navigable but not created.]
>
> This should fail on the further derivation of Car
>
> <<English,French>>AngloFrenchCar

It would, exactly as specified. Doesn't it? If not, then that's only
a bug in the implementation of the navigation of the (non-navigable)
extension_Nationalized end.

>
> If English defines a "name" property and French defines a "nom"
> property, then at M1 I may write
>
> context FrenchCar
> ...self.extension_French.nom... -- safe
> ...self.extension_English.name... -- unsafe (but only statically
> detectable in a closed world)

No. FrenchCar is a class in the M1 modeling level. extension_French
is a property in the M2 metamodeling level. This is as nonsensical as

context FrenchCar
inv: not self.isAbstract() implies self.general->exists(isAbstract)

in which a constraint tries to access "meta-"attributes of the Class
metaclass. The extension ends similarly are meta-attributes. I could
imagine that something like this would make more sense:

context FrenchCar
inv: self.oclType().oclAsType(uml::Class).extension_French.nom...

but I don't know how this could be translated to code in the run-time system.

What the extension ends are not is M1 properties in the namespace of a
class that has a stereotype applied. Consider that the FrenchCar class
in the M1 model owns a bunch of properties in its namespace:

class FrenchCar {
property pneu : Tyre [4..5]
property vitre : Window [4..6]
... etc.
}

In the run-time system, a FrenchCar instance can contain instances of
Tyres and Windows. There is no instance of the InFrench stereotype in
the run-time system, and no implementation of the extension_French end.


> context Car
> ...self.extension_French.nom... -- unsafe since
> self.extension_French may be null
> ...self.extension_English.name... -- unsafe since
> self.extension_English may be null
> ...self.extension_Nationalized->selectByType(English)->any(true).name...
> -- unsafe since any(true) may return invalid for none
>
> If Nationalized defines a "nationality" property then since EnglishCar
> has the direct application of <<English>> and the inherited application
> of <<Nationalized>>, EnglishCar has two extensions and so two
> "nationality"

I don't think so. The Car class has an applied stereotype having a
value for the nationality property. The EnglishCar class also has an
applied stereotype having a value for the nationality property. But
these stereotype applications are distinct; no stereotype application
has two nationalities. And certainly, neither Car not EnglishCar has a
nationality property in its namespace.


> context EnglishCar
> ...self.extension_Nationalized.nationality... -- error abstract stereotype
> ...self.extension_English.nationality... -- safe
>
> IMHO An OCL user should never need to use the type-unsafe
> getAppliedStereotypes() since the type-safe extension_XXX and base_YYY
> should provide better capabilities.

Quite agreed. The extension_XXX properties are much friendlier, but
they are M2 concepts just like getAppliedStereotypes(). They don't
exist in M1.


> Back to the original question:
> On 12/11/2013 09:17, Elhamlaoui Mahmoud wrote:
>> I have class Person which is a superclass of Man and Woman (for example)
>>
>> if you apply a Stereotype XXX to the Person, shouldn't the sereotype be
>> applied to the
>> subclasses?
> No. The stereotype XXX should not be applied to Man or Woman, since
> that would be double application. The application to Person should be
> inherited.

Which to me, still, makes as much sense as inheriting the value of
uml::Class::isAbstract, uml::Class::general, and every other
meta-attribute from Person ...


> And revisiting
> On 12/11/2013 15:48, Christian W. Damus wrote:
>> I don't understand. Stereotypes add features to elements of the UML
>> metamodel. They don't add features to, for example, classes to which
>> they are applied.
> Yes they do. Are you getting confused with the Ecore profiles that are
> defined at M3 and so contribute e.g. EStructuralFeature.volatile at M1?

ecore::EStructuralFeature::volatile is not contributed at M1. It's
contributed at M2. It is effectively a peer of
uml::TypedElement::type, uml::MultiplicityElement::upper, etc.

I don't understand the assertion that the properties of a stereotype
are added to the namespace of a Class that the stereotype is applied
to, as members of that Class in the M1 model.

Where would the attributes of a stereotype applied to a Package go?
Package namespaces don't include properties. What about a stereotype
of a Dependency? Classes are not different from these elements are far
as stereotype extension is concerned.


>
> Regards
>
> Ed
>
>
>
> On 12/11/2013 19:18, Christian W. Damus wrote:
>> Hi, Ed,
>>
>> But, how can stereotypes possibly be construed as types accessible from
>> static properties in the model? Stereotypes function as
>> pseudo-metaclasses. This would be akin to making a reference to a
>> profile or a diagram available in the model as representing some thing
>> in the run-time system. What is a stereotype supposed to describe in
>> the run-time system when it is the type of properties of classes in the
>> model, which in turn describe attributes of objects in the run-time
>> system?
>>
>> My entire point is that cross-level navigation is nonsense, which is
>> what the original poster expected and what you propose to accomplish by
>> promoting extension ends in the metamodel to static properties in the
>> model.
>>
>> cW
>>
>>
>> On 2013-11-12 17:55:17 +0000, Ed Willink said:
>>
>>> Hi Christian
>>>
>>> There are no unnavigable properties in OCL, just an implementation
>>> option to not support them.
>>>
>>> IMHO the concept of navigating a Property at the wrong meta-level is a
>>> complete nonsense.
>>>
>>> OCL 2.2 introduced the concept of static properties. Or rather it
>>> allowed the 'static' keyword to be used when defining Complete OCL
>>> Operations and Properties. No further insight into the semantics was
>>> given other than intuitive UML alignment.
>>>
>>> My proposed solution to this mess is to make static properties class
>>> properties that can be accessed without a self (just as in Java or C++).
>>>
>>> Then the process of loading a UML metamodel for use by OCL is required
>>> to reify the M2 stereotypes as extension_XXX and base_YYY static
>>> properties at M1; no cross-level navigation. Since extension_XXX is a
>>> static property, there is no problem in both A::extension_XXX and
>>> B::extension_XXX existing.
>>>
>>> Regards
>>>
>>> Ed
>>>
>>> On 12/11/2013 16:41, Christian W. Damus wrote:
>>>> Hi, Ed,
>>>>
>>>> Yes, stereotypes add non-navigable extension-end properties to the
>>>> metaclasses that they are applicable to. But these are defined at a
>>>> different meta-level than the properties of classes in a UML model,
>>>> which are inheritable by the semantics of generalization, on the model
>>>> level.
>>>>
>>>> Given a profile P containing stereotype X that extends uml::Class and a
>>>> model M having P applied containing classes A and B where B has a
>>>> generalization relationship with A. In the context of M, the
>>>> uml::Class metaclass has a non-navigable extension_X property simply by
>>>> virtue of the the profile P being applied to M. So, classes A and B
>>>> (instances of the Class metaclass) have non-navigable slots for
>>>> extension_X.
>>>>
>>>> Now, I apply stereotype X to class A by setting A's Class::extension_X
>>>> meta-property to instance x of X. If Class B were to inherit the value
>>>> of extension_X from A (remembering still that extension_X is on a
>>>> different metalevel than the features of class A defined in the model)
>>>> then it would now also have the value x in extension_X. But that's a
>>>> contradiction because the multiplicity of extension_X's opposite end
>>>> X::base_Class is [0..1]; x cannot extend both class A and class B!
>>>>
>>>> Note that there *is* inheritance of the extension end extension_X from
>>>> this example. The Component metaclass, a subclass of Class, inherits
>>>> this extension end. So, the stereotype X is applicable to components
>>>> as well as to classes in the model. But this is, again, in the
>>>> metamodel, not in the model.
>>>>
>>>> Which is all to say that I think we're mixing meta-levels because
>>>> uml::Class happens to have a a dual role as a "class" in the UML
>>>> metamodel, participating in the Stereotype extension metamodel, and as
>>>> the metaclass for "classes" in a UML model.
>>>>
>>>> Am I making sense?
>>>>
>>>> cW
>>>>
>>>> On 2013-11-12 16:01:45 +0000, Ed Willink said:
>>
>> -------- 8< --------
Re: inheritance of stereotypes in subclasses [message #1184748 is a reply to message #1184528] Wed, 13 November 2013 17:08 Go to previous messageGo to next message
Elhamlaoui Mahmoud is currently offline Elhamlaoui MahmoudFriend
Messages: 268
Registered: March 2010
Senior Member
Hi,
Thanks Ed and christian for your responses.
It seems that its a controversy problem.

Sincerly
Re: inheritance of stereotypes in subclasses [message #1184849 is a reply to message #1184748] Wed, 13 November 2013 18:44 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Yep! It would certainly seem so.

I hope Ed has enjoyed the discussion as much as I. Doubtless there is
something quite basic that I am misunderstanding. ;-)

cW


On 2013-11-13 17:08:00 +0000, Elhamlaoui Mahmoud said:

> Hi,
> Thanks Ed and christian for your responses.
> It seems that its a controversy problem.
> Sincerly
Re: inheritance of stereotypes in subclasses [message #1188141 is a reply to message #1184849] Fri, 15 November 2013 13:18 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Christian

On 13/11/2013 18:44, Christian W. Damus wrote:
> I hope Ed has enjoyed the discussion as much as I. Doubtless there is
> something quite basic that I am misunderstanding. ;-)
It's always helpful, though sometimes a bit embarrassing, to have one's
shaky ideas challenged.

You got me totally confused, so let me correct my earlier email in which
I wrongly suggested that stereotypes at M2 contributed equivalent
non-static properties at M1.

On 13/11/2013 07:32, Ed Willink wrote:
> Hi Christian
>
> Yes, static propertties are a stupid red herring and may be why I've
> got in a mess with https://bugs.eclipse.org/bugs/show_bug.cgi?id=420732.
No. Static properties can be a useful way to access class-features
without needing to use reflection.

So at M1, writing

context Car
....self.extension_French.nom...

is a non-reflective equivalent of the fully reflective and static type
preserving

....self.oclType().extension_French.nom...

"nom" is a class feature so all FrenchCar's share the same value
assigned to the "nom".

NB. oclType() is differently non-reflective in OCL 2.0, 2.2 making
oclType().extension_XXXX unuseable until/if OCL 2.5 introduces fuller
reflection.
> The stereotype features typically defined at M2, are installed for use
> at M1.
The M2 features are accessible from M1 by the M1toM2 static properties
such as extension_French.

Regards

Ed Willink
Previous Topic:Register a Profile programmatically
Next Topic:Binary serialization broken with UML2 Kepler ?
Goto Forum:
  


Current Time: Thu Mar 28 23:43:57 GMT 2024

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

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

Back to the top