KNOWLEDGE MODELLING FOR DESIGN DECISIONS 1 ... - CiteSeerX

KNOWLEDGE MODELLING FOR DESIGN DECISIONS FATMA MILI, AMIT GOKANI School of Engineering and Computer Science, Oakland University, Rochester MI48309-4478 AND KEITH FRY, MURLI RAM, EVIE ZOURAS DaimlerChrysler Corporation, Auburn Hills, MI48326 -2757

Abstract. In this paper we share our experience in modeling and representing design knowledge relevant for engineering design decisions. An object model is used where classes definitions are used as design specifications and class instances are seen as candidate designs. The object classes are augmented with validation and evaluation information. We discuss in some detail the semantics and use of these two categories of information and its interaction with traditional constructs of sub-classing and inheritance.

1. Introduction Engineering design refers to all activities aiming at generating and refining detailed product descriptions prior to their physical realization (Shah et al , 1996). The process of engineering design is an analytic step used to improve the quality of the final product and to reduce the time and resources needed for the final production (Hazelrigg, 1996). The improved quality results from the potentially large number of candidate solutions considered during design. Descriptions of these solutions a re generated, refined, analyzed, validated, and compared prior to any physical production of a selected candidate. The reflective activities of analysis and evaluation during design allow the early discovery and correction of problems, thus reducing the occurrence of trial and error, and saving time and cost during the production stage. Because design is in essence a modeling activity, its effectiveness and efficiency are a direct function of the modeling language used. (Brown,

2

F. MILI, A. GOKANI, K. FRY, M. RAM, E. ZOURAS

K.N., 1994). The level of a bstraction and the expressive power of the modeling language used to describe designs dictate the ease with which multiple alternatives can be generated and the amount and accuracy of the insight that can be obtained from them. Engineering design is a labor intensive and knowledge intensive activity that can greatly benefit from computer support (Bernaras A. et al, 1994, Cleland G. et al, 1994, Dym C., 1995, Gero J.S., 1996, Gero J.S., 1997, McMahon C.A., 1991, Reinschmidt K.A., 1994, Tong C. et al, 1991). The most basic form of support comes in the form of facilities for editing, storing, and displaying of designs in progress. More advanced support can cover all phases of design including: • The generation of designs from a set of requirements. • The validati on of designs with respect to a pre -defined set of validity criteria. • The comparison of designs with respect to a set of criteria. Traditional design support systems have consisted of geometry -based CAD systems. The narrowly focused expressive power of ge ometry, and the wide semantic gap between the geometry and the abstract features of a product make this approach limited in the amount and in the quality of the feedback information it provides to the designers. There is a consensus in the engineering des ign community on the need for more comprehensive design support systems (Anantha R. et al , 1996, Bourne, D.A., 1995, Chu P. C., 1998, Kim G. et al, 1994, McMohan C.A., 1994, Mili F., 2000, Narayanan K.2000) and for a better integration of the reflective activities of design validation and evaluation with the active steps of design generation and refinement (Bahler D. et al, 1994, Fisher G. et al, 1994, Kamel A. et al, 1994, Nakakoji K. et al, 1994, Nichols K.,1990, Umeda Y. et al,1997). The project we describe here shares this general goal. It aims in particular at supporting design refinement by providing designers with all the information necessary to make decisions and to validate and justify these decisions. We discuss issues related to the modeling an d the management of this information. This paper is organized as follows. In section 2, we briefly introduce the problem and explain the general approach used. In section 3, we discuss the nature of the information of interest and introduce the data and knowledge model developed. In section 4, we discuss issues of interest that remain open and that we would be interested in exploring during the workshop.

KNOWLEDGE MODELLING FOR DESIGN DECISIONS

3

2. Problem, Approach 2.1. PROBLEM

