Department of Crop Protection, Danish Institute of Agricultural Sciences, Research Centre Flakkebjerg, 4200 Slagelse, Denmark

Background and objectives
Decision support systems (DSSs) are often based on models that tend to be very complicated because they must integrate a diverse set of system components (eg crops, pests, weather, cultivation practices). Each component is represented by a specific set of state variables (including for the crop eg, root depth, leaf area, nitrogen content, shoot density). The components are linked by interactions which are described functionally as rates (eg water uptake rate, infection rate, translocation rate) that often depend on the state of yet other components (eg weather). The complexity inherent in simulation models has to be managed somehow, or else the models become difficult to use, maintain, and validate; furthermore, they will not be open for scientific review. Software complexity demands an engineering solution. Object-oriented design (OOD) has been suggested as one such solution [2], especially in conjunction with so-called design patterns, a recently invented tool of OOD [1]. Design patterns supply standard solutions for recurring design problems. In the case of modelling, the patterns that have been found most useful are as follows: (the pattern names are as used in [1])

Model components are frequently recursively nested; eg a plant component may consist of organ components (ear, leaves, roots) each divided into subcomponents (eg infected, uninfected, and dead area). Using the Composite pattern you define components and subcomponents as having the same set of attributes (area, nitrogen content, etc), and you let subcomponents always be managed by the component in which they reside. When manipulating a component you then don't have to speculate whether it is singular or composed of subcomponents one or several layers deep.

The usual implementation of interactions between components is as functions. Using the Strategy pattern you turn the interactions themselves into separate entities and organise them into classes of like functionality. Through inheritance from the Strategy base classes you can define derived classes that refine the details of the interactions.

Loose coupling is a key issue in the design of large software systems. A Mediator is a component whose only responsibility it is to orchestrate the interactions between all other components in the system. Using this pattern the components do not communicate directly but always indirectly, through the Mediator. This design ensures that components remain independent from the particular configuration of components in the system. Each component will only have to adhere to the common protocol for interaction which is defined by the Mediator component.

Abstract Factory
In OOD you first design generic components, so-called classes; eg you design a generic cereal class rather than a concrete spring barley class. Having designed and implemented the classes pertinent to the problem domain, the classes serve as a set of templates from which you can mould any number of models of particular systems within the domain. Abstract Factory is a design pattern for creating the concrete system components (in OOD terminology, the objects) from a given set of classes. In our case, the factory has the responsibility of creating model components, configuring them with subcomponents and strategies, and informing the mediator about all the objects and interconnections thus created. After the factory has finished its job, the model is ready to run in the hands of the mediator.

Results and conclusions
OOD and design patterns have proven useful in the development of complex eco-physiologial models [2]. The examples presented here demonstrate model designs for systems of soil, winter wheat, weeds and plant diseases, and of winter wheat, aphids and natural enemies. The approach is well-suited for designing and managing complex models and thus provides a very useful framework for developing DSSs.

1. Gamma E, Helm R, Johnson R, Vlissides J, 1995. Design patterns, Addison-Wesley, pp. 1-395.

2. Holst N, Axelsen JA, Olesen JE, Ruggle P, 1997. Object-oriented implementation of the metabolic pool model. Ecological Modelling 104, 175-187.