Author Topic: <<realize>> stereotype not in StereotypeEx?  (Read 6315 times)

LurkingGrue

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
<<realize>> stereotype not in StereotypeEx?
« on: May 29, 2008, 01:43:33 pm »
I'm fairly new to EA and have been playing with the automation interface via custom add-ins.

My understanding is that the StereotypeEx property is a comma-separated list of all stereotypes for a given object, and the Stereotype property just gives the first one from that list.

However, I noticed when iterating through stereoptypes that a Realization connector with Stereotype = "realize" does not have any values in the StereotypeEx property (which = "" if there are no others).  Is this by design because it is a special built-in value?  Are there other examples of this to watch out for in EA?

Or perhaps one should always read Stereotype and StereotypeEx together to get all stereotypes for a given object?

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8061
  • Karma: +118/-20
    • View Profile
Re: <<realize>> stereotype not in StereotypeEx?
« Reply #1 on: May 29, 2008, 03:18:10 pm »
I suspect that realize is not a stereotype, but a keyword.

Although they look the same, a keyword is goes with the base class (in this case realization) and can't be modified.  However, I think that there is still a potential problem here because if it is in the stereotype field it should also be in the stereotypeex field.

Yes, there are other examples of this.  The only one I can think of at the moment is interface.

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: <<realize>> stereotype not in StereotypeEx?
« Reply #2 on: May 29, 2008, 10:05:05 pm »
FWIW,

There are almost 100 of these. The UML 2.1.2 superstructure (07-11-02, 07-11-01 with change bars) lists them in Annex B. Also in that annex is an improved [yes, I'm kidding] preamble to explain the notation. It includes the following helpful content:
Quote
...
Keywords are always enclosed in guillemets («keyword»), which serve as visual cues to more readily distinguish when a
keyword is being used. (Note that guillemets are a special kind of quotation marks and should not be confused with or
replaced by duplicated “greater than” (>>) or “less than” (<<) symbols, except in situations where the available character
set may not include guillemets.) In addition to identifying keywords, guillemets are also used to distinguish the usage of
stereotypes defined in user profiles. This means that:
1. Not all words appearing between guillemets are necessarily keywords (i.e., reserved words), and
2. words appearing in guillemets do not necessarily represent stereotypes.
If multiple keywords and/or stereotype names apply to the same model element, they all appear between the same pair of
guillemets, separated by commas:
...
Keywords are context sensitive and, in a few cases, the same keyword is used for different purposes in different contexts.
For instance, the «create» keyword can appear next to an operation name to indicate that it as a constructor operation, and
it can also be used to label a Usage dependency between two Classes to indicate that one Class creates instances of the
other. This means that it is possible in principle to use a keyword for a user-defined stereotype (provided that it is used in
a context that does not conflict with the keyword context). However, such practices are discouraged since they are likely
to lead to confusion.
An earlier version of UML - one of several variants of version 1.4 - went so far as to explain that use of a keyword in a stereotype is "ill-formed" without providing additional advice.

This - the confusion caused by keywords and stereotypes being different, but serving similar purposes with the same notation - all dates back to the very beginning (pre 1.0 days) of UML. It was a poor choice of notation(s) and continues to cause problem. In desperation not to break older implementations the defect [IMHO] has been perpetuated in each version. As the number of keywords explodes this problem has become essentially untenable.

Just beware...

David
No, you can't have it!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8061
  • Karma: +118/-20
    • View Profile
Re: <<realize>> stereotype not in StereotypeEx?
« Reply #3 on: May 30, 2008, 08:33:41 am »
Thank you for the quote about keywords from the specification.  I think that the first part of that particuarly expresses what I was trying to say much more clearly.  (Either that or I have become too used to "specification talk".)

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: <<realize>> stereotype not in StereotypeEx?
« Reply #4 on: May 30, 2008, 09:24:15 pm »
No Simon, you had it right the first time.

I was just trying to ensure that three things were clear. In no particular order:

There are a lot of these things to watch out for.

They can be a real quagmire for the unwary. [And the wary too, as this continues to evolve.]

Sparx did not create or exacerbate this problem; it comes with the territory.

David
No, you can't have it!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8061
  • Karma: +118/-20
    • View Profile
Re: <<realize>> stereotype not in StereotypeEx?
« Reply #5 on: June 02, 2008, 08:29:47 am »
Thanks David,

I didn't think I'd made a mistake, but did appreciate that are more lengthy and formal description could remove possible ambiguities from what I said.

LurkingGrue

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: <<realize>> stereotype not in StereotypeEx?
« Reply #6 on: June 19, 2008, 09:56:05 am »
Thank you both for clearing up my confusion between keywords and stereotypes!  The specification quote was very enlightening, and I appreciate the historical perspective on how the notational confusion has been perpetuated.

I agree that there is still a problem here, though.  The spec suggests that keywords and stereotypes for a given element be comma-separated between a single pair of guillemets.  That might justify listing them together in the StereotypeEx property.

However, anything appearing in the single Stereotype property should appear in StereotypeEx as the automation interface docs suggest.  Otherwise, both properties have to be checked every time.  And you can't just concat them if you're building a list, since Stereotype usually (but not always!) will appear in StereotypEx.  This inconsistent behavior certainly makes for messy code, but at least there is a workaround for now.

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: <<realize>> stereotype not in StereotypeEx?
« Reply #7 on: June 19, 2008, 10:42:32 am »
To make matters worse, you should not have white space between the commas and the items; they will be interpreted to be part of the items themselves, which is unlikely to be your intent.

While this problem is 'how EA does things' it was willed upon Sparx by the specification's legacy issues, as we've discussed above.
No, you can't have it!