Development of decision support tools for aquaculture: …directory.umm.ac.id/Data...

Aquacultural Engineering 23 (2000) 103–119

Development of decision support tools foraquaculture: the POND experience

John Bolte a,*, Shree Nath b, Doug Ernst a

a Department of Bioresource Engineering, Oregon State Uni6ersity, Cor6allis, OR 97331, USAb Skillings–Connolly, Inc., 5016 Lacy Boule6ard S.E., Lacey, WA 95803, USA

Received 17 March 1999; accepted 29 September 1999

Abstract

Decision support systems (DSS) are potentially valuable tools for assessing the economicand ecological impacts of alternative decisions on aquaculture production. In this paper, wediscuss the philosophy of design, functional modules and application areas of POND, adecision tool that has been developed to allow analysis of pond aquaculture facilities by theuse of a combination of simulation models and enterprise budgeting. We focus less on thedetails of POND’s internal models, and more on the experiences we have gained from goingthrough the process of the designing, developing and using the POND software. POND wasdesigned and implemented using object-oriented programming principles. The softwaremakes use of a simulation framework to provide much of the generic simulation, datahandling, time flow synchronization and communication features necessary for complexmodel-based DSSs. Additionally, an architecture suitable for representing and manipulatingpond aquaculture facilities was developed in order to meet the design specifications ofPOND. This architecture includes a series of mini-databases, a number of knowledge-basedcomponents (‘experts’), models of the pond ecosystem, and various decision support features(e.g. assembling alternate management scenarios, economic analysis, and data visualization).A typical POND simulation consists of assembling a number of appropriate objects orentities (e.g. multiple ponds and fish lots), their management settings together with appropri-ate experts (e.g. an aquaculture engineer, an aquatic biologist, an economist, etc.), andprojecting changes in the facility over time. Our experience with the development of PONDand other simulation-based tools indicates that the object-based approach provides a robustfoundation for developing tools which allow code reusability, facilitate maintenance ofcomplex software, and enable partition of program development among multiple pro-

www.elsevier.nl/locate/aqua-online

-

* Corresponding author. Tel.: +1-541-7374021; fax: +1-541-7372082.E-mail address: [email protected] (J. Bolte)

0144-8609/00/$ - see front matter © 2000 Elsevier Science B.V. All rights reserved.PII: S0144 -8609 (00 )00049 -2

104 J. Bolte et al. / Aquacultural Engineering 23 (2000) 103–119

grammers. Experience gained with POND users suggests that there are largely two groups ofaquaculture personnel interested in such applications, namely commercial growers andeducators. These two groups have substantially different interests and needs. Consequently,a single tool such as POND may not optimally meet the requirements of both groups. Recentdevelopment work on POND, and the need to involve users in the design process of suchtools are discussed. © 2000 Elsevier Science B.V. All rights reserved.

Keywords: Aquaculture; Decision support; Object-orientated modeling; Pond dynamics; Simulation;Tilapia

1. Introduction

Ponds used for aquacultural production are typically complex systems that canbe driven by a wide range of inputs and interactions. This complexity can makedesigning and managing these systems challenging: successful fulfilment of thesetasks can often be assisted by the application of tools that capture important systemdrivers and their interactions. These drivers can be both ecological and economic innature. Within the realm of pond aquaculture planning and management, decisionsmust be made regarding site locations, target fish species and appropriate practicessuch as fish feeding, pond fertilization and liming, stocking densities, aeration, andwater exchange (Hickling, 1962; Boyd, 1979; Allen et al., 1983; Colt, 1986; Hepher,1988). These decisions typically have considerable effects on resource use efficiencyand therefore the economics of an aquaculture facility (Allen et al., 1983). Thedecision-making process typically requires some expertise on the part of theplanner, manager or extension agent. Such expertise includes an understanding ofthe principles of pond aquaculture and the implications of various decisions onfacility-level economics (Shang, 1981; Allen et al., 1983). In certain situations, itmay also be necessary to address socio-economic issues such as receptivity offarmers to new technology, and alternative uses of available resources (Chambers etal., 1989; Harrison, 1994; Molnar et al., 1996). Decision-makers usually acquire therequired knowledge via a combination of formal education and experience.

Often, the immediate need for pond aquaculture technology may cause decision-makers to apply or recommend management practices developed and tested at onelocation to a new site, without first assessing the appropriateness of the technology.The use of technology that has been found to be suitable for one location may verywell be inadequate when applied elsewhere (Colt, 1986). This may be due todifferences in fish production potential caused by the variability in climate, waterand soil characteristics among sites (King and Garling, 1983), and because ofdifferences in the availability and cost of resources used in pond production (Shang,1981). For example, a decision as specific as the calculation of feed requirements fora pond requires consideration of fish biomass, natural food availability, and watertemperature which vary both with time and among different locations (Hepher,1988). Similarly, calculation of fertilizer application rates requires a basic under-standing of soil and water chemistry both of which also vary among different sites.In both cases, availability and cost of appropriate inputs should be factored intothe decision-making process (Shang, 1981).

