Model Architecture and Design Approach

Introduction

Component-based software engineering (CBSE) has existed in one form or another for several years. The advantages of constructing modular software are well known within the software community. Modularity is a general concept which applies to the development of software in a fashion which allows individual modules to be developed, often with a standardized interface to allow modules to communicate. In fact, the kind of separation of concerns between objects in an object-oriented language is much the same concept as for modules, but on a larger scale. Typically, partitioning a system into modules helps minimize coupling, which should lead to 'easier-to-maintain' code.

Initially, software components were viewed almost exclusively as source code modules. In recent years, however, the popular use of the term software component has been with reference to so-called “binary” components. Binary component are individual software artifacts that exist in compiled form, and are typically ready for distribution. A wide variety of technologies have been developed to support the packaging of binary components.

OMS as a framework is object-oriented, the models within the framework are objects or components as understood in CBSE. However the design of OMS is unique in one important aspect. It is considered non-invasive and sees models and components as plain objects with meta data by means of annotations. Modelers do not have to learn an extensive object-oriented application programming interface (API), nor do they have to comprehend complex design patterns. Instead OMS plain objects are perfect fits as modeling components as long as they communicate the location of their (i) processing logic, and (ii) data flow. Annotations do this in a descriptive, noninvasive way. Non-invasive lightweight frameworks principles based on plain objects have proven successful in other application fields (Richardson2006) and are expected to pay dividends for agro-environmental modeling.

Why is a non-invasive approach important?

• Most OMS modelers, at least early in the development life cycle, are natural resource scientists often self-taught in programming, but not experience in software architecture and design. Most modeling projects do not employ experienced software engineers who understand and apply complex design patterns, UML diagrams, advanced object-oriented techniques such as parameterized types, or higher level data structures and composition. A hydrologist or other natural resource scientist usually does not have experience with these techniques.

• The agro-environmental modeling community maintains a large number of legacy models. Some methods and equations still in use were developed as long as 60 years ago. What has changed and will continue to change is the infrastructure around them delivering the output from these models. Smart phones and computing clouds are emerging technologies, to which lightweight, non-invasive frameworks can easily adapt.

• A lightweight framework adjusts to an existing design as opposed to defining its own specification or API. The learning curve is small, with no complex API to learn or new data types to manage. This is practical to the modeler, since there is no shift from using existing modeling code and libraries. A model component integrated with the lightweight framework can still have a 'life' outside on other platforms, and can keep evolving there.

In the graphic above, OMS system components interact with science components through annotations (metadata). This separation enables the science components to be formed into models outside of OMS without disentangling the code. Also note that modelers make OMS system components interact with science components using a domain specific language (DSL) designed for OMS modeling, precluding the need to understand the more complex OMS API.

Since OMS is a non-invasive modeling framework, the modeler does not need an extensive knowledge of object-oriented principles to make model-framework integration happen. Creating a modeling object is very easy. There are no interfaces to implement, no classes to extend and polymorphic methods to overwrite, and no framework-specific data types to replace common native language data types. Instead OMS uses metadata by means of annotations to specify and describe "points of interest" for existing data fields and methods for the framework. Annotations are explained in detail in subsequent sections of this workbook. Within a modeling object any complex internal object-oriented design can be used as needed, however, the framework does not depend on any object-oriented contract.

Modular Component Based Design

With OMS, we understand a component ideally to represent one scientific concept, manifested as a plain (Java) object with annotations. A component can be hierarchical, it may contains other, finer grained components contributing to the larger concept. It is a "black-box" that exposes its framework relevant information via meta data.

A component represents a sufficient level of complexity so that someone can use it in an executable simulation. A single component can become a model, however, a model usually is the top level component within a component hierarchy.

A large legacy monolithic model containing multiple concepts can be represented as a single component in OMS. It also can be re-factored into components and re-built as a component hierarchy. Whether deconstructing a legacy model or creating one from the ground up, a modeling team must decide on the granularity of the components in the design of the model. This mostly is a judgement call based on the modeler's knowledge of the scientific concepts involved.

The figure above shows the basic structure of an OMS component. Like all modeling frameworks OMS provides for the same features:

• Isolating the computational process in the component
• Facilitating directed data flow (slots, or exchange items)
• Managing various execution phases of a component.

As pointed out in (Peckham2008), an "Initialize #Run #Finalize" (IRF) is a common life cycle for almost all simulation models. OMS provides annotations allowing the modeler to specify these framework requirements on top of the plain object.

Science components receive inputs from (1) data files, (2) other components in the same iteration, and (3) other components in a previous iteration. The latter case has been termed feedback. The following example shows feedback data flow in the CSMLite model, where leaf area index (LAI) output from the Plant component in the first iteration is input to the Soil-Water and Plant components in the next iteration.

