Figure 1: Results of running the example model
How could we help an ecologist to build a model like this? Not by giving them yet another general-purpose modelling language because these require the modeller to understand exactly which bits of the language to fit together to construct the model. Ecologists do not normally possess this sort of specialist knowledge and few seem highly motivated to acquire it. What often happens in practice is that a specialist in a sub-domain of ecology (animal population dynamics in our example) collaborates with a specialist in particular ecological modelling methods. A skilled modeller is often able to suggest a likely architecture from just a few ecological cues and to follow this up with directed questioning aimed at filling out the details. One way of providing support for this activity is to discern the major architectural features of programs such as the one above and express them in such a way that they can be instantiated to full specifications of models. These are the components which we use in model design. Each has three elements:
Choosing how to construct components requires the component designer to understand both an appropriate formal language (of which there are many) and the problem domain, so there is a training overhead at this stage in development. In general, designers need to have a feel for those parts of the specification which ``belong together'' and must then be able to generalise some of the structures in those packages by substituting them with variables. Those variables are then constrained by conditions which guide their instantiation by those in the domain of application.
We now define a set of components sufficient to construct our example model and then describe how these are parameterised to construct our example model.
