POND: design rationale and approach

analysis of these facilities under various management scenarios. This paper provides an overview of the design aspects with an emphasis on object-oriented program- ming principles, functional modules and application areas of POND, a decision support software that has been developed to specifically enable analysis of pond aquaculture facilities via a combination of simulation models and enterprise budgeting.

2. POND: design rationale and approach

The rational design of DSS software is critical to determining the ultimate usefulness and maintainability of the software. Although a number of software design paradigms have come and gone over the years, a few themes relevant to software development generally, and DSS software specifically, have demonstrated their utility over relatively long time spans. These themes can be classified based on 1 their usefulness at defining the operational structure of the software, and 2 their utility in implementing, maintaining and upgrading the software at the code level. Because of the nature of DSS software, it is important that the operational structure of the software effectively addresses user requirements for defining available input data, executing knowledge bases, displaying outputs e.g. in tabular andor graphical format, and providing an effective, readily understandable user interface for manipulating the software. In the case of POND, input data require- ments were initially determined in part from the datasets typically collected during experimental protocols established by the Pond DynamicsAquaculture Collabora- tive Research Support Program PDA CRSP. This program has provided the principal development support for the POND software. Datasets collected during field experiments conducted by the PDA CRSP include weather, water quality, soil type, and fertilizerfeed inputs, and are available on the Internet Ernst et al., 1997. Although such input datasets are unlikely to be available to many users, it was felt that they would provide a reasonable starting point for model development, especially because the most important target audience initially identified for POND were aquaculture researchers. Moreover, we believed that creating a situation where users could apply pond data in model evaluation beyond their traditional use for presenting results from field experiments would guide additional field experimenta- tion designed to test model assumptions. In terms of the knowledge bases i.e. the representation scheme of knowledge in a DSS, POND was structured to support mechanistic models of varying levels of scientific detail, as described further below. It was also felt that more decision-ori- ented modules would necessarily have to have well-validated mechanistic models in place to provide a basis for effective decision support. In terms of output data presentation, one of the design criteria was that we would provide as much flexibility as possible in terms of visualizing model results in graphical andor tabular form. Finally, our assessment of trends in software development at the time that work on POND initially commenced mid-1993 suggested that the Microsoft Windows platform was likely to become the dominant operating environment. The choice of this platform lent itself well to the development of a user-friendly interface Fig. 1. To implement POND, we surveyed the available software design methodologies and settled on an object-based paradigm for the program. Object-based, or object- oriented programming OOP provides a natural and intuitive method for examining the process of decomposing problems and developing programming solutions Meyer, 1988 It goes well beyond structured programming by establishing the concept of an object, a self-contained collection of data and algorithms which directly correspond to entities in the real world. An object is an instance, or specific realization, of a class. The class is a useful design and implementation abstraction that defines the data members and methods of objects Ege, 1992. Data members store an object’s state. Specific methods define an object’s behavior and functional- ity. An object-oriented application is a set of objects that work together to achieve an overall goal. Because objects in such applications mirror reality at both conceptual and implementation levels, object-based representations are well adapted to simulation model development, and result in programs that are gener- Fig. 1. General architecture of POND showing databases, functional modules, applications and ‘experts’. ally easier to design, maintain and understand than programs based on more traditional paradigms. Specific examples that demonstrate the use of OOP princi- ples in the POND architecture are discussed in a later section of this paper. There have been many implementations of object-oriented languages. For POND, we chose C + + as the implementation language. C + + is currently the most widely used object language. It provides support for all the major characteris- tics defining the object-based paradigm, generates efficient executable code, and is widely available and portable across platforms. It has proven to be an excellent language for implementing large simulation programs. 2 . 1 . Object-oriented simulation Simulation is one of the natural applications of object-oriented programming. From an object-oriented viewpoint, simulation models are readily envisioned as an assemblage of interacting objects representing specific objects in the real world Zeigler, 1990. Although the mechanisms of OOP can be implemented with a traditional programming language supporting data abstraction, better results can be achieved with an object-oriented programming language Bischak, 1991 which directly incorporates object-orientation into the language specification. The object- based approach provides powerful tools for the representation of complex domains and results in very efficient programming environments Rumbaugh et al., 1991. The limitations of procedural approaches in simulation are well established. One of the most significant problems of traditional simulation modeling has been the lack of reusability of the simulation models andor components Rumbaugh et al., 1991. This problem stems from the fact that most simulation models are developed for a specific simulation experiment objective. When a new objective is encountered, a new model is developed from scratch even though it may include elements contained in earlier models Rumbaugh et al., 1991; Sierra and Pulido, 1991. A classic example of this type of approach can be found in the DSSAT D6ecision S6upport S6ystem for A6grotechnology T6ransfer, an assemblage of models for simu- lating the production of different crops. Although all of these models use similar methods for integrating model equations, the underlying simulation code is re- peated for each model. Thus, any improvement of the simulation approach in any one of the models would need to be repeated for all of the models. In a well-designed object-oriented approach, such a change can be made once in the simulation framework and all of the models would benefit from it. The benefits of an object-oriented approach to simulation modeling have led researchers to develop object-based models in a variety of domains. Several object oriented models have been reported in ecological and agricultural simulations Folse et al., 1990; Sequeria et al., 1991; Whittaker et al., 1991; Van Evert and Campell, 1994. All of these authors indicated the primary advantage of OOP for simulation models as a basis for model conceptualization, program design, and model reuse. Key concepts of OOP which provide mechanisms for enhancing reusability and maintainability of various models and associated components are: encapsulation, message passing, dynamic binding and inheritance Meyer, 1988; Budd, 1991. Encapsulation is a mechanism for information hiding, whereby each object hides its own information. Encapsulation ensures that object data can be protected and unwanted modification due to software errors is prevented. The use of encapsula- tion therefore improves the modularity, reliability and maintainability of system code Wilde et al., 1993. Message passing is a necessary result of encapsulation. Communication between objects is possible only through messages. Every action in an object-oriented program is initiated by objects sending messages to one another e.g. a request for the value of a certain variable. A message received by an object states ‘what’ should be done, whereas a method within an object expresses ‘how’ it will be done. A message is ‘bound’ to a method either statically at compile time or dynamically at run time Ege, 1992. Dynamic binding is the ability to determine which method of an object will be called at run time, rather than resolving the call at compile time. This feature allows references to generic objects during compilation, with the run-time behavior of the system determined by the actual objects which are active in the software system at the time. Dynamic binding provides different objects with the ability to respond to the same message in different ways. For example, animal and plant simulation objects both might have a method Grow , but each one responds to the Grow message differently. Inheritance denotes the ability of an object to derive its data and behavior automatically from another object Budd, 1991. When a new class is defined as a subclass of an existing one, data members and methods are automatically inherited from the parent class superclass. Inheritance allows new classes of objects to be created as descendants of existing ones, and may extend, reduce, or otherwise modify the parent’s functionality. It is a powerful concept that has proven to be an extremely valuable tool for constructing and reusing complex simulation compo- nents, because the inheritance hierarchy defines various levels of information and behavioral abstraction appropriate to the real-world system that is being represented. 2 . 2 . Object-oriented decision support systems DSSs have received considerable attention in the agricultural community because of the complexities in managing agricultural enterprises, which are essentially complex composites of biological, physical, environmental, and economic interac- tions. Aquaculture enterprises are also characterized by such interactions. As such, object-based methods are particularly appropriate for the construction of decision tools in these domains, because of the typically high degree of complexity that such software must address, the requirement for representation, and ability to facilitate code reuse. Such decision tools typically present several requirements that go beyond that need for simulation modeling alone. These requirements include 1 standardized public interfaces defining object access and action initiation, 2 high-level communications capabilities for components of the system to communi- cate with other components in a non-specific manner, 3 standardized methodolo- gies for collecting and transferring information among components of the system, and 4 mechanisms for synchronizing the sequencing of flow execution among system components. The OOP paradigm provides potentially useful capabilities in all of these areas. For example, standardization of public interfaces is a central OOP concept, and is readily implemented through the definition of generic objects with virtualized public interfaces, which provide the fundamental building blocks from which domain-spe- cific objects can be developed through subclassing. Virtualizing the interface allows direct communication to specific subclasses without any knowledge of the type of that subclass, a critical requirement for the development of high-level, domain-inde- pendent decision support frameworks. POND simulation objects heavily utilize these virtual interfaces to allow them to be controlled and manipulated by the simulation engine, without the simulation engine having any direct knowledge about the simulation object. Similarly, high-level communications between objects can be accomplished through a virtualized public interface, in a manner that precludes the requirement that the caller has specific knowledge about those objects retrieving the communications. POND utilizes these higher-level communication pathways for allowing ‘expert’ objects to periodically monitor the state of a simulation and post messages when potential problems occur. Other objects in the system can retrieve the messages and initiate control modifications or prescribe solutions. Synchronization and data collection can also be handled at a high level, with subclasses inheriting much of the behavior necessary to handle synchroniza- tion, data flow and communication. This relieves POND simulation objects such as ponds and fish lots from most of the burden of collecting and displaying their own internal time-series data. 2 . 3 . The POND architecture In developing POND, we utilized an existing simulation framework Bolte et al., 1993 which provides a wide range of simulation services for managing collections of interacting simulation objects. These services include: 1. basic time-flow synchronization of system components; 2. data storage, collection, display and output; 3. linear programming tools for optimization, and 4. parameter estimation methods for determining best-fit model parameters. The framework also provides a generic simulation object class, which was subclassed into specific simulation components relevant to pond modeling and decision support. The framework also relieves the developer of much of the management of simulation details, and instead allows focus on the specific compo- nents of the physical system to be modeled. This approach has proven to be an effective and powerful approach for model andor DSS development, and has provided the ability to effectively share simulation objects between applications Fig. 2. Because the underlying framework takes care of simulation details, the primary task in developing POND was to specify important factors controlling the dynamics and decision-making processes of an aquaculture facility, and define a corresponding set of simulation objects. It was important that these components Fig. 2. User interface of POND showing icons and results graphs and an enterprise budget generated after simulation model runs. allow simulation of pond dynamics at both the individual pond-level, as well as at the facility-level. Addressing this need involved providing capabilities for simulating processes within a pond, as well as allowing the definition of multiple ponds and multiple fish lots i.e. a population of fish stocked in a pond, each with their own characteristic data. Simulation of dynamic pond process requires expertise from a number of domain areas, including aquatic biology, aquatic chemistry, fish biology, fish culture, aquacultural engineering and economics. In an aquacultural facility, each of these domain areas is typically represented by well-defined entities; a facility is a collection of these entities, operating under a particular management context to allocate resources and produce fish. The object paradigm provided a natural way to represent an aquaculture facility as a collection of individual objects. Object definitions for important physical systems components, including ponds and fish lots, were developed. These were represented within the program code by subclassing from the generic simulation object provided by the simulation framework, and adding data and functionality specific to the objects. For ponds, important characteristics such as dimensions, current temperature and water quality variables, and associated fish lots were defined. For fish lots, characteristics defined for the object included species informa- tion, stocking sizes, and stocking dates and densities, among others. Methods for these objects include the ability to simulate their dynamics based on their current states and the influence of exogenous variables. POND contains a series of mini-databases, which are accessible to the various objects in the software. For instance, databases are maintained for each lot and pond in a facility, as well as for simulation settings, economic information, soil types, fertilizers, feeds, liming materials, site information and weather characteris- tics. The software also has an experimental database that allows users to specify the combination of the above databases to be used in a model experiment. This feature has proven useful for quickly assembling and executing relatively complex scenarios of alternate pond management practices. Additional objects representing ‘experts’ managing the facility were defined. These experts included 1 an aquatic chemist, with the ability to perform a wide range of water chemistry calculations, 2 an aquatic biologist, with the ability to perform functions related to fish growth and algal dynamics, 3 a weather manager, with the ability to estimate weather conditions for specific sites, 4 an aquacultural engineer, with the ability to perform heat and water balance calcula- tions, among others, and 5 and an economist, capable of performing enterprise budget analyses and managing costs of various facility operations. A schematic of the overall POND architecture is provided in Fig. 3. The various experts in POND have capabilities for simulating different aspects of production. These areas include fish performance, water temperature, water quality dynamics, and primary and secondary productivity. Models in POND are orga- nized hierarchically into two levels, allowing users to perform different kinds of analyses based on data availability and output resolution requirements. Level 1 models are fairly simple, require minimal data inputs, and are intended for applied management and rapid analysis of pond facilities. At this level, the variables simulated are fish growth based on a bioenergetics model and water temperature. Consumption of natural food by fish is assumed to be a function of fish biomass and appetite. Fertilizer application rates are typically user specified, but the model optionally generates supplementary feeding schedules. Level 2 models provide a substantially more sophisticated view of pond dynam- ics, allowing prediction of phytoplankton, zooplankton and nutrient dynamics carbon, nitrogen and phosphorus in addition to fish growth and water tempera- ture. This modeling level is intended for detailed pond analysis, management optimization and numerical experimentation. Fish can feed from natural andor artificial food pools. Consumption of natural food phytoplankton and zooplank- ton pools by fish is predicted on the basis of a resource competition model, and also depends on fish appetite. At this level, a constant, user-specified concentration of pond nitrogen, phosphorus and carbon is assumed. Mass balance accounting for each of these variables is maintained, allowing estimation of fertilizer requirements necessary to maintain steady-state levels. Both fertilization and feeding schedules are generated by Level 2 models. Further details regarding the models in POND and their verification can be found elsewhere e.g. Nath, 1996. 2 . 4 . Economics POND allows the incorporation of economic analyses of facilities in the form of enterprise budgets. Enterprise budgets allow for the accumulation of various types of cost and income streams, summarized and coupled with interest and depreciation expressions, to assess the overall economic viability of a particular production enterprise. POND supports three cost categories: 1 fixed, 2 depreciable and 3 variable costs. Fixed costs are those costs that do not change over the course of facility operation and are not depreciable e.g. baseline labor costs that are fixed throughout an analysis period. Related to fixed costs are depreciable costs, which typically are used for items which require up-front expenditures, but which may have some back-end redeemable value after some period of time. POND incorpo- rates depreciation schedules describing the loss of value of the depreciable asset over time. An example of a depreciable cost is a tractor, which has an initial cost as well as a resale value after some period in use at the facility. Variable costs are those costs that are not fixed or depreciable, and typically vary according to the scale of production e.g. seasonal labor costs, fertilizer and feed costs, and fuel and electricity costs. Fig. 3. Different software tools developed using the object-oriented simulation framework described in Bolte 1998. The arrows indicate which parts of the framework are used in these applications. The ‘Experts’ component, although not strictly simulation-based, resides at the same abstract level program- matically. The CropSim model is described in Canpolat and Bolte 1993 and AquaFarm in Ernst et al. 1993, 2000. To generate an enterprise budget, income sources are also required. POND allows the specification of any number of income sources, based on either a per unit area, per unit of production, or per facility basis. The facility simulator provides income sources relating to fish production. Additionally, interest rates used for calculating fixed and variable investment costs are required. After specifying each cost by an amount, a cost type fixed, depreciable or variable, basis per unit area, per unit of production, or per facility and other related information, the economics module in POND summarizes costs on an areal, per unit of production or facility basis, balances those costs against income, and reports the results in a tabular form. By including andor excluding particular costsincomes, or adjusting costincome details, one can quickly ‘experiment’ to determine alternative possibilities for the economic viability of various facility and management configurations. A more recent feature in the software is the ability to specify market prices for different sizes of a particular target species, and to automatically determine the time of harvest when economic returns may be optimized where marginal costs equal marginal returns. 2 . 4 . 1 . Facility simulation To conduct a facility-level simulation in POND, an appropriate collection of class instances, each of which represents one of the objects described above is created by the framework. A typical simulation might be conducted by creating a series of experts e.g. an aquatic chemist, an aquatic biologist, an aquatic engineer, a species biologist, and a fish culturist and a collection of facility entities e.g. one or more fish pond instances, each representing a pond in the facility, and one or more fish lot instances, each representing a single population of fish of the same species. The simulation then proceeds by ‘asking’ the fish culturist to manage the fish lot; it does so with the assistance of its associated experts according to the conditions present in each pond. The object paradigm makes it very straightforward to create facilities consisting of arbitrary numbers of fish ponds andor fish lots, each maintaining its own characteristic data and simulating as a separate process. POND simulations are dynamic, providing time series analysis for a range of variables that are dependent on the level of resolution requested prior to simula- tion. During the simulation, POND accumulates time series data for each variable; these data may be viewed in plots or tables at the end of the simulation run. Data may also be exported in comma-delimited format for use in other programs such as spreadsheets and databases. Because POND encapsulates an economist in its collection of supported object classes, economic analysis of the facility may be conducted at any time. Such analysis may use simulation data if available, as well as other fixed and variable costs and income streams as defined by the user. The overall approach to facility-level simulation has proven to be very flexible and effective for accomplishing POND’s design goals, and the partitioning of expertise into well-defined components has allowed reuse of these components in other simulation contexts. For example, the AquaFarm software described else- where in this special issue Ernst et al., 2000 and POND share a number of components such as the aquatic biologist, the aquatic chemist, the aquacultural engineer, and the economist in addition to the same underlying simulation framework.

3. Experience gained