[Uml-devel] more insanity

[Andrew Sutton]

On Friday 08 November 2002 12:29 pm, Luis De la Parra Blum wrote:
> well.. this is getting confusing =)
>
> what about this:
> > so, in the XMI listing:
> >
> >     <Model:Package annotation="" isAbstract="false" isLeaf="false"
> >       isRoot="false" name="Model" visibility="public_vis" xmi.id="a9">
> >       <Model:ModelElement.constraints>
> >         <Model:Constraint xmi.idref="a10"/>
> >         <Model:Constraint xmi.idref="a11"/>	<-- parse state is here
> >         <Model:Constraint xmi.idref="a12"/>
> >         <Model:Constraint xmi.idref="a13"/>
> >       </Model:ModelElement.constraints>

> after parsing the document we start walking the tree and do something like:
> MOF::Package *p = new MOF::Package(/*id=*/ "a9");
> p->setAbstract(false);
> p->setLeaf(false);
> ...
> //parentElement is the element "in which" we currently are (can be the
> Model // a package, or a class...
> parentElement->add(p);
> //if there were no parentElement, ie, if we just found the first element
> //we would have called Model::setTopElement(p) or something like that
> //parse the rest of the file and finaly return the model we just created to
> //the caller
> return Model;

hmm... to specific. we wouldn't be able to parse XMI files with UML elements 
in them. actually, take what you have there, change the MOF::Package to a 
Ref::RefObject, and the set* methods to refSetValue("*", false) and you have 
the reflective version. basically.

> ok, ok, so this is not reflective and maybe my approach is much more
> simplistic, but if in the MOF there are only a few "building blocks"
> (package, object, association) this would be all that we need.
> we can get MOF going, and then we use the MOF code generator to write
> the UML metamodel for us (which has many more elements)

no no no... in the reflective stuff there's only a few building blocks. MOF 
has significantly more. (types of associations, features, types, etc.).

> hm... somehow I have the feeling I am talking nonsense here, but why cant
> we just keep it simple?

hehe. because we aren't dealing with a simple standard. and recursive 
definitions are headaches.

here's my idea... lets start with libReflective. we'll model it after JMI 
(http://java.sun.com/products/jmi/) because they have a somewhat cleaner 
reflective module than MOF. we'll just be sure to write down the MOF -> Qt 
mapping and document all extensions, modifications and rational.

then, we start going in 2 directions: libXMI for generic parsing and libMOF - 
the real one. we'll build it by hand according to the template mappings that 
we figure out for C++ and Qt. that should plug directly into libXMI (and 
libReflective).

actually, some parts of libXMI can probably be developed in paralell with 
libReflective - since we only want to use reflective interfaces there.

by the time we've got a big chunk of libMOF done, we should be able to 
"mostly" regenerate our work on libMOF (to validate our manual template 
instantiation) and generate a significant chunk of libUML with no errors.

that's a plan and half... :) are we ready to actually code it? maybe? we 
should probably get a new branch and start thinking about project 
organization if we are.

andy