Abstract

The use of AI techniques in developing design programs provides formalisms for representing p r o b l e m -s o l v i n g processes. In this article, the use of AI techniques in modeling design processes is elaborated with the presentation of three models that formalize the representation of design knowledge within a design program. For the purpose of establishing the relevance of the models presented here, a structured approach to the overall process of design is adopted in which the design process comprises three phases: formulation, synthesis, and evaluation. Design formulation involves identifying the requirements and specifications of the design problem. The result of design formulation is sometimes referred to as the design brief or program or, more simply, the definition of the design problem. Design synthesis includes Studies in design methodology provide various structured approaches to the design process. Many books provide definitions and elaborations of the design process: In the structural engineering field, such books include There is a need to The focus in this article is on the synthesis phase. During design synthesis, the form of the design solution is identified. This phase of the design process is not well supported by computer-based tools unless the design problem can be formulated in mathematical terms; for example, optimization techniques are used during synthesis when the design problem can be formulated as an objective function and constraints. The recent use of knowledgebased systems for the synthesis of design descriptions has shown promise and forms the basis for the models described here. Experienced designers resort to trial and error less frequently than novice designers when they synthesize designs, suggesting that the use of knowledge-based systems to represent experithe identification of one or more design solutions consistent with the requirements defined during formulation and any additional requirements identified during synthesis. Design evaluation involves interpreting a partially or completely specified design description for conformance with expected performances. This phase of the design process often includes engineering analysis. Although the phases might not be addressed in the order prescribed for the entire design process and are often carried out recursively, there is an inherent order in which designers approach a design problem. Typically, a designer starts with a definition of the design problem, identifies one or more potential design descriptions, and then evaluates the design. The variation occurs in the revisions of the requirements or descriptions and the iterations of the various phases. The identification of different phases in the design process is a beginning for the formalization and understanding of design. What is missing from such methods is how each phase is completed. The use of a structured approach is acceptable for identifying various ence might aid in synthesizing designs. The major issue then is the explicit representation of design experience in a knowledge base. During design synthesis, a designer considers a design space that contains the knowledge that is used to develop the design solution. A human designer does not need to explicitly identify his(her) design space; it is implicitly developed and expanded as s/he gains experience. A design program, however, does contain an explicit representation of the relevant design space. The nature of the knowledge in the design space must be explicit when considering a knowledge-based approach to design. Simon (1969) presents design as a problemsolving process and, even more specifically, as a search process. The implication of search as a model for design processes is that design knowledge can be expressed as goals and operators. As a general approach to modeling design, search provides a formalism for expressing design knowledge; however, it does not directly address some of the intricacies and idiosyncrasies of design problems. Considering design as problem solving is a beginning to understanding and modeling design, but design problem solving has some additional characteristics that can be exploited by more explicit models. It is interesting to consider the three phases of design as a search process within a design space: Design formulation involves identifying the goal(s) of the design problem. Design synthesis involves the search for one or more design solutions through the selection and application of operators. Design evaluation involves assessing whether the goal(s) have been satisfied. Variations in both the goals and the statespace descriptions as the design process proceeds and the difficulty in predetermining the relevant operators are some of the issues that are not readily addressed in using search for solving design problems. The goals of the problem can change during the problem-solving process, which can indicate a different design space to be searched. One reason design has been difficult to implement as a search process is this change in problem definition during the problem-solving process. One way of dealing with this difficulty is to identify models of the design synthesis process, assuming that formulation has occurred. Another way is to allow synthesis to proceed even with a change of goals. The implication here is that using search as a model for the design process is too general; more specific models that use search in various ways are needed to bridge the gap between a model of design and the eventual representation of design knowledge and experience. The use of AI techniques combined with research in design methodology provides an opportunity to exploit the results of both to produce an understanding of design problem solving. The early efforts in using AI techniques in design resulted in expert systems capable of designing specific artifacts using rule-based approaches. In many cases, the experience in developing rule-based design systems led to the generalization of design problem solving in which the knowledge base was no longer made up of unstructured rules. The justifications for this transition from an unstructured rule base to a design-oriented knowledge base included ease of knowledge acquisition and an increased understanding of design problem solving. Three Models of Design Synthesis In generalizing design problem solving, three distinct models of design synthesis can be identified: decomposition, case-based reasoning, and transformation (figure 1). These models are distinct in their associated formalisms for design knowledge. The models are not necessarily cognitive models; although they might match various approaches humans take when producing design solutions, the correspondence has not 52 AI MAGAZINE been adequately tested. The distinction among the models lies in the representation of design knowledge rather than in their appropriateness for a specific design domain or phase of design. The purpose of identifying more than one design model is in identifying appropriate formalisms for representing design knowledge. Decomposition (figure 2) is perhaps the most ubiquitous model of design. It follows directly from the development of design methodology and has been shown to be useful in the development of knowledgebased design systems. The idea of dividing large complex problems into smaller, less complex problems is well accepted and practiced. It is possible to consider all models of design as some form of decomposition. When we consider a knowledge-based approach to representing design knowledge, the decomposition model has provided a clear position about the type of design knowledge needed. Specific knowledge-based systems for design by decomposition have been developed that identify specific languages for describing design knowledge. Examples of such languages include DSPL Case-based reasoning is a model of design that directly uses design experience in the form of episodes rather than compiles and generalizes it. The model (figure 3) uses analogic reasoning to select and transform specific solutions to previous design problems to be appropriate as solutions for a new design problem. This model is attractive because the knowledge acquisition for developing generalized representations of design knowledge in a particular domain can be difficult and time consuming. The issues associated with using this model for design include the identification of the necessary information about a design episode to reason about its applicability in a different context, the meaning of a similar design, and the transformation of the solution from the original context to the new context. Although human designers appear to be good at using this type of analogy, it is difficult to automate it. Transformation is a holistic approach to design, similar to case-based reasoning, but uses generalizations rather than specific episodes, like decomposition. In the transformation model (figure 4), the design knowledge is expressed as a set of transformational rules in which the left-hand side (LHS) of the rule is replaced by the right-hand side (RHS) of the rule. The most common application of the transformation model is manifested as grammars. The issues associated with using this model are the representation of the design description, the control in selecting an eligible transformational rule, and the termination of the application of rules. In the following subsections, the definition and use of these models are elaborated. Currently, the models are ill defined, and many issues need to be resolved before they can become domain-independent formalisms defined in sufficient detail to be computer environments for knowledge-based design. In addition, examples are presented of systems that have been implemented that use one of the models. The purpose of the following subsections is to illustrate that such models of design are not domain dependent-the examples are drawn from different domainsand that the models provide an understanding of the nature of the design knowledge that needs to be acquired to implement knowledge-based systems for design. Decomposition Decomposition by definition means that something is decomposed; it also implies a recomposition. The early expert systems for design synthesis implicitly used the decomposition model. Hi-Rise (Maher and Fenves 1984; What is decomposed? It is easy to say that the design problem is decomposed into subproblems, but what is the meaning of decomposition in design? There are at least two meanings to the decomposition of a design problem into subproblems: (1) to decompose a domain of design knowledge, say, structural design, into the various physical components that are used to construct design solutions, say, walls, slabs, and so on, or (2) to decompose into the various functions that must be provided for by a design solution, for example, resisting various types of load and providing open space, until a component can be identified that will provide a specified function. The first approach to decomposition is an object-centered approach in which the design knowledge is organized around the physical systems and components that a particular domain is concerned with. The second approach considers a functional decomposition to a sufficient level of detail in which a function to form mapping can occur. The issue of function versus form as a basis for decomposition is not resolved yet. The point here is that design knowledge comprises various types of knowledge, for example, function and form, and recognizing these types of knowledge facilitates the formalization of the design process and, subsequently, the development of a solution. One approach to dealing with the decomposition of the function versus form dilemma is to ignore the distinction between function and form and identify a uniform representation for either function or form. In a search process approach to design, this uniform representation is typically called a goal. Another approach is to dictate a specific representation for functional decomposition and a specific representation for form decomposition. How is the problem decomposed? The assumption behind decomposition is that each subproblem can be solved independent of the other subproblems. However, this assumption is an idealization rather than a reality for any problem definition. The rule of thumb in decomposition is to decompose into nearly independent subproblems or loosely coupled subproblems. Usually, this decomposition is easier said than done. However, because many have been successful in solving complex problems using decomposi- Articles 54 AI MAGAZINE tion, there must be something to it. A wellunderstood problem is easier to decompose than one that has not yet been explored. Is the decomposition fixed? A fixed decomposition implies that it is not altered for a specific problem and is used without modification for all problems presented. At a general level of abstraction, a fixed decomposition might be possible. For example, it is useful to decompose design into formulation, synthesis, and evaluation at a general level. Such a decomposition is not as useful for a more detailed view of a specific design problem. As soon as a more detailed approach to design is required, a single decomposition is inadequate. For example, the decomposition of the design of a structural system might be (1) design the lateral load resisting system, (2) design the gravity load resisting system, and (3) design the foundation. This decomposition makes sense when the structure is a building with more than five stories. Variations can occur when (1) the structure is a single-family residence, where the lateral load resisting system is insignificant and where the order of the decomposition might change but not the subproblems; (2) the structure is underground, where the lateral load resisting system cannot be considered separate from the gravity load resisting system, and the nature of the subproblems must be reconsidered; and (3) the structure is an offshore oil platform, where the foundation and the various structural systems for lateral and gravity loads are integrated. Once it has been determined that the decomposition should not be fixed, a representation that accommodates variations must be identified. How does recomposition occur? The decomposition of a design problem into subproblems implicitly assumes that recomposition will occur. The fact that recomposition is implicit, rather than explicit, indicates that it is not an obvious process. Recomposition can occur implicitly; that is, by stating the solutions to the subproblems, the entire problem is solved. Recomposition can, however, introduce complications. Considering the subproblems as independent problems is only an idealization of reality. Putting the subproblems together must take into account the interactions. One way of representing the interactions is as constraints; the issue of recomposition then becomes one of constraint satisfaction. The various computer environments that have been developed for design by decomposition answer each of these questions through the identification of a structured language or syntax for describing a knowledge base. As an example, Edesyn provides two major representation structures for the representation of design knowledge: the system and the constraint. The representation of various systems allows the design knowledge base to explicitly represent the decomposition knowledge discretely, although the decomposition of any one system can vary as design proceeds. Edesyn provides a uniform representation for form and function, leaving the distinction to the knowledge base developer. The representation of various constraints allows the recomposition knowledge to be explicitly stated. What we gain from the implementation of the decomposition model as domainindependent computer environments for design is a better understanding of decomposition and its associated problems but, more importantly, the realization that models of design are not domain specific. Case-Based Reasoning Case-based reasoning in design involves the generation of a design solution using the solution or solution process from a previous design problem as a basis. This model of design synthesis requires episodes of design cases rather than generalizations about a design domain. Examples of a case-based reasoning approach to design include Struple As a process model, case-based reasoning involves several operations. One set of operations is (Darpa 1989) (1) recall relevant cases from case memory, (2) select the most promising case, (3) construct a solution for the new problem, (4) test the solution, (5) evaluate the results, and (6) update case memory by storing the new case. In design synthesis, the operations of most interest are centered on case retrieval, selection, and modification. With the assumption that case memory is large (that is, many design cases are stored), retrieval becomes a search problem in a large space. The selection of a case among potential cases requires recognition of the relevance of each case and how close the case is to providing a solution to the design problem. The modification of the case for the new design problem raises the issues of what should be changed and what should stay the same. It can be assumed that the changes are based on the results of a partial match, where the features of the case that did not match should be changed, but such local changes might not be sufficient. There are guidelines for the development of a case-based reasoning system, regardless of whether the problem is design, planning, or diagnosis, as in the following: Case memory organization: The extremes in representing cases in memory are to represent each case in its entirety