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
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:
Where the firstobjectInstance ( coloured | marked ) [ domain '@' ] colour [ '[' objectInstance ']' ]
objectInstanceexpression 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
PersistanceControlobject from a user defined
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..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
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.