EFITA/WCCA 2005 25-28 July 2005, Vila Real, Portugal

Using Model Driven Architecture principles to develop crop

simulation models
Petraq Papajorgji a, Ryan Clark b

a
IFAS Information Technologies Office, University of Florida, Gainesville, FL, USA, petraq@ifas.ufl.edu
b
SOSYINC, San Francisco, CA,USA, rclark@sosyinc.com

Abstract

This papers aims to demonstrate the concept and the feasibility of developing crop simulation models
using the principles of the Model Driven Architecture approach. First, a conceptual model is constructed
using UML that represents the relationships between concepts of the domain. Objects representing
concepts of the domain are provided with the right data and behavior to play a well-defined role. Later,
the XML representation of the conceptual model is passed to a code generator engine that generates the
required code in several programming languages such as Java, C#, Visual Basic, etc.

Key words: simulation models, UML, MDA, model.

1 Introduction

The Model Driven Architecture (MDA) approach is a framework for software development defined by
the Object Management Group (OMG, http://omg.org/). At the heart of the MDA approach is the role of
models in the software development process (Kleppe et. al., 2003). Models are constructed using the
Unified Modeling Language (UML). UML is widely accepted by the software industry as the standard for
object-oriented modeling. Therefore, UML plays an important role in the MDA approach (Frankel, 2003).

MDA development lifecycle includes the development of three formal models: a Platform Independent
Model (PIM), a Platform Specific Model (PSM), and code. These models are formal models, i.e., they can
be understood by computers (Kleppe et. al., 2003).

1.1 The platform independent model (PIM)

The PIM is the first model created tha represents a high level of abstraction of the problem domain and is
independent of any implementation technology. It usually shows the main concepts of the problem
domain provided with data and behavior and their relationships. The fact that the implementation
environment could be Java or .NET, it not relevant at this point. This model is often reffered to as the
conceptual model.

1.2 The platform specific model (PSM)

A PSM is obtained by transforming a PIM while taking into consideration a particular implementation
technology. Thus, if the implementation technology would be a relational database management system,
then concepts of the problem domain will be translated into tables, and columns and their relationships
would be translated into foreign keys. In the case that Java would be the implementation technology then
concepts of the problem domain would be translated into classes and their relationships into associations
amongst them. A PIM could be transformed into one or more PSMs. The process of transforming a PIM
into PSMs is the most complex effort within the MDA approach.

2005 EFITA/WCCA JOINT CONGRESS ON IT IN AGRICULTURE 1062

EFITA/WCCA 2005 25-28 July 2005, Vila Real, Portugal

1.3 Code

Once the PSM is created, it passes to an code generation engine to generate the coresponding code in a
particular implementation environment. The Transformation from PIM to PSM, makes a PSM closer to
the implementation environment and the code generation is very much a straitforward process.

Our paper aims to present the concept and feasibility of developing a crop simulation model using the
Kraalingen aproach (Kraalingen, 1995). This model has been developed previously in Java (Papajorgji et.
al., 2001). We selected the Kraalingen model to test the MDA approach because we have already a
running system of this model so we could compare the time needed for model development and the
obtained results. The MDA-based system used to develop the simulation model is OlivaNova Model
Execution System (http://sosyinc.com).

2 Conceptual model

The conceptual model represents objects of the problem domain provided with data and behaviour and the
relationships between them. Figure 1 shows concepts such as Soil, Plant and Weather provided with data
and behaviour to play a well-defined role in the simulation process. As an example, class Plant defines
attributes such as plantDensity, fractionToCanopy, leafAreaIndex, maximumLeafNumber etc.

Figure 1 Conceptual model for a crop simulation.

2005 EFITA/WCCA JOINT CONGRESS ON IT IN AGRICULTURE 1063

EFITA/WCCA 2005 25-28 July 2005, Vila Real, Portugal

Plant is linked to Soil by association plantGrowsInSoil that represents the fact that Plant and Soil will
exchange data between them; Plant needs Soil data to calculate processes occurring in Plant and Soil
needs Plant data to calculate processes occurring in Soil (Papajorgji and Shatar, 2004).

The Weather concept is represented by two classes: Weather and DailyWeather. Class Weather represents
a container of daily weather data captured in instances of class DailyWeather. The most used daily
weather data are: minimum and maximum temperature, rainfall, solar radiation and wind speed.

Class Simulator is designed to play a superviser role in the system. Simulator has access to all other
objects created from classes Plant, Soil and Weather. Simulator is provided with a method referred to as
simulate that carries out the simulation process. The body of this method has the calls sent to the right
object in the proper sequence. Thus, simulate will send messages to object soil such as initialize,
calculateRate and integrate as defined by Kraalingen (Kraalingen, 1995).

3 Provide object with behaviour using a declarative approach

The behaviour of objects representing concepts of the problem domain is mostly defined using equations.
As an example, soil albedo is calculated using equations 1, presented as follows.

albedo = 0.1 * e * *(−0.7 * lai ) + 0.2 * (1 − e * *(−0.7 * lai )) Equation 1

Where:
lai = leaf area index.

Figure 2 Writing equations using attributes of objects of the diagram.

Figure 2 shows the OlivaNova modeler used to declaratively define the value of soil albedo by selecting

2005 EFITA/WCCA JOINT CONGRESS ON IT IN AGRICULTURE 1064

EFITA/WCCA 2005 25-28 July 2005, Vila Real, Portugal

attributes from objects of the conceptual diagram that are used in the formula for calculating soil albedo.
The formula used to calculate the value of a derived attribute may require the definition of some condition
that should be true for the calculation to take place. Figure 2 shows that the condition for calculating the
value of soil albedo is that an instance of class Plant should exist; the formula for calculating soil albedo
requires data from Plant, such as leaf area index.

Another way of providing objects with behaviour is to define services. A service represents a certain
functionality that the class should provide (CARE Technologies, 2005). Services in Oliva Nova can be of
the following types: events, transactions and operations. Events are atomic units of activity that occur at
some point in time (CARE Technologies, 2005). Transactions are atomic processing units composed of
one or more services i.e., events or other transactions (CARE Technologies, 2005). In the case a
transaction fails execution then the situation is rolled back to the state before the transaction occurs.
Operations are similar to transactions but do not roll back in case of failure.

MDA makes heavily use of the design by contract approach (Meyer, 1988. Warmer and Kleppe, 1999).
According to this approach, some constraints must be satisfied for a routine or service to function.
Figure3 shows the dialog with Oliva Nova for defining the precondition for service integrate as stated by
Kraalingen (1995).

Figure 3 Dialog for defining precondition for service "integrate".

As shown in Figure 3, Plant should be in the state of postplanting in order to perform the service referred
to as integration. In the case that service integrate is executed when the precondition is not satisfied, then
an appropriate error message is shown to the user.

The simulation process will be carried out by object Simulator as shown in Figure 1. Simulator has access
to all other objects of the conceptual diagram to send them the right message at the right time. Therefore,
this object is provided with a service, named simulate, to perform the required functionality. This service
is implemented as a transaction.

2005 EFITA/WCCA JOINT CONGRESS ON IT IN AGRICULTURE 1065

EFITA/WCCA 2005 25-28 July 2005, Vila Real, Portugal

4 Generating code form the conceptual model

As mentioned previously, the heart of the MDA approach is generating code by applying a series of
transform(s) to the PIM. The conceptual model expresses all the elements of the problem domain and
their relationships. The model must be complete and rigorous so that code could be generated by applying
transform(s) to the model.

There is some scepticism in the software engineering community about the role of model-centric
approaches. Many believe that only code is the ultimate product of a software project and the focus
should be in the code-generation process. According to the code-centric approach, only when code is
obtained, errors could be found and corrected. Although there is some truth in this statement, the process
of checking the validity of the model can start while designing the model. MDA-based tools provide
ample capabilities to check the correctness of the conceptual model, its objects behaviour and
relationships between them. An XML file is created that contains detailed specification about the model
that can be used by code engines to generate code in several programming languages. Figure 4 shows the
dialog with the MDA tool for selecting the programming environment for the server and the client. As
shown in this figure, the user can choose the C# environment for developing the user interface and a
CORBA-EJB, Java-based environment for the implementation of the server. Because the conceptual
model is detailed and précised; code generators can find all the needed information to translate the model
in several programming environments. Besides the code representing objects of the conceptual model,
code generators will provide all the wiring code that links the client and the server applications.

Figure 4 Selecting optins for code -generation.

2005 EFITA/WCCA JOINT CONGRESS ON IT IN AGRICULTURE 1066

EFITA/WCCA 2005 25-28 July 2005, Vila Real, Portugal

5 Conclusions

The MDA defines models of applications in terms that are familiar to users focusing more on the business
concerns and less on the implementation issues. In MDA the focus is on developing software using
concepts from the problem domain, thus increasing the number of people that can successfully participate
in the model discussion. MDA brings the software engineers closer to the business specialist thus
allowing for a better collaboration between them. The role of specialists from the problem domain is
increased as they can be more actitive during the process of software design.

MDA makes extensive use of UML that is a standard widely accepted by the software enginnering
community. UML allows for developing software visualy. UML models are well-defined and therefore
they can be passed to automatic code generators to produce code in several programming environments
such as Java, .NET, Visual Basic, etc.

The intellectual investment in the form of a PIM is not jeopardized when members of the design team
leave the company. All the details needed for the execution of the model are expressed in terms of objects
and their relationships, object’s behavior and object’s data. The formulas and the business rules needed to
express how the system works and interacts with other systems, are presented in a declarative manner,
that is easy to understand and modify. No code is required to be developed as the code is generated by
code generators that embed the best software practices.

6 References

CARE Technologies, 2005. OlivaNova Model Execution System, Introduction. http://sosyinc.com

Frankel, S.D., 2003. Model Driven Architecture. Applying MDA to Enterprise Computing. Wiley
Publishing, Inc. OMG Press.

Kraalingen D.W.G. van. 1995. The FSE system for crop simulation, version 2.1. QuantitativeApproaches
in Systems Analysis Report no. 1. AB/DLO, PE, Wageningen.

Object Management Group (OMG), http://omg.org/

Meyer, B., 1998 Object-Oriented software construction. Prentice Hall

Papajorgji. P, Braga, R., Jones, J.W., Porter, C., Beck, H.W. 2001. Object-Oriented design of crop
models with interchangeable modules: concepts and issues. 2nd International Symposium, Modelling
Cropping Systems, Florence, Italy.

Papajorgji, P., Beck, W.B., Braga, J.L., 2004. An architecture for developing service-oriented and
component-based environmental models. Ecological Modelling vol. 179 (1), 61e76.

Papajorgji, P., Shatar, T., 2004. Using the Unified Modelling Language to develop soil water-balance and
irrigation-scheduling models. Environmental Modelling & Software 19, 451e459.

Kleppe, A., Warmer, J., Bast, W., 2003. MDA Explained The Model Driven Architecture: Practice and
Promise. Addison-Wesley.

Warmer, J., Kleppe, A., 1999. The Object Constraint Language Precise Modeling with UML. Addison
Wesley.

2005 EFITA/WCCA JOINT CONGRESS ON IT IN AGRICULTURE 1067