Product information systems engineering: an approach for building product models by reuse of...

Robotics and Computer Integrated Manufacturing 19 (2003) 239–261

Product information systems engineering: an approach for buildingproduct models by reuse of patterns

Lilia Gzaraa,*, Dominique Rieub, Michel Tollenaerea

a GILCO Laboratory, INPG, 46 Avenue F!elix Viallet, Grenoble, Franceb LSR Laboratory-IMAG, BP72, 38402 Saint Martin d’Heres, France

Abstract

This paper deals with an approach for Product Information Systems (PIS) engineering by reuse of patterns. Patterns form generic

solutions to problems frequently occurring during PIS specification and implementation. The pattern approach provides an

engineering guide to model data by organizing hierarchically and functionally modeling problems and the manner to resolve them.

Their use would contribute to accelerate building and implementing product and process models during PIS specification and

implementation. Two kind of patterns are distinguished: business patterns used for specification and providing solutions for

application field problems and software patterns used for implementation and providing solutions for technical problems (software).

A special interest is given to identify and specify different business patterns for product modeling during PIS specification.

However, a pattern-based approach can be developed only for disciplines which acquired a certain maturity, i.e. those for which

there is both a consensus around a finite set of problems and a variety of known solutions for solving these problems. There is no

universal agreement on the knowledge needed in product information systems, let alone on the representation of this knowledge and

we therefore find it impossible to discuss product information systems without reference to what kind of knowledge is being

managed. The first step consisted thus of constructing a general reference framework based on PIS concepts, providing a common

terminology and a semantic of the principal concepts managed in PIS and proposing various models to fix these concepts. It forms a

basis for exploring the problems frequently occurring during PIS specification. A pattern language is thus defined to resolve the

identified problems, basing partially on existing design pattern catalogues.

r 2003 Elsevier Science Ltd. All rights reserved.

1. Introduction

Industrial companies must today obtain a rigorouscontrol of the whole product information system (PIS)in order to increase their reactivity to the differentchanges involved in the product development process orlater during the product life cycle. PIS support all typesof engineering data used to define, manufacture, andsupport products. This may include part definitions,specifications, CAD drawings, manufacturing processplans and routings, project plans, control records,engineering change orders, etc.

Since the mid-1980s, software industries have devel-oped a new class of software packages, called ProductData Management Systems (PDMs) to support themanagement of all product engineering data. PDMs

constitute for industrial companies the core of ProductInformation Systems, such it is case of Data BaseManagement Systems (DBMs) for Management Infor-mation Systems. They are tool platforms adapted tocharacterization of items, bills of material, documents,procedures, etc. and providing class libraries dedicatedto PIS.

PDMs, like described by CimDATA [1] provide twomajor functions: managing product data (storage,control, retrieval, etc.) and managing product develop-ment processes (approval process, authorizations, en-gineering change orders, deviations, configurations andother processes that impact on product data).

Several research works have already been interested inengineering data management. Thus, associated with theAIT1 initiative [2], we quote the RISESTEP project [3]interested in the implementation and validation of STEPshared databases for concurrent engineering. Finally, let*Corresponding author. CRAN Laboratory, University Henri

Poincare, UMR CNRS 7039, Nancy, France. Fax: +33-3-83-68-44-37.

E-mail addresses: [email protected] (L. Gzara), tollenaere

@gilco.inpg.fr (M Tollenaere), [email protected] (D. Rieu). 1 Advanced Information Technology Design and Manufacturing.

0736-5845/03/$ - see front matter r 2003 Elsevier Science Ltd. All rights reserved.

doi:10.1016/S0736-5845(03)00028-0

us quote the OPAL project2 [4] whose aim is to provideconcepts for processes and information high-qualityintegration in manufacturing engineering field.

These projects are particularly interested in dataintegration and sharing problems. However, they donot fully deal with the engineering of PIS, i.e. themethodological aspects related to their design andimplementation. The development of such systemsimplies significant investments for the companies. Thestakes associated with these methodological aspects aretherefore strategic. We are thus focusing our research onthose stakes.

After describing briefly the principal methodologicalproblems currently faced by industrial companies whenPIS development (Section 2), we outline the need for areuse approach in PIS engineering and we focus on reuseof patterns (Section 3). Section 4 outlines the approachretained to identify and specify business patterns. Wepresent the generic reference framework developed atthis end. Finally in Section 5, a pattern language for PISis presented.

2. PIS engineering problems

Just like most information systems, the developmentcycle of a PIS consists of chronological stages: analysis(users requirements formulation), design (standardizedspecifications), implementation3 (operational solution;software) and maintenance (evolution).

However, the development of PIS in industrialcompanies currently encounters technical, methodologi-cal, organizational and human difficulties that we shallbriefly describe below:

Analysis: This initial stage is complicated by the lackof ‘‘formal’’ specification models for users requirementsformulation, that can easily be understood by the usersand by the lack of approaches able to draw up clear andunambiguous requirement specifications.

Design: Based on requirements analysis, this stagedefines the PIS specifications that will be considered bythe developers in charge of their implementation.Currently, this specification is done with no realcontinuity. Developers have trouble understanding theusers description, too informal to get used for imple-menting the system. The PIS project manager has towrite two separate specifications: one file for the users,described from a business point of view, and another filefor the developers, described from a technical point of

view. Any consistency between what is expected andwhat is actually delivered is purely intentional.

Implementation and evolutive maintenance: This stagemakes increasing use of PDM systems, whose imple-mentation is extremely complex and complicates theconsideration of the above-mentioned specifications.This problem does not only arise during specificationand implementation of a PIS, but also when the systemis upgraded in the company to allow for organizationalchanges or evolutive maintenance of the software partsof the system.

With respect to these difficulties concerning each stageof the development cycle, we should highlight that thedevelopment of such systems is always accompaniedwith organizational changes (e.g. new objectives, newinformation flows, evolution of quality procedures) andregular needs evolutions that the PIS must take underconsideration and anticipate. Industrial companies aretherefore obliged to constantly evolve their PIS, withinreduced times in order to avoid the delivery of obsoletesystems, unfitted to new organizations.

In conclusion, PIS specification and implementationare not currently tackled in a methodical way ofcomputerization, thus generating significant costs andmalfunctions. The objective of this research is so topropose a methodological framework for PIS specifica-tion and implementation:

* offering models of various abstraction levels and onegeneral PIS engineering approach, that cover thecomplexity of such systems (representation of pro-cesses, of versions, etc.), support the exchangebetween actors and ensure a continuum of transfor-mation during specifications and

* supporting specification ‘‘by deviation’’ both asregards capitalization and reuse of knowledge alreadycaptured in past experiences, in order to acceleratethe PIS development process.

3. A methodological approach based on patterns reuse

3.1. The need for reuse in PIS development

An efficient way to speed up PIS development consistsso of allowing ‘‘deviation’’ specifications, both asregards capitalization and reuse of concepts alreadyencountered and consideration of the software resources(components and systems) available. Consequently, thereuse approach, already effective in software engineer-ing, is a key factor to our PIS development methodo-logical approach, both for specification andimplementation of PIS and for their evolutive main-tenance. A general definition of the term ‘‘reuse’’ couldbe: a new development approach by which a system canbe built from existing components already described,

2 Integrated Information and Process Management in Manufactur-

ing Engineering.3 Implementation is often carried out by using software packages

called PDMS (Product Data Management Systems) such as Meta-

phase, Matrix, Sherpa, Agilesoft, etc.

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261240

carried out, tested and accepted in past experiences. Theaim is to avoid remaking all with each new applicationor when changing a software. Thus, we deliberately arein the framework of a capitalization and reuse approachof functional, organizational and software components,at all stages of the PIS development cycle.

Today the reuse approach is extensively used insoftware engineering, and different forms of reusablesoftware components have already been proposed.Three major approaches can be identified: toolkits [5],frameworks [6,7] and patterns [8,9].

A special interest is given to the pattern approachwhich is, in our opinion, the most suitable form of reusefor PIS engineering. In the next paragraph, we shalldevelop the concept of patterns and show its advantagesfor PIS design.

3.2. Patterns

The Pattern concept was initially proposed inarchitecture field by Alexander. In Alexander et al. [8],a pattern is defined as follows: ‘‘Each pattern describes

both a problem which occurs over and over again in our

environment, and then describe the core solution to that

problem, in such a way that you can use this solution

million times over, without ever doing it the same way

twice’’. Then, the pattern approach has been adoptedinto software engineering. The first object orientedpatterns were introduced by Beck and Cunninghan[10]. More recently, patterns dedicated to InformationSystems engineering were proposed by Coad [11],Gamma [9], etc.

