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.

Week 6 of 2010

I'm slowly getting back into things this week. However, I haven't been focusing on the priority one item which is to get Build 014 released. Instead, I have been trying to sort out a workable design for high-level reuse in the Recursive Design subsystem of the OOA of OOA. Enabling reuse of service domains and software architectures has always been a primary objective of OOA10 and OOA Tool. However, the current version of OOA Tool only supports reuse via copy and paste.

I've been working on a few ideas for reusing domains for some time. The main issue that has stopped me implementing an approach has been how to resolve parent links from a domain to the enclosing project, many of which are GUI related. I originally wanted users to be able to open multiple projects within OOA Tool where one project reuses one or more domains from another project. I envisaged a particular domain having only one actual instance at any one time. However, this leads to all sorts of linkage problems that could not be resolved without increasing the complexity of the current implementation considerably. Thus, I decided to abandon the goal of having only one instance of a domain at any one time. When a domain is imported into another project and separately loaded then it will be copied into that project but will not be persisted with the project. Users will also not be able to edit imported domains. They will be able to reload them. Automatic synchronisation may be possible in the future but will probably be processor intensive.

I also decided to broaden reuse across a number of high-level assets including domains, bridges and layers. I will probably add populations and transformations (simulations and translations) to this list in the future. This was done by defining a new Asset object which generalizes high-level reusable components. To reuse an asset within a project, users must first define an External Project allowing the location of the asset to be specified, then an external asset can be defined which imports the desired asset from the external project. The asset can then be loaded from the specified location, e.g. the associated information model can be loaded. Users can also load the whole of the external project into OOA Tool. In this situation, any external assets which are loaded (or reloaded) should be loaded from the current instance of the external project which may have been edited since it was loaded.

Bridges and layers introduce an additional resolution issue when they are reused. A simple mechanism for importing a bridge would be to ensure both the client and server domain were already imported from that external project. However, either or both domains may have already been imported from another external project. Alternatively, a newer or compatible version of one of the domains may already be defined in the project. The approach that I have decided to adopt for now is to require users to explicitly resolve client and server domains when they import a bridge from an external project. If the domains are incompatible with any bridge mappings then appropriate errors will be flagged separately. The same applies to layers, users will need to explicitly resolve all connected domains when a layer is imported.

This approach provides considerably flexibility but leads to an interesting problem. How do we identify client and server domains within bridge mappings, e.g. when we want to qualify a data type. I had envisaged using domainName@ prefixes as needed within bridge mapping code. However, we may want to resolve a client or server domain to a domain with a different name. The solution I have adopted is to define domain role names and use those within bridge mappings instead, i.e. users will now use client@ or server@ prefixes instead. This solution can also be adopted in domain observer code assuming each connection defines a unique role name.

OK, so I have a workable design for domain (and other asset) reuse within projects. I have started implementing the above design and another week or so should see this work finished. This work needed to be done sooner rather than later anyway. Comments always welcome but I prefer them in English!

Week 3/4/5 of 2010

I haven't been able to spend much time on this project over the last few weeks. I've done some modelling and fixed a few OOA Tool bugs but I haven't made substantial progress towards getting the next build released. However, some of the bugs might be quite annoying for anyone using the last ALPHA release so I have done another release which can be downloaded from the following link:

2010-02-08_OOATool014_ALPHA2 (8.33 MB)