Rules and Standards |
CAA V5 Feature Modeler RulesStandard rules for working with the feature modeler |
AbstractCAA 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: |
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. |
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.
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]
Rule Title |
Rule Description |
Explanation |
Notes |
Metrics |
Objectives |
1-Catalog identification and creation |
|
|
(Nb of deviations)/(Nb of entries) |
0% |
|
2-Catalog storage location |
|
|
(Nb of deviations)/(Nb of entries) |
0% |
[Top]
Rule Title |
Rule Description |
Explanation |
Notes |
Metrics |
Objectives |
1-Base StartUp and Extension creation and Identification |
|
|
|
(Nb of deviations)/(Nb of entries) |
0% |
2-Deriving StartUps |
|
|
(Nb of deviations)/(Nb of entries) |
0% |
[Top]
Rule Title |
Rule Description |
Explanation |
Notes |
Metrics |
Objectives |
1-Creating a new feature by instantiation |
|
|
(Nb of deviations)/(Nb of entries) |
0% |
[Top]
Rule Title |
Rule Description |
Explanation |
Notes |
Metrics |
Objectives |
1-Attribute status |
|
|
|
(Nb of deviations)/(Nb of entries) |
0% |
2-Attribute Creation and Access |
|
|
(Nb of deviations)/(Nb of entries) |
0% |
[Top]
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 |
|
|
(Nb of deviations)/(Nb of entries) |
0% |
|
2-Modifying StartUp hierarchy |
|
|
(Nb of deviations)/(Nb of entries) |
0% |
|
3-Modifying StartUp catalogs | If a catalog existed in V5Rn, then in V5Rp:
|
(Nb of deviations)/(Nb of entries) |
0% |
[Top]
Version: 1.0 [Dec 2000] | Document created |
[Top] |
Copyright © 2000, Dassault Systèmes. All rights reserved.