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

Luis De la Parra lparrab at gmx.net
Thu Nov 7 03:01:01 UTC 2002


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

a UML implementation is some kind of specialitation of MOF.. I mean, a MOF
tool
can do more than a UML tool because with it you could create UML and then
the UML models you want...
but ok, lets go for all of it.

> 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 n
> ame  of the top package. i think rose uses "Logical View" or something
like th

as I remember it, in argo the top level element is called "Model" .. I think
the default
name they used is "unamedModel" and you are supposed to change it later =)


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

The standard says there is a "PresentationElement" which is the base for all
visual
representations of the elements in the Model. the problem is that the
current specs dont really
define what this thing is supposed to do, so 
I had always thought of it as the base for a "ClassWidget", "ActorWidget"
etc.
all this PresentationElements represent an element in the model (UML::Class,
etc) and they
all  live in a Diagram, which is just a Canvas...

you see the PresentationElement rather as the base for the Diagram itself,
right?
and does the ClassWidget also derive from it?

> > why? I was thinking of deriving ModelElement from QObject !!
> > in the specs ModelElemnt derives from Element, which as far as I can te

> can't do it. there's multiple inheritance several places in the UML model

well... altough I have never used it in real life, I always thought thats
what virtual
inheritance is supposed to do. If we have virtual hineritance from QObject
to ModelElement
there will be only one "QObject" in each class even if a class derives from
several classes which
all have its own "QObject"

> this is to derive Ref::RefBaseObject from it.

as I say, I think virtual inheritance can solve this for us... but now that
you mention it..
would you mind explaining again what is this thing about "reflection"??  =)

> we'd include. i think it would be really cool to make a kpart for each ty
> pe  of diagram. how flexible would that be :)

yes, I had already thought of that.. and I think its a very good idea.

> 
> it can be done. there was earlier mention of an intermediary between libX
> MI 
> and libMOF/UML. while it might result in more code and/or more effort, th
> e 
> decoupling (on both sides) will result in a much more maintainable produc
> t.

ok, I got this now. I agree with you.

luis

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!





More information about the umbrello-devel mailing list