As we have briefly discussed in the introduction, the state of the practice in computer design support is in need of improvement. We mention notably two major shortcomings of the current practice. 1. Low level design modeling language: Current CAD systems are geared towards geometry. Designers must generate alternatives a nd refine them in terms of low level geometric constructs. For most cases, this forces the designers to bridge a wide gap between the concepts meaningful to them and the concepts that are part of the modeling language. Designers’ decisions are more likely to be conceived in terms of higher level aspects of function, structure, and features. Using current systems, they have to mentally map these concepts in terms of geometric lines, curves, and surfaces. 2. Lack of integrated decision support: The evaluation of an engineering artifact is increasingly complex and multi -disciplinary in nature. An artifact must be evaluated in terms of its function, safety, manufacture, recyclability, and so forth. The amount of expertise involved in all of these areas and its m ismatch with the designer’s training make it impossible for the designer to thoroughly evaluate a design by simple inspection without outside support. In practice, designers seek the expertise of various domain specialists who individually examine the designs from their domain’s perspective and provide feedback and recommendations for design alterations. The designer is then responsible for synthesizing these multiple recommendations into a new version of the design. The cycle is repeated as many times as necessary. This manual and distributed process is costly, slow, unreliable, and not reproducible. Furthermore, because the reflective activities of evaluation and validation take place outside of the system they leave little or no trace in the form of desi gn rationale and design documentation (Chung P.W.H. et al, 1994). The two above issues are clearly inter -dependent. Raising the level of abstraction of the modeling language is a pre -requisite to providing an integrated decision support. As CAD systems m ove towards feature -based and object-oriented representations, providing an integrated decision support becomes within reach. The integration of validation and evaluation support with generation and modification support requires the existence of repositories of validation requirements and evaluation criteria. Engineering

4

F. MILI, A. GOKANI, K. FRY, M. RAM, E. ZOURAS

domains have the advantage of being highly documented and relatively formalized domains. A good portion of engineering knowledge is widely available in textbooks, databases, and other pu blications. In addition, the recent trend of knowledge management has led a number of corporations to capitalize on corporate knowledge by eliciting it and recording it (Blackler F. et al , 1993, Halal W.E., 1998). This creates additional sources that are proprietary and more focussed. A knowledge management effort was initiated a few years ago at DaimlerChrysler (then Chrysler). Selected units were given the mission to author their books of knowledge . The resulting books are intended to be live, up to d ate documents synthesizing the corporate expertise in the form of standards, procedures, and best practices. This expertise, once recorded, becomes more easily reviewed, shared, and used. The knowledge collected is, for the major part, knowledge relevant to the main business of the company: design and manufacture of automotive systems. In addition to being valuable in their own right, the books represent an important stepping stone towards an integrated system support of evaluation and validation activi ties during design. The stamping book of knowledge, for example, authored by the stamping department, includes a major section defining constraints and criteria on the dimensions and shapes of all the parts that are manufactured by a stamping process. Cons iderations of feasibility and cost of the stamping process and considerations of quality of the stamped product drive these constraints and criteria. This information is, in essence, the very information needed for the evaluation of designs. The representation and organization of the knowledge in the books has been initially crafted so as to facilitate its retrieval and readability by the authors, the reviewers, and other human readers from the same unit. This knowledge needs to be re -examined with the pro spect of using it by a design support system. We discuss below issues and criteria directly relevant to the selection of a modeling language for this knowledge.

2.2. APPROACH

The long-term goal of this project is to make use of the knowledge collected in the various books by enforcing its standards and recommendations during the design process. The books authored by the different units cover various aspects of corporate knowledge and corporate operation. Some of that knowledge is directly relevant to de sign. For a major part, the books have been written as electronic versions of paper books. There was a deliberate choice to not inhibit the book contributors by letting them express the

KNOWLEDGE MODELLING FOR DESIGN DECISIONS

5

knowledge in whatever form they are comfortable with rather than impos ing on them an additional burden of form. This separation between contents and form allowed also a staged development of the books, and delayed the decision about form until sufficient information is available to make it. With the first goal of eliciting the knowledge accomplished, we set to rethink the form of the knowledge in light of its contents and the uses that we want to make of it. A major underlying concern has been to preserve as much as possible the distributed ownership of the knowledge and th e ease with which it is read, understood, and updated, while also making the knowledge accessible and usable by an automatic decision support system. In particular, we have used the following criteria: tonomous. This • The books must remain separate, independent, and au condition is necessary to ensure that the knowledge in the books truly reflects the latest innovations and best practices in each domain. • The books must remain descriptive. We have found that the knowledge elicited in the books is descriptiv e in nature. It states the conditions that ideally should hold without prescribing fixes for those cases where they do not. It is important to let the domain experts state what they know best. Fixes for violated constraints depend on the processes, the co ntext, and many other considerations outside their jurisdiction. • Changes in the books must be reflected within the design support system with little or no delay. The general solution adopted is illustrated in Figure 1.