Several pattern definitions are presented. It comes outfrom these definitions that a pattern constitutes a know-how base to solve a problem frequently occurring in aparticular field. This know-how allows to identify theproblem to solve (for example a BOM4 management), topropose a correct solution to take it into account andfinally to give indications to adapt this solution in aparticular context.

This form of reusable component has several advan-tages over the toolkits and frameworks approachespreviously mentioned. First, the granularity of thepattern provides a very modular reasoning unit, as eachpattern exists to solve a standard problem. Integrationin the same pattern of a standard problem and asolution forms a component search and integration aid.Naturally, problems have still to be solved regardingpattern composition and organization in order to ensureeffective reuse.

Furthermore, we should highlight that patterns are‘‘know-how’’ oriented components, while other formsof reusable components are rather ‘‘know’’ orientedcomponents. These latter provide only solutions to

problems whereas ‘‘know-how’’ oriented componentsprovide solutions but also a manner to construct thesesolutions. Patterns form hence an engineering guide byorganizing hierarchically and functionally problems andthe manner to resolve them.

Reuse of patterns is, in our opinion, the most suitableform of reuse for PIS engineering, as it can be used in allstages of the PIS development cycle (analysis, design,implementation).

Our objective is thus to adapt the pattern approach toa particular field, that is of PIS, according to a targettechnology, the PDMs.

3.3. Patterns in PIS

The proposed methodological framework is based ona consistent set of models of varying abstraction levelsthat can be developed by reuse of patterns. Each levelproposed must enable a problem to be solved (of aconceptual, organizational, technical nature, etc.) spe-cific to PIS development. Just as for managementinformation systems engineering, two main aspects mustbe taken into consideration in PIS engineering: first, anorganizational aspect specifying the organizationalinformation system (OIS) and with which ‘‘business’’patterns will be associated, and, second, a technicalaspect (software) specifying the part of this OIS whichwill result in computerization. This is the computer-based information system (CIS) which will result inspecifying and reusing ‘‘software’’ patterns.

* At organizational level, business patterns are veryimportant, particularly in the stages of formulation ofneeds and definition of functional specifications.They provide solutions for application field problemsso they must be able to take into account a set ofinformation needs associated both with the productdescription and the various industrial and businessprocesses acting on it. In the definition of organiza-tional level, two forms of modeling are essential:product modeling [12–16] and process modeling [17–19]. With respect to product modeling, the aim is touse and adapt the modeling solutions taken fromindustrial and mechanical engineering work, as wellas from information systems engineering. Withrespect to process modeling, we base ourselves onenterprise modeling and integration work [20–22], ontechniques of Business Process Reengineering type[23] and on work carried out in information systemsprocess engineering.

* At technical level, the definition of software patternsis strongly linked to the PDM systems which are atthe basis of PIS development. The generic nature ofmodeling based on software patterns stems from itsindependence from a PDMs. This modeling is theexpression of a technical solution that takes two4 Bill Of Material.

L. Gzara et al. / Robotics and Computer Integrated Manufacturing 19 (2003) 239–261 241

major problems into account: implementation ofproduct and process models and communication ofthe PIS with other systems. With respect to imple-mentation of product and process models, PDMs usedatabase models (relational or object) and ‘‘work-flow’’ models. In both cases the models proposedin the tools are extensively used and can thusbe integrated in the proposed methodologicalframework.

Definition and specification of software patterns asso-ciated with PIS are based on the functions proposed bymost PDM systems. With respect to business patterns,mainly used for formulation of needs and definition offunctional specifications for PIS, the aim is to identifythe problems from the field’s analysis. We give interestin the present research to business patterns and speciallythose for product modeling.

3.4. Formalism and examples

Formalism: Several formalisms can be used torepresent a pattern.5 They are characterized by thenumber of more or less detailed headings that theypropose. In order to simplify the comprehension of thepatterns we are later presenting (Section 5), we adaptedthe Gamma formalism by retaining and adapting only

the five headings that we judge essential. These headingsare detailed in Fig. 1.

We should note that the choice for UML6 formalismwas dictated by its capacity to support dialog betweenusers and designers of the system and by the variety ofabstraction levels of the diagrams it offers so to ensure acontinuum during specification.

Examples: To illustrate the notion of pattern, wepartially present in the next two design patterns called‘‘item-description’’ and ‘‘composite’’. These patterns areparticularly retained since the problems which they raiseare rather general to correspond to problems frequentlyoccurring in PIS. They are hence frequently used in ourapproach. In fact, to specify business patterns, we needfirst to identify, through a field’s analysis, the mostrecurrent problems occurring in PIS field and second, topropose solutions to these problems. This latter phase ismade easier by exploiting solutions already proposed indesign pattern catalogues and available in softwareengineering field. Indeed, problems encountered in PIScan be brought into general problems, resolved in thesecatalogues.

To keep illustration homogenous in the whole paper,we use the formalism presented in Fig. 1 to describethese patterns. Moreover, we express the examples inmotivation and solutions in semi-formal description

headings, using the UML formalism (see Figs. 2–5).The original patterns are described in the literature with

Name: the name of the pattern,

Classification: relating to product or process,

Intention: the problem to which the pattern addresses,

Motivation: a scenario (an example) of application of the pattern describing, in textual manner and possibly graphic, particular problems,

Semi-formal description: the solution suggested by the pattern, expressed using UML6 diagrams and describing in particular the participants in the pattern and their collaborations.

Fig. 1. Formalism for patterns description.

Name: item-description pattern.

Intention: this pattern is used when some attribute values may apply to more than one object in a class, it allows the management of data from different levels.

Motivation: an “aircraft” object knows its own tail number (e.g. N123ABV) and flight’s hours number (e.g. 5000 hours): it also knows about exactly one “aircraft description” object. An “aircraft description” object knows its own manufacturer (e.g. Boeing), model (e.g. 747-400), and standard cruising range (e.g. 8,333 miles). It also may know about some number of “aircraft” objects that depend on that information.

Aircraft

tail Number

flight’s hours nb.

Model ? () { }

Aircraft Description

manufacturer

model

standard Cruising Range

0..*1

description

return description.model

Fig. 2. Example.

5 Formalisms of Coad [24], Gang of Four or Gamma [9], Fowler

[25], etc.

6 Unified Modeling Language; the standard of modeling in object-

oriented development (see Appendix A).


other formalisms. Moreover, we give sometimes preci-sion to motivation and solution headings particularlyabout behavioral aspects and objects collaboration. Wehope thus not denaturing the initial intention of thepatterns authors.

Item-Description Pattern [11]. We should notethat the ‘‘item-description’’ pattern is also known by‘‘materialization pattern’’. This latter was largelydiscussed and more formalized with the TELOSlanguage in [27]).

Composite Pattern [26].

3.5. Towards a new development cycle: the For reuse and

the By-reuse engineering processes

The emergency of the pattern concept leads to thinkdifferently about the development cycle of an IS. The

classic development process based on the transforma-tion of user’s specifications into design models and thentheir implementation on a specific software remains veryslow since in every new project, designers develop newmodels without reference to what is already done inprevious projects. Introducing patterns in PISengineering process so as to accelerate the delays,requires first to construct a patterns library or catalogue.In this order, a new activity is required and consists ofidentifying and specifying these patterns. Once patternsare built, the development of an IS consists ofreusing these patterns. Thus, the classical developmentprocess evolves into two complementary processes(Fig. 6):

* One process dedicated to patterns engineering FOR

reuse, i.e. identification and specification of the

Name: Composite pattern

Intention: this pattern is used to manage a recursive object composition. It defines composite object class hierarchies and allows the addition of new components.

Motivation: Graphic editors allow recursive elaboration of composite figures from simple, predefined figures. Asolution is to define one class to manage complex figures and another to manage basic figures (text, circle, etc.). In this case simple objects are treated differently from composite objects, thus making applications weighty.

CompoundFigure

paint () { }draw()add (fig)remove (fig)access

1..*

Circle

paint ()draw()

Text

paint ()draw ()

Figure

paint ()draw ()add(fig)remove(fig)access

components

For any figure of components

figure.paint

Fig. 4. Example.

An “aircraft description” object gather all properties common to aircraft objects, such as manufacturer, model, etc.These properties shared by all aircraft objects are described in “aircraft description” level but not handled in aircraftobjects. Thus, one aircraft object would consult some of these properties. The properties of “aircraft-description” level remain visible at “aircraft” level by defining consultation methods allowing to propagate a value through associations. Let us take the example of model property: when one requests to an "aircraft" its model, it executes the method: Model?(), defined in its object. This method (pseudo-code return description.model) returns the value of the modelattribute in the description of the aircraft which is "aircraft-description" to the aircraft looking for it (through the description role of the association relating an aircraft to its description).

