Conflict Resolution in Cooperative Design1 Mark Klein Department of Computer Science University of Illinois 1304 W. Springfield Urbana, IL 61801
[email protected] Stephen C-Y. Lu Department of Mechanical and Industrial Engineering University of Illinois 142 Mechanical Engineering Urbana, IL 61801
[email protected] Abstract Complex modern-day artifacts are designed by groups of experts, each with their own areas of expertise. Current approaches to group design are often serial and iterative in nature, which can be time-consuming as well as leading to poor designs that are expensive to realize. New models for cooperative group design, which emphasize the parallel interaction of the design experts involved, are needed. A central issue in cooperative group design concerns how conflicts among different experts can be resolved as the design is being produced. This paper proposes a model for how such conflict resolution can take place, and describes the results of a study aimed at verifying and instantiating this model by examining conflict resolution among human experts in the domain of architectural design. The study yielded four main conclusions: (1) conflict resolution plays a central role in cooperative design, (2) a rich collection of domain-independent conflict resolution expertise can be identified, (3) we need to represent the design rationale to support conflict resolution, and (4) knowledge acquisition in cooperative design presents special challenges and requires special techniques. We include a description of the conflict resolution expertise we uncovered. Key Words: group design, cooperative design, conflict resolution, simultaneous engineering 1. Introduction Design is a problem solving activity based on multiple and diverse sources of expertise. Currently, it is often accomplished by a group of experts asserting and critiquing partial design decisions from their local perspectives in a roughly sequential manner. This process is very time-consuming and often leads to poor designs that are expensive to realize. Better design models and associated computer tools are needed. These new models and tools should support parallel rather than sequential interactions among different design sources of expertise. Our research is aimed at developing such cooperative design models, and at implementing computer tools based on these models to support cooperative design with human and machine-based participants.
1 Appears in The International Journal For Artificial Intelligence in Engineering. Volume 4, Number 4, Pages 168-
180, 1990.
-1-
One critical component of a cooperative design model is a theory of how conflicts among the different sources of expertise can be detected and resolved. While conflict-free cooperation among multiple sources of expertise has been well-studied, cooperation when conflict can occur is less well-understood. Existing approaches to conflict resolution in knowledge based systems suffer from a number of limitations, including slowed knowledge-base development, reduced comprehensibility and extensibility, and limited expressiveness in the representation for conflict resolution expertise. In this paper we propose a model of run-time conflict resolution in cooperative design that we believe has advantages over existing conflict resolution approaches. It is based on the notions that conflict resolution expertise can be captured explicitly, and in addition can be organized usefully into a taxonomy of conflict classes and associated conflict resolution strategies. This theory is supported and instantiated in a study, described herein, that examines conflict resolution among human experts in the domain of architectural design. The study consisted in essence of recording the activity of architects engaged in the design of a home, and then analyzing it to gain insights into the cooperative design process in general, as well as conflict resolution in particular. The study yielded four main conclusions: (1) conflict resolution appears to play a central role in cooperative design, (2) a rich collection of domain-independent conflict resolution expertise can be identified, (3) we need to represent the design rationale to support conflict resolution, and (4) knowledge acquisition in cooperative design presents special challenges and requires special techniques. We would like to make some comments concerning the intended scope of this work. Conflict situations can be divided into two categories: competitive conflict situations and cooperative conflict situations. In competitive situations each party has solely their own benefit in mind and has no interest in achieving a globally optimal situation if such a solution provides them no added personal benefit. In cooperative situations, the parties are united by the superordinate goal of achieving a globally optimal solution, which often requires sacrificing personal benefit in the interest of increased global benefit. Strategies for competitive conflict situations include hiding information from the adversary, making threats, and so on. Strategies for cooperative conflict situations typically involve techniques, such as compromise or abandonment of less important goals, oriented towards finding as mutually beneficial a solution as possible. Our theory is oriented strictly towards cooperative conflict resolution, since that is appropriate for cooperative design where the shared goal of producing the best possible product exists. An important aspect of some conflict situations in human settings is psychological factors such as degree of trust and liking among the participants, the need to preserve self-esteem, the perceived relative social status of the participants, and so on. While important, these issues are often orthogonal to issues concerning objective benefit to the participants. In this work we choose to ignore such psychological factors. Our work is aimed initially at producing a model of conflict resolution that is suitable for use with machine-based participants, which do not face these issues. As for the study itself; although it provides interesting insights into human problem solving, its aim is to help us develop computational models of cooperative design. In addition, although the detection of conflict is also an important part of a cooperative design system, it was not examined in our study. Our focus was on what took place after the human experts had detected the conflicts. For a discussion of conflict detection in a cooperative design system, see [Klein]. The remainder of this paper is organized as follows. We begin by describing the importance of good theories of cooperative design, and highlight the central role conflict resolution must play in such theories. We then critically review previous work on conflict resolution, and present a model of conflict resolution that we believe avoids important limitations in existing approaches. With this background in place, we present a study that supports and instantiates our conflict resolution model. The study involved observing and analyzing cooperative design performed by experts in the architectural design domain. We consider the nature of the architectural design domain, how the -2-
study was performed, and the results. The paper then concludes with a discussion of the significance of our research results, as well as the possibilities for future research. 2. Why Cooperative Design?
Design Engineer
Redesign Request
Manufacturing Engineer
Production Plan
Blueprints
Marketing Expert
Specifications
Design is a problem solving activity that is based on multiple sources of expertise. For example, design of an electric fan may require experts on properties of materials, ease of manufacturability, kinds of available gears, blades and motors, potential markets for the fan, and so on. As a result, the product development process is often distributed amongst a team of engineers, each with different responsibilities and expertise. Product development often advances serially in this framework. For example, specifications produced by marketing experts may be sent to design engineers, who produce a complete design for a product that is then sent to manufacturing engineers so they can create a production plan. (figure 2).
Redesign Request
Figure 2: Current Approach to Group Design Many time-consuming iterations are often required, normally at later stages in the design, to resolve conflicts between early and later design decisions. Several iterations may be required before a design that satisfies both sources of expertise is produced. More often, the number of design iterations is limited to save time, resulting in a design that is poor from the perspective of experts later on in the design process. The fundamental problem is that design commitments are made by experts early on in the design process without consulting experts later on in the design process; if these commitments produce grave problems for these later experts, a conflict has occurred and we are forced to iterate in order to resolve it. Improved product development practices are needed. These new practices must be able to simultaneously incorporate and integrate a wide spectrum of product concerns. This requires parallel interaction, instead of serial iteration, amongst the various product development concerns. 3. Conflict Resolution in Cooperative Design Resolving conflicts is a critical requirement for a cooperative design system that realizes parallel interaction among different sources of expertise. Since the participants in a cooperative design activity generally have different perspectives (e.g. different goals, different ways of achieving similar goals, etc), they will occasionally come into conflict concerning some aspect of the design. One design agent may specify that a given part have a particular shape to maximize strength, while another may specify a different shape that simplifies the operations needed to machine the part. In human design teams, the participants will usually then utilize conflict resolution strategies they have developed over the course of their working lives to produce a design that is satisfactory with respect to the different sources of expertise represented on the design team. Not all conflicts may be discovered at design time, of course; some may only become apparent when the product is actually built and used.
-3-
In this section we will review existing research related to conflict resolution in cooperative problem solving. This can be divided into work oriented towards developing computational models for design/planning systems, as well as work oriented towards creating models of human conflict resolution behavior. We consider both groups in the sections below. 3.1. Computational Models Computational models of conflict resolution range over a spectrum that can be divided into five categories: (1) development time conflict resolution, (2) backtracking-based failure handling, (3) numerically-weighted constraint relaxation, (4) specific conflict resolution advice, and (5) general conflict resolution expertise. These categories vary in the extent to which conflict resolution expertise is made explicit and available for use during run time. Development-Time Conflict Resolution: Traditional knowledge-based systems rely on all of the potential conflicts between different perspectives being resolved at development time [bezem-87], [nguyen-85], [suwa-82]. The conflict resolution knowledge utilized by the experts is then implicit in the individual conflict resolution decisions made during development. While this approach can be used in cooperative problem solving systems, there are a number of advantages to allowing conflicts among knowledge sources to be detected and resolved at run time using explicitly represented conflict resolution strategies. Reduced Development Time: Resolving all conflicts, no matter how unlikely, at development time can be prohibitively time-consuming [bezem-87]. Dividing the domain knowledge into smaller internally consistent collections according to domain of expertise, and using run-time strategies to mediate conflicts among KSs should reduce the need for exhaustive developmenttime consistency checking. In practice, only a portion of all possible conflicts are likely to actually occur for a specific design task. Improved Comprehensibility: Run time conflict resolution allows us to maintain the different expertises, as originally produced by the human domain experts, in separate knowledge sources. This makes it easier for a domain expert to modify a knowledge source at a later time. If all conflict is resolved at development time, we have in effect replaced these multiple expertises by a single one that is difficult for any one domain expert to understand or modify. Increased Extensibility: We can add new expertises to the design system without having to resolve, at development time, all the conflicts that may arise among the knowledge sources. Run-time conflict resolution thus helps insure the independence of the expertises in a complex knowledge-based system. Increased Flexibility: When conflicts are resolved at run time instead of development time, we have flexibility in the choice of which conflict resolution strategy we use. We can, in fact, use conflict resolution knowledge added to the system after the knowledge sources were originally developed. Involving Human Problem Solvers: Among the most compelling reasons for using run time conflict resolution concerns the role of humans in design systems that include both human and machine-based design agents. It is not practical to expect the human participants to have resolved all potential conflicts before they participate in the design system's operation. The use of run-time conflict resolution strategies constitutes a better model of how cooperative design in human design teams takes place, and thus provides a more natural framework for systems with human and automated participants.
-4-
The fundamental advantage of run-time conflict resolution, then, is that it constitutes a more realistic model of cooperative problem solving than does run-time conflict resolution, both in the sense of constituting a better model of human group problem solving, as well as in the sense of reducing the complexity of the individual design agents to more manageable levels. Run-time conflict resolution has been studied in a variety of contexts and implemented using a variety of techniques. We review this literature in the section below. Backtracking-Based Failure Handling: Conflict resolution in non-distributed design and planning systems is generally known as failure processing. In backtracking-based failure handling, when conflicting design commitments are made, the control flow is traced backwards to some decision point, and some previously untried alternative is chosen. Systems of this class include [doyle-80, Chan-Paulson-87, sussman-82]. This approach suffers from the drawback that the backtracking is done without the guidance of domain-specific conflict resolution knowledge. As a result, excessive amounts of backtracking may needed before a conflict resolution is found, and there is no guarantee that the resolution found is in any way optimal. Numerically-Weighted Constraint Relaxation: Systems that perform conflict resolution based on numerically-weighted constraint relaxation include the ISIS system for factory scheduling [fox-84] and the GARI system for producing plans for manufacturing parts [descotte-85]. These approaches rely on assigning static numerical weights to different constraints on the final design. When constraints come into conflict, the systems attempt to find the set of admissible constraint relaxations that minimizes the reduction in the total constraint weights. While this approach has shown some success, it suffers problems analogous to those exhibited by other numerical weighting approaches, such as plausibility factors [duda-79]. These problems include: Acquisition: Human experts find it unnatural to express conflict resolution expertise using a numerical formalism. Consistency: If the constraint weights are derived from multiple experts, we can not be sure that the different experts used the same semantics when assigning the weights. Modifiability: Changing the desired conflict resolution behavior in a design system can require coordinated changes to a potentially large set of constraint weights. Explainability: The reasoning behind a given conflict resolution decision can only be expressed in terms of constraint weights, rather than in terms of the domain entities used to explain design commitments. This makes these conflict resolution decisions more difficult to understand. Context Dependence: The importance of a given constraint may vary with the situation, but the use of a single numerical value commits us to a single context-independent evaluation. This makes it difficult to capture situations where the importance of a given constraint is contextdependent, i.e. is determined by an interaction among the participating constraints. Weights given to constraints represent an extremely condensed shorthand for expertise that is usually expressed in terms of entities and operations in the task domain. They, therefore, can be a restrictive and unnatural language for expressing such expertise. In general, numerical weighting approaches have only an indirect relation to the factors (e.g. cost, reliability, production delays) and strategies (e.g. satisfy most important subset of goals) that people seem to use in resolving conflicts. Specific Conflict Resolution Advice: Systems in this class store collections of specific contextindependent conflict resolution advice to handle failures encountered during the design process. -5-
Systems in this class include the AIR-CYL [Brown-85] and VT [Marcus-87] design systems. This approach has the advantage of applying explicitly identified conflict resolution knowledge to the resolution of conflicts. It does suffer from a number of limitations, however, including limited ability to express conflict resolution expertise (e.g. context-dependent actions or general strategies). The BARGAINER personal scheduling system [Goldstein-75] is a more powerful instance of this class where a limited set of fairly general conflict resolution strategies is used to resolve conflicts. All these systems, however, represent conflict resolution expertise using a different and less powerful formalism than that used for domain expertise. In addition, these systems are all hypothesis and test type systems. This leads to conflicts that could have been avoided by the use of a least-commitment approach. A related point is that these systems do not make use of an abstraction space of designs to allow conflict detection while the design is still at an abstract level; conflicts can only be detected at the level of a detailed design or plan. In general, we can view this class of systems as one in which conflict resolution expertise is made more explicit, but is still given second class status. General Conflict Resolution Expertise: Systems in this class represent and reason with conflict resolution expertise using the same mechanisms used for domain expertise (i.e. conflict resolution is given "first class" status), and attempt to capture general conflict resolution principles as well as specific instantiations of these principles tailored to particular conflicts. As a result, many of the disadvantages with the other approaches described above are avoided. The conflict resolution model proposed in this paper fits into this category. A proposal for a system of this type is described in [wilensky-83]. Wilensky's instantiation of this approach, however, does not constitute a comprehensive theory of conflict resolution. Little conflict resolution knowledge applicable to cooperative conflict situations is described. There is considerable discussion of competitive conflict situations, but this is mostly irrelevant to a cooperative design system. In addition, the work leaves unspecified many important details concerning how the conflictresolution mechanism might actually be realized. Finally, this work has not been applied to cooperative planning or design tasks. Hewitt [hewitt-86] has also proposed a model of intelligent behaviour based on the interaction of conflicting internally consistent "microtheories", but his work contains essentially no discussion of how this interaction would be managed, i.e. how conflicts would be detected or resolved. 3.2. Models of Human Conflict Resolution There has been a large amount of research concerning the resolution of conflicts that occur between individuals or groups of individuals in contexts such as business, jurisprudence, international relations, and so on. This work, unfortunately, often has only tangential relevance to conflict resolution in cooperative design among machine-based agents. Much of the work on models of human conflict resolution has focused on competitive conflict ([Pruitt-81], [Coombs-88], [SycaraCyranski-85] [Wilensky-83]) which is usually irrelevant to cooperative design situations. In addition, a preponderance of this work addresses issues specific to the psychology of human participants [Pruitt-81] [Feldman-85] [Fisher-81]. Finally, work on human conflict resolution assumes of course that the individuals have high-level cognitive skills, and focuses on such issues as organizing the agenda of interaction among the participants to ensure that all conflicts are considered (see, for example [Fisher-81] [Carey-88]). As a result, the level of description of conflict resolution expertise is much higher than appropriate for machine-based design agents. Given these provisos, there are areas of fruitful overlap between the literature on human conflict resolution and our work on conflict resolution for cooperative design systems. Many principles of human conflict resolution can be incorporated into cooperative design models, such as the use of limits on concession levels, the strategy of logrolling (trading concessions on low-priority issues until both parties are satisfied), and the notion of integrative agreements where a novel solution is found that resolves or alleviates the conflict [Pruitt-81].
-6-
3.3. Summing Up There are two fairly distinct literatures relevant to our work on conflict resolution in cooperative design: work on computational models of conflict resolution, and studies of conflict resolution in human settings. The work on computational models represents and uses conflict resolution expertise in a restrictive way, and/or represents very little of it. This work also does not consider conflict resolution issues specific to cooperative design domains with heterogeneous design agents, i.e. differences in the agents' implementational formalisms, differing semantics for numeric weights, differing susceptibility to having conflict compiled out (e.g. humans vs machines), and the need to match existing decompositions of expertise to increase comprehensibility to the human experts. Studies of human conflict resolution describe a varied collection of conflict resolution strategies (albeit much of it oriented towards competitive conflict and/or purely psychological issues) but do not express it in a way suitable for incorporation in a computational model. 4. Our Approach to Conflict Resolution Our approach to conflict resolution is based on two important tenets: (1) conflict resolution expertise can be captured explicitly, and (2) conflict resolution expertise can be organized. We discuss these tenets in the paragraphs below. Capturing Conflict Resolution Expertise: The first basic tenet of our work is that conflict resolution represents an important kind of expertise used by designers in the process of group design. Accordingly, it can and should be captured explicitly and declaratively as a separate form of metaknowledge. We can view this as an attempt to further the evolution of knowledge-based systems towards greater use of explicitly encoded expertise to guide problem solving (figure 6). Approach
Knowledge Types Distinguished
conventional programming language
data procedure
traditional expert systems
data domain knowledge control knowledge
our approach
data domain knowledge control knowledge conflict resolution knowledge
Figure 6: Evolution in Problem Solving Systems Being able to represent separately and explicitly the different kinds of knowledge involved in problem solving has resulted in increases in the flexibility and generality of the problem solving process. Our own work attempts to take this one step beyond traditional expert systems by explicitly encoding and utilizing a class of knowledge heretofore represented only implicitly or using restrictive formalisms; namely, conflict resolution strategies. Organizing Conflict Resolution Expertise: The second basic tenet is that conflict resolution expertise can be organized for effective use. In particular, we believe that the different kinds of
-7-
Efficiency
DomainIndependent
DomainDependent
Applicability
conflicts can be arranged into an abstraction hierarchy of conflict classes, and that we can associate applicable conflict resolution strategies with each conflict class. More general classes of conflict appear near the top of this conflict hierarchy, and more specific classes near the bottom (figure 7).
Figure 7: A Conflict Hierarchy The more abstract classes represent domain-independent classes and associated strategies, while the more specific classes apply only to particular domains. Conflict resolution strategies associated with more specific conflict classes will have a narrower range of applicability but usually greater efficiency than the more general strategies associated with abstract conflict classes. An important advantage of this hierarchical arrangement is that it allows us to determine the range of conflict resolution strategies applicable to a given conflict. When a conflict occurs, we can find the most specific conflict class that subsumes that conflict, and try the conflict resolution strategies associated with that class. If none of these strategies are successful, we can climb the hierarchy to the next conflict class and try the more general if less efficient strategies associated with that class. A related advantage is that a conflict hierarchy can be useful even if one has not encoded specific strategies for every conflict that can occur. If there is no specific conflict class for that particular conflict, one can find the first more or less abstract conflict class that covers that kind of conflict. Of course, the conflict resolution strategies associated with that conflict class may be quite difficult and time-consuming to apply. For example, our conflict hierarchy can trivially handle all possible conflicts by having a single completely general conflict class that includes conflict resolution heuristics like "try all possible designs till a non-conflicting one occurs", or "ask a human expert" [Mayer]. Our hope, of course, is that we can add enough more specific conflict classes and strategies to avoid the use of such expensive general strategies. The domain-dependent portion of the conflict hierarchy can be generated when the design system is developed, based on knowledge acquisition from domain experts. This portion can be developed just once and then applied to a wide variety of domains. The domain-dependent part, of course, needs to be created anew for each substantially new domain. The conflict hierarchy can be changed or added to, of course, at a later time. The conflict hierarchy is designed to play the following role in a cooperative design system:
-8-
Design Agent
Resolutions
Conflict Resolution Expert Conflict Hierarchy
Conflicts
Design Agent
Shared Representation
Design Agent
= critiques and design updates Figure #: Role of Conflict Hierarchy in Cooperative Design System Design agents cooperate by updating a shared representation of the design, and by critiquing design commitments made by other design agents. When a conflict is detected (either by noting two incompatible design commitments, or when a design agent has a negative critique of another agent's actions), a description of this conflict is given to a conflict resolution expert which uses the conflict hierarchy to find a resolution for the conflict. In the remainder of this paper we describe the study we undertook to verify the above-described model of conflict resolution, as well as instantiate it by collecting a body of conflict resolution expertise. 5. Knowledge Acquisition In The Architecture Domain The domain we chose was the design of homes by a group of architects. Home design is a complex process that involves several different kinds of expertise, including expertise concerning aesthetics, functionality (e.g. floor space or privacy), and maximal energy efficiency. This division of expertise is well-recognized in the architectural literature. It is not uncommon for architects to cooperate when producing a design, so experienced architects will generally have well-developed skills for engaging in cooperative design. These characteristics (a complex design task, an existing decomposition of expertise, and well-developed group design skills) make the architecture domain an excellent one for the purpose of studying cooperative design. The goal statement we set for ourselves was to design an aesthetic, habitable and energy-efficient home within budgetary and other client-defined constraints. The second author served the role of the client; the home was designed to fit onto the site of his current home, and to be consonant with his needs. The site is located in central Illinois. We were fortunate to be able to work with three highly qualified architects; Michael J. Andrejasich, Donald E. Bergeson, and Robert I. Selby, all practicing architects who also serve as professors in the Architecture Department of the University of Illinois. Though we initially assigned each of them a particular role in the design process (form, energy, and function, respectively), they were all knowledgeable enough to represent each of the areas of expertise. The architects were asked to work on the design of the house just as they always do, except that they were asked to verbalize their thought processes as much as possible while working. The sessions were tape-recorded, and all drawings produced by the architects were kept. The role of
-9-
the interviewer was limited to asking for clarification on the meaning of technical terms, asking what role the experts were representing at a given time, and occasionally encouraging the architects to describe the goals they were pursuing at that point in the design process. The recorded sessions were then transcribed. The resulting design transcript was presented to the architects to ensure that it represented an accurate history of the design process. 6. Analyses Our analysis of the design transcript was divided into two parts. The first part studied the kinds of inputs made during the design process, while the second part studied in particular those inputs concerning conflict identification and resolution.. We consider these two parts in the sections below. 6.1. Inputs to the Design Process The design process consisted of two major stages; a "needs assessment" stage in which the clients needs were uncovered, followed by the actual design of the house. The information required by the architects in the needs assessment stage was quite extensive, and included the building budget, site profile, street location, family privacy needs, and so on. Our analysis of the needs assessment stage was limited to recording the different questions asked by the architects. The first step of our analysis of the house design per se was to reduce the design transcript into design statements, each representing a single irreducible contribution to the design. Once this reduction was done, we grouped these statements into categories describing their role in the design process. This "protocol analysis" stage is similar to that utilized in other empirical studies of the design process, such as [ullman-dietterich-stauffer-88]. We identified six categories of statements: 1. commit: A tentative design commitment made by an expert. This involves the addition of some design detail to an existing design state to produce a new design state. 2. pro: An identification of a positive aspect of a design by an expert. This involves noting that a given design state satisfies one or more of the goals of a given expert. 3. con: A identification of a negative aspect of a design by an expert. This involves noting a conflict between the design state and the goals of a given expert. 4. res: A list of suggestions concerning how to resolve a conflict. A conflict resolution is thus a kind of design commitment. 5. goal: A description of a goal that a given expert is currently trying to achieve. 6. note: A comment made by an expert that does not relate specifically to the current design, probably for pedagogical purposes. The expertise responsible for producing each design statement was identified. In addition to the domain-specific sources of expertise form (aesthetics), function, and energy we noted that some statements represent input from a domain-independent global expertise that checks for violation of constraints derived from the client's initial specifications (e.g. budget, floor area, lot geometry). Though it may seem strange that four different sources of expertise should be represented by only three human participants, recall that each of the human participants are capable of playing, and in fact often did play, several roles in the design process.
- 10 -
We call the result of this analysis into categorized statements the design protocol . An excerpt of the design protocol is given below (figure 11). commit
Locate house at front of lot.
function
pro
Maximizes backyard size, which is good for privacy of the backyard, providing play areas for kid and entertainment areas for adults.
energy
note
Illinois has a permissive and temperate climate in terms of energy use, so house orientation is less critical. However, rotating the house long axis much more than 15% away from true south significantly reduces the amount of solar energy usable by home.
energy
con
EW orientation may provide too much south facing glass and thus too much of a cooling load in the summer.
energy
res
Use triple glazing, extra insulation, reduce south-facing glazing, shading devices to reduce insolation from high summer sun.
energy
goal
We want to maximize the opportunities for solar insolation here.
form commit
Instantiate standard floor plan for second story of house. Stairs
form
Closet Bedroom
Two-story Closet Open Space Bedroom corridor Bed/Bath
Figure 11: Excerpt from Design Protocol The design protocol includes a number of diagrams that represent the current design. All further analyses were based on this protocol, rather than the transcript. Tabulation of the number of design statements produced for each expertise and statement type revealed the following pattern: energy form function global TOTAL
commit 8 16 8 2 34
pro 21 8 32 0 61
con 8 10 29 3 50
res 21 12 5 0 38
goal 9 0 6 0 15
note 1 0 0 0 1
TOTAL 68 46 80 5 199
Perhaps the most striking feature of this data is the relative proportions of design commitments, critiquing statements and conflict resolution statements (Figure 12).
- 11 -
commit pro
Statement Type
con res goal note 0
20
40
60
80
Number Figure 12: Statement Type Counts There are actually more critiquing statements (positive and negative) as well as more conflict resolution statements than there are design commitments. This is particularly striking when we consider that each "res" statement usually contained several candidate resolutions. This suggests that critiquing and conflict resolution plays a substantial role in the architectural design process. Another interesting aspect of the design protocol was that design commitments usually involved instantiation of default templates, such as standard floor plans, rather than novel designs created from scratch to suit the particular clients' needs. We will return to both these points later. The next step in our analysis was to capture the control flow of the design process. The architects considered many aspects of many alternative designs, producing a branchy "search space" not made explicit by the linear structure of the design protocol. Accordingly, we produced a design flow chart whose nodes represent design states. Figure 13 gives a sample design flow chart. Design State 0 Commit
Commit
Design State 2
Design State 1 Con
Design State 3
Con
Design State 4 Res
Design State 5 Figure 13: Sample Design Flow Chart There are three kinds of arcs in this flow chart. The role of each of the arc is described in the table below: - 12 -
Arc Type commit
Role design commitment
con
conflict identification
res
conflict resolution
Description Adds detail to a consistent state to produce a new consistent design state. Takes a consistent design state and produces an inconsistent design state. Takes an inconsistent design state and produces a consistent design state.
Note that the arcs extending from a given node do not necessarily represent mutually exclusive design alternatives, since they may represent, for example, two different conflicts involving the same design state. The design flow chart we produced is given in figure 16 below.
Figure 16: Design Flow Chart There were a total of 125 design states, of which 63 were leaf states (design states from which no arcs extend). The average branching factor from a design state was 2, and the average depth of a path from the root state to a leaf state was 7. The branching factor tended to get somewhat smaller as the depth of the nodes in the design flow chart increased, but this was not very significant statistically (correlation = -0.3). The distributions of the depth and branching factors are given in figure 17.
- 13 -
Number of Paths
Number of Nodes
70 60 50 40 30 20 10 0
0
3 6 9 12 Branching Factor
20 15 10 5 4
7
10 13 Depth
16
Figure 17: Distributions of Depths and Branching Factors In general it appears that a lot of alternatives were explored, usually to moderate depth. Though not all of the branching represents mutually exclusive alternatives, there were nevertheless multiple candidate designs active for much of the design process. 6.2. Conflict Resolution For the conflict resolution analysis we began by collecting all the conflicts that occurred in the design protocol (i.e. every "con" statement), as well as other conflicts that did not but could have occured during home design. We were able to identify more than 60 conflicts, of which 50 were derived directly from the design protocol and the remainder were generated by us. There were roughly 200 specific conflict resolution suggestions associated with these conflicts (about four suggestions per conflict). The conflicts occurred exclusively between pairs of sources of expertise, so we were able to arrange them into a table where the first column was a statement made by an expertise, the second was a contradictory statement made by an expertise, and the third column included one or more potential resolutions of that conflict. The expertise that produced each of the contradictory statements was identified, as well as the expertise that suggested the resolution, when that was unambiguous. Two examples are included below: Expertise 1 Expertise 2 Resolution function: orient house along NS on energy: E or Worient side of house lot; maximizes EW; presents available function: large south-facing lawn orient house areaalong for solar heating EW and move to N or S end of lot to maximize available lawn area energy: use heavier insulation to minimize energy loss and thus solar heating needs energy: remove trees; allows clearfunction: sky-domepreserve to maximize significant solar energy surrounding energy: collection try vegetation; an forenergy-saving direct-gain privacy systems reasons alternative that is less affected by the shadows made by the trees, such as celestories, skylights, or super-insulation We then studied this table with the goals of identifying (1) what classes of conflicts occurred, (2) what responses the human experts typically had to the conflicts, and (3) what strategies were used - 14 -
when the experts attempted to resolve the conflicts. We consider each of these points in the section below. 6.2.1. Conflict Classes We were able to arrange the conflicts we encountered into a conflict class hierarchy (figure 18). The way we did this was by identifying what domain-independent conflict class every conflict instance belonged to. We then arranged the conflict classes into a hierarchy according to the subsumption relationships that existed among them, and generated new classes when appropriate by generalizing from existing classes. This hierarchy is by no means comprehensive; it merely represents a way of organizing the conflicts we encountered during the process we observed. All Conflicts
Objections by Critics Global Expert
Conflicting Recommendations
Domain Expert
Numerical Resource Constraint Limit Violated Exceeded Anticipated Usage
Shallow Model Functional Constraint Violated
Actual Usage
Worst Likely Budget Case Usage for Usage Total Design
Differing Local Maxima
Default Assumptions
Number Valued Feature
One Side Flexible
Both Sides Flexible
Budget for Design Subtask
Figure 18: Conflict Class Hierarchy We include below a description of the conflict classes we identified. This description includes a definition of each class, as well as examples of strategies that can be used to resolve conflicts for that class. Since some of the classes were created by generalization, not all of the classes have strategies included with them. A complete listing of the conflict resolution strategies we identified will be presented later on in this paper. 1. Conflicting Recommendations: two experts independently make inconsistent recommendations concerning a design feature. 1.1. Shallow Model: one of the recommendations is based on a shallow model that is inaccurate for the current situation [Chandresekaran-83]. If the model had been accurate, the conflict would not have occurred. Strategy: remove recommendations not supported by the deep model. 1.2. Default Assumptions: one of the recommendations is based on an unchecked default assumption that is inappropriate for the current situation. If the assumption had been warranted, the conflict would not have occurred. An example of a logic based on
- 15 -
defaulted assumptions is given in [Michalski-86]. Strategy: remove recommendations with invalid default assumptions. 1.3. Differing Local Maxima: the conflicting sources of expertise have different optimal values for a given design feature. Strategies: compromise, add detailing that satisfies both sources of expertise. 1.3.1. Number-Valued Feature: The design feature disagreed over is numbervalued. Strategies: numerical optimization using a common yardstick, or taking the average of conflicting values. 1.3.1.1. Both Sides Flexible: Both sources of expertise involved in the conflict are able to change somewhat the asked-for value for the design feature. Strategy: express the tradeoff as a mathematical equation and present to the user. 1.3.1.2. One Side Fixed: One of the sources of expertise involved has no room for changes. Strategies: change the flexible side till it meets the inflexible side. 2. Objection by Critic: one expertise makes a design commitment that another expertise has an objection to. Strategies: abandon the goal supporting the critiqued action, try an alternate plan for the critiqued goal, or add a plan to satisfy the threatened goal. 2.1. Domain Expertise: The criticism comes from a domain-specific expertise. 2.2. Global Expertise: The criticism comes from the global expertise. 2.2.1. Functional Constraint Violated: The critiqued action violates a constraint specifying that the design support a given function. 2.2.2. Numerical Constraint Violated: The critiques action violates a constraint constraining a number-valued design feature. 2.2.3. Resource Limit Exceeded: The critiqued action uses/is likely to use too much of a given resource. Strategy: use a less resource intensive plan to achieve the goal supporting the critiqued action. 2.2.3.1. Actual Usage: the actual resource use of the critiqued design action exceeds the resource budget. 2.2.3.1.1. Budget for Design Subtask: the resource use budget for the critiqued subtask is exceeded. Strategy: take some of the resource allotted to another subtask budget. 2.2.3.1.2. Budget for Total Design: the total budget for the resource is exceeded. 2.2.3.2. Anticipated Usage: the estimated resource use for the critiqued design action exceeds the amount available. 2.2.3.2.1. Likely Usage: The estimate is based on the likely usage of the resource. 2.2.3.2.2. Worst Case Usage: The estimate is based on the worst case usage of the resource. Once a conflict has occurred we are faced with the task of deciding how to respond. A description of the responses to conflict is given in the following section. 6.2.2. Responses to Conflict We were able to identify two major groupings of responses to conflict: responses to anticipated conflicts, and responses to actual conflict. Anticipated conflicts occur when the design state did not, but could potentially, violate goals held by one of the sources of expertise. Responses to anticipated conflicts include: Potential Resolution Suggested: An expert indicates that a conflict resolution strategy is potentially available. The role of this kind of assertion may be to ensure that we do not explore a design path that may lead to a difficult-to-resolve design conflict. - 16 -
Avoid Conflict: This kind of assertion adds a constraint to the design in an attempt to guide future design actions so that the anticipated conflict is avoided. Reminder to Consider Conflict Later: An expert simply reminds the other experts that this conflict is one that will probably have to be dealt with later on. Actual conflicts occur when a design state currently violates the goals for an expertise. Responses to actual conflicts include: Resolution Provided: An expert provides a resolution for the conflict, allowing work to continue on the design. No Resolution Provided: Abandon: The experts provide no resolution for the conflict and remove the design state from further consideration. No Resolution Provided: Evaluate: The sources of expertise wait to see how many conflicts are produced by each of several design options, in order to determine which option elicits the fewest significant conflicts and thus looks most promising. The experts thus had a range of options when they encountered a conflict. In the following section we consider the strategies they use when they attempted to resolve a conflict, be it actual or anticipated. 6.2.3. Conflict Resolution Strategies The conflict resolution strategies we identified could also be arranged into a hierarchy. Note that this does not constitute a conflict class hierarchy, but is merely a convenient way of arranging a large collection of conflict resolution strategies. We generated this hierarchy the same way we generated the conflict class hierarchy, i.e., by identifying the domain-independent strategies underlying every conflict resolution instance, arranging the strategies according to the subsumption relationships that hold among them, and creating new strategy descriptions by generalization when appropriate. In the listing below we describe each conflict resolution strategy, and also indicate when necessary the applicability conditions for that strategy. As with the conflict class hierarchy, we make no claim of comprehensiveness; this listing merely represents the strategies encountered in our particular study. 1. Abandon Goal: Abandon one of the goals involved in the conflict. This is appropriate if the goals, rather than just the plans implementing them, conflict inherently. 1.1. Abandon Goal Justifying Action: Abandon the goal justifying a design action. This is appropriate when we want to (1) reduce use of a resource (abandon the goal justifying the plan that uses that resource); (2) resolve conflicting recommendations (abandon a goal justifying one of the conflicting recommendations); (3) resolve a negative critique of a design action (abandon the goal that justifies the critiqued design action). 1.1.1. If Preconditions Invalid: Abandon the goal if its defaulted preconditions are invalid. This is appropriate when default logics are used. 1.1.2. If Invalidated by Deep Model Check: Abandon the goal if not supported by the deep model. This is appropriate when shallow models are used. 1.1.3. If Much Less Important: Abandon the goal if it is much less important. 1.1.4. If Supported by a Tentative Commitment: Abandon the goal if it supported only by a tentative design commitment. - 17 -
1.1.5. If Client Says So: Ask the client whether to abandon the goal. Only appropriate of the client has the technical expertise to make a good decision. 1.1.6. Try Both and Evaluate: Explore the consequences of abandoning each goal in a different assumption context, and evaluate which goal abandonment lead to a more satisfactory resolution. 1.2. Abandon Goal Justifying a Critique: Abandon the implicit threatened goal justifying the negative critique. 1.2.1. If Preconditions Invalid: Abandon the goal supporting the critique if the defaulted preconditions for that goal are not true. 1.2.2. If Invalidated by Deep Model Check: Abandon the goal supporting the critique if it is not supported by the deep model. 1.2.3. If Much Less Important: Abandon the goal supporting the critique if it is much less important than the goal supporting the critiqued design action. 1.2.4. If Client Says So: Abandon the goal if the client says so. 2. Try Alternate: Find an alternate way of satisfying a goal. This is appropriate when alternatives exist for satisfying the goal. 2.1. Alternate Plan: Find an alternate plan for a goal. 2.1.1. For Critiqued Action: Find an alternate plan for a goal justifying a critiqued design action that no longer threatens the goal justifying the critique. 2.1.1.1. Less Resource Intensive Plan: Find a plan that uses less of the resource that the threatened goal wishes to preserve. 2.1.2. For Conflicting Recommendations: Find an alternate plan for satisfying a goal justifying one of the conflicting recommendations. 2.1.2.1. Consistent with Existing Constraints: The alternate plan does not conflict with existing constraints on the design. 2.1.2.2. Inconsistent with Existing Constraints: The alternate plan conflicts with existing constraints on the design. 2.2. Alternate Subgoal: Replace the goal justifying a design action with an alternate subgoal for satisfying the higher level design goal involved. This is appropriate when the higher level goal has several viable subgoals. 3. Add Detailing: Add detail to the design so that the conflict no longer exists. 3.1. To Satisfy Threatened Goal: Find a plan to satisfy the threatened goal justifying the negative critique of a design action. 3.1.1. Inconsistent With Critiqued Action: Find a plan for the threatened goal that is inconsistent with the critiqued action. 3.1.2. Consistent with Critiqued Action: Find a plan for the threatened goal that is consistent with the critiqued action. 3.1.2.1. Alleviate Resource Shortage: Find a plan that satisfies the threatened goal by alleviating the shortage of a limited resource. 3.1.2.1.1. Make More of Resource Available: Find a plan that makes more of the resource available. 3.1.2.1.2. Reduce Use of Resource: Find a plan that reduces the use of the resource. 3.1.2.1.2.1. Use Less: Find a plan that reduces the amount of resource consumed. 3.1.2.1.2.2. Goal Overlap: Find a plan that makes a given chunk of resource satisfy several goals that were previously satisfied by separate chunks. 3.1.2.2. Change Number-Valued Feature: Find a plan to increase/decrease the value of a design feature that is too small/big to satisfy the threatened goal. 3.2. Satisfy Goals for Conflicting Recommendations: Add detailing that allows the satisfaction of both the goals justifying conflicting recommendations.
- 18 -
3.2.1. Duplicate Functional Resource: Find a plan that divides the conflicting constraints on a functional resource into mutually consistent sets, and then produce one copy of the resource to satisfy each set of constraints. 4. Partial Goal Fulfillment: Find a compromise where the goals involved in the conflict are satisfied only partially. 4.1. Two-Sided Compromise: Partially satisfy both conflicting goals. This is appropriate when all sides involved have some degree of flexibility. 4.1.1. Establish Tradeoff and Ask Client: Frame the conflict as a tradeoff and allow the client to pick a compromise point that is most satisfactory. 4.1.2. Heuristic: Use a heuristic to find a tradeoff point, such as "find the average of the conflicting constraints on a numeric design feature". 4.1.3. Numeric Optimization: Use numerical optimization techniques. This is appropriate when evaluation functions are available). 4.1.4. Resource Tradeoff: Allocate some of the resources used by one goal to the conflicting goal. This is appropriate when the plans for the conflicting goals both use a limited resource. 4.1.5. Minimize Degree of Goal Violation: Minimize the extent to which one or both goals are violated. 4.1.5.1. Minimize Area: Minimize the spatial area over which the goals are violated. 4.1.5.2. Minimize Time: Minimize the amount of time for which the goals are violated. 4.1.5.3. Most Important Subset: Satisfy the most important subset of the goals. 4.2. One-Sided Compromise: Partially satisfy one of the conflicting goals, and completely satisfy the other. 4.2.1. Penalize Biggest Resource User: Find a plan to partially satisfy the goal that justifies the heavy use of a limited resource in a way that reduces the use of that resource. Many of the conflict resolution strategies listed above can result in secondary conflicts, i.e., in conflicts that are created as a result of the actions taken to resolve the original conflict. This is useful if a difficult-to-resolve conflict is thereby replaced by one easier to resolve. The conflict resolutions suggested by the experts in the architecture domain represented for the most part small changes to the design, most commonly involving the addition of some detailing or the abandonment of the goal justifying a negative critique. 7. Discussion The work described above provided us with several insights into cooperative design: • conflict resolution plays a central role in cooperative design • conflict resolution knowledge can be viewed as a form of problem solving expertise • we need to represent the design rationale to support conflict resolution • knowledge acquisition in cooperative design presents special challenges, and requires additional techniques compared to traditional knowledge acquisition In the sections that follow we will consider each of these points in turn.
- 19 -
7.1. The Central Role of Conflict Resolution in Cooperative Design We noted in the analysis section that design statements associated with the identification and resolution of conflicts figure prominently in the design process. Our work suggests a model for the cooperative design process where conflict resolution plays a central role: 1. The experts generate one or more potential solutions for a given design subtask, usually based on "default" or "standard" solutions for that kind of problem. 2. They then evaluate the design, identifying its pros and cons. Pros are added to the list of reasons for choosing that design. 3. The design is then modified to resolve the conflicts identified. The design process thus appears to be an iterative generate-and-test process, wherein candidate designs are quickly generated using default knowledge, evaluated, and then "tweaked" as needed, in response to conflicts, to make them consonant with each expert's view of the specific demands of the given client. Conflicts, rather than being avoided at all costs, are thus actually an integral part of the design process (figure 19).
Design State
No Make Design Commitment
Done?
Evaluate
Yes
No
Update Rationale
Resolution No Available?
Eliminate State
Conflict Identified? Yes
Stop Successfully
Yes Resolve Conflict
Figure 19: A Design Process Model The advantage of this kind of design is that, rather than having to derive a new design tailored from scratch to the specific needs of a particular client, we can use a relatively small set of default designs and modify them incrementally using conflict resolution to produce a satisfactory design, thereby exploring a smaller search space. In many cases the modifications required are small or easy to make. This is particularly important for domains with large search spaces, where an exhaustive delineation of all the possible designs is likely to be prohibitively expensive.Note that the model described above does not require that there be multiple experts, and thus may be appropriate in a more general context than that of cooperative design. 7.2. Conflict Resolution as Problem Solving Expertise We were able to identify and categorize a rich variety of domain-independent conflict classes and resolution strategies. This supports to the notion that conflict resolution expertise can be represented explicitly apart from domain expertise, and that we can therefore produce a theory of
- 20 -
conflict resolution in cooperative design that is potentially applicable to a wide variety of design domains. Clearly the conflict resolution and conflict strategy hierarchies we have presented are incomplete and perhaps could be organized into a more useful structure, but they serve to illustrate that domain-independent conflict resolution expertise does exist as a separate entity in its own right. 7.3. The Need for Design Rationale A design rationale appears to be a crucial prerequisite for conflict resolution. Many of the conflict resolution strategies described above require that we be able to identify the reasons for given design actions. In addition, we need to be able to determine whether design changes produced by the execution of conflict resolution strategies produce secondary conflicts. The design rationale should include at least three elements for conflict resolution purposes: plan structures, meta-plan structures, and design dependencies. Plan structures represent the links between top-level design goals and design actions. These planning structures can include both links from top-level goals through subgoals and plans to design actions, as well as theme-based links from design states to the goals they threaten or support [Wilensky-83]. An example of a plan structure is given in figure 20 below. Goal
Subgoal-N
Plan-N
Plan-1
Action-1
Action-N
Goal
Plan-1
Action-1
Plan-N
Action-N
State N
Theme
Subgoal-1
State N+1
Figure 20: A Planning Structure Plan structures thus store the reasons justifying a given design choice. Since conflict resolution decisions can themselves lead to secondary conflicts, we need a way to represent the rationale for conflict resolution-based design commitments. To do so we can use a meta-version of the plan structure entities, i.e., meta-themes, meta-goals, meta-plans, and metaactions. This way the same machinery that resolves primary conflicts can be used to resolve secondary conflicts. This meta-rationale would be created as follows. When a conflict occurs, a meta-theme "notices" the conflict and activates a meta-goal to resolve it. A suitable meta-plan is then chosen that executes a number of domain and meta-actions until the conflict is resolved. An example including both domain and conflict resolution rationale is given in figure 21.
- 21 -
Function Goal: Increase Entrance Privacy
Form Goal: Want Clean Modern Lines
Plan: Privacy Detailing on Entrance Theme: Pretentious Additions Action: Add Pillars Surrounding Entrance
Design State N
Design State N+1
Meta-Theme: Theme-Based Conflict Meta-Goal: Resolve Conflict Meta-Plan: Try Modern Pillars
Design State N+2
Meta-Action: Use Modern Pillars
Figure 21: A Design Rationale In the figure above, the design action of adding pillars to the main entrance of the house produces a design state that threatens the form goal of maintaining clean modern lines, based on the theme that pillars generally represent pretentious additions. This conflict is detected by a meta-theme that activates the meta-goal of resolving that conflict. A meta-plan for resolving the conflict is found and executed, leading to the creation of a new design state. Finally, we need a description of the dependencies between design actions so we can determine the consequences of design changes made due to conflict resolution. This allows us to detect secondary conflicts. Design dependencies can be represented using a combination of constraints and truth-maintenance techniques [deKleer-86, Klein]. 7.4. Knowledge Acquisition in Group Design Knowledge acquisition in group design settings faces many of the same challenges as in conventional knowledge acquisition (e.g. ensuring coverage and accuracy). There are however a number of additional challenges that derive from the attempt to glean information about how the experts interact. We list some of our observations concerning knowledge acquisition in group design below: • The experts may each represent several sources of expertise, and change which expertise they represent quite often. • One expertise we may expect to find is a domain-independent "global" expertise that checks for violation of constraints derived from the initial design specifications. • The domain experts sometimes find it hard to separate out individual sources of expertise, presumedly because they are used to trying to incorporate several sources of expertise rather than have to deal with the inefficiencies of serial interaction. It is important to ask experts to be very selfish so they only represent a given expertise at a time. • It is useful to ask the experts to describe their goals from a selfish perspective before each new stage of the design process, so as to clarify what the different sources of expertise are for this stage and what their goals are.
- 22 -
• Ask experts to note out loud whenever a conflict with their goals occurs. Often they will quietly find a resolution to a conflict on their own rather than slow down the design process. While probably an effective strategy for facilitating the group design process, it is unfortunate for the purposes of knowledge acquisition. • It is useful to produce a conflicts list and design protocol with associated design flow chart when analyzing group problem solving. Knowledge acquisition on cooperative design presents special challenges, but can nevertheless be pursued productively. 8. Conclusion We have presented in this paper a model of how conflict resolution can occur in cooperative design. This model is based upon the explicit representation of conflict resolution expertise in the form of a conflict hierarchy. We have performed a study of conflict resolution in the architecture domain with the aim of verifying and instantiating this model. This study proved useful from a number of perspectives. First of all, it highlighted the role of conflict resolution in cooperative design, leading us to propose a model of cooperative design that is centered around the instantiation of default designs followed by theme-based evaluation and conflict-triggered design modification. It provided support for our notion that conflict resolution can usefully be viewed as a separate form of expertise, and allowed us to assemble a substantial collection of domainindependent conflict resolution knowledge. Finally, it provided some guidance concerning useful representations for design rationale, as well as how to conduct knowledge acquisition in group design settings. The study also raised a number of issues, however. One issue is that the associations between the conflict classes and conflict resolution strategies we were able to identify are fairly ad-hoc; it would be preferable to have a strong theory concerning which conflict strategies should be associated with which conflict classes. Though we have a number of ideas (e.g. strategies concerned with alleviating resource shortages should be associated with resource limit violation conflict classes), more work needs to be done in this area. Another issue is that there are often a large number of conflict resolution strategies potentially applicable to any given conflict. A theory that informs the choice among competing candidate strategies is needed. Though we can identify some heuristics for picking strategies (e.g. use the most specific strategy, use resolutions that avoid secondary conflicts), more work is needed in this area as well. In addition, we need to develop of good theory of how relative goal importance and value can be assessed. This is important for the use of strategies like "abandon the less important goal" and "negotiate a compromise that partially satisfies the competing goals". A fundamental prerequisite of such a theory appears to be some kind of common yardstick for comparing the value of more or less completely satisfying different design goals. Resource-based conflicts appear to provide a rich and important source of conflict classes and strategies. This kind of conflict is heavily represented in the architecture design domain, and is likely to be important in many other design domains due to the common problem of limited resources. This is another area that we would like to explore further. Finally, anticipatory conflict detection (and resolution) needs to be looked into. If we can detect impending conflicts early in the design process (before a lot of effort has been devoted to exploring a given design branch) we can either abandon that design branch or make some design decisions now that avoid the conflict and potentially expensive backtracking later on. Our conflict class
- 23 -
hierarchy includes one example of this (anticipated resource limit violation) but we believe that there is probably a greater variety of conflict classes of this type. We have a number of plans for our future work. We would like to explore a new design domain; one different enough to exercise new conflict resolution expertise, and tractable enough to allow development of an actual cooperative design system. This will allow us to further populate and refine our existing conflict class and conflict resolution strategy hierarchies, and serve as a testbed for our evolving theories of cooperative design. We would also like to test whether this conflict resolution expertise can be used effectively in a group including both human and machine-based design experts. We have selected the Local Area Network design domain for this purpose and are currently completing an implementation of a system in this domain. 9. References [Bezem-87] Bezem. Consistency of Rule-Based Expert Systems. Report CS-R8736. Centre for Mathematics and Computer Science. Amsterdam, The Netherlands. July 1987. [Chandresekaran-83] Chandrasekaran & Mittal. Deep versus Compiled Knowledge Approaches to Diagnostic Problem Solving. International Journal of Man-Machine Studies. Pps. 425-436, 1983 [deKleer-86] de Kleer. An Assumption-Based TMS. Artificial Intelligence, Volume 28, Pps, 127162, 1986. [Descotte-85] Descotte & Latombe. Making Compromises among Antagonistic Constraints in a Planner. Artificial Intelligence. Vol 27, 1985. [Duda-79] Duda, Gaschnig & Hart. Model Design in the Prospector Consultant System for Mineral Exploitation. In; Expert Systems in the Microelectronic Age. D. Michie, Ed. 1979. [Fox-84] Fox & Smith. ISIS - A Knowledge-Based System for Factory Scheduling. Expert Systems, July 1984. [Hewitt-1986] C. Hewitt. Offices are Open Systems. ACM Transactions on Office Information Systems. Vol. 4, No. 3, Pps. 271-287, July 1986. [Klein] Klein, M. & Lu, S. C-Y. Run-Time Conflict Resolution in Cooperative Design. Proceedings of the AAAI Workshop on AI in Design, August 24, 1988. In Press. [Mayer] Mayer & Lu. An AI-Based Approach for the Integration of Multiple Sources of Knowledge to Aid Engineering Design. Journal of Transmission, Mechanism, and Automation in Design, AMSE Transactions, to appear. [Michalski-86] Michalski & Winston. Variable Precision Logic. Artificial Intelligence. Vol 29, No 2, August 1986. [Nguyen-85] Nguyen, Perkins, Laffey & Pecorn. Checking an Expert Systems Knowledge Base for Consistency and Completeness. IJCAI-85. Pps 375-378. 1985. [Suwa-82] Suwa, Scott & Shortliffe. An Approach to Verifying Completeness and Consistency in a Rule-Based Expert System. AAAI-82. 1982. [Wilensky-83] Wilensky. Planning and Understanding. Addison-Wesley, Reading, MA. 1983. [Ullman-Dietterich-Stauffer-88] D.G. Ullman, T.G. Dietterich & L.A. Stauffer. A Model of the Mechanical Design Process Based on Empirical Data. AI EDAM. Vol 2, No 1, Pps 33-52. 1988.
- 24 -
