Week 27 of 2010

I've had a very productive week modelling wise. I've been trying to finish off the Recursive Design subsystem in particular. However, I've also been resolving a few cross-subsystem modelling issues as well. If some on you are wondering what's happening with the OOA Tool 2 development. It relies heavily on the OOA of OOA unlike OOA Tool which quietly added a few extra details not in the old OOA of OOA, e.g. location information and code module support. I also want to ensure populations (including runtime populations) are fully defined in the OOA of OOA before coding the virtual machine in OOA Tool 2.

I realised one nasty issue with regards to metamodel population objects was caused by an identifier simplification that I've been using for a long time now. The simplification in question is the use of a standalone arbitrary ID attribute for identifying information models when I should have used the enclosing domain's compound identifier. The advantage gained was being able to refer to an information model using only a single referential attribute. The disadvantage was that several objects need to refer to both an information model and the enclosing domain using different referential attributes. I could have added loop constraints to ensure the referenced information model is the one defined by the referenced domain. However, I haven't being adding those constraints to date. The nasty issue only surfaced during a moment of reflection - metamodel population objects actually need to refer to two different projects, the first being the population project and the second being the metamodel project. The extent of this dual project relationship is something that definitely should be visible in the OOA of OOA but was being hidden by my identifier simplification. I've now entirely eliminated the arbitrary ID defined in information model using the enclosing domain's compound identifier instead. This took many hours! The moral of this story is don't shortcut compound identifiers in complex domains.

Now back to the Recursive Design subsystem, the latest version of which is shown below:

I've now added support for Code Modules since most developers want to bundle code into manageable files in the real world. Operations can still be coded within the model but the user will now be able to locate the actual code inside an external Action Module associated with the enclosing domain. I will have to extend the Action Language syntax to include operation definition statements so that multiple operations can be defined within a single code module. However, this change will make code reviews and configuration management much easier. Code modules also include archetype templates (see Archetype Language) and pattern sets defining syntax and lexical grammars (see Pattern Language). This does offer the possibility of manageably supporting multiple languages since we could associate a particular language with a given code module.

I've also added the concept of a Software Product which is a locatable software component at the highest level. I haven't used the word component since it would clash badly with the UML component concept. Software products include code modules (discussed above), projects and external projects (loaded from ".ooa" files), and output products generated from translations. The current version of OOA Tool also implements a few custom output products, i.e. diagrams and information model reports. Information model reports will be reimplemented using archetype templates in the future. However, diagram image generation will have to remain a custom output product for now since I imagine creating a ".png" template directly is a really difficult task!

All software products have a lifecycle. Code module lifecycles include states such as loaded, parsed, changed and saved. Project lifecycles include states such as changed and saved. External project lifecycles include states such as loaded. Output product lifecycles include states such as generated, saved and loaded. A related active object is External Asset which defines states such as loaded (has a similar state model to external project). Obviously, all of the mentioned state models will also define one or more error states etc. I haven't finished modelling the various state models yet so I can't include them here. I originally tried to keep this concept out of the OOA of OOA. However, that was a mistake with regards to the Recursive Design subsystem since it's purpose is to define how domains are integrated and reuse enabled. On the other hand, I don't like having the Task and Task Activity objects in the OOA of OOA which is almost certainly domain pollution. However, I'll keep them for now since I want to maintain support for Project Matrices (one of the original Shlaer-Mellor work products) without adding a new project management service domain. I did move (a while ago) this pollution from the Recursive Design subsystem into a separate Recursive Design Project Management subsystem to isolate it.

I've also added asset dependencies to the model. Domains should have no dependencies since they define a world in isolation. Bridges and layers obviously have domain dependencies. Input populations also have domain dependencies. Transformations have domain and input population dependencies. They may also have simulation dependencies if part of an input population is generated. There should be no code module dependencies across assets since operations remain hidden within their enclosing domain. The same should be true for pattern modules. Even though syntax might be shared across domains, e.g. I've reused some bits of Java syntax within the action, archetype and pattern languages. I'm not planning on formalizing any such sharing. Archetype modules are a little bit different since I could imagine wanting to share some templates across multiple software architecture domains. This is why I have captured the includes relationship on the model. However, changing a shared template could completely break one or more of the software architectures unless very careful consideration was given to any changes. Balancing the risks here, I'm currently going to require any included archetype modules to be defined within the same domain as the includer. This places the responsibility of checking any changes on the user which I believe is required in this situation. Comments welcome.

Remember, we are enabling Asset reuse, not Code Module reuse in the OOA of OOA. Code is simply implementation logic within an asset.

I was also going to talk about a bunch of other stuff today but it's already 7pm and I want to do some real work tomorrow! I'm almost certainly going to release a new build of OOA Tool now before OOA Tool 2 is rolled out since I'm making lots of changes to the OOA of OOA some of which I want to use to model the OOA of OOA! Anyway, enough for now.