Semi-Formal description: The item description pattern consists of an “item” class and an “item description” class. An “item description” class has attribute values which may apply to more than one “item” class. An “item” class has its own individual assignment of attribute values and various consultation methods to access to the “item description” attributes values.

Item

specific-parameters

get generic-parameters ? ( ) { }

Item Description

generic-parameters 0..*1

description

return description.generic-parameters

Fig. 3. Solution.


various patterns to use during specification of PIS.This process is based on a field analysis and a study ofthe existing PIS models in order first to explore themost recurrent problems and then to specify theassociated solutions.

* One other process dedicated to PIS engineering BY

reuse of patterns, i.e. specification of PIS using thevarious patterns identified in the above process. Thisprocess, based on user’s requirements, identifies the

problems to resolve, select from the patterns librarythe patterns which resolve these problems and thenconsiders the proposed solutions.

We should note that this new process is recurrent, i.e.the models proposed in the new developed PIS, asa result of the PIS engineering by reuse, supply thepatterns engineering process for reuse so to takeconstantly into account new problems.

PISengineering PIS

userspecifications

PatternsLibrary

PatternsengineeringFOR reuse

PISengineeringBY reuse

FieldAnalysis

New PIS

userspecifications

ExistingPIS

From the classic process …

…to 2 new complementary processes

Fig. 6. New development process.

An abstract class, called "Figure", represents both composite and simple objects (or leaves). The "Figure" class contains primitive operations such as draw and paint as well as component management operations (access, remove, add acomponent).

The sub-classes (Circle, Text, etc.) implement graphic primitives such as paint or draw in order to color and plot a circle, text, etc. The "CompoundFigure" class also performs the paint and draw operations by recursive calls to the operations of its components: thus, in order to paint a "compound figure", all its "figures" (simple and compound) must be painted (pseudo-code For any figure of components figure.paint).

Semi-Formal description: The composite pattern consists of a "Component" class, a "leaf" class, a "composite" classand a "customer" class.

The "component" class defines the common interface of the leaf and composite objects. The "Leaf" class defines the behavior of the leaf objects. The "Composite" class defines the behavior of the composite objects and implements the component management operations. The "Customer" class handles the leaf and composite objects via the Component interface.

Component

specific_operation ()add (component)remove (component)access ()

Leaf

specific_operation ()

Composite

specific_operation () { }add (component)remove (component)access()

Customer 1..*

components

For any c of components

c.specific_operation

Fig. 5. Solution.


In the next, we are focusing on the first process, that isof patterns engineering For reuse (Section 4). A patternlanguage is given in Section 5.

Highlighting business patterns requires:

1. Identification and comprehension of the problemscommon to PIS, related to product definition,representation and processing.

2. Specification of various solutions associated to theidentified problems.

The first step, consisting of identifying problems fromthe PIS field, is based on the study of existing models inPIS. However, few are the contributions7 that take intoaccount the whole concepts needed in PIS and model thevariety of relationships existing between these concepts.Existing proposals for modelling product engineeringconcepts rather address parts from this field but not thewhole [29–31]. Moreover, we noted the absence of aconsensus on the concepts managed in PIS, on theirformalization and on their behavior. We therefore focusour efforts on constructing a generic framework for PIS,providing a reference model for the field, which can betailored for the needs of a given PIS environment. Thisgeneric framework provides a common terminology anda semantic of the principal concepts and proposesvarious models to fix these concepts.

The reference model thus obtained forms, withthe existing PIS models, a basis for exploring theproblems frequently occurring in the field. Onceidentified, these problems are compared to problemstreated in existing design patterns catalogues. Thisallows, on the one hand, to fix the problems alreadytreated in catalogues and, on the other hand, to discovernew problems.

Once problems are identified and classified, thesecond step of the engineering pattern process consistsof specifying solutions to these problems. Many scenar-ios can exist:

* If the problem is already treated in design patterncatalogues, the corresponding existing pattern is thusintegrated in our pattern catalogue.

* If the problem is a refinement (particular case) of aproblem already treated in design pattern catalogues,new patterns are thus defined on the basis of theexisting patterns treating the general problem.

* If the problem is complex and can be brought backinto problems raised in design pattern catalogues, it isbroken down into sub-problems so that they corre-

spond to the problems treated in the existing patternsand the associated solutions are integrated in theproposed solution.

* If the problem is new, a new solution is proposed.

Fig. 7 gives a description of the patterns engineeringprocess for reuse, using an UML activity diagram.

In the following, the process of patterns engineer-ing is developed. First, the generic framework ispresented (Section 4) and then, an overview ofthe developed business patterns language is given(Section 5).

4. Generic framework for PIS

The aim of the generic framework is to fix aterminology and a semantic for the concepts managedin PIS and then to model the variety of relationshipsexisting between these concepts. As we specified inSection 2, PIS are articulated around two axes: productwhich the purpose of the PIS and processes acting on itduring its life cycle.

We report particularly on the product axis for whichwe describe in the sequel the principal concepts.

4.1. Product abstraction levels

First of all, we underline that the term product is ageneral concept whose employment and significancediffer from the context. It takes various aspectsaccording to the business considered. Furthermore,many terms referring to the product are used, such asexemplary, generic product, specific product, basicproduct, etc. Thus, the term product is referred some-times to virtual objects sometimes with physical objects.

To relieve this ambiguity, we define three abstractionlevels of the product concept:

* Production process (manufacturing, support, andmaintenance) relates to a physical object; an indivi-dualized exemplary of a product: that’s the product-

exemplary level. For example, in cars production,

mypeugeot206 � S16.* Engineering process, on the other hand, generally

relates to the model of product according to whichexemplars (with same technological parameters anddefinition) will be manufactured: it is the objective tobe reached; the product generally presented incatalogues: that’s the product-type level. Thus, the

model according to which my peugeot 206-S16 was

manufactured is the product-type peugeot206 � S16.* However, in many companies adopting routine

design or providing products varying with customerrequirements, the development concerns a genericproduct referring to a set of similar product types anddefined with a set of possible options and design

7 We quote mainly the draft standard STEP (Standard for Exchange

of Product model dated) developed by the ISO under the reference

ISO10303 whose aim is to develop a standard of product data

representation allowing exchange and sharing of these data [31]. We

quote also the Object Management Group initiative [28] aiming to

develop standard interfaces for PDMs in order to make easier

exchange between the various systems.


variants8 (with a multiple configuration that can bereused several times for design of product types):that’s the generic-product level. For example the line of

products peugeot206.

Exemplary-Product is a physical product whereasProduct-Type and Generic-Product are virtual products.

Fig. 8 illustrates the concept of three abstractionlevels for the product car.

The distinction we made between the abstractionlevels of a product is not simply to raise a terminologicalambiguity but especially because we noticed that theknowledge associated with a product is not finallyrelated to the ‘‘same’’ product but to various levels ofthis product. Thus, in order to organize the variousproduct related knowledge, it is necessary to distinguishthese different abstraction levels so to affect the suitableknowledge to the appropriate level.

The figure a proposes to model the three abstractionlevels. It was built by using twice the ‘‘item-description’’pattern (Section 3.4). In fact, ‘‘generic-product’’ isa description of ‘‘Product-type’’ and this latteris a description of ‘‘Product-exemplary’’, since the

PatternsLibrary

PatternsengineeringFOR reuse

PISengineeringBY reuseField

Analysis

New PIS

ExistingPIS

Identify problems

Construct

reference model

Analyse

existing models

Identify

problems

Integrate the associatedpattern in our catalogue

Define new patternsderiving from

exiting patterns

Break down the probleminto sub-problems whichare treated in catalogues

Integrate the patternsassociated to the sub-

problems in our catalogue

Define new solution

Problem already treatedin patterns catalogues

Problem is refinement of problemalready treated in catalogues

New problem

Problem breakable into sub-problems treated in catalogues

Specify solutions

Fig. 7. Patterns engineering process, for reuse.

Generic Product Product-Type Exemplary-Product

Peugeot 206

GP-Name = peugeot 206engine = thermal or with injection

or 4 cylinders or electriccolor = gree or red or blue

Peugeot 206-S16

PT-name = peugeot 206-S16 engine = 4 cylinderscylinder = 2 litresvalves nb = 16 color = green or blue

My Peugeot 206-S16

PE-name = peugeot 206-S16 engine = 4 cylinderscylinder = 2 litresvalves nb = 16 color = bleuserial nb. = S16.98.100

Fig. 8. Three levels of peugeot 206.

8 Used in the product structure to indicate a co-ordinated set of

alternatives in the design which produce a different product, for

example, a 4-cylinder auto versus a 6-cylinder auto. Design variants

represent sets of variations which evolve in versions consistent with the

