Author Topic: Generalization Sets - Can a descendant be in more than one at the same time?  (Read 20228 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8599
  • Karma: +256/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
I'll report some issues with Generalization Sets over the next little while.  This one started as a potential defect in t_xref, but before reporting the defect, I thought I try to get some clarification.

We're implementing the UML standard for extracting the name of the Generalization set into the name of the Generalization Link (as per section 9.7.4 of the UML 2.5.1 Standard) because EA doesn't (AFAIK).
We found a few t_xref entries with more than one Set defined in t_xref.Description.  We checked the link with the GUI and found the values corresponded with what the GUI said.  So the GUI can allow you to make the same link in more than one Set.

My reading of the standard (and, I believe, first principles) says that one Generalization link can ONLY be part of one Generalization Set.  Am I wrong?

TIA,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8064
  • Karma: +118/-20
    • View Profile
Quote
9.9.7.5 Association Ends
...
  • generalizationSet : GeneralizationSet [0..*] (opposite GeneralizationSet::generalization)
    Represents a set of instances of Generalization. A Generalization may appear in many GeneralizationSets.
Yes.

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8064
  • Karma: +118/-20
    • View Profile
We're implementing the UML standard for extracting the name of the Generalization set into the name of the Generalization Link (as per section 9.7.4 of the UML 2.5.1 Standard) because EA doesn't (AFAIK).
While the notation is indistinguishable from the name, I don't believe there is any indication in the spec that any names should be copied (or constrained to be the same.)


Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8599
  • Karma: +256/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Quote
9.9.7.5 Association Ends
...
  • generalizationSet : GeneralizationSet [0..*] (opposite GeneralizationSet::generalization)
    Represents a set of instances of Generalization. A Generalization may appear in many GeneralizationSets.
Yes.
No wonder I missed it!  It's a long way away from 9.7.4!  But thanks for finding it.

I originally (a long time ago) misread this as saying that the general Classifier can exist in multiple Generalization Sets, which is, of course. true.  Re-reading it now, with your assistance, clarifies what is meant.

Notwithstanding what the standard allows, it's our view that while this is theoretically possible, it is to be discouraged (in our case, particularly in our Ontological models).

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8599
  • Karma: +256/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
We're implementing the UML standard for extracting the name of the Generalization set into the name of the Generalization Link (as per section 9.7.4 of the UML 2.5.1 Standard) because EA doesn't (AFAIK).
While the notation is indistinguishable from the name, I don't believe there is any indication in the spec that any names should be copied (or constrained to be the same.)
Accepted, but the pretty clear inference (to us) from the notation examples (Figures 9.15 to 9.22) is that the Generalization Set name should be renderable onto the diagram.  We've chosen to use the Name property for this.  We give it a particular syntax and a pretty colour  :D  to make it as obvious as we can that it is a Generalization Set name.


Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8064
  • Karma: +118/-20
    • View Profile
Accepted, but the pretty clear inference (to us) from the notation examples (Figures 9.15 to 9.22) is that the Generalization Set name should be renderable onto the diagram.  We've chosen to use the Name property for this.  We give it a particular syntax and a pretty colour  :D  to make it as obvious as we can that it is a Generalization Set name.
The generalization set name is being rendered on the diagram as soon as I created it. Are you hiding the stereotype label for your generalizations? The generalization set is being added to that label.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8599
  • Karma: +256/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Accepted, but the pretty clear inference (to us) from the notation examples (Figures 9.15 to 9.22) is that the Generalization Set name should be renderable onto the diagram.  We've chosen to use the Name property for this.  We give it a particular syntax and a pretty colour  :D  to make it obvious that it is a Generalization Set name.
The generalization set name is rendered on the diagram as soon as I created it. Are you hiding the stereotype label for your generalizations? The generalization set is being added to that label.
OH, I can see that now...  We DO suppress the stereotype label for our arcs via shapescripts.  I note that we could suppress the stereotype label on the connectors in the diagram.  We'll need to consider all the options.  We also provide the applicable Generalization Set name to other types of (related arcs) arcs - so it's more complex than just Generalizations and we have a LOT of diagrams that could be affected.

In any event, thanks for clarifying the rendering of the Generalization Set name.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!