105J. Bolte et al. / Aquacultural Engineering 23 (2000) 103–119

The complexity of decision-making for an aquaculture facility suggests the needfor computerized analytical tools that can integrate biological, physical, environ-mental, economic, and social components of the knowledge base required to arriveat a decision. Such tools, termed decision support systems (DSS), integrate knowl-edge in the form of mathematical models, rule-based (expert) systems, and/ordatabases into user-friendly software systems focused on developing, analyzing andoptimizing management strategies. These tools have emerged as powerful tools forcapturing expert knowledge about particular domains and providing that knowl-edge in a friendly, easy-to-use manner to end users. In a broader sense, DSSsaddress the problem of packaging a large domain of scientific and technicalknowledge into a form that is of practical value to a diverse audience, includingnon-scientists (Lannan, 1993). The power of such systems results from theircapability for representing and manipulating both quantitative and qualitativeknowledge that describe objects in the domain of interest and their inter-relationships.

A key component of any DSS is the knowledge base(s) upon which decisions aremade. Expertise exists in many forms, ranging from highly qualitative ‘rule ofthumb’ approaches useful for representing subjective information, to databasescontaining historical data, to more rigorous and quantitative mathematical al-gorithms that describe explicit relationships among components of the domain inquestion (Hopgood, 1991).

In agriculture, DSSs have been developed for the diagnosis of plant diseases(Michalski et al., 1982), crop production (Smith et al., 1985), analyzing marketingalternatives (Uhrig et al., 1986), selection of appropriate crop cultivars (Lodge andFrecker, 1989; Bolte et al., 1990), pesticide application (Ferris et al., 1992) andmany other applications. DSSs that have been developed for aquaculture can beclassified into two broad categories: farm management/planning tools (Gempesawet al., 1992; Ernst et al., 1993; Lannan, 1993; Silvert, 1994; Itoga and Brock, 1995;Ernst et al., 2000) and macro-economic tools (Pedini et al., 1995; El-Gayar andLeung, 1996). DSSs that fall into the former category deal primarily with decisionsrelevant to farm management operations (e.g. fertilizer and lime recommendationsfor ponds as in Lannan, 1993; site selection for marine fish culture operations as inSilvert, 1994; tilapia disease diagnosis and treatment as in Itoga and Brock, 1995),as well as long-term planning tasks that may be required during the initial designphase of a farm (e.g. financial assessment relevant to the target fish species as inGempesaw et al., 1992). Macro-economic tools, on the other hand, have beendeveloped to evaluate project proposals (e.g. Pedini et al., 1995) and to examine theeconomic consequences of aquaculture development of one or more culture speciesin larger regions varying in size from districts to perhaps entire countries (El-Gayarand Leung, 1996). The development of both categories of aquaculture DSSs isrelatively recent, and the presently available tools are essentially first generationproducts.

With the exception of the system described by Ernst et al. (1993), none of thefarm management/planning DSSs were designed to serve as a framework forrepresenting aquaculture facilities and providing capabilities for comprehensive


analysis of these facilities under various management scenarios. This paper providesan overview of the design aspects (with an emphasis on object-oriented program-ming principles), functional modules and application areas of POND, a decisionsupport software that has been developed to specifically enable analysis of pondaquaculture facilities via a combination of simulation models and enterprisebudgeting.

2. POND: design rationale and approach

The rational design of DSS software is critical to determining the ultimateusefulness and maintainability of the software. Although a number of softwaredesign paradigms have come and gone over the years, a few themes relevant tosoftware development generally, and DSS software specifically, have demonstratedtheir 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 codelevel.

