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).

Week 11 of 2010

This week was very productive, focused mainly on the new Data Management domain at the heart of the new OOA Tool II architecture. I had some interesting thoughts on how OOA Tool has evolved and how it will evolve in the future:

• OOA Tool I (previously labelled OOA Tool 1.0) was incrementally prototyped. The approach allowed me to develop a rich OOA of OOA going beyond what was originally specified in OOA91 and OOA96, in step with a tool that supported it. However, over the last year I have spent a lot of time trying to make what should be simple changes work. Prototypes are just not scaleable or maintainable beyond a certain size and OOA Tool I has 145,000 lines of compact Java. However, without the knowledge gained from this prototype I would never have been able to develop a suitable architecture for the next version.
• OOA Tool II will comprise a completely generic configurable core (the Data Management domain) driven by XML dictionary/repository files for OOA of OOA, Work Product and GUI domain metadata/data. This version will include a working simulator and translator. It will allow me to develop one or more working software architectures (Shlaer-Mellor RD style).
• OOA Tool III (in the future) will use archetype templates to generate custom business objects and editor forms with a much reduced need for the previous generic configurable core. This version should be very fast (not that speed has been a problem so far) and may even include a web interface since we could generate active web content rather than traditional Java code. This version will fully demonstrate the power of Shlaer-Mellor OOA/RD, i.e. a code generation tool built using code generated from itself.
• OOA Tool IV? I'm not sure what major architectural improvement would drive this version. Perhaps a knowledge based query driven design assistent developed using the previous version could be used to automatically generate the necessary RD mappings to a generic software architecture. This is what I originally imagined OOA Tool would evolve into - an OOA/RD CASE tool with AI support for OOA/RD.

Now to progress on OOA Tool II:

• Now that I have dropped J2SE 5.0 support, I can take advantage of bundled features of Java SE 6. Loading OOA project files with Java SE 6's built-in XML parser is extremely easy. The first task was to load the OOA of OOA domain and create a suitable dictionary for the Data Management domain. Once created, this can be saved to a XML dictionary file for faster loading later. Last week, I mentioned that I would probably hand-code these dictionary files. However, it has become obvious that the process can be automated (with some hints not captured by OOA Tool at present) allowing future OOA of OOA changes to be deployed to OOA Tool II quickly. This involves mapping Objects, Attributes and Relationships to Node Types, Subnodes and Property Types (I will discuss this mapping in the future since it is a design problem for anyone generating code from Shlaer-Mellor OOA models).
• The second task now that the dictionary (i.e. metadata) is populated (or at least on the way to being populated) from the OOA of OOA domain, is to populate the repository from one or more project files using the OOA Interchange Format. Since I have already been using Java's built-in XML parser to do this task - no problem here. Except that the mapping from XML element/attributes to node/property types (in my dictionary) is a quirky one since the OOA Interchange Format was developed by hand. Future versions of the format will be generated automatically from the dictionary which is itself generated from the OOA of OOA.
• I have also extended the Data Management domain to include a Data Management Language that is a cross between an Action Language and an Archetype Language. This is going surprising quickly. I hope to develop the final Action/Archetype Languages as subsets of this language (maybe with a different syntax) making the simulator and translator relatively easy work. I will publish the syntax for this in the future.
• I haven't started working on the generic GUI yet since I first needed to be able to load metadata and data to browse. However, I will create a basic GUI domain especially for menu controls since OOA Tool I is mostly driven by menu controls and it would be nice for these to be configuration driven. The main components that I need are a tree browser and form editor. The tree browser is mostly generic in OOA Tool I. However, I want to incorporate more drag-and-drop functionality in OOA Tool II. Form editors in OOA Tool I were mostly hand-coded and this will be one of the major improvements of OOA Tool II since I will use a completely generic form editor. Obviously, I need sufficient information in my metadata to configure these. However, final validation of constraints is left to validation checking functions in business logic plug-ins (most OOA of OOA objects will have a hopefully small business logic plug-in). It should be possible to generate this logic automatically from an OOA model if all mathematically dependent attributes and relationships are coded in the OOA model (which they are not at present).

Obviously, the mythical build 014 for OOA Tool is on hold at present. However, coding of the OOA Tool II core is going fast enough that it will probably be the basis for the next build. I would estimate the work taking a few months. The difficult issues here will relate to moving across and testing all of the OOA of OOA business logic (constraints and derived calculations).

Week 8/9/10 of 2010

I have lots to say this week! I've been remiss over the last few weeks (i.e. no blogging) because I have had so many new ideas that I didn't want to sit down and try to explain them until the ideas had more fully matured. Some of these ideas have gone in unexpected directions and so now I have to sit down and do some explaining. Each of the different areas that I have been working on is numbered below.