Source 1

Source 2

Source n

book 1

book 2

book n

Design Support System Knowledge Extraction and transformat ion Component

Design Support KB

6

F. MILI, A. GOKANI, K. FRY, M. RAM, E. ZOURAS

Figure 1. System Architecture.

In this figure, each source represents the unit authoring and maintaining its book. This reflects the full ownership of the books by their corresponding units. Because the design support system needs timely access to the knowledge originated from the different books, it is networked to the books via a knowledge extraction and transformation component . This component extracts relevant knowledge from the different sources, and integrates it together into the design supp ort system’s knowledge base. In the process, the knowledge may be transformed into efficient prescriptive processes. The use of a level of indirection in the form of the knowledge extraction and transformation component introduces flexibility and relative independence, yet still requires that the knowledge in the books have some degree of formality. We discuss now the knowledge model developed for the revised versions of the books. 3. Knowledge Model The knowledge of interest is in essence a collection of constraints (e.g. “the distance between the fuel filler and the wheel opening must be greater than 40mm”) and design criteria (e.g. “maximize the radii of the corners of the door opening”). These constraints and criteria are organized around parts (e.g. Body side aperture, door). We sought a representation that matches closely the organization chosen by the original authors while allowing for formality and rigor. We have chosen to use the object -oriented formalism, amending it and augmenting it as needed . The representation used is characterized as follows: • Parts and systems that are the focus of constraints in the book (e.g. door, fuel filler) are represented by classes. • Constraints and criteria are encapsulated within classes. We have expanded the class concept in this respect. The resulting classes with their constraints and criteria can be thought of • as specifications for the design objects. Design alternatives, when finalized, must meet their specifications. • Traditional Object -Oriented constructs (e. g. subclasses, inheritance) are used. We also define new constructs (e.g. assembly, part -feature) to capture commonly occurring associations between classes. In the reminder of this section, we define the concept of classes with constraints and criteria i n more details. We discuss the semantic

KNOWLEDGE MODELLING FOR DESIGN DECISIONS

7

implications of this extension. The additional constructs are outside the scope of this paper. 3.1. CLASSES WITH CONSTRAINTS AND CRITERIA

3.1.1. Classes From a designer’s point of view, the knowledge in the books i s of value to the extent that it supports them in making design decisions. Designers use their creativity and experience in generating design alternatives. They need system support notably for evaluation decisions and validation decisions. Validation decis ions are those decisions where individual designs are assessed for compliance with their validity requirements. Evaluation decisions are those decisions where competing designs are compared with respect to relevant criteria. We represent validation knowled ge by constraints that must be met by valid designs. We represent evaluation knowledge by criteria, i.e. partial ordering relations. Because validation and evaluation are activities specific to the nature of the object being considered, constraints and cri teria are encapsulated within classes. Consider, for example, the following design knowledge on an outer panel from the stamping point of view: • The size of the panel must not exceed 500mm • The angles at the corners of the panel must be no sharper than 50 degrees. • The softer are the angles at the corners, the better. We use the UML notation to represent the resulting class OuterPanel. OuterPanel Attributes length: Real Methods cornerAngles ():set of Real Validation constraints bounded length nosharpCorners Evaluation criteria SoftCorners Figure 2. Sample Class.

8

F. MILI, A. GOKANI, K. FRY, M. RAM, E. ZOURAS

Understandably, the focus in this class definition is on the constraints and criteria. All attributes and methods listed are merely included because they are referenced in the expression of th e validation and evaluation knowledge. In the above class definition, we only listed the names of (a reference to) the knowledge units. In fact, a wealth of information is associated with these knowledge units. We define two classes of knowledge units, one for each category of information. We discuss below the class validation constraint. 3.1.2. Validation constraints There is more to a validation constraint than its name or its formula. We define a class Validation Constraint to capture the many dimension s of this concept. We show a skeleton class definition for the Validation Constraint class. This skeleton can be refined and customized in light of the specific domain’s needs. The attributes listed are only suggestive, although some of them (e.g. names, formula) can be expected to be universal. Validation Constraint name : constrains : formula : text : illustration : rationale : premise : reference : last updated : Figure 3. Validation Constraint class.