Because of the nature of DSS software, it is important that the operationalstructure of the software effectively addresses user requirements for definingavailable input data, executing knowledge bases, displaying outputs (e.g. in tabularand/or graphical format), and providing an effective, readily understandable userinterface for manipulating the software. In the case of POND, input data require-ments were initially determined in part from the datasets typically collected duringexperimental protocols established by the Pond Dynamics/Aquaculture Collabora-tive Research Support Program (PD/A CRSP). This program has provided theprincipal development support for the POND software. Datasets collected duringfield experiments conducted by the PD/A CRSP include weather, water quality, soiltype, and fertilizer/feed 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 feltthat they would provide a reasonable starting point for model development,especially because the most important target audience initially identified for PONDwere aquaculture researchers. Moreover, we believed that creating a situation whereusers could apply pond data in model evaluation (beyond their traditional use forpresenting 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 ina DSS), POND was structured to support mechanistic models of varying levels ofscientific detail, as described further below. It was also felt that more decision-ori-ented modules would necessarily have to have well-validated mechanistic models inplace to provide a basis for effective decision support. In terms of output datapresentation, one of the design criteria was that we would provide as muchflexibility as possible in terms of visualizing model results in graphical and/ortabular form. Finally, our assessment of trends in software development at the timethat work on POND initially commenced (mid-1993) suggested that the Microsoft


Windows platform was likely to become the dominant operating environment. Thechoice 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 methodologiesand settled on an object-based paradigm for the program. Object-based, or object-oriented programming (OOP) provides a natural and intuitive method for examiningthe process of decomposing problems and developing programming solutions(Meyer, 1988) It goes well beyond structured programming by establishing theconcept of an object, a self-contained collection of data and algorithms whichdirectly correspond to entities in the real world. An object is an instance, or specificrealization, of a class. The class is a useful design and implementation abstractionthat defines the data members and methods of objects (Ege, 1992). Data membersstore 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 achievean overall goal. Because objects in such applications mirror reality at bothconceptual and implementation levels, object-based representations are welladapted 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 moretraditional 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. ForPOND, we chose C+ + as the implementation language. C+ + is currently themost widely used object language. It provides support for all the major characteris-tics defining the object-based paradigm, generates efficient executable code, and iswidely available and portable across platforms. It has proven to be an excellentlanguage 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 anassemblage of interacting objects representing specific objects in the real world(Zeigler, 1990). Although the mechanisms of OOP can be implemented with atraditional programming language supporting data abstraction, better results canbe achieved with an object-oriented programming language (Bischak, 1991) whichdirectly incorporates object-orientation into the language specification. The object-based approach provides powerful tools for the representation of complex domainsand results in very efficient programming environments (Rumbaugh et al., 1991).

The limitations of procedural approaches in simulation are well established. Oneof the most significant problems of traditional simulation modeling has been thelack of reusability of the simulation models and/or components (Rumbaugh et al.,1991). This problem stems from the fact that most simulation models are developedfor a specific simulation experiment objective. When a new objective is encountered,a new model is developed from scratch even though it may include elementscontained in earlier models (Rumbaugh et al., 1991; Sierra and Pulido, 1991). Aclassic example of this type of approach can be found in the DSSAT (D6 ecisionS6 upport S6 ystem for A6 grotechnology T6 ransfer), an assemblage of models for simu-lating the production of different crops. Although all of these models use similarmethods for integrating model equations, the underlying simulation code is re-peated for each model. Thus, any improvement of the simulation approach in anyone of the models would need to be repeated for all of the models. In awell-designed object-oriented approach, such a change can be made (once) in thesimulation framework and all of the models would benefit from it.

The benefits of an object-oriented approach to simulation modeling have ledresearchers to develop object-based models in a variety of domains. Several objectoriented models have been reported in ecological and agricultural simulations(Folse et al., 1990; Sequeria et al., 1991; Whittaker et al., 1991; Van Evert andCampell, 1994). All of these authors indicated the primary advantage of OOP forsimulation models as a basis for model conceptualization, program design, andmodel reuse.

Key concepts of OOP which provide mechanisms for enhancing reusability andmaintainability 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 itsown information. Encapsulation ensures that object data can be protected andunwanted modification due to software errors is prevented. The use of encapsula-tion therefore improves the modularity, reliability and maintainability of systemcode (Wilde et al., 1993). Message passing is a necessary result of encapsulation.Communication between objects is possible only through messages. Every action inan 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 objectstates ‘what’ should be done, whereas a method within an object expresses ‘how’ itwill 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 todetermine which method of an object will be called at run time, rather thanresolving the call at compile time. This feature allows references to generic objectsduring compilation, with the run-time behavior of the system determined by theactual objects which are active in the software system at the time. Dynamic bindingprovides different objects with the ability to respond to the same message indifferent ways. For example, animal and plant simulation objects both might havea method Grow(), but each one responds to the Grow() message differently.

Inheritance denotes the ability of an object to derive its data and behaviorautomatically from another object (Budd, 1991). When a new class is defined as asubclass of an existing one, data members and methods are automatically inheritedfrom the parent class (superclass). Inheritance allows new classes of objects to becreated as descendants of existing ones, and may extend, reduce, or otherwisemodify the parent’s functionality. It is a powerful concept that has proven to be anextremely valuable tool for constructing and reusing complex simulation compo-nents, because the inheritance hierarchy defines various levels of information andbehavioral abstraction appropriate to the real-world system that is beingrepresented.

