Features of the architecture of decision support systems

Transcription

1 Features of the architecture of decision support systems van Hee, K.M. Published: 01/01/1987 Document Version Publisher s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication: A submitted manuscript is the author's version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website. The final author version and the galley proof are versions of the publication after peer review. The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication Citation for published version (APA): Hee, van, K. M. (1987). Features of the architecture of decision support systems. (Designing decision support systems notes; Vol. 8707). Eindhoven: Technische Universiteit Eindhoven. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal? Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Download date: 05. Nov. 2018

2 FKA.TUR.ES OF THE AltCBITKCTORE OF DECISION SUPPORT SYSTEMS by K.M. van Hee NFl 11.87/07 EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics and Computing Science P.O. Box MB EINDHOVEN, The Netherlands December 1987

3 K.M. van Hee Department of Mathematics and Computing Science Eindhoven University of Technology P.O. Box 5l3, 5600 MB Eindhoven, the Netherlands

4 Features of the architecture of decision support systems by Kees M. van flee Eindhoven University of Technology 1. Introduction Decision support systems and expert systems are infonnation systems that assist people by giving advise or solving problems. If this role would be played by human beings we would classify their work as intelligent behaviour. Therefore we may call such systems: intelligent information systems, in contrast with more classical infonnation systems that monitor some process and perfonn routine functions. There is a big market for intelligent infonnation systems and therefore it is important to have a good design methodology for these systems. For development approaches for classical infonnation systems seem to be inadequate. In this paper we study the architecture of intelligent infonnation systems with the purpose to use the architectural characteristics for a designmethodology. The tenn "decision support sytem" is used in the area of operations research, while the tenn "expert system" is coming from the artificial intelligence world. The application area of expert systems seems to be larger than the area of decision support systems [cf. Sowa (1984)]. The following definition of an expert system is due to [Jackson 1986]: "Computing system capable of representing and reasoning about some knowledge rich domain with a view to solving problems and giving advise". In the nex.t section we define the concept of a decision support system and in section 3 we consider the model-oriented approach to decision support systems. In section 4 we consider the process of the construction of a decision as a graph search problem and we indicate how a shell could be constructed for decision situations that can be characterized as "combinatorial planning situations". For a more extended treatment we refer to [Van Hee, Lapinski (1987)].

5 Concept of a decision support system We consider a decision support system (dss) as a subsystem of a control system of some other system, called object or target system. The control system has two tasks: monitoring and steering of the target system. The monitoring task is usually perfonned partly by a classical information system, also called a database system. The monitoring of the target system is essential for the steering task. The steering task is sometimes completely fulfilled by computers, but in many cases human beings steer the target system. Their control actions are called plans or decisions. Computer systems that assist decision makers by offering facilities for: computing effects of plans that are made by the decision makers, ii iii generating plans within some region of allowable plans, selecting plans from a given finite set of plans and their effects are called decision support systems. The first facility may be called 'evaluator' and requires some mathematical model that describes all relevant characteristics of the target system. With this model the effects of plans can be computed. The second facility needs also a model of the target system, however it may be a less precise description, for instance a simplification of the model used to compute the effects. A classical characterisation of an allowable region is the set of optimal plans, where optimality is defined by some criterion. In general this characterisation is a difficult one because the complexity of the computation needed to verify whether a given plan is allowable, is the same as generating an optimal one. The last facility perfonns multicriteria analysis. It is usually studied in combination with linear programming models. The facility is usefull in situations with conflicting evaluation functions, where the vector of evaluation functions does not provide a total ordering on the set of plans. With this facility the decision maker may find his utility or weight function over the criteria. A selection facility does not require any knowledge of the structure of the decision situation or target system, a generating facility requires detailed knowledge of the set of allowable decisions and also knowledge, in the fonn of a mathematical model, of the target system. An evaluation facility needs the most detailed knowledge of the target system and therefore these subsystems are often developed for a specific decision situation, for instance in the fonn of a simulation model. Decision support systems that really interact with the decision maker, i.e. without a human intennediair, require a high level userinterface. Decision support systems that have a very frequent interaction with decision makers, are found on the level of operational management

