OODS: an object-oriented design system — an example of electronics assemblies

Computers & Industrial Engineering 40 (2001) 229±247

www.elsevier.com/locate/dsw

OODS: an object-oriented design system Ð an example of electronics assemblies Wen-Yau Liang a,*, Peter O'Grady b a

Department of Information Management, Da-Yeh University, 112, Shan-Jeau Road, Fu Hsing, Ta Tsun, Changhua, Taiwan, ROC b Department of Industrial Engineering, University of Iowa, Iowa City, IA 52242, USA

Abstract Object-oriented design is viewed as a promising approach for handling a wide variety of design problems. However, little work has been done to date on developing object-oriented design systems that can handle a variety of design problems. This paper describes an object-oriented design system (OODS) that uses an object-oriented formalism called design with objects (DwO). The background to DwO is described including the DwO design model, the other design objects in DwO, the use of DwO methods and the resulting design process models. The decomposition of objects in OODS is then described, followed by a description of the con®guration system object and the user interface (UI) object. The implementation of OODS is then detailed. This implementation uses the Internet to communicate between OODS and users, and with databases that may be geographically scattered. The use of OODS is illustrated by a description of an application as an example that involves the design of electronics assemblies. The contribution of this paper is threefold. First, a new object-oriented design formalism is presented. Second, an implementation architecture for this formalism is described, and, third, an example application is presented showing how this approach can be used. q 2001 Elsevier Science Ltd. All rights reserved. Keywords: Object-oriented; Design system; Internet

1. Introduction Design acts as a foundation for much engineering activity and is notoriously dif®cult to classify and organize. This is a result of the disparate nature of design problems and the wide range of domains that involve design. The dif®culties associated with design have prompted much work in design and design process models. * Corresponding author. Tel.: 1886-4-852-8469; fax: 1886-4-852-8466. E-mail address: [email protected] (W.-Y. Liang). 0360-8352/01/$ - see front matter q 2001 Elsevier Science Ltd. All rights reserved. PII: S 0 3 6 0 - 8 3 5 2 ( 0 1 ) 0 0 02 3 - 7

230

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

Nomenclature {} [] Ci(z) oli;j (z) k n Ro,p S Skl Vlk Z j c v A E O R C P UI CS

set subset constraints from location z design object i with attribute j from location z selected at design model l generation/iteration number of design objects in Skl functional requirement o with attribute p design model S represents the design model l at generation k objective function, where Vlk ˆ f …Skl † location object operator: inheritance object operator: import object operator: message passing object: design algorithms object: evaluation schema object: physical design objects object: requirements object: constraints object: selection object: user interface object: con®guration system

To date a large number of de®nitions of design has been proposed. De®nitions of design range from the very broad, for example: Design is the process of attaining wide latitude and narrow variance (Bebb, 1989). and Design is a search process in which a satisfactory design solution is produced from a number of alternatives (Gero, 1990) to the more speci®c, for example Design is an activity for converting speci®cation descriptions to design descriptions ready for implementation and, in general, includes within it the concerns of manufacturing (materials, processing, and equipment) and also concerns felt further down the life cycle of the product (e.g. maintenance and disposal) (Kannapan & Marshek, 1992). These de®nitions are important in that each is based on its own view of design and research goals, thus leading to diverse design process models. The differing views of the design process may be classi®ed according to the activities involved (Whitney, 1990), their perspectives (Waldron, 1987), the nature of

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

231

