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

[Andrew Sutton]

On Monday 04 November 2002 11:10 pm, P. Fleury wrote:
> Phew... thanks Andrew for taking the time to go about this MOF, UML, XMI
> and all its friends. It was also sort of fuzzy to me what that was all
> about, and the intro from O'Reilly's UML in a nutshell confused me even
> more.

ain't no thang. actually, i spent a year or more digesting all that 
information before i finally got it straight in my head. i'm just glad it 
helped at least one other person ;)

> - what does libXMI do that a SAX parser does not do ? If I understand
> well, the real "interpretation" of the content of a XMI file is done in
> the libMOF/libUML/etc lib, right?

a sax parser uses callbacks when elements are encountered. we need to create a 
set of objects with particular attributes and relationships to other objects. 
i thought about using the sax interface to xml to construct the information 
base (collection of objects and relationships), but the dom interface turns 
out to work better.

> - Our projects are made of objects which are instances of UML object,
> which themselves are instances of MOF objects. All of which seem to
> have, at the (meta)*model level only getter/setter methods. Why not
> another level which has only 1 class, of which MOF objects are
> instances. Let's call it libOOTU (Lib Origin Of The Universe), which we
> could define for the purpose of our project. Sorry, that may be a dumb
> academic point of view, but I see now that I have been playing with only
> a few snow balls of the UML iceberg...

good question. there's a set of interfaces from which all MOF classes are 
derived (and maybe all UML classes too - i can't remember) called reflective 
classes. the MOF standard actually defines a namespace "Ref" (for reflective) 
that contains these interfaces. basically, they provide the ultimate 
meta-level interfaces for these objects. you can use them to get attributes, 
examine associations and investigate packages. i haven't really given it alot 
of thought because it has (and continues to) pollute my understanding of the 
standards. i think i'm finally starting to reconcile my differences with 
these things.

i don't even know if these interfaces will see the light of day in my design. 
they're too arbitrary and don't map well to C++. if i could find some kind of 
QAny (based off the IDL "any" type), then it wouldn't be so bad. come to 
think of it, the boost library has an any type (boost::any). you can find the 
specification of these interfaces in the MOF standard.

> - for code generation, it would be very good to keep in mind that for a
> same model, we may produce files in different languages for different
> classes (Think Java/JNI/C++ or Python/C). This information is not
> present in the model that clearly (can we mark this kind of info?) and
> maybe should be part of a "production stage" where one can work with a
> model,  and add this kind of annotations before generating the code. The
> extra info would be saved in another file if needed. This would probably
> wrap around the UML model as the GUI objects do. How does thaty fit into
> the big picture, (if it belongs there) ?

the whole point of uml - as a (primarily) OO modeling language - is to provide 
a language independant way of visualizing software design - not 
implementation. the code generation and parser components of umbrello (and 
other uml applications) are used to provide some level of round-trip 
engineering (continuous synchronization of design and implementation).

that said, the object model defined by UML is meant to be language 
independant. i think each code generator (Java, JNI, C++, Python, C, C#, J++, 
Smalltalk, OO Cobol, whatever) should be implemented in its own library - 
independant of other generators regardless of their similarity. separation of 
concerns is key. the best we can do is provide a well-defined protocol for 
code generators.

the same goes for parsers.

andy