Preach it, Brother Paolo!
EA's implementation of stereotypes is stuck somewhere between UML's original notion of a stereotype as little more than a string and the more developed notion of stereotypes as classifiers existing in a namespace. This inconsistency can lead to all sorts of madcap UML adventures, possibly contributing to accelerated hair loss.
For example, you might think that multiple stereotypes might be represented in the database as a delimited sequence of (possibly qualified) names, something EA does in a number of other places (e.g. object run state) [Codd's Bodkins!]. But you would be wrong. It seems that the original Stereotype field in EA database table t_object is a text field limited to 255 characters - wide enough for most cases, perhaps, but certainly not wide enough for all possible lists of applied stereotypes users might conjure up (it would be necessary to change the field to a Memo field [in Access / EAP files at least, BLOB or whatever in other RDBMS's], as in the case of object run state, to have 'unlimited' stereotype lists on a single field).
To get around this, EA uses an extra table - t_xref - to hold all stereotypes after the very first ALONG WITH the very first. For example, if I have an actor named "User", and then display User with rectangle notation, the stereotype «actor» appears. This isn't actually stored in the database as a stereotype; it simply means the element is a stick figure incognito. If I then add the stereotypes «bob», «carol», «ted», and «alice», I find the following has occurred:
- The Actor "User" now has the string "bob" in the field t_object.Stereotype.
- The other stereotypes, along with "bob," are in t_xref, represented (in a Memo field!) as follows:
@STEREO;Name=bob;GUID={E60E44BA-D7C4-4e06-8A1F-B97BBDAF637B};@ENDSTEREO;@STEREO;Name=carol;GUID={8F8BC8D5-9745-4770-B262-74C2853C18A4};@ENDSTEREO;@STEREO;Name=ted;GUID={D54F0850-F938-4532-9986-F68FC756FD7F};@ENDSTEREO;@STEREO;Name=alice;GUID={0EA90EBC-A048-443c-AD3D-DC027B0F209B};@ENDSTEREO;If I now try to add the stereotypes «Bob», «BOB», and «bOb», there is NO CHANGE to the stereotype list - case is ignored for stereotypes. I can't change «bob» to «Bob» without deleting the original stereotype «bob» (which now appears in two places in the database) and adding a new one - «Bob». So I do just that, and my diagram now shows «actor,Bob». OK? But wait - if I then click on the stereotype drop down in the Element Properties dialog, it shows "bob". Close the dialog and the diagram reverts to «actor,bob». (It goes without saying that, in case-sensitive languages at least, bob <> Bob.)
Now, putting Codd and database normalization aside for the moment, none of this under-the-hood stuff would matter if EA hid it all neatly and consistently in the UI and in the AI. But if stereotypes are now really classifiers (which means their instances are now really objects), why not store them as such in a table akin to t_objectproperties? Why does StereotypeEx return a comma-separated list while TaggedValuesEx returns a collection? And why is schema backwards-compatibility a sacred cow?
Consider this your moment of Zen.
