IDEA: Better rendering of internal glyphs

[Paolo F Cantoni]

Tables are currently implemented as stereotyped classes.  When you make the primary stereotype of the class «table», the little table glyph will appear at the top right.  In addition, if both ends of a relationship are stereotyped table in this way, the Foreign Keys... dialog is enabled.

Using EA's multiple stereotype functionality, you can add further stereotypes, that describe the nature for the table.  In addition, when multiple stereotypes are defined, and EA draws the glyph, it (conveniently) removes the «table» stereotypes (because it has now been rendered in the glyph)!

However, from a user point of view, there is a problem with the current implementation.  When rendering the multiple stereotypes, one needs the glyph is rendered ONLY if it is the primary stereotype.  Accordingly, there is NO simple mechanism to allow the rendering of the auxiliary stereotypes.

We propose that since the glyph rendering is internal to EA (and therefore beyond user control), the the glyph be rendered if the «table» stereotype occurs anywhere in the list.

In this way, the primary stereo can become one of the more expressive stereotypes that describe the nature of the table and the glyph (specifying that it IS a table) will still appear...

Interestingly, (in the current implementation) if you make the «table» stereotype NOT the primary stereotype, the relationship link will STILL detect it is a table and provide the Foreign Keys... dialog!
Consistency, Consistency, Consistency! ^TM

Although this posting is specific to the table glyph, we think it should be generally applicable.

Thoughts? Votes?
Paolo and Darren

[size=0]©2007 Paolo Cantoni & Darren Sampson, Ripple Systems[/size]

[thomaskilian]

I sometimes stumbled over this and I personally think there should be a way to denote the primary stereotype. I haven't read what Superstructures tells about that, but for me this would be an advantage.

[Paolo F Cantoni]

I sometimes stumbled over this and I personally think there should be a way to denote the primary stereotype. I haven't read what Superstructures tells about that, but for me this would be an advantage.

Thomas,

The primary stereotype is already specified.  That's the one in the main stereotype dropdown.

The others are auxiliaries.

Our point is related to the fact that in order to get the glyph, using  the current implementation, it has to be the primary stereotype.  Then, once the glyph is created, the primary stereotype is removed from the list and the remainder are displayed.

So now you have the incongruity that the primary stereotype is NO longer displayed (as text), and the one that IS displayed DOESN'T contribute to the rendering.  

Our proposal fixes this...  

Paolo

[Paolo F Cantoni]

I sometimes stumbled over this and I personally think there should be a way to denote the primary stereotype. I haven't read what Superstructures tells about that, but for me this would be an advantage.

On further reflection, I think I misunderstood your request.  

Are you saying that the primary stereotype should be rendered differently to the others, in some way?  If so, then I agree that's a good idea.

The [size=13]UML 2.1 Superstructure (interim)[/size] Specification make no distinctions between stereotypes.  Darren and my view is that stereotypes should be ranked.  We've previously posted how we believe stereotype ranking could allow a mechanism to fully render an element according to the ranking.

However, the current behaviour precludes that (as I now think you are suggesting) since if the glyph is created from the primary stereotype, it's no longer in the list!

Paolo  

[thomaskilian]

Hi Paolo,
actually this is what I was trying to say (Unfortunately my fingers do not type so well any more - or they have to type so much other stuff that I haven't the time to write more lengthy texts as I should).

[Paolo F Cantoni]

An interesting sidelight to this problem is that if «table» is NOT the primary stereotype, then the Class will behave differently.  The Attribute and Operation dialogs render differently and, more importantly, behave differently...  For example, if «table» is primary, there is NO [Copy] button.  This limits the ability to (for example) easily copy a FK Constraint into an Inversion Index.  Frustratingly, if «table» is NOT the primary then the copy functionality appears to work perfectly...

Can this be fixed, please?

Thoughts?  Votes?
Paolo

Consistency, Consistency, Consistency! ^TM