Tapia 1990 developed a multiple objective linear programming model for agricultural planning. The model seeks to determine which types of crops to plant,
in what months of the year and in what different ratios for a given farm in order to maximize net total income, to maximize total yield per unit land area, to
maximize land usage, and to minimize production costs. The constraints considered are land constraints, vegetable family constraints indicating that no vegetable types
belonging to the same family can be planted in immediate succession, seasonality constraints as not all vegetables can grow in certain months, and market availabil-
ity constraints which ensure a significant harvest of vegetables belonging to a specific family. The model is solved as a multi-objective mathematical programming
formulation.
Tabucanon 1990 suggested MCDM as a framework for an analytical inquiry into policy issues on food commodities. The main motivation behind his choice lies
in the various criteria inherent in food policy issues as they relate to socio-economic and political goals. Tabucanon overviewed MCDM, its process, techniques and
applications as it relates to food policy analysis.
1
.
2
. Objecti6es The main objective of this work is to design and implement an aquacultural
development decision support system ADDSS that aids the decision maker or the planner in making choices regarding the planning and development of the aquacul-
ture industry in a given region. Given the inherent multiple objective nature of aquaculture planning, and due to the lack of multiple criteria decision-making
MCDM models for regional aquacultural development, it is also the objective of this work to develop such a model. The applicability of the system is then
demonstrated through a case study from Egypt.
2. Methods
2
.
1
. ADDSS system components ADDSS includes three main components: a modeling, a database and a dialog
component as shown in Fig. 1. The arrows in Fig. 1 denote possible interactions, in which the user, through the dialog component, can access the modeling component
for analysis purposes and the database component for data-entryquery. Fur- thermore, the modeling component can interact with the database component for
accessing data and storing results.
2
.
1
.
1
. The dialog component The dialog component provides a user interface to the other two components of
ADDSS: the database component and the modeling component. In ADDSS, the dialog component is a graphical user interface GUI with a pull-down menu
structure that operates under Microsoft’s Windows© environment as shown in Fig.
2. The dialog component takes full advantage of Windows multi-tasking capability as well as the multitude of user interface objects available under Windows.
Multi-tasking is particularly useful as it allows the user to switch between various tasks programs in an easy manner rather than the traditional sequential approach,
thereby mimicking the way people normally think. It should be noted, however,
Fig. 1. ADDSS framework adapted from Sprague and Carlson, 1982.
Fig. 2. The database menu popup.
Fig. 3. The modeling menu popup.
that while multi-tasking capability is available under Windows, its introduction and utilization significantly complicates the design and implementation of the dialog
component. The dialog component is implemented using the screen and menu sub-systems of Microsoft’s FoxPro© development environment together with Fox-
Pro’s programming language.
The two primary menu pads in ADDSS’s user interface are the database and the modeling menu pad. The database menu pad Fig. 2 provides an interface to the
database component while the modeling menu pad Fig. 3 provides an interface to the modeling component which includes model specification, building and running.
2
.
1
.
2
. The database component The database component is composed of a database management system
DBMS and a database containing all relevant data as shown in Fig. 4. The DBMS provides the interface between the database and the other ADDSS compo-
nents. The database, in turn, is a pool of all relevant data pertaining to the policy objectives and the issues involved when planning for regional development for
aquaculture. The database contains region-, species- and feed-specific data as shown in Fig. 4. Region-specific data include climatic conditions, population
statistics and market statistics such as fisheries production, aquaculture production,
other protein sources such as beef and poultry, current protein consumption per capita, projected export demand, etc. Species-specific data include data regarding
the optimum culture environment and the different culture technologies. Feed-spe- cific data include ingredients’ analysis, feed formulas, and manufacturing
technologies.
The relational database structure is designed in a top down fashion independent of the modeling component. Moreover, particular emphasis is given to data
normalization to eliminate data redundancy. In the conceptual database design Fig. 5, each aquaculture growout production system has several production
technologies, e.g. a sea bream monoculture production system can be grown using a semi-intensive or an intensive production technology. Growout production sys-
tems data include the name of the system, while growout production technology data include information on resource requirements such as water, land, capital and
labor.
To allow for polyculture, the simultaneous cultivation of several species, each growout production technology is assumed to grow multiple species. Data included
represent the fry requirements for each species as well as the production per unit area. Other data pertinent to the cultivated species include designated usage, e.g.
whether it is designated for human consumption or not, domestic and export prices, domestic and export market demands, amount of fry available in the wild, etc.
Besides the possible availability of fry in the wild, fry may be produced in captivity using hatchery production technologies. Hatchery production technology
data include information on resource utilization similar to those for the production systems technologies.
Fig. 4. The database component.
Fig. 5. Database conceptual design.
On the other hand, each growout production technology uses more than one feed type, which in turn can be produced by utilizing various levels of technologies using
multiple feed ingredients as inputs. Feed data include import and export prices,
while feed production technology data include details on resource requirements such as labor, land, water, and capital. With multiple feed ingredients used in the
production of a particular feed, feed ingredients data include the feed ingredient requirements for every feed production technology. Other data pertinent to feed
ingredients include the quantities available domestically as well as their import prices. Finally, resource information such as the amounts available domestically of
each resource type is also stored in the database.
Microsoft’s FoxPro DBMS provides all required data management capabilities including commands for adding, deleting, updating, browsing, listing, retrieving,
and sorting records as well as indexing, importing, exporting and creating database files. Moreover, programs operate in a multi-tasking fashion allowing more than
one program to operate concurrently, thereby greatly facilitating the switch from one database to the other. Fig. 6 is a sample data entry screen for the species
database.
2
.
1
.
3
. The modeling component The modeling component is composed of a model base management system
MBMS and a model base containing all relevant models as shown in Fig. 7. The MBMS provides the interface between the model base and the other ADDSS
Fig. 6. Species database.
Fig. 7. The modeling component.
components. The model base is a pool of all relevant models pertaining to the policy objectives and issues involved when planning for regional development for
aquaculture. In this version of ADDSS, the role of the model base management system reduces to the management of the MCDM model and techniques developed,
by providing provisions for model specification, building, and execution Fig. 3.
In aquaculture development, the planners are often confronted with a multitude of policy objectives that they seek to realize through the development of the
region’s aquaculture industry. Examples of such policy objectives include producing human food, improving natural stock, improving the standards of living, and
increasing foreign exchange earnings Pillay, 1977. In realizing such policy objec- tives, the planners have to make decisions regarding the level of activities decision
variables that would strike an acceptable balance among these conflicting policy objectives. Examples of such decision variables include what species to grow, what
technology to use, how much to grow of each species andor technology, etc. Moreover, the planners are constrained by the resources available in the region
such as land, labor, water, etc., as well as other external constraints such as domestic market demand, export market demand, and pollution restraints. The
MCDM model thus seeks to assist the planners in identifying feasible i.e. satisfying resources and external constraints alternatives that balance the multiple policy
objectives encountered when planning for regional aquaculture development.
Several techniques are available for handling MCDM problems Zeleny, 1982; Tabucanon, 1988; Romero and Rehman, 1989. Such techniques vary in their
suitability to handle different decision situations. For example, when the planner faces a situation in which it is desired to optimize a set of objectives, then the
recommended approach can be either multiple objective programming MOP or compromise programming CP depending on the number of objectives considered.
The MOP technique attempts to generate the efficient set, which is a subset of the feasible solutions in which no other feasible solution can achieve the same or better
performance for all policy objectives under consideration and strictly better for at least one objective. It is then left to the planner to choose from such sets. However,
as the number of objectives increases, the size of the efficient set grows exponen- tially thereby overwhelming the planner with a large number of efficient solutions
that render it extremely difficult for the planner to compare, contrast, and finally choose from the set of efficient solutions. MOP is thus recommended only when
two objectives are considered. This not only results in an efficient set of manageable size, but also allows for graphing the efficient solutions in the objective function
space thereby exemplifying the tradeoffs between the objectives under consider- ation. The main purpose of MOP is to establish the set of efficient solutions. This
can be accomplished by several methods which include the constraint method, the weighting method, and the non-inferior set estimation method NISE Romero and
Rehman, 1989. In ADDSS, the weighting method is used to obtain an approxima- tion of the efficient set while the NISE method is used to obtain the exact set.
When the number of objectives is greater than two, CP is recommended. CP searches for a best compromise solution among the efficient solutions and presents
only that solution to the planner, so avoids overwhelming the planner with a large number of efficient solutions to choose from. Given the efficient set, CP seeks the
best compromise solution based on some information regarding the preferences of the planner with respect to the objectives under consideration. CP assumes that any
planner seeks a solution as close as possible to the ideal point vector comprised of the ideal values for all the relevant objectives. The distance function is thus
introduced as a proxy measure for human preferences regarding the closeness to the ideal point Romero and Rehman, 1989.
On the other hand, when the planner faces a situation in which multiple policy objectives exist, i.e. aspiration levels or target values for all relevant policy
objectives are known a priori, then the recommended technique is weighted goal programming WGP. WGP optimizes multiple goals policy objectives simulta-
neously by minimizing the deviations among the desired levels of targets and the actual goal values through the addition of positive and negative deviation variables
permitting either under- or over-achievement of each goal. WGP considers all the goals simultaneously in a composite objective function which minimizes the sum of
all the deviations among the goals from their respective aspiration levels targets. The deviations are weighted according to the relative importance of each goal to
the planner Schniederjans, 1995.
In ADDSS, model specification includes assigning weights and targets to the policy objectives in the model Fig. 8, selecting resources and external constraints
to incorporate in the model, and selecting the decision variables activities to consider when solving the model Figs. 9 and 10. Building the model involves
compiling the model specifications, acquiring the required data from the database, and generating a GAMS© the acronym stands for General Algebraic Modeling
System program file for solving the specified model. Finally, model execution involves selecting the desired MCDM solution technique and activating the GAMS
system with the corresponding program file Fig. 11. A detailed description of the MCDM model and the different MCDM techniques can be found in El-Gayar
1995.
2
.
2
. De6elopment issues and system features Each of ADDSS’s components has its own processing requirements as well as its
own development environment. With regard to the dialog component, a window- based graphical user interface represents the state of the art. As such, the choice of
the development environment should facilitate the design and implementation of such interfaces. Moreover, the flexibility desired from the proposed system requires
easy modifications of the user interface. On the other hand, the database compo- nent requires powerful data management capabilities that are provided by special-
ized commercial data management systems and with less emphasis on processing efficiency. Such capabilities realize desired design features such as flexibility, low
cost and generality. In addition, the modeling component requires the use of either specialized solvers or an implementation language that results in efficient code, due
to the processing requirements involved.
Fig. 8. Weight and target assignments for aquaculture development policy objectives.
Fig. 9. Selection of a set of decision variables.
The challenge thus imposed, is the choice of development tools that meet such requirements and realize the desired design features. The development environment
which satisfies the basic requirements of the dialog and database components is FoxPro© for Windows version 2.6 of Microsoft Inc. — FoxPro© belongs to the
application category known as Relational DataBase Management Systems RDBMS. Likewise, GAMS© is used to develop and implement the MCDM
model and techniques representing the core of ADDSS. GAMS© is designed to facilitate the construction and solution of large and complex mathematical pro-
gramming models.
Special features and characteristics of ADDSS include user friendliness, general- ity, low cost, speed, and flexibility. For ADDSS to be efficiently used, the system
should possess a friendly user interface. This is attained through the use of a window-based graphical user interface. The use of FoxPro© with its powerful
design tools such as the screen generation utility facilitated the design of the user interface as well as any future modification of the interface.
Besides international development agencies, the primary beneficiaries of ADDSS are local governments in developing countries with limited financial and technolog-
ical capabilities. Therefore it is important to reduce the cost of the system by
designing it to operate on an IBM PC and compatible machines instead of specialized expensive workstations, mini-computers or mainframes. Furthermore,
the modular design of the system allows for easy addition of models to the model base, thereby reducing the need for in-house model development and its associ-
ated costs. Moreover, the use of a dedicated database development system with its associated high-level programming language Xbase dialect for system implemen-
tation significantly reduces development times and cost.
Another feature of ADDSS is generality. ADDSS can accommodate various regions by simply incorporating the relevant data and model specification. The
user-friendly interface enables the user to easily enter the relevant data and model specification. Alternatively, the user can utilize FoxPro’s powerful file import and
export capabilities to load the relevant data directly into the system. Other features that are pertinent to the MCDM model include provisions for the choice
of policy objectives, the choice of constraints, the choice of variables to be included in the model, and the choice of an appropriate MCDM technique.
ADDSS modular design also facilitates the modification of the system to accommodate various problems andor situations as well as the inclusion or
Fig. 10. Selection of individual decision variables within a decision variable set.
Fig. 11. Selection of MCDM solution technique.
exclusion of data, models or analysis routines. In effect, the top down design of the database in a fashion independent of the models in the model base, and the use of
a specialized database management system DBMS help realize much of the desired flexibility and in particular, data – model independence. Also, with regard to
the dialog component, the choice of the integrated database development environ- ment facilitates the inclusion and exclusion of modules from the system. For the
modeling component, GAMS© provides a high level language for the compact representation of large and complex models thereby allowing changes to be made in
model specifications simply and accurately. GAMS© also permits model descrip- tions that are independent of solution algorithms.
Finally, ADDSS processing speed is enhanced by the use of a specialized model development system GAMS© and its accompanied solvers. Moreover, the choice
of the development environment allows for the utilization of assembly language and C programming language for model implementation, if necessary, thereby produc-
ing efficient routines.
3. Results and discussion
