- Email: [email protected]
A framework for developing optimization-based decision support systems
Expert Systems with Applications 36 (2009) 4581–4588
Contents lists available at ScienceDirect
Expert Systems with Applications journal homepage: www.elsevier.com/locate/eswa
A framework for developing optimization-based decision support systems Juan R. González *, David A. Pelta, Antonio D. Masegosa Departamento de Ciencias de la Computación e Inteligencia Artificial, ETS Ingenierı´as Informática y de Telecomunicación, Universidad de Granada, E-18071 Granada, Spain
a r t i c l e
i n f o
Keywords: Optimization-based decision support systems Framework Solvers management Algorithms
a b s t r a c t Optimization-based decision support systems (DSSs) are an interesting and important area among the many classes of decision support systems. This paper presents SiGMA, a generic core to build Optimization-based DSSs that tries to be as generic as possible on the on-line addition and use of solvers while preserving the maximum functionality on the Analysis stage that this criterion allows. SiGMA serves as a framework to build more complex DSSs where problem specific knowledge can be used to improve the functionality available at the Formulation and Analysis stages. Two application examples from different domains are also presented: SiGMAPhub and SiGMAProt. These applications include additional analysis capabilities for the p-hub and the protein structure comparison problems, respectively. Ó 2008 Elsevier Ltd. All rights reserved.
1. Introduction Since the early 1970s, decision support systems (DSSs) have evolved sustantially and many new techniques like data warehouses, OLAP, data mining and web technologies have been incorporated onto the DSS design. DSS is a technology rich field and different people perceive it and its history from various points of view, with different notions of what happened and what was important (Arnott & Pervan, 2005; McCosh & Correa-Pérez, 2006; Power, 2004, 2007). Among the many classes of DSSs, this paper concentrates on a particularly interesting and important area: optimization-based decision support systems. As can be read on (Shim et al., 2002), optimization-based decision support can be divided into three stages: Formulation, Solution and Analysis. The Formulation stage deals with the generation of a model in a form that is acceptable by a model solver, the Solution stage refers to the algorithmic solution of the model (by a solver) and the Analysis stage refers to the analysis and interpretation of a solution or a set of solutions. When we are dealing with different problems or sometimes even with a single problem, several different models can exists and every researcher/developer can choose to write his own algorithms (solvers) on many different programming languages, with many different parameters and possibly expecting different formats for the inputs. Due to these reasons a given solver will not necessarily be able to plug into a specific optimization-based DSS for the problem it solves. Thus the decisor (researcher) is forced
* Corresponding author. Fax: +34 958 243317. E-mail addresses: [email protected] (J.R. González), [email protected] (D.A. Pelta), [email protected] (A.D. Masegosa). 0957-4174/$ - see front matter Ó 2008 Elsevier Ltd. All rights reserved. doi:10.1016/j.eswa.2008.05.013
to either ignore such ‘‘non-compliant” solvers or to handle them outside of the DSS with the annoyances it implies. While some effort has been put on the model-solver integration and data independence (Luan et al., 1990; Lee & Huh, 2003, 2006), there are several important limitations even in the most recent proposals (Lee & Huh, 2006) such as having to manually register and manage interfacing rules or having to resolve structural conflicts between models and solvers by writing conversion scripts that transform data. These limitations difficult the maintenance and utilization of such systems by not experts and they also imply a considerable amount of time and effort when a new model or solver needs to be added. Given these drawbacks, it would be necessary for a system of this kind to have the following characteristics and functionality: To facilitate the incorporation of pre-existing solvers without having to reimplement them on any specific language. This is needed because the users of the DSS may not be willing to do that or they may not have the knowledge nor the time. To collect and make available to the user any results provided by the solvers in an easy and systematic way. To allow the addition, modification and deletion of solvers in a dynamic way, including the dynamic generation of the graphical user interfaces needed to execute the solvers and analyze their results. To not require the recompilation of solvers or the DSS during the normal work with the system, including the tasks related with the previous characteristics. To provide a database of solvers that allows to reutilize or modify them at any time, so it allows the user to forget the specific details of the solvers configuration and parameters and concentrate on their actual use and the analysis of their results.
4582
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
It should be based on well established open-source tools and languages so the DSS itself can be easily extended and also be easily portable to different platforms. It should be runnable on all major computers and operating systems, so it not imposes a restriction on the working environment of the decisor and circumvents the problem of using solvers that are fixed to a platform by allowing to run the DSS there. The purpose of this paper is to develop and to made available to the researchers a generic and dynamically extensible optimizationbased DSS with the ability to cope with the previous list of desiderata. This tool is essentially a Framework for developing Optimization-based Decision Support Systems called SiGMA and in order to show SiGMA, its main features and how it can be used as the basis for a DSS on a specific problem, we have organized this paper as follows: Section 2 presents an initial description of SiGMA; Section 3 focuses on the description of the three main parts of the tool and how to use them; Section 4 shows the application of SiGMA to build initial DSS prototypes for the p-hub and the protein structure comparison problems; finally, some concluding remarks and ideas are presented in Section 5.
2. Description, requirements and design of SiGMA As stated before, an optimization-based decision support systems can be divided into three stages: Formulation, Solution and Analysis. The Formulation stage deals with the generation of a model in a form that is acceptable by a model solver, the Solution stage refers to the algorithmic solution of the model (by a solver) and the Analysis stage refers to the analysis and interpretation of a solution or a set of solutions. SiGMA is a framework to build optimization-based DSSs that focuses on the Solution stage by providing a powerful and dynamic manager for algorithmic solvers facilitating its management, comparison and analysis of their results whatever problem or model they are designed to solve and whatever input format they expect. SiGMA tries to meet all the desiderable characteristics for this kind of system, as detailed in the introduction. To achieve these goals SiGMA provides the user the ability to add, modify, execute and see the result of any solver with an easy to use graphical user interface and without having to write a single line of code. Once a solver is fully specified by the user, SiGMA is able to generate the appropriate form-like interfaces to execute them and collects their output making it easily available and analyzable. It is important to say that for the purpose of this paper a solver will be referring to an algorithm or more precisely an implementation of an algorithm and both terms are going to be used interchangeably. Many situations can greatly benefit for a system like SiGMA. Two examples are: (1) A decisor who wants to incorporate many solvers for the problem that he is working on. For example, a broker working on the stock market may benefit of any new program algorithm that analyzes the stock movements and suggest sell or buy operations. Then he can analyze and aggregate/ combine the results of different solvers and use his own expertise to make the final decisions about the actions to take. SiGMA can fit perfectly on this scenario by easing the fast inclusion and execution of this new solvers. (2) When a researcher develops a new algorithm (solver for a specific problem), he wants to be able to compare it against all the existing algorithms over the same problem on the literature, or at least the best ones. This will allow the researcher to know what the weak and strong points of his
new algorithm are, and the advantages or disadvantages of using one algorithm over the other. SiGMA fits specially well on this scenario, allowing to easily add and manage all the solvers to be compared onto the system. The solvers that are available to the user can be as full source code or just as a binary executable files. While there exists the possibility to alter the source code of those algorithms when it is available, the binary executable files can not be modified, thus forcing requirements on this area would imply the impossibility to use them. Also, when it is available, the code for the algorithms can be very complex or difficult to modify, or it could require the researcher to develop skills on new languages he does not really need for any other purpose. Taking all of this into consideration, it is clear that integrating arbitrary solvers on a DSS is not a simple task, and ideally the user that works with the DSS should not have to know about its internals to be able to add a new solver to the system. Therefore, the first decision taken to make SiGMA as generic as possible has been to work with the binary executable files directly, thus removing the need for modifications to source code files. More precisely SiGMA will work with any binary executable file that receives its parameters on the command line and produces its output as either files or as lines written to its standard output. In this way, the time and effort needed to add a new solver to SiGMA will be just the time for the specification of where its executable is, what parameters it receives and what datatypes they have plus optional additional metadata like a solver description. SiGMA will provide the appropriate graphical user interface (GUI) to accomplish these tasks. Since there are no requirements or restrictions on the format of the standard output nor on the files a solver produces it is not possible to provide a complex Analysis stage on SiGMA. So SiGMA will just provide a basic analysis of the results and more advanced result analysis may be included only when working on a specific problem by adding the extra functionality on top of the framework. 2.1. Technical details To be able to meet all the above requirements SiGMA has been developed on top of Java technologies (Gosling & McGilton, 1996). Java is a well-known and widely accepted language made by Sun Microsystems. The Java source code is compiled to a binary representation that can be run on a Java Virtual Machine (JVM). Since a JVM hides all the underlying specific architecture of the machine, a Java program can be run without modifications on any architecture and operating system that has an appropriate JVM available. Thanks to its great diffusion and that the source code of the JVM, java compiler and associated tools have been made available as open source, a lot of JVMs already exists and it is possible to modify and compile the code for any other architecture if it were needed. Particularly, good and perfectly working JVMs exists for the main machines and operating systems, that’s to say Microsoft Windows, most Unix and Linux flavours and Mac OS. Although the JVM is a good abstraction of the underlying hardware and operating system, not all the tasks are performed exactly in the same way in every OS. For example, the actual execution of programs, and opening a file with its associated program are in some aspects specific operations of the platform where it is run. Nevertheless, the amount of changes needed to adapt this tasks to a different OS is not too big, and SiGMA has been prepared to work well at least on some of the newer versions of the three major OSes. Tests have been done showing SiGMA to work correctly at least on Microsoft Windows XP, Kubuntu Linux 7.04 and Apple Mac OS X 10.4.
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
For storing the data manipulated by SiGMA, the decision was to just rely on the filesystem to store solver specification files and results. The solver files are going to be stored as xml files using the Java Beans XMLEncoder and XMLDecoder classes and the whole database of solvers will just be the serialization of a list class containing them. This is extremely simple but also extremely powerfull allowing for example to easily share solver definitions among SiGMA instances by just copying its XML definition files in the appropriate place. Results of solvers are also going to be files or standard output streams, that are also stored directly in the filesystem. All of this allowed us to build a multi-platform, multi-language tool that dynamically generates the user interface for the manipulation of the solvers by means of Java Swing components (Eckel, 2006) and which only requisite is to have a JVM installed. An user that wants to use SiGMA just needs to execute the distribution JAR file and configure the appropriate binaries of the algorithms he wants to use as solvers using the SiGMA interface for this purpose. Once this is done, solvers can be easily executed and their results can be inspected as it will be shown in the next sections. 3. Working with SiGMA SiGMA, as it is shown in Fig. 1, is composed of a menu bar and a panel with three tabs, namely: (1) the Solver administration tab, that lets the user add, edit an delete solvers (algorithms); (2) the Solver execution tab, where the current parameters of every selected solver are to be set, and then the algorithms can be launched; and (3) the Result analysis tab, where the collected outputs of the executed solvers can be seen. All the files generated by the execution of SiGMA are created or stored on the SiGMA subdirectory of the appropriate user home directory. This directory is operating system dependent so if sigmauser is the account name for the user working with SiGMA, the associated home directory could be: C:nDocuments and settingsnsigmausern if the user is working on Microsoft Windows XP;/home/sigmauser/, if the user is working on almost any distri-
4583
bution of Unix/Linux; or/Users/sigmauser/, if the user works on Mac OS X. SiGMA just creates a subdirectory SiGMA on the appropiate path into the user home directory and uses it for all its data. Currently this means two main things are stored there: the solvers and the results of the execution of the solvers. All solvers are stored directly under the solvers subdirectory. On the other hand results are stored under subfolders of the results subdirectory. Results in SiGMA are grouped as sessions and tasks. A session is simply a common name for a group of tasks while a task its associated to the execution of a specific solver. SiGMA creates subfolders for every session under its results subdirectory and also every task is stored under its own subfolder of the associated session folder (more details on the names of this folders and the contents of each task directory are presented while describing the execution of solvers on Section 3.2). This directory tree structure is very convenient for backing up all the solvers and experiments data because just a single directory tree needs to be preserved. Solvers and results can also be easily shared between users or different SiGMA installations by just copying the files or directories to the target installation, keeping the same directory structure. SiGMA is prepared to test for the presence of new solvers on invocation and it automatically adds them to the solver base. Also, once we have the results for any given solver, it can be viewed on any other SiGMA installation, even if the new installation does not have the solvers used for their creation, as they are not needed on the analysis phase. Now, we will describe each tab of SiGMA with more detail. 3.1. Solver administration The Solver administration tab lets the user add, edit an delete solvers (algorithms). This tab is divided vertically into two parts. The left part contains a solver description, a list of solvers and three buttons (Add, Edit and Delete solver). A click on the ‘‘Add solver” button, loads a new tab inside the right part of the Solver Administration tab that allows the addition of the new solver as shown in Fig. 2.
Fig. 1. SiGMA’s main window.
4584
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
Fig. 2. SiGMA’s Solver administration tab: addition of a solver.
All solvers need a solver name, a solver description and the solver executable that are specified in the first three fields under the ‘‘Add field” button. Then, the formal parameters should be specified. To do that, there is a drop-down list to select a field type of the parameter to add. Below the drop-down list there appear the type-dependent fields to specify the parameter, and an ‘‘Add field” button that allows the user to add that field to the solver. In Fig. 2 three fields have been already added to the solver and they are shown under the ‘‘Parameters” label: a seed, and integer parameter ‘‘integerPar12” with a default value of 12 and a float parameter ‘‘floatfield124” with default value 1,24. Parameter checking is done by ensuring that every parameter has correct values for their type, discarding or correcting wrong input and also displays the values in the correct format for the user language/regional settings. The type of parameters available are INTEGER and FLOAT, that are defined by a name and a default value, STRING, that is defined by a name, a default value and a maximum length; and RANDOM_INTEGER_SEED, FILE and FILE_OF_VALUES that are defined by just a name. Once the required data is obtained, the new solver can be added to the database of solvers by pressing the ‘‘Save solver” button. It is important to notice that while a FILE parameter is just a file that the algorithm receives as part of the input, the FILE_OF_VALUES has a different meaning. Instead of using the path to the file as a parameter for the algorithm, this file is read line by SiGMA itself when the algorithm is going to be executed and for every value (line) read an execution is made with that value as the parameter. 3.2. Solver execution The Solver execution tab allows to execute the solvers, either immediately or by queueing it on a list of tasks that can be processed later. The tab is divided into two parts. The left one contains a list of the available solvers, a solver description panel (associated to the selected solver), a list of queued tasks and three buttons to manip-
ulate the list of tasks (Delete task, Delete all tasks, and Launch session). To execute a solver, we need to open it from the list of solvers available (just a double-click on its name) and a new dynamically generated tab will open in the right part of the Solver Execution tab. In this new form-like tab, we need to set up the parameters of the solver and then press the Execute button to run it immediately or the Enqueue button to add it to the task list to execute it later. Fig. 3 shows and example of the execution of a solver for the p-hub problem. As it was said, an algorithm may be executed ‘‘right now” (pressing the ‘‘Execute” button) or may be enqueued for later execution (the ‘‘Enqueue” button). In the last case, the list of enqueued task may be manipulated to delete a specific task or all of them, or to launch the stored tasks as a new session. Once a solver or a series of saved tasks is executed, SiGMA invokes the appropriate executables for the solvers with the given parameters on a generated output directory. For every task, the path of its output directory relative to the main SiGMA data directory has the form results/session-dir/task-dir. Session directory names are created with the pattern session-FULLDATE, where FULLDATE is the current date on the time of its creation. Task directory names on the other hand have the form SOLVERNAME-SHORTDATE, where SOLVERNAME is the name of the solver associated with the task and SHORTDATE is the date the task was run. Both FULLDATE and SHORTDATE are numeric representations of the date in the form MonthDayHourMinuteSecond with the only difference being that FULLDATE also includes the year at the beginning. Since a task can also have multiple runs, and even more different parameter configurations (when FILE_OF_VALUES parameters are used), every task represents also a bunch of single executions. Every single execution is stored on a subfolder of the associated task with a name of the form ParsN-runM. When a FILE_OF_VALUES parameter is used the solver will be executed with more than one combination of parameter values, the value of N in the subfolder is a number associated to each of these combinations. Also, for every parameter
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
4585
Fig. 3. SiGMA’s Solver execution tab: executing an algorithm.
Fig. 4. SiGMA’s result analysis tab: viewing the results of an execution.
combination several runs are done, the number of each run is the value included as M in the subfolder name. 3.3. Results analysis The Result analysis tab is where solver execution results are presented. This tab is also divided in two vertical zones. The left part shows a tree of the full SiGMA results directory with all the entries for the sessions, tasks and individual runs.
When the user double-clicks an individual run, the right part of the window loads a new tab with a list of the result files the solver generated and shows the standard output it produced, which is also saved in a text file. All the result files are followed by two buttons ‘‘Open file. . .” and ‘‘Open folder. . .”, the first one opens the file with the associated application for its extension while the second one opens the folder containing the file. Fig. 4 shows an example of viewing results in SiGMA for a particular algorithm.
4586
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
Fig. 5. SiGMAPhub graphical output example.
It is also possible to refresh the tree of results by pressing the ‘‘Refresh results” button or to delete any part of the results by selecting it on the tree and then pressing the ‘‘Delete results branch” button. 4. Application examples When one has specific knowledge of the problem being solved or the output that the solvers produce, it is usually desiderable to have a more complex manipulation, analysis or visualization of the results. SiGMAs design allows the construction of this kind of more complete optimization-based DSSs. Tailoring the framework for a specific problem is doable by just extending the Java classes of SiGMA to add the appropriate advanced problem-specific and solution-specific modules while reusing all the remaining necessary functionality from the generic implementation. This section shows two applications of the SiGMA framework to the construction of more complex DSSs for two different problems of different domains: a facility location problem (the p-hub) and the protein structure comparison problems. They are presented on Sections 4.1 and 4.2, respectively. 4.1. Facility location problem: the p-hub model The problem of locating interacting hub facilities arises in designing telecommunications networks, airline passenger networks, and postal delivery networks (Ernst & Krishnamoorthy, 1996). The problem arises in instances where traffic between nodes on a network has to be routed via a set of nodes, designated as hubs. The hubs, which are fully interconnected, facilitate easy flow of traffic. The non-hub nodes are connected to hub nodes. The hubs serve as trans-shipment points or switching points for flows between non-hub nodes. Non-negative flows are associated with each origin-destination (O-D) pair of nodes in the network. Between any two nodes there is a ‘‘cost” based on factors such as time, money and/or distance for routing flow between these nodes. These flows are generally routed via one or (at most) two hubs. The resulting network has a hub-and-spoke structure. The problem is
to find the optimal hub locations and the non-hub to hub allocations (the spokes). This section focuses on the construction of an optimizationbased DSS for the Uncapacitated Single Allocation p-Hub Median (Campbell, 1994; Ernst & Krishnamoorthy, 1996; O’Kelly, 1987) on top of the SiGMA framework and using different versions of algorithms like Simulated Annealing, Tabu Search or Variable Neighborhood Search. This system will be called SiGMAPhub and, in addition to the generic SiGMA functionality, the goal was to improve its Analysis stage capabilities by adding a simple graphical visualization of the results of the solvers that shows the hubs that were selected and how the remaining nodes are assigned to them. This graphical output was added by making the standard tabs for the display of results on the SiGMA result analysis section to be further subdivided in an additional two-tabs pane. The first of this two tabs just contains the standard SiGMA tab while the other one contains the graphical display. An example is shown on Fig. 5. The changes needed in SiGMA to add this additional graphical output capability are very small thanks to its design. In fact, only four steps were needed: (1) Create a new SiGMAPhub window that extended the original SiGMA window, displaying SiGMAPhub instead of SiGMA where neccesary. (2) Rename the last part of SiGMAPhub work directory to be SiGMAPhub. (3) Create a visualizer for displaying p-hub problem results (with the help of the open source library JFreeChart). (4) Finally, the viewer was instructed to load the appropriate .phub file from the directory with the solver’s execution results in the appropriate graphical output tab of the results that is open when clicking on a result name on the tree of results.
4.2. Protein structure comparison problem The protein structure comparison field is an example where there are both more than one model available and several heuris-
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
4587
Fig. 6. SiGMAProt graphical output through Jmol.
tics for each of them. The available strategies for solving the problem include the use of dynamic programming, comparisons of distance matrices, graph theory, geometrical hashing, principle component correlation analysis, local and global alignment, consensus shapes, consensus structures, Kolmogorov complexity, Contact Map Overlap, Fuzzy Contact Map Overlap, and comparing proteins as paths in 3D. See for example Bourne and Weissig (2003), González and Pelta (2007), Krasnogor and Pelta (2004), Pelta et al. (2005), González, Pelta, and Moreno-Vega (2005) for relevant references on the topic. SiGMA framework was also used to build an optimization-based DSS for the protein structure comparison problem called SiGMAProt. SiGMAProt achieves a very similar goal than SiGMAPhub by adding advanced displaying of the results with the help of Jmol (http://www.jmol.org). The process for adding this functionality was similar to the process explained in the SiGMAPhub case (Section 4.1) and an example of the result obtained is presented on Fig. 6. 5. Concluding remarks This paper has presented a Framework for developing Optimization-based DSSs called SiGMA that focuses on the dynamic management, execution and analysis of the results of the solvers. We have shown how in its generic form SiGMA can fulfill all the desired functionality for this kind of systems that was specified on the introduction. In this manner SiGMA is a valuable tool for working with any kind of solvers (algorithms) in a problem/model independent way. It has also been shown how SiGMA can be easily used to build more complex optimization-based DSSs that provide more advanced functionality when problem-specific knowledge is available. Our daily research on the p-hub and protein structure comparison problems can be used as an example of the benefits obtained by using SiGMA. SiGMAPhub and SiGMAProt have become essential tools on our research and they have been proven to be profitable from several points of view. One of them is to help us in keeping the different algorithms available for each problem in a
database of solvers so we can forget about the specific details of their invocation or the order of their parameters as they are conveniently managed by SiGMA when it is needed. Also, the possibility to use the same application for the execution and the analysis of the results reduces the time needed to do new experiments and to check the changes of performance of the solvers we develop as we make changes on them. Besides that, SiGMA (as well as SiGMAPhub or SiGMAProt) is not affected by changes to the binary executable files for the solvers, so they can be changed and recompiled as needed without posing any effect or needing any additional work to reuse them using the provided interfaces. Only if the parameters of an algorithm are needed to be changed (very infrequently), the solvers on SiGMA need to be changed accordingly, but SiGMA provides a very simple and fast interface for the edition of solvers, making this step a fast and trivial task. Several extensions are also planned for future versions of SiGMA. Among the possibilities to further improve the system are to provide the option to execute the solvers on remote machines (currently it only executes the algorithm in the same machine SiGMA itself is running) adding this option directly to the main SiGMA core. The problem-specific DSSs can also include more powerfull result analysis functionality such as handling clicks on the result tree not just on the leeves but at higher levels also. For this higher levels, the behaviour could be to show statistics of a whole task/ session, such as best cost, average cost, best algorithm, average times to solutions, and so on. Also most of the modules for statistics like time, or cost probably could be done on such a way that they can be reutilized on different problems by just changing the way they gather their results from the files generated by each problem-specific solver while keeping the graphics generation unchanged. People interested on SiGMA can get a copy of the framework by emailing the authors. Acknowledgements This work is supported by Project HeuriCosc (TIN2005-08404C04-01) from the Spanish Ministry of Education and Science; and
4588
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
Projects MINAS (TIC-00129-JA) and P07-TIC02970 from the Regional Government of Andalusia.
References Arnott, D., & Pervan, G. (2005). A critical analysis of decision support systems research. Journal of Information Technology, 20(2), 67–87http://dx.doi.org/ 10.1057/palgrave.jit.2000035. Bourne, P. E., & Weissig, H. (Eds.). (2003). Structural bioinformatics. Methods of biochemical analysis (Vol. 44). John Wiley & Sons. Campbell, J. F. (1994). Integer programming formulations of discrete hub location problems. European Journal of Operational Research, 72(2), 387–405http:// dx.doi.org/10.1016/0377-2217(94)90318-2. Eckel, B. (2006). Thinking in Java (4th ed.). Prentice Hall PTR. Ernst, A. T., & Krishnamoorthy, M. (1996). Efficient algorithms for the uncapacitated single allocation p-hub median problem. Location Science, 4(3), 139–154http:// dx.doi.org/10.1016/S0966-8349(96)00011-3. González, J. R., & Pelta, D. A. (2007). On using fuzzy contact maps for protein structure comparison. In Proceedings of FUZZ-IEEE 2007, London. González, J. R., Pelta, D. A., & Moreno-Vega, J. M. (2005). Multistart VNS for the Maximum Contact Map Overlap Problem, in: Proc. of 18th MECVNS, Tenerife, Spain. Gosling, J., & McGilton, H. (1996). The Java language environment: A white paper, Technical report, Sun Microsystems, 2550 Garcia Avenue, Mountain View, CA 94043, USA. http://java.sun.com/docs/white/langenv/. Jmol: an open-source java viewer for chemical structures in 3d. http:// www.jmol.org.
Krasnogor, N., & Pelta, D. (2004). Measuring the similarity of protein structures by means of the universal similarity metric. Journal of Bioinformatics, 20(7), 1015–1021. Lee, K.-W., & Huh, S.-Y. (2003). Model-solver integration in decision support systems: a web services approach. In Pre-ICIS SIG-DSS Workshop. Lee, K.-W., & Huh, S.-Y. (2006). A model-solver integration framework for autonomous and intelligent model solution. Decision Support Systems, 42(2), 926–944http://www.sciencedirect.com/science/article/B6V8S-4H3BKST-1/2/ 15d2ac0b3efe2ec82be89b099223e7ad. Luan, P., Ramirez, R., & St. Louis, R. (1990). Expert systems that satisfy model-solverdata independence. In Proceedings of the twenty-third annual hawaii international conference on system sciences (Vol. III), 1990. McCosh, A., & Correa-Pérez, B. (2006). The optimization of what? In Intelligent decision-making support systems. Springerhttp://dx.doi.org/10.1007/1-84628231-4_24. O’Kelly, M. E. (1987). A quadratic integer program for the location of interacting hub facilities. European Journal of Operational Research, 32(3), 393–404http:// dx.doi.org/10.1016/S0377-2217(87)80007-3. Pelta, D. A., Krasnogor, N., Bousoño-Calzón, C., Verdegay, J. L., Hirst, J. D., & Burke, E. K. (2005). A fuzzy sets based generalization of contact maps for the overlap of protein structures. Fuzzy Sets and Systems, 152(1), 103–123. Power, D. J. (2004). Specifying an expanded framework for classifying and describing decision support systems. Communications of the Association for Information Systems, 13, 158–166. Power, D. J. (2007). A brief history of decision support systems, version 4.0, DSSResources.COM, World Wide Web. http://DSSResources.COM/history/ dsshistory.htm. Shim, J. P., Warkentin, M., Courtney, J. F., Power, D. J., Sharda, R., Carlsson, C., et al. (2002). and future of decision support technology. Decision Support Systems, 33(2), 111–126.
Contents lists available at ScienceDirect
Expert Systems with Applications journal homepage: www.elsevier.com/locate/eswa
A framework for developing optimization-based decision support systems Juan R. González *, David A. Pelta, Antonio D. Masegosa Departamento de Ciencias de la Computación e Inteligencia Artificial, ETS Ingenierı´as Informática y de Telecomunicación, Universidad de Granada, E-18071 Granada, Spain
a r t i c l e
i n f o
Keywords: Optimization-based decision support systems Framework Solvers management Algorithms
a b s t r a c t Optimization-based decision support systems (DSSs) are an interesting and important area among the many classes of decision support systems. This paper presents SiGMA, a generic core to build Optimization-based DSSs that tries to be as generic as possible on the on-line addition and use of solvers while preserving the maximum functionality on the Analysis stage that this criterion allows. SiGMA serves as a framework to build more complex DSSs where problem specific knowledge can be used to improve the functionality available at the Formulation and Analysis stages. Two application examples from different domains are also presented: SiGMAPhub and SiGMAProt. These applications include additional analysis capabilities for the p-hub and the protein structure comparison problems, respectively. Ó 2008 Elsevier Ltd. All rights reserved.
1. Introduction Since the early 1970s, decision support systems (DSSs) have evolved sustantially and many new techniques like data warehouses, OLAP, data mining and web technologies have been incorporated onto the DSS design. DSS is a technology rich field and different people perceive it and its history from various points of view, with different notions of what happened and what was important (Arnott & Pervan, 2005; McCosh & Correa-Pérez, 2006; Power, 2004, 2007). Among the many classes of DSSs, this paper concentrates on a particularly interesting and important area: optimization-based decision support systems. As can be read on (Shim et al., 2002), optimization-based decision support can be divided into three stages: Formulation, Solution and Analysis. The Formulation stage deals with the generation of a model in a form that is acceptable by a model solver, the Solution stage refers to the algorithmic solution of the model (by a solver) and the Analysis stage refers to the analysis and interpretation of a solution or a set of solutions. When we are dealing with different problems or sometimes even with a single problem, several different models can exists and every researcher/developer can choose to write his own algorithms (solvers) on many different programming languages, with many different parameters and possibly expecting different formats for the inputs. Due to these reasons a given solver will not necessarily be able to plug into a specific optimization-based DSS for the problem it solves. Thus the decisor (researcher) is forced
* Corresponding author. Fax: +34 958 243317. E-mail addresses: [email protected] (J.R. González), [email protected] (D.A. Pelta), [email protected] (A.D. Masegosa). 0957-4174/$ - see front matter Ó 2008 Elsevier Ltd. All rights reserved. doi:10.1016/j.eswa.2008.05.013
to either ignore such ‘‘non-compliant” solvers or to handle them outside of the DSS with the annoyances it implies. While some effort has been put on the model-solver integration and data independence (Luan et al., 1990; Lee & Huh, 2003, 2006), there are several important limitations even in the most recent proposals (Lee & Huh, 2006) such as having to manually register and manage interfacing rules or having to resolve structural conflicts between models and solvers by writing conversion scripts that transform data. These limitations difficult the maintenance and utilization of such systems by not experts and they also imply a considerable amount of time and effort when a new model or solver needs to be added. Given these drawbacks, it would be necessary for a system of this kind to have the following characteristics and functionality: To facilitate the incorporation of pre-existing solvers without having to reimplement them on any specific language. This is needed because the users of the DSS may not be willing to do that or they may not have the knowledge nor the time. To collect and make available to the user any results provided by the solvers in an easy and systematic way. To allow the addition, modification and deletion of solvers in a dynamic way, including the dynamic generation of the graphical user interfaces needed to execute the solvers and analyze their results. To not require the recompilation of solvers or the DSS during the normal work with the system, including the tasks related with the previous characteristics. To provide a database of solvers that allows to reutilize or modify them at any time, so it allows the user to forget the specific details of the solvers configuration and parameters and concentrate on their actual use and the analysis of their results.
4582
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
It should be based on well established open-source tools and languages so the DSS itself can be easily extended and also be easily portable to different platforms. It should be runnable on all major computers and operating systems, so it not imposes a restriction on the working environment of the decisor and circumvents the problem of using solvers that are fixed to a platform by allowing to run the DSS there. The purpose of this paper is to develop and to made available to the researchers a generic and dynamically extensible optimizationbased DSS with the ability to cope with the previous list of desiderata. This tool is essentially a Framework for developing Optimization-based Decision Support Systems called SiGMA and in order to show SiGMA, its main features and how it can be used as the basis for a DSS on a specific problem, we have organized this paper as follows: Section 2 presents an initial description of SiGMA; Section 3 focuses on the description of the three main parts of the tool and how to use them; Section 4 shows the application of SiGMA to build initial DSS prototypes for the p-hub and the protein structure comparison problems; finally, some concluding remarks and ideas are presented in Section 5.
2. Description, requirements and design of SiGMA As stated before, an optimization-based decision support systems can be divided into three stages: Formulation, Solution and Analysis. The Formulation stage deals with the generation of a model in a form that is acceptable by a model solver, the Solution stage refers to the algorithmic solution of the model (by a solver) and the Analysis stage refers to the analysis and interpretation of a solution or a set of solutions. SiGMA is a framework to build optimization-based DSSs that focuses on the Solution stage by providing a powerful and dynamic manager for algorithmic solvers facilitating its management, comparison and analysis of their results whatever problem or model they are designed to solve and whatever input format they expect. SiGMA tries to meet all the desiderable characteristics for this kind of system, as detailed in the introduction. To achieve these goals SiGMA provides the user the ability to add, modify, execute and see the result of any solver with an easy to use graphical user interface and without having to write a single line of code. Once a solver is fully specified by the user, SiGMA is able to generate the appropriate form-like interfaces to execute them and collects their output making it easily available and analyzable. It is important to say that for the purpose of this paper a solver will be referring to an algorithm or more precisely an implementation of an algorithm and both terms are going to be used interchangeably. Many situations can greatly benefit for a system like SiGMA. Two examples are: (1) A decisor who wants to incorporate many solvers for the problem that he is working on. For example, a broker working on the stock market may benefit of any new program algorithm that analyzes the stock movements and suggest sell or buy operations. Then he can analyze and aggregate/ combine the results of different solvers and use his own expertise to make the final decisions about the actions to take. SiGMA can fit perfectly on this scenario by easing the fast inclusion and execution of this new solvers. (2) When a researcher develops a new algorithm (solver for a specific problem), he wants to be able to compare it against all the existing algorithms over the same problem on the literature, or at least the best ones. This will allow the researcher to know what the weak and strong points of his
new algorithm are, and the advantages or disadvantages of using one algorithm over the other. SiGMA fits specially well on this scenario, allowing to easily add and manage all the solvers to be compared onto the system. The solvers that are available to the user can be as full source code or just as a binary executable files. While there exists the possibility to alter the source code of those algorithms when it is available, the binary executable files can not be modified, thus forcing requirements on this area would imply the impossibility to use them. Also, when it is available, the code for the algorithms can be very complex or difficult to modify, or it could require the researcher to develop skills on new languages he does not really need for any other purpose. Taking all of this into consideration, it is clear that integrating arbitrary solvers on a DSS is not a simple task, and ideally the user that works with the DSS should not have to know about its internals to be able to add a new solver to the system. Therefore, the first decision taken to make SiGMA as generic as possible has been to work with the binary executable files directly, thus removing the need for modifications to source code files. More precisely SiGMA will work with any binary executable file that receives its parameters on the command line and produces its output as either files or as lines written to its standard output. In this way, the time and effort needed to add a new solver to SiGMA will be just the time for the specification of where its executable is, what parameters it receives and what datatypes they have plus optional additional metadata like a solver description. SiGMA will provide the appropriate graphical user interface (GUI) to accomplish these tasks. Since there are no requirements or restrictions on the format of the standard output nor on the files a solver produces it is not possible to provide a complex Analysis stage on SiGMA. So SiGMA will just provide a basic analysis of the results and more advanced result analysis may be included only when working on a specific problem by adding the extra functionality on top of the framework. 2.1. Technical details To be able to meet all the above requirements SiGMA has been developed on top of Java technologies (Gosling & McGilton, 1996). Java is a well-known and widely accepted language made by Sun Microsystems. The Java source code is compiled to a binary representation that can be run on a Java Virtual Machine (JVM). Since a JVM hides all the underlying specific architecture of the machine, a Java program can be run without modifications on any architecture and operating system that has an appropriate JVM available. Thanks to its great diffusion and that the source code of the JVM, java compiler and associated tools have been made available as open source, a lot of JVMs already exists and it is possible to modify and compile the code for any other architecture if it were needed. Particularly, good and perfectly working JVMs exists for the main machines and operating systems, that’s to say Microsoft Windows, most Unix and Linux flavours and Mac OS. Although the JVM is a good abstraction of the underlying hardware and operating system, not all the tasks are performed exactly in the same way in every OS. For example, the actual execution of programs, and opening a file with its associated program are in some aspects specific operations of the platform where it is run. Nevertheless, the amount of changes needed to adapt this tasks to a different OS is not too big, and SiGMA has been prepared to work well at least on some of the newer versions of the three major OSes. Tests have been done showing SiGMA to work correctly at least on Microsoft Windows XP, Kubuntu Linux 7.04 and Apple Mac OS X 10.4.
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
For storing the data manipulated by SiGMA, the decision was to just rely on the filesystem to store solver specification files and results. The solver files are going to be stored as xml files using the Java Beans XMLEncoder and XMLDecoder classes and the whole database of solvers will just be the serialization of a list class containing them. This is extremely simple but also extremely powerfull allowing for example to easily share solver definitions among SiGMA instances by just copying its XML definition files in the appropriate place. Results of solvers are also going to be files or standard output streams, that are also stored directly in the filesystem. All of this allowed us to build a multi-platform, multi-language tool that dynamically generates the user interface for the manipulation of the solvers by means of Java Swing components (Eckel, 2006) and which only requisite is to have a JVM installed. An user that wants to use SiGMA just needs to execute the distribution JAR file and configure the appropriate binaries of the algorithms he wants to use as solvers using the SiGMA interface for this purpose. Once this is done, solvers can be easily executed and their results can be inspected as it will be shown in the next sections. 3. Working with SiGMA SiGMA, as it is shown in Fig. 1, is composed of a menu bar and a panel with three tabs, namely: (1) the Solver administration tab, that lets the user add, edit an delete solvers (algorithms); (2) the Solver execution tab, where the current parameters of every selected solver are to be set, and then the algorithms can be launched; and (3) the Result analysis tab, where the collected outputs of the executed solvers can be seen. All the files generated by the execution of SiGMA are created or stored on the SiGMA subdirectory of the appropriate user home directory. This directory is operating system dependent so if sigmauser is the account name for the user working with SiGMA, the associated home directory could be: C:nDocuments and settingsnsigmausern if the user is working on Microsoft Windows XP;/home/sigmauser/, if the user is working on almost any distri-
4583
bution of Unix/Linux; or/Users/sigmauser/, if the user works on Mac OS X. SiGMA just creates a subdirectory SiGMA on the appropiate path into the user home directory and uses it for all its data. Currently this means two main things are stored there: the solvers and the results of the execution of the solvers. All solvers are stored directly under the solvers subdirectory. On the other hand results are stored under subfolders of the results subdirectory. Results in SiGMA are grouped as sessions and tasks. A session is simply a common name for a group of tasks while a task its associated to the execution of a specific solver. SiGMA creates subfolders for every session under its results subdirectory and also every task is stored under its own subfolder of the associated session folder (more details on the names of this folders and the contents of each task directory are presented while describing the execution of solvers on Section 3.2). This directory tree structure is very convenient for backing up all the solvers and experiments data because just a single directory tree needs to be preserved. Solvers and results can also be easily shared between users or different SiGMA installations by just copying the files or directories to the target installation, keeping the same directory structure. SiGMA is prepared to test for the presence of new solvers on invocation and it automatically adds them to the solver base. Also, once we have the results for any given solver, it can be viewed on any other SiGMA installation, even if the new installation does not have the solvers used for their creation, as they are not needed on the analysis phase. Now, we will describe each tab of SiGMA with more detail. 3.1. Solver administration The Solver administration tab lets the user add, edit an delete solvers (algorithms). This tab is divided vertically into two parts. The left part contains a solver description, a list of solvers and three buttons (Add, Edit and Delete solver). A click on the ‘‘Add solver” button, loads a new tab inside the right part of the Solver Administration tab that allows the addition of the new solver as shown in Fig. 2.
Fig. 1. SiGMA’s main window.
4584
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
Fig. 2. SiGMA’s Solver administration tab: addition of a solver.
All solvers need a solver name, a solver description and the solver executable that are specified in the first three fields under the ‘‘Add field” button. Then, the formal parameters should be specified. To do that, there is a drop-down list to select a field type of the parameter to add. Below the drop-down list there appear the type-dependent fields to specify the parameter, and an ‘‘Add field” button that allows the user to add that field to the solver. In Fig. 2 three fields have been already added to the solver and they are shown under the ‘‘Parameters” label: a seed, and integer parameter ‘‘integerPar12” with a default value of 12 and a float parameter ‘‘floatfield124” with default value 1,24. Parameter checking is done by ensuring that every parameter has correct values for their type, discarding or correcting wrong input and also displays the values in the correct format for the user language/regional settings. The type of parameters available are INTEGER and FLOAT, that are defined by a name and a default value, STRING, that is defined by a name, a default value and a maximum length; and RANDOM_INTEGER_SEED, FILE and FILE_OF_VALUES that are defined by just a name. Once the required data is obtained, the new solver can be added to the database of solvers by pressing the ‘‘Save solver” button. It is important to notice that while a FILE parameter is just a file that the algorithm receives as part of the input, the FILE_OF_VALUES has a different meaning. Instead of using the path to the file as a parameter for the algorithm, this file is read line by SiGMA itself when the algorithm is going to be executed and for every value (line) read an execution is made with that value as the parameter. 3.2. Solver execution The Solver execution tab allows to execute the solvers, either immediately or by queueing it on a list of tasks that can be processed later. The tab is divided into two parts. The left one contains a list of the available solvers, a solver description panel (associated to the selected solver), a list of queued tasks and three buttons to manip-
ulate the list of tasks (Delete task, Delete all tasks, and Launch session). To execute a solver, we need to open it from the list of solvers available (just a double-click on its name) and a new dynamically generated tab will open in the right part of the Solver Execution tab. In this new form-like tab, we need to set up the parameters of the solver and then press the Execute button to run it immediately or the Enqueue button to add it to the task list to execute it later. Fig. 3 shows and example of the execution of a solver for the p-hub problem. As it was said, an algorithm may be executed ‘‘right now” (pressing the ‘‘Execute” button) or may be enqueued for later execution (the ‘‘Enqueue” button). In the last case, the list of enqueued task may be manipulated to delete a specific task or all of them, or to launch the stored tasks as a new session. Once a solver or a series of saved tasks is executed, SiGMA invokes the appropriate executables for the solvers with the given parameters on a generated output directory. For every task, the path of its output directory relative to the main SiGMA data directory has the form results/session-dir/task-dir. Session directory names are created with the pattern session-FULLDATE, where FULLDATE is the current date on the time of its creation. Task directory names on the other hand have the form SOLVERNAME-SHORTDATE, where SOLVERNAME is the name of the solver associated with the task and SHORTDATE is the date the task was run. Both FULLDATE and SHORTDATE are numeric representations of the date in the form MonthDayHourMinuteSecond with the only difference being that FULLDATE also includes the year at the beginning. Since a task can also have multiple runs, and even more different parameter configurations (when FILE_OF_VALUES parameters are used), every task represents also a bunch of single executions. Every single execution is stored on a subfolder of the associated task with a name of the form ParsN-runM. When a FILE_OF_VALUES parameter is used the solver will be executed with more than one combination of parameter values, the value of N in the subfolder is a number associated to each of these combinations. Also, for every parameter
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
4585
Fig. 3. SiGMA’s Solver execution tab: executing an algorithm.
Fig. 4. SiGMA’s result analysis tab: viewing the results of an execution.
combination several runs are done, the number of each run is the value included as M in the subfolder name. 3.3. Results analysis The Result analysis tab is where solver execution results are presented. This tab is also divided in two vertical zones. The left part shows a tree of the full SiGMA results directory with all the entries for the sessions, tasks and individual runs.
When the user double-clicks an individual run, the right part of the window loads a new tab with a list of the result files the solver generated and shows the standard output it produced, which is also saved in a text file. All the result files are followed by two buttons ‘‘Open file. . .” and ‘‘Open folder. . .”, the first one opens the file with the associated application for its extension while the second one opens the folder containing the file. Fig. 4 shows an example of viewing results in SiGMA for a particular algorithm.
4586
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
Fig. 5. SiGMAPhub graphical output example.
It is also possible to refresh the tree of results by pressing the ‘‘Refresh results” button or to delete any part of the results by selecting it on the tree and then pressing the ‘‘Delete results branch” button. 4. Application examples When one has specific knowledge of the problem being solved or the output that the solvers produce, it is usually desiderable to have a more complex manipulation, analysis or visualization of the results. SiGMAs design allows the construction of this kind of more complete optimization-based DSSs. Tailoring the framework for a specific problem is doable by just extending the Java classes of SiGMA to add the appropriate advanced problem-specific and solution-specific modules while reusing all the remaining necessary functionality from the generic implementation. This section shows two applications of the SiGMA framework to the construction of more complex DSSs for two different problems of different domains: a facility location problem (the p-hub) and the protein structure comparison problems. They are presented on Sections 4.1 and 4.2, respectively. 4.1. Facility location problem: the p-hub model The problem of locating interacting hub facilities arises in designing telecommunications networks, airline passenger networks, and postal delivery networks (Ernst & Krishnamoorthy, 1996). The problem arises in instances where traffic between nodes on a network has to be routed via a set of nodes, designated as hubs. The hubs, which are fully interconnected, facilitate easy flow of traffic. The non-hub nodes are connected to hub nodes. The hubs serve as trans-shipment points or switching points for flows between non-hub nodes. Non-negative flows are associated with each origin-destination (O-D) pair of nodes in the network. Between any two nodes there is a ‘‘cost” based on factors such as time, money and/or distance for routing flow between these nodes. These flows are generally routed via one or (at most) two hubs. The resulting network has a hub-and-spoke structure. The problem is
to find the optimal hub locations and the non-hub to hub allocations (the spokes). This section focuses on the construction of an optimizationbased DSS for the Uncapacitated Single Allocation p-Hub Median (Campbell, 1994; Ernst & Krishnamoorthy, 1996; O’Kelly, 1987) on top of the SiGMA framework and using different versions of algorithms like Simulated Annealing, Tabu Search or Variable Neighborhood Search. This system will be called SiGMAPhub and, in addition to the generic SiGMA functionality, the goal was to improve its Analysis stage capabilities by adding a simple graphical visualization of the results of the solvers that shows the hubs that were selected and how the remaining nodes are assigned to them. This graphical output was added by making the standard tabs for the display of results on the SiGMA result analysis section to be further subdivided in an additional two-tabs pane. The first of this two tabs just contains the standard SiGMA tab while the other one contains the graphical display. An example is shown on Fig. 5. The changes needed in SiGMA to add this additional graphical output capability are very small thanks to its design. In fact, only four steps were needed: (1) Create a new SiGMAPhub window that extended the original SiGMA window, displaying SiGMAPhub instead of SiGMA where neccesary. (2) Rename the last part of SiGMAPhub work directory to be SiGMAPhub. (3) Create a visualizer for displaying p-hub problem results (with the help of the open source library JFreeChart). (4) Finally, the viewer was instructed to load the appropriate .phub file from the directory with the solver’s execution results in the appropriate graphical output tab of the results that is open when clicking on a result name on the tree of results.
4.2. Protein structure comparison problem The protein structure comparison field is an example where there are both more than one model available and several heuris-
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
4587
Fig. 6. SiGMAProt graphical output through Jmol.
tics for each of them. The available strategies for solving the problem include the use of dynamic programming, comparisons of distance matrices, graph theory, geometrical hashing, principle component correlation analysis, local and global alignment, consensus shapes, consensus structures, Kolmogorov complexity, Contact Map Overlap, Fuzzy Contact Map Overlap, and comparing proteins as paths in 3D. See for example Bourne and Weissig (2003), González and Pelta (2007), Krasnogor and Pelta (2004), Pelta et al. (2005), González, Pelta, and Moreno-Vega (2005) for relevant references on the topic. SiGMA framework was also used to build an optimization-based DSS for the protein structure comparison problem called SiGMAProt. SiGMAProt achieves a very similar goal than SiGMAPhub by adding advanced displaying of the results with the help of Jmol (http://www.jmol.org). The process for adding this functionality was similar to the process explained in the SiGMAPhub case (Section 4.1) and an example of the result obtained is presented on Fig. 6. 5. Concluding remarks This paper has presented a Framework for developing Optimization-based DSSs called SiGMA that focuses on the dynamic management, execution and analysis of the results of the solvers. We have shown how in its generic form SiGMA can fulfill all the desired functionality for this kind of systems that was specified on the introduction. In this manner SiGMA is a valuable tool for working with any kind of solvers (algorithms) in a problem/model independent way. It has also been shown how SiGMA can be easily used to build more complex optimization-based DSSs that provide more advanced functionality when problem-specific knowledge is available. Our daily research on the p-hub and protein structure comparison problems can be used as an example of the benefits obtained by using SiGMA. SiGMAPhub and SiGMAProt have become essential tools on our research and they have been proven to be profitable from several points of view. One of them is to help us in keeping the different algorithms available for each problem in a
database of solvers so we can forget about the specific details of their invocation or the order of their parameters as they are conveniently managed by SiGMA when it is needed. Also, the possibility to use the same application for the execution and the analysis of the results reduces the time needed to do new experiments and to check the changes of performance of the solvers we develop as we make changes on them. Besides that, SiGMA (as well as SiGMAPhub or SiGMAProt) is not affected by changes to the binary executable files for the solvers, so they can be changed and recompiled as needed without posing any effect or needing any additional work to reuse them using the provided interfaces. Only if the parameters of an algorithm are needed to be changed (very infrequently), the solvers on SiGMA need to be changed accordingly, but SiGMA provides a very simple and fast interface for the edition of solvers, making this step a fast and trivial task. Several extensions are also planned for future versions of SiGMA. Among the possibilities to further improve the system are to provide the option to execute the solvers on remote machines (currently it only executes the algorithm in the same machine SiGMA itself is running) adding this option directly to the main SiGMA core. The problem-specific DSSs can also include more powerfull result analysis functionality such as handling clicks on the result tree not just on the leeves but at higher levels also. For this higher levels, the behaviour could be to show statistics of a whole task/ session, such as best cost, average cost, best algorithm, average times to solutions, and so on. Also most of the modules for statistics like time, or cost probably could be done on such a way that they can be reutilized on different problems by just changing the way they gather their results from the files generated by each problem-specific solver while keeping the graphics generation unchanged. People interested on SiGMA can get a copy of the framework by emailing the authors. Acknowledgements This work is supported by Project HeuriCosc (TIN2005-08404C04-01) from the Spanish Ministry of Education and Science; and
4588
J.R. González et al. / Expert Systems with Applications 36 (2009) 4581–4588
Projects MINAS (TIC-00129-JA) and P07-TIC02970 from the Regional Government of Andalusia.
References Arnott, D., & Pervan, G. (2005). A critical analysis of decision support systems research. Journal of Information Technology, 20(2), 67–87http://dx.doi.org/ 10.1057/palgrave.jit.2000035. Bourne, P. E., & Weissig, H. (Eds.). (2003). Structural bioinformatics. Methods of biochemical analysis (Vol. 44). John Wiley & Sons. Campbell, J. F. (1994). Integer programming formulations of discrete hub location problems. European Journal of Operational Research, 72(2), 387–405http:// dx.doi.org/10.1016/0377-2217(94)90318-2. Eckel, B. (2006). Thinking in Java (4th ed.). Prentice Hall PTR. Ernst, A. T., & Krishnamoorthy, M. (1996). Efficient algorithms for the uncapacitated single allocation p-hub median problem. Location Science, 4(3), 139–154http:// dx.doi.org/10.1016/S0966-8349(96)00011-3. González, J. R., & Pelta, D. A. (2007). On using fuzzy contact maps for protein structure comparison. In Proceedings of FUZZ-IEEE 2007, London. González, J. R., Pelta, D. A., & Moreno-Vega, J. M. (2005). Multistart VNS for the Maximum Contact Map Overlap Problem, in: Proc. of 18th MECVNS, Tenerife, Spain. Gosling, J., & McGilton, H. (1996). The Java language environment: A white paper, Technical report, Sun Microsystems, 2550 Garcia Avenue, Mountain View, CA 94043, USA. http://java.sun.com/docs/white/langenv/. Jmol: an open-source java viewer for chemical structures in 3d. http:// www.jmol.org.
Krasnogor, N., & Pelta, D. (2004). Measuring the similarity of protein structures by means of the universal similarity metric. Journal of Bioinformatics, 20(7), 1015–1021. Lee, K.-W., & Huh, S.-Y. (2003). Model-solver integration in decision support systems: a web services approach. In Pre-ICIS SIG-DSS Workshop. Lee, K.-W., & Huh, S.-Y. (2006). A model-solver integration framework for autonomous and intelligent model solution. Decision Support Systems, 42(2), 926–944http://www.sciencedirect.com/science/article/B6V8S-4H3BKST-1/2/ 15d2ac0b3efe2ec82be89b099223e7ad. Luan, P., Ramirez, R., & St. Louis, R. (1990). Expert systems that satisfy model-solverdata independence. In Proceedings of the twenty-third annual hawaii international conference on system sciences (Vol. III), 1990. McCosh, A., & Correa-Pérez, B. (2006). The optimization of what? In Intelligent decision-making support systems. Springerhttp://dx.doi.org/10.1007/1-84628231-4_24. O’Kelly, M. E. (1987). A quadratic integer program for the location of interacting hub facilities. European Journal of Operational Research, 32(3), 393–404http:// dx.doi.org/10.1016/S0377-2217(87)80007-3. Pelta, D. A., Krasnogor, N., Bousoño-Calzón, C., Verdegay, J. L., Hirst, J. D., & Burke, E. K. (2005). A fuzzy sets based generalization of contact maps for the overlap of protein structures. Fuzzy Sets and Systems, 152(1), 103–123. Power, D. J. (2004). Specifying an expanded framework for classifying and describing decision support systems. Communications of the Association for Information Systems, 13, 158–166. Power, D. J. (2007). A brief history of decision support systems, version 4.0, DSSResources.COM, World Wide Web. http://DSSResources.COM/history/ dsshistory.htm. Shim, J. P., Warkentin, M., Courtney, J. F., Power, D. J., Sharda, R., Carlsson, C., et al. (2002). and future of decision support technology. Decision Support Systems, 33(2), 111–126.