A collaborative data management framework for concurrent product and process development

This article was downloaded by: [The UC Irvine Libraries]On: 08 November 2014, At: 18:26Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office:Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

International Journal of ComputerIntegrated ManufacturingPublication details, including instructions for authors and subscriptioninformation:http://www.tandfonline.com/loi/tcim20

A collaborative data managementframework for concurrent product andprocess developmentYuh-Min Chen & Yun-Tau HsiaoPublished online: 08 Nov 2010.

To cite this article: Yuh-Min Chen & Yun-Tau Hsiao (1997) A collaborative data management frameworkfor concurrent product and process development, International Journal of Computer IntegratedManufacturing, 10:6, 446-469, DOI: 10.1080/095119297131020

To link to this article: http://dx.doi.org/10.1080/095119297131020

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the“Content”) contained in the publications on our platform. However, Taylor & Francis, ouragents, and our licensors make no representations or warranties whatsoever as to theaccuracy, completeness, or suitability for any purpose of the Content. Any opinions and viewsexpressed in this publication are the opinions and views of the authors, and are not the viewsof or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shallnot be liable for any losses, actions, claims, proceedings, demands, costs, expenses, damages,and other liabilities whatsoever or howsoever caused arising directly or indirectly in connectionwith, in relation to or arising out of the use of the Content.

This article may be used for research, teaching, and private study purposes. Any substantialor systematic reproduction, redistribution, reselling, loan, sub-licensing, systematic supply, ordistribution in any form to anyone is expressly forbidden. Terms & Conditions of access and usecan be found at http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/loi/tcim20

http://www.tandfonline.com/action/showCitFormats?doi=10.1080/095119297131020

http://dx.doi.org/10.1080/095119297131020

http://www.tandfonline.com/page/terms-and-conditions

A collaborative data management framework forconcurrent product and process development

YU H -M IN C H EN an d YU N -TAU H SIAO

Abstract. This paper presents a systematic approach, fromdomain investigation and functional requirement analysis,through modelling to implementation, to development of acollaborative data management framework that m akes useof object-oriented techniques. The framework can supportinformation sharing and team data management in concur-rent product and process development by providing func-tions for project con® guration, personal product and processitem management, and team library management. Establish-ing this framework involves: (i) identi® cation of functionalrequirements for computer-aided engineering data manage-ment through the investigation of a concurrent productdelivery process with emphasis on product and processdevelopment; (ii) use of system engineering and object-oriented modelling techniques for development of theproposed framework. A product structure and a projectcon ® guration are devised for the development of an objectmodel, and a functional model. They are used together as thebasic construct of the collaborative team data managementframework.

1. Introduction

In recent years, one of the most signi® cant impactson product and process development has been madeby the application of data managem ent techniques.They are known as Product Data Management (PDM),Engineering Data Management (EDM), EngineeringDocumentation Management (EDM), and IntegratedProduct Data Management (IPDM) (E. Miller 1993,Stover 1993). The initial objective of applying thesetechniques was to provide methods for the storage andretrieval of electronic product data (e.g. productgeometry, product structure, and design documents)that were created in the product development process.Lately, the techniques for process and work¯ ow manage-ment, and for product structure management have also

been provided to better manage the product data anddevelopment process (Mills et al. 1991).

In the 1990s, concurrent engineering has beenemployed to improve product manufacturability andquality and to reduce development cycle time and costby resolving product, process, and organizational issuesat the early stage of design. Since the new product andprocess development practice requires the simulta-neous incorporation of a wide variety of design exper-tise, as well as knowledge of engineering and theselected manufacturing processes, product developersmust manage diverse, heterogeneous data that supportthe needs of various applications (Chen et al. 1994,Cleetus 1992, Nagy et al. 1992, Davis and Trapp 1991).Therefore , data managem ent plays an increasinglyimportant role in a concurrent engineering environ-ment (Bradley and Agogino 1991, Wong and Sriram1993).

