Week 28 of 2010

I've been very busy over the last week, extending and evolving the OOA of OOA. I've also been implementing some OOA Tool changes with regard to Arbitrary ID Types which have been completely overhauled. Let's start with the Recursive Design subsystem which is shown below:

This hasn't changed much over the last week. The Location attribute on Software Product has expanded into several attributes reflecting the new implementation within OOA Tool. The user can set a manual location (relative or absolute). However, a default location (relative if parent location defined, absolute otherwise) is always defined and used if no manual location is specified. A parent location (absolute if defined) is always defined for software products enclosed within other software products, e.g. code modules are enclosed within projects and/or external projects. Manual and default locations are resolved relative to any parent location. All locations are specified as URIs while the final location should also be a valid absolute URL. Using URIs here blurs the distinction between file system and web locations. OOA Tool also converts to and from platform specific paths allowing normal file chooser dialogs to be used.

Another change involves the new Work Product object, a subtype of software product. This change expanded so much over the week that a new Work Product subsystem had to be added to the OOA of OOA. This sounds like a major pollution of the domain, especially since I have previously mentioned that I wanted to evolve the Diagramming domain used in the OOA Tool project into a more general Work Product domain covering diagrams, tables and other graphical constructs. However, I'm only concerned with OOA/RD specific information in the new subsystem. No mention of size, location or other graphical pretty printing is involved. The Work Product subsystem is shown below:

As this subsystem evolved from a few objects into 25 objects, I made a number of important discoveries:

• each diagram product has it's own notation which may differ from the enclosing project's notation reflecting the reality in OOA Tool while table products do not,
• a new Information Model Partition object was required to formalize this subsystem and as a result, I was able to simplify the messy unassigned/assigned object/relationship cluster in the Information Model subsystem,
• archetypes can determine diagram locations (e.g. when generating reports) from a metamodel population by looking at instance data associated with this subsystem,
• imported objects and event destinations are modelling issues best captured in the OOA of OOA rather than as diagram pretty printing,
• tasks and task activities (now called Work Cells) have a proper home and it's in this subsystem,
• and I identified the need for allowing generalized data types in polymorphic attributes since I can't resolve the polymorphic row and column attributes on Table Cell without it (more soon).

The new subsystem also makes bridging to a generic Work Product domain much easier since each diagram and table product now has an object in the OOA of OOA domain which can be mapped to a counterpart in the generic domain. The new Information Model subsystem is shown below:

You should see how the new Information Model Partition object eliminates the need for unassigned/assigned object/relationship objects. I haven't made the change in OOA Tool yet since it will probably involve lots of work. However, the above subsystem is much cleaner with the change.

You may also notice that I have replaced Arbitrary ID Attribute with System Set Attribute. System set attributes allow system reallocated IDs, current subtype and current state attributes to be added to an object (and provides room for future system derived attributes). As far as current state is concerned, OOA91 allowed users to access it while OOA96 disallowed such access. I'm in favour of allowing controlled access to current state information. My initial plan was to provide a special current state (and current subtype) expression syntax within the Action Language to support this. However, this is messy since it complicates the Action Language and hides such access from any model reviews. The better approach is to allow users to add a current state attribute (which is set by the system) to an appropriately related object, e.g. the current state of a lifecycle model can be added to it's active object. I already automatically define an Enumerated State Type for each state model allowing such an attribute to be typed. I've extended this idea to allow the current subtype of a subtype-supertype relationship to also be added to an object since I also already automatically define an Enumerated Subtype Type for each subtype-supertype relationship. This allows identifiers to be defined which include the current subtype! Current subtype attributes should only be added to the appropriate supertype object. As a result of the overall change, I've also replaced the "(A)" suffix with an "(S)" suffix within information models.

I was also going to talk about the revamped Arbitrary ID Type which I've already coded up but time has run out (I'm trying to limit weekly reporting to a few hours a week now!). I'm definitely planning a new OOA Tool build now since the current metamodel won't load into the currently released build.