the design process (Kannapan & Marshek, 1992) or else as a transformational view in which engineering design is regarded as a transformation from function to form (Akman, Hagen & Tomiyama, 1990; Gero, 1990). Alternatively, design may be viewed as a problem-solving process, involving searching through a state space, where the states represent the various design solutions (Simon, 1969). Bardasz and Zeid (1992) classify the design process into two classes: creating new design models for new problems, and modifying old design models to ®t new problems. New formulation design is, in essence, the same process as the creation of a new design model. The modi®cation of an old design may be either to produce a new formulation or to vary the parameter values of the existing design model. Therefore, the purpose of the design can be thought to be either to produce another feasible state of an existing design model or to produce a signi®cantly different design model. Classifying design as routine design and innovative design, parametric design and con®guration design, and variant design and creation of new design has been suggested (Finger & Dixon, 1989; Finger, Fox, Prinz & Rinderle, 1992; Gero, 1990; Kannapan & Marshek, 1992). A design process model can be thought of as a representation of the design process that depicts the design activity, design model, and the design solutions, as the design progresses, where the design model can range from a simple, conceptual model to a complex, detailed model. Thus, the design process model provides the framework in which design is described. From what has been stated above, the design process model should be able to describe the various activities, behavior, and the progress of the design. It has been suggested that design process models, in essence, are required to answer the following three basic questions (Smithers, 1989): 1. How does the model incorporate the representation and reasoning mechanism about various forms of design knowledge? 2. How well does the model describe the design process itself as it proceeds? 3. How can the design process model be integrated into a system for design support? Smithers (1989) also identi®es a set of basic types of knowledge application and generation activities, which are typically found in all kinds of engineering design, and includes requirement description, decomposition, strategy planning, detailing and parameterization, synthesis, simulation, analysis, optimization, and documentation (Maher, 1990; Silverman & Mezher, 1992). Though all of these activities are not needed in all cases of engineering design, it is generally accepted that the design process is composed of these or similar activities. It should be noted that different views of design process models, and representation schemes, result in different research agendas. However, there are some common issues in design process models regardless of their classi®cations: the design stages, the representation of a design model and its evolution, the function to design model transformation, design alternatives, and design history (Kim, 1994). One potential approach to handling the dif®culties associated with design is that of object-oriented design: Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notion for depicting both logical and physical as well as static and dynamic models of the system under design (Booch, 1994). Object-oriented design aims to decompose and to represent the design problem and process.

232

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

Decomposition involves the breakdown of functions of the artifact to permit detailed analysis. Representation involves de®ning an object and organizing objects. Work done on object-oriented design systems includes that by Dopplick (1995), Kusiak, Szczerbicki and Vujosevic (1991) and Takeda, Tomiyama and Yoshikawa (1992). While the potential advantages of object-oriented design has been recognized (Coad & Yourdon, 1991; Liu, 1996), the previous objectoriented design systems appear to have been built for the most part in an ad-hoc manner for a speci®c design domain and are not based on a formal methodology. Therefore, the results are dif®cult to extend to other design domains. This paper describes an object-oriented design system (OODS) that uses an object-oriented formalism called design with objects (DwO). The main requirements for an object-oriented design system are detailed. The background to DwO is then described including the DwO design model, the other design objects in DwO, the use of DwO methods and the resulting design process models. The decomposition of objects in OODS is then detailed, followed by a description of the con®guration system object and the user interface (UI) object. The implementation of OODS is then detailed. This implementation uses the Internet to communicate between OODS and users, and with databases that may be geographically scattered. The use of OODS is illustrated by a description of an example application that involves the design of electronics assemblies. 2. System requirements The design and development of an object-oriented design system is a challenging research task. Some of the main requirements are that the system should: ² be able to handle a wide variety of design problems. Such problems range from variant to creative design and range from small-scale to large-scale problems. ² be able to deal with a wide range of domains. The domains can vary from the design of an electronics assembly to that of a mechanical part. ² have an interface to databases. This will allow for data to be obtained from corporate databases and hence provide links to other systems such as CAD, ERP, and ®nancial systems. ² be able to operate over a network. This will allow for the system to be operated by design team participants who are geographically dispersed. Implicit in this is that the UIs should allow for a disparate range of users, on a variety of platforms, to work together. ² be computationally ef®cient. This will allow for the system to readily assist in the design process.

