[Uml-devel] more insanity

[Andrew Sutton]

> let me know if i'm way off base with this stuff. now, my brain is jello,
> i'm going to drink.

didn't help. still confused.

i did download some sample interfaces generated by the JMI implementation. its 
been *kind* of useful. it turns out my thinking about parsing xmi elements in 
terms of reflective objects has been a little off.

there are essentially 3 (well, a couple more) types of elements in the xmi 
file we have to deal with: packages, associations and objects. packages are 
generic containers, associations describe relationships and objects define 
structural elements. in theory, when we encounter these types of elements in 
the xmi file, we should be able to instantiate an object that provides the 
reflective interface for those objects, right?

wrong - as it turns out. the reflective interfaces for packages and 
associations don't offer the interfaces we need to fully configure these 
elements. when we walk the xmi tree, the only thing we can do is instantiate 
objects. for example, <Model:Package/> won't result in the creation of 
something derived from Ref::RefPackage, it results in the instantiation of 
the MOF::Package class - derived from Ref::RefObject through 
MOF::ModelElement.

however, it gets kind of confusing, because in a fully implemented MOF or UML 
there will be classes that DO derive from Ref::RefPackage - we just don't use 
them. the same goes for Ref::Association.

now, for packages, i don't think its really that big of a deal. for 
associations, we run into the problem of how to connect elements 
participating in an association to the parent object that contains or 
references them. i don't know if we can use the get, set, add, remove methods 
on the Ref::RefObject class because those seem to apply more to attributes 
than associations.

aha! i found it: "The refValue method fetches the current value of the 
attribute or *reference* denoted by the feature argument." a reference 
participates in an association (whereas an attribute only applies to the 
owner class). if the refValue method applies to both attributes and 
references, then so will the refSetValue, refAddValue, refAddValueBefore, 
refRemoveValue, refModifyValue, etc.

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>

where Mode:ModelElement.constraints is a relationship, the xmi load protocol 
can use the following Ref::RefObject interface to add the relationships:

	Ref::RefObject *current = ...;
	Ref::RefObject *composite = ...;
	Ref::RefObject *obj = ...;
	composite->refAddValue("constraints", obj);

where current is the MOF::Reference object on the top of the stack - pushed 
when Model:ModelElement.constraints was encountered, composite is the 
immediate composite of current - obtained through refImmediateComposite() - 
which is MOF::Package and obj is created as a result of visiting the current 
node (Model:Constraint).

that's pretty generic. the only time we'd have to get specific is during the 
creation of an object - we need to lookup the namespace and tag to 
instantiate that particular object.

yes... this is all falling into place :)

andy