EA creating strange FQ Stereotypes

[Ian Mitchell]

I wonder if anyone can explain this - a variation of Paulo's question in https://www.sparxsystems.com/forums/smf/index.php/topic,41578.0.html

I have a simple MDG "Stakeholders", with a toolbox which contains a type 'Stakeholder'.
When I drop it into my diagram, all is well: there is an entry in t_xref with the correct stereotype:

@STEREO;Name=Stakeholder;FQName=Stakeholders::Stakeholder;@ENDSTEREO;

Now I edit the element. OK, so I'm using my own editor, but all I'm doing in this test is changing the value of a test tagged value from 'hello' to 'hello world'. Everything else in the element stays the same.
When I come to update the element, I copy all the fields from the UI to the Ea.Element fields like a good boy, including StereotypeEx.

Now I haven't edited the stereotype, but the code doesn't know that, and my general-purpose 'save all the changes' code updates all the EA fields which MIGHT have been edited (ok, I could check...), so I set ea.element.stereotype = "Stakeholder", and, for good measure, StereotypeEX = "Stakeholder". (From the above post, I now see I should make StereotypeEx = "Stakeholders::Stakeholder", which makes everything OK. But stay with me....)

Then I update the element.

If I choose to set 'StereotypeEx' then my element magically acquires a new MDG: 'BIZBOK'.
So t_xref looks like:
@STEREO;Name=Stakeholder;FQName=BIZBOK::Stakeholder;@ENDSTEREO;

This is a concern: BIZBOK::Stakeholders look different in the diagram - so the user is confused -  and, as they have a different MDG, lots of other stuff now doesn't work.
Now that I know about this, I can work around it, but what's happening here? Why change the MDG at all, and why to this 'BIZBOK' MDG - what's special about this ?

[Geert Bellekens]

Yeah, that a little "gotcha" 

The field StereotypeEx allows to enter a fully qualified stereotype.
So you can say StereotypeEx  = "Stakeholders::Stakeholder"

But when you check the field again, it returns only the non qualified stereotype: Stakeholder

So if you do

Code: [Select]

myElement.StereotypeEx = myElement.StereotypeEx
You might be changing your myElement. When StereotypeEx received a non qualified stereotype, it start searching in all MDG's for a matching stereotype (the same behavior we had in the past when typing in a stereotype in the GUI)
In this case it find a stereotype "Stakeholder" in the BIZBOK MDG, and assumes that is the one you meant.
I'm pretty sure it pure chance that BIZBOK is the first one it finds.

I think this behavior qualifies as a bug as it violates the law of "least surprise"
A property should not behave like that.

Geert

PS. One of the "best practices" I adopted because of funnies like this is to prefix all of my stereotypes with the name or code of my MDG (a bit like ArchiMate stereotypes). So I would name the stakeholder stereotype something like STK_StakeHolder (if STK is short for StakeHolder)

[Ian Mitchell]

Thanks Geert - I thought I was going mad....
I'm now taking two routes:
1 - only update the StereotypeEx when needed
2 - add the MDG name to the stereotype, as you suggested.
Not sure about overloading the stereotype name, as that's user-visible, but it's still a good suggestion.
@Sparx - any comments ? Bug ?

[qwerty]

It "should" be designed differently. Stereotype was the ancient property (understandable from UML 1.x). Then later with UML 2.x there was a need for qualified names. So they only added StereotypeEx (like so many Ex attributes). Rather there should be getters with paramters (include FQN as bool parameter) and setters that should be able to either croak on missing FQN (if the name is not unique) or where you need to supply the profile name as a parameter. Just some quick thought. The current implementation however is following just the law of being most Sparxian.

q.

[Eve]

@Sparx - any comments ? Bug ?

Yes. In your code.

If you don't specify a fully qualified name you will cause problems.

Setting Stereotype is never a good thing to do. Especially in addition to StereotypeEx.

But the way you are using StereotypeEx is explicitly replacing a list of qualified stereotype names with a single non-qualified stereotype name. By using a non-qualified stereotype you are requesting EA to find "something" that matches. As far as I'm concerned you are explicitly saying you don't care which one, just that you want one of them.

[Paolo F Cantoni]

@Sparx - any comments ? Bug ?

Yes. In your code.

If you don't specify a fully qualified name you will cause problems.

Setting Stereotype is never a good thing to do. Especially in addition to StereotypeEx.

But the way you are using StereotypeEx is explicitly replacing a list of qualified stereotype names with a single non-qualified stereotype name. By using a non-qualified stereotype you are requesting EA to find "something" that matches. As far as I'm concerned you are explicitly saying you don't care which one, just that you want one of them.

I agree with what you are saying, Eve.  Of course, since the result is, therefore (operationally) somewhat indeterminate, it violates the principle (Geert, it's not a "law"  ) of "least surprise".

However, can you confirm the relationship between the LIST of (fully qualified) stereotypes in t_object.StereotypeEx and the principal stereotype in t_object.Stereotype?
My understanding was that the first time in the list ended up "getting the guernsey", but this may have changed in recent versions.

Paolo

[Eve]

Yes, it usually will be the first stereotype in the list.

PS. If I could change either of those functions to require fully qualified names I would. Unfortunately, I can't introduce code that will break existing users of the API.

[Paolo F Cantoni]

Yes, it usually will be the first stereotype in the list.

PS. If I could change either of those functions to require fully qualified names I would. Unfortunately, I can't introduce code that will break existing users of the API.

(my emphasis)
Well, for my part, I'm happy (enough) with the way it currently works if we (users) are specific.  Since we have the notion of a principal stereotype - denoting the metatype; so long as we know the relationship between the two properties won't change, it is acceptable.

I think, though, that code enforcing the relationship (thus converting the usually to always) would be useful and won't break any existing API use.

Paolo

[Geert Bellekens]

In my book, if a statement like this:

Code: [Select]

myElement.StereotypeEx = myElement.StereotypeEx
Actually changes the element, it should be considered a (design) bug in the API. If it does change the object it should not have been implemented as a property in the first place.
The real problem is that the getter of the StereotypeEx field returns the non-qualified stereotypes.

The least the API could do it be defensive about it.
If the element already has a stereotype "A::X", and I'm updating the StereotypeEx field with "X", the API could check if the element already has an "X" stereotype, and in that case keep it the same instead of changing it to "B::X"

Geert

[Paolo F Cantoni]

In my book, if a statement like this:

Code: [Select]

myElement.StereotypeEx = myElement.StereotypeEx
Actually changes the element, it should be considered a (design) bug in the API. If it does change the object it should not have been implemented as a property in the first place.
The real problem is that the getter of the StereotypeEx field returns the non-qualified stereotypes.

The least the API could do it be defensive about it.
If the element already has a stereotype "A::X", and I'm updating the StereotypeEx field with "X", the API could check if the element already has an "X" stereotype, and in that case keep it the same instead of changing it to "B::X"

Geert

My Bad, I don't need to use StereotypeEx

If that's what's happening then, as you say, that's WRONG!

Paolo