The practice of concurrent engineering is to per-form product and process development activities con-currently and cooperatively by a multi-functional teamof experienced engineers. This process is referred to as`concurrent product and process development’. Tofacilitate the coordination and management of concur-rent engineering processes, there is a need to providetools that can help manage product delivery activitiesand track products from conception to retirement and,at the same time, support effective communication andinformation sharing among functional groups andindividuals of a product development team.

This paper presents a collaborative data manage-ment framework which is capable of supportinginformation sharing and team data management inconcurrent product and process development by pro-viding functions for project con ® guration, personalproduct and process item management, and teamlibrary management. Establishing this frameworkinvolves: (i) identi® cation of functional requirementsfor computer-aided engineering data management

0951-192X /97 $12.00 q 1997 Taylor & Francis Ltd

INT. J. CO MPUTER INTEGRATED M ANUFACTURING, 1997, VOL. 10, NO. 6, 446 ± 469

Authors: Yuh-Min Chen and Yun-Tau Hsiao, Institute of Manufacturing

Engineering, National Cheng Kung University, Tainan, Taiwan.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

through the investigation of concurrent product deliv-ery process, with an emphasis on product and processdevelopment; (ii) use of system engineering and object-oriented modelling techniques for development of theproposed framework. A product structure and a projectcon ® guration are devised for the development of anobject model, a dynamic model, and a functionalmodel. They are used together as the basic constructof the collaborative team data management framework.

2. Domain investigation and functional requirements

analysis

This section reviews the product delivery process,focusing on the characteristics of concurrent productand process development so as to help identify thefunctional requirements for team data management.The results of this review will be used for developing theproposed collaborative engineering data managementframework to facilitate concurrent product and processdevelopment.

2.1. Product delivery process

Product deliver y process is de® ned as the series of stepsthat take levels of product functional requirementsand, using tools and methods, translate them into tech-nically sound products that meet those requirements. Itconsists of several phases, including proposal prepara-tion, concept formation, design, production support,and fabrication (Clausing 1994, L. C. G. Miller 1993,Mills et al. 1991).

(1) Proposal preparation. The product delivery pro-cess typically begins at the receipt of a custom er requestfor proposal or as a response to marketing planning. Aset of system level and derived requirements are gen-erated, from which the product design draws, in orderto formulate and develop product concepts that areincorporated into the proposal. This phase shouldinclude all the groups involved in the product deliverycycle in order to achieve the best results in preparingthe proposal.

(2) Concept formation. Depending on the negotiatedcontract and proposal baseline, the concept phaseusually starts with the layout and planning of an assem-bly of the product, followed by the creation of a productstructure, the development of speci® cations for sub-assemblies or product components, and the establish-ment of a development team . Here, the proposalbaseline and any other alternative design concepts aremodelled, analysed, and evaluated in order to select aconcept development baseline design to be carried into

the subsequent development phases. One of the maintasks during concept development is to build produci-bility into product design by considering and resolvingproducibility and cost tradeoffs. Therefore, develop-ment of a product concept requires active participationfrom other product delivery areas, including productdesign, process design, production, and fabrication.

(3) Design. The product design phase whichincludes both preliminary design and detail design,synthesizes product requirements into a coherentdesign. The preliminary design activity re ® nes theproduct design concepts that were developed atthe concept development phase. It also provides thetechnical foundation required before proceeding tothe detail design phase. The detail design involves thegeneration of the actual detail designs and drawingsthat will be used for the fabrication and assembly ofhardware end items. To ensure the product can beproduced and assembled, process design is always per-formed concurrently with the product detail design.The tasks of process design include design of fabrica-tion tools; design of process plans for tool manufactur-ing; and, design of plans for product manufacturing,inspection, and assembly.

(4) Production support. This phase begins with therelease of the formal signed documentation packagefor manufacturing production. The documentationincludes component or assembly drawings, manufactur-ing process plans, inspection plans, and assembly plans.Engineering support of manufacturing and the cus-tomer is required during this phase.

(5) Fabrication. According to the engineering plans,types and quantity of orders and availability of facility, aproduction plan and schedule is prepared for productfabrication. Computer-aided manufacturing concepts,techniques and facilities play a very important role inthe phase of fabrication. Along with automatic tools formaterial handling and manufacturing operations, theshop ¯ oor control facility is used to ensure the propercondition of material, work-in-process, machines, andproducts.

2.2. Concurrent product and process development

Product and process development focuses on thedevelopment of products and their related processes.Product and process development is itself a very com-plicated engineering process with strong interactionsamong development tasks and with involvement ofvarious types of product and process data. Figure 1illustrates the tasks and data ¯ ow in an example ofproduct and process development. The product, in thiscase an assembly of sheet metal and injection moulding

A collaborative data management framework 447D

ownl

oade

d by

[T

he U

C I

rvin

e L

ibra

ries

] at

18:

26 0

8 N

ovem

ber

2014

components, is designed according to the productfunctional requirements and speci® cations from cus-tomers or from a marketing survey. The results of theproduct concept formation are a product structure andan assembly layout associated with the speci ® cations ofthe components. The product structure is used forproject management and for scheduling. The assemblylayout is used for the detailed design of the componentsand for the design of assembly plans.

Preliminary design involves constructing theinitial component geometry and specifying additionalperformance requirements. The choice of manufactur-ing process for each component depends on the pro-duction volumes, functional requirements, and shapecharacteristics of the components. The purpose ofprocess-speci® c detail design is to modify or transferthe initial component geometry into a shape compati-ble with the selected manufacturing process. Areas of

the shape that could cause defects or con¯ icts withthe product’ s design or manufacturing process areaddressed. The need for enhancement and modi® ca-tion of the initial component geometry is determined,based on design guidelines, rules or heuristics. Engin-eering analyses are also performed during componentdetail design to ensure components perform as required.

Along with product design, tool design, processdesign, and process planning are also required tosupport the manufacture of the designed product. Inthe case of moulding components, prototyping, moulddesign, and moulding inspection planning may beperformed concurrently, based on the results of mould-ing component design. For economic consideration,moulds might be ordered from mould manufacturers,in which case the moulding speci ® cations and mould-ing component models must be released to them. Theplanning of mould prototyping, manufacturing, and

Y.-M. Chen and Y.-T. Hsiao448

Figure 1. Data ¯ ow in product and process development.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

inspection are based on the mould models from themould design. The design of moulding process is basedon factors such as material properties, productionvolumes, component size, and the results of mouldand moulding feature layout.

The sheet metal component and its processes aredeveloped in a similar fashion. The interaction betweenmoulding component design and sheet metal com-ponent design is through the product assembly design.

According to the concept of concurrent engineer-ing, most of the product delivery activities discussed inthe previous section may be coordinated and per-formed concurrently by a team from different disci-plines as part of a project. This approach is de® ned asconcurrent product and process development.

2.3. Analysis of functional requirements

The essence of concurrent product and processdevelopment is an integrated and collaborative process,where people in different disciplines cooperate tospecify, and design products and relevant processesthrough coordination, communication, and negotia-tion. The key to the collaborative process is a completeunderstanding and sharing of the product- and process-related information throughout the entire develop-ment cycle (Karinthi et al. 1992, Trapp 1991).

Information shared in the process of product andprocess development includes engineering, process,and organizational data. Engineering data includesproduct models, application models, engineeringplans, engineering documents, and data ® les. Productmodels, which contain geometric and non-geometricinformation about products, are created to describe theproduct and to provide support for product and pro-cess development activities. Application models are thegeometric models re® ned from the product modelsand used for process-speci ® c applications such as ana-lysis, simulation, and model design. The engineeringplans include the process plans, assembly plans, andinspection plans, which describe how the productshould be fabricated, assembled, and inspected, respec-tively. Engineering documents are the detail descrip-tion of each development activity and task. An exampleof a data ® le is an IGES ® le which de® nes the neutralformat for the transformation of a product geometryamong CAD systems. Process data that describe howa development process can be accomplished includeproject activities, work¯ ow, development policies andrules. Organizational data is related to the organizationof individuals and functional teams, use of resource,and the responsibilities of people and their roles withinthe development cycle.

An environment that is capable of supportingconcurrent product and process development shouldprovide facilities to deal with the m odelling andmanagement of product, process, and organizationaldata that can be shared throughout the entire develop-ment cycle. In such an environment, this informationcan be distributed through various information reposi-tories such as a product library, knowledge bases, anddatabases; mail and message libraries; and, ® le anddocument libraries in the form of texts, graphics,images, formulas, CAD data, and multim edia data(Srinivas et al. 1992).

Product and process development is usually per-formed as a project, which is, in turn, broken downinto sub-projects. Each of the sub-projects de® nesseveral interrelated development activities and associ-ated resources. One of the challenges of concurrentproduct and process development is to decouple theotherwise linear development activities so that they canbe performed in parallel (Adedeji 1993). Therefore,there is a need for using a systematic way to expressproduct and process development activities and tomeasure the in¯ uence of these activities so as to opti-mize the product and process development process,tools, and their supporting organization.

Design is an iterative process that takes into accountthe in¯ uences of a number of applications. Forinstance, the results of moulding analysis might causea change in the moulding design that, in turn, affectsthe mould model and the results of manufacturingplanning. Therefore , authorized design changes mustbe allowed to be automatically re¯ ected in all otherapplications, regardless of where they are used. Forinstance, analysts can perform simulations of a mould-ing that is still being re ® ned by the moulding designer.Once design changes are approved, the results of themoulding simulation will be autom atically updated tore¯ ect these changes.

Another requirement for concurrent product andprocess development is the ability to re ® ne the productmodel re® nements and maintain associativity betweenthe models. This requirement includes the generationof application-speci® c geometry, propagation of pro-duct requirements and speci® cations (Serrano 1991,Fu and Pennington 1993), and the establishm ent andmaintenance of associativity between application models(Sriram et al. 1991, 1992).

3. A collaborative team data management framework

Based on the requirements analysis discussed in theprevious section, a collaborative team data manage-ment framework is proposed. It allows development


ownl

oade

d by

[T

he U

C I

rvin

e L

ibra

ries

] at

18:

26 0

8 N

ovem

ber

2014

members to work concurrently in a team with the abilityto (1) model and manage a project for product andprocess development, (2) model a product structurethat is related to a de® ned project, and (3) manage andshare product and process information through theentire product and process development cycle.

3.1. System overview

The user’ s view of the proposed collaborative teamdata management framework, mapped onto a systemfunctional diagram, is illustrated in Figure 2. Thediagram shows functions for supporting team datamanagement (indicated by rectangular boxes) andtwo kinds of containers: physical containers (indicatedby plain rounded rectangular boxes) and logical con-tainers (indicated by bold boxes with rounded cor-ners). A physical container is a product or process itemthat can be seen on the operating system when ® les arelisted; a logical container is a conceptual work area orlocation that does not appear on the operating system.

The logical container includes project installation,personal work area, workbench, bin, and team library asdiscussed below. The logical container may also containphysical product and process items such as productmodels, application models, engineering plans, engin-eering documents, and data ® les that are shared inconcurrent product and process development.

(1) Project insta llation. A project that is set upthrough a `project con® guration’ is a logical containerof product and process data and of the project activitiesof a project, which consists of personal work areas and ateam library.