6 Model-oriented approach The model-oriented approach is the approach of operations research. Here the designer or a dss chooses or develops mathematical models that describe relevant aspects of the target system. This is often his starting point Sometimes the emphasise is on the evaluation of effects of a plan. Examples of this type occur in situations where a new organisation of production resources has to be chosen. In situations where the decision concerns the allocation or assignment of resources the generation of a plan is the main task and there optimization models are often used. It seldom occurs that a target system can adequately be described by only one model. Then we need a set of models, each describing only aspects of the target system. Often these models are interrelated by parameters that are input for one model and output to another. An example of such a situation occurs when for the generation of decisions a simplified model of the target system is used, while for the evaluation a complex simulation model is used. With the simulation model it is practically impossible to optimize, however it computes essential parameters for the simplified optimization model. On the other hand the simulation model can only evaluate plans generated by the optimization model. In general we may have a network where the models fonn the nodes and the (directed) arcs are labelled by parameters that are transferred from the source node to the sink node of the arc. Given a value to all parameters in a network and considering them as inputparameters for the models in the network we get for each parameter an output value computed by a model. Hence the network defines a network-function that transfonns the set of parameter vectors into itself. A consistency condition for a model network: is that a used parametervector is a fixpoint of the network-function. In general there is very little known about the relationship between input and output parameters of a model-network and therefore very little is known of the networkfunction. A usual computational procedure is iteration of the network-function until in- and output vectors are close. However in practice there is often no theoretical justification that such a method of successive approximations is converging. Most fixpoint theorems require structural properties of the underlying transfonnation that are unknown. In the model-oriented approach the dss is build around the model or the model network. It means that a datastructure is designed to describe the parameters of the model network and a database system is constructed to manipulate the datastructure. Then each model is translated into a program or module. In case of a network there is a module needed that takes care of the above described successive approximation of a fixpoint. Finally a user-interface is designed which enables the decision maker to control the activation of the other modules and with which the database can be questioned. It turns out that decision makers usually want to keep more than one parameterset, each one representing a scenario or world. Therefore a database system in a decision support systems needs a facility for version or configuration management The model-oriented approach has a disadvantage, namely that the used models are simplifying the decision situation too much. The modelling of the target system is the central goal and not the representation of the space of allowable plans. Therefore in many dss's designed according

7 - 4 - to the model-oriented approach is the inflexibility for adaptations, in case new constraints arise or the preference pattern over the planning space changes. In many cases these adaptations require fundamental changes of the models and therefore of the algorithms. Such changes cannot be performed by the end-user, the decision maker, but they require the involvement of the dss-designer. This fact is probably the cause that there are so little dss's in operation while there are so many decision situations. In the next section we consider another approach to dss, one that may overcome the problems sketched above. 4. Towards dss-shells In this section we sketch a model of a dss that can be used to construct a dss-shell. With a dss-shell we mean a software system that accepts a description in a high-level language of a structure of a decision situation. Given this data the shell behaves like a dss for that panicular decision situation. This means that it accepts factual data of the decision situation, i.e. data of the aclual state of the decision situation, and it interacts with the decision maker to construct a plan that satisfies some user-defined requirements. Such a shell will be very flexible in the sense of section 3 since a decision maker or an expert only has to update the high-level description of the decision situation to adapt the dss to changes in the target system. A trade off of the use of such a dss-shell will be a less-efficient system in the sense that there might be model-oriented dss's that give better plans according to criteria suited for the models in such a dss. A dss-shell may be compared to a database management system and an expert system shell. A database management system gets a description of the datastructure in the form of a scheme and if some database instance is created the query-language offers the user the facility to retrieve data for this particular data structure. If an expen system shell is augmented by a knowledge or rule base then it behaves as a specific expen system. Now we sketch a model of a dss that is applicable in many decision situations where a plan has to be constructed. The model is described by a tuple <D,P,E,T,Q,G,M,SE,SM,U > where D : P : E : the set of domains, i.e. an element of D represents the state of the decision situation at some moment; set of plans, i.e. each element is a plan for the decision situation; set of plan-extensions; T: a plan transformation function, i.e. T:P xe -:;P, so given a planp and an extension a T(p,a) will be a new plan;

