Inheritance Shape-Script between Stereotyps

[Paolo F Cantoni]

I tried Eve's suggestion here is the diagram.

Did I understand her correctly?

Because, if I did, the output for the profile is quite peculiar...
Any ideas?
[EDIT: caused by my accidentally forgetting to set the package stereotype to "profile"  - ignore previous versions of this post.]



TIA,
Paolo

[qwerty]

Are you able to expose C (or B) in a toolbox? I was not (which I said in a previous comment). Only if there's an explicit extends then the stereo will be shown in the toolbox.

q.

[Paolo F Cantoni]

Are you able to expose C (or B) in a toolbox? I was not (which I said in a previous comment). Only if there's an explicit extends then the stereo will be shown in the toolbox.

q.

No, I couldn't either.  So I'll try that.

Paolo

[EDIT: That did the trick!
]

[Paolo F Cantoni]

[SNIP]

Now that I've been using the model-based definitions for a while, I checked the emitted XML and everything looked as I expected.  Am I missing some secret sauce?  For example, do I need a "shape main" in the supplementary stereotype?

Paolo

As noted elsewhere, the "Secret Sauce" was to include the extension to the metaclass.  Shapescripts don't seem to be activated if there is no such link.  Can anyone confirm?

Some more experimentation required to find the "envelope" within which we have to work, but looking good, so far!

Paolo

[Paolo F Cantoni]

[SNIP]

Some more experimentation required to find the "envelope" within which we have to work, but looking good, so far!

OK, so I've done some further experimenting and it's raised several questions.  However, I think I'm able to achieve what we're after, but it seems clumsier than I would have thought.

I'll use the diagram below to illustrate and set up my questions.  NOTE: This is NOT what we ended up with but allows me to discuss the issues we found.

Initially, we had only StndrdItm¯S, no metaclass.  The inheritance failed completely (as previously discussed). 
So, since the Item(Generic) was a Class, we added the Class metatype as a direct extension to StndrdItm¯S.  This worked and Item(Generic) inherited the decorations correctly.

