Environmental Engineering Reference
In-Depth Information
Model Granularity in Components
One definition of a model is that it is a conceptualization of a process. From a
software point of view a model can be implemented in a class that offers a method for
computing a variable (or a set of interrelated variables), thus obtaining the desired
level of granularity. There might be more than one way to do this. If two different
models estimate the same variable A, we can implement both of them as alternative
methods for estimating variable A even if they have different input requirements
and different parameters. To do this, the two models must be made available as
separate units, and their input, parameters and output must be defined. Such units
are here called “strategies”, from the related design pattern introduced below.
A set of alternative models can be implemented in the same component using
the design patterns Strategy and Composite. These designs offer the component
user alternative algorithms (strategies) for doing the same thing. When building
a biophysical model component, this allows in principle alternative options to be
offered for estimating a variable or, more generally, for modelling a process. This
often-needed feature in the implementation of biophysical models comes with two
very welcome benefits on the software side: (1) it allows easier maintenance of the
component, by facilitating the addition of other algorithms, (2) it allows the easy
addition of further algorithms from the client side, without the need to recompile
the component, while keeping the same interface and the same method signature.
In summary, the strategy (a model class) encapsulates a model, the ontology of
its parameters and the test of its pre- and post-conditions. It can be used either
directly as a strategy (in this case we call it “simple strategy”, where simple indicates
that does not use other strategies as part of its implementation), or it can be used as
a unit of composition. A composite strategy differs from a simple strategy because
it needs other (simple) strategies to provide its output(s). A sequence of calls might
be implemented inside a composite class. The list of inputs includes all the inputs
of all classes involved (except those which are matched internally). The list of
outputs includes all outputs produced by each strategy and the ones specific to the
composite class (if any). The list of parameters needed includes those of the classes
associated with and the ones (if any) defined in the composite class. When the value
of a parameter is set, if the parameter belongs to an associated class, it is set in that
class. The test of pre- and post-conditions (see following paragraph) makes use of
the methods available in each associated simple strategy class, plus the new tests
specified in the composite class. If a violation of pre- and post-conditions occurs in
one of the associated classes, the message informs the user not only about the violation
that has occurred, but also in what class it has occurred. Composite strategies do
not differ in their use compared to simple strategies.
A different type of composite strategy is the context strategy. Such classes
implement an internal model to select the appropriate strategy (either simple or
composite) based on the
context
, that is, on the inputs received at each call.
An example of a context strategy is the one which estimates reference evapotrans-
piration by the Penman-Monteith, Priestley-Taylor, or Hargreaves method depending
on the inputs available.
