[Uml-devel] Re: karbon14 and uml

[Dirk Schönberger]

Sebastian Stein schreibt:

> 
> Really? I'm not sure about that. Of course if you stay in the logical view
> you just have a hierarchie, but now you switch to another view and you are
> looking at the same hierarchie from a very different point.
> 
> Let's look at a package diagram. There you have stereotypes <<uses>> and
> <<includes>>:
> 
> 1. <<includes>>
> 
> package1 <<includes>> package2 and package3.
> package3 <<includes>> package4 and package5.
> 
> 2. <<uses>>
> 
> package1 <<uses>> package4 and package2
> package2 <<uses>> package3 and package5
> 
> Now draw this diagram and you will see that the representation changed
> completely. I don't know how to handle this in file browser approach. But if
> you find a good solution, I would be the first to experiment with it!!!

I think stereotypes are not really a part of the "object model" of UML, but
rather a way to express custom meanings to elements. So as long as you
don't provide renderers for my stereotypes <<clone>> and <<rather
unimportant package>> I think it would be appropriate to render the
underlying relationships as simple hyperlinks, with the stereotypes as
labels.

> Another point very important. You have file browsers like Konqueror or MS
> Explorer. But you are more productive with a file browser like
> MidnightCommander or TotalCommander. So both types are showing the
> hierarchie, but the handling is different. So I would say that Konqueror
> style don't have to be the best to handle hierarchies.

Not me. As soon as I see a file manager with a fixed two column layout, I
have to curse as much that all possible productivity would be lost. I
really can't stand that kind of file manager. Sometimes I need things like
the detail view in Konqueror or Explorer, but a fixed two column view with
tabular data which is forced on me is nothing I want to work with.

> And another point. Let's reduce Konqueror to it's base. It is nothing more
> than a giant tree view. Nothing more.

No. Konqueror provides a framework for multiple views which are used over a
general model, an abstract file system and come contained documents. A
treeview is a possible view, but not the most important. Normally I browse
without treeview.

> 
> Ok, but this is only a question how the data of the modell is stored/handled
> internally. If a file system would be best, ok, I could accept it. But I
> think we allready have something like a DOM tree and there are not so many
> differences between a file system and a DOM tree.
>  

I think a file system like approach would be nice for communicating with
the rest of the system. Something like "lets copy this diagram from this
package in this XMI file to the local file system". The process of copying
would involve generating of HTML or SVG content, which would be some kind
of "external representation" of the diagram / package.

An DOM tree (or rather an internal representation based on the DOM tree)
would be find for internal work, like a overview about the classes in a
package, or the fields and methods in a class.

> 
> Look at the current CVS version of Umbrello. There you can see 4 different
> views. Maybe there are more, maybe not:
> 
> - Component View
> - Deployment View
> - Logical View
> - Use Case View
> 

But these are not really views, i.e. multiple visual representations of the
same data. I think you should rather see it as different documents showing
different contents. It would be not feasible to e.g. drop a class icon from
component view to usecase view.

Regards
Dirk