(2) Personal work area. A personal work area is alogical workspace of an individual team member. Apersonal work area corresponds to an activity of adevelopment process, such as product design, moulddesign, or process design. Personal work areas areprivate, where data within them cannot be sharedunless they are released to the team library.

(3) Workbench. A workbench is the space where theteam member performs tasks as part of development


Figure 2. Collaborative team data management framework.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

activity. Entity management entails controlling what ison and off the workbench.

(4) Bin. Bins are private storage areas for individualmembers of the project team. The team member canorganize and control his or her work by taking thingsoff the workbench and storing them in a bin. Bins allowthe storage of a number of types of data. A bin andinformation about it resides within the personal workarea.

(5) Team library. The team library is a group storagearea managed by mechanisms of library managementfor the purpose of sharing data among members of thedevelopment team .

3.2. Functions of team data management

The functional ingredients of the proposed frame-work include mechanisms for project con® guration,product de® nition, entity management, and librarymanagement as discussed below:

(1) Product de® nition. The mechanisms of productde® nition are used to create a product structureby logically de® ning the components in a productand their related models or items, including theirrelationships.

(2) Project con ® guration. With the reference of pro-duct structure and using the mechanisms of projectcon ® guration, a project leader can con® gure projectactivities, de® ne project members, and assign themroles that de® ne access privileges to product and pro-cess data.

(3) Entity management. Entity management providesindividual team members with the ability to manageproduct and process items in a personal work area. A`get’ function allows the user to select a product orprocess item and bring it to the workbench from a bin.The `put away’ function allows the user to acceptdefaults for bin, name and part number, or to makechanges.

(4) Librar y management. Library management pro-vides mechanisms for team library access and main-tenance, which are supported by the underlyingfunctions of design release management, changemanagement and noti ® cation, and product structuremanagement.

Design release management provides functions forteam members to access a team library. The functionsare reference, check-in, check-out and copy.

d Reference. Reference allows team members to geta product or process items from a team library and

use them in their own development activities forreference only. No modi® cation to the referenceditem is allowed. Product and process items m ay bereferenced even if they have already been checkedout or referenced.

d Check-in. Check-in allows team members to releaseproduct or process items from their personal workareas into the team library for information sharing.Checking-in an item creates a new version of theitem if it was originally checked out from the teamlibrary.

d Check-out. Check-out allows the team members tohave full privilege for modi® cation. Once checkedout, the item is locked so that no one else maycheck it out. However, a copy of or reference to theoriginal item is allowable.

d Copy. Copying a product or process item from ateam library is similar to getting a new item . Thecopy of the item has no link to the team libraryitem and the team member who copied the itemmay do whatever he or she wants on the item.Product and process items may be copied eventhough they have been checked out or referenced.

When a team member checks in or updates his/herdesign to the team library, all existing references to thelatest version of the product or process items and theirassociated items are made invalid. An e-mail message issent to all other members referencing the item and itsassociated items and all creators of the associated itemsfor the change. A function of change management andnoti® cation is to control item versions and to keep trackof the reference status of items in the library. Thefollowing three speci ® c conditions within the projectwill cause the change management and noti ® cationcontrol mechanism to notify team members: (i) whena new version of an item is created; (ii) when a modi® -cation to an existing item version occurs; or (iii) whenthe state of an item is modi® ed via an approval.

The purpose of product structure management is tomaintain the product structure and the associativitybetween product and process items in the team libraryas well as in personal work areas.

4. Object modelling of collaborative team data

managem ent

This section presents the proposed collaborativeteam data management framework from a systemmodelling perspective using object-oriented tech-niques. The concepts and characteristics of object-oriented modelling are discussed ® rst. A product struc-ture and a system object model are then developed to


ownl

oade

d by

[T

he U

C I

rvin

e L

ibra

ries

] at

18:

26 0

8 N

ovem

ber

2014

provide the essential foundation for the further systemdevelopment.

4.1. Concepts of object modelling techniques (OMT)

Object-oriented techniques provide a new way ofthinking about problems through models organizedaround real-world concepts. The fundamental con-struct is the object, in which data and associated opera-tions that are norm ally performed on that data areencapsulated in a single entity. Therefore, instead ofpassing data to procedures and having these pro-cedures operate on the data, the objects can be invokedto perform operations upon themselves.

Based on Rumbaugh’s Object Modelling Technique(OMT) (Rumbaugh et al. 1992), the proposed frame-work is developed in terms of three related models:object model, dynamic model, and functional model.The object model de® nes the static, structural, and data


