Week 26 Addendum

I finished the report yesterday and then headed off to the coffee shop to reflect (and flesh out the next modelling task). In particular, I thought about how I might access thread pool allocation colouring within an archetype template to generate the necessary code. It occurred to me that I would need to manually create a new colour for each thread pool instance using yesterday's model - not good! After some rework, I ended up with the following revised Colour subsystem:

The above model adds the concept of an Indexed Colour (I did call it an Array Colour for a while) which allows a colour to be defined which implicitly defines a component colour for each indexed element. Object instances are used for indexing purposes. Using the thread pool allocation issue as an example, "Thread Pool Allocation" would be an indexed colour indexed by instances of Thread Pool. Each instance of thread pool that a user creates within a simulation results in an implicit component colour of "Thread Pool Allocation" being created. To allocate event destinations etc. to a given thread pool, the user creates an Indexed Colouring Rule which references the "Thread Pool Allocation" colour and the given thread pool's object instance (along with the contents of the rule of course!).

We also need to add support for indexed colours to the Boolean binary operator which tests for colouring in the Archetype Language:

objectInstance ( coloured | marked )
    [ domain '@' ] colour [ '[' objectInstance ']' ]

Where the first objectInstance expression references the instance being checked and the second references an instance of an architectural concept (e.g. thread pool). To demonstrate the above, yesterday's example archetype code fragment is expanded below to support a PersistanceControl object from a user defined Persistence domain:

.Select many objects from instances of Object
    where selected coloured Persistence@Persist
.for all object in objects
.Select one persistenceControl
    from instances of Persistence@PersistenceControl
    where object coloured Persistence@Persist[selected]
.// Generate code to persist using control settings...
.end for

From the above, we can see that indexed colours can be checked for in a generic sense, i.e. all objects with any "Persist" colouring are selected at the start.

The only other change I made to the Colour subsystem was to refactor two ownership relationships into one. Specifically, top-level colouring rules are defined by either input populations or transformations. Since both are assets, I added a new Colouring Rule Owner object between them and asset. I'm now able to use a single defines relationship for top-level colouring rules.