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

[Andrew Sutton]

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

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

right. a code generator walks over the UML::* classes in some interesting and 
as-of-yet undetermined way. all codegen information is implemented within the 
code generator.

the primary reason we want to derive from QObject (in leaf node classes only) 
is to provide access to the signal/slot mechanism. it would be nice to emit 
signals when, say, an attribute is modified or an association is unlinked. in 
fact, when i think about it, it might be better to derive the base reflective 
interface from QObject. yes. definitely...


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

i think so too. alright. somebody come up with a good, generic and dynamic 
design for separating save/load features from the MOF and UML model 
implementations such that libXMI can invoke the save/load features to deal 
with the semantics of certain elements :) i've got an image...

andy