Product Modeler Description & Customization

This section first presents the objects representing the Product modeler. Then it describes how this object model view has been translated towards PLM objects based on PLM Core Modeler objects. You will see the description of each PLM package defining these PLM objects.

The Product model is based on a Product Reference aggregating other components:

• Product Instance.
• Product Representation Instance.
• Product Port.
• Product Connection or Connection from other Modelers.

This is summarized in the following UML schema:

• The Product Reference is the only component that can aggregate other components. A Product Reference or a Product Representation Reference can be instantiated. These resulting components are Product instances and Product Representation Instances.

• Product Ports  are components that are used to publish parts of a Product Model object that are otherwise inaccessible

• Connections are components that establish semantic relationships between Product Model components. Examples of Connections as seen by the user include CATIA contextual links and assembly constraints. The Product reference can aggregate Product Connections (coming from the PRODUCT modeler) as from other PLM modelers.

Product is implemented through one modeler PLM class package of the same name. The Product package, like any PLM package, consists in PLM Classes enriching the PLM Core Classes.

The Product specializes the PLM Core modeler by adding PLM attributes and semantics

This section lists and describes the PLM Opening ID implemented by the following PLM classes of the XXX modeler.

<Explanations:

• col1 : PLM Openings ID name:  the ones of INFRA +  the ones provided by this modeler
• col2 :  Describe the behavior of the implementation >

This part consist in to create a new package when the modeler PLM package must be customized.

Product must be fully customized.

When a PLM attribute is defined (inside modeler PLM package) some features like its editability criteria, mandatory /optonal option, can be overwriten by UI  mask. You can say this PLM attribute is not writable in Query context, this PLM attribute is mandatory in Create context, this user PLM attribute is not never visible and so one. A set of UI masks form a security mask file. We say security mask because it is associated with these files security information. For a people, and a given context can be associated a security mask.

For each customized Modeler PLM package, at least one UI mask file must be created (for the default security mask ), since it must contain the new PLM Attributes. When you use the tool to create a customization, a default UI mask file is provided taken into account the added PLM attributes. You can modify  the default file to introduce your change.

If you want create a new security mask file, you should provide a UI mask for all the "AsIs" modeler PLM packages and for each customization of the "Customizable"  modeler PLM package. 

Rules to respect for a new UI mask creation

No specific rule to customize UI mask file.

You can yourself integrate your business logic for each customization of:

• ExternalClassName1

PLM Opening ID	Remarks
ID1
ID2

<IDx : name of the PLM OpeningID : The ones of INFRA +  the ones provided by this modeler ; add a link to the article describing how to implement it : CAABusinessLogicInfra.doc for INFRA ; CAABusinessLogicPLMModeler.doc for modeler >

• ExternalClassName2

<if the modeler only contains AsIs package, replace the lines just above, by the sentence "No customization is possible">

<Each package name in the reference table is an external name, but the links refer to a file whose the name is build with the package's internal name >