Requirement's StereotypeEx

[TimmyTreeFriends]

Hi guys, I am working on the next release build of Time Architect (the new Add-In for EA, see http://www.timearchitect.net). I am trying to access Stereotype from a Requirement element. Now I've got an interesting situation:

For example, if I drag a Requirement from Toolbox-Extended-Requirements to the diagram, assign a Type, say "Display" to it. From automation, the Stereotype property returns "Display", and the StereotypeEx property returns "Display" too, as expected.

However, if I drag a Requirement from Toolbox-Extended-Custom to the diagram, after assigninng "Display" to its Type, from automation, the Stereotype property still returns "Functional", and the StereotypeEx property returns "Display,Functional".

Can anybody tell me why this is? Does this imply that the Requirement dragged from Custom section is different from the Requirement dragged from Requirements section? ( Well their icons look the same.... )


Another question is, what is the difference between an element's Stereotype and StereotypeEx?


Thank you in advance. Your help is much appreciated.
Tim

[«Midnight»]

Tim,

This dates back to simpler times when EA only handled a single stereotype. [We were all much more naive then, or happier if you prefer that term.]

When Sparx gave us the ability to handle multiple stereotypes, they did not want to break old models - or to deal with a new schema and the resultant upgrades. This meant keeping the 'single' stereotype, while also supporting an arbitrary number of 'other' stereotypes. What you end up with is a situation where the first one entered - often through the Stereotype box on an Properties dialog - becomes sort of 'first among equals.'

Over time this has gotten blurred. Newer features of EA often assign stereotypes for you, which can mean that you lose control over which one is 'first.' This looks like the situation you're encountering.

Meanwhile, the Stereotype property returns the stereotype set in the element's Properties dialog, whether by you or EA. The Stereotype returns a comma-separated list of all the stereotypes of that element (possibly including inherited stereotypes, I cannot remember off-hand).

HTH, David

[TimmyTreeFriends]

Thank you so much for your quick response David, it really helped.

But still, is it a bug or known feature that if a Requirement element is dragged from Toolbox-Extended-Custom, its Stereotype (Element.Stereotype property from automation) remains unchanged even if you munually change it from EA?

I guess the problem I am having is - the Requirement element in Toolbox-Extended-Custom and in Toolbox-Extended-Requirements are different!

[«Midnight»]

...Over time this has gotten blurred. Newer features of EA often assign stereotypes for you, which can mean that you lose control over which one is 'first.' This looks like the situation you're encountering.

Almost certainly one of the above cases I'm afraid.

Best to experiment to see if you can find a more reliable way, where you don't get this behavior. Or, build an automation routine that inspects StereotypeEx when you are (or might be) dealing with requirement elements.

Unfortunately, EA may only be looking at the 'first' stereotype when it decides how to treat an element. If you reverse the stereotypes (somehow) make sure you test thoroughly to determine whether EA starts treating the elements in ways you don't expect or want.

David

[TimmyTreeFriends]

Yes David you've got the point, maybe I'll just treat Requirement element differently with extra checking routine.

Thank again.

Tim

[Paolo F Cantoni]

Tim,

If you look for some recent posts of mine regarding XSD handling - you'll see I showed that not only will two "identical" elements behave differently from time to time, but will also themselves behave differently depending upon the context.

It's all quicksand...


Paolo

[TimmyTreeFriends]

I see what you mean Paolo, thanks for your reply!

Tim

[«Midnight»]

Tim,

If you look for some recent posts of mine regarding XSD handling - you'll see I showed that not only will two "identical" elements behave differently from time to time, but will also themselves behave differently depending upon the context.

It's all quicksand...


Paolo

Such a pessimist Paolo!

You seem to see the glass as half empty. I'm trying to be a realist. I see the glass as half full.

But yes, it's half full of quicksand...

David

Oh yes, now for the test:

What is the correct order for the above stereotypes?

[Yes, I know they are unordered in UML. But in the real world we often insist on a specific order for otherwise equal sets of things.]