For Future illustration, we show a sample instance of the class. noSharpAngles: ValidationConstraint name = noSharpAngles constrains = OuterPanel formula = ∀ a ∈ cornerAngles(): a ≥ 50 degrees illustration = {Figure OP3, Figure OP5} rationale = sharp edges cause low spots and weak dies premise = panel is made out of alloy X reference = Internal document Ref. X888 last updated = 10/30/1999

Identification, Contents Human interface

Management and Use

KNOWLEDGE MODELLING FOR DESIGN DECISIONS

9

Figure 4. Sample Constraint.

In addition to the basic attributes defining the identification and co ntents of the constraints we list attributes useful for the readability by human uses (authors as well as designers) and attributes used for management and argumentation purposes. The rationale explains why the constraint is needed. This often translates i nto: “what happens if the constraint is violated”. The premise represents the underlying assumption made. In the above example, it is known that sharp angles cause low spots and weak die when the metal being used is alloy X. Using a different alloy than X for the manufacture of the panels may invalidate or require an adjustment to the constraint. To the attributes listed, we will later add associations between constraints. This is motivated by inheritance introduced in the coming subsections.

3.1.3. Class Semantics Before proceeding further, we need to define the semantics implied by the Validation Constraints attached to a class. Given a class E with attributes A 1: T 1 ,……A n : T n and validation constraints C1,C2,….,Ck, We define • the decision space of the class E as the n-dimensional space obtained from the n attributes i.e. S = T1 x T2 x…….x Tn and • The valid decision space of class E as the subset V of S in which all the constraints are met, i.e., V = { s | s ∈ S and (C1 . C2 .….. Ck)(s)}. Because design is a progressive refinement process that is non -monotonic, it is understood that most design alternatives are neither complete nor compliant. For this reason, design alternatives in progress are generally not instances of the set V. An alternative i s not valid by construction. It only becomes valid after evaluations and corrections. Elsewhere (Mili F., 2000), we have defined a set of design milestones which correspond to different stages of refinement of design alternatives. We only mention here that design alternatives are defined in terms of pairs of subsets of S. Also, design alternatives are classified into drafts, solutions, and designs. The result of any sequence of decisions qualifies as draft. Drafts that meet all of the

10

F. MILI, A. GOKANI, K. FRY, M. RAM, E. ZOURAS

validity constraints q ualify as solutions. Solutions for which all decision variables have been set qualify as design.

3.2 SUBCLASSES AND INHERITANCE

3.2.1 Syntax One of the major features of using the object model is the modular derivation and representation of information. Modularity is obtained through the concept of generalization and specialization. A class can be defined as a special case of more general classes. The concept of outer door panel for example, can be defined as a subclass of the class Outer Panel. Specialization is advantageous because of the associated concept of inheritance. The properties of a class do not need to be repeated for its subclasses. They are automatically inherited. They can also be refined within the subclasses. We make use here of concep t of subclassing focussing mostly on the refinement through the addition and specialization of constraints. A subclass inherits all of the constraints of its superclass unless specified otherwise. A validation constraint specified under outer panel, for example, will automatically apply to all subclasses of outer panel. Similarly, an evaluation criterion defined under the class outer panel will apply to its subclasses. For example, if the noSharpAngle constraint is relevant to all panels, then it would be defined under the class Panel. The class OuterPanel is a subclass of Panel and inherits automatically all of the features of the Panel class, including the noSharpAngle constraint. This is illustrated below. Panel Attributes Methods CornerAngles ():set of Real Validation constraints NoSharpAngles Evaluation criteria MaximizeAngles OuterPanel: Panel Attributes Length: Real

KNOWLEDGE MODELLING FOR DESIGN DECISIONS

11

Validation constraints BoundedLength Figure 5. Subclassing and Inheritance

