Week 12 of 2010

Work is progressing nicely on OOA Tool II. I spent some time getting the new GUI framework started this week. I've been able to drop some nasty workarounds from OOA Tool I that were needed because of J2SE 5.0 bugs. There are a lot less bugs in Java SE 6.

I'd like to talk about a mapping from objects, attributes and subtype-supertype relationships (SSRs) to tables and rows. Within OOA Tool I, object instances stored as rows were mapped directly to objects. However, the design required a knowledge of subtype-supertype relationships and an ability to migrate between subtypes while preserving object instance references. I wanted to take SSRs out of the picture entirely in the more generic OOA Tool II architecture. Otherwise, I would need to add the concept of SSRs into the Data Management dictionary subsystem.

To eliminate SSR's, objects and the SSR's that bind them are used to create object families (an object family is the set of objects inter-related by an SSR graph) and object combinations (an object combination is a subset of objects that may exist at one time as part of an object family instance, i.e. it defines a particular combination of SSR choices). The algorithm used to determine these is highly recursive and quite complex (maybe another day!). Each object family has one or more root objects (objects which never participate as subtypes) and one or more object combinations. The name of each object family can be derived from it's root objects and in many cases there will only be one. The name of each object combination can be derived from it's leaf objects (objects which never participate as supertypes).

In the new design, an object instance reference is actually an object family instance reference with an object reference for type qualification. While an object family instance held as a row within a repository table contains the cells for all potential attributes that an object family instance may have. It also has a current object combination indicator allowing us to determine which cells are currently accessible.

Migration now involves updating various cells in a row along with a simply change of object combination indicator. To determine if a particular object family instance reference is still valid one only has to check whether the current object combination indicated includes the object used as the qualifier within the reference. When an row is marked as deleted, depending on a setting associated with any reference holders (i.e. cells in other object instance family rows) we can now either: make reference holders invalid since they hold an invalid reference, automatically remove the reference from any holders allowing the holders to remain valid, or attempt to delete any reference holders to fix the situation.

Cast operations between different objects are easily performed by creating a new object reference containing the same object family instance reference but with a different object qualifier. Obviously, a cast is statically invalid between objects in different families, and dynamically invalid to an object not included in the current object combination indicated by the referenced object family instance. The scheme that I have adopted cleanly eliminates all SSRs without losing the benefits. The primary disadvantage is that each table row is now potentially much bigger than it needs to be. However, memory in my experience is not a resource in short supply.

Some graphic examples would have been nice here but I don't want to spend all day on this blog. Hopefully, I'm managed to convey the basic approach I'm using to eliminate subtype-supertype relationships (which are difficult to implement without recursive algorithms everywhere) from the OOA Tool II architecture by adding object families and combinations (which are easy to implement with simple lookups).