Inheritability of stereotypes

[Paolo F Cantoni]

Of course, apologies, feature is indeed le mot juste. It was on the tip of my tongue, honest!

Never doubted it...    (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?  
[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

[Paolo F Cantoni]

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

[KP]

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?

[Paolo F Cantoni]

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?

Paolo

[KP]

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?

[Paolo F Cantoni]

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!?!  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! )

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!

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!