rest of the product [1].


generic-product (respectively product-type) gathers allshared properties of product-types (respectively pro-duct-exemplars).

4.2. Knowledge on levels

Product Life cycle: A product, whatever is its level(generic, type, exemplary), has a life cycle through whichit evolves and consequently passes by various states.Fig. 10 shows a standard life cycle of the product-type.The formalism used is UML state diagrams [32].

The first step in the engineering process is to study thefeasibility. The product-type is created in a studied statewhile the feasibility study is running. When this latter isfinished, the product-type is abandoned if it is notfeasible or evolving into functional state if it is feasible.In this case, the product is described in terms of expectedfunctions and a definition phase is launched, aiming atrefining user’s requirements. When the definition isfinished, the product-type evolve into specified state anda development activity is done, aiming at specifying atechnical solution and manufacturing methods. Oncethe development is finished, the product-type becomedefined and the exploitation (manufacture of exemplars)can start. When the exploitation is finished, the product-type is retrieved from the activity portfolio. We shouldnote that transitions between states in the abovediagram are occurring when the activities in the previousstate are finished and there is no external event to occur.

Representations of knowledge: During the wholeproduct life cycle and depending on the state of theproduct, various knowledge is associated with this oneto describe it. The state of an object is so function of theknowledge associated to it. This knowledge is supportedby various representations forming thus the productmodel. We distinguish two types of representations: Bill

Of Materials (BOM) or configurations and documents.Then, in the ‘‘defined’’ state for example, the product-

type can be described by an Engineering bill of materialand detail design drawings, part plans, geometricmodels, etc. In the following, we describe each type ofrepresentations.

Document: A document is defined as a container forknowledge aiming at describing an object and seized on asupport (paper, tape, cassette, disc, microfilm, etc).According to the document finality, we distinguish twotypes of document. Models aim to define the product(such as CAD drawings) or to control the way in whichthe associated processes must be carried out (such asmanufacturing process routings). Records report theactivities results (such as control sheets). A documentcan be therefore composite or elementary. Such as thecase of folders which are composed of a set of documents,gathered in some way in order to treat easily the variousknowledge at operational status (such as contractual file,engineering file, manufacturing file, etc.) (Fig. 11).

We should note that to represent the concept ofcomposition, the model proposed in Fig. 11 was built by

Virtualrealization

Physicrealization

modelmodel

1 0..*1 0..*

Product-Type

Type-parameters

Product-Exemplary

exemplar-parameters

Generic-Product

Generic-parameters

Fig. 9. Product levels sub-model.

studied

do: feasibilitystudy

Functional

do: define

specified

do: developdefined

do: exploit

[study OK]

[study not OK]

productretrieved

productabandoned

Fig. 10. State diagram of a product-type.


adapting the ‘‘composite’’ pattern of Gamma (Section3.4).

Bill Of Material: a BOM is defined as a graphstructure composed of nodes of same nature and linkedby composition9 relationships. It describes the product,at a particular abstraction level, from several points ofview, such as:

* its finality: functional BOM is a hierarchicallystructured description of the product functions. It isbuilt for the highest product level (generic-product ingeneral) and established during the feasibility study.

* its definition: engineering BOM is hierarchicalrepresentation of the items constituting the product.It is built for the generic-product and product-type and established during development phase. InFig. 13, we propose a modeling of the recursive items

composition.* its manufacturing process: manufacturing BOM is a

description of successive steps of product elaborationstarting from raw materials, parts, sub-assemblies,assemblies until the product itself. It is built forproduct-type (or product-exemplary) and establishedduring manufacturing preparation phase.

* its maintenance process: logistic BOM is a treestructure of logistic support elements, organized bymaintenance levels. It is built for product-type orproduct-exemplary.

A BOM is thus a recursive composition of technicalobjects, whereas a technical object is a component of theproduct. It can be an item, as in the case of organicBOMs (engineering, manufacturing and logistic BOMs),a function as in the case of the functional BOM, afeature in the case of a geometric BOM, etc. In the next,we present the most used technical objects, that isFunction and Item).

Function: The feasibility study describes the productin terms of expected functions to be satisfied by theproduct. A function is an action of the product or one of

its parts expressed in terms of finality [34]. A function canthus be:

* an external function expressing an action provided bythe product to the environment. It describes what theproduct does to satisfy a user need and

* an internal function describing the behavior ofproduct components in terms of how they contributeto realization of external functions.

A function whatever is its nature (internal, external) canbe elementary or composite. In the last case, it is onlycomposed of functions of same nature (Fig. 12).

We note that functions defined at generic-productlevel remain available at lower levels.

Item: Many terms are used in organic productdecomposition, such as component, part, element, sub-assembly, assembly, sub-system, system, mechanism,etc. Some of these terms correspond to logic criterion ofdecomposition (component, system, sub-system), someothers to material criterion (part, mechanism). An otherterm often used by the AFNOR10 to describe theproduct from a management point of view, that isthe Item concept which appeared to us suitable for thecontext of PIS.

An item is defined as a constituent of the product,from the most elementary11 component or part (such asa screw) to the product itself, passing by all theintermediate layers of decomposition. We class an itemaccording to criteria.

* Decomposition criterion classifies an item intocomposite-item (made up in unit) or catalogue-item

(supplied such as raw materials, parts, inseparableassemblies, etc).

document

elementary compositemodel record

2..*

{finality} {composition}

Comments

• two criteria of classification : onedocument can be elementary or compositeand be model or record. For each criteria,the double classification of document iscomplete and disjoint.

• one composite document has ascomponents other documents which can beelementary or composite themselves andmodel or record.

Fig. 11. Document sub-model.

9 A composition links a composite to its components where the

composite is an aggregation of components. Each component describes

partially the composite object [33].

10 French Association for Standards (Association Fran@aise de

NORmalisation).11 Terminal unit in product decomposition, with no interest to be

broken down.


* Variance criterion classifies an item as a variant-item

which has a set of design variants (an engine is avariant item whose variants can be diesel engine,electric engine and thermal engine) or a constant-item,i.e. with no variants. We should note that thevariance of an item is relative to the product whereit is component, for example in one particular carwhose engine can be electric, diesel or thermal, the‘‘diesel engine’’ is a variant of engine item whereas inan electricity generator the ‘‘diesel engine’’ it is theunique kind of engine.

Just like a product, an item can be perceived at twoabstraction levels. One can deal with virtual item andphysical item. It can be so described by variousrepresentations (documents, BOMs for composite-items). Thus, virtual products are composed of virtualitems and physical products are composed of physicalitems (Fig. 13).

The passage from one generic-product to product-types and then from one product-type to product-exemplars is done according to design variantsand optional items. A generic-product has at least two

Comments

• two criteria of classification : one function isinternal or external. In each case, it can beelementary or composite.

• this classification differs from that in figure 11since one composite function (of external or internalnature) can not be composed of any function butonly of function of same nature. The compositionclassification is made under each nature of function

• to each external function, a set of internalfunctions are associated to express that theycontribute to execute the external function

Function

InternalFunction (IF)

ElementaryEF

CompositeEF

ElementaryIF

CompositeIF

2..*2..* ExternalFunction (EF)

1..* 1..*

Fig. 12. Function sub-model.

Comments

• one physic item results from a definitive choicebetween a potential set of variants of a virtualitem. No variance has to be managed at physicallevel. One item can be so catalogue or compositethis classification is complete and disjoint.

• one composite item has as components otheritems which can be elementary or compositethemselves.

Physic Item

CatalogueItem

CompositeItem

2..*

Virtual Item

CatalogueItem

CompositeItem

VariantItem

ConstantItem

its variant 2..*1..*

{variance} {composition}

Comments

• two criteria of classification : one item can becatalogue or composite and be variant orconstant. For each criteria, the doubleclassification of item is complete and disjoint.

• one composite item has as components otheritems which can be elementary or compositethemselves and variant or constant.

• the variants of one variant item are items whichcan be themselves variants or constant.

Fig. 13. Item sub-models.


non-interchangeable12 design variants of the same objectin its composition (the choice of one variant isconstrained by the choice of variants of other compo-nents). A product-type does not present any choicebetween design variants or is only composed ofinterchangeable variants. Thus,

* The passage from the generic-product to product-types is made by fixing some variants for each variantitem. In the particular case of noninterchangeabledesign variants, only one design variant is chosen.Furthermore, the choice for one variant of aparticular variant item constrains the choice betweenvariants of an other variant item.

* The passage from the product-type to product-exemplars is made by fixing one design variantsbetween a list of interchangeable variants.

Let us consider the example of cars: peugeot 206/peugeot 206-S16/my peugeot 206-S16. To illustrate thisexample, we use the feature diagram formalism pro-posed in FODA [36], described in Fig. 14.

