Designing Conceptual Ideas - Essay Example

Conceptual design (CD) as a process model of design is intuitively appealing because much of design knowledge comes through the experience of multiple, individual design situations. A major task in the development of computer support for design is the identification of the design knowledge to be included in the support tool. Although designers may have difficulty generalizing their heuristics or styles, they usually have no trouble telling stories about previous design situations. If this kind of reasoning can be captured in a computable model of design, the resulting design system may be capable of learning from design experience and maintaining a reasonable competency in design without major reprogramming. Developing such a model also improves our understanding of design and challenges some of the theoretical developments in CD. In order to effectively apply CD to design, it helps to do a task analysis of design problem solving. Design process models begin to identify some of the computational models of design and the implications of implementing one of them. Such models can provide guidelines in the development and use of computer support tools. Three models considered in this chapter include a decomposition approach to design, a CD approach, and a transformational approach. Design, as ill-structured problem solving that has formal knowledge as well, presents challenges to the application of CD. Using CD requires the formalization of design experiences as a design case memory and the formalization of the reasoning processes of recall and adaptation. There are aspects of a design domain that have no formal representations, where the basics of CD cannot be applied as a formalism. There are also aspects of a design domain that may already be formalized and these formalisms need to be integrated with the CD model in order to have an effective design support tool. The idea of a hybrid CD system is defined and introduced in this chapter and is presented in more detail in later chapters. Considering the implementations of CD in design problem solving shows the variety of applications of the same computational model. CD has been applied to the design of mechanical devices, the design of a meal, architectural and structural designs of buildings, and the design of computer programs. There are similarities in the use of CD in these domains, and there are significant are significant differences. A brief review of a selection of implementations of CD to design is included in this chapter. The purpose of this review is to introduce a variety of approaches to the application of CD to design; the rest of the book focuses on a subset of these approaches. DESIGN PROCESS MODELS Design is characterized as an ill-structured problem in several aspects. First, the problem definition is incomplete. As design proceeds, the definition of design problems changes. The formulation of design problems is, therefore, dynamically refined. Design also appears to be ill-structured, in the sense that there is no straightforward process to be followed. The imprecision of pertinent design knowledge can be viewed as another aspect of the ill-structured nature of design. Design theories and principles are often insufficient to guide the design process. During designing, therefore, the formulation of the design problem is dynamically modified as design progresses; multiple types of design knowledge, such as design theories, heuristics, and past design experience, are combined to compensate for the insufficient domain knowledge.The design process, although ill-structured, can be formalized at a high level of abstraction ( Simon, 1973). The selection of a formalization depends on the intended role of the resulting model, as there are many ways to characterize, dissect, and order design processes ( Dym, 1994). For the purpose of establishing the relevance of CD to the broadly defined process of design, the design process is considered as comprising three phases: formulation, synthesis, and evaluation: - Design formulation involves identifying the requirements and specifications of the design problem, understanding the problem, and producing an explicit statement of the design goals. This is sometimes referred to as the design brief or program, or more simply as the definition of the design problem. - Design synthesis includes the 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; that is, this phase judges the validity of solutions relative to the goals and selects among alternatives. This phase of the design process often includes engineering analysis. Although the phases may not be addressed in the order prescribed for the entire design process and are often carried out recursively and iteratively, 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. Variation can occur in the revisions of the requirements and/or descriptions, and the iterations on the various phases. Therefore, certain feedback between the evaluation and the formulation phase complete the process model. The identification of different phases in the design process is a beginning for the formalization and understanding of design. What is missing from such a description is how each phase is completed. A structured approach to design is helpful in identifying various design activities, but not in executing them. When a particular methodology does provide a procedure for executing a design activity, it imposes constraints on the representation and control of the design process. Rather than prescriptions for the execution of design activities, it may be more helpful to identify descriptive models that allow reasoning and creativity within a formalized representation of design knowledge and experience. The focus for process models of design here is on the synthesis phase. Synthesis processes produce a design solution in the form of a structural description. During design synthesis, the form of the design solution is identified. Design synthesis develops a form, such that an object constructed according to this form would satisfy the requirements. Design Synthesis Design synthesis begins with a set of intended functions and design constraints that are generated from the formulation phase according to the client's needs or more general requirements, and then produces a set of alternative design structural solutions. Such tasks include the definitions of forms and the identification of design components for an object. In general, design synthesis constructs a design description by identifying the form of a design object and producing feasible structural design components of the object. In the synthesis of design solutions, alternative structural configurations are generated and evaluated. Design synthesis is arguably the most difficult and least understood phase in the design process. The synthesis phase itself is a further form of formulation-synthesis-evaluation. From the perspective of the threephase model, it is unnecessary for the design problem to be formulated completely before synthesis can begin. Complete formulation is then impossible in any but the simplest design task. Thus, in the course of design synthesis, the detailed formulation is involved when new problems occur during the generation of a design description, and when further design synthesis and evaluation of the design description will be performed. Therefore, design synthesis tasks must be concerned with a recursion from more general to more detailed. Design synthesis is central to the design process because it plays a role of generating a design description. There is a question of how design synthesis is performed. In practice, 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 its constraints. Although there appears to be no standard approach to synthesis suitable for all design problems, the recent use of knowledge-based systems for the synthesis of design descriptions has shown promise and forms the basis for the models described in this book. 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 "experience" may 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 design space, it is implicitly developed and expanded as 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 we consider a knowledge-based approach to design synthesis. Modeling Design Process As a process, design can be a sequence of goal-directed actions that cumulatively generate a design description, or a number of alternative design descriptions, from a set of design specifications. In formulating a framework that facilitates design activity, a design process model is formed. In other words, design process models formalize problem solving activity in the generation of design descriptions. In the context of design, process models are useful vehicles for developing computer support. Simon ( 1969) presented a general approach to modeling design 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. Variations in both the goals and the state space 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 may change during the problem solving process, which may indicate a different design space needs to be searched. One reason design has been difficult to implement as a search process is this change in definition of the problem 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 employ search in various ways are needed to bridge the gap between a model of design and the eventual representation of design knowledge and experience. Design process models describe the progression from design requirements to design solutions. Here, the major concern is with design processes, such as synthesis, in which the requirements do not include the variables that will be used to describe the solution, in other words, part of the design process is to determine the design variables, as well as the values of the variables. Associated with a design process model is design knowledge, which supports the generation of design descriptions, and knowledge to perform certain design activity by manipulating a sequence of actions. A process model of design differs from a representation of design knowledge. A process model describes how the design proceeds. A representation of design knowledge describes the format of the knowledge used during the design process. It is possible, in some cases, to describe design knowledge representation without making an explicit reference to the process that uses the knowledge. It is also possible to refer to a process model without being explicit about the knowledge representation that drives the process. However, the two are closely coupled. The choice of a process model dictates, to some extent, the type of knowledge needed, just as the choice of a representation determines how it can be used. Using a knowledge-based paradigm to model design processes makes design knowledge explicit. The design knowledge pertaining to a design domain is separated from the reasoning mechanism of the design model. The nature of design knowledge directly influences the reasoning methods used. Knowledgebased design process models are, therefore, distinguished by the representation of design knowledge. Furthermore, the formalism for representing design knowledge classifies design models. Three process models are presented here, where the design variables are identified and where reasoning mechanisms for finding feasible values for the variables are available. The process models presented assume that specific types of design knowledge are available. Each process model and its associated knowledge representation schemes are considered in terms of the AI techniques used and their implementations as knowledge-based design systems. The three distinct models of design processes are: 1. Decomposition. 2. CD. 3. Transformation. These models are distinct because they allow the design process to progress in very different ways and because they require different types of design knowledge. Decomposition Decomposition is an implementation of hierarchical refinement, in which the generation of a solution is a knowledge-based representation of general design methodology. The philosophy of this model is to break large, complex problems into small, less complex, manageable ones. A design solution is produced based on the recomposition of the solutions of design components whose solutions are compositions of more basic components.In a design process model, design progresses by considering different levels of abstraction of the design problem. As each design subproblem is considered, decisions are made regarding the selection of a component or value for a variable or deciding whether the problem is to be decomposed into smaller problems. In developing a design model by decomposition in a particular domain, the substantial task is identifying the decomposable form of information. Many forms of information can be decomposed based on the concept of abstract refinement. Regardless of which domains and categories of design information are involved in refinement, the essential characteristic of the representation of such information is decomposable into constituent components. Maher ( 1990) proposed two approaches to the decomposition of a design problem in to subproblems: 1. To decompose a domain of design knowledge into structural systems. 2. To decompose a problem into the various functions that must be provided by a design solution. Once a decomposition approach is used, recomposition becomes an issue. Recomposition can occur implicitly, in which case the solutions to the subproblems are considered to be the solution to the entire problem. Recomposition usually introduces complications through the interaction of the subproblem solutions and the complex dependencies between constraints among subproblems. Therefore, putting the subproblems together must take into account the interactions. The typical way of representing such interactions is as constraints; then the issue of recomposition becomes one of constraint satisfaction. When we consider a knowledge-based approach to representing design knowledge, the decomposition model specifies the type of design knowledge needed. Knowledge-based systems for design by decomposition have been developed that identify specific languages for describing design knowledge. Examples of such languages include DSPL ( Steinberg, 1987). The issues associated with this model include the appropriateness of decomposing and of assuming that solutions to loosely coupled subproblems will combine to form a good design solution. The use of a decomposition model requires identifying decomposable systems and constraints for composing subsystems. CD CD is a form of analogical reasoning. The basic idea is to use specific design knowledge in terms of previous design episodes to generate a new design. The specific knowledge applied is usually represented as a repository of design cases. Rather than solving the problem from basic components based on general rational knowledge, a CD model recalls and adapts specific solutions to previous design problems to attain feasibility as a solution for a new design problem. There are several issues that must be addressed: organizing case memory and indexing cases, retrieving and selecting the most relevant case to the new problem, adapting past solutions to fit the new problem, and updating the case memory whenever a new case is generated. When we consider a knowledge-based approach to representing design knowledge, the decomposition model specifies the type of design knowledge needed. Knowledge-based systems for design by decomposition have been developed that identify specific languages for describing design knowledge. Examples of such languages include DSPL ( Brown and Chandrasekaran, 1985). The issues associated with this model include the appropriateness of decomposing and of assuming that solutions to loosely coupled subproblems will combine to form a good design solution. The use of a decomposition model requires identifying decomposable systems and constraints for composing subsystems. CD CD is a form of analogical reasoning. The basic idea is to use specific design knowledge in terms of previous design episodes to generate a new design. The specific knowledge applied is usually represented as a repository of design cases. Rather than solving the problem from basic components based on general rational knowledge, a CD model recalls and adapts specific solutions to previous design problems to attain feasibility as a solution for a new design problem. There are several issues that must be addressed: organizing case memory and indexing cases, retrieving and selecting the most relevant case to the new problem, adapting past solutions to fit the new problem, and updating the case memory whenever a new case is generated. In a design process model, design progresses by finding relevant previous design solutions to serve as a basis for the new design problem and then adapting the representation of a previous design problem to satisfy the requirements of the new design problem. CD is becoming more attractive as a basis for knowledgebased design process models because it provides many advantages as a problem solver. First, CD presents a shortcut for the generation of a new design solution, avoiding the time necessary to create a solution from scratch. In other words, CD provides a way to reason holistically about previous solutions and, consequently, to preserve and exploit the internal consistency of previous solutions. By applying CD to design, a previous design case suggests an entire solution to a new problem, and pieces that do not fit the new situation are adapted. Second, CD alleviates the knowledge acquisition bottleneck because it directly employs previous design experience, rather than relying on generalizations of design experience. Developing generalized representations of design knowledge in a particular domain can be difficult and time-consuming. There is a large and growing interest in the use of the CD approach for building knowledge-based systems that aid in the process of design. Related work, including Sycara and Navinchandra ( 1989), Wang and Howard ( 1989), Maher and Zhang ( 1991), Goel and Chandrasekaran ( 1989), Hinrichs and Kolodner ( 1991), and Hua, Schmitt, and Faltings ( 1992), is aimed at employing design experience to solve certain classes of design problems using CD. In using a CD approach to design, some generalized knowledge is needed to model design process. For example, generalized knowledge is needed to adapt a previous solution to be a solution to a new problem. Sycara and Navinchandra used qualitative reasoning to adapt previous cases to be suitable as new solutions. Wang and Howard used a rule base, in addition to the case base. Maher and Zhang used decomposition knowledge to assist in the adaptation. The issues associated with using this model for design include the identification of what is stored in a design episode in order to reason about its applicability in a different context, the meaning of a similar design, and the adaptation of the solution from the original context to the new context. Transformation The transformation model follows a theoretical approach to design in which the initial set of design requirements is transformed into a design description. Because grammars provide a formalism for the transformation model, the most common application of the transformation model of design is manifested as grammars. A general rule-based system shares many characteristics of a transformation model, the distinction being a subtle one. The considerations in using a grammar to represent design synthesis knowledge include (a) the definition of the terminal and nonterminal symbols, and (b) the identification of productions. The definition of the terminal and nonterminal symbols is based on a formal representation of the design requirements and solution. The identification of production rules provides the domain knowledge, where the production rules represent design transformations associated with a specific design domain. The collection of production rules represents a specific design approach, for example, the design of rigid-frame structural systems can be captured in a set of production rules or in the formalization of a design style, such as prairie houses. The application of shape grammars to architectural design has illustrated the ability of shape grammars to formally represent generative design knowledge and capture design style. The most notable applications include grammars that characterize the design of Frank Lloyd Wright prairie houses ( Koning and Eizenberg, 1981), Palladian villa plans ( Mitchell and Stiny, 1978), and Queen Anne-style houses ( Flemming, 1987). CD PROCESS MODEL CD provides a process model for applying past experience directly to new problems. CD has been presented as a cognitive model for problem solving. This has led to guidelines for the development of memory organization, indexing, retrieval algorithms, and selection methods. These guidelines provide a general understanding of CD, however, and do not reflect how CD is implemented to perform practical design problem solving. In addition, CD in design applications is a new research area. The design process itself poses some fundamental problems for CD (e.g., the identification of what is in a design episode in order to reason about its applicability in a different design context and the adaptation of previous design situations from an original context to a new context). In general, a CD system involves the representation of design episodes in a manageable structure and the generation of a new design using previous designs as a basis. A CD system thus poses representation-related issues (e.g., representation of a design case, indexing of design cases, etc.) and process-related issues, such as design case retrieval, design case adaptation, learning, and so on.A CD system is characterized here by three fundamental issues: - Design case representation. - Relevant case recall. - Design case adaptation. Design Case Representation A CD system must be able to represent past design experiences in a manageable structure. When specific design knowledge is stored as previous design episodes or cases, the content and knowledge structure of design cases, as well as the organizational structure of case memory, must be considered because subsequent retrieval of relevant design cases and their adaptation will rely heavily on the selected model of case representation. A certain amount of domain-specific rational knowledge is required to support the performance of design subgoals. This leads to the issue of the inclusion of rational knowledge for a design case either inside or outside the case.In general, the issues related to design case representation include the following questions: - What information is stored in design cases' - What representation schemes are used to represent design cases' - How is generalized design knowledge represented in case memory' - How is design case memory organized' The contents of design cases must be represented and indexed in appropriate forms so as to be retrieved efficiently. Design knowledge associated with a design case needs to be represented at several levels, ranging from a topological description of the components to linguistic specifications. As a typical representation scheme, a hierarchical structure represents episodic information at different levels of abstraction ranging from more general (e.g., system), to more specific, levels (e.g., component). Such a knowledge representation structure not only allows a CD reasoner to use small chunks of cases, but also allows abstractions across parts common to several kinds of cases. Representing design cases also should take into account storing a design case in its entirety or breaking a case into pieces. There is also the issue of storing the design solution or the operators used to produce the design description. The advantage to storing the design solution is that many existing cases can be used immediately, augmenting the geometric description with the relevant functions, and so on. The disadvantage is that adapting the old solution to fit the new problem is difficult. The alternative, storing the operators, allows the adaptation to the new problem to be an execution of the old solution operators using a new problem statement. Whether to include the rational knowledge and the governing constraints of a design case within the case or to represent this knowledge outside the case is still an open research question. If rational knowledge is kept within a design case representation, it should be able to anticipate any possible new design contexts to which the case can be adapted. However, the rational knowledge in design cases might be redundant in some design domains, such as structural design and mechanical design, where a certain amount of deep knowledge used for supporting decision making and evaluating the performance are applied to different design contexts. If rational knowledge relies on generalized design knowledge separated from specific design cases, it is hard for domain experts to conceive of all the new contexts and variations for a particular case. In addition, such a CD system must consider the relationships between case knowledge and other types of knowledge. Design Case Recall A CD system must be able to recall the most relevant design cases. Design case recall in a CD model consists of the retrieval of relevant cases and selection of the most relevant case. The retrieval and selection among cases entails the recognition of the relevance of each case to a new problem and of how close a case is to providing a solution to the new design problem. The retrieval of design cases requires recognition of the potential relevance of each case to a current design situation. To do this, design cases must be organized into some manageable structure with appropriate indexing. Design cases are typically indexed by features, the presence or absence of which plays a primary role in determining the applicability of a design case to a current situation. Those features used to index design cases are designated as labels. The fundamental choice in using feature-based indices is how complex and abstract the labels will be. Labels can be concrete. For example, labels might use a number of surface features in design cases and the current design situation, such that the retrieval process is based on the matching of features. Alternately, labels can be abstract. For example, design cases are indexed according to certain deep semantic features pertaining to functionality. Retrieval under such an indexing approach is based on functional relevance. Based on the indexing of design cases, the retrieval process searches case memory to find the relevant design cases. The search method is dependent on the structure of the memory organization. Case selection involves assessing not only how close the past cases are to the new problem, but also the relative importance of the relevant similarities and differences. The retrieval process searches through the cases according to the new problem definition and identifies the similarities between cases and the new problem. The selection process then compares the similar design cases to choose the most relevant ones. There are various techniques that are explored to model this selection process: For example, a weighted count of matching features can be applied. The result of case selection is a previous design that will serve as the basis for the new design solution. Design Case Adaptation A CD system must be able to recommend or perform actions required to adapt one or more design cases to fit the current design situation. Adaptation of design cases plays a problem solving role in the CD process model. Design case adaptation includes identifying the differences between the retrieved cases and the new problem and consistently modifying the previous designs. The benefit of using a conceptual model for design is the efficiency, in terms of effort expended computationally, in producing a design description. Because previous designs cannot be reused without changes, reasoning about these changes needs domain knowledge. Hence, additional reasoning processes need to be defined, and certain domain knowledge is essential for design generation by case adaptation.Because the reasoning methods are different from domain to domain, adapting design cases becomes complicated. Central to design case adaptation, however, is the way old cases are transferred to fit a new problem. Several transfer inferenceshave been developed that provide a background understanding of case adaptation. These inferences include structural adaptation ( Carbonell, 1983) and derivational adaptation ( Carbonell, 1986). These inferences, to a certain extent, appear to correspond to what are known as "weak" methods: abstract, domainindependent problem solving methods.In design problem solving, a previous design is either proprietary or customized for a specific context. Previous designs cannot be reused without substantial changes. It is possible that the ideas or concepts in previous designs can be used again, but their application is different. Design case adaptation often forms the essence of design synthesis in a CD model, using a holistic approach to design by starting with a solution and adapting it to fit a new context. The issues raised by adaptation are: - The representation of domain knowledge about the adaptation. - The maintenance of consistent modification when some aspects are transformed. - The verification of a feasible solution. As a design process model, adaptation assumes that case selection provides a description of a specific design solution that is close to the acceptable final solution, and changes those aspects of the design solution that are inconsistent. First, a potential solution to a new problem is proposed as the solution using the selected case. This potential solution is adapted to change the differences in specifications to match the new context, which introduces some inconsistencies between the design specifications and the design description. This potential solution is then verified, the process of evaluating the new solution, and modified, the process of fixing an inconsistent design. The process of fixing an invalid potential solution is based on using other reasoning methods. The knowledge needed to fix an inconsistent solution is based on domain-specific knowledge. In applying CD to design, the nature of the design process imposes needs of generalized knowledge and underlying reasoning methods to augment or support the CD paradigm. Using underlying reasoning methods and/or domainspecific knowledge in conjunction with a CD paradigm, the idea of a hybrid CD system emerges. The variety of representation forms for generalized knowledge and underlying reasoning methods leads to different implementations of CD to design. To clarify the broad range of implementations of CD, examples of applications of CD to design problems are presented in the form of hybrid systems. Acorn T., and Walden S. ( 1992). "SMART: Support management cultivated reasoning technology for Compaq customer service", Proceedings of AAAI92. Cambridge, MA: AAAI Press/ MIT Press. Alberts L. K. ( 1992). "The use of primitive generic components for the structuring of design cases", in P. Pu (Ed.), Unpublished Proceedings of the AID'92 Workshop on CD Systems, pp. 5-8. Duffy A. H. B., and MacCallum K. J. ( 1989). "Computer representation of numerical expertise for preliminary ship design". Marine Technology 26: 289-302. Falkenhainer B., Forbus K. D., and Gentner D. ( 1990). "The structure-mapping engine: Algorithm and examples". Artificial Intelligence 41: 1-63. Maher M. L. ( 1990). "Process models for design synthesis". AI Magazine 11( 4): 49-58. Maher M.. (1994). "Flexible retrieval strategies for CD", in J. S. Gero and F. Sudweeks (Eds.), Artificial Intelligence in Design '94. Dordrecht: Kluwer Academic, pp. 163-180. Russell S. ( 1989). The Use of Knowledge in Analogy and Induction. San Mateo, CA: Morgan Kaufmann. Schank R. C. ( 1982). Dynamic Memory. London: Cambridge University Press. Simon H. A. ( 1969). The Sciences of the Artificial. Cambridge, MA: MIT Press. Read More