2.2. Object-oriented decision support systems

DSSs have received considerable attention in the agricultural community becauseof the complexities in managing agricultural enterprises, which are essentiallycomplex 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 decisiontools in these domains, because of the typically high degree of complexity that suchsoftware must address, the requirement for representation, and ability to facilitatecode reuse. Such decision tools typically present several requirements that gobeyond 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 amongsystem 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 isreadily implemented through the definition of generic objects with virtualized publicinterfaces, which provide the fundamental building blocks from which domain-spe-cific objects can be developed through subclassing. Virtualizing the interface allowsdirect communication to specific subclasses without any knowledge of the type ofthat subclass, a critical requirement for the development of high-level, domain-inde-pendent decision support frameworks. POND simulation objects heavily utilizethese virtual interfaces to allow them to be controlled and manipulated by thesimulation engine, without the simulation engine having any direct knowledgeabout the simulation object. Similarly, high-level communications between objectscan be accomplished through a virtualized public interface, in a manner thatprecludes the requirement that the caller has specific knowledge about those objectsretrieving the communications. POND utilizes these higher-level communicationpathways for allowing ‘expert’ objects to periodically monitor the state of asimulation and post messages when potential problems occur. Other objects in thesystem can retrieve the messages and initiate control modifications or prescribesolutions. 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 asponds and fish lots from most of the burden of collecting and displaying their owninternal 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 collectionsof 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, and4. parameter estimation methods (for determining best-fit model parameters).

The framework also provides a generic simulation object class, which wassubclassed into specific simulation components relevant to pond modeling anddecision support. The framework also relieves the developer of much of themanagement 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 aneffective and powerful approach for model and/or DSS development, and hasprovided the ability to effectively share simulation objects between applications(Fig. 2). Because the underlying framework takes care of simulation details, theprimary task in developing POND was to specify important factors controlling thedynamics and decision-making processes of an aquaculture facility, and define acorresponding 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) generatedafter simulation model runs.

allow simulation of pond dynamics at both the individual pond-level, as well as atthe facility-level. Addressing this need involved providing capabilities for simulatingprocesses within a pond, as well as allowing the definition of multiple ponds andmultiple fish lots (i.e. a population of fish stocked in a pond), each with their owncharacteristic data. Simulation of dynamic pond process requires expertise from anumber 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 facilityis a collection of these entities, operating under a particular management context toallocate resources and produce fish.

The object paradigm provided a natural way to represent an aquaculture facilityas a collection of individual objects. Object definitions for important physicalsystems components, including ponds and fish lots, were developed. These wererepresented within the program code by subclassing from the generic simulationobject provided by the simulation framework, and adding data and functionalityspecific to the objects. For ponds, important characteristics such as dimensions,


current temperature and water quality variables, and associated fish lots weredefined. For fish lots, characteristics defined for the object included species informa-tion, stocking sizes, and stocking dates and densities, among others. Methods forthese objects include the ability to simulate their dynamics based on their currentstates and the influence of exogenous variables.

POND contains a series of mini-databases, which are accessible to the variousobjects in the software. For instance, databases are maintained for each lot andpond in a facility, as well as for simulation settings, economic information, soiltypes, fertilizers, feeds, liming materials, site information and weather characteris-tics. The software also has an experimental database that allows users to specify thecombination of the above databases to be used in a model experiment. This featurehas proven useful for quickly assembling and executing relatively complex scenariosof 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 widerange of water chemistry calculations, (2) an aquatic biologist, with the ability toperform functions related to fish growth and algal dynamics, (3) a weathermanager, with the ability to estimate weather conditions for specific sites, (4) anaquacultural engineer, with the ability to perform heat and water balance calcula-tions, among others, and (5) and an economist, capable of performing enterprisebudget analyses and managing costs of various facility operations. A schematic ofthe overall POND architecture is provided in Fig. 3.

