고객 중심의 설계 제조공정 지원 시스템 모델링

- 시나리오 기법을 중심으로 -

A Customer involved Collaborative design

and manufacturing process support System modeling

- Scenario Centered Perspective -

박 화 규*

Hwa-Gyoo Park*

Abstract

As business organizations are struggling to compete in the global marketplace, they are concentrating on the efficient utilization and manipulation of numerous information on design, production, and, distribution of final output, and the throughout their whole life cycles in the Internet based virtual enterprise environment. To meet these organizations□ demands on information integration, the collaboration has been recently focused as a dominant philosophy.

Journal of the Korean Institute

of Plant Engineering

Vol.7,No.2, JUN 2002

In addition, as the complexity of a system increases, the collaboration of the design and manufacturing process becomes a critical issue to productivity. Typically, a large-scale engineering project is carried out through collaboration of engineers scattered across space and time. This paper presents a customer Involved collaborative design and manufacturing process support system (CCS) modeling based on scenario centered perspective, and the CCS requirement analysis is proposed under the concept of collaboration among customer, design sector, and manufacturing sector of participants. The suggested analysis system includes a distributed design and manufacturing process support framework, and rules and methods for information management over the Internet. Based on the proposed modeling, the CCS system is developed. The result of this research will enable the practice of collaboration and consequently help increase product development capability and quality, reduce development cycle time and cost, and hence increase product marketability.

key words＞modeling, design, CCS, collaborative design

* dept of Management Information Systems, Kyungdong University

2001년 12월 접수,  2002년 3월 게재확정

1. Introduction

고객 중심의 설계 제조공정 지원 시스템 모델링

박화규

Today□s industry is undergoing fun-damental transformations, driven by the need to be competitive on a global scale, and by a technology, the Internet, that is pushing more and more force into the customer sides. To survive these rapidly changing competitive pressure, suppliers need to reconsider their system completely in the perspective of customers. Therefore a winning strategy has to move up the value curve from simple supply in supplier□s side to customer oriented colla-borative supply in customer□s side, this means a system enabling let customers confidentially access wanted information and collaborate in real-time to provide customers with the most complete and competitive services possible over the Internet

Most new trend of the Internet-based commerce definitions emphasizes on the importance of exchanging information in the initial stage of design. Consequently, they focus on its customer behaviors in the conduct of the Internet based- commerce. That information is not just a supporting element of the value-adding process, but a source of value itself; that organizations apply useful information to make more timely, better decisions of customers.

This paper places emphasis on the CCS in the sphere of design activities before e-procurement. There have been a various CCS type of systems, Systems such as engineering data management (EDM), product data management (PDM), product information management (PIM), technical document management (TDM), technical information management (TIM) and others are commercially available for the practice of collaborative engineering  [5]. They also provide a structured way to orderly and efficiently store, integrate, manage and control both the data and engineering process from design, manufacturing to distribution however just in supplier□s side and its□ functional perspectives [5].

Although they also ensure that the right information is quickly provided to the right place, at the right time, in the right formats, within the practice of CCS, the communication error and misunder-standing are increased while customer and inter-enterprise communication and process control, system heterogeneity.

In addition, there have been Various modeling methodologies to materialize the a various CCS type of systems - CIM-OSA (open system architecture for computer integrated manufacturing), PERA (Prude Enterprise reference architecture), and GRAI-GIM (GRAI integrated meth-odology) [AMICE, 1988; Williams, 1994a; Williams, 1994b], IE (information engi-neering) [Martine, 1998], IDEF [De-partment of Defense 1993], IFEM (Inte-grated Framework for Enterprise Model-ing)[Malhotra et al. 1992] Object Flow Model (OFM) [Delcambre et al. 1990], SSAD (Structured Systems Analysis and Design) Enhancement [Eddins et al. 1991], HPM (Hierarchical Process Modeling) [Mujitaba 1994], SADT, IDEF0, IDEF1, IDEF2, DFD Integration [Banerjee et al. 1989], UML [fowler et al 1997].

Nevertheless, the range of CCS is so unique and broad that no single formal modeling methodology is relevant for developing all of them. Although these previous methodologies have there own advantages, they are not so appropriate and successful in developing such a modeling. A new approach is needed in order to develop CCS activities and im-plementation. From this motivation, this paper provides a CCS integrated metho-dology for developing the systems that support Customer Centered Collaborative design work activities, and modeling technique.

