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