Design patterns (see relevant paragraph in the page Design summary) are elegant and effective solutions to common programming problems; they describe how objects communicate without knowing each other’s data and methods. The design patterns strategy allows offering to the user of the component different models (one or more algorithms) by encapsulating each of them in a class. Different algorithms, which are alternate options to do the same thing, are called strategies. When building a biophysical model component this allows in principle to offer alternate options to estimate a variable or, more in general, to model a process. This often needed feature in the implementation of biophysical models, if implemented using the design pattern Strategy, comes with two very welcomed effects from the software side: 1) it allows an easier maintenance of the component, by facilitating adding other algorithms, 2) it allows to add easily further algorithms from the client side, without the need of recompiling the component, but keeping the same interface and the same call. 

A class implementing the interface inheriting from the IStrategy is a strategy of the CropML component.

This topic shows the structure of a simple strategy created via the SCC software (see topic How to create a simple strategy).

The main concept is that the only part of the code on which the developer must focus is the writing of the model.

All the other code regions contains methods which are automatically generated by SCC and which should not be changed.

1. The general structure of a simple strategy. The generated code is divided into regions which are named according to the logic implemented. The following steps of this topic will show the content of each code region.

2. Code region "Constructor". This code region contains the constructor of the class. Whenever a strategy is created, its constructor is called. In this code region, the ontology of the inputs, outputs and parameters (minimum, maximum and default values, units, description and URL) of the strategy are firstly added to dedicated Lists and then to an instance of the ModellingOptions class, which contains all the variables used by the strategy.

3. Code region "Implementation of IAnnotable". This code region contains the public properties Description and URL which were defined via the SCC software.

4. Code region "Implementation of IStrategy". This code region contains the public properties Domain, ModelType, IsContext and TimeStep, which were defined via the SCC software.

5. Code region "Instances of the parameters". This code region contains  the getter and setters for the value of the parameters of the strategy. The actual parameters are stored into the ModelingOptionsManager of the strategy. In this example, the only parameter is the "SampleParameter", see topic How to create a simple strategy.

6. Code region "Parameters initialization method". This code region contains  the method "SetParametersDefaultValue". When this method is called, the values of the parameters of the class are set to the default.

7. Code region "Static parameters VarInfo definition". This code region contains  the ontology of the parameters of the strategy. These values are the ones defined via the SCC software.

8. Code region "pre/post conditions management". This code region contains  the two methods TestPostConditions and TestPreConditions, which are called in the Update method of the Application Programming Interface of the Diseases component, and evaluates if the values of the inputs, outputs and parameters of the strategy are outside of the minimum and maximum value. If the evaluation of pre- or post-conditions gives an error, a message is send to the application (i.e., "PostConditions errors in component [name_of_the_component], strategy [name_of_the_strategy]" );

9. Code region "Model". This code region contains  the two methods Update and Estimate. The Update methods contains the call to the Estimate method, which in turn contains the formalization of the model.

10.  In this example, two input variables (DailyAirMaximumTemperature and DailyAirMinimumTemperature, Exogenous domain class) and a parameter (SampleParameter) are used to compute an output variable (LatencyDaily, Auxiliary domain class). The model is written ONLY as an example of implementation of the Estimate method.

Created with the Personal Edition of HelpNDoc: Easy to use tool to create HTML Help files and Help web sites