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

[P. Fleury]

Andrew Sutton wrote:

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

in otherwords, extract the semantics of the save/load stuff from the UML::* 
classes and shift to it a tree walking algorithm. the only problem i'd see is 
dynamically handling semantics. the way i was thinking, libXMI would dlopen() 
a metamodel library when it found the <XMI.metamodel> tag. it would have 
loaded libUML or libMOF because i was planning to implement save/load 
semantics in the elements themselves.

if we decouple save/load from modeling, the semantics have to go somewhere, 
and i'd still like them to be dynamic. being dynamic should allow us to 
handle extensions and other metamodels quite nicely.
  

The reason for having the "walker" is for modularity. The libXMI may be 
a stub, reading the XMI file up to the XMI.metamodel point, then loading 
the libUML and libUMLXMI, or in the MOF case, libMOF and libMOFXMI. The 
second lib is always responsible for read/write operations from/to a XMI 
file.

Ok, now that I think about this a little bit more, it would be so that 
if we consider aspect oriented programming, we would have all the 
methods in the classes (scattered there) and have a set of clean 
interfaces (abstract base classes in C++) which represent the aspect of 
UML modeling, UMLXMI read/write, etc.
If I make these comments about modularity, it is because I think that 
code generation for the model only is easier than if we need to make the 
read/write ops at the same time, it makes maintenance easier because the 
code is logically grouped, and we have been bitten already once with 
backwards-compatilibity of UMl files.
Now, I am no God, so maybe there are things I just did not see, that are 
fairly obvious to you. I would hate to be the captain of an ship liek 
Titanic...

Luis De la Parra Blum wrote:

>>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...
>  
>
This problem will recurr when we try to produce other code from UML 
models. That means, we need extra information to produce the code, which 
cannot be stored in the XMI. Therefore, we need this in some other 
"location" (maybe a section of XML in the XMI for vendor extensions, 
another file in the same tar file, or simply another file). I would see 
that once you have a model in UML, you can go about producing code, in 
which stage you can add these little pieces of info and let the thing 
produce code for you. That would enable setting inline flags for 
methods, setting the language in which you want a particular object to 
be produced, some other constraints like you can use Qt, KDE, gnome 
libs, etc. This could also later on become a sort of "code production 
tool" as the logical next step to the "modeling tool" which we are 
talking about. That's what I tried to explain a while ago with the 
inline methods, but I am poor at explaining, my co-workers and my family 
remind me that fact almost daily... (now the mailing lists too :-)

>  
>
>>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.
>  
>
Make it a "global package" :-) It exists in almost any programming 
language, which to me means there is a reason for it to exist, even if 
OO books tell you to avoid it like a highly dangerous desease.

>  
>
>>    
>>
>.[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.
>  
>
Well, maybe the split between walker and libXMI is there for nothing. 
But having the UML model knowing nothing about how you can save it make 
it cleaner. The libXMI "knows" about the UML model, knows how to walk 
it, and knows how to produce an XMI file. To some extend, you could 
think that writing an XMI file is just a special kind of codegen, which 
needs no additional information of its code generation (as opposed to 
thew QObject/inline etc. info for others)
So, yes, the libXMI is tighly linked to the UML model, because it has to 
know what it looks like, and any change to the UML model will have an 
immediate effect on the libXMI code. However, there is a clear 
separation of concerns here, and all the code related to saving is in 
one single location, not scattered across several classes.
For reading, libXMI would be able to create the objects in the UML 
world, while getting events from SAX of walking DOM tree. Again, other 
libANY may read C++ code, Java code, Python to do the same thing, and 
the API of these "readers" would be similar to libXMI.
On the other hand, if we manage to have some way of introspection, maybe 
the libXMI will actually be able to find the information with that 
mechanism, making it more generic and less sensitive to changes in the 
UML model implementation.


--Pascal