This week's report is a little late since I thought I might finish some modelling first. The only problem with that is that modelling often leads to more modelling! I've been working on the
Recursive Design and
Simulation subsystems of the OOA of OOA. In fact, I've now replaced the old
Translation subsystems with new
Population Runtime and
Colour Model subsystems. Most of the old
Simulation subsystem was actually concerned with population data anyway. I've moved the few objects directly relating to simulation and translation into the
Recursive Design subsystem which is a good home for them anyway. The new
Recursive Design subsystem is shown below:
You can now see that recursive design involves partitioning a system into domains, bridging between domains, adding layers to those domains if appropriate (new in OOA10), populating those domains, simulating the system for testing and translating the system into the final software product. Recursive design also involves colouring arbitrary aspects of the model and/or data to control aspects of simulation/translation such as population boundaries and thread allocations. I'm providing support for basic thread pools during simulation to help facilitate successful reuse, i.e. users should always test concurrent models using multiple thread simulations. There are many other architectural concerns that are not supported during simulation. Those concerns can only be tested by running a translated version of the system using an appropriate software architecture. I may need to add support for additional architectural concerns in future, e.g. concurrent access controls. Any comments here?
Colour models and Colours in Shlaer-Mellor are known as Marking Models and Marks in Executable UML. This is a neglected area of Shlaer-Mellor methodology and not well defined in MDA either. However, the need for those ideas became evident as I started to think how I would capture thread allocations for simulation purposes and population boundaries where I want to include a subset of a given population in a simulation/translation (a good example here are metamodel populations which rarely need to used entirely). I'm still working on the
Colour Model subsystem so I won't show it here. I have been thinking how I can incorporate colour models into OOA Tool but I'll leave that topic to another day also. One interesting issue with colours is how you access that information within archetype templates which traditionally only accesses object, attribute and relationship instance data.
Back to populations. The new
Population subsystem is shown below:
I've made quite a few changes here. Populations are now either
Input Populations which are project assets in their own right (i.e. can be imported into other projects),
Executable Populations used with simulations or
Translatable Populations used with translations. Input populations are
Simple Populations (i.e. user data),
Composed Populations allowing a set of input populations to be merged into one, and
Output Populations which are derived from the output state of a completed simulation run (e.g. a software architecture may code an optimizer as a model that can be simulated to generate optimization flags that can then be passed as input into a translation). Composed populations is a powerful concept when combined with output populations allowing multi-stage build processes to be defined.
An interesting issue with translation is what do you do about derived attributes and relationships? Do you use an active population during translation so that derived attributes and relationships are still determined on demand or do you pre-calculate all such information before you start the translation. I've taken the view that pre-calculation is best so that translation will in the most part be a deterministic process, i.e. if you recalculate on demand then the results may change if the calculation logic is non-deterministic (e.g. involves current time). However, this means that I can't set any attributes during translation (which is probably a bad idea anyway). In the above model, a translatable population is an input population with all derived data pre-calculated.
Population data and executable population data is shown in the model above. However, runtime population data could not also be shown without considerable mess. Thus, I've put all supplemental runtime population data into a new
Population Runtime subsystem. This was the work I was trying to finish before I did this report but I haven't quite finished it yet so I won't include it here yet. An additional requirement here is that sufficient data be gathered so that an automatically generated Thread of Control Chart (or Sequence Diagram) can be associated with each simulation run.
So I plan on finishing the
Population Runtime and
Colour Model subsystems now. I'm considering whether it's a good idea to add support for what I've done here to OOA Tool immediately without waiting for OOA Tool 2 to be completed. It would allow me to validate some of the ideas. The problem is that without a working Action Language and Archetype Language, it doesn't give us much.