3.2.2 Semantics The semantics of sub -classing must be consistent with the semantics of the class concept. We have defined the semantics of classes in terms of pairs of spaces, a decision space, S, and a valid space V. Because this definition is state-based, the concept of sub -classing must also be stat e-based, and thus must be consistent with sub-setting. We consider three special cases: 1. No new decision variables: Consider a class E defining a decision space S and a valid space V. Consider a class F defined as a subclass of E with no new attributes but with a new constraint C’. F has the same decision space, S, as E and a valid space V’={s| s ∈ V and C’(s)}. In this case the class E defines the pair and the sub -class F defines with V’ ⊆ V. 2. Redefined decision variables: Consider a class E d efining a decision space S and a valid space V. Consider a class F defined as a subclass of E with some of the attributes redefined and a new constraint C’. According to the principle of co -variance (Abadi and Cardelli 1996), the resulting redefined decis ion space S’ is a subset of S. The valid space V’ is defined by V’={s| s ∈ V and s ∈ S’ and C’(s)}. In sum, the class E defines the pair and the sub -class F defines the pair with S’ ⊆ S and V’ ⊆ V. 3. Redefined constraint: Consider a class E de fining a decision space S and a valid space V. Consider a class F defined as a subclass of E with some of the attributes redefined and some of the constraints redefined. In order to remain consistent with the concept of sub -setting, the resulting class F must be such that F defines a pair with S’ ⊆ S and V’ ⊆ V. The three cases above do not include the case where new decision variables are added. These cases can be easily handled by extrapolation (the projection of the space V’ over the space S must be a subset of V). We discuss now the implications of the sub -setting interpretation of sub classing. We re -examine the third case in more detail focussing on the constraints alone:

12

F. MILI, A. GOKANI, K. FRY, M. RAM, E. ZOURAS

Given a class E with attributes A 1:T1, …, A n:Tn and with validati on constraints C1,C2,….,Ck, E defines • the decision space S = T1 x T2 x…….x Tn, and, • the valid space V = { s | s ∈ S and (C1 Λ C2 Λ...Λ Ck)(s) } Given a class F defined as a sub -class of E with C 1,C2,….,Ck redefined by C 1’,C2’,….,Ck’. We know that the re sulting space V’={s| s ∈ S and (C1’ Λ C2’ Λ...Λ Ck’)(s)} must be such that V’⊆V. Logically, this means that the set of redefined constraints, must globally be stronger (logically imply) than the original set of constraints. For example, given the class E w ith real attributes x and y and constraints C1: x ≥ 3 and C2: y≥ 5, we can define the following subclasses of E: • F1 where constraint C1’ redefines C1 as: x ≥ 4 and C2’ redefines C2: y ≥ 6 • F2 where constraint C1’ redefines C1: y≥ 5 and C2’ redefines C2: x≥ 3 • F3 where constraint C1’ redefines C1: x = y and C2’ redefines C2: y≥ 6 All three examples meet the requirement that, collectively, the new set of constraints is stronger than the original set, and therefore defines a valid subclass. In practice, the most c ommon form of refinement is the one illustrated by the first example (F1). In other words, the redefinition of constraints is done on a constraint by constraint basis, whereby the new constraint implies the old one. There are cases of global redefinition, but they take a special form. We discuss the two cases below.

3.2.3 Constraints Specialization in sub-classes Constraint-wise refinement: This is the “trivial” case where one constraint in the sub -class redefines another constraint in the super -class. A sufficient condition of correctness is that the redefined constraint be logically stronger than the original constraint, i.e. the new formula implies the old formula. For example, we define a smooth panel as a panel with no angles sharper than 95 degrees . The class SmoothPanel shown in Figure 6 shows how the new constraint smoothAngles (requiring angles of at least 95 degrees) replaces the weaker constraint of the parent. SmoothPanel: Panel

Validation constraints

KNOWLEDGE MODELLING FOR DESIGN DECISIONS

13

SmoothAngles replaces noSharpAngles

Figure 6. Constraint specialization

