[Uml-devel] Re: Umbrello design (was UML XML tree viewer)

[Luis De la Parra Blum]

> BUT! because we agree that implementing MOF, Umbrello can be much more than
> just a UML modeling tool. it can be a generic modeling tool that

wait a sec!, this seems to be the first point we need to clear...
do we want Umbrello to be a "universal Modeling tool" or do we want it to be a 
"UML Modeling tool" ??
And... if the answer is to go for the whole thing, then, do we want to do it 
all in one step, or first get UML and then "generalize" it untill we get MOF?

>
> > libUML is a piece of code (most likely a library) that reads UML models
> > stored in XML / XMI and generates a model out of it.
>
> no. libUML implements classes and relationships of the UML domain model.
> ideally, it has nothing to do with reading XMI files. of course, this is
> (in my thinking) almost impossible - or at least very ugly to separate.
> just think of libUML as providing access to a very complicated data model
> for some application.

I dont see how you can "completly" separate libUML from XMI reading/writing
>
> unfortunately, UML doesn't have a model element. it just has packages. the
> UML XMI file should contain a single package. in fact, if you read the JMI

yes, unfortunately UML doesnt have a model element, I guess they "forgot" to 
put it in =))
however I do think we need to have a Model in Umbrello... this is where all 
the objects will live. We cannot have a Package as the top element because a 
model can have several packages... hm.. wait.. that's not a good argument 
because a package can contain other packages, but still... I think we should 
have a model.

Coming back to what you mentioned, who says that a UML XMI file should contain 
a single package?
if you look at section 5.2 of the UML spec, in the XMI example, right after 
the header there is a "content" element which has a UML:Model element.
I dont see why there could not be another Model element after that...
It's only that it makes more sense to store one model per file.

> > question: is there much difference in implementing libMOF_bootstrap to
> > implementing libMOF directly?  (ie, cant we skip this extra step?)
>
> not really. in fact, we should be able to use the bootstrap implementation
> to generate libUML directly. the only reason we'd recreate libMOF is to
> make its implementation follow the patterns prescribed by our metamodel
> code generator.

I still dont see the difference betwen libMOF and the bootstrap... except that 
sounds cool to say that our libMOF generated itself =)

> man... i've thought so much about this, and i'm just starting to figure it
> out. deriving from QObject would be a *huge* bonus for libMOF, libUML,
> libCWM or whatever.
I think we *must* derive from QObject.. we could maybe get away without doing 
it, but I dont see why we shouldnt take advantage of the benefits this would 
give us... specially the Signal/Slot mechanism.

> however, this is kind of tricky. we can only derive from QObject in classes
> that are leaf nodes of the inheritance tree. in fact, we can only derive

why? I was thinking of deriving ModelElement from QObject !!
in the specs ModelElemnt derives from Element, which as far as I can tell is 
an empty class.. so I'd say we just change Element for QObject and we are 
set.. then we could add signals and slots only to some classes, but since all 
are derived from QObject we would have no real limits in that.

> no. the metamodel code generator must do this for us. remember, this code
> generator is going to generate code specifically for umbrello's design.

so, maybe you can do this for libMOF, but doing the same for libUML would not 
be that easy... how is the code generator supposed to know that a method is a 
signal or slot?
The only way I can think of is with a UML Profile for QT, but we'd be 
extending the language already... maybe with tags attached to the 
operations...

> right. as i mentioned before, it should all be contained in a package - not
> a model.
no, I insist in having a model which can contain packages and other elements.
I think that not all elements must be contained in a package... what about 
elements in the "global scope"? these should go directly under the Model.

>
> every model element in uml has 0..* presentation elements. i believe that a
> presentation element is probably some kind of view (i.e. diagram). if we
> subclass our diagrams from UML::PresentationElement then that capability is

I think we should have a UML::PresentationElement, and some derived classes 
like ClassWidget, UseCaseWidget, etc.
PresentationElement is some kind of QWidget or QCanvasItem, and has a 
reference to the Model element it is representing... when something changes 
in the Model element, the presentation object updates itself.
This is what I tried to explain in the Diagram I sent to the list a couple of 
weeks ago...
now.. talking about PresentationElements...
Question: do we want to have *only* UML elements in the diagrams?? (or more 
general, Model elements --in case we decide to make umbrello a general 
modeling tool)
... or should we allow graphical elements with no meaning for the diagram? for 
example, putting a simple rectangle to separate objects in a client from 
objects in a server (I think there are UML diagrams to do this, but having 
certain shapes in the diagram, with no real meaning for the model itself can 
be nice sometimes)
another example would be to have a "DataBase" widget close to a 
DataBaseManager object.. just to give a better visual representation..

> built in for us. of course, if we do that, we can save diagrams directly
> into the XMI file (as, say, SVG) without sacrificing compliance).

definetly all diagrams should be stored in SVG. The new version of UML (and 
its corresponding XMI format) will include this, so that not only the models 
but also the graphic representaion of them can be portable across tools. I 
read somewhere in the omg pages that this information is going to be stores 
in SVG... so if we use this format from the beginning adopting the new UML 
standard should be no big work.

>[andrew:]
> as mentioned, neither libUML nor libMOF is responsible for saving or
> loading documents. libXMI is primarily responsible for that capability.
.[pascal:]
> have a library giving you some API to access XMI files. Then you have a
> object (the walker) which 'reads' the UML model, and 'writes' it to the
> XMI file. This is a neat way graph walking algorithms can be
[luis]
this would mean that the walker --or whatever implementation we choose for 
libXMI has to know the UML model... I mean, we cannot have a "generic" libXMI 
which parses all kinds of XMI files.  it has to know all the elements in the 
UML model so that it can query them and write the file, and it need to know 
for which nodes to look for in the DOM tree and how to create elements based 
on the informatino found.
As I understand this, the libXMI would be so coupled to the UML implementation 
that I dont see much point in putting it in a different library.

luis