In that formalism, at the passage from one level to thelower, the selected optional items and design variantsare highlighted in the diagram with boxes. We adaptedthe formalism by introducing an additional symbol

(double-lined boxes) in order to distinguish the retaineditems in Product-exemplary level from those in Product-type level (Figs. 15–17).

Product view: Based on representations, several viewsof a product can be defined by the various businesses oractors co-operating in the product development. A viewexpresses a selective perception of the product, byaccentuating special aspects and neglecting others andserves a particular community in the company. A view isthus an extraction of information from the masterproduct model (i.e. from one or more representations)according to certain of its properties.

4.3. Reference model: synthesis

Based on the partial models introduced throughoutthe previous paragraphs, a global model is built bylinking these sub-models (Fig. 18). Therefore, some ofthe above described objects have knowledge in common,we built a super-class to these objects to which weassociate this knowledge.

Description: It comes out from the descriptions givenin Section 4.2 that a product whatever of its level isdescribed by various representations. By representation,we mean documents and Bills Of Materials.

* Each product level is documented by variousdocuments. Product-Exemplary level is essentially

OptionalComponent

Composed

ObligatoryComponent

Designvariant

Designvariant

• Optional items are designated graphically by a smallcircle immediately above the item name.

• Design variants are shown as being children of the sameparent variant item, with an arc drawn through all of theoptions.

• The remaining features with no special notation are allobligatory.

Fig. 14. Feature diagram formalism of FODA.

The generic product "peugeot 206" is composed of"engine" which has as design variants : "electric”,"thermal” or "4 cylinders". At the definition of product-types:

• The choice of the variant "4 cylinders” for engineimplies the choice of the variant "tank" for container

• The choice of the variant “electric” for engine impliesthe choice of the variant “battery” for container.

In case of choice for “4 cylinders” as engine, thecomponents of the engine are then “cylinder” and“valve”.

color bluecolor green color red

Peugeot206

engine

4 cylindersthermal

electric

container

petrol tank battery

framewheel

air conditioner

radio

4

valvecylinder

16

Fig. 15. Peugeot 206’s BOM.

12 Two objects A and A0 are interchangeable if A0 can be substituted

for A without involving evolution of any assembly using A [35].


documented with record-documents. Generic-Pro-duct and Product-Type levels are rather documentedwith model-documents. In the same way, an itemsome is its nature (virtual or physic) is documented byvarious documents (such as a plan or a CAD modelfor a mechanical component). Then, the class‘‘document’’ can be associated for both items andproduct levels. We built so a super-class to ‘‘Generic-product’’, ‘‘Product-Type’’, ‘‘Product-Exemplary’’,‘‘virtual item’’ and ‘‘physic item’’, named ‘‘documen-ted object’’ to which we associate the class ‘‘docu-ment’’ and the associated sub-model.

* On the other hand, each product level is described byvarious structures or BOMs. A Bill Of Material is arecursive composition of technical objects which canbe items, functions, features, etc. Thus, a BOM is notmanaged in the PIS as an object, with an ownexistence; it concretizes the composition relationshipsbetween composite objects and related components.It is materialized in the product model by an

association linking a the structured object, i.e. theobject to whom a BOM is associated such as theproduct, to the root of the corresponding BOMgraph which is a composite technical object.Hence:

* Structural BOMs describing Generic-Product andproduct-type are based on recursive composition ofvirtual items. They are modeled by an associationbetween the ‘‘product level’’ class and the ‘‘compositevirtual item’’ class, corresponding to the top levelof the associated BOM. Since several BOMs basedon items are existing, each one is modeled in theitem recursive composition model by a parti-cular composition link stereotyped according to itsnature (‘‘engineering BOM’’, ‘‘manufacturingBOM’’, etc.).

* Structural BOMs describing Product-Exemplary arebased on physical items. They are modeled by anassociation between the ‘‘Product-exemplary’’ classand the ‘‘composite physic item’’ class.

The product-type "peugeot 206-S16" has as

color variants : "green" or "blue". The choice of

any one of these variants doesn't trouble the

composition of the product. All exemplars of

peugeot 206-S16 are composed of a "4 cylinders

engine", "2 litres cylinder" and 16 "valves",

whatever their color.color bluecolor green

color red

Peugeot 206-S16

engine

4 cylindersthermalelectric

container

petrol tank battery

framewheel

radio

4

valvecylinder

16

air conditioner

Fig. 16. Peugeot 206-S16’s BOM.

At the exemplary level (my peugeot 206-S16), the

structure is solidified and no choice for variants

or options is possible.

valveref. V321

color bluecolor greenref..GF147

color red

My Peugeot 206-S16

engine

4 cylindersref. CE258

thermalelectric

container

petrol tankref.. PT123

battery

frameWheel

ref..W789

Radioref. RD741

4

cylinderref.C369

16

air conditioner

Fig. 17. My peugeot 206-S16’s BOM.


* Only Generic-Product is described by functionalBOM. This latter is modeled by an associationbetween the ‘‘Generic-Product’’ class and the ‘‘com-posite external function’’ class.

Analysis: The proposed reference model was built,basing on the hypothesis of three levels of product. Itrelies then functional BOM to only ‘‘generic-product’’,for example. We highlighted the existence of threeproduct levels in the enterprise but some organizationsmay not have generic product. In this case, functionalBOM is rather associated with ‘‘Product-Type’’. Someother organizations may not manage product-exemplarylevel. In this case, there is no reason to distinguishphysical items. Furthermore, the number and type andBOMs managed is widely varying between organizations(functional BOM and hence functions may not bemanaged whereas geometric BOM exits for example).Type of documents is also varying.

Then, Fig. 18 can be perceived as a possible productmodel for a PIS based on three levels of product, threeBOMs (functional, engineering, manufacturing) andrecord and model documents.

The reference model so obtained is both too generaland too specific. It is general because it does not express

specific properties to organizations (for example itemproperty ‘‘resistance’’ for an electronic cards industry).Thus it is not easily used by organizations. On the otherhand, it is specific in the mean where it expresses aparticular case of three product levels, three BOM types,etc.

The aim to build a generic product model, raising alldifferences due to the luck of a consensus about PISconcepts, is very ambitious. We can only express thevariability about these concepts. The Key remainingchallenge is so to keep general the reference model, evenmore general and more complete than the current one,and to give a method to express the variability.

* One solution consists of proposing first a meta-model,too general and then declining various models fromthis meta-model by instantiating it according tovarious specificity points. This solution remainrestrictive since it fixes in advance the specificity.

* An alternative solution is to propose first a generalmodel and then to give a method to refine this modelbased on various patterns, allowing each one tospecify one particular variability point. This ap-proach seems more suitable since it is more flexible.

0..*

documented

« BOM »

Function

InternalFunction (IF)

ElementaryEF

CompositeEF

ElementaryIF

CompositeIF

2..*2..* ExternalFunction (EF)

Virtual Item

CatalogueItem

CompositeItem

VariantItem

ConstantItem

its variant 2..*1..*Physic Item

CatalogueItem

CompositeItem

2..*

DocumentedObject

« BOM »

« BOM »

“manufacturing BOM”

“engineering BOM”

« BOM »

document

elementary compositemodel record

2..*

{finality} {composition}

0..*

{variance} {composition}

1..* 1..*

« functional BOM »

Virtualrealization

Physicrealization

modelmodel

1 0..*1 0..* Product-Type

Product-Exemplary

Generic-Product

0..* 0..*

0..*

0..*0..*

0..*

0..* 0..1

Fig. 18. PIS reference model.


The retained approach to offer a method for PISengineering is so to propose a general reference modeland then to offer a pattern language.13 That consists ofproposing a pattern language which allows to adapt thisreference model, according to various variability points,so to fit it into one organization specificity.

5. The pattern language

In the proposed reference model (Section 4), weconclude on the impossibility to fit into the genericframework one single model, too general to be used byeveryone and too specific to take into account everyorganization characteristics. The key challenge is tokeep generality in the reference framework, by expres-sing organizations variance, and to give an approachallowing construction of specific models according tothe organization preferences. This approach for PISengineering is made possible by reuse of patterns. It isbased on use of a succession of patterns resolvingvarious problems of PIS specification and providinga progressive refinement of models according to theorganization specificity. The passage from one patternto another is carried out according to two mechanismsor links: use link and refinement link.

Use link: A pattern B ‘‘uses’’ a pattern A when thesolution of pattern A constitutes completely or partiallythe intention of pattern B, i.e. the problem treated in B isa sub-problem of that in pattern A. For example patternA is for engineering change process management andpattern B is for engineering change request.

