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

[Andrew Sutton]

On Wednesday 06 November 2002 5:13 pm, Luis De la Parra Blum wrote:
> > 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?

ah. therein lies the proble, johnny :) actually, a truly compliant UML 
implementation will include MOF. the real question is: do we design for 
generality or do we design for specifically for UML? in my thinking, UML is 
just another (albeit quite complex) modeling language - and we have other 
metamodels to work with: particularly CWM.

i say we shoot for the whole enchilada. the design shouldn't be prohibitively 
complicated, and even if we never do implement other metamodels, we'll always 
know that we can.

> I dont see how you can "completly" separate libUML from XMI reading/writing

well... you do and you don't. basically what you end up with is a "helper" 
library or module that acts as a go-between for libXMI and libUML.

> 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.

i think most other modeling tools have some kind of "Top" package or 
otherwise. visio does this. i believe that argoUML makes you change the name 
of the top package. i think rose uses "Logical View" or something like that. 
we'll have to think about this one. i like argUML. maybe when a new model is 
opened, we should require a top package name.

> 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.

aha! i was wrong. there is a UML::Model element :) oops. but, since Model is 
derived from Package, its kind of the same thing. The semantics of Model and 
Package differ because a Model represents a view of a system... 

but, if that's true, then what the hell is a presentation element??? the 
standard defines a presentation element as a presenter of model elements. it 
also says that its the base class of all view classes implemented by the 
modeling application (sructural diagram, sequence diagram, etc).

the only difference i can see is the aggregation of elements in a model and an 
association for presentation elements. maybe a model is required to have a 
presentation element. i have no idea.

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

there are actually methods to MOF classes that we don't want to implement 
right away. we can postpone that with a bootstrap implementation. however, 
the should be available for the full implementation when libUML is done. 
also, we'd like all our metamodels generated the same way. i don't think 
anybody wants to do that by hand.

> 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.
>
> 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.

can't do it. there's multiple inheritance several places in the UML model (and 
the MOF model for that matter). you get base class ambiguities during 
compling. you'd need to derive from it in the base classes. one way of doing 
this is to derive Ref::RefBaseObject from it.

> 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...

we aren't really changing the metamodel or the metametamodel. we're adding 
functionality for our own uses. i don't see a problem with it. i think uml 
supports enough functionality to model signals and slots on a class (they're 
called signals and receptions).

> 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.

okay.

> 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...

actually, i believe presentation element represents the various diagrams that 
we'd include. i think it would be really cool to make a kpart for each type 
of diagram. how flexible would that be :)

> 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..

uh.. it depends and yes. i think there should probably be some type of diagram 
that allows inclusions from other types of metamodels - if we choose to 
design generically. for other diagrams, it doesn't make much sense.

absolutely. uml is about visual communication so if we can enhance the 
appearance using, say, callouts and labels, then more power to us. i think a 
small set of other widgets should be avaiable.

one thing though: we should never be able to have Model and UML elements 
anywhere near each other. probably not even in the same project. that would 
be very, very confusing. i'd say you either start a UML project or a 
metamodel project.

> 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.

sweet! they might formalize interfaces for presentation elements as well. that 
would be scary.

> [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.

it can be done. there was earlier mention of an intermediary between libXMI 
and libMOF/UML. while it might result in more code and/or more effort, the 
decoupling (on both sides) will result in a much more maintainable product.

the thing is: we need one intermediary per metamodel, so that would be MOF, 
UML, CWM, SPEM (software process modeling or something like that), etc. of 
course, we'd also need a library for each of those. and a GUI library for 
each of those. and get just keeps getting more and more tedious :)

lets put it this way. in the design i'm working on, every metamodel must have 
the following:
	- the metamodel implementation (libUML, libMOF)
	- a reading intermediary (libUML_reader, libMOF_reader)
	- a writing intermediary (libUML_writer, libMOF_writer)
	- a GUI library (libUML_gui, libMOF_gui)

its alot of work. but, it pays off. if you want to build a UML model, umbrello 
just loads those libraries and they work automatically. if you want to build 
a metamodel, umbrello loads the MOF libraries. each part of an implementation 
is almost completely decoupled from every other part of the system. it's 
highly componentized and should be very maintanable.

andy