Hej!
As Q said, roots and views are still in there for historical reasons. There's no UML reason for them: the UML standard says nothing about the organization of elements, packages and diagrams, leaving it entirely up to the toolmakers. Sparx have removed the earlier restriction on moving packages to the view level and vice versa, so that's a step in the right direction, but it's still an archaic pair of concepts.
In practice, root nodes are different from other packages in that they are not backed by an element. In EA, most properties (such as tagged values) belong to elements, and (non-root) packages have a double nature in that they are both a package and an element. This way, packages can have tagged values, can be the endpoints of connectors, and can be shown in diagrams -- but root nodes can't.
Now if I may be permitted some musings on the subject --
All trees must have a root. That's just the nature of the beast. The problem is that EA hasn't made up its mind whether the browser shows one tree, or several trees.
If it's one tree, then there should be no difference between a root node and other packages. There is then an actual root node which is the parent of all the packages you see at the top level, but this actual root node is hidden from view.
It need only be a package (not a package and an element), so the equivalent of the current root nodes. It should always have ID 0 and not be deletable, and the Repository.Models API call should return the children of this hidden root node.
This would make it possible for the highest-level visible packages to contain diagrams, have connectors and tagged values, be shown in diagrams, etc.
You should be able to do most package-related things to the hidden root, including import, export, version control, baselines, etc. You could access these functions in the browser by right-clicking the "Project" tab of the browser window itself. Alternatively, you could access them by right-clicking an empty area with nothing selected (it should then also be possible to explicitly select nothing in the browser).
If on the other hand the idea is that the browser shows several trees, then there needs to be functionality restricting the use of elements between trees (connectors between elements in different trees, showing an element from one tree in a diagram belonging to another, using an element from one tree as a RefGUID tag in an element belonging to another, etc), to make sure such use is strictly one-way.
You would then also need to restrict the movement of packages, elements and diagrams between trees, to make sure the one-way-use rule would not be violated.
The idea here is that a tree represents a unit of modelling (arbitrarily large) which has some management rules associated with it. This makes it a stronger concept than the current root node, which is just a package that's not quite a package.
Neither suggestion would be a simple change. There might well be weird stuff related to root nodes (and views, still) deep in EA's core code. But it could be worthwhile. I think the first idea, with a single hidden package-only root node, probably has the least impact, and is also at the end of the day probably the better one.
Indepentently from those lofty ideals, it would make sense to just drop the view level already, and at the same time introduce the option of showing an arbitrary icon in place of the current view ones. This icon should be shown within the outline of a package symbol, and be overridden as necessary (eg version-controlled packages).
I'm not sure whether browser icons are in fact supported for package stereotypes, but since you can't selectively switch off presentation of package stereotype names in the browser (got a suggestion coming up about that), it would be useful not to have to introduce a package stereotype just to show a different icon -- which is all that views do anyway.
Thank you for tuning in to today's episode of Screaming Into the Void.
/Uffe
