Package: Set As Namespace Leaf

[Uffe]

Hi!


This feature is intended to improve the display of foreign elements (ie elements from a different package) in a diagram, primarily within large models with recurring package structures.


Let's say you have a model along these lines:
+-- Software Modules
|   +-- Blarg (*)
|   |   +-- Actors
|   |   +-- Use Cases
|   +-- Honk (*)
|   |   +-- Actors
|   |   +-- Use Cases

Ignore the (*) for now.
Let's say in one of my Honk use cases I wish to include a use case from Blarg.
When presented in Honk's diagram, this use case will be labelled "(From Use Cases)".
Since I am using a recurring package structure, this label isn't very helpful: EA displays only the immediate parent package of the foreign element, and that package name occurs in dozens or hundreds of different software modules.

I propose adding an option "Set As Namespace Leaf" to a package. In the structure above, assume I have applied this flag to the (*) packages.

When displaying a use case symbol from Blarg - Use Cases in a diagram in Honk - Use Cases, EA would then label it "(From Blarg)".
In other words, EA searches upwards in the package hierarchy and uses the name of the first package it finds with the "Namespace Leaf" flag set.
If the search hits the root node with no "Namespace Leaf" package found, EA uses the name of the element's immediate parent package (ie today's behaviour).
 
In a use case diagram in Honk - Use Cases, an actor from Honk - Use Cases should be labelled "(From Actors)".
This is achieved by EA performing the "Namespace Leaf" package search twice, once from the element and once from the diagram.
If the first hit in both searches is the same package, ie the element and diagram have the same nearest "Namespace Leaf" package, the immediate parent package name is displayed (again, as today).

This way, Honk actors will be labelled "(From Actors)" in the Honk use case diagrams.
In the same Honk use case diagrams, use cases from Blarg - Use Cases will be labelled "(From Blarg)".
Let's say that one of my Honk actors generalizes a Blarg actor. In the Honk actor diagram the Blarg actor will be labelled "(From Blarg"), while in a Blarg use case diagram, the same actor will be labelled "(From Actors)".

The package symbol in the project browser should be different when the package is a "Namespace Leaf."
Finally, "Namespace Root" is a code engineering concept, while "Namespace Leaf" is a purely visual one. Therefore the option shouldn't go in the same place as "Set As Namespace Root," and perhaps the name "Namespace Leaf" is a bad one.


Cheers,


/Uffe

[Graham_Moir]

Seconded

[Geert Bellekens]

Vote!

We face exactly the same problem, and I had to explain the useless package names in more then one occasion (usually to business type people)

Geert

[Thelonius]

Thanks for setting out the explanation of the request as completely and as accurately as you have, Uffe.

I too would like to add my name to the list of people endorsing this request.

+1

[«Midnight»]

And another...

[skiwi]

I like it, vote

[Paolo F Cantoni]

Me too...

Although I think we (and possibly EA, and perhaps even - as some have suggested - UML itself) may be mixing our metaphors...

If you look at the examples the the Superstructure presents, the namespace is about identifying the root...  So when we say "From namespace" the namespace is the root.  It is self deluding to think that placing the lowest level namespace without qualification as an reference to the source would be suitable.  Uffe's example is just one that blows that idea out of the water...

Since EA allows multiple namespace roots with the same name - all is lost anyway.  Since you can't unambiguously define a source using just one level of a hierarchy, I just remove the namespace visibility from virtually all my diagrams.  As others have said, too often they just get in the way (especially for business punters).

We are mixing the notion of a namespace with the source of an item.  The two aren't the same thing...

Paolo

[«Midnight»]

Me too...

Although I think we (and possibly EA, and perhaps even - as some have suggested - UML itself) may be mixing our metaphors...

If you look at the examples the the Superstructure presents, the namespace is about identifying the root...  So when we say "From namespace" the namespace is the root.  It is self deluding to think that placing the lowest level namespace without qualification as an reference to the source would be suitable.  Uffe's example is just one that blows that idea out of the water...

Since EA allows multiple namespace roots with the same name - all is lost anyway.  Since you can't unambiguously define a source using just one level of a hierarchy, I just remove the namespace visibility from virtually all my diagrams.  As others have said, too often they just get in the way (especially for business punters).

We are mixing the notion of a namespace with the source of an item.  The two aren't the same thing...

Paolo

Paolo makes a very good point here. You can have multiple namespaces with the same 'final' name, but their paths must all be unique across the entire scope of a model. Unless EA updates functionality to show the entire package (namespace) path for elements this might all be for naught.

[Paolo F Cantoni]

Paolo makes a very good point here. You can have multiple namespaces with the same 'final' name, but their paths must all be unique across the entire scope of a model. Unless EA updates functionality to show the entire package (namespace) path for elements this might all be for naught.

Too kind David, but I think I didn't explain my concern well enough.  I suspect, without proof - except to note that EA doesn't enforce unique naming within a namespace, that you could, within the same repository, construct two identical namespace paths, and have two items having different physical paths have the same "namespace name".

We need to clarify that before going to too much trouble.

Paolo

[Uffe]

EA does indeed not enforce unique naming of elements within a package which means, by induction, that you can end up with multiple elements with the same fully-qualified name.

I've written up a separate feature request to help with this issue, which I believe goes right back to the UML standard: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1249971647.

The "namespace leaf" feature was not intended to address the uniqueness issue, but to allow display of (two) different source packages for one element depending on display context, purely for readability purposes when using recurring substructures in a model.

/Uffe

[Paolo F Cantoni]

EA does indeed not enforce unique naming of elements within a package which means, by induction, that you can end up with multiple elements with the same fully-qualified name.

I've written up a separate feature request to help with this issue, which I believe goes right back to the UML standard: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1249971647The "Namespace leaf" feature was not intended to address the uniqueness issue, but to allow display of (two) different source packages for one element depending on display context, purely for readability purposes when using recurring substructures in a model.

/Uffe

Understood Uffe (and I did agree with your suggestion).  

But the printed page doesn't know you're using recurring structures it just shows: (from xxxxxx).  So if you're not going to be able to find xxxxxx easily it may still be a problem.  I guess that's up to the modeller I suppose.

By the way, I think you can have multiple Namespace Roots in the same path.  Have you considered the situation where you might have several Namespace Leafs in the same path - I  assume you'd stop at the first found.

Paolo

[Geert Bellekens]

By the way, I think you can have multiple Namespace Roots in the same path.  Have you considered the situation where you might have several Namespace Leafs in the same path - I  assume you'd stop at the first found.

Paolo

Paolo, I agree if "the first found" has to be understood as the first one when traversing bottom up. (so the most "leafiest" leaf is displayed)

And given the other post about the uniqueness of names in a namespace it might be a good idea to drop the term "Namespace" and use something else for this feature. Maybe "Context"?

Geert

Geert

[Paolo F Cantoni]

Agreed and agreed...

Paolo

[«Midnight»]

Of course we should still be able to turn this off by clearing the strict UML option...

[Roddy]

Uffe's start post - yiz, I'd vote 4 that.