Refinement link: A pattern B ‘‘refines’’ a pattern Awhen the intention of pattern B is a special case of theintention in pattern A, i.e. the problem treated in patternB can be resolved also by the solution in pattern A. Forexample pattern A is for BOM construction and patternB is for functional BOM construction.The proposedapproach is thus a succession of business patterns reliedby these links.

5.1. Pattern ‘‘variance points’’

As stated before, there is variance between organiza-tions about some points related to product levels, kindof BOMs, document types, etc. The first step in the PISspecification project is, in our opinion, to fix specificityof the organization according to these variance pointswhich constitute the input points of the approach.Name: Variance Points.Classification: Product Pattern.

Intention: Identifying all variance points in theorganization in order to fix them so to associate theadequate knowledge.Motivation: Some organizations have single types of

products, others have also lines of products so that theymanage generic and types of products. In both thesecases, product exemplars can be or not managed,according to the criticality of the exemplars and theafter sale services (thus in aerospace domain, every planeexemplar is managed to keep trace on manufacturingconditions and maintenance changes occurring duringits life whereas in mass production such as of pencilsmanufacturing, no exemplars are managed).

Furthermore, the type and the number of BOMs usedare also varying from one organization to an other. Inorganizations all managing Product types, some of themhave only one structural BOM whereas others distin-guish technical BOM, manufacturing BOM, logisticBOM, etc.

Moreover, number and types of documents are alsovarying from one organization to another.

Solution:

1. Fix the number and type of product levels (generic,type, exemplar). For that purpose, apply the pattern‘‘Product Levels’’

2. Fix the type of applied BOMs For that purpose,apply the pattern ‘‘Applied BOMs’’

3. Associate the applied BOMs to the product Forthat purpose, apply the pattern ‘‘Associate BOMsTo Product’’

4. Fix the type of applied documents For thatpurpose, apply the pattern ‘‘Applied Documents’’

5. Associate the applied documents to the product Forthat purpose, apply the pattern ‘‘Associate Docu-ments To Product’’

Assess:In solution of pattern ‘‘Variance Points’’, it is

suggested to fix the product levels, to fix the appliedBOMs, etc. The immediate patterns have hence theintention to provide a guide to fix each of these points(Fig. 19). We only develop the pattern ‘‘ProductsLevels’’.

5.2. Pattern ‘‘product levels’’

Name: Product levels.Classification: Product Pattern.Intention: There are three abstraction levels of

product:

* Exemplary: physical object resulting from manufac-turing process,

* Product-type: the theoretical model according towhich exemplars are manufactured,

13 A pattern language is a set of patterns relied with links of various

natures such as use, extension/refinement and alternative links. These

links were developed in [37].


* Generic product: a theoretical model including allpossible options and design variants, according towhich the definition of a particular product-type isdeclined by a particular choice of options andvariants.

The pattern ‘‘Product Levels’’ allows identification ofthe number of product levels managed in the organiza-tion and proposes solution to represent them.Motivation: Let us take the following example for the

product ‘‘Car’’ (Fig. 20). This product takes variousaspects and is described by different knowledge accord-ing to the business dealing with. We distinguish threeaspects:

* The exemplary-product: the product which is deliv-ered to the customer, such as my peugeot 206 S16.

* The product type: the model defined by the engineer-ing services and according to which various exem-plars are manufactured in production units, such asthe peugeot 206 S16. It is the product presented in thecatalogue and according to which the customer placesa buying order.

* The generic product: a line of product types sharingmany characteristics and deriving by some options or

variants in their structure. It is the product developedby engineering services and according to which theyderive various configurations according to differentcustomer requirements. The line peugeot 206 is ageneric product.

The entity Generic-Product has an abstraction levelhigher than the entity Product-Type. This latter is higherthan Product-Exemplary.

Generic and type levels are virtual products whereasexemplary level corresponds to a physical product.

These levels of product are distinguished because theknowledge associated with the product is varyingaccording to the level. In order to organize thisknowledge, it is necessary to distinguish these levels soto affect the suitable knowledge to the appropriate level.Solution: An organization has always a product type

(for example: peugeot 206-S16). To identify the otherlevels, one must answer to the following questions:

1. do you manage physical exemplars?Case a: yes. There is the levels Product-type andProduct-exemplaryCase b: no. There is the level Product-Type

Pattern « Product Levels »

Pattern « Applied BOMs »

Pattern « Associate

BOMs To Product »

Pattern « Applied Documents »

Pattern « Associate

Documents To Product »

Pattern « Variance Points »

“use”

“use”

“use”

“use”

“use”

Fig. 19. Fixing variance points.

Generic Product Product-Type Product-Exemplary

Peugeot 206

GP-Name = peugeot 206engine = thermal, with injection

or 4 cylinderscolor = green or red or blue

Peugeot 206-S16

PT-Name = peugeot 206-S16engine = 4 cylinderscylinder = 2 litersvalve nb = 16color = green or blue

my Peugeot 206-S16

PE-Name = peugeot 206-S16engine = 4 cylinderscylinder = 2 litersvalve nb = 16color = blueserial number = S16.98.100



2. does the product type forms a part of a product-line?Case c: yes. There is the levels Generic-Product andProduct-typeCase d: no. There is the level Product-type

General structure:3. if case a and c are true: There is three levels; generic,

type, exemplar. Apply pattern ‘‘Three Levels’’4. if case a and d are true: There is two levels; type,

exemplar. Apply pattern ‘‘Two Levels’’5. if case b and c are true: There is two levels; generic,

type. Apply pattern ‘‘Two Levels’’6. if case b and d are true: There is one level; type.

Apply pattern ‘‘One Level’’

Assess:

The solution in pattern ‘‘Product Levels’’ suggests touse various patterns to represent one, two or three levels(Fig. 21). In the following, we describe the patterns‘‘Two Levels’’ and ‘‘Three Levels’’.

5.3. Pattern ‘‘two levels’

Name: Two levelsClassification: Product pattern.Intention: this pattern allows representing the product

concept in 2 abstraction levels in order, first to partitionknowledge between these levels (common properties inhigher level and individual properties in lower level) andsecond to define relations between the levels so to allowpropagation of properties values between levels. Thispattern can be applied for representing Generic-productand Product-type levels as well as Product-Type andProduct-Exemplary levels.Motivation: Let us consider the example for the

product Car. We illustrate the particular case of thetwo levels: Product-Type and Product-Exemplary(Fig. 22).

Knowledge associated with these 2 entities (Product-Type PT, Product-Exemplary PE) depends on theabstraction level. The entity Product-Type has anabstraction level higher than the entity Product-

Exemplary.Otherwise, the knowledge described for each of these

entities is of two types:

Entity properties: An entity takes a value for each oneof its properties. For example, properties engine = 4

cylinders for the product-type Peugeot 206-S16 andserial number = S16.98.100 or color = blue for theexemplary my Peugeot 206-S16.

We notice that a property value existing at a certainabstraction level must be visible at a lower level. Then,the property engine of the Product-Type: Peugeot 206-S16 having for value 4 cylinders, is also visible in theProduct-Exemplary: my Peugeot 206-S16.

Constraints: Expressed at a certain abstraction leveland bearing on values of lower level properties. Forexample, the constraint color ¼ greenorblue; expressedfor the Product-Type: Peugeot 206-S16, constrains thevalue of the property color of the Product-Exemplary:my Peugeot 206-S16 (color = blue).

In Fig. 23, we propose a class diagram and aninstance diagram that partially represent the exampleabove. Associations allow to link every exemplary toits product-type. peugeot206-S16 (respectively my peu-geot206-S16) is an instance of the ‘‘Product-Type’’ class(respectively ‘‘Exemplary-206-S16’’ class).

The properties of a level remain visible at the lowerlevel by defining consultation methods allowing topropagate a value through associations. Let us takethe example of engine property: when one requests to mypeugeot206-S16 its engine, it executes the method:Engine? (), defined in its class ‘‘Exemplary-206-S16’’.This method returns the value of the engine attributefrom the model of the ‘‘exemplary 206-S16’’ (pseudo-code return model.Engine?), which is ‘‘Type-206’’(through the model role of the association between anexemplary and its type). In the example, the value ofthat attribute is 4 cylinders.

However, the preceding modeling does not allowrefining constraints on a property at the Product-Exemplary level. In the present example, the color

property is constrained at type level (color of peu-geot206-S16: blue or green). An other type of productsuch as peugeot 206-1,1 L XR for example, can onlyhave the colors: green or red.

Thus, the preceding modeling does not allow illus-trating this intermediate layer of constraint on the color,according to the type of product. Then we add the

Pattern « Product Levels »

Pattern «Three Levels»

Pattern «Two Levels»

Pattern «One Level»

“use”

“use”

“use”

Fig. 21. Product levels.

