Nesting classes (and generalization)

[Modesto Vega]

I have been extensively using nested stereotyped classes each time that a generalisation is involved; for example:

Diagram
-----Structure Diagram
----------------Class Diagram
----------------Component Diagram
-----Behaviour Diagram
----------------Activity Diagram
----------------Use Case Diagram

In some diagrams I want to depict the generalised classes inside the generalising classes (to save space) and in other diagrams I want to depict a hierarchy. If the classes are nested, Sparx allows me to do the former but does not like me doing the later.

Other than not nesting the classes, is there anything I can do to be able to create both diagrams?

[Geert Bellekens]

Nested classes is a bad idea in general which you should only use if you really mean nested classes, not to express inheritance.

Geert

[KP]

Geert is right. Nested class is inner class, not sub-class.

[Paolo F Cantoni]

Geert is right. Nested class is inner class, not sub-class.

AND you MUST distinguish visual embedding versus nesting.

For example, the ArchiMate Language allows you to visually embed one element inside another to indicate one of a small number of relationships between the two elements. BUT that is NOT the same as nesting the two items - which Sparx often does for you (INCORRECTLY).

For the record, Nesting is about access (as KP said) it's an inner-class which should not be able to be accessed without passing through the outer class.  Specialization (get into the habit of calling it Specialization rather than Generalization) is about creating a (specialized) sub-class with a structure similar to the base - whereas there is NO such requirement in the nested class.

The whole NESTING functionality in Sparx EA is much less than optimal.  In trying to be "helpful", it serves merely to make everyone confused - since it doesn't actually make sense.

In our framework, we go to extreme lengths to stop Sparx "nesting things" and in fact if we find it has we un-nest them - automagically.  Solves a whole pile of problem.

Paolo

[Glassboy]

example, the ArchiMate Language allows you to visually embed one element inside another to indicate one of a small number of relationships between the two elements. BUT that is NOT the same as nesting the two items - which Sparx often does for you (INCORRECTLY).

If you nest two elements in Archi it asks you what the relationship is.  For example, if you nest an application component inside another application component it asks if the relationship is a composition or an aggregation.

[Paolo F Cantoni]

example, the ArchiMate Language allows you to visually embed one element inside another to indicate one of a small number of relationships between the two elements. BUT that is NOT the same as nesting the two items - which Sparx often does for you (INCORRECTLY).

If you nest two elements in Archi it asks you what the relationship is.  For example, if you nest an application component inside another application component it asks if the relationship is a composition or an aggregation.

But you can also visually embed (it's not nesting  ) specialization (AFAIK)


Paolo

[Glassboy]

example, the ArchiMate Language allows you to visually embed one element inside another to indicate one of a small number of relationships between the two elements. BUT that is NOT the same as nesting the two items - which Sparx often does for you (INCORRECTLY).

If you nest two elements in Archi it asks you what the relationship is.  For example, if you nest an application component inside another application component it asks if the relationship is a composition or an aggregation.

But you can also visually embed (it's not nesting  ) specialization (AFAIK)

IMHO architects who habitually visually embed elements are very lazy and inconsistant modellers.

[Paolo F Cantoni]

[SNIP]
IMHO architects who habitually visually embed elements are very lazy and inconsistent modellers.

I believe, what you meant to say was: architects who habitually ONLY visually embed elements are very lazy and inconsistent modellers.

Visual embedding is an exposition mechanism NOT a definition mechanism!

The problem with the metaphor (for the resulting diagrams) is that there is NO indication as to which of the relationships are being used.  Of course, you mustn't mix them.

In our framework, we have instantiated the concept of the Generalization Set (Specialization Set) to allow multiple Set types.  We see NO reason why the metaphor should not be extended to ALL relationship types, SO LONG as the type is clearly communicated. 

It is the rendering of the instantiation of the set with the items visually embedded within it that indicates the nature of the set (Specialization, Aggregation, Composition, Association etc.).   

The instantiated set element also renders the total set membership, whether it is disjoint and/or covering.  Therefore you can tell if what you are seeing in front of you is the "full picture".

The set element is interposed between the encompassing element and the set members - both within the repository and on the diagram.   You're not allowed to have a visually embedded element without having specified the relationship.

Paolo

[Modesto Vega]

I wasn't expecting such a reply, thanks for the contributions.

Reading through the answers, I suppose an important part of the question is: when is it reasonable to use nested classes?

[SNIP]
AND you MUST distinguish visual embedding versus nesting.

For the record, Nesting is about access (as KP said) it's an inner-class which should not be able to be accessed without passing through the outer class.  Specialization (get into the habit of calling it Specialization rather than Generalization) is about creating a (specialized) sub-class with a structure similar to the base - whereas there is NO such requirement in the nested class
In our framework, we go to extreme lengths to stop Sparx "nesting things" and in fact if we find it has we un-nest them - automagically.

[SNIP]
Visual embedding is an exposition mechanism NOT a definition mechanism!

In our framework, we have instantiated the concept of the Generalization Set (Specialization Set) to allow multiple Set types.  We see NO reason why the metaphor should not be extended to ALL relationship types, SO LONG as the type is clearly communicated. 

The set element is interposed between the encompassing element and the set members - both within the repository and on the diagram.   You're not allowed to have a visually embedded element without having specified the relationship.

Paolo

Paolo is correct
1) I am looking at representing specialisation (rather than generalisation) at a conceptual/abstract level which is often close to typing; please note that not all conceptual/abstract classes have a code implementation
2) I am visually embedding conceptual/classes for exposition/presentation reasons: it communicates the message better and it reduces the size of the diagrams
3) All visually embedded elements have a specified relationship, which is always an specialisation (but could be anything else)