The various experts in POND have capabilities for simulating different aspects ofproduction. These areas include fish performance, water temperature, water qualitydynamics, and primary and secondary productivity. Models in POND are orga-nized hierarchically into two levels, allowing users to perform different kinds ofanalyses based on data availability and output resolution requirements. Level 1models are fairly simple, require minimal data inputs, and are intended for appliedmanagement and rapid analysis of pond facilities. At this level, the variablessimulated 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 biomassand appetite. Fertilizer application rates are typically user specified, but the modeloptionally 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, managementoptimization and numerical experimentation. Fish can feed from natural and/orartificial food pools. Consumption of natural food (phytoplankton and zooplank-ton pools) by fish is predicted on the basis of a resource competition model, andalso depends on fish appetite. At this level, a constant, user-specified concentrationof pond nitrogen, phosphorus and carbon is assumed. Mass balance accounting foreach of these variables is maintained, allowing estimation of fertilizer requirementsnecessary to maintain steady-state levels. Both fertilization and feeding schedulesare generated by Level 2 models. Further details regarding the models in PONDand 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 ofenterprise budgets. Enterprise budgets allow for the accumulation of various typesof cost and income streams, summarized and coupled with interest and depreciationexpressions, to assess the overall economic viability of a particular productionenterprise. 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 offacility operation and are not depreciable (e.g. baseline labor costs that are fixedthroughout an analysis period). Related to fixed costs are depreciable costs, whichtypically are used for items which require up-front expenditures, but which mayhave some back-end redeemable value after some period of time. POND incorpo-rates depreciation schedules describing the loss of value of the depreciable assetover time. An example of a depreciable cost is a tractor, which has an initial costas well as a resale value after some period in use at the facility. Variable costs arethose costs that are not fixed or depreciable, and typically vary according to thescale of production (e.g. seasonal labor costs, fertilizer and feed costs, and fuel andelectricity costs).

Fig. 3. Different software tools developed using the object-oriented simulation framework described inBolte (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. PONDallows the specification of any number of income sources, based on either a per unitarea, per unit of production, or per facility basis. The facility simulator providesincome sources relating to fish production. Additionally, interest rates used forcalculating fixed and variable investment costs are required. After specifying eachcost 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 economicsmodule in POND summarizes costs on an areal, per unit of production or facilitybasis, balances those costs against income, and reports the results in a tabular form.By including and/or excluding particular costs/incomes, or adjusting cost/incomedetails, one can quickly ‘experiment’ to determine alternative possibilities for theeconomic viability of various facility and management configurations. A morerecent feature in the software is the ability to specify market prices for differentsizes of a particular target species, and to automatically determine the time ofharvest when economic returns may be optimized (where marginal costs equalmarginal returns).

2.4.1. Facility simulationTo conduct a facility-level simulation in POND, an appropriate collection of

class instances, each of which represents one of the objects described above iscreated by the framework. A typical simulation might be conducted by creating aseries 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. oneor more fish pond instances, each representing a pond in the facility, and one ormore fish lot instances, each representing a single population of fish of the samespecies). The simulation then proceeds by ‘asking’ the fish culturist to manage thefish lot; it does so with the assistance of its associated experts according to theconditions present in each pond. The object paradigm makes it very straightforwardto create facilities consisting of arbitrary numbers of fish ponds and/or 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 ofvariables 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. Datamay also be exported (in comma-delimited format) for use in other programs suchas spreadsheets and databases. Because POND encapsulates an economist in itscollection of supported object classes, economic analysis of the facility may beconducted at any time. Such analysis may use simulation data if available, as wellas 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 flexibleand effective for accomplishing POND’s design goals, and the partitioning ofexpertise into well-defined components has allowed reuse of these components inother simulation contexts. For example, the AquaFarm software described else-where in this special issue (Ernst et al., 2000) and POND share a number ofcomponents such as the aquatic biologist, the aquatic chemist, the aquacultural


engineer, and the economist (in addition to the same underlying simulationframework).

3. Experience gained

The design, development and implementation of the POND software has pro-vided useful lessons in several areas. As the user base for POND has grown, wehave had the opportunity to solicit feedback on how well POND is addressing userneeds. The first lesson is that a diverse group of users has used POND to addressa diverse set of needs. Although we originally anticipated a research-focusedaudience, our largest group of users has in fact been commercial aquaculturefacility managers. The primary focus of this group has been on economic analyses,with the utility of the biological models contained within POND of secondaryimportance. An additional audience has been educators using POND in theclassroom as a tool for examining pond dynamics, where the biological models playa more important role. Each of these groups has a different set of interests and adifferent user interface requirement, and the ‘one size fits all’ approach that weinitially used has not been optimal in addressing their respective needs.

