Week 7 of 2010

I continued working on the Recursive Design subsystem (follow this link if you want to understand what is discussed below!) and it's implementation within OOA Tool this week. I have moved bridge mappings, wormholes and control reception points into the Operation subsystem. This makes the RD subsystem much more managable and makes room for future growth, e.g. additional types of reusable assets will probably be added.

I replaced Domain IDs (Dn), Bridge IDs (Bn) and Layer IDs (Ln) with Asset IDs (An). This change means that bridge links within Domain Charts now use Asset IDs rather than Bridge IDs. However, I convert Bridge IDs when a model is loaded to maintain backwards compatibility. This also allowed me to change Data Type ID format from DTn to Dn.

Domain Activity is now Asset Activity allowing bridge and layer activities to be captured in a Project Matrix. I also renamed Activity to Task Activity to avoid confusion. However, to keep Project Matrix size down, columns are now only added when there is at least one activity in a column. Thus, they now look very empty to begin with. Note that, activities are project specific, i.e. are not loaded from imported assets.

Domain names are an interesting issue. They are currently unique within a project and are used as domain shape names within Domain Charts. However, imported domains load their names from an external project and thus may break uniqueness. This can be avoided by adding an External Name attribute to Imported Asset. However, you then have two names which may get out of step in a significant way. The alternative is to drop the uniqueness constraint and allow domain names to be duplicated. Since we now use domain role names within bridge mapping and domain observer code, this shouldn't be a big issue. I would need to change domain shape names to use Asset IDs. Domain Chart diagrams can also qualify duplicated domain names using Asset IDs to avoid confusion (if necessary). I'm 95% sure that I should choose the latter solution. Arguments to the contrary are welcome.

A similar issue concerns the multiplicity of bridge associations, i.e. whether each client/server domain pair can have at most one bridge. This made sense when all assets being bridged were local to a project. However, one may want to import two domains along with a existing bridge between the two domains, yet also add additional bridge mappings using an additional local bridge. This changes the multiplicity of R7 (in the RD OIM referenced above) to many. One could even imagine creating two local bridges within a single project to facilitate reuse by separating core bridge mappings from application specific bridge mappings. Making this change seems to be well justified so I will go ahead and change this next week.

I also downloaded the latest JDKs from Sun's website. I am now using Java SE 6 build 16 (JDK 1.6.0_16) for development and testing purposes. I also downloaded and tested Java SE 7 beta build 76. This beta still can't display HTML tables correctly so I can't recommend it yet. I also attempted to download J2SE 5.0 (JDK 1.5.0_22) but have gotten no response from Sun from a form request I submitted. It has reached end of life but I was still hoping to support it until Java SE 7 is finally released. Since it can't be downloaded anymore, I have decided to drop support for J2SE 5.0 from the next OOA Tool build. That means that I can now start using features that where added in Java SE 6 and remove numerous workarounds for J2SE 5.0 bugs (mostly GUI related). The next build will use the new class file format (50.0) so it definitely won't be runnable using J2SE 5.0. Speak now if anyone has issues with this decision, e.g. if you are running OOA Tool on a platform without Java SE 6 support.