Product-Type Product-Exemplary

Peugeot 206-S16


my Peugeot 206-S16

PE-Name = peugeot 206-S16engine = 4 cylinderscylinder = 2 litersvalvenb = 16color = blueserial number = S16.98.100

Fig. 22. Two levels of peugeot 206.


abstract class ‘‘Exemplary-206’’ whose the class ‘‘Ex-emplary-206-S16’’ is a subclass. It is thus possible todefine other subclasses (‘‘Exemplary-206-1,1 L XR’’ forexample) holding different constraints––see Fig. 24.

Solution:

1. A company organizes its activities around twoproduct abstraction levels. There exist two abstractclasses (Fig. 25).Product higher level ‘‘PHL’’, holding commonproperties to lower level products deriving from itand a set of possible values for some properties.Product lower level ‘‘PLL’’, holding specificproperties of lower level products associated toone higher level product and a fixed value of someproperties.

Two scenarios can exist: ‘‘PHL’’ is a generic-productand ‘‘PLL’’ a product-type or ‘‘PHL’’ is a product-typeand ‘‘PLL’’ a product-exemplary.

2. When the company decides to create a new ProductHigher Level (for example a new generic-product),let us phl1. That corresponds to the creationof a new set of products (for example line ofcars ‘‘peugeot 206’’) (Fig. 26), sharing commoncharacteristics. Phl1 is then an instance ofthe ‘‘PHL’’ class. That results in the objectphl1:PHL.With the creation of a new set of products phl1,there will be probably various lower level productsderiving from the new set phl1 (for example variousproduct-types). One then creates a concrete class forall lower products resulting from phl1 (for example

peugeot206-S16 :Type-206

PT-Name = peugeot206-S16 engine = 4 cylinders

my peugeot206-S16 :Exemplary-206-S16

serial number = S16.98.100color = blue

Physicrealization

model

1 0..*

return model .engine

Type-206

PT-Nameengine : enum (thermal, withinjection, 4cylinders)

Exemplary-206-S16

serial numbercolor : enum (green, blue)

Engine? () { }

Classdiagram

Instancediagram

property

constraint

Fig. 23. Properties and constraints.

Exemplary-206-1,1L XR

color : enum (green,red)

Exemplary-206-S16

color : enum (green,blue)

Physicrealization

model

1 0..*Type-206

PT-Nameengine : enum (thermal,with injection, 4cylinders)

Exemplary-206

serial numbercolor : enum (green, redblue)

the constraint on the color isrefined between the generic-product "Peugeot 206" (color= green or red or blue) and theproduct-type "peugeot 206-1,1LXR" (color = green or red).

my peugeot206-S16 :Exemplary-206-S16

serial number = S16.99.15color = blue

my peugeot206-1,1 LXR :Exemplary-206-1,1 LXR

serial number = LXR.98.10color = green

Fig. 24. Constraint refining.

realizationmodel

1 0..*

PLL

specific parameters

PHL

common parameters

Fig. 25. Two abstraction levels of product.


product-types of peugeot 206), let’s ‘‘PLL (phl1)’’.This class contains specific properties to phl1 lowerlevel products

Assess: any creation of a new higher level productgenerates one instance of the class PHL and one sub-class of the class PLL (Fig. 27).

We should note that in the proposed solution, we dealwith a partition of the class ‘‘PLL’’. In fact, for eachinstance of ‘‘PHL’’ class (peugeot 206 for example), thereexist a sub-class of ‘‘PLL’’ associated to this instance to

represent all lower level products raising from thatinstance of higher level product (for example Type-

peugeot 206, for all product types in the line peugeot 206).Thus, the population of ‘‘PLL’’ class is partitioned intosub-classes. This partition is controlled by an inheritancelink. In [27], this concept was largely discussed.

5.4. Pattern ‘‘three levels of product’’

Name: Three levels.Classification: Product pattern.

realizationmodel

1 0..*

PLL

specific parameters

PLL (phl 1)

specific properties to phl 1lower level products

PHL

common parameters

phl 1: PHL

common properties to phl 1lower level products

creation of a new PHL, i.e. phl1 (forexample a new generic-productpeugeot206), implies probablycreation of various lower levelproducts relating to phl1 (variousproduct-types of peugeot 206).

Fig. 26. Creation of a new Product Higher Level (phl1).

realizationmodel

1 0..*

PLL

specific parameters

PLL (phl 1)


PHL

common parameters

phl 1: PHL


phl 2: PHL


PLL (phl 2)


Fig. 27. Creation of two higher level products (phl1 & phl2).

Generic Product Product-Type Product-Exemplary

Peugeot 206

GP-Name = peugeot 206engine = thermal, with injection

or 4 cylinderscolor = green or red or blue

Peugeot 206-S16


my Peugeot 206-S16

PE-Name = peugeot 206-S16engine = 4 cylinderscylinder = 2 litersvalve nb = 16color = blueserial number = S16.98.100



Intention: This pattern allows representing the pro-duct concept in three abstraction levels in order, first topartition knowledge between these levels (commonproperties in higher level and individual properties inlower level) and second to define relations between the

levels so to allow propagation of properties valuesbetween levels (Fig. 28).Motivation: We consider the example of the product

Car. We distinguish three levels of this product:Knowledge associated with these three entities (Gen-

eric-Product GP, Product-Type PT, Product-ExemplaryPE) depends on the abstraction level. The entityGeneric-Product has an abstraction level higher thanthe entity Product-Type. This latter is itself higher thanProduct-Exemplary.Solution: A company organizes its activities around

three product abstraction levels:The ‘‘Generic-Product’’ level, holding the properties

of generic products (such as GP-name).The ‘‘Product-Type’’ level, holding the properties of

the types of products, resulting from various genericproducts (such as PT-Name, launching-date).

The ‘‘Product-Exemplary’’ level, holding theproperties of the exemplars relating to various types

virtualrealization

model

1 0..*

Product-Type

PT-Namelaunching date

Product-Type (gp1)

Product-Type (gp1)-Name

Generic-Product

GP-Name

Gp1 : generic-Product

GP-Name = gp1

Fig. 29. First application of pattern ‘‘two levels of product’’.

physicrealization

model

1 0..*

Exemplary-Type (gp1)

Parameter : enum (a, b, c)

Exemplary (pt1-gp1)

parameter : enum (a, b)

Product-Type (gp1)

Product-Type (gp1)-Name

Pt1-gp1 : Product-Type (gp1)

Product-Type (gp1)-Name = pt1-gp1

Fig. 30. Second application of pattern ‘‘two levels of product’’.

my pt1-gp1: Exemplary(pt1-gp1)

color = blue

Virtualrealization

model

1 0..*

Product-Type

PT-Namelaunching date

Generic-Product

GP-Name

gp1 : Generic-Product

GP-Name = gp1

pt1-gp1 : Product-Type(gp1)

Product-Type(gp1)-Name = pt1-gp1

Exemplary(pt1-gp1)

color : enum (green, blue)

Physicrealization

model

1 0..*Exemplary-Type (gp1)

color : enum (green, red, blue)

Product-Type (gp1)

Product-Type(gp1)-Name

Fig. 31. Three abstraction levels modeling.


of products (such as serial-number, manufacturing-

date).Generic-Product level is higher than Product-

Type level, which one is higher than Product-Exemplarylevel.

1. Apply the pattern ‘‘Two Levels’’ to the ‘‘Generic-product’’ as the ‘‘PHL’’ and the ‘‘Product-Type’’ asthe ‘‘PLL’’. An instance of the ‘‘PHL’’ class is, inthis case, a new generic product (corresponding tothe creation of a new product line) that we namedgp1 (for example the generic product: peugeot206).The model (Fig. 29) is obtained:

2. Apply again the pattern ‘‘Two Levels’’ to the‘‘Product-Type (gp1)’’ as the ‘‘PHL’’ and theexemplars of this latter, let us ‘‘Exemplary-Type(gp1)’’ as the ‘‘PLL’’. An instance of the PHL classis, in this case, a new type of product in theline of products gp1 (for example the type peugeot206-S16 in the line of peugeot 206 products)that we named pt1-gp1. The model (Fig. 30) isobtained:

General structure:The final model obtained by joining the two models

above is the following (Fig. 31):

my pt1-gp1 is an individual exemplar manufactured inthe organization, delivered for me.Assess (Fig. 32):

5.5. Overview on the pattern language

In the following (Fig. 33) we give, in a use-casediagram, an overview of the whole business patternlanguage developed for product modeling.

6. Conclusion

Reuse, already efficient in software engineering, isalso interesting for PIS engineering. This approachevolves the classical development process into twocomplementary processes: one dedicated to patternsengineering FOR reuse (identification and specificationof patterns) and one other dedicated to PIS engineeringBY reuse of patterns.

