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

[P. Fleury]

Luis De la Parra wrote:

>>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?
>  
>
My guess it that they designed it with a pattern known as the composite 
pattern. So basically, a PresentatinElement can present a certain aspect 
from the model. But it can also consist of several other 
PresentationElements. Therefore, a Diagram is aPresentationElement, as 
well as "smaller" things like class widget, association widget, even a 
single line of text or a comment box.

>  
>
>>>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"
>  
>
Yes, virtual inheritance cna make you day for this kind of situation. 
However, if improperly used, you can get in some situations where you 
don't even understand what your own code does (or is supposed to do). 
These cases are typically a sign of bad design (it was my case) and with 
a good design they are easily avoidable. Java has much stronger 
limitations with respect to multiple inheritance (you can only multiply 
inherit from interfaces) thus making you avoid a lot of the pitfalls you 
can run into when using it in C++. But if the base classes represent 
well-defined entities, with non-overlapping functionality, there should 
not be the slightest problem.

>>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.
>  
>
With kpart, I thought you could also install a small XML file describing 
some actions you can take on your kpart when displayed in a "foreign" 
container like konq or kword. So I thought the application would be a 
kpart, with a menu letting you select the diagram in that UML file 
containing the diagrams.
I don't see what we gain in having a kpart for each type of diagram...


--Pascal