Implicit is the fact that constraint SmoothAngles is defined as an instance of the class Validation Constraints and that its formula is logically stronger than the formula of noSharpAngles. In this particular examp le, the re definition is motivated by a stronger requirement on the angle. In practice, a constraint may need to be redefined for other reasons than its logical formula. Any of the attributes of the Validation Constraint can be redefined (e.g. rationale, t ext, illustration, reference, etc.). It is conceivable to impose a discipline whereby redefining some attributes requires the redefinition of others. For example, the value of the attribute Last Updated can be changed automatically; the rationale may need to be updated to reflect a change in the formula; some changes in a formula may require changes in the illustration, etc. Global overwriting of constraints: There are cases where a constraint associated with a super -class is dropped in the sub -class beca use it is implied by other implicit or explicit constraints. Consider the example of a class E with real attributes x and y and constraints C1: XY ≥0 C2: X>-10. If we define a class F, subclass of E in which Y=0 (by restriction of the space or through the a ddition of a constraint), we can easily drop the constraint C1. It is implied by the rest of the requirements. When a constraint can safely be dropped, we need to mention it, and explain the reason for dropping it. To take another example, we define a rou nd panel as a panel whose perimeter is a circle. Within such a panel, the constraint on the angles is no longer needed. This is shown below in Figure 7. RoundPanel: Panel Shape RoundShape NoSharpAngles impliedby RoundShape Figure7. Constraint Overwriting

14

F. MILI, A. GOKANI, K. FRY, M. RAM, E. ZOURAS

3.5. CONSTRAINTS REVISITED

The two cases of constraint redefinition raise the need for a documentation of the various associations that may exist between validity constraints. We expand here the definition of the class Validity constraint to a ccount for these associations. We expand the definition of the class Validation Constraint as follows: Validation Constraint Attributes name : String constrains : Class formula : Formula text : Text illustration : Set of Illustration rationale : Set of formula premise : Set of formula reference : Text last updated : Date replaces : Validation Constraint implied by : Set of Validation Constraint Methods Validation constraints Replaces weaker formula Replaces formula defined in a parent of the class this constraint constrains Implied by a set of stronger constraints Implied by constraints from same class or parent classes Figure8. Validation Constraint Class refined

The validation constraints on the class validation are those conditions that guarantee that the specialization hierarchy does not violate the semantics provided.

KNOWLEDGE MODELLING FOR DESIGN DECISIONS

15

4. Summary, Discussion In this paper, we have considered the modeling of knowledge relevant to reflective decision activities during engineering design. We have classified the knowledge into validation knowledge and evaluation knowledge, and focussed on the evaluation knowledge. We used an object -oriented model as a means to organize and encapsulate design constraints. Desig n validation constraints are interpreted as a major component of the specification of engineering objects. These validation constraints are not class invariants. Most alternatives manipulated by designers would not be compliant with these constraints. For the sake of flexibility, and to promote free exploration of the decision space, only final designs are expected to be compliant. The particular issue addressed in this paper is he concept of sub -classing and inheritance. Specialization in object -oriented formalisms is generally interpreted in terms of variance and co-variance. We have followed the same general principle and adapted it the special category of validation constraint. This project is work in progress with some features implemented whi le others are at the conceptual state. We are very much interested in attending this workshop to share our experience and learn from others’.

Acknowledgements This project is conducted as a cooperation between DaimlerChrysler Corporation and Oakland Un iversity. The first author would like to acknowledge funding from DaimlerChrysler under grant xxxx and Oakland University and the Michigan Research Excellence Fund.

References Anantha, R. et al: 1996, Assembly modeling by geometric constraint satisfactio n, ComputerAided Design, 28(9): 707-722,1996. Bahler, D. et al : 1994, An axiomatic approach that supports negotiated resolution of design conflicts in engineering. In J. S. Gero and F. Sudweeks, editors, Artificial intelligence in design, pages 363-379, Kluwer Academic Publishers. Bancilhon, F. et al: Building an Object-Oriented Database System: The Story of O2. Bernaras, A. et al : 1994 Problem -Oriented and Task -oriented Models of Design in The Commonkads Framework. In J. S. Gero and F. Sudweeks, editors, Artificial intelligence in design, pages 499-516, Kluwer Academic Publishers. Blackler, F. et al : 1993 Editorial introduction : Knowledge workers and contemporary organizations. Journal of Management Studies, 30(6): 852-862,November 1993. Booch, G. et al: 1999 The Unified Modeling Language User Guide. Addison Wesley.

16

F. MILI, A. GOKANI, K. FRY, M. RAM, E. ZOURAS