A special interest was given to the first process, i.e. theBy reuse process. For that purpose, the first stepconsisted of identifying the most recurrent problems inPIS field. This exploration is based on the study ofexisting PIS models but also on a field analysis aiming atconstructing a reference model for PIS. After identifying

Pattern «Three Levels» Pattern «Two Levels»“use”

Fig. 32. Use of pattern ‘‘two levels of product’’.

Pattern «Product Levels»

Pattern «Applied BOMs »

Pattern «Associate

BOMs To Product »

Pattern «Applied Documents »

Pattern «Associate Documents To Product»

Pattern «Construct BOM»

Pattern «Variance Points»

“use”

“use”

“use”

“use”

“use”

Pattern «Three Levels»

Pattern «Two Levels»

Pattern «One Level»

Pattern «BOM With Variants»

“use”

“use”

“use”

“refine”

Pattern «BOM With

Existential Dependence»

“refine”

“use”

“use”

“use”

Fig. 33. Overview of the pattern language.


problems, the second step consisted of specifyingsolutions to the problems discussed above, basingpartially on solutions proposed in existing designpatterns catalogues. An overview of the developedbusiness pattern language is given. This pattern lan-guage is actually under test and validation by our

industrial partner. Some of the proposed patterns havebeen used to specify the extension of an existingPDM system in the domain of mechanical engineeringto take into account electronic parts of theproducts.

Extensions of the current language for a completedescription of the PIS domain including versioningmechanisms, passage between product levels mechan-isms, etc. is under progress. It has also to be extended totake into account process modeling. With term, oncebusiness patterns are identified and specified, we shallfocus on the definition of associated software patterns.After, once the pattern language is completely specified,the BY reuse process for PIS engineering will consistsimply of applying this language. The FOR reuse

process constitutes hence the specification of the BYreuse process.

Appendix A. UML notation

References

[1] CIMdata Inc. Product data management: the definition. An

introduction to concepts, benefits, and terminology (http://

www.cimdata.com/), 1997.

[2] Waite EJ. In: Kosanke K, Nell JG, editors. AIT—advanced

information technology for design and manufacture. Proceedings

of the ICEIMT’97 International Conference on Enterprise

Integration and Modeling Technology, 1997.

[3] RISESTEP. Enterprise wide standard access to step distributed

databases. Esprit 4 Project, 1996–1998.

[4] OPAL. Integrated information and process management in

manufacturing engineering. Esprit 4 Project, 1997.

[5] Poulin JS. Populating software repositories: incentives and

domain specific software. J Systems Software, 1995;30:187–99.

[6] Wilson DA, Rosenstein LS, Shafer D. Programming with

MacApp. Reading, MA: Addison-Wesley, 1990.

Class

Class diagram

A

property

operation

C

B

D Generalization

Composition

Association

b:B

property = value

objectBinding

1..*

Multiplicity

Initial state

Final state

activity

event [Guard condition]

activity

activity

transition with

exclusive conditions

transition

Activity Diagram

Initial state

Final state

State

do: operation

event [Guard condition]

State Diagram

Use case AActeur

Use case C« use »

Use case B

«extend »

Actor fires the

use case A

C contains the behaviour

described in A

B extends the behaviour

described in A

Use-Case Diagram

Fig. A1.


http://www.cimdata.com/

http://www.cimdata.com/

[7] Fukanaga A, Pree W, Kimura T. Functions as data objects in a

data flow based visual language. ACM Computer Science

Conference, Indianapolis, 1993.

[8] Alexander C, Ishikawa S, Silverstein M, Jacobson M, Friksdhl-

King I, Angel S. A pattern language. New York: Oxford

University Press, 1977.

[9] Gamma E, Helm R, Johnson R, Vlissides J. Design patterns:

elements of reusable object oriented software. Reading, MA:

Addison-Wesley Publishing Company, 1995.

[10] Beck K, Cunningham W. Using pattern languages for object-

oriented programs, Norman MEYROWITZ, OOPSLA’87, 1987.

[11] Coad P. Object-oriented patterns. Commun ACM, 1992;35(9).

[12] Harrington HJ. Business process improvement—the break-

through strategy for total quality, productivity, and competitive-

ness. New York: McGraw-Hill Inc, 1991.

[13] Xue D, Yadav S, Norrie DH. Knowledge base and database

representation for intelligent concurrent design. Comput Aided

Des J 1999;131–45.

[14] Kimura F, Suzuki H. Representing background information for

product description to support product development process. Ann

CIRP Annals 1995;44(1):113–6.

[15] Ranta M, M.antyl.a M, Umeda Y, Tomiyama T. Integration of

functional and feature-based product modeling—the IMS/GNO-

SIS experience. Comput-Aided Des 1996;28(5):371–81.

[16] Rosenman MA, Gero JS. Modelling multiple views of design

objects in a collaborative CAD environment. Comput Aided Des

1996;28(3):193–205.

[17] AMICE. CIMOSA: Open System Architecture for CIM, 2nd

extended and revised version. Berlin: Springer, 1993.

[18] Williams TJ. The Perdue enterprise reference architecture. Perdue

Laboratory for Applied Industrial Control, Perdue University,

West Lafayette, IN, USA, March 16, 1992.

[19] Fox MS, Chionglo JF, Fadel FG. A common-sense model of the

enterprise. Proceedings of the Industrial Engineering Research

Conference, 1993.

[20] Ladet P, Vernadat F. The dimensions of integrated manufactur-

ing systems engineering. Integrated manufacturing systems

engineering. London: Chapman & Hall, 1995.

[21] Vernadat F. Enterprise modelling and integration: principles and

applications. London: Chapman & Hall, 1996.

[22] El Mhamedi A, Lerch C, Marier S, Sonntag M, Vernadat F,

Int!egration des activit!es non structur!ees das la mod!elisation des sys-

t"emes de production ACNOS. Final report of the project

ACNOS—DSPT 8 en productique du MENESR, 1997 (in

French).

[23] Jacobson I, Ericsson M, Jacobson A. The object advantage:

business process reengineering with object technology. Reading,

MA: Addison Wesley, 1995.

[24] Coad D, North P, Mayfield M. Object models—strategies,

patterns and applications. Yourdon Press Computing Series,

1996.

[25] Fowler M. Analysis patterns: reusable object models. Reading

MA: Addison-Wesley, 1997.

[26] Gamma E, Helm R, Johnson R, Vlissides J. Design patterns:

elements of object oriented software architecture. Reading, MA:

Addison-Wesley, 1994.

[27] Dahchour M. Formalizing materialization using a metaclass

approach. In: Proceedings of CASSE’98, 1998.

[28] OMG, Product data management enablers–request for proposal.

Object Management Group document, 1997.

[29] Van Veen EA. Modelling product structures by generic bills-

of-material. Ph.D. thesis, Eindhoven University of Technology,

1991.

[30] Peltonen H, M.annist.o T, Alho K, Sulonen R, Product config-

urations—an application for prototype object approach. Proceed-

ings of the Eighth ECOOP Conference, Lecture Notes in

Computer Science, vol. 821. Berlin: Springer, 1994. p. 513–34.

[31] IMS/Gnosis Consortium. Report on the IMS/GNOSIS test case:

configuration systems for knowledge systematization, 1995.

[32] Rumbaugh J, Jacobson I, Booch G. Unified modeling language

reference manual. Reading, MA: Addison Wesley, 1997, ISBN:

0-201-30998-X.

[33] Magnan M, Oussalah C. Objets et composition. In: C. Oussalah,

editor. ‘‘Ingenierie Objet—concepts et techniques’’, InterEditions,

1997 [in French].

[34] AFNOR. NF EN 1325—Vocabulaire du management de la

valeur, de l’analyse de la valeur et de l’analyse fonctionnelle—

Partie 1: analyse de la valeur et analyse fonctionnelle. Afnor,

Paris, November 1996 [in French].

[35] Maurino M. La gestion des donnees techniques—technologie du

concurrent engineering. Paris: Masson, 1993 [in French].

[36] Kang KC, Cohen SG, Hess JA, Novak WE, Spencer Peterson A.

Feature-oriented domain analysis (FODA) feasibility study.

Technical Report AD-A235 785, Carnegie-Mellon University,

Software Engineering Institute, 1990

[37] Rieu D, Giraudin JP, Saint-Marcel C, Front-Conte A. Des

operations et des relations pour les patrons de conception. In:

Proceedings of Inforsid 1999, La Garde, France, 1–4 Juin 1999

[in French].


Product information systems engineering: an approach for building product models by reuse of...

Documents

Transcript of Product information systems engineering: an approach for building product models by reuse of...