Inheritance Shape-Script between Stereotyps

[Paolo F Cantoni]

I didn't explain myself well enough.  The stereotype involved is NOT the one on the toolbar.  It's one of the antecedents.  The one to drag is clear and singular.  I would have expected that so long as the dropped metaclass was one of the multiples in the antecedent, it should be OK.

Doesn't matter where you are going to drop the stereotype. If the stereotype on the toolbox can't determine a metaclass when you start a drag it won't work.

<Profile>::<Metatype> is defined as a Class (and ONLY a Class) - via extension. To have to say <Profile>::<Metatype>(UML::Class) is, surely redundant.  It still strikes me as a code "smell".

Two points. It's <Profile>::<Stereotype>, not <Profile>::<Metatype>. As I said, if there is only one possible extension it does work it out. The only time (I know of) where it can't work it out for a single extension is if that extension is to an abstract metaclass. The problem is when you omit the extension by habit and are then surprised when it doesn't work when you have more than one. That's why it's recommended to include it explicitly.

OK, my bad on <Profile>::<Stereotype>, vs <Profile>::<Metatype>.  (It's force of habit!  I thought <Profile>::<Stereotype>, but wrote <Profile>::<Metatype>.)

I think your explanation should be expanded to be clearer...  "if there is only one possible extension all the way up the inheritance hierarchy it does work it out.

Now to figure out how to respecify the toolboxes (and there are MANY) most efficiently!

Paolo

BTW: From the observed behaviour and your explanations,  if you have a multiple extension in the hierarchy ^[1] it would seem pointless to have to define the toolbox item within the model as a specific metaclass extension since it needs to be overridden at the toolbox in any event.  Is that observation correct?

Indeed, we ran a test <Profile>::<Sterotype> is directly defined as a Class (and ONLY a Class) - via extension and thus has the section:
<AppliesTo>
   <Apply type="Class">
      <Property name="_HideMetaclassIcon" value="true"/>
      <Property name="isActive" value=""/>
   </Apply>
</AppliesTo>
and yet, if we define the toolbox entry as <Profile>::<Sterotype>(UML::Activity), we will get an Activity.  This also smells.

^[1]  Since we want to achieve commonality of decorations efficiently, it is likely that EVERY toolbox item will have a multi extension at least once in its inheritance hierarchy.

[Eve]

I think your explanation should be expanded to be clearer...  "if there is only one possible extension all the way up the inheritance hierarchy it does work it out.

Accepted.

BTW: From the observed behaviour and your explanations,  if you have a multiple extension in the hierarchy ^[1] it would seem pointless to have to define the toolbox item within the model as a specific metaclass extension since it needs to be overridden at the toolbox in any event.  Is that observation correct?

I'm not sure what you mean.

Indeed, we ran a test <Profile>::<Sterotype> is directly defined as a Class (and ONLY a Class)

...

and yet, if we define the toolbox entry as <Profile>::<Sterotype>(UML::Activity), we will get an Activity.  This also smells.

No, that's good. An activity IS A^[1] class. So in that case EA should be looking for the extension of Activity and instead finding the extension of its superclass.

^[1] Via inheritance. Activity IS A Behavior IS A Class.

[Paolo F Cantoni]

No, that's good. An activity IS A^[1] class. So in that case EA should be looking for the extension of Activity and instead finding the extension of its superclass.

^[1] Via inheritance. Activity IS A Behavior IS A Class.

If that's the case,
why did
<AppliesTo>
<Apply type="Activity"/>
<Apply type="Class"/>
</AppliesTo>
fail?  Remember, the toolbox item was explicitly defined as a Class.  It should have found the Class in the antecedent as both Activity and Class are Classes (shades of the Oranges and Lemons problem....)

[Eve]

The rule is that as soon as there are multiple extensions in the inheritance hierarchy, specifying the base UML type becomes compulsory.

If a single metaclass is extended then that metaclass can be inferred to be the base type. That doesn't mean that specialized base types aren't valid, just that a logical choice can be made.

As soon as multiple metaclasses exist, even when they are related, the base type can't be inferred so it needs to be manually specified.

[Paolo F Cantoni]

In the defect report and subsequent investigation by Sparx with respect to decoration inheritance, it was admitted that (at the time - and apparently as of the date of this post with build 1559) such inheritance only worked for one level.  That is, one couldn't have a more formal inheritance tree.

Can any Sparxians enlighten us if this is being worked on? I think it was admitted as a defect - and for my money - an important one to get fixed.

We're looking at how to reduce the amount of rework (due to technical, architectural and conceptual debt) we might have when that functionality works as we'd expect and our significant jury-rigged solutions can be greatly simplified.

TIA,
Paolo

BTW: I can't recall if Shape Main (and other Shapes) were inherited through a tree.  Perhaps that could be confirmed or denied...

[Edit:  If you're looking at Inheritance, then the USDP Inheritance issue (Can <DiagramProperties> be inherited?) would also be good to get sorted.]

[qwerty]

And what about setting multiple stereotypes? To my experience the order of how the scipts are applied seems random.

q.

[Paolo F Cantoni]

And what about setting multiple stereotypes? To my experience, the order of how the scripts are applied seems random.

q.

My understanding (from what Eve has said - she can correct me) is that shapes are overwritten, whereas decorations are inherited.  Now, since decorations are bound to a compass point, they are, essentially, independent (although I guess we try to set them up so that they don't overwrite each other).

Paolo