Nested classes: hide parent class names

[Guillaume]

Hi,

Working on a large conceptual data model with a team, we decided to nest classes in the Project Browser as it was convenient for this context:
Root
+ Class1
  + Class11
+ Class2
  + Class21
  + Class22
    + Class221
    + Class222
    etc.

I have an issue in using these classes on diagrams i.e. they're displayed with the full path e.g. "Class2 :: Class22 :: Class222"
To my surprise I cannot find an option in the diagram properties to hide the parent classes to display e.g. Class222.

Am I missing an easy trick here?

Thanks

[Geert Bellekens]

I don't think you can do anything about that in the case of nested classes.

I would reconsider nesting classes, but if that is not an option I think you'll have to create your own stereotype and attach a shapescript to it.
Downside of the shapescript option is that you cannot fully recreate the attributes compartment with a shapescript.

Geert

[Guillaume]

Thanks for the reply Geert.
I'd rather avoid the Shapescript solution so I'll find a different way to organize the model.

Guillaume

[Paolo F Cantoni]

I don't think you can do anything about that in the case of nested classes.

I would reconsider nesting classes, but if that is not an option I think you'll have to create your own stereotype and attach a shapescript to it.
A downside of the shapescript option is that you cannot fully recreate the attributes compartment with a shapescript.

Geert

(my emphasis)
Guillaume,

Geert is correct.  EA unnecessarily (and in my view, incorrectly) nests things in the browser.  Nesting is a structural issue to do with access to the nestling via the nest item.  I have mentioned this many times.  Accordingly, through our entire repository, consisting of 10s of thousands of items, the ONLY nested items are embedded items (such as ports or interfaces).  In fact we have a routine that specifically unnnests incorrectly nested items.  All other elements are related via their appropriate relationships.

Solves SO MANY problems for us.

Paolo

[Arshad]

Try Checking Disable Fully Scoped Object names and Show Namespace under appearance in Diagram Tab of diagram properties



or

Checking Disable Fully Scoped Object Names in Diagram tabs for entire model



 

[Geert Bellekens]

I don't think you can do anything about that in the case of nested classes.

I would reconsider nesting classes, but if that is not an option I think you'll have to create your own stereotype and attach a shapescript to it.
A downside of the shapescript option is that you cannot fully recreate the attributes compartment with a shapescript.

Geert

(my emphasis)
Guillaume,

Geert is correct.  EA unnecessarily (and in my view, incorrectly) nests things in the browser.  Nesting is a structural issue to do with access to the nestling via the nest item.  I have mentioned this many times.  Accordingly, through our entire repository, consisting of 10s of thousands of items, the ONLY nested items are embedded items (such as ports or interfaces).  In fact we have a routine that specifically unnnests incorrectly nested items.  All other elements are related via their appropriate relationships.

Solves SO MANY problems for us.

Paolo

There are a few more cases in which we use nesting:
- Class -> StateMachine -> States
- Activity -> Actions
- BPMN Business Process -> Pool -> Lane -> Task

But in general I try to avoid nesting as much as possible (e.g. no requirement nesting, no (ArchiMate) business process nesting,...)

Geert

[qwerty]

Encapsulation is a proven concept.

q.

[Geert Bellekens]

Encapsulation is a proven concept.

q.

Sure, but that doesn't mean you should create nested classes all over the place.
In all the years I've been doing OO programming I only wrote a handful of nested classes.

Also, I'm not sure if that is the driver here, since Guillaume is talking about a conceptual datamodel. It would be interesting to know why they choose for nested classes.

Geert

[qwerty]

indeed. My need for nested classes was also significantly low. So knowing the background here would be interesting.

q.

[Guillaume]

Thanks for your additional replies.

The option mentioned by Arshad is the answer to my initial query.
However I'm investigating the pros/cons of having nested classes versus creating packages in between e.g.
Pkg C1
+ Class C1
+ Class C2
+ Pkg C1
  + Class C11
  + Class C12
+ Pkg C2
  + Class C21
  + Class C22

As potential issues with classes nesting :
 - issues when extracting or processing them via scripting,
 - classes moved in the tree when moving classes on a diagram?
 - classes or attributes moved by mistake when accessing/manipulating infos via the Project Browser

Like I said this is a conceptual model and some users liked the way one can expand a class to see its subclasses and so on, but it won't be used if it's a bad idea.

[Geert Bellekens]

Like I said this is a conceptual model and some users liked the way one can expand a class to see its subclasses and so on, but it won't be used if it's a bad idea.

I would definitely go for the package structure. There are just too many downsides to nesting to be practical

Geert

[qwerty]

As potential issues with classes nesting :
 - issues when extracting or processing them via scripting,
 - classes moved in the tree when moving classes on a diagram?
 - classes or attributes moved by mistake when accessing/manipulating infos via the Project Browser

- There are no issues. Both ways can be addressed with scripting equally
- No. What you see on a diagram is a representation (diagram object) of the original element. Diagram moves will not move the element itself.
- That can happen in either case.

So if that's what you have, I don't see a reason for nesting classes rather than using packages.

q.

[Glassboy]

Given the OP said that this is a conceptual data model, the nesting would seem to be a proxy for another relationship, or purely for visual ordering.

Both would seem to be problematic at a conceptual level.  At a conceptual level a package that is a big bucket of stuff is fine.