8 - 5 - Q : G : a function that dermes the set of allowable plan-extensions of a plan, depending on the domain, i.e. Q: P xd -'t 2E ; a function that detennines whether a plan could be accepted or not, i.e. G : P xd -'t {true, false}; M: a memory structure, i.e. an element m of M contains the set of plans constructed so far and considered relevant. In fact m is a tree, the nodes of which are pairs composed of a plan and a set of extensions. The edges of the tree are labelled by plan-extensions, and if < p,e > is a node and a is an edge starting in this node then the edge ends in a node where the first component equals T (p, a ). Further e e Q (p, d) and a e Q (p,d) {e}. Hence the plan-extensions e in a node <p,e > are the free extensions that might be considered in the future. A tree m e M represents the state of the plan construction process at some stage; SE: is a selection function that selects an extension from a set of extensions, i.e. SE: 2E -'t E such that SE(e)e e; SM: is a selection function that selects a node to extend from a memory state m EM, i.e. SM: M -'t P X 2E, such that for m E M SM (m) is a node in the tree m, with a non-empty set of free- extensions; U: is a memory-update function, i.e. U:M xp xe -'tm such that U(m,p,e) is a tree that can be fonned out of m by extension of a node < T (p,e ), Q (T (p, e ), d ) > or by transfonning the node where p is the first component by deleting e from the set of free extensions, or by deleting leave nodes; Now we will describe how the shell operates, given these components in some representation. It first asks the user for an initial state for the search process, in fact this will be the root of all memory states during the planning process. Then the shell will perfonn the following iteration: 1. select a node from the memory state m according to SM(m), say <p,e >, 2. select an extension from SM (m) according to SE (e), say a ( E e ), 3. compute T(p,a), 4. if G(T(p,a ),d) = true then stop else compute U(m,p,a) and return to step 1. The functions SE, SM and U may be defined by some fonnulas in the shell or by the user in an interactive way. The last option means that the shell is asking the user for a selection or update in each step of the process. This may be called hand-control while the first option is full-automatic control of the planning process. Note that only Q and G depend on domain-data and are defined in fact by the end-user. The other components are domain-state independent and fonn the so called structural data. It depends on the level of the language in which the components are described and of the expertise of the end-user whether he is able to modify the structural data. In case the language will be a first order logic, it seems that it requires some expert to modify the structural data.

9 - 6 - However such an expert can do this very quickly. (We have made some experiments where Prolog was used as description language). Such a shell needs in fact two user-interfaces: one for decision makers and one for an expert. Note however that Q and G can be adapted by the decision makers. In [Van Hee, Lapinski (1987)] we showed that it is easy to express all kind of search strategies like depth-first, breadth first, hill climbing etc. by specifying the functions SE, SM and U. There we also considered a jobshop as decision situation as an example. The representation of plans and extensions is important If plans are represented by sets of terms (or tuples) and if plan-extension means adding terms (or tuples) then a memory state m may be represented by representing each node only by its difference with its predecessor node. This gives in many cases an interesting reduction of the representation of the state. We conclude with some remarks. The approach sketched in this section seems to be suitable for a large class of operational planning problems, specially where a combinatorial model is used in the case of a model-oriented approach. It will take a lot of experimentations with prototypes before such dss-shells will be able to operate in practice. Two major problems are: the language of the shell to define the structural data and the efficiency of computations if the system is operating under automatic control. The language needs to have great expressive power but should be easy to learn, because a planning expert should use it instead of a programmer. The computational complexity might be large, however the search graph approach is suitable to apply parallel processing techniques. 5. Literature Van Hee, K.M., Lapinski, A. OR and AI approaches to decision support systems. To appear in Decision Support Systems (1988). Jackson, P. Introduction to expert systems. Addison-Wesley, Sowa, J.F. Conceptual structures: information processing in mind and machine. Addison-Wesley, 1984.