Bourne, D. A. et al: 1995 Design and Manufacturing of Sheet Metal Parts: Using features to Resolve Manufacturability Problems. Proceedings of the Computers in Engineering Conference and the Engineering database Symposium ASME: 745-753. Brown, K. N. et al : 1994 Constraint Unification Grammars: Specifying Languages of Parametric Designs. In J. S. Gero and F. Sudweeks, editors, Artificial intelligence in design, pages 239-256, Kluwer Academic Publishers. Cardena, A.F. et al : 1990 Research foundations in object -oriented and semantic database system. Prentice Hall. Choo, C.W.: 1998 The Knowing Organization. Oxford University Press. Chu, P. C. et al: 1996 Feature-based approach for set-up minimization of process design from product design. Computer-Aided Design,28(5):321-332,1996. Chung, P.W.H. et al : 1994 Representing design History. In J. S. Gero and F. Sudweeks, editors, Artificial intelligence in design, pages 735-752, Kluwer Academic Publishers. Cleland, G. et al: 1994 A Knowledge -based System Approach to the Layout Design of Large Made-to-Order Products. In J. S. Gero and F. Sudweeks, editors, Artificial intelligence in design, pages 257-274, Kluwer Academic Publishers. Fisher, G. et al: 1994 Seedi ng evolutionary growth and reseeding: supporting incremental development of design environmnts. In Human factors in computing systems(CHI’94), Pages 292-298,1994. Gero, J.S. et al: 1997 A framework for research in design computing. In Proceedings of ECAADE, 1997. Gero, J. S.: 1996 Creativity, emergence and evolution in design. Knowledge-Based Systems, 9:453-448,1996. Gero, J.S. et al: 1996 Artificial Intelligence in design. Kluwer Academic Publishers,1996. Halal,W.E.: 1998 The infinite resource : Creating a nd leading the knowledge enterprise. Jossey-Bass Publishers, 1998. Hazelrigg, G.: 1996 Systems Engineering: An Approach to Information -Based Design. Prentice Hall, New Jersey. Kamel, A. et al : 1994 Multiple Design: An Extension of Routine Design For Genera ting Multiple Design Alternatives. In J. S. Gero and F. Sudweeks, editors, Artificial intelligence in design, pages , Kluwer Academic Publishers. Kim, G. et al: 1994 Design -For-Assembly (DFA) by Reverse Engineering. In J. S. Gero and F. Sudweeks, editors, Artificial intelligence in design, pages 717 -734, Kluwer Academic Publishers. Martin et al: 1996, A Theory of Objects, Springer Verlag, 1996. McMahon, C. A. et al : 1994 A Knowledge -Based Approach to Design for Durability in Concurrent Engineering. Journal of System Engineering (1994)1:13-22. McMahon, C.A. et al: 1991 Knowledge -based systems for automotive engineering design. In Autotech 1991,pages 1-7. Mili,F. : 2000 Knowledge architecture for engineering design support. In Proceedings of AAAI spring symposium,March 2000. Narayanan, K.: 2000 Knowledge modeling for engineering design support, Doctoral thesis defenses. Nakakoji, K. et al: 1994 Perspective -based critiquing: helping designers cope with conflicts among design intentions. . In J. S. Gero and F. Su dweeks, editors, Artificial intelligence in design, pages 449-466, Kluwer Academic Publishers. Nichols,K.:1990 Getting engineering changes under control. Journal of Engineering Design,1(1),1990. Reinschmidt, K.A. et al : 1994 Smarter computer -aided design. IEEE Expert, pages 50 -55, 1994.

KNOWLEDGE MODELLING FOR DESIGN DECISIONS

17

Shah et al : 1996, Research Opportunities in Engineering Design, NSF Strategic Planning Workshop Final Report, April 1996. Taylor, G.H.: 1998 Knowledge companies. In William E. Halal, editor, The infinite resource, pages 97-110. Jossey-Bass Publishers, 1998. Tong, C et al: 1991 Artificial Intelligence in Engineering Design: Volume I. Academic Press, 1991. Umeda, Y. et al : 1997 Functional reasoning in design. IEEE Expert, pages 42 -48,MarchApril, 1997.