The main drawbacks of previous approaches to the current related proposed system disregards a philosophy of the emerging needs enabling let customers confidentially access wanted information and collaborate in real-time to provide customers with the most complete and competitive services possible over the Internet. The target domain examples are as follows＞

◑ Electronic Industry＞In the National.com, a design engineer logs on the site over the Internet, and is prompted to specify the overall parameters for the required electronic part and to identify the key components needed. The system automatically generates possible design, along with complete technical specifications, prices, and cost-benefit analysis.

◑ Construction industry＞Buzzswa.com is a b2b market place and collaboration workspace for the $3 trillion building design, construction, and real estate management in industries. Buzzswa.com helps building professionals-architects, engineers, underwriters, contractors, and facilities managers- to work more effi-ciently at every stage of the con-struction and building management pro-cess.

◑ Printing industry＞Impresse is a pro-vider in the emerging market for b2b e-commerce solution for the crea-tion and procurement of commercially printed material. The hosted impresse.com service provides a platform for cor-porations, their commercial print sup-pliers, their design, advertising and marketing agencies, and other partici-pant in the enterprise print supply chain to design, specify, price, order, track, fulfill, and pay for print job.

The drawbacks in the modeling technique points of view to support the collaborative  activities are as follows＞

Limited ability to represent the Col-laborative  activities＞In the system, the activities require the full details of implementation. The Collaborative  system, which is the combination of the required services and activities and the specifi-cation of methodology, must be predefined in advance. However, in previous re-searches, understanding Collaborative  activities is difficult, and sharing and continuously improving the process is not possible.  Also, most systems are weak in modeling the dynamic behavior of the activity processes.

Lack of formalism＞Because they lack formalism, it is not easy to predict the behavior of Collaborative  activities and to analyze whether a Collaborative  activities satisfies initially required services and requirements.

Lack of flexibility＞Modifying the col-laborative system in short period of timely is not easy. For flexibility, overall consistency, reusability have to be supported in the modeling methodology However, most methodologies are not seamlessly indicate the guide line of system design, system modeling, and system development.

No strong tie between Internet based virtually distributed business to business environment＞The activities generate a large amount of data of various activities.  Current methodologies are weak in capturing the relationships of virtually distributed collaboration and transaction between participants or e-partners.

2. Methodology Overview

This section presents an overview of the modeling of the proposed CCS approach over the Internet. It includes three stages. Stage one is the devel-opment of CCS require-ment and data representation and its□ ma-nagement, stage two is the modeling of the CCS system, and in the third stage, the final outputs of the modeling, physical component classes, are mapped into com-ponent architecure to materialize the CCS system with the consistency, productivity, efficiency.

Stage 1＞CCS system analysis.

During this stage, the definition and re-quirement of CCS activities are given based on the concepts of customer basis. The characteristic analysis of a CCS process is then conducted based on the definition. According to the characteristics of CCS defined, the life cycle of CCS information management is proposed. A CCS is then developed based on the proposed CCS information management life cycle.

Stage 2＞System modeling.

Main tasks in system development include Participant Analysis, activity Analysis, Biz Component Analysis, and Physical component Design.

According to the proposed methodology, the environment and requirements of CCS are first identified. Participant Analysis and activity Analysis define what the system must do and provide the guide-lines for system development, and activity diagram break down of information flow from participant diagram into detailed roles, namely activities.