(1) I evolved the Diagramming domain into a more complete Work Product domain with Diagram, Table and Template subsystems (not all done yet). The mission statement for the new domain covers work product information that needs to be persisted along with OOA of OOA information in model files. This is distinct from what is needed to display and change the work products in a GUI. This domain will be published since it forms part of the OOA Interchange Format.

(2) I also evolved the Naming domain to Name Management then to Text Management and finally to a Data Management domain with Dictionary, Repository, Change Control and Text subsystems. This domain will now be proprietary in nature but will have an open interface for user supplied language resources (e.g. French resources).

The Dictionary subsystem will allow notation and locale (language, country etc.) specific titles and icons to be loaded from Java resource files. The dictionary itself will now be loaded from an XML file. This XML file will initially be hand coded for OOA Tool but will later be generated from the OOA of OOA via an archetype template. Yep, I'm moving towards a self-generated OOA Tool.

The Repository subsystem with include built-in file system support that will allow all files to be loaded either from a local or networked hard-drive or over the internet. This will later be expanded to support database persistence and shared access.

The Change Control subsystem breaks down all changes into atomic reversible changes which are bundled into reversible transactions. Complete validation checks are then performed before transactions are committed. The repository will only save committed transactions. Users will be able to cancel a transaction or undo previous transactions (in order obviously). They will also be able to redo transactions etc. This will be a massive change from what is currently supported in OOA Tool.

The Text subsystem expands on the previous Name Management domain. I may separate this subsystem back out in future.

(3) I added concepts of Empty State, Deleted State, Creation Transition, Deleted Transition, Deleted Event and Communication Path to the State Model subsystem of the OOA of OOA. These changes were the result of a better understanding of what is needed by the Table subsystem of the new Work Product domain and what is needed to support Shlaer-Mellor and Executable UML notation.

It also reflects an important shift from user controlled memory management to automatic garbage collection, i.e. Deletion State is where user requests a deletion while Deleted State is a logical state after which deletion has occurred via garbage collection (a state which has meaning in the model but not at run-time). I personally don't believe it is possible for users to safely manage memory allocation and deallocation. For this reason, OOA10 reflects this assumption. You can still create C archetypes with memory allocation and deallocation logic but executing a delete object instance Action Language statement does not immediately delete an object instance. It only requests that a deletion should be carried out once all references to the object instance are cleared. However, users will not be able to search for a deleted object instance or navigate to such an instance but there may be any number of events carrying references to a deleted object instance (which we can't delete without unknown repercussions). There may also be actions being executed in parallel with access to deleted object instances (which would be impossible to delete).

(4) I have also been thinking about how to commercially manage reusable assets using public/private key encryption. Service domain suppliers will have their own public/private keys for their products (packaged as model files). They will securely distribute the public keys to licensed users. They will then encrypt the associated products (i.e. model files) using their matching private keys allowing the products to be openly distributed across the internet. Users download the products over the internet but have to manually enter any public keys into OOA Tool to access the products. OOA Tool will decrypt as required. This approach also allows users to verify the source of the products since public/private key encryption can be certicate based.

This approach can be extended to allow controlled user access (without having to securely distribute public keys) using an OOA Tool supplied public/private key combination. OOA Tool will include it's own public key hidden within itself while the private key will be made available to suppliers on request. Each imported domain will then be assigned an access level (from most restrictive to less restrictive):

• View - View domain as black box only allowing user to see control reception points, e.g. synchronous services, external events etc.
• Simulate - View domain as black box but allow OOA Tool simulator to access whole of domain for simulation purposes (users can't trace into domain making reverse engineering difficult).
• Translate - View domain as black box but allow OOA Tool simulator and translator to access whole of domain (obviously, output files from translator make reverse engineering easy).
• Edit - View domain as white box giving users full access.

The OOA Tool public/private key can be used as well as the the supplier's own public/private key to provide a flexible solution for commercial distribution of OOA assets.

(5) Finally, I have come to realize that the architecture of OOA Tool 1.0 is fatally flawed since it is not scalable or maintainable. The new Data Management domain will form the basis of future OOA Tool 2.0 development. The OOA Interchange Format will evolve in a controlled fashion so that users will be able to load old models. I may also continue with the old infrastructure for a few more builds. However, I will start to migrate stuff over as soon as the new stuff is stable. Since the Data Management domain will deliver a majority of OOA Tool 2.0's functionality, I have decided to make it a proprietary domain and not publish the domain's model. However, the OOA of OOA and Work Product domains will continue to be published and obviously the OOA Interchange Format will continue to be completely open. The new architecture should allow me to create changes in the OOA of OOA and rapidly roll them out. It should also allow me to make significant generic changes in the GUI without having to manually update large amounts of model specific GUI code.

That's all for now. Comments always welcome.