Generalization notation

[qwerty]

A class shown on a diagram without the class from which it is specialized is shown with the name of the general class in italics top right of class compartment. Now I have fostered UML 1.5 and 2.5 but could not spot any reference which rectifies this notation. So I guess, this is a bug?

q.

[KP]

Don't know where the notation comes from, but you can turn it off with Tools > Options > Diagram > Behavior > Show Hidden Parents

[qwerty]

I don't want to be picky, but is a tool that claims to be UML compliant still compliant if it offers a non-compliant presentation? I never questioned that this notation comes from UML specs until someone on StackOverflow asked me specifically. (Similarly the composition symbol which is not described in Superstructures, but where at least a singular reference has been used in 1.5.)

q.

[Geert Bellekens]

EA offers loads of non UML compliant notations (ERD, GUI wireframes, ...), but I don't see why that would make it non-UML compliant.
As long as it also offers a UML compliant one I guess it is UML compliant.

Geert

[Paolo F Cantoni]

As I've observed here (perhaps for nearly a decade) the implementation of this feature is incorrect and can lead to misreading of the diagram - and consequenct misunderstanding of the model.

The intent of the feature SHOULD be to indicate that where the Generalization relationship is NOT visible on the diagram, the additional parent should be shown - whether or not the parent is on the diagram.

There is no indication (EAUI) that the base item is related by Generalization to the specialized item if the relationship is not visible.  Consequently (with the current implementation), if I can't see that something is a parent then I, ipso facto, can't tell if its a hidden parent (that is, the parental relationship is not visible).

(just thought I'd give this another bump).

I probably put in a bug report a decade ago, but I could do it again if others agreed with the contention.

Paolo

[Glassboy]

I use this feature all the time, if it was removed I'd have to find another way of achieving the same thing.

[Paolo F Cantoni]

I use this feature all the time, if it was removed I'd have to find another way of achieving the same thing.

As do I! I just think it should be implemented correctly.  The current implementation is only a subset of the correct one.


I am certainly NOT suggesting that it should be removed.


Paolo

[Glassboy]

I have to admit to not understanding why turning on "Show Additional Parent" and "Show Hidden Parent" only shows the generalize parent and not the implements parent.

[Paolo F Cantoni]

I have to admit to not understanding why turning on "Show Additional Parent" and "Show Hidden Parent" only shows the generalize parent and not the implements parent.

Perhaps because the implements is an In Vitro fertilization? 


Seriously, though, it does go to what we mean by parent.


Thoughts?


Paolo

[Glassboy]

Thoughts?

I think that may have been a pun too far. 

I'm wondering if there is actually the need for a class-like diagram for logical modelling with more permissive options for those of us with a less than Teutonic need for adherence to the UML rules.  I don't use a class diagram for any sort of code engineering.  I use it to create semantic models and show how attributes flow through multiple systems (eg Active Directory into Cisco Call Manager or Follow-me printing)

[Paolo F Cantoni]

Thoughts?

I think that may have been a pun too far. 

I'm wondering if there is actually the need for a class-like diagram for logical modelling with more permissive options for those of us with a less than Teutonic need for adherence to the UML rules.  I don't use a class diagram for any sort of code engineering.  I use it to create semantic models and show how attributes flow through multiple systems (eg Active Directory into Cisco Call Manager or Follow-me printing)

Well, I ALWAYS have strict syntax OFF.

But by implements parent do you mean the destination of a Realization relationship?  If so, then my view is that parent (as in the sense of antecedent) is not an appropriate semantic concept here. 


The primary semantics of the Specialization relationship is that of inheritance - as from an antecedent - thus "parent" is applicable.  (Hence why ArchiMate puts it in a section of its own).

The relationship between the more concrete and the more abstract item in a Realization is not that of parent-child but, as you say, more concrete implements more abstract.

Now, I think your suggestion of having the realized destination listed similarly - but distinct from - the more generalized destination (if the relationship is missing) is excellent and I support it, but they aren't the parents.  So they should have their own User Experience controls.

And it shouldn't interfere with Code Engineering in any way.

Paolo

[Glassboy]

But by implements parent do you mean the destination of a Realization relationship?  If so, then my view is that parent (as in the sense of antecedent) is not an appropriate semantic concept here. 

My bad, I'd never checked the help text on that dialog (Ctrl + I), it seems it does dual duty with selecting the "interfaces  it realizes (implements)".