The plant, weather, and soil plant atmosphere elements of the conceptual model are presented by the classes Plant, Weather, and SoilPlantAtmosphere, as shown in Figure 10-4. Soil is represented by three classes; SoilProfile, SoilLayer, and Cell. The SoilProfile class represents the profile as a whole. Some models consider soil as a composition of layers with different properties. Some other models consider the entire soil profile as one layer. The SoilLayer class is created to store layer-specific data and behavior. The Cell class represents the surface. It represents a uniform area for which a simulation is run. The Groundwater class is created to store data and behavior for the groundwater layer, sometimes considered by water-balance and irrigation-scheduling models. The IrrigationManagement class plays an important role in irrigation-scheduling models. It stores information related to irrigation management practices and calculates outputs such as recommended irrigation rates.
A unidirectional association, referred at as usesWeatherData, links classes SoilPlantAtmosphere and Weather. The navigation direction is from SoilPlantAtmosphere towards Weather. This means that objects of class SoilPlantAtmosphere have access to data and behavior to objects of class Weather. Weather data are required to calculate processes occurring in SoilPlantAtmosphere, such as calculations of actual évapotranspiration rates. Objects of class Weather do not have access to objects of class SoilPlantAtmosphere, as there are no calculations occurring in this class. The multiplicity of the association usesWeatherData is one-to-one, meaning that one object of type SoilPlantAtmosphere has access to one object of type Weather (one source of weather data) at the time of the simulation.
The association usesWeatherData that links classes Cell and Weather has the same properties as the one linking classes SoilPlantAtmosphere and Weather, it is bidirectional and a one-to-one association.
The association between classes SoilPlantAtmosphere and Plant is unidirectional, with the navigation direction from SoilPlantAtmosphere towards Plant. An object of type SoilPlantAtmosphere can access data and behavior from an object of type Plant. The vice versa is not true; an object of type Plant cannot access data and behavior from an object of type SoilPlantAtmosphere. Processes occurring in class SoilPlantAtmosphere need plant data for their calculations. The multiplicity of the association is one-to-one; one object of type SoilPlantAtmosphere can access one object of type Plant.
The association between classes SoilPlantAtmosphere and Cell is bidirectional, as processes occurring in each of the classes need data from the other class. The multiplicity of the association is one-to-many; one object of type SoilPlantAtmosphere can access one or more objects of type Cell.
In the template shown, Cell is the central unit of the system. It has a soil profile associated with it, which, in turn, is composed of one or more layers. A soil profile may also contain groundwater. Plant grows in a Cell and the two classes are able to exchange data. Any soil data required is accessed through the Cell. Class Cell does have access to data from SoilPlantAtmosphere, which it is able to pass to SoilProflle and Soi ¡Layer, in order that, for example, water removal from the soil by évapotranspiration (ET) can be modeled.
After defining the elements involved in irrigation scheduling and waterbalance models, attributes and behavior are defined for each element represented in the diagram. Attributes represent the input data required by the model and behavior defines the processes that are calculated. Figure 10-4 shows elements, represented by classes, provided with data and behavior. Based on the general template, class diagrams were developed for two models: A water-balance model and an irrigation scheduling model that will be presented in the following sections.
Was this article helpful?