We wanted to extend this capability to an Activity-based stereotype BusinessProcess.  We tried merely having BusinessProcess inherit from StndrdItm¯S, but, as expected, this failed (Activities can't inherit from Classes). 

So, we added the Activity metaclass to StndrdItm¯S.  Still no go (not unexpected. It looks as though being able to have multiple extensions has failed for the last few versions - can anyone confirm?)

Next we created the structure in the diagram.  Each item type gets its own metaclass to inherit from.  So now Item(Generic) inherits from StndrdClss¯S and BusinessProcess inherits from StndrdActvty¯S.  With this structure, we can drag the items from the toolbox, but the decorations shapescript is NOT inherited (from StndrdItm¯S). 

This was a shame, but we then copied the _image attribute from StndrdItm¯S to both StndrdClss¯S and StndrdActvty¯S and voila, it works!

My questions are:
Can this (notionally) redundant cloning of the shapescript avoidable?
Is multiple extension broken?  If it was fixed, should everything be able to inherit from a multi-extended StndrdItm¯S?

TIA,
PAolo

[qwerty]

Basically I would expect your first model (up this page) to work. As it does not, Sparx has implemented, well, selective, ignorant or just sparxian inheritance. In any case it's irrelevant whether I think it's a bug.

q.

[Eve]

My initial test had both B and C inheriting from A directly, while A held the only extends relationship.

Making C inherit from B instead resulted in it not getting the decoration from A. The reverse (inheritance C -> A, B -> C) resulted in B not drawing the main shape from A. That's not the behavior I expected, but it does align with what you have described.

I also saw that the shape script isn't picked up by the specializations in the situation like your last diagram. I can't explain why that would be either.

[Paolo F Cantoni]

My initial test had both B and C inheriting from A directly, while A held the only extends relationship.

Making C inherit from B instead resulted in it not getting the decoration from A. The reverse (inheritance C -> A, B -> C) resulted in B not drawing the main shape from A. That's not the behaviour I expected, but it does align with what you have described.

I also saw that the shape script isn't picked up by the specializations in the situation like your last diagram. I can't explain why that would be either.

Thanks, Eve,

So should I report a defect?  I have already reported inheritance defects with USDPs etc.

Also, do you have any comment on my multiple extension question?  It used to work in the past for things like Association (arc) and AssociationClass (vertex), but now seems broken.

Finally, is qwerty's observation that without the extension, the stereotype won't work correctly in the toolbox correct?

[EDIT: Defect reported]

Paolo

[Paolo F Cantoni]

I have received a reply from Sparx regarding the defect I mentioned.

Hello Paolo,

Thanks for the email.
My investigation shows that a stereotyped element will display decorations from its stereotype and from that stereotype's immediate generalization, but doesn't recurse up the stereotype hierarchy.
See the attached screenshot "Shape Test.png".

We will fix this in a future release.
Issue ID: 21027012
Were there any other unresolved issues from that forum thread?


This clarifies matters, but I've now discovered what appears to be a further defect.

We have made EXTENSIVE use of decorations to surface properties of the item.  We can have (currently) up to 5 "widgets" in a particular orientation of the item (NW,N,NE,E,SE,S,SW,W & CENTER).  However, when we separate the widgets via inheritance (Generalization), this breaks.  NOTE: so long as the widgets don't overlap, it works fine for a given shapescript.

If we have a shape script (for stereotype G) that has:
shape main
{
}
decoration A
{
(NE)
}
decoration B
{
(NE)
}

If I now extract decoration A & B into a separate stereotype  J
and reduce Shapescript G to just

shape main
{
}

and have a Generalization from G to J, it works as expected.

However, if I split each decoration into Stereotype A & Stereotype B - each one consisting only of the decoration - remove the generalization to J and add the generalizations to A & B, it now fails.

In other words, if it works in two of the above use cases, it should also work for the third!

In my view, this is a defect, but before I formally report it, I'd welcome feedback.

TIA,
PAolo

[qwerty]

I suspect shape script to be some of those quick designs being implemented (from brain to keyboard) and never designed. Just a look at the poor language design makes that clear. (Just as a fun fact: comments were only introduced a couple of years ago after I sent a feature request.) So I would not be astonished to find more kind of weirdness as I already did.

q.

[Paolo F Cantoni]

My initial test had both B and C inheriting from A directly, while A held the only extends relationship.

Making C inherit from B instead resulted in it not getting the decoration from A. The reverse (inheritance C -> A, B -> C) resulted in B not drawing the main shape from A. That's not the behaviour I expected, but it does align with what you have described.

I also saw that the shape script isn't picked up by the specializations in the situation like your last diagram. I can't explain why that would be either.

Thanks, Eve,

So should I report a defect?  I have already reported inheritance defects with USDPs etc.

Also, do you have any comment on my multiple extension question?  It used to work in the past for things like Association (arc) and AssociationClass (vertex), but now seems broken.

Finally, is qwerty's observation that without the extension, the stereotype won't work correctly in the toolbox correct?

[EDIT: Defect reported]

Paolo

Hi Sparxians, Any chance this could be answered definitively?  I've just spent another few hours diagnosing this to be the issue in an inheritance hierarchy...  Sometimes it seems to work and other times it's "screwed".

Paolo

[Edit:
The question I'm looking for an answer to is "Does multiple extension work"?  That is if you have a single

<AppliesTo>
<Apply type="Class"/>
</AppliesTo>

Things will work (i.e. the item can be dragged from the toolbar)

If there are multiple,

<AppliesTo>
<Apply type="Activity"/>
<Apply type="Class"/>
</AppliesTo>

It will not drag...]

[Eve]

If you want a definitive answer, go through the support form.

The question I'm looking for an answer to is "Does multiple extension work"?  That is if you have a single

<AppliesTo>
<Apply type="Class"/>
</AppliesTo>

Things will work (i.e. the item can be dragged from the toolbar)

If there are multiple,

<AppliesTo>
<Apply type="Activity"/>
<Apply type="Class"/>
</AppliesTo>

It will not drag...]

How is your toolbox defined? If you have "Profile::Stereotype" in the default field it needs to work out for itself which metaclass you want to drop. It can (usually?) do this if there's only one metaclass, but it can't if there are multiples.

That's why the preferred way to reference the item is with "Profile::Stereotype(UML::Metaclass). My personal experience is that it has always worked if I've specified the extension to use.

[Paolo F Cantoni]

If you want a definitive answer, go through the support form.

The question I'm looking for an answer to is "Does multiple extension work"?  That is if you have a single

<AppliesTo>
<Apply type="Class"/>
</AppliesTo>

Things will work (i.e. the item can be dragged from the toolbar)

If there are multiple,

<AppliesTo>
<Apply type="Activity"/>
<Apply type="Class"/>
</AppliesTo>

It will not drag...]

How is your toolbox defined? If you have "Profile::Stereotype" in the default field it needs to work out for itself which metaclass you want to drop. It can (usually?) do this if there's only one metaclass, but it can't if there are multiples.

That's why the preferred way to reference the item is with "Profile::Stereotype(UML::Metaclass). My personal experience is that it has always worked if I've specified the extension to use.

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.

The only thing I changed (and manually for test purposes) was the line indicated - in the antecedent.  If the dropped metaclass is NOT one of the multiples, it won't drop and that is understandable.

Paolo

[Paolo F Cantoni]

Well, it seems that notwithstanding that if the concrete metatype is defined as a single metaclass, if there are multiple metaclasses in the inheritance tree, you have to specifically (and I would argue redundantly) specify the draggable metaclass in the concrete toolbox specification.

<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".  Still, at least I don't have to redesign our inheritance tree for the second time in a couple of days.

So, thanks for the hint, Eve.  It's replaced a large pile of work with a smaller pile of work to specify the explicit metaclass on the toolbox items.

Paolo

[Eve]

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 our 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.