IMHO architects who habitually visually embed elements are very lazy and inconsistant modellers.

If you have never faced a situation where you had to use visual embedding you are not modelling something too complex, or you do not print your diagrams, or you are not very environmentally conscious.
Conclusion, get rid of a bad having (nesting) and stop Sparx from automagically “nesting things”.

[Geert Bellekens]

Sometimes the automatic nesting is a good thing.
For example when using BPMN diagrams, or modelling user interfaces.

The option Tools|Options|Objects|Support for Composite Objects controls the automagical nesting behavior.

Geert

[PeterHeintz]

From my experience nesting things in other things can have many meanings and use cases.
Nesting a Class on another Class is an Inner Class
Nesting something in a package is containment, typically with some namespace semantics.
Nesting e.g. class typed properties in classes nest class instances in classes.
…
The problem I see with EA is that it sometimes allow to nest things that should not be allowed, it do not allow to nest things that should be allowed, it is inconsistent in what is allowed on a diagram and on the project browser to be nested and at least for SysML it do not allow lot of things needed to define the characteristics “stamping” of properties/instances.

[Modesto Vega]

Sometimes the automatic nesting is a good thing.
For example when using BPMN diagrams, or modelling user interfaces.

The option Tools|Options|Objects|Support for Composite Objects controls the automagical nesting behavior.

Geert

I will always learn something from you. Pity it cannot be done by type.

[Glassboy]

If you have never faced a situation where you had to use visual embedding you are not modelling something too complex, or you do not print your diagrams, or you are not very environmentally conscious.

I visually embed where it is useful, subcomponents in components et al.  However I also see I lot of Visio-upping of designs that are ambiguous and just the result of the architect not taking the time to model properly. 

[Paolo F Cantoni]

From my experience nesting things in other things can have many meanings and use cases.
Nesting a Class on another Class is an Inner Class
Nesting something in a package is containment, typically with some namespace semantics.
Nesting e.g. class typed properties in classes nest class instances in classes.
…
The problem I see with EA is that it sometimes allow to nest things that should not be allowed, it do not allow to nest things that should be allowed, it is inconsistent in what is allowed on a diagram and on the project browser to be nested and at least for SysML it do not allow lot of things needed to define the characteristics “stamping” of properties/instances.

Excellent points and conclusion!


Paolo

[Paolo F Cantoni]

If you have never faced a situation where you had to use visual embedding you are not modelling something too complex, or you do not print your diagrams, or you are not very environmentally conscious.

I visually embed where it is useful, subcomponents in components et al.  However I also see I lot of Visio-upping of designs that are ambiguous and just the result of the architect not taking the time to model properly.

You reminded me of one of my better (if I may say) aphorisms:

Manage Complexity,
   .   .   Reduce Ambiguity,
   .   .   .   .   Eliminate Inconsistency! ^TM

Paolo