Week 26 of 2010

I've continued work on the Recursive Design, Population and Colour subsystems of the OOA of OOA. I dropped the term Colour Model as it didn't add any value. The Colour subsystem is shown below:

The basic points to note are:

• Any domain can define logical Colours (called Marks in Executable UML), not just architectural domains since any domain can define archetypes for translation (e.g. a non-architectural domain may create an archetype to generate an external configuration file and use one or more colours to control the process). Even the OOA of OOA domain defines a number of colours (see next bullet).
• Colouring Rules (called Marking Rules in Executable UML) are defined by either input populations (allowing boundaries to be defined), simulations (allowing thread pool allocations, breakpoints and logging to be defined) or translations (allowing archetype specific colouring to be defined). All colours used with input populations and simulations are predefined by the OOA of OOA domain.
• The result of applying a colour rule prior to a translation is always zero or more Coloured Object Instances (called Marked Objects in Executable UML) referencing either metamodel or model object instances. The fact that we treat metamodel data just like ordinary model data makes the process here very simple.
• Visual colours are outside the scope of the OOA of OOA. Instead they are associated with work products such as diagrams and tables. The idea being that on a given diagram (e.g. an OIM) a user can associate a particular visual colour (e.g. green) with a colouring rule (e.g. the boundary rule associated with a specific input population) which applies a specific logical colour (e.g. Boundary defined by the OOA of OOA domain) to it's data. Such colour selections are normally transient.

The need for input population boundaries is particularly strong where generated populations are concerned. Metamodel populations and output populations from long simulations can be really big. If your transformation only uses a small subset of such data then a boundary can be defined by colouring objects within the boundary. Population data outside a boundary is never generated as long as the boundary is specified on the generated population itself, not a composed population which contains the generated population. One may even want to specify a boundary on a simple population to stop users adding specification data outside the scope of the population's intended use.

The need for simulation colouring rules is weaker since colours can't be accessed at runtime without providing access to metamodel data. However, the mechanism does allow concepts such as thread allocation, breakpoints and logging to be easily specified. Other concepts may be added in future. One benefit of using colouring rules here is that a translation can access them quite easily (e.g. to add simulation specific logging to generated software).

Population Selection Rules are defined using a series of inclusion/exclusion criteria. The first rule will always be an include rule. Any children will be exclude rules. Any grandchildren will be include rules etc. For example, the top level include rule may select a particular domain, with child rules excluding particular subsystems. We can combine these rules with Set Expression Rules for union, intersection and difference. Many top-level colouring rules will actually be a union set expression rule containing multiple include population selection rules. Thus, we probably don't need population selection rules to be any more flexible. A possible exception concerns the Where Selection Rule which only allows limited expressions to be defined at present.

What's not obvious from the above model is how colours are used to control archetype translations. This is done by adding a new Boolean binary operator to the Archetype Language:

objectInstance coloured [ domain '@' ] colour

Where objectInstance is an arbitrary object instance expression and domain is the name of the domain which defines the statically referenced colour (which is optional if colour defined in archetype's domain). The operator simply checks for the presence of a coloured object instance for the specified object instance. An Executable UML version of the operator will also be supported:

object marked [ domain '@' ] mark

Colours are always statically referenced within archetypes allowing OOA Tool to track colour usage and rename colours automatically if necessary. I can't see a real need for archetypes to dynamically access colours at present. An example archetype code fragment is given below:

.Select many objects from instances of Object
    where selected coloured Persist
.for all object in objects
.// Generate code to persist...
.end for

Once again for those Executable UML users out there:

.Select many classes from instances of Class
    where selected marked Persist
.for all class in classes
.// Generate code to persist...
.end for

I won't go into anything else this week since I've probably already said enough! If anyone has any views on how I'm intending to support colours (and marks) then please comment (or drop me an email).