Export duplicate stereotype

[qwerty]

Assume you have a stereotype that extends two metatypes. When you draw two extensions from one stereotype the export is ok. However, if you are in need for two different sets of stereotype properties and you have two stereotypes with the same name extending each of the metaclasses individually then only one of them gets exported. When editing the xml profile manually you can well create two such stereotypes with the same name and EA interprets them as desired. Simple question: oversight (which I assume and do not really hope for a fix) or intention (where I would like to know the reasoning)?

q.

[qwerty]

My bad. I can answer. Made an error with the manually edited xml and it's not working. So the name must appear only once. Too bad in any case.

q.

[Paolo F Cantoni]

Assume you have a stereotype that extends two metaclasses. When you draw two extensions from one stereotype the export is ok. However, if you are in need of two different sets of stereotype properties and you have two stereotypes with the same name extending each of the metaclasses individually then only one of them gets exported. When editing the XML profile manually you can well create two such stereotypes with the same name and EA interprets them as desired. Simple question: oversight (which I assume and do not really hope for a fix) or intention (where I would like to know the reasoning)?

q.

Hi q,
I've adjusted the quote.  I find it useful to restrict the use of metatype to a specific metaclass-stereotype combination.

Now to discuss your use case.  I'm not sure I fully understand what you are trying to do, so if you could give a more narrative explanation, with perhaps some examples?  With the model approach, I found I had to clarify my thinking a bit as I got into it.  Sorting out if it's a viable use case may help that process.

What I'm about to say is my understanding (and I would welcome any correction from Sparxians or others if it's wrong).
An extension relationship seems to be required if you actually want things to happen via the toolbox.
When you extend multiple metaclasses, you are saying, this stereotype can be applied to more than one metaclass.  If you observe my definition above, this means you are defining multiple metatypes (which, consequently, should have unique metatype names).
Now when you define a toolbox item, you can just use the <profile>::<stereotype> approach if the stereotype is unique and EA will determine the metaclass for you since there is no ambiguity.  If however, there are multiple metaclasses possible, then you need to disambiguate with <profile>::<stereotype>(UML::<metaclass) to indicate which metatype (that is,  metaclass) is to be created.

So to your use case...  It seems to me it ought to be possible to say: Let me define a supplemental stereotype that extends only one metaclass and which the stereotype inherits from to hold one set of Attributes (Tag Properties).  Let me define a second supplemental that extends only the other metaclass and which the stereotype also inherits from to hold the other set of Attributes (Tag Properties).  Let the common stereotype extend BOTH metaclasses.

Thus when EA instantiates the appropriate metatype (metaclass-stereotype combination) toolbox entry it knows which supplemental stereotype to use to create the tag set required.  Is that what you are after?

If so, then (as an exercise for the reader ) create a model (as I've been doing for the recent discussion with Eve on v15.2 – What is FQN of «stereotype» (from Profiles)? ) and the resultant generate MDG entries and we can help.

@Eve, if I've misunderstood what is possible, please leap in and save q a pile of work.

HTH,
Paolo

[Eve]

First off, I believe it's a UML restriction that stereotype names need to be unique in a profile, not an EA restriction. As UML would describe it,

The default rule is that two members are distinguishable if they have different names or if  they have the same names, but their metaclasses are different and neither is a (direct or indirect) subclass of the other.

In concrete terms, UML specifies a constraint on a namespace that all members should be distinguishable. A profile is a namespace and two stereotypes with the same name do not meet the criteria for being distinguishable from above.

Regardless of any tricks, there can only be one stereotype with a given name in a profile. That stereotype will have exactly the same set of properties regardless of the metaclass it extends. The inheritance hierarchy for a stereotype is not filtered by any extensions because they are effectively properties themselves and are therefore inherited along with the other properties.

In summary, if you want a different set of properties you will need two different stereotypes.

As for what extensions mean... Regardless of how it's created or even what tool you are using. If you are creating a stereotyped element you are conceptually creating two elements. First, the base element is created, this will always be one of the extension targets or their specializations. The stereotype is a second object that holds its own properties and a reference to the base element. UML is explicit that the total multiplicity of all extensions from a stereotype is always 1. ie. They always apply to a single element.

Thinking of an extension as something that enables the toolbox in my opinion flawed. Without an extension a stereotype can't be instantiated at all. It is implicitly abstract, although the specification doesn't refer to it as such. The behavior of the toolbox is a symptom of the fact that it can't be created. You also can't apply the stereotype to any existing element.

[qwerty]

(Argh! I just accidentally closed my browser with the almost complete answer)

To repeat myself: This time (but only as an exception) I was not trying to blame EA being the cause for all evil ;-)

Just to elaborate on the reason behind my post: Imagine you have a stereotype «businessUse» which extends Part and Port. Now for some reason you might want to show the Name for Parts optionally and the Type for Ports. Also you might wish to have different renderings for either. Now, if you put «diagramProperty» ShowName and ShowType in that single stereotype (since you only have that one) you end up with both elements showing both options in the context menu. Pretty dull and not really what you want. Also the shape script gets unnecessary complicated as you have to code if-constructs depending on the element type. You can't really live with those restrictions.

We ended up in creating different stereotypes namely «businessUse part» and  «businessUse port». Not that elegant either but the only way we saw.

So here's where I started to think and play. Having two equally named stereotypes extending different metaclasses would solve the issue. Semantically they are different (just not by name) since they extend different metaclasses. Both have the right place for shape scripts and «diagramProperty». And the stereotype would not look that bloated.

Maybe the OMG guys were not smart-ass enough to think of such a construct?

q.

[Eve]

And the stereotype would not look that bloated.

Maybe the OMG guys were not smart-ass enough to think of such a construct?

At least some of them had the same problem with overly verbose stereotype names on diagrams. SysML has examples of stereotypes that display a different/shorter keyword than the stereotype name.

• 'ParticipantProperty' has the keyword «participant»
• 'ConnectorProperty' has the keyword «connector»
• 'ConstraintBlock' has the keyword «constraint»

The common point about the examples I've given there is that they all omit  the type they apply to like you're wanting to do.

[qwerty]

Yep. We just use a shape script to print the shorter name where and if needed. Sort of works and it is as it is. Howeer, I'm always looking for magic potions. Sometimes I find one often I don't.

q.