[Uml-devel] 2.0 status

[Andrew Sutton]

all,

i just thought i'd write and let you know the status of what i've done with 
2.0 so far... and some observations that i've made, and to request some 
feedback on design and implementation.

i've been working on 3 things pretty religiously: reflective interfaces, the 
type library and the MOF implementation. here's what i've got done.

reflection
- stubbed out all the reflective interfaces
- implemented several methods as generically as possible

type library
- implemented a bunch of primitive types - integer, string and boolean are the 
only ones used but i've implemented long, float and double as well
- given them reflective capabilities (you can get and set each as a string)
- implemented enumeration types to work like primitive types (you can get and 
set the value as a string) in fact, RefEnum is derived from RefPrimitive 
specifically for this reason.

MOF
- stubbed out all the MOF interfaces and written all the attributes, 
references and operations (the ops aren't implemented)
- implemented all the MOF data types (enumerations and structures) using the 
type library and reflective interfaces
- started implementing some of non-abstract MOF classes (like MOFPrimitiveType 
and MOFPackage).

now, here's what i think is bad about the implementation: i've written a bunch 
of macros to prevent the duplication of code. its really, really ugly. well, 
not that ugly, but still pretty bad. i have an idea that would make it alot 
better, but i'm not entirely sure what i want to do about it - yet.

some observations:
MOF is like a programming language for metamodels. there's packages that 
translate to namespaces, classes that translate to, well... classes, 
attributes and references that act as accessors and mutators, operations and 
the like. its a programming language. as i implement this stuff, i realize 
that i'm following a translation from one programming language to another. 
the mapping just describes how the MOF programming language translates to 
java or IDL or C++ (which doesn't exist). this is starting to affect the way 
i want to implement it.

the reflective interfaces define a generic structure for all things defined in 
the MOF programming language. essentially, each instance of an MOF language 
(like UML or CWM) conforms to this generic structure. the structure is based 
on packages, associations and objects. the objects have features - basically. 
that means that any implementation of the reflective interfaces must adapt to 
the generic reflective structure. MOF is easy, because they're tightly 
coupled. its pretty easy for UML too because those constructs exist in UML 
(packages, assocations and objects).

OCL (object constraint language) is a scripting interface onto the generic 
structure of the reflective interfaces. it could be REALLY, REALLY powerful. 
for example, the operations defined for objects in the MOF are given 
implementations defined in OCL - we wouldn't have to implement them in C++ if 
we had an OCL interpreter (that would be the "mad bomb" as the kids say).

so, what i have right now is a programming language made up of ugly macros and 
i don't know how well its going to be scriptable. i suspect that i'm missing 
a big piece of my design because i haven't done a good job adapting the MOF 
interfaces to the reflective interfaces. its really a non-trivial problem. i 
suppose one way to implement it would be to define an adapter interface for 
reflective objects and derive implementations from them - then implement the 
adapter interfaces for implementation objects (i.e. MOFPackageImpl). that 
might be a good solution.

another thing i'm thinking about is using templates to implement attribution 
and references. so instead of seeing this in a header file:

class MOFModelElement
{
	String *_name;
	String *name() { return _name; }
	void name(String *value) { _name = _value; }
};

you'd see this:

class MOFModelElement
{
	mof::single_attribute<String> name;
};

String *value = obj->name.get();
obj->name.set(new String("Foo"));

or something like that. i'm unsure of the tradeoffs right now - and the 
design, really. i just know that i like it a little bit better. its cleaner 
and more graceful. note that this doesn't really affect the overall design of 
the MOF implementation, it just affects how attributes and references are 
dealt with.

in fact, we could probably do the same with operations - define them like stl 
functors (stl::nullary_function, stl::unary_function, etc). that might be 
pretty cool.

i'll poke around with a prototype and see how i like it. let me know what you 
guys think about all this stuff.

andy