A primary feedback from POND users involved the ease of use of the software.Although we have spent considerable effort in developing a modern user interfacefor POND, because of the underlying complexity of the models POND employsand our desire to fully expose these models, the user interface proved to beburdensome for many users. Exposure of the underlying models is helpful to thosefocused on understanding the detailed biological dynamics of these systems, but itis less helpful or irrelevant to those focused primarily on economic analyses offacility operations. We are addressing this issue in upcoming releases of POND intwo ways. First, the focus of POND, from a user interface perspective, is more ondecision support and less on models of the underlying biophysical system. Theunderlying models continue to be an essential tool for supporting decision-making,but are less apparent to the user. In other words, they operate in the backgroundbut play a secondary role to higher-level decision-making processes. Second, wehave introduced a series of ‘wizards’ into POND. These wizards are software toolsthat ‘walk’ the user through specific and frequently used tasks (e.g. estimating feed,fertilizer and water requirements and associated economic implications). The wiz-ards hide much of the complexity of these tasks and provide immediate help to theuser in accomplishing their goals. We anticipate continued development of thesewizards to address specific needs of different user groups and to improve ease of useof the program.

The target audience for POND continues to evolve. The bulk of our requestscome from commercial producers looking for tools to improve their ability todesign and manage their facilities. We are examining the possibility of developingan additional product specifically oriented towards routine management of aquacul-ture ponds. It is expected that some of the components developed and tested inPOND will be reused for this product. Another audience from whom we have had


numerous requests is small commercial entrepreneurs, often new to aquaculture,who are looking for tools to help them explore the financial feasibility of launchingan aquaculture venture. Both of the above groups tend to focus primarily oneconomic analyses, but require some basic understanding and consideration of theunderlying biophysical processes underlying facility operation. Aquaculture educa-tors represent a final audience for POND. Their requirement is for readily accessi-ble tools that students can use in class to enhance their understanding of thebiophysical processes controlling aquaculture ponds, as well as completing specificdesign tasks related to facility management.

From an implementation perspective, the object-based paradigm has been verysuccessful at addressing the software development needs of POND. Although it isa relatively complex program from an implementation perspective, the modularityprovided by OOP has allowed us to manage the complexity to a workable level.Additionally, most of the objects in POND can and have been reused directly inother applications we have developed, resulting in an efficient use and leveraging ofresources for development. The advantages of approaching software developmentfrom an object-oriented perspective are most clearly evident in the enhancementswe have made to the simulation framework as a result of needs that have emergedduring the implementation of POND. These enhancements have automaticallybecome available for other applications developed by our group. For instance, theneed to estimate parameters for POND models (in turn derived from the need touse them for different fish species) resulted in our implementing a generic parameterestimation approach in the simulation framework. This approach has since founduse in VSS (Virtual Systems Simulator), a generic model development application.Similarly, the need for a method to estimate least-cost fertilizer mixes in PONDprompted the implementation of a linear programming module in the simulationframework that is available for use by other applications. At a more specific level,oriented towards aquaculture applications, refinements in the ‘experts’ shared byPOND and AquaFarm automatically become available to both applications. Fi-nally, we have been able, with relative ease, to extract models from POND andapply them in complex Geographical Information Systems (GIS) to evaluate inlandaquaculture potential over large areas in Latin America (Kapetsky and Nath, 1997)and Africa (Aguilar-Manjarrez and Nath, 1998).

At this point, we are strong advocates of the object paradigm for softwaredevelopment generally, and simulation models specifically. From a work flowperspective, object-oriented application development lends itself very well to teamsof developers, each focusing on their own areas of expertise and interests (mirroredin components of the application that they are responsible for) with minimaloverlap of duties. C+ + has proven to be a very capable and manageablelanguage for these efforts and comes with very robust development environments.We are considering the use of Java for future efforts to assist in cross-platformissues and Web-based implementations, but at this point in time, Java developmentenvironments are primitive compared to their C+ + competitors, and executionspeed continues to be an issue. The current trend towards component-basedtechnology suggests that actual programming languages used in the future may be


less critical than figuring out how to assemble such components into an applicationfocused on satisfying a list of user specifications. In any event, regardless of thespecific language used, the representational capabilities of any of the object-basedlanguages are very well matched with the needs of simulation and decision supportsoftware.

POND continues to evolve as the needs of the user base for such software tools,and the aquaculture community itself, evolves. A heightened interest in shrimpproduction is moving us in the direction of developing and utilizing bioenergeticmodels that are adaptable to these species. Advances in software development,algorithms and user interface design continue in computer science at an almostdizzying pace, and we are attempting to take advantage of these where appropriate.The World Wide Web provides both opportunities and challenges for decisionsupport system developers. Ultimately, however, the success of any softwaredevelopment effort depends on how well the product addresses user needs. There isno substitute for getting software out in the hands of users, soliciting theirfeedback, and incorporating this feedback into future design and implementationefforts.

Acknowledgements

Development of POND has been supported by the Pond Dynamics/AquacultureCollaborative Research Support Program (PD/A CRSP). The Pond Dynamics/Aquaculture CRSP accession number for this publication is 1198.

References

