[Uml-devel] 2.0 status

[Heiko Nardmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Maybe there are some implementation ideas in Chris Moores code which help you:

http://www.freecase.seul.org/~zmower/repository-0.6.tar.gz

On Mittwoch, 22. Januar 2003 17:58, Andrew Sutton wrote:
> 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
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Uml-devel mailing list
> umbrello-devel at kde.org
> https://mail.kde.org/mailman/listinfo/umbrello-devel

- -- 
Heiko Nardmann (Dipl.-Ing.), h.nardmann at secunet.de, Software Development
secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de),
Weidenauer Str. 223-225, D-57076 Siegen
Tel. : +49 271 48950-13, Fax  : +49 271 48950-50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iEYEARECAAYFAj4voA4ACgkQpm53PRScYyic5wCg0bwJcUVN0x4Z/kcG1iwIhUBR
ICAAnRazmvQLqO7mvtgt4Aot2gpJflrX
=YwBv
-----END PGP SIGNATURE-----