Figure 3. Product component aggregation hierarchy.

Figure 4. Product structure.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

aspects of the framework in terms of objects andrelationships that correspond to elements in thedomain of engineering data management. Thedynamic model de® nes the temporal, behavioural,and control aspects of the framework in terms ofevent and states of these elements. The functional

model de® nes the transformational and functionalaspects of the framework values and functions.

An object model is represented by an object dia-gram that consists of object classes, links, and associa-tions. An object is a concept, abstraction, or thing in acertain application domain. An object class describes a

A collaborative data management framework 453

Figure 5. Example of (a) project con® guration; (b) product structure.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

group of objects that have common attributes, opera-tions, and semantics. A link is a physical or conceptualconnection between object instances. An association

describes a group of links that have a common structureand semantics. Two of the most commonly used associ-ations are generalization and aggregation. Aggregationis the `part_of ’ relationship in which lower-level objectsare associated as a higher-level aggregate object. Gen-eralization is the is_a’ relationship in which lower-levelsubclasses are the specialization of their superclass.

In Rumbaugh’s notation, an object class is indicatedby a rectangular box with three regions of class name,list of attributes, and list of operations. An object isdenoted by rectangular boxes with rounded corners.An association is drawn as a line between classes, withwhich a verb in a problem statement is associated.Similarly, the OMT notation for a link is a line betweenobjects. Aggregation is drawn like association, excepta small diamond indicates the assembly end of therelationships. The generalization is indicated by atriangle connecting a superclass to its subclasses.

4.2. Product structure and project con ® guration

(1) Product structure. A product can be a single partor an assembly that is composed of parts and/or sub-assemblies. The components of a product form aproduct component aggregation hierarchy (Figure 3),which in turn is the basic construct of the productstructure and maintains the bill-of-material (BOM) ofthe product. For the purpose of supporting productand process development, in addition to de® ning therelationships among the components of the product,the product component aggregation hierarchy isextended to include the associated applicationmodels, plans, ® les, and documents, which form aproduct structure as depicted in Figure 4. In manycases, the product structure is enhanced into a morecomplete structure, with relationships such as versionsand options added.

Most of the product and process items, exceptdocuments, shown in the product structure correspondto a project activity. Employment of the product struc-ture may facilitate the con® guration of project activitiesand provide a better way for development processtracking and management. The product structure alsoprovides inform ation for version and access control ofproduct and process data, as well as maintenance of therelationships between the product models and relatedapplication models, ® les, and documents.

One of the requirements for collaborative team datamanagement is to ensure team members are informedimmediately of actions that have taken place which

could affect any aspect of their work. Product structureplays a key role in change management and noti ® cationas well.

(2) Project con ® guration. A project con ® guration isalso referred to as a process model (Sriram et al. 1991,1992) that de® nes (1) activities needed to accomplish aproject; (2) inter-activity relationships and sequence ofthese activities; and (3) the sequence of tasks, opera-tions, and steps to perform in an activity. Figure 5(a)and (b) show the project con® guration and the productstructure respectively of the example shown in Figure 1.

One of the purposes of using project con® gurationis to facilitate project management by providing infor-mation to track process activities, the interaction andcoordination among the activities, the use of resourcesand time, and the assignm ent of roles and responsibil-ities. Since product and process items are the results ofprocess activities, the product structure and projectcon® guration play an integral role in the collaborativeteam data management. Figure 5(b) illustrates thestructure of product and process items developed bythe project activities shown in Figure 5(a).

4.3. Object model of collaborative team data management

The objective of object modelling is to identify theelements involved in collaborative team data manage-ment and their relationships. This process helps pro-mote understanding of the real-world collaborativeteam data management and thus provides a practicalbasis for the system design and implementation.

Figure 6 illustrates the object model of the proposedcollaborative team data management. A project isassociated with a series of project activities, a projectteam, a project library, and a product. A project con-® guration is the aggregation of the project activities.The relationships and sequence of the activities arede® ned implicitly in term of the Follow’ attribute ineach activity object. An activity is performed by one ormore team members. Similarly, a team member may beinvolved in one or more than one project activities. Aproject team consists of team members with differentresponsib ilities. A project team owns a team library asthe place for global storage and for information shar-ing. The team library contains all product and processitems that are mature enough for sharing. Personalwork areas, consisting of a workbench and bins, are thelogical space that belongs to individual team members.

A product or process item can be a product, anapplication model, a ® le, or a document. Each of themin the object model is the logical representation of itscorresponding physical model, ® le or document. Aproduct can be an assembly or a part. An assembly is

Y.-M. Chen and Y.-T. Hsiao454D

ownl

oade

d by

[T

he U

C I

rvin

e L

ibra

ries

] at

18:

26 0

8 N

ovem

ber

2014

in turn the aggregation of subassemblies and/or parts.An application model that is associated to a part orassembly model can be a FEA model, a process plan, aninspection plan, an assembly plan, or a drawing. Simi-larly, a ® le or a document is associated to its corre-sponding product model or application model. Allthese logical models are created through productstructure de® nition and form a product structure.The product structure is registered in the team libraryright after it is de® ned. A physical product or processitem is created by a team member and belongs to aproject activity. For example, an assembly layout andproduct structure are the results of conceptual design,

all part models are the outputs of component detaildesign, the assembly models are the results of assemblydesign, a mould model is the result of mould design,and a process plan is the output of process planning fora part or a mould.

A physical product or process item in the teamlibrary can be referenced or checked out by the teammembers. Once checked out or referenced, or beforebeing checked into a team library, a product or processitem can reside in a workbench or bin. The structure ofproducts is maintained in the workbench, while it is notin the bin. After being checked into the team library,the product and process item s are placed into the


Figure 6. Object model of collaborative team data managem ent.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

categories where they belong. However, the productstructure is still maintained. An example of the organi-zation of data in the team library and personal workarea is depicted in Figure 7, where each of the items in aproduct structure points to the latest version of itsphysical model in a physical storage area, that in turnpoints to its previous version, and so on.

5. Dynamic modelling of collaborative team data

management

In the previous section, we examined the staticstructure of the proposed collaborative team data man-agement by identifying the structure of the objects in itand their relationships. In this section, the dynamicmodelling techniques of OMT are employed todescribe changes to the objects and their relationshipsover time. The main construct of the dynamic model-ling is the control information, including the sequenceof events, states, and operations that occur within asystem of objects.

5.1. Events and states

The object model presented in the previous section

described the possible patterns of objects, attributes,and links that can exist in the proposed framework. Theattribute values and links of an object at a singlemoment in time are called its state’. Over time, theuser may perform operations or the objects may stimu-late each other, which results in a series of changes totheir states. An individual stimulus from outside of thesystem (i.e. the user performs operations) or from oneobject to another is called an event’. The response toan event depends on the state of the object receiving itand can include a change of state or the sending ofanother event to the original sender or to a third object.Following are portions of the events from the user tothe collaborative team data management system:


Figure 7. Data organization of team library and personal work area.

Events related to productstructure de® nition

· De® ne product· De® ne product items· Delete product· Delete product items· Modify product structure

Events related to projectcon ® guration

· De® ne project· De® ne project team· De® ne project activities· Delete project· Delete project team

Events related to entitymanagement

· Set up personal workareas

· Delete personal work area· Create items in work-

bench· Delete items from work-

bench· Put items into bin· Get items from bin

Events related to librarymanagement

· De® ne team library

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

5.2. State diagrams

A state diagram describes the behaviour of a singleclass of objects. A state diagram is a graph whose nodesare states and whose directed arcs are transitionlabelled by event names. A state is drawn as a roundedbox containing an optional name. A transition is drawnas an arrow from the receiving state to the target state;the label on the arrow is the name of the event causingthe transition. All the transitions leaving a state mustcorrespond to different events.

(1) Product and process items. As shown in Figure 8, aproduct or process item can reside in a workbench, binor team library. It may be associated with a productstructure or exist individually before being added to aproduct structure or removed from a product structure.Normally, the creation of a product or a process itemstarts with checking out a logical node of the itemfrom a product structure registered in a team library.

However, the members are also allowed to create pro-duct and process items and add them to a productstructure.

(2) Team library. The state of the team library isillustrated in Figure 9. An empty team library withoutcategories is created after the project leader sets up ateam library for the project team. The team library canbe classi ® ed by several storage areas according toproject activities. The exam ples of the categoriesinclude standard parts, assemblies, parts, and mouldmodels. The accessibility of the entire team library andeach area can be speci® ed and changed as required.

(3) Personal work area. An empty personal work areais created by generating a setup personal work area’event (Figure 10). The èmpty’ state of a personal workarea can be transformed to a `with item’ state when anitem is created in the workbench or an item is refer-enced, copied or checked out from a team library.

