[Uml-devel] Re: karbon14 and uml

[Dirk Schönberger]

> I'm not really sure if a file system like approach would be best. Ok, I
have
> to say it is very uncommon and I would expect it as user. So you might
have
> a very high learning curve to get used to it.

Why? All you do is browsing some hierarchies. I tend to see things like XMI
as a special kind of container,
i.e. you have end nodes, like the documents, and further hierarchy nodes,
like sub-folders.
And you have a defined set of actions you can do with the nodes (create
document, delete document,
view document, edit document, create subnode, delete subnode, parse subnode,
move and copy documents to another node.
For a full featured "tree management" system you need this functionality
anyway. I think it is better to use existing software, and provide some kind
of plugin, instead of implement the functionality in your own, substandard
ways.

> I think it is very clear that a standard tree view approach is very boring
> and not the best method to browse complex data. But I think a file system
> isn't a very good abstraction as well. Because file systems are
representing
> the structure the files are stored on the harddisk. This is mostly useless
> for the user. A user (I mean not a hacker) wants to store his documents in
> folders connected to special subjects or times. So I think a file system
> isn't perfect and it is not the way we should go.

- A file system defines just the above mentioned actions and object nodes.
It doesn't say anything about the represenation. I think an older project,
which was unfortunately rejected in KDE, implemented a treemap visualization
of a file system.
I think this is the power of a file system approach. You have a defined set
of objects and their hierarchies, and you can implement multiple view about
that data.

A file system don't necessarily have to be some bytes on a hard disc.

> And yes, you could render a UML modell as HTML and offer some kind of
> navigation. But, as someone else said before, browsers are good for
> presenting data, but not for manipulation.

Agreed. At least currently, file system views are more suited for displaying
purposes.

> I think we have to ask ourselves how we want to handle a software modell.
An
> architect could make a modell of his building. Car builders have modells
in
> 3D CAD and maybe as small version with rapid prototyping (printing of 3D
> modells).

And software developers have their UML diagrams, i.e. special kind of
documents in a package tree.
If the packages are stored in a XMI file or a stored ZIP file, or
uncompressed on a har disk, is a irrelevant implementation detail...

> Some years ago I did a lot of 3D modelling for rendering. There you find
> very different interfaces as well. The one I liked most was an interface,
> where you saw your modell in 4 different views at the same time. The
screen
> was splitted into 4 sections, 3 showing 2D views of the modell and 1
showing
> a OpenGL version of the modell. It was very good. You edit the modell in
2D,
> but you can see the difference immidiatly in 3D.

Sorry, but I absolutely hated old-school 3D modellers with their custom user
interface.

> Maybe this would be also a solution. Give the user the possibility to
switch
> very easy between different views on the same subject. Like rotating the
> whole information cube.

But what are the different views of a software model?

Regards
Dirk