Know How Modeler Description & Customization

This section first presents the objects representing the Know How 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 Know How modeler enables the definition of rules and checks. It also allows to model structures of those elements in rule sets.

This is summarized in the following UML schema:

Fig.1: Know How UML Model

• Rule: is an elementary object that has its own lifecycle (it can be created independently, versioned, duplicated, ...). A rule defines an action that we want to apply on any object of a given type. The typing hierarchy that is mentioned here is the "Knowledge Object Model" typing hierarchy. The action that we want to apply is written in a scripting language: the Enterprise Knowledge Language (EKL). A rule is a declaration of an intent. It does not describe where it is used.
• Check: is an elementary object that has its own lifecycle (it can be created independently, versioned, duplicated, ...). A check defines a statement that we want to verify on any object of a given type. It is very close to a rule. The main difference is that a check only describes a statement (that will be true or false on the final objects that we want to check) whereas a rule applies a treatment on the objects and potentially modifies the objects on which it will be applied.
• Rule set: is an elementary object that has its own lifecycle (it can be created independently, versioned, duplicated, ...). A rule set is created to regroup several rules and checks together, in order to apply them all at the same time. It is a recursive concept since a rule set can regroup different rule sets also. Note that a same rule, check or rule set can be part of several rule sets.

The Know How model is implemented with PLM Core Object as follows:

KnowHow is described through 5 modeler PLM packages :

• PLMKnowHowRule
• PLMKnowHowCheck
• PLMKnowHowRuleSet
• PLMKnowHowGenericRuleBaseComponent
• PLMKnowHowRuleBaseComponent

The reason of the split in several packages is due to implementation constraints. Not for a particular objective.

PLMKnowHowCheck

PLMKnowHowRuleSet

PLMKnowHowGenericRuleBaseComponent

PLMKnowHowRuleBaseComponent

<Insert a picture showing the PLM classes (using internal name) of the package; distinct the class to customize from the instantiable one.>

<Below the picture explains the relationship between the modeler's object and the PLM classes>

<Remove the useless lines; this table is useful to find the PLM Classes names through the Search ; Name inside picture are not usable for the Search... >

<if the package contains PLM extensions, describe them too; but do not list the extended PLM classes, except it it a public inform>

This section lists and describes the PLM Opening ID implemented by the following PLM classes of the Know How 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.

PackageExternalName3 must be partially (or fully) customized.

<Remove the useless lines - Choose Yes or No - Remarks column specifies all deviations from the generic customization process- if any deviation remove the column>

When a PLM attribute is defined (inside modeler PLM package) some features like its editability criteria, mandatory /optional option, can be overwritten 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.

<if your modeler contains at least one package to customize add these sentences:

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.>

< in all cases add the following sentence>

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.

<or> To create a UI mask you should respect the following rules :

• rule1
• rule2
• ...

<here list the specific rules; add bullet if the rules are package specific>

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 >