6. Functional modelling of collaborative team data

managem ent

Functional models are employed to specify themeaning of operations and constraints in the objectmodel and actions in the dynamic models. They consistof multiple data ¯ ow diagrams (DFDs), that specify themeaning of operations, constraints and actions. A DFDshows the functional relationships of the values com-puted by a system, including input values, output


· Delete project activities· Add team members· Delete team members· Add project activities· Delete project activities· Change roles

· Set/change libraryaccessibility

· Delete team library· De® ne library category· Change library categories· Delete library categories· Check-in items to library· Check-out items from

library· Reference items from

library· Copy items from library

Figure 8. State diagram of product and process items.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14


Figure 9. State diagram of team library.

Figure 10. State diagram of personal work area.

Figure 11. Functional model of product de® nition.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

values, and internal data structures. A DFD containsprocesses that transfer data, data ¯ ows that move data,actor objects that produce and consume data, and datastore objects that store data passively.

6.1. Product de® n ition

Figure 11 illustrates the ® rst-level DFD of productde® nition. There is only one input actor: the user, whode® nes a product, the components of the product andall related models, ® les, documents , as well as theirrelationships. De® ning a product by giving a productname and project number will instance a productobject from a class library. The method of Àddcomponents’ in the product object is then activatedto request for de® ning the ® rst layer components ofthe product. The method of Àdd components’ in thecomponent object can be activated to add the com-ponents of the component, while the method ofÀdd application items’ can be activated to associateapplication models, ® les or documents with the com-ponent. After the de® nition of the product, a productstructure is created and automatically registered in ateam library.

6.2. Project con ® guration

Figure 12 shows a portion of the ® rst-level DFD ofproject de® nition. There is only one input actor: the user,who de® nes and con® gures a project, de® nes a projectteam, and sets up a team library. De® ning a project bygiving a project name and project number will instance aproject object. The methods of `project con® guration’and `project team’ in the project object are then activatedto request for project con® guration and project teamde® nition. After project de® nition, a project objectassociated with a project con® guration object, a projectteam object and a product structure object exist.

6.3. Entity management

A personal work area is speci® ed and assigned toa team member after a team member is de® ned in aproject. With the method of de® ne bins’, the member isable to create bins of his or her personal work area. Thepersonal work area is controlled by entity management.Functions of entity management are activated when (1)a product or process item is created in the workbench,(2) an item is put away to a bin, and (3) an item is taken(got) from a bin to a workbench. Figures 13(a) and (b)


Figure 12. Portion of functional model for project de® nition.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

depict the DFDs of `put away’ and `get’ respectively.

6.4. Team library management

The process of team library management may startwith checking in an item, checking out an item ,

referencing an item, or copying an item. Figure 14shows the functional model of check in’. The mainprocesses of this functional model include upd ateentity management directory’ of the personal workarea, upd ate product structure’ that the item belongsto, search for members need to notify’ for change


Figure 13. Functional model for (a) put away, and (b) get.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

