Author Topic: Inheritance Shape-Script between Stereotyps  (Read 6661 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 7911
  • Karma: +205/-124
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Inheritance Shape-Script between Stereotyps
« Reply #30 on: April 20, 2021, 10:17:31 am »
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.
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 7533
  • Karma: +94/-17
    • View Profile
Re: Inheritance Shape-Script between Stereotyps
« Reply #31 on: April 20, 2021, 11:18:03 am »
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.
« Last Edit: April 20, 2021, 11:32:06 am by Eve »
Eve

support@sparxsystems.com

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 7911
  • Karma: +205/-124
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Inheritance Shape-Script between Stereotyps
« Reply #32 on: April 20, 2021, 02:02:00 pm »

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....)
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 7533
  • Karma: +94/-17
    • View Profile
Re: Inheritance Shape-Script between Stereotyps
« Reply #33 on: April 20, 2021, 03:13:27 pm »
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.
Eve

support@sparxsystems.com

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 7911
  • Karma: +205/-124
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Inheritance Shape-Script between Stereotypes
« Reply #34 on: July 26, 2021, 11:49:49 am »
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.]
« Last Edit: July 26, 2021, 02:19:59 pm by Paolo F Cantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

qwerty

  • EA Guru
  • *****
  • Posts: 12234
  • Karma: +346/-280
  • I'm no guru at all
    • View Profile
Re: Inheritance Shape-Script between Stereotyps
« Reply #35 on: July 26, 2021, 05:40:37 pm »
And what about setting multiple stereotypes? To my experience the order of how the scipts are applied seems random.

q.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 7911
  • Karma: +205/-124
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Inheritance Shape-Script between Stereotyps
« Reply #36 on: July 26, 2021, 06:09:49 pm »
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
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!