The details are added to the design model in accordance with the requirement established during System analysis stage. In the proposed approach, role and its scena-rio based modeling techniques are employed to define the structures and behaviors of the elements in the system as well as the relationships among the participants. The result of system mo-deling is a set of phy-sical component  classes that corresponds to the elements in the system. The physical component architec-ture is classified into VCO(Visual COmpo-nent), LCO(Logic COmpo-nent), DCO(Data COmponent), KCO(Know-ledge COmponent), NCO(Neural net COmpo-nent), and SCO(Service COmponent

Stage 3＞System development.

The third Stage is System development. In the stage, all the extracted components from the modeling stage are seamlessly mapped into pseudo codes and user inter-faces.

Each stage involves several steps of activities as shown in Fig. 1.

Fig. 1 Proposed methodology architecture

3. System Implementation

3.1  The system analysis

In this section, the characteristics of CCS are analyzed. Based on the charac-teristics, a CCS management methodology is developed with the outputs of a life cycle model, a framework and methods for CCS information management. The result of system analysis will pave the way for system modeling and develop-ment.

3.1.1 CCS definition and characterization

A design engineer logs on the CCS over the Internet, and is prompted to specify the overall parameters for the required mechanical part and to identify the key components needed. The system automatically generates possible design, along with complete technical speci-fications, prices, and cost-benefit analysis. The engineer then refines the designs until one appears to satisfy the require-ments. After the engineer check the manufacturability of the part, the engineer can then run real-time simulations of the design, using a parametric programming software application provided on the site by CCS system. The engineer can alter the design and simulate it as many times as necessary and then save all the iterations in a private portfolio or even e-mail links to colleagues so they can run the saved simulations.

Once the engineer settles on a final design to be tested. The system can generate production process plan for creating prototype. The plan list includes are required for the engineer□s company as well as other manufacturers. It has links to distributors for the part. And because CCS system is tied in directly to the participants for design and manu-facturer, the engineer can order the parts with a single click.

The classification encoding of a part design is determined by a user's re-sponses to queries provided by the sys-tem. The CCS will attempt to retrieve similar existing designs or a generic template into which parameters are auto-matically inserted to instantiate the design and produce a wireframe model.

The scenario based requirements extrac-tions can be summarized as follows as shown in Fig2.＞(in this paper, we focus on the modeling method, therefore, we assumed that target domain□s requirements are pre-defined and represented partly using LISP language format because of its attractive point of making compact pseudo codes.)

(1) Detailed Scenario flow

Fig. 2 CCS system Scenario

１ Input requirement stage

Step 1＞Generating the 5-digit design code.

A customer accessed CCS and queries about the external and internal shape of a new part, and answers determine primary design attributes.  Each of the 7 design code subframes has its own rules and parameters and works independently.  The □considerframe□ function in CCS engineering system instantiates the proper frame; for instance, the rule for instantiation of another subframe is IF part is □rotational component with deviation□ THEN CON-SIDERFRAME rot with deviation

After assigning a value to the fifth design code digit, the system generates the cluster code to represent the overall shape of the part, which is determined by the first and second digits of the design code.  This consists of the component's class which, in turn, is divided into 7 subgroups, each with its own meaning, and several part families, depending on the component class.

Part families in CCS have 26 different codes, each having unique parameters.  After the form and cluster codes are determined, the CCS system will instan-tiate the manufacturing frame to generate the supplementary code.

Step 2＞Generating 4-digit supplementary code.

The system now queries about, as that are useful in manufacturing, such as dimension, material, initial stock shape, and accuracy.  These queries, which are independent on the form and cluster codes, determine the supplemental code.

-Review design alternative

Step3＞Finding the design template for the part.

(If a template model does not exist, the database retrieving frame, step4, is ins-tan-tiated instead.) Let□s say, based on answers to queries, the system locates a template model, instantiates the subframe SAMPLE1, and prompts for a part name to be assigned to the DESIGN model for dimensional values which are stored in external files.  The template is a .CDL file consisting of geometric primitives such as point , line, and circle, with unassigned parameters, e.g., the x, y, and z coor-dinates for a point.  CCS  then invokes a parametric program that replaces para-meters in the design template with values previously stored in a file to create a DESIGN model of the new part.  There-fore, many different models that share common geometric and topological fea-tures can be generated from a single generic template.

- Design simulation (parameter based)

Finally, CCS  stores information about the new part, such as design code, supple-mentary code, cluster code, and DESIGN file name, under case database.  The case database-append function, which enables a user to append information to the case database, is used; for instance, one of the rules in the SAMPLE1 frame representing the operator to access external files is as follows＞

IF＞R1>0 and R2>0 and R3>0 and L1>0 and L2>0 and L3>0 and partname is known and description is known

THEN＞DONE1=□ok□ and write-file □dimension.dat□ quote (R1 R2 R3 L1 L2 L3) and write-dos-file □model-name.txt□ quote (partname) append and dBase-append □gtbase□ for-mcode=fcode suppcode=scode cadfile =partname flag=□N□ partfm=x com-ment=description and dos-call cad-model.exe " " ")

where R1, R2, R3, L1, L2, and L3 are parameters which represent the  dimen-sion of the part; partname is the DESIGN model file

DONE01 is the goal of the SAMPLE1 frame; Design_code, manufacturing_code, cadfile, flag, partfm, comment are field name in the □gtbase□ which is the data-base design case base; Fcode is the design code of the part; Scode is the supple-mentary code; and X is the cluster. The □dimension.dat□ and □modelname.txt□ are external files for communication between CCS  systems and DESIGN

To find the goal, DONE01, of the frame, this rule will be instantiated. Since the system uses backward chaining, it asks for the IF-part of the rule first.  To get values for the parameters in the IF-part, the system queries for R1, R2, and the other parameters.  After satisfying the IF-part, the system asks for the related THEN-part.

- Design simulation (classification based)

Step 4＞Retrieving the design case base part data file.

If the query fails to locate a template model, the system attempts to find similar models in order to allow a user to modify an existing DESIGN model.  The CCS ENGINEERING system links with case database to find similar models using the cluster code.  The □dbase-retrieve□ function is used to obtain information from the database, and the parameter FIND is used display the name of a similar DESIGN part file.  For instance, the value of the EXPECT parameter could be expressed as follows＞

EXPECT＞dbase-retrieve gt-base (QUAL PARTFM =X) CADFILE

where □gtbase□ is the case database data filename ; partfm and cadfile are the field names in □gtbase□ representing the cluster code and the DESIGN model file name, respectively; X is the cluster code of the new part; and (QUAL PARTFM=X) means that the system check the cluster code which was stored in the □gtbase□ data file.

If similar models exist, their filenames are displayed, a user selects one of the names, and the system displays a view of the model using the □picture□ function of The CCS system.  After viewing similar parts one-by-one, a user decides which model most closely resembles the new design and exits CCS ENGINEERING to modify the selected DESIGN model. If no model is found to be sufficiently similar, a new design may be created within DESIGN.

- Optimal selection and final design

Step 5＞Modifying a DESIGN model.

A user can modify a DESIGN model using DESIGN interactive functions,  Subsequently, the user must capture a picture of the model using The CCS system's □snapshot□ utility by sizing and framing the model, saving it, and copying it into The CCS system. Since information for this part was already stored in the case database part file by the system, a user need not update the database for the picture file.  However, if a new DESIGN model was created the user must record information about the new part including its associated picture file.  Thus, finally, the user re-enters the CCS and updates the case database part file for storing information about the new part.

- Manufacturing process information retrieval and order

Step6＞Process plan template

Using manufacturing build index, user retrieves a template or similar process plan and modifies the plan to check the selected part is manufacturable. Finally, user reenters the system and updates the part database for two types of part families, design code, supplementary code, PP code, and part specification information about the new part. Once the engineer settles on a final design the system generate a prototype and order them.

As the preceding discussion illustrates, engineering collaboration is not simply a piece of software information system; rather it is a solution that can be architected around each customer's unique combination of heritage systems, ERP applications, and other information repo-sitories. The basic ability to find, manage, and deliver customer's product-related information represents the foundation for any engineering collaboration portal solution.

The design and build feature coding system presented has been used developed in the feature-based, CCS engineering. The system was developed is aimed at generating a cost and fast time to market based design requirements and requires product able system.

The CCS engineering task is carried out through the following steps.

3.2 System Modeling

The following steps will be elaborated for a engineering collaboration case study.

Step 1＞participant diagram

This diagram is described in terms of participants□ engineering collaboration  and their causal relationships. It is drawn to delimit engineering collaboration system to be developed.

The design of a participant diagram starts with the relation and rough infor-mation communication structure. The diagram is based on the hybrid format approach of workflow and context diagram used in structured modeling method.

Fig. 3 participant diagram and notations

Step 2＞participant diagram

This is a useful diagram identifying participants such as internal, external collaborative participants and sub participants including customer, and easily identifying the required activities, and its interaction based on scenario flow. Key points are that the diagram is showing a bird□s eye view of the whole message scenarios in participants and sub partici-pants perspective. There was no proper diagram so far in the previous researches for engineering collaboration to represents participant and/or e-partner oriented perspectives.

The diagram is described in terms of individual collaborative participants tasks and detail information flows.

Fig. 4 Collaborative diagram and notations

Clearly, a description in terms of business components extraction from the workflow based Customer centered scenario diagram  is too detailed to start with, even if the participants, activities, and other additional information can be extracted.  Therefore, another technique, which represents best the interorgani-zational participants and its instances is needed. We use particiant diagram , a variant of message sequence chart(MSC), for this purpose. MSCs are a graphical language for the visualization of com-munications between systems/processes [1].  Each message has a sender and a receiver. The customer ordering activities is specified by the time axis of an instance, which is represented by a vertical line.

Step 3＞Component Analysis Card(CAC)

CAC are adopted from CRC(collaborator, resource card) because they have attractive informal appeal helping make complex modeling tractable. However, in this paper we extended the CAC by adding function, logic, variable and linking to corresponding   participant description, so that particianpt oriented modeling technique are consistently kept without loosing any specification and information extracted when transited into other diagram or card.

To facilitate the identification of system classes, we stereotyped a [8] CAC into physical component as described above, and then the component are decomposed into proper type of classes according to whether they exhibit external interfacing, business ruling and controlling, or entity management characteristics.

The principle of component technology making possible that standard engineering software use modules from other manu-facturers [Cheng, 94]. The components are classified into 5 types.

(1) BCO (Business COmponent)

BCO contains SCO, business application component, business transaction compo-nents, however, in a narrower perspec-tives, only VCO, LCO, DCO, KCO, NCO are categorized.

- VCO(Visual COmponent)＞The VCO encapsulates the visual user interfaces related a Screen ScreenProcess, Control and a Dialog component type. The ScreenProcess is broken down into ASP(After ScreenProcess), BSP(Before ScreenProcess), and CSP(Common ScreenProcess) once again. Transactions  contain several screen or dialog steps, and the screen begins with the preparation and subsequent transmis-sion of the input screen to the user's screen. The two type of screen step processing are ASP, and BSP.

- LCO(Logic COmponent)＞The LCO refers to programs performing appli-cation logic, and upper-level method.

- DCO(Data COmponent)＞DCO refers to relational table components for application, and element components.

- KCO(Knowledge COmponent)＞KCO encapsulates rules, meta-rule, and reasoning engine[Park, 98].

; Knowledge Source Sub Component＞it stores the facts and heuristics of domain experts.

; Working Memory Sub Component＞it contains the information the system has received on the problem at hand. Any information the component drives on the problem is stored in here.

; Inference Engine Sub Component＞it provides the system control and applies the expert domain knowledge to present situation.

- NCO(Neural net COmponent)＞NCO encapsulates Conversion, NN Data-base interface, NN Recall, NN Lear-ning, Restructuring

; Conversion Sub Component＞it is a Sub Component for the conversion process.

; NN Database interface＞it is a Sub Component that stores and manages the coefficients, weighting vector, size, and learning patterns of neural network.

; NN Recall Sub Component＞it is a Sub Component that restructures neural network model utilizing the coefficients, weighting vector, and size stored in NN database.

; NN Learning Sub Component＞After reading the size and learning patterns of neural network in NN database, constructing a multi-layer perceptron model of neural network, and com-pleting training process as specified, this Sub Component returns coeffi-cients and weighting vectors to the NN database.

; Restructuring Sub Component＞A Sub Component that generates topological information.

Figure  illustrates the Proposed Devel-opment Tool Structure, which is consists of the briefly mentioned components.

(2) SCO(Service COmponent)

The service component is for the support component edit and execution. The SCO is a core component, which have a role of supporting component framework. It is a standardized interface for linking compo-nents, and services are an elementary part of open programming environments. The component is implemented to manipulate the components, attributes and methods. It acts as suggested system servers.

Fig. 5 Component analysis diagram and relationship

Step 4＞Physical component Class Extrac-tion

To facilitate the identification of system classes, we stereotyped a [14] CAC into user class, control class, data class, and entity class according to whether they exhibit external interfacing, business ruling and controlling, or entity manage-ment characteristics.

Fig. 6 CAC into Physical Component Classes

Step 4＞Component based class imple-mentation

According to component based class implementation, each class is implemented.

LCO-Program Pseudo Code for design code generation

Program 05

=======

IF＞(SEL = □DESIGN CODE□ AND ! ROT AND ! PART'1 AND PART-NON <= 3 AND

PART-NON' >= 4 )

THEN＞(D1 = 6 AND PICTURE F)

PREMISE＞($AND

(SAME FRAME SEL □DESIGN CODE□)

(NOTSAME FRAME ROT)

(NOTSAME FRAME PART'1)

(LESSEQ*

(VAL1 FRAME PART-NON) 3)

(GREATEQ*

(VAL1 FRAME PART-NON') 4))

ACTION＞(DO-ALL

(CONCLUDE FRAME D1 6 TALLY 100)

(PICTURE □Nonrot□))

Fig. 7 LCO-Program Pseudo Code for design code generation

LCO-method Pseudo Code for DB interface

IF＞(code=0000000001 and,  name=axis )

THEN＞(append and dBase-append □gtbase□in design sector)

Fig. 8 LCO- method Pseudo Code for DB interface

LCO-knowledge Pseudo Code for Parametric Parameters

RULE135

===========

IF＞Dia1>0 and Dia2>0 and Length>0 and partname is known and description is known

THEN＞connecting_rod_type1 = □ok□ and write-dos-file

□dimension.dat□ quote (Dia1 Dia2 Length) and write-dos-file □modelname.txt□ quote (partname) append and dBase-append □gtbase□

Design_code=fcode Mfg_ code=scode

cadfile=partname

flag=□N□ partfm=x comment=description and dos-call cadmodel.exe " " ")

EXPECT＞dbase-retrieve gt-base (QUAL PARTFM =X) CADFILE

Fig. 9 LCO-knowledge Pseudo Code for Parametric Parameters

VCO-screen for data input

Fig. 9 VCO-screen for data input

This screen is to generate design can-didates by identifying and combining proper design features. This can be accom-plished by either using LCO-knowledge based or through a hyper media navi-gation based search within design feature clusters case base

Fig.10 Design simulation

In the Fig.10, the most cost and time effective design is found out using the optimization search scheme based on classifi-cation. The most cost and build effective design satisfies the design requirement and requires minimizing production cost, time, and manufacturability.

3. Environment of System Im-plemen-tation

Based on the results of system design and modeling, a CCS prototype was im-plemented. To support interoperability in a heterogeneous environment, the system was implemented based on the concept of CORBA (Common Object Request Broker Architecture) [15]. Each of the compo-nents in the system was defined as a distributed object and packaged as an independent piece of code that could be accessed by remote clients via method invocations. The object request broker (ORB) is the component that establishes the client/server relationships between the objects. Using an ORB, a client object can transparently invoke a method on a server, which can be on the same machine or across a network.

Fig. 11 CCS Implementation Environ-ment Structure

4. Conclusion

Industrial enterprises are currently faced with fundamental changes in the overall application framework. Aggressive early adopters are now leveraging the Internet for a far more strategic advantage. These companies are participating in Colla-borative Commerce by collaborating with partners to share product designs, procure-ment plans, demand forecasts, manu-facturing schedules, distribution activities, and transportation movements. Collabo-rative Commerce is the ultimate evolution of electronic commerce since it involves developing joint business plans and the collaborative execution of those plans.

Typically, a largescale engineering project is carried out through cooperation of engineers scattered across space and time. For example, cars are designed jointly by several teams, and parts are designed and manufactured by plants across the world.  It is becoming necessary to provide an infrastructure for virtual enterprises in a globally competitive yet cooperative environ-ment.  The infrastructure must integrate advanced enterprise and enterprise sys-tems, provide interfaces with product data, and coordinate the business process, all through the information highway.

The proposed modeling method guides developers in creating systematic oriented CCS system. The methodology was developed under the principles of con-sistency, productivity, and reusability. These results will enable the practice of CCS-based c-commerce, and consequently help increase system development capa-bility and quality, reduce development cycle time and cost, and hence increase product marketability.

References

[1] R Helm, I. Holland, and D. Gango-padhyay □Contracts＞Specifying Beha-vioral Compositions in Object- Oriented Systems,□ Proceedings of OOPSLA/ECOOP, 1990.

[2] Margarida F. Jacome and Stephen W. Director. □Design Process Manage-ment for CAD Frameworks□. Procee-dings of the 29th Design Automation Conference, pp 500-505, 1992.

[3] Eliseo Mambella, Roberto Ferrari et al, □An Integrated Approach to Soft-ware Reuse Practice,□ SSR □95, Seattle WA, USA, pp. 63-71, 1995.

[4] Carma McClure, The Three Rs of Software Automation＞Re-Enginee-ring, Repository, Reusability, Prentice Hall, 1992

[5] Orfali, Harkey and Edwards, The Essential Distributed Object Survival Guide, Wiley, 1996.

[6] Hwa Gyoo Park, □Multi Agent System Based Manufacturing System Enhancement□, Proceedings of Con-current Engineering □98 Japan, 1998.

[7] Hwa Gyoo Park, □Feature Recognition System Based on Neural Network Technique□, Proceedings of 4World Congress on Expert Systems, 1998.

[8] Steven H. Kim, □Optimizing Product Design in Cyberspace through Know-ledge Mining Agents□ Proceeding of Korea Management Science, pp. 56∼58, 1998.

[9] Michael J. Shaw, Uday Menon, Snagchan Park, □Machine Learning In Knowledge-Based Process Planning Systems, 1990.

[10] Han, J. and Requicha, AAG., Mdeler- Independent Feature Recognition in a Distributed Environment, Computer- aided Design, Vol. 30, No.6, pp. 453∼463, 1998.