noti ® cation, and `mark associated items out-of-date’.Once an item is selected to check in, the item is erasedfrom the entity management directory of the personalwork area. The item is then registered in the librarymanagement directory of the library and the item statusin product structure is updated to conceptually movethe item to the library. If the item was originallychecked out from the library, a comparison is madebetween the original item model and the one beingchecked in. If any changes are made, a search formembers who are currently referencing this item isperformed for change noti ® cation. Besides changenoti ® cation, any items that are associated to the itemor its associated items are marked òut-of -date’.

7. Implementation and prototype

7.1. Implementation

A commercial object-oriented data managementsystem, ObjectStore (from Object Design) is selectedfor the implementation of the proposed collaborativeteam data management framework. The framework isimplemented using Visual C++ language in a Windows-NT environment on an Altos 9000 system networkedwith four PC clients located in the Computer-AidedConcurrent Engineering Research Lab. at NationalCheng Kung University in Taiwan. The architecture isa client/server con® guration as shown in Figure 15.


Figure 14. Portion of functional model for library management.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

The entity management modules run at four clientsites, while project con® guration and team librarymanagement modules are run at the server site. Theserver also contains a shared knowledge and infor-mation repository and works as a ® le server. Theclient/server con® guration re¯ ects the distributedand integrated nature of concurrent product and pro-cess development.

The collaborative team data management frame-work is fully integrated with advisory tools for mouldingproduct design, injection moulding process design,mould design, and mould manufacturing process plan-ning to form a computer-aided concurrent engineeringenvironment that can support virtual team-orientedconcurrent net shape product and process develop-ment (Chen et al. 1995).

The collaborative team data managementframework together with a module for knowledgemanagement, mechanisms for data and knowledgeabstraction, coordination and con¯ ict resolution, andutility for communication and networking are workingas the infrastructure of the environment. The infra-structure is implemented by integrating the object-oriented data managem ent system Ð ObjectStore Ðwith a computer-aided design tool (Pro/Engineerfrom Parametric Technology Co.) and an object-oriented expert system shell (Nexpert/Object fromNeuron Data).

7.2. Software architecture

The system is developed as an object -oriented envir-onment consisting of several layers of class library asshown in Figure 16. The ® rst layer is user interface,which is used for the communication between usersand the team data management functions. The nextlayer contains classes of the team data management.Some of them are shown in Figure 17. The bottomlayer contains the interfaces to a CAD system and a


Figure 15. Client/server con ® guration of collaborative team data management.

Figure 16. Software architecture.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14


ownl

oade

d by

[T

he U

C I

rvin

e L

ibra

ries

] at

18:

26 0

8 N

ovem

ber

2014

knowledge-based system, and the utility for communi-cation and networking. Methods which are written informs of procedural function calls.

A class describes a group of objects with similarproperties (attributes), common behaviour (opera-tions), common relationships to other classes, andcommon semantics. A class is represented by a boxwhich may have as many as three regions. The regionscontain, from top to bottom : class name, class attributesand class operations. An attribute is a data value held bythe objects in a class and an operation is a function thatmay be applied to or by objects in a class.

7.3. Application scenario

This section presents a scenario of the concurrentproduct development procedure through collaborativedata management using an example product: Transmis-sion TRS-01 as shown in Figure 18.

7.3.1. Phase I: Project setup. The project starts with the

de® nition of a transm ission project ’ by activating a`project ’ form and entering project name and projectnumber. Once the project de® nition is complete, theproject manager creates a project con ® guration basedon the activities required to accomplish the project. Theactivities of the project and their sequence are de® nedthrough the Àctivity’ form shown in Figure 19(a) bypushing the Àctivi ty’ button in the `proje ct’ form.

In accordance with the assembly layout of Transmis-sion TRS-01 from concept formation, the project man-ager de® nes a product `Transmission’ through the`product’ form (Figure 19(b)). He/she then de® nesthe product and process items, assigns them to corre-sponding activities and establishes associations amongthe items. The item s and their association form the pro-duct structure. For the purpose of reference, the pro-duct structure is autom atically registered in the teamlibrary created when the project manager de® ned theproject.

The project manager then de® nes a project team,assigns project tasks to team members, and de® nestheir library access privilege (Figure 19(c)). He/she


Figure 17. Example of classes.

Figure 18. An example of product for team-oriented design.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

also checks in some standard parts to team library forreference. The team members are allowed to create theirpersonal work areas, including a workbench and bins.

The `workbench’ form provides functions to checkin (to team library), put away (to bin) and list all theproduct and process items in the workbench. Similarly,the user can select a bin and get’ an item from the binto the workbench through `Bin’ form. The `LibraryManagement’ form allows users of the functions torefer, check out, or copy items from the team library.

Each of the forms mentioned above corresponds toa class as shown in Figure 17.

7.3.2. Phase II: Team-oriented design. Stage I. Each teammember ® rst checks out his/her logical item’ from theproduct structure registered in the team library. Thelogical item contains only the speci ® cations of a pro-

duct or process item that the member is assigned towork on. The status of the project library looks like this:

Transmission TRS-01(a) Top housing Ð locked by team member A(b) Bottom housing Ð locked by team member A(c) Bracket Ð standard part(d) Bearing Ð locked by team member B, refer-

enced by team member C (in gear trainassembly)

(e) Gear train assembly Ð locked by team mem-ber C[1] 1st gear assembly Ð locked by team mem-

ber C[a] shaft Ð locked by team member C[b] gear 1 Ð locked by team member C[c] gear 2 Ð locked by team mem ber C

[2] Bearing Ð locked by team member B,referenced by team member C (in geartrain assembly).

At this stage, team member B checked out `bearing’® rst, so team member C was warned when he checkedout `Gear train assembly’ that he could only reference`bearing’ because it was locked by team member B.

Stage II. Team member A ® nished his work andchecks in `Top housing’ and `Bottom housing’. Sincehe has ® nished so quickly, he is assigned to work onshaft’. Team member C checks in shaft’ and an auto-

matic reference is created, since team member C still


Figure 19. Forms (a) activity, (b) product, and (c) members.

Dow

nloa

ded

by [

The

UC

Irv

ine

Lib

rari

es]

at 1

8:26

08

Nov

embe

r 20

14

has `1st Gear Assembly’ checked out. Team member Athen checked out `shaft’. The status of the projectlibrary looks like this:

Transmission TRS-01(a) Top housing(b) Bottom housing(c) Bracket Ð standard part(d) Bearing Ð locked by team mem ber B, refer-

enced by team member C (in gear trainassembly)

(e) Gear train assembly Ð locked by team mem-ber C[1] 1st gear Assembly Ð locked by team

mem ber C[a] shaft ± locked by team member A,

referenced by team member C (in1st gear assembly)

[b] gear 1 Ð locked by team mem ber C[c] gear 2 Ð locked by team member C

[2] Bearing Ð locked by team member B,referenced by team member C (in geartrain assembly).

Stage III. Team member B ® nishes work on `bearing’and checks it in. Team member A ® nishes work onsha ft’ and checks it in. Team member C has already

saved his model (without purging library references)and gone hom e for the day. The status of the projectlibrary looks like this:

Transmission TRS-01(a) Top housing(b) Bottom housing(c) Bracket Ð standard part(d) Bearing Ð referenced by team member C (in

gear train assembly)(e) Gear train assembly Ð locked by team member C

[1] 1st gear assembly Ð locked by team memberC[a] shaft Ð referenced by team member C

(in 1st gear assembly)[b] gear 1 Ð locked by team member C[c] gear 2 Ð locked by team member C

[2] Bearing Ð referenced by team member C(in gear train assembly).

Stage IV. Team member C comes in the next morning,opens his model, and is prompted to update `shaft’ and`bearing’ . He responds `yes’ , then ® nishes work on`gear 1’ , `gear 2’ and checks in `1st gear assembly’ .`Gear 1’ , `gear 2’ are automatically checked in, and thereferences are created. The status of the project librarylooks like:

