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

[P. Fleury]

More from the far east front...

Andrew Sutton wrote:

>  
>
>>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.
>  
>
Why is it difficult to separate? If you have a set of UML:: classes you 
can access and walk through (you've got get/set methods) so I guess you 
can also know what the relations are between the bojects, etc. Then you 
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 
implemented, without having the algorithm split into bits and pieces of 
code in every node and vertex. It makes the addition of a new algorithm 
also easier, and does not need any change in the implementaiton of the 
nodes. STL is actually sort of based on a similar approach. And 
otherwise, this is just plain MVC.

>  
>
>>    
>>
>  
>
>>Another point I'm just thinking about, is that we cannot have an UML
>>Implementation that is "only" the UML Model... I mean, I dont want our
>>"UML::Class" to be "just" a thing with a name, and some booleans (isActive,
>>etc) but has to have some other functionality that is not described by
>>UML... for example, our UML::Class should be a QObject so that we can use
>>signals and slots  ( I want to emit a signal when a new attribute gets
>>added to the class so that the diagram can update itself, for example)
>>our UML::Class should also have a method "writeXMI" or something like that
>>to store the model back to disk ( libUML would read the file and create the
>>objects, but we need to save them back)
>>    
>>
>
>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.
>
>anyway, i think we can do that. remember, we control what code is generated. 
>its not wrong (or noncompliant) to *add* to the implementation. 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 from 
>Ref::RefObject (or some other reflective interface) in leaf nodes of the 
>inheritance tree). so, if the metamodel codegenerator runs into a leaf node 
>class, we know to insert a QObject (probably something more specific) parent 
>into its inheritance list. we can also modify the way the get, set, add, 
>remove, or other methods are implemented to emit signals on well-known 
>events.
>  
>
Again, the code generator would be a UML model structure walker, but 
instead of producing an XMI file through a libXMI, it would produce our 
classes through a libUMLCodeGen. All the implementation specific things 
are in that lib, and the UML model representation is still clean.
Having QObject information in the model would contradict what I was 
understanding before, that is that there is no code generation 
information in the model. And UML is a model, right?

>on a side note, if we have fully compliant MOF and UML implementations 
>(including the reflective interfaces), we should be able to completely remove 
>any save load capabilities from both libMOF and libUML. honestly, that would 
>be a pristine implementation because it completely decouples data modeling 
>with serialization (save/load). i don't know if that's something we want to 
>aim for right now.
>
I think it would make code maintenance much much easier.

--pascal