Typing Mechanism Principles

The unified typing system relies on four capabilities. You can:

• Describe your own semantic such as Engine, Deck, Hull, and Connecting Rod. This semantic is called specialization type. A specialization type is a specialization of a DS type. Each specialization type can own some attributes such as RodLength, MaxWeight, Size.
• Specialize DS extensions. These extensions can be applied to specialization types or DS types objects using the Manage Customer Extension command. These extensions are called specialization extensions and can own attributes. They are available in the New Content dialog box.
• Describe your own extensions that can be applied to specialization types or DS types objects. These extensions are called customer extensions and can own attributes.
• Create deployment extensions. Deployment extensions can be added to any object at creation time:
  • automatically if the extension is automatic
  • through a business rule if it is not automatic.
  Non automatic extensions can be allocated on a collaborative space basis as the business rule is selected from the current credentials.

The above picture illustrates the typing system:

• The large orange box represents a package delivered by DS. A package is a logical grouping of types, extensions and their attributes. For example : PRODUCT, RFLVPMLogical are packages.
• The large blue box is a customer specialization package. It is created using Specialize Data Model. It contains the specialization objects of the DS objects found in the referenced package and can contain also the customer extensions.
• The large green box is a deployment package. It contains the deployment extensions and the unique keys.

Some objects are tagged:

• With a star, meaning that the object can be specialized. Customer objects can always be specialized, except deployment extensions.
• With a full circle, meaning that the object is extensible. It applies only to types.
• With an empty circle, meaning that the object is abstract. Customer objects cannot be abstract.

The specialization types, specialization extensions, customer extensions and deployment extensions are grouped in packages. Three types of packages are available:

• DS packages: Packages delivered by DS that you cannot modify.
• Specialization packages: Packages containing specialization types and/or specialization extensions and/or customer extensions. A specialization package can specialize only one DS package. A specialization package cannot be specialized. A customer extension can extend several types of the specialized package.
• Deployment packages: Packages containing deployment extensions and unique keys. Two types of deployment packages are available:
  • Packages containing extension for IRPC types
  • Packages containing extensions for E/R types

Customizing data models may serve several objectives and the Unified typing configuration tools provide several different data customization patterns.

The most common pattern is the ability to extend 3DEXPERIENCE apps data models with customer attributes: this is done by defining deployment extensions that will contain the attributes and that will be applied to objects of a given type. For more information, see the Model Customization guide.

The second pattern is the ability to define sub types (called specialization types) of 3DEXPERIENCE data models: the notion of sub type is particularly useful when you want to introduce more detailed categories of objects than the one provided by the 3DEXPERIENCE apps and that will be proposed to end user for selection. For more information, see the Specialize Data Model guide.

Finally, the last pattern -which is less common-, consists in defining data extensions that the end-user will use to extend a particular object. For this, the end-user has access to generic user interfaces enabling this extension. The same kind of extension can be used to extend objects of different types. The purpose is to model facets that can be applied to different objects. For more information, see the Specialize Data Model guide.

The domain expert can define specialization types gathered in packages. Using those types, he can describe his own semantic. The packages are built by creating specializations containing customer extensions.

• Specializations are defined by inheriting (directly or not) from DS types and extensions that can be specialized.
• Customer extensions are defined as extending extensible types.
• Collections of attributes can be defined on those types and extensions.
• Icons can be associated with a specialization type.
• NLS translations for types names and attributes names can be defined.

The administrator can deploy these customizations on his 3DEXPERIENCE platform server.

Once the customization is deployed, the final user can use the native apps that manipulate those OOTB types.

As the end user, you can:

• Create objects. You select the type you want to create (the OOTB type or the functional specializations that inherits from this type). You can then create an object of the selected type with all the attributes defined in the hierarchy of types.
• Create objects using apps by selecting the sub types of the type you want to create (the OOTB type or the functional specializations that inherits from this type). Once this is done, you create an object of the selected type with all the attributes defined in the hierarchy of types.
• Add extensions to objects using apps. You select the sub types of the extension type you want to add (the OOTB extension type or the specialization extension that inherits from this extension). Once this is done, you extend the object with the selected extension that contains all the attributes defined in the hierarchy of extensions.
• Use a generic command to extend an object (that must be extensible) with a customer extension of your choice.
• Edit the properties of the objects created by selecting the objects attributes.
• Save all objects in database and close the editors.
• Perform searches (using standard keywords in the search box): if you use a keyword corresponding to an OOTB type, the result will contain all the objects of this type including the objects of the specialization types.
• Perform advanced searches showing you the list of searchable types including their specializations. You can also select the specialization and the customer extensions you want to use. You finally define criteria on attributes. The result of the search contains the objects of the selected type (including the objects of sub types) that match the search criteria. If an extension was defined, only the objects extended with this extension (or a sub extension) are returned.
  Notes:

  • The maturity graph associated with an object with a specialized type is by default the same maturity graph as the one defined on the OOTB type that it specializes.
  • From an Enterprise Knowledge Language perspective, the objects are seen as primary types (the type chosen at creation) and if the objects are extended, they are seen also as “supporting” those extension types, also called secondary types.
  • You can define Quality Rules Reuse rules that are applied to objects of a given type (primary or secondary).
  • You can associate a business rule with a given type (in a project, for a given opening) in the Data Setup app. This type belongs to the primary types. It means that only the objects that support the type as their primary types (or sub types) will use this business rule.
  • You can define Knowledge reports on the objects of a given type (primary or secondary).
  • Using a rule, you can ask for the creation of an object of a given type (including specialization types).
• Export and import briefcases to exchange data between:
  • Servers that work with the same type customization (they share the same specialization packages). In this case, the objects are imported with the right specialization types. Specialization extensions and deployment extensions are lost except if you created a business rule (PLMImportExportAttributeValuation).
  • Servers that do not work with the same type customization: the server dictionary receiving the data does not contain the specialization packages. In this case, the objects are imported with the first DS OOTB types. The attributes specific to these specialization types and extensions are lost. The PLMImportExportAttributeValuation business rule can be used to choose the type or the extensions.

A domain expert can iterate several times on the definition of its customization.

As a domain expert, you can:

• Add new specialization types to a package.
• Add new specialization extensions to a type.
• Add new customer extensions to a type.
• Add attributes to types.
• Modify the visibility of an attribute (hidden, read only, read write).
• Modify the Icons, the NLS translations, the predefined query.
• Change the default value.
• Change the preferred unit.
• Extend a range.