Transmission TRS-01(a) Top housing(b) Bottom housing(c) Bracket Ð standard part(d) Bearing Ð referenced by team member C (in

gear train assembly(e) Gear train assembly Ð locked by team member C

[1] 1st gear assemblyÐ referenced by teammember C (in gear train assembly)[a] shaft Ð referenced by team member

C (in 1st gear assembly)[b] gear 1 Ð referenced by team mem -

ber C (in 1st gear assembly)[c] gear 2 Ð referenced by team mem -

ber C (in 1st gear assembly)[2] Bearing Ð referenced by team member C

(in gear train assembly).

Stage V. Finally, team member C checks in `gear trainassembly’ and all references are automatically removed.The ® nal status of the project library looks like this:

Transmission TRS-01(a) Top housing(b) Bottom housing(c) Bracket Ð standard part(d) Bearing(e) Gear train assembly

[1] 1st gear assembly[a] shaft[b] gear 1[c] gear 2

[2] Bearing

8. Conclusions and discussions

8.1. Conclusions

8.1.1. General remarks. This paper presents a systematicapproach, from domain investigation and functionalrequirements analysis, through modelling to implemen-tation, to development of a collaborative data manage-ment framework using object-oriented techniques.

The collaborative team data management frame-work contains functions of product de® nition, projectcon® guration, team library management, and entitymanagement, which are able to support concurrentproduct and process development. The basic constructof the framework includes a product structure, a pro-ject con® guration, an object model, dynamic models,and functional models.

The product structure de® nes components in theproduct, along with the relationships among thecomponents and their associated models, ® les, and


ownl

oade

d by

[T

he U

C I

rvin

e L

ibra

ries

] at

18:

26 0

8 N

ovem

ber

2014

documents. Each product structure corresponds to aproject con ® guration that de® nes (i) activities to accom-plish the development process, (ii) interactivity rela-tionships and the sequence of these activities, (iii) theresource assigned to each activity, including tools usedand engineers engaged in the activity.

Using product and project con® guration functions,a team leader is able to con® gure projects, form projectteams, and construct product structures. They togetherprovide a systematic way to express development activ-ities and their relationships with project team membersand products. This capability consequently facilitatesproject management and smoothes the developmentprocess, as well as provides the individual team mem-bers with a more secured and con® guration-managedenvironment.

Throughout the product and process developmentprocess, multiple users can access the design results byusing the team library management capabilities. Thisprovides a disciplined design check-out and referen-cing mechanism that allows multiple users to access thelatest, most up-to-date design revision. This mechanismassures that changes do not occur at the same time andalso noti ® es users of design changes.

The maintenance of associativity among relatedmodels, ® les is one of the major challenges in theresearch of product data management. In currentsystem, the changes are communicated to other pro-duct components which use the design, and the usersare responsible for upgrading the components withrespect to the changes. As a result, the entire teamwill remain up to date and producibility improves. Toensure the consistency, research is being conducted ondevelopment of mechanisms for associativity mainte-nance and change propagation.

Entity managem ent functions are physically distrib-uted and logically integrated with library m anagementfunctions. With functions of entity management, ateam member can manage product and processitems in a more secured and structured fashion whilecontinuing to interact with team library and otherteam members.

8.1.2. Lesson learned. (1) Comments on object-oriented

modelling technology. Object-oriented technology pro-vides a common ground for the transitions betweenthe stages of system development (i.e. system require-ment analysis, modelling and design, coding, andmaintenance). The real-world objects identi® ed in therequirements analysis can be translated into systemobjects in the design phase, which are implementedas software objects in the programming phase, and soon. It also allows much easier mapping from a function-ing program back to the original requirements and

thus makes a system easier to maintain and modify.In this work, functional requirements are identi® ed

and the mechanisms for data management are devisedpurely based on the understanding of concurrent pro-duct and process development. How they can be donein a systematic way and how the object-oriented tech-nology can help at this stage is still an open question.

(2) Comments on Rumbaugh’s object modelling tech-

niques (OM T). There are several methods, yet no stan-dard notation, for object-oriented modelling anddesign. Shaler and Mellor (1988) provided an approachto extending the E-R model into object constructs.Wirfs-Brock et al. (1990) offered a notation for object-oriented design along with a technique calledresponsib ility-driven design. Booch (1994) proposedan object-oriented design notation based on Ada con-cepts. The notation itself is somewhat complex.

Instead of concentrating on the techniques forobject-oriented design and programming as most ofthe above methods, Rumbaugh’s approach places astrong emphasis on modelling. This is one of themain reasons why it was employed in our work. How-ever, Rumbaugh’s OMT method has its own lim itations.Some of them, as noted by Jacobson et al. (1992), aretheir separate notation and orientations, and the lackof integration between the three different models Ðobject model, dynamic model and functional model Ðthat make it dif® cult to maintain the consistenciesbetween the models.

8.2. Future extension s

(1) Concurrent associativity management. One of therequirements for collaborative team data managementis the ability to allow product model re® nements andalso to maintain associativity. Meeting this criterion isnecessary for the support of different application per-spectives, while maintaining the associativity amongthem. This requirement of product data managementincludes the generation of application-speci ® c geo-metry, propagation of product requirements and speci-® cations, and the establishment and maintenance ofassociativity between application models.

(2) Knowledge sharing and management. An idealcomputer-aided concurrent engineering environmentshould be able to support effective communication,coordination, and knowledge and information sharing.Most of the engineering data management systems andresearch concentrate on the management of engineer-ing data and are not able to handle the managementand sharing of knowledge. As a m atter of fact, any pieceof engineering data may represent different types of


ownl

oade

d by

[T

he U

C I

rvin

e L

ibra

ries

] at

18:

26 0

8 N

ovem

ber

2014

information that indeed re¯ ects various sources of knowl-edge. Hence, there is a need to convey the knowledgebehind product and process data. By knowledge, wemean the rules, principles, or rationales used in thedecision-making process during product development.One of the most promising enhancements of engineer-ing data management will be the incorporation ofknowledge into the product and process data to facil-itate information and knowledge sharing.

(3) Product and process data exchange. Concurrentengineering is implemented in a highly heterogeneousenvironment. Computer-aided design (CAD), computer-aided engineering (CAE), and computer-aided manu-facturing (CAM) tools, engineering and material data-bases, and word processors are provided by differentvendors and run on different sites. The differences inrepresentations, structures, and contents of data indifferent applications make them island s of automa-tion’ and prevent product development from reachingthe goals of concurrent engineering. Therefore, pro-viding an effective means for sharing and exchangingproduct and process data among applications andorganizations is also one of the challenges of theteam data management.

(4) Database management and storage. Classical datamodels (e.g. relational, network, and hierarchicalmodels) have been employed in modelling engineeringdata. Most researchers have tried to describe the rela-tionships among the entities in an engineering envir-onment. However, classical data models are too simplefor modelling complex product and process data, andtheir levels of abstraction are too limited to capture thevarious types of inform ation needed for engineeringapplications (Chen et al. 1994). In this research, theobject-oriented technique has proved effective inmodelling and programming. However, there are stillno viable ways to store the objects. Only recently havethere been object database management system(ODBMS) techniques mature enough to considerusing them as primary repository of objects. The earlyODBMSs have problems of their own (Wood 1992). Tosupport data managem ent in concurrent engineeringactivities, a more ef® cient database management andstorage method as well as the client-server architecture(i.e. logging, transaction model, remote databaseaccess), OLE environment, and heterogeneity requirefurther research efforts.

Acknowledgement

This research is supported by National ScienceCouncil, Taiwan under Grant No. NSC-85-2212-E-006-105. Thanks are due to Professor Cheng-Ter Ted Ho,

Dept. of Industrial Engineering and Management,National Kaohsiung Institute of Technology, Taiwan,for discussions on the product delivery process.

References

ADED EJI , B. B., 1993, Scheduling of Concurrent Manufactur-ing Projects . In H. R. Parsasi and W. G. Sullivan (eds),Concurrent Engineering (Chapman & Hall, New York), pp.93 ± 110.

BOO CH , G., 1994, Object-Oriented Design with Applications, 2ndedn (Benjamin/Cummings, Redwood City, CA).

BRADLEY, S. R., and AGO GINO , A. M., 1991, Design Capture andInformation Management for Concurrent Design (AddisonWesley, New York).

CH EN, YUH -M IN , M ILLER , R. A., and LEE, D IK LUN , 1994,Object-oriented part model for geometric reasoning. Jour-nal of Integrated Computer-Aided Engineering, 1, 375 ± 395.

CH EN, YUH -M IN , LEE , RO NG -SHEANG , HO , CH ENG -TER, CHENG ,HSING -YEOU , and LIN , GRIER C. I., 1995, A fram ework forcomputer-aided concurrent net shape product and processdevelopment. The 8th Automation Conference, Taiwan, July.

CLAUSING , D., 1994, Total Quality Development: A Step-by-StepGuide to World Class Concurrent Engineering (ASME Press, NewYork).

CLEETUS, K. J., 1992, Modeling evolving product data forconcurrent engineering. CERC Technical Report, CERC-TR-RN-92-016. Concurrent Engineering Research Center, WestVirginia University.

DAVIS, T. A., and TRAPP, G., 1991, Advancing concurrentengineering using step. CERC Technical Report, CERC-TR-RN-91-012. Concurrent Engineering Research Center, WestVirginia University.

FU , Z., and PENNINGTO N , A. de, 1993, Constraint-based designusing an operational approach. Research in EngineeringDesign, 5, 202 ± 217.

JACO BSO N, I., et al., 1992, Object-Oriented Software Engineering, aUse Case Driven Approach (Addison-Wesley, Wokingham ).

KARINTHI, R., JAGANNA , V., MONTAN, V., PETRO , J., RAM AN , R.,and TRAPP, G., 1992, Promoting concurrent engineeringthrough information sharing. Proceedings of ASME WinterAnnual Meeting, Anaheim, CA, November 1992, pp. 8 ± 13.

M ILLER , E., 1993, Managing engineering data: an inside lookat PDM. Computer-Aided Engineering, July, SR1 ± SR8.

M ILLER , L. C. G., 1993, Concurrent Engineering Design (Societyof Manufacturing Engineers, Dearborn, MI).

M ILLS, R., BECKERT, B., and CARRABINE, L., 1991, The future ofproduct development. Computer Aided Engineering, October38 ± 46.

NAGY, R. L., ULLM AN , D. G., and D IETTERICH , T. G., 1992, Adata representation for collaborative mechanical design.Research in Engineering Design, ?, 233 ± 242.

RUMBAUGH , J., BLAHA , M., PREM ERLANI, W., EDDY, F., andLORENSEN , W., 1992, Object-Oriented Modeling and Design(Prentice Hall, Englewood Cliffs, NJ).

SERRANO , D., 1991, Constraint-based concurrent design. Inter-national Journal of Systems Automation: Research and Applica-tions (SARA), 1, 287 ± 304.

SHALER , S., and MELLOR , S., 1988, Object-Oriented SystemsAnalysis (Prentice Hall, Englewood Cliffs, NJ).

SRIRAM, D., AH MED , S., and LOG CHER , R., 1992, A transactionmanagement framework for collaborative engineering.Engineering with Computers, 8, 213 ± 232.


ownl

oade

d by

[T

he U

C I

rvin

e L

ibra

ries

] at

18:

26 0

8 N

ovem

ber

2014

SRIRAM , D., LO GCH ER , R., W ONG , A., and AH MED , S., 1991,Computer-aided cooperative product development: a casestudy. International Journal of Systems Automation: Research andApplications (SARA), 1, 89 ± 112.

SRINIVAS, K., REDDY, R., BABADI, A., KAM ANA, S., KUM AR , V., andZH AO , D. Z., 1992, MONET: a multi-media system forconferencing and application sharing in distributedsystem s. CERC Technical Report, CERC-TR-RN-91-009.Concurrent Engineering Research Center, West VirginiaUniversity.

STOVER, R. N., 1993, EDM as an enabling technology. Specialreport/engineering document management. ComputerAided Engineering. August, EDM1 ± EDM16.

TRAPP, G., 1991, Sharing information: a CALS/CITIS,concurrent engineering and PDES/STEP synergy. CERCTechnical Report, CERC-TR-TM-91-011. Concurrent Engineer-ing Research Center, West Virginia University.

W IRFS -BRO CK , R., W ILKERSO N , B., and W IENER , L., 1990,Designing Object-Oriented Software (Prentice Hall, EnglewoodCliffs, NJ).

W OO D , C., 1992, Choosing an engineering object data man-agement system. ASME Engineering Data Management Con-ference, San Francisco, CA, August 2 ± 6, 1992.

W ONG , A., and SRIRAM , D., 1993, SHARED: an informationmodel for cooperative product development. Research inEngineering Design, 5, 21 ± 39.


ownl

oade

d by

[T

he U

C I

rvin

e L

ibra

ries

] at

18:

26 0

8 N

ovem

ber

2014

Documents

A collaborative data management framework for concurrent product and process development