Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
Complex Decision Making Processes: their Modelling and Support Angela Liew and David Sundaram Department of Information Systems and Operations Management, University of Auckland, New Zealand
[email protected],
[email protected] Abstract Decision making processes and systems to support the same have focused for the most part on narrow disciplines, paradigms, perspectives, and pre-determined processes. Apart from these most decision processes and systems are designed to solve simple problems and are therefore unable to support complex problems that consist of interrelated decisions that span multiple domains, paradigms, and/or perspectives. To address these problems we propose conceptual decision-making and modelling processes. A flexible object-oriented decision system framework and architecture was developed and implemented to support the proposed processes. Some of the key concepts that we have been able to explore and implement are generic modelling ideas, such as data-model, model-solver, model-model, solver-visualisation, and data-visualisation independences. Specifically we have been able to explore the integration of models of different types, levels of complexity, depths of integration (aggregation, pipelining, and splicing) and orientations (satisficing as well as optimising).
1. Introduction Decision making is undeniably an essential and vital part of the human life. Every decision has a different level of influence or impact in the human life. In order to come up with the best choices, it may be necessary to go through the decision making process repeatedly until an optimal, a near-optimal, or a satisficing solution is obtained. Hence, a decision-making process may not be structured in a strictly orderly manner. Very often, numerous smaller decisions have to be made before a complex decision can eventually arrive at its best conclusion. Moreover, each decision may directly or indirectly have a bearing on other subsequent decisions. The complexity of such decision-making calls for the use of models. Models are abstractions of the problem and its interaction under consideration [9, 15]. Models can also
be actual model instances of the abstraction schema [18]. They can also be executable computer program modules that are used to generate model solutions [18] while with the intention of providing insights rather than numbers [14]. It is important to note that a model is said to be useful only if it is represented in some medium, hence, much description must be captured so that it can be decomposed into sufficient detail for model execution [5]. Modelling is the process of understanding, capturing, representing, and solving such models [3, 10]. There are four common purposes as to why modelling the process is important: to capture functional, behavioural, organisational and informational perspectives [5]. The functional perspective helps us to understand what the process elements are being performed and what flows of informational entities are applicable. The behavioural perspective tells us when the process elements are performed and how they are performed particularly through feedback loops, iteration, complex decisionmaking conditions, and entry and exit criteria. The organisational perspective allows us to see where the process elements are performed and who in the organisation is going to do it. The informational perspective enables us to be familiar with the informational entities produced or manipulated by a process and the relationships among these entities. Most systems focus on the functional and informational perspectives at the detriment of the organisational and behavioural. Furthermore, most decision systems are observed to concentrate on efficiency, effectiveness, interfaces or data depending on the disciplines of the system designers. The inclusion of simply a traditional optimising [7, 13] or a satisficing paradigm method but not both prevents the possibility of integrating optimising and satisficing in the process. Furthermore, most decision systems are observed to solve problems by receiving decision parameters at the start of the process. The lack of intervention during the process suggests that only fixed sequential decisions are considered. Despite the fact that many decisions execute in a sequential fashion [23] the order of execution should be neither fixed nor predetermined. This way, the decision systems are flexible and able to solve complex problems in various domains and/or paradigms. Moreover, the problem can be
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
1
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
recognised and modelled differently by different user group, but the user must be able to progress from novice to competent users [8]. To overcome these problems, we first propose a converging decision analysis, an organisational learning decision-making, and a cyclical modelling process, and subsequently a Flexible Object-Oriented Decision System (FOODS) framework and architecture to support this process. A prototypical system was developed and implemented to act as a proof-of-concept to support the proposed processes, framework and architecture. Objectoriented concepts were leveraged as they are better at handling complex problems.
2. Decision Making Processes and their Modelling Process A decision process that can flexibly solve problems in any domain or paradigm is essential in decision making and support. Often a decision comes with many factors. Therefore, decision making can be improved by first focusing on essential factors, and eliminating nonessential ones. This is known as the attention-focused method that provides a cut down version of the problem rather than an actionable result [16]. Subsequently, a decision can be derived from the reduced problem so as to provide an actionable result. This is the decision-focused method that produces an actionable result from the given problem [16]. Often in solving a complex problem, many intermediate decisions are necessary before recommending on a course of action. If the result or outcome of an intermediate decision is not satisfactory it can be revisited. This is the iterative process known as the convergence process [19]. Adopting the two differing focusing methods allows many intermediate decisions to be made, starting from “concentrating” on essential factors and then “deciding” on given factors. Each decision converges as the scope of the problem is narrowed and refined through several iterations of attention-focused and decision-focused methods within the decision making process before prescribing or settling on a course of action, as shown in Figure 1.
Figure 1: Converging Decision Analysis (adapted from [16, 19])
The course of action derived can be an optimised or a satisficing solution. An attention-focused method or a decision-focused method does not necessarily produce an optimal or a satisficing solution. It is up to the decision maker to decide on what sort of solution is desired at the time. Each decision and solution is encompassed in a decision model. Each actionable scenario may be fed into another decision model to produce another optimal or satisficing action. In a complex problem this process may repeat over several scenario instances before an ultimate action is reached, where each of them can take on a different solution option. Each decision model may return to itself for refinement, or return to the previous model for additional processing, or feed to the next model for further processing. A focusing method is a narrowing or decisive method that is helpful for problem classification, whereas an optimising or satisficing approach adopts a mathematical or algorithmic method that can be developed and implemented. The overall decision-making process originated from the single and double-loop learning of the individual and organisational learning processes [1, 22], as shown in Figure 2.
Figure 2: Individual and Organisational Learning (adapted from [1, 22]) Besides the imperfect information supplied at the beginning as in Phase 1, additional information may be requested as in Phase 2 pending on whether additional factors are applicable to a particular decision problem. All the information is sent to the decision model in Phase 3 to generate a scenario solution in Phase 4. However, such a scenario may not be actionable and need to be recomputed, hence, it may be necessary to return to Phase 3 and repeat the decision model process. Nevertheless, one may learn that the initial information is incorrect or incomplete and can be corrected by going back to Phase 1 and starting the whole decision-making process again (“single-loop learning”). Alternatively, one may learn that the initial model is inaccurate and will need to investigate on the fundamental objectives and compare the model representation against the reality as in Phase 5 in order to
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
2
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
return to Phase 3 to modify and recompute the decision model (“double-loop learning”). Due to the fact that the underlying model can be altered as a result of the proposed action, this process is said to be in an open environment. Figure 2 gives a pictorial summary of the open individual and organisational learning. It also depicts the inclusion and integration of both optimising and satisficing solution methods within each decision model in Phase 3. Such decision models are also consistent with the two differing focusing methods mentioned earlier. A modelling process occurs when the decision maker defines and develops an abstraction of the real world problem in the form of a model so that s/he can decide and solve a problem under consideration [3]. Not only does the model act as a model schema [9, 15], but it is also a mathematical model [9, 20] that acts as an executable computer program module [18]. Often this modelling process is iterative and cyclical, and requires continuous adjustment and refinement. It is also
especially valuable on modelling the system components of the decision. Figure 3 shows how the whole modelling process operates and recurs, from the initial step that once the problem is understood it can be represented in the form of a model (“formulation of the model”). This model is then instantiated with data (“integration of the model with data”) and integrated with solvers (“integration of the model with solvers”) so that it can be executed (“execution of the model”). Such a model is especially beneficial if it is storable (“storage of the model”) and retrievable (“retrieval of the model”) for later use and comparison. Once the model is represented, a solution can be derived through analysing (“analysis of the model”) and investigating it (“scenario investigation”). Such a model can also be terminated or removed at any time (“termination or removal of the model”). The derived solution is then reviewed and validated. If it is considered unsatisfactory such information can be used to modify (“modifying the model”) and reformulate the decision model (“reformulation of the model”).
Figure 3: Cyclical Modelling Process (adapted from [3, 9, 20]) Real world problems are often complex with the result from one decision influencing a subsequent decision. Therefore it is important that all such decisions be captured. Each of these decisions may be treated as a permanent and independent scenario model which can be retrieved and included as part of a bigger scenario
problem. Alternatively, it may be treated as a temporary scenario that is pipelined within a bigger scenario problem. Such model integration treatments are subject to the discretion of decision makers at the time of making such decisions.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
3
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
Thus, a complex problem may encapsulate many levels and depths of models integration, such as pipelining, recursion, consolidation, and splicing, as shown in Figure 4. For instance, the result from one model component Model Two is pipelined as an input to another model Model Four; the result from one model component Model Four may be re-entered into the same model component in the hope of improving the result; the result from one model component Model Four may be joined and consolidated with Model One into a main
model component Model Five; the choice of subsequent models Model Two or Model Three may defer based on the final or intermediate results of a model component Model One. However, models that are pure abstractions are insufficient [5]; they must be populated with raw data that formulates the models under representation, solved with some known methods that the described models are intended to resolve; and visually presented that enables decision makers to view the proposed solutions.
Figure 4: Complex Model Integration
3. A Flexible Object-Oriented Decision System Framework and Architecture We propose a flexible object-oriented decision system (FOODS) framework to support the process and overcome the problems and issues identified in the previous section. The FOODS framework comprises of five major components, namely, data, model, dialog [24], solver [18], and visualisation [4], as shown in Figure 5.
Figure 5: System-Oriented Framework Data is the component where the raw data is physically stored and retrieved from. Model is the scenario instance that represents the problem under
consideration. Solver is a component that comprises a combination of known mathematical and computational methods used to solve a model instance. The visualisation component is a combination of embedded text and chart presentations. The dialog component is an interface template that bridges language exchange and user level interaction, which is defined somewhat differently from what it is first introduced [24]. Each of the components is independent from one another, but they are able to map to each other [21] as a pluggable object [26]. Each of the components is also retrievable from their component pool [4] and can be integrated through the kernel for scenario execution. In order to ensure that each component is independent from each other, generic modelling ideas and integration issues are explored and considered, such as, data-model, model-solver, solver-visualisation, datavisualisation, and data-solver independences [21]. Each decision scenario calls for a different combination of components [11]. Since the result from one decision may influence a subsequent decision, it is therefore important to store certain decisions as independent and permanent model instances so that they can be pipelined or consolidated as part of another decision model. The interrelated decisions in a complex problem highlight the representation and integrations of models that bring reduced cost [6], increased modelling productivity and reusability [14], facilitated growth and evolution of modelling systems, and improved managerial decisions [2, 25]. Depending on the nature or condition of the problem, the existence of the integration may be temporary or permanent. A model builder may decide on the suitability of the type of models at the time of execution. A combination of temporary and permanent integration may also be desired if the problem is complex and consist of numerous smaller decision models. For
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
4
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
example in Figure 6, a model may consist of a data D1 and a solver component S1, as illustrated by model M1; whilst another model may consist of two data components D2 and D3, a solver S2, a visualisation V, and a dialog component G, as illustrated by model M2. Furthermore, the result from a model component may be an input to another model component, as illustrated by M1 feeding into M2.
sequence, all decisions must be solved sequentially at the time of execution. Therefore, an iconic interface on its own would not be adequate to represent such a sequence. An execution order, in the form of a list and/or a tree structure, may have to be prescribed for the iconic representation to be useful.
Figure 6: An Example Instance with its Component Pools All four levels of models integration [17], namely, the consolidation of values obtained from different models, the consolidation or pipelining of models that belong to the same modelling paradigm, the pipelining of models that belong to different modelling paradigm and the splicing of models are considered in the framework. A model builder may decide to store the output of that model before feeding it into the next model, or allow reformulation and recalculation to happen at each occurrence. This level of integration is often not developed because it is difficult to put into practice and is seldom supported by any implementation environment. The search for a new proposed architecture is necessary since the integration among components is an important issue among complex problems. We propose a FOODS architecture that implements the framework and supports the proposed process, as shown in Figure 7. This architecture although rooted in tradition, expands and enhances existing work [4]. The FOODS architectural components are organised into four distinct layers, namely, presentation layer, kernel integration layer, component integration layer, and component pool layer. Each of these layers and their components are briefly described below. The Presentation Layer is the layer that communicates with the users in the form of a presentation language, and receives instructions from the users in the form of an action language [4]. However despite that multiple scenario models may exist in parallel or in
Figure 7: Four-Tier Architecture The Kernel Integration Layer is the layer that takes care of the kernel, the composition scenario of the kernel and the execution of the kernel. It holds all the components in place and executes in the form of a problem scenario. Previously, the assimilation of components happens through the control of component or presentation controllers for scenario management, and integration between components in the integration layer. However, past research often only considered simple problems where a stored scenario is unable to be included as an independent scenario inside a bigger scenario. Hence a separation is necessary as the scenario formed at the kernel layer may consist of several smaller scenarios that are integrated to other components but not with the kernel, as seen in Figure 6. In a complex problem the decision maker undertakes the decision-making process one phase at a time. Each decision phase creates a smaller scenario so that the decision maker can have a better appreciation of the effects of a decision within the bigger context of the overall decision. This way, the kernel integration layer can concentrate on scenario management and the retrieval of stored scenarios. The Component Integration Layer is the layer that ensures the amalgamation of various components. Some of these amalgamations happen outside the kernel. This
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
5
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
layer focuses on component integration as well as model integration that occurs on an ad hoc basis until it is stored. It integrates with components from the component pool. The Component Pool Layer manages the components which hold data and functionalities [4]. There are two types of components in this layer: compound components, and atomic components. Compound components are component objects that are permanently integrated. They are common in object-oriented technologies, and are consistent with smaller independent decisions that are part of a bigger decision scenario. Like other component objects the stored scenario object is also a pluggable object so that it can be included in the decision-making of another bigger scenario. There are five atomic components that exist in the component pool. They can be categorised as either the base components or as the communication components. Base components are components that exist in most scenarios and can be permanently integrated into a compound component. Communication components are components that are essential if the description or results of the problem scenario is intended to be communicated. Each component or sub-component is constructed and implemented using object-oriented concepts, is signified by an object-oriented class, and contains its own properties and functionalities. Through the use of the FOODS architecture, a decision maker can undertake the decision making process one phase at a time by creating smaller scenarios and integrating existing scenarios into a bigger scenario. This allows the decision maker to have a better appreciation of the effects of a decision within the bigger context of the overall decision.
process. When a scenario is semi-automated, it is partially customised with some room for intervention in terms of a domain or a paradigm (medium versatility and autonomy). Though a semi-automated scenario is prepared with decision processes in a predefined sequence by the model builder, the user is able to decide on which solver to use. When a scenario is either a manual or an integrated scenario it is highly adaptable for any domain or paradigm and is a knowledge intensive process. This means that in a manual scenario besides determining the decision parameters the user must design each decision step and sequence along the way in the decision making process (high versatility and low autonomy). Furthermore, a manual scenario may consist of several stored scenarios temporarily integrated together. Hence, a manual scenario can be an integrated scenario. It is important to note that a manual or an integrated scenario is domain and paradigm independent since the user has more control to formulate the scenario, design the sequence of the scenario; whilst an automated scenario is domain and paradigm dependent where the user simply enters the required parameters and seeks for solutions; and a semi-automated scenario is paradigm independent but domain dependent so that the user has some freedom to choose which solution method to use to solve the scenario instance. For the purpose of illustration, only the manual scenario (which is also an integrated scenario) is only presented in this section.
4. FOODS Implementation and its Support of the Cyclical Modelling Process A prototypical system was implemented to prove the validity of the proposed processes, FOODS framework and architecture. It was implemented using an objectoriented database management system following the object-oriented concepts: abstraction, encapsulation, inheritance, and reusability, and was in-line with Fourer’s mathematical structure [12] that addressed sparsity. The prototype was evaluated and assessed through four differing optimising and/or satisficing scenarios which in turn distinguished from each other in the context of versatility and autonomy. As depicted in Figure 8, when a scenario is automated, it is highly customised with little knowledge input but is narrowly focused in a domain or paradigm (low versatility and high autonomy). This means an automated scenario is prepared with a chosen solver and decision processes in a predefined sequence by the model builder; so that the user simply enters the decision parameters as requested at the start of the decision making
Figure 8: The Versatility-Autonomy Trade-off of each Scenario In order to illustrate the implemented prototypical system, the one-dimensional cutting stock problem (1DCSP) is used as an example. 1D-CSP is a resource management problem making good use of a piece of material by cutting it into the number of desired size within certain constraints. 1D-CSP is a simple problem in pure mathematical terms, but is complex considering all the real world constraints and interrelated decisions. Hence, it is an ideal “simple” example that consists of “complex” modelling issues that FOODS has been designed to address. Each of the activity, decision, and request happens in a specific phase in the decisionmaking and the modelling process as denoted in the proposed cyclical modelling process (as evidenced in the far left side and to the right of Figure 9). The stakeholders are made up of several interested parties in a 1D-CSP, but
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
6
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
they are grouped into three user groups in terms of their competencies and permissions, rather than the roles they play. The three user groups, namely, the decision maker, the programmer, and the model builder [24], will in turn interact with the activities, decisions, and requests which are represented in the form of use cases. These use cases
are clustered into five groups as a result of the decision making process (as illustrated in the “decision model” in Figure 2). These five groups are domain, optimising, satisficing, utilities, and generic (as shown as columns near the middle of Figure 9).
Figure 9: The Modelling Process of a Manual 1D-CSP Scenario with all possible Stakeholders and Use-Cases The remainder of this section illustrates the 1D-CSP decision-making process of a manual scenario through the steps of the cyclical modelling process by a competent model builder (as illustrated in Figure 9). Figure 10 gives a sample interface of such circumstances. The interface is divided into four areas: (1) the top left panel that displays all the possible modelling tasks; (2) the bottom left panel that displays the modelling process of the problem under consideration and in progress; (3) the top middle area that describes the setup of an instance or the mapping of two instances; and (4) the wider bottom right area reflects the interface of the current execution item and changes subject to the execution item and model in use, as selected and indicated in the bottom left panel.
4.1 Formulation of the Model The model builder starts the modelling process by creating a domain model instance. This domain scenario happens to be of the same type as the satisficing scenario and therefore minimises mapping between the domain and satisficing scenarios.
4.2 Instantiation of the Model with Data The model builder continues on with the modelling process and is able to decide on the order of entering the data as required by the domain that best suit him/herself. In this instance, the orders and quantities are first entered, followed by the objective, and last the raw material availability.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
7
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
4.3 Integration of the Model with Solvers Once the domain parameters are recorded, the model builder selects a satisficing method based on his/her own knowledge to generate some suitable cutting patterns to narrow down all combination of cutting patterns. However, the user may wish to utilise prior and own knowledge to best decide on the most suitable patterns and thus correct the existing model in use. The narrowing and deciding actions described here support the attention-
focused and decision-focused methods as depicted in Figure 1.
4.4 Execution of the Model Once a solver has been chosen the model builder can execute and solve the instantiated satisficing model instance.
This panel area shows the setup of an instance or the mapping of two instances.
This panel area reflects the current execution item, for example, it is reflecting “Display Satisficing Scenario” now. This panel area displays all the possible modelling tasks.
This panel area displays the modelling process of the problem under consideration.
Figure 10: The User-Interface of a “Display Satisficing Scenario” for a Model Builder
4.5 Analysis of the Model
4.6 Integration of the Model with Solvers
The model builder is then able to view the solved solution and come to a conclusion on whether the inputs or outputs need adjustment, or to continue with the recommended solution. The cutting patterns solution can be viewed in a matrix style or in a stacked bar chart to visually evaluate the output quantities and wastage.
In order to resolve the model instance in an optimised manner, a new optimising scenario is created and the current model instance is mapped to the new optimising model as they are of different type structure. Once it is mapped, the model builder selects an optimising method which first concentrates on generating the relevant demand constraints given the cutting patterns. The optimising method then decides on the best frequencies of each cutting patterns given the specified objective(s). The narrowing and deciding actions described here support the
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
8
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
attention-focused and decision-focused methods as depicted in Figure 1. The integration of the optimising solver with the mapped optimising model described here and that between the satisficing solver and the domain model described in section 4.3 are both in line with the optimising-satisficing decision model depicted in Figure 2.
decision-making process in a complimentary fashion. We then developed a framework and architecture to support this process. We also implemented a prototypical system that acts as a proof-of-concept for the processes, framework and architecture. Through different scenarios the framework was evaluated as generic and effective in solving complex problems under varying conditions of versatility and autonomy.
4.7 Execution of the Model
6. References
Once a solver is chosen the model builder can execute and solve the instantiated optimising model instance.
[1] Argyris, C. and D. Schön, Organizational Learning II: Theory, Method and Practice. 1996, Mass: Addison Wesley.
4.8 Integration of the Model with Solvers In order to interpret the optimised model solution, the instantiated and solved optimising model instance is mapped back to the original domain model instance for viewing or further processing.
4.9 Analysis of the Model The model builder is now able to view the results from both satisficing and optimising solution methods and come to a conclusion on whether the inputs or outputs need adjustment, or to continue with the recommended solution. The frequencies of each cutting patterns solution can be viewed in a matrix style or in a pie chart to visually evaluate the recommended cutting patterns and the overall usage of these patterns.
4.10 Scenario Investigation Once a solution is derived, it can be compared to other similar stored scenarios for the best practical implementation.
5. Conclusion Real life problems under consideration are often complicated and seldom can be simplified without losing the influence between each interrelated decision. Current decision systems fulfil specific objectives and provide predetermined solutions, but fail to see the need to integrate and provide both optimising and satisficing solution methods for different user perspectives. This research blends together various disciplines to model multiple facets of the problem and solve it in an integrated and holistic fashion. We proposed a cyclical modelling process that considers iterative and converging decision analysis and organisational learning. This cyclical modelling process also considers the application of optimising, satisficing as well as integrating both types of solution methods in the
[2] Bhatt, G.D. and J. Zaveri, The Enabling Role of Decision Support Systems in Organizational Learning. Decision Support Systems, 2002. Vol. 32, No. 3: p. 297-309. [3] Brewer, G.D. and P. DeLeon, The Foundations of Policy Analysis. 1995, Homewood, IL: Dorsey Press. [4] Chen, K.J., Sundaram, D., and Srinivasan, A. The Design and Implementation of a Decision Support System Generator. in Proceedings of the IFIP8.3 Conference on Decision Support Through Knowledge Management: Position Papers on Future Directions in Decision Support Research. 2000. Stockholm, Sweden. [5] Curtis, B., M. Kellner, and J. Over, Process Modelling. Communications of the ACM, 1992. Vol. 35, No. 9: p. 75-90. [6] Dolk, D. and B. Konsynski, Model Management in Organizations. Information & Management, 1985. Vol. 9: p. 3547. [7] Draman, M., et al., A Clone-Based Graphical Modeler and Mathematical Model Generator For Optimal Production Planning in Process Industries. European Journal of Operational Research, 2002. Vol. 137, No. 3: p. 483-496. [8] Dreyfus, H.L. and S.E. Dreyfus, Mind Over Machine: The Power of Human Intuition and Expertise in the Era of the Computer. 1986, New York: Free Press. [9] Eppen, G. and F. Gould, Introductory Management Science. 1984, New Jersey: Prentice-Hall. 164-165. [10] Eriksson, D.M., A Framework for the Constitution of Modelling Processes: A Proposition. European Journal of Operational Research, 2003. Vol. 145, No. 1: p. 202-215. [11] Fierbinteanu, C., A Decision Support Systems Generator For Transportation Demand Forecasting Implemented by Constraint Logic Programming. Decision Support Systems, 1999. Vol. 26: p. 179-194. [12] Fourer, R., Database Structures for Mathematical Programming Models. Decision Support Systems, 1997. Vol. 20: p. 317-344.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
9
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
[13] Geoffrion, A., An Introduction to Structured Modelling. Management Science, 1987. Vol. 33, No. 5: p. 547-588. [14] Geoffrion, A. Reusing Structured Models via Model Integration. in Proceedings of the Twenty-second Annual Hawaii International Conference on System Sciences. 1989. Los Alamitos, CA: IEEE Computer Society Press. [15] Golub, A.L., Decision Analysis: An Integrated Approach. 1997, New York: John Wiley & Sons. [16] Holtzman, S., Intelligent Decision Systems. 1989: AddisonWesley Publishing.
[20] Mathur, K. and D. Solow, Management Science: The Art of Decision Making. 1994, Englewood Cliffs, New Jersey: Prentice Hall. [21] Ramirez, R.G., C. Ching, and R.D. St Louis, Model-Data and Model-Solver Mappings: A Basis for an Extended DSS Framework. ISDSS Conference Proceedings, 1990. [22] Sage, A.P., Chapter 6: Information Processing in Individuals and Organizations, in Decision Support Systems Engineering. 1991, John Wiley & Sons. p. 205-262. [23] Simon, H., Models of Bounded Rationality. 1983, Cambridge, M.A.: Harper and Row.
[17] Kottemann, J.E. and D.R. Dolk, Model Integration and Modelling Languages: A Process Perspective. Information Systems Research, 1992. Vol. 3, No. 1: p. 1-16.
[24] Sprague, R.J., A Framework for the Development of Decision Support Systems. MIS Quarterly, 1980: p. 1-26.
[18] Krishnan, R. and K. Chari, Model Management: Survey, Future Research Directions and a Bibliography. Interactive Transactions of ORMS, 2000. Vol. 3, No. 1.
[25] Tung, L., R.G. Ramirez, and R.D. St Louis, Model Integration In An Object-Oriented Model Management System. IEEE, 1991. Vol. 73.
[19] Langley, A., et al., Opening up Decision Making: the View from the Black Stool. Organization Science, 1995. Vol. 6, No. 3, May-Jun 1995: p. 260-279.
[26] Wrobel, S., et al. Extensibility in Data Mining System. in 2nd International Conference on Knowledge Discovery and Data Mining. 1997.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
10