The term component refers to a concept in software development, which extends the re-usability of code from the source level to the executable. Components are software units that are context-independent both in the conceptual and technical domain. A component is a self contained software unit that is well separated from its environment.

The component approach takes object-oriented designs to the next level. While object-oriented design methods focus on abstraction, encapsulation, and localization of data and methods, they can also lead to simulation systems where objects are highly co-dependent. To remove this limitation, a more structured process was introduced in model development and applied to OMS: component-oriented modeling. It emphasizes the component as object-oriented software which can be developed and tested independently, and delivered as a unit. It provides its services through well defined interfaces.

Component implementations in general have proven to support reuse in a more efficient way than just using object-oriented methods. There are some general benefits of using components for building complex systems.

• Components are designed with a standard, well defined interface in mind. Such a published interface hides the implementation of the component logic and forces an abstraction level which separates the offered contract for communication from its implementation.
• Components are self contained units from the conceptual and technical perspective. They can be developed and tested individually. Finally they are packaged and are delivered to be used in several applications.
• The use of components simplifies the construction of complex systems since they change the way these are built. As opposed to programming the entire model, it can be composed using components. Some parts of a model may originate from legacy code sources, and some may be new code. A component approach facilitates the integration of legacy and new code.

The use of components helps face the challenge building complex simulation models by reducing model software complexity and overcome the limitations of monolithic, highly coupled model implementations.

Model Base of Components

The customer may require a model be used in different contexts within a business function, and the solution may involve model instances that fit into the various business work flows. Knowing these requirements up front is important for architecting the model and deploying as instances aligned with business needs. The model instances should be managed as a model base. Model base components (including the model and its instances) should be managed within an OMS modeling project and stored in the OMS Component Library.

Model Control With OMS System Components

Model Structure

References

Bernholdt D.E. and Allan B.A. and Armstrong R. and Bertrand F. and Chiu K. and Dahlgren T.L. and Damevski K. and Ewasif W.R. and Epperly T.G.W and Govindaraju M. and Katz D.S. and Kohl J.A. and Krishnan M. and Kumfert G. and Larson J.W. and Lefantzi S. and Lewis M.J. and Malony A.D. and McInnes L.C. and Nieplocha J. and Norris B. and Parker S.G. and Ray, J. Shende and S. Windus, T.L. and Zhou, S. "A Component Architecture for High Performance Scientific Computing", Journal of High Performance Computing Applications, ACTS Collection Special Issue, May 2006

Collins, N., G. Theurich, C. DeLuca, M. Suarez, A. Trayanov, V. Balaji, P. Li, W. Yang, C. Hill, and A. da Silva. Design and Implementation of Components in the Earth System Modeling Framework. International Journal of High Performance Computing Applications, Volume 19, Number 3, pp. 341-350. 2005

David O., S.L. Markstrom, K.W. Rojas, L.R. Ahuja and I.W. Schneider, The Object Modeling System. In: L.R. Ahuja, L. Ma and T.A. Howell, Editors, Agricultural System Models in Field Research and Technology Transfer, Lewis Publishers, Boca Raton (2002), pp. 317–330.

Gregersen, J.B., Gijsbers, P.J.A., and Westen, S.J.P., (2007). Open Modelling Interface. Journal of Hydroinformatics, 9 (3), 175-191. 2007

Moore, A.D., D.P. Holzworth, N.I. Herrmann, N.I. Huth, M.J. Robertson, The Common Modelling Protocol: A hierarchical framework for simulation of agricultural and environmental systems. Agricultural Systems, Volume 95, Issues 1-3, Dec 2007, Pages 37-48

Peckham, S: CSDMS Handbook of Concepts and Protocols: A Guide for Code Contributors, http://csdms.colorado.edu/wiki/Help:Tools_CSDMS_Handbook, 2008

Richardson, C: POJOs In Action. Manning Publications. Jan 2006

Rizzoli, A.E., Leavesley, G.H., Ascough II, J.C., Argent, R.M. Athanasiadis, I.N., Brilhante, V.C., Claeys, F.H., David, O., Donatelli, M., Gijsbers, P., Havlik, D., Kassahun, A., Krause, P., Quinn, N.W., Scholten, H., Sojda, R.S., and Villa, F. 2008. Chap. 7: Integrated modelling frameworks for environmental assessment and decision support. In: Environmental Modelling and Software and Decision Support – Developments in Integrated Environmental Assessment (DIEA), Vol. 3, A.J. Jakeman, A.A. Voinov, A.E. Rizzoli, and S.H. Chen (Eds.), pp. 101-118. Elsevier, The Netherlands.

Rizzoli, A.E., Svensson, M.G.E., Rowe, E.C., Donatelli, M., Muetzelfeldt, R., van der Wal, T., van Evert, F.K., Villa, F.:Modelling Framework (SeamFrame) requirements. SEAMLESS report no. 6, Dec 2005