Sparx Systems Forum

Enterprise Architect => Uml Process => Topic started by: Paolo F Cantoni on September 20, 2019, 04:28:39 pm

Title: Generalization Sets How should they work?
Post by: Paolo F Cantoni on September 20, 2019, 04:28:39 pm

I received the following response from Sparx:

The intended behaviour is when multiple sets are defined, generalization sets are drawn as comma-separated on the diagram and the generalization dialog loads corresponding subtypes for with respect to the selected set

It is my understanding that it is NOT possible for there to be more than one Generalization Set (because you can only define one PowerType) per Specialization/Generalization arc.  Consequently, the notion of comma-separated Generalization Sets is invalid.

I accept that a given specialized item may be a member of more than one Generalization Set to the generalized item, but that requires more than one PowerType and therefore more than one arc.

Thoughts?  I know very few users use Generalization Sets, but you should!  ;)
Paolo

Title: Re: Generalization Sets How should they work?
Post by: Geert Bellekens on September 21, 2019, 03:12:28 am

The problem with generalization sets is that they are only understood by the (very) few information modelers who use them.

In my experience they are not understood by business users, or by technical oriented users (such as developers)
A model that contains information that is so hard to communicate is maybe not the best model.

Geert

Title: Re: Generalization Sets How should they work?
Post by: Paolo F Cantoni on September 21, 2019, 11:14:32 am

Quote from: Geert Bellekens on September 21, 2019, 03:12:28 am

The problem with generalization sets is that they are only understood by the (very) few information modellers who use them.

In my experience, they are not understood by business users, or by technically oriented users (such as developers)
A model that contains information that is so hard to communicate is maybe not the best model.

Geert

Maybe we haven't explained them well.  I hope I DO understand them and can communicate their utility.
I agree that the definition in the UML specification are somewhat dense.

It's a bit like the Helsinki Principle I refer to in my signature:  In its original form, its couched in diplomatic speak, almost unintelligible.  In its redux it's easier to understand:
"If we can’t agree on the words, what they mean, and how they’re to be used, we’re sunk!"

^{Paolo Cantoni (2013)}

Paolo