3. DwO: the design model and design process The DwO approach (Liang & O'Grady, 1998) views all entities associated with design as objects. This means that the disparate entities associated with design, including design artifacts, design processes, design algorithms, and design data, are each regarded as objects. Each design object can contain methods (procedures that act on design objects), data(a named attribute of a design object) and interfaces (the basic structure and interface of a design object).

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

233

Design objects are related to each other by the following object operators: Inheritance (j) which creates an instance B from a design object A. The instance B then can be thought of another design object which inherits the basic structure and methods of A but which can be altered and which can contain its own data. Import (c) which allows design object B to import methods from another design object A. The design object B can now use the methods that are imported from design object A in a similar manner to A. Message passing (v) which allows data to be passed from one design object B to another design object A. This could involve the data or methods associated with A and/or B. Such use of design objects in DwO has several potential advantages. The ®rst potential advantage is that of computability where design can be thought of as a computable design process model. The implication is that a design process model obtained using DwO is not just a descriptive model but a computable model, which computes new stages in the design process using the object operators described above. The second potential advantage is that of reusability where, once a design object has been established, it can be reused. This is allied with the third potential advantage namely that of exchangeability where the modular nature of objects allows for an object to be replaced by another object with a similar one. 3.1. The DwO design model S and other design objects in DwO DwO views the design model (S) as a central element of design. S is the representation of an artifact to be designed and represents a model that consists of one or more design objects, oi,. that can be physical or non-physical objects. From a DwO perspective S ˆ ‰oi;: …z†Š where z is the location of the item and is a variable of the form of a numeric, symbolic and/or Boolean data type. The exact form of S will vary with the design process model and with the artifact being designed. For example, for evolutionary design where the design goes through a number of generations and where there may be several design models at each generation, then Skl ˆ ‰oli;: …z†Šk ˆ ‰ol1;: …z†; ol2;: …z†; ol3;: …z†Š¼o1n;: …z†Šk l where Skl represents the design model l at generation k, and o1,. (z) represents a design object from location z included in design model l at generation k, while n represents the number of design objects in the design model. Note that the design objects may come from differing locations, z. The other main objects in the DwO approach are:

A E R C P

design algorithms and the design process object; evaluation schema object; requirements object; constraints object; selection object.

234

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

3.2. DwO methods A DwO method is a mechanism for changing or creating one or more design objects. In order to apply a DwO method, both the design object(s) to be manipulated and the model to which the method is applied should be speci®ed. Two basic DwO methods can be de®ned, namely add and delete, and any change in the design model S can be obtained by applying a ®nite number of these two basic DwO methods to S. The ¯ow of design operations in the proposed DwO approach is, in essence, represented in terms of DwO methods. A combination of DwO methods is an ordered set of DwO methods that are successively applied to the model. 3.3. Design process models The design objects in DwO can be used to develop a design process model for a particular design problem and domain. Example design process models are described in Liang and O'Grady (1997) and O'Grady and Liang (1998). 4. OODS: object decomposition OODS includes a number of objects from the DwO view of design, described in Section 3. The objects and their relationship are shown in Fig. 1.

Fig. 1. The Overall architecture of OODS.

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

235

Table 1 Major objects in OODS Object

Initial state

Operation state

S O E P R C A

[Null, Null, SD] [Null, Null, SD] [Null, SD, SD] [Null, SD, SD] [Null, Null, SD] [Null, Null, SD] [Null, SD, SD]

[R, Null, SD] [C, Null, SD] [R, Null, SD] [C, Null, SD] [Null, SD, SD] [Null, SD, SD] [USER, Null, SD] [USER, Null, SD] [R/C/ oi, P/E, SD]

The relationships between objects are as follows: Relation Relation Relation Relation Relation Relation Relation Relation Relation Relation

1: instance of design model Skl jdesign model S 2: design algorithm Avdesign model S 3: design algorithm Acevaluation schema E 4: design algorithm Acselection object P 5: instance of design object oijdesign object O 6: design model Skl voi(z) 7: requirements Rvdesign algorithm A 8: constraints Cvdesign algorithm A 9: design algorithm Avoi(z) 10: design algorithm Avdesign model Skl

The architecture in Fig. 1 shows how the particular instance of a design model, Skl ; is obtained from the design algorithm, evaluation schema, requirements, constraints and the design model object. An important point to note is that additional objects can be de®ned within the overall architecture shown in Fig. 1. 5. OODS: object representation Representation is concerned with de®ning an object and organizing objects. Each object described in Section 4 contains three entities namely: data, methods, and a structure. The objects obtain their data primarily by message passing, v, from another object. The methods can be obtained from another object by import, c. The structure is obtained from inheritance j from another object, and this can also contain some data and methods. Table 1 shows the source of the data, methods, and structure for each of the seven main objects in OODS, both in their initial state and in their operational state. SD means that the system designer has prede®ned the content while USER means that the content has been inputted by a user, through the UI object (Section 6). In addition to this, the con®guration system (CS), described in Section 6, is used to initially con®gure the objects. Table 1 shows both the initial and operation sources for data, methods, and structure for each of the

236

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

seven main objects. This migration from initial to operation state is as a result of the following ¯ow of operations: R [USER, Null, SD]: object R receives data from USER C [USER, Null, SD]: object C receives data from USER O [R, Null, SD]: object O receives data from R O [C, Null, SD]: object O receives data from C S [R, Null, SD]: object S receives data from R S [C, Null, SD]: object S receives data from C and imports methods from A oi [USER, Null, O]: instance oi inherits the structure from O and receives data from USER Skl [oi, Null, S]: instance Skl inherits the structure and methods from S receives data from oi A [R/C/ oi, P/E, SD]: object A receives data from R, C and/or oi and imports methods from P and E In this manner objects can be constructed from other objects with inputs from the system designer (SD) and the users. For example, an instance of the design model, Skl can be constructed from four other objects (S, O, R, and C) as shown in Fig. 2, with input from SD and users. This allows for Skl to take a wide variety of forms and hence to represent, for example, designs produced by creative or parametric design. 6. OODS: UI and con®guration objects The above has described how the main operational objects in OODS are de®ned. In addition to these operational objects, two further objects are de®ned in OODS, namely the UI and CS objects. The UI object provides different interfaces for different design problems while the CS object allows the system to be customized for different design problems and domains.

Fig. 2. Obtaining an instance of the design model, Skl ; from other objects.

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

237

Table 2 The input variables and mapping processes of each object for CS object Object

Form

Input variable

S

S ˆ [oi,.(z)]

O

Oi

Methods of design (creative or parametric), number of attributes for each S Number of attributes for each O

R

Ro;p

C

Ci(z)

E

Vlk ˆ f …Skl † ˆ a £ oli;aaa 1 b £ oli;bbb 1 ¼ 1 r £ oli;rrr

A P

Number of requirements, number of attributes for each requirement Number of constraints Number of criteria, weight of criteria

± Selection methods (P1/P2¼)

Actions needed

Mapping attributes between O and database Mapping attributes between R and O Mapping attributes between C and S Mapping attributes between E and S, mapping attributes between E and O

The CS object provides data to the main objects in OODS regarding the con®guration of the design problem, domain, and location of data, for each design problem (Table 2). The CS object is used as follows: Phase 1: Invoke CS. Phase 2: Alter CS parameters, these include: Modes of design (creative or parametric) Number of attributes for each S Number of attributes for each O Number of requirements Number of attributes for each requirement Number of constraints Number of criteria Weight of criteria Selection methods (P1/P2¼) Mapping attributes between O and database Mapping attributes between R and O Mapping attributes between C and S Mapping attributes between E and S Mapping attributes between E and O Phase 3: Develop New UI and using the UI object.

238

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

Phase 4: Deploy the OODS environment so that users can input the requirements and constraints and then perform the design. The UI object provides interface to the main objects in OODS regarding the users' preference and is expected to have the following features: ² Easy to develop. The user can easily develop his own UI through UI object regarding the design problem. ² Easy to use. The developed UI can be clearly used by the other designers without confusion, graphical user interface (GUI) is preferred (see Fig. 4).

7. Implementation: object-oriented design system (OODS) Given the above overall description of OODS, the question remains of how can this be implemented? Certainly, it can be implemented on a single processor with a single user. However, such an isolationist approach ignores the geographic distribution of personnel. To address these aspects, an Internet network based implementation of this system is described. This particular implementation was carried out using a test-bed in the E-Commerce Laboratory consisting of a server running Windows NT with the Internet information server (Fig. 3). ActiveX objects were built and loaded on the server using active server pages. Users can then use OODS using a standard web browser.

Fig. 3. The prototype implementation architecture of OODS.

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

239

7.1. OODS objects Each object in the implementation of OODS is composed of an ActiveX object which can be considered as an enhanced object component. Such an ActiveX object is an element of computer code that adheres to the ActiveX speci®cation (Chappell, 1996). Each object in the OODS system can communicate with other objects by calling their properties and methods, and each object can be maintained independently. 7.2. OODS implementation architecture The overall implementation architecture of the OODS prototype is shown in Fig. 3. For this implementation, the OODS objects reside on the OODS server where they can be accessed by users using a conventional web browser over the Internet. The OODS server can also communicate with multiple databases over the Internet. The CS and UI objects can be either con®gured by the user's inputs during the design or prede®ned by the SD. 7.3. Example application operation Fig. 4 shows the UI for the prototype implementation of the OODS design system, which has been con®gured into three design systems, namely design with modules (DwM), feature-based design, and electronics assemblies design. Each has been individually con®gured using the CS object and each connects to databases scattered across the Internet.

Fig. 4. The initial screen for the prototype implementation of OODS.

240

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

Fig. 5. The design process for electronics assemblies (adapted from Ginsberg (1990)).

7.4. Design scenario The following section will illustrate the operation of the electronics assemblies design system Ð components selection (EACS). Note that this description is necessarily an overview due to space limitations and some simpli®cations have been made to the system to reduce the space required for the description. Electronics assemblies design is composed of a number of activities as shown in Fig. 5. EACS is concerned with the problem of component design, as shown in Fig. 5, where a key design problem is to select a set of components that satis®es the requirements and constraints while maximizing (minimizing) an objective function. Thus the central design problem addressed by EACS is as follows: Given a set of candidate electronics components {oi,.(z)}, at design iteration k, produce a design Slk that is composed of a subset of the candidate electronics components and which satis®es both a set of functional requirements {Ro,.} and a set of constraints {Ci(z)} while minimizing (maximizing) an objective function Vlk, where Vlk ˆ f(Slk). The constraints considered include both operational constraints and concurrent engineering constraints. EACS is implemented as described above, namely as a series of ActiveX objects situated on a server (Fig. 3) and accessed by users via a web page. The CS object con®gures links to relational databases, scattered across the Internet. Let us consider a scenario where a pulser/¯asher electronic assembly is being designed and where the design has reached the stage where the schematic design aspect has been completed (Fig. 5) so that the broad speci®cation of each component has been determined (Liang & O'Grady, 1998). In practice, these would usually be obtained from a computer system that develops a schematic outline of the electronics assembly. The design problem now becomes that of EACS, as described above, to determine the set of speci®c components that meet the overall speci®cation, which form a set of design requirements, while still satisfying a set of constraints {Ci} and while minimizing (maximizing) an objective function Vlk ; where Vlk ˆ f …Skl †: The main objects involved are as follows: The requirements (R) are of the form: {component1.type, component1.spec., component1.x position, component1.y componenti.spec., componenti.x position, componenti.y position}

position´ ´´componenti.type,

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

241

Table 3 A segment of the aggregated component database ID

Spec.

Length (in.)

Width (in.)

Max.

Cost

Vendor

R20030 R20055 R40055 R20090

200 200 400 200

0.3 0.55 0.55 0.9

0.09 0.18 0.18 0.27

100 100 100 100

0.25 0.2 0.3 0.15

± ± ± ±

±

±

The set of constraints {C} include such aspects as the maximum operating temperature, minimum operating temperature, component type, speci®ed cost, and speci®ed reliability. Also included in {C} are concurrent engineering constraints such as Components should not be within 0.2 in. of the board edge (to allow for the equipment to work properly) This can be expressed as an if-then rule as follows: (component. x position-1/2 £ component. length # 0.2 in.)or (component. x position 1 1/2 £ component. length $ board width 2 0.2 in.) or (component. y position-1/2 £ component. width # 0.2 in.) or (component. y position-1/2 £ component. width $ board length 2 0.2 in.) then Violate concurrent engineering constraint E224 Other concurrent engineering constraints are formulated in a similar manner. The design model, S, includes the following design objects: [component1.id, component1.orientation,¼ componenti.id, componenti.orientation] Where component1.id is the identi®cation of the component and where componenti.orientation indicates the orientation of the component. This is expressed as a Boolean variable of 1,0 indicating an orientation of 0 or 908, respectively, to allow for the usual restrictions imposed by electronic assembly equipment. The evaluation schema (E) is taken to be the objective function Vlk , is used to rank components and design models. A weighted attainment objective function certainly can be used, which enables the determination of compromise solutions. This will facilitate the satisfactory ful®llment of different departmental aspects. The set of design objects {oi,..} includes data on design objects and this is contained in vendor databases that may be scattered over the Internet. A segment of the aggregated component database (design object O) is shown in Table 3. Resistors. The user's initial input screen for EACS is shown in Fig. 6 and the user can input such information as the evaluation schema, the design environment, the selection strategy, and the parameters of the genetic algorithm search procedure (if selected). The main design requirements for EACS are contained in a relational database and are pre-connected (using the CS object) to EACS. In practice these requirements in the database are usually generated by an electronics CAD system. The concurrent engineering constraints are stored in the database and preconnected to EACS, again using the CS object. The designer can now invoke EACS by ®rst, inputting the various required parameters (Fig. 6). Let us

242

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

Fig. 6. The input screen of EACS.

assume that the designer enters the data as shown in Fig. 6, namely a maximum cost of $2.8 with a minimum reliability of 0.95, a maximum and minimum operating temperature of 100 and 208, respectively, and the function evaluation and ranking is based on cost. If the designer selects selection strategy P1, EACS conducts a simple search procedure through the Internet, which ®nds the design solutions through the remote database with the lowest cost while not violating the various constraints. A typical result is shown in Fig. 7. As an alternative to this, the designer can use a search mechanism, speci®cally a constrained genetic algorithm search mechanism (Appendix A, Liang & O'Grady, 1997, 1998) that we can include in a new selection object P2 and typical results obtained by selection object P2 are shown in Fig. 8. For this latter scenario, a family of design models (Skl ) are obtained with a minimum cost solution of $1.82 with a reliability of 0.957 compared to a cost of $2.34 with a reliability of 0.952 using selection object P1. However these ®gures are illustrative only: the main principle is that of exchangeability in that the selection object P1 has been readily exchanged with selection object P2 While space limitations do not permit a full description, the above has described a typical design session using the EACS system with example data. One point to note is that the object oriented nature of the approach has allowed for the ready interchange of objects so that object P1 can be readily replaced by P2. 7.5. The implication of OODS In the above-described example, the proposed system OODS has been implemented. However it could be further re®ned and extended in several areas. They are as follows:

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

243

Fig. 7. Example solutions obtained by EACS with selection object P1.

1. Examine the application of OODS to different design problems and domains. With the implication that OODS can be applied to a wide variety of such proposed domains, for example, for discrete parts design, the design rules can be regarded as requirements or constraints. However further testing to test its implementation is required, particular for creative design and variant design. 2. Investigate the possibility of distributed network objects. In this paper, the objects reside at the same location (at the server). However it is thought that the OODS can be readily extended to encompass distributed network objects, but this needs to be investigated. 3. Examine the application of OODS to software design. The OODS system views design objects as being objects that represent not only physical entities but also non-physical entities. It would therefore appear that OODS would be very useful to software design, but this needs to be investigated.

8. Conclusions This paper has described an OODS that uses an object-oriented formalism called DwO. The foundation to OODS is described by an overview of the DwO design model, the other design objects in DwO, the use of DwO methods, the resulting design process models, the decomposition of objects in OODS, followed by a description of the con®guration system object and the UI object. The implementation of OODS is then detailed. This implementation uses the Internet to communicate between OODS and users, and with databases that may be geographically scattered. The use of OODS is illustrated by a description of an example application that involves the design of electronics assemblies.

244

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

Fig. 8. Example solutions obtained by EACS with selection object P2.

While much further research remains to be done, OODS allows for design problems to be con®gured into the system so that the designer can interact with OODS over the Internet to help produce designs that satisfy the various design requirements and constraints. Acknowledgements This work was partially supported by funding from the Nation Science Council of the Republic of China (NSC 89-2213-E-212-008). Appendix A. Constrained genetic algorithm search mechanism Step 1 (re®nement) Re®ne the set of initial design speci®cation into an equivalent set of functional requirement {Ro,p} such that each Ro,. is ready to be mapped into a subset of objects. Ro,p is functional requirement o with attribute p. Step 2 (design initialization) AcE (design algorithm A imports evaluation schema E) AvR&C (design algorithm A gets data from requirements and constraints R&C) The design algorithm, A, used in this example is described below.

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

245

The design model, S, for this example consists of a set of physical design objects [oi,.]. Skl jS (instance of design model Skl inherits from design model S) oijO (instance of design object oi inherits from physical design object O) The physical design object, O, consists of a description of the artifact. {Ro;: }u ˆ {Ro;: } {Ro;: }s ˆ Null Step 3 ( function-object transformation) In this step, each functional requirement is mapped into a set of design objects and the design objects are added to the instance of the design model by applying object design methods. This step involves selecting a functional requirement and then selecting a design object that satis®es the requirement. Step 3.1 Initialization A variety of initialization schemes are possible, including random and user invoked schemes. This step is to try to generate the initial population of design model. (a) If {Ro;: }u ˆ Null; then set {Ro;: }u ˆ {Ro;: } and {Ro;: }s ˆ Null: Add 1 to population number (b) If population size ˆ m 1 1 (m is from user input), then go to Step 3.2 (c) Arbitrarily select one requirement (Ro,.) from{Ro;: }u: : Find a set of electronics components {qi;: …z†} which satis®es the selected functional requirement (Ro,.) with each attributes. The selection can be done by an attribute matching process in a 1:1 relationship where attribute j in electronics component qi;: …z† satis®es attribute p in requirement Ro,p (d) If the set of electronics components {qi;: …z†} is empty, stop. In this case there are no electronics component that will satisfy the selected functional requirement (Ro,.), and the design process can only proceed if either the selected functional requirement is relaxed or if alternative electronics components can be made available. (e) Randomly select one qi;: …z† from the set of electronics components {qi;: …z†}: Using add object methods (Fadd), add the selected electronics component into the current instance of the design model …Skl †: This results in a new design model (New …Skl †). (f) Checks that none of the set of constraints {Ci …z†} are violated when the method is applied. This procedure is called validity-preservation. (g) If the model violates the constraints, undo (e) and delete qi;: …z† from{qi;: …z†}. Then repeat from (e) and choose another qi;: …z†. Otherwise go to (h). (h) Delete the functional requirement (Ro,.) from the set of functional requirements {Ro,.}u. Go to Step 3.1. Step 3.2 Selection (a) Add 1 to the generation number. If the generation number is greater than k, stop (b) Evaluate each design model using the objective function Vlk ; where Vlk ˆ f …Skl †: (c) Use an appropriate selection strategy to select the new population.

246

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

Step 3.3 Crossover Apply the constrained crossover method to the design models that are selected for crossover. In this proposed constrained crossover method, a crossover point is selected and components are exchanged between model one at a time and the validity is checked after each component is exchanged. If the result is infeasible then the exchange is cancelled and another component is selected. In this manner the ®nal result will be a population of design models that are feasible. Step 3.4 Mutation Apply the constrained mutation method to the design models that are selected for mutation. In this proposed constrained mutation method, a design model Skl and mutation point are selected. A member of the feasible subset of components then replaces the selected component and the validity of the resulting new design model is checked. If it is invalid then the replacement is cancelled and a new design model Skl and mutation point are selected. Go to Step 3.2. References Akman, V., Hagen, P. J. V., & Tomiyama, T. (1990). A fundamental and theoretical framework for an intelligent CAD system. Computer-Aided Design, 22 (1), 352±367. Bardasz, T., & Zeid, I. (1992). Cognitive model of memory for mechanical design problems. Computer Aided Design, 24 (6), 327±342. Bebb, H. B. (1989). Quality design engineering: The missing link to US competitiveness, keynote address. Proceedings of the NSF Engineering Design Conference. Amherst: SME, June 1989. Booch, G. (1994). Object oriented design with applications, Menlo Park, CA: Benjamin/Cummings. Chappell, D. (1996). Understanding ActiveX and OLE, Strategic technology series. Microsoft Press. Coad, P., & Yourdon, E. (1991). Object-oriented design, NJ: Yourdon Press. Dopplick, T. (1995). A science user's guide to the EOSDIS core system (ECS) development process. Technical Paper 160-TP003-001, Science Of®ce, EOSDIS Core System Project. Finger, S., & Dixon, J. R. (1989). A review of research in mechanical engineering design. Part 1: Descriptive, prescriptive, and computer-based models of design processes. Research in Engineering Design, 1, 51±67. Finger, S., Fox, M. S., Prinz, F. B., & Rinderle, J. R. (1992). Concurrent design. Applied Arti®cial Intelligence, 6, 257±283. Gero, J. S. (1990). Design prototypes: A knowledge representation schema for design. AI Magazine, Winter, 26±36. Ginsberg, G. L. (1990). Printed circuits design: Featuring computer-aided technologies, New York: McGraw-Hill. Kannapan, S. M., & Marshek, K. M. (1992). Engineering design methodologies: A new perspective. In A. Kusiak, Intelligent design and manufacturing (pp. 3±38). New York: Wiley. Kim, C. (1994). A representation formalism for feature-based design as a formal concurrent engineering approach. PhD thesis, North Carolina State University, Raleigh, NC. Kusiak, A., Szczerbicki, E., & Vujosevic, R. (1991). Intelligent design synthesis: An object-oriented approach. International Journal of Production Research, 29 (7), 1291±1308. Liang, W. Y., & O'Grady, P. J. (1997). Genetic algorithm. Computers and Industrial Engineering, 33 (3±4), 593±596. Liang, W. Y., & O'Grady, P. J. (1998). Design with objects: An approach to object-oriented design. Computer Aided Design, 30 (12), 943±956. Liu, C. (1996). Smalltalk, Objects, and Design, Hardbound. Maher, M. L. (1990). Process models for design synthesis. AI Magazine, Winter, 49±58. O'Grady, P., & Liang, W. Y. (1998). An object oriented approach to design with modules. Computer Integrated Manufacturing Systems, 11 (4), 267±283. Silverman, B. G., & Mezher, T. M. (1992). Expert critics in engineering design: Lessons learned and research needs. AI Magazine, Spring, 45±62. Simon, H. A. (1969). The sciences of the arti®cial, Cambridge: MIT Press.

W.-Y. Liang, P. O'Grady / Computers & Industrial Engineering 40 (2001) 229±247

247

Smithers, T. (1989). AI-based design versus geometry-based design or why design cannot be supported by geometry alone. Computer-Aided Design, 21 (3), 141±150. Takeda, H., Tomiyama, T., & Yoshikawa, H. (1992). A logical and computable framework for reasoning in design. Design theory and methodology Ð DTM'92 (p. 1). New York: ASME. Waldron, M. B. (1987). Modeling of the design process. In H. Yoshikawa, D. Gossard (Eds.), Intelligent CAD, I: Proceedings of the IFIP TC 5/WG 5.2 Workshop on Intelligent CAD (pp. 13±27), Boston, MA, 6±8 October. Whitney, D. E. (1990). Designing the design process. Research in Engineering Design, 2, 3±13.