Aguilar-Manjarrez, J., Nath, S.S., 1998. A strategic reassessment of fish farming potential in Africa.CIFA Technical Paper No. 32. FAO, Rome, 170 pp.

Allen, P.G., Botsford, L.W., Schuur, A.M., Johnston, W.E., 1983. Bioeconomics of Aquaculture.Developments in Aquaculture and Fisheries Science, 13. Elsevier, Amsterdam, p. 351.

Bischak, D.P., 1991. Object-Oriented Simulation. In: Nelson, B.L., Kelton, W.D., Clark, G.M. (Eds.),Proceedings of the 1991 Winter Simulation Conference, pp. 294–303.

Bolte, J.P., 1998. Object-orientated programming for decision making systems. In: Peart, R., Curry, B.(Eds.), Agricultural Systems Modeling. Marcel Dekker Inc, New York, pp. 629–650.

Bolte, J.P., Hannaway, D.B., Shuler, P.E., Ballerstedt, P.J., 1990. An intelligent frame system forcultivar selection. A.I. Appl. Nat. Resour. Manage. 5 (3), 21–31.

Bolte, J.P., Fisher, J.A., Ernst, D.H., 1993. An object-oriented, message-based environment forintegrating continuous, event-driven and knowledge-based simulation. In: Proceedings of the Appli-cation of Advanced Information Technologies: Effective Management of Natural Resources. ASAE.June 18–19, Spokane, WA.

Boyd, C.E., 1979. Water quality in warmwater fish ponds. Agricultural Experiment Station, AuburnUniversity, AL, p. 359.

Budd, T., 1991. An Introduction to Object-Oriented Programming. Addison-Wesley, Reading, MA.Canpolat, N., Bolte, J.P., 1993. Object-orientated implementation of the CERES-Wheat models. ASAE

paper 934052. ASAE, St. Joseph, MI, USA.


Chambers, R., Pacey, A., Thrupp, L.A., 1989. Farmer First: Farmer Innovation and AgriculturalResearch. Intermediate Technical Publications, London, p. 218.

Colt, J., 1986. Pond culture practices. In: Lannan, J.E., Smitherman, R.O., Tchobanoglous, G. (Eds.),Principles and Practices of Pond Aquaculture: A State of the Art Review. Pond Dynamics/Aquacul-ture CRSP, Oregon State University, Corvallis, OR, pp. 187–197.

Ege, R.K., 1992. Programming in an Object-Oriented Environment. Academic Press, San Diego, CA.El-Gayar, O., Leung, P., 1996. An aquacultural development decision support system (ADDSS): A

prototype system with application in Egypt. Paper presented at the 1996 Annual Meeting of theWorld Aquaculture Society, Bangkok, Thailand.

Ernst, D.H., Bolte, J.P., Nath, S.S., 1993. A decision support system for finfish aquaculture. In: Wang,J.-K. (Ed.), Techniques for Modern Aquaculture Symposium: Proceedings of an AquaculturalEngineering Conference, 21–23 June 1993, Spokane, WA. ASAE, St Joseph, MI, pp. 568–580.

Ernst, D.H., Bolte, J.P., Lowes, D., Nath, S.S., 1997. PD/A CRSP Central Database: A StandardizedInformation Resource for Pond Aquaculture. In: Proceedings of the ISTA IV Conference, Orlando,FL, Nov. 1977.

Ernst, D.H., Bolte, J.P., Nath, S.S., 2000. AquaFarm: Software for Aquaculture Planning and Design.Aquacult. Eng., this issue.

Ferris, I.G., Frecker, T.C., Haigh, B.M., Durrant, S., 1992. HERBICIDE ADVISER: a decision supportsystem to optimise atrazine and chlorsulfuron activity and crop safety. Comput. Electron. Agric. 6,295–317.

Folse, L.J., Meuller, H.E., Whittaker, A.D., 1990. Object-oriented simulation and geographic informa-tion systems. AI Appl. 4 (2), 41–47.

Gempesaw, C.M., Wirth, F.F., Bacon, J.R., 1992. A financial analysis of integration in aquacultureproduction: the case of hybrid striped bass. Aquaculture 104, 193–215.

Harrison, E., 1994. Aquaculture in Africa: Socio-economic dimensions. In: Muir, J.F., Roberts, R.J.(Eds.), Recent Advances in Aquaculture. Blackwell, Oxford, pp. 240–299.

Hepher, B., 1988. Nutrition of Pond Fishes. Cambridge University Press, Cambridge, MA, p. 388.Hickling, C.F., 1962. Fish Culture. Faber and Faber, London, p. 295.Hopgood, A.A., 1991. Knowledge-based Systems for Engineers and Scientists. CRC Press, Boca Raton,

