Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: Paolo F Cantoni on May 09, 2005, 07:40:25 am
-
The UML 2.0 specification appears to be silent on the matter,
but why aren't stereotypes inherited along with attributes and
operations? ???
In fact, the default filter for stereotypes should be: show all
base class stereotypes
While we're at it, shouldn't stereotypes have visibility like
attributes? :-)
From the UML 2.0 Glossary:
[size=13]Stereotype:[/size]
A class that defines how an existing metaclass (or
stereotype) may be extended, and enables the use of platform or
domain specific terminology or notation in addition to the ones
used for the extended metaclass. Certain stereotypes are
predefined in the UML, others may be user defined. Stereotypes
are one of the extensibility mechanisms in UML.
While, the definition is correct, the implications of the
definition are not obvious, in my view... While the stereotype
is defining the extension of the metaclass (or stereotype), you
apply the denomination to an instance of the class... That is,
although the stereotype «enumeration» extends class, all the
definition says its that you may apply the stereotype
«enumeration» to a class. Not every class is an
«enumeration». Now supposing I make class X an
«enumeration», then it seems to me from first principles, that
all subclasses of X must also be «enumeration»s.
In addition, in my verbaliser technology, that I have
implemented in Rational Rose, I explicitly inherit stereotypes
and I have found it most useful in determining the validity of
the model. After you enforce stereotype inheritance, you may
find stereotypes appearing in what appear to be inappropriate
parts of the model. (Coupling this with stereotype adornments
that help them stand out)
When you investigate, you find that there is an ERROR in the
model! Fix the error, the inappropriate stereotype is removed
and all is right with the world! ;D
Thoughts anyone?
Paolo
-
The UML 2.0 specification appears to be silent on the matter,
but why aren't stereotypes inherited along with attributes and
operations? ???
Here's an example: suppose you have a class hierarchy and you want to mark the root node with the <<root>> stereotype. Do you really want stereotypes to be inherited?
-
Here's an example: suppose you have a class hierarchy and you want to mark the root node with the <<root>> stereotype. Do you really want stereotypes to be inherited?
Interesting point Evil... 8) I'll have to think about it. My first impression, though, is that <<root>> might not be an appropriate use of stereotype. I would have thought the stereotype needs to indicate something innate in the class, which, I suspect, in this instance it doesn't.
Can you explain the semantics of <<root>>. (I've found the "bleeding obvious" often isn't- that's why I haven't injected any semantics of my own yet). How is the existing metaclass extended by <<root>>?
As a side issue, do you have any thoughts about stereotype hierarchies?
Paolo
-
any stereotype that applies to a specific class in the metamodel also applies to any subclasses of that class:
...from various Google-obtained pages.
So it's really a case of EA deciding to show them as such.
Multiple inheritance from stereotyped classes , anyone ?
-
Since there can only be one stereotype to an element it seems a bit restrictive to make it part of the inheritable features...
Besides an stereotype is an abstract concept, like a metaclass or a class... you should be able to create a stereotype that inherits from another one, but not a class that has a stereotype as a father (meaning that a class that has a stereotype is no longer a class but a stereotype of that class)...
Attributes and methods are physical characteristics of a class, the stereotype is more etheral.
I know it sounds abstract, but i am trying to 'land' it and can't find the proper words... i will try to think of a better way to phrase it latter.
Anyways, it feels correct to me...
-
...from various Google-obtained pages.
So it's really a case of EA deciding to show them as such.
Multiple inheritance from stereotyped classes , anyone ?
I think that is it, the inheritable feature is the "ability" to adopt that stereotype, but there is still only one stereotype to each element and so it can't be in the nature of the child to have it father's stereotype.
A stereotype stills seems to me more like a behavior characteristic than a structure or physicall one so i'm trying to look at it like a class behavior pattern... perhaps it could be an overwrittable one...
-
...from various Google-obtained pages.
Mike, did you check the source of those pages? I may have written them...
;D
(Only kidding!)
Paolo
-
Since there can only be one stereotype to an element it seems a bit restrictive to make it part of the inheritable features...
Sorry Alexander, in UML 2 you can (AT LAST!) have more than one stereotype per element! 8) That's what started me thinking about this...
Paolo
-
...(meaning that a class that has a stereotype is no longer a class but a stereotype of that class)...
No... it's a stereotyped class... We have to be very careful (and clear) about this...
Paolo
-
Attributes and methods are physical characteristics of a class, the stereotype is more ethereal.
(It's not bash Alexander day - honest! :D)
But here I can definitely agree with you! Much as I might like to have stereotypes add attributes and operations, they can't! That's the job of Generalization!
I also agree with you that the stereotype is more ethereal. It "hints at" differences in processing or behaviour within the same class. That's why you can use it to add tagged values, and why you can get different adornments to the class. (EA doesn't yet support that ability of stereotypes does it? Other products do.) :(
You're NOT changing the intrinsic structure or contracts of the class, but how it might respond.
In the light of this view (approach) can you see how Inheritability of stereotypes becomes more reasonable?
Paolo
-
Interesting point Evil... 8) I'll have to think about it. My first impression, though, is that <<root>> might not be an appropriate use of stereotype. I would have thought the stereotype needs to indicate something innate in the class, which, I suspect, in this instance it doesn't.
Can you explain the semantics of <<root>>.
Oh I dunno, it was just the first example that came to mind. Perhaps you could be generating a custom language and the syntax of root nodes is different to other nodes - the stereotype is used to modify the code generation templates. I think that's a perfectly valid use for stereotypes. You could also do it with a tagged value, but applying tagged values to elements is another valid use for stereotypes. Either way, stereotypes aren't "properties", so they aren't inherited.
-
Perhaps you could be generating a custom language and the syntax of root nodes is different to other nodes - the stereotype is used to modify the code generation templates. I think that's a perfectly valid use for stereotypes.
Using stereotypes to modify code generation IS indeed a valid use for stereotypes. I'm not sure if it's explicitly stated in the UML 2 specifications, but it's certainly implied.
Nevertheless, I still suspect your usage is novel...
You could also do it with a tagged value, but applying tagged values to elements is another valid use for stereotypes.
It's actually a required UML 2 functionality which EA isn't yet implmenting... ;)
Either way, stereotypes aren't "properties", so they aren't inherited.
The actual term used in the UML 2 is "feature". Your point is taken for strict UML 2. My question is "beyond" current UML. I guess I'm proposing that stereotypes (and any associated characteristics like adornment and tagged values) be treated as "features"
Paolo
-
(It's not bash Alexander day - honest! :D)
But here I can definitely agree with you! Much as I might like to have stereotypes add attributes and operations, they can't! That's the job of Generalization!
I also agree with you that the stereotype is more ethereal. It "hints at" differences in processing or behaviour within the same class. That's why you can use it to add tagged values, and why you can get different adornments to the class. (EA doesn't yet support that ability of stereotypes does it? Other products do.) :(
You're NOT changing the intrinsic structure or contracts of the class, but how it might respond.
In the light of this view (approach) can you see how Inheritability of stereotypes becomes more reasonable?
Paolo
That was what i was trying to say when refering to stereotypes as 'etheral' and to attributes and methods as 'physical'
I wasn't aware that you could have more than one stereotype in UML 2.0, i would have to think about that, it sure makes me think there is a 'multiple inherit' problem there since it defines multiple behavior for probably the same characteristic.
Just to be clear, i never said stereotype Inheritability wasn't reasonable, my point was it would bring a lot of 'inconsistency' to the UML model (i would have to review this in the light of recent information).
This might be a very dumb question, but how do you plan to inherit a class from another if not by the use of 'generalize'?
Don't worry about 'bash Alexander day', my girlfriend stablished it as a permanent festivity long ago ;)
-
This might be a very dumb question, but how do you plan to inherit a class from another if not by the use of 'generalize'?
My point was Generalization in UML is the method by which attributes and operations (features) get passed down. I didn't explain myself well enough, sorry...
Don't worry about 'bash Alexander day', my girlfriend established it as a permanent festivity long ago ;)
Say no more!
Paolo
-
The actual term used in the UML 2 is "feature".
Of course, apologies, feature is indeed le mot juste. It was on the tip of my tongue, honest!
Your point is taken for strict UML 2. My question is "beyond" current UML. I guess I'm proposing that stereotypes (and any associated characteristics like adornment and tagged values) be treated as "features"
I hope they never are. If stereotypes aren't inherited, you can choose to apply them wherever you wish; if they are inherited, you can no longer choose not to apply them.
-
Of course, apologies, feature is indeed le mot juste. It was on the tip of my tongue, honest!
Never doubted it... ;D (Truly!) It's just I like to be precise.
I hope they never are. If stereotypes aren't inherited, you can choose to apply them wherever you wish; if they are inherited, you can no longer choose not to apply them.
Indeed, Evil, this is the essential issue. But suppose we had concepts simlar to Java's "final" or Eiffel's suppression of inheritable features, then might we not have our cake and eat it too? 8)
[size=10](I don't have my copy of OOSC2 - here at home, so I can't be absolutely precise about Eiffel but I believe it to be correct)[/size] :)
Paolo
-
Thought I'd resurrect this topic.
From my perspective, I haven't seen a convincing argument as to why stereotypes shouldn't be inheritable...
Paolo
-
I'm going to climb off the fence and say "don't inherit".
If you model an element of type "Class" and then apply a stereotype to it, you aren't changing the meaning of the element, you're changing the meaning of "Class". So why did you model it as a class in the first place? Maybe because you wanted to generate a class in your program. And why did you add a stereotype? Maybe to change the detail of the way in which the program is generated, or to change languages, or any number of reasons associated with the mechanics of modelling but nothing to do with what the model actually means or tries to communicate.
I'll turn the question round: if you want a stereotype to add semantic meaning to the element you're modelling, shouldn't you add attributes instead?
-
I'm going to climb off the fence and say "don't inherit".
[SNIP]
Well, KP, I'm glad you think so... Because EA doesn't... ???
Create a class, create a second class. Change the first class to a boundary stereotype - the class changes shape. NOW, add a Generalization link from the second class to the first! Presto - stereotype is inherited, second class changes shape! :-/
For the "coup de gras" - create a third class, and a fourth class. Connect four to three via Generalization. Change three to a boundary. Voila! Three's shape changes, four's doesn't... ::)
Create a fifth class, create a sixth class. Change the fifth class to a metaclass stereotype. Add a Generalization link from the sixth class to the fifth! Presto - nothing happens! >:(
More secret handshakes? :o
Paolo
-
Well, KP, I'm glad you think so... Because EA doesn't... ???
Create a class, create a second class. Change the first class to a boundary stereotype - the class changes shape. NOW, add a Generalization link from the second class to the first! Presto - stereotype is inherited, second class changes shape! :-/
For the "coup de gras" - create a third class, and a fourth class. Connect four to three via Generalization. Change three to a boundary. Voila! Three's shape changes, four's doesn't... ::)
The behaviour you describe is as designed: stereotypes are not inherited but are copied from parent to child on applying a generalization connector. Remove the generalization and the stereotypes stay copied: if they'd been inherited they would've been removed. You can use EA's behaviour to choose whether you want to apply stereotypes singly or all down the hierarchy, simply by changing the order you apply stereotype and generalization.
Create a fifth class, create a sixth class. Change the fifth class to a metaclass stereotype. Add a Generalization link from the sixth class to the fifth! Presto - nothing happens! >:(
That's not good: it works for me. Is your metaclass stereotype in a profile or did you define it in "Configuration | UML | Stereotypes"? What is the file format of the metaclass file? What is the name you've given the stereotype?
-
The behaviour you describe is as designed: stereotypes are not inherited but are copied from parent to child on applying a generalization connector. Remove the generalization and the stereotypes stay copied: if they'd been inherited they would've been removed. You can use EA's behaviour to choose whether you want to apply stereotypes singly or all down the hierarchy, simply by changing the order you apply stereotype and generalization.
Surely you jest!?! :o How can I, over time, have 'a priori' decidability over how the model will develop? The model develops as the model will - as a result of analysis and design! The rules around copying of stereotypes have to be declarative, not procedural!
Once again, I'm no longer the modeller, EA is... IT, NOT ME, decides when it will copy the stereotype, based upon some serendipitous set of circumstances! :'(
At a minimum, EA should ask whether it wants me to copy the stereotype. Both at the time the generalization link is created and if I change the stereotype of the Generalized class and a Generalization link exists! (Recursively please! 8))
In my view, however, the fact that EA does copy the stereotype by default on the inital generalization is yet another indication supporting the generalized notion of inheritability of stereotypes! ;D
That's not good: it works for me. Is your metaclass stereotype in a profile or did you define it in "Configuration | UML | Stereotypes"? What is the file format of the metaclass file? What is the name you've given the stereotype?
I don't know where it came from. In any case, from your foregoing, the name of the stereotype should not be relevant! You said, it will copy the stereotype on initial generalization (giving me the choice - see highlight in read above). Certainly, if I do it with one of my own stereotypes - added as you describe, it doesn't work!
Paolo
Consistency, Consistency, Consistency!