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 Simulation and Translation subsystems with new Population, 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), Metamodel Populations, 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.
4 comments:
Hi Sean,
How refreshing to be shown some Shlaer-Mellor notation instead of that ‘orrible UML.
We should standardise on a term for Marking/Tagging/Colouring. I would prefer tagging as this implies augmenting with a value or classification. This may reflect my KC background too! Colouring is my least favourite as it sounds too abstract.
Software architectures are a whole new ball game and I would advise you to implement the simplest possible architecture. A dead simple one state at a time architecture is fine for simulation and this is the way humans run the model anyway. Code Generation is where it gets interesting and complex.
The issue with colours can be solved by having a Colours domain (or subsystem in your terminology?).
Regards,
Mike
I agree with the "'orrible UML" comment. However, any Shlaer-Mellor diagram that I show can also be viewed at a click as Executable UML in OOA Tool.
I prefer to keep the term "colouring" when referring to Shlaer-Mellor stuff to keep it distinct from the term "marking" which is very much associated with UML and MDA. A major benefit for me is that I plan to support colouring within OOA Tool using colour highlighting. Colouring is very much an abstract concept representing some arbitrary distinction.
I'm not planning on allowing arbitrary values to be associated with colours. The idea is that you would model some concept in your architectural domain (e.g. thread pool) and then colour objects and/or instances in your application model and/or input populations and also colour an instance of the concern in an architectural population (e.g. a thread pool instance). Your archetype could then determine where to go from there.
Domains and subsystems are very different things. I'm currently defining colour models in a OOA of OOA subsystem because it directly relates to population instances and transformations and I'm using colour in the Shlaer-Mellor sense here. I would only define a colours domain if I wanted to model RGB and other colour representations.
Thanks for the comment.
You said: I'm not planning on allowing arbitrary values to be associated with colours.
Say I needed to tag a class in my Application Domain model with the information that there were always going to be a maximum of 5 instances.
Obviously, that would be a very useful piece of information for the architecture since it could optimise the data structures used to implement the instance data (for example, array instead of a linked list).
How would OOA Tool Colouring deal with this situation?
Then you would define an "Object Instance Creation Constraint" object (or something similar) in your architectural domain, create an instance of that architectural object (with maximum number set to 5) as part of your input data. You could then associate a colour with that constraint and with any object that you want to constraint in such a way. Your architecture will then have to implement some additional constraint checking to ensure the user doesn't create more than 5 instances.
The interesting point here is that you will probably want to associate some kind of error handling logic with constraint failure and that can easily be done by setting additional attributes in your new architectural object. This shows the fallacy of associating values with colours/tags/marks and ever thinking that will be enough. In my view, colours should only be used to make yes/no decisions with regard to options provided by an architecture. Any tagged values should be defined in an architectural domain.
OOA Tool will (in future) deal with the above by allowing the architecture developer to:
1) create an architectural domain with an information model defining architectural concerns,
2) create a default input population (of the architectural domain) with default/basic choices for those concerns,
3) create a default colour model for selecting those choices,
4) and create a set of archetype templates which check whether particular model elements/data have been associated with a colour and also associated with a particular choice.
Then allowing the application developer to:
1) create an additional input population (of the architectural domain) if some custom choices need to configured,
2) colour model elements/data with colours associated with particular choices,
3) and finally run a translation with all input data to generate their application code.
I should point out that particular visual colours will obviously be heavily overloaded within a project. Users will be allowed to enable/disable visual colour coding for particular colour models. All colours will also have names/descriptions.
Post a Comment