FL, p. 387.Itoga, S.Y., Brock, J.A., 1995. Hawaii Aquaculture Module Expert System for Windows. Publication

No. 118. Center for Tropical and Sub-Tropical Aquaculture, Waimanalo, HI, p. 18.Kapetsky, J.M., Nath, S.S., 1997. A strategic assessment of the potential for freshwater fish farming in

Latin America. COPESCAL Technical Paper No 10. FAO, Rome, p. 128.King, D.L., Garling, D.L., 1983. A state of the art overview of aquatic fertility with specific reference

to control exerted by chemical and physical factors. In: Lannan, J.E., Smitherman, R.O.,Tchobanoglous, G. (Eds.), Principles and Practices of Pond Aquaculture: A State of the Art Review.Pond Dynamics/Aquaculture CRSP, Oregon State University, Corvallis, OR, pp. 67–76.

Lannan, J.E., 1993. Users guide to PONDCLASS: Guidelines for fertilizing aquaculture ponds. PD/ACRSP, Oregon State University, Corvallis, OR, p. 60.

Lodge, G.M., Frecker, T.C., 1989. LUCVAR: a computer-based consultation system for selectinglucerne (alfalfa) varieties. J. Expert Syst. 6, 166–178.

Meyer, B., 1988. Object-oriented Software Construction. Prentice-Hall, Englewood Cliffs, NJ, p. 534.Michalski, R.S., Davis, J.H., Bisht, V.S., Sinclair, J.B., 1982. PLANT/DS: an expert consulting system

for the diagnosis of soybean diseases. In: Proceedings of the 1982 European Conference on ArtificialIntelligence, Orsay, France, July 12–14, 1982, pp. 133–138.

Molnar, J.J., Hanson, T.R., Lovshin, L.L., 1996. Social, economic and institutional impacts ofaquacultural research on tilapia: The PD/A CRSP in Rwanda, Honduras, the Philippines, andThailand. Research and Development Series No. 40. International Center for Aquaculture andAquatic Environments, Alabama Experimental Station, Auburn University, AL, p. 72.

Nath, S.S., 1996. Development of a Decision Support System for Pond Aquaculture. Ph.D. Thesis,Bioresource Engineering Department, Oregon State University.

Pedini, P., Coppola, S.R., Moretti, A., 1995. The Aquaculture Planning Simulator. Unpublished Report,Food and Agricultural Organization of the UN, Inland Water Resources and Aquaculture Service,Rome, Italy, 18 pp.


Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., 1991. Object Oriented Modeling andDesign. Prentice-Hall, Englewood Cliffs, NJ.

Sequeria, R.A., Sharpe, P.J.H., Stone, N.D., El-Zik, K.M., Makela, M.E., 1991. Object-orientedsimulation: plant growth and discrete organ to organ interactions. Ecol. Modeling 58, 55–89.

Shang, Y., 1981. Aquaculture Economics: Basic Concepts and Methods of Analysis. Westview Press,Boulder, CO, p. 153.

Sierra, J.M., Pulido, J.A., 1991. Doing object oriented simulations: advantages, new development tools.In: The 24th Annual Simulation Symposium Records of Proceedings, New Orleans, LA, April 1–5,1991, pp. 177–184.

Silvert, W., 1994. A decision support system for regulating finfish aquaculture. Ecol. Modelling 76,609–615.

Smith, R.D., Barrett, J.R., Peart, R.M., 1985. Crop Production Management with Expert Systems.ASAE Paper No. 85-5521. ASAE, St Joseph, MI.

Uhrig, J.W., Thieme, R.H., Peart, R.M., 1986. Grain marketing alternative selection: an expert systemapproach. Paper presented at the AAEA Symposium: Innovative Extension Delivery Systems:Satellites, Expert Systems and Artificial Intelligence, Reno, NV, July 29, 1986.

Van Evert, F.K., Campell, G.S., 1994. CropSyst: A collection of object-oriented simulation models ofagricultural systems. Agron. J. 86, 325–331.

Whittaker, A.D., Wolfe, M.L., Godbole, R., Alem, G.J.V., 1991. Object-oriented modeling of hydro-logic process. AI Appl. 5 (4), 49–58.

Wilde, N., Mathews, P., Hutt, R.H., 1993. Maintaining object-oriented software. IEEE Software,January 1993, pp. 75–79.

Zeigler, B.P., 1990. Object-Oriented Simulations with Hierarchical, Modular Models. Academic Press,New York.

.

Development of decision support tools for aquaculture: …directory.umm.ac.id/Data...

Documents

Transcript of Development of decision support tools for aquaculture: …directory.umm.ac.id/Data...