[Uml-devel] Re: Umbrello design

[Andrew Sutton]

> so, to summarize:
> I suggest having a simple reflective interface (abstract class, API) and
> then have our objects implement this interface (if possible code
> autogenerated) then, for the libXMI and friends, I would suggest
> 1- making a dom out of the file
> 2- for each object found, make a
> 	obj = Factory::makeObject(objtype)
> where objtype is the type read from the file (MOF::Package, UML::Class,
> etc) the object returned would be a "real" object (ie, not a dumb,
> reflective only object)
> 3- since the object returned would also implement the "reflection
> interface", the next step is to read all attributs and do some
> 	obj -> setAttribute("attname", "attvalue")

right. this is what i'm suggesting - except that the reflective interfaces are 
already (for the most part defined for us) - the reflective module specified 
toward the end of the MOF standard. it defines 4 interfaces, my design has 
several more.
	- RefBaseObject
	- RefObject
	- RefAssociation
	- RefPackage

JMI extends this list a bit.
	- RefFeatured (becomes base of RefObject and RefClas)
	- RefClass
	- RefEnum
	- RefStructure
	- RefException
	- RefAssociationLink

I take it a little further
	- RefDataType (becomes base of RefEnum, RefStructure, and RefPrimitive)
	- RefPrimitive
	- currently excludes RefException (can't think why i should have it).
	- currently excludes RefAssociationLink

these are the classes that i'd use for a set of reflective interfaces. It 
defines some pretty functional stuff. I introduce RefDataType to provide a 
type name for data types. RefPrimitive acts as the base for classes like 
Integer, Float, Double and String - which are also listed in my design.

i think, however, it might be good to let the reflective classes (not the 
derived object classes, but the reflective classes) to manage most of the 
information internally. remember, these are supposed to be highly generic and 
the concept of immediate package or outermost composite might not translate 
as well.

> There are only two things worth mentioning:
> the Factory would have to know all the objects we support (MOF::*, UML::* )
> and create and return the appropiate object based on the "objype" string
> passes as argument (see the WriterFactory... it gets a string asking for a
> specific language, and it returns an object of that type)
> of course when we want to support other objects (ie, add support for CWM)
> the factory would have to be changed.. but I think this code could also be
> in great part automatically generated. and we could load the factory
> dinamically so that we dont have to recompile the basic XML reader/writer

actually, i was thinking the factory would load libraries dynamically - both 
at runtime and when an <XMI.metamodel> tag is encountered. that way, the only 
thing that would need to change would be a configuration file.

> the second thing is that we need to provide functions like "stringToInt",
> "stringToFloat" and so on for all basic data types, which can be used for
> all the object in the "setAttribute" methods (providing this functions is
> not complicated.. we just have to remember that we have to convert
> everything from /to string, since it is the format stored in the XML.

my "in progress" design for the reflective stuff handles that. RefPrimitive 
maintains all data values for primitives as a string. the Integer, Boolean, 
String, Float and Double types just convert to and from the string.

code generation for this stuff is kind of weird... during parsing, all we're 
doing is instantiating objects and operating on their reflective interfaces. 
During code gen, we walk the reflective interfaces to generate code (or 
output XMI for that matter).

andy