Rules and Standards

CAA V5 Feature Modeler Rules

Standard rules for working with the feature modeler

Abstract

CAA V5 Feature Modeler rules must necessarily be considered in order to create functional and coherent applications. These rules have been designed as guidelines in performing the most frequent activities related to CAA programming with the Feature Modeler:


Introduction

This document defines a number of rules to follow while working with the feature modeler. Following is a quick review of the concepts that are at the base of the rules defined here.

The feature modeler is based on a prototype/instance model. As such, the creation of new features in a document is initially based on the retrieval of a prototype object called a StartUp. All StartUps must be created in catalogs in order to be shareable between documents as well as for memory size and performance reasons. Catalogs are protected by a client identifier that must be known in order to access the catalog. At run-time, new features are created by instantiating either StartUps from catalogs or by instantiating other features already existing in the document.

A StartUp can be enriched with new behaviors and/or data in essentially two ways:

A StartUp can be created in several different ways:

An extension is created like a StartUp except that it can only derive from another extension owned by the same user.

Here is a graphical illustration of the methods and mechanisms described above:

Case 1: Create a StartUp "from scratch" and derive a new StartUp from it.

Client B creates a new StartUp "from scratch" with late type "XXX". Client B then derives a new StartUp with late type "YYY" from "XXX". Client B can perform this direct derivation because he is the owner of both.

Case 2: Create a new derived StartUp using a provided Factory.

Client B creates a new StartUp with late type "YYY" deriving from the StartUp with late type "XXX" by using the provided factory. Since Client B is not the owner of the "XXX" late type, his only means of deriving a new StartUp from it is through the provided factory.

Case 3: Create a feature extension "from scratch" and use it to extend a feature object. Create a derived feature extension.

Client B activates a feature extension on a feature object. The feature object can be his own, Dassault Systemes' or Client A's. Client B can create a new feature extension by deriving one of his already-existing feature extensions.

Extension vs. Derivation

The feature extension mechanism allows a base feature to be enriched with behaviors and data belonging to a feature extension that is activated at run-time. It is used in the case where a base object has characteristics common to several different applications. Using extensions, each application can take into account its own specific needs while the base feature object remains stable and unchanged.

The derivation mechanism alters the base feature by actually creating a new feature late type having different data and behaviors.

It is important to understand that in the case of a derived StartUp, an active application depends on the existence of API managing the derived/deriving StartUp as well as on the existence of the catalogs containing the derived/deriving StartUps. On the other hand, in the case of extensions, the active application will tolerate the absence of an extension.

Between these two ways of enriching feature objects, choose the appropriate one given the specific application needs and remember that the extension mechanism should be favored whenever possible.

Instantiation

A feature object is instantiated in two possible types of containers: a general applicative container or a Dassault Systemes container, depending on the API used. In other words, if using the ObjectSpecsModeler API to manipulate client-owned features in a specific client applicative context, the general applicative container must be used. Otherwise, if using Dassault Systemes specific API to manipulate features in a specific applicative context, the container used will be a Dassault Systemes container.

"Public" and "Private" features and attributes

A StartUp can be either "public" or "private". A "public" StartUp means that its derivation is permitted by others. In this case, the owner of the "public" StartUp must provide a factory that will actually create the derived StartUp. The owner of the "public" StartUp also provides specific API allowing the access and manipulation of the features instantiated from it. A "private" StartUp, on the other hand, remains hidden from others.

The attributes of a "public" StartUp also have a "public" or "private" status defined at the time of their creation. A "public" attribute can be accessible in read and/or write mode, whereas a "private" attribute is not accessible at all.

Managing StartUp Compatibility

In order to ensure upward compability of feature data, specific rules must be followed and applied when modifying StartUps and StartUp catalogs. These rules are classified into 3 categories:

[Top]

Feature Catalog Creation and Access Rules

Rule Title

Rule Description

Explanation

Notes

Metrics

Objectives

1-Catalog identification and creation
  • Follow naming rules when creating a new catalog
  • Always define a unique client identifier for a new catalog.
  • A catalog must be named using the following naming rule: CAA<FWAlias>name.CATfct. Naming rules should be followed in order to avoid the collision of one catalog with another.
  • A client identifier is necessary in order to access and protect the catalog.
(Nb of deviations)/(Nb of entries)

0%

2-Catalog storage location
  • The storage pathname of a new catalog should reference the CNext + resources + graphic directory of the current framework.
  • In order to be accessible during an AccessCatalog, UpgradeCatalog or OpenPrereqCatalog operation, a catalog must be found under the current "OS" + resources + graphic directory. If it is stored under the CNext + resources + graphic directory as recommended, the update of the runtime view will then automatically place the catalog in the proper directory for being accessible.
(Nb of deviations)/(Nb of entries)

0%

[Top]

StartUp Creation, Extension and Derivation Rules

Rule Title

Rule Description

Explanation

Notes

Metrics

Objectives

1-Base StartUp and Extension creation and Identification
  • A new StartUp or extension name and late type should follow standard naming rules.
  • Attributes should be added at StartUp or extension creation time.
  • A StartUp or extension must be named using the following naming rule: V5<FWAlias>FeatureName or V5<FWAlias>LateTypeName. Naming rules should be followed in order to avoid the collision of one StartUp with another.
  • For extensions, it is not even possible to add attributes or to modify attribute values at run-time.
  • For "public" StartUps, "public" attributes can only be added at build-time. "Private" attributes may, however, be added at run-time as well.
  • Attribute values on StartUps are propagated to all of the instances based on this StartUp.
  • It is better that attributes be added and valuated at creation time in order to gain performance at run-time. Furthermore, the definition of the "public"/"private" status of an attribute is done at creation time as well.

(Nb of deviations)/(Nb of entries)

0%

2-Deriving StartUps
  • The owner of a "public" StartUp must provide a factory allowing its derivation.
  • The owner of a "public" StartUp must provide API in order to manipulate those features instantiated from it.
  • The users deriving the StartUp need not access the owner's catalog themselves, nor should they have visibility on those attributes of the StartUp considered as "private".
  • The API must take into account the "public"/"private" status of the StartUp's attributes.
(Nb of deviations)/(Nb of entries)

0%

[Top]

Feature Creation, Extension and Deletion Rules

Rule Title

Rule Description

Explanation

Notes

Metrics

Objectives

1-Creating a new feature by instantiation
  • New features should always be created in applicative containers if they are instances of client-owned StartUps created "from scratch".
  • An applicative container should be named according to standard naming rules for applicative containers.
  • The new feature's name should follow the standard naming rules for features.
  • An applicative container must be named using the following naming rule: V5<FWAlias>ContainerName. Naming rules should be followed in order to avoid the collision of one applicative container with another.
  • A feature object must be named using the following naming rule: V5<FWAlias>FeatureName. Naming rules should be followed in order to avoid the collision of one feature with another.
(Nb of deviations)/(Nb of entries)

0%

[Top]

Attribute Creation and Access Rules

Rule Title

Rule Description

Explanation

Notes

Metrics

Objectives

1-Attribute status
  • The "public"/"private" status of an attribute is defined at the time of its creation.
  • The "public"/"private" status of an attribute cannot be changed once it has been defined.
  • If an attribute is defined as available for read and/or write access, it is said to be a "public" attribute. Otherwise, it is said to be a "private" attribute.
(Nb of deviations)/(Nb of entries)

0%

2-Attribute Creation and Access
  • An attribute should be added to a StartUp at build-time (i.e., StartUp creation time).
  • An attribute should be valuated with a default value at build-time (i.e., StartUp creation time).
  • A "public" attribute cannot be defined at run-time.
  • A "private" attribute may be defined at run-time.
(Nb of deviations)/(Nb of entries)

0%

[Top]

Data Compatibility Rules

The following notation is used here: V5Rn and V5Rp designate two releases of CATIA, where p is greater than n.

Rule Title

Rule Description

Explanation

Notes

Metrics

Objectives

1-Modifying StartUp structure
  • A new attribute can be added in V5Rp. However, if the new attribute is a "tk_component" type, the already existing feature objects instantiated from it must be specifically synchronized.
  • An attribute can be moved from a StartUp to one of its base StartUps except if it is a "tk_component" attribute in which case it must not be moved.
  • The sp_IN/OUT facet of the attribute of a StartUp should not be modified in order to avoid subsequent update problems.
  • Adding an attribute in V5Rp is possible because applications written for V5Rn will go on running without caring for the new attribute. In V5Rp, the synchronization mechanism automatically adds the attribute to any instance that does not already have it. If this attribute is accessed, it is valued using the StartUp attribute value, if this value exists. The application must either provide a default value that is compatible with its process, or valuate the attribute when accessing it on the instance. Remember that the automatic synchronization mechanism does not apply to "tk_component" types of attributes.
(Nb of deviations)/(Nb of entries)

0%

2-Modifying StartUp hierarchy
  • A StartUp must not be deleted unless it has definitely never been used, i.e., instantiated or derived.
  • A StartUp cannot be added into a catalog if another StartUp with the same type exists in one of the prerequisite catalogs.
(Nb of deviations)/(Nb of entries)

0%

3-Modifying StartUp catalogs If a catalog existed in V5Rn, then in V5Rp:
  • Its name or its UID must not be changed.
(Nb of deviations)/(Nb of entries)

0%

[Top]


History

Version: 1.0 [Dec 2000] Document created
[Top]

Copyright © 2000, Dassault Systèmes. All rights reserved.