- Email: [email protected]
Use of reason maintenance in model formulation
OMEGA Int. J. o f M g m t Sci., Vol. 21, No. 1, pp. 123-133, 1993 Printed in Great Britain. All rights reserved
0305-0483/93 $6.00+0.00 Copyright © 1993 Pergamon Press Ltd
Use of Reason Maintenance in Model Formulation AS BHARADWAJ A SEN AS VINZE Texas A&M University, College Station, Texas, USA (Received November 1991; in revised form June 1992) Studies of the process of model formulation by experts have shown the process to be an iterative one, in which the model is continuously refined until a complete and consistent representation emerges. It is also a highly unstable activity as the problem specifications, including the goal, may change both during and after the formulation. In order to be able to model real world problems, model formulation systems, which provide computer-based support for model formulation, should also be capable of dealing with changes to the problem. This paper presents the architecture of a model formulation system enhanced with reason maintenance capabilities, for dealing with changes in assumptions and specifications during formulation.
Key words--artificial intelligence, modeling
1. INTRODUCTION MANAGERIAL PROBLEM SOLVING has been an active research area for several decades. The term problem solving encompasses two distinct phases: the problem formulation phase and the problem solution phase [20]. The problem formulation phase consists of the tasks of problem identification, problem definition and problem structuring. This activity is regarded as highly knowledge intensive, with various cognitive processes such as perception, conceptualization, planning and reasoning coming into play. The classical management science approach to problem solving is to construct a mathematical model for the problem as a set of equations and then to solve the model using standard algorithmic procedures. This stream of research has traditionally focused its efforts on the development of new and improved algorithms for computerized model solving [6, 7]. The front-end task of model formulation, recognized as requir-
ing a high degree of cognitive skills continued to be performed manually with little computer support. Recent research efforts, however, have focused on providing computer-based support for model formulation, leading to the construction of model formulation systems [1, 10, 11, 16-18]. In these systems, the problem description is elicited from the user, usually through friendly interfaces that allow high-level qualitative descriptions of the problem. Formulation proceeds in an incremental manner until all the information is obtained, and the system is able to construct a mathematical representation. Two problems implicit in the current approaches to model formulation are monotonicity and atomicity. The monotonicity problem leads a system to assume that all of its current information is true and that truths never change. The formulation system's reasoning process therefore only consists of augmenting its current information with additional 123
124
Bharadwaj et al.--Reason Maintenance in Model Formulation
information derived through explicit inference rules. If the new information conflicts with the old, the system cannot handle it. For example, if the system believes that factory A produces product A, and later the user indicates that factory A is closed due to a fire in the premises, the system cannot reconcile the new information. It would continue to believe that product A is still manufactured at the factory. The related problem of atomicity leads the formulation system to view each piece of information as an isolated statement related to other beliefs ~ only through explicit semantic relationships. Since the semantics of beliefs are usually not explicitly represented, the system cannot handle any incremental changes to its current set of beliefs. Thus, repercussions of any new information provided to the system is ignored by it. In contrast to this behavior, we find that human experts when formulating models, constantly check and revise their assumptions and other deduced facts. This task is performed implicitly by humans, and hence the problem of maintaining internal consistency is easily solved. In order for model formulation systems to be able to handle real world problems, they must be capable of making dynamic adjustments in response to changing scenarios. Even if the problem scenario remains unchanged, the user may wish to model hypothetical problem scenarios by changing some of the problem specifications. A stream of research in artificial intelligence (AI) deals exactly with the aforementioned problem. This research stream attempts to develop systems which can handle changing environments and contexts. These systems, called reason maintenance systems2 (RMS), maintain dependencies between the facts stored in the system's knowledge-base. Changes to the knowledge-base are propagated throughout the system and the effect of the changes is communicated to the problem solver system. Thus, by incorporating an RMS with a model formulation system, the objective of making dynamic adjustments to the model in response to changes in problem specifications can be achieved. iT he term 'belief' in knowledge-base systems represents all the data that the system takes to be 'true'. Generally, in model formulation systems, the data supplied by the user and the new data inferred from the inference rules, represent the system's beliefs. 2These systems are also referred to as truth maintenance systems in the literature.
This paper describes a model formulation system enhanced with reason maintenance capabilities. Specifically, the architecture and implementation details of such a system are presented. The reason maintenance capability allows the system to handle changes to assumptions and/or problem specifications. The remainder of the paper is organized as follows. In the next section, we provide a broad overview of the literature on model formulation, reason maintenance and their interaction. Section 3 provides details of the actual process of model formulation as observed from a protocol analysis conducted as part of the study. The cognitive aspects of expert reason maintenance gleaned from the protocol analysis forms the basis for the system architecture described in Section 4. Finally, the paper is concluded in Section 5. 2. MODEL FORMULATION AND REASON MAINTENANCE: AN OVERVIEW
Model formulation is an intellectual process, that transforms a problem situation into a specific mathematical representation. The process by which human experts formulate models in different problem domains has been studied, using protocols of expert verbalizations [17-19]. These studies indicate that formulation is an iterative process, in which the model is continuously refined until a complete and consistent representation emerges. It is also a highly unstable activity, as the problem specifications, including the goal, may change both during and after formulation. Summarizing the research in model formulation and model revision the following points can be made: Changes to problem specifications occur constantly and are unavoidable. They may be avoided at the cost of building a model for the wrong problem, or at best building an inadequate model that ignores salient aspects of the problem. Changes to the problem occur due to a number of reasons. Some of the changes may be uncontrollable, dictated by changes in the environment. Other changes may be introduced by the modeler for (i) revising mistaken assumptions made earlier in the formulation; (ii) simplifying the problem to make it more tractable; (iii) enriching the
Omega, Vol. 21, No. 1
problem to make it more complex and realistic; and (iv) for studying alternate scenarios to choose the best alternative for the problem. • Changes to one aspect of a problem often impacts other parts of the problem leading to substantial revisions in the entire problem space. The changes may also contradict some of the current aspects of the problem making the entire representation inconsistent. • Expert human modelers have implicit mechanisms for handling changes to the problem specifications. They can reason with new knowledge and revise past beliefs/ knowledge in a way that makes the problem representation internally consistent. In spite of these observations, very few attempts have been made by the DSS community to build systems capable of dealing with changes to problem specifications. A few notable exceptions are discussed in a subsequent section. As noted earlier, the AI community has been actively pursuing research in this area under the broad label of truth maintenance or reason maintenance. We briefly describe the functionality of reason maintenance systems next. 2.1 Reason maintenance systems In any reasoning system, such as an expert or a knowledge-base system, the problem solver makes inferences (or reasons) based on the facts provided to it. These facts represent the beliefs of the system. Typically, the beliefs influence each other and are always assumed to be true by the system, that is, the system assumes that the state of the world does not change during the reasoning process. Thus, if a piece of information is retracted, or if some new information is added that contradicts a previous belief, the system cannot revise its beliefs accordingly. For example, suppose the model formulation system has the following simple rule: If (product X is shipped from region A to region B) Then (product X is available in region B) Let us further assume that the user has asserted that product X is shipped from region A to
2IME 21 I--1
125
region B. The system now has two beliefs (a) product X is shipped from region A to region B and (b) product X is available in region B. But suppose the user later retracts the assertion that product X is shipped from region A to region B. The system will however continue to believe the inferred fact product X is available in region B, without suitably retracting or modifying it. One of the functions of a reason maintenance system is to enable a problem solver to suitably alter its beliefs about the state of the world in response to new information, i.e. perform belief revision. A reason maintenance system was first introduced by Doyle [4] in the late seventies, and since then there has been an explosion of interest in these systems in the AI community. A reason maintenance system serves as a house-keeping subsystem of an overall reasoning system. The problem solver passes to the RMS the inference it makes, and the RMS uses the structure of these inferences to organize the beliefs of the problem solver. By interrogating the RMS the problem solver receives feed-back about what it believes. The form of the interaction between the two systems usually varies, but typically the RMS would provide information about the beliefs on which inconsistencies rest and the set of mutually consistent beliefs with which to work [9]. Thus, in the above example, the model formulator would pass both the asserted datum and the inferred fact to the RMS which would record the fact that product X is shipped from region A to region B as the reason for believing that product X is available in region B. The primary task of an RMS is to maintain a set of beliefs in such a way that (i) they are not known to be contradicting and (ii) no belief is kept without a reason [14]. An RMS works by constructing a dependency network of all the facts represented in the knowledge-base. Whenever a new fact is introduced in the knowledgebase, not only the fact but also the reasons for believing the fact are recorded. Thus, every fact (represented as a node in the dependency network) has a list of justification nodes. These are the other facts that support a given fact. Whenever a fact (say A) is retracted, all other facts which have A on their justification lists also have to be retracted or modified. Likewise, the justification network of A has to be traced backwards to see which other facts do not hold in the revised context.
126
Bharadwaj et al.--Reason Maintenance in Model Formulation
The RMS is by itself not a problem-solving system. All the facts and justifications have to be provided by the problem-solving system. It is only a supporting system that records and maintains the dependency network of the facts. By keeping the RMS independent of the problem-solving system, it can be used for any problem-domain and also with any type of problem-solving system. 2.2 Use of reason maintenance in operations research
Reason maintenance has been used for solving certain design problems in operations research (OR). The design problem consists of assigning permissable values to a set of design variables in order to maximize (or minimize) an objective stated in terms of such variables [15]. An example of a general class of design problems in OR, that have been solved with AI techniques are the constraint satisfaction problems (CSP) [2]. A CSP is characterized by a finite number of choice sets and a set of constraints defined over the choice sets. A solution to a CSP is a combination of alternatives, one from each choice set, such that together they satisfy each of the constraints. Dhar [2] shows how RMS provide an ideal mechanism for managing the reasoning process in solving CSPs. The RMS is used for analyzing the repercussions of making incremental changes such as tightening or relaxing of constraints. A more specific example of the use of RMS for a design problem is presented in [15]. In their system the authors combine optimization algorithms with heuristic methods for designing communication networks. A blackboard data structure is used to store the current state of the network design as it evolves, and is accessible by interacting knowledge sources. An RMS records the justifications for choices leading to the current design state, as well as for promising alternatives that are not selected by the system. A dependency-directed backtracking procedure works in conjunction with the RMS to choose other promising alternatives, when a current partial design turns out to be infeasible. The only previous implementation of an RMS with a model formulation system is described in [17]. In their system called MODFORM, designed for formulating LP models in the production planning domain, the
authors incorporate a reason maintenance component called BMS (belief maintenane system) for performing model revisions. The BMS is used as a computational tool, to support revisions of beliefs held by the formulation system. It keeps track of the justifications and the justificands for every belief that is represented in the system. The basic operations supported by the BMS are addition of a node (belief), deletion of a node, and verifying whether a node is valid in a particular context. The BMS allows the user to explore multiple contexts, and keep track of the beliefs that are valid in each context. Thus, different versions of the same problem can be treated as multiple contexts with varying sets of assumptions in each context. In this system, the dependencies between the model components are captured at the instance level, rather than at the schema level, resulting in large and cumbersome dependency networks. 3. M O D E L FORMULATION P R O C E S S
In order to understand the modeling process adopted by experts, a protocol analysis of the formulation process was conducted. Linear programming problems from the production planning domain were assigned to three experts, who were asked to formulate the corresponding models. They were also instructed to verbalize their thought processes as they proceeded with the formulation. The expert verbalizations were recorded and analyzed to understand the cognitive processes that came into play during formulation. The analysis provided an understanding of the overall reasoning and control strategies adopted by experts during the formulation process. The protocols of the experts' verbalizations revealed that the experts adopted an opportunistic approach to model formulation. This was in contrast to past findings which have suggested other approaches such as the hierarchical [17] and analogical [12] approaches to model formulation. The opportunistic approach to model formulation, suggests that rather than having a well-defined plan of action, the expert exploits the intermediate decisions and observations to guide the formulation process. For example, the expert may have proceeded to the problem analysis phase, when he/she discovers that some more information is required about the problem. At the stage the expert goes back
Omega, Vol. 21, No. 1
to the problem understanding phase, and may even re-read the whole problem. Opportunism was evident from the rapid and dramatic shifts in the experts focus of attention during the entire process. The protocol analysis also indicated that during the formulation process, experts tend to make certain critical assumptions that enable them to proceed with the formulation. These assumptions, usually referred to as default assumptions, 3 were often made when the expert thought that he/she had incomplete information about the problem. However, in certain situations the default assumptions turned out to be wrong. This happened whenever the experts focused too quickly on a particular aspect of the problem, sometimes even before the problem was fully read and comprehended. The protocol analysis further revealed that default assumptions were also frequently made when the experts had standard expectations as a result of their prior experience with similar problems. For example, one of the problems assigned to the experts was a multi-commodity transportation problem. This problem differed from other standard problems in this class, in that it did not have any supply constraints. However, two of the three experts to whom this problem was assigned, first assumed that each producing region had supply constraints. In this case, the default assumption turned out to be wrong, and the experts realizing this at a later stage, retracted the default. When experts retracted any assumption, they always checked the other aspects of the model that they had previously formulated to ensure that their formulation was consistent with the new information. This revealed to us that experts were implicitly performing reason maintenance in order to come up with the correct formulations. Details of the protocol analysis and a description of the findings have been presented in [13].
4. S Y S T E M A R C H I T E C T U R E
The cognitive aspects of the expert model formulation process, identified from the protocol analysis, guided the design of the model 3The term 'default assumptions' is used in AI to describe standard or routine assumptions that humans make especially when faced with incomplete information.
127
formulation system. The primary design consideration, focusing on the process of model formulation, suggested that the system must be capable of exhibiting opportunism. Hence, the opportunistic planning paradigm was chosen as the appropriate model for constructing the system [8]. The blackboard architecture has been found to be a suitable representation for implementing an opportunistic model [5]. The blackboard architecture uses two basic components: knowledge sources and a blackboard data structure. The knowledge-base is partitioned into independent chunks of knowledge called the knowledge sources (KS). These are specialists, and may be viewed as mini expert systems that focus on different aspects of the problem. The blackboard is a global data-base on which all the problem-solving knowledge is represented. Typically, the KSs interact in an opportunistic manner to incrementally develop the solution on the blackboard. Our system adopts the blackboard architecture for model formulation. The next major consideration in designing the system was to implement reason maintenance capabilities, in order to enhance the capability of the system to deal with real world complexities. As indicated earlier, the protocol analysis suggested that human experts constantly and implicitly perform reason maintenance. This feature is essential in a model formulation system to ensure consistency of the knowledge-base and correctness of the formulated model. A modular approach to system construction was adopted. In the first phase of system development, a model formulation system without reason maintenance capabilities was developed. This system, called AEROBA (an entity relationship oriented blackboard architecture), uses the blackboard framework to construct LP models in the production planning domain. A brief overview of the AEROBA system is presented here (for a more complete description of the system see [18]).
4.1 An overview of AEROBA The AEROBA system uses a blackboard comprising of two panels, for operationalizing the cognitive model of formulation observed through protocol analysis. The problem panel is used to store problem related information in a structured manner. The representation of information is based on a data model called the
128
Bharadwaj et al.--Reason Maintenance in Model Formulation sl.name
A,,ri
sl.cap sl.tot.sh.qty
sh.name sh.cost
sh.qty sh.tot.cost
dl.name dl.ra( dl.tot.sh.qty
ute-,eve,
Relationship-level
Entity-level
/
Demand-location
Supply-location
Domain-level
Transportation
Basic-level
sl.name sl.cap sl.tot.sh.qty sh.name sh.cost
: supply-location-name : supply-capacity : supply-total-shipment-qty : shipment-name : shipment-cost
sh.qty sh.tot.cost dl.name dl.req dl.tot.sh.qty
: shipment-qty : shipment-total-cost : demand-location-name : demand-location-requirement : demand-tot-shipment-qty
Fig. 1. Problem panel representation for a general transportation problem.
extended entity relational model (EERD), proposed by the designers of AEROBA [18]. As the system elicits information interactively from the user, it incrementally constructs an EERD model of the problem on the problem panel. An example of a problem panel representation of a generic transportation problem is presented in Fig. 1. Based on the model structure that evolves on the problem panel, the solution panel is used to bring an appropriate tool template (for example, linear programming template) for formalizing the model into a standard (LP) structure. The tool template is then instantiated with the problem data to come up with the algebraic formulation for the given problem. Assisting AEROBA in all the knowledgeintensive tasks, such as problem type identification, tool selection etc., are multiple specialists called knowledge sources. The knowledge sources contain domain-dependent modeling knowledge and are programmed to be stimulated by, and respond to the information that is posted on the blackboard. The knowledge sources are controlled by an opportunistic control mechanism that monitors and polls the knowledge sources for contribution. In each cycle of operation, the knowledge source which has the highest potential contribution to the formulation process is selected to respond. In
this manner, the process continues until the model is fully formulated. The basic data item in the blackboard is called a solution element (SE). A solution element is implemented as a frame data structure with several slots carrying related information. The solution element corresponds to the various component types that are identified in the EERD data model. Some of the important EERD components are described below. (The complete definitions and examples of all EERD components can be found in [18].) • An entity refers to a physical object in the problem, such as a resource or a plant. A relationship represents an association between entities. For example, shipping is a relationship between a plant and a warehouse. Data attribute, denoted by da, refers to user specified values or parameters, such as shipping-rate-per-unit. Derived attribute, denoted by dr, refers to attribute values that are derived internally using some specified function. For example, shipment-cost is derived
Omega, Vol. 21, No. 1
from shipping-quantity and shipping-rateper-unit. • Action attribute, denoted by ac, refers to the variables or the unknown values in the model. An example of a solution element from the problem panel of Fig. 1 is: Slot-name SE-NAME SE-TYPE OWNER
Slot-value
Remarks
(SUPPLY-CAPACITY) (DATA) (SUPPLY-LOC)
4.2 Extending A E R O B A
data attribute; parent entity is supply location
with an R M S c o m -
ponent
In designing an RMS, the overall structure of AEROBA was used to come up with a representation structure for model dependencies. Next, using the knowledge about dependencies, highlevel algorithms for propagation of changes through the dependency structure were developed. The adequacy of the representation structure, and the correctness of the algorithms were tested, by taking an example problem and applying the RMS to reasons with various model related changes The RMS component is designed to exploit the E E R D structure of the model, and uses the solution elements to explicitly represent the model related dependencies. Our RMS is based on De Kleer's assumption based truth maintenance system (ATMS) [3]. The ATMS design allows the representation of multiple environments simultaneously. Each environment is characterized by a unique set of assumptions. Thus, different versions of the same problem can be represented as separate environments. This provides the user with the flexibility to simultaneously explore different versions of the same problem and to switch from one version to another quickly. For example, in formulating a model for a production planning problem the user may assume that a certain part is manufactured in-house and represent the model accordingly. In a different version of the same problem, the user may wish to explore the resulting changes if the part were to be purchased from an outside source. Figure 2 represents the architecture for AEROBA with reason maintenance. The multilayered problem and solution panels are used
129
for creating different model versions. Each layer represents a version or context with the topmost layer representing the current or the latest version. Each layer is uniquely identified by a label and all the solution elements that are active in that environment will carry this label in one of the slots specially marked for this purpose. If the user explores an alternate scenario, where some data item (solution element) is deleted, then the solution element and all other related solution elements will become inactive in the new environment. The use of labels for specifying the environments helps the model formulator identify the relevant solution elements for the new version. The changed E E R D for the new version can be constructed as a new layer in the problem and solution panels. The control process in the enhanced system, not only schedules the knowledge sources, but also triggers the RMS, whenever the user makes a change to the model. A typical RMS works by constructing a node for every problem solver datum. A node is similar to frame data structure with multiple slots attached to it. For example, in the ATMS, each node consists of a justification slot, a justificand slot, a label slot and a contradictory slot. The justification slot comprises of all the other nodes that together justify
Blackboard
,v3 Iv2
[ v3
I v2
Iv1 l
Iv1
V0
vo
Problem panel
/ Knowledge sources
Solution panel
I
Control mechanism
\ Reason I maintenance system
Fig. 2. Architecture of AEROBA with reason maintenance
Bharadwaj et al.--Reason Maintenance in Model Formulation
130
the current node. For example, if node P represents the fact product X is available in region B, and node Q represents the fact product X is shipped from region A to region B, then the justification slot for node P will contain node Q indicating that P is justified by Q. The justificand slot of any node represents all other nodes that are justified by the current node. Thus, in the above example, the justificand slot of node Q will contain node P, indicating that node Q justifies node P. The label slot identifies the environments associated with that node, and the contradictory slot which contains a single bit to indicate if the datum represented by the node is contradictory. In our design, rather than introduce a new data type for the RMS node, we extended the representation of each solution element frame with the following additional slots: Justification slot. For a given solution element SEx, this slot will contain a list of other solution Slot-name
Slot-value
SE-NAME SE-TYPE OWNER JUSTIFICATION JUSTIFICAND DEL-BIT LABEL
Remarks
(SUPPLY-CAPACITY) (DATA) (SUPPLY-LOC) (SUPPLY-LOC) (STK-AVA1L-CONST5 NULL (V0,V 1
data attribute; parent entity is supply location; justified by existence of the solution element supply location; justifies the constraint solution element--stock availability; currently a valid solution element; this solution element is valid in environments V0 and VI
elements that justify SEx. The justification slot can be empty, indicating that it is a premise justification. A premise justification is one that is always valid and consequently a solution element that contains a premise justification is one that does not depend on other SEs for its existence, i.e. the SE can exist independently. For example, all entities asserted by the user, such as plants, warehouses etc., will have premise justifications since entities can exist independently. A justification list of the form {(SEI,SE2)} represents a conjunction of justifications, and indicates that both SE~ and SE2 are needed for justifying SEx. A justification list of the form {(SEI)(SE2) } represents a disjunction of justifications and indicates that either SE~ or SE2 alone is sufficient to justify SEx. More SE-ID SE-NAME TYPE JUSTIFICATION JUSTIFICAND EXPRESSION DEL-BIT LABEL
complex justification structures can be obtained by combining these rules. Justificand slot. For a given solution element SE x, this is a list of other solution elements that are justified by SEx. If a solution element is deleted, then all the consequences of the deleted solution element are obtained from the justificand slot, and are recursively deleted, if necessary, until a consistent set of solution elements emerge. Label slot. For a given solution element SE x, this slot indicates all the environments in which SE x is valid. A solution element is valid in a context, if it has a valid set of justifications, i.e. every SE in its justification slot are themselves valid. Delete-bit. This is a single bit which is set to 0 if the solution element is invalid or deleted in a given context. Thus, using the extended representation the solution element for SL.CAP will be as follows:
Apart from the solution element types allowed in the original AEROBA system, two additional types of RMS solution elements called the function type and the constraint type were introduced. Examples of these two types of solution elements are shown below. These types are necessary, because in a given problem situation, many solution elements may be linked to each other through constraint or function expressions. Dependencies are established through constraints and functions, and these dependencies have to be tracked to ensure that changes are propagated correctly. For example, suppose there is a constraint on supply capacity at each supply center. This would be represented through a constraint-type solution element as follows:
:CI : STOCK-AVAIL-CONS; constraint on stock availability : CONSTRAINT (co) : {(SUPPLY-CAPACITY, SUPPLY-QUANTITYS}
:{}
: SUPPLY-QUANTITY < SUPPLY-CAPACITY : NULL : V0,V1
Omega, Vol. 21, No. 1
The constraint C1 represents the link between SUPPLY-CAPACITY and SUPPLY-QUANT I T Y through its justification slot. The solution elements S T O C K - A V A I L A B L E and SUPPLYQ U A N T I T Y would in turn have C1 in their respective justificand slots. Thus, if STOCKAVAILABLE is removed from the problem panel, indicating that a supply center no longer produces goods, the justificand slot of STOCKAVAILABLE would indicate that it justifies constraint C1. The reason maintenance algorithm will trace and remove C1 as it would no longer be a relevant constrain for that problem. Dependencies between attributes, expressed through functions, are handled differently. For example, consider the following function node F1, expressing the function SUPPLY-SALESV A L U E = (SUPPLY-QTY * SALE-PRICE):
131
information is ignored. Users may inadvertently add information that is inconsistent with the current data, or retract some crucial assumption, thereby making the whole structure inconsistent. With the inclusion of an RMS component, the system required a more complex control scheme that would allow it to accept modifications from the user and construct revised models. Users may add, modify or delete solution elements or justifications to solution elements. Whenever any of these happen, the control mechanism has to invoke the appropriate RMS algorithm for dealing with the change. The RMS algorithms are designed to carry out the necessary sequence of changes to ensure overall model consistency. For example, if the user adds a solution element SE~, the RMS
SE-ID: F1 SE-NAME: SUPPLY-SALES-VALUE; TYPE: FUNCTION (fn) JUSTIFICATION: {<~SALE-PRICE, SUPPLY-QTY)} JUSTIFICAND: {(SUPPLY-SALES-VALUE)} EXPRESSION: SUPPLY-SALES-VALUE = (SALE-PRICE*SUPPLY-QTY) DEL-BIT: LABEL: V0.V1
SALE-PRICE and SUPPLY-QTY are attributes of S U P P L Y - L O C A T I O N and justify the function node F1, which in turn justifies the solution element SUPPLY-SALES-VALUE. In this way dependencies between the participating attributes and the functions are recorded. Whenever an attribute that participates in a function is removed, the justification set of the corresponding function is checked and other related attributes are also deleted. Thus, if the entity S U P P L Y - L O C A T I O N is removed, its attributes will be removed first, and through their justificand slots, function F1 and the SUPPLY-SALES-VALUE node will also be deleted, indicating that there can be no sales from that supply center. In this way, all changes can be propagated correctly.
would ask the user to specify the justification for SEx, and then verify the existence of those solution elements. These must in turn specify SE x in their justificand slots. For example, when the solution element SHIPPED is added to the problem panel, the solution elements SUPPLY.LOC and D E M A N D . L O C would have to be specified as the justification for SHIPPED (see Fig. 1). In the case of a delete operation, the RMS algorithm would delete the particular SE and then recursively delete all the justificands of the deleted SEs until a consistent subset of the original model is derived. If the user wishes to preserve the original model, he/she may specify that a new version be created. In this case, the RMS will assign a label to the new environment and create a new layer in the problem and solution panels.
4.3 Control scheme for A E R O B A with an R M S
AEROBA uses a control scheme that is based on opportunism. This allows for a flexible control mechanism that can switch focus and problem-solving approach based on the incoming information. However, while the new information is exploited from a control point of view, its impact on the existing
4.4 The RMS algorithms The operations of the RMS would include adding a solution element, deleting a solution element, adding a justification and deleting a justification. In this section, we provide high level algorithms for adding or deleting solution elements. Modification operations can be
132
Bharadwaj et al.--Reason Maintenance in Model Formulation
handled by a combination of delete and add operations. Solution elements are added to the ap propriate level on the blackboard by the various knowledge sources. Whenever a new solution element is added, control invokes the RMS algorithm ADD-SOLUTION-ELEMENT. The procedure ADD-SOLUTION-ELEMENT(SEx), first verifies if this is a totally new SE or is one that had been previously deleted. This is necessary because, users may sometimes reinsert an assumption that they had previously deleted. In this case, since the SE is already present with its delete-bit set to 0, the RMS only has to reset it to 1, and verify if all its justifications are still valid. Procedure ADD-SOLUTION-ELEMENT(SEx, SE-data, justifications, justificands) begin If SEx exist and delete-bit = 0 then set delete-bit = 1 else add SEx to the appropriate level in the problem panel; For V justification SEj e SEx do; get corresponding SEj and verify if SEx belongs to its justificand slot; For V justificand SEc ~ SEx do; call procedure ADD-JUSTIFICATION(SEe, SEx); end Deleting a solution element involves, propagating the changes recursively through the entire EERD structure Procedure DELETE-SOLUTIONELEMENT(SEx) begin Set delete-bit of SEx = 0; For V SEj~justification slot of SEx do; call REMOVE-JUSTIFICATION(SEj, SEx); For V SEcejustificand slot of SEx do; call DELETE-SOLUTION-ELEMENT(SEe); end 4.5 M o d e l revisions
With the RMS component, AEROBA can be used to systematically deal with many types of
model revisions. For example, suppose in the transportation problem of Fig. 1, the shipment activity is removed. Tracing the justificands of SHIP progressively, the attributes associated with SHIP, namely SHIPMENT-NAME, SHIPMENT-COST, SHIPMENT-QTY and SHIPMENT-TOT-COST would first be removed from the problem panel. Since, the solution element SHIPMENT-QTY is linked to the solution element DEMAND-QTY in entity DEMAND-LOCATION through a constraint node (shipment-qty/>demand-qty), the latter also gets removed from the problem panel. The revised EERD for the problem is shown in Fig. 3. In our approach, the justification links between the various solution elements are maintained at the model schema level, rather than at the model instance level. In this way, the dependencies between the solution elements for even large problems can be easily represented. However, modifications at the instance level (for example, closing of a particular supply center) can be handled by identifying all the solution elements linked to that particular supply center through its key attribute value (SUPPLYLOCATION-NAME). The corresponding instances of the dependent solution elements will be suitably modified. 5. CONCLUSION This paper presented an approach for reason maintenance in model formulation systems. Reason maintenance was shown to be necessary for handling the real world complexities of model formulation. The paper discussed the incorporation of an RMS component to a blackboard based model formulation system. Future research will focus on the application of reason maintenance techniques for model integration. Formulation of large and complex problems would demand the integration of several smaller models. For model integration to be successful a more systematic study of the assumptions underlying each model and the problem of assumption violations across multiple models is necessary. Dependencies between entire models and not just model components will have to be maintained and verified each time the models are integrated. Since any given model can potentially be combined with many different models, a complex network of dependencies will
Omega, Vol. 21, No. I
sl.name
133
dl.name dl.req
sl.cap sl.tot.sh.qty
Attribute-level~ r~ Relationship-level ~
I,,,O0,-,oca,,oo I
Entity-level
I Demand-location I Transportation
Domain-level Basic-level sl.name : supply-location-name sl.cap : supply-capacity sl.tot.sh.qty : supply-total-shipment-qty
dl.name dl.req
: demand-location-name : demand-location-requirement
Fig. 3. Revised problem representation for the transportation problem.
have to be established. The scenario can be further complicated if multiple users maintain different versions of each model. Reasons maintenance techniques can be used for building appropriate links between the different model versions and for maintaining overall consistency in the model base.
11. 12.
13.
REFERENCES 14. 1. Binbasioglu M and Jarke M (1986) Domain specific D S S tools for knowledge-based model building. Dec. Supp. Syst. 2(3), 213-223. 2. Dhar V (1989) A truth maintenance system for supporting constraint-based reasoning. Dec. Supp. Syst. 5(4), 379-387. 3. De Kleer J (1986) Problem solving with the ATMS. Artific. Intell. 28(2), 197-224. 4. Doyle J (1979) A truth maintenance system. Artific. IntelL 12(3), 231-272. 5. Engelmore RS, Morgan AJ and Nil HP (1988) Introduction to blackboard systems. In Blackboard Systems (Edited by Englemore RS and Morgan AJ). AddisonWesley, Reading, Mass. 6. Fourer R (1983) Modeling languages and matrix generators for linear programming. A C M Trans. mathl Software 9(2), 153-183. 7. Geoffrion AM (1987) An introduction to structured modeling. Mgmt Sci. 33(5), 547-588. 8. Hayes-Roth B and Hayes-Roth F (1979) A cognitive model of planning. Cognitive Sci. 3, 275-310. 9. Kelleher G and Smith BM (1988) A brief introduction to reason maintenance systems. In Reason Maintenance Systems and their Applications. Horwood, Chichester. 10. Krishnan R (1989) PDM: a knowledge-based tool for model construction. In Proceedings of the TwentySecond Annual Hawaii Int. Conf. on System Sci., Vol.
15. 16. 17.
18. 19.
20.
llI, Decision Support and Knowledge Based Systems Track, pp. 467-474. Liang TP and Jones CV (1988) Meta-design considerations in developing model management systems. Decn Sci. 19(1), 72-91. Liang TP (1990) Problem similarity, modeling by analogy and their roles in model management systems. In Proceedings of the First Systems Conf. for Decision Support Systems. Austin, Tex., pp. 405-421. Liou ST (1992) Aeroba: a control blackboard approach for model formulation. Unpublished doctoral dissertation, Texas A&M University, Tex. Martins JP (1991) The truth, the whole truth, and nothing but the truth: an indexed bibliography to the literature of truth maintenance systems. Artific. lntell. Special Issue, 7 25. Mitra S (1990) AI/OR hybrid methods in telecommunication network design. Unpublished doctoral dissertation, University of Iowa, Iowa. Murphy FH and Stohr EA (1986) An intelligent system for formulating linear programs. Dec. Supp. Syst. 2(1), 39-47. Raghunathan S (1990) An artificial intelligence approach to the formulation and maintenance of models. Unpublished doctoral dissertation, University of Pittsburgh, Pa. Sen A, Vinze A and Liou SF (1994) Construction of a moel formulation consultant: the AEROBA experience. IEEE Trans. Syst. Man Cybernet. 22(5). Sklar MM and Pick RA (1990) A knowledge engineered linear programming formulation assistant. In Proceedings of the Twenty-Third Annual Hawaii Int. Conf. on System Sci., Vol. III, Decision Support and Knowledge Based Systems Track, pp. 269-278. Smith G F (1989) Defining managerial problems: a framework for prescriptive theorizing. Mgmt Sci. 35(8), 963-981. Professor Arun Sen, College of Business Administration, Texas A&M University, College Station, TX 77843-4217, USA.
ADDRESS FOR CORRF~PONDENCE:
0305-0483/93 $6.00+0.00 Copyright © 1993 Pergamon Press Ltd
Use of Reason Maintenance in Model Formulation AS BHARADWAJ A SEN AS VINZE Texas A&M University, College Station, Texas, USA (Received November 1991; in revised form June 1992) Studies of the process of model formulation by experts have shown the process to be an iterative one, in which the model is continuously refined until a complete and consistent representation emerges. It is also a highly unstable activity as the problem specifications, including the goal, may change both during and after the formulation. In order to be able to model real world problems, model formulation systems, which provide computer-based support for model formulation, should also be capable of dealing with changes to the problem. This paper presents the architecture of a model formulation system enhanced with reason maintenance capabilities, for dealing with changes in assumptions and specifications during formulation.
Key words--artificial intelligence, modeling
1. INTRODUCTION MANAGERIAL PROBLEM SOLVING has been an active research area for several decades. The term problem solving encompasses two distinct phases: the problem formulation phase and the problem solution phase [20]. The problem formulation phase consists of the tasks of problem identification, problem definition and problem structuring. This activity is regarded as highly knowledge intensive, with various cognitive processes such as perception, conceptualization, planning and reasoning coming into play. The classical management science approach to problem solving is to construct a mathematical model for the problem as a set of equations and then to solve the model using standard algorithmic procedures. This stream of research has traditionally focused its efforts on the development of new and improved algorithms for computerized model solving [6, 7]. The front-end task of model formulation, recognized as requir-
ing a high degree of cognitive skills continued to be performed manually with little computer support. Recent research efforts, however, have focused on providing computer-based support for model formulation, leading to the construction of model formulation systems [1, 10, 11, 16-18]. In these systems, the problem description is elicited from the user, usually through friendly interfaces that allow high-level qualitative descriptions of the problem. Formulation proceeds in an incremental manner until all the information is obtained, and the system is able to construct a mathematical representation. Two problems implicit in the current approaches to model formulation are monotonicity and atomicity. The monotonicity problem leads a system to assume that all of its current information is true and that truths never change. The formulation system's reasoning process therefore only consists of augmenting its current information with additional 123
124
Bharadwaj et al.--Reason Maintenance in Model Formulation
information derived through explicit inference rules. If the new information conflicts with the old, the system cannot handle it. For example, if the system believes that factory A produces product A, and later the user indicates that factory A is closed due to a fire in the premises, the system cannot reconcile the new information. It would continue to believe that product A is still manufactured at the factory. The related problem of atomicity leads the formulation system to view each piece of information as an isolated statement related to other beliefs ~ only through explicit semantic relationships. Since the semantics of beliefs are usually not explicitly represented, the system cannot handle any incremental changes to its current set of beliefs. Thus, repercussions of any new information provided to the system is ignored by it. In contrast to this behavior, we find that human experts when formulating models, constantly check and revise their assumptions and other deduced facts. This task is performed implicitly by humans, and hence the problem of maintaining internal consistency is easily solved. In order for model formulation systems to be able to handle real world problems, they must be capable of making dynamic adjustments in response to changing scenarios. Even if the problem scenario remains unchanged, the user may wish to model hypothetical problem scenarios by changing some of the problem specifications. A stream of research in artificial intelligence (AI) deals exactly with the aforementioned problem. This research stream attempts to develop systems which can handle changing environments and contexts. These systems, called reason maintenance systems2 (RMS), maintain dependencies between the facts stored in the system's knowledge-base. Changes to the knowledge-base are propagated throughout the system and the effect of the changes is communicated to the problem solver system. Thus, by incorporating an RMS with a model formulation system, the objective of making dynamic adjustments to the model in response to changes in problem specifications can be achieved. iT he term 'belief' in knowledge-base systems represents all the data that the system takes to be 'true'. Generally, in model formulation systems, the data supplied by the user and the new data inferred from the inference rules, represent the system's beliefs. 2These systems are also referred to as truth maintenance systems in the literature.
This paper describes a model formulation system enhanced with reason maintenance capabilities. Specifically, the architecture and implementation details of such a system are presented. The reason maintenance capability allows the system to handle changes to assumptions and/or problem specifications. The remainder of the paper is organized as follows. In the next section, we provide a broad overview of the literature on model formulation, reason maintenance and their interaction. Section 3 provides details of the actual process of model formulation as observed from a protocol analysis conducted as part of the study. The cognitive aspects of expert reason maintenance gleaned from the protocol analysis forms the basis for the system architecture described in Section 4. Finally, the paper is concluded in Section 5. 2. MODEL FORMULATION AND REASON MAINTENANCE: AN OVERVIEW
Model formulation is an intellectual process, that transforms a problem situation into a specific mathematical representation. The process by which human experts formulate models in different problem domains has been studied, using protocols of expert verbalizations [17-19]. These studies indicate that formulation is an iterative process, in which the model is continuously refined until a complete and consistent representation emerges. It is also a highly unstable activity, as the problem specifications, including the goal, may change both during and after formulation. Summarizing the research in model formulation and model revision the following points can be made: Changes to problem specifications occur constantly and are unavoidable. They may be avoided at the cost of building a model for the wrong problem, or at best building an inadequate model that ignores salient aspects of the problem. Changes to the problem occur due to a number of reasons. Some of the changes may be uncontrollable, dictated by changes in the environment. Other changes may be introduced by the modeler for (i) revising mistaken assumptions made earlier in the formulation; (ii) simplifying the problem to make it more tractable; (iii) enriching the
Omega, Vol. 21, No. 1
problem to make it more complex and realistic; and (iv) for studying alternate scenarios to choose the best alternative for the problem. • Changes to one aspect of a problem often impacts other parts of the problem leading to substantial revisions in the entire problem space. The changes may also contradict some of the current aspects of the problem making the entire representation inconsistent. • Expert human modelers have implicit mechanisms for handling changes to the problem specifications. They can reason with new knowledge and revise past beliefs/ knowledge in a way that makes the problem representation internally consistent. In spite of these observations, very few attempts have been made by the DSS community to build systems capable of dealing with changes to problem specifications. A few notable exceptions are discussed in a subsequent section. As noted earlier, the AI community has been actively pursuing research in this area under the broad label of truth maintenance or reason maintenance. We briefly describe the functionality of reason maintenance systems next. 2.1 Reason maintenance systems In any reasoning system, such as an expert or a knowledge-base system, the problem solver makes inferences (or reasons) based on the facts provided to it. These facts represent the beliefs of the system. Typically, the beliefs influence each other and are always assumed to be true by the system, that is, the system assumes that the state of the world does not change during the reasoning process. Thus, if a piece of information is retracted, or if some new information is added that contradicts a previous belief, the system cannot revise its beliefs accordingly. For example, suppose the model formulation system has the following simple rule: If (product X is shipped from region A to region B) Then (product X is available in region B) Let us further assume that the user has asserted that product X is shipped from region A to
2IME 21 I--1
125
region B. The system now has two beliefs (a) product X is shipped from region A to region B and (b) product X is available in region B. But suppose the user later retracts the assertion that product X is shipped from region A to region B. The system will however continue to believe the inferred fact product X is available in region B, without suitably retracting or modifying it. One of the functions of a reason maintenance system is to enable a problem solver to suitably alter its beliefs about the state of the world in response to new information, i.e. perform belief revision. A reason maintenance system was first introduced by Doyle [4] in the late seventies, and since then there has been an explosion of interest in these systems in the AI community. A reason maintenance system serves as a house-keeping subsystem of an overall reasoning system. The problem solver passes to the RMS the inference it makes, and the RMS uses the structure of these inferences to organize the beliefs of the problem solver. By interrogating the RMS the problem solver receives feed-back about what it believes. The form of the interaction between the two systems usually varies, but typically the RMS would provide information about the beliefs on which inconsistencies rest and the set of mutually consistent beliefs with which to work [9]. Thus, in the above example, the model formulator would pass both the asserted datum and the inferred fact to the RMS which would record the fact that product X is shipped from region A to region B as the reason for believing that product X is available in region B. The primary task of an RMS is to maintain a set of beliefs in such a way that (i) they are not known to be contradicting and (ii) no belief is kept without a reason [14]. An RMS works by constructing a dependency network of all the facts represented in the knowledge-base. Whenever a new fact is introduced in the knowledgebase, not only the fact but also the reasons for believing the fact are recorded. Thus, every fact (represented as a node in the dependency network) has a list of justification nodes. These are the other facts that support a given fact. Whenever a fact (say A) is retracted, all other facts which have A on their justification lists also have to be retracted or modified. Likewise, the justification network of A has to be traced backwards to see which other facts do not hold in the revised context.
126
Bharadwaj et al.--Reason Maintenance in Model Formulation
The RMS is by itself not a problem-solving system. All the facts and justifications have to be provided by the problem-solving system. It is only a supporting system that records and maintains the dependency network of the facts. By keeping the RMS independent of the problem-solving system, it can be used for any problem-domain and also with any type of problem-solving system. 2.2 Use of reason maintenance in operations research
Reason maintenance has been used for solving certain design problems in operations research (OR). The design problem consists of assigning permissable values to a set of design variables in order to maximize (or minimize) an objective stated in terms of such variables [15]. An example of a general class of design problems in OR, that have been solved with AI techniques are the constraint satisfaction problems (CSP) [2]. A CSP is characterized by a finite number of choice sets and a set of constraints defined over the choice sets. A solution to a CSP is a combination of alternatives, one from each choice set, such that together they satisfy each of the constraints. Dhar [2] shows how RMS provide an ideal mechanism for managing the reasoning process in solving CSPs. The RMS is used for analyzing the repercussions of making incremental changes such as tightening or relaxing of constraints. A more specific example of the use of RMS for a design problem is presented in [15]. In their system the authors combine optimization algorithms with heuristic methods for designing communication networks. A blackboard data structure is used to store the current state of the network design as it evolves, and is accessible by interacting knowledge sources. An RMS records the justifications for choices leading to the current design state, as well as for promising alternatives that are not selected by the system. A dependency-directed backtracking procedure works in conjunction with the RMS to choose other promising alternatives, when a current partial design turns out to be infeasible. The only previous implementation of an RMS with a model formulation system is described in [17]. In their system called MODFORM, designed for formulating LP models in the production planning domain, the
authors incorporate a reason maintenance component called BMS (belief maintenane system) for performing model revisions. The BMS is used as a computational tool, to support revisions of beliefs held by the formulation system. It keeps track of the justifications and the justificands for every belief that is represented in the system. The basic operations supported by the BMS are addition of a node (belief), deletion of a node, and verifying whether a node is valid in a particular context. The BMS allows the user to explore multiple contexts, and keep track of the beliefs that are valid in each context. Thus, different versions of the same problem can be treated as multiple contexts with varying sets of assumptions in each context. In this system, the dependencies between the model components are captured at the instance level, rather than at the schema level, resulting in large and cumbersome dependency networks. 3. M O D E L FORMULATION P R O C E S S
In order to understand the modeling process adopted by experts, a protocol analysis of the formulation process was conducted. Linear programming problems from the production planning domain were assigned to three experts, who were asked to formulate the corresponding models. They were also instructed to verbalize their thought processes as they proceeded with the formulation. The expert verbalizations were recorded and analyzed to understand the cognitive processes that came into play during formulation. The analysis provided an understanding of the overall reasoning and control strategies adopted by experts during the formulation process. The protocols of the experts' verbalizations revealed that the experts adopted an opportunistic approach to model formulation. This was in contrast to past findings which have suggested other approaches such as the hierarchical [17] and analogical [12] approaches to model formulation. The opportunistic approach to model formulation, suggests that rather than having a well-defined plan of action, the expert exploits the intermediate decisions and observations to guide the formulation process. For example, the expert may have proceeded to the problem analysis phase, when he/she discovers that some more information is required about the problem. At the stage the expert goes back
Omega, Vol. 21, No. 1
to the problem understanding phase, and may even re-read the whole problem. Opportunism was evident from the rapid and dramatic shifts in the experts focus of attention during the entire process. The protocol analysis also indicated that during the formulation process, experts tend to make certain critical assumptions that enable them to proceed with the formulation. These assumptions, usually referred to as default assumptions, 3 were often made when the expert thought that he/she had incomplete information about the problem. However, in certain situations the default assumptions turned out to be wrong. This happened whenever the experts focused too quickly on a particular aspect of the problem, sometimes even before the problem was fully read and comprehended. The protocol analysis further revealed that default assumptions were also frequently made when the experts had standard expectations as a result of their prior experience with similar problems. For example, one of the problems assigned to the experts was a multi-commodity transportation problem. This problem differed from other standard problems in this class, in that it did not have any supply constraints. However, two of the three experts to whom this problem was assigned, first assumed that each producing region had supply constraints. In this case, the default assumption turned out to be wrong, and the experts realizing this at a later stage, retracted the default. When experts retracted any assumption, they always checked the other aspects of the model that they had previously formulated to ensure that their formulation was consistent with the new information. This revealed to us that experts were implicitly performing reason maintenance in order to come up with the correct formulations. Details of the protocol analysis and a description of the findings have been presented in [13].
4. S Y S T E M A R C H I T E C T U R E
The cognitive aspects of the expert model formulation process, identified from the protocol analysis, guided the design of the model 3The term 'default assumptions' is used in AI to describe standard or routine assumptions that humans make especially when faced with incomplete information.
127
formulation system. The primary design consideration, focusing on the process of model formulation, suggested that the system must be capable of exhibiting opportunism. Hence, the opportunistic planning paradigm was chosen as the appropriate model for constructing the system [8]. The blackboard architecture has been found to be a suitable representation for implementing an opportunistic model [5]. The blackboard architecture uses two basic components: knowledge sources and a blackboard data structure. The knowledge-base is partitioned into independent chunks of knowledge called the knowledge sources (KS). These are specialists, and may be viewed as mini expert systems that focus on different aspects of the problem. The blackboard is a global data-base on which all the problem-solving knowledge is represented. Typically, the KSs interact in an opportunistic manner to incrementally develop the solution on the blackboard. Our system adopts the blackboard architecture for model formulation. The next major consideration in designing the system was to implement reason maintenance capabilities, in order to enhance the capability of the system to deal with real world complexities. As indicated earlier, the protocol analysis suggested that human experts constantly and implicitly perform reason maintenance. This feature is essential in a model formulation system to ensure consistency of the knowledge-base and correctness of the formulated model. A modular approach to system construction was adopted. In the first phase of system development, a model formulation system without reason maintenance capabilities was developed. This system, called AEROBA (an entity relationship oriented blackboard architecture), uses the blackboard framework to construct LP models in the production planning domain. A brief overview of the AEROBA system is presented here (for a more complete description of the system see [18]).
4.1 An overview of AEROBA The AEROBA system uses a blackboard comprising of two panels, for operationalizing the cognitive model of formulation observed through protocol analysis. The problem panel is used to store problem related information in a structured manner. The representation of information is based on a data model called the
128
Bharadwaj et al.--Reason Maintenance in Model Formulation sl.name
A,,ri
sl.cap sl.tot.sh.qty
sh.name sh.cost
sh.qty sh.tot.cost
dl.name dl.ra( dl.tot.sh.qty
ute-,eve,
Relationship-level
Entity-level
/
Demand-location
Supply-location
Domain-level
Transportation
Basic-level
sl.name sl.cap sl.tot.sh.qty sh.name sh.cost
: supply-location-name : supply-capacity : supply-total-shipment-qty : shipment-name : shipment-cost
sh.qty sh.tot.cost dl.name dl.req dl.tot.sh.qty
: shipment-qty : shipment-total-cost : demand-location-name : demand-location-requirement : demand-tot-shipment-qty
Fig. 1. Problem panel representation for a general transportation problem.
extended entity relational model (EERD), proposed by the designers of AEROBA [18]. As the system elicits information interactively from the user, it incrementally constructs an EERD model of the problem on the problem panel. An example of a problem panel representation of a generic transportation problem is presented in Fig. 1. Based on the model structure that evolves on the problem panel, the solution panel is used to bring an appropriate tool template (for example, linear programming template) for formalizing the model into a standard (LP) structure. The tool template is then instantiated with the problem data to come up with the algebraic formulation for the given problem. Assisting AEROBA in all the knowledgeintensive tasks, such as problem type identification, tool selection etc., are multiple specialists called knowledge sources. The knowledge sources contain domain-dependent modeling knowledge and are programmed to be stimulated by, and respond to the information that is posted on the blackboard. The knowledge sources are controlled by an opportunistic control mechanism that monitors and polls the knowledge sources for contribution. In each cycle of operation, the knowledge source which has the highest potential contribution to the formulation process is selected to respond. In
this manner, the process continues until the model is fully formulated. The basic data item in the blackboard is called a solution element (SE). A solution element is implemented as a frame data structure with several slots carrying related information. The solution element corresponds to the various component types that are identified in the EERD data model. Some of the important EERD components are described below. (The complete definitions and examples of all EERD components can be found in [18].) • An entity refers to a physical object in the problem, such as a resource or a plant. A relationship represents an association between entities. For example, shipping is a relationship between a plant and a warehouse. Data attribute, denoted by da, refers to user specified values or parameters, such as shipping-rate-per-unit. Derived attribute, denoted by dr, refers to attribute values that are derived internally using some specified function. For example, shipment-cost is derived
Omega, Vol. 21, No. 1
from shipping-quantity and shipping-rateper-unit. • Action attribute, denoted by ac, refers to the variables or the unknown values in the model. An example of a solution element from the problem panel of Fig. 1 is: Slot-name SE-NAME SE-TYPE OWNER
Slot-value
Remarks
(SUPPLY-CAPACITY) (DATA) (SUPPLY-LOC)
4.2 Extending A E R O B A
data attribute; parent entity is supply location
with an R M S c o m -
ponent
In designing an RMS, the overall structure of AEROBA was used to come up with a representation structure for model dependencies. Next, using the knowledge about dependencies, highlevel algorithms for propagation of changes through the dependency structure were developed. The adequacy of the representation structure, and the correctness of the algorithms were tested, by taking an example problem and applying the RMS to reasons with various model related changes The RMS component is designed to exploit the E E R D structure of the model, and uses the solution elements to explicitly represent the model related dependencies. Our RMS is based on De Kleer's assumption based truth maintenance system (ATMS) [3]. The ATMS design allows the representation of multiple environments simultaneously. Each environment is characterized by a unique set of assumptions. Thus, different versions of the same problem can be represented as separate environments. This provides the user with the flexibility to simultaneously explore different versions of the same problem and to switch from one version to another quickly. For example, in formulating a model for a production planning problem the user may assume that a certain part is manufactured in-house and represent the model accordingly. In a different version of the same problem, the user may wish to explore the resulting changes if the part were to be purchased from an outside source. Figure 2 represents the architecture for AEROBA with reason maintenance. The multilayered problem and solution panels are used
129
for creating different model versions. Each layer represents a version or context with the topmost layer representing the current or the latest version. Each layer is uniquely identified by a label and all the solution elements that are active in that environment will carry this label in one of the slots specially marked for this purpose. If the user explores an alternate scenario, where some data item (solution element) is deleted, then the solution element and all other related solution elements will become inactive in the new environment. The use of labels for specifying the environments helps the model formulator identify the relevant solution elements for the new version. The changed E E R D for the new version can be constructed as a new layer in the problem and solution panels. The control process in the enhanced system, not only schedules the knowledge sources, but also triggers the RMS, whenever the user makes a change to the model. A typical RMS works by constructing a node for every problem solver datum. A node is similar to frame data structure with multiple slots attached to it. For example, in the ATMS, each node consists of a justification slot, a justificand slot, a label slot and a contradictory slot. The justification slot comprises of all the other nodes that together justify
Blackboard
,v3 Iv2
[ v3
I v2
Iv1 l
Iv1
V0
vo
Problem panel
/ Knowledge sources
Solution panel
I
Control mechanism
\ Reason I maintenance system
Fig. 2. Architecture of AEROBA with reason maintenance
Bharadwaj et al.--Reason Maintenance in Model Formulation
130
the current node. For example, if node P represents the fact product X is available in region B, and node Q represents the fact product X is shipped from region A to region B, then the justification slot for node P will contain node Q indicating that P is justified by Q. The justificand slot of any node represents all other nodes that are justified by the current node. Thus, in the above example, the justificand slot of node Q will contain node P, indicating that node Q justifies node P. The label slot identifies the environments associated with that node, and the contradictory slot which contains a single bit to indicate if the datum represented by the node is contradictory. In our design, rather than introduce a new data type for the RMS node, we extended the representation of each solution element frame with the following additional slots: Justification slot. For a given solution element SEx, this slot will contain a list of other solution Slot-name
Slot-value
SE-NAME SE-TYPE OWNER JUSTIFICATION JUSTIFICAND DEL-BIT LABEL
Remarks
(SUPPLY-CAPACITY) (DATA) (SUPPLY-LOC) (SUPPLY-LOC) (STK-AVA1L-CONST5 NULL (V0,V 1
data attribute; parent entity is supply location; justified by existence of the solution element supply location; justifies the constraint solution element--stock availability; currently a valid solution element; this solution element is valid in environments V0 and VI
elements that justify SEx. The justification slot can be empty, indicating that it is a premise justification. A premise justification is one that is always valid and consequently a solution element that contains a premise justification is one that does not depend on other SEs for its existence, i.e. the SE can exist independently. For example, all entities asserted by the user, such as plants, warehouses etc., will have premise justifications since entities can exist independently. A justification list of the form {(SEI,SE2)} represents a conjunction of justifications, and indicates that both SE~ and SE2 are needed for justifying SEx. A justification list of the form {(SEI)(SE2) } represents a disjunction of justifications and indicates that either SE~ or SE2 alone is sufficient to justify SEx. More SE-ID SE-NAME TYPE JUSTIFICATION JUSTIFICAND EXPRESSION DEL-BIT LABEL
complex justification structures can be obtained by combining these rules. Justificand slot. For a given solution element SE x, this is a list of other solution elements that are justified by SEx. If a solution element is deleted, then all the consequences of the deleted solution element are obtained from the justificand slot, and are recursively deleted, if necessary, until a consistent set of solution elements emerge. Label slot. For a given solution element SE x, this slot indicates all the environments in which SE x is valid. A solution element is valid in a context, if it has a valid set of justifications, i.e. every SE in its justification slot are themselves valid. Delete-bit. This is a single bit which is set to 0 if the solution element is invalid or deleted in a given context. Thus, using the extended representation the solution element for SL.CAP will be as follows:
Apart from the solution element types allowed in the original AEROBA system, two additional types of RMS solution elements called the function type and the constraint type were introduced. Examples of these two types of solution elements are shown below. These types are necessary, because in a given problem situation, many solution elements may be linked to each other through constraint or function expressions. Dependencies are established through constraints and functions, and these dependencies have to be tracked to ensure that changes are propagated correctly. For example, suppose there is a constraint on supply capacity at each supply center. This would be represented through a constraint-type solution element as follows:
:CI : STOCK-AVAIL-CONS; constraint on stock availability : CONSTRAINT (co) : {(SUPPLY-CAPACITY, SUPPLY-QUANTITYS}
:{}
: SUPPLY-QUANTITY < SUPPLY-CAPACITY : NULL : V0,V1
Omega, Vol. 21, No. 1
The constraint C1 represents the link between SUPPLY-CAPACITY and SUPPLY-QUANT I T Y through its justification slot. The solution elements S T O C K - A V A I L A B L E and SUPPLYQ U A N T I T Y would in turn have C1 in their respective justificand slots. Thus, if STOCKAVAILABLE is removed from the problem panel, indicating that a supply center no longer produces goods, the justificand slot of STOCKAVAILABLE would indicate that it justifies constraint C1. The reason maintenance algorithm will trace and remove C1 as it would no longer be a relevant constrain for that problem. Dependencies between attributes, expressed through functions, are handled differently. For example, consider the following function node F1, expressing the function SUPPLY-SALESV A L U E = (SUPPLY-QTY * SALE-PRICE):
131
information is ignored. Users may inadvertently add information that is inconsistent with the current data, or retract some crucial assumption, thereby making the whole structure inconsistent. With the inclusion of an RMS component, the system required a more complex control scheme that would allow it to accept modifications from the user and construct revised models. Users may add, modify or delete solution elements or justifications to solution elements. Whenever any of these happen, the control mechanism has to invoke the appropriate RMS algorithm for dealing with the change. The RMS algorithms are designed to carry out the necessary sequence of changes to ensure overall model consistency. For example, if the user adds a solution element SE~, the RMS
SE-ID: F1 SE-NAME: SUPPLY-SALES-VALUE; TYPE: FUNCTION (fn) JUSTIFICATION: {<~SALE-PRICE, SUPPLY-QTY)} JUSTIFICAND: {(SUPPLY-SALES-VALUE)} EXPRESSION: SUPPLY-SALES-VALUE = (SALE-PRICE*SUPPLY-QTY) DEL-BIT: LABEL: V0.V1
SALE-PRICE and SUPPLY-QTY are attributes of S U P P L Y - L O C A T I O N and justify the function node F1, which in turn justifies the solution element SUPPLY-SALES-VALUE. In this way dependencies between the participating attributes and the functions are recorded. Whenever an attribute that participates in a function is removed, the justification set of the corresponding function is checked and other related attributes are also deleted. Thus, if the entity S U P P L Y - L O C A T I O N is removed, its attributes will be removed first, and through their justificand slots, function F1 and the SUPPLY-SALES-VALUE node will also be deleted, indicating that there can be no sales from that supply center. In this way, all changes can be propagated correctly.
would ask the user to specify the justification for SEx, and then verify the existence of those solution elements. These must in turn specify SE x in their justificand slots. For example, when the solution element SHIPPED is added to the problem panel, the solution elements SUPPLY.LOC and D E M A N D . L O C would have to be specified as the justification for SHIPPED (see Fig. 1). In the case of a delete operation, the RMS algorithm would delete the particular SE and then recursively delete all the justificands of the deleted SEs until a consistent subset of the original model is derived. If the user wishes to preserve the original model, he/she may specify that a new version be created. In this case, the RMS will assign a label to the new environment and create a new layer in the problem and solution panels.
4.3 Control scheme for A E R O B A with an R M S
AEROBA uses a control scheme that is based on opportunism. This allows for a flexible control mechanism that can switch focus and problem-solving approach based on the incoming information. However, while the new information is exploited from a control point of view, its impact on the existing
4.4 The RMS algorithms The operations of the RMS would include adding a solution element, deleting a solution element, adding a justification and deleting a justification. In this section, we provide high level algorithms for adding or deleting solution elements. Modification operations can be
132
Bharadwaj et al.--Reason Maintenance in Model Formulation
handled by a combination of delete and add operations. Solution elements are added to the ap propriate level on the blackboard by the various knowledge sources. Whenever a new solution element is added, control invokes the RMS algorithm ADD-SOLUTION-ELEMENT. The procedure ADD-SOLUTION-ELEMENT(SEx), first verifies if this is a totally new SE or is one that had been previously deleted. This is necessary because, users may sometimes reinsert an assumption that they had previously deleted. In this case, since the SE is already present with its delete-bit set to 0, the RMS only has to reset it to 1, and verify if all its justifications are still valid. Procedure ADD-SOLUTION-ELEMENT(SEx, SE-data, justifications, justificands) begin If SEx exist and delete-bit = 0 then set delete-bit = 1 else add SEx to the appropriate level in the problem panel; For V justification SEj e SEx do; get corresponding SEj and verify if SEx belongs to its justificand slot; For V justificand SEc ~ SEx do; call procedure ADD-JUSTIFICATION(SEe, SEx); end Deleting a solution element involves, propagating the changes recursively through the entire EERD structure Procedure DELETE-SOLUTIONELEMENT(SEx) begin Set delete-bit of SEx = 0; For V SEj~justification slot of SEx do; call REMOVE-JUSTIFICATION(SEj, SEx); For V SEcejustificand slot of SEx do; call DELETE-SOLUTION-ELEMENT(SEe); end 4.5 M o d e l revisions
With the RMS component, AEROBA can be used to systematically deal with many types of
model revisions. For example, suppose in the transportation problem of Fig. 1, the shipment activity is removed. Tracing the justificands of SHIP progressively, the attributes associated with SHIP, namely SHIPMENT-NAME, SHIPMENT-COST, SHIPMENT-QTY and SHIPMENT-TOT-COST would first be removed from the problem panel. Since, the solution element SHIPMENT-QTY is linked to the solution element DEMAND-QTY in entity DEMAND-LOCATION through a constraint node (shipment-qty/>demand-qty), the latter also gets removed from the problem panel. The revised EERD for the problem is shown in Fig. 3. In our approach, the justification links between the various solution elements are maintained at the model schema level, rather than at the model instance level. In this way, the dependencies between the solution elements for even large problems can be easily represented. However, modifications at the instance level (for example, closing of a particular supply center) can be handled by identifying all the solution elements linked to that particular supply center through its key attribute value (SUPPLYLOCATION-NAME). The corresponding instances of the dependent solution elements will be suitably modified. 5. CONCLUSION This paper presented an approach for reason maintenance in model formulation systems. Reason maintenance was shown to be necessary for handling the real world complexities of model formulation. The paper discussed the incorporation of an RMS component to a blackboard based model formulation system. Future research will focus on the application of reason maintenance techniques for model integration. Formulation of large and complex problems would demand the integration of several smaller models. For model integration to be successful a more systematic study of the assumptions underlying each model and the problem of assumption violations across multiple models is necessary. Dependencies between entire models and not just model components will have to be maintained and verified each time the models are integrated. Since any given model can potentially be combined with many different models, a complex network of dependencies will
Omega, Vol. 21, No. I
sl.name
133
dl.name dl.req
sl.cap sl.tot.sh.qty
Attribute-level~ r~ Relationship-level ~
I,,,O0,-,oca,,oo I
Entity-level
I Demand-location I Transportation
Domain-level Basic-level sl.name : supply-location-name sl.cap : supply-capacity sl.tot.sh.qty : supply-total-shipment-qty
dl.name dl.req
: demand-location-name : demand-location-requirement
Fig. 3. Revised problem representation for the transportation problem.
have to be established. The scenario can be further complicated if multiple users maintain different versions of each model. Reasons maintenance techniques can be used for building appropriate links between the different model versions and for maintaining overall consistency in the model base.
11. 12.
13.
REFERENCES 14. 1. Binbasioglu M and Jarke M (1986) Domain specific D S S tools for knowledge-based model building. Dec. Supp. Syst. 2(3), 213-223. 2. Dhar V (1989) A truth maintenance system for supporting constraint-based reasoning. Dec. Supp. Syst. 5(4), 379-387. 3. De Kleer J (1986) Problem solving with the ATMS. Artific. Intell. 28(2), 197-224. 4. Doyle J (1979) A truth maintenance system. Artific. IntelL 12(3), 231-272. 5. Engelmore RS, Morgan AJ and Nil HP (1988) Introduction to blackboard systems. In Blackboard Systems (Edited by Englemore RS and Morgan AJ). AddisonWesley, Reading, Mass. 6. Fourer R (1983) Modeling languages and matrix generators for linear programming. A C M Trans. mathl Software 9(2), 153-183. 7. Geoffrion AM (1987) An introduction to structured modeling. Mgmt Sci. 33(5), 547-588. 8. Hayes-Roth B and Hayes-Roth F (1979) A cognitive model of planning. Cognitive Sci. 3, 275-310. 9. Kelleher G and Smith BM (1988) A brief introduction to reason maintenance systems. In Reason Maintenance Systems and their Applications. Horwood, Chichester. 10. Krishnan R (1989) PDM: a knowledge-based tool for model construction. In Proceedings of the TwentySecond Annual Hawaii Int. Conf. on System Sci., Vol.
15. 16. 17.
18. 19.
20.
llI, Decision Support and Knowledge Based Systems Track, pp. 467-474. Liang TP and Jones CV (1988) Meta-design considerations in developing model management systems. Decn Sci. 19(1), 72-91. Liang TP (1990) Problem similarity, modeling by analogy and their roles in model management systems. In Proceedings of the First Systems Conf. for Decision Support Systems. Austin, Tex., pp. 405-421. Liou ST (1992) Aeroba: a control blackboard approach for model formulation. Unpublished doctoral dissertation, Texas A&M University, Tex. Martins JP (1991) The truth, the whole truth, and nothing but the truth: an indexed bibliography to the literature of truth maintenance systems. Artific. lntell. Special Issue, 7 25. Mitra S (1990) AI/OR hybrid methods in telecommunication network design. Unpublished doctoral dissertation, University of Iowa, Iowa. Murphy FH and Stohr EA (1986) An intelligent system for formulating linear programs. Dec. Supp. Syst. 2(1), 39-47. Raghunathan S (1990) An artificial intelligence approach to the formulation and maintenance of models. Unpublished doctoral dissertation, University of Pittsburgh, Pa. Sen A, Vinze A and Liou SF (1994) Construction of a moel formulation consultant: the AEROBA experience. IEEE Trans. Syst. Man Cybernet. 22(5). Sklar MM and Pick RA (1990) A knowledge engineered linear programming formulation assistant. In Proceedings of the Twenty-Third Annual Hawaii Int. Conf. on System Sci., Vol. III, Decision Support and Knowledge Based Systems Track, pp. 269-278. Smith G F (1989) Defining managerial problems: a framework for prescriptive theorizing. Mgmt Sci. 35(8), 963-981. Professor Arun Sen, College of Business Administration, Texas A&M University, College Station, TX 77843-4217, USA.
ADDRESS FOR CORRF~PONDENCE: