pdf: 600KB - Potsdam Institute for Climate Impact Research

13
into the correct order. In some cases, however, such models could not be implemented in a componentbased
framework in which each submodel corresponds to one component: it is not possible to carve the
model up into independent 'black box' submodels.
Example: consider a model containing a farmer component and a crop component, with crop
harvesting being influenced by farmer labour input and influencing farmer revenue. The crop
component cannot be called first, because it depends on labour input; but the farmer component
cannot be called first, because it depends on crop harvesting.
The only way around this is to split the 'rate' calculations in the component into several steps. However,
the programmer needs to know the precise pattern of influence links in the external components in order
to know how to do this. This violates a key principle of the component-based approach, that
components can be programmed without regard to the other modules they may be combined with.
This may sound an esoteric criticism, but in fact we have found that a number of the submodels in the
FLORES model [see URLs] have such influence linkages, leading to the view that this is a practical as
well as a theoretical criticism.
Opacity and rigidity of the component interface
Paradoxically, the biggest weakness of the component-based approach is put forward by its proponents
as its major strength. Components are delivered as black boxes: indeed, in COM they are provided in
compiled binary form. The only way in which the outside world (other components or input/output
tools) can communicate with them is through a fixed, pre-defined interface. This is claimed as a virtue
because all that the user of the module needs to know is the interfacing: how the module does its job is
irrelevant.
Now, this approach is fine in the software engineering world. If I want to use a text window component
in a program, then it's great if all I need to know is how to call it. But models are designs - not just at
the model level (in terms of components), but also at the inside-component level as well. Why
deliberately hide the contents of a submodel from the modeller?
On top of this, imagine that the international ecosystem modelling community does actually standardise
on a particular component-based approach. Scientists around the world start developing components
according to the standard. Plant models, soil water and nutrient models, animal grazing models, and so
on. Others want to start building ecosystem models from these components. What are the chances of
these components being interfaceable: in other words, that the soil water output provided by the soil
water submodel will match the soil water input required by the plant submodel? In a very controlled
situation (a particular research team, having spent considerable effort defining the interfacing between
the components of their ecosystem model), the components will indeed interface. But choosing
components, developed without regard to each other, off the web, and one can virtually guarantee that
they will not interface. In contrast, submodels in a declarative modelling approach do not have rigid,
opaque 'shells', so it is easier to make connections between arbitrary pairs of submodels.
The conclusion is that a component-based approach might well work at a local level. But it cannot by
itself be the way forward if we dare to envision a future in which we build models